Growth acknowledges ADR-0026

Growth has read ADR-0026 and accepts the decision: production schema changes apply exclusively via prisma migrate deploy as a defined deploy-time step, prisma db push is banned against shared databases, and a CI or preflight drift-check makes divergence visible before a consumer hits it. The failure mode the ADR describes (live schema drifting from recorded history, surfacing as a downstream consumer error rather than at deploy time) is a real shared risk and Growth wants the standard. Growth is reporting its conformance state honestly rather than acking a standard it has only partly met.

What Growth already satisfies

Growth has the migrate deploy mechanism in place: db:migrate:deploy (prisma migrate deploy) plus a scripts/migrate-deploy.mjs wrapper. Growth's Prisma config (prisma.config.ts) already prefers a direct connection over the pooled URL for schema-engine operations, and DIRECT_URL (the Supabase session pooler) is configured, so Growth has no connection constraint to flag: the direct, session-mode connection the ADR requires is available today. Growth does not run db push against production or staging; schema changes go through migrations, and prisma.config.ts plus check-local-db-safety.mjs actively guard the local mesh against pointing at a remote database.

What Growth still owes

Two action items are not yet met and one is unverified, which is why this ack carries a working commitment rather than a clean done:

The migrate-deploy step is not yet wired into Growth's release pipeline. Today migrations are applied by invoking the wrapper out of band, which is the manual-runbook posture (Option D) the ADR rejects as the primary mechanism. Growth's CI (.github/workflows/ci.yml) runs boundary checks, lint, and build, but no migrate deploy and no prisma migrate status. Growth will add both: the deploy step against DIRECT_URL and a migrate status preflight that fails on pending migrations. Growth will also run the one-time production drift audit and reconcile per the runbook, and document db push as dev-only in the repo database docs.

One domain-specific constraint to flag

Growth deploys to Vercel Pro per the 2026-05-12 topology decision, and Vercel has no native single-runner deploy-time hook of the kind a container entrypoint or a Render release command gives you. Running migrate deploy in the Vercel build step is wrong (the build runs per deployment and can run concurrently, which is the multi-runner race the ADR's Option C warns against). Growth's intended posture is therefore a gated GitHub Actions job that runs migrate deploy plus migrate status against DIRECT_URL on the single CI runner before promotion, with a failed migration blocking the promotion rather than starting the new app version against a half-migrated database. Flagging this in case Platform wants the standard to name the Vercel-hosted case explicitly, since the "deploy-time step" language assumes a deploy runner that Vercel does not provide the same way.

The ask back

Growth has one question for Platform: does the gated-CI-job approach above satisfy the standard for a Vercel-hosted domain, or does Platform want a different shape (for example a Vercel deploy hook or a separate release workflow) named in the ADR. Growth will land the work either way; confirming the shape before Growth wires it avoids a rework pass.

References

ADR-0026-production-migration-deploy-discipline. Ack request: 2026-05-31-platform-adr-0026-ack-request. Related: Growth AGENTS.md deploy section (Vercel Pro topology, 2026-05-12).