designlisted

# design Nobody on the team is a designer, so the design is a checklist and a foundation, not taste. A screen that passes the checklist looks like the rest of the product and does not embarrass the CEO in front of a user; that is the bar. Taste comes from the CEO's own words in the brief's appendix and from "이거 별로네" after they try it. ## The design foundation (decided at /kickoff, in the stack ADR's "Design foundation" section) - A component library or a small set of primitives (button, input, list, card, dialog, toast) — never one-off styling per screen. - Tokens: colour, spacing, type scale, radius — a single file the whole product reads. Dark mode only if the brief says so. - A layout shell: navigation, page frame, empty page — every screen lives inside it. - The screenshots command (a headless browser script that renders each screen in each state to docs/screens/<plan-slug>/<screen>-<state>.png; docs/screens/ is git-ignored) registered under "## Commands" as `screenshots:`. ## The checklist — every screen a step adds or changes 1. **Four states**, each designed, not defaulted: empty (first use — what the user does next), loading (no layout jump), error (what went wrong, what to do; never a stack trace), success (the content). A list also needs its one-item and many-items case. 2. **Hierarchy**: one primary action per screen, visible without scrolling on a phone; secondary actions look secondary; destructive actions confirm. 3. **Copy**: labels say what happens ("저장" no