# Phase TS-1：业务任务模型扩展

日期：2026-04-08
状态：待实施

---

## 1. 阶段目标

补齐业务级 Task / SubTask / 分配 / 派发字段，为 Today Status、Schedule Center、Chat 创建、Commander 派发提供统一的数据主模型。

本阶段重点是“把业务模型补齐”，而不是直接接 commander runtime。

---

## 2. 详细任务

### 2.1 扩展 Task 模型

**文件**：
- `backend/app/models/task.py`
- `backend/app/schemas/task.py`

建议新增字段：
- `source`
- `conversation_id`
- `quadrant`
- `assignee_type`
- `assignee_id`
- `dispatch_status`
- `dispatch_run_id`
- `result_summary`
- `started_at`
- `last_synced_at`

### 2.2 新增业务级 TaskSubTask

**文件**：
- 新增 TaskSubTask 模型文件或在任务模型模块中补充
- `backend/app/schemas/task.py`

建议字段：
- `task_id`
- `title`
- `description`
- `status`
- `order_index`
- `assignee_type`
- `assignee_id`
- `dispatch_status`
- `dispatch_run_id`
- `completed_at`

### 2.3 扩展 TaskHistory 语义

建议新增 action：
- `created_from_chat`
- `assigned`
- `subtask_created`
- `subtask_reordered`
- `dispatched_to_commander`
- `dispatch_status_changed`

### 2.4 设计 migration

需要新增 migration，确保：
- 旧 task 可兼容新字段
- 新 subtasks 表可按 task_id 关联
- 必要索引可支撑按日期 / 象限 / assignee / dispatch 状态查询

---

## 3. 设计原则

1. **业务 task 与 runtime task 分层**
   - 不能直接把 runtime 的 `owner_agent_id / parent_task_id` 作为业务主模型。
2. **SubTask 必须是业务实体**
   - 不能继续停留在前端本地数组。
3. **先支持显式字段，再做自动推导**
   - `quadrant`、`assignee_type` 等优先用显式字段，不做复杂推断。

---

## 4. 核心文件清单

| 文件 | 操作 | 说明 |
|------|------|------|
| `backend/app/models/task.py` | 修改 | 扩展 Task 字段 |
| `backend/app/schemas/task.py` | 修改 | 扩展 TaskCreate/TaskUpdate/TaskOut/SubTask schema |
| migration 文件 | 新增 | 数据库结构迁移 |

---

## 5. 验收标准

- [ ] Task 可表达来源、象限、分配对象、派发状态
- [ ] 有独立的业务级 SubTask 模型
- [ ] TaskHistory 能记录关键业务动作
- [ ] migration 方案清晰且可兼容旧数据

---

## 6. 依赖关系

```text
本阶段 → Phase TS-2（API）
       → Phase TS-4（详情编辑器）
       → Phase TS-5（Commander 派发）
```

本阶段是后续所有真实任务操作的基础。