dsh-workbuddy-connect 0.7.2 → 0.7.3

package/README.en.md

@@ -62,7 +62,8 @@ Prerequisite: the WorkBuddy desktop app is installed and signed in. The plugin r
 
 | Plugin | Required DSH core | Desktop app |
 |---|---|---|
-| **0.7.2** | **supports `0.2.0-rc.2` only** (`0.2.0-rc.1` users should stay on `0.7.0`), and moves `@earendil-works/pi-ai` from a **peer to a regular dependency the plugin ships** (pinned to `0.87.1`): the plugin no longer relies on the copy at the profile's top level, so another package's older copy (e.g. `0.82.x`) cannot shadow it and load the wrong version ([#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)). **On a normal, correct install** it resolves the copy it installed; what resolves still depends on the installer and the profile layout, and the plugin warns at load if a mismatch is found. Also fixes rejected CN `Off` / `Default` requests ([#87](https://github.com/corrinehu/dsh-workbuddy-connect/issues/87)) and Windows uninstall-record encoding ([#88](https://github.com/corrinehu/dsh-workbuddy-connect/issues/88)). | desktop builds bundling the `0.2.0-rc.2` core (preview / nightly) |
+| **0.7.3** | **supports `0.2.0-rc.2` only** (`0.2.0-rc.1` users should stay on `0.7.0`), Windows registry-discovery hotfix: on non-ASCII registry output, the PowerShell 5.1 fallback introduced in `0.7.2` never bound the install root path into the script, so automatic discovery failed and the plugin wrongly showed "signed out" with the model groups gone ([#105](https://github.com/corrinehu/dsh-workbuddy-connect/issues/105) / [#106](https://github.com/corrinehu/dsh-workbuddy-connect/issues/106) / [#107](https://github.com/corrinehu/dsh-workbuddy-connect/issues/107) / [#110](https://github.com/corrinehu/dsh-workbuddy-connect/issues/110)). The fallback now uses the `& { …script… } -Root <path>` call-operator form plus a strict root-path pattern guard; the per-subprocess cap on Windows is raised to 10 seconds while the whole-discovery budget stays at 10 seconds. Verified by scoped real-PowerShell-5.1 CI on Windows Server 2022/2025 (7/7 each) and accepted on a real Windows 11 machine (international variant, non-default install path, no path override variable). | desktop builds bundling the `0.2.0-rc.2` core (preview / nightly) |
+| **0.7.2 (historical)** | **supports `0.2.0-rc.2` only** (`0.2.0-rc.1` users should stay on `0.7.0`), and moves `@earendil-works/pi-ai` from a **peer to a regular dependency the plugin ships** (pinned to `0.87.1`): the plugin no longer relies on the copy at the profile's top level, so another package's older copy (e.g. `0.82.x`) cannot shadow it and load the wrong version ([#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)). **On a normal, correct install** it resolves the copy it installed; what resolves still depends on the installer and the profile layout, and the plugin warns at load if a mismatch is found. Also fixes rejected CN `Off` / `Default` requests ([#87](https://github.com/corrinehu/dsh-workbuddy-connect/issues/87)) and Windows uninstall-record encoding ([#88](https://github.com/corrinehu/dsh-workbuddy-connect/issues/88)). **This release carries the Windows registry-fallback regression, fixed in `0.7.3` — Windows users should go straight to `0.7.3`**. | desktop builds bundling the `0.2.0-rc.2` core (preview / nightly) |
 | **0.7.1 (historical)** | supports `0.2.0-rc.2` only, and narrows the `@earendil-works/pi-ai` peer from `^0.85.1 \|\| ^0.87.1` to **`^0.87.1`**: pnpm profiles upgraded in place from `0.6.x` no longer keep a stale `pi-ai@0.85.1` that still satisfies the range and re-creates the two-generation mixing of [#69](https://github.com/corrinehu/dsh-workbuddy-connect/issues/69) ([#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74)). **The in-place upgrade from `0.6.5` is verified**: after editing `package.json` and running `pnpm install`, the plugin resolves `pi-ai@0.87.1` with no overrides; the old dual-arm behavior of `0.7.0` admitting `0.85.1` was reproduced as the control. This release still used pi-ai as a **peer**, i.e. the profile's top-level copy — a limitation fixed in `0.7.2` | desktop builds bundling the `0.2.0-rc.2` core (preview / nightly) |
 | **0.7.0 (the 0.2.0-era debut)** | **supports `0.2.0-rc.1` / `0.2.0-rc.2` only** (`0.1.5` / `0.1.6` / `0.1.7` are no longer covered — those users should stay on `0.6.5`), verified on a real `0.2.0-rc.2` host (web: loading, both CN and international catalogs, encrypted credentials, status routes all fine). This is the release that adapts to DSH `0.2.0`'s settings-service rework — `0.2.0` replaced the service with a Config-derived form facade that no longer installs sections, so earlier releases lose their settings there. **`0.7.1` drops `rc.1`** | desktop builds bundling the `0.2.0` core (preview / nightly) |
 | **0.6.0 (dual-UI adaptive)** | `0.1.5-rc.1` / `rc.2` / `rc.3`; the `0.1.6-alpha` line (incl. `alpha.1` / `alpha.2`) and `0.1.6` stable; verified against `0.1.7-alpha.1` (`0.1.7` stable is inside the range too). **Subsequent `0.1.x` prereleases (e.g. `0.1.8-alpha.x`) DO fall inside the `^0.1.7-alpha.1` arm** — the host's compatibility check resolves peer ranges with includePrerelease semantics (our earlier "not covered" claim was wrong; corrected here); prereleases crossing into `0.2.0` are the ones that need an explicit peer-range extension | `2.0.7`+ works today; desktop builds bundling `0.1.6+` will work too |
@@ -99,14 +100,14 @@ Prerequisite: the WorkBuddy desktop app is installed and signed in. The plugin r
   ```
 
 - From `0.6.0` on, the Models settings page no longer shows the non-editable WorkBuddy / WorkBuddy AI cards (consistent across both core generations); the model picker, `/model`, and chat calls are unaffected.
-- On DSH `0.2.0-rc.2`, install `0.7.2`: `dsh plugin --profile web add dsh-workbuddy-connect@0.7.2`; on `0.2.0-rc.1`, stay on `0.7.0`: `dsh plugin --profile web add dsh-workbuddy-connect@0.7.0`
+- On DSH `0.2.0-rc.2`, install `0.7.3`: `dsh plugin --profile web add dsh-workbuddy-connect@0.7.3` (Windows users should not stay on `0.7.2` — it carries the registry-discovery regression, see the `0.7.3` row above); on `0.2.0-rc.1`, stay on `0.7.0`: `dsh plugin --profile web add dsh-workbuddy-connect@0.7.0`
 - pnpm profiles upgraded in place from `0.6.x` (with a manually installed `pi-ai@0.85.1`): on `0.7.1` the peer range no longer admits `0.85.1`, so `pnpm install` moves the plugin onto the host's `0.87.1`; the temporary `overrides: {'@earendil-works/pi-ai': 0.87.1}` from [#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74) can be removed
 - **Do not upgrade the profile-level `@earendil-works/pi-ai` to 1.x**: this plugin and the `0.2.0-rc.2` DSH core both require `^0.87.1` (from `0.7.2` the plugin ships its own copy, see `dependencies` in `package.json`; `0.7.1` and earlier declared it under `peerDependencies`). Upgrading to 1.x may make the plugin load an incompatible version and leave different pi-ai versions coexisting in the install tree. **Some third-party plugin managers (e.g. `@linxin666/dsh-client-ui-plugin-manager@0.4.5`) decide "updates" from third-party packages and `dsh.engines.dsh` alone, without checking peer constraints**, so they may list `pi-ai` as updatable — do not act on that prompt (see [#86](https://github.com/corrinehu/dsh-workbuddy-connect/issues/86))
 - Before upgrading `0.7.1` → `0.7.2`, confirm the host core is `0.2.0-rc.2` (`0.7.2` supports `rc.2` only; users still on `rc.1` should stay on `0.7.0`). Now that the plugin ships pi-ai itself, any `overrides: {'@earendil-works/pi-ai': 0.87.1}` added to the profile for [#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74) / [#82](https://github.com/corrinehu/dsh-workbuddy-connect/issues/82) should **not be removed blindly** — if other plugins still rely on it to resolve the right version, dropping it may affect them; check that those plugins and DSH itself all resolve correctly before cleaning up, and keep it when unsure (it no longer conflicts with this plugin)
 - Still on DSH `0.1.5` / `0.1.6` / `0.1.7`? Stay on `0.6.5`: `dsh plugin --profile web add dsh-workbuddy-connect@0.6.5`
 - Still on DSH `0.1.2-rc.1`? Stay on `0.3.1`: `dsh plugin --profile web add dsh-workbuddy-connect@0.3.1`
 - Still on DSH `0.1.1-rc.2`? Stay on the older release: `dsh plugin --profile web add dsh-workbuddy-connect@0.2.6`
-- Pick the desktop plugin version by the **bundled core**: desktop builds bundling `0.1.x` cores (incl. the released `2.0.7`+ line) should use `dsh-workbuddy-connect@0.6.5`; desktop builds bundling the `0.2.0-rc.2` core should use `0.7.2`, and those bundling `0.2.0-rc.1` should use `0.7.0` (preview / nightly); `2.0.5` and earlier apps (bundled `0.1.2-rc.1`) should stay on `0.3.1`
+- Pick the desktop plugin version by the **bundled core**: desktop builds bundling `0.1.x` cores (incl. the released `2.0.7`+ line) should use `dsh-workbuddy-connect@0.6.5`; desktop builds bundling the `0.2.0-rc.2` core should use `0.7.3`, and those bundling `0.2.0-rc.1` should use `0.7.0` (preview / nightly); `2.0.5` and earlier apps (bundled `0.1.2-rc.1`) should stay on `0.3.1`
 
 The plugin runs under all three DSH interfaces: **Web**, **Desktop**, and **TUI**.
 
@@ -120,7 +121,7 @@ Constraints and facts:
   for Web / TUI read the standalone CLI's `dsh --version`; for the Desktop app you must confirm
   its **bundled DSH core version** (the desktop app's About page) — never substitute the standalone
   CLI's version for the desktop app's core.
-  Core `0.2.0-rc.2` -> install `0.7.2`; core `0.2.0-rc.1` -> pin `0.7.0`; cores `0.1.5`-`0.1.7` -> pin `0.6.5`;
+  Core `0.2.0-rc.2` -> install `0.7.3`; core `0.2.0-rc.1` -> pin `0.7.0`; cores `0.1.5`-`0.1.7` -> pin `0.6.5`;
   older cores follow the version table in the README at
   https://github.com/corrinehu/dsh-workbuddy-connect.
 - The interface I use is: (tell the Agent one of: Web / Desktop app / TUI)

package/README.md

@@ -72,7 +72,8 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
 
 | 插件版本 | 要求的 DSH 核心 | 桌面 App |
 |---|---|---|
-| **0.7.2** | **仅支持 `0.2.0-rc.2`**（`0.2.0-rc.1` 用户请停留在 `0.7.0`），并把 `@earendil-works/pi-ai` 从 **peer 依赖改为插件自带的普通依赖**（精确 `0.87.1`）：插件不再依赖 profile 顶层那一份 pi-ai，避免被其他包留下的旧拷贝（如 `0.82.x`）遮蔽而加载到错误版本（[#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)）。**在正常、正确的安装下**插件会优先解析自己安装的那份；解析结果仍取决于具体 installer 与 profile 布局，异常时插件会在加载时给出告警。同时修复国内版 `Off` / `Default` 档位请求被拒（[#87](https://github.com/corrinehu/dsh-workbuddy-connect/issues/87)）与 Windows 卸载记录编码（[#88](https://github.com/corrinehu/dsh-workbuddy-connect/issues/88)）。 | 内置 `0.2.0-rc.2` 内核的桌面版（预览 / nightly） |
+| **0.7.3** | **仅支持 `0.2.0-rc.2`**（`0.2.0-rc.1` 用户请停留在 `0.7.0`），Windows 注册表发现热修复：`0.7.2` 在非 ASCII 注册表输出下触发的 PowerShell 5.1 兜底从未把安装根路径绑定进脚本，导致自动发现失败、插件误判「未登录」、模型分组消失（[#105](https://github.com/corrinehu/dsh-workbuddy-connect/issues/105) / [#106](https://github.com/corrinehu/dsh-workbuddy-connect/issues/106) / [#107](https://github.com/corrinehu/dsh-workbuddy-connect/issues/107) / [#110](https://github.com/corrinehu/dsh-workbuddy-connect/issues/110)）。兜底改为 `& { …script… } -Root <path>` 调用操作符形态并加严格的根路径模式守卫；Windows 每步子进程上限放宽到 10 秒，整体发现预算仍为 10 秒。已在 Windows Server 2022/2025 真实 PowerShell 5.1 专项 CI 各 7/7 通过，并经 Windows 11 真机（国际版、非默认安装路径、未设路径覆盖变量）验收。 | 内置 `0.2.0-rc.2` 内核的桌面版（预览 / nightly） |
+| **0.7.2（历史版本）** | **仅支持 `0.2.0-rc.2`**（`0.2.0-rc.1` 用户请停留在 `0.7.0`），并把 `@earendil-works/pi-ai` 从 **peer 依赖改为插件自带的普通依赖**（精确 `0.87.1`）：插件不再依赖 profile 顶层那一份 pi-ai，避免被其他包留下的旧拷贝（如 `0.82.x`）遮蔽而加载到错误版本（[#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)）。**在正常、正确的安装下**插件会优先解析自己安装的那份；解析结果仍取决于具体 installer 与 profile 布局，异常时插件会在加载时给出告警。同时修复国内版 `Off` / `Default` 档位请求被拒（[#87](https://github.com/corrinehu/dsh-workbuddy-connect/issues/87)）与 Windows 卸载记录编码（[#88](https://github.com/corrinehu/dsh-workbuddy-connect/issues/88)）。**该版存在 Windows 注册表兜底回归，已在 `0.7.3` 修复，Windows 用户请直接使用 `0.7.3`**。 | 内置 `0.2.0-rc.2` 内核的桌面版（预览 / nightly） |
 | **0.7.1（历史版本）** | 仅支持 `0.2.0-rc.2`，并把 `@earendil-works/pi-ai` peer 从 `^0.85.1 \|\| ^0.87.1` 收窄为 **`^0.87.1`**：从 `0.6.x` 原地升级的 pnpm profile 不再因旧 `pi-ai@0.85.1` 仍在范围内而被保留、复现 [#69](https://github.com/corrinehu/dsh-workbuddy-connect/issues/69) 的两代混用（[#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74)）。**从 `0.6.5` 原地升级已实测**：编辑 `package.json` 后 `pnpm install`，插件即解析到 `pi-ai@0.87.1`，无需任何 override；同时在 `0.7.0` 上复现了双臂范围放行 `0.85.1` 的原行为作为对照。该版仍以 **peer** 方式使用 profile 顶层的 pi-ai —— 这一局限在 `0.7.2` 已修复 | 内置 `0.2.0-rc.2` 内核的桌面版（预览 / nightly） |
 | **0.7.0（0.2.0 世代首发）** | **仅支持 `0.2.0-rc.1` / `0.2.0-rc.2`**（`0.1.5` / `0.1.6` / `0.1.7` 不再支持，用户请停留在 `0.6.5`），已在 `0.2.0-rc.2` 真机实测（web 端：加载、国内版与国际版目录、加密凭据、状态路由正常）。这是适配 DSH `0.2.0` 设置服务改造的版本——`0.2.0` 把设置服务换成了 Config 表单门面，移除了旧的 `installSection` 接口，早期版本在上面会丢失设置项。**`0.7.1` 起不再支持 `rc.1`** | 内置 `0.2.0` 内核的桌面版（预览 / nightly） |
 | **0.6.0（双界面自适应）** | `0.1.5-rc.1` / `rc.2` / `rc.3`；`0.1.6-alpha` 系列（含 `alpha.1` / `alpha.2`）与 `0.1.6` 正式版；已实测 `0.1.7-alpha.1`（`0.1.7` 正式版同样在范围内）。**后续 `0.1.x` prerelease（如 `0.1.8-alpha.x`）同样落在 `^0.1.7-alpha.1` 区间内**——宿主兼容判定按 includePrerelease 语义解析 peer range（早先「不自动覆盖」的说法有误，已更正）；跨入 `0.2.0` 的 prerelease 才需要插件显式扩展 peer range | `2.0.7`+ 可直接使用；搭载 `0.1.6+` 核心的桌面版发布后同样适用 |
@@ -108,14 +109,14 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
   ```
 
 - 自 `0.6.0` 起，Models 设置页不再显示 WorkBuddy / WorkBuddy AI 的不可编辑卡片（两代核心行为一致）；模型选择器、`/model` 与对话调用不受影响。
-- DSH `0.2.0-rc.2` 的用户，安装 `0.7.2` 即可：`dsh plugin --profile web add dsh-workbuddy-connect@0.7.2`；还在 `0.2.0-rc.1` 的用户请停留在 `0.7.0`：`dsh plugin --profile web add dsh-workbuddy-connect@0.7.0`
+- DSH `0.2.0-rc.2` 的用户，安装 `0.7.3` 即可：`dsh plugin --profile web add dsh-workbuddy-connect@0.7.3`（Windows 用户请勿停留在 `0.7.2`——该版存在注册表发现回归，见上方 `0.7.3` 行）；还在 `0.2.0-rc.1` 的用户请停留在 `0.7.0`：`dsh plugin --profile web add dsh-workbuddy-connect@0.7.0`
 - 从 `0.6.x` 原地升级的 pnpm profile（曾手动装过 `pi-ai@0.85.1`）：升级到 `0.7.1` 后 peer 范围不再接受 `0.85.1`，`pnpm install` 会把插件解析到宿主同代的 `0.87.1`；此前按 [#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74) 临时加过的 `overrides: {'@earendil-works/pi-ai': 0.87.1}` 可以删掉了
 - **不要把 profile 级的 `@earendil-works/pi-ai` 升到 1.x**：本插件与 `0.2.0-rc.2` 这一代 DSH 内核都要求 `^0.87.1`（`0.7.2` 起由插件自带，见 `package.json` 的 `dependencies`；`0.7.1` 及更早为 `peerDependencies`）。升到 1.x 可能导致插件加载不兼容版本，并造成不同版本的 pi-ai 在安装树中并存。**部分第三方插件管理器（如 `@linxin666/dsh-client-ui-plugin-manager@0.4.5`）的「检查更新」只看第三方包与 `dsh.engines.dsh`，不校验 peer 约束**，因此可能把 `pi-ai` 列为「可更新」——这个提示不能照做（见 [#86](https://github.com/corrinehu/dsh-workbuddy-connect/issues/86)）
 - 从 `0.7.1` 升到 `0.7.2` 前请先确认宿主内核为 `0.2.0-rc.2`（`0.7.2` 只支持 `rc.2`，仍在 `rc.1` 的用户请停留在 `0.7.0`）。`pi-ai` 改由插件自带后，此前按 [#74](https://github.com/corrinehu/dsh-workbuddy-connect/issues/74) / [#82](https://github.com/corrinehu/dsh-workbuddy-connect/issues/82) 在 profile 里加过的 `overrides: {'@earendil-works/pi-ai': 0.87.1}` **不要盲目删除**——若其他插件仍依赖它才能解析到正确版本，删除可能让它们受影响；确认其他插件与 DSH 自身解析均正常后再考虑清理，不确定时保留即可（与本插件已不冲突）
 - 还在用 DSH `0.1.5` / `0.1.6` / `0.1.7` 的用户，请停留在 `0.6.5`：`dsh plugin --profile web add dsh-workbuddy-connect@0.6.5`
 - 还在用 DSH `0.1.2-rc.1` 的用户，请停留在 `0.3.1`：`dsh plugin --profile web add dsh-workbuddy-connect@0.3.1`
 - 还在用 DSH `0.1.1-rc.2` 的用户，请停留在 `0.2.6`：`dsh plugin --profile web add dsh-workbuddy-connect@0.2.6`
-- 桌面版按**内置核心**选择插件版本：内置 `0.1.x` 内核的桌面版（含 `2.0.7` 起的已发布正式版）用 `dsh-workbuddy-connect@0.6.5`；内置 `0.2.0-rc.2` 内核的桌面版用 `0.7.2`，内置 `0.2.0-rc.1` 内核的用 `0.7.0`（预览 / nightly）；`2.0.5` 及更早（内置 `0.1.2-rc.1`）请继续使用 `0.3.1`
+- 桌面版按**内置核心**选择插件版本：内置 `0.1.x` 内核的桌面版（含 `2.0.7` 起的已发布正式版）用 `dsh-workbuddy-connect@0.6.5`；内置 `0.2.0-rc.2` 内核的桌面版用 `0.7.3`，内置 `0.2.0-rc.1` 内核的用 `0.7.0`（预览 / nightly）；`2.0.5` 及更早（内置 `0.1.2-rc.1`）请继续使用 `0.3.1`
 
 插件在三种 DSH 界面下均可运行：**Web**、**Desktop**、**TUI**。
 
@@ -128,7 +129,7 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
 - 插件版本必须与 DSH 内核匹配。先确认内核版本——注意区分来源：Web / TUI 看独立 CLI 的
   `dsh --version`；Desktop 桌面版必须确认其**内置 DSH 核心版本**（桌面 App 的「关于」页），
   不要拿独立 CLI 的版本代替桌面 App 的内核做判断。
-  内核 `0.2.0-rc.2` → 装 `0.7.2`；内核 `0.2.0-rc.1` → 固定 `0.7.0`；内核 `0.1.5`–`0.1.7` → 固定 `0.6.5`；
+  内核 `0.2.0-rc.2` → 装 `0.7.3`；内核 `0.2.0-rc.1` → 固定 `0.7.0`；内核 `0.1.5`–`0.1.7` → 固定 `0.6.5`；
   更早内核见 https://github.com/corrinehu/dsh-workbuddy-connect README 的版本对应表。
 - 我使用的界面是：（发给 Agent 时注明 Web / Desktop 桌面版 / TUI 之一）
 - Web：执行 `dsh plugin --profile web add dsh-workbuddy-connect`（需要指定版本就加 `@版本号`）。

package/lib/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { C as WORKBUDDY_VARIANTS, O as WorkBuddyUpstreamClient, Q as resolveAppVersion, S as CN_VARIANT, a as readHostHeartbeat, b as atRestKeyProviderFor, c as WORKBUDDY_CONNECT_VERSION, l as FALLBACK_WORKBUDDY_AI_MODELS, m as WorkBuddyCredentialStore, o as workbuddyHostHeartbeatPath, r as isHeartbeatProcessAlive, u as FALLBACK_WORKBUDDY_MODELS, w as variantFor } from "./host-heartbeat-DJb8l_4O.js";
+import { C as WORKBUDDY_VARIANTS, O as WorkBuddyUpstreamClient, Q as resolveAppVersion, S as CN_VARIANT, a as readHostHeartbeat, b as atRestKeyProviderFor, c as WORKBUDDY_CONNECT_VERSION, l as FALLBACK_WORKBUDDY_AI_MODELS, m as WorkBuddyCredentialStore, o as workbuddyHostHeartbeatPath, r as isHeartbeatProcessAlive, u as FALLBACK_WORKBUDDY_MODELS, w as variantFor } from "./host-heartbeat-DpaqHdXw.js";
 import { realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 //#region src/bin.ts

package/lib/client.js

@@ -2772,7 +2772,7 @@ window.__ModuleLoader__.load({
 		};
 		//#endregion
 		//#region src/version.ts
-		const WORKBUDDY_CONNECT_VERSION = "0.7.2";
+		const WORKBUDDY_CONNECT_VERSION = "0.7.3";
 		//#endregion
 		//#region src/client/WorkBuddyConfigPage.tsx
 		/**

package/lib/{host-heartbeat-DJb8l_4O.js → host-heartbeat-DpaqHdXw.js}

@@ -2031,16 +2031,45 @@ const WINDOWS_ELECTRON_VERSION_PATTERN = /^\d+\.\d+\.\d+(?:[-+][0-9A-Za-z.-]+)?$
 * - **Output is JSON.** PowerShell does the escaping, so paths containing
 *   spaces, commas, or quotes no longer depend on column positions, and only
 *   the two values this plugin reads are collected.
+* - **The invocation wraps this script in a call-operator script block.**
+*   Windows PowerShell 5.1 joins every argument after `-Command` into one
+*   command string and parses that string as code, so a script whose text
+*   merely starts with `param` never receives the trailing `-Root` tokens —
+*   they land inside the script text, `$Root` stays empty, and every
+*   fallback query fails as exit 2/3 (#105/#106/#107). See
+*   {@link WINDOWS_POWERSHELL_QUERY_COMMAND}.
 *
 * The root is passed as a `-Root` argument, never interpolated into the
-* command text.
+* command text, and it must pass {@link WINDOWS_REGISTRY_ROOT_PATTERN}
+* before the process starts — `-Command` arguments are re-parsed as code, so
+* only provably inert path characters may ride along.
 */
 const WINDOWS_REGISTRY_RELATIVE_POWERSHELL = "System32\\WindowsPowerShell\\v1.0\\powershell.exe";
 /** Exit code meaning the root key does not exist (a normal, expected outcome). */
 const WINDOWS_POWERSHELL_ROOT_ABSENT = 2;
 /** Exit code meaning the root exists but a part of it could not be read. */
 const WINDOWS_POWERSHELL_ROOT_UNREADABLE = 3;
-const WINDOWS_POWERSHELL_QUERY_SCRIPT = [
+/**
+* The `-Command` value actually handed to `powershell.exe`: the query script
+* wrapped in a call-operator script block.
+*
+* Windows PowerShell 5.1 joins every argument that follows `-Command` into
+* one command string and runs that string as code. A bare `param(...)`
+* script therefore never binds the trailing `-Root <path>` tokens — they end
+* up inside the script text, `$Root` is empty, and the query ends as exit
+* 2/3: discovery incomplete, the app binary is never located, and at-rest
+* key resolution fails as a silent `signed-out` (#105/#106/#107, three
+* independent Windows reports on 0.7.2). The call operator makes the binding
+* explicit: the joined command becomes `& { …script… } -Root <path>`, and
+* `&` applies the named argument to the script block's `param` block — the
+* form #106 verified on a real 5.1 machine.
+*
+* Exported for the Windows-only integration spec, which replays this exact
+* text against a real `powershell.exe` 5.1 and derives the pre-fix 0.7.2
+* argv from it by removing the wrapper. `src/index.ts` does not re-export
+* it, so it is not part of the package's public API.
+*/
+const WINDOWS_POWERSHELL_QUERY_COMMAND = `& { ${[
 	"param([string]$Root)",
 	"[Console]::OutputEncoding=[Text.Encoding]::UTF8;",
 	"$ErrorActionPreference=\"Stop\";",
@@ -2054,9 +2083,53 @@ const WINDOWS_POWERSHELL_QUERY_SCRIPT = [
 	"  if ($null -ne $d -or $null -ne $i) { $out += [pscustomobject]@{ displayName=[string]$d; displayIcon=[string]$i } }",
 	"};",
 	"ConvertTo-Json -InputObject @($out) -Compress -Depth 3"
-].join(" ");
-/** One discovery subprocess's own limits; see {@link WorkBuddyAtRestKeyProviderOptions}. */
+].join(" ")} }`;
+/**
+* The only roots this tool will name on a `-Command` command line.
+*
+* `powershell.exe` re-parses everything after `-Command` as code, so a root
+* is handed over only when it is provably inert in that position: a hive
+* this file actually queries, then subkey components of plain path
+* characters — no spaces, quotes, subexpressions, or any other byte that
+* could change what the joined command does. Production roots are the fixed
+* {@link WINDOWS_REGISTRY_ROOTS}; anything else is refused before any
+* process starts, as "we could not check", never as executable text.
+*/
+const WINDOWS_REGISTRY_ROOT_PATTERN = /^HK(?:LM|CU)(?:\\[A-Za-z0-9._-]+)+$/u;
+/**
+* One discovery subprocess's own limits; see {@link WorkBuddyAtRestKeyProviderOptions}.
+*
+* Governs the macOS discovery tools (Spotlight, plutil). The Windows registry
+* readers have their own, larger limit — {@link WINDOWS_REGISTRY_STEP_TIMEOUT_MS}.
+*/
 const WORKBUDDY_DISCOVERY_STEP_TIMEOUT_MS = 3e3;
+/**
+* One Windows registry subprocess's own limit: `reg.exe` or the PowerShell
+* 5.1 fallback.
+*
+* Why larger than the macOS step limit: `reg query <root> /s` over a
+* software-dense uninstall tree takes seconds, not milliseconds. On GitHub's
+* windows-2022 and windows-2025 runner images (hundreds of installed
+* programs) the plain HKLM uninstall read exceeds 3s while HKCU finishes in
+* ~20ms; on a real user machine the PowerShell fallback itself ran
+* 135–270ms (#106). A 3s cap therefore cuts the HKLM read in half on
+* ordinary developer machines and reports the product absent when it is
+* merely slow to enumerate.
+*
+* Why this is safe to raise without touching the budget: the whole-discovery
+* budget ({@link WORKBUDDY_DISCOVERY_BUDGET_MS}, 10s) still bounds what a
+* user waits for — during a real discovery the budget abort remains the
+* effective ceiling, so this limit only decides whether a root that would
+* have finished inside the budget gets to finish, instead of being cut at 3s
+* mid-enumeration. For direct `queryUninstallRoot` callers (no outer
+* budget), this limit is the cap.
+*
+* Invariant, asserted by tests: never above the discovery budget. The
+* remaining known bound — a machine where every root is both slow *and*
+* non-ASCII, needing more than the budget in total — still ends as a safe
+* "we could not check" rather than a wrong answer.
+*/
+const WINDOWS_REGISTRY_STEP_TIMEOUT_MS = 1e4;
 const MDFIND_MAX_OUTPUT_BYTES = 1048576;
 const PLUTIL_MAX_OUTPUT_BYTES = 65536;
 /**
@@ -2174,7 +2247,7 @@ function workBuddyWindowsDiscoveryTools() {
 			"/s"
 		], {
 			maxBuffer: WINDOWS_REGISTRY_OUTPUT_MAX_BYTES,
-			timeout: WORKBUDDY_DISCOVERY_STEP_TIMEOUT_MS,
+			timeout: WINDOWS_REGISTRY_STEP_TIMEOUT_MS,
 			windowsHide: true,
 			encoding: "buffer"
 		}, (error, stdout, stderr) => {
@@ -2211,6 +2284,10 @@ function workBuddyWindowsDiscoveryTools() {
 	* three roots being absent is normal and must not fail the search.
 	*/
 	const runFallback = (root, signal) => new Promise((resolve, reject) => {
+		if (!WINDOWS_REGISTRY_ROOT_PATTERN.test(root)) {
+			reject(new DiscoveryIncompleteError("the registry root was not a plain HKLM/HKCU path this tool may query"));
+			return;
+		}
 		if (powershellPath === void 0) {
 			reject(new DiscoveryIncompleteError("SystemRoot is not configured"));
 			return;
@@ -2224,12 +2301,12 @@ function workBuddyWindowsDiscoveryTools() {
 			"-NoProfile",
 			"-NonInteractive",
 			"-Command",
-			WINDOWS_POWERSHELL_QUERY_SCRIPT,
+			WINDOWS_POWERSHELL_QUERY_COMMAND,
 			"-Root",
 			root
 		], {
 			maxBuffer: WINDOWS_REGISTRY_OUTPUT_MAX_BYTES,
-			timeout: WORKBUDDY_DISCOVERY_STEP_TIMEOUT_MS,
+			timeout: WINDOWS_REGISTRY_STEP_TIMEOUT_MS,
 			windowsHide: true,
 			encoding: "utf8"
 		}, (error, stdout) => {
@@ -3938,7 +4015,7 @@ var WorkBuddyCatalog = class {
 };
 //#endregion
 //#region src/version.ts
-const WORKBUDDY_CONNECT_VERSION = "0.7.2";
+const WORKBUDDY_CONNECT_VERSION = "0.7.3";
 //#endregion
 //#region src/host-heartbeat.ts
 /**

package/lib/index.js

@@ -1,4 +1,4 @@
-import { $ as validAppVersion, A as extractDisplayErrorMessage, B as randomSentinel, C as WORKBUDDY_VARIANTS, D as WORKBUDDY_UPDATE_PATH, F as prepareCnChatBody, G as readCliVersion, H as FALLBACK_CN_APP_VERSION, I as prepareInternationalChatBody, J as WORKBUDDY_APP_VERSION_FILENAME, K as resolveChatIdentity, L as regionOf, M as normalizeCredits, N as parseModelCatalog, O as WorkBuddyUpstreamClient, P as prepareChatBody, Q as resolveAppVersion, R as PROBE_EFFORT_CANDIDATES, S as CN_VARIANT, U as chatUserAgent, V as CN_APP_VERSION_FILENAME, W as fallbackChatIdentity, X as installedAppVersion, Y as appUserAgent, Z as readBundleVersion, _ as desktopAuthCandidatesFor, a as readHostHeartbeat, b as atRestKeyProviderFor, c as WORKBUDDY_CONNECT_VERSION, d as WorkBuddyCatalog, f as WORKBUDDY_AUTH_FILENAME, g as defaultDesktopAuthPath, h as defaultDesktopAuthCandidates, i as processStartTimeMs, j as modelWithCurrentPromotion, k as classifyUpstreamError, l as FALLBACK_WORKBUDDY_AI_MODELS, m as WorkBuddyCredentialStore, n as clearHostHeartbeat, o as workbuddyHostHeartbeatPath, p as WORKBUDDY_AUTH_FILE_ENV, q as validCliVersion, r as isHeartbeatProcessAlive, s as writeHostHeartbeat, t as WORKBUDDY_HOST_HEARTBEAT_FILENAME, u as FALLBACK_WORKBUDDY_MODELS, v as parseWorkBuddyAuth, w as variantFor, x as AI_VARIANT, y as workbuddyOwnAuthPath, z as probeModel } from "./host-heartbeat-DJb8l_4O.js";
+import { $ as validAppVersion, A as extractDisplayErrorMessage, B as randomSentinel, C as WORKBUDDY_VARIANTS, D as WORKBUDDY_UPDATE_PATH, F as prepareCnChatBody, G as readCliVersion, H as FALLBACK_CN_APP_VERSION, I as prepareInternationalChatBody, J as WORKBUDDY_APP_VERSION_FILENAME, K as resolveChatIdentity, L as regionOf, M as normalizeCredits, N as parseModelCatalog, O as WorkBuddyUpstreamClient, P as prepareChatBody, Q as resolveAppVersion, R as PROBE_EFFORT_CANDIDATES, S as CN_VARIANT, U as chatUserAgent, V as CN_APP_VERSION_FILENAME, W as fallbackChatIdentity, X as installedAppVersion, Y as appUserAgent, Z as readBundleVersion, _ as desktopAuthCandidatesFor, a as readHostHeartbeat, b as atRestKeyProviderFor, c as WORKBUDDY_CONNECT_VERSION, d as WorkBuddyCatalog, f as WORKBUDDY_AUTH_FILENAME, g as defaultDesktopAuthPath, h as defaultDesktopAuthCandidates, i as processStartTimeMs, j as modelWithCurrentPromotion, k as classifyUpstreamError, l as FALLBACK_WORKBUDDY_AI_MODELS, m as WorkBuddyCredentialStore, n as clearHostHeartbeat, o as workbuddyHostHeartbeatPath, p as WORKBUDDY_AUTH_FILE_ENV, q as validCliVersion, r as isHeartbeatProcessAlive, s as writeHostHeartbeat, t as WORKBUDDY_HOST_HEARTBEAT_FILENAME, u as FALLBACK_WORKBUDDY_MODELS, v as parseWorkBuddyAuth, w as variantFor, x as AI_VARIANT, y as workbuddyOwnAuthPath, z as probeModel } from "./host-heartbeat-DpaqHdXw.js";
 import z from "@deepseek-ai/schemastery";
 import { resolveImageAttachmentAccess, resolveRetryPolicy } from "@deepseek-ai/dsh-llm";
 import { dirname, join, resolve } from "node:path";

package/package.json

@@ -2,7 +2,7 @@
   "name": "dsh-workbuddy-connect",
   "displayName": "DSH WorkBuddy Connect",
   "description": "将 WorkBuddy 桌面 App 包含的模型自动接入 DeepSeek Harness — bring WorkBuddy desktop app models into DeepSeek Harness with zero configuration.",
-  "version": "0.7.2",
+  "version": "0.7.3",
   "author": "corrinehu",
   "keywords": [
     "dsh-plugin",