showdar-buildlisted

# Showdar Build ## Purpose - Convert an approved requirement/plan into maintainable production code. - Preserve existing ownership boundaries and public contracts unless change is explicitly required. - Minimize blast radius without cutting required correctness, error handling, or tests. - Make implementation decisions evidence-based and stack-native. - Read `references/minimal-change.md` and `references/architecture-boundaries.md` before introducing new abstractions. ## When to use - Implementing a feature, refactor, bug fix after root cause is known, or architecture-safe change. - Applying an approved UI implementation after design decisions are clear. - Small migrations where the upgrade-specific analysis is already complete. - Completing a bounded task recovered from a previous session. ## When not to use - Root cause is unknown; use showdar-debug. - Requirements/change surface are unclear and multiple approaches remain; use showdar-plan. - The work is only review or testing strategy. - Production deploy/release actions belong to showdar-ship. ## Inputs and assumptions - User outcome and current repository conventions are understood. - Relevant tests/build/typecheck commands are known or discoverable. - Existing public interfaces and state ownership are constraints unless explicitly changed. - For dirty repositories, distinguish user work from this task before editing. - `scripts/change-surface.mjs` can summarize current git changes without mutation. ## Non-negot