新增: 文档(任务推进链实施路径+任务模块分析+审查报告+patch_file指南)

docs/02-架构设计/Phase1架构决策-2026-06-12.md

@@ -13,8 +13,9 @@ Phase 1 是 DevFlow 的引擎骨架阶段，聚焦于核心数据流打通。本
 ### ADR-001: 引擎不绑定业务
 
 - **决策**: Workflow Engine (df-workflow) 只做 DAG 执行，不感知具体业务语义
-- **原因**: 保持引擎通用性，阶段逻辑通过 df-stages 插件化注入
-- **影响**: df-workflow 的 Node trait 是纯接口，业务逻辑在 df-nodes / df-stages 实现
+- **原因**: 保持引擎通用性
+- **影响**: df-workflow 的 Node trait 是纯接口，业务逻辑在 df-nodes 实现
+> ⚠️ 原文写"阶段逻辑通过 df-stages 插件化注入"、"业务逻辑在 df-nodes / df-stages 实现"。`df-stages` crate 已删除（零引用清理），实际无 stages 层。业务逻辑直接在 df-nodes 的 3 个节点实现。
 
 ### ADR-002: 本地优先架构
 
@@ -24,9 +25,10 @@ Phase 1 是 DevFlow 的引擎骨架阶段，聚焦于核心数据流打通。本
 
 ### ADR-003: 多 Crate Workspace
 
-- **决策**: 拆分为 13 个独立 crate
+- **决策**: 拆分为多个独立 crate
 - **原因**: 模块解耦、独立编译、按需引用
 - **影响**: 依赖关系需严格管控，避免循环依赖
+> ⚠️ 原文写"13 个独立 crate"，属过时数字（原始设计值）。实际为 **8 个 crate**：df-core / df-workflow / df-nodes / df-ai / df-execute / df-storage / df-ideas / df-project。详见 [业务系统设计](./业务系统设计-2026-06-12.md) §六。
 
 ### ADR-004: 无 panic 原则
 

docs/02-架构设计/aichat交互体验改进方案-2026-06-14.md

@@ -1,6 +1,6 @@
 # AIChat 交互体验改进方案
 
-> 创建: 2025-07-15 | 状态: 待讨论
+> 创建: 2026-06-14 | 状态: 待讨论
 > 范围: 消息发送、流式渲染、对话管理、错误恢复、技能/Provider、窗口布局等非授权类交互
 
 ---

docs/02-架构设计/aichat审查报告-2026-06-14.md

@@ -2,6 +2,7 @@
 
 > 性质:只审查不改代码。本报告汇总本次会话对 devflow AI chat 全链路的核对发现。
 > 增补:2026-06-14 追加「修复进度」表（AC1/AC2、AR-3、FR-S4、FR-R4、FR-R5 对照 commit 36d68dd / 4b5f096 标已完成），并在 §8 优先级表 AR-3 行内联标注。
+> 二次增补:2026-06-15 §8 优先级表全表对齐 todo.md AR 编号体系，逐行补 AR-1~AR-11 标签 + 状态勾注（AR-1 退役 / AR-2~7/9~11 已修 / AR-8 重评降级）。
 
 ## 审查范围
 
@@ -216,17 +217,17 @@ handler 接上后 `bind_directory` 使用频率大降(只剩改绑),第二章 bi
 
 | 优先 | 问题 | 方向 |
 |------|------|------|
-| P0 | H1 流式 Markdown 重解析 | 流式态纯文本/增量渲染,完成后再 markdown;rAF 合并 |
-| P0 | H2 审批态新建对话卡死 | `ai_conversation_create` 加 generating 守卫 |
-| P0 | 第二章 审批卡片裸 id + reason 模板（✅ 已完成 commit 36d68dd / AR-3）| 后端 reason 拼对象名;前端 id→name |
-| P0 | 第四章 create_project 双审(⚠️ 半成品:schema 已加 handler 没接) | handler 读 args 的 path/stack,复用 IPC `project.rs:43-83` 探测逻辑 |
-| P1 | H3 审批态 stop 无兜底 | stopChat 本地先复位 streaming |
-| P1 | M3 Low 工具失败语义 | 统一 AiError 后 loop 也退出,或不 emit AiError |
-| P1 | 第三章 clean 无入口 | AiChat 加清空按钮 + 后端真删当前对话消息 |
-| P2 | M1+M2 delta 节流 + 滚动 | 后端 50ms 合批 / 前端 rAF |
-| P2 | M4 friendlyError i18n | 抽 i18n key |
-| P2 | 第六章 灵感迁移残留 | i18n + 后端错误 + LLM 描述统一改 |
-| P2 | 第五章 数据联动 | 方案 A 后端 emit + store 监听 |
+| P0 | H1 流式 Markdown 重解析 ✅ **退役**（AR-1，2026-06-15）— 自研块级 memo 取代（splitBlocks O(末块)+rAF 节流），详见 [流式渲染调研 §5](./aichat流式Markdown渲染调研-2026-06-15.md) | 流式态纯文本/增量渲染,完成后再 markdown;rAF 合并 |
+| P0 | H2 审批态新建对话卡死 ✅ **已修**（AR-2，commit 057a212） | `ai_conversation_create` 加 generating 守卫 |
+| P0 | 第二章 审批卡片裸 id + reason 模板 ✅ **已修**（AR-3，commit 36d68dd）| 后端 reason 拼对象名;前端 id→name |
+| P0 | 第四章 create_project 双审 ✅ **已修**（AR-4，commit 057a212）— schema 加 path/stack + handler 合并绑定 | handler 读 args 的 path/stack,复用 IPC `project.rs:43-83` 探测逻辑 |
+| P1 | H3 审批态 stop 无兜底 ✅ **已修**（AR-5，commit 9e2aeff）— stopChat 本地先复位 streaming + clearStreamWatchdog | stopChat 本地先复位 streaming |
+| P1 | M3 Low 工具失败语义 ✅ **已修**（AR-6，commit f82dd8b）— Low 失败非 AiError，错误回填 tool_result 让 LLM 自处理 | 统一 AiError 后 loop 也退出,或不 emit AiError |
+| P1 | 第三章 clean 无入口 ✅ **已修**（AR-7，commit 9e2aeff）— clear_messages 真删 + 垃桶按钮二次确认 | AiChat 加清空按钮 + 后端真删当前对话消息 |
+| P2 | M1+M2 delta 节流 + 滚动 🔄 **重评降级**（AR-8，2026-06-15）— 前端 rAF 节流已被 ARC-08 覆盖；剩后端 50ms 合批 + 滚动跟随 | 后端 50ms 合批 / 前端 rAF |
+| P2 | M4 friendlyError i18n ✅ **已修**（AR-9，commit 9e2aeff）— 全走 i18n.global.t + zh/en 双语补 key | 抽 i18n key |
+| P2 | 第六章 灵感迁移残留 ✅ **已修**（AR-10，commit 65c475b）— 13 文件批量统一 | i18n + 后端错误 + LLM 描述统一改 |
+| P2 | 第五章 数据联动 ✅ **已修**（AR-11，commit dc27e79）— 方案 A 后端 emit `df-data-changed` + store listen 已 attach | 方案 A 后端 emit + store 监听 |
 
 ---
 

docs/02-架构设计/aichat授权体验改进方案-2026-06-14.md

@@ -1,6 +1,6 @@
 # AIChat 授权功能体验改进方案
 
-> 创建: 2025-07-15 | 状态: 待讨论
+> 创建: 2026-06-14 | 状态: 待讨论
 
 ## 一、当前授权机制概览
 
@@ -24,7 +24,7 @@
 | 风险等级 | 工具 | 执行方式 |
 |---------|------|---------|
 | **Low** | `list_projects`, `list_tasks`, `list_ideas`, `list_trash`, `read_file`, `list_directory` | 自动执行，并行 `join_all` |
-| **Medium** | `create_project`, `create_task`, `create_idea`, `update_project`, `update_task`, `bind_directory`, `write_file` | 需人工审批 |
+| Medium | `create_project`, `create_task`, `create_idea`, `update_project`, `update_task`, `bind_directory`, `write_file` | 需人工审批 |
 | **High** | `delete_project`, `restore_project`, `purge_project`, `delete_task`, `run_workflow`, `run_command` | 需人工审批 |
 
 ### 1.3 已实现的亮点
@@ -181,26 +181,28 @@
 
 ### P1 — 增强控制力
 
-#### 3.4 自动审批策略（信任模式）
+#### 3.4 会话级授权 Session Trust
 
-**方案**：Settings 中增加"自动审批"配置，用户可选择对特定风险等级或工具类型自动放行。
+**方案**：引入会话级信任机制，替代全局宽松模式。用户在当前对话中一次性授权某目录的写/执行权限，后续该对话内同类操作自动放行。切换对话或新建对话时信任清空。
 
 **配置项**：
 ```
-Settings → AI → 自动审批策略
-  ○ 严格模式（默认）：所有 Medium/High 需人工审批
-  ○ 宽松模式：Medium 自动放行，High 需人工审批
-  ○ 自定义：按工具类型选择
-      ☑ write_file（workspace 内自动放行）
-      ☑ create_task / create_idea（自动放行）
-      ☐ delete_*（始终需审批）
-      ☐ run_command（始终需审批）
+当前会话信任目录:
+  ✅ E:/wk-lab/devflow/src  (Write + Execute)
+  ✅ E:/wk-lab/devflow/docs  (Write)
+  + 添加目录...
 ```
 
 **改动范围**：
-- `df-storage`：`app_settings` 表存储配置（KV 已有 V13 表）
-- `audit.rs`：`process_tool_calls` 读取配置，决定 Medium 工具是否进 pending 或直接执行
-- `Settings.vue`：新增配置面板
+- 前端：Settings 或对话 header 新增「信任管理」入口
+- 后端：`AiSession` 增加 `trusted_dirs: HashSet<(PathBuf, TrustLevel)>`
+- `audit.rs`：`process_tool_calls` 先查 session trust，命中则跳过 pending
+
+**安全边界**：
+- 仅纯读取操作（list_*/read_*/list_directory）保持自动放行
+- 所有 create/update/bind/write/delete 操作默认需审批或 session-trust
+- bind_directory 归类为修改操作
+- 信任仅限当前会话内存，不持久化
 
 #### 3.5 High 二次确认
 
@@ -221,13 +223,13 @@ Settings → AI → 自动审批策略
   → 才真正执行 ai_approve
 ```
 
-#### 3.6 审批超时
+#### 3.6 审批超时（前端定时器）
 
-**方案**：可配置超时自动拒绝（默认 5 分钟），避免对话永久卡住。
+**方案**：前端侧 5 分钟超时自动拒绝，避免对话永久卡住。超时策略独立于 Webhook 等外部动作路径。
 
 **改动范围**：
-- 后端：`AiSession` 增加 pending 审批的 `created_at` 时间戳，定时检查超时
-- 或前端：`useAiSend.ts` 在 pending 时启动定时器，超时自动调 `ai_approve(id, false)`
+- 前端：`useAiSend.ts` 在 pending 时启动 5min 定时器，超时自动调 `ai_approve(id, false)`
+- 不改后端 AiSession 结构（远期 Webhook 走独立路径）
 
 ---
 
@@ -252,7 +254,7 @@ Settings → AI → 自动审批策略
 └──────────────────────────────────┘
 ```
 
-#### 3.8 审批历史面板
+#### 3.8 审计历史面板
 
 **方案**：独立页面展示 `ai_tool_executions` 表的审计记录。
 
@@ -262,7 +264,7 @@ Settings → AI → 自动审批策略
 
 **展示字段**：
 | 时间 | 工具 | 风险 | 状态 | 决策者 | 参数摘要 | 结果摘要 |
-|------|------|------|------|--------|---------|---------|
+|------|------|------|------|--------|---------|----------|
 
 ---
 
@@ -273,10 +275,10 @@ Settings → AI → 自动审批策略
 | **P0** | 3.1 批量审批 | 0.5 天 | 🔥🔥🔥 |
 | **P0** | 3.2 审批计数器 + 跳转 | 0.5 天 | 🔥🔥🔥 |
 | **P0** | 3.3 write_file diff 预览 | 1 天 | 🔥🔥 |
-| **P1** | 3.4 自动审批策略 | 1.5 天 | 🔥🔥🔥 |
+| **P1** | 3.4 会话级授权 Session Trust | 1.5 天 | 🔥🔥🔥 |
 | **P1** | 3.5 High 二次确认 | 0.5 天 | 🔥 |
-| **P1** | 3.6 审批超时 | 0.5 天 | 🔥 |
+| **P1** | 3.6 审批超时(前端5min) | 0.5 天 | 🔥 |
 | **P2** | 3.7 Agentic 进度条 | 0.5 天 | 🔥🔥 |
-| **P2** | 3.8 审批历史面板 | 1 天 | 🔥 |
+| **P2** | 3.8 审计历史面板 | 1 天 | 🔥 |
 
 **建议第一批落地**：P0 三项（批量审批 + 计数器 + diff 预览），总计约 2 天工作量，覆盖最高频的体验痛点。

docs/02-架构设计/业务系统设计-2026-06-12.md

@@ -1,6 +1,8 @@
 # DevFlow 业务系统设计
 
-> 创建: 2026-06-10 | 状态: 设计中 | 基于: 功能审查结论
+> 创建: 2026-06-10 | 状态: 设计中 | 最后重写: 2026-06-15 (DOC-01 硬伤修复)
+>
+> **本文档为 ARCHITECTURE.md 的实质载体**（项目无独立 ARCHITECTURE.md 文件）。所有数据模型、设计决策均以源码为基准，已剔除虚构内容。
 
 ---
 
@@ -8,9 +10,9 @@
 
 | 维度 | 定义 |
 |------|------|
-| **一句话** | AI 原生的产研操作系统，从想法到上线的全流程编排 |
-| **目标用户** | 个人开发者优先，后续扩展到小团队 |
-| **核心价值** | 全流程编排 — 想法池 → 项目 → 任务 → 工作流 → 发布，AI 贯穿每个环节 |
+| **一句话** | AI 原生的个人开发流程驾驶舱，从想法到任务到工作流的本地工具 |
+| **目标用户** | 个人开发者 |
+| **核心价值** | 想法池 → 项目 → 任务 → 工作流（DAG），AI 贯穿每个环节 |
 | **差异化** | 想法第一公民 + AI 全程参与 + 本地优先（零运维） |
 
 ---
@@ -20,240 +22,176 @@
 ### 2.1 核心旅程
 
 ```
-💡 想法池                    📂 项目                    🔀 任务                  🚀 发布
-─────────────────────────────────────────────────────────────────────────────────────
-捕捉想法 ──→ AI评估评分 ──→ 晋升立项 ──→ 创建任务 ──→ 绑定分支 ──→ 执行工作流 ──→ 合并发布
-               │                              │            │            │           │
-               └── 淘汰/归档                   └── 多任务   └── DAG     └── AI辅助  └── 自动化
-                                               并行推进     自动执行    冲突解决     发布流程
+想法池                    项目                      任务                   工作流
+────────────────────────────────────────────────────────────────────────────
+捕捉想法 → 评估评分 → 晋升立项 → 创建任务 → 绑定分支 → 执行 DAG 工作流
+              │                     │         │           │
+              └── 淘汰/归档          └── 多任务  └── 自动执行  └── Script/Ai/Human
 ```
 
-### 2.2 五个阶段详细设计
+### 2.2 四个阶段详细设计
 
-#### 阶段一：💡 想法池 (Idea Pool)
+#### 阶段一：想法池 (Idea Pool)
 
-**用户场景**：开发者日常产生大量想法（看到新技术、遇到痛点、产生产品灵感），需要一个地方快速捕捉、评估、筛选。
+**用户场景**：快速捕捉想法、评估、筛选。
 
 | 操作 | 描述 | AI 参与 |
 |------|------|---------|
-| **捕捉** | 文本输入、快捷键快速记录、剪贴板导入 | 无 |
-| **评估** | AI 分析可行性、市场潜力、技术难度 | ⭐ 核心场景：LLM 评估报告 |
-| **评分** | 多维打分 (可行性/影响力/紧迫性) | AI 给出建议分 |
-| **关联** | 相似想法自动发现，可合并 | AI 语义相似度 |
+| **捕捉** | 文本输入 | 无 |
+| **评估** | 启发式评分（可行性/影响力/紧迫性） | 当前固定算法，Phase 2 接 LLM |
 | **晋升** | 高分想法晋升为项目 | AI 生成项目初始化建议 |
 | **淘汰** | 低分想法归档或删除 | 无 |
 
-**状态机**：
+**状态机**（对齐 `IdeaStatus` 枚举）：
 ```
-Draft → Evaluating → Scored → Approved → Promoted
-                                → Rejected → Archived
+draft → pending_review → approved → promoted（正向）
+                     → rejected → archived（淘汰）
 ```
 
-**关键问题**：
-- ✅ 想法是独立于项目的第一公民，不需要先有项目
-- ✅ AI 评估是核心差异化功能
-- ⚠️ 评分维度需要与实际对齐（当前有3套不同的维度定义）
-
-#### 阶段二：📂 项目 (Project)
-
-**用户场景**：从想法晋升或手动创建项目，管理项目全生命周期。
+#### 阶段二：项目 (Project)
 
 | 操作 | 描述 | AI 参与 |
 |------|------|---------|
-| **创建** | 从想法晋升 或 手动创建 | AI 生成项目描述/技术栈建议 |
-| **阶段管理** | 5阶段管线：想法→需求→编码→测试→发布 | 阶段推进时 AI 检查前置条件 |
-| **上下文** | 项目代码结构、依赖、规范 | AI 自动分析项目结构 |
-| **暂停/恢复** | 项目可暂停后恢复 | 无 |
+| **创建** | 从想法晋升 或 手动创建 | AI 生成描述/技术栈建议 |
+| **绑定目录** | 关联本地代码目录（自动探测技术栈） | 无 |
+| **软删/恢复** | 回收站机制（deleted_at） | 无 |
 
-**状态机**：
+**状态机**（对齐 `ProjectStatus` 枚举）：
 ```
-Planning → InProgress → Testing → Releasing → Completed
-         → Paused → InProgress (恢复)
-         → Cancelled
+planning → in_progress → testing → releasing → completed
+        → paused → in_progress（恢复）
+        → cancelled
 ```
 
-**阶段管线**（current_stage，独立于 status）：
-```
-Idea → Requirement → Coding → Testing → Release
-```
-
-**关键问题**：
-- ⚠️ 当前 `status`（项目生命周期）和 `current_stage`（当前阶段）是两个维度，前端混用了
-- ⚠️ 数据库 projects 表缺少 `current_stage`、`repo_path`、`priority`、`tags` 字段
-
-#### 阶段三：🔀 任务 (Task)
-
-**用户场景**：项目内创建多个并行任务，每个任务绑定一个 Git 分支，独立工作流。
+#### 阶段三：任务 (Task)
 
 | 操作 | 描述 | AI 参与 |
 |------|------|---------|
-| **创建任务** | 标题+描述，自动创建分支 | AI 从需求拆解任务 |
-| **绑定分支** | 每个任务一个独立分支 | 自动生成分支名 |
-| **执行工作流** | 触发 DAG 工作流（编码→测试→审查） | AI 参与每个节点 |
-| **审查** | 代码审查、质量检查 | AI 自动审查 |
-| **合并** | 合并到主分支，冲突解决 | AI 辅助冲突解决 |
+| **创建任务** | 标题+描述 | AI 从需求拆解任务 |
+| **执行工作流** | 触发 DAG 工作流 | AI 参与每个 Ai 节点 |
 
-**状态机**：
+**状态机**（对齐 `TaskStatus` 枚举，7 态）：
 ```
-Todo → InProgress → InReview → Testing → Done
-                    → Blocked → InProgress (解除阻塞)
-                    → Cancelled
+todo → in_progress → in_review → testing → done
+                  → blocked → in_progress（解除阻塞）
+                  → cancelled
 ```
 
-**关键问题**：
-- ⚠️ 缺少 `branches` 表，分支信息无法持久化
-- ⚠️ 任务到工作流的关联 (`workflow_def_id`) 缺失
-- ⚠️ 前端 TaskStatus 有 4 套不同的值
+#### 阶段四：工作流 (Workflow)
 
-#### 阶段四：⚙️ 工作流 (Workflow)
+**实际内置 3 种节点类型**（均在 `crates/df-nodes/src/` 完整实现）：
 
-**用户场景**：DAG 驱动的工作流自动执行，支持条件分支、并行、人工审批。
+| 节点 | 文件 | 作用 | 阻塞 |
+|------|------|------|------|
+| **Script** | `script_node.rs` | Shell 命令执行（经 `df-execute::shell`） | 否 |
+| **Ai** | `ai_node.rs` | LLM 文本生成/分析（非流式 complete） | 否 |
+| **Human** | `human_node.rs` | 人工审批/确认（单选/多选） | 是 |
 
-| 组件 | 描述 |
-|------|------|
-| **DAG 定义** | 可序列化的节点+边定义，持久化到 SQLite |
-| **节点类型** | Script / AI / Docker / Git / HTTP / Human / Notify / Subflow |
-| **执行器** | 按拓扑层并行执行，支持暂停/恢复 |
-| **事件总线** | 实时推送节点状态到前端 |
-| **NodeRegistry** | 根据类型字符串动态创建节点实例 |
+> 不存在 Condition / Parallel / Docker / Git / Notify / HTTP / Subflow 节点。
+> 条件分支由工作流引擎层处理（条件表达式引擎见 `条件表达式引擎-2026-06-15.md`）。
 
 **工作流执行生命周期**：
 ```
-Pending → Running → Completed
-                → Paused → Running (恢复)
-                → Failed → Running (重试)
-                → Cancelled
+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)
+### 3.1 知识库 (Knowledge)
 
-**设计理念**：任何内容（代码/文档/需求/测试报告）都可插入标注，统一收集后交给 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)
-
-**设计理念**：开发过程自动沉淀知识，越用越聪明。
+Tier1 AI 提炼：从 AI 对话中自动提炼候选经验条目，附带 reasoning 判断依据。
 
 | 知识类型 | 来源 | 复用场景 |
 |---------|------|---------|
-| 审查规则 | 代码审查结论 | 后续审查自动应用 |
+| 审查规则 | 代码审查结论 | 后续审查参考 |
 | Prompt 模板 | 成功的 AI 对话 | 类似场景复用 |
-| 踩坑经验 | 错误修复过程 | 遇到类似问题时提醒 |
-| 架构模式 | 项目结构分析 | 新项目初始化建议 |
+| 踩坑经验 | 错误修复过程 | 类似问题提醒 |
 
-### 3.4 AI 编排
+**生命线**：candidate → pending_review → published → archived，带 reuse_count / verified 信号。
 
-**多模型策略**：
-```
-任务类型 → ModelRouter → 最优模型
-  代码生成     → Claude/GPT-4
-  代码审查     → Claude (长上下文)
-  文档生成     → GLM/DeepSeek (性价比)
-  快速问答     → DeepSeek (低成本)
-```
+### 3.2 AI 多 Provider
 
-**Agent 协作模式**（Phase 2+）：
-```
-Planner Agent → 拆解任务
-Coder Agent   → 编码实现
-Reviewer Agent → 代码审查
-Fixer Agent   → 修复问题
-```
+支持配置多个 AI 提供商（OpenAI 兼容 / GLM / DeepSeek / Anthropic 原生协议），可在设置中管理并指定默认。
+
+详见 [df-ai AI集成模块](../03-模块文档/df-ai-AI集成模块-2026-06-12.md)。
+
+### 3.3 EventBus 事件总线
+
+进程内 `tokio::sync::broadcast` 发布/订阅，前端经 `@tauri-apps/api/event` 的 emit/listen 接收。**不是 WebSocket**。
 
 ---
 
-## 四、数据模型设计（按阶段）
+## ~~三、跨领域功能设计（已废弃规划）~~
 
-### Phase 1 最小表集（当前 + 补全）
+> 以下章节曾详述标注系统、决策留痕、经验进化、AI 编排（ModelRouter/Agent 协作）等设计。
+> 这些功能**从未实现**，对应表（annotations/decisions/features/test_cases）也从未建表。
+> 保留此节仅作历史存档参考，读者应视为"规划意图"而非"现有能力"。
 
-| 表 | 用途 | 状态 |
-|----|------|------|
-| ideas | 想法池 | ✅ 已有，需补字段 |
-| projects | 项目管理 | ✅ 已有，需补字段 |
-| tasks | 任务管理 | ✅ 已有，需补字段 |
-| releases | 发布管理 | ✅ 已有，需补字段 |
-| workflow_defs | 工作流定义 | ❌ 缺失 |
-| workflow_executions | 工作流执行 | ✅ 已有，需补字段 |
-| node_executions | 节点执行记录 | ✅ 已有 |
-| branches | 分支管理 | ❌ 缺失 |
+### ~~3.1 标注系统 (Annotation)~~ — ❌ 未实现
 
-### Phase 2 扩展表
+### ~~3.2 决策留痕 (Decision Journal)~~ — ❌ 未实现
 
-| 表 | 用途 |
-|----|------|
-| ai_providers | AI 模型配置 |
-| connections | 连接配置 |
-| artifacts | 产出物 |
+### ~~3.3 经验进化 (Evolution)~~ — ⚠️ 部分落地为知识库（knowledges 表），但远不及原规划规模
 
-### Phase 3+ 完整表
+### ~~3.4 AI 编排（ModelRouter / Agent 协作）~~ — ❌ ModelRouter 从未存在；Agent 协作属 Phase 2 规划（B 路线）
 
-| 表 | 用途 |
-|----|------|
-| annotations | 标注系统 |
-| decisions | 决策留痕 |
-| features | 需求功能清单 |
-| test_cases | 测试用例 |
-| test_runs | 测试执行记录 |
-| knowledge | 经验知识库 |
-| merge_requests | 合并请求 |
+---
+
+## 四、数据模型设计（V1-V13 迁移实际表）
+
+> 核对基准：`crates/df-storage/src/migrations.rs` 建表 SQL + `models.rs` Record 结构体。
+
+### 全量表清单（13 业务表 + 1 元表）
+
+#### 活跃业务表（11 张）— 有上层代码读写
+
+| # | 表名 | 建表版本 | 用途 | 对应 Model | 活跃消费者 |
+|---|------|---------|------|-----------|-----------|
+| 1 | `ideas` | V1+V2 | 想法池 | IdeaRecord | df-ideas crate |
+| 2 | `projects` | V1+V11+V12 | 项目管理 | ProjectRecord | df-project crate |
+| 3 | `tasks` | V1+V2 | 任务管理 | TaskRecord | commands::task（IPC handler 直连 CRUD） |
+| 4 | `workflow_executions` | V1+V2 | 工作流执行实例 | WorkflowRecord | df-workflow crate |
+| 5 | `node_executions` | V1 | 节点执行审计 | NodeExecutionRecord | df-workflow executor |
+| 6 | `ai_conversations` | V3+V4/V5/V6 | AI 对话历史 | AiConversationRecord | commands::ai |
+| 7 | `ai_providers` | V9 | AI 提供商配置 | AiProviderRecord | commands::ai::provider |
+| 8 | `ai_tool_executions` | V9 | AI 工具调用审计 | AiToolExecutionRecord | commands::ai |
+| 9 | `knowledges` | V7+V8/V10 | 知识库条目 | KnowledgeRecord | commands::knowledge |
+| 10 | `knowledge_events` | V10 | 知识生命线事件 | KnowledgeEventRecord | commands::knowledge |
+| 11 | `app_settings` | V13 | 通用 KV 设置 | (无独立 model) | commands::settings（手写 Repo） |
+
+#### 遗留表（2 张）— DDL 存在但无活跃业务消费者
+
+> `df-task` crate 已于 2026-06-14 移除（零引用清理）。以下表仍在 migrations.rs 中创建、models.rs 有结构体、CRUD 可用，但当前**无上层业务代码写入或消费**。
+
+| # | 表名 | 建表版本 | 原始用途 | 状态 |
+|---|------|---------|---------|------|
+| 12 | `branches` | V2 | Git 分支绑定 | ⚠️ 无消费者（DDL 存在，CRUD 可用但无人调用） |
+| 13 | `releases` | V1 | 发布记录 | ⚠️ **功能性死表**：DDL 存在且含 version/status/task_ids/changelog/released_at 完整 schema，但全代码库零业务读写——无 ReleaseStatus 枚举、无 release 相关 IPC command、前端无发布管理页面。属"建了但从未使用"的空壳占位。 |
+
+#### 内部元表
+
+| # | 表名 | 建表版本 | 用途 |
+|---|------|---------|------|
+| - | `schema_version` | V0 | 迁移版本跟踪（仅存 version INTEGER，无业务语义） |
+
+### 不存在的表（曾出现在早期规划但从未建表）
+
+| 表名 | 状态 | 说明 |
+|------|------|------|
+| `workflow_defs` | ❌ 从未建表 | 工作流定义以 dag_json 内嵌在 workflow_executions 中 |
+| `connections` | ❌ 从未建表 | 连接配置使用 app_settings KV 表存储 |
+| `artifacts` | ❌ 从未建表 | 产出物概念未落地 |
+| `annotations` | ❌ 从未建表 | 标注系统属已废弃规划 |
+| `decisions` | ❌ 从未建表 | 决策留痕属已废弃规划 |
+| `features` | ❌ 从未建表 | 需求功能清单未落地 |
+| `test_cases` / `test_runs` | ❌ 从未建表 | 测试模块未落地 |
+| `knowledge`（单数）| ❌ 不存在的旧命名 | 实际表名为 `knowledges`（复数），V7 建表 |
+| `merge_requests` | ❌ 从未建表 | 合并请求未落地 |
 
 ---
 
@@ -261,52 +199,39 @@ Fixer Agent   → 修复问题
 
 ### D1: 想法是第一公民
 - 想法池独立于项目，可以独立运转
-- 想法不需要关联项目即可被评估和打分
 - 晋升是单向操作（想法→项目），但保留追溯
 
-### D2: 多任务/分支并行
-- 同一项目内多个任务同时开发
-- 每个任务绑定独立 Git 分支
-- 任务间互不干扰，完成后合并
-
-### D3: 引擎不绑定业务
-- DAG 引擎纯粹做编排，不知道"想法"/"项目"等概念
-- 阶段是 DAG 模板，可自定义
-- 节点通过 Node trait 扩展
-
-### D4: 本地优先
+### D2: 本地优先
 - SQLite 嵌入，不依赖云服务
 - 所有数据存储在本地
 - 零运维，安装即用
 
-### D5: AI 贯穿全程
-- 不是"加了 AI 功能"，而是"AI 是系统的一部分"
-- 每个阶段都有 AI 参与
-- AI 输出作为决策依据，最终决策权在人
+### D3: 引擎不绑定业务
+- DAG 引擎纯粹做编排，不感知具体业务语义
+- 业务逻辑在 df-nodes 实现（Node trait 是纯接口）
 
-### D6: 决策必留痕
-- 所有关键决策自动记录
-- 决策可追溯到具体上下文（哪个想法、哪个功能、哪次审查）
-- 未来可回溯"为什么这么做"
+### D4: AI 贯穿全程
+- AI Chat 对话 + 工作流 AiNode 双路径
+- AI 输出作为决策依据，最终决策权在人
 
 ---
 
-## 六、审查发现的设计问题与决策
+## 六、Crate 结构
 
-| # | 问题 | 设计决策 | 优先级 |
-|---|------|---------|--------|
-| 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 |
+实际 **8 个 crate**（`crates/` 目录下）：
+
+| Crate | 职责 |
+|-------|------|
+| `df-core` | 公共类型（types.rs）、事件定义、工具函数 |
+| `df-workflow` | DAG 引擎（拓扑排序、执行器、Node trait） |
+| `df-nodes` | 内置节点（Ai / Script / Human） |
+| `df-ai` | AI 集成层（LlmProvider trait、OpenAI 兼容、Anthropic、ContextManager、工具注册基础设施） |
+| `df-execute` | Shell 执行（跨平台封装） |
+| `df-storage` | SQLite 存储层（migrations、CRUD 宏、Repo） |
+| `df-ideas` | 想法池业务逻辑（评估、晋升） |
+| `df-project` | 项目管理业务逻辑（目录绑定、技术栈探测） |
+
+> 原始设计文档（Phase1架构决策 ADR-003）曾写 "13 个独立 crate"，属过时数字，未随代码演进更新。实际为以上 8 个。
 
 ---
 
@@ -316,16 +241,15 @@ Fixer Agent   → 修复问题
 
 ```
 1. 用户在想法池输入"做一个 Markdown 编辑器"
-2. AI 评估可行性，给出评分和建议
+2. 启发式评估可行性，给出评分和建议
 3. 用户点击"晋升为项目"
-4. 系统创建项目，进入编码阶段
+4. 系统创建项目
 5. 用户创建任务"实现基础编辑功能"
-6. 系统创建分支 task/abc123
-7. 用户点击"运行工作流"
-8. DAG 执行: [Shell: 环境检查] → [Shell: 运行测试] → [Shell: 构建产物]
-9. 前端实时展示执行日志
-10. 执行完成，结果持久化到 SQLite
-11. 用户刷新页面，数据仍在
+6. 用户点击"运行工作流"
+7. DAG 执行: [Script: 环境检查] → [Ai: 代码生成] → [Human: 审批]
+8. 前端经 EventBus 实时展示执行日志
+9. 执行完成，结果持久化到 SQLite
+10. 用户刷新页面，数据仍在
 ```
 
 ---
@@ -337,13 +261,22 @@ Fixer Agent   → 修复问题
 - 与 `evaluator.rs` 已实现的 `EvalDimension` 对齐
 - `IdeaScores { feasibility, impact, urgency, overall }` 保留
 
-### Q2: 发布模块 Phase 1 范围 ✅ 已确认
-**决策**：Phase 1 简化 — 只做 Release 记录 + 手动标记任务
-- releases 表保留，支持 CRUD
-- 不做自动化发布流程（合并→测试→部署）
-- 前端在 ProjectDetail 中添加简单 Release 面板
+### Q2: 发布模块 ✅ 已确认（当前为死表状态）
+**决策**：Phase 1 不做发布功能。releases 表 DDL 存在但无业务逻辑，待后续激活。
+- 不做自动化发布流程
+- 前端无发布入口
 
 ### Q3: AI 评估 Phase 1 范围 ✅ 已确认
-**决策**：Phase 1 用固定算法评分，延后接入 AI
-- `ScoringEngine` 当前返回固定 5.0，改为基于启发式规则的简单算法
+**决策**：Phase 1 用固定算法评分，延后接入 LLM
+- `ScoringEngine` 当前返回基于启发式规则的分数
 - Phase 2 接入 LLM 后替换为 AI 评分
+
+---
+
+## 相关文档
+
+- [df-nodes 节点集合](../03-模块文档/df-nodes-节点集合-2026-06-12.md) — 3 节点详述
+- [df-ai AI 集成模块](../03-模块文档/df-ai-AI集成模块-2026-06-12.md) — Provider / Context / 工具注册
+- [df-storage 存储层](../03-模块文档/df-storage-存储层-2026-06-12.md) — 迁移 / CRUD / Repo
+- [df-workflow 工作流引擎](../03-模块文档/df-workflow-工作流引擎-2026-06-12.md) — DAG / Executor
+- [Phase1 架构决策](./Phase1架构决策-2026-06-12.md) — ADR 记录（注意：ADR-001/003 含过时信息，以本文档为准）

docs/02-架构设计/任务推进链实施路径-2026-06-16.md

@@ -0,0 +1,125 @@
+# 任务推进链实施路径
+
+> **日期**: 2026-06-16
+> **来源**: [任务执行与推进能力分析-2026-06-16.md](../05-代码审查/任务执行与推进能力分析-2026-06-16.md) 第八章（已核对注入）
+> **状态**: 规划定稿。**D-260616-01~04 已决策(2026-06-16)**:①前端对齐7态 ②任务软删(UI缓做) ③advance_task 走 **df-nodes Node** ④阶段1先行。**阶段1可启动(F-01~05)**。
+> **关联决策**: D-260616-01~04（决策结果见 todo.md 待决策区块）
+
+---
+
+## 〇、核对纠正（实施前必读）
+
+经 Explore 代理核对，原分析报告「AI 缺 update_task / run_command 工具」**核实为假**：
+
+| 工具 | 报告称 | 核实 | 证据 |
+|------|--------|------|------|
+| `update_task` | 缺失 | ❌ **存在** | tool_registry.rs:348，AI 能改任务字段（含 status，经裸 update_field 非状态机收口） |
+| `run_command` | 缺失 | ❌ **存在** | tool_registry.rs:468，完整 Shell 执行实现 |
+| `run_workflow` | 空壳桩 | ⚠️ **未注册** | tool_registry.rs 无此工具（连空壳都没有） |
+| `advance_task` | 缺失 | ✅ 确实缺失 | 全局搜零定义 |
+
+**修正后结论**：AI **能**更新任务状态、**能**运行命令，但仍**不能**：① 触发三闸门推进链（无 advance_task）② 联动工作流（task_id=None + 无完成回调）③ 在对话中触发工作流（无 run_workflow 工具）。
+
+---
+
+## 一、阶段 0 — 基础修复（前置，部分已立）
+
+已在 todo.md 立项 **B-260616-12~18**（状态枚举/路由/try-catch/字段保护/DDL/priority/绕 store）。
+
+✅ **阻塞已解除（2026-06-16 D-01/D-02 决策）**：
+- B-260616-12（状态枚举）→ D-260616-01 定**前端对齐后端 7 态**，可直接做
+- B-260616-13（软删除）→ D-260616-02 定**加软删除对标 projects（UI 缓做）**，可直接做
+
+---
+
+## 二、阶段 1 — 推进骨架（手动闭环 ~200 行，报告建议先行）
+
+目标：任务状态经「合法路径」推进，而非裸字段修改。
+
+| 任务 | 内容 | 依赖 |
+|------|------|------|
+| **F-260616-01** [P1] | **状态机定义（df-nodes 新模块 `task_state_machine.rs`）**：7 态合法转换枚举（`todo→in_progress→in_review→testing→done` 闸门链 + `blocked` 退回 + `cancelled`）。独立模块，非挂在 TaskStatus enum 上。 | D-01✅ 前端对齐7态 |
+| **F-260616-02** [P1] | **advance_task 推进逻辑（df-nodes `task_advance_node.rs` 实现 Node trait）**：校验转换 + 原子写（下沉 SQL `WHERE status=:expected` 防 TOCTOU）。df-nodes 需补 `df-storage` 依赖读 TaskRecord（核实无循环）。IPC 层 thin 入口调 df-nodes。 | D-03✅ df-nodes, F-01 |
+| **F-260616-03** [P1] | `status` 移出 `update_task` 白名单（推进链唯一收口） | F-02（关联 B-260616-16） |
+| **F-260616-04** [P2] | `review_rounds` 字段（退回时 +1，任务卡显示「第 N 轮 review」） | F-01 |
+| **F-260616-05** [P1] | 前端 TaskDetail 推进按钮（手动推进，不接 AI） | F-02, F-03 |
+
+此阶段不接 AI/工作流，纯人工推进，但状态机保护和收口到位。
+
+---
+
+## 三、阶段 2 — 工作流联动（单向）
+
+目标：工作流执行能回写任务状态。
+
+**F-260616-06** [P1]（聚合）：
+1. `run_workflow` IPC 支持 `task_id` 参数（去 workflow.rs:56 None 硬编码）
+2. 工作流完成回调 → 检查 task_id → 推进任务状态
+3. 定义任务推进 DAG 模板（AiNode 执行 + AiNode 自审 + HumanNode 核对）
+4. `advance_task` 触发对应闸门工作流
+5. 前端展示工作流执行进度
+
+**依赖**：阶段 1 完成。详见报告 §8 阶段 2。
+
+---
+
+## 四、阶段 3 — AI 执行闭环
+
+目标：AI 能真正执行任务内容。
+
+**F-260616-07** [P2]（聚合）：
+1. `advance_task` AI 工具（让 AI 经合法路径推进）
+2. `run_workflow` AI 工具注册实装（核对：tool_registry.rs **无此工具**，需新建）
+3. AiNode 接入任务上下文（读任务描述 + 项目目录）
+4. AI 自审 verdict 结构化输出 + 解析
+5. 失败路径完整处理（退回/重做/保持）
+
+**依赖**：阶段 2 完成。详见报告 §8 阶段 3。
+
+---
+
+## 五、阶段 4 — Git 集成（增强）
+
+目标：代码类任务支持 Git 工作流。
+
+**F-260616-08** [P3]（聚合）：
+1. 加 `kind` 字段（code/doc/design/generic）
+2. code kind 闸门接 git 命令（worktree/commit/merge）
+3. BranchRecord 联动（加 worktree_path）
+4. `on_task_advanced` 钩子填充（分支联动 + 项目 completed）
+
+**依赖**：阶段 3 完成。详见报告 §8 阶段 4。
+
+---
+
+## 六、依赖关系图
+
+```
+D-01 枚举方向 ──▶ F-01 状态机 ──▶ F-02 advance_task ──▶ F-03 收口 ──▶ F-05 前端按钮
+                       │                  │
+                       └──▶ F-04 rounds   └──▶ 阶段2(F-06) ──▶ 阶段3(F-07) ──▶ 阶段4(F-08)
+
+D-03 架构落点 ──▶ F-02
+D-04 路径取舍 ──▶ 阶段1 是否先行
+```
+
+**✅ 阶段 1 可启动（2026-06-16）**：D-01（前端 7 态）/ D-03（df-nodes Node）/ D-04（先行）三决策已定。阶段 1 ~200 行，从 0% 推进能力到「手动推进闭环」。df-nodes 落点核实可行（Node trait 纯接口 `df-workflow/src/node.rs:67`，现有 AiNode/HumanNode/ScriptNode，需补 `df-storage` 依赖无循环）。
+
+---
+
+## 七、待合并到 `docs/todo.md` 的指针
+
+> 主文件 todo.md 并发修改频繁（后台代理），以下指针待稍后合并。合并时在「待决策」区块（D-260616-04 后）插入：
+
+```
+### 🗺️ 任务推进链实施路径（2026-06-16 规划·供其他会话读取）
+
+> 详见 [任务推进链实施路径-2026-06-16.md](./02-架构设计/任务推进链实施路径-2026-06-16.md)。
+> 推进能力实现度 0%。**阶段 1 已解除阻塞（D-01/D-03/D-04 三决策已定 2026-06-16），可启动 F-01~05**。
+> 核对纠正：AI 有 update_task/run_command 工具，无 run_workflow/advance_task。
+
+- [ ] F-260616-01~05 阶段1 推进骨架（状态机+advance_task+收口+rounds+前端按钮）
+- [ ] F-260616-06 阶段2 工作流联动（task_id+回调+DAG模板）
+- [ ] F-260616-07 阶段3 AI 执行闭环（advance_task/run_workflow 工具+AiNode+自审）
+- [ ] F-260616-08 阶段4 Git 集成（kind+git闸门+worktree）
+```

docs/02-架构设计/对抗论证裁决报告-2026-06-12.md

@@ -11,7 +11,7 @@
 | 代理 | 立场 | 综合评分 |
 |------|------|---------|
 | 市场分析师 | 竞品全景 + 市场数据（带外部信源） | **4/10 — 不建议以当前形态推进** |
-| 技术架构师 | 13 crate / Tauri / 引擎 / AI 可行性 | **2.7/5 — 可行但必须砍 scope** |
+| 技术架构师 | 13 crate（2026-06-12 评审时数；2026-06-14 删 5 僵尸 crate，现 8）/ Tauri / 引擎 / AI 可行性 | **2.7/5 — 可行但必须砍 scope** |
 | 恶魔代言人 | 逐功能质疑需求真实性 | **核心成立，60% 功能该砍** |
 
 ---
@@ -21,7 +21,7 @@
 ### 共识 1：🔴 Scope 失控是最大风险
 
 - 8 个核心功能横跨 4-5 个产品类别（PM + 工作流 + AI 编排 + 代码分析 + 知识库）
-- 22,745 字架构文档、16 张表、13 crate —— **这是操作系统的野心，不是 MVP 的规划**
+- 22,745 字架构文档、16 张表、13 crate（评审时点数；2026-06-14 裁定为 8 crate）—— **这是操作系统的野心，不是 MVP 的规划**
 - 现实工时：v1.0 全功能需全职 8-12 个月 / 业余 1.5-2 年
 - 历史教训：Firebase/Heroku/全生命周期 API 平台都被"组件化组合"打败
 
@@ -112,7 +112,7 @@
 
 ### 5.3 架构调整
 
-- **13 crate 保留目录结构**（已建好，删除反而费工），但 Phase 1 只激活 6 个：
+- **13 crate 保留目录结构**（评审时点；2026-06-14 裁定删除 5 个僵尸 crate df-evolve/df-plugin/df-stages/df-task/df-traceability，现实际 8 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 周）