design-and-planlisted

# Design and Plan Keep a mechanical edit, routine status update, or settled implementation path inline unless it exposes a new requirement or material tradeoff. ## Understand the system Read repository instructions and relevant code. Establish entry points, callers, blast radius, the nearest convention-setting sibling, test coverage, and any unread area that could change the decision. Resolve factual prerequisites before preference or policy questions. Present competing sketches only for a high-impact, underconstrained, or hard-to-reverse design. Recommend one and state its tradeoff. Mark assumptions and blockers. Model a domain term when repeated state branches or synchronized booleans obscure one concept. Do not force a glossary or ADR. ## Specify observable behavior For a non-trivial behavior change, state intent, scope, non-goals, and implementation-independent requirements before the plan. Give each requirement concrete scenarios and an acceptance oracle. Map each requirement ID to scenarios, implementation tasks, and evidence. Include relevant failure and boundary cases. Separate proposed, implemented, and verified behavior; completed planning artifacts prove only planning. Describe behavior as Added, Modified, or Removed deltas. Reconcile existing specifications with code and tests; a stale specification is not evidence. Before choosing a format, inspect repository instructions and files for baseline requirements and an active change. Detect them independentl