prototypelisted

# Prototype A prototype is an experiment, not a draft of the product. The prototype dies; the **answer** survives — as a decision, a feature spec, or a discarded option with a reason. ## 1. Name the question Before writing anything, state the design question this prototype answers ("does optimistic locking survive concurrent edits of the same block?", "which of these three layouts makes the hierarchy scannable?"). No question, no prototype — that's just coding without a spec. Confirm the question with the user; it decides the branch. ## 2. Pick the branch **Logic branch** — for state machines, data models, algorithms, API shapes: the smallest *runnable* terminal program that exercises the real question with hardcoded data. Print state transitions; make it interactive (read stdin) when the user should drive. No UI, no persistence, no error handling beyond what the question needs. **UI branch** — for look-and-feel and interaction questions: build **3–4 radically different** variations, not one safe design with color tweaks — different layouts, different interaction models, different information hierarchies. All toggleable from one route/entry point so comparison is one keystroke. Real-looking data (from the domain, using the glossary's terms), faked backend. ## 3. Throwaway discipline - Lives outside the production tree: `.prototype/<question-slug>/` (or `/tmp` for one-shots). Production code never imports from it. - Exempt from `/tdd` — no tests, no lint perfection;