clarify-before-actionlisted

# 行动前澄清 先形成双方一致、可验证的任务定义，再执行。不得用一份看似完整的方案代替与用户确认真实需求。 ## 推理底盘与权限 - 先完整读取并使用 `$first-principles-adversarial-review`，从真实目标、事实、约束、上下游、替代方案和反证重新推导。 - 可以自主进行只读调查，例如读取代码、配置、日志、文档、历史差异和已有同类实现；能自行查明的事实不要反问用户。 - 澄清阶段不得修改代码、配置、文档或数据，不得提交、推送、部署或更新外部系统。 - 只有在用户确认任务理解和拟执行范围后，才能进入实现；该确认只授权当次明确范围，不授权删除、提交、推送、部署、数据库写入等另有确认要求的操作。 ## 工作流 ### 1. 先调查，再决定问什么 识别用户最终想改善的可观察结果，而非照抄其初始方案。检查当前事实源、相关上下游、既有同类实现和至少一个可行替代方向。区分： - 已验证事实； - 用户明确给出的硬约束； - 可协商偏好； - 尚未验证的假设。 只把无法通过只读调查获得、且会实质改变范围或方案的信息留给用户回答。 ### 2. 使用苏格拉底式单问题追问 每轮只问一个最关键的问题并等待回答。问题应优先消除最上游、最可能导致返工的不确定性，通常依次关注目标、使用者、现状、边界、约束、异常场景和完成标准，但不要机械套问卷。 不要在一个句子中塞入多个问题，不要把预设答案藏进选项，也不要重复询问已经能从事实源确认的内容。根据新回答更新理解；若回答暴露矛盾，先指出矛盾及证据，再继续问一个问题。 当以下内容已足够支持行动时停止追问：为什么要��、为谁做、当前机制与痛点、期望结果、范围内外、关键约束、主要异常分支和可验证完成标准。不要追求无法证明的“完全理解”，也不要为了仪式无限追问。 ### 3. 形成三要素任务简报 确认前默认整理以下三类信息，但表达应服从理解需要，不必机械套模板： 1. **背景**：用人话说明事情为何产生、当前怎样运作；解释小白理解任务所必需的名词、关键方法、角色和上下游。 2. **需求**：说明真正要达到的结果、目标用户、触发场景、范围、约束和验收标准；区分真实目标与用户最初提出的候选解法。 3. **痛点**：说明现状与目标之间的差距、根本阻碍、影响以及仍未验证的风险。 复杂关系适合图示时，使用最小有用的流程图、时序图、状态图、因果图或对比表；简单问题用短文即可。 ### 4. 自审规格，并判断是否需要最小验证探针 把任务简报交给用户确认前，先做一次规格自审并直接修正能自行修正的问题： - 是否仍有占位符、模糊代词或没有定义的名词； - 背景、需求、痛点、范围和验收标准之间是否矛盾； - 是否遗漏生产者、消费者、关键集成点、异常分支或明确不做的事项； - 验收标准是否可观察，是否可能出现双方都声称完成但理解不同的情况。 再识别一个最可能导致整体返工的关键假设。若它能以明显低于完整实现的成本被证伪，向用户提出一个最小验证探针，写清：唯一假设、最小验证物或测试、可观察结果、预先定义的失败阈值、时间上限，以及验证后保留还是丢弃。探针只是待确认选项，不得在澄清阶段擅自执行。 不要为了显得严谨而强行做探针。事实明确、风险低，或验证成本接近完整实现时，直接说明无需先验证并进入确认。 ### 5. 请求明确确认 用自己的话复述已经自审过的任务简报，并列出准备执行的范围、明确不做的事项，以及必要时建议先运行的最小验证探针。然后只请求一个确认：当前理解是否准确、是否可以按该