@auggieteo/dsh-mcp-adapter 0.4.2 → 0.5.0

package/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to this project are documented in this file.
 
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [v0.5.0] - 2026-09-30
+
+### Fixed
+
+- DSH 0.2.0-rc.2 no longer skips the plugin. A web profile running DSH 0.2.0-rc.2 refused to load the Adapter at all, logging `skipping profile bundle "@auggieteo/dsh-mcp-adapter": Plugin @auggieteo/dsh-mcp-adapter@0.4.2 is incompatible with dsh 0.2.0-rc.2: peerDependencies {"@deepseek-ai/dsh-settings":"^0.1.7-rc.1"}` and leaving MCP unconfigured — the runtime gates every `@deepseek-ai/dsh*` peer range against **its own version**, so a range capped at `^0.1.7-rc.1` excludes every 0.2.x release. The break is declaration-only: checked against the installed 0.2.0-rc.2 packages, every surface the Adapter uses is unchanged — `@deepseek-ai/dsh-settings` still exports `SettingsForms` and `redactSecrets`, the host `connection.fetch.register` exact-route seam takes the same `{ path, methods, requestBody, fetch }` route, the client's `connection.rpc.call(channel, endpoint, …)` signature is unchanged, `configForms` keeps `get`/`describe`/`mutate` over the positional `remote.settings` wire, the `settings.section` slot survives, `loader/volatile-update` still commits volatile Config edits (cordis-plugin-loader 1.0.5), schemastery is the same 3.18.4, and the nav-icon patch's `MODELS_BRANCH` pattern still matches the 0.2.0-rc.2 settings shell. The peer range therefore widens to `@deepseek-ai/dsh-settings` `^0.1.7-rc.1 || ^0.2.0-rc.1` with no source change, and no legacy drop is needed — DSH 0.1.7-rc.x keeps working. Compatibility is pinned by execution, not by diff reading: `test/client-apply.test.js` adds a 0.2.0-rc.2 generation fake locking the identical positional write (`remote.update`, `mcp-adapter`, the Server patch, revision `7` → `8`), and `test/package.test.js` pins the range against both generations' runtime versions. No exact-version exemption (`dsh plugin allow-version`) is needed: update the plugin instead. [ADR 0009](docs/adr/0009-dual-generation-settings-api.md).
+
 ## [v0.4.2] - 2026-09-28
 
 ### Fixed

package/README.md

@@ -67,6 +67,7 @@ Then restart DSH. The Settings panel (`⌘,` / sidebar foot) gains an **MCP** se
 | DSH release | Support |
 | --- | --- |
 | 0.1.7-rc.1 and newer 0.1.x | Supported. Configuration is the plugin's Loader-entry Config: the Host reads the validated Config cordis passes to `apply` (there is no `ctx.config`) plus its live-committed volatile updates, writes go through the settings service, and the page reads the `configForms` service and writes through the `remote.settings` face mounted by the `@deepseek-ai/dsh-api-remotes` client bundle. |
+| 0.2.0-rc.1 and newer 0.2.x | Supported. Same Loader-entry Config model: every surface the Adapter uses — `configForms`, the `remote.settings` wire face, the `connection.fetch` exact-route seam, `tools`/`commands` registration, the `settings.section` slot, and the `loader/volatile-update` commit path — is unchanged from 0.1.7, so the support is declaration-only (peer `@deepseek-ai/dsh-settings` `^0.1.7-rc.1 \|\| ^0.2.0-rc.1`). `test/client-apply.test.js` pins the 0.2.0-rc.2 wire shape by execution. |
 | Older 0.1.x | Unsupported. Those releases require the registered-namespace settings model this plugin used through v0.3.x; upgrade DSH or stay on that release line. |
 
 Upgrading from v0.3.x on DSH 0.1.7: at the first start after the upgrade, the Adapter imports the legacy `mcp:` section of the profile's `settings.yaml` into the `mcp-adapter` entry once. A `mcp-adapter.legacy-imported` marker records the import; anything the import refuses to accept (for example an invalid section) stays in `settings.yaml.imported` and a Host warning names the manual copy path. See [ADR 0010](./docs/adr/0010-loader-entry-config-model.md).

package/docs/adr/0009-dual-generation-settings-api.md

@@ -13,3 +13,5 @@ Consequences: the `apply`-level test suite (`test/client-apply.test.js`) compile
 *Widening (0.1.5 check):* the DSH 0.1.2-rc.1 → 0.1.5-rc.2 diff leaves every face this ADR pins on untouched — `packages/settings/settings` and `packages/api/settings-controller` change version strings only, the remotes mount list still includes the settings controller (two remotes added, none removed), and the `connection` service keeps its `rpc` face while refactoring reconnect internals. The one rename in range (`CommandInputDescriptor.images` → `attachments`) does not touch the Adapter's commands, which declare only `input.hint`. The peer dependency therefore widens to `^0.1.1-rc.2 || ^0.1.2-rc.1 || ^0.1.5-rc.1` with no code change; `test/client-apply.test.js` locks the 0.1.5-rc.1 shape with its own generation fake.
 
 *Superseded (0.1.7):* DSH 0.1.7 is the third shape this ADR anticipated and hard-failed on: `ctx.settings.register` is gone, configuration is the plugin's Loader-entry Config, and the client reads through the `configForms` service while the `remote.settings` wire keeps the positional shape and flat envelope pinned here. The 0.1.1 fallback and its fake are deleted; the surviving `remote.settings` wrapper now addresses the `mcp-adapter` entry id. See [ADR 0010](./0010-loader-entry-config-model.md).
+
+*Widening (0.2.0 check):* DSH 0.2.0-rc.2 will not load the Adapter at all: `dsh-app-boot`'s compatibility gate evaluates every `@deepseek-ai/dsh*` peer range **against the runtime version itself** — `semver.satisfies("0.2.0-rc.2", "^0.1.7-rc.1", { includePrerelease: true })` is false — so the profile logs `skipping profile bundle` and the plugin never applies. Checked surface by surface against the installed 0.2.0-rc.2 packages, the shape this ADR pins is untouched: `@deepseek-ai/dsh-settings` still exports `SettingsForms` and `redactSecrets(schema, value)`; the host mounts RPC on the shared `/api` channel through `connection.fetch.register` with the same `{ path, methods, requestBody, fetch }` route accepted by `registerFetchRoute`; the client's `rpc.call(channel, endpoint, payload, signal)` signature is unchanged; `configForms` keeps `get(entryId)`, `describe()`, and `mutate(ops, expectedRevision)` forwarding to `remote.settings.mutate(ns, ops, revision)`; the `settings.section` slot, the `webServer` provider inject, and `loader/volatile-update` (cordis-plugin-loader 1.0.5) all survive; schemastery is the same 3.18.4, so `.volatile()` needs nothing; and the nav-icon patch's `MODELS_BRANCH` pattern still matches `dsh-client-ui-settings-general`'s 0.2.0-rc.2 bundle. The break is declaration-level, so per this ADR's rule — source changes only on a runtime break — the peer dependency widens to `^0.1.7-rc.1 || ^0.2.0-rc.1` and 0.1.7 support is kept, not dropped: the shape proves out identical, and a range that abandoned 0.1.7 would strand users whose harness the Adapter still satisfies. `test/client-apply.test.js` locks the 0.2.0-rc.2 generation with its own fake pinning the positional write on `mcp-adapter`, so the widening is backed by execution. The cap at `<0.3.0-0` is deliberate: the gate is the mechanism that turns an unverified future generation into one loud startup log instead of an `undefined` read at runtime, so it is widened by evidence, release by release — `test/package.test.js` pins the range and both accepted bounds.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@auggieteo/dsh-mcp-adapter",
-  "version": "0.4.2",
+  "version": "0.5.0",
   "description": "DSH plugin connecting the agent to MCP servers through one mcp proxy tool and a Settings > MCP page.",
   "type": "module",
   "license": "MIT",
@@ -57,7 +57,7 @@
     "provenance": true
   },
   "peerDependencies": {
-    "@deepseek-ai/dsh-settings": "^0.1.7-rc.1",
+    "@deepseek-ai/dsh-settings": "^0.1.7-rc.1 || ^0.2.0-rc.1",
     "@deepseek-ai/schemastery": "^3.18.4"
   },
   "devDependencies": {