dsh-vision-router 3.0.3 → 3.0.4

package/README.md

@@ -17,7 +17,7 @@
 </p>
 
 <p align="center">
-  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.3.0"><img src="https://img.shields.io/badge/release-v2.3.0-5B4CF0?style=flat-square" alt="Release v2.3.0" /></a>
+  <a href="https://github.com/ysr666/dsh-vision-router/releases/latest"><img src="https://img.shields.io/github/v/release/ysr666/dsh-vision-router?label=release&color=5B4CF0&style=flat-square" alt="Latest stable release" /></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>
@@ -34,6 +34,8 @@
   <a href="https://dshmarket.com/p/ysr666/dsh-vision-router/">dsh-market</a>
 </p>
 
+<p align="center">Repository: <a href="https://github.com/ysr666/dsh-vision-router">GitHub (primary · issues, PRs and releases)</a> · <a href="https://atomgit.com/ysr666/dsh-vision-router">AtomGit (China mirror)</a></p>
+
 <p align="center">English · <a href="README.zh.md">中文</a></p>
 
 <p align="center">💬 <strong>QQ community group: 1105463028</strong></p>
@@ -42,15 +44,12 @@
 > **Data leaves your machine by default.** When a cloud vision model is used, Vision Router sends the image (or a derived crop), the vision prompt and related request metadata to that provider. A fresh install has an anonymous OVHcloud vision fallback enabled, so "free" and "no key" do **not** mean offline. Do not use the cloud chain for confidential, regulated or classified material. See [Data flow and strict local-only use](#data-flow-and-strict-local-only-use).
 
 > [!WARNING]
-> 📌 **Announcement (v3.0.3)**
+> 📌 **Announcement (v3.0.4)**
 >
-> **v3.0.3: presentation and proxy-boundary corrections.** Restored history and empty
-> `vision_present` results no longer steal the reader’s scroll position, while fresh presented
-> images still focus correctly on both the newer phase-based Host contract and the supported DSH
-> 0.1.5 lifecycle. Cookie-domain-style `.example.com` entries now follow the same proxy-host
-> policy as `*.example.com`, and the exact DSH 0.1.7 browser smoke again follows both
-> presentation-boundary owners. CI action pins were also refreshed; runtime dependencies and
-> supported Hosts are unchanged. [What’s new →](docs/releases/v3.0.3.md)
+> **v3.0.4: DSH alpha.5 verification and release hardening.** Exact Host/Chromium
+> gates passed for DSH `0.2.1-alpha.5`; CI supply-chain actions were refreshed.
+> The public DSH support range stays unchanged. Future `0.2.1-rc.1` is not
+> yet independently verified. [What’s new →](docs/releases/v3.0.4.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" />
@@ -207,7 +206,7 @@ With “👁 Vision” enabled, paste or upload an image normally. By default th
 
 If the session already contains images, DSH may reject switching from a vision wrapper back to a text-only route. Vision Router does not bypass that Host rule: it shows a transient error using the same interaction style as the stock model selector, keeps the real current model unchanged, and leaves `👁 Vision ✓` reflecting the actual state so the session stays usable.
 
-The built-in anonymous OVH vision fallback is already configured, so normal image use needs no signup or API key. **The lower-right chat picker selects only the brain/conversation model**; vision backends do not belong there. Advanced options live under **Settings → Vision Router**: each vision-backend row may select any callable generative user model already configured under **Settings → Models**. DSH image-capability metadata is advisory only: undeclared or text-only-labelled models remain selectable and show a warning. At runtime Vision Router always tries the provider's registered DSH adapter first — including WebSocket, RPC and private transports — and falls through on a real failure. The direct compatibility bridge is used only when an http(s) OpenAI Chat Completions endpoint is positively identified. Leaving every user row empty is valid; the OVH chain remains the final fallback. `Vision HTTP` is an internal transport route, not a model group users should select.
+The built-in anonymous OVH vision fallback is already configured, so normal image use needs no signup or API key. **The lower-right chat picker selects only the brain/conversation model**; vision backends do not belong there. Advanced options live under **Settings → Vision Router**: each vision-backend row may select any callable generative user model already configured under **Settings → Models**. DSH image-capability metadata is advisory for backend selection, but an explicit text-only declaration makes the Host replace image pixels with text placeholders before adapter dispatch. Vision Router uses a direct pixel bridge only for verified http(s) OpenAI Chat Completions endpoints; otherwise that backend fails safely and the chain continues. WebSocket, RPC, Responses API and other native protocols use their registered adapters when image input is declared or modalities are unknown. If a custom model genuinely supports images, first enable **Image** under **Settings → Models → provider editor → Customized settings → Model options → Input types** when that Host control is available. On older Hosts without the control, set the provider-specific model field (`llm-pi-ai`: `input: [text, image]`; `llm-deepseek`: `inputModalities: [text, image]`) and reload the model configuration. Never claim image input for an endpoint that cannot accept images. Leaving every user row empty is valid; the OVH chain remains the final fallback. `Vision HTTP` is an internal transport route, not a model group users should select.
 
 ### See it in action
 
@@ -356,6 +355,8 @@ The settings card uses provider + model dropdowns; an empty model means every mo
 
 The Web profile registers a first-class **Settings → Vision Router** surface. Its General page keeps model choice and v2 routing authority together; Vision Strategy, Local & Device, Advanced and Diagnostics separate tool behavior, local backends, sensitive/performance controls and troubleshooting.
 
+**Reverse proxy deployments:** Preserve the original browser-facing `Host` when forwarding to DSH, as required by [upstream DSH](https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/docs/user/guide/public-deployments.md). A remote request forwarded over loopback must not become a *local-machine-only* request. Proxy-marked loopback requests are denied local-only Vision Router capabilities; proxies that rewrite `Host` to localhost **and strip all forwarding metadata cannot be reliably identified by the current Host API**. See [remote settings security](docs/remote-settings.md) and [Issue #680](https://github.com/ysr666/dsh-vision-router/issues/680).
+
 - **Vision model chain**: the real image-capable models used by `vision_describe` and friends; the built-in free chain remains the final fallback;
 - **Model selection**: keep the configured order, or explicitly enable capability-aware Auto with Balanced / Quality / Speed / Local preference;
 - **Background capability data**: `off`, `local-free`, or `all`; this is separately authorized and never turns on merely because Auto was enabled;
@@ -460,6 +461,8 @@ ollama pull qwen2.5vl
 
 ## Install and lifecycle
 
+**Source developers:** use [Web development watch, Live Reload and native HMR](docs/development/web-live-reload.md) with an isolated DSH profile. This workflow is separate from packaged installation and does not enable Desktop HMR.
+
 ### Install
 
 Normal npm/npx install — one command:

package/README.zh.md

@@ -17,7 +17,7 @@
 </p>
 
 <p align="center">
-  <a href="https://github.com/ysr666/dsh-vision-router/releases/tag/v2.3.0"><img src="https://img.shields.io/badge/release-v2.3.0-5B4CF0?style=flat-square" alt="Release v2.3.0" /></a>
+  <a href="https://github.com/ysr666/dsh-vision-router/releases/latest"><img src="https://img.shields.io/github/v/release/ysr666/dsh-vision-router?label=release&color=5B4CF0&style=flat-square" alt="Latest stable release" /></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>
@@ -34,6 +34,8 @@
   <a href="https://dshmarket.com/p/ysr666/dsh-vision-router/">dsh-market</a>
 </p>
 
+<p align="center">代码仓库：<a href="https://github.com/ysr666/dsh-vision-router">GitHub（开发主仓库、Issue、PR及版本发布）</a> · 国内 AtomGit 托管：<a href="https://atomgit.com/ysr666/dsh-vision-router">AtomGit 镜像</a></p>
+
 <p align="center"><a href="README.md">English</a> · 中文</p>
 
 <p align="center">💬 <strong>QQ 用户交流群：1105463028</strong></p>
@@ -42,13 +44,12 @@
 > **默认配置会让数据出网。** 使用云端视觉模型时，Vision Router 会将图片（或由它裁剪出的局部）、识图提示词及相关请求元数据发送给对应供应商。新安装默认开启 OVHcloud 匿名视觉兜底，因此“免费”和“免 Key”不等于离线。涉密、涉案、内部或其他受限材料请勿使用云端链路。详见[数据流向与严格纯本地配置](#数据流向与严格纯本地配置)。
 
 > [!WARNING]
-> 📌 **公告（v3.0.3）**
+> 📌 **公告（v3.0.4）**
 >
-> **v3.0.3：修正图片呈现与代理边界。** 恢复历史会话和空的 `vision_present` 结果不再抢走滚动位置，
-> 新生成的图片仍会在新版 phase 生命周期与受支持的 DSH 0.1.5 旧生命周期上正确聚焦；
-> cookie-domain 风格的 `.example.com` 现在与 `*.example.com` 遵守同一套代理主机规则；
-> DSH 0.1.7 精确浏览器 smoke 也重新跟随两个 presentation-boundary owner。CI Action 固定版本同步更新，
-> 运行时依赖和 Host 支持范围均不变。[查看完整更新 →](docs/releases/v3.0.3.md)
+> **v3.0.4：DSH alpha.5 兼容验证与发布门禁加固。** 已通过 `0.2.1-alpha.5` 的
+> 精确源码、三平台 Host 与真实 Chromium 验收，并更新 CI Action 固定 SHA。
+> 原有 DSH Host 最低支持范围保持不变；`0.2.1-rc.1` 待正式发布后另行验收。
+> [查看完整更新 →](docs/releases/v3.0.4.md)
 
 <p align="center">
   <img src="assets/vision-demo.gif" width="640" alt="演示：粘贴图片，Agent 用 vision_ground / vision_crop / vision_pixel_diff 定位发送按钮并给出坐标" />
@@ -203,7 +204,7 @@ pnpm dsh plugin --profile web add dsh-vision-router
 
 如果当前 session 已经包含图片，DSH 可能拒绝从识图 route 切回不接受图片的纯文本 route。此时 Vision Router 不绕过 Host 约束：会显示与原生模型选择器一致的临时错误提示，真实模型保持不变，`👁 识图 ✓` 也继续反映真实状态，可继续使用或稍后重试。
 
-默认已经有内置 OVH 匿名视觉兜底，无需注册、无需 Key。**聊天页右下角只选择“脑子/会话模型”**；视觉模型不要在那里选。高级配置在 **设置 → Vision Router**：视觉后端链每一行都可以选择 **设置 → 模型** 中任意可调用的生成式用户模型。DSH 的图片能力声明现在只作提示：未声明图片能力、甚至被标成仅文本的模型也会列出并给出警告。运行时永远先通过该供应商已注册的 DSH adapter 实际调用，因此 WebSocket、RPC 和私有协议都保留原生传输；只有明确识别为 http(s) OpenAI Chat Completions 的渠道才可能进入 HTTP 直连兼容兜底。实际调用失败后自动尝试下一后端；一行都不填也可以，OVH 免费链会固定在最后兜底。插件内部的 `Vision HTTP` 只是传输实现，不是用户需要选择的模型组。
+默认已经有内置 OVH 匿名视觉兜底，无需注册、无需 Key。**聊天页右下角只选择“脑子/会话模型”**；视觉模型不要在那里选。高级配置在 **设置 → Vision Router**：视觉后端链每一行都可以选择 **设置 → 模型** 中任意可调用的生成式用户模型。DSH 的图片能力声明对**后端选择**只作提示：未声明图片能力或被标为仅文本的模型仍可选择，并会显示警告。但实际分发时，DSH 会把明确声明为仅文本模型的图片转换为文本占位符。此时 Vision Router 只有在确认渠道为 http(s) OpenAI Chat Completions 时才会通过直连兼容桥传送图片；否则会安全地判定该后端失败并尝试下一后端，避免把只收到 SHA 文本的回复误判为识图成功。WebSocket、RPC、Responses API、Anthropic 等协议在 Host 声明支持图片（或未声明输入模态）时仍走注册的原生 adapter。如果自定义模型确实支持图片但被 Host 标为仅文本，请优先在 DSH **设置 → 模型 → 对应供应商 → 自定义设置 → 模型选项 → 输入类型** 中勾选**图片**（Host 提供该选项时）。旧版 Host 没有此选项时，请在相应模型配置中声明正确字段：`llm-pi-ai` 使用 `input: [text, image]`，`llm-deepseek` 使用 `inputModalities: [text, image]`，然后重新加载配置；不支持图片的模型不要添加该声明。一行都不填也可以，OVH 免费链会固定在最后兜底。插件内部的 `Vision HTTP` 只是传输实现，不是用户需要选择的模型组。
 
 ### 实际效果
 
@@ -352,6 +353,8 @@ vision_long_screenshot_ocr image="chat-log.png" chunkHeight=1200 overlap=120
 
 Web profile 现在提供一级 **设置 → Vision Router** 页面。常规页把识图模型与 v2 路由授权放在一起；「识图策略 / 本地与设备 / 高级 / 诊断」分别承载工具行为、本地后端、敏感/性能设置和排障。
 
+**反向代理部署须知：**遵循[DSH上游部署要求](https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/docs/user/guide/public-deployments.md)，代理转发时必须保留浏览器原始 `Host`，不能把远程访问改写成 `localhost` 后冒充“本机专属操作”。带常见代理转发标记的回环请求将失去Vision Router本机操作权限；但代理如果同时改写 `Host` 且抹掉全部来源信息，现有Host接口仍无法可靠辨别。参见[远程设置安全说明](docs/remote-settings.md)及[Issue #680](https://github.com/ysr666/dsh-vision-router/issues/680)。
+
 - **识图模型链**：`vision_describe` 等视觉工具真正调用的图片模型，内置免费链固定作为最终兜底；
 - **模型选择方式**：继续按配置顺序，或显式开启能力感知 Auto，并选择「综合 / 质量 / 速度 / 本地」偏好；
 - **后台补充能力数据**：`关闭 / 仅本地与免费 / 所有模型`，独立授权，不会因开启 Auto 自动开启；

package/cordis.patch.yml

@@ -19,25 +19,29 @@
   name: '@deepseek-ai/dsh-client-modules'
   inject: [webServer]
 
-# DSH rc.6 至 0.1.5-rc.2 的 Web bundle 里，Connection provider row 只声明
-# webRuntime，但 HostConnectionService.rpc/fetch 的 accessor 会把调用 owner
-# 追踪回这个 provider fiber；rpc.handle() 最终又通过 owner.webServer.register()
-# 挂载路由。因此仅在 DVR 的调用 child fiber 注入 webServer 仍不足以覆盖
-# Cordis Service shadow 语义（issue #478 / Desktop 2.0.9 可稳定复现）。
+# DSH 0.1.x / 0.2.0-rc.2 Connection 的 Host owner 必须注入 webServer
+# （issue #478），但 0.2.1-alpha.2 已移除 webRuntime、改为 webStartup。
+# 不要静态引用任一代独有的 webRuntime：它会使新 Host 必需服务永远待定。
 #
-# 保留官方既有 webRuntime 依赖，并让 Connection provider 本身同时等待
-# webServer。这样不改 connection config / trustedHosts，不复制 RPC 协议或鉴权，
-# 也不改变非 Web surface。exact-source contract 会监控上游 row；官方一旦
-# 自己拥有 webServer，此 shim 必须随支持窗口审计退休，避免覆盖未来新增依赖。
+# 本层统一让 Connection 在 webServer、webStartup 及 DVR 私有 ready gate
+# 均就绪后启动；ready gate 在旧 Host 等官方 webRuntime（含 bind-derived
+# LAN authorities），在新 Host 直接读取官方 webStartup.trustedHosts。
+# trustedHosts 只转交 Host 授权列表，不自行扩大、合并或猜测网络信任；
+# Cookie、/api 和 RPC 仍归官方 Connection 所有。Host 新增配置项时，
+# exact-source contract 必须拒绝未经审查的整段 config 覆盖。
 - id: connection
   name: '@deepseek-ai/dsh-client-connection'
-  inject: [webRuntime, webServer]
+  inject: [webStartup, webServer, visionRouterWebConnectionReady]
+  config:
+    trustedHosts: !!js ctx.visionRouterWebConnectionReady.trustedHosts
 
 # 挂载插件行。默认保持完整视觉工具表常驻（issue #81）：虽然渐进挂载可以
 # 少发一小段工具 schema，但图片轮首次扩展工具列表会改变请求前缀，可能让
 # 长会话的 provider KV/prefix cache 整体失效。高级用户仍可在 profile /
 # composition 补丁中显式把 progressiveTools 改回 true（启动期配置）。
 - insert:
+    - id: vision-router-web-connection-ready
+      name: './presets/web-connection-ready/index.mjs'
     - id: vision-router
       name: dsh-vision-router
       config:

package/docs/architecture/dsh-0.2.1-alpha.2-compat.md

@@ -0,0 +1,41 @@
+# DSH 0.2.1-alpha.2 compatibility audit (2026-10-09)
+
+## Identity and scope
+
+- Upstream **tag**: `dsh-v0.2.1-alpha.2`.
+- Annotated tag object: `6851e496285b2c9670066fdd142e7e46da586649`; peeled **commit**: `d743267388641bc76f17c45ce8b4c231aed1d32c`.
+- Previous reviewed alpha: `dsh-v0.2.1-alpha.1@5badb15009ae1756c3afe0ae0cef1faafc290ccc` (PR #645).
+- The upstream tag exists, but its GitHub Release and npm alpha dist-tag were **not confirmed published** when this work began. Treat exact source as the test target, not floating npm resolution.
+- Keep DVR's existing 0.1.x minimum, current 0.2.0-rc.2 support evidence, 0.2.x peer bounds, and package version unchanged.
+
+## Changes requiring a real Host gate
+
+1. **Build tooling**: DSH root `packageManager` changed from `pnpm@11.7.0` to `pnpm@11.28.5`. DVR remains pinned to its own package manager. Explicitly validate the upstream manifest and execute Host builds with the new manager; do not rewrite DVR's published package requirements.
+2. **Settings/client**: the Host reorganized plugin settings and its experimental catalog. Verify plugin settings mount, save, refresh, and readback in a real Chromium browser; do not infer support from source-level slot presence.
+3. **Web transport**: WebServer gained native TLS and concrete bind-address handling; Desktop Host now constructs URLs using `webServer.protocol` and may request OS-assigned ports. Verify authenticated Host/plugin routes, proxy authority, and injected Desktop client. Existing plaintext smoke does not establish support for every custom TLS topology.
+4. **LLM/model routing**: Host `prepareCall` supports a third `configure` callback and revised call-control binding; model visibility is also changing. Verify the registered adapter, image input and fallback paths. Existing DVR use of `prepareCall(config, signal)` remains positional compatibility pending executable checks.
+5. **Session/attachments**: Session schema/version compatibility and plugin record behavior changed. Keep source admission, durable image ownership, cold-restart, and mixed-attachment tests.
+6. **Bundle lifecycle**: Host package and dependency mappings continue changing. Verify cold startup, browser injection, multi-plugin ordering, and recompose through real DSH rather than mocks.
+
+## Acceptance gate
+
+The existing `.github/workflows/dsh-alpha-settings-host-gate.yml` performs:
+- immutable alpha source contract and Host-owned Sharp on Linux/macOS/Windows;
+- official Host peer admission and proxy egress;
+- macOS Desktop renderer;
+- Windows Desktop auth on Node 22 and Node 24, plus renderer/multi-plugin adversaries;
+- real Web + Chromium cold Vision, Settings mount/save/reload/readback, mixed attachments, and bundle recomposition.
+
+The pin is intentionally **not** a blanket support declaration: a PR with pending/failed gates does not authorize saying alpha.2 is validated. No release, tag, dependency bump, production workaround, or merge is part of this audit PR. Only add a runtime workaround after reproducing a genuine interface regression.
+
+## Observed blockers (2026-10-09, exact-source gate)
+
+- **P1 / real compatibility break**: the `connection` row fails to activate under alpha.2 (`missing webRuntime`). Alpha.2 replaces its upstream `inject: [webRuntime]` with `inject: [webStartup]`, while DVR still overlays `inject: [webRuntime, webServer]`. Older supported Hosts still use `webRuntime` and materialize extra LAN trust information there. A global rename does not preserve this old-Host contract. The PR **must remain Draft and unmerged** until a version-aware solution passes both old and new real Host gates.
+- **Desktop CI fixture / independent**: Windows Node 22/24 originally failed required `desktop-product-telemetry` validation because the isolated test runner omitted Host-owned `DSH_CLIENT_VERSION`. Set that environment value to the exact Desktop release version in the fixture, retaining normal required-plugin validation and restoring the previous environment afterward. This change does not repair the Connection incompatibility.
+- The ordinary CI, security, architecture, native cold-resume, and exact old-Host checks passed on the earlier head; they are **not** evidence that alpha.2 real browser/desktop support has passed. The alpha2 end-to-end test must be rerun and fully green before merging.
+
+## Proposed corrective architecture (still requires green real-Host CI)
+
+The compatibility patch no longer installs an obsolete `webRuntime` dependency into the alpha.2 Connection row. It instead injects `webStartup`, `webServer` and a private readiness service. A legacy Host's native `webRuntime` is awaited before capturing its complete bind-derived LAN plus declared trust list; alpha.2 captures only native `webStartup.trustedHosts`. Both are detached, frozen and validated; Host Connection still owns every authentication and RPC action. Unexpected protocol, trust-list and upstream Connection-config drift fail closed.
+
+The sidecar must live under an independent private nested package root, `presets/web-connection-ready/package.json`, with a different package name and **no** `dsh.client` declaration. DSH 0.1.7 client-modules rejects two active Loader specifiers that resolve into the **same** client package, even when the second specifier only supplies a host service. A separate package identity prevents this duplicate-source startup failure without creating another browser client or adding an external runtime dependency. Both the older and the alpha.2 real-Host gates remain mandatory before merge.

package/docs/development/dsh-alpha3-compatibility.md

@@ -0,0 +1,36 @@
+# DSH 0.2.1-alpha.3 compatibility audit
+
+**Channel:** alpha/pre-release, not stable or next/rc. npm `latest` and `next` are still `0.2.0-rc.2`; npm `alpha` is `0.2.1-alpha.3`.
+
+**Immutable source:** `dsh-v0.2.1-alpha.3` → `2fbf4359b82fb94c03dcce0b831660d87f12ea5c`. Compared against alpha.2 `d743267388641bc76f17c45ce8b4c231aed1d32c`. npm publication: 2026-10-14 12:35:33 UTC; GitHub release: 2026-10-14 13:32:15 UTC. Upstream uses `pnpm@11.28.5`.
+
+## Compatibility review
+
+- **Host:** WebServer now exposes `getOrigin()` and makes `port` explicitly optional before listening. DVR does not directly depend on an early `webServer.port` read. The existing named-route registration/cleanup contract remains in place.
+- **LLM / model / image:** `LlmRuntime.imageRequestTarget()` newly calls the registered adapter's method without optional chaining. DVR's plain adapter objects do not inherit the new `LlmAdapter` default. The compatibility boundary therefore supplies the upstream normalized-image identity target (`width`, `height`, `maxBytes`) only for DVR-owned adapters on Hosts exposing that method. Explicit adapter implementations take precedence; frozen adapters use a scoped proxy. This is a real root-level runtime contract repair.
+- **Attachment:** The canonical image admission and normalization policy is still exercised against the exact Host's Sharp pipeline. No change to DVR's 20 MiB / 100 MP / 10,000 px policy.
+- **Session:** Upstream adds resource identity to session remote metadata and changes session-controller and chat projection code. The session event and persistence boundaries remain subject to exact-source and real-browser gates.
+- **Settings:** Credential precedence and Settings navigation changed. Newer Web shells expose Settings through the Account menu rather than a top-level Settings button; browser acceptance must follow the actual shell. Settings mount/save/reload/readback remains a mandatory gate.
+- **Bundle/HMR:** Source changes in `app-boot`, `hmr` and `web-app` require bundle recompose verification. The exact macOS run completed three recomposes with stable DVR routes.
+- **Web/client/Connection:** New connect/peer handshake and browser-auth paths require authenticated Desktop and Chromium tests. No unscoped Host-wide patch is introduced.
+- **Service injection:** Exact alpha.3 still uses `webStartup` for Connection readiness. The existing DVR overlay remains required; do not remove it or raise the minimum public Host support.
+
+## Verified locally (not a substitute for CI)
+
+- macOS Node 24 exact-source/Host-Sharp, Web Connection, peer admission and proxy egress: PASS.
+- DVR local tests: 1,770 + 28 + 41 passing; two platform-limited skips; zero failures.
+- macOS upstream full build: nine of nine gates PASS.
+- macOS Desktop renderer: functional Vision turn and Settings save/reload PASS.
+- macOS Desktop authenticated Host: token-to-cookie 303, authenticated index 200, missing API 404, DVR RPC 200.
+- macOS bundle recompose: three passes, route stable.
+- Windows Node 24 exact-source/Host-Sharp and upstream build: PASS.
+- macOS Web Settings browser lifecycle: PASS after locally adapting the acceptance selector to the Account menu. The browser acceptance helper now supports both the legacy Settings button and the newer Account-menu Settings entry, without changing shipped product behavior.
+- macOS cold Vision and mixed-attachment Web smoke could not automate the native directory picker; Linux Chromium remains the authoritative headless gate.
+
+## Release/merge hold
+
+The exact alpha.3 CI pin and repairs are reviewed through [PR #710](https://github.com/ysr666/dsh-vision-router/pull/710). Merge only after the PR cross-platform Linux/macOS/Windows exact-source/Host-Sharp, Windows Node 22/24, real Web+Chromium lifecycle, and related contract/adversarial gates pass on the final head. This compatibility PR does not authorize publishing. Keep the public minimum Host range and stable/next verification baselines unchanged.
+
+## Windows CRLF regression (local follow-up)
+
+On a real Windows Node 24 checkout with `core.autocrlf=true`, the pre-existing root-hardening test failed because exact client-source seam replacements assumed LF template literals. A focused source change now matches the same owned seam under CRLF without normalizing unrelated HTML or changing the Host; the original 9-test Windows root-hardening suite passes after rebuilding package artifacts. A new CRLF-specific regression also passes on macOS. Full Windows and Linux CI acceptance is still required before merging.

package/docs/development/dsh-alpha4-adaptation.md

@@ -0,0 +1,12 @@
+# DSH 0.2.1-alpha.4 adaptation
+
+Channel: alpha/pre-release (not stable or next).
+Upstream tag: `dsh-v0.2.1-alpha.4`.
+Exact upstream commit: `86a402200d95fecef4529d969836f1fe13c6cb0d`.
+Published to npm: 2026-10-15 13:08:08 UTC.
+GitHub release: 2026-10-15 13:40:02 UTC.
+Baseline: alpha.3 `2fbf4359b82fb94c03dcce0b831660d87f12ea5c`.
+
+Upstream changes include model reasoning levels, custom plugin index sources, `engines.dsh`-first plugin admission, Web/client release-change and HMR handling, command editor fixes, and developer tools UI. Keep the 0.1.5-rc.1 minimum and 0.2.0-rc.2 stable/next evidence unchanged. No automatic release.
+
+Technical gates pending.

package/docs/development/dsh-alpha4-validation-evidence.md

@@ -0,0 +1,29 @@
+# DSH 0.2.1-alpha.4 validation evidence
+
+**Channel:** alpha/pre-release only. npm `latest` and `next`: `0.2.0-rc.2`; npm `alpha`: `0.2.1-alpha.4`.
+
+**Exact source:** `dsh-v0.2.1-alpha.4` = `86a402200d95fecef4529d969836f1fe13c6cb0d`; previous alpha.3 = `2fbf4359b82fb94c03dcce0b831660d87f12ea5c`. npm publication 2026-10-15 13:08:08 UTC; GitHub release 2026-10-15 13:40:02 UTC. Upstream pnpm 11.28.5.
+
+## Compatibility audit
+
+- **Plugin admission:** Host now prioritizes `engines.dsh`, falling back to `@deepseek-ai/dsh-*` peer ranges. DVR declares both with the same support window and tests legacy `peers` and newer `requirements` refusal shapes. Public minimum remains `0.1.5-rc.1` for the 0.1.x train and `0.2.0-rc.2` for 0.2.x.
+- **Host, Session, Settings, attachment:** Exact upstream source blobs for core Session, SessionController, SettingsController, and local attachment index are unchanged from alpha.3. Existing exact Host-Sharp and session v4 admission contracts passed on alpha.4.
+- **Web/client/bundle:** New client module release-change and HMR logic, remotes events, plugin-market registration and Web bundle patches require real Chromium and bundle lifecycle checks. Three bundle recomposes passed with stable DVR routes.
+- **Model:** Custom model reasoning-level UI changed. Existing LLM index source blob is unchanged; adapter imageRequestTarget compatibility from alpha.3 is retained.
+- **Service injection:** Exact Connection source still requires `webStartup`; the DVR readiness shim remains required, without Host-global patching.
+
+## Local macOS evidence (Node 24.5.0)
+
+- DVR build/build:check: PASS. Focused manifest/Host tests: 89/89 PASS.
+- DVR full test command: 1,773 + 28 + 41 PASS, 1 platform skip, zero failures.
+- Exact alpha.4 DSH workspace install and full build: 9/9 build gates PASS.
+- Exact source + Host Sharp contract: PASS; peer admission: PASS; Connection trust-generation overlay: PASS; proxy egress: PASS.
+- Real Web+Chromium Settings mount/save/reload/readback: PASS (`vision-router`, one save, reload, two reads).
+- Bundle recompose: 3/3 PASS, process and DVR route stable.
+
+## Outstanding validation
+
+- macOS cold Vision fixture did not reach the native workspace picker (`Select Workspace Directory` timeout). This is a fixture/platform limitation, not a successful Vision test; Linux Chromium remains mandatory.
+- macOS Desktop renderer could not launch because Electron binary download failed; no Desktop pass is claimed.
+- Mixed attachment lifecycle and Node 22, Windows/Linux exact Host-Sharp, and adversarial CI remain pending.
+- No PR CI was run at the time of this note. Do not merge or publish on this evidence alone.

package/docs/development/dsh-alpha5-adaptation.md

@@ -0,0 +1,31 @@
+# DeepSeek Harness 0.2.1-alpha.5 exact-source adaptation
+
+- **Channel:** alpha/pre-release only; do not treat as stable or next/rc.
+- **Upstream tag / immutable commit:** `dsh-v0.2.1-alpha.5` / `1517a4dbca0a2789ff1d41ba439600f8547d23fa`.
+- **Published release:** 2026-10-16 12:23:28 UTC (2026-10-16 20:23:28 China time).
+- **Comparison baseline:** `dsh-v0.2.1-alpha.4` / `86a402200d95fecef4529d969836f1fe13c6cb0d`.
+- **Host pnpm:** 11.28.5; DVR package manager and support windows remain unchanged.
+
+## Compatibility review
+
+| Area | Alpha.5 change / contract to protect | Gate |
+| --- | --- | --- |
+| Host and plugin admission | No evidence requiring an admission-window bump; retain both `engines.dsh` and legacy DSH peers from alpha.4, minimum `0.1.5-rc.1` (0.1 train) and `0.2.0-rc.2` (0.2 train). | Exact evaluator admission/refusal, previous Host matrix |
+| Session and attachment | Session v4 producer-owned source, post-commit session/event ordering, exact Host Sharp normalization and mixed image/file attachment ingestion must remain valid. | Exact source/Host-Sharp, adversarial/contract, real Chromium mixed attachment |
+| Settings | Preserve Host-owned Settings mount/save/reload/readback and real on-disk persistence. | Real Web+Chromium Settings lifecycle |
+| Model / composer | New session-scoped `conversation.input.model.label` Slot is inline and non-interactive; existing `conversation.input.model` selection and DVR's `conversation.input.right` Vision toggle must coexist. | Exact Slot/renderer assertions + real cold/reload Vision |
+| Web and client | Skill cache now invalidates on `plugin-manager/changed`; account notice/UI layout changes must not disturb client attachment or Vision lifecycle. | Exact invalidation assertion + real Web/Chromium |
+| Terminal | New cached session-owned terminal inventory; ensure unrelated Vision/Settings interactions survive terminal sidebar changes. | Exact source inventory smoke + Chromium |
+| Bundle | Preserve DVR route registration and stable recompose behavior. | Three consecutive bundle recomposes |
+| Service injection | Retain the bounded `webStartup` readiness shim where required; no Host-global monkeypatch or opportunistic injected service widening. | Web Connection overlay and Desktop Host injection |
+
+This change **only advances the alpha exact-source gate** and adds focused upstream assertions. It does not declare alpha.5 verified before final-head CI passes, does not change stable/next pins, and does not publish a DVR release.
+
+## Required acceptance evidence (not yet green at branch creation)
+
+- Node 22 and Node 24, Linux/macOS/Windows exact source and Host-Sharp.
+- Native Windows Desktop Node 22/24 and macOS Desktop renderer (subject to Electron availability).
+- Real DSH Web + Chromium: cold Vision, mixed attachments, Settings mount/save/reload/readback, three bundle recomposes, Desktop service injection.
+- Existing DSH support-window, contract, and adversarial/security checks.
+
+Investigate CI failures at their actual owners, repair root causes only, rerun on the final head, and leave the PR draft until green. Do not use workflow_dispatch as a substitute for PR CI or require Copilot review.

package/docs/development/web-live-reload.md

@@ -0,0 +1,157 @@
+# Web Client development: staged builds, Live Reload and native HMR
+
+> **Status (2026-10-12):** The developer-only `pnpm dev:web` workflow,
+> upstream native Web HMR and the fail-closed staged build publisher are
+> merged in `main` (Issues/PRs #697–#700). The production `pnpm build`,
+> released plugin behavior, Host authority and Desktop entry are unchanged.
+
+`pnpm dev:web` is an **opt-in developer tool**. It watches the canonical
+`src/` tree and relevant build scripts, checks the generated maintenance
+Client code, builds the same 183 artifacts into an isolated temporary directory,
+verifies the source-to-artifact map **before publication**, and atomically
+publishes the entry files with `lib/client.js` **last**. Builds never overlap.
+A compile/verification failure leaves every previously published artifact
+untouched, preventing upstream DSH's independent Client-HMR stat watcher from
+mistaking an incomplete build for a new revision. Watcher errors do not kill
+future builds. The formal `pnpm build` / release packaging remains unchanged.
+
+Start in build-only mode:
+
+```sh
+pnpm install --frozen-lockfile
+pnpm dev:web
+```
+
+### Optional automatic full-page Web reload
+
+Start a **throwaway DSH Web profile** using the plugin entry from the *same*
+checkout (`entry.js` or the appropriate compiled package entry), not a stale
+installed npm tarball. Then, in the checkout's developer terminal:
+
+```sh
+export DVR_DEV_WEB_URL='http://127.0.0.1:PORT/'
+export DVR_DEV_CHROME='/absolute/path/to/Google Chrome'
+pnpm dev:web
+```
+
+The script opens a private Chrome window after the first successful build and
+performs a full-page reload after subsequent successful builds. Authenticate
+in that window if DSH asks you to. An isolated DSH token URL can be supplied
+via the environment variable, but **never paste it into a committed script or
+logs**. The program does not print the URL. `DVR_DEV_HEADLESS=1` is available
+for automated smoke tests. Only HTTP loopback addresses are allowed; remote
+web pages, remote debugging ports, and external browser requests are blocked.
+Chrome is controlled through its private CDP stdio pipe, not via a WebSocket
+listener exposed to other users. Stop the watcher with Ctrl+C to close Chrome.
+
+In the default **`page` mode** this is full-page Live Reload, not module-level
+HMR: the page and React component state initialize from scratch. The opt-in
+`native-hmr` mode described below instead uses DSH's own Client Modules
+fiber replacement without page navigation; plugin-local React state can still
+reset. Vision Router also has structured `webserver/index-inject` and
+`tapIndex()` script carriers protected by a per-page one-shot registry.
+Native HMR does **not** hot-replace those injected carrier scripts. Do not
+manually re-inject them; restart the isolated Host/fresh page for those
+changes. No production carrier registry, package export, or Host authority
+changes are part of this feature.
+
+If `src/lib/client-maintenance-actions.js` changes, the embedded generated
+section in `src/lib/client.js` must be synchronized deliberately by running
+`pnpm client:sync` before the watcher can pass the embedded-source check.
+It is deliberately **not** rewritten by the watcher: an automated source
+rewrite would conceal unreviewed Client changes.
+
+**Scope:** Web-only development. Desktop's custom scheme is unverified and
+must not be treated as HMR. Source changes that affect Host runtime services
+or settings require an isolated Host restart; reloading Chrome alone does not
+reload Host modules. Run established Settings and Issue #684 ON→OFF real-Host
+regression gates separately before claiming all-round compatibility.
+
+## Choose the development mode
+
+| Mode | How to run | Behavior |
+| --- | --- | --- |
+| Build only | `pnpm dev:web` | Rebuild and verify artifacts without launching Chrome |
+| Full-page Web reload | Set `DVR_DEV_WEB_URL` and `DVR_DEV_CHROME` | Refresh private Chrome after successful build (default `page` mode) |
+| Native DSH Web HMR | Same settings plus `DVR_DEV_RELOAD_MODE=native-hmr` | DSH replaces the Client factory without navigating the page |
+
+Native mode requires DSH's Web boot HMR plugin and the
+`/plugins/events` SSE endpoint. If unavailable, use
+`DVR_DEV_RELOAD_MODE=page`; the helper will not silently claim native HMR.
+Only HTTP loopback URLs are permitted. Never commit token-bearing URLs.
+
+## Upstream native Web HMR (opt-in)
+
+DSH 0.2.0-rc.2 already provides its own Web plugin HMR transport:
+`@deepseek-ai/dsh-client-hmr` stat-polls the canonical built `lib/client.js`
+and publishes `rebuilt` events through `/plugins/events`. The browser Client
+Modules controller invalidates and replaces the plugin fiber, with **no page
+navigation**. It is not React Fast Refresh: local component state inside the
+plugin resets, while unrelated Web page/session state survives. Electron's
+Desktop scheme does **not** use this SSE transport.
+
+With the isolated DSH Web Host pointing to this checkout's Client artifacts
+and the usual `DVR_DEV_WEB_URL` / `DVR_DEV_CHROME` variables, use:
+
+```sh
+export DVR_DEV_RELOAD_MODE=native-hmr
+pnpm dev:web
+```
+
+The dev controller probes the HMR row in DSH's boot manifest and an
+HTTP 200 `text/event-stream` response from `/plugins/events`. If either is
+unavailable, it closes private Chrome and reports an error rather than
+pretending to hot-swap the UI. `DVR_DEV_RELOAD_MODE=page` (the default) keeps
+the older full-page fallback.
+
+**Important DVR boundary:** native HMR replaces the DSH `dsh.client` factory,
+not the Host-injected `client-script-carrier` bootstrap JS/CSS or server-side
+settings bridges. The latter retain their one-shot per-page fence and may
+need a Host restart and a fresh page to update. Do not claim that changing
+Host-side JS automatically updates those browser carriers. Do not interpret
+HMR as fixing Issue #684's Host selection/recovery bug; that needs its own
+real Desktop ON→OFF evidence.
+
+### Why a staged developer build is necessary
+
+The production artifact builder removes `lib/`, `entry.js`, and `index.js`
+before compiling to their final paths. That is acceptable for CI/release
+packaging, but **unsafe as a development HMR trigger**: a TypeScript compiler
+failure can leave deleted `.js` outputs and still change the live `client.js`
+file metadata while upstream DSH polls it. The developer watcher instead calls
+`scripts/dev-staged-build.mjs` to compile into a temporary folder under the
+checkout, validates the complete map using
+`verify-source-artifact-map.mjs --artifact-root <stage>`, and publishes files
+with atomic rename operations. The watched Client entry is written last.
+
+The verified publication is not a full database transaction; a disk error
+halfway through publishing siblings can still need a clean rebuild/restart.
+No claim is made that Host runtime modules themselves are hot replaced.
+
+A real DSH 0.2.0-rc.2/Chrome/Node24 acceptance test covered:
+`src/lib/client.js` A→B through the dev watcher, invalid TypeScript compile
+with old B artifact unchanged, then repair B→C, without any browser navigation
+or unexpected JavaScript exceptions.
+
+
+## Acceptance summary and deliberate non-goals
+
+- Real isolated **DSH 0.2.0-rc.2 / macOS / Chrome / Node 24**: 30
+  consecutive plugin Client swaps, one initial page navigation, no
+  unexpected JavaScript exceptions during valid swaps, and no growing CSS
+  style count in the observed run. A deliberately malformed bundle was
+  rejected and later replaced by a working one.
+- Full watcher-to-Host path: source A→B triggered native HMR in about 2.03s;
+  a deliberate TypeScript compilation failure left the B artifact and live
+  UI unchanged; restoring the source then built and hot-swapped C in about
+  2.16s without page navigation.
+- GitHub PR #700: all 16 compatibility/CI workflows passed, including
+  Node 22/24 and real DSH Host matrices. These checks do not certify
+  Desktop HMR, all future DSH releases, or long-running heap memory safety.
+- **Issue #684 remains a separate runtime problem.** HMR does not
+  fix or validate Desktop Vision ON→OFF recovery; its real-Host evidence
+  and implementation remain independent. Host-injected scripts and Settings
+  bridges are not Client-fiber hot-swapped.
+
+No new HMR loader architecture or public plugin release is required for this
+development workflow.

package/docs/releases/v3.0.4.md

@@ -0,0 +1,18 @@
+# v3.0.4
+
+Maintenance and DSH 0.2.1-alpha.5 compatibility-qualification release. No routing-runtime, schema, public-API, or minimum supported Host change.
+
+## Upstream qualification
+- Exact upstream DSH 0.2.1-alpha.5 SHA: `1517a4dbca0a2789ff1d41ba439600f8547d23fa`.
+- PR #713 passed Windows/macOS/Linux exact-source and Host-Sharp, Node 22/24, Windows/macOS Desktop, real `dsh web` + Chromium cold Vision, mixed attachments, Settings mount/save/reload/readback, bundle recomposition, service injection, and adversarial/legacy Host contracts.
+- Published Host window stays `>=0.1.5-rc.1 <0.2.0-0 || >=0.2.0-rc.2 <0.3.0-0`.
+
+## Supply-chain upkeep
+Consolidates upstream Action pin upgrades from #705–#709: setup-node 7.1.0, upload-artifact 7.0.2, Scorecard 2.5.0, CodeQL upload-sarif 4.38.3 and HOL scanner Action 1.2.786. The exact release-package evidence test is updated along with upload-artifact's pinned version; immutable tarball identity, trusted OIDC and provenance remain required.
+
+## RC1 scope and outstanding issues
+DSH 0.2.1-rc.1 has not yet been independently validated: semver admission is not proof of real-Host compatibility. After official release, record exact upstream tag/commit and rerun the full cross-platform source/Host/Chromium/Settings/attachment gate before claiming verified RC1 support.
+
+Issues #684 (historical intermittent Windows alpha2 Vision pointer loss), #703 (DSH Plugin Hub Windows package.json.lock writer contention) and #704 (billion-context coexistence requiring reproduction) remain tracked; none is represented as resolved by this maintenance-only package.
+
+No user configuration or data migration is required. Publication is a separate gated trusted-release workflow and is not performed by this preparation PR.

package/docs/remote-settings.md

@@ -9,3 +9,7 @@ DSH `trustedHosts` protects the browser carrier against Host/Origin/DNS-rebindin
 The transport contract differs across supported DSH generations without changing that security model. On the rc.8 Connection contract, Vision Router registers the dedicated channel with the required per-channel `{ authority: 'trusted-host' }` option. Newer Connection contracts expose the carrier-level `requestRejection()` / BrowserAuth fence and `rpc.handle()` no longer accepts a channel authority option; Vision Router feature-detects that carrier and registers with the modern two-argument form. The remote field allow-list and `allowRemoteSettings` gate remain authoritative in both cases.
 
 If DSH is behind Nginx, Caddy or another reverse proxy, forward `/vision-router-settings/*` to the same DSH origin in addition to the normal DSH routes. The UI detects a 404 on this channel and shows this requirement directly.
+
+**Reverse-proxy security:** Follow the [upstream DSH public deployment contract](https://github.com/deepseek-ai/deepseek-harness/blob/d743267388641bc76f17c45ce8b4c231aed1d32c/docs/user/guide/public-deployments.md): preserve the **browser-facing `Host`** on proxy requests; do **not** rewrite it to `localhost` or `127.0.0.1` when forwarding remote traffic to a loopback DSH listener. DSH Host/Origin checks and its signed browser session authenticate accepted requests, but do **not** attest that a user is physically local. Vision Router grants local-only diagnostics, permission changes and self-update tokens only to requests classified as local. It conservatively treats loopback TCP requests carrying `Forwarded`, `X-Forwarded-*`, `X-Real-IP`, `Via` or common client-IP proxy headers as **remote for local-only actions**, regardless of an apparent localhost `Host`.
+
+**Limit:** Forwarding headers can be absent, stripped or forged; they are only negative evidence, **never positive proof of physical-local origin**. An untrusted proxy that rewrites the browser `Host` to localhost and strips all forwarding evidence is indistinguishable from a genuine local browser using the current DSH Host request contract. Do not expose such a topology. Restrict upstream listener access, preserve external `Host`, configure DSH `trustedHosts` explicitly, and keep local-only actions on a direct trusted loopback UI. The broader local-presence attestation gap remains tracked in [Issue #680](https://github.com/ysr666/dsh-vision-router/issues/680).

package/docs/v2-capability-routing.md

@@ -73,13 +73,28 @@ plan, revoked Auto authority, or planner failure falls back to the current
 configured order. The temporary Auto order is isolated to one visual-tool call
 with `AsyncLocalStorage` and is restored automatically afterward.
 
-Host text-only metadata is advisory for a user-selected generative model. It is
-not treated as proof that the model cannot inspect images. **Test Vision** always
-tries the exact current dropdown selection when its live adapter can be invoked.
-If the user has explicitly enabled `backgroundBenchmarking`, eligible configured
-models are also actually measured within that cost scope even when Host metadata
-currently labels them text-only. The measured result, rather than the Host label,
-is the capability evidence used by Auto.
+Host text-only metadata is advisory for *selection* of a generative backend,
+not proof of the endpoint's real image capability. It is not, however, advisory
+to DSH's request projection: an explicit text-only declaration causes DSH to
+replace image pixels with text placeholders before the adapter is invoked.
+Vision Router bypasses that projection only for positively identified HTTP OpenAI
+Chat Completions bridges. For Responses API, WebSocket, RPC and other native protocols, a genuinely
+image-capable model must have Host image input declared; otherwise a visual
+request cannot safely reach its registered adapter. Where available, use
+**Settings → Models → provider editor → Customized settings → Model options →
+Input types → Image**, then save and reload the model configuration. This model
+editor control is documented in DSH
+[0.1.7-rc.1](https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.1.7-rc.1/packages/client/ui-settings-models/README.md)
+and [0.2.0-rc.2](https://github.com/deepseek-ai/deepseek-harness/blob/dsh-v0.2.0-rc.2/packages/client/ui-settings-models/README.md).
+For older Hosts without this control, set the provider-specific model field:
+`llm-pi-ai` uses `input: [text, image]`, while `llm-deepseek` uses
+`inputModalities: [text, image]`. Only declare image input for endpoints that
+actually accept image content. Unknown modalities still use the registered
+adapter first. **Test Vision** targets the exact dropdown model,
+but a text-only Host declaration without a safe bridge may yield an image-input
+failure rather than a valid visual measurement. Explicitly authorized background
+benchmarking has the same delivery constraint; only successful pixel-grounded
+measurements count as capability evidence for Auto.
 
 Structural non-generative exclusions remain hard boundaries: explicit measurement
 authority never turns an endpoint that cannot be invoked as a generative model
@@ -101,8 +116,9 @@ Auto-routing control.
   requests.
 
 A Host text-only label is shown as an advisory, not as a separate product mode.
-Quick/Full Benchmark may still send generated test images to verify the model
-when the user explicitly starts the Benchmark. The implementation may carry an
+Quick/Full Benchmark prepares generated test images when the user explicitly
+starts the Benchmark, but delivery still depends on the Host's model modalities
+or a verified compatible bridge. The implementation may carry an
 internal force flag for compatibility with older service guards, but users do
 not need to reason about a separate “Force Verify” workflow.