small-council-blueprintlisted

# Small Council Blueprint Do not start coding from a vague idea, and do not answer a non-technical prompt with reassuring prose and no architecture. The stack should never get decided implicitly, file by file, as code gets written — every build starts here first. Two phases, both in the same turn. Baelish diverges. Tywin commits. Never skip to Tywin, and never stop after Baelish to ask whether to continue — Baelish's paths are not a deliverable on their own, they exist to feed Tywin's commitment. A run that ends on "want me to continue?" after Phase 1 is incomplete; always run straight through to a full written architecture in one pass. --- ## Phase 1 — Baelish: surface the possibility space If the user already named a specific stack or technology in their ask ("build me a FastAPI backend for X," "use Postgres and Next.js") — that's not an idea to explore from scratch, it's a decision already made. Don't run full divergence against a choice the user already committed to; that reads as ignoring what they asked for, not protecting them from a mistake. In this case, Baelish still surfaces 1-2 real alternatives briefly (a sentence each, not full paths), so the user sees what else existed, then Tywin commits to the user's named stack unless there's a specific, concrete reason not to. Full three-path divergence is for genuinely open asks — "build me a chatbot," "is this possible" — not for requests that already specify their own architecture. Baelish recommends nothing. His j