docs(harness,#15793): plancher de session pluriel -- >=2 grains dont >=1 DEEP de CONTENU

.claude/commands/continue.md

@@ -28,7 +28,7 @@ python scripts/pick_idle_grain.py --lane <machine:workspace> --prev-genre <genre
 
 **P0 — Reparer SON PROPRE rouge.** La commande rend en **sortie 0** un grain de reparation quand cette lane porte des PRs **bloquees et ouvertes depuis plus de 24 h** : la premiere devient `grain`, la liste complete reste dans `backlog`. **C'est la tache du cycle**, avant tout grain neuf. La raison est mecanique, pas disciplinaire : une PR rouge ne peut etre reparee **que par sa lane** — le coordinateur ne peut ni rebaser ni corriger a sa place — donc tant que la lane ne revient pas dessus, elle reste ouverte indefiniment pendant que les PRs du jour, elles, mergent. C'est exactement ce qui produit le residu de vieilles PRs.
 
-- Une PR reparee **et mergee compte comme le grain livre du cycle** (plancher R1 tenu) : ce n'est pas un a-cote, c'est du travail deja ecrit qu'on porte a son terme.
+- Une PR reparee **et mergee compte comme un grain du cycle** — jamais comme le plancher R1, qui exige un DEEP de CONTENU (un REPAIR est au mieux MED) : ce n'est pas un a-cote, c'est du travail deja ecrit qu'on porte a son terme.
 - Rouge **non reparable par cette lane** (garde casse sur main, dependance d'une autre PR) : l'**ecrire en commentaire sur la PR**, puis `--ignore-red`. L'echappatoire se justifie par ecrit, elle ne se prend pas en silence.
 - Seule preemption : une mission coordinateur **URGENT** (le coordinateur voit le plateau entier).
 

.claude/rules/coordinator-discipline.md

@@ -8,7 +8,7 @@ Detail complet (workflow batch merge + commandes + audit pre-merge + incidents +
 
 La production des lanes et la digestion (CI, reviews, merges) sont **deux pipelines paralleles**. Une saturation du second est un symptome a reparer ou a capaciter ; elle ne devient jamais une politique de ralentissement du premier.
 
-- Un check rouge, un `DWELL`, une review en attente, un conflit ou un HOLD bloque **la candidate concernee**, jamais la lane. La lane traite ce qu'elle peut reparer, puis poursuit aussitot un nouveau grain DEEP/MED de contenu pendant toute attente externe.
+- Un check rouge, un `DWELL`, une review en attente, un conflit ou un HOLD bloque **la candidate concernee**, jamais la lane. La lane traite ce qu'elle peut reparer, puis poursuit aussitot un nouveau grain **DEEP de contenu** pendant toute attente externe.
 - `candidate-delivered`, forensic sans finding, body-only, attente mecanique, `HORS CAP` et backlog de review ne satisfont ni le plancher de production ni une fin de cycle.
 - Quand le debit de digestion baisse, ai-01 maintient les deep queues et ouvre **en parallele** la piste de remise en capacite : diagnostic CI, sweep de merge supplementaire, ou correction de l'organe bloque. Il ne reduit pas les dispatchs pour rendre la queue confortable.
 - ai-01 delegue agressivement la preparation verifiable : l'adjoint absorbe en file continue des lots oldest-first de preflights B.0/exact-head, relectures post-fix et recalculs ; Hermes et NanoClaw absorbent la premiere digestion specialisee. Chaque lot inventorie toutes les reserves de chaque candidate et remonte chaque READY sans attendre la fin du lot. Ces avis preparent la decision sans remplacer la lecture B.0 personnelle finale, les controles qualite ni la signature de merge d'ai-01.

.claude/rules/proactive-coordination.md

@@ -1,12 +1,12 @@
-# Coordination proactive — 1 PR/wakeup plancher + pool global + never-idle
+# Coordination proactive — plusieurs grains/wakeup plancher + pool global + never-idle
 
 S'applique à **tous les workers du cluster CoursIA** (po-2023/2024/2025/2026) et au **coordinateur ai-01**. Source : mandat user 2026-05-23, durci 2026-06-30 → 2026-07-19.
 
 **Détail (backlog 8 sources, mapping machines→tracks, cadence, anti-patterns, incidents, leçons L721/L1356 complètes, picker, veine)** : [docs/reference/proactive-coordination-detail.md](../../docs/reference/proactive-coordination-detail.md).
 
 ## Règles HARD
 
-1. **≥1 PR entre 2 wakeups = PLANCHER, jamais plafond.** Une PR livrée ne **clôt pas** la session : re-pioche **immédiatement** et enchaîne autant de PRs que la fenêtre le permet (débit nominal ~2 PR/h). S'arrêter après 1 PR alors qu'il reste du temps **et** 60+ issues ouvertes = **sous-régime**, pas « cycle terminé ».
+1. **≥2 grains livrés entre 2 wakeups, dont ≥1 DEEP portant un genre de CONTENU = PLANCHER, jamais plafond.** Une PR livrée ne **clôt pas** la session : re-pioche **immédiatement** et enchaîne autant de PRs que la fenêtre le permet (débit nominal ~2 PR/h). S'arrêter après 1 PR alors qu'il reste du temps **et** 60+ issues ouvertes = **sous-régime**, pas « cycle terminé ». Le plancher est **pluriel et durci** (mandat user 2026-09-12) : un cycle dont le plat principal est MED ou META **n'a pas de plancher tenu**, même avec plusieurs PR livrées. La mesure qui motive ce durcissement — 15 % de DEEP sur 7 j, et sur 48 h le META passant devant le CONTENU — est déposée datée dans [détail, section Plancher durci](../../docs/reference/proactive-coordination-detail.md) ; le tier et le genre se tranchent en [variation-protocol.md](variation-protocol.md) (G-VAR-1).
 2. **2 tracks en flight minimum** : une **track principale** (dispatchée, Epic) + une **side-track autonome** que le worker avance **même si le coordinateur s'absente 1-2 jours**.
 3. **Side-tracks → sous-agents spécialistes async (HARD).** Quand un specialist `.claude/agents/` couvre la side-track, la déléguer en **`run_in_background: true`** pendant que le worker interactif tient la main track. Roster : [docs/reference/subagents-reference.md](../../docs/reference/subagents-reference.md).
 4. **Backlog pickup au wakeup vide (HARD).** Sans nouveau feedback / directive / tâche : **ne pas s'arrêter** — piocher dans le backlog et produire la PR du cycle.
@@ -25,9 +25,9 @@ Tirage pondéré dans **trois urnes** : **grain** (issue unitaire → la livrer)
 
 **Le picker ne décide pas.** Il propose ; l'agent tranche selon les critères de variété de sa lane et pose son `[CLAIMED]` (`check_lane_claim.py` avant d'**éditer**, cf [lane-claim-protocol.md](lane-claim-protocol.md)). Plutôt que rejouer aveuglément : demander davantage de candidats et passer les exclusions factuelles (`--exclude-issue`, labels, bornes age/inactivité, `--urns`) ; `--reroll` reste le dernier recours ; le cache ne touche jamais les organes minute-sensitive ([détail §Cache](../../docs/reference/proactive-coordination-detail.md)). **Aucun résultat vide filtré ne justifie un `[ASK coordinator]` ni un statut idle.**
 
-**Reparer son propre rouge, dans le meme cycle que la production (HARD, mandat user 2026-08-22 ; l'ordre retire le 2026-09-12).** Le picker rend la reparation (sortie **0** — le grain rendu *est* la reprise) tant que la lane porte une PR **bloquee et ouverte depuis plus de 24 h** ; il nomme la liste, la cause et le geste. Ce n'est **pas un prealable a produire** : au debut de chaque session, la lane inventorie **toutes** ses PRs portant nits, reserves, `CHANGES_REQUESTED` ou threads inline non resolus, puis traite sequentiellement **tous** les points reparables qui la concernent — jamais un seul nit ou une seule PR. Chaque remarque recoit une correction reelle si necessaire et une reponse ecrite qui la nomme ; les attentes externes (`CI`, `DWELL`, re-review, merge ou dependance) **sortent du champ de vision de la lane** — elles appartiennent a la candidate, qui attend seule, et une candidate n'attend jamais avec sa lane. La file reparable ne precede pas le tirage : la lane tire ses grains DEEP/MED de contenu dans le **meme** cycle, sequentiellement, tant que la fenetre reste ouverte.
+**Reparer son propre rouge, dans le meme cycle que la production (HARD, mandat user 2026-08-22 ; l'ordre retire le 2026-09-12).** Le picker rend la reparation (sortie **0** — le grain rendu *est* la reprise) tant que la lane porte une PR **bloquee et ouverte depuis plus de 24 h** ; il nomme la liste, la cause et le geste. Ce n'est **pas un prealable a produire** : au debut de chaque session, la lane inventorie **toutes** ses PRs portant nits, reserves, `CHANGES_REQUESTED` ou threads inline non resolus, puis traite sequentiellement **tous** les points reparables qui la concernent — jamais un seul nit ou une seule PR. Chaque remarque recoit une correction reelle si necessaire et une reponse ecrite qui la nomme ; les attentes externes (`CI`, `DWELL`, re-review, merge ou dependance) **sortent du champ de vision de la lane** — elles appartiennent a la candidate, qui attend seule, et une candidate n'attend jamais avec sa lane. La file reparable ne precede pas le tirage : la lane tire son grain DEEP de contenu dans le **meme** cycle, sequentiellement, tant que la fenetre reste ouverte.
 
-- **Une PR reparee et mergee tient le plancher R1** : ce n'est pas un a-cote, c'est du travail deja ecrit porte a son terme. Une PR seulement corrigee mais encore en attente externe ne le tient pas encore ; la lane continue donc a produire. Elle garde son tag `Grain:` d'origine — la reparation ne re-qualifie pas le tier.
+- **Une PR reparee et mergee compte dans le plancher R1** : ce n'est pas un a-cote, c'est du travail deja ecrit porte a son terme. Elle ne le tient pas **seule** — le plancher exige ≥1 DEEP de CONTENU, et un REPAIR est au mieux MED ([variation-protocol.md](variation-protocol.md), §Grain REPAIR) : il compte comme grain, jamais comme plancher. Une PR seulement corrigee mais encore en attente externe ne compte pas encore ; la lane continue donc a produire. Elle garde son tag `Grain:` d'origine — la reparation ne re-qualifie pas le tier.
 - **Ce qui compte comme a reprendre en premiere action** est ce qui **empeche vraiment le merge**, en **quatre** causes : un check **requis** en echec (champ GraphQL `isRequired`, pas un motif de nom), un conflit avec `main`, un `CHANGES_REQUESTED` non leve, et — **en tete des trois autres** — un **point de review non leve**. Il est propose a chaque cycle et n'interdit jamais le grain suivant. Un advisory rouge n'est **pas** un rouge ; `mergeStateStatus: BLOCKED` vaut aussi « en attente de review », que la lane ne peut pas lever — une telle PR n'est donc **pas** un grain de reparation, et sort du champ de la lane jusqu'a ce qu'un geste de lane redevienne possible.
 - **Les points de review passent en premier** car ils sont structurellement aveugles aux trois surfaces de [§B.0](../../CLAUDE.md) (nits du user en issue comments, réserves d'Hermes en préfixe de body, threads inline) : une PR peut être verte, sans conflit, sans `CHANGES_REQUESTED` — et rester non mergeable. Le picker délègue la détection à `check_unaddressed_nits.analyse`, **le même organe que le merge-gate** — s'ils divergeaient, une lane serait autorisée à produire du neuf sur une PR que le merge-gate refusera. La cause est listée d'abord parce que ce qui lève une remarque est **une phrase, pas un SHA**.
 - **Organe injoignable ≠ ardoise propre** : quand la lecture des points échoue, le picker tire quand même mais le **dit** — vérifier à la main (`python scripts/check_unaddressed_nits.py <N>`) avant de produire.
@@ -46,7 +46,7 @@ Tirage pondéré dans **trois urnes** : **grain** (issue unitaire → la livrer)
    **Trois évasions mortes** (labels bannis : [détail, section Vocabulaire](../../docs/reference/proactive-coordination-detail.md)) :
    - **« Pas ma famille »** — FAUX : famille = préférence de **reporting**, pas frontière. **Seules deux vraies barrières** : (a) **GPU-only** ; (b) **vision-only** (→ lanes MiniMax/ai-01). Le reste est piochable partout.
    - **« Tout ce qui reste est gated »** — un *gate* qualifie une **prochaine action**, pas une issue entière : énumérer chaque issue ouverte + son gate précis ; si UNE a un sous-grain exécutable (doc, notebook CPU, audit, test), **le prendre**.
-   - **« Les micro-fixes suffisent »** — non : nettoyage/tooling/doc plafonnés, jamais le plat principal ; viser **DEEP/MED** chaque cycle (tiers : [variation-protocol.md](variation-protocol.md)).
+   - **« Les micro-fixes suffisent »** — non : nettoyage/tooling/doc plafonnés, jamais le plat principal ; le plancher exige un **DEEP de CONTENU** chaque cycle, le MED et le META venant au-delà (tiers et genres : [variation-protocol.md](variation-protocol.md)).
 
    **Mécanisme never-empty (ordre strict, inversé le 2026-08-20).** (1) **Tirer** — `pick_idle_grain.py`, au démarrage du cycle, systématiquement. (2) Un **steering nommé** du coordinateur (deep-queue, DM `[DISPATCH→inbox]`) **s'ajoute** au tirage quand il est déjà là : le brûler dans l'ordre, ne pas attendre entre items, `[CLAIMED]` avant chaque. Son absence ne se constate pas. (3) Ni tirage exploitable ni steering → le pool global reste la source : « rien à faire » demeure **structurellement impossible** tant que `gh issue list` renvoie >0. La deep-queue est un **bootstrap éphémère**, jamais la condition du travail.