guard(pr_close_keyword): les citations backtiquées fixes/closes #N déclenchent le garde (4e axe #14550)

[jsboige]

Mesure firsthand 2026-09-05 pendant la vérification de l'acceptance #14703 (item 4 : « vérifier que le même repli ne casse pas le masquage de pr_close_keyword_guard.py, qui partage la logique de spans »).

La prémisse est fausse — et c'est le défaut

pr_close_keyword_guard.py ne partage aucune logique de spans : il délègue à grain_tag.find_close_keyword_pr_refs (scripts/grain_tag.py:379), qui scanne le texte brut sans aucun masquage backtick — CLOSE_KW_REF_RE.finditer(text) direct.

Contrôle isolé (mesuré sur main da13579)

gt.find_close_keyword_pr_refs("documents the guard firing on ``fixes #10094`` in prose")
# -> [{'keyword': 'fixes', 'number': 10094, ...}]   FALSE POSITIF
gt.find_close_keyword_pr_refs("we ``closes\n#1234`` wrapped citation")
# -> [{'keyword': 'closes', 'number': 1234, ...}]   idem avec repli de ligne

Une PR qui documente en prose le comportement du close-keyword guard (citation backtiquée de fixes #10094, comme le fait le docstring même du finder, grain_tag.py:385-387 qui cite CLOSED <PR-number>) déclenche le garde sur son propre texte explicatif. Même piège auto-referentiel que #14550/#14703, déplacé sur le garde sœur.

Asymétrie

variation_prev_guard masque les spans backtiqués depuis #14560 (multi-lignes depuis #14700) précisément parce qu'une citation ≠ une déclaration. find_close_keyword_pr_refs n'a jamais reçu l'équivalent.

Acceptance proposée

• find_close_keyword_pr_refs masque les spans inline + fenced avant le scan (réutiliser _mask_code_spans ou l'extraire en commun dans grain_tag) en préservant les offsets (le verdict cite les lignes).
• Test : citation backtiquée mono-ligne ET repliée → aucun hit ; contrôle de mordant : la même clause sans backticks → hit.
• Non-régression : tests grain_tag + pr_close_keyword_guard verts.
• Vérifier les consommateurs du finder (grep find_close_keyword_pr_refs) pour aucun autre chemin non masqué.

Provenance

• Famille guard(prev_guard): citer un tag prev: en prose CREE une declaration — 3 PRs gelees sur une phrase de documentation correcte #14550 (racine CLOSED) : « citer un tag en prose crée une déclaration ».
• Détecté en vérifiant guard(prev_guard): le masquage des backticks ne survit pas a un repli de ligne (3e axe de #14550) #14703 item 4 — hors scope de cette issue (un sujet par PR), d'où la présente.
• Mesure myia-po-2026, worktree frais origin/main da13579, 2026-09-05.

[jsboige]

Verification c.305 - label candidate-delivered retire : la PR MERGED (#14781) livre #14703, pas #14780.

Diagnostic : PR #14781 MERGED 2026-09-05T17:53:34Z - Closes #14703 (explicite dans le body PR, ligne 22). MAIS le ticket #14780 est NEUF, documente un defaut distinct : find_close_keyword_pr_refs ne masque pas les spans backtiques (acceptance 4 items listes dans le body).

Body PR verbatim (ligne 10) :

2. Verification item 4 : pr_close_keyword_guard.py ne partage AUCUNE logique de spans (premissse de l'issue fausse) ... Decouverte adjacente au passage : les citations backtiquees fixes #N ... declenchent ce garde - signalee par issue dediee guard(pr_close_keyword): les citations backtiquées fixes/closes #N déclenchent le garde (4e axe #14550) #14780 (famille guard(prev_guard): citer un tag prev: en prose CREE une declaration — 3 PRs gelees sur une phrase de documentation correcte #14550, hors scope ici).

L'item 4 du ticket #14703 etait : « verifier que le meme repli ne casse pas le masquage de pr_close_keyword_guard.py ». La PR #14781 a verifie que la premisse etait fausse (pas de logique partagee). MAIS elle a identifie un defaut REEL adjacent sur find_close_keyword_pr_refs lui-meme, qu'elle a signale par une nouvelle issue #14780 - hors scope de la PR.

Le ticket #14780 reste donc OPEN avec ses 4 acceptance items non couverts :

1. find_close_keyword_pr_refs masque les spans inline + fenced avant le scan
2. Test : citation backtiquee mono-ligne ET repliee -> aucun hit
3. Non-regression : tests grain_tag + pr_close_keyword_guard verts
4. Verifier les consommateurs du finder pour aucun autre chemin non masque

Pas de full delivery : la PR a signale le defaut mais ne l'a pas fixe. Ticket reste OPEN.

Tell c.304-L2 sustained : 24ᵉ cas. La mention hors scope ici dans le body PR est un signe revelateur que le label candidate-delivered declenche sur PR MERGED sans scanner si elle livre le bon ticket. Le matcher devrait verifier la clause Closes #N explicite (et non seulement une reference textuelle faible).

[jsboige]

[CLAIMED] lane myia-po-2026:CoursIA — grain tag MED/guard #14780 : masquage backtick dans find_close_keyword_pr_refs (acceptance 4 items : mask inline+fenced offsets préservés, test citation repliée + contrôle de mordant, non-régression grain_tag + pr_close_keyword_guard, grep consommateurs). Grain: MED/guard -- lane myia-po-2026:CoursIA -- prev: MED/guard #15095