organ(rename_notebooks): target_violation juge un CHEMIN avec une regex ancree (31 faux positifs / 31 lignes) et contredit canonical_target

[jsboige]

Deux défauts mesurés dans la validation de cible de scripts/notebook_tools/rename_notebooks.py (organe mergé en #17801), tous deux rencontrés en appliquant la table de la série SmartContracts (#16231, commentaire 5836104610).

1. target_violation reçoit un chemin et juge une grammaire ancrée — 100 % de faux positifs

main() (l.803-808) parcourt pairs issu de load_mapping(...) — dont les entrées sont des chemins relatifs complets — et passe new tel quel à target_violation(new). Or target_violation (l.253-256) applique :

stem = re.sub(r"\.ipynb$", "", new_name, flags=re.I)
m = STEM_RE.match(stem)          # STEM_RE = ^(?P<prefix>[A-Za-z][A-Za-z0-9]*)-(?P<num>\d+)...

STEM_RE est ancrée en ^ : sur un chemin, le premier caractère est M de MyIA.AI.Notebooks/…, et le motif échoue dès le premier / ou ..

Mesure (25/09, table SmartContracts, 31 lignes) :

Appel	Résultat
target_violation("MyIA.AI.Notebooks/SymbolicAI/SmartContracts/00-Foundations/SC-01-Setup-Foundry-Python.ipynb")	"hors grammaire de serie (prefixe absent, index en tete ou separateur _)"
target_violation("SC-01-Setup-Foundry-Python.ipynb")	None

Conséquence : --mapping imprime 31 avertissements sur 31 lignes, sur toutes les séries, quel que soit le sérieux de la table. Ce n'est pas cosmétique : le message est accompagné (l.806-807) de « une cible non canonique promet un second renommage -- le dire, ne pas le taire », et le docstring de target_violation (l.249-251) prescrit que la ligne tombe en A TRANCHER. Un opérateur qui lit ce flot peut donc re-trancher des lignes déjà canoniques, ou renoncer au contrôle — c'est-à-dire exactement l'inverse du but.

Correctif suggéré : target_violation(os.path.basename(new)) à l'appel (l.804), ou dans la fonction elle-même.

2. canonical_target et target_violation se contredisent sur la même cible

Sur SC-7b-ERC20-Lean-Verification-Companion.ipynb (noyau python3) :

• canonical_target("SC-7b-ERC20-Lean-Verification-Companion.ipynb", "python") → SC-07b-ERC20-Lean-Verification-Companion-Python.ipynb (le titre ERC20-Lean-Verification-Companion ne se termine pas par un mot de noyau, donc la l.232 ne retire rien) ;
• target_violation("SC-07b-ERC20-Lean-Verification-Companion-Python.ipynb") → "mot de noyau en infixe du titre" (_KERNEL_INFIX_RE, l.259, attrape -Lean-).

Le générateur de --propose produit donc une ligne que le lint du même organe déclare non livrable. Sur cette série, la table --propose contenait une ligne qui, par contrat (l.249-251), devait tomber en A TRANCHER — elle était proposée comme un renommage ordinaire.

Ce que j'ai fait de mon côté : la ligne est tenue hors de la PR de renommage et laissée en A TRANCHER avec la mesure, la décision de grammaire étant rendue au coordinateur (« Lean » y est le sujet du carnet — vérification Lean d'un ERC-20 — et non le nom du noyau, mais _KERNEL_INFIX_RE ne fait pas cette distinction).

Arbitrage attendu (un des deux) : soit canonical_target applique la même règle que le lint (retirer l'infixe), soit _KERNEL_INFIX_RE est restreint aux mots de noyau non porteurs de sens métier, soit la règle de grammaire tolère un infixe quand le mot désigne le sujet. Les deux fonctions doivent converger : aujourd'hui --propose et le contrôle de la table ne jugent pas avec le même critère.

Note de méthode

Ces deux défauts ont été trouvés en consommant l'organe, pas en le relisant. Le premier se voit sur n'importe quelle série en une commande ; le second demande de croiser les deux fonctions. Aucun des deux n'empêche le renommage — target_violation est un avertissement, pas un refus — ce qui est précisément pourquoi ils peuvent passer inaperçus longtemps.

See #16231 (série SmartContracts, où les deux ont été rencontrés).

[jsboige]

Deux défauts supplémentaires, rencontrés en passant --apply pour de bon sur la série SmartContracts (30 renommages). Contrairement aux deux premiers, ceux-ci ne sont pas cosmétiques : le premier casse le --apply et laisse la branche à moitié faite, le second écrit dans un fichier que la règle interdit de toucher. Les deux frappent toutes les séries, donc toutes les lanes du chantier.

3. plan.rewrites est indexé sur les chemins d'avant le renommage — --apply meurt après avoir commité la jambe 1

L'ordre dans main() :

Ligne	Geste
l.811	plan = scan_referents(forms_list, repo) — scan de l'arbre avant tout git mv
l.839	git mv old new pour les 30 paires (commit 1)
l.849	rewrite_file(repo / rel, …) pour chaque rel de plan.rewrites (commit 2)

plan.rewrites est donc une table de hachage dont les clés sont les chemins pré-renommage. À la l.849, la jambe 1 a déjà déplacé ces fichiers : le chemin n'existe plus.

Mesure (25/09, série SmartContracts) :

FileNotFoundError: 'D:\dev\CoursIA-screname\MyIA.AI.Notebooks\SymbolicAI\SmartContracts\00-Foundations\SC-0-Cypherpunk-Origins.ipynb'
  at rename_notebooks.py line 849

Ce n'est pas un cas de bord : SC-0-Cypherpunk-Origins.ipynb est dans plan.rewrites parce qu'il cite lui-même un autre carnet renommé de la série. Sur une série où les carnets se citent entre eux — le cas normal — au moins un fichier renommé est aussi un référent, et le crash est certain.

Conséquence, la pire du lot : la panne n'est pas rattrapable par l'organe lui-même. L'échec laisse 6 fichiers réécrits dans l'arbre, et la garde d'arbre propre (l.826-832) refuse alors toute nouvelle exécution de --apply :

ARBRE NON PROPRE -- refus d'appliquer. Committer ou retirer avant :

Donc : commit 1 posé, commit 2 avorté, et l'opérateur ne peut pas relancer l'organe — il doit recoudre à la main (restaurer l'arbre, puis rejouer la jambe 2 hors organe). La jambe 1 n'est pas non plus annulable proprement, puisqu'elle est déjà commitée.

Correctif suggéré : ré-écrire plan.rewrites après la jambe 1, ou plus simplement dériver les clés de pairs (old → new) au moment de l'appel l.849 :

for rel in sorted(plan.rewrites):
    cur = dict(pairs).get(rel, rel)          # chemin courant après la jambe 1
    n = rewrite_file(repo / cur, forms_list)
    if n:
        done[cur] = n

4. scan_referents ne consulte jamais is_excluded — le catalogue est réécrit

is_excluded (l.264) est appelée à un seul endroit de l'organe : propose() (l.309), qui classe la ligne EXCLU et ne la propose donc jamais au renommage. scan_referents (l.466-546) ne l'appelle pas — son filtre à la l.474 est _is_history(rel) or rel in FIXTURES_DECLARED, rien d'autre. rewrite_file (l.603) ne l'appelle pas non plus.

Les deux moitiés de l'organe ne jugent donc pas avec le même critère : --propose déclare le catalogue EXCLU (jamais candidat au renommage), et la jambe référents le réécrit comme un fichier ordinaire.

Mesure (même run) :

Fichier	Occurrences réécrites
COURSE_CATALOG.generated.json	83
COURSE_CATALOG.generated.md	173

Pourquoi c'est un défaut et pas un mieux : la règle du dépôt (catalog-pr-hygiene, .claude/rules/) veut que ces fichiers restent byte-identiques à main sur une branche feature — c'est l'automatisation qui les régénère, et une écriture locale est silencieusement annulée par le bot au merge suivant. Le pilote de la même famille (#17787, Z3-17, mergé) a touché 8 fichiers et 0 fichier de catalogue : l'organe s'est donc comporté différemment selon la série, ce qui est exactement le propre d'une garde absente.

Sur ce run je l'ai rattrapé après coup :

git restore --source=origin/main -- COURSE_CATALOG.generated.json COURSE_CATALOG.generated.md

Correctif suggéré : appeler is_excluded(rel) dans la boucle de scan_referents (l.474), au même titre que _is_history — c'est une ligne, et elle aligne la jambe référents sur la sémantique déjà écrite pour --propose.

Portée

Ces deux défauts bloquent chaque lane qui exécutera un renommage de série, pas seulement la mienne : le 3 rend --apply inutilisable dès qu'une série s'auto-référence, le 4 fait échouer la PR au contrôle d'hygiène de catalogue. Je poursuis en attendant (jambe 2 rejouée hors organe, en réutilisant load_mapping / ref_forms / scan_referents / rewrite_file pour ne pas diverger de la sémantique validée), et je signale ici pour que le correctif soit posé avant que les autres lanes ne s'y cassent les dents.

See #16231.

[jsboige]

[CLAIMED] lane myia-po-2024:CoursIA-2 -- paths: scripts/notebook_tools/rename_notebooks.py, scripts/notebook_tools/tests/test_rename_notebooks.py -- 2026-09-28T08:30Z