Limcode Test 0.0.34

0.0.34

v0.0.33 的标签推送后，GitHub CI 在 Windows 上发现读取历史库文件时会误报“在读取时被替换了”，所以 0.0.33 没有发布安装包。0.0.34 包含原定 0.0.33 的全部内容，以及下面列出的修复。从 0.0.30 升级请直接装 0.0.34。

这一版的重点是：以前按工作区分开存放的旧聊天记录，尽量都能找回来、读得到、接着用。

旧聊天记录

• 以前各工作区各自一份的旧历史库，启动后会在后台自动合并进当前库。合并前先备份；合并时其它窗口照常工作。一次在线合并最多 4000 行或 12 MiB。
• 更大的旧库（最多 2000 万行）在"大库会话"里合并：
  1. 先只读估计需要多久、要多少磁盘空间。
  2. 倒计时 60 秒提示，可以推迟到下次启动。
  3. 同意之后才开始准备。
  4. 合并时所有窗口暂停一次，合并完重载。
• 删掉的对话不会被合并回来。从这一版起，删除对话时会写下删除记录，以后每次合并都跳过这些对话。这一版之前删掉的对话，如果旧库里还有，合并时会回来，合并确认框里写明了这一点。
• 在 0.0.24–0.0.30 里手动切换走的库不会自动合并。启动时由一个窗口问一次"全部合并 / 保持分开"。
• 以下归档和拷来的目录会列为只读的"外来历史库"，可以查看，也可以按需合并进当前库：
  • .limcode-runtime-backups 里的归档；
  • .limcode-copied-* 目录；
  • 0.0.10–0.0.20 命名的归档；
  • 以前用过的数据目录里的归档。

清理备份（新增）

• "历史与存储管理"里新增"清理备份"。只删能证明内容已经完整存在于当前库或某个历史库里的这几类东西：升级前备份、合并前备份、合并来源、归档。
• 备份里如果有你后来删除、编辑或重试替换掉的消息，会单独列出来，默认不勾选。删掉之后就再也看不到了。
• 当前库里已经找不到的对话，所在的备份一律保留。
• "查看存储占用"按类型统计当前库的正文。

迁移数据目录（新增）

• 设置页可以把数据目录迁到别处。先复制并逐项核对，再切换；旧目录保留。任何一步中断，都可以撤销或接着撤销。
• 迁走时还在进行的任务，要在旧目录里全部按中止收尾才放行。收不完就不打开旧目录，逐条说明原因，可以重试或改用新目录。
• 删除记录和合并账本会一起带走。旧目录里的归档仍然可见，最多记住 10 个以前的数据目录。

删除对话

• 任务正在跑也能删除。删除时先停掉整棵子树里的任务（包括其它窗口里的），再收尾，最后删除。
• 只删子对话时，父对话会收到"子任务已删除"，不会卡住。

多窗口

• 合并、迁移这类需要独占的维护会先协调所有窗口，全部确认后统一重载。等其它窗口时会说明原因和已经等了多久。
• 对话的恢复和审批只由对应项目的窗口接手。子 Agent、停止、压缩在多窗口下由哪个窗口处理更可靠了。
• 重载窗口后，会恢复输入框里没发出去的草稿、附件和编辑。

Provider 报错

• Provider 的额度或配额用完时，按永久错误处理，不再自动重试；状态码是 429 也一样。能识别的写法包括 Ask Sage 的 monthly token limit、OpenAI 的 insufficient_quota、中文网关的“额度已用完 / 余额不足”等。提示改成中文，写明提高额度或换一个渠道/模型之后，直接发送“继续”就能接着做。
• 按分钟、按秒的限流仍然照常自动重试。
• 工具调用之后的失败提示，原因里已经说了工具结果还在时，不再重复“工具结果已保留”。

Windows

• 修复 Windows 上读取历史库文件时误报“在读取时被替换了”。这个问题出在原定 0.0.33 的新代码里，没有进入任何已发布的版本；如果不修，会影响旧库升级、合并和外来历史库的读取。原因是 Node 在 Windows 上按路径取的文件信息里没有卷序列号，而按打开的文件取的有，两者对不上；现在 Windows 上只比较文件 ID。
• 计划检查读源码时统一换成 LF，Windows 检出（CRLF）也能通过。这一条不影响扩展本身。

其它

• 侧栏历史按页码定位。重命名、停止、重试等操作后回到第 1 页，并定位到这个对话。
• 只读历史里显示工具结果消息。
• 文件工具不再读取 SQLite 伴随文件。
• 数据库 worker 复用预编译语句，大事务更快。

已知限制

• epoch 3/4 的旧归档只能列出，暂时不能打开。
• 带有未完成任务的外来历史库暂时不能合并。
• 同时开着 0.0.30 或更早版本的窗口时，旧版本窗口不认新版本写的标记。请把所有窗口都升级到 0.0.34。
• 两个安装（例如 VS Code 和 code-server）同时对同一个数据目录清理备份时，彼此不互斥。
• 撤销或取消合并、迁移后，可能留下没有被引用的正文文件。它们只占空间，不影响使用。
• 迁移在"切换中"中断时，只能由发起它的那个安装接着处理。它回不来的话，要按提示手动处理。
• 删除对话时，如果在写下删除记录之后、删除提交之前崩溃，这个对话还留在当前库，以后合并时会跳过它在其它库里的副本。不会丢数据。
• 模型请求失败时点“重试此消息”，会从这一轮开头重来，已完成的工具会再执行一遍。想保留工具结果接着做，请直接发送“继续”。

验证

• 发布前做了一轮完全盲审，分 9 个方向：合并、大库合并、迁移数据目录、外来历史库、清理备份、删除对话、多窗口协调、数据库 worker、跨模块。其中会丢数据或导致执行出错的问题都已修复，并补了测试。关键防护做了变异测试，确认改坏代码时测试会失败。
• GitHub Actions 在发布提交 6a8874b8 上全部通过（Node 22.15.1）：
  • Windows、macOS、Linux 的编译与合同检查；
  • Windows、macOS 的运行时兼容测试，包括旧库升级；
  • 四个平台的安装包内容检查；
  • Linux 完整 --ci 回归：244 个测试文件，3254 项，0 失败。跳过的 43 项都是 Windows/macOS 专用测试。浏览器测试 3 项也通过了。
• 本机 Linux（Node 24）完整 --ci 回归，在 7315e30f 上 3247 项，0 失败。这之后的改动只跑了相关测试，最终由上面的 GitHub 回归覆盖。
• 上一轮 GitHub 回归出现过 3 项失败，都已处理：
  • 一个测试直接加载 .ts，Node 22 不支持，已改为 webview 测试；
  • 一个测试在等不占事件循环的计时器，已修正测试写法；
  • 多窗口协调测试失败过一次。本机加压跑了 8 遍也没能复现，推测是测试写请求文件不是原子写入。测试已改成原子写入，这个改动在发布之后单独提交。
• 没有在真实的 Windows 和 macOS 机器上手动安装使用过。
• 四个平台的 VSIX（Linux x64、Windows x64、macOS x64/arm64）都已通过内容检查，附 SHA256SUMS 校验文件。
• 构建源码：6a8874b830b78eb1451cd0b2e0f7afda34cdd18f，工作区干净。Runtime epoch 保持为 5。
• 直接推送到 main，没有经过 PR。