绝尘
80239500f1
- 项目知识图谱与任务队列系统-2026-06-26.md:AI Working 终局设计(任务网络queue/parent/links + 事件流 + 基础设施 + 注入 + Mission Control 五视图),父②Phase1 + 父⑥Phase2-3 已据此实施落地 - AI原生上下文地图与去AI化进化系统-2026-06-26.md:AI Working 定位体系设计
833 lines
39 KiB
Markdown
833 lines
39 KiB
Markdown
# 项目知识图谱与任务队列系统 — 设计
|
||
|
||
> **日期**: 2026-06-26
|
||
> **状态**: 设计阶段（待评审）
|
||
> **前提**: AI Working — AI 是系统的主要操作者，人是监督者与决策者
|
||
> **关联**: ARCHITECTURE.md §AI Working 定位体系 / 多工程方案（子1-子5）/ todo.md 灵感模块 + AI 对话目标丢失
|
||
|
||
---
|
||
|
||
## 〇、核心命题
|
||
|
||
**DevFlow 的终局是：AI 拥有完整的项目信息知识图谱，比任何人都了解项目。**
|
||
|
||
人在 AI Chat 中描述目标，AI 基于图谱自主分解任务、编排依赖、执行推进、自检完成度。人的角色是决策确认和方向把控，不是填表单和翻列表。
|
||
|
||
本文档定义支撑这一终局所需的数据结构、关联关系和实现路径。
|
||
|
||
---
|
||
|
||
## 一、问题诊断
|
||
|
||
### 1.1 当前缺失
|
||
|
||
| 缺失 | 后果 |
|
||
|------|------|
|
||
| **无全局工作队列** | 任务散落在各项目下，无法跨项目看"所有待办" |
|
||
| **需求无承载体** | Idea 是模糊灵感，Task 是具体执行，中间缺"已确认要做但还没排期"的需求层 |
|
||
| **决策无队列** | AI Agentic Loop 中产生的"需要人决策"事项散落在对话流里，错过即丢失 |
|
||
| **任务无纵向关联** | 无法表达"一个需求拆出多个子任务"（当前用 `[子N]` 标题前缀硬编码） |
|
||
| **任务无横向关联** | 无法表达任务间依赖关系，AI 无法做拓扑排序编排 |
|
||
| **需求无结构化规格** | description 是纯文本，AI 无法提取验收标准做自检 |
|
||
| **无基础设施记录** | AI 不知道项目用了什么数据库/缓存/MQ |
|
||
| **无统一事件流** | 回答"上周做了什么"需跨 6 张表 JOIN |
|
||
| **溯源链断裂** | 无法从任务回溯到灵感、从灵感到对话、从对话到决策 |
|
||
|
||
### 1.2 核心原则
|
||
|
||
> **每一条数据结构都不是给人填的表单，是给 AI 消费的上下文。**
|
||
>
|
||
> 前端可视化是最后的投影层，不是数据结构存在的原因。
|
||
|
||
---
|
||
|
||
## 二、数据模型设计
|
||
|
||
> 当前迁移版本 V27（V21=消息拆分 / V22=灵感评估 / V23=嵌入状态 / V24=灵感关联 / V25=评估唯一约束 / V26=任务索引 / V27=审批状态统一）。本设计从 V28 起。
|
||
|
||
### 2.1 Task 表扩展（V28 迁移）
|
||
|
||
```sql
|
||
-- 队列字段：AI 行为约束信号
|
||
ALTER TABLE tasks ADD COLUMN queue TEXT NOT NULL DEFAULT 'todo';
|
||
-- backlog(需求池) / todo(待办池) / decision(待决策池) / active(执行中) / done(已完成)
|
||
|
||
-- 父任务 ID：AI 分解-执行编排结构
|
||
ALTER TABLE tasks ADD COLUMN parent_id TEXT REFERENCES tasks(id);
|
||
-- NULL = 叶子任务；非空 = 子任务（限制 1 级，不允许孙任务）
|
||
|
||
-- 结构化需求规格：AI 可读写的执行规格
|
||
ALTER TABLE tasks ADD COLUMN content_json TEXT;
|
||
-- JSON: { background, acceptance_criteria[], scope[], technical_design, custom_fields }
|
||
```
|
||
|
||
#### queue 字段语义
|
||
|
||
| queue 值 | 含义 | AI 行为约束 |
|
||
|----------|------|------------|
|
||
| `backlog` | 需求池：确认有价值，未排期 | AI **不自主推进**，等待人确认排期 |
|
||
| `todo` | 待办池：已排期，待执行 | AI **可自主推进**到 active + in_progress |
|
||
| `decision` | 待决策池：需要人拍板 | AI **暂停执行**，请求人类输入 |
|
||
| `active` | 执行中：正在推进 | AI **按状态机推进** |
|
||
| `done` | 已完成 | 终态 |
|
||
|
||
#### queue 与 status 的关系
|
||
|
||
两个正交维度，各管各的：
|
||
|
||
```
|
||
queue（管理维度）：backlog → todo → active → done
|
||
↑
|
||
decision（临时池）
|
||
|
||
status（执行维度）：todo → in_progress → in_review → testing → done
|
||
↑
|
||
blocked / cancelled
|
||
```
|
||
|
||
**一致性约束**（IPC 层校验，不进状态机）：
|
||
- queue=done 时 status 必须=done
|
||
- queue=backlog 时 status 必须=todo
|
||
- queue=active 时 status ∈ {in_progress, in_review, testing}
|
||
- status=blocked 时 queue 可为 decision 或 active
|
||
|
||
#### parent_id 纵向关联
|
||
|
||
- **限制 1 级嵌套**：parent 有 parent_id 时拒绝再创建子任务
|
||
- **父任务=容器模型**：父任务 status 不走状态机（不能 advance_task），由子任务聚合计算
|
||
- **聚合规则**：
|
||
|
||
| 子任务状态 | 父任务推导 status |
|
||
|-----------|-----------------|
|
||
| 全 todo | todo |
|
||
| 任一 in_progress | in_progress |
|
||
| 任一 blocked | blocked |
|
||
| 全 done/cancelled | done |
|
||
|
||
#### content_json 结构
|
||
|
||
```jsonc
|
||
{
|
||
"background": "当前 DevFlow 一个项目只能绑一个目录...", // 背景：AI 理解动机
|
||
"acceptance_criteria": [ // 验收标准：AI 自检清单
|
||
"看板三列拖拽",
|
||
"跨项目展示任务"
|
||
],
|
||
"scope": ["前端 Board.vue", "task_repo", "router"], // 影响范围：AI 操作边界
|
||
"technical_design": "新增 queue 字段 + task_links 表...", // 技术方案：AI 执行路径
|
||
"custom_fields": {} // 扩展字段
|
||
}
|
||
```
|
||
|
||
**定位**：不是人填的表单，是 AI 和人协作填充的结构化规格。AI 从对话中提取信息填充，人确认后 AI 执行中用 acceptance_criteria 自检。
|
||
|
||
### 2.2 task_links 表（横向关联）
|
||
|
||
```sql
|
||
CREATE TABLE task_links (
|
||
id TEXT PRIMARY KEY,
|
||
source_id TEXT NOT NULL REFERENCES tasks(id),
|
||
target_id TEXT NOT NULL REFERENCES tasks(id),
|
||
link_type TEXT NOT NULL, -- depends_on / blocks / relates_to
|
||
remark TEXT, -- 可选备注
|
||
created_at TEXT NOT NULL
|
||
);
|
||
CREATE INDEX idx_task_links_source ON task_links(source_id);
|
||
CREATE INDEX idx_task_links_target ON task_links(target_id);
|
||
```
|
||
|
||
#### link_type 语义
|
||
|
||
| 类型 | 语义 | AI 用途 |
|
||
|------|------|---------|
|
||
| `depends_on` | source 依赖 target（target 完成后 source 才能开始） | **拓扑排序调度** |
|
||
| `blocks` | source 阻塞 target（source 不完成则 target 无法推进） | 依赖的反向声明 |
|
||
| `relates_to` | 弱关联，无执行约束 | 上下文提示 |
|
||
|
||
#### 为什么不用 JSON 列（仿 Idea related_ids）
|
||
|
||
Idea 的 related_ids JSON 方案是 todo.md 待修的 P1 问题（#8 关联双向同步）。JSON 列的缺陷：
|
||
- 无类型区分（不能表达 depends_on vs relates_to）
|
||
- 单向（A 关联 B 不意味着 B 知道）
|
||
- 无法高效反向查询（"谁依赖了我"需全表扫描 JSON）
|
||
|
||
独立表方案：有类型、双向查询、可扩展。
|
||
|
||
#### 边界约束
|
||
|
||
| 约束 | 规则 |
|
||
|------|------|
|
||
| 循环依赖 | 创建 link 时 BFS 检测环，拒绝 A→B→A |
|
||
| 跨项目 | 允许（现实中有跨项目依赖） |
|
||
| 软删除 | Task 软删除时保留 link（恢复后关系还在） |
|
||
| 执行约束 | AI **应遵守** depends_on（检查依赖全 done 才推进），人**可绕过** |
|
||
|
||
### 2.3 project_services 表（基础设施配置）
|
||
|
||
```sql
|
||
CREATE TABLE project_services (
|
||
id TEXT PRIMARY KEY,
|
||
project_id TEXT NOT NULL REFERENCES projects(id),
|
||
name TEXT NOT NULL, -- "主数据库" / "缓存" / "消息队列"
|
||
service_type TEXT NOT NULL, -- mysql/postgresql/sqlite/redis/mongodb/mq/api/other
|
||
endpoint TEXT, -- 连接地址（localhost:3306 / URL）
|
||
config_json TEXT, -- 类型相关配置 JSON
|
||
environment TEXT NOT NULL DEFAULT 'development', -- development/staging/production
|
||
remark TEXT,
|
||
created_at TEXT NOT NULL,
|
||
updated_at TEXT NOT NULL
|
||
);
|
||
```
|
||
|
||
**定位**：AI 执行任务时的基础设施上下文。AI 知道"这个项目用了什么数据库、Redis 在哪、有没有 MQ"。
|
||
|
||
**边界**：
|
||
- ⚠️ **不存敏感凭证**（密码/密钥）—— 只存连接信息，凭证走环境变量/外部密钥管理
|
||
- 这是元数据，不是运维工具 —— 不做连接池/健康检查
|
||
|
||
### 2.4 project_events 表（统一事件流）
|
||
|
||
```sql
|
||
CREATE TABLE project_events (
|
||
id TEXT PRIMARY KEY,
|
||
project_id TEXT NOT NULL REFERENCES projects(id),
|
||
event_type TEXT NOT NULL,
|
||
-- idea_created / idea_promoted / idea_evaluated
|
||
-- task_created / task_advanced / task_blocked / task_completed
|
||
-- workflow_started / workflow_completed
|
||
-- knowledge_extracted / knowledge_referenced
|
||
-- service_added / service_updated
|
||
-- module_bound / module_unbound
|
||
-- decision_made
|
||
entity_type TEXT, -- idea/project/task/workflow/knowledge/module/service
|
||
entity_id TEXT, -- 对应实体 ID
|
||
from_state TEXT, -- 状态变化前
|
||
to_state TEXT, -- 状态变化后
|
||
context_json TEXT, -- 事件附加上下文
|
||
source TEXT, -- ai / human / system
|
||
conversation_id TEXT, -- 触发事件的对应对话（AI Working 溯源）
|
||
created_at TEXT NOT NULL
|
||
);
|
||
CREATE INDEX idx_project_events_project ON project_events(project_id, created_at);
|
||
CREATE INDEX idx_project_events_entity ON project_events(entity_type, entity_id);
|
||
```
|
||
|
||
**定位**：AI 精准检索的基础。回答"上周做了什么""这个任务为什么 blocked""这个决策是什么时候做的"。
|
||
|
||
**与 knowledge_events 的关系**：knowledge_events 保持不变（知识库专属，向后兼容）。project_events 是全局事件流，knowledge 事件同时写入两者。
|
||
|
||
**埋点策略**：在现有 IPC 命令（create_task / advance_task / create_project 等）的执行后追加事件写入。不侵入业务逻辑，用 hook/after 模式。
|
||
|
||
### 2.5 Inbox 项目（project_id NOT NULL 兼容）
|
||
|
||
需求池的任务可能还没决定归到哪个项目。保持 `project_id NOT NULL` 约束，系统初始化自动创建 Inbox 项目：
|
||
|
||
- name = "收件箱"
|
||
- status = planning
|
||
- 特殊标记不可删除
|
||
- 不参与 Dashboard 统计
|
||
|
||
---
|
||
|
||
## 三、完整图谱视图
|
||
|
||
```
|
||
💡 Idea
|
||
╱ │ ╲
|
||
evaluations related_ids
|
||
│
|
||
promoted_to
|
||
│
|
||
▼
|
||
┌────── 📂 Project ──────────────────────────────────┐
|
||
│ ╱ │ ╲ │
|
||
│ modules services project_events │
|
||
│ (多工程) (基础设施) (统一事件流) │
|
||
│ │
|
||
│ ╱ │ ╲ │
|
||
│ parent links workflow │
|
||
│ (纵向) (横向) (执行) │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ ▼ │
|
||
│ 🔀 Task ── Task ── ⚙️ Workflow │
|
||
│ │ ╱ ╲ │
|
||
│ content_json nodes branches │
|
||
│ (执行规格) (节点执行) (分支) │
|
||
│ │
|
||
│ queue (管理池: backlog/todo/decision/active/done) │
|
||
│ │
|
||
│ ai_tool_executions ←─ conversation_id ──→ 💬 对话 │
|
||
│ (AI 操作审计) (AI Working 留痕) │
|
||
│ │
|
||
│ knowledges ←── knowledge_events │
|
||
│ (经验沉淀) (知识事件) │
|
||
└────────────────────────────────────────────────────┘
|
||
|
||
每条线都是 AI 可查询、可推理的关系。
|
||
```
|
||
|
||
---
|
||
|
||
## 四、AI 上下文注入
|
||
|
||
### 4.1 get_project_context 工具
|
||
|
||
AI "比人懂项目"的技术实现 —— 一次调用获得完整心智模型：
|
||
|
||
```jsonc
|
||
// get_project_context(project_id) →
|
||
{
|
||
"project": {
|
||
"id", "name", "status", "stack",
|
||
"created_from": { "idea_id", "ai_analysis", "score" }
|
||
},
|
||
"modules": [
|
||
{ "name", "path", "stack", "dependencies": [...] }
|
||
],
|
||
"services": [
|
||
{ "type", "endpoint", "environment" }
|
||
],
|
||
"task_summary": {
|
||
"total", "by_status", "by_queue",
|
||
"blocked_tasks": [{ "id", "title", "blocked_by" }],
|
||
"in_progress": [{ "id", "title", "progress" }]
|
||
},
|
||
"task_graph": {
|
||
"parent_children": { "parent_id": ["child_id", ...] },
|
||
"dependencies": [{ "from", "to", "type" }]
|
||
},
|
||
"recent_events": [/* 最近 20 条事件 */],
|
||
"key_decisions": [/* 重要决策记录 */],
|
||
"known_pitfalls": [/* knowledges kind=pitfall */]
|
||
}
|
||
```
|
||
|
||
### 4.2 自动注入策略
|
||
|
||
此上下文可自动注入到每次 AI 对话的 system prompt（类似现有 useAiContext），让 AI 在每轮交互中都带着完整的项目认知。
|
||
|
||
**Token 预算**：完整上下文可能较大，需分级注入：
|
||
- **L0（始终注入）**：project 基础信息 + task_summary（~500 token）
|
||
- **L1（对话开始注入）**：task_graph + recent_events（~2000 token）
|
||
- **L2（按需调用）**：full context（get_project_context 工具）
|
||
|
||
---
|
||
|
||
## 五、AI 工具注册表
|
||
|
||
| 工具 | 用途 | 风险等级 |
|
||
|------|------|---------|
|
||
| `create_task` | 创建任务（支持 queue/parent_id/content_json） | low |
|
||
| `list_tasks` | 查询（支持 queue/parent_id/status 筛选） | low（只读） |
|
||
| `move_task_queue` | 跨池移动（backlog→todo→active→done） | medium |
|
||
| `create_task_link` | 建立任务关联（depends_on/blocks/relates_to） | medium |
|
||
| `remove_task_link` | 解除关联 | medium |
|
||
| `list_task_links` | 查询任务关联（AI 编排调度用） | low（只读） |
|
||
| `get_task_tree` | 获取父子任务树（含子任务进度聚合） | low（只读） |
|
||
| `update_content` | 更新 content_json 结构化规格 | medium |
|
||
| `get_project_context` | 获取项目完整图谱投影 | low（只读） |
|
||
| `get_project_timeline` | 查询项目事件流 | low（只读） |
|
||
| `add_project_service` | 添加基础设施配置 | medium |
|
||
| `list_project_services` | 查询基础设施 | low（只读） |
|
||
|
||
已有工具（扩展参数）：`advance_task`、`update_task`、`list_tasks`。
|
||
|
||
---
|
||
|
||
## 六、AI Working 完整工作流
|
||
|
||
```
|
||
人在 AI Chat 说："我想给 DevFlow 加队列看板功能"
|
||
│
|
||
▼ ① AI 创建需求
|
||
create_task(
|
||
title="队列看板功能",
|
||
queue="backlog",
|
||
content_json={ background, acceptance_criteria, scope, technical_design }
|
||
)
|
||
│
|
||
▼ ② 人确认需求（AI Chat 内审批）
|
||
人修改 content_json → AI 执行 move_task_queue(backlog → todo)
|
||
│
|
||
▼ ③ AI 自主分解
|
||
AI 创建子任务（parent_id 指向父任务）：
|
||
child-1: "V28 迁移 + queue 列 + task_links 表"
|
||
child-2: "TaskRecord + Repo 扩展"
|
||
child-3: "Board.vue 看板视图"
|
||
child-4: "AI 工具注册"
|
||
│
|
||
▼ ④ AI 建立依赖
|
||
create_task_link(child-3, depends_on, child-1)
|
||
create_task_link(child-3, depends_on, child-2)
|
||
create_task_link(child-4, depends_on, child-2)
|
||
│
|
||
▼ ⑤ AI 按拓扑序执行
|
||
拓扑排序：child-1 → child-2 → child-3 ∥ child-4
|
||
AI 逐个 advance_task(todo → in_progress → ... → done)
|
||
每完成一个检查后继解锁
|
||
每步操作写入 project_events
|
||
│
|
||
▼ ⑥ AI 自检
|
||
对照 content_json.acceptance_criteria 逐项检查
|
||
│
|
||
▼ ⑦ 父任务聚合
|
||
全部子任务 done → 父任务自动聚合 done
|
||
AI 报告人类："队列看板功能已完成"
|
||
```
|
||
|
||
---
|
||
|
||
## 七、改动影响评估
|
||
|
||
| 层 | 改动 | 量级 | 风险 |
|
||
|---|------|------|------|
|
||
| df-storage V28 | queue 列 + parent_id 列 + content_json 列 + task_links 表 + project_services 表 + project_events 表 | 中 | 低（纯加列加表） |
|
||
| df-types | TaskRecord 加 3 字段 + TaskLink / ProjectService / ProjectEvent 类型 | 小 | 低 |
|
||
| task_repo | insert/update 补字段 + TaskLinkRepo / ProjectServiceRepo / ProjectEventRepo | 中 | 低 |
|
||
| task_state_machine | **不改** | 无 | 无 |
|
||
| 父任务聚合逻辑 | 新增（子任务 status 变化时重算父 status） | 中 | 中（需定义聚合规则） |
|
||
| 事件埋点 | 在现有 IPC 命令后追加事件写入 | 中 | 低（hook 模式，不侵入） |
|
||
| IPC | create_task 加可选参数 + link/service/event CRUD + move_task_queue | 中 | 低 |
|
||
| AI 工具 | 新增 12 个工具注册 + create_task 参数扩展 | 中 | 低 |
|
||
| 前端 Board 看板 | 新增视图 | 中 | 低 |
|
||
| 前端 Task 详情 | 结构化渲染 content_json + 子任务列表 + 关联面板 | 中 | 低 |
|
||
| 前端项目详情 | 基础设施面板 + 时间线面板 | 中 | 低 |
|
||
| Inbox 项目 | 系统初始化创建 | 小 | 低 |
|
||
|
||
---
|
||
|
||
## 八、实现路径（按 AI 价值排序）
|
||
|
||
### Phase 1 — 任务网络基础（AI 编排的地基）
|
||
|
||
| 任务 | 内容 | 依赖 |
|
||
|------|------|------|
|
||
| V28 迁移 | queue + parent_id + content_json 列 + task_links 表 | 无 |
|
||
| TaskRecord 扩展 | df-types + df-storage models 补字段 | V28 |
|
||
| TaskLinkRepo | CRUD + 按 source/target 查询 + 循环依赖检测 | V28 |
|
||
| task_repo 扩展 | insert/update 补 queue/parent_id/content_json | TaskRecord |
|
||
| IPC: create_task 扩展 | 加 queue/parent_id/content_json 可选参数 | task_repo |
|
||
| IPC: task_link CRUD | create/remove/list_task_links | TaskLinkRepo |
|
||
| IPC: move_task_queue | 跨池移动 + 一致性约束校验 | task_repo |
|
||
| 父任务聚合 | 子任务 status 变化时重算父 status | task_repo |
|
||
| AI 工具注册 | create_task_link / remove_task_link / list_task_links / get_task_tree / move_task_queue / update_content | IPC |
|
||
|
||
### Phase 2 — 统一事件流（AI 精准检索的地基）
|
||
|
||
| 任务 | 内容 | 依赖 |
|
||
|------|------|------|
|
||
| project_events 表 | V28（或 V29 独立迁移） | 无 |
|
||
| ProjectEventRepo | CRUD + 按 project_id 查询 + 按 entity 查询 | project_events |
|
||
| 事件埋点 | create_task / advance_task / create_project / idea_promote 等追加事件写入 | ProjectEventRepo |
|
||
| IPC: get_project_timeline | 事件流查询（支持时间范围/事件类型筛选） | ProjectEventRepo |
|
||
| AI 工具注册 | get_project_timeline | IPC |
|
||
|
||
### Phase 3 — 项目基础设施（AI 上下文补全）
|
||
|
||
| 任务 | 内容 | 依赖 |
|
||
|------|------|------|
|
||
| project_services 表 | V28（或 V30 独立迁移） | 无 |
|
||
| ProjectServiceRepo | CRUD | project_services |
|
||
| IPC: service CRUD | add/update/remove/list_project_services | ProjectServiceRepo |
|
||
| modules 表 | 复用多工程方案子1 | 无 |
|
||
| AI 工具注册 | add_project_service / list_project_services | IPC |
|
||
|
||
### Phase 4 — AI 上下文注入（AI 使用知识图谱的接口）
|
||
|
||
| 任务 | 内容 | 依赖 |
|
||
|------|------|------|
|
||
| get_project_context 工具 | 聚合查询返回完整图谱投影 | Phase 1-3 |
|
||
| 分级注入策略 | L0 始终注入 / L1 对话开始 / L2 按需调用 | get_project_context |
|
||
| useAiContext 扩展 | 对接现有上下文注入机制 | 分级注入策略 |
|
||
|
||
### Phase 5 — 前端可视化（人的查看层）
|
||
|
||
| 任务 | 内容 | 依赖 |
|
||
|------|------|------|
|
||
| Board 看板 | 三列拖拽 + 跨项目展示 + 快速录入 | Phase 1 |
|
||
| Task 详情增强 | content_json 结构化渲染 + 子任务列表 + 关联面板 | Phase 1 |
|
||
| 项目时间线 | 事件流可视化 | Phase 2 |
|
||
| 基础设施面板 | 服务列表 + 增删改 | Phase 3 |
|
||
| 项目图谱视图 | 全景关系图（可选，优先级最低） | Phase 1-3 |
|
||
|
||
---
|
||
|
||
## 九、关键设计决策记录
|
||
|
||
| # | 决策点 | 选择 | 理由 |
|
||
|---|--------|------|------|
|
||
| D1 | queue vs status 扩展 | 新增 queue 字段 | 正交维度，状态机不动，职责分离 |
|
||
| D2 | parent_id 嵌套深度 | 限制 1 级 | 避免递归复杂度和进度幻觉 |
|
||
| D3 | 父任务语义 | 容器模型，status 聚合计算 | 父任务不执行工作流 |
|
||
| D4 | 横向关联 | 独立 task_links 表 | 有类型、可双向查询，避免 JSON 方案已知缺陷 |
|
||
| D5 | 需求结构化 | content_json + description 并存 | 结构化渲染 + 自由描述互补 |
|
||
| D6 | project_id 约束 | 保持 NOT NULL + Inbox 项目 | 最小改动，GTD 收件箱模式 |
|
||
| D7 | depends_on 执行约束 | AI 应遵守，人可绕过 | 过强约束会被绕过 |
|
||
| D8 | 循环依赖检测 | 创建 link 时 BFS 检测 | task_links 数据量小，检测成本低 |
|
||
| D9 | 事件流与 knowledge_events | 并存不替代 | knowledge_events 向后兼容 |
|
||
| D10 | 敏感凭证 | 不存入 project_services | 安全边界，凭证走环境变量 |
|
||
| D11 | 数据结构定位 | 为 AI 消费设计，非为人填表单 | AI Working 核心原则 |
|
||
| D12 | 实现优先级 | 按 AI 价值排序非按 UI 需求 | AI Working 核心原则 |
|
||
|
||
---
|
||
|
||
## 十、任务全景视图设计（Mission Control）
|
||
|
||
> **核心目标**：一个页面，看清全部项目的任务推进过程、状态分布、依赖关系、时间维度、卡点阻塞。
|
||
|
||
### 10.1 信息架构
|
||
|
||
用户要的是五个维度的清晰呈现，对应五种视图模式：
|
||
|
||
| 维度 | 视图 | 核心问题 | 数据来源 |
|
||
|------|------|---------|---------|
|
||
| **推进过程** | 看板视图 | 任务在 backlog→todo→active→done 各池的分布和流动 | tasks.queue |
|
||
| **状态分布** | 热力矩阵 | 每个项目 × 每个状态的交叉分布，一眼看全局 | tasks GROUP BY project, status |
|
||
| **依赖关系** | DAG 图 | 任务间依赖链、拓扑序、关键路径 | task_links + parent_id |
|
||
| **时间维度** | 时间线 | 任务的创建/推进/完成时间线，最近活跃度 | tasks.created_at/updated_at + project_events |
|
||
| **卡点阻塞** | 阻塞面板 | 哪些任务 blocked、为什么 blocked、阻塞了谁 | tasks.status=blocked + task_links(blocks) |
|
||
|
||
### 10.2 路由 & 页面结构
|
||
|
||
```
|
||
/mission-control → MissionControl.vue（壳页面，顶部 Tab 切换五种视图）
|
||
├── Tab 1: 看板（KanbanView.vue） — 默认视图
|
||
├── Tab 2: 矩阵（MatrixView.vue）
|
||
├── Tab 3: 依赖图（DagView.vue）
|
||
├── Tab 4: 时间线（TimelineView.vue）
|
||
├── Tab 5: 阻塞（BlockedView.vue）
|
||
└── 公共侧栏: 筛选器（项目/优先级/负责人）
|
||
```
|
||
|
||
侧栏新增导航项：**🚀 任务全景**（Mission Control），位于"任务"和"知识库"之间。
|
||
|
||
### 10.3 各视图详细设计
|
||
|
||
#### 10.3.1 看板视图（KanbanView）— 推进过程
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────────┐
|
||
│ 💡 需求池(3) │ 📋 待办(5) │ 🔨 执行中(2) │ ✅ 完成(12) │
|
||
│ │ │ │ │
|
||
│ ┌───────────────┐ │ ┌────────────────┐ │ ┌──────────────┐ │ ┌──────────┐ │
|
||
│ │ 队列看板功能 │ │ │ V28 迁移+表结构 │ │ │ TaskRecord扩 │ │ │ 软删除 │ │
|
||
│ │ DevFlow · P1 │ │ │ DevFlow · P0 │ │ │ DevFlow·P1 │ │ │ B-13 │ │
|
||
│ │ 🔗 4 子任务 │ │ │ 🔗 → Board.vue │ │ │ ▓▓▓▓▓░░ 70% │ │ │ 06-16 │ │
|
||
│ └───────────────┘ │ └────────────────┘ │ └──────────────┘ │ └──────────┘ │
|
||
│ ┌───────────────┐ │ ┌────────────────┐ │ │
|
||
│ │ 插件机制 │ │ │ DagView 依赖图 │ │ │
|
||
│ │ DevFlow · P2 │ │ │ DevFlow · P1 │ │ │
|
||
│ └───────────────┘ │ └────────────────┘ │ │
|
||
│ │ │ │
|
||
│ ⚠️ 待决策(1) │ │ 🚫 阻塞(1) │
|
||
│ ┌───────────────┐ │ │ ┌──────────────┐ │
|
||
│ │ API 协议选型 │ │ │ │ IPC 层封装 │ │
|
||
│ │ ❓需确认 │ │ │ │ 被 V28 阻塞 │ │
|
||
│ └───────────────┘ │ │ └──────────────┘ │
|
||
└─────────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**列定义**（对应 queue 值）：
|
||
|
||
| 列 | queue | 子列 | 说明 |
|
||
|----|-------|------|------|
|
||
| 需求池 | backlog | — | 确认有价值，未排期 |
|
||
| 待决策 | decision | — | 需要人拍板，**红色高亮** |
|
||
| 待办 | todo | — | 已排期，可执行 |
|
||
| 执行中 | active | 正常 | 按状态机推进中 |
|
||
| 执行中 | active | 阻塞 | status=blocked，**红色边框 + 阻塞原因** |
|
||
| 完成 | done | — | 终态 |
|
||
|
||
**卡片信息密度**：
|
||
```
|
||
┌──────────────────────────┐
|
||
│ 任务标题（1 行截断） │ ← title
|
||
│ 项目名 · 优先级标签 │ ← project.name + priority badge
|
||
│ 🔗 3 子任务 / 🔗→ 依赖任务 │ ← parent_id 子任务计数 / depends_on 链
|
||
│ ▓▓▓▓░░ 60% │ ← 子任务完成率（父任务）/ 状态机进度（叶子）
|
||
│ 🚫 被 xxx 阻塞 │ ← blocked 时显示阻塞源（仅红色卡片）
|
||
│ 06-26 │ ← updated_at（相对时间）
|
||
└──────────────────────────┘
|
||
```
|
||
|
||
**交互**：
|
||
- 点击卡片 → 跳转 TaskDetail
|
||
- 卡片左滑/右滑 → 快捷 move_task_queue（需确认）
|
||
- 列头显示计数 + 拖拽提示
|
||
- 顶部全局筛选：项目（多选）/ 优先级 / 负责人
|
||
|
||
**跨项目展示**：卡片左上角的项目色条（3px）区分项目归属，悬停显示项目全名。
|
||
|
||
#### 10.3.2 热力矩阵（MatrixView）— 状态分布
|
||
|
||
```
|
||
todo in_progress in_review testing blocked done 总计
|
||
DevFlow 3 2 1 0 2 12 20
|
||
u-ask 1 0 0 0 0 5 6
|
||
u-img 0 1 0 0 0 3 4
|
||
workpod 2 0 0 0 0 1 3
|
||
─────────────────────────────────────────────────────────────────────────
|
||
总计 6 3 1 0 2 21 33
|
||
```
|
||
|
||
**视觉**：每个格子是一个色块，数字越大颜色越深（热力图）。blocked 列**红色系**，done 列**绿色系**，其他列**蓝色系**。
|
||
|
||
**交互**：
|
||
- 点击格子 → 展开该项目该状态的任务列表（inline accordion 或侧抽屉）
|
||
- 行/列可排序（按总计降序）
|
||
- 顶部摘要条：`33 任务 · 2 阻塞 · 3 执行中 · 完成率 64%`
|
||
|
||
**AI 消费价值**：get_project_context 的 task_summary.by_status / by_queue 就是这个矩阵的数据源。AI 读到 `blocked: 2` 就知道要主动排查阻塞。
|
||
|
||
#### 10.3.3 依赖图（DagView）— 依赖关系
|
||
|
||
```
|
||
┌──────────┐
|
||
│ V28 迁移 │ ← 无依赖，可立即执行
|
||
│ (done) │
|
||
└────┬─────┘
|
||
│ depends_on
|
||
▼
|
||
┌──────────┐
|
||
│ TaskRepo │
|
||
│ 扩展(todo) │
|
||
└──┬────┬──┘
|
||
│ │
|
||
▼ ▼
|
||
┌─────────┐ ┌──────────┐
|
||
│ IPC 封装 │ │ AI 工具 │
|
||
│(blocked)│ │ 注册(todo) │ ← 被 V28 阻塞（虚线 blocks）
|
||
└────┬────┘ └──────────┘
|
||
│
|
||
▼
|
||
┌─────────┐
|
||
│Board.vue │
|
||
│ (todo) │
|
||
└─────────┘
|
||
```
|
||
|
||
**节点视觉**：
|
||
- 状态颜色：todo=灰 / in_progress=蓝 / in_review=黄 / testing=橙 / done=绿 / blocked=红
|
||
- 父任务=大圆角矩形，子任务=小圆角矩形，用虚线框分组
|
||
- depends_on=实线箭头 → / blocks=红色虚线箭头 ⇢ / relates_to=灰色点线 ⋯
|
||
|
||
**布局算法**：
|
||
- 拓扑排序分层（Sugiyama / 简化版：按依赖深度分层）
|
||
- 同层节点水平排列
|
||
- 父子关系用虚线框圈住
|
||
|
||
**交互**：
|
||
- 点击节点 → 高亮该节点的所有依赖链（上游+下游路径加粗）
|
||
- 双击节点 → 跳转 TaskDetail
|
||
- 悬停节点 → 显示 tooltip（标题/状态/阻塞原因）
|
||
- 右键节点 → 快捷操作（推进/解除阻塞/编辑依赖）
|
||
- 顶部工具栏：仅看阻塞链 / 仅看关键路径 / 按项目着色
|
||
|
||
**关键路径标注**：拓扑排序后，从入度=0 的节点到出度=0 的节点的最长路径，用粗线标注。
|
||
|
||
**数据量控制**：
|
||
- 默认只渲染 active + todo + blocked 的任务（隐藏 done/cancelled）
|
||
- 超过 30 个节点时提示"节点过多，请按项目筛选"
|
||
- 支持按项目过滤
|
||
|
||
#### 10.3.4 时间线（TimelineView）— 时间维度
|
||
|
||
两种模式：
|
||
|
||
**模式 A：甘特图（横向时间轴）**
|
||
|
||
```
|
||
06-24 06-25 06-26 06-27 06-28 06-29 06-30
|
||
V28迁移 ████████←done
|
||
TaskRepo ████████←in_progress 70%
|
||
IPC封装 ██████←blocked(等V28)
|
||
Board.vue ░░░░░░←todo(未开始)
|
||
AI工具注册 ░░░░░░←todo
|
||
```
|
||
|
||
- 横轴=日期（created_at → 预估完成 / 实际 updated_at）
|
||
- 每行一个任务，条形颜色=状态色
|
||
- blocked 段叠加红色斜纹
|
||
- 父任务行展开显示子任务
|
||
|
||
**模式 B：事件流（纵向时间轴）**
|
||
|
||
```
|
||
今天 06-26
|
||
│
|
||
├─ 14:30 ✅ V28 迁移完成 DevFlow
|
||
├─ 13:15 🔨 TaskRepo 扩展开始 DevFlow
|
||
├─ 11:00 🚫 IPC 封装被阻塞 DevFlow ← 红色高亮
|
||
│ 原因：等待 V28 迁移完成
|
||
├─ 09:45 💡 创建需求"队列看板" DevFlow
|
||
│
|
||
昨天 06-25
|
||
│
|
||
├─ 22:10 ✅ B-27 审批状态统一 DevFlow
|
||
├─ 18:30 🔨 V28 迁移开始 DevFlow
|
||
...
|
||
```
|
||
|
||
- 来源：project_events 表
|
||
- 事件类型图标 + 颜色区分
|
||
- blocked/decision 事件**红色高亮**
|
||
- 按天分组，可折叠
|
||
- 支持按项目/事件类型筛选
|
||
- 无限滚动加载
|
||
|
||
**切换**：顶部 Toggle 切换甘特/事件流两种模式。
|
||
|
||
#### 10.3.5 阻塞面板（BlockedView）— 卡点
|
||
|
||
**这是最重要的视图** —— 回答"哪里卡住了、为什么、阻塞了谁"。
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 🚫 阻塞任务 (2) │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ 🔴 IPC 层封装 DevFlow · P1 │
|
||
│ 状态: blocked ← 3 天 │
|
||
│ 阻塞原因: 等待 V28 迁移完成 │
|
||
│ 阻塞了谁: ↓ │
|
||
│ └─ Board.vue 看板视图 (todo，无法开始) │
|
||
│ └─ AI 工具注册 (todo，无法开始) │
|
||
│ 连锁影响: 2 个下游任务被阻塞 │
|
||
│ [解除阻塞] [查看详情] │
|
||
│ │
|
||
│ 🔴 API 协议选型 u-ask · P0 │
|
||
│ 状态: blocked ← 7 天 ⚠️ 长时间阻塞 │
|
||
│ 阻塞原因: 需要确认 REST vs GraphQL │
|
||
│ 阻塞了谁: ↓ │
|
||
│ └─ 后端 API 重构 (todo) │
|
||
│ └─ 前端适配 (todo) │
|
||
│ 连锁影响: 3 个下游任务被阻塞 │
|
||
│ [解除阻塞] [查看详情] │
|
||
│ │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ ⚠️ 待决策 (1) │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ❓ 缓存策略选型 workpod · P2 │
|
||
│ 队列: decision ← 2 天 │
|
||
│ 决策内容: Redis vs 本地缓存 │
|
||
│ 阻塞了谁: ↓ │
|
||
│ └─ 缓存模块实现 (backlog) │
|
||
│ [做出决策] [查看详情] │
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
**数据来源**：
|
||
- `tasks WHERE status = 'blocked'` → 阻塞任务列表
|
||
- `task_links WHERE target_id = :blocked_task_id AND link_type = 'depends_on'` → 查谁被它阻塞
|
||
- `tasks WHERE queue = 'decision'` → 待决策列表
|
||
- BFS 遍历依赖链计算"连锁影响数"（下游被间接阻塞的任务总数）
|
||
|
||
**关键视觉**：
|
||
- 阻塞时间 > 3 天 → 黄色警告标记
|
||
- 阻塞时间 > 7 天 → 红色闪烁标记 + 置顶
|
||
- 连锁影响 > 3 → 加粗影响数
|
||
- 每个阻塞项可展开"阻塞链"树形图
|
||
|
||
**排序策略**：
|
||
1. 连锁影响数降序（阻塞越多越优先处理）
|
||
2. 阻塞时间降序（越久越紧急）
|
||
3. 优先级降序
|
||
|
||
### 10.4 公共筛选器（侧栏）
|
||
|
||
所有视图共享的筛选维度：
|
||
|
||
```
|
||
┌──────────────────────┐
|
||
│ 🔍 筛选 │
|
||
│ │
|
||
│ 项目 │
|
||
│ ☑ DevFlow │
|
||
│ ☑ u-ask │
|
||
│ ☐ u-img │
|
||
│ ☑ workpod │
|
||
│ │
|
||
│ 优先级 │
|
||
│ ☑ P0 紧急 │
|
||
│ ☑ P1 高 │
|
||
│ ☑ P2 中 │
|
||
│ ☐ P3 低 │
|
||
│ │
|
||
│ 负责人 │
|
||
│ [全部 ▾] │
|
||
│ │
|
||
│ 隐藏已完成 │
|
||
│ [开关] │
|
||
│ │
|
||
│ 仅看阻塞链 │
|
||
│ [开关] │
|
||
└──────────────────────┘
|
||
```
|
||
|
||
### 10.5 后端 API 设计
|
||
|
||
| IPC Command | 用途 | 参数 |
|
||
|-------------|------|------|
|
||
| `get_mission_kanban` | 看板视图数据（按 queue 分组） | project_ids?, priority? |
|
||
| `get_mission_matrix` | 热力矩阵数据（project × status 交叉统计） | project_ids? |
|
||
| `get_mission_dag` | DAG 依赖图数据（节点+边） | project_ids?, include_done? |
|
||
| `get_mission_timeline` | 时间线数据（事件流 or 甘特图） | project_ids?, date_from?, date_to?, mode |
|
||
| `get_mission_blocked` | 阻塞面板数据（含连锁影响计算） | project_ids? |
|
||
|
||
**性能考虑**：
|
||
- 任务量级 ~50-200（桌面应用单用户），全量查询无压力
|
||
- DAG 连锁影响用 Rust BFS 遍历，不走 SQL 递归
|
||
- 时间线分页加载（每次 50 条事件）
|
||
- 矩阵统计用 SQL `GROUP BY project_id, status` 一次查询
|
||
|
||
### 10.6 AI 消费场景
|
||
|
||
这些视图的数据结构同时也是 AI 的上下文：
|
||
|
||
| AI 场景 | 数据来源 | 对应视图 |
|
||
|---------|---------|---------|
|
||
| "项目进展如何？" | get_mission_matrix | 热力矩阵 |
|
||
| "有什么卡住了？" | get_mission_blocked | 阻塞面板 |
|
||
| "下一步做什么？" | get_mission_dag（拓扑排序入度=0 的 todo 任务） | 依赖图 |
|
||
| "上周做了什么？" | get_mission_timeline（事件流） | 时间线 |
|
||
| "这个需求拆得对不对？" | get_task_tree + get_mission_dag | 看板 + 依赖图 |
|
||
|
||
**AI 自动排查阻塞**：当 get_project_context 返回 blocked_tasks 非空时，AI 可主动在对话中提示"检测到 2 个任务被阻塞，是否需要排查？"并附带阻塞链摘要。
|
||
|
||
### 10.7 实现优先级
|
||
|
||
| 优先级 | 视图 | 理由 |
|
||
|--------|------|------|
|
||
| **P0** | 阻塞面板 | 最高价值：一眼看卡点，当前完全缺失 |
|
||
| **P0** | 看板视图 | 核心交互：queue 流动可视化 |
|
||
| **P1** | 热力矩阵 | 全局分布：跨项目状态一览 |
|
||
| **P1** | 时间线（事件流模式） | 追溯能力：做了什么/何时做的 |
|
||
| **P2** | 依赖图（DAG） | 编排可视化：需要 task_links 先落地 |
|
||
| **P2** | 时间线（甘特图模式） | 锦上添花：需要预估完成时间字段 |
|
||
|
||
**P0 可独立先做**：阻塞面板 + 看板视图只需要 tasks 表的 queue/status 字段（Phase 1），不依赖 task_links（依赖图才需要）。
|
||
|
||
---
|
||
|
||
## 十一、边界与风险
|
||
|
||
### 10.1 已识别风险
|
||
|
||
| 风险 | 影响 | 缓解 |
|
||
|------|------|------|
|
||
| queue 与 status 一致性 | 两个字段可能不同步 | IPC 层强制校验约束规则 |
|
||
| 父任务聚合性能 | 子任务变化触发父重算 | 项目内任务量小（~50），实时计算无压力 |
|
||
| 事件流写入失败 | 埋点失败影响事件完整性 | 事件写入失败不阻断主操作（best-effort） |
|
||
| get_project_context 体积 | 大项目上下文可能超 token 预算 | 分级注入 L0/L1/L2 |
|
||
| task_links 循环依赖 | 死锁 | BFS 检测 + 拒绝创建 |
|
||
|
||
### 10.2 不做的事
|
||
|
||
- ❌ 不做无限嵌套任务树（限制 1 级）
|
||
- ❌ 不做凭证存储/管理（安全边界外）
|
||
- ❌ 不做事件流回填（历史数据不补事件，从上线时间点开始记录）
|
||
- ❌ 不做前端拖拽排序的 sort_order（queue 内排序按 priority + created_at）
|
||
- ❌ 不做看板的 WIP 限制（列宽限制，过度设计）
|