[Audit #17073] Série Sudoku — partition Hermes

[clusterManager-Myia]

Panorama de série (audit #17073, partition Hermes)

Arc pédagogique — 38 notebooks, 4 déclinaisons langagières : 18 C# + 19 Python + 1 companion Lean 4 (Sudoku-19-Lean-Propagation, lake sudoku_lean 0-sorry). Deux blocs bien distincts :

• Paires jumelles C#/Python 00→15 (même algorithme, deux langages), plus le benchmark 18 (comparaison des solveurs) ;
• Python uniquement 16-NeuralNetwork, 17-LLM, 18b-Statistical-Comparison (le C# s'arrête à 18) ;
• Companion formel 19 (soundness de la propagation, hors langage-jumeau).

Le fil rouge est un curseur de garantie : solveurs exacts (01 backtracking, 02 DLX, 06/07 CSP, 10 OR-Tools, 11 Choco, 12 Z3) → métaheuristiques non garanties (03 GA, 04 SA, 05 PSO) → modèles appris (15 NumPyro, 16 réseau, 17 LLM) → comparaison quantitative honnête (18, 18b). Chaque notebook mesurant le même puzzle témoin (Easy51, 36 cases vides, 45 indices), la série rend la comparaison inter-méthodes immédiate.

Ordre canonique proposé : l'ordre numérique actuel (00→19). La chaîne de navigation est correcte sur tous les frères vérifiés (02→03→04→05→06→07→08→09→10→12→15…), les prérequis d'en-tête suivent, rien à réordonner. La numérotation des fichiers est en plus zero-paddée (00, 01…) depuis le chantier #11840.

Niveau d'apprenant proposé : intermédiaire (L2-M2). Aucun prérequis IA — le backtracking est introduit depuis zéro ; Python 3.10+ suffit pour la branche Python, .NET 9 pour la branche C#.

Gaps observés entre notebooks (survol des frères 01/02/03/05/06/07/10/11/12/15/16/17/18/18b) :

• Sous-famille métaheuristiques (03, 04, 05) inégalement instrumentée : 03 possède une section « ## 4. Visualisation de la Convergence » (figure committée) ; 04 accumule energy_history dans son solveur manuel sans jamais le tracer ; 05 n'a aucune sortie image. Candidat de panorama, pas un finding (aucune figure promise par la prose).
• Motif de série « Conclusion puis section ajoutée » : Sudoku-03 a une Conclusion (cell 23) puis une seconde (cell 28) puis la Section 7 Prong B (cell 30) ; Sudoku-04 a une Conclusion (cell 45) puis la Section 11 Prong B (cell 46) et les références (cell 49). Défaut de SÉRIE (append rétroactif des livrables Prong B), pas d'instance — aucun finding déposé à ce titre.
• Résolution des citations inter-notebooks non uniforme : Sudoku-04 renvoie à Sudoku-01 (cell 15 = code du benchmark ✓) et Sudoku-10 (cell 19 = code du benchmark ✓), mais à Sudoku-03 « cell 22 » alors que le benchmark GA y est en cellule 21 (22 = sa lecture). Un lecteur qui suit la référence tombe une fois sur trois sur une cellule de prose.

Population : 38 notebooks, tous partition Hermes.

Checklist

• Sudoku-00-Environment-CSharp.ipynb
• Sudoku-01-Backtracking-CSharp.ipynb
• Sudoku-01-Backtracking-Python.ipynb
• Sudoku-02-DancingLinks-CSharp.ipynb
• Sudoku-02-DancingLinks-Python.ipynb
• Sudoku-03-Genetic-CSharp.ipynb
• Sudoku-03-Genetic-Python.ipynb
• Sudoku-04-SimulatedAnnealing-CSharp.ipynb
• Sudoku-04-SimulatedAnnealing-Python.ipynb
• Sudoku-05-PSO-CSharp.ipynb
• Sudoku-05-PSO-Python.ipynb
• Sudoku-06-AIMA-CSP-CSharp.ipynb
• Sudoku-06-AIMA-CSP-Python.ipynb
• Sudoku-07-Norvig-CSharp.ipynb
• Sudoku-07-Norvig-Python.ipynb
• Sudoku-08-HumanStrategies-CSharp.ipynb
• Sudoku-08-HumanStrategies-Python.ipynb
• Sudoku-09-GraphColoring-CSharp.ipynb
• Sudoku-09-GraphColoring-Python.ipynb
• Sudoku-10-ORTools-CSharp.ipynb
• Sudoku-10-ORTools-Python.ipynb
• Sudoku-11-Choco-CSharp.ipynb
• Sudoku-11-Choco-Python.ipynb
• Sudoku-12-Z3-CSharp.ipynb
• Sudoku-12-Z3-Python.ipynb
• Sudoku-12b-Z3-Linq2Z3-CSharp.ipynb
• Sudoku-13-SymbolicAutomata-CSharp.ipynb
• Sudoku-13-SymbolicAutomata-Python.ipynb
• Sudoku-14-BDD-CSharp.ipynb
• Sudoku-14-BDD-Python.ipynb
• Sudoku-15-Infer-CSharp.ipynb
• Sudoku-15-Infer-Python.ipynb
• Sudoku-16-NeuralNetwork-Python.ipynb
• Sudoku-17-LLM-Python.ipynb
• Sudoku-18-Comparison-CSharp.ipynb
• Sudoku-18-Comparison-Python.ipynb
• Sudoku-18b-Statistical-Comparison-Python.ipynb
• Sudoku-19-Lean-Propagation.ipynb (renommé Sudoku-19-Lean-Propagation-Lean.ipynb)

Premier audité de la série : Sudoku-04-SimulatedAnnealing-Python.ipynb (rang 1, « densité récente »).

[clusterManager-Myia]

Sudoku/Sudoku-04-SimulatedAnnealing-Python.ipynb — 4 findings (2 classes)

Survol de série : 1er notebook audité de la série Sudoku (38 notebooks, 18 C# + 19 Python + 1 Lean). Survol des frères 01, 02, 03, 05, 06, 07, 10, 11, 12, 15, 16, 17, 18, 18b + jumeau Sudoku-04-Csharp et version antérieure du notebook (blob 4257ce1e8). Conventions de série confirmées : un puzzle témoin unique (Easy51, 36 vides, 45 indices) dans tous les frères Python, en-tête Niveau/Duree/Prerequis + table de navigation, une lecture par sortie (### Lecture … ici, ### Interpretation … chez les frères). Détail décisif : ce notebook a reçu aujourd'hui 12:36Z la tranche densité #16386 (« tranche densite Sudoku Python — lectures de sorties et anatomies ») qui a inséré 4 cellules markdown aux positions 6, 14, 19 et 29. Vérifié par diff de cellules contre le blob parent : benchmark_sa passe de l'index 29 → 33, SimpleBacktracking de 32 → 36 — +4 sur tout indice cité ≥ 29. Les trois premiers findings en découlent.

---

Finding 1 — stale-claim (sous-famille « citation de cellule », 4ᵉ instance de la campagne — ligne additive, voir §Organes)

• Cellules : [34] (id a8eb3667), [46] (id cell-29f37419), [48] (id cell-998bfe01), [49] (id cell-bc0eceef)
• Extrait : « Note methodologique : les durees absolues sont mesurees en direct par les cellules benchmark (29 SA, 32 BT ; outputs reels, ec != null, 0 erreur) » (cellule 46) ; « T_SA_MS = (131, 10340, 207723) … # (cell 32) » (cellule 48) ; « mesure en direct par la cellule 29 » (cellule 34) ; « (cell 32 — comparaison BT vs SA sur 3 Easy) » (cellule 49)
• Classe : stale-claim
• Pourquoi : au head courant la cellule 29 est une lecture markdown (« Lecture du test manuel ») et la cellule 32 un squelette d'exercice (# EXERCICE : Comparer les schemas de refroidissement, sortie Exercice a completer) — les vraies cellules de mesure sont 33 (benchmark SA) et 36 (BT vs SA). L'apprenant qui suit la référence « re-exécutez-les » tombe sur du texte et un stub, et lit un tableau de chiffres sans pouvoir les reproduire.
• Preuve de l'origine : git log --diff-filter=M sur le fichier + diff contre 4257ce1e8 → les 4 insertions de Add: tranche densite Sudoku Python - lectures de sorties et anatomies (See #13410) #16386 sont exactement les 4 cellules ### Lecture … ; aucun index cité n'a été mis à jour.

---

Finding 2 — stale-claim (sous-famille « prose vs sortie committée »)

• Cellules : [24] (id a3490f65, lecture) vs sortie de [23] (id 75893419)
• Extrait : « l'energie part de 29 …, puis fluctue (7, 13, 9, 7, 4, 2, 0...) … Accept … non triviales au debut (Accept ~23%, Improve ~9% a T=0.93) »
• Classe : stale-claim
• Pourquoi : la trace réellement committée en 23 ne contient aucune de ces valeurs — 100 paliers comptés, séquence réelle T=1.00000 E=29.00 puis 0.93325 E=14.00 (Accept 17.40%, Improve 7.40%), 0.87096 E=16.00 (10.60/4.00), 0.81283 E=2.00, … ; maxima mesurés Accept 17.4% / Improve 7.4%. La colonne Energy ne prend jamais que les valeurs 29, 14, 16, 2 et 0 sur les 101 lignes de trace (7, 13, 9 et 4 y sont absents ; le seul 9.00 de tout le notebook est le 29.00 de la ligne d'en-tête). L'apprenant vérifie un chiffre faux et conclut que sa compréhension de la trace est erronée, pas la prose.
• Note : défaut antérieur à Add: tranche densite Sudoku Python - lectures de sorties et anatomies (See #13410) #16386 (déjà présent dans 4257ce1e8) — la tranche ne l'a pas créé, elle ne l'a pas corrigé.

---

Finding 3 — stale-claim (même sous-famille que 2, sur une section différente)

• Cellules : [46] (id cell-29f37419) + [48] (id cell-998bfe01) + [49] (id cell-bc0eceef), contredites par les sorties de [33] (id 4dd820e2) et [36] (id fbd14051)
• Extrait : « T_SA_MS = (131, 10340, 207723) … # Chiffres reels tires du tableau comparatif (cellule du dessus) » et « T_BT_MS = (1.0, 5.1, 8.6) » ; note de [49] : « ces ratios (SA/BT ~131 a ~24 154x) »
• Classe : stale-claim
• Pourquoi : trois jeux de durées incompatibles coexistent pour la même mesure. Sortie committée de 33 : SA = 0.22 s / 14.70 s / 395.21 s ; sortie de 36 : SA = 250 / 17427 / 347659 ms, BT = 4.3 / 7.7 / 15.0 ms ; constantes de 48 : SA = 131 / 10340 / 207723 ms, BT = 1.0 / 5.1 / 8.6 ms. Les valeurs de 48 n'existent que dans la sortie de 48 elle-même (elles y sont imprimées) — le tableau de la cellule 46 qu'elles prétendent citer ne porte que des compteurs d'appels (49/201/295), aucune durée. L'énoncé de l'exercice 11 « Prong B » fait donc calculer des ratios sur des nombres non mesurés, et la note de 49 en tire la conclusion « ~24 154x ».
• Pourquoi c'est réfutable en une commande : grep des six constantes sur les sorties du notebook — 131/10340/207723 n'apparaissent que dans la cellule 48, 1.0/5.1/8.6 également ; l'écart le plus visible est le puzzle 3 : 207.7 s (prose) vs 347.7 s (cellule 36) vs 395.2 s (cellule 33).

---

Finding 4 — exercise-mismatch (2ᵉ occurrence campagne)

• Cellules : [38] (id 51c02a71, ex. 1), [40] (id i44iitvrsl, ex. 2), [42] (id rrr4hbaa4ls, ex. 3) vs chargeur de [5] (id 798282b0)
• Extrait : « Verification : Testez sur un puzzle medium avec et sans rechauffement » / « Comparez alpha constant vs adaptatif sur 10 puzzles medium » / « Testez différentes valeurs de use_extended (0.1, 0.2, 0.5) sur des puzzles medium »
• Classe : exercise-mismatch
• Pourquoi : les trois vérifications exigent un corpus « medium » que le notebook ne fournit pas et que le dépôt ne contient pas. Le seul chargeur du notebook est load_puzzles(PUZZLES_DIR / 'Sudoku_Easy51.txt', max_puzzles=5) et MyIA.AI.Notebooks/Sudoku/Puzzles/ ne contient que Sudoku_Easy51.txt, Sudoku_hardest.txt, Sudoku_top95.txt (vérifié par git ls-tree sur la branche main). Le mot « medium » n'apparaît nulle part ailleurs dans le notebook (hors ces 3 vérifications) ; dans la branche Python de la série aucun frère n'en définit un, alors que la branche C# en a un (SudokuHelper.GetSudokus(SudokuDifficulty.Medium) → Sudoku_hardest.txt). L'apprenant ne peut pas exécuter la vérification demandée sans deviner la convention.
• Portée : défaut des trois exercices simultanément, pas d'une occurrence isolée.

---

Organes (passe réelle, checkout coursia-organs à jour — 0be934167)

• check_split_reading_cells : couvert (0 signal)
• check_interp_positioning : couvert (0 signal, baseline vide)
• check_output_failure_text : couvert (0 signal)
• check_cell_source_parses : couvert (0 signal, 1 source scannée)
• restore_accents_canonical --check : 8 accents curables dans 6/31 cellules markdown + 94 formes hors table (signalé, non curé par la table)
• check_duplicate_sections : absent du checkout (seul check_duplicate_notebook_index.py existe) — porte Redressement critique des 218 notebooks a sections dupliquees -- lecture de bout en bout, consolidation, pas suppression mecanique #17066 : rien à signaler ici
• Extras exécutés (hors liste mandatée) : detect_repeated_prose → 2 recouvrements de paraphrase (cell 34→45, cell 47→46) → paraphrase-stack couvert par l'organe, aucun finding déposé ; detect_solution_leaks --scan 0 ; audit_solution_leaks --json 0 ; detect_stub_truth_returns 0 ; detect_code_in_markdown_cells 0 ; check_null_exec OK.

Organes — ligne additive (pas de nouvel organe proposé)

stale-claim passe de 9 à 12 occurrences Hermes, mais aucune nouvelle sous-famille : les findings 2 et 3 sont exactement la famille « prose vs outputs » déjà instrumentée par scan_d5_prose_outputs_alignment.py (D5), et le finding 1 est la sous-famille « citation de cellule » déjà portée par le détecteur de NanoClaw (check_cited_code_in_markdown.py). Renforcement demandé, pas un 4ᵉ détecteur : résoudre l'index cité (cellule N désigne-t-elle bien le code de mesure annoncé ?), pas seulement le code cité — la tranche densité #16386 montre le mode de panne : tout insert structurel décale les index ≥ sa position et invalide silencieusement les références cell N du même fichier.

(exercise-mismatch à 2 occurrences campagne — sous le seuil de 3, aucune proposition.)

[clusterManager-Myia]

Sudoku/Sudoku-07-Norvig-Python.ipynb — 3 findings (3 classes)

Survol de série : frères 01, 02, 04, 05, 06 (headers seuls). Arc confirmé : 01 backtracking → 02 DLX → 03-05 métaheuristiques → 06 AIMA CSP (MRV, LCV, FC, AC-3, MAC déjà introduits) → 07 Norvig. Posture d'apprenant sorti de 06 : MRV et forward checking sont acquis, le notebook les réactive correctement en tête — pas de prerequisite-gap.

Organes : couverts (0 signal sur 4 checks ; accents 4 cures / 34 formes hors table ; check_duplicate_sections toujours absent du checkout — pull 320c5f9).

---

F1 — exercise-mismatch — cellules cell-c705c6d5 (md) + cell-e5725826 (code)

Extrait : « Modifiez la fonction solve pour court-circuiter eliminate » vs stub fourni : « def solve_without_propagation(grid: str) ... result = None # TODO etudiant »

L'énoncé prescrit de modifier solve — donc de casser le solveur utilisé par le benchmark trois cellules plus bas — alors que le stub contredit l'énoncé en créant une fonction séparée ; l'exercice est en outre logé sous le header « Benchmark » (21) dont le contenu réel n'arrive qu'en 24-26. L'apprenant qui suit l'énoncé à la lettre sabote la suite du notebook.

F2 — paraphrase-stack — cellule 162evydrpdu

Extrait : « | Faciles | (ms live -- regle #9434) | 100% (20/20) | Resolution quasi-instantanee | »

Cette « Interpretation » redit en plus pauvre la « Lecture du benchmark » (25) qui la précède immédiatement — mêmes chiffres, mêmes points (facteur ~1,3, propagation efficace, ~80 lignes) — avec un tableau à trous « (ms live) » : l'apprenant relit deux fois la même lecture, la seconde moins informée que la première.

F3 — stale-claim — cellule b00eeb33 (Résumé final)

Extrait : « | Faciles (20 puzzles) | ~2.1 ms | 100% (20/20) | ... | Difficiles (11 puzzles) | ~2.8 ms | 100% (11/11) | »

Le tableau de synthèse cite des temps (~2,1 / ~2,8 ms) qui contredisent les outputs réels du benchmark du notebook (3,30 et 4,45 ms/puzzle) : l'apprenant qui referme le notebook retient des performances ~35 % meilleures que mesurées, sans signal que la mesure a bougé. Relève de la sous-famille « valeurs citées vs outputs » déjà couverte par les propositions existantes (check_cited_code_in_markdown.py / gate #17040) — pas de nouvelle proposition d'organe.

---

Vérifications croisées (non-findings) : la référence au jumeau C# de la cellule 25 (« 3 015 ms, 0/10 ») est exacte — Sudoku-07-Norvig-Csharp cell 4heal8sfw7x : « Backtracking Simple | Hard | 3015,1 | 0 | Disqualified ». La lecture de la cellule 20 (grille d'entrée déjà résolue, propagation seule, zéro embranchement) est correcte.

[AUDIT #17073 — Hermes po-2026, lecture seule]

[jsboige]

Sudoku/Sudoku-14-BDD-Python.ipynb — 3 findings (2 classes)

Passe d'organes : OK (0 signal sur 4 checks ; accents 1 cure / 6 formes hors table ; check_duplicate_notebook_index prend --base/--head, pas de fichier seul — non applicable en lecture seule). Aucun organe n'a attrapé les 3 findings ci-dessous.

F1 — stale-claim — cellule [32] (id cb09a8ca, code)

Extrait : « 1. Construit un MDD par ligne (contrainte 'N valeurs distinctes'). »

La docstring de solve_sudoku_mdd annonce comme étape 1 la construction d'un MDD par ligne ; le corps de la fonction ne construit aucun MDD (0 occurrence de RowMDDBuilder/mdd hors docstring, vérifié) — c'est de la propagation de domaines CP classique (élimination chez les peers ligne/colonne/bloc) + backtracking MRV. La note pédagogique de la cellule [35] l'admet d'ailleurs (« le solveur pragmatique en extrait la sémantique… une implémentation complète propagerait directement sur la structure MDD ») : le notebook est donc contradictoire en interne — docstring dit « construit », note dit « n'utilise pas ». L'apprenant qui lit la docstring croit que le titre du §6 (« Solveur Sudoku avec MDD») est littéral, alors que l'objet central du notebook n'intervient plus dans le solveur.
15ᵉ occurrence Hermes stale-claim ; sous-famille « prose/docstring nomme une construction absente du code » — même famille que l'en-tête pm.math.switch (PyMC-03), ligne additive : extension de périmètre de check_cited_code_in_markdown.py aux docstrings, pas un nouveau détecteur.

F2 — exercise-mismatch — cellule [36] (id 66f2f0c7, md) + stub [37]

Extrait : « Comparez la taille (nombre de nœuds) d'un BDD booléen vs un MDD à 9 valeurs pour représenter la « même » contrainte d'unicité. »

Le côté MDD de la comparaison est exécutable (RowMDDBuilder), mais le côté « BDD booléen pour la contrainte d'unicité » exige un encodage booléen des domaines 1..9 (one-hot = 729 variables, ou binaire) que ni ce notebook ni ses prérequis ne construisent : le BDD de §2 (BDDNode) ne manipule que des variables booléennes abstraites (x AND y), et le seul encodage de valeurs en bits du corridor (Sudoku-13 §9) est sur mini-grille 3-cellules avec la librairie dd — autre outil, autre taille. L'apprenant ne peut pas exécuter la comparaison demandée sans inventer lui-même l'encodage, qui est précisément la difficulté que l'exercice prétend illustrer (le blowup BDD vs MDD). Sous-famille « corpus/outil exigé absent » (déjà vue Sudoku-04 « puzzles medium »).

F3 — exercise-mismatch — cellules [5] (id 66fe9ab9), [24] (id 1ef7589c), [36] (id 66f2f0c7) non numérotées vs [38] (id d7913dec)

Extrait : « ### Exercice 4 : Inspection d'un BDD » / « ### Exercice 5 : Évaluation par lot »

Le notebook porte trois sections « ## Exercice : … » sans numéro, puis une section « Exercices supplémentaires » qui reprend à « Exercice 4 ». Le référent de 1–3 est ambigu : la lecture naturelle (« les exercices 1 à 3 sont dans le notebook précédent ») est fausse — Sudoku-13 a bien ses propres Exercices 1–3 sur un autre sujet — et la bonne lecture (les trois exercices non numérotés de ce notebook) n'est affichée nulle part. Le jumeau C# numérote « Exercice 1 : BDD pour x OR y » depuis 1 (parité divergente, cf #4956). L'apprenant cherche des Exercices 1–3 qui n'existent sous ce nom nulle part. Sous-famille « numérotation » (déjà vue PyMC-03 : démarrage à 2 sans Exercice 1).

Suivi campagne (dépôt séparé sur #17073) : exercise-mismatch passe à 7 occurrences Hermes — seuil d'organe franchi, proposition déposée pour la sous-famille mécanisable (numérotation).

RAS sur le reste : lectures présentes après chaque sortie réelle (cellules 4, 9, 12, 15, 23, 30, 35), progression BDD→MDD→produit→solveur propre, pas de wall-of-text, aucune figure.

[jsboige]

Sudoku/Sudoku-08-HumanStrategies-Python.ipynb — 3 findings (2 classes)

Survol de série : frères 01, 02, 04, 05, 06, 07 déjà audités ou survolés (#17239). Arc confirmé : 01 backtracking → 02 DLX → 03-05 métaheuristiques → 06 AIMA CSP → 07 Norvig → 08 stratégies humaines (5 techniques + solveur à fallback). Posture d'apprenant sorti de 07 : la gestion des candidats par case est une extension naturelle de la propagation de contraintes de Norvig — pas de prerequisite-gap. Toutes les Lectures chiffrées (30/33/39/54/59) adossées aux sorties réelles : 149/91/17/15/5 ✓, 240/277=87% ✓, ratios 2,1x/2,4x/5,1x ✓, pivots XY-Wing ✓.

Passe d'organes : couverte (0 signal sur 4 checks ; accents 7 cures / 106 formes hors table ; check_duplicate_sections toujours absent du checkout). Aucun organe n'a attrapé les 3 findings ci-dessous.

---

F1 — exercise-mismatch (sous-famille « corpus exigé absent », 2ᵉ instance — 1ʳᵉ : Sudoku-04) — cellules cell-454955f9 (énoncé) + cell-a0f67067 (stub)

Extrait : « Comptez combien de naked singles peuvent etre trouves dans des puzzles de différentes difficultes (facile, moyen, difficile). »

Le notebook ne charge que Sudoku_Easy51.txt (max_puzzles=5, cellule 5) et le dossier Puzzles/ ne contient que Easy51/hardest/top95 (vérifié git ls-tree) : aucun corpus « moyen » n'existe — l'apprenant ne peut pas exécuter la comparaison demandée. L'apprenant perd : l'exercice est infaisable en l'état, la comparaison par difficulté reste une promesse.

F2 — exercise-mismatch (sous-famille « observable exigé absent du code ») — cellules cell-b761dae5 (énoncé) + cell-2bc950e1 (stub)

Extrait : « comptez les puzzles ou solve() retourne True sans utiliser le backtracking de secours. »

solve() (cellule 27) appelle _backtrack() sans aucun compteur ni flag : rien dans strategy_counts ni ailleurs ne distingue une résolution par déduction pure d'une résolution avec fallback. L'observable que l'indice ordonne de compter n'existe pas dans le code fourni — l'apprenant doit d'abord instrumenter le solveur lui-même. L'apprenant perd : l'exercice exige une modification non demandée du solveur pour devenir mesurable.

F3 — stale-claim (sous-famille « citation de sortie non locale ») — cellule e55b3e3d (Lecture XY-Wing), sortie visée produite par c78392d0 (test section 10)

Extrait : « La sortie ne dit pas seulement « 3 trouvés », elle imprime les pivots : Pivot=(7, 1), Aile1=(7, 5), Aile2=(7, 7) »

À sa position, la seule sortie à portée est celle de la cellule précédente : Methodes definies : _are_peers, find_xy_wings — une ligne, ni « 3 trouvés » ni pivots. Les pivots n'apparaissent que 4 cellules plus loin (sortie du test section 10). Les Lectures sœurs (44, 49) qualifient explicitement le renvoi (« la cellule de test de la section 10 ») — celle-ci le présente comme « La sortie » locale. L'apprenant perd : il remonte les sorties précédentes chercher des pivots introuvables et croit avoir raté une exécution.

---

Notes de campagne :

• exercise-mismatch passe à 9 occurrences Hermes — organe déjà proposé (sous-famille « numérotation », Audit critique au long cours des 1343 notebooks -- campagne Hermes + NanoClaw, decouverte de classes et organes #17073) ; F1-F2 relèvent des sous-familles « corpus absent » / « observable absent » déjà documentées comme non mécanisables. Ligne additive, pas de nouvelle proposition.
• stale-claim passe à 27 occurrences ; sous-famille « citation de sortie non locale » cousine de « citation de cellule » (décalages d'index) — le renforcement demandé (résoudre l'index/la sortie citée, pas seulement le code cité) couvrirait ce cas.
• Paires Lecture/Interprétation empilées (30/31, 33/34, 39/40) : angles distincts (chiffres vs tableau qualitatif), pas de duplicate-reading déposé ; chevauchement partiel 39/40 (ratios exacts en 39, « 2-5x » en 40) → relève de la proposition d'organe NanoClaw si arbitrée.

Rappel de frontière : constats de série = matière à arbitrage, pas d'exécution.

[clusterManager-Myia]

Audit apprenant — Sudoku-18b-Statistical-Comparison-Python.ipynb (cycle #17073, partition Hermes, lecture seule)

Organes (passe réelle, checkout de363674a) : couverts — 0 signal sur check_split_reading_cells, check_interp_positioning, check_output_failure_text, check_cell_source_parses, restore_accents_canonical --check (0 cure ; 8 formes hors table banales : montre/suppose/signe/donne/borne).

Survol de série : Sudoku-18-Comparison (précédent, lu en headers) introduit 4 solveurs (naïf, MRV, Norvig, OR-Tools CP-SAT) et un benchmark multi-difficultés ; 18b est son compagnon statistique (README : « comble le gap méthodologique de Sudoku-18 »). Prérequis couverts : backtracking/MRV définis en propre dès la cellule d'intro de 18b, wilcoxon/mannwhitneyu importés. Aucun gap.
Vue d'ensemble de la série Sudoku (headers, max 5) : 00-Environment → 08-ConstraintPropagation → 09/10/11-CSP → 12-Quantum → 13-SAT → 14-SudokuSolverClass (C# only) → 15-ComputationalComplexity → 16-NeuralNetwork / 17-LLM (Python only) → 18-Comparison (paire miroir) → 18b (position OK) → 19-Lean-Propagation (companion Lean).

3 findings (prose non resynchronisée sur les sorties réelles — les trois introduits ou déplacés par les tranches #16398 / non corrigés par elles) :

---

F1 — stale-claim (cellules cell-fa845acc [07])

« Le temps moyen de 1,5 ms ne veut rien dire sans son incertitude. »

La cellule suivante (exécution 3) mesure « Temps moyen naïf = 1,187 ms » et l'IC [1,027, 1,347] ms. Le 1,5 ms est un vestige du notebook original #9805 (présent tel quel dans le blob 7a24cfa84 avant que le plan apparié #14828 ne change les timings) : l'apprenant cherche un 1,5 ms qui n'existe plus dans aucune sortie — la lecture «Lire l'intervalle» (cell 09) qui suit cite correctement 1,187 ms, ce qui rend l'incohérence visible. Non couvert par un organe (prose-only).

F2 — stale-claim (cellules cell-e3c8e58e [10])

« …donnent des médianes de ~0,3 ms à ~3,3 ms, soit un facteur 10. »

Le tableau de la sortie (cellule 05) affiche 0,273 (P4) à 2,800 (P3) : la borne haute ~3,3 ms ne figure dans aucune sortie. Pire, « facteur 10 » était cohérent avec 0,273→2,800 ≈ 10× (arrondi 0,3↔3,3 ×10), mais la version courante affirme un facteur 10 à partir d'une borne ~3,3 inexistante. Vestige du même blob parent (#9805/#14828 le portaient déjà — vérifié sur blobs ba922303e), jamais resynchronisé par la densification #16398.

F3 — stale-claim (cellules 1ba997c9 [12])

« (elle vaut exactement 2/2⁸, comme l'explique la section 5.1) »

Aucune section 5.1 n'existe (headers : 5 → 6, avec ###Lire… et ###La leçon…). L'explication du plancher 2/2⁸ est aujourd'hui dans l'Exercice 1 (cell 22) et la section pseudo-réplication (cell 19). Renvoi interne mort — l'apprenant cherche une sous-section inexistante. Introduit par la densification #16398 (présent dans de363674a, absent de ba922303e).

---

Exclusions appliquées (Parade 3) : « la honnêteté méthodologique » (cell 20) = style, pas déposé ; Exercice 2 Mann-Whitney vs section 4 Wilcoxon = choix pédagogique cohérent avec l'indice fourni, pas un finding ; figures non légendées : toutes les figures ont titre+axes légendés (vérifié cell 02/05/08/11/17).

Classe(s) déposée(s) : stale-claim ×3.

[jsboige]

Audit apprenant — Sudoku-06-AIMA-CSP-Python.ipynb (cycle #17073, partition Hermes, lecture seule)

Organes (passe réelle, checkout cb8269f5a) : couverts

• check_split_reading_cells, check_interp_positioning, check_output_failure_text, check_cell_source_parses : 0 signal.
• check_duplicate_sections : 1 signal dup_closing « resume » (cellules 45/46) — couvert par l'organe, une ligne de renvoi suffit.
• restore_accents_canonical : 0 cure, 18 formes hors table (pre ×5, tot ×2, affiche ×2, superieur ×2, ameliore, evitant, lecon, determinante, resout, variees, elimination) — la table de cure existante ne couvre pas ces formes ; signal organe, pas un finding.

Survol de série (Sudoku-04 SA, 05 PSO, 06-C#, 07 Norvig) + vérifications inter-notebooks : lecture cell 33 (« 62,4 ms / 81 / 0 ») confirme le jumeau C# (cell C# 33 : Solution (MAC): 56ms, 81 assignations, 0 backtracks) et le 473 ms Choco IKVM (cell C# Choco 26) — deux renvois exacts. Grille témoin = 45 indices ✓ (même corpus que 04/06-C#/11).

Findings : 1

1. stale-claim — cellules 8 (52ee651d) et 10 (10f2f163)
   • extrait (cell 10) : « la colonne 1 contient 1, 5, 2, 9, 4, 8 » ; (cell 8) : « ni 1, 5 (déjà en colonne) »
   • pourquoi : la colonne 1 de la grille témoin (sortie committée cell 5) est {2, 4, 5, 8, 9} — le 1 est en colonne 0 (ligne 1 « 1 . . ») ; l'apprenant qui vérifie l'indice contre la grille affichée deux cellules plus haut trouve une contradiction qui l'égare, alors que le point utile de l'indice (le domaine de (0,1) se réduit, ici à {6,7}) est juste. La cellule 10 répète la même liste fausse dans une lecture censée « décoder » la sortie pour l'apprenant.

RAS ailleurs : les trois exercices (get_cell_domain, analyze_fc_propagation, preprocess_ac3) sont des stubs TODO avec lecture honnête de leur sortie placeholder (cell 10, 44) — modèle de la classe, aucun ajout de contenu requis. Lecture CBJ (cell 41) : chiffres de la sortie (82/1/82 vs 91/10/82) exacts et nuance bookkeeping correctement problématisée. Résumé (45) cohérent avec les sorties (2,9 M assignations, 255, 81, 81).

[clusterManager-Myia]

[Hermes] Audit Sudoku-12-Z3-Python.ipynb (cycle 2026-09-23, campagne #17073) — 1 finding + 4 lignes additives. Organes : couverts, 0 signal (split_reading_cells, interp_positioning, output_failure_text, cell_source_parses, duplicate_sections : 0 finding ; restore_accents_canonical : 13 cures possibles dans 6/23 cellules md, 30 formes hors table — la table d'accents ne couvre pas resoudre, carre, regions, modeliser…, à remonter à la campagne accents).

---

F1 — progression-break (finding complet)

• Cellules : [15] id 7abaad82, [16] id f40ab878
• Extrait : return False # TODO etudiant : remplacer par la resolution reelle ⋯ (cellule suivante, sans aucun markdown entre) ⋯ class Z3BitVectorSolver: / """Solveur Z3 utilisant des BitVectors 4 bits."""
• Pourquoi : le 2ᵉ encodage de la comparaison annoncée en tête de section ([07] : « puis comparons les deux encodages », objectif d'apprentissage n°4) arrive immédiatement après le stub d'exercice Killer sans aucune cellule de transition — c'est le seul bloc de code d'enseignement du notebook sans cellule d'introduction ([08]→[09], [11]→[12], [22]→[23], [28]→[29] en ont toutes une) ; l'apprenant qui vient de lire « Exercice a completer » doit deviner depuis le nom de classe que l'exercice est fini et que la comparaison Int-vs-BitVec (le cœur du notebook) commence.

---

Lignes additives (instances d'appui pour détecteurs déjà proposés)

• stale-claim (sous-famille « durée figée en prose ») — cellule [10] id c6a48652 : « l'exemplaire sur lequel le solveur Int de la section suivante sera mesuré à 340,86 ms » — contredit la règle notebooks(#9377,#8052): porter le mandat « quantitatif tenu par le CI, pas par la prose » a l'interieur des notebooks — la vague #8052 re-epingle des valeurs qui rebougeront #9434 que les cellules [13] et [17] invoquent elles-mêmes pour le même temps de résolution (« il n'est pas fige ici ») : deux conventions pour le même nombre dans le même notebook.
• stale-claim (sous-famille « inventaire de section périmé ») — cellule [19] id tkp1ie77lp : « Cette section contient : Exercice 1 … Exemple guide … Exercice 2 » — la section 5 contient en réalité 5 blocs : la démo Optimize/maximize ([28]-[30]) et l'exercice minimise ([31]-[32], ajout feat(sudoku,#3801): demonstrate Z3 SMT optimization (Optimize/maximize) #7589) ne figurent pas à l'inventaire ; l'apprenant lit un plan faux de la dernière section.
• navigation-misplaced — cellule [18] id 64d13639 : le footer de navigation (« Infer Python >> ») est placé au milieu du notebook (suivi de 14 cellules : toute la section 5), et une seconde « ## Conclusion » existe en [33] id d7796c4b sans footer — l'apprenant qui suit le footer de [18] quitte le notebook en sautant exercices 1-2 et la démo Optimize, le contenu le plus distinctif du notebook.
• navigation-misplaced (série) — cellules [00] id z3-header et [18] : le lien avant « >> Infer Python » saute Sudoku-13 et Sudoku-14 ; contradiction croisée vérifiée sur les frères : Sudoku-13-Python déclare « << Sudoku-12 Z3 Python », Sudoku-14-Python n'a aucune navigation, Sudoku-15-Python déclare « << Choco (Sudoku-11) », et Sudoku-10-Python déclare « << Python Backtracking (Sudoku-01) ». La branche Python 10→15 est un faisceau incohérent, pas une chaîne — relevant de l'organe série check_notebook_nav_chain.py (baseline à comparer).

RAS vérifiés : citations croisées exactes (diagonales [1,4,3,7,2,6,5,8,9]/[3,7,1,9,2,8,6,5,4] ✓ contre la solution [23] ; reward 178 ✓ identique au jumeau CP-SAT #7589 ; plage « ~2x à ~6x » [17] et « 2.3x à 6.4x » [33] ✓ contre les 5 mesures [16] : 2,26x–6,43x) ; stubs C.1/C.2 conformes avec lectures honnêtes ([24], [27], [30]).

[clusterManager-Myia]

[Hermes] Rectification du panorama de série (body de cette issue)

Le panorama affirme : « La chaîne de navigation est correcte sur tous les frères vérifiés (02→03→04→05→06→07→08→09→10→12→15…) ». Cette affirmation est fausse en sens : elle ne vérifiait que les liens avant, qui existent bel et bien, mais la branche Python est un faisceau incohérent (constaté ce cycle sur Sudoku-12, cf. audit précédent) :

• 12-Python >> = 15-Infer (saute 13, 14) alors que 13-Python déclare « << Sudoku-12 Z3 Python » ;
• 14-BDD-Python : navigation absente ;
• 15-Python << = 11-Choco-Python (pas son prédécesseur canonique) ;
• 10-Python << = 01-Backtracking-Python (pas 09) ;
• 11-Python << = 11-C# et >> = 12-C# (bascule vers la branche C#).

La ligne « rien à réordonner » de l'ordre canonique reste valable ; c'est le maillage de navigation qui est à réparer, côté organe série check_notebook_nav_chain.py (backlinks + sauts, pas seulement l'atteignabilité avant).

[jsboige]

Audit — Sudoku-13-SymbolicAutomata-Python.ipynb (partition Hermes, campagne #17073)

Organes : OK — 0 signal sur 5 checks (split_reading_cells, interp_positioning, output_failure_text, source_parses, duplicate_sections) ; accents 9 cures / 2 cellules + 7 formes hors table.

3 findings :

1. stale-claim — cellule 25 (253accad) — extrait : « Le tableau qui s'affiche ci-dessous est la synthèse de l'échelle entière du notebook : reconnaître (le motif lookahead…), résoudre (Z3 sur 81 entiers…), optimiser (le Optimize de Sudoku-12 — produire la meilleure). »
Pourquoi : le tableau committé (sortie cellule 26) porte 5 lignes — aucune ligne ni rôle « optimiser », et aucun Optimize nulle part dans le notebook ; l'apprenant cherche dans le tableau un rôle que la prose lui promet et que ni le tableau ni la suite du notebook ne séparent. Attribué à la tranche densité #16393 : la prose parent (blob 123d766fc) énonçait « Trois outils, trois rôles distincts » sans la mention optimiser — la tranche a inséré la promesse sans toucher au tableau.

2. stale-claim (renvoi positionnel cross-twin) — cellules 00 (92986127), 18 (e5a48069), 19 (8cd6348c, y compris output committé) — extrait : « Le twin C# démontre (cellule 15) que System.Text.RegularExpressions rejette cette syntaxe à la construction. »
Pourquoi : dans le twin C# (55 cellules), l'index 15 — markdown ou code, 0- ou 1-indexé — expose la logique M2L-str, sans aucun rejet ; la démonstration réelle vit aux cellules 40-41 (§8 banc d'essai, ids bench00rec1/bench00rec2). L'apprenant qui saute à la cellule citée tombe sur un autre sujet. Aucun id cell-15 n'existe côté C#. Préexistant : les deux twins naissent au même commit 123d766fc — la tranche ne l'a ni créé ni corrigé.

3. exercise-mismatch — cellules 13 (7ff0f87c) + 14 (c87338d8) — extrait : « Exercice 2 — Sudoku-X (…) ajoutez deux contraintes Distinct : sur la diagonale principale (cells[i, i]) et l'anti-diagonale (cells[i, 8-i]). »
Pourquoi : Sudoku-12 (prérequis direct, section 5) fournit déjà en « Exemple guide : Solveur Z3 avec contrainte diagonale » la solution complète des deux mêmes diagonales (cells[i][i] et cells[i][8-i]) ; l'apprenant qui suit la série recopie le solveur du notebook précédent — l'exercice ne teste plus rien.

RAS sur le reste : échelle 4 barreaux + BDD propre, lectures ancrées sur sorties réelles (sat 101,8 ms vérifiée, 27,2 ms backtracking, 6 lignes BDD = 3!), navigation cellule 00 correcte (asset sudoku-unrolled.regex.txt présent, 13 515 c.), section 9 BDD = teaser assumé avec renvoi explicite vers Sudoku-14 (survolé : BDD/MDD y est traité en profondeur).