model-domainlisted

# Model Domain Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. > **HARD GATE** — Capture invariants (what MUST always be true) and state machines (what transitions are legal) for core entities. If these are fuzzy, design will fail. Ask the questions one at a time, waiting for feedback on each question before continuing. If a question can be answered by exploring the codebase, explore the codebase instead. ## Domain awareness During codebase exploration, also look for existing documentation: ### File structure Most repos have a single context: ``` / ├── specs/ │ ├── CONTEXT.md │ └── adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ ``` If a `specs/tech-architecture/tech-stack.md` exists, the repo has multiple contexts. The map points to where each one lives: ``` / ├── specs/ │ ├── CONTEXT-MAP.md │ └── adr/ ← system-wide decisions └── src/ ├── ordering/ │ └── specs/ │ ├── CONTEXT.md │ └── adr/ ← context-specific decisions └── billing/ └── specs/ ├── CONTEXT.md └── adr/ ``` Create files lazily — only when you have something to write. If no `specs/tech-architecture/tech-stack.md` exists, create it when the first