dsh-workbuddy-xdpool 1.6.1 → 1.7.1

package/CHANGELOG.md

@@ -4,6 +4,291 @@
 
 版本号遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
 
+## 1.7.1 (2026-09-28)
+
+一句话：**你存进去的设置，终于会在重启后真的生效了。顺带让那些甩不掉的失效账号可以永久请出去。**
+
+这一版修的都是社区朋友报的问题（[#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 一看 —— 模式跳回「优先」，自动化显示「已关闭」，
+模型**全部打勾**。改一次、重启一次、退一次，堪称赛博西西弗斯。
+
+**最关键的线索**（也是报问题那位朋友观察得最准的地方）：**同一张卡片上，
+「今日自动化」的收益账本能正常显示**（签到 +200、猫猫旅行 +26 都在）。
+
+账本读得出来、开关却是关的 —— 说明配置**读得到**，只是**没人去用它**。
+就好比你钥匙插得进去，但没人转那一下。
+
+**为什么**：负责把配置写到「池子 / 模型目录 / 自动化」这三个地方的那个函数，
+只在**两个事件回调**里被调用：设置变更时（0.1.5）和热更新时（0.1.7）。
+
+问题就在这儿 —— 这俩都是**事件**，开机那一刻谁都不响。
+而 0.1.7 上那个 `configure({auto})` 只管登记「这个插件有个设置页」，
+**既不读值也不写值**。于是三条线全停在出厂默认值上，配置文件孤零零躺在磁盘上，
+写得一丝不苟，就是没人理它。
+
+顺带这也解释了一个「灵异现象」：为什么**退回旧版反而正常** ——
+旧版走的是另一条路（`onChange`），开机时会被触发一次。
+
+**怎么修的**：开机时老老实实调用一次，就一行。回归测试专门盯着「这行必须是
+开机就执行的独立语句」，防止以后有人手滑把它挪回回调里。
+
+### 二、自动化开关亮着「已开启」，实际一个任务都不跑
+
+**你会看到**：开关明明开着，界面也没报错，但**所有任务永远不会触发**。
+一个安静的、什么都不做的自动化。薛定谔的积分。
+
+**为什么**：一条自我强化的四段链条，每一环都在帮倒忙：
+
+1. 配置结构里把时间表写成了「可选数组」，于是**「没设置」被自动填成了空数组 `[]`** ——
+   从此「我没配」和「我故意配成空」长得一模一样；
+2. 调度器看到 `[]` 觉得「这是个有效值」，欣然采纳，**内置的默认时间表永远用不上**；
+3. 判断「该不该跑」时看到空数组，直接回一句「不跑」——**永远地**；
+4. 卡片在回写配置时**漏掉了「猫猫旅行」的时间**，还把空数组原样写了回去。
+
+于是文件被**固化**成空的，而且**你在界面上怎么点都修不好**——
+因为界面永远只会写回空数组。死循环。
+
+**怎么修的**：空数组一律当作「没设置」，回落到默认时间表
+（签到 9 点、上报 10 点、任务 11 点、连登 12 点，猫猫旅行早晚各一趟 9 点和 21 点）；
+三个地方都改（构造、应用配置、卡片回写），并把时间表抽成**两端共用的一份**——
+宿主和浏览器代码没法互相引用，写两份迟早会漂移，那种漂移还特别隐蔽。
+顺手把「猫猫旅行永远写不回去」也修了。
+
+### 三、模型选择一丢，就给你「全选」
+
+**你会看到**：本来精挑细选勾了三四只模型，某天打开一看——**全勾上了**，
+而且**真正生效的也真的变成了全部**。你的精简清单变成了自助餐。
+
+**为什么**：「没有选择」和「选择丢了」这两种情况，在代码里长得**一模一样**
+（都是 `undefined`）。而它的兜底是个**空对象**，空对象翻译过来恰好是
+**「全部启用」**。
+
+所以一旦选择丢失，系统不是「保持不变」，而是**朝最离谱的方向**——
+把你有意关掉的模型全放出来。
+
+**怎么修的**：兜底改成「**沿用现在正在生效的那份选择**」。
+丢了就丢了，至少不会变成「全开」。丢失只会原地不动，不会放飞自我。
+
+### 四、失效账号终于可以彻底请出去
+
+**这个不是 bug，是缺功能**。池子里混着国内版和国际版账号，国际版更容易触发风控。
+一旦某个号废了，它就一直赖在池子里 —— 而且**没有任何办法把它彻底弄走**。
+
+现有三条路都不行：「停用」只是让它不参与轮换（**账号还在卡片上、凭据文件还会被读取**）；
+命令行 `remove` 只对你手动导入的快照有效；`disabledAccountIds` 同样是「排除轮换」，
+不是「移除」。
+
+最要命的是：**只要你在桌面 App 里再登一次这个号，它就又回来了**。打地鼠。
+
+**怎么修的**：新增**「移出池子」**，和「暂时停用」明确分开：
+
+- **卡片**上每个账号多了个「移出池子」按钮，下面还有一块「**已移出的账号**」——
+  每条都能**恢复**。移除不是单向门，点错了能找回来；
+- **命令行**同步支持 `ignore` / `unignore` / `ignored`，`accounts` 也会列出已移出的号
+  （不然账号凭空消失，你还以为插件坏了）；
+- 被移出的账号**连凭据都不再读取**，所以它**不会在你重新登录后又偷偷溜回来**。
+
+关于「为什么不干脆把凭据文件删掉」：那个文件就是桌面 App 当前登录的凭证，
+删了会把 App 一起登出；而且下次登录它还会生成回来。属于既伤人、又没用。
+
+移出名单存在插件自己的文件里（`~/.dsh/.workbuddy-xdpool/ignored.json`），
+这样**命令行和卡片读写的是同一份**——不然会出现「卡片能改、终端改不了」的尴尬。
+
+### 五、国际版模型的「倍率」和「免费」标记回来了
+
+**你会看到**：国际版那几个模型的倍率（`x0.79` 这种）和「免费」标签不见了。
+光秃秃一行模型名，看着像没人管的弃儿。
+
+**为什么**（这个是拉了真实接口逐字段对出来的，两个毛病叠加）：
+
+1. 上游**明明发了** `tags` 字段，但我们的解析代码**从头到尾就没读它**——
+   读的时候没读，转换的时候又丢一次。所以卡片的标签逻辑**对两个平台的所有模型
+   都不可能命中**，白写了；
+2. 「免费」一直在等一个叫 `free` 的标签出现，而**两个平台从来没发过这种标签**
+   （实测标签是 `craft`、`text-to-image` 这类东西）。
+   真正的「免费」写法是 **`credits: "x0.00"`**——国际版有三只模型就是零费率，
+   它们一直免费，我们一直不知道。
+
+**怎么修的**：把 `tags` 老老实实读进来传下去；「免费」改成**看倍率是不是 0**
+（谁也不会为了 0 费率专门发个标签）；倍率是 0 的时候**不再显示「x0.00 积分」**——
+零费率的免费模型旁边挂个 0，还不如干脆说"免费"。
+
+另外给「静态兜底列表」也补上了倍率：以前上游一抽风就回退到那份没倍率的列表，
+表现就是「倍率突然全没了」，你还以为是插件坏了，其实只是网络打了个嗝。
+
+### 六、顺便修了一个让我很尴尬的事
+
+上一版我说「可以了」，结果有人（其实就是我）改完代码**只改了源码仓库，
+忘了同步到 DSH 真正加载的那个目录**。所以怎么重启都看不到新按钮——
+代码在隔壁房间好好地跑着，你在这边找。
+
+这版已经同步部署，并留了备份可以回退。
+
+### 验证
+
+- 类型检查全绿，测试 **248 项全绿**（原 222 + 新增 26）。
+- 新增的两个测试文件**逐项做了反向验证**：把修复**撤回**去，测试必须变红
+  （撤回一处 → 1 项红；撤回另一处 → 2 项红；撤回忽略过滤 → 1 项红；
+  撤回标签读取 → 3 项红）。确认这些测试不是"闭着眼睛也全绿"的装饰品。
+- 拿**真实构建产物**跑端到端：空时间表能解析出默认值、被移出的账号在
+  **凭据文件还在的情况下不会被重新扫描进来**、恢复后能回来。
+- 拿**真实的国际版接口数据**跑完整解析链，确认倍率和免费标记的实际渲染结果
+  （20 个模型有倍率、3 个正确识别为免费）。
+
+### 最后
+
+感谢 [@hmtime](https://github.com/hmtime) 提交 #17 / #18。
+报告里「配置读得到、但没被应用」和「账本能显示、开关却是关的」这两句
+几乎是直接指向了根因 —— 光看现象的话，很容易一头扎进"肯定是写入失败了"的坑里
+查半天。这样的报告质量，值得一版单独的更新日志来谢。
+
+## 1.7.0 (2026-09-25)
+
+一句话：**这一版终于能在 DSH 0.1.7 上活下来了，顺带把设置入口搬进了左栏、把页面重新排了一遍。**
+
+以前一个构建只能伺候 0.1.5 那条线，0.1.7 上是真的会出事 —— 不是"卡片不显示"这种小事，
+是整个 DSH 直接退出。现在两条线一个构建通吃。
+
+### 一、0.1.7 上一启用插件，DSH 就原地去世
+
+先说症状，因为它实在太有迷惑性了：用户装好插件、点启用、**进程直接没了**。
+
+桌面端只留下一句 `DSH Host exited (1)`。日志？日志里最后一行还是个无关紧要的
+warning，然后就**戛然而止**，一个 error 都没有。
+
+这种"日志被齐刷刷截断"的样子，其实是宿主的一个设计在作祟：DSH 装了 `installFailLoud`，
+进程里**任何**没被捕获的异常、任何没接住的 Promise rejection，都会让它当场 `exit(1)`。
+而那句真正的死因只写进 stderr —— 打包版 Windows 应用压根没有控制台，于是它就
+悄无声息地消失了。查了半天日志找不到错，别怀疑自己，它真的没写进去。
+
+那么是谁抛的？**三个坑叠在一起**，而且全在插件这边，内核无辜：
+
+**坑 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)`，
+然后拒绝打开。它不报错，它就是不开。
+
+**坑 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` 噪声清掉了。
+
+### 二、0.1.7 上保存没反应，或者说"没保存成功"
+
+0.1.7 有个硬门禁：**schema 里一个 `volatile` 字段都没标的条目，直接拒收**。
+`write()` 抛 `has no volatile fields`，`describe()` 干脆跳过它 —— 页面就是一片空白。
+我们的 Config 当时一个都没标，于是保存必炸、页面必空。
+
+还有个更阴的：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`，保存后运行中的实例立刻重读，不用重启。
+
+### 三、设置入口搬进左栏 + 页面重新排了一遍
+
+- **入口**：改注册到 `settings.section`，左栏现在多出一行，名字叫 **XD Pool**。
+- **图标**：这个槽位的注册契约只投影 `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，账本继续在内存里服务卡片，
+  绝不影响已经领到的奖励。
+
+### 验证
+
+- `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 / 两个服务都没有 这三种情形下都不抛异常。
+- `lib/` 与 `src/` 同步重建（不然从 GitHub 源码装的人拿到的还是旧产物）。
+
+### 最后
+
+这一版由用户在本机 DSH Desktop 2.0.14（内核 0.1.7-rc.1）实测确认：
+**入口出来了、卡片显示了、名字和图标都对了。**
+
+感谢反馈问题的朋友 —— 那个"日志戛然而止"的现象描述得非常关键，否则光看日志
+根本无从下手。
+
+## 1.6.1 (2026-09-24)
+
+### 同机双桌面 build：凭据按各自 keyId 解开
+
+国内 `WorkBuddy.exe` 与国际版 `WorkBuddyAI.exe` 各自独立密钥，每个加密字段的
+envelope 里带 keyId。同机双 build 时，旧 opener 假设"全局唯一一把密钥"，
+keyId 不匹配就报 `ciphertext 错误 / 找不到账号`。
+
+修法：`encryptedFieldOpener` 先预热密钥缓存，再返回同步闭包，按字段
+`envelope.keyId` 用 `atRestKeyFor` 选对应 build 的密钥；无 build 能提供该
+keyId 时报"此字段无可用密钥"而非静默空串。
+
+回归测试 +3（全仓 198）：不同 keyId 各用自身密钥解开、无 build 提供时抛错、
+错误密钥在场仍命中正确 key。
+
 ## 1.6.0 (2026-09-24)
 
 这一版修的都是「已装、已登录，插件却说找不到 App / 存不进去」这一类误报。