Schema drift: user_hackathons exists in production but not in main's migrations

[Jose-Gael-Cruz-Lopez]

public.user_hackathons exists in the live Supabase project, but nothing on main records that it does.

How it happened

The migration that creates it, supabase/migrations/20260725154500_user_hackathons.sql, says so in its own header:

applied by hand through the Supabase SQL Editor on 2026-07-26, because this project has no Supabase CLI or MCP apply_migration configured. That path records nothing in supabase_migrations.schema_migrations, so unlike every other file here this timestamp is NOT a recorded version — it will not appear in list_migrations, and supabase db push would try to replay it if a CLI is ever wired up.

The file itself only exists on the unmerged draft branch for #236 (vercel). main's migrations stop at 20260722192614_harden_trigger_fn_and_submitter_reads.sql.

So the drift is in two directions at once:

• Production is ahead of main. The table, its RLS policies and its grants are live. Rebuild a database from main's migrations and you get a schema missing a table production has.
• The migration is not recorded. It is absent from supabase_migrations.schema_migrations, so a future supabase db push would try to replay a create table for a table that already exists.

Why it matters even though the table is empty

user_hackathons holds no user data yet, so nothing is at risk today. The problem is that the repo has stopped being a faithful description of the database. Every other migration here is careful about exactly this — explicit grants, revoke of Supabase's default privileges, comments explaining replay behaviour — and that care is wasted if one table is invisible to the same process.

It also blocks #235. That issue is about moving tracker ownership enforcement into Postgres via RLS; reasoning about which policies are live is harder when the policies in question exist only in production and on a draft branch.

Options

1. Land the migration on main independently of feat: persist the tracker to the user's account, add win trophies, and deploy from main (#226, #223) #236. Cherry-pick just 20260725154500_user_hackathons.sql. It is idempotent — create table if not exists, drop policy if exists before each create policy — so it is safe against the live database. This makes main describe reality without waiting on the feature branch.
2. Record it as already-applied if a Supabase CLI is ever configured, so db push does not replay it. The header flags this; worth resolving at the same time.
3. Decide the convention for hand-applied SQL — either always go through the CLI, or write down that the SQL Editor is the path and how such files get reconciled. Right now this file is the only exception and it is documented only in its own header.

Option 1 is the cheap fix and does not depend on #236's fate.

Found while investigating #235.