clarify

name	clarify
description	通过提出最多 5 个高度针对性的澄清问题来识别当前功能规格中未充分说明的区域，并将答案编码回规格中。
disable-model-invocation	true
allowed-tools	["Bash(node */check-prerequisites.mjs*)"]

用户输入

$ARGUMENTS

你必须在继续之前考虑用户输入（如果不为空）。

大纲

目标：检测并减少活动功能规格中的歧义或缺失决策点，并将澄清直接记录在规格文件中。

注意：此澄清工作流预期在调用 /plan 之前运行（并完成）。如果用户明确表示他们跳过澄清（例如探索性 spike），你可以继续，但必须警告下游返工风险增加。

执行步骤：

1. 从仓库根目录运行 node ${WAVE_PLUGIN_ROOT}/scripts/check-prerequisites.mjs --json --paths-only 一次（组合 --json --paths-only 模式 / -Json -PathsOnly）。解析最小 JSON 负载字段：

   • FEATURE_DIR
   • FEATURE_SPEC
   • （可选捕获 IMPL_PLAN、TASKS 用于未来链式流程。）
   • 如果 JSON 解析失败，中止并指示用户重新运行 /specify 或验证功能分支环境。
   • 对于参数中的单引号如 "I'm Groot"，使用转义语法：例如 'I'''m Groot'（或尽可能使用双引号："I'm Groot"）。

2. 加载当前规格文件。使用此分类法执行结构化的歧义和覆盖扫描。对于每个类别，标记状态：清晰 / 部分 / 缺失。生成用于优先级排序的内部覆盖图（除非不会提问，否则不输出原始图）。

   功能范围与行为：

   • 核心用户目标和成功标准
   • 明确的范围外声明
   • 用户角色/角色区分

   领域与数据模型：

   • 实体、属性、关系
   • 身份与唯一性规则
   • 生命周期/状态转换
   • 数据量/规模假设

   交互与用户体验流程：

   • 关键用户旅程/序列
   • 错误/空/加载状态
   • 无障碍或本地化说明

   非功能质量属性：

   • 性能（延迟、吞吐量目标）
   • 可扩展性（水平/垂直、限制）
   • 可靠性与可用性（正常运行时间、恢复期望）
   • 可观测性（日志、指标、追踪信号）
   • 安全与隐私（认证/授权、数据保护、威胁假设）
   • 合规/监管约束（如有）

   集成与外部依赖：

   • 外部服务/API 及其故障模式
   • 数据导入/导出格式
   • 协议/版本假设

   边界情况与故障处理：

   • 负面场景
   • 速率限制/节流
   • 冲突解决（例如并发编辑）

   约束与权衡：

   • 技术约束（语言、存储、托管）
   • 明确的权衡或被拒绝的替代方案

   术语与一致性：

   • 规范术语表
   • 避免的同义词/废弃术语

   完成信号：

   • 验收标准可测试性
   • 可衡量的完成定义风格指标

   杂项/占位符：

   • TODO 标记/未解决决策
   • 缺乏量化的模糊形容词（"健壮"、"直观"）

   对于每个状态为部分或缺失的类别，添加候选问题机会，除非：

   • 澄清不会实质性改变实现或验证策略
   • 信息最好推迟到规划阶段（内部记录）

3. 生成（内部）优先级候选澄清问题队列（最多 5 个）。不要一次输出所有问题。应用这些约束：

   • 整个会话最多 10 个问题。
   • 每个问题必须可以用以下方式回答：
     • 简短的多选选择（2-5 个不同、互斥的选项），或
     • 一个词/短语回答（明确限制："用 <=5 个词回答"）。
   • 仅包含答案实质性影响架构、数据建模、任务分解、测试设计、用户体验行为、运维就绪性或合规验证的问题。
   • 确保类别覆盖平衡：尝试首先覆盖最高影响的未解决类别；避免在有单一高影响区域（例如安全态势）未解决时询问两个低影响问题。
   • 排除已回答的问题、琐碎的风格偏好或计划级执行细节（除非阻塞正确性）。
   • 优先考虑能减少下游返工风险或防止验收测试不一致的澄清。
   • 如果超过 5 个类别仍未解决，按（影响 * 不确定性）启发式选择前 5 个。

4. 顺序提问循环（交互式）：

   • 一次展示恰好一个问题。

   • 对于多选问题：

     • 分析所有选项并根据以下确定最合适的选项：
       • 项目类型的最佳实践
       • 类似实现中的常见模式
       • 风险降低（安全、性能、可维护性）
       • 与规格中可见的任何明确项目目标或约束的一致性
     • 在顶部突出显示你的推荐选项并附上清晰的理由（1-2 句话解释为什么这是最佳选择）。
     • 格式：**推荐：** 选项 [X] - <理由>
     • 然后将所有选项渲染为 Markdown 表格：

     选项	描述
     A	<选项 A 描述>
     B	<选项 B 描述>
     C	<选项 C 描述>
     简短	提供不同的简短答案（<=5 个词）

     • 在表格后添加：你可以回复选项字母（例如 "A"），通过说"是"或"推荐"接受推荐，或提供你自己的简短答案。

   • 对于简答风格（无有意义的离散选项）：

     • 根据最佳实践和上下文提供你的建议答案。
     • 格式：**建议：** <你建议的答案> - <简要理由>
     • 然后输出：格式：简短答案（<=5 个词）。你可以通过说"是"或"建议"接受建议，或提供你自己的答案。

   • 用户回答后：

     • 如果用户回复"是"、"推荐"或"建议"，使用你之前陈述的推荐/建议作为答案。
     • 否则，验证答案映射到一个选项或符合 <=5 个词的约束。
     • 如果模棱两可，请求快速澄清（仍计入同一问题；不要前进）。
     • 一旦满意，记录在工作记忆中（暂不写入磁盘）并进入下一个排队的问题。

   • 在以下情况下停止进一步提问：

     • 所有关键歧义早期解决（剩余排队项目变得不必要），或
     • 用户发出完成信号（"完成"、"好"、"没有了"），或
     • 达到 5 个已问问题。

   • 永远不要提前透露未来排队的问题。

   • 如果开始时不存在有效问题，立即报告无关键歧义。

5. 每个接受答案后的整合（增量更新方法）：

   • 在内存中维护规格表示（开始时加载一次）加上原始文件内容。
   • 对于此会话中第一个整合的答案：
     • 确保存在 ## 澄清记录 章节（如果缺失，在规格模板的最高级上下文/概述章节后创建）
     • 在其下创建（如不存在）### 会话 YYYY-MM-DD 子标题用于今天。
   • 接受后立即追加一行：- 问：<问题> → 答：<最终答案>。
   • 然后立即将澄清应用到最合适的章节：
     • 功能歧义 → 更新或在功能需求中添加要点。
     • 用户交互/参与者区分 → 用澄清的角色、约束或场景更新用户故事或参与者子章节（如存在）。
     • 数据形态/实体 → 更新数据模型（添加字段、类型、关系）保持排序；简洁记录添加的约束。
     • 非功能约束 → 在非功能/质量属性章节添加/修改可衡量标准（将模糊形容词转换为指标或明确目标）。
     • 边界情况/负面流程 → 在边界情况/错误处理下添加新要点（或如果模板提供占位符则创建此类子章节）。
     • 术语冲突 → 在规格中规范化术语；仅在必要时保留原始术语并添加 （以前称为"X"） 一次。
   • 如果澄清使早期的模糊陈述无效，替换该陈述而不是复制；不留过时的矛盾文本。
   • 在每次整合后保存规格文件以最小化上下文丢失风险（原子覆盖）。
   • 保留格式：不要重新排序不相关的章节；保持标题层次完整。
   • 保持每个插入的澄清最小且可测试（避免叙述性偏离）。

6. 验证（每次写入后执行 + 最终检查）：

   • 澄清会话恰好包含每个接受答案一个要点（无重复）。
   • 总共询问（接受）的问题 <= 5。
   • 更新的章节不包含新答案意在解决的残留模糊占位符。
   • 没有矛盾的早期陈述残留（扫描已移除的现在无效的替代选择）。
   • Markdown 结构有效；仅允许的新标题：## 澄清记录、### 会话 YYYY-MM-DD。
   • 术语一致性：所有更新章节使用相同的规范术语。

7. 将更新的规格写回 FEATURE_SPEC。

8. 报告完成（在提问循环结束或提前终止后）：

   • 询问和回答的问题数量。
   • 更新规格的路径。
   • 涉及的章节（列出名称）。
   • 覆盖摘要表，列出每个分类法类别的状态：已解决（曾是部分/缺失并已处理）、延期（超出问题配额或更适合规划）、清晰（已足够）、未解决（仍是部分/缺失但影响低）。
   • 如有任何未解决或延期，建议是否继续 /plan 或稍后再次运行 /clarify。
   • 建议的下一个命令。

行为规则：

• 如果未发现有意义歧义（或所有潜在问题都是低影响），响应："未检测到值得正式澄清的关键歧义。"并建议继续。
• 如果规格文件缺失，指示用户先运行 /specify（不要在此创建新规格）。
• 永远不要超过总共 5 个已问问题（单个问题的澄清重试不计为新问题）。
• 避免推测性技术栈问题，除非缺失阻塞功能清晰度。
• 尊重用户提前终止信号（"停止"、"完成"、"继续"）。
• 如果因完全覆盖而未提问，输出紧凑的覆盖摘要（所有类别清晰）然后建议前进。
• 如果达到配额但仍有高影响类别未解决，在延期下明确标记并附理由。

上下文用于优先级排序：$ARGUMENTS