_Assistant_Lead_Tech/knowledge/workflow/patterns/general.md

title: Workflow — Patterns : Général domain: workflow bucket: patterns tags: [review, adversarial, git, chantier, agent] applies_to: [analysis, implementation, review] severity: high validated_on: 2026-04-27 source_projects: [RL799_V2]

Workflow — Patterns : Général

Extrait de la base de connaissance Lead_tech. Voir knowledge/workflow/patterns/README.md pour l'index complet.

---

Pattern : Review adversarial obligatoire sur chemin critique

• Objectif : détecter avant commit les race conditions, assertions trop molles et dépendances cachées qui ne sont pas visibles à la lecture du spec mais le sont à la lecture du code écrit.
• Contexte : chantier qui touche un chemin critique (atomicité, audit, sécurité, intégrité financière, lifecycle d'entité métier) — même petit (< 100 lignes).
• Quand l'utiliser : systématique sur les chemins critiques, indépendamment de la taille du chantier.
• Quand l'éviter : refactor cosmétique, polish UX, documentation, tests d'un chemin déjà couvert.
• Avantage :
  • capture les défauts post-spec (l'intention est cadrée, l'implémentation peut diverger)
  • moins coûteuse à corriger avant commit qu'en post-prod (incident, debug, rollback)
• Limites / vigilance :
  • pas un substitut à la code review classique (posture différente : "qu'est-ce qui casse" vs "est-ce conforme au spec")
  • pas un substitut aux tests qui passent (les tests valident ce qu'on a pensé tester)
• Validé le : 27-04-2026
• Contexte technique : workflow agent / BMAD — RL799_V2

Identifier un chemin critique

Au moins une des conditions :

• mutation atomique d'une entité métier (close, cancel, lock, archive)
• émission d'audit log (la traçabilité est non-négociable)
• émission de notification (mauvais target = bug visible utilisateur)
• logique d'autorisation, RBAC, gates de permission
• calculs financiers (paiements, soldes, totaux)
• intégrité référentielle (FK, soft-delete)
• concurrence : plusieurs process peuvent toucher la même entité

Format de review efficace

Posture : œil fâché, on cherche à casser ce qu'on vient de livrer.

Pour chaque finding :

• Sévérité : HIGH / MEDIUM / LOW / NIT
• Localisation : file:line
• Problème : ce qui peut casser, dans quel scénario
• Mitigation possible : 1-3 options
• Verdict : fix dans le scope, dette explicite, ignorer

Sortie : tableau synthétique. Si > 0 HIGH ou > 2 MEDIUM, on fixe avant commit.

Anti-règle

• Confondre review adversarial et code review classique
• Confondre "tests verts" et "implémentation correcte"
• Lire son propre code en attendant de le valider (biais cognitif fort)

---

Pattern : Isolation chirurgicale d'un hunk via git apply --cached <patch>

• Objectif : commiter uniquement les hunks d'un chantier A dans un fichier également modifié par un chantier B, sans interaction git add -p.
• Contexte : plusieurs chantiers parallèles touchent le même fichier central (catalog audit, schema partagé, fichier d'enums).
• Quand l'utiliser : agent IA en environnement non-interactif qui prépare un commit avec sélection de hunks.
• Quand l'éviter : si on commit la totalité du fichier (git add <file> direct suffit), ou si les hunks sont logiquement indissociables.
• Avantage :
  • non-interactif, scriptable
  • le worktree garde tous les changements (mes hunks A commités + hunks B unstaged pour le chantier B)
• Limites / vigilance :
  • en interactif humain, git add -p reste plus rapide
  • le patch filtré doit rester valide (en-têtes diff --git, index, @@ cohérents)
• Validé le : 27-04-2026
• Contexte technique : git / chantiers parallèles — RL799_V2

Recette

# 1. Capturer le diff du fichier mixte
git diff <file> > /tmp/mixed.patch

# 2. Éditer le patch pour ne garder que les hunks à commiter
#    (un agent peut le faire via Read + Write — c'est un fichier texte)

# 3. Appliquer le patch filtré uniquement à l'index (pas au worktree)
git apply --cached /tmp/mine_only.patch

# 4. Vérifier le staged
git diff --cached <file>

# 5. Commit
git commit ...

# 6. Le worktree garde TOUS les changements
git diff <file>  # affiche les hunks de l'autre chantier

Format minimal d'un hunk

diff --git a/<file> b/<file>
index <hash_old>..<hash_new> 100644
--- a/<file>
+++ b/<file>
@@ -<line>,<count> +<line>,<count> @@ <context>
 <ligne contexte avant>
+<ligne ajoutée>
 <ligne contexte après>

Les index et @@ viennent du git diff original — pas besoin de recalculer les hashes.

---

Pattern : Trianguler par grep les localisations rapportées par un sub-agent

• Objectif : ne jamais agir directement sur les localisations précises rapportées par un sub-agent d'analyse — toujours vérifier avant de patcher.
• Contexte : workflow multi-agent où un sub-agent (Explore, audit BMAD, lecture de code) retourne un rapport avec findings.
• Quand l'utiliser : à la réception de tout rapport de sub-agent qui cite des fichiers, lignes, ou snippets.
• Quand l'éviter : pour les comptages globaux et tendances — fiables même sans triangulation.
• Avantage :
  • évite de "corriger" du code déjà correct (pollution de commit, perte de confiance)
  • distingue les findings actionables des extrapolations
• Limites / vigilance :
  • ajoute ~15-20 % de temps à la phase d'action — largement compensé par les commits évités
• Validé le : 24-04-2026
• Contexte technique : workflow multi-agent / BMAD — RL799_V2

Règle

Ne jamais agir sur les localisations précises d'un sub-agent sans vérification.

• Sub-agent dit "fichier X ligne Y a pattern Z" → grep Z fichier X doit confirmer
• Sub-agent dit "fichiers A, B, C, D ont pattern Z" → grep chaque fichier
• Si un finding s'effondre à la vérif, relire critiquement les autres findings du même sub-agent

Ce qui reste fiable chez un sub-agent

• Comptages globaux (X fichiers sur Y ont le pattern Z — l'ordre de grandeur est généralement juste)
• Tendances (ex: "le projet a un problème de cleanup" — juste, même si les fichiers cités sont faux)
• Patterns de risque identifiés (vi.stubEnv sans restauration est un vrai pattern à risque)

Ce qui est peu fiable

• Numéros de ligne précis (peuvent être hallucinés)
• Listes de fichiers exhaustives pour un pattern rare
• Snippets de code cités (peuvent être reconstruits de mémoire plutôt que lus)

Communication au user

"Sub-agent X signale 4 fichiers, j'ai validé 1/4 et invalidé 3/4. Voici le plan d'action corrigé."