dsh-workbuddy-xdpool 1.7.1 → 1.7.3

package/CHANGELOG.md

@@ -4,275 +4,252 @@
 
 版本号遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
 
-## 1.7.1 (2026-09-28)
+## 1.7.3 — 模型不会因为一次网络抖动就消失
 
-一句话：**你存进去的设置，终于会在重启后真的生效了。顺带让那些甩不掉的失效账号可以永久请出去。**
+> 开机那一秒网络还没起来，插件就把模型列表「降级」了，然后一整天都不再试第二次。
 
-这一版修的都是社区朋友报的问题（[#17](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/17)、
-[#18](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/18)、
-[#19](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/19)），症状各不一样，
-但核心都是同一句话：**「我明明设置过了，它当没看见。」**
+**你会看到**：某次重启后，国内版的模型从 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 — 自动化不再「一跑跑一天」
+
+> 定好几点跑，就几点跑。之前是定好几点跑，然后从那一刻起每个整点都跑，跑到你睡觉。
+
+**你会看到**：把签到配成 9 点，它 9 点跑了；然后 10 点又跑、11 点又跑、13 点、14 点、15 点……**每个整点准时跑一次，一直跑到第二天零点**。配了 `[9]` 的签到，一天能跑 8 次。猫猫旅行同理，满勤。
+
+最诡异的是**有的任务正常、有的不正常**：活跃上报配的是 10 点，它就老老实实只跑一次。同样的代码、同样的时刻、同样的配置格式，凭什么它就能安分？
+
+**为什么**：一个字段被当成两种意思用了。
+
+闸门那边问的是「**配置的那个小时**花掉了没」——比如签到的 9 点，它去找的记号是 `今天的9点`。而跑完之后记账那边写的是「**现在几点**」——10 点 35 分跑完，写的就是 `今天的10点`。
+
+**两边的答案几乎永远对不上**。于是闸门永远是开的，任务每小时都能再跑一次。至于为什么最后变成「每个整点一次」而不是每分钟一次——还有一道「同一小时内不许重复」的节流挡着，所以最密也就是每小时一发。
+
+**那个「正常」的任务恰恰是证据**：上报配的是 10 点，而那次补跑碰巧发生在 10 点 35 分（同一小时内），它写下的记号**正好**是闸门要找的那个，于是就锁住了。纯粹是撞上的——换任何一个别的时刻，它照样失控。
+
+还有两个更隐蔽的变体，**即使在正确的时间点触发也会失效**：
+
+- **一天跑两次的任务**（猫猫旅行配 `[9, 21]`）：字段只有一个，存不下两个时间点。晚上 21 点跑完写下 `21`，早上那个 `9` 的记号就被顶掉了——于是它又「欠着」，22 点、23 点接着跑；
+- **跑得久的任务**：记的是**跑完**那一刻。11:58 开始、12:01 结束，就记成了 `12 点`——哪怕它是准时触发的。
+
+**怎么修的**：把「花掉的时间点」和「什么时候跑的」彻底拆开，而且花掉的时间点用**集合**记（因为一天可能有好几个）。
+
+- **闸门**改成只认「被花掉的那个配置小时」，一次一个，最早优先；
+- **节流**（同一小时不重复）改用单独的字段，不再和记账混在一起；
+- **手动点「立即运行」不再吃掉当天的排期**——它是「额外再跑一次」，不是「今天就算完事了」。所以 10 点 35 分按一下按钮，不会把晚上 21 点的猫猫旅行取消掉。
+
+### 顺手修了一个让我很惭愧的地方：卡片一直瞒着我们
+
+这次的问题**本该一眼看出来**，但卡片上每个任务只显示日期：
+
+```
+每日签到   09:00    2026-09-28 · 2
+```
+
+那个 `2026-09-28` 是**日期**，不是时刻。所以一天跑 1 次还是 8 次，卡片上**是同一句话**——肉眼看不出任何区别，只能去翻日志才发现。这就是它能活这么久的原因。
+
+修复：卡片改显示**真实运行时刻**（用的是本来就采集、本来就传输、就是没渲染的那个 `lastRunAtMs`）。数据链路一直是通的，就差最后打印出来那一步。
+
+### 还没有做的（说清楚，免得以为都好了）
+
+**运行记录仍然不落盘**，重启后当天「已跑过」的记忆会清空。所以如果你在 15:00 重启一次，已经跑过的 9/10/11 点会被认为「还没跑」，补跑一轮——**这是刻意保留的补跑设计**（笔记本睡过 10 点，醒来当天仍要跑），不是 bug。但它意味着「重启几次就补跑几次」，这点没有改变。
+
+真要连这个也记住，得把「花掉的时间点」和收益账本一样持久化。这次没做，因为补跑本身是对的、而每次重启补跑一轮的代价是可接受的（任务都是幂等的）；把它一起改了反而会让「睡过头当天不跑」。**先说明白，不夹带。**
+
+### 验证
+
+- 类型检查全绿，测试 **259 项全绿**（原 248 + 新增 11）。
+- 新增 `tests/automation-schedule.test.ts` 锁住四个场景：补跑后当日不再重复、一天两次的任务各跑一次且中间安静、跨整点仍记在被消耗的那个时间点上、手动运行不吃掉当天排期。
+- **反向验证**：把修复**完整撤回**成原始写法后，这 5 个关键用例全部变红（含「每整点重复执行」那条）——确认测试确实能抓住这个 bug，而不是闭着眼睛也绿。
+
+## 1.7.1 — 你存进去的设置，终于在重启后真的生效了
+
+> 顺带让那些甩不掉的失效账号可以永久请出去。
+
+这一版修的都是社区朋友报的问题（[#17](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/17)、[#18](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/18)、[#19](https://github.com/XDTrees/dsh-workbuddy-xdpool/issues/19)），症状各不一样，但核心都是同一句话：**「我明明设置过了，它当没看见。」**
 
 ### 一、重启一次，设置就白设一次
 
-**你会看到**：把账号使用方式调成「轮换模式」、把积分自动化打开、模型只勾了三四只……
-配置明明写进文件了，重启 DSH 一看 —— 模式跳回「优先」，自动化显示「已关闭」，
-模型**全部打勾**。改一次、重启一次、退一次，堪称赛博西西弗斯。
+**你会看到**：把账号使用方式调成「轮换模式」、把积分自动化打开、模型只勾了三四只…… 配置明明写进文件了，重启 DSH 一看 —— 模式跳回「优先」，自动化显示「已关闭」，模型**全部打勾**。改一次、重启一次、退一次，堪称赛博西西弗斯。
 
-**最关键的线索**（也是报问题那位朋友观察得最准的地方）：**同一张卡片上，
-「今日自动化」的收益账本能正常显示**（签到 +200、猫猫旅行 +26 都在）。
+**最关键的线索**（也是报问题那位朋友观察得最准的地方）：**同一张卡片上，「今日自动化」的收益账本能正常显示**（签到 +200、猫猫旅行 +26 都在）。
 
-账本读得出来、开关却是关的 —— 说明配置**读得到**，只是**没人去用它**。
-就好比你钥匙插得进去，但没人转那一下。
+账本读得出来、开关却是关的 —— 说明配置**读得到**，只是**没人去用它**。就好比你钥匙插得进去，但没人转那一下。
 
-**为什么**：负责把配置写到「池子 / 模型目录 / 自动化」这三个地方的那个函数，
-只在**两个事件回调**里被调用：设置变更时（0.1.5）和热更新时（0.1.7）。
+**为什么**：负责把配置写到「池子 / 模型目录 / 自动化」这三个地方的那个函数，只在**两个事件回调**里被调用：设置变更时（0.1.5）和热更新时（0.1.7）。
 
-问题就在这儿 —— 这俩都是**事件**，开机那一刻谁都不响。
-而 0.1.7 上那个 `configure({auto})` 只管登记「这个插件有个设置页」，
-**既不读值也不写值**。于是三条线全停在出厂默认值上，配置文件孤零零躺在磁盘上，
-写得一丝不苟，就是没人理它。
+问题就在这儿 —— 这俩都是**事件**，开机那一刻谁都不响。而 0.1.7 上那个 `configure({auto})` 只管登记「这个插件有个设置页」，**既不读值也不写值**。于是三条线全停在出厂默认值上，配置文件孤零零躺在磁盘上，写得一丝不苟，就是没人理它。
 
-顺带这也解释了一个「灵异现象」：为什么**退回旧版反而正常** ——
-旧版走的是另一条路（`onChange`），开机时会被触发一次。
+顺带这也解释了一个「灵异现象」：为什么**退回旧版反而正常** —— 旧版走的是另一条路（`onChange`），开机时会被触发一次。
 
-**怎么修的**：开机时老老实实调用一次，就一行。回归测试专门盯着「这行必须是
-开机就执行的独立语句」，防止以后有人手滑把它挪回回调里。
+**怎么修的**：开机时老老实实调用一次，就一行。回归测试专门盯着「这行必须是开机就执行的独立语句」，防止以后有人手滑把它挪回回调里。
 
 ### 二、自动化开关亮着「已开启」，实际一个任务都不跑
 
-**你会看到**：开关明明开着，界面也没报错，但**所有任务永远不会触发**。
-一个安静的、什么都不做的自动化。薛定谔的积分。
+**你会看到**：开关明明开着，界面也没报错，但**所有任务永远不会触发**。一个安静的、什么都不做的自动化。薛定谔的积分。
 
 **为什么**：一条自我强化的四段链条，每一环都在帮倒忙：
 
-1. 配置结构里把时间表写成了「可选数组」，于是**「没设置」被自动填成了空数组 `[]`** ——
-   从此「我没配」和「我故意配成空」长得一模一样；
+1. 配置结构里把时间表写成了「可选数组」，于是**「没设置」被自动填成了空数组 `[]`** —— 从此「我没配」和「我故意配成空」长得一模一样；
 2. 调度器看到 `[]` 觉得「这是个有效值」，欣然采纳，**内置的默认时间表永远用不上**；
-3. 判断「该不该跑」时看到空数组，直接回一句「不跑」——**永远地**；
+3. 判断「该不该跑」时看到空数组，直接回一句「不跑」—— **永远地**；
 4. 卡片在回写配置时**漏掉了「猫猫旅行」的时间**，还把空数组原样写了回去。
 
-于是文件被**固化**成空的，而且**你在界面上怎么点都修不好**——
-因为界面永远只会写回空数组。死循环。
+于是文件被**固化**成空的，而且**你在界面上怎么点都修不好** —— 因为界面永远只会写回空数组。死循环。
 
-**怎么修的**：空数组一律当作「没设置」，回落到默认时间表
-（签到 9 点、上报 10 点、任务 11 点、连登 12 点，猫猫旅行早晚各一趟 9 点和 21 点）；
-三个地方都改（构造、应用配置、卡片回写），并把时间表抽成**两端共用的一份**——
-宿主和浏览器代码没法互相引用，写两份迟早会漂移，那种漂移还特别隐蔽。
-顺手把「猫猫旅行永远写不回去」也修了。
+**怎么修的**：空数组一律当作「没设置」，回落到默认时间表（签到 9 点、上报 10 点、任务 11 点、连登 12 点，猫猫旅行早晚各一趟 9 点和 21 点）；三个地方都改（构造、应用配置、卡片回写），并把时间表抽成**两端共用的一份** —— 宿主和浏览器代码没法互相引用，写两份迟早会漂移，那种漂移还特别隐蔽。顺手把「猫猫旅行永远写不回去」也修了。
 
 ### 三、模型选择一丢，就给你「全选」
 
-**你会看到**：本来精挑细选勾了三四只模型，某天打开一看——**全勾上了**，
-而且**真正生效的也真的变成了全部**。你的精简清单变成了自助餐。
+**你会看到**：本来精挑细选勾了三四只模型，某天打开一看 —— **全勾上了**，而且**真正生效的也真的变成了全部**。你的精简清单变成了自助餐。
 
-**为什么**：「没有选择」和「选择丢了」这两种情况，在代码里长得**一模一样**
-（都是 `undefined`）。而它的兜底是个**空对象**，空对象翻译过来恰好是
-**「全部启用」**。
+**为什么**：「没有选择」和「选择丢了」这两种情况，在代码里长得**一模一样**（都是 `undefined`）。而它的兜底是个**空对象**，空对象翻译过来恰好是**「全部启用」**。
 
-所以一旦选择丢失，系统不是「保持不变」，而是**朝最离谱的方向**——
-把你有意关掉的模型全放出来。
+所以一旦选择丢失，系统不是「保持不变」，而是**朝最离谱的方向** —— 把你有意关掉的模型全放出来。
 
-**怎么修的**：兜底改成「**沿用现在正在生效的那份选择**」。
-丢了就丢了，至少不会变成「全开」。丢失只会原地不动，不会放飞自我。
+**怎么修的**：兜底改成「**沿用现在正在生效的那份选择**」。丢了就丢了，至少不会变成「全开」。丢失只会原地不动，不会放飞自我。
 
 ### 四、失效账号终于可以彻底请出去
 
-**这个不是 bug，是缺功能**。池子里混着国内版和国际版账号，国际版更容易触发风控。
-一旦某个号废了，它就一直赖在池子里 —— 而且**没有任何办法把它彻底弄走**。
+**这个不是 bug，是缺功能**。池子里混着国内版和国际版账号，国际版更容易触发风控。一旦某个号废了，它就一直赖在池子里 —— 而且**没有任何办法把它彻底弄走**。
 
-现有三条路都不行：「停用」只是让它不参与轮换（**账号还在卡片上、凭据文件还会被读取**）；
-命令行 `remove` 只对你手动导入的快照有效；`disabledAccountIds` 同样是「排除轮换」，
-不是「移除」。
+现有三条路都不行：「停用」只是让它不参与轮换（**账号还在卡片上、凭据文件还会被读取**）；命令行 `remove` 只对你手动导入的快照有效；`disabledAccountIds` 同样是「排除轮换」，不是「移除」。
 
 最要命的是：**只要你在桌面 App 里再登一次这个号，它就又回来了**。打地鼠。
 
 **怎么修的**：新增**「移出池子」**，和「暂时停用」明确分开：
 
-- **卡片**上每个账号多了个「移出池子」按钮，下面还有一块「**已移出的账号**」——
-  每条都能**恢复**。移除不是单向门，点错了能找回来；
-- **命令行**同步支持 `ignore` / `unignore` / `ignored`，`accounts` 也会列出已移出的号
-  （不然账号凭空消失，你还以为插件坏了）；
+- **卡片**上每个账号多了个「移出池子」按钮，下面还有一块「**已移出的账号**」—— 每条都能**恢复**。移除不是单向门，点错了能找回来；
+- **命令行**同步支持 `ignore` / `unignore` / `ignored`，`accounts` 也会列出已移出的号（不然账号凭空消失，你还以为插件坏了）；
 - 被移出的账号**连凭据都不再读取**，所以它**不会在你重新登录后又偷偷溜回来**。
 
-关于「为什么不干脆把凭据文件删掉」：那个文件就是桌面 App 当前登录的凭证，
-删了会把 App 一起登出；而且下次登录它还会生成回来。属于既伤人、又没用。
+关于「为什么不干脆把凭据文件删掉」：那个文件就是桌面 App 当前登录的凭证，删了会把 App 一起登出；而且下次登录它还会生成回来。属于既伤人、又没用。
 
-移出名单存在插件自己的文件里（`~/.dsh/.workbuddy-xdpool/ignored.json`），
-这样**命令行和卡片读写的是同一份**——不然会出现「卡片能改、终端改不了」的尴尬。
+移出名单存在插件自己的文件里（`~/.dsh/.workbuddy-xdpool/ignored.json`），这样**命令行和卡片读写的是同一份** —— 不然会出现「卡片能改、终端改不了」的尴尬。
 
 ### 五、国际版模型的「倍率」和「免费」标记回来了
 
-**你会看到**：国际版那几个模型的倍率（`x0.79` 这种）和「免费」标签不见了。
-光秃秃一行模型名，看着像没人管的弃儿。
+**你会看到**：国际版那几个模型的倍率（`x0.79` 这种）和「免费」标签不见了。光秃秃一行模型名，看着像没人管的弃儿。
 
 **为什么**（这个是拉了真实接口逐字段对出来的，两个毛病叠加）：
 
-1. 上游**明明发了** `tags` 字段，但我们的解析代码**从头到尾就没读它**——
-   读的时候没读，转换的时候又丢一次。所以卡片的标签逻辑**对两个平台的所有模型
-   都不可能命中**，白写了；
-2. 「免费」一直在等一个叫 `free` 的标签出现，而**两个平台从来没发过这种标签**
-   （实测标签是 `craft`、`text-to-image` 这类东西）。
-   真正的「免费」写法是 **`credits: "x0.00"`**——国际版有三只模型就是零费率，
-   它们一直免费，我们一直不知道。
+1. 上游**明明发了** `tags` 字段，但我们的解析代码**从头到尾就没读它** —— 读的时候没读，转换的时候又丢一次。所以卡片的标签逻辑**对两个平台的所有模型都不可能命中**，白写了；
+2. 「免费」一直在等一个叫 `free` 的标签出现，而**两个平台从来没发过这种标签**（实测标签是 `craft`、`text-to-image` 这类东西）。真正的「免费」写法是 **`credits: "x0.00"`** —— 国际版有三只模型就是零费率，它们一直免费，我们一直不知道。
 
-**怎么修的**：把 `tags` 老老实实读进来传下去；「免费」改成**看倍率是不是 0**
-（谁也不会为了 0 费率专门发个标签）；倍率是 0 的时候**不再显示「x0.00 积分」**——
-零费率的免费模型旁边挂个 0，还不如干脆说"免费"。
+**怎么修的**：把 `tags` 老老实实读进来传下去；「免费」改成**看倍率是不是 0**（谁也不会为了 0 费率专门发个标签）；倍率是 0 的时候**不再显示「x0.00 积分」** —— 零费率的免费模型旁边挂个 0，还不如干脆说「免费」。
 
-另外给「静态兜底列表」也补上了倍率：以前上游一抽风就回退到那份没倍率的列表，
-表现就是「倍率突然全没了」，你还以为是插件坏了，其实只是网络打了个嗝。
+另外给「静态兜底列表」也补上了倍率：以前上游一抽风就回退到那份没倍率的列表，表现就是「倍率突然全没了」，你还以为是插件坏了，其实只是网络打了个嗝。
 
 ### 六、顺便修了一个让我很尴尬的事
 
-上一版我说「可以了」，结果有人（其实就是我）改完代码**只改了源码仓库，
-忘了同步到 DSH 真正加载的那个目录**。所以怎么重启都看不到新按钮——
-代码在隔壁房间好好地跑着，你在这边找。
+上一版我说「可以了」，结果有人（其实就是我）改完代码**只改了源码仓库，忘了同步到 DSH 真正加载的那个目录**。所以怎么重启都看不到新按钮 —— 代码在隔壁房间好好地跑着，你在这边找。
 
 这版已经同步部署，并留了备份可以回退。
 
 ### 验证
 
 - 类型检查全绿，测试 **248 项全绿**（原 222 + 新增 26）。
-- 新增的两个测试文件**逐项做了反向验证**：把修复**撤回**去，测试必须变红
-  （撤回一处 → 1 项红；撤回另一处 → 2 项红；撤回忽略过滤 → 1 项红；
-  撤回标签读取 → 3 项红）。确认这些测试不是"闭着眼睛也全绿"的装饰品。
-- 拿**真实构建产物**跑端到端：空时间表能解析出默认值、被移出的账号在
-  **凭据文件还在的情况下不会被重新扫描进来**、恢复后能回来。
-- 拿**真实的国际版接口数据**跑完整解析链，确认倍率和免费标记的实际渲染结果
-  （20 个模型有倍率、3 个正确识别为免费）。
+- 新增的两个测试文件**逐项做了反向验证**：把修复**撤回**去，测试必须变红（撤回一处 → 1 项红；撤回另一处 → 2 项红；撤回忽略过滤 → 1 项红；撤回标签读取 → 3 项红）。确认这些测试不是「闭着眼睛也全绿」的装饰品。
+- 拿**真实构建产物**跑端到端：空时间表能解析出默认值、被移出的账号在**凭据文件还在的情况下不会被重新扫描进来**、恢复后能回来。
+- 拿**真实的国际版接口数据**跑完整解析链，确认倍率和免费标记的实际渲染结果（20 个模型有倍率、3 个正确识别为免费）。
 
 ### 最后
 
-感谢 [@hmtime](https://github.com/hmtime) 提交 #17 / #18。
-报告里「配置读得到、但没被应用」和「账本能显示、开关却是关的」这两句
-几乎是直接指向了根因 —— 光看现象的话，很容易一头扎进"肯定是写入失败了"的坑里
-查半天。这样的报告质量，值得一版单独的更新日志来谢。
+感谢 [@hmtime](https://github.com/hmtime) 提交 #17 / #18。报告里「配置读得到、但没被应用」和「账本能显示、开关却是关的」这两句几乎是直接指向了根因 —— 光看现象的话，很容易一头扎进「肯定是写入失败了」的坑里查半天。这样的报告质量，值得一版单独的更新日志来谢。
 
-## 1.7.0 (2026-09-25)
+## 1.7.0 — 同一构建通吃 DSH 0.1.5 / 0.1.7，设置入口搬进左栏
 
 一句话：**这一版终于能在 DSH 0.1.7 上活下来了，顺带把设置入口搬进了左栏、把页面重新排了一遍。**
 
-以前一个构建只能伺候 0.1.5 那条线，0.1.7 上是真的会出事 —— 不是"卡片不显示"这种小事，
-是整个 DSH 直接退出。现在两条线一个构建通吃。
+以前一个构建只能伺候 0.1.5 那条线，0.1.7 上是真的会出事 —— 不是"卡片不显示"这种小事，是整个 DSH 直接退出。现在两条线一个构建通吃。
 
 ### 一、0.1.7 上一启用插件，DSH 就原地去世
 
 先说症状，因为它实在太有迷惑性了：用户装好插件、点启用、**进程直接没了**。
 
-桌面端只留下一句 `DSH Host exited (1)`。日志？日志里最后一行还是个无关紧要的
-warning，然后就**戛然而止**，一个 error 都没有。
+桌面端只留下一句 `DSH Host exited (1)`。日志？日志里最后一行还是个无关紧要的 warning，然后就**戛然而止**，一个 error 都没有。
 
-这种"日志被齐刷刷截断"的样子，其实是宿主的一个设计在作祟：DSH 装了 `installFailLoud`，
-进程里**任何**没被捕获的异常、任何没接住的 Promise rejection，都会让它当场 `exit(1)`。
-而那句真正的死因只写进 stderr —— 打包版 Windows 应用压根没有控制台，于是它就
-悄无声息地消失了。查了半天日志找不到错，别怀疑自己，它真的没写进去。
+这种"日志被齐刷刷截断"的样子，其实是宿主的一个设计在作祟：DSH 装了 `installFailLoud`，进程里**任何**没被捕获的异常、任何没接住的 Promise rejection，都会让它当场 `exit(1)`。而那句真正的死因只写进 stderr —— 打包版 Windows 应用压根没有控制台，于是它就悄无声息地消失了。查了半天日志找不到错，别怀疑自己，它真的没写进去。
 
 那么是谁抛的？**三个坑叠在一起**，而且全在插件这边，内核无辜：
 
-**坑 1：宿主那边的 API 换了个名字，老代码还在敲旧门。**
-0.1.7 把 `settings.installSection(...)` 整个删了，换成了 `configure({auto}, owner)`。
-我们的代码虽然做了"先看看有没有"的判断，但问题是 —— 判断失败时它只是 **warn 一声就算了**，
-设置页从此永远不出现；而万一服务真在场，它就**直接裸调**，在 0.1.7 上"啪"地从
-`apply()` 里抛出去。宿主一看：未捕获异常，走你。
+**坑 1：宿主那边的 API 换了个名字，老代码还在敲旧门。** 0.1.7 把 `settings.installSection(...)` 整个删了，换成了 `configure({auto}, owner)`。我们的代码虽然做了"先看看有没有"的判断，但问题是 —— 判断失败时它只是 **warn 一声就算了**，设置页从此永远不出现；而万一服务真在场，它就**直接裸调**，在 0.1.7 上"啪"地从 `apply()` 里抛出去。宿主一看：未捕获异常，走你。
 
-**坑 2：客户端 `inject` 里写了两个"有你没我"的服务名。**
-0.1.5 提供 `settingsScope`，0.1.7 换成了 `configForms`。而 cordis 的依赖闸门是**硬**的：
-`inject` 里只要有一个服务不存在，`apply` 就**永远不会被执行**，fiber 就永远挂在那里
-PENDING。桌面端报 `renderer boot failed (plugins: dsh-workbuddy-xdpool)`，
-然后拒绝打开。它不报错，它就是不开。
+**坑 2：客户端 `inject` 里写了两个"有你没我"的服务名。** 0.1.5 提供 `settingsScope`，0.1.7 换成了 `configForms`。而 cordis 的依赖闸门是**硬**的：`inject` 里只要有一个服务不存在，`apply` 就**永远不会被执行**，fiber 就永远挂在那里 PENDING。桌面端报 `renderer boot failed (plugins: dsh-workbuddy-xdpool)`，然后拒绝打开。它不报错，它就是不开。
 
-**坑 3：卡片注册的那个槽位，0.1.7 里根本不存在。**
-`settings.plugin.item` 是 0.1.5 的专属座位。0.1.7 的设置左栏只认 `settings.section`
-（内置的通用 / 模型 / 插件页都坐那儿）。我们一直往一个不存在的座位上放东西，
-于是卡片安安静静地不显示 —— 不报错、不警告，就是不出现。
+**坑 3：卡片注册的那个槽位，0.1.7 里根本不存在。** `settings.plugin.item` 是 0.1.5 的专属座位。0.1.7 的设置左栏只认 `settings.section`（内置的通用 / 模型 / 插件页都坐那儿）。我们一直往一个不存在的座位上放东西，于是卡片安安静静地不显示 —— 不报错、不警告，就是不出现。
 
 **怎么修的：** 一律改成"先探路、再走"，不猜。
 
-- 宿主侧：有 `installSection` 就用它（0.1.5），没有就用 `configure({auto:true})`（0.1.7），
-  两个都没有才 warn。写入时的命名空间也得跟着线路换 —— 0.1.5 用自己起的名字，
-  0.1.7 得用**宿主给这个插件分配的条目 id**（`ctx.fiber.entry.options.id`）。
-  这里猜错的代价是每次保存都报 `No configurable plugin entry`。
-- 客户端：`inject` 只留两条线**都**有的 `slots` / `locale`，设置服务改用 `ctx.get()`
-  软探测（服务不在就返回 undefined，不抛）。
-- 顺手声明 `engines.dsh: ">=0.1.5-rc.1 <0.2.0"`，让插件市场把两条线都认成兼容；
-  另外把 `dsh.client.inject` 里早就停更的 `dsh-client-runtime` 噪声清掉了。
+- 宿主侧：有 `installSection` 就用它（0.1.5），没有就用 `configure({auto:true})`（0.1.7），两个都没有才 warn。写入时的命名空间也得跟着线路换 —— 0.1.5 用自己起的名字，0.1.7 得用**宿主给这个插件分配的条目 id**（`ctx.fiber.entry.options.id`）。这里猜错的代价是每次保存都报 `No configurable plugin entry`。
+- 客户端：`inject` 只留两条线**都**有的 `slots` / `locale`，设置服务改用 `ctx.get()` 软探测（服务不在就返回 undefined，不抛）。
+- 顺手声明 `engines.dsh: ">=0.1.5-rc.1 <0.2.0"`，让插件市场把两条线都认成兼容；另外把 `dsh.client.inject` 里早就停更的 `dsh-client-runtime` 噪声清掉了。
 
 ### 二、0.1.7 上保存没反应，或者说"没保存成功"
 
-0.1.7 有个硬门禁：**schema 里一个 `volatile` 字段都没标的条目，直接拒收**。
-`write()` 抛 `has no volatile fields`，`describe()` 干脆跳过它 —— 页面就是一片空白。
-我们的 Config 当时一个都没标，于是保存必炸、页面必空。
+0.1.7 有个硬门禁：**schema 里一个 `volatile` 字段都没标的条目，直接拒收**。`write()` 抛 `has no volatile fields`，`describe()` 干脆跳过它 —— 页面就是一片空白。我们的 Config 当时一个都没标，于是保存必炸、页面必空。
 
-还有个更阴的：0.1.7 把 volatile 字段以**活引用** `{get(): T}` 的形式交回来
-（这样改设置不用重挂载就能生效）。我们直接拿它去比较 —— 拿一个对象比一个字符串，
-结果就是**刚存进去的值，读回来是"没设置"**。
+还有个更阴的：0.1.7 把 volatile 字段以**活引用** `{get(): T}` 的形式交回来（这样改设置不用重挂载就能生效）。我们直接拿它去比较 —— 拿一个对象比一个字符串，结果就是**刚存进去的值，读回来是"没设置"**。
 
 对，这就是那个"我明明填了保留积分，重开又变回 0"的元凶。不是没存进去，是读错了。
 
-**怎么修的：** Config 全部 12 个字段都过一遍 `asVolatile()` —— schemastery 3.18.3+
-会调 `.volatile()`；0.1.5 那条线是 3.18.2，压根没这个方法，那就退化成什么都不做
-（不能手写 `meta.volatile`，那会绕过 schemastery 自己的摆放校验，塞给 0.1.5 一个
-它看不懂的东西）。读取则统一走 `unwrapVolatileDeep()` 把活引用剥开。
-另外监听 `loader/volatile-update`，保存后运行中的实例立刻重读，不用重启。
+**怎么修的：** Config 全部 12 个字段都过一遍 `asVolatile()` —— schemastery 3.18.3+ 会调 `.volatile()`；0.1.5 那条线是 3.18.2，压根没这个方法，那就退化成什么都不做（不能手写 `meta.volatile`，那会绕过 schemastery 自己的摆放校验，塞给 0.1.5 一个它看不懂的东西）。读取则统一走 `unwrapVolatileDeep()` 把活引用剥开。另外监听 `loader/volatile-update`，保存后运行中的实例立刻重读，不用重启。
 
 ### 三、设置入口搬进左栏 + 页面重新排了一遍
 
 - **入口**：改注册到 `settings.section`，左栏现在多出一行，名字叫 **XD Pool**。
-- **图标**：这个槽位的注册契约只投影 `id` / `order` / `label`，**没有 icon 字段** ——
-  宿主对不认识的 id 一律画个齿轮。想换图标只能自己动手：照着 `dshmarket` 的做法，
-  按 label 在 DOM 里认出自己那一行、打个标记，再用 CSS 把宿主的 svg 藏起来，
-  用 `mask-image` + `currentColor` 把自己的图标盖上去（颜色跟着主题走）。
-  外加一个 `MutationObserver` 盯着 —— 切语言、切主题时行元素会被重建，标记会掉。
-- **页面**：以前要点一下才展开，现在**整页直接铺开**，并且重新排成分区卡片：
-  页头（图标 / 标题 / 描述，右边放「重新检测账号」「清除冷却」）、
-  状态卡片（地区切换 + 状态灯 + 汇总 + 账号使用方式）、
-  自动化卡片、账号卡片、模型卡片。
-  顺带修了个陈年小毛病：原来有个 `if (!open) return`，意思是**没展开就一次都不去
-  拉状态** —— 所以你刚点开永远是空的，得傻等一轮轮询。现在挂载即拉。
+- **图标**：这个槽位的注册契约只投影 `id` / `order` / `label`，**没有 icon 字段** —— 宿主对不认识的 id 一律画个齿轮。想换图标只能自己动手：照着 `dshmarket` 的做法，按 label 在 DOM 里认出自己那一行、打个标记，再用 CSS 把宿主的 svg 藏起来，用 `mask-image` + `currentColor` 把自己的图标盖上去（颜色跟着主题走）。外加一个 `MutationObserver` 盯着 —— 切语言、切主题时行元素会被重建，标记会掉。
+- **页面**：以前要点一下才展开，现在**整页直接铺开**，并且重新排成分区卡片：页头（图标 / 标题 / 描述，右边放「重新检测账号」「清除冷却」）、状态卡片（地区切换 + 状态灯 + 汇总 + 账号使用方式）、自动化卡片、账号卡片、模型卡片。顺带修了个陈年小毛病：原来有个 `if (!open) return`，意思是**没展开就一次都不去拉状态** —— 所以你刚点开永远是空的，得傻等一轮轮询。现在挂载即拉。
 
 ### 四、顺手修的几件小事（都来自 0.1.7 真机排查）
 
-- **取密钥的超时 10 秒 → 30 秒。** 那个子进程是拿 WorkBuddy 的 Electron 二进制当
-  普通 Node 跑，冷启动第一次 spawn 实测就要 4.5 秒。碰上同时在跑 pnpm install、
-  或者杀毒软件在全盘扫描，10 秒预算直接被击穿 → 所有加密凭据被读成"未登录"，
-  还要再背 60 秒负缓存。成功结果本来就是进程级缓存，加长预算最多只付一次。
-- **补上盘符根目录。** `D:\workbuddy\`、`D:\workbuddyai\` 是真实安装位置，
-  可我们只扫 `Program Files`，一级扫描永远够不着它们。
-- **顶层 IIFE 补 `.catch()`。** 那个 IIFE 里的 `await` 一旦失败就变成 unhandled
-  rejection，在 `installFailLoud` 下同样是直接杀宿主。
-
-- **保存收益账本失败不再拖垮宿主。** 这条来自社区反馈：以前 scheduler 把「写
-  settings」的调用放在 `try` 里但**没 await** —— 而 `try/catch` 只抓得住同步抛错，
-  Promise 的 rejection 会直接漏成 unhandled rejection，在 `installFailLoud` 下
-  就是 `exit(1)`。那位朋友遇到的正是这个：打开设置页 → 读状态 → 滚动收益账本 →
-  写盘失败 → 整个 DSH 起不来。他把原因归到「写入方法名从 `set()` 改成了
-  `update()`」，那确实是当时那一次抛错的直接原因（我们 1.6.0 已经改过了），但
-  **结构上的隐患当时还在**：只要保存以任何理由失败（服务缺失、文件被锁、校验
-  不通过），宿主照样会崩。现在给持久化回调的返回值挂上 rejection 处理，同时保留
-  同步抛错的原有兜底 —— 保存失败只会记一条 warning，账本继续在内存里服务卡片，
-  绝不影响已经领到的奖励。
+- **取密钥的超时 10 秒 → 30 秒。** 那个子进程是拿 WorkBuddy 的 Electron 二进制当普通 Node 跑，冷启动第一次 spawn 实测就要 4.5 秒。碰上同时在跑 pnpm install、或者杀毒软件在全盘扫描，10 秒预算直接被击穿 → 所有加密凭据被读成"未登录"，还要再背 60 秒负缓存。成功结果本来就是进程级缓存，加长预算最多只付一次。
+- **补上盘符根目录。** `D:\workbuddy\`、`D:\workbuddyai\` 是真实安装位置，可我们只扫 `Program Files`，一级扫描永远够不着它们。
+- **顶层 IIFE 补 `.catch()`。** 那个 IIFE 里的 `await` 一旦失败就变成 unhandled rejection，在 `installFailLoud` 下同样是直接杀宿主。
+- **保存收益账本失败不再拖垮宿主。** 这条来自社区反馈：以前 scheduler 把「写 settings」的调用放在 `try` 里但**没 await** —— 而 `try/catch` 只抓得住同步抛错，Promise 的 rejection 会直接漏成 unhandled rejection，在 `installFailLoud` 下就是 `exit(1)`。那位朋友遇到的正是这个：打开设置页 → 读状态 → 滚动收益账本 → 写盘失败 → 整个 DSH 起不来。他把原因归到「写入方法名从 `set()` 改成了 `update()`」，那确实是当时那一次抛错的直接原因（我们 1.6.0 已经改过了），但**结构上的隐患当时还在**：只要保存以任何理由失败（服务缺失、文件被锁、校验不通过），宿主照样会崩。现在给持久化回调的返回值挂上 rejection 处理，同时保留同步抛错的原有兜底 —— 保存失败只会记一条 warning，账本继续在内存里服务卡片，绝不影响已经领到的奖励。
 
 ### 验证
 
 - `typecheck` / `typecheck:client` 全绿；vitest **222 用例全绿**（原 198 + 新增 24）。
-- 新增 `tests/host-compat.test.ts`：两条线的注册分支互斥且都不抛、两个 API 都没有时
-  只 warn、全部字段都标了 volatile、活引用的浅 / 深解引用、`inject` 不含互斥服务名、
-  注册槽位是 `settings.section`、0.1.7 用条目 id / 0.1.5 用 namespace、
-  整页无折叠且轮询不再依赖展开状态、左栏名称与图标注入、异步持久化失败不产生
-unhandled rejection（该用例经反向验证：还原成旧写法时它会失败）。
-- 拿**真实的 0.1.7 schemastery 3.18.4** 解析**真实的 Config**（12 个字段全部变成
-  活引用、schema 校验无异常）；再用假宿主加载真实产物 `lib/index.js` / `lib/client.js`，
-  确认 `apply()` 在 0.1.7 / 0.1.5 / 两个服务都没有 这三种情形下都不抛异常。
+- 新增 `tests/host-compat.test.ts`：两条线的注册分支互斥且都不抛、两个 API 都没有时只 warn、全部字段都标了 volatile、活引用的浅 / 深解引用、`inject` 不含互斥服务名、注册槽位是 `settings.section`、0.1.7 用条目 id / 0.1.5 用 namespace、整页无折叠且轮询不再依赖展开状态、左栏名称与图标注入、异步持久化失败不产生 unhandled rejection（该用例经反向验证：还原成旧写法时它会失败）。
+- 拿**真实的 0.1.7 schemastery 3.18.4** 解析**真实的 Config**（12 个字段全部变成活引用、schema 校验无异常）；再用假宿主加载真实产物 `lib/index.js` / `lib/client.js`，确认 `apply()` 在 0.1.7 / 0.1.5 / 两个服务都没有 这三种情形下都不抛异常。
 - `lib/` 与 `src/` 同步重建（不然从 GitHub 源码装的人拿到的还是旧产物）。
 
 ### 最后
 
-这一版由用户在本机 DSH Desktop 2.0.14（内核 0.1.7-rc.1）实测确认：
-**入口出来了、卡片显示了、名字和图标都对了。**
+这一版由用户在本机 DSH Desktop 2.0.14（内核 0.1.7-rc.1）实测确认：**入口出来了、卡片显示了、名字和图标都对了。**
 
-感谢反馈问题的朋友 —— 那个"日志戛然而止"的现象描述得非常关键，否则光看日志
-根本无从下手。
+感谢反馈问题的朋友 —— 那个"日志戛然而止"的现象描述得非常关键，否则光看日志根本无从下手。
 
 ## 1.6.1 (2026-09-24)