fix(db): reload PostgREST schema cache so open_to_work_email is writable

[panbergco]

Saving a contact email on /hire fails with:

Could not find the 'open_to_work_email' column of 'profiles' in the schema cache

Reproduced on production today (profile panbergco, tier Supernova, rank #7) while opting in to open-to-work.

Cause

The column is not missing. 009_open_to_work_email.sql adds it and setOpenToWork in src/lib/data/supabase/client.ts writes it. But PostgREST serves a cached copy of the schema, and no migration in supabase/migrations/ ever asks it to reload — grep -rn "NOTIFY\|pgrst" supabase/migrations/ returns nothing. So the API rejects the write with PGRST204 while the column exists in the table.

Supabase reloads the cache on its own eventually, and the dashboard SQL editor usually triggers it — which is why this does not reproduce in a fresh local setup. A migration applied via the supabase CLI or a direct psql connection does not trigger it.

Fix

Adds 013_reload_schema_cache.sql:

NOTIFY pgrst, 'reload schema';

Kept as its own migration rather than a line appended to 009, because the cache is global: one reload republishes every column from every earlier migration, so any other stale column is fixed at the same time. Safe to re-run and harmless when the cache is already current.

README gains a note to run it last, and again after any future migration that adds a column.

Notes

• SQL only, no app code touched — nothing for tsc --noEmit or pnpm build to react to.
• Related: [codex] Add custom open-to-work contact email #75 (added the feature), /hire MVP: open-to-work opt-in + hiring page + company CTA #68 (/hire MVP).
• Applying this to the production database is what actually unblocks the error; merging alone will not.

[vercel]

@panbergco is attempting to deploy a commit to the sculpt Team on Vercel.

A member of the Team first needs to authorize it.

[nikshepsvn]

Thanks for the report and the fix — merging with two adjustments:

1. Renumbered 013 → 014 (013 was taken by 013_month_stats.sql on main while this was open).
2. Corrected the diagnosis in the migration comment: reproduced your error, and it was Postgres 42703 ("column does not exist"), not PGRST204 — migration 009 had never actually been applied to production. It's applied now, along with the schema reload, and saving a contact email on /hire works again. Your reload migration is still the right guardrail for any future migration applied over psql or the management API, so it stays.

🤖 Generated with Claude Code