Fix(sudoku,#20356): stubs booleens C.1 -- return False -> return None (5 carnets)

scripts/notebook_tools/twin_pairs.d/sudoku-01-backtracking.yaml

@@ -11,3 +11,4 @@
     - "Divergence d'implementation : le Python implemente le backtracking from scratch (fonction recursive + suivi des conflits) avec une visualisation matplotlib/numpy du deroulement ; le C# implemente le backtracking pur en stdlib (System.*) sans visualisation. Meme algorithme, niveau d'abstraction et d'enrichissement visuel differents."
     - "Asymetrie structurelle : Python 13 cellules code / 20 markdown (implementation complete + benchmark/visualisation + exercices) ; C# 8 cellules code / 11 markdown (resolution compacte). Idiomes framework : C# = stdlib System.*, Python = numpy + matplotlib + time."
     - "2026-08-20 (c.1301+261, myia-po-2025:CoursIA-2) : flip verdict RECOVERABLE-LOCAL -> SOTA-OK (bucket 3 de #10382). Faux positif : la raison disait 'lib SOTA n'est PAS requise' mais le verdict restait RECOVERABLE-LOCAL (= installable, pas installe). Verifie firsthand : Python = numpy/time/typing stdlib only, C# = BCL pure 0 NuGet. Aucune lib SOTA-tier partagee entre les deux ecosystemes pour Norvig (port pedagogique). Les DEUX cotes sont des ports directs from-scratch du Norvig reference implementation -- le from-scratch EST la contrepartie (bucket 3), pas un manque a installer."
+    - "2026-10-11 (grain REPAIR/MED notebook-python #20356, myia-po-2027:CoursIA-2) : normalisation C.1 du stub d'exercice booleen cote Python -- `return False  # TODO` devient `return None  # TODO`. Le jumeau C# n'est PAS touche : sa convention de stub est `return null; // TODO` partout ou le type le permet (Dictionary, objets), et `return false;` / `return 0;` la ou le type l'interdit -- bool et int ne sont pas nullables en C#. C'est une contrainte de langage, pas une divergence pedagogique : la serie C# entiere porte ces litteraux (Sudoku-09 cell27, Sudoku-12 cell37/41, Sudoku-18 cell23, entre autres). Les DEUX cotes restent des exercices NON IMPLEMENTES ; seul le litteral de retour a change cote Python, d'un resultat fabrique vers une absence explicite. Le blob SHA Python deplace dans l'audit ci-dessus est l'artefact de cette normalisation, pas une derive de l'algorithme enseigne."

scripts/notebook_tools/twin_pairs.d/sudoku-01-backtracking/0014-2026-10-11-myia-po-2027-CoursIA-2.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-11'
+by: myia-po-2027:CoursIA-2
+python_sha: e5ada05b8d5bb10acaef6e74befd228b68bc1daa
+csharp_sha: 95f2a198c247d88ad8555ecf43f8554a252ffddf
+content_python_sha: 0659a9554d85e51acdc002ade9cea832f351b1e5bc50db3587a34ddf7ff26f8a
+content_csharp_sha: 765a83bd6498be259f67f32f53362f3b0e9d6cbaf7622a22d514b10e9540de05

scripts/notebook_tools/twin_pairs.d/sudoku-02-dancinglinks.yaml

@@ -9,3 +9,4 @@
     - "Socle pedagogique commun : algorithme Dancing Links (DLX) de Knuth / Algorithm X pour la couverture exacte (exact cover), applique a un mini-Sudoku 4x4. Meme concept mathematique (matrice binaire de couverture, selection de colonnes a cardinalite minimale, unlinking/relinking des noeuds), meme cas d'application (mini-Sudoku 4x4), meme exercice pedagogique (construire la matrice de couverture, stub TODO)."
     - "Divergence d'implementation : le C# delegue a la lib DlxLib (NuGet `#r \"nuget: DlxLib\"`, classe `DancingLinkSolver : ISudokuSolver` qui wrappe le solveur de la lib, importe le socle `Sudoku-00-Environment-CSharp.ipynb`) ; le Python implemente Dancing Links ENTIEREMENT from scratch (`class DancingLinksNode` a 4 voisins gauche/droite/haut/bas + `class DancingLinks` construisant la matrice creuse et executant l'Algorithm X de Knuth manuellement). Meme algorithme, deux niveaux d'abstraction : lib industrielle cote C# vs reconstruction pedagogique a la main cote Python."
     - "Asymetrie structurelle : Python 12 cellules code / 21 markdown (implementation complete from scratch + docstring algorithmique detaillee) ; C# 10 cellules code / 16 markdown (wrapper DlxLib + exercice BuildMiniSudokuMatrix). Idiomes framework : C# = DlxLib + System.*, Python = stdlib (typing, dataclasses), 0 dependance numerique."
+    - "2026-10-11 (grain REPAIR/MED notebook-python #20356, myia-po-2027:CoursIA-2) : normalisation C.1 du stub d'exercice booleen cote Python -- `return False  # TODO` devient `return None  # TODO`. Le jumeau C# n'est PAS touche : sa convention de stub est `return null; // TODO` partout ou le type le permet (Dictionary, objets), et `return false;` / `return 0;` la ou le type l'interdit -- bool et int ne sont pas nullables en C#. C'est une contrainte de langage, pas une divergence pedagogique : la serie C# entiere porte ces litteraux (Sudoku-09 cell27, Sudoku-12 cell37/41, Sudoku-18 cell23, entre autres). Les DEUX cotes restent des exercices NON IMPLEMENTES ; seul le litteral de retour a change cote Python, d'un resultat fabrique vers une absence explicite. Le blob SHA Python deplace dans l'audit ci-dessus est l'artefact de cette normalisation, pas une derive de l'algorithme enseigne."

scripts/notebook_tools/twin_pairs.d/sudoku-02-dancinglinks/0008-2026-10-11-myia-po-2027-CoursIA-2.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-11'
+by: myia-po-2027:CoursIA-2
+python_sha: 0de8baae7403933137c53178252e3982ba02e2c8
+csharp_sha: 568b1ea9e39f2d07860830ac09015fc1d4818681
+content_python_sha: 2b2a362769bd847f776322ddb4d6c1ccd36c1a49154699c2888837d14e46c98c
+content_csharp_sha: 556f350515d3f05ff6926ff3bba338a4a346de421283bec06af6839bde90c1be

scripts/notebook_tools/twin_pairs.d/sudoku-05-pso.yaml

@@ -16,3 +16,4 @@
     - "Idiomes framework : Python = numpy + matplotlib, 15 cellules code, mealpy optionnel (import try/except non execute -- output committe) ; C# = System.* (Tranche 1) + GeneticSharp 3.1.4 (Tranche 2), 16 cellules code. Asymetrie attendue cote C# : Tranche 1 sans lib numerique (System.* stdlib), Tranche 2 avec moteur metaheuristique de production (GeneticSharp)."
     - "2026-08-19 (c.140, myia-po-2026:CoursIA-2) : Tranche 2 GeneticSharp ajoutee cote C# (lib-vs-lib #10382, bucket mealpy/simanneal -> MGS) : chromosome permutation-ligne, fitness -NbErrors, operateurs custom (OX par ligne, swap intra-ligne), TplTaskExecutor + RandomizationProvider, redemarrages, comparaison croisee PSO-from-scratch vs GA-GeneticSharp sur 3 puzzles faciles (15 s max). Correction honnetete du census : mealpy cote Python = import optionnel NON execute (output committe : « mealpy non installe (optionnel) - ce notebook utilise PSO manuel ») -- le PSO execute cote Python est manuel numpy, symetrique du System.* cote C# Tranche 1. Grain d'enrichissement Python restant (non bloquant) : installer mealpy et brancher la cellule deja prevue."
     - "Tranche 5 (#10382, 2026-08-22 re-applique, lane myia-po-2025:CoursIA ; initialement Tranche 3 le 2026-08-20, renumerotee apres l atterrissage des Tranches 3-4 #11977 sur main) : double-face mealpy. Twin Python : fix de l import drift (mealpy.problem -> mealpy.utils.problem, mealpy 3.x) + annexe mealpy native OriginalPSO 3 seeds. Twin C# : pont PythonNet -> mealpy (meme instance/budget/seeds), insere apres la Tranche 4. Les deux chains re-executees post-merge (0 erreur). Flip RECOVERABLE-LOCAL -> SOTA-OK."
+    - "2026-10-11 (grain REPAIR/MED notebook-python #20356, myia-po-2027:CoursIA-2) : normalisation C.1 du stub d'exercice booleen cote Python -- `return False  # TODO` devient `return None  # TODO`. Le jumeau C# n'est PAS touche : sa convention de stub est `return null; // TODO` partout ou le type le permet (Dictionary, objets), et `return false;` / `return 0;` la ou le type l'interdit -- bool et int ne sont pas nullables en C#. C'est une contrainte de langage, pas une divergence pedagogique : la serie C# entiere porte ces litteraux (Sudoku-09 cell27, Sudoku-12 cell37/41, Sudoku-18 cell23, entre autres). Les DEUX cotes restent des exercices NON IMPLEMENTES ; seul le litteral de retour a change cote Python, d'un resultat fabrique vers une absence explicite. Le blob SHA Python deplace dans l'audit ci-dessus est l'artefact de cette normalisation, pas une derive de l'algorithme enseigne."

scripts/notebook_tools/twin_pairs.d/sudoku-05-pso/0022-2026-10-11-myia-po-2027-CoursIA-2.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-11'
+by: myia-po-2027:CoursIA-2
+python_sha: 6166a2beebe1af7d3ca2b3504a03100977964e44
+csharp_sha: e5537a12da13d4113cbe3b20426ab04f3bb07319
+content_python_sha: bb6e591063248c3aed8c5b9f9b74976c04e1acf5e750ba66d950832de37baa93
+content_csharp_sha: 944eb74b776eca035020edf4a9912840f20ca8905d53b729b87de72d8a555aa2

scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools.yaml

@@ -9,3 +9,4 @@
     - "Socle pedagogique commun : resolution du Sudoku par programmation par contraintes avec OR-Tools CP-SAT (Google.OrTools), meme solveur sous-jacent, meme modelisation (variables IntVar par case, contraintes AllDifferent sur lignes/colonnes/blocs, objectif de satisfaction)."
     - "Idiomes framework symetriques : Python = `from ortools.sat.python import cp_model` (binding Python natif), C# = NuGet `#r \"nuget: Google.OrTools\"` + `using IntVar / SimpleCPSolver / SimpleConstraint` (binding .NET). Les deux cotes deleguent au meme moteur CP-SAT de Google, seules les API de binding different."
     - "Parite structurelle proche : Python 13 cellules code / 17 markdown ; C# 14 cellules code / 21 markdown. Arc pedagogique identique (formulation CP-SAT -> exemple resolu -> benchmark de passage a l'echelle)."
+    - "2026-10-11 (grain REPAIR/MED notebook-python #20356, myia-po-2027:CoursIA-2) : normalisation C.1 du stub d'exercice booleen cote Python -- `return False  # TODO` devient `return None  # TODO`. Le jumeau C# n'est PAS touche : sa convention de stub est `return null; // TODO` partout ou le type le permet (Dictionary, objets), et `return false;` / `return 0;` la ou le type l'interdit -- bool et int ne sont pas nullables en C#. C'est une contrainte de langage, pas une divergence pedagogique : la serie C# entiere porte ces litteraux (Sudoku-09 cell27, Sudoku-12 cell37/41, Sudoku-18 cell23, entre autres). Les DEUX cotes restent des exercices NON IMPLEMENTES ; seul le litteral de retour a change cote Python, d'un resultat fabrique vers une absence explicite. Le blob SHA Python deplace dans l'audit ci-dessus est l'artefact de cette normalisation, pas une derive de l'algorithme enseigne."

scripts/notebook_tools/twin_pairs.d/sudoku-10-ortools/0012-2026-10-11-myia-po-2027-CoursIA-2.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-11'
+by: myia-po-2027:CoursIA-2
+python_sha: ff73ba3ac84e6d60b508ded7d84d8491e5a6bce2
+csharp_sha: eea8ed76aed7f21bcc876bde2600a9d35059bed2
+content_python_sha: 79c58bf8bd3ba16f0ff7acc643c60c965205760ee0a76c650dadb34ada438356
+content_csharp_sha: 533f4a38b1621df6070d8e5bb07e738a14a67b3292adb5603c569db6f294cd1f

scripts/notebook_tools/twin_pairs.d/sudoku-12-z3.yaml

@@ -14,3 +14,4 @@
     - "#9434 drainage Python (2026-08-05) : cellules markdown 12 + 16 figeaient des temps absolus machine-dependants (340.86 ms, 271.18/68.65/462.26/71.84/222.89/61.95/389.18/117.54/237.59/105.18 ms) = frozen dups des outputs live des cellules code 11 (Z3Solver) et 15 (Z3BitVectorSolver + time). Drainage markdown-only : ms absolus remplaces par qualitatif + pointeur vers la cellule de benchmark live ; speedup structurel conserve (~2-6x, observationnel, cf #9434 App-11 precedent). Correction G.9 : la note originale disait 'C# non touche (estimations de duree, pas des frozen dups)' -- c'etait INEXACT, les timings C# (166,5 ms, 1367 ms...) sont eux aussi des frozen dups des outputs TestSolvers (cellule 19)."
     - "#9434 drainage C# (2026-08-06) : cellules markdown 24 (Interpretation des resultats) + 29 (Conclusion) figeaient les memes temps absolus machine-dependants (166,5/273,8 ms, 273,2 ms, 182,5 ms, 1367 ms, 294,5 a 470,9 ms) = frozen dups des outputs TestSolvers. Drainage markdown-only (twin du pattern Python #9507) : ms absolus remplaces par qualitatif + pointeur vers la cellule de banc d'essai live ; speedup structurel conserve (~3 a 5x, ordre de grandeur stable cross-machine). Parite Python/C# retablie : les deux twins refletent desormais le meme registre de mesure (live, pas prose figee). 2 claims machine residuels legitimes (TN) : '3 s max par grille' = budget de config, '~40 minutes' = duree pedagogique totale (ni l'un ni l'autre n'est une mesure de performance)."
     - "2026-09-27 (grain REPAIR/MED notebook-python #17239, myia-po-2023:CoursIA-2) : traitement des 4 constats de l'audit Hermes du 23/09 sur le seul jumeau Python (F1 : ajout de la cellule markdown de transition manquante entre le squelette Killer et Z3BitVectorSolver ; F2 : nuance sur la mesure citee ; F3 : inventaire de la section 5 complete de 3 a 6 entrees ; F4 : pied de page 18 remplace par 34, aligne sur le jumeau C#). 13 insertions / 46 suppressions sur 1 notebook, markdown uniquement -- aucune cellule de code modifiee, aucun output modifie, aucune re-execution due (C.2, exception markdown-only). Les blob et content SHAs Python deplaces dans l'audit ci-dessus sont des artefacts de cette reprise redactionnelle, pas une divergence pedagogique : les deux twins resolvent toujours le meme Sudoku par le meme solveur Z3, et le cote C# n'a pas ete touche."
+    - "2026-10-11 (grain REPAIR/MED notebook-python #20356, myia-po-2027:CoursIA-2) : normalisation C.1 du stub d'exercice booleen cote Python -- `return False  # TODO` devient `return None  # TODO`. Le jumeau C# n'est PAS touche : sa convention de stub est `return null; // TODO` partout ou le type le permet (Dictionary, objets), et `return false;` / `return 0;` la ou le type l'interdit -- bool et int ne sont pas nullables en C#. C'est une contrainte de langage, pas une divergence pedagogique : la serie C# entiere porte ces litteraux (Sudoku-09 cell27, Sudoku-12 cell37/41, Sudoku-18 cell23, entre autres). Les DEUX cotes restent des exercices NON IMPLEMENTES ; seul le litteral de retour a change cote Python, d'un resultat fabrique vers une absence explicite. Le blob SHA Python deplace dans l'audit ci-dessus est l'artefact de cette normalisation, pas une derive de l'algorithme enseigne."

scripts/notebook_tools/twin_pairs.d/sudoku-12-z3/0015-2026-10-11-myia-po-2027-CoursIA-2.yaml

@@ -0,0 +1,6 @@
+date: '2026-10-11'
+by: myia-po-2027:CoursIA-2
+python_sha: 1cc184afcff03273dd4d5bc2ecb44e7c5fb3d58b
+csharp_sha: de44d3131395164cb10105a9d64f25c214468bef
+content_python_sha: 9de61e5e1741167fd88d8373c1992a6985bdc4174740edb2a1be4493862b88ed
+content_csharp_sha: 76d83ac233d41b1b20f2a5ac6d1f0adccef089d45eb4c6da9b17c76899422dad