在设计讨论中主动构建并打磨领域模型：解决术语冲突、模糊语言…

适用于讨论 codebase 术语、编写或编辑 CONTEXT.md，或记录/编辑 ADR 时。

适用场景

解决思路

1. 在设计过程中主动构建并打磨项目的 domain model；这是 active discipline：挑战术语、发明 edge-case scenarios，并在概念成形的当下写入 glossary 和 decisions。
2. 判断 repo 是单个 context 还是多个 contexts：多数 repos 只有一个 context；如果 root 有 CONTEXT-MAP.md，说明 repo 有多个 contexts，map 指向每个 context 的位置。
3. 多 contexts 时，按 CONTEXT-MAP.md 指向每个 context 的位置；root 的 docs/adr/ 放 system-wide decisions，各 context 的 docs/adr/ 放 context-specific decisions。
4. 按需懒创建文件：只有在有内容要写时才创建；如果没有 CONTEXT.md，当第一个 term 被解决时创建它；如果没有 docs/adr/，当第一个 ADR 需要出现时创建它。
5. 当用户使用的术语与 CONTEXT.md 中既有语言冲突时，立即指出；例如：glossary 把 'cancellation' 定义为 X，但你似乎指 Y——到底是哪一个？
6. 当用户使用模糊或过载术语时，提出一个精确的 canonical term；例如：用户说 'account'，问是指 Customer 还是 User，那些是不同的东西。
7. 讨论 domain relationships 时，用具体场景做压力测试；发明能探测 edge cases 的场景，迫使用户精确定义概念之间的 boundaries。
8. 当用户描述某事如何工作时，检查代码是否同意；如果发现矛盾，要指出；例如：代码取消整个 Orders，但你刚说 partial cancellation 是可能的——哪个是对的？
9. 当一个 term 被解决时，立刻更新 CONTEXT.md；不要批量攒到最后，随着概念出现就捕获；使用 CONTEXT-FORMAT.md 中的格式。
10. 确保 CONTEXT.md 完全不包含 implementation details；不要把 CONTEXT.md 当 spec、scratch pad 或 implementation decisions 的仓库；它只是一份 glossary。
11. 只有以下三项都成立时，才提出创建 ADR：1) Hard to reverse——之后改变主意的成本有意义；2) Surprising without context——未来读者会疑惑 why did they do it this way?；3) The result of a real trade-off——确实存在替代方案，而你基于具体理由选择了其中一个。缺少任一项就跳过 ADR；使用 ADR-FORMAT.md 中的格式。

适用边界 · 注意事项

• 没有内容要写时不要创建 CONTEXT.md 或 docs/adr/；按需懒创建。
• 不要把 CONTEXT.md 当 spec、scratch pad 或 implementation decisions 的仓库，也不要写入 implementation details。
• ADR 的三项条件缺任一项时不要提出创建 ADR。