新增: 初始化 DevFlow 项目仓库

Tauri 2 + Vue 3 + Vite 6 桌面应用，Rust workspace 含 13 个 crate (df-ai / df-storage / df-workflow / df-core / df-execute 等)。核心能力：AI 聊天 agentic 循环(工具调用+人工审批)、工作流引擎、任务/想法/项目/阶段管理、可追溯性，及配套前端组件。
2026-06-12 01:31:05 +08:00
commit 98393b4908
178 changed files with 27859 additions and 0 deletions
--- a/docs/02-架构设计/Phase1架构决策.md
+++ b/docs/02-架构设计/Phase1架构决策.md
@@ -0,0 +1,46 @@
+# Phase 1 架构决策
+
+> 创建: 2026-06-10 | 状态: 初稿
+
+---
+
+## 概述
+
+Phase 1 是 DevFlow 的引擎骨架阶段，聚焦于核心数据流打通。本文记录此阶段的关键架构决策。
+
+## 决策记录
+
+### ADR-001: 引擎不绑定业务
+
+- **决策**: Workflow Engine (df-workflow) 只做 DAG 执行，不感知具体业务语义
+- **原因**: 保持引擎通用性，阶段逻辑通过 df-stages 插件化注入
+- **影响**: df-workflow 的 Node trait 是纯接口，业务逻辑在 df-nodes / df-stages 实现
+
+### ADR-002: 本地优先架构
+
+- **决策**: 使用 SQLite 嵌入式数据库，不依赖云服务
+- **原因**: DevFlow 定位为桌面工具，零运维，离线可用
+- **影响**: 无网络层、无认证系统，数据全部本地存储
+
+### ADR-003: 多 Crate Workspace
+
+- **决策**: 拆分为 13 个独立 crate
+- **原因**: 模块解耦、独立编译、按需引用
+- **影响**: 依赖关系需严格管控，避免循环依赖
+
+### ADR-004: 无 panic 原则
+
+- **决策**: 所有占位代码返回空/默认值，不使用 `todo!`/`unimplemented!`
+- **原因**: 保证应用不会因为未实现功能而崩溃
+- **影响**: 未实现的方法返回 `Ok(default)` 而非 panic
+
+### ADR-005: Phase 1 最小可用路径
+
+- **决策**: 优先打通 `df-core → df-workflow → df-storage → Tauri IPC → Vue` 链路
+- **原因**: 验证架构可行性，尽早发现集成问题
+- **影响**: Phase 1 不实现 AI、想法池、多项目等高级功能
+
+## 参考文档
+
+- `ARCHITECTURE.md` — 完整架构设计
+- `PROGRESS.md` — 当前进度与全局性问题
--- a/docs/02-架构设计/业务系统设计.md
+++ b/docs/02-架构设计/业务系统设计.md
@@ -0,0 +1,349 @@
+# DevFlow 业务系统设计
+
+> 创建: 2026-06-10 | 状态: 设计中 | 基于: 功能审查结论
+
+---
+
+## 一、产品定位
+
+| 维度 | 定义 |
+|------|------|
+| **一句话** | AI 原生的产研操作系统，从想法到上线的全流程编排 |
+| **目标用户** | 个人开发者优先，后续扩展到小团队 |
+| **核心价值** | 全流程编排 — 想法池 → 项目 → 任务 → 工作流 → 发布，AI 贯穿每个环节 |
+| **差异化** | 想法第一公民 + AI 全程参与 + 本地优先（零运维） |
+
+---
+
+## 二、用户旅程设计
+
+### 2.1 核心旅程
+
+```
+💡 想法池                    📂 项目                    🔀 任务                  🚀 发布
+─────────────────────────────────────────────────────────────────────────────────────
+捕捉想法 ──→ AI评估评分 ──→ 晋升立项 ──→ 创建任务 ──→ 绑定分支 ──→ 执行工作流 ──→ 合并发布
+               │                              │            │            │           │
+               └── 淘汰/归档                   └── 多任务   └── DAG     └── AI辅助  └── 自动化
+                                               并行推进     自动执行    冲突解决     发布流程
+```
+
+### 2.2 五个阶段详细设计
+
+#### 阶段一：💡 想法池 (Idea Pool)
+
+**用户场景**：开发者日常产生大量想法（看到新技术、遇到痛点、产生产品灵感），需要一个地方快速捕捉、评估、筛选。
+
+| 操作 | 描述 | AI 参与 |
+|------|------|---------|
+| **捕捉** | 文本输入、快捷键快速记录、剪贴板导入 | 无 |
+| **评估** | AI 分析可行性、市场潜力、技术难度 | ⭐ 核心场景：LLM 评估报告 |
+| **评分** | 多维打分 (可行性/影响力/紧迫性) | AI 给出建议分 |
+| **关联** | 相似想法自动发现，可合并 | AI 语义相似度 |
+| **晋升** | 高分想法晋升为项目 | AI 生成项目初始化建议 |
+| **淘汰** | 低分想法归档或删除 | 无 |
+
+**状态机**：
+```
+Draft → Evaluating → Scored → Approved → Promoted
+                                → Rejected → Archived
+```
+
+**关键问题**：
+- ✅ 想法是独立于项目的第一公民，不需要先有项目
+- ✅ AI 评估是核心差异化功能
+- ⚠️ 评分维度需要与实际对齐（当前有3套不同的维度定义）
+
+#### 阶段二：📂 项目 (Project)
+
+**用户场景**：从想法晋升或手动创建项目，管理项目全生命周期。
+
+| 操作 | 描述 | AI 参与 |
+|------|------|---------|
+| **创建** | 从想法晋升 或 手动创建 | AI 生成项目描述/技术栈建议 |
+| **阶段管理** | 5阶段管线：想法→需求→编码→测试→发布 | 阶段推进时 AI 检查前置条件 |
+| **上下文** | 项目代码结构、依赖、规范 | AI 自动分析项目结构 |
+| **暂停/恢复** | 项目可暂停后恢复 | 无 |
+
+**状态机**：
+```
+Planning → InProgress → Testing → Releasing → Completed
+         → Paused → InProgress (恢复)
+         → Cancelled
+```
+
+**阶段管线**（current_stage，独立于 status）：
+```
+Idea → Requirement → Coding → Testing → Release
+```
+
+**关键问题**：
+- ⚠️ 当前 `status`（项目生命周期）和 `current_stage`（当前阶段）是两个维度，前端混用了
+- ⚠️ 数据库 projects 表缺少 `current_stage`、`repo_path`、`priority`、`tags` 字段
+
+#### 阶段三：🔀 任务 (Task)
+
+**用户场景**：项目内创建多个并行任务，每个任务绑定一个 Git 分支，独立工作流。
+
+| 操作 | 描述 | AI 参与 |
+|------|------|---------|
+| **创建任务** | 标题+描述，自动创建分支 | AI 从需求拆解任务 |
+| **绑定分支** | 每个任务一个独立分支 | 自动生成分支名 |
+| **执行工作流** | 触发 DAG 工作流（编码→测试→审查） | AI 参与每个节点 |
+| **审查** | 代码审查、质量检查 | AI 自动审查 |
+| **合并** | 合并到主分支，冲突解决 | AI 辅助冲突解决 |
+
+**状态机**：
+```
+Todo → InProgress → InReview → Testing → Done
+                    → Blocked → InProgress (解除阻塞)
+                    → Cancelled
+```
+
+**关键问题**：
+- ⚠️ 缺少 `branches` 表，分支信息无法持久化
+- ⚠️ 任务到工作流的关联 (`workflow_def_id`) 缺失
+- ⚠️ 前端 TaskStatus 有 4 套不同的值
+
+#### 阶段四：⚙️ 工作流 (Workflow)
+
+**用户场景**：DAG 驱动的工作流自动执行，支持条件分支、并行、人工审批。
+
+| 组件 | 描述 |
+|------|------|
+| **DAG 定义** | 可序列化的节点+边定义，持久化到 SQLite |
+| **节点类型** | Script / AI / Docker / Git / HTTP / Human / Notify / Subflow |
+| **执行器** | 按拓扑层并行执行，支持暂停/恢复 |
+| **事件总线** | 实时推送节点状态到前端 |
+| **NodeRegistry** | 根据类型字符串动态创建节点实例 |
+
+**工作流执行生命周期**：
+```
+Pending → Running → Completed
+                → Paused → Running (恢复)
+                → Failed → Running (重试)
+                → Cancelled
+```
+
+**关键问题**：
+- ✅ DAG 拓扑排序算法正确
+- ✅ DagDef/NodeRegistry 已实现
+- ⚠️ Executor 同层节点尚未并行化
+- ⚠️ 条件分支引擎未实现
+- ⚠️ HumanNode（人工审批）暂停/恢复未连通
+
+#### 阶段五：🚀 发布 (Release)
+
+**用户场景**：选择多个已完成任务，编排发布流程。
+
+| 操作 | 描述 | AI 参与 |
+|------|------|---------|
+| **选择任务** | 选择要发布的 Done 状态任务 | 无 |
+| **创建发布** | 合并分支到 release 分支 | AI 生成 changelog |
+| **集成测试** | 运行完整测试工作流 | 自动 |
+| **发布** | 部署 + 健康检查 | 自动 |
+| **回滚** | 发布失败回滚 | AI 分析失败原因 |
+
+**状态机**：
+```
+Planning → Integrating → Testing → Ready → Published
+                                         → RolledBack
+                     → Cancelled
+```
+
+**关键问题**：
+- ⚠️ 前端完全缺少发布入口
+- ⚠️ releases 表缺少 `branch_name`、`workflow_def_id`
+
+---
+
+## 三、跨领域功能设计
+
+### 3.1 标注系统 (Annotation)
+
+**设计理念**：任何内容（代码/文档/需求/测试报告）都可插入标注，统一收集后交给 AI 批量处理。
+
+| 标记 | 含义 | AI 处理方式 |
+|------|------|-----------|
+| FIXME | 需要修复 | AI 定位问题并生成修复建议 |
+| TODO | 待办 | AI 拆解为任务 |
+| QUESTION | 疑问 | AI 尝试回答 |
+| RISK | 风险 | AI 评估风险等级 |
+| DECISION | 决策 | 自动记录到决策日志 |
+| OPTIMIZE | 优化 | AI 给出优化方案 |
+
+**批量处理流程**：
+```
+收集所有 Open 标注 → 按类型分组 → AI 逐条处理 → 标记为 Resolved
+```
+
+### 3.2 决策留痕 (Decision Journal)
+
+**设计理念**：所有关键决策自动或半自动记录，全程可追溯。
+
+**自动记录的决策场景**：
+- 想法评估结果（为什么批准/拒绝）
+- 功能标记为"不做"时（为什么不做）
+- AI 选择了方案 A 而非方案 B 时
+- 代码审查中发现风险时的处理决策
+- 发布前的检查点决策
+
+### 3.3 经验进化 (Evolution)
+
+**设计理念**：开发过程自动沉淀知识，越用越聪明。
+
+| 知识类型 | 来源 | 复用场景 |
+|---------|------|---------|
+| 审查规则 | 代码审查结论 | 后续审查自动应用 |
+| Prompt 模板 | 成功的 AI 对话 | 类似场景复用 |
+| 踩坑经验 | 错误修复过程 | 遇到类似问题时提醒 |
+| 架构模式 | 项目结构分析 | 新项目初始化建议 |
+
+### 3.4 AI 编排
+
+**多模型策略**：
+```
+任务类型 → ModelRouter → 最优模型
+  代码生成     → Claude/GPT-4
+  代码审查     → Claude (长上下文)
+  文档生成     → GLM/DeepSeek (性价比)
+  快速问答     → DeepSeek (低成本)
+```
+
+**Agent 协作模式**（Phase 2+）：
+```
+Planner Agent → 拆解任务
+Coder Agent   → 编码实现
+Reviewer Agent → 代码审查
+Fixer Agent   → 修复问题
+```
+
+---
+
+## 四、数据模型设计（按阶段）
+
+### Phase 1 最小表集（当前 + 补全）
+
+| 表 | 用途 | 状态 |
+|----|------|------|
+| ideas | 想法池 | ✅ 已有，需补字段 |
+| projects | 项目管理 | ✅ 已有，需补字段 |
+| tasks | 任务管理 | ✅ 已有，需补字段 |
+| releases | 发布管理 | ✅ 已有，需补字段 |
+| workflow_defs | 工作流定义 | ❌ 缺失 |
+| workflow_executions | 工作流执行 | ✅ 已有，需补字段 |
+| node_executions | 节点执行记录 | ✅ 已有 |
+| branches | 分支管理 | ❌ 缺失 |
+
+### Phase 2 扩展表
+
+| 表 | 用途 |
+|----|------|
+| ai_providers | AI 模型配置 |
+| connections | 连接配置 |
+| artifacts | 产出物 |
+
+### Phase 3+ 完整表
+
+| 表 | 用途 |
+|----|------|
+| annotations | 标注系统 |
+| decisions | 决策留痕 |
+| features | 需求功能清单 |
+| test_cases | 测试用例 |
+| test_runs | 测试执行记录 |
+| knowledge | 经验知识库 |
+| merge_requests | 合并请求 |
+
+---
+
+## 五、关键设计决策
+
+### D1: 想法是第一公民
+- 想法池独立于项目，可以独立运转
+- 想法不需要关联项目即可被评估和打分
+- 晋升是单向操作（想法→项目），但保留追溯
+
+### D2: 多任务/分支并行
+- 同一项目内多个任务同时开发
+- 每个任务绑定独立 Git 分支
+- 任务间互不干扰，完成后合并
+
+### D3: 引擎不绑定业务
+- DAG 引擎纯粹做编排，不知道"想法"/"项目"等概念
+- 阶段是 DAG 模板，可自定义
+- 节点通过 Node trait 扩展
+
+### D4: 本地优先
+- SQLite 嵌入，不依赖云服务
+- 所有数据存储在本地
+- 零运维，安装即用
+
+### D5: AI 贯穿全程
+- 不是"加了 AI 功能"，而是"AI 是系统的一部分"
+- 每个阶段都有 AI 参与
+- AI 输出作为决策依据，最终决策权在人
+
+### D6: 决策必留痕
+- 所有关键决策自动记录
+- 决策可追溯到具体上下文（哪个想法、哪个功能、哪次审查）
+- 未来可回溯"为什么这么做"
+
+---
+
+## 六、审查发现的设计问题与决策
+
+| # | 问题 | 设计决策 | 优先级 |
+|---|------|---------|--------|
+| 1 | 状态枚举三套不一致 | **以 types.rs 为准**，ARCHITECTURE.md 和 SQL 同步 | Phase 1 |
+| 2 | projects 缺 status vs stage | **status 和 current_stage 分开**：status 管生命周期，stage 管进度 | Phase 1 |
+| 3 | ideas.promoted_to 缺失 | **V2 补字段**，晋升时回写 | Phase 1 |
+| 4 | branches 表不存在 | **V2 新增表**，分支管理需要持久化 | Phase 1 |
+| 5 | workflow_executions 缺 project_id | **V2 补字段**，执行记录必须关联业务 | Phase 1 |
+| 6 | DAG 不可序列化 | **DagDef/Dag 分离**（已完成） | Phase 1 |
+| 7 | Executor 串行 | **同层并行化**（待实现） | Phase 1 |
+| 8 | 前端 id 类型不对 | **统一为 string (UUID)** | Phase 1 |
+| 9 | Store 未接入 View | **先建 API 层再接 Store** | Phase 1 |
+| 10 | 标注/决策表缺失 | Phase 3 再建表，当前 UI 标注 "Coming Soon" | Phase 3 |
+| 11 | 需求-测试追溯 | Phase 4 再建表 | Phase 4 |
+| 12 | 经验进化 | Phase 5 实现 | Phase 5 |
+
+---
+
+## 七、MVP 验证场景
+
+**Phase 1 目标**：跑通"创建想法 → 晋升项目 → 创建任务 → 执行 3 节点工作流 → 查看结果"
+
+```
+1. 用户在想法池输入"做一个 Markdown 编辑器"
+2. AI 评估可行性，给出评分和建议
+3. 用户点击"晋升为项目"
+4. 系统创建项目，进入编码阶段
+5. 用户创建任务"实现基础编辑功能"
+6. 系统创建分支 task/abc123
+7. 用户点击"运行工作流"
+8. DAG 执行: [Shell: 环境检查] → [Shell: 运行测试] → [Shell: 构建产物]
+9. 前端实时展示执行日志
+10. 执行完成，结果持久化到 SQLite
+11. 用户刷新页面，数据仍在
+```
+
+---
+
+## 八、已确认的设计决策
+
+### Q1: 想法评分维度 ✅ 已确认
+**决策**：采用 C 方案 — 可行性/影响力/紧迫性 + 综合分 (3+1 维)
+- 与 `evaluator.rs` 已实现的 `EvalDimension` 对齐
+- `IdeaScores { feasibility, impact, urgency, overall }` 保留
+
+### Q2: 发布模块 Phase 1 范围 ✅ 已确认
+**决策**：Phase 1 简化 — 只做 Release 记录 + 手动标记任务
+- releases 表保留，支持 CRUD
+- 不做自动化发布流程（合并→测试→部署）
+- 前端在 ProjectDetail 中添加简单 Release 面板
+
+### Q3: AI 评估 Phase 1 范围 ✅ 已确认
+**决策**：Phase 1 用固定算法评分，延后接入 AI
+- `ScoringEngine` 当前返回固定 5.0，改为基于启发式规则的简单算法
+- Phase 2 接入 LLM 后替换为 AI 评分
--- a/docs/02-架构设计/产品定位调整.md
+++ b/docs/02-架构设计/产品定位调整.md
@@ -0,0 +1,145 @@
+# 产品定位调整报告
+
+> 从"想法到代码"到"想法到创作"的升级转型
+
+## 📊 背景分析
+
+### 原定位的问题
+- 过于狭窄：只面向开发者
+- 竞争激烈：代码工具市场已饱和
+- 限制场景：无法满足多元化的创作需求
+
+### 新定位的优势
+- **普适性强**：覆盖所有创作者
+- **场景多样**：技术、商业、教育、创意
+- **价值更大**：从单一工具到创作平台
+
+## 🎯 新产品定位
+
+### 核心价值主张
+**"从想法到创作成果的全流程管理平台"**
+
+### 目标用户画像
+| 用户类型 | 创作内容 | 使用场景 |
+|---------|---------|---------|
+| **开发者** | 代码、技术文档 | 项目开发、技术分享 |
+| **产品经理** | 需求文档、原型方案 | 产品规划、项目提案 |
+| **设计师** | 设计方案、创意文档 | 设计展示、概念提案 |
+| **研究者** | 学术论文、分析报告 | 研究、报告撰写 |
+| **内容创作者** | 博客、课程、培训 | 知识分享、教育 |
+
+### 核心功能矩阵
+
+| 功能模块 | 代码创作 | 文档创作 | 演示创作 | 内容创作 |
+|---------|---------|---------|---------|---------|
+| **想法池** | ✓ | ✓ | ✓ | ✓ |
+| **对抗评估** | ✓ | ✓ | ✓ | ✓ |
+| **任务管理** | ✓ | ✓ | ✓ | ✓ |
+| **工作流引擎** | ✓ | ✓ | ✓ | ✓ |
+| **模板系统** | ✓ | ✓ | ✓ | ✓ |
+| **协作功能** | ✓ | ✓ | ✓ | ✓ |
+
+## 🔄 功能升级规划
+
+### Phase 1: 基础创作支持
+- [x] 代码创作（现有）
+- [ ] Markdown 文档编辑器
+- [ ] PPT 演示文稿生成器
+- [ ] 文档模板库
+
+### Phase 2: 智能创作辅助
+- [ ] AI 内容生成
+- [ ] 自动格式化
+- [ ] 多格式导出
+- [ ] 版本管理
+
+### Phase 3: 创作生态
+- [ ] 创作市场
+- [ ] 团队协作
+- [ ] 知识库集成
+- [ ] 发布平台
+
+## 📈 产品差异化
+
+### 竞争优势
+1. **全流程覆盖**：从想法到发布
+2. **对抗式评估**：独特的质量控制机制
+3. **本地优先**：数据安全、隐私保护
+4. **跨平台支持**：桌面端 + Web 端
+
+### 差异化场景
+- **学术研究**：论文写作 + 代码实现
+- **产品设计**：需求文档 + 原型设计
+- **技术培训**：课程内容 + 示例代码
+- **创意策划**：概念方案 + 可视化展示
+
+## 🎨 视觉识别调整
+
+### 品牌口号
+- **原**："本地优先的开发流程工具"
+- **新**："创意工作流的私人助手"
+
+### 颜色系统
+保持现有的紫色系作为主色，增加：
+- 橙色：创意和活力
+- 绿色：成长和产出
+- 蓝色：专业和可靠
+
+### 图标体系
+- 🧠 思维导图
+- ✍️ 创作工具
+- 📊 产出展示
+- 🚀 发布分享
+
+## 📋 实施计划
+
+### 短期（1个月）
+- 更新文档和营销材料
+- 完成文档创作基础功能
+- 发布 V2.0 版本
+
+### 中期（3个月）
+- 完成演示文稿生成器
+- 实现模板系统
+- 上线创作市场 Beta
+
+### 长期（6个月）
+- 建立创作者生态
+- 集成协作功能
+- 考虑 SaaS 服务
+
+## 🎯 成功指标
+
+### 用户增长
+- 月活跃用户：1000+
+- 创作者留存率：>60%
+- 日均创作次数：>3/用户
+
+### 内容质量
+- 作品发布率：>40%
+- 用户满意度：>4.5/5
+- 重复使用率：>50%
+
+### 业务指标
+- 付费转化率：>5%
+- 平均客单价：$50
+- 年营收目标：$100K
+
+## 🔮 未来展望
+
+### 5年愿景
+成为**创作者的首选工作平台**，连接想法与世界的桥梁。
+
+### 技术演进
+- AI 驱动的智能创作
+- 虚拟现实创作空间
+- 区块链确权和版权保护
+
+### 社会价值
+- 降低创作门槛
+- 促进知识分享
+- 支持创意经济
+
+---
+
+**总结**：从"想法到代码"到"想法到创作"不是功能减少，而是价值升级。我们不再局限于技术工具，而是成为所有创作者的伙伴。
--- a/docs/02-架构设计/前后端类型对齐.md
+++ b/docs/02-架构设计/前后端类型对齐.md
@@ -0,0 +1,82 @@
+# 前后端类型对齐
+
+> 创建: 2026-06-10 | 状态: 初稿
+
+---
+
+## 概述
+
+DevFlow 前端 (TypeScript) 和后端 (Rust) 通过 Tauri IPC 和 JSON 序列化通信。两侧的类型定义必须保持一致。
+
+## 类型映射
+
+### 基础类型
+
+| Rust | TypeScript | 说明 |
+|------|-----------|------|
+| `String` | `string` | 文本字段 |
+| `i64` | `number` | 时间戳 (Unix timestamp) |
+| `Option<String>` | `string \| null` | 可空字段 |
+| `Vec<String>` | `string[]` | 数组 (JSON 序列化) |
+| `bool` | `boolean` | 布尔值 |
+
+### ID 类型
+
+| 实体 | Rust | TypeScript | 格式 |
+|------|------|-----------|------|
+| 所有 ID | `String` | `string` | UUID v4 |
+
+所有 ID 统一使用 UUID v4 字符串，便于前后端传递。
+
+### 枚举对齐
+
+#### IdeaStatus (8 值)
+
+| Rust | TypeScript |
+|------|-----------|
+| `Draft` | `"Draft"` |
+| `Evaluating` | `"Evaluating"` |
+| `Scored` | `"Scored"` |
+| `Hot` | `"Hot"` |
+| `Promoted` | `"Promoted"` |
+| `Parked` | `"Parked"` |
+| `Merged` | `"Merged"` |
+| `Discarded` | `"Discarded"` |
+
+#### TaskStatus (6 值)
+
+| Rust | TypeScript |
+|------|-----------|
+| `Created` | `"Created"` |
+| `BranchCreated` | `"BranchCreated"` |
+| `InProgress` | `"InProgress"` |
+| `ReviewReady` | `"ReviewReady"` |
+| `Merged` | `"Merged"` |
+| `Abandoned` | `"Abandoned"` |
+
+#### WorkflowRunStatus (6 值)
+
+| Rust | TypeScript |
+|------|-----------|
+| `Pending` | `"Pending"` |
+| `Running` | `"Running"` |
+| `Paused` | `"Paused"` |
+| `Completed` | `"Completed"` |
+| `Failed` | `"Failed"` |
+| `Cancelled` | `"Cancelled"` |
+
+#### ProjectStatus (4 值)
+
+| Rust | TypeScript |
+|------|-----------|
+| `Active` | `"Active"` |
+| `Paused` | `"Paused"` |
+| `Completed` | `"Completed"` |
+| `Archived` | `"Archived"` |
+
+## 约定
+
+1. 枚举值使用 PascalCase 字符串，前后端保持一致
+2. JSON 字段（如 `scores`、`tags`）在 Rust 侧用 `TEXT` 存储 JSON 字符串，前端解析为对象/数组
+3. 时间字段统一用 `i64` (Unix timestamp)，前端用 `new Date(ts * 1000)` 转换
+4. 新增枚举值时，Rust 和 TypeScript 两侧必须同步更新
--- a/docs/02-架构设计/对抗论证裁决报告.md
+++ b/docs/02-架构设计/对抗论证裁决报告.md
@@ -0,0 +1,143 @@
+# DevFlow 对抗论证裁决报告
+
+> 创建: 2026-06-11 | 方法: 三路对抗论证（市场/技术/需求） | 结论: 方向有价值，scope 必须砍
+
+---
+
+## 一、论证方法
+
+用"魔法打败魔法"：三个独立 AI 代理分别从不同立场攻击这个项目，互不可见，最后综合裁决。
+
+| 代理 | 立场 | 综合评分 |
+|------|------|---------|
+| 市场分析师 | 竞品全景 + 市场数据（带外部信源） | **4/10 — 不建议以当前形态推进** |
+| 技术架构师 | 13 crate / Tauri / 引擎 / AI 可行性 | **2.7/5 — 可行但必须砍 scope** |
+| 恶魔代言人 | 逐功能质疑需求真实性 | **核心成立，60% 功能该砍** |
+
+---
+
+## 二、三方共识（站不住脚的地方）
+
+### 共识 1：🔴 Scope 失控是最大风险
+
+- 8 个核心功能横跨 4-5 个产品类别（PM + 工作流 + AI 编排 + 代码分析 + 知识库）
+- 22,745 字架构文档、16 张表、13 crate —— **这是操作系统的野心，不是 MVP 的规划**
+- 现实工时：v1.0 全功能需全职 8-12 个月 / 业余 1.5-2 年
+- 历史教训：Firebase/Heroku/全生命周期 API 平台都被"组件化组合"打败
+
+### 共识 2：🔴 身份危机 — 无法一句话说清
+
+- Cursor = "AI 编辑器"，Linear = "快的 issue 追踪器"，DevFlow = ？
+- "全流程"不是定位，是定位的缺失
+
+### 共识 3：🔴 部分功能是伪需求（对个人开发者）
+
+| 功能 | 需求方评分 | 市场方评分 | 裁决 |
+|------|-----------|-----------|------|
+| 插件系统 (WASM) | 1/5 | — | **砍掉**（为 0 个用户设计生态） |
+| 经验进化（自动沉淀） | 1/5 | 3/10 | **砍掉**（技术上无法落地，连骨架都是空的） |
+| 需求-测试追溯 | 1/5 | — | **砍掉**（企业需求硬塞给个人） |
+| 多模型路由 + Agent 协作 | — | 4/10 | **砍掉**（OpenClaw/大厂赛道，无法竞争） |
+| 想法池（完整版） | 2/5 | 2/10 | **降级**（简化为列表+对抗式评估） |
+| 决策留痕（独立子系统） | 2/5 | 4/10 | **降级**（字段级方案，不建独立体系） |
+
+### 共识 4：🟡 AI 信任危机的时代背景
+
+- Stack Overflow 2025：开发者对 AI 信任度从 40% 跌至 29%
+- 66% 开发者花更多时间修复 AI 的"差不多对"代码
+- **定位必须从"AI 帮你做事"转向"AI 帮你控制流程"**——AI 是副驾驶，不是自动驾驶
+
+---
+
+## 三、三方冲突点的调和
+
+### 冲突 1：DAG 工作流引擎
+
+- 需求方：**5/5 必须有**（产品的灵魂，本地工作流有空白）
+- 市场方：**2/10 伪需求**（GitHub Actions 已免费解决）
+
+**裁决**：两者都对，但说的是不同的东西。
+- GitHub Actions 解决的是 **仓库内 CI/CD**（push 触发、云端跑）
+- DevFlow 的空隙是 **本地的、跨项目的、AI 参与的交互式流程**（不依赖 push、可以有人工审批节点、能调用本地资源）
+- **保留 DAG 引擎，但作为内部基础设施，不作为对外卖点**。用户看到的是"一键执行编码→审查→测试流程"，而不是"DAG 编辑器"
+
+### 冲突 2：标注系统
+
+- 需求方：**1/5 砍掉**（IDE 已解决）
+- 市场方：**6.5/10 全场最高差异化机会**（"扫描代码库 FIXME/TODO → AI 批量处理 → 关联任务"是真空地带）
+
+**裁决**：需求方批的是"在文档/测试报告上加标注"的重模式（确实没人用）；市场方挺的是"代码库 TODO 扫描器 + AI 处理"的轻模式。
+- **采用轻模式**：扫描代码 TODO/FIXME → 汇总 → AI 生成处理建议 → 一键转任务
+- 砍掉"任意实体标注"的重设计
+
+---
+
+## 四、站得住脚的部分
+
+1. **本地优先** — Obsidian 证明了本地优先工具有大市场，订阅疲劳（52% 用户因此退订）反推一次性付费
+2. **Tauri 技术栈** — 比 Electron 小 96%，选型正确（4/5）
+3. **引擎代码质量** — 拓扑排序算法正确、trait 设计合理、依赖树无环
+4. **任务绑 Git 分支** — 6/10，最有价值的业务功能，做深"任务→分支→提交→合并→关单"全链路有空间
+5. **对抗式想法评估** — 这是本次论证方法本身的产品化，市场上没有工具这么做
+
+---
+
+## 五、调整方案
+
+### 5.1 产品定位调整
+
+**旧**：AI 原生的产研操作系统，从想法到上线的全流程编排（❌ 无法一句话说清）
+
+**新**：**本地优先的个人开发流程驾驶舱 — 把想法、任务、分支和 AI 流程放进一个不联网也能跑的桌面应用**
+
+一句话版本：「你的项目流程，本地跑，AI 辅助，数据不出门」
+
+### 5.2 功能调整清单
+
+| 功能 | 原计划 | 调整后 |
+|------|--------|--------|
+| DAG 工作流引擎 | 对外核心卖点 | ✅ 保留为内部引擎，UI 上呈现为"流程模板一键执行" |
+| 任务+分支 | 一般功能 | ✅ **升级为核心**：任务→分支→工作流→合并全链路 |
+| 想法池 | 完整漏斗系统 | ⬇️ 简化：列表 + **对抗式评估**（正方/反方/分析师三路论证，差异化卖点） |
+| 标注系统 | 任意实体标注 | ⬇️ 简化：代码库 TODO/FIXME 扫描器 + AI 批处理 |
+| 决策留痕 | 独立子系统 | ⬇️ 降级：关键操作自动写决策字段，无独立 UI |
+| AI 编排 | 多模型路由+四 Agent | ⬇️ 砍：单 Provider (Claude) + AI 节点，无 Agent 协作 |
+| 阶段插件 | 5 阶段 | ⬇️ 3 个内置流程模板（编码/测试/发布） |
+| 8 种节点 | 全部实现 | ⬇️ Phase 1 只做 Shell/AI/Subflow，Git 用 Shell 调 CLI |
+| 需求-测试追溯 | 完整体系 | ❌ 砍掉（v2.0 团队版再说） |
+| 经验进化 | 自动沉淀引擎 | ❌ 砍掉（降为手动 Snippet 收藏，Phase 5 再议） |
+| 插件系统 | WASM/动态加载 | ❌ 砍掉（v2.0 再说） |
+
+**砍掉比例：约 60%，与三方建议一致。**
+
+### 5.3 架构调整
+
+- **13 crate 保留目录结构**（已建好，删除反而费工），但 Phase 1 只激活 6 个：
+  `df-core / df-workflow / df-storage / df-execute / df-nodes / src-tauri`
+- 其余 7 个 crate 标记为 `[预留]`，从 workspace 默认构建中保留但不再投入开发
+- Git 操作走 Shell CLI，不引入 libgit2（技术报告建议，省 1-2 周）
+
+### 5.4 Phase 重排
+
+| Phase | 旧目标 | 新目标 |
+|-------|--------|--------|
+| 1 | 引擎骨架（含一切基础） | **跑通一条 Shell→AI→Shell 工作流 + 任务/分支 CRUD + 前端真数据** |
+| 2 | AI 集成（多模型） | Claude 单 Provider + AI 节点 + 想法对抗式评估 |
+| 3 | 想法池+多项目 | TODO 扫描器 + 3 个流程模板 |
+| 4 | 节点丰富+阶段插件 | 任务→分支→合并全链路（Git 深度集成） |
+| 5 | 体验打磨 v1.0 | 打磨 + 自用验证 3 个月 → 决定是否对外 |
+
+### 5.5 验证策略调整
+
+市场报告的最重要建议：**先验证再深投**。
+- DevFlow 首先是**自用工具**（管理 wk-* 工作空间的真实项目）
+- 自用 3 个月，记录每天真实打开次数
+- 如果自己都不用，停止投入；如果离不开它，再考虑对外
+
+---
+
+## 六、裁决结论
+
+> **方向有价值，形态要收敛。** "本地优先 + 任务分支驱动 + AI 辅助流程"是真空隙；"全流程操作系统"是幻觉。砍掉 60% 的功能不是失败，是论证的胜利——它们本来会消耗 6-9 个月却没人用。
+>
+> 同时，本次论证方法本身（三路对抗）被产品化为想法池的"对抗式评估"功能，详见 `docs/03-模块文档/想法探索-对抗式评估.md`。这是 DevFlow 吃自己的狗粮的第一个案例。