dsh-vision-router 2.2.8 → 2.3.0

package/docs/architecture/compat-inventory.md

@@ -1,36 +1,30 @@
 # Compatibility seam inventory
 
-P0 records why each major compatibility seam exists and the condition that permits its removal. This inventory is normative for 2.x convergence: a shim without an exit criterion is architectural debt that cannot silently become permanent.
+P0 records why each major compatibility seam exists and the condition that permits its removal. This inventory is normative for DVR 2.3 convergence: a shim without an exit criterion is architectural debt that cannot silently become permanent.
 
 ## `lib/dsh-contract-compat.js`
 
-- **Reason:** preserve released attachment/settings/provider-ownership behavior across the supported DSH window.
-- **Host gap:** rc.6 has the single-attachment contract; later Hosts add batch save, max-dimension policy and newer settings/provider lifecycle behavior.
-- **First needed for:** minimum rc.6 support and the subsequent rc.7/rc.8 attachment migration.
-- **Feature detection:** `attachments.saveImages`, attachment `imageLimits`, settings registration/scope functions, and LLM registration methods. The batch-attachment generation is also the semantic boundary where `deepseek-official` remains Host-owned instead of being reconstructed by DVR. No version-string branch.
-- **Removal condition:** minimum supported DSH natively exposes the required attachment/settings/provider seams and legacy profile overlays are outside support.
-- **Tests:** `rc6-rc7-compat`, `rc6-real-settings-persistence`, `attachment-admission-policy`, `dsh-host-capabilities`, minimum/legacy/current contract CI.
+- **2.3 state:** `retain-host-gap`.
+- **Reason:** keep supported settings/provider-ownership contracts and durable attachment-policy migrations centralized without reviving pre-floor Host ownership.
+- **Host gap:** the DVR 2.3 window spans multiple Settings/Config generations, while persisted historical `attachment-local` profile overlays can still shadow current image-limit/normalization defaults after the Host is upgraded.
+- **First needed for:** supported Settings lifecycle convergence plus durable profile migration. The pre-`0.1.5` single-attachment / DeepSeek-provider reconstruction path is retired in R2.3.
+- **Feature detection:** attachment `imageLimits` / normalization shape, settings registration/scope functions, and LLM registration ownership. `attachments.saveImages` remains a diagnostic/ownership fact; it no longer authorizes DVR to synthesize an official DeepSeek provider.
+- **Removal condition:** the supported Settings lifecycle has one native contract and durable profiles containing the historical attachment policy overlay are migrated or explicitly outside the data-compatibility window.
+- **Tests:** `dsh-host-compat` (retained durable/current cases), `minimum-host-settings-persistence`, `attachment-admission-policy`, `dsh-host-capabilities`, minimum/current/rc2 contract CI.
 
 ## `lib/adapter-update-coalescer.js`
 
+- **2.3 state:** `retain-host-gap`.
 - **Reason:** keep Vision Router-owned duck-typed adapters compatible with Host `prepareCall` dispatch and prevent synchronous adapter-topology events from recursively reconciling forever.
-- **Host gap:** older plugin adapters do not inherit the Host adapter base class; supported Host generations can emit adapter updates synchronously during registration.
-- **First needed for:** DSH 0.1.1 `prepareCall` and atomic registration behavior.
+- **Host gap:** Vision Router intentionally owns several plain/duck-typed adapters instead of inheriting the Host adapter base class; supported Host generations call base-class contracts and can emit adapter updates synchronously during registration.
+- **First needed for:** Host adapter-contract evolution (`prepareCall`, later image-request pricing) and synchronous registration reconciliation. The original version labels are historical origin only, not a current support dependency.
 - **Feature detection:** adapter-local `prepareCall` presence; actual `llm/adapters-updated` event path. No version inference.
 - **Removal condition:** every supported Vision Router adapter directly satisfies the Host adapter contract and supported Host event semantics no longer require the bounded coalescer.
 - **Tests:** `adapter-prepare-call-compat`, `runtime-boundary-fixes`, current-contract Host smoke.
 
-## `lib/android-attachment-compat.js`
-
-- **Reason:** allow the minimum Host path to survive Termux/Android attachment persistence permission boundaries without taking ownership on batch-capable Hosts.
-- **Host gap:** file-backed attachment storage can fail with `EACCES`/`EPERM` in Android/Termux environments on the legacy path.
-- **First needed for:** Android/Termux support while rc.6 remains minimum.
-- **Feature detection:** Android/Termux environment, permission-boundary error and absence of the batch attachment contract.
-- **Removal condition:** minimum supported DSH owns a working Android attachment implementation for the same path and the fallback is no longer reachable.
-- **Tests:** `android-attachment-compat`, image-resource/resource-retention tests.
-
 ## `lib/replay-envelope-v2-compat.js`
 
+- **2.3 state:** `product-compat`.
 - **Reason:** preserve delegated replay identity when producer provider/model moved into durable pi-ai replay envelope v2.
 - **Host gap:** older Vision Router replay code expected producer identity at the top level.
 - **First needed for:** rc.7 replay-envelope v2 histories.
@@ -40,6 +34,7 @@ P0 records why each major compatibility seam exists and the condition that permi
 
 ## `lib/pi-ai-bridge-wire-compat.js`
 
+- **2.3 state:** `retain-host-gap`.
 - **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.
@@ -47,17 +42,19 @@ P0 records why each major compatibility seam exists and the condition that permi
 - **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`
+## `lib/settings-client-loader-lifecycle.js`
 
-- **Reason:** keep browser settings lifecycle coherent across legacy and current Host client generations.
-- **Host gap:** settings client attachment/replacement lifecycle is not identical across the support window.
-- **First needed for:** rc.8-era settings UI coexistence.
-- **Feature detection:** actual client/runtime lifecycle surfaces; never the Host version label.
-- **Removal condition:** supported Hosts expose one stable settings client lifecycle and the compatibility branch is proven unreachable by contract tests.
+- **2.3 state:** `retain-host-gap`.
+- **Reason:** keep current Settings permission/risk capability owners attached when the Host module system switches registrations from queue to live loading. The legacy in-page `settings-rc8-lifecycle` marker/sentinel is intentionally retained only for mixed-generation/HMR idempotency; source/API ownership is capability-named.
+- **Host gap:** immutable supported sources from 0.1.5-rc.1 through 0.2.0-rc.2 still replace the live module `load` function during `create()`, so one boot-time wrapper is not stable across the complete client lifecycle.
+- **First needed for:** the older Settings UI coexistence work; retained now because the same loader replacement remains present on supported Hosts, not because rc.8 itself is supported.
+- **Feature detection:** actual `__ModuleLoader__.create/load` lifecycle and current Settings surfaces; never the Host version label.
+- **Removal condition:** supported Hosts expose one stable Settings client attachment lifecycle (or the shared carrier gives DVR a native post-create hook) and current product permission/risk wrappers no longer require reattachment.
 - **Tests:** settings IA, client lifecycle, remote-settings and Web acceptance regressions.
 
 ## `lib/http-compat.js`
 
+- **2.3 state:** `product-compat`.
 - **Reason:** isolate evidenced provider/model wire quirks from generic visual HTTP execution.
 - **Host gap:** this is provider compatibility rather than a DSH Host gap; some OpenAI-compatible endpoints reject otherwise valid generic payload shapes.
 - **First needed for:** model-family quirks such as GLM-4V-Flash output limits and image-only message handling.
@@ -65,17 +62,9 @@ P0 records why each major compatibility seam exists and the condition that permi
 - **Removal condition:** upstream endpoint behavior becomes generic-compatible for a rule and regression evidence confirms the preset is no longer needed.
 - **Tests:** `http-compat`, provider HTTP regression tests.
 
-## `lib/vision-provider-transport.js` process/profile registry
-
-- **Reason:** carry the Router-owned provider transport into compatibility callers whose mature function signatures still accept only a raw `fetch` or use an internal direct HTTP call, while keeping Router traffic off the process-global fetch patch.
-- **Host gap:** this is an internal composition gap rather than a DSH version persona: `fetchWithOpenAICompatibility(...)` and the Anthropic catalog-correction path do not yet receive a `VisionProviderTransport` parameter explicitly.
-- **First needed for:** provider-scoped transport ownership and proxy narrowing without rewriting the mature compatibility call signatures in the same migration.
-- **Feature detection:** explicit transport-aware callers bypass the registry; only compatibility paths that call `currentVisionProviderTransport()` consume the currently installed process/profile transport. The registry never patches `globalThis.fetch`. Router-owned and scoped Host-owned explicit proxies share one lease/retire dispatcher pool. First-hop `proxyHosts` admission preserves the no-Undici Host path for non-matches; admitted requests use a request-scoped selector that re-checks every redirect origin and delegates non-matches to the request-start Host/caller dispatcher.
-- **Removal condition:** every Router-owned compatibility caller receives `VisionProviderTransport` explicitly, production has zero reads of `currentVisionProviderTransport()`, and the install/release registry can be removed without changing proxy, redirect-hop authority, credential, bounded-body, cancellation, or dispatcher-lifecycle behavior.
-- **Tests:** `vision-provider-transport` (A→B lifecycle, proxy clear, pending-construction unload, synchronous loader failure, real Fetch listed→unlisted redirect, initial-unlisted no-import and explicit-caller fallback), `legacy-global-proxy-boundary` (scoped Host-owned redirect and pool cleanup), `http-compat`, `catalog-corrections`, P2 Data Boundary provider-transport Node 22/24, Host pack/install smoke.
-
 ## `lib/legacy-global-proxy-boundary.js`
 
+- **2.3 state:** `retain-host-gap`.
 - **Reason:** preserve the explicit Vision Router proxy override for Host-owned/raw-fetch visual providers without granting that configuration process-wide routing authority. Router-owned HTTP already uses `VisionProviderTransport`; blank `proxy` leaves the compatibility wrapper fully transparent.
 - **Host gap:** DSH 0.1.5 owns ordinary process egress, but a Host adapter invoked through `ctx.llm.stream()` still exposes no DVR-owned request/dispatcher parameter for a vision-only SOCKS/selective override. A separate legacy direct whole-turn mode (`routing=true` plus blank `chainRoute`) also hands control to the Host after the DVR hook returns, leaving no adapter-iteration scope to authorize.
 - **First needed for:** legacy/custom Host-owned visual provider compatibility when users configure a Vision Router-specific proxy override.
@@ -86,6 +75,7 @@ P0 records why each major compatibility seam exists and the condition that permi
 
 ## `lib/legacy-core-vision-policy-bridge.js`
 
+- **2.3 state:** `retain-host-gap`.
 - **Reason:** preserve the two remaining pre-step compatibility behaviors after Core policy ownership moved to explicit session/Core surfaces: reuse the exact `SessionMemoryView` for text-only image-history rewrite, and expose exact current-turn durable attachment IDs as read-only model context for Vision Router-owned wrappers.
 - **Host gap:** the supported Host pre-step path does not natively provide both an exact session-scoped visual-memory rewrite seam for text-only fallback and a model-readable durable attachment-reference seam for Router-owned image turns.
 - **First needed for:** the Core/session ownership migration that removed Settings/config impersonation while retaining these two real pre-step behaviors.
@@ -95,6 +85,7 @@ P0 records why each major compatibility seam exists and the condition that permi
 
 ## `lib/tesseract-exec-compat.js`
 
+- **2.3 state:** `product-compat`.
 - **Reason:** own the single process-wide `promisify(execFile)` compatibility boundary for the two narrow child-process cases Vision Router still needs: materializing Tesseract stdin image bytes, and replacing only Core's exact legacy Windows `VirtualScreen`/`CopyFromScreen` desktop-capture command with a per-monitor-DPI-safe equivalent. One owner prevents cleanup-order bugs from independently stacked `execFile` wrappers.
 - **Host gap:** these are runtime/platform gaps rather than DSH semantic ownership: Node's async `execFile` path does not consume the historical OCR `options.input`, while non-DPI-aware Windows PowerShell virtualizes desktop metrics and can disagree with physical screen-copy coordinates on scaled/mixed-DPI displays.
 - **First needed for:** Node 24/local Tesseract process execution reliability; Windows scaled/mixed-DPI `vision_screenshot` correctness (#340).
@@ -104,6 +95,7 @@ P0 records why each major compatibility seam exists and the condition that permi
 
 ## `lib/abort-signal-compat.js`
 
+- **2.3 state:** `product-compat`.
 - **Reason:** keep Vision Router cancellation/deadline composition working when a supported DSH Host or bridge exposes `AbortSignal`/`AbortController` but omits the standard static `AbortSignal.any()` or `AbortSignal.timeout()` helpers used by the Router's runtime boundaries.
 - **Host gap:** some real Host/bridge environments can surface a partial AbortSignal runtime even though the declared Node support window normally provides both helpers, producing `AbortSignal.any is not a function` inside visual work.
 - **First needed for:** partial Host/bridge AbortSignal runtimes observed during Vision Router image execution and exact capability checks.
@@ -117,6 +109,6 @@ A compatibility seam may be deleted only when all of the following are true:
 
 1. its **Removal condition** is satisfied by the declared support window;
 2. the relevant capability is proved by a gating Host contract fixture or direct feature test;
-3. deleting the seam leaves Node 22/24, minimum/legacy/current Host contracts and relevant platform tests green;
+3. deleting the seam leaves Node 22/24, minimum/current/mid-train/rc.2 Host evidence and relevant platform tests green;
 4. no Authority, Session, Storage or native-multimodal invariant changes as a side effect;
 5. the deletion is a focused change, not bundled into an unrelated routing/data-boundary refactor.

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

@@ -6,53 +6,59 @@ Status: normative for the current DVR 2.x compatibility program.
 
 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` | **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)
 ```
 
-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.
 
-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 +67,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 +81,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/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))
-
-// 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 const Config = composePublicVisionConfig(core.Config)
 
 export * 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)
 }