implementation-planninglisted

# Implementation Planning Write for a capable engineer who does not know this repository or the hidden assumptions behind the request. A plan is useful only when another agent can execute it without reconstructing the design from hints. ## Plan structure Before listing tasks, record: - goal and user-visible outcome; - architecture and ownership boundaries; - constraints, compatibility promises, and non-goals; - files to create, modify, or delete; - test and evidence strategy; - rollback and migration safety. Use [plan-template.md](references/plan-template.md) for the complete skeleton. ## Task rules Break the work into thin, independently testable slices. Each task names: 1. exact files and responsibilities; 2. inputs, outputs, and interfaces consumed or produced; 3. the failing or observable check first; 4. the smallest implementation step; 5. the focused command and expected result; 6. the next checkpoint or integration dependency. Prefer one behavior per task. Keep setup with the first deliverable that needs it. Do not create a task for speculative cleanup. ## Plan quality gate Before handing off: - trace every design requirement to a task; - search for placeholders such as `TBD`, `TODO`, or “add appropriate…”; - check names and types across task boundaries; - confirm commands exist in the repository; - identify what the plan cannot prove locally. Hand the completed plan to `plan-execution` or `subagent-driven-development`. Do not claim the feature is implemen