pedagogy_density_baseline.json : 48 cles orphelines laissees par la campagne de renum, et aucun refresh automatique

[myia-ai-01]

Le fait

scripts/notebook_tools/pedagogy_density_baseline.json porte 48 cles orphelines : des chemins de notebooks qui n'existent plus, laisses par la campagne de renumerotation/reclassement.

count declare        : 814
cles dans le fichier : 814
notebooks traques    : 1198
CLES ORPHELINES      : 48

Mesure (sur main a 9803c6de2, 2026-08-31) :

import json, subprocess
d = json.load(open('scripts/notebook_tools/pedagogy_density_baseline.json', encoding='utf-8'))
tracked = set(x for x in subprocess.run(['git','ls-files','*.ipynb'],
                                        capture_output=True, text=True).stdout.split('\n') if x)
orph = sorted(k for k in d['notebooks'] if k not in tracked)
print(len(orph))   # -> 48

D'ou elles viennent — ce sont des renommages, pas des suppressions

Les familles orphelines correspondent une a une a des reclassements deja mergés :

Famille orpheline	Cles	Renommage a l'origine
GameTheory-2..9*	28	reclassement de la serie GameTheory
GenAI/.../AI-Engine-WordPress/*	8	deplacement de sous-serie
Probas/PyMC/PyMC-2..9	8	0d3b026f9 — zero-pad PyMC 1-9 en 01-09
Search/Applications/Search/App-12-ConnectFour*	2	07bf76093 — App-12 devient App-14b/14c
SymbolicAI/Lean/Lean-11-TorchLean-Python	1	b56d8f116 — devient Lean-11b
GenAI/SemanticKernel/Createur de mail personnalise	1	a tracer

Le cas App-12-ConnectFour est le meme renommage qui a laisse main rouge sur check-navlinks le 2026-08-31 au matin (referents non suivis dans Search-17, repare par #13805). Le baseline est la seconde surface que ce renommage a laissee derriere lui — celle qui, elle, n'a rougi nulle part.

Pourquoi ca ne se repare pas tout seul

Le seul workflow qui touche ce fichier est .github/workflows/pedagogy-density-advisory.yml, et il ne peut pas ecrire :

permissions:
  contents: read          # <-- pas write

Aucune etape git commit / git push / create-pull-request n'y figure. Le refresh est manuel (python scripts/notebook_tools/pedagogy_density.py --update-baseline).

C'est une correction a apporter a la lecture courante : la review Hermes de #13796 ecrit que « le baseline se regenere au prochain refresh ». Il n'y a pas de prochain refresh automatique. Une cle orpheline y reste jusqu'a ce que quelqu'un lance la commande.

Ce que la campagne fait deja bien — et qu'il suffit de generaliser

Deux PRs de renum ouvertes mettent deja le baseline a jour, et de la bonne facon : un renommage chirurgical de la cle qui preserve la valeur de densite, pas une regeneration complete.

# #13797 (Search-15/16 -> 02b/02c) : +3/-3
-    "…/Search-15-NetworkX.ipynb": 772.048,
+    "…/Search-02b-NetworkX.ipynb": 772.048,

# #13804 (QC-Py-Cloud-01 -> 03b) : +1/-1
-    "…/QC-Py-Cloud-01-RiskParity-Composite.ipynb": 2224.667,
+    "…/QC-Py-Cloud-03b-RiskParity-Composite.ipynb": 2224.667,

La regeneration complete est a eviter : elle produirait un diff massif melant des entrees sans rapport avec le livrable — le poison-catalogue que catalog-pr-hygiene.md ferme deja pour COURSE_CATALOG.generated.json.

Acceptance

1. Rattrapage : les 48 cles orphelines resolues — chacune soit renommee vers son chemin actuel en preservant sa valeur, soit retiree si le notebook a reellement disparu (a trancher cle par cle, pas en bloc : une valeur de densite perdue est une mesure perdue).
2. Prevention : que la prochaine PR de renum ne puisse plus l'oublier. Deux voies, a trancher — (a) un organe advisory qui compte les cles orphelines et le signale sur la PR qui renomme ; (b) une ligne dans la procedure de renum. La (a) est preferable : la (b) repose sur la vigilance, et c'est precisement ce qui a produit 48 orphelines.
3. Correction de doc : partout ou l'on suppose un refresh automatique de ce baseline, ecrire qu'il est manuel.

Hors scope

• La couverture du baseline (814 cles pour 1198 notebooks traques) : c'est le filtrage corpus/kind consomme depuis count_exercises.py, pas un defaut.
• Les 20 lignes perimees que le meme renommage Z3-Python-07 laisse dans translations/smt/z3-api.csv : meme classe, autre surface, et le moteur de traduction est sous hold user i18n notebooks : T4 renderer + CI autonome — sortir du moteur qui tourne a vide (mandat user 2026-08-08) #10038. A traiter avec la famille Les CSV de traduction GenAI produisent des rendus non traduits (21 cell_id orphelins, 19 text_en vides) -- et render_notebook.py ne fait que WARN #13546 / fix(translation,#13546): purger 110 lignes CSV orphelines genai + render_notebook --fail-on-stale #13706, pas ici.
• COURSE_CATALOG.generated.json et docs/archive/** : appartiennent respectivement a l'automatisation et a l'histoire. Ne pas les toucher.

Origine

Trouve en arbitrant la reserve Hermes de #13796 (reclassement Z3-Python-07 -> 01b), qui signalait l'instance n° 49. Cette issue porte les 48 autres, que personne ne regardait.

[jsboige]

[CLAIMED] #13815 — myia-po-2026:CoursIA 2026-08-31T11:22Z — Volet Partie 2 (prevention, voie a) : ajouter un organe --check-orphans a scripts/notebook_tools/pedagogy_density.py qui compte les cles orphelines du baseline (chemin absent de git ls-files *.ipynb) et le signale (WARN + compte, non-zero si orphelines) — pour qu'une PR de renum ne puisse plus l'oublier. Rattrapage (48->121 orphelines, cible mouvante mid-campagne renum) DELIBEREMENT differe a la fin de la campagne #13737-13776. paths: scripts/notebook_tools/pedagogy_density.py + scripts/notebook_tools/tests/test_pedagogy_density_orphans.py

[jsboige]

Correction factual a mon claim [CLAIMED] du 2026-08-31 : le chiffre '48->121 orphelines' etait une mesure intermediaire erronee. La verification definitive (organe --check-orphans livre dans cette PR, + git ls-files -- *.ipynb sur origin/main) donne 48 orphelines (814 cles baseline, 1198 notebooks suivis) — il rejoint exactement le 48 de l'issue. Il n'y a donc PAS de 'cible mouvante a 121' : le compte est stable a 48. Le rattrapage des 48 orphelines n'en reste pas moins deliberatehors de cette PR (campagne renum en cours) ; cette PR livre uniquement l'organe de prevention.

[myia-ai-01]

Correction de chiffre + contrainte de séquencement pour le Part 3 (suite à la review Hermes sur #13826).

Le compte d'orphelins est 47, pas 48 — et le 48 initial de cette issue n'était pas une mesure : il dépendait de la config git du lecteur.

Avec core.quotepath à sa valeur par défaut, git ls-files rend un chemin non-ASCII échappé en octal et entre guillemets ("MyIA.AI.Notebooks/GenAI/SemanticKernel/Cr\303\251ateur de mail personnalis\303\251.ipynb"), qu'aucune clé de baseline ne peut égaler. Le 48e « orphelin » était donc un notebook tracké. Le défaut est dans le rendu de git, en amont de tout décodage Python : encoding="utf-8" sur le subprocess ne l'évite pas — seul -c core.quotepath=false le fait. Corrigé par 2f34b99b9 (#13826), avec deux tests portant leur contrôle négatif.

Contrainte pour le Part 3 (wiring CI) — à respecter, sans quoi le gate est rouge à sa première exécution :

• les 47 clés orphelines sont réelles (majorité famille GameTheory renumérotée) ;
• leur rattrapage attend la fin de la campagne de renumérotation [EPIC] Consolidation structurelle du dépôt — audit 30 périmètres (2026-08-31) #13737-13776 — tant qu'elle bouge, une régénération de baseline est périssable ;
• donc le wiring ne peut pas poser un seuil absolu à zéro. Deux formes acceptables : coupler le wiring à une régénération de baseline dans la même PR, ou porter un ratchet ≤ 47 documenté, à faire décroître.

C'est la réserve de séquencement d'Hermes du 2026-08-31T12:34Z, tranchée ici plutôt que reportée.

[jsboige]

→DELIVERED — myia-po-2026:CoursIA c173 (2026-09-02)

PR : #14257

Acceptance #13815 #1 (rattrapage, partie 1/3) — 4/4 :

1. 45 cles orphelines renommees vers leur chemin actuel en preservant la valeur de densite : 28 GameTheory (zero-pad GameTheory-2..9 -> -02..09), 8 PyMC (zero-pad PyMC-2..9 -> -02..09), 8 AI-Engine-WordPress (deplacement racine -> 03-Functional/0X-Y/...), 1 SymbolicAI/Lean (Lean-11-TorchLean-Python -> Lean-11b-TorchLean-Python). Ratio prose_chars/code_cells invariant par git mv, donc preservation valide.
2. 3 cles orphelines retirees (notebooks reellement disparus, valeur perdue) : SemanticKernel/Createur de mail personnalise (supprime en commit 56ec9751 i18n cleanup), QC-Py-Cloud-06-VolTargeting (supprime en PR refactor(qc-py-cloud): resolve Cloud-06 collision (PCA-StatArb vs VolTargeting) #14093 collision resolution, remplacement semantique PCA-StatArb, densite non-transferable), Lean-18-Search-AStar-Optimality (supprime en PR Fix(notebooks,13488): descent Lean-18 to Search/Part1-Foundations (issue 13662) #13685 descent, renommage reintroduit par PR fix(search,#13841): minimal rename Lean-18 -> Search-03e + README attribution fix #14250 OPEN lors de son merge).
3. Orphelines residuelles : 0 (avant 48). count : 814 -> 811.
4. Diff chirurgical : 46 insertions / 49 deletions sur 1 fichier (pedagogy_density_baseline.json). 45 renames = +45/-45 + 3 retraits = -3 + count 814->811 = +1/-1.

Verification post-fix :

• git ls-files '*.ipynb' = 1212 fichiers sur origin/main, intersection baseline = 811/811 (avant 766/814).
• Aucune cle cible n'etait deja dans le baseline (0 doublon cree).
• catalog-pr-hygiene R1 : OK (aucun marqueur CATALOG-STATUS touche, catalogue byte-identique a main).
• Anti-regression D : OK (baseline = mesure sur artefact de production, pas code de production ; cellules notebooks STRICTEMENT inchangees).
• Pre-commit hooks : gitleaks Passed.
• CRLF trap esquite (cf body PR) : open(NB, 'wb') + bytes(utf-8) + b'\n' au lieu de open(NB, 'w') qui aurait produit +818/-821 mecaniques.

Hors scope de cette PR (acceptance #2 prevention + #3 doc) : sortie en PR separee, scope borne au rattrapage chirurgical. Issue de suivi a ouvrir pour la prevention (advisory qui compte les orphelines sur la PR de renum) -- pedagogy-density-advisory.yml est contents: read, ne peut pas refresh tout seul.

Lecon trans-cycle : CRLF trap sur Windows pour serialisation JSON + preservation de l'ordre d'insertion pour minimiser le diff + verify-before-claiming sur 3 issues consecutives avec premise non verifiee (cf #14187 fantome, #14251 supprimes, #14061 fichiers cibles inexistants). Memorise dans python-text-mode-eol-rewrite.md (renforce) + verify-before-claiming.md (renforce).

[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]

[COORDINATEUR] Correction de mon propre commentaire de 04:24Z : l'ordre de merge est dissous, et #14077 est ferme

Mon commentaire d'il y a cinq heures posait un ordre strict « #14077 puis #14137 », au motif que le garde bloquant de #14137 dependait du renommage porte par #14077. Je l'avais ecrit sans mesurer l'etat de main. La mesure change la conclusion.

Ce que main porte deja

#14257 (merge le 2026-09-02T18:25:57Z, commit 8b5a24c05, lane myia-po-2026:CoursIA) a livre le rattrapage : « 45 cles renommees preservant la valeur, 3 retraits ». Verification firsthand ce jour, worktree detache sur origin/main (95bb867), commande exacte du garde de #14137 :

$ 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 (rattrapage) est satisfaite sur main. #14077 et #14257 poursuivaient le meme objectif depuis la meme base de fusion ; c'est #14257 qui est arrive.

Pourquoi #14077 ne pouvait plus merger

Applique sur main, son baseline reintroduit 3 orphelines (rc=1) -- il porte une numerotation perimee :

cle portee par #14077	fichier reel sur main
QC-Py-Cloud-04-RL-DQN-Trading.ipynb	QC-Py-Cloud-10-RL-DQN-Trading.ipynb
QC-Py-Cloud-06-VolTargeting.ipynb	QC-Py-Cloud-13-VolTargeting.ipynb
Lean-18-Search-AStar-Optimality.ipynb	Search-03e-AStar-Optimality.ipynb

Mesure et controles des deux cotes : #14077 (comment) -- #14077 est ferme, branche conservee.

Etat des deux acceptances

Acceptance	Etat	Porteur
#1 -- rattraper les cles orphelines	LIVREE sur main (0 orpheline, rc=0)	#14257 (merged)
#2 -- garde anti-reintroduction	en vol, debloquee	#14137 (OPEN, aucun rouge, nits rc=0)

#14137 n'a plus de dependance d'ordre : il merge des que ses runs concluent. L'issue reste ouverte jusque-la.

Ce que je retiens pour moi

Un ordre de merge que j'ecris est un status condense de plus des qu'un merge passe apres -- ici #14257 avait merge la veille au soir, avant que je redige l'ordre. La regle etait deja la (verify-before-claiming R5, « un body est date de sa redaction, pas de sa lecture ») ; elle vaut aussi pour mes propres notes de coordination, et c'est le cas que je n'avais pas couvert.

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

[jsboige]

[CLAIMED] lane myia-po-2026:CoursIA-2 -- REPAIR P0 #14137 dispatch ai-01 msg-20260904T080211-mh0drv (HIGH) : les 2 corrections verbatim sur .github/workflows/pedagogy-density-advisory.yml (L.59 cancel-in-progress conditionnel + L.72 same-repo parenthésé), paths: .github/workflows/pedagogy-density-advisory.yml -- 2026-09-04T08:14Z