0.5.1: validated on dsh 0.2.2-alpha.2

No code change from 0.5.0. The 0.2.2-alpha.2 review found the allow path's
bundles byte-identical, the webserver's new resource route kind orthogonal to
the interceptor, and the frontend static bundle's resource rewrite still
emitting webserver/index-inject. Full probe matrix (11/11) and Files pane
checks pass against a sandbox of the published release; README records the
new dsh web --host wildcard refusal.

README.md

@@ -351,8 +351,8 @@ three are `true` by default; serving over HTTPS makes the first two redundant.
 ## Compatibility
 
 Verified against **DSH 0.1.7-rc.2**, **0.2.0-rc.1**, **0.2.1-alpha.1**,
-**0.2.1-alpha.2**, **0.2.1-alpha.4**, and **0.2.1-rc.1**. From 0.4.0 the
-manifest also declares the range:
+**0.2.1-alpha.2**, **0.2.1-alpha.4**, **0.2.1-rc.1**, and **0.2.2-alpha.2**.
+From 0.4.0 the manifest also declares the range:
 
 ```json
 "engines": { "dsh": ">=0.1.7-rc.2 <0.3.0-0" }
@@ -362,10 +362,15 @@ manifest also declares the range:
 provide — the harness uses it, when present, in place of guessing from
 `@deepseek-ai/dsh-*` peer ranges. This plugin has no dsh peers at all, so the
 declaration is the only statement of support it makes, and it is bounded above
-at the next minor release, excluding its prereleases, rather than left open. `0.2.1-rc.2` is not listed as a
-separate version because `dsh-client-connection`, `dsh-host-webserver`,
-`dsh-web-app`, and the frontend static bundle are byte-identical between rc.1
-and rc.2.
+at the next minor release, excluding its prereleases, rather than left open.
+
+`0.2.1-rc.2` is not listed separately because all four bundles the plugin hooks
+are byte-identical between rc.1 and rc.2. `0.2.2-alpha.2` *is* listed: it is the
+first release since 0.2.1-rc.1 that moves a hooked bundle, so it was re-checked live
+rather than inferred. Its `dsh-client-connection` and `dsh-web-app` are still
+byte-identical to `0.2.1-rc.2`; `dsh-host-webserver` and
+`dsh-host-frontend-static` changed in ways that leave the surfaces used here
+intact, and `dsh-session`'s stricter publication does not touch this plugin.
 
 The plugin depends on several things that are internal rather than public API,
 so a harness release that renames any of them will break it:
@@ -395,6 +400,59 @@ interceptor was not installed and a Host fence will still refuse a remote
 window; the harness surface may have changed
 ```
 
+### What was checked on 0.2.2-alpha.2
+
+The first release since 0.2.1-rc.1 that moves a bundle this plugin hooks, so it was
+re-checked end to end instead of inferred from byte-identity.
+
+**What moved.** `dsh-client-connection` and `dsh-web-app` are still
+byte-identical to `0.2.1-rc.2`, so the allow path — `admit`, `trustedHosts`,
+`requestRejection`, `authorizeIndex`, `authenticatedUrl` — is untouched. The two
+surfaces that did move are `dsh-host-webserver` and `dsh-host-frontend-static`.
+The webserver gained a second route kind (`{ resource }`: a Fetch-API
+`Request → Response` handler, plus a `readResource` variant) beside the plain
+`{ handler }` one; `server`, `register`, `tapIndex`, `host`, `port`, and
+`protocol` are unchanged, and the interceptor wraps the raw server's request
+emission before routing, so a route's kind does not matter to it. The frontend
+static bundle still authorizes the index through
+`connection.authorizeIndex(request, shim)` and still emits
+`webserver/index-inject`, so the browser grant, the shims, the viewport, and the
+PWA route inject exactly as before. `dsh-session` tightened store-owned
+publication (`cannot append outside a SessionStore`), which this plugin never
+does. The CLI's new optional bundles do not change a profile's explicit bundle
+list, so nothing new is inserted next to this one.
+
+**Measured on a sandbox of the published `@deepseek-ai/[email protected]`** (the
+npm `alpha` tag; `latest` still points at `0.2.1-rc.2`), with a copy of a real
+profile, over a non-loopback peer:
+
+| Check | Result |
+|---|---|
+| interceptor answers `GET /` for a foreign `Host` | `200` index, no cookie |
+| WebSocket upgrade for a foreign `Host` | `101` |
+| `/api/*` over the non-loopback peer and over a named host | `200`, not the `400` trust fence |
+| browser grant, shims, viewport, and PWA markers in the served index | all present |
+| PWA manifest | `200 application/manifest+json` |
+| Files pane over a foreign `Host` — `fs.tree`, `fs.read`, `GET /sidebar/file` download | `200`, and the downloaded bytes are the file's |
+| `dsh plugin` load | no skip line, no missing-surface warning |
+
+`node scripts/live-probe.mjs` passes **11/11** against that sandbox, including
+the sidebar Files API row. A control run with the bundle disabled answers `401`
+to `GET /` — the token gate stands — so a remote browser never gets as far as
+the pane; that is the difference the bypass makes. The installed sidebar bundle
+(0.28.0) no longer injects `webRuntime` at all, so on this harness its Files
+routes register whether or not the service is provided; `provideWebRuntime`
+stays for bundles that still inject it (0.26 and older), where the missing
+service is what left the pane answering `405`.
+
+One harness deployment change to know about: since DSH 0.2.1-alpha.2, `dsh web --host` refuses
+a wildcard address (`0.0.0.0`, `::`) — *"is an unspecified (wildcard) address,
+which is not supported: binding every interface would expose remote code
+execution to the network; bind one concrete IPv4 or IPv6 address instead"* — so
+a container that bound wildcard must pass its concrete container IP. The bind
+address is still accepted as an authority by the trust snapshot, so
+`provideWebRuntime` and the no-`--trusted-host` posture keep working.
+
 ### What was checked on 0.2.1-rc.1
 
 This is the release the 0.4.0 change answers. Two things moved.
@@ -647,7 +705,7 @@ node test/web-runtime.test.mjs  # the restored webRuntime value, and when it is
 node scripts/live-probe.mjs  # against the running harness, over a non-loopback peer
 ```
 
-All five suites together — **60 tests** (fence 8, apply 21, handover 15,
+All five suites together — **61 tests** (fence 8, apply 22, handover 15,
 shims 9, web-runtime 7) — are `node --test test/*.test.mjs` from the plugin
 directory. The shell has to expand that glob: `node --test test/` fails with `MODULE_NOT_FOUND`
 on Node 22.
@@ -676,6 +734,7 @@ remote client and always looks like it passes.
 
 | Version | What changed |
 |---|---|
+| **0.5.1** | Documentation and compatibility only — **no code change from 0.5.0**. Records the 0.2.2-alpha.2 review: the allow path's bundles are byte-identical, the webserver's new route kind does not touch the interceptor, and `scripts/live-probe.mjs` passes 11/11 against a sandbox of the published release (Files pane, PWA, shell, Skill Center, shims). Also notes the new `--host` wildcard refusal. |
 | **0.5.0** | Restores `disableAuth: true` as the default: no launch token and no per-device pairing, which is what the plugin exists to remove. `0.4.0`'s keep-the-check posture remains available with `disableAuth: false`. No code change beyond the default and the documentation; validated on DSH `0.2.1-rc.2`, where the bypass still replaces `connection.admit`. |
 | **0.4.0** | Keeps the browser-session check by default (`disableAuth: false`) and makes the 0.2.1-alpha.3 launch-token → 30-day-cookie flow survive the Host rewrite, including on a remote origin; the no-check posture moves to `disableAuth: true` and now replaces `connection.admit` as well, because the gate moved there. Declares `engines.dsh` (the 0.2.1-alpha.4 recommendation) and is validated on 0.2.1-alpha.4 and 0.2.1-rc.1. |
 | **0.3.0** | Provides the `webRuntime` trust snapshot that `0.2.1-alpha.2` stopped publishing (`lib/web-runtime.js`, `provideWebRuntime`), so a plugin that injects it — the sidebar among them — mounts instead of answering 405 on every request. The value is read live from `connection.trustedHosts` plus the listener's bind address, and an existing provider is left alone. |

package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-trustworthy",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "Removes the untrusted-origin restriction from DeepSeek Harness while keeping its own session check: every browser window is treated as if it were running on the harness machine itself, so no declared trusted host and no per-plugin origin fence refuse it. One interceptor answers every request with the loopback authority, and the one-time launch token is exchanged for a 30-day cookie exactly as on the loopback host.",
   "type": "module",
   "main": "lib/index.js",