验收编排器
Acceptance Orchestrator (验收编排器)
概述
将编码工作编排为一个状态机，仅在验收标准通过证据验证或任务被明确升级（escalated）时才结束。
核心原则：不要为了“代码已更改”而优化；要为了“DoD（完成定义）已证明”而优化。
使用场景
- 任务已有 Issue 或明确的验收标准，且应在极少人工干预下端到端运行。
- 需要在实现、评审、部署和最终验证之间进行结构化交接。
- 需要明确的停止条件和升级机制，而非静默的局部完成。
必需子技能
create-issue-gate
closed-loop-delivery
verification-before-completion
可选支持技能：
deploy-dev
pr-watch
pr-review-autopilot
git-ship
输入要求
需要以下输入：
- Issue ID 或 Issue 正文
- Issue 状态
- 验收标准 (DoD)
- 目标环境（默认为
dev）
固定默认值：
- 最大迭代轮数 =
2
- PR 评审轮询间隔 =
3m -> 6m -> 10m
状态机
intake(接收)
issue-gated(Issue 门控)
executing(执行中)
review-loop(评审循环)
deploy-verify(部署验证)
accepted(已验收)
escalated(已升级)
工作流
1. 接收 (Intake)
- 读取 Issue 并提取任务目标 + DoD。
2. Issue 门控 (Issue gate)
- 使用 create-issue-gate 逻辑。
- 如果 Issue 状态不是 ready 或执行门控未 allowed，立即停止。
- 在 Issue 仍为 draft 状态时，不要进行任何实现。
3. 执行 (Execute)
- 交接给 closed-loop-delivery 进行实现和本地验证。
4. 评审循环 (Review loop)
- 如果 PR 反馈相关，按以下时间窗口批量轮询：
- 等待 3m
- 然后 6m
- 然后 10m
- 在 10m 轮次后，停止等待并统一处理所有可见评论。
5. 部署与运行时验证 (Deploy and runtime verification)
- 如果 DoD 依赖于运行时行为，默认仅部署到 dev 环境。
- 通过真实的日志/API/Lambda 行为进行验证，而非凭假设。
6. 完成门控 (Completion gate)
- 在声明完成之前，必须执行 verification-before-completion。
- 没有最新的证据，不得声明成功。
停止条件
仅当每个验收标准都有相应的证据匹配时，才转入 accepted 状态。
当发生以下任何情况时，转入 escalated 状态：
- 经过
2轮完整迭代后 DoD 仍未通过
- 缺失密钥/权限/外部依赖导致进度阻塞
- 任务需要生产环境操作或破坏性操作审批
- 评审指令冲突且无法同时满足
人工门控
在以下情况必须停止并请求人工确认：
- 超出约定范围的 prod/stage 部署
- 破坏性的 git/数据操作
- 计费或安全态势变更
- 缺失用户提供的验收标准
输出契约
报告状态时，必须包含：
Status: intake / executing / accepted / escalated
Acceptance Criteria: 通过/失败检查清单
Evidence: 命令、日志、API 结果或运行时证明
Open Risks: 任何仍不确定的事项
Need Human Input: 如果被阻塞，请列出下一个最小决策点
除非状态为 accepted，否则不要报告为 "done"。
局限性
- 仅在任务明确符合上述范围时使用此技能。
- 不要将输出视为特定环境验证、测试或专家评审的替代方案。
- 停止
