Plan: the agent proposes, the engineer disposes.
The approved chess spec reaches a planner agent, which breaks it into tasks in Asana. Nothing gets built until the engineer approves the plan — and the engineer can veto any task that breaks the spec or the team's steering rules.
How the engineer's veto works
-
1
Veto with a reason
The engineer marks a task ✋ Vetoed and ties the reason to the spec or the steering files — "FR-4 says the server owns the clock", not "I don't like it".
-
2
The gate closes
Any veto or coverage gap flips the plan to Changes requested. Build stays locked: no coder agent gets a task from a plan that isn't approved.
-
3
The agent replans
The planner agent must replace vetoed tasks and fill every gap, then resubmit a new version. The vetoed version stays visible in the history.
-
4
Only approval unlocks Build
Explicit sign-off assigns the tasks to coder agents. Repeated vetoes become proposed steering rules, so the next plan doesn't make the same mistake.
Asana is used here as the example planning tool; the same gate works with Jira, Linear or GitHub Projects.