[EPIC] Nommage canonique et parcours des notebooks — numéros, accrétions, noyaux et catalogue

[jsboigeEpita]

Relance du 2026-09-25 — renommer et dégager le chemin principal, série par série

Décision du mainteneur (2026-09-25). Les deux chantiers de cette Epic avancent trop lentement, et la dette grossit à chaque notebook ajouté sous l'ancien nommage. Ces deux chantiers sont :

• la normalisation des noms : numéros sur deux chiffres, suffixes de noyau, lettres d'accrétion ;
• la consolidation : dégager un chemin de numéros nus qui reste digeste, en faisant redescendre en lettres les numéros trop avancés et les parties avancées de notebooks trop lourds.

Cette section donne l'état de chaque série et le prochain geste. Elle est tenue à jour par ai-01.

Le geste de consolidation, précisé

Une lecture de gradation (procédure ci-dessous) ne se contente plus de classer des fichiers entiers. Elle nomme aussi :

• les parties avancées d'un numéro nu à sortir en lettre, cellule par cellule (identifiants de cellule cités), quand un notebook du chemin principal porte en fin de parcours une matière de niveau Recherche ;
• les numéros élevés qui doivent redescendre en lettre d'un palier existant, parce qu'ils approfondissent un palier au lieu de prolonger l'arc.

La règle 4 tient toujours : rien de validé n'est retiré. La matière déplacée garde ses sorties, re-exécutées (C.2).

Descendre en sous-séries, garder un escalier (arbitrage du mainteneur, 25/09)

Le second geste de consolidation, le plus lent et le plus exigeant : déclutter une série en faisant descendre d'un cran dans l'arborescence les arcs d'accrétions qui forment un sujet autonome, avec leurs lakes, tout en gardant un escalier dans la série mère (règle 6).

• Dossier, pas préfixe. Une sous-série vit dans un sous-dossier de sa série (GameTheory/SocialChoice/, SymbolicAI/Lean/Serre100/). La série Lean est concernée comme les autres.
• Un escalier dans la série mère. Le parcours principal garde une référence explicite vers la sous-série, idéalement un notebook capstone léger : le notebook le plus accessible de l'arc, qui reste alors dans la série mère, ou un notebook à écrire s'il manque.
• Le capstone peut exécuter ou citer le lake de la sous-série : c'est la forme recommandée. Un lake descend donc même si un notebook du chemin principal le consomme ; celui-ci le référence par son nouveau chemin. Pas de dossier lean/ générique : les lakes suivent leur sous-série.
• Finir les deux modèles avant de les copier. Serre100/ a son lake dans son dossier mais aucun escalier depuis la racine Lean. SocialChoice/ n'a pas de capstone, et ses lakes sont restés à la racine de GameTheory.
• Ordre : les deux pilotes, puis les sous-séries Lean de [Lean] Gradation du chemin principal a partir de Lean-10 + sous-series (Lean et IA, Conway, verification, formalisations) — fille #5081 #17545 (Grothendieck, Conway, nœuds, MIMO, analyse), puis les arcs de GameTheory que nommera la lecture GameTheory(#14944): passe de coherence de gradation de la serie apres renum — la sequence refermee n'a pas la gradation des premiers numeros #15615, puis les arcs de maturation d'ICT. Chaque descente de lake suit le protocole en 5 points de [EPIC] Lean — harmoniser Mathlib, mutualiser les checkouts, regrouper les lakes (anti-proliferation) #4362.

État et prochain geste par série

Série	Issue	État au 25/09	Prochain geste	Lane
Complexity	#17063	décidée le 23/09 ; 01 à 03b livrés (#17593, #17662)	finir 04 à 06 et leurs lettres, puis le README	po-2025:CoursIA
Lean	#17545, avec #16231 pour les suffixes	décidée le 24/09 ; sous-séries en dossiers avec leurs lakes (25/09, #4362)	la PR-drift tout de suite ; l'escalier vers Serre100 (pilote) ; puis une PR par sous-série, dossier et lake, dès que la lane repasse sous son cap WIP	po-2026:CoursIA
Argumentation	#17547	PR 1/3 #17718 : levées posées, nouveau dossier attendu. PR 3/3 : #17765	merger 1/3, puis 2/3 et 3/3 ; le README suit	po-2027:CoursIA
GameTheory	#14944, #15615, #16231 (chantier C)	tranche A livrée le 11/09 (#15586) ; chantier C : PR-1 et PR-2 mergées, PR-3 repliée dans le passage qui suit la gradation (c.5829587332)	lecture de gradation #15615 d'abord (elle nomme aussi les arcs à descendre en sous-série), puis un seul passage de renommage (branche 03 comprise), puis le lot lakes de #4362 et le pilote SocialChoice (capstone, lake dans le dossier)	po-2023:CoursIA
Probas	#14873	phase A livrée le 25/09 ; décision ai-01 postée sur l'issue	P1 à P4 de la recommandation, puis lecture de gradation	po-2024:CoursIA
SMT / Z3-API	#16763	22 notebooks sur 24 au canon	Z3-17 tout de suite ; Z3-13 après #17678	po-2024:CoursIA-2
ICT	#11840, #11690	renommages 01-09 réclamés le 15/09, sans nouvelle depuis	re-mesurer, puis reprendre ou relâcher le claim en le disant ; nommer les arcs de maturation candidats à une sous-série	po-2027:CoursIA
Search (Python et C#)	fille à ouvrir	suffixes normalisés (#17363)	lecture de gradation	po-2027:CoursIA
ML	fille à ouvrir	—	lecture de gradation	po-2023:CoursIA-2
SemanticWeb, Tweety	#5669, #16008	analyses de nommage antérieures à la doctrine	relecture de gradation sous la doctrine	po-2027:CoursIA-2

Une lecture de gradation est un livrable de lecture : un commentaire sur l'issue fille, sans aucune PR. Elle ne compte donc pas dans le cap WIP. ai-01 tranche dans les 24 heures.

Le README d'une série se refond en dernier dans l'arc de la série. La forme cible est décrite dans #3973. Les READMEs de famille qui agrègent plusieurs arcs (GameTheory, SymbolicAI…) sont portés par ai-01.

---

Doctrine de gradation : les deux dimensions (mandat user du 2026-09-23)

Le user a validé la décision Complexity (#17063) comme modèle, avec cette consigne : « globalement on devrait faire ça sur toutes les séries ». Cette section étend donc à toutes les séries ce que le canon ci-dessous posait pour le nommage. Le numéro et la lettre ne classent pas des fichiers : ils portent deux dimensions pédagogiques.

Dimension	Ce qu'elle porte	Ce qu'on y met	Ce qu'on n'y met jamais
Numéros nus (01, 02, …)	l'arc narratif de la série, lisible par qui la découvre	un concept principal par notebook, qui ne suppose que ce qui le précède	un résultat de recherche, un preprint, une conjecture récente, une chronologie historique
Lettres (b, c, …)	la profondeur : approfondissement, recherche, hommage, variante	la matière pointue actuelle, conservée et re-exécutée	un prérequis dont un numéro suivant aurait besoin

Règles de fabrication (critères de review, toutes séries)

1. Chaque numéro nu s'ouvre sur « Ce que ce notebook suppose », qui pointe vers un numéro antérieur ou vers rien, et porte une étiquette de public : Découverte, Licence ou Recherche. Un numéro nu étiqueté Recherche est un défaut.
2. On lit les numéros nus sans avoir ouvert une seule lettre.
3. Chaque lettre s'ouvre sur un lien vers sa base et nomme les prérequis qu'elle ajoute.
4. Rien de validé n'est retiré : la matière avancée déménage en lettre, avec ses sorties re-exécutées (C.2).
5. Un nouveau notebook de recherche ne prend pas un nouveau numéro nu. Il entre comme lettre de la base la plus proche, ou dans une sous-série. S'il manque la marche simple qui le précéderait, on la nomme, puis on l'écrit.
6. Sous-série : quand une plage de numéros ou de lettres forme un arc autonome (Lean et IA, Conway, formalisations d'un domaine…), elle descend dans un dossier de la série, avec son propre arc gradué, son README et ses lakes. La série mère garde un escalier : une référence explicite depuis son parcours principal, idéalement un notebook capstone léger qui présente la sous-série et peut exécuter ou citer son lake (arbitrage du mainteneur du 25/09, détail sur [EPIC] Lean — harmoniser Mathlib, mutualiser les checkouts, regrouper les lakes (anti-proliferation) #4362 c.5829716177).
7. Le README de série rend les deux dimensions visibles. La table du parcours principal ne porte que les numéros nus, avec une colonne public et une colonne « pour approfondir » où les lettres ne sont que des liens. Les lettres sont décrites à part, palier par palier. Forme complète : [EPIC] README ascendant — resynchroniser la hiérarchie (feuilles -> principal) depuis l'évolution du dépôt #3973, refonte du 2026-09-25.

Procédure par série

Une lane lit les contenus, pas les titres. Elle poste sur l'issue fille le tableau « chemin principal / lettres / sous-séries / marches manquantes », l'impact des renommages (liens, tests, baselines, cellules de code qui citent des noms de notebooks, CI), puis le séquencement des PRs. ai-01 tranche dans les 24 heures : un arbitrage de curriculum ne dort pas dans une issue (#17063 a attendu trois jours). Seul un changement de périmètre de série remonte au user.

Série	Issue fille	État
Complexity	#17063	décidée le 23/09 : c'est la référence
Lean	#17545	à cadrer : numéros 10 à 34 sans socle, Conway et nœuds sans base, sous-séries candidates
Argumentation (Argument_Analysis)	#17547 (mesures de base : #14950)	à cadrer : 10 numéros sur 33 notebooks, deux arcs non articulés
GameTheory	#15615	à relire sous cette doctrine
Probas	#14873	à relire sous cette doctrine

Les autres séries viennent ensuite, dans l'ordre où un étudiant les rencontre.

---

État vivant — relance du 2026-09-10

Cette Epic reste le programme canonique unique de consolidation des noms, numéros, accrétions et parcours. Elle n’est pas remplacée par une nouvelle Epic. Les décisions et livraisons historiques sont conservées intégralement sous ce préambule, mais les tableaux anciens ne constituent plus un état courant.

Mandat consolidé

Le livrable final est le catalogue rendu dans un navigateur : chaque notebook pédagogique propre à CoursIA doit y apparaître sous un nom français, descriptif et ordonnable, avec une hiérarchie série → sous-série lisible et des comptes qui se réconcilient exactement.

Le canon cible est :

<PrefixeSerie>-<SousSerie?>-<NN><accretion?>-<TitreFrancais>-<Noyau>.ipynb

Élément	Règle
Préfixe	obligatoire, stable et représentatif de la série ; la sous-série est explicite lorsqu’elle porte un arc autonome
Numéro	deux chiffres (00 à 99) ; tous les notebooks ont un numéro
Numéros nus	constituent le speed run : leur lecture dans l’ordre couvre tous les domaines essentiels de la série
Accrétions	la base vaut implicitement a ; les approfondissements commencent à b, puis c, etc. ; une lettre différente suppose un contenu substantiellement distinct
Orientation	00 porte la présentation/setup et 00b, 00c ses annexes ; si 01 joue déjà ce rôle, ne pas créer artificiellement 00 et rattacher les annexes à 01b, 01c
Profondeur	absorber les contenus proches dans un notebook plus riche plutôt que multiplier les lettres ; si plusieurs sujets deviennent réellement autonomes, créer une sous-série et un notebook bridge
Noyau	suffixe obligatoire et à casse canonique : Python, CSharp, Lean, etc. ; deux implémentations analogues partagent préfixe, numéro, accrétion et titre, seul le suffixe change
Français	le titre sémantique et le H1 sont français ; le slug de fichier reste portable et professionnel, avec les règles d’encodage du dépôt
Exceptions	uniquement conventions externes/vendored ou plateformes imposées, inscrites explicitement dans l’inventaire ; jamais d’exception silencieuse

Baseline reproductible au 2026-09-10

Mesure sur origin/main b474cf8f3030d7b90d5c2e798599a45ee38c7211, via git ls-tree, hors checkpoints, .lake et _output :

Mesure	Valeur	Lecture
notebooks pédagogiques scannés	1 244	dénominateur courant
noms reconnus par la grammaire historique	832	412 restent hors parseur historique
noms non reconnus	412	à classifier avant tout renommage ; inclut des conventions de plateforme/sous-série
indices à un chiffre dans une famille allant au moins jusqu’à 10	208	dette de padding encore visible
suffixes reconnus	Csharp 113 · CSharp 16 · Python 43 · Lean 4	casse et couverture hétérogènes
sans suffixe reconnu par cette mesure	1 068	signal à inventorier ; pas une preuve que le kernel est inconnu

Commande de mesure à conserver dans l’issue fille d’inventaire : scanner les chemins suivis par Git, publier le dénominateur, distinguer « non parsé », « kernel inféré » et « exception justifiée ». Aucun chiffre de ce tableau ne décide seul d’un git mv.

Axes vivants et résidu

Axe	Tracker	État vérifié	Résidu
doctrine numéros / lettres	#5081	actif ; règle notebook-accretion-numbering.md présente sur main	intégrer le canon complet ci-dessus, notamment tous numérotés + noyau obligatoire + sous-séries/bridges
padding, titres et noms	#11840	Phase 1 livrée ; plusieurs pilotes paddés	inventaire global, suffixes noyau, titres français et rollout série par série
parité des variantes	#12933	garde NUMBERING-DRIFT livré ; inventaire DecisionTheory livré	même slot et même titre pour les variantes analogues ; mapping restant par famille
GameTheory	#14944	tranche A annoncée, tranche B explicitement gatée	confronter le label candidate-delivered à la livraison réelle ; traiter GT-03 après levée du gate
Search padding	#14545	clos/livré	aucun nouveau tracker concurrent
ICT	#7260 et #11690	consolidation et lecture déjà engagées	traiter sous cette doctrine, sans dupliquer le toolkit scientifique #15475
libellés de liens	#14624 / PR #14625	organe livré	résorber le stock restant puis câbler l’advisory/fast lane
inventaire canonique	#15488	ouvert	classifier chaque notebook, kernel, cible, exception, référents et collision
gardes pré-renommage	#15489	ouvert	collision rename-aware, suffixe noyau, réservation de slots et parseur partagé
catalogue rendu	#15490	ouvert	hiérarchie, basenames cliquables, totaux exhaustifs, statuts futurs et QA navigateur
équité du picker	#13420 / #15491	ouvert	âge de dernière livraison réelle par Epic, instrumentation puis calibration

Séquencement anti-collision — obligatoire

1. W0 avant tout nouveau rollout : inventaire canonique, mapping proposé, gardes de collision/suffixe/slot et tests positifs.
2. Une série, une lane, une fenêtre : claim GitHub paths: et vérification des PR ouvertes avant édition.
3. Publier la table actuel → cible → geste → justification → référents avant chaque vague.
4. Un notebook n’est renommé qu’une fois : padding, préfixe, titre, séparateur et suffixe noyau sont regroupés dans sa vague.
5. Une PR de renommage ne modifie pas le contenu pédagogique ; une consolidation de contenu est une PR distincte avec preuve de préservation.
6. Tous les référents vivants sont mis à jour atomiquement : notebooks, README/docs, _quarto.yml, workflows, tests, baselines, registres twins, sidecars et consommateurs cross-dépôt connus.
7. COURSE_CATALOG.generated.*, les marqueurs CATALOG-STATUS et les traductions bot-owned restent byte-identiques sur la branche feature ; l’automatisation les régénère.
8. Aucun renommage ne démarre sur une famille touchée par une PR ouverte ou une vague de normalisation concurrente (dont Split #15146 en 8 sous-PRs atomiques par famille (T1-T8) — résidu acceptance #14209 #15429 tant que ses tranches ne sont pas stabilisées).

Critères de sortie globaux

• Inventaire canonique exhaustif, versionné et reproductible, avec exceptions explicites et collisions calculées.
• Tous les notebooks pédagogiques propres au dépôt respectent le canon adopté ; chaque exception restante est nommée et justifiée.
• Les numéros nus de chaque série forment un speed run complet ; les approfondissements sont rattachés à leur parent ; les branches trop profondes sont absorbées ou promues en sous-séries avec bridge.
• Les variantes analogues partagent le même identifiant et le même titre, avec parité suivie.
• Les gardes empêchent collision, padding régressif, suffixe non canonique, chemin twin mort et libellé de lien mensonger.
• Le générateur de catalogue affiche série → sous-série/root, basename canonique cliquable, titre explicite, kernel, statuts et totaux réconciliés.
• Le rendu Quarto/GitHub est vérifié en navigateur, desktop et mobile, sans erreur console ni table tronquée.
• Chaque vague de renommage prouve zéro référence vivante vers les anciens chemins et laisse les artefacts bot-owned hors diff.

---

Historique conservé

Mandat user (2026-07-03, verbatim)

Pour les nombreux nouveaux notebooks rajoutés, je pense qu'il faudra une issue pour repenser la numérotation dans un arc narratif et pédagogique cohérent. Les sites officiels peuvent aider parfois, comme pour Infer ou PyMC ; en tout cas souvent, les numéros se suivent simplement à l'opportunité des derniers ajouts alors qu'une renumérotation s'impose.

Problème

Le débit récent (150 PRs mergées les 1-2/07) a ajouté beaucoup de notebooks en fin de série (Infer-18/19, ICT-11/12/13, Search-14, QC-Py-40, Tweety C# 2b/2c/3/4...) : la numérotation suit l'ordre d'arrivée, pas la progression pédagogique. Résultat : des arcs narratifs cassés (un notebook « frontière » inséré après un notebook de synthèse, des ports C# numérotés hors de leur jumeau Python, etc.).

Méthode

1. Une série à la fois (fille issue par série), en commençant par celles qui ont le plus bougé : Probas/Infer, Probas/PyMC, ICT, Search, Tweety, QC-Py.
2. S'appuyer sur les progressions des sites officiels quand elles existent : tutoriels Infer.NET (docs Microsoft), galerie PyMC (pymc.io examples), etc. — l'ordre canonique upstream est souvent le bon squelette narratif.
3. Chaque renumérotation = PR dédiée : rename + sweep complet des références entrantes (leçon refactor(infer): extraction de l'arc décision vers DecisionTheory/Infer/ + gap-closure bayésien #4737→fix(links): repair inbound refs broken by Infer restructure (#4737) #4743 : un rename casse les liens inbound hors du dossier) + check_docs_links --check sur la branche.
4. Catalogue intouché sur branche (cron-owned, .claude/rules/catalog-pr-hygiene.md).
5. Re-exécution non requise si seuls les noms/liens changent (C.2 : modifs markdown/rename), mais vérifier que les papermill paths internes ne référencent pas l'ancien nom.

Précédents (modèles)

• [Lean] Rationaliser numérotation + progression pédagogique de la série (doublon 15, Finiteness-Derivatives hors bloc Conway) #3843 (CLOSED) : rationalisation numérotation série Lean — le modèle de fille issue.
• [Epic Conway] Renumerotation : Lean-14 (GoL) -> Lean-14b — la bio (14a) doit etre le premier de la serie #2258 (CLOSED) : renumérotation Conway Lean-14 → 14b (la bio d'abord).
• refactor(probas): extraire la théorie de la décision dans Probas/DecisionTheory/{Infer,PyMC} — fin de l'entrelacement Bayésien→Décision→Bayésien #4725 (CLOSED) : extraction DecisionTheory Probas — restructuration réussie avec sweep de liens.

Acceptance

• Fille issue par série avec l'arc narratif cible explicité en table (ordre actuel → ordre cible → justification pédagogique).
• Renumérotations livrées en PRs atomiques, liens entrants réparés, CI check-links verte.
• READMEs de série resynchronisés dans la même PR (anti-drift prose↔structure).

Part of #4208 (référence publique — axe D finition).

---

Amendement doctrinal — mandat user 2026-08-30 (verbatim)

Il faudra armer un mouvement qui consolide les notebooks avec 2 directions orthogonales :

• les numéros
• les lettres

Les numéros permettent d'aller jusqu'au bout de la série. On doit pouvoir les lire dans l'ordre pour un premier survol complet. Les lettres permettent des approfondissements optionnels. Mais il faudrait également les consolider et les hiérarchiser.

Au final, ce mouvement devrait aboutir à diminuer le nombre de numéros, créer quelques nouvelles accrétions de lettres, et puis en supprimer d'autres par les jeux de consolidation dans des lettres antérieures.

Ce mécanisme devrait être généralisé de partout, y compris dans ICT, et on devrait essayer de systématiser les numérotations avec padding zéro un peu de partout. Les paires csharp doivent avoir également une politique de numérotation consistante, ça ne me gêne pas qu'elles partagent le même numéro et accrétion.

[...] c'est une issue potentiellement source de conflits de merges, donc à traiter avec prudence, et une dette technique qu'il faudra bien payer.

Ce que l'amendement change par rapport au mandat de 2026-07-03

Le mandat initial demandait un arc narratif au lieu d'une numérotation d'opportunité. Il ne disait pas combien de numéros une série doit avoir. C'est ce que cet amendement tranche, et il donne aux deux axes un rôle fonctionnel distinct :

Axe	Rôle	Critère de décision	Effet sur le compte
Numéros	la colonne vertébrale : le chemin complet et suffisant. Un lecteur qui lit 01, 02, 03… dans l'ordre a fait un survol complet de la série, sans trou et sans détour.	« ce notebook est-il nécessaire au survol complet ? » Si on peut faire le tour du sujet sans lui, ce n'est pas un numéro.	diminue
Lettres	les approfondissements optionnels, accrochés au numéro dont ils dépendent. Sautables sans casser la lecture.	« de quel numéro cet approfondissement dépend-il ? » — la réponse est son adresse.	augmente (accrétions) et diminue (absorptions)

Le mouvement n'est donc pas un renommage : c'est une requalification. Trois gestes, et un seul est un simple git mv :

1. Démotion — un numéro non nécessaire au survol devient une lettre de son numéro-parent (X-20-Sujet → X-09b-Sujet). C'est le geste qui fait baisser le compte de numéros ; c'est le grain déjà instruit par Reorganisation : ranger en sides (-b/-c) les ajouts recents qui ont pris un numero sequentiel (GT-19..23, Lean-25/26, Audio 04-7..13, ICT-Life, rlpt_, Planners-13) #12375.
2. Accrétion — un approfondissement neuf naît lettre, jamais numéro. C'est le geste qui empêche la dette de se reformer : sans lui, chaque vague d'ajouts reprend un numéro frais et le travail est à refaire.
3. Absorption — deux lettres voisines traitant la même matière fusionnent dans la plus ancienne (X-06c + X-06d → X-06c enrichi). C'est le geste qui supprime des lettres, et le plus risqué : il détruit du contenu s'il est mal fait. Il exige une preuve de préservation (« Consolider != Archiver »), donc une PR dédiée qui cite ce qui a été fusionné et où il vit — jamais un git rm.

Baseline mesurée le 2026-08-30

git ls-files sur MyIA.AI.Notebooks/**/*.ipynb, hors _output, .lake, checkpoints ; séries d'au moins 8 notebooks.

Mesure	Valeur	Lecture
numéros entiers distincts	411	la surface que le mouvement doit faire baisser
numéros portant ≥1 lettre	66 (16 %)	les lettres sont sous-employées : 84 % des numéros n'ont aucun approfondissement rattaché
slots-lettres existants	118
lettres de profondeur 2 (ab, bc…)	0	la hiérarchisation des lettres est un terrain vierge — rien à consolider, tout à concevoir
séries zéro-paddées	1 sur 58 (5 mixtes, 52 non paddées)	dette de padding quasi totale

⚠ Ce que ces nombres ne disent pas. Ils viennent d'un motif <prefixe>-<num><lettre?>-<slug> appliqué aux noms de fichiers : ils ne mesurent ni le contenu, ni la nécessité pédagogique d'un notebook. « 411 numéros » n'est pas « 411 numéros de trop » — c'est la surface à instruire, série par série. Aucune démotion ne se décide sur ce tableau ; il dit seulement où le travail est.

Cinq séries n'entrent pas du tout dans le motif — GenAI/Texte (29 nb), DataScienceWithAgents/02-ML-Cours (20), GenAI/SemanticKernel (19), Z3-Linq2Z3 (18), QuantConnect/research (17) : zéro notebook numéroté. Pour elles la question n'est pas la requalification mais l'existence même d'une colonne vertébrale — grain distinct, à ne pas confondre avec celui-ci.

Politique des paires C# — elle existe déjà, il faut la généraliser

Le user tranche : « ça ne me gêne pas qu'elles partagent le même numéro et accrétion ». GameTheory le fait déjà, et devient donc le modèle de référence plutôt qu'un cas à corriger :

GameTheory-04c-NashExistence-Csharp.ipynb              +  GameTheory-04c-NashExistence-Python.ipynb
GameTheory-06c-RepeatedGames-FolkTheorem-Csharp.ipynb  +  GameTheory-06c-RepeatedGames-FolkTheorem.ipynb

Numéro et lettre partagés ; seul le suffixe de langage distingue. C'est cohérent avec la doctrine : le jumeau C# n'est pas une étape de plus du survol, c'est la même étape dans une autre implémentation. Lui donner un numéro propre gonflerait la colonne vertébrale d'un facteur ~2 sans ajouter une seule étape au parcours.

Conséquence pour #12933 (renumérotation paritaire) : son constat DecisionTheory — DecInfer-3 ⇄ DecPyMC-2, sept concepts décalés d'un cran par l'insertion du companion Lean DecInfer-2 — se résout par cet amendement. Le companion formel est un approfondissement, donc une lettre (DecInfer-01b-Lean-ExpectedUtility), et l'alignement des sept suivants tombe de lui-même. #12933 n'appelle pas une politique séparée : elle est une application de la doctrine.

Deux défauts mesurés au passage, à traiter dans la fille GameTheory :

• slot 06d porte deux sujets distincts (StatiqueComparative-Sympathie et Sympathie-vs-Engagement) — vraie collision, pas une paire de jumeaux ;
• slot 02 porte quatre fichiers via un motif -Part2 concurrent de la convention des lettres (-Part2 devrait être une accrétion).

Padding zéro

Cible : deux chiffres (01…99) dans le nom de fichier. Le padding n'est pas cosmétique : sans lui, le tri lexicographique d'un ls, d'un explorateur de fichiers ou d'un README rend 1, 10, 11, 2, 20… — c'est-à-dire qu'il casse exactement la propriété que les numéros existent pour porter. Une série non paddée au-delà de 9 notebooks ne se lit pas dans l'ordre, quelle que soit la qualité de son arc.

Généralisation ICT

Le mandat nomme ICT explicitement. Les deux filles existantes — #7260 (renumérotation) et #11690 (consolidation) — se lisent désormais sous la doctrine : ICT porte 34 numéros pour 7 numéros lettrés, et aucune de ses 61 entrées n'est paddée. C'est la série où l'écart entre « ce qui est nécessaire au survol » et « ce qui a pris un numéro à l'arrivée » est le plus large du dépôt.

Prudence — dette conflictogène, séquencement obligatoire

Le user le dit lui-même. Un git mv de notebook touche : le fichier, les liens entrants hors du dossier, les README de série, les navlinks, le registre de jumeaux, et les entrées de catalogue générées. Deux lanes qui renomment dans la même série produisent un conflit que ni l'une ni l'autre ne sait résoudre proprement.

En plus de la méthode 1-5 ci-dessus :

• Une série à la fois, une lane à la fois. [CLAIMED] … paths: MyIA.AI.Notebooks/<serie>/** obligatoire — scope de fichiers explicite, jamais epic-wide.
• Requalification et enrichissement ne voyagent pas ensemble. Une PR qui renomme ne modifie aucune cellule ; une PR qui enrichit ne renomme rien. Mêlées, elles rendent le diff illisible et le conflit inarbitrable.
• Catalogue byte-identique à main sur la branche — le cron le régénère (catalog-pr-hygiene.md). C'est la source n°1 de conflit sur ce type de PR.
• L'absorption exige sa preuve de préservation, citée dans le corps de la PR.

Axes et filles

Axe	Issue	Rôle sous la doctrine
Démotion numéro → lettre	#12375	audit déjà instruit (GT-19..23, Lean-25/26, Audio 04-7..13, ICT-Life, Planners-13) — c'est le geste 1
Parité des séries jumelles	#12933	application de « même numéro, même accrétion »
Padding + uniformisation des noms	#11840	cible deux chiffres
ICT	#7260, #11690	généralisation nommée par le mandat

Acceptance de l'amendement

• Chaque fille de série produit une table de requalification : nom actuel → nom cible → geste (démotion / accrétion / absorption / padding) → justification, avec le nombre de numéros avant/après.
• Une fille ne se ferme pas sur un renommage seul : la propriété à vérifier est que la lecture des numéros dans l'ordre constitue un survol complet de la série — énoncée et vérifiée dans le corps de la PR.
• Toute absorption cite ce qu'elle a préservé et où.
• Aucun grain de ce mouvement ne touche deux séries à la fois.

[jsboige]

Dispose PR #5171 → repost audit narratif + plan 8 PRs comme commentaire Epic

Cette PR (audit narratif livrée en C201 par po-2023) est disposée : son contenu (10 problèmes transversaux P1-P10 + plan 8 PRs atomiques) est reposté ici comme commentaire Epic pour rester centré sur l'EPIC parent et archivé publiquement via la timeline GitHub. La branche docs/5081-audit-numerotation est préservée (contenu non perdu) ; l'audit est actif comme commentaire Epic pour les futurs cycles workers.

10 problèmes transversaux (P1-P10) — audit C201

• P1 Numérotation opportuniste (trous inexpliqués QC-Py-29, QC-Py-36..39, sauts 23b/7b)
• P2 Conflits de préfixes (Infer-1 désigne à la fois Gaussian Mixtures ET Utility Foundations selon le dossier)
• P3 Incohérence stylistique des séparateurs (Infer-1-Setup vs 1_OpenAI_Intro vs QC-Py-01-Setup)
• P4 Suffixes langue/outil proliférants (-Csharp/-Python/-Csharp-Python)
• P5 Séries préfixées m1..m12 à côté de QC-Py-NN-* = parcours étudiant illisible (QC)
• P6 Numérotation prématurée (ICT-16..19 = engagement roadmap future, pas arc actuel)
• P7 Frontière floue racine vs sous-dossier (5 notebooks Search racine, Part3-Advanced vide)
• P8 Lecture pédagogique faible (Infer 15-19 = ajouts thématiques en queue d'arc original)
• P9 Absence d'index de correspondance entre les notations
• P10 Cloud vs Local non distingués (QC-Py-NN vs QC-Py-Cloud-NN)

Plan d'action 8 PRs atomiques

#	PR cible	Scope	Effort	Statut
1	Sudoku-7b → Sudoku-19 (Lean Propagation)	1 renommage + 1 redirect README	~30 min	LIVRÉE PR #5187
2	5 notebooks Search racine → Part1-Foundations	5 renommages + 1 README	~1h	À planifier (po-2023 C205+)
3	DecisionTheory/Infer → DecInfer	10 renommages + 1 README	~1h	À planifier (po-2023 C206+ ou po-2025 selon partition)
4	DecisionTheory/PyMC → DecPyMC	7 renommages + 1 README	~1h	À planifier (po-2023 C207+ ou po-2025 selon partition)
5	Table de parité cross-série	1 fichier docs/reference/notebook-parity-table.md	~1h	LIVRÉE PR #5177 C202 (MERGED via #5178 chain)
6	QC-Py trous 29, 36-39 (bouchage OU renumérotation)	1 PR	~2h	À discuter (G.4 composite?, assigné po-2024)
7	GenAI/Texte alignement 01-1-...	20 renommages	~2h	À discuter (PR atomique, assigné po-2023 lane GenAI)
8	Documenter transition IIT → ICT	1 fichier docs/suivis/iit-ict-transition.md	~30 min	À planifier (po-2023 C210+)

Total estimé : 8-10 PRs atomiques sur ~6-10 cycles workers, dispatcher à po-2023/2024/2025 selon partition dominante.

PR #5187 LIVRÉE (PR #1 plan C201)

Fichier	Type	Détail
MyIA.AI.Notebooks/Sudoku/Sudoku-7b-Lean-Propagation.ipynb → Sudoku-19-Lean-Propagation.ipynb	RENAME (99%)	3 cellules internes modifiées (titre H1 + papermill metadata)
MyIA.AI.Notebooks/Sudoku/README.md	MODIFY (2 lignes)	Paragraphe introductif + table inventaire
scripts/notebook_tools/tests/test_validate_pr_notebooks.py	MODIFY (1 ligne)	Docstring regression guard #5151

Diff : 3 fichiers / 6 insertions / 6 deletions (scope chirurgical, R3 atomique).

catalog-pr-hygiene R1-R4 : R1 catalogue byte-identique origin/main ✓ ; R2 branche fraîche depuis origin/main 4ee811580 ✓ ; R3 atomique ✓ ; R4 See #5081 ✓.

H.3 : 16 cellules (12 markdown + 4 code Lean), 0 execution_count=None, 0 red-flag C.1 ✓.

Vérifications post-merge : catalog-cron quotidien régénèrera COURSE_CATALOG.generated.{md,json} avec le nouveau nom Sudoku-19-Lean-Propagation (R1 respectée : catalogue non régénéré sur la branche).

Suite (deep-queue C204+)

• C205+ : PR Genetic sharp playground #2 (Search racine → Part1) = quick win ~1h, à dispatcher selon partition dominante. PAS fix(docs): accents manquants dans les READMEs francophones #2876 accents (filler anti-tunneling).
• Cross-référence : PR création du doscier projet #5 table parité déjà LIVRÉE — cette ligne devient une contribution close de l'EPIC, à retirer du plan ou marquer LIVRÉE.