用途：将编码任务端到端编排为状态机，仅在验收标准（DoD）被证据验证通过，或任务被明确升级时才结束。核心规则：不优化“代码已改”，只优化“DoD 已证明”。
必需子技能：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、executing、review-loop、deploy-verify、accepted、escalated。
工作流：接入时读取 issue 并提取任务目标与 DoD；issue 门禁使用 create-issue-gate 逻辑，若 issue 未就绪或执行门禁不允许则立即停止，issue 仍为草稿时不得实现任何内容；执行阶段交给 closed-loop-delivery 做实现与本地验证；评审循环中若 PR 反馈相关，按 3m、6m、10m 分批轮询，10m 轮后停止等待并统一处理所有可见评论；部署与运行时验证中，若 DoD 依赖运行时行为，默认只部署到 dev，并用真实日志/API/Lambda 行为验证而非假设；完成门禁要求在任何完成声明前执行 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”。