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

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,253 @@
+# 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",
+      "matcher": {
+        "type": "verified-email",
+        "providers": ["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" }
+      }
+    }
+  ]
+}
+```
+
+Authentication has three separate parts:
+
+1. The local Supabase configuration enables Google, GitHub, or email sign-in and reads
+   any provider credentials from the environment.
+2. The application completes the ordinary sign-in and receives a normal Supabase
+   session. Rehearsal does not intercept the callback.
+3. The identity policy matches that verified local identity and transfers only the
+   reviewed copied-account graph.
+
+The email stays in an environment variable; only its reviewed hash is committed. Run
+`rehearsal open`, complete the ordinary local 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.
+
+### Supported identity matchers
+
+Rehearsal currently supports the Supabase provider values `email`, `google`, and
+`github`. Other provider names fail closed until their Auth representation has package
+coverage. Two matcher types are supported:
+
+- `verified-email` accepts one or more supported providers. It lowercases the email from
+  the named environment variable and compares its SHA-256 receipt before querying Auth.
+- `provider-subject` accepts one OAuth provider (`google` or `github`). It compares the
+  reviewed SHA-256 to Supabase's stable provider ID/subject without placing the raw
+  subject in the policy, baseline, command output, SQL parameters, or receipt.
+
+Google by verified email:
+
+```json
+"matcher": {
+  "type": "verified-email",
+  "providers": ["google"],
+  "emailEnvironmentVariable": "REHEARSAL_APPROVED_OWNER_EMAIL",
+  "approvedEmailSha256": "<sha256 of the lowercase email>"
+}
+```
+
+Supabase email/password or magic-link sign-in uses the same matcher with
+`"providers": ["email"]`. An account intentionally allowed to use either ordinary
+email or Google can declare `"providers": ["email", "google"]`; the claim still refuses
+zero or multiple matching identities.
+
+GitHub by stable provider subject:
+
+```json
+"matcher": {
+  "type": "provider-subject",
+  "provider": "github",
+  "subjectEnvironmentVariable": "REHEARSAL_APPROVED_OWNER_SUBJECT",
+  "approvedSubjectSha256": "<sha256 of the exact GitHub subject>"
+}
+```
+
+Set the raw value only in the local shell or an ignored environment file. Existing
+policies using the older top-level `provider`, `emailEnvironmentVariable`, and
+`approvedEmailSha256` fields remain accepted as a single-provider verified-email
+matcher. New policies should use the explicit `matcher` object.
+
+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.
+
+After a claim, sign out and sign in again (or otherwise force a full token refresh) before
+judging application roles. This preserves normal RLS, account blocks, role checks, and
+MFA; identity association is not an authentication bypass.
+
+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,140 @@ 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; approved-owner conditionals; exhaustively classified
+JSON objects; and bounded JSON arrays. Unknown tables, columns, nested keys, formats,
+recipes, or missing required fields fail closed. It never evaluates JavaScript or SQL
+from the policy.
+
+## Approved-owner values
+
+Keep the raw approved owner outside the policy and baseline. The policy stores only its
+environment-variable name and SHA-256 receipt:
+
+```json
+{
+  "bindings": {
+    "approved-owner": {
+      "environmentVariable": "REHEARSAL_APPROVED_OWNER_ID",
+      "approvedValueSha256": "<lowercase sha256 of the exact owner value>"
+    }
+  },
+  "tables": [
+    {
+      "name": "profiles",
+      "sourceRows": "STREAM AND SANITIZE",
+      "ownerBinding": { "binding": "approved-owner", "column": "user_id" },
+      "columns": [
+        {
+          "name": "user_id",
+          "action": "PSEUDONYMIZE",
+          "recipe": { "format": "uuid", "namespace": "account-id" },
+          "generated": "NEVER",
+          "identity": "YES",
+          "foreignKey": null
+        },
+        {
+          "name": "display_name",
+          "action": "DERIVE",
+          "recipe": {
+            "kind": "approved-owner",
+            "approved": { "action": "KEEP" },
+            "otherwise": {
+              "action": "REPLACE",
+              "recipe": { "kind": "constant", "value": "Synthetic account" }
+            }
+          },
+          "generated": "NEVER",
+          "identity": "NO",
+          "foreignKey": null
+        }
+      ]
+    }
+  ]
+}
+```
+
+Generate the receipt without putting the owner value in shell history:
+
+```sh
+node -e 'const {createHash}=require("node:crypto"); process.stdout.write(createHash("sha256").update(process.env.REHEARSAL_APPROVED_OWNER_ID).digest("hex")+"\n")'
+```
+
+Every conditional table names its owner column. Missing bindings, hash mismatches,
+missing owner columns, null/unsupported owner values, and conditionals without an owner
+binding are refused. The owner column must be marked `identity: "YES"` and use
+`PSEUDONYMIZE`, preventing a conditional policy from retaining raw account IDs. Other
+owners take the declared `otherwise` path; every other identity-bearing field still
+needs its own pseudonymization declaration. Supply the binding only to the local
+server-side Rehearsal process; do not put it in the policy, baseline, or tracked files.
+
+## Structured JSON
+
+`json-object` fields are required by default. Set `"required": false` on an explicitly
+optional field. Unknown keys remain errors. `json-array` declares one item recipe and a
+required `maximumItems`. Both recipes accept `maximumDepth`, `maximumBytes`, and
+`allowNull`; defaults are 8 levels, 65,536 bytes, and no null container. Bounds are
+checked before producing the transformed structure. Nested objects and arrays repeat
+the same declarations, and every nested identity uses an explicit pseudonym recipe.
+
+```json
+{
+  "action": "DERIVE",
+  "recipe": {
+    "kind": "json-array",
+    "maximumItems": 25,
+    "maximumDepth": 4,
+    "maximumBytes": 8192,
+    "items": {
+      "action": "DERIVE",
+      "recipe": {
+        "kind": "json-object",
+        "fields": {
+          "actor_id": {
+            "action": "PSEUDONYMIZE",
+            "recipe": { "format": "uuid", "namespace": "account-id" }
+          },
+          "note": {
+            "action": "REPLACE",
+            "required": false,
+            "recipe": { "kind": "constant", "value": "Synthetic note" }
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+The package still exports `validateSanitizationCoverage` and
+`applySanitizationAction` for existing version 1 preparation tools:
 
 ```ts
 import {
@@ -35,15 +167,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 +199,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.