spec-to-taskslisted

# Spec to Tasks 1. Inspect the applicable instructions, source specification, repository structure, relevant execution paths, tests, configuration, and version constraints before planning. Do not invent files, APIs, commands, or architecture. Read [planning principles](references/planning-principles.md). 2. State the intended outcome, current state, explicit scope, non-goals, constraints, acceptance criteria, and material assumptions. Return unresolved product decisions to clarification instead of hiding them inside tasks. 3. Identify the smallest sufficient approach. Compare alternatives only when they differ materially, choose one, and record the decisive trade-off. Exclude speculative flexibility, unrelated cleanup, and work not required for the outcome. 4. Map requirements and risks to affected capabilities, contracts, data, integrations, runtime paths, files or symbols when known, compatibility obligations, and operational concerns. 5. Organize work into outcome-based milestones, then slice each milestone into vertical, independently understandable tasks. Keep every task large enough to produce a meaningful verified result and small enough for one focused implementation session. 6. Give every task one outcome, bounded scope, prerequisites, affected boundaries, implementation intent, acceptance criteria, and concrete validation evidence. Add migration, rollout, rollback, observability, documentation, or cleanup only when the task requires them. 7. Record only real blocki