@haaaiawd/anws 2.2.0 → 2.2.2

package/templates/.agents/workflows/challenge.md

@@ -1,364 +1,332 @@
----
-description: "对项目的设计、任务与实现进行系统性挑战，用证据证明风险真实存在。适用于设计完成后的质量把关、编码前的决策复核，以及实现后的静态忠实度审查。产出 07_CHALLENGE_REPORT.md。"
----
-
-# /challenge
-
-<phase_context>
-你是项目的 **CHALLENGER (质疑者)**。
-
-**你的核心使命**：
-系统性地挑战项目的每一个决策和假设，**用证据证明问题真实存在**，而非空想问题。
-
-**你审查的主对象不是文档本身，而是系统是否忠于其规范契约。**
-
-**规范契约** 由以下来源共同组成：
-- **业务契约**: `01_PRD.md` 中的业务目标、主流程、约束、验收语义
-- **架构契约**: `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/` 中的系统边界、接口、状态与技术决策
-- **任务契约**: `05_TASKS.md` 对实现承接、覆盖范围、验证方式作出的承诺
-- **文档契约**: README / 使用说明 / 验证路径对评审者和实施者作出的操作承诺（如在当前审查范围内可获得）
-- **运行契约**: 错误语义、审计边界、日志边界、幂等、重试、超时、降级、调度与长期运行承诺
-
-**核心原则**：
-- **规范契约优先**: 先识别系统承诺了什么，再判断这些承诺是否闭合，最后再用工程证据坐实
-- **三维度审查**: 系统设计（架构完整性）、运行模拟（时序正确性）、工程实现（可测试性）
-- **承诺闭合优先于形式完整**: 比起“看起来像个完整项目”，更优先发现“系统最不能撒谎的地方是否失真”
-- **高信号输出**: 聚焦真正影响判断的根因问题，避免把报告写成低价值 checklist
-- **有证据才算问题**: 每个质疑必须有具体理由或调研支撑
-- **问题分级**: Critical / High / Medium / Low 四级严重度
-- **宁缺毋滥**: 10 个虚假问题不如 3 个真实问题
-- **可验证**: 每个问题都要说明如何验证
-
-**审查方法论**：
-1. **系统设计维度** - 架构完整性、边界清晰度、一致性
-2. **运行模拟维度** - 时序正确性、状态同步、边界条件
-3. **工程实现维度** - 可测试性、可维护性、性能、安全
-
-**Output Goal**: `.anws/v{N}/07_CHALLENGE_REPORT.md`
-
----
-
-## ⚠️ CRITICAL 深度思考要求
-
-> [!IMPORTANT]
-> **质疑需要深度思考，思考方式基于模型能力和任务复杂度。**
-> 
-> **核心判断规则**：
-> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
-> - **有 CoT 模型 + 简单质疑**（问题明确、步骤 < 5）→ 用思考引导问题组织自然 CoT
-> - **有 CoT 模型 + 复杂质疑**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
-> 
-> 质疑不是"扫一眼文档然后列问题"。质疑需要**深度思考**：
-> - 你需要理解设计者的意图，才能找到他们遗漏的部分
-> - 你需要推演因果链，才能证明问题真实存在
-> - 你需要模拟系统运行，才能发现隐藏的故障模式
-
----
-
-## ⚠️ CRITICAL 质量要求
-
-> [!IMPORTANT]
-> **禁止空想问题！**
-> - ❌ "可能会有性能问题" → 没有证据
-> - ✅ "根据 RFC 设计，每次请求需要 3 次数据库查询，在 1000 并发下可能成为瓶颈" → 有具体分析
-> 
-> 每个质疑**必须**包含：
-> 1. **具体指向**: 指出问题在哪个文件/设计的哪个部分
-> 2. **证据来源**: 代码分析 / 调研结果 / 历史经验
-> 3. **影响评估**: 如果问题成真，后果是什么
-
----
-
-## 🎚️ 严重度分级
-
-| 等级 | 判定标准 | 所需行动 |
-|:----:|---------|---------|
-| **Critical** 🔴 | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
-| **High** 🟠 | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
-| **Medium** 🟡 | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
-| **Low** 🟢 | 润色项或轻微不一致。 | P3 — 后续跟踪 |
-
-> [!NOTE]
-> 报告输出时，**优先保留 Critical / High**。Medium / Low 只在确实影响判断或能形成稳定改进方向时保留，避免报告膨胀。
-
----
-
-## Step 0: 定位架构版本 (Locate Architecture)
-
-**目标**: 找到当前活动的架构版本。
-
-1.  **扫描版本**: `list_dir .anws/`
-2.  **确定最新版本**: 找到数字最大的文件夹 `v{N}`（例如 `v3`）。
-3.  **TARGET_DIR** = `.anws/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 1.5: 规范来源识别与承诺模型 (Contract Modeling)
-
-**目标**: 在任何详细审查之前，先明确**系统到底承诺了什么**。
-
-> [!IMPORTANT]
-> 不要一上来就扫问题。先抽取**规范来源集合**与**承诺模型**。
-> 这是本工作流的第一性动作。
-
-1.  **识别规范来源**:
-    - `01_PRD.md` → 业务契约
-    - `02_ARCHITECTURE_OVERVIEW.md` + `03_ADR/` + `04_SYSTEM_DESIGN/` → 架构契约
-    - `05_TASKS.md` → 任务契约
-    - 当前审查范围内可读到的 README / 验证说明 / 配置说明 → 文档契约
-
-2.  **构建最小语义模型**（内部使用，不必原样照抄到最终报告）:
-    - **规范来源清单**: 每类契约来自哪些文件
-    - **承诺清单**: 每条关键承诺的来源、对象、失败后果
-    - **任务承接映射**: 若 `05_TASKS.md` 存在，记录哪些承诺已被任务覆盖，哪些没有
-
-3.  **至少抽取以下承诺类型**:
-    - **结果承诺**: 系统最终要达成什么业务结果
-    - **状态承诺**: 状态机、资源生命周期、越序约束是否明确
-    - **时间承诺**: 时间窗口、TTL、过期、调度、保留期
-    - **错误承诺**: 错误码、错误结构、默认失败路径是否一致
-    - **安全承诺**: 鉴权、授权、数据隔离、敏感信息边界
-    - **审计承诺**: 哪些操作应留痕、留痕粒度、问责边界
-    - **运行承诺**: 幂等、重试、超时、降级、可观测性
-
-4.  **输出一个简明承诺模型摘要**:
-    ```markdown
-    | 承诺类型 | 承诺摘要 | 契约来源 | 失真风险 |
-    |---------|---------|---------|---------|
-    | 错误承诺 | 所有 API 失败路径返回统一错误结构 | PRD §X / ADR-00Y | 客户端分叉处理 |
-    | 审计承诺 | 所有关键业务读写操作需留痕 | PRD §Y / System Design §Z | 无法问责 / 排障 |
-    | 运行承诺 | 写操作可安全重试且不重复副作用 | PRD §A / Architecture §B | 重复扣款/发货 |
-    ```
-
----
-
-## Step 2: Pre-Mortem (预演失败)
-
-**目标**: 从未来回看，分析可能的失败原因——**但必须有逻辑依据**。
-
-> [!IMPORTANT]
-> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**进行深度思考。
-> 
-> **为什么？** Pre-Mortem 的本质是**模拟推演**。你需要：
-> - 在脑中"运行"这个项目
-> - 想象每个阶段可能出什么问题
-> - 追溯每个问题的 Root Cause
-> - 应用三维度审查框架（系统设计、运行模拟、工程实现）
-
-1.  **设定场景**:
-    > 6 个月后，项目失败了。为什么？
-
-2.  **优先追问以下失真类型**:
-    - **写操作副作用失真**: 重试后是否可能重复产生副作用？
-    - **状态/时间口径失真**: 状态转换、时间字段、窗口计算是否偏离契约？
-    - **失败语义失真**: 默认 401/404/校验失败路径是否仍符合统一承诺？
-    - **审计/观测失真**: 留痕边界是否缩水？日志是否引入新的泄露面？
-    - **任务承接失真**: 关键承诺是否根本没有落入实现任务？
-
-3.  **思考引导** (每个失败原因都要回答):
-    1. "这个失败原因的 Root Cause 是什么？"
-    2. "它违背了哪条规范契约？"
-    3. "有什么证据表明这会发生？"
-    4. "发生概率有多高？(高/中/低)"
-    5. "如果发生了，影响有多大？"
-    6. "有没有已知的类似失败案例？"
-
-4.  **输出格式**:
-    ```markdown
-    | 失败原因 | 失真契约 | Root Cause | 证据 | 概率 |
-    |---------|---------|-----------|------|:----:|
-    | 重复发货 | 写操作承诺 | 无幂等键 / 无去重状态 | PRD + API 设计未定义重试语义 | 🔴高 |
-    | 错误响应分叉 | 错误契约 | 默认失败路径未统一包装 | 401/404 由框架默认返回 | 🟡中 |
-    ```
-
----
-
-## Step 2.5: 审查模式判定 (Review Mode Detection)
-
-**目标**: 在开始任何审查之前，先确定**本次应该审查什么**——避免无脑双跑。
-
-根据上下文信号推断模式：
-
-| 信号 | 推断模式 |
-|------|---------|
-| `05_TASKS.md` 不存在 | `DESIGN` — 只能审查设计 |
-| 用户明确提到任务/任务清单有问题 | `TASKS` |
-| 用户明确提到实现代码 / 交付验收 / 静态代码质检 | `CODE` |
-| 用户明确说「全面审查」或「都看看」 | `FULL` |
-| `05_TASKS.md` 存在，但用户无明确指向 | `DESIGN`，任务审查与代码审查**按需自适应升级** |
-| 本轮是修复后的复查，上轮有任务类问题 | `FULL` |
-
-**如果模式仍不明确，直接询问用户**：
-
+---
+
+## description: "对项目的设计、任务与实现进行系统性挑战，用证据证明风险真实存在。适用于设计完成后的质量把关、编码前的决策复核，以及实现后的静态忠实度审查。产出 07_CHALLENGE_REPORT.md。"
+
+# /challenge
+
+你是项目的 **CHALLENGER (质疑者)**。
+
+**你的核心使命**：
+系统性地挑战项目的每一个决策和假设，**用证据证明问题真实存在**，而非空想问题。
+
+**你审查的主对象不是文档本身，而是系统是否忠于其规范契约。**
+
+**规范契约** 由以下来源共同组成：
+
+- **业务契约**: `01_PRD.md` 中的业务目标、主流程、约束、验收语义
+- **架构契约**: `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/` 中的系统边界、接口、状态与技术决策
+- **任务契约**: `05_TASKS.md` 对实现承接、覆盖范围、验证方式作出的承诺
+- **文档契约**: README / 使用说明 / 验证路径对评审者和实施者作出的操作承诺（如在当前审查范围内可获得）
+- **运行契约**: 错误语义、审计边界、日志边界、幂等、重试、超时、降级、调度与长期运行承诺
+
+**核心原则**：
+
+- **规范契约优先**: 先识别系统承诺了什么，再判断这些承诺是否闭合，最后再用工程证据坐实
+- **三维度审查**: 系统设计（架构完整性）、运行模拟（时序正确性）、工程实现（可测试性）
+- **承诺闭合优先于形式完整**: 比起“看起来像个完整项目”，更优先发现“系统最不能撒谎的地方是否失真”
+- **高信号输出**: 聚焦真正影响判断的根因问题，避免把报告写成低价值 checklist
+- **有证据才算问题**: 每个质疑必须有具体理由或调研支撑
+- **问题分级**: Critical / High / Medium / Low 四级严重度
+- **宁缺毋滥**: 10 个虚假问题不如 3 个真实问题
+- **可验证**: 每个问题都要说明如何验证
+
+**审查方法论**：
+
+1. **系统设计维度** - 架构完整性、边界清晰度、一致性
+2. **运行模拟维度** - 时序正确性、状态同步、边界条件
+3. **工程实现维度** - 可测试性、可维护性、性能、安全
+
+**Output Goal**: `.anws/v{N}/07_CHALLENGE_REPORT.md`
+
+---
+
+## ⚠️ CRITICAL 深度思考要求
+
+> [!IMPORTANT]
+> **质疑需要深度思考，思考方式基于模型能力和任务复杂度。**
+>
+> **核心判断规则**：
+>
+> - **无 CoT 模型** → **必须调用** `sequential-thinking` CLI
+> - **有 CoT 模型 + 简单质疑**（问题明确、步骤 < 5）→ 用思考引导问题组织自然 CoT
+> - **有 CoT 模型 + 复杂质疑**（需要多方案比较、修正前提）→ 调用 `sequential-thinking` CLI
+>
+> 质疑不是"扫一眼文档然后列问题"。质疑需要**深度思考**：
+>
+> - 你需要理解设计者的意图，才能找到他们遗漏的部分
+> - 你需要推演因果链，才能证明问题真实存在
+> - 你需要模拟系统运行，才能发现隐藏的故障模式
+
+---
+
+## ⚠️ CRITICAL 质量要求
+
+> [!IMPORTANT]
+> **禁止空想问题！**
+>
+> - ❌ "可能会有性能问题" → 没有证据
+> - ✅ "根据 RFC 设计，每次请求需要 3 次数据库查询，在 1000 并发下可能成为瓶颈" → 有具体分析
+>
+> 每个质疑**必须**包含：
+>
+> 1. **具体指向**: 指出问题在哪个文件/设计的哪个部分
+> 2. **证据来源**: 代码分析 / 调研结果 / 历史经验
+> 3. **影响评估**: 如果问题成真，后果是什么
+
+---
+
+## 🎚️ 严重度分级
+
+
+| 等级              | 判定标准                 | 所需行动                          |
+| --------------- | -------------------- | ----------------------------- |
+| **Critical** 🔴 | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
+| **High** 🟠     | 大概率导致返工或失败的严重风险。     | P1 — 在 forge 之前修复             |
+| **Medium** 🟡   | 有变通方案的质量隐患。          | P2 — 实现阶段修复                   |
+| **Low** 🟢      | 润色项或轻微不一致。           | P3 — 后续跟踪                     |
+
+
+> [!NOTE]
+> 报告输出时，**优先保留 Critical / High**。Medium / Low 只在确实影响判断或能形成稳定改进方向时保留，避免报告膨胀。
+
+---
+
+## Step 0: 定位架构版本 (Locate Architecture)
+
+**目标**: 找到当前活动的架构版本。
+
+1. **扫描版本**: `list_dir .anws/`
+2. **确定最新版本**: 找到数字最大的文件夹 `v{N}`（例如 `v3`）。
+3. **TARGET_DIR** = `.anws/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 1.5: 规范来源识别与承诺模型 (Contract Modeling)
+
+**目标**: 在任何详细审查之前，先明确**系统到底承诺了什么**。
+
+> [!IMPORTANT]
+> 不要一上来就扫问题。先抽取**规范来源集合**与**承诺模型**。
+> 这是本工作流的第一性动作。
+
+1. **识别规范来源**:
+  - `01_PRD.md` → 业务契约
+    - `02_ARCHITECTURE_OVERVIEW.md` + `03_ADR/` + `04_SYSTEM_DESIGN/` → 架构契约
+    - `05_TASKS.md` → 任务契约
+    - 当前审查范围内可读到的 README / 验证说明 / 配置说明 → 文档契约
+2. **构建最小语义模型**（内部使用，不必原样照抄到最终报告）:
+  - **规范来源清单**: 每类契约来自哪些文件
+    - **承诺清单**: 每条关键承诺的来源、对象、失败后果
+    - **任务承接映射**: 若 `05_TASKS.md` 存在，记录哪些承诺已被任务覆盖，哪些没有
+3. **至少抽取以下承诺类型**:
+  - **结果承诺**: 系统最终要达成什么业务结果
+    - **状态承诺**: 状态机、资源生命周期、越序约束是否明确
+    - **时间承诺**: 时间窗口、TTL、过期、调度、保留期
+    - **错误承诺**: 错误码、错误结构、默认失败路径是否一致
+    - **安全承诺**: 鉴权、授权、数据隔离、敏感信息边界
+    - **审计承诺**: 哪些操作应留痕、留痕粒度、问责边界
+    - **运行承诺**: 幂等、重试、超时、降级、可观测性
+4. **输出一个简明承诺模型摘要**:
+  ```markdown
+    | 承诺类型 | 承诺摘要 | 契约来源 | 失真风险 |
+    |---------|---------|---------|---------|
+    | 错误承诺 | 所有 API 失败路径返回统一错误结构 | PRD §X / ADR-00Y | 客户端分叉处理 |
+    | 审计承诺 | 所有关键业务读写操作需留痕 | PRD §Y / System Design §Z | 无法问责 / 排障 |
+    | 运行承诺 | 写操作可安全重试且不重复副作用 | PRD §A / Architecture §B | 重复扣款/发货 |
+  ```
+
+---
+
+## Step 2: Pre-Mortem (预演失败)
+
+**目标**: 从未来回看，分析可能的失败原因——**但必须有逻辑依据**。
+
+> [!IMPORTANT]
+> 你**必须**使用 `sequential-thinking` skill 组织 **3-5 个 thought**进行深度思考。
+>
+> **为什么？** Pre-Mortem 的本质是**模拟推演**。你需要：
+>
+> - 在脑中"运行"这个项目
+> - 想象每个阶段可能出什么问题
+> - 追溯每个问题的 Root Cause
+> - 应用三维度审查框架（系统设计、运行模拟、工程实现）
+
+1. **设定场景**:
+  > 6 个月后，项目失败了。为什么？
+2. **优先追问以下失真类型**:
+  - **写操作副作用失真**: 重试后是否可能重复产生副作用？
+    - **状态/时间口径失真**: 状态转换、时间字段、窗口计算是否偏离契约？
+    - **失败语义失真**: 默认 401/404/校验失败路径是否仍符合统一承诺？
+    - **审计/观测失真**: 留痕边界是否缩水？日志是否引入新的泄露面？
+    - **任务承接失真**: 关键承诺是否根本没有落入实现任务？
+3. **思考引导** (每个失败原因都要回答):
+  1. "这个失败原因的 Root Cause 是什么？"
+  2. "它违背了哪条规范契约？"
+  3. "有什么证据表明这会发生？"
+  4. "发生概率有多高？(高/中/低)"
+  5. "如果发生了，影响有多大？"
+  6. "有没有已知的类似失败案例？"
+4. **输出格式**:
+  ```markdown
+    | 失败原因 | 失真契约 | Root Cause | 证据 | 概率 |
+    |---------|---------|-----------|------|:----:|
+    | 重复发货 | 写操作承诺 | 无幂等键 / 无去重状态 | PRD + API 设计未定义重试语义 | 🔴高 |
+    | 错误响应分叉 | 错误契约 | 默认失败路径未统一包装 | 401/404 由框架默认返回 | 🟡中 |
+  ```
+
+---
+
+## Step 2.5: 审查模式判定 (Review Mode Detection)
+
+**目标**: 在开始任何审查之前，先确定**本次应该审查什么**——避免无脑双跑。
+
+根据上下文信号推断模式：
+
+
+| 信号                         | 推断模式                          |
+| -------------------------- | ----------------------------- |
+| `05_TASKS.md` 不存在          | `DESIGN` — 只能审查设计             |
+| 用户明确提到任务/任务清单有问题           | `TASKS`                       |
+| 用户明确提到实现代码 / 交付验收 / 静态代码质检 | `CODE`                        |
+| 用户明确说「全面审查」或「都看看」          | `FULL`                        |
+| `05_TASKS.md` 存在，但用户无明确指向  | `DESIGN`，任务审查与代码审查**按需自适应升级** |
+| 本轮是修复后的复查，上轮有任务类问题         | `FULL`                        |
+
+
+**如果模式仍不明确，直接询问用户**：
+
 > 本次审查侧重什么？
+>
 > 1. **设计/架构**（design-reviewer）— 架构完整性、接口、运行时行为
 > 2. **任务清单**（task-reviewer）— 任务质量、REQ 覆盖、US 完整性
 > 3. **实现代码**（code-reviewer）— 契约忠实度、测试漂移、回流遗漏
 > 4. **全面审查**（全都跑）
 
 **设置** `REVIEW_MODE` = `DESIGN` / `TASKS` / `CODE` / `FULL`，后续步骤依据此值触发。
-
----
-
-## Step 3: 设计审查 (Design Review)
-
-**触发条件**: `REVIEW_MODE` = `DESIGN` 或 `FULL`
-
-> 如果 `REVIEW_MODE` = `TASKS`，**跳过本步骤**，直接进入 Step 3.5。
-
-调用 `design-reviewer` skill：
-- 输入: `{TARGET_DIR}` 下的 `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`, `04_SYSTEM_DESIGN/`
-- 输出: 设计审查发现清单（含严重度分级 + 文档关联）
-
-**使用方式要求**:
-- 将 `design-reviewer` 视为**规范契约的设计证据层**，不是最终结论本身
-- 优先要求其证明：哪些契约在系统边界、接口、状态、时序、错误路径上没有闭合
-
-**收集发现**，暂存待 Step 5 合并。
-
----
-
-## Step 3.5: 任务审查 (Task Review)
-
-**触发条件**（满足任一即执行，`05_TASKS.md` 必须存在）：
-
-1. `REVIEW_MODE` = `TASKS` 或 `FULL`
-2. **自适应升级**：`REVIEW_MODE` = `DESIGN`，且 design-reviewer 的发现满足以下任一条件：
-   - 存在「架构组件在任务中无覆盖」类问题（对应 task-reviewer Pass D2）
-   - Critical/High 级设计问题超过 3 条，需确认是否已有任务跟进
-
-**自适应升级时，询问用户**：
-
-> 设计审查发现 {N} 个问题可能涉及任务覆盖不足，是否追加任务审查？
-> 1. 是，追加 task-reviewer
-> 2. 否，继续
-
-如触发，调用 `task-reviewer` skill：
-- 输入: `{TARGET_DIR}` 下的 `05_TASKS.md`, `01_PRD.md`, `02_ARCHITECTURE_OVERVIEW.md`, `03_ADR/`, `04_SYSTEM_DESIGN/`
-- 输出: 任务审查报告（含契约覆盖、基础单测承接、REQ 覆盖率、US 完整性 + 问题清单）
-
-**使用方式要求**:
-- 将 `task-reviewer` 视为**规范契约在任务层的承接证据**
-- 优先确认：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴
-- 额外确认：公共契约是否被任务和验证接住，基础层低依赖逻辑是否被单元测试充分承接，而不是只靠高层集成测试兜底
 
-> [!IMPORTANT]
-> **若 `04_SYSTEM_DESIGN/` 存在，则 task-reviewer 必须读取。**
-> 如任务涉及公共契约而 `04_SYSTEM_DESIGN/` 缺失，不应静默降级，而应在审查中明确标记为“证据不足 / 设计契约缺口”。
-
-**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Task review skipped`（附原因）。
+---
+
+## Step 3: 设计审查 (Design Review)
+
+**触发条件**: `REVIEW_MODE` = `DESIGN` 或 `FULL`
+
+> 若 `REVIEW_MODE` = `TASKS`，**跳过本步骤**，直接进入 Step 3.5。
+
+完整遵从 `**design-reviewer`** skill（输入范围、Pass、输出结构均以 skill 为准）。
+
+**收集发现**，暂存 Step 5。
 
 ---
 
-## Step 3.7: 代码审查 (Code Review)
+## Step 3.5: 任务审查 (Task Review)
+
+**触发条件**（满足任一即执行，`05_TASKS.md` 必须存在）：
+
+1. `REVIEW_MODE` = `TASKS` 或 `FULL`
+2. **自适应升级**：`REVIEW_MODE` = `DESIGN`，且 design-reviewer 发现指向任务覆盖不足（见 skill 与上轮输出）。
+
+升级前询问用户是否追加 task-reviewer（是 / 否）。
+
+如触发，完整遵从 `**task-reviewer`** skill（含 `04_SYSTEM_DESIGN/` 必读规则，详见 skill）。
+
+**收集发现**，暂存 Step 5。跳过则 `Task review skipped` + 原因。
+
+---
 
-**触发条件**（满足任一即执行，`src/` 必须存在）：
+## Step 3.7: 代码审查 (Code Review)
 
-1. `REVIEW_MODE` = `CODE` 或 `FULL`
-2. **自适应升级**：`REVIEW_MODE` = `DESIGN` 或 `TASKS`，且发现满足以下任一条件：
-   - 契约已定义、任务已承接，但需要确认实现是否忠于这些承诺
-   - 存在“测试可能只是表面覆盖”的高风险信号
-   - 存在“代码里可能出现未回流的新公共契约”的高风险信号
+**触发**：同上 `REVIEW_MODE` / 自适应规则；`src/` 须存在。
 
-如触发，调用 `code-reviewer` skill：
-- 输入: 当前工作目录下的 `src/`, `{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`, 如存在再加 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`
-- 输出: 代码审查报告（Contract Drift / Task Drift / Test Drift / Missing Change Backflow / Foundational Test Gaps + 安全与测试摘要）
+完整遵从 `**code-reviewer`** skill（静态边界、输入、Lens、输出结构、跳过协议一概以 skill 为准——本节不重复）。
 
-**使用方式要求**:
-- 将 `code-reviewer` 视为**实现侧证据层**，不是泛化风格审查器
-- 优先确认：实现是否忠于既有契约与任务承诺，而不是先盯代码美观度
-- 它必须是**纯静态审查**：不启动项目、不跑测试、不修改代码
+**执行方式**：宿主支持子代理时 **优先**委派子代理执行 `code-reviewer`；否则由当前会话执行（协议相同）。
 
-**收集发现**，暂存待 Step 5 合并。如跳过，记录 `Code review skipped`（附原因）。
+**收集发现** 待 Step 5 合并；跳过则 `Code review skipped` + 一行原因。
 
 ---
 
 ## Step 4: 承诺闭合验证与假设证伪 (Closure Validation)
-
-**目标**: 识别隐含假设，并验证关键承诺在边界条件下是否**真正闭合**。
-
-> **为什么？** 隐含假设是最危险的，因为它们通常不会被记录和验证。
-
-1.  **承诺闭合检查清单**:
-
-    | 检查维度 | 核心问题 | 契约位置 |
-    |---------|---------|:-------:|
-    | **重复态** | 同一请求再来一次，是否仍忠于原承诺？ | |
-    | **失败态** | 超时、部分失败、外部依赖失败时，承诺是否仍成立？ | |
-    | **默认态** | 框架默认错误路径 / 默认资源路径是否与系统契约一致？ | |
-    | **运行态** | 调度、清理、保留期、长期运行行为是否有闭环？ | |
-    | **并发态** | 多用户/并发冲突时，状态与副作用是否可控？ | |
-    | **观测态** | 是否留有足够日志/审计证据，同时不扩大泄露面？ | |
-
-2.  **技术与运行健壮性检查**:
-
-    | 检查项 | 问题 | 契约位置 |
-    |---------|------|:-------:|
-    | **事务处理** | 关键写操作是否有原子性保障？中间失败能回滚吗？ | |
-    | **重试机制** | 外部服务调用失败时怎么办？是否会扩大副作用？ | |
-    | **降级策略** | 主服务不可用时有 Fallback 吗？ | |
-    | **超时处理** | 慢操作有超时限制吗？ | |
-    | **接口定义** | 所有关键 API 都有完整输入/输出/错误 Schema 吗？ | |
-    | **配置管理** | 秘钥/配置如何管理？硬编码了吗？ | |
-    | **日志监控** | 关键操作有日志吗？日志是否越界记录敏感信息？ | |
-    | **版本控制** | 数据格式/升级如何处理？ | |
-    | **Prompt 模板** | LLM 的 Prompt 有完整定义吗？ | |
-    | **工具定义** | LLM Tool Use 有 JSON Schema 吗？ | |
-
-3.  **契约与验证责任闭合检查**:
-
-    | 检查项 | 问题 | 契约位置 |
-    |---------|------|:-------:|
-    | **契约承接** | 所有公共契约是否都有实现任务承接？ | |
-    | **验证承接** | 所有高风险公共契约是否都有至少一层明确验证承接？ | |
-    | **基础单测** | 基础层、共享层、纯逻辑层是否默认获得单元测试承接？ | |
-    | **错误路径** | 契约的失败态、边界态是否有对应测试责任？ | |
-    | **回归责任** | 影响既有关键能力的变更是否有最小回归验证？ | |
-
-4.  **记录验证结果**（内部分析可详细，最终报告只保留高信号摘要）:
-
-    ```markdown
-    | 项目 | 结论 | 证据 | 对应问题 |
-    |------|------|------|----------|
-    | 重复态 | Pass / Partial / Fail | ... | CH-01 |
-    | 失败态 | Pass / Partial / Fail | ... | CH-02 |
-    | 默认态 | Pass / Partial / Fail | ... | CH-03 |
-    | 运行态 | Pass / Partial / Fail | ... | CH-04 |
-    ```
-
+
+**目标**: 识别隐含假设，并验证关键承诺在边界条件下是否**真正闭合**。
+
+> **为什么？** 隐含假设是最危险的，因为它们通常不会被记录和验证。
+
+1. **承诺闭合检查清单**:
+
+  | 检查维度    | 核心问题                        | 契约位置 |
+  | ------- | --------------------------- | ---- |
+  | **重复态** | 同一请求再来一次，是否仍忠于原承诺？          |      |
+  | **失败态** | 超时、部分失败、外部依赖失败时，承诺是否仍成立？    |      |
+  | **默认态** | 框架默认错误路径 / 默认资源路径是否与系统契约一致？ |      |
+  | **运行态** | 调度、清理、保留期、长期运行行为是否有闭环？      |      |
+  | **并发态** | 多用户/并发冲突时，状态与副作用是否可控？       |      |
+  | **观测态** | 是否留有足够日志/审计证据，同时不扩大泄露面？     |      |
+
+2. **技术与运行健壮性检查**:
+
+  | 检查项           | 问题                              | 契约位置 |
+  | ------------- | ------------------------------- | ---- |
+  | **事务处理**      | 关键写操作是否有原子性保障？中间失败能回滚吗？         |      |
+  | **重试机制**      | 外部服务调用失败时怎么办？是否会扩大副作用？          |      |
+  | **降级策略**      | 主服务不可用时有 Fallback 吗？            |      |
+  | **超时处理**      | 慢操作有超时限制吗？                      |      |
+  | **接口定义**      | 所有关键 API 都有完整输入/输出/错误 Schema 吗？ |      |
+  | **配置管理**      | 秘钥/配置如何管理？硬编码了吗？                |      |
+  | **日志监控**      | 关键操作有日志吗？日志是否越界记录敏感信息？          |      |
+  | **版本控制**      | 数据格式/升级如何处理？                    |      |
+  | **Prompt 模板** | LLM 的 Prompt 有完整定义吗？            |      |
+  | **工具定义**      | LLM Tool Use 有 JSON Schema 吗？   |      |
+
+3. **契约与验证责任闭合检查**:
+
+  | 检查项      | 问题                        | 契约位置 |
+  | -------- | ------------------------- | ---- |
+  | **契约承接** | 所有公共契约是否都有实现任务承接？         |      |
+  | **验证承接** | 所有高风险公共契约是否都有至少一层明确验证承接？  |      |
+  | **基础单测** | 基础层、共享层、纯逻辑层是否默认获得单元测试承接？ |      |
+  | **错误路径** | 契约的失败态、边界态是否有对应测试责任？      |      |
+  | **回归责任** | 影响既有关键能力的变更是否有最小回归验证？     |      |
+
+4. **记录验证结果**（内部分析可详细，最终报告只保留高信号摘要）:
+  ```markdown
+    | 项目 | 结论 | 证据 | 对应问题 |
+    |------|------|------|----------|
+    | 重复态 | Pass / Partial / Fail | ... | CH-01 |
+    | 失败态 | Pass / Partial / Fail | ... | CH-02 |
+    | 默认态 | Pass / Partial / Fail | ... | CH-03 |
+    | 运行态 | Pass / Partial / Fail | ... | CH-04 |
+  ```
+
 ---
 
 ## Step 4.5: 审查门禁 (Review Gate)
@@ -369,57 +337,58 @@ description: "对项目的设计、任务与实现进行系统性挑战，用证
 > **如果最新 `07_CHALLENGE_REPORT.md` 中存在未处理的 Critical 问题，不得直接进入 `/forge`。**
 >
 > 处理方式：
+>
 > - 通过 `/change` 消化当前版本内可收敛的问题
 > - 或通过 `/genesis` / `/design-system` 重开设计前提
 >
 > 如仅存在 High 问题，可由用户显式签名决定是否继续；AUTO 模式不得自动穿过这一关。
-
-## Step 5: 生成质疑报告 (Challenge Report)
-
-**目标**: 输出结构化报告，每个问题都有证据支撑，并采用**问题发现优先**的紧凑结构。
-
-保存报告到 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`
-
-**报告模板**:
-
-```markdown
-# [项目名称] 质疑报告 (Challenge Report)
-
-> **审查日期**: {YYYY-MM-DD}  
-> **审查范围**: {TARGET_DIR} 全部设计文档  
-> **累计轮次**: {N}
-
----
-
-## 📋 问题总览
-
-> 已解决轮次仅保留摘要。当前活跃轮只保留影响判断的高信号问题。
-
-### 第{N}轮（当前活跃）
-
-| 严重度 | 数量 | 摘要 | 状态 |
-|--------|------|------|------|
-| Critical | X | [本轮 Critical 问题的合并摘要] | ⏳ 待处理 |
-| High | X | [本轮 High 问题的合并摘要] | ⏳ 待处理 |
-| Medium | X | [本轮 Medium 问题的合并摘要] | ⏳ 待处理 |
-| Low | X | [本轮 Low 问题的合并摘要或省略说明] | ⏳ 待处理 |
-
----
-
-## 📊 审查摘要
-
-**审查模式**: `{REVIEW_MODE}`  
-**整体判断**: 🟢 可继续 / 🟡 需先修复高优先问题 / 🔴 暂不建议继续  
-**高信号结论**: [用 2-4 句总结最值得关心的问题，不展开方法过程]
-
-| 指标 | 数值 |
-|------|------|
-| Critical | X |
-| High | X |
-| Medium | X |
-| Low | X |
-| Total Findings | X |
-
+
+## Step 5: 生成质疑报告 (Challenge Report)
+
+**目标**: 输出结构化报告，每个问题都有证据支撑，并采用**问题发现优先**的紧凑结构。
+
+保存报告到 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`
+
+**报告模板**:
+
+```markdown
+# [项目名称] 质疑报告 (Challenge Report)
+
+> **审查日期**: {YYYY-MM-DD}  
+> **审查范围**: {TARGET_DIR} 全部设计文档  
+> **累计轮次**: {N}
+
+---
+
+## 📋 问题总览
+
+> 已解决轮次仅保留摘要。当前活跃轮只保留影响判断的高信号问题。
+
+### 第{N}轮（当前活跃）
+
+| 严重度 | 数量 | 摘要 | 状态 |
+|--------|------|------|------|
+| Critical | X | [本轮 Critical 问题的合并摘要] | ⏳ 待处理 |
+| High | X | [本轮 High 问题的合并摘要] | ⏳ 待处理 |
+| Medium | X | [本轮 Medium 问题的合并摘要] | ⏳ 待处理 |
+| Low | X | [本轮 Low 问题的合并摘要或省略说明] | ⏳ 待处理 |
+
+---
+
+## 📊 审查摘要
+
+**审查模式**: `{REVIEW_MODE}`  
+**整体判断**: 🟢 可继续 / 🟡 需先修复高优先问题 / 🔴 暂不建议继续  
+**高信号结论**: [用 2-4 句总结最值得关心的问题，不展开方法过程]
+
+| 指标 | 数值 |
+|------|------|
+| Critical | X |
+| High | X |
+| Medium | X |
+| Low | X |
+| Total Findings | X |
+
 | 证据来源 | 结论 |
 |----------|------|
 | design-reviewer | {执行 / 跳过} |
@@ -427,109 +396,99 @@ description: "对项目的设计、任务与实现进行系统性挑战，用证
 | code-reviewer | {执行 / 跳过 / 自适应升级} |
 | Pre-Mortem | {关键结论一句话} |
 | 承诺闭合检查 | {Pass / Partial / Fail} |
-
----
-
-## 🔍 核心发现清单
-
-| ID | 类别 | 严重度 | 契约/Pass | 位置 | 发现 | 影响 | 建议 |
-|----|------|--------|-----------|------|------|------|------|
+
+---
+
+## 🔍 核心发现清单
+
+| ID | 类别 | 严重度 | 契约/Pass | 位置 | 发现 | 影响 | 建议 |
+|----|------|--------|-----------|------|------|------|------|
 | CH-01 | 承诺失真 | Critical | 错误承诺 / Contract Drift | PRD §X / ADR §Y / src/... | 默认失败路径未统一，契约未闭合 | 客户端错误处理分叉 | 统一错误语义并补验证任务或实现修复 |
 | CH-02 | 任务承接 | High | E1 / Task Drift | 05_TASKS.md §X / src/... | P0 需求无对应任务或实现未兑现承接 | 核心能力无法落地 | 补充实现与验证任务 |
 | CH-03 | 设计闭合 | Medium | RS-5 / Code Drift | 04_SYSTEM_DESIGN/... / src/... | 故障传播路径未说明或实现未按设计落地 | 出现级联失败时难以恢复 | 增加降级与超时策略 |
- 
-> 仅保留真正影响判断的问题。低价值措辞、泛泛而谈的担忧不要写进表。
- 
----
-
-## 建议行动清单
-
-### P0 - 立即处理 (阻塞)
-1. [CH-01] - [建议方案]
-
-### P1 - 近期处理 (重要)
-1. [CH-02] - [建议方案]
-
-### P2 - 持续改进 (优化)
-1. [CH-03] - [建议方案]
-
----
-
-## 🚦 最终判断
-
-- [ ] 🟢 项目可继续，风险可控
-- [ ] 🟡 项目可继续，但需先解决 P0 问题
-- [ ] 🔴 项目需要重新评估
-
-**判断依据**: [基于关键问题数量、严重度和影响范围的综合评估]
-
----
-
-## 📚 附录（按需）
-
-### A. 承诺闭合与假设验证摘要
-
-| 项目 | 结论 | 证据 | 对应问题 |
-|------|------|------|----------|
-| 重复态 | Pass / Partial / Fail | ... | CH-01 |
-| 失败态 | Pass / Partial / Fail | ... | CH-02 |
-| 默认态 | Pass / Partial / Fail | ... | CH-03 |
-| 运行态 | Pass / Partial / Fail | ... | CH-04 |
-
-### B. ADR 影响追踪
-
-> **提醒**: 如果本次审查发现需要修改 ADR，请检查以下引用链：
-
-| ADR 文件 | 引用该 ADR 的 SYSTEM_DESIGN | 影响说明 |
-|---------|---------------------------|---------|
-| [ADR-XXX](../03_ADR/ADR_XXX.md) | [system-1.md](../04_SYSTEM_DESIGN/system-1.md) §8 | [说明] |
-```
-
-## Step 6: 轮次归档协议 (Round Archive Protocol)
-
-**目标**: 保持报告精简，已解决的轮次只保留摘要。
-
-> [!IMPORTANT]
-> **此步骤在每轮新审查开始时自动执行，不需要单独触发。**
-
-### 归档规则
-
-1.  **新轮审查开始时**，检查上一轮的所有问题是否已解决（由用户确认修复）
-2.  **如已解决** →
-    - 在 `📋 问题总览` 中将该轮的状态全部标为 ✅
-    - **删除该轮的详细审查章节**（`## 🔥 第{N-1}轮详细审查`）
-    - 问题总览中的摘要行即为该轮的永久存档
-3.  **如部分解决** →
-    - 已解决的问题在总览中标 ✅
-    - 未解决的问题保留 ⏳ 并在新轮中继续跟踪
-    - 上一轮详情中仅保留未解决问题的描述
-4.  **报告中同一时刻只有一轮详细内容**（当前活跃轮）
-
-### 总览行合并规则
-
-同严重度的已解决问题合并为一行，格式：
-```markdown
-| C1-C4 | 🔴 | 条约矛盾/毁约逻辑/升级公式/领地缺失 | ✅ 全部修复 |
-```
-
-未解决问题保持独立行，格式：
-```markdown
-| R2-C1 | 🔴 | executor v2 动作缺失 | ⏳ 待修复 |
-```
-
----
-
-<completion_criteria>
-- ✅ 深度阅读了项目设计文档
-- ✅ 已识别规范来源集合并提炼关键承诺模型
-- ✅ Pre-Mortem 分析有逻辑依据
-- ✅ 每个质疑点都有证据支撑
-- ✅ 已完成承诺闭合验证（至少覆盖重复态 / 失败态 / 默认态 / 运行态）
-- ✅ 技术健壮性审计已完成
-- ✅ Top 3 假设已尝试验证
-- ✅ 承诺型质疑优先于载体型质疑输出
-- ✅ 质疑报告格式完整（含问题总览目录）
-- ✅ 上一轮已解决问题的详情已归档（仅保留总览行）
-- ✅ 用户已阅读并决定下一步
-</completion_criteria>
-
+ 
+> 仅保留真正影响判断的问题。低价值措辞、泛泛而谈的担忧不要写进表。
+ 
+---
+
+## 建议行动清单
+
+### P0 - 立即处理 (阻塞)
+1. [CH-01] - [建议方案]
+
+### P1 - 近期处理 (重要)
+1. [CH-02] - [建议方案]
+
+### P2 - 持续改进 (优化)
+1. [CH-03] - [建议方案]
+
+---
+
+## 🚦 最终判断
+
+- [ ] 🟢 项目可继续，风险可控
+- [ ] 🟡 项目可继续，但需先解决 P0 问题
+- [ ] 🔴 项目需要重新评估
+
+**判断依据**: [基于关键问题数量、严重度和影响范围的综合评估]
+
+---
+
+## 📚 附录（按需）
+
+### A. 承诺闭合与假设验证摘要
+
+| 项目 | 结论 | 证据 | 对应问题 |
+|------|------|------|----------|
+| 重复态 | Pass / Partial / Fail | ... | CH-01 |
+| 失败态 | Pass / Partial / Fail | ... | CH-02 |
+| 默认态 | Pass / Partial / Fail | ... | CH-03 |
+| 运行态 | Pass / Partial / Fail | ... | CH-04 |
+
+### B. ADR 影响追踪
+
+> **提醒**: 如果本次审查发现需要修改 ADR，请检查以下引用链：
+
+| ADR 文件 | 引用该 ADR 的 SYSTEM_DESIGN | 影响说明 |
+|---------|---------------------------|---------|
+| [ADR-XXX](../03_ADR/ADR_XXX.md) | [system-1.md](../04_SYSTEM_DESIGN/system-1.md) §8 | [说明] |
+```
+
+## Step 6: 轮次归档协议 (Round Archive Protocol)
+
+**目标**: 保持报告精简，已解决的轮次只保留摘要。
+
+> [!IMPORTANT]
+> **此步骤在每轮新审查开始时自动执行，不需要单独触发。**
+
+### 归档规则
+
+1. **新轮审查开始时**，检查上一轮的所有问题是否已解决（由用户确认修复）
+2. **如已解决** →
+  - 在 `📋 问题总览` 中将该轮的状态全部标为 ✅
+    - **删除该轮的详细审查章节**（`## 🔥 第{N-1}轮详细审查`）
+    - 问题总览中的摘要行即为该轮的永久存档
+3. **如部分解决** →
+  - 已解决的问题在总览中标 ✅
+    - 未解决的问题保留 ⏳ 并在新轮中继续跟踪
+    - 上一轮详情中仅保留未解决问题的描述
+4. **报告中同一时刻只有一轮详细内容**（当前活跃轮）
+
+### 总览行合并规则
+
+同严重度的已解决问题合并为一行，格式：
+
+```markdown
+| C1-C4 | 🔴 | 条约矛盾/毁约逻辑/升级公式/领地缺失 | ✅ 全部修复 |
+```
+
+未解决问题保持独立行，格式：
+
+```markdown
+| R2-C1 | 🔴 | executor v2 动作缺失 | ⏳ 待修复 |
+```
+
+---
+
+- ✅ 深度阅读了项目设计文档 - ✅ 已识别规范来源集合并提炼关键承诺模型 - ✅ Pre-Mortem 分析有逻辑依据 - ✅ 每个质疑点都有证据支撑 - ✅ 已完成承诺闭合验证（至少覆盖重复态 / 失败态 / 默认态 / 运行态） - ✅ 技术健壮性审计已完成 - ✅ Top 3 假设已尝试验证 - ✅ 承诺型质疑优先于载体型质疑输出 - ✅ 质疑报告格式完整（含问题总览目录） - ✅ 上一轮已解决问题的详情已归档（仅保留总览行） - ✅ 用户已阅读并决定下一步
+