deliver-spec

交付规范

核心原则

交付一个获批的结果，并进行适度验证和独立的最终审查。负责人负责架构、集成和交付，默认直接实施紧密耦合或需要按顺序完成的工作。只有在独立工作、隔离或专业调查能够证明其开销合理时才进行委派；仅仅有可用的工作者容量并不足以构成委派理由。明确保留所有权、外部操作权限、执行预算和针对具体调用的合并权限。绝不从 Project 队列中选择工作。

选择模式

对于处于活跃状态的 run-github-project 控制器已验证的工单交接，请阅读 Project 控制器交接，并遵循其中的流程，而非以下独立审批、合并和超时规则。 Project 控制器保留所有共享状态和合并权限。 对于直接指定规范的请求，请使用以下独立流程；如果某个 Project 运行已拥有该问题，请将其交还给该控制器。

流程

1. 从最新状态确认具名来源、代码仓库、已批准的约定，以及任何现有分支或 PR。恢复工作时，先核对 PR、确切的 head、检查结果、反馈和授权，再采取行动。对于集成修订，在使用任何增量之前，先按照 Evidence and review 验证已安装的规划器约定和保留的工作。
2. 规划：复用当前的 to-plan 计划；否则调用 to-plan（对于本地来源，使用对话模式），并遵循其就绪和发布关卡。符合快速路径条件的来源改用该路径。对于缺少 ready-for-agent 的 GitHub issue，先使用 triage，并等待其批准结果；不要自行更改标签。本地来源跳过 triage，但需要利益相关方明确批准。对于已批准、没有计划且不符合快速路径条件的本地来源，初始路线应指定为对话模式的 to-plan，包括回答恢复问题时。批准仅涵盖已接受的约定，以及其中明确记录的当前资格例外；不要推断额外尝试次数或授权。
3. 一次性核实范围和边界。已核实的交接授权在隔离的检出环境中继续进行范围内的实现、测试和修复；无需逐文件或逐阶段的许可包。复用有效的计划、审查和检查。只有在继续之前必须解决具体风险时，才要求提前进行独立审查，例如在观察输出前冻结实验标签；与此无关的工作，例如工具开发，应并行开展，而不是等到之后再做。遵守要求的交付物以及数据处理和支出限制；不要构建未经请求的通用基础设施。根据运行时元数据确认审查者的能力，绝不要仅为确认能力而另行启动审查者。如果无法进行最终审查，应报告此交付阻碍，不得免除审查。
4. 对于单人或委派工作、所有权、隔离和恢复，遵循随附的实现流程。作为负责人实现顺序执行或紧密耦合的切片，不要交由工作者处理。遵循注明的代码仓库或用户测试策略。实现之前先核对保留的工作；绝不要为了路由而重做已接受的工作。遵循 Evidence and review 中的测试、修正和单一可复用交付记录要求。如果来源要求异步或持久的实时资格验证，在尝试和恢复工作之前，遵循 Live qualification and failure recovery；不要将其用于常规离线工作。
5. 自行审查集成后的候选版本，运行受影响的本地检查和必需的推送前检查，然后为每个交付 PR 指定一位独立的只读审查者，并提供已批准的来源、代码仓库规范、确切且干净的候选 head 及其验证证据。使用全新的 Agent，不得写入任何内容，也不得继承实现上下文。复用有效的独立审查覆盖；不要重复规划或实现审查。要求提供有证据支持的发现，并给出 ship、fix-first 或 rethink 结论。遵守明确调用的提供方约定，并报告缺失的覆盖。将发现反馈给实现负责人；在修复后的 head 上，更新受影响的检查，并审查变更范围及其交互。只有当影响无法限定或明确要求更广范围时，才扩大审查。推送前，确认最终干净 head 的整体审查覆盖完整。如果已完成且经过验证的工作使最终差异为空，则报告 no-change；初始差异为空不属于 no-change。否则创建一个草稿 PR，或复用现有 PR，并确认其 head 与已审查的 head 一致。遵循 PR review timing：CI 运行期间启动适用的外部审查，并在允许时使用已验证的草稿支持或更早的 PR 就绪状态。所有最终 head 关卡通过前，交付状态保持为 pending。仅对已核实的 GitHub issue 使用关闭链接。
6. shepherd 负责 CI、反馈和所有 PR 操作。修复工作由其实现负责人继续负责；推送前，须在修复后的 head 上更新受影响的检查，并进行有针对性的审查。若常规实现或测试夹具修正不改变要求、覆盖范围、架构和授权，则可依据现有批准继续进行；应简要记录。重大变更须先取得相应决策并重新规划，再继续受影响的工作。资格验证弱化或权限扩大均属于重大变更。只有在本次调用的明确授权仍然有效时才可合并。若待处理关卡约 30 分钟后仍未通过，应交接确切的待处理检查、反馈、PR 和 head，以便之后恢复工作。

完成门槛

仅当最终 head 通过必需的检查和评审，所有问题均已解决，且证据适用于该干净 head 时，才报告 ready； 仅在读取并确认已授权合并后，才报告 merged； 仅当实现和验证完成，且最终 diff 为空时，才报告 no-change；存在尚未完成的门槛时，报告 pending 并列出这些门槛；其他情况则报告 blocked，并说明所需的决策或能力。在 pending 或 blocked 的运行中保留 PR 和源指针。不要将先前的 head 报告为已评审结果。