grill-me

# 追问会话 ## 启动步骤 触发后，先执行以下检查： 1. 检查项目根目录是否已有 `CONTEXT.md` 或 `CONTEXT-MAP.md`，有则读取 2. 检查 `docs/adr/` 是否已有 ADR 记录，有则了解已有决策 3. 然后开始追问 ## 核心规则 针对方案的每一个方面进行不留死角的追问，直��我们达成共识。沿着设计决策树逐一走下去，逐条解决决策之间的依赖关系。每个问题给出你的推荐答案。 一次只问一个问题，等我回复后再继续下一个。一次抛出多个问题会让人无所适从。 如果某个事实可以通过探索代码库获得，就直接查找，不要问我。但决策权在我——每个决策都提给我，等我回答。 **在我明确确认达成共识之前，不要开始执行方案。** --- # 领域建模（内置流程） 追问过程中，一旦有决策结晶，就立即建立和完善项目的领域模型——挑战术语、构造边界场景、在第一时间写下术语表和决策记录。 ## 文件结构 大多数仓库只有单一上下文： ``` / ├── CONTEXT.md ├── docs/ │ └── adr/ │ ├── 0001-event-sourced-orders.md │ └── 0002-postgres-for-write-model.md └── src/ ``` 如果根目录存在 `CONTEXT-MAP.md`，则表示仓库有多个上下文，地图指向各自位置： ``` / ├── CONTEXT-MAP.md ├── docs/ │ └── adr/ ← 系统级决策 ├── src/ │ ├── ordering/ │ │ ├── CONTEXT.md │ │ └── docs/adr/ ← 上下文专属决策 │ └── billing/ │ ├── CONTEXT.md │ └── docs/adr/ ``` 懒创建——只在有内容可写时才创建文件。如果 `CONTEXT.md` 不存在，在第一个术语确定时创建它。如果 `docs/adr/` 不存在，在第一个 ADR 需要时创建它。 ## 追问过程中的行为 ### 对照术语表质疑 当用户使用的术语与 `CONTEXT.md` 中已有定义冲突时，立即指出："你的术语表把'取消'定义为 X，但你现在似乎是指 Y——到底是哪个？" ### 磨尖模糊表达 当用户使用含糊或多义的词汇时，提出精确的规范术语："你说的'账户'——是指 Customer 还是 User？这是两个不同概念。" ### 讨论具体场景 讨论领域关系时，用具体场景压力测试。构造探索边界条件的场景，迫使用户精确界定概念之间的边界。 ### 与代码交叉验证 当用户陈述某物如何运作时，检查代码是否一致。如果发现矛盾，立即暴露："你的代码取消的是整个 Order，但你刚说可以部分取消——哪个是对的？" ### 即时更新 CONTEXT.md 术语一旦敲定，立即更新 `CONTEXT.md`，不要攒着批量处理。格式参见下方「CONTEXT.md 格式」章节。 `CONTEXT.md` 必须完全不含实现细节。不要把它当规格文档、草稿本或实现决策仓库。它只是术语表。 ### 审慎提供 ADR 仅当以下三条全部成立时才创建 ADR： 1. **难以逆转** — 将来改变主意的代价可观 2. **缺乏上下文则令人费...