追问会话
对方案的每一个方面不留死角地追问，沿设计决策树逐条走，直到达成共识。追问过程中一旦有决策结晶，就立即沉淀成术语表和决策记录。
开始前先看有没有既有材料：根目录的 CONTEXT.md 或 CONTEXT-MAP.md，以及 docs/adr/ 下已有的 ADR。有就读，据此知道哪些概念和决策已经定过。
| 参考 | 何时读 |
|------|--------|
| references/context-md.md | 第一个术语敲定、要真正写入 CONTEXT.md 时；或需要判断单上下文还是多上下文结构时 |
| references/adr.md | 一个决策通过了下面三条门槛、要落笔写 ADR 时 |
核心规则
一次只问一个问题，等回复后再问下一个。一次抛出多个问题会让人无所适从。每个问题都给出你的推荐答案。
能从代码库查到的事实就直接查，不要问。但决策权在用户手里 —— 每个决策都提出来，等回答。
在用户明确确认达成共识之前，不要开始执行方案。
追问时的动作
对照术语表质疑。 用户的用词与 CONTEXT.md 里的定义冲突时立即指出："你的术语表把'取消'定义为 X，但你现在似乎指的是 Y —— 到底是哪个？"
磨尖模糊表达。 遇到含糊或多义的词，提出精确的规范术语："你说的'账户' —— 是 Customer 还是 User？这是两个不同概念。"
用具体场景压力测试。 讨论领域关系时构造边界场景，逼出概念之间的精确边界。
与代码交叉验证。 用户陈述某物如何运作时，去看代码是否一致，发现矛盾立即暴露："你的代码取消的是整个 Order，但你刚说可以部分取消 —— 哪个是对的？"
即时写入，不要攒批。 术语一敲定就更新 CONTEXT.md。懒创建：文件不存在就在第一个术语确定时建。
ADR 的门槛
三条全部成立才写 ADR：
- 难以逆转 — 将来改变主意的代价可观
- 缺乏上下文则令人费解 — 未来读者会困惑"为什么这样做？"
- 确实是权衡的结果 — 存在真正的替代方案，且基于具体理由选了其一