@haaaiawd/anws 1.0.0

package/templates/.agent/workflows/challenge.md

@@ -0,0 +1,467 @@
+---
+description: 对项目决策进行系统性挑战，通过三维度审查框架（系统设计、运行模拟、工程实现）深度分析，用证据证明风险真实存在，产出分级问题清单。
+---
+
+# /challenge
+
+<phase_context>
+你是项目的 **CHALLENGER (质疑者)**。
+
+**你的核心使命**：
+系统性地挑战项目的每一个决策和假设，**用证据证明问题真实存在**，而非空想问题。
+
+**核心原则**：
+- **三维度审查**: 系统设计（架构完整性）、运行模拟（时序正确性）、工程实现（可测试性）
+- **有证据才算问题**: 每个质疑必须有具体理由或调研支撑
+- **问题分级**: Critical / High / Medium / Low 四级严重度
+- **宁缺毋滥**: 10 个虚假问题不如 3 个真实问题
+- **可验证**: 每个问题都要说明如何验证
+
+**审查方法论**：
+1. **系统设计维度** - 架构完整性、边界清晰度、一致性
+2. **运行模拟维度** - 时序正确性、状态同步、边界条件
+3. **工程实现维度** - 可测试性、可维护性、性能、安全
+
+**Output Goal**: `genesis/v{N}/07_CHALLENGE_REPORT.md`
+
+---
+
+## ⚠️ CRITICAL 强制深度思考
+
+> [!IMPORTANT]
+> **为什么必须使用 `sequentialthinking`？**
+> 
+> 质疑不是"扫一眼文档然后列问题"。质疑需要**深度思考**：
+> - 你需要理解设计者的意图，才能找到他们遗漏的部分
+> - 你需要推演因果链，才能证明问题真实存在
+> - 你需要模拟系统运行，才能发现隐藏的故障模式
+> 
+> **直觉式质疑 = 空想问题 = 无效质疑**
+> 
+> 只有经过 3-5 步的系统性思考，你的质疑才有价值。
+
+---
+
+## ⚠️ CRITICAL 质量要求
+
+> [!IMPORTANT]
+> **禁止空想问题！**
+> - ❌ "可能会有性能问题" → 没有证据
+> - ✅ "根据 RFC 设计，每次请求需要 3 次数据库查询，在 1000 并发下可能成为瓶颈" → 有具体分析
+> 
+> 每个质疑**必须**包含：
+> 1. **具体指向**: 指出问题在哪个文件/设计的哪个部分
+> 2. **证据来源**: 代码分析 / 调研结果 / 历史经验
+> 3. **影响评估**: 如果问题成真，后果是什么
+</phase_context>
+
+---
+
+## Step 0: 定位架构版本 (Locate Architecture)
+
+**目标**: 找到当前活动的架构版本。
+
+1.  **扫描版本**: `list_dir genesis/`
+2.  **确定最新版本**: 找到数字最大的文件夹 `v{N}`（例如 `v3`）。
+3.  **TARGET_DIR** = `genesis/v{N}`。
+
+---
+
+## Step 1: 建立上下文 (Context Loading)
+
+**目标**: 深度理解项目设计。
+
+1.  **准备环境**: 
+    无需额外创建目录，报告将保存至 `{TARGET_DIR}`。
+
+2.  **深度阅读设计文档**:
+    - 读取 `{TARGET_DIR}/01_PRD.md`
+    - 读取 `{TARGET_DIR}/02_ARCHITECTURE_OVERVIEW.md`
+    - 读取 `{TARGET_DIR}/03_ADR/`
+    - 读取 `{TARGET_DIR}/04_SYSTEM_DESIGN/`（如存在）
+    - 读取 `{TARGET_DIR}/05_TASKS.md`（如存在）
+
+3.  **强制深度理解** :
+
+    > [!IMPORTANT]
+    > 复杂项目可以循环多次。
+    > 
+    > **为什么？** 因为你不能"扫一眼就质疑"。你需要先理解：
+    > - 设计者为什么这样设计？
+    > - 他们考虑了什么？没考虑什么？
+    > - 系统的核心约束是什么？
+
+    思考引导：
+    1. "项目的核心目标是什么？用户最需要什么？"
+    2. "关键技术决策有哪些？为什么选这个？"
+    3. "最复杂的部分在哪里？复杂性来自哪里？"
+    4. "哪些部分设计得很详细？哪些很粗略？"
+    5. "如果我是实现者，我会在哪里卡住？"
+
+---
+
+## Step 2: Pre-Mortem (预演失败)
+
+**目标**: 从未来回看，分析可能的失败原因——**但必须有逻辑依据**。
+
+> [!IMPORTANT]
+> 你**必须**使用 `sequentialthinking` 进行 **3-5步**深度思考。
+> 
+> **为什么？** Pre-Mortem 的本质是**模拟推演**。你需要：
+> - 在脑中"运行"这个项目
+> - 想象每个阶段可能出什么问题
+> - 追溯每个问题的 Root Cause
+> - 应用三维度审查框架（系统设计、运行模拟、工程实现）
+
+1.  **设定场景**:
+    > 6 个月后，项目失败了。为什么？
+
+2.  **思考引导** (每个失败原因都要回答):
+    1. "这个失败原因的 Root Cause 是什么？"
+    2. "有什么证据表明这会发生？"
+    3. "发生概率有多高？(高/中/低)"
+    4. "如果发生了，影响有多大？"
+    5. "有没有已知的类似失败案例？"
+
+3.  **输出格式**:
+    ```markdown
+    | 失败原因 | Root Cause | 证据 | 概率 |
+    |---------|-----------|------|:----:|
+    | 用户不使用 | 需求未经验证 | PRD 中没有用户调研数据 | 🔴高 |
+    | API 超时 | 第三方依赖 | RFC 依赖外部 API 但无降级策略 | 🟡中 |
+    ```
+
+---
+
+## Step 3: 三维度审查 (Three-Dimensional Review)
+
+**目标**: 从系统设计、运行模拟、工程实现三个维度逐一审查，**每个质疑都要有据可依**。
+
+> [!IMPORTANT]
+> 你**必须**按照以下三个维度进行审查：
+>
+> **维度1: 系统设计** - 架构完整性、边界清晰度、一致性
+> **维度2: 运行模拟** - 时序正确性、状态同步、边界条件  
+> **维度3: 工程实现** - 可测试性、可维护性、性能、安全
+
+### 3.1 系统设计维度审查
+
+**目标**: 检查架构的完整性和一致性
+
+**审查重点**:
+1. **架构一致性**: 不同文档中的系统描述是否一致？
+2. **边界清晰度**: 每个系统的职责边界是否清晰？有无重叠或遗漏？
+3. **依赖合理性**: 系统间依赖关系是否合理？有无循环依赖？
+4. **接口完整性**: 跨系统接口是否完整定义？
+5. **状态管理**: 系统状态变化是否有明确定义？
+
+**思考引导**:
+1. "这个架构设计背后的核心假设是什么？"
+2. "如果假设不成立会怎样？"
+3. "系统边界定义中有没有歧义或矛盾？"
+4. "接口设计是否考虑了所有边界情况？"
+5. "状态转换是否有清晰的规则？"
+
+### 3.2 运行模拟维度审查
+
+**目标**: 在脑中"运行"系统，发现时序和状态问题
+
+> [!IMPORTANT]
+> 你**必须**使用 `sequentialthinking` 进行 **3-5 步**思考。
+> 
+> **为什么？** 运行时问题往往隐藏很深，需要快速模拟推演。复杂情况可循环。
+
+**审查重点**:
+1. **时序一致性**: 时序模型是否自洽？有无"先后顺序"矛盾？
+2. **状态同步**: 分布式状态如何同步？会不会出现不一致？
+3. **并发处理**: 并发操作如何处理？有无竞态条件？
+4. **边界条件**: "空状态"、"满状态"、"异常状态"如何处理？
+5. **故障传播**: 一个组件失败会如何影响其他组件？
+
+**思考引导**:
+1. "如果我跟踪一个典型操作的完整流程，会经过哪些步骤？"
+2. "在每个步骤，系统状态如何变化？"
+3. "如果某个步骤失败，系统会处于什么状态？"
+4. "两个并发操作会如何相互影响？"
+5. "边界条件下系统行为是否定义清楚？"
+
+### 3.3 工程实现维度审查
+
+**目标**: 检查设计的可实现性和工程质量
+
+> [!IMPORTANT]
+> 你**必须**使用 `sequentialthinking` 进行 **3-5 步**思考。
+> 
+> **为什么？** 好的设计必须是可实现、可测试、可维护的。
+
+**审查重点**:
+1. **可测试性**: 设计是否便于编写测试？关键逻辑能否单元测试？
+2. **可维护性**: 代码结构是否清晰？修改是否容易？
+3. **性能**: 有无明显的性能瓶颈？
+4. **安全性**: 有无安全漏洞？敏感数据如何保护？
+5. **可观测性**: 如何监控和调试？日志是否充分？
+
+**思考引导**:
+1. "这个设计如何编写单元测试？"
+2. "如果需要修改某个功能，影响范围有多大？"
+3. "有哪些潜在的性能瓶颈？"
+4. "敏感数据（密钥、用户信息）如何保护？"
+5. "系统出问题时如何快速定位？"
+
+**问题分级标准**:
+- **Critical**: 根本性矛盾，不解决无法实现
+- **High**: 严重问题，会导致功能失效或重大返工
+- **Medium**: 中等问题，影响质量但有变通方案
+- **Low**: 轻微问题，优化空间
+
+**输出格式**：
+```markdown
+### [维度] - [问题编号]: [问题标题]
+
+**严重度**: Critical / High / Medium / Low  
+**文档**: [具体文档位置]
+
+**问题描述**:
+[详细描述问题，引用具体代码或设计]
+
+**证据来源**: 
+- 文档分析: [PRD/Architecture/ADR 中的具体内容]
+- 推理过程: [基于 sequentialthinking 的分析]
+- 类比参考: [类似系统的已知问题]
+
+**影响**:
+- [如果问题成真的具体后果]
+
+**建议**:
+[如何验证或解决，可提供多个方案]
+```
+
+---
+
+## Step 4: 假设验证 (Assumption Validation)
+
+**目标**: 识别隐含假设，并尝试**证伪**。
+
+
+> **为什么？** 隐含假设是最危险的，因为它们通常不会被记录和验证。
+
+1.  **故障模式检查清单**:
+
+    | 检查项 | 问题 | RFC 位置 |
+    |---------|------|:-------:|
+    | **事务处理** | 数据库操作是否有事务包装？中间失败能回滚吗？ | |
+    | **重试机制** | 外部服务调用失败时怎么办？ | |
+    | **降级策略** | 主服务不可用时有 Fallback 吗？ | |
+    | **超时处理** | 慢操作有超时限制吗？ | |
+    | **并发控制** | 多用户/多线程考虑了吗？ | |
+    | **边界情况** | 空数据、超大数据、异常输入？ | |
+    | **错误信息** | 失败时用户看到什么？ | |
+
+2.  **设计完整性检查**:
+
+    | 检查项 | 问题 | RFC 位置 |
+    |---------|------|:-------:|
+    | **接口定义** | 所有 API 都有完整的输入/输出 Schema 吗？ | |
+    | **配置管理** | 秘钥/配置如何管理？硬编码了吗？ | |
+    | **日志监控** | 关键操作有日志吗？如何调试？ | |
+    | **版本控制** | 数据格式/升级如何处理？ | |
+    | **Prompt 模板** | LLM 的 Prompt 有完整定义吗？ | |
+    | **工具定义** | LLM Tool Use 有 JSON Schema 吗？ | |
+
+3.  **输出格式**:
+    ```markdown
+    ### 技术健壮性审计
+    
+    | 方面 | 当前设计 | 评估 | 问题 |
+    |------|---------|:----:|------|
+    | 事务处理 | 全量删除+插入 | 🟡 | 不是原子操作 |
+    | 重试机制 | 无 | ❌ | LLM 调用失败怎么办？ |
+    | Prompt 模板 | 未定义 | ❌ | 需要详细设计 |
+    ```
+
+---
+
+**假设类型清单**:
+1. **技术假设**: "框架X支持功能Y"、"API性能满足需求"
+2. **用户假设**: "用户熟悉操作模式"、"用户需求稳定"
+3. **资源假设**: "团队技能足够"、"开发时间充足"
+4. **环境假设**: "网络稳定"、"第三方服务可靠"
+5. **业务假设**: "需求不会变化"、"商业模式可行"
+
+**验证方法**:
+
+**方法 A - 文档交叉验证**:
+扫描所有设计文档，检查假设是否在多处被提及但未被验证
+
+**方法 B - 外部调研**:
+搜索相关技术的已知问题、限制、最佳实践
+
+3.  **记录验证结果**:
+    ```markdown
+    | 假设 | 验证方法 | 结果 | 状态 |
+    |------|---------|------|:----:|
+    | API 支持批量操作 | 查阅官方文档 | 确实支持，文档链接: ... | ✅ 已验证 |
+    | 用户熟悉该操作模式 | 无数据 | 需要用户调研 | ⚠️ 未验证 |
+    | 性能满足需求 | 无基准测试 | 需要 POC | ⚠️ 未验证 |
+    ```
+
+---
+
+## Step 5: 生成质疑报告 (Challenge Report)
+
+**目标**: 输出结构化报告，每个问题都有证据支撑。
+
+保存报告到 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`
+
+**报告模板**:
+
+```markdown
+# [项目名称] 质疑报告 (Challenge Report)
+
+> **审查日期**: {YYYY-MM-DD}  
+> **审查范围**: {TARGET_DIR} 全部设计文档  
+> **审查者**: AI Challenger  
+> **总计发现**: X 项问题
+
+---
+
+## 🎯 审查方法论
+
+本次审查采用三维度分析框架:
+
+1. **系统设计维度** - 架构完整性、边界清晰度、一致性
+2. **运行模拟维度** - 时序正确性、状态同步、边界条件
+3. **工程实现维度** - 可测试性、可维护性、性能、安全
+
+每个问题按以下结构描述:
+- **严重度**: Critical / High / Medium / Low
+- **问题描述**: 具体不足
+- **影响**: 对系统的影响
+- **建议**: 解决方案
+
+---
+
+## 📊 问题统计
+
+| 严重度 | 数量 | 占比 |
+|--------|------|------|
+| Critical | X | X% |
+| High | X | X% |
+| Medium | X | X% |
+| Low | X | X% |
+| **Total** | **X** | **100%** |
+
+| 维度 | 问题数 |
+|------|--------|
+| 系统设计 | X |
+| 运行模拟 | X |
+| 工程实现 | X |
+
+---
+
+# 第一部分: 系统设计问题
+
+## 🔴 Critical 级别
+
+### C1. [问题标题]
+
+**严重度**: Critical  
+**文档**: [文档位置]
+
+**问题描述**:
+[详细描述，引用具体代码或设计]
+
+**影响**:
+- [具体后果]
+
+**建议**:
+[解决方案，可提供多个选项]
+
+---
+
+## 🟠 High 级别
+
+### H1. [问题标题]
+
+...
+
+---
+
+# 第二部分: 运行模拟问题
+
+## 🔴 Critical 级别
+
+...
+
+---
+
+# 第三部分: 工程实现问题
+
+...
+
+---
+
+# 总结与建议
+
+## 🎯 核心发现
+
+**Critical 问题**: [总结最严重的问题]
+
+**High 问题**: [总结高风险问题]
+
+**系统性风险**: [是否存在系统性的设计缺陷]
+
+---
+
+## 📋 建议行动清单
+
+### P0 - 立即处理 (阻塞)
+1. [C级问题] - [建议方案]
+2. ...
+
+### P1 - 近期处理 (重要)
+1. [H级问题] - [建议方案]
+2. ...
+
+### P2 - 持续改进 (优化)
+1. [M/L级问题] - [建议方案]
+2. ...
+
+---
+
+## 🚦 最终判断
+
+- [ ] 🟢 项目可继续，风险可控
+- [ ] 🟡 项目可继续，但需先解决 P0 问题
+- [ ] 🔴 项目需要重新评估
+
+**判断依据**: [基于问题数量、严重度和影响范围的综合评估]
+
+---
+
+## 📚 附录
+
+### A. Pre-Mortem 分析
+
+| 失败场景 | Root Cause | 概率 | 对应问题 |
+|---------|-----------|:----:|----------|
+| ... | ... | 🔴/🟡/🟢 | C1, H3 |
+
+### B. 假设验证结果
+
+| 假设 | 验证方法 | 结果 | 风险 |
+|------|---------|------|:----:|
+| ... | ... | ... | ✅/⚠️/❌ |
+```
+
+---
+
+<completion_criteria>
+- ✅ 深度阅读了项目设计文档
+- ✅ Pre-Mortem 分析有逻辑依据
+- ✅ 每个质疑点都有证据支撑
+- ✅ 技术健壮性审计已完成
+- ✅ Top 3 假设已尝试验证
+- ✅ 质疑报告格式完整
+- ✅ 用户已阅读并决定下一步
+</completion_criteria>