rpi

RPI

负责实现经授权的目标，直至完成。RPI（研究、规划、实现）是一次原生流程，而非固定阶段：使用原生编码 Agent 和 shell。BD 或调用方的跟踪工具负责工作与交接；Git 负责内容与交付。AgentOps 提供简短章程，并在出错代价高昂时提供一次新的判断，而不是充当调度器。

操作章程

1. 遵循现有已接受的目标、范围和实际限制。明确的变更无需 Plan、Recall 或 Learn 工作表。仅当不确定性可能改变实现或验收决策时，才解决它。
2. 采取能推进验收的最小行动。Plan 用于明确缺失的意图或修订已被证伪的方法。一旦实现者可以着手、验证者可以判断，就开始实现；不要继续改进计划。方法修订不得改变验收标准和授权范围。变更验收标准需要调用方授权。
3. 直接实现 Implement 并修复常见的已知缺陷。已知的测试失败需要修复并进行有区分度的检查，而不是再进入一个规划阶段、召集评审团或寻找帮手。
4. 编辑期间进行有针对性的检查，并在完成前通过所有必需的集成检查。仅在输入未变时复用检查结果；发生变更后，重新运行受影响的检查。为集成和修复预留资源。判断对象正在接受评审时，不要改动它。
5. 在出错代价高昂时投入验证。对于普通变更，检查和 CI 就是把关标准：完成即可。仅在调用方要求、变更落地后出错无法低成本撤销（例如已发布的版本、用户将遵循的说明、安全边界、销毁数据或跟踪工具状态、删除保护产品的检查），或没有确定性检查能覆盖变更行为时，才从一个全新的、与作者身份不同的上下文获取 Validate 结果。除非调用方选择增加评审方，否则使用作者所属的模型系列；明确要求的评审者仍须参与。
6. 只进行一轮。向验证者提供已接受的标准、确切的评审对象，以及在验证开始前写下的一个问题；绝不要提供作者的信心或期望的结论；验证者不重新运行检查。修复不符合已接受行为、可能误导用户、导致安装或 CLI 出问题，或会移除产品保护的内容；其余内容视为可选建议。通过检查确认每项修复，然后完成。修复不会启动另一轮评审；对于 NOT_PROVEN，应报告其缺失之处，而非继续追查。评审成本应远低于工作成本；当两者接近时，应停止并报告尚未检查的内容。
7. 在验收完成、任务取消、遭到拒绝、实际限制耗尽、等待调用方决策，或按下述求助后仍存在未解决的因果停滞时停止。如果已接受目标所依赖的某项选择超出现有授权范围（变更验收标准、扩大范围、采取授权未涵盖的不可逆步骤），那是调用方的决策，不属于停滞，因此不适用任何求助方式。完成独立且已授权的工作，然后停止并交由调用方决定，而不是等待；交接时须完整说明：是什么引发了该问题、你发现了什么、有哪些选项及其利弊，以及你的建议。只给出数量或链接不算交接；只要仍有待决选择，结果就绝不能是 done。相邻的改进并不意味着可以扩大目标。仅在有用时简要报告；不要将它们变成另一批工作。

委派与交接

当委派已获授权且有用时，为独立工作选择运行时的仅任务分派选项：在完整历史记录分支中使用简短提示词，仍会携带完整历史记录；提示词措辞既不能证明已隔离，也不能证明继承的上下文更小。提供已接受的意图和范围、确切主题、相关证据、剩余边界、结果的使用者以及检查责任归属；如有帮助，可恢复由作者直接修复。完成时，验证预期主题和所需结果；状态安静或不完整并不代表成功。对于委派工作，按照 Implement 的说明进行整合，并在现有交接中披露缺失或截断的证据。

因果停滞与边界

根据观察到的情况命名停滞，绝不要根据次数命名：

• 原因未知：检查失败，且其输出和差异都无法指出你能明确说出的更改或假设。
• 再次发生：修复后通过的检查，因同一原因再次失败。
• 毫无进展：自上次尝试以来，失败检查的输出和差异均未变化；或者自你上次查看以来，委派工作者最后观察到的活动没有变化。
• 目标错误：调用方的更正，或对已接受示例的检查，表明当前工作针对的内容并非验收要求。

对于上述四种情况，在授权和边界范围内，每个事件最多允许一个新的、范围明确的助手；若问题仍未解决，停滞的结果应写明观察到的事实。 向助手提供失败的假设、证据和一个可区分原因的问题。只有采用不同且可测试的方法才能继续；无帮助的回答会终止尝试。 不得串联多个助手，也不得重新命名事件。已知故障应直接修复。 遇到取消、拒绝或硬性时间／成本／配额耗尽时，不得寻求帮助。

遵守调用方／原生限制，包括明确的修复轮次上限。重试、压缩、助手和新主题都不会重置这些限制；单靠重试次数并不代表预算耗尽，提示词文本也不能证明存在原生强制执行机制。如果中断可能导致证据丢失，请在原生交接中保留已接受的意图、确切主题、检查结果、未解决原因、边界和助手使用情况。 外层目标指南仍为可选内容。

证据与边界

使用验证器时，应按照 Validate 的主题规则，绑定已接受的意图、完整的已更改路径、确切主题及其检查结果，包括未提交工作的状态列表和文件哈希。 如果仓库记录了 AgentOps 证据绑定，请运行 ao provenance evidence-orphans --root <repo> --changed <path>...，并披露其报告为孤立的验收证据。请求的证明应存放在调用方选定的 Git 外受保护存储中；保留旧有的 .agents/ 证据。Validate 中的判定顺序决定请求的绑定判定，作者无权签发该判定。

Memory、专家和运行时适配器均按需使用；无匹配和无更改都是有效结果。当授权、范围、证据或交付存在问题时，请阅读边界。不要为了完成普通更改而臆造运行时、隐藏的机器产物或工作流。

收尾

按以下格式报告。计划、活动、评审和已保存的页面不计入能力分数，未勾选的项目应如实报告，而不是继续验证的理由。除非调用方或声明的使用方要求，否则 rpi-report.v1 或 verdict.v2 等机器证据是可选的。如果未请求或未要求机器制品，则直接返回结果，无需创建制品。

Result:      done | stopped: <cancelled | refused | needs decision: <choice> | bound spent | stalled: <unknown cause | recurrence | no progress | wrong objective> - <observed fact>> | NOT_PLANNED | NOT_BUILT
Subject:     <commit, branch or diff identity>
Acceptance:  <criterion> -> <evidence: check, receipt or ref>, one line each
Checked:     <checks run on the final subject, with results>
Not checked: <what was not run or not covered, and why> | none
Judgment:    none (checks and CI gate an ordinary change) | <validator context id>: PASS | FAIL | NOT_PROVEN
Limits:      <material gaps; each open decision in full; departures from the literal ask, one line with its reason each; adjacent work noticed but not done> | none

偏离是指在授权范围内做出的、调用方会希望知晓的决定：与要求不同地构建、拒绝或质疑某项发现，或遵循运行中途的指示。常规修复无需列出；若没有此类决定，则不添加任何内容。

NOT_PLANNED（在出现可执行的切片前停止）和 NOT_BUILT（在出现候选变更前停止）描述的是进度，而非语义判定。

当请求 rpi-report.v1 时，如果 Judgment 在最终对象上运行过，status 就是验证器的判定。否则，按报告内容填写 NOT_PLANNED 或 NOT_BUILT；若对最终对象的检查证明某项标准未通过，则填写 FAIL；对于所有其他 Result（包括 done），填写 NOT_PROVEN；绝不能填写 PASS。填写 checked 和 not_checked；运行时未推导出的字段，以及未运行验证器时的两个判定字段，均填写 null。