文档: 设计文档入库与构建配套收尾

- 云化两设计文档入库(devflow-core 抽取三步收口/云化架构 html) - 看板销账: T1-T4 逐件附验收 - D4 工具 schema 空 description 清理(渐进披露配套,~10KB/轮) - 换装脚本验证修复: 安装后装机 exe 版本核对,防 NSIS 静默失败误报成功 - capabilities/锁文件随批
2026-10-26 01:36:55 +08:00
parent d97cbb4439
commit 070223baa5
7 changed files with 236 additions and 15 deletions
@@ -0,0 +1,64 @@
+# 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 天**（远低于原「抽取重构」预期）。