lenneTech/grilling-decisions

拷问开放决策

坚持不懈地就计划、工单或设计向用户提问，直到达成共同理解。目的是在工作开始前对齐：一个基于错误假设的变更会浪费整个实现，以及随之而来的审查、浏览器演示和合并。一个提前提出的问题只需一次点击；同一个问题在实现中途提出则会导致用户上下文切换，并使运行停滞直到用户回来。

在用户确认理解一致之前，不要对拷问的主题采取任何行动。

循环

1. 自己查找每个事实（参见事实 vs 决策）。在面试时已经了解代码。
2. 映射决策树。 每个开放决策都会分支成依赖它的决策。
3. 解决工单和证据所能解决的问题。 通过决策简报的五个部分来处理每个开放决策。工单明确陈述的内容按其措辞记录；证据仅为一个选项留下空间的内容则附带其 Beleg: 记录；其余内容对用户保持开放（解决或询问）。
4. 在提出问题之前，根据来源重新检查每个剩余问题（重新检查后再询问）。来源已经回答的问题会让用户付出本不需要做出的决策代价。
5. 将前沿作为一轮提出。 前沿是每个前置条件已经解决、你现在可以提出的开放决策：那些无需猜测未听到的答案即可提出的问题。依赖本轮中另一个仍开放的问题属于后续轮次。
6. 为每个问题呈现其简报。 简报以你的推荐结束，这样用户可以在看到事实的情况下一次点击做出决策，无需先阅读代码或从头开始构建设计。
7. 每轮之后重新计算前沿：已解决的决策将其向外推进，解除依赖它们的问题的阻塞，并且常常淘汰问题或使其足够清晰以从证据中解决。重新检查并询问下一轮。
8. 当前沿为空时停止：每个分支都已访问，没有沉默的假设留下。编写决策记录并让用户确认它。

解决或询问

工单（或被拷问的计划或规格）是命令，并且具有优先权：它明确陈述的内容尽可能精确地按原样实现。工单常常不精确、自相矛盾或遗漏事项，而这些正是需要决策的点。用户必须做出的决策越少越好，每个不明确的点都是他们的。决策简报划清了界限：在询问任何人之前为每个开放决策编写它，并让它的输出将点放入三种情况之一。

1. 工单明确回答了它：按原样实现。 该点被解决并标记为 [Ticket <ID>]，即使相邻功能以不同方式实现或你会选择其他方式也是如此。不需要询问任何人。

2. 工单不精确、自相矛盾或遗漏了后果：由用户决定。 当其措辞有两种解读方式或未明确“完成”的含义时；当描述、评论、验收标准和设计不一致时；当它对当前代码的描述与代码实际显示不符时；或者当按字面意思实现时会破坏它未提及的内容（其他功能依赖的行为、安全性、现有数据）时，用简报询问。工单的含义是用户的决定，因此即使你倾向于某种方式，这些问题也要交给他们。

3. 工单未提及：当证据明确时自己解决，否则询问。 当只有一个选项成立时自己解决：

• 另一个来源陈述了答案（链接的文档、设计、项目文档），或者代码以一种既定的方式处理了这个确切情况（path:line），
• 来源或代码中没有指向另一个方向的内容，
• 没有其他选项具有有人可能合理评价更高的优势，并且
• 它没有持久性后果（数据模型、迁移、权限默认值、其他模块或团队消费的契约）。每当工单沉默时，无论你自己的推理多么自信，这些都要交给用户。

将已解决的缺口记录为带有 Beleg: 行证据的 Annahme（决策记录）；用户在确认记录时会看到它，并且可以在那里推翻它。每个其他缺口都要带着简报交给用户，以及每个你不确定的点：怀疑一个点是否明确意味着它不明确。

重新检查后再询问

到达用户的问题要求他们做出决策，因此在发出新一轮之前，要带着其问题回到来源。第一次阅读寻找需求；这一次寻找一个特定问题的答案，并且会发现一般阅读会忽略的内容：评论线程深处的回复、设计中的第二帧、只以一种方式工作的验收标准。

1. 完整重读工单，记住本轮的问题：描述、验收标准、每条评论和回复（不仅仅是最新的），以及其中的图片。
2. 在其他来源中搜索每个问题的术语，包括德语和英语及同义词（涉及的实体、字段、角色、屏幕或状态）：父、子和链接的问题、附件文档、更早的决策评论和问题文档、设计的每个框架和状态、流程、项目文档。
3. 寻找从已确定的答案中推导出的答案：另一个只与一个选项兼容的验收标准、本拷问中更早做出的决策、已经固定了工单未改变行为的测试或验证。

然后根据解决或询问再次对每个问题进行分类：工单明确陈述的答案按原样解决；其他来源中的答案可以解决一个缺口，附带其 Beleg:；重新检查发现的矛盾保持为问题，现在附带两个引用。只有幸存下来的问题才进入本轮，其简报的第3部分指明了重新检查覆盖的内容，这样用户就看到这个问题是真实的。

决策简报

按此顺序的五个部分，每个部分都从您在本次会话中收集的证据回答：当前分支上的代码，今天阅读的来源。

1. Ist-Stand im Code：代码在决策落点处今天的行为，附带 path:line。对于尚不存在的内容，说明并指出您查找的位置。如果工单描述的行为与代码显示的不同，则两者都说明：那个缺口往往是真正的问题。
2. Geplante Änderung：修改、添加或删除了什么，如何以及为什么（要求它的验收标准或来源）。将已确定的部分与选项所解决的分叉分开。
3. Ticket und Quellen：工单、其评论、链接的工单和文档、设计以及项目文档对此点的说明，首先是工单，用“„…“”逐字引用并注明来源（括号中，例如工单和章节、评论日期、文档标题、Figma 节点、CLAUDE.md:<line>）。引用重要的句子，而不是段落。如果来源不一致，则引用每一方。如果没有来源涉及该点，则说明并列出重新检查覆盖的内容：这种沉默正是它成为问题的原因。
4. Optionen：两到四个，与问题提供的相同，每个都具体说明其含义、优势、缺点及其影响：涉及的文件和模块、现有数据、其他角色或消费者、测试、工作量以及以后是否难以撤销。框架已经提供的一个选项是其中之一。
5. Empfehlung：你会选择的选项以及为什么，根据第1到第3部分论证。

保持每个部分一到三行：简报是一个决策的上下文，而不是报告。编写它也是解决或询问的测试：当第3部分找到回答该点的引用，或者第1部分显示代码已经决定了它时，该点被解决并离开本轮。

**F1 发票删除行为**

1. **Ist-Stand im Code:** `InvoiceService.delete()` 通过 `deleteOne` 硬删除（`projects/api/src/server/modules/invoice/invoice.service.ts:88`），但至今未被调用。`Payment.invoice` 引用发票（`payment.model.ts:31`）。项目中有两种模式：`Order` 通过 `deletedAt` 软删除（`order.service.ts:54`），`Customer` 硬删除（`customer.service.ts:71`）。
2. **Geplante Änderung:** 管理员在发票列表中获得删除操作（AK 3）：新端点 `DELETE /invoices/:id`，`InvoiceList.vue` 中的按钮。谁可以删除已确定；未确定的是记录是否消失。
3. **Ticket und Quellen:**
   - „管理员应能删除错误的发票。“（DEV-1234，描述）
   - „仅限管理员删除。“（DEV-1234，2026-10-02 评论）
   - 删除的发票是否保留，来源未说明（已检查：描述、3条评论、Figma 节点 12:345、`docs/`）。
4. **Optionen:**
   - **A 软删除** 通过 `deletedAt`，像 `Order` 一样。优点：历史和 `Payment` 引用保持有效。缺点：每个查询都需要过滤器。影响：模型、服务和三个列表查询更改；无需迁移，该字段是可选的。
   - **B 硬删除**，像 `Customer` 一样。优点：无额外字段，无过滤器。缺点：发票永久消失。影响：`Payment` 引用失效，需要单独处理。
5. **Empfehlung:** A，因为付款引用发票，否则删除的发票无法追溯。

工单沉默，项目有先例，选择影响数据模型，因此这个缺口交给用户。如果描述中写道“已删除的发票保持保存并仅被隐藏”，工单就会解决它：软删除，按原样实现，标记为 [Ticket DEV-1234]，没有问题。如果评论要求相反，矛盾就会交给用户，第3部分下有两个引用。

轮次格式

使用 AskUserQuestion：每轮一次调用，最多四个问题，每个问题首先列出推荐选项并添加后缀 (Recommended)，每个选项的描述包含一行影响。自动提供的“其他”条目包含自由文本答案。当前沿包含超过四个问题时，首先询问最上游的问题；它们的答案通常会淘汰一些其余问题。

将本轮的简报放在与调用相同的消息中，就在调用之前，编号匹配（F1，F2，…），这样用户在打开问题时就能看到它们。

一个仅收集用户独自持有的事实（他们观察到什么，使用了哪个账户）或工作流选择（运行审查，如何合并）的问题不需要简报：其选项标签包含了重要信息。

如果没有 AskUserQuestion（纯聊天，非交互式运行器），则以相同格式打印本轮并等待答案。

事实 vs 决策

查找事实是你的工作。询问用户你可以自己阅读的内容会让面试感觉像审讯，而且你从记忆中得到的答案不如仓库中的可靠。

自己查找	决策（从证据中解决，或询问）
服务已经允许哪些角色（@Restricted，@Roles，securityCheck）	应该允许哪些角色
实体、DTO 或生成类型的当前形状（types.gen.ts，sdk.gen.ts）	是否添加、重命名或替换字段
端点、页面或 composable 是否已存在	是扩展它还是在其旁边构建
工单、其评论和链接的 Figma 节点实际说了什么	工单在不明确处的含义
相邻功能如何解决同一个问题	此功能是否应遵循该先例
哪些测试今天覆盖受影响的路径	新测试应放在哪些接缝处
描述的缺陷是否仍可重现	正确的行为应该是什么

在提出问题之前使用 Read、Grep、Glob、Linear MCP 和 Figma MCP。如果查找范围很广，则派遣子代理进行处理且不要阻塞：正在进行的查找是一个未解决的前提条件，因此只有依赖它的问题等待，而前沿的其余部分现在就被询问。

问题质量

• 探询边缘，而不是快乐路径。 空值、null值、非常大、并发、未授权、离线。快乐路径是每个人都已同意的部分。
• 揭示超出工单的后果： 以后难以迁移的数据模型、成为先例的权限默认值、其他团队将消费的契约。
• 一个新的 nest-server 项目在本轮中解决其数据库。 除非工单或根目录 CLAUDE.md 中的 ## Database 部分指定了数据库，否则数据库和 SQL 引擎是一个问题（它们超出每个工单的生命周期），由 generating-nest-servers → reference/choosing-a-database.md 中的程序进行简报：第3部分中的来源信号，第5部分中的决策步骤，以及对于 MySQL / MariaDB 项目放弃的内容。一个拥有自己数据的新模块留在项目的数据库中，无需提问；只有当来源指向另一个数据库（混合）时才会成为问题。确认的答案进入决策记录，并作为 ## Database 进入根目录 CLAUDE.md。
• 涵盖实现否则会停滞的内容。 在关闭之前，在头脑中走一遍计划的工作（模型、端点、权限、UI 状态、测试），并通过解决或询问处理每个你会暂停的点。这就是使之后运行无问题的方法。

当用户无法联系时

一个不明确的决策属于用户，因此阻塞性决策永远不会代表用户回答

…

[已截断以进行翻译]