pastilhasandClaude Opus 5
c57fefa75d
role_capabilities (role, capability, level). the subject of a grant is a role and never a user — the owner's call, and it keeps "what can a Member do" a question with an answer, which per-user rows would not. when one person genuinely needs something different, that person needs a role. a missing row means no access. nothing denies; absence denies. an empty table is a freshly installed server where members reach nothing but their own account, which is the right starting state. the capability key is deliberately unconstrained: a CHECK listing the keys would put the registry in two places and turn adding one into a schema change. the api validates against the registry instead. what the database does enforce is shape — a legal role, a legal level, one grant per pair, and no rows for Super Admin, since the owner bypasses this table entirely and an inert row that looks meaningful is worse than no row. uniqueIndex not unique().on() per databases/CLAUDE.md. verified: pushed to a scratch db twice, second push planned only the two known-harmless pk_music_now_playing lines, so the declaration is stable. applied to officer_dev without --force and without a prompt. all six constraint cases behave — bogus role, bogus level, a Super Admin row and a duplicate pair are each rejected; a legal grant and the same capability on another role are accepted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>