Deleting a member returned 500. The cause is mine and hours old:
attachments.uploaded_by is NOT NULL and does not cascade, so once
somebody has posted a photo SQLite refuses to delete their row.
erase_member knew about threads, comments and created_by — every table
that existed when it was written — and Phase B added a fourth without
telling it.
Reproduced before fixing: a member with a thread erases cleanly, the
same member with an attachment raises FOREIGN KEY constraint failed.
The picture is reassigned to the tombstone rather than deleted, the same
rule the words around it already follow: the thread survives as "Miembro
eliminado" and keeps its shape. Removing the picture means deleting the
post it hangs off.
The lists of columns to reassign and to clear are now module constants
that erase_member iterates, and a test reads the live schema with PRAGMA
foreign_key_list and fails if any table points at members(id), does not
cascade, and is not in them. Checked against the pre-fix lists: it names
attachments.uploaded_by. The next table to be added will fail a test
instead of a button — and this one failed at the moment somebody
exercised a right they are entitled to, which is the worst time to
find out.
201 tests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
c9c549ed22