127 lines
9.1 KiB
Markdown
127 lines
9.1 KiB
Markdown
# 待决策队列
|
||
|
||
> **职责分离**:
|
||
> - **主会话**(汇总/巡检)→ 【写入】"当前队列",登记待人工决策项(背景 + 决策点 + 选项 a/b/c + 推荐)。
|
||
> - **用户**(人工)→ 【拍板】选选项或确认推荐,回填理由(可选)。
|
||
> - **主会话**(拍板后)→ 决策项回流 [todo.md](./todo.md) 推进 + 迁入"已决归档"。
|
||
>
|
||
> 这里**只放需人工决策项**(产品取舍 / 方向选型 / 排期 / 用户实测澄清)。不放可自主推进待办(见 [todo.md](./todo.md))、不放审查登记(见 [待审查.md](./待审查.md))。
|
||
>
|
||
> **已决策历史**按月归档,见 [07-项目管理/待决策归档/](./07-项目管理/待决策归档/)。拍板后的项迁入对应 `YYYY-MM.md`(随时间增长追加月份文件,防本文件膨胀;文件不存在则新建)。
|
||
> 来源:2026-06-16 从 todo.md 抽离③④C类(可自主批 AE-03/复核⑪/UX-04 留 todo 推进)。
|
||
|
||
## 决策规则
|
||
|
||
- 每条须:背景 + 决策点 + 选项 + 推荐 + 关联 todo。
|
||
- 用户回填:`✅ 决策:X`(选 + 理由可选)。
|
||
- 拍板后:主会话回流 todo 实施 + 迁入 [07-项目管理/待决策归档/YYYY-MM.md](./07-项目管理/待决策归档/)(按月文件)。
|
||
- 暂缓项标 ⏸️,不删(条件变化可重启)。
|
||
|
||
## 状态图例
|
||
|
||
🟡 待决 / ✅ 已决(回填决策) / ⏸️ 暂缓(待条件)
|
||
|
||
---
|
||
|
||
## 当前队列
|
||
|
||
### ③类 — 产品取舍(有 a/b/c 决策点,核心待拍板)
|
||
|
||
#### B-260617-01 run_workflow 作为 AI 工具无法执行 + 无意义重试 + 审批混淆
|
||
- **背景**：2026-06-17 实测发现，AI 对话中调用 `run_workflow(task_id, target_status)` 推进任务状态，审批通过后 handler 返回 Err 提示字符串（`tool_registry.rs:530-546`），`ai_approve`（`commands.rs:329-334`）将其包成 `"failed"` tool_result 回传 LLM → LLM 认为失败 → 重试(1/4) → 又进审批 → 循环。三个关联问题：
|
||
- **问题 1**：run_workflow handler 仅持有 `db: Arc<Database>`，无法访问 `AppHandle/State`（registry/event_bus/workflows Repo），返回 Err 提示前端走 IPC。但 `ai_approve` 审批通过后直接 `ai_tools.execute()` 调 handler → 必然 Err。
|
||
- **问题 2**：handler Err → tool_result = 错误提示 → LLM 重试 → 同结果循环（工具定义未标 `no_retry`）。
|
||
- **问题 3**：前端渲染的是 AI 工具审批（tool_call pending），非工作流 HumanNode 审批。用户批准后工作流引擎从未启动。
|
||
- **决策点**：run_workflow 审批通过后如何真正执行工作流？
|
||
- **选项**：
|
||
- a: **前端拦截**（`ai_approve` 中识别 `run_workflow` → 不走 `ai_tools.execute` → 直接 `invoke('run_workflow', {task_id, target_status})` → 结果回填 tool_result）
|
||
- b: **后端注入 State**（`build_ai_tool_registry` 传入 `AppHandle` 使 handler 可直接执行，改 state.rs + tool_registry 签名）
|
||
- c: **从 AI 工具移除 run_workflow**（仅保留 advance_task 推进状态，工作流由用户手动在前端触发）
|
||
- **推荐**：**a 前端拦截**（改动最小，`ai_approve` 一处分支即可；方案 b 需改 tool_registry 签名链路较长；方案 c 退回手动不符合 AI 驱动目标）。问题 2/3 随 a 自动消解。
|
||
- **关联**：todo B-260617-01 / tool_registry.rs:530-546 / commands.rs:329-334 / audit.rs:590-630
|
||
- **状态**:✅ 已决(2026-06-17·波9 e23b316)— **决策:a 细化为 a2(后端分支)**。ai_approve 已持 app+state,后端直接调 run_workflow_inner 最干净(无需新 IPC/前端分支/工作流知识泄漏),符合 a 大方向(绕开 ai_tools.execute 必 Err)。问题 2 随 a2 消解(成功 tool_result + High 去重缓存双层断循环);问题 3 渲染区分记观察项(tool_display_hint 已含「触发工作流」语义)。详单见待审查 CR-52。
|
||
|
||
### 🟡 S-260614-01 多会话来回切对话(A/B 路线决策)
|
||
- **背景**:用户澄清(2026-06-17)「显示多开」原意 = 多个会话来回切都可对话(非 AI Chat 窗口多开)。关联 T-260614-02(切对话不中断实测)+ F-09 多会话架构。
|
||
- **决策点**:A 路线(单例软隔离)实测够 vs 需 B 路线(真多会话并行)架构升级?
|
||
- **选项**:
|
||
- a: **A 路线实测确认**(T-260614-02 跑 tauri dev 验证切会话不中断、来回切可对话)。够 → 销账;不够 → 升 b。
|
||
- b: **B 路线架构升级**(AiSession 单例 → 多实例,每会话独立 generating/AiSession,切走不打断)。memory aichat-arch-extensibility 记录单例未动。大改(触 ai/mod.rs AiSession + state.rs AppState + agentic.rs loop)。
|
||
- **推荐**:**a 先实测**(T-260614-02 验证 A 路线是否满足"来回切都可对话")。A 路线设计目标即切会话不丢上下文 + active 切换,理论支持。若实测发现切走 generating 被打断(单例限制)→ 升 b。避免盲目大改。
|
||
- **关联**:todo S-260614-01 / T-260614-02 / F-09 / memory aichat-arch-extensibility
|
||
- **状态**:🟡 待用户实测(T-260614-02)确认 A 路线是否够
|
||
|
||
### ⏸️ 暂缓(待条件触发)
|
||
|
||
#### T-260614-11 条件表达式引擎升级
|
||
- **背景**:df-workflow conditions 仅支持 true/false 字面量,升级为真表达式求值。引擎设计好但无前端 UI 消费方(demoDag edges 无 condition 字段)。
|
||
- **决策点**:求值器实现方式?(已暂缓:等工作流真实场景)
|
||
- **选项**:
|
||
- a: 手写求值器
|
||
- b: 复活 set_skipped
|
||
- c: default false + warn(均认可)
|
||
- **推荐**:**⏸️ 暂缓**(无消费方,等 BuildNode 落地跑构建→测试→部署真实场景)
|
||
- **关联**:todo T-260614-11
|
||
- **状态**:⏸️ 暂缓
|
||
|
||
### 🟡 待用户实测/澄清(需用户操作,主会话无法代办)
|
||
|
||
#### S-260614-02 审批可见性实测重评
|
||
- **待用户操作**:实测 tc 卡片是否渲染。B-01 修复后 pending_approvals 内存态不再被 switch 清空,前端查询有数据,但 state.pendingApprovals 在 AiChat.vue 是否有兜底渲染仍需实测。
|
||
- **选项**:A 加兜底渲染 / B 实测确认(去重:AR-3 修完已缓解,改实测重评)
|
||
- **状态**:🟡 待用户实测
|
||
|
||
#### T-260614-01 多项 tauri dev 实测
|
||
- **待用户操作**:Sprint 9/10/14/15/16/18 多项未 tauri dev 实测 — 评分 IPC 缩放 / update_full / promote_idea / Store getter / token 落库 / 知识库 Tier 1 全栈 / LLM 并发 Semaphore / 知识生命线(#54 跟踪)。
|
||
- **状态**:🟡 待用户实测
|
||
|
||
#### T-260614-02 切对话不中断路由实测
|
||
- **待用户操作**:部分场景运行时实测(A 路线场景 2/3)。
|
||
- **状态**:🟡 待用户实测
|
||
|
||
### 🟡 待设计/架构演进(有决策点,需方案设计或长期规划)
|
||
|
||
#### ARC-260615-07 架构重构批(排期/优先级决策)
|
||
- **背景**:src-tauri IPC 编排层 5711 行成事实业务层,7 项架构债。df-core→df-types 已完成(CR-61),剩 6 项独立大改。
|
||
- **决策点**:6 项重构何时做/优先级/是否做(每项 ROI 与风险权衡,无法纯技术论证——做不做是资源/产品取舍)
|
||
- **选项(剩余 6 项)**:
|
||
- a: df-app 抽取(IPC 编排层 5711 行独立 crate)
|
||
- b: AI agent loop 从 IPC 下沉 df-ai(逻辑与 IO 分离)
|
||
- c: 类型契约 ts-rs 代码生成(替代手写 types.ts)
|
||
- d: AiSession 多会话(B 路线前置,关联 S-260614-01)
|
||
- e: AppState 分组(5711 行 state 拆分)
|
||
- f: IPC 命名统一
|
||
- **推荐**:**⏸️ 缓做**(重构低 ROI,当前功能优先;待稳定后按 d→b→a 顺序,d 是 B 路线前置可先)
|
||
- **关联**:todo ARC-260615-07 / memory aichat-arch-extensibility
|
||
- **状态**:🟡 待排期决策
|
||
|
||
#### UX-260617-01 aichat 消息全量重叠(待 DevTools 定位根因)
|
||
- **背景**:用户实测消息大量重叠堆叠。5 角度分析排除 CSS/scoped/DOM,核心嫌疑虚拟滚动 IO 半激活态不一致 + height=0 未设 minHeight → slot 塌 0 → 重叠。
|
||
- **决策点**:根因确切触发路径(需 DevTools 实测,静态分析已到极限)
|
||
- **选项**:
|
||
- a: 虚拟滚动 IO/RO 时序竞态(主嫌疑,unload 分支 minHeight 兜底修复)
|
||
- b: 其他(DOM 结构问题,需 DevTools 实查)
|
||
- **推荐**:**待用户 DevTools 实测**(shouldRenderMsg 卸载时检查 slot 实际高度 + IO unobserve/observe 时序),定位后修法明确(unload 分支 minHeight fallback)
|
||
- **关联**:todo UX-260617-01 / docs/05-代码审查/AI聊天组件极端数据场景分析-2026-06-17.md
|
||
- **状态**:🟡 待 DevTools 验证根因
|
||
|
||
#### UX-260617-28 双监听器同通道(长期架构演进)
|
||
- **背景**:useAiEvents + useAiContext 各自 listen('ai-chat-event'),人工 AiCompressing flag 协调防双重处理,非架构保证。未来新增事件处理可能触发双重 bug。
|
||
- **决策点**:是否升级单一分发器模式(架构保证)
|
||
- **选项**:
|
||
- a: 保持现状(AiCompressing flag 协调够用)
|
||
- b: 单一分发器(架构保证,但大改)
|
||
- **推荐**:**⏸️ 暂缓**(当前 flag 协调有效,未来新增事件处理触发双重 bug 时再升级)
|
||
- **关联**:todo UX-260617-28 [INFO]
|
||
- **状态**:⏸️ 长期(INFO,当前够用)
|
||
|
||
---
|
||
|
||
## 已决归档
|
||
|
||
按月归档(随时间增长追加月份文件,防主文件膨胀):
|
||
|
||
- [2026-06.md](./07-项目管理/待决策归档/2026-06.md) — 2026-06 已决策/已实施/已排期/已解决历史(③类产品取舍 12 项 / ④类设计方向 6 项 / 重投入排期 8 项 / ④类续 5 项 / C类已解决 2 项)
|
||
|
||
> 新月份拍板项累积时,新建 `YYYY-MM.md` 承载。
|