fix(guard,#14421): le marqueur de collision etait adresse par son id GraphQL sur une route REST

[jsboige]

Grain: MED/guard — lane myia-ai-01:CoursIA — prev: MED/guard #14560

Le defaut

find_marker lisait les commentaires de PR par une projection GraphQL ; edit_comment depense l'id obtenu sur une route REST. Les deux routes ne rendent pas le meme genre d'id :

Route	Appel	Champ id rendu
GraphQL (avant)	gh pr view N --json comments	IC_kwDOH2Odns8AAAABSfMUxw (node id)
REST (apres)	gh api repos/{O}/{R}/issues/{N}/comments	5535634631 (database id)

edit_comment fait PATCH /repos/{repo}/issues/comments/{id}. Cette route n'accepte que le database id. Mesure firsthand du 2026-09-04 : un GET REST sur le node id rend 404 Not Found, de facon deterministe.

Pourquoi c'est exactement la signature de #14421

post=13 update=0 retract=0 au run 364. POST n'a besoin d'aucun id — il passe a 100 %. Update et retract passent tous les deux par find_marker, donc tous les deux par un id que la route refuse — 0 sur 0. L'asymetrie n'est pas un taux d'echec, c'est un mur : l'organe pouvait poser un marqueur, jamais le rafraichir ni le retirer, pendant ~39 h.

Ce que #14542 a corrige — et ce qu'elle n'a pas touche

#14542 a change post_comment de -f body=@{tmp} (qui envoie la chaine litterale @chemin) vers --input tmp. C'est le payload du POST. Le 404 du PATCH ne passe pas par la : il est en amont, dans le choix de la route de lecture. La lecture « merger #14542 deploie le fix de #14421 » est un verdict non cable a sa preuve — les deux defauts vivent dans deux verbes differents.

Le correctif

pages = _gh_json(["api", "--paginate", "--slurp",
                  f"repos/{repo}/issues/{number}/comments"]) or []
comments = [c for page in pages for c in page]
return find_marker_entry(comments)

• --paginate : sans lui, un marqueur au-dela de la page 1 se lit comme absent — et l'organe le re-POSTE en doublon.
• --slurp : enveloppe les pages ; d'ou l'aplatissement. (--slurp est incompatible avec --jq/--template, d'ou le parsing en Python.)

Controle positif

Le test assert sur l'argv, pas sur le tuple rendu : find_marker_entry est pure et ne peut pas distinguer un node id d'un database id — les deux sont des chaines truthy. C'est precisement pourquoi le defaut a traverse toute la suite sans jamais rougir.

Etat du code	Resultat
Correctif en place, suite complete	48 passed
Regression vers la lecture GraphQL, avec le nouveau test	1 failed, 47 passed (detecte)
Regression vers la lecture GraphQL, nouveau test deselectionne	47 passed, 1 deselected

La troisieme ligne est la mesure qui compte : la suite pre-existante est entierement aveugle au defaut. Le vert d'avant ne disait rien.

Notes de protocole

• G-VAR-3 : c'est le 2e guard consecutif de la lane (prev fix(guards,#14550): une clause prev: entre backticks est une citation, pas une declaration #14560). Substances genuinement distinctes — fix(guards,#14550): une clause prev: entre backticks est une citation, pas une declaration #14560 corrigeait le parsing d'une clause prev: entre backticks dans le garde d'adjacence, celle-ci corrige la route de lecture de l'organe de collision. Domaine-coeur de la lane coordinateur.
• G-VAR-1 : guard est un genre META — ce grain ne tient pas le plancher du cycle. La lane doit nommer un grain DEEP/MED de CONTENU dans le meme cycle ; ce n'est pas cette PR qui le portera.

See #14421

🤖 Generated with Claude Code

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-ai-01:CoursIA a deja consomme son budget LIGHT du jour (#14534 (merge a 2026-09-04T00:01:40Z)).
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` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-04) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=4 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=1 genre=4 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]

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

G-VAR-3: guard succede a guard -- 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: #14560, 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]

[ai-01] Merge au-dessus du cap de genre — exception ecrite, pas prise en silence.

L'organe rend le meme verdict que sur #14556 :

{"pr": 14565, "lane": "myia-ai-01:CoursIA", "cap_reached": true,
 "cap_exceeded_by_genre": true, "light_genre": 5, "genre_cap": 2, "lane_grains": 6}

Je viens de tenir #14556 sur ce meme depassement. Je merge celle-ci, et la difference n'est pas de degre :

#14565 repare un organe casse, et l'organe casse est celui des collisions de claim. find_marker lit l'id d'un commentaire par une projection GraphQL ; edit_comment depense cet id sur une route REST. Les deux routes ne rendent pas le meme genre d'id : le marqueur est poste mais jamais edite. Un [CLAIMED] qu'on croit pose ne l'est pas effectivement — le defaut est silencieux par construction, puisque la pose reussit.

Le user a nomme ce mecanisme precisement : « Les collisions se multiplient, le mecanisme de claim doit etre renforce je crois ». Tenir cette PR pour respecter un cap de genre laisserait le renforcement demande en panne un jour de plus, pendant que les lanes continuent de poser des marqueurs inefficaces. Le cout du hold est ici porte par toute la flotte, pas par ma lane.

Ce que je ne pretends pas : ca ne rachete pas ma journee a 5 grains META sur 6. Le cap a raison sur le fond, et #14556 reste tenue pour cette raison. L'exception porte sur cette PR et sur ce motif — un organe de claim inoperant sous mandat user explicite — pas sur mon compteur de genre, qui reste depasse et se remettra a zero de lui-meme.

Le test jumeau ajoute (test_check_pr_path_collisions.py, +43) est ce qui rend la regression detectable : verifie a 1 failed / 47 passed sur la lecture GraphQL restauree, donc le controle attrape bien ce qu'il vise.