dsh-workbuddy-connect 0.7.3 → 0.7.5

package/README.en.md

@@ -2,9 +2,51 @@
 
 English | [中文](./README.md)
 
-Brings every model in the WorkBuddy desktop app (GLM-5.3, GLM-5.2, DeepSeek-V4-Pro, DeepSeek-V4-Flash, Kimi-K3, MiniMax-M3, Hy3, and more) straight into [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) — zero configuration in the DSH chat.
+Brings the models available in your signed-in WorkBuddy / WorkBuddy AI desktop app into [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness); the two versions each show their own model group and reuse their own account sign-in and credit.
 
-Both the CN **WorkBuddy** and the international **WorkBuddy AI** apps are supported (international support since **v0.5.0**): whichever one you have installed shows up as its own model group, and having both installed shows both, each with its own account and credit.
+## Install
+
+**Prerequisite**: the WorkBuddy (CN) or WorkBuddy AI desktop app is installed and signed in on this machine. The plugin reuses the app's sign-in state and follows account switches automatically; the two never affect each other.
+
+**Recommended: let an Agent you already have do the install** — any assistant with terminal and file access (the DSH agent, Codex, Claude Code, Cursor, …). Paste this to it verbatim:
+
+```text
+Please install and verify the DSH (DeepSeek Harness) plugin dsh-workbuddy-connect for me (project: https://github.com/corrinehu/dsh-workbuddy-connect).
+Start by reading the project README and confirming which interface I actually use (Web / Desktop / TUI) and its DSH core version — for the Desktop app, the bundled core, never the standalone CLI's version.
+Then install from the official npm package per the version mapping (0.2.0-rc.2 -> 0.7.5, rc.1 -> 0.7.0, 0.1.5-0.1.7 -> 0.6.5), preferring a locally supported non-market channel; on some Desktop distributions (the official Electron app in particular) the profile is app-managed and rules vary by distribution — check mine first, then explore its compliant install route, but never bypass its validation.
+Ask for my consent and make backups before changing any local files or configuration.
+After installing, verify the WorkBuddy group appears in the model picker and walk me through one short conversation.
+If the Desktop install still fails generation validation (e.g. the @types/retry false positive), report it honestly, reference upstream dataelement/dsh-desktop#688, and suggest switching to the standalone Web / TUI — do not modify dependency packages or bypass the check.
+```
+
+Core-to-plugin quick reference (full table in "Compatibility and release history" at the end):
+
+| DSH core | Recommended plugin |
+|---|---|
+| 0.2.0-rc.2 | 0.7.5 (npm latest) |
+| 0.2.0-rc.1 | 0.7.0 |
+| 0.1.5 – 0.1.7 | 0.6.5 |
+
+<details>
+<summary>Manual install (command line, Web / TUI only)</summary>
+
+```sh
+# Web (pin per your actual core — example: 0.2.0-rc.2 -> 0.7.5; or install from source via github:corrinehu/dsh-workbuddy-connect)
+dsh plugin --profile web add dsh-workbuddy-connect@0.7.5
+dsh web
+
+# TUI (example for a 0.1.x core; that profile needs pnpm 11, e.g. npx pnpm@11)
+dsh plugin --profile dsh-tui add dsh-workbuddy-connect@0.6.5
+dsh --profile dsh-tui
+```
+
+</details>
+
+> **TUI version pairing**: the terminal shell `@deepseek-harness-tui/dsh-tui` must be 0.10.0-beta.5 or newer — older versions fail at startup with this plugin installed (`events is not iterable`); manual reasoning-level detection exists on Web / Desktop only, not TUI.
+
+> **Desktop**: on some Desktop distributions (the official Electron app in particular) the `desktop` profile is app-managed, and the official app rejects the standalone CLI's `--profile desktop`; other distributions may follow different rules, so check yours first and do not blindly use the standalone CLI's `--profile desktop`. An Agent may probe whether your distribution offers a compliant non-market install route, but that is not guaranteed to work; never blindly edit the app-managed directory or bypass its validation.
+
+**Verify**: after restarting the interface, the model picker shows the "WorkBuddy / WorkBuddy AI" group(s) (with only one app installed, check just that group), and a model picked from the group completes one short conversation with a normal reply — that is what a successful install means.
 
 ## Features
 
@@ -12,19 +54,19 @@ Both the CN **WorkBuddy** and the international **WorkBuddy AI** apps are suppor
 
 ![WorkBuddy models in the DSH model picker](assets/1.png)
 
-- **CN and international side by side**: the CN app appears as the **WorkBuddy** group and the international one as **WorkBuddy AI**. Their models, accounts, and credit never mix. **Each group follows only its own app's sign-in**: install just the international app and only WorkBuddy AI appears; install both and both groups appear; sign out of one and that group goes away. Settings likewise shows **one card per version**, each with its own account and balance.
+- **CN and international side by side**: the CN app appears as the WorkBuddy group and the international one (WorkBuddy AI) as the WorkBuddy AI group; their models, accounts, and credit never mix. Each group follows only its own app's sign-in — install just the international app and only WorkBuddy AI appears, install both and both groups appear, sign out of one and that group goes away. Settings shows one card per version, each with its own account and balance.
 
 ![WorkBuddy AI models in the DSH model picker](assets/5.png)
 
-- **Image input**: most models accept images — paste or drop one straight into the conversation (GLM-5.3-Flash, GLM-5.2, the DeepSeek-V4 series, and more); the few text-only models (e.g. GLM-5.1) clearly say so.
+- **Image input**: most models accept images pasted or dropped straight into the conversation (GLM-5.3-Flash, GLM-5.2, the DeepSeek-V4 series, and more); the few text-only models (e.g. GLM-5.1) clearly say so.
 
-- **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.
+- **Reasoning levels**: levels explicitly declared by WorkBuddy appear directly — for example, GLM-5.3 and GLM-5.3-Flash offer low / high / max. For models without declared levels, Web and Desktop offer a manual check in the model picker (it sends a few requests and may consume credit); models without a check result or selectable levels keep using 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.
+- **Balance at a glance**: with a WorkBuddy / WorkBuddy AI model 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 is a real billing query): one read on mount, then refresh on demand with the ↻ beside it. During session switching, the controls may briefly hide until the model selection is ready, then return automatically. The refresh button remains available even when the model has no reasoning-level detection entry or the balance cannot be read.
 
-- **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.
+- **Status and detection**: Settings → Plugins → the matching card shows the account, token validity, remaining credit, and model offers; it also refreshes the model list manually, shows whether the current list came from the upstream or the built-in fallback, and runs manual reasoning-level detection for eligible models. On DSH 0.1.5 the entry lives under Settings → Plugins; on 0.1.6+ it moved to the left-sidebar Plugins panel (workbuddy-connect → View) — and the Settings → Models page shows no WorkBuddy entries on either generation, by design.
 
-- **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**.
+- **Model visibility**: the Context window tab of each card lets 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.
 
 ![Model visibility in the context-window list (DSH 0.1.6+ plugin configuration page)](assets/6.png)
 
@@ -32,15 +74,15 @@ The same UI works unchanged inside the DSH 0.1.5 settings cards:
 
 ![Model visibility in a DSH 0.1.5 settings card](assets/7.png)
 
-- **Enterprise credit**: on the CN product, enterprise accounts (non-empty `enterpriseId`) read their cycle quota from the enterprise billing endpoint, and the card shows an "enterprise quota" row with the cycle reset time.
+- **Enterprise credit**: on the CN product, enterprise accounts (non-empty `enterpriseId`) read their cycle quota from the enterprise billing endpoint, and the card shows the enterprise quota with the cycle reset time.
 
-- **Rate**: every model name carries its credits multiplier (e.g. `GLM-5.2 · x0.79`, `Hy3 · x0.00`) in both the `/model` popup and the composer's model dropdown. The rate is display-only and never affects requests.
+- **Rate**: every model name carries its credits multiplier (e.g. `GLM-5.2 · x0.79`, `Hy3 · x0.00`) in both the `/model` popup and the composer's model dropdown; the rate is display-only and never affects requests.
 
-- **Promo badges**: promo badges (`限时免费`, `夜间折扣`) ride the model name itself (e.g. `Hy4 preview · x0.00 · 限时免费`), visible wherever you pick a model; the status card also collects currently-discounted models. Per the WorkBuddy service data, synced each time DSH starts. The international version's promotions come from the service's `modelPromotions` (which carry an effective window). Once a promotion lapses its badge is withdrawn; because the service writes the discounted value into the model's own rate field, the original price cannot be reconstructed, so that model then reports "price unavailable — refresh to update" rather than repeating the discounted rate or claiming the model is free.
+- **Promo badges**: promo badges (limited-time free, night discount) ride the model name itself (e.g. `Hy4 preview · x0.00 · 限时免费`), visible wherever you pick a model, and the status card collects currently discounted models — per WorkBuddy service data, synced each time DSH starts. The international version's promotions come from the service's `modelPromotions` (with an effective window); once a promotion lapses its badge is withdrawn, and because the service writes the discounted value into the model's own rate field, the original price cannot be reconstructed — the model then reports "price unavailable — refresh to update" instead of repeating the discounted rate or claiming it is free.
 
 ![Settings card showing the plugin](assets/2.png)
 
-The expanded card has three tabs: **Status** shows the account, token validity, total credit, catalog source, and reasoning-level detection; **Context** lists each model's context window (where the international version offers a larger declared window, the "Use the largest declared context window" switch lives here — it is **on by default**, so DSH sizes context compression to the largest window the upstream declares; turn it off to follow the upstream default instead, and the preference persists across restarts); **Details** shows per-package credit and model offers. The CN and international versions each get their own card, showing their own account's information.
+The expanded card has three tabs: Status shows the account, token validity, total credit, catalog source, and reasoning-level detection; Context lists each model's context window, and the international version's "use the upstream's largest declared context window" switch lives here (on by default, so DSH sizes context compression to the largest declared window; turn it off to follow the upstream default instead, and the preference persists across restarts); Details shows per-package credit and model offers. The CN and international versions each get their own card.
 
 ![Settings card showing account and remaining credit](assets/3.png)
 
@@ -54,129 +96,9 @@ Testing also found that some models accept the `reasoning_effort` parameter whil
 
 For models without declared levels, Web and Desktop instead use user-authorized, on-demand detection: it first confirms that the upstream validates the parameter, then checks which standard levels it accepts. The check sends a few requests and may consume credit. Its result means only that the upstream currently accepts that level; it does not promise a particular change in reasoning quality, speed, or credit use.
 
-## Install
-
-Prerequisite: the WorkBuddy desktop app is installed and signed in. The plugin reuses the app's sign-in state and follows account switches automatically; the same applies to the international WorkBuddy AI app, and the two do not affect each other.
-
-**Match the plugin version to your DSH core** — from **`0.6.0`** on, one plugin version spans both core generations, removing the per-version pairing; earlier releases still pair one-to-one, and a mismatched combination fails to start DSH. **From `0.7.0` the plugin targets `0.2.0` cores only; `0.1.x` users should stay on `0.6.5`**:
-
-| Plugin | Required DSH core | Desktop app |
-|---|---|---|
-| **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 |
-| **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`) |
-| **0.3.0 – 0.3.1** | `0.1.2-rc.1` | `2.0.5` |
-| **0.2.6** | `0.1.1-rc.2` (older line) | `2.0.3` / `2.0.4` |
-
-- **`0.6.0` does not require upgrading to DSH `0.1.6` just to install WorkBuddy Connect**: the plugin adapts to whichever configuration surface the host actually provides at load time — `0.1.5` and `0.1.6+` each get their own UI, independently.
-- **DSH `0.2.0` reworked the settings service**: from `0.2.0` it is a Config-derived form facade exposing only `.volatile()` fields, with no section-installation API. The plugin adapts to what the host actually offers: on `0.1.5` / `0.1.6` both sections install as before (so `authFile` / `authFileAI` stay readable from `settings.yaml` and the TUI `/settings`), while on `0.1.7`+ / `0.2.0` it degrades to a settings-less provider — models, the picker, model visibility, and the context rows all keep working; only the "use the upstream's declared maximum context window" preference stops being persistable, and the card renders no switch it could not save.
-- **Where the cards live depends on the DSH version** — each generation has its own place:
-
-  ```text
-  DSH 0.1.5 + this plugin
-  ├─ Settings → Models
-  │   └─ no WorkBuddy rows ← unified with 0.1.6+ (only plugins ≤0.5.4 still showed those old
-  │                            configurable-provider rows)
-  ├─ Settings → Plugins
-  │   ├─ DSH WorkBuddy Connect      ✅ config card (CN)
-  │   └─ DSH WorkBuddy AI Connect   ✅ config card (international)
-  └─ chat model picker
-      └─ WorkBuddy / WorkBuddy AI groups ✅
-
-  DSH 0.1.6+ + this plugin
-  ├─ Settings → Models
-  │   └─ no WorkBuddy rows          ← intentional, consistent across both generations
-  ├─ Settings → Built-in Plugins
-  │   └─ workbuddy-connect          ← read-only inventory (runtime status), no config entry
-  ├─ main UI → Plugins → workbuddy-connect → View
-  │   ├─ DSH WorkBuddy Connect      ✅ new config entry (CN)
-  │   └─ DSH WorkBuddy AI Connect   ✅ new config entry (international)
-  └─ chat model picker
-      └─ WorkBuddy / WorkBuddy AI groups ✅
-  ```
-
-- 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.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.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**.
-
-**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.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)
-- 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.
-```
-
-<details>
-<summary>Manual install (command line, Web / TUI only)</summary>
-
-```sh
-# Web (recommended; ships prebuilt artifacts)
-dsh plugin --profile web add dsh-workbuddy-connect
-dsh web
-
-# or install the Web version from the GitHub source
-dsh plugin --profile web add github:corrinehu/dsh-workbuddy-connect
-dsh web
-
-# 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.
-
-> Note: the `dsh-tui` profile requires pnpm 11 to install packages (a different pnpm on PATH fails with `ERR_PNPM_UNEXPECTED_STORE` — use `npx pnpm@11`).
-
-After installing, switch to a WorkBuddy model in the model picker of the interface you chose. On Web and Desktop, the settings card shows the account, token validity, and remaining credit, can refresh the model list manually, and can check eligible models for reasoning levels; the CN and international versions each have their own card. On TUI, configure `authFile` in `/settings` (or `authFileAI` for the international version).
-
 ## CLI
 
-`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.
+`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 generally managed by the desktop app, so the CLI (including `exec`) does not work against it (see the Desktop note under Install).
 
 Both commands target the CN version by default; add `--provider workbuddy-ai` for the international one:
 
@@ -190,13 +112,40 @@ dsh plugin --profile web exec dsh-workbuddy-connect doctor --provider workbuddy-
 ## Known limitations
 
 - Verified on macOS with the DSH Web / Desktop / TUI profiles (as of 0.3.2 this requires `0.1.5-rc.1`+ and Node 22+; TUI requires the terminal UI package `0.10.0-beta.5` or newer — see the Install section). Windows probes Local and Roaming AppData in order; WSL first reads credentials from the mounted Windows user profile. If the Windows and Linux user names differ and Windows environment variables are not forwarded into WSL, point `WORKBUDDY_AUTH_FILE` (or `WORKBUDDY_AI_AUTH_FILE` for the international version) at the actual file.
-- **Encrypted desktop credential helper discovery**: both the CN and international versions (whose credentials are encrypted since 5.6.2) use their own verified default path and app discovery on macOS; on Windows the CN version first checks `%LOCALAPPDATA%\Programs\WorkBuddy\WorkBuddy.exe` and then the WorkBuddy uninstall registry records, while the international version has no verified default install location and checks the registry records only. Each product locates and runs only its own app identity (bundle id / registry name / executable name), so neither can pick the other's app; both apps currently happening to share one at-rest key on a machine is an upstream coincidence the plugin does not rely on — if the keys diverge, the diagnosis is reported rather than a wrong open attempted. If automatic discovery still fails, set the product's variable — `WORKBUDDY_ELECTRON_BIN` for CN, `WORKBUDDY_AI_ELECTRON_BIN` for international (separate since 0.6.4; if you previously pointed `WORKBUDDY_ELECTRON_BIN` at the international app, switch to the new variable and clear the old one) — then fully quit and restart DSH (the variable is read when the plugin is constructed); on Windows, sign out and back in first if possible (explorer caches the old environment block). Linux has no built-in auto-discovery; the card offers Agent Assist when needed, while an explicit environment path remains supported.
+- **Encrypted desktop credential helper discovery**: the helper is auto-detected on macOS and Windows; on Windows the CN app checks the default path `%LOCALAPPDATA%\Programs\WorkBuddy\WorkBuddy.exe` first and then the uninstall registry records, while the international app has no verified default path and checks the registry only. If auto-detection fails, set `WORKBUDDY_ELECTRON_BIN` (CN) or `WORKBUDDY_AI_ELECTRON_BIN` (international) to the executable explicitly, then fully quit and restart DSH for the change to take effect. Linux has no auto-discovery; an explicit environment variable is required. When WSL invokes the Windows-side helper, the plugin automatically normalizes the `ELECTRON_RUN_AS_NODE` entry in the child's `WSLENV` to a single safe flag set (carrying `/w` for forwarding, with no path translation; all other entries are preserved) — no manual `WSLENV` setup is needed. This change has passed offline regression tests; real WSL2 / Windows verification remains outstanding.
 - **The international version's model catalog comes from the app's own interface**: the service splits it by User-Agent, which is a private implementation detail that a server-side change can break. When that happens the plugin degrades to this account's last successful catalog and then to its built-in roster, showing the source (live / saved / built-in), the fetch time, and the failure reason on the card — but long-term compatibility is not guaranteed. The CN version's catalog uses the same interface as the official CLI and is unaffected.
 - **International-version environments not yet covered**: on Windows / WSL / Linux no reliable source for the international app's version has been located yet, so the saved value or the built-in default is used. On macOS, real-shim checks covered complete GPT-family replies, tool calls, and continued turns.
 - **Behaviour change with no credentials**: a version whose app was never signed in — and that left no plugin-owned copy — no longer shows a model group. The CN version used to display a built-in fallback list, but every model on it failed when selected.
 - **The enterprise credit path currently covers the CN product only**: the international enterprise billing interface is unverified, so those accounts still read through the personal endpoint pending measurement. The enterprise branch could not be tested locally (the development machine holds a personal account); it was implemented from the official app's interface contract, and reports from enterprise users are welcome.
+- **Settings entries vary with the DSH version**: on 0.1.5 / 0.1.6 the plugin installs its settings sections as before (`authFile` / `authFileAI` stay readable from `settings.yaml` and the TUI `/settings`); on 0.1.7+ / 0.2.0 the settings service no longer offers that interface, so the plugin degrades to a settings-less provider — models, the picker, model visibility, and context windows keep working; only the "use the upstream's declared maximum context window" preference stops being persistable.
 - Relies on WorkBuddy client interfaces (not a public API); the plugin may need updates as WorkBuddy changes.
 
+## Compatibility and release history
+
+The plugin version must match the DSH core — a mismatched combination fails to start DSH — and the Desktop app picks its plugin version by the bundled core. The newest npm release is not necessarily right for you: match your actual core first.
+
+| DSH core | Recommended plugin | Notes |
+|---|---|---|
+| `0.2.0-rc.2` | `0.7.5` (npm latest) | Current line; fixes disappearing composer controls and WSL helper environment forwarding. Avoid 0.7.2 with its registry regression. |
+| `0.2.0-rc.1` | `0.7.0` | 0.7.1 drops rc.1 support; stay on this version. |
+| `0.1.5` – `0.1.7` | `0.6.5` | Final release for the old cores; 0.7.0 targets 0.2.0 only. |
+| `0.1.2-rc.1` | `0.3.1` | Older line, historical maintenance only. |
+| `0.1.1-rc.2` | `0.2.6` | Older line, historical maintenance only. |
+
+Release history (full records at [releases](https://github.com/corrinehu/dsh-workbuddy-connect/releases)):
+
+- **0.7.5**: restores composer controls after session switching ([#125](https://github.com/corrinehu/dsh-workbuddy-connect/issues/125) / [#132](https://github.com/corrinehu/dsh-workbuddy-connect/issues/132)), fixes WSL helper environment forwarding ([#133](https://github.com/corrinehu/dsh-workbuddy-connect/issues/133)), and adds community projects to both READMEs.
+- **0.7.4**: Windows diagnostics and stability improvements: accurate classification of oversized registry-subprocess output, cross-platform test-assumption fixes ([#62](https://github.com/corrinehu/dsh-workbuddy-connect/issues/62)), and a reworked install section.
+- **0.7.3**: fixes Windows registry auto-discovery failing on non-default install paths ([#105](https://github.com/corrinehu/dsh-workbuddy-connect/issues/105)).
+- **0.7.2**: pi-ai becomes a plugin-bundled dependency and rejected inference-field requests are fixed ([#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)); this release carries a Windows registry regression — use 0.7.4 or a newer stable release.
+- **0.7.1**: narrows the pi-ai dependency range.
+- **0.7.0**: adapts to DSH 0.2.0's settings-service rework and drops 0.1.x support.
+- **0.6.5**: final release of the 0.1.x line.
+
+Pinned-version install example: `dsh plugin --profile web add dsh-workbuddy-connect@0.7.5`.
+
+**Do not upgrade the profile-level `@earendil-works/pi-ai` to 1.x**: this plugin and the `0.2.0-rc.2` generation of the DSH core both require `^0.87.1` (bundled by the plugin since 0.7.2), and third-party plugin managers' "updatable" prompts do not check peer constraints — do not act on them ([#86](https://github.com/corrinehu/dsh-workbuddy-connect/issues/86)); likewise, do not blindly remove a leftover `overrides: {'@earendil-works/pi-ai': '0.87.1'}` until you have confirmed nothing else depends on it.
+
 ## Disclaimer
 
 - This project is for **personal learning and research only**, driving your own WorkBuddy account on your own machine. Do not use it commercially or beyond reasonable personal use.
@@ -204,6 +153,13 @@ dsh plugin --profile web exec dsh-workbuddy-connect doctor --provider workbuddy-
 - The author is not liable for any direct or indirect loss arising from the use or misuse of this project.
 - This project is not affiliated with, endorsed by, or sponsored by Tencent, WorkBuddy, or DeepSeek. Product names are used for compatibility description only; trademarks belong to their respective owners.
 
+## Related Projects / Community Ecosystem
+
+- **[HanaAgent](https://github.com/liliMozi/openhanako)**: an independent personal AI Agent project.
+- **[hana-workbuddy-connect](https://github.com/miaoyongxu/hana-workbuddy-connect)**: a community-maintained unofficial adapter project that reuses parts of the `dsh-workbuddy-connect` implementation to bring WorkBuddy / WorkBuddy AI models to HanaAgent.
+
+Both projects are maintained independently by third parties. The compatibility, security, and usage support of `hana-workbuddy-connect` are the responsibility of its maintainer. Listing them here is not an official endorsement, nor does it imply any stability or compatibility commitment on this plugin's internal interfaces.
+
 ## Acknowledgements
 
 - [Sliverkiss/workbuddy2api](https://github.com/Sliverkiss/workbuddy2api) (MIT) — reference implementation of the WorkBuddy upstream protocol.

package/README.md

@@ -1,38 +1,72 @@
 # DSH WorkBuddy Connect
 
-
 [English](./README.en.md) | 中文
 
+将已登录的 WorkBuddy / WorkBuddy AI 桌面应用中可用的模型接入 DeepSeek Harness；两版分别显示各自的模型分组，并沿用各自的账号登录与积分。
 
-将 WorkBuddy 桌面 App 中包含的各种模型（GLM-5.3、GLM-5.2、DeepSeek-V4-Pro、DeepSeek-V4-Flash、Kimi-K3、MiniMax-M3 、Hy3等）自动接入 DeepSeek Harness，实现在 DSH 对话窗口里零配置使用。
+## 安装
 
-国内版 **WorkBuddy** 与国际版 **WorkBuddy AI** 同时支持（国际版自 **v0.5.0** 起）：装哪个 App 就出现哪个模型分组，两个都装就两组并存，各自用自己的账号与积分。
+**前置**：本机已安装并登录 WorkBuddy（国内版）或 WorkBuddy AI 桌面 App。插件直接复用 App 的登录状态，账号切换自动跟随，两版互不影响。
 
+**推荐：把安装交给本机已有的 Agent**——任何具备终端与文件操作能力的助手（DSH Agent、Codex、Claude Code、Cursor 等）都可以，把下面这段话原样发给它：
 
-## 功能
+```text
+请帮我安装并验证 DSH（DeepSeek Harness）插件 dsh-workbuddy-connect（项目地址：https://github.com/corrinehu/dsh-workbuddy-connect）：
+先阅读项目 README，确认我实际使用的界面（Web / Desktop / TUI）与 DSH 内核版本，桌面版以 App 内置核心为准，不要用独立 CLI 的版本代替；
+再按版本对应关系从 npm 正式包安装（0.2.0-rc.2→0.7.5、rc.1→0.7.0、0.1.5–0.1.7→0.6.5），优先走本机受支持的非插件市场渠道；部分 Desktop 发行版（尤其官方 Electron 版）的 profile 由 App 管理，各发行版规则未必相同，先确认我所用的发行版，再探查其合规的安装方式，但不得绕过其校验；
+任何本地文件或配置改动，先征得我同意并做好备份；
+装完后验证模型选择器里出现 WorkBuddy 分组，并陪我完成一次简短对话；
+若 Desktop 安装仍因 generation 校验失败（如 @types/retry 误报），请如实报告、参照上游 dataelement/dsh-desktop#688，并建议我改用独立的 Web / TUI，不要修改依赖包或绕过校验。
+```
 
-- **开箱即用**：安装和启用插件后，在 DSH 中直接使用，无需额外配置。
+内核与插件版本速查（完整对应表见文末「版本兼容与历史版本」）：
 
+| DSH 内核 | 推荐插件版 |
+|---|---|
+| 0.2.0-rc.2 | 0.7.5（npm latest） |
+| 0.2.0-rc.1 | 0.7.0 |
+| 0.1.5 – 0.1.7 | 0.6.5 |
 
-![WorkBuddy 模型出现在 DSH 模型选择器中](assets/1.png)
+<details>
+<summary>手动安装（命令行，仅 Web / TUI）</summary>
 
+```sh
+# Web（按实际内核固定版本，示例为 0.2.0-rc.2 → 0.7.5；也可用 github:corrinehu/dsh-workbuddy-connect 从源码安装）
+dsh plugin --profile web add dsh-workbuddy-connect@0.7.5
+dsh web
 
-- **国内版与国际版并存**：国内版显示为「WorkBuddy」分组，国际版（WorkBuddy AI）显示为「WorkBuddy AI」分组。两版的模型、账号和积分互不混用。**各自只看自己那版 App 的登录状态**：只装国际版就只出现「WorkBuddy AI」，两版都装就两组都在，退出其中一版则对应分组消失。设置里也是**两张卡片**，分别展示各自的账号与余额。
+# TUI（示例为 0.1.x 内核；该 profile 需用 pnpm 11 安装，如 npx pnpm@11）
+dsh plugin --profile dsh-tui add dsh-workbuddy-connect@0.6.5
+dsh --profile dsh-tui
+```
 
-![WorkBuddy AI 模型出现在 DSH 模型选择器中](assets/5.png)
+</details>
 
+> **TUI 版本搭配**：终端壳 `@deepseek-harness-tui/dsh-tui` 需 0.10.0-beta.5 及以上，更早版本装本插件会启动失败（`events is not iterable`）；推理档位的手动检测仅 Web / Desktop 提供，TUI 没有。
 
-- **图片输入**：大部分模型支持发图，在对话里直接粘贴或拖入图片即可（GLM-5.3-Flash、GLM-5.2、DeepSeek-V4 系列等）；少数只支持文字的模型（如 GLM-5.1）会明确提示不支持。
+> **Desktop**：部分 Desktop 发行版（尤其官方 Electron 版）的 `desktop` profile 由 App 管理，官方版会直接拒绝独立 CLI 的 `--profile desktop`；其他发行版规则未必相同，请先检查你所用的发行版，不要盲用独立 CLI 的 `--profile desktop`。可以让 Agent 探查是否有合规的非市场安装路径，但不保证可行；切勿盲改 App 管理的目录或绕过其校验。
 
+**验证**：重启对应界面后，模型选择器出现「WorkBuddy / WorkBuddy AI」分组（只装一版就只验对应一组），并从分组里选一个模型完成一次简短对话、能正常回复，才算安装成功。
 
-- **推理档位**：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 中直接使用，无需额外配置。
 
+![WorkBuddy 模型出现在 DSH 模型选择器中](assets/1.png)
 
-- **信息查看与检测**：设置 → 插件 → 对应卡片可查看账号、令牌有效期、剩余积分和模型优惠（DSH `0.1.6+` 上入口在左侧栏「插件」面板，见下方版本对应一节）；也可以手动刷新模型列表，并在卡片上看到当前列表来自上游还是内置兜底。对于可检测模型，也可以在这里手动检测推理档位。
+- **国内版与国际版并存**：国内版显示为「WorkBuddy」分组，国际版（WorkBuddy AI）显示为「WorkBuddy AI」分组，两版的模型、账号和积分互不混用。各自只跟随对应 App 的登录状态：只装国际版就只出现 WorkBuddy AI，两版都装则两组并存，退出一版则对应分组消失。设置里两张卡片分别展示各自账号与余额。
 
-- **模型显隐**：WorkBuddy 与 WorkBuddy AI 都可以在对应卡片的「上下文窗口」标签里勾选要在模型选择器中显示的模型。隐藏配置**按登录账号分别保存**：切换账号自动切换各自的配置，切回后恢复；新账号和新上架的模型默认显示。隐藏只影响选择器里的可选性，**正在使用该模型的已有会话不受影响**。
+![WorkBuddy AI 模型出现在 DSH 模型选择器中](assets/5.png)
+
+- **图片输入**：大部分模型支持在对话里直接粘贴或拖入图片（GLM-5.3-Flash、GLM-5.2、DeepSeek-V4 系列等）；少数纯文字模型（如 GLM-5.1）会明确提示不支持。
+
+- **推理档位**：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.5 的入口在「设置 → 插件」，0.1.6+ 移到主界面左侧栏「插件」面板（workbuddy-connect → 查看）；「设置 → 模型」页两代都不显示 WorkBuddy 条目，属有意设计。
+
+- **模型显隐**：两张卡片的「上下文窗口」标签里可勾选要在模型选择器中显示的模型。隐藏配置按登录账号分别保存：切换账号自动切换各自配置，切回后恢复；新账号和新上架模型默认显示。隐藏只影响选择器中的可选性，正在使用该模型的已有会话不受影响。
 
 ![上下文窗口列表里的模型显隐（DSH 0.1.6+ 插件配置页）](assets/6.png)
 
@@ -40,16 +74,15 @@
 
 ![DSH 0.1.5 设置卡片中的模型显隐](assets/7.png)
 
-- **企业账号积分**：国内版企业账号（`enterpriseId` 非空）走企业专用计费接口读取周期额度，卡片显示「企业额度」与周期重置时间。
-
-- **费率比例**：模型选择列表里每个模型名后直接显示积分倍率（如 `GLM-5.2 · x0.79`、`Hy3 · x0.00`），`/model` 弹窗与输入框的模型下拉都能看到。倍率只是显示，不影响实际请求。
+- **企业账号积分**：国内版企业账号（`enterpriseId` 非空）走企业计费接口读取周期额度，卡片显示「企业额度」与周期重置时间。
 
+- **费率比例**：每个模型名后直接显示积分倍率（如 `GLM-5.2 · x0.79`、`Hy3 · x0.00`），`/model` 弹窗与输入框的模型下拉都能看到；倍率仅用于显示，不影响实际请求。
 
-- **徽章展示**：促销徽章（限时免费、夜间折扣）直接跟在模型名后面（如 `Hy4 preview · x0.00 · 限时免费`），选模型时一眼可见；设置卡片里也会汇总当前有优惠的模型。以 WorkBuddy 服务端的数据为准，每次启动 DSH 时同步。国际版的促销来自服务端的 `modelPromotions`（含生效时段）：促销过期后徽章会撤销；由于服务端把折后价直接写在模型的倍率字段里，原价无法还原，此时该模型的倍率会显示为「价格未知 — 刷新后更新」，而不是继续显示折扣价或「免费」。
+- **徽章展示**：促销徽章（限时免费、夜间折扣）直接跟在模型名后（如 `Hy4 preview · x0.00 · 限时免费`），设置卡片会汇总当前有优惠的模型，数据以 WorkBuddy 服务端为准、每次启动 DSH 时同步。国际版促销来自服务端 `modelPromotions`（含生效时段），过期后徽章自动撤销；由于服务端把折后价直接写进模型的倍率字段，原价无法还原，此时该模型倍率显示为「价格未知 — 刷新后更新」，而不是继续显示折扣价或「免费」。
 
 ![设置卡片显示插件](assets/2.png)
 
-卡片展开后分为「状态 / 上下文 / 明细」三个标签：状态页展示账号、令牌有效期、合计积分、模型列表来源与推理档位检测；上下文页列出各模型的上下文窗口。国际版在上游声明了更大可选窗口时，可在这里切换「使用上游声明的最大上下文窗口」；该开关**默认开启**，DSH 会按上游声明的最大窗口安排上下文压缩；想改用上游的默认窗口就在这里关掉，偏好会持久化，重启后保持。明细页展示各套餐余量与模型优惠。国内版与国际版各有一张自己的卡片，各显示自己账号的信息。
+卡片展开后分「状态 / 上下文 / 明细」三个标签：状态页展示账号、令牌有效期、合计积分、模型列表来源与推理档位检测；上下文页列出各模型上下文窗口，国际版可在这里关闭「使用上游声明的最大上下文窗口」（默认开启，DSH 按上游最大窗口安排上下文压缩；关闭后改用上游默认窗口，偏好持久化）；明细页展示各套餐余量与模型优惠。国内版与国际版各有一张自己的卡片。
 
 ![设置卡片显示账号与剩余积分](assets/3.png)
 
@@ -64,122 +97,9 @@ WorkBuddy 中模型的推理档位信息目前分散在上游接口与客户端
 
 因此，对于没有声明档位的模型，Web 和 Desktop 采用用户主动授权触发、动态获取档位的方式：先确认上游会校验该参数，再逐项确认哪些规范档位被接受。检测会发送少量请求，可能消耗积分；结果只表示当前上游接受该档位，不承诺它一定改变推理效果、速度或积分消耗。
 
-## 安装
-
-前置：已安装并登录 WorkBuddy 桌面 App。插件复用 App 的登录状态，账号切换自动跟随；装了国际版 WorkBuddy AI 的同样适用，两版互不影响。
-
-**版本对应（重要）**：自 **`0.6.0`** 起，同一个插件版本横跨两代 DSH 核心，安装时无需再逐版本对照；更早的已发布版本仍与核心一一对应，不可混用——不匹配的组合会导致 DSH 启动失败。**自 `0.7.0` 起插件仅面向 `0.2.0` 内核，`0.1.x` 用户请停留在 `0.6.5`**：
-
-| 插件版本 | 要求的 DSH 核心 | 桌面 App |
-|---|---|---|
-| **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+` 核心的桌面版发布后同样适用 |
-| **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`） |
-| **0.3.0 – 0.3.1** | `0.1.2-rc.1` | `2.0.5` |
-| **0.2.6** | `0.1.1-rc.2`（旧线） | `2.0.3` / `2.0.4` |
-
-- **计划中的 `0.6.0` 不要求为了安装 WorkBuddy Connect 强制升级到 DSH `0.1.6`**：插件在加载时按宿主实际提供的配置入口自适应，`0.1.5` 与 `0.1.6+` 各自走各自的界面，互不干扰。
-- **DSH `0.2.0` 的设置服务改造**：`0.2.0` 起设置服务改为 Config 派生的表单门面（只暴露 `.volatile()` 字段），不再提供安装设置分区的接口。插件按宿主实际能力自适应：在 `0.1.5` / `0.1.6` 上照旧安装两个分区（`authFile` / `authFileAI` 等仍可从 `settings.yaml` 与 TUI `/settings` 读写），在 `0.1.7`+ / `0.2.0` 上降级为无设置项的 provider——模型、选择器、模型显隐与上下文窗口照常工作，只是「使用上游声明的最大上下文窗口」这一偏好不再可持久化，卡片也不会渲染无法保存的开关。
-- **配置入口随 DSH 版本不同**，两代各就各位：
-
-  ```text
-  DSH 0.1.5 + 本插件
-  ├─ 设置 → 模型
-  │   └─ 不显示 WorkBuddy 两行 ← 与 0.1.6+ 统一（≤0.5.4 旧版插件才显示那两行旧 configurable-provider 条目）
-  ├─ 设置 → 插件
-  │   ├─ DSH WorkBuddy Connect      ✅ 配置卡片（国内版）
-  │   └─ DSH WorkBuddy AI Connect   ✅ 配置卡片（国际版）
-  └─ 聊天模型选择器
-      └─ WorkBuddy / WorkBuddy AI 分组 ✅
-
-  DSH 0.1.6+ + 本插件
-  ├─ 设置 → 模型
-  │   └─ 不显示 WorkBuddy 两行      ← 有意如此，两代行为统一
-  ├─ 设置 → 内置插件
-  │   └─ workbuddy-connect          ← 只读清单（运行状态），无配置入口，别找错地方
-  ├─ 主界面 → 插件 → workbuddy-connect → 查看
-  │   ├─ DSH WorkBuddy Connect      ✅ 新配置入口（国内版）
-  │   └─ DSH WorkBuddy AI Connect   ✅ 新配置入口（国际版）
-  └─ 聊天模型选择器
-      └─ WorkBuddy / WorkBuddy AI 分组 ✅
-  ```
-
-- 自 `0.6.0` 起，Models 设置页不再显示 WorkBuddy / WorkBuddy AI 的不可编辑卡片（两代核心行为一致）；模型选择器、`/model` 与对话调用不受影响。
-- 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.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**。
-
-**推荐：把安装交给 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.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`（需要指定版本就加 `@版本号`）。
-- 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」分组——只装国内版或
-  只装国际版时，只需验证对应的那一组。分组与积分可见只说明插件加载、目录与账号读取正常；
-  请再从中选一个模型完成一次简短对话，能正常回复才算接入成功。
-```
-
-<details>
-<summary>手动安装（命令行，仅 Web / TUI）</summary>
-
-```sh
-# Web（推荐，自带预构建产物）
-dsh plugin --profile web add dsh-workbuddy-connect
-dsh web
-
-# 或从 GitHub 源码安装 Web 版
-dsh plugin --profile web add github:corrinehu/dsh-workbuddy-connect
-dsh web
-
-# 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 不提供检测操作。
-
-> 提示：`dsh-tui` profile 需用 pnpm 11 安装（PATH 里是其他版本会报 `ERR_PNPM_UNEXPECTED_STORE`，用 `npx pnpm@11` 即可）。
-
-安装后，在对应界面的模型选择器里切换到 WorkBuddy 模型即可使用。Web 和 Desktop 下，设置卡片可查看账号信息、令牌有效期与剩余积分，手动刷新模型列表，并手动检测符合条件模型的推理档位；国内版与国际版各有自己的卡片。TUI 下可在 `/settings` 里配置 `authFile`（国际版为 `authFileAI`）。
-
 ## 命令行
 
-`dsh plugin --profile <web|dsh-tui> exec dsh-workbuddy-connect status`：登录状态与剩余积分（`--json` 输出机器可读格式；另有 `doctor` 诊断、`logout` 清理凭据）。`desktop` profile 由桌面 App 独占管理，CLI（含 `exec`）一律不可用。
+`dsh plugin --profile <web|dsh-tui> exec dsh-workbuddy-connect status`：登录状态与剩余积分（`--json` 输出机器可读格式；另有 `doctor` 诊断、`logout` 清理凭据）。`desktop` profile 一般由桌面 App 管理，CLI（含 `exec`）对其不可用（见安装章节的 Desktop 说明）。
 
 默认操作国内版；加 `--provider workbuddy-ai` 操作国际版：
 
@@ -193,13 +113,39 @@ dsh plugin --profile web exec dsh-workbuddy-connect doctor --provider workbuddy-
 ## 已知限制
 
 - 在 macOS 的 DSH Web / Desktop / TUI 下验证通过（0.3.2 起要求 `0.1.5-rc.1`+、Node 22+；TUI 需终端界面插件 `0.10.0-beta.5` 及以上，见安装章节说明）。Windows 会依次探测 Local 与 Roaming AppData；WSL 会优先从挂载的 Windows 用户目录读取登录凭据。若 Windows 与 Linux 用户名不同且 Windows 环境变量未传入 WSL，请通过 `WORKBUDDY_AUTH_FILE`（国际版为 `WORKBUDDY_AI_AUTH_FILE`）指定实际位置。
-- **加密桌面凭据的解密程序定位**：国内版与国际版（WorkBuddy AI 的凭据自 5.6.2 起同样加密）在 macOS 使用各自的默认路径与 App 发现；Windows 上国内版先检查 `%LOCALAPPDATA%\Programs\WorkBuddy\WorkBuddy.exe` 再查卸载注册表记录，国际版没有已验证的默认安装位置、仅查注册表记录。两个产品只按各自的 App 身份（bundle id / 注册表名 / 可执行文件名）定位与执行解密程序，不会互相误选；同机两个 App 当前恰好共用同一把静态保护密钥，这属于上游实现的巧合，插件不依赖它，密钥分叉后会如实报诊断而不是误读。若自动定位仍不可用，可按产品设置环境变量：国内版 `WORKBUDDY_ELECTRON_BIN`、国际版 `WORKBUDDY_AI_ELECTRON_BIN`（两变量自 0.6.4 起分离；此前把 `WORKBUDDY_ELECTRON_BIN` 指向过国际版 App 的用户请改用新变量并清理旧值），设置后需完全退出并重启 DSH（插件在构造时读取该变量）；Windows 上建议注销重登后再启动（explorer 会缓存旧的环境块）。Linux 没有内置自动定位；失败时卡片提供 Agent Assist，显式环境变量仍可用。
+- **加密桌面凭据的解密程序定位**：解密程序在 macOS 与 Windows 上会自动探测；Windows 上国内版先查默认路径 `%LOCALAPPDATA%\Programs\WorkBuddy\WorkBuddy.exe`，再查卸载注册表记录，国际版没有已验证的默认路径、仅查注册表。自动探测失败时，可用 `WORKBUDDY_ELECTRON_BIN`（国内版）或 `WORKBUDDY_AI_ELECTRON_BIN`（国际版）显式指定可执行文件，设置后需完全退出并重启 DSH 才生效。Linux 无法自动发现，需显式指定。WSL 下调用 Windows 侧解密程序时，插件会自动把子进程 `WSLENV` 中的 `ELECTRON_RUN_AS_NODE` 条目规范化为单一安全旗标（含 `/w` 转发、不做路径转换，其余条目原样保留），无需手动设置。此改动已通过离线回归测试，尚未完成 WSL2 / Windows 真机验证。
 - **国际版的模型目录来自 App 界面接口**：服务端按 User-Agent 分流下发，属私有实现，上游改动可能使其失效。届时插件按「本账号上次成功目录 → 内置目录」降级，并在卡片上标明来源（实时 / 已保存 / 内置）、更新时间与失败原因，但不能保证长期兼容。国内版目录走官方 CLI 同款接口，不受此影响。
 - **国际版仍未覆盖的环境**：Windows / WSL / Linux 下国际版 App 的版本读取尚未找到可靠来源，会退回最近保存的版本或内置值。macOS 上已通过真实 shim 验证 GPT 系完整回复、工具调用与续轮。
 - **无凭据时的行为变化**：某版 App 从未登录、也没留下插件自留副本时，该版模型分组不再显示。此前国内版会显示一份内置兜底列表，但那些模型选了必然报错。
 - **企业账号积分目前仅覆盖国内版**：国际版企业账号的计费接口尚未验证，仍按个人版接口读取；待有实测结论后再扩展。企业账号分支在本机无法自测（开发机为个人账号），依据官方 App 的接口契约实现，欢迎企业账号用户反馈实测结果。
+- **设置入口随 DSH 版本而异**：0.1.5 / 0.1.6 上插件照常安装 `authFile` / `authFileAI` 等设置分区（`settings.yaml` 与 TUI `/settings` 均可读写）；0.1.7+ / 0.2.0 的设置服务不再提供该接口，插件降级为无设置项的 provider——模型、选择器、模型显隐与上下文窗口照常工作，只是「使用上游声明的最大上下文窗口」这一偏好不再可持久化。
 - 依赖 WorkBuddy 客户端接口（非官方开放 API），WorkBuddy 更新后插件可能需要随之调整。
 
+## 版本兼容与历史版本
+
+插件版本必须与 DSH 内核匹配，不匹配的组合会导致 DSH 启动失败；桌面版按其内置核心选择插件版本。npm 上的最新版不一定适合你，以实际内核的匹配关系为准：
+
+| DSH 内核 | 推荐插件版 | 注意事项 |
+|---|---|---|
+| `0.2.0-rc.2` | `0.7.5`（npm latest） | 当前最新线；修复输入框组件消失与 WSL helper 环境转发，勿停留在有注册表回归的 0.7.2。 |
+| `0.2.0-rc.1` | `0.7.0` | 0.7.1 起不再支持 rc.1，请停留本版。 |
+| `0.1.5` – `0.1.7` | `0.6.5` | 旧内核最终版；0.7.0 起仅面向 0.2.0。 |
+| `0.1.2-rc.1` | `0.3.1` | 更早旧线，仅历史维护。 |
+| `0.1.1-rc.2` | `0.2.6` | 更早旧线，仅历史维护。 |
+
+历次更新（完整记录见 [releases](https://github.com/corrinehu/dsh-workbuddy-connect/releases)）：
+
+- **0.7.4**：Windows 诊断与稳定性改进：注册表子进程输出超限准确分类、跨平台测试假设修正（[#62](https://github.com/corrinehu/dsh-workbuddy-connect/issues/62)），安装说明重排。
+- **0.7.3**：修复 Windows 非默认安装路径下注册表自动发现失败（[#105](https://github.com/corrinehu/dsh-workbuddy-connect/issues/105)）。
+- **0.7.2**：pi-ai 改为插件自带依赖，并修复推理字段请求被拒（[#92](https://github.com/corrinehu/dsh-workbuddy-connect/issues/92)）；该版存在 Windows 注册表回归，请使用 0.7.4 或更新的正式版本。
+- **0.7.1**：收窄 pi-ai 依赖范围。
+- **0.7.0**：适配 DSH 0.2.0 的设置服务改造，不再支持 0.1.x。
+- **0.6.5**：0.1.x 线最终版本。
+
+固定版本安装示例：`dsh plugin --profile web add dsh-workbuddy-connect@0.7.5`。
+
+**不要把 profile 级的 `@earendil-works/pi-ai` 升到 1.x**：本插件与 `0.2.0-rc.2` 这一代内核都要求 `^0.87.1`（0.7.2 起由插件自带），第三方插件管理器的「可更新」提示不校验 peer 约束、不能照做（[#86](https://github.com/corrinehu/dsh-workbuddy-connect/issues/86)）；为此历史遗留的 `overrides: {'@earendil-works/pi-ai': '0.87.1'}` 在确认其他插件不依赖前也不要盲目移除。
+
 ## 免责声明
 
 - 本项目**仅供个人学习和研究使用**，仅驱动使用者自己的 WorkBuddy 账号在本机调用，请勿用于商业用途或超出个人合理使用的场景。
@@ -207,6 +153,13 @@ dsh plugin --profile web exec dsh-workbuddy-connect doctor --provider workbuddy-
 - 本项目作者不对任何因使用或滥用本项目产生的直接或间接损失负责。
 - 本项目与腾讯、WorkBuddy、DeepSeek 均无关联，未获其授权或认可；文中出现的名称仅用于描述兼容关系，其商标权利归各自所有。
 
+## 相关项目 / 社区生态
+
+- **[HanaAgent](https://github.com/liliMozi/openhanako)**：独立的个人 AI Agent 项目。
+- **[hana-workbuddy-connect](https://github.com/miaoyongxu/hana-workbuddy-connect)**：社区维护的非官方适配项目，复用 `dsh-workbuddy-connect` 的部分实现，为 HanaAgent 接入 WorkBuddy / WorkBuddy AI 模型。
+
+以上项目均由第三方独立维护。其中，`hana-workbuddy-connect` 的兼容性、安全性及使用支持由其维护者负责。收录不代表官方背书，也不意味着本插件对内部接口提供稳定性或兼容性承诺。
+
 ## 致谢
 
 - [Sliverkiss/workbuddy2api](https://github.com/Sliverkiss/workbuddy2api)（MIT）— WorkBuddy 上游协议的参照实现。

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-DpaqHdXw.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-CvtbpuQi.js";
 import { realpathSync } from "node:fs";
 import { fileURLToPath } from "node:url";
 //#region src/bin.ts

package/lib/client.js

@@ -1746,14 +1746,14 @@ window.__ModuleLoader__.load({
 			const subscribe = (0, react.useCallback)((listener) => directory.subscribe(listener), [directory]);
 			const snapshot = (0, react.useCallback)(() => directory.getSnapshot(), [directory]);
 			const selection = (0, react.useSyncExternalStore)(subscribe, snapshot, snapshot).current;
-			const card = selection === void 0 ? void 0 : cardVariantFor(selection.provider);
-			const key = card === void 0 || selection === void 0 ? void 0 : `${card.id}:${selection.model}`;
-			return card === void 0 || selection === void 0 || key === void 0 ? null : /* @__PURE__ */ (0, react_jsx_runtime.jsx)(ModelProbe, {
+			if (selection == null) return null;
+			const card = cardVariantFor(selection.provider);
+			return card === void 0 ? null : /* @__PURE__ */ (0, react_jsx_runtime.jsx)(ModelProbe, {
 				model: selection.model,
 				card,
 				label: useLabel(t),
 				t
-			}, key);
+			}, `${card.id}:${selection.model}`);
 		}
 		function ModelProbe({ model, card, label, t }) {
 			const [status, setStatus] = (0, react.useState)();
@@ -2772,7 +2772,7 @@ window.__ModuleLoader__.load({
 		};
 		//#endregion
 		//#region src/version.ts
-		const WORKBUDDY_CONNECT_VERSION = "0.7.3";
+		const WORKBUDDY_CONNECT_VERSION = "0.7.5";
 		//#endregion
 		//#region src/client/WorkBuddyConfigPage.tsx
 		/**

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

@@ -1625,6 +1625,23 @@ const INTERNATIONAL_SYSTEM_PROMPT = "You are a helpful assistant.";
 */
 const INTERNATIONAL_PROBE_MAX_TOKENS = 16;
 //#endregion
+//#region src/wsl.ts
+/**
+* Whether this Linux process is running inside Windows Subsystem for Linux.
+*
+* Shared by the desktop-auth candidate probe (`auth.ts`) and the at-rest key
+* helper spawn (`desktop-credential-protection.ts`), so both agree on what
+* "WSL" means. Covers WSL1 and WSL2: WSL2 sets `WSL_DISTRO_NAME` /
+* `WSL_INTEROP`, and every WSL kernel release string carries "microsoft"
+* (e.g. `6.18.33.2-microsoft-standard-WSL2`), which also catches a WSL2
+* session whose env vars were stripped.
+*/
+function isWsl() {
+	if (process.platform !== "linux") return false;
+	if (process.env["WSL_DISTRO_NAME"] !== void 0 || process.env["WSL_INTEROP"] !== void 0) return true;
+	return release().toLowerCase().includes("microsoft");
+}
+//#endregion
 //#region src/status-paths.ts
 /** Node-free constants and types shared by the Host and browser halves. */
 /** Plugin-owned status endpoint consumed by its browser half. */
@@ -2140,6 +2157,86 @@ const PLUTIL_MAX_OUTPUT_BYTES = 65536;
 */
 var DiscoveryIncompleteError = class extends Error {};
 /**
+* Merge a `WSLENV` value so `ELECTRON_RUN_AS_NODE` crosses WSL→Windows
+* interop (#133).
+*
+* WSL only forwards listed variables to a Windows child, and only when the
+* entry carries the `/w` (WSL→Windows) direction flag — a plain
+* `env: { …, ELECTRON_RUN_AS_NODE: '1' }` stays on the Linux side, so the
+* WorkBuddy exe starts in GUI mode and its stdout is app log rather than the
+* key payload.
+*
+* The target variable is consolidated into exactly ONE safe entry, because
+* duplicate same-name entries leave the forwarding direction indeterminate:
+*
+* - the single entry always carries `w` (the plugin's requirement) and takes
+*   the position of the first same-name occurrence;
+* - `u` (Windows→WSL) is kept when ANY existing same-name entry asked for it,
+*   so a user's bidirectional setup survives as `/uw`;
+* - the path flags are dropped: `p` (path translation) and `l` (path list)
+*   would mangle the value, which here is the numeric switch `1` —
+*   `ELECTRON_RUN_AS_NODE=1` must arrive byte-for-byte, never as a converted
+*   path. An inherited `/pw`, `/lw`, or `/l` therefore normalizes to a
+*   path-free flag set rather than being appended to;
+* - a BARE name carries no direction at all, so it counts as neither `w` nor
+*   `u` — it only consolidates;
+* - with no same-name entry at all, `ELECTRON_RUN_AS_NODE/w` is appended;
+* - every OTHER entry keeps its order and bytes; empty segments (the
+*   trailing colons Windows Terminal tends to leave) and exact duplicates
+*   among them are dropped.
+*
+* The result is idempotent: merging it again yields the same string.
+*
+* @param value - the inherited `WSLENV` value, or `undefined` when unset.
+* @returns the `WSLENV` value the child should receive.
+*/
+function wslenvForwardRunAsNode(value) {
+	const merged = [];
+	/** Index of the consolidated target entry inside `merged`, once placed. */
+	let targetIndex = -1;
+	/** The safe flag set for the target: always `w`, plus `u` if asked for. */
+	let targetFlags = "/w";
+	for (const entry of (value ?? "").split(":")) {
+		if (entry === "") continue;
+		const slash = entry.indexOf("/");
+		if ((slash === -1 ? entry : entry.slice(0, slash)) !== "ELECTRON_RUN_AS_NODE") {
+			if (!merged.includes(entry)) merged.push(entry);
+			continue;
+		}
+		if ((slash === -1 ? "" : entry.slice(slash + 1)).includes("u")) targetFlags = "/uw";
+		if (targetIndex === -1) {
+			targetIndex = merged.length;
+			merged.push(`ELECTRON_RUN_AS_NODE${targetFlags}`);
+		} else merged[targetIndex] = `ELECTRON_RUN_AS_NODE${targetFlags}`;
+	}
+	if (targetIndex === -1) merged.push(`ELECTRON_RUN_AS_NODE${targetFlags}`);
+	return merged.join(":");
+}
+/**
+* The environment the at-rest key helper is spawned with (#133).
+*
+* Always a fresh object — the parent (`process.env` in production) is never
+* mutated. `ELECTRON_RUN_AS_NODE=1` forces the Electron binary into plain
+* Node mode; when the spawn crosses WSL→Windows interop — a WSL host and a
+* helper that is itself a Windows executable — the child's `WSLENV` is
+* additionally merged via {@link wslenvForwardRunAsNode} so the interop layer
+* actually forwards that variable. Every other platform and path combination
+* gets the previous behaviour byte-for-byte.
+*
+* @param parent - the environment to inherit (a copy is taken).
+* @param electronPath - the helper binary about to be spawned.
+* @param wsl - whether the current process runs inside WSL.
+* @returns the child process environment.
+*/
+function helperChildEnv(parent, electronPath, wsl) {
+	const childEnv = {
+		...parent,
+		ELECTRON_RUN_AS_NODE: "1"
+	};
+	if (wsl && basename(electronPath).toLowerCase().endsWith(".exe")) childEnv["WSLENV"] = wslenvForwardRunAsNode(childEnv["WSLENV"]);
+	return childEnv;
+}
+/**
 * The default discovery tools: Spotlight for the bundle, `/usr/bin/plutil` for
 * identity. Every failure that means "we could not tell" — a missing tool, a
 * timeout, an oversized answer — is raised as {@link DiscoveryIncompleteError}
@@ -2258,7 +2355,7 @@ function workBuddyWindowsDiscoveryTools() {
 					resolve(Buffer.alloc(0));
 					return;
 				}
-				reject(new DiscoveryIncompleteError(`reg.exe could not complete (${error.killed === true ? "timed out" : String(error.code ?? "unavailable")})`));
+				reject(new DiscoveryIncompleteError(`reg.exe could not complete (${subprocessFailureReason(error)})`));
 				return;
 			}
 			resolve(stdout);
@@ -2322,7 +2419,7 @@ function workBuddyWindowsDiscoveryTools() {
 					reject(new DiscoveryIncompleteError(`powershell.exe could not read the registry root ${root}`));
 					return;
 				}
-				reject(new DiscoveryIncompleteError(`powershell.exe could not complete (${error.killed === true ? "timed out" : String(error.code ?? "unavailable")})`));
+				reject(new DiscoveryIncompleteError(`powershell.exe could not complete (${subprocessFailureReason(error)})`));
 				return;
 			}
 			const records = parseWindowsUninstallJson(stdout);
@@ -2412,6 +2509,7 @@ function parseWindowsUninstallJson(output) {
 	platform;
 	discoveryBudgetMs;
 	timeoutMs;
+	wsl;
 	source;
 	spawnHelper;
 	/**
@@ -2434,6 +2532,7 @@ function parseWindowsUninstallJson(output) {
 		this.windowsTools = options.windowsTools ?? workBuddyWindowsDiscoveryTools();
 		this.discoveryBudgetMs = options.discoveryBudgetMs ?? 1e4;
 		this.timeoutMs = options.timeoutMs ?? 1e4;
+		this.wsl = options.wsl ?? isWsl;
 		this.spawnHelper = options.spawnHelper ?? ((path) => this.spawnAt(path));
 		this.source = options.source ?? (() => this.spawnPayload());
 	}
@@ -2636,10 +2735,7 @@ function parseWindowsUninstallJson(output) {
 				timeout: this.timeoutMs,
 				maxBuffer: 1048576,
 				windowsHide: true,
-				env: {
-					...process.env,
-					ELECTRON_RUN_AS_NODE: "1"
-				}
+				env: helperChildEnv(process.env, electronPath, this.wsl())
 			}, (error, stdout) => {
 				if (error !== null && error !== void 0) {
 					reject(new WorkBuddyElectronPathError("encrypted-credential-unreadable", `the WorkBuddy key helper (${electronPath}) ${error.killed === true ? `timed out or was killed after ${String(this.timeoutMs)}ms` : error.code !== void 0 ? `exited with code ${String(error.code)}` : "could not be started"}`));
@@ -2655,6 +2751,19 @@ function parseWindowsUninstallJson(output) {
 		});
 	}
 };
+/**
+* Why a finished-but-failed discovery subprocess cannot produce an answer.
+*
+* A size-limit overflow (`maxBuffer`, delivered as
+* `ERR_CHILD_PROCESS_STDIO_MAXBUFFER`) gets its own words: reporting it as a
+* timeout would send a user chasing scheduler latency when the machine's
+* uninstall tree is simply larger than the documented cap — a different
+* problem with a different fix. Both stay "incomplete", never "absent".
+*/
+function subprocessFailureReason(error) {
+	if (error.code === "ERR_CHILD_PROCESS_STDIO_MAXBUFFER") return "the output exceeded the size limit";
+	return error.killed === true ? "timed out" : String(error.code ?? "unavailable");
+}
 /** Only known missing-key diagnostics can safely make a failed query empty. */
 function windowsRegistryKeyMissing(stderr) {
 	const detail = stderr.trim();
@@ -2830,12 +2939,6 @@ const DESKTOP_AUTH_RELATIVE_PATH = [
 	"auth",
 	"workbuddy-desktop.info"
 ];
-/** Whether this Linux process is running inside Windows Subsystem for Linux. */
-function isWsl() {
-	if (process.platform !== "linux") return false;
-	if (process.env["WSL_DISTRO_NAME"] !== void 0 || process.env["WSL_INTEROP"] !== void 0) return true;
-	return release().toLowerCase().includes("microsoft");
-}
 /** Convert a Windows drive path to WSL's conventional `/mnt/<drive>` form. */
 function windowsPathForWsl(value) {
 	const path = value?.trim();
@@ -4015,7 +4118,7 @@ var WorkBuddyCatalog = class {
 };
 //#endregion
 //#region src/version.ts
-const WORKBUDDY_CONNECT_VERSION = "0.7.3";
+const WORKBUDDY_CONNECT_VERSION = "0.7.5";
 //#endregion
 //#region src/host-heartbeat.ts
 /**

package/lib/index.d.ts

@@ -851,6 +851,13 @@ interface WorkBuddyAtRestKeyProviderOptions {
   windowsTools?: WorkBuddyWindowsDiscoveryTools;
   /** Platform override for deterministic discovery tests. */
   platform?: NodeJS.Platform;
+  /**
+   * Whether the helper spawn crosses WSL→Windows interop. Injectable so tests
+   * can simulate a WSL host on any platform; defaults to the shared
+   * {@link isWsl} check. Only consulted for the key-helper spawn (#133) —
+   * never for discovery.
+   */
+  wsl?: () => boolean;
   /**
    * Total budget for one discovery run, covering the search and every
    * candidate check. Injectable so tests can exercise exhaustion without
@@ -878,6 +885,7 @@ interface WorkBuddyAtRestKeyProviderOptions {
   private readonly platform;
   private readonly discoveryBudgetMs;
   private readonly timeoutMs;
+  private readonly wsl;
   private readonly source;
   private readonly spawnHelper;
   /**

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-DpaqHdXw.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-CvtbpuQi.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.3",
+  "version": "0.7.5",
   "author": "corrinehu",
   "keywords": [
     "dsh-plugin",