验收编排器

验收编排器 是做什么的？

概述

将编码工作编排为一个状态机，仅在验收标准有证据验证或任务被明确升级时才结束。

核心规则：不优化“代码已变更”，而优化“DoD已证明”。

何时使用

• 任务已有问题或明确的验收标准，需以最少人工干预端到端执行。
• 需要在实施、审查、部署和最终验证之间进行结构化交接。
• 需要明确的停止条件和升级机制，而不是无声的部分完成。

所需子技能

• create-issue-gate
• closed-loop-delivery
• verification-before-completion

可选支持技能：

• deploy-dev
• pr-watch
• pr-review-autopilot
• git-ship

输入

需要以下输入：

• 问题 ID 或问题正文
• 问题状态
• 验收标准（DoD）
• 目标环境（默认dev）

固定默认值：

• 最大迭代轮次 = 2
• PR 审查轮询间隔 = 3m -> 6m -> 10m

状态机

• intake（接收）
• issue-gated（问题筛选）
• executing（执行中）
• review-loop（审查循环）
• deploy-verify（部署验证）
• accepted（已接受）
• escalated（已升级）

工作流

1. 接收

   • 读取问题，提取任务目标及 DoD。

2. 问题筛选

   • 使用 create-issue-gate 逻辑。
   • 如果问题状态不是 ready 或执行门控未 allowed，立即停止。
   • 问题仍为 draft 时，不执行任何实现。

3. 执行

   • 移交给 closed-loop-delivery 进行实现和本地验证。

4. 审查循环

   • 如果 PR 反馈相关，按以下窗口批量轮询：
     • 等待 3m
     • 然后 6m
     • 然后 10m
   • 经过 10m 轮次后，停止等待并一起处理所有可见评论。

5. 部署与运行时验证

   • 如果 DoD 依赖于运行时行为，默认仅部署到 dev。
   • 使用真实的日志/API/Lambda 行为进行验证，而非假设。

6. 完成门控

   • 在心智声明完成之前，要求执行 verification-before-completion。
   • 没有新鲜证据，不得声称成功。

停止条件

只有当每个验收标准都有相应的证据时，才转入 accepted 状态。

当出现以下任一情况时，转入 escalated 状态：

• 经过 2 个完整轮次后 DoD 仍未通过
• 缺少密钥/权限/外部依赖导致进度受阻
• 任务需要生产操作或破坏性操作批准
• 审查指令冲突且无法同时满足

人工门控

在以下情况必须停止并等待人工确认：

• 生产/预发布部署超出了约定范围
• 破坏性 git/数据操作
• 计费或安全策略变更
• 缺少用户提供的验收标准

输出契约

报告状态时，必须包含以下内容：

• Status：intake / executing / accepted / escalated
• Acceptance Criteria：通过/未通过检查清单
• Evidence：命令、日志、API 结果或运行时证明
• Open Risks：仍不确定的事项
• Need Human Input：如果受阻，给出所需的最小下一步决策

除非状态为 accepted，否则不要报告“完成”。

限制

• 仅当任务明确符合上述范围时使用本技能。
• 不要将输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少必要的输入、权限、安全边界或成功标准，请停止并请求澄清。