# 任务执行能力与推进能力分析

> **日期**: 2026-06-16
> **范围**: 任务实体在 DevFlow 系统中的定位、执行链路、推进能力全景分析
> **关联文档**: `任务推进构想-2026-06-14.md` / `业务系统设计-2026-06-12.md` / `AI对话引擎-2026-06-14.md` / `DAG引擎详解-2026-06-14.md` / `任务模块问题分析-2026-06-16.md`

---

## 〇、核对结论速览（2026-06-16 · Explore 代理并行取证）

> 本报告系架构分析，含密集代码事实断言。经 2 个代理逐项取证，12 项断言中 **10 真 / 1 部分真 / 1 假（重大）**。核心论点（任务能存不能推进 / nodes 未接入 / 无回调）成立，但**一处工具缺失论据错误**（见下方纠正）。

### 真伪矩阵

| # | 断言 | 核实 | 证据 |
|---|------|------|------|
| 1 | workflow.rs task_id 恒 None | ✅真 | `workflow.rs:56`，全局无写入点 |
| 2 | workflow_def_id 从未写入 | ✅真 | `task.rs:73` None，crud 有 UPDATE 语句但无调用 |
| 3 | AI 缺 update_task / run_command | ❌**假** | `update_task`(tool_registry.rs:348) + `run_command`(:468) **均存在**，仅缺 `advance_task` |
| 4 | df-task crate 已删除 | ✅真 | `ARCHITECTURE.md:89-90`，crates/ 无 df-task |
| 5 | DAG 完成无任务回调 | ✅真 | `executor.rs:169-172` 仅 emit WorkflowCompleted，无监听推进 task |
| 6 | 任务无独立业务层 | ✅真 | `task.rs` 直连 Repository，无状态机/推进逻辑 |
| 7 | AiNode 未接入任务推进 | ✅真 | `ai_node.rs:331`（~12.7KB）完整，无任务推进 DAG 模板 |
| 8 | HumanNode 未接入任务推进 | ✅真 | `human_node.rs:640`（~27.7KB）完整，无任务审批 DAG 模板 |
| 9 | ProjectDetail 工作流入口下线 | ✅真 | `ProjectDetail.vue:289-292` 注释 R-PD-2，script 节点不注册 |
| 10 | 前端无推进入口 | ✅真 | Tasks.vue 纯展示 / TaskDetail.vue 纯只读 |
| 11 | 状态枚举三方不一致 | ⚠️部分真 | 后端7态 / 前端5态(merged) / 构想5态(done)；前端 vs 构想 `merged`≠`done` 微差 |
| 12 | advance_task / can_transition_to / review_rounds 全未实现 | ✅真 | Rust+TS 全局搜零定义，TaskRecord 无 review_rounds 字段 |

### ⚠️ 关键纠正（影响多处结论）

报告第二章 2.2「缺失关键工具」、第四章断裂点 2/3 称 **「AI 缺 update_task / run_command 工具」——核实为假**：
- `update_task`（tool_registry.rs:348）**存在**，AI 能改任务字段（含 status，经裸 update_field 非状态机收口）
- `run_command`（tool_registry.rs:468）**存在且有完整 Shell 执行实现**，AI 能写代码也能跑命令
- 真正缺失的仅 `advance_task`（推进链触发器）

**修正后结论**：AI **能**更新任务状态、**能**运行命令，但仍**不能**：① 触发三闘门推进链（无 advance_task）② 联动工作流（task_id=None + 无完成回调）。报告核心论点「任务能存不能（自动）执行/推进」成立，但「AI 缺 update_task/run_command」的具体论据错误，断裂点 2/3 已在正文中纠正标注。

---

## 一、任务在 DevFlow 中的设计定位

### 1.1 产品旅程中的位置

```
想法池 ──晋升──▶ 项目 ──拆解──▶ 任务 ──执行──▶ 工作流(DAG)
(Idea)          (Project)      (Task)         (Workflow)
 第一公民        容器/上下文     执行单元        编排引擎
```

DevFlow 的核心价值链是 **「想法 → 项目 → 任务 → 工作流」**，任务是从「规划」到「执行」的转折点：

- **想法**是「做什么」的候选池（评估/筛选/晋升）
- **项目**是「在哪个上下文做」（目录绑定/技术栈/状态）
- **任务**是「具体做什么」（标题/描述/状态/优先级/分支）
- **工作流**是「怎么自动做」（DAG 编排 AI/Script/Human 节点）

### 1.2 设计意图：AI-First 推进链

`任务推进构想-2026-06-14.md` 定义了任务的终极形态：

```
todo ──AI执行──▶ in_progress ──AI自审──▶ review_ready ──人工核对──▶ done
       AiNode            AiNode              HumanNode
       AI 干活          AI 审 AI 的活        人最终把关 AI 产出
```

核心设计原则：
- **人从「操作者」转为「审批者」** — 任务由 AI 执行，人监督 AI
- **advance_task 默认 AI 触发** — AI 执行/自审完成自动推进
- **三闸门必需** — AI 执行 / AI 自审 / 人工核对各有关卡
- **拒绝 → 退回 AI 重做** — 不是退回给人干

### 1.3 实际现状：设计 vs 实现的巨大鸿沟

| 维度 | 设计意图 | 实际实现 |
|------|---------|---------|
| 状态推进 | advance_task 状态机 + 三闸门 DAG | ❌ 不存在 advance_task，status 可被任意修改 |
| AI 执行 | AiNode/agent 读任务→写代码→跑测试→产出 diff | ❌ AiNode 存在但未接入任务推进链 |
| AI 自审 | AiNode 结构化 verdict (pass/warn/block) | ❌ 未实现 |
| 人工核对 | HumanNode 审批闭环 | ⚠️ HumanNode 存在但未接入任务推进链 |
| 状态机收口 | status 白名单移除，advance_task 唯一入口 | ❌ status 仍在白名单，任意可改 |
| 工作流联动 | task → workflow 双向关联 | ❌ workflow 的 task_id 恒为 None |
| 前端推进 UI | 推进按钮 + 环节可视化 + diff 展示 | ❌ 纯只读，无任何推进入口 |

**结论：任务模块目前是一个「数据容器」，不是「执行单元」。它能存、能查、能删，但不能推进、不能执行、不能联动工作流。**

---

## 二、执行能力分析

### 2.1 任务「执行」的定义

在 DevFlow 的 AI-First 愿景中，「执行任务」意味着：

```
1. 读取任务描述 + 项目上下文
2. AI 写代码/改文件/跑测试（agent 多步）
3. 产出 diff / 文件变更 / 测试结果
4. AI 自审产出（code review，结构化结论）
5. 人工最终核对
```

### 2.2 当前执行能力盘点

#### ❌ 任务 → 工作流：无连接

```rust
// commands/workflow.rs — run_workflow 中 task_id 恒为 None
task_id: None,  // 唯一引用点，硬编码 None
```

工作流执行**完全不感知任务**。`WorkflowRecord` 有 `task_id` 字段（V2 迁移加的），但没有任何代码写入它。工作流是独立运行的，不知道自己在为哪个任务工作。

#### ❌ AI 对话 → 任务执行：无闭环

AI 对话引擎有 12 个工具，其中任务相关：
- `list_tasks`（Low 风险，自动执行）— 只读
- `create_task`（Medium 风险，需审批）— 只创建

**缺失的关键工具**：
- ❌ 无 `update_task` 工具 — AI 不能推进任务状态
- ❌ 无 `advance_task` 工具 — AI 不能触发推进链
- ❌ 无 `run_command` 工具 — AI 能写代码但不能跑（"能写不能跑"）
- ❌ `run_workflow` 工具是空壳 — AI 不能在对话中触发工作流

AI 可以 **创建任务**，但不能 **执行任务**、**推进任务**、**关联工作流**。

#### ❌ 工作流节点 → 任务状态：无联动

```
DAG 执行完成
    │
    ▼
WorkflowRecord.status = "completed"
    │
    ▼
（结束 — 不回调任务状态，不触发 advance_task）
```

DAG 引擎有完善的执行能力（拓扑排序/并发/状态机/事件总线），但执行结果**不回写任务**。一个工作流跑完了，关联的任务状态纹丝不动。

#### ⚠️ AiNode：有能力但没接入

```rust
// ai_node.rs — 12.7KB，完整实现
// 能力：调用 LLM（OpenAI/Anthropic），config 驱动，支持上游输入
// 但：只在 DAG 内可用，没有「为某个任务执行」的入口
```

AiNode 是通用的 LLM 调用节点，可以做分析/生成/审查。但当前没有任何 DAG 模板把 AiNode 接入任务推进链。

#### ⚠️ HumanNode：有能力但没接入

```rust
// human_node.rs — 27.7KB，完整实现
// 能力：阻塞等待人工审批（subscribe→send→select!），支持单选/多选
// 但：只在 DAG 内可用，没有「为某个任务审批」的入口
```

### 2.3 执行能力总结

| 执行环节 | 需要的能力 | 现状 | 缺口 |
|---------|-----------|------|------|
| 读取任务上下文 | 任务描述 + 项目目录 + 相关文件 | ✅ AI 工具可读 | — |
| AI 写代码 | write_file 工具 | ✅ 有（需审批） | — |
| AI 跑测试 | run_command 工具 | ❌ 不存在 | AI "能写不能跑" |
| AI 自审 | AiNode verdict 结构化输出 | ❌ 未实现 | 需定义 prompt + 解析 |
| 触发工作流 | run_workflow 工具 | ❌ 空壳 | 需实装 |
| 工作流回写任务 | 完成回调 advance_task | ❌ 不存在 | 需实现回调链路 |
| 人工审批 | HumanNode 审批 | ⚠️ 存在但未接入 | 需 DAG 模板 + 路由 |

**核心断链**：任务 ←✕→ 工作流 ←✕→ AI 执行。三个系统各自独立运行，没有形成闭环。

---

## 三、推进能力分析

### 3.1 当前推进机制：裸 status 字段 + 无保护

```rust
// commands/task.rs — update_task
// status 在白名单中，任意调用方可直接修改
state.tasks.update_field(&id, "status", &value)
```

任何人（AI/用户/脚本）可以一行代码把任务从 `todo` 直接改成 `done`，跳过所有闸门。这是 `任务推进构想` 文档中标注的 **P0 致命漏洞**。

### 3.2 设计中的推进机制：advance_task + 状态机

> ⚠️ **决策更新（2026-06-16）**：本节原设想 advance_task 落 IPC 层 / df-task 复活。**D-260616-03 已决策走 df-nodes Node**（对齐 D3「业务逻辑在 df-nodes 实现」）：状态机落 `df-nodes/src/task_state_machine.rs`（F-01），advance_task 落 `df-nodes/src/task_advance_node.rs` 实现 Node trait（F-02），IPC 层 thin 入口调 df-nodes。又 **D-260616-01 已定前端对齐 7 态**，下文状态机示例的 5 态（ReviewReady/Abandoned）实施时按 7 态重设（激活 InReview/Testing/Blocked）。详见 [任务推进链实施路径](../../02-架构设计/专项设计/任务推进链实施路径-2026-06-16.md)。

构想文档设计了完整的推进链，但**全部未实现**：

#### 状态机（can_transition_to）

```rust
// 设计中 — 未实现
(Todo, InProgress | Abandoned) => true,
(InProgress, ReviewReady | Abandoned) => true,
(ReviewReady, Done | Abandoned | InProgress) => true,  // 可退回
_ => false,
```

#### 状态机下沉 SQL（防 TOCTOU）

```sql
-- 设计中 — 未实现
UPDATE tasks SET status=:new, updated_at=:now
WHERE id=:id AND status=:expected   -- affected_rows==0 即状态已变,拒绝
```

#### advance_task 命令

```
设计中 — 未实现
1. 校验状态转换合法性（can_transition_to）
2. 原子写入（下沉 SQL WHERE 前置）
3. 触发对应闸门工作流（start/ready/merge）
4. 工作流完成回调再推进状态
5. 失败路径处理（退回/保持）
```

#### loop 管理

```
设计中 — 未实现
review_rounds: i32  -- 退回时 +1，任务卡显示「第 N 轮 review」
```

### 3.3 推进能力总结

| 推进环节 | 设计方案 | 实现状态 |
|---------|---------|---------|
| 状态机定义 | 7 态 / 5 态（待统一） | ❌ 无 can_transition_to |
| 状态机收口 | 移除 status 白名单 | ❌ status 仍可任意改 |
| advance_task 命令 | 唯一 status 写入路径 | ❌ 不存在 |
| 状态机下沉 SQL | WHERE 前置防 TOCTOU | ❌ 不存在 |
| AI 执行闸门 | AiNode 最小形态 | ❌ 未接入 |
| AI 自审闸门 | AiNode verdict | ❌ 未实现 |
| 人工核对闸门 | HumanNode 审批 | ❌ 未接入 |
| 失败路径 | 退回/保持/重做 | ❌ 未实现 |
| loop 管理 | review_rounds | ❌ 字段不存在 |
| 并发护栏 | per-task 互斥锁 | ❌ 不存在 |
| 崩溃恢复 | 孤儿清理 + 审批持久化 | ⚠️ 部分存在（审批持久化有，孤儿清理无） |
| 前端推进 UI | 按钮 + 可视化 | ❌ 纯只读 |

**推进能力实现度：0%。全部停留在构想文档阶段。**

---

## 四、任务与其他系统的断裂点

### 4.1 断裂全景图

```
┌──────────┐         ┌──────────┐         ┌──────────┐         ┌──────────┐
│  想法池   │──✅晋升──│   项目    │──✅拆解──│   任务    │──✕✕✕──│  工作流   │
│ (Idea)   │         │(Project) │         │  (Task)  │         │(Workflow)│
└──────────┘         └──────────┘         └────┬─────┘         └────┬─────┘
                                               │                     │
                                          ┌────┴─────┐          ┌────┴─────┐
                                          │  AI 对话  │          │ DAG 引擎 │
                                          │ (Agentic)│          │(Executor)│
                                          └──────────┘          └──────────┘
                                               │                     │
                                          ✕ 无 update_task      ✕ task_id=None
                                          ✕ 无 advance_task     ✕ 无完成回调
                                          ✕ 无 run_command      ✕ 无状态回写
                                          ✕ run_workflow=空壳   ✕ 无任务路由
```

### 4.2 六大断裂点详解

#### 断裂点 1：任务 ↔ 工作流（task_id = None）

```rust
// commands/workflow.rs:56
task_id: None,  // 硬编码
```

工作流不知道为哪个任务执行，任务不知道被哪个工作流处理。`TaskRecord.workflow_def_id` 字段存在但从未被写入。

**影响**：工作流执行结果无法回写任务状态，无法实现「工作流完成 → 自动推进任务」。

#### 断裂点 2：AI 对话 ↔ 任务推进（无 advance_task 工具）

> ⚠️ **核对纠正**：原报告称「无 update_task 工具」——**核实为假**，`update_task`（tool_registry.rs:348）存在。AI 工具集实际仅缺 `advance_task`（推进链触发器）。AI 能经裸 `update_task` 改 status 字段（无状态机收口，B-260616-15/16 同源），但不能触发三闸门推进链。

AI 工具集有 `create_task` / `update_task` 但没有 `advance_task`。AI 能创建/改任务但不能触发推进链。

**影响**：AI 在对话中分析了任务、写了代码、跑了测试，但无法经「合法状态机路径」把任务从 `todo` 推进到 `done`，只能裸改 status（旁路闸门）。

#### 断裂点 3：~~AI 对话 ↔ 命令执行（无 run_command）~~ 【⚠️ 核对为假，本断裂点不成立】

> ⚠️ **核对纠正**：`run_command`（tool_registry.rs:468）**实际存在且有完整 Shell 执行实现**。AI 有 `write_file` 也有 `run_command`，能写代码也能跑命令，「写→跑→改」闭环成立。（注：`run_command` 属高危需审批工具，见 AE-2025-04 会话级授权；其 stdout/stderr 恒空问题见 B-260616 系列另报。）

~~AI 有 `write_file` 但没有 `run_command`。AI 写了代码但无法运行验证。~~

**影响**：~~AI 执行链断裂在「写→跑→改」的「跑」环节~~ **不成立**。AI 执行链在命令执行环节闭合。

#### 断裂点 4：AI 对话 ↔ 工作流（run_workflow 空壳）

```rust
// tool_registry.rs — run_workflow 工具是 no-op 桩
// 返回提示信息，不真正执行工作流
```

**影响**：AI 不能在对话中触发工作流来自动化任务执行。对应已有任务 `R-PD-12`。

#### 断裂点 5：工作流完成 → 任务状态（无回调）

DAG 执行器有 `WorkflowCompleted` 事件，但没有回调机制把这个事件转化为任务状态推进。

**影响**：即使工作流成功执行了 AI 执行 + AI 自审，任务状态仍然是 `todo`。

#### 断裂点 6：前端 ↔ 推进操作（无 UI 入口）

Tasks.vue 是纯展示，TaskDetail.vue 是纯只读。没有任何按钮/操作可以推进任务状态。

**影响**：用户只能通过 AI 对话（如果 AI 有工具的话）或直接 API 调用来推进任务，但前者缺工具、后者不暴露 UI。

---

## 五、核心矛盾分析

### 矛盾 1：状态枚举三方不一致

| 层面 | 状态集 | 语义导向 |
|------|--------|---------|
| 后端 enum | todo/in_progress/in_review/testing/done/blocked/cancelled | 通用软件工程 |
| 前端常量 | todo/in_progress/review_ready/merged/abandoned | Git 工作流 |
| 推进构想 | todo/in_progress/review_ready/done/abandoned | AI-First 推进链 |

三方各执一词，且推进构想的 5 态与前端常量一致但与后端 enum 不一致。**在推进链实现前必须先统一状态集**，否则状态机无法定义。

### 矛盾 2：df-task crate 已删除但任务无独立业务层

```
ARCHITECTURE.md: 5.3.1 ~~Task & Branch Manager (df-task)~~ — 已移除
> 2026-06-14 零引用清理：df-task crate 已删除
```

对比其他实体：
- **Idea** → 有 `df-ideas` crate（评估/晋升/对抗）
- **Project** → 有 `df-project` crate（扫描/管理）
- **Task** → ❌ 无独立 crate，IPC 层直连 CRUD

任务没有业务逻辑层，`commands/task.rs` 直接调 `state.tasks.insert/query/update_field/delete`。这意味着：
- 状态机逻辑无处安放（只能塞 IPC 层或重新建 crate）
- 推进链编排无处安放
- 与其他系统的联动逻辑无处安放

### 矛盾 3：工作流引擎完善但无业务消费

DAG 引擎功能完善（拓扑排序/并发执行/状态机/事件总线/审批闭环/取消机制），但**没有任何业务场景在使用它**：
- ProjectDetail.vue 的工作流演示入口已下线（R-PD-2：script 节点不再注册）
- run_workflow AI 工具是空壳
- 任务推进链未接入

引擎是「准备好了但没有乘客的列车」。

### 矛盾 4：AI 能力在增长但无法触达任务

AI 对话引擎是系统中最活跃的模块（Agentic Loop / 12 工具 / 审批门控 / 知识库集成 / 多 Provider），但它的能力**无法触达任务执行**：
- AI 能读项目代码、能写文件、能创建任务/项目/灵感
- 但不能推进任务、不能触发工作流、不能运行命令
- AI 的「手」伸到了文件系统，但伸不到任务状态机和工作流引擎

---

## 六、能力成熟度评估

### 按维度评分（满分 5 分）

| 维度 | 评分 | 说明 |
|------|------|------|
| **数据存储** | ⭐⭐⭐⭐ | CRUD 完整，SQLite 持久化，字段丰富 |
| **数据查询** | ⭐⭐⭐ | 基本查询可用，缺分页/搜索/排序 |
| **状态管理** | ⭐ | 裸字段无保护，无状态机，无收口 |
| **执行能力** | ⭐ | 完全断裂，任务无法被执行 |
| **推进能力** | ⭐ | 0% 实现，全停留在构想文档 |
| **工作流联动** | ⭐ | task_id=None，无回调，无路由 |
| **AI 集成** | ⭐⭐ | AI 能创建任务，但不能执行/推进 |
| **前端体验** | ⭐⭐ | 列表展示可用，详情只读，无操作入口 |
| **数据安全** | ⭐⭐ | 硬删除无恢复，字段保护不足 |
| **架构设计** | ⭐⭐⭐⭐ | 构想文档非常完整（344 行），设计质量高 |

**综合评分：2.1/5** — 数据层及格，执行/推进层空白。

### 与其他实体对比

| 实体 | 存储 | 业务逻辑 | AI 集成 | 工作流联动 | 前端体验 | 综合 |
|------|------|---------|---------|-----------|---------|------|
| **Idea** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ (df-ideas) | ⭐⭐⭐ (评估/晋升) | ⚪ N/A | ⭐⭐⭐⭐ | **3.6** |
| **Project** | ⭐⭐⭐⭐ | ⭐⭐⭐ (df-project) | ⭐⭐⭐ (创建/描述) | ⚪ N/A | ⭐⭐⭐⭐ | **3.5** |
| **Task** | ⭐⭐⭐⭐ | ⭐ (无 crate) | ⭐ (仅创建) | ⭐ (断裂) | ⭐⭐ (只读) | **2.1** |
| **Workflow** | ⭐⭐⭐ | ⭐⭐⭐⭐ (df-workflow) | ⭐⭐ (AiNode 可用) | ⭐ (无消费) | ⭐⭐ (已下线) | **2.4** |
| **Knowledge** | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ (提炼/注入) | ⚪ N/A | ⭐⭐⭐ | **3.4** |

**任务是系统中成熟度最低的实体。**

---

## 七、根因分析

### 为什么任务模块「能存不能执行」？

```
根因链（从表层到深层）：

表层：前端无推进入口，后端无 advance_task
  ↑
中层：任务 ↔ 工作流断裂（task_id=None），AI 工具缺 update_task/run_command
  ↑
深层：df-task crate 被删除后，任务没有业务逻辑层
  ↑
根因：任务推进链涉及跨系统编排（Task + Workflow + AI + Human），
      但系统设计是「引擎不绑定业务」（D3 决策），
      导致引擎和业务之间的「胶水层」始终没有建立
```

### 架构决策 D3 的双刃剑

```markdown
### D3: 引擎不绑定业务
- DAG 引擎纯粹做编排，不感知具体业务语义
- 业务逻辑在 df-nodes 实现（Node trait 是纯接口）
```

这个决策本身是好的（关注点分离），但它留下了一个**架构空洞**：

```
DAG 引擎（通用编排）  ←——空洞——→  任务业务（具体语义）
    df-workflow                       ???
    df-nodes
```

谁来把「任务推进」这个业务语义映射到「DAG 工作流执行」？答案应该是 **advance_task 编排层**（构想文档中设计了但未实现），或者一个新 crate（df-task 的复活）。

---

## 八、建议：从「数据容器」到「执行单元」的路径

### 阶段 0：修复基础问题（前置条件）

参照 `任务模块问题分析-2026-06-16.md`：
1. 统一状态枚举（前后端对齐）
2. 注册 `/tasks/:id` 路由
3. 补 updateTask store 错误处理
4. 不可变字段保护

### 阶段 1：建立推进骨架（最小闭环）

```
目标：任务状态能通过「合法路径」推进，而非裸字段修改

1. 实现 TaskStatus::can_transition_to（状态机定义）
2. 实现 advance_task 推进逻辑（**df-nodes Node**，D-260616-03 已决策；IPC 层 thin 入口）：校验+原子写入+状态机下沉 SQL
3. 从 update_task 白名单移除 status（收口）
4. 前端 TaskDetail 加推进按钮（手动推进，不接 AI）
5. 补 review_rounds 字段
```

此阶段不接 AI/工作流，纯人工推进，但状态机保护和收口到位。

### 阶段 2：接入工作流（单向联动）

```
目标：工作流执行能回写任务状态

1. run_workflow 支持 task_id 参数（不再硬编码 None）
2. 工作流完成回调 → 检查 task_id → 推进任务状态
3. 定义任务推进 DAG 模板（AiNode 执行 + AiNode 自审 + HumanNode 核对）
4. advance_task 触发对应闸门工作流
5. 前端展示工作流执行进度
```

### 阶段 3：AI 执行能力（闭环）

```
目标：AI 能真正执行任务内容

1. 补 run_command AI 工具（或等 patch_file + run_command 完善）
2. 补 update_task / advance_task AI 工具
3. 实装 run_workflow AI 工具（不再是空壳）
4. AiNode 接入任务上下文（读任务描述 + 项目目录）
5. AI 自审 verdict 结构化输出 + 解析
6. 失败路径完整处理（退回/重做/保持）
```

### 阶段 4：Git 集成（增强）

```
目标：代码类任务支持 Git 工作流

1. 加 kind 字段（code/doc/design/generic）
2. code kind 闸门接 git 命令（worktree/commit/merge）
3. BranchRecord 联动（加 worktree_path）
4. on_task_advanced 钩子填充（分支联动 + 项目 completed）
```

---

## 九、总结

### 一句话诊断

**任务是 DevFlow 系统中设计最完善（344 行构想文档）但实现最空白（0% 推进能力）的模块。它目前是一个「能存能查不能做」的数据容器，距离设计中的「AI-First 执行单元」还有阶段 1-3 的完整路径要走。**

### 最紧迫的事

不是写 AI 执行、不是接工作流，而是 **先建立 advance_task 状态机骨架 + 收口 status 字段**。因为：
- 状态机是所有后续工作的基础（没有合法转换定义，AI 推进无从谈起）
- status 旁路是 P0 安全漏洞（AI 能直接改 status = done，所有闸门形同虚设）
- 这是投入最小（~200 行代码）但收益最大的改动（从 0% 推进能力到「手动推进闭环」）