fix(ci,#15106): enrich-quality gate — résoudre le nom BASE des notebooks renommés (-M seul = no-op)

[jsboige]

Grain: MED/guard — lane myia-po-2023:CoursIA — prev: LIGHT/docs #15050

enrich-quality gate : resoudre le nom BASE des notebooks renommes (le -M seul est un no-op)

Closes #15106
Supersedes #15110 (voir commentaire avec preuve d'execution) — debloque #15085.

Cause racine (affinee par rapport au diagnostic de l'issue)

L'issue #15106 proposait d'ajouter -M a git diff --name-only. Verifie firsthand : la detection de rename est deja active par defaut (diff.renames=true depuis git 2.9) — --name-only rend deja le nouveau chemin seul, avec ou sans -M. Le bug est en aval :

git cat-file -e "$BASE:$nb"   # $nb = chemin HEAD ; a la base le notebook porte l'ANCIEN nom

Pour un rename pur, ce test echoue -> basef="NONE" -> le gate applique la clause "a new notebook (no base) must be clean" au notebook renomme -> chaque finding pre-existing (ex. PHANTOM_IN_FENCE generate x2 de Texte/9_Production_Patterns.ipynb) est compte comme regression introduite par la PR. Le -M de #15110 ne change pas ce verdict.

Correctif

git diff --name-status -M + parsing des lignes dans la boucle :

• R099\told\tnew -> scanner new, resoudre la base sous old ;
• A/M\tpath -> comportement inchange (base = meme chemin, NONE si absent) ;
• D -> skip (deja le cas via [ -f ]).

Aucun changement de contrat cote enrich_quality_ci.py (--base NONE reste "new notebook must be clean").

Preuves d'execution (script integral du step, extrait du YAML committe et rejoue — pas une reimplementation)

Scenario #15085 rejoue sur worktree propre (base origin/main 7af725e) : git mv Texte/9_Production_Patterns.ipynb Texte/09_Production_Patterns.ipynb (R100), le PHANTOM_IN_FENCE generate x2 etant preexistant sur main (scanner verifie sur le fichier main) :

Controle	Avant (logique main / #15110)	Apres (ce commit)
rename pur R100 (le cas #15085)	FAIL — basef=NONE, finding pre-existing compte en regression (message identique au rapport de #15085)	OK rc=0 — base resolue sous 9_, finding pre-existing
notebook neuf SALE (zanzibar_magic x2 en fences)	FAIL	FAIL rc=1 (clause new-notebook-clean intacte)
notebook EXISTANT modifie + nouvelle regression injectee	FAIL	FAIL rc=1 (detection de vraie regression intacte)

Le faux positif disparait ; aucun des deux controles inverses ne faiblit.

Verifications

• Diff strictement confine : 1 fichier (.github/workflows/enrich-quality-gate.yml), +15/-7, aucun notebook, aucun catalogue.
• YAML valide (yaml.safe_load OK) ; les 56 lignes du script extrait et rejoue sont celles du commit.
• Branche jetable de repro (test/repro-*) non poussee, supprimee ; worktree propre.
• Collision : PR Fix #15106: enrich-quality gate — recognise notebook renames (-M) #15110 (ouverte avant) touche le meme fichier avec le fix -M seul — insuffisant (preuve ci-dessus), review preuve-postee dessus ; cette PR la supersede en citant tout. Arbitrage merge : coordinateur.

Diagnostic derive

Verdict : CAUSE_FIXED — le gate ne traitait pas les renames comme des relocalisations d'un notebook existant mais comme des fichiers neufs (base introuvable sous le nom HEAD). La base est desormais resolue via le mapping rename de --name-status -M, et les trois chemins (rename, ajout, modification) sont couverts par des controles executes dans les deux sens.

[jsboige]

[ADJOINT PREFLIGHT] COMMENTED — exact head af34ab5160, complete surface and diff reread.

Verified: the change is confined to .github/workflows/enrich-quality-gate.yml (+15/-7); git diff --name-status -M now carries the BASE path separately from the HEAD path, so an Rxxx old new row scans new while git cat-file/git show resolve old. Added/deleted/modified paths retain the intended behavior. No comments, prior reviews, or unresolved inline threads exist; check_unaddressed_nits.py 15143 is OK. All reported checks are now concluded successfully, including PR gate, scripts tests, workflow label-path coverage, metadata guards, and secret scan; GitHub reports OPEN / MERGEABLE / CLEAN.

Decision remains reserved to ai-01. Recommendation: prioritize this dependency before reassessing rename PRs such as #15147; their enrich-quality result is not repaired firsthand until this workflow is effective on the base and their own check reruns green.