dsh-workbuddy-xdpool 1.7.2 → 1.7.4

package/CHANGELOG.md

@@ -4,6 +4,88 @@
 
 版本号遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
 
+## 1.7.4 — 装在中文文件夹里的 WorkBuddy，终于找得到了
+
+> 「腾讯」两个字，让插件整整看不见一个装好、登录着、正在运行的 WorkBuddy。
+
+**你会看到**：插件卡片报「找不到 WorkBuddy 桌面端，无法取得密钥」，可你明明：程序装着、还开着、凭据文件就在那儿躺着。中文 Windows 上，只要**安装路径里带中文**（比如 `D:\ruanjian\anzhuang\腾讯\WorkBuddy\`）就会中招——国内用户把软件装进中文目录太常见了。
+
+**为什么**：插件去注册表里问「WorkBuddy 装哪儿了」，用的是 `reg.exe`，而 `reg.exe` 按**系统控制台代码页**输出——中文系统就是 GBK（936）。我们这边却当成 UTF-8 去读。于是：
+
+```
+实际路径：D:\ruanjian\anzhuang\腾讯\WorkBuddy\WorkBuddy.exe
+读出来：  D:\ruanjian\anzhuang\��Ѷ\WorkBuddy\WorkBuddy.exe   ← 存的什么鬼
+```
+
+`腾讯` 变成 `��Ѷ`，这个路径当然**不存在**。所有候选路径全部落空，插件就得出「没装」的结论。可笑的是它其实**探到了**注册表记录，只是**读成了乱码**。
+
+这个坑和之前那个「装到非系统盘」是两回事——那个是找不到记录，这个是找到了但读不对。
+
+**怎么修的**：
+
+- **改走 PowerShell 读注册表**（主路径）。`Get-ItemProperty` 直接调注册表 API，**根本不过控制台代码页那一关**，中文路径原样拿到；
+- **保留 `reg.exe` 作后备**（万一机器上 PowerShell 不可用），但**不再假定 UTF-8**：按字节读进来，逐个尝试各种编码，并且**用「这个路径是否真的存在」来判定哪个解码是对的**——这是唯一能区分「正确字节」和「看着像那么回事的乱码」的办法。
+
+**顺带修了报告里提到的两点**：
+
+- `DisplayIcon` 和 `InstallLocation` **两个字段都读**（不少安装包的 `InstallLocation` 是空的，只有 `DisplayIcon` 有值），并且清理 `",0` 后缀的逻辑保持不变；
+- `doctor` **现在会把探测到的每一条路径原样列出来**，前面标 `✓`/`·` 表示存不存在。以前它压根不显示这些路径——而这恰恰是排查「装了却找不到」最该看的东西。**乱码路径现在一眼就能看见**，不用再靠猜。
+
+### 验证
+
+- 类型检查全绿，测试 **278 项全绿**（+2）。
+- 新增 `tests/windows-registry-encoding.test.ts`：在本机**真实创建**一个含中文的目录（`D:\...\腾讯\WorkBuddy\WorkBuddy.exe`）并写进真实注册表，然后跑插件的真实探测逻辑，断言**拿到的路径与真实路径完全一致、且文件确实存在**。
+- **反向验证**：把修复撤掉、退回「`reg.exe` + UTF-8」，含中文的路径**读不出来**（0 条），测试变红——确认这个测试真的能抓住这个 bug。
+- 实测 `doctor` 输出：`✓ D:\DSH\_doc_check\腾讯\WorkBuddy\WorkBuddy.exe`，中文完整、存在性正确。
+
+### 给中招的人（在你升级之前，或者万一还有别的编码）
+
+临时指路，设完**完全退出 DSH 再启动**：
+
+```powershell
+[Environment]::SetEnvironmentVariable("WORKBUDDY_APP_EXECUTABLE",
+  "D:\ruanjian\anzhuang\腾讯\WorkBuddy\WorkBuddy.exe", "User")
+```
+
+写进 `$DSH_HOME/.env` 也一样有效（不用注销，更省事）。
+
+## 1.7.3 — 模型不会因为一次网络抖动就消失
+
+> 开机那一秒网络还没起来，插件就把模型列表「降级」了，然后一整天都不再试第二次。
+
+**你会看到**：某次重启后，国内版的模型从 16 个变成 10 个，`deepseek-v4.1-flash` 之类凭空消失（国际版没事）。更麻烦的是你之前勾选过那个模型，于是**依赖这个 provider 的东西开始报错**（`has no configured model "deepseek-v4.1-flash"`），会话被悄悄切到国际版的同名模型上，而你根本不知道为什么。
+
+界面**没有任何提示** —— 只有日志里一条不起眼的 `[W]`。点卡片上的「重新检测账号」？**没用**。唯一的恢复方式是重启 DSH。
+
+**为什么**：启动时去拉模型列表，那一次**失败了**（日志显示同一秒里有好几个独立组件都报 `fetch failed`，而 0.7 秒后国际版就成功了 —— 典型的开机网络还没就绪）。失败之后：
+
+1. **不重试**，一次就放弃；
+2. **静默回退**到插件内置的那张静态表 —— 那张表里没有 `deepseek-v4.1-flash`，于是「拉取失败」在你眼里就是「模型被删了」；
+3. 「重新检测账号」这个按钮**只重新扫描账号**，压根不碰模型列表。名字起得太容易让人误会，你会以为它能修好，实际什么都不做。
+
+**怎么修的**：
+
+- **拉取失败自动重试**（1 秒 / 3 秒 / 8 秒，最多 3 次）。开机抖动基本一次就能救回来。重试会写日志并标明第几次，所以「列表为什么慢」是可查的。**一个 region 的重试不影响另一个** —— 两个网关是独立主机，没理由同归于尽；
+- **新增「重新获取模型」按钮**，并把它和「重新检测账号」分清楚：前者只管模型，后者只管账号，而且**后者现在也会顺带刷新模型**（因为大家都会去点它）；
+- **卡片会明说**：当前列表是「内置列表（离线）」时，模型区标题旁挂一个橙色标记，告诉你在看的是兜底表而不是完整清单，旁边就是重试按钮；
+- **兜底表按真实上游数据重建**。这是顺手挖出来的一个更严重的问题：旧表**几乎全部过时** —— `hy3` 的窗口写着 32K（实际 192K）、`kimi-k3` 这个 id 上游早就不用了（实际是 `kimi-k3-1`），而 `deepseek-v4.1-flash`、`kimi-k2.6/2.7/2.8`、`glm-5v-turbo`、`hy3-x` 全都不在表里。我是**直接拉了国内版的真实接口**逐条核对后重写的，包含窗口大小和倍率。过时的兜底表比短表更糟 —— 它看起来权威，实际是错的。
+
+### 一个差点修反的地方（顺手修了，免得白干）
+
+改完重试我差点以为完事，结果发现：「刷新失败」会把一个**本来正常的**列表也打回兜底状态。也就是说，如果当前用的是实时列表、只是这次刷新没成功，卡片反而会显示「离线」。这是**修反了** —— 所以现在**刷新失败保留现有列表**，只有真的没有实时数据时才标记为兜底。
+
+### 明确没做的
+
+- **不做定时自动重拉**。开机失败已有重试兜底，而正常运行时定期轮询模型接口只会增加无谓的上游请求；真要更新，点按钮即可。
+- **不做「缓存上次成功的列表到磁盘」**。这能彻底消灭回退问题，但会把模型清单持久化，涉及与 settings 文档的版本兼容；本轮先修「抖动即降级」这个主因，不夹带更大的改动。
+
+### 验证
+
+- 类型检查全绿，测试 **274 项全绿**（原 262 + 新增 13，另删掉 1 项一次性探针）。
+- 新增 `tests/catalog-resilience.test.ts` 覆盖：首次失败第二次成功的恢复、用尽重试后抛错、**被调用方主动取消的请求不重试**（否则会在被要求停止后继续干活）、重试写日志、兜底表含关键模型且无重复 id、窗口值均有效。
+- **反向验证**：把重试去掉 → 3 项变红；把「刷新失败降级」的错误改法放回去 → 1 项变红。确认测试真的能抓住这两个缺陷。
+- 拉取国内版**真实接口**核对兜底表：共 16 个模型，已全部按实测数据录入。
+
 ## 1.7.2 — 自动化不再「一跑跑一天」
 
 > 定好几点跑，就几点跑。之前是定好几点跑，然后从那一刻起每个整点都跑，跑到你睡觉。