Delivery acknowledges ADR-0026 (production migration deploy discipline)
Why
Platform asked every domain to ack ADR-0026 (run migrate deploy as a pipeline step, ban db push on shared databases, add a CI or preflight drift-check) and to flag any domain-specific connection constraint. Delivery agrees with the decision without reservation, and owes Platform an honest picture of Delivery's current production state rather than a clean ack, because Delivery is mid-remediation on exactly this failure mode.
What
Delivery reached the same conclusion independently, and on the same day, in its internal ADR-0005 (deploy-time schema migration strategy). The trigger was the same class of incident ADR-0026 describes: on 2026-05-31 the customer workbench hit Prisma P2021 and P2022 errors because delivery.waiver_token, delivery.waiver_token_spend, and customer.assigned_coach_profile_id existed in the deployed client but not in the production schema. The root cause is the one ADR-0026 names: production schema reached its shape through a path that does not record migrations, so the live schema and _prisma_migrations history are out of lockstep, and new migrations were not applying.
Where Delivery already complies:
CI runs prisma migrate deploy against the database in both the build-and-test and e2e jobs, so the test database is always migrated through the recorded history. The Prisma config (prisma.config.ts) already prefers DIRECT_URL over the transaction-pooled DATABASE_URL, which is the session or direct connection ADR-0026 requires for migrate deploy. db push is not used against any shared database.
Where Delivery does not yet comply, flagged honestly:
The production deploy path is Vercel, and the production buildCommand does not currently run prisma migrate deploy. On 2026-05-27 it briefly did (commit e873f23) and was reverted minutes later (commit ac7944d) because migrate deploy failed the build against the drifted production ledger. Since then production schema has been kept ahead of the deployed client by an interim idempotent bridge, scripts/ensure-deploy-schema.mjs, which hand-mirrors DDL for the objects the unapplied migrations would have created. That bridge stops the bleeding but is the parallel-DDL surface ADR-0026 and Delivery ADR-0005 both reject as a permanent answer.
Domain-specific connection constraint, as asked: the production reconciliation cannot be done from the local toolchain because the production _prisma_migrations ledger is not visible from it. It requires the production DIRECT_URL (Supabase session pooler on 5432, not the transaction pooler) in hand, to run migrate status, then migrate resolve --applied for the migrations whose objects the bridge already created (20260524213000, 20260525122000, 20260527120000, 20260527183000) plus resolve any failed ledger entry, before the first clean migrate deploy.
Asks
No ask of Platform beyond recording this ack. Delivery is declaring the remediation as a commitment on this memo (reconcile the production ledger, wire migrate deploy into the Vercel build, add the schema-without-migration CI guard, retire the bridge), tracked under internal ADR-0005. Delivery will report completion on this thread once one clean production migrate deploy proves the ledger is reconciled.