redweb 0.13.0 → 0.13.2

package/CHANGELOG.md

@@ -2,9 +2,25 @@
 
 ## Unreleased
 
-- Heartbeat timeout enforcement now defers termination to the event-loop check phase, allowing already-dispatched pong handling to win after a server stall. Silent peers remain bounded and are terminated by the deferred check. Unexpected soak close events now preserve the native WebSocket close code and an escaped reason for diagnosis.
+## 0.13.2
+
+Released 2026-09-01 (America/Toronto).
+
+- Ship package-versioned README setup, generated documentation, and the immutable 0.13.2 catalogue snapshot together.
+- Refuse publication when the package version, generated catalogue, README recipe, or release snapshot is unreleased, stale, missing, or inconsistent.
+
+## 0.13.1
+
+Released 2026-09-01 (America/Toronto).
 
-Next package version: `0.13.0` (not yet published).
+- Give an expired WebSocket heartbeat one additional `timeoutMs` grace window before termination. A pong, detach, reattach, or shutdown cancels the owned timer, preventing a delayed Node event loop from disconnecting a responsive peer while keeping silent-peer cleanup bounded.
+- Publication note: the runtime fix shipped, but the archive retained unreleased documentation, omitted a 0.13.1 catalogue snapshot, and recorded a `gitHead` whose committed package version was still 0.13.0. Version 0.13.2 supersedes that release-process defect.
+
+## 0.13.0
+
+Published 2026-08-31 (America/Toronto; 2026-09-01 UTC).
+
+- Heartbeat timeout enforcement now defers termination to the event-loop check phase, allowing already-dispatched pong handling to win after a server stall. Silent peers remain bounded and are terminated by the deferred check. Unexpected soak close events now preserve the native WebSocket close code and an escaped reason for diagnosis.
 
 - Align multiplayer operations and production-readiness guidance with the approved blocking server-recovery command. Keep the original shared-process command and its overrides in a separately labelled diagnostic section; distinguish historical baseline/results from current release acceptance. Add a generated-documentation regression without changing any runtime or verification policy.
 

package/README.md

@@ -9,19 +9,15 @@ Use the same package for a live site, static HTML, Express HTTP endpoints, or ro
 Start with a complete, tested counter application:
 
 <!-- redweb:setup:start -->
-> Unreleased development documentation. Package metadata is 0.13.0, but these features are not claimed to be published in that npm version. Use the matching Redweb tarball described in the recipe setup; its published client dependency installs automatically. Do not install latest and assume compatibility.
-
-Replace `TARBALL` with the absolute path to the matching Redweb tarball produced by `npm pack` (quoted if it contains spaces). This is an explicit prerequisite, not an npm package name. Both commands must use the same tarball. The published redweb-client dependency installs automatically; no separate client checkout or linking is required:
+> Documentation for Redweb 0.13.2. Install that exact version when following these examples.
 
 ```sh
-npx --yes --package TARBALL redweb init my-realtime --template realtime
+npx --yes redweb@0.13.2 init my-realtime --template realtime
 cd my-realtime
-npm install --save-exact TARBALL
+npm install --save-exact redweb@0.13.2
 npm test
 npm run dev
 ```
-
-This prerelease Redweb artifact is development-only until its release checks finish. For released applications, use an available versioned release guide.
 <!-- redweb:setup:end -->
 
 Open two tabs at `http://localhost:8181`. Clicking either button changes the counter on the server and updates both tabs.
@@ -269,7 +265,7 @@ The isolated browser harness copies its verification helpers explicitly and chec
 
 `npm run verify:live-html:browser:coverage` combines the existing full browser workload (counter, chat, CSS, JSX, components, forms and dashboard) with explicit failure-path unit tests. Its 100% authored-tool coverage is separate from frontend coverage and release acceptance. The native workload requires the dashboard's supported Node version. Known limitations of the unchanged legacy browser tool— including uncertain descendant cleanup—are characterized, not silently fixed or counted as verified cleanup; see the [coverage audit](docs/COVERAGE_SCOPE_AUDIT.md).
 
-The frontend is maintained in `redweb-client/live-html`; Redweb emits only a two-line mounting bootstrap. This branch depends on published `redweb-client@^0.2.0`, so ordinary application installation needs no client checkout or link. Contributors editing the client can still use the [linked development workflow](docs/CLIENT_DEVELOPMENT.md). Redweb itself remains unreleased until its remaining release checks finish.
+The frontend is maintained in `redweb-client/live-html`; Redweb emits only a two-line mounting bootstrap. Redweb 0.13.2 depends on published `redweb-client@^0.2.0`, so ordinary application installation needs no client checkout or link. Contributors editing the client can still use the [linked development workflow](docs/CLIENT_DEVELOPMENT.md).
 
 `npm run measure:browser:client` separately serves the exact installed socket-only module with and without instrumentation through the same real HTTP/WebSocket/browser cases and retains its source hash and counters. It exits unsuccessfully until all four coverage metrics reach 100%; incomplete results are not a passing dependency-coverage claim. Reports are local under `coverage/browser-client` and do not alter the installed dependency or published package.
 

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,30 @@ 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
 
+- `0.13.2` release-candidate checkpoint (Windows, Node 22.21.0, 2026-09-01): package and lock metadata, README setup commands, generated catalogue and the immutable `docs/releases/0.13.2.json` snapshot all identify 0.13.2. A new `prepublishOnly` check fails closed when the catalogue channel, README, package version or snapshot differs; its actual subprocess tests cover missing/stale snapshots, unreleased channels, invalid option combinations and successful release checks. The final full run passed all 178 suites: 2,018 tests passed, five platform cases were skipped, every pretest/type check passed, and the maintained Redweb library scope reported 100% statements/branches/functions/lines. Unit tests and no-mock HTTP/WebSocket/browser/clean-installed-consumer integrations remain distinct. The complete packed-package gate passed all counter, chat/reconnect/disconnect, generated TypeScript addition, dashboard, browser-runtime, refresh, source-free recipe and initialized-application checks.
+- Two verifier defects exposed during repeated full runs were corrected without changing runtime behavior or application limits. Generated dashboard tests retain their own five/seven-second process deadlines while the aggregate supervisor now allows 60 seconds under full-system load; five isolated dashboard repetitions, the complete six-starter run and the final full suite passed. The hostile-frame test no longer mistakes a Windows `ws` client lingering in `CLOSING` for a Redweb containment failure after the server has already handled close and emptied its route registry. It now requires exact server registration/release before reconnect and owns local client cleanup; the unchanged two-second containment limit passed 100 consecutive no-mock fuzz runs and the final full suite.
+- Final resource and release gates passed: 3,200 messages/32 clients at 3,454.66 messages/s with p99 56.59 ms and slow-consumer containment; three 500-connection memory trials measured 1,892.608 framework bytes/connection under the 2,048-byte limit; five recovery storms delivered all 7,400 replies and ended at 97.2814% of warmed server heap; Live HTML expired 200 renders with 110 live clients and 8,166,992 bytes heap delta; JSX rendered 10,000 component rows in 51.8 ms with 0.6 MiB retained. A current 30-second smoke soak delivered 17,592/17,596 replies (99.9773%), ended at 93.7786% of warm heap, passed every trend and emptied all final registries. The earlier 3,600-second soak predates the final heartbeat implementation and is not relabelled as current-code evidence. Audit found zero vulnerabilities; 580 installed dependencies had verified registry signatures and 67 had verified attestations. The pre-evidence dry run produced the expected 218-file 0.13.2 archive; the final archive is rechecked after this canonical evidence update rather than recording a self-invalidating hash inside itself. No npm publication or website deployment occurred.
+
+- 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.2`.
 
 ```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.2`. 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.2` 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.2, 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.2, 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.2 contains the capabilities described by the 0.13.2 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,43 @@ 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 guide is versioned for 0.13.2. Before registry publication, verify the packed candidate; after publication, repeat these registry checks from a clean application:
 
 ```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.2 version engines dist.integrity dist.signatures dist.attestations gitHead --json
+npm install --save-exact redweb@0.13.2
 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.2 contains the 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.13.2 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
+## Historical registry verification
 
-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.
+
+Registry inspection after the later 0.13.1 publication reported `gitHead` `db64d5b655d5668a75b587122c9e1e9ef4c9bca1`, SHA-512 integrity `sha512-DCLcmiDj89kXf3+80H5/1W+nQEXIhF8RfiBlU6b/LA7418/ChkzhZ8oV4JmVLDL/nt7zFNcytyjavzrDT/XfoA==`, SHA-1 checksum `c05f3e0dc560d4bb379b8fbd6747c3470fcc31f0`, a registry signature, and no provenance attestation. Its runtime contains the heartbeat correction, but its 217-file immutable archive again labels `docs/generated.json` and the README as unreleased and contains no `docs/releases/0.13.1.json`. Its package version was materialized in the publication workspace rather than committed at the recorded `gitHead`, so 0.13.1 is not presented as a clean source-identical release.
+
+The 0.13.2 release candidate corrects that process: version metadata and lockfile, an empty Unreleased section, registry-pinned README setup, and `docs/releases/0.13.2.json` must exist in the reviewed commit before manual publication. Publish only that clean merged commit, then verify the registry metadata and installed archive before synchronizing the website.
 
 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 and 0.13.1 registry metadata contain signatures but no provenance attestations. 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: included in `redweb@0.13.2`.
 
 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: included in `redweb@0.13.2`.
 
 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.2 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