redweb 0.16.1 → 0.16.3

package/docs/SOCKET_PAGES.md

@@ -1,172 +1,172 @@
-# Server-side TSX for custom socket routes
-
-## Connected clients (0.16.0)
-
-The following convenience layer requires Redweb **0.16.0**; it is not in Redweb 0.15.0.
-It uses existing redweb-client 0.3.0 without a client upgrade.
-
-`connectedClients({ identity, page, project })` creates one route-owned group.
-Register it as `connections` in `SocketRoute`; rooms and handler drain tracking
-are enabled by default. Create a fresh group inside each application factory.
-It reuses RoomRegistry capacity, authorization and disconnect cleanup, not a second
-membership map. Normal raw SocketRoute/SocketContract APIs remain unchanged.
-
-```ts
-const players = connectedClients({
-    identity: context => account(context.request),
-    page: () => GamePage,
-    project: (player, room, online) => ({
-        game: games.resume(room, player.identity).snapshot(player.identity),
-        online,
-    }),
-});
-const match = players.bind(contract);
-const Join = match.handler('join', (player, { room }) =>
-    player.join(room, () => games.join(room, player.identity)));
-```
-
-This is a composition excerpt: the application supplies `account`, `games`, the
-typed `contract`, and decorated `GamePage` state fields. Register the resulting
-handler, contract protocol and `connections: players` on the page's SocketRoute.
-Handler `.with(payload)` bindings keep their inferred input type.
-
-The client exposes `identity`, `page`, `rooms`, `room` (exactly one membership),
-`join(room, commit?)`, `leave(room)` and an explicit underlying `socket` escape hatch.
-`players.get(socket)` supports page lifecycle callbacks, and
-`players.refresh(room)` publishes changes made outside a handler. Successful
-handlers automatically refresh their client's current rooms. Room changes batch
-refresh requests; multiple tabs count as one online identity, but receive separate
-private page projections.
-
-Identity must remain exactly equal to the admitted principal. The group checks it
-after payload validation and before/after asynchronous projection work. Existing
-page authorization and generation guards remain in force. Access is not granted
-by a button or a room name. The application still defines room access, game rules,
-seat recovery, revisions and durable storage.
-
-`join` checks membership capacity/permission before its synchronous domain commit.
-A rejected commit removes newly added membership, but does not remove pre-existing
-membership. Domain operations must validate before changing their own state:
-Redweb cannot roll back arbitrary application or database side effects. Async
-domain commits are rejected; they must not be used as an external transaction.
-
-Projection callbacks return partial page state and must be side-effect-free.
-Authorization and projection work use bounded operations (5000ms defaults;
-`authorizationTimeoutMs` and `projectionTimeoutMs` configure them). Disconnect
-cancels delivery; late results and late failures cannot overwrite or disconnect a
-newer generation. Recipient failures do not reject someone else's committed move.
-Cancellation cannot stop arbitrary work inside user callbacks, only its acceptance.
-
-Throw `ClientError` only for deliberately public text, or classify domain errors
-with `reject(error): string | undefined`. Unexpected exceptions retain normal
-private server error handling. Optional `errorState(message)` returns page fields
-such as a notice; the framework owns protocol errors and form completion.
-
-An optional `raw.update(state)` adapter returns `{ type, payload }` for non-HTML
-clients. Optional `raw.reject(message)` returns an uncorrelated display event.
-Redweb performs the final authorized send, not the adapter. State events are
-uncorrelated; successful raw requests complete with `redweb:result`, while safe
-rejections use correlated protocol errors. With redweb-client use
-`request(type, payload, { responseType: 'redweb:result' })` and subscribe to state
-separately. This is an opt-in completion contract, not a silent change to existing
-raw handlers. Custom adapters must not send from inside their callbacks.
-
-## Socket-bound pages (0.15.0)
-
-Added in Redweb 0.15.0 with redweb-client 0.3.0, installed automatically by Redweb.
-Earlier Redweb 0.14.0/client 0.2.0 packages do not provide this extension.
-Contributors editing both packages can use the optional npm-link workflow in the repository's `docs/CLIENT_DEVELOPMENT.md`.
-
-A live page can attach to a registered custom `SocketRoute` using
-`@page('/', { socket: MatchRoute })`. There is no new view class, no second renderer,
-and no application-specific browser module. Its connection carries ordinary typed
-commands and reserved `redweb:*` rendering/completion messages.
-
-## Typed controls
-
-`defineSocketContract(...).handler(type, callback)` still returns a handler class.
-That class can now be used as a JSX binding:
-
-```tsx
-<form rw-submit={Join}>
-    <input name="room" required />
-    <button>Join room</button>
-</form>
-
-<button rw-click={Move.with({ cell, revision })}>Move</button>
-```
-
-`.with()` snapshots JSON data; it never invokes the handler during rendering.
-TypeScript checks the payload's input type. Incoming wire data is independently
-validated by the contract, including asynchronous schemas. Form fields merge over
-the bound object payload. A click sends its bound payload, or an empty object when
-none was supplied. Bound values are untrusted inputs, not server-held secrets or
-authorization capabilities. Do not embed private data in them.
-
-Bindings are server-owned identities, not arbitrary function closures. Rendering
-rejects references to handlers absent from the attached route, even if a different
-handler has the same message name. Existing string `rw-click`/`rw-submit` actions
-remain unchanged on ordinary live pages. Socket-bound pages dispatch only their
-custom route handlers; do not mix local `@action()`/`rw-bind` commands into them.
-
-## Server-owned client state
-
-On an attached connection, `socket.page(PageClass)` returns that connection's
-concrete page after checking its class, ownership and active lifetime:
-
-```ts
-if (socket.page) {
-    socket.page(GamePage).game = games.snapshot(room, account);
-}
-```
-
-Assigning `@state()` fields uses the existing reactive renderer and keyed TSX.
-Raw connections have no `page` accessor and keep their existing socket protocol.
-Shared domain state belongs in a room/service; each private page receives only its
-authorized perspective. Components remain ordinary page-owned Redweb components.
-
-## Configuration and boundaries
-
-Register the route once in `defineApp({ pages: [GamePage], sockets: [MatchRoute] })`.
-Socket-bound pages must be live, connection-scoped and render TSX. Their route must
-support protocol version `1` with the default `redwebVersion` query parameter and
-explicitly allow duplicate connections (independent tabs). `redweb:*` handler names
-are reserved. Page-enabled routes use ordered, bounded message dispatch and track
-in-flight work for shutdown. JSON commands are supported; binary input is rejected
-on page-attached connections. Raw route connections retain binary handling.
-
-The adapter preserves route admission, origin and placement policies, then checks
-the page token, exact route, page identity and page origin. Use `authenticate` for
-page identity and `authorize` for current permissions/session validity. Authorization
-runs before commands, again after contract validation, and before render publication.
-Revocation and disconnect cancel ownership even when validation is still running.
-The page token is not a substitute for credentials.
-
-Initial page attachment completes before custom initialization hooks or commands.
-Do not call page commands from initialization hooks expecting those hooks themselves
-to finish first. Each page owns its connection; the same token cannot attach twice.
-
-Reconnect reauthenticates, invokes existing `connected()` hooks, and sends a fresh
-rendering snapshot. Game-seat recovery remains in that server hook. Commands are
-not queued or replayed. Page-session expiration requires a reload; game persistence
-is not provided by page retention.
-
-## Completion and client runtime
-
-After successful handler dispatch, Redweb sends a correlated `redweb:result`.
-The generated runtime waits specifically for that terminal type or a protocol error,
-not intermediate correlated progress messages. Direct client users can opt into
-the same behavior using `client.request(type, payload, { responseType })`; omitting
-the option preserves the existing any-correlated-response behavior.
-
-For an expected application rejection, send a safe correlated error with
-`socket.sendProtocolError('GAME_REJECTED', safeMessage, { requestId })` and return
-`false` from the handler. Only literal `false` declines successful dispatch;
-`undefined` remains success. The browser shows error feedback, preserves the form,
-and keeps its connection usable. Returning `false` without sending a correlated
-reply leaves a requesting client waiting until its deadline. Unexpected exceptions
-retain the existing sanitized handler-failure behavior and close the connection.
-
-This browser support lives in redweb-client's existing feedback/transport modules.
-The server still owns validation, authorization, game revisions, room fan-out and
-private rendering. Disabled controls are presentation, never permissions.
+# Server-side TSX for custom socket routes
+
+## Connected clients (0.16.0)
+
+The following convenience layer requires Redweb **0.16.0**; it is not in Redweb 0.15.0.
+It uses existing redweb-client 0.3.0 without a client upgrade.
+
+`connectedClients({ identity, page, project })` creates one route-owned group.
+Register it as `connections` in `SocketRoute`; rooms and handler drain tracking
+are enabled by default. Create a fresh group inside each application factory.
+It reuses RoomRegistry capacity, authorization and disconnect cleanup, not a second
+membership map. Normal raw SocketRoute/SocketContract APIs remain unchanged.
+
+```ts
+const players = connectedClients({
+    identity: context => account(context.request),
+    page: () => GamePage,
+    project: (player, room, online) => ({
+        game: games.resume(room, player.identity).snapshot(player.identity),
+        online,
+    }),
+});
+const match = players.bind(contract);
+const Join = match.handler('join', (player, { room }) =>
+    player.join(room, () => games.join(room, player.identity)));
+```
+
+This is a composition excerpt: the application supplies `account`, `games`, the
+typed `contract`, and decorated `GamePage` state fields. Register the resulting
+handler, contract protocol and `connections: players` on the page's SocketRoute.
+Handler `.with(payload)` bindings keep their inferred input type.
+
+The client exposes `identity`, `page`, `rooms`, `room` (exactly one membership),
+`join(room, commit?)`, `leave(room)` and an explicit underlying `socket` escape hatch.
+`players.get(socket)` supports page lifecycle callbacks, and
+`players.refresh(room)` publishes changes made outside a handler. Successful
+handlers automatically refresh their client's current rooms. Room changes batch
+refresh requests; multiple tabs count as one online identity, but receive separate
+private page projections.
+
+Identity must remain exactly equal to the admitted principal. The group checks it
+after payload validation and before/after asynchronous projection work. Existing
+page authorization and generation guards remain in force. Access is not granted
+by a button or a room name. The application still defines room access, game rules,
+seat recovery, revisions and durable storage.
+
+`join` checks membership capacity/permission before its synchronous domain commit.
+A rejected commit removes newly added membership, but does not remove pre-existing
+membership. Domain operations must validate before changing their own state:
+Redweb cannot roll back arbitrary application or database side effects. Async
+domain commits are rejected; they must not be used as an external transaction.
+
+Projection callbacks return partial page state and must be side-effect-free.
+Authorization and projection work use bounded operations (5000ms defaults;
+`authorizationTimeoutMs` and `projectionTimeoutMs` configure them). Disconnect
+cancels delivery; late results and late failures cannot overwrite or disconnect a
+newer generation. Recipient failures do not reject someone else's committed move.
+Cancellation cannot stop arbitrary work inside user callbacks, only its acceptance.
+
+Throw `ClientError` only for deliberately public text, or classify domain errors
+with `reject(error): string | undefined`. Unexpected exceptions retain normal
+private server error handling. Optional `errorState(message)` returns page fields
+such as a notice; the framework owns protocol errors and form completion.
+
+An optional `raw.update(state)` adapter returns `{ type, payload }` for non-HTML
+clients. Optional `raw.reject(message)` returns an uncorrelated display event.
+Redweb performs the final authorized send, not the adapter. State events are
+uncorrelated; successful raw requests complete with `redweb:result`, while safe
+rejections use correlated protocol errors. With redweb-client use
+`request(type, payload, { responseType: 'redweb:result' })` and subscribe to state
+separately. This is an opt-in completion contract, not a silent change to existing
+raw handlers. Custom adapters must not send from inside their callbacks.
+
+## Socket-bound pages (0.15.0)
+
+Added in Redweb 0.15.0 with redweb-client 0.3.0, installed automatically by Redweb.
+Earlier Redweb 0.14.0/client 0.2.0 packages do not provide this extension.
+Contributors editing both packages can use the optional npm-link workflow in the repository's `docs/CLIENT_DEVELOPMENT.md`.
+
+A live page can attach to a registered custom `SocketRoute` using
+`@page('/', { socket: MatchRoute })`. There is no new view class, no second renderer,
+and no application-specific browser module. Its connection carries ordinary typed
+commands and reserved `redweb:*` rendering/completion messages.
+
+## Typed controls
+
+`defineSocketContract(...).handler(type, callback)` still returns a handler class.
+That class can now be used as a JSX binding:
+
+```tsx
+<form rw-submit={Join}>
+    <input name="room" required />
+    <button>Join room</button>
+</form>
+
+<button rw-click={Move.with({ cell, revision })}>Move</button>
+```
+
+`.with()` snapshots JSON data; it never invokes the handler during rendering.
+TypeScript checks the payload's input type. Incoming wire data is independently
+validated by the contract, including asynchronous schemas. Form fields merge over
+the bound object payload. A click sends its bound payload, or an empty object when
+none was supplied. Bound values are untrusted inputs, not server-held secrets or
+authorization capabilities. Do not embed private data in them.
+
+Bindings are server-owned identities, not arbitrary function closures. Rendering
+rejects references to handlers absent from the attached route, even if a different
+handler has the same message name. Existing string `rw-click`/`rw-submit` actions
+remain unchanged on ordinary live pages. Socket-bound pages dispatch only their
+custom route handlers; do not mix local `@action()`/`rw-bind` commands into them.
+
+## Server-owned client state
+
+On an attached connection, `socket.page(PageClass)` returns that connection's
+concrete page after checking its class, ownership and active lifetime:
+
+```ts
+if (socket.page) {
+    socket.page(GamePage).game = games.snapshot(room, account);
+}
+```
+
+Assigning `@state()` fields uses the existing reactive renderer and keyed TSX.
+Raw connections have no `page` accessor and keep their existing socket protocol.
+Shared domain state belongs in a room/service; each private page receives only its
+authorized perspective. Components remain ordinary page-owned Redweb components.
+
+## Configuration and boundaries
+
+Register the route once in `defineApp({ pages: [GamePage], sockets: [MatchRoute] })`.
+Socket-bound pages must be live, connection-scoped and render TSX. Their route must
+support protocol version `1` with the default `redwebVersion` query parameter and
+explicitly allow duplicate connections (independent tabs). `redweb:*` handler names
+are reserved. Page-enabled routes use ordered, bounded message dispatch and track
+in-flight work for shutdown. JSON commands are supported; binary input is rejected
+on page-attached connections. Raw route connections retain binary handling.
+
+The adapter preserves route admission, origin and placement policies, then checks
+the page token, exact route, page identity and page origin. Use `authenticate` for
+page identity and `authorize` for current permissions/session validity. Authorization
+runs before commands, again after contract validation, and before render publication.
+Revocation and disconnect cancel ownership even when validation is still running.
+The page token is not a substitute for credentials.
+
+Initial page attachment completes before custom initialization hooks or commands.
+Do not call page commands from initialization hooks expecting those hooks themselves
+to finish first. Each page owns its connection; the same token cannot attach twice.
+
+Reconnect reauthenticates, invokes existing `connected()` hooks, and sends a fresh
+rendering snapshot. Game-seat recovery remains in that server hook. Commands are
+not queued or replayed. Page-session expiration requires a reload; game persistence
+is not provided by page retention.
+
+## Completion and client runtime
+
+After successful handler dispatch, Redweb sends a correlated `redweb:result`.
+The generated runtime waits specifically for that terminal type or a protocol error,
+not intermediate correlated progress messages. Direct client users can opt into
+the same behavior using `client.request(type, payload, { responseType })`; omitting
+the option preserves the existing any-correlated-response behavior.
+
+For an expected application rejection, send a safe correlated error with
+`socket.sendProtocolError('GAME_REJECTED', safeMessage, { requestId })` and return
+`false` from the handler. Only literal `false` declines successful dispatch;
+`undefined` remains success. The browser shows error feedback, preserves the form,
+and keeps its connection usable. Returning `false` without sending a correlated
+reply leaves a requesting client waiting until its deadline. Unexpected exceptions
+retain the existing sanitized handler-failure behavior and close the connection.
+
+This browser support lives in redweb-client's existing feedback/transport modules.
+The server still owns validation, authorization, game revisions, room fan-out and
+private rendering. Disabled controls are presentation, never permissions.

package/docs/SOCKET_PAGE_RELEASE_PREPARATION.md

@@ -1,120 +1,120 @@
-# Socket-page release preparation
-
-Updated 2026-09-02. The maintainer published client 0.3.0; no core publication or
-hosting deployment was performed during this preparation.
-
-## Client publication verified
-
-`redweb-client@0.3.0` was published from the sibling client checkout on
-`codex/socket-page-actions`, commit `3d2bcfec75db367b6e4924bcf430670f5569b1c7`.
-Its package version and lockfile agree, release notes are included, and prepack
-rebuilds the ESM/CommonJS bundles and declarations. Build logs use stderr so
-`npm pack --json` remains machine-readable.
-
-After npm's processing delay, the actual public registry returned version 0.3.0,
-the same source commit, and the tested candidate integrity below. A fresh local
-pack independently reproduced the publication's SHA-1
-`def8dcc0bb205ccff68bf8fd1c7ea91b7d289547`, 14 files and 31,378 bytes.
-
-```text
-sha512-hUBa40wdsvWKY5bqeyreDzUhMcaB0e0x0OX+YRyZw6ccri6BBSHnM6eEKMV0wOkprIF2cxDkGNILwAA5ELYkWw==
-```
-
-Core's real dependency installation now resolves that registry artifact, not a
-link. Its lockfile records the actual registry URL and integrity. This verifies
-artifact identity, not a claim that client provenance was available.
-
-## Finish the dependent releases afterward
-
-1. Completed: verify client 0.3.0 registry metadata and install the actual artifact.
-2. Redweb **0.15.0** now has `redweb-client@^0.3.0`, its real npm lockfile,
-   versioned changelog and immutable 69-page 0.15.0 documentation snapshot.
-   The final gates below passed; core is ready for manual publication.
-3. After core publication, update site/tutorial exact dependency pins and locks,
-   synchronize the released catalogue, run the downloadable-archive/browser gates,
-   then hand off manual Firebase deployment.
-
-No future registry URL, integrity value or already-published version was fabricated
-in a lockfile. The site's development tutorial remains undeployable with its
-previous published pins; its candidate-archive tests are not evidence that core
-0.15.0 is already published. Do not deploy it before step 3.
-
-## Verification completed
-
-- Client `npm test`: build, declarations, unit tests, mock-free HTTP/WS integration,
-  and headed Chrome passed. Original-source coverage remains 800 statements,
-  543 branches, 125 functions and 667 lines, all 100%. Report:
-  `coverage/client-source/af576edc-b382-424b-97a2-bd46ca163832/summary.json`.
-- The actual client tarball installs in a fresh, unlinked application with released
-  Redweb 0.14.0. Both module formats and the optional live-html entry load; native
-  socket requests wait for terminal replies and preserve null payloads. Actual
-  nested HTTP form parsing and the installed Express/body-parser qs versions pass.
-  Run the opt-in regression with `REDWEB_VERIFY_CLIENT_RELEASE=1` and
-  `tests/integration/client-release.integration.test.js`; it rebuilds/packs the
-  sibling client and uses the existing owned-workspace/process helpers.
-- After installing registry client 0.3.0, 308 core tests across 29 suites pass.
-  Every `src/htmx/*.js` module, `src/cli/templates.js`, and the socket
-  `BaseHandler`, `SocketContract`, `SocketAction` and `HandlerGuard` modules
-  reach 100% statements, branches, functions and lines. This is scoped coverage,
-  not whole-repository certification. Report: `coverage/socket-page-release`.
-- Canonical examples, protocol declarations, all three TypeScript configurations,
-  generated documentation and the prepublication release check pass.
-- The actual downloadable tutorial archive passes independent installation,
-  compilation, type tests, mock-free HTTP/WS/SQLite tests, all-four 100% coverage
-  of its game/schema modules, and headed Chrome acceptance. The explicit pair was
-  core 0.15.0 candidate plus a client 0.3.0 pack byte-identical to npm's artifact;
-  no developer links were used inside the extracted application. Its unchanged
-  old dependency pins still need replacement after core publication.
-- Core's production audit reports zero vulnerabilities under its application-root
-  qs policy. The installed dependency signature audit verifies 428 registry
-  signatures and 31 attestations; this aggregate does not claim every package has
-  provenance.
-- Fresh site/tutorial locked installs audit with zero reported vulnerabilities.
-  The site build, 438-page HTTP/link verification and its seven-module 100%
-  documentation coverage scope pass. After restoring npm links, the headed
-  three-player tutorial passes login, rejection/input retention, moves, reconnect,
-  disconnect presence, win and logout.
-- The complete isolated core package gate passes against registry client 0.3.0
-  without a candidate-client override: headed counter/chat/cards/components/JSX,
-  private dashboard login and actions, reconnect/disconnect, all six generated
-  starters and source-free execution, executable documentation and static export.
-  Bundled Live HTML and browser-refresh coverage each remain all-four 100%.
-  Report: `coverage/packed-browser/2cc05d98-d6b7-4c54-b5ce-fef4cbb83053`.
-  The tested core archive SHA-256 was
-  `1fd3fe3b35fd8ec0f9e805df9c3ad6655af40f373e38b44ab0418db71660eb1a`;
-  the subsequent evidence-only update to this file changes the final archive hash,
-  not its runtime, recipes, declarations or versioned catalogue.
-- The independent senior critic approved the release metadata, actual installed
-  client identity and catalogue consistency with no blocking findings. Core
-  publication dry run passes. No soak or long fixed-window tests were run.
-
-## Manual next step
-
-Publish from the clean `codex/socket-page-actions` core checkout:
-
-```powershell
-Set-Location C:\Users\arkam\Documents\redweb
-$env:NODE_OPTIONS = '--use-system-ca'
-npm publish
-```
-
-The system-trust-store option preserves TLS verification. Do not disable TLS
-checks. Do not publish the client again or deploy the site yet. After core is
-available in npm, replace the site's/tutorial's old pins with verified registry
-dependencies and synchronize the 0.15.0 catalogue before rebuilding and deploying.
-
-## Dependency mitigation, not a library-level promise
-
-Core development, generated applications, the site and the tutorial now use an
-application-root override scoped to the Express dependency subtree:
-`{ "express": { "qs": "6.16.0" } }`. Their checked locks and the fresh packed-client
-consumer audit report zero known vulnerabilities. Actual Express and body-parser
-both resolve the patched qs version. The generator reuses the root policy rather
-than maintaining a separate starter copy.
-
-The override does not upgrade Express or affect unrelated dependency subtrees.
-It also does **not** propagate from Redweb when another application installs it:
-existing consumers must apply the documented root policy and verify their own
-locks/tests. See [release trust](RELEASE_TRUST.md#temporary-express-4-dependency-mitigation)
-for the maintainer advisories and npm's override rules. Ordinary installs without
-the policy can remain affected until upstream dependency ranges are patched.
+# Socket-page release preparation
+
+Updated 2026-09-02. The maintainer published client 0.3.0; no core publication or
+hosting deployment was performed during this preparation.
+
+## Client publication verified
+
+`redweb-client@0.3.0` was published from the sibling client checkout on
+`codex/socket-page-actions`, commit `3d2bcfec75db367b6e4924bcf430670f5569b1c7`.
+Its package version and lockfile agree, release notes are included, and prepack
+rebuilds the ESM/CommonJS bundles and declarations. Build logs use stderr so
+`npm pack --json` remains machine-readable.
+
+After npm's processing delay, the actual public registry returned version 0.3.0,
+the same source commit, and the tested candidate integrity below. A fresh local
+pack independently reproduced the publication's SHA-1
+`def8dcc0bb205ccff68bf8fd1c7ea91b7d289547`, 14 files and 31,378 bytes.
+
+```text
+sha512-hUBa40wdsvWKY5bqeyreDzUhMcaB0e0x0OX+YRyZw6ccri6BBSHnM6eEKMV0wOkprIF2cxDkGNILwAA5ELYkWw==
+```
+
+Core's real dependency installation now resolves that registry artifact, not a
+link. Its lockfile records the actual registry URL and integrity. This verifies
+artifact identity, not a claim that client provenance was available.
+
+## Finish the dependent releases afterward
+
+1. Completed: verify client 0.3.0 registry metadata and install the actual artifact.
+2. Redweb **0.15.0** now has `redweb-client@^0.3.0`, its real npm lockfile,
+   versioned changelog and immutable 69-page 0.15.0 documentation snapshot.
+   The final gates below passed; core is ready for manual publication.
+3. After core publication, update site/tutorial exact dependency pins and locks,
+   synchronize the released catalogue, run the downloadable-archive/browser gates,
+   then hand off manual Firebase deployment.
+
+No future registry URL, integrity value or already-published version was fabricated
+in a lockfile. The site's development tutorial remains undeployable with its
+previous published pins; its candidate-archive tests are not evidence that core
+0.15.0 is already published. Do not deploy it before step 3.
+
+## Verification completed
+
+- Client `npm test`: build, declarations, unit tests, mock-free HTTP/WS integration,
+  and headed Chrome passed. Original-source coverage remains 800 statements,
+  543 branches, 125 functions and 667 lines, all 100%. Report:
+  `coverage/client-source/af576edc-b382-424b-97a2-bd46ca163832/summary.json`.
+- The actual client tarball installs in a fresh, unlinked application with released
+  Redweb 0.14.0. Both module formats and the optional live-html entry load; native
+  socket requests wait for terminal replies and preserve null payloads. Actual
+  nested HTTP form parsing and the installed Express/body-parser qs versions pass.
+  Run the opt-in regression with `REDWEB_VERIFY_CLIENT_RELEASE=1` and
+  `tests/integration/client-release.integration.test.js`; it rebuilds/packs the
+  sibling client and uses the existing owned-workspace/process helpers.
+- After installing registry client 0.3.0, 308 core tests across 29 suites pass.
+  Every `src/htmx/*.js` module, `src/cli/templates.js`, and the socket
+  `BaseHandler`, `SocketContract`, `SocketAction` and `HandlerGuard` modules
+  reach 100% statements, branches, functions and lines. This is scoped coverage,
+  not whole-repository certification. Report: `coverage/socket-page-release`.
+- Canonical examples, protocol declarations, all three TypeScript configurations,
+  generated documentation and the prepublication release check pass.
+- The actual downloadable tutorial archive passes independent installation,
+  compilation, type tests, mock-free HTTP/WS/SQLite tests, all-four 100% coverage
+  of its game/schema modules, and headed Chrome acceptance. The explicit pair was
+  core 0.15.0 candidate plus a client 0.3.0 pack byte-identical to npm's artifact;
+  no developer links were used inside the extracted application. Its unchanged
+  old dependency pins still need replacement after core publication.
+- Core's production audit reports zero vulnerabilities under its application-root
+  qs policy. The installed dependency signature audit verifies 428 registry
+  signatures and 31 attestations; this aggregate does not claim every package has
+  provenance.
+- Fresh site/tutorial locked installs audit with zero reported vulnerabilities.
+  The site build, 438-page HTTP/link verification and its seven-module 100%
+  documentation coverage scope pass. After restoring npm links, the headed
+  three-player tutorial passes login, rejection/input retention, moves, reconnect,
+  disconnect presence, win and logout.
+- The complete isolated core package gate passes against registry client 0.3.0
+  without a candidate-client override: headed counter/chat/cards/components/JSX,
+  private dashboard login and actions, reconnect/disconnect, all six generated
+  starters and source-free execution, executable documentation and static export.
+  Bundled Live HTML and browser-refresh coverage each remain all-four 100%.
+  Report: `coverage/packed-browser/2cc05d98-d6b7-4c54-b5ce-fef4cbb83053`.
+  The tested core archive SHA-256 was
+  `1fd3fe3b35fd8ec0f9e805df9c3ad6655af40f373e38b44ab0418db71660eb1a`;
+  the subsequent evidence-only update to this file changes the final archive hash,
+  not its runtime, recipes, declarations or versioned catalogue.
+- The independent senior critic approved the release metadata, actual installed
+  client identity and catalogue consistency with no blocking findings. Core
+  publication dry run passes. No soak or long fixed-window tests were run.
+
+## Manual next step
+
+Publish from the clean `codex/socket-page-actions` core checkout:
+
+```powershell
+Set-Location C:\Users\arkam\Documents\redweb
+$env:NODE_OPTIONS = '--use-system-ca'
+npm publish
+```
+
+The system-trust-store option preserves TLS verification. Do not disable TLS
+checks. Do not publish the client again or deploy the site yet. After core is
+available in npm, replace the site's/tutorial's old pins with verified registry
+dependencies and synchronize the 0.15.0 catalogue before rebuilding and deploying.
+
+## Dependency mitigation, not a library-level promise
+
+Core development, generated applications, the site and the tutorial now use an
+application-root override scoped to the Express dependency subtree:
+`{ "express": { "qs": "6.16.0" } }`. Their checked locks and the fresh packed-client
+consumer audit report zero known vulnerabilities. Actual Express and body-parser
+both resolve the patched qs version. The generator reuses the root policy rather
+than maintaining a separate starter copy.
+
+The override does not upgrade Express or affect unrelated dependency subtrees.
+It also does **not** propagate from Redweb when another application installs it:
+existing consumers must apply the documented root policy and verify their own
+locks/tests. See [release trust](RELEASE_TRUST.md#temporary-express-4-dependency-mitigation)
+for the maintainer advisories and npm's override rules. Ordinary installs without
+the policy can remain affected until upstream dependency ranges are patched.