lxy
070223baa5
- 云化两设计文档入库(devflow-core 抽取三步收口/云化架构 html) - 看板销账: T1-T4 逐件附验收 - D4 工具 schema 空 description 清理(渐进披露配套,~10KB/轮) - 换装脚本验证修复: 安装后装机 exe 版本核对,防 NSIS 静默失败误报成功 - capabilities/锁文件随批
65 lines
3.8 KiB
Markdown
65 lines
3.8 KiB
Markdown
# 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 天**（远低于原「抽取重构」预期）。
|