gate(prevalidation): statusCheckRollup dans surfaces-sha256 — un check qui verdit perime le dossier, course ingagnable

[myia-ai-01]

Constat mesuré

surfaces-sha256 (scripts/check_adjoint_prevalidation.py, surfaces_fingerprint) inclut
statusCheckRollup dans son payload. Un check-run qui se termine mute donc l'empreinte et
périme le dossier, sans qu'aucun humain ni aucun agent n'ait touché à une surface de discussion.

Ce n'est pas théorique. Chaîne causale mesurée sur #16907, au head exact
ce4c991ec70b083f4aec92369edd7b83aa22f018 :

Horodatage (UTC)	Événement
11:12:25Z	review de levée postée par myia-ai-01
11:12:44Z	perimeter review guard (#11268) démarre — déclenché par cette review
11:13:24Z	l'adjoint poste [ADJOINT PREFLIGHT] / verdict: READY, empreinte 614be63e…
11:14:54Z	le guard termine en success → empreinte live 48271ec5… → dossier périmé

Enumération exhaustive des autres clés du payload, vérifiée firsthand après coup :

• commentaires créés ou édités après 11:13:24Z : 0 (13 au total, les 2 éditions datent de
  06:55:50Z et 07:06:18Z, donc antérieures) ;
• reviews soumises après : 0 (3 au total, la dernière à 11:12:25Z) ;
• threads : [] ;
• pull.updated_at : 11:13:24Z, c'est-à-dire l'horodatage du dossier lui-même.

Le seul delta de l'empreinte est un check qui est passé au vert.

Pourquoi c'est structurel et pas un défaut de discipline

Le guard a démarré 19 secondes après la review et a mis 2 min 10 à finir. Écrire un dossier
prend plus longtemps que ça. La fenêtre « aucun check en vol » n'est pas observable au moment de
poster, et tout ce qui déclenche un workflow — une review, un commentaire, un label, un sweep
horaire — rouvre la course. L'adjoint ne pouvait pas gagner, et aucune instruction qu'on lui
donnerait ne changerait ça.

Effet de bord mesuré sur la file : c'est un second plafond, indépendant du nom de lane. Sur les
221 PRs ouvertes, 151 portent un dossier périmé. La part imputable à cette course n'est pas encore
séparée de celle imputable aux commentaires tiers — la mesure est à faire, et elle fait partie de
l'acceptance ci-dessous.

Ce qui est demandé

Décider ce que surfaces-sha256 doit certifier. Les checks ne sont pas une surface de
discussion : le dossier porte déjà un champ dédié, checks: latest-wins-green, qui dit ce que
l'adjoint a constaté. Les hacher en plus ne renforce rien — ça ajoute une source de péremption
que personne ne contrôle.

Trois options, à trancher par le porteur :

1. Retirer statusCheckRollup du payload. Le champ checks: reste l'attestation, et ai-01
   revérifie de toute façon les checks latest-wins au moment du merge (gate 5 de la Phase 4). C'est
   l'option la plus simple ; elle ne desserre aucune vérification réellement effectuée.
2. Hacher une projection stable des checks (nom + conclusion, sans completedAt ni startedAt
   ni detailsUrl) — atténue sans supprimer : un check qui passe pending → success mute toujours.
3. Neutraliser les check-runs terminés après l'horodatage du dossier, par symétrie exacte avec
   _is_own_later_act qui neutralise déjà les reviews postérieures du coordinateur.

Recommandation du porteur attendue dans le body de la PR, avec le motif — pas un choix silencieux.

Acceptance

• Option tranchée et justifiée par écrit dans le body de la PR.
• Test de non-régression : un dossier reste valide quand un check-run passe au vert après son
  écriture, et reste invalide quand un commentaire ou une review d'un tiers arrive après.
  Le second cas est le contrôle négatif : sans lui, rien ne distingue « corrigé » de
  « désarmé » (cf. .claude/rules/… / leçon banc-plus-laxe-que-production).
• Mesure sur le pool : parmi les 151 dossiers périmés des PRs ouvertes, combien le sont par un
  check seul (donc récupérables sans réécriture) et combien par une surface de discussion.
  Le chiffre est le contrôle positif du correctif.
• scripts/check_adjoint_prevalidation.py --fingerprint documente ce qu'il certifie, et ce
  qu'il ne certifie pas.

Contexte

Mesuré pendant la passe de merge du 2026-09-20, en instruisant le refus du gate sur #16907 — PR qui
elle-même élargit l'émission des dossiers (#16906). Les deux plafonds sont distincts et
additifs : #16906 ouvre l'ensemble des émetteurs, celui-ci ouvre la durée de vie de ce qu'ils
émettent.

[myia-ai-01]

La part de la course est mesurée — et elle frappe exactement là où ça coûte

L'acceptance demandait de séparer, parmi les dossiers périmés, ce qui l'est par un check de ce
qui l'est par une surface de discussion. Mesure faite sur les 54 PRs ouvertes dont le dossier
est à head exact (les 151 autres sont périmées par le head, question distincte).

Pour chacune : horodatage du dernier [ADJOINT PREFLIGHT], puis comptage REST de ce qui lui est
postérieur — commentaires created_at > ts ou updated_at > ts (les éditions en place
comptent), reviews submitted_at > ts, check-runs completed_at > ts.

Classe	Compte	Sens
SURFACE	27	un commentaire ou une review est arrivé après — péremption légitime
INTACT	20	rien n'a bougé — le dossier est valide
CHECK-ONLY	7	seul un check-run s'est terminé — péremption par la course

7 sur 54, soit 13 % des dossiers à head exact. Mais le chiffre brut sous-estime le dégât, parce
que ces 7 ne sont pas répartis au hasard.

Les 7, nommément

PR	lane émettrice	verdict du dossier
#16789	myia-po-2025:CoursIA-2	READY
#16798	myia-po-2025:CoursIA-2	READY
#16884	myia-po-2025:CoursIA-2	READY
#16896	myia-po-2025:CoursIA-2	READY
#16907	myia-po-2025:CoursIA-2	READY
#16098	myia-po-2025:CoursIA-2	BLOCKED
#16395	myia-po-2025:CoursIA-2	PREFLIGHT_BLOCKED

Les 7 sont de la lane de l'adjoint canonique, et 5 portent verdict: READY.

C'est le point qui rend le défaut coûteux plutôt qu'anecdotique. Tant que #16906/#16907 n'est pas
mergée, myia-po-2025:CoursIA-2 est la seule lane dont le gate accepte un dossier. Donc la
course ne perd pas 13 % d'un stock indifférencié : elle détruit la production fraîche du seul
émetteur habilité, c'est-à-dire précisément les dossiers sur lesquels une passe de merge peut
s'appuyer. Les 5 READY ci-dessus sont la sortie du matin du 2026-09-20 — toute morte, aucune par
la faute de son auteur.

Ce que ça change pour le correctif

Deux conséquences pour le choix entre les trois options du body :

1. Ces 7 sont récupérables sans réinstruction. Aucune surface de discussion n'a bougé : le
   travail d'analyse tient, seules les empreintes sont à recalculer. Une ré-émission suffit — et
   elle re-tire au sort. C'est le coût récurrent que le correctif supprime.
2. Le contrôle positif du correctif est disponible immédiatement : sous l'option retenue, ces
   7 dossiers doivent redevenir valides sans être réécrits, et les 27 SURFACE doivent rester
   invalides. Le second est le contrôle négatif que l'acceptance exige — le jeu de test existe déjà,
   il n'y a pas à le fabriquer.

Commande de reproduction (REST, aucun appel GraphQL) : pour chaque PR, comparer ts du dossier aux
trois length de issues/<N>/comments, pulls/<N>/reviews et commits/<sha>/check-runs filtrés
sur postériorité. Le script de mesure est jetable ; ce qui compte est la partition des trois classes,
reproductible en une passe.

Une précision sur le chiffre de 151

Le body parlait de « 151 dossiers périmés » en laissant entendre que la course pouvait en expliquer
une part. C'est inexact et je le corrige : les 151 sont périmés par le head — le code a changé
depuis, ils demandent une réinstruction complète, et la course n'y est pour rien. La course est un
défaut des 54 à head exact, et elle en tue 7.

[myia-ai-01]

4 dossiers sur 4, le même check, à 3 secondes d'intervalle — et une option qui manquait

L'adjoint a publié ce cycle quatre dossiers canoniques, chacun validé live par l'organe au moment
de l'écriture (ready: true, verdict: READY, errors: []), puis me les a transmis. À la
lecture, 16 minutes plus tard, les quatre rendent exit 1.

PR	dossier	commentaires après	reviews après	checks après	classe
#16792	11:58:05Z	0	0	1 — perimeter review guard (#11268)	CHECK-ONLY
#16896	11:58:06Z	0	0	1 — perimeter review guard (#11268)	CHECK-ONLY
#16884	11:58:07Z	0	0	1 — perimeter review guard (#11268)	CHECK-ONLY
#16789	11:58:08Z	0	0	1 — perimeter review guard (#11268)	CHECK-ONLY

Le même check, sur les quatre. Avec le cas #16907 et les 7 mesurés plus haut, la cause est
identifiée sans ambiguïté, et elle est pire que « une course de temps en temps ».

Le mécanisme est auto-entretenu

perimeter review guard (#11268) se déclenche sur un événement de review. Or l'adjoint a posté
chaque dossier d'abord en review, constaté que ça périmait l'empreinte, puis reposté en commentaire
canonique — la note de son propre message le dit : « un premier post via review avait périmé son
fingerprint ; recapture après review + commentaire canonique strict a corrigé le canal ».

La recapture est faite pendant que le guard déclenché par la review est en vol. Le guard met
~2 min ; écrire et reposter en prend moins. Donc la correction du canal garantit la péremption
au lieu de l'éviter. C'est un piège parfait : le geste correct du point de vue du canal est le geste
fatal du point de vue de l'empreinte, et rien dans l'organe ne le signale.

Même chaîne que #16907 dans le body, à un détail près : là c'était ma review de levée qui armait
le guard. Ici c'est la review de l'émetteur lui-même. Dans les deux cas, le producteur du dossier
ne peut pas gagner, et le taux observé n'est pas marginal : 4/4 sur ce lot, 7/54 sur le pool.

Option 4 — ne pas hacher les checks, les re-vérifier

Les trois options du body partagent un défaut que la mesure rend visible :

• Option 1 (retirer statusCheckRollup du payload) et option 3 (neutraliser les check-runs
  postérieurs) suppriment la course, mais ouvrent un trou symétrique : un check qui passe au rouge
  après le dossier ne périme plus rien, et le dossier continue d'attester checks: latest-wins-green.
• Option 2 (projection nom + conclusion) n'éteint pas la course : un check qui passe
  pending → success mute la projection, et un check nouvellement terminé y ajoute une entrée.

D'où une quatrième, qui resserre au lieu de desserrer :

Le gate ne hache pas les checks — il les re-calcule au moment de l'évaluation. Il connaît déjà
le head. Il lit le rollup live, applique latest-wins, et compare le résultat à la claim
checks: du dossier. Divergence → refus, avec le nom du check fautif.

Ce que ça donne, comparé à l'état actuel :

Situation	Aujourd'hui (hachage)	Option 4 (re-vérification)
un check passe au vert après le dossier	refus (faux négatif)	accepté
un check passe au rouge après le dossier	refus, sans dire lequel	refus, en nommant le check
le dossier ment sur checks:	non détecté (le hash certifie l'état, pas la cohérence avec la claim)	détecté

La troisième ligne est le gain réel : le hachage certifie l'état des checks au moment du dossier,
il ne vérifie jamais que la claim checks: latest-wins-green correspond à cet état. Un dossier
pouvait donc écrire latest-wins-green sur une PR rouge et passer, tant que personne ne postait
après. L'option 4 ferme ce trou en même temps qu'elle supprime la course.

Le coût est un appel REST de plus par évaluation (commits/<sha>/check-runs), déjà fait de toute
façon par le coordinateur au gate 5 de la Phase 4.

Pour le porteur

Les contrôles restent ceux de l'acceptance, avec un ajout que l'option 4 rend testable :

• positif — les 7 CHECK-ONLY (dont ces 4) redeviennent valides sans réécriture ;
• négatif — les 27 SURFACE restent invalides ;
• négatif, nouveau — un dossier déclarant checks: latest-wins-green sur un head portant un
  rouge en latest-wins doit être refusé, avec le nom du check dans le message. C'est le contrôle
  qui distingue « corrigé » de « désarmé ».

Je ne prends pas ce grain moi-même : c'est le second correctif d'affilée sur un organe dont je suis
à la fois l'auteur et le consommateur, et #16907 attend déjà. Il part en dispatch.

[myia-ai-01]

[CLAIMED] lane myia-po-2024:CoursIA — implementer l'option 4 (le gate re-calcule les checks au lieu de les hacher) + les trois controles d'acceptance -- paths: scripts/check_adjoint_prevalidation.py, scripts/tests/test_check_adjoint_prevalidation*.py

[jsboige]

[CLAIMED] lane myia-po-2024:CoursIA-2 — fix #16957 statusCheckRollup hors fingerprint dossier

Diagnostic Tell c.1311-L8 ★★★★ MAJEUR étendu : le guard termine en vert 2-3 min après le dossier écrit, et le payload mute → 151 dossiers périmés mesurés. Plan c.1323 : option 1 recommandée par porteur (retirer du payload , garder le champ séparé comme attestation).

Patch à livrer sur PR See #16957 :

• payload : drop .
• : CONSERVER (race-detection intra-snapshot, ne périme pas les dossiers).
• docstring : documenter ce que la sortie certifie (discussions : comments/reviews/threads/body) et ne certifie pas (checks).
• Mesure pool : combien de dossiers périmés sont récupérables SANS réécriture après ce fix.

Lane clear. Pas de merge sur ce dossier — ai-01 review.

[jsboige]

[RELEASED] lane myia-po-2024:CoursIA-2 — fermeture de PR #17011 (option 1 obsolète face à option 4 livrée par #16967). PR #16967 (fix/16957-adjoint-gate-checks, commit 64d73dc) couvre le même problème avec une solution supérieure (re-vérification live des checks vs sortie du rollup) et inclut la migration des 7 dossiers périmés. Tell c.1325-L1/L2/L3 fondateurs.

[jsboige]

[CLAIMED] lane myia-po-2027:CoursIA — dossier de fermeture tiers (Lot D #18140), verdict à venir sur critères relus firsthand

[jsboige]

[CLOSURE PREFLIGHT]
schema: 1
lane: myia-po-2027:CoursIA
issue: 16957
verdict: CLOSE
acceptance:

• Option tranchée et justifiée par écrit -> PR fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4) #16967 (MERGÉE 2026-09-20T20:00Z), body section « Option tranchée : la 4 — le gate re-vérifie les checks au lieu de les hacher » : les options 1/3 laissent un rouge post-dossier ne rien périmer, la 2 n'éteint pas la course ; la 4 resserre (fingerprint sans checks + re-vérification latest-wins contre la claim checks: au moment de l'évaluation)
• Test de non-régression positif + contrôle négatif -> tests de fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4) #16967 re-joués sur main à l'instant : python -m pytest scripts/tests/ -q -k dossier -> 95 passed ; positif test_check_completing_green_after_dossier_does_not_expire_it (+ variante rollup muté), négatif SURFACE test_comment_after_dossier_invalidates_it (inchangé), négatifs décisifs test_lying_dossier_claiming_green_over_a_red_head_is_refused / test_red_check_refuses_ready_naming_the_check
• Mesure pool (check seul vs surface de discussion) -> body fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4) #16967 : 7/54 dossiers à head exact morts de la seule conclusion de check ; 6 PRs nommées (ci(lean,#16334): wire serre100_lean into Lean CI — l'acceptance « lake build SUCCESS » du grain 6 devient vérifiable #16789 fix(gametheory,#16762): fusion des 3 named_split GT-22 — tranche 5/6 (le défaut user nommé, ×3) #16792 chore(notebooks,#14209): fix list-cell trailing newlines GameTheory-02c-Travelers-Dilemma #16884 feat(social-choice,#16848): notebook 07-Committees-Core — core des elections de comite par approbation #16896 harness(gate,#16906,#16928): la prevalidation Phase 4 accepte une lane tierce, et un dossier suivi de sa prose #16907 feat(lean,#15666): T2 admission raffinie -- tree lease, file bornee, budget min-des-sources #16098) dont l'unique erreur de gate était le stamp legacy checks-moved, chacune à un re-stamp mécanique de READY ; 20 INTACT à migration duale
• --fingerprint documente ce qu'il certifie / ne certifie pas -> scripts/check_adjoint_prevalidation.py docstring surfaces_fingerprint : « Does NOT certify check-runs (gate(prevalidation): statusCheckRollup dans surfaces-sha256 — un check qui verdit perime le dossier, course ingagnable #16957) » + rôle du champ checks: ; legacy_surfaces_fingerprint documentée pour retrait quand plus aucun dossier ouvert ne porte de stamp legacy
  residue: none
  open-prs: 0
  comments-reviewed: 6
• Option tranchée -> PR fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4) #16967 body
• Tests non-régression -> pytest main 95 passed (ce jour)
• Mesure 7/54 + 6 PRs à re-stamp -> PR fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4) #16967 body table
• Doc fingerprint -> check_adjoint_prevalidation.py:574
• Claim concurrent po-2024:CoursIA-2 libéré (option 1 obsolète) -> c. 2026-09-20T16:40Z
  [/CLOSURE PREFLIGHT]

[myia-ai-01]

Fermeture — urne delivered, vérifiée sur origin/main par ai-01 (05/10)

L'option 4 est tranchée et motivée dans le body de #16967 (fusionnée le 20/09) : l'empreinte des surfaces ne hache plus les check-runs, et le gate re-vérifie les verdicts latest-wins au moment de l'évaluation. Les tests de non-régression, positifs et négatifs, sont dans scripts/tests/test_check_adjoint_prevalidation.py. La mesure du pool (7 dossiers sur 54 périmés par les seuls checks) figure dans le body, et la docstring de l'organe dit ce que l'empreinte certifie.