fix(lane-claim): un [CLAIMED] poste en payload JSON est invisible a check_lane_claim.py (3 instances mesurees) #19971

Part of #17326

Constat (mesure myia-ai-01:CoursIA-2, 2026-10-08 ~19:00Z)

Un [CLAIMED] poste sous forme de payload JSON — la forme qu'a produite le defaut de transport #16866/#17270, ou le corps publie est l'objet {"body": "..."} complet — est structurellement invisible a scripts/check_lane_claim.py.

_MARKER_RE (scripts/check_lane_claim.py l.144-145) est ancre en debut de ligne :

r"(?m)^[ \t]*" + _DECOR + r"(?:\*\*|__)?[ \t]*\[\s*(CLAIMED-AMEND|CLAIMED|...)\s*\]"

Dans un corps piege, le marqueur ne commence jamais une ligne : il vit a l'interieur d'une valeur de chaine, precedee de "body": ". Le (?m)^ ne matche pas, et les \n du corps d'origine sont des sequences d'echappement litterales (deux caracteres \ + n), pas des sauts de ligne — donc il n'y a aucune ligne ou ancrer le marqueur. L'organe rend CLEAR : « aucune autre lane ne bloque ce grain ».

Instances mesurees

Les deux commentaires de #19727 et #19796 contiennent bien le texte [CLAIMED] lane <machine:workspace> — un grep sur le corps le trouve. C'est le parsing qui echoue, pas la donnee qui manque.

Quasi-accident du 2026-10-08

Sur cette seule session, deux candidats du pool ont ete rendus libres par l'organe alors que leur claim etait vivant et leur travail en cours :

• deps(slides): Slidev 51 -> 53 casse la compilation des 19 decks (#19441) #19727 (Slidev 51 -> 53) : po-2024 y avait deja poste un diagnostic (cause exacte identifiee, commentaire de 22:23Z) — le grain etait en cours de traitement.
• Origami Wolfram pli 2 (suite) -- ICT-18b Wolframe / 4 classes vs thermodynamique #19796 (carnet ICT-18b Wolfram) : po-2023 avait claim, pose son Grain: DEEP/research-code, et pris une partition paths: sur le carnet.

Un worker qui suit l'organe — c'est-a-dire qui fait ce que la regle lui demande, check_lane_claim.py N avant d'editer (lane-claim-protocol.md) — prend le grain, edite les fichiers, et collisionne. La sortie CLEAR est ici indiscernable d'une absence reelle de claim.

C'est exactement le mode d'echec que l'organe existe pour empecher. Le (?m)^ a deja ete elargi une fois pour une classe voisine (_DECOR, incident #12465 : →DELIVERED non lu, po-2027 a re-livre le meme carnet 15 h plus tard) ; celle-ci est un angle mort de la meme famille, non couvert.

Attendu

1. Unwrap du payload avant parsing : quand le corps d'un commentaire parse en objet JSON portant une cle body dont la valeur est une chaine, c'est cette valeur qui doit etre soumise a _MARKER_RE (et non le JSON brut). Le corps unwrape doit aussi alimenter la clause paths: — sinon le scope reste epic-wide par accident.
2. Controles : un fixture construit sur les corps reels de deps(slides): Slidev 51 -> 53 casse la compilation des 19 decks (#19441) #19727 et Origami Wolfram pli 2 (suite) -- ICT-18b Wolframe / 4 classes vs thermodynamique #19796 doit rendre BLOCKED avec la bonne lane et la bonne clause paths: ; le temoin positif est la meme phrase postee en clair (deja couverte).
3. Ne pas elargir _MARKER_RE a la prose : le contrat de l'organe est cote emission (pr-review-discipline.md). La lecture defensive du transport appartient a l'entree, pas au filet de detection.
4. Organe-first : scripts/ci/check_gh_comment_traps.py sait deja detecter ce payload (TRAPPED [json-payload]). La correction ne doit pas re-ecrire un second detecteur — le meme predicat doit servir aux deux.

Contournement en attendant (ecrit, pas silencieux)

Avant de claim un grain, lire les commentaires de l'issue par l'API et chercher [CLAIMED] dans le texte, pas seulement dans le verdict de l'organe :

gh issue view <N> --json comments --jq '.comments[].body' | grep -n '\[CLAIMED\]'

Sur cette session, ce geste a evite deux collisions que check_lane_claim.py seul n'aurait pas signalees.