redweb 0.14.0 → 0.16.0

package/contract.d.ts

@@ -15,9 +15,17 @@ export interface SocketSchema<Input = unknown, Output = Input> {
 export type SocketSchemas = Readonly<Record<string, SocketSchema>>;
 export type ContractInput<Schema extends SocketSchema> = NonNullable<Schema['~standard']['types']>['input'];
 export type ContractOutput<Schema extends SocketSchema> = Awaited<NonNullable<Schema['~standard']['types']>['output']>;
-export type ContractMessage<Schemas extends SocketSchemas> = {
+export type ContractMessage<Schemas extends SocketSchemas> = {
     [Type in keyof Schemas & string]: ProtocolEnvelope<ContractOutput<Schemas[Type]>> & { type: Type };
-}[keyof Schemas & string];
+}[keyof Schemas & string];
+
+declare const socketActionBrand: unique symbol;
+export interface SocketAction { readonly [socketActionBrand]: true; }
+export interface SocketHandler<Input> {
+    new (): BaseHandler;
+    /** Bind a JSON payload to a server-rendered rw-click/rw-submit control. */
+    with(payload: Input): SocketAction;
+}
 
 export interface ContractClient<Schemas extends SocketSchemas> {
     envelope<Type extends keyof Schemas & string>(type: Type, payload: ContractInput<Schemas[Type]>, metadata?: ProtocolMetadata):
@@ -36,7 +44,7 @@ export interface SocketContract<Schemas extends SocketSchemas> {
     handler<Type extends keyof Schemas & string>(type: Type, callback: (
         socket: RedWebSocket, payload: ContractOutput<Schemas[Type]>,
         message: ProtocolEnvelope<ContractOutput<Schemas[Type]>> & { type: Type },
-    ) => unknown): new () => BaseHandler;
+    ) => unknown): SocketHandler<ContractInput<Schemas[Type]>>;
     client(socket: SendableSocket): ContractClient<Schemas>;
     send<Type extends keyof Schemas & string>(socket: RedWebSocket, type: Type, payload: ContractInput<Schemas[Type]>, metadata?: ProtocolMetadata): Promise<boolean>;
 }

package/docs/CLI.md

@@ -4,7 +4,7 @@ Use the version installed in your project (`npx --no-install redweb`) when troub
 
 ## Add pages, components, and socket routes
 
-These commands are available in `redweb@0.14.0`.
+These commands are available in `redweb@0.15.0`.
 
 ```sh
 npx --no-install redweb add page dashboard

package/docs/CLIENT_DEVELOPMENT.md

@@ -1,12 +1,16 @@
 # Developing Redweb with redweb-client
 
 The Live HTML implementation is maintained in published `redweb-client/live-html`
-starting with client 0.2.0. This Redweb development branch requires `^0.2.0`;
+starting with client 0.2.0. Redweb 0.15.0 requires client `^0.3.0`;
 normal application installation retrieves it automatically. The linking workflow
 below is optional for contributors editing both repositories.
 Redweb serves that module and emits only its import and `mountLivePage()` call.
-DOM reconciliation, reactive updates, delegated actions, form feedback and page
-disposal belong to the client. The root `redweb-client` entry remains socket-only.
+DOM reconciliation, reactive updates, delegated actions, form feedback and page
+disposal belong to the client. The root `redweb-client` entry remains socket-only.
+
+Socket-bound TSX command bindings and terminal-response filtering use the published
+client 0.3.0 runtime. No link is needed for applications using Redweb 0.15.0.
+See [socket pages](SOCKET_PAGES.md).
 
 ## Link the sibling repositories
 
@@ -107,7 +111,7 @@ For example, from Redweb in PowerShell (use a fresh output directory):
 npm --prefix ../redweb-client run build
 New-Item -ItemType Directory -Path coverage/client-candidate
 npm pack ../redweb-client --pack-destination coverage/client-candidate
-$env:REDWEB_CLIENT_CANDIDATE = (Resolve-Path coverage/client-candidate/redweb-client-0.2.0.tgz).Path
+$env:REDWEB_CLIENT_CANDIDATE = (Resolve-Path coverage/client-candidate/redweb-client-0.3.0.tgz).Path
 npm run verify:live-html:package
 Remove-Item Env:REDWEB_CLIENT_CANDIDATE
 ```
@@ -143,7 +147,7 @@ bundles with the source-tested local build and run the same browser checks.
 A candidate pass is not a registry release pass. `npm run verify:package:tools` includes the fingerprint/containment
 unit regressions; its scoped coverage is not coverage of every browser driver.
 
-Published `redweb-client@0.2.0` supplies both required entry points; version 0.1.0
+Historically, published `redweb-client@0.2.0` supplied both required entry points; version 0.1.0
 does not. The 0.2.0 archive's runtime bundles match the previously source-tested
 build, and the clean registry-installed package gate passes without an override.
 The developer link can remain in place because registry checks own independent

package/docs/CONNECTED_CLIENTS_VERIFICATION.md

@@ -0,0 +1,65 @@
+# Connected-client implementation verification
+
+Date: 2026-09-02. Runtime commit: `e001a58`, branch `codex/connected-clients`.
+This is an unreleased development feature, not the published Redweb 0.15.0 package.
+No client source changes or client publication are required; tests use published
+redweb-client 0.3.0.
+
+## Scope
+
+`connectedClients` composes the existing RoomRegistry, bounded authorization,
+projection work, typed socket handlers and private page ownership. It introduces
+no second membership registry. The tutorial consumes it on the companion site's
+`codex/tutorial-connected-clients` branch.
+
+## Passed gates
+
+- `npm run pretest`: generated examples, protocol types, development documentation
+  and all three TypeScript consumer configurations.
+- 368 unit/integration tests in 25 suites: socket servers/routes, connected clients,
+  room access, multiplayer policies/state, protocol/contracts, socket pages,
+  distribution, inspection, page access and the existing HTML test directory.
+- Coverage: 100% statements, branches, functions and lines in **ConnectedClients.js,
+  RoomRegistry.js, RouteRuntime.js and SocketRoute.js**. Report:
+  `coverage/connected-client-rooms`. This is an affected-module claim, not a claim
+  that every module in the repository was measured by this command.
+- `npm run verify:live-html:package`: actual tarball installed in isolation;
+  counter, chat, reconnect/disconnect, cards, components, JSX, dashboard login,
+  generated starters, rendering and development-refresh browser checks passed.
+  Browser: headed Google Chrome 152.0.7977.64. Existing bundled HTML-runtime and
+  refresh coverage gates also reached 100% in their declared scopes.
+- Production dependency audit: zero reported vulnerabilities.
+
+Packed runtime SHA-256 (before adding this evidence document):
+`818bfeb32683089b883bd88f2cef8ac444a8611365a9fe121b4fe2d6b597e540`.
+Package verification report:
+`coverage/packed-browser/8a79c650-cf59-460b-b024-ad791406147f`.
+The archive retains the development checkout's 0.15.0 manifest version; it is
+**not** the npm release bearing that version and must not be published over it.
+
+## Real-network regressions
+
+Independent tabs receive separate private pages; presence counts unique identities
+and reacts to the last tab disconnecting. Tests also cover capacity before domain
+commit, rejected-join membership rollback, room isolation, authorization revoked
+during validation/projection, stale successful and failed projections, failing
+recipients, page-only groups, raw clients and overlapping commands.
+
+Senior critic findings were fixed and regression-tested:
+
+1. A stale authorization/projection failure cannot disconnect a newer valid view.
+2. Raw command completion is independent of superseded state projections.
+3. Raw rejection adapters are bounded and cancel when the connection closes.
+
+No soak or long fixed-observation-time tests were run. Test timeouts are failure
+deadlines. Application callbacks still must validate before mutating domain state;
+membership rollback is not an arbitrary application/database transaction.
+
+## Release boundary
+
+The implementation above was tested as unreleased. Release preparation now targets
+**0.16.0**, with matching package/lock metadata and a generated immutable release
+catalogue. This preparation does not publish the package or change runtime code.
+After publication, update the site's dependency pins, lockfiles and catalogue;
+remove development-preview notices and retest the archive against registry packages
+before manual deployment. Immutable published documentation snapshots are unchanged.

package/docs/DEVELOPMENT.md

@@ -1,6 +1,6 @@
 # Development refresh and inspection
 
-This API is available in `redweb@0.14.0`. Use documentation matching the installed package before enabling it.
+This API is available in `redweb@0.15.0`. Use documentation matching the installed package before enabling it.
 
 ## Browser refresh
 

package/docs/GETTING_STARTED.md

@@ -47,7 +47,7 @@ For private raw socket subscriptions, see [room authorization and shared request
 
 Build first. Deploy `dist/`, the package manifest, and the lockfile, then install runtime dependencies with `npm ci --omit=dev`. The starters are tested with `src/` unavailable after compilation. Configure HTTPS/WSS and a proxy that supports WebSocket upgrades when using a reverse proxy.
 
-These deployment commands require a verified release pair. `redweb@0.14.0` installs published `redweb-client@0.2.0` automatically through its dependency. Future unreleased Redweb changes require their matching tested tarball until a release containing them is published. The `npm link` workflow is local development only: a clean production install does not preserve that link.
+These deployment commands require a verified release pair. `redweb@0.15.0` installs published `redweb-client@0.3.0` automatically through its dependency. Future unreleased Redweb changes require their matching tested tarball until a release containing them is published. The `npm link` workflow is local development only: a clean production install does not preserve that link.
 
 Before public access, add authentication, authorization, trusted-origin policy, input/rate limits, application persistence where needed, and bounded shutdown. Treat reconnect/session tokens as credentials. Do not promise exactly-once delivery or durable sessions from an in-memory starter. See [operations](MULTIPLAYER_OPERATIONS.md) and [guarantees and limits](PRODUCTION_READINESS.md).
 

package/docs/LIVE_HTML.md

@@ -340,7 +340,7 @@ The same bounded validation implementation is shared with socket contracts. Thei
 
 ## Action authorization
 
-Identity and permission are separate: the server's existing `authenticate(request)` hook establishes `context.principal`; an action policy decides whether that identity may perform this operation. In Redweb 0.14.0, add `authorize` to the action decorator instead of repeating permission checks inside each method:
+Identity and permission are separate: the server's existing `authenticate(request)` hook establishes `context.principal`; an action policy decides whether that identity may perform this operation. In Redweb 0.15.0, add `authorize` to the action decorator instead of repeating permission checks inside each method:
 
 ```tsx
 // Inside a page/component; `input` is the amount schema from the example above.
@@ -365,7 +365,7 @@ Denial returns recoverable `ACCESS_DENIED`; timeout returns `ACCESS_TIMEOUT`; co
 
 ## Protected pages and shared request identity
 
-In Redweb 0.14.0, a page can declare `authorize(context)` alongside its route. This is an API pattern for an application that already supplies the server's `authenticate(request)` hook, not a standalone login system:
+In Redweb 0.15.0, a page can declare `authorize(context)` alongside its route. This is an API pattern for an application that already supplies the server's `authenticate(request)` hook, not a standalone login system:
 
 ```tsx
 @page('/account/:id', {

package/docs/MIGRATION.md

@@ -1,6 +1,6 @@
 # Upgrade an existing Redweb application
 
-Match the installed package to its versioned documentation. Redweb 0.14.0 contains the capabilities described by the 0.14.0 guides; a later development checkout may not match that release. See [release verification](RELEASE_TRUST.md) and the changelog shipped with your selected package. Keep your lockfile and rollback artifact, and run your own real HTTP/WebSocket/browser tests after upgrading.
+Match the installed package to its versioned documentation. Redweb 0.15.0 contains the capabilities described by the 0.15.0 guides; a later development checkout may not match that release. See [release verification](RELEASE_TRUST.md) and the changelog shipped with your selected package. Keep your lockfile and rollback artifact, and run your own real HTTP/WebSocket/browser tests after upgrading.
 
 ## 0.8 migration notes
 

package/docs/RELEASE_TRUST.md

@@ -16,20 +16,43 @@ Redweb is a Node.js HTTP/WebSocket library with server-rendered TSX, not a hoste
 
 Use the [official Node release schedule](https://nodejs.org/en/about/previous-releases) for maintained releases, the [TypeScript decorator documentation](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-0.html#decorators) for the distinction between decorator modes, and [Node's TypeScript limitations](https://nodejs.org/api/typescript.html) for native execution constraints. Current per-commit test evidence and uncompleted checks are recorded in the [release checklist](AGENT_READY_ACCEPTANCE.md), not inferred from this table.
 
-## Pin the package and the documentation together
-
-For a published application, select an exact release, commit its lockfile, and use `npm ci` in CI/deployment. This guide is versioned for 0.14.0. Before registry publication, verify the packed candidate; after publication, repeat these registry checks from a clean application:
+## Pin the package and the documentation together
+
+### Temporary Express 4 dependency mitigation
+
+As verified on 2026-09-02, Express 4.22.2 selects `qs ~6.15.1`; the maintainer's
+[isBuffer advisory](https://github.com/ljharb/qs/security/advisories/GHSA-4mjr-xmp4-gh2g)
+and [bracket-key advisory](https://github.com/ljharb/qs/security/advisories/GHSA-x5fp-wj9c-mxmx)
+identify patched `qs@6.16.0`. Until compatible upstream ranges select that fix,
+use this temporary mitigation in the **application's root** `package.json`:
+
+```json
+{ "overrides": { "express": { "qs": "6.16.0" } } }
+```
+
+Merge it with existing overrides, run `npm install`, commit the resulting lockfile,
+and verify with `npm ls qs`, `npm audit --omit=dev`, and application HTTP/form tests.
+New generated starters include the same policy. It is scoped to Express so it
+does not force unrelated dependency trees onto another `qs` version.
+
+This is an application-level mitigation, not a transparent fix for every Redweb
+consumer. [npm ignores overrides inside installed dependencies](https://docs.npmjs.com/cli/v11/configuring-npm/package-json/#overrides).
+An ordinary installation without this root policy can still select affected
+dependencies. No Express 5 migration, bundled fork or published shrinkwrap is
+introduced. Audit results remain time-sensitive and application-specific.
+
+For a published application, select an exact release, commit its lockfile, and use `npm ci` in CI/deployment. This guide is versioned for 0.15.0. Before registry publication, verify the packed candidate; after publication, repeat these registry checks from a clean application:
 
 ```sh
-npm view redweb@0.14.0 version engines dist.integrity dist.signatures dist.attestations gitHead --json
-npm install --save-exact redweb@0.14.0
+npm view redweb@0.15.0 version engines dist.integrity dist.signatures dist.attestations gitHead --json
+npm install --save-exact redweb@0.15.0
 npm audit signatures
 npm audit --omit=dev
 ```
 
 The signature command must run in the installed application directory. Keep TLS verification enabled and use a current npm CLI; a certificate/trust-store failure is not a reason to disable verification. A lockfile's integrity value detects changed package bytes; registry signatures authenticate registry metadata; provenance, when present and verified, links an artifact to a build/source identity. Vulnerability audit is a separate check against known advisories, not an application penetration test.
 
-Redweb 0.14.0 contains unified application startup, server-rendered TSX, reactive state/actions, complete starters, shared socket contracts, authorization, diagnostics, lifecycle work, and bounded heartbeat grace described by these versioned guides. Keep the package and documentation version aligned; do not mix a development guide or a future checkout with 0.14.0 and assume newer APIs exist.
+Redweb 0.15.0 contains socket-bound TSX controls and connection-owned page state, unified application startup, server-rendered TSX, reactive state/actions, complete starters, shared socket contracts, authorization, diagnostics, lifecycle work, and bounded heartbeat grace described by these versioned guides. Keep the package and documentation version aligned; do not mix a development guide or a future checkout with 0.15.0 and assume newer APIs exist.
 
 Redweb is pre-1.0. Consult the changelog and versioned guide before upgrading, run your own real HTTP/WebSocket/browser tests, and keep a rollback artifact. Patch/minor numbers and a compatible TypeScript build alone do not prove wire compatibility, preserved sessions, database compatibility or application authorization. HTTP-created live-page sessions are process-owned; a restart or rolling replacement does not migrate them automatically. Raw socket protocol versions are negotiated only when the route opts in, and application payload compatibility remains your contract.
 

package/docs/RUNTIME_DIAGNOSTICS.md

@@ -1,6 +1,6 @@
 # Understand failures before retrying
 
-Status: included in `redweb@0.14.0`.
+Status: included in `redweb@0.15.0`.
 
 Authentication identifies a visitor. Authorization decides what that visitor may do. Validation checks an input's shape. An application failure means server code or a dependency failed; it is not evidence that the visitor supplied bad credentials.
 

package/docs/SOCKET_CONTRACTS.md

@@ -1,16 +1,19 @@
 # Shared socket contracts
 
-Status: included in `redweb@0.14.0`.
+Status: included in `redweb@0.15.0`.
 
 A contract declares message payloads once. The same schema supplies runtime validation and inferred TypeScript types for senders and handlers. The URL still selects the route (`/match`), and the envelope's `type` selects an individual handler (`join`, `move`, `resume`). No socket decorators or second action dispatcher are required.
 
-Start with `npx --yes redweb@0.14.0 init my-match --template socket`. The complete maintained example lives in [the socket recipe](../recipes/socket/README.md): [contract](../recipes/socket/contract.ts), [handlers](../recipes/socket/handlers.ts), [server](../recipes/socket/app.tsx), and [real-network tests](../recipes/socket/app.test.cjs).
+Start with `npx --yes redweb@0.15.0 init my-match --template socket`. The complete maintained example lives in [the socket recipe](../recipes/socket/README.md): [contract](../recipes/socket/contract.ts), [handlers](../recipes/socket/handlers.ts), [server](../recipes/socket/app.tsx), and [real-network tests](../recipes/socket/app.test.cjs).
 
 Session ownership is separate from room fan-out. For authenticated group delivery,
 see [room authorization](ROOM_AUTHORIZATION.md) and the complete
 [shared page/private-room example](snippets/room-access.tsx).
 
-## One schema, two sides
+## One schema, two sides
+
+Redweb 0.15.0 also supports [typed handlers in server TSX](SOCKET_PAGES.md)
+with per-connection page state; earlier releases do not include that extension.
 
 Import `defineSocketContract` from `redweb/contract` for a shared module, or from `redweb` in server-only code. The standalone entry does not import the HTTP server or Node socket listener. Browser consumers need a bundler capable of consuming the CommonJS package; this is not a native browser script URL or a React integration.
 

package/docs/SOCKET_PAGES.md

@@ -0,0 +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.

package/docs/SOCKET_PAGE_RELEASE_PREPARATION.md

@@ -0,0 +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.