dev-architecturelisted

# Dev Architecture — Design Before Code ## Classify First (say it out loud before the first question) - **Spike** — a feasibility question ("can we...", "is it possible"). Output is an answer, not kept code. No design doc. Anything built stays labeled throwaway - **Bounded** — a well-scoped change to a flow that already exists in this repo. Short design IN CHAT (a few paragraphs) covering problem, approach, rejected alternatives, touched files. Then STOP - **Architectural** — new subsystem, new project, or changes that restructure component boundaries or interfaces. Full spec + implementation plan When in doubt between two paths, take the heavier one. "Bounded" requires the flow to already exist in code — understanding what kind of app this is does not make a task bounded. ## The Gate No implementation action until the human approves the stated design. The ceremony scales with the task — the approval gate never does. ## Judgment Rules - Design units with clear boundaries and one responsibility each. Files that change together live together — split by responsibility, not technical layer - Follow established codebase patterns. Don't unilaterally restructure an existing style — propose the split in the design instead - YAGNI — cut everything not required now. DRY only at the third repetition - Each plan task must produce independently testable software. If two tasks can't be reviewed separately, fold them into one - State trade-offs as "we get X, we pay Y" — a design with