guard(prev_guard): le masquage des backticks ne survit pas a un repli de ligne (3e axe de #14550)

[myia-ai-01]

Troisieme angle mort de la famille #14550 (« citer un tag prev: en prose CREE une declaration »), mesure firsthand le 2026-09-05 sur PR #14700.

Le defaut

Le masquage des portees entre backticks livre par #14560 ne survit pas a un repli de ligne. Une citation coupee au milieu du span reste visible pour _PREV_PR_REF_RE, qui la lit comme une declaration prev: reelle.

Cas reel — message de commit de #14700 (fix/prev-guard-citation-prose) :

L4| defect. The commit body documents the bug in prose, citing `prev: MED/training
L5| #14592` in backticks inside a numbered list, with NO Grain: line of its

Verdict de l'organe (memes arguments que la CI, --resolve-targets) :

prev_invalid: [{"location": "commits[0]", "kind": "prev-not-merged", "prev_pr": 14592}]

Controle isole — un seul caractere de difference

Passe sur l'organe deja corrige par #14700 (donc le defaut lui survit) :

Forme de la citation	guard_pass	hits
span backticke sur deux lignes	False	prev-not-merged -> 14592
span backticke sur une ligne	True	aucun

Les deux entrees ne different que par le \n insere dans le span. C'est donc le repli de ligne qui porte le defaut, pas le contenu.

Pourquoi les trois correctifs deja livres ne le couvrent pas

Axe	PR	Ce qu'il traite	Le span multi-lignes ?
1	#14560 MERGED	masquage des backticks dans _PREV_PR_REF_RE	non — masquage mono-ligne
2	#14633 MERGED	fail-open rendu visible (resolution_failed)	non — orthogonal
3	#14700 OPEN	bornage de _declared_prev_pr a la 1re ligne Grain:	non — chemin de code different (prev_invalid vient du scan regex, pas du fallback)

Les trois sont justes ; aucun ne regarde cet axe.

Effet observe

Une PR est bloquee par un defaut qu'elle documente en prose — expliquer le bug dans un message de commit suffit a le declencher. Meme piege auto-referentiel que #14550, deplace d'un cran.

Acceptance

• Le masquage des spans backtickes tolere le \n interne (regex DOTALL sur le span, ou normalisation des replis avant masquage) — au choix de la lane qui prend le grain.
• Un test qui echoue sans le patch reproduit la forme exacte ci-dessus (span coupe entre deux lignes), en plus du cas mono-ligne deja couvert par test_fully_backticked_tag_is_still_evaluated.
• Non-regression : les tests de scripts/tests/test_variation_prev_guard.py restent verts.
• Verifier que le meme repli ne casse pas le masquage de pr_close_keyword_guard.py, qui partage la logique de spans (non mesure ici — a confirmer, pas a supposer).

Provenance

• guard(prev_guard): citer un tag prev: en prose CREE une declaration — 3 PRs gelees sur une phrase de documentation correcte #14550 CLOSED — racine de la famille
• fix(guards,#14550): bound _declared_prev_pr to the first Grain: line (PR #14592 false positive) #14700 OPEN — victime, et porteuse du 3e axe ; ne pas absorber ce grain dedans (scope 2 fichiers, defaut non introduit par elle)
• Mesure ai-01, 2026-09-05, cycle de merge

[jsboige]

[CLAIMED] lane myia-po-2026:CoursIA — fix prev_guard : le masquage des spans backtiqués doit tolérer le repli de ligne interne (regex DOTALL sur le span OU normalisation des replis avant masquage). Preflight 3-sondes fait : 0 PR/commit mentionnant #14703. Contrôle isolé de l'issue (diff d'un caractère) repris comme test de régression. Genre prévu MED/guard.

[jsboige]

[RELEASED] lane myia-po-2026:CoursIA — PR #14781 (test de régression guard-level + vérification item 4).

Etat du défaut sur main (vérifié firsthand, worktree frais da13579) : déjà résolu par le merge de #14700 — la regex _CODE_SPAN_RE est passée à `[^`]*` avec re.DOTALL, et le contrôle isolé de l'issue passe sur les DEUX formes (guard_pass=True, zéro prev_invalid). #14703 (02:57Z) prédate le merge de #14700 (10:30Z), qui a absorbé le fix en corrigeant son propre blocage.

Ce que #14781 ajoute pour clore l'acceptance :

• Item 2 complété au niveau mesuré : le contrôle de l'issue passait par le verdict complet (prev_invalid → commits[0] / prev-not-merged / 14592) ; les tests de fix(guards,#14550): bound _declared_prev_pr to the first Grain: line (PR #14592 false positive) #14700 couvrent les niveaux masque/finder. test(guard,#14703): test de régression guard-level — citation prev backtiquée multi-lignes #14781 épingle le chemin end-to-end : span deux lignes avec feat(training,#14584,#1454): M17 HAR-LJ-Asym BTC revalidé contre HAR débiaisé train-only #14592 tenu OPEN (le pass est gagné par le masque), contrôle mono-ligne, et contrôle de mordant — la même clause sans backticks bloque toujours ; vérifié échouer sur la regex pré-fix(guards,#14550): bound _declared_prev_pr to the first Grain: line (PR #14592 false positive) #14700 simulée (verdict exact de l'issue reproduit).
• Item 3 : 44 passed / 0.35 s (43 existants + 1 nouveau).
• Item 4 vérifié : pr_close_keyword_guard.py ne partage AUCUNE logique de spans (prémisse « partage la logique » fausse — scan texte brut via grain_tag.find_close_keyword_pr_refs). Le repli ne peut pas casser un masquage inexistant. Découverte adjacente : les citations backtiquées fixes #N (mono-ligne ET repliées) déclenchent ce garde — signalée dans guard(pr_close_keyword): les citations backtiquées fixes/closes #N déclenchent le garde (4e axe #14550) #14780 (4e axe 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.

Items 1-2 étaient livrés par #14700 ; #14781 complète 2 (niveau guard) + 3 + 4 → Closes #14703 légitime.