Files

T

- 云化两设计文档入库(devflow-core 抽取三步收口/云化架构 html)
- 看板销账: T1-T4 逐件附验收
- D4 工具 schema 空 description 清理(渐进披露配套,~10KB/轮)
- 换装脚本验证修复: 安装后装机 exe 版本核对,防 NSIS 静默失败误报成功
- capabilities/锁文件随批

2026-10-26 01:36:55 +08:00

3.8 KiB

Raw Blame History

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 管道层，拓扑不变

四、迁移步骤

S1 约定划界 + cargo check 全绿验证（不动代码）
S2 StorageProvider trait 引入，SQLite 实现先行，桌面端切到 trait 调用（行为零变更，IPC 68 commands 不动）
df-storage-pg 新 crate + 集成测试（本地 docker postgres）
S3 RemoteProvider feature
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 天（远低于原「抽取重构」预期）。

3.8 KiB Raw Blame History Unescape Escape