planned-executionlisted

# Planned Execution The midweight lane: a spec becomes a plan an engineer with zero context could execute cold, and the plan becomes working software through a loop of fresh implementer subagents and two-stage review. Below this lane, implement directly with test-driven-development; above it, a governed series (keel, convoy) owns the work. This is a **rigid** skill: the plan contract and the review-loop order are bright lines, because the failure mode of plan-then-execute work is self-granted shortcuts — placeholder steps, skipped re-reviews, "close enough" spec compliance. ## The plan contract Write the plan assuming a skilled engineer who knows nothing about this codebase or problem domain. Save it where the project keeps plans (user preference wins; a dated file under the repo's plans convention is a sensible default). 1. **Map the file structure first.** Which files are created or modified and what each is responsible for — decomposition gets locked in here. One clear responsibility per file; follow existing codebase patterns. 2. **Bite-sized steps, one action each** (2–5 minutes): write the failing test — run it and watch it fail — write the minimal implementation — run to green — commit. The task granularity of test-driven-development, written down. 3. **Exact everything.** Exact file paths (`src/path/file.py:123-145` for modifications), complete code in every code step, exact commands with their expected output. 4. **No placeholders.** These a