rust-java-migration-testing

Java 到 Rust 的迁移测试

证明可观察兼容性和 Rust 安全属性，而不是追求测试数量。将完整的源测试套件视为不可妥协的兼容性底线：迁移 100% 的测试用例，不得弱化输入或断言；将每个测试夹具／数据／脚本逐字节复制到目标仓库，并确保两种实现对每个用例产生相同的可观察结果。按以下顺序建立三个明确的测试台账：

强制验证结构

• 要求 Java/Rust 路径完全一致；每个 MISPLACED 项或 file-map.csv 中缺失的目标都会阻止完成。
• 文件移动后，将 E0583/E0761/E0405/E0425/E0659 和损坏的夹具路径视为结构性故障。
• 物理行数不超过 500 行视为正常；对 501–800 行的自编 .rs 文件进行内聚性审查；超过 800 行的文件不得通过。按契约或行为类别拆分测试套件，而不是按任意行数范围拆分。
• 允许在实现旁边的 #[cfg(test)] 模块中编写聚焦的单元测试。将公共边界、跨模块、差异、主机、负载和整个项目的测试放在 tests/ 或非发布的 test/testkit crate 中。
• 运行路径审计、fmt、默认／全部功能检查、Clippy、完整测试、黄金／实时差异测试、迁移审计和项目覆盖率门槛；不得将任何一项结果单独作为兼容性证明。

阅读目录一致性验证和迁移验证标准操作流程。

1. SOURCE_PARITY — 映射每个源测试／用例和每项源测试资产；不允许有缺失、受阻或不适用的行，否则不得宣称已完成。
2. RUST_OBLIGATION — 测试 Rust 实现和替代组件引入的风险。
3. VALUE_ADD — 针对未覆盖的行为、可能的缺陷、事故、变异测试存活项或恶意输入，添加有依据的测试。

SOURCE_PARITY 必须包含两个部分：TEST_CASE 和 TEST_ASSET。 TEST_CASE 保留源输入、断言、异常／错误类别、顺序、状态、副作用和清理行为。TEST_ASSET 保留每个复制的夹具、脚本、语料库、黄金文件和数据文件的源相对路径、目标路径及 SHA-256。覆盖率应随着有意义的契约得到测试而提升。百分比不是设计输入，100% 也不能证明迁移正确。

范围与路由

将此技能用于迁移专属的测试规划、实现、审计和验收。

这是共享目标语言迁移配置文件的 Rust 测试适配器。保持源测试处置方式、精确资产规则、完整差异测试结果和完成语义与 zig-java-migration-testing 及未来的 Kotlin/Swift 适配器一致；仅调整 Rust 测试／构建语法和 Rust 风险。

路由：

• 模块／对象／组件迁移规划：rust-java-migration；
• 通用 Rust 单元测试、集成测试、文档测试和夹具机制：rust-testing；
• 异步模型检查：rust-concurrency；
• 性能分析和基准测试构建：rust-performance；
• 不安全代码和 FFI 验证：rust-unsafe-ffi；
• Web 威胁建模：rust-web-security。

仅审计的请求不授权删除或改写测试。保留现有行为和无关的未提交工作。将启发式发现视为待审查项。

必需输入

解析或标记为未知：

• 固定的 Java 和 Rust SHA、脏状态、工具链、配置、功能、目标，以及生成代码边界；
• 权威工作区拓扑决策，以及目标生产包和 <project>-test 包的实际路径；不要假设存在 crates/ 目录；
• 完整的源测试根目录和运行器配置，包括夹具、示例、脚本、测试资源、参数源、动态工厂和测试支持代码；源仓库定义分母，不得仅为使一致性达到 100% 而引入排除项；
• Java 测试运行器和 Rust 测试运行器，包括参数化和动态测试行为；
• 源覆盖率范围／工具／报告，以及可比较的 Rust 覆盖率范围／工具／报告；
• 可用的预言机：仅源代码、可执行 Java 测试、黄金数据导出器、打包构件、在线服务或标准套件；
• 由相同 Java／Rust 基线生成的当前权威对象台账；读取当前状态时忽略历史设计附录；
• 所需主机、真实依赖、并发／负载模型、安全边界和回滚机制；
• 时间、标识符、路径、映射顺序、区域设置、浮点精度和调度的确定性规范化规则。

绝不使用未固定版本的远程构件作为兼容性预言机。

证据标签

使用以下标签，不得提升等级：

等级	证据	允许的声明
V0_STATIC	源码／测试清单、调用跟踪、无桩扫描	仅结构性处置
V1_RUST_LOCAL	Rust 单元／集成／文档／编译测试	Rust 本地行为通过
V2_MIRRORED	Rust 测试保留了某个具名 Java 测试的输入和断言	已表示源测试；不是差分测试
V3_GOLDEN_DIFF	将固定的 Java 生成夹具与 Rust 进行比较	记录的输出匹配；完成要求覆盖完整源分母
V4_LIVE_DIFF	固定版本的 Java 和 Rust 执行相同用例	记录的在线行为匹配；完成要求覆盖每个源用例
V5_HOST	真实框架／进程／数据库／网络／文件系统	指定的集成边界可正常工作
V6_NONFUNCTIONAL	模型、变异、属性、模糊测试、负载、浸泡、安全	指定的非功能性声明成立
V7_ROLLBACK	灰度发布和回滚演练	声明的恢复路径可正常工作

复制测试名称、Rust 测试套件全部通过或达到 100% 行覆盖率，都不能证明 V3_GOLDEN_DIFF。

证据等级绝不替代对象状态。V1_RUST_LOCAL 测试套件全部通过，也不会将 MISSING、MISPLACED、STUB、PARTIAL 或 UNVERIFIED 转变为 IMPLEMENTED。DEPENDENCY_REUSED 还要求提供精确固定版本的上游符号和本地集成测试；PLATFORM_NA 则要求平台证据，不能仅凭跳过该行为的通过测试认定。

SOP

1. 固定验证基线

记录精确的 SHA、命令、工具、配置、功能、目标、测试数量、被忽略／不稳定的测试、覆盖率排除项和现有证据构件。在比较之前，分别记录 Java 和 Rust 的覆盖率。

设计测试前，先阅读权威对象表的当前事实区域。读到 historical-design-appendix-start 时停止；旧附录中的状态仅供参考。记录所有严格对象状态的数量。只要仍有任何未完成状态，无论测试结果如何，验收报告都必须注明“模块迁移未完成”。

如果已建立索引，请使用 CodeGraph 跟踪每个源测试经过的生产入口、协作者、副作用和 Rust 对应项。对于重载方法、注册表、拦截器、动态分派、清理和异步路径，仅凭文本相似度并不足够。

2. 清点源测试和目标测试

为每个 Java 测试方法创建一行，并为每个具体的参数化、重复、模板或动态测试用例创建一行。包括已禁用的测试；已禁用的源测试仍是必须迁移的测试，并应单独保留其禁用原因。为每个源测试资源、夹具、脚本、语料库和数据根目录中的每个文件创建一行 TEST_ASSET。原样复制源资源，不要编辑；将目标生成或规范化后的衍生文件放在不可变副本旁边。

使用以下处置状态：

处置状态	含义
MIRRORED	在一个 Rust 测试中表示相同契约
ADAPTED	使用 Rust 原生夹具／判定器表示相同的可观察契约
SPLIT	一个 Java 测试拆分为多个专注的 Rust 测试
MERGED_APPROVED	多个 Java 测试合并为一个参数化 Rust 测试，且未丢失用例／断言
NOT_APPLICABLE	记录仅适用于 JVM 的声明以供分析；会阻止达成 100% 无损的源测试完成度
BLOCKED	已命名的依赖项或判定器导致测试无法执行；会阻止完成
MISSING	没有 Rust 实现；会阻止完成

只有在每个源用例仍可识别、所有保留标志均为 true、每个目标测试均存在，且黄金／实时比较记录为 MATCH 时，MIRRORED、ADAPTED、SPLIT 和 MERGED_APPROVED 才算完成。ADAPTED 允许使用 Rust 原生测试框架机制，但不允许弱化契约。SPLIT 和 MERGED_APPROVED 可以重新组织测试，但不得移除任何用例或断言。不要仅按测试名称进行映射。

将 SKILL_DIR 解析为此技能目录，并从迁移仓库运行：

python3 "$SKILL_DIR/scripts/audit_migration_tests.py" \
  --java-root ../java-project/source-module \
  --rust-root <selected-target-crate-or-workspace> \
  --object-ledger docs/source-module/对象级对照表.md \
  --parity-manifest docs/source-module/source-test-parity.json \
  --java-test-assets-root src/test/resources \
  --fail-on-incomplete

该报告会清点测试、标记弱信号、验证每一行源测试清单、检查目标测试文件、校验精确的资源副本哈希，并拒绝为任何对象、测试、资源、运行或差异缺口设置完成门槛。其他非标准资源根目录必须通过重复传入 --java-test-assets-root 指定。脚本会验证记录的保留证据，但无法推断语义映射或授权删除。对于超过 500 个物理行的自编写文件，它会发出警告；超过 800 行的文件会阻止完成。行内单元测试是有效的 Rust 组织方式，不会被报告为结构违规。

3. 实现 SOURCE_PARITY 账本

对于每一行源记录：

1. 追踪受保护的 Java 契约和生产调用路径。
2. 移植夹具和断言，而不只是方法名称。
3. 保留有效、边界、失败、状态转换和副作用用例。
4. 从固定基线运行源测试套件和目标测试套件，并保留每个用例的原始结果。实现期间，缺少 Java 输出的镜像测试仍有用，但不满足最终的源测试一致性门槛。
5. 通过固定的黄金或实时差分判定器比较每个源用例；要求结果为 MATCH、测试框架失败数为零，且未运行用例数为零。
6. 记录 Rust 测试、保留标志、证据、命令、制品及任何差异。

缺失、受阻或不适用的源测试必须保持可见，并会阻止得出迁移已完成的结论。源测试是兼容性底线，并非完整的 Rust 计划。

全项目迁移测试模块

对于每一项仓库／产品级迁移完成声明，都要创建一个不发布的工作区包，作为全项目验收依据。对于包含多个 crate、绑定／适配器，或源系统／模板套件的项目，这一点尤为重要。默认命名为 <project>-test；最终目录名与 Cargo 包名保持一致，设置 publish = false，并在 CI 中显式运行。其父路径遵循已记录的工作区拓扑：小型根目录扁平工作区使用 <project>-test/；混合型工作区可以将其放在根目录或实际的测试目录中；包含式工作区可以使用 crates/<project>-test/ 或 crates/tests/<project>-test/。生产 crate 中的本地测试可验证其自身的解析器／类型／API／绑定行为；但不能替代全项目模块对源套件的重放、跨 crate 工作流、实际复制的资源、黄金／实时差异比较或汇总结果产物的验证。

FreeMarker 使用以下边界：

freemarker/          # Rust engine local unit/integration tests
freemarker-pyo3/     # Python binding local/packaging tests
freemarker-test/     # complete Java templatesuite + cross-component acceptance

freemarker-test 包必须是工作区成员，依赖受测的公共接口，并保持在 crates.io 发布范围之外。完整门禁要求每个源用例都为 MATCH，不得设置通过数量阈值，不得跳过能力或忽略用例。有关命名、归属、布局和 CI 规则，请阅读 迁移验证 SOP。

测试包的语义角色是强制要求；其物理父目录不必固定。切勿仅为模仿 Java 测试模块树或通用 Rust 示例而迁移它。

不要用每个对象一个测试来替代每个源对象一个真实文件。测试即使调用了重新导出接口、兼容性门面或合并后的类型，也无法消除 MISPLACED／MISSING。只有在布局和对象边界确实存在后，测试才能验证语义。

将 500 行物理代码作为套件内聚性审查阈值，将 800 行作为手写文件的阻断阈值。按契约、行为族、夹具族、适配器或验证层拆分，同时保留每个源用例 ID 和断言。将精简的私有行为单元测试保留在 #[cfg(test)] 模块中；将可复用的集成测试支持代码放入 tests/common/ 或专用的 testkit crate。启用 clippy::too_many_lines，以审查超过其默认 100 行的函数。

4. 实现 RUST_OBLIGATION 台账

添加目标设计要求的适用测试：

Rust 机制	必须检查的问题
所有权 / Drop	是否恰好清理一次、部分初始化、提前返回、panic/cancel 边界
异步 / Tokio	取消、超时所有权、孤儿任务、关闭、有界队列、慢速消费者
共享状态	原子性、中毒/恢复策略、是否有锁跨越 .await、死锁/交错风险
Send / Sync	预期的编译契约和支持的执行器/线程边界
类型化错误	确切变体、上下文、是否可重试、Error::source、公开的脱敏界面
serde / 线协议/存储	重命名/默认值/未知字段、往返、字节、兼容窗口
Trait / 注册表	选择、重复注册、缺少提供方、动态分派
过程宏	编译通过/失败、泛型、可见性、依赖重命名、诊断信息
功能/平台/MSRV	支持的组合能否按承诺编译并正常工作
不安全代码 / FFI	不变量、适用时的 Miri/消毒器、跨边界所有权
替换 crate	高风险语义路径、生命周期、真实依赖、升级/回滚边界
框架适配器	一套共享契约测试，以及适配器原生的路由/正文/服务行为

这些测试不必存在于 Java 中，因为它们旨在保护 Rust 实现的正确性。

对于 DEPENDENCY_REUSED 行，使用确切声明的上游符号/版本或提交，执行本地适配器。依赖自身的单元测试、文档示例或类似功能名称，都不能作为本地集成证据。断言穿过适配器的源契约排序、错误、生命周期、取消行为和元数据。

5. 实现 VALUE_ADD 台账

只有在有充分理由时才添加测试，例如：

• 覆盖率揭示了缺失的边界或分支；
• 有意义的变异仍能存活；
• 覆盖广泛输入空间的属性/不变量；
• 模糊测试发现了格式错误或恶意输入；
• 生产事故或 Bug 回归；
• 并发交错、负载、资源泄漏或长时间运行风险；
• Java 测试套件未覆盖、但文档/协议要求的兼容行为；
• Mock 无法证明的真实宿主或回滚行为。

为每项测试记录它应捕获的具体 Bug。优先采用小型参数/分支矩阵，而非追求“每种类型/令牌/方法各一个测试”的数量目标。

6. 使用可观察断言

强测试会观察确切的公开行为：

• 值、字节、顺序、状态转换、调用次数、副作用、资源释放或类型化错误；
• 对公开的内容分别检查 Display、Debug、序列化错误报告、日志/跟踪字段、传输正文和 Error::source()；
• 声称缓存行为时，检查缓存命中/未命中/驱逐指标或后端调用次数；
• 声称流式生命周期行为时，检查正文/尾部/背压以及断开连接后的清理。

需要审查的弱模式：

• let _ = result、未使用的解析 AST，或既接受成功也接受失败的测试； 请注意，在清理期间，将确实被丢弃的 Result 转换为 let _ = expr; 会保留语义，本身并不构成弱证据——只有当 let _ = 是 对被测行为的唯一观察方式时，才会变弱；
• 仅做解析的检查，却命名为语义/求值测试；
• 当值/错误类别很重要时，只检查 is_ok() 或 is_err()；
• 只观察最终值的缓存测试；
• 对 Fixture 的 Clone、Debug、常量、构造函数或类型存在性的测试，却没有公开契约；
• 没有独特风险的重复“覆盖率突增”测试；
• 仅证明 todo!() 或 unimplemented!() 会 panic 的测试。

清理前请阅读 Vernal 案例研究 和 测试价值评估准则。

7. 构建差分测试固件

使用带版本的案例格式，例如 JSON Lines：

{"schema":1,"case_id":"empty-name","input":{"name":""},"expected":{"kind":"error","code":"INVALID_NAME"}}

分别保留 Java 和 Rust 的原始输出。固定导出器和实现的 SHA、种子、环境及规范化器版本。根据具体情况比较成功值、错误类别、副作用、顺序和线路字节。不要通过规范化来抹去意外字段。

差分比较是完整源测试套件的门禁，而非代表性样本。最终清单必须为每个具体源案例记录一个 MATCH，并记录套件级 Java、Rust 和差分运行结果，均为 PASS，不匹配数为零、测试框架故障数为零，未运行案例数为零。临时子集可以用于指导开发，但必须标为部分测试，不能满足完成要求。

8. 为适配器复用一致性测试套件

将共享断言和失败测试固件放入测试工具包。每个适配器都必须提供真实的原生观测结果。为每个实现运行相同的身份、作用域、生命周期、错误、取消、流式传输和清理契约，然后添加适配器原生测试。

优先使用事件驱动的同步和有界超时，而非固定休眠。断言流处于活动状态时资源保持打开，并在完成、断开连接、超时、取消或发生 panic 后关闭。

9. 公平比较覆盖率

只有在覆盖范围有文档记录且具备合理可比性时，覆盖率比较才有效：

• 纳入的生产文件／模块；
• 生成代码和经批准的排除项；
• 各工具的行／区域／分支语义；
• 功能、目标平台、测试类型和配置；
• 源基线和目标基线。

验收顺序：

1. 每个源测试和具体案例都有无损的目标实现；
2. 每个源测试资产都有经过 SHA-256 验证、字节完全一致的目标副本；
3. 两个完整测试套件均通过，且每个源案例的差分结果均为 MATCH；
4. 每个高风险源契约都有充分证据；
5. 每项适用的 Rust 要求都经过测试；
6. 已审查有意义的变异体和未覆盖分支；
7. 若项目有此要求，可比的 Rust 覆盖率高于 Java 基线。

不要弱化断言、重复测试、排除难处理的文件，或添加无实际意义的 getter 来凑数字。用户强制要求的 100% 门禁可以执行，但须说明它能证明什么、不能证明什么。

10. 移除或合并测试前审查其价值

手动为每项测试评分：

问题	通过标准
可追溯？	明确指出源测试、契约、风险、缺陷或事故
可观测？	断言检查外部有意义的行为
对变异敏感？	合理的缺陷会导致测试失败
走生产路径？	在正确边界上执行真实的生产逻辑
确定性？	同步方式／种子／环境均受控
有区别？	增加了分支、案例、平台、失败场景或不变量
层级恰当？	单元／集成／主机／负载测试与边界相符

将测试分类为 KEEP、IMPROVE、MERGE 或 REMOVE_PROPOSED；删除前必须经过审查。覆盖率下降本身可以作为替换测试的理由，但不能作为保留无意义断言的理由。

11. 运行分层门禁

按成本从低到高、诊断性从弱到强，运行适用的门禁：

cargo fmt --all -- --check
cargo check --workspace --all-targets --all-features
cargo test --workspace --all-features
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --doc --workspace

然后运行定向编译失败、平台/MSRV、差分、真实依赖、真实宿主、模型/Loom、Miri/消毒器、变异、属性/模糊、负载/浸泡、安全和回滚门禁。记录准确的命令、环境、结果和产物。

在工作区 MSRV 下运行每个门禁：如果默认 rustc 版本早于工作区的 rust-version，就会报错 rustc X is not supported by the following packages， 而不是测试你的代码——请使用 rustup run <ver> cargo ...，绝不要 悄悄降低清单中的版本。使用 --keep-going，避免某个 crate 失败而掩盖其余错误（错误会分层显现；修复第一层后再运行）。要求默认配置和 --all-features 检查均达到零警告：受功能门控的 crate 和代码路径只有在 --all-features 下才会编译；带有警告的检查门禁必须报告为缺口，而非通过。

使用项目专用的覆盖率命令。对于变异候选项：

"$SKILL_DIR/scripts/run_mutation_test.sh" <selected-target-crate>

逐一解读存活项；不要强求统一的变异分数。

12. 如实报告验收情况

分别报告：

• 源测试的无损实现情况和逐案例差分覆盖情况；
• 按 V0–V4 分级的源行为证据；
• Rust 义务完成情况；
• 增值测试及缺陷/风险依据；
• 可比范围内的行/分支/区域覆盖率；
• 变异、属性、模糊、并发、负载、安全、宿主和回滚证据；
• 失败、不稳定/已忽略的测试、存根、排除项、缺失目标及外部边界。
• 当前对象状态计数，以及所有 MISSING/MISPLACED/STUB/PARTIAL/UNVERIFIED 阻塞项的明确清单；
• 编译器和 Clippy 警告、已忽略的测试/文档测试、功能/目标缺口，以及 未执行的测试；

红线

• 不要将镜像测试称为差异测试。
• 不要用原始测试数量对等替代源测试处置状态。
• 不要排除、禁用、弱化、合并掉任何源测试，也不要将其标记为不适用，以制造 100% 对等。
• 不要就地改写复制的源测试夹具或数据；保留字节完全一致的副本，并单独生成特定于目标的衍生版本。
• 不要将两套各自通过的测试套件视为结果对等；必须逐案例进行 Java/Rust 基准或实时对比。
• 不要用生产代码或绑定 crate 中的本地测试替代非发布的 <project>-test 全项目验收包，也不要将通过率阈值、跳过项或忽略的案例作为其完成门槛。
• 未检查迁移路线图中由项目驱动的工作区拓扑前，不要将 <project>-test 硬编码到 crates/ 下或仓库根目录中。
• 不要仅为提高覆盖率或文件数量而编写测试。
• 不要让编写的 .rs 文件超过 800 行（按物理行计）；审查每个超过 500 行的文件，并拆分内聚性较弱的测试套件。
• 不要压缩代码、删除有用注释，也不要任意拆分行范围来规避大小门槛。
• 不要将集成、差异、宿主、负载或全项目测试套件放在生产模块中；聚焦的内联单元测试仍然有效。
• 不要将解析成功称为语义等价。
• 如果错误契约可观察，不要接受泛泛的 is_err()。
• 不要根据名称、正文长度或启发式规则自动删除测试。
• 不要通过宽泛的归一化或重新生成快照来掩盖不匹配。
• 当契约跨越依赖或宿主边界时，不要用模拟对象替代真实依赖或宿主测试。
• 不要将固定时长的休眠作为唯一的异步协调机制。
• 不要因为生产代码桩的测试能编译，就将其视为已实现。
• 当权威对象台账中仍有未完成状态时，不要仅凭 Cargo/JUnit 测试总数、覆盖率或通过的 CI 作业，就宣布模块完成。
• 没有源测试对等清单时，不要运行完成门禁。缺少测试映射、参数展开不完整、保留标记错误、缺少目标文件、资产哈希不一致、结果不是 MATCH、测试框架失败或案例未运行，都会阻止完成。
• 不要从历史附录或过时的重复迁移文档中读取完成状态。
• 不要根据上游测试或语义相似性宣称已验证依赖复用；必须有确切的依赖符号和本地集成测试。
• 当 cargo check（默认或 --all-features）仍产生警告，或运行使用了不受支持的工具链而非工作区 MSRV 时，不要报告检查门禁已通过。

按需资源

• 迁移验证标准操作流程
• 目录对等验证与迁移后检查
• 跨语言迁移配置
• 测试类别
• 测试价值评估标准
• Vernal 正反示例
• 迁移测试台账模板
• 机器可读的源测试对等清单
• 审计报告示例
• scripts/audit_migration_tests.py — Java/Rust 测试清单与弱信号审计
• scripts/run_mutation_test.sh — 变异测试包装脚本

完成标准

• 冻结的源测试根目录中的每个 Java 测试，以及每个具体的参数化／动态／重复用例，都有目标语言实现和源代码追溯；源用例分母的覆盖率为 100%，且没有排除任何用例。
• 每个源 fixture、资源、脚本、语料库、黄金文件和测试数据文件，在目标仓库中都有字节完全相同的副本，且 SHA-256 匹配。
• 每个映射后的用例都证明契约、输入、断言、fixture 状态和清理步骤均得到保留；拆分、合并或适配后的形式不得遗漏任何内容。
• 完整的固定版本 Java 和 Rust 测试套件全部通过，完整的黄金／实时差异报告中只有 MATCH，且没有测试框架失败或未运行用例。
• <project>-test 包是工作区成员，设置了 publish = false，位于记录的工作区拓扑所选路径下，测试公共组件接口，并拥有完整的套件／差异测试命令和汇总产物；本地 crate 测试仍作为子系统证据。
• 已检查权威的当前对象台账，其基线与测试运行相符，且测试摘要未掩盖任何未完成的对象状态。
• 每项高风险契约都有预言机、证据标签和结果。
• 已测试适用的 Rust 所有权、异步、错误处理、序列化、功能、适配器和不安全代码义务。
• 新增测试均指明一种不同的风险或合理可预见的缺陷。
• 每个编写的 .rs 文件最多 800 行；超过 500 行的文件和超过 Clippy 100 行提示阈值的函数，都已记录内聚性审查。
• 聚焦的单元测试可以与代码放在一起，位于 #[cfg(test)] 模块中；集成、差异、主机、负载和整个项目的测试套件位于 tests/ 下，或非发布的测试包中。
• 覆盖率范围具有可比性，任何数值门槛都作为参考信号报告，而非等价性证明。
• 存根、警告、不稳定／已跳过的测试、缺失的平台、真实主机缺口和未经验证的边界仍清晰可见。
• 仅当对象台账、源测试用例台账、源资产台账、完整差异测试结果、Rust 义务以及必需的主机／非功能门槛均满足要求时，才发布模块完成声明。