domain-glossarylisted

# Domain glossary A ticket says "Vertragspartner-Zuordnung". The code says `PartnerAssignmentFacade`. Without a mapping, the agent searches for the German term, finds nothing, and either asks or guesses — and guessing at domain vocabulary produces code that works and models the wrong thing. Enterprise domains have a second problem: the same concept under three names, one per generation of the codebase. The glossary records the aliases and marks which one is current. ## 1 — Harvest terms Take terms from where the business speaks, not from where the code speaks: - Ticket titles and descriptions (last ~50 issues) - UI labels and i18n translation files — the richest source, because every user-visible string is a business term already mapped to a code key - Enum values and status names - Backend endpoint paths and payload field names i18n files are the highest-yield source in a localised enterprise app: a translation key is literally a business term paired with a code identifier. ## 2 — Map each term to its code home For every term, find the places it lives and record file paths: - **Type or model** — the interface/class that represents it - **UI** — the component or route where a user meets it - **Data** — the endpoint that serves it, and the backend type behind it - **State** — the store slice, service or query key that holds it A term you cannot map is a finding: either the concept has no code representation yet, or it lives under a name nobody remembers. Both are wor