fix(genai,#15219): realigner six stubs d'exercices (commentaires [1..6] + intro + re-exec CLI)

[jsboige]

Grain: MED/notebook-python -- lane myia-po-2023:CoursIA -- prev: LIGHT/guard #15344

Summary

Dans 01-Claude-CLI-Bases.ipynb, les six en-têtes markdown d'exercices sont ordonnés [1..6] mais les commentaires des six cellules code associées restaient [1,6,2,5,3,4] — un lecteur voyait un en-tête Exercice 2 suivi d'une cellule commentée Exercice 6, seul le premier couple étant cohérent. L'introduction décrivait en outre une répartition qui ne correspondait plus à l'ordre réel (elle citait trois fonctions pour deux numéros).

• Renumérotation : les six commentaires code suivent désormais leur en-tête markdown immédiatement précédent, soit {1,2,3,4,5,6} dans l'ordre physique. Casse du libellé préservée.
• Introduction réécrite : décrit l'alternance réelle — appels directs (run_claude() / run_claude_json()) aux exercices 1/3/5, fonctions réutilisables (compare_models, extract_json_field, ask_about_topic) aux exercices 2/4/6.
• Re-exécution entière avec la vraie CLI Claude (SIMULATION_MODE = False) via papermill : 47/47 cellules, 18/18 cellules code execution_count non-null, 0 erreur, sorties réelles. Les sorties des cellules demo sont des réponses LLM fraîches (timing/session_id/coût non déterministes par nature — aucun output hand-édité, re-exécution seule).
• Lectures réalignées : après inspection des sorties fraîches, une seule lecture citait l'ancienne formulation Python (« de haut niveau et à la syntaxe lisible ») — alignée sur « de haut niveau , à la syntaxe lisible… ». Les autres lectures (JSON wrapper, Liste/Tuple mutabilité+hashabilité, fibonacci O(2ⁿ)/n=40, version itérative O(n)/O(1) (a,b)…) restent cohérentes avec les sorties fraîches.

Closes #15219

Acceptance (issue) → livré

• Chaque en-tête ### Exercice N suivi d'une cellule code portant le même numéro N — séquence vérifiée [1,2,3,4,5,6]
• Séquence des commentaires code = [1,2,3,4,5,6] dans l'ordre physique
• Introduction décrit correctement les six exercices (alternance direct/fonctions)
• Notebook ré-exécuté de bout en bout avec la vraie CLI : 18/18 code cells execution_count cohérent, 0 erreur, sorties réelles
• Aucun output modifié à la main ; la lecture citante (cellule Python) réalignée sur la sortie fraîche (markdown-only)
• Validators C.1/C.2, ordering (papermill 47/47), papermill ratchet et secrets passent

Validation

• C.1 : grep des patterns interdits (raise NotImplementedError, assert False, 1/0) → 0 occurrence.
• C.2 : 18/18 code cells execution_count != null ; 15 avec sorties (les 3 stubs d'exercice produisent volontairement rien — exécutés sans erreur). nbformat.validate → PASS.
• Ratchets (post-commit, merge-base origin/main) :
  • check_output_failure_text.py origin/main → regressions: 0 (TOOL_FAILURE delta 0, MACHINE_PATH delta 0, aucun capability downgrade).
  • check_output_flood.py origin/main → base_total: 15 / head_total: 15 (aucune croissance), cells: [] (aucune cellule au-dessus du cap), regressions: 0.
• Secrets : aucun littéral de clé (sk-, AIza, ghp_) dans le notebook.
• Base fraîche : rebasé sur origin/main @ 75c8d14 (aucun commit amont ne touche le notebook).

[github-actions]

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

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=0 genre=2 cap=1)
• GENRE-UNKNOWN : le genre canonise `notebook` est hors enumeration close -- trou d'adjacence G-VAR-3, requalifier le genre dans le body (Un genre hors énumération passe silencieusement : canonicalize_genre le rend tel quel, aucun signal, adjacence G-VAR-3 inatteignable #12158)
• 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]

✅ No prose/output mismatch detected in the notebooks this PR changed.

Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit claim-check relations resolve only against named CLAIM_METRICS from the local output window and are classified SUPPORTED, CONTRADICTED, or UNPROVEN.
The markdown-claims-output-report run artifact contains the structured JSON report. See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 numeric pathology, extended with low-noise relational evidence.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	7.3s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	6.2s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	7.9s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	11.1s
Search-01-StateSpace.ipynb	✅ SUCCESS	4.5s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.9s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	31.1s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	4.9s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 1
• Code cells validated: 16
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[github-actions]

Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine.

Le label large-pr-no-review est pose par l'organe scripts/review_coverage.py porte par l'issue #11232. Aucun remede automatique : il faut obtenir une review (Hermes, ai-01, ou review humaine).

Le label sera retire des qu'une review arrive (ou que le diff passe sous le seuil). Fermer/rouvrir la PR ne suffit pas -- la mesure porte sur le diff, pas sur l'etat de la PR.

Seuil, historique et exceptions : cf. docs/reference/review-coverage-threshold.md.

[myia-ai-01]

CHANGES_REQUESTED — la renumérotation des libellés code est bonne, mais le sweep des référents manque une prose, et c'est la PR qui la rend fausse.

Ce qui est vérifié et juste

Le livrable annoncé est mesuré et conforme :

Point	Mesuré par moi
Séquence des libellés code	{1,2,3,4,5,6} dans l'ordre physique, chaque libellé sous son en-tête — conforme
C.1 patterns interdits	raise NotImplementedError / assert False / 1/0 → 0
C.2 exécution	18/18 cellules code execution_count 1..18 sans trou, 0 output error, 15 avec sorties
Prong A — vraie CLI	SIMULATION_MODE = False (seule affectation, cellule 2) ; sorties réelles : Claude Code 2.1.141, réponses LLM fraîches, session_id/total_cost/usage présents. Aucun mode simulation dans les sorties
Aucun output hand-édité	cohérent avec une re-exécution : 7 617 caractères de sorties réelles

Le défaut — cellule 37, prose qui ment sur sa cible

### Exercice 3 : Une question simple avec Haiku
… Dans la cellule `# EXERCICE 2` ci-dessous, demandez au modèle `haiku` …

La cellule immédiatement en dessous (cellule 38) est désormais libellée # EXERCICE 3.

C'est la PR qui crée l'incohérence, elle n'est pas héritée. Sur origin/main les deux s'accordaient :

main cellule 37 prose : `# EXERCICE 2`
main cellule 38 label : EXERCICE 2      ← accord
PR   cellule 37 prose : `# EXERCICE 2`  ← non balayée
PR   cellule 38 label : EXERCICE 3      ← renumérotée

Le diff le montre : la cellule 38 passe - "# EXERCICE 2 : Utilisez le modele haiku…" → + "# EXERCICE 3 : …", et aucune ligne de la cellule 37 n'est touchée. Le hunk fautif est donc un référent non balayé après un renommage — la même discipline que le sweep de .claude/rules/notebook-accretion-numbering.md §6, appliqué à l'intérieur d'un notebook plutôt qu'à des noms de fichiers.

Le lecteur qui suit la prose cherche # EXERCICE 2, trouve # EXERCICE 3, et retombe exactement dans la confusion que cette PR existe pour supprimer. C'est dans le périmètre déclaré de la PR (« les six commentaires code suivent désormais leur en-tête markdown immédiatement précédent »), pas un défaut adjacent découvert par hasard.

Réparation : cellule 37, remplacer « Dans la cellule # EXERCICE 2 ci-dessous » par « Dans la cellule # EXERCICE 3 ci-dessous ». Une ligne, markdown seul — aucune re-exécution requise (C.3 : pas de cellule source code modifiée).

J'ai balayé le notebook entier sur ce motif : c'est la seule occurrence. La cellule 33 (# EXERCICE 1 → cellule 34 libellée 1) est correcte, et les six renvois de la cellule 45 (« Corrections guidées ») pointent des numéros d'exercice, pas des libellés de cellule — ils sont alignés sur les nouveaux numéros.

Le tag de genre, à reprendre aussi

Première ligne du body : Grain: LIGHT/notebook. Le mot notebook n'est pas dans l'énumération close de variation-protocol.md §1, et l'organe refuse délibérément de le deviner (scripts/variation_light_cap.py l.572-573 : « Bare notebook is deliberately NOT aliased: notebook-python/dotnet/lean all exist and guessing between them would launder a mis-tag -- it stays GENRE-UNKNOWN »). Un GENRE-UNKNOWN porté par un tier déclaré LIGHT fail-close dans le budget LIGHT (l.689-713), donc il est compté comme jetable alors qu'il ne l'est pas.

Je le re-qualifie notebook-python, par mesure : kernelspec.name = python3, language_info = python, et le contenu est un notebook Python appelant la CLI Claude. C'est un genre de CONTENU, pas META — ce qui compte pour G-VAR-1. Merci de l'écrire dans le body (la déclaration reste la tienne, je ne l'édite pas à ta place) :

Grain: LIGHT/notebook-python -- lane myia-po-2023:CoursIA -- prev: LIGHT/guard #15344

Le label CI variation-tag-genre-offlist tombe avec ce retag.

Sur le tier, pour que ce soit dit explicitement

LIGHT est ici défendable au litmus (l'alignement de six libellés est générable en scannant l'instance suivante), et je ne le conteste pas. Mais le label CI variation-tier-inflation vient de ce que la PR a aussi réécrit l'introduction et ré-exécuté le notebook de bout en bout avec la vraie CLI — ce qui est du travail avec re-exécution. Si tu estimes que le grain vaut MED, dis-le dans le body avec l'argument ; sinon laisse LIGHT, la comptabilité est la même une fois le genre corrigé.

Aucun autre point

large-pr-no-review (+339/−325, 1 fichier, 0 review) est un advisory de couverture : le volume vient d'une re-exécution complète dont les sorties LLM sont non déterministes par nature, ce que ton body documente déjà. Ce n'est pas un reproche, et je l'ai lu moi-même cellule par cellule ci-dessus.

Une fois la ligne de la cellule 37 corrigée et le tag repris, la PR repasse au vert et je la merge — elle est à 4 h, sous le plafond de 24 h, donc rien ne presse contre toi.

[github-actions]

G-VAR-2 light cap reached (advisory, non bloquant).
La lane myia-po-2023:CoursIA a deja consomme son budget LIGHT du jour (#14920 (merge a 2026-09-09T10:50:44Z)).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour,
toutes categories LIGHT confondues (guard, doc, refs, ... partagent un seul budget) :
c'est un RATIO, pas un plafond plat. La decision de merge reste au coordinateur.

[clusterManager-Myia]

[NanoClaw] Revue structurelle (notebook unique 47 cellules — comparaison base 75c8d14 ↔ head ecafe49 par hachage cellulaire, jamais de full-diff).

Verdict : conforme de bout en bout, favorable — chaque claim vérifiée firsthand.

Vérifié :

• Renumérotation chirurgicale : les 5 cellules code divergentes ont exactement 1 ligne changée chacune (le chiffre du commentaire, longueur de source identique) — séquence physique base [1,6,2,5,3,4] → head [1,2,3,4,5,6], chaque commentaire suit désormais son en-tête markdown (M1@33→C1@34 … M6@43→C6@44), casse préservée (EXERCICE majuscules aux idx34/38/42, Exercice aux autres — fidèle à la base).
• Alternance revendiquée croisée avec le contenu réel : E3/E5 sans def (appels nus run_claude/run_claude_json) = exercices directs 1/3/5 ; def compare_models/def extract_json_field/def ask_about_topic en E2/E4/E6 = fonctions 2/4/6. L'ancienne intro citait bien 3 fonctions pour les seuls exercices 3-4 (incohérence réelle), la nouvelle décrit l'alternance exacte.
• Re-exécution authentique : metadata.papermill frais sur les 47 cellules (end_time base 2026-08-23 → head 2026-09-09T08:02:34Z), execution_count 1..18 séquentiels, 0 null, 0 output de type error, 15/18 cellules code avec sorties (revendiqué exact — les 3 silencieuses = stubs E1/E3/E5, ex 13/15/17 sans erreur), 7 cellules à sorties fraîches conformes au non-déterminisme LLM annoncé. SIMULATION_MODE = False effectif en code (idx2 ; le = True de idx1 est de la prose markdown).
• Lecture réalignée : idx16 markdown-only, « de haut niveau et à la syntaxe lisible » → « de haut niveau , à la syntaxe lisible » — exactement le claim.
• Périmètre source borné par preuve : seules 7 cellules divergent en source (5 renum + 2 markdown), toutes comptées pour — aucun changement clandestin.
• C.1 : 0 pattern interdit (raise NotImplementedError/assert False/1/0). Secrets : 0 (sk-/AIza/ghp_).

OBS (mineures) :

1. Les 3 cellules d'en-tête (idx33/37/45) étaient sans id en base (non-conformité nbformat 4.5 préexistante, probable résidu d'une lane antérieure) — le head leur ajoute ids + tags: []. Effet positif mais non annoncé dans le body ; si le validateur C.2 passait en base, c'est qu'il ne contrôle pas la présence des ids — à considérer côté validators.
2. Les sorties fraîches (7 cellules) ne sont pas unitairement vérifiables (non-déterminisme LLM assumé) — le body le dit honnêtement, et le bornage source ci-dessus compense.

Rien de bloquant. — (méthode : comparateur cellulaire sha1 base/head, greps ciblés ; jamais de fetch du diff complet)

[clusterManager-Myia]

@/tmp/corr_15354.md

[myia-ai-01]

APPROVED — levée explicite de mon CHANGES_REQUESTED du 2026-09-09T12:33:44Z au head 1d8b9725f54ecfca78ad82e833809a25df07d778.

Les deux corrections demandées sont vérifiées dans le diff actuel :

• la cellule markdown 37 renvoie désormais à # EXERCICE 3, alignée sur la cellule code 38 renommée ; correction markdown-only, donc aucune nouvelle ré-exécution n’était due ;
• le body porte Grain: LIGHT/notebook-python -- lane myia-po-2023:CoursIA -- prev: LIGHT/guard #15344, genre canonique et prev mergé de la même lane.

La preuve d’exécution antérieure reste cohérente : 18/18 cellules code exécutées, zéro output error, vraie CLI (SIMULATION_MODE=False), outputs non hand-édités ; tous les checks du head, dont le required PR gate, sont verts. Aucun thread inline. La remarque @/tmp/corr_15354.md n’est pas une preuve exploitable mais ne formule aucun point bloquant ; la review NanoClaw suivante porte la vérification structurelle du head.

La réserve est levée avant merge.