# Role Definitions
 
 ## Purpose
 Define each role available in IGNY8, what it can access, and where those permissions are enforced.
 
 ## Code Locations (exact paths)
 - Role field: `backend/igny8_core/auth/models.py` (`User.role`)
 - Permission classes: `backend/igny8_core/auth/permissions.py` (`IsOwnerOrAdmin`, `IsEditorOrAbove`, `IsViewerOrAbove`, `AccountPermission`)
 - Frontend guards: `frontend/src/App.tsx` (`ProtectedRoute`, `ModuleGuard`), `frontend/src/store/authStore.ts` (role persisted in state)
 
 ## Roles and Capabilities (backend-enforced)
 - `developer`: Treated as admin-level for debugging; passes owner/admin checks.
 - `owner`: Full tenant control (users, billing, plans, sites, automation).
 - `admin`: Nearly full control; same as owner for most modules except potential business policy differences (not differentiated in code).
 - `editor`: Can create/update planner/writer/automation configs; cannot perform owner/admin-only billing or team admin actions.
 - `viewer`: Read-only access where `IsViewerOrAbove` is applied; cannot mutate resources.
 - `system_bot`: Reserved for system automation; not typically used via UI; expected to bypass some checks when invoked server-side (still scoped to account).
 
 ## Enforcement Points
 - DRF permissions: Applied per view/action using classes above; combined with account/site/sector scoping from base viewsets.
 - Middleware: `AccountContextMiddleware` must set `request.account` and reject inactive accounts before permissions run.
 - Site scoping: For non-admins, `SiteUserAccess` limits visible sites in `SiteViewSet`.
 
 ## Cross-Module Impact
 - Planner/Writer/Automation: `IsEditorOrAbove` gates writes; viewers read only.
 - Billing: owner/admin (and developer) expected for invoices/payments/plan changes; editors/viewers not permitted to mutate.
 - Integration: editor+ for connect/test/sync; viewer may read status where allowed.
 - System settings: owner/admin for account/system settings; others limited.
 
 ## Tenancy Rules
 - Roles operate within the resolved `request.account`; there is no cross-tenant role scope. API key flows bypass user roles but remain account-scoped.
 
 ## How Developers Should Work With This Module
 - When adding a new endpoint, pick the minimal role needed and reuse existing permission classes.
 - If introducing finer-grained roles, extend `permissions.py` centrally and update `ModuleGuard` to mirror backend expectations.
 - Keep `User.role` values consistent; avoid hardcoding role strings outside permission helpers.