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".

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 verification.

4. Review loop

   • If PR feedback is relevant, batch polling windows as:
     • wait 3m
     • then 6m
     • then 10m
   • After the 10m round, stop waiting and process all visible comments together.

5. Deploy and runtime verification

   • If DoD depends on runtime behavior, deploy only to dev by default.
   • Verify with real logs/API/Lambda behavior, not assumptions.

6. Completion gate

   • Before any claim of completion, require verification-before-completion.
   • No success claim without fresh evidence.

Stop Conditions

Move to accepted only when every acceptance criterion has matching evidence.

Move to escalated when any of these happen:

• DoD still fails after 2 full rounds
• missing secrets/permissions/external dependency blocks progress
• task needs production action or destructive operation approval
• review instructions conflict and cannot both be satisfied

Human Gates

Always stop for human confirmation on:

• prod/stage deploys beyond agreed scope
• destructive git/data operations
• billing or security posture changes
• missing user-provided acceptance criteria

Output Contract

When reporting status, always include:

• Status: intake / executing / accepted / escalated
• Acceptance Criteria: pass/fail checklist
• Evidence: commands, logs, API results, or runtime proof
• Open Risks: anything still uncertain
• Need Human Input: smallest next decision, if blocked

Do not report "done" unless status is accepted.

AGI Framework Integration

Adapted for @techwavedev/agi-agent-kit Original source: antigravity-awesome-skills

Memory-First Protocol

Retrieve prior deployment configurations, rollback procedures, and incident post-mortems. Avoid re-discovering infrastructure patterns.

# Check for prior infrastructure context before starting
python3 execution/memory_manager.py auto --query "deployment configuration and patterns for Acceptance Orchestrator"

Storing Results

After completing work, store infrastructure decisions for future sessions:

python3 execution/memory_manager.py store \
  --content "Deployment pipeline: configured blue-green deployment with health checks on port 8080" \
  --type technical --project <project> \
  --tags acceptance-orchestrator devops

Multi-Agent Collaboration

Broadcast deployment changes so frontend and backend agents update their configurations accordingly.

python3 execution/cross_agent_context.py store \
  --agent "<your-agent>" \
  --action "Deployed infrastructure changes — updated CI/CD pipeline with new health check endpoints" \
  --project <project>

Playbook Integration

Use the ship-saas-mvp or full-stack-deploy playbook to sequence this skill with testing, documentation, and deployment verification.