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

docs/superpowers/2026-05-29-MASTER-PLAN.md

@@ -534,4 +534,4 @@ Each plan = one phase, produces working/verifiable software on its own, and is e
 - **What:** an attribute-based policy engine (subject/resource/action/context attributes; ordered permit/deny; deny-wins; default-deny) generalizing the role/override data; `can(action, resource, ctx)` API; a permission-aware route guard; the Option-B unified route scheme (one human-readable route per feature, role landings only); nav hiding + styled Access Restricted page; Org Settings as policy/attribute editor.
 - **Why:** ABAC expresses ownership/assignment/territory rules RBAC can't (a rep edits only their projects; a sub sees only theirs) while still covering the simple "deny one admin / one agent read-only" asks — a credible enterprise-access story; folded with the route cleanup it also yields one obvious URL per feature.
 - **How:** a pure engine in `src/data/abac.js` (`evaluate` deny-wins/default-deny + `compilePolicies` folding the matrix + per-person overrides + resource-aware rules); `usePermissions` keeps `can(module,action)` (engine-backed, back-compatible) and adds resource-aware `canAccess(action, resource)`; a module-gated `ProtectedRoute` + Access Restricted page; resource gates on project detail; nav permission-hiding; then (separately, higher-risk) **consolidate `App.jsx`** to unified routes (with redirects from legacy paths) and strip `basePath` from 4 files. The friendly Org-Settings matrix already configures the engine (no new policy editor). **Phased so the ABAC core (low-risk wow) is shippable before the route-URL consolidation, which is deferrable.** Verify: rep blocked from editing a project they're not on; sub sees only theirs; denied direct-URL → Access Restricted; (Phase C) one route per feature, no `basePath` left.
-- **Plan file:** `docs/superpowers/plans/2026-05-29-plan8-abac-routing.md`. **Note:** plan keeps `can(module,action)` + adds `canAccess(action,resource)` (rather than replacing the signature) to avoid breaking existing callers; ABAC engine lives in `src/data/abac.js` (not `utils/permissions.js`).
+- **Plan file:** `docs/superpowers/plans/2026-05-29-plan8-abac-routing.md`. **Note:** plan keeps `can(module,action)` + adds `canAccess(action,resource)` (rather than replacing the signature) to avoid breaking existing callers; ABAC engine lives in `src/data/abac.js` (not `utils/permissions.js`). **Cosmetic/frontend-only** — a client-side demonstration of the access model against the mock store; real enforcement is backend (another team), so no auth/session/server policy plumbing.

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.