L'accroche

QW-01 disait : ton fichier d'état ment. QW-02 disait : ton compteur ment. Voici la troisième couche : ton sub-agent ignore ce que toi tu sais. Pas par malice, par construction. Le contexte qu'il reçoit, c'est ton brief, point. Pas ton MEMORY.md, pas tes feedbacks user-scope, pas la doctrine que tu as accumulée en 70 jours. Tu lui parles comme à un collègue qui a relu le wiki, alors qu'il vient d'arriver et n'a jamais ouvert la page.

Ce qui a cassé

18 mai, fin d'après-midi. Je délègue six fichiers à mon sub-agent ERP — autosend premier contact, ADR-0072. Brief en trois paragraphes : contexte, livrables, phase 0 grep d'audit avant tout INSERT. Court, propre, ce que je donnerais à un humain qui connaît le projet.

Quarante-cinq minutes plus tard, le rapport arrive. Je grep mon git log par réflexe : commit 3756e63 parti sur main, six fichiers, sept cent trente insertions, sans branche feature, sans pull request. Trente minutes de cherry-pick pour rattraper. Et la règle qui aurait dû empêcher ça — feedback_git_branch_check_avant_commit — était bien dans ~/.claude/agent-memory/, scope user, indexée dans mon MEMORY.md. Je la consulte mécaniquement avant chaque commit non-trivial depuis l'incident du 14 mai. Elle ne m'a pas trahi. Elle n'a juste jamais atteint le délégué.

La leçon est plus inconfortable que les deux premières cartes. Tu peux construire la doctrine la plus rigoureuse du monde, l'indexer, la versionner, la backporter entre projets — si le brief que tu envoies au sub-agent ne la cite pas explicitement, elle est effectivement absente. La mémoire user-scope ne se transmet pas par filiation. Le sub-agent n'est pas un héritier, c'est un sous-traitant qui n'a pas lu ton wiki.

Une objection légitime ici : la protection de branche côté repo GitHub aurait aussi attrapé le commit sur main. C'est vrai pour cet exemple-là. Mais la doctrine doit tenir même dans les repos où tu n'as pas câblé la protection, et surtout, les deux autres feedbacks de l'exemple ci-dessous (probe DB avant DELETE, audit inscriptions.source) n'ont pas d'équivalent en garde-fou serveur. C'est précisément la catégorie qu'il faut couvrir par le brief, parce qu'aucune autre couche ne le fera.

L'en-tête de brief qui ferme la classe

À coller en tête de tout brief sub-agent qui touche du code applicatif, dure plus de trente minutes, ou délègue une décision qui pourrait casser une règle silencieuse. Trois à cinq feedbacks load-bearing (dans le vocabulaire Counterpart, un feedback = une règle codifiée à partir d'un incident passé, stockée dans MEMORY.md, nommée par un slug stable).

# Brief sub-agent — <task name>

## Load-bearing feedbacks (apply BEFORE any code)
- `feedback_git_branch_check_avant_commit` — `git branch --show-current`
  before every non-trivial commit; feature branch + PR for any new feature.
- `feedback_audit_db_pre_flight_canonique` — `SELECT … GROUP BY` probe
  before any bulk DELETE/UPDATE.
- `feedback_source_audit_inscriptions` — never touch `inscriptions.source`
  rows where source ∉ {NULL, 'migration_notes'}.

## Context
<the brief itself>

Trois feedbacks nommés en tête de brief. Pas le contenu — juste le slug + une phrase opérante. Si le sub-agent veut le détail, il ouvre le fichier. Mais l'invocation explicite suffit à ramener la règle dans son contexte actif. Une règle citée par son nom est une règle considérée. Une règle qui vit dans ton MEMORY.md et nulle part ailleurs est une règle qui n'existe pas pour ton délégué.

ROI

Pas du temps économisé sur la délégation elle-même — le brief grandit de quelques lignes, c'est neutre. Le gain est en aval. Trente minutes de cherry-pick évitées par commit-sur-main raté. Une demi-journée d'audit DB évitée par bulk-DELETE-sans-probe évité. Une catégorie entière de fail-modes silencieux qui sort du périmètre d'incident parce qu'elle est nommée dans le brief avant que le code soit écrit. L'en-tête ne remplace pas la doctrine — il la rend opérante pour le délégué qui n'y a pas accès en lecture directe.

À appliquer maintenant

Ouvre le prochain brief que tu vas envoyer à un sub-agent. En tête du fichier, avant le contexte, colle le bloc ## Load-bearing feedbacks avec trois feedbacks pertinents pour la tâche. Le choix des trois est l'exercice — c'est lui qui rend visible quelle partie de ta mémoire est load-bearing pour cette délégation précise. Si tu ne sais pas lesquels citer, c'est probablement que le brief est trop vague pour être délégué. Auquel cas le bénéfice du pattern arrive avant même que le sub-agent commence à travailler : il t'a fait re-clarifier ton intention.

Ton quick win tient en cinq minutes — celles qu'il faut pour identifier les trois feedbacks à inliner. La doctrine ne te suit pas dans la délégation toute seule. Tu dois la porter.

Quick Win Card series, épisode 03. Counterpart Toolkit v0.7, amendement R9 promu 20/05/2026. Repo doctrine : github.com/michelfaure/doctrine-counterpart. Triptyque QW-01 → QW-02 → QW-03 : fichier ment, compteur ment, contexte du délégué ment. Trois couches d'observabilité qui mentent par défaut, trois hooks qui les forcent à parler.