devflow-clarify-requirements

# DevFlow 需求澄清 把用户请求和项目证据整理为双方一致、可测试的需求边界。产品澄清与技术设计严格分开。 ## 输入与角色 接收用户请求、项目规则、有边界的代码/知识检索结果，以及调用方指定的报告路径。 在 DevFlow 中由协调者在当前上下文依次完成证据检查、决策图、用户访谈和需求报告，不再创建独立需求分析 Agent。只有代码或知识检索范围明确且会产生大量无关上下文时，才启动只读 helper 并只接收事实摘要。 ## 澄清流程 1. 用一段话复述期望结果，不虚构行为。 2. 只列会改变可观察行为、范围或风险的决策分支，不设固定数量。考虑结果、范围、用户交互、数据归属与生命周期、权限、兼容性、失败行为和成功标准；证据已明确且没有真实分支的内容不展开。 3. 对每个分支分类： - `evidence-resolved`：代码、文档或现有行为已经给出答案； - `safe-default`：存在可逆、低风险的默认值；明确写出该默认值； - `user-decision`：不同选择会实质改变可观察行为、兼容性、成本、风险或范围。 4. 先用当前上下文的定向检索解决证据问题；只有一次直接检索会带入大量无关上下文时才启动一个有边界的 `devflow-code-explorer` 或 `devflow-knowledge-retriever`，并把相关证据问题合并到同一提示。绝不让用户重新调查仓库事实。 5. 同一轮合并询问最多 3 个相互独立的 `user-decision`；存在依赖关系时才逐个询问。每题先给推荐答案和简短理由，适合时提供 2–3 个具体选项。 6. 完成当前决策组后再处理依赖分支。如果答案产生新的重要分支，把它加入决策图。 7. 备选方案会实质改变产品时，给出 2–3 种方案、取舍和推荐；实现细节留给 DESIGN。 8. 复述最终范围、排除项、可观察行为和验收场景。独立使用时按用户需要确认；在 DevFlow REQUIREMENT 中，报告写完并通过校验后必须由协调者展示摘要并取得一次明确确认，不能因为逐项问题已经回答就跳过最终确认门禁。 不要追求固定问题数量。简单任务可能无需提问或只需一个问题，复杂任务可能需要多个。当每个重要分支都已由证据解决、明确决定，或作为有负责人的非阻断未决问题记录后停止。 ## 质量门禁 完成 REQUIREMENT 前确认： - 用户结果和受影响角色明确。 - 范围内与范围外行为不会被合理地混淆。 - 相关时，数据归属、修改方式、权限和兼容性均已决定。 - 验收标准可从外部观察并可测试。 - 假设有证据，或明确标记为默认值。 - 没有答案只停留在“视情况而定”；依赖条件已解决或记录。 - 未决问题区分阻断项与非阻断项。 ## 输出 只写调用方指定的路径。DevFlow 已在 `start` 时物化需求报告模板，应直接填充模板并删除所有 `{{...}}` 占位项，不重建标题或排版。独立使用且没有现成模板时，使用以下中文结构： ```markdown # 需求报告 ## 目标与背景 ## 范围 ## 排除项 ## 决策与理由 ## 验收标准 ## 假设与证据 ## 未决问题 ``` 不要为了标题措辞或排版反复改写正确内容。不要提交代码、写入 `docs/superpowers/specs`、调用 `writing-plans`、生成技术方案或开始实现。 在 DevFlow 中，写完报告不代表 REQUIREMENT 已获批准。调用方必须先结束阶段并进入 `awaiting_approval=REQUIREMENT`，向用户展示摘要；仅在用户明确确认后执行带 `--user-confirmed` 的批准命令。