redweb 0.14.0 → 0.15.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/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,99 @@
+# Server-side TSX for custom socket routes
+
+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.

package/docs/SOCKET_PAGE_VERIFICATION.md

@@ -0,0 +1,85 @@
+# Socket-bound TSX verification
+
+Development verification on 2026-09-02, Windows, Node 22.21.0, headed Chrome 152.
+This records feature acceptance, not an npm release or full-repository certification.
+
+## Implementation and review
+
+Core/client branch: `codex/socket-page-actions`. Site branch:
+`codex/server-tsx-tutorial` in the sibling landing-page checkout.
+
+- Typed handler references and `.with(payload)` reuse contract validation, page
+  ownership, reactive rendering and the existing redweb-client runtime.
+- The tutorial has no application browser module or bundling step. Its private
+  page, game rules, commands, room fan-out and seat recovery live on the server.
+- Independent critic reviews covered core/client and the actual tutorial. Fixed
+  findings included attachment ordering, post-validation disconnect authorization,
+  duplicate-connection policy, intermediate reply correlation, obsolete render
+  cancellation and rejected forms incorrectly reporting success. Final review
+  reported no remaining blocking findings within that scope.
+
+## Passing gates
+
+- 294 tests / 27 suites passed in the rendering regression selection below.
+  Every module in `src/htmx/*.js`, plus `BaseHandler`, `SocketContract`,
+  `SocketAction` and `HandlerGuard`, reached 100% statements, branches, functions
+  and lines. The changed explicit-false dispatch in `SocketRoute` is exercised by
+  real-network tests; this measurement does not claim all of `SocketRoute` or the
+  whole repository is covered by this selection.
+- Client `npm test` passed linkage, build, declarations and the combined original
+  source gate: 800 statements, 543 branches, 125 functions and 667 lines, all 100%.
+  Report: `coverage/client-source/c819157b-6aaa-4020-99f4-152b8df473ed/summary.json`.
+  It runs plain and instrumented Node tests and headed Chrome on real HTTP/WS.
+  The existing instrumentation does not count every optional-chain/V8 branch.
+- Core pretest checked canonical example output, protocol declarations, all
+  TypeScript configurations and 69 generated unreleased documentation pages.
+  The standalone contract entry also bundled for browsers without Node builtins.
+- Site build and real HTTP verification passed: 438 pages, 11 examples, 30 API
+  articles, downloads and internal links. The seven-module documentation coverage
+  scope remains 100% lines, branches and functions.
+- The actual tutorial archive was extracted to a fresh temporary directory,
+  installed with both explicitly packed development candidates (no links),
+  compiled, typechecked and tested with real HTTP, WebSockets and SQLite. Its
+  game-rule and message-schema modules remain all-four 100%; this is not a
+  whole-tutorial/authentication coverage claim.
+- Headed Chrome passed both linked and extracted-package tutorial acceptance:
+  hello world, two-tab server counter, wrong/right login, two-player game,
+  third-player full-room rejection with retained input and reusable connection,
+  reconnect without move replay, disconnect presence, win and logout. Actual
+  outgoing game connections use `/match`; game commands are `join` and `move`.
+- Headed static-site navigation passed both minimal homepage examples, six
+  highlighted chapters, next links and the project download.
+
+New integration tests use actual transports, not mocks. Pure failure-boundary
+units supplement them. No soak or long fixed-window workload was run.
+
+### Reproduce the scoped core coverage gate
+
+```sh
+node node_modules/jest/bin/jest.js tests/htmx tests/ws tests/unit/socket-action.unit.test.js tests/unit/page-access.unit.test.js tests/unit/socket-contract.unit.test.js tests/unit/utilities.unit.test.js tests/unit/action-input.unit.test.js tests/unit/inspection.unit.test.js tests/unit/development-refresh.unit.test.js tests/unit/development-refresh-boundaries.unit.test.js tests/unit/development-refresh-cleanup.unit.test.js tests/unit/define-app.unit.test.js tests/integration/define-app.integration.test.js tests/integration/socket-page.integration.test.js tests/integration/socket-contract.integration.test.js tests/integration/live-html.integration.test.js tests/integration/page-access.integration.test.js tests/integration/action-input.integration.test.js tests/integration/inspection.integration.test.js --runInBand --silent --coverage --collectCoverageFrom=src/htmx/*.js --collectCoverageFrom=src/ws/BaseHandler.js --collectCoverageFrom=src/ws/SocketContract.js --collectCoverageFrom=src/ws/SocketAction.js --collectCoverageFrom=src/ws/HandlerGuard.js --coverageDirectory=coverage/socket-page-regression
+```
+
+The site README documents the two candidate-tarball environment variables for
+`npm test`. That gate includes headed browser acceptance inside the extracted
+archive; Chrome and the tutorial's Node version are required.
+
+## Release boundaries and outstanding dependency audit
+
+The follow-up [release preparation](SOCKET_PAGE_RELEASE_PREPARATION.md) prepares
+client 0.3.0 and records the tested application-root qs mitigation. The initial
+observations below remain historical; they do not override that later status.
+
+The old published versions (Redweb 0.14.0/client 0.2.0) do not contain these APIs.
+Local tarballs retaining those development metadata versions were verification
+inputs, not artifacts to publish over existing releases. Release a new client,
+align and release Redweb, then update the site's tutorial pins/lockfile and
+catalogue before manual deployment. Existing immutable release snapshots were
+not rewritten. Nothing was published or deployed during this task.
+
+An additional `npm audit --omit=dev` check reports four moderate dependency-tree
+entries in the existing site/tutorial locks, rooted in two `qs` advisories:
+[bracket-key parsing](https://github.com/advisories/GHSA-x5fp-wj9c-mxmx) and
+[attacker-controlled isBuffer](https://github.com/advisories/GHSA-4mjr-xmp4-gh2g).
+The installed Express 4 dependency range does not select the published qs 6.16.0
+fix. This feature work does not waive that audit or silently force an Express 5
+migration. Resolve and verify the dependency policy before production release.