Repository navigation
Conversation
…e sur le referentiel canonique + bootstrap idempotent La cellule [11] de `Argument_Analysis_Agentic-0-init_agent.ipynb` cherchait le JDK portable et les JARs Tweety aux emplacements d'AVANT #1437 (Phase 1, EPIC #1396) : `libs/`, `SymbolicAI/libs`, `../libs`, `Argument_Analysis/jdk-17-portable`. Tous sont vides ou inexistants depuis que les JARs (857 Mo) ont ete de-suivis et deplaces vers le referentiel partage -- d'ou `Aucun JAR Tweety trouve` puis `Classpath Tweety vide` et une JVM non demarree. Trois changements dans CETTE cellule, meme fichier : 1. localisation via la shim du depot (`argumentation_lib._paths.SYMBOLIC_AI_DIR`, resolution __file__-relative donc insensible au cwd du lanceur) -- la convention de la famille, qui interdit le walk manuel ; les anciens chemins restent en repli, donc aucune regression ; 2. bootstrap idempotent des JARs quand le classpath est vide : appel de l'outil canonique de la serie Tweety (`download_tweety_tools.py --jars --lib-dir`) plutot qu'un telechargement reimplemente -- un clone neuf n'a aucun JAR ; 3. conformite C.1 : le `raise Exception("Classpath Tweety vide")` devient un degrade journalise, comme l'exige la note explicite de `-0-init.ipynb` (« aucun guard de path ni raise dans la cellule »). Version alignee sur 1.30, defaut de `--lib-dir/--version` de l'outil canonique : cela tranche le « 1.28 vs 1.30 » laisse ouvert par l'issue, dont la forme concrete sur disque est une duplication 1.29/1.30 dans le referentiel local (77 JARs = les 42 du jeu 1.30 + 35 residus 1.29), signalee et non nettoyee. Preuves (meme machine, memes artefacts, outil du depot) : - controle ROUGE sur la version HEAD : reproduit exactement le symptome de l'issue, JDK introuvable ET classpath vide -> « JVM/Tweety NON OPERATIONNELS » ; - VERRE cas nominal : JDK Zulu 17 trouve, classpath 77 JARs, Java 17.0.11, 4/4 classes critiques, « JVM + Tweety OPERATIONNELS » ; - VERRE cas clone neuf : referentiel deplace hors de son chemin pour forcer la branche de bootstrap -> telechargement des 42 JARs 1.30 en ~60 s, puis classpath construit et « JVM + Tweety OPERATIONNELS » ; les 42 sont un sous-ensemble strict des 77 (verifie nom a nom, 0 absent) ; - execution complete : 11/11 cellules code avec execution_count non nul, 0 erreur, notebook committe AVEC ses sorties (C.2/H.3) -- celles du run post-bootstrap (42 JARs), etat reproductible par un clone neuf. Dans le SOURCE, seule la cellule 11 change ; le diff embarque aussi le rafraichissement des sorties de toutes les cellules, consequence exigee par C.2 d'une re-execution complete. Catalogue, baseline et README non touches. Collision a sequencer (ai-01) : #16247 (F4) et #16269 (titres, lot 1) touchent deja ce meme notebook ; les apports ne se recouvrent pas (code de cellule 11 vs noms de modeles et titres), mais l'ordre de merge n'est pas le mien. Residu assume : les notebooks soeurs (-1..-5) n'ont pas ete re-executes (aucun ne reference les anciens chemins, mais la verification par execution n'a porte que sur le notebook de l'issue) -- d'ou `See` et non `Closes`. La duplication de fond (la cellule embarque son propre amorcage JVM alors que la shim expose `initialize_jvm()`) est un grain separe. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
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 |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
|
aucun genre mots-clé fermant dans le body ni les commits ; prev: accepté(s) : #16273 Run vert du garde : ce commentaire bloquant est obsolète. Réécrit en place (#15372) plutôt que laissé affiché faux — le marqueur reste porté pour le prochain upsert. Historique : runs |
Golden-Set Execution (H.7 P3)✅ 8/8 notebooks passed (certified reproducible)
Pinned lockfile: |
…[11] + re-execution avec l'env LLM attendu
Deux regressions remontees par la CI sur la premiere revision de cette PR, toutes
deux corrigees a la CAUSE puis re-executees (jamais retouchees dans la sortie).
1. `Output-failure ratchet` : MACHINE_PATH 0 -> 4.
`find_portable_jdk` et `get_tweety_classpath` journalisent l'absolu depuis
toujours (`{jdk_dir.absolute()}`, `{libs_path}`, `{portable_jdk}`). Ces lignes
etaient INATTEIGNABLES tant que la cellule ne trouvait ni JDK ni JARs : en les
faisant enfin trouver, ce correctif les a activees. La sortie committeas sur
main portait `<repo>` a cet endroit -- une retouche anterieure du texte de
sortie. On ne reproduit pas ce contournement : on arrete l'emission. Un helper
`display_path()` rend desormais chaque chemin relatif a la racine du depot,
donc il n'y a plus rien a nettoyer apres coup, et la sortie se regenere juste
au run suivant (la retouche de sortie, elle, serait a refaire chaque fois --
le treadmill que le hook pre-commit decrit lui-meme).
2. `Output-failure ratchet` : TOOL_FAILURE 0 -> 1 (cellule [19], service LLM
`non disponible`).
La cellule [7] derive `use_azure_openai = bool(OPENAI_ENDPOINT)`. Le lanceur
de verification fabriquait un `OPENAI_ENDPOINT` a partir de `OPENAI_BASE_URL` :
la branche Azure s'activait, et comme ce poste n'a pas de
`chat_deployment_name`, le service restait `None` -> sortie degradee. Le
lanceur ne fabrique plus cet endpoint et fournit le `OPENAI_CHAT_MODEL_ID`
par defaut documente (`docs/archive/NOTEBOOK_ENV_COVERAGE.md`). La cellule
retrouve la configuration de main : `Service LLM global OpenAI (gpt-5-mini) créé`.
Re-execution dans l'etat d'un CLONE NEUF, qui est celui que l'etudiant obtient et
celui qui exerce la branche de bootstrap ajoutee : referentiel local mis de cote
(77 JARs preserves, restaures et recomptes apres le run), 42 JARs 1.30
telecharges, JVM demarree, 4/4 classes critiques.
Preuves : `check_output_failure_text origin/main` -> **0 regressed** (etait
1 notebook / 1 regressed) ; 11/11 cellules code, 0 erreur ; `check_exec_sequence`
0 dans les 4 buckets ; `detect_notebook_plan_loss` findings=0 ;
`scan_md_table_syntax --check` 0 defaut ; `cell_order_ci` RC=0.
Dans le SOURCE, seule la cellule 11 change toujours (verifie cellule par cellule
contre origin/main).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Cycle c.1176 worker confirme PR ripe-merge-clean CLEAN débloquée via Tell NEW c.1175-L1 ★★ fondateur ( |
github-actions
Bot
added
the
large-pr-no-review
|
Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine. Le label Le label sera retire des qu'une review arrive (ou que le diff passe sous le seuil). Fermer/rouvrir la PR ne suffit pas -- la mesure porte sur le diff, pas sur l'etat de la PR. Seuil, historique et exceptions : cf. |
Path-collision (organ #13359/#13615)Cette PR #16277 (
|
github-actions
Bot
added
the
pr-overlap
|
Fermée comme supplantée par #16726 (leçon [conflicting-pr-superseded-sibling]). Cette PR du 2026-09-15 portait le même travail #16264 (classpath Tweety → référentiel canonique + bootstrap idempotent) sur la branche #16726 est la livraison canonique — rien ne merge ici. Fermée par sa propre lane pour éviter le double-merge. — lane myia-po-2023:CoursIA 2026-09-18T22:3xZ |
1 participant
Contexte
#16264 — Phase 2 de l'EPIC #1396.
Argument_Analysis_Agentic-0-init_agent.ipynb(cellule [11], « Configuration Java Auto-Suffisante ») cherche le JDK portable et les JARs Tweety à des emplacements qui n'existent plus depuis le commitd6932b1396(#1437, Phase 1) :Cause racine, mesurée
libs/(relatif au cwd)native/MyIA.AI.Notebooks/SymbolicAI/libsnative/../libsArgument_Analysis/jdk-17-portable#1437 (Phase 1) a dé-suivi les 71 JARs (857 Mo) et le référentiel partagé vit désormais ailleurs. Deux emplacements canoniques coexistaient sans que la cellule en connaisse aucun :
MyIA.AI.Notebooks/SymbolicAI/Tweety/libs— défaut du flag--lib-dirdedownload_tweety_tools.py, et seule cible que l'outil alimente ;MyIA.AI.Notebooks/SymbolicAI/Tweety/jdk-17-portable— défaut de--jdk.La famille le savait déjà :
Argument_Analysis_Agentic-0-init.ipynbrésoutSYMBOLIC_AI_DIR / "Tweety"via la shimargumentation_lib._paths, etArgument_Analysis_Agentic-2-formal.ipynbdocumente ce chemin comme « canonique ». Seul le notebook_agent(génération « Option B », antérieure à la shim) était resté sur l'ancien layout.Livrable — 3 changements dans la cellule [11], un seul fichier
SYMBOLIC_AI_DIRdeargumentation_lib._paths([EPIC] Argument_Analysis v3 — submodule Argumentum (prémerge v0.9.0) + remontées moteur (CsvDiff/DatasetUpdater/Owl) + landing essence multidimensionnelle EPITA-IS #4960) — la convention de la famille, résolution__file__-relative donc insensible au cwd du lanceur (Jupyter,papermill --cwd, outil du dépôt). Aucun walk manuel n'est introduit : la shim l'interdit explicitement. Les anciens chemins restent en repli, donc aucune régression.download_tweety_tools.py --jars --lib-dir <Tweety/libs> --no-interactive) plutôt que de réimplémenter un téléchargement. Il ne s'exécute que sur classpath vide.raise Exception("Classpath Tweety vide…")devient un dégradé journalisé (la JVM n'est pas démarrée et le diagnostic final dit exactement ce qui manque). C'est ce qu'exige la note de-0-init.ipynb: « aucun guard de path ni raise dans la cellule (règle C.1) ». Le notebook s'exécute de bout en bout dans les deux cas.Validation — deux contrôles sur données réelles, même machine
Contrôle ROUGE (version
HEADdu notebook, mêmes artefacts, outil du dépôt) — reproduit le symptôme et la misère du JDK, qui vient du même mauvais chemin :Contrôle VERT, cas nominal (référentiel présent) :
Contrôle VERT, cas clone neuf (référentiel JARs déplacé hors de son chemin pour forcer la branche de bootstrap) — c'est le cas qui compte pour un nouveau clone, et il fallait le prouver plutôt que le supposer :
Exécution complète :
notebook_tools.py execute→Success: 1 / Failed: 0, 11/11 cellules code avecexecution_countnon nul, 0 erreur, notebook committé AVEC ses sorties (C.2/H.3). Les sorties committées sont celles du run post-bootstrap (42 JARs, soit l'état reproductible qu'un clone neuf obtient) — pas celles du run à 77, qui dépend d'un état local.Réparations après la CI (commit
505e0e2d58)La première révision a été rougie par
Output-failure ratchetsur deux points. Les deux sont corrigés à la cause, puis re-exécutés — aucune sortie n'a été retouchée (Stop & Repair).1.
MACHINE_PATH0 → 4 — la cellule journalisait l'absolu.find_portable_jdketget_tweety_classpathimpriment{jdk_dir.absolute()},{libs_path},{portable_jdk}depuis toujours. Ces lignes étaient inatteignables tant que la cellule ne trouvait ni JDK ni JARs : en les faisant enfin trouver, ce correctif les a activées. La sortie committée surmainportait<repo>à cet endroit — une retouche antérieure du texte de sortie. Je ne reproduis pas ce contournement : un helperdisplay_path()rend désormais chaque chemin relatif à la racine du dépôt, donc il n'y a plus rien à nettoyer après coup et la sortie se régénère juste au run suivant. La retouche de sortie, elle, serait à refaire à chaque exécution — le treadmill que le hook pre-commit décrit lui-même dans son commentaire.2.
TOOL_FAILURE0 → 1 — cellule [19] en mode dégradé.La cellule [7] dérive
use_azure_openai = bool(OPENAI_ENDPOINT). Mon lanceur de vérification fabriquait unOPENAI_ENDPOINTà partir deOPENAI_BASE_URL: la branche Azure s'activait, et comme ce poste n'a pas dechat_deployment_name, le service restaitNone→Service LLM global non disponible. Le lanceur ne fabrique plus cet endpoint et fournit leOPENAI_CHAT_MODEL_IDpar défaut documenté (docs/archive/NOTEBOOK_ENV_COVERAGE.md,GenAI/.env.example). La cellule retrouve la configuration demain:Re-exécution dans l'état d'un clone neuf (le référentiel local de 77 JARs mis de côté puis restauré et recompté après le run, 42 JARs 1.30 re-téléchargés) — c'est l'état que l'étudiant obtient, et celui qui exerce la branche de bootstrap ajoutée par ce correctif. Preuve du résultat :
Chemins relatifs de bout en bout, aucune trace de la machine, aucune retouche. Ratchet : 0 regressed (contre 1 notebook / 1 regressed avant).
Chiffres exacts (les premiers étaient faux, corrigés après mesure)
Les sorties committées sur
mainaffichaient 41 JARs trouvés par un chemin hérité — dans un environnement qui n'existe plus. Sur cette machine, le référentiel partagé en contient 77 : les 42 du jeu 1.30 installé par l'outil + 35 JARs 1.29 résiduels. Les 42 téléchargés par le bootstrap sont un sous-ensemble strict des 77 (vérifié nom à nom : 0 absent). Autrement dit, la question « 1.28 vs 1.30 » laissée ouverte par l'issue a une forme concrète sur disque : une duplication 1.29/1.30 dans le référentiel local. Le correctif retient 1.30 (défaut de--version/--lib-dirde l'outil canonique, et version installée par lui) ; la présence des 1.29 est signalée, pas nettoyée — ce sont des artefacts locaux non suivis, hors du périmètre d'une PR de notebook.Périmètre et collision
Un fichier, et dans le source seule la cellule 11 change (vérifié cellule par cellule). Le diff embarque aussi le rafraîchissement des sorties de toutes les cellules : c'est la conséquence d'une ré-exécution complète, exigée par C.2/H.1 dès qu'une cellule code est modifiée. Aucun catalogue, baseline ni README touché.
Résidus
-1..-5) ne sont pas re-exécutés ici : je les ai cherchés (aucun ne référence les anciens chemins ;-2-formaldocumente déjà le résolveur canonique), mais la vérification par exécution n'a porté que sur le notebook de l'issue — d'oùSeeet nonCloses.argumentation_lib.initialize_jvm()(qui délègue àTweety/tweety_init.py). Converger le notebook_agentsur cette entrée canonique est un grain séparé — il change le cycle de vie JVM (chdirversTweety/, classpath 35+ modules) et mérite sa propre revue.execution_count/outputs, ce qui fait échouernbformat.validate(). Vérifié présent surHEAD, donc non introduit ici.Grain: DEEP/notebook-python — lane myia-po-2023:CoursIA — prev: DEEP/tooling #16273
See #16264
See #1396
🤖 Generated with Claude Code