always-on-guards: le garde prev: ne retracte jamais son commentaire bloquant (19 faux mesures sur 4 PRs) #15372

Le garde prev: d'always-on-guards.yml poste un commentaire bloquant à chaque run rouge et n'en retire jamais aucun. Il n'a pas de geste de retraction, ni d'édition en place. Résultat mesuré ce jour : 19 commentaires « bloquant » sur 4 PRs, tous faux à l'instant de la mesure.

Ce n'est pas un défaut cosmétique. Le mur de commentaires est lu comme l'état courant — par les lanes, et par moi.

Mesure (2026-09-09T10:2xZ, firsthand)

Contrôle : le garde passerait aujourd'hui sur les quatre. variation_prev_guard.find_prev_target_pr_numbers exécuté sur les corps actuels rend exactement le prev: déclaré, et rien d'autre :

#15210: cibles=[14865]  declaree_ligne_Grain=14865
#15146: cibles=[14958]  declaree_ligne_Grain=14958
#15033: cibles=[15116]  declaree_ligne_Grain=15116
#15175: cibles=[14865]  declaree_ligne_Grain=14865

Confirmé en CI : run Always-on guards 34337879117 sur la branche de #15210 (2026-09-09T10:00:35Z) → success. Les 19 commentaires disent « bloquant » pendant que le garde dit vert.

Le mécanisme

always-on-guards.yml l.720 : le commentaire est posté par gh pr comment, qui crée systématiquement. Le marqueur <!-- vtr-prev-close-keyword --> est présent dans le corps — c'est exactement la primitive de recherche-et-mise-à-jour — mais rien ne le relit jamais. Il est décoratif.

S'y ajoute une course qui rend le commentaire faux sans qu'aucune lane n'y puisse rien : sur #15146 et #15033, la cible prev: a mergé après le tir (1 h 56 et 2 h 20). Le verdict était vrai à l'émission et faux ensuite ; seul un nouvel événement pull_request réévalue, et il n'y en a plus quand la PR attend.

Ce que j'ai écarté — pour que le prochain lecteur ne le refasse pas

J'ai annoncé deux fois à po-2024, par écrit, que le garde lisait le prev: de la payload initiale (payload gelée). C'est faux, et je le retire. Deux mesures le réfutent :

1. on.pull_request.types (l.57) contient edited : une édition de body ré-émet l'événement avec un corps frais.
2. Le parser lu sur les corps réels rend le prev: courant (bloc ci-dessus), pas l'ancien.

J'ai aussi écarté l'hypothèse « le scan porte sur tout le corps, donc citer son propre prev: en prose le ré-arme » : find_prev_target_pr_numbers scanne bien tout le corps, mais gt.mask_code_spans masque les spans de code, et les lanes citent leur ancien prev: entre backticks. Vérifié sur #15210, dont le corps cite prev: MED/notebook-python #15175 en l.55 : la cible n'est pas collectée. La discipline citation/déclaration est déjà en place — elle tient.

Il ne reste donc que l'absence de retraction. C'est tout le défaut, et il suffit à produire les 19 faux.

Le coût, deux fois payé

• po-2024 a diagnostiqué sur chore(notebooks,#14209): normaliser 174 cellules source str→list sur 44 notebooks #15146 que les commentaires du bot étaient le bloquant, et a demandé leur suppression par un mainteneur. Le vrai bloquant était Twin parity audit (#8057), 9 paires dérivées.
• Et moi, en lisant le même mur, j'ai fabriqué la thèse de la payload gelée et l'ai promise en issue. C'est ma faute autant que la leur : un organe qui laisse 19 affirmations fausses affichées produit des diagnostics faux, et il en produira d'autres.

Piège pour l'implémentation — le marqueur est déjà porté par des tiers

Sur #15146 seule, 4 commentaires contiennent <!-- vtr-prev-close-keyword --> sans être du bot : 3 de jsboige, 1 de myia-ai-01 — des lanes et moi citant le verdict verbatim dans nos comptes rendus. Une recherche naïve « le commentaire qui porte le marqueur » éditera donc un commentaire humain.

La recherche doit filtrer sur l'auteur (github-actions), pas sur le seul marqueur. Citer un marqueur en pose un.

Acceptance

1. Le garde recherche le commentaire portant <!-- vtr-prev-close-keyword --> et écrit par github-actions, et l'édite au lieu d'en créer un nouveau (gh api --method PATCH .../issues/comments/{id}).
2. Sur un run vert, si un tel commentaire existe, il est réécrit en état levé — horodaté, nommant le prev: désormais accepté. Un mur qui ne se ferme jamais n'est pas un signal.
3. Le filtre d'auteur est couvert par un test qui fait échouer une recherche marqueur-seul (le corpus chore(notebooks,#14209): normaliser 174 cellules source str→list sur 44 notebooks #15146 en fournit le cas réel).
4. Les 19 commentaires existants ne sont pas supprimés — pas d'effacement d'historique. Ils seront couverts par (2) au prochain run vert de chaque PR, ou laissés tels quels sur les PRs déjà mergées.

Ratissage : #10093 (l'incident fondateur du garde), #13475 (validation du vocabulaire du tag).