Discuss Phase

用途

• 把"需求文字看起来清楚了就开干"改成"先把灰色地带和隐含假设摊开讨论"。
• 适合需求有模糊空间、存在多种可行路线、或用户偏好尚未表达的场景。
• 在 /team-intake 完成后、/team-plan 之前推荐触发。

两种模式

discuss（交互质疑模式）

逐项质疑需求中的灰色地带，引导用户做出偏好选择。适用于用户在场、可以即时回答的场景。

assumptions（代码分析优先模式）

先扫描代码库识别现有模式和约束，把代码中已有的事实作为假设基础，仅对代码无法回答的灰色地带提问。适用于代码库已有大量存量逻辑的迭代场景。

默认做法

1. 收集输入：读取 /team-intake 的产出（PRD、需求简报），提取目标、范围、约束和待确认项。

1. 识别灰色地带：按以下维度自动扫描未锁定的决策点：

• UI 交互：状态管理方式、加载/空/错误态策略、动效取舍
• API/数据：分页策略、错误码规范、缓存策略、数据保留周期
• 架构：同步/异步、推/拉、单体/微服务边界
• 业务规则：边界条件处理、权限粒度、审批流程节点
• 质量：性能预算、浏览器兼容基线、可访问性等级
• 部署：环境策略、Feature Flag、灰度比例

1. Forcing Questions（来自 gstack office-hours 方法论）：

• 如果这个功能只能做一件事，那件事是什么？
• 这个功能的用户是谁？他们当前的替代方案是什么？
• 半年后回看，什么情况下我们会认为这是浪费时间？
• 最小可交付版本是什么？跟完整版的差距在哪？
• 有哪些假设一旦不成立，方案就会完全不同？
• 哪个决策如果做错了代价最大？

1. 逐项讨论：每个灰色地带呈现为：

• 背景：为什么这是一个需要讨论的点
• 选项：可行方案列表，每个带利弊分析
• 推荐：基于代码分析和最佳实践的建议
• 等待用户确认或修改

1. 产出 CONTEXT.md：将所有讨论结论写入 docs/artifacts/{slug}/context.md，包含：

• 确认的技术偏好和约束
• 灰色地带的最终决策
• 待进一步验证的假设（标记为 [ASSUMPTION]）
• 明确排除的选项及排除原因

触发信号

• /team-intake 产出中包含 3 个以上待确认项。
• 需求涉及新领域或新技术栈，团队缺乏先验经验。
• 存在多个合理的技术路线，无法在 intake 阶段直接锁定。
• 需求涉及跨团队或跨系统边界。
• 用户显式要求"先讨论一下再开始"。

配套约束

1. 不替代 intake：discuss-phase 消费 intake 的输出，不重新做需求收集。
2. 不替代 plan：discuss-phase 产出偏好和约束，不产出任务拆解和排期。
3. 时间控制：单次 discuss 控制在 6-10 个灰色地带以内，超出时建议分批或升级给 architect。
4. 结论必须落盘：所有讨论结论写入 context.md，不停留在对话上下文中。
5. assumptions 模式红线：代码分析得出的假设必须标注证据来源（文件路径 + 行号），不能凭直觉编造。