fix(seed): make seed.sql drill insert idempotent against migrations

[Spedge]

supabase/seed.sql's drill corpus insert (125 rows) duplicates what migrations 0034/0035 already insert into public.drills — 0035's own header explains why (it backfilled drills that used to live only in seed.sql). seed.sql was never trimmed after, so a fresh local supabase start/db reset applies migrations then fails re-inserting the same rows via seed.sql, hitting drills_name_unique. Add the same on conflict (name) do nothing guard 0035 already uses.

What this PR does

Type of change

• Bug fix
• New feature
• Design/UI change
• Refactor
• Docs

Testing

• Reproduced the failure on a fresh supabase start.
• Confirm supabase start (or supabase db reset) completes cleanly with this

Notes for reviewer

Just getting this dev branch started locally and this was a blocker. Seemed to be fine once I'd fixed that overlap.

[vercel]

@Spedge is attempting to deploy a commit to the cner-smith's projects Team on Vercel.

A member of the Team first needs to authorize it.

[cner-smith]

Review — fix(seed): make seed.sql drill insert idempotent against migrations

Concerns

• No GitHub Actions check runs are attached to this PR (get_check_runs returns total_count: 0) — the only status is Vercel's preview-deploy authorization gate, not the pnpm typecheck / pnpm test / build CI described in CONTRIBUTING.md. That's most likely first-time-contributor workflow approval being withheld rather than anything in the diff, but per CONTRIBUTING.md ("CI runs the same four commands. A PR with a red CI gate will not be reviewed until it's green") this should get a maintainer's workflow-approval before merge, not just this comment.

The fix itself is correct: on conflict (name) do nothing matches the guard migration 0035 already uses for the same backfill, and ON CONFLICT DO NOTHING is safe against duplicate names within the same multi-row INSERT (unlike DO UPDATE, which would error on a repeat key in one command). Scope is a single clause on one existing statement — nothing beyond what the stated bug needs.

---

Looked good: minimal single-purpose fix, comment explains the why (migrations 0034/0035 already own this corpus) rather than restating the diff, reuses the exact conflict-handling pattern already established in migration 0035 instead of inventing a new one.

---

Generated by Claude Code

[cner-smith]

(Attribution for the review above.)

---

Generated by Claude Code

[cner-smith]

Nice catch, and thanks for tracking down the actual cause. This bites anyone doing a fresh supabase start: 0034/0035 already backfill the whole drill corpus, so the seed then trips over drills_name_unique. on conflict (name) do nothing is exactly the guard 0035 uses internally, so this keeps the two consistent — and it's the single multi-row drills insert, so the one guard covers all of them. Merging. 🙌