# 任务生成规则

## 核心原则

### 1. 自然语言描述
关注能力和结果，而非代码结构。

**描述**：
- 要实现的功能
- 业务逻辑和行为
- 功能和能力
- 领域语言和概念
- 数据关系和工作流

**避免**：
- 文件路径和目录结构
- 函数/方法名称和签名
- 类型定义和接口
- 类名和API协议
- 特定数据结构

**理由**：实现细节（文件、方法、类型）在design.md中定义。任务描述要完成的功能性工作。

### 2. 任务集成和进展

**每个任务必须**：
- 基于先前的输出（无孤立代码）
- 连接到整体系统（无悬空功能）
- 逐步进展（无大的复杂度跳跃）
- 在序列中尽早验证核心功能
- 尊重design.md中定义的架构边界（架构模式和边界图）
- 遵循design.md中记录的接口协议
- 谨慎使用主要任务摘要——如果工作完全由子任务捕获，则省略详细要点。

**以集成任务结束**，将所有内容连接在一起。

### 3. 灵活的任务规模

**指南**：
- **主要任务**：根据逻辑需要尽可能多的子任务（按内聚性分组）
- **子任务**：每个1-3小时，每个子任务3-10个细节
- 在过于细粒度和过于宽泛之间平衡

**不要强制任意数字** - 让逻辑分组决定结构。

### 4. 需求映射

**在每个任务详细章节末尾**：
- `_Requirements: X.X, Y.Y_` 仅列出**数字需求ID**（逗号分隔）。永远不要附加描述性文本、括号、翻译或自由格式标签。
- 对于横切需求，列出每个相关的需求ID。所有需求必须在requirements.md中具有数字ID。如果缺少ID，停止并在生成任务之前更正requirements.md。
- 在有用时引用design.md中的组件/接口（例如，`_Contracts: AuthService API`）

### 5. 仅代码焦点

**仅包含**：
- 编码任务（实现）
- 测试任务（单元、集成、E2E）
- 技术设置任务（基础设施、配置）

**排除**：
- 部署任务
- 文档任务
- 用户测试
- 营销/业务活动

### 可选测试覆盖任务

- 当设计已经保证功能覆盖且优先考虑快速MVP交付时，使用 `- [ ]*` 复选框形式将纯测试导向的后续工作（例如，基线渲染/单元测试）标记为**可选**。
- 仅当子任务在其详细要点中直接引用requirements.md中的验收标准时，才应用可选标记。
- 永远不要将实现工作或集成关键验证标记为可选——将 `*` 保留用于可以在MVP后重新审视的辅助/可延迟测试覆盖。

## 任务层次规则

### 最多2级
- **级别1**：主要任务（1, 2, 3, 4...）
- **级别2**：子任务（1.1, 1.2, 2.1, 2.2...）
- **无更深嵌套**（无1.1.1）
- 如果主要任务仅包含单个可操作项，则折叠结构并将子任务提升到主要级别（例如，将 `1.1` 替换为 `1.`）。
- 当主要任务纯粹作为容器存在时，保持复选框描述简洁，避免重复详细要点——将具体内容保留给其子任务。

### 顺序编号
- 主要任务必须递增：1, 2, 3, 4, 5...
- 子任务按主要任务重置：1.1, 1.2，然后2.1, 2.2...
- 永远不要重复主要任务编号

### 并行分析（默认）
- 除非明确禁用（例如 `--sequential` 标志），否则假设并行分析已启用。
- 当**所有**条件成立时，识别可以并发运行的任务：
  - 对其他待处理任务无数据依赖
  - 无共享文件或资源争用
  - 无来自另一个任务的先决条件审查/批准
- 验证识别的并行任务在架构模式和边界图中定义的单独边界内运行。
- 确认design.md中的API/事件协议不会以导致冲突的方式重叠。
- 在每个可并行任务的任务编号后立即附加 `(P)`：
  - 示例：`- [ ] 2.1 (P) Build background worker`
  - 在适当时应用于主要任务和子任务。
- 如果请求顺序模式，完全省略 `(P)` 标记。
- 逻辑上分组并行任务（尽可能使用相同的父级），并在详细要点中突出显示任何排序注意事项。
- 明确指出阻止 `(P)` 的依赖关系，即使任务看起来相似。

### Checkbox Format
```markdown
- [ ] 1. Major task description
- [ ] 1.1 Sub-task description
  - Detail item 1
  - Detail item 2
  - _Requirements: X.X_

- [ ] 1.2 Sub-task description
  - Detail items...
  - _Requirements: Y.Y_

- [ ] 1.3 Sub-task description
  - Detail items...
  - _Requirements: Z.Z, W.W_

- [ ] 2. Next major task (NOT 1 again!)
- [ ] 2.1 Sub-task...
```

## 需求覆盖

**强制检查**：
- requirements.md中的所有需求必须被覆盖
- 将每个需求ID与任务映射进行交叉引用
- 如果发现差距：返回到需求或设计阶段
- 不应有任何需求没有对应的任务

使用 `N.M` 样式的数字需求ID，其中 `N` 是requirements.md中的顶级需求编号（例如，Requirement 1 → 1.1, 1.2；Requirement 2 → 2.1, 2.2），`M` 是该需求组内的本地索引。

记录任何有意延迟的需求及其理由。
