architect

Technical design interview → ## Technical Design in the living doc → adversarial review. Pipeline: explore → define → [design] → architect → plan.

Phase: Engineering. User is technical. Architecture, data models, APIs, build phasing.

Starting

Before asking anything:

1. Read the living doc (./plans/*.md). If multiple .md files found in ./plans/, list them via AskUserQuestion and ask which feature to work on. Check for ## Scope, ## Requirements (including ### Glossary), ## UX Design. Use glossary terms for data models, APIs, modules. UX flows map to behavior specs; screens map to frontend architecture.
   • ## Rollback Notes has content → this takes priority. Skip steps 2-3, resume only affected domains, clear after resolving.
   • ## Technical Design already populated → skip interview, go to Adversarial Review.
   • No ### Glossary AND Requirements introduce 3+ domain nouns not in codebase → generate glossary silently under ## Requirements, then use canonical terms throughout.
2. Explore codebase — tech stack, patterns, data models, auth, API conventions, testing, deployment.
3. Search for architecture docs, ADRs, domain glossaries. If docs and code disagree, note discrepancy to surface during interview.

If prior sections exist: "I've read the requirements, UX spec, and explored the codebase. Requirements call for [items]. UX defines [N flows] across [N screens]. Stack uses [tech]. First: [question]."

No Requirements? Works — but note that defined requirements make for a better design. No UX? Interview covers frontend concerns as needed.