Repository navigation
feat(lean,#11703): exposer le backbone topologique dans Lean-15c - #16945
Conversation
Co-Authored-By: Claude Code <noreply@anthropic.com>
…opological-backbone-v2
|
✅ No prose/output mismatch detected in the notebooks this PR changed. Scope = notebooks CHANGED in this PR, not the whole corpus. Explicit |
Notebook PR Validation: PASS
Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns) |
Golden-Set Execution (H.7 P3)✅ 8/8 notebooks passed (certified reproducible)
Pinned lockfile: |
Notebook outputs-required (H.4 schema): PASS (every code cell carries an
|
clusterManager-Myia
left a comment
There was a problem hiding this comment.
VERDICT: LGTM (vérifié: multiset 0 perte 14/14 qualifiées, sorry code 0, simplification import vérifiée contre l'agrégateur sur main, ancrages #check localisés, CI gardes verts)
[NanoClaw] structural review — feat(lean,#11703): backbone topologique dans Lean (head 480364cb, +1191/−580, 1 notebook, lane po-2025:CoursIA). Review notebook-lean : multiset SHA-256 base↔head + protocole Lean.
Vérifié sur le blob au head :
- Multiset 34→39 : 0 perte de contenu. Les 14 « perdues » se qualifient une à une : 13 additions-only (source préfixe conservé ou étendu, 0 retrait — diffs de hash = outputs re-exec, attendu pour une passe Papermill complète) + 1 = la simplification d'import déclarée (cellule 2 : 4 imports redondants + commentaire périmé retirés, remplacés par
import Grothendieckseul). 5 cellules réellement neuves : annexe complète (md + code + lecture + exercice ×2). - La simplification d'import est correcte : vérifié sur
main(non modifié par la PR) — la zone d'imports deGrothendieck.leanré-exporte bien les huit modules dontStalks,StalkPoints,StalkSeparated,StalkGluing,Skyscraper,SpacesMathlib,SpacesSubcanonical,StalkCharacterization. Le commentaire base (« le cluster tiges n'est pas entièrement ré-exporté ») était bien périmé. - sorry : 0 en cellule code (2 occurrences en prose markdown pédagogique seulement) — corroboré par votre
count_code_sorry=0. Axiom hors#print: 0. Les 4 modules cités (SpacesMathlib…Skyscraper) présents au head. 39/39 cellules avecid(contrairement à la classe récente #16908/#16922/#16929 — rien ici). Exec 1-16 consécutifs. 0 secret. - #check recount (discipline P5) : code-only 109→125 = +16, dont 15 dans la cellule annexe neuve (head[34], exactement les 15 annoncées) + 1 dans la cellule exercice — le compte « 15 » du body est exact pour l'annexe, le 16ᵉ appartient au livrable exercice. Précision sans conséquence.
Réserves (non bloquantes) :
- Aucun gate Lean ne se déclenche sur une PR notebook-only :
lean-grothendieck.yml(dispatcher dédié — le lake est BIEN câblé pour les sources, contrairement au cas #16942) déclenche surgrothendieck_lean/**.lean/lakefile/manifest, pas sur les notebooks ;ci_lakes.jsonne contient pas grothendieck (cohérent : il a son dispatcher). Les gardes verts au head sont metadata/rendering/leak — la validation Lean du notebook repose sur votre run local (honnêtement documentée). Classe connue (#16942 c) : à verser au dossier harnais si la lane veut un advisory d'exécution notebook-Lean en CI. - Les mesures scanner (14/77→10/77 noirs, 150→165 citées) ne sont pas re-mesurables depuis mon siège — prises sur votre artefact local, cohérentes avec les deltas de contenu observés.
— [NanoClaw] (clusterManager-Myia, slot :45)
|
[ADJOINT PREFLIGHT] schema: 1 Verification detail (third-party lane, all firsthand at head 480364c):
|
|
[ADJOINT PREFLIGHT] |
|
[ADJOINT PREFLIGHT] |
Grain: DEEP/notebook-lean — lane myia-po-2025:CoursIA — prev: DEEP/notebook-python #16900
Résumé
SpacesMathlib→SpacesSubcanonical→StalkCharacterization→Skyscraper;#check, qui rendent 15 déclarations supplémentaires visibles selon le scanner canonique après exécution, dont trois pivots contrôlés par#print axioms;See #11703 — sous-grain borné de l’EPIC ; cette PR ne clôt pas l’inventaire.
Périmètre
Un seul livrable est modifié :
MyIA.AI.Notebooks/SymbolicAI/Lean/Lean-15c-Lean-Grothendieck-Companion.ipynbAucun source
.lean, catalogue généré ou registre de traduction n’est modifié. La cellule d’import est simplifiée vers l’agrégateur canoniqueimport Grothendieck: sur le head courant,Grothendieck.lean:81-91réexporte bien les huit modules nécessaires, y comprisStalksetStalkPoints. Le commentaire historique était devenu périmé après l’ajout des imports FR manquants par #16068 (e50689b9f), puis les extensions #16066/#16623. Les veines concurrentesGrothendieck.lean(#16228) etCoversEtaleArrow.leanrestent hors périmètre.Effet mesuré
Mesure
scan_lake_notebook_visibility.py --lake grothendieck_leansur la base fraîche puis sur le livrable :origin/mainLes quatre modules ciblés sortent du noir :
SpacesMathlib,SpacesSubcanonical,StalkCharacterizationetSkyscraper.Validation réelle
lake build Grothendieck(agrégateur réellement importé par le notebook) : SUCCESS, 4632 jobs ;lake env lean 11703-probe.lean: SUCCESS, les six signatures sondées sont résolues et les trois#print axiomsrendent uniquementpropext,Classical.choice,Quot.sound;~/coursia-wsl, kernellean4-wslrésolu vers/home/jesse/.lean4-venv/bin/python3, cwd du lake : SUCCESS en 236,7 s ;output_type=error: 0 ; diagnostics Leanseverity=error: 0) ;python scripts/lean/count_code_sorry.py --json:distinct_code_sorry = 0, aucun théorème vacuous signalé ;scan_cell_ordering.py --fail-on HIGH: 1 notebook propre, 0 finding ;detect_stub_truth_returns.py --json:[];raise NotImplementedError,assert False,1/0) : 0 occurrence ;test_validate_lean_actual_notebook.py: 2 tests réussis.Intégrité des preuves (B.3)
Le workflow
lean-grothendieck.ymlporte bien un gate exhaustif (target-modules: "*",fail-on-sorry: true), mais son filtrepull_request.pathsne couvre pas les notebooks. B.3 est donc non applicable au check-run de cette PR notebook-only. Le livrable compense au niveau pédagogique par trois#print axiomsexécutés sur les résultats pivots ; leurs sorties excluentsorryAxetnative_decideet ne rendent quepropext,Classical.choice,Quot.sound.Diagnostic d’exécution
L’environnement sépare correctement le driver et le kernel : Papermill 2.7.0 tourne depuis
~/coursia-wsl, tandis que la kernelspeclean4-wsllance explicitement/home/jesse/.lean4-venv/bin/python3 -m lean4_jupyter. Une tentative concurrente a rencontré un processus Git pendant le build du lake (external command 'git' exited with code 128). Le diagnostic décisif a ensuite reproduit un comportement trompeur delean4_jupyter:import Grothendieckrendait seulement{\"env\": 0}alors queGrothendieck.oleanmanquait, puis cet environnement vide faisait échouer jusqu’aux noms core (Nat,String). Un probe exact parlake env leana nommé l’objet manquant. Le build ciblé des quatre nouveaux modules, pourtant vert, ne construisait pas l’agrégateur réellement importé ; la réparation correcte est donclake build Grothendieck, suivie du probe exact puis d’une réexécution intégrale. Aucun échec n’est consacré dans les outputs livrés et aucune sortie n’est éditée à la main.Justification du ratchet de sortie
Le ratchet advisory
check_output_collapse.pysignale unMAGNITUDEsur la cellule d’import0a19158f: 1 418 → 95 caractères. Cette contraction est intentionnelle et ne retire aucun résultat pédagogique : les neuf accusés d’import explicites sont remplacés par l’unique agrégateur canoniqueimport Grothendieck. Le contrôle positif est double : les 15 déclarations de l’annexe sont toutes résolues après cette cellule, et le volume total des sorties du notebook augmente de 107 169 → 122 119 caractères. Il ne s’agit donc ni d’une exécution dégradée ni d’une perte silencieuse de calcul.SOTA
SOTA-OK — les signatures et dépendances axiomatiques proviennent du lake Lean réel, chargé par
lean4-wsl; aucune sortie de substitution ou sortie éditée à la main.Préservation
La branche intègre
origin/mainau commitd319c41d3avant publication et conserve le correctif #16656 (05c28ebd0) qui a retiré les nombres dérivés de la prose de Lean-15c.🤖 Generated with Claude Code