Release checklist

The required security, compatibility, browser, packaging, documentation, upgrade, and rollback evidence for every Ownfold release.

Run pnpm release:check from a clean checkout before publishing. It executes formatting, strict type checking, package builds, API Extractor, immutable format compatibility tests, unit and adapter tests, publish-content validation for every SDK tarball, the Playwright browser matrix, Blume documentation validation, and Changesets status.

Required evidence

• Every user-visible or public API change has a Changeset.
• The complete dependency audit, including build and documentation tooling, reports no known moderate, high, or critical vulnerabilities.
• API Extractor reports were intentionally reviewed and committed.
• PersistedFormatSupport matches all parsers, writers, fixtures, and format documentation.
• PersistedCryptoCapabilities.current matches every cryptographic reader, writer, fixed KDF parameter, compatibility fixture, and supported rolling-deployment pair.
• Database adapters pass the shared compliance suite against their supported database versions.
• The real PostgreSQL lane passes for direct node-postgres, Drizzle, and a generated Prisma Client against a fresh disposable database; it does not use destructive reset flags. PGlite-only or structural-mock-only results are not accepted as release evidence.
• Recovery, device enrollment, activity tracking, revocation, pairing, locking, and interrupted rotation paths pass.
• The required 4,097-record rotation scale gate resumes after interruption, preserves content ciphertext, and stays within its 30-second operation budget.
• Chromium, Firefox, WebKit, mobile Chromium, and the production-style TanStack Start example pass.
• Application-owned example accessibility scans and keyboard interaction pass.
• Built package contents contain their README and canonical license, and contain no fixtures, secrets, unexpected source maps or framework dependencies, or project-owned runtime endpoints.
• All packed package roots and public subpaths install, type-check, and runtime-import from a clean temporary consumer with no workspace links.
• Production browser assets and real cryptographic operations remain within the reviewed performance budgets.
• Upgrade order, database migrations, observability, rollback conditions, and the incident owner are recorded for the consuming application.

Production-beta gates

The aggregate automated gate proves the repository candidate, not independent assurance. Before a production-grade beta claim, also record:

• an independent cryptographic and application-security review with release-blocking findings resolved or explicitly disclosed;
• the complete manual assistive-technology matrix from Accessibility and browser support;
• a public source repository and successful npm OIDC provenance from the protected release workflow;
• a canonical public documentation URL configured in Blume; and
• installation and lifecycle smoke testing from the actual published tarballs in a clean consumer.
• a successful pnpm release:smoke-registry run against every exact published version.
• representative low-powered device timing and browser-storage behavior from the supported matrix.

See Beta readiness for the evidence boundary. Missing external evidence is a failed gate even when pnpm release:check passes. Record every gate against the exact candidate in the production-beta evidence record, and commission the independent assessment with the security review brief.

Cryptographic changes

Any primitive, parameter, authenticated-data, key hierarchy, serialization, or writer-version change requires a focused security review and ADR update. Add immutable old and new fixtures before changing a writer. Never regenerate an old fixture to make a failing compatibility test pass; first determine why historical bytes can no longer be read.

Publishing

Publish only through the protected, manual release.yml workflow after merging a dedicated version pull request. The workflow requires npm OIDC trusted publishing, public-repository provenance, no pending Changesets, and the complete release gate before publishing and pushing package tags. Verify package tarballs locally before the first public beta. This repository deliberately does not run CI on ordinary pushes; the full verification workflow runs on pull requests reserved for substantial changes. Follow the complete release process.