Fix(Tweety): 5 notebooks C# sous Linux et macOS, RID IKVM dérivé de la machine, lot B2 (hors flotte)

[jsboige]

Hors flotte : PR de la session cloud d'agnosticisme du mainteneur (branche claude/*, exemption #17713, rôle décrit dans docs/reference/agent-cloud-agnosticisme.md). Pas de tag Grain:, pas de lane. See #17654, sous l'EPIC de parité Linux #10643. Dernier lot de la série Tweety, après #18067 (lot A) et #18444 (lot B1), toutes deux mergées.

Summary

• Lot B2 : cinq notebooks C# (Tweety-06-Structured-Argumentation, 07a-Extended-Frameworks, 07b-Ranking-Probabilistic, 08-Agent-Dialogues, 09-Preferences) codaient le RID win-x64 en dur dans leur configuration IKVM. Sous Linux, cette configuration fait échouer l'initialisation de la JVM IKVM au premier appel Java (échec mesuré sur Tweety-3-Dung dans Fix(Tweety): 8 notebooks C# via IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18067 ; la cellule en cause est la même ici).
• Même recette que Fix(CSP,Sudoku): Choco via IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18031, Fix(Tweety): 8 notebooks C# via IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18067 et Fix(Tweety): 5 notebooks C# et la sonde IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18444 : RID dérivé de OperatingSystem et RuntimeInformation.ProcessArchitecture. Les cinq s'exécutent de bout en bout sous Linux ; sous Windows, le RID calculé vaut win-x64, donc le même home qu'avant.
• Après cette PR, plus aucun notebook du dépôt ne code en dur le RID win-x64 dans sa configuration IKVM (voir le point 5 de la checklist).

Changes

Cellules de configuration IKVM, dans les cinq notebooks :

• La déclaration ikvmRid = "win-x64" devient une expression (win, osx ou linux, suivi de - et de l'architecture du processus en minuscules), précédée d'une ligne de commentaire.
• La ligne #r "nuget: IKVM.Image.runtime.win-x64, <version>" est retirée là où elle existait (06, 07b, 08, 09) : IKVM.Image tire déjà les onze runtimes natifs. Tweety-07a ne référençait que IKVM 8.15.0, qui dépend de IKVM.Image (même cas que Tweety-10-MLN dans Fix(Tweety): 5 notebooks C# et la sonde IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18444).

Tweety-09 C#, cellule de chargement de la DLL : elle affichait le chemin absolu de la DLL (C:\dev\CoursIA-tweety9\... sur la base). Ré-exécutée ailleurs, elle aurait écrit le chemin de cette machine dans la sortie. Elle affiche désormais le chemin relatif au dossier du notebook (Path.GetRelativePath), avec une ligne de commentaire. C'est la cause corrigée à la source, sans retouche de sortie (règle 6 de secrets-hygiene.md).

Markdown :

• Tweety-07a C#, cellule 19 : « l'image d'architecture ikvm.image.runtime.win-x64 » devient « l'image d'architecture de la machine (ikvm.image.runtime.<rid>, par exemple win-x64 ou linux-x64) ».
• Tweety-09 Python (jumeau), cellule 22, tableau comparatif : la dépendance C# « IKVM 8.15.0 + IKVM.Image + IKVM.Image.runtime.win-x64 (NuGet) » devient « IKVM 8.15.0 + IKVM.Image (NuGet ; IKVM.Image tire le runtime natif de chaque plateforme) ». Cellule markdown seule : pas de ré-exécution due.

Le jumeau Python Tweety-07b, annoncé dans #18444, ne cite plus ce runtime sur main depuis #18151 : il n'est pas touché.

Registre de parité jumelle : les cinq notebooks appartiennent chacun à une paire. Chacune reçoit une attestation --update --by claude-cloud:hors-flotte, posée après les strips outillés ; ses SHA sont ceux des blobs de tête. Les YAML de paire ne changent pas : les écarts ci-dessous sont des écarts d'environnement, pas des différences entre jumeaux.

Le diff compte 11 fichiers : les 6 notebooks (5 C# et le jumeau Python Tweety-09) et les 5 attestations. Hors notebooks, il fait 30 lignes, les 5 attestations de 6 lignes : le seuil §A de 3000 lignes se compte hors notebooks.

Diagnostic dérive

Comparaison cellule par cellule entre la base (flotte, Windows) et cette tête (clone vierge Linux), sur le texte des sorties, CRLF normalisés :

Notebook	Cellules code	Sorties identiques	Écarts
Tweety-06-Structured-Argumentation	15	14	culture (8,0 Mo → 8.0 Mo)
Tweety-07a-Extended-Frameworks	18	14	langue de l'avertissement CS1701 du compilateur (déjà présent sur la base, en français), culture (0,857 → 0.857)
Tweety-07b-Ranking-Probabilistic	10	9	culture (13,0 Mo → 13.0 Mo)
Tweety-08-Agent-Dialogues	11	9	culture (1,374 → 1.374) ; identité d'un objet Java affichée par toString() (GroundedGameSystem@577e881 → @37e1826)
Tweety-09-Preferences	9	7	RID du home IKVM ; chemin de la DLL (voir Changes), culture

Classement des causes :

• (a) env/kernel : RID du home IKVM (objet de la PR), culture du poste (séparateur décimal, langue des avertissements du compilateur), chemin de chargement de la DLL. Sur Tweety-09, la base chargeait la DLL depuis dotnet-build/bin/Release/net8.0/, un dossier de build présent sur ce poste-là seulement ; un clone vierge la charge depuis la racine de la série, par le repli prévu dans la cellule. Même DLL, même taille (0,6 Mo), mêmes 44 types exposés. language_info.version de Tweety-09 passe de 12.0 à 13.0, la version déclarée par le pin dotnet-interactive 1.0.617701 (même alignement que sur Tweety-3-Advanced-Logics dans Fix(Tweety): 8 notebooks C# via IKVM sous Linux et macOS, RID dérivé de la machine (hors flotte) #18067). Verdict CAUSE_FIXED.
• (e) non déterministe : l'identité d'objet Java affichée par Tweety-08 (cellule 7) change à chaque exécution. La prose ne la cite pas. Verdict CAUSE_INTRINSIC.
• Les résultats calculés (extensions, classements, agrégations Borda/Condorcet/Copeland, dialogues) sont identiques à la base. Aucune sortie n'a été touchée à la main.

La prose de Tweety-08 (cellule 20) cite les espérances en notation française (Pro-TL = 1,374, Anti-TL = 0,731) : c'est la même valeur que la sortie Linux (1.374, 0.731), rien à changer.

Verdict SOTA : SOTA-OK. Le vrai moteur (TweetyProject 1.30 via IKVM) s'exécute. Il n'y a ni substitution ni réimplémentation. L'organe-first ne s'applique pas : rien n'est réimplémenté.

Review Checklist

• 1. Scope — cellules de configuration IKVM, prose qui les décrit, une ligne d'affichage de Tweety-09 ; le registre de parité suit.
• 2. Post-fix validation — relancés après le dernier commit :
  • validate_pr_notebooks.py origin/main : PASS ;
  • check_output_failure_text.py origin/main : 0 regressed ;
  • check_output_collapse.py et check_source_collapse.py : 0 flagged ;
  • check_kernel_drift.py origin/main : 0 regression ;
  • check_twin_parity.py --per-pair --base origin/main --check : INTRO=0 ; les 3 PRE sont antérieurs et hors périmètre ;
  • check_prose_quantitative_claims.py --diff origin/main...HEAD --strict : OK ;
  • check_docs_links.py --check --base origin/main : 0 nouveau lien cassé ;
  • check_machine_dep_timing.py sur les six notebooks : 0 ;
  • strip_machine_paths.py --scan sur les cinq notebooks C# : 0 ;
  • scripts/check_markdown_claims_output.py : mêmes verdicts et même nombre de findings (64) sur la tête et sur la base.
• 3. Pedagogical coherence — exercices et stubs inchangés.
• 4. Real execution — notebook_tools.py execute <nb> --kernel .net-csharp sur les cinq, sous Linux (dotnet-interactive 1.0.617701, .NET 9) : exec_count 15/15, 18/18, 10/10, 11/11, 9/9, et 0 erreur. Puis strip_probe_banner.py --apply et scrub_papermill_paths.py --apply. Contre-vérification du chemin d'un clone vierge : les homes /tmp/ikvm-home-* supprimés avant chaque notebook, puis ré-exécution papermill vers un fichier hors dépôt ; chacun reconstruit son home linux-x64 (IKVM home=OK) et va au bout, 0 erreur.
• 5. Regression check — grep -rlE 'ikvmRid *= *"win-x64"|IKVM\.Image\.runtime\.win-x64' --include=*.ipynb MyIA.AI.Notebooks ne rend plus aucun notebook, dans aucune série. Les autres occurrences de win-x64 en cellule de code sont hors IKVM : choix conditionnel déjà multiplateforme (série MGS), ou chemins natifs de notebooks GenAI (LLamaSharp, ONNX Runtime GPU) liés à Windows.

Anti-regression

• Pas de Lean/Coq touché.
• Aucun test désactivé.
• Aucune suppression de code métier : une ligne #r redondante retirée dans quatre des cinq notebooks, justifiée par le .nuspec.

Notebook-specific

• Aucun raise NotImplementedError / assert False / 1/0 introduit.
• Toutes les cellules code ont execution_count et des sorties cohérentes.
• Seuls les notebooks dont une cellule source a changé sont committés (C.3).

Test plan

Sur un poste Linux ou macOS, avec .NET 9 et dotnet-interactive 1.0.617701 :

python scripts/notebook_tools/notebook_tools.py execute MyIA.AI.Notebooks/SymbolicAI/Tweety/Tweety-09-Preferences-CSharp.ipynb --kernel .net-csharp

Le notebook doit aller au bout et afficher NuGet IKVM 8.15.0 (<rid>) : OK avec le RID de la machine.

Constat signalé, non corrigé ici (hors périmètre) : le tableau comparatif du jumeau Python Tweety-09 (cellule 22) décrit encore la DLL C# comme « 7,4 Mo compilee depuis fat-jar shade Maven » et cite DLL size : 7,4 Mo. La sortie C# affiche 0,6 Mo sur la base comme ici, et le YAML de la paire documente la DLL de 641 Ko livrée par rebuild-preferences.sh. À reprendre par la flotte dans une PR dédiée.

Environnement de mesure : conteneur Linux x64, 4 threads, clone vierge, hors flotte.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VuVMY5fhzd5cQhzHiyvjka

---

Generated by Claude Code

[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).

[github-actions]

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

[jsboige]

Check en échec : Always-on guards -- 16 organes, 1 checkout, organe hot_subset (scripts/translation/tests/test_hot_subset_ratchet.py, job 109664887400). Ce rouge vient de main, pas de cette PR.

Ajout à 00:13Z : le même test fait aussi échouer Scripts Tests (CPU) (job 109664886734 : 1 failed, 16706 passed, 112 skipped). C'est le seul test en échec, avec la même cause.

Ajout à 01:57Z : le correctif existe désormais en PR, #18530 (translations/genai/image.csv seul). Son diff est exactement le rafraîchissement du pivot proposé plus bas : mêmes 2 lignes rafraîchies, mêmes 4 ajoutées. Je ne le porte pas ici : ce serait ajouter un fichier de traduction GenAI à une PR Tweety, et un commit de contenu ré-armerait le plancher DWELL de 120 min. Une fois #18530 sur main, une fusion de main dans cette branche, sans conflit, suffira à ces deux checks sans ré-armer le plancher.

• Cellule en cause : MyIA.AI.Notebooks/GenAI/Image/01-Foundation/01-1-OpenAI-DALL-E-3.ipynb, cellule a02bbf24, verdict SRC_DRIFT (csv=bb9ce1f5af3ac379, actuel=a75ff37c764ac29c).
• Origine : b8f6e37f1 (TP1 - Exercice 1 : Construction progressive de prompts #18449, mergée à 23:15Z) transforme l'exercice 1 de ce notebook en exemple guidé sans resynchroniser translations/genai/image.csv. La ligne porte une traduction russe déposée, d'où son entrée dans le hot-subset.
• Reproduit sur main seul : avec les versions origin/main du notebook et du CSV, le test échoue à l'identique (1 failed, 1 passed). Cette PR ne touche ni ce notebook ni translations/.

Correctif proposé, mesuré en local sur les fichiers de main :

python scripts/translation/extract_cells_to_csv.py --update translations/genai/image.csv \
  MyIA.AI.Notebooks/GenAI/Image/01-Foundation/01-1-OpenAI-DALL-E-3.ipynb

Cette commande rafraîchit le pivot de 2 lignes (a02bbf24, 61d83ca5), en ajoute 4 (les nouvelles cellules de #18449) et signale 2 orphelines ; le test repasse alors (2 passed). Elle laisse cependant text_ru et hash_ru de a02bbf24 tels quels : ils traduisent encore l'ancien « Exercice 1 » (### Упражнение 1, toujours présent dans #18530). Le correctif complet retraduit cette cellule en russe dans la même ligne.

Je n'ai pas les droits pour relancer le job (403). Je garde la PR sous surveillance.

---

Generated by Claude Code

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	4.4s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	3.8s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	4.5s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	4.2s
Search-01-StateSpace.ipynb	✅ SUCCESS	3.4s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.5s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	14.7s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	3.2s

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

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

Notebook PR Validation: PASS

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

[clusterManager-Myia]

VERDICT: LGTM (vérifié: protocole v2 — 6 carnets extraits base↔head, diff mécanique par cellule réconcilie l'annonce EXACTEMENT ; RID dérivé + retrait #r runtime + chemin relatif vérifiés dans les sources ; attestation yaml = blob sha1 exact des carnets head ; les 3 checks rouges sont hérités de main, preuve croisée sur une autre PR)

[NanoClaw] structural review — protocole v2, 6 carnets (5 C# + jumeau Python 09) extraits au base (b6cf954c = main) et head (87e2eb72). Note de méthode : la branche est 1-ahead/3-behind main ; les 3 commits de main absents (GenAI ×2 + script rename) ne touchent aucun fichier de la PR ⇒ mes diffs par carnet = le commit de la PR. Siège sans .NET/IKVM : pas de re-exécution (déclaré) — la re-exécution Linux des 5 carnets est celle du body, corrélée par les enregistrements papermill committés (2026-09-29 22:55-22:58Z, durations 38,9/28,7/17,7/7,1/8,7 s).

Le diff mécanique réconcilie l'annonce cellule par cellule. Sources changées : EXACTEMENT les cellules de config IKVM (06:15-16, 07a:21, 07b:2-3, 08:22 — le gros bloc §6 parité, 09C#:2-3) + les 2 md annoncées (07a:19, 09Py:22). Aucune autre source ne bouge ; compte de cellules inchangé partout (30/48/21/28/23/26). Le hash porte sur le texte joint (l'array source peut se ré-sérialiser sans changement de contenu — mon premier passage sur l'array brut flaggait 2 md fantômes, artefact écarté). Vérifications in vivo : base 09C# cell. 2 porte ikvmRid = "win-x64" littéral + #r IKVM.Image.runtime.win-x64 → head dérive le RID ((IsWindows() ? "win" : IsMacOS() ? "osx" : "linux") + "-" + ProcessArchitecture.ToLowerInvariant(), cohérent avec les 11 runtimes natifs d'IKVM.Image) et la ligne #r runtime est retirée ; cell. 3 : dllPath → Path.GetRelativePath(Environment.CurrentDirectory, dllPath) — la fuite de chemin absolu est corrigée à la source, pas en retouchant la sortie. Les 2 md correspondent mot à mot aux annonces (07a:19 généralise ikvm.image.runtime.<rid> ; 09Py:22 remplace la dépendance runtime win-x64 par « IKVM.Image tire le runtime natif de chaque plateforme »).

Sorties : spot-check 06 cell. 19/20 base↔head — contenus identiques (mêmes règles ASPIC+, mêmes extensions fondées/préférées), seule la fin de ligne varie (CRLF→LF, la normalisation annoncée du body). Les classes de dérive annoncées (culture 8,0→8.0 Mo, langue CS1701, identité d'objet Java, RID du home) sont cohérentes avec mes empreintes par cellule. 09-Python : meta IDENTICAL, md seule — conforme à « pas de ré-exécution due ».

Attestations : le yaml tweety-9 porte python_sha 96d421d6… / csharp_sha 4c3d1906… = git blob sha1 exacts des deux carnets head (re-calculés par moi). Claim repo-wide corroboré : sur main, les seuls .ipynb portant le littéral IKVM.Image.runtime.win-x64 sont exactement les 6 carnets de cette PR (les autres hits = docs + yaml d'attestations historiques, hors périmètre du grep du body) ⇒ après merge, zéro.

Metadata : 09C# language_info 12.0→13.0 (annoncé, pin dotnet-interactive — Kernel drift guard : pass) ; papermill ajouté/rafraîchi sur les 5 C# ; gain d'hygiène mesuré : la base 07b portait des chemins absolus Windows (C:\Users\jsboi\AppData\Local\Temp\...) dans papermill, head nettoyé.

Checks (pas d'APPROVE) — les 3 rouges ne sont PAS de cette PR : Always-on guards, Scripts Tests (CPU) et PR gate échouent sur une seule racine : test_hot_subset_ratchet SRC_DRIFT sur GenAI/.../01-1-OpenAI-DALL-E-3.ipynb cell a02bbf24 — carnet que la PR ne touche pas (1 failed / 16706 passed sur Scripts Tests). Preuve d'héritage : la même signature exacte apparaît à 23:52Z sur #18429 (qui ne touche pas GenAI non plus), et la PR fix/18166-reprise-stale-facts passe le même organe en vert à 00:05Z — le resync CSV per-cell (#13551) existe déjà quelque part, la dette est à main (fenêtre post-merge #18449 b8f6e37f), pas à ce head. Les organes propres aux carnets sont tous verts au head : kernel drift, twin parity ×2, exec-sequence ratchet, papermill ratchet, Quarto build, prose-counts, translation drift (85 pass / 3 fail hérités). Merge à attendre le resync main — décision Emerjesse.

[github-actions]

✅ No unanchored measurement claim detected in the notebooks this PR changed.

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.

[jsboige]

Tête dc7d4e08d : fusion sans conflit de main (#18530 comprise). Le test hot_subset passe désormais, en local comme en CI. Scripts Tests (CPU) reste rouge, pour une autre cause que cette PR ne touche pas.

Job 109733639770, runner myia-po-2026-wsl-2 : 4 failed, 16719 passed. Les quatre échecs sont dans scripts/lean/tests/test_lean_exec.py :

• test_admission_cap_machine_wide_two_worktrees, avec « vu 0 » : aucun run enregistré en 30 s ;
• test_queue_wait_admits_after_release, test_queue_timeout_refuses et test_queue_full_refuses, avec « 1er run enregistré non atteinte sous 30 s ».

Pourquoi ce n'est pas cette PR :

• elle ne touche pas scripts/lean/, et main n'y a rien changé depuis la tête précédente ;
• ces mêmes tests passaient au run précédent de cette PR, sur un autre runner ;
• les autres runs Scripts Tests de la nuit n'échouent que sur hot_subset ;
• les quatre tests passent en local sur cette tête (4 passed en 29,9 s).

Cause probable, lue dans le code mais pas mesurée sur le runner, car les runs lancés par ces tests ont leur sortie jetée (DEVNULL) : l'admission de lean_exec.py lit l'état réel de l'hôte. scan_native_population() compte les lean et lake vivants par ps -eo comm=, et compute_granted() accorde cores - reserve_cores - population jobs CPU. Sur un runner qui partage sa machine avec des builds Lean, le budget tombe à 0 : tous les runs sont refusés et aucun ne s'enregistre. Le correctif de #18024 a neutralisé la RAM, commit et disque (NEUTRAL_RESOURCE_GATE), pas la population native ni le CPU.

Correctif proposé, hors périmètre de cette PR : ajouter une surcharge de test, par exemple une variable LEAN_EXEC_NATIVE_POPULATION lue par scan_native_population(), que _env() fixerait à 0 avec LEAN_EXEC_RESERVE_CORES=0. Les tests d'admission ne dépendraient alors plus des processus de l'hôte.

Je n'ai pas les droits pour relancer le job (rerun-failed-jobs : 403). Je garde la PR sous surveillance.

---

Generated by Claude Code

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2026:CoursIA-3
pr: 18514
head: 02d9098
complete: true
body: read
comments-reviewed: 9
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 4c5993ec434f75bd280b109e253de63397ccc1659df678983f22f41c5924064f
diff-files: 11
diff-additions: 1906
diff-deletions: 1250
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]

#18514 — Fix(Tweety) 5 notebooks C# sous Linux/macOS (lot B2, hors flotte)
Tete 02d9098 (lane porteuse). mergeStateStatus CLEAN.
B.0 rc=0, threads-unresolved=0.
Checks : latest-wins-green (notebooks ratchets, hot_subset reussi au plus tard, golden-set exec, kernel drift guard, twin parity, validate-notebooks).
scope 11 fichiers, 1906 add / 1250 del.

— secretariat verificateur c267