Stabilize Product Builders v0.1 Demo Day workflow

[SaharPak]

Summary

Stabilizes the app into a clean, reliable v0.1 that supports the real Tech Immigrants Demo Day workflow end to end:

submit → admin approve → public project → vote/support → select for Demo Day → public Demo Day page

The repo already had a working weekly "Friday showcase" (immediate publishing + automatic top-3 snapshot). This PR adds the missing review/approve gate and manual Demo Day curation, fixes two RLS privilege-escalation holes, and hardens demo mode, while keeping the existing weekly features.

New end-to-end workflow

1. Builder submits a project. New submissions are pending review and visible only to the builder/admins.
2. Admin reviews the queue and approves or rejects.
3. Approved projects appear publicly on the home feed and project pages.
4. Community votes/supports approved projects (one vote per user per project).
5. Admin creates a Demo Day and selects approved projects for the line-up (with order, "mark presented", recording URL).
6. Everyone sees upcoming and past Demo Days with the selected line-up at /demo-days.

Security fixes

• Blocked self-promotion to admin — previously any authenticated user could update profiles set is_admin = true on their own row. Now enforced by a protect_admin_flag before-update trigger.
• Blocked self-approval — builders could set their own product status = 'live'. Now a protect_product_status trigger restricts status changes to admins (builders may only withdraw → removed).
• Removed noisy auth/session logging — per-request proxy logs and verbose auth-callback logs that printed cookie/session details are gone.

Database changes

• New migration 004_review_workflow_and_demo_curation.sql:
  • Adds pending and rejected to products.status; default is now pending.
  • Adds a self-read RLS policy so builders can read their own non-public projects.
  • Adds protect_admin_flag and protect_product_status triggers (security fixes above).
  • New demo_day_projects table (admin-curated line-up: week_of, product_id, display_order, status) with public-read + admin-manage RLS.
• supabase/seed.sql updated — reproducible, idempotent demo data (admin account, projects incl. a pending one, votes, an upcoming Demo Day with line-up, a completed Demo Day with winners).
• The legacy demo_day_winners auto-snapshot table is unchanged and still works.

Manual Supabase steps required before production

1. Apply migrations 001 → 004 in the Supabase SQL Editor.
2. Optionally run supabase/seed.sql.
3. Optionally create the product-images Storage bucket and enable Google OAuth.
4. Copy .env.example → .env.local and set env vars (NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY, CRON_SECRET).
5. Set ADMIN_EMAILS=you@example.com (auto-promotes trusted emails to admin on sign-in) or run update profiles set is_admin = true ....

Works in demo mode without any config

With no/placeholder Supabase env, the app runs on read-only sample data: home feed, leaderboard, project detail, an upcoming Demo Day with a sample line-up, the pending-project owner view, a "Demo data" banner, and a friendly demo guard on /submit. The proxy skips auth entirely so there are no redirect loops or blank crashes.

Tested

• npm install, npm run lint, npm run build all pass (13 routes).
• Demo-mode smoke test (placeholder env): /, /demo-days, /submit, /leaderboard, /p/p1, /p/p4 (pending banner), /u/alexbuilds return 200 with expected content.
• Confirmed the service role key and cron secret are not present in the client bundle (.next/static).
• See MANUAL_TEST_PLAN.md for 18 manual test groups including RLS/security checks.

Known limitations

• Demo Day line-up order is add-order (no drag-to-reorder yet).
• Voting requires sign-in (no anonymous voting).
• Auto top-3 snapshot and manual curation coexist; the curated line-up is the primary public surface.
• seed.sql inserts an auth.users row directly (relies on pgcrypto, on by default in Supabase); convenience for fresh projects, not tested against every Supabase version.

Next 5 recommended tasks

1. Drag-to-reorder the Demo Day line-up and persist display_order.
2. Notify builders when approved/rejected or selected for a Demo Day.
3. A "My projects" dashboard consolidating a builder's submissions and statuses.
4. Move admin writes to "use server" actions with revalidatePath, add unit tests for status transitions + RLS.
5. Playwright e2e: home, project detail, submit validation, demo-day page, admin access protection.

Notes

• Does not merge to main, does not apply production migrations, does not deploy.
• No secrets or real user data committed (.env.local is gitignored; only safe placeholder emails).