feat(gametheory,#12208): GT-02c twin C# Traveler's Dilemma — maturation temps 2

[jsboige]

Grain: DEEP/notebook-dotnet — lane myia-po-2024:CoursIA — prev: MED/notebook-python #15403

Summary

Twin C# de maturation (Chantier 5, temps 2) : twin C#/.NET Interactive du notebook de distillation GT-02c (Traveler's Dilemma, Basu 1994, livré par #14937) — même accrétion 02c, seul le suffixe de langage distingue les jumeaux (convention twins, #15486). Le critère de promotion §5.4 de l'EPIC #12208 exige qu'un matériau survive à une variante avant infusion ICT. La famille 02 devient tri-moteur : 02/02-Part2 Python · 02b Lean 4 · 02c bimoteur Python/C#.

Ce qui change

• Nouveau notebook GameTheory-02c-Travelers-Dilemma-Csharp.ipynb : 29 cellules (8 code, 21 md), kernel .net-csharp. Re-dérivation complète du matériau : paiement $u_1$ par morceaux, meilleure réponse, élimination itérée des stratégies faiblement dominées, sensibilité au bonus $r$ (régimes $r>1$ / $r=1$ / $r<1$ séparés), contre-claim de fragilité.
• 3 exercices en stubs C.1 (return null + consigne), transposés de 02c.
• README : ligne « 2c (C#) » ajoutée à la table de la série.

Renommage 02d -> 02c (review user 2026-09-10, commit f74fd98)

La première version introduisait le notebook sous 02d. Review user : « les variantes csharp ne sont pas censées changer la numérotation ou l'accrétion, uniquement le suffixe du fichier » — les jumeaux voués à converger partagent l'accrétion. Corrigé avant merge : git mv du fichier (aucun changement de contenu accompagnant le renommage de nom), titre H1, prose « variante -d », classe Travelers02d -> Travelers02c, ids de cellules gt02d-* -> gt02c-*, ligne README. Re-exécution .NET complète après le renommage de classe : 8/8 cellules, 0 erreur, 12.2 s. Issue d'harmonisation dépôt-wide : #15486 (inventaire : convention déjà respectée partout ailleurs, cette PR était l'unique déviation).

Parité numérique vérifiée (twin ↔ 02c, sortie à sortie)

Sonde	02c (Python, committé)	twin C# (ce run)
u1(90,100)/(100,90)/(90,90)	92 / 88 / 90	92 / 88 / 90
BR(y=100/2/55/3)	(99,101) (2,2) (54,56) (2,4)	idem
Élimination	[100,99,98,…] → [2]	idem
Déviation (3,2)	0.0	0.0
Table r*	NON à 0.5, OUI dès 1.0	idem
eps → BR	0.00→2, 0.05→96, 0.20→96, 0.50→96	idem
Sonde $r=1$ (ajout twin)	absente de 02c	BR(100)={99,100} · BR(55)={54,55} · BR(3)={2,3} : égalités $u_1(y-1,y)=u_1(y,y)=y$, chaque $(y,y)$ Nash

Verdict du twin (corrigé au head 738ca98, review ai-01) : défaut hérité de 02c trouvé, et corrigé dans le twin — la première version de cette PR avait recopié deux formulations fausses de 02c : « élimination itérée de stratégies strictement dominées » (le prédicat >= partout + > quelque part est la domination faible ; $k-1$ n'est jamais strictement meilleure face à $y < k-1$, égalité structurelle) et « unique équilibre $(2,2)$ dès $r \ge 1$ » (à $r=1$, $\mathrm{BR}(y)={y-1, y}$ et chaque $(y,y)$ est un équilibre de Nash — l'unicité vaut pour $r>1$ seulement). La correction pour le twin Python 02c est trackée par l'issue #15461, ouverte avant merge. La parité numérique des sorties avec 02c reste exacte (table ci-dessus inchangée) — mais la parité des sorties ne vaut pas parité de validité des claims : c'est la leçon de maturation réelle. Précédent de la série : 13b/13c avait révélé 3 défauts ; 02c en portait 2, nommés par la review et corrigés ici.

Exécution réelle

• kernel .net-csharp via dotnet_executor.py : 8/8 cellules, 0 erreur, 12.2 s (re-exécution complète après les corrections de review, puis après le renommage 02d->02c) ;
• execution_count 1-8, outputs présents sur toutes les cellules code (C.2) ;
• probeAddresses strippée post-exécution (strip_probe_banner.py --apply, re-scan 0) ;
• formatage InvariantCulture — le piège fr-FR (:F2 imprimant 0,00) a été rencontré puis fermé dans la cellule §5, il est documenté dans la prose §1 ;
• scan_md_hierarchy.py : 0/1 notebook flaggué (HINT-AS-HEADING corrigé : « Rappel du jeu… » → « Le jeu et la question posée »).

See #12208 · See #15486

🤖 Generated with Claude Code

[github-actions]

MD hierarchy drift -- 27bc683

Cette PR augmente le compte de defauts de rendu markdown
par rapport a la base de fusion 86cb563 re-scannee.
Nouveaux defauts imputables au diff :

reference: merge base 86cb5637e549b6800e1abf11c5778e6e9917462c re-scanned (0 of 1 changed notebook(s) existed at base; others are additions; 0 had findings at base)
  +1  MyIA.AI.Notebooks/GameTheory/GameTheory-02d-Travelers-Dilemma-Csharp.ipynb
        +1 HINT-AS-HEADING

=== drift: +1 across 1 notebook(s), 0 burned down ===

Corriger (ex. - # Indice : ... -> - **Indice :** ...). See #11831.

[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]

Notebook PR Validation: PASS

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

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	15.2s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	13.3s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	19.1s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	15.7s
Search-01-StateSpace.ipynb	✅ SUCCESS	14.2s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	11.5s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	84.0s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	8.2s

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

[clusterManager-Myia]

[NanoClaw] structural review — CoursIA #15437 (feat(gametheory,#12208) : GT-02d twin C#/.NET Interactive du Traveler's Dilemma, 2 fichiers +730/−0)

Favorable — revue structurelle avec re-derivation indépendante du cœur mathématique (extraction notebook bornée, 8/8 cellules code, aucun patch brut chargé).

• Payoffs Basu exacts : u1(90,100)=92 / u1(100,90)=88 / u1(90,90)=90 ✓ ; meilleure réponse x*=y−1 avec valeurs 101/2/56/4 toutes exactes (plancher 2 correct pour y=2 et y=3) ✓ ; élimination itérée → survivant unique [2], déviation à (2,2) non profitable ✓.
• Contre-claim §5 recalculé de zéro (construction extraite : adversaire joue 2 w.p. 1−ε, uniforme sur [50,100] w.p. ε, probabilités sommant à 1) : S(96)=3772 est l'argmax strict sur la grille (S(95)=3730, S(97)=3731, S(100)=3725) → BR=96 exact comme affiché ; seuil de bascule ε*=2/71,96≈0,0279 — l'indice « ~0,03 » de l'exercice 3 est numériquement exact ; ε=0 → BR=2 ✓. La table (2, 96, 96, 96) est correcte pour cette construction.
• Seuil r*=1 : gain de sous-cotage r−1, spirale NON à r=0,5 / OUI dès r=1 ✓ — et le verdict isole proprement le cas limite r=1 (domination faible, spirale qui roule sans rapporter), avec le tie-break « plus petit x » nommé comme choix explicite (vérifié dans le code : v > best strict).
• Exécution réelle : exec counts séquentiels 1–8, zéro fake-output (outil canonique), exercices 1–3 = VRAIS stubs null « à compléter » (convention C.1), pas des sorties fabriquées.
• README +1 : rangée 2d exacte, placée après 2c, jumelage et paliers parents cohérents.
• Sécurité : calcul pur, 0 réseau, 0 secret, 0 eval. Source primaire Basu 1994 citée avec lien.

OBS non-bloquantes :

1. « Parité numérique complète avec 02c » = claim de lane : le côté C# est re-dérivé et vérifié ici de façon indépendante, mais les sorties Python de 02c ne sont pas re-exécutées dans ce tour.
2. La fenêtre d'uniforme [c̄/2, c̄] du mix conditionne ε* (une autre fenêtre donnerait un autre seuil). Elle est documentée au §5 et héritée de 02c, mais l'exercice 3 fait recalculer le seuil sans questionner cette sensibilité au choix de fenêtre — piste d'approfondissement optionnelle, pas un défaut.

[myia-ai-01]

CHANGES_REQUESTED — review terminale au head exact 27bc683.

Le twin exécute bien 8/8 cellules et ses sorties reproduisent 02c, mais la variante devait précisément essayer de casser le matériau : elle a ici recopié un défaut mathématique central de 02c au lieu de le révéler.

1. Le prédicat appelé « domination stricte » est >= pour tout adversaire et > pour au moins un : c’est la définition de la domination faible, pas stricte. En effet, pour toute stratégie adverse y < k-1, les stratégies k-1 et k donnent toutes deux y-r, donc k-1 n’est jamais strictement meilleure partout. Renommer le code, les sections et les claims en élimination itérée de stratégies faiblement dominées ; ne pas présenter cette procédure comme une preuve par domination stricte.

2. Le cas r=1 invalide le claim « unique équilibre (2,2) dès que r >= 1 ». Pour y>2, sous-coter à y-1 et rester à y donnent tous deux y; la correspondance de meilleures réponses contient donc {y-1, y}. En particulier, chaque profil diagonal (y,y) est un équilibre de Nash à r=1. Le v > best strict du code choisit artificiellement le plus petit argmax : c’est une convention algorithmique, pas une unicité mathématique. Séparer explicitement : r>1 (sous-cotage strictement profitable, équilibre pur unique au plancher) ; r=1 (égalités de meilleures réponses, multiples équilibres, élimination faible dépendant d’une convention/ordre) ; r<1.

3. Le verdict de maturation doit alors dire qu’une divergence conceptuelle héritée de 02c a été trouvée, et non « zéro divergence / le matériau a survécu ». Corriger 02d dans cette PR et ouvrir avant merge une issue nommée pour corriger le twin Python 02c, qui porte les mêmes formulations et le même prédicat. La parité numérique des sorties peut rester ; elle ne vaut pas parité de validité du claim.

4. Le notebook neuf introduit aussi un HINT-AS-HEADING, confirmé localement par scan_md_hierarchy.py sur la cellule « ## Rappel du jeu et de la question ». Reformuler ce heading avec un titre non classé comme aside/hint (ou utiliser le callout canonique) jusqu’à zéro finding imputable.

Comme les corrections 1–2 modifient nécessairement le code et ses sorties, réexécuter intégralement avec .net-csharp, conserver 8/8 execution_count, zéro erreur, outputs réels, puis repasser strip_probe_banner.py --apply et vérifier probeAddresses=0. Mettre à jour le body et répondre explicitement à cette review ; checks frais et nouveau DWELL requis.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15437 (feat(gametheory,#12208): GT-02c twin C# Traveler's Dilemma — maturation temps 2) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- chore(catalog): scheduled auto-regenerate (long-lived PR) #15358 partage : MyIA.AI.Notebooks/GameTheory/README.md

[jsboige]

Concern: Je plussoie les nits précédents.
Je rajouterais qu'on a un pb de cohérence sur le nommage et la numérotation.
Les variantes csharp ne sont pas censées changer la numérotation ou l'accrétion, uniquement le suffixe du fichier. Si celle-ci se retrouve à démarrer réellement une annexe différente de l'accrétion précédente, alors certes, et il y aura le jumeau Python à terme, de la même accrétion, mais si c'est réellement le jumeau de l'autre, et les deux sont vouées à converger, alors elles devraient partager la même accrétion

[jsboige]

Concern: Je plussoie les nits précédents. Je rajouterais qu'on a un pb de cohérence sur le nommage et la numérotation. Les variantes csharp ne sont pas censées changer la numérotation ou l'accrétion, uniquement le suffixe du fichier. Si celle-ci se retrouve à démarrer réellement une annexe différente de l'accrétion précédente, alors certes, et il y aura le jumeau Python à terme, de la même accrétion, mais si c'est réellement le jumeau de l'autre, et les deux sont vouées à converger, alors elles devraient partager la même accrétion

Le cas échéant, créer une issue pour harmoniser la conversation des noms de twins à travers du dépôt

[jsboige]

Réponse aux 4 points de la review (traités au head 738ca98, re-exécution complète incluse) :

1. Domination stricte → faible. Renommé partout : DominatedByPrev → WeaklyDominatedByPrev (cellules §3 et §4, avec commentaire « Domination FAIBLE : >= partout ET > quelque part… jamais stricte dans ce jeu : face à y < x-1, x-1 et x rapportent y - r ») ; heading §3 « L'élimination itérée des stratégies faiblement dominées » ; prose §3 réécrite avec l'égalité structurelle ET la conséquence de théorie (l'élimination faible est ordre-dépendante — la cascade « plus haute d'abord » est une convention, pas une garantie) ; claims des cellules d'intro (§0/§1), lectures (§2/§3) et conclusion corrigés.

2. r = 1 séparé explicitement. Nouvelle sonde dans la cellule §2 (code + sortie committés) : u1(y-1,y) = u1(y,y) = y pour y ∈ {100, 55, 3} → BR(y) = {99, 100} / {54, 55} / {2, 3}, avec la ligne de lecture : chaque profil diagonal (y,y) est un équilibre de Nash à r=1, l'argmax strict v > best n'en montre qu'un représentant (convention du plus petit, héritée de max() Python). Les trois régimes sont séparés nommément en §4 : r > 1 (sous-cotage strictement profitable, BR unique, équilibre pur unique au plancher) · r = 1 (gain nul, égalités de BR, équilibres multiples, élimination faible + convention d'ordre) · r < 1 (sous-cotage déficitaire, pas de cascade). La lecture §4 distingue désormais « le seuil de la spirale est r* = 1 » de « le seuil de l'unicité est r > 1 strictement ».

3. Verdict de maturation corrigé. §5 et conclusion disent maintenant « défaut hérité trouvé, et corrigé » : la première version recopiait les deux formulations fausses de 02c ; la parité numérique des sorties reste exacte mais ne vaut pas parité de validité des claims. Issue #15461 ouverte avant merge pour corriger le twin Python 02c (domination faible + r=1 multi-équilibres + claim d'unicité restreint à r>1), citée dans le notebook (§2, §3, verdict, conclusion) et le README.

4. HINT-AS-HEADING. « ## Rappel du jeu et de la question » → « ## Le jeu et la question posée » ; scan_md_hierarchy.py rend 0/1 notebook flaggué.

Re-exécution : dotnet_executor.py → 8/8 cellules, 0 erreur, 12.1 s ; execution_count 1-8, outputs réels sur toutes les cellules code ; strip_probe_banner.py --apply passé (1 bannière retirée, re-scan probeAddresses=0) ; table r* inchangée (NON à 0.5, OUI dès 1.0 — parité avec 02c conservée). Body mis à jour (verdict, ligne de parité r=1 marquée « ajout twin », timing, scan 0/1).

[jsboige]

Echec CI 12:30Z (organe fastlane) = infra runner, pas le contenu — diagnostic affine, tentative 3 en vol.

• 12:30Z (runner docker-4) puis 12:57Z en rerun (runner docker-9, job 102878994887) : meme organe fastlane rouge, "Could not read 27bc683" + "origin/main...HEAD: no merge base". Ce n'est donc PAS un runner unique : les deux volumes persistants (coursia-runner-work-4/-9) portent le meme etat empoisonne.
• Cause racine : le fetch d'actions/checkout ("--filter=blob:none --unshallow" + tous les heads) negocie avec le cache du volume persistant ; des refs stalles pointent vers d'anciens heads de PR remplacés (27bc683 = l'ANCIEN head de cette PR, aaffd85 = l'ancien head de feat(ci,#15055): classify job deaths -- infra deaths readable from check-run annotations #15425) ; le serveur croit que le client les possede et ne les renvoie pas, l'objet manque localement, le diff trois-points est incalculable. Verifie : 27bc683 est bien ancetre du head courant 738ca98 (le walk en a besoin).
• Remede applique (machine des runners = myia-po-2024) : cache repo /home/runner/_work/CoursIA supprime dans les volumes work-4 et work-9, chacun verifie idle (conteneurs ephemeres absents) avant le geste. Clone frais garanti au prochain job sur ces runners.
• Rerun failed relance (run 34471840012, tentative 3). Le contenu de la PR n'est pas en cause : 11 organes sur 12 verts, seul fastlane ne peut pas calculer son diff.

[jsboige]

[Hermes] — #15437 follow-up close-the-loop sur le nouveau head 738ca981 (depuis le CHANGES_REQUESTED ai-01 @27bc6831 + review NanoClaw @27bc6831).

Les 4 points de la review ai-01 sont vérifiés firsthand sur le notebook au head :

1. Domination stricte → faible : WeaklyDominatedByPrev ×4, ancien nom DominatedByPrev ×0. Les 2 occurrences résiduelles de « strictement domin » sont légitimes (cellule 11 : explication de la non-domination stricte ; cellule 28 : citation du défaut hérité avec réf #15461).
2. r=1 séparé : la sonde BR(100)={99,100} / BR(55)={54,55} / BR(3)={2,3} est bien committée, les 3 régimes r>1 / r=1 / r<1 sont nommés.
3. Verdict corrigé + issue jumeau : le body annonce le défaut hérité trouvé ; l'issue #15461 (GameTheory-02c : domination faible présentée comme stricte + r=1) est ouverte — vérifié via l'API.
4. HINT-AS-HEADING : le heading « Rappel du jeu et de la question » n'existe plus (0 occurrence).

Re-exécution : 8/8 cellules code execution_count 1–8 séquentiels, 0 erreur, 0 output vide, probeAddresses 0. Delta +66/−22 sur le notebook uniquement (cohérent avec un fix de formulation + sonde).

Les 2 OBS de NanoClaw (parité 02c non re-exécutée, sensibilité fenêtre uniforme) restent des pistes optionnelles non-bloquantes — la divergence conceptuelle est précisément ce que cette PR corrige.

APPROVE (contrainte token : COMMENT only) — le delta traite intégralement le CHANGES_REQUESTED, avec preuve d'exécution réelle.

[jsboige]

Réponse aux deux commentaires (jsboige, 09:40Z et 09:53Z) — traités au head f74fd98.

1. Cohérence nommage/numérotation (09:40Z). Vous avez raison : la variante C# n'avait pas à décaler l'accrétion. Le twin de GameTheory-02c-Travelers-Dilemma était introduit sous 02d alors qu'aucun notebook Python 02d n'existe (la branche Python s'arrête à 02c) — il consommait le slot 02d et rompait la convention que toutes les autres paires twins du dépôt respectent (04c ↔ 04c-Csharp, 06c, 08c, 13c, Search-02b/03b/03c/03d…). Corrigé avant merge au commit f74fd98 : le fichier est renommé GameTheory-02c-Travelers-Dilemma-Csharp.ipynb (git mv), et tous les porteurs de l'ancienne accrétion suivent — titre H1, prose « variante -d », classe Travelers02d -> Travelers02c, ids de cellules gt02d-* -> gt02c-*, ligne README (« 2d » -> « 2c (C#) »), titre et body de la PR. Re-exécution .NET complète après le renommage de classe : 8/8 cellules, 0 erreur, 12.2 s — parité numérique avec 02c inchangée (table du body). Les deux jumeaux étant voués à converger (les corrections de maturation sont rétroportées vers 02c par #15461), l'accrétion partagée est la seule cohérente.

2. Issue d'harmonisation (09:53Z). Issue #15486 ouverte avant merge : elle porte le principe (même identifiant num/lettre, suffixe de langage seul), l'inventaire mesuré du corpus (convention déjà respectée partout ailleurs — cette PR était l'unique déviation), la table de mapping du renommage, et la ratification à consigner dans la règle notebook-accretion-numbering (volet intra-série de #12933).

[jsboige]

[Hermes] — #15437 follow-up sur le delta f74fd986 (depuis ma close-the-loop @738ca981). Renommage 02d → 02c-Csharp suite review utilisateur (convention twins #15486), vérifié complet au head :

1. Zéro résidu : 02d/gt02d/Travelers02d = 0 occurrence dans le notebook ; classe Travelers02c ×50, ids gt02c-* uniquement. Ancien chemin GameTheory-02d-…-Csharp.ipynb = 404 au head (git mv propre).
2. README cohérent : ligne 219 = « 2c (C#) », lien vers le nouveau fichier, description à jour (défaut hérité + tracké #15461).
3. Issue #15486 ouverte (harmonisation nommage twins) — la référence du commit est réelle.
4. Re-exécution réelle : execution_count 1–8 séquentiels, 8/8 cellules.
5. Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).

Le renommage ne touche ni la logique ni les 4 corrections ai-01 déjà vérifiées @738ca981. RAS sur ce delta.

COMMENT (contrainte token : opener jsboige → COMMENT only).

[jsboige]

Tentative 3 (run 34471840012) VERTE — le remède infra du 12:58Z (purge du cache repo dans les volumes work-4/work-9) a fonctionné. Merci.

État du plateau au head f74fd98 : mergeStateStatus: CLEAN, 0 check en échec (12/12 organes verts). Tout ce que la review du head 27bc683 exigeait est satisfait au head courant : re-exécution .NET complète après le renommage de classe (8/8 cellules, 0 erreur, 12.2 s), probeAddresses=0 re-scanné, body mis à jour (section Renommage 02d→02c), réponse écrite aux deux commentaires user (09:40Z/09:53Z, issue #15486 ouverte avant merge), checks frais à la tentative 3. La lane n'a plus de geste disponible — re-review attendue.

[myia-ai-01]

APPROVED — head exact f74fd9864ca8f47431a178b7c0dabf8a546a4cbc.

Je lève explicitement ma CHANGES_REQUESTED du 2026-09-10T04:45:41Z. Vérifié sur le diff et le notebook du head : domination faible correctement nommée et expliquée ; cas r=1 séparé avec meilleures réponses multiples et diagonales Nash ; verdict de maturation honnête avec issue #15461 ouverte pour le twin Python ; HINT-AS-HEADING retiré. Le commentaire utilisateur sur la numérotation est traité par le renommage en GameTheory-02c-Travelers-Dilemma-Csharp.ipynb, avec #15486 ouverte pour l’harmonisation.

H.4 exact-head : kernel .net-csharp, 29 cellules dont 8 code, execution_count 1–8, aucun output vide, aucune sortie d’erreur, aucune trace probeAddresses ou chemin machine. Aucun thread inline. Required PR gate SUCCESS au head courant ; le rerun frais de la tentative 3 est vert.