Execute

Goal

Ship the plan. Treat the plan as the source of truth — direct, don't redesign.

Hard Rules

These hold at every step; a rule that binds one step lives with that step.

• Evidence before claims. Never report a task done without running its verification this turn and reading the output.
• Name a staged plan's task with its stage. Every task number your reply gives the user from a staged plan carries its stage, as in Task 14 (stage 2 of 3). The task that closes a stage also names its gate and that stage row's exit state, as in Task 18 (stage 2 of 3, gate): <exit state>. Ledger lines, briefs, and commit messages keep the bare task number.
• Destination frozen, road flexible. What the plan ships — each task's goal, its contract, the architecture — is frozen. The road there is not: when a bug, stale detail (renamed symbol, moved file), or failed assumption blocks a task, fix it as a detour — the smallest change that still ships exactly what the task promises — and log it on the ledger line. A fix that would change what ships is a reroute: stop and surface it with your recommendation. Off-path surprises (a pre-existing bug the task doesn't hit) stay retro entries, never side quests.
• Reviewers judge independently. Every review dispatch is cold: the reviewer pulls its own facts — it runs the diff, reads its task from the plan, reads the implementer's evidence from the report file, and applies the fixed rubric file. Your dispatch hands it only pointers and the BASE SHA; anything more — a description or defense of the diff, a reproduced or annotated rubric — pre-judges the review you asked for.
• Verify once; trust the evidence. A task's RED→GREEN evidence (the implementer's per-behavior output) is the suite's authoritative run for that task; the final gate's plan-and-coverage walk is the single authoritative re-run across the whole diff.
• A stated dispatch binds you to spawn. The moment your output says a task gets a subagent — or the run's chosen shape says so — your next action is that spawn, never the work done inline (the pre-flight roster is not itself the dispatch). If main-thread work is the right call, say you're staying on-thread and why (for a shape change, re-state the shape) instead of announcing a dispatch.
• A dispatch is a blocking call. From spawn to return the subagent owns the work: end your turn at the spawn, let its return notification resume you, and make reading that return your next action. Everything else — the next task, edits near its files, a peek at its progress — queues behind that return. In parallel mode the batch of spawns goes out in one message and blocks as one; every return is read before anything else moves. When a subagent is out past the point you expected it back, reconcile against durable state — git log since BASE, the ledger, its report file on disk — then resume the agent or surface the stall with your recommendation.
• Oscillation stops the loop. A review round that demands reversing what a prior round required is oscillation, not progress — never flip the code blind; stop and surface both verdicts to the user with your recommendation.
• Never force-push, amend earlier commits, rewrite history, or delete a branch without explicit approval.