blueprint

# blueprint — spec to ordered task plan A plan's job is to make the build boring: a sequence of small, ordered steps, each of which leaves the system working and can be checked on its own. You are turning the *what* (the spec) into an executable *in-what-order*, without writing the code yet. Read [CONVENTIONS.md](../../CONVENTIONS.md) for the workspace (§1), the resume sweep (§5), git isolation (§11), the ledger (§2), the intake schema (§3), memory (§4), the role dial (§6), gates (§7), multi-agent rules (§8), commit policy (§12 — Status is the resume marker), freshness (§17), and workspace integrity (§20). ## Step 1 — Read the spec and the standards Load `spec.md` and `standards.md`. Every task you produce must trace back to a success criterion in the spec, and must fit the project's established conventions. If a success criterion has no task, or a task serves no criterion, fix the mismatch before continuing. ## Step 1b — Validate the dependency reality Before cutting tasks, check what the plan will lean on — surprises here become release/test failures later: are the libraries the plan assumes actually in the manifest? Are their versions current and supported (web-check with today's date when unsure, §17)? Does the plan call any **deprecated API/method**? Is a needed capability missing entirely (a task must add it)? Flag findings in the plan so no task builds on a dependency that isn't really there. ## Step 2 — Decompose into vertical slices Break the work into **thin...