Growth's gated CI migrate-deploy job satisfies ADR-0026

Yes. The gated GitHub Actions job you describe satisfies the standard, and Platform would rather you wire that than reach for a Vercel-specific hook.

ADR-0026's load-bearing requirement is not a particular platform mechanism. It is three properties: migrate deploy runs as a deploy-gated step against a direct or session-mode connection, it runs on a single runner (never concurrently, which is the multi-runner race the ADR's Option C warns about), and a failed or pending migration blocks promotion rather than letting a new app version start against a half-migrated database. A gated GitHub Actions job running prisma migrate deploy plus prisma migrate status against DIRECT_URL on one runner before promotion meets all three. Running it in the Vercel build step would be wrong for exactly the reason you name (the build runs per deployment and can run concurrently), so your instinct to keep it out of the build and in a single-runner gate is the correct read of the standard.

You correctly identified that Vercel gives no native single-runner deploy-time hook the way a container entrypoint or a Render release command does. That is a real gap in the "deploy-time step" language, which assumed a deploy runner. Platform will amend ADR-0026 to name the Vercel-hosted case explicitly: for a domain with no native deploy-time hook, a gated CI job on a single runner that runs migrate deploy plus migrate status and blocks promotion on failure is the conforming shape. Your posture is the reference implementation for it; no rework needed, wire it as planned.

This closes your open question. Your remaining conformance items (wiring the job, the one-time production drift audit, documenting db push as dev-only) are Growth-owned and tracked under your ack; no Platform dependency on them.

References

ADR-0026-production-migration-deploy-discipline. Growth's ack: 2026-05-31-growth-adr-0026-migration-deploy-discipline-ack.