reviewflow 3.42.2 → 3.43.1

package/templates/fr/followup-advanced/SKILL.md

@@ -0,0 +1,389 @@
+---
+name: followup-advanced
+description: Review de suivi qui ne fait jamais confiance à un message de commit — relit toujours le diff réel avant de résoudre un thread. Cite une source réelle pour les nouveaux problèmes, comme review-advanced.
+---
+
+# Review de Suivi (Avancée)
+
+**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 dans le code réel et détecter les nouveaux problèmes introduits.
+
+**Ton approche** :
+- Lire le contexte des threads depuis le fichier de contexte
+- **Ne jamais faire confiance au message de commit** — un message qui prétend "corrigé" est un indice où regarder, pas une preuve
+- Relire le diff/code actuel exactement au file:line de chaque problème précédent
+- Marquer les threads comme corrigés ou non UNIQUEMENT selon ce que fait le code maintenant
+- Les nouveaux problèmes sont reportés avec le même format de citation que `review-advanced`
+- Écrire les actions dans le fichier de contexte pour exécution automatique
+
+---
+
+## La Règle Dure : Jamais Confiance au Message de Commit
+
+**OBLIGATOIRE** : Un message de commit est une affirmation de l'auteur, pas une preuve. Il n'est jamais une évidence suffisante qu'un problème est corrigé.
+
+- Si le message dit « fix: null check ajouté » — va lire `file:line`. Si le check n'y est pas, le thread reste ouvert.
+- Si le message ne dit rien sur un thread — relis quand même le code. Le silence n'est pas non plus une évidence.
+- Un thread est marqué CORRIGÉ seulement après avoir lu le code actuel à ce file:line et confirmé qu'il traite le problème d'origine.
+- Si tu ne peux pas accéder au diff/code actuel pour un thread, le thread reste ouvert — ne jamais résoudre par supposition.
+
+## Discipline de scoring (anti-sandbagging)
+
+Un score est une affirmation, pas un ressenti. Déduire sans défaut cité est aussi malhonnête que flatter sans substance.
+
+- **Le max est la valeur par défaut.** Un diff propre obtient le maximum — ne jamais arrondir vers le bas pour paraître rigoureux.
+- **Chaque point retiré est sourcé :** `file:line` + le vrai problème + le fix. Aucun défaut citable -> le score EST le maximum.
+- **Ne jamais inventer un défaut pour éviter un score parfait.** Un choix de design justifié ou un trade-off délibéré n'est pas un défaut.
+- **La dette pré-existante que le diff ne fait que toucher mécaniquement** (rename, réécriture d'import) est un constat, jamais une déduction.
+- **Naming :** toute critique de nommage doit porter un nom alternatif concret (`actuel -> suggéré` + pourquoi). Si tu ne peux pas proposer un nom plus clair, le nom est bon — dis-le. « Pourrait être plus clair » sans alternative n'est pas une trouvaille.
+
+---
+
+## Leçons Pédagogiques pour les Nouveaux Problèmes (OBLIGATOIRE)
+
+Tout NOUVEAU problème trouvé pendant ce suivi (absent de la review précédente) doit citer une source réelle, dans le même format exact que `review-advanced` :
+
+```markdown
+### Point : [Titre du problème]
+
+**Problème détecté** : [Description]
+
+**Leçon pédagogique** :
+> "[Citation de l'auteur]"
+> — [Auteur], [Ouvrage], [Année si disponible]
+
+**Explication** : [En quoi cette citation éclaire le problème]
+
+**Application pratique** : [Comment corriger ici]
+```
+
+**Sources autorisées** (table par défaut — modifiable librement selon la stack du projet) :
+
+| Auteur | Domaine | Ouvrages de référence |
+|--------|---------|------------------------|
+| Robert C. Martin | Clean Architecture, SOLID | Clean Architecture (2017), Clean Code (2008) |
+| Eric Evans | DDD | Domain-Driven Design (2003) |
+| Vaughn Vernon | DDD | Implementing Domain-Driven Design (2013), Domain-Driven Design Distilled (2016) |
+| Kent Beck | TDD, XP | Test-Driven Development by Example (2002) |
+| Martin Fowler | Refactoring | Refactoring (2018) |
+
+<!-- CUSTOMIZE: ajoutez une ligne pour votre propre stack -->
+
+Si aucun auteur ne correspond vraiment, énoncer la règle simplement plutôt que de forcer une citation.
+
+---
+
+## 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
+
+**Ne PAS lire les messages de commit des nouveaux commits comme preuve.** Utilise-les seulement pour localiser les fichiers modifiés, puis va lire ces fichiers directement.
+
+---
+
+## É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** (seulement après avoir relu le code et confirmé la correction) :
+```json
+{
+  "actions": [
+    {
+      "type": "THREAD_RESOLVE",
+      "threadId": "PRRT_kwDONxxx",
+      "message": "Corrigé - Ajout du null check (vérifié dans src/services/myService.ts:320)"
+    }
+  ]
+}
+```
+
+**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 quels fichiers ont changé — un pointeur vers OÙ regarder, pas une preuve de CE QUI a changé
+
+```
+[PROGRESS:context:completed]
+```
+
+---
+
+### Phase 2 : Vérification (le code seul, jamais le message de commit)
+
+```
+[PHASE:agents-running]
+[PROGRESS:verify:started]
+```
+
+Pour CHAQUE thread du fichier de contexte :
+
+1. Ouvrir le fichier à la ligne enregistrée
+2. Lire le code actuel à cet emplacement exact
+3. Comparer au problème d'origine
+4. Ignorer tout ce que prétend le message de commit — le code est la seule preuve
+
+| Status | Critère |
+|--------|---------|
+| ✅ CORRIGÉ | Le code actuel à file:line traite manifestement le problème |
+| ⚠️ PARTIEL | Code modifié mais avec des réserves ou une approche différente de celle demandée |
+| ❌ NON CORRIGÉ | Le code à file:line est inchangé ou présente toujours le problème |
+
+```
+[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 ?
+
+Tout nouveau problème trouvé ici doit inclure une Leçon Pédagogique selon le format ci-dessus.
+
+```
+[PROGRESS:scan:completed]
+```
+
+---
+
+### Phase 4 : Gestion des Threads
+
+```
+[PROGRESS:threads:started]
+```
+
+#### Pour les problèmes CORRIGÉS (vérifiés dans le code, pas le message)
+
+É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 (vérifié à src/services/myService.ts:320)"
+}
+```
+
+**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) — y compris quand le message de commit prétend le contraire. Optionnellement utiliser un marqueur stdout pour répondre :
+```
+[THREAD_REPLY:THREAD_ID:❌ **Non corrigé** - [Explication courte de ce qui ne va toujours pas dans le code]]
+```
+
+#### 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, d'après le code]]
+```
+
+```
+[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 | Vérifié via |
+|---|----------|--------|--------------|
+| 1 | [Description] | ✅/⚠️/❌ | `fichier.ts:42` (code, pas le message de commit) |
+| 2 | [Description] | ✅/⚠️/❌ | `fichier.ts:88` |
+
+## Nouveaux Problèmes Détectés
+
+<!-- Si présents -->
+🚨 **[Titre du problème]**
+📍 `fichier.ts:42`
+
+**Leçon pédagogique** :
+> "[Citation de l'auteur]"
+> — [Auteur], [Ouvrage], [Année]
+
+**Explication** : [...]
+**Application pratique** : [...]
+
+<!-- Si aucun -->
+Aucun nouveau problème détecté.
+
+## Verdict
+
+| Critère | Status |
+|---------|--------|
+| Bloquants corrigés (vérifiés dans le code) | 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 **dans le code**
+- `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. **Relire le code réel** à chaque file:line des threads — jamais le message de commit
+3. **Écrire** les actions THREAD_RESOLVE seulement pour les problèmes confirmés corrigés dans le code
+4. **Citer** une source réelle pour tout nouveau problème trouvé
+5. **Écrire** l'action POST_COMMENT avec ton rapport
+6. **Écrire** l'action ADD_LABEL si prêt pour merge
+7. **É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 dans le code lu**
+- Un message de commit n'est jamais une preuve suffisante à lui seul — il peut mentir, se tromper, ou décrire autre chose
+- 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

package/templates/fr/review-advanced/README.md

@@ -0,0 +1,62 @@
+# review-advanced
+
+Un skill de code review rigoureux à audits séquentiels, avec bloc sécurité dédié et leçons pédagogiques sourcées obligatoires.
+
+## Vue d'ensemble
+
+Ce template fournit :
+- 8 audits séquentiels se terminant par un audit Naming **jamais compté** dans le score global
+- Un audit Sécurité dédié, scoré **et bloquant**
+- Chaque point soulevé doit citer un auteur réel et reconnu (citation + explication + application pratique) — aucune opinion non sourcée
+- Exécution séquentielle pour éviter les problèmes mémoire, même protocole que `review-with-agents`
+
+## Installation
+
+1. Copier ce dossier dans votre projet :
+   ```bash
+   cp -r templates/fr/review-advanced .claude/skills/ma-review
+   ```
+
+2. Renommer le skill dans le frontmatter de `SKILL.md`
+
+3. Remplir l'audit **Bonnes Pratiques Stack** (Audit 3) avec les règles idiomatiques de votre propre framework/langage — il est livré volontairement vide
+
+4. Remplir l'audit **Prévention Pareto des Bugs** (Audit 7) avec les catégories de défauts qui reviennent réellement dans votre codebase
+
+5. Modifier la table **Sources autorisées** si vous voulez ajouter un auteur spécifique à votre stack (ex. l'équipe doc officielle de votre framework)
+
+6. Configurer les agents dans `.claude/reviews/config.json` :
+   ```json
+   {
+     "reviewSkill": "ma-review",
+     "agents": [
+       { "name": "clean-architecture", "displayName": "Clean Architecture" },
+       { "name": "ddd", "displayName": "DDD" },
+       { "name": "stack-best-practices", "displayName": "Bonnes Pratiques Stack" },
+       { "name": "solid", "displayName": "SOLID" },
+       { "name": "testing", "displayName": "Testing" },
+       { "name": "code-quality", "displayName": "Code Quality" },
+       { "name": "pareto-bug-prevention", "displayName": "Prévention Pareto" },
+       { "name": "naming-audit", "displayName": "Naming" },
+       { "name": "security", "displayName": "Sécurité" }
+     ]
+   }
+   ```
+
+## Pourquoi le Naming est exclu du score
+
+Le feedback de nommage est jugé utile mais subjectif et non-bloquant. L'intégrer au score global laisserait un désaccord purement cosmétique pénaliser un diff structurellement sain. Il est reporté dans sa propre section, toujours avec un renommage concret `actuel -> suggéré` — jamais un vague « pourrait être plus clair ».
+
+## Pourquoi la Sécurité est bloquante
+
+Contrairement aux autres audits, une trouvaille Sécurité non résolue bloque le merge quel que soit le score global. Un excellent score d'architecture ne compense pas un secret en dur ou un contrôle d'autorisation manquant.
+
+## L'exigence de citation
+
+Chaque correction bloquante, avertissement ou suggestion doit inclure une **Leçon Pédagogique** : une citation réelle d'un auteur reconnu, une explication de son application, et une correction pratique. Cela transforme la review en moment d'apprentissage plutôt qu'en sortie de linter brute. Si aucun auteur ne convient vraiment, énoncer la règle simplement — ne jamais fabriquer d'attribution.
+
+## Voir Aussi
+
+- [review-with-agents](../review-with-agents/) — Template multi-agents plus léger, sans format de citation ni bloc sécurité dédié
+- [followup-advanced](../followup-advanced/) — Template de suivi correspondant, qui ne fait jamais confiance à un message de commit
+- [Review Skills Guide](../../../docs/guide/review-skills.md)