---
name: splitter
description: 将 architect 的设计文档拆解为任务卡，若项目有 .blueprint/ 则写入蓝图文件。Use after /architect for L-complexity tasks.
allowed-tools: Read, Edit, Write, Glob
---

# 任务拆解

将架构设计拆解为可独立执行的任务卡。

## 前提
当前对话中应已有 `/architect` 输出的设计文档，包含受影响文件和拆解建议。

## 步骤

### 1. 确认任务管理方式
- 若项目存在 `.blueprint/manifest.yaml` → 写入蓝图文件
- 若不存在 → 以 Markdown 列表输出到对话，由用户决定放哪里

### 2. 拆解原则

**粒度控制**
- 每张卡 complexity 必须是 `S` 或 `M`，不允许 L
- S：单文件改动，逻辑简单，独立可完成
- M：跨 2-3 个文件，有业务逻辑，但边界清晰
- 拆出来还是 L → 继续细拆

**依赖顺序**
- 数据层（schema / model）→ 后端接口 → 前端封装 → UI 组件
- 有依赖的卡填写 `depends` 字段

**可派发标准（每张卡必须满足）**
- `files`：明确列出涉及文件的相对路径
- `acceptance`：**可执行验证路径**，格式：`[载体] 调用/运行什么(参数) → 断言什么`
  - 载体从 architect 的「验证路径」声明继承，就近选择：Tauri command / HTTP API / CLI / Playwright
  - 断言要具体（检查字段值、返回码、文件存在、数量 > 0），不写模糊的"功能正常"
  - 示例：`[Tauri command] apply_onboarding_pack(project_id) → 返回 written≥1，磁盘上文件存在`
  - 示例：`[HTTP API] POST /api/projects → 201，body.id 非空`
  - 示例：`[cargo test] cargo test parse_conventional → 6 个 case 全通过`
- `complexity`：S 或 M

### 3a. 写入蓝图（有 .blueprint/ 时）

读取 `.blueprint/modules/<id>.md`，在末尾追加任务卡：

```markdown
### 📋 <任务标题>
- status: todo
- complexity: S|M
- files: src/path/to/file.tsx, src-tauri/src/commands/xxx.rs
- depends: <依赖模块id>（可选）
- acceptance: "[载体] 调用什么(参数) → 断言什么"
```

然后更新 `manifest.yaml`：status → `planned`，`updated` 改为今天日期。

### 3b. 输出到对话（无 .blueprint/ 时）

```markdown
## 任务拆解：<功能名>

### 📋 <卡名>（S）
- files: ...
- acceptance: "[载体] 调用什么(参数) → 断言什么"

### 📋 <卡名>（M）
- files: ...
- acceptance: "[载体] 调用什么(参数) → 断言什么"
- depends: 上一张卡
```

### 4. 输出拆解摘要

```
共 N 张任务卡，执行顺序：
1. 📋 <卡名>（S）— <一句话说明>
2. 📋 <卡名>（M）— <一句话说明>
3. 📋 <卡名>（M）— <一句话说明，depends: 卡2>
```

## 质量检查
写完后逐张确认：
- [ ] 每张卡有 `files`
- [ ] 每张卡有 `acceptance`
- [ ] complexity 全部是 S 或 M
- [ ] 有依赖的卡填了 `depends`
- [ ] 任务卡按执行顺序排列