dsh-vision-router 2.2.8 → 3.0.0

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

@@ -1,62 +1,73 @@
-# DSH compatibility matrix
+# DSH compatibility matrix — DVR 2.3
 
-This document is the P0 compatibility baseline for dsh-vision-router 2.x.
+This document is the normative Host-evidence matrix for dsh-vision-router 2.3.
 
-The matrix is capability-based. Runtime code must feature-detect the seam it needs; it must not branch on a DSH version string merely to select a behavior. Version labels below name the CI fixtures that prove each capability.
+Runtime code remains capability-based: version labels below identify immutable CI evidence only. They must not become runtime version branches.
 
-## Gating fixtures
+## Support and admission policy
 
-| CI fixture | DSH package line | Role |
+DVR 2.3 supports the DSH 0.1.x line continuously from the first admitted 0.1.5 release candidate and the 0.2.x line from the exact rc.2 boundary that is exercised by the current Desktop/Host gates:
+
+```text
+>=0.1.5-rc.1 <0.2.0-0
+||
+>=0.2.0-rc.2 <0.3.0-0
+```
+
+Ordinary DVR development is pinned to exact `0.2.0-rc.2`. Hosts below the 0.1.5 train are not part of the DVR 2.3 support contract.
+
+The `0.1.5-alpha.2` browser fixture may remain as historical drift surveillance. It is deliberately outside peer admission, outside the normative exact-source matrix, and must never be described as DVR 2.3 support evidence.
+
+## Gating evidence
+
+| Evidence | DSH version | Role |
 | --- | --- | --- |
-| `minimum-contract` | `0.1.0-rc.6` | Historical compatibility-retention fixture. The name is legacy; DVR 2.1.x and later 2.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.3` | Current stable Host contract baseline. Must remain green. |
-| `preview-contract` | `0.1.7-rc.2` | Retained predecessor-preview regression fixture. |
-| `DSH 0.2.0-rc.2 validation` | `0.2.0-rc.2` (`next/rc`) | Current exact next/rc evidence; not a public preview-support claim. |
-| retained preview regression | `0.1.5-alpha.2` | Older preview regression fixture retained as an older preview regression while the 0.1.7 next line is qualified. |
-| release-channel canary | npm `latest` / `next` / `alpha` | Separately labelled stable, next/rc, and alpha/pre-release drift surveillance. 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.
-
-## Capability matrix
-
-`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.3 (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. |
-| Adapter registration | yes | yes | yes | released `ctx.llm.registerAdapter` surface plus adapter contract tests. |
-| Atomic registration replace | probe | probe | yes | current-contract exercises the real registration handle's `replace()` and disposer; Doctor reports `unknown` if a live Host cannot prove replacement without mutating topology. |
-| Settings live namespace | yes | yes | yes | `settings.register()` + live `scope.get()/watch()` compatibility tests; current-contract mounts the real SettingsProvider contract through a minimal storage subclass. |
-| Tool registration / execution | probe | probe | yes | current-contract mounts the released `@deepseek-ai/dsh-tools` runtime, registers a typed tool, executes it, and disposes it; Vision Router tool-runtime boundary tests remain additive. |
-| `prepareCall` | no | no | yes | `tests/adapter-prepare-call-compat.test.js`; current-contract exercises the installed LLM runtime's `prepareCall()`. |
-| Native image coexistence | yes | yes | yes | `tests/native-image-coexistence.test.js`, `tests/issue-289-native-nonintervention.test.js`, cold-resume workflow. |
-| Jobs service | probe | probe | probe | read-only Doctor capability probe only; P2 must run a separate feasibility spike before any scheduler migration. |
-| Client surface replacement | probe | probe | probe | no version inference; keep `unknown` until a safe readable Host seam is available. |
-| Settings web exposure | probe | probe | probe | presentation capability; never inferred from the settings persistence service. |
-| Effect/dispose cleanup | yes | yes | yes | compatibility lifecycle tests plus current-contract adapter/tool/watch disposer checks; plugin registrations remain Cordis-effect owned. |
-| Public entry boot | yes | yes | yes | packed plugin public entry import in each Host contract fixture. |
-| Packaged tarball install | yes | yes | yes | each Host contract fixture packs the plugin then installs the tarball into an isolated Host package. |
-
-Preview-only evidence: the retained `0.1.7-rc.2` contract fixture additionally mounts the Host-owned `@deepseek-ai/dsh-compaction-image-offload` projection and proves that one offloaded image occurrence stays offloaded across live requests, `SessionStore.fork()`, JSONL process restart, and cold resume. The exact `0.2.0-rc.1` gate separately proves immutable source contracts, official peer evaluation, Host proxy authority, WebServer overlay ownership, real Host + Chromium Vision/mixed-attachment/Settings/bundle lifecycles, and Windows Node 22/24 Desktop plus the Node 24 multi-plugin adversary. Both are verification evidence only; neither expands the public support window.
-
-## Compatibility inventory and exit criteria
-
-Every compatibility seam must answer the same six questions: **Reason**, **Host gap**, **First needed for**, **Feature detection**, **Removal condition**, and **Tests**. Source modules carry the detailed annotation; this table is the architectural index.
-
-| Seam | Reason / Host gap | Feature detection | Removal condition | Primary tests |
-| --- | --- | --- | --- | --- |
-| `lib/dsh-contract-compat.js` | Keep rc.6 single-attachment behavior, rc.8 attachment overlay repair, and settings/provider ownership semantics across the support window. | attachment/settings/LLM methods, never a version string. | Supported Host window provides the needed public seams natively and minimum supported DSH advances beyond the gap. | `rc6-rc7-compat`, `rc6-real-settings-persistence`, `attachment-admission-policy`, contract CI. |
-| `lib/adapter-update-coalescer.js` | Older Vision Router adapters are duck-typed while DSH 0.1.1 dispatches through `prepareCall`; synchronous topology events can re-enter reconciliation. | adapter has `prepareCall`; event behavior is bounded by the coalescer. | All supported adapters implement the Host contract directly and no supported Host needs the reconciliation guard. | `adapter-prepare-call-compat`, adapter/runtime regression tests. |
-| `lib/android-attachment-compat.js` | Termux/Android file persistence can fail at the permission boundary on the minimum Host contract. | actual Android/Termux environment plus permission-boundary failure and absence of batch attachment ownership. | Minimum supported Host owns a working Android attachment store for this path. | `android-attachment-compat`, resource tests. |
-| `lib/replay-envelope-v2-compat.js` | Durable replay producer identity moved into the v2 replay envelope. | exact `response.kind === 'pi-ai' && response.version === 2` producer proof. | Support window no longer contains histories/runtime needing the old source normalization. | `replay-delegation`, replay/session tests. |
-| `lib/pi-ai-bridge-wire-compat.js` | The legacy direct image bridge predates pi-ai declared wire compatibility. | exact non-streaming image bridge fingerprint and resolved pi-ai route/model facts. | Direct bridge is removed or every supported Host executes the request through the native pi-ai wire contract. | `pi-ai-bridge-wire-compat`, native process-restart contract. |
-| `lib/settings-client-rc8-lifecycle.js` | Browser-side settings lifecycle differs across supported Host generations. | browser/runtime surface behavior, not DSH version parsing. | Support window exposes one stable settings client lifecycle. | settings IA/lifecycle regression tests. |
+| `minimum-contract` | `0.1.5-rc.1` | Public 2.3 minimum. Packed-plugin install, public entry, Settings persistence, batch attachment, SessionQuery and core Host contracts. |
+| `current-contract` | `0.1.5-rc.3` | Current stable 0.1.5 Host evidence. |
+| exact-source matrix | `0.1.5-rc.1`, `0.1.5-rc.3`, `0.1.7-rc.2` on Ubuntu/macOS/Windows | Proves the continuous supported 0.1.x line at the floor, current stable point and a later mid-train point. |
+| `2.3 Critical Architecture Gate` / rc.2 reusable workflow | `0.2.0-rc.2` | Default development/next boundary: exact source on three OSes, real Host + Chromium, Windows Desktop Node 22/24 and macOS Desktop lifecycle. |
+| preview browser historical canary | `0.1.5-alpha.2` | Non-support surveillance only; catches browser drift in an older immutable Host. |
+| upstream Web overlay watch | moving DSH `master` | Retirement/drift sentinel only. It never changes the public support window by itself. |
+
+Node 22 and Node 24 remain the general runtime matrix. Minimum/current Host jobs and exact-source/Desktop evidence are additive.
+
+## Current capability evidence
+
+| Capability / boundary | 2.3 verdict | Evidence / detection |
+| --- | --- | --- |
+| Batch attachment ownership | native on every supported Host | `attachments.saveImages`; minimum/current Host contracts; immutable 0.1.5/0.1.7/0.2 source evidence. The pre-floor Android single-attachment fallback was retired in R2.3. |
+| Official DeepSeek provider ownership | Host-owned throughout the supported window | DVR no longer reconstructs `deepseek-official`; `protectHostProviderOwnership()` prevents synthetic takeover. |
+| Settings persistence | native, but lifecycle shape changes across the supported window | minimum Host real Settings persistence plus current/rc.2 browser contracts. `installHostSettingsCompatibility()` remains the narrow runtime bridge. |
+| Session event/log reads | native minimum/current contract | `SessionQuery.readEvent/readSession/observeSession` capability probes; bounded Session recovery remains capability-based. |
+| DVR duck-typed adapter contract | DVR normalization still required | `ensureAdapterContracts()` supplies missing Host base-class defaults such as `prepareCall` / `imageRequestPricing` to DVR-owned plain adapters only. |
+| Client module loader lifecycle | supported Hosts still replace live `load` during `create()` | immutable 0.1.5-rc.1 through 0.2.0-rc.2 source review. The current Settings client lifecycle bridge therefore remains reachable. |
+| modules -> webServer overlay | `shim-required` | exact supported/rc source contracts plus moving upstream watch. |
+| connection -> webServer overlay | `shim-required` | exact supported/rc source contracts plus moving upstream watch. |
+| Router-specific proxy override | product compatibility | explicit `proxy` / `proxyHosts` remain supported; Host-first default egress stays authoritative. |
+| OpenCode Go session wire projection | Host gap remains | current pi-ai transports generic `sessionId`, but upstream does not yet emit the required `x-opencode-session` carrier. |
+
+## R2.3 retirement result
+
+The support-floor reset produced real removals rather than a cosmetic reclassification:
+
+- retired the pre-floor no-batch Android attachment fallback;
+- retired legacy DeepSeek provider reconstruction/keep-alive takeover;
+- retired rc.7-labelled public compatibility aliases in favor of capability-named APIs;
+- removed pre-floor `0.1.5-alpha.2` from the normative exact-source support matrix.
+
+The remaining compatibility seams are retained only for one of four reasons:
+
+1. a capability/lifecycle difference still exists on a supported 0.1.5+/0.2 Host;
+2. supported Hosts can still consume durable data/profile state produced by older DVR/Host generations;
+3. the behavior is an intentional current product compatibility contract;
+4. the behavior closes a runtime/platform gap rather than a Host-version gap.
+
+Detailed owners and removal conditions live in `compat-inventory.md`.
 
 ## Rules
 
-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. 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.
+1. Runtime behavior branches on capabilities, not DSH version strings.
+2. A pre-floor Host may be kept as an explicitly labelled non-support drift canary, but it may not be a required support fixture or broaden peer admission.
+3. Durable historical data compatibility is independent of Host support: old Session/settings/replay state is retained when a supported Host can still load it.
+4. A compatibility seam is removed only when its current-Host/product/durable-data/platform removal condition is proven.
+5. Moving upstream/canary evidence may reveal drift but never silently redefine the public support policy.

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

@@ -1,58 +1,66 @@
 # DSH Host support window
 
-Status: normative for the current DVR 2.x compatibility program.
+Status: normative for the current DVR 3.x compatibility program.
 
 ## 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.2.x publicly supports. |
-| Current Stable Host | `0.1.5-rc.3` | Current npm stable-channel release covered by required exact Host and browser evidence. |
+| DVR train | Minimum Supported Host | Current Stable Host | Ordinary development Host |
+|---|---|---|---|
+| `2.2.x` | `0.1.0-rc.8` | `0.1.5-rc.3` | historical 2.2 development baseline |
+| `2.3.x` | **DSH `0.1.5` train** | `0.1.5-rc.3` | historical 2.3 baseline |
+| `3.0.x` | **DSH `0.1.5` train** | `0.1.5-rc.3` | **exact `0.2.0-rc.2`** |
+
+DVR `2.2.x` keeps `0.1.0-rc.8` as its historical public floor.
 
-DVR `2.2.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.
+DVR `2.3.0` deliberately resets the public minimum to the **DSH `0.1.5` train**. The earliest admitted release in that train is `0.1.5-rc.1`; current stable evidence is `0.1.5-rc.3`. DVR 2.3 no longer publishes a jagged list of `0.1.0` / `0.1.1` / `0.1.3` / `0.1.7` exceptions.
 
-DSH `0.1.5-rc.1` / `0.1.5-rc.2` remain admitted for existing installations; current exact stable evidence has advanced to `0.1.5-rc.3`. Advancing this evidence does not raise the public minimum.
+Ordinary DVR 2.3 development is pinned to **exact DSH `0.2.0-rc.2`** so `pnpm install && pnpm test` exercises the latest fully verified Host/Desktop generation rather than an obsolete compatibility floor. This exact development pin is evidence policy, not a reason to turn runtime behavior into version-string checks.
 
-No later support-floor increase is currently announced.
+Runtime branching remains capability-based rather than version-string-driven.
 
 ### DSH 0.2.x forward admission
 
-DVR 2.2.x peer-admits the DSH `0.2.x` train from the verified rc.1 boundary (`>=0.2.0-rc.1 <0.3.0-0`) without raising the `0.1.0-rc.8` minimum Host floor. Initial forward admission was backed by public pre-0.2.0 master `21638c56315ae6a2b552d6091945d3144c9af32e`. Exact release evidence has now advanced to immutable `dsh-v0.2.0-rc.2` commit `639ed015397290b3745d163aafe02ffee4aa3f84`, published on 2026-09-29. Required gates cover three-OS source contracts, real Host + Chromium, Settings mount/save/reload/readback, mixed attachments, bundle recomposition, Windows Node 22/24 Desktop authentication, the Node 24 multi-plugin isolation adversary, and Host-owned Sharp resolution.
+DVR 2.2.x peer-admits the DSH `0.2.x` train from the verified rc.1 boundary (`>=0.2.0-rc.1 <0.3.0-0`) without raising its historical `0.1.0-rc.8` minimum Host floor.
+
+DVR 2.3 uses exact `0.2.0-rc.2` as its ordinary development Host while keeping the public minimum at the `0.1.5` train. Peer admission is intentionally train-shaped: `>=0.1.5-rc.1 <0.2.0-0` for the continuous supported 0.1.x line from 0.1.5, plus `>=0.2.0-rc.2 <0.3.0-0` for the 0.2.x train from the verified rc.2 boundary. Initial forward admission was backed by public pre-0.2.0 master `21638c56315ae6a2b552d6091945d3144c9af32e`. Exact release evidence has now advanced to immutable `dsh-v0.2.0-rc.2` commit `639ed015397290b3745d163aafe02ffee4aa3f84`, published on 2026-09-29. Required gates cover three-OS source contracts, real Host + Chromium, Settings mount/save/reload/readback, mixed attachments, bundle recomposition, Windows Node 22/24 Desktop authentication, the Node 24 multi-plugin isolation adversary, and Host-owned Sharp resolution.
 
-The final immutable upstream `0.2.0` stable tag and signed official Desktop installer remain release-time revalidation targets. The rc.1 evidence is next-channel verification, not a preview support promise and not a support-floor increase.
+The final immutable upstream `0.2.0` stable tag and signed official Desktop installer remain release-time revalidation targets. The verified `0.2.0-rc.2` boundary is already part of DVR 2.3's peer-admitted supported 0.2.x train; it does not raise the public minimum above the DSH 0.1.5 train.
 
-## Verification evidence — not support policy
+## Verification evidence and drift canaries
 
-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.
+Exact evidence answers which admitted Host points have current CI proof; moving canaries answer whether upstream has drifted beyond those points. Evidence inside an already declared train does not by itself change the minimum support floor, while peer-admission boundaries remain explicit support policy.
 
 | Evidence role | DSH source | Meaning |
 |---|---|---|
 | Exact stable evidence | `0.1.5-rc.3` | Required Host/wire and real Host + Chromium coverage for the current stable release. |
-| Exact next/rc evidence | `0.2.0-rc.2` (`next/rc`) | Required Host/wire/lifecycle/browser evidence. This is not a preview support promise. |
+| Exact supported 0.2.x boundary | `0.2.0-rc.2` (`next/rc`) | Required Host/wire/lifecycle/browser/Desktop evidence for the peer-admitted 0.2.x train; it does not raise the 0.1.5 minimum floor. |
 | Stable drift canary | npm dist-tag `latest` | Scheduled, dynamically resolved surveillance. A failure starts compatibility investigation; it does not rewrite support policy. |
 | Next/rc drift canary | npm dist-tag `next` | Scheduled, dynamically resolved surveillance for the rc channel. A failure does not rewrite support policy. |
 | Alpha/pre-release drift canary | npm dist-tag `alpha` | Scheduled, dynamically resolved surveillance for the alpha channel. 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.
+Exact evidence points may advance inside an already admitted train when CI proof advances. The public minimum and any peer-admission boundary change remain explicit support-policy changes.
 
 Historical release notes under `docs/releases/` are release-time snapshots and are not rewritten when later evidence advances.
 
-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.
+Peer-dependency admission is itself part of the compatibility contract. DVR 2.3 deliberately admits the 0.2.x train from verified `0.2.0-rc.2`; moving npm `next`/`alpha` canaries outside that declared boundary remain surveillance only.
 
-## Floor transition from DVR 2.0.x
+## Floor transitions across DVR 2.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 raised 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. DVR 2.1.0 raised the public minimum to DSH `0.1.0-rc.8`; DVR 2.2.x inherited that rc.8 floor. DVR 2.3.0 raises the floor again to the DSH `0.1.5` train.
 
 ```text
 DVR 2.0.x minimum: DSH 0.1.0-rc.6
 DVR 2.1.x minimum: DSH 0.1.0-rc.8
+DVR 2.2.x minimum: DSH 0.1.0-rc.8
+DVR 2.3.x minimum: DSH 0.1.5 train (earliest admitted release: 0.1.5-rc.1)
+DVR 3.0.x minimum: DSH 0.1.5 train (unchanged from 2.3.x; earliest admitted release: 0.1.5-rc.1)
 ```
 
-Users still on rc.6/rc.7 should upgrade DSH before upgrading to DVR 2.1.x or any later 2.x train. DVR 2.2.x inherits the same rc.8 floor; this maintenance update does not raise it.
+Users on DSH trains older than `0.1.5` must upgrade DSH before upgrading to DVR 2.3.x or 3.0.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.
+The 2.3 floor increase authorizes a fresh deletion audit for Host-version compatibility whose only purpose was keeping pre-`0.1.5` Hosts running. It does **not** authorize deleting compatibility for durable data merely because the Host that originally produced that data is no longer supported. Session logs, replay envelopes, persisted settings and other long-lived inputs require separate reachability evidence on supported Hosts.
 
 ## Support-policy change protocol
 
@@ -61,11 +69,11 @@ A public Host support-floor change is valid only when all of the following are t
 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 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;
+4. required CI proves the public floor, current stable Host, and every declared forward-admission boundary, while moving canaries remain separately labelled surveillance;
 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.
+Advancing exact evidence inside an already declared train or moving a canary target does **not** by itself change the minimum support floor. Changing the peer-admitted train boundary is a support-policy change and must be explicit.
 
 ## Capability-first rule
 
@@ -75,6 +83,6 @@ DVR must not turn these tables into widespread version-string conditionals. Runt
 
 ## Compatibility-retirement rule
 
-The 2.1.x floor makes rc.6-only compatibility candidates eligible for a fresh deletion audit, but does not automatically authorize deletion. Durable session formats, replay envelopes, adapter wire shapes, and other historical inputs may outlive the Host version that originally produced them.
+The 2.3.x `0.1.5` train floor makes any compatibility path used only by pre-`0.1.5` Hosts eligible for a fresh deletion audit, but does not automatically authorize deletion. Durable session formats, replay envelopes, adapter wire shapes, and other historical inputs may outlive the Host version that originally produced them.
 
 See [DSH 0.2.0-rc.2 compatibility audit](dsh-020-rc2-adaptation.md) for the upstream seam review and validation plan.

package/docs/architecture/final-closure-audit.md

@@ -2,6 +2,8 @@
 
 Audit baseline: `main@1c11c1c3c7046268ae1c7b8f2287b023aeb1eb26` (after C3-B / PR #339).
 
+> Historical 2.x closure baseline. The 2.3 architecture phase supersedes its compatibility-status observations; in particular, the former `VisionProviderTransport` process/profile registry has been removed. See `2.3.0-final-audit.md` for the current branch state.
+
 This document records the final adversarial architecture review. It is not a feature roadmap and does not claim that PDF, video, CAD or GUI-agent support exists. The final `CLOSED` declaration is allowed only after the accompanying final Closure gate is merged and the resulting `main` gates are green.
 
 ## Severity result

package/docs/releases/v2.3.0.md

@@ -0,0 +1,53 @@
+# v2.3.0
+
+DSH Vision Router 2.3.0 is an architecture-hardening and compatibility-convergence release. It makes runtime ownership and lifecycle composition more explicit, closes Session and browser correctness gaps discovered by the reopened audit, retires only compatibility paths proven unreachable on the new supported Host window, and adds durable architecture/fuzz/resource evidence without changing Vision Router's core routing authority model.
+
+## Highlights
+
+- **Explicit composition and transport ownership:** runtime installation is grouped into five explicit phases. Router-owned provider HTTP uses an explicitly passed `VisionProviderTransport`; the former process-global current transport registry is gone.
+- **Session correctness under pressure:** the bounded event-feed repair queue now recovers still-current events after overflow instead of silently losing the oldest pending repair, while steady-state paths remain bounded. Async Core bootstrap completion also follows actual Promise settlement.
+- **Mature-Core extraction at stable seams:** public Config composition, maintenance Web routes, Desktop screenshot implementation, and diagnostics Web routes have dedicated owners. The branch deliberately rejects extractions that would only create callback bags or facades.
+- **Current-product browser source owners:** maintenance actions, remote Settings risk/reminder behavior, and local remote-settings permission behavior are source-owned instead of duplicated across generated/compatibility code. The Settings loader lifecycle is named by capability rather than by its historical rc.8 origin.
+- **DSH RemoteResult semantics:** Vision mode selection now treats a resolved `{ ok: false }` from the official `ModelDirectory.select()` contract as failure, preserving recovery diagnostics instead of presenting a silent no-op. Recovery state is also latest-selection-wins, so a stale Host completion cannot overwrite the state of a newer selection.
+- **Session v4 producer ownership (#606):** every DVR-owned durable message producer now emits a Session-format source owned by Vision Router (`plugin:dsh-vision-router` on v4, the legacy plugin shape on v3). The source-normalization boundary remains defense-in-depth rather than the correctness owner, and exact upstream rc.2 admission is covered directly.
+- **End-to-end cancellation ownership:** turn/tool cancellation now reaches macOS/Linux desktop capture processes, screenshot identification, Tesseract, potrace workers, and pair/direct-HTTP vision attempts. Cancellation is terminal, does not poison backend breaker state, and a cancelled `identify=true` screenshot cannot publish a successful managed artifact first.
+- **Final transport and UI lifecycle closure (#610):** the text-projected direct bridge and capability benchmark retain the explicitly owned `VisionProviderTransport`, preserving `proxy` / `proxyHosts` without restoring a global registry. Remote Settings authorization is isolated per live RPC target, including Connection RPC replacement, and stale Vision-toggle settlements cannot overwrite newer recovery state.
+- **Compatibility retirement with evidence:** pre-floor Android/no-batch attachment fallback, legacy DeepSeek provider reconstruction, and rc.7 public aliases are removed. Durable replay/profile compatibility, provider/platform compatibility, and supported Advanced proxy overrides remain where their removal conditions are not satisfied.
+
+## Host support window
+
+2.3.x intentionally raises the public Host floor:
+
+- DSH 0.1.x: `>=0.1.5-rc.1 <0.2.0-0`
+- DSH 0.2.x: `>=0.2.0-rc.2 <0.3.0-0`
+- ordinary development Host: exact `0.2.0-rc.2`
+
+Hosts below 0.1.5 are no longer supported. This does **not** retire durable historical Session/profile readers merely because the running Host floor moved forward.
+
+Remote Settings keeps the same product contract: its confirmation is reminder/acknowledgement only. `acceptedRisk: true` is not authentication or an authorization credential. Remote mutation remains bounded by the explicit allow-list and local-only fields.
+
+The explicit `proxy` / `proxyHosts` Advanced override remains supported and non-deprecated; blank DVR proxy configuration continues to follow the Host network path.
+
+## Validation
+
+The final release candidate and permanent gates cover:
+
+- Node 22 and Node 24 full regression: `1569 tests / 1563 pass / 6 skip / 0 fail` on each, plus `10/10` backend-runtime-policy tests;
+- current Architecture Closure: `131/131` on each Node line;
+- ESM dependency graph: `166 modules / 354 static relative edges / 0 cycles`;
+- minimum DSH `0.1.5-rc.1` and current `0.1.5-rc.3` Host contracts;
+- real DSH `0.1.7-rc.2` Host coverage across Chromium, Windows Desktop Node 22/24, and macOS Desktop renderer lifecycle;
+- exact DSH `0.2.0-rc.2` source on Ubuntu/macOS/Windows, plus real Host + Chromium and Windows/macOS Desktop lifecycle;
+- exact upstream v4 Session admission for DVR durable source ownership;
+- dependency review, P1/P2/P3 architecture gates, fetch-wrapper composition, adversarial compatibility/fuzz, native multimodal cold resume, and large-image resource stress;
+- deterministic and rotating property/adversarial fuzz;
+- 100MP compressed-image stress on Linux/macOS/Windows, with a maximum observed RSS delta of `92.5 MiB` and a fully drained resource governor;
+- package/public-entry smoke and deterministic client-source synchronization.
+
+Architecture evidence is recorded in `docs/architecture/2.3.0-final-audit.md`.
+
+## Upgrade
+
+Users already running 2.2.8 on a supported DSH 0.1.5+ Host can upgrade without migrating existing Vision Router settings or historical Session data.
+
+If the current Host is below 0.1.5, upgrade DSH first. 2.3.0 intentionally does not restore the old jagged pre-0.1.5 compatibility exceptions.

package/docs/releases/v3.0.0.md

@@ -0,0 +1,85 @@
+# v3.0.0
+
+DSH Vision Router 3.0.0 is the ownership release. Vision authority now belongs to a
+durable, explicitly owned Session policy instead of ambient session state; the
+package root is a deliberate, typed public API instead of a monolithic
+implementation file; and the runtime installation is grouped into explicit
+composition phases with an explicitly passed provider transport. It also closes the
+R10 correctness work, the R11 adversarial final audit, and hardens the release
+pipeline itself.
+
+## Highlights
+
+- **Session Vision policy has a durable owner.** A scoped policy store, backed by
+  the Host storage domain, owns Vision authority per Session: it hydrates before a
+  child session publishes, carries into direct Vision checks, and binds delegation
+  to the Host Agent lifecycle instead of re-deriving authority from ambient state. A
+  scoped volatile backend keeps hosts without durable storage working.
+- **Deliberate package root.** The monolithic `index.js` entry is replaced by a
+  curated public entry with its own declaration file, and `exports["."]` now carries
+  `types`. The packed public-API contract executes that entry, checks its lifecycle
+  preconditions and arity, and type-checks a consumer sample against the shipped
+  declarations.
+- **Explicit composition and transport ownership.** Runtime installation is grouped
+  into explicit phases; router-owned provider HTTP receives its
+  `VisionProviderTransport` explicitly, and Core no longer installs a process-wide
+  proxy fetch. Provider probes — live model discovery and the settings connection
+  check — run inside the same configured-pair proxy scope as vision turns, taking the
+  transport the proxy boundary owns rather than reading the process global at call
+  time.
+- **R11 adversarial final audit.** Twenty findings closed, each recorded together
+  with the artifact that guards it, plus the mechanical gates that keep the defect
+  classes from returning: source-ownership lint rules, the bundle-patch activation
+  shim contract, the offline release state machine, and boundary tests against a real
+  Host.
+- **Release-pipeline integrity.** The release state machine is refusal-first and
+  draft-safe; registry identity and package content are compared before and after
+  publishing; the README announcement bars and the release notes are hard gates; the
+  pnpm-free Windows runtime smoke now receives built artifacts instead of installing
+  a package manager.
+
+## Breaking change: a new required peer
+
+3.0.0 adds one required peer dependency:
+
+- `@deepseek-ai/dsh-storage-domain` `>=0.1.5-rc.1 <0.2.0-0 || >=0.2.0-rc.2 <0.3.0-0`
+
+It backs the durable Session Vision policy layer. A Host that cannot provide the
+storage domain cannot persist the policy and therefore must be upgraded first.
+Existing Vision Router settings, profiles and historical Session data keep working:
+the policy store is additive and hydrates from the Session when no durable entry
+exists yet.
+
+## Host support window
+
+Unchanged from 2.3.x:
+
+- DSH 0.1.x: `>=0.1.5-rc.1 <0.2.0-0`
+- DSH 0.2.x: `>=0.2.0-rc.2 <0.3.0-0`
+- ordinary development Host: exact `0.2.0-rc.2`
+
+## Validation
+
+- the full gate battery on the exact release commit: install, build, build:check,
+  source-ownership lint, source→artifact evidence, reproducible clean build,
+  typecheck, the test suite, client-source synchronization, the Host support-window
+  contract, and the packed public-API contract;
+- the real-Host compatibility matrix, adversarial compatibility/fuzz gates and the
+  resource-stress gates;
+- consumer verification of the installed package on both targets (a `dsh web`
+  profile installed from the repository, and a real Desktop shell): a real image turn
+  reaches the provider with the image and the configured credential attached, live
+  model discovery reports the live models, and the Vision Router settings surface
+  renders.
+
+The audit and its evidence index are recorded in
+`docs/architecture/3.0-r11-adversarial-review.md`.
+
+## Upgrade
+
+Users on 2.3.0 with a supported Host can upgrade in place; Vision Router settings and
+existing Session data are read as before, and the durable policy store starts empty
+and hydrates from the Session. On a Host that predates the storage domain, upgrade
+DSH first. Remote Settings keeps its existing product contract: its confirmation is
+an acknowledgement, not an authorization credential, and mutation stays bounded by
+the explicit allow-list and local-only fields.

package/entry.js

@@ -3,78 +3,30 @@
 // P3-F keeps this file as the public schema/export boundary. Runtime ownership
 // lives in lib/runtime-composition.js; the mature core remains in index.js.
 
-import z from '@deepseek-ai/schemastery'
 import * as core from './index.js'
+import {
+  composePublicVisionConfig,
+  SETTINGS_CONTRACT_REVISION,
+} from './lib/public-config.js'
 import { applyVisionRuntimeComposition } from './lib/runtime-composition.js'
 
-// Increment whenever the browser-visible settings contract gains a field whose
-// absence changes write semantics. This revision is also exposed as a resolved
-// schema default so a newer browser client can distinguish a genuinely updated
-// Host from a stale in-process plugin module instead of reporting a generic
-// readback mismatch after the old Host rejects a newly visible field.
-export const SETTINGS_CONTRACT_REVISION = 7
+export { SETTINGS_CONTRACT_REVISION }
 
-// Schemastery object schemas expose set() as the supported way to replace a
-// field schema. This mutates the Config object that index.js itself later uses
-// for the settings namespace, so composition config and settings validation
-// agree on the same default.
-core.Config.set('progressiveTools', z.boolean().default(false))
-// Keep the timeout layers coherent: one provider call may use up to 120s and
-// one visual task (including fallbacks) shares 120s. The whole-turn visual
-// budget is an optional user safety cap rather than an Agent lifetime policy:
-// 0 means unlimited, which is the default for long-running autonomous turns.
-core.Config.set('visionTaskTimeoutMs', z.number().step(1000).min(1000).max(180000).default(120000))
-core.Config.set('visionTurnBudgetMs', z.number().step(1000).min(0).max(600000).default(0))
+export const Config = composePublicVisionConfig(core.Config)
 
-// Both visible entry points — Settings > Vision Router and the legacy
-// Settings > Plugins compatibility card — edit the same Host-owned namespace.
-core.Config.set('visionDepth', z.union(['fast', 'standard', 'deep', 'custom']).default('standard'))
-core.Config.set('visionDepthMaxCalls', z.number().step(1).min(0).max(100).default(0))
-
-// Product semantics: ordered remains the safe default; Auto changes execution
-// only under explicit live routingMode:auto authority.
-core.Config.set('routingMode', z.union(['ordered', 'auto']).default('ordered'))
-core.Config.set(
-  'routingPreference',
-  z.union(['balanced', 'quality', 'speed', 'local']).default('balanced'),
-)
-// Background measurement is separate user authority; absence never grants it.
-core.Config.set(
-  'backgroundBenchmarking',
-  z.union(['local-free', 'all', 'off']).default('off'),
-)
-
-// Settings surfaces and Host persistence must agree on this field.
-core.Config.set('allowRemoteSettings', z.boolean().default(false))
-
-// Internal read-only-by-convention handshake. It is not rendered by Vision
-// Router's settings UI and is not in the remote mutable allow-list.
-core.Config.set(
-  'settingsContractRevision',
-  z.number().step(1).min(1).max(SETTINGS_CONTRACT_REVISION).default(SETTINGS_CONTRACT_REVISION),
-)
-
-export * from './index.js'
+export { inject, name } from './index.js'
 export { sessionSurfaceReplacementIntent } from './lib/session-surface-compat.js'
 export {
-  attachmentContextForContract,
   ensureVisionAttachmentAdmissionPolicy,
   hasBatchAttachmentContract,
   hostOwnsOfficialDeepSeekProvider,
   installHostSettingsCompatibility,
   installVisionAttachmentAdmissionPolicy,
   protectHostProviderOwnership,
-  // Transitional public aliases retained for callers/tests written during the
-  // rc.7 compatibility pass. Production runtime branches on feature seams.
-  installRc7SettingsCompatibility,
-  isRc7ContractRuntime,
-  protectRc7ProviderOwnership,
 } from './lib/dsh-contract-compat.js'
-export const Config = core.Config
-
 // Defense in depth for direct/programmatic callers is implemented by the same
 // production composition used by Cordis. This public entry intentionally owns
 // no runtime installer ordering beyond that single call.
-export function apply(ctx, config = {}) {
-  return applyVisionRuntimeComposition(ctx, config, core)
+export function apply(ctx, config = {}, runtime = {}) {
+  return applyVisionRuntimeComposition(ctx, config, core, runtime)
 }