pastilhasandClaude Opus 5
4ccdb8a1fa
Two guards on user 1, the bootstrap account, so ownership survives whatever happens to the rows. ck_users_owner_is_super_admin — CHECK ((id <> 1) OR (role = 'Super Admin')). In the database rather than in application code because the point is that it holds against a stray UPDATE, a migration script or someone at a psql prompt, not just against the API. A row-level CHECK can say "if this row is user 1 then its role is Super Admin"; it cannot say "some row must be Super Admin", which would need to see other rows. So it pins the bootstrap account and nothing else — promoting and demoting everyone else stays free. deleteUser() refuses id 1, because a CHECK cannot stop a DELETE and removing the owner reaches the same end by another route: nobody who can open the vault, no identity for the agent sidecar to run as, a web origin restricted to a Super Admin that no longer exists, and the passkeys cascaded away so there is no signing back in. It throws rather than returning false — its eventual caller is a manage-users flow, where a silent false reads as "already gone". OWNER_USER_ID is exported from the schema and used by both, so the number appears once. Tested on a scratch database, and the first harness was wrong — a shell variable holding a command did not expand, every statement failed with "command not found", and the check reported them all as allowed. Re-run directly: insert user 1 as Super Admin allowed demote user 1 -> Member REJECTED by CHECK demote user 1 -> Admin REJECTED by CHECK insert user 1 as Member REJECTED by CHECK demote/promote users 2 and 3 allowed deleteUser(1) refused with the message above deleteUser(3) deleted Pushing twice showed the CHECK adds no diff churn — still only the two known pk_music_now_playing statements. Every row in officer_dev already satisfies it, so it will apply without touching data. NOT covered: nothing stops a second account also being Super Admin. The rule asked for was "user 1 is always Super Admin", not "only user 1 is", and the two are different constraints. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>