bts-domain-modellisted

# Domain Model Design the problem's conceptual model **before** drawing modules. This skill exists because verify/audit/simulate all check "is the drawn decomposition internally consistent" — none of them ask "is this the *right* decomposition?". A bad decomposition (e.g., duplicating truth across Card/DropZone/Game state) passes every downstream check while producing patch-of-patches bugs in implementation. domain.md fixes the boundaries BEFORE that drift can start. ## Resume Check ```bash bts recipe status ``` - Phase already `domain-model` and `domain.md` exists → read it, continue refining if sections are incomplete; else advance to `/bts-architect` (or straight to `/bts-wireframe` if wireframe.md already carries an `<!-- architect-decision -->` block). - Phase is `research` or later without `domain.md` → start from Step 1. - No active recipe → fail: this skill runs inside an active blueprint or design recipe only. ## Prerequisites 1. Read `.bts/specs/recipes/{id}/scope.md` — scope MUST be Status: CONFIRMED 2. Read `.bts/specs/recipes/{id}/research/v1.md` (or latest research doc) 3. Read `.bts/specs/recipes/{id}/intent.md` for the Success Criteria 4. Read `.bts/specs/project-map.md` for existing layer structure ## Output: `.bts/specs/recipes/{id}/domain.md` Emit exactly these five sections. All are required for the Quality Gate. ### 1. Entities The stable nouns of the domain. One row per entity. Entities are **concepts**, not files or modules — those co