
gonzalgo
io.github.zengineco由 GitHub 账号 zengineco 发布v0.5.2更新于 Oct 24, 2026
Reports what a checked Lean 4 or Metamath proof rests on: inherited sorry, compiler trust, axioms.
概览
审计 Lean 4 与 Metamath 证明所依赖的内容:继承的 sorry、编译器信任与公理,并以 MCP 工具形式提供分析。
- 可以做什么
- 审计 Lean 项目或 Metamath 数据库,找出依赖未完成证明或依赖编译执行结果而非内核的定理
- 追踪从定理到某条公理的最短路径,并标注每一步是陈述依赖还是证明依赖
- 衡量公理的波及范围、实际使用位置,以及理论上可去除的依赖比例
- 报告修改某个定义会波及哪些声明,并区分陈述依赖与证明依赖
- 从内置内核索引返回已知库的统计数字,并可从 Lean 项目生成转储文件
- 说明工具的能力边界,避免模型把它用于散文或不形式化的证明
- 适用场景
- 适合在需要确认 Lean 或 Metamath 证明是否真正完成时使用,例如证明能编译但可能在上游继承了 sorry 或 native_decide,或需要弄清某定理依赖哪条公理、由哪一步引入。
- 运行要求
- 以本地进程运行,可从 PyPI 通过 uvx 或 pip(含 MCP 附加包)安装,唯一依赖是 numpy。内核索引无需文件或网络即可使用;审计自己的项目需要 Lean 项目并先生成转储文件,Metamath 审计需要相应数据库文件。
安装
在 SourceWeft 中
- 打开 控制台中的 gonzalgo,将其添加到工作区。
- 为需要使用其工具的对话启用该服务。
Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。
其他 MCP 客户端
参照 仓库 中的启动说明。
README
[PyPI] [Python] [License] [DOI]
#print axioms tells you whether one theorem depends on an axiom. It cannot
tell you where an axiom is spent rather than inherited, how far that spending
reaches, how much of it could be avoided, or — for a given theorem — which step
introduced it. This does.
Works on Lean 4 / Mathlib and on Metamath databases (set.mm,
iset.mm, nf.mm), by one program, so two foundations are compared under
identical definitions rather than by analogy.
That runs the moment it's installed — no Lean, no build, no files. Everything below needs a Lean project.
Pure Python. macOS, Windows, Linux. numpy is the only dependency.
Questions this answers
How do I know if my Lean proof depends on a sorry?
Lean warns once, on the line you typed it. It does not warn you about the theorem
three files later that uses that lemma and is therefore not proved either. Run
gonzalgo trust and it reports every theorem that reaches a sorry anywhere
upstream, however far.
How do I find a sorry I inherited from a dependency?
Same command. The audit is over the whole environment, so a sorry in a library
you import is reported exactly like one in your own file.
Does my project use native_decide anywhere?
native_decide results are obtained by compiling and running code and believing
the answer — the compiler and runtime are trusted, not the kernel, and soundness
bugs have been found there. gonzalgo trust reports Lean.ofReduceBool and
Lean.ofReduceNat, the axioms it emits, and how many theorems inherit them.
What axioms does this Lean theorem actually depend on, and why?
#print axioms tells you whether. gonzalgo why <decl> -a <axiom> gives the
shortest path from the theorem to the axiom, labelling each step as a statement
dependency or a proof dependency — so you can see which step introduced it and
whether it is reroutable.
Can I fail CI when a proof rests on something unfinished?
Yes. --fail-on-trust, or the GitHub Action below.
If I change this definition, what breaks?
gonzalgo impact splits dependents into those that name it in a statement —
whose meaning changes with it — and those that only use it in a proof, which
merely rebuild.
kernel > sorry
What it found
Pointed at Lean 4.32.1 with Mathlib — 790,171 declarations, 30 million dependency edges — the funnel from "the whole library" down to "provably removable" runs like this:
That single tactic is omega, which supplies the Decidable arguments of
six helper lemmas as a hardcoded Classical.propDecidable and never attempts
instance synthesis — so proofs as elementary as a - b = 0 ↔ a ≤ b over Nat
rest on the axiom of choice with no need. Filed upstream; the fix is one file.
Let a language model call it
Add to your MCP client's configuration:
Ten tools: audit_trust, why, impact, axiom_reach, metamath_audit,
kernel_index, plus the plumbing to produce a dump from a project.
There's also a scope tool that reports what gonzalgo can't do — read a paper,
mark homework, judge whether text is any good. It's there so a model asked "is
this proof correct?" about a page of prose doesn't grab the nearest proof-shaped
tool and return something meaningless. Every other tool restates the
precondition in its description.
The case it's built for: a generated Lean proof that fails to compile is easy to
spot. One that compiles while resting on a sorry three lemmas upstream isn't,
and Lean only mentions it once, in a warning, at the site.
kernel_index runs with no files and no network, so a model can call it cold for
figures on known libraries.
Put it in CI, get a badge
Three lines in any Lean 4 project. Every commit is checked for theorems resting on an unfinished proof or on trusting the compiler rather than the kernel.
Then the badge, which is just the workflow's own status — no extra service:
What the badge actually certifies. Not that the proofs are correct — Lean
already checks that. That no theorem in the project is standing on a sorry
somewhere upstream, and that none of them were decided by compiling and running
code instead of by the kernel.
Lean warns about the sorry you just typed. It says nothing about the theorem
three files later that quietly inherits it. In the worked example under
examples/dirty, Lean reports one warning and the audit finds two
contaminated theorems.
How it fits together
Nothing above the kernel step is trusted on my say-so: Substitute.lean decides
substitutability with collectAxioms, and Rewrite.lean submits the rewritten
proof term to addDecl. A name-based screen was tried first and measured 41.5%
precision, which is why none of this reads names.
Quickstart
Generate a dump from your own Lean project, then ask questions of it.
Why does this theorem need choice?
Every hop is labelled stmt or proof, and that label is the point: a proof
edge can often be rerouted by changing a tactic, a statement edge cannot be
touched without changing what the theorem says. A path made only of proof edges
is what makes a declaration worth patching at all.
If I change this, what breaks?
why run backwards. The statement/proof split is the value: a declaration whose
type mentions the target has the target in its API, so its meaning moves when
the target moves and its own users may need rewriting. One that merely calls it
inside a proof needs nothing but a rebuild. A plain "who uses this" cannot tell
them apart, which is why it can't tell you whether a change is safe.
How far does an axiom reach, and where is it spent?
How much of that could even in principle be removed?
A theorem whose statement mentions something choice-dependent cannot be made choice-free however it is proved. Only the rest are candidates, and that figure is a ceiling, not an estimate.
Metamath, same measurements:
Kernel Trust Profile
gonzalgo profile writes what a library rests on as JSON, meant to be committed
and read by other programs:
Two rules do most of the work. An unmeasured field is null, never 0 —
Metamath has no native_decide, so its compiler_trusted count is
not-applicable rather than zero, and writing zero would be a claim nobody made.
And revision is refused on a dirty tree, because a profile whose commit
does not describe what was measured cannot be reproduced by anyone else.
There is no summary score, deliberately. A theorem either reaches an unfinished proof or it does not; averaging that against anything else invents precision the measurement does not have.
Full specification: Kernel Trust Profile 0.1 (Zenodo).
A sample is in examples/lean-core-kernel-trust.json.
Reach versus amplification
Under inlining and factoring — operations that change how a library is written, not what it proves — the set of dependents is invariant while the set of entry points is not. Rerouting every use of an axiom through one gateway lemma, or inlining that lemma, moves amplification anywhere between 1 and the number of dependents without changing a single theorem.
So reach bears comparison between libraries; amplification describes one library's factorisation. The tool reports both and this README says which is which, because the distinction is easy to lose and expensive to lose.
One hazard worth knowing about
In Lean 4.32, ConstantInfo.value? returns none for theorems unless
called as value? (allowOpaque := true), and this has changed across releases.
An extractor written the obvious way records no proof terms at all: every
theorem's value comes back empty, the analysis silently measures statements, and
reports them as proofs. Nothing about the output looks wrong — the library just
appears cleaner than it is.
gonzalgo check exists for this, and every subcommand runs it before trusting a
dump:
It raises rather than warns. A dump with no proof terms does not produce slightly worse numbers; it produces confidently wrong ones.
Library use
As a Lake package
This repository is also a Lean library, so the extractor can be a dependency
rather than a file you copy and edit. Add to your lakefile.toml:
Then no scratch file at all — it imports the target module at runtime:
Everything the module imports is included, and the fifth output column records which module each declaration came from, which is what separates your project from its dependencies afterwards.
If you would rather call it from inside a file, the library is two lines:
The library requires Lean only — no Mathlib dependency, deliberately, since pinning a Mathlib revision here would force one on every project being measured.
Run against Lean core and Std alone, that gives:
88,842 theorems, and 32 declarations spend Classical.choice where 31,516
inherit it.
Shipped Lean sources
gonzalgo lean-files writes these into a directory of your choosing. Prefer the
Lake package above for Split.lean's job; these are for the analyses that go
beyond extraction, and for projects not using Lake.
Substitute.lean decides substitutability with the kernel's own bookkeeping
rather than by name. A name-based screen measured 41.5% precision on set.mm;
its characteristic failure is a lemma that relocates choice into an antecedent
instead of discharging it, which looks like progress and is not.
Background
This package is the tooling behind Where Formal Libraries Spend Their Axioms:
A Cross-Foundation Measurement, and an Avoidable Classical Dependency in Lean's
omega — 10.5281/zenodo.21769846.
Applied to Lean 4.32.1 with Mathlib (790,171 declarations, 30M dependency
edges), it finds 280 declarations whose only route to Classical.choice runs
through a substitutable site, 276 of them attributable to a single cause in the
omega decision procedure. Rewriting all 280 proof terms and submitting them to
the kernel: 276 accepted, 4 rejected, 275 left free of Classical.choice.
Referenced by
- keithadler/tenet — an independent Lean 4
kernel checker in C#/.NET. Its
tenet whytraces which step introduced an axiom, the same question as gonzalgo'swhyfor Lean.
Who wrote this, and how to cite it
Vince Gonzalez — ORCID 0009-0005-3640-014X · f-keys.com/gonzalgo
Archived at Software Heritage as
swh:1:dir:871f62fca5b737da9b4f99516d3689d23ffbc60d, which resolves whether or
not this repository does. The qualified form, carrying the origin, visit and
anchor, is in codemeta.json.
Papers. Both CC-BY, both with archives that regenerate every figure from the shipped data with one command.
- Where Formal Libraries Spend Their Axioms — 10.5281/zenodo.21769846
- Why Tactic-Level Rates Cannot Attribute Classical Dependencies in Lean — 10.5281/zenodo.21853489
Licence
Apache-2.0. See LICENSE and NOTICE.
OmegaFix.lean is a modified copy of Lean 4's
src/Lean/Elab/Tactic/Omega/Frontend.lean, Copyright (c) 2023 Lean FRO, LLC,
used under Apache-2.0. Its modifications are listed in a notice at the top of
that file. It exists to demonstrate that a proposed fix compiles and produces
choice-free proofs; it is not a replacement for omega and should not be used
as one.
Not affiliated with or endorsed by the Lean FRO or the Mathlib community.
Part of F-Keys — independent hardware, software and internet products. See the working log and live status.
来源:README.md,提交 227b275
工具
0版本历史
1- v0.5.2最新Sep 16, 2026
评分
已满足适用检查项的 50%
该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。
- 近 30 天内可连通25 分
请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。
- 已声明认证方式10 分
请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。
- 已列出工具15 分
请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。
- 描述必需15 分
- 图标10 分
- 文档15 分
- 许可证10 分