prove

/prove 用于检查工单、规格说明或约定结果是否确实得到满足。它会验证一个固定的候选版本并报告差距；不会修复候选版本。对于有明确范围的修复，请使用 /repair-gaps，然后再次运行 /prove。 /implement-contract 用于开发候选版本；/review-implementation 则单独检查是否忠实遵循契约、范围是否合适以及工程质量如何。两者都不能替代验证。

开始验证前，请阅读验收契约协议。 该协议定义了规格范围、身份标识、证据和判定结果。遵循其中的 实用保障 和重点重新验证 规则：完整覆盖和针对当前候选版本做出的最新判定，并不要求穷尽检查或重复检查。

可选的 evidence-record v1 记录可通过证据 ID 和计算得出的 SHA-256 摘要引用，其确定性 Markdown 渲染结果也可嵌入 proof.md。条件允许时，请依据确切的验证上下文校验记录。记录为可选项，且有效记录本身绝不代表判定结果：各项要求的 proven、not proven 和 disproven 判定仍须由 /prove 写入 proof.md。如果没有宿主签发的命令／测试回执，请将自行运行命令的观察结果直接记录在 proof.md 中。

判定结果

• PROVEN：每项实质性要求都有可信证据，没有遗留契约差异，并且候选版本在验证期间保持不变。
• NOT PROVEN：某项已接受的要求缺少可信证据，仍存在实质性反例或契约差异，无法进行所需验证，或者候选版本身份不确定。可选建议和非阻塞限制本身不会阻止判定为 PROVEN。
• 明确的违规属于 disproven；证据不可用或结论不明确属于 not proven，而非 disproven。

规则

• 对照源内容和经授权的修订，核对带版本的验收契约。报告差异，但不要缩小或重写契约。
• 遵循协议中的验证和合并就绪规则，独立评估各项要求的证据，不要以 PR 的整体状态作为依据。无关的 CI 修复应交由 /fix-pr 处理，不要因此等待检查全部通过，也不要将其作为验证的前置条件。
• 尽可能使用干净的提交作为候选版本。除非能够确定其确切快照，否则工作区有未提交更改或仍在变化时，判定为 NOT PROVEN。
• 验证运行不得修改产品文件、候选版本或契约。如果发生任何此类更改，请返回 NOT PROVEN，并丢弃更改后状态的观察结果；修复应交由 /repair-gaps 处理，并须重新运行 /prove。
• 不要编辑产品代码、测试、CI 配置或验收契约。
• 不要提交、推送、发布或宣布修复完成。
• 优先通过公共接口和独立预言机获取行为证据。
• 仅运行某条路径、使用同义反复断言，或依赖无法失败的模拟对象的测试，不能证明所承诺的结果。
• 拒绝存根或仅适用于特定测试夹具的行为、仅由模拟替代的实现，以及绕过所需生产状态的证据。区分已证明的违规与证据薄弱、因而无法确定结果的检查。
• 评估完整的承诺能力。不要因为小型实现缺少非必要架构而予以扣分。对于未请求的范围，应依据契约排除项或源内容核对结果报告，而非依据架构偏好。

保留可复用的交付经验

如果本次运行揭示了持久、非显而易见且可能有助于未来交付工作的知识，请将其作为经验候选项纳入。没有内容也有效，并且优于凭空编造经验。候选项必须说明其适用范围、可复用的经验、提出该经验的具体证据，以及重要的不确定性。

当外层控制器要求结构化 JSON 时，将这些内容放入其 learning_candidates 数组。否则，在报告中添加简短的 ## Learning candidates 章节。

经验候选项是供 /retrospect 参考的线索，不是已采纳的建议。它们不得更改合约、需求 ID、阶段判定、范围、修复额度或权限。不得将其提升为项目规则或本技能的建议经验登记内容。

工作流

1. 确定合约

接受 .p2p/work/<slug>/contract.md，并按照协议的持久交接约定，查找其链接输入、candidate.json 和 .p2p/work/<slug>/ 中的报告。 阅读源内容、待处理修订、适用的上级约束，以及确切的验收合约修订版。保留所有需求 ID、边界、接缝、判定标准、未决问题和排除项。报告源内容中被遗漏、冲突或含糊的承诺，不要编辑合约。如果无法确定有版本记录的合约，则报告 NOT PROVEN，并移交给 /plan-acceptance；验证期间不得创建或修订合约。

对于切片子项，获取分解信息、贡献映射、父项快照和前置项结果。遵循协议中的父项／子项规则，协调当前父项与修订。根据适用的继承约束评判子项自身的合约；无关的兄弟功能不是子项要求。父项存在尚未解决的重大变更时，当前约定应判为 NOT PROVEN。记录并重新检查适用的父项标识及子项合约。对于父项验证，在同一个精确的集成候选项上评估所有父项义务和跨切片交互。历史子项验证和已关闭问题只能作为参考，不能汇总成父项判定。按照协议中 Epic 交付计划的规则，找回已批准的交付计划和父项完成条件。在精确的父项候选项中纳入独立交付的贡献以及所需的最终目标集成。即使所有子项都已通过，交互失败也意味着父项尚未通过验证。完全独立交付仍需进行综合父项验证，不能以空 PR 代替。仅目标位置发生变更，不会改变产品承诺，也不能证明另一个候选项。

2. 识别候选项

记录完整的提交 SHA 或精确快照、合约来源与修订版、已捕获的合约标识、相关目标或基准，以及验证环境。遵循协议的标识规则，并在检查开始前确认两个标识。根据 candidate.json 验证工作项哈希、绑定的父项／规格哈希和比较基准 SHA。比较 .p2p/ 之外的产品内容；本地 .p2p/ 记录更新保留原候选项标识，且不得进入 Git 历史记录。 如果无法确定任何标识，则返回 NOT PROVEN。 如果候选项或合约发生漂移，或观察结果无法关联到它们，则返回 NOT PROVEN。

对于已准入的交付，将验证绑定到经过验证的比较基准和精确候选项。之后仅目标位置发生变化，不会改变任一标识。验证不能证明该候选项与更新的目标提交兼容。

3. 映射并审查证据

对于每项需求，指出观察结果，以及用于判断其是否通过的独立判定标准。在约定的公共接缝检查现有测试、不变量、架构和命令。如果接缝或判定标准需要进行重大更改，则将该决定报告为差距，而不是悄然替换它。对于结果从未被断言的承诺，即便测试套件通过或 GitHub 标准已检查，也不能证明该承诺。

4. 检查实质性反例

针对实际变更及其重要衔接点，选择真实的失败案例。 空值／单个／多个、状态转换、重试、重启、授权和并发都是可考虑的示例， 但适用与否视情况而定，并非每项任务都必须逐一检查。 只有在敏感性实验能够消除实质性的不确定性时，才在与候选版本关联的 一次性副本中进行实验。当需求已有可信证据，且不再存在实质性反例或必要的未知项时， 就停止调查。 此后不要继续寻找假设性的改进。

5. 在不修改的情况下验证

运行能够证明需求的最少量高信号检查。将持久证据保存在候选版本之外，并将每个引用 关联到其观察结果、断言、命令和环境。保存的证明报告可根据协议的证据规则， 直接包含证据本身。之后再次检查 .p2p/、候选版本和已捕获契约之外的产品内容。绝不要在此技能中修复失败。报告 所需的最小完整修复，并指出受影响的需求 ID，供 /repair-gaps 使用。

如果已接受的契约或仓库标准有要求，或者无法通过有针对性的检查可信地覆盖实质性回归风险， 则运行完整测试套件。否则，采用足以满足要求的最少检查。不要因为变更看似很小就跳过 有约束力的检查。运行必要的长时间测试套件之前，先在确切的一次性工作区中验证设置： 解释器、导入、工作目录和候选版本身份。复用仍然有效的设置事实，不要重复无关的探测。 在源代码检出目录中进行的检查不能证明嵌套运行器的环境。记录实际命令、环境和结果； 设置失败不能作为候选版本行为的证据。重试前先纠正设置问题。不要并行启动 重复的完整测试套件。

局部修复后，在保留之前的观察结果前，先满足协议规定的针对性重新验证条件。独立检查 完整差异并运行受影响的检查；否则，重新验证所有内容。始终为确切的当前候选版本生成 一份涵盖所有需求的新报告。将可选建议与未解决的验收缺口及所需修复分开。

6. 报告

保存并重新读取 .p2p/work/<slug>/proof.md 和 evidence/ 中安全保留的证据，并根据协议的 历史记录规则保留之前的运行记录。允许将生成的记录保存在产品候选版本之外。只读 阶段上下文会返回确切文本，供外围工作流保存并重新读取。不能要求通过临时文件来恢复进度。 对于不适合保留的证据，保留安全且持久的引用、校验和、描述及访问限制；如果没有安全的 持久副本，则报告该证据不可用。

返回预期结果、契约核对情况、候选版本、环境、每项需求的判定结果、证据观察结果、 反例、候选版本稳定性及未解决的缺口。证明结果必须涵盖每个需求 ID，不得隐瞒任何未兑现的承诺。

输出

# <PROVEN | NOT PROVEN>: <source>

Requirements: <proven>/<total>
Counterexamples tested: <count>
Contract: <.p2p/work/<slug>/contract.md and exact revision>
Contract snapshot: <immutable reference or captured text and digest>
Parent context: <parent identity, snapshot, contribution mapping and prerequisites; omit if none>
Candidate: <commit or exact snapshot>
Candidate stability: <unchanged or NOT PROVEN>
Contract stability: <unchanged or NOT PROVEN>
Verification context: <environment>

## Outcome

<intended result and why it is or is not established>

## Requirement verdicts

| ID | Observation and oracle | Evidence reference | Verdict |
|---|---|---|---|
| R1 | <observed outcome and independent expected result> | <saved report section, artifact, or run; command and assertion> | proven |

## Unresolved gaps

- <requirement, counterexample, or limitation, or "None">

## Repairs needed

- <requirement ID and smallest complete repair, or "None">

Fresh `/prove` is required after any repair.
Refresh `/review-implementation` for the changed candidate as a separate phase.

报告结束后，以 Next steps: 收尾，并附上仅包含适用操作的编号列表（1.、2.……），按顺序排列，以便逐项引用。 对于 PROVEN，如果缺少审查，则给出 /review-implementation <saved candidate> against <comparison base>。当匹配的完整审查和证明均已存在时，说明该候选方案的验收证据已齐备。对于临近合并的现有 PR，给出 /merge-readiness <PR URL>; review <saved review>; proof <saved proof>。 对于尚未临近合并的现有 PR，提及已知的待处理门槛，并给出 /merge-readiness <PR URL>; review <saved review>; proof <saved proof>，供 PR 临近合并决策时使用；本次证明中不要评估 PR 的门槛。 如果不存在 PR，则说明除非希望发布，否则无需进一步操作；只有在希望发布时，才使用保存的引用给出此可选的发布预览命令：

/publish-pr <candidate handoff>; review <saved review>; proof <saved proof>; target <branch>; draft only

对于 NOT PROVEN，如需按范围修复，则给出 /repair-gaps <saved proof>；如协议缺失或已更改，则给出 /plan-acceptance <source>。如果候选方案的身份或证据不确定，请说明所需的确切身份或证据；重新运行检查时，请附上记录的命令和预期结果。