{
  "latestTested": "0.2.1-rc.3",
  "acceptedRuntimeRange": ">=0.1.1-rc.2 <0.3.0-0",
  "supported": [
    "0.1.1-rc.2",
    "0.1.2-alpha.2",
    "0.1.2-alpha.3",
    "0.1.2-alpha.5",
    "0.1.5-alpha.1",
    "0.1.5-alpha.2",
    "0.1.5-rc.1",
    "0.1.5-rc.2",
    "0.1.5-rc.3",
    "0.1.6-alpha.1",
    "0.1.6-alpha.2",
    "0.1.7-alpha.1",
    "0.1.7-alpha.2",
    "0.1.7-rc.1",
    "0.1.7-rc.2",
    "0.2.0-rc.1",
    "0.2.0-rc.2",
    "0.2.1-rc.1",
    "0.2.1-rc.3"
  ],
  "piAi": "1.1.0",
  "validation": {
    "0.1.5-alpha.1": "58 automated tests, real Cordis Loader/Connection activation with dynamic trustedHosts interpolation, and RPC authentication/disposal checks. User confirmed successful DSH startup with the corrected webRuntime/webServer dependency list; no live model or full account-flow verification.",
    "0.1.5-alpha.2": "Offline tests against the published host packages cover resolution and call preparation of every advertised Kimi model using the real PiAiAdapter, Cordis Loader/Connection activation and RPC authentication/disposal, and the actual adapter retry policy through the real retry executor and Session event validation (six retryable codes, finite backoff, two-retry limit, original failure preservation, provider-directed delays, and cancellation). No live model calls, real credential reads, or full GUI/account-flow verification.",
    "0.1.7-rc.1": "Offline tests run against the published 0.1.7-rc.1 host packages, the same version as the desktop app. They cover the desktop installer's peer-range gate, activation without the removed settings.register API, model resolution and call preparation through the real PiAiAdapter, Cordis Loader/Connection activation (including the legacy 0.1.2-alpha.5 Connection), RPC authentication/disposal, and the adapter retry policy. A scratch profile boot confirms the account route mounts. No live model calls, real credential reads, or desktop GUI verification.",
    "0.1.7-rc.2": "The desktop app auto-updated to this release. Its app-boot compatibility gate accepts the declared peer range, the client modules this plugin injects are all present, and `@deepseek-ai/dsh-llm` / `@deepseek-ai/dsh-llm-pi-ai` still export `LlmError`, `resolveRetryPolicy`, and `PiAiAdapter`. The settings service still has no `register`, so the volatile-Config path is the one that runs. A scratch profile boot on this kernel activates the account route. The device authorization request was also exercised against the live Kimi endpoint; the token exchange is covered by offline tests only, including the compressed-body and classified-failure paths. Release 1.3.1 additionally exercised the plugin self-update path against this exact desktop runtime with the shipped bundle: the live host process's own launch arguments were replayed, the bundled pnpm 11.7.0 entry was selected by name, and `update()` installed the target version into a scratch desktop profile and rewrote its dependency while keeping the `dsh.profile.bundles` entry. That run also confirmed `dsh plugin --profile desktop` is refused by this CLI, which is why the update installs with pnpm directly. No live model calls or credential reads.",
    "0.2.0-rc.2": "DeepSeek Harness.app 0.2.0-rc.2 and its bundled CLI are the same host line. `dsh web --dump-default-config` on that CLI shows the official connection row injects only webRuntime; the string webServer does not appear anywhere in the default tree. Desktop loads the same @deepseek-ai/dsh-web-app@0.2.0-rc.2 bundle, so deleting the connection patch would drop webServer on both surfaces. A scratch web profile with this plugin linked composes inject [credentials, webRuntime, webServer], keeps trustedHosts as the webRuntime expression, and reaches the listen line with no 'did not activate' warning. The offline suite still runs on the 0.2.0-rc.1 packages already in the lockfile; connection's published 0.2.0-rc.2 bundle is byte-identical to 0.2.0-rc.1. No live model calls, credential reads, or desktop GUI verification.",
    "0.2.0-rc.1": "The desktop app updated to this release. Its app-boot compatibility preflight had disabled the whole bundle, because every declared `@deepseek-ai/dsh-*` peer stopped at `<0.2.0-0`; the profile startup line was `skipping profile bundle \"dsh-kimi-subscription\": Error: Plugin dsh-kimi-subscription@1.3.1 is incompatible with dsh 0.2.0-rc.1`. That denial was reproduced against a scratch profile on the real desktop runtime, and the widened range was confirmed to clear it. Every host package this plugin consumes is present at 0.2.0-rc.1, every module named in `dsh.client.inject` resolves, `@deepseek-ai/dsh-llm` still exports `LlmError` and `resolveRetryPolicy`, `@deepseek-ai/dsh-llm-pi-ai` still exports `PiAiAdapter`, and `@deepseek-ai/dsh-settings` still has no `register`, so the volatile-Config path is the one that runs. The development baseline and the whole offline suite now run against the published 0.2.0-rc.1 host packages and pi-ai 0.87.1, which the 0.2 line resolves through `^0.85.1`; `kimiCodingProvider` is unchanged between pi-ai 0.85.1 and 0.87.1. No live model calls, credential reads, or desktop GUI verification.",
    "0.2.1-rc.1": "DeepSeek Harness.app 0.2.1-rc.1 renamed the service the official connection row injects from webRuntime to webStartup (trustedHosts: !!js ctx.webStartup.trustedHosts). With 1.3.8 installed the desktop app did not boot: the bundle's row patch replaced that inject list with [credentials, webRuntime, webServer], and the host listed `connection (required)  webRuntime` among the plugins waiting for services. `--dump-config` on the app's bundled CLI, run against a scratch DSH_HOME, composes exactly that row for 1.3.8 and leaves the official [webStartup] row untouched for 1.3.9; the bundle passes the app-boot peer gate in both. The whole offline suite also runs against the host packages extracted from that app (cordis 4.0.5, cordis-plugin-loader 1.0.6, cordis-plugin-include 1.0.10, dsh-client-connection, dsh-llm, and dsh-llm-pi-ai 0.2.1-rc.1, pi-ai 1.1.0) through a resolver hook with no fallback to the development baseline: all 106 tests pass, including activation on the official 0.2.1 row, a web server that starts after the plugin, and rejection of unauthenticated requests. Cordis 4.0.5's runtime is byte-identical to 4.0.4, and pi-ai 1.1.0's kimiCodingProvider is unchanged. This host's adapter lists a provider's models only after resolveApiKey succeeds, so an unconnected subscription shows no Kimi models. The published 0.2.1-rc.1 packages are younger than the release-age window, so the development baseline stays at 0.2.0-rc.1. Desktop was not restarted. No live model calls, credential reads, or desktop GUI verification.",
    "0.2.1-rc.3": "The development baseline moved to the host packages DeepSeek Harness.app 0.2.1-rc.3 ships: dsh 0.2.1-rc.3, cordis 4.0.5, cordis-plugin-loader 1.0.6, cordis-plugin-include 1.0.10, schemastery 3.18.5, and pi-ai 1.1.0, read from the app bundle. As in the app, the llm-pi-ai adapter and the plugin now load one pi-ai copy, and a contract test keeps them on it. The previous baseline paired the 0.2.0-rc.1 adapter, which depends on pi-ai ^0.85.1, with the plugin on 0.87.1. pi-ai 0.87.1 expects the system prompt and tools folded into the transcript and 0.85.1 hands them over unfolded, so every Kimi request lost both without an error. A desktop profile whose installed plugin still carried a node_modules copied from a local-path install ran that same pairing, and Kimi ended every turn after one reply without calling a tool. All offline tests pass on the new baseline, including a request through the real adapter that must carry the system prompt and tools. dsh-invariants left the baseline: no 0.2.1 package depends on it and the app does not ship it. After that copy was removed and the user restarted the app, the next session in DeepSeek Harness.app 0.2.1-rc.3 had k3.1-pro-highspeed call bash, glob, grep, and read 15 times. This change made no live model calls and read no credentials."
  }
}