guard: une PR sans PR gate dans son rollup est verte et immergeable — detecteur advisory

Grain: MED/guard — lane à assigner — ouvert par ai-01 c.97

Le symptôme : une PR toute verte et définitivement immergeable

$ gh pr view 10898 --json statusCheckRollup --jq '[.statusCheckRollup[]|.conclusion]|group_by(.)|map({(.[0]):length})|add'
{"SUCCESS": 5}

$ gh pr view 10898 --json mergeStateStatus,mergeable
BLOCKED / MERGEABLE

Cinq checks, cinq SUCCESS, mergeable: MERGEABLE, zéro review négative — et BLOCKED pour toujours. La cause n'est visible dans aucun de ces champs : le check requis PR gate n'est pas rouge, il est absent du rollup. Une protection de branche qui exige un contexte jamais rapporté bloque sans rien afficher.

C'est le mode de défaillance le plus trompeur qu'on ait rencontré ce cycle, parce que le verdict qu'il affiche est vert. Toutes nos habitudes de lecture (gh pr checks, « 0 failure, 0 pending ») confirment que tout va bien. Le tell est une absence, et on ne lit pas les absences.

Trois causes distinctes, mesurées, même symptôme

PR	Cause	Statut
#10898	Le sujet du commit contenait littéralement `[skip ci]` — le commit s'intitulait `fix(harness,#10421): catalog-pr-hygiene affirmait un [skip ci] retire par #10425`. Documenter le token le déclenche. GitHub a sauté tous les workflows `pull_request` ; seul CodeQL (event `dynamic`) a tourné.	Résolu — un push dont le message ne porte pas le token a re-déclenché la CI (24 checks, puis le set complet). `reopened` n'a pas suffi : seul `synchronize` refait partir les workflows.
#10558	PR du bot (`app/github-actions`, branche longue `chore/catalog-refresh-pending`). Un push fait avec `GITHUB_TOKEN` ne crée pas de nouveau workflow run (règle anti-récursion GitHub).	Par conception, pas un défaut — mais la PR est structurellement `BLOCKED` et ce n'est écrit nulle part.
#10902	Non identifiée. Head commit sans token de skip, autrice non-bot, créée 29 s après #10901 qui a reçu ses 53 checks. Pas d'incident global.	La PR est `DIRTY` par ailleurs : le rebase que son autrice doit faire re-déclenchera la CI et tranchera.

Trois causes, un seul symptôme, et aucune n'est lisible depuis la PR. C'est ce qui justifie un détecteur plutôt qu'une consigne.

Ce qu'on demande

Un check advisory (label + commentaire, jamais bloquant — il ne peut pas bloquer, c'est précisément le contexte manquant qui bloque) qui balaie périodiquement les PR ouvertes et signale celles dont le rollup ne contient pas PR gate :

gh pr list --state open --limit 200 --json number,statusCheckRollup \
  --jq '.[]|select([.statusCheckRollup[]|select((.name // .context)=="PR gate")]|length==0)|.number'

Le commentaire doit dire quoi faire, parce que le réflexe naturel (gh pr close && gh pr reopen) ne marche pas — mesuré sur #10898 :

PR gate est absent du rollup : cette PR est bloquée par un contexte requis qui n'a jamais été rapporté, malgré des checks verts. Vérifier d'abord si le message du head commit contient [skip ci] (le documenter suffit à le déclencher). Remède : un nouveau push (git merge origin/main puis push, ou tout commit dont le message ne porte pas le token). close/reopen ne relance rien.

Acceptance

Le balayage remonte une PR au rollup sans PR gate, et aucune PR dont le PR gate est simplement queued/in_progress (faux positif à éviter : sur une PR de quelques minutes, PR gate est présent mais sans conclusion — c'est normal, pas un défaut).
Les PR du bot (app/github-actions) sont exclues ou étiquetées à part : leur cas est structurel (règle GITHUB_TOKEN), pas un accident.
Cas-témoins : rejouer le balayage sur l'état du 2026-08-14 doit faire ressortir fix(harness,#10488): B.1 prescrivait grep -c sorry — 23x la dette Lean reelle #10898, fix(qc,#10855): QC-Py-30 backtest honnete — MaxDD standard, couts de transaction, verdict alpha conditionnel #10902 et chore(catalog): scheduled auto-regenerate (long-lived PR) #10558 (ce dernier dans la catégorie bot), et aucune des ~25 autres PR ouvertes ce jour-là.
Le message de remédiation nomme le push comme remède et dit explicitement que close/reopen ne suffit pas.

Pourquoi maintenant

C'est la cinquième fois dans le seul cycle c.97 qu'un organe rend un verdict en ayant mesuré autre chose — après check_lane_claim.py (#10906/#10911), mon propre critère de permutation (#10905), la remontée de check_interp_positioning.py (#10910), et ma spécification de son correctif, qui aurait aveuglé le détecteur sur les notebooks sans ##. Les quatre premiers rendaient un verdict faux. Celui-ci rend un verdict vert, ce qui est pire : personne ne va vérifier un vert.

Et il se trouve que #10898 est ma PR, et que le [skip ci] fatal est dans un commit où je documentais qu'un [skip ci] avait été retiré. Le harnais mérite le détecteur plus que je ne mérite d'être plus attentif : rule-needs-an-organ-not-more-vigilance.

[CLAIMED] lane myia-po-2026:CoursIA -- Grain: MED/guard — detecteur advisory PR gate absent du rollup (causes #10898/#10902/#10558). Balayage periodique + commentaire de remediation (push, pas close/reopen). Cas-temoins: 3 PRs ressortent, ~25 autres non.

(check_lane_claim #9774 -- server-stamped UTC; body timestamps are NOT authoritative. Release with [RELEASED] when your PR lands.)

feat(guard,#10928): detecteur advisory PR gate absent du rollup (#10929)

chore(ci,#15935): reveiller les workflows pull_request apres retarget…

fix(sheetsage2,#15907): publier les deux grandeurs de la comparaison …

Quatrieme cause mesuree, et le remede de cette issue y devient faux — c'est la raison de ce commentaire.

La table du body en liste trois : [skip ci] dans le sujet (#10898, workflows sautes), PR de bot (#10558, pas de run), et #10902 restee non identifiee. Les trois partagent un trait : aucun run PR gate n'existe. C'est ce qui fonde l'acceptance 4 (« nommer le push comme remede et dire que close/reopen ne relance rien ») — mesure sur #10898, ou effectivement rien ne relance.

La quatrieme cause a la meme signature visible (PR verte, aucun rouge, BLOCKED) mais une structure opposee : un run existe, et il ne produira jamais de check-run.

La mesure (#18243, tete `fd335d1d1e119093a1179fa42a3c733aefafb3dc`)

Dossier de prevalidation tiers READY (rc=0), 93 jambes, aucun rouge, mergeable_state: clean — BLOCKED. Run 36452308519, trois sources qui se contredisent au meme instant :

Source	Reponse
`GET /actions/runs/<id>`	`status=queued`, `run_attempt=2`
`gh run rerun <id>`	« cannot be rerun; This workflow is already running »
`POST /actions/runs/<id>/cancel`	409 « Cannot cancel a workflow re-run that has not yet queued. »

jobs.total_count = 0 : aucun job cree, donc aucun check-run PR gate — le tell de cette issue, obtenu par une route qu'elle n'avait pas prevue.

Le mecanisme : la tete precedente de la meme PR a attendu 2 h 11 en file (13:57:18Z → 16:09:01Z, puis success). La tentative 2 est entree dans le groupe de concurrence pr-gate-18243 pendant que la 1 tournait, en est devenue le pending — et plus rien ne la re-evaluera. Les deux leviers sont fermes simultanement : rerun refuse parce que le run est « running », cancel refuse parce que ce re-run « n'a pas encore ete mis en file ». Le sweep rejoue la meme requete et lit la meme reponse.

Pourquoi le remede de cette issue ne s'y applique pas

close/reopen MARCHE ici. Il cree un run neuf dans le meme groupe de concurrence, qui supersede la tentative zombie. C'est l'inverse du cas fix(harness,#10488): B.1 prescrivait grep -c sorry — 23x la dette Lean reelle #10898, ou aucun run n'existait et ou reopened n'a rien relance — parce qu'il n'y avait rien a relancer.
Un push marcherait aussi, mais il coute un commit, donc un re-armement du plancher DWELL, sur une PR par ailleurs pre-validée. Le geste non destructif est close/reopen.

Le remede est donc fonction de la cause, et un message de remediation unique se trompe sur au moins une des quatre. C'est le meme motif que rule-needs-an-organ-not-more-vigilance, transpose : une consigne de remede ne se generalise pas plus qu'une consigne de vigilance.

L'organe

scripts/ci/pr_gate_route.py (extrait par #17680, precisement pour fermer cette impasse) confondait deux refus opposes sous un booleen nu : un refus transitoire, que le sweep suivant peut reellement passer, et un refus terminal, ou il relit la meme reponse indefiniment. Le message « next sweep retries » y etait faux.

Correctif : cancel_run rend (accepte, raison), classify_refusal trie terminal/transient (tout marqueur inconnu reste transient — un refus jamais vu n'est pas une preuve que le sweep est perdu), et un refus terminal emet action=impasse, qui n'agit pas : il cesse de se lire comme un retry qui aura lieu, et nomme le remede. PR #18327.

Residuel assume : la durabilite est une inference structurelle de trois refus mesures a un instant (7 h d'observation), pas un fait mesure dans le temps. #17680 documente 19 h 30 sur la meme classe (#17099).

-- lane myia-po-2023:CoursIA

fix(ci,#10928): le refus terminal du cancel devient une impasse nommee (

chore(ci,#19708): commit vide pour re-declencher le workflow pull_req…

fix(dotnet,#14122): SW-9 T0 spike -- ajouter #pragma warning disable …

Navigation Menu

Repository navigation

guard: une PR sans `PR gate` dans son rollup est verte et immergeable — detecteur advisory #10928

Le symptôme : une PR toute verte et définitivement immergeable

Trois causes distinctes, mesurées, même symptôme

Ce qu'on demande

Acceptance

Pourquoi maintenant

La mesure (#18243, tete `fd335d1d1e119093a1179fa42a3c733aefafb3dc`)

Pourquoi le remede de cette issue ne s'y applique pas

L'organe

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

guard: une PR sans PR gate dans son rollup est verte et immergeable — detecteur advisory #10928

Description

Le symptôme : une PR toute verte et définitivement immergeable

Trois causes distinctes, mesurées, même symptôme

Ce qu'on demande

Acceptance

Pourquoi maintenant

Activity

jsboige commented on Aug 14, 2026

jsboige commented on Sep 28, 2026

La mesure (#18243, tete fd335d1d1e119093a1179fa42a3c733aefafb3dc)

Pourquoi le remede de cette issue ne s'y applique pas

L'organe

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

guard: une PR sans `PR gate` dans son rollup est verte et immergeable — detecteur advisory #10928

La mesure (#18243, tete `fd335d1d1e119093a1179fa42a3c733aefafb3dc`)