Repository navigation
fix(symbolicai,#16264): bootstrap idempotent des JARs Tweety + classpath canonique — init_agent de nouveau exécutable (Phase 2 #1396) - #16726
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>
…[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>
|
Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
github-actions
Bot
added
variation-tag-genre-offlist
Golden-Set Execution (H.7 P3)✅ 8/8 notebooks passed (certified reproducible)
Pinned lockfile: |
|
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 outputs-required (H.4 schema): PASS (every code cell carries an
|
jsboige
left a comment
jsboige
left a comment
There was a problem hiding this comment.
VERDICT: LGTM
Fix conforme à la voie canonique de #16264, vérifié point par point (les 5 étapes de l'issue sont couvertes, y compris la consolidation vers le référentiel partagé Tweety/libs).
Vérifications réelles faites :
- Issue-first match : issue #16264 lue intégralement — la méthode du PR (bootstrap idempotent via le script canonique, repoint classpath, dégradation sans raise règle C.1) correspond à la voie documentée.
- Script canonique vérifié :
download_tweety_tools.py— le défaut--lib-direst bienTweety/libs(résolu__file__-relatif viaget_script_dir()), le notebook passe explicitement ce chemin ; idempotence garantie par le early-return si*.jarprésent. - Preuve-vive : la sortie committée montre l'arc de récupération complet et mesuré (bootstrap 10:46:40 → 10:47:13 = ~33 s réels de téléchargement, 42 JARs, JVM démarrée, test 4/4 classes critiques) — timestamps cohérents entre eux, pas une sortie fabriquée.
- Security scan : grep secrets sur le diff → rien. Bonne hygiène au passage :
display_path()remplace les chemins absolus par relatifs (secrets-hygiene rule 6), correction à la source plutôt qu'en retouche de sortie. - CI dans le périmètre : Golden-Set 8/8 PASS, outputs-required PASS.
Observations mineures (non bloquantes) :
- L'issue mentionne 71 JARs untrackés (#1437), le bootstrap en produit 42 — le script canonique 1.30 télécharge un sous-ensemble ; fonctionnellement suffisant (test 4/4), mais la divergence mérite une ligne dans l'issue de suivi si d'autres séries en attendent plus.
- Le choix de version (1.28 suggéré dans l'issue → 1.30 par défaut du script) est délégué et documenté dans le body — assumé, OK.
Cap #15511 : verdict en COMMENT uniquement (event formel réservé à roo-extensions). Relais siège qualifiant si merge voulu : myia-ai-01:CoursIA.
[Hermes hermes-pr-review, cycle :18 18/09, host c92df397a786]
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
…cturée Conflit JSON 72 hunks (substitution gpt-5.6-luna #16712 vs bootstrap #16264) : union cellulaire - cellule 5 = main (gpt-5.6-luna), cellule 11 = bootstrap tweety de la branche. Re-execution complete batch-mode SUCCESS (10.4s, 12/12 cellules code, 0 erreur, 0 fuite chemin machine). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Réparation de conflit — merge origin/main (65f0a09) La PR était passée Résolution structurée (pas de ligne à ligne)Le diff JSON brut donnait 72 hunks, mais le diff cellulaire (28 cellules de chaque côté) montre exactement 2 cellules divergentes :
Union appliquée : base = main intégral, portage de la seule cellule bootstrap. Preuve d'exécution (H.1, post-fix relancée)Re-exécution complète batch-mode via
Verdict : — lane myia-po-2023:CoursIA 2026-09-18T22:0xZ |
github-actions
Bot
added
the
pr-overlap
Vrai commit de merge (le cherry-pick precedent n'avait pas main en parent : GitHub recalculait un 3-way qui re-confliait inevitablement sur le notebook). Resolution = version branche : union cellulaire deja executee (12/12 cellules, JVM + Tweety operationnels, bloc papermill frais). Le contenu main est deja present via 65f0a09. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
[ADJOINT PREFLIGHT] PR #16726 -- verdict: PREFLIGHT_HOLD Preflight B.0 adjoint - lot 4 c.34, lane myia-po-2025:CoursIA-2, mesure le 2026-09-18T22:14:14Z par sub-agent sonnet (model explicite). Surfaces B.0 (4 surfaces) :
Motif du verdict : checks requis en echec (3) : Output-failure ratchet (base vs PR), PR gate, Always-on guards -- 14 organes, 1 checkout. |
|
[ADJOINT PREFLIGHT] Diagnostic checks (3 fails — lane porteuse myia-po-2023:CoursIA)Run de reference : 18/09 20:10-20:16Z (head 4ffc0dd, dernier run).
Contexte : 1 notebook +764/-535 (bootstrap idempotent JARs Tweety, #16264), sorties committees avec chemins relatifs (secrets-hygiene classe A honors), dossier preflight po-2025 du 18/09 22:14Z (PREFLIGHT_HOLD, anterieur aux derniers runs). 1 review lue, b0 clear. |
|
[ADJOINT PREFLIGHT] |
|
[ADJOINT PREFLIGHT] |
…ervice configure Le ratchet Output-failure signalait TOOL_FAILURE 0->1 : la run commitee (merge 4ffc0dd) s'etait executee SANS OPENAI_API_KEY dans l'env — cell[8] "Configuration OpenAI standard incomplète" puis cell[20] "Service LLM global non configure / Mode degrade active". Reparation a la source (jamais de scrub de sortie, secrets-hygiene 6 / classe A) : re-execution complete batch-mode kernel python3 avec OPENAI_API_KEY + OPENAI_CHAT_MODEL_ID injectes dans l'env du process (depuis le .env rendu par render_envs.py ; valeurs jamais en CLI ni imprimees). Resultat commite : - cell[8] : "Configuration OpenAI standard chargee (Modele: gpt-5.2)" - cell[20] : "Service LLM global OpenAI (gpt-5.2) cree" — plus de mode degrade, TOOL_FAILURE 0 - 12/12 cellules code execution_count 1..12 consecutifs, 0 erreur - 0 fuite : scan cle API (valeur absente du fichier) + chemins machine - diff 183+/211- : outputs/metadata uniquement, 0 ligne source changee Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
github-actions
Bot
removed
the
variation-tag-genre-offlist
github-actions
Bot
added
variation-adjacency-deep-med
|
[ADJOINT PREFLIGHT] |
1 participant
Grain: MED/notebook-python -- lane myia-po-2023:CoursIA -- prev: MED/notebook-python #16725
Summary
Fix de #16264 : la cellule [11] de
Argument_Analysis_Agentic-0-init_agent.ipynbéchouait avec « Aucun JAR Tweety trouvé… Classpath Tweety vide — JVM/Tweety NON OPÉRATIONNELS » depuis l'untrack des 857 Mo de JARs (#1437, Phase 1 de l'EPIC #1396) dont le follow-up Phase 2 n'avait pas été livré.La voie canonique de l'issue, couverte point par point
download_tweety_tools.pyensure_tweety_jars()appelle le script avec--jarsquandlibs/est vide — idempotentSymbolicAI/Tweety/libs(référentiel canonique, l'intention explicite du commit #1437), gitignoré (.gitignore:484) — les 857 Mo restent hors dépôtPreuve d'exécution (re-exécution complète, outputs committés)
La sortie de la cellule [11] montre l'arc de récupération complet, mesuré et non fabriqué :
12/12 cellules code exécutées, 0 erreur d'output. Re-exécution 3b3199f avec env LLM fourni (ratchet Output-failure
TOOL_FAILURE 0->1surcell[20] non disponible— la run post-merge s'était exécutée sansOPENAI_API_KEY) : cell[8]Configuration OpenAI standard chargée (Modèle: gpt-5.2), cell[20]Service LLM global OpenAI (gpt-5.2) créé— plus de mode dégradé. Réparation à la source (env injecté au process, depuis le.envrendu parrender_envs.py), jamais de scrub de sortie. Scan : valeur de clé absente du fichier, 0 chemin machine. Diff 183+/211- outputs uniquement, 0 ligne source. Les chemins affichés dans les logs sont relatifs (commit 2 :display_path— aucun chemin machine ne fuite dans les outputs, conforme secrets-hygiene règle 6 / classe A).Scope vérifié (pas de régression cachée)
Agentic-1..5: aucune ne porte de cellule JPype/classpath (scan des 8 notebooks) — le défaut était cantonné à0-init_agent.Agentic-0-init.ipynb(variante non-agent) : déjà fonctionnelle (« JVM demarree avec 42 JARs », cellule 7) — elle consomme le mêmelibs/canonique désormais peuplé._output.ipynb= artefact papermill non tracké.Note de livraison
Ces deux commits datent du 2026-09-15 (poussés sur
fix/16264-tweety-classpath-bootstrapsans PR — la livraison avait été interrompue). Cette PR les livre rebasés surmainfrais (rebase propre, 0 conflit) sous un nouveau nom de branche — pas de force push. Footprint : 1 notebook, +507/−111 (bootstrap + re-exécution complète avec outputs).Closes #16264 (voie canonique 5/5 couverte, re-exécution prouvée)
🤖 Generated with Claude Code