Domain Modeling

设计过程中主动构建并 sharpen 项目领域模型。这是 主动 discipline — 挑战术语、发明 edge-case scenario、在 crystallise 的瞬间写下 glossary 与决策。（仅 读取 CONTEXT.md 学词汇不是本 skill — 那是任何 skill 都能做的一行习惯。本 skill 用于你在 改变 模型，而非仅消费它。）

File structure

多数 repo 有 single context：

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

若根有 CONTEXT-MAP.md，repo 有 multiple context。Map 指向各 context 位置：

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

Lazy 创建文件 — 仅有内容可写时。若无 CONTEXT.md，第一个 term resolved 时创建。若无 docs/adr/，第一个 ADR 需要时创建。

During the session

Challenge against the glossary

用户使用的 term 与 CONTEXT.md 现有 language 冲突时，立即 call out。「你的词汇表将 'cancellation' 定义为 X，但你似乎指 Y — 到底是哪个？」

Sharpen fuzzy language

用户使用 vague 或 overloaded term 时，propose precise canonical term。「你说 'account' — 是指 Customer 还是 User？那是不同事物。」

Discuss concrete scenarios

讨论 domain relationship 时，用 specific scenario stress-test。发明 probe edge case、迫使用户 precise 概念边界的 scenario。

Cross-reference with code

用户陈述某物如何工作时，检查 code 是否 agree。若发现矛盾，surface：「你的 code 取消 entire Order，但你刚说 partial cancellation 可能 — 哪个对？」

Update CONTEXT.md inline

Term resolved 时，right there 更新 CONTEXT.md。不要 batch — 发生时 capture。格式见 CONTEXT-FORMAT.md。

CONTEXT.md 应 totally devoid of implementation details。不要把 CONTEXT.md 当 spec、scratch pad 或 implementation 决定仓库。它只是 glossary，nothing else。

Offer ADRs sparingly

仅当三者皆真时才 offer 创建 ADR：

1. Hard to reverse — 之后改主意的 cost meaningful
2. Surprising without context — future reader 会 wonder「为何这样做？」
3. The result of a real trade-off — 有 genuine alternative，因 specific reason 选了一个

任一缺失则 skip ADR。格式见 ADR-FORMAT.md。