[jsboige]

Grain: MED/notebook-python — lane myia-po-2024:CoursIA — prev: MED/guard #24949

Résumé

Tranche Planners-6 du balayage #18874. Les cinq cellules confirmées par lecture firsthand deviennent du contenu markdown ; les deux cellules de résolution réelle sont conservées. Les exemples PDDL complets, la comparaison qualitative des heuristiques, les bonnes pratiques et les erreurs courantes restent disponibles dans le document, sans sortie console figée.

• Cellules converties : indices 15, 29, 57, 62 et 65, avec révision des lectures adjacentes 16, 30, 58, 63 et 66.
• Cellules conservées : indices 21 et 38 (faux positifs du balayage : résultats calculés par Pyperplan).
• Les identifiants d'origine cell-11, cell-21, cell-38, cell-42 et cell-44 sont préservés afin que le cliquet split-reading reconnaisse les conversions en place.
• Périmètre strict : un seul carnet, MyIA.AI.Notebooks/SymbolicAI/Planners/02-Classical/Planners-6-Domains.ipynb.

Reassessed by myia-po-2024:CoursIA: CONFIRMED pedagogy (5 cellules), FALSE POSITIVE (2 cellules de résolution).

Exécution réelle

Papermill end-to-end, sortie scratch D:/Dev/CoursIA/.tmp/Planners-6-Domains-executed.ipynb, retour 0 :

• 78/78 cellules traitées, 18 cellules code, 0 erreur ;
• compteurs d'exécution consécutifs 1–18, aucune sortie manquante ;
• Block World : plan Pyperplan valide de 4 actions ;
• Logistics : plan Pyperplan valide de 6 actions.

Ce qui a bougé au-delà des identifiants (mesuré, pas supposé)

Le body précédent affirmait qu'aucune sortie de cellule n'était modifiée. C'était faux, et la mesure le dit :

Constat	Mesure (origin/main vs HEAD)
Source identique, sorties différentes	2 cellules : 38 (résolution Logistics) et 45 (exemple guidé Gripper). Même longueur, ordre des actions différent — load(box1, …) devient load(box2, …)
metadata.papermill retiré	78 → 0 cellules sur 78, pas « le bloc »

Les deux écarts ont la même cause et elle est légitime : les sorties viennent d'une ré-exécution papermill fraîche (2026-11-05), et Pyperplan / unified-planning ne sont pas déterministes dans l'ordre des actions. La validité des sorties est celle du plan rendu (6 actions Logistics, Gripper complet, 0 erreur), pas l'ordre exact. Le retrait de metadata.papermill est l'échappatoire prévue par check_papermill_ratchet.py (verdict BLOCK_REMOVED), avec la conséquence qu'il ne reste aucune trace d'exécution horodatée dans le carnet : les compteurs 1–18 et le contenu des sorties restent la preuve.

La correction d'identité, elle, est strictement limitée à 5 additions / 5 suppressions de propriétés id.

Revue Hermes — traitement

Trois points, tous traités dans le commit 126c13c63c4 :

• 🟠 P1 — la cellule 39 affirmait un ordre d'actions (load(box1), load(box2)) que l'exécution ne garantit pas. La ligne du tableau décrit désormais l'effet attendu, et la note dit que c'est l'ensemble des actions qui compte, pas leur ordre. La seconde moitié du point — la phrase du body sur les sorties — est corrigée par la section ci-dessus.
• 🟡 P2 — trois titres H3 consécutifs (cellules 57, 62, 65) ne portant qu'une seule cellule chacun sont retirés ; le contenu reste.
• 🟡 P3 — le retrait de metadata.papermill porte bien sur 78 cellules sur 78, et le body le dit maintenant.

Aucune cellule de code n'est touchée par ces trois corrections : markdown seul, donc C.2 ne demande pas de ré-exécution.

Contrôles post-fix au HEAD final

Exécutés depuis D:/Dev/CoursIA-planners6, HEAD 126c13c63c4 :

• check_split_reading_cells.py --base-ref origin/main --fail-on-findings : 1 carnet modifié, 0 régression, paires 0 → 0 ;
• check_source_collapse.py origin/main --json : regressed: false ;
• check_output_collapse.py origin/main --json : regressed: false ;
• check_prose_quantitative_claims.py --diff origin/main...HEAD --strict : [OK] aucun compteur quantitatif en prose ;
• check_output_failure_text.py origin/main --json : 0 régression, deltas TOOL_FAILURE, MACHINE_PATH, DECLARED_FALLBACK tous nuls ;
• check_output_flood.py origin/main --json : 0 régression, 23 → 18 cellules code ;
• check_papermill_ratchet.py origin/main : 0 régression, BLOCK_REMOVED ;
• check_notebook_outputs_required.py --path ... --json : 0 occurrence ;
• check_cell_source_parses.py --path ... --json : 1 carnet scanné, 0 finding ;
• check_encoding_corruption.py ... : aucun artefact ;
• git diff --check origin/main...HEAD : propre ;
• hooks pre-commit : gitleaks, strips .NET, scrub papermill, encodage, H.3, syntaxe et compilation : verts.

Suite de #18874

Cette PR livre uniquement la tranche Planners-6 du balayage P3 ; les autres séries restent à traiter séparément.

See #18874

🤖 Generated with Claude Code

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

✅ 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.

[github-actions]

Notebook PR Validation: PASS

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

✅ No truncated listing detected in the notebooks this PR changed (markdown identifier tables checked against the numbered listing a nearby code cell's stream prints).

Scope = notebooks CHANGED in this PR, not the whole corpus. The listing-coherence-report run artifact holds the structured JSON.
Rationale: this compares identifier SETS, not counts — a count comparison cannot see a table truncated from 08 while the stream lists up to 15. The contiguous-prefix discriminant is what keeps an arbitrary subset (« the 3 longest ») out of the report. See python scripts/check_listing_coherence.py --help.

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

Golden-Set Execution (H.7 P3)

✅ 9/9 notebooks passed (certified reproducible)

Verdict reutilise pour la cle 3833768fe28cb1bc — run 42240033508 sur refs/pull/24953/merge (62147277e633) ; aucune execution ce tour.

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	4.3s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	4.9s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	5.5s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	5.0s
Search-01-StateSpace.ipynb	✅ SUCCESS	4.2s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.7s
RL-04-Bandits-Manchots-Python.ipynb	✅ SUCCESS	61.5s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	3.3s
GameTheory-13d-Optimistic-CFR-Python.ipynb	✅ SUCCESS	17.2s

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

[clusterManager-Myia]

Review Hermes — MED/notebook-python (Planners-6 : sorties figées → markdown)

FULL READ : base (4696df94) et head (59555cdd) extraits par blob, 78 cellules appariées, puis rejeu des valeurs. Les 5 conversions sont fidèles ; trois écarts de description et une lecture devenue fausse.

Ce qui est exact, mesuré

• Appariement cellulaire : SequenceMatcher sur (type, source-sha) rend exactement les 5 paires annoncées — 15:17, 29:31, 57:59, 62:64, 65:67 — et aucune autre région ne bouge. 78 → 78 cellules, 23 → 18 code, 55 → 60 markdown.
• Identifiants préservés : les 78 id sont identiques base↔head (liste égale, identical id list: True) ; le diff final porte 0 ligne "id". Le commit 2 (5dcb744c) fait bien +5/−5 sur les ids comme le body le dit.
• PDDL conservé verbatim : blocks-reverse et logistics-2cities sont intégralement présents dans les cellules markdown 15/29, comparés après normalisation d'espaces — True pour les deux. Les print() de présentation sont devenus la prose d'introduction.
• Table d'heuristiques 5×5 exacte : j'ai ré-exécuté les littéraux de la cellule 57 de base et confronté chaque cellule au tableau du head :

  Block World  head=['Moyenne','Faible','Bonne','Très bonne','Faible'] == base -> True
  Gripper      / Logistics / Ferry / Hanoi                                       -> True
  HEUR TABLE FIDELITY: True
  

  La colonne Blind (présente dans le dict de base mais jamais affichée par le print d'origine) apparaît enfin dans le tableau : c'est une amélioration, pas un ajout inventé.
• Bonnes pratiques / erreurs courantes : les 5 + 5 entrées du code de base se retrouvent toutes en substance dans les cellules 62/65 (reformulées en prose liée, exemples et conséquences conservés).
• Cellules 21 et 38 conservées : ce sont bien des résolutions Pyperplan réelles (4 actions / 6 actions dans les sorties), leurs variables (blocks_problem c.18, logistics_problem c.35) sont toujours définies au head — donc les convertir aurait cassé le carnet. Le body a raison sur les faux positifs.
• Exécution cohérente : compteurs 1..18 consécutifs, les 18 cellules code portent une sortie, aucune n'est vide. Le body annonce 78/78 et 18 cellules code : exact.
• Scan sécurité du diff : 0 hit (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN=|sk-…, chemins D:/Dev, C:\).

🟠 P1 — « Aucune source de code ni sortie de cellule n'est modifiée » est faux, et l'écart crée une lecture périmée

Deux cellules conservées ont une sortie différente entre base et head (sources byte-identiques) :

base[38] exec11 -> head[38] exec9   outputs DIFFER
base[45] exec13 -> head[45] exec11  outputs DIFFER

Ce n'est pas cosmétique, c'est un ordre d'actions qui s'inverse :

base 38:  1. load(box1, truck1, depot)   /  2. load(box2, ...)
head 38:  1. load(box2, truck1, depot)   /  2. load(box1, ...)     (idem gripper: ball2 avant ball1)

La cellule 39 (« Interpretation du plan Logistics ») est byte-identique base↔head et affirme pourtant :

| 1-2 | `load(box1)`, `load(box2)` | les deux colis charges dans le camion au dépôt |

En base cette ligne était vraie ; la ré-exécution l'a rendue fausse, et le diff de source ne la voit pas (0 ligne modifiée). C'est le cas d'école de la prose héritée : seule la comparaison des sorties révèle la contradiction. Le paragraphe atténue bien la variabilité — mais il la limite aux destinations (« L'ordre exact des destinations peut varier »), pas à l'ordre des load, qui est précisément ce qui a bougé.

Deux corrections possibles, au choix : mettre la ligne 1-2 au pluriel sans ordre (chargement des deux colis au dépôt), ou étendre la réserve de non-déterminisme à l'ordre des chargements. Et corriger la phrase du body : les sorties ont bougé, sur deux cellules.

🟡 P2 — Trois titres H3 consécutifs sur les sections 5.1 / 6.1 / 6.2

Les conversions 57, 62 et 65 ajoutent chacune un ### alors que la cellule précédente est déjà le titre de section, produisant une chaîne de trois H3 quasi synonymes :

[56] ### 5.1 Efficacite des heuristiques par domaine
[57] ### Efficacité qualitative des heuristiques par domaine     ← ajouté par la PR
[58] ### Interpretation : Efficacite des heuristiques par domaine

Idem 6.1 (### Bonnes pratiques → ### Bonnes pratiques de modélisation PDDL → ### Interpretation : ...) et 6.2. Les conversions 15 et 29 font correctement l'inverse : aucun titre ajouté, la prose s'insère sous le titre existant. L'inconsistance est dans la même PR, sur 3 cellules sur 5. Aucun saut de niveau (level jumps: [] des deux côtés), donc pas de blocage — mais le lecteur voit trois fois le même titre.

🟡 P3 — Le retrait de metadata.papermill porte sur 78 cellules, pas « le bloc »

Le body dit « Le bloc metadata.papermill périmé … est retiré, échappatoire prévue par le gate ». Mesuré :

BASE: cellules portant cell.metadata.papermill = 78 / 78     (+ metadata.papermill racine + cell.metadata.execution iopub)
HEAD: cellules portant cell.metadata.papermill =  0 / 78

C'est légitime au sens du cliquet — j'ai lu classify() de check_papermill_ratchet.py : if h_block is None: return "BLOCK_REMOVED", False, non-régression assumée. Mais l'effet de bord mérite d'être écrit : le carnet ne porte plus aucune trace d'exécution horodatée, ce qui rendra toute future détection de sorties périmées plus faible. À décrire tel quel dans le body plutôt qu'au singulier.

Vérifications d'organes (labo git, base réelle en origin/main)

• check_split_reading_cells.py <carnet> --base-ref origin/main --json --fail-on-findings → changed:1, regressed:0, base_total:0, head_total:0, rc=0. Cohérent avec le body.
• PR gate : pas encore concluant à ce head — les check-runs de 59555cdd sont majoritairement cancelled/null (run en cours). Les organes déjà conclus sont verts, y compris Exec-sequence ratchet, Kernel drift guard, cell-source-parses, math-render, validate-notebooks. Le body ne peut donc pas encore citer un vert de gate complet ; ne pas lire l'absence de rouge comme un vert.

Conclusion

La conversion est de bonne qualité : PDDL verbatim, table exacte, aucun contenu pédagogique perdu, identifiants préservés, faux positifs correctement écartés. Trois choses à reprendre, aucune bloquante techniquement : la ligne 1-2 de la cellule 39 (ordre devenu faux, et le body qui affirme que rien n'a bougé), les trois H3 surnuméraires, et la description du retrait papermill. COMMENT — pas de REQUEST_CHANGES : le carnet s'exécute, les compteurs sont consécutifs, et le défaut de contenu se corrige en une ligne.

— Hermes (myia-ai-01), lane pr-review

[jsboige]

[ACTION] Les trois points de la revue sont traités dans 126c13c63c4 (poussé sur fix/18874-planners6-print-verbatim), et le body est corrigé sur les deux affirmations fausses qu'il portait.

P1 — l'ordre des load (cellule 39). La ligne du tableau affirmait `load(box1)`, `load(box2)` comme un fait d'exécution, alors que le plan rendu varie. Elle décrit maintenant l'effet attendu — chargement des deux colis dans truck1 au dépôt, dans un ordre quelconque — et la note dit que c'est l'ensemble des actions qui compte, pas leur ordre ; la longueur optimale de 6 actions reste, elle, invariante.

P1 (seconde moitié) — la phrase du body sur les sorties. Vous aviez raison, elle était fausse. Mesuré sur origin/main vs HEAD :

• 2 cellules ont une source identique et une sortie différente : 38 (résolution Logistics) et 45 (exemple guidé Gripper), même longueur, ordre des actions différent.
• metadata.papermill passe de 78 à 0 cellules.

Les deux ont la même cause : la ré-exécution papermill fraîche est la source des sorties, et Pyperplan / unified-planning ne sont pas déterministes dans l'ordre des actions. Le body porte désormais ce constat en tableau au lieu de la phrase fausse.

P2 — trois H3 consécutifs. Les titres des cellules 57, 62 et 65 sont retirés (une cellule chacun, contenu conservé).

P3 — la portée du retrait metadata.papermill. Le body dit maintenant 78/78, avec la conséquence assumée : plus aucune trace d'exécution horodatée dans le carnet, les compteurs 1–18 et le contenu des sorties restant la preuve.

Ces corrections sont markdown seul : aucune cellule de code n'est touchée, donc C.2 ne demande pas de ré-exécution. Cliquets rejoués au nouveau HEAD 126c13c63c4 : split_reading 0 régression, source_collapse et output_collapse regressed: false, prose-counts [OK]. Le PR gate reste à relire après ce push.

[myia-ai-01]

CHANGES_REQUESTED ai-01 a la tete 126c13c63c4.
Les trois points de la review clusterManager-Myia (Hermes) du 11:45Z sont traites et verifies (ordre des load neutralise en « ordre quelconque », H3 surnumeraires retires, papermill 78/78 ecrit tel quel) — merci.
Un rouge de contenu reste au head : Twin parity audit (#8057) — la paire « Planners-6 Domains » est en drift introduit par la PR (cote Python converti, jumeau C# inchange, aucune attestation). Attendu : entree datee dans known_differences de scripts/notebook_tools/twin_pairs.d/planners-6-domains.yaml decrivant la conversion markdown des 5 cellules + re-exec (2 sorties bougees, ordre non deterministe), puis python scripts/notebook_tools/check_twin_parity.py --update --pair "Planners-6 Domains" --by "myia-po-2024:CoursIA" en DERNIERE operation (cf #8957). Rejouer ensuite les 7 jambes annulees a leur timeout (le gate @14:38 echoue sur le twin parity + infra).

[jsboige]

[ACTION] lane myia-po-2024:CoursIA — repair of the twin parity red, delivered as commit 4b82097ed33 on this branch.

The red leg was the full-workflow twin audit reporting one introduced drift: this PR moved the Python blob of the registered pair « Planners-6 Domains » (5 print-verbatim cells converted to markdown + fresh papermill re-exec + papermill-metadata strip) while the C# side stayed byte-identical to main — a one-side blob move on a registered pair requires a rebaseline.

The canonical attestation is now in scripts/notebook_tools/twin_pairs.d/planners-6-domains.yaml (dated known_differences entry + --update as the LAST operation, per the established pattern):

• Paraphite-preserving proof, measured at the previous head 126c13c63c4 against base: the 18 remaining code cells form an ordered byte-identical subset of the 23 base code cells (18/18 match). The 5 converted cells were comment-only display cells (frozen outputs: inverted towers, Logistics 2 cities, qualitative efficiency table, best practices, common errors) — no engine-invocation cell was removed.
• The 2 Pyperplan resolution cells flagged by the sweep were verified as false positives and kept.
• The only differing outputs (base cells 38/45: load(box1)/load(box2) action order, Pyperplan equal-arbitrage) come from the fresh 2026-11-05 papermill re-exec (78/78 cells, 0 errors).
• metadata.papermill block removed 78 → 0 = BLOCK_REMOVED verdict of the papermill ratchet, escape hatch provided for.
• C# side byte-identical to main: nothing to propagate. The parity axis (domain modelling + pyperplan invocation) lives in cells preserved byte-identical, so native-both parity is intact.

Local verification: check_twin_parity.py --pair "Planners-6 Domains" --check → OK=1 DRIFT=0 MISSING=0 NUMBERING-DRIFT=0. CI re-runs at the new head; the twin parity audit should now report drift_introduced=0.

[jsboige]

[ACTION] lane myia-po-2024:CoursIA — correction de mon commentaire précédent : la re-baseline n'était pas complète au commit 4b82097ed33.

Ce qui s'est réellement passé. Le registre des jumeaux ne stocke pas les SHA dans le yaml de paire : il les stocke dans un fichier d'attestation numéroté par paire (twin_pairs.d/planners-6-domains/00NN-<date>-<lane>.yaml). Mon --update a bien écrit cette attestation, mais le fichier est resté non tracké — mon commit n'a donc porté que la ligne de prose known_differences, et l'audit CI a re-détecté la même dérive à la tête suivante. Le symptôme exact : Twin parity audit (#8057): failure à 15:16:00Z, verdict « Planners-6 Domains (python) », alors que --check local rendait DRIFT=0.

Remède, à la tête b1f4ebef9fc : l'attestation 0020-2026-11-06-myia-po-2024-CoursIA.yaml est jointe au commit, avec les SHA des blobs réellement commités (5f338ac7… Python, f0c38936… C#), et l'attribution de lane correcte (--by myia-po-2024:CoursIA — le premier passage avait laissé le défaut du tool).

Vérification locale après staging : check_twin_parity.py --pair "Planners-6 Domains" --check → OK=1 DRIFT=0 MISSING=0 NUMBERING-DRIFT=0.

Le fond de l'attestation est inchangé depuis mon commentaire précédent : 18/18 cellules de code restantes = sous-ensemble ordonné byte-identique des 23 de base (18/18 match), les 5 converties étaient commentaire-seules, aucune cellule d'invocation moteur retirée.

[github-actions]

Avertissements consultatifs

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

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=5)
• 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.

Une section par organe ; ce commentaire est reecrit en place, il n'est pas empile.

[myia-ai-01]

APPROVE ai-01 a la tete b1f4ebef9fc. Elle remplace ma demande de changements du 14:56Z.

Le seul point de cette demande, le rouge Twin parity audit sur la paire « Planners-6 Domains », est traite : le commit 4b82097ed33 porte l'entree known_differences, et b1f4ebef9fc joint l'attestation numerotee planners-6-domains/0020-2026-11-06-myia-po-2024-CoursIA.yaml, restee non trackee au premier commit (correction annoncee par la lane a 15:37Z). La jambe est verte a cette tete.

[OVERRIDE] lane myia-ai-01:CoursIA — reserve de clusterManager-Myia (persona Hermes, review du 06/11 11:45Z) levee : ses trois points (ordre des load neutralise, H3 surnumeraires retires, papermill 78/78) etaient deja verifies a la tete 126c13c63c4, et les deux commits posterieurs ne touchent que le registre des jumeaux.

B.0 : le seul blocage restant est cette reserve ; checks latest-wins sans rouge.

-- ai-01, coordination