---

description: "功能实现的任务列表模板"
---

# 任务清单: [FEATURE NAME]

**输入**: 来自 `/specs/[###-feature-name]/` 的设计文档
**前提条件**: plan.md（必需），spec.md（用户故事必需），research.md，data-model.md，contracts/

**⚠️ 重要提示**: 根据 AgentSwitch 项目宪章，本文档必须使用中文编写。

**测试**: 以下示例包含测试任务。测试是可选的 - 仅在功能规格中明确要求时包含。

**组织方式**: 任务按用户故事分组，以实现每个故事的独立实现和测试。

## 格式: `[ID] [P?] [Story] 描述`

- **[P]**: 可并行运行（不同文件，无依赖）
- **[Story]**: 此任务属于哪个用户故事（例如 US1, US2, US3）
- 在描述中包含确切的文件路径

## 路径约定

- **单项目**: 仓库根目录的 `src/`, `tests/`
- **Web 应用**: `backend/src/`, `frontend/src/`
- **移动端**: `api/src/`, `ios/src/` 或 `android/src/`
- 以下显示的路径假设为单项目 - 根据 plan.md 结构调整

<!--
  ============================================================================
  重要提示: 以下任务仅为说明目的的示例任务。

  /speckit.tasks 命令 MUST 根据以下内容替换为实际任务:
  - spec.md 中的用户故事（及其优先级 P1, P2, P3...）
  - plan.md 中的功能需求
  - data-model.md 中的实体
  - contracts/ 中的端点

  任务 MUST 按用户故事组织，以便每个故事可以:
  - 独立实现
  - 独立测试
  - 作为 MVP 增量交付

  不要在生成的 tasks.md 文件中保留这些示例任务。
  ============================================================================
-->

## 阶段 1: 设置（共享基础设施）

**目的**: 项目初始化和基本结构

- [ ] T001 根据实现计划创建项目结构
- [ ] T002 初始化 Rust 项目，配置 Cargo.toml（edition = "2024"）
- [ ] T003 [P] 配置 linting 和格式化工具（cargo fmt, cargo clippy）

---

## 阶段 2: 基础设施（阻塞前提条件）

**目的**: 在任何用户故事实现前必须完成的核心基础设施

**⚠️ 关键**: 在此阶段完成前，不能开始任何用户故事工作

基础任务示例（根据项目调整）:

- [ ] T004 创建基础数据模型（ModelConfig, AgentAdapter trait）
- [ ] T005 [P] 实现配置文件存储模块（~/.agentswitch/config.toml）
- [ ] T006 [P] 实现 API Key 安全存储（加密或系统密钥链）
- [ ] T007 设置错误处理基础设施（anyhow + 自定义错误类型）
- [ ] T008 设置日志基础设施
- [ ] T009 创建 CLI 命令框架（clap）

**检查点**: 基础设施就绪 - 用户故事实现现在可以并行开始

---

## 阶段 3: 用户故事 1 - [标题] (优先级: P1) 🎯 MVP

**目标**: [此故事交付内容的简短描述]

**独立测试**: [如何验证此故事单独工作]

### 用户故事 1 的测试（可选 - 仅在要求测试时）⚠️

> **注意: 先编写这些测试，确保在实现前失败**

- [ ] T010 [P] [US1] [功能/端点] 的单元测试在 tests/unit/test_[name].rs
- [ ] T011 [P] [US1] [用户旅程] 的集成测试在 tests/integration/test_[name].rs

### 用户故事 1 的实现

- [ ] T012 [P] [US1] 在 src/models/[entity1].rs 创建 [实体1] 模型
- [ ] T013 [P] [US1] 在 src/models/[entity2].rs 创建 [实体2] 模型
- [ ] T014 [US1] 在 src/services/[service].rs 实现 [服务]（依赖 T012, T013）
- [ ] T015 [US1] 在 src/[location]/[file].rs 实现 [端点/功能]
- [ ] T016 [US1] 添加验证和错误处理
- [ ] T017 [US1] 为用户故事 1 的操作添加日志

**检查点**: 此时，用户故事 1 应该完全可功能并独立可测试

---

## 阶段 4: 用户故事 2 - [标题] (优先级: P2)

**目标**: [此故事交付内容的简短描述]

**独立测试**: [如何验证此故事单独工作]

### 用户故事 2 的测试（可选 - 仅在要求测试时）⚠️

- [ ] T018 [P] [US2] [功能/端点] 的单元测试在 tests/unit/test_[name].rs
- [ ] T019 [P] [US2] [用户旅程] 的集成测试在 tests/integration/test_[name].rs

### 用户故事 2 的实现

- [ ] T020 [P] [US2] 在 src/models/[entity].rs 创建 [实体] 模型
- [ ] T021 [US2] 在 src/services/[service].rs 实现 [服务]
- [ ] T022 [US2] 在 src/[location]/[file].rs 实现 [端点/功能]
- [ ] T023 [US2] 与用户故事 1 的组件集成（如果需要）

**检查点**: 此时，用户故事 1 和 2 都应该独立工作

---

## 阶段 5: 用户故事 3 - [标题] (优先级: P3)

**目标**: [此故事交付内容的简短描述]

**独立测试**: [如何验证此故事单独工作]

### 用户故事 3 的测试（可选 - 仅在要求测试时）⚠️

- [ ] T024 [P] [US3] [功能/端点] 的单元测试在 tests/unit/test_[name].rs
- [ ] T025 [P] [US3] [用户旅程] 的集成测试在 tests/integration/test_[name].rs

### 用户故事 3 的实现

- [ ] T026 [P] [US3] 在 src/models/[entity].rs 创建 [实体] 模型
- [ ] T027 [US3] 在 src/services/[service].rs 实现 [服务]
- [ ] T028 [US3] 在 src/[location]/[file].rs 实现 [端点/功能]

**检查点**: 所有用户故事现在应该独立可功能

---

[根据需要添加更多用户故事阶段，遵循相同模式]

---

## 阶段 N: 完善与跨领域关注点

**目的**: 影响多个用户故事的改进

- [ ] TXXX [P] 文档更新（使用中文）
- [ ] TXXX 代码清理和重构
- [ ] TXXX 所有故事的性能优化
- [ ] TXXX [P] 额外的单元测试（如果要求）在 tests/unit/
- [ ] TXXX 安全加固（API Key 加密验证）
- [ ] TXXX 运行 quickstart.md 验证
- [ ] TXXX 执行完整集成测试套件

---

## 依赖与执行顺序

### 阶段依赖

- **设置（阶段 1）**: 无依赖 - 可立即开始
- **基础设施（阶段 2）**: 依赖设置完成 - 阻塞所有用户故事
- **用户故事（阶段 3+）**: 都依赖基础设施阶段完成
  - 用户故事然后可以并行进行（如果有人力）
  - 或按优先级顺序进行（P1 → P2 → P3）
- **完善（最后阶段）**: 依赖所有期望的用户故事完成

### 用户故事依赖

- **用户故事 1 (P1)**: 在基础设施（阶段 2）完成后可开始 - 无其他故事依赖
- **用户故事 2 (P2)**: 在基础设施（阶段 2）完成后可开始 - 可能与 US1 集成但应独立可测试
- **用户故事 3 (P3)**: 在基础设施（阶段 2）完成后可开始 - 可能与 US1/US2 集成但应独立可测试

### 每个用户故事内

- 测试（如果包含）MUST 在实现前编写并失败
- 模型在服务之前
- 服务在端点之前
- 核心实现在集成之前
- 故事完成后再进入下一个优先级

### 并行机会

- 所有标记 [P] 的设置任务可并行运行
- 所有标记 [P] 的基础设施任务可并行运行（在阶段 2 内）
- 基础设施阶段完成后，所有用户故事可并行开始（如果团队容量允许）
- 用户故事的所有标记 [P] 的测试可并行运行
- 故事内标记 [P] 的模型可并行运行
- 不同用户故事可由不同团队成员并行工作

---

## 并行示例: 用户故事 1

```bash
# 一起启动用户故事 1 的所有测试（如果要求测试）:
任务: "[功能/端点] 的单元测试在 tests/unit/test_[name].rs"
任务: "[用户旅程] 的集成测试在 tests/integration/test_[name].rs"

# 一起启动用户故事 1 的所有模型:
任务: "在 src/models/[entity1].rs 创建 [实体1] 模型"
任务: "在 src/models/[entity2].rs 创建 [实体2] 模型"
```

---

## 实现策略

### MVP 优先（仅用户故事 1）

1. 完成阶段 1: 设置
2. 完成阶段 2: 基础设施（关键 - 阻塞所有故事）
3. 完成阶段 3: 用户故事 1
4. **停止并验证**: 独立测试用户故事 1
5. 如果就绪则部署/演示

### 增量交付

1. 完成设置 + 基础设施 → 基础就绪
2. 添加用户故事 1 → 独立测试 → 部署/演示（MVP！）
3. 添加用户故事 2 → 独立测试 → 部署/演示
4. 添加用户故事 3 → 独立测试 → 部署/演示
5. 每个故事增加价值而不破坏之前的故事

### 并行团队策略

有多个开发人员时:

1. 团队一起完成设置 + 基础设施
2. 基础设施完成后:
   - 开发人员 A: 用户故事 1
   - 开发人员 B: 用户故事 2
   - 开发人员 C: 用户故事 3
3. 故事独立完成和集成

---

## 注意事项

- [P] 任务 = 不同文件，无依赖
- [Story] 标签将任务映射到特定用户故事以实现可追溯性
- 每个用户故事应该可独立完成和测试
- 实现前验证测试失败
- 每个任务或逻辑组后提交
- 在任何检查点停止以独立验证故事
- 避免: 模糊任务、相同文件冲突、破坏独立性的跨故事依赖
