# Contract: RBAC Guardrails for Filament (v2)

**Branch**: `066-rbac-ui-enforcement-helper-v2`  
**Date**: 2026-01-30  
**Spec**: `/Users/ahmeddarrazi/Documents/projects/TenantAtlas-066-rbac-ui-enforcement-helper-v2/specs/066-rbac-ui-enforcement-helper/spec.md`

## Goal

Prevent re-introducing ad-hoc RBAC authorization patterns inside `app/Filament/**` by keeping a CI-failing, allowlist-driven guard.

## Guard contract

- The guard is CI-failing for new violations (no “warnings only” mode).
- Legacy violations are allowed only via an explicit allowlist.
- Every v2 migration batch removes allowlist entries for the migrated files.

## Forbidden patterns (examples)

The exact pattern list is defined in the guard test, but v2 migrations must remove ad-hoc patterns such as:

- `Gate::...` checks inside Filament resources/pages when the enforcement helper is intended.
- `abort_*` calls used as the primary UI enforcement mechanism inside Filament resources/pages.
- Raw policy ability string literals (instead of `Capabilities::*` constants).
- Custom RBAC helper patterns that bypass `UiEnforcement`.

## Allowed patterns

- Capability checks via `UiEnforcement` and `Capabilities::*` registry constants.
- Defense-in-depth server-side authorization inside action handlers (403 for members without capability; 404 for non-members where reachable).
- Filament action UX patterns: `->requiresConfirmation()` for destructive/high-impact actions.