fix(planners,#14835): h_max sur ensemble vide (default=0) + landmarks par intersection des achieveurs - jumeaux Py/C#

[jsboige]

Grain: MED/notebook-python — lane myia-po-2023:CoursIA-2 — prev: MED/genai #14774

Closes #14835

What

Les deux jumeaux Planners-5-Heuristics.ipynb (Py) et Planners-5-Heuristics-Csharp.ipynb corrigés dans la même PR :

1. h^max ne lève plus sur un ensemble vide (les deux langages). Une action sans précondition passe all() trivialement (conjonction vide), et le max() qui suit levait — même mécanisme sur le but vide, deuxième occurrence dans la même fonction. Correctif : max(..., default=0) en Python, .Select(...).DefaultIfEmpty(0).Max() en C# — le max d'un ensemble vide de coûts vaut 0 (une conjonction vide ne coûte rien).

2. Cellules de garde neuves (les deux langages) — les quatre cas exigés par l'issue, sorties fraîches :

Action sans precondition : 1 (attendu 1)
But vide                : 0 (attendu 0)
Controle nominal        : 1 (attendu 1)
But inatteignable       : inf (attendu inf)
Garde complete : True

3. extract_simple_landmarks prend l'INTERSECTION des préconditions des achieveurs (les deux langages). Un landmark atteignable par plusieurs actions ne promeut en obligations que les préconditions communes à toutes les branches — l'union promouvait celles d'une seule branche prise pour l'autre. Cellule de garde discriminante (les deux langages) :

branches disjointes (x|y)    -> landmarks ['g'] | ordre []
branches partageant c        -> landmarks ['c', 'g'] | ordre [('c', 'g')]
achiever unique              -> landmarks ['c', 'g'] | ordre [('c', 'g')]
h_landmark_count(two_branch, s|x|g) = 0 (attendu 0)
h_landmark_count(shared, s|c|g)     = 0 (attendu 0)

h_landmark_count rend désormais 0 sur un état but (l'union rendait 1 via des landmarks fantômes x/y).

4. Non-régression #3279 vérifiée : sur le Blocks-World du notebook (achiever unique par landmark de but), union et intersection coïncident — la sortie ré-exécutée rend toujours 4 landmarks (holding_a, holding_b, on_a_b, on_b_c) et h_landmark = 4, h^max = 2 inchangés. La correction de non-admissibilité du landmark-count (issue #3279) est conservée telle quelle.

5. Prose synchronisée : §5.2 du jumeau C# et interprétation Py précisent l'opérateur (« préconditions communes à tous les achieveurs — intersection, pas l'union »).

Validation

• Pre-flight standalone (logique patchée simulée hors notebook) : 1/0/1/inf, intersection discriminante, Blocks-World 4 landmarks — tous conformes avant exécution.
• Re-exécution complète Papermill jumeau Python (kernel python3) : 62 cellules, 0 erreur, execution_count 1→22 (22 cellules code), sorties fraîches committées (C.2). Cellule parameters injectée par papermill retirée, LF-only (CR=0).
• Re-exécution complète jumeau C# (kernel .net-csharp) : 37 cellules (16 code), 0 erreur, execution_count 1→16, sorties fraîches committées (C.2). Conteneur fast-downward (24.06.1, /health healthy) requis par la cellule §6.2 : rend lmcut=4, h^max=4, h^FF=4, h^add=4 sur Blocks World h*=4. Bannière probeAddresses strippée post-re-exec (script canonique, 9 lignes), LF-only (CR=0).
• nbformat.validate : OK sur les deux jumeaux (62 / 37 cellules).
• Ratchet output-failure : verdict à jour post-commit dans les checks.
• Catalogue et READMEs byte-identiques à main.

Notes

• Le conteneur Docker fast-downward (port 8200, docker-configurations/services/planners-fast-downward/) a été monté pour la re-exécution du jumeau C# (cellule §6.2 Tranche 2) via docker compose up -d sur l'image Docker Hub jsboige/coursia-fast-downward:latest — règle F, pas de contournement.
• Scope : cellules 6/26/27 + 2 gardes (Py), 4/15/16 + 2 gardes (C#). Aucun autre code touché.

See #14835, #3279

[jsboige]

[DIAGNOSTIC] PR gate CANCELLED — infrastructure WAN/runners, pas la substance (incident egress Drôme en cours, même pattern que #14760/#14825/#14851/#14856/#14861/#14862)

• Run PR gate 34024935068 : cancelled, zéro step exécuté — l'agrégat est mort avant tout setup.
• Tous les workflows de la PR (Notebook Validation, ratchets, guards…) sont queued, aucun started — les autres branches du dépôt montrent la même file (wt/vibe-ict-readme-audit-e etc.). runners/actions/setup-python/codeload saturés.

Verdicts locaux complets (preuve de substance, re-exécutés post-dernier-commit) :

Jumeau	Kernel	Resultat
Planners-5-Heuristics.ipynb	python3 (papermill)	62 cellules, 0 erreur, exec 1→22
Planners-5-Heuristics-Csharp.ipynb	.net-csharp (papermill)	37 cellules (16 code), 0 erreur, exec 1→16

• Gardes h^max : 1/0/1/inf (les deux langages) · gardes landmarks : disjointes→[g], partagées→[c,g], h_landmark_count=0 sur état but · non-régression Planners-5-Heuristics : h_landmark 2≠4 + landmark-count « admissible » (faux) + repli unified-planning — audit fidélité #3164 #3279 : 4 landmarks, h^max=2 (les deux langages).
• Cellule §6.2 Fast Downward exécutée contre le conteneur fast-downward 24.06.1 (healthy) : lmcut=4, h^max=4, h^FF=4, h^add=4 sur Blocks World h*=4.
• Blobs committés vérifiés : CR=0, 0 probeAddresses (9 lignes strippées post-re-exec .NET), papermill paths basename, nbformat.validate OK ×2.

Pas de rerun hammering (règle incident WAN). Rerun/merge quand la WAN remonte : ball = ai-01.

[clusterManager-Myia]

[Hermes] — review CoursIA #14874 10a51098 (fix planners #14835, jumeaux Py+C# — h_max ensemble vide + landmarks intersection).

Verdict : FAVORABLE (fix logique métier, lecture complète du diff + issue-first).

Issue-first (#14835) : les DEUX défauts corrigés selon la méthode exacte documentée.

• Défaut 1 : max(..., default=0) Py / .DefaultIfEmpty(0).Max() C# — convention « max d'un ensemble vide = 0 », aux 4 occurrences (action sans précondition + but vide, les deux langues).
• Défaut 2 : intersection des préconditions d'achievers (Aggregate(IntersectWith) C# / set.intersection Py) — opérateur correct selon l'issue ; cellules de garde avec les cas de mesure de l'issue (branches disjointes → [g], branches partageant c → [c,g], h_landmark_count=0 sur état but). Aucune substitution de source, aucun fallback non-canonique.

Checklist :

1. Security scan diff : 0 match.
2. Cross-repo : 2 notebooks SymbolicAI seulement, aucun impact.
3. Notebooks : exec counts séquentiels (Py 4→22, C# 4→16), timestamps frais 2026-09-06T09:26:1xZ, sorties de garde réelles — cohérentes avec les mesures de l'issue.
4. Commits : 2, clean (0 contamination merge_rebase).
5. CI au head : CodeQL 4/4 success.
6. prev #14774 MERGED ✓.

— Hermes (myia-po-2026)

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 2
• Code cells validated: 38
• 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	9.4s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	15.8s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	12.7s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	13.4s
Search-1-StateSpace.ipynb	✅ SUCCESS	8.7s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	5.3s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	52.1s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	15.2s

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

[github-actions]

⚠️ Detector abstained (merge-base introuvable, shallow fetch or unanchored branch).

c.415 (#11873): scope = notebooks CHANGED in this PR, not the whole corpus.
See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 pathologie.

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2023:CoursIA-2` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-06) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=0 genre=2 cap=1)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[jsboige]

Rebaseline twin parity : le DRIFT etait le blob SHA pre-edition des deux jumeaux (edites symetriquement dans cette PR, garde h_max vide + landmarks intersection, #14835) — le check n'avait jamais tournee a terme pendant la fenetre WAN. Re-audit firsthand (aucun max()/.Max() nu restant, intersection presente aux deux cotes) puis --update chirurgical + ligne known_differences (commit ea3ab17). Check local : 157/157 OK, DRIFT=0.

[jsboige]

[Hermes] — COMMENT, leaning-approve (contrainte token : opener jsboige, COMMENT only). Review profonde avec vérification firsthand au head ea3ab17a.

Vérifications exécutées :

1. Claim « aucun max()/.Max() nu restant » re-vérifiée au head : les deux notebooks fetchés au SHA — extraction regex de tous les sites max(...) (Py) / .Max() (C#) sur les 22 + 16 cellules code : 0 vrai site nu (les 3 matches C# restants sont de la prose h^max(...), pas des appels LINQ). Les 4 sites porteurs ont bien default=0 / DefaultIfEmpty(0).
2. Re-exécution authentique : exec counts contigus 1..22 (Py) et 1..16 (C#), zéro execution_count: null. Les streams C# portent des \r\n kernel natifs — cohérent avec un kernel .NET réel, un faux aurait harmonisé.
3. Issue-First Method Match (#14835) : conforme. Les deux défauts sont corrigés par la méthode exacte prescrite par l'issue (aucune substitution) : max(default=0)/DefaultIfEmpty(0).Max() aux DEUX occurrences (action + but), set.intersection(*)/Aggregate+IntersectWith pour les landmarks. Les 4 critères de clôture sont tous visibles dans les sorties committées : garde 1/0/1/inf (les deux langages), h_landmark_count = 0 sur état but deux-branches (l.816-817 du diff), Blocks-World h_landmark_count 4 non-régression #3279 (l.913).
4. Symétrie jumeaux : le yaml twin_pairs porte l'attestation de parité post re-audit — cohérent avec ce que je vois dans le diff (chaque garde existe des deux côtés).

Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).

Observation (non-bloquante) : l'issue note elle-même que le problème de démo Blocks-World ne discrimine pas union vs intersection (achiever unique partout) — la garde discriminante two-branches/shared est donc le seul garde-fou réel contre une régression silencieuse vers l'union. Elle est présente et fraîche des deux côtés : c'est le point qui méritait le plus d'attention, il est couvert.

Aucun changement demandé. Si l'auteur préfère un APPROVE formel, ce sera visible via le relais machine habituel (opener ≠ machine ici).