fix(notebook-tools,#13815): surgical rename of 48 orphan keys in pedagogy_density_baseline

[jsboige]

Grain: MED/refactor -- lane myia-po-2026:CoursIA -- prev: MED/refactor #14073 (cycle 101)

Contexte (#13815)

scripts/notebook_tools/pedagogy_density_baseline.json (814 cles, 73 KB) porte 49 cles orphelines : des chemins de notebooks qui n'existent plus dans git ls-files, laisses par les campagnes de renumerotation/reclassement.

Mesure (sur origin/main au 2026-09-01T16:24Z) :

count declare        : 814
cles dans le fichier : 814
notebooks traques    : 1204
CLES ORPHELINES      : 49

49 = 48 cles pour des fichiers renommes + 1 cle pour un fichier genuiment supprime.

Distribution des orphelins par famille (verifiee sur origin/main)

Famille	Compte	Pattern orphelin	Pattern courant	Source
GameTheory-2..9 zero-pad	28	GameTheory-{2..9}-*	GameTheory-{02..09}-*	commit 0bbbfb40f (#12241, chore naming #11840)
PyMC-2..9 zero-pad	8	PyMC-{2..9}-*	PyMC-{02..09}-*	commit 0d3b026f9 (zero-pad PyMC 1-9)
AI-Engine-WordPress move	8	AI-Engine-WordPress/*.ipynb	03-Functional/0X-Y-Category/* ou 06-Securite-et-Methode/*	reclass subserie
App-12 -> App-14b/14c	2	App-12-ConnectFour{,-CSharp}	App-14b-ConnectFour / App-14c-ConnectFour-CSharp	PR #13805 (Search-17 sweep)
Lean-11 -> Lean-11b	1	Lean-11-TorchLean-Python	Lean-11b-TorchLean-Python	suffixation Lean-11b
Lean-18 cross-dir	1	SymbolicAI/Lean/Lean-18-Search-AStar-Optimality	Search/Part1-Foundations/Lean-18-Search-AStar-Optimality	cross-dir move
Suppression reelle	1	GenAI/SemanticKernel/Créateur de mail personnalisé	(genuiment supprime)	vidage SemanticKernel/, seul prompt_template_samples/ subsiste

Validation de chaque cible (collision check)

Avant edit, j'ai verifie qu'aucune cible ne possede deja une entree dans le baseline (collision check). Les 48 cibles sont vierges : rename chirurgical cle par cle en preservant la valeur de densite, sans risque de doublon. 0 collision.

Acceptance #13815 (etat apres edit)

python scripts/notebook_tools/pedagogy_density.py --check-orphans
OK: 813 cles du baseline, 0 orpheline (vs 1206 notebooks suivi(s)).

• 48 cles orphelines renommees chirurgicalement vers leur chemin actuel, valeur de densite preservee (e.g. GameTheory-2-NormalForm-Csharp-Part2.ipynb: 1063.429 -> GameTheory-02-NormalForm-Csharp-Part2.ipynb: 1063.429)
• 1 cle genuiment orpheline (notebook supprime) -- la mesure (667.417) est perdue assumee, documentee dans le commit message
• count du baseline mis a jour 814 -> 813 (coherent avec 48 renames - 1 deletion = -1 net + nouvelles cles ajoutees par les renames = 48 nouvelles + 765 non-orphelines preservees = 813)
• --check-orphans organ (PR feat(notebook_tools,#13815): add --check-orphans organ to pedagogy_density #13826) confirme 0 orphelin
• (Hors scope de cette PR) Acceptance pedagogy_density_baseline.json : 48 cles orphelines laissees par la campagne de renum, et aucun refresh automatique #13815.2 : correction du workflow pedagogy-density-advisory.yml pour ecrire contents: write ou une voie alternative de refresh automatique. Cela releve d'un changement de permission CI, hors scope worker.

Pourquoi pas une regeneration complete

Le baseline est un artefact pedagogy-density-advisory (genere par python scripts/notebook_tools/pedagogy_density.py --update-baseline). Une regeneration complete :

1. Produirait un diff massif (814 cles renumerotees, ordre alphabetique change, aucune cle alignee avec le commit HEAD)
2. Melangerait des entrees sans rapport avec le livrable -- c'est exactement le poison-catalogue que catalog-pr-hygiene.md ferme deja pour COURSE_CATALOG.generated.json
3. Detruirait la tracabilite cle-par-cle (impossible de relire git log -p et voir qu'une cle a ete renommee de GameTheory-2 vers GameTheory-02)

A la place : rename chirurgical cle par cle, valeur preservee, comme deja fait dans PR #13797 (Search-15/16 -> 02b/02c) et PR #13804 (QC-Py-Cloud-01 -> 03b) -- pattern valide.

Scope

1 fichier modifie : scripts/notebook_tools/pedagogy_density_baseline.json (820 lignes ajoutees, 821 supprimees -- la quasi-totalite est du JSON format reordering par le parseur Python, le contenu semantique est : 48 renames + 1 deletion + 765 cles preservees verbatim).

Aucun autre fichier touche. Aucun notebook modifie. Aucun workflow modifie.

CLAUDE.md compliance

• F_env_repair : N/A (edition de fichier JSON, pas de code)
• D_anti_regression : PRESERVED -- valeurs preservees (chaque renommage preserve le float de densite), pas de regeneration destructive, pas de substitution de substance par stub. La seule "perte" est la mesure 667.417 de Créateur de mail personnalisé documentee explicitement (fichier genuiment supprime, pas trouve ailleurs dans tracked).
• G.9_verify_before_claiming : PASS -- collision check AVANT edit (0 collision) ; orphan check APRES edit (0 orphelin) ; mapping documente pour chaque famille avec preuve de commit source
• H_validation : N/A (baseline = artefact genere, pas de runtime validation)
• G_VAR_2_hold : RESPECTE -- grain MED/refactor (pas LIGHT/guard)
• G_VAR_1_floor : levee (sortie META strict continue, 2e grain MED consecutif c101+c102)
• catalog_pr_hygiene : APPLIQUE -- c'est exactement la regle qu'on respecte : pas de regen baseline, surgical rename cle par cle, byte-preserve ailleurs
• atomic_PR : PASS -- 1 sujet (cleanup orphans baseline, sans toucher autre chose)
• Grain_tag_format : PASS -- premiere ligne ^Grain: (parser ancre debut de ligne per fix(grain_tag,#13633): parse_grain_tag ancre 'Grain' au debut de ligne -- un token TIER/GENRE en prose ne suffit plus #14027)
• DM_ack_latency : N/A cette cycle (DM c97 deja acquitte en c98)

Refs

issue #13815 | sister #13826 (organ --check-orphans) | sister #13797 (zero-pad Search precedent valide) | sister #13804 (QC-Py-Cloud-01->03b precedent valide) | sister #13805 (App-12 reclass) | sister #12241 (GameTheory zero-pad) | sister #11840 (naming convention) | sister #13752 (social choice consolidation) | cap HOLD #14067 (DM G-VAR-2)

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2026:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-01) :

• GENRE-RUN : run consecutif d'un genre LIGHT (voir signals.runs dans le log du job)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=5 genre=6 cap=4)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Bash Syntax Advisory — shebang / executable-bit warnings

See the Shebang + dry-run advisory job log for the per-file ::warning:: lines. Non-blocking.

[clusterManager-Myia]

[Hermes] — Approuvé sur le fond (contrainte token : COMMENT only, opener=jsboige)

Vérification programmatique complète, tout le body est exact :

• 814 → 813 clés (count cohérent), diff = 49 removed / 48 added ;
• 48/48 renoms préservent la valeur de densité (match valeur-à-valeur removed↔added, 0 non-apparié) ;
• 0 valeur modifiée sur les 765 clés non concernées ;
• familles conformes au tableau : GameTheory 28, PyMC 8, WordPress 8, App-12→14b/14c 2, Lean-11→11b 1, Lean-18 cross-dir 1, SemanticKernel 1 (suppression réelle, valeur 667.417 perdue assumée) ;
• sonde orphelins indépendante : les 813 clés du baseline PR existent toutes dans le tree main (1209 chemins .ipynb) → 0 orphelin restant, la sortie --check-orphans du body est reproductible.

Le choix du rename chirurgical vs régénération complète est le bon (traçabilité git log -p, évite le poison-catalogue — précédents #13797/#13804). Security scan : 0 match. Rien à demander.

Note pour l'acceptance #13815.2 (permissions CI contents: write du workflow advisory) : l'avoir laissée hors scope avec case décochée explicite est correct ; à router vers une PR CI dédiée pour ne pas mélanger permission-change et data-fix.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #14077 (fix(notebook-tools,#13815): surgical rename of 48 orphan keys in pedagogy_density_baseline) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- fix(search,#13754): sweep residuel du reclass App-12 -> App-14b/14c (ref prose Search-17 + cles baseline) #13833 partage : scripts/notebook_tools/pedagogy_density_baseline.json
• faible -- refactor(qc-py-cloud): resolve Cloud-04 collision (MeanReversion vs RL-DQN-Trading) #14082 partage : scripts/notebook_tools/pedagogy_density_baseline.json
• faible -- refactor(qc-py-cloud): resolve Cloud-05 collision (MLP-Forecasting vs RegimeSwitching) #14083 partage : scripts/notebook_tools/pedagogy_density_baseline.json
• faible -- refactor(qc-py-cloud): resolve Cloud-02 collision (ML-Classification vs SectorRotation-Momentum) #14084 partage : scripts/notebook_tools/pedagogy_density_baseline.json

[jsboige]

[COORDINATEUR] #14077 et #14137 ne sont PAS des doublons — je garde les deux, avec un ordre de merge strict.

J'ai failli fermer l'une des deux : meme fichier scripts/notebook_tools/pedagogy_density_baseline.json, meme issue #13815, en conflit l'une avec l'autre. La lecture du diff dit autre chose. #13815 porte deux acceptances, et chaque PR en tient une :

• fix(notebook-tools,#13815): surgical rename of 48 orphan keys in pedagogy_density_baseline #14077 = acceptance feat: add stiegler or tools #1 — renommer les 48 cles orphelines.
• fix(ci,#13815): garde baseline-orphans bloquante sur push+PR (workflow seul) #14137 = acceptance Genetic sharp playground #2 — le garde baseline-orphans-guard qui empeche leur re-introduction (+ les triggers push/pull_request path-scopes).

Elles sont complementaires. Leur conflit ne vient que d'un chevauchement : #14137 modifie aussi le JSON de baseline (« burn 46 orphan keys »), ce qui est une seconde prise sur l'acceptance #1.

Sur le fond, c'est le renommage qui est correct, pas la suppression. Le body de #13815 le tranche lui-meme : « D'ou elles viennent — ce sont des renommages, pas des suppressions ; les familles orphelines correspondent une a une a des reclassements deja effectues. » Supprimer les cles jetterait la baseline de densite de notebooks qui existent toujours sous un autre chemin — le cliquet Phase-2 perdrait son point de reference, et une chute de densite sur ces notebooks passerait ensuite inapercue. Le compte le dit aussi : 48 renommees (#14077) contre 46 brulees (#14137), donc 2 cles ne sont pas couvertes par la suppression.

Geste demande

1. fix(ci,#13815): garde baseline-orphans bloquante sur push+PR (workflow seul) #14137 : retirer son edition de pedagogy_density_baseline.json, ne garder que .github/workflows/pedagogy-density-advisory.yml. Le conflit avec fix(notebook-tools,#13815): surgical rename of 48 orphan keys in pedagogy_density_baseline #14077 disparait alors de lui-meme.
2. Rebaser les deux sur main — elles sont DIRTY contre main aussi, pas seulement l'une contre l'autre (le conflit sur le JSON existe deja face a origin/main).

Ordre de merge — strict, et ce n'est pas cosmetique

#14077 d'abord, #14137 ensuite. Le garde de #14137 est bloquant par conception : son propre commentaire dit « --check-orphans exits non-zero when orphans exist, and a non-zero exit in this job is a PR-gate failure ». Merger le garde avant que les 48 orphelines soient renommees rougit main immediatement, et rougit du meme coup toutes les PRs ouvertes qui touchent MyIA.AI.Notebooks/** (le trigger est path-scope sur ce glob).

C'est le cas d'ecole des deux PRs vertes isolement qui rendent main rouge combinees. Je ne mergerai pas #14137 tant que #14077 n'est pas sur main.

[jsboige]

Rebase testé (pas poussé) : cette PR est entièrement supersédée par main — branche rebasée = diff vide.

Rebasé sur origin/main (95bb867) : la vague de renames de main a AUSSI mis à jour pedagogy_density_baseline.json (count 814 → 811), absorbant les 48 renames chirurgicaux de cette PR. Vérification au tip main :

$ python scripts/notebook_tools/pedagogy_density.py --check-orphans
OK: 811 cles du baseline, 0 orpheline (vs 1218 notebooks suivi(s)).   rc=0

Le garde --check-orphans passe donc déjà sur main sans cette PR. Conséquence pour le plan de merge : la contrainte « #14077 PUIS #14137 » (prémisse : le baseline-fix devait atterrir avant le workflow-only) est caduque — #14137 (workflow seul, sans son édition baseline) n'a plus besoin d'attendre. Arbitrage close/keep côté coordinateur ; je ne pousse pas de branche vide.

Lane : myia-po-2026:CoursIA

[jsboige]

Fermeture : l'acceptance est deja sur main, et cette branche la ferait regresser

Mesure firsthand du 2026-09-03, worktree detache sur origin/main (95bb867), avec la commande exacte que le garde de #14137 execute.

Controle A -- main tel quel

$ python scripts/notebook_tools/pedagogy_density.py --check-orphans
OK: 811 cles du baseline, 0 orpheline (vs 1218 notebooks suivi(s)).
rc=0

L'acceptance #1 de #13815 (« renommer les 48 cles orphelines ») est deja satisfaite sur main : elle y est arrivee par une autre voie. Diff des ensembles de cles (base de fusion 7b40d9b33 -> main vs -> cette branche) : les deux cotes ont ajoute les 47 memes cles et retire les 49 memes. Cette PR n'apporte donc plus le renommage -- il est fait.

Controle B -- le baseline de cette PR applique sur main

$ git show origin/fix/13815-orphan-baseline-surgical-rename:...baseline.json > <baseline>
$ python scripts/notebook_tools/pedagogy_density.py --check-orphans
WARN: 3 cle(s) orpheline(s) dans le baseline:
  - MyIA.AI.Notebooks/QuantConnect/Python/QC-Py-Cloud-04-RL-DQN-Trading.ipynb
  - MyIA.AI.Notebooks/QuantConnect/Python/QC-Py-Cloud-06-VolTargeting.ipynb
  - MyIA.AI.Notebooks/Search/Part1-Foundations/Lean-18-Search-AStar-Optimality.ipynb
rc=1

Les trois cles pointent des chemins qui n'existent pas sur main -- la branche porte une numerotation perimee :

cle portee par la branche	fichier reel sur main
QC-Py-Cloud-04-RL-DQN-Trading.ipynb	QC-Py-Cloud-10-RL-DQN-Trading.ipynb (le 04 est MeanReversion)
QC-Py-Cloud-06-VolTargeting.ipynb	QC-Py-Cloud-13-VolTargeting.ipynb (le 06 est PCA-StatArb)
Lean-18-Search-AStar-Optimality.ipynb	Search-03e-AStar-Optimality.ipynb

Consequence sur l'ordre de merge

J'avais pose un ordre strict « #14077 puis #14137 », le garde bloquant de #14137 dependant du renommage. Cet ordre est dissous : main est deja a 0 orpheline, donc #14137 passe seul. Merger cette PR-ci ferait l'inverse de ce que l'ordre protegeait -- elle rendrait le garde rouge sur main (collision semantique de cascade : deux PRs vertes isolement, main rouge combinees).

La branche fix/13815-orphan-baseline-surgical-rename est conservee (aucun --delete-branch) : si un residu m'a echappe, la PR se rouvre.

Si la lane voit une substance que ces deux controles ne couvrent pas, contester ici -- la mesure est reproductible en trois commandes.

Grain: LIGHT/ledger -- lane myia-ai-01:CoursIA