#moonbit_static_analysis

1. 程序代码修订：分析快速进化中的 MoonBit 语言的程序（未定义名、未用绑定、类型错配、死分支、不可达代码）；
2. 静态状态修订：为多层状态机提供通用机器表审计（src/statecheck）——被测对象调用本模块，把机器表作为纯数据喂进来。参考消费方是 riantr/pyroduct（主体／群体／社会／进化层状态机族），其 audit 包用真实机器表调用本模块做黑盒测试。

#0.4.7 要点

#0.4.11 —— 第一次扫外部代码：四个修复，全部来自实测

moonx riantr/moonbit_static_analysis@latest riantr/pyroduct@latest

#0.4.12 —— 包私有跨文件解析：剩余最大的一类被关掉

• 26 条涉及的 11 个名字（sieve、ridge_fit、ridge_predict、ols_core、 normal_cdf、fmt、claim_code、claim_of、phase_code、contains_state、 has_state）全部是同目录兄弟文件里的包私有顶层 fn——26/26，没有例外；
• 工具链确认语言确实允许：两文件包里一个文件调用另一个文件的私有 fn， moon check 与 moon test 都通过，跨 _test.mbt 也一样（has_state 正是这一种）。所以这 26 条全是对分析器的误报。

1. 只取深度 0。 函数体、test、extend、impl 里的绑定都在至少一层花括号 之下，永远不会被收进来。否则一个局部 let 就能让自己全包可见。
2. 名字必须是关键字后紧邻的那个 token。 let (a, b) = ... 后面跟的是 (， 什么都收不到。
3. fn Foo::new 按整体收成 Foo::new，不是 Foo——Foo 未必存在。

#0.4.23 —— raise 效应标注，以及一个被它照出来的假阳性

#一条子句，两个位置

#顺带照出来的假阳性：guard!

// moonbitlang/async 0.22.4 src/internal/fd_util/pipe.mbt:31
 fds is [r, w]

#代价：actionable 涨了，而且涨的全是 UndefinedName

// proton facade_error.mbt:6
OperationFailed(action~, status=..., detail=...)
// 报: no visible binding for 'OperationFailed'

#突变门禁：9 道，9 杀 0 存活（_verify/mutate_0423.ps1）

• M7 / M8 是同一个守卫的两个方向。 守卫放行一切 → 裸 raise 吞掉函数体的 { 或闭合的 )，静默误解析，4 条测试变红；守卫什么都不放行 → 每个具名效应都不再被消费，6 条变红。 只测一个方向，会把「过严」误当成「正确」。
• M5 杀掉的不是 skip_indexed()，而是 raise 关键字自己。 第一版我把 skip_indexed() 去掉当 M5，结果 371/371 全绿——它是个等价突变：type_annotation 自己 就调 indexed_suffix()，raise E[Int] 不靠那行也能整块吃掉。这行死代码删掉了，理由写在 调用点：留着会让下一个人以为它在管一个它其实没管的用例，而删掉它的人没有任何证据说明有东西 在查。
• M2 第一次报的是 COMPILE-ERR，那是门禁自己的 bug 不是结果。 我的 Find 串以换行开头， 替换后代码被并进了上一行注释里，突变根本没运行。判据只有一个：Total tests: 行不存在 才算 COMPILE-ERR，绝不 grep。

#两个新记下来的缺口（这一版量到，没修）

• 返回类型在尾表达式函数体上渲染成 None。 fn f() -> Int { 1 } → f() -> None， 而 fn f() -> Int { return 1 } → f() -> int。跟 raise 无关：四种 raise 形式配上/不配上 显式 return 全部一致。真实 MoonBit 大量用尾表达式，所以这个的语料影响大概率远大于 raise 本身。 0.4.23 的测试因此刻意用显式 return——不然这条断言会因为一个和效应标注毫无关系的理由变红。
• 返回位置的带括号函数类型被当成元组。 fn f() -> (() -> Int) { 报 expected '{'， 没有 raise 也一样（return_annotation 的元组分支停在第一个 ) 而非配对的那个）。 真实的 -> (Int, String) 正常。语料影响小：moui 6 个文件，其余语料 0。下一版处理。

#0.4.22 —— 具名实参按名字匹配，以及 Int32 读作 Int

// core/pkg.generated.mbti:92 的声明顺序
ActionCommand::new(intent~, label?, shortcut?, enabled?, group?, description?)
// core/gesture.mbt:754 的调用顺序
ActionCommand::new(intent=..., label=..., group=..., description=..., shortcut=...)

• 夹具里多一行 let r = build() 会让三条突变全部存活。 实参类型不符时行为透镜会把 同一个调用报成 MethodError，和类型透镜的 ArgTypeMismatch 合并（merge_findings 按 (merge family, 行号) 分组），于是 count_family("ArgTypeMismatch") 恒为 0。 把 param_index 改成永不匹配，432 个测试照样全绿。 零计数断言只有在它数的那个 finding 真的以那个 family 到达时才可能失败。
• 两行同线会塌成一条。 同上，merge_key 是 (merge_group, line)；两个错实参写在 一行只回来一条，所以期望 2 的用例必须拆行。
• parse_call_args 有四个 push 点。 「不以名字开头的实参」那一个不是「以名字开头」 那一个；少 push 一次不会报错，只会让 labels 比 args 短，缺口之后的每个实参读到的 是后面某个实参的标签。补的夹具是 g(1, b=true)——顺带settle出一条语义： ? 可选形参根本不能按位置传（moon check 报 "requires 0 positional arguments"）， ~ 必填标签的也不能，只有裸的 a : Int 才行。这也正是具名实参在真实 MoonBit 里 到处都是、而按位置匹配误报那么多的原因。

• M7 all_positional 门（具名调用不查元数）。 没有任何测试能看见它，因为没有任何 合法 MoonBit 会用具名实参传超过形参个数——settle 过了：标签重复是 4084，标签匹配不 到形参是 4085，都是 moon check 已经报出来的编译错误。它的代价是量过的：六个语料 12,428 个文件里，它只影响 1 条 finding（moui backend/web/web_host.mbt，且在该文件 的可靠区边界之后，落进 unreliable 桶、从不作为结果显示），而那条无法确认是真阳性。 写一条钉住「无合法程序会表现出的行为」的测试会让门禁变绿、让套件变弱。
• M8 方法调用标签。 EMethodCall 现在带标签，但 infer 直接丢弃 （EMethodCall(base, _, args, _)），因为本模型里方法实参根本没有类型检查——没有 接收者签名可查。这是真缺口，不是设计上的宽容：要杀掉它得先有方法接收者签名，比这一版大。

#0.4.21 —— 436 → 481：guard、具名实参的 lambda、跨行的 is，和一个只绑第一个名字的 is

#C 是这个项目里最难查的一种坏：解析成功，树是错的

guard (self.frame, self.image, self.host_bridge)
  is (Some(frame_state), Some(image_state), Some(host_bridge)) &&
  !self.disposed else {

#D：先 settle 再动手，结果和我的判断不一样

fn f(x : Int) -> Int {
  guard try_os(x) is Some(Os(error)) else { return 0 }
  error + 1
}

• 不是 _，不是关键字
• 后面不是 (——那是嵌套构造器，不是绑定
• 左右邻居都不是 .——@core.Role::Checkbox 是限定路径，语料里 18 处
• 第一个 : 收尾——后面是类型标注，Int 不是绑定；:: 正好走到这条

#差分抓出了我自己引入的回归

runtime.prepare_bridge_request(request, window) is (Gone | PageUnavailable)

#差分

#突变 8 道全杀，两个方向都有

#没修的，如实记账

• 调用函数类型的参数会报 undefined function：let f = inc 然后 f(1) 就报，文件里根本没有 lambda。这是 0.4.19 加函数类型注解带出来的既有假阳性。 我的门禁夹具一开始踩到了它，才写进测试文件头的告诫里。
• is Some(x : Int) 的类型标注：全语料 0 处（18 处 is X(...) 里带冒号的 全是 @core.Role::Checked 这种限定路径）。规则里留了 : 收尾，但没有语料 验证过，不据此宣称已覆盖。

#工具链在这次发布当天动了，CI 一开始是红的

1. 本地 moon fmt --check 是绿的，所以不是我这棵树的问题。
2. 把已发布的 v0.4.20 tag 检出，用同一个新 moon 跑 moon fmt --check—— 也红。所以这是早就存在的环境问题，跟任何一次改动无关：上游一改 格式化器，不钉版本的 gate 就会在任何 commit（包括 revert）上变红。
3. 新 moon 是 0.1.20261012（当天发布），本地是 0.1.20260920。差异不是 空白：它把 src/core/moon.pkg 的 options("proof-enabled": true,) 改成 proof_enabled = true，全树 19 个文件要重排，其中还有 Int → Int32 的类型改写。
4. 先试钉版本——最省事。MOONBIT_INSTALL_VERSION=0.1.20260920 装到 CI 上，Install moon 这一步直接失败：CDN 上已经没有这个版本的 Linux 二进制。钉版本这条路是死的，因为旧的会被删。
5. 所以只剩一条：接受新工具链的格式化。

#顺带发现：突变脚本会静默失配

#测试

#0.4.20 —— 一个方法被当成了顶层函数

#我第一版的测试是空的，突变抓出来了

#改了两个地方，因为有两个独立的读取器

1. skip_decl_braced：fn 哨兵是给 pub impl Eq for T（无体，形参在另一个 块里）准备的，with 只出现在有体的那种写法里，所以拿 with 当区分。
2. collect_declared_names：完全独立的第二个名字读取器，根本不经过 skip_decl_braced。不给它自己加护栏，幽灵方法名原样回来。

#trait 自己的名字必须留着

#收割那道修复在 moui 上看不到收益，这是预期

#差分

#突变 4 道全杀，而且是两个方向

#0.4.19 —— 389 → 432：一个字面量被当成绑定名，和一个把文件读废的类型注解

#if x is Some(true) 把 true 当成了绑定名

#函数类型注解：845 处 / 171 个文件

#诚实记账：这一版 actionable 从 4 涨到 14

#差分

#突变：一道杀不掉，而且应该杀不掉

#0.4.18 —— 换一个语料：608 个文件里 193 → 389，actionable 588 → 6

#先 settle，再动手

Error [4100] x : &Node
  ╰── The type Node is not a trait
Error [4091] x.n
  ╰── @moonbitlang/core/ref.Ref[Node] has no field n

#六处修复，各自的账

#三条「读到了但丢掉」，不是三条规则

• spread 的 base 以空名压进字段表——walk/infer/interp 三家都写成 let (_, v) = f，只看值不看名，所以空名对它们不可见，而表达式活着， self 就还是被读到的；
• 行首链复用真正的 postfix 构造器（把 parse_postfix 拆出一个 parse_postfix_from），链段于是成为 EMethodCall，实参自然在树里。

#一处如实记账：b"..." 没有换来可读文件

#突变验证里，脚本自己抓到了自己的错

#差分

#还没修的（都是 parser，行为上有意不改）

• is 打头的表达式（f(x) 换行后接 is Some(_)）会被读成裸名字 is， 报 undefined name 'is'；if x is Some(true) 会把字面量 true 当成绑定名， 报 local variable 'true'。两处共 3 条 actionable，都在 core/view_node_test.mbt 一带。
• impl ... with fn layout(self, context) 里未标注类型的 self 报未定义， 1 条。
• 三处 parser 补完之后 219 个文件仍读不到全文，主因还是 unexpected token。

#0.4.17 —— 11 → 9：一条的根因是「上一版把探针写坏了」，另一条是「读到了却丢掉」

#Array::make：探针从来没调用过那个函数

#为什么是表，不是规则

#顺带证伪了 0.4.16 的一条结论

#Select：同包兄弟文件里的枚举变体

fn every_mode() -> Array[Mode] {
  [Select, Rect, Polygon, Keypoint, EditBinding]
}

#差分：933 个文件里只有 2 个文件的判定变了

#0.4.16 —— 19 → 8，其中 6 条是真阳性：先承认「对」，再修剩下的错

#跨包 const：3.0F * hz 被报成 'float' 和 'fn hz'

// snn_mbt/istdp.mbt
r: 3.0F * hz,   // hz 是 @snn_kw 的 const hz : Float

#带花括号的 suberror

#一个反向的发现：这个分析器漏报

限定名一度被过度报告（Layer::ReLU、fn hz），修完之后它们变成了 报告不足。

#改完又撤回：Byte::default / Array::make

let pixels : Array[Byte] = Array::make(total, Byte::default())

#结果

#0.4.15 —— 剩下 30 条里的 12 条：三个成因，其中一个差点把整条规则静音

#单元变体：同一文件里，带载荷的能读、不能带载荷的读不到

enum Layer {
  Conv2d(Conv2dParam)   // 能读
  ReLU                 // 报 undefined name
}

#「函数体是空的」不能当 extern 的代理

#结果

#突变脚本自己踩的第三个坑

#0.4.14 —— pyroduct 的 0 不是「对」：换四个语料，一次挖出三个真缺陷 + 一个静默错误

#还有一个不产生任何发现的缺陷

1.5 -> 1 | 0.25 -> 0 | 3.14159 -> 3

#实测过的修法，以及一条实测后撤回的修法

• 五道突变里，这三道全部存活（改回去套件照样全绿）；
• 在 933 个文件上做差分扫描，两次的报告流逐字节相同。

#结果

#顺带修掉的两个自伤

1. Get-Content -Raw 在中文 Windows 上按 GBK 解码 UTF-8，把注释里的 — 写成 鈥?，并且吞掉了后面的换行，把两行注释并成一行。现已改为按字节读、并用 SHA256 证明 restore 与运行前逐字节一致。
2. 差分脚本里 "$v_" 被 PowerShell 解析成名为 v_ 的变量（空），两次扫描 写进同一个文件、后者覆盖前者，于是「变体 A 和变体 B」变成了自己和自己比， 报出「完全一致」。现在用 ${v_}，并在比较前断言文件存在——两次读取都失败 曾经被当成「相同」。

#0.4.13 —— 最后 5 条：三种成因，其中一种是「把检查调窄」的陷阱

#第一条差点被我用一个更糟的 bug 换掉

#_ 前缀：分析器和编译器规则相反

#self 是约定参数名，不是关键字

#被突变验证挖出来的两件事

1. 突变脚本自己的过滤器匹配了 0 个测试。 两个 guard 报成 GREEN，其实 --filter 的 glob 根本没选中任何用例——一次「全绿」什么也没证明。脚本现在 断言 ran > 0，ran = 0 直接判 INVALID。
2. 一个修复没有任何测试能杀死它。 我一度让空列表字面量「采纳注解类型」， 把它静音后两个语料的发现流逐字节相同（496 / 528 条），也没有测试能杀它。 真正起作用的是 ty_assignability 那一条。测不出差别的分支不是保险，是没被测过 却长得像决策的代码——已删，并在两处注释里写明为什么删。

#0.4.10 —— 发布 0.4.9 才暴露出自检一直在遮蔽的两件事

no visible binding for 'is_coordinate'
no visible binding for 'split_coord'

let stem = if is_coordinate(p.target) {   // 226 行——if 表达式
  ...
if is_coordinate(target) {                // 411 行——if 语句

#0.4.9 —— @latest 扫描把自己的产物命名成 unknown

moonx riantr/moonbit_static_analysis@latest riantr/moonbit_static_analysis@latest --mmd-auto

MMD	riantr-moonbit_static_analysis_0.4.8_0.1.20260920_20261010T235302Z.mmd
  %% version=0.4.8

#0.4.8 —— 以 mermaid 工件为证据的三轮自检

• 第三轮的起点就是错的。 那 8 条本来准备当死代码清理。它们不是死代码——照着清理 就是删掉能跑的代码去迎合一条误报。那一轮找到的是分析器自己的缺陷。
• 插值那个修复立刻又造出两条误报：no visible binding for '1' 和 '10'， 出在 \{i + 1} 与 \{pct / 10}——标识符被允许以数字开头。只有拿真实代码再扫一遍 才会浮出来。修误报和制造误报是同一类动作，区别只在于有没有再跑一次扫描。

#安装 / 快速上手

moon add riantr/moonbit_static_analysis@0.4.23

// 用途一：修订一段 MoonBit（当前子集）程序
let result : @pipeline.PipelineResult = @pipeline.run(source, "main.mbt")
println(@pipeline.render_result(result))

// 用途二：审计一台状态机（机器表以纯数据进来）
let spec : @statecheck.MachineSpec = { name: "主体", states: [...], ... }
println(@statecheck.render(spec))

#三鉴（结构/类型/行为）（流水线核心）

#用途一：程序代码修订（快速进化中的 MoonBit 语言）

moon run src/cli          # demo：6 个样例 × 三鉴

=== undefined.mbt ===
2:10 - error: undefined variable 'missing' (UndefinedName) [structural+type+behavior]
  in main() at undefined.mbt:4
  in g at undefined.mbt:1
Summary: 1 finding(s) (before merge: structural 1, type 2, behavior 1)

#用途二：静态状态修订（机器表 → 三鉴）

let spec : @statecheck.MachineSpec = { name: "主体", states: [...], ... }
let findings : Array[@report.Report] = @statecheck.audit(spec)
let text : String = @statecheck.render(spec)   // 合并后的文本报告

规格 | 计数
---|---
状态 | 034
迁移 | 053
触发→槽 | 049 → 8
无路组合（带理由） | 228
修习历程 | 031 站

已知设计（4 条，出处层：设计使然——0.2.0 审计已验证）：
- state '无忆' is never entered: it appears only as a transition source
- state '无筹' is never entered: it appears only as a transition source
- state '无忆' is unreachable from the initial position '立位'
- state '无筹' is unreachable from the initial position '立位'

未预期发现：**0 条**

moon run src/cli 末尾那台 pyroduct 形状示例机器 是本模块内嵌的 8 状态玩具机 （statecheck.pyroduct_flavored()），不是 pyroduct 的真表；它带 182:12 这类 行:列，那是 state_span() 按状态名哈希出来的稳定伪 span（同一名字永远同一坐标）， 不是任何源文件的位置——别拿它去 pyroduct 里对行号。

#把扫描结果渲染成状态图（public API）

let root = /* 已解析到的源码根目录 */
let prov = @sa.provenance_for("my/module@1.2.3", root)
let text = @sa.mermaid_states(verdicts, @sa.aggregate(verdicts), prov, 8, 25)
println(scan_artifact_name(prov, root))

• 迁移标签是第一个 : 之后的全部内容，所以标签里不能再有 :——行号和消息因此放在 带引号的 state 标签里，绝不放箭头上
• MoonBit 没有运算符续行，源码里以 + 开头的行是语法错误——所以文档是一段一段 write_string 拼出来的，原因就是这个

#给产物命名：版本与扫描时间写进文件名

moonbit_static_analysis_0.4.7_0.1.20260920_20261009T155222Z.mmd
moonbitlang-core_0.1.20260920+7d59c7ec9_0.1.20260920_20261009T051925Z.mmd
tree_unknown_0.1.20260920_20261009T051511Z.mmd     # 版本没找到

moon 0.1.20260920 (914d7da 2026-09-20)

本轮更正。 上一版这一节写着「CLI 根本没法打时间戳，因为唯一的时钟在 internal 包后面」。那是错的：moonbitlang/async 把它公开重导出了 （pub using @event_loop {now}），而且 provenance_for 从 0.4.5 起就在调 @async.now()。CLI 之所以写 unknown，只是因为它被塞了一个手写的空时间戳，而没有去调 那个本来就能用的函数。

• 不省略它没能确定的东西。 版本、工具链或时钟缺失时写字面量 unknown。省掉那一段会 得到一个"看起来完整"的名字，而且四个字段时更糟：会错位——读 core_0.1.2_20261009 的人会把时间戳当成工具链版本。
• 不产出 dotfile。 以 . 开头的名字在 Linux/macOS 上 ls 根本列不出来，而没人 列得出来的产物等于没人找得回来。
• 不把文件名当记录。 同样的三个字段会以 %% 注释重复写在文档正文里，因为文件 是会被改名的，改完名之后它的名字就不再是证据了。

#从 CLI 直接写出一张图：--mmd / --mmd-auto

moonx riantr/moonbit_static_analysis@latest <target> --mmd out/scan.mmd
moonx riantr/moonbit_static_analysis@latest <target> --mmd-auto

• 要显式开，永远不是默认。 这张图天生有损：mermaid_states 按 actionable 数排序、 到自己的上限就停，并在正文里写明 %% THIS DRAWING IS A SUBSET。把图当唯一输出等于把 这句话藏起来，而且会悄悄弄坏所有 grep SUMMARY 的脚本。
• --mmd 必须带路径，自动命名另给一个 --mmd-auto。 可选值在这里是歧义的： <target> --mmd <path> 里 --mmd 后面那个裸词同样可能是第二个目标，两种读法无法区分。 与其猜、然后以 "unexpected extra argument" 失败，不如让这个值必填。
• 产物绝不落进被扫描的树里。 本模块写明的约束是只读目标的文件；往别人的源码仓库 里丢文件既违背这个承诺，也会弄脏一棵用户未必拥有的树。

MMD  _mbcore_0.1.20260920+7d59c7ec9_0.1.20260920_20261009T132547Z.mmd

#包结构

src/core      Span/Severity/Lens/Family(merge_group 契约)/Frame + Family::advice
src/report    Report 结构与渲染（lens 并集标签、vst 框架）
src/sa        扫描入口 + aggregate() + mermaid_states()（对外 library）
src/lexer     MoonBit 词法前端
src/parser    MoonBit 语法 → ast（含 .mbtx 脚本的 import 块）
src/ast       MoonBit 抽象语法
src/walk      结构鉴：绑定表 + 结构发现
src/types     类型鉴：Ty/Ty?/Sig 推断
src/interp    行为鉴：AbsVal 格 + 调度 + 虚栈
src/pipeline  组装：跑三鉴 + merge_group 合并
src/moonfiles 其余文件种类：.mbt.md 逐块三鉴 / .mbti 接口审计 / .mbtp 证明 lint
src/statecheck 用途二：通用机器表审计（MachineSpec 纯数据桥）
src/samples   demo 样例（内嵌 MoonBit 源）
src/cli       可执行入口（程序 demo + 文件种类 demo + 示例机器审计）

#文件种类（MoonBit 工具链的其它后缀）

#验证

moon check --target all --deny-warn   # 0 错 0 警（js / native / wasm / wasm-gc）
moon test --deny-warn                # wasm 192/192；js 与 wasm-gc 139/139
moon run src/cli                     # 程序 demo + 文件种类 demo + pyroduct 形状示例机器审计

CI 只跑 --target js；上面「四个 target」是本地跑的结论，CI 不覆盖 native/wasm。

#形式验证（moon prove）

moon prove src/core --why3-config .why3.conf   # 生成 19 个 VC 并交 cvc5/alt-ergo

• 21/21 目标全部 VALID（unsat）：19 条引理 + span_at/zero_span 两个自动安全 VC。
• 已知工具链限制（均为上游问题，非本项目代码）：
  1. #proof_pure 函数体为结构体字面量时（pos/span_at/zero_span）降级为不透明逻辑符号 —— 函数体被丢弃，span 形状律在逻辑侧不可证（已由测试钉住，见 core_proof.mbtp 注释）。
  2. 捆绑 why3server（Windows 构建）丢失求解器 stdout —— why3 报 "High failure"、输出仅 .；裸 why3 ... prove CLI 同样复现。逐目标机检绕过： why3 -o <dir> -P cvc5 <mlw> 导出 SMT 后对每个文件跑 cvc5。

#发布

• mooncakes.io：moon publish（发布后 riantr/moonbit_static_analysis@0.4.23 可被任何 MoonBit 模块以 import 依赖；src/cli 附带 SKILL.md，上架 skills.mooncakes.io）。
• Gitee / GitHub：git push 双推；tag 与 moon.mod 版本号保持一致。

#分析其他项目（不引入本项目）

moonx riantr/moonbit_static_analysis@latest riantr/moonbit_doubleML@latest

#输出说的是「我读懂了什么」，不是「我数出多少条」

SCANNED	107 files under ...\ML\CI
CLEAN	.mbti	...\CI/pof/pkg.generated.mbti
PARTIAL	.mbt	defects=2	notices=1	read up to line 36, 57 after it not shown	...\CI/pof/aggregator.mbt
12:3 - error: ... (UndefinedName) [behavior]
PARSED	32/107 files understood (29.9%); 75 more read only up to their first parse error
SUMMARY	files=107	parsed=32	actionable=57	notices=211	unreliable=15759	withheld=6769	total=16027	(actionable+notices+unreliable = total; withheld ⊆ unreliable)

• PARSED 是头号指标。 工具链的前端只覆盖 MoonBit 的一个子集，读不懂的部分 报出来的「发现」量的是工具的盲区，不是你的代码。
• 半读懂的文件仍然值得读。 解析器记录它真正读不下去的第一行；那之前的 发现照常报（PARTIAL），之后的计入 unreliable 且从不展示——它们来自一棵 已经错了的树，摆出来等于把这个工具最初的毛病又犯一遍。
• 跳过声明不算读不懂。 「不分析 test 块」不会移动这条边界，因为块之后的 代码照样读得通。
• actionable 不含告知。 「这种声明不分析」不是你的代码有缺陷——不然自检 会报「发现 92 个问题」而真实缺陷是 0。
• 未解析文件按原因分组而不是一行一个，带示例路径。
• actionable + notices + unreliable = total，这一行打印里直接断言成立。withheld 也印在旁边，但是 unreliable 的子集（无前置发现的 PARTIAL 文件的尾部发现），不计入等式。

与 moon check 的关系要说清楚：在 .mbt 上，本工具不与工具链的编译器 竞争——moon check 有真正的解析器和约 90 条内建告警，覆盖率恒为 100%， 实测 2.3 秒 / 128 条，且每条都带 file:line:col、源码片段与修复建议。本工具的 .mbt 前端只读一个子集：在 moonbitlang/core 上，882 个 .mbt 解析了 173 个（19.6%），而 .mbti 与 .mbt.md 是 100%。原先最大的单一原因 方法调用在 AST 里根本没有位置——ECall 的被调名是 String，所以 m.set(k, v) 无处安放，解析就停在那里——本轮已修（新增 EMethodCall 节点， 三个 lens 都接上），该阻塞从 34 降到 0。这才是诚实的头条数字，也是 PARSED 要印在第一行的原因。本工具能说「编译器做不到」的地方是 .mbti / .mbt.md / .mbtp 三类文件与跨包语义。

早先版本在同一份 ML/CI 代码上报过 529 条「未使用局部」，而编译器报 8 条。 那不是两种意见，而是没解析的 struct 函数体里那些字段被当成了没被读的绑定。 现在它报不出来了——被前端截断的函数会整函数退出未使用局部 / 未使用参数 / 参数被改写这三族审计，因为「从未被读」是关于整个函数的结论，半个函数 支撑不了这个结论。仅此一项修复就把 moonbitlang/core 从 270 条 actionable 降到 147 条，把本仓库从 11 条降到 0 条。

再往下读，同一条原则还适用于模块帧，也适用于一类解析器从没学过怎么解析的 名字：前端没读完的文件，模块帧是可证不完整的，所以那里「找不到可见绑定」 什么也不能证明；而 Type::member 路径（@debug.Repr::opaque_(v)）是成员引用 不是绑定，跟字段名、方法名本来的处理一致。再把 extern "c" fn 当成声明建模 （原先整条跳过，名字就丢了，于是每个 extern 函数的调用点都报未绑定），补上数值 字面量与 enum 构造器，moonbitlang/core 从 270 条降到 49 条，undefined name 从 64 条降到 17 条（发布 0.4.6 时误记为 0，与该版扫描产物不符，后按实测勘正）， 本仓库仍是 0；0.4.7 再把 .mbti 审计的未知类型检查接到模块级接口符号表上， 其余 13 条误报清零，降到 36。

moonbitlang/core	文件	解析	actionable	未定义名
0.4.5	1029	305	270	64
0.4.6	1029	320	49	17
0.4.7	1029	320	36	17

#DeepSeek Harness 插件