root/goodbuddy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: resolve runtime, review, channel and chat state failures

Browse Source 
Keep remote startup cancellable without blocking other sessions and surface local OpenCode submission failures promptly. Preserve supervisor project isolation, pause behavior and valid story destinations.

Restore generated-image channel delivery, Telegram reconnection on unchanged Save and DingTalk business-error retries. Preserve virtualized message disclosures using sparse state and release stale supervisor UI requests.

Add production-path regressions, Electron checks, isolated SQLite validation and audit evidence. Fix the SDK cleanup test fixture lifetime under garbage collection without weakening its assertions.

Validation: 6136 tests passed, 87 skipped; typecheck, lint and diff checks passed. Seven real text-model calls, current-source Linux x64 Host scenarios and large-history Electron comparisons completed.

Release note: Fix stuck runtime requests, inconsistent review results and channel delivery failures, and retain expanded details while browsing long conversations. Remote runtime fixes require an Agent build containing these changes.
This commit is contained in:
mesalogo
2026-10-05 10:25:43 +08:00
parent 126dbc57e2
commit bbf24c282a
49 changed files with 1710 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/features/application-tool-navigation/progress.md
+46
View File
@@ -1,5 +1,51 @@
# 应用导航实施进度
## 2026-10-05：展开状态缓存复查
独立复查发现，首次 A10 修复在每个折叠项挂载时保存默认值；无引用的消息也会因引用 Hook 留下一条记录。下节首次验收只检查了 DOM 上限，没有覆盖这部分缓存。新增回归在该实现上失败：分批挂载 10,000 个未操作的消息作用域后，预期缓存为 0，实际为 10,000；恢复默认状态后也没有释放条目。
现改为只保存偏离自动默认值的用户选择，恢复默认时立即删除覆盖项。消息更新后，清理逻辑只检查已保存的覆盖项，借用历史面板已有的消息索引定位来源，清除已删除消息、工具／输入／推理块／子代理／引用及已过期的流式默认值对应的记录。清理不在滚动或渲染期执行。正常的虚拟行卸载、子代理收起继续保留有效选择，行卸载期间完成的推理仍按原规则自动收起。
本次执行结果：
- `npm test -- --project unit src/renderer/src/message-expansion.test.tsx src/renderer/src/ChatHistoryPane.test.tsx src/renderer/src/ChatTimeline.test.tsx src/renderer/src/SupervisorWorkspace.test.tsx`：4 个文件、112 项通过。其中新增 4 项覆盖 10,000 个未操作作用域零缓存、用户选择跨卸载保留、恢复默认释放、消息及折叠项删除、未挂载推理完成。
- `npm test -- --project unit src/renderer/src/App.test.tsx -t 'keeps each conversation history window|isolates history and task strips'`：2 项通过，346 项未选中。
- `npm test -- --project integration tests/message-expansion.electron.test.ts`：三轮交替比较后，最终测量探针调整也单独复跑通过。`npm test -- --project integration tests/frosted-glass.electron.test.ts`：1 项通过，继续覆盖浅深主题、原生点击、跳底、锚点和缓存切换。
- `npm run typecheck`、`npm run lint` 通过。该组定向验收后，完整集成测试为 6,136 项通过、0 失败、87 跳过，见[阶段修复验收](../../review/stage-audit-fixes-2026-10-05.md#最终检查)；本组模型调用 0 次。
Electron 环境与合成消息结构同下节。此次比较对象为首次 A10 的默认值缓存实现和本次稀疏覆盖实现，不是 `126dbc57`。测试通过 `GB_EXPANSION_DENSE_SOURCE` 加载修改前保留的模块副本，其余生产 Renderer 源码相同。fixture 临时观察首次展开状态写入，捕获该 Map 后恢复原 `Map.set`；产品未增加诊断接口。每个数据量先进行 200 次未操作导航，实际见到 1,397 个不同消息行（一轮旧实现为 1,401），再原生展开 13 条消息的推理、工具结果和输入，返回原行确认恢复，用 Space 收起一项，最后删除消息。
| 历史消息数 | 旧实现：未操作导航后条目 | 新实现：未操作导航后条目 | 用户操作后：旧／新条目 | 删除消息后：旧／新条目 |
| --- | --- | --- | --- | --- |
| 2,000 | 5,600 | 0 | 5,708 / 38 | 5,708 / 0 |
| 10,000 | 5,604 | 0 | 5,904 / 38 | 5,904 / 0 |
以上计数在三轮比较中一致。交互阶段两版均最多采样到 15 个消息行、926 个 DOM 元素，原消息的三个展开项均恢复；A09 迟到来源响应检查也继续通过。计数针对缓存条目，不是浏览器堆内存字节数。
| 消息数 | 旧实现每轮导航中位数（ms） | 新实现每轮导航中位数（ms） | 旧实现每轮 p95（ms） | 新实现每轮 p95（ms） |
| --- | --- | --- | --- | --- |
| 2,000 | 38.8 / 38.8 / 38.4 | 38.8 / 39.1 / 38.5 | 40.4 / 39.6 / 46.9 | 39.2 / 46.7 / 40.1 |
| 10,000 | 38.7 / 39.1 / 38.9 | 38.8 / 38.9 / 38.6 | 39.7 / 39.5 / 46.9 | 39.4 / 39.3 / 46.6 |
导航计时仍为目标聚焦后再等待两个动画帧，每轮 14 个样本；此次先扫过历史，不能与下节首次进入的计时直接比较。三轮比较中，200 次未操作导航的总耗时，旧实现为 4,753.5–5,080.5 ms，新实现为 4,820.3–5,228.8 ms。数据证明默认条目和删除后的条目不再积累，未证明提速；未测堆内存峰值、低端机节流或完整 App／生产 IPC。
## 2026-10-05：虚拟消息行的展开状态
聊天历史面板通过 `message-expansion.tsx` 按消息、子代理及折叠项的稳定标识保留展开状态。虚拟行卸载后只保留状态值，不保留 DOM；仍沿用最多 8 个近期交互行及焦点、选区、问题的挂载保护。阅读行为见[聊天阅读状态](./ui-design.md#聊天阅读状态)。本次没有修改 Runtime 执行或消息持久化。
旧代码上的新增组件回归在返回原消息时失败：预期展开，实际收起。最终三文件 108 项通过，覆盖嵌套工具、父子同名调用隔离、手动收起、行卸载期间流式完成、既有焦点／选区及平滑滚动。命令：`npm test -- --project unit src/renderer/src/ChatHistoryPane.test.tsx src/renderer/src/ChatTimeline.test.tsx src/renderer/src/SupervisorWorkspace.test.tsx`。另有会话存储、同步、流式缓冲、窗口模型和侧栏回归 48 项，以及 App 历史加载、重试、热切换、流式隔离和超过 500 条消息的定向回归 5 项通过。
真实 Electron 使用当前 `ChatHistoryPane`、样式及 Markdown 渲染，数据为 2,000／10,000 条合成助手消息，每条含正文、推理、工具结果与输入。Windows x64、Electron 44.5.1、1280×800、缩放 1；原生鼠标展开 13 条相距较远的消息，确认原行卸载后再返回，并用原生 Space 操作。基线为临时 worktree 中的 `126dbc57`。三轮交替运行 `npm test -- --project integration tests/message-expansion.electron.test.ts`；基线运行另设 `GB_HISTORY_SOURCE` 指向该 worktree。每轮、每种数据量采样 14 次导航；计时从请求消息定位到目标 article 获得焦点后的两个动画帧，含这两个帧的等待，不等同于纯渲染耗时。
| 消息数 | 基线每轮中位数（ms） | 修复后每轮中位数（ms） | 基线每轮 p95（ms） | 修复后每轮 p95（ms） |
| --- | --- | --- | --- | --- |
| 2,000 | 47.0 / 39.2 / 39.3 | 39.4 / 39.0 / 39.1 | 177.6 / 136.4 / 137.4 | 129.7 / 128.8 / 138.7 |
| 10,000 | 47.2 / 39.4 / 39.2 | 38.8 / 39.2 / 39.5 | 56.0 / 40.2 / 43.7 | 41.4 / 39.7 / 40.0 |
两版在两种数据量下的采样最大值均为 15 个消息行、926 个 DOM 元素；基线三轮均丢失原消息的三个展开状态，修复后三轮均恢复。数字只证明本场景的 DOM 数量有界，计时存在波动，不据此宣称提速或整体性能预算达标。该 Electron fixture 替换了数据来源，不是完整 App、生产 IPC 或真实模型验收；模型调用 0 次。
既有 `npm test -- --project integration tests/frosted-glass.electron.test.ts` 单独复跑通过，覆盖浅深主题、原生点击、跳底、阅读锚点、会话缓存、加载更早消息及 960×540 短窗口。首次与监督者布局测试合并运行在工具的 60 秒期限内未返回结果，不计为通过；`tests/supervisor-layout.electron.test.ts` 随后单独后台运行通过，总耗时 65.26 秒，stderr 为空。最终完整 typecheck、全仓 lint 和修改范围差异检查通过。首次 lint 曾受其他并行修改中的三个 Runtime 错误阻断，后续复跑已通过。未运行完整测试集或低端机节流测量。
## 2026-10-04：新建本地项目必选目录
对应 FR-14 的项目创建入口，规则见 [PRD](./prd.md#fr-14-项目活动汇总)及[界面设计](./ui-design.md#10-项目活动汇总)。创建表单已增加中英文必填提示、无障碍关联及空目录提交检查；共享创建 schema 拒绝空白路径，更新 IPC 使用独立 schema，保留历史空目录项目的保存能力。
docs/features/application-tool-navigation/ui-design.md
+8
View File
@@ -270,6 +270,14 @@ CPU 4% · 内存 620 MB · 桌面进程 7
导出也适用于消息通道会话。持久化与刷新规则见
[会话置顶存储](../assistant-workbar/execution-history-storage.md#会话置顶)。
### 聊天阅读状态
在同一历史面板内，滚动到别处再返回时，消息的推理、工具结果、工具输入、引用和子代理详情保留用户的展开或收起选择。子代理收起后重新展开，其内部工具详情也保留选择；不同消息及父子工具分别记忆。状态保留在历史面板中，不依赖把所有已展开的消息留在 DOM 中；面板被缓存淘汰或应用重启后不恢复这些临时阅读选择。
未操作的折叠项不留下默认状态记录；用户恢复默认选择、消息或对应折叠项被删除后，释放相应记录。正常滚动卸载不视为删除。
推理仍在流式输出时默认展开、完成时自动收起，流式期间手动收起不因滚动重挂载而重新展开。有焦点、文本选区端点、待回答问题和待审批项的消息继续按既有规则保留挂载；平滑跳到底部及滚动锚定行为不变。
## 9. 未来插件入口
FR-15、US-F1／US-F2 的市场 URL、YAML 导入导出及 ShareServer 分发在后续设计中定义。
docs/features/assistant-workbar/progress.md
+9
View File
@@ -1,5 +1,14 @@
# 工作栏实现与验证进度
## 2026-10-05：Runtime 提交失败与启动取消
本机 OpenCode 提交失败后会结束所属 SSE 等待；远程原生 Session 启动等待期间，
取消与其他 binding 的控制请求可继续处理。保留无默认 Prompt 总时限、共享 peer
隔离、取消后的会话清理及原有事件顺序。实现规则见
[进程复用设计](./runtime-process-reuse-technical-design.md)，旧/新回归、当前源码
Windows/Linux x64 实测、真实数据检查及本轮 5 次文本模型调用计数统一记录在
[统一执行进度](../unified-execution/progress.md#2026-10-05-runtime-生命周期审查修复)。
## 2026-10-04：移除成果页，工作区导入与文件时间
对应 [FR-WF1～FR-WF3、US-WF1～US-WF3](./workspace-files.md)。成果 Tab、目录注册及独立导入
docs/features/assistant-workbar/runtime-interactions.md
+5
View File
@@ -17,6 +17,11 @@ Host 环境。2026-09-14 的已发布 Desktop `0.13.2` / Agent `0.11.25` 已包
## 运行与失败
OpenCode 提交请求失败时直接显示该失败，不等待没有被接受的请求产生结束事件。
远程 Runtime 在原生 Session 启动期间也可取消；启动等待不阻塞其他会话的状态读取。
取消及清理范围仍限于所属请求，完整规则见
[Runtime 进程复用技术设计](./runtime-process-reuse-technical-design.md)。
- 结构化 yes/no 是普通选项，不从日志、自然语言或 Shell 输出猜测用户意图。
- 前台同一请求的待答问题按公开 `questionId` 去重，按到达顺序保存在消息的
`pendingQuestions` 中。每次显示队首表单；有多个待答请求时显示数量。后续提问和重复
docs/features/assistant-workbar/runtime-process-reuse-technical-design.md
+15
View File
@@ -168,6 +168,11 @@ Session 和 Prompt 路由删除产品模式，按实际能力和请求归属接
使用独立的 ACP 取消路径。
现有 `snapshot: false` 必须保留。
提交 Prompt 的 Promise 与 SSE 消费同时运行。提交返回错误、抛错或控制请求超时后，
立即中止本请求的 SSE 订阅并保留提交错误；不能等待服务端为未接受的 Prompt 发送
`session.idle`。回收仍先 abort 订阅再结束迭代器，随后完成该 Session 的有界取消，
不关闭其他会话的订阅或共享 Server。生产运行不增加整个 Prompt 的默认总时限。
`mcpMutationTail` 目前属于 Runtime 对象；共享后同一原生目录的变更必须由同一 owner
串行协调。注册名称、工具可见性、knowledge token 和清理仍按请求区分，不能用一个全局
“当前 MCP 列表”覆盖同目录或跨目录的其他请求。探针未覆盖动态 MCP，这是实施验收项。
@@ -282,6 +287,16 @@ Agent 当前 Runtime installation + 兼容配置
- 同一 PID 的多个 binding 不代表同一权限或同一 operation。Host/installation identity
变化仍使用已有失效和退役规则，不把不同 Host、账号或 Runtime generation 合并。
`runtime/startPrompt` 校验及 owner 登记经过 backend 控制队列，原生握手、Session
创建/恢复和模型路由准备在队列外等待。协议接收端也不等待该 RPC 的最终响应才分派
后续帧；未完成的响应继续占用已有 request channel，沿用连接通道容量限制及 FIFO
写入。其他方法的分派顺序保持不变，Prompt 终态仍经 backend 控制队列提交。
同一 binding 的相同启动请求共用 Promise，内容不同的并发启动返回冲突。
启动等待属于 Session owner，可以被取消、启动 watchdog 或关闭中断。取消后不得
发送 Prompt；原生调用迟到返回的 Session 只关闭自身，不能回收仍服务其他 binding
的共享进程。原生握手本身仍由进程 owner 共享，一个等待者退出不取消其他等待者。
原生 `chat.message` 在模型请求前设置该 Session 的工具与模型路由，不再按产品模式
过滤 Shell、编辑或写入；请求级端点与子会话归属仍独立。
OpenCode 1.18.29 的 ACP 不转发未注册子 Session 的权限请求，且原生子代理只继承父
docs/features/conversation-supervision/progress.md
+18
View File
@@ -4,6 +4,24 @@
当前记录以已验证生产行为为准。监督者尚未覆盖全部 user stories。
## 2026-10-05 后端阶段审查 A03／A04／A05
对应 SL-5、SL-8、FR-S6、FR-S10。生产候选读取现在将批次项目和跨项目设置传到只读 Worker；最终候选读取返回后检查暂停／取消；故事归属和拆分在原写事务内拒绝已移除或合并的目标。存储、停止与重试规则见[技术设计](./technical-design.md#单次执行与取消)。没有 schema 变更，原始消息、历史结果及人工确认字段保留。
先加回归、后改实现的结果：8 个新用例中旧代码失败 7 个，取消用例原本通过。失败覆盖跨项目开／关两种生产候选、最终候选读取期间暂停、归属期间移除／合并目标、拆分前移除功能／子线索。旧暂停用例实际返回 `completed` 并发布结果；旧归属用例写入隐藏目标且把事件标为已处理。修复后暂停不发布结果或 checkpoint，继续仍复用原批次；失效故事批次回滚且事件可重试。生产身份测试补充真实项目事件关联，保留 UUID 别名、确认字段及失败后继续的断言。
验证命令与结果：
- `npm test -- src/main/assistant/supervision-production.test.ts src/main/assistant/supervision-worker.test.ts src/main/assistant/supervision-stories.test.ts src/main/assistant/supervision-review.test.ts src/main/assistant/supervision-timeline.test.ts src/main/assistant/supervision-experiences.test.ts src/main/assistant/supervisor-service.test.ts src/main/readonly-query-reader.test.ts`：8 个文件、96 项通过。Worker 回归每轮使用两个项目、422 条来源，并检查候选隔离、实体数量、外键及暂停后的完整发布。
- 本次修改的 Main 源码、测试和验证脚本定向 ESLint、`git diff --check` 通过。`npm run typecheck` 首轮发现本轮 fixture 缺默认设置字段，修正后曾被并行 `tests/message-expansion.electron.test.ts:39` 类型错误阻塞；该文件由其负责方修正后，Main／Agent／Web 三组最终全部通过。本轮未修改该文件。
- 定向验收时 `npm run lint` 曾被并行 OpenCode 修改中的三项错误阻塞；负责方修正后，最终全仓 lint 与 typecheck 均通过。两份后端文档扫描阻断项为 0；人工复核保留取消与事务顺序的边界说明。完整集成结果见[阶段修复验收](../../review/stage-audit-fixes-2026-10-05.md#最终检查)。
- `node --import jiti/register scripts/supervision-audit-validation.ts scale <临时父目录>`：真实文件 SQLite，10 个项目、1,000 个实体、10,000 个事件、10,000 条事件实体关联、10 条来源，库文件 10,964,992 字节。三轮交替查询中，每轮十次旧相关子查询合计 3,517／5,302／4,190 ms；新 Worker 查询合计 39.18／34.01／36.04 ms，包含传输。逐项目返回的 100 个候选 ID 及顺序与旧 SQL 完全一致；跨项目读取每轮 0.95～1.79 ms。120 个事件的单批归属事务为 6.63 ms。计数不变，`foreign_key_check` 为空，`integrity_check` 为 `ok`。
- 查询测量是同一合成库内的 SQL 对照，非完整 App 基线；同时有其他本地验证任务运行。原相关查询在修复传参后首次实测暴露每十次 3.60～4.65 秒耗时，随后改为实体集合查询。没有新增索引或迁移，也不据此宣称整窗性能改善。
真实模型检查沿用 `scripts/supervision-production-live.ts` 的环境文件读取与 `ModelAgentRuntime` 无工具模式，由新增合成验证脚本执行。`node --import jiti/register scripts/supervision-audit-validation.ts live <临时父目录> .env.deepseek.local` 只发送一条 147 字符合成消息，真实生产工厂和文件 Worker 完成提取、保存及故事归属。外部请求准确为 **2 次**：提取 1 次、故事归属 1 次；无变化重跑新增请求 0 次。原文片段精确重建，外键与完整性检查通过，总耗时 3.84 秒。脚本上限为 3 次 HTTP 请求、每次模型阶段 45 秒、1,800 输出 token；凭据仅在进程内读取，终端与指标文件只输出计数和验证信息。本机继承的 TLS 环境设置未由本次修改。
报告位于系统临时 `opencode/supervision-audit-Ggn5uW/metrics.json`（规模检查）和 `opencode/supervision-audit-WNu08s/metrics.json`（模型检查）。只写隔离合成库，未读取或修改用户库，未运行完整 App／Electron 回归或整包构建；没有提交。修改位于桌面监督服务及其 SQLite Worker，GoodBuddy Agent 与远程 Runtime 控制路径未改变。
## 2026-10-04 螺旋工具栏与事件颜色修正
接续未提交的回顾布局调整。平铺与螺旋共用标题工具栏样式，项目层级菜单放在面包屑旁，画布内的视角入口和左下角圈数说明已移除。默认斜俯视，拖动及键盘操作保留；两种图谱均以共享 InlineHelp 的 i 图标打开图例。共用历史回顾栏、下钻返回、详情选择与中窄窗口详情面板保留。当前规则见 [UI 设计](./ui-design.md#故事线图谱)。
docs/features/conversation-supervision/technical-design.md
+10 -4
View File
@@ -13,11 +13,13 @@
本文回答如何在现有 GoodBuddy 桌面端中实现监督者。它不改变产品范围，也不把模拟 Demo 当作生产数据模型。
FR-S11 的读取架构见[时态 Story Graph 内置 MCP 设计](./story-graph-mcp-design.md)。三个只读工具通过 `readStoryGraph` 投影现有 SQLite，Main 在发现、调用和返回前检查监督者启用、会话开关及 Runtime 分配。绑定携带会话 ID，按主键读取当前设置；原生客户端的复用键包含会话 ID 和开关值。本地 MCP、Model、Harness Main 代理和远程受管工具通道共用此入口；会话开关复用 `context_state_json`，无 schema 迁移。该文独立定义对象／版本合同、时间语义、配置映射及后续跨 scope 复用和记忆过渡。当前 memory 背景读取、精确 scope checkpoint 与候选身份保留；结果快照不支持 `as_of` 历史重建。
FR-S11 的读取架构见[时态 Story Graph 内置 MCP 设计](./story-graph-mcp-design.md)。三个只读工具通过 `readStoryGraph` 投影现有 SQLite，Main 在发现、调用和返回前检查监督者启用、会话开关及 Runtime 分配。绑定携带会话 ID，按主键读取当前设置；原生客户端的复用键包含会话 ID 和开关值。本地 MCP、Model、Harness Main 代理和远程受管工具通道共用此入口；会话开关复用 `context_state_json`，无 schema 迁移。当前监督阶段使用共享时间线 checkpoint；候选按下文的批次项目与跨项目设置筛选。memory 继续作为背景读取，结果快照不支持 `as_of` 历史重建。
生产入口由 `supervision-production.ts` 组装服务、SQLite、共享池和无工具 Runtime。`supervision-review-store.ts` 保存冻结来源清单，按有界页和片段供 `SupervisorService` 派发；叶子及连续位置先提交，导航和完整结果之后发布。消息已有知识引用保留本地或外部 locator，已确认记忆通过独立背景输入提供。不会检索外部全库。详细存储、调度及当前限制统一见[分块调度第 0 节](./review-scheduling-design.md#0-生产接线与剩余边界)。
模型实体 `id` 只在单次输出内有效。Main 从同一 scope 的故事线提供最多 100 个未撤销实体候选，生产提示只暴露 `candidateRef`（如 `known_1`）、名称和说明。模型显式选择候选后，Main 转换为严格 UUID 类型的内部 `persistedId`。服务校验候选集成员和重复映射，保存事务再次按实体主键校验故事线归属及撤销状态。没有有效候选引用时分配新 UUID，不按名称或裸模型 ID 合并。来源仍按每次结果分配 UUID，保留原始 `source_id` 和 locator。
模型实体 `id` 只在单次输出内有效。生产服务将批次的 `projectId` 和 `crossProject` 经 `supervisionCandidates` 传到只读 Worker，再由 `listSupervisionCandidates` 查询共享时间线。跨项目关闭时，只提供该项目当前事件关联的未撤销实体；开启时允许其他项目的实体。候选仍最多 100 个，按更新时间和 ID 排序。查询先取得项目事件关联的实体集合，再筛选候选，避免对每个实体重复扫描事件。省略批次参数的旧读取入口保留精确 scope 查询。
生产提示只暴露 `candidateRef`（如 `known_1`）、名称和说明。模型显式选择候选后，Main 转换为严格 UUID 类型的内部 `persistedId`。服务校验候选集成员和重复映射，保存事务再次按实体主键校验存在性及撤销状态。没有有效候选引用时分配新 UUID，不按名称或裸模型 ID 合并。来源仍按每次结果分配 UUID，保留原始 `source_id` 和 locator。
新实体省略 `candidateRef`，不要求模型生成数据库 ID。未知非空 `candidateRef`、冲突身份和候选集之外的 UUID 均拒绝。旧输出中的 `persistedId` 仅在 UUID 合法且属于候选集时复用；空值、占位符和格式错误值不能证明已有身份，保留为独立新实体。局部 ID 或同名不会触发合并。
@@ -71,6 +73,10 @@ schema 47 的四张批次相关表使用外键随监督运行清理，未完成
`supervision:execution` 返回进程内 `{ active, runId?, stopping? }`，配置读取期间可有 `active: true` 而尚无 runId。`supervision:cancel({ runId })` 先在既有 `supervision_runs` 写入 `cancelled`、清除错误并保存取消时间，再向父 controller 传播 abort；重复取消保留原时间。该接口等待执行 Promise 结束，包含并行批次的 `allSettled` 和 Runtime `releaseConversation`，之后才释放准入。暂停只请求 abort，执行停止后保存 `paused`；取消优先于暂停。迟到模型输出不得保存叶子、导航或完整结果，成功批次保留，自动 checkpoint 不推进。发布是同步 SQLite 事务，已完成或无变化的运行拒绝取消，不撤销已发布结果；本次无 schema 迁移。
发布前重读已保存批次所需候选后，再检查父 signal。此时收到暂停或取消，走原有停止分支；完整叶子和导航保留，结果及 checkpoint 尚未提交。该检查与同步保存之间没有新的异步等待。
故事归属和子线索拆分在既有写事务内，按主键检查模型选中的目标、父故事和跨项目功能仍为 `current`。模型等待期间若用户移除或合并目标，整批写入回滚，包含新建故事和已处理标记；重新整理使用当前候选。拆分同样检查原功能及目标子线索。已发布回顾、用户调整和此前成功批次保留，不增加版本表或恢复日志。
Preload 暴露类型化 `execution`、`cancel`，取消输入使用 UUID schema 并校验可信 sender。活动 UI 用实时执行状态覆盖持久记录的停止显示；工作回顾只在发起前查询执行状态，Main 仍作最终准入判断。`resume` IPC 直到运行结束才返回，Renderer 发出请求后释放提交锁并独立处理结果，确保继续中的回顾仍可暂停或取消。
`App` 将既有通知回调经 `HeartbeatCenter` 传给 `SupervisorWorkspace`。回顾操作用 `supervisor-review` 去重键发送本地化 Toast，结果读取失败仍写入 `loadError` 并就地重试；实体、关系操作和来源读取失败也使用通知。工作回顾不再为状态条轮询执行状态，历史读取不发送操作通知。请求锁覆盖发起前检查和整次运行；页面刷新只使旧结果选择失效，不丢弃运行结束反馈。卸载后忽略迟到响应，检查阶段尚未提交的回顾不再发起，已提交的后台运行不取消。活动查询、原始错误持久化和 Main 生命周期保持原路径。
@@ -98,7 +104,7 @@ IPC `supervision:suggestions`、`supervision:suggestion-action`、`supervision:r
只有实际送入模型、通过结果校验且成功落库的完整片段推进位置。心跳报告及其进度、监督结果及其进度分别在各自 SQLite 事务提交。监督服务串行执行，后续自动请求在前次保存后重新收集。报告成功而监督失败时，下一次自动检查跳过已成功的报告输入，但重试监督输入；无变化不创建报告、来源或图谱事件。
已有同 scope 故事线的 scope 表示和实体 ID 保留；比较项目集合时忽略排序。模型接收最近摘要和同 scope 最多 100 个未撤销实体的候选引用、名称、说明，显式选择候选才复用，身份转换按上文执行。不同范围不合并，已有重复实体不自动修复。知识引用继续以独立来源保存 locator；当前记忆和旧摘要不作为新事件。
已有故事线的 scope 表示和实体 ID 保留；比较项目集合时忽略排序。生产候选按上文的项目归属与跨项目设置读取，显式选择候选才复用；已有重复实体不自动修复。监督 checkpoint 的共享时间线规则见[故事线模型](./storyline-model-design.md)。知识引用继续以独立来源保存 locator；当前记忆和旧摘要不作为新事件。
迁移在事务中扩展心跳计划及运行表的状态 CHECK，保留列、索引、ID、计划、报告与引用；消息版本列使用默认值，无需遍历或重写旧正文。进度初始为空，首次自动运行从配置窗口开始。报告保留期限覆盖 `no_change` 运行，但不删除来源进度；删除报告不触发重新消费。
@@ -326,7 +332,7 @@ IPC 返回图谱查询结果时使用分页和有界字段；详情中的来源
## 当前剩余差距
- 实体与关系 revoke 保存状态；界面没有 undo 或恢复入口。
- 跨 run identity 依赖同 scope 候选 UUID 的显式引用，不自动合并历史重复实体；模型漏选候选时会创建新身份。
- 跨 run identity 依赖候选 UUID 的显式引用，候选范围受批次项目及跨项目设置控制；不自动合并历史重复实体，模型漏选候选时会创建新身份。
- 结果图谱使用真实事件实体连线，侧栏已按固定目标过滤并支持结果直达图谱；逐事件状态回放和 Experiment 尚未实现。
- 用户暂停已接到排队/在途 signal，并保留已保存批次；源版本变更后的局部重算、完整模型配置冻结及其他限制见分块调度第 0 节。
- 监督知识实体与知识库正文条目仍是不同对象，知识正文只能通过现有条目定位和预览接口处理。
docs/features/conversation-supervision/ui-design.md
+2
View File
@@ -96,6 +96,8 @@ Modal 按[共享表单 Modal 规则](../../../UI-DESIGN.md#615-表单-modal)复
选择历史结果后，图谱读取该结果的成员和内容，历史菜单显示其回顾区间和生成时间。切换时清空旧图谱和详情并显示加载状态，迟到请求不得替换新选择。确认、修订和移除反馈更新当前所选结果，后续自动回顾不改写旧结果。
切换语言或手动回顾完成引起刷新时，同时解除被替代的来源读取、实体和关系操作的等待状态。新图谱读取完成后，历史选择、刷新和详情操作恢复可用；旧请求迟到时既不显示旧内容，也不能解除后来发起的请求的等待状态。
手动“回顾当前进展”新建回顾，活动页“继续”恢复原 run；运行中再次发起按上文显示提示，停止清理结束后才能开始新回顾。失败保留上次结果、本次范围和成功批次；已取消回顾不能继续。手动操作不推进自动位置，删除报告也不重置自动位置。
## 会话侧栏
docs/features/remote-host/technical-design.md
+6
View File
@@ -365,6 +365,12 @@ Runtime 包。2026-09-19 完整桌面验证覆盖联合包安装、CN 项目创
同次验证复现原生 ACP 冷启动超过 15 秒控制超时。`runtime/startPrompt` 的控制等待
现至少为 30 秒，其余控制请求沿用原时限；Runtime 外层仍保留启动超时和取消处理。
2026-10-05 修复启动等待阻塞控制队列的问题：原生启动等待同时释放 backend 全局控制
队列和协议接收分派，取消、watchdog 及其他 binding 的控制请求可继续处理。相同启动
请求只执行一次，迟到返回的已取消 Session 单独关闭；不增加 Prompt 总时限或新协议
阶段。实现规则见[共享进程与 Session 所有权](../assistant-workbar/runtime-process-reuse-technical-design.md#61-连接与所有权)，
本次源码 Host 验证及调用计数见[统一执行进度](../unified-execution/progress.md#2026-10-05-runtime-生命周期审查修复)。
## ACP 与断线
- 管控面只负责有界 JSON-RPC：连接、查询、启动、取消、关闭和重连。数据面只负责
docs/features/telegram-channel/progress.md
+21 -1
View File
@@ -35,6 +35,26 @@ npm test
集成集合及 301 项复跑的完整命令未随计数提供，这里不推测其文件清单。真实本地代理 fixture 见 [`tests/telegram-proxy.electron.test.ts`](../../../tests/telegram-proxy.electron.test.ts)；其本地代理结果不证明外部 Telegram Bot 可用。探针操作见 [API 联调](./api-testing.md)，探针成功也不包含模型验收。
## 2026-10-05 通道审计修复验证
A06 的图片结果回归使用现有 IPC executor 图片事件 fixture，接入生产 `ChannelService` 和内存 SQLite 发件箱。修复前回复状态为 `failed`；修复后状态为 `completed`，图片附件字节保持一致，桌面会话仍记录成果 ID。未调用付费图片模型。
A07 的 Renderer 回归覆盖推送状态为 `error`、`stopped`、`running`、`starting`、`disabled` 的无修改保存。前两种状态在修复前没有提交配置，修复后能够提交；其余状态保持不提交。扩展的 Electron 场景通过真实设置 UI、Preload、IPC、Manager 和驱动验证 409 后无修改保存恢复轮询，以及正常连接时再次保存不重启。Telegram API 在网络边界使用替身；本次运行有 2 次本地 HTTP 模型调用、0 次外部请求。
A08 的钉钉回归使用生产传输、服务和 SQLite 发件箱，HTTP 请求只发送到 loopback fixture。首次 HTTP 200 携带非零 `errcode`，修复前被当作成功；修复后记录一次失败并保留上下文，第二次成功响应完成投递，executor 只执行一次。另有空响应、缺少错误码、JSON null、无效 JSON 和超限响应回归。
本轮聚焦验证：6 个 channel / Renderer suite 共 106 项通过；IPC 图片、文件与 Telegram 场景 3 项通过；Electron 场景 1 项通过。修复前选择性回归为 9 项失败、3 项通过。命令如下：
```powershell
npm test -- src/main/channels/dingtalk-channel-driver.test.ts src/renderer/src/ChannelSettingsSection.test.tsx src/main/channels/channel-manager.test.ts src/main/channels/channel-service.test.ts src/main/channels/telegram-channel-driver.test.ts src/main/channels/sqlite-channel-state.test.ts
npm test -- src/main/ipc.test.ts -t "returns a generated image only|creates a bounded result file|routes Telegram settings"
npm test -- tests/telegram-channel.electron.test.ts
```
这些结果验证本地生产连接关系，不替代真实平台收发或图片模型验收。本轮未改 Agent、Runtime 协议或执行策略，未做性能改善声明。
补充检查：钉钉错误码断言加入后，单独复跑 9 项通过；修改的 TS 文件 ESLint、Renderer typecheck 和 `git diff --check` 通过。早期全仓检查受到并行修改中的类型与 lint 错误阻塞，负责方修正后最终检查均通过；完整测试为 6,136 项通过、0 失败、87 跳过。汇总见[阶段修复验收](../../review/stage-audit-fixes-2026-10-05.md#最终检查)。
## Main 性能对比
基线为 `78afec77758f3c175f8e2b80e5be4327e13b4689` 的临时 detached worktree，当前为包含 Telegram 改动的工作区。按基线、当前交替执行 `npm run perf:main` 各 3 次。环境为 Windows x64、Intel Core Ultra X7 358H、Electron 44.5.1、Node 24.21.0；每轮使用隔离数据库，包含 1000 个会话、20008 条生成消息、24000 条活动记录，每个场景预热后测量 15 次，无外部模型调用。
@@ -62,7 +82,7 @@ worker 读取、活动启动、增量更新和同步首页查询在六轮中均
## 待完成
- 在可完成操作系统信任确认的环境中复跑显式启用的代理测试，记录最终结果；保留单次成功和后续导入超时两项证据，不把默认跳过视为通过。
- 跟踪全量测试中的 Runtime 清理与帮助弹层间歇性失败；两者均有原样复跑通过证据，未为此修改无关产品逻辑。
- Runtime 清理用例的 GC 生命周期问题已定位并修正测试夹具，完整集成测试通过，见[GC 复查](../unified-execution/progress.md#sdk-cleanup-timeout-复查)。历史帮助弹层间歇性失败在本轮完整测试中未出现。
- 提供有效测试凭据后运行生产实时探针，记录连接及固定回复结果；本次缺少凭据的阻塞不以历史 Node 成功替代。
- 从真实设置页保存并启用专用 Bot，在手机发送授权请求，经过实际模型产生回复并核对桌面历史；再按 PRD 验证连续上下文、隔离、无害工具任务和恢复场景。当前没有真实 Bot 与模型完整链路的通过记录。
- Main 测量未覆盖迁移和完整 UI；后续验收需按[性能原则](../../architecture/performance-principles.md)区分实测路径与未测路径。
docs/features/telegram-channel/technical-design.md
+4
View File
@@ -27,6 +27,8 @@
结果先进入现有发件箱，发送失败由服务有限重试，不重新调用模型；失败计数达到 5 或遇到永久错误后停止补发。发送前校验目标会话中的 Bot ID，拒绝把旧 Bot 结果交给新 Bot。附件只附加桌面查看提示。
生成图片后，executor 先把 `artifactIds` 写入桌面会话，再向 `ChannelService` 返回通道契约中的状态、正文、错误和附件。图片字节保留在附件中；桌面成果 ID 不进入严格校验的通道结果，避免成功任务被误报为“无效结果”。该转换位于本地和远程 Runtime 事件处理之后，不改变 Runtime 或 Agent 协议。
驱动按最多 4096 个 UTF-16 码元拆分纯文本，并避开代理对中间位置；不设置 `parse_mode` 或引用原消息。分段进度只在驱动内存保存，最多 128 条，停止时清空。单次发送的 429 最多等待重试 3 次，仍失败则交回发件箱处理。跨重启补发与不确定网络结果允许产生重复段落。
停用会中止轮询、发送等待、活动执行与排队工作，等待活动操作结束后报告停止。清除凭据时设置页同时提交 `enabled=false`；底层拒绝启用但无 Token 的配置。Token 替换先验证，失败不停止旧服务。项目与历史不因停用或清除凭据删除。
@@ -37,4 +39,6 @@ Manager 通过 `{ channel, status }` 增量 IPC 推送状态，忽略旧服务
Renderer 的 `channel-status-store.ts` 订阅事件，selector 只向状态区域提供对应通道数据。首次快照不会覆盖已收到的较新事件；状态更新不重新加载整份设置，不重置 Token 或白名单草稿。配置页复用共享页签、开关、项目设置字段和通知控件。
保存时读取状态 store 的最新值。Telegram 已启用、配置可编辑且状态为 `error` 或 `stopped` 时，即使字段未变，也提交当前配置以重启连接；`running`、`starting` 状态下的无修改保存不重启轮询。环境变量配置仍为只读，测试连接不改变轮询状态。
源码入口：[`telegram-channel-driver.ts`](../../../src/main/channels/telegram-channel-driver.ts)、[`channel-manager.ts`](../../../src/main/channels/channel-manager.ts)、[`channel-service.ts`](../../../src/main/channels/channel-service.ts)、[`channel-settings-store.ts`](../../../src/main/channels/channel-settings-store.ts)、[`channel-status-store.ts`](../../../src/renderer/src/channel-status-store.ts)、[`ChannelSettingsSection.tsx`](../../../src/renderer/src/ChannelSettingsSection.tsx)。
docs/features/unified-execution/progress.md
+95
View File
@@ -1,5 +1,100 @@
# 进度与证据
## 2026-10-05 Runtime 生命周期审查修复
A01（远程启动阻塞控制队列）和 A02（本机 OpenCode 提交失败后等待静默 SSE）已修复。
远程启动等待释放 backend 控制队列及协议接收分派，取消、watchdog、关闭和其他
binding 可以继续处理；Session owner 合并相同启动、拒绝冲突，并关闭取消后迟到的
原生 Session。本机提交错误立即唤醒所属 SSE 消费，保留原错误和既有 Session 取消。
两条实现均未增加整个 Prompt 的默认总时限；共享进程、终态提交和写帧顺序规则见
[Runtime 进程复用设计](../assistant-workbar/runtime-process-reuse-technical-design.md)。
### 确定性复现
持久回归中，本机拒绝、错误响应、10 ms 提交超时三种情况在旧代码经过 100 ms
假时钟后仍未结算；远程共享进程中的第二个 Session 启动被挂起时，旧代码经过
200 ms 后，取消/截止时间和同进程另一 binding 的查询均未结算。上述五项先运行旧
实现，全部按这些断言失败。真实 Host 首轮还定位到协议 dispatcher 串行等待启动
响应，新增帧级回归在修复前只分派 `start`，没有分派后续 `cancel` 和 `peer`。
修复后的九项新增回归通过，另覆盖启动 watchdog、默认关闭时限、相同启动重放及
冲突。共享 peer 保持 running；迟到 Session 收到自身的 `session/close`，取消的
启动不发送 Prompt。原始审查探针曾在 131 秒假时钟后观察到启动、取消、peer 查询
仍等待，默认 10 秒 dispose 报超时且 stop 次数为 0，现有关闭与 watchdog 回归不再
等待原生初始化响应。各假时钟值是确定性边界，不是系统性能测量。
### 当前源码实机验证
复用已有 lifecycle harness，用 esbuild 重建当前 Desktop driver、Agent daemon、
CLI/helper；凭据从 GoodBuddy 已有加密配置的临时副本加载，SSH 校验已固定 Host
identity。共享 Linux x64 经 `192.168.0.23` 连接，只使用 `/root/tmp/gb-lifecycle-*`
专用目录和所属进程，未替换原 Host 安装或修改无关数据。
| 场景 | 实际结果 | 真实文本提供商调用 |
| --- | --- | ---: |
| 首轮 Host 启动挂起 | backend 修复后，协议 dispatcher 仍阻塞；测试退出后所属进程为 0 | 0 |
| OpenCode 启动取消及工具、detach、controller 恢复、测试 Agent 提升、重放 | 启动响应被挂起时控制查询 48 ms、取消 216 ms；工具与恢复完成；两个提供商响应均 HTTP 200 | 2 |
| Continue 同场景 | 控制查询 60 ms、取消 258 ms；工具与恢复完成；两个提供商响应均 HTTP 200 | 2 |
| Windows 当前源码 OpenCode 普通文本 | 真实原生二进制经有界 loopback 转发访问已配置模型，返回 `LOCAL_RUNTIME_OK`，0 工具调用；总耗时 4,727 ms | 1 |
本轮合计 **5 次真实文本提供商调用、0 次图片生成调用**。两次本机脚本准备失败发生在
SDK 动态加载阶段，均为 0 次模型调用，随后修正测试 bundle 并通过。所有成功场景均
使用最终相关生产源码。Host 启动取消阶段各为 0 次模型调用，最终所属残留进程均为 0，
专用目录由 harness 清理；本机 Runtime 和凭据临时副本也已清理。
真实数据检查使用本轮原生工具和模型产生的事件：OpenCode 45 条写入、23 个 checkpoint，
Continue 16 条写入、8 个 checkpoint，经生产 `AssistantDatabase` 和
`RemoteEventBatcher` 写入隔离 SQLite，再重放确认全部去重。未迁移、改写用户生产
历史库，也未以构造事件代替本轮 Host transcript。
原始脚本和日志位于 `C:/Users/jiang/AppData/Local/Temp/opencode`：
`a01-runtime-host-build.cjs`、`a01-runtime-host-run.cjs`、`a01-runtime-host/`，以及
`a02-local-model.ts`、`a02-local-model-run.cjs` 和 `a02-local-model-1791142126078.log`。
Host 成功日志为 `opencode-1791141713375.log`、`continue-1791141785721.log`。
延迟为各场景一次实测，不宣称吞吐、p95 或完整桌面性能提升。
### 检查命令与边界
```text
npx vitest run src/agent-daemon --testTimeout=30000 --hookTimeout=60000
npx vitest run src/main/remote-agent src/main/agent/acp-remote-runtime.test.ts src/main/agent/runtime-controller.test.ts src/main/agent/local-runtime-registry.test.ts --testTimeout=30000
npx vitest run src/main/agent/opencode-runtime.test.ts
npx vitest run src/main/agent/opencode-runtime-lifecycle.test.ts --testTimeout=30000 --hookTimeout=60000
npm run typecheck
npm run lint
```
四组测试分别为 323 通过/33 跳过、393 通过、156 通过、4 通过，共 876 项通过；
typecheck、全仓 lint 和修改范围 `git diff --check` 通过。初次合并运行中，既有
OpenCode `cleanup-timeout` 用例失败一次；该用例独立复跑及随后完整 OpenCode 文件
复跑通过，未改动该用例或相关产品清理逻辑。较早 Main 类型检查的并发监督者 fixture
错误在最终全仓检查时已消失。
验证覆盖当前源码、真实 Windows OpenCode 二进制和共享 Linux x64 Host，不含签名包
安装验收、完整 UI 点击、macOS/Linux arm64 或用户生产大库性能测试。首轮定向验证
未运行全仓 `npm test`，后续完整检查见下节；远程更新仍须部署包含本次源码的 Agent，
未提交或发布。
### SDK cleanup-timeout 复查
后续全仓验证为 6,130 通过、1 失败、87 跳过，唯一失败是 OpenCode SDK
`cleanup-timeout` 用例。复查通过独立 Node 子进程的十轮显式 GC 和受控取消复现：
旧 fetch 替身只保存 `request.signal`，返回永不结算的 Promise，没有在途 Request
所有者或 abort 处理。Request 及 Undici 内部 AbortController 被回收后，外层超时
signal 已中止，保存的 Request signal 仍未中止。真实 loopback fetch 在同样 GC
条件下保留 Request，取消后 SDK 返回错误，未观察到产品清理提前完成。
修正仅涉及测试：挂起的 fetch 替身在 abort 时以 `request.signal.reason` 拒绝，
闭包保持 Request 存活至取消。原有 `signals.every(signal => signal.aborted)`、调用
顺序、错误脱敏及超时均保留。新增 GC 回归在旧替身上稳定失败，修正后通过；九项
SDK 定向用例、Main 类型检查及该文件 ESLint 通过。本次跟进新增外部模型调用 0 次，
生产代码与远程 Agent 路径均未改动，无需重新执行 Host 模型验证。
修正后的完整 `npm test` 于 04:00:22 开始，852.63 秒完成，退出码 0：518 文件通过、
15 文件跳过；6,136 项通过、0 失败、87 跳过。计数包含并发工作树中的其他修复。
原始记录为 `C:/Users/jiang/AppData/Local/Temp/opencode/a02-cleanup-final-20261005.log`
及同名 `.json`；GC/真实 loopback 对照脚本为该目录的 `a02-cleanup-gc-probe.mjs`。
## 2026-10-04 调研与设计
调研阶段，用户确认彻底移除 Ask / Execute，包括界面、原生工具与 MCP 限制，并允许升级清理历史模式字段。该阶段先交付文档，随后用户确认删除安全设置并授权实施；实现结果见下文。
docs/features/wechat-channel/prd.md
+2
View File
@@ -298,6 +298,8 @@ Agent Runtime。OpenCode/Continue 的通道项目只持久化 `provider`，旧
现有发送者白名单和群聊提及设置继续有效。
钉钉回复以接口响应中的 `errcode=0` 确认投递，HTTP 200 本身不代表成功。业务错误或无效响应保留回复上下文和发件箱结果，由现有有限重试补发，不重新执行任务。响应读取上限为 64 KiB，包含没有 `Content-Length` 的分块响应；错误提示只保留数值错误码，不回显平台响应中的敏感字段。
## 8. 远程会话需求
### 8.1 会话创建与复用