dsh-workbuddy-connect 0.7.0 → 0.7.2

package/README.en.md

@@ -20,6 +20,8 @@ Both the CN **WorkBuddy** and the international **WorkBuddy AI** apps are suppor
 
 - **Reasoning levels**: levels explicitly declared by WorkBuddy appear directly — for example, GLM-5.3 and GLM-5.3-Flash offer low / high / max. For some models that do not declare selectable levels, Web and Desktop provide a **Reasoning levels** control in the model picker for a manual check. It sends a few requests and may consume credit. Models without a check result or selectable levels continue to use WorkBuddy's default.
 
+- **Balance at a glance**: when a WorkBuddy / WorkBuddy AI model is selected, the composer shows the account's remaining credit next to the model selector (e.g. `WB.3,401 credits`, `WB AI.3,401 credits` on the international app). Credit is not polled automatically (every status read performs a real billing query): one read on mount, then refresh on demand with the ↻ beside it.
+
 - **Status and detection**: Settings → Plugins → the matching card shows the account, token validity, remaining credit, and model offers (on DSH `0.1.6+` the entry lives in the left sidebar Plugins panel — see the version table below). It also lets you refresh the model list manually and shows whether the current list came from the upstream or from the built-in fallback, and provides manual reasoning-level detection for eligible models.
 
 - **Model visibility**: both WorkBuddy and WorkBuddy AI cards (Context window tab) let you check which models appear in the model picker. Hidden lists are **saved per signed-in account**: switching accounts switches to that account's own list, switching back restores it; new accounts and newly added models are visible by default. Hiding only affects pickability — **existing chats using a hidden model keep working**.
@@ -60,7 +62,9 @@ Prerequisite: the WorkBuddy desktop app is installed and signed in. The plugin r
 
 | Plugin | Required DSH core | Desktop app |
 |---|---|---|
-| **0.7.0 (the 0.2.0 era)** | **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 | desktop builds bundling the `0.2.0` core (preview / nightly) |
+| **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.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 |
 | **0.6.5 (final release of the `0.1.x` line)** | adds `0.2.0-rc.1` on top of the `0.6.0` surface (`0.1.5` / `0.1.6` / `0.1.7` / `0.2.0-rc.1`), verified on a real `0.2.0-rc.1` host (web: loading, catalogs, encrypted credentials, chat & image round-trips all fine). Releases up to and including `0.6.4` do not carry that range and are skipped wholesale by DSH `0.2.0-rc.1` (see [#63](https://github.com/corrinehu/dsh-workbuddy-connect/issues/63)) | desktop builds bundling `0.1.x` cores (incl. the released `2.0.7`+ line); `0.2.0-rc.1` works too (verified on web; desktop not yet verified) |
 | **0.3.2 – 0.5.4** (international support since `0.5.0`) | the `0.1.5-rc.1` line only (no `0.1.6+`; see [#41](https://github.com/corrinehu/dsh-workbuddy-connect/issues/41)) | `2.0.7`+ (bundled core `0.1.5-rc.1`) |
@@ -95,13 +99,53 @@ 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.1` / `0.2.0-rc.2`, just install the latest: `dsh plugin --profile web add dsh-workbuddy-connect`
+- 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`
+- 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` core (preview / nightly) should use the latest; `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.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`
+
+The plugin runs under all three DSH interfaces: **Web**, **Desktop**, and **TUI**.
+
+**Recommended: hand the install to an Agent.** No manual commands needed — paste the brief below verbatim to your AI assistant (the built-in DSH agent, Claude Code, Codex, Cursor, …) and let it pick the right mechanism, the right version, and verify the result for your environment:
+
+```markdown
+Please install the DSH (DeepSeek Harness) plugin dsh-workbuddy-connect for me and verify it afterwards.
+
+Constraints and facts:
+- The plugin version must match the DSH core. Check the core version first — mind the source:
+  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`;
+  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)
+- Web: run `dsh plugin --profile web add dsh-workbuddy-connect` (append `@<version>` to pin).
+- TUI: run `dsh plugin --profile dsh-tui add dsh-workbuddy-connect`; that profile requires pnpm 11.
+- Desktop app: the `desktop` profile is managed exclusively by the Electron app — any
+  `dsh plugin --profile desktop ...` command is rejected by the CLI with
+  `profile "desktop" is managed exclusively by the Electron application`.
+  Preferred: guide me through the desktop app's built-in plugin manager. If going through the file
+  route instead, every step matters: (1) confirm the profile directory the desktop app actually
+  uses (default `~/.dsh/profiles/desktop`, on Windows `%USERPROFILE%\.dsh\profiles\desktop` —
+  verify against reality); (2) have me fully quit the desktop app; (3) back up `package.json` and
+  `pnpm-lock.yaml` in that directory; (4) add `"dsh-workbuddy-connect": "<version>"` to
+  dependencies; (5) install in that directory with the pnpm matching the profile (prefer the pnpm
+  bundled with the desktop app; a mismatched one may fail with store errors — switch versions per
+  the error message and retry); (6) relaunch the desktop app.
+- Verification: after restarting the interface, the model picker should show the
+  "WorkBuddy / WorkBuddy AI" groups — with only the CN or only the international app installed,
+  verify just the corresponding group. Groups and credit being visible only proves the plugin
+  loaded and the catalog and account were read; pick one model from the group and finish a short
+  conversation — a normal reply is what counts as a working integration.
+```
 
-The plugin runs under all three DSH interfaces: **Web**, **Desktop**, and **TUI**. Pick the install command that matches the profile you use.
+<details>
+<summary>Manual install (command line, Web / TUI only)</summary>
 
 ```sh
 # Web (recommended; ships prebuilt artifacts)
@@ -111,20 +155,16 @@ dsh web
 # or install the Web version from the GitHub source
 dsh plugin --profile web add github:corrinehu/dsh-workbuddy-connect
 dsh web
-```
 
-```sh
-# Desktop (the DSH Desktop app)
-dsh plugin --profile desktop add dsh-workbuddy-connect
-dsh --profile desktop
-```
-
-```sh
 # TUI (terminal UI)
 dsh plugin --profile dsh-tui add dsh-workbuddy-connect
 dsh --profile dsh-tui
 ```
 
+The Desktop app does not install via the command line: the `desktop` profile is managed exclusively by the Electron app and the CLI rejects it outright (`profile "desktop" is managed exclusively by the Electron application`). Use the desktop app's built-in plugin manager instead.
+
+</details>
+
 > **TUI users, check the version pairing**: the terminal UI package (`@deepseek-harness-tui/dsh-tui`) must be **`0.10.0-beta.5` or newer** — older versions fail at startup with `events is not iterable` when this plugin is installed. Update the shell first (via its built-in update command or a fresh install), then add this plugin; the newest release is a beta, and a stable one will work the same way.
 
 > Manual reasoning-level detection is currently available only on Web and Desktop; TUI does not provide a detection action.
@@ -135,7 +175,7 @@ After installing, switch to a WorkBuddy model in the model picker of the interfa
 
 ## CLI
 
-`dsh plugin --profile <web|desktop|dsh-tui> exec dsh-workbuddy-connect status`: sign-in state and remaining credit (`--json` for machine-readable output; `doctor` for diagnostics and `logout` for credential cleanup are also available).
+`dsh plugin --profile <web|dsh-tui> exec dsh-workbuddy-connect status`: sign-in state and remaining credit (`--json` for machine-readable output; `doctor` for diagnostics and `logout` for credential cleanup are also available). The `desktop` profile is managed exclusively by the desktop app, so the CLI (including `exec`) does not work against it.
 
 Both commands target the CN version by default; add `--provider workbuddy-ai` for the international one:
 

package/README.md

@@ -27,6 +27,8 @@
 
 - **推理档位**：WorkBuddy 明确声明的档位会直接显示，例如 GLM-5.3 和 GLM-5.3-Flash 可选 low / high / max。对于部分没有声明可选档位的模型，Web 和 Desktop 可在模型选择器中点击「推理等级」手动检测；检测会发送少量请求，可能消耗积分。未检测或没有可用档位的模型仍使用 WorkBuddy 的默认档位。
 
+- **余额速览**：选中 WorkBuddy / WorkBuddy AI 的模型时，输入框底部会在模型选择器旁显示一行当前账号的剩余积分（如 `WB.3,401（积分）`、国际版 `WB AI.3,401（积分）`）。积分不自动轮询（每次状态读取都会真实查询计费），挂载读取一次后可点击旁边的 ↻ 手动刷新。
+
 
 - **信息查看与检测**：设置 → 插件 → 对应卡片可查看账号、令牌有效期、剩余积分和模型优惠（DSH `0.1.6+` 上入口在左侧栏「插件」面板，见下方版本对应一节）；也可以手动刷新模型列表，并在卡片上看到当前列表来自上游还是内置兜底。对于可检测模型，也可以在这里手动检测推理档位。
 
@@ -70,7 +72,9 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
 
 | 插件版本 | 要求的 DSH 核心 | 桌面 App |
 |---|---|---|
-| **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.2.0` 内核的桌面版（预览 / 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)）。 | 内置 `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+` 核心的桌面版发布后同样适用 |
 | **0.6.5（`0.1.x` 线最终版）** | 在 `0.6.0` 的支持面上追加 `0.2.0-rc.1`（`0.1.5` / `0.1.6` / `0.1.7` / `0.2.0-rc.1`），已在 `0.2.0-rc.1` 真机实测（web 端：加载、目录、加密凭据、对话与图片往返正常）。已发布的 `0.6.4` 及更早版本不含该区间，在 DSH `0.2.0-rc.1` 上会被宿主整体跳过（见 [#63](https://github.com/corrinehu/dsh-workbuddy-connect/issues/63)） | 内置 `0.1.x` 内核的桌面版（含 `2.0.7` 起的已发布正式版）；`0.2.0-rc.1` 亦可（web 已实测，桌面版待实测） |
 | **0.3.2 – 0.5.4**（国际版支持自 `0.5.0`） | `0.1.5-rc.1` 系列（不支持 `0.1.6+`，见 [#41](https://github.com/corrinehu/dsh-workbuddy-connect/issues/41)） | `2.0.7`+（内置核心已跟进 `0.1.5-rc.1`） |
@@ -104,13 +108,47 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
   ```
 
 - 自 `0.6.0` 起，Models 设置页不再显示 WorkBuddy / WorkBuddy AI 的不可编辑卡片（两代核心行为一致）；模型选择器、`/model` 与对话调用不受影响。
-- DSH `0.2.0-rc.1` / `0.2.0-rc.2` 的用户，安装最新版即可：`dsh plugin --profile web add dsh-workbuddy-connect`
+- 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`
+- 从 `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` 内核的桌面版（预览 / 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.2`，内置 `0.2.0-rc.1` 内核的用 `0.7.0`（预览 / nightly）；`2.0.5` 及更早（内置 `0.1.2-rc.1`）请继续使用 `0.3.1`
+
+插件在三种 DSH 界面下均可运行：**Web**、**Desktop**、**TUI**。
+
+**推荐：把安装交给 Agent**。不用自己敲命令——把下面这段引导原样发给你的 AI 助手（DSH 内置 Agent、Claude Code、Codex、Cursor 等均可），它会按你的实际环境选对方式、装对版本并完成验证：
+
+```markdown
+请帮我安装 DSH（DeepSeek Harness）插件 dsh-workbuddy-connect，并在装完后验证。
+
+约束与信息：
+- 插件版本必须与 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`；
+  更早内核见 https://github.com/corrinehu/dsh-workbuddy-connect README 的版本对应表。
+- 我使用的界面是：（发给 Agent 时注明 Web / Desktop 桌面版 / TUI 之一）
+- Web：执行 `dsh plugin --profile web add dsh-workbuddy-connect`（需要指定版本就加 `@版本号`）。
+- TUI：执行 `dsh plugin --profile dsh-tui add dsh-workbuddy-connect`；该 profile 需用 pnpm 11 安装。
+- Desktop 桌面版：`desktop` profile 由桌面 App 独占管理，任何 `dsh plugin --profile desktop ...`
+  命令都会被 CLI 直接拒绝（报 `profile "desktop" is managed exclusively by the Electron application`）。
+  首选做法：引导我在桌面 App 内置的插件管理界面安装。若改走文件方式，步骤必须完整：
+  ① 先确认桌面 App 实际使用的 profile 目录（默认 `~/.dsh/profiles/desktop`，Windows 为
+  `%USERPROFILE%\.dsh\profiles\desktop`，以实际为准）；② 让我完全退出桌面 App；
+  ③ 备份该目录下的 `package.json` 与 `pnpm-lock.yaml`；④ 在 dependencies 中加入
+  `"dsh-workbuddy-connect": "<版本>"`；⑤ 用与该 profile 匹配的 pnpm 在该目录执行安装
+  （优先使用桌面 App 自带的 pnpm；用错版本可能报 store 相关错误，按报错提示换版本重试）；
+  ⑥ 重启桌面 App。
+- 验证：重启对应界面后，模型选择器里应出现「WorkBuddy / WorkBuddy AI」分组——只装国内版或
+  只装国际版时，只需验证对应的那一组。分组与积分可见只说明插件加载、目录与账号读取正常；
+  请再从中选一个模型完成一次简短对话，能正常回复才算接入成功。
+```
 
-插件在三种 DSH 界面下均可运行：**Web**、**Desktop**、**TUI**。根据你使用的 profile 选对应命令安装。
+<details>
+<summary>手动安装（命令行，仅 Web / TUI）</summary>
 
 ```sh
 # Web（推荐，自带预构建产物）
@@ -120,20 +158,16 @@ dsh web
 # 或从 GitHub 源码安装 Web 版
 dsh plugin --profile web add github:corrinehu/dsh-workbuddy-connect
 dsh web
-```
 
-```sh
-# Desktop（DSH Desktop 桌面版）
-dsh plugin --profile desktop add dsh-workbuddy-connect
-dsh --profile desktop
-```
-
-```sh
 # TUI（终端界面）
 dsh plugin --profile dsh-tui add dsh-workbuddy-connect
 dsh --profile dsh-tui
 ```
 
+Desktop 桌面版不走命令行：`desktop` profile 由桌面 App 独占管理，CLI 一律拒绝（`profile "desktop" is managed exclusively by the Electron application`），请在桌面 App 内置的插件管理里安装。
+
+</details>
+
 > **TUI 用户请注意版本搭配**：终端界面插件 `@deepseek-harness-tui/dsh-tui` 需要 **`0.10.0-beta.5` 及以上**（更早的版本装了本插件会启动失败，报 `events is not iterable`）。请先用 TUI 自带的更新方式把壳升到 beta.5 及以上，再安装本插件；当前最新的是 beta 版，正式版发布后同样可用。
 
 > 推理档位的手动检测入口目前仅提供给 Web 和 Desktop；TUI 不提供检测操作。
@@ -144,7 +178,7 @@ dsh --profile dsh-tui
 
 ## 命令行
 
-`dsh plugin --profile <web|desktop|dsh-tui> exec dsh-workbuddy-connect status`：登录状态与剩余积分（`--json` 输出机器可读格式；另有 `doctor` 诊断、`logout` 清理凭据）。
+`dsh plugin --profile <web|dsh-tui> exec dsh-workbuddy-connect status`：登录状态与剩余积分（`--json` 输出机器可读格式；另有 `doctor` 诊断、`logout` 清理凭据）。`desktop` profile 由桌面 App 独占管理，CLI（含 `exec`）一律不可用。
 
 默认操作国内版；加 `--provider workbuddy-ai` 操作国际版：
 

package/lib/bin.js

@@ -1,5 +1,5 @@
 #!/usr/bin/env node
-import { C as WORKBUDDY_VARIANTS, O as WorkBuddyUpstreamClient, S as CN_VARIANT, Z as resolveAppVersion, 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-d_lBAk8t.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-DJb8l_4O.js";
 import { realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 //#region src/bin.ts