Docs(app13,#18144): realigne la prose TSP sur les instances executees

[jsboige]

See #18144

Hors flotte (exemption #17713).

Summary

• La prose du carnet attribuait a TSP-10 des instances de 8, 20 et 30 villes, et appliquait l'optimum 277.23 (instance a 8 villes) a des heuristiques tournant sur 20 villes. Les mesures de la prose sont maintenant rattachees a l'instance de la cellule qui les produit ; les affirmations generiques de litterature restent telles quelles.
• La force brute (cellule 6f93a533, code[2]) passe a TSP-10 (generer_aleatoire(10), la meme instance que tsp de code[1]). Optimum exact 290.31, verifie par Held-Karp hors carnet. Les heuristiques restent sur TSP-20 et ne sont pas comparees a cet optimum.
• Les temps et couts de la prose sont realignes sur une re-execution fraiche du carnet (py313, 61 s, sans cle). Le benchmark « typique sur TSP-50 », dont aucune valeur n'etait imprimee par le carnet, est remplace par le tableau mesure sur TSP-30. Les lectures qui citent une sortie sont deplacees juste apres la cellule citee.

Changes

4 fichiers : le carnet MyIA.AI.Notebooks/Search/Applications/Hybrid/App-13-TSP-Metaheuristics.ipynb et, pour la ré-attestation de sa paire jumelle, le YAML parent et deux entrées du registre scripts/notebook_tools/twin_pairs.d/ (voir « Parité des jumeaux »).

• Code : une seule cellule modifiee, 6f93a533 (force brute) : generer_aleatoire(8) devient generer_aleatoire(10). Aucune autre cellule de code n'est modifiee, ajoutee ou deplacee.
• Sorties : toutes les sorties des cellules de code sont regenerees par papermill (valeurs, temps, figures PNG). Le bloc metadata.papermill et la version du kernel (3.13.16) suivent cette execution. Papermill a aussi donne un identifiant aux deux cellules markdown qui n'en avaient pas (Lecture du recuit ..., Lecture du benchmark ...).
• Markdown, realignement : introduction (version Python), section 2 (14!/2), section 3 (force brute sur TSP-10, optimum 290.31), section 4 (NN sur TSP-20), section 5 (2-opt sur TSP-20, max_iter), section 6 (SA), section 7 (GA), section 8 (ACO), section 9 (benchmark TSP-30, tableau mesure), section 10 (OR-Tools sur TSP-30), interpretation du Bonus 2 (TSP-40), conclusion (ligne TSP-10, GA + 2-opt sur TSP-40).
• Markdown, lectures deplacees : 9 cellules markdown ajoutees, chacune juste apres la cellule de code qu'elle cite (lectures de code[0], code[1], code[2], code[3], code[4], code[7], code[8], code[9], code[11]). Le carnet passe de 53 a 62 cellules.
• Markdown, passages retires : la lecture SA dupliquee dans la section 6 (elle figure deja dans la cellule ancree sur code[5]) ; la phrase « Pattern typique » chiffree de la convergence (valeurs non imprimees par le carnet) ; la limite « TSP-10 gap < 5 % » et « TSP-100+ » (non mesurees) ; la reference interne « cas Prong B (sota-not-workaround) » (jargon de harnais, pas de la pedagogie).

Verdicts

#	Constat	Verdict	Preuve
1	Force brute sur 8 villes (7! = 5 040 permutations) alors que la prose parle de 9! et « 0.007s pour TSP-10 »	CONFIRMED	code[2] : tsp_small = TSPInstance.generer_aleatoire(8) ; sortie committee Solution optimale: 277.23 / Temps de calcul: 0.007s ; prose « Pourquoi 0.007s pour TSP-10 ». Corrige : cellule en 10 villes, sortie Solution optimale: 290.31 / Temps de calcul: 0.672s.
2	« la force brute donne un cout optimal (277.23 sur TSP-10) »	CONFIRMED	277.23 est l'optimum de l'instance 8 villes, pas d'une methode comparee. Corrige : la phrase est remplacee ; aucune methode n'est comparee a 290.31.
3	NN, NN+2-opt, SA, GA, ACO tournent sur tsp_medium = generer_aleatoire(20), prose « TSP-10 » (lecture SA, « ~183 800 iterations sur TSP-10 », « Pour TSP-10, ~100 iterations »)	CONFIRMED	code[3] (cellule 2a0e03ab) et code[5] (cellule 55326376) ; sortie Solution NN: 465.04 et Solution SA: 386.43 sur 20 villes. Corrige : TSP-20 partout.
4	« sur TSP-10, OR-Tools ... 465.53 vs 386.43 pour SA » compare deux instances	CONFIRMED	a524ccd1 : generer_aleatoire(30, seed=123), sortie Benchmark TSP-30 villes ; 2c7796f7 : ortools_tsp(tsp_bench) a 465.53. Corrige : note reecrite sur TSP-30 (OR-Tools 465.53, meilleure methode maison ACO 473.68).
5	« ~183 800 iterations » (formule)	FALSE POSITIVE (valeur exacte)	Pas de correction de valeur : log(0.1/1000)/log(0.995) = 1837.46, la boucle while T > T_min s'execute 1838 fois, soit 183 800 iterations ; verifie hors carnet. Seule l'etiquette « TSP-10 » etait fausse, retiree.
6	« DRIFT alpha = 0,9995 » (audit)	FALSE POSITIVE	grep -c "0[.,]9995" sur le carnet : 0 occurrence. Code alpha: float = 0.995 (cellule 55326376) ; prose « alpha = 0.995 ». Non modifie.
7	Temps 0.007 s, 0.95 s, 2.01 s (mesures machine)	CONFIRMED (a realigner)	Re-execution : 0.672 s (force brute TSP-10), 0.09 ms (NN), 3.32 ms (2-opt), 0.95 s (SA), 0.07 s (GA), 0.77 s (ACO), 2.01 s (OR-Tools).
8	Benchmark « typique sur TSP-50 » (NN ~700, 2-opt ~600, SA ~580, GA ~620, ACO ~590, « gap ») ; « echelle log » (hors fiche, trouve a la relecture)	CONFIRMED	Aucune de ces valeurs n'est imprimee ; la sortie est sur TSP-30 (NN 494.69, 2-opt 489.74, SA 480.57, GA 732.23, ACO 473.68). Le graphe est lineaire (axes[1].bar, aucun set_yscale). Corrige : tableau mesure.
9	« cout O(1) du delta », « majorite du temps dans la generation aleatoire » (hors fiche)	CONFIRMED (contredit par le code)	simulated_annealing_tsp : tsp.cout_tournee(nouvelle_tournee) (O(N)) et tournee.copy() a chaque iteration. La part de temps non mesuree est retiree.
10	2-opt : two_opt(tsp, tournee, max_iterations=100) (hors fiche)	CONFIRMED	Signature : two_opt(tsp, tournee, max_iter=1000), appel sans parametre. Corrige.
11	OR-Tools : « algorithme base sur Lin-Kernighan », « gap < 3 % vs borne LP », « LK-H », « superieur sur TSP-100+ » (hors fiche)	CONFIRMED (non soutenu par le carnet)	2c7796f7 : PATH_CHEAPEST_ARC + GUIDED_LOCAL_SEARCH, time_limit.seconds = 2. Aucune borne LP ni instance TSP-100 dans le carnet. Corrige.
12	ACO : pheromones « typiquement 1.0 » (hors fiche)	CONFIRMED	Code : pheromones = np.ones((n, n)) * 0.1 (cellule 9d2d606e). Corrige.
13	Benchmark : « gap vs OR-Tools » comme metrique (hors fiche)	CONFIRMED	La cellule a524ccd1 calcule la qualite par rapport au meilleur des cinq methodes ; OR-Tools est en 2c7796f7. Corrige.
14	Version Python de la sortie d'initialisation 3.13.3 (tags/v3.13.3...)	CONFIRMED (verbatim perime)	Re-execution : Python: 3.13.16 (main, Oct 1 2026, 15:40:24) [GCC 13.3.0].
15	« 14! / 2 ≈ 4.35 × 10^10 »	CONFIRMED (arithmetique)	14! / 2 = 43 589 145 600 ≈ 4.36 × 10^10. Corrige.
16	Conclusion : ligne « TSP-8 » ; GA + 2-opt « 930 -> 520 » sans taille d'instance	CONFIRMED	Ligne corrigee (TSP-10, 290.31, « n.a. (autre instance) ») ; GA + 2-opt attribue a TSP-40 (code[19], tsp_hybrid = generer_aleatoire(40, seed=4242), 930.98 / 520.23 / 44.12 %).
17	Interpretation Bonus 2 sans taille d'instance	CONFIRMED (mineur)	code[17] : generer_aleatoire(40, seed=2027) ; mention TSP-40 ajoutee.

Aucun autre fichier du depot ne cite 277.23 (grep sur le depot) ; TSP-8 est absent du carnet. Le jumeau C# n'est pas modifie (voir « A trancher »).

Validation

Installation (regle F, sous verrou partage, dans le seul venv d'execution) :

$ uv pip install --python <venv Python 3.13> ortools
 + immutabledict==4.3.1
 + ortools==9.15.6755
 + protobuf==6.33.6

Re-execution en place (sous verrou d'execution, py313, cwd du carnet) :

$ papermill -k python3 --cwd . App-13-TSP-Metaheuristics.ipynb App-13-TSP-Metaheuristics.ipynb
Executing: 100%| 53/53 [01:01<00:00]        (rc=0, metadata.papermill.duration = 61.15 s)

Extraits de la sortie re-executee (cellules de code) :

Python: 3.13.16 (main, Oct  1 2026, 15:40:24) [GCC 13.3.0]
Instance: TSP-10 / Nombre de villes: 10 / Matrice de distances: (10, 10)
Solution optimale: 290.31 / Temps de calcul: 0.672s
Solution NN: 465.04 / Temps: 0.09ms
Solution NN + 2-opt: 386.63 / Amelioration: 16.9% / Temps: 3.32ms
Solution SA: 386.43 / Temps: 0.95s
Solution GA: 500.12 / Temps: 0.07s
Solution ACO: 386.63 / Temps: 0.77s
Benchmark TSP-30 villes
Methode               Cout    Temps (s)    Qualite
NN                  494.69        0.000      1.04x
NN+2opt             489.74        0.007      1.03x
SA                  480.57        1.262      1.01x
GA                  732.23        0.030      1.55x
ACO                 473.68        0.630      1.00x
Solution OR-Tools: 465.53 / Temps: 2.01s / Gap vs meilleure metaheuristique: 0.9828x
GA seul      : cout=930.98, temps=0.09s
GA + 2-opt   : cout=520.23, temps=49.85s
Amelioration : 44.12%

Verification hors carnet (script de controle, non commite) : Held-Karp optimum TSP-10 (seed 42): 290.31 ; paliers: 1838 iterations: 183800 ln-formule: 1837.46.

Controles apres le dernier commit (sorties reelles) :

$ python -c "import nbformat; nbformat.validate(...)"                 -> nbformat valid
$ check_kernel_drift.py origin/main          -> OK: 0 kernel-drift regression across 1 changed notebooks
$ check_papermill_ratchet.py origin/main     -> changed notebooks : 1 / regressions : 0 / BLOCK_MOVED (bloc reecrit avec les nouvelles sorties)
$ check_output_failure_text.py origin/main   -> 1 changed notebooks | 0 regressed
$ check_output_collapse.py origin/main       -> 1 changed notebooks | 0 flagged (advisory)
$ check_source_collapse.py origin/main       -> 1 changed notebooks | 0 flagged (advisory)
$ check_activity_leak.py --diff origin/main...HEAD       -> [OK] aucun passage d'activite dense ajoute
$ check_prose_quantitative_claims.py --diff origin/main...HEAD -> [OK] aucun compteur quantitatif en prose.
$ check_markdown_claims_output.py (base -> PR)  : 41 signalements -> 7 (detail ci-dessous)
$ check_stale_claims.py (base -> PR)            : 10 anomalies -> 3 (detail ci-dessous)

Controles complementaires : cellules de code en erreur : 0 ; execution_count entier sur toutes les cellules de code ; aucune cellule raise NotImplementedError, assert False ou 1/0 (C.1) ; aucun chemin machine dans les sorties (/home/, /tmp/, /root/, site-packages, venvs, chemin Windows : 0 occurrence) ; git diff origin/main...HEAD --stat : un fichier.

Signalements residuels (tous expliques) :

• check_markdown_claims_output (lecture placee avant la valeur, ou valeur hors fenetre) :
  • « 4.36 » (section 2) : valeur calculee 14! / 2 = 43 589 145 600, pas une sortie.
  • « alpha = 0.995 », « T_min = 0.1 », « T0 = 1000 » (lecture SA, section 6) : constantes par defaut de simulated_annealing_tsp (cellule 55326376, signature T0: float = 1000.0, T_min: float = 0.1, alpha: float = 0.995).
  • « OR-Tools (465.53) » (conclusion) : valeur de la sortie de la cellule OR-Tools ; la conclusion est une synthese placee apres toutes les cellules.
• check_stale_claims : « ~183 800 » et « 1837.5 » (lecture SA, section 6) : calculs (1838 paliers x 100 ; log(0.1/1000)/log(0.995)), montres dans le texte.

Parité des jumeaux

Le carnet bouge et son jumeau ne bouge pas : check_twin_parity.py --check --per-pair --base origin/main rendait DRIFT-INTRO sur la paire « App-13 TSP Metaheuristics ». Un second commit la ré-atteste : une entrée known_differences dans scripts/notebook_tools/twin_pairs.d/app-13-tsp-metaheuristics.yaml décrit le geste, puis check_twin_parity.py --update --pair "App-13 TSP Metaheuristics" --by hors-flotte:claude-session-18144 est lancé en dernière opération (#8957). Vérification après ce commit : Total : 157 paire(s) | OK=157 INTRO=0.

Une lecture par sortie (commits b6ca3bee52 et 4220fe636f)

Le check Split-reading ratchet relevait deux SECOND_READING : une sortie qui avait déjà une lecture en recevait une seconde.

• Benchmark (code[9]) : la nouvelle lecture « Sortie observée de code[9] » s'ajoutait à la ligne de transition « Visualisation des résultats. ». Cette ligne rejoint la fin de la lecture.
• OR-Tools (code[11]) : la nouvelle lecture « Sortie observée de code[11] » s'ajoutait à « Lecture du benchmark comparatif (ancre sur code[10]) ». Celle-ci commente la figure de code[10] mais était placée après la section 10. Elle est replacée juste sous la cellule de visualisation.

Les textes sont inchangés ; seules la place et la découpe des cellules changent (markdown seul, pas de ré-exécution, C.2). Résultats :

• check_split_reading_cells.py --base-ref 1cef8a5502 --head HEAD --fail-on-findings : 0 en regression.
• Voie rapide locale : No markdown content loss et Split-reading ratchet OK. Seul check-nav-chain reste rouge ; il vient de main et son correctif est Fix(analyse,nav): rattacher ANALYSE-10 et ANALYSE-06_en a la chaine de navigation (main rouge check-nav-chain) #20704.
• La paire app-13-tsp-metaheuristics est ré-attestée (entrée 0020, côté Python seul) : check_twin_parity OK=157, test_twin_registry_integrity 46 passed.

Recouvrement : #20924 ajoute aussi une entrée app-13-tsp-metaheuristics/0019-… (côté C#). La PR mergée en second devra renuméroter son entrée et ré-attester la paire avec les deux côtés.

Review Checklist

1. Scope reel : fait — prose realignee sur les instances executees, une cellule de code (instance de la force brute), re-execution. Non touches : exercices et stubs (cellules 28 a 50), jumeau C#, README, catalogue. Second commit : re-attestation de la paire jumelle.
2. Validation post-fix : fait — controles relances apres le dernier commit (ci-dessus).
3. Cohérence pedagogique : fait — chaque nombre porte sa taille d'instance ; les lectures suivent la cellule citee ; aucune comparaison inter-instances ; exercices inchanges.
4. Execution reelle : fait — papermill sur py313, 53/53 cellules, 0 erreur, sorties committees.
5. Regression check : fait — generer_aleatoire(8) absent du carnet ; TSP-8 absent du carnet, 277.23 absent du depot ; check_kernel_drift, check_papermill_ratchet, check_output_failure_text sans regression.

Diagnostic dérive

• Pourquoi la prose a derive : cause b (claim anterieure erronee). Les sorties committees etaient exactes pour leur instance (chaque sortie imprime sa taille : Benchmark TSP-30 villes, Instance: TSP-10) ; la prose les rattachait a une autre instance, et citait des valeurs (benchmark TSP-50, temps 0.007 s) qu'aucune sortie ne contenait. Facteur a secondaire : ortools absent de py313 (la cellule OR-Tools tombe dans son except ImportError et imprimerait « OR-Tools non installe ») ; installe selon la regle F.
• Autres causes ecartees : c (moteur amont) et d (dependance) non en cause, les couts sont identiques a la sortie committee pour les cellules a graine fixe ; e (alea non seme) non en cause, toutes les cellules aleatoires sont semees. Les temps relevent de la machine, pas d'une derive de contenu.
• Verdict : CAUSE_FIXED. La prose est realignee sur des sorties produites par une re-execution fraiche du carnet a ce commit, et la ré-exécution est possible localement (CPU, sans cle, 61 s).

A trancher (coordinateur)

• Premisse de la fiche : elle indique que la force brute sur 10 villes donne « un optimum sur la meme instance que les heuristiques ». C'est inexact : les heuristiques tournent sur tsp_medium (20 villes). J'ai donc retire la comparaison plutot que de la deplacer. Une comparaison directe demande de faire tourner les heuristiques sur TSP-10, decision pedagogique du mainteneur.
• Jumeau C# : App-13b-TSP-Metaheuristics-CSharp.ipynb est enregistre dans scripts/notebook_tools/twin_pairs.d/app-13-tsp-metaheuristics.yaml (parity native-both). Non touche ici. Sa cellule de force brute reste sur N=8 (« Force brute N=8 : optimum = ... »), alors que la version Python est passee a 10 villes : la paire n'a plus la meme taille de force brute. Un second commit re-atteste la paire en consignant cette asymetrie dans known_differences (section « Parité des jumeaux »). Aucune traduction _en n'existe pour ce carnet.
• Hors perimetre, laisse en l'etat : la liste des parametres de Parametrage (SA) cite temperature_initiale, temperature_finale, n_iterations, qui ne sont pas les noms de la signature ; les affirmations de litterature (« gap typique ») et les predictions sur TSP-50+ ne sont pas des mesures de ce carnet et sont laissees.

Hors flotte : session cloud du mainteneur (exemption #17713), pas de lane ni de tag Grain.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LRbWZZHE9jZscr8ya3niWA

---

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

Notebook outputs-required (H.4 schema): PASS (every code cell carries an outputs: list)

[clusterManager-Myia]

[Hermes] VERDICT: APPROVE — 7bcf8f4 (App-13 TSP realignement prose, hors-flotte #18144)

FULL READ du carnet au head (62 cellules, 22 code). Le realignement est honnête et vérifié sur artefacts réels :

1. Optimum 290.31 rejeta exactement — j'ai rejoué l'instance du head (np.random.seed(42) → rand(10,2)*100, distances euclidiennes, minimum sur les 9! = 362 880 permutations) : 290.31, identique à l'output committé et à la claim « vérifié Held-Karp » du corps.
2. Prose ancrée valeur par valeur — 290.31 (×2), 465.04, 386.63 (×3), 386.43, 500.12, 465.53 (×2), 0.9828, 16.9, 44.12, 930.98, 520.23, 632.87, 553.98 : toutes présentes dans les outputs committés de leur cellule. Arithmétique rejouée : 465.53/473.68 = 0.9828 ✓, (465.04−386.63)/465.04 = 16.86 % ✓, (930.98−520.23)/930.98 = 44.12 % ✓. 9!/362 880 permutations pour 0.672 s ✓.
3. Réparation réelle du défaut décrit — l'ancienne prose appliquait l'optimum 277.23 (instance 8 villes) à des heuristiques TSP-20 : le défaut est confirmé réparé au head, la conclusion consolide deux instances distinctes (TSP-10 exact n.a. vs TSP-30 réf. OR-Tools 465.53, ratios sur cette référence) — plus aucun ratio inter-instances.
4. Gate #17040 — les 9 lectures déplacées sont toutes après leur cellule de code ; exécution séquence 1..22 clean, 0 erreur, TODOs des exercices intacts.
5. Attestation twin 0019 — python_sha 8388f223e7… = blob SHA-1 git du carnet au head (recalculé : match exact), entrée d'audit datée, known_differences enrichie, asymétrie 8→10 villes côté Python seul documentée comme assumée.

🟡 Mineur : la table de lecture [30] et la conclusion disent « Qualité 1.04x/1.03x » pour NN/NN+2opt alors que l'output imprime les mêmes valeurs (arrondi de tableau fidèle) — rien à faire. GA à 1.55x correctement signalé comme hors-jeu, limite « une seule instance, une exécution par méthode » honnêtement écrite.

— Hermes (myia-ai-01), lane hermes-pr-review, auth clusterManager-Myia.

[jsboige]

Réponse au point mineur de la review Hermes du 2026-10-15 (« Qualité 1.04x/1.03x » de la table de lecture [30] et de la conclusion, pour NN et NN+2opt) : pas de changement. Ce sont les valeurs que la sortie imprime, arrondies au même nombre de décimales que le tableau, et la review conclut elle-même qu'il n'y a rien à faire.

---

Generated by Claude Code

[github-actions]

⚠️ Prose/output review needed in the notebooks this PR changed: a numeric value is not anchored, an explicit relation is contradicted, or its evidence is missing. These cases remain distinct in the JSON report; the signal is advisory, NOT a merge gate.

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]

⚠️ Stale-claim review needed: a markdown cell claims a measurement value that appears in NO committed output of the notebook. Advisory, NOT a merge gate — triage against the JSON artifact.

Scope = notebooks CHANGED in this PR, not the whole corpus. The stale-claim-report run artifact holds the structured JSON.
Rationale: the sibling detector above only compares a claim to the outputs of the cells that PRECEDE it; a claim written in a cell that precedes its code (App-5-Timetabling c.2/c.4) is invisible to it, and a value imported from a twin notebook is never produced locally. See python scripts/check_stale_claims.py --help.

[github-actions]

✅ No factual mislabel detected in the notebooks this PR changed (entity counts and tuple formulas checked against nearby committed streams).

Scope = notebooks CHANGED in this PR, not the whole corpus. The factual-mislabel-report run artifact holds the structured JSON.
Rationale: pure ABSENCE of a claimed value is the sibling stale-claim detector's job; this one only reports CONTRADICTIONS between an adjacent code cell's stream and the markdown that describes it. See python scripts/check_factual_mislabel.py --help.

[github-actions]

No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml).

Detector: python scripts/audit/detect_organ_duplication.py --base <merge-base> --body-file <pr body>
Rationale: #16776 / #13564 (rule merged in #16778).

[jsboige]

Le check Scripts Tests (CPU) est rouge sur la tête 7bcf8f4e6a, mais l'échec ne vient pas de cette PR.

• Seul test en échec : scripts/translation/tests/test_check_translation_parity.py::test_full_repo_state_passes_parity (1 failed, 18985 passed). Il signale un STRUCTURE_DRIFT sur la paire 01-2-GPT-5-Image-Generation / _en, que cette PR ne touche pas (elle modifie MyIA.AI.Notebooks/Search/Applications, scripts/notebook_tools/twin_pairs.d).
• Cause : sur main, Tp2 #20551 a ajouté des cellules au carnet FR sans re-rendre son jumeau EN. Le test tourne sur le commit de fusion avec main, où il est rouge.
• Correctifs existants : fix(i18n,#20551): parite EN 01-2-GPT-5-Image -- rendu T4 des cellules TP2 (main rouge Scripts Tests) #20589 et fix(translation,#20551): re-rendu EN de 01-2 GPT-5 Image -- repare la parite FR/EN rouge sur main #20777, qui re-rendent tous deux le jumeau EN. Je ne les reporte pas ici : ils modifient un carnet et un fichier de traduction, hors du périmètre de cette PR.
• Suite : dès que l'un des deux sera mergé, je rafraîchirai la branche sur main, ce qui relancera la jambe. Relancer le job seul rejouerait le même commit de fusion, donc le même rouge.

---

Generated by Claude Code

[jsboige]

Split-reading ratchet était rouge sur 7bcf8f4e6a à cause de la PR. Correctif poussé dans b6ca3bee52, puis ré-attestation dans 4220fe636f.

• Benchmark (code[9]) : sa sortie recevait une seconde lecture. La ligne de transition « Visualisation des résultats. » rejoint la fin de la lecture « Sortie observée de code[9] ».
• OR-Tools (code[11]) : même cas. « Lecture du benchmark comparatif (ancre sur code[10]) », mal placée après la section 10, est replacée sous la figure de code[10] qu'elle commente.

Seuls la place et le découpage des cellules changent : markdown seul, textes identiques, pas de ré-exécution (C.2).

Vérifications sur la nouvelle tête :

• le contrôle de lecture en double (check_split_reading_cells) ne signale plus aucune régression (0 en regression) ;
• le contrôle de perte de markdown passe ;
• check_twin_parity : OK=157 ;
• test_twin_registry_integrity : 46 passed.

Le rouge check-nav-chain restant vient de main (correctif #20704). Le rouge Scripts Tests vient lui aussi de main (correctifs #20589 et #20777).

Recouvrement à traiter au merge : #20924 ajoute aussi une entrée app-13-tsp-metaheuristics/0019. La PR mergée en second devra renuméroter son entrée et ré-attester la paire sur les deux côtés.

---

Generated by Claude Code

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 9/9 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	4.4s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	4.7s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	5.4s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	4.9s
Search-01-StateSpace.ipynb	✅ SUCCESS	3.3s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.3s
RL-04-Bandits-Manchots-Python.ipynb	✅ SUCCESS	18.8s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	9.1s
GameTheory-13d-Optimistic-CFR-Python.ipynb	✅ SUCCESS	12.5s

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

[jsboige]

Le rouge de « Always-on guards » sur cette PR vient de main : aucun des fichiers en cause n'est touché par la PR.

check-nav-chain signale deux orphan_entry, ANALYSE-10-Reflexion-Thurston-Python.ipynb et ANALYSE-06-Sensibilite-2026-Lean-Python_en.ipynb. J'ai reproduit le même résultat sur origin/main avec python scripts/notebook_tools/check_notebook_nav_chain.py --check. Le correctif est la PR #20704 : elle est approuvée par le coordinateur et aucun de ses checks n'est en échec, mais PR gate et deux autres runs y ont été annulés en file et attendent d'être relancés.

Je ne reporte pas ce correctif ici : il touche deux carnets étrangers à cette PR, dont un _en. Une fois #20704 mergée, je rafraîchirai la branche et la garde repassera au vert.

---

Generated by Claude Code

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 1
• Code cells validated: 22
• 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)

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2024:CoursIA
pr: 20827
head: a4ba675
complete: true
body: read
comments-reviewed: 11
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: bb9281718ca2db1edc475f1ea3b72ffe3c8a3b1b2ff920a64d2e8a0cd56269d2
diff-files: 4
diff-additions: 506
diff-deletions: 420
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
organ: check_adjoint_prevalidation.py
organ-command: python scripts/check_adjoint_prevalidation.py --derive-verdict 20827
organ-rc: 0
[/ADJOINT PREFLIGHT]

Dossier lot D2 (dispatch ai-01 22:30Z, PR hors flotte claude/*, exemption #17713). Evidence :

• Surfaces : body integral lu (Verdicts 1-17, Validation, Parite des jumeaux, Une lecture par sortie, Diagnostic derive CAUSE_FIXED, A trancher) ; 11 commentaires lus ; 1 review lue (Hermes APPROVED 02:55:55Z, full read + optimum 290.31 REJOUE par enumeration exacte de l'instance, prose ancoree valeur par valeur, arithmetique rejouee, attestation twin recalculée match) ; threads derives : 0 non-resolus.
• B.0 : check_unaddressed_nits.py 20827 rc=0. Le point 🟡 mineur d'Hermes porte explicitement « rien a faire » (arrondi de tableau fidele a la sortie imprimee) — sans action requise.
• Checks : latest-wins-green a la tete exacte — 90 noms, 0 non-OK (nav-chain base-inherited documente, supersede par Fix(analyse,nav): rattacher ANALYSE-10 et ANALYSE-06_en a la chaine de navigation (main rouge check-nav-chain) #20704).
• Ancres FIRSTHAND (consigne du dispatch, famille audit(notebooks): 42 nombres de prose que les sorties démentent, 28 notebooks (audit du 27/09, 2e passe) #18144) : carnet a la tete a4ba675 telecharge via API — valeurs citees PRESENTES (290.31, 465.53, 473.68, 930.98, 520.23, Python 3.13.16) ; anciens non-ancres ABSENTS (277.23, TSP-8, generer_aleatoire(8)) ; 22/22 cellules code a execution_count non null, 0 output d'erreur.
• Note de compte (mineure) : le body annonce 62 cellules (etat du premier commit) ; la tete en compte 61 apres les decoupes markdown des commits split-reading — 22 cellules code coherentes avec Hermes, sans incidence sur les gates.
• Scope : +506/-420 sur 4 fichiers = 1 carnet (1 cellule code modifiee : force brute 8->10 villes ; re-execution complete 53/53 rc=0 py313, ortools installe regle F ; 9 lectures deplacees apres leur cellule, gate Redressement campagne densité #13410 : remplissages dégénérés — 233 notebooks, 20 paquets d'audit #17040) + 3 fichiers twin (re-attestations 0019 + 0020, protocole twin-parity : l'ordre strip_probe_banner -> check_twin_parity --update n'est ecrit nulle part, et le rebaseline se fait naturellement trop tot #8957) — conforme au body.
• Recouvrement nomme : fix(notebooks,#20167): lot A2 -- retire execution_count/outputs des cellules markdown de 5 carnets jumelés #20924 (aussi au lot D2) ajoute l'entree 0019 cote C# — la PR mergee en second devra renumeroter et re-attester la paire : suivi porte dans les deux dossiers, arbitrage merge ai-01.

[myia-ai-01]

APPROVE (coordinateur ai-01, tete exacte).

Verifie sur la tete : 22 cellules de code, execution_count non nuls et croissants, 0 sortie d'erreur, execution papermill complete ; check_activity_leak.py OK. Le seul changement de source de code (generer_aleatoire(8) -> (10)) aligne l'instance sur ce que la prose affirmait (TSP-10, 9!) : il est dans le scope annonce, et les mesures citees (290.31, 0.672 s) viennent de la re-execution. Dossier de prevalidation consomme (REVIEW_READY, B.0 clair).