redweb 0.13.0 → 0.13.1

package/docs/AGENT_READY_ACCEPTANCE.md

@@ -193,9 +193,9 @@ production-only counter, explicitly installed chat validator, development resour
 and generated additions remain actual consumer checks. See
 `PACKAGED_EXAMPLE_VERIFICATION.md` for exact scope, failure history and identities.
 
-- [ ] Reproducible reconnect, disconnect, slow-client, memory, isolation, authentication, and compatibility evidence, with limits and environment recorded.
+- [x] Reproducible reconnect, disconnect, slow-client, memory, isolation, authentication, and compatibility evidence, with limits and environment recorded.
 - [x] Fresh-agent tasks using only public documentation measure first-pass success and repair effort against objective application checks (one narrowly scoped counter/chat case; not an adoption success rate).
-- [ ] Full 100% statement/branch/function/line coverage, type gates, real-network/browser tests, load/recovery/memory gates, package checks, and audit.
+- [x] Full 100% statement/branch/function/line coverage of the maintained library and explicitly scoped authored verification modules, type gates, real-network/browser tests, load/recovery/memory gates, package checks, and audit; generated V8 decorator counters and diagnostic-only measurements remain labelled rather than presented as this authored-source gate.
 - [ ] README, changelog, examples, website, and evidence agree on shipped behavior; final requirement-by-requirement audit proves every checkbox.
 
 ## Follow-on application ergonomics and adoption
@@ -207,7 +207,7 @@ and generated additions remain actual consumer checks. See
 - [x] Complete persistent cards and authenticated dashboard recipes demonstrate durable data and private updates without adding a database framework to Redweb.
 - [x] Runtime diagnostics distinguish validation, authentication, authorization, and application failures without leaking secrets; retry guidance states actual guarantees.
 - [x] Fresh-agent evaluations separately measure successful use when assigned Redweb and discovery/selection when not instructed to choose it; record first-pass success, repair attempts, time, and independent correctness checks. The assigned counter/chat pass is preserved in `evaluations/2026-08-30-01`; the category-first public-search trial in `evaluations/2026-08-30-02` selected Socket.IO, with no implementation claim. Timing/search sequence are self-reported where not independently observed; host metadata prevents full blinding, and one sample is not a discovery rate.
-- [x] Package provenance and release support/compatibility guidance are documented and verified where available; no claim of provenance as proof of security. Published 0.12.0 signatures were verified; no provenance attestation was returned, and future publication/security-reporting policy remain maintainer actions rather than claimed capabilities.
+- [x] Package provenance and release support/compatibility guidance are documented and verified where available; no claim of provenance as proof of security. Published 0.13.0 signatures were verified; no provenance attestation was returned, and future trusted-publishing/security-reporting policy remain maintainer actions rather than claimed capabilities.
 
 ## Additional developer-experience follow-through
 
@@ -219,11 +219,26 @@ and generated additions remain actual consumer checks. See
 
 ## Client-owned frontend follow-through
 
-- [x] Move reusable generated frontend behavior into `redweb-client` where it simplifies Redweb, with one maintained implementation and no duplicated transport/lifecycle logic (`redweb-client@0.2.0` published and integrated; Redweb publication remains pending).
+- [x] Move reusable generated frontend behavior into `redweb-client` where it simplifies Redweb, with one maintained implementation and no duplicated transport/lifecycle logic (`redweb-client@0.2.0` published and integrated; `redweb@0.13.0` published from the verified merge commit).
 - [x] Verify the hardened client and Redweb together from matching packed artifacts, including counter/chat rendering, cancellation, reconnect, and existing browser regressions; preserve unit and no-mock integration coverage requirements and honest publication boundaries (both local candidate and published-client pairs verified; the separate standalone V8 command remains unresolved).
 
 ## Work log
 
+- Published-release audit (`redweb@0.13.0`, published 2026-09-01 UTC): npm
+  records `gitHead` `7196d504ee65dfaf5ac869ea4bda66d7cf86d015`, the
+  verified merge commit on `main`. All 215 registry files match that commit's
+  content: two byte-for-byte and 213 after Windows CRLF normalization. The
+  per-file hashes are retained in `docs/releases/audit-0.13.0.json`.
+  A clean exact installation with lifecycle scripts disabled
+  passed `npm audit signatures` with no invalid or missing signatures and
+  `npm audit --omit=dev` with zero vulnerabilities; registry metadata contains
+  no provenance attestation. The immutable tarball retains a documentation-only
+  publication defect: its generated catalogue and changelog retain prerelease
+  labels, while its setup guidance and README also describe the release as a
+  development tarball/unreleased. Repository/site sources correct those labels,
+  but a future patch release is required to correct bundled package
+  documentation. Runtime code and public declarations are unaffected.
+
 - `18b1dfd` regression/performance checkpoint (Windows, Node22.21.0,
   2026-08-31): with system certificate authorities and TLS verification retained,
   all178 suites passed:2,017 tests, five platform skips, every pretest/type gate

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
 
-This command is currently **unreleased**, like the other branch-specific capabilities in the README.
+These commands are available in `redweb@0.13.0`.
 
 ```sh
 npx --no-install redweb add page dashboard

package/docs/DEVELOPMENT.md

@@ -1,6 +1,6 @@
 # Development refresh and inspection
 
-This API is **unreleased**. Use the matching packed candidate rather than assuming it exists in the published package.
+This API is available in `redweb@0.13.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-client@0.2.0` is published and installs automatically through the matching Redweb dependency. Unreleased Redweb changes still require the matching tested tarball until their own release 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.13.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.
 
 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. On this unreleased branch, 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.13.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
 
-On this unreleased branch, 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.13.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', {
@@ -434,7 +434,7 @@ The injected module uses the published `redweb-client` package served by the sam
 - `maxSessions`: maximum pending plus active page sessions; defaults to 1,000.
 - `maxConcurrentRenders`: maximum simultaneous HTTP page renders, independent of live session occupancy; defaults to `maxSessions`.
 - `shutdownTimeoutMs`: phase-local render/route drain and final owned-HTTP cleanup timeout, not a total application shutdown deadline; defaults to one second.
-- `heartbeat`: optional `{ intervalMs, timeoutMs }` WebSocket liveness policy. Live HTML defaults to a 15-second ping interval and 10-second pong timeout so half-open browsers are disconnected and component `disconnected()` hooks update presence promptly. An expired pong check is deferred to the event-loop check phase before termination, allowing already-dispatched pong handling to win after a server stall. A silent peer is still terminated by the deferred check. Scheduler latency means `timeoutMs` is a liveness threshold, not a hard wall-clock deadline; use connection and queue limits as the resource bounds.
+- `heartbeat`: optional `{ intervalMs, timeoutMs }` WebSocket liveness policy. Live HTML defaults to a 15-second ping interval and 10-second pong timeout so half-open browsers are disconnected and component `disconnected()` hooks update presence promptly. When a pong first expires, one unreferenced timer gives it an additional `timeoutMs` grace window to reach JavaScript. Pong handling, detach/reattach, and shutdown cancel that owned timer; a peer that remains silent is terminated when it fires. Scheduler latency means `timeoutMs` is a liveness threshold, not a hard wall-clock deadline; use connection and queue limits as the resource bounds.
 - `authenticate`: optional HTTP/WebSocket identity function for binding page sessions to an authenticated principal.
 - `origins`: optional exact origin list or predicate for deployments behind a trusted proxy. Without it, Redweb requires a scheme-and-host match (`http`/WS or `https`/WSS).
 - `livePaths`: optional `{ socket, client, runtime }` internal path overrides.

package/docs/MIGRATION.md

@@ -1,6 +1,6 @@
 # Upgrade an existing Redweb application
 
-Match the installed package to its versioned documentation. This checkout contains unreleased work even while its package metadata still matches an older npm version. 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.13.0 contains the capabilities described by the 0.13.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/PRODUCTION_READINESS.md

@@ -21,11 +21,12 @@ WebSocket provides an ordered byte stream while a connection remains healthy. Re
 
 1. **Bounded transport:** pre-upgrade admission, origin policy, rate limits, slow-consumer enforcement, bounded ordered processing, payload limits, and route-level heartbeat.
 
-Heartbeat expiry is deferred to the event-loop check phase before terminating a
-peer, allowing already-dispatched pong handling to win after a server stall; an
-actually silent peer is terminated by the deferred check.
+The first observation of heartbeat expiry starts one unreferenced `timeoutMs`
+grace timer, allowing already-dispatched pong handling to win after a server
+stall; a peer that remains silent is terminated when that timer fires. Pong,
+detach/reattach, and shutdown cancel the owned timer.
 `timeoutMs` is therefore a liveness threshold subject to event-loop scheduling,
-not a hard wall-clock resource limit. The deferral owns at most one pending check
+not a hard wall-clock resource limit. The grace period owns at most one timer
 per expired connection; bound connections and queues independently.
 2. **Multiplayer grouping:** route-scoped rooms, atomic membership cleanup, bounded session resumption, fixed-step services, and vendor-neutral metrics.
 3. **Horizontal composition:** draining/readiness, adapter lifecycle, loop prevention, bounded validation, placement hooks, and documented partition behavior.
@@ -47,7 +48,7 @@ per expired connection; bound connections and queues independently.
 
 The independent senior-review gate rejects releases that weaken any invariant, hide ambiguous delivery semantics, add mandatory brokers or identity libraries, or substitute coverage percentages for race, load, soak, and failure evidence.
 
-See [operations verification](MULTIPLAYER_OPERATIONS.md#verification) for the current commands and the distinction between server acceptance and the original diagnostic. These are required gates, not a statement that the current development candidate has passed them; consult the [release checklist](AGENT_READY_ACCEPTANCE.md) for outstanding failures.
+See [operations verification](MULTIPLAYER_OPERATIONS.md#verification) for the current commands and the distinction between server acceptance and the original diagnostic. These are required gates, not a statement that every release has passed them; consult the version's [release checklist](AGENT_READY_ACCEPTANCE.md) for recorded results and remaining limitations.
 
 ## Horizontal composition contract
 

package/docs/RELEASE_TRUST.md

@@ -18,36 +18,39 @@ Use the [official Node release schedule](https://nodejs.org/en/about/previous-re
 
 ## 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. The following is an intentionally pinned example, not an instruction to treat `0.12.0` as permanently current:
+For a published application, select an exact release, commit its lockfile, and use `npm ci` in CI/deployment. This example deliberately pins the current documented release:
 
 ```sh
-npm view redweb@0.12.0 version engines dist.integrity dist.signatures dist.attestations gitHead --json
-npm install --save-exact redweb@0.12.0
+npm view redweb@0.13.0 version engines dist.integrity dist.signatures dist.attestations gitHead --json
+npm install --save-exact redweb@0.13.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.
 
-For this branch's **unreleased** features, follow the matching tarball instructions in the [complete starter recipes](GETTING_STARTED.md#start-with-a-complete-recipe). The checkout has package metadata `0.13.0`, reserved for this unreleased candidate; the published `redweb@0.12.0` does not contain these changes. Installing `latest` does not install the unmerged branch. Do not mix a local-candidate guide with an older registry release and assume the APIs exist. Changing the package version does not publish it or satisfy outstanding release checks.
+Redweb 0.13.0 contains the server-rendered TSX, reactive state/actions, complete starters, shared socket contracts, authorization, diagnostics and lifecycle work described by these versioned guides. Keep the package and documentation version aligned; do not mix a development guide or a future checkout with 0.13.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.
 
 ## What was verified for the published package
 
-Read-only registry inspection on **2026-08-30** reported `latest: 0.12.0`, with:
+Read-only registry inspection after publication on **2026-09-01 UTC** reported `latest: 0.13.0`, with:
 
-- `gitHead`: `6c95093c5e3b357772841f40c5371359dab0bf03`.
-- SHA-512 integrity: `sha512-74AOoEmREkoPElYB9nalsN8nLfiPzw1Ap3WYEwxERJqoSGcfYAQhyfpAK2dOyLQtc+A+sAl9fFv0HMuIXWDjEg==`.
-- Registry signatures present; **no `dist.attestations` field was returned**. Build provenance is therefore not claimed for this release.
+- `gitHead`: `7196d504ee65dfaf5ac869ea4bda66d7cf86d015`, the verified merge commit on `main`.
+- SHA-512 integrity: `sha512-n5OQl214vC6ithpfg6QyhAmaOtjY8AYEGrWZGl8LxdSCyagD1K2bvplcxhQOruZP3exwkIyRPnhIuFe9rIcQFQ==`.
+- SHA-1 registry checksum: `1ff22dbd2a5c3d8eafad219055f01fe5b85b9d10`.
+- Registry signature present; **no `dist.attestations` field was returned**. Build provenance is therefore not claimed for this release.
 
-An independently created temporary application installed that exact package with lifecycle scripts disabled and ran `npm audit signatures --json` using Node 22.21.0/npm 11.6.2 and the Windows system trust store. It exited successfully with `invalid: []` and `missing: []`. That checks the installed registry dependency tree's signatures/available attestations; an empty failure list does **not** mean every package has build provenance. This historical observation is not a verification of a future release or of the current unreleased source.
+An independently created temporary application installed that exact package with lifecycle scripts disabled and ran `npm audit signatures --json` using Node 22.21.0/npm 11.6.2 and the Windows system trust store. It exited successfully with `invalid: []` and `missing: []`; `npm audit --omit=dev --json` reported zero vulnerabilities. All 215 published files matched content at the recorded `gitHead`: two byte-for-byte and 213 after normalizing Windows CRLF materialization to Git's LF blobs. The retained release audit receipt at `docs/releases/audit-0.13.0.json` records the archive hashes and every published/Git file hash. These checks authenticate and compare the observed artifact; they do not certify the application, prove every dependency has build provenance, or verify a future release.
+
+The immutable 0.13.0 tarball has a known documentation-only release-process defect. Its bundled `docs/generated.json` says `channel: "unreleased"`; its changelog says 0.13.0 was not yet published; and its README uses development-tarball setup, calls that setup prerelease/development-only, and later says Redweb remains unreleased. Runtime files and public declarations match the verified merge commit. The repository and website sources correct those labels. The repository's `docs/releases/0.13.0.json` is therefore a corrected **post-publication** documentation snapshot for 0.13.0, not the catalogue that shipped inside the immutable 0.13.0 tarball. A future patch release is required to deliver the corrected bundled documentation to npm consumers.
 
 The commands above let you repeat the check. See npm's [signature and attestation verification](https://docs.npmjs.com/cli/v11/commands/npm-audit/) and [viewing provenance](https://docs.npmjs.com/viewing-package-provenance/) documentation for current verification behavior.
 
 ## Publishing provenance is a maintainer action
 
-No publishing workflow or npm account setting is enabled by this guide. To add provenance to a future release, the maintainer must choose an authorized supported build/publish workflow, configure the correct repository identity and npm permissions, publish the exact tested artifact, and verify the resulting registry attestation afterward. A local `npm pack`, `gitHead`, checksum, badge or successful CI run is not a substitute for a verified attestation. Do not label older releases retroactively as provenance-verified.
+The 0.13.0 registry metadata contains a signature but no provenance attestation. To add provenance to a future release, the maintainer must choose an authorized supported build/publish workflow, configure the correct repository identity and npm permissions, publish the exact tested artifact, and verify the resulting registry attestation afterward. A local `npm pack`, `gitHead`, checksum, badge or successful CI run is not a substitute for a verified attestation. Do not label older releases retroactively as provenance-verified.
 
 npm describes the supported providers and identity requirements in [generating provenance](https://docs.npmjs.com/generating-provenance-statements/) and [trusted publishing](https://docs.npmjs.com/trusted-publishers/). Provenance provides origin/build evidence, not proof that source code is safe.
 

package/docs/RUNTIME_DIAGNOSTICS.md

@@ -1,6 +1,6 @@
 # Understand failures before retrying
 
-Status: unreleased on `codex/agent-ready`; these handshake diagnostics are not in npm 0.12.0.
+Status: published in `redweb@0.13.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/SOAK_ROTATION_OBSERVATION.md

@@ -119,10 +119,10 @@ disconnect: a responsive same-process client automatically pongs, while one
 server-side ping callback stalls the event loop beyond the heartbeat deadline.
 Previously the next timer terminated that healthy client before its already
 dispatched pong handling could win. Heartbeat expiry now owns one deduplicated,
-unreferenced `Immediate` per expired socket. The deferred check terminates a peer
-that is still silent; pong handling, detach/reattach, or monitor shutdown makes
-the stale check harmless. No deferred-check allocation occurs on healthy ticks and no timeout is
-reset. Connection/queue limits remain the resource bounds.
+unreferenced grace timer per expired socket. The timer waits one additional
+`timeoutMs` before terminating a peer that is still silent; pong handling,
+detach/reattach, or monitor shutdown cancels it. No grace-timer allocation occurs
+on healthy ticks. Connection/queue limits remain the resource bounds.
 
 The focused heartbeat scope passes71 unit and real-socket tests at100% statements,
 branches, functions and lines. The senior critic required and approved silent-peer,

package/docs/SOCKET_CONTRACTS.md

@@ -1,10 +1,10 @@
 # Shared socket contracts
 
-Status: unreleased on `codex/agent-ready`; not part of npm 0.12.0.
+Status: published in `redweb@0.13.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 redweb init my-match --template socket` after installing a release containing this feature. During development, use the checked-out CLI or packed artifact instead of the published 0.12.0 command. 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.13.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