cc-haha/tests/manual/v0.4.10-to-head-ui-errors.md

v0.4.10 之后人工界面测试缺陷与修复记录

测试范围：v0.4.10..91829e91

平台：Windows 11 x64；隔离 CLAUDE_CONFIG_DIR 与 Electron user-data-dir

状态：本轮执行已收口。DeepSeek、MiniMax 真实编程任务、附件恢复、多模态、SubAgent、Task 并发与 Windows 长空闲恢复均有真实 UI 证据；BUG-001～BUG-011 已修复并验证。未执行或仅部分执行的硬件、故障注入、CLI/TUI 用例仍按限制保留，不冒充 passed。

BUG-001｜React StrictMode 下内置终端首次打开为空白

• 严重程度：P0
• 状态：fixed / verified
• 对应用例：WIN-03、终端基础冒烟
• 测试场景：开发构建中打开顶部内置终端标签。
• 实际结果：终端区域为空白且没有可用会话；刷新设置页不能恢复。
• 期望结果：终端只创建一个 runtime，显示 Running、shell、cwd 和可交互提示符。
• 根因：React StrictMode 首次挂载会重放 effect。第一次 cleanup 立即销毁共享 terminal runtime，第二次 effect 继续持有已经失效的对象，因而无法重新启动。
• 修复：为组件 effect 增加生命周期版本；普通真实卸载仍在 microtask 中销毁 runtime，StrictMode replay 的过期 cleanup 则不再销毁当前 runtime。
• 变更文件：
  • desktop/src/pages/TerminalSettings.tsx
  • desktop/src/pages/TerminalSettings.test.tsx
• 验证证据：
  • 聚焦 Vitest：17/17 passed。
  • TypeScript tsc --noEmit passed。
  • Computer Use 复验：顶部终端显示 Running、C:\WINDOWS\system32\cmd.exe 和隔离配置目录提示符；Restart 后仍为 Running。
  • 完整 bun run check:desktop：2430 passed、2 skipped、0 failed，production build passed。

BUG-002｜切换语言后 Settings 顶部标签仍保留旧中文标题

• 严重程度：P1
• 状态：fixed / verified
• 对应用例：I18N-01
• 测试场景：应用最初为简体中文，打开设置标签后切换到 English。
• 实际结果：设置页正文已经变为英文，但顶部标签仍显示持久化的“设置”。
• 期望结果：顶部标签与当前 locale 同步显示 Settings，关闭按钮的无障碍名称也同步更新。
• 根因：设置标签直接渲染创建标签时保存的 tab.title，没有根据当前 locale 重新读取 settings.title。
• 修复：设置类型标签动态渲染当前 t('settings.title')，同时用于 close button 的 aria-label；普通会话标签仍保留原标题。
• 变更文件：
  • desktop/src/components/layout/TabBar.tsx
  • desktop/src/components/layout/TabBar.test.tsx
• 验证证据：
  • 聚焦 Vitest：40/40 passed。
  • TypeScript tsc --noEmit passed。
  • Computer Use 复验：切换 English 后顶部显示 Settings，关闭按钮为 Close Settings。
  • 完整 bun run check:desktop：passed。

QA-001｜Windows 完整桌面门禁的跨平台测试夹具失败

• 严重程度：测试基础设施
• 状态：fixed / verified
• 首次结果：bun run check:desktop 为 12 failed、2418 passed，因测试失败未进入最终 build。
• 分类：
  • 7 个稳定失败来自测试夹具把 POSIX/macOS 路径、权限位或 PATH 大小写写死到 Windows。
  • 2 个 petWindow 失败来自源码字符串断言写死 LF，不能处理 Windows CRLF。
  • 3 个 Workspace 测试在全量并发下渲染约 5001、1996、2300 个 DOM 行，触发 5/20 秒超时；聚焦运行均通过。
• 修复原则：没有发现对应生产逻辑错误，因此只修正测试的跨平台构造和无必要的大规模 DOM 夹具，没有改生产代码，也没有简单扩大超时。
• 变更文件：
  • desktop/scripts/electron-output-guard.test.ts
  • desktop/electron/services/pets.test.ts
  • desktop/electron/services/sidecarManager.test.ts
  • desktop/electron/services/terminal.test.ts
  • desktop/electron/services/petWindow.test.ts
  • desktop/src/components/workspace/WorkspaceDiffSurface.test.tsx
  • desktop/src/components/workspace/WorkspacePanel.test.tsx
• 验证证据：
  • 路径/权限聚焦测试：98 passed、1 macOS-only skipped。
  • petWindow/Workspace 聚焦测试：95/95 passed；同组 coverage 运行 95/95 passed。
  • 修复后完整 check:desktop：2430 passed、2 skipped、0 failed；最终 tsc -b 与 Vite production build passed。
  • 紧接着的全量 JSON 复跑：524/524 suites passed，2430 passed、2 skipped。

排除的环境误报

ENV-001｜旧 Sidecar 导致 Pets 无法加载

• 初始现象：设置页显示“无法加载宠物”。
• 结论：不是候选代码缺陷。Electron 主进程使用当前源码，但启动时加载的是 2026-07-18 的旧 claude-sidecar 二进制，早于测试范围内的服务端改动。
• 处置：备份旧二进制后执行 bun run build:sidecars，仅在隔离测试实例中换入当前 Sidecar。
• 复验：4 个内置宠物 Dada、Huhu、Bubu、Huihui 正常出现；桌面宠物窗口可打开。

ENV-002｜旧 Sidecar 导致 Agent 保存后前端读取 agentType 报错

• 初始现象：创建 Agent 后弹出 Cannot read properties of undefined (reading 'agentType')。
• 结论：不是候选代码缺陷。旧 Sidecar 的 POST /api/agents 返回 {ok:true}，当前桌面端期望 {agent: ...}。
• 处置：同 ENV-001，重建当前 Sidecar。
• 复验：用户 Agent manual_reviewer 可创建、查看、编辑回继承；内置 Agent 保持只读。

BUG-003｜权限模式控制请求被拒绝后遗留 pending confirmation

• 严重程度：P1
• 状态：fixed / verified
• 对应用例：DENY-01、DENY-02、权限模式切换
• 发现方式：Windows check:coverage 在连续执行“确认成功 → CLI 拒绝 → 确认超时”三个权限模式测试时稳定不退出。
• 根因：ConversationService.setPermissionMode() 在创建 confirmation Promise 后调用 requestControl()；CLI 拒绝 control request 时，catch 只清理 timer/callback，没有 settle 已创建的 confirmation Promise。在 coverage 异步跟踪下，该 pending Promise 会让后续计时测试进入持续 CPU 状态。
• 修复：保存 confirmation reject 句柄，引入 settled guard 和显式 cancelConfirmation(reason)；control request 失败时清理 callback/timer、拒绝 confirmation，并原样重新抛出原始 CLI 错误。确认超时计时器只在 control request 成功后按总预算剩余时间启动。
• 变更文件：
  • src/server/services/conversationService.ts
  • src/server/__tests__/conversations.test.ts
• 验证证据：
  • 三个权限模式顺序回归：3 passed、0 failed。
  • 同组三用例 coverage：3 passed、0 failed，不再挂起。
  • 完整 conversations.test.ts coverage：96 个具名测试全部完成并通过；Windows afterAll 临时目录清理另有一次 EBUSY，不属于行为断言失败。
  • 回归额外断言 CLI 拒绝后 outputCallbacks 为空、pendingPermissionModeChanges 为空。

QA-002｜Windows check:coverage 的 root-server 阶段异常慢

• 严重程度：测试基础设施
• 状态：fixed / verified
• 实际结果：单次 bun run check:coverage 在第一个 root-server 覆盖率套件持续 22 分钟，没有生成 coverage.log 或 lcov 产物；Bun 进程保持约单核满载、约 500 MB working set 且响应正常。
• 历史对照：同机历史 coverage 报告中 root-server 阶段约为 135、151、190 秒。
• runner 限制：scripts/quality-gate/coverage.ts 会把整个子进程 stdout/stderr 缓冲到退出后再写日志，且没有套件级 timeout，所以执行中没有可用于定位最后用例的进度产物。
• 处置：确认 PID、父子关系和完整 command line 后，仅终止本次 check:coverage 的三个 Bun 进程；没有启动重复运行，也没有影响 Vite、Electron 或其他测试。
• 根因定位：连续权限模式用例会触发 BUG-003 的 pending confirmation 泄漏；定向 coverage 修复后不再挂起。
• 结论：首次覆盖率门禁记为 blocked/timeout；修复后完整重跑在 130.2 秒内完成，5/5 suites passed，changed lines 95.56%（43/45）。

BUG-004｜Bun 下销毁 CONNECTING WebSocket 会永久停在 CLOSING

• 严重程度：P1
• 状态：fixed / verified
• 对应用例：WIN-05
• 发现方式：修复 BUG-003 后，完整 coverage 的 adapters 阶段为 405 passed、1 failed；WsBridge > destroy cleans up all sessions without leaking connecting-socket errors 在 20ms 后仍保留一个 error listener。
• 根因：Bun 1.3.11 会把 bare ws 导入替换为 BunWebSocket 兼容层。对仍为 CONNECTING 的不可达连接立即调用 close() 或 terminate()，socket 会永久停在 CLOSING，且不再触发 error/close；原临时 error sink 和 close listener 因而永久保留。
• 修复：CONNECTING 状态不再调用会毒化状态的 close/terminate。移除业务 listener 后只挂 teardown listener：自然 error 被消费并清理；若 open 先发生，则再正常 close，并在 close/error 时清理。OPEN/CLOSING/CLOSED 的原关闭路径保持不变；生产代码没有新增任意超时。
• 变更文件：
  • adapters/common/ws-bridge.ts
  • adapters/common/__tests__/ws-bridge.test.ts
• 验证证据：
  • 聚焦测试：13 passed、0 failed。
  • 聚焦 coverage：13 passed、0 failed；ws-bridge.ts lines 85.59%、functions 73.68%。
  • 回归按条件等待 CLOSED，并断言 open/error/close listeners 全部为 0。
  • bun run check:adapters：406 passed、0 failed。
  • 修复后完整 bun run check:coverage：5/5 suites passed。

BUG-005｜Trace abort backstop timer 被 unref 后在 Bun/Windows 单核自旋

• 严重程度：P1
• 状态：fixed / verified
• 对应用例：Trace/诊断稳定性、server 质量门禁
• 发现方式：check:server 卡在 trace-capture.test.ts；拆分单文件后，在任何测试结果输出前持续占满一个 CPU 核心。
• 根因：captureResponseTraceSnapshot 对无法被 cancel 唤醒的永久 pending reader.read() 使用 grace backstop timer，但该 timer 随即 unref()。Bun 1.3.11 Windows 在 Promise.race 只剩 pending read 与 unref timer 时会同步忙循环，timer 不触发。
• 修复：保留 backstop timer 的 event-loop 引用，并注释说明它是当前函数正在等待的正确性兜底，不能 unref。
• 变更文件：src/services/api/traceCapture.ts
• 验证证据：
  • 原挂起用例：1/1 passed，63ms。
  • 完整 trace-capture.test.ts：61/61 passed、281 assertions，Bun 2.67 秒，自然退出。
  • bun run check:server：219 files、2248 passed、0 failed。
  • bun run check:chat-contract：5 files、299 passed、0 failed。

QA-003｜Reconciliation safety sweep 测试等待 unref interval 时忙循环

• 严重程度：测试基础设施
• 状态：fixed / verified
• 实际结果：前 5 个测试显示 passed 后进程持续单核满载，没有最终汇总；定位到第 6 个 low-frequency safety sweep 用例。
• 根因：测试 await 的 Promise 只能由 production 中已 unref() 的 safety interval resolve；pending Promise 不保持事件循环活跃，在没有 referenced timer 时 Bun runner 忙等，测试也无法走到 watcher.stop()。
• 修复：用已有带 referenced Bun.sleep 的 waitFor 等待首个 batch，并用 try/finally 始终释放被阻塞的首批次、停止 watcher。
• 变更文件：src/server/services/localIndex/reconciliationWatcher.test.ts
• 验证证据：单用例 1/1 passed、191ms；完整文件 7/7 passed、570ms，自然输出汇总并退出。

BUG-006｜Windows 下停止系统代理时 CONNECT 连接使 Electron 测试超时

• 严重程度：P1 / Windows 资源生命周期
• 状态：fixed / verified
• 触发用例：WIN-04；check:native 内的 SystemProxyBridge > closes active CONNECT clients and outbound routes during stop。
• 实际结果：Vitest 单文件通过，但 native 使用的 Bun test runner 中 bridge.stop() 稳定超过 500ms。
• 根因：Bun/Windows 对已升级的 CONNECT socket，仅销毁桥接层跟踪的 socket 不足以让 http.Server.close() callback 完成。
• 修复：先销毁已跟踪的 client/outbound sockets；仅在 server 仍处于 listening 时调用 closeAllConnections()，然后调用并等待 server.close()。保留 listening guard，避免破坏 startup/stop 竞态。
• 变更文件：desktop/electron/services/systemProxyBridge.ts
• 验证证据：Bun 聚焦测试 18/18 passed；Electron TypeScript passed；完整 check:native 中 Electron 310 passed、1 skipped、0 failed，目录打包与 current package smoke passed。

QA-004｜Tray 测试与 Menu 测试共享 Electron 模块 mock

• 严重程度：测试基础设施
• 状态：fixed / verified
• 触发用例：check:native 内 tray.test.ts 的未处理错误 Electron tray mocks were not initialized for this test。
• 实际结果：tray 单文件 4/4 passed；与 menu 测试联跑时稳定失败，证明是测试加载顺序相关污染。
• 根因：Bun 整套 Electron 测试共享 electron 模块 mock 注册表，menu.test.ts 与 tray.test.ts 会互相覆盖模块级 mock。
• 修复：installTray 接受可选且类型受限的 Electron runtime 注入，生产默认仍动态导入 Electron；tray 测试改为注入本地 mocks，不再注册全局 vi.mock('electron')。
• 变更文件：desktop/electron/services/tray.ts、desktop/electron/services/tray.test.ts
• 验证证据：tray 4/4 passed；menu + tray 15/15 passed；Electron TypeScript passed；完整 check:native passed。

BUG-007｜项目 Agent 保存被可选热重载阻塞 120 秒

• 严重程度：P1 / Agent 管理可用性
• 状态：fixed / verified
• 触发用例：AGT-03、AGT-08。
• 实际结果：Project Agent 的文件和列表刷新已完成，但 Create Agent 对话框仍保持 Save/Cancel disabled 与 loading；120 秒后才关闭并显示 The change was saved, but the latest agent configuration could not be fully applied. Request timed out after 120s。
• 现场证据：首次隔离工作区位于外层 Git 仓库内，服务端按既有 Git-root 规则将文件写到仓库 .claude/agents/project_reviewer.md；该测试文件及本轮创建的空 agents 目录已精确清理。随后在 artifacts/manual-ui-91829e91/workspace 内初始化独立 Git 根，后续复测不会写入产品仓库。
• 根因：desktop/src/stores/agentStore.ts 在已成功 create/list 后仍等待 agentsApi.reload()；reload 请求使用 120 秒 timeout，并在结束前保持全局 isMutating=true。热重载本应是保存后的非阻塞增强，失败只需 warning + Retry。
• 修复：create/update/delete 在持久化和列表刷新成功后立即结束 mutation；session reload 改为后台 warning，并用 request id 隔离项目切换后的迟到结果。
• 验证证据：AgentManager + agentStore 44/44 passed，desktop lint passed；Computer Use 复测点击 Save 后约 1.2 秒进入 Agent 详情页，提示“active CLI session is not running”但 Save/Cancel 不再阻塞。

BUG-008｜Agent Git 根缓存未感知运行中新增的嵌套仓库

• 严重程度：P1 / 项目隔离与数据安全
• 状态：fixed / verified
• 触发用例：AGT-03。
• 实际结果：Create Agent 表单显示目标为 artifacts/manual-ui-91829e91/workspace，且该目录已通过 git init 成为独立 Git 根；保存后文件仍被写入外层产品仓库 .claude/agents/project_reviewer_fixed.md。
• 现场证据：git -C artifacts/manual-ui-91829e91/workspace rev-parse --show-toplevel 返回隔离工作区；隔离目录无 Agent 文件，外层文件的创建时间与本轮保存一致。已读取并核对内容后精确删除该测试文件。
• 根因：Agent 服务首次解析隔离目录时它尚未初始化为仓库，findGitRoot(realCwd) 的全局缓存记录了外层仓库；运行中 git init 后 Agent CRUD 仍复用旧缓存，且 clearAgentDefinitionsCache() 不会清理 Git-root 缓存。
• 修复：项目 Agent 路径解析前按 realCwd 刷新 Git-root 缓存；新增“先预热父仓库、再创建嵌套 .git”的 API 回归测试。
• 验证证据：新增用例在临时撤掉修复时按预期失败，恢复后 agents-api.test.ts 17/17 passed、260 assertions。重建 Sidecar 并重启隔离 Electron 后，Computer Use 创建 project_reviewer_fixed2，约 1.5 秒进入详情页且目标显示隔离工作区；Shell 确认文件只存在于 artifacts/manual-ui-91829e91/workspace/.claude/agents/，外层产品仓库同名文件不存在。

BUG-009｜Windows 本地半关闭连接堆积并拖垮 Session 列表

• 严重程度：P0 / Windows 桌面核心可用性
• 状态：fixed / focused + live Windows verified
• 触发用例：WIN-06、CTX-01、会话列表与 Scheduled 冒烟。
• 实际结果：左侧短暂显示 Session list failed to load / Request timed out after 120s，稍后刷新又自行消失。同期并非只有 Session：16:59:19 的 Task list 与 turn-checkpoints 同时 120 秒超时；17:04:01 的 /api/sessions?limit=400 与 /api/scheduled-tasks 同时 120 秒超时，之前分别有两次 context inspection 20 秒超时。
• Windows 现场证据：Sidecar 和 CLI 进程始终存活，故障窗口无 Electron/Bun crash；端口 51529 残留 9 对异常连接，Electron 侧为 FinWait2、Sidecar 侧为 CloseWait。Session 目录只有 3 个小 JSONL，本地 SQLite 也很小，不支持“400 条 Session 扫描过慢”的解释。
• 首轮根因假设：ContextUsageIndicator 的 HTTP deadline 与服务端 get_context_usage control budget 同为 20,000 ms，客户端 abort 与服务端 timeout 同刻竞速，使 localhost keep-alive socket 未及时收尾。该假设只能解释早期相关性，不是最终根因。
• 最终根因：Electron/Chromium 会长期池化 HTTP/1.1 本地连接，而 Bun.serve 配置 idleTimeout: 60。Chromium netlog 证明失败的 source 4974 在 socket #1319 空闲约 104 秒后复用：此前该 socket 多次正常收发，复用时客户端成功写入 684 bytes，服务端却不再返回响应头，120,011 ms 后 Chromium 取消。Windows 上 Bun 超时后的 socket 没有被客户端识别为已关闭，形成 stale keep-alive；任务、turn-checkpoints、workspace-status 等任意复用该连接的 REST 都会受影响。
• 修复：保留客户端/abort/health 的正确生命周期修复，并将本地 Bun.serve HTTP idleTimeout 设为 0，让 Chromium 客户端拥有池化连接生命周期，避免 server 先静默失效而 client 继续复用。曾尝试给所有 REST 响应加 Connection: close，但 12 次导航制造 403 个 TIME_WAIT，已撤回该全局策略。
• 变更文件：
  • desktop/src/components/chat/ContextUsageIndicator.tsx
  • desktop/src/components/chat/ContextUsageIndicator.test.tsx
  • desktop/src/api/client.ts
  • desktop/src/api/client.test.ts
  • desktop/src/stores/cliTaskStore.ts
  • desktop/src/stores/cliTaskStore.test.ts
  • desktop/electron/services/sidecarManager.ts
  • desktop/electron/services/sidecarManager.test.ts
  • src/server/index.ts
  • src/server/__tests__/server-options.test.ts
  • src/server/requestLifecycle.ts
  • src/server/api/sessions.ts
  • src/server/services/conversationService.ts
  • src/server/__tests__/conversations.test.ts
• 验证证据：
  • 服务端 abort callback 清理：1/1 passed；服务端 timeout listener 清理：1/1 passed。
  • ContextUsageIndicator 聚焦 Vitest：7/7 passed。
  • 重建 Sidecar、重启同一隔离 Electron 后，真实 DeepSeek 返回 WINDOWS_TIMEOUT_FIX_ACTIVE，会话列表与 context 2% 正常。
  • 修复版基线为 0 CloseWait / 0 FinWait2；Computer Use 连续手动刷新 context 10 次后仍为 0 / 0，仅有正常 Established 和短期 TimeWait。
  • 随后会话列表手动刷新约 1.3 秒，Scheduled 页面约 1.3 秒打开，均无 timeout；这只证明了短时场景。
  • 最终定位前的重启复现中，真实 MiniMax 多模态会话跨过 120 秒后再次出现 CloseWait/FinWait2，并在稍后明确写入 3 条新的 120 秒诊断：task-list、turn-checkpoints、workspace-status；这批证据用于否定“只是 context 计算慢”。
  • server-options.test.ts、request-lifecycle 与 tasks 聚焦回归合计 14 passed / 0 failed / 27 expects；Sidecar 重新编译成功。
  • 修复版真实 Electron 启动后先空闲 85 秒，随后 MiniMax 在同一轮并发执行 2 个 TaskCreate、TaskList + 2 个 TaskGet、2 个 TaskUpdate 和最终 TaskList，UI 两项均为绿色 completed，模型返回 TASK_PARALLEL_IDLE0_OK。
  • 修复版 netlog 中同一路径最慢 235 ms，所有 localhost API 最慢 578 ms；运行 137 秒后 sidecar 仍只有正常 Established，0 CloseWait / 0 FinWait2，诊断日志无新增 timeout。WIN-06 改为 passed。
  • 使用官方 @oven/bun-windows-x64-baseline@1.3.14 binary 重编译 sidecar；真实 Electron 空闲 106 秒后 MiniMax 返回 IDLE0_BUN1314_OK，运行 131 秒仍为 0 CloseWait / 0 FinWait2 且无新增 timeout，排除仅在系统 Bun 1.3.11 上偶然通过。
  • cliTaskStore 新增同一 session 重叠轮询合并；聚焦 12/12 passed，避免 React/轮询重入放大本地连接压力，但它不是 stale socket 根因的替代修复。
• 剩余风险：H5 开启时 sidecar 监听 0.0.0.0，idleTimeout: 0 也会允许尚未发送完整 HTTP headers 的裸 TCP 连接长期占用资源。当前 H5 token 鉴权只发生在形成 HTTP 请求之后；若要彻底收敛 slowloris/资源占用风险，应将桌面 loopback 与 LAN H5 listener 拆分，或增加 pre-header 连接级 deadline。此架构项不影响本轮 localhost timeout 修复结论，但发布时需要风险接受或后续整改。

BUG-010｜Windows 宠物窗口重启后失去置顶层级

• 严重程度：P1 / Windows 桌面宠物可见性
• 状态：fixed / focused + live Windows verified
• 触发用例：PET-01、PET-02。
• 实际结果：完整重启隔离 Electron 后，宠物窗口存在且 shaped region 正确，但被 ChatGPT 等普通窗口遮住；用户只能偶尔看到很小的光标/透明边缘，容易误判为宠物图片资源缺失。
• 排除项：当前配置选择的是仓库内置 dada-code，4 个内置宠物资源均存在且与 HEAD 一致。另一台电脑导入的猫/狗宠物位于 ${CLAUDE_CONFIG_DIR}/cc-haha/pets，属于本地用户状态，不会通过 Git 自动同步；本次故障不是资源丢失或 fallback。
• Windows 现场证据：修复前宠物 Win32 z-rank 285，ChatGPT 为 39，窗口样式 topmost=false；宠物 mascot region 为 96,116,288,322，任务卡 region 为 12,322,372,388，证明渲染区域存在但层级错误。
• 根因：BrowserWindow 构造时的 alwaysOnTop: true 在 Windows showInactive() 后未保持；代码只在 macOS 分支重新调用 setAlwaysOnTop。
• 修复：showInactive() 后，macOS 继续使用 setAlwaysOnTop(true, 'floating')，Windows 等其他平台显式调用 setAlwaysOnTop(true)。
• 变更文件：
  • desktop/electron/services/petWindow.ts
  • desktop/electron/services/petWindow.test.ts
• 验证证据：
  • bun run test -- --run electron/services/petWindow.test.ts：24/24 passed（连续两次）。
  • bun run build:electron：passed；重启隔离 Electron 两次。
  • 修复后宠物 topmost=True、z-rank 13，高于主窗口 30 与 ChatGPT 43；截图/可访问性树可见 192px Dada 和“暂无进行中的任务 / 收起 0 个任务”。
  • 后续 BUG-011 修复原生 shape 与前端层级后，Computer Use 已能真实鼠标命中任务圆点和关闭按钮；宠物本体拖动与多显示器位置恢复仍未完成，PET-02 继续保持 partial。

BUG-011｜宠物任务卡顶部被原生 shape 裁切，关闭按钮被宠物透明命中区截获

• 严重程度：P1 / Windows 宠物任务面板可用性
• 状态：fixed / focused + live Windows verified
• 触发用例：PET-02、PET-04；用户截图显示卡片顶部圆角/阴影缺失，点击卡片下方箭头没有反应。
• 实际结果：任务卡 DOM 矩形紧贴 Windows BrowserWindow.setShape() 边界，圆角抗锯齿与阴影越界部分被原生窗口裁切；关闭按钮绝对定位在卡片 DOM 矩形外，最初既不在原生命中 shape 内，又处在 z-index: 5 的卡片 stacking context 中，低于 z-index: 10 的宠物透明按钮区域。鼠标点箭头实际聚焦宠物按钮，因此卡片不关闭。
• 排查证据：
  • 修复前真实鼠标点击箭头后 UI 无变化，隔离配置 showTaskPanel 仍为 true。
  • 同一界面用 Tab 将焦点移到关闭按钮并按 Enter，卡片立即隐藏且 showTaskPanel 变为 false，排除 React handler 和偏好持久化故障。
  • 修复层级前鼠标点击箭头后，下一次 Tab 焦点从宠物按钮移到任务行，证明点击被宠物透明命中区截获。
• 修复：
  • Windows/Linux 原生交互 shape 对每个渲染区域增加 12px 安全边距并钳制在 384×400 窗口内，保留圆角、边框抗锯齿和阴影。
  • 将独立关闭按钮注册为原生命中区域，并纳入 renderer 的交互点/透传判断。
  • 将任务卡 stacking context 提升到 z-index: 15，高于宠物按钮的 z-index: 10，让画在宠物上方的关闭按钮也实际接收鼠标事件。
• 变更文件：
  • desktop/electron/services/petWindow.ts
  • desktop/electron/services/petWindow.test.ts
  • desktop/src/features/pets/PetApp.tsx
  • desktop/src/features/pets/PetApp.test.tsx
  • desktop/src/theme/globals.css
  • desktop/src/theme/globals.test.ts
• 验证证据：
  • 原生 shape 回归 24/24 passed；PetApp + globals 聚焦回归 24/24 passed。
  • 真实 Windows Electron + DeepSeek 编程任务中，卡片四角、顶部边框和阴影完整可见。
  • Computer Use 真实鼠标完成“数字圆点展开 → 箭头关闭 → 数字圆点恢复”两轮；第二轮无键盘辅助或 DOM 注入。
  • 隔离配置最终为 showTaskPanel: false，证明关闭状态已真实落盘。

当前测试限制

• LIVE-001（closed）：用户明确授权真实 Provider 额度并提供专用测试配置。隔离 Electron 中 DeepSeek 连接测试 179 ms 成功，deepseek-v4-pro 已设为默认；真实回复 LIVE_DEEPSEEK_OK、拒绝权限后的 CHAT_CONTINUES 和修复后重启的 WINDOWS_TIMEOUT_FIX_ACTIVE 均通过。配置与证据只保留在隔离测试目录，本文不记录密钥。
• PROVIDER-001（closed / false negative）：MiniMax-M3 的 Anthropic 兼容接口确实支持 image block。此前出现 [Unsupported Image] 的会话复用了由 DeepSeek 产生该文本的历史 assistant 消息，并把同一图片重复附加，不能作为 MiniMax 不支持图片的证据。使用首轮即选 MiniMax-M3 的全新会话、只附一张 canary.png 后，真实模型准确返回 PDF_CANARY_91829E91；trace 为 /anthropic/v1/messages、1 个 image block、HTTP 200，prompt 仅出现 1 次，请求和响应均无 [Unsupported Image]。离线附件序列化回归 conversation-attachments.test.ts 为 3 passed / 0 failed / 22 expects。MiniMax 连接测试为 1,349 ms，本文不记录密钥。
• LIVE-002（closed）：真实 MiniMax-M3 编程流程调用 TaskCreate/List/Get/Update、SubAgent、Read/Bash 并运行 bun test，3 个任务全部完成、测试 2 passed / 0 failed，最终返回 REAL_TASK_AGENT_FLOW_OK。真实 DeepSeek 流程同样完成 3 个 Task V2、真实编辑和 bun test，最终返回 DEEPSEEK_TASK_V2_OK 2 pass, 0 fail。这两条均为隔离 Git 工作区的实际 Provider 流程，不是 mock。
• PLAT-001：项目声明的 Electron 42.4 本地二进制不可用，本轮交互暂用已缓存的 Electron 42.3。最终构建与源码门禁不受此回退影响，但 Electron 版本特异风险会在最终结论中单独保留。
• NATIVE-001（closed）：check:native 首次执行在替换 Windows sidecar 时因隔离 Electron 遗留进程持有 exe 而 EPERM。核实进程链为隔离测试的 bun 39396 → electron 29132 → sidecar 44260 后仅结束该实例；清理后门禁进入 Electron 套件并暴露 BUG-006 / QA-004，修复后完整重跑 passed。

最终门禁汇总

• bun run check:impact：policy blocked；正确识别 adapters、cli-core、desktop、server，并要求 desktop、server、provider-contract、chat-contract、adapters、native、coverage。唯一 blocker 是 CLI core 变更需要 PR 标签与维护者批准，不是测试失败。
• bun run check:desktop：passed；完整 Vitest、lint 与 production Vite build 均成功。首轮仅因旧断言仍期待 20 秒 context timeout 而失败；更新为当前 30 秒契约后聚焦 30/30 passed，完整门禁重跑通过。
• bun run check:server：passed；221 files、2254 passed、0 failed。首次与其他大门禁并行时 conversations.test.ts 单例触发 10 秒资源竞争超时；单例 203 ms 通过，随后完整串行重跑通过。
• bun run check:provider-contract：passed；18 个 deterministic suites 全部通过。
• bun run check:chat-contract：passed。
• bun run check:adapters：passed；406 passed、0 failed、1091 assertions。
• bun run check:native：passed；sidecar compiled smoke 8/8，Electron 311 passed、1 个 macOS-only skipped、0 failed；Electron production build、Windows x64 目录打包及 current package smoke 均通过。一次 1 秒命令超时是执行器主动中止，不是代码失败，完整重跑 84 秒成功。
• bun run check:coverage：passed；5/5 groups、0 failed，报告位于 artifacts/coverage/2026-07-22T11-11-42-208Z/coverage-report.md。
• 最终工作区核对：git diff --check passed；git diff --stat 为 53 个已跟踪文件、931 insertions / 301 deletions（另有本轮新增测试与两份人工文档）；git status --short 已复核。未执行 bun run verify，因为本轮按 check:impact 选择的最小完整门禁交付，未声明 PR-ready/push-ready。