@rehearsal-db/core 0.1.0-beta.1 → 0.1.0-beta.10

package/docs/releasing.md

@@ -5,48 +5,27 @@ environment. The workflow builds and hashes the candidate before the environment
 approval gate, then publishes those exact bytes with npm provenance. A local working
 tree is never the release source.
 
-The initial publishable `0.1.0-beta.1` release branch is the first change allowed to set
-`"private": false`. Publication still requires the exact protected-main tag, prerelease
-flag, artifact checks, and protected `npm` environment gate described below.
-
 `0.1.0-beta.0` was prepared under the unavailable `@rehearsal` npm scope and was never
 published. `0.1.0-beta.1` supersedes that candidate under `@rehearsal-db/core` without
 rewriting the earlier Git tag or GitHub prerelease.
 
-## One-time first-package bootstrap
+## Trusted publication boundary
 
-npm trusted publishing and staged publishing are package-level settings, so they cannot
-be configured until `@rehearsal-db/core` exists in the registry. The first public version has
-a deliberately narrower bootstrap path:
+`@rehearsal-db/core` trusts only the GitHub Actions publisher for repository
+`Ddupasquier/rehearsal-db`, workflow `publish.yml`, and environment `npm`. The publish job
+requests a short-lived GitHub OIDC identity after the protected environment approval;
+it does not read an npm token or retain a registry credential. Package publishing access
+requires 2FA and disallows bypass tokens.
 
-1. The npm owner enables 2FA and creates or confirms the public `@rehearsal-db` organization
-   scope. Do not send a password, OTP, recovery code, or access token to another person.
-2. After the reviewed release change reaches protected `main`, the owner creates the
-   exact `v0.1.0-beta.1` GitHub release and marks it as a prerelease. The prepare job runs without npm credentials,
-   packs the tag, and uploads its versioned tarball plus SHA-1 and SHA-256 metadata. The
-   publish job waits at the protected environment and cannot run yet.
-3. The owner downloads or inspects that prepared artifact, confirms its version and
-   checksum, and explicitly authorizes those exact bytes.
-4. Only then, the owner creates a short-lived granular npm token with read/write access
-   limited to the `@rehearsal-db` scope and **Bypass 2FA** enabled. npm requires that bypass
-   for a non-interactive first publish; the environment approval remains the human
-   release gate. Store the token only as the `NPM_TOKEN` secret in the protected GitHub
-   `npm` environment.
-5. The owner approves the waiting `npm` deployment. GitHub Actions publishes the exact
-   uploaded tarball with provenance. The workflow
-   refuses to use the bootstrap secret for any version other than `0.1.0-beta.1`.
-6. Immediately after the registry verification passes, the owner deletes the GitHub
-   environment secret and revokes the temporary npm token.
-7. From the new package's npm settings, configure the trusted GitHub Actions publisher
-   for repository `Ddupasquier/rehearsal-db`, workflow `publish.yml`, and environment
-   `npm`. Allow direct `npm publish` for this workflow because the protected GitHub
-   environment supplies the human gate. A later switch to npm staged publication must
-   change and prove the workflow before narrowing the trusted publisher permission.
-8. Set package publishing access to require 2FA and disallow traditional tokens.
+The initial `0.1.0-beta.1` package creation required a one-time bootstrap credential
+because npm cannot configure a trusted publisher before a package exists. That
+credential is not part of the maintained release architecture: it was deleted from the
+GitHub environment after publication, must remain revoked at npm, and cannot be consumed
+by this workflow.
 
-This bootstrap token is a one-release compromise imposed by npm's package-creation
-boundary. It is never committed, printed, copied into a ticket, or retained for later
-versions.
+Direct `npm publish` is allowed only for this trusted publisher because the protected
+GitHub `npm` environment supplies the human gate. A later switch to npm staged
+publication must change and prove the workflow before narrowing that permission.
 
 ## Every release candidate
 
@@ -58,7 +37,7 @@ versions.
    onboarding. Correct and retest the first confusing, missing, or wrong instruction.
 5. Change `private` to `false` only in the reviewed release change.
 6. Record the exact tarball filename, SHA-1, SHA-256, allowlisted files, unpacked size,
-   executable, and zero-runtime-dependency result.
+   executable, declared runtime dependency inventory, and dependency audit result.
 7. Obtain explicit publication authorization for that exact version and artifact.
 8. Merge the approved release commit through protected `main` and create the exact
    `v<package-version>` tag and GitHub release.
@@ -66,12 +45,23 @@ versions.
    the approved version and checksum.
 10. Verify public visibility, ownership, provenance, registry SHA-1, README rendering,
     exact-version clean installation, CLI execution, signatures, and the unrelated
-    installed Docker fixture.
+    installed Docker fixture. Allow up to six minutes for a first package to propagate
+    through the public registry before classifying a missing packument as a release
+    failure.
 11. Replace consuming projects' temporary Git/archive references only on their own
     protected integration branches and rerun their complete verification.
 
 The workflow publishes prereleases under the `beta` dist-tag and refuses a stable
-version. A stable tag requires a later contract, compatibility, and release decision.
+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 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
+the human approval gate.
 
 Creating the repository, passing CI, extracting the engine, merging a release branch,
 or creating a tag does not authorize npm publication. Publication requires explicit

package/docs/roadmap.md

@@ -0,0 +1,41 @@
+# Next steps
+
+Rehearsal supports guided Supabase and ordinary PostgreSQL migration rehearsals. The
+current development track removes the need for consumer-owned Rehearsal engines while
+keeping application meaning and privacy decisions project-owned.
+
+## Standalone workflow
+
+The implementation sequence is dependency-driven:
+
+1. exact temporary source access and retirement;
+2. bounded coherent extraction and executable privacy rules;
+3. approved Storage assets and declarative restore prerequisites;
+4. verified local identity association;
+5. ordinary application launch and meaningful positive/negative proofs;
+6. onboarding, upgrade safety, and exact packaged-artifact acceptance.
+
+These capabilities stay behind separate review boundaries. Normal runtime commands never
+receive source credentials. Source-side writes, package publication, consumer cleanup,
+and real provider observation each require their own authorization.
+
+Track the full breakdown in
+[standalone roadmap issue #38](https://github.com/Ddupasquier/rehearsal-db/issues/38).
+
+## Acceptance still required
+
+- Install the exact packed candidate in clean Supabase and PostgreSQL consumers.
+- Exercise two unrelated synthetic schemas, bounded large data, interruption, drift,
+  invalid migrations, identities, images, persistence, reset, and cleanup.
+- Run the released package in the real reporting consumer and record positives and
+  negatives.
+- Directly observe any claimed Google account-picker/callback and unfamiliar-developer
+  onboarding behavior; automation cannot invent that evidence.
+- Remove consumer integration code only after its replacement passes and that deletion
+  is separately approved.
+
+## Later database targets
+
+After the PostgreSQL family is stable in real projects, evaluate individual PostgreSQL
+services. MySQL, MongoDB, and unrelated database families require different migration,
+restore, and safety behavior and remain out of scope.

package/docs/runtime-policies.md

@@ -0,0 +1,193 @@
+# Runtime and identity policies
+
+These optional JSON files replace common project-owned Rehearsal adapters. They contain
+declarations only: unknown fields, SQL, JavaScript, and unsupported extensions fail.
+
+## Runtime policy
+
+Point `runtimePolicy` in `rehearsal.config.mjs` to a reviewed file:
+
+```json
+{
+  "policyVersion": 1,
+  "prerequisites": {
+    "schemas": ["extensions"],
+    "extensions": [{ "name": "pgcrypto", "schema": "extensions" }]
+  },
+  "triggers": [
+    {
+      "name": "profile_after_auth_insert",
+      "table": { "schema": "auth", "name": "users" },
+      "timing": "after",
+      "events": ["insert"],
+      "function": { "schema": "public", "name": "handle_new_user" }
+    }
+  ],
+  "localRows": [
+    {
+      "table": { "schema": "public", "name": "runtime_settings" },
+      "keyColumns": ["name"],
+      "values": { "name": "scheduler_enabled", "value": false }
+    },
+    {
+      "table": { "schema": "public", "name": "app_role_assignments" },
+      "keyColumns": ["user_id"],
+      "values": {
+        "user_id": "11111111-1111-4111-8111-111111111111",
+        "role": "owner"
+      },
+      "identityAssociation": {
+        "identity": "approved-owner",
+        "column": "user_id"
+      }
+    }
+  ],
+  "expectations": [
+    {
+      "table": { "schema": "public", "name": "profiles" },
+      "rowLevelSecurity": true,
+      "columns": [{ "name": "id", "generated": false, "identity": false }],
+      "foreignKeys": [],
+      "policies": []
+    }
+  ]
+}
+```
+
+Restore order is fixed: Rehearsal creates named schemas and allowlisted extensions
+before dependent schema objects, adds declared triggers after their tables and functions
+exist, then inserts local-only rows after baseline data. Application schema remains in
+immutable migrations or the verified schema snapshot. Verification checks extensions,
+triggers, local-only rows, columns, generated/identity behavior, foreign keys, named RLS
+policies, RLS state, and unvalidated constraints.
+
+Use `identityAssociation` when a local seed is intentionally transferred by a named
+identity policy. Verification accepts the configured placeholder before association and
+the exact recorded local identity afterward. Rehearsal stores that mapping only in its
+local internal schema; it does not duplicate the old role or weaken the row check.
+
+## Identity policy
+
+The identity policy links one verified local Supabase identity to a copied pseudonymous
+graph without an application callback patch:
+
+```json
+{
+  "identityVersion": 1,
+  "identities": [
+    {
+      "name": "approved-owner",
+      "provider": "google",
+      "emailEnvironmentVariable": "REHEARSAL_APPROVED_OWNER_EMAIL",
+      "approvedEmailSha256": "<sha256 of the lowercase approved email>",
+      "placeholderUserId": "11111111-1111-4111-8111-111111111111",
+      "references": [
+        {
+          "schema": "public",
+          "table": "profiles",
+          "column": "user_id",
+          "required": true
+        },
+        {
+          "schema": "public",
+          "table": "app_role_assignments",
+          "column": "user_id",
+          "required": true
+        },
+        {
+          "schema": "public",
+          "table": "food_compatibility_feedback",
+          "column": "reviewed_by",
+          "required": true,
+          "strategy": "preserve-audit"
+        }
+      ],
+      "jsonReferences": [
+        {
+          "schema": "public",
+          "table": "events",
+          "column": "payload",
+          "path": ["actor_id"]
+        }
+      ],
+      "signupDefaults": [
+        {
+          "table": { "schema": "public", "table": "profiles" },
+          "identityColumn": "user_id",
+          "ignoredColumns": ["created_at", "updated_at"],
+          "values": {
+            "display_name": {
+              "kind": "pattern",
+              "pattern": "^User[0-9]{14}$"
+            },
+            "avatar_path": null
+          }
+        }
+      ],
+      "pathReferences": [
+        {
+          "schema": "public",
+          "table": "profiles",
+          "column": "avatar_path",
+          "valueType": "text"
+        }
+      ],
+      "assets": [
+        {
+          "bucket": "avatars",
+          "prefix": "11111111-1111-4111-8111-111111111111/",
+          "rewritePath": true
+        }
+      ],
+      "claims": { "rehearsal_owner": true },
+      "tokenHook": {
+        "function": {
+          "schema": "public",
+          "name": "custom_access_token_hook"
+        },
+        "expectedClaims": { "app_role": "developer" }
+      }
+    }
+  ]
+}
+```
+
+The email stays in an environment variable; only its reviewed hash is committed. Run
+`rehearsal open`, complete the ordinary local Google sign-in, and stop the app with
+`Ctrl+C`. Then preview and confirm the association:
+
+```bash
+npx rehearsal identity plan --identity=approved-owner
+npx rehearsal identity claim --identity=approved-owner \
+  --confirm-identity=<full-sha256>
+```
+
+Rehearsal requires exactly one verified matching local provider identity. Every
+`required` reference must exist after transfer. Declare application role tables as
+references; `claims` alone is not a replacement for a database-backed token hook.
+
+References use `"strategy": "transfer"` by default. Use `"preserve-audit"` only for
+immutable historical authorship, such as a completed review. Rehearsal leaves that row
+and its synthetic Auth actor unchanged, but still transfers the active profile, roles,
+and other declared data. Undeclared references still stop the claim.
+
+`signupDefaults` resolves a copied-profile collision only when the local row's complete
+non-ignored shape matches. List every remaining column. Use ignored columns only for
+server-managed values such as timestamps. An edited value, extra column, ambiguous row,
+or unrelated local application data rolls back the entire claim.
+
+`rewritePath` copies approved Storage objects through the local Supabase Storage API,
+verifies the destination bytes, updates the declared database paths, and then removes
+the old objects. A database failure removes the new copies and leaves the originals
+usable. Restored objects may begin with either the placeholder owner or no owner;
+another owner is refused. `pathReferences` updates matching text or JSONB pointers. A
+configured `tokenHook` must return the declared claim subset before commit. The browser must then
+refresh its session or sign in again because Rehearsal cannot rewrite an issued JWT.
+Run `rehearsal open` again for that fresh-session check; runtime data is preserved.
+
+The transaction does not import production passwords, sessions, refresh tokens,
+cookies, MFA secrets, or provider credentials. Local MFA and authorization rules remain
+real.
+
+A synthetic test can prove the plumbing and refusal controls. Claim that Google account
+selection or callback behavior works only after directly observing that real flow.

package/docs/sanitization.md

@@ -1,7 +1,7 @@
 # Sanitization policy
 
-Rehearsal deliberately does not decide what your application may copy. The consuming
-project owns an exhaustive, reviewable policy for its export surface.
+Rehearsal never decides what your application may copy. The project owner reviews an
+exhaustive policy; the package validates and executes the supported recipes.
 
 Every exported field should receive one action:
 
@@ -13,8 +13,39 @@ Every exported field should receive one action:
 
 Fail if a new column is unclassified. Do not default unknown fields to `KEEP`.
 
-The package exports `validateSanitizationCoverage` and
-`applySanitizationAction` as generic primitives:
+For runtime restore, each included column must also classify whether it is generated,
+whether it is an identity column, and its foreign-key target or explicit absence. Run
+`rehearsal baseline prepare` to create a shape-only draft from synthetic NDJSON. The
+draft uses `REVIEW REQUIRED` placeholders and cannot be activated until they are
+replaced and the `draft` marker is removed.
+
+Tables default to the `public` schema. Add `"schema": "app_api"` beside `name`
+for another schema. Schema plus table is the identity, so two schemas may safely contain
+tables with the same name.
+
+In an interactive terminal, the guided **Review the script** action works table by table.
+For larger tables, a human can explicitly apply safe defaults (`REPLACE`, `NEVER`
+generated, `NO` identity, and no foreign key), then review only exceptions. Likely
+structural columns such as `id`, `*_id`, and timestamps start selected as exceptions.
+Users can instead review every column individually. Retaining a value is explicitly
+labeled as sensitive, every saved field remains classified, and no preset is silently
+applied. The reviewer validates the completed policy and refuses to overwrite a draft
+changed during the session.
+
+Two policy versions exist:
+
+- Version 1 describes data that a project has already made safe. It remains supported
+  for synthetic/local inputs and existing baselines.
+- Version 2 is required by `baseline refresh`. It adds bounded declarative recipes so
+  Rehearsal can sanitize without project callbacks.
+
+Version 2 supports keyed UUID, email, text, and integer pseudonyms; explicit constant
+replacement; bounded date shifting; and exhaustively classified JSON objects. Unknown
+tables, columns, nested keys, formats, recipes, or missing fields fail closed. It never
+evaluates JavaScript or SQL from the policy.
+
+The package still exports `validateSanitizationCoverage` and
+`applySanitizationAction` for existing version 1 preparation tools:
 
 ```ts
 import {
@@ -35,15 +66,15 @@ const safeValue = applySanitizationAction({
 ```
 
 Coverage validation requires a one-to-one table and column match: missing and unknown
-entries both fail. The package supplies the operation contract; the project supplies
-the schema inventory, keys, replacements, and derivation logic.
+entries both fail. New standalone preparation should use the version 2 engine described
+in [Production source](production-source.md).
 
 ## Stable identity
 
 Use keyed, deterministic pseudonyms when relationships must survive across tables.
-Keep the key outside source control and outside the final baseline. The same source ID
+Keep the key under `.rehearsal`, outside source control and the final baseline. The same source ID
 should map consistently within a generation, while the original value cannot be
-recovered from the artifact.
+recovered from the artifact. The manifest records only the key fingerprint.
 
 ## High-risk fields
 
@@ -67,3 +98,7 @@ Before activation, verify:
 
 Completeness is not correctness. Human review of the policy and export boundary remains
 mandatory before any real source is introduced.
+
+The exact reviewed policy bytes are checksum-bound to the active baseline. Planning,
+candidate inspection, and runtime restore refuse to continue if that file later changes;
+build a new reviewed baseline instead of editing the active policy in place.

package/docs/security-model.md

@@ -5,24 +5,39 @@ misconfiguration fail closed before a state-changing operation.
 
 ## Trust boundaries
 
-The engine trusts the reviewed package code, strict project configuration, a verified
-active baseline, exact migration bytes, and explicitly project-owned proof code. It does
-not trust ambient environment variables, hosted project state, unknown config fields,
-changed migration history, incomplete artifacts, or an unverified runtime.
+The engine trusts reviewed package code, strict declarations, a verified active baseline,
+and exact migration bytes. It does not trust ambient environment variables, hosted
+project state, unknown fields, changed history, incomplete artifacts, or an unverified
+runtime.
 
 ## Independent barriers
 
 - loopback-only application and service URLs;
-- a dedicated unlinked Supabase workdir and project ID;
+- a dedicated unlinked Supabase workdir, or an exactly named and labeled PostgreSQL
+  container and volume;
 - exact non-overlapping local ports;
 - a clean child-process environment that omits hosted credentials;
 - immutable baseline files and checksums;
 - exact migration-prefix and candidate digests;
 - local runtime labels used for bounded stop/removal;
+- PostgreSQL images must already exist locally and are never pulled implicitly;
+- plain PostgreSQL receives a fresh random password per disposable runtime, retained
+  only in owner-readable ignored runtime files;
 - successful receipts written only after verification.
+- separate exact-digest approval for source setup, source retirement, and identity claim;
+- short-lived source readers limited to reviewed views/columns and deny checks;
+- bounded read-only extraction with no raw dump or row-value logging;
+- exhaustive privacy policy version 2 with an owner-only local pseudonym key;
+- application children receive only explicit local mappings and stay in an owned process
+  group.
+- only one state-changing Rehearsal command may own a project at a time; stale locks are
+  recovered after their process exits;
+- a state-changing command fingerprints its installed Rehearsal package and refuses to
+  continue if that installation changes while the command is running.
 
-No single environment variable or config edit should redirect the tool to production.
-Version 1 provides no hosted execution mode.
+No single environment variable or config edit can redirect runtime commands to
+production. Optional source preparation is a separate boundary and never provides a
+hosted execution mode.
 
 ## Identity providers
 
@@ -31,10 +46,20 @@ credential names are read from an ignored owner-only file, and the callback must
 local Auth. The local account may represent a sanitized production identity, but its
 session and writes remain local.
 
+Account association is one local transaction. Rehearsal removes a signup-created row
+only when its complete declared default shape still matches, refuses unrelated local
+application data, verifies required role references and an optional token hook, and can
+copy, byte-check, and retire only declared placeholder-owned Storage paths. Immutable
+audit references may explicitly retain their synthetic historical actor. Rehearsal also
+refuses to rewrite application paths when copied records refer to files that are absent
+from local Storage. Existing browser JWTs still require an ordinary refresh or new
+sign-in.
+
 ## Remaining responsibilities
 
 Rehearsal cannot prove that retained data is lawful, a sanitization rule is ethically
-appropriate, a migration has the intended business meaning, or a project adapter is
-safe. Repository owners must review those decisions and protect artifacts.
+appropriate, a migration has the intended business meaning, or a real provider flow was
+observed. Repository owners must review those decisions and protect artifacts. The
+configuration barriers are not an operating-system firewall.
 
 Report vulnerabilities using the private process in the root security policy.

package/docs/standalone-workflow.md

@@ -0,0 +1,107 @@
+# Standalone workflow contract
+
+Rehearsal's normal commands remain local-only. `run`, `start`, `reset`,
+`migrate`, `verify`, and `cleanup` never receive source credentials and never
+connect to a hosted database.
+
+The optional preparation workflow is a separate security boundary. It has
+three deliberately separate phases:
+
+1. `source plan` reads declarations and produces a redacted, exact plan.
+2. `source apply` requires the plan digest and source-owner credentials from a
+   named environment variable. It creates only the declared, time-limited
+   reader and export surface.
+3. `refresh` uses that reader in a read-only repeatable-read transaction, builds
+   privately, activates only after verification, resets the local runtime, and applies
+   reviewed retention. `baseline refresh` is the lower-level baseline-only form.
+
+`source retire` has its own preview and digest. It removes only the exact
+reader and export objects Rehearsal recorded. It never searches for similarly
+named roles or removes unrelated grants.
+
+## What belongs in declarations
+
+Projects declare application meaning; Rehearsal executes it. Declarations may
+name:
+
+- approved source relations and columns;
+- whether rows are approved public data or belong to one explicitly approved
+  owner;
+- privacy actions and bounded transformation recipes;
+- licensed or consented Storage buckets and prefixes;
+- schema and extension prerequisites;
+- local identities and reference locations;
+- ordinary application commands and observable proof expectations.
+
+Declarations cannot contain JavaScript callbacks, SQL fragments, passwords,
+tokens, production URLs, or automatic consent decisions. Unknown fields,
+tables, columns, recipes, JSON keys, and target identities fail closed.
+
+## Credential separation
+
+Provisioning, extraction, asset, provider, and local-runtime credentials are
+separate. A declaration contains only the name of an environment variable or
+owner-only secret file. Rehearsal never puts credential values in command-line
+arguments, reports, baselines, receipts, or a launched application.
+
+The current workflow creates and verifies its own temporary PostgreSQL reader. An
+externally provisioned reader is not yet accepted because Rehearsal cannot currently
+prove that reader's complete scope and retirement behavior.
+
+## Snapshot and privacy guarantees
+
+Database schema, migration evidence, and selected rows are read in one
+read-only repeatable-read PostgreSQL transaction. Rehearsal rechecks the source
+identity and migration evidence before commit. Rows stream in bounded batches;
+record bodies never appear in progress or error output.
+
+Storage objects do not share the database transaction guarantee. Their inventory records
+size and version metadata; transfer requires that version, verifies the exact byte count,
+and records a SHA-256 in the immutable baseline. Transfer refuses an object that changes,
+exceeds its declared limit, or falls outside an approved bucket and prefix.
+
+Privacy policy version 2 is executable without project sanitizer code. It
+supports exact keep, exclusion, keyed pseudonyms, constants, and a small set of
+documented derivations. Policies classify every selected field and supported
+nested JSON key. A new or unknown field blocks refresh until the policy is
+reviewed again.
+
+The pseudonym key is an owner-only local secret. It is not stored in the
+baseline or source control. Receipts bind the policy bytes, schema shape,
+source scope, migration evidence, and key fingerprint without storing the key
+or source identifiers.
+
+## Restore, identities, and applications
+
+Restore performs only supported declarative prerequisites. Application schema
+changes remain immutable migration files; configuration is never an arbitrary
+privileged-SQL escape hatch.
+
+Local identities never reuse production sessions, refresh tokens, password
+hashes, provider secrets, or MFA material. An approved provider association is
+performed inside the local runtime and must match the reviewed receipt.
+
+Rehearsal launches ordinary project commands with a minimal environment and
+generated local connection files. It verifies every configured dependency
+before launch, owns only the child process group it starts, and does not claim
+to provide an operating-system firewall.
+
+Proofs require explicit positives and negatives. A process starting, a non-5xx
+response, an empty 200, a 401, or a 404 cannot satisfy a declared positive.
+Reports distinguish engine readiness, dependency readiness, proof completion,
+and provider behavior that was directly observed by a person.
+
+## Failure and upgrade behavior
+
+- Failed, interrupted, changed-policy, low-disk, or drifted refreshes leave the
+  prior active baseline and any edited runtime untouched.
+- Setup and upgrades preview exact file changes and never overwrite a reviewed
+  policy, config, baseline, or local edit silently.
+- Reset, discard, and cleanup operate only on purpose-created Rehearsal
+  resources and retain their existing exact-preview protections.
+- Rehearsal does not make legal, consent, licensing, backup, disaster-recovery,
+  universal-database, or OS-firewall guarantees.
+
+The final acceptance gate uses the exact packed or published artifact in clean
+Supabase and PostgreSQL consumers. Consumer integration code is removed only
+after that replacement is proved and the removal is separately approved.