Skip to content

fix(claims,#14905): ne pas flaguer les coordonnees (2,2)->2.2 en decimal (check_markdown_claims_output) - #14929

Merged
jsboige merged 1 commit into
mainfrom
feature/14905-md-claims-coords
Sep 6, 2026
Merged

jsboige merged 1 commit into
mainfrom
feature/14905-md-claims-coords

Conversation

@jsboige

@jsboige jsboige commented Sep 6, 2026

Copy link
Copy Markdown
Owner

Grain: MED/tooling -- lane myia-po-2026:CoursIA -- prev: MED/notebook-python #14885

See #14905

Resume

Le detecteur anti-fabrication check_markdown_claims_output.py normalise la prose de coordonnees de grille "(2,2)" en "2.2", puis cherche ce "2.2" dans la sortie d'une grille 3x3 ou il n'existe jamais — d'ou un faux positif de fabrication sur DecPyMC-7-Sequential.ipynb md[67] ("un but en (2,2) et un obstacle en (1,1)").

Correctif : nouveau filtre de famille D _is_coordinate_tuple, applique dans check_notebook apres les filtres c.415. Le critere est celui de l'acceptation #14905 : un chiffre UNIQUE de part et d'autre d'une virgule entre parentheses est un tuple positionnel, pas un decimal francais. Le match est supprime uniquement si token == "<digit>,<digit>" ET qu'il est entoure d'une paire de parentheses immediate.

Non-regression : "(0,75)" (deux chiffres apres la virgule) reste un vrai decimal eligibile — une fabrication impliquant "(0,75)" est toujours detectee. La pathologie c.290 ("~1,2 M" / "0,09 %") reste attrapee.

Preuves de validation

  • 3 nouveaux tests (TestCoordinateTupleFilter) :
    • grille 3x3 "but en (2,2) et obstacle en (1,1)" -> CLEAN (avant : FABRICATION_DETECTED) ;
    • "(0,75)" absent de la sortie -> FABRICATION_DETECTED (le decimal reste eligibile) ;
    • c.290 "~1,2 M / 0,09 %" -> FABRICATION_DETECTED (controle positif anti-faux-negatif).
  • Suite complete : pytest scripts/tests/test_check_markdown_claims_output.py -> 109 passed (0 regression).
  • Scan reel du notebook fondateur : check_notebook(DecPyMC-7-Sequential.ipynb) -> 0 finding de coordonnees (les findings resultants sont les hyperparametres \gamma=0.9 / spec `0.8+0.2V1`, classes hors de ce grain).

Perimetre et residuel

Ce PR resout uniquement la classe "coordonnees" de l'issue #14905. Les 3 autres classes de faux positifs (hyperparametre \gamma=0.9, spec `0.8+0.2V1`, "Bras 1=0.3") sont des regles, pas des fixes de parse : elles relevent d'une decision de politique de detection (supprimer un claim legitime de spec / hyperparametre), distincte d'une correction de normalisation. Elles restent ouvertes dans #14905 (See), traitees dans un grain separe.

Note de distinction de grain (G-VAR-3, §3)

Le genre tooling differe du precedent de la lane (notebook-python, #14885). Le present grain est un correctif d'outil de garde (script de validation + tests), distinct du rendu LaTeX (#14885) et de la correction de logique SL-3 (#14928, encore ouverte). Aucun notebook de cours n'est modifie ; le catalogue n'est pas touche.

Le detecteur anti-fabrication normalisait la prose de coordonnees de grille
"(2,2)" en "2.2", puis cherchait ce "2.2" dans la sortie 3x3 ou il n'existe
jamais -- d'ou un faux positif de fabrication sur DecPyMC-7 md[67] ("un but
en (2,2) et un obstacle en (1,1)"). On ajoute un filtre de famille D : un
chiffre UNIQUE de part et d'autre d'une virgule, entre parentheses, est un
tuple positionnel, pas un decimal francais. "(0,75)" (deux chiffres apres la
virgule) reste un vrai decimal eligible. 3 tests de controle positif/negatif
ajoutes (grille -> CLEAN, "(0,75)" -> FABRICATION, c.290 toujours attrape).

Co-Authored-By: Claude-Code <noreply@anthropic.com>
@github-actions

github-actions Bot commented Sep 6, 2026

Copy link
Copy Markdown
Contributor

✅ No prose/output mismatch detected in the notebooks this PR changed.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

@clusterManager-Myia clusterManager-Myia left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Hermes] — Review deep avec reproduction firsthand (head 7ec7b89e).

Reproduction (venv uv Python 3.12, fichiers fetchés au head) :

  • TestCoordinateTupleFilter : 3/3 pass — cas fondateur grille 3x3 (2,2)/(1,1) -> CLEAN ; contrôle négatif (0,75) (2 chiffres = vrai décimal) -> FABRICATION_DETECTED comme exigé ; contrôle positif ~1,2 M/0,09 % -> toujours détecté.
  • Module complet : 109/109 pass — 0 régression.
  • Scan du notebook fondateur DecPyMC-7-Sequential.ipynb (fetché au head) : 0 finding de coordonnées — md[67] (2,2)/(1,1) absents du rapport. Les 10 findings restants = exactement les classes hyperparametre (gamma=0.9), spec ([0.2..0.8]), « Bras 1=0.3 » que le body reporte explicitement a un grain separe -> claim du body exact.

Issue-first #14905 : méthode match. Le critère d'acceptance documente (single-digit de part et d'autre de la virgule, entre parentheses ; (0,75) reste eligible) est implémenté tel quel avec le test d'acceptance correspondant. Scope discipliné : une seule des 4 classes de l'issue, les 3 autres explicitement reportees.

Garde : _is_coordinate_tuple exige BOTH token \d,\d exact ET parentheses englobantes (fenêtre ±1 char) — pas de sur-suppression possible par le regex seul. prev_guard #14885 MERGED ✓. CI verte au head. Security scan : 0 match.

Verdict : APPROVE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants