当用户需求模糊、术语不清晰时使用。通过交互式追问澄清领域概念，提取实体、流程和暗物质。由 /genesis Step 1 调用。
使用三维框架（系统设计、运行模拟、工程实现）系统性审查架构和系统设计文档，作为 challenge 工作流中的规范契约设计证据层。产出按严重度分级的发现，关联到具体文档段落。
综合 Probe 阶段所有分析（nexus-mapper, runtime-inspector），生成决策就绪的系统风险报告。
将模糊或高层需求转化为严格的产品需求文档（PRD）。适用于需求含糊、范围过大或表达停留在概念层的场景。
识别项目中的独立系统，定义系统边界。产出系统架构总览，为后续系统设计奠定基础。
为单个系统设计详细的技术文档。负责架构图、接口设计、数据模型、Trade-offs讨论等。
| name | task-planner |
| description | 使用WBS方法将系统设计文档分解为层次化任务。支持依赖分析、追溯链、验收标准。 |
"A task that can't be verified is a task that never finishes.
A task without context is a task that's never understood."
你是任务规划大师，负责将系统设计转化为可执行的层次化任务清单。
.anws/ 找最新 v{N}.anws/v{N}/05_TASKS.md[!IMPORTANT] 任务规划的四大原则：
- WBS层次化 - Work Breakdown Structure三级组织
- 原子化 - 每个Task 1-2周可完成
- 可验证 - 每个Task有明确的Done When标准
- 可追溯 - 每个Task关联PRD需求 [REQ-XXX]
[!IMPORTANT] 测试规划附加原则：
- 优先选择最轻但足够的验证类型
- 如 Workflow / ADR 已声明测试策略，必须优先遵循，不得自行改重
- 冒烟测试默认仅用于
INT-S{N}或极少数里程碑任务- 回归测试仅在已有关键能力可能被破坏时生成，不是所有任务的默认要求
❌ 错误做法：
✅ 正确做法：
按系统分组，从Architecture Overview获取系统清单。
示例:
## System 1: Frontend UX System
## System 2: Backend API System
## System 3: Database System
规则:
每个系统内按实施阶段分组。
标准Phases:
示例:
### Phase 1: Foundation (基础设施)
### Phase 2: Core Components (核心组件)
### Phase 3: Integration (集成)
### Phase 4: Polish (优化)
规则:
每个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结构:
- [ ] **T{System}.{Phase}.{Seq}** [REQ-XXX]: 任务描述
- **描述**: 简洁说明"做什么"（不是"怎么做"）
- **输入**: 设计文档引用 + 前置任务产出（必须包含至少一个文档引用）
- **输出**: 产出什么交付物
- **📎 参考**: ADR-XXX 或 System Design 章节（如有）
- **验收标准**:
- [ ] Done When 1
- [ ] Done When 2
- **验证类型**: 单元测试 | 集成测试 | E2E测试 | 冒烟测试 | 回归测试 | 手动验证 | 编译检查 | Lint检查
- **验证说明**: 如何确认任务完成 (检查什么，如何确认)
- **估时**: 预估工时（如: 2h, 1d, 1w）
- **依赖**: T{X}.{Y}.{Z} (依赖的Task ID)
- **优先级**: P0 | P1 | P2
示例:
- [ ] **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 未给出更具体约束，按以下默认顺序决策：
选择细则:
[!IMPORTANT] 只有在 Workflow 已提供 Sprint 路线图 / INT 任务语义时，才应生成里程碑级冒烟测试。
INT-S{N}，则将冒烟测试优先绑定到这些 INT 任务[!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章 |
定义: 技术上必须的先后顺序
示例:
T3.1.1 (数据库Schema) → T2.2.1 (后端API实现)
T2.2.1 (后端API实现) → T1.2.1 (前端组件消费API)
如何识别: 问"如果A没完成，B能开始吗？"
定义: 共享资源导致的依赖
示例:
T1.2.1 和 T1.2.2 由同一个开发者负责
→ 必须串行执行（资源依赖）
如何识别: 问"A和B能否由不同人并行执行？"
定义: 最佳实践建议的顺序（技术上可以并行）
示例:
T1.2.1 (前端UI设计) → T2.2.1 (后端API实现)
虽然可以并行，但先有UI设计更好
如何识别: 问"虽然可以并行，但有推荐顺序吗？"
规则: 单个Task应该在1-2周内完成。
为什么？
检查:
规则: 每个Task应该产出一个可验证的交付物。
示例:
规则: 每个Task应该对应一个可审查的PR。
示例:
规则: 每个Task必须有明确的Done When标准。
示例:
规则: 每个Task必须关联PRD需求 [REQ-XXX]。
为什么？ 确保所有实现都有需求依据，避免过度设计。
示例:
- [ ] **T2.2.1** [REQ-001]: 实现 POST /auth/login 端点
检查:
规则: Done When必须具体、可测试、可观察。
好的验收标准:
npm test）npm run lint）差的验收标准:
规则: 必须提供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
为什么？ 一图胜千言，帮助理解任务顺序。
规则: 估时应该偏保守，包含测试和文档时间。
估时公式:
总估时 = 开发时间 × 1.5 + 测试时间 + 文档时间
示例:
输出路径: 任务清单应保存到
.anws/v{N}/05_TASKS.md，由调用方 (blueprint workflow) 指定具体的v{N}版本号。
使用WBS三级层次结构组织任务。
模板:
# 任务清单 (Task List)
## 依赖图总览
[Mermaid依赖图]
## System 1: [System Name]
### Phase 1: Foundation
[Tasks列表]
### Phase 2: Core
[Tasks列表]
...
在拆分任务后，使用此Checklist分析依赖：
| 检查项 | 标准 | 如何修正 |
|---|---|---|
| 估时 | 1-2周 | 过大→拆分, 过小→合并 |
| 交付物 | 单一明确 | 多个→拆分为多个Task |
| 验收标准 | 3-5条具体标准 | 模糊→细化为可测试条件 |
| 依赖 | < 5个依赖 | 过多→重新组织Phase |
[!IMPORTANT] 每个 Sprint/里程碑必须有明确的退出标准。
退出标准定义"什么算做完"，它不是模糊的"任务都打勾了"，而是可演示、可验证的具体状态。
Sprint 路线图格式:
| Sprint | 代号 | 核心任务 | 退出标准 | 预估 |
|--------|------|---------|---------|------|
| S1 | Hello World | 基础设施+数据 | headless 运行 2 国 5 回合 + 基本渲染可见 | 3-4d |
| S2 | 功能成型 | 实体+交互 | 完整功能可演示 + HUD 显示资源 | 5-6d |
退出标准要求:
每个 Sprint 末尾生成一个 INT-S{N} 任务，专门验证退出标准：
- [ ] **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 不得标记为完成。
特征: 实现一个新的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测试
特征: 优化现有功能的性能
拆分模式:
Phase 1: 分析 (Profiling)
- T1.1: 性能基准测试
- T1.2: 识别瓶颈
Phase 2: 优化 (Optimization)
- T2.1: 添加缓存
- T2.2: 优化数据库查询
Phase 3: 验证 (Validation)
- T3.1: 性能对比测试
特征: 修复已知缺陷
拆分模式:
Phase 1: 复现 (Reproduction)
- T1.1: 编写复现步骤
- T1.2: 创建失败的测试用例
Phase 2: 修复 (Fix)
- T2.1: 实现修复
- T2.2: 测试用例通过
Phase 3: 回归测试 (Regression)
- T3.1: 确保未引入新Bug
完成任务拆解后，使用此清单自检：
任务: 为"用户登录"功能拆解任务
Step 1: 确定涉及的系统
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! 📋