@rehearsal-db/core 1.2.0 → 1.3.0

package/docs/configuration.md

@@ -386,7 +386,8 @@ inspection remain explicit command choices. See [CLI commands](commands.md).
 
 ### Resource review policies
 
-`resources` applies to the configured project topology, not the shared Docker engine:
+Resource review limits apply to the configured project topology, not the shared Docker
+engine. The optional workload queue instead coordinates participating local projects:
 
 ```ts
 resources: {
@@ -394,6 +395,7 @@ resources: {
   retainedEnvironmentCount: 2,
   maximumBytes: null,
   cleanupSchedule: "daily-preview",
+  workloadQueue: { enabled: true, waitTimeoutSeconds: 30 },
 },
 ```
 
@@ -410,6 +412,36 @@ resources: {
   shown on the next resource inspection. There is no daemon, operating-system scheduler,
   or automatic deletion. An approved cleanup records an owner-only, project/policy-bound
   review time; ordinary read-only inspection writes nothing.
+- `workloadQueue` is optional and off when omitted. With `enabled: true`, participating
+  Rehearsal clients serialize their `start`, `reset`, `run` and `migrate` runtime phases
+  across projects for the same local OS user, boot and process namespace. Waiting is
+  bounded to `waitTimeoutSeconds` (integer 0–300; default 30); zero refuses immediately
+  when busy. Ctrl+C cancels the waiting request without interrupting its holder.
+  Stop, discard, inspection and cleanup remain available. `open` releases admission
+  after startup, before its interactive session; application proofs run outside this
+  first lifecycle-only queue. This does **not** measure available RAM, stop existing
+  runtimes, limit other tools, or promise an entire Docker/VM memory budget. All projects
+  that should cooperate must opt in. Older clients and different OS users/namespaces do
+  not participate. Local filesystems with coherent atomic file operations are required;
+  this is not a network-filesystem or distributed scheduler.
+  Configure it in the source configuration for now; the existing editor field-metadata
+  contract is unchanged so older supported Starter clients keep working.
+
+Run `rehearsal workloads` (or `--json`) without Docker to inspect this queue. Waiting
+requests whose processes have died can be removed automatically because guarded work
+never began. A dead **holder** remains blocking: its child may still be running.
+After checking its owned commands and descendants, use the exact digest shown by
+inspection with `rehearsal workloads recover --confirm-workloads=<digest>`. Recovery
+removes only those reviewed dead-holder metadata records. It never kills a process,
+stops a container, removes data or treats age alone as permission to steal admission.
+Live owners cannot be recovered, even after a wait expires. Malformed or inaccessible
+state refuses admission; it is not silently deleted.
+
+Queue state is private to the local OS user under `~/Library/Application Support/Rehearsal`
+on macOS or `~/.local/state/rehearsal` on Linux/WSL, independent of `TMPDIR`. Advanced
+launchers can set `REHEARSAL_USER_STATE_DIRECTORY` to one absolute local directory;
+every cooperating client must use the same value. Do not delete or move active queue
+state. Boot/namespace-separated records are retained, not automatically pruned.
 
 Temporary files and application processes created by an operation are cleaned up by
 that operation's existing ownership boundary. These policies do not turn a persistent

package/docs/getting-started.md

@@ -15,7 +15,7 @@ They are readable helpers, not native executables or bundled Node/Docker install
 Existing Node.js 22, 24 or 26 is required. The default only checks an existing project;
 installation needs an explicit option and does not start a database. Review the
 [shared behavior and release availability](https://github.com/Ddupasquier/rehearsal-db/blob/main/installers/README.md)
-before choosing an install option. An exact core 1.1.0 install requires that version to
+before choosing an install option. The helper's exact target requires that version to
 be published; a checked-in helper is not proof of publication.
 
 ### Windows: use a WSL 2 Linux workspace

package/docs/releasing.md

@@ -133,6 +133,10 @@ release-source migration.
 
 1. Start from protected `main` on a dedicated ticketed release branch.
 2. Verify the exact version, changelog, compatibility notes, and packed file list.
+   Reconcile the core, VS Code extension and Test Lab READMEs and affected guides with
+   their actual published versions and contracts. Keep candidate availability explicit,
+   link to the owning installation/update guide instead of duplicating version lists,
+   and retain dated historical evidence without presenting it as current acceptance.
 3. Run `npm run release:verify`. It performs the package checks and every
    installed-consumer scenario against one tarball, then records the exact package
    version, SHA-256, environment, commands, timings, and results in

package/docs/roadmap.md

@@ -1,11 +1,13 @@
 # Next steps
 
-Rehearsal core **1.1.0 is available on
-[npm](https://www.npmjs.com/package/@rehearsal-db/core)** for guided Supabase and
-ordinary PostgreSQL migration rehearsals. The [free VS Code Starter 0.1.23 preview](vscode.md)
-adds a visual workbench and is distributed through Marketplace and reviewed GitHub
-VSIX releases. Neither requires a purchase or account. Core is MIT-licensed; all
-features included in Starter are free indefinitely for personal or commercial development.
+Rehearsal core is available on
+[npm](https://www.npmjs.com/package/@rehearsal-db/core) for guided Supabase and
+ordinary PostgreSQL migration rehearsals. The [free VS Code Starter preview](vscode.md)
+adds a visual workbench through Marketplace and reviewed GitHub VSIX releases.
+[Releases and updates](updating.md) explains how to find and install the published
+versions; a roadmap or source version is not a publication claim. Neither requires
+a purchase or account. Core is MIT-licensed; all features included in Starter are
+free indefinitely for personal or commercial development.
 
 Stable core, the editor preview and a future paid Pro offer have separate completion
 boundaries. A downloadable preview does not imply that every native accessibility,

package/docs/stability.md

@@ -1,13 +1,13 @@
 # Stability and release verification
 
-Rehearsal core **1.1.0 is published** on
-[npm](https://www.npmjs.com/package/@rehearsal-db/core). This page defines its
+Stable Rehearsal core releases are available on
+[npm](https://www.npmjs.com/package/@rehearsal-db/core). This page defines the
 compatibility promise and the verification policy for releases; it is not an
 unfinished launch checklist. Stable core does not require every planned database,
 editor interface, or paid feature.
 
 The compatibility promise began with **1.0.0**. The separate
-[VS Code Starter 0.1.23 preview](vscode.md) has its own editor acceptance and does
+[VS Code Starter preview](vscode.md) has its own editor acceptance and does
 not turn a core release into a completed accessibility or provider walkthrough.
 
 ## What becomes a compatibility promise
@@ -98,7 +98,7 @@ baseline. Automatic compatible updates do not cross the 0.x-to-1.x version bound
 review the changelog and deliberately select the stable version:
 
 ```bash
-npm install --save-dev --save-exact @rehearsal-db/core@1.1.0
+npm install --save-dev --save-exact @rehearsal-db/core@1.3.0
 npx --no-install rehearsal --version
 npx --no-install rehearsal doctor
 ```

package/docs/updating.md

@@ -38,11 +38,11 @@ instead of installing both extension identities together.
 
 Finish active Rehearsal commands first. Read the [release notes](https://github.com/Ddupasquier/rehearsal-db/releases),
 then use your project's existing package manager and dependency location. For an npm
-project that keeps Rehearsal in development dependencies, update to the reviewed 1.2.0
+project that keeps Rehearsal in development dependencies, update to the reviewed 1.3.0
 release only after it appears in the official registry:
 
 ```bash
-npm install --save-dev --save-exact @rehearsal-db/core@1.2.0
+npm install --save-dev --save-exact @rehearsal-db/core@1.3.0
 npx --no-install rehearsal --version
 ```
 

package/docs/vscode.md

@@ -70,7 +70,7 @@ real WSL core fixtures do not certify a native Remote-WSL editor walkthrough.
    setup, source access, migration execution and cleanup keep their own confirmations.
 
 Core and the extension have independent version numbers. This guide targets core
-**1.2.0** and Starter **0.1.24**, only once each is published. See [Updates](updating.md)
+**1.3.0** and Starter **0.1.24**, only once each is published. See [Updates](updating.md)
 when moving an existing installation forward.
 The extension's minimum core is `0.1.0-rc.4`. A project that is not ready should show
 setup guidance, not require you to build the extension. Opening the dashboard does not

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rehearsal-db/core",
-  "version": "1.2.0",
+  "version": "1.3.0",
   "private": false,
   "description": "Catch PostgreSQL and Supabase migrations that pass on empty databases but fail on real data—before deploy.",
   "repository": {
@@ -26,6 +26,7 @@
     "projectDiscovery": 1,
     "resourceInventory": 1,
     "resourceManager": 1,
+    "workloadQueue": 1,
     "migrationReview": 1,
     "migrationInsights": 1,
     "migrationImpact": 1,