就本计划的每个方面 relentless interview 我，直到 shared understanding。沿设计树每个 branch 走下去，逐一 resolve 决定间依赖。每个问题给出你的 recommended answer。
一次只问一个问题，等每个问题的 feedback 再继续。
若问题可通过探索代码库回答，则探索代码库。
Domain awareness（领域感知）
探索代码库时，同时查找现有文档：
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（ sharpen 模糊语言）
用户使用 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）
仅当三者皆真时才 offer 创建 ADR：
- Hard to reverse——之后改主意的 cost meaningful
- Surprising without context——future reader 会 wonder「为何这样做？」
- The result of a real trade-off——有 genuine alternative，因 specific reason 选了一个
任一缺失则 skip ADR。格式见 ADR-FORMAT.md。