verified-delivery

已验证交付

通过一系列针对实时状态的关卡，将获授权的变更从实现推进到合并和合并后验证。运行下一步之前，必须根据仓库、PR、CI 和评审系统的实际状态验证每个关卡；每个关卡的判定都绑定到其验证所依据的确切头部 SHA。由于硬性限制（工具调用预算、上下文耗尽、工作者替换、会话中断）可能导致工作尚未到达交付边界就结束，因此此技能定义了持久的中断交接和恢复协议：将下一次重新进入视为同一指令的恢复，而不是要求用户重述指令。

授权边界

只有在用户明确指令中指定了变更内容及其授权的关卡时，才能继续交付。绝不要根据上下文、语气或不完整的交接推断权限。

操作前确认目标、范围和回滚路径。无需确认即可进行只读探索。

首次修改前必须应用此确认，恢复工作时也不例外。目标需指明仓库，以及存在时的 PR；范围需指明接下来获授权执行的关卡步骤；回滚路径需说明如何撤销或控制下一项修改。交接会记录此确认，但不会扩大授权范围。

• 指令需说明授权执行哪些关卡步骤（例如：开启 PR、在 CI 通过且评审要求满足时合并、验证合并后的状态）。
• 超出所述边界的步骤必须停在相应关卡，并准确报告缺少的授权。正确的做法是请用户明确作出新的决定，而不是擅自行动。
• 授权必须随工作一同传递：中断交接中会原文重述授权（见下文），以便恢复的会话继承相同边界，绝不扩大范围。

每个关卡都必须维持以下边界：

• 合并边界 — 只有在明确获准合并，且 CI 和评审关卡均针对待合并的确切头部通过时，才能合并。
• 评审边界 — 在有限的循环内处理评审反馈；绝不强行绕过尚未解决的评审异议。
• 安全边界 — CI 或评审发现的安全问题是关卡，而非警告；绝不能绕过、弱化问题，也不能通过抑制问题反复重试直至通过。
• 确切头部边界 — 所有关卡证据都绑定到确切的头部 SHA。头部发生变动后，之前的证据即失效，直至在新头部上重新验证。
• 无法收敛边界 — 在任一关卡经历三轮无法收敛的修复或评审后，停止并报告证据。
• 合并后验证边界 — 合并后确认合并状态之前，交付尚未完成。

交付关卡

按顺序执行各关卡。每个关卡都应先检查实时状态，再采取行动，最后记录绑定到当前头部 SHA 的证据。

1. 变更就绪 — 实现已完成，且本地验证在当前工作头部通过。
2. PR 已开启 — PR 已存在，并已记录其标识和头部 SHA。
3. CI 通过 — CI 在确切的 PR 头部 SHA 上通过。
4. 评审已满足 — 在确切的头部 SHA 上满足仓库策略的评审要求。
5. 合并 — 仅当第 3 和第 4 个关卡均针对确切头部通过，且合并属于获准范围时才能执行。
6. 合并后验证 — 在声称完成之前，确认合并后的状态（分支、PR 状态、合并后检查）。

中断交接

只要交付指令仍获授权且还有受门控步骤待完成，任何结束情况——会话结束、轮次结束、工作进程关闭或即将达到硬性限制——都必须先记录一份持久交接记录。若仍有步骤待完成却没有持久交接记录便结束，即使已清楚报告剩余步骤，也属于协议失败。报告剩余步骤绝不代表端到端指令已最终成功。

交接记录是以机器可读 JSON 格式持久存储的：默认存为仓库工作树中的文件 .verified-delivery/handoff.json，在本地从 Git 中排除，并在每次提交前确认为未跟踪文件；或者，在确认外部披露及其回滚路径后，将其存入 PR 描述中的机器可读围栏代码块；也可以在已配置时存入主机提供的持久存储。记录中必须注明其自身的存储位置。持久性意味着下次重新进入时，无需用户协助即可找到并读取该记录。

必需字段——schema（交接架构版本）、status（open 或 closed）、store（持久存储位置）、directive（用户指令原文）、authorization_boundary（已获授权的门控步骤，以及明确排除在范围之外的事项）、repository（远程身份）、pull_request（PR 身份或 null）、branch（交付分支）、head_sha（交接时的头部 SHA）、completed_steps（已完成的门控步骤及其绑定 SHA 的证据）、pending_steps（接下来已获授权的门控步骤，按顺序排列）、watchers（活跃监视器、进程或工作进程标识符；若没有则为空）、stop_reason（已观察到的中断类别）和 updated_at。完整的字段架构、持久性规则及示例见 references/interruption-handoff.md。

重新进入时恢复

重新进入是指在存在 status: open 的交接记录时，新的会话、轮次或工作进程触及该仓库。重新进入时，扫描文档中列出的存储位置。存在未关闭的交接记录意味着本次重新进入是恢复已记录的指令：不要要求用户重述或重复指令，也不要从头重新规划。

首要操作：只读核验实时状态。完成核验前不得进行任何修改。

1. 仓库——远程地址与交接记录中的 repository 一致；确认分支状态。
2. PR——确认其存在且处于打开状态，并将其头部 SHA 与交接记录中的 head_sha 进行比较。
3. CI——核验准确头部上的状态。
4. 审查——根据仓库策略核验准确头部上的状态。
5. 监视器——确认记录中的监视器、进程或工作进程是否仍在运行；绝不重复启动仍在运行的实例。

然后继续执行下一项已获授权的门控步骤。交接记录中的门控证据仅对其核验时对应的头部有效。如果头部已变更（新增提交、变基、强制推送），必须先协调：获取最新状态，在新头部上重新核验 CI 和审查，更新交接记录中的 head_sha，然后才能继续。只有完成核验后，才能进行修改——提交、推送、合并、评论。

在授权边界处停止

出现以下情况时，停止并报告确切原因，不再采取任何行动：

• 不存在指令，也没有未关闭的交接记录（将输入视为新请求，而非恢复操作）；
• 交接记录已损坏——无法解析、缺少必需字段或内部不一致；
• 交接记录已过时——PR 已关闭且未包含记录中的变更、变更已回滚、合并时头部冲突、仓库不匹配，或记录的授权已不再适用；如果合并已完成且符合预期，但仍有获授权的合并后核验待完成，则应协调后恢复；
• 下一步缺少授权，或授权含义不明确；
• 实时状态不明确——无法确定门控结果或合并状态。

绝不可从不完整或过时的交接记录中推断权限。停止报告应说明发现了什么、哪些内容无法核验，以及停止的确切原因。

结束端到端指令

• 已到达交付边界 — 结束交接（status: closed），并报告与该边界绑定的 SHA 证据。
• 仍有未完成步骤 — 先记录交接，然后发送一条消息结束，指出交接存储位置和明确的下一触发条件：下次重新进入时继续执行该指令。这是仍有未完成步骤时唯一可接受的结束方式。

如实说明运行时能力

任何技能内容都无法强制宿主运行时在达到硬性工具调用次数或上下文限制后继续运行，本协议也绝不对此作出承诺。它所保证的是可观察的行为：在限制生效前写入持久交接记录，并提供一条可在下次重新进入时根据已验证的实时状态继续执行的路径。不要声称运行时会自动恢复——下一触发条件是明确的重新进入。

完成与退出条件

满足以下任一条件时退出：

• 已到达交付边界，交接已结束，并且已报告证据；或
• 工作在某个边界处停止，已报告确切原因，并且——若仍有未完成步骤——存在一份开放的持久交接记录。

在任何关卡连续三次无法收敛后，停止并报告，不要继续循环。

不适用场景

不要将此技能用于不包含端到端交付指令的简单修复、重构或审查——常规变更工作流是更合适的替代方案。不要用它来设计发布流水线、发布列车或渐进式交付机制——请使用 发布工程。不要用它来捏造授权：此技能只执行用户明确授予的权限。

相关技能

• 发布工程 — 单项授权变更之外的发布流水线机制、渐进式交付和回滚规划。
• 验证方法论 — 各关卡实时状态检查的证据和判定标准。

参考文件

参考资料	何时加载
references/interruption-handoff.md	记录、查找、验证或协调中断交接时——字段架构、持久性规则和示例