// 这张覆盖率矩阵不是替代单页拓扑，而是回答两个问题：
// 1. 每个模块到底有哪些证据类型已经具备？
// 2. 哪些模块只有边界说明或规划口径，不能被误读成“已完成”？
//
// 本页统一把模块映射到六类证据：
// - Code
// - Query
// - Receipt
// - Logs
// - Negative
// - Boundary
//
// 这次再补一个“证据强度”列：
// - 强：主证据闭环更完整
// - 中：已有关键证据，但仍存在缺口
// - 弱：以导览、边界或规划说明为主
//
// 这样读者无需逐页猜测“证据强不强”，可以先在总表完成一次全站体检。

// 标注原则：
// 1. 有明确源码锚点，才记 Code。
// 2. 有链上或接口查询原文，才记 Query。
// 3. 有执行结果、回执或状态变更原文，才记 Receipt。
// 4. 有测试日志、运行日志或验收日志，才记 Logs。
// 5. 有错误地址、超时、空响应、stub 等保留样本，才记 Negative。
// 6. 即使没有前五类，只要页面明确写清当前边界，也至少要记 Boundary。
// 7. 证据强度按“强 / 中 / 弱”给出总评，帮助快速筛出最值得优先复核的模块。
//
// 因此这张表是“总索引”，不是“替代证据原文”。

// 这张表能证明的是：
// - 导航系统已经把大部分模块的证据颗粒度表达清楚。
// - 读者可以直接看到哪些页证据强、哪些页仍偏边界描述。
//
// 这张表不能越级证明的是：
// - 经济模型主线缺口已经全部关闭。
// - 规划态生态模块已经上线运营。
// - 广域网 / 主网收口已经完成。
//
// 所以“覆盖率高”证明的是导航表达可信，不是底层工程已经全部收官。

// 升格最小门槛：
// 1. 规划态 -> 部分实现：
//    - 至少出现真实代码底座、接口或可运行入口
//    - 同时页面要保留仍未闭环的边界说明
//
// 2. 部分实现 -> 已实现：
//    - 至少具备代码锚点
//    - 至少具备 query / receipt / log / test 中的关键原文
//    - 不再依赖“核心路径仍是 stub / planned”才能成立
//
// 3. 已实现 -> 部分实现：
//    - 若关键证据失效、路径回退为 stub、或原先结论被证伪
//    - 应如实降级，而不是保留旧标签
//
// 状态变化后必须同步：
// - 单页模块
// - credibility.html
// - evidence_coverage.html
// - trust_verdict.html（如可证范围受影响）
// - module_audit_report.json