implement

实现

实现已接受的结果。直接修复已知的常见缺陷。沿用现有意图；明确的编辑无需先制定计划。实现工作负责源代码变更和事实核查。通过 Git 读取已更改的路径（git status --porcelain、 git diff --name-only <base>），切勿凭记忆填写； ao provenance manifest --root <repo> 为每个声明的路径各传入一个 --include <path>，只对声明的路径计算摘要，且不运行 Git。照抄命令输出中的检查结果。

决定结果的规则

• 修复根因，而非判断标准。 切勿放宽断言、容差、 基准文件、测试夹具或抑制规则，也不要用模拟对象或占位内容替代，以使检查通过；也不要更改检查针对的对象：在测试或 CI 中行为不同的代码、新增的静默失败路径，或变为非阻塞或被跳过的检查。针对已接受行为失败的检查，表明产品存在缺陷；更改检查所接受的内容属于验收变更，需要调用方授权。
• 编辑前先找出实际使用方。 搜索每个已编辑的函数、类型、路径、格式或消息的调用方、读取方、脚本、文档和测试。对每一项说明变更是否影响它，以及由哪项检查覆盖。退役或重命名时，使用方还包括安装、查找和旧名称调用；保留历史来源记录。如果被替换的接口从未合并或发布，且所有使用方更新均在范围内，则在同一变更中更新它们并删除旧版本，不提供别名或垫片；否则保持旧版本可用，或报告此事。
• 明确能区分行为的检查。 行为变更应保留预期缺失行为的 RED：指出编辑前失败、编辑后通过的检查（见 测试的证明规则），并指出覆盖每个受影响使用方的检查。
• 只报告实际运行的内容。 给出准确的命令和结果。列出所有未运行或无法运行的检查，并注明未运行。绝不要把未运行的工作称为已验证、已修复或通过。命令一旦运行就可能输出内容，因此构建命令时要保护秘密：凭证保留在环境中，可能包含令牌的输出写入文件，只展示已脱敏的摘录。

更改公开的失败路径时，保留其原生失败信号，并检查恢复建议是否与已完成的工作一致。对于不确定的写入结果或无人值守的调用方，只使用测试的错误恢复方法中相关的检查。

对于已接受的有界捷径、反馈或变更引入的缺陷、经授权的提交、历史重写或合并冲突、依赖升级、移除、受阻操作、读取其他工具状态得出的决策，或自身不确定的写入，只使用变更安全方法中匹配的方法。这些方法保留现有授权；不会授予任何新操作权限。

对于经授权的服务操作，只加载运维方法中的相关流程（可靠性、交付、事件恢复、韧性、运维负担）；普通编辑无需经过运维阶段。

工作流

1. 在首次写入前，阅读意图、验收标准、范围和仓库边界；复用已加载的约定。选择 RPI 时，适用 RPI 边界；由调用方选择的阶段跟踪遵循会话关联参考。记录修订版本以及已修改、已暂存或未跟踪的文件；只报告自己造成的变更，若要编辑包含他人修改的文件，先征求调用方同意。
2. 原样保留已接受的行为示例。在符号和测试中使用仓库的领域名称；通过相关接口检查可观察结果。编辑前后都运行适用范围最小的检查。纯重构、迁移位置或文档修改可以有真实且通过的基线。优先使用现有测试或有针对性的小型探测。
3. 只做范围内最小的变更。修复发现或检查问题时，保留使用方现有的输入选择；修复错误路径不等于授权扩大扫描范围。需要排除内容时，使用负向对照。批量传播前，先根据现有约束检查一个代表性变更；大范围重新生成前，先检查编写好的源文件集合。跨文件脚本编辑前，先确认每个锚点都恰好匹配一次；若匹配为零次或多次，则不写入任何内容，并重新推导锚点。直接修复已知故障，并通过检查验证确切结果；修复不会启动新一轮审查。被证伪的假设可以在范围内改变方案；只有存在重大不确定性时才使用 Plan。
4. 阅读仓库实际的检查步骤，包括检测工具和环境，不要凭记忆重构步骤。在大范围集成前运行定向测试和 lint／静态检查，并在集成时运行所需的完整检查。仅当源代码、工具和相关环境一致时，才复用针对完全相同输入的检查记录。既不绕过必需的钩子，也不为重命名检查记录而重放检查。必需 CI 作业中已知的故障应在运行结束前处理：在范围内修复，保留故障对象的证据，并重新运行受影响的检查。待处理作业不代表成功。新检查、钩子或 lint 规则只有在汇总命令或 CI 运行时才算生效（Git 钩子需要安装路径；.git/hooks 不会被克隆），且必须能被故意引入的违规触发失败；否则在 gaps 下列出，注明尚未接入。只有能够证明本地已在某端口运行的服务确实服务于此检出版本时，才可使用；只停止自己启动的进程。
5. 在验收标准保持通过的前提下进行重构。交接前，根据原始意图检查已修改的测试、夹具、黄金文件、容差、抑制项和规范文本。直接从原始来源重新阅读该意图，不要依赖压缩后的摘要，并根据该意图检查完整差异，包括未跟踪文件。清理已放弃方案的残留、临时探测（使用一个共享标记即可通过一次搜索证明已全部清除）以及检查产生的文件；无法说明用途的路径，应在 gaps 下列出，作为范围修订。
6. 由运行时推导实际变更路径和内容标识。等待集成的委派增量，应在现有交接内容中返回确切提交或运行时推导的内容摘要、作者上下文 ID 和检查事实。从运行时公开的会话、子 Agent 或线程 ID 中复制该 ID；若 ID 由调用方提供，则标注为其提供；否则报告为未知，绝不可编造。集成方在作出判断前，应针对完整的最终对象推导 subject-manifest.v1（AgentOps 架构：subject-manifest.v1.schema.json，仅适用于 AgentOps 源码检出）；需独立判定的增量也需要自己的清单。不要仅因工作是委派的就同时生成两份清单。如果仓库记录了 AgentOps 证据绑定，还应运行 ao provenance evidence-orphans --root <repo-root>，并为每个推导出的路径分别使用一个 --changed <path>（该命令仅提供参考）；保留实际输出，并在修复后刷新被标记的绑定；若没有 ao，则在 not run 下列出。
7. 按下方格式返回交接，然后停止。

交接

完整日志保留在其来源处；不要重复列出清单或状态文档。

changed:   <runtime-derived paths>; identity: <commit or content digests>
author:    <runtime session/subagent/thread ID, "ID (supplied)" or "unknown">; when an integrator or fresh read follows
checks:    <exact command> -> <result>, one per line; before and after for a behavioral change
not run:   <check> -> <reason>; "none" only when every relevant check ran
consumers: <file:line> -> <covering check, or "uncovered">
gaps:      <missing or truncated evidence, known failures, scope amendments needed>
cause:     <defect repairs only: trigger -> mechanism -> symptom at file:line; sites left as follow-up>

报告未覆盖的实际使用方，以便调用方修订范围，并继续独立的授权工作。只有当某个可逆的实现选择存在调用方可能希望更改、且会造成实质影响的替代方案时，才披露该选择；在交接中说明选择、替代方案和理由，不必使用固定模板。已纳入范围的生成配套内容无需新的批准；更改已接受的方向、行为或验收要求，始终需要调用方授权。

诊断、脚手架与委派工作

遇到原因不明的故障，修复前请遵循诊断循环：确认失败的运行确实执行了你认为的代码，根据观察确定主要原因，指出最有力的竞争解释，并测试一项二者预测不同的结果。同一文件还包含针对竞态、状态泄漏、挂起、回归和跨组件故障的实验方法。

需要搭建脚手架时，从仓库现有布局（新项目则采用生态系统的标准布局）和一个可运行的垂直切片着手；避免使用占位式成功路径，也不要为一次性操作引入新框架。对于安装程序、面向 Agent 的工具服务或带有本地状态的 Rust CLI，请参阅面向 Agent 的工具脚手架。

优先在当前会话中执行。如果获准委派且确有帮助，请按 Agent Native 的说明，让并行编写者各自负责互不重叠且相互隔离的工作；共享生成器和集成工作应串行进行。向每个工作单元提供其意图、验收标准、范围和评审负责人，然后整合其确切内容并核实事实。选定的一轮工作以调用方要求的结果收尾；不要擅自新增一轮。对整合后的候选成果进行一次新的评审，即可覆盖尚未评判的增量；若集成者负责该评审，工作者应直接交接，不要再委托他人评审。保留任何另有要求的工作单元评判；进程成功退出不等于语义上的 PASS。

明确要求的一次性适配器应将每项给定操作分发一次，报告输出或错误，然后停止；不得包含调度器、重试控制器或存储。使用试运行或固定测试数据展示其分发次数和失败报告方式。工厂模式须由调用方选择。

收尾

专家只提供建议；已知缺陷仍属于实现工作。只有真正的因果性停滞，才允许依据 RPI 的停滞规则安排一位有明确限制的新助手；重试不会延长任何限制。

返回事实，不要给出语义上的 PASS。仅实现的交接不授权执行 Git、跟踪器或交付状态转换；现有的调用方授权仍可使用。完整结果请求应以完成检查和 CI 收尾；只有符合 Validate 的触发条件时，才继续进行一次新的独立评判。成功意味着行为可用且有可用证据，而不是日志或进程产物的数量。