[tooling] check_markdown_claims_output : les coordonnees (2,2) normalisees en decimal 2.2 -> faux positifs de fabrication #14905

Defaut

scripts/check_markdown_claims_output.py normalise la virgule comme separateur decimal francais. C'est correct pour 0,75 -> 0.75, mais cela mange les paires de coordonnees : (2,2) devient le nombre 2.2, (1,1) devient 1.1. Le detecteur cherche alors ces « valeurs » dans la sortie de la cellule de code precedente, ne les trouve pas, et les signale comme fabrications.

Mesure firsthand

Sur MyIA.AI.Notebooks/Probas/DecisionTheory/PyMC/DecPyMC-7-Sequential.ipynb :

md[67] (after code[64]) raw='2,2' normalized='2.2'
    context: ..., gamma=0.9)` avec un but en (2,2) et un obstacle en (1,1) - L'evaluation...
md[67] (after code[64]) raw='1,1' normalized='1.1'

La prose dit « un but en (2,2) et un obstacle en (1,1) » — ce sont des cases d'une grille 3x3, pas des reels.

Le defaut est anterieur a #14881 : rc=1 et les deux memes findings sont rendus par la version de base comme par la tete de cette PR. #14881 etend le detecteur (relations contre metriques de sortie) sans toucher ce chemin, et n'a donc pas a le corriger — c'est pourquoi ce point est sorti en issue separee plutot qu'en reserve de review.

Pourquoi ca compte malgre le caractere advisory

Le workflow est advisory, donc rien n'est bloque. Mais un detecteur anti-fabrication qui crie au loup sur des coordonnees de grille se fait desapprendre : au bout de quelques notebooks, le lecteur classe la sortie entiere comme bruit et rate le vrai finding. C'est le mode de mort ordinaire d'un organe advisory — pas le faux negatif, la perte de credit.

Meme famille de faux positifs observee sur le meme notebook, a trier avec :

• $\gamma = 0.9$ (md[15], md[19]) — hyperparametre enonce en prose, pas une valeur citee depuis une sortie ;
• [0.2, 0.4, 0.6, 0.8, 0.5] (md[36]) — specification du probleme (moyennes des bras), donnee d'entree ;
• Bras 1=0.3, Bras 2=0.5 (md[38]) — idem.

Ces trois-la sont une classe distincte du bug de coordonnees : ce sont des nombres legitimement absents de la sortie parce qu'ils sont des entrees. Les traiter demande une regle, pas un correctif de parsing.

Acceptance

1. Coordonnees : ne pas normaliser N,N en decimal quand le motif est entoure de parentheses ou appartient a un tuple ((2,2), (1,1), (i,j)). Un chiffre unique de part et d'autre d'une virgule a l'interieur de parentheses n'est pas un decimal francais.
2. Controle positif obligatoire — le correctif se valide par ses faux negatifs, pas par ses hits : ecrire dans les tests les deux formes cote a cote, et verifier que le detecteur distingue :
   • (2,2) -> pas un nombre (coordonnee) ;
   • 0,75 -> reste 0.75 (decimal francais, comportement a preserver).
     Sans ce second cas, un correctif trop large desactiverait la normalisation francaise, qui est la raison d'etre du chemin.
3. Trancher separement la classe « nombre d'entree » (hyperparametres, specifications) : soit une liste de contextes exemptes, soit un marqueur explicite. Ne pas l'embarquer dans le meme correctif que (1) — les deux ont des causes differentes.
4. Re-mesurer sur DecPyMC-7-Sequential.ipynb : les 2 findings de coordonnees doivent disparaitre, les assertions claim-check doivent rester SUPPORTED.

Hors scope

• Le comportement des relations claim-check introduites par feat(claims-guard): detect relations against output metrics #14881 : verifie fonctionnel, 5/5 assertions resolues correctement contre le CLAIM_METRICS reellement emis.
• Le passage du workflow en bloquant.

See #14881.