Domain Modeling

Actively build and sharpen the project's domain model as you design — challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading CONTEXT.md for vocabulary is not this skill — that's a one-line habit any skill can do. This skill is for when you're changing the model.)

雙語規則（領域語言不是英文的專案）

CONTEXT.md 有兩種讀者：批准者與客戶讀母語，程式碼讀英文。因此每個詞條 必須同時給定母語權威詞與英文識別碼——英文識別碼就是資料表、欄位、函式、 型別、測試名稱要用的那個字：

**牌位**（`plaque`）：
法會中為特定對象設立的祭祀名位，是計費的最小單位。
_Avoid_: 名牌、tablet、memorial

**蓮位**（`lotus_plaque`）：
牌位的一種，規格與價格不同。**不是**牌位的同義詞——計費規則不同。
_Avoid_: 把「蓮位」當成「牌位」的別名

易混淆的上下位詞要在定義裡明講差異，不要只寫 _Avoid_—— 計費、權限這類規則常常就掛在那個差異上。

詞條與外部尚未回覆的問題有衝突時，標為未定並指向追蹤 issue 的完整網址， 不要自己編一個定義。

識別碼定了就要用：詞彙表給了 proxy_registration 而程式碼各寫各的， 詞彙表就死了。實作第一次用到某個概念時回來對表；表上沒有就先補表再寫碼。

File structure

Most repos have a single context:

/
├── CONTEXT.md
├── docs/adr/
│   ├── 0001-….md
│   └── template.md
└── src/

If a CONTEXT-MAP.md exists at the root, the repo has multiple contexts and the map points to where each one lives. Create files lazily — only when you have something to write.

During the session

• Challenge against the glossary — 使用者用了與 CONTEXT.md 衝突的詞就當場指出。
• Sharpen fuzzy language — 模糊或超載的詞，提出精確的權威詞。
• Discuss concrete scenarios — 用具體情境戳邊界，逼出概念之間的精確分界。
• Cross-reference with code — 使用者說的運作方式與程式碼矛盾時，攤開來問。
• Update CONTEXT.md inline — 詞一收斂就寫，不要批次。格式見 CONTEXT-FORMAT.md。 CONTEXT.md 只是詞彙表——不放實作細節、不當 spec、不當筆記。

Offer ADRs sparingly

三條件全中才提議寫 ADR：難回頭、沒脈絡會看不懂為什麼、真的有取捨。 格式用專案的 docs/adr/template.md（含日期、狀態、裁示人、出處—— 沒有這四欄的 ADR，半年後只能靠考古拼時序）；沒有 template 就用 ADR-FORMAT.md。 ADR 要記代價，不只記決定；有牴觸合約或對外承諾的，引用條文並記錄對方同意的出處。