docs(plan8): frame ABAC layer as cosmetic frontend-only (real enforcement is backend, another team)

docs/superpowers/plans/2026-05-29-plan8-abac-routing.md

@@ -24,6 +24,13 @@
 - **Org Settings (`OrgSettings.jsx`):** `AccessControlMatrix` (iterates `PERMISSION_MODULES` × `orgRoles`, toggles via `updateOrgPermissions`) + `AccessControlPersonModal` (per-user overrides). **It already drives the data the engine will consume — so adding modules flows into it automatically.**
 - **Resource attributes:** project `ownerId`, `subcontractorIds[]`, `teamMembers[].userId`, `contractorId` (NO top-level `salesRepId` — rep is a teamMember with jobRole 'Sales Rep'); kanban lead `assignedAgentId`; sub task `subcontractorId`; **primary `leads` use `assignedTo` (name string) — needs `assignedAgentId` for ABAC.** `filterProjectsForUser` util already exists.
 
+## Cosmetic / frontend-only (read first)
+
+This entire layer is a **client-side demonstration of the access model**, not a security boundary. The app is frontend-only (mock React-context store, no server — `/api/*` is stubbed). The **real policy enforcement is backend, owned by another team**; Plan 8 only makes the access story *demoable* in the UI:
+- The engine, `canAccess`, route guard, nav-hiding, and the Org Settings matrix all run **in the browser against the mock store**.
+- **No** backend calls, auth tokens, server policy checks, session validation, or "real" enforcement. Frontend gates are presentational (and bypassable) — that is acceptable and intended for the demo.
+- Keep it **proportionate**: convincing, coherent UI behavior (nav hides, edits go read-only, Access Restricted shows, matrix toggles flip the UI live) over hardened security plumbing. Don't build auth/session/server infrastructure.
+
 ## Scope & risk note (read first)
 
 - **Phases A–B (ABAC engine + guard + Access Restricted + nav hiding + resource rules)** are **additive and low-risk** — the demo "wow" (realistic enterprise access). They can ship and be reviewed independently.