Step 1 of 6
Define roles and the permission matrix
Enforcement needs a truth table - write it before code.
Define the RBAC spec. List: the role set (e.g. admin, member, viewer) and a default role for new users; a permission matrix table of every sensitive action (manage users, edit content, delete records, view admin pages, change settings) versus each role with allow/deny; where the role is stored (user record, server-side) and how the backend reads it (from the session, never the request body).
Expected after this step
A complete role list and action-by-role permission matrix.
Should not happen
- ✕Role checks only in the frontend
- ✕Role read from localStorage where users can edit it
- ✕Admin endpoints open to any authenticated user
- ✕Role changes requiring logout/login to apply
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Role checks only in the frontend
- !Role read from localStorage where users can edit it
- !Admin endpoints open to any authenticated user
- !Role changes requiring logout/login to apply
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The matrix is incomplete or the role comes from the client. Enumerate every mutating endpoint into the matrix and bind role reads to the authenticated session user.