已完成并推送到 feat/ai-001（commit cc1261e9）。本次修复包括：

• 续接持久化会话时，在首个 LLM 请求前对独立历史副本执行 tool 结果裁剪，保留 OPFS/UI 完整历史。
• loop-guard 超时发送 ask_user_expired，清理前台 pending 状态并继续执行。
• 统一 chat、compact、定时任务的持久化消息重建，过滤错误占位消息。
• 仅允许最后一个 max_iterations 错误助手组显示继续按钮。
• 统一 ephemeral、UI、定时任务的 maxIterations 归一化到 1–1000。
• execute_script 按最终 JSON 信封大小限制截断，并覆盖引号/反斜杠回归场景。

验证：相关 5 个测试文件 95 个测试通过；pnpm run lint（Prettier、TypeScript、ESLint）通过。

已根据完整 pnpm test 结果补充并推送修复，最新提交为 bb142ca6（前一提交为 cc1261e9）。

本次补充修复了持久化历史裁剪与既有内存消息循环语义之间的边界：只有正常续接持久化会话和续接已有会话的定时任务启用首个 LLM 请求前的历史副本裁剪；ephemeral/direct tool-loop 调用继续保留原有消息数组行为。

最终验证：

• pnpm test：289 个测试文件、3044 个测试全部通过
• pnpm run lint：Prettier、TypeScript、ESLint 全部通过
• 已推送至 feat/ai-001

已完成本轮问题修复并推送到 feat/ai-001（提交 ad31fd2d）。

• 定时任务遇到 max_iterations 时现在标记为失败，并保留累计 usage。
• 续接历史仅在估算上下文达到 40% 阈值时预裁剪；手动 /compact 先过滤错误占位消息，再裁剪旧工具结果。
• 循环检测改用稳定的 continue/stop action，禁止自定义输入；补充过期、取消及多监听器的状态广播。
• max_iterations 终态保存并发送 usage/duration；实时错误透传 errorCode。
• execute_script 现在按最终 envelope 限制 30,000 字符，并覆盖边界与转义内容测试。
• 循环检测问题、选项和停止消息已补齐八种语言。

验证结果：

• pnpm run typecheck 通过
• pnpm run lint 通过
• 目标相关测试 92 项通过
• pnpm test 在并行运行时有 1 个既有 ScriptEditor 预加载测试时序失败（3048/3049 通过）；该测试单独复跑 3/3 通过

已继续修复并推送到 feat/ai-001（提交 769c15bf）。

• userscript API 调用不再注入无法响应的 loop-guard 交互回调，避免无 UI 客户端暂停五分钟。
• attached background responder 现在通过 broadcastEvent 向所有监听器发送 ask_user_resolved。
• 首次续接与手动 /compact 使用包含工具定义的 UTF-8 保守请求预算；仅在超过安全阈值时逐步裁剪工具结果，兼顾小历史和小上下文模型。
• 定时任务失败保留 conversationId；userscript chat/chatStream、sub-agent 与 UI 均透传终态 error 的 usage/duration。
• loop-guard 等待在 abort 与微任务竞态下不会创建残留 prompt、resolver 或 timer。

验证结果：

• 目标回归测试 89 项通过
• pnpm run typecheck 通过
• pnpm run lint 通过
• pnpm test：3051/3052 通过；唯一失败项为既有 lint harness 测试并行运行时的 340ms 超时，单独复跑 23/23 通过

已完成本轮修复并推送到 feat/ai-001（提交 256705d8）。

• userscript 会话不再注册无法由公开 API 响应的 ask_user 工具。
• 普通 ask_user 接入 AbortSignal；用户回答、超时和中止都会清理 resolver/timer，并广播 ask_user_resolved 或 ask_user_expired。
• 上下文预算估算改用 UTF-8 字节保守上界，支持报告裁剪是否达标；无法安全裁剪的续接/compact 请求会返回明确的上下文过大错误，并识别未知多模态附件成本。
• provider 直接抛错现在携带累计 usage、duration 和 conversationId；定时任务与子代理使用结构化失败终态。
• 子代理达到 max_iterations 时工具调用标记为失败，不再返回普通成功的空结果。
• 公开 chat()/chatStream() 统一透传 error 的 usage 与 durationMs。

验证结果：

• pnpm test：289 个测试文件、3054 个测试全部通过
• pnpm run typecheck 通过
• pnpm run lint 通过

已完成本轮修复并推送到 feat/ai-001（提交 cbb6d8fc）。

• 多模态上下文预算现在读取附件 Blob 实际大小，估算 provider 展开后的 data URL 成本；旧附件可替换为可恢复占位，当前附件按真实大小参与 overflow 判断，初始与续接请求采用一致的安全决策。
• 自动 compact 纳入编排器结构化终态边界，摘要请求也执行上下文预算检查；失败时保留累计 usage、duration 和 conversationId。
• context overflow 在发送事件前先持久化终态错误，定时任务不再依赖 error listener 抛异常控制流程。
• 工具失败状态贯穿排除工具、未知工具、userscript handler、注册工具、tool_call_complete、后台快照、前台 UI 和持久化状态。
• 子代理终态异常保留部分消息、usage 与 subAgentDetails，刷新后仍可查看失败轨迹。
• ask_user_resolved 统一由 resolver 层发送，普通回答不再重复广播；guard 与普通 ask_user 使用同一终态契约。
• 公开 API 的成功 chat()/chatStream() 也透传 durationMs。

验证结果：

• pnpm test：289 个测试文件、3058 个测试全部通过
• pnpm run typecheck 通过
• pnpm run lint 通过

本次推送修复了 code review 中发现的 7 个问题（均已本地验证：pnpm run test 3069 个测试通过，pnpm run typecheck 无报错）：

1. 请求前预算检查：每轮 LLM 调用前用当前 messages + 工具定义重新估算体积，超出安全阈值时立即裁剪；不再仅依赖上一轮响应的 usage 反馈，避免巨大 tool 结果在下一次请求发出前就把上下文撑爆（tool_loop_orchestrator.ts）。
2. 附件预算按 provider 实际内联行为估算：file/audio 从不被 provider 内联，image 只在 vision 模型上才会解析为 data URL；按类型和模型能力估算体积，避免非 vision 场景或无法读取的附件把预算估算撑到 Infinity；裁剪后的占位文本保留 type/attachmentId（OPFS 路径）而非完全丢弃（context_elision.ts）。
3. 用户脚本工具循环遗漏 tool_call_complete/new_message 事件：非流式与流式适配器都只处理了 tool_call_start/delta，导致 ephemeral 历史中的 toolCalls 没有结果/终态，多轮对话被压平成一条消息、最终回复重复追加；已按轮次边界重建 assistant + 对应 tool 消息，并在 StreamChunk 新增 tool_call_complete/new_message 类型（cat_agent.ts）。
4. 脚本工具回调 abort/断开/超时处理：脚本工具调用的 pending promise 现在会在 abort、连接断开或 5 分钟超时时主动结束，不再无限期挂起整条对话（chat_service.ts）。
5. 子代理原生异常补发终态事件：orchestrator 的 callLLM/autoCompact 原生失败只 throw、不 sendEvent，导致实时 UI 收不到子代理终态、卡在 running 直到刷新；现在会在捕获异常时补发一次 error 事件（若尚未上报过终态）（sub_agent_service.ts）。
6. tool_call_complete 状态不再硬编码：改为 event.status ?? "completed"，避免持久化后把失败的嵌套工具显示为成功（sub_agent_service.ts）。
7. 消除 ask_user 终态事件重复广播：后台会话 attach 不再重复广播 ask_user_resolved；loop-guard 超时路径不再在发 ask_user_expired 后又紧接着触发 ask_user_resolved（background_session_manager.ts / chat_service.ts）。

提交记录：b335f5c4 b17e1395 8c72058a 7df95858 fc587b26（均带回归测试，先复现问题再修复）。

🤖 Generated with Claude Code

已按本轮审查 Findings 完成修复并推送到 feat/ai-001，当前 HEAD：ca0a46e413d759136a5559ec98b25d723024913e。

主要修复：

• attach() 公开并消费后台 sync 快照；终态快照立即结束，恢复已有内容、thinking、tool calls、ask_user 与 tasks。
• userscript 非流式/流式适配器统一按 id -> index -> running fallback 路由并发 tool-call 参数；ChatReply.toolCalls 跨轮聚合；ephemeral 历史保留生成内容块；意外断连在排空队列后抛出错误。
• 调用级同名工具同时替换 schema 与 handler；脚本工具 undefined 统一序列化为 "null"。
• script tool 执行批次增加 correlation ID，拒绝迟到响应；严格校验结果 ID 完整覆盖、无重复/越界；后台原连接断开后当前及后续脚本工具返回结构化错误，保证编排和持久化正常收尾。
• 上下文 preflight 统一预留 provider 输出 token 与安全边际，normal/compact 路径使用同一输入预算；context_too_large 终态消息补存累计 usage。

验证：相关 TypeScript 文件已通过 Prettier 检查。当前受限执行环境无法解析完整项目的 Vitest 依赖，因此未宣称本地完整测试通过，后续以 PR CI 结果为准。

Implemented on feat/ai-001:

• Ignored forwarded subAgent lifecycle events in the public chat adapter so child done/error events no longer settle the parent conversation.
• Reserved output tokens for explicit compact and now return context_too_large on overflow.
• Aligned the canonical CAT.agent.conversation declarations with runtime behavior, including background, attach(), sync, durationMs, and cache usage fields.
• Sanitized tool_call_complete handling so returned tool calls only carry tool-call fields and default status to completed.

Verified with pnpm exec eslint ... and pnpm run typecheck.

Pushed feat/ai-001 with the requested fixes and local commit 41ff1155.

Summary:

• fixed abort propagation for registered tools, skill scripts, and execute_script
• fixed compact / summary budget handling so output reservation is applied once
• updated canonical public declarations for durationMs, background, attach(), and sync
• added regressions for missing-image estimation, summary preflight, and signal forwarding

Verified with pnpm exec tsc -p tsconfig.json --noEmit, pnpm exec eslint on the touched TypeScript files, and the targeted vitest set.

已完成本次修复并提交 bd6c0d51：

• Stop 会话现在会广播取消终态、清理 pending 状态并安排注册表清理，允许同一 conversation ID 重新运行。
• ToolRegistry 现在竞速 AbortSignal，规范化 undefined/不可序列化工具结果；OPFS/task 工具协作取消。
• sandbox execute_script 超时会中止底层脚本；预检预算不再重复扣安全裕量；自动压缩 usage（含缓存 token）会计入总量。
• 更新 signal 传递相关单元测试断言。

验证：pnpm run lint 通过；pnpm test 通过（290 个文件、3089 个测试）。

已在 feat/ai-001（ae540d44）针对本轮 review 逐条修复：

1. 后台会话取消竞态（High）：BackgroundSessionManager 新增 cancelling 占位态——stop() 不再立即把记录标为终态，has() 在 cancelling 期间仍视为占用，避免旧执行的 promise 尚未落定时同一 conversationId 被新会话顶替；执行方在 abort 真正落定后调用新增的 finalizeCancelled() 才收敛为终态（按 rc 实例做 CAS 校验，防止顶替上位的新会话被误终态化）。stop() 新增 expectedRc 参数，handleAttach 与 chat_service_base 的 Stop 消息处理都改为按会话实例校验，避免旧连接的延迟 Stop 误杀新会话。见 background_session_manager.ts、chat_service_base.ts。

2. compact 取消竞态（High）：自动 compact（compact_service.ts）与手动 compact（chat_service_base.ts 的 handleCompactChat）都在 LLM 调用返回后、覆盖 currentMessages/持久化摘要前，以及持久化完成后再各补一次 abort 检查；tool_loop_orchestrator_base.ts 的主循环在 autoCompact() 返回后同样补了检查，取消后不会再继续持久化/广播 compact_done、done。

3. 取消终态化不完整（Medium）：tool_loop_orchestrator_base.ts 新增统一的 emitCancelled() 收口路径——工具执行期间取消时，先把所有工具调用（含未及返回结果的）回写为 error/cancelled 状态并持久化，再发送唯一一条携带累计 usage/durationMs 的终态事件；LLM 响应后的 usage 改为先累加再检查 abort，避免最后一次响应的用量丢失。子代理的 usage 收集依赖 done/error 事件，因此这个修复同时解决了超时静默返回导致 usage 缺失的问题。

4. 端口/监听器泄漏（Medium）：options 页面的 useStreamingChat hook 在终态事件/终态 sync 后主动调用 conn.disconnect()；cat_agent.ts 的 processChat 在 resolve/reject 前断开连接，processStream 的异步迭代器补上了 return()/throw()，for await...break 或消费方抛错时会断开连接并唤醒挂起的 next()。

5. execute_script(target=page) 无法真正中止（Medium）：chrome.scripting.executeScript 本身没有取消 API，无法安全地强制终止 MAIN world 代码。改为诚实呈现边界：超时/取消错误信息与工具描述都明确说明这只是"调用方停止等待"，页面代码可能仍在 tab 内继续运行；target='sandbox' 路径不受影响，仍是真正可取消的。

6. context_too_large 持久化 usage 不完整（Medium）：emitContextTooLarge() 直接持久化 totalUsage（此时已包含 autoCompact 的用量），移除了外层 tool_loop_orchestrator.ts 中只包裹 callLLM、覆盖不到 autoCompact 的旧 usage 补丁 proxy。

7. 字节数当 token 数（Low）：estimateRequestTokens() 不再把 UTF-8 字节数直接当 token 数返回，改为除以一个保守换算常数（2 字节/token）后再与预算比较，仍然保守但不会把普通文本按 1 字节 = 1 token 过度低估上下文余量。

全部改动已跑过 tsc --noEmit、eslint、prettier --check 及相关单测（background.test.ts、compact_service.test.ts、tool_loop_orchestrator.test.ts、autocompact.test.ts、context_elision.test.ts、execute_script.test.ts、cat_agent.test.ts、hooks.test.ts 等），并补充/更新了对应用例以反映修正后的行为（尤其是 stop() 语义变化的测试）。

CI 失败已修复（feat/ai-001 2f7467f1）。

根因：上一提交把 `estimateRequestTokens()` 从"UTF-8 字节数直接当 token 数"改成了"字节数按保守常数折算成 token 数"，返回值整体变小。compact_service.test.ts 里 摘要请求超过输出保留预算时应返回 context_too_large 这条用例用来构造测试数据的 makeCurrentMessages()，是从长度 1 开始逐字符线性扫描、每次都做一次 O(len) 的 JSON.stringify 来找命中目标预算区间的字符串长度——估算值变小后，命中区间所需的字符数随之变大，扫描总耗时成倍增长，超过了 vitest.config.ts 里 fast 分组 340ms 的用例超时，在 CI 上表现为 timeout（本地默认并发调度下偶发未复现）。

修复：compact_service.test.ts 把逐字符线性扫描改成二分查找最小满足长度，迭代次数从 O(n) 降到 O(log n)，测试逻辑不变，只是构造样本的方式更快。

验证：

• npx vitest run 全量 3090 个用例通过（Duration 24.56s，该用例单独跑总耗时 6ms）
• tsc --noEmit、eslint、prettier --check 均通过

e2e 失败已修复（`feat/ai-001` `c4b7dfa0`）。

根因：修复端口泄漏（finding 4）时，在 cat_agent.ts 的 `processChat` 里把顺序写成了先 `conn.disconnect()` 再 `resolve()/reject()`。部分连接实现的 `disconnect()` 会同步触发已注册的 `onDisconnect` 回调，而该回调里正是 `reject(new Error("Connection disconnected"))`——Promise 只认第一次 settle，于是这次 reject 抢在预期的 resolve 之前把整个 promise 判定为失败。结果是 `CAT.agent.conversation` 的每一次 `chat()` 调用最终都以 "Connection disconnected" 报错，对应 CI 里 `agent-conversation.spec.ts` 的三个用例（basic chat / tool calling / multi-turn）和 `agent-error-handling.spec.ts` 的重试用例全部失败；第二次 retry 里出现的 "waiting for event serviceworker" 超时是同一批用例反复失败导致的连锁重试超时，不是独立问题。

修复：把 `processChat` 的 done/error 分支改回先 `resolve()/reject()` 后 `conn.disconnect()`，并加了 `settled` 标记，让 `onDisconnect` 回调在 promise 已经终态化之后变成 no-op——不再依赖 "disconnect() 是否会同步触发回调" 这个具体实现细节。`processStream` 那边原本就是先 `done = true` 再 `conn.disconnect()`，且 `onDisconnect` 里已有 `if (done) return` 守卫，本身不受影响。

本地复现与验证：

• 未修复前本地复现出同样的 `ERROR: Connection disconnected`（`npx playwright test e2e/agent-conversation.spec.ts -g "basic chat"`）
• 修复后：`npx playwright test e2e/agent-conversation.spec.ts`（3 项全过）、`npx playwright test e2e/agent-error-handling.spec.ts`（通过）、`npx playwright test e2e/agent-chat.spec.ts e2e/agent-navigation.spec.ts e2e/agent-provider.spec.ts`（9 项全过）
• `npx vitest run`：3090 项全过；`tsc --noEmit`、`eslint`、`prettier --check` 均通过

按要求对本 PR 引入/新增的算法逐一做了时间/空间复杂度复查（`feat/ai-001` `7e7c1f2c`）。范围是本分支相对 `main` 实际新增或修改的非测试代码（`tool_loop_orchestrator_base.ts`、`context_elision.ts` 等新文件，以及 `background_session_manager.ts`、`cat_agent.ts`、`execute_script.ts` 等改动文件），跳过纯移动未改逻辑的代码。

已修复

1. tool_loop_orchestrator_base.ts — 工具调用结束后回写 toolCalls 状态

原实现每一轮工具调用结束后都会：

• `getMessages(conversationId)`：整份读出该会话的持久化历史（OPFS JSON 文件，O(n) 读取 + 反序列化）；
• 反向线性扫描该历史，用嵌套 `toolCalls.some(...)` 逐条匹配目标 assistant 消息；
• `saveMessages(conversationId, allMessages)`：整份覆写回文件（O(n) 序列化 + 写入）。

跨一整个多轮 tool-calling 对话（R 轮、历史长度随轮次线性增长到 N），这部分是 O(R·N) 的编排器侧冗余工作（不含存储层本身必要的 O(n) 读写）。

根因是：`appendMessage` 落库时其实已经构造出了带 `id` 的完整消息对象，但代码没有保留这个引用，之后要更新状态时只能重新整份读回、按内容匹配、整份写回。修复：保留该对象引用（`persistedAssistantMessage`），工具执行完成后直接 `chatRepo.updateMessage(persistedAssistantMessage)` 按 `id` 更新——去掉了编排器侧那份重复的全量消息拷贝和逐条 `some()` 匹配（`updateMessage` 内部仍是 OPFS 文件的整份读写，这是存储层本身的限制，不在本次改动范围内）。同时内存态 `messages` 里查找目标 assistant 消息，从正向 `Array.prototype.find`（O(n) 全量扫描）改成了从尾部反向扫描——目标消息就是本轮刚 push 的那条，实际总在数组尾部附近，反向扫描把摊还成本降到接近 O(1)。

2. context_elision.ts 的 `elideUntilWithinBudget`

原代码先算 `hasToolResults = messages.some(...)`（O(n)），再分两条 `if` 判断 `!hasToolResults && estimate()...` / `hasToolResults && estimate()...`——但这两个分支条件完全相同，`hasToolResults` 的值根本不影响任何分支行为，纯属多余的一次 O(n) 扫描。合并为一次判断，语义不变。

复查过但判断不适合在本 PR 改的

• `estimateRequestTokens`（context_elision.ts:53）在 tool loop 每轮都做一次 `JSON.stringify(messages)`：由于 `messages` 每轮增长，一整个对话下来是 O(n²) 字节处理。要降到 O(n) 需要维护增量字节计数（每次 push/裁剪消息时更新一个运行中的字节总数），但这会牵涉多处消息增删（工具结果、裁剪、compact）都要同步维护计数，属于架构级改动，风险和改动面明显超出这个以 bug 修复为主的 PR 范围，本次不动，仅记录在案。
• `preloadSkillsFromHistory`（chat_service_base.ts:723）每轮全量重扫历史找已加载的 skill：确认这段逻辑是从 `main` 的 `chat_service.ts` 原样搬过来的（`git show origin/main:.../chat_service.ts | grep preloadSkillsFromHistory` 可查到同名同逻辑函数），不是本 PR 引入的新代码，不在这次复查改动范围内。
• `tool_call_guard`、`background_session_manager`、`cat_agent_base` 里的 `.find()` 调用：都被单轮 tool-call 数量（个位数）限制，不随会话规模增长，影响可忽略。
• `execute_script.ts` 的 `buildResultPayload` 二分截断：范围受 `MAX_RESULT_CHARS`（30k）限制，不随历史增长。
• `web_search.ts` 结果集固定 ≤10 条，非算法瓶颈。

验证

• `npx vitest run`：3090 项全过（含为 `updateMessage` mock 语义新增/调整的用例）
• `npx tsc --noEmit`、`eslint`、`prettier --check` 全部通过
• `npx playwright test e2e/agent-conversation.spec.ts e2e/agent-error-handling.spec.ts e2e/agent-chat.spec.ts`：5 项全过

按要求把之前"值得做但先搁置"的架构性问题落实了（`feat/ai-001` `58c7eb9d`）。

`estimateRequestTokens`：按消息增量缓存序列化字节数

问题：context_elision.ts 的 `estimateRequestTokens` 每次调用都对整段 `messages` 做一次 `JSON.stringify`。tool loop 每轮 preflight 都要调用它（tool_loop_orchestrator_base.ts），R 轮下来是 O(R·n)，随对话增长趋近 O(n²)。真实场景下 tool 结果（页面内容、搜索结果摘录等）常见到数十 KB，这是长对话里真实的性能热点。

实现：按 message 对象身份缓存其 `role`/`content`/`toolCallId` 的序列化字节数（`WeakMap`）——这三个字段一旦写入基本不再变化。唯一会原地改写 `content` 的两处（`elideOldToolResults`、`elideOldAttachments`）都显式调用新增的 `invalidateMessageByteCache()` 使缓存失效。`toolCalls` 字段（`status`/`attachments`/`subAgentDetails` 会在工具执行后原地变化）刻意不缓存，每次单独重算——但它的体积只随"该条消息自身的工具调用数"增长，不随对话长度增长，代价很小。

为什么没有做成完全 O(n) 总量：也评估过按数组引用维护一个"只加新增项"的运行总量缓存（类似 tool_loop_orchestrator_base.ts 那次改动的思路），但会和 `toolCalls.status` 原地变化的正确性要求冲突——同一个 messages 数组、同一个长度，工具执行前后再次调用必须能读到最新状态，而"只加新增项"的设计一旦某条消息被计入运行总量就不会再重新访问它。要安全实现需要在 `applyToolUpdates` 等多处新增跨文件失效钩子，改动面和引入新 bug 的风险明显超过收益，因此没有采用。当前方案已经消除了真正昂贵的部分（大文本反复序列化），剩下的按条求和本身是廉价操作（Map 查找 + 加法）。

基准验证（20KB/tool 结果，模拟真实页面内容/搜索结果量级）：

加速比随对话变长持续提升，符合"消除了随 n 增长的重复序列化成本"的预期。

新增测试覆盖三类关键正确性场景（context_elision.test.ts）：`elideOldToolResults`/`elideOldAttachments` 改写 content 后估算值立即反映新内容而非陈旧缓存；`toolCalls.status` 原地变化后估算值能读到最新状态；反复调用同一未变化的消息返回稳定一致的结果。

`preloadSkillsFromHistory`：复核后判断不值得做架构改动

再评估了一下。它确实每轮都要 O(n) 扫描历史找 `load_skill` 调用（因为每轮的 `sessionRegistry` 都是全新构建的，为保证并发隔离——历史里记录过哪些 skill 被加载过，必须每轮重新得知才能把动态工具重新注册进这个新对象里，这部分 `执行` 本身无法省略）。可省的只是"扫描历史"这一步，做法是维护一个按 `conversationId` 的增量缓存（只扫描上次以来的新消息）。

没有动它的原因：这个循环本身极便宜——只是对轻量对象做 `msg.role === "assistant" && msg.toolCalls` 判断，不涉及大字符串序列化，即使历史有几千条消息，耗时也在亚毫秒级，和 `estimateRequestTokens` 那种"反复重新序列化数十 KB 文本"的量级完全不是一个数量级。而要安全实现跨轮次持久化的增量缓存，需要在 Service Worker 这种长期存活的上下文里新增一套"何时清理某个 conversationId 缓存"的生命周期管理——做不好就是真实的内存泄漏，风险比它要解决的（本就很小的）耗时问题更大。这是权衡后判断"改了收益不够、且引入新风险"，不是漏看。

验证

• `npx vitest run`：3094 项全过（含 4 条新增缓存正确性用例）
• `npx tsc --noEmit`、`eslint`、`prettier --check` 全部通过
• `npx playwright test e2e/agent-conversation.spec.ts e2e/agent-error-handling.spec.ts e2e/agent-chat.spec.ts`：5 项全过

已在 `feat/ai-001`（`2777ceaa`）针对本轮 review 逐条修复：

1. SSE 流 abort 时悬挂（High）：content_utils.ts 的 `readSSEStream()` 在 abort 时不再静默 `return`，改为主动 `reader.cancel()` 并 reject，让循环内 `reader.read()` 卡住时也能被唤醒。anthropic.ts 补上了缺失的终态兜底（流结束但没收到 `message_stop`/`message_delta(usage)`/`error` 时补发 error）。llm_client.ts 的 `callLLM()` 额外订阅 signal 作为最后一道保险。三处叠加，确保 `LLMClient.callLLM()` 的外层 Promise 在任何取消场景下都会 settle。

2. 取消终态双主体竞态（High）：background_session_manager.ts 的 `stop()` 不再自行广播终态事件（只置 `cancelling` 并 `abort()`）；终态事件的唯一来源改为 orchestrator 的 `emitCancelled()`（携带完整 usage/耗时）。同时在 tool_loop_orchestrator_base.ts 里把之前遗漏的几个 abort 出口（`callLLM`/`toolRegistry.execute`/`autoCompact` 因 abort 而 reject、guard 等待用户回答期间 abort、最终消息落库后）都统一收口到 `emitCancelled()`，不再出现"这条路径直接 throw 跳过终态化"或"误报 done"的情况。

3. compact 在 Stop 后仍完成破坏性覆写（High）：opfs_repo.ts 的 `writeJsonFile()` 新增可选 `signal`，利用 OPFS `createWritable()` 本身的事务性（`write()` 只写临时副本，`close()` 才原子替换旧文件）——signal 在 `close()` 落定前 abort 时改为 `writable.abort()` 放弃这次整份覆写，不提交、旧内容保持完整。`AgentChatRepo.saveMessages` 透传 signal；compact_service.ts 与手动 compact 都改为写盘确认成功后才允许覆写内存中的 `currentMessages`，不再"写盘失败但内存已被摘要顶替"。

4. 同一会话并发写入无锁（High）：复用仓库已有的 `stackAsyncTask`（async_queue.ts，未引入新依赖）按 `conversationId` 排队。chat_service_base.ts 把 `handleConversationChat` 拆成快速拒绝层 + 排队执行层，chat/compact（复用同一入口）与 `clearMessages` 现在共用同一把按会话排队的锁，不会再互相用过期快照覆盖对方的持久化写入。ephemeral 会话不读写 chatRepo，跳过排队。已有的"后台会话正在运行"快速拒绝仍在排队之前完成，不会让重复请求卡在队列里空等。

5. 连接生命周期收尾（Medium）：cat_agent.ts 的 `processStream()` 收到终态 `sync` 快照后立即 `disconnect()`；`processStreamEphemeral()` 的迭代器补上 `return()`/`throw()`，转发给内层迭代器并在提前退出时提交已累积的部分输出，避免下一轮 `chat()` 因丢失这部分历史而上下文断裂；两处 `executeTools` 结果发送前都检查连接是否已 settled 并用 try/catch 包裹 `sendMessage`，避免用户脚本上下文出现 unhandled rejection。

6. token 估算器诚实化（Medium）：context_elision.ts 的 `estimateRequestTokens()` 不再对文本/JSON 与图片字节数使用同一个折算系数——图片的 provider 计费机制（OpenAI 按分块、Anthropic 按宽×高/750）与 base64 字节数没有对应关系，本仓库也没有图片宽高元数据，无法套用具体公式，因此图片部分不做任何折算（宁可偏保守拒绝，不假装精确换算导致低估）；函数注释也改为明确声明这是启发式估算、不是任何 provider 的精确 tokenizer（接入 tiktoken 等官方计数器需要新增依赖，超出本次改动范围，未采用）。

验证

• `npx vitest run`：3099 项全过，新增用例覆盖 SSE abort 时 reject（open/anthropic/agent 三处）、stop() 不再自行广播、`writeJsonFile` 取消安全（abort 后旧内容不被覆盖）、同一 conversationId 的 chat/compact/clear 严格排队而不同会话互不阻塞
• `npx tsc --noEmit`、`eslint`、`prettier --check` 全部通过
• `npx playwright test`：`agent-conversation`、`agent-error-handling`、`agent-chat`、`agent-navigation`、`agent-provider`，共 13 项全过

已在 `feat/ai-001`（`40ad4b0e`）针对本轮 review 逐条修复：

1. finalizeCancelled 清理漏判（High）：background_session_manager.ts 的 `emitCancelled()` 广播的终态事件会先经过正常的 `sendEvent → updateStreamingState` 把 `status` 从 `cancelling` 改写成 `error`，而 `finalizeCancelled()` 原本只认 `cancelling`，导致这个真实存在的时序下永远不会调度 `cleanupIfDone()`，记录永久留在 `runningConversations`。改为 `cancelling` 或已经落定的终态都可以安全调度清理（`cleanupIfDone` 本身按实例比对 + status 二次确认，幂等安全）。`cancelling` 阶段的迟到 attach 也不再立即报 `error` 断开：sync 快照对外仍按 `running` 处理并继续订阅 listener，直到 orchestrator 真正广播出那条带完整取消原因/usage/耗时的终态事件才断开，避免丢失这条事件、也避免客户端在取消记录落库前就重载。

2. 多个终态分支未在持久化后复查取消（High）：tool_loop_orchestrator_base.ts 里 loop-guard 用户选择 Stop 的路径、超过 `maxIterations` 的路径、`emitContextTooLarge()` 都补上了信号复查——持久化期间/之后已被 Stop 时改走统一的取消终态化路径，不再对外报告 `done`/`max_iterations`/`context_too_large`。`emitCancelled`/`emitContextTooLarge` 的落库也都改为 try/catch 包裹，落库失败不再阻塞终态事件发送（此前 `emitCancelled` 是 `await appendMessage()` 后才发事件，写失败客户端就永远收不到终态）。

3. abort 时 provider 侧图片落盘/usage 未妥善处理（Medium）：llm_client.ts 的图片保存/markdown 内联图片提取流程改为逐步检查 `settled`，一旦外层 Promise 已经因 abort 落定就停止继续保存/发送 `content_block_complete`，并清理这一轮已经落盘但用不上的孤儿附件。openai.ts/anthropic.ts 在 abort reject 时把已知的部分 usage（chunk 级 usage / `message_start` 的 input+cache usage）带在错误对象上，orchestrator 取消前会把这部分并入累计 usage，不再直接丢弃。

4. EOF 截断被当作成功完成（Medium）：OpenAI 解析器现在跟踪是否见过 `finish_reason`，reader EOF 但既没有 `[DONE]` 也没见过 `finish_reason` 时按未预期断连报错，不再把可能截断的部分内容当作完整答案持久化，与 Anthropic 解析器的对应处理保持一致。

5. 图片 token 估算严重失真（Medium）：context_elision.ts 里 base64 字节数不再按 1:1 当 token 数——一张普通 100KB 照片按此前的估算会膨胀到十几万 token，直接撑爆未配置 `contextWindow` 模型（128K）的输入预算。改为按更贴近真实 provider 计费量级、但仍保守的固定系数（40 字节/token，注释里附了 OpenAI/Anthropic 的真实计费量级作为依据）折算。精确的按图片宽高计费（Anthropic 的 宽×高/750 公式）仍是已知的后续待办——需要在附件加载阶段解码图片尺寸，超出本次改动范围，已在提交信息里记录。

6. ephemeral 提前退出留下悬空 tool_call 协议状态（Medium）：cat_agent.ts 的 `processStreamEphemeral()` 的 `finish()` 现在会把没有收到 `tool_call_complete` 就被提前 `return()`/`throw()` 打断的 toolCall 统一补成终态 cancelled，并补上配对的 tool 结果消息，保证重放给 provider 的历史里 tool_call/tool_result 协议状态始终完整，不会因为 provider 拒绝"assistant 消息里的 tool_call 缺少对应结果"而报错。

7. 模型 token 限制未校验（Low）：`AgentModelRepo.saveModel` 落库前统一把 `maxTokens`/`contextWindow` 归一化为有限正整数（超出合理范围或非正数一律视为未配置），作为存储边界的唯一校验点。`getContextWindow` 与 OpenAI/Anthropic 的请求体构造也改为显式的正数校验而不是 truthy 判断——负数在 JS 里是 truthy，此前会绕过校验原样发给 provider 或让预算计算塌缩为 0。

评估后本次未实现（记录在案）

finding 3（仓库层跨执行环境序列化）与 finding 4（队列的连接感知/重入策略）：Options 页面、定时任务与 Service Worker 分属不同 JS 执行上下文，上一轮实现的进程内 `stackAsyncTask` 队列（chat_service_base.ts）只能覆盖同一个执行上下文内的并发，无法覆盖跨上下文的并发写入。真正的修复需要 Web Locks API（`navigator.locks`，跨上下文共享同一把源级锁）覆盖仓库层所有写方法（消息、任务、附件清理、会话元数据），并为"活跃 tool handler 内发起新操作"（如工具执行期间调用 `conv.clear()`）设计明确的重入策略——这是一次影响面大、需要独立测试与产品决策的改动，仓促实现风险明显高于收益，故未在本次改动中处理，留作后续独立的一轮。

验证

• `npx vitest run`：3111 项全过，新增/调整测试覆盖 cancelling 阶段 attach 行为、`finalizeCancelled` 幂等性、guard-Stop/max_iterations 取消复查、abort 时 usage 透传、EOF 截断报错、图片 token 估算、ephemeral 悬空 toolCall、模型限制归一化
• `npx tsc --noEmit`、`eslint`、`prettier --check` 全部通过
• `npx playwright test`：`agent-conversation`、`agent-error-handling`、`agent-chat`、`agent-navigation`、`agent-provider`，共 13 项全过

补充一轮修复（commit cd3c79db，已推送到 feat/ai-001），针对本轮 review 的 12 项 findings：

已修复

1. SSE reader 提前终态未释放（Low ＃12）：readSSEStream() 在 onEvent 判定为终态提前 return 时不再遗留未读完的 body/reader lock，finally 里识别该场景后主动 reader.cancel()。（content_utils.ts）

2. abort 安全网抢占带 usage 的真实 reject / error 事件丢字段（Medium ＃7）：LLMClient 的 abort 安全网改为延迟到下一个宏任务 reject，让 parser 自身携带部分 usage 的 reject 优先落定；case "error" 保留 usage/errorCode/durationMs，不再转成裸 Error。（llm_client.ts）

3. 生成图片孤儿附件清理遗漏（Medium ＃8）：改为记录本轮所有已落盘的附件 id，settled 时统一清理整轮附件，不再只清理取消瞬间"正在保存"的那一个。（llm_client.ts）

4. emitContextTooLarge 落库后未复查取消（Medium ＃5）：持久化占位错误消息后补上信号复查，命中则走统一取消终态路径而不是继续对外报告 context_too_large。（tool_loop_orchestrator_base.ts）

5. 自动 compact 落盘后未复查取消（High ＃3）：saveMessages() 成功后补 throwIfAborted，Stop 落在写盘之后、覆盖内存/广播 compact_done 之前时中止。（compact_service.ts）

6. Options UI 发现/生命周期竞态（High ＃6）：listIds() 纳入 cancelling 状态；stopGeneration() 不再立即断开连接或置 isStreaming=false，改为等真正的终态事件/连接断开触发；sendMessage/attachToConversation 的 onMessage 在 abort 后仍放行终态事件（只抑制中间流式增量）；handleStop() 不再自行处理排队消息/重新加载历史，交由 onDone 在终态落定后统一处理，避免排队消息丢失。（hooks.ts, ChatArea.tsx, background_session_manager.ts）

7. executeTools 批次内不感知 settle（Medium ＃9）：串行 handler 循环在每次迭代前检查连接是否已 settle（Stop/超时/断开），命中则把剩余 toolCall 标记为取消，不再继续执行。（cat_agent.ts）

8. 最终成功回复静默丢失持久化失败（Medium ＃10）：正常完成分支的 appendMessage 加有限重试（3 次，200ms/400ms 退避），仍失败则发结构化 error（errorCode: persist_failed），不再对外报告 done。（tool_loop_orchestrator_base.ts）

9. 输出 token 预留为 0（Medium ＃11）：getReservedOutputTokens() 对未显式配置 maxTokens 的 OpenAI 兼容模型不再预留 0（这类请求会省略 max_tokens，provider 侧套用它自己的非零默认值），统一用保守默认值兜底。（model_context.ts）

10. 工具附件保存未感知取消（High ＃4，部分）：saveAttachments() 接受 signal，每次写入前检查；内置工具与脚本工具两条路径均已传入，abort 时停止继续写入并把该 toolCall 标记为 error。（tool_registry.ts）

评估后本次未处理

• ＃1 仓库层非事务性写入、＃2 队列非连接感知/不可重入：真正的修复需要 navigator.locks 覆盖仓库层所有写方法，并对"活跃 tool handler 内发起新操作"（如 conv.clear()）设计明确的重入策略——这是独立的一轮架构改动，且 happy-dom 测试环境下 navigator.locks 不可用，需要额外的环境探测兜底，不适合塞进这一轮。
• ＃4 task 工具的持久化回调：仍缺少取消感知，与上面同理留作后续。

验证

• npx vitest run：290 个文件、3115 个测试全部通过（含本轮新增/调整的针对性用例）
• npx tsc --noEmit / eslint / prettier --check：全部通过
• npx playwright test e2e/agent-conversation.spec.ts e2e/agent-error-handling.spec.ts e2e/agent-chat.spec.ts e2e/agent-navigation.spec.ts e2e/agent-provider.spec.ts：13 项全过
• pnpm run build：Rspack 编译成功