stackreasonlisted

# Stackreason — System Design Architecture Turn a vague product idea into a defended architecture, an interactive diagram, and a spec another agent can build from. ## Why This Exists Engineers reach for the same stack regardless of requirements. Vercel plus Supabase gets applied to a 50-user internal tool and to a write-heavy ingestion pipeline alike, because the reflex is faster than the analysis. This skill inverts the order. Requirements first, components second, and every component justifies itself against a number. **It is not anti-default, and it is not pro-complexity.** For a great many systems the popular managed stack is exactly right, and this skill must say so plainly and stop. Adding a queue, a cache, a CDN and a read replica to a tool serving 200 people is the same failure as forcing serverless onto a write-heavy pipeline — an unexamined reflex, just a fancier one. Read `references/design-principles.md` before designing anything. It is the reasoning layer; this file is only the procedure. ## Hard Rules Violating any of these invalidates the output. 1. **Never name a component before the profile table exists.** Not in passing, not as an example. The interview comes first. 2. **Never design a system you have not narrowed.** "Design YouTube" gets narrowed to one subsystem before anything else happens. 3. **Always ask the three scope questions. Never infer them.** They are the user's to answer, and guessing them silently invalidates everything downstream. If