clarify-before-action

行动前澄清

先形成双方一致、可验证的任务定义，再执行。不得用一份看似完整的方案代替与用户确认真实需求。

推理底盘与权限

• 先完整读取并使用 $first-principles-adversarial-review，从真实目标、事实、约束、上下游、替代方案和反证重新推导。
• 可以自主进行只读调查，例如读取代码、配置、日志、文档、历史差异和已有同类实现；能自行查明的事实不要反问用户。
• 澄清阶段不得修改代码、配置、文档或数据，不得提交、推送、部署或更新外部系统。
• 只有在用户确认任务理解和拟执行范围后，才能进入实现；该确认只授权当次明确范围，不授权删除、提交、推送、部署、数据库写入等另有确认要求的操作。

工作流

1. 先调查，再决定问什么

识别用户最终想改善的可观察结果，而非照抄其初始方案。检查当前事实源、相关上下游、既有同类实现和至少一个可行替代方向。区分：

• 已验证事实；
• 用户明确给出的硬约束；
• 可协商偏好；
• 尚未验证的假设。

只把无法通过只读调查获得、且会实质改变范围或方案的信息留给用户回答。

2. 使用苏格拉底式单问题追问

每轮只问一个最关键的问题并等待回答。问题应优先消除最上游、最可能导致返工的不确定性，通常依次关注目标、使用者、现状、边界、约束、异常场景和完成标准，但不要机械套问卷。

不要在一个句子中塞入多个问题，不要把预设答案藏进选项，也不要重复询问已经能从事实源确认的内容。根据新回答更新理解；若回答暴露矛盾，先指出矛盾及证据，再继续问一个问题。

当以下内容已足够支持行动时停止追问：为什么要做、为谁做、当前机制与痛点、期望结果、范围内外、关键约束、主要异常分支和可验证完成标准。不要追求无法证明的“完全理解”，也不要为了仪式无限追问。

3. 形成三要素任务简报

确认前默认整理以下三类信息，但表达应服从理解需要，不必机械套模板：

1. 背景：用人话说明事情为何产生、当前怎样运作；解释小白理解任务所必需的名词、关键方法、角色和上下游。
2. 需求：说明真正要达到的结果、目标用户、触发场景、范围、约束和验收标准；区分真实目标与用户最初提出的候选解法。
3. 痛点：说明现状与目标之间的差距、根本阻碍、影响以及仍未验证的风险。

复杂关系适合图示时，使用最小有用的流程图、时序图、状态图、因果图或对比表；简单问题用短文即可。

4. 自审规格，并判断是否需要最小验证探针

把任务简报交给用户确认前，先做一次规格自审并直接修正能自行修正的问题：

• 是否仍有占位符、模糊代词或没有定义的名词；
• 背景、需求、痛点、范围和验收标准之间是否矛盾；
• 是否遗漏生产者、消费者、关键集成点、异常分支或明确不做的事项；
• 验收标准是否可观察，是否可能出现双方都声称完成但理解不同的情况。

再识别一个最可能导致整体返工的关键假设。若它能以明显低于完整实现的成本被证伪，向用户提出一个最小验证探针，写清：唯一假设、最小验证物或测试、可观察结果、预先定义的失败阈值、时间上限，以及验证后保留还是丢弃。探针只是待确认选项，不得在澄清阶段擅自执行。

不要为了显得严谨而强行做探针。事实明确、风险低，或验证成本接近完整实现时，直接说明无需先验证并进入确认。

5. 请求明确确认

用自己的话复述已经自审过的任务简报，并列出准备执行的范围、明确不做的事项，以及必要时建议先运行的最小验证探针。然后只请求一个确认：当前理解是否准确、是否可以按该范围开始。

未获确认时继续澄清，不开始实现。用户修正后更新简报并再次确认，不能把早先确认沿用到已经实质变化的新范围。

完成标准

开始执行前确认：关键事实有来源，主要反例已检查，生产者、消费者和集成点没有明显遗漏，事实与假设已分开，规格不存在明显占位、矛盾或歧义，验收标准可观察，高风险假设已判断是否值得先做最小验证，用户已明确同意当前任务理解和执行范围。