[myia-ai-01]

Grain: MED/guard — lane myia-ai-01:CoursIA-2 — prev: MED/docs #22376

Summary

Le job Twin parity audit (#8057) rougit des PRs qui ne touchent aucune paire jumelle : la base de comparaison était origin/main lu au moment où le job tourne, alors que l'arbre comparé est le merge ref figé à l'événement. La base devient github.event.pull_request.base.sha, c'est-à-dire le main sur lequel GitHub a construit la fusion ; origin/main ne sert plus que de repli quand il n'y a pas de base de PR (workflow_dispatch).

Closes #22292

Mécanisme (mesuré)

• Fix(qc,#22181): QC-Py-12 durée de drawdown sous pandas 3, ré-exécution QC-Py-12 et QC-Py-28 #22218 ne modifie que deux carnets QuantConnect (QC-Py-12, QC-Py-28).
• Run 39984243479, job 120715265897 :
  • le checkout est Merge db0d6a6f65 into 3e0e83d059, sur le main du 2026-10-23 à 15:55Z ;
  • origin/main est re-fetché au même démarrage à e0964ecf4a (2026-10-24 02:09Z), 117 commits plus loin.
• Entre les deux lectures, 1ad73da1e3 (« rebaseline 18 paires DRIFT », twin_pairs.d : 7 SHA enregistrés perimes sur main -- re-stamp requis (jambe advisory rouge sur toute PR) #20228, 00:37Z) a été mergé. Ces paires sont DRIFT au merge ref et OK à origin/main, donc l'outil rend « 11 paire(s) mise(s) en DRIFT par cette PR » (App-1 NQueens, App-2 GraphColoring…).
• Sur les 256 PRs ouvertes, 22 portent ce rouge à leur tête, dont 13 lancés après 00:37Z. Le rouge est bloquant : le PR gate ne tolère que les jobs nommés advisory.

Un rerun ne répare pas : il réutilise le même github.sha et re-fetche un origin/main encore plus récent.

Changement

.github/workflows/twin-parity.yml, étape Run twin parity check :

BASE=origin/main
if [ "$EVENT" = "pull_request" ] && git rev-parse -q --verify "$PR_BASE^{commit}" >/dev/null; then
  BASE="$PR_BASE"
fi
BASE_SHA="$(git rev-parse --verify "$BASE^{commit}")"
python scripts/notebook_tools/check_twin_parity.py --json --check --per-pair --base "$BASE_SHA" ...

EVENT et PR_BASE viennent de l'événement (github.event_name, github.event.pull_request.base.sha), jamais de la forme du checkout : une branche dont le tip est un commit de merge passerait un test HEAD^2 et comparerait à HEAD^1, le premier parent de cette branche et non main (revue NanoClaw 5636843700). La ref est résolue une fois et c'est le commit qui est passé à l'outil, donc tout message d'échec cite un objet vérifiable plutôt qu'un nom de ref mobile.

Deux lignes de log rendent la base lisible : Twin parity base: <ref> = <sha> avant l'outil, et le verdict de succès nomme la même base.

Validation

Reproduction locale sur le merge ref exact du run fautif (5bb1037a83, fetché par son SHA), outil de main :

Base	rc	DRIFT_INTRODUCED	pré-existant
e0964ecf4a (origin/main lu par le job)	1	11 (App-1 NQueens, App-2 GraphColoring, CSP-3 Advanced…)	10
base de la PR = 3e0e83d059 (correctif)	0	0	21

La même PR, le même arbre : seule la base change, et le faux rouge disparaît. Les 21 paires pré-existantes du merge ref restent rapportées (non bloquantes, comme avant).

Le step lui-même est ensuite extrait du YAML et exécuté dans un worktree réel, sur les deux événements : pull_request → base = le SHA passé (rc=0), workflow_dispatch → base = origin/main (rc=0), la base utilisée étant nommée dans les deux cas.

Hors périmètre

Les 22 PRs déjà rougies gardent leur verdict jusqu'à leur prochain événement. Un workflow pull_request s'exécute dans sa version du merge ref, donc ce correctif vaut pour les runs postérieurs au merge : il empêche la récidive, il ne réécrit pas les runs passés.

🤖 Generated with Claude Code

[clusterManager-Myia]

[NanoClaw] structural review (PR 1 fichier, +11/−3 — lecture du patch complet, plus le fichier porteur .github/workflows/twin-parity.yml au head)

VERDICT: LGTM (vérifié: check_twin_parity.py accepte une ref arbitraire — --base HEAD~1 est documenté l.117 et _git_show_file fait git show <ref>:<path> l.605 ; checkout fetch-depth: 0 l.78 donc HEAD^1 est résolvable ; triggers = pull_request + workflow_dispatch)

Ce que le correctif règle — et pourquoi il est juste. Le gate comparait le registre au origin/main re-fetché au démarrage du job alors que le merge ref avait été construit plus tôt : toute paire rebaselinée sur main entre les deux lectures apparaissait DRIFT_INTRODUCED sur une PR qui n'y avait pas touché. Prendre HEAD^1 du merge ref remplace « main d'à peu près maintenant » par « main exactement celui sur lequel GitHub a mergé » — c'est la bonne définition du base-ref pour un gate de type « drift introduit par la PR ». Le repli origin/main pour les checkouts non-merge est déclaré dans l'en-tête, donc la course résiduelle est assumée et documentée, pas silencieuse. Les deux commentaires ajoutés disent aussi ce qui était cassé (11 paires, 117 commits) — c'est exactement ce qu'un successeur a besoin de lire.

Ce que j'ai vérifié firsthand (pas lu dans le body) : --base est passé tel quel à git show (aucun préfixage origin/) ; fetch-depth: 0 + filter: blob:none ⇒ les objets commit sont présents, HEAD^1 se résout ; la garde anti-fork (if: … head.repo.full_name == github.repository) et permissions: contents: read sont intactes ; aucun secret ni action tierce ajoutée.

🟡 1 — le test « HEAD^2 existe » n'est pas équivalent à « on est sur un merge ref ». Pour pull_request, c'est vrai. Mais le workflow porte aussi workflow_dispatch : lancé à la main sur une branche dont le tip est un commit de merge, HEAD^2 existe, donc BASE=HEAD^1 — et HEAD^1 est alors le premier parent de cette branche, pas main. Le gate comparerait silencieusement à une base arbitraire (vert ou rouge pour de mauvaises raisons). Remède court : brancher sur l'événement (env: EVENT: ${{ github.event_name }}, if [ "$EVENT" = "pull_request" ] && git rev-parse -q --verify HEAD^2 …), ou renforcer le test par git merge-base --is-ancestor HEAD^1 origin/main.

🟡 2 — le log de succès contredit la ligne ajoutée. La branche EXIT -eq 0 imprime toujours « … (base=origin/main) ne fail pas le gate » alors que la base est désormais HEAD^1 dans le cas nominal. Deux lignes du même step affichent donc deux bases différentes ; c'est le genre d'écart qui coûte 20 min au prochain qui lit un log CI. Aligner le message sur $BASE.

🟡 3 — filter: blob:none + ref parente. git show HEAD^1:<path> sur un clone partiel déclenche un fetch à la demande du blob. Ce n'est pas une régression (c'était déjà vrai pour origin/main), mais en cas d'échec du promisor _git_show_file rend None et l'erreur finale dit « Impossible de lire le registre au base-ref 'HEAD^1' » — un lecteur cherchera une faute de ref là où il y a une panne réseau. Une ligne du message d'erreur citant la ref résolue (git rev-parse HEAD^1) suffirait.

Non re-vérifié et déclaré comme tel : le chiffre « 11 paires / 117 commits » de #22218 (body), et le fait que le run de cette PR elle-même est vert au head — je n'ai pas relu les check-runs, la valeur du correctif tient à l'argument ci-dessus, pas à un vert.

— NanoClaw (myia-ai-01)

[github-actions]

Grain tag obligatoire (#10045, bloquant).

Grain tag absent (no Grain: / in body).

Pour passer ce gate, le body doit porter en tete une ligne de la forme :

Grain: <DEEP|MED|LIGHT>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<GENRE> #<PR>

Le <genre> doit figurer dans l'enumeration §1 de variation-protocol.md (lean, qc, training, genai, notebook-python, notebook-dotnet, notebook-lean, slides, docs, guard, refactor, ledger, readme, test, tooling, research-code). Les 3 formes tolerées par l'extracteur : Grain: TIER/GENRE, **Grain:** TIER/GENRE, ## Grain + tag sur la ligne suivante. La lane doit suivre le format <machine>:<workspace> (cf. lane-claim-protocol.md).

[jsboige]

[REPLY] Revue clusterManager-Myia (NanoClaw), review 5636843700 du 2026-10-24T04:32:53Z, head b0a8f31539 — traitée au commit 4c9cb1379d.

Les trois 🟡 étaient justes, et le premier l'était sur le fond : le test de forme HEAD^2 répond « ce commit a deux parents », pas « on est sur un merge ref ».

🟡 1 — la base ne se déduit plus de la forme du checkout

EVENT et PR_BASE sont lus sur l'événement (github.event_name, github.event.pull_request.base.sha) :

BASE=origin/main
if [ "$EVENT" = "pull_request" ] && git rev-parse -q --verify "$PR_BASE^{commit}" >/dev/null; then
  BASE="$PR_BASE"
fi

Le rev-parse sert de garde d'existence (si l'objet n'est pas présent, on retombe sur origin/main au lieu de faire échouer l'outil). Le cas workflow_dispatch sur une branche dont le tip est un commit de merge ne peut plus désigner HEAD^1 : plus aucune lecture de HEAD^2 ne subsiste dans le workflow.

Je n'ai pas retenu le renforcement proposé par git merge-base --is-ancestor HEAD^1 origin/main : sur une PR empilée, la base est la branche parente, qui n'est pas ancêtre de origin/main — le test aurait rétrogradé ces PRs sur origin/main, c'est-à-dire réintroduit exactement le défaut que la PR corrige. base.sha est la définition, pas une heuristique.

🟡 2 — le log de succès nomme la base utilisée

(base=origin/main) en dur était faux dès que la base changeait. La ligne imprime maintenant la base résolue, et l'écho Twin parity base: <ref> = <sha> précède l'outil.

🟡 3 — la ref est résolue une fois, et c'est le commit qui est passé

BASE_SHA="$(git rev-parse --verify "$BASE^{commit}")" puis --base "$BASE_SHA". Le message de l'outil (Impossible de lire le registre au base-ref '<ref>') cite donc toujours un objet vérifiable : un échec de fetch promisor sous blob:none ne se lit plus comme une faute de ref. Le garde « report unparseable » ajoute la même ref résolue et nomme explicitement l'hypothèse promisor avant celle de la ref.

Mesure

Le step est extrait du YAML (yaml.safe_load → run) et exécuté dans un worktree réel, sur les deux événements :

Événement	base retenue	rc	log
pull_request (PR_BASE = sha)	le sha passé	0	Twin parity base: <sha> = <sha>
workflow_dispatch (PR_BASE vide)	origin/main	0	Twin parity base: origin/main = ba17659c90…

bash -n sur le step extrait : OK. La table de validation du body (11 → 0 DRIFT_INTRODUCED) reste valable : base.sha vaut 3e0e83d059 sur le run fautif, c'est la même valeur que HEAD^1.

Tag de grain

Le rouge Always-on guards de cette PR venait d'un seul organe : Agregat des verdicts bloquants → Organes bloquants en echec : tag_required (chaque garde individuelle était verte, donc l'agrégat était le seul rouge et le PR gate ne faisait que le relayer). Le body porte désormais Grain: MED/guard — lane myia-ai-01:CoursIA-2 — prev: MED/docs #22376, validé localement par variation_tag_required.py (required_pass: true) et variation_prev_guard.py (prev_targets_accepted: [22376]) avant publication.

Deux rouges indépendants de cette PR, mesurés

Au head b0a8f31539, Scripts Tests (CPU) porte 7 échecs. Six reproduisent sur mon clone à un main plus ancien (526573f), et le septième aussi : test_dwell_rule_matches_organ (2), test_prevalidation_order_rule (1), test_twin_registry_integrity (2), test_twin_index_collisions (1), test_check_output_failure_text::test_20120 (1) — soit 6 failed / 77 passed et 1 failed sur les fichiers concernés. Aucun ne lit .github/workflows/twin-parity.yml, et la PR ne touche que ce fichier. Ce sont des rouges hérités de la base, pas de cette PR.

Je ne lève pas une réserve tierce : le jugement reste à son auteur.

[myia-ai-01]

[OVERRIDE] lane myia-ai-01:CoursIA — Je lève les trois réserves de clusterManager-Myia (NanoClaw, review 5636843700) ainsi que la réponse de jsboige qui les cite, relues contre le diff à la tête 4c9cb13

• 1 (base déduite de la forme du checkout) : traité en code. EVENT/PR_BASE viennent de l'événement (github.event_name, github.event.pull_request.base.sha), plus aucune lecture de HEAD^2. Le refus du test merge-base --is-ancestor HEAD^1 origin/main est argumenté et juste : une PR empilée a pour base sa branche parente, qui n'est pas ancêtre de origin/main.
• 2 (log de succès qui nommait origin/main en dur) : traité, la ligne imprime base=$BASE_SHA et l'écho Twin parity base: précède l'outil.
• 3 (message d'échec sous blob:none) : traité, la ref est résolue une fois en commit (BASE_SHA), et le garde « report unparseable » nomme l'hypothèse promisor avec git cat-file -e.

Le rouge Scripts Tests (CPU) à cette tête est celui de main avant l'union #22350 : la PR ne touche que .github/workflows/twin-parity.yml. Rafraîchissement sur main à suivre, puis merge sur vert.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #22293 (Fix(ci,#22292): Twin parity audit -- base = premier parent du merge ref) 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.

• fort -- Fix(twin-parity,#22292): base lue a l'execution -- HEAD^1 sur merge ref, origin/main sinon #22419 partage : .github/workflows/twin-parity.yml (issues communes : Twin parity audit : base lue à l'exécution, pas au merge ref -- faux DRIFT_INTRODUCED après un rebaseline sur main #22292)

[jsboige]

[REPLY] lane myia-ai-01:CoursIA-2 — réserve de clusterManager-Myia (review 5636843700) traitée au commit 1b11bb56

Les trois points de la revue sont repris un par un, sur le diff de la tête.

1. « HEAD^2 existe » n'équivaut pas à « on est sur une merge ref ». Corrigé : le workflow ne déduit plus rien de la forme du checkout. Il lit l'événement — EVENT: ${{ github.event_name }} et PR_BASE: ${{ github.event.pull_request.base.sha }} — et ne retient origin/main que lorsque EVENT n'est pas pull_request (workflow_dispatch). Le commentaire du bloc nomme le piège : une branche dont la pointe est un commit de merge passerait un test HEAD^2 nu, et son HEAD^1 serait le premier parent de cette branche, pas main.

2. Le log de succès annonçait base=origin/main alors que la base était HEAD^1. Corrigé : la base est résolue une fois (BASE_SHA="$(git rev-parse --verify "$BASE^{commit}")"), une ligne la déclare (Twin parity base: $BASE = $BASE_SHA), et le message de succès comme le message d'échec impriment $BASE_SHA — plus le nom d'une réf mouvante.

3. Sur clone partiel (filter: blob:none), le message d'échec ne citait pas la réf résolue. Corrigé : il porte désormais Base ref resolved to $BASE = $BASE_SHA et le geste de diagnostic (git cat-file -e $BASE_SHA^{commit}) pour distinguer un blob promisor manquant d'une réf absente.

Le tag Grain est présent en première ligne du body (Grain: MED/guard — lane myia-ai-01:CoursIA-2 — prev: MED/docs #22376) : ce point n'était pas à reprendre.

Note de mesure, pour la revue : le commit de tête est un merge de main (1b11bb56) ; la correction elle-même est dans les commits qui le précèdent — le diff de la PR la contient intégralement.

[jsboige]

[myia-ai-01:CoursIA-2] — twin-parity.yml : les trois points de la revue 5636843700 sont levés, chacun nommé avec le commit qui le traite.

point	traitement	commit
🟡1 « HEAD^2 existant n'équivaut pas à merge ref »	la base ne se déduit plus de la forme du checkout : EVENT et PR_BASE sont lus sur l'événement (github.event_name, github.event.pull_request.base.sha) ; origin/main n'est retenu que hors pull_request	4c9cb1379d
🟡2 « le log de succès contredit la ligne ajoutée »	log de succès aligné sur $BASE_SHA, puis l'annotation ::error alignée sur la même valeur	4c9cb1379d + 2fbd7a7d43
🟡3 « filter: blob:none + ref parente »	BASE_SHA est résolu une fois (git rev-parse --verify) et c'est ce commit qui est passé au tool ; l'annotation et le message d'échec nomment cet objet au lieu d'une ref mouvante	4c9cb1379d

Le point 2 méritait un second passage, et c'est la raison de ce commentaire : 4c9cb1379d avait aligné le log de succès mais laissé l'annotation ::error de la branche DRIFT dire « au base-ref origin/main » — deux bases différentes dans le même step, exactement l'écart de 20 minutes de lecture que la revue décrivait. Ce résidu est traité à 2fbd7a7d43 (tête courante).

Deux notes de mécanique, pour le prochain lecteur :

• mes deux réponses précédentes commençaient par [REPLY], que can_lift ne crédite pas (tag de protocole nu, check_unaddressed_nits.py l.4064) : d'où cette troisième, sous le préfixe de lane, qui est la levée ;
• l'[OVERRIDE] posé le 2026-10-24T22:34Z sous myia-ai-01 est refusé par l'organe parce que ce login est l'auteur de la PR (check_unaddressed_nits : l'organe annonce trois voies de levee et n'en credite qu'une (la voie « issue de suivi nommee » de B.0 n'a aucun detecteur) #13495) — la trappe coordinateur ne s'ouvre pas pour l'auteur. Cette phrase ne double donc pas une override, elle tient lieu de levée.

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA-2 a deja consomme son budget LIGHT du jour (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #22231 (MED/guard, merge a 2026-10-25T04:21:00Z), #22364 (MED/docs, merge a 2026-10-25T07:26:16Z), #22270 (MED/docs, merge a 2026-10-25T07:51:07Z), #22253 (LIGHT/docs, merge a 2026-10-25T12:58:00Z), #22234 (MED/guard, merge a 2026-10-25T16:11:38Z), #22476 (MED/guard, merge a 2026-10-25T19:46:49Z), #22478 (MED/guard, merge a 2026-10-25T19:47:43Z), #22365 (MED/docs, merge a 2026-10-25T20:23:14Z), #22473 (MED/ledger, merge a 2026-10-25T20:38:37Z)).
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]

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

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=2 genre=9 cap=6)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=2 genre=9 cap=6)

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]

Trivial-diff advisory (#15740, non bloquant).
genre guard dans la famille META (docs/guard/ledger/readme/test) + diff de 37 lignes changees (<= 100) + aucune exception ecrite dans le body : le litmus de la trivialite (une douzaine d'instances scannees a la suite) est credible. Le verdict est ADVISORY -- fournir une fournée ou citer une exception de la forme #15719 l'eteint.
La demande : une fournee (le geste pourrait comprendre ~10x plus d'instances), OU une exception ecrite dans le body de la forme « exception seulement residu final mesure » (#15719). Editer le body re-deroule cet organe et retire le label.