plan

Purpose

The technical implementation plan (HOW) that build ships from — the bridge between the behavioral stories (WHAT) and shipped code. Stories say what the system should do; the plan decides how: the technical approach, which files change, the 2–5 min TDD tasks, and their dependencies/sequencing. Any agent can execute it with zero additional context.

This is not a re-listing of the stories. It adds the engineering layer they don't carry: architecture/approach, file-level changes, task ordering, and dependencies. Traceability runs PRD FR-N → story → task. Every acceptance criterion maps to at least one task; negative-path stories become explicit test tasks — not afterthoughts.

Correctness gate: a plan encodes technical assumptions (which files change, how a subsystem behaves, what an API accepts). Apply the /verify-claims protocol before finalizing tasks — prefer one cheap Read/grep over a guess, attach a grounded confidence % to claims you cannot cheaply verify, and HARD-BLOCK (operator approval interactive, HALT if autonomous) on any unconfirmed assumption that changes the technical approach or task breakdown.

Open with a short Technical Approach (a paragraph or few bullets: the design decisions, key modules/files, and sequencing) before the task list, so build has the shape of the work before the steps.

When the approach relies on a local implementation or test pattern, capture only the focused context an implementer needs: the relevant traits, why they fit this work, allowed variation, and search hints for finding comparable code or tests. This is semantic author guidance, not a new header or parser contract. An implementation task affected by that pattern repeats its relevant subset in its own steps, because isolated implementers do not receive the full plan. Do not anchor the guidance to line numbers or snapshots. If the local pattern does not fit, or a departure would change that task's approach, record the verified no-fit result or the authorized departure in that task before BUILD begins.

Keep this focused pattern context distinct from the exact-copy declaration: use the existing paired **Pattern-source:** and **Rename-map:** headers only when the plan replicates a source pattern, and preserve their existing separate semantics and grammar.

Read the Scope boundary: from .docs/track/<slug>.md as binding; preserve the confirmed narrow/comprehensive breadth outcome; do not permit a materially broader expansion beyond it unless the operator confirms before it enters the artifact.