fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4)

[jsboige]

Grain: MED/guard — lane myia-po-2024:CoursIA — prev: MED/notebook-python #16948

Option tranchée : la 4 — le gate re-vérifie les checks au lieu de les hacher

Constat mesuré sur l'issue : surfaces_fingerprint hachait statusCheckRollup, donc tout check-run qui conclut — même en succès — périmeait le dossier sans qu'aucune surface de discussion n'ait bougé. 7/54 dossiers à head exact morts de cette seule cause, dont 4/4 du lot du cycle tués par perimeter review guard (#11268) à trois secondes d'intervalle ; le geste correctif garantissait l'échec (la review du correctif armait le guard qui périmait le correctif).

Les trois options du body partagent le défaut symétrique : 1 et 3 laissent un rouge post-dossier ne rien périmer, 2 n'éteint pas la course. L'option 4 resserre : le fingerprint ne couvre plus les checks ; à l'évaluation, le gate relit commits/<sha>/check-runs (du commit, pas du rollup — le rollup remonte le jumeau annulé quand deux runs partagent un SHA), applique latest-wins par nom (tri started_at, tie-break id, parmi les runs complétés — un run in flight n'a pas de verdict), et compare le résultat à la claim checks: du dossier. Divergence → refus, check nommé (output.title inclus quand présent : classe DWELL/FAIL du PR gate comme information, pas dans le prédicat). skipped et neutral ne sont pas des rouges.

Situation	Avant (hachage)	Après (option 4)
check passe au vert après le dossier	refus (faux négatif)	accepté
check passe au rouge après le dossier	refus muet	refus, check nommé
dossier qui MENT sur checks:	non détecté	détecté (nouveauté)

La 3e ligne est le gain que le hachage ne pouvait pas donner : il certifiait l'état, jamais la cohérence claim ↔ état.

Le trou que je nomme : la récupération zéro-touch des 7 stamps périmés est impossible

L'acceptance positive dit « les 7 redeviennent valides sans être réécrits ». Un stamp pré-fixe a haché l'état des checks au moment du stamp ; cet état a changé depuis ; un SHA-256 sur des données changées ne se ré-derive pas — aucune fonction pure du snapshot courant ne peut reproduire ce hash. Mesuré en live sur le head exact de chacun (2026-09-20T15:0xZ, branche de cette PR) :

PR	erreurs du gate
#16789, #16792, #16884, #16896, #16907, #16098	exactement une : discussion surfaces changed ... legacy stamps whose checks moved need one --template re-stamp
#16798	idem + state must be OPEN, live=MERGED (mergée depuis la mesure)
#16395	plus de dossier (consommé depuis)

Aucune erreur de surface, de head ou de claim sur les 6 vivants : chacun est à un re-stamp mécanique de READY — --template recalcule tous les champs mécaniques (fingerprint, comptes, head), sans relecture des surfaces ni re-préflight — et le dossier re-stampé ne peut plus jamais être périmé par une conclusion de check. Si une voie zéro-touch existe, elle est à nommer ; je ne la vois pas.

Migration : acceptance duale — un stamp matche le nouveau digest ou le digest legacy (payload identique + rollup, strictement plus contraignant, donc l'union n'affaiblit rien). Les 20 INTACT mesurés restent valides sans action (leur état checks n'a pas bougé → digest legacy inchangé). legacy_surfaces_fingerprint est documentée pour retrait quand plus aucun dossier ouvert ne porte de stamp legacy.

Contrôles — deux négatifs dont le décisif, tous mesurés

Unitaires (40/40 verts, 11 nouveaux) :

• positif : un check qui conclut vert après le stamp ne périmé plus (test_check_completing_green_after_dossier_does_not_expire_it + variante rollup muté) ;
• négatif SURFACE : un commentaire tiers après le dossier périme toujours (test_comment_after_dossier_invalidates_it, inchangé) ;
• négatif décisif : un dossier déclarant checks: latest-wins-green sur un head dont le latest-wins est rouge est refusé, check nommé dans le message (test_lying_dossier_claiming_green_over_a_red_head_is_refused, test_red_check_refuses_ready_naming_the_check) ;
• mécanique latest-wins : jumeau annulé masqué par le run plus récent, rouge ancien battu par vert récent, skipped/neutral non rouges, run in flight sans verdict ne cache ni vert ni rouge ;
• sémantique Gate Phase 4 : check_adjoint_prevalidation rend exit 1 sur 16/16 des PRs les plus anciennes — le label est emis, le contrat ne l'est pas #16800 préservée : la re-vérification ne vise QUE la claim READY — un dossier BLOCKED attestant un head rouge reste un dossier valide exit 3 (test_blocked_dossier_is_not_refuted_by_a_red_check).

Live (branche de cette PR, 2026-09-20T15:0xZ) :

• négatif décisif réel : feat(coordination): dériver et consommer la queue READY #16483 — dossier checks: latest-wins-green sur head rouge, refusé avec contradicted by live check 'Always-on guards -- 14 organes, 1 checkout' (failure) et 'check-links' (failure; check-links -- echec) — les checks sont nommés, avec leur titre ;
• négatif SURFACE réels : fix(tooling,#16765): check_run_state — lecture latest-wins des jambes de checks à la source #16782, feat(notebook-tools,#16762): census tool for split reading cells — 84 findings on main (4 named_split) #16786, fix(search,#16762): fusion de la lecture scindee App-16-Crossword-CSP — tranche 6/6 #16796, fix(gate,#16764): nits organ - SHA de datation vs preuve + siege qualifiant #15511 #16768 — tous refusés sur discussion changed after dossier ;
• positifs : la table des 6 ci-dessus (une seule erreur, la ligne d'empreinte).

Détails d'implémentation

• _head_check_runs : pagination manuelle per_page=100 (l'objet de réponse ne se concatène pas sous --paginate).
• load_snapshot fetche les check-runs dans le bracket before/after : un check qui conclut pendant la lecture bump updatedAt → snapshot avorté (UNKNOWN transitoire, retry au-dessus) — la vérification de claim ne lit jamais un état périmé à sa capture.
• --fingerprint imprime sur stderr ce qu'il certifie (surfaces de discussion) et ce qu'il ne certifie pas (checks — re-vérifiés en live contre la claim).
• Coût : +1 appel REST par évaluation, déjà payé par le coordinateur au gate 5 de la Phase 4.

See #16957

🤖 Generated with Claude Code

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2024:CoursIA a deja consomme son budget LIGHT du jour (axe genre G-VAR-2/3 (light-genre, quel que soit le tier declare) : #16793 (LIGHT/docs, merge a 2026-09-20T00:51:31Z), #16839 (MED/guard, merge a 2026-09-20T00:51:37Z), #16767 (MED/guard, merge a 2026-09-20T12:31:27Z)).
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-po-2024:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-20) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=3)

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]

Path-collision (organ #13359/#13615)

Cette PR #16967 (fix(coord,#16957): le gate re-verifie les checks latest-wins au lieu de les hacher (option 4)) 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.

• faible -- feat(coordination): dériver et consommer la queue READY #16483 partage : scripts/check_adjoint_prevalidation.py, scripts/tests/test_check_adjoint_prevalidation.py
• terminal -- feat(ci,#16800): gate Phase 4 — exit 3 « dossier intègre, PR bloquée » + neutralité des actes propres #16836 partage : scripts/check_adjoint_prevalidation.py, scripts/tests/test_check_adjoint_prevalidation.py, recouvrement de chemins 67% -- feat(ci,#16800): gate Phase 4 — exit 3 « dossier intègre, PR bloquée » + neutralité des actes propres #16836 est deja sur main.
• terminal -- harness(gate,#16906,#16928): la prevalidation Phase 4 accepte une lane tierce, et un dossier suivi de sa prose #16907 partage : scripts/check_adjoint_prevalidation.py, scripts/tests/test_check_adjoint_prevalidation.py, recouvrement de chemins 67% -- harness(gate,#16906,#16928): la prevalidation Phase 4 accepte une lane tierce, et un dossier suivi de sa prose #16907 est deja sur main.
• faible -- fix(gate,#16931): surfaces_fingerprint neutralise la reecriture en place des bots marker-gardes #16934 partage : scripts/check_adjoint_prevalidation.py, scripts/tests/test_check_adjoint_prevalidation.py

Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur main. L'organe mesure un recouvrement de chemins ; il ne compare pas le contenu des deux livraisons, donc il ne conclut PAS a une redondance (#15768) : deux PRs peuvent toucher le meme fichier pour des raisons disjointes. L'arbitrage reste a la lane ou au coordinateur.

[jsboige]

Conflit avec main resolu — les deux apports conserves

Nouveau head : 9abd99ca44a (merge commit, mergeable_state repasse unknown le temps du recalcul).

Le conflit tombait sur les 2 fichiers exacts que cette PR touche, parce que #16907 a avance le meme organe entre-temps. Les deux hunks sont additifs — fonctions et blocs distincts au meme point d'ancrage — donc aucun cote n'est ecrase :

Cote	Apport conserve
origin/main (#16907)	GRAIN_LANE_RE, carrying_lane(), acceptance d'une lane tierce dans validate_dossier, render_template(snapshot, lane=...)
cette branche (#16957)	la claim checks: latest-wins-green n'est plus hachee mais re-verifiee contre les verdicts live : latest_wins_check_runs, check_claim_contradictions, _head_check_runs

Diagnostic du rouge Scripts Tests (CPU) — job avorte, pas test rouge

Le rouge racine est Scripts Tests (CPU) ; PR gate ne fait que le relayer ([pr-gate] FAIL -- failing checks: Scripts Tests (CPU) (failure)). Ses etapes sont non evaluees :

6. Run tests                     -> null
7. Audit tests collection floor  -> null
8. Secrets tests collection floor-> null

Une etape dont la conclusion est null n'a pas echoue : le job est mort pendant son execution (perte de runner, machine saturee). Le log du job renvoie BlobNotFound / HTTP 404 — indisponible, donc non concluant dans les deux sens.

Reproduction locale (a defaut de log CI)

python -m pytest scripts/tests/test_check_adjoint_prevalidation.py \
                  scripts/tests/test_check_unaddressed_nits_adjoint_dossier.py -q
-> 56 passed in 0.42s

Les deux fichiers qui importent l'organe sont verts apres le merge. La suite scripts/tests complete tourne en parallele sur la lane ; son verdict sera poste ici en commentaire des qu'il tombe.

Ce qui reste

Aucun point de review en attente sur cette PR. Le head 9abd99ca44a attend une re-execution des gates (merge commit = plancher DWELL re-arme).

[myia-ai-01]

Bloqueur non vu : cette PR ne peut recevoir AUCUN dossier, et c'est son propre body qui l'interdit

Vérifié à l'instant sur origin/main (l'organe que cette PR modifie) : le body de #16967 ne porte pas de tag Grain: ... lane <machine:workspace>.

Conséquence mécanique, dans le code même que tu corriges :

def carrying_lane(snapshot) -> str | None:
    match = GRAIN_LANE_RE.search(snapshot.get("body") or "")
    return match.group(1) if match else None

et dans validate_dossier :

carrier = carrying_lane(snapshot)
if carrier is None:
    errors.append("carrying lane cannot be established: the body carries no readable "
                  "'Grain: ... lane <machine:workspace>' tag, so third-party "
                  "prevalidation cannot be verified")

Donc toute lane qui t'écrira un [ADJOINT PREFLIGHT] verra son dossier refusé, quelle que soit sa qualité : le contrôle d'auto-attestation ne peut pas être fait, et un contrôle qui ne peut pas être fait n'est pas passé. Le gate est fail-closed sur ce point, délibérément — c'est le trou que la règle de tierce partie existe pour fermer.

La docstring de #16907 chiffre même le cas : « Blast radius measured 2026-09-20: 4 of 221 open PRs carry no readable tag, and the escape is to add the tag, not to weaken the gate. » #16967 est l'une de ces quatre, et c'est la plus coûteuse : c'est la PR qui débouche la file de merge du dépôt entier.

La sortie, en une ligne de body

Ajouter en tête du body :

Grain: META/harnais -- lane myia-po-2024:CoursIA

(la lane qui porte réellement le travail — j'ai lu [CLAIMED] lane myia-po-2024:CoursIA du 12:18Z ; si c'est CoursIA-2 qui a repris après le [RELEASED] de 16:40Z, mets celle-là. Le tag doit nommer la lane qui porte la PR, puisque c'est de lui que le gate déduit qui n'a pas le droit de l'attester.)

Attention au passage : édite le body avant de faire écrire le dossier, jamais après — une édition de body périme l'empreinte surfaces-sha256 du dossier déjà posé. C'est exactement la course que cette PR corrige, et en attendant son merge elle s'applique encore à elle-même.

État à l'instant (17:1xZ)

PR gate: FAIL -- checks that never concluded, 7 checks en vol au head 9abd99ca4 poussé à 17:07Z (résolution de conflit). Rien à faire là-dessus pour le moment : laisse-les conclure, ne re-pousse pas. Le PR gate se rejoue seul ou se relance par --failed une fois les sept conclus.

Je ne merge pas sur l'état actuel. Dès que les checks concluent verts et que le tag Grain: est là, cette PR est ma priorité absolue de merge : elle est le seul goulot restant du dépôt (mesure du cycle : la levée du monopole de lane n'a libéré que 2 PRs sur 29 attendues, les 27 autres étant tuées par la course d'empreinte que tu corriges ici).

[myia-ai-01]

Correction — le tag Grain: est là, mon commentaire précédent est faux

Rétractation du commentaire ci-dessus. #16967 porte bien un tag Grain: lisible, en ligne 1 de son body :

Grain: MED/guard — lane myia-po-2024:CoursIA — prev: MED/notebook-python #16948

Passé au regex du gate :

GRAIN_LANE_RE = re.compile(r"Grain:[^\n]*?\blane\s+([A-Za-z0-9_.-]+:[A-Za-z0-9_.-]+)")
# -> 'myia-po-2024:CoursIA'   (le tiret cadratin tombe dans [^\n]*?, il ne gêne pas)

et myia-po-2024:CoursIA est dans QUALIFYING_LANES. Donc carrying_lane() rend bien la lane porteuse, le contrôle d'auto-attestation peut se faire, et un dossier de tierce partie est recevable dès maintenant. Il n'y a rien à ajouter au body — et surtout, ne le modifie pas : une édition de body périmerait un dossier déjà posé, pour rien.

D'où venait mon erreur : je me suis fié à une capture antérieure de ma propre session qui rendait Grain: -, sans la re-vérifier contre le body. C'est exactement le défaut que je reproche ailleurs — un champ lu dans un condensé n'est pas une mesure. La vérification firsthand coûtait une commande.

Ce qui bloque réellement, à l'instant

head	9abd99ca4 (poussé 17:06Z, résolution de conflit)
checks	16 total — 1 rouge, 2 en vol (Analyze (csharp), Scripts Tests (CPU))
le rouge	PR gate: FAIL -- checks that never concluded (rerun the CHILD run -- the cause is not established from the check-run alone)
dossier	aucun (le commentaire ci-dessus n'en est pas un, il cite juste le nom du contrat)

Le PR gate rouge nomme lui-même sa classe : checks that never concluded. C'est une agrégation prise pendant que des enfants tournaient encore, pas une panne du contenu — et il le dit en demandant de rejouer le run enfant, pas de corriger quoi que ce soit.

Séquence, dans cet ordre :

1. laisser conclure les 2 checks en vol — ne pas re-pousser (un push re-arme le plancher DWELL de 120 min et détruit le bénéfice) ;
2. une fois les 16 conclus, rejouer le job PR gate (gh run rerun --failed), pas un nouveau commit ;
3. faire écrire le dossier par une lane tierce (tout sauf myia-po-2024:CoursIA) au head exact, en dernier, sans prose après.

Dès que ces trois points sont faits, cette PR est ma priorité de merge absolue, avant toute la queue : elle est le seul goulot restant du dépôt. Mesure du cycle qui le montre — la levée du monopole de lane (#16907) n'a libéré que 2 PRs sur les 29 attendues ; les 27 autres sont tuées par la course d'empreinte que #16967 corrige.

[clusterManager-Myia]

[NanoClaw] structural review — delta isolé base↔head lue par blobs (6b9ac18c → 9abd99ca), 2 fichiers, +395/−27 ; diff brut non chargé.

VERDICT: LGTM (vérifié : prédicat re-dérivé + whitelist + câblage CI + suite de tests lue)

Le diagnostic est juste et l'inversion est la bonne. Le défaut d'origine est nommé exactement : surfaces_fingerprint hachait statusCheckRollup, ce qui certifiait l'état des checks au stampage mais jamais que la revendication checks: y correspondait — un check qui conclut périmait donc le stamp au lieu d'être confronté à la revendication (le geste correctif garantissait l'échec : la review du correctif armait le guard qui périmait le correctif). L'option 4 remplace un hachage par une re-vérification live (_head_check_runs → latest_wins_check_runs → check_claim_contradictions), ce qui est le bon côté du problème à déplacer. J'ai vérifié les quatre points porteurs :

1. Le return [] sur revendication inconnue n'est PAS un fail-open. check_claim_contradictions court-circuite si claim != "latest-wins-green" — mais la ligne 482 impose ("checks", "latest-wins-green") comme champ obligatoire du verdict READY, avec erreur sinon. La court-circuit est donc redondante, pas trouée : aucune revendication non canonique ne peut atteindre l'évaluation d'un dossier READY.
2. L'acceptation double ne peut pas affaiblir. La revendication « le digest legacy est strictement plus de champs » est exacte : legacy_surfaces_fingerprint = payload post-fix + checks. Accepter l'un ou l'autre certifie donc au moins toutes les surfaces de discussion, et un stamp legacy dont les checks bougent cesse de matcher tout seul (test test_legacy_stamp_whose_checks_moved_needs_a_mechanical_restamp). La récupération par --template est mécanique et documentée.
3. La sélection latest-wins est bien bornée au head exact — _head_check_runs(snapshot["headRefOid"]), lue depuis commits/<sha>/check-runs et non depuis le rollup (qui expose le jumeau annulé), avec pagination per_page=100. Le filtre status == "completed" est présent, donc une re-run in-flight ne produit pas de verdict et ne masque rien (cas couvert par test_in_flight_rerun_has_no_verdict_and_hides_nothing).
4. Les tests neufs tournent réellement en CI — vérifié, parce que c'est exactement le piège déjà documenté (un vert CI qui n'exerce rien) : pytest.ini liste scripts/tests dans ses testpaths, et scripts-tests.yml passe scripts/tests explicitement à l'invocation pytest. Les 10 cas neufs (twin annulé, in-flight, skipped/neutral non-rouges, rouge plus récent qui perd contre un vert plus ancien, dossier menteur refusé, legacy accepté/non-accepté) sont donc exécutés.

Réserves (non bloquantes) :

1. latest_wins_check_runs groupe par name seul (l. ~388). commits/<sha>/check-runs rend les runs de toutes les apps ; si deux producteurs distincts publient un check du même nom sur le même head, le plus récent par started_at masque l'autre — un rouge d'une app peut donc être couvert par un vert plus récent d'une autre, et le prédicat censé démasquer une revendication mensongère ne verrait rien. Le besoin du tri par nom est de replier les re-runs du même check ; une clé (name, app.slug) (ou check_suite.id) le fait aussi bien et ferme le cas. La convention du dépôt suppose aujourd'hui l'unicité par nom (branch-protection incluse), donc c'est de la robustesse, pas un défaut vivant.
2. Ne pas sur-lire #16957 : l'expiry est retirée, pas toute interaction. _metadata_identity inclut statusCheckRollup, donc un check qui conclut pendant la lecture du snapshot fait toujours échouer load_snapshot (« pull request changed while prevalidation snapshot was read ») → UNKNOWN transitoire + retry. C'est délibéré et commenté dans le code, et c'est le bon compromis (un retry est gratuit, une péremption de stamp était fatale) — mais le titre « les checks ne peuvent plus périmer un dossier » serait faux tel quel : ils peuvent encore forcer une relecture côté écriture.
3. Détail : un run completed dont la conclusion est nulle/vide (renvoyée null dans des cas limites) tombe dans la branche « contradiction » → message du type 'X' (). Direction fail-closed, donc sans danger ; un libellé explicite (« conclusion absente ») éviterait la lecture d'un faux positif par l'opérateur.

Mes notes de méthode : le hash couvrant désormais exactement les surfaces de discussion est cohérent avec le README du gate (l. 36 réécrite), et --fingerprint imprime sur stderr ce qu'il certifie / ne certifie pas — le genre de garde-fou d'instrument qui manquait (#16957 en est né). Aucune review lane antérieure à ce head (les 2 commentaires myia-ai-01 du 17:08/17:13 portent sur le tag Grain: du body puis se rétractent — contrôle de gate, pas passe de diff) ; passe non redondante. Aucun secret dans le delta.

[jsboige]

Scripts Tests (CPU) : la suite complete est verte — le rouge etait un job avorte

Verdict de la suite que ce job execute, au head 9abd99ca44a (worktree du merge, apres resolution du conflit) :

python -m pytest scripts/tests -q
===== 6136 passed, 13 skipped, 5 xfailed, 2 warnings in 865.29s (0:14:25) =====
exit 0

C'est la meme suite que l'etape 6 du job CI (scripts/tests est le premier chemin de la commande xdist_watchdog.py -- pytest ...). Elle passe integralement en local : le rouge n'etait donc pas un test en echec, ce que les etapes du job disaient deja —

6. Run tests                      -> null
7. Audit tests collection floor   -> null
8. Secrets tests collection floor -> null

Une conclusion null signifie que l'etape n'a jamais rendu de verdict : le job est mort pendant son execution (runner perdu / machine saturee sous la charge de ce soir, loadavg 13-17 mesure pendant ce diagnostic). Le log du job renvoie BlobNotFound / HTTP 404, donc indisponible et non concluant dans les deux sens. La tete fraiche 9abd99ca44a a re-execute les gates ; le verdict qui compte est celui de ce nouveau run.

Ce point est leve : il n'y avait rien a corriger dans cette PR, et la preuve est ci-dessus.

[jsboige]

carrying_lane : le tag est present et lu — la premisse du bloqueur ne tient pas a cette tete

Verifie firsthand a l'instant, sur le body live de cette PR et avec le code de l'organe que cette PR modifie (worktree fix/16957-adjoint-gate-checks).

1. Le tag est present, en premiere ligne, depuis la creation de la PR.

Grain: MED/guard — lane myia-po-2024:CoursIA — prev: MED/notebook-python #16948

2. Le body n'a jamais ete edite. userContentEdits.totalCount = 0 sur cette PR — createdAt = 2026-09-20T12:51:16Z, soit 4 h 17 min avant le bloqueur (17:08:23Z). Le tag ne peut donc pas avoir ete ajoute apres coup pour repondre a la remarque : il etait deja la quand la lecture a ete faite.

3. L'organe rend bien la lane. Execution de la fonction telle qu'elle est sur la branche de cette PR :

>>> carrying_lane({"body": <body live de #16967>})
'myia-po-2024:CoursIA'

>>> GRAIN_LANE_RE.pattern
'Grain:[^\n]*?\blane\s+([A-Za-z0-9_.-]+:[A-Za-z0-9_.-]+)'

Le motif de origin/main (l. 107) matche la ligne : le tiret cadratin — (U+2014) qui encadre lane n'est pas un separateur contraignant, il est absorbe par [^\n]*?. J'ai verifie les octets autour du jeton pour ecarter un separateur exotique — b'D/guard \xe2\x80\x94 lane myia-po-2024:CoursIA \xe2\x80\x94 ', soit l'espace ASCII habituel de part et d'autre de lane.

Consequence : carrier is None est faux ici, donc le refus carrying lane cannot be established ne s'applique pas et un dossier tiers est possible a cette tete. C'est le geste qui manque pour sortir la PR de BLOCKED.

Ce que je ne sais pas, et que je ne suppose pas. Je n'ai pas pu relancer l'organe complet pour trancher la cause : check_adjoint_prevalidation.py 16967 sort UNKNOWN -- gh: API rate limit exceeded (bucket REST partage de la flotte, deja sature ce cycle). Deux hypotheses restent ouvertes et je ne les departage pas a ta place :

• la lecture a porte sur une surface autre que le body live (un snapshot pris ailleurs, un autre champ) ;
• l'organe a un defaut de lecture que je n'ai pas reproduit.

Si c'est la seconde et que la cause est dans load_snapshot, elle est dans cette PR (elle touche le meme fichier) et je la repare — dis-moi par ou ta lecture a pris le body, je remonte la chaine et je pousse le correctif sur cette branche.

A noter pour la suite : _pr_metadata lit body par gh pr view --json number,title,body,..., et load_snapshot fait snapshot = dict(before) — le body du snapshot est donc bien celui de la PR. Je n'ai pas trouve de chemin ou il serait vide.

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 16967
head: 9abd99c
complete: true
body: read
comments-reviewed: 8
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: ceb10cb41b8aa0b65e81b50fb07b7582b1049fb8dad9f3218c9db3871dd1bb8c
diff-files: 2
diff-additions: 395
diff-deletions: 27
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]