dsh-workbuddy-xdpool 1.4.1 → 1.6.1

package/CHANGELOG.md

@@ -4,6 +4,197 @@
 
 版本号遵循 [语义化版本](https://semver.org/lang/zh-CN/)。
 
+## 1.6.0 (2026-09-24)
+
+这一版修的都是「已装、已登录，插件却说找不到 App / 存不进去」这一类误报。
+
+### 一、WorkBuddy 装在非系统盘时找不到 App（社区反馈 + 本机复现）
+
+报错：`holds encrypted credentials but the desktop app could not provide the key`，
+但 App 明明装着并在运行。
+
+根因：Windows 只探测四个固定在**系统盘**的路径，而实际安装位置是自定义盘符 ——
+本机实测两个 App 都在非默认位置，且**国际版的文件名都不一样**：
+
+```
+D:\workbuddy\WorkBuddy.exe        国内版 5.5.3
+D:\workbuddyai\WorkBuddyAI.exe    国际版 5.6.2   ← 文件名都不同
+```
+
+修法（三层，按可靠性排序）：
+
+1. **读注册表**（最权威）——安装器自己记录的 `DisplayIcon` / `InstallLocation`，
+   不管装在哪个盘、目录叫什么、可执行文件叫什么都能找到；
+2. 环境变量 `WORKBUDDY_APP_EXECUTABLE`（用户显式指定，优先级最高）；
+3. 兜底枚举：`ProgramFiles` / `ProgramW6432` / `ProgramFiles(x86)` / `LOCALAPPDATA`，
+   **外加所有固定盘符**的 `Program Files`，再向下扫一层匹配 `workbuddy*` 目录。
+
+同时补上国际版可执行文件名 `WorkBuddyAI.exe` —— 它此前从未进过候选，
+所以哪怕路径对了也找不到。
+
+**实测验证**：注册表方案在本机正确发现两个 App，且用国内版 App 派生的密钥
+能解开国际版凭据（两个 App 共用同一个构建期密钥，`keyId` 完全匹配）。
+
+### 二、报错文案不再误导
+
+原文案暗示「去装 App」，而用户 App 就装着。现在区分两种情况，并给出真正可执行的指引：
+设置 `WORKBUDDY_APP_EXECUTABLE` 指向实际路径，并明说**重新登录无效**
+（凭据本身是好的，缺的是密钥）。
+
+### 三、读账号很慢 / 重新检测账号也报错
+
+每次读凭据都会 spawn App 并等待 10 秒超时；一旦失败，逐个凭据文件再来一遍。
+新增**失败负缓存**（60 秒）：一次失败后短期内不再重试，
+既让「扫描账号」瞬间返回，也保证装上/启动 App 后无需重启 DSH 就能恢复。
+
+### 四、「保留积分」保存报 `settings service unavailable; creditReserves was not saved`
+
+**这是我 1.5.0 引入的 bug**：校验写入了不存在的 API。
+本版 `dsh-settings` 暴露的是**按命名空间**的写入方法，没有 `set(key, value)`：
+
+```
+update(ns, patch, expectedRevision)    // 把 patch 合并进该命名空间的用户层
+replace(ns, section, expectedRevision)
+mutate(ns, ops, expectedRevision)
+```
+
+现在改用 `update(ns, { [key]: value })`。**「await + 回读校验」的理念保持不变**
+（它确实抓到了问题，只是抓错了原因）——写入后仍然回读文档比对，不一致就报错。
+
+### 测试
+
+188 → 195（新增 `app-location.test.ts` 7 例：注册表优先、override 优先、
+多盘符与文件名变体、macOS 仍走 bundle 而不碰注册表）。
+
+## 1.5.3 (2026-09-24)
+
+### 内核依赖对齐 DSH 实际版本，消除「需要 0.1.7」的歧义
+
+`devDependencies` 里十个 `@deepseek-ai/dsh-*` 包原先钉在最老的版本
+（`0.1.1-rc.2` / `0.1.2-rc.1`），而插件实际运行在 DSH Desktop 2.0.13 捆绑的
+**`0.1.5-rc.2`** 上——开发环境与运行环境不一致，正是姊妹项目踩过的那类坑
+（用旧类型构建、或反过来用新类型构建跑在旧内核上）。
+
+现在钉到 **`0.1.5-rc.2`**，与实际运行内核一致。`dsh-client-runtime` 例外：该包
+已停止发布（最后版本 `0.1.1-rc.2`），保持不动。
+
+**peerDependencies 未改**，仍是最宽的 `>=0.1.1-rc.1 <0.2.0`。实测（semver）该范围
+同时接受 `0.1.5-rc.2` 与 `0.1.7-rc.1`，比 `^0.1.5-rc.1`、`^0.1.5-0` 都广，所以
+插件本身从来没有版本不兼容——市场页面上那句「需要 DSH >=0.1.7-rc.1」是市场对
+预发布范围的判定方式所致，不是插件声明有误。
+
+内核 `0.1.7-rc.1` 目前只在 npm 的 `next` 通道（`latest` 仍是 `0.0.1-rc.1`），
+属于预发布；内核版本由 DSH Desktop 应用捆绑，需等官方发新版桌面端才能跟进。
+
+### 测试
+
+仍为 188 通过（本次只改依赖声明，无代码改动）。
+
+## 1.5.2 (2026-09-24)
+
+### 修掉测试对运行时区的依赖（发布流程在 CI 上红了）
+
+1.5.0 把签到的小时判定改成显式 `Asia/Shanghai` 之后，测试却仍在用
+`new Date(2026, 8, 7, 10, 30)` 构造时刻——那是**本机时区**的 10:30。本机在 UTC+8 时
+恰好等于北京时间 10:30，所以本地全绿；换到 UTC 的 CI 上，同一时刻变成北京时间 18:30，
+于是 `isFireHour(..., [10])` 返回 false，四个用例集体变红。
+
+**代码没问题，是测试的构造方式错了**：用一个「运行机器时区」的输入去断言一个
+「固定北京时区」的实现，结论必然随机器而变。
+
+修法：测试里所有时刻改用 `beijing(y, m, d, h, min)` 显式构造（`Date.UTC(h - 8)`），
+并新增一条用例专门钉住「同一个瞬间在任何时区下判出同一个小时」。
+
+验证：`UTC` / `America/New_York` / `Asia/Shanghai` / `Europe/London` **四个时区各跑一遍，
+均 188 通过**。
+
+（顺带修好一处漏掉的 `AUTOMATION_JOB_KINDS` import——它让「卡片与调度器任务列表一致」
+那条用例在 UTC 下失败。）
+
+## 1.5.1 (2026-09-24)
+
+### 「保留积分」改成填完点保存，并且告诉你存没存上
+
+上一版修好了写入不落盘却报成功的问题，但交互仍然不好：输入框**一失焦就自动提交**，
+你既没有明确的「保存」动作，也不知道到底有没有生效——失败了只在卡片顶上飘一行提示，很容易错过。
+
+现在：
+- 输入框只是草稿，**不再失焦自动提交**（回车或点「保存」才会写入）。
+- 「保存」按钮只在草稿与已存值不同时可用，避免误点与空提交。
+- 结果**就地显示在按钮旁边**：保存中… / 已保留 N 积分 / 保存失败，请重试。
+- 保存成功后本地立刻定格新值，不用等下一次轮询——这是「重开又不显示」观感的直接解法。
+- 输入框加了聚焦态（绿色描边），宽度从 76px 调到 84px。
+
+### 测试
+
+187 通过（本次为客户端交互改动，未新增用例）。
+
+## 1.5.0 (2026-09-24)
+
+这一版修四处实报问题，其中第一处直接决定 Mac 用户能不能用。
+
+### 一、Mac 上 WorkBuddy 5.6.2「获取不到账号」——桌面端加密了凭据
+
+现象：Mac 上 App 装着、也登录着，插件却一个账号都列不出来。
+
+根因不在路径，在**加密**。WorkBuddy 桌面端从 **5.6.0 起**把 auth 文件里的
+`accessToken` / `refreshToken` / `nickname` 从纯字符串改成了加密信封
+（`{"$wbEncrypted":1,"envelope":"…"}`，AES-256-GCM），而且 **macOS 与 Windows
+同样如此**——此前「只有 Windows 加密」的判断是错的。原来的读取代码是
+`typeof auth.accessToken === 'string'`，遇到信封对象直接判定「没有凭据」，于是
+把「已登录」误报成「未登录」。
+
+修法（`src/at-rest.ts` 新增 + `src/accounts.ts` 接入）：
+- 向**本机已安装的 App 自己**索取字段密钥：用 `ELECTRON_RUN_AS_NODE` 跑它的原生绑定
+  (`electron_browser_workbuddy_storage.loggerGet()`)，就地派生密钥。插件不内置任何密钥
+  副本，密钥只在进程内存缓存、不落盘。
+- 二进制定位改为**问 bundle 自己**：macOS 的 `CFBundleExecutable` 是 `Electron`
+  而不是 `WorkBuddy`，按 App 名拼路径永远找不到 App。候选含国际版 `WorkBuddy AI.app`，
+  并支持 App 被归入 `/Applications/子目录/`，扫到的候选先用 `CFBundleIdentifier`
+  确认身份才执行（每个 Electron 应用的二进制都叫 `Electron`，只按名字匹配有风险）。
+- **「未登录」与「登录信息读不出来」不再共用一句话**：加密但拿不到密钥时抛
+  `WorkBuddyEncryptedCredentialError`，文案指向「装 App / 用 `WORKBUDDY_APP_EXECUTABLE`
+  指定位置」，并明说**重新登录没用**——因为凭据本身是好的。
+
+### 二、签到到点不跑
+
+两个独立原因，都会让 09:00 的签到静默错过：
+- **时区**：判定用 `date.getHours()`（本机时区）。活动窗口按北京时间定义，机器时区不是
+  北京时就会错点。现改为显式 `Asia/Shanghai`（`AUTOMATION_TIME_ZONE`）。
+- **错过不补**：原来要求「当前小时正好等于配置小时」。DSH 在 09:00 没运行（或笔记本睡过去了），
+  10:00 再启动时 `10 ∉ [9]`，当天就再也不跑。现改为**补跑**：只要配置的小时已过、且该时段
+  当天未跑过，下一次 tick 立即执行。
+
+### 三、字体太淡 + 时间显示不全
+
+- 自动化面板里时间戳（`上次运行` 那列）被左侧名称以固定 `72px` 挤掉，且没有 `nowrap`，
+  长日期会被换行/截断。现给该列独立的宽度策略与 `white-space:nowrap`。
+- 一批文字用了过淡的 `#8a97b5`（`auto-hint` / `auto-total-label` / `earned-label` /
+  `auto-switch` 等）与 11px 字号，对比度不足。统一提到次级色 `#c6c9d0`、字号 12px。
+
+### 四、「保留积分」填了数值、重开还是 0
+
+根因是**写入没有校验**。`setSetting` 原来是 fire-and-forget：不 await、不问结果，
+于是「settings 服务 resolve 了但值没落盘」这种失败会**被报告成保存成功**，卡片显示已保存，
+下次读取又变回 0——用户无法判断到底有没有生效。
+
+修法：`setSetting` 改为 async，**await 写入 + 回读文档校验**，不一致就抛错，
+由路由返回失败、卡片显示出来。比较用忽略键序的深比较（`stableJsonEqual`），
+否则两个内容相同、键序不同的对象会被误判为「没落盘」。四处写入（保留积分、账号启停、
+模型选择、积分台账）全部走这条路径。
+
+### 测试
+
+新增 16 例，总数 171 → **187**：加密凭据 7 例（含「不可解密必须报 ENCRYPTED 而不是未登录」、
+「密钥不对不能返回垃圾」）、落盘校验 6 例（含「setter resolve 但没存必须抛错」）、
+签到补跑 2 例、以及既有的调度/凭据用例随语义更新。
+
+### 溯源
+
+`src/at-rest.ts` 移植自 [dingminhua/dsh-connect-workbuddy](https://github.com/dingminhua/dsh-connect-workbuddy)
+（MIT, Copyright (c) 2026 LaoDing）——该模块最先定位并修复了「5.6.0 起 macOS 也加密凭据」
+（其 issue #15 真机取证）。移植保留其全部判定逻辑，未作改动。
+
 ## 1.4.1 (2026-09-24)
 
 ### 修了：hy3 超长对话还是会弹 400