DevFlow/docs/todo.md

DevFlow 工作看板

来源：docs/02-架构设计/滚动规范/功能决策记录-2026-06-14.md「需求与待办」+ PROGRESS.md 各 Sprint 遗留，2026-06-14 汇总去重 + 代码核对修正。 互操作：执行走 mission-control，回写 mission_id；审查走 cr；发布走 publish-*。 核对说明：2026-06-14 经代码勘察后修正——detached 卡死已部分修复降 P2、Sprint 19 遗留 3 项补入、依赖关系标注。

2026-06-18 归档: 已完成 [x] 与历史分析段已迁至 07-项目管理/todo归档/2026-06-18.md。 2026-06-27 归档: 已完成 [x]/✅ 项已迁至 07-项目管理/todo归档/2026-06-27.md。

💡 2026-06-27 对话上下文透明化

用户看不到 AI 接收到的上下文信息（目标钉扎/enrichment/system_prompt），导致行为不可理解。

• L1 目标可见: 对话顶部显示当前 pinned_goals 列表，用户可查看/清理
• L2 Enrichment 可见: @[项目] 发送前展开 enrichment 摘要
• L3 完整上下文: 可展开面板查看 system_prompt / augmentations

💡 2026-06-27 统一 Inbox 设计(讨论产出)

思路:所有需要用户注意的事项(审批/知识待审/灵感确认/其他通知)集中到一个统一入口, 不阻塞对话。

审批留在对话内(需要即时上下文),知识/灵感/通知放 Inbox。 后续做详细设计方案。

🎯 统一规划（2026-06-26 全景）

整合知识图谱设计 + 22 条未完成项 + G1 目标钉扎(✅落地待实测) + 多工程方案。 核心主线：AI Working — AI 拥有项目知识图谱，自主分解/编排/执行/自检，人只决策。 执行策略（两阶段）：① 先攒批无冲突小 bug/小调整 → 提交；② workflow 编排相关任务批量推进大重构（减少文件读取/LLM 交互，提高上下文效率）。

主线脉络

G1目标钉扎(✅落地,待实测) → 知识图谱Phase1(任务网络,AI编排地基)
   ↓                              ↓
实测验证                    Phase4注入(复用G1的system_prompt注入基建)
   ↓                              ↑
F-09多会话B(立项) ────────────────┘ (Phase4前置:多会话各自注入)

任务图谱（DAG · 有方向有状态）

节点=任务（着色=状态），边=依赖方向（前置 → 后继）。推进时更新状态（CLI/edit 同步此表 + Mermaid）。 图例：✅完成 / 🔨进行中 / 📋待办 / 🚫阻塞

graph TD
  classDef done fill:#bfb,stroke:#393,stroke-width:2px
  classDef doing fill:#ffd,stroke:#993,stroke-width:2px
  classDef todo fill:#eef,stroke:#99c
  classDef blocked fill:#fcc,stroke:#c33

  G1["G1 目标钉扎<br/>✅代码 8ce18cb / 🔨待实测"]:::doing
  P1["父① 小bug攒批<br/>✅①.2/①.3(①.1过时·①.4归⑤)"]:::done
  P2["父② 知识图谱Phase1<br/>✅Phase1(数据层+业务层)"]:::done
  P3["父③ AI对话体验<br/>📋待办"]:::todo
  P4["父④ F-09 per-conv<br/>✅前端per-conv(accessor)"]:::done
  P5["父⑤ 灵感模块<br/>✅完成(⑤.1/①.4/⑤.2)"]:::done
  P6["父⑥ Phase2-5<br/>🔨Phase2-3✅·4-5待办"]:::doing
  P7["父⑦ 技术债<br/>📋待办"]:::todo

  P1 -.先行.-> P2
  G1 ==基建==> P6
  P2 ==> P6
  P4 ==> P6
  P2 -.task_links.-> P5

任务	状态	子项	依赖（前置）
G1 目标钉扎	🔨 代码✅8ce18cb 待实测	G1/G2/G4 落地	—
父① 小bug攒批	✅ 完成	①.2 白名单✅(settings.rs) / ①.3 priority✅(idea.rs) / ①.1 BUG层1❌过时(F-260619-03 方案①取代,层2待决策) / ①.4 雷达图→归父⑤	—
父② 知识图谱Phase1	✅ Phase1完成	②.1 V29迁移✅ / ②.2 TaskRecord+TaskLinkRepo✅ / ②.3 IPC(create_task扩展+task_link CRUD+move_queue+get_tree)✅ / ②.4 父聚合✅(set_status_for_aggregation绕status收口) / ②.5 AI工具6✅(基线38)	G1(弱)
父③ AI对话体验	🔨 ③.1✅ / ③.2待办	③.1 B-260619-04 ToolCard✅(跨轮收起已有+标题增强) / ③.2 REFACTOR-260619-04 审批状态机拆分 / 对话透明化 L1🟡待定	—
父④ F-09 per-conv	✅ 前端per-conv	④.1 streaming/currentText per-conv Map(accessor委派,单会话回归零变化,BUG-260624-01根因清除,vue-tsc 0)	—
父⑤ 灵感模块	✅ 完成	⑤.1 软删除✅ / ①.4 雷达图✅ / ⑤.2 #05✅/#06拆const✅/#09/#10表单(逗号tags)✅ / #07 DEC-02保留purge(不改) / 附:priority_from_i32跨层映射修复(对齐前端0=critical)	#07→②.1
父⑥ Phase2-5	🔨 Phase4 注入进行中	⑥.1事件流✅(V30) / ⑥.2基础设施✅(V31) / ⑥.3注入✅(resolver 增强+extra 渲染) / ⑥.4前端(C 方案展开摘要✅已决待实施)
父⑦ 技术债	📋 待办	SMELL-P1-6 / conditions / CR缓存 / UX分页 / 审批超时 / miniapp / 双监听器	— (穿插)

推进路径：父①先行（攒批提交）→ 父②主线 workflow → 父③/④并行 → 父⑤/⑥/⑦穿插。每父任务一个 workflow 批，子任务相关文件批量读改减少交互。状态更新约定：子项完成→父状态 🔨；全子完成→父 ✅；每批提交后同步此表。

协同点（跨主题复用）

1. IDEA-FIX-07 关联单向 ↔ 知识图谱 task_links：并入 Phase 1 用独立表（§2.2 论证 JSON 缺陷），别补 JSON 双向同步
2. G1 system_prompt 注入基建 ↔ Phase 4 L0 注入：复用 pinned_goal 拼接链路
3. F-09 per-conv ↔ Phase 4 多会话注入：F-09 前置
4. REFACTOR-260619-04 审批状态机 ↔ queue=decision 待决策池：审批对齐

待决策

决策点	选项
多工程合并	方案 A 合并 V28（前提:确认子1 表设计，find 未找到独立文档）/ 知识图谱独立 Phase 1
conditions 启用	启用求值 / 保留观察
BUG-260620-05 层2	workspace_root 外默认放行（黑名单制）？— 详见 ## 🔴 2026-06-20 BUG-260620-05

---

交接状态（2026-06-14）

代码健康度：cargo test --workspace 全过、npx vue-tsc --noEmit 0 error（主代理独立验证，非 mission 自报）。

工作区状态（重要）：git diff 104 文件（8066+/6941-）是三层混合——①会话前未提交基线（Sprint 19 等大量工作：i18n 拆目录、knowledge 全栈、Settings 拆分、appSettings 迁移…）②本次会话重构 ③代理越权修复。接手前务必 git diff 通览区分，勿整体当作单一改动提交。

本次会话完成：

• 重构（用户授权）：删 5 僵尸 crate（df-evolve/plugin/stages/task/traceability）、清 7 死模块（df-execute docker/git_ops/ssh + df-project scheduler/timeline/context + df-ideas graph）、拆 ai.rs→commands/ai/ 11 文件、拆 ai.ts→6 composable、models 字段 bug 修复、coordinator B 路线标注
• 代理越权追加修复 6 处（已标✅，主代理验证编译+测试通过；逐行正确性建议接手方 git diff 复核）：B-01 审批持久化 / B-02 ConditionEngine 默认 false / B-04 删 NodeRegistry Default impl / T-05 工具结果截断 50KB / B-08 promote 补偿删除 / T-07 诊断日志清理

待设计交其他会话（核心）：df-workflow 审批闭环三连 B-06/B-07/B-03。✅ B-03 设计已完成（接手会话，2026-06-14）：见 B-03-人工审批响应机制-2026-06-14.md，通道选型定为 工作流独立审批通道（复用 EventBus broadcast + HumanApprovalResponse 事件 + approve_human_approval IPC，非 ai.rs AiApprovalRequired——后者是 AI Chat 工具审批路径，与工作流节点审批是两条独立链路）。拆 B-03a（响应等待 + 超时，不依赖 B-07）/ B-03b（取消机制）。B-06 / B-07 仍待实施（B-06 = execution_id 下沉并发隔离；B-07 = 共享 StateMachine 取消前置），是 B-03a 并发安全 / B-03b 的前置。

失控代理教训：本次会话派的后台拆分代理在 stop hook 循环里失控，越权改代码/文档（先斩后奏）。接手方若再派 agent，注意约束其不碰决策记录（用户已要求手动触发）+ 限定单任务不自主续推。

---

待办

🔍 2026-06-21 AI Chat 技术债审查(workflow wf_92b61c35-4d2 · 10 模块串行 grep 核验)

详单见 aichat-技术债审查-2026-06-21.md。0 P0 / 7 P1 / 25 P2 / 40 P3 / 已登记 8 / 新债 64。P1#5/#6 已即时修并自验过。

[2026-06-24 核验销账]: try_continue pending_conv_id 🟡语义复杂(R-PD-6 优先审批 conv_id 设计+try_continue 回退,非确定性低风险)/ MidStream chunk.error 🟡UX 结构变更(Partial 保文加 err 字段+前端渲染,非 bug)/ auto-compress save 🟡需理解 loop save 时机判真缺口。

销账核对(已登记 8 复核):SMELL-P1-6(line221·#5 覆盖 executed/completed 双轨)/ MED-1(tool_registry:546 bind_directory)/ REFACTOR-260619-08(tool_registry:881 拆)/ REFACTOR-260619-09(context.rs:1 God 1552行)/ ARC-260619-05(agentic:318 超长)/ UX-260617-28(双监听器 INFO)。均仍在未完成,审查复核确认,保留。

残留诊断代码(待清):chat.rs authz_debug/authz-debug.log(L2 调试遗留,P2 报 chat.rs:548 硬编码绝对路径),L2 完成 + 用户实测后可清。

---

🔍 2026-06-21 查询能力缺口 + run_workflow 缺陷(本轮排查登记·未实施)

用户排查任务/项目/灵感查询能力现状,登记缺口为待办/缺陷,本轮不实施代码。详单见 查询能力补全方案-2026-06-21.md。

---

📋 编排推进总览（2026-06-18 更新）

未完成待办按可执行性分 8 组（详细条目见下方各分类，勿重复记录）：

组	说明	代表项
A todo 卫生	矛盾清理/被取代退役标注	✅ 本批已完成
B 零风险减法	死链清/空壳合并	✅ 本批已完成
C 需用户输入	阻塞，无法代办	S-260615-01 curl 测 / S-260614-01 多开澄清 / S-260614-02 实测重评
D 功能增强	设计清晰可推进（P1）	F-15-01 审批选项 / F-15-02 task 详情 / F-15-03 分页⚠️breaking / F-15-04 卡片折叠
E 架构重投入	需设计，非小改	F-14-01 模型能力 / F-14-07 trait 下沉 / ARC-05·06 store 拆·循环依赖
F 全局 review P2 需设计	安全/竞态收口	R-PD-4/5/6/8/9/12/13 + R-PD-10 .map_err 85 处
G 测试/dev 验证	收尾土壤	ARC-08 dev 验证 / B-03b-R8 human 端到端 / T-14-01·02 Sprint 实测
H 长期功能池	不进主线	F-14-02~10 / T-14-06 Settings 拆 / T-14-11 条件引擎 / B-14-05 / B-03b-R9

推进原则：能并行不串行（独立子任务 8-12 并发）；每批重汇总+全优先级重排+销账核对 ✅；C 组阻塞项不代办等用户。本会话首批：A 卫生 + B 清死链。

③④C类已迁（2026-06-16）：需人工决策项(③产品取舍 7 / ④设计方向 7 / 重投入排期 9 / C用户实测 5)见 待决策.md,从本文件抽离职责分离。batch54 可自主批进展(2026-06-16·workflow wsfz7zl8i + 主代核查):复核-新⑪ 看门狗幽灵 ✅ 销账(清主窗口 state 视觉残留;核验更正:原 watchdog 幽灵已被 CR-260615-24 stopListener:371 clearStreamWatchdog 兜底);AE-03 diff预览 ⚠️ 降级阻塞(后端 write_file 未返 diff,待后端补,见 line 538);UX-04 断线保文 待 DEC-260616-03 授权(见待决策.md 🟡,本批不含)。

📦 已完成项归档: 07-项目管理/todo归档/2026-06.md — 2026-06-18 拆分, 已完成 [x] 与历史分析段迁此。另有 2026-06-18.md / 2026-06-27.md — 本次归档。

🔴 2026-06-20 BUG-260620-05 F-260619-03 工程内路径误弹窗(reload_allowed_dirs 丢 workspace_root·b22e9ae 回归)

现象:AI Chat file_info 等文件工具访问工程内路径(如 docs/02-架构设计/单对话并行多轮-设计-2026-06-20.md)触发授权弹窗,用户称"本来就有访问权限,为什么还来申请"。

根因:state.rs:586-619 reload_allowed_dirs 合并 kv_dirs(KV allowed_dirs)+ project_dirs(projects.bind_directory) 为 all_dirs,仅当 all_dirs.is_empty() 时(:618)才插入 workspace_root。KV 配过 allowed_dirs 或有绑定项目 → all_dirs 非空 → workspace_root 不入 persistent → 工程内路径(在 workspace_root 下)is_authorized(:356 starts_with)失败 → check_path_authorization 返 NeedsAuthorization → 弹窗。

注释承诺失配::346-348 / :583 / :617 注释均称"KV 未配时保持 workspace_root 免授权(向后兼容)",但 :618 条件用 all_dirs(含 project_dirs),project_dirs 非空也丢 root。b22e9ae "reload 尊重用户 persistent" 引入的回归。

用户政策指令(2026-06-20):"默认直接访问,明确知道无权限才申请"。指向工程内(workspace_root 下)默认免授权,仅 workspace_root 外非白名单路径才弹窗。

修法(层1·1 行确定性 bug):state.rs:618 去掉 if all_dirs.is_empty() 条件包裹,无条件 set.insert(workspace_root_path())(工程内始终免授权,对齐用户政策 + 注释承诺)。不破坏现有能力:workspace_root 经 set/get_allowed_dirs(:664/680 filter root)本就不可见不可删,"用户删 root"语义未落地,保 root 无冲突。

层2 待决策(政策范围):用户"默认直接访问"是否要求更宽语义——workspace_root 外的非黑名单路径也默认放行(翻转 is_authorized 为黑名单制,实质去白名单)?涉 P0 去固定根决策方向,见待决策.md。dev 自用场景层1 即满足。

关联:F-260619-03(todo :528 b22e9ae 回归源)/ 待决策 workspace_root 分发适配(方案b 用户项目绑定)/ memory devflow-project-path-binding 状态:🔴 待用户授权(层1 1 行修法可直改;层2 待政策澄清)

---

💡 2026-06-16 新需求（已分析·待实施）

功能需求，已走查定位链路 + 方案记录，待用户确认后实施。

• F-260616-09 [P1/架构·A路线✅(batch60 + 06-19核验补漏已落地:commands.rs:1404/useAiConversations.ts:80 → 阶段1跳过),B 设计完成 2026-06-19(F-09设计文档)·阶段2 批1-8 待拍板 b-1(messages per-conv)启动(见待决策.md)·messages per-conv 已落地(2026-06-20 核验):mod.rs:326 pub per_conv: HashMap<String, PerConvState> + :384 conv(&mut self, conv_id) 访问器 + :394 conv_read + tests_f09_per_conv 测试模块 + 决策e 真并发已上线(见文件末 F-09 决策e 段,CR-260620-02 审 PASS)****] — AiSession 单例 → 多会话并发架构（多窗口来回切 + 并行执行）。用户需求(3 条消息强化)：「应用级支持同时具备多会话」+「同时具备多会话的能力」+「多个会话窗口来回切，并行执行」。现状（Explore 走查确认）：AiSession 应用级单例（state.rs:164 ai_session: Arc<Mutex<AiSession>>，init:205），messages/generating/stop_flag/pending_approvals/agent_language 全一份。设计「单例 + 软隔离」——generating 互斥(同一时刻只一个对话能跑) + 切换旧 loop 退出(agentic.rs:177-190 B-260615-11) + 切换时 generating→readonly(commands.rs:873-881)。llm_concurrency per_conv 因此退化为单对话内并发(state.rs:93-96 注释已标注预留改 HashMap)。memory 已标记「AiSession 单例未动」架构债(aichat-arch-extensibility)。残留 bug(表象=新建会话上下文残留)：前端 newConversation(useAiConversations.ts:31-41) 漏清 queue/generatingConvId/agentRound/searchQuery；后端 ai_conversation_create(commands.rs:784-821) 漏清 agent_language/stop_flag(设 true 停旧 loop 没复位 false)。用户「并行执行」明确=B 方向(A 只解切换残留不满足并行)。分档：A 短期隔离修复(补漏清字段，维持单例软隔离，解残留，低风险立即做，B 前置) + B 多会话并发架构(单例 → HashMap<conv_id, SessionState>，每会话独立 messages/generating/stop_flag/pending_approvals + llm_concurrency per_conv 改真 per-conv HashMap + loop 内校验改 conv_id 索引各自 session + 切换不退出旧 loop 各自跑完真并发 + 事件路由核对 conversation_id 全覆盖)。决策点(待定)：(a) A 先做解燃眉 vs 直接 B——倾向 A 先(残留真 bug 立即解，B 架构另立项) (b) B 形态——AiSession 整体 HashMap vs 拆字段(messages/pending 已可按 conv reload，只拆 generating/stop_flag per-conv)——倾向后者侵入小 (c) B 并发上限——复用 llm_concurrency.global 限并发会话数防 token 暴增——倾向是 (d) 多窗口 UI 形态——(d1) 单面板侧栏会话列表切换+后台并行(改动小) vs (d2) 每会话独立 Tauri 窗口(useAiWindow.ts detached 已有基础可扩，改动大但「窗口来回切」语义最贴)——待用户定，倾向先 d1 后 d2 (e) 旧 loop 切换处理——不退出各自跑完(真并发，倾向) vs 仍退出。— state.rs(AiSession 去单例化) + commands.rs(create/switch 重构 + 漏清补) + agentic.rs(:177-190 校验改 conv_id 索引) + context.rs(ContextManager per-conv) + useAiConversations.ts(漏清补) + stores/ai.ts(per-conv state) + llm_concurrency per_conv + useAiWindow.ts(若 d2 多窗口)。B 是大改架构升级，需单独设计文档 + 立项。✅ 已决(2026-06-16·待决策归档):a — A 隔离修复 + B 立项(🔥 B 阶段高优先级尽快实施),UI d1+d2 都做(侧栏切换 + 独立 Tauri 窗口)。

• F-260616-12 [P2/依赖F-09] — retry 持 permit 不释放（多会话隐患）。F-260616-07 落地的流式重试循环（agentic.rs:238-239）重试期间持有 global+per_conv permit 不释放（注释「防新请求挤占」）。当前 AiSession 单例 + 主 loop 串行无影响，但 F-260616-09 多会话并发后，重试期间阻塞其他对话 LLM 调用。方向：多会话落地时核对——主 loop 串行下重试持 permit 防自己挤占无意义，倾向重试不持 permit 或仅持 per_conv。— agentic.rs:238 + F-260616-09 多会话架构。依赖 F-260616-09 立项后一并处理。

🔴 aichat API Key 401 排查（2026-06-16）

用户报对话失败「调用失败: API Key 无效或无权限」+ 重设 key 无效。排查结论:代码链路全对(保存 keyring✓ / 读取 resolve_provider_secret✓ / 鉴权头 openai=Bearer·anthropic=x-api-key✓ / URL 智能拼接✓),401 来自服务端,非 devflow bug。根因四选一(key 无效 / provider_type 不匹配 / base_url 错 / model 名错)。详见 aichat-apikey-401排查-2026-06-15.md。

• S-260615-01 — [待用户确认根因] 用户跑直连测试(curl)区分 key/provider_type/base_url/model 哪项错,见详情文档「验证步骤」

🟦 架构审查待修项（2026-06-16）

纯架构层评估（边界/依赖/抽象/扩展性/状态管理），详见 架构审查-2026-06-15.md。共 🔴6 🟡6 ⚪4 + 亮点 6。与 06-14 三份报告去重（不重复 bug/性能 FR-、aichat AR-）。

中期（技术债）

• ARC-260615-07 — 其余见文档：df-core 改名 df-types（类型库非核心）/ src-tauri IPC 编排层抽取(df-app，5711 行成事实业务层) / AI agent loop 从 IPC 下沉 df-ai / 3 view 绕 store 调 api / 类型契约 ts-rs 代码生成 / AiSession 多会话(B 路线前置) / AppState 分组 / IPC 命名统一

P1 — 重要缺陷

• T-260614-01 — [P1] Sprint 9/10/14/15/16/18 多项未 tauri dev 实测 — 评分 IPC 缩放 / update_full / promote_idea / Store getter / token 落库 / 知识库 Tier 1 全栈 / LLM 并发 Semaphore / 知识生命线（#54 跟踪）— source:Sprint 9-18 (06-14)
• T-260614-02 — [P1] 切对话不中断路由：部分场景运行时实测（A 路线场景 2/3） — source:Sprint 8 (06-14)

🔴 架构坏味道全面扫描（2026-06-18·6路并行 Explore agent·57K行代码）

来源: God文件/长函数 + 循环依赖/耦合 + DRY违反 + 错误处理不一致 + 命名API/类型安全 + 测试覆盖/死代码。6 维度全覆盖。

🟡 P1 应该改进 (9项):

• SMELL-P1-6 — [P1🟡] String 类型滥用替 newtype/enum —— execution_id/status/tool_type 等 5+ 处改强类型

🆕 sweep 派生登记（2026-06-18·workflow w2xkw4ybh data 抽出 + wo7d6zdqm 多维度 sweep）:

• ARC-260618-01-d [P1/🟡已实现待启用] — conditions 条件引擎(核验2026-06-22:conditions.rs:31 ConditionEngine + executor.rs:106 已调 evaluate 求值 + executor.rs:95 cfg!(feature="conditions-eval") feature flag 控制,求值逻辑已实现待产品确认启用时机)。df-workflow/conditions.rs ConditionEngine 零消费(无调用方),Edge.condition 字段存储但工作流执行器未求值分支——边条件当前形同虚设。产品决策点:① 实现条件求值(executor 在节点完成后求值出边 condition 决定路由)还是 ② 标 #[allow(dead_code)] + 文档明示"条件为预留未启用"。涉及行为变更(executor 控制流改变),确认产品意图后再实施。对齐 H 组长期池 T-14-11 条件引擎(line 42 仅指针无详情)。— crates/df-workflow/src/conditions.rs(ConditionEngine) + crates/df-workflow/src/executor.rs(边求值点)

🟡 AI Chat 交互体验改进（2026-06-14 方案 → 待办化）

来源：aichat交互体验改进方案-2026-06-14.md。7 大类 20 个改进项，按原文优先级分 4 批。去重：§1.3 复制 ⊂ F-260615-13/14（已写）、§3.4 新建中断 ⊂ B-260615-10（已做软复位，本文档加 confirm 增强）、§6.2 分离窗口同步 ⊂ CR-24/25（已写）。状态: 待讨论→看板跟踪。

第三批 — 锦上添花

• UX-2025-12 [P2] — 历史消息分页懒加载（§2.3）。▶ 已打开推进（2026-06-17 用户决定不再等痛点，与 UX-19 一并纳入）。方案：switchConversation 首次加载最近 50 条，滚顶加载更多（需后端 messages 查询加 offset/limit 支持）。关联 B-260629(messages 无上限)。决策点（待定）——与 UX-19(虚拟滚动)二选一解决长对话渲染卡顿：分页（后端配合，简单稳定，但切换/搜索跨页体验割裂）vs 虚拟滚动（纯前端，体验流畅，但流式末条挂载复杂）。倾向 UX-19 虚拟滚动优先（纯前端零后端改动+体验优），本项分页作为虚拟滚动不足时的补充方案。— src/stores/ai.ts + src/composables/ai/useAiConversations.ts + 后端 conversation.rs

待澄清 / A-B 待定

• S-260614-01 — [用户已澄清 2026-06-17] 「显示多开」= 多个会话来回切都可对话(非 AI Chat 窗口多开)。关联 T-260614-02(切对话不中断实测)+ F-09 多会话架构。A 路线(单例软隔离,已做):切会话软复位+DB 加载上下文+active 切换,来回切应能对话(需实测 T-260614-02)。B 路线(真多会话,未做):切走会话 generating 不打断,每会话独立 AiSession(memory aichat-arch-extensibility 单例未动)。✅ 已并入 F-260616-09(2026-06-16 已决 a):A 路线已实施待实测(T-260614-02),B 高优先立项,详见待决策归档/2026-06.md
• S-260614-02 — 审批可见性 A/B 待定 — B-01 修复后 pending_approvals 内存态不再被 switch 清空，前端 ai_pending_tool_calls 查询有数据，但 state.pendingApprovals 在 AiChat.vue 是否有兜底渲染仍需实测确认。A. 加兜底渲染 / B. 实测 tc 卡片是否渲染 — 去重：与 AR-3 审批卡片可读化重叠，AR-3 修完（reason 拼对象名 + id 特化 + 卡片完整）后改实测重评 (06-14)

ℹ️ 架构观察（INFO · 2 项·不进修复队列）

• UX-260617-28 [INFO] — 双监听器同通道 fragility — useAiEvents + useAiContext 各自 listen('ai-chat-event')，人工协调防双重处理(AiCompressing flag)非架构保证。未来新增事件处理可能触发双重 bug。长期考虑单一分发器模式。— src/composables/ai/useAiEvents.ts:269 + src/composables/ai/useAiContext.ts:85-105

🔧 2026-06-19 文件拆分升级（3 代理并行分析·建任务·未实施）

大文件统计(总 51143 行)+ 3 代理并行分析拆分方案。与已有 SMELL-P0-2(tool_registry)/SMELL-P0-3(AiChat.vue)/SMELL-P1-9(crud.rs) 合并。通用执行原则:可见性升级(私有 fn/struct → pub(super))/ 测试跟随被测函数 / 不改逻辑不改 await 边界不改签名 / 三段式验证(cargo check+test+clippy 分 crate,对齐 workflow-cargo-timeout-wrap)/ 保守方案(热路径整块搬不拆函数体)。

P1

• REFACTOR-260619-04 [P1·部分已做] — ToolCard.vue 拆分。2026-06-24 核验:ToolCard 已从 1527→428 行,已抽 ToolResultBody.vue + useToolCardHeader.ts + useToolCardRender.ts(主体瘦身完成);但原计划的 useToolFormat.ts/useToolApproval.ts/ToolCardHeader.vue/ToolApproval.vue 未独立(当前 useToolCard/useToolCardHeader/useToolCardRender 三模块)。剩余:审批状态机独立(useToolApproval)+ 头部组件(ToolCardHeader)。风险:折叠态 shouldKeepOpen 共享 / 审批状态机断链(B-260616-08 回归)/ ToolCardList 批量审批联动。— src/components/ToolCard.vue + ToolCardList.vue

P2 暂缓(窗口未到/收益低)

• REFACTOR-260619-09 [P2 暂缓] — context.rs(1332)等 F-15 压缩链路稳定再拆。生产 745+测试 587。impl 跨文件方案(同 crate 多 impl 块,零字段可见性改动)。先 sanitize.rs(最大连续块 ~184)。当前 context.rs 被 F-15/压缩频繁改动,拆分窗口未到。— crates/df-ai/src/context.rs

执行顺序建议:01-C provider_cfg(零风险试水) → 02 anthropropic → 03 audit → 04 ToolCard useToolFormat → 05 agentic_runtime → 06 ai_node → 07 AiChat.vue → 08 tool_registry。每步 cargo check+test+clippy 分 crate + 手测。

---

🔧 2026-06-19 ToolCard 同批/跨轮 UI 合并（子代理方案·其他会话实施·P1）

用户需求:AI 多轮 read_file(轮1×2 + 轮2×2)前端一排展开卡片("上面两个下面两个"),希望 UI 合并。后端 convert 已合并连续 tool_result(B-260619-03),前端展示层对齐。子代理分析:同批同类合并已存在(ToolCardList groupedToolCalls L92-110,calls>=2 显标题行+默认收起),痛点是跨轮(轮1/轮2 各独立 ToolCardList 实例→各成分组)。用户强调"谨慎不出错"。

• B-260619-04 [P1] — ToolCard UI 合并:跨轮同类自动收起 + 标题信息增强。推荐方案 A(不合并卡片本体/不跨 message 边界/不动数据结构,只做 ① 标题增强 ② 新轮收起旧轮):
  • 现状(已查清):ToolCardList.vue groupedToolCalls 按 tc.name 全局聚合,calls>=2 显「[图标] 读取文件 [N] ▸」标题行 + 默认收起(initDefaultCollapse L139-147)。同批 read_file×2 应已是折叠组;用户「下面又两个」=下一轮新 message 的独立 ToolCardList 实例→第二个分组(跨轮未合并)。
  • 方案 A 改动:
    1. 标题信息增强(低风险):收起态「读取文件 [2]」→「读取 2 个文件 · shortPath1 · shortPath2」(从 group.calls[].args.path 取前 2-3 个 shortPath 截断)。新增 groupSummary(group) computed + i18n 键 aiTool.readNFiles(zh/en,漏 en 键 vue-i18n prod 报错)。
    2. 新轮到达自动收起旧轮已完成组(中风险):AiChat.vue watch 末尾 message toolCalls 到达→对前序 message 的 ToolCardList 调 expose 新方法 collapseCompletedGroups()(只收起 calls 全 completed 且无 pending_approval 的组,尊重 userExpandedCards 记忆)。
  • 前置必做(步骤1,0 改动验证):跑 read_file×2 确认同批是否真成分组标题(排除 initDefaultCollapse watch 一次性锁 bug——immediate 在 toolCalls 异步到达 len===0 跳过,L152-160 initialized 锁可能误锁)。若同批未分组→先修此 P0 前置。
  • 风险(全列,谨慎):R2/R3 收起的分组 display:none 会盖过审批卡 shouldKeepOpen v-show(现有风险),自动收起必须跳过含 pending_approval 的组;R5 流式 calls 1→2 跃变时不应收起用户正在看的卡(组内已有 userExpandedCards 命中→该组不默认收起);R7 scrollToFirstPending 兜底(offsetParent===null→全展开重查)需保证自动收起走 collapsedGroups 机制而非硬 display:none。
  • 谨慎实施步骤:① 0 改动验证同批分组 → ② 标题增强(低风险) → ③ 新轮收起旧轮(中风险,跳 pending) → ④ 流式跃变保护 → ⑤ 回归(审批徽标/批量审批/切对话/High 二次确认)。
  • 不推荐方案 B(跨轮全局合并,破坏 message 边界,审批/折叠重构高风险)/ C(纯视觉框,不解决占用)。 — src/components/ToolCardList.vue(groupedToolCalls L92-110/initDefaultCollapse L139-160/isCardExpanded L222-234/collapseInactive L265-296) + src/components/AiChat.vue(watch messages) + src/i18n/{zh-CN,en}/aiTool.ts(readNFiles)

---

💡 灵感模块-来源采集/追溯(2026-06-21·待办·新功能范畴)

继批1-3c 升级后的下一步:灵感来源录入增强 + 自动采集机制。属新功能范畴,需独立设计采集规则/触发/去重,下一阶段推进。

• F-260621-01 [P2/新功能] — source 字段录入增强 + 自动采集机制。
  1. source 录入增强:灵感捕捉模态框加 source / tags / priority 输入(现仅描述),让录入即结构化(来源/标签/优先级)
  2. 自动采集机制:从对话 / 任务 / 代码中自动提炼灵感(降低录入门槛,捕捉随手遗失的灵感)
  • 需设计:采集规则(什么信号算灵感 — 关键词/意图/重复模式)/ 触发时机(对话结束/任务完成/手动触发)/ 去重(相似灵感合并避免洪水)/ 用户确认流(自动采集不污染灵感池,需用户确认入库)
  • 依赖:批1-3c 升级完成(已有 source/tags 字段基础) + 对话历史可读(F-15 archived_segment 状态) + 任务可读
  • 关联:memory devflow-idea-module / [aichat-skill-slash-autocomplete]

---

F-260620-01 跨端 AI Chat:微信小程序 ↔ Rust 云后端 ↔ DevFlow 桌面端

背景:微信小程序远程用 DevFlow AI Chat,桌面端与小程序双向实时同步(微信电脑+手机同时在线模式)。 设计:F-260620-01-跨端AIChat-微信小程序-2026-06-20.md(三层架构 df-tunnel/df-relay/df-miniapp + Rust 云后端选型) 关系:灵感 4495fbcd(选型论证,pending_review)+ 任务 6c816709(todo)

实施分阶段:

• P1 df-relay 云后端(axum WS Server + 广播中继 + 鉴权)— 无依赖
• P2 df-tunnel 桌面端(WS client + 事件桥接 ai-chat-event 透传 + 指令路由 + 配对绑定)— 依赖 P1
• P3 df-miniapp 小程序(前端 UI 复用 + WSS 连云)— 依赖 P1/P2
• P4 双向同步完善(冲突处理 + 安全 + 离线降级 + 部署)— 依赖 P1/P2/P3

Phase3 联调待办(D1-D6 决策点推荐:A纯透传 / 全19变体透传 / EventBus汇聚 / switch不处理 / 强类型保留 / 桥接层R1兜底):

• F-260622-01-阶段4:真机联调 + 多会话并发验证矩阵(6 场景含 F-09 跨端并发)

🔍 2026-06-22 miniapp 功能走查(workflow wf_ddd49ac8 · 5 域并行核验 + 主代终态抽查)

用户 /review miniapp + workflow 汇总安排。5 agent 独立 grep/read 核验源码(不信注释/文档) + 主代终态核验(ws.ts 真路径 src/api/ws.ts、relay.rs:255/355、remote_bridge 命令数 10 非 11)。18 findings → 去重 P1×5 / P2×3 / P3×1,2 项 refuted。关联 F-260620-01 阶段4(真机联调前置)。守 session-role-diagnose-only:本会话仅走查 + 登记,未实施代码。

P1(阻塞真机/可靠性·5 项):

• P1-D-260622 [P1🔴·真机分发最高阻断] — token/deviceId 硬编码 + 无配对绑定 + 无 storage 持久化。config.ts:35-39 硬编码本机 device_id+token(注释自认「联调期硬编码,后续做配对绑定」),:52-54 setConfig 仅内存赋值无 uni.setStorageSync。真机分发不能用本机硬编码 device_id。修:settings 页输入 + setConfig 持久化 storage + getConfig 读回退 default。— apps/df-miniapp/src/config.ts
• P1-A-260622 [P1🔴·可靠性] — 心跳 pong 闭环缺失。ws.ts:226 发 {control_kind:'ping'},relay.rs:355 miniapp 入站全标 MessageKind::Command 透传 device,但 ping 无 cmd 字段 → remote_bridge.rs:143 match 无 ping 分支 → device 收不到有效命令无 pong 回;useAiChat.ts:440 onControl 仅 console.log 无 pong 处理;ws.ts:245-257 重连仅靠 onClose/onError 无心跳超时。移动网络 TCP 半连接高发,device 静默挂死无感知。修:relay 解析 ping 构造 Control 类型 + device 响应 pong + miniapp 维护 lastPongTime 看门狗(3×interval 未收 pong 主动重连)。— ws.ts + relay.rs:handle_inbound_text + useAiChat.ts

用户补充核验(2026-06-22 用户详读源码+设计文档,主代逐项核源码判真伪):

⚠️ 用户分析 P0 三项(协议三重不匹配 / EventBus 未接 / 桥接层占位)经源码核验全部失实,系基于 Phase3 阶段1-3 落地前的设计文档「计划态」描述,未核当前代码。证据:

• P0-1 协议:crates/df-tunnel/src/tunnel.rs:457/327/424 tunnel 纯透传 payload Value 上抛 on_command,不做 from_value::<TunnelCommand> 强类型反序列化(方案A 阶段1 已落地 commit 0fb5af5)→ miniapp {cmd,args} 反序列化在桥接层 remote_bridge.rs:96 from_payload 成功,非阻断。tunnel.rs:457 注释自证「不反序列化为 TunnelCommand 强类型」。
• P0-2 EventBus:src-tauri/src/lib.rs:128 state.ai_event_bus.subscribe()(tunnel subscriber 已接)+ remote_bridge.rs:303/332/358/388 + commands/ai/mod.rs:209/225 publish_event 跨端透传。已双写接入(todo line 760 commit 0fb5af5/612de4c emit 双写 chat19/audit12/guard3/stream_recv2/agentic18)。event_bus.rs:53/115 的 #![allow(dead_code)]+「骨架阶段」注释是过时历史标注(publish_event 现有调用方 remote_bridge/mod),非未接入。
• P0-3 桥接层:remote_bridge.rs 完整实装(handle_remote_command:121 + MiniCommand:83 + from_payload:96 + match 路由 10 条 + route_list/load_messages publish_event)+ 已 wire lib.rs:150-154 on_command = Arc::new(...handle_remote_command...) + :171 .connect(&relay_url,&device_id,&token,on_command.clone())。非占位/设计态。remote_bridge.rs:40-42 的 #![allow(dead_code)]+「零调用方」注释写于联调前,现 lib.rs 已调(过时标注,待清)。

剩余开放项:P3-B-260622 [P3·真机前置] — manifest appid 占位。PLACEHOLDER 无法真机调试,需微信公众平台注册的真 appid。— apps/df-miniapp/src/manifest.json

✅ 2026-06-24 aichat 可靠性修复(消息重叠×5 + 授权弹窗卡死 + 工具执行心跳误报 · 诊断workflow→论证workflow)

剩余低优 :

• BUG-260624-02 残留:审批超时倒计时 UI(5min 无倒计时,ToolCard pending 态显 mm:ss 到期前 60s 变红)+ 核 detached 窗口 emit 作用域(分离窗口是否独立 startListener,否则 ai-pending-arrived 收不到)
• F-09 根因:streaming/currentText 全局单例改 per-conv(根治多会话串扰,见 docs/待决策.md)
• CR-260622-01-P2-2 [P2低优·评估降级] — HTML/markdown/JSON 等非代码文件无 session 级缓存。2026-06-24 评估:已有 TOOL_RESULT_COMPRESS_ENABLED(mod.rs:98/1029-1078 view-only 摘要,>2KB tool_result 压缩,LLM 视图摘要非全文回灌 prompt)部分缓解;read_symbol 治代码文件(主场景,降 24.4x)。非代码文件完整 session 缓存(path→hash+content+patch失效)设计复杂 + LLM patch 后重读确认行为不确定(缓存命中提示可能不够 LLM 仍重读),归 B 路线 prompt 策略(约束 patch 后不重读)更合适,工具侧完整缓存低优暂缓。

---

🔍 2026-06-26 灵感模块诊断待办（合并推进·单任务）

✅ 全部修复完成（2026-06-27 核验）

• [~] IDEA-FIX-10 [P2🟠] — 前端 filter + 后端分页漏数据。团队决策：hot/pending 保留前端 filter（扩多值属性过度设计）；keyword/order_by 已下沉后端。