subagent-driven-developmentlisted

# Subagent-Driven Development The controller never writes the code itself. It dispatches work to fresh subagents, one task at a time, and gates every result. This keeps the controller's context small (it holds the plan + the ledger, not the diffs) and makes each task independently verifiable. ## Loop 1. **Plan → ledger, verification-first.** Break the work into tasks. For each, decide **how it will be verified** (a command + the expected observation) before dispatching anyone — a task without a check is not yet planned. Record it on the ledger at creation time: `ledger_add(title, verify: {command, expect})`. The `verify` field is structural, not prose in a brief — it survives compaction, server restarts, and gets handed to the implementer and reviewer identically. The ledger is file-backed (under `.ideal-harness/`), so it survives both context compaction and an MCP-server restart — it is the controller's memory. Use the `scout` agent first when the plan needs locations ("where is X") — it returns a file:line table, not file dumps. 2. **Independent second opinion, for non-trivial plans.** Before dispatching any implementer, spawn `plan-critic` with the plan/ledger tasks — it runs at a different model tier (pinned in its own frontmatter) than the authoring conversation, so its critique is a genuinely different reasoning trace, not the same model re-reading its own output. Treat it like the reviewer gate: a blocker sends the plan back for revision; PASS or only minor issues l