validate

验证

对一个已完成的候选版本进行全新判断，对照其原始验收标准，返回 PASS、FAIL 或 NOT_PROVEN，并提供逐项标准的证据，然后停止。 相邻主题：提供建议或再次审查请参阅 Review；核实某项陈述是否成立请参阅 Research。本文件包含判断所需的所有规则。链接文件，包括 RPI 边界和 机制，仅提供更深入的信息：如果无法读取其中任何文件，请依据本文件作出判断，并说明哪些文件无法读取。

决定判定结果的规则

• 作者不能签发具有约束力的 PASS，建议性发现也不能代替本判断。作者的总结、信心或保证都是需要核实的主张，而非证据；仅有解释不能证明问题。
• 每项标准都需要针对确切候选版本提供独立证据。无人证明的标准应列入 not_checked，且绝不能计入 PASS。
• 更改后的测试、容差、基准结果、抑制规则或验收文本，仍必须符合原始意图。通过削弱判定标准而取得的绿色结果，对于原本要证明的标准而言就是 FAIL，且该绿色结果不算证据。通过更改检查对象取得的绿色结果也同样如此：检测到测试或 CI 环境时行为不同的产品代码；新添空处理程序或丢弃错误，从而使失败路径不再报错；或将检查改为非阻断、跳过或绕过。每种情况都必须能从变更中看出理由，且仍服务于原始意图。
• 查阅检查收据；不要重新运行作者已针对确切对象运行的检查，也不要重新运行 CI 将运行的检查。仅对没有收据的关键风险主张重新执行检查。
• 必要的发现绝不能变成可选的注意事项或非目标。

按以下顺序作出判断：

1. 判断期间主体发生了变化、变更路径覆盖不完整，或作者与验证者的身份或新鲜度缺失、冲突或未经证明：NOT_PROVEN。
2. 已证明某项标准未通过，或某项变更超出范围：FAIL，即使其他标准尚未验证。
3. 任何范围内的标准缺少证据：NOT_PROVEN。
4. 每项标准都已通过证据验证、已检查的范围非空，且 not_checked 为空：PASS。

先确定意图

明确请求进行验证、作出验收判定或独立证明原始验收标准已满足，即选择此技能，即使请求措辞是“审查这个”。即使提供了标准，泛泛的检查或就绪情况问题也不属于此类：只需询问一次调用方要的是建议还是验收判定，然后等待。在此期间不得给出判定或就绪批准；意图不明确不等于 NOT_PROVEN 判定。共同路由说明： 建议或验收。

何时值得进行新的判断

在错误代价高昂时投入验证。对于普通变更，作者的检查和 CI 是把关环节，无需进行新的判断。以下情况使用 Validate：

• 调用方要求作出验收判定或提供独立证明；
• 变更一旦落地，错误就无法轻易撤销：已发布的版本或用户将遵循的说明、安全边界、数据或跟踪器状态遭到破坏、删除保护产品的检查；或
• 没有确定性检查覆盖发生变更的行为。

只判断一次。报告 NOT_PROVEN 及其缺口，然后停止；不要要求或等待另一轮。作者修复问题后，由相关检查确认修复结果；只有调用方再次要求时，才进行第二次判断。判断成本应只是工作成本的一小部分：当判断成本接近工作成本时，停止并报告尚未检查的内容。

主体

主体是一个非空的实现候选，在通过必要检查和已知修复后保持不变；只有在调用方要求审查文档时，计划、审计和审查才是主体。提供的验收失败证据意味着该主体判定为 FAIL；不要审查仍在变动的修复内容。判断开始时和结束时都要绑定其身份：

• 安装了 AgentOps 时：ao provenance manifest --root "$REPO_ROOT" --include "$CHANGED_PATH"，每个变更路径使用一个 --include。
• 在任何 Git 仓库中：提交 SHA（git rev-parse HEAD）和变更路径（git diff --name-only <base>...HEAD）；对于未提交的工作，记录 git status --porcelain 列表，并对每个变更文件计算 shasum -a 256。
• 如果主体仅由对话提供，例如粘贴的差异或对变更的描述，则主体就是所提供的内容；其中未展示的任何内容都未经验证。

请求的回顾应在代码判定之后进行，不能作为代码判定的证据。如果意图同时包含这两项，应分别判定代码标准，并在回顾完成前将整体请求视为未完成；不得提前给出整体 PASS。明确要求审查回顾时，应仅按该文档自身的范围进行判定。

身份与新鲜度

作者和验证者的身份必须明确且彼此不同；新鲜度必须由运行时或调用方证明，并注明证明者。证明是声明的信任事实，并非密码学隔离。在常规使用中，以下情况均可计入：

• **作者：**调用方提供的候选产出者身份，可以是个人、会话或 Agent ID，也可以是提交作者。
• **验证者：**如果运行时提供身份，则使用此上下文的运行时 ID，例如子 Agent 或会话 ID；否则，使用调度器为其持有的标识，例如启动时返回的 Agent ID，或在调用方为此次判定开启此对话时使用“此对话”。
• **新鲜度：**由运行时、调度器或调用方作出的声明，注明声明者，并说明此上下文未产出该候选，且获得了意图、主体和证据，而非作者的工作历史。调用方为此次判定开启此对话并提供候选时，调用方即为证明者。

角色名称、作者对话中的角色切换，或验证者为自己背书，均不计入。不得虚构身份。身份信息缺失会使结果变为 NOT_PROVEN；报告中仍须保留每项发现。

审查者

默认使用作者所属模型系列中的一位新鲜审查者：Codex/OpenAI 对应 Codex/OpenAI，Claude/Anthropic 对应 Claude/Anthropic；使用运行时配置的、具备相应能力的模型，除非指定了固定模型。提供特定于任务的意图、范围、确切主体和相关证据，不提供完整作者历史、期望的判定结果或其他审查者的结论。简洁的输入不得省略必要证据；当某项标准需要更多源材料时，应获取更多内容。

跨模型审查需明确启用：--cross-model [model] 是技能提示词选择，而非 AO 标志；它通过 model-dispatch 添加一位来自其他模型系列的新鲜审查者。无法执行必需审查环节时，应标记为 diversity_unsatisfied，并将组合请求判定为 NOT_PROVEN，即使另一环节已通过也不例外。无法提供可选的多样性时，应披露该情况，但不得因此抹去已有发现。已给出的 FAIL 和异议均须保留；投票或模型偏好都不能让存在分歧的结果变成 PASS，一致意见也不等于真相的证明。不设固定的 10 分钟上限；遵守调用方或原生机制的实际限制，不得续期。超时表示缺少判定，而非 FAIL。

判断

1. 绑定评审对象。通过核对调用方明确提出的意图、引用的证据以及所有变更路径，验证评审对象是否一致；完整性缺失即为 NOT_PROVEN。
2. 重新审视最初获认可的行为示例，包括对话或 bead 中的示例，并在确切的候选对象上检查每项可观察结果及其领域含义。新测试或重命名的概念不能替代未满足的场景。对照每项标准检查实际差异；文档中的发布或来源声明也需要可验证的证据。风险决定审查深度：验收、权限、测试与门禁、停止、披露、钩子和可执行控制都需要深入审阅，包括策略说明文档。风险未知意味着需要检查，而不是增加审查者。
3. 运行任何命令前，先对命令分类。重新生成、同步、格式化和 --force 都会修改评审对象，除非证明确实不会；只能在一次性副本或已提交的评审对象上运行，绝不可在待评审的树上运行。
4. 再次绑定评审对象；若不一致，即为 NOT_PROVEN。
5. 按下方格式尽快返回一个结果，然后停止。

报告

Verdict: PASS | FAIL | NOT_PROVEN
Subject: <manifest digest, or commit SHA and changed paths>; unchanged start to end: yes | no
Criteria:
  1. <criterion> - verified | failed | not verified - <evidence: file:line, receipt, observed output>
Findings: <class> - <what and where> - <consequence>   (or "none")
Notes (optional, do not change the verdict): <...>
Checked: <what was inspected, and how>
Not checked: <in-scope acceptance not verified>   (empty only for PASS)
Identity: author <id>; validator <id>; freshness attested by <runtime | caller>: <attester>

如果某项发现未满足验收标准，或会误导用户、破坏安装或 CLI，或移除产品防护措施，则属于问题；其他情况都是作者可以忽略的可选备注。为每项新发现提供简短且稳定的 class，再次出现时沿用，并根据前后证据说明它是既存、引入还是无法确定；仅凭计数和时间戳无法判定原因。保留此前的发现。not_checked 用于记录范围内但未经验证的验收项；其他限制应写在标准分析、声明的不在范围内事项或剩余风险说明中，绝不可为了获得 PASS 而隐去。验收范围内的交付内容，在有证据之前一律视为未经验证；绝不可为了获得 PASS 而删除该标准。机制说明介绍报告的适当详略程度，以及各类范围限制应写在何处。

Validate 是 verdict.v2 唯一的语义作者。 只有在调用方请求机器可读证据，或声明的使用方要求时，才通过 ao provenance store-verdict 持久化（见机制说明）；Go 验证的是结构和存储，而非真实性。否则，通过调用方现有的渠道返回结果，不创建隐式机器工件。Validate 不负责修复、重试、交付或跟踪器状态转换：已知问题交由作者直接修复，因果性停滞则遵循 RPI 单助手规则。