TenantAtlas/specs/066-rbac-ui-enforcement-helper/contracts/guardrails.md

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.