fix(harness): /coordinate dispatche avant de merger, et merge par la queue

.claude/skills/coordinate/SKILL.md

@@ -31,35 +31,41 @@ Cycle de coordination du cluster CoursIA. **Reserve au coordinateur ai-01** : un
 3. **GitHub** : `gh pr list --state open` (a merger) + le pool **tire, jamais scanne** — `python scripts/pick_idle_grain.py --lane myia-ai-01:CoursIA` (un `gh issue list` nu plafonne a 30, tries par recence : il ne montre que ce que je viens de creer, et c'est ce biais que le steering doit eviter de reproduire).
 4. **Cron** : `CronList` — si le job coordinateur a disparu (session-only), re-armer `CronCreate("13 0-23/2 * * *", "/coordinate", recurring)`. Cadence unique, PAS de 2e cron ni ScheduleWakeup en plus.
 
-### Phase 3 - Production et digestion en parallèle
+### Phase 3 - Dispatchs, relances, memoire (LES 30 PREMIERES MINUTES)
 
-**Production avant digestion (HARD)** : lancer ou maintenir les deep queues productives avant d'attendre la fin de la passe de merge. CI, review, `DWELL`, HOLD ou backlog bloquent une candidate, jamais une lane. Chaque worker draine a chaque session **tous** les nits et reserves reparables de **toutes** ses PRs, sequentiellement, puis enchaine plusieurs grains dont **au moins un DEEP de contenu** (plancher durci #15793) ; traiter un seul nit ou livrer une seule PR ne clot pas la session. La saturation de digestion déclenche une piste de réparation/capacité parallèle ; elle ne réduit jamais les dispatchs.
+**Cette phase precede la passe de merge et se ferme avant elle.** L'ordre inverse -- merger d'abord, dispatcher avec ce qui reste -- ne termine jamais : le pool de PRs est non borne et chaque PR ouvre trois surfaces a lire, donc les lanes sont affamees **par construction du cycle**, pas par negligence. Le symptome mesure : un cycle de plus de 4 h pour une cadence de 4 h, passe a rejouer le travail deja fait par l'adjoint et les bots (correction user 2026-09-14).
 
-Sweep batché, dossiers préparés en parallèle, décision séquentielle au coordinateur — pas de re-audit intégral PR par PR. Déléguer agressivement la préparation vérifiable : adjoint pour preflight B.0/exact-head, Hermes et NanoClaw pour la première digestion spécialisée ; ai-01 garde la lecture B.0 personnelle finale, le verdict et le merge.
+1. **Sweep unique, trie par anciennete** -- il sert LES DEUX phases, on ne le capture qu'une fois : `gh pr list --state open --limit 200 --json number,title,author,createdAt,mergeStateStatus,reviewDecision,headRefOid --jq 'sort_by(.createdAt) | .[] | [.createdAt[0:10],.number,.mergeStateStatus,.reviewDecision,.title] | @tsv'`. Sans `--limit`, gh plafonne a 30, et sans tri declare il rend par recence. **Pas de champ `reviews`** (payload lourd -- 504). 200 lignes rendues = plafond touche, paginer plutot que croire la liste complete.
+2. **Grouper LA QUEUE par lane, et dispatcher le deblocage.** Les ~20 PRs les plus vieilles, regroupees par leur tag `Grain: ... lane`, partent en mandat de deblocage a leur lane. Une PR est vieille **parce qu'**elle est bloquee : ce qui se dispatche est le deblocage, pas le merge qui s'attend. Le lot d'une lane se derive du sweep seul -- aucun re-audit prealable n'est requis pour l'envoyer.
+3. **Relancer les nits bloquants, nommement.** Chaque reserve non levee (`[Hermes] COMMENT_WITH_CONCERNS`, `CHANGES_REQUESTED`, nit user, thread inline non resolu) est renvoyee a la lane de l'auteur de la PR **avec le point cite**. Une reserve qu'on ne relance pas devient un grain qu'aucune lane ne sait qu'elle doit executer -- et celles posees par ai-01 ne peuvent etre levees par personne d'autre.
+4. **Le rouge sans lane est a MOI.** Le garde "reparer son rouge d'abord" ([proactive-coordination](../../rules/proactive-coordination.md) R5) renvoie chaque lane sur ses propres PRs bloquees -- mais une PR **sans tag `Grain:` lisible** n'est imputable a aucune lane et reste invisible a tous les gardes. Lire le commentaire marker-guarde `GRAIN-ORPHANS-SWEEP` sur #13086 (rafraichi via `python scripts/pick_idle_grain.py --orphans-report`) et traiter chaque orpheline nommee avec son auteur : reparer, dispatcher nommement, ou fermer en le disant. Le coordinateur est soumis au meme garde pour **sa propre** lane.
+5. **Trancher les design-gates en attente** dans le cycle -- ne pas deferer une option deja investiguee. Regles : [coordinator-discipline.md](../../rules/coordinator-discipline.md) (R3 lanes independantes, R4 jamais sanctionner l'idle, R5 steer qui ATTEINT/VRAI/DECIDE).
+6. **Grounder chaque grain firsthand** (`gh issue view N` / `gh pr view N`) AVANT de dispatcher -- jamais depuis un status condense.
+7. **Double canal obligatoire** : DM `roosync_messages(action:"send", to:"<machine>:<workspace>", ...)` (le worker lit l'inbox en premier, le DM survit a la condensation) **+** pointeur `[DISPATCH->inbox]` sur le dashboard de la lane (sonnette persistante).
+8. **Une lane sans grain = echec coordinateur** : deep-queue, fallback perenne par famille, ou pool global -- jamais un statut terminal-idle. Chaque worker draine **tous** ses nits et reserves reparables sur **toutes** ses PRs, puis enchaine plusieurs grains DEEP/MED ; une seule PR livree ne clot pas sa session.
+9. **MAJ memoire maintenant, pas en fin de cycle** : `coordinator-durable-state.md` si l'etat durable a bouge. Repoussee a la fin, elle saute quand le cycle deborde -- et le cycle suivant re-derive ce qu'il savait deja.
 
-1. **Sweep leger batche** : `gh pr list --state open --limit 200 --json number,title,author,createdAt,mergeStateStatus,reviewDecision,headRefOid --jq 'sort_by(.createdAt) | .[] | [.createdAt[0:10],.number,.mergeStateStatus,.reviewDecision,.title] | @tsv'` — un seul appel, tri explicite par anciennete (sans `--limit`, gh plafonne a 30 et sans tri declare). Le sweep ordonne et qualifie, il ne decide pas : `mergeStateStatus` / `reviewDecision` restent aveugles aux trois surfaces B.0. **Pas de champ `reviews` dans le sweep** (payload lourd — 504) : les corps detailles (reviews, comments, bodies) se lisent par PR dans les lots de decision (etape 4). Si le rendu atteint 200 lignes, le plafond est touche — paginer plutot que croire la liste complete.
-2. **Corps de review Hermes/NanoClaw lus PAR DEFAUT — leur verification est deja faite** : verdicts `[Hermes] COMMENT_WITH_CONCERNS` (prefixe de `reviews[].body`) et `EXEC_PROVED` / `STRUCTURAL_ONLY` / `SUSPECT_REGRESSION` (body). Les exploiter au lieu de rejouer l'audit : le coordinateur ne verifie que (a) le **delta** depuis la derniere review — commits pousses apres, qui ne leve rien par eux-memes (B.0 : une phrase leve, pas un SHA) ; (b) les **reserves non levees** — CONCERNS, `CHANGES_REQUESTED` (le sien non plus ne s'auto-leve pas, #8821), nits user, threads inline non resolus ; (c) la **preuve decisive** du claim central — pas de repetition des tests/audits deja etayes ; la lecture du diff reste requise avant signature. Tout finding NanoClaw suit le protocole [audit-reassessment.md](../../rules/audit-reassessment.md) avant fix (FP connus).
-3. **Consommer AVANT de fabriquer (HARD)** : **aucun sous-agent n'est lance sur une PR qui figure dans la liste de pre-machage extraite en Phase 2.2** — son dossier existe deja ; le refaire est une depense pure, et il laisse sans reponse la lane qui l'a produit. Un dossier d'adjoint se **lit et se tranche**, il ne se re-derive pas ; ce qu'il faut y verifier est le **delta** depuis sa redaction, pas son contenu. Le defaut que cette ligne ferme : six preflights d'adjoint restes non lus pendant que le coordinateur rejouait a la main la verification qu'ils portaient. Pour le RESTE seulement — **dossiers en parallele, decision au coordinateur** : les PRs proches de decision partent en preparation `run_in_background: true` chez des sous-agents varies — modele explicite obligatoire, haiku pour le mecanique (comptages, extraction, verification de champs), sonnet pour l'interpretation bornee, cf [model-delegation.md](../../rules/model-delegation.md) — pendant que le coordinateur lit et tranche les dossiers murs. **Le lot de chaque sous-agent est une liste explicite de numeros de PR extraite de la capture unique du sweep (etape 1)** — jamais d'enumeration du pool par le sous-agent lui-meme : des partitions recalculees par agent se recouvrent et dupliquent le travail. Dossier attendu : preuves citees (file:line, log, SHA), verdict par critere [pr-review-discipline](../../rules/pr-review-discipline.md), questions ouvertes. Un dossier insuffisant repart avec UNE question precise et la preuve de sortie attendue — jamais un re-audit integral par reflexe. Un dossier pret remonte immediatement, sans attendre les autres.
-4. **Lecture B.0 personnelle avant chaque merge — non delegable** : body + comments + reviews + diff (regle HARD "Read Body Before Any Action", `~/.claude/CLAUDE.md` global) ; etat A L'INSTANT-T via `gh pr view N --json state,mergedAt,mergeStateStatus,reviews` (jamais depuis le dashboard ni le cycle N-1 — lecon phantom-steer #5563) ; organe `python scripts/check_unaddressed_nits.py <PR>` (exit 1 = ne pas merger — son vert ne dispense pas de la lecture). Une levee porte un auteur et une heure.
-5. Gates : H.4 (notebooks : checkout + Papermill local OU log dans le body), catalogue byte-identique a main (`gh pr view N --json files` — lecon stale-catalog), scope reel = titre.
-6. Merge : directement sous `myia-ai-01` (a le droit `MergePullRequest`, verifie firsthand 2026-08-08 ; `gh auth switch -u jsboige` reserve a la lecture/ecriture de la protection de branche, cf [coordinator-discipline.md](../../rules/coordinator-discipline.md) Regle 1), `--squash` par defaut, `--merge` (preserve-SHA) pour la base d'un stack, **JAMAIS `--delete-branch`**.
-7. **Le rouge sans lane est a MOI.** Le garde "reparer son rouge d'abord" ([proactive-coordination](../../rules/proactive-coordination.md) R5) renvoie chaque lane sur ses propres PRs bloquees — mais une PR **sans tag `Grain:` lisible** n'est imputable a aucune lane et reste donc invisible a tous les gardes. Personne ne viendra les reprendre : lire le commentaire marker-guarde `GRAIN-ORPHANS-SWEEP` sur #13086 (balayage quotidien, rafraichi a la demande via `python scripts/pick_idle_grain.py --orphans-report`) et traiter chaque orpheline nommee avec son auteur — reparer, dispatcher nommement, ou fermer en le disant. Le coordinateur est soumis au meme garde pour **sa propre** lane : son tirage lui assigne la reparation de ses propres PRs -- sortie 0, grain rendu -- tant que ses PRs rouges trainent.
+**Budget** : ces neuf points sont **clos avant** d'ouvrir la Phase 4. S'ils ne le sont pas a la fin des 30 minutes, ce sont eux qu'on termine -- pas le merge qu'on commence.
 
-### Phase 4 - Steers et design-gates
+### Phase 4 - Merge PAR LA QUEUE, sur dossiers premaches
 
-Regles completes : [coordinator-discipline.md](../../rules/coordinator-discipline.md) (R3 lanes independantes, R4 jamais sanctionner l'idle, R5 steer qui ATTEINT/VRAI/DECIDE).
+**Ordre unique : du plus ancien au plus recent.** Selectionner les PRs CLEAN / vertes / `rc=0` selectionne les PRs **neuves par construction** : une PR est verte parce qu'elle est recente, et vieille parce qu'elle est bloquee. Merger la tete **degrade en plus la queue** -- un merge rend DIRTY les PRs ouvertes qui touchent les memes fichiers (mesure : le merge de #15627 a sali #15799 et #15915). Mandat user 2026-09-14 : merger en batch par la queue, en mandatant le deblocage aux workers.
 
-1. **Trancher les design-gates en attente** dans le cycle — ne pas deferer une option deja investiguee.
-2. **Grounder chaque grain firsthand** (`gh issue view N` / `gh pr view N`) AVANT de dispatcher — jamais depuis un status condense.
-3. **Double canal obligatoire** : DM `roosync_messages(action:"send", to:"<machine>:<workspace>", subject:"...", body:"...", priority:"HIGH|MEDIUM")` (le worker lit l'inbox en premier, le DM survit a la condensation) **+** pointeur `[DISPATCH→inbox]` sur le dashboard de la lane (sonnette persistante).
-4. Une lane sans grain = echec coordinateur : deep-queue, fallback perenne par famille, ou pool global — jamais un statut terminal-idle.
+**Ce que le coordinateur NE refait PAS.** L'audit d'Hermes, de NanoClaw et de l'adjoint **est deja fait** : il se lit, il ne se rejoue pas. Ne sont verifies que (a) le **delta** depuis la derniere review -- les commits pousses apres, qui ne levent rien par eux-memes (B.0 : une phrase leve, pas un SHA) ; (b) les **reserves non levees** ; (c) la **preuve decisive** du claim central. Dix allers-retours sur une PR ne coutent rien tant qu'on ne les reverifie pas dix fois.
+
+1. **Exploiter les verdicts deja poses** : `[Hermes] COMMENT_WITH_CONCERNS` (prefixe de `reviews[].body`), `EXEC_PROVED` / `STRUCTURAL_ONLY` / `SUSPECT_REGRESSION` (body). Tout finding NanoClaw suit [audit-reassessment.md](../../rules/audit-reassessment.md) avant fix (~60 % de FP).
+2. **Dossiers en parallele, decision sequentielle au coordinateur** : les PRs proches de decision partent en preparation `run_in_background: true` -- modele explicite obligatoire, haiku pour le mecanique, sonnet pour l'interpretation bornee ([model-delegation.md](../../rules/model-delegation.md)). **Le lot de chaque sous-agent est une liste explicite de numeros extraite du sweep de la Phase 3** -- jamais d'enumeration du pool par le sous-agent (des partitions recalculees se recouvrent). Dossier attendu : preuves citees (file:line, log, SHA), verdict par critere, questions ouvertes. Un dossier insuffisant repart avec UNE question precise -- jamais un re-audit integral par reflexe.
+3. **Lecture B.0 personnelle avant chaque merge -- non delegable** : body + comments + reviews + diff ("Read Body Before Any Action") ; etat A L'INSTANT-T via `gh pr view N --json state,mergedAt,mergeStateStatus,reviews` (jamais depuis le dashboard ni le cycle N-1) ; organe `python scripts/check_unaddressed_nits.py <PR>` (exit 1 = ne pas merger ; son vert ne dispense pas de la lecture). Une levee porte un auteur et une heure.
+4. **Gates** : H.4 (notebooks : checkout + Papermill local OU log dans le body), catalogue byte-identique a main (`gh pr view N --json files`), scope reel = titre.
+5. **Merge** : sous `myia-ai-01` (droit `MergePullRequest` verifie firsthand 2026-08-08), `--squash` par defaut, `--merge` (preserve-SHA) pour la base d'un stack, **JAMAIS `--delete-branch`**.
 
 ### Phase 5 - Fin de cycle (obligatoire)
 
 1. **Commit + PR AVANT le rapport** — ne jamais annoncer un travail non commite.
 2. `[DONE]` lane-specific sur **les deux** dashboards (jamais un miroir copie-colle).
 3. **Bloqueurs user** : re-poke explicite dans vscode a CHAQUE fin de session tant que l'action user n'est pas faite ([user-blocker-signaling](../../rules/user-blocker-signaling.md)).
 4. MAJ `coordinator-durable-state.md` si l'etat durable a change (PR#/SHA ephemeres → dashboard, pas la memoire).
+5. **Une seule investigation par cycle, et en fin de session.** Toute question ouverte qui n'est **pas** un bloqueur de merge se note et attend le cycle suivant : mesurer un organe, verifier une provenance, instruire un doute de securite sont des gestes utiles et couteux, qui n'ont leur place qu'apres les dispatchs, les relances et la passe de merge. Une investigation qui deborde sur le cycle suivant est une investigation de trop -- elle a mange le temps des lanes. Si l'objet est reellement urgent, il devient un **grain dispatche**, pas une enquete du coordinateur.
 
 ## Regles importantes