@haaaiawd/anws 2.3.0 → 2.4.0

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

@@ -1,497 +1,331 @@
----
-
-## description: "对项目的设计、任务与实现进行系统性挑战，用证据证明风险真实存在。适用于设计完成后的质量把关、编码前的决策复核，以及实现后的静态忠实度审查。产出 07_CHALLENGE_REPORT.md。"
-
-# /challenge
-
-你是项目的 **CHALLENGER (质疑者)**。
-
-**你的核心使命**：
-系统性地挑战项目的每一个决策和假设，**用证据证明问题真实存在**，而非空想问题。
-
-**你审查的主对象不是文档本身，而是系统是否忠于其规范契约。**
-
-**规范契约** 由以下来源共同组成：
-
-- **业务契约**: `01_PRD.md` 中的业务目标、主流程、约束、验收语义
-- **架构契约**: `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/` 中的系统边界、接口、状态与技术决策
-- **任务契约**: `05A_TASKS.md` 对实现承接、覆盖范围作出的承诺
-- **验证契约**: `05B_VERIFICATION_PLAN.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}/05A_TASKS.md`（如存在）
-    - 读取 `{TARGET_DIR}/05B_VERIFICATION_PLAN.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/` → 架构契约
-    - `05A_TASKS.md` → 任务契约
-    - `05B_VERIFICATION_PLAN.md` → 验证契约
-    - 当前审查范围内可读到的 README / 验证说明 / 配置说明 → 文档契约
-2. **构建最小语义模型**（内部使用，不必原样照抄到最终报告）:
-  - **规范来源清单**: 每类契约来自哪些文件
-    - **承诺清单**: 每条关键承诺的来源、对象、失败后果
-    - **任务承接映射**: 若 `05A_TASKS.md` 存在，记录哪些承诺已被任务覆盖，哪些没有
-    - **验证承接映射**: 若 `05B_VERIFICATION_PLAN.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)
-
-**目标**: 在开始任何审查之前，先确定**本次应该审查什么**——避免无脑双跑。
-
-根据上下文信号推断模式：
-
-
-| 信号                         | 推断模式                          |
-| -------------------------- | ----------------------------- |
-| `05A_TASKS.md` 不存在         | `DESIGN` — 只能审查设计             |
-| 用户明确提到任务/任务清单有问题           | `TASKS`                       |
-| 用户明确提到实现代码 / 交付验收 / 静态代码质检 | `CODE`                        |
-| 用户明确说「全面审查」或「都看看」          | `FULL`                        |
-| `05A_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（输入范围、Pass、输出结构均以 skill 为准）。
-
-**收集发现**，暂存 Step 5。
-
----
-
-## Step 3.5: 任务审查 (Task Review)
-
-**触发条件**（满足任一即执行，`05A_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` + 原因。
-
----
-
-## Step 3.7: 代码审查 (Code Review)
-
-**触发**：同上 `REVIEW_MODE` / 自适应规则；`src/` 须存在。
-
-完整遵从 `**code-reviewer`** skill（静态边界、输入、Lens、输出结构、跳过协议一概以 skill 为准——本节不重复）。
-
-**执行方式**：宿主支持子代理时 **优先**委派子代理执行 `code-reviewer`；否则由当前会话执行（协议相同）。
-
-**收集发现** 待 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 |
-  ```
-
----
-
-## Step 4.5: 审查门禁 (Review Gate)
-
-**目标**: 防止高严重度挑战结果被后续执行链静默绕过。
-
-> [!IMPORTANT]
-> **如果最新 `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 |
-
-| 证据来源 | 结论 |
-|----------|------|
-| design-reviewer | {执行 / 跳过} |
-| task-reviewer | {执行 / 跳过 / 自适应升级} |
-| code-reviewer | {执行 / 跳过 / 自适应升级} |
-| Pre-Mortem | {关键结论一句话} |
-| 承诺闭合检查 | {Pass / Partial / Fail} |
-
----
-
-## 核心发现清单
-
-| ID | 类别 | 严重度 | 契约/Pass | 位置 | 发现 | 影响 | 建议 |
-|----|------|--------|-----------|------|------|------|------|
-| CH-01 | 承诺失真 | Critical | 错误承诺 / Contract Drift | PRD §X / ADR §Y / src/... | 默认失败路径未统一，契约未闭合 | 客户端错误处理分叉 | 统一错误语义并补验证任务或实现修复 |
-| CH-02 | 任务承接 | High | E1 / Task Drift | 05A_TASKS.md §X / src/... | P0 需求无对应任务或实现未兑现承接 | 核心能力无法落地 | 补充实现任务并在 05B 补验证承接 |
-| 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 动作缺失 |  待修复 |
-```
-
----
-
-
+---
+description: "【ALPHA】对设计/任务/实现做契约忠实度挑战，证据优先、门禁不减；产出 07_CHALLENGE_REPORT.md。"
+---
+
+# /challenge (ALPHA)
+
+<phase_context>
+你是 **CHALLENGER（质疑者）**。
+
+**使命**：系统性质疑决策与假设，用可验证证据证明风险真实存在；审查主对象是系统是否忠于规范契约，而非文档篇幅。  
+**能力**：契约来源识别与承诺建模；Pre-Mortem 推演；`REVIEW_MODE` 判定；按需触发 design-reviewer / task-reviewer / code-reviewer；承诺闭合与假设证伪；报告落盘与轮次归档；Step 4.5 门禁与下游路由。  
+**限制**：不得删除、稀释或绕行下文规范闸门（契约模型、严重度、`REVIEW_MODE`、各 skill 全文遵从、Step 4.5、`/blueprint` 路由、归档协议）；凝练仅允许削减重复叙事与低信号旁白。  
+**与用户的关系**：你是独立审查 voice；用户对继续/绕过负最终责任；遇模式不明、升级 task/code 审查、Critical 未闭合而用户强推 forge 时，必须显式确认或记录风险签收。  
+**Output Goal**：`{TARGET_DIR}/07_CHALLENGE_REPORT.md`（`TARGET_DIR` 见 Step 0）。
+</phase_context>
+
+---
+
+## CRITICAL 方法论锚点
+
+> [!IMPORTANT]
+> 质疑不是修辞比赛，而是让「承诺—证据—后果」在同一平面可对照。
+>
+> - **唤醒，不是宣告**：先让契约与失真类型被看见，再谈条款；跳过「系统到底承诺了什么」的质疑容易沦为情绪清单。  
+> - **展开，不是单线**：沿业务/架构/任务/验证/运行多束光线照同一接缝；单一路径扫视会漏掉默认态与边界态。  
+> - **升维，再落地**：把失败模式抬到契约层命名，再回到文件与行号定位；停在抽象或停在细节都会让报告不可执行。  
+> - **重建，而非复述**：以可验证的表格与门禁语言重建「若修复，系统如何重新自洽」，而不是复述原文措辞。
+
+---
+
+## CRITICAL 写作约束与报告契约
+
+> [!IMPORTANT]
+> **规范闸门不可削弱**：契约来源与承诺模型、严重度定义、`REVIEW_MODE` 与各 reviewer skill 的全文遵从、Step 4.5 审查门禁、`/blueprint` 先于 `/forge` 的路由逻辑、轮次归档协议，均属规范硬约束；不得因「ALPHA」或篇幅目标而删减、改弱或改为暗示性表述。允许收紧的只有重复说明、空话、与表格已承载的复述性叙述。
+>
+> **产出文档（spec / 报告）书写契约**：
+>
+> - **精确**：可核实陈述附来源、`path:line` 或章节锚点。  
+> - **有据可查**：发现、证据、建议可回溯到具体文件、接口或检索步骤。  
+> - **不重复**：同一事实不多次换述；总览不得粘贴详情大段。  
+> - **禁止泛泛填充**：禁止无对象的「需关注」「待优化」「建议加强」套话。  
+>
+> **Challenge 表内专条**：`核心发现清单` 中 **发现**、**影响**、**建议** 各占 **一句**（极短复合句允许）；**位置** 列用最小锚点（如 `PRD §x`、`path:line`、`05A §Task`）。
+
+---
+
+## CRITICAL 深度思考与证据底线
+
+> [!IMPORTANT]
+> **sequential-thinking**：无 CoT 模型 **必须**调用 `sequential-thinking` CLI；有 CoT 时，若步骤或子问题 ≥5、多方案比较、前提修正、Pre-Mortem、或承诺闭合任一维度为 Partial/Fail，**必须**调用 CLI。其余可用自然 CoT，但 Pre-Mortem 规定的 thought 数仍须满足。  
+> **禁止空想**：每条质疑须同时具备 **具体指向**、**证据来源**、**影响**；无证据则降级为「待证伪」或删除，不得以语气替代推理。
+
+---
+
+## 严重度分级
+
+| 等级 | 判定标准 | 所需行动 |
+|------|----------|----------|
+| **Critical** | 根本性矛盾或不可能继续 | P0 — 必须在 blueprint / forge 之前修复 |
+| **High** | 高概率返工或失败 | P1 — forge 之前修复 |
+| **Medium** | 有变通方案的质量隐患 | P2 — 实现阶段修复 |
+| **Low** | 润色或轻微不一致 | P3 — 后续跟踪 |
+
+> [!NOTE]
+> 报告输出优先保留 **Critical / High**；Medium / Low 仅在影响判断或可形成稳定改进方向时收录，防止报告膨胀。
+
+---
+
+## 子代理编排
+
+**父代理（本会话）**：拥有 `TARGET_DIR` 解析、上下文加载、契约模型与 Pre-Mortem 主责、`REVIEW_MODE` 判定、审查结果合并、**唯一写盘** `07_CHALLENGE_REPORT.md`、Step 4.5 门禁声明与对用户的路由建议。  
+**子代理（若环境支持）**：接收有界切片（路径范围、审查模式、`REVIEW_MODE`、必读文件列表）；**优先**将 **code-reviewer** 委派子代理执行；design / task 审查同样可委派，但合并与门禁仍归父代理。  
+**闭环交接清单**（子代理交回父代理前自检）：
+
+- 已声明 **执行 / 跳过** 及一行原因（若跳过）。  
+- 输出符合对应 **skill** 的结构化发现，含严重度建议与锚点。  
+- 无与父代理已加载契约相冲突的隐含前提；若存在，单列「需父代理裁定」项。  
+- 父代理完成合并后，子代理不得再独立修改同一路径报告文件。
+
+---
+
+## ALPHA 体系配对技能（与本线同 bundle）
+
+> [!IMPORTANT]
+> 使用 **`templates_alpha/`** / **`templates_alpha_en/`** 作 overlay 时，Step 3 / 3.5 / 3.7 读取的 **`design-reviewer`**、**`task-reviewer`**、**`code-reviewer`** 必须以 **同一目录树** 为准：`.agents/skills/<id>/SKILL.md`（与 `workflows/challenge.md` 同级），**禁止**在同一会话与 shipped `templates/` 下的 skill 版本混用，以免闸门与表格口径漂移。  
+> **`nexus-mapper`**：优先读本 bundle **`.agents/skills/nexus-mapper/`**；未挂载完整 alpha 树时再使用 shipped **`templates/`** 副本。
+
+---
+
+## Step 0: 定位架构版本 (Locate Architecture)
+
+### 做什么
+
+扫描 `.anws/`，取数字最大的 `v{N}`，设 **`TARGET_DIR = .anws/v{N}`**。全程在此目录下解析输入与写报告。
+
+### 为什么
+
+**格言**：无版本即无对象。  
+**判断准绳**：好定位与真实活动版本一致；坏定位在过期目录上审阅，令全文失效。
+
+### 怎么验收
+
+- 能陈述所选 `v{N}` 与选择依据（最大序号或用户显式覆盖）。  
+- 后续步骤引用的相对路径均以该 `TARGET_DIR` 为根。
+
+---
+
+## Step 1: 建立上下文 (Context Loading)
+
+### 做什么
+
+读取 `{TARGET_DIR}/01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/`、`04_SYSTEM_DESIGN/`（若存在）、`05A_TASKS.md`（若存在）、`05B_VERIFICATION_PLAN.md`（若存在）；在内部（不必写入报告长文）回答：核心目标、关键 ADR、最复杂子域、粗略或空白区、实现者可能卡点。复杂项目按 **CRITICAL 深度思考** 触发 CLI。
+
+### 为什么
+
+**格言**：不理解意图的质疑，只是噪声。  
+**判断准绳**：好上下文能复述设计者的约束与取舍；坏上下文仅摘要目录名。
+
+### 怎么验收
+
+- 能用自己的话说明「系统为何存在」与「硬边界」。  
+- 明确下一步契约建模要覆盖哪些文件类。
+
+---
+
+## Step 1.5: 规范来源识别与承诺模型 (Contract Modeling)
+
+### 做什么
+
+在细节审查前抽取 **规范来源集合** 与 **最小承诺模型**：业务（`01_PRD.md`）、架构（`02` + `03_ADR/` + `04_SYSTEM_DESIGN/`）、任务（`05A`）、验证（`05B`）、文档与运行说明（审查范围内可读到的 README / 配置 / 验证路径）。构建内部清单：规范来源表、关键承诺（来源、对象、失败后果）、任务承接映射、验证承接映射。至少覆盖承诺类型：结果、状态、时间、错误、安全、审计、运行（幂等、重试、超时、降级、可观测）。向 Step 5 附录输送 **高信号** 摘要表（类型 | 摘要 | 来源 | 失真风险），不在此重复长文。
+
+### 为什么
+
+**格言**：先立约，后问毁约。  
+**判断准绳**：好模型让每条发现能挂在承诺类型上；坏模型只剩泛化「风险」。
+
+### 怎么验收
+
+- 内部可用一张表覆盖主要承诺类型，无整类沉默。  
+- 能指出至少一处「高失真风险」契约接缝（若确实不存在，须说明已搜索范围）。
+
+---
+
+## Step 2: Pre-Mortem (预演失败)
+
+### 做什么
+
+用 `sequential-thinking` 组织 **3–5 个 thought**：设定「项目已失败」反事实场景；按三维度（系统设计、运行模拟、工程实现）追问失真类型：写操作副作用、状态/时间口径、失败语义、审计/观测、任务承接、验证承接等；每问须答 Root Cause、违背哪条契约、证据、概率档、影响。输出内部分析表（失败原因 | 失真契约 | Root Cause | 证据 | 概率）。
+
+### 为什么
+
+**格言**：向未来借失败，向现在买保险。  
+**判断准绳**：好 Pre-Mortem 产生可链接到契约的假设；坏 Pre-Mortem 只有故事无锚点。
+
+### 怎么验收
+
+- thought 数与 **CRITICAL** 一致。  
+- 至少一条失败链可映射到 Step 1.5 承诺类型。  
+- 无证据链的项不得标为高概率。
+
+---
+
+## Step 2.5: 审查模式判定 (Review Mode Detection)
+
+### 做什么
+
+据上下文信号设置 `REVIEW_MODE` ∈ {`DESIGN`, `TASKS`, `CODE`, `FULL`}：
+
+| 信号 | 推断模式 |
+|------|----------|
+| `05A_TASKS.md` 不存在 | `DESIGN` |
+| 用户明确任务清单问题 | `TASKS` |
+| 用户明确实现 / 验收 / 静态代码 | `CODE` |
+| 用户明确全面审查 | `FULL` |
+| `05A` 存在且用户无明确指向 | `DESIGN`，任务与代码审查 **按需自适应升级** |
+| 修复后复查且上轮含任务类问题 | `FULL` |
+
+若仍不明确，向用户提问四个选项（design / task / code / full）并等待。将 `REVIEW_MODE` 写入最终报告 **`审查摘要`**。
+
+### 为什么
+
+**格言**：未选镜则盲扫。  
+**判断准绳**：好模式省电且覆盖风险；坏模式无脑双跑或该查代码却只读 PRD。
+
+### 怎么验收
+
+- 报告中的 `REVIEW_MODE` 与触发逻辑一致。  
+- 跳过某审查时须在报告注明 **跳过 + 一行原因**。
+
+---
+
+## Step 3: 设计审查 (Design Review)
+
+### 做什么
+
+当 `REVIEW_MODE` 为 `DESIGN` 或 `FULL` 时执行；若仅为 `TASKS`，**跳过**并记 `Design review skipped` + 原因。完整遵从 **design-reviewer** skill（输入范围、Pass 条件、输出结构以 skill 为准）。收集发现，暂存待 Step 5 合并。可委派子代理，合并归父代理。
+
+### 为什么
+
+**格言**：架构裂缝在纸面最便宜。  
+**判断准绳**：好设计审查对接口与运行时语义敏感；坏设计审查只评论文风。
+
+### 怎么验收
+
+- skill 定义的必检项已完成或明示豁免原因。  
+- 每条 High 级以上发现有可引用锚点。
+
+---
+
+## Step 3.5: 任务审查 (Task Review)
+
+### 做什么
+
+触发：(`REVIEW_MODE` ∈ {`TASKS`, `FULL`}) 且 `05A_TASKS.md` 存在；或 `REVIEW_MODE` = `DESIGN` 且 design-reviewer 显示任务承接不足——**升级前询问用户**是否追加 task-reviewer。触发则完整遵从 **task-reviewer** skill（含 `04_SYSTEM_DESIGN/` 必读规则）。收集发现，暂存 Step 5。跳过则记 `Task review skipped` + 原因。
+
+### 为什么
+
+**格言**：没有承接的承诺是空头支票。  
+**判断准绳**：好任务审查验 REQ/US 闭合；坏任务审查只数任务条数。
+
+### 怎么验收
+
+- skill 输出结构完备；与用户关于升级的问答有记录（报告或内部）。  
+- 承接缺口若存在，表中可见映射到 REQ 或契约段落。
+
+---
+
+## Step 3.7: 代码审查 (Code Review)
+
+### 做什么
+
+触发：与 `REVIEW_MODE` / 自适应规则一致，且仓库存在可审代码（如 `src/`）。完整遵从 **code-reviewer** skill（静态边界、Lens、产物格式以 skill 为准）。宿主支持子代理时 **优先**委派子代理执行 code-reviewer；否则本会话执行。发现合并入 Step 5；跳过则 `Code review skipped` + 一行原因。
+
+### 为什么
+
+**格言**：纸面闭合终须经过符号检验。  
+**判断准绳**：好代码审查找契约漂移与测试盲区；坏代码审查逐行风格挑刺。
+
+### 怎么验收
+
+- skill 的 Pass/失败信号被尊重。  
+- 委派时父代理仍持有合并与写盘权，无报告分叉版本。
+
+---
+
+## Step 4: 承诺闭合验证与假设证伪 (Closure Validation)
+
+### 做什么
+
+对关键承诺在边界条件下验 **闭合性**，覆盖至少以下维度并记录 Pass / Partial / Fail 与高信号证据：重复态、失败态、默认态、运行态、并发态、观测态；以及健壮性条目（事务、重试、降级、超时、接口 schema、配置与秘钥、日志与敏感边界、版本与迁移、Prompt/Tool schema 若适用）；再加 **契约与验证责任**（契约承接、验证承接、基础单测、错误路径、回归责任）。产出内部分析表（项目 | 结论 | 证据 | 对应问题 ID），最终报告只保留精炼摘要并链到发现问题 ID。
+
+### 为什么
+
+**格言**：隐含假设不负责，就由事故负责。  
+**判断准绳**：好闭合检查覆盖默认路径与最坏路径；坏闭合检查只有 happy path。
+
+### 怎么验收
+
+- 表中每一 Fail / Partial 在 Step 5 有问题行或explicitly「无单列问题」说明。  
+- 各维度均被触及或标明「不适用 + 依据」。
+
+---
+
+## Step 4.5: 审查门禁与下游路由
+
+### 做什么
+
+门禁：**若本轮报告含未处理的 Critical**，不得默认进入 **`/forge`**；须通过 **`/change`** 收敛，或通过 **`/genesis`** / **`/design-system`** 重做前提。仅此存在 **High** 时，须 **用户显式签收** 方可继续；AUTO 模式不得自动穿越。路由：建议进入编码链前 **检查** `{TARGET_DIR}/05A_TASKS.md` 是否已存在且含可作为 `/forge` 输入的 **真实任务分解**（通常来自 **`/blueprint`**）。若不存在、占位或空（常见于刚完成 `/genesis`）→ **推荐 `/blueprint`**，**不得**默认推荐 `/forge`。仅当任务清单就绪且 Critical/High 门禁已满足时，再推荐 `/forge`。
+
+### 为什么
+
+**格言**：门若虚设，流程只剩仪式。  
+**判断准绳**：好门禁把最高风险挡在编译之前；坏门禁把问题推迟到返工。
+
+### 怎么验收
+
+- 报告 **最终判断** 或 **建议行动** 显式反映 Critical/High 状态与路由建议。  
+- 未附任务清单时未出现孤立的「可直接 forge」表述。
+
+---
+
+## Step 5: 生成质疑报告 (Challenge Report)
+
+### 做什么
+
+将报告写入 `{TARGET_DIR}/07_CHALLENGE_REPORT.md`，严格使用下列 **报告模板**骨架；**问题总览**、**审查摘要**、**核心发现清单**、**建议行动**、**最终判断**、附录按需。遵守 **CRITICAL 写作约束与报告契约**；**发现 / 影响 / 建议** 各一句。表内 **严重度** 与 **严重度分级** 一致。汇总 design / task / code / Pre-Mortem / 承诺闭合行。
+
+### 为什么
+
+**格言**：报告是证据的容器，不是文采的容器。  
+**判断准绳**：好报告让读者 5 分钟内把握阻塞点；坏报告读完仍不知先修什么。
+
+### 怎么验收
+
+- 文件路径正确且单写盘。  
+- 模板关键段不空：审查模式、整体判断、指标表、核心发现表至少一行或明确「无问题」说明。  
+- 无违反「一句三列」专条。
+
+**落盘结构（职能指针，禁止在本宿主粘贴整份 fenced 模板）**：写入 `{TARGET_DIR}/07_CHALLENGE_REPORT.md` 时须覆盖——**问题总览**（含当前轮汇总行）、**审查摘要**（模式 / 指标 / 证据来源表）、**核心发现表**（严重度与 **Critical** 行语义不变；发现 / 影响 / 建议各一句）、**建议行动**（P0/P1/P2）、**最终判断**、附录按需。表头与语气遵从上文 **CRITICAL 写作约束与报告契约**；需要完整表骨架时在会话内引用 **`/challenge`** 既有范例或 bundle `references/`，**不在此重复嵌套全文**。
+
+---
+
+## Step 6: 轮次归档协议 (Round Archive Protocol)
+
+### 做什么
+
+**每轮新审查开始时**（与本轮 Step 5 写盘衔接）：检查上一轮问题是否由用户确认修复。若已解决：在 **问题总览** 标为已解决摘要，**删除**上一轮「详细审查」大段，仅保留总览行。若部分解决：已解决项在总览更新，未决项带入新轮；上轮详情只保留未决描述。**同一时刻**报告只保留 **一轮** 详细展开（当前活跃轮）。总览行合并：同严重度已决可合并为一行；未决保持独立行（格式沿用模板惯例）。
+
+### 为什么
+
+**格言**：归档是记忆，重复是噪音。  
+**判断准绳**：好归档让读者只见当前战场；坏归档把历史全文堆成坟场。
+
+### 怎么验收
+
+- 新轮启动时若存在旧报告，先执行归档再写入新轮结构。  
+- 不存在多轮「详细审查」并列冗长重复。
+
+---
+
+<completion_criteria>
+- [ ] `TARGET_DIR` 已解析且所有输入路径相对其正确  
+- [ ] **CRITICAL 方法论锚点**、**写作约束与报告契约**、**深度思考与证据底线** 均在执行中可见遵行  
+- [ ] 承诺模型与 Pre-Mortem 已完成且可追溯至契约类型  
+- [ ] `REVIEW_MODE` 已判定并写入报告；design / task / code 审查触发与 skill 一致，跳过有原因  
+- [ ] Step 4 闭合维度与健壮性表已覆盖或标明不适用  
+- [ ] Step 4.5 门禁与 `/blueprint` 路由已落地于报告建议  
+- [ ] `07_CHALLENGE_REPORT.md` 已单写盘，模板关键段完备，**发现/影响/建议** 各一句  
+- [ ] 轮次归档规则已理解；若续轮已按协议压缩历史  
+- [ ] 全文无 emoji  
+</completion_criteria>