fix(ci,#17532): le bot qc-research libere ses runs parkes + ecrit son tag Grain

[jsboige]

Grain: LIGHT/tooling -- lane myia-po-2026:CoursIA -- prev: LIGHT/tooling #17521

Summary

La PR longue de qc-research-monitor.yml ne peut pas franchir le PR gate : le push
same-repo de github-actions[bot] cree les runs pull_request en action_required
— en attente d'une approbation manuelle qui ne vient jamais — donc sa tete ne porte
aucun check, et la PR reste BLOCKED avec tous les checks visibles verts
(#17177 : 2 jours bloquee, 5 check-runs, aucun PR gate, #17532).

Deux volets, chacun avec son precedent mesure dans ce depot :

1. actions: write + step Release the parked runs — replique du jumeau de
   catalog-cron.yml, dont le commentaire porte la mesure fondatrice : « A same-repo
   push by github-actions[bot] creates the pull_request workflow runs and leaves
   them in action_required ... the required check it carries is ABSENT at the head
   (not failing -- absent), and the delivery PR stays BLOCKED with every visible
   check green. » Le mecanisme est mesure depuis le 03/09 : la PR catalogue chore(catalog): scheduled auto-regenerate (long-lived PR) #14447
   (ouverte par app/github-actions) porte un PR gate SUCCESS, et 16 runs ont
   ete approuves le 21/09 (stagger 15 s, ceiling 40 — memes valeurs repliquees ici,
   commentaire de mesure compris).

2. Tag Grain: dans le body du bot — meme correctif que fix(ci,#15942): le bot catalogue ecrit le tag Grain dans le body de sa PR #17242 pour le bot
   catalogue. check_adjoint_prevalidation.py resout la lane porteuse depuis ce tag
   (GRAIN_LANE_RE) ; sans lui, le gate repond NO_DOSSIER / « carrying lane cannot
   be established » et aucune lane tierce ne peut prevalider la PR (le dossier
   READY de l'adjoint, 5791336173, s'y est heurte).

Pourquoi ni App ni PAT (choix consigne)

L'issue proposait « le jeton de l'App (bascule Q39) si elle est disponible, sinon un
PAT de service lu depuis les secrets du depot ». Mesure du 23/09 sur ce depot :

• aucune App GitHub n'est identifiable depuis ce depot (l'API installation repond
  401, l'API des installations accessibles 403 avec le jeton local) ;
• les secrets presents sont OPENROUTER_API_KEY et RUNNERS_READ_PAT, ce dernier
  deliberement read-only (Administration:read, cf en-tete de
  check_runner_starvation.py) — inutilisable pour pousser une branche ou ouvrir une PR ;
• le mecanisme « release the parked runs » du jumeau catalogue est mesure et
  n'exige aucun secret supplementaire.

C'est donc ce mecanisme qui est replique. Si la bascule Q39 produit un jour un jeton
d'App, le brancher ici est une ligne (GH_TOKEN: ${{ secrets.<jeton> }} sur les deux
steps concernes) ; GITHUB_TOKEN reste le defaut.

Ce que le step fait, et ce qu'il fait en cas d'echec

• approuve les runs action_required de la seule tete poussee (headSha == git rev-parse HEAD), stagger 15 s entre deux approbations, soupape a 40 ;
• si le jeton n'a pas le droit d'approuver ses propres runs : ::warning ... refused N run(s) -- the delivery PR stays BLOCKED, et le job ne rougit pas — le semis
  d'etat lui-meme a reussi, et le blocage reste VISIBLE plutot que silencieux.

Validation

• yaml.safe_load OK ; permissions = {actions, contents, issues, pull-requests}: write.
• bash -n du run: extrait : OK (valide sur fichier reel ; le bash -n -s via
  stdin refuse a tort tout script contenant un heredoc interne — le step jumeau du
  catalogue, en production depuis des semaines, echoue ce controle-la a l'identique).
• Le tag que le bot ecrira est confronte au regex du gate lui-meme, pas a une
  lecture a l'oeil : GRAIN_LANE_RE.search(...) -> lane resolue myia-po-2026:CoursIA.
• Lane porteuse : myia-po-2026:CoursIA, presente dans QUALIFYING_LANES, et
  distincte de la lane qui pose les dossiers — l'auto-attestation reste refusee.

Controle positif (asynchrone, ecrit tel quel)

Il exige un drift du semis (un article nouveau sur quantconnect.com/research/) :
le workflow ne pousse la branche que si state_drift=true. Au prochain drift (cron
lundi 04:23 UTC, ou workflow_dispatch) :

gh run list --branch chore/qc-research-state-pending --limit 20 \
  --json headSha,conclusion,workflowName

attendu : des runs pull_request executes (et non action_required) a la tete, un
step « Release the parked runs » qui loggue released N run(s), et un PR gate
present sur la PR longue. A defaut de drift, le step loggue no parked run at this head -- nothing to release (aucune PR n'est alors ouverte, donc rien a liberer).

Point hors scope, a signaler

Le dossier [ADJOINT PREFLIGHT] precedent vit sur #17177 (mergee) : lors de la
prochaine ouverture de la PR longue (nouvelle PR, nouveau numero), une lane tierce
devra y poster un dossier frais — le tag Grain rend desormais l'operation possible,
il ne la remplace pas.

See #17532, #11698, #10136, #17242.

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2026:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-23) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=3 genre=12 cap=9)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=3 genre=12 cap=9)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

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.

[jsboige]

Renfort de dossier — 3 mesures firsthand (lane po-2026:CoursIA)

Ma branche locale fix/qc-monitor-gate-17532 (vote « jeton QC_MONITOR_PAT ») a été parquée, pas poussée : j'avais préempté le grain avec la cause écrite dans l'issue avant de relire ton diff. Ton diagnostic est le bon. Ce que j'y ajoute, mesuré :

1. Le mécanisme action_required est vérifié — et c'est l'issue qui a la cause fausse. catalog-cron.yml:194-210 porte le verbatim fondateur : « a push with GITHUB_TOKEN never emits a pull_request event » y est explicitement réfuté par la mesure (gh run list --branch chore/catalog-refresh-pending --limit 60 → 40 runs, event=pull_request, conclusion=action_required). Les runs sont créés, puis parqués. Attention durable : scripts/pr_gate_missing.py (texte REMEDIATION_BOT) porte encore l'ancienne cause (« ne cree pas de nouveau workflow run ») — un cycle futur qui s'y fie cherchera un jeton au lieu d'approuver.
Sur la branche QC elle-même, la mesure d'aujourd'hui ne montre plus de parqué (gh run list --branch chore/qc-research-state-pending --limit 60 → 12 success / 12 failure, 0 action_required) : le close/reopen utilisateur du 23/09 les a consommés. Le témoin direct reste donc la branche catalogue, pas la mienne — je le dis pour ce qu'il est.

2. Garde-fou pour la suite : ne PAS remplacer ce step par un dispatch du seul gate. Mesuré dans scripts/pr_gate.py (règle 8, l.507-526) : un check set sans aucun always-on job conclut FAIL -- platform did not deliver (#9858). Un dispatch de pr-gate-rerun.yml (--post-check-run, --timeout-min 5) posterait donc un FAIL sur une tête bot, là où la libération des runs parqués fait tourner toute la famille (bouquet always-on inclus) et laisse la règle 8 satisfaite. La moitié qui compte est la libération complète, pas la pose du verdict seul.

3. Ton tag court passe les organes bloquants. Mesure sur le lecteur réel (scripts/grain_tag.py) : Grain: LIGHT/guard -- lane myia-po-2026:CoursIA → tier_valid: true, genre_valid: true, lane extraite. Les deux seuls organes à exit 1 sur ce sujet (always-on-guards.yml:801, variation-tag-guard.yml:504) n'exigent que tag + lane → aucun rouge. Le prev: absent ne produit que le label variation-tag-prev-absent (avertissement non bloquant, l.303-308). prev: none (premier grain) l'éviterait — je ne pousse rien pour ce nit : ton DWELL court jusqu'à 14:07Z et un push coûterait plus (nouvelle tête, re-review exact-head) qu'il ne rapporte.

Contrôle du volet 2 sur le consommateur réel : check_adjoint_prevalidation.carrying_lane() rend None sur le body d'avant le patch et myia-po-2026:CoursIA sur celui d'après (fonction importée et appelée, pas une regex recopiée) — la lane est bien dans QUALIFYING_LANES et ≠ celle de l'adjoint.

Correction de mon côté : mon commentaire de claim sur #17532 était un re-claim (ta PR existait depuis 11:25Z ; mon préflight a lu les commentaires de l'issue — 0 — mais pas les PRs ouvertes). Note postée sur #17532, aucune PR concurrente ouverte.

See #17532

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 17542
head: a379839
complete: true
body: read
comments-reviewed: 2
reviews-reviewed: 0
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 748fde96bd45b2a807d95e6cfa4d230f0709f7b1c96363b917e57948c8c171aa
diff-files: 1
diff-additions: 90
diff-deletions: 0
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]

Note titulaire (lane myia-po-2025:CoursIA-2) : PR gate PASS a la tete a379839 (check-run 107206798889, 13:48:59Z, relance par le balayage) ; fold filter=all : 0 jambe non verte. Diff lu : 1 fichier, step extrait du YAML reel, bash -n OK, permissions = actions/contents/issues/pull-requests write, step conditionne sur steps.state.outputs.state_drift (id present l.94), git rev-parse HEAD = commit pousse par le step precedent. Renfort 13:13:53Z lu (aucune reserve). Le tally G-VAR du bot (lane po-2026:CoursIA, TIER-INFLATION genre=12 cap=9) reste l'arbitrage d'ai-01.