ADR-0049 saved production targets and operational release boundary

Update at 22:02Z: a free encrypted manual application-data backup succeeded and its archive integrity checks passed. The backup-specific release hold below is superseded by the scoped recovery decision at the end of this memo. Other release and activation gates remain.

All four owners verified their current saved Vercel production database configuration through bounded diagnostic builds. This closes the masked-configuration comparison gap in the earlier schema checkpoint. It does not attest credentials, connectivity or the immutable environment of the older running applications. The paid-invoice-handoff-ready decision remains uncleared.

Each diagnostic uploaded exactly three files, parsed its own production environment, logged only allowlisted predicates and exited intentionally with code 73. The install command only printed the Node version. No dependencies, application code, database connection or HTTP handler ran. Every deployment reached ERROR / BUILD_UTILS_SPAWN_73 with automatic domain promotion skipped. Before/after evidence confirms live production deployments, aliases and project build settings remained unchanged. These actions created failed diagnostic deployment records; they were not application releases.

The common physical target is Supabase project pfuctqiobbjglpukteei, host aws-1-us-east-1.pooler.supabase.com, database postgres, role component postgres. DATABASE_URL uses port 6543 and DIRECT_URL uses 5432. Platform, Sales and Revenue have their expected schema selectors. Delivery's first equality check failed; its refinement established that both selectors are absent, not a different named schema. The predicates found no unexpected parameters, duplicates or fragments without exposing credentials.

Delivery's owner inspected deployed e806e1b and candidate fb806e4. Their unchanged CLI helper adds schema=delivery when absent, and generated model annotations explicitly qualify delivery. The alternate schema override is absent. The candidate handoff boundary independently checks the actual generated inline schema and rejects wrong or duplicate selectors. A session current_schema result alone is not ORM mapping proof; unqualified raw SQL remains a separate inspection.

Narrow configuration correction

Delivery's explicit DELIVERY_ORGANIZATION_ID was absent. Platform's canonical organization constant and published policy reach independently establish org_01900000-0000-7000-8000-000000000001; this was not inferred from tenant or customer data. After verifying the candidate accepts its org-prefixed UUIDv7 syntax, the Delivery owner added only that sensitive production setting to the existing project. The successful authenticated add command and before/after metadata show one new key, no changed existing keys, handoff flag still absent, and unchanged live deployment and aliases. Sensitive value readback was not claimed. The existing running application has not been redeployed to consume it. Legacy DELIVERY_DEFAULT_ORG_ID was not used as a fallback.

Source and sequencing review

The ADR-0048 coordinator reviewed accepted ADR-0050 and concurs that its new epoch, privilege and drain requirements precede new lineage admission. They do not retroactively block the separately reviewed pre-lineage ADR-0049 rollout. Revenue concurs for runtime915ee65/docs3359395 and Delivery for fb806e4, with their two reviewed ADR-0048/0049 migration files. No ADR-0050 migration, writer or admission may be mixed into these pins. Existing atomic financial guards, writer compatibility, availability, combined Lead-lock exclusion and ADR-0049 evidence remain required. The postgres role is an explicit ADR-0050 cutover blocker, not an invented dependency on that future cutover for this release.

Platform's source review concurs for fixed3b0ef9d against deployed239bf724. The three closure selectors are explicit additions and do not widen existing default policies; producer endpoints remain independently disabled. Salesa01687e and Deliveryfb806e4 pass their Vercel workload proof intact. Required timestamp claims are documented by Vercel, but actual fresh deployed workload exchanges must still be verified. The postdeployment plan checks exact fixed authority, existing read paths, malformed-proof rejection and no business writes. It does not exercise provider or closure mutations as an auth test.

Operational evidence still required

Sales authenticated its existing authorized local direct credential to the same physical session target. Read-only role checks found the required schema/table ownership and privileges. Its fresh journal still has exactly the two reviewed pending files and no unresolved failed or unknown entry. There are 325 tasks, zero open closure duplicates, one terminal stage and no new handoff vocabulary. The local credential's success does not authenticate Vercel's saved secret.

Sales also found that requested startup timeout settings were not honored by that connection: observed statement timeout was two minutes and lock timeout zero. Explicit SET LOCAL succeeded in the inspection transaction, but cannot govern another Prisma connection. Actual Prisma timeout enforcement must be demonstrated before migration. Any pending-file wrapper proposal needs explicit source/hash review and local rehearsal; no historical migration or journal may change to conceal this finding.

Platform collected a short read-only aggregate baseline from its existing authorized producer connection. It includes ordinary activity and ADR-0051's exact identity repair at21:43:34.665Z; it is not a pure ADR-0049 workload sample. Database-wide counters cannot establish route p95/p99 or financial writer throughput. Authenticated Revenue and Delivery Vercel metrics requests returned payment_required because Observability Plus is disabled. That response is not zero requests and no paid add-on was enabled.

Next checks are actual saved-credential read-only connectivity, target-bound roles/journal and compatible data, verified recovery availability, enforced migration limits and concrete writer/drain acceptance. Owners are preparing bounded connection checks using the same intentionally failing deployment boundary. No production schema apply, application release, Render restart, payment replay or handoff activation occurred in this checkpoint. The release plan retains consumer-before-producer order and forward-stop recovery. Probe hashes, live deployment IDs and local evidence paths are in the companion record.

Recovery and connection follow-up

The authenticated Supabase dashboard now identifies sguild-domains on the Free Plan, with no scheduled project backups and no point-in-time recovery add-on. It also reports an organization quota restriction. Recent authenticated SQL reads succeeded, so the dashboard banner must not be reported as proof of a complete database outage. No paid plan or add-on was selected. The coordinator asked the operator to identify an existing backup or resolve managed backup/billing availability and explicitly held production DDL and application release. An encrypted logical backup with verified isolated restore is a possible alternative requiring a concrete reviewed recovery plan; the earlier schema-only exports are not data backups.

Sales subsequently authenticated both saved production credentials in diagnostic dpl_6Pde7nS7w5YzvgKqkyKudnZSziLz. The four-file probe used pinned pg8.20.0 and npm ci with lifecycle scripts disabled, separate READ ONLY transactions, verified five-second statement/two-second lock limits, and allowlisted identity/privilege predicates. Both passed, the build intentionally exited73, and production plus all three aliases stayed unchanged. This proves those saved credentials connected at that time, not an older running application's environment or DDL success. Its actual Prisma engine test independently confirmed ignored URL startup timeouts. Pending-only transaction wrappers and local migration-engine rehearsal are now authorized source preparation; any resulting candidate/hash change must be reviewed before apply. Revenue and Delivery are performing their corresponding bounded checks. These checks do not clear the recovery or activation gate.

Free manual recovery path accepted

The operator asked for a free recovery path and instructed the coordinator to proceed without one if none was available. Supabase documents manual exports for Free Plan projects. Platform used the already installed PostgreSQL17.9 tools and its independently authenticated, exact-target DIRECT_URL session connection. No subscription, paid backup service or quota override was enabled.

One consistent pg_dump snapshot completed at21:59:39.686Z. It includes definitions, owners/ACLs, data, sequences and migration journals for coaching, delivery, finance, growth, platform, portfolio, public, revenue and sales. The custom archive was encrypted as a stream with AES-256-GCM; the random encryption key was wrapped with Windows CurrentUser DPAPI. No plaintext archive or customer rows were written to tool output. The resulting encrypted file is23,846,938bytes with SHA256 b9379998264b4a3ad347f92215c4b7a97ffff9ef078c8b57baa8c30b93b01c1f.

Validation recovered the stored key, verified the encrypted checksum, authenticated the entire decryption and ran complete pg_restore SQL generation into Windows NUL. Both pg_dump and pg_restore exited0. A second verification from the retained backup directory also passed. No restore SQL was executed, no shared development database received customer data, and no production data changed. This is archive integrity and key recovery evidence, not a tested database restore.

The archive, protected key, encryption metadata, catalog manifest, verification helper and recovery instructions are retained under Platform's locally Git-ignored .local-backups/adr0049-backup-2026-10-02T21-59-07-575Z. They are not published to coordination. Recovery requires this Windows profile and DPAPI keys. The snapshot excludes Supabase-managed auth/storage/vault schemas, stored object files, provider settings, role passwords, publications and subscriptions; it is neither a complete project clone, off-site disaster recovery nor PITR.

Platform accepts this limited manual application-data recovery path for ADR-0049 and removes the requirement for a paid managed-backup upgrade. The earlier absolute hold pending billing or a full isolated restore was the coordinator's conservative release-plan interpretation, not an immutable ADR requirement. The operator's direction rejects using that interpretation to indefinitely block progress. Preserve the artifact and its limitations; take a fresh snapshot immediately before the eventual migration window if needed. Application-target, pending-file, writer-availability, bounded-DDL, deployed authentication and activation checks remain in force. No production migration or application release is authorized merely by this recovery decision.

Sales preparation also advanced to reviewed clean commit b2c439eac6da75d2f2fac857274b0a16daa9b825, parenta01687e. Its only changes are BEGIN, SET LOCAL lock_timeout5s, SET LOCAL statement_timeout60s and COMMIT around the unchanged bodies of the two still-pending migrations. Historical SQL/journals are untouched. Fresh local actual-Prisma deploy/status and timeout assertions passed. New pending hashes are966953edc30a7f980d3f429ab4706a85f01a5d985f8db5030ca3be36293186c1 and898be869276f463ef819849e18b7ab0a03a3ca0d166b74f635e9a7bc1175c452. These supersede the previous pending hashes for this candidate; they must never be retrofitted into an applied journal.