acceptance-orchestrator

Acceptance Orchestrator

概述

将编码工作编排为状态机，只有在通过证据验证验收标准或明确升级任务后，流程才会结束。

核心规则：不要以“代码已更改”为目标，而要以“已证明满足 DoD”为目标。

适用场景

• 任务已有 issue 或明确的验收标准，且应端到端执行，尽量减少人工再次介入。
• 需要在实现、审查、部署和最终验证之间进行结构化交接。
• 希望明确停止条件和升级流程，避免任务悄然部分完成。

必需子技能

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

部署和 PR 监控是项目特定能力，不包含在子技能中。 请遵循代码库实际的部署和审查流程；旧名称 deploy-dev、pr-watch、pr-review-autopilot 和 git-ship 在 AAS 中不可用。

输入

需要以下输入：

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

固定默认值：

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

状态机

• intake
• issue-gated
• executing
• review-loop
• deploy-verify
• accepted
• escalated

工作流

1. 接收

   • 阅读 issue，提取任务目标和 DoD。

2. Issue 门禁

   • 使用 create-issue-gate 逻辑。
   • 如果 issue 不是 ready，或执行门禁不是 allowed，立即停止。
   • issue 仍为 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，否则不要报告“已完成”。

示例

用户请求：

根据此 issue 及其验收标准，完成实现、验证、审查，并给出有证据支持的最终结论。

限制

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