haaaiawd 任务目标
- 加载文档 (必须): 读取
.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（如存在）。 - 构建语义模型: 构建 4 个清单模型（见 §语义模型构建）。
- 执行 7 大 Pass (A→G): 顺序执行每个检测 Pass——每个 Pass 在语义模型上操作。
- 严重度分级: 为每条发现分配严重度（CRITICAL / HIGH / MEDIUM / LOW）。
- 生成报告: 输出任务审查报告（见 §输出格式）。
- 展示摘要: 向用户展示检测汇总表 + 前 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 中找不到对应契约来源，应优先报告为设计证据缺口，而不是默认视作任务正确。
输出格式：任务审查报告
按以下结构生成报告：
## 任务审查报告
> **审查文件**: .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，审查就物有所值。完美不是目标。