Constat
scripts/ci/update_stale_pr_branches.py (1100 lignes, suite de tests dediee, --apply, --max-updates, registre in-flight, detection de base empilee-vs-main, jamais de force-push) est invoque par rien. Verification :
$ git grep -n "update_stale_pr_branches" -- . | grep -v "^scripts/ci/update_stale_pr_branches.py:"
scripts/tests/test_update_stale_pr_branches.py:1,53,54,56,1142,1146
Seul son propre fichier de tests le nomme. Aucun workflow, aucun cron, aucun skill.
Et il n'a pas de mode sweep : --pr est un argument requis. Il sait traiter des PRs nommees, il ne sait pas les trouver.
Mandat
Mandat user du 2026-09-19 : « j'ai l'impression que le CI n'aide pas avec des MAJ de rebase successives qui sont mandatees et coutent enormement de temps a tout le monde : il faut qu'elles soient automatiques pour la plupart ».
Ce qui manque, precisement
Deux pieces, petites, en aval d'un organe deja construit et teste :
- Un pilote de sweep — enumerer les PRs ouvertes en retard sur leur base, filtrer celles qui sont eligibles, les passer a l'organe existant par
--pr. Ne PAS reimplementer la mise a jour : l'organe la fait deja, avec sa detection de base empilee et son registre in-flight.
- Un declenchement planifie — workflow cron,
--apply borne par --max-updates.
Taille du gisement (mesure 2026-09-19, 213 PRs ouvertes)
| Etat |
Nombre |
| CLEAN |
104 |
| BLOCKED |
79 |
| DIRTY |
12 |
| UNSTABLE |
9 |
| UNKNOWN |
9 |
Le sweep rattrape ~12 PRs, pas 100. Il faut le dire pour que personne ne survende l'organe : la valeur reelle n'est pas le nombre de PRs debloquees, c'est la suppression d'allers-retours. Aujourd'hui une PR en retard coute un commentaire, une session de worker dediee, un nouveau dossier exact-head. Le sweep remplace les trois par un run.
Contraintes a respecter (deja portees par l'organe, a ne pas defaire)
- Jamais de force-push. L'organe ne le fait pas ; le pilote ne doit pas l'introduire.
- Base empilee : une PR dont la base n'est pas
main se met a jour contre sa base. L'organe le detecte et le REPORTE (base_kind: main|stacked) ; le pilote ne fournit jamais de base.
- Peremption des verdicts : un
update-branch reecrit la tete, donc checks, reviews et dossier [ADJOINT PREFLIGHT] deviennent STALE. L'organe le signale deja (freshness: STALE, invalidated: [checks, reviews, dossier]). Le pilote doit rendre cette liste pour que l'adjoint sache quels dossiers refabriquer — sinon le sweep detruit du premachage en silence et on perd plus qu'on ne gagne.
- Le plancher DWELL ne doit PAS se re-armer sur un update-branch serveur legitime : c'est deja repare dans
merge_dwell.py (last_authoritative_committed_at). Un test de non-regression sur ce point est attendu dans le pilote.
- Borne de volume :
--max-updates obligatoire dans le workflow. Un sweep non borne qui touche 12 branches d'un coup perime 12 dossiers simultanement.
Acceptance
- Pilote qui enumere et delegue, sans reimplementer la mise a jour.
- Dry-run par defaut ;
--apply explicite.
- Sortie
--json listant, par PR : action, base_kind, freshness, invalidated.
- Workflow cron avec
--apply --max-updates <N>, N justifie dans le body de la PR.
- Test de non-regression : un update-branch serveur ne re-arme pas le plancher DWELL.
- Le body de la PR rapporte un run reel sur >= 3 PRs, avec la liste des dossiers perimes.
Ce que ce grain ne resout PAS
174 des 213 PRs ouvertes n'ont aucune review, et 104 sont CLEAN — mergeables sur-le-champ, sans le moindre conflit. Le goulot du depot est l'attestation tierce, pas le rebase. Ce grain supprime des allers-retours couteux ; il ne remplace pas la production de dossiers (cf #16907, qui retire le producteur unique du gate).
Constat
scripts/ci/update_stale_pr_branches.py(1100 lignes, suite de tests dediee,--apply,--max-updates, registre in-flight, detection de base empilee-vs-main, jamais de force-push) est invoque par rien. Verification :Seul son propre fichier de tests le nomme. Aucun workflow, aucun cron, aucun skill.
Et il n'a pas de mode sweep :
--prest un argument requis. Il sait traiter des PRs nommees, il ne sait pas les trouver.Mandat
Mandat user du 2026-09-19 : « j'ai l'impression que le CI n'aide pas avec des MAJ de rebase successives qui sont mandatees et coutent enormement de temps a tout le monde : il faut qu'elles soient automatiques pour la plupart ».
Ce qui manque, precisement
Deux pieces, petites, en aval d'un organe deja construit et teste :
--pr. Ne PAS reimplementer la mise a jour : l'organe la fait deja, avec sa detection de base empilee et son registre in-flight.--applyborne par--max-updates.Taille du gisement (mesure 2026-09-19, 213 PRs ouvertes)
Le sweep rattrape ~12 PRs, pas 100. Il faut le dire pour que personne ne survende l'organe : la valeur reelle n'est pas le nombre de PRs debloquees, c'est la suppression d'allers-retours. Aujourd'hui une PR en retard coute un commentaire, une session de worker dediee, un nouveau dossier exact-head. Le sweep remplace les trois par un run.
Contraintes a respecter (deja portees par l'organe, a ne pas defaire)
mainse met a jour contre sa base. L'organe le detecte et le REPORTE (base_kind: main|stacked) ; le pilote ne fournit jamais de base.update-branchreecrit la tete, donc checks, reviews et dossier[ADJOINT PREFLIGHT]deviennent STALE. L'organe le signale deja (freshness: STALE,invalidated: [checks, reviews, dossier]). Le pilote doit rendre cette liste pour que l'adjoint sache quels dossiers refabriquer — sinon le sweep detruit du premachage en silence et on perd plus qu'on ne gagne.merge_dwell.py(last_authoritative_committed_at). Un test de non-regression sur ce point est attendu dans le pilote.--max-updatesobligatoire dans le workflow. Un sweep non borne qui touche 12 branches d'un coup perime 12 dossiers simultanement.Acceptance
--applyexplicite.--jsonlistant, par PR : action,base_kind,freshness,invalidated.--apply --max-updates <N>, N justifie dans le body de la PR.Ce que ce grain ne resout PAS
174 des 213 PRs ouvertes n'ont aucune review, et 104 sont CLEAN — mergeables sur-le-champ, sans le moindre conflit. Le goulot du depot est l'attestation tierce, pas le rebase. Ce grain supprime des allers-retours couteux ; il ne remplace pas la production de dossiers (cf #16907, qui retire le producteur unique du gate).