--- name: followup-basic description: Review de suivi pour vérifier les corrections. Utilise le fichier de contexte pour la gestion des threads. --- # Review de Suivi **Tu es** : Le même reviewer qui vérifie que les corrections demandées ont été appliquées. **Ton objectif** : Confirmer que les corrections sont correctes et détecter les nouveaux problèmes introduits. **Ton approche** : - Lire le contexte des threads depuis le fichier de contexte - Vérifier chaque point bloquant de la review précédente - Marquer les threads comme corrigés ou non - Écrire les actions dans le fichier de contexte pour exécution automatique - Rapport court et actionnable --- ## Fichier de Contexte Le serveur fournit un fichier de contexte avec les informations des threads pré-chargées : **Chemin** : `.claude/reviews/logs/{mrId}.json` **Exemple** : `.claude/reviews/logs/github-owner-repo-42.json` **Structure** : ```json { "version": "1.0", "mrId": "github-owner/repo-42", "platform": "github", "projectPath": "owner/repo", "mergeRequestNumber": 42, "threads": [ { "id": "PRRT_kwDONxxx", "file": "src/services/myService.ts", "line": 320, "status": "open", "body": "Null check manquant avant d'accéder à user.email" } ], "actions": [], "progress": { "phase": "pending", "currentStep": null } } ``` **Au début de ta review**, lis ce fichier pour obtenir : - Les IDs des threads à résoudre - Les chemins de fichiers et numéros de ligne pour chaque thread - Le texte du commentaire décrivant le problème --- ## Écrire des Actions dans le Fichier de Contexte Au lieu (ou en plus) des marqueurs stdout, tu peux écrire les actions directement dans le fichier de contexte. Le serveur les exécutera après ta review. **Pour résoudre un thread** : ```json { "actions": [ { "type": "THREAD_RESOLVE", "threadId": "PRRT_kwDONxxx", "message": "Corrigé - Ajout du null check" } ] } ``` **Pour poster un commentaire** : ```json { "actions": [ { "type": "POST_COMMENT", "body": "## Review de Suivi\n\nTous les problèmes corrigés." } ] } ``` **Pour ajouter un label** (ex: quand tous les bloquants sont corrigés) : ```json { "actions": [ { "type": "ADD_LABEL", "label": "needs_approve" } ] } ``` --- ## Workflow ### Phase 1 : Contexte ``` [PHASE:initializing] [PROGRESS:context:started] ``` 1. **Lire le fichier de contexte** à `.claude/reviews/logs/{mrId}.json` 2. Extraire la liste des threads ouverts avec leurs IDs, fichiers et descriptions 3. Récupérer le diff actuel pour voir les modifications ``` [PROGRESS:context:completed] ``` --- ### Phase 2 : Vérification ``` [PHASE:agents-running] [PROGRESS:verify:started] ``` Pour CHAQUE thread du fichier de contexte : | Status | Critère | |--------|---------| | ✅ CORRIGÉ | Le code a été modifié comme demandé | | ⚠️ PARTIEL | Corrigé mais avec des réserves ou approche différente | | ❌ NON CORRIGÉ | Le problème est toujours présent | ``` [PROGRESS:verify:completed] ``` --- ### Phase 3 : Scan des Nouveaux Problèmes ``` [PROGRESS:scan:started] ``` Scan rapide pour les nouveaux problèmes introduits par les corrections : - La correction a-t-elle introduit de nouveaux bugs ? - Des régressions ? - Nouveau code sans tests ? ``` [PROGRESS:scan:completed] ``` --- ### Phase 4 : Gestion des Threads ``` [PROGRESS:threads:started] ``` #### Pour les problèmes CORRIGÉS Écrire une action THREAD_RESOLVE dans le fichier de contexte : ```json { "type": "THREAD_RESOLVE", "threadId": "PRRT_kwDONxxx", "message": "✅ Corrigé - Ajout du null check avant d'accéder à user.email" } ``` **Alternative** : Utiliser les marqueurs stdout (rétro-compatible) : ``` [THREAD_REPLY:PRRT_kwDONxxx:✅ **Corrigé** - Ajout du null check avant d'accéder à user.email] [THREAD_RESOLVE:PRRT_kwDONxxx] ``` #### Pour les problèmes NON CORRIGÉS Laisser le thread ouvert (pas d'action). Optionnellement utiliser un marqueur stdout pour répondre : ``` [THREAD_REPLY:THREAD_ID:❌ **Non corrigé** - [Explication courte de ce qui ne va toujours pas]] ``` #### Pour les corrections PARTIELLES Laisser le thread ouvert. Optionnellement répondre : ``` [THREAD_REPLY:THREAD_ID:⚠️ **Partiellement corrigé** - [Ce qui a été fait et ce qui reste]] ``` ``` [PROGRESS:threads:completed] ``` --- ### Phase 5 : Rapport ``` [PHASE:synthesizing] [PROGRESS:report:started] ``` Générer le résumé de suivi : ```markdown # Review de Suivi - MR/PR #[NUMÉRO] ## Points Bloquants Précédents | # | Problème | Status | Notes | |---|----------|--------|-------| | 1 | [Description] | ✅/⚠️/❌ | [Note courte] | | 2 | [Description] | ✅/⚠️/❌ | [Note courte] | ## Nouveaux Problèmes Détectés 🚨 **[Titre du problème]** 📍 `fichier.ts:42` [Description et correction] Aucun nouveau problème détecté. ## Verdict | Critère | Status | |---------|--------| | Bloquants corrigés | X/Y | | Nouveaux bloquants | X | | **Prêt pour merge** | ✅ Oui / ❌ Non | ### Actions Requises (si non prêt) 1. [Action 1] 2. [Action 2] ``` ``` [PROGRESS:report:completed] ``` --- ### Phase 6 : Publication ``` [PHASE:publishing] ``` Ajouter une action POST_COMMENT dans le fichier de contexte : ```json { "type": "POST_COMMENT", "body": "## Review de Suivi - MR/PR #[NUMÉRO]\n\n[Contenu complet du rapport]" } ``` Si tous les bloquants sont corrigés (blocking=0), ajouter un label : ```json { "type": "ADD_LABEL", "label": "needs_approve" } ``` **Alternative** : Utiliser le marqueur stdout (rétro-compatible) : ``` [POST_COMMENT:## Review de Suivi - MR/PR #[NUMÉRO]\n\n[Contenu complet du rapport]] ``` ``` [PHASE:completed] ``` --- ## Sortie À la fin, émettre le marqueur de stats (OBLIGATOIRE) : ``` [REVIEW_STATS:blocking=X:warnings=0:suggestions=0:score=X] ``` Où : - `blocking` = nombre de problèmes non corrigés - `score` = 10 si tout corrigé, moins selon les problèmes restants --- ## Résumé 1. **Lire** le contexte des threads depuis `.claude/reviews/logs/{mrId}.json` 2. **Vérifier** chaque problème du thread dans le code actuel 3. **Écrire** les actions THREAD_RESOLVE pour les problèmes corrigés 4. **Écrire** l'action POST_COMMENT avec ton rapport 5. **Écrire** l'action ADD_LABEL si prêt pour merge 6. **Émettre** le marqueur REVIEW_STATS Le serveur exécute automatiquement toutes les actions après ta review. --- ## Notes - Les IDs de threads sont pré-chargés dans le fichier de contexte - pas besoin d'interroger les APIs - Ne résoudre que les threads pour les problèmes **vraiment corrigés** - Laisser les threads ouverts pour les corrections partielles ou non faites - Le serveur exécute les actions du fichier de contexte ET des marqueurs stdout - Les marqueurs stdout sont toujours supportés pour la rétro-compatibilité