ADR-0049 observed-schema migration rehearsals and release stops

Each producer owner exported only its schema from the authenticated Render configured database using a read-only connection, restored it into a newly allocated loopback database, and applied the actual accepted ADR-0048 then ADR-0049 SQL. All six migration files applied successfully. No customer rows were copied, no existing proof database was reset, and no production migration, deployment, payment replay or activation occurred. This checkpoint extends the release preflight, not the activation gate.

The operator's October 2 coordination scope update permits necessary in-scope production changes without another confirmation solely because an action changes production. Domain ownership, accepted design and readiness evidence remain required. Current target, migration history and compatibility gaps prevent dependent execution; this memo does not clear them.

What the local replays establish

Snapshots omitted owners/privileges and all data. These results prove structural compatibility on the captured producer schema, not Vercel application target equality, populated-data compatibility, grants, production contention or deployed authentication. SQL byte hashes, snapshot hashes, new database names and retained evidence paths are in the companion evidence record. Raw schema dumps and credentials remain outside coordination.

Sales retained an initial synthetic fixture failure because the observed database requires lead_stage.workbench_id while its Prisma declaration permits omission; supplying a synthetic Workbench reference made the fixture valid. That preexisting strictness mismatch remains. Delivery retained an incorrect post-DDL table-count assertion: the previous 49-relation count included coach_csat_aggregate, a view. Independent verification corrected the count without rerunning migrations. Revenue retained a harness-only DMMF schema-metadata assertion failure before database queries; generated schema inspection corrected that harness assumption. None of these failures was erased or represented as a migration success on the initial check.

Concrete release stops

Sales' complete producer migration-history comparison found exactly the two planned migrations pending, no unresolved failed or unknown entries, and a genuine historical checksum mismatch for 20260524173000_relink_qualified_path_prompts. The recorded checksum differs from both newline variants and locally available historical revisions. A second raw mismatch, 20260610230000_lead_stage_history_handoff_evidence, is explained by CRLF. Authenticated Vercel deployment-era file-tree requests returned 404, so they could not identify the successful historical bytes. Do not rewrite the old SQL, change the journal or replay prompt mutations to remove the unresolved mismatch.

After Sales owner reassessment and Platform review of accepted ADR-0026, the missing historical bytes alone are not an indefinite blocker for these unrelated pending migrations. The earlier unconditional stop was a conservative interpretation, not a canonical checksum requirement. The current old SQL changes prompt/cadence data; the new SQL targets task uniqueness and Lead vocabulary, and migrate deploy does not intentionally replay a completed name. Platform accepts an explicit unresolved legacy-provenance finding, preserving the original journal and source. This does not assert what the unknown original bytes did. Exact target, pending-set, new SQL hashes, actual schema/data compatibility and deploy/status failure gates remain mandatory. New evidence linking that drift to pending tables or cadence safety stops the affected release. Neither checksum nor activation readiness is declared resolved.

The checked Sales producer had 317 tasks, zero open closure duplicates and one terminal stage. These aggregate compatibility checks need refresh immediately before any apply. Sales locally committed 895034cc8c3fa7dfaac8e3777912de405865f049, adding only build:payment-handoff-release to run the existing migration preflight, client generation and Next build without the unrelated prompt installer. Ordinary build remains unchanged, package-lock has no delta and parsed command/consistency checks pass. The deployment must explicitly select this command; merely adding it does not select Vercel's build command. It was not run against production. The source still preserves the 132-path primary-workspace difference inventory.

Delivery requires an explicit canonical DELIVERY_ORGANIZATION_ID and actual generated schema agreement. Its observed legacy DELIVERY_DEFAULT_ORG_ID is not a source fallback. Clean local merge fb806e42968b70e0de0adde1d1c666f5b3a14d77 preserves all 38 later ADR-0048 paths and all 39 ADR-0049 paths, excludes unrelated primary dirt, and passed 906 tests plus eight audit tests, typecheck and smoke. It was not pushed. Its fresh 42-row producer journal has exactly the two expected pending files and no unresolved failed history. The historical 20260520170000_lesson_person_id_bridge checksum matches original Git commit e39f009fc651465fc94f46a53e4d6be9e63b17ad; the later file wraps its Revenue-table backfill in an existence guard. That explains genuine source drift, without changing either journal or historical SQL.

Delivery recovered authenticated immutable Vercel build logs for dpl_Cf9U964S6fADECJgvEuiUzAonxZx. They show the deployed override npm run db:ensure-deploy-schema && npm run prisma:migrate:deploy && npm run build && npm run smoke. This corrects the incomplete earlier repository-only prebuild description: a deployment can apply SQL. The logs identify the historical build migration datasource as database postgres, schema delivery, pooler host aws-1-us-east-1.pooler.supabase.com on port 5432, with 42 migrations and none pending. They do not establish username/project reference or runtime DATABASE_URL equality. Review the effective build override before source publication or deployment.

Revenue's fresh history audit found 49 journal rows representing 47 distinct applied migrations and two explicitly rolled-back historical attempts. All completed checksums match source, with three explained checkout CRLF variants; exactly the two intended migrations are pending. Additional local proof verified atomic rollback of both migrations after an injected SQL error, successful combined transactional application on a fresh database, and exact Prisma journal reconciliation/repeated-applied rejection without changing the already-committed schema. Revenue's database guards serialize existing financial writers even with new feature flags off, so target-bound roles and representative throughput remain part of acceptance.

Vercel's API masks the relevant production datasource values. An authenticated Render producer configuration is not proof of the Vercel application or migration connection. The coordinator initially opened the Vercel browser sign-in flow, then confirmed from official documentation that sensitive values also cannot be read back through the dashboard. All three owners found no existing protected read-only runtime target diagnostic in their deployed source. Their authenticated immutable build logs consistently identify each domain's historical migration datasource as postgres on the same pooler hostname at port 5432, with separate schemas. None exposes the project reference or runtime DATABASE_URL equality, and their build configuration prefers DIRECT_URL independently of runtime. Revenue's effective build also runs migrations before build. No variable replacement, guessed target substitution, new diagnostic deployment or security weakening was used to obtain a passing check.

Sales' immutable deployed build logs also warn that new Node20 deployments fail on or after October 1. Final clean local source a01687eb2e3e868d7483408f6bbea40879318583 updates package and lockfile engine metadata plus CI setup-node to Node24.x, preserves all dependency resolutions and scripts, and retains the dedicated release build command. Parsed metadata, exact diff and YAML checks pass. The earlier direct Node24 build and startup proof cover the unchanged application source; the metadata change was not misrepresented as a new deployed build.

Platform deployment coupling

Platform candidate 3b0ef9d020512a91158c74e87f4a50e4e39b9c0a has no Prisma, package manifest, lockfile or worker-entrypoint delta from the observed Render source. Its web delta also includes ADR-0048 closure token selectors and stricter mandatory workload proof claims. Those selectors are not feature-flagged. ADR-0049 assessment needs only the existing revenue.sales-operations capability and revenue.orders.read scope, so review the combined authorization change explicitly before selecting the web candidate.

Authenticated Render Settings now confirms auto-deploy After CI Checks Pass on Platform main, with npm ci and npm run render:worker. A main push can restart fanout, external actions and Growth intake matching. Saved fanout is true, and the new event registry entry has no per-event switch. Deployment must follow signed consumer readiness and a fresh exact backlog/cursor/dead-letter review; an absent cursor starts at zero. No worker configuration changed during inspection. Both other active Platform coordinators received this coupling evidence.

The accompanying Platform release plan records source pins, target and history abort conditions, consumer-before-producer sequencing, verification and forward-stop recovery. Canonical ADR-0026 selects prisma migrate deploy for normal production application. The coordinator returned Revenue's initial manual-SQL-plus-resolve proposal for correction; local recovery evidence does not create an exception to that accepted rule. Retain receipts, history, nullable ownership and financial facts during recovery. A flag-off rollback does not remove Revenue trigger contention or make an older binary compatible with payment-only ownership.

Revenue then verified actual Prisma 7.8.0 migrate deploy on two fresh observed-schema copies with 47 clearly synthetic source-history entries. Success applied both unmodified files with exact engine-written checksums, 47 tables and 63 new guards; status and repeat deployment passed with no new migration. A synthetic conflict in the second migration produced P3018/42P07 while the first migration remained committed. Retrying returned P3009 with unchanged state. This proves the required stop behavior and the absence of atomicity across migration files. The specific failing file's earlier clock creation rolled back in this observed case; it does not prove every transport-loss or journal-crash outcome. All proof databases and failed journal evidence remain local and preserved. The owner withdrew the normal manual-SQL/resolve recommendation.

Ledger boundary

The fresh live ledger at 21:17:10Z still showed Sales activation/reconciliation conditional on uncleared paid-invoice-handoff-ready. The four earlier scoped implementation commitments remain completed. The new schema evidence neither clears that decision nor accepts a production migration. The ADR-0048 coordinator merged the accepted ADR-0050 contract package as b3a3afb8932298e76b7da728988226e0f054b587 and verified its CI/ledger sync; runtime implementation remains a separate handoff. That contract merge is not deployed producer-fence behavior, nor readiness clearance for this release.