dsh-vision-router 2.1.3 → 2.1.5

package/README.md

@@ -17,7 +17,7 @@
 </p>
 
 <p align="center">
-  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.1.0"><img src="https://img.shields.io/badge/release-v2.1.0-5B4CF0?style=flat-square" alt="Release v2.1.0" /></a>
+  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.1.5"><img src="https://img.shields.io/badge/release-v2.1.5-5B4CF0?style=flat-square" alt="Release v2.1.5" /></a>
   <a href="tests"><img src="https://img.shields.io/badge/verified-Node%2022%20%2B%2024-2EA44F?style=flat-square" alt="Verified: Node 22 + 24" /></a>
   <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-2EA44F?style=flat-square" alt="License: MIT" /></a>
   <a href="package.json"><img src="https://img.shields.io/badge/Node.js-%3E%3D22-339933?style=flat-square&amp;logo=nodedotjs&amp;logoColor=white" alt="Node.js >=22" /></a>
@@ -39,9 +39,9 @@
 <p align="center">💬 <strong>QQ community group: 1105463028</strong></p>
 
 > [!WARNING]
-> 📌 **Announcement (v2.1.0)**
+> 📌 **Announcement (v2.1.5)**
 >
-> **v2.1.0:** Native five-card Settings, explicit Vision mode, runtime i18n, hardened capability routing/benchmarks, and the DSH rc.8 support floor. [What’s new →](docs/releases/v2.1.0.md)
+> **v2.1.5:** Supports the current DSH stable `0.1.5-rc.1`, reconciles Vision twins as providers change live, preserves Vision across wrapped-model switches, and hardens Web activation plus the release/security pipeline. [What’s new →](docs/releases/v2.1.5.md)
 
 <p align="center">
   <img src="assets/vision-demo.gif" width="640" alt="Demo: paste an image, the agent locates the send button with vision_ground / vision_crop / vision_pixel_diff and answers with coordinates" />
@@ -413,7 +413,7 @@ ollama pull qwen2.5vl
 ## Requirements
 
 - DeepSeek Harness Web profile. Normal installs can use `npx @deepseek-ai/dsh ...`; source checkouts use `pnpm dsh ...`. A bare `dsh ...` command only works when the CLI is already on your shell `PATH`.
-- **DSH Host support window:** DVR 2.1.x supports DSH `0.1.0-rc.8` (minimum), `0.1.1-rc.1` (previous released train), and current `0.1.1-rc.2`; DSH `0.1.2-alpha.4` is canary-only evidence. DVR 2.0.x was the final train with public support for rc.6/rc.7. See [DSH Host support window](docs/architecture/dsh-support-window.md).
+- **DSH Host support policy:** DVR 2.1.x keeps DSH `0.1.0-rc.8` as the public minimum and currently supports the released stable channel through `0.1.5-rc.1`. Exact `0.1.5-alpha.2` coverage is **verification evidence only**, not a preview support promise; scheduled `latest`/`alpha` canaries monitor drift without changing the support policy. DVR 2.0.x was the final train with public support for rc.6/rc.7. See [DSH Host support window](docs/architecture/dsh-support-window.md).
 - Node ≥ 22 (host side).
 - No API key for the default free chain; a credential reference (`apiKeyEnv`) only for paid `httpProviders`.
 - Chrome / Chromium / Edge is needed only for `vision_html_screenshot`; every other tool works without a browser.

package/README.zh.md

@@ -17,7 +17,7 @@
 </p>
 
 <p align="center">
-  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.1.0"><img src="https://img.shields.io/badge/release-v2.1.0-5B4CF0?style=flat-square" alt="Release v2.1.0" /></a>
+  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.1.5"><img src="https://img.shields.io/badge/release-v2.1.5-5B4CF0?style=flat-square" alt="Release v2.1.5" /></a>
   <a href="tests"><img src="https://img.shields.io/badge/verified-Node%2022%20%2B%2024-2EA44F?style=flat-square" alt="已验证 Node 22 + 24" /></a>
   <a href="LICENSE"><img src="https://img.shields.io/badge/license-MIT-2EA44F?style=flat-square" alt="MIT 许可证" /></a>
   <a href="package.json"><img src="https://img.shields.io/badge/Node.js-%3E%3D22-339933?style=flat-square&amp;logo=nodedotjs&amp;logoColor=white" alt="Node.js >=22" /></a>
@@ -39,9 +39,9 @@
 <p align="center">💬 <strong>QQ 用户交流群：1105463028</strong></p>
 
 > [!WARNING]
-> 📌 **公告（v2.1.0）**
+> 📌 **公告（v2.1.5）**
 >
-> **v2.1.0：原生五卡设置、输入框识图、运行时双语、能力路由/测评加固，并正式启用 DSH rc.8 最低支持线。** [查看完整更新 →](docs/releases/v2.1.0.md)
+> **v2.1.5：已支持当前 DSH 稳定版 `0.1.5-rc.1`，修复 live provider 变化时 Vision twin 对账与识图模式下 wrapper 模型切换，并加固 Web 激活与发版/安全链路。** [查看完整更新 →](docs/releases/v2.1.5.md)
 
 <p align="center">
   <img src="assets/vision-demo.gif" width="640" alt="演示：粘贴图片，Agent 用 vision_ground / vision_crop / vision_pixel_diff 定位发送按钮并给出坐标" />
@@ -411,7 +411,7 @@ ollama pull qwen2.5vl
 ## 环境要求
 
 - DeepSeek Harness 的 Web profile。普通安装可用 `npx @deepseek-ai/dsh ...`；从源码仓库运行时用 `pnpm dsh ...`。只有 CLI 已经进入系统 `PATH` 时才能直接写 `dsh ...`。
-- **DSH Host 支持窗口：** DVR 2.1.x 支持 DSH `0.1.0-rc.8`（最低）、`0.1.1-rc.1`（上一正式支持线）以及当前 `0.1.1-rc.2`；DSH `0.1.2-alpha.4` 仅作为 canary 兼容证据。DVR 2.0.x 是最后公开支持 rc.6/rc.7 的版本线。详见 [DSH Host 支持窗口](docs/architecture/dsh-support-window.md)。
+- **DSH Host 支持策略：** DVR 2.1.x 的公开最低 Host 仍为 DSH `0.1.0-rc.8`，当前正式发布通道已验证并支持到 `0.1.5-rc.1`。对 `0.1.5-alpha.2` 的精确覆盖**只属于验证证据**，不代表对 preview 的公开支持承诺；定时 `latest`/`alpha` canary 只负责发现上游漂移，也不会自动改变支持策略。DVR 2.0.x 是最后公开支持 rc.6/rc.7 的版本线。详见 [DSH Host 支持窗口](docs/architecture/dsh-support-window.md)。
 - Node ≥ 22（宿主侧）。
 - 默认免费链路无需 API Key；付费 `httpProviders` 只需一个凭据引用（`apiKeyEnv`）。
 - 只有 `vision_html_screenshot` 需要 Chrome / Chromium / Edge；其余工具无浏览器也能用。

package/cordis.patch.yml

@@ -4,9 +4,20 @@
 # without any manual cordis.patch.yml edits. Later layers (the profile's own
 # cordis.patch.yml, --patch overlays) override these rows by id.
 
-# 纯增量补丁（issue #34）：不碰核心行。最低支持 Host 仍保留旧兼容路径；
+# 纯增量补丁（issue #34）：不替换/禁用核心行。最低支持 Host 仍保留旧兼容路径；
 # batch-attachment 合同的 Host 始终拥有 deepseek-official，插件只提供
 # 「+ 自动识图」包装路由，因此这里永远不默认禁用官方 llm-deepseek 行。
+#
+# DSH 0.1.5 family（含当前 0.1.5-rc.1）的 client-modules Node half 在 webServer 尚未可用时会走
+# ctx.inject() 延迟注册路径；Linux 并行 Loader 激活可在安装额外 client bundle 后
+# 命中 Cordis 的 service-access 竞态（"webServer without inject"）。rc.8 至当前
+# Web bundle 都使用同一个 modules row，因此只给该既有行追加显式 webServer
+# activation dependency：不替换 row，不改变 client graph，只把官方已经需要的
+# Web carrier 依赖从运行时探测收敛成 Loader 顺序。非 Web surface 缺少该 row 时
+# Include 按官方 patch 语义仅跳过此 overlay。上游修复该竞态后可重新审计删除。
+- id: modules
+  name: '@deepseek-ai/dsh-client-modules'
+  inject: [webServer]
 
 # 挂载插件行。默认保持完整视觉工具表常驻（issue #81）：虽然渐进挂载可以
 # 少发一小段工具 schema，但图片轮首次扩展工具列表会改变请求前缀，可能让

package/docs/architecture/compat-inventory.md

@@ -40,12 +40,12 @@ P0 records why each major compatibility seam exists and the condition that permi
 
 ## `lib/pi-ai-bridge-wire-compat.js`
 
-- **Reason:** make the legacy direct image bridge transport-equivalent to pi-ai declared wire compatibility without reading credentials or changing provider priority.
-- **Host gap:** the direct bridge predates route/model wire metadata such as max-token fields and route-owned headers.
-- **First needed for:** DSH 0.1.1 pi-ai declared provider/wire compatibility.
-- **Feature detection:** exact non-streaming OpenAI-compatible image bridge fingerprint plus resolved route/model facts; normal streaming Host traffic does not match.
-- **Removal condition:** the direct bridge is removed or every supported Host executes this image path through the native pi-ai wire seam.
-- **Tests:** `pi-ai-bridge-wire-compat`, native process-restart/cold-resume contract.
+- **Reason:** keep the legacy direct image bridge transport-equivalent to pi-ai declared wire compatibility and, while upstream lacks the OpenCode-specific carrier, project Vision Router-owned session affinity onto the final Go wire without taking ownership of ordinary Host traffic. `lib/session-affinity-runtime.js` is the scoped AsyncLocalStorage companion; it carries affinity only while a Router-owned lazy stream is executing.
+- **Host gap:** the direct bridge predates route/model wire metadata such as max-token fields and route-owned headers; current DSH/pi-ai accepts `GenerateOptions.sessionId` but emits generic affinity carriers rather than OpenCode Go's required `x-opencode-session`.
+- **First needed for:** DSH 0.1.1 pi-ai declared provider/wire compatibility; OpenCode Go's September 2026 required session header.
+- **Feature detection:** legacy wire recovery still requires the exact non-streaming OpenAI-compatible image bridge fingerprint plus resolved route/model facts. OpenCode affinity requires an active Vision Router AsyncLocalStorage scope, the exact official HTTPS `opencode.ai/zen/go...` endpoint, and absence of an upstream-native `x-opencode-session`; unrelated Host/plugin traffic is inert.
+- **Removal condition:** remove legacy bridge recovery when every supported Host executes that image path through native pi-ai wire facts; remove the scoped OpenCode projection independently once every supported DSH/pi-ai path emits `x-opencode-session` from `GenerateOptions.sessionId`. The native header must win before deletion so the compatibility rule self-retires.
+- **Tests:** `pi-ai-bridge-wire-compat`, real `opencode-session-wire-contract`, native process-restart/cold-resume contract.
 
 ## `lib/settings-client-rc8-lifecycle.js`
 

package/docs/architecture/dsh-compatibility-matrix.md

@@ -8,10 +8,11 @@ The matrix is capability-based. Runtime code must feature-detect the seam it nee
 
 | CI fixture | DSH package line | Role |
 | --- | --- | --- |
-| `minimum-contract` | `0.1.0-rc.6` | Minimum supported Host contract. Must remain green. |
-| `legacy-contract` | `0.1.0-rc.8` | Legacy contract carrying batch attachments and dimension policy. |
-| `current-contract` | `0.1.1-rc.2` | Current contract baseline for 2.x convergence. Must be green before P1. |
-| `latest-dsh` | resolved dynamically from npm | Scheduled canary only. Never a normal PR required check. |
+| `minimum-contract` | `0.1.0-rc.6` | Historical compatibility-retention fixture. The name is legacy; DVR 2.1.x public support starts at rc.8. |
+| `legacy-contract` | `0.1.0-rc.8` | Public support-floor fixture carrying batch attachments and dimension policy. |
+| `current-contract` | `0.1.5-rc.1` | Current stable Host contract baseline. Must remain green. |
+| exact preview gates | `0.1.5-alpha.2` | Required verification evidence only; not a public preview-support claim. |
+| `latest-dsh` / alpha canaries | resolved dynamically from npm dist-tags | Scheduled drift surveillance only. Never changes support policy by itself. |
 
 Node 22 and Node 24 remain the general required runtime matrix. The Host contract jobs are additive; they do not replace the normal test matrix.
 
@@ -19,7 +20,7 @@ Node 22 and Node 24 remain the general required runtime matrix. The Host contrac
 
 `yes` means the fixture has a direct positive test or feature probe. `no` means a direct negative probe exists. `compat` means the fixture proves Vision Router can safely carry the newer input/config through that Host, but does **not** claim the Host owns that capability. `probe` means the capability is intentionally not inferred from the version label and is verified at runtime/contract-test time.
 
-| Capability | minimum-contract rc.6 | legacy-contract rc.8 | current-contract rc.2 | Evidence / detection |
+| Capability | minimum-contract rc.6 | legacy-contract rc.8 | current-contract rc.1 (0.1.5) | Evidence / detection |
 | --- | --- | --- | --- | --- |
 | Batch attachment save | no | yes | yes | `hasBatchAttachmentContract()` checks the released `attachments.saveImages` prototype; `tests/rc6-rc7-compat.test.js`; contract CI. |
 | Max image dimension policy | compat | yes | yes | All fixtures parse the complete attachment-local row; rc.8/current positively retain the field and the established admission tests exercise the 10000/10001 boundary. Older Schemastery passthrough is not treated as ownership evidence. |
@@ -53,5 +54,5 @@ Every compatibility seam must answer the same six questions: **Reason**, **Host
 
 1. A new version-specific branch requires evidence that no stable capability probe exists.
 2. A compatibility layer may narrow behavior to preserve an existing product contract; it may not expand routing authority.
-3. `latest-dsh` can reveal upstream drift, but a canary failure must not silently redefine the supported contract.
+3. Exact preview and dynamic canary evidence can reveal upstream drift, but neither may silently redefine the public support policy.
 4. P1 may begin only when all three gating fixtures and the existing cold-resume/resource baselines are green.

package/docs/architecture/dsh-support-window.md

@@ -1,21 +1,41 @@
 # DSH Host support window
 
-Status: normative for the DVR 2.x compatibility program.
+Status: normative for the current DVR 2.x compatibility program.
 
-## Current DVR 2.1.x window
+## Public support policy
+
+The public support policy contains only released Host semantics. Preview/canary versions are intentionally excluded from this table.
 
 | Role | DSH train | Meaning |
 |---|---|---|
 | Minimum Supported Host | `0.1.0-rc.8` | Oldest Host generation that DVR 2.1.x publicly supports. |
-| Previous Supported Train | `0.1.1-rc.1` | Previous released Host train kept in the compatibility matrix. |
-| Current Supported Train | `0.1.1-rc.2` | Current released train used by the required current-contract gate. |
-| Canary only | `0.1.2-alpha.4` | Latest upstream prerelease evidence at v2.1.0 release preparation time. It is not a released support-floor claim and does not authorize compat deletion by itself. |
+| Current Stable Host | `0.1.5-rc.1` | Current npm stable-channel release covered by required exact Host and browser evidence. |
+
+DVR `2.1.x` therefore keeps `0.1.0-rc.8` as its public floor and supports released Host trains through the current stable channel. Runtime branching remains capability-based rather than version-string-driven.
+
+No later support-floor increase is currently announced.
+
+## Verification evidence — not support policy
+
+Compatibility evidence answers a different question: what exact upstream releases and moving channels have current CI proof? It must never be interpreted as a public support-floor change.
+
+| Evidence role | DSH source | Meaning |
+|---|---|---|
+| Exact stable evidence | `0.1.5-rc.1` | Required Host/wire and real Host + Chromium coverage for the current stable release. |
+| Exact preview evidence | `0.1.5-alpha.2` | Required preview Host/wire/lifecycle/browser evidence. This is not a preview support promise. |
+| Stable drift canary | npm dist-tag `latest` | Scheduled, dynamically resolved surveillance. A failure starts compatibility investigation; it does not rewrite support policy. |
+| Preview drift canary | npm dist-tag `alpha` | Scheduled, dynamically resolved surveillance with preview-specific lifecycle coverage. A failure does not rewrite support policy. |
+
+The exact evidence values may move in a patch-level maintenance PR when CI proof advances. The public minimum may move only under the support-floor protocol below.
+
+Historical release notes under `docs/releases/` are release-time snapshots and are not rewritten when later evidence advances.
+
 
-DVR `2.1.x` therefore supports DSH `0.1.0-rc.8` and newer released trains covered by the published matrix. Runtime branching remains capability-based rather than version-string-driven.
+The optional peer-dependency range may admit an exact preview version so CI/users can install a verified preview Host without peer-resolution noise. That install admission is compatibility evidence, not a public preview support promise.
 
 ## Floor transition from DVR 2.0.x
 
-DVR 2.0.x was released with DSH `0.1.0-rc.6` as its minimum Host. The 2.1.0 boundary was announced in advance and raises the public minimum to DSH `0.1.0-rc.8`.
+DVR 2.0.x was released with DSH `0.1.0-rc.6` as its minimum Host. The 2.1.0 boundary was announced in advance and raised the public minimum to DSH `0.1.0-rc.8`.
 
 ```text
 DVR 2.0.x minimum: DSH 0.1.0-rc.6
@@ -26,24 +46,24 @@ Users still on rc.6/rc.7 should upgrade DSH before upgrading to DVR 2.1.x.
 
 This support-floor transition does **not** require deleting every rc.6-era compatibility seam in the same release. Compatibility code is retired only after a separate proof shows it is unreachable or unnecessary on every supported Host and durable-history path.
 
-No later support-floor increase is currently announced.
-
-## Support-window change protocol
+## Support-policy change protocol
 
-A Host support-floor change is valid only when all of the following are true:
+A public Host support-floor change is valid only when all of the following are true:
 
-1. the change is announced in a DVR minor or major release, never only in a patch release;
+1. the floor change is announced in a DVR minor or major release, never only in a patch release;
 2. README / support documentation and release notes state the old and new floors;
-3. Doctor reports the effective support window and gives a capability-based upgrade result for Hosts below the active floor;
-4. required CI has stable minimum, previous, current, and canary evidence for the declared window;
+3. Doctor reports the effective public support policy and gives a capability-based upgrade result for Hosts below the active floor;
+4. required CI proves the public floor and current stable Host, while preview and dynamic canaries remain separately labelled verification evidence;
 5. compatibility seams are removed only after the new minimum Host proves the replacement capability;
 6. removal PRs keep restart, settings, native-image coexistence, tool execution, Node 22/24 and supported-platform regressions green.
 
+Advancing an exact stable/preview evidence version or a moving canary target does **not** by itself change the public support floor.
+
 ## Capability-first rule
 
-Version labels describe the public support window; runtime branching still uses capabilities.
+Version labels describe support policy and CI evidence; runtime branching still uses capabilities.
 
-DVR must not turn this table into widespread version-string conditionals. Runtime compatibility continues to feature-detect the concrete Host seam it needs. If a capability cannot be proven safely, the compatibility path fails open or reports an explicit unsupported/unknown state according to that seam's contract.
+DVR must not turn these tables into widespread version-string conditionals. Runtime compatibility continues to feature-detect the concrete Host seam it needs. If a capability cannot be proven safely, the compatibility path fails open or reports an explicit unsupported/unknown state according to that seam's contract.
 
 ## Compatibility-retirement rule
 

package/docs/architecture/p3-compat-retirement.md

@@ -2,15 +2,17 @@
 
 Decision date: 2026-08-28
 
-Current DVR train: `2.0.x`
+Status: historical P3-B audit snapshot. It records the 2.0.x support policy in force at the decision date; it is **not** the current Host support policy. See [`dsh-support-window.md`](dsh-support-window.md) for the normative current policy and verification evidence.
 
-Current minimum supported Host: DSH `0.1.0-rc.6`
+DVR train at decision time: `2.0.x`
+
+Minimum supported Host at decision time: DSH `0.1.0-rc.6`
 
 ## Result
 
 **NO COMPAT DELETION IS CURRENTLY AUTHORIZED.**
 
-P3-B is intentionally a retirement audit, not a quota to delete files. Under the current 2.0.x support window, every Host-generation compatibility seam that materially exists for rc.6/rc.8 users still has a reachable support case.
+P3-B is intentionally a retirement audit, not a quota to delete files. Under the 2.0.x support window in force at the decision date, every Host-generation compatibility seam that materially exists for rc.6/rc.8 users still has a reachable support case.
 
 ## Seam review
 
@@ -18,7 +20,7 @@ P3-B is intentionally a retirement audit, not a quota to delete files. Under the
 |---|---|---|
 | attachment contract / Android attachment fallback | rc.6 remains the minimum and does not provide the later batch-attachment contract used by the modern path | after the released minimum Host no longer needs the single-attachment/permission fallback and the replacement is proven on the new minimum |
 | Host settings compatibility | rc.6 remains supported; live settings/client behavior differs across the support window | after the new minimum exposes the stable settings seam used by DVR without compatibility wrapping |
-| rc.8 browser/client lifecycle compatibility | rc.8 is still inside the declared support window and remains the Previous Supported Train | only after rc.8 itself leaves the support window or the same path becomes unreachable by capability proof |
+| rc.8 browser/client lifecycle compatibility | rc.8 is still inside the declared support window and was the Previous Supported Train at the decision date | only after rc.8 itself leaves the support window or the same path becomes unreachable by capability proof |
 | replay envelope v2 compatibility | old durable histories remain valid inputs even when the live Host is newer | only when the supported history/runtime window no longer needs producer rebinding or Host provides an equivalent native replay identity seam |
 | adapter prepareCall/coalescing compatibility | the support matrix still spans Host generations with different adapter-registration/update behavior | only when the minimum Host and every DVR-owned adapter satisfy one stable registration/update contract |
 | pi-ai bridge wire compatibility | legacy direct-bridge traffic remains a supported route shape | only after the direct bridge is retired or all supported Hosts execute that path through an equivalent native wire seam |
@@ -41,6 +43,6 @@ Each deletion still requires proof on:
 
 ## P3-B verdict
 
-`PASS — no expired seam under the current 2.0.x support window.`
+`PASS — no expired seam under the 2.0.x support window in force at the decision date.`
 
 Deleting a still-supported rc.6 seam merely to make the compatibility inventory smaller would violate the P3 plan and the published 2.0.x compatibility contract.

package/docs/architecture/p3-host-native-seams.md

@@ -2,7 +2,9 @@
 
 Decision date: 2026-08-28
 
-Support window: DVR `2.0.x` / minimum DSH `0.1.0-rc.6` / previous `0.1.0-rc.8` / current `0.1.1-rc.2`.
+Status: historical P3-D audit snapshot. It records the support policy in force when this decision was made; it is **not** the current Host support policy. See [`dsh-support-window.md`](dsh-support-window.md) for the normative current policy and verification evidence.
+
+Support window at decision time: DVR `2.0.x` / minimum DSH `0.1.0-rc.6` / previous `0.1.0-rc.8` / current `0.1.1-rc.2`.
 
 P3-D permits a migration only when all four conditions are true:
 

package/docs/doctor.md

@@ -79,7 +79,7 @@ or `DSH_WEB_URL`. To perform offline checks only:
 npx dsh-vision-router doctor --no-runtime
 ```
 
-An unreachable DSH process is advisory rather than a doctor failure; offline checks still complete. When `--profile` is used against a reachable runtime, doctor does not attribute green route health to that profile unless the runtime exposes a verified Vision Router profile identity. If ownership cannot be proven, the human report shows `? runtime profile ownership unknown` instead of a false green binding.
+An unreachable DSH process is advisory rather than a doctor failure; offline checks still complete. DSH Web may also require its signed browser-session cookie before any `/api` route is visible. If every side-effect-free route probe is rejected with `401`, Doctor reports the runtime as **reachable but authentication-required** and keeps plugin route health/ownership unknown instead of printing false route failures or bypassing Host authentication. The JSON report exposes `runtime.authenticationRequired: true`; capability support advice remains unknown because no Host seam was actually observed. When `--profile` is used against an authenticated reachable runtime, Doctor still does not attribute green route health to that profile unless the runtime exposes a verified Vision Router profile identity. If ownership cannot be proven, the human report shows `? runtime profile ownership unknown` instead of a false green binding.
 
 ### Local capability diagnostics
 
@@ -91,6 +91,9 @@ Doctor reports the local platform, Node version, and whether it can find:
 
 Tesseract, Chromium and profile-local Sharp are advisory because the corresponding optional tool may be unused or supplied by the host through another resolution path.
 
+
+Doctor also keeps **public Host support policy** separate from **compatibility verification evidence**. Human output lists the DVR support floor/current stable Host in the support section, then lists exact stable/preview CI evidence and moving npm canary channels in a separate verification section. In `--json`, these are separate `hostSupportWindow` and `hostVerificationEvidence` objects; preview/canary values never appear inside `hostSupportWindow`.
+
 ### Scan historical sessions
 
 Session scanning is opt-in because a large session store can take longer to read/decompress:

package/docs/releases/v2.1.4.md

@@ -0,0 +1,34 @@
+# v2.1.4
+
+DVR 2.1.4 is a compatibility and reliability patch for the current DSH stable/preview trains. It hardens Windows capture, OpenCode Go session affinity, attachment/timeout lifecycle boundaries, live-model credentials, background capability measurement, and Doctor diagnostics without changing the public 2.1.x routing model.
+
+## Runtime reliability
+
+- Replaces the legacy Windows DPI screenshot shim with a dedicated PMv2 → PMv1 DPI-aware desktop capture path. Compilation uses an isolated ASCII temp directory so non-ASCII Windows user profiles no longer break `Add-Type`, while incorrect DPI contexts still fail closed instead of returning a cropped desktop.
+- Propagates the real DSH session identity through vision child calls and isolates OpenCode Go wire affinity from internal Session identity. Direct Go requests without a stable session fail closed, existing upstream `x-opencode-session` headers remain authoritative, and benchmark traffic uses isolated synthetic affinity rather than contaminating user sessions.
+- Bounds the user-facing lifetime of vision tools across Host attachment saves by combining the ambient turn signal, Host execution signal, and live `visionTaskTimeoutMs` deadline. Late plugin work observes the spent signal even though the Host attachment store itself has no physical cancellation primitive.
+- Keeps `visionTaskTimeoutMs` hot: Settings changes are read on the next invocation without restarting DSH or re-registering tools.
+
+## DSH stable / preview compatibility
+
+- Adds exact compatibility evidence for DSH `0.1.2-rc.1` and `0.1.3-alpha.2`, including real Host contracts, pi-ai wire behavior, Session-v2 restart coverage, cold Vision-toggle browser smoke, and alpha mixed generic-file paste lifecycle.
+- Splits scheduled release canaries into npm `latest` (stable) and npm `alpha` (preview). These moving canaries automatically test newly published DSH trains while fixed exact-version gates preserve reproducible compatibility evidence.
+- Hardens bitmap normalization and alpha mixed paste so MIME/extension mismatches, text+image+generic-file combinations, and duplicate lifecycle delivery cannot silently corrupt attachment intake.
+
+## Security, discovery, and diagnostics
+
+- Separates public Host support policy from compatibility verification evidence. DVR 2.1.x keeps `0.1.0-rc.8` as its public minimum and `0.1.2-rc.1` as the current stable Host, while exact preview evidence and moving npm canaries are reported separately and never become an implicit support promise.
+- Removes secret-derived data from live-model route fingerprints and from persisted background AUTH stops. Credential rotation is handled by the current `credentials/reference-updated` event with legacy-event compatibility, immediately invalidating stale evidence and revalidating with the new credential.
+- Makes unattended background failures quieter and more accurate: authentication, protocol, and rate-limit failures share bounded transport-scope cooldowns instead of rotating through sibling models/axes every short gap, while ordinary network/timeout failures remain narrowly axis-scoped.
+- Treats token-authenticated DSH Web correctly in Doctor. A blanket `401` now means “runtime reachable, browser authentication required, route health unknown” instead of a false route failure; Doctor does not bypass the Host’s signed-cookie boundary.
+- Closes the remaining CodeQL findings without dismissing them; current Code Scanning is clean.
+
+## Validation
+
+- Covered by Node 22/24, DSH rc.6/rc.7/rc.8 contracts, exact stable `0.1.2-rc.1`, exact preview `0.1.3-alpha.2`, Windows Node 24 screenshot runtime, provider transport, routing parity, Session surfaces, real browser lifecycle gates, and CodeQL.
+- Local release-candidate verification completed with the full test suite at zero failures, contract tests at zero failures, and backend runtime policy coverage green.
+- No Settings migration is required. Restart DSH Web/Desktop after upgrading so the new runtime and browser-side compatibility logic are loaded.
+
+## Upgrade
+
+Upgrade to 2.1.4 and restart DSH Web/Desktop. Existing Vision Router settings remain compatible.

package/docs/releases/v2.1.5.md

@@ -0,0 +1,41 @@
+# v2.1.5
+
+DVR 2.1.5 is a compatibility, reliability, and release-hardening patch. It moves the fixed stable evidence to DSH `0.1.5-rc.1`, keeps exact preview evidence on `0.1.5-alpha.2`, fixes live Vision-twin reconciliation and wrapped-model switching, and modularizes the oversized Core runtime without changing the public 2.1.x routing model or minimum Host floor.
+
+## DSH 0.1.5 stable / preview compatibility
+
+- Supports the current npm stable Host `0.1.5-rc.1` while keeping DSH `0.1.0-rc.8` as the public minimum for DVR 2.1.x. Exact `0.1.5-alpha.2` coverage remains preview verification evidence only, not a blanket preview-support promise.
+- Admits the exact verified `0.1.5-alpha.1`, `0.1.5-alpha.2`, and `0.1.5-rc.1` Host peers without using a broad semver range that would silently promise compatibility with future untested DSH releases.
+- Moves the required current Host contract, Node 22/24 release-family contracts, exact source checks, and real Host + Chromium browser gates onto `0.1.5-rc.1`; the exact preview gates move to `0.1.5-alpha.2`.
+- Pins exact source evidence to immutable upstream commits and verifies the checkout SHA before running attachment normalization, LLM adapter, session/remotes, and Web compatibility contracts on Ubuntu, macOS, and Windows.
+- Keeps the existing Web `@deepseek-ai/dsh-client-modules` row explicitly waiting for the official `webServer` carrier. Current `0.1.5-rc.1` and `0.1.5-alpha.2` still require this compatibility overlay.
+- Adds a three-state overlay lifecycle contract plus moving upstream watch: `shim-required` keeps the overlay, `retire-ready` fails and requires deliberate retirement once DSH owns the dependency, and `dangerous-drift` fails closed if the upstream row changes incompatibly.
+
+## Vision-mode and live-provider reliability
+
+- Preserves Vision mode when the user switches to another model that has a matching hidden Vision Router wrapper in the same visible source provider. Cross-provider switches or targets without a wrapper still leave Vision mode, and DSH's image-session model guards remain authoritative.
+- Treats `wrappedProviders` as configuration intent rather than a snapshot of startup topology. Generated `<provider>-vision` twins are reconciled against the live provider registry: dormant sources do not materialize twins, newly mounted providers gain them, removed providers withdraw them, and provider/model presentation metadata refreshes atomically.
+- Reuses the bounded adapter-update coalescer for synchronous registry events so live provider churn converges without duplicate registrations, re-entrant loops, or stale model filters.
+- Keeps the lower twin-image capability compatibility boundary tolerant of out-of-order registration for older Host shapes while preserving fail-closed ownership checks for Vision Router-owned routes.
+
+## Runtime architecture
+
+- Splits the oversized root runtime into `lib/core-primitives.js` and `lib/sharp-runtime.js` while keeping `Config`, `apply`, Host composition, and public exports owned by the existing entry point.
+- The modularization is behavior-preserving: no settings migration, route rename, tool-schema change, or public API change is introduced. A permanent architecture contract prevents the extracted primitives from drifting back into a monolithic entry file or creating a second runtime owner.
+
+## Security and release hardening
+
+- Updates the development `sharp` runtime past the libheif advisory while keeping the shared-Host peer contract at `sharp >=0.35.3 <1`, so the security fix does not raise the public Host floor.
+- Reworks the trusted PR impact shadow so `pull_request_target` never checks out PR code. The classifier is fetched from the trusted base commit, size-bounded, and verified against its Git blob identity before execution; permissions remain read-only.
+- Adds deterministic adversarial security fuzzing, dependency review, OpenSSF Scorecard coverage, Private Vulnerability Reporting guidance, and stronger immutable release verification.
+- Expands audited browser-impact triggers so client preludes, model-visibility boundaries, Web modules, Settings client surfaces, and exact compatibility modules cannot change without the corresponding browser/source gates running.
+
+## Validation
+
+- Release-candidate coverage includes Node 22/24, DSH rc.6/rc.7/rc.8 compatibility contracts, current stable `0.1.5-rc.1`, exact preview `0.1.5-alpha.2`, Ubuntu/macOS/Windows exact-source contracts, Windows screenshot runtime, host-sharp on all three desktop OSes, routing parity, native multimodal cold resume, large-image resource stress, deterministic hostile-input fuzz, dependency review, CodeQL, and real Chromium lifecycle gates for both exact stable and preview Hosts.
+- The moving release-channel canary also resolves npm `latest` and `alpha` independently so a newly published DSH train is detected before the fixed release evidence is deliberately advanced.
+- No Settings migration is required. Restart DSH Web/Desktop after upgrading so the updated Host and browser compatibility logic is loaded.
+
+## Upgrade
+
+Upgrade to 2.1.5 and restart DSH Web/Desktop. Existing Vision Router settings remain compatible.

package/docs/v2-capability-routing.md

@@ -156,17 +156,26 @@ intentional: standing background authority is the user's permission to verify
 capability within the selected local/free/paid cost boundary, not permission to
 trust possibly stale Host modality metadata as ground truth.
 
-Transient failure state is scoped to the exact deployment fingerprint plus model
-and axis. Network, timeout, and rate-limit conditions receive retry backoff.
-Clear deployment-level non-retryable failures such as authentication failure,
-unavailable model, and unsupported protocol are persisted for the same exact
-fingerprint and stop unattended measurement across axes, including after process
-restart. Visual-proof and Benchmark-infrastructure failures remain axis-scoped;
-they do not manufacture a text-only verdict or disable other axes. An explicit
-image-input rejection is persisted separately as a measured text-only verdict.
-Ordinary settings refreshes, adapter notifications, and process restart do not
-silently clear these same-fingerprint stops. A changed deployment fingerprint
-creates a new evidence scope, and an explicit successful Test Vision clears the
+Failure lifetime follows the narrowest authority that can explain the failure.
+Timeout, network, visual-proof, and Benchmark-infrastructure failures remain
+model/axis-scoped, so one failed axis does not suppress another axis or an
+independent route. Authentication and unsupported-protocol failures apply to the
+same transport scope (provider + endpoint + protocol + credential reference), and
+rate-limit backoff is shared by sibling models on that same scope, preventing an
+invalid or throttled account/endpoint from rotating through every model and axis
+at the normal 15-second background gap.
+
+Authentication stops are process-local and bounded; Vision Router never persists
+an API-key value or deterministic derivative just to recognize a later key
+rotation. Current `credentials/reference-updated` and legacy
+`credentials/updated` notifications synchronously revoke the in-memory AUTH stop
+and rescan with the new credential. Unsupported-protocol and unavailable-model
+stops remain bounded persistent evidence (the former also suppresses sibling
+models on the same transport; the latter stays model-specific). Visual-proof and
+Benchmark-infrastructure failures do not manufacture a text-only verdict or
+disable other axes. An explicit image-input rejection is persisted separately as
+a measured text-only verdict. A changed deployment fingerprint creates a new
+evidence scope, and an explicit successful Test Vision clears the corresponding
 same-fingerprint stop. Public background status exposes only a sanitized failure
 class/code; raw provider responses and credentials are not published to the
 browser.