acceptance-orchestrator

# Acceptance Orchestrator ## Overview Orchestrate coding work as a state machine that ends only when acceptance criteria are verified with evidence or the task is explicitly escalated. Core rule: **do not optimize for "code changed"; optimize for "DoD proven".** ## When to Use - The task already has an issue or clear acceptance criteria and should run end-to-end with minimal human re-intervention. - You need structured handoff across implementation, review, deployment, and final verification. - You want explicit stop conditions and escalation instead of silent partial completion. ## Required Sub-Skills - `create-issue-gate` - `closed-loop-delivery` - `verification-before-completion` Optional supporting skills: - `deploy-dev` - `pr-watch` - `pr-review-autopilot` - `git-ship` ## Inputs Require these inputs: - issue id or issue body - issue status - acceptance criteria (DoD) - target environment (`dev` default) Fixed defaults: - max iteration rounds = `2` - PR review polling = `3m -> 6m -> 10m` ## State Machine - `intake` - `issue-gated` - `executing` - `review-loop` - `deploy-verify` - `accepted` - `escalated` ## Workflow 1. **Intake** - Read issue and extract task goal + DoD. 2. **Issue gate** - Use `create-issue-gate` logic. - If issue is not `ready` or execution gate is not `allowed`, stop immediately. - Do not implement anything while issue remains `draft`. 3. **Execute** - Hand off to `closed-loop-delivery` for implementation and local verifi...