amal66 puts the database under lock and key

Three changes that make amal66's fork harder to misuse and harder to corrupt - work borrowed straight from the upstream project.

securityinfrastructure

amal66 has spent real effort on the layer most forks ignore: the database itself, here running on Supabase, a hosted database service with built-in access controls. The fork now keeps a versioned, replayable history of every schema change instead of one frozen snapshot - so the structure can be rebuilt cleanly rather than guessed at.

Two moves stand out. Every public table now defaults to no access at all unless explicitly granted, so a stray browser-side query can't read data it shouldn't. And user records are now tied to verified identities with enforced relationships, which stops orphaned or malformed rows from piling up. One caveat worth flagging: that identity change is a one-way migration that assumes existing data is already clean, so anyone adopting it needs to check their own data first.

So what Anyone weighing whether a Mike fork can be trusted with client data should look here - this is the unglamorous hardening that separates a demo from something you'd run in production.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

3 commits from amal66/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`c72b8c74`	feat(chapter-03): add Supabase migrations as database history	Amal	2026-05-24	↗ GitHub
commit body Chapter: 03 - Database evolution. Plain-English map: Introduce Supabase CLI configuration and timestamped migrations so database changes can be reviewed, applied, and repeated over time. Why it matters: A single schema file shows what the database looks like today, but not how it got there. Migrations tell future maintainers when and why the shape changed. Principle: Schema changes should be versioned like application code. Existing deployments need an incremental path instead of a one-shot reset. Precedent borrowed: The fork report's Docker/local-development cluster, Supabase practice, and upstream PR #113's database-integrity work. Upstream base: willchen96/mike@d39f580. Original local commit: bc72e34.
`e3efabf0`	fix(chapter-15): default public tables to deny-all RLS	Amal	2026-05-24	↗ GitHub
commit body Chapter: 15 - Database defense in depth. Plain-English map: Enable Row Level Security fallback policies that deny browser/client roles by default on public tables. Why it matters: The backend uses a service role, but mistakes happen. If a future grant or client path exposes a table, the database should still default to no access. Principle: Least privilege by default, with explicit access instead of accidental access. Precedent borrowed: Upstream PR #145. Upstream base: willchen96/mike@d39f580. Original local commit: faa098c.
`5b82eff9`	fix(chapter-30): convert user IDs to UUID foreign keys	Amal	2026-05-24	↗ GitHub
commit body Chapter: 30 - Database identity integrity. Plain-English map: Convert nine `user_id` columns from text to UUID and attach them to Supabase Auth users with foreign keys. Why it matters: Supabase user IDs are UUIDs. Storing them as plain text allows invalid values and orphaned rows that the database cannot protect against. Principle: Let the database enforce identity shape and relationships. Precedent borrowed: Upstream PR #113. Upstream base: willchen96/mike@d39f580. Original local commit: 5c28df3.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-583.md from inside the repo you want the changes in.

⬇ Download capture-thread-583.md