@rehearsal-db/core 0.1.0-beta.17 → 0.1.0-beta.18

package/CHANGELOG.md

@@ -5,6 +5,25 @@ a Changelog, and versions will follow Semantic Versioning after the package exis
 
 ## Unreleased
 
+## [0.1.0-beta.18] - 2026-10-08
+
+### Added
+
+- A concise stability contract now defines the supported public surface, defects that
+  block the first stable release, and the exact beta-to-RC-to-stable promotion gate.
+- Automated release-policy tests cover beta, release-candidate, stable, malformed, and
+  mismatched GitHub release metadata.
+
+### Changed
+
+- Protected OIDC publication now supports both prerelease and stable versions. Beta and
+  release-candidate versions update `beta`; once a stable version exists they cannot
+  replace `latest`. Stable publication updates `latest` without rewriting `beta`.
+- npm channel selection lives only in the protected release workflow instead of static
+  package metadata, and missing beta.16 and beta.17 changelog comparisons are restored.
+- Vitest's locked patch release is updated from 5.0.2 to 5.0.3 after the complete CI
+  matrix passed.
+
 ## [0.1.0-beta.17] - 2026-10-08
 
 ### Added
@@ -525,7 +544,10 @@ a Changelog, and versions will follow Semantic Versioning after the package exis
   publication uses short-lived trusted OIDC, and every release tag must already exist on
   protected `main`.
 
-[Unreleased]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.15...HEAD
+[Unreleased]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.18...HEAD
+[0.1.0-beta.18]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.17...v0.1.0-beta.18
+[0.1.0-beta.17]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.16...v0.1.0-beta.17
+[0.1.0-beta.16]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.15...v0.1.0-beta.16
 [0.1.0-beta.15]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.14...v0.1.0-beta.15
 [0.1.0-beta.14]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.13...v0.1.0-beta.14
 [0.1.0-beta.13]: https://github.com/Ddupasquier/rehearsal-db/compare/v0.1.0-beta.12...v0.1.0-beta.13

package/README.md

@@ -155,6 +155,7 @@ Reference:
 - [Runtime and local identity policies](docs/runtime-policies.md)
 - [Glossary](docs/glossary.md)
 - [Repository architecture](docs/architecture.md)
+- [Stability and the first stable release](docs/stability.md)
 - [Release process](docs/releasing.md)
 
 ## Getting support

package/dist/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@rehearsal-db/core",
-    "version": "0.1.0-beta.17",
+    "version": "0.1.0-beta.18",
     "private": false,
     "description": "Safely rehearse PostgreSQL and Supabase migrations against sanitized, production-shaped data.",
     "repository": {
@@ -13,7 +13,6 @@
     "homepage": "https://ddupasquier.github.io/rehearsal-db/",
     "publishConfig": {
         "access": "public",
-        "tag": "beta",
         "provenance": true
     },
     "type": "module",

package/docs/README.md

@@ -32,6 +32,7 @@ want to accomplish and follow that path.
 ## Follow the project
 
 - [Roadmap](roadmap.md)
+- [Stability and the first stable release](stability.md)
 - [Repository architecture](architecture.md)
 - [Release process](releasing.md)
 

package/docs/releasing.md

@@ -58,16 +58,21 @@ The independent Rehearsal Test Lab is the primary pre-release consumer environme
 Real product integrations provide additional compatibility evidence; they do not
 replace the package-owned release gate or Test Lab.
 
-The workflow publishes prereleases under the `beta` dist-tag and refuses a stable
-version. While Rehearsal has no stable release, the workflow also moves `latest` to the
-same reviewed beta. This keeps the npm package page and the ordinary
-`npm install @rehearsal-db/core` command current. When Rehearsal gains a stable release,
-`latest` must switch to the stable line while `beta` continues to identify prereleases.
+The workflow publishes beta and release-candidate versions under the `beta` dist-tag.
+While Rehearsal has no stable release, it also moves `latest` to the same reviewed
+prerelease. This keeps the npm package page and the ordinary
+`npm install @rehearsal-db/core` command current. A stable version publishes under
+`latest` without changing `beta`; after that point, later prereleases update only `beta`
+and cannot replace the stable `latest` line. The GitHub prerelease setting must agree
+with the package version or preparation fails.
+
+The objective promotion checklist and compatibility boundary live in
+[Stability and the first stable release](stability.md).
 
 The trusted publisher allows `npm dist-tag` only so this workflow can maintain those two
-tags without a stored npm token. A manual workflow run from `main` can repair the tags
-for the exact prerelease version currently recorded in `package.json`; it cannot publish
-a package or select a different version. The protected `npm` environment still supplies
+tags without a stored npm token. A manual workflow run from `main` can repair the correct
+channel for the exact version currently recorded in `package.json`; it cannot publish a
+package or select a different version. The protected `npm` environment still supplies
 the human approval gate.
 
 Creating the repository, passing CI, extracting the engine, merging a release branch,

package/docs/stability.md

@@ -0,0 +1,69 @@
+# Stability and the first stable release
+
+Rehearsal leaves beta when the workflow it already promises is dependable. Stable
+`0.1.0` does not require every planned database, desktop interface, or paid feature.
+
+## What becomes a compatibility promise
+
+Starting with `0.1.0`, Rehearsal treats these documented surfaces as public:
+
+- CLI command names, flags, JSON result fields, and exit categories in
+  [CLI commands](commands.md);
+- `rehearsal.config.mjs` schema version 1 and the policy formats documented in
+  [Configuration](configuration.md), [Sanitization](sanitization.md), and
+  [Runtime and identity policies](runtime-policies.md);
+- package entry points and generated declarations listed in
+  [TypeScript](typescript.md);
+- supported Node.js, operating-system, Docker, Supabase, and PostgreSQL boundaries in
+  [COMPATIBILITY.md](https://github.com/Ddupasquier/rehearsal-db/blob/main/COMPATIBILITY.md);
+- non-destructive ownership, confirmation, credential, and hosted-access guarantees in
+  [Security model](security-model.md).
+
+Patch releases may fix defects and improve messages without changing those contracts.
+A future breaking contract change requires a version that clearly communicates it under
+Semantic Versioning. Internal source files, terminal decoration, exact prose, temporary
+file names, and undocumented package paths are not compatibility promises.
+
+## What blocks a release candidate
+
+An issue blocks `0.1.0-rc.1` when it can cause any of the following within a supported
+configuration:
+
+- data loss, credential exposure, hosted-system access, or mutation outside resources
+  that Rehearsal can prove it owns;
+- an incorrect baseline, migration set, verification result, or successful status;
+- failure of clean installation, supported-version upgrade, restore, reset, cleanup, or
+  interruption recovery;
+- a documented CLI, configuration, policy, or TypeScript contract behaving differently
+  from its reference;
+- a supported Node.js, Supabase, PostgreSQL, macOS, or Linux path failing its maintained
+  automated gate.
+
+Cosmetic improvements, new database families, production-shaped sampling, the VS Code
+extension, desktop work, and commercial capabilities do not block the first stable
+release.
+
+## Promotion sequence
+
+1. Ship beta.18 with only stability, release-safety, upgrade, and documentation work.
+2. Freeze broad feature development on the release branch.
+3. Publish `0.1.0-rc.1` from protected `main` through the reviewed npm environment.
+4. Run the complete Rehearsal Test Lab gate twice from clean isolated workspaces.
+5. Perform one final package-only upgrade in a real consumer. The consumer must use the
+   published package rather than duplicate Rehearsal machinery.
+6. Keep the candidate available for at least seven calendar days. Restart the window if
+   a blocking package change is required.
+7. Publish `0.1.0` only when no blocking issue remains and the accepted registry artifact
+   matches the tested artifact exactly.
+
+Test Lab is the primary verification system. A real consumer is the final compatibility
+check, not a replacement for package-owned coverage. Real Google or GitHub consent does
+not need to run on every build unless authentication behavior changes.
+
+## npm channels
+
+Beta and release-candidate versions publish under the `beta` tag. Before a stable
+release exists, `latest` follows that reviewed prerelease so the ordinary install command
+remains useful. Once stable `0.1.0` exists, `latest` stays on the stable line and `beta`
+continues to identify the newest prerelease. Stable publication never rewrites the
+`beta` tag.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rehearsal-db/core",
-  "version": "0.1.0-beta.17",
+  "version": "0.1.0-beta.18",
   "private": false,
   "description": "Safely rehearse PostgreSQL and Supabase migrations against sanitized, production-shaped data.",
   "repository": {
@@ -13,7 +13,6 @@
   "homepage": "https://ddupasquier.github.io/rehearsal-db/",
   "publishConfig": {
     "access": "public",
-    "tag": "beta",
     "provenance": true
   },
   "type": "module",