md-content-loss-gate : aveugle a la traduction, et l'exemption evidente serait une regression #13548

Grain: MED/guard — lane myia-ai-01:CoursIA — prev: MED/notebook-python #13542

Le constat

detect_md_content_loss.py compare le volume et les motifs du markdown entre une base et une tete. Sur une PR de traduction, il compare mecaniquement du francais a de l'anglais -- et l'anglais est plus court a contenu egal (~26 % mesure sur medical_chatbot). Le garde lit ce delta comme une perte.

Mesure sur #13542, apres verification cellule par cellule du texte base-vs-tete : 3 findings sur FT-05-ModelMerging-Routing_en.ipynb, tous des faux positifs. Deux mecanismes :

• volume : la traduction fidele passe sous le seuil de ratio ;
• motifs : Objectif -> Objective, Etapes -> Steps -- le motif francais n'est plus la, le garde le compte perdu.

Le garde n'a aujourd'hui aucune des deux portes de sortie :

grep -nE '_en|lang|translat|TARGET_LANGS|suffix'  scripts/notebook_tools/detect_md_content_loss.py   -> rien
grep -nE 'override|label|bypass'                  scripts/notebook_tools/detect_md_content_loss.py   -> rien
grep -nE 'override|label|bypass'                  .github/workflows/md-content-loss-gate.yml         -> rien

Consequence : toute PR de traduction fidele est rouge, sans levee possible autre que de merger par-dessus un rouge.

Le contre-exemple, a lire avant de proposer un correctif

Le reflexe evident -- exempter *_<lang>.ipynb -- serait une erreur, et il faut l'ecrire ici pour qu'il ne soit pas propose de bonne foi dans six semaines.

Ce meme garde vient d'attraper une vraie troncature. Sur medical_chatbot_en, 6 cellules markdown etaient traduites au titre seul (ratios 0.04 a 0.36, cf #13542) : le titre survivait, le paragraphe avait disparu. C'est md-content-loss qui l'a rendu visible. Une exemption en bloc sur le suffixe de langue aurait laisse passer exactement ce defaut -- sur le fichier meme qui motive cette issue.

Le garde ne se trompe donc pas parce que la cible est une traduction. Il se trompe parce qu'il ne sait pas distinguer contenu supprime de contenu traduit -- et cette distinction est precisement ce qu'il faut lui apprendre, pas contourner.

Piste, a instruire (pas un cahier des charges)

La comparaison utile sur une paire de traduction n'est pas FR-tete contre FR-base : c'est EN-tete contre EN-base, avec le sibling FR comme reference de structure. Ce que check_translation_parity.py fait deja -- il a rendu OK, 0 anomalie sur les deux paires de #13542 la ou md-content-loss en voyait 3.

Deux directions a peser, sans trancher ici :

1. le garde detecte la paire (X_en.ipynb + X.ipynb present) et delegue a l'invariant de parite plutot que de mesurer un volume ;
2. il garde sa mesure mais contre le sibling FR de la meme revision, pas contre sa propre base.

L'option 1 a l'avantage de ne pas dupliquer une logique qui existe et qui a fait ses preuves sur ce cas precis.

Critere d'acceptation

• fix(translation,#10038): completer les 2 premieres paires _en (T2/T3/T4) + cliquet 2 #13542 (ou son successeur) passe vert sur No markdown content loss sans --update-baseline et sans exemption de suffixe.
• Un controle positif est fourni dans le meme artefact que le vert : la troncature de medical_chatbot (etat main avant fix(translation,#10038): completer les 2 premieres paires _en (T2/T3/T4) + cliquet 2 #13542) doit rester detectee par la version corrigee. Un correctif qui verdit FT-05 en aveuglant le garde sur medical_chatbot est un echec, pas un succes -- et il se lira comme un succes si personne n'exige ce controle.

Contexte

Sorti de #13542 (traduction FR->EN de medical_chatbot et FT-05). Ce n'est pas un correctif de PR : la PR est correcte, c'est le garde qui doit apprendre a lire une traduction.