Fleet 0.2.233

Fixed

• 北斗主会话和每个 Worker 不再各占一个可见的命令行窗口。执行宿主自己没有控制台，它启动 claude.exe（以及 Codex app-server）时没有带 windowsHide，Windows 11 就给每个进程开一个新的 Windows Terminal 窗口（标题 “claude”）；关掉这个窗口会直接杀掉对应的会话。10-21 的修复（22a7f87）一直停在分支上没有合入。现在这些进程都以无窗口方式启动（stream-json / app-server 本来就经管道通信），会话里的 Bash、PowerShell、cmd、git、hook 和 MCP 子进程实测同样不弹窗、照常执行；宿主与控制面启动的 taskkill、git、robocopy、天枢 python 采集、IM CLI、盘符枚举、hook shim、非 ASCII 路径 MCP 包装与自重启也一并补齐。生效时机：执行宿主换到新版本之后新拉起的会话；宿主仍按原规则等全部会话空闲后自动换代，已开着的旧窗口随对应会话重启消失。

• 手机端 PDF 阅读器在 Chrome 107（用户的 Android 手机）上不再整页空白。PDF.js 6.4.299 的 worker 把每个字体交给页面时都调用 ArrayBuffer.prototype.transferToFixedLength（Chrome 114+），PDF.js 自带的 core-js 不补它；Chrome 107 上每页都因此丢掉整个绘制列表，PDF 能打开、能翻页，但画布是白的。10-22 那次修复把根因误认为 Promise.try（其实 PDF.js 的 core-js 会补），而且只部署、没合入主线，10-26 起两个生产面都回到了旧版本。现在页面和 worker 共用同一份兜底（web/src/pdfCompat.ts，构建时编进 worker 的第一个 import）：补 transferToFixedLength/transfer、Response/Request/Blob.bytes（Chrome 132+，worker 取 CMap/标准字体/wasm 用）、ReadableStream 的 for await 迭代（Chrome 124+），保留 withResolvers/try/AbortSignal.any/URL.parse/sumPrecise。PDF.js 资源目录后缀改为兜底内容的哈希，改了兜底就自动换路径，避开 30 天 immutable 缓存；Service Worker 升到 beidou-v22。新增守卫测试：PDF.js 用到 Chrome 107 没有、且既无 core-js 也无本地兜底的 API 时测试失败。同时合入 10-22 分支的阅读器改动：45 秒加载超时并给出“用系统查看器打开 / 下载 PDF”出口、顶栏常驻“原文件”、画布上限 400 万像素并封顶 2x、/api/files/serve 支持单段 Range。

• 北斗主会话（Claude）调用 AskUserQuestion 时，网页和手机 PWA 上终于能点选并把答案交回原工具调用。根因：问题早已落进 chat.db，但控制面推给前端的 question_state 和回答接口都只对 Codex 放行，Claude 的问题从未到达前端，主消息流里只剩一张不能点的工具卡；用户只好打字回答，消息排在被提问卡住的回合后面，插队发送又打断了回合，工具调用以“用户拒绝”结束。10-24 的修复（d9985e7）停在分支上从未合入，0.2.230/0.2.231 都不含它。现在合入该修复并改为与 Worker 提问同一个卡片组件（选项纵向一行一个，每个选项就是一段完整内容（标题与说明连成一句，不再是短标签加一行注释）；单选、多选按选项顺序以 , 连接、自己填写或补充说明；Worker 提问卡同步改为同样的样式），答案经 stream-json permission channel 原地交回；手机经 Hub 隧道的请求按“真人”放行（此前 Worker 页回答在手机上同样会被 403），北斗自身与其他系统身份仍被拒绝。Claude 回合结束（含打断）时控制面直接关闭该回合未答的问题，不依赖宿主是否已升级；最近取消的问题保留在卡片上显示“提问已取消”。Service Worker 升到 beidou-v23。