showdar-planlisted

# Showdar Plan ## Purpose - Turn an idea, bug requirement, migration, or design decision into executable engineering work. - Make scope and non-goals explicit before code changes begin. - Derive tasks from current repository evidence instead of generic software phases. - Expose compatibility, data, lifecycle, platform, security, and rollback risks early. - Read `references/requirements.md`, `references/scope.md`, and `references/task-decomposition.md` when requirements are ambiguous or the plan is expanding. ## When to use - New feature or behavior spans multiple files or boundaries. - The user explicitly asks for a plan, breakdown, architecture approach, or implementation order. - An upgrade/migration needs staged execution. - A risky fix needs change-surface and rollback thinking before implementation. - Multiple agents/engineers may execute the work and need unambiguous handoff. ## When not to use - A tiny local edit is already fully specified and planning would add no decision value. - The user only wants repository understanding; use showdar-understand. - Root cause is unknown; debug first instead of planning a guessed fix. - Do not write a long plan merely to satisfy ceremony for a one-line safe change. ## Inputs and assumptions - The requirement or intended outcome is available. - The current repository flow is understood enough to name the real change surface. - If not, run showdar-understand first or collect focused context with `scripts/collect-planning-cont