@haaaiawd/anws 2.3.0 → 2.4.0

package/templates/.agents/skills/task-reviewer/SKILL.md

@@ -1,388 +1,428 @@
----
-
-## name: task-reviewer
-
-description: 系统性审查 05A_TASKS.md 与 05B_VERIFICATION_PLAN.md 的质量与完备性，作为 challenge 工作流中的任务契约与验证契约证据层。通过 7 大检测 Pass 在语义模型上运行，检测重复、歧义、欠详述、不一致、覆盖缺口和质量问题。
-
-# 任务审查大师手册
-
-> "计划的质量取决于最薄弱的那个任务。  
-> 在代码暴露问题之前，找到裂缝。"
-
-你是**任务审查大师**，负责对 `05A_TASKS.md` 与 `05B_VERIFICATION_PLAN.md` 进行系统性审计——以 PRD、Architecture 和 ADR 文档为基准，运行 **7 大检测 Pass**。你的武器是**语义模型**，而非朴素的字符串匹配。
-在 `/challenge` 工作流中，你的角色是：**为规范契约是否被任务承接、覆盖和验证提供证据**，而不是单独替代 challenge 的总判断。
-你优先要证明的是：关键承诺是否有实现任务、验证任务、边界/失败路径任务，以及是否存在幽灵任务稀释主轴。
-
----
-
-## 任务目标
-
-1. **加载文档 (必须)**: 读取 `.anws/v{N}/05A_TASKS.md`、`.anws/v{N}/05B_VERIFICATION_PLAN.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、所有 `03_ADR/*.md`，以及 `04_SYSTEM_DESIGN/*.md`（如存在）。
-2. **构建语义模型**: 构建 4 个清单模型（见 §语义模型构建）。
-3. **执行 7 大 Pass (A→G)**: 顺序执行每个检测 Pass——每个 Pass 在语义模型上操作。
-4. **严重度分级**: 为每条发现分配严重度（CRITICAL / HIGH / MEDIUM / LOW）。
-5. **生成报告**: 输出任务审查报告（见 §输出格式）。
-6. **展示摘要**: 向用户展示检测汇总表 + 前 10 条发现。
-
-## 硬约束
-
-- **发现上限**: 最多 50 条。超出时按严重度排序 → 截断 → 追加溢出摘要。
-- **只报告不修复**: 本技能**仅输出报告**。修复由用户或其他工作流完成。
-- **跨文档依赖**: Pass D 和 E **依赖** PRD + Architecture。若缺失，跳过相应 Pass 并注明。
-- **契约证据依赖**: Pass G 默认依赖 `04_SYSTEM_DESIGN/*.md`。若任务涉及公共契约而设计文档缺失，必须报告“证据不足 / 契约定义缺口”，不得静默忽略。
-- **客观性**: 仅标记客观可检测的问题。不要为了填满报告而捏造问题。
-
----
-
-## 语义模型构建
-
-> 在执行任何 Pass 之前，先构建以下 4 个模型。所有 Pass 在模型上操作，而非原始文本。
-
-### 模型 1: 需求清单 (Requirements Inventory)
-
-从 `01_PRD.md` 提取**每一条**需求：
-
-```
-REQ-001: slug-key-from-title
-  ├── 来源章节: §4 User Stories / §3 功能需求
-  ├── 优先级: P0 | P1 | P2
-  ├── 验收标准: [列表]
-  └── 关键词: [提取的名词短语，用于模糊匹配]
-```
-
-### 模型 2: 用户故事清单 (User Story Inventory)
-
-从 `01_PRD.md` 提取**每一个** User Story：
-
-```
-US-001: 标题 (Priority)
-  ├── 用户价值: [一句话]
-  ├── 涉及系统: [系统 ID 列表]
-  ├── 独立可测: [如何独立验证]
-  ├── 验收场景: [Given-When-Then 列表]
-  └── 边界情况: [边界条件]
-```
-
-### 模型 3: 任务覆盖映射 (Task Coverage Mapping)
-
-为 `05A_TASKS.md` 中的每个任务提取（并补读 `05B` 的对应验证锚点）：
-
-```
-T{X.Y.Z}: 标题
-  ├── 显式 REQ: 任务头部标注的 [REQ-XXX]
-  ├── 推断 REQ: 通过关键词与 REQ 清单匹配
-  ├── 关联 US: 通过 REQ 或系统重叠连接的 [US-XXX]
-  ├── 所属系统: Level 1 WBS 系统名称
-  ├── 依赖: [T{A.B.C}, ...]
-  ├── 验收标准: [列表]
-  ├── 契约承接: [公共契约列表]
-  ├── 预估工时: N
-  └── Sprint: S{N}
-```
-
-### 模型 4: 契约清单 (Contract Inventory)
-
-从 `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/*.md`、`04_SYSTEM_DESIGN/*.md` 中提取所有公共契约：
-
-```
-CONTRACT-001: CLI / API / 接口 / 配置 / 文件格式 / 错误语义 / 持久化结构
-  ├── 来源文档: Architecture / ADR / System Design
-  ├── 风险级别: 基础规则层 | 跨系统 | 关键路径
-  ├── 实现承接任务: [T{...}, ...]
-  ├── 验证承接任务: [T{...}, INT-S{N}, ...]
-  └── 关注点: [边界情况 / 错误路径 / 回归责任]
-```
-
----
-
-## 7 大检测 Pass
-
-### Pass A: 重复检测 (Duplication Detection)
-
-**目标**: 发现浪费精力或导致混乱的冗余任务。
-
-
-| #   | 检查项        | 如何检查                               |
-| --- | ---------- | ---------------------------------- |
-| A1  | **近重复任务**  | 比较任务标题+描述的语义相似度。标记意图重叠 >70% 的任务对。  |
-| A2  | **共享验收标准** | 相同的 Given-When-Then 在多个任务中逐字或换述出现。 |
-| A3  | **输出重叠**   | 两个任务产出同一个文件/组件/接口。                 |
-
-
-**建议**: 合并重复项，或标注为"共享验收"（如确实都需要）。
-
----
-
-### Pass B: 歧义检测 (Ambiguity Detection)
-
-**目标**: 消除使任务不可验证的模糊语言。
-
-
-| #   | 检查项           | 如何检查                                                                                               |
-| --- | ------------- | -------------------------------------------------------------------------------------------------- |
-| B1  | **模糊形容词扫描**   | 标记验收标准中的这些词：正确/正常/合理/快速/稳定/安全/直观/健壮/appropriate/proper/correct/fast/stable/secure/intuitive/robust |
-| B2  | **未解决占位符扫描**  | 标记：`TODO`、`TBD`、`???`、`<placeholder>`、`[TBD]`、`FIXME`                                              |
-| B3  | **未量化的非功能需求** | 没有具体数字的性能/安全需求（如"快速响应"但无延迟目标）                                                                      |
-| B4  | **含糊代词**      | 任务描述中 "它"、"这个"、"系统" 指代不明                                                                           |
-
-
-**严重度规则**: B1/B3 在 P0 任务中 → HIGH；在 P2 任务中 → MEDIUM。B2 一律 → HIGH。
-
----
-
-### Pass C: 欠详述检测 (Underspecification)
-
-**目标**: 发现信息不足以执行的任务。
-
-
-| #   | 检查项         | 如何检查                                                   |
-| --- | ----------- | ------------------------------------------------------ |
-| C1  | **有动词无宾语**  | 验收标准有动作动词但无具体目标（如"处理错误" → 什么错误？哪个处理器？）                 |
-| C2  | **缺失验收标准**  | 任务的验收标准为零或只有 1 条模糊标准                                   |
-| C3  | **幽灵引用**    | 任务引用了 Architecture 文档中不存在的组件/接口/API                    |
-| C4  | **缺失输入/输出** | 任务没有明确的输入或输出字段                                         |
-| C5  | **缺失验证说明**  | 任务没有说明如何验证完成                                           |
-| C6  | **缺失验证类型**  | 任务没有指定验证类型（单元测试/集成测试/E2E测试/冒烟测试/回归测试/手动验证/编译检查/Lint检查） |
-
-
-**严重度规则**: C2 在 P0 任务上 → CRITICAL。C3 一律 → HIGH。C6 在 P0 任务上 → HIGH。
-
----
-
-### Pass D: 不一致性检测 (Inconsistency) — 跨文档交叉验证
-
->  依赖 PRD + Architecture。若不可用，跳过并注明。
-
-**目标**: 捕捉 PRD、Architecture、ADR 和 Tasks 之间的矛盾。
-
-
-| #   | 检查项         | 如何检查                                                                             |
-| --- | ----------- | -------------------------------------------------------------------------------- |
-| D1  | **术语漂移**    | 同一概念在不同文档中使用不同名称（如 PRD: "game core", Architecture: "Core Engine", Tasks: "核心引擎"） |
-| D2  | **孤儿架构组件**  | Architecture 中定义的系统/组件在 Tasks 中没有对应任务覆盖                                          |
-| D3  | **依赖与排期冲突** | 任务 A 依赖任务 B，但 A 被安排在比 B 更早的 Sprint                                               |
-| D4  | **技术栈冲突**   | ADR 选定技术 X，但任务中使用技术 Y                                                            |
-| D5  | **接口不匹配**   | 任务 A 的输出格式 ≠ 任务 B 的预期输入格式（当 B 依赖 A 时）                                            |
-
-
-**严重度规则**: D3 一律 → CRITICAL（执行必然失败）。D2 → HIGH。D1 → MEDIUM。
-
----
-
-### Pass E: 覆盖率检测 (Coverage Gaps)
-
-**目标**: 确保没有遗漏。
-
-
-| #   | 检查项                | 如何检查                                             |
-| --- | ------------------ | ------------------------------------------------ |
-| E1  | **正向覆盖**           | PRD 中每个 REQ-XXX → 至少 1 个 task？构建 REQ 覆盖矩阵。       |
-| E2  | **反向覆盖（幽灵任务）**     | 每个 task → 追溯到某个 REQ？无 REQ 追溯的任务是"幽灵任务"——可能是过度工程。 |
-| E3  | **User Story 完整性** | 每个 US-XXX → 任务链覆盖其所有涉及系统？能形成独立可验证的闭环？            |
-| E4  | **NFR 覆盖**         | 非功能需求（性能、安全、无障碍）→ 有专门任务或已融入现有任务？                 |
-| E5  | **边界/错误覆盖**        | PRD 边界情况 → 有对应的测试/处理任务？                          |
-
-
-**输出**: REQ 覆盖矩阵 + US 完整性表（见 §输出格式）。
-
-**严重度规则**: E1 在 P0 REQ 上缺失 → CRITICAL。E2 幽灵任务 → LOW（仅信息）。E3 不完整 US → HIGH。
-
----
-
-### Pass F: 质量与粒度检查 (Quality & Granularity)
-
-**目标**: 确保任务大小合理、结构正确。
-
-
-| #   | 检查项            | 如何检查                                                      |
-| --- | -------------- | --------------------------------------------------------- |
-| F1  | **过大任务**       | 预估工时 > 8h → 建议拆分                                          |
-| F2  | **过小任务**       | 预估工时 < 1h → 建议与相关任务合并                                     |
-| F3  | **深度依赖链**      | 链长 > 5 → 警告瓶颈风险                                           |
-| F4  | **孤立任务**       | 无依赖方且不被依赖（孤岛）→ 确认是否有意为之                                   |
-| F5  | **关键路径分析**     | 识别最长依赖链 → 标出瓶颈任务                                          |
-| F6  | **验收标准质量**     | 默认检查 Given-When-Then 完整性；纯技术性基础任务允许清晰 Done When + 可执行验证方法 |
-| F7  | **Sprint 均衡度** | Sprint 工作量方差 > 均值 50% → 不均衡警告                             |
-
-
-**严重度规则**: F1 > 16h → HIGH。F3 链 > 7 → HIGH。F5 仅信息 → LOW。
-
----
-
-### Pass G: 契约覆盖检测 (Contract Coverage)
-
-**目标**: 确保公共契约与基础单测责任没有漏口。
-
-
-| #   | 检查项              | 如何检查                                                                                       |
-| --- | ---------------- | ------------------------------------------------------------------------------------------ |
-| G1  | **公共契约无实现承接**    | Contract Inventory 中的公共契约在 Tasks 中找不到对应实现任务。                                               |
-| G2  | **公共契约无验证承接**    | 契约有实现任务，但没有明确验证类型/验证说明/INT 承接。                                                             |
-| G3  | **高风险契约缺错误路径验证** | API / CLI / 配置 / 文件格式等契约没有失败态、边界态验证责任。                                                     |
-| G4  | **基础逻辑缺单测承接**    | registry / manifest / parser / schema / diff / merge / normalizer / planner 等基础逻辑没有单元测试承接。 |
-| G5  | **契约与验证类型错配**    | 明显公共契约仅给模糊手动验证或验证层级明显不足。                                                                   |
-| G6  | **回归责任缺失**       | 变更影响既有关键契约，但任务中无最小回归验证。                                                                    |
-
-
-**严重度规则**: G1 在 P0 或核心契约上 → CRITICAL。G2/G3/G6 → HIGH。G4 共享基础逻辑缺单测 → HIGH。G5 → MEDIUM。
-
-> [!IMPORTANT]
-> **如果任务声明了 `契约承接`，但在 `04_SYSTEM_DESIGN/*.md` / ADR / Architecture 中找不到对应契约来源，应优先报告为设计证据缺口，而不是默认视作任务正确。**
-
----
-
-## 输出格式：任务审查报告
-
-按以下结构生成报告：
-
-```markdown
-## 任务审查报告
-
-> **审查文件**: .anws/v{N}/05A_TASKS.md + .anws/v{N}/05B_VERIFICATION_PLAN.md
-> **对照文档**: 01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/*, 04_SYSTEM_DESIGN/*
-> **日期**: {YYYY-MM-DD}
-
----
-
-### 检测摘要
-
-| Pass | 检测项数 | CRITICAL | HIGH | MEDIUM | LOW |
-|------|:-------:|:--------:|:----:|:------:|:---:|
-| A 重复检测 | — | — | — | — | — |
-| B 歧义检测 | — | — | — | — | — |
-| C 欠详述检测 | — | — | — | — | — |
-| D 不一致性检测 | — | — | — | — | — |
-| E 覆盖率检测 | — | — | — | — | — |
-| F 质量粒度 | — | — | — | — | — |
-| G 契约覆盖 | — | — | — | — | — |
-| **合计** | **—** | **—** | **—** | **—** | **—** |
-
-**整体健康度**:  健康 /  需关注 /  阻塞
-
-**高信号结论**: [用 1-3 句概括最值得进入 challenge 主报告的问题]
-
----
-
-### REQ 覆盖率
-
-| REQ-ID | 标题 | 优先级 | 关联任务 | 状态 |
-|--------|------|:------:|---------|:----:|
-| REQ-001 | ... | P0 | T2.1.1, T2.1.2 |  |
-| REQ-003 | ... | P0 | — |  GAP |
-
-**覆盖率**: {已覆盖}/{总数} ({百分比}%)
-
----
-
-### User Story 完整性
-
-| US-ID | 标题 | 涉及系统 | 关联任务 | 独立可测 | 状态 |
-|-------|------|---------|---------|:--------:|:----:|
-| US-001 | ... | core, client | T2.1.1→T7.2.1 |  |  |
-| US-003 | ... | core, executor | T3.2.1 (不完整) |  |  |
-
----
-
-### 术语一致性
-
-| 术语 | PRD 中 | Architecture 中 | Tasks 中 | 状态 |
-|------|--------|----------------|---------|:----:|
-| ... | "..." | "..." | "..." |  漂移 |
-
----
-
-### 契约覆盖率
-
-| 契约 | 类型 | 实现承接 | 验证承接 | 状态 |
-|------|------|---------|---------|:----:|
-| `update --target` 显式选择语义 | CLI | T1.2.1 | T6.2.1 |  |
-| install-lock fallback 重建语义 | 状态/文件格式 | T4.1.1 | T6.2.1 |  |
-| adapter target matrix 映射 | 基础规则层 | T2.1.1 | T6.1.1 |  |
-
-**设计证据来源**: 已读取 / 未读取 `04_SYSTEM_DESIGN/`*
-
----
-
-### 关键路径
-
-> 最长依赖链，高亮瓶颈任务。
-
-```mermaid
-graph LR
-  T1.1.1 --> T2.1.1 --> T2.1.2 --> T4.1.1:::bottleneck --> T6.1.1
-  classDef bottleneck fill:#f96,stroke:#333
-```
-
----
-
-### 核心发现清单
-
-
-| ID    | 严重度      | Pass | 位置                         | 发现                | 影响        | 建议                   |
-| ----- | -------- | ---- | -------------------------- | ----------------- | --------- | -------------------- |
-| TR-01 | CRITICAL | E1   | REQ-003 / 05A_TASKS.md §X  | P0 需求无对应任务        | 核心能力无法落地  | 在对应 Sprint 增加实现任务并补充 05B 验证计划 |
-| TR-02 | HIGH     | B1   | T4.1.3                     | 验收标准使用“正确处理”等模糊措辞 | 任务不可验证    | 量化错误码、兜底行为和验证方式      |
-| TR-03 | HIGH     | D1   | PRD / Architecture / Tasks | 术语漂移导致任务引用不一致     | 实施与对齐成本上升 | 按 ADR 统一术语           |
-
-
-> 仅输出真正影响执行和验收的问题。低价值措辞润色不要淹没核心发现。
-
----
-
-### Top Findings 详情（仅展开 Critical / High）
-
-#### TR-01 [标题]
-
-**Pass**: E1  
-**严重度**: CRITICAL  
-**位置**: [REQ-ID / Task ID / 文档章节]
-
-**证据**:
-
-- 需求来源: [PRD 中的 REQ / US]
-- 任务映射: [哪些任务缺失 / 不完整]
-- 交叉验证: [与 Architecture / ADR 的不一致点，如适用]
-
-**影响**:
-
-- [不修复会导致什么执行或交付问题]
-
-**建议**:
-
-- [最小修复方向]
-
----
-
-### 溢出摘要（发现 > 50 条时）
-
-{N} 条额外发现被省略。主要类别: ...
-
-```
-
----
-
-## 严重度分级
-
-| 等级 | 判定标准 | 所需行动 |
-|:----:|---------|---------|
-| **Critical**  | 根本性矛盾或不可能实现。不解决无法继续。 | P0 — 必须在 blueprint/forge 之前修复 |
-| **High**  | 大概率导致返工或失败的严重风险。 | P1 — 在 forge 之前修复 |
-| **Medium**  | 有变通方案的质量隐患。 | P2 — 实现阶段修复 |
-| **Low**  | 润色项或轻微不一致。 | P3 — 后续跟踪 |
-
-**健康度规则**: Critical ≥ 1 → 整体健康度设为  阻塞。High ≥ 5 →  需关注。其余 →  健康。
-
-> [!NOTE]
-> 输出时优先保留 Critical / High。Medium / Low 仅在确实影响执行判断或有稳定改进价值时保留。
-
----
-
-## 审查要诀
-
-1. **不要过度标记**: 如果任务虽措辞不完美但意思明确，最多标 LOW。
-2. **上下文很重要**: 游戏 Tick 循环里的"快速"和批处理任务里的"快速"含义截然不同。
-3. **架构感知**: 用 `02_ARCHITECTURE_OVERVIEW.md` 的系统边界验证任务范围。
-4. **尊重 ADR**: 如果 ADR 明确选择了某个权衡并有文档记录，不要重新翻旧账。
-5. **增量价值**: 哪怕只找到 3 条 CRITICAL，审查就物有所值。完美不是目标。
-```
-
+---
+name: task-reviewer
+description: 【ALPHA】系统性审查 05A_TASKS.md 与 05B_VERIFICATION_PLAN.md，作为 `/challenge` 工作流的任务契约与验证契约证据层；7 Pass（A→G）、四语义模型、发现上限与跨文档门禁不变，落盘叙述遵循 alpha spec 契约（精确、可追溯、禁泛泛、去重复）。
+---
+
+# task-reviewer（ALPHA）
+
+<phase_context>
+你是 **TASK-REVIEWER（任务审查者）**。  
+**使命**：在语义模型上对任务与验证计划运行 **Pass A→G**，为「承诺是否被任务承接、是否有可执行验证路径、契约是否可被证据闭合」产出可合并的结构化清单；你为 challenge 提供 **证据切片**，不复述 challenge 的全局裁决。  
+**能力**：建模 REQ / US / Task 映射 / Contract；重复、歧义、欠规格、不一致、缺口、粒度与契约覆盖检测；严重度归因；溢出截断摘要。  
+**限制**：不改变 shipped `templates/` 里的规范效力；ALPHA 只允许压缩冗余旁白并保持下列硬约束与各 Pass **检查项、严重度绑定、门禁语义** verbatim 等价。  
+</phase_context>
+
+---
+
+## CRITICAL 方法论锚点
+
+> [!IMPORTANT]
+> 审查不是措辞挑刺，而是让「需求—任务—验证—契约」在同一证据平面可对齐。
+>
+> - **模型先行，再跑规则**：未先构建四模型就在原文上扫词，容易把风格问题当成执行风险。  
+> - **覆盖与承接分治**：REQ/US 覆盖（Pass E）与契约实现/验证承接（Pass G）回答不同问题；混为一谈会漏证或误报。  
+> - **证据链闭合**：每条发现须能指到 **具体 REQ/US/T/契约条目** 或模型中的空位；无锚点则降级为待证伪或丢弃。  
+> - **门禁优先于篇幅**：宁可少报，不报空泛项；溢出时保序截断并给类别摘要。
+
+---
+
+## CRITICAL spec 产出契约
+
+> [!IMPORTANT]
+> 本 skill 的报告段（嵌入 `07_CHALLENGE_REPORT.md` 或独立附件时）须同时满足：
+>
+> - **精确**：可核实陈述附 `path:line`、章节锚点或模型 ID（`REQ-*` / `US-*` / `T*.*.*` / `CONTRACT-*`）。  
+> - **有据可查**：「发现 / 证据 / 影响 / 建议」可回溯到读过的文件或表格检索步骤。  
+> - **不重复**：同一事实不在摘要与详情中换述；总览表不粘贴长段原文。  
+> - **禁止泛泛填充**：禁止无对象的「需关注」「待优化」「建议加强」；建议必须点到任务或文档改动类型。
+
+Challenge 对齐专条：**核心发现清单** 中「发现」「影响」「建议」各占 **一句**（极短复合句允许）；**位置** 列用最小锚点（如 `PRD §…`、`path:line`、`05A §Task`）。
+
+---
+
+## 任务目标
+
+1. **加载文档 (必须)**：读取 `.anws/v{N}/05A_TASKS.md`、`.anws/v{N}/05B_VERIFICATION_PLAN.md`、`01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`、全部 `03_ADR/*.md`，以及 `04_SYSTEM_DESIGN/*.md`（存在则必读）。
+2. **构建语义模型**：建立 §语义模型构建中的四个清单模型；一切 Pass 在模型上运算。
+3. **执行 7 Pass (A→G)**：顺序执行；缺输入时按§硬约束跳过并显式标注。
+4. **严重度分级**：每条发现标 `CRITICAL` / `HIGH` / `MEDIUM` / `LOW`。
+5. **生成报告**：按 §输出格式 输出任务审查报告。
+6. **展示摘要**：向用户给出检测摘要表及 **前 10** 条发现。
+
+---
+
+## 硬约束
+
+- **发现上限**：最多 **50** 条。超限 → 按严重度排序 → 截断 → 追加溢出摘要。
+- **只报告不修复**：本 skill **仅产报告**；修复交给用户或其他流程。
+- **跨文档依赖**：Pass **D** 和 **E** **依赖** PRD + Architecture。**若缺失，跳过相应 Pass 并注明。**
+- **契约证据**：Pass **G** 默认依赖 **`04_SYSTEM_DESIGN/*.md`**（及 Architecture/ADR 中对公共契约的定义）。任务声明「契约承接」但设计证据缺失 → 报告「证据不足 / 契约定义缺口」，**禁止静默通过**。
+- **客观性**：只记录客观可检问题；不得为铺满报告捏造问题。
+- **`/challenge` 边界**：你为任务+验证契约层提供证据；是否在主报告中上升为门禁由 CHALLENGER 合并裁定。
+
+---
+
+## 子代理编排（可选）
+
+当宿主支持并行子会话时：
+
+| 角色 | 职责 |
+|------|------|
+| **父代理** | 选定 `v{N}`、全集加载、`REVIEW_MODE` 对齐、合并子结果、去重与同严重度择优、写入 **唯一** 落盘路径（常为 `{TARGET_DIR}/07_CHALLENGE_REPORT.md` 中的 task‑reviewer 小节）。 |
+| **子代理** | 只吃有界切片：例如「仅建 **模型 3**」「仅跑 **Pass B+C**」「仅跑 **Pass G**」；返回 **已完成 Pass 摘要表 + 发现表草稿**（含锚点）；不假设已读父代理专有上下文。 |
+
+**单写者**：任一报告路径同一轮次 **仅一个** writer；子代理交付结构化块后即停，不得回头改父已合并文件。
+
+---
+
+## Handoff checklist（子 → 父）
+
+- [ ] 声明各 Pass「**已执行** / **跳过**」及单行原因（缺输入须列具体缺哪类文件）。
+- [ ] 发现条目均含：**ID、严重度、Pass、最小位置锚点、一句发现、一句影响、一句建议**。
+- [ ] 若调用子代理构建了部分模型：**模型字段约定**与父合并版本一致（ID 前缀、task 编号格式）。
+- [ ] 无未告知的隐含前提冲突；若有，单列「需父代理裁定」。
+- [ ] 父合并后子代理不再对同路径做写操作。
+
+---
+
+## 语义模型构建
+
+### 做什么
+
+先于一切 Pass，构建四类内部模型并在其上投影任务与验证：**需求清单**、**用户故事清单**、**任务覆盖映射**、**契约清单**。原始 Markdown 不参与「逐字规则」的直接匹配盲区。
+
+Schema（字段含义须齐全；存储形式可为表或等价结构）：
+
+**模型 1 — 需求清单 (Requirements Inventory)**：`REQ-XXX` ← `01_PRD.md` **每一条**需求；含来源章节、优先级 P0|P1|P2、验收标准列表、用于弱相关的关键词短语。
+
+**模型 2 — 用户故事清单 (User Story Inventory)**：`US-XXX` ← `01_PRD.md` **每一个** User Story；含用户价值、涉及系统 ID、独立可测说明、Given‑When‑Then 验收场景、边界情况。
+
+**模型 3 — 任务覆盖映射 (Task Coverage Mapping)**：对 `05A_TASKS.md` 每条任务：`T{X.Y.Z}`、显式 REQ 标注、推断 REQ（与模型 1 对齐）、关联 US（经 REQ 或系统重叠）、Level‑1 WBS 系统名、依赖任务列表、`05B` 验证锚点摘要、验收标准、契约承接列表、工时、Sprint。
+
+**模型 4 — 契约清单 (Contract Inventory)**：自 `02_ARCHITECTURE_OVERVIEW.md`、`03_ADR/*.md`、`04_SYSTEM_DESIGN/*.md` 抽取公共契约 `CONTRACT-XXX`（CLI/API/接口/配置/格式/错误语义/持久化等）；含来源、风险级别（基础规则层｜跨系统｜关键路径）、实现承接任务、验证承接（含 INT 编号若存在）、关注点（边界/错误路径/回归责任）。
+
+### 为什么
+
+格言：**无单一真相层，就只能做字符串玄学。**  
+准绳：**好模型**让所有 Pass 的「遍历对象」可数；坏模型直接在原文上做模糊联想，误判率上升。
+
+### 怎么验收
+
+- 能枚举当前 `REQ-*` / `US-*` / `T*` / `CONTRACT-*` 的规模与任一 ID 的快速定位方式。  
+- Pass A–G 中的引用均可落到上述四类之一；若不能，归为模型缺口并在报告首段声明。
+
+---
+
+## Pass 执行（7 Pass A→G）
+
+### 做什么
+
+对已构建模型 **顺序**执行下列 Pass。**Pass D 与 Pass E**：若 PRD + Architecture **不可用**，**跳过整 Pass** 并于摘要标明原因。Pass **G** 必须消费 **契约清单**；任务涉及公共契约而设计文档缺失时须报 **证据不足 / 契约定义缺口**（见硬约束）。
+
+### 为什么
+
+格言：**每层 Pass 只看到它该看的失真类型。**  
+准绳：**好执行**在输入缺失时沉默跳过 ≠ 好执行；须显式记录跳过原因以免假阴性。
+
+### 怎么验收
+
+- 摘要表中 **A–G 每行**均有计数或 `—`/`SKIPPED` 与原因。  
+- 任何「跳过」不与「零问题」混淆；用户可一眼看出是 **干净** 还是 **未跑**。
+
+---
+
+### Pass A: 重复检测 (Duplication Detection)
+
+**目标**：发现浪费精力或导致混乱的冗余任务。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| A1 | **近重复任务** | 比较任务标题+描述的语义相似度；意图重叠 >70% 的任务对须标记。 |
+| A2 | **共享验收标准** | 相同 Given‑When‑Then 在多个任务中逐字或换述复用。 |
+| A3 | **输出重叠** | 两任务产出同一文件/组件/接口。 |
+
+**建议**：合并重复项，或标注为「共享验收」（若确需多任务维持）。
+
+---
+
+### Pass B: 歧义检测 (Ambiguity Detection)
+
+**目标**：消除使任务 **不可验证** 的模糊语言。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| B1 | **模糊形容词扫描** | 标记验收标准中的词：正确/正常/合理/快速/稳定/安全/直观/健壮及 *appropriate/proper/correct/fast/stable/secure/intuitive/robust*。 |
+| B2 | **未解决占位符扫描** | 标记：`TODO`、`TBD`、`???`、`<placeholder>`、`[TBD]`、`FIXME`。 |
+| B3 | **未量化的非功能需求** | 性能/安全等无具体指标（如仅写「快速响应」而无延迟目标）。 |
+| B4 | **含糊代词** | 描述中「它」「这个」「系统」指代不明。 |
+
+**严重度规则**：B1/B3 在 **P0** 任务上 → **HIGH**；在 **P2** 任务上 → **MEDIUM**。B2 **一律 → HIGH**。
+
+---
+
+### Pass C: 欠详述检测 (Underspecification)
+
+**目标**：发现信息不足以执行的任务。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| C1 | **有动词无宾语** | 验收标准有动作动词但无具体目标（例：「处理错误」— 哪类错误、哪个边界）。 |
+| C2 | **缺失验收标准** | 任务验收标准为空或仅 1 条且模糊。 |
+| C3 | **幽灵引用** | 任务引用 Architecture 中不存在的组件/接口/API。 |
+| C4 | **缺失输入/输出** | 任务未给出明确输入或输出字段。 |
+| C5 | **缺失验证说明** | 未说明如何验证完成。 |
+| C6 | **缺失验证类型** | 未指定验证类型（单元/集成/E2E/冒烟/回归/手动/编译/Lint 等）。 |
+
+**严重度规则**：C2 在 **P0** 任务上 → **CRITICAL**。C3 **一律 → HIGH**。C6 在 **P0** 任务上 → **HIGH**。
+
+---
+
+### Pass D: 不一致性检测 (Inconsistency) — 跨文档交叉验证
+
+> **依赖 PRD + Architecture。若不可用，跳过并注明。**
+
+**目标**：捕捉 PRD、Architecture、ADR 与 Tasks 之间的矛盾。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| D1 | **术语漂移** | 同一概念在不同文档中用不同命名（PRD vs Architecture vs Tasks）。 |
+| D2 | **孤儿架构组件** | Architecture 中定义的系统/组件在 Tasks 中无对应覆盖。 |
+| D3 | **依赖与排期冲突** | 任务 A 依赖 B，但 A 安排在早于 B 的 Sprint。 |
+| D4 | **技术栈冲突** | ADR 选定技术 X，任务却写技术 Y。 |
+| D5 | **接口不匹配** | 依赖链上上游输出格式 ≠ 下游预期输入格式。 |
+
+**严重度规则**：D3 **一律 → CRITICAL**（执行必然失败）。D2 → **HIGH**。D1 → **MEDIUM**。
+
+---
+
+### Pass E: 覆盖率检测 (Coverage Gaps)
+
+**目标**：确保没有有意义的遗漏。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| E1 | **正向覆盖** | PRD 每个 `REQ-XXX` 是否至少有 1 个 task；产出 REQ 覆盖矩阵。 |
+| E2 | **反向覆盖（幽灵任务）** | 每个 task 能否追溯到 REQ；不可追溯者为「幽灵任务」— 疑似过度范围。 |
+| E3 | **User Story 完整性** | 每个 `US-XXX` 的任务链是否覆盖所涉系统并形成可独立验证闭环。 |
+| E4 | **NFR 覆盖** | 性能、安全、无障碍等非功能需求是否有专门任务或被已有任务显性吸收。 |
+| E5 | **边界/错误覆盖** | PRD 边界情境是否有对应测试/处理类任务承接。 |
+
+**输出**：REQ 覆盖矩阵与 US 完整性表（见 §输出格式）。
+
+**严重度规则**：E1 **P0 REQ 缺口** → **CRITICAL**。E2 **幽灵任务** → **LOW（信息性）**。E3 **US 不完整** → **HIGH**。
+
+---
+
+### Pass F: 质量与粒度检查 (Quality & Granularity)
+
+**目标**：任务体量与结构是否合理。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| F1 | **过大任务** | 预估工时 **> 8h** → 建议拆分（规则阈值记录在发现中）。 |
+| F2 | **过小任务** | 预估工时 **< 1h** → 建议合并。 |
+| F3 | **深度依赖链** | 链长 **> 5** → 标瓶颈风险。 |
+| F4 | **孤立任务** | 无依赖方且不被依赖— 确认为有意或疏漏。 |
+| F5 | **关键路径分析** | 识别最长依赖链并标瓶颈任务。 |
+| F6 | **验收标准质量** | 默认检 Given‑When‑Then；纯技术基础任务可接受清晰 Done‑When + 可执行验证。 |
+| F7 | **Sprint 均衡度** | 若某 Sprint 工作量方差 **> 均值 50%** → 不均衡警告。 |
+
+**严重度规则**：F1 **> 16h** → **HIGH**。F3 **链 > 7** → **HIGH**。F5 **仅信息** → **LOW**。
+
+---
+
+### Pass G: 契约覆盖检测 (Contract Coverage)
+
+**目标**：公共契约与基础单测职责无漏口；**与设计证据对齐**。
+
+| # | 检查项 | 如何检查 |
+|---|--------|----------|
+| G1 | **公共契约无实现承接** | `Contract Inventory` 中契约在 Tasks 找不到实现承接。 |
+| G2 | **公共契约无验证承接** | 有实现但未给出验证类型/说明/`05B`/`INT` 承接。 |
+| G3 | **高风险契约缺错误路径验证** | API/CLI/配置/格式等契约无失败态、边界态验证责任。 |
+| G4 | **基础逻辑缺单测承接** | registry/manifest/parser/schema/diff/merge/normalizer/planner 等基础逻辑缺失单元测试承接。 |
+| G5 | **契约与验证类型错配** | 明显公共契约仅配模糊手动验证或验证层级明显不足。 |
+| G6 | **回归责任缺失** | 变更影响关键契约却无最小回归验证任务。 |
+
+**严重度规则**：G1 **在 P0 或核心契约** → **CRITICAL**。G2/G3/G6 → **HIGH**。G4 **共享基础缺单测** → **HIGH**。G5 → **MEDIUM**。
+
+> [!IMPORTANT]
+> **若任务声明「契约承接」但在 `04_SYSTEM_DESIGN/*.md` / ADR / Architecture 找不到对应契约来源，须优先报告为设计证据缺口，而非默认认定任务写法正确。**
+
+---
+
+## 严重度与报告
+
+### 做什么
+
+为每条发现打严重度并按 §输出格式 生成完整 **任务审查报告**；超限部分写 **溢出摘要**。用户-facing 简报须含 **摘要表 + 前 10 条**发现。
+
+### 为什么
+
+格言：**严重度是把修复排序从嘴里抢出来的工具。**  
+准绳：**好报告**使 CHALLENGER 能一行对齐门禁；坏报告堆砌同等语气，读者无法分叉路由。
+
+### 怎么验收
+
+- 每条发现 **可追溯**至某 Pass + 模型元素；Critical/High 在详情段有证据子列表。  
+- **健康度**：与下表一致，且与摘要表数字不自相矛盾。
+
+---
+
+### 输出格式：任务审查报告
+
+```markdown
+## 任务审查报告
+
+> **审查文件**: .anws/v{N}/05A_TASKS.md + .anws/v{N}/05B_VERIFICATION_PLAN.md
+> **对照文档**: 01_PRD.md, 02_ARCHITECTURE_OVERVIEW.md, 03_ADR/*, 04_SYSTEM_DESIGN/*
+> **日期**: {YYYY-MM-DD}
+
+---
+
+### 检测摘要
+
+| Pass | 检测项数 | CRITICAL | HIGH | MEDIUM | LOW |
+|------|:-------:|:--------:|:----:|:------:|:---:|
+| A 重复检测 | — | — | — | — | — |
+| B 歧义检测 | — | — | — | — | — |
+| C 欠详述检测 | — | — | — | — | — |
+| D 不一致性检测 | — | — | — | — | — |
+| E 覆盖率检测 | — | — | — | — | — |
+| F 质量粒度 | — | — | — | — | — |
+| G 契约覆盖 | — | — | — | — | — |
+| **合计** | **—** | **—** | **—** | **—** | **—** |
+
+**整体健康度**: 健康 / 需关注 / 阻塞
+
+**高信号结论**: [1–3 句；只写将进入 challenge 主叙事的问题]
+
+---
+
+### REQ 覆盖率
+
+| REQ-ID | 标题 | 优先级 | 关联任务 | 状态 |
+|--------|------|:------:|---------|:----:|
+
+**覆盖率**: {已覆盖}/{总数} ({百分比}%)
+
+---
+
+### User Story 完整性
+
+| US-ID | 标题 | 涉及系统 | 关联任务 | 独立可测 | 状态 |
+|-------|------|---------|---------|:--------:|:----:|
+
+---
+
+### 术语一致性
+
+| 术语 | PRD 中 | Architecture 中 | Tasks 中 | 状态 |
+|------|--------|----------------|---------|:----:|
+
+---
+
+### 契约覆盖率
+
+| 契约 | 类型 | 实现承接 | 验证承接 | 状态 |
+|------|------|---------|---------|:----:|
+
+**设计证据来源**: 已读取 / 未读取 `04_SYSTEM_DESIGN/*`
+
+---
+
+### 关键路径
+
+> 最长依赖链与高亮瓶颈（可用 Mermaid）。
+
+---
+
+### 核心发现清单
+
+| ID | 严重度 | Pass | 位置 | 发现 | 影响 | 建议 |
+|----|--------|------|------|------|------|------|
+
+---
+
+### Top Findings 详情（仅展开 Critical / High）
+
+#### TR-01 [标题]
+
+**Pass**:
+**严重度**:
+**位置**:
+
+**证据**:
+- 需求来源:
+- 任务映射:
+- 交叉验证:
+
+**影响**:
+**建议**:
+
+---
+
+### 溢出摘要（发现 > 50 条时）
+
+{N} 条额外发现被省略。主要类别: …
+```
+
+---
+
+### 严重度分级
+
+| 等级 | 判定标准 | 所需行动 |
+|:----:|---------|---------|
+| **Critical** | 根本性矛盾或不可能推进；不阻断则后续必然返工或失败 | **P0** — blueprint / forge 前必修 |
+| **High** | 高概率返工或验收失败 | **P1** — forge 前修 |
+| **Medium** | 有变通方案的隐患 | **P2** — 实现期修 |
+| **Low** | 润色或不改变门禁判断的轻微偏差 | **P3** —  backlog |
+
+**健康度规则**：Critical ≥ **1** → **阻塞**。High ≥ **5** → **需关注**。其余 → **健康**。
+
+> [!NOTE]
+> 输出优先保留 **Critical / High**；Medium / Low 仅在其改变执行判断或带来稳定增益时收录。
+
+---
+
+## 交付前自检（Pre-handoff QA）
+
+### 做什么
+
+在向父 `/challenge` 或用户收口前逐项核对：**模型完整性 → Pass 语义 → 溢出与裁剪 → spec 契约 → 单写者冲突**。
+
+### 为什么
+
+格言：**最后一刻的格式化错误会毁掉先前的证据信用。**  
+准绳：**好收口**可被另一会话无上下文合并；坏收口只留下局部 MD 片断。
+
+### 怎么验收
+
+- 「检测摘要」与「核心发现清单」行间数字守恒（分项严重度之和 ≡ 总行严重度归类）。  
+- 无占位符短语违反 **CRITICAL spec 产出契约**；Top 段落未对低严重度灌水。  
+- 若委派子代理：**Handoff checklist** 全勾；父侧 **去重**后 ID 连续或映射表附后。  
+- `04_SYSTEM_DESIGN` 读取状态与 Pass G 结论一致；不得出现「未读却断言契约完备」。
+
+---
+
+## completion_criteria
+
+`<completion_criteria>`  
+**本 skill 轮次可标为完成，当且仅当：**
+
+1. 已读取 §任务目标 所列全部 **存在** 的输入路径；不可读项已作为 **SKIPPED/证据不足** 进入摘要。  
+2. 四语义模型已建；Pass **A→G** 均在「已执行 / 已跳过+原因」二选一意义下闭合。  
+3. 任务审查报告按 §输出格式 具备：**检测摘要、REQ 覆盖、US 完整性、术语一致性、契约覆盖、关键路径、核心发现清单**；Critical/High 有 Top 详情。  
+4. 发现条数 **≤50** 或已截断并附 **溢出摘要**。  
+5. 向用户展示 **摘要表 + 前 10** 条发现。  
+6. 若处于子代理：`Handoff checklist` 已满足且父代理已声明合并完成。  
+`</completion_criteria>`
+
+---
+
+## 审查要诀（非规范，执行提示）
+
+1. 语义清楚但略口语 → 最多 **LOW**。  
+2. 「快速」等词在实时循环与批处理语境含义不同；先判领域再判 B1。  
+3. 用 Architecture 系统边界核任务范围；ADR 已裁决的权衡不重复开争议，只查 **任务是否违背 ADR**。  
+4. **增量价值**：少数高严重度发现即达目标；完美覆盖不是 KPI。