@haaaiawd/anws 2.2.4 → 2.2.5

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

@@ -1,699 +1,253 @@
----
-
-## name: task-planner
-description: 使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。
-
-# 任务规划大师手册 (Task Planning Master Manual)
-
-> "A task that can't be verified is a task that never finishes.  
-> A task without context is a task that's never understood."
-
-你是**任务规划大师**，负责将系统设计转化为**可执行的层次化任务清单**。
-
----
-
-## 快速开始
-
-1. **定位版本**：扫描 `.anws/` 找最新 `v{N}`
-2. **加载必需文档**：读取 Architecture Overview + PRD
-3. **加载可选文档**：扫描 ADR 目录 + System Design 目录
-4. **缺失检查**：必需文档缺失则报错退出
-5. **加载测试约束**：如果 Workflow 或 ADR 提供测试策略、质量门禁、Sprint 边界，必须一并纳入任务生成输入
-6. **执行拆解**：按 WBS 方法拆解任务
-7. **应用验证类型选择逻辑**：为每个任务分配“最轻但足够”的验证类型，避免默认升级为 E2E
-8. **输出**：保存到 `.anws/v{N}/05_TASKS.md`
-
----
-
-## 核心原则
-
-> [!IMPORTANT]
-> **任务规划的四大原则**：
->
-> 1. **WBS层次化** - Work Breakdown Structure三级组织
-> 2. **原子化** - 每个 Task 优先控制在 2h-2d
-> 3. **可验证** - 默认使用 Given / When / Then；仅纯技术性基础任务允许清晰 Done When
-> 4. **可追溯** - 每个Task关联PRD需求 [REQ-XXX]
-
-> [!IMPORTANT]
-> **测试规划附加原则**：
->
-> - 优先选择**最轻但足够**的验证类型
-> - 如 Workflow / ADR 已声明测试策略，必须优先遵循，不得自行改重
-> - **冒烟测试默认仅用于 `INT-S{N}` 或极少数里程碑任务**
-> - **回归测试仅在已有关键能力可能被破坏时生成**，不是所有任务的默认要求
-> - **基础层、共享层、纯逻辑层默认优先单元测试**，主要分支、边界情况与错误路径应尽量覆盖
-> - **公共契约必须有承接**：至少一个实现任务 + 至少一个验证承接点
-
- **错误做法**：
-
-- 平铺任务列表（无层次）
-- 任务过大（如"实现整个后端"）
-- 任务过小（如"写一行代码"）
-- 缺少验收标准
-- 忽略依赖关系
-
- **正确做法**：
-
-- **三级层次**: System → Phase → Task
-- **合理粒度**: 每个 Task 2h-2d
-- **清晰验收**: 默认 Given / When / Then，必要时使用清晰 Done When
-- **完整元数据**: ID, [REQ-XXX], 描述, 输入, 输出, 验收, 估时, 依赖, 优先级
-
----
-
-## WBS方法：Work Breakdown Structure
-
-### Level 1: System (系统级)
-
-**按系统分组**，从Architecture Overview获取系统清单。
-
-**示例**:
-
-```markdown
-## System 1: Frontend UX System
-## System 2: Backend API System
-## System 3: Database System
-```
-
-**规则**:
-
-- 每个系统对应Architecture Overview中的一个系统
-- 系统顺序按依赖关系排列（被依赖的在前）
-
----
-
-### Level 2: Phase (阶段级)
-
-**每个系统内按实施阶段分组**。
-
-**标准Phases**:
-
-1. **Foundation** (基础设施) - 环境配置、项目初始化、依赖安装
-2. **Core** (核心功能) - 主要业务逻辑实现
-3. **Integration** (集成) - 跨系统集成、API对接
-4. **Polish** (优化) - 性能优化、错误处理、测试完善
-
-**示例**:
-
-```markdown
-### Phase 1: Foundation (基础设施)
-### Phase 2: Core Components (核心组件)
-### Phase 3: Integration (集成)
-### Phase 4: Polish (优化)
-```
-
-**规则**:
-
-- Phase按自然顺序排列（Foundation → Core → Integration → Polish）
-- 每个Phase有明确的目标说明
-
----
-
-### Level 3: Task (任务级)
-
-**每个Phase内的具体任务**。
-
-> [!IMPORTANT]
-> **每个任务的「输入」必须引用设计文档**，禁止凭空编造。
->
-> 可引用的文档类型：
->
-> - `02_ARCHITECTURE_OVERVIEW.md` §章节 - 系统边界、依赖关系
-> - `01_PRD.md` - 需求定义、User Story
-> - `03_ADR/ADR-XXX.md` - 架构决策、技术约束
-> - `04_SYSTEM_DESIGN/{system}.md` §章节 - 接口契约、数据模型
-> - 好: `04_SYSTEM_DESIGN/auth.md` §JWT 签发
-> - 差: "JWT 相关设计"（无具体文档引用）
-
-**Task结构**:
-
-```markdown
-- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
-  - **描述**: 简洁说明"做什么"（不是"怎么做"）
-  - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
-  - **输出**: 产出什么交付物
-  - **契约承接**: 本任务实现或验证的公共契约；如无则写“无”
-  - ** 参考**: ADR-XXX 或 System Design 章节（如有）
-  - **验收标准**: 
-    - Given [前置条件]
-    - When [执行动作]
-    - Then [预期结果]
-    - （仅纯技术性基础任务允许使用清晰 Done When 列表）
-  - **验证类型**: 单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
-  - **验证说明**: 如何确认任务完成 (检查什么，如何确认)
-  - **估时**: 预估工时（如: 2h, 6h, 1d, 2d）
-  - **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
-  - **优先级**: P0 | P1 | P2
-```
-
-**示例**:
-
-```markdown
-- [ ] **T1.1.1** [基础]: 设置 Vite + React 项目
-  - **描述**: 初始化前端项目，配置Vite、React、TypeScript
-  - **输入**: PRD (React技术栈要求)
-  - **输出**: 可运行的Hello World应用 (`src/App.tsx`, `vite.config.ts`)
-  - **验收标准**: 
-    - [ ] `npm run dev` 正常启动
-    - [ ] 页面显示"Hello World"
-    - [ ] TypeScript类型检查通过
-  - **验证类型**: 编译检查
-  - **估时**: 2h
-  - **依赖**: 无
-  - **优先级**: P0
-```
-
-### 验证类型选择逻辑
-
-> [!IMPORTANT]
-> **如果 Workflow 未给出更具体约束，按以下默认顺序决策：**
-
-1. **局部逻辑 / 纯算法 / 数据变换** → 单元测试
-2. **跨模块 / 接口 / 数据库 / 多服务协作** → 集成测试
-3. **直接面向终端用户的关键路径** → E2E测试 或 手动验证
-4. **Sprint 退出标准 / 里程碑 gate** → 冒烟测试
-5. **修改可能影响已完成关键能力** → 回归测试
-6. **配置、脚手架、基础设施** → 编译检查 / Lint检查 / 手动验证
-
-**选择细则**:
-
-- 不要因为任务“看起来重要”就默认选择 E2E测试
-- 如果集成测试足以证明任务完成，就不要升级为 E2E测试
-- 如果只是里程碑 readiness 检查，优先使用少量冒烟测试，而不是新建大量 E2E任务
-- 如果只是验证旧能力未被破坏，优先复用已有测试集合作为回归测试
-
-### 契约风险覆盖规则
-
-> [!IMPORTANT]
-> **若任务产出包含新的公共契约或会修改现有公共契约，必须为其分配明确验证承接。**
-
-公共契约至少包括：
-
-- 操作契约
-- 跨系统接口
-- HTTP API
-- CLI 命令 / 参数语义
-- 配置结构 / 文件格式 / 状态格式
-- 错误语义 / 返回结构
-- 持久化结构
-
-规则：
-
-- 每个公共契约至少要有一个实现任务承接
-- 每个高风险公共契约至少要有一个验证承接点
-- 不得仅以“实现任务已有代码变更”视为契约闭合
-- 若契约属于基础规则层或低依赖纯逻辑，应优先补充单元测试，而不是直接升级为 E2E
-
-### 基础单测优先原则
-
-> [!IMPORTANT]
-> **对 registry、manifest、parser、planner、schema、diff、merge、normalizer、selector 等基础逻辑，优先生成单元测试任务。**
-
-- 如果这些逻辑是多个上层流程共享的基础设施，其单元测试默认视为必选，不应依赖高层流程测试间接覆盖
-- 如果一个 Sprint 新增了多个基础逻辑点，优先在同 Sprint 或紧邻 Sprint 内生成对应单测任务，不要全部拖到收尾期
-
-### Sprint 与冒烟测试绑定规则
-
-> [!IMPORTANT]
-> **只有在 Workflow 已提供 Sprint 路线图 / INT 任务语义时，才应生成里程碑级冒烟测试。**
-
-- 如果上游 Workflow 已定义 `INT-S{N}`，则将冒烟测试优先绑定到这些 INT 任务
-- 不要为每个普通 Level 3 开发任务单独生成冒烟测试
-- 若没有明确 Sprint / 里程碑边界，则优先退回单元测试、集成测试、手动验证，而不是滥造冒烟任务
-
-### 接口追溯规则
-
-> [!IMPORTANT]
-> **任务间的输入/输出必须对齐。**
->
-> 如果任务 B 依赖任务 A，则 B 的「输入」必须明确引用 A 的「输出」的具体产物（文件路径、接口名、数据格式）。
->
-> - 好: B 输入 = “T1.1.1 产出的 `App.tsx` 组件 + `vite.config.ts` 配置”
-> - 差: B 输入 = “前端项目”
-
----
-
-## 任务元数据完整性
-
-### 必需字段
-
-
-| 字段            | 格式                      | 说明               | 示例             |
-| ------------- | ----------------------- | ---------------- | -------------- |
-| **ID**        | T{System}.{Phase}.{Seq} | 唯一标识符            | T1.2.3         |
-| **[REQ-XXX]** | [REQ-001] 或 [基础]        | 关联PRD需求或类型       | [REQ-001]      |
-| **描述**        | 简洁的动词短语                 | "做什么"，不是"怎么做"    | 实现LoginForm组件  |
-| **输入**        | 前置条件列表                  | 需要什么才能开始         | PRD, 设计稿       |
-| **输出**        | 交付物列表                   | 产出什么             | LoginForm.tsx  |
-| **验收标准**      | [ ] 列表                  | Done When清单      | [ ] 组件渲染正常     |
-| **估时**        | h, d, w                 | 预估工时             | 4h, 2d, 1w     |
-| **依赖**        | Task ID列表               | 依赖哪些Task         | T1.1.1, T2.1.2 |
-| **优先级**       | P0, P1, P2              | Must/Should/Nice | P0             |
-
-
----
-
-### 可选字段
-
-
-| 字段      | 说明     | 示例                 |
-| ------- | ------ | ------------------ |
-| **负责人** | 建议的负责人 | @frontend-dev      |
-| **风险**  | 潜在风险   | 依赖外部API，可能不稳定      |
-| **备注**  | 额外说明   | 参考System Design第5章 |
-
-
----
-
-## 依赖关系类型
-
-### 1. 逻辑依赖 (Logical Dependency)
-
-**定义**: 技术上必须的先后顺序
-
-**示例**:
-
-```
-T3.1.1 (数据库Schema) → T2.2.1 (后端API实现)
-T2.2.1 (后端API实现) → T1.2.1 (前端组件消费API)
-```
-
-**如何识别**: 问"如果A没完成，B能开始吗？"
-
----
-
-### 2. 资源依赖 (Resource Dependency)
-
-**定义**: 共享资源导致的依赖
-
-**示例**:
-
-```
-T1.2.1 和 T1.2.2 由同一个开发者负责
-→ 必须串行执行（资源依赖）
-```
-
-**如何识别**: 问"A和B能否由不同人并行执行？"
-
----
-
-### 3. 偏好依赖 (Preference Dependency)
-
-**定义**: 最佳实践建议的顺序（技术上可以并行）
-
-**示例**:
-
-```
-T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
-虽然可以并行，但先有UI设计更好
-```
-
-**如何识别**: 问"虽然可以并行，但有推荐顺序吗？"
-
----
-
-## 任务拆分原则
-
-### 原则1: 2h-2d 规则
-
-**规则**: 单个 Task 应优先落在 2 小时到 2 天内；超过 2 天应继续拆分。
-
-**为什么？** 
-
-- 太大: 难以估时、风险不可控
-- 太小: 管理成本高、碎片化
-
-**检查**:
-
-- Task估时 > 2天 → 继续拆分
-- Task估时 < 2小时 → 考虑合并
-
----
-
-### 原则2: 单一交付物
-
-**规则**: 每个Task应该产出一个可验证的交付物。
-
-**示例**:
-
-- 好: "实现LoginForm组件" → 交付物: LoginForm.tsx
-- 差: "做前端" → 交付物不明确
-
----
-
-### 原则3: Git-Friendly
-
-**规则**: 每个Task应该对应一个可审查的PR。
-
-**示例**:
-
-- 好: Task完成 = 1个PR（~200-500行代码）
-- 差: Task完成 = 10个PR
-
----
-
-### 原则4: 可验证性
-
-**规则**: 每个 Task 必须有明确、可执行、可观察的验收标准；默认使用 Given / When / Then，纯技术性基础任务可使用清晰 Done When。
-
-**示例**:
-
-- 好: "Given 合法输入, When 调用接口, Then 返回 200 且结构符合契约"
-- 好: "[ ] 单元测试通过（仅用于纯技术性基础任务）"
-- 差: "Done When: 差不多完成了"
-
----
-
-## 任务规划守则
-
-### 守则1: 追溯链完整
-
-**规则**: 每个Task必须关联PRD需求 [REQ-XXX]。
-
-**为什么？** 确保所有实现都有需求依据，避免过度设计。
-
-**示例**:
-
-```markdown
-- [ ] **T2.2.1** [REQ-001]: 实现 POST /auth/login 端点
-```
-
-**检查**:
-
-- 所有PRD需求是否都映射到了至少一个Task？
-- 所有Task是否都关联了PRD需求？
-
----
-
-### 守则2: 验收标准具体化
-
-**规则**: 默认使用 Given / When / Then；仅当纯技术性基础任务不适合 GWT 时，才退回清晰的 Done When。
-
-**好的验收标准**:
-
-- Given 输入合法, When 调用接口, Then 返回 200 且结构符合契约
-- Given 非法凭证, When 请求登录, Then 返回 401 且错误语义一致
-- 单元测试通过（仅用于纯技术性基础任务）
-- Lint无错误（仅用于纯技术性基础任务）
-
-**差的验收标准**:
-
-- 功能正常（太模糊）
-- 代码写完了（无法验证）
-
----
-
-### 守则3: 依赖关系可视化
-
-**规则**: 必须提供Mermaid依赖图。
-
-**示例**:
-
-```mermaid
-graph TD
-    T1.1.1[前端项目初始化] --> T1.2.1[实现LoginForm]
-    T2.1.1[后端项目初始化] --> T2.2.1[实现/auth/login]
-    T3.1.1[数据库Schema] --> T2.2.1
-    T2.2.1 --> T1.2.1
-```
-
-
-
-**为什么？** 一图胜千言，帮助理解任务顺序。
-
----
-
-### 守则4: 估时保守
-
-**规则**: 估时应该偏保守，包含测试和文档时间。
-
-**估时公式**:
-
-```
-总估时 = 开发时间 × 1.5 + 测试时间 + 文档时间
-```
-
-**示例**:
-
-- 开发: 4h
-- 测试: 1h
-- 文档: 0.5h
-- **总估时**: 4 × 1.5 + 1 + 0.5 = 7.5h → 向上取整为 **1d**
-
----
-
-## 工具箱
-
-> **输出路径**: 任务清单应保存到 `.anws/v{N}/05_TASKS.md`，由调用方 (blueprint workflow) 指定具体的 `v{N}` 版本号。
-
-### 工具1: Tasks模板
-
-使用WBS三级层次结构组织任务。
-
-**模板**:
-
-```markdown
-# 任务清单 (Task List)
-
-## 依赖图总览
-[Mermaid依赖图]
-
-## System 1: [System Name]
-
-### Phase 1: Foundation
-[Tasks列表]
-
-### Phase 2: Core
-[Tasks列表]
-
-...
-```
-
----
-
-### 工具2: 依赖分析Checklist
-
-在拆分任务后，使用此Checklist分析依赖：
-
-- 识别所有逻辑依赖（A必须在B之前）
-- 识别资源依赖（同一人负责的任务）
-- 识别偏好依赖（推荐顺序）
-- 找出可并行的任务（标记[P]）
-- 绘制Mermaid依赖图
-
----
-
-### 工具3: 任务粒度检查表
-
-
-| 检查项  | 标准       | 如何修正         |
-| ---- | -------- | ------------ |
-| 估时   | 2h-2d    | 过大→拆分, 过小→合并 |
-| 交付物  | 单一明确     | 多个→拆分为多个Task |
-| 验收标准 | 3-5条具体标准 | 模糊→细化为可测试条件  |
-| 依赖   | < 5个依赖   | 过多→重新组织Phase |
-
-
----
-
-## Sprint 退出标准与集成验证任务
-
-### Sprint 退出标准
-
-> [!IMPORTANT]
-> **每个 Sprint/里程碑必须有明确的退出标准。**
->
-> 退出标准定义"什么算做完"，它不是模糊的"任务都打勾了"，而是**可演示、可验证的具体状态**。
-
-**Sprint 路线图格式**:
-
-```markdown
-| Sprint | 代号 | 核心任务 | 退出标准 | 预估 |
-|--------|------|---------|---------|------|
-| S1 | Hello World | 基础设施+数据 | headless 运行 2 国 5 回合 + 基本渲染可见 | 3-4d |
-| S2 | 功能成型 | 实体+交互 | 完整功能可演示 + HUD 显示资源 | 5-6d |
-```
-
-**退出标准要求**:
-
-- 必须是可客观验证的（可截图/录屏/日志证明）
-- 必须涵盖跨系统集成（而非单个组件）
-- 描述用户/开发者能观察到的行为，而非内部实现细节
-
-### 集成验证任务 (INT Task)
-
-每个 Sprint 末尾生成一个 **INT-S{N}** 任务，专门验证退出标准：
-
-```markdown
-- [ ] **INT-S{N}** [MILESTONE]: S{N} 集成验证 — {代号}
-  - **描述**: 验证 S{N} 退出标准
-  - **输入**: S{N} 所有任务的产出
-  - **输出**: 集成验证报告（通过/失败 + Bug 清单）
-  - **验收标准**:
-    - Given S{N} 所有任务已完成
-    - When 逐条执行退出标准中的检查
-    - Then 全部通过 → Sprint 完成; 有失败 → 记录 Bug
-  - **验证说明**: 按退出标准逐条执行，截图/录屏/日志确认
-  - **估时**: 2-4h
-  - **依赖**: S{N} 最后一个任务
-```
-
-INT 任务是该 Sprint 的"关门任务"。**未通过 INT 任务的 Sprint 不得标记为完成。**
-
----
-
-## 常见场景与模式
-
-### 场景1: 新功能开发
-
-**特征**: 实现一个新的User Story
-
-**拆分模式**:
-
-```
-Phase 1: 数据层 (Database)
-  - T3.1.1: 设计Schema
-  - T3.1.2: 创建Migration
-
-Phase 2: 业务层 (Backend)
-  - T2.2.1: 实现API端点
-  - T2.2.2: 单元测试
-
-Phase 3: 表现层 (Frontend)
-  - T1.3.1: 实现UI组件
-  - T1.3.2: 集成API
-
-Phase 4: 验证
-  - T99.1: E2E测试
-```
-
----
-
-### 场景2: 性能优化
-
-**特征**: 优化现有功能的性能
-
-**拆分模式**:
-
-```
-Phase 1: 分析 (Profiling)
-  - T1.1: 性能基准测试
-  - T1.2: 识别瓶颈
-
-Phase 2: 优化 (Optimization)
-  - T2.1: 添加缓存
-  - T2.2: 优化数据库查询
-
-Phase 3: 验证 (Validation)
-  - T3.1: 性能对比测试
-```
-
----
-
-### 场景3: Bug修复
-
-**特征**: 修复已知缺陷
-
-**拆分模式**:
-
-```
-Phase 1: 复现 (Reproduction)
-  - T1.1: 编写复现步骤
-  - T1.2: 创建失败的测试用例
-
-Phase 2: 修复 (Fix)
-  - T2.1: 实现修复
-  - T2.2: 测试用例通过
-
-Phase 3: 回归测试 (Regression)
-  - T3.1: 确保未引入新Bug
-```
-
----
-
-## 质量检查清单
-
-完成任务拆解后，使用此清单自检：
-
-### 结构完整性
-
-- 使用WBS三级层次（System → Phase → Task）
-- 每个System有清晰的Phase划分
-- 每个Task有完整的元数据
-
-### 任务质量
-
-- 每个Task估时 2h-2d
-- 每个Task有3-5条验收标准
-- 每个Task关联PRD需求 [REQ-XXX]
-- 每个Task描述清晰（"做什么"）
-
-### 依赖关系
-
-- 提供Mermaid依赖图
-- 标注逻辑依赖、资源依赖、偏好依赖
-- 无循环依赖
-- 识别可并行任务
-
-### 追溯链
-
-- 所有PRD需求映射到至少一个Task
-- 所有Task关联PRD需求或标注为[基础]
-- 跨系统集成任务已识别
-
-### User Story 覆盖
-
-- 每个 US-XXX 有足够的 tasks 覆盖其所有涉及系统
-- 每个 US 的 task 链能形成可独立验证的闭环
-- 高优先级 US (P0) 的 task 分布在靠前的 Sprint
-
----
-
-## 快速上手示例
-
-**任务**: 为"用户登录"功能拆解任务
-
-**Step 1: 确定涉及的系统**
-
-- Frontend System, Backend API System, Database System
-
-**Step 2: 按Phase组织**
-
-```
-Database System:
-  Phase 1: Foundation
-    - T3.1.1: 创建users表Schema
-
-Backend API System:
-  Phase 2: Core
-    - T2.2.1: 实现 POST /auth/login
-    - T2.2.2: 单元测试
-
-Frontend System:
-  Phase 2: Core
-    - T1.2.1: 实现LoginForm组件
-    - T1.2.2: 集成/auth/login API
-```
-
-**Step 3: 分析依赖**
-
-```
-T3.1.1 → T2.2.1 → T1.2.1 (逻辑依赖)
-```
-
-**Step 4: 定义验收标准**
-
-```
-T2.2.1验收:
-  - [ ] API返回JWT Token
-  - [ ] 单元测试通过
-  - [ ] Postman测试成功
-```
-
----
-
-**记住**: 好的任务拆解是平衡的艺术。  
-不要过度拆分（管理成本高），也不要过度聚合（风险不可控）。
-
-Happy Planning! 
+---
+
+name: task-planner
+description: 使用 WBS 将系统设计文档分解为执行主清单（05A_TASKS.md）与验证计划（05B_VERIFICATION_PLAN.md），支持依赖分析、验证追溯与证据定义。
+
+# Task Planner
+
+你是任务拆解与验证编排技能，目标是输出两份文档：
+
+- `.anws/v{N}/05A_TASKS.md`（执行主清单）
+- `.anws/v{N}/05B_VERIFICATION_PLAN.md`（验证计划）
+
+---
+
+## 快速流程
+
+1. 读取 `01_PRD.md`、`02_ARCHITECTURE_OVERVIEW.md`
+2. 读取 `03_ADR/` 与 `04_SYSTEM_DESIGN/`（如存在）
+3. 若 ADR 中存在测试策略/质量门禁，必须优先遵循，不得自行改重
+4. 提取公共契约（HTTP API / CLI / 配置 / 错误语义 / 数据结构等）
+5. 生成 WBS 任务（System → Phase → Task）到 `05A`
+6. 为每个任务生成验证锚点与证据要求到 `05B`
+
+---
+
+## 分轨职责
+
+### 05A_TASKS.md（执行主清单）
+
+- WBS 任务列表与依赖
+- Sprint 路线图
+- INT 里程碑任务
+- 进度 checkbox
+- User Story Overlay
+
+### 05B_VERIFICATION_PLAN.md（验证计划）
+
+- 验证分层策略
+- 风险类别覆盖规则
+- Task-by-Task 验证计划
+- Contract Coverage Overlay
+- Testing Coverage Overlay
+- Verification Traceability Matrix
+
+> [!IMPORTANT]
+> 上述三项为 05B 的硬性必选章节，不可删除：
+>
+> - Contract Coverage Overlay
+> - Testing Coverage Overlay
+> - Verification Traceability Matrix
+
+---
+
+## 任务格式（05A）
+
+```markdown
+- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务标题
+  - **描述**: 做什么（不是怎么做）
+  - **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
+  - **输出**: 产出的文件/组件/接口
+  - **契约承接**: 本任务实现或验证的公共契约；如无则写"无"
+  - **参考**: ADR-XXX 或 System Design 章节（如有）
+  - **验收标准**:
+    - Given [前置条件]
+    - When [执行动作]
+    - Then [预期结果]
+    - （仅纯技术性基础任务允许使用清晰 Done When 列表）
+  - **验证类型**: 单元测试 | API接口功能测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
+  - **验证摘要**: 验证目标与边界（不展开完整用例）
+  - **验证引用**: `05B_VERIFICATION_PLAN.md#t-x-y-z`
+  - **证据产出**: `tests/...`, `reports/...`, `screenshots/...`, `logs/...`
+  - **估时**: Xh
+  - **依赖**: T{A}.{B}.{C}
+  - **优先级**: P0 | P1 | P2
+```
+
+---
+
+## 验证格式（05B）
+
+### Task-by-Task 条目
+
+```markdown
+### T{X}.{Y}.{Z}
+- 关联需求:
+- 关联契约:
+- 风险类别:
+- 单元测试覆盖:
+- API接口功能测试覆盖:
+- 集成/E2E/冒烟覆盖:
+- 前置数据:
+- 断言:
+- 证据:
+```
+
+### 追溯矩阵
+
+```markdown
+## Verification Traceability Matrix
+| REQ/Contract | Task | Verification | Test Material | Evidence | Status |
+|---|---|---|---|---|---|
+```
+
+---
+
+## 验证类型选择逻辑
+
+按"最轻但足够"原则：
+
+1. 局部逻辑 / 纯算法 / 状态转换 / 异常处理 → 单元测试
+2. HTTP API / CLI API / 权限边界 / 错误语义 / 数据变更接口 → API接口功能测试
+3. 跨模块 / 数据库 / 多服务协作 → 集成测试
+4. 直接面向终端用户的关键路径 → E2E测试 或 手动验证
+5. Sprint 退出关口 / 里程碑 gate → 冒烟测试（优先绑定 `INT-S{N}`）
+6. 修改可能影响已完成关键能力 → 回归测试
+7. 配置/脚手架/基础设施 → 编译检查 / Lint检查 / 手动验证
+
+**选择细则**：
+
+- 不要因为任务"看起来重要"就默认选择 E2E测试
+- 任务暴露或修改对外 API → 必须明确正常请求/代表性异常请求/错误语义如何验证
+- 涉及数据变更接口 → 验证说明必须包含 before/after 断言
+- 涉及鉴权/角色/权限边界 → 验证说明必须包含权限不足场景
+
+### E2E 执行边界（强约束）
+
+- `task-planner` 只负责在 `05A_TASKS.md` / `05B_VERIFICATION_PLAN.md` 记录 E2E 触发设想、覆盖范围和证据预期
+- 规划阶段不得调用或执行 `e2e-testing-guide`
+- 实际 E2E 指南生成与实机验证由 `/forge` 根据任务触发执行
+
+---
+
+## 测试标准（硬约束）
+
+> [!IMPORTANT]
+> **项目验收必须同时包含单元测试与 API 接口功能测试。**
+
+### 单元测试内容要求
+
+- **核心业务计算逻辑**: 正常输入、边界输入、非法输入，验证处理结果符合预期
+- **关键状态转换逻辑**: 创建、执行、失败、重试等状态分别规划用例
+- **异常处理逻辑**: 构造空值、超范围参数、非法状态，验证错误信息正确且系统稳定
+
+### API接口功能测试内容要求
+
+- **核心业务接口**: 正常请求参数下返回正确响应
+- **异常请求场景**: 参数缺失、参数格式错误、权限不足，验证错误码和错误信息符合接口设计规范
+- **数据变更接口**: 验证调用前后系统状态或数据结果正确（before/after 断言）
+
+### 反测试膨胀原则
+
+- 目标是**风险类别闭合**，不是测试数量最大化
+- 优先等价类划分、边界值、代表性错误样本、参数化测试或表驱动测试
+- 禁止全组合笛卡尔积枚举
+- 单元测试负责细粒度逻辑，API接口功能测试负责对外契约，E2E 只保留关键用户链路
+
+---
+
+## 契约覆盖规则
+
+> [!IMPORTANT]
+> **若任务产出包含或修改公共契约，必须为其分配明确验证承接。**
+
+公共契约至少包括：操作契约、跨系统接口、HTTP API、CLI 命令/参数语义、配置结构、文件格式、错误语义、持久化结构。
+
+规则：
+
+- 每个公共契约至少有一个实现任务承接
+- 每个高风险公共契约至少有一个验证承接点
+- 不得仅以"实现任务有代码变更"视为契约闭合
+- 基础规则层/低依赖纯逻辑 → 优先单元测试
+- HTTP API / CLI API / 对外接口 → 优先 API接口功能测试
+- 错误码/错误信息/权限不足语义/数据变更前后状态 → 属于可观察契约，不得遗漏
+
+---
+
+## WBS 方法
+
+### 三级层次
+
+```
+Level 1: System（系统级）  ← 来自 Architecture Overview 的系统清单
+Level 2: Phase（阶段级）   ← Foundation / Core / Integration / Polish
+Level 3: Task（任务级）    ← 2h–2d 粒度的具体任务
+```
+
+### Sprint 路线图格式
+
+```markdown
+## Sprint 路线图
+
+| Sprint | 代号 | 核心任务 | 退出标准 | 预估 |
+|--------|------|---------|---------|------|
+| S1     | Hello World | 基础设施 + 核心数据 | headless 运行通过 + 基本渲染可见 | 3-4d |
+```
+
+退出标准要求：
+
+- 可客观验证（截图/录屏/日志）
+- 描述用户或开发者能观察到的行为
+- 涵盖跨系统集成
+
+### 集成验证任务 (INT-S{N})
+
+```markdown
+- [ ] **INT-S{N}** [MILESTONE]: S{N} 集成验证 — {代号}
+  - **描述**: 验证 S{N} 退出标准
+  - **输入**: S{N} 所有任务的产出
+  - **输出**: 集成验证报告（通过/失败 + Bug 清单）
+  - **验收标准**:
+    - Given S{N} 所有任务已完成
+    - When 逐条执行退出标准中的检查
+    - Then 全部通过 → Sprint 完成; 有失败 → 记录 Bug
+  - **验证说明**: 按退出标准逐条执行，截图/录屏/日志确认
+  - **估时**: 2-4h
+  - **依赖**: S{N} 最后一个任务
+```
+
+INT 任务是该 Sprint 的"关门任务"。**未通过 INT 任务的 Sprint 不得标记为完成。**
+
+---
+
+## 任务质量守则
+
+### 粒度
+
+- 单个 Task 优先落在 2h–2d；超过 2d 应继续拆分
+- 太小（< 2h）考虑合并
+
+### 输入/输出追溯
+
+> [!IMPORTANT]
+> **任务间的输入/输出必须对齐。**
+>
+> 如果 Task B 依赖 Task A，则 B 的「输入」必须明确引用 A 的「输出」的具体产物（文件路径、接口名、数据格式）。
+
+### 验收标准
+
+- 默认使用 Given / When / Then
+- 仅纯技术性基础任务（配置、脚手架）允许清晰 Done When 列表
+
+---
+
+## 输出质量检查
+
+- `05A` 与 `05B` 已同时生成
+- 每个 05A 任务都包含 `验证引用` 与 `证据产出`
+- `05B` 含 Task-by-Task 计划与追溯矩阵
+- User Story Overlay 在 `05A`
+- Contract Coverage Overlay、Testing Coverage Overlay、Verification Traceability Matrix 在 `05B`
+- 冒烟测试优先绑定 `INT-S{N}`，未扩散到普通开发任务
+- 未出现 E2E 测试滥用现象
+