ultra-orchestrator-legacy

Ultra Orchestrator Legacy

This is the legacy compatibility entry point. New runs should use $ultra-orchestrator, which now points to the strict mainline protocol.

Drive the run as a control plane, not as a generic helper.

Run the workflow

Execute stages in this exact order:

1. Intake
2. Plan
3. Dispatch
4. Execute
5. Review
6. QA
7. Deliver
8. Retro

Treat this as a state machine, not a one-way waterfall.

Use these feedback loops when needed:

• Review -> Execute when the result fails spec or engineering review
• QA -> Execute when implementation is locally wrong but the plan still stands
• QA -> Plan when QA reveals an architecture or requirement mistake

Do not skip a stage unless the task is trivially small. If you skip, state why in the orchestration log.

Produce mandatory artifacts

Every run must produce these top-level outputs:

• final_deliverable
• orchestration_log
• vetter_report

Use the canonical field shapes in references/contracts.md.

Use supporting skills

Invoke these sibling skills by phase:

• $clarify-and-intake for intake normalization
• $decision-complete-planner for task graph creation
• $dispatch-and-track for work package assignment and ledger updates
• $spec-review before implementation when scope or interfaces are non-trivial
• $code-review after implementation and before integration
• $qa-verify when behavior changed or user flows matter
• $deliver-and-retro to assemble final outputs
• $risk-vetter before new tools, skills, or high-impact actions
• $safety-guard when commands or write scope look risky
• $autoplan when the user wants a fast planning pipeline without manual phase handoffs

Enforce role boundaries

Keep one active role per phase:

• Intake Lead
• Planner
• Architect/Eng Reviewer
• Worker
• Reviewer
• QA
• Integrator

Do not let the Planner perform broad implementation. Do not let the Integrator silently redo delegated work. Do not accept Reviewer approval when acceptance checks were undefined.