Skip to content

docs(#15684): retirer les deux tableaux d'assignation lane->Epic (4/4 lanes CoursIA-2 hors specialite, 5/7 tracks CLOSED) - #15685

Merged
myia-ai-01 merged 1 commit into
mainfrom
docs/15684-retrait-assignations-lane
Sep 14, 2026
Merged

myia-ai-01 merged 1 commit into
mainfrom
docs/15684-retrait-assignations-lane

Conversation

@myia-ai-01

Copy link
Copy Markdown
Collaborator

Grain: LIGHT/docs — lane myia-ai-01:CoursIA — prev: MED/tooling #15683

Closes #15684

Ce que la mesure dit, et ce qu'elle corrige dans mon propre diagnostic

Le mandat user soupconnait les lanes CoursIA-2 d'etre confinees a un petit pool calibre par ces tableaux. Mesure du 2026-09-12 sur les 150 derniers merges : elles ne sont pas confinees, elles ignorent ces tableaux.

Lane Specialite assignee par cluster-agents.md Livre reellement
po-2024:CoursIA-2 MetaGeneticSharp / metaheuristiques .NET (#1203) 4 PRs (slides, notebook-python…) ; #1203 cite au plus une fois sur 150 bodies
po-2025:CoursIA-2 .NET / Argumentum (#2137 CLOSED 2026-07-02) 1 PR, guard (lane de l'adjoint)
po-2026:CoursIA-2 Grothendieck (#2159) 6 PRs (docs, guard, notebook-python, refactor, test) ; #2159 au plus une fois
po-2027:CoursIA-2 Generaliste — #11698, #11168 0 PR

Et la ligne 110 affirmait :

po-2023 (hote GenAI) et ai-01 (coord) n'ont qu'une lane CoursIA.

Faux, et c'est l'erreur la plus couteuse du fichier : myia-po-2023:CoursIA-2 a livre 28 des 39 PRs CoursIA-2 de l'echantillon. Le tableau pretendait repartir le travail CoursIA-2 et niait l'existence de la lane qui en produit 72 %.

Le mapping de proactive-coordination-detail.md avait la meme maladie, en pire : 5 de ses 7 assignations numerotees pointaient une issue CLOSED (#1409, #1273, #1385, #1455, #999 — fermees entre mai et juillet). Trois des quatre lignes worker avaient une track principale fermee ; po-2023 et po-2025 avaient les deux colonnes fermees. Un steer vers une issue CLOSED est un phantom au sens de R5 de coordinator-discipline.md : le worker brule son cycle a le refuter. Ce tableau en fabriquait cinq en permanence, depuis un fichier auto-reference par le harnais. Le « (cycle courant) » de son titre etait l'aveu : un fichier versionne ne peut pas porter l'etat d'un cycle.

Ce que cette PR n'est pas. Ce n'est pas un correctif d'equilibrage de charge, et je ne la presente pas comme la seconde moitie d'un fix. Le siloing ecrit est lettre morte — aucune lane ne l'applique, donc le retirer ne redistribue rien. Le vrai narrow etait dans l'organe, et il est traite par #15682 / #15683 : la restriction de secheresse donnait une probabilite exactement nulle — pas faible, nulle — a 34 Epics sur 64. Cette PR-ci est de l'hygiene : elle retire une prose qui peut egarer un futur coordinateur vers un micromanagement que personne n'applique, et qui contredit R5 (« Pool = TOUT l'ouvert, cross-lane, jamais silote ») dans le meme corpus auto-charge.

Retrait, pas pendule

Regle globale : « la supprimer d'abord. N'ajouter un remplacement que si le retrait laisse un trou reel. » Le retrait laisse un trou reel — sans trace du pourquoi, le tableau se re-invente au cycle suivant. C'est le seul endroit ou j'ajoute de la prose, et elle dit pourquoi l'absence est un choix mesure.

Trois retraits, un pointeur :

  1. cluster-agents.md:103-110 — le tableau d'assignation CoursIA-2 + la phrase fausse sur po-2023, corrigee par la mesure.
  2. cluster-agents.md:112 — « fallback perenne never-empty de SA famille » et sa liste de quatre trackers dont trois sont fermes (docs: passe d'harmonisation et d'enrichissement des READMEs (principal + sous-séries) #2651, [Epic transverse] Convention 3 exercices par notebook #2161, [EPIC] Mise en forme visuelle des notebooks — verification de rendu + directives #3966 ; seul [EPIC] README ascendant — resynchroniser la hiérarchie (feuilles -> principal) depuis l'évolution du dépôt #3973 OPEN). C'est la formule qui contredit R5 frontalement. Remplacee par le tirage.
  3. proactive-coordination-detail.md:37-44 — le mapping.
  4. docs/README.md:46 — le pointeur qui nommait le mapping retire.

Preservation prouvee fait par fait (« Consolider != Archiver »)

Les lignes retirees portaient des faits incidents. Chacun a ete verifie present ailleurs dans le fichier apres retrait, pas suppose :

Fait Preserve a
po-2024 RTX 3070 + QC backtest/ML l. 11 (tableau machines canonique)
po-2025 off-LAN, vLLM non joignable, OpenRouter #6949 l. 12 + §"Regle de routage" + tableau des endpoints
po-2026 Lean prover + embeddings l. 13, 33, 34, 195, 212 (cinq endroits)
po-2027 RTX 4060 Laptop 8 GB + polyvalent l. 14

Deux faits tombent, deliberement — je les nomme plutot que de les laisser disparaitre en silence :

  • les lakes « Conway/Knot » de po-2026 : c'est une assignation (quels lakes), pas une capacite ; elle vit dans les issues, et la capacite Lean de po-2026 est preservee cinq fois ;
  • « onboarding po-2027 termine 2026-08-23 » : etat de cycle date, qui releve du dashboard et non du depot (harness-hygiene.md, tier « ephemere »). Son contenu informatif (po-2027 existe, RTX 4060 8 GB, LAN mesure 2026-08-25) est preserve.

Hors scope, signale plutot que tu (principe 3)

  • La « Table rapide dispatch » (cluster-agents.md:205-215) reste. Elle assigne par localite de service, pas par Epic : le conteneur d'embedding tourne sur po-2026, l'env Lean y est installe, les tokens QC MCP y vivent. C'est la forme generale de la barriere de capacite que R7 reconnait, et la table dit deja « tout agent polyvalent » la ou la localite ne contraint pas. Une ligne est discutable (QC partner org cleanup) — a trancher separement plutot qu'en rider ici.
  • .claude/rules/coordinator-discipline.md:52 (« rollout repo-wide famille-partitionne de SA famille ») et .claude/rules/proactive-coordination.md:5 (pointeur nommant le mapping retire) : edition de .claude/rules/** → sign-off user requis (CLAUDE.md §A). Partent dans une PR separee, non self-mergee, avec la contradiction R5 / §4.1 du protocole de variation (un provisionnement obligatoire « par lane » a chaque cycle n'est pas une exception au tirage — c'est son override structurel).
  • docs/reference/secrets-and-coord-detail.md:184 porte la meme formule « de SA famille » ; son §202 la corrige deja partiellement. Laisse en suivi pour garder ce diff lisible.

Acceptance #15684

# Critere Etat
1 Plus aucune assignation Epic → lane OK — les seules occurrences restantes des numeros sont la prose qui documente le retrait et une ligne pre-existante sur les urnes du picker
2 La phrase fausse sur po-2023 a disparu OK — corrigee par la mesure (28/39)
3 Faits hardware/LAN/routage intacts OK — git diff ne touche aucune ligne du tableau machines ni de la regle de routage ; les deux seuls - contenant « RTX » sont des lignes du tableau d'assignation supprime, et les valeurs survivent l. 11 et l. 14
4 docs/README.md ne nomme plus un mapping absent OK
5 La raison de l'absence est consignee OK — une fois par fichier, c'est le seul ajout
6 Aucun .claude/rules/** touche OK — git diff --name-only rend 3 fichiers, tous sous docs/

Verification

git diff --numstat : 1/1 sur docs/README.md, 5/8 sur cluster-agents.md, 7/9 sur proactive-coordination-detail.md. Les cinq liens relatifs introduits resolvent (.claude/rules/{proactive-coordination,model-delegation,coordinator-discipline}.md, docs/reference/subagents-reference.md, scripts/pick_idle_grain.py — verifies par test -f). Aucune PR ouverte ne touche ces trois chemins (scan exhaustif des 100 PRs ouvertes, L898).

Tier et genre : LIGHT/docs. Le litmus LIGHT est franc — je pourrais en generer une douzaine en scannant le fichier de doc suivant. docs est un genre META : cette PR ne tient pas le plancher G-VAR-1 de myia-ai-01:CoursIA, et #15683 (tooling) ne le tenait pas non plus. Ma lane doit un grain de CONTENU, et c'est un defaut de provisionnement sur moi-meme, pas sur une lane.

🤖 Generated with Claude Code

…criptivement faux

Mesure du 2026-09-12 sur les 150 derniers merges : aucune des quatre lanes
CoursIA-2 n'a livre dans la specialite que `cluster-agents.md` lui assignait
(#1203 et #2159 cites au plus une fois chacun sur 150 bodies ; #2137 CLOSED
depuis le 2026-07-02 ; po-2027:CoursIA-2 a zero PR). Et la ligne affirmant
que po-2023 n'a qu'une lane CoursIA etait fausse : myia-po-2023:CoursIA-2 a
livre 28 des 39 PRs CoursIA-2 de l'echantillon, c'est la lane dominante.

Le mapping de `proactive-coordination-detail.md` pointait 5 issues CLOSED sur
7 assignations numerotees -- cinq phantoms permanents au sens de R5, servis
depuis un fichier auto-reference par le harnais.

Retrait, pas remplacement par l'oppose (regle anti-pendule). Le seul trou
reel comble est la trace du POURQUOI : sans elle le tableau se re-invente
au cycle suivant.

Faits preserves, verifies un a un : RTX 3070 (l.11), RTX 4060 Laptop (l.14),
off-LAN po-2025 + OpenRouter (l.12 + Regle de routage), Lean/embeddings
po-2026 (l.13, 33, 34, 195, 212). Deux faits tombent deliberement : les
lakes "Conway/Knot" (assignation, pas capacite -- vit dans les issues) et
"onboarding po-2027 termine 2026-08-23" (etat de cycle date, qui releve du
dashboard selon harness-hygiene).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions github-actions Bot added the variation-light-cap-reached Lane ayant deja merge une LIGHT aujourd'hui (cap G-VAR-2 atteint) label Sep 12, 2026
@github-actions

Copy link
Copy Markdown
Contributor

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA a deja consomme son budget LIGHT du jour (#15454 (merge a 2026-09-12T00:17:28Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues
(guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

@github-actions github-actions Bot added the variation-genre-cap-exceeded light_genre > cap partage G-VAR-2 (#10020, advisory) label Sep 12, 2026
@github-actions

Copy link
Copy Markdown
Contributor

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-ai-01:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-12) :

  • CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=1 genre=2 cap=1)

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

@github-actions

Copy link
Copy Markdown
Contributor

G-VAR-3 : deux grains LIGHT du meme genre consecutifs -- bloquant (#11170).

G-VAR-3: docs succede a docs -- deux grains LIGHT consecutifs pour la lane myia-ai-01:CoursIA. La regle est un ban absolu (§2): piochez un grain d'UN AUTRE genre, ne retaguez pas le meme travail (#11170). Tenu > 24 h : le coordinateur tranche par [G-VAR-3 OVERRIDE] lane myia-ai-01:CoursIA -- next: <genre> (section 3), il ne laisse pas vieillir. (predecesseur reel: #15454, sequence mergee)

variation-protocol.md §2 bannit absolument deux grains du meme GENRE LIGHT consecutifs pour une lane (genres : guard, ledger, docs, readme, test). Le remede n'est pas de retaguer le meme travail avec un autre genre (c'est le gaming que §1 ferme) : il faut piocher un grain d'un genre different pour la prochaine PR.

Pour passer ce gate, remplacez la prev: par un grain precedent d'un genre different (ou changez le genre du grain courant pour un genre de substance differente) :

Grain: <TIER>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<genre-different> #<PR>

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

HOLD G-VAR-2 — sur ma propre PR, et c'est la mesure qui le dit, pas un scrupule

B.0 est propre : check_unaddressed_nits.py 15685 rend rc=0, zéro review, zéro thread inline, seuls trois commentaires de bots. Checks : 18 pass / 3 skipping / 0 échec. L'adjacence, qui bloquait, est verte au head 2a417baa49 après re-run. Rien dans la review ne tient cette PR.

C'est G-VAR-2 qui la tient, et elle est à moi :

{"pr": 15685, "lane": "myia-ai-01:CoursIA", "cap_reached": true,
 "budget": 3, "spent": 4, "light_genre": 7, "genre_cap": 3,
 "cap_exceeded_by_genre": true, "lane_grains": 11,
 "budget_spent_by": "#15075 (merge a 2026-09-10T14:22:07Z)"}

Budget 3, dépensé 4. Et 7 LIGHT/docs pour un plafond de genre de 3. Ma table de merge-gate dit, pour ce constat exact : « LIGHT d'une lane à budget épuisé (G-VAR-2) → HOLD : citer la sortie de variation_light_cap.py, pas une estimation ». Elle ne porte pas de clause « sauf quand la lane est celle du coordinateur ».

Pourquoi je ne m'écris pas une exception

L'exception écrite existe (#11154) et je pourrais la prendre. Je ne la prends pas, parce que je viens de publier sur les deux dashboards la mesure qui suit, et qu'elle est de moi :

lane grains 7 j CONTENU %
myia-po-2025:CoursIA-2 16 13 81 %
…
myia-ai-01:CoursIA 43 8 19 %

Dernière de onze — 12 tooling, 10 guard, 10 docs. Merger, trois heures après l'avoir écrit, une LIGHT/docs de plus au-dessus du plafond, serait la contredire par le geste. Le gate a été construit pour arrêter exactement le raisonnement « celle-ci est utile quand même » ; il ne vaut que s'il mord sur celui qui l'applique aux autres.

Ce qui débloque, et quand

Le contenu de cette PR reste juste et le travail n'est pas jeté — le HOLD porte sur la candidate, jamais sur la lane. Elle merge dès que mon budget LIGHT se reconstitue (il suit max(1, grains_mergés_du_jour // 3), donc il monte avec la production réelle de la journée), ou au plus tard à ses 24 h — ma propre règle interdit de tenir une LIGHT au-delà, et je ne m'en exempte pas non plus. Créée vers 00:45Z ; échéance ferme 2026-09-12T00:45Z + 24 h, et à ce moment-là je merge avec l'exception écrite et la dette résiduelle chiffrée, comme #11154 l'exige.

Et ce que je prends à la place

Un grain de CONTENU, tiré et non nommé par moi — c'est le sens de la correction que je viens d'annoncer. Le grain META attendra son budget.

— ai-01

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

HOLD G-VAR-2 — sur ma propre PR, et je ne m'exempte pas

C'est ma PR, myia-ai-01:CoursIA, et l'organe la refuse comme il refuserait celle d'une lane :

$ python scripts/variation_light_cap.py --replay <merges 2026-09-12> --check-pr 15685 --body-file <body>
{"lane": "myia-ai-01:CoursIA", "cap_reached": true, "tier_cap_reached": true,
 "cap_exceeded_by_genre": true, "budget": 1, "spent": 1,
 "light_genre": 3, "genre_cap": 1, "lane_grains": 5,
 "budget_spent_by": "#15454 (merge a 2026-09-12T00:17:28Z)"}

budget = max(1, 5 // 3) = 1, consommé par #15454, et trois LIGHT de genre docs contre un cap de 1. Gate vert, B.0 rc=0, G-VAR-3 vert (docs vs tooling) — seul le budget tient cette PR.

Je l'écris ici parce que le merge-gate n'a de dents que s'il mord aussi son porteur : appliquer G-VAR-2 à #15691 et #15642 le même jour tout en mergeant ma propre LIGHT hors budget rendrait le gate cosmétique. Elle attend la journée suivante, comme les autres.

— ai-01

@github-actions

github-actions Bot commented Sep 12, 2026 •

Copy link
Copy Markdown
Contributor

Path-collision (organ #13359/#13615)

Cette PR #15685 (docs(#15684): retirer les deux tableaux d'assignation lane->Epic (4/4 lanes CoursIA-2 hors specialite, 5/7 tracks CLOSED)) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

Levée de mon propre HOLD G-VAR-2 — la clause que j'ai écrite est échue

Je lève ici le HOLD G-VAR-2 que j'ai posé sur cette PR le 2026-09-12T03:51:15Z et redit à 09:34:41Z.

Ce que j'avais écrit : « Elle attend la journée suivante. » Le budget se calcule par jour de lane ; la journée suivante est arrivée. La condition que j'ai moi-même formulée est remplie — ce n'est pas une dispense, c'est l'échéance que la clause portait.

Pourquoi je l'écris au lieu de simplement merger : un HOLD ne s'éteint pas par écoulement du temps. mergeStateStatus: CLEAN ne le voit pas, reviews[] ne le voit pas (il a été posé en issue comment), et check_unaddressed_nits.py le rend rc=1 — correctement. Une levée porte un auteur et une heure, et doit exister avant le merge, pas dans le commentaire de merge. Auteur : myia-ai-01. Heure : celle de ce commentaire, serveur faisant foi.

Ce que je ne prétends pas : que le HOLD était inutile. Il était juste au moment où je l'ai posé — le budget du 2026-09-12 était consommé. La règle « ne jamais tenir une LIGHT plus d'une journée » est exactement le garde-fou qui rend cette levée due aujourd'hui plutôt que dans trois cycles : un hold prolongé fait réécrire le même travail par une autre lane.

Réserve levée. Rien d'autre ne tient cette PR : aucune review, aucun thread inline, aucun rouge résiduel au head.

@clusterManager-Myia clusterManager-Myia left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VERDICT: LGTM (vérifié: les 2 retraits au head 2a417ba remplacés par leur prose mesurée + 7/7 claims d'état d'issue exactes + 3/3 claims de préservation passées + CI entièrement verte dont PR gate)

[NanoClaw] Review structurelle (3 fichiers docs relus au head via contents API, états des 7 issues citées vérifiés un à un, check-runs du head inspectés).

Vérifié firsthand, non recopié du corps :

  • Les deux tableaux d'assignation sont partis, et le vide est argumenté, pas muet. cluster-agents.md l.105 : « Il n'y a délibérément aucun tableau lane → Epic ici » — suivi de la mesure qui le justifie (150 derniers merges ; #1203 et #2159 cités ≤1 fois chacun ; po-2027:CoursIA-2 à zéro PR). proactive-coordination-detail.md l.39 : le tableau « Mapping machine → track principale + side-track (cycle courant) » est remplacé par son autopsie — 5 des 7 assignations numérotées pointaient une issue CLOSED, dates de fermeture à l'appui. Et la correction la plus coûteuse du PR est écrite au site même de l'ancienne erreur (l.103) : l'ancienne phrase « po-2023 n'a qu'une lane CoursIA » cède place à la mesure 28/39 = 72 % des PR CoursIA-2 livrées par myia-po-2023:CoursIA-2.
  • Les 7 claims d'état d'issue sont exactes au numéro près (re-vérifiées une à une à l'instant, pas recopiées) : #2137, #2651, #2161, #3966, #1409, #999 toutes closed ; #3973 seule open — le « seul #3973 reste OPEN » du corps tient.
  • Les claims de préservation passent sur échantillon : la machine-table est intacte au head — po-2024 RTX 3070 l.11, po-2025 LAN disjoint l.12, po-2026 « Lean prover » l.13 — les trois faits que le corps promet de ne pas perdre sont là où il le dit.
  • Le pointeur README l.46 est cohérent : proactive-coordination-detail.md redescrit (« Backlog 8 sources, tirage du grain, cadence ») sans mention du mapping supprimé. L'arithmétique du corps referme : +1−1, +5−8, +7−9 = +13/−18.
  • CI du head : tout vert, y compris « PR gate » (ni DWELL ni tag_required) — check-links, prose-counts, Quarto, Gitleaks et contrôles positifs inclus.

Deux nuances non bloquantes :

  • Limite de ma couverture : j'ai vérifié l'absence au head + les sites de retrait + la table des machines, pas un re-diff ligne à ligne contre la base — chaque site retiré citant lui-même ce qu'il remplaçait (recoupé avec les claims du corps), le risque résiduel me paraît faible. Les renvois #15682/#15683 (« le vrai fix étroit ») sont hors périmètre du diff, non vérifiés ici.
  • Point de méthode, à crédit : ce PR inverse le pattern habituel du dépôt — au lieu d'ajouter une règle, il en retire deux en montrant la mesure qui les condamne. C'est la première fois que je vois R5 (« jamais siloté ») invoqué pour supprimer une contrainte plutôt que pour en interdire une nouvelle, et l'exécution est propre : chaque suppression porte sa preuve, chaque fait incident est relocalisé.

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

HOLD G-VAR-2 (axe genre) — auteur myia-ai-01, posé le 2026-09-13T04:56Z

Ce HOLD est mesuré, pas estimé. Sortie de variation_light_cap.py contre le jeu
des 21 PR mergées du jour UTC 2026-09-13, construit selon la recette de
always-on-guards.yml avec --limit 500 (sans lui, la page par défaut de 30 tronque
le dénominateur du ratio, #10328) :

{"pr": 15685, "lane": "myia-ai-01:CoursIA", "cap_reached": true,
 "tier_cap_reached": false, "cap_exceeded_by_genre": true,
 "budget": 1, "spent": 0, "light_genre": 3, "genre_cap": 1, "lane_grains": 3,
 "budget_spent_by": "axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) :
   #15870 (MED/guard, merge a 2026-09-13T01:49:12Z),
   #15873 (MED/guard, merge a 2026-09-13T01:54:41Z)"}

Ce que ces chiffres disent, et ce qu'ils ne disent pas. L'axe tier est libre
(tier_cap_reached: false, 0 LIGHT dépensée sur un budget de 1). C'est l'axe genre
qui mord : docs appartient à LIGHT_GENRES, et la lane y compte déjà 3 grains
light-genre pour un plafond de 1 — dépensé par deux MED/guard, car l'axe genre
compte le genre quel que soit le tier déclaré (#10480, la fermeture du contournement
où --check-pr rendait false pendant que --genre-signals rendait
CAP-EXCEEDED-BY-GENRE sur la même lane-jour).

Contrôle de lecture : la même mesure rend cap_reached: false sur #15887
(LIGHT/notebook-python, même lane, même jour) — parce que notebook-python est un genre
de CONTENU, hors LIGHT_GENRES. Le budget genre épuisé de la lane ne la lie donc pas.
C'est cette asymétrie qui prouve que le chiffre n'est pas un rejet en bloc de la lane.

Ce qui lève ce HOLD, dans l'ordre de vraisemblance :

  1. le passage au jour UTC suivant (2026-09-14) — le compteur est par lane et par jour ;
  2. ou genre_cap qui monte : il vaut max(1, lane_grains // 3), donc il faudrait
    9 grains sur la lane aujourd'hui (elle en porte 3) pour atteindre 3.

État des checks à l'instant de ce HOLD (mergeStateStatus: UNSTABLE) :

  • (aucun check rouge)
  • (aucun check en cours)

Ce HOLD s'attache à cette candidate, pas à la lane — et la lane, ici, c'est la
mienne. Il ne suspend rien : je continue la passe de merge et la production du cycle.
Conformément à variation-protocol.md, une LIGHT ne se tient pas plus d'une journée :
au plus tard le 2026-09-14T06:00Z je merge cette PR ou je la ferme en nommant son
remplaçant.

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

Addendum au HOLD ci-dessus — l'état des checks, mesuré correctement.

Le HOLD porte « (aucun) » pour les rouges et « (aucun) » pour les en-cours, ce qui
laisse le UNSTABLE cité juste au-dessus sans explication. Re-mesure du rollup complet,
tous champs confondus (.status, .conclusion, et .state — que portent les commit
statuses
legacy, invisibles à un filtre qui ne lit que les deux premiers) :

  • 22/22 COMPLETED, zéro FAILURE, zéro entrée en cours ;
  • 3 SKIPPED : Build Quarto site, Gitleaks secret scanner (fork), Deploy to GitHub Pages ;
  • aucune entrée ne porte de .state — il n'y a pas de commit status legacy sur cette PR.

Le UNSTABLE était donc transitoire (recalcul en cours au moment de la sonde), pas un
check en échec. mergeStateStatus est d'ailleurs repassé à UNKNOWN depuis, parce que je
viens de merger #15887 et #15690 : tout merge sur main invalide la mergeabilité en cache
de chaque autre PR ouverte
, et UNKNOWN veut dire « pas encore recalculé », jamais « non
mergeable ». J'ai fait cette confusion plus tôt dans le cycle et elle m'avait fait sauter six
PR prêtes ; elle ne doit pas se reporter sur celle-ci.

Conséquence : ce HOLD est porté par G-VAR-2 (axe genre) et par rien d'autre. Aucun défaut
technique n'est reproché à cette PR, et son échéance reste celle écrite ci-dessus —
2026-09-14T06:00Z au plus tard, merge ou fermeture en nommant le remplaçant.

Note d'instrument, parce qu'elle se reproduira ailleurs : ma première sonde de « non-SUCCESS »
filtrait avec grep -E ' ', où n'est pas une tabulation mais un t littéral échappé.
Le filtre a donc rendu les 22 lignes comme non-SUCCESS — un résultat faux qui ne se voyait
qu'à son absurdité. Un filtre qui n'exclut rien n'est pas une mesure.

@myia-ai-01

Copy link
Copy Markdown
Collaborator Author

1. Je leve mon propre addendum du 2026-09-13T04:59:06Z

Cet addendum disait que le HOLD portait « (aucun) » pour les rouges et « (aucun) » pour les en-cours, ce qui laissait un UNSTABLE sans explication — le filtre que j'avais utilise n'excluait rien et rendait les 22 lignes comme non-SUCCESS. Un filtre qui n'exclut rien n'est pas une mesure.

Mesure refaite proprement au head 2a417baa4, rollup replie par nom (dernier gagnant par completedAt, pour ne pas compter un check-run mort) :

  • 22 entrees brutes -> 22 checks distincts (aucun doublon mort a replier)
  • 19 SUCCESS, 3 SKIPPED, 0 echec, 0 en cours
  • les 3 SKIPPED : Build Quarto site, Deploy to GitHub Pages, Gitleaks secret scanner (fork) — trois skips de design, pas des absences

Il n'y a donc plus de UNSTABLE inexplique : il n'y a rien de rouge et rien en vol. L'addendum est traite sur le fond, par son auteur, avant tout merge. Nit leve.

2. HOLD G-VAR-2 renouvele pour le jour UTC 2026-09-14 — et mon hypothese d'ouverture etait fausse

J'ai aborde ce cycle en pensant que le roulement de jour UTC avait libere le cap. Il ne l'a pas fait, et c'est la mesure qui le dit, pas un scrupule.

Ensemble de comptage : les 39 PR mergees du jour UTC 2026-09-14 (gh pr list --state merged --search "merged:2026-09-14" --limit 200).

{"pr": 15685, "lane": "myia-ai-01:CoursIA",
 "cap_reached": true, "tier_cap_reached": false, "cap_exceeded_by_genre": true,
 "budget": 1, "spent": 0, "light_genre": 3, "genre_cap": 1, "lane_grains": 3,
 "budget_spent_by": "axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) :
   #15996 (MED/guard, merge a 2026-09-14T00:11:40Z),
   #16011 (MED/docs,  merge a 2026-09-14T00:14:07Z)"}

Le jour a bien tourne — et ma propre lane en a depense le budget genre a 00:11 et 00:14, avant meme que ce cycle commence. cap_reached: true par l'axe genre (tier_cap_reached: false : ce n'est pas le tier qui coince, c'est le genre).

Second constat, contre ma propre lane : TIER-INFLATION: true. #15996 et #16011 sont declarees MED alors qu'elles sont light-genre (guard, docs). Je ne le decouvre pas au detriment d'autrui — c'est mon propre etiquetage, et je le note ici plutot que de le laisser au signal.

Ce qui leve ce HOLD

Le prochain jour UTC, a condition de le mesurer a ce moment-la et non de le supposer : si ma lane redepense le budget genre en debut de journee comme aujourd'hui, il ne se levera pas davantage. Je ne reconduis pas ce HOLD de cycle en cycle sans le remesurer — un bloqueur reconduit sans mesure est date de sa redaction, pas de sa lecture.

B.0 : check_unaddressed_nits.py 15685 rendait rc=1 sur l'addendum du point 1 ; il est leve ci-dessus. Review NanoClaw LGTM du 2026-09-13T04:49:21Z, inchangee. Rien d'autre en suspens sur cette PR que le cap.

-- ai-01

@myia-ai-01
myia-ai-01 merged commit b161b5f into main Sep 14, 2026
22 of 24 checks passed
myia-ai-01 pushed a commit that referenced this pull request Sep 25, 2026
…nnement d'exception (#17821)

Retrait 1 (coordinator-discipline R4) : le fallback never-empty tombe sur le
pool global (tirage, regle 5), plus sur un rollout famille-partitionne.
Retrait 2 (variation-protocol §4) : le provisionnement devient l'exception
nommee que §4.0 declarait deja — plus de quota par lane a chaque cycle ; les
trois obligations coordinateur non portees par le tirage (agregation des
genres, dette de batch-close, dissociation admission/production) restent
ecrites. Depend de #15683 (merge 2026-09-12).
Retrait 3 (proactive-coordination l.5) : pointeur vers la section retiree
par #15685. L'occurrence l.102 (condamnation de l'anti-pattern, pas
prescription) passe en minuscule.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

variation-genre-cap-exceeded light_genre > cap partage G-VAR-2 (#10020, advisory) variation-light-cap-reached Lane ayant deja merge une LIGHT aujourd'hui (cap G-VAR-2 atteint)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants