# devflow-core 抽取设计（云化阶段2）

> 任务 711e1390 · 2026-10-22 · 勘察依据：workspace 9 个 crate Cargo.toml 实测

## 一、现状 crate 依赖图（实测）

```
                    df-types (零依赖: serde/thiserror/chrono/uuid)
                   ┌────┴──────────────────────┐
              df-ai-core                   df-workflow
          (零tauri, trait层)          (DAG/条件引擎, 仅依赖df-types)
                   │                             │
              df-storage ←──df-ai─────┐     df-nodes ──┐
        (rusqlite+keyring,      (reqwest流式)  (聚合5crate) │
         依赖df-types/df-ai-core)     │              │
                   └──────┬───────────┴──────────────┘
                          ▼
                     src-tauri (Tauri 壳, 68 IPC commands)

  隧道链: df-tunnel(出站WS) → df-relay(云端中继镜像) → df-im-gateway(IM适配)
  工具链: df-execute(零依赖) / df-mcp / df-ideas / df-project(依赖df-types)
```

## 二、核心发现：devflow-core 已基本存在，无需「抽取」只需「收口」

关键事实：**UI 无关的 crate 已经全部独立**——df-types/df-ai-core/df-workflow/df-storage/df-ai/df-nodes/df-project/df-execute/df-tunnel 均零 tauri 依赖，tauri 只在 src-tauri 壳层。昨天的「抽取」假设（需要从 8-crate 里剥离 UI 耦合）不成立，工作量大幅下降。

## 三、设计（三步收口，非重构）

### S1. 虚拟 target：workspace 内定义 `devflow-core` 集合（0.5 天）
不建新 crate，先以约定划界：`crates/df-{types,ai-core,workflow,storage,ai,nodes,project,execute}` = core 集合。云端服务直接 path 依赖这组 crate。**零代码改动**。

### S2. 存储层 trait 化（2-3 天，唯一实质改造）
- 现状：df-storage 直用 rusqlite（bundled），SQL 内嵌
- 改造：定义 `StorageProvider` trait（项目/任务/工作流/知识 CRUD 切面），SQLite 为默认实现；PostgreSQL 实现放独立 `df-storage-pg`（feature-gated，云端服务才编译）
- 保留双库分歧模式（devflow.db / devflow-dev.db 的 cfg! 分支语义）
- 风险：rusqlite 与 sqlx-tokio-postgres 的异步模型差异 → trait 方法全部 async（workspace 已有 async-trait）

### S3. AI Provider 双模式（1 天）
- df-ai/df-ai-core 已是 trait 层（reqwest 直连，key 本机）——天然支持云端托管：新增 `RemoteProvider` 实现（key 由 df-cloud-server 下发），编译期 feature 切换，个人版行为零变更

### 云端落地形态（阶段2 末期）
- `df-cloud-server`：新 crate（或独立仓），path 依赖 core 集合 + df-storage-pg，Axum/actix 暴露 HTTP+WS，部署同主机 Nginx 后
- 复用 df-tunnel 协议与 u-relay 管道层，拓扑不变

## 四、迁移步骤

1. S1 约定划界 + `cargo check` 全绿验证（不动代码）
2. S2 StorageProvider trait 引入，SQLite 实现先行，桌面端切到 trait 调用（行为零变更，IPC 68 commands 不动）
3. df-storage-pg 新 crate + 集成测试（本地 docker postgres）
4. S3 RemoteProvider feature
5. df-cloud-server 骨架（healthz + 只读任务查询先行）

## 五、风险 Top3

| 风险 | 缓解 |
|---|---|
| rusqlite 同步 API vs PG 异步驱动的 trait 撕裂 | trait 全 async + SQLite 实现内 spawn_blocking |
| df-storage 依赖 df-ai-core（ModelConfig 反序列化）造成边界混杂 | 接受（同属 core 集合，不跨集合） |
| 与阶段1 联调互踩 src-tauri | S2 改动收敛在 df-storage 内部 + 调用方，分批提交攒批 |

## 六、工作量总估

S1 0.5d + S2 2-3d + S3 1d + cloud-server 骨架 1-2d ≈ **5-7 天**（远低于原「抽取重构」预期）。