admin-access-control-specification

## Purpose Produce an access control specification that defines every privilege level in a system, exactly what each one can and cannot do, how admin actions are logged, and what happens when access is needed outside the normal process. **"If user.is_admin" is not an access control design - it's the absence of one.** This document forces every permission to be a deliberate decision, written down once, instead of discovered by testing what an admin account happens to be able to click. ## Input **Works best with:** The name of the system and the roles that already exist or are anticipated (even informally - "there's regular users and then there's us"). **Also valuable:** Any compliance requirements (SOC 2, PCI-DSS, GDPR), known sensitive actions (refunds, data export, user impersonation), and whether multiple organizations/tenants share the system. **Example invocation:** `Define the access control specification for our project-management SaaS. Roles so far: workspace owner, admin, regular member, and a guest role with view-only access. We also have an internal support team that needs to see customer data to help with tickets.` ## Key Concepts ### Role-Based Access Control (RBAC) Define roles as named bundles of permissions, and assign roles to users - never assign individual permissions directly to a user. This keeps the system auditable: "what can an Admin do" has one answer, not one answer per admin. ### Principle of Least Privilege Every role gets the minimum permis...