domain-modellisted

# Domain Model Own the project's shared language and its recorded decisions. This is the *active* discipline: challenging terms, inventing scenarios that break them, and writing the glossary and the ADR down the moment they crystallise — not after the feature ships, when the reasoning is gone. Two artifacts, and they do not overlap: | File | Holds | Never holds | | --- | --- | --- | | `CONTEXT.md` | What the project's nouns *mean* | Implementation, structure, plans, TODOs | | `docs/adr/NNNN-slug.md` | Why a hard-to-reverse decision was made | Anything easy to reverse or unsurprising | ## Ground yourself first Read before writing. The model that already exists outranks the one in your head. 1. Look for `CONTEXT-MAP.md` at the root. If it exists, the repo has **multiple contexts** — read it to find which `CONTEXT.md` the current topic belongs to, and ask if it is genuinely unclear. 2. Otherwise read the root `CONTEXT.md`. If neither exists, the repo has no model yet — create files **lazily**, when the first term or decision actually lands, never as an empty scaffold. 3. Skim `docs/adr/` for decisions that already constrain the topic. A term you are about to coin may already be settled there under another name. ```text Single context (most repos) Multiple contexts / / ├── CONTEXT.md ├── CONTEXT-MAP.md ├── docs/adr/ ├── docs/adr/ ← system-wide │ ├── 0001-….md