Plan-For-RBAC Below is a strict, execution-grade RBAC checklist and a non-ambiguous audit test suite.

PART A — RBAC IMPLEMENTATION CHECKLIST

(Binding for Antigravity)

Instruction: Implement RBAC exactly as specified below. Do not invent alternatives. Do not refactor backend code outside the allowed scope. Any deviation is a defect.

A.1 Scope Lock (Reaffirmed)

Before starting, Antigravity must acknowledge:

• C# backend is read-only except:

  • Firebase JWT decoding
  • Tenant resolution middleware
  • RBAC enforcement hooks (checks only, no refactors)

• No controller/service/repository redesign

• No new authorization model

• Existing SQL role tables are reused

A.2 Source of Truth (Non-Negotiable)

RBAC must use:

• Existing MS SQL role tables (roles, user_roles_link, features, etc.)
• Existing backend role logic
• Backend is the only authority

❌ No role computation in Next.js ❌ No role logic duplication

A.3 Backend Enforcement (Mandatory)

For every protected API endpoint:

• Authorization check occurs inside the API

• Check executes after:

  • JWT validation
  • TenantContext resolution
  • Session validation (if implemented)

• Failure returns:

  • 403 Forbidden (not 401, not 500)

• Business logic is not executed if unauthorized

Rule: If an endpoint works without a role check, RBAC is incomplete.

A.4 Feature-Level Granularity (Parity with Blazor)

RBAC must support:

• Page-level access (e.g. MemberMstDetails)
• Action-level access (e.g. MemberMstReport, MemberMstCreate)
• Same feature codes as Blazor

No consolidation. No simplification.

A.5 Permissions Exposure Endpoint (Read-Only)

Implement exactly one backend endpoint:

GET /api/auth/my-permissions

Requirements:

• Uses backend role logic
• Returns feature → boolean map
• Derived per request
• No write capability
• No role mutation

Example response:

{
  "MemberMstDetails": true,
  "MemberMstReport": false
}

A.6 Frontend Usage Rules (Strict)

Next.js may:

• Hide menu items
• Disable buttons
• Block navigation with “Access Denied” page

Next.js must not:

• Decide authorization
• Bypass backend failures
• Assume permissions without backend response

Frontend checks are UX only.

A.7 Failure Behavior (No-Crash Contract)

• Missing permission → 403
• Unauthorized API call → 403
• UI must show “Access Denied”
• No blank screens
• No unhandled exceptions

A.8 Explicit Anti-Patterns (Forbidden)

Antigravity must not implement:

• Client-side RBAC as authority
• Role checks only in React
• Caching permissions in localStorage
• Hardcoded role names
• Bypassing RBAC for “trusted” routes

A.9 Completion Declaration (Required)

RBAC is considered implemented only if Antigravity can state:

“All protected APIs enforce RBAC internally. Frontend reflects permissions only. No backend authority has been moved to the client.”

PART B — RBAC ACCEPTANCE TESTS

(Binding for Opencode Audit)

Instruction: Verify the following tests strictly. If any test fails → RBAC is NON-COMPLIANT.

B.1 Backend Authority Tests (Critical)

Test B1.1 — API Bypass Attempt

• Call a protected API directly (Postman / curl)
• Use a valid JWT
• User lacks required role

Expected:

• HTTP 403
• No data returned

❌ If data returns → FAIL

Test B1.2 — Frontend Disabled Button Bypass

• Force-enable a disabled UI button via DevTools
• Trigger API call

Expected:

• HTTP 403
• UI shows error

❌ If action succeeds → FAIL

B.2 Frontend Non-Authority Tests

Test B2.1 — Permission Tampering

• Modify permissions in frontend state (DevTools)
• Attempt restricted action

Expected:

• Backend blocks action

❌ If action succeeds → FAIL

Test B2.2 — Permissions Endpoint Trust

• Permissions endpoint returns false
• UI hides feature
• API still blocks even if UI is bypassed

❌ If backend trusts frontend → FAIL

B.3 Role Change Propagation Tests

Test B3.1 — Role Revocation

• User logged in
• Admin removes role in SQL
• User retries action

Expected:

• Access denied immediately (or on next request)

❌ If access persists → FAIL

Test B3.2 — Role Grant

• User granted role
• Permissions endpoint reflects change
• API allows access

❌ If mismatch → FAIL

B.4 Multi-Tenant Isolation Tests

Test B4.1 — Cross-Tenant Role Leak

• Same user ID in two tenants
• Role exists in Tenant A only

Expected:

• Access allowed only in Tenant A

❌ If Tenant B access works → FAIL (critical)

B.5 Error Handling Tests

Test B5.1 — Missing Role Mapping

• User exists
• No role record

Expected:

• 403
• Clean error response
• No crash

❌ If 500 or crash → FAIL

B.6 Regression Guard

Test B6.1 — Blazor Compatibility

• Existing Blazor flows still work
• No RBAC regression in legacy UI

❌ If broken → FAIL

B.7 Final Audit Verdict

Opencode must conclude explicitly:

• Backend enforces RBAC
• Frontend is non-authoritative
• No scope violations
• No security regressions
• RBAC parity with Blazor achieved

If any checkbox is false → RBAC is NOT DONE

PART C — One-Line Authority Statement (Give to Both Tools)

RBAC is valid only if the backend denies access even when the frontend lies.

This single sentence catches 90% of RBAC bugs.