domain-glossarylisted

# Domain Glossary One shared language between the user, the agent, and the code — what Domain-Driven Design calls the *ubiquitous language* — living in `CONTEXT.md` at the repo root: a glossary and nothing else. The payoff compounds across work: a term sharpened during one piece of work serves every later one — shorter conversations, consistent naming in code and tests, fewer tokens spent decoding jargon. ## Format ```markdown # {Project Name} {One or two sentences on what this project is.} ## Language **customer**: {One or two sentences. What it IS, not what it does.} Killed: *client*, *buyer* — one concept, one word. **archive**: Soft-hide; the user can restore it. Settled against permanent deletion in the exports work — restorability is a support contract. Killed: *trash*, *delete* — each carried both meanings at once. ``` Rules of the file: - **Be opinionated.** When several words name one concept, pick the best and name the losers as killed — with what killed them where there was a real fight, and a plain "one concept, one word" where there wasn't. - **A fought term keeps its fight.** A term that collided — two meanings, or a claim against the code — carries the collision in one line: what collided, which won, why. A resolution recorded without its collision gets re-litigated; that is as true of words as of designs. A term that never collided is just its definition. - **Published API names outrank opinion.** A misleading name that's public API (a decade-old keyw