重建就绪验证¶

从干净的检出（clean checkout）运行公开的静态分析旅程与合成报告评估器检查：

npm ci
npm run verify:readiness

该命令会构建可再分发的原生一致性夹具，通过公共 CLI 检查原生可执行文件，并通过 CLI 与 MCP 两种途径分析 JavaScript CLI 与 Electron 夹具源码。它会检查这两项应用分析所产生的 CLI/MCP Evidence 身份是否匹配。夹具应用不会被执行，原生 MCP 对等性也不在本次验证范围内。

此外，该命令还会评估一个完全合成的九阶段输入，并检查评估器的确定性、Evidence 篡改拒绝以及过期源摘要拒绝。这些检查针对的是报告评估本身；它们并不确立被测夹具的应用运行时行为、权限恢复、取消清理、行为等价性或重建闭环。该命令只会打印一条紧凑的 JSON 摘要。

设置 REA_READINESS_REPORT_PATH 以保留完整的机器可读报告：

REA_READINESS_REPORT_PATH=readiness-report.json npm run verify:readiness

CI 在 Linux 上运行该命令，发布紧凑摘要，并将完整报告作为 reconstruction-readiness 工件保留。

报告范围与归属¶

验证器以 npm run verify:readiness 的形式运行；它并未作为公共 CLI 命令或 MCP 工具公开。其报告区分两类验证：

• observed_journeys 保留实际的静态分析 Evidence 和观测到的 CLI/MCP 身份检查，以及它们的覆盖限制。
• evaluator_conformance 保留合成基线报告和评估器检查。其九阶段 pass 表示对所提供的合成观测结果的接受。

验证器的整体成功仅表示其列出的检查已通过。它并不是端到端的重建就绪判定。实际分析产生的 Evidence 不会被并入合成报告，也不会被用于闭合其检查项。

保留的工件现在使用 schema: "ReconstructionReadinessVerificationReport" 和 schema_version: 1。之前的无版本号工件就是九阶段评估器报告本身。使用方应读取这两个明确的部分；合成九阶段报告现在位于 evaluator_conformance.baseline_report。观测到的 CLI 与 MCP Evidence 分别保存在 observed_journeys.evidence_bundles 下的独立捆绑包中，以保留各个接口面的记录。

评估器、模式（schemas）、合成输入和语义测试位于 tests/conformance/readiness/report/ 目录下。它们属于开发期验证代码，不包含在编译后的运行时包中。评估器负责认证 Evidence 承诺（commitments），并检查所提供的观测结果之间的一致性；它不会独立地观测这些观测结果所描述的事件。

合成评估器阶段¶

在合成输入中，每个阶段和必需的检查都必须恰好出现一次，并链接到其内嵌捆绑包中的 Evidence。fail、unknown、unsupported、truncated 和 skipped 永远不会汇总为 pass。

失败关闭规则¶

在以下情况下，评估器会拒绝或不予通过合成报告：

• 受限能力遗漏了其有效的数值限制；
• 某个夹具未恰好具有一个兼容的已选工作流；
• 调用了不兼容或不可用的提供方；
• 类型化 CLI 失败却以零状态退出，或 MCP 失败却报告成功；
• 并发行为使用了全序比较；
• 截断、不稳定、权限不可用或矛盾被标记为等价；
• 蓄意的主要分歧未被定位；
• 矛盾 Evidence 或其受影响的比较缺失；
• 重建义务分类账不是 ready 状态、没有任何必需义务，或仍保留未归属/未验证的必需义务；
• 被拒绝或取消的授权却报告进程已启动，已取消清理的观测结果缺少诊断性 Evidence，或仍有归属资源残留；
• 重放不确定、未检测到篡改/过期，或期望的源摘要不一致。

每条发现（finding）都会标明其阶段、稳定的原因代码、Evidence ID 与详细信息。其中 capability_issue 和 next_action 字段会将不支持或失败的工作映射到负责的能力与补救措施，而不会声称所请求的分析已经运行。

结清历史根据所提供的最终账本描述一个固定的必需义务论域。其第一条记录确立起始未结数量，且不能声称出现新的转换。每个标记为 ready 的观测必须报告零个未结必需义务。标记为 open 或 failed 的观测必须报告一个正的未结必需义务数量。unknown 可以有零个未结义务，因为各种限制可能独立于该数量而阻止 ready 判定。每次减少都必须指明相应数量的互不相同且已验证的必需义务；一个义务不能在同一记录内或后续观测中再次计数。任何历史未结数量都不能超过账本的必需义务总数。所保留的历史仅与该账本做一致性检查，而不作为一系列完整历史账本加以认证。当这些检查失败时，原始记录仍保留在报告快照中。

对于每个操作和调用种类，每个保留的成功/错误码变体都必须同时出现在 CLI 和 MCP 中。重复的观测及其 Evidence 保留在报告快照中；漂移发现会引用完整组及其序列号。不声称重复次数相等或运行之间存在一一对应的配对关系：输入中没有身份标识可将单个 CLI 尝试与单个 MCP 尝试关联。传输状态差异会在每个观测上分别检查。

测试夹具¶

静态分析流程使用源代码自有、可再分发的测试夹具：

• build/conformance/c，由 tests/conformance/c/fixture.c 构建，具有稳定的符号和字符串；
• tests/conformance/readiness/javascript-cli，向静态重建暴露提示、备用屏幕行为、配置优先级、子进程、持久化、回环 HTTP 和信号拆除流程；
• tests/conformance/readiness/electron，向静态分析暴露 main、preload、renderer、utility、IPC、renderer 重启、被阻止的 shell 效果和 deep-link 表面。

独立的 RECONSTRUCTION_READINESS_EXAMPLE 提供合成的观测，用于不完整重建、损坏的运行时、权威性、比较、清理和结清。其语义测试保留了畸形 Evidence 拒绝、fail-closed 阶段结果、矛盾处理、CLI/MCP 重复结果以及结清历史一致性。请独立运行这些源代码测试：

npm run test:local -- tests/conformance/readiness/report/reconstructionReadiness.test.ts

通过评估器测试并不能确认真实提供方或测试夹具的运行时行为。对于这些声明，请使用适用的真实工具链验证通道。