ci: verify skipped migrations target no public schema (register #40)

[tornidomaroc-web]

Closes register #40 — "latent hole in the db-types gate".

The hole

supabase/migration-order.txt skips 002_storage.sql, and the skip is keyed on the filename, not on the file's content. Nothing stopped a public-schema object from being added to a skipped file: it would be silently absent from the generated types while db-types — a required status check — stayed green.

gen-db-types.sh also printed the claim, on every run, with nothing executing it:

Skipped migrations create no objects in the public schema, so they cannot affect the generated types.

That is prose wearing a gate's uniform — the same shape as #23 (a written migration assumed applied) and #39 ("Enforcement WAS prose only and prose already failed once").

The fix

Each skipped file is now statically verified before Postgres starts: every statement must match a form whose target is explicitly qualified to an allowlisted schema (auth, storage). The notice no longer asserts the claim — it states what was verified, and keeps saying what this gate still does not prove.

Allowlist, not a public-token denylist, because a denylist is backwards in both directions:

• it misses the dangerous case — create table foo (id int) resolves to public through search_path and contains no public token at all;
• it fires on a harmless one — 002_storage.sql:1 is insert into storage.buckets (id, name, public), where public is the bucket-visibility column. A token scan would have redded a provably clean tree on its first run.

Honest limit (stated in the script's own register)

A fail-closed static heuristic over SQL text, not a proof of application. It has a documented undecidable case: a $$-quoted body, dynamic SQL, or an unterminated literal/comment is rejected rather than guessed at. The only sound proof is execution, and execution is blocked for exactly the reason the skip exists — the storage schema is absent on bare Postgres. Provisioning a stub of it would let the gate claim a full application backed by a fake schema this repo does not own: a louder false green than the one being closed.

Evidence

Real file passes (002_storage.sql — one insert into storage.buckets, two create policy ... on storage.objects, all storage-qualified):

==> Verifying skipped migration 002_storage.sql (targets no public-schema object)
...
==> Applied 13/14 migrations; skipped 1

Fail-closed path fires, through the real script, before docker run (scratch file, not committed):

==> Verifying skipped migration 999_scratch.sql (targets no public-schema object)

ERROR: supabase/migrations/999_scratch.sql is SKIPPED by supabase/migration-order.txt, but it
       cannot be shown to leave the `public` schema untouched.

  - this statement matches no verified-safe form:
        create table foo (id int)
=== script exit: 1 ===

Also exercised: explicit create table public.foo → red; do $$ ... $$ → red with "apply it or split it"; create table foo inside a -- comment → pass; the same text inside a string literal → pass.

Scope

Register #40 only. No migration, no DB, no live access, no app code. database.types.ts is byte-identical; the same 13/14 migrations apply. Placed beside the manifest/disk cross-check so a bad skipped file reds on a text read in seconds rather than after Postgres startup and a partial application.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
knowflow	Ready	Preview, Comment	Jul 21, 2026 1:25pm