@terreno/mcp 0.30.0 → 0.31.0

package/dist/docs/versioned/0.30.0/implementationPlans/rbac-permissions.md

@@ -0,0 +1,982 @@
+# RBAC Permissions for Terreno — API Design
+
+**Status:** Draft — API design for discussion (full IP to follow)
+**Target package:** `@terreno/api` (new `src/rbac/` module), with surfaces in `admin-backend`, `admin-frontend`, `admin-spa`, `rtk`, and the modelRouter MCP work
+**Depends on:** `better-auth/plugins/access` (already a dependency via the Better Auth provider)
+
+---
+
+## 1. Summary
+
+Terreno currently has a binary privilege model: `User.admin: boolean`, plus per-route
+`PermissionMethod<T>[]` arrays (`Permissions.IsAdmin`, `IsOwner`, …) with AND semantics. This
+plan replaces that with a first-class RBAC module in `@terreno/api`:
+
+- **Permission vocabulary** (resources → actions) is statically defined by the consuming app,
+  merged with Terreno defaults, using Better Auth's `createAccessControl` as the engine.
+- **Roles** are DB-backed Mongoose documents editable at runtime through the Terreno admin,
+  hydrated into Better Auth `Role` objects (`ac.newRole(permissionsFromDb)`) at check time.
+  Terreno ships standard roles; consuming apps add their own (SuperUser, PatientGuide, …).
+- **Users hold many roles**; effective permissions are the union of all their roles plus any
+  grants from **external permission sources** (e.g. a Healthie adapter).
+- **Document-level scopes** and **field-level views** cover the dynamic cases RBAC alone can't
+  ("any PG can view any patient, but only edit patients on their panel"; "patients see fewer
+  fields than staff").
+- **One `can()` check** is enforced across REST (modelRouter + custom routes), websockets
+  (subscribe + emit), MCP tools, and the admin panel.
+- **Everything has a function escape hatch** so consuming apps (Flourish) can migrate
+  incrementally without a big-bang rewrite.
+
+Nothing in this design is Flourish-specific; PatientGuide/Healthie examples below are
+illustrations of consuming-app usage.
+
+## 2. Concepts
+
+| Concept | What it is | Where it lives |
+|---|---|---|
+| **Statement** | Map of resource → allowed actions (`{patient: ["read", "update"]}`) | Static, in code, per app (merged with Terreno defaults) |
+| **Permission** | One resource:action pair (`patient:update`) | Derived from statements |
+| **Role** | Named bundle of permissions (`PatientGuide`) | DB (`RbacRole` collection), editable in admin; Terreno ships defaults |
+| **Grant** | Roles/permissions attached to a user | `user.roles: string[]` (+ external sources) |
+| **Scope** | Per-document predicate/query narrowing an action (`patient:update` only on panel) | Code, registered by app as functions |
+| **Field view** | Per-permission read/write field mask (Patient vs Staff vs SuperUser view) | Code, registered by app |
+| **Permission source** | External system contributing grants (Healthie) | Code, adapter interface |
+
+The split is deliberate: **what can be granted** (statements, scopes, views) is code — typed,
+reviewed, versioned. **Who has what** (roles, assignments) is data — editable at runtime in the
+admin UI. This mirrors Better Auth's own design, where dynamic roles can only recombine a
+statically defined vocabulary, and it is what makes "permissions can be dynamically added by the
+consuming app but not limited by Terreno" work.
+
+## 3. Module layout
+
+```
+api/src/rbac/
+  index.ts            # Public exports
+  statements.ts       # terrenoStatements, mergeStatements
+  access.ts           # createAccess, TerrenoAccess class (wraps better-auth ac)
+  roleModel.ts        # RbacRole Mongoose model + terrenoDefaultRoles seed
+  userPlugin.ts       # rbacUserPlugin (adds roles: string[] to user schema)
+  scopes.ts           # ResourceScope types + evaluation
+  fieldViews.ts       # Field view types + apply/pick logic
+  middleware.ts       # requireAccess() express middleware, IsPermitted() adapter
+  resolve.ts          # Role resolution + caching + PermissionSource merging
+  routes.ts           # rbacRouter (roles CRUD, catalog, previews)
+  betterAuthBridge.ts # Mirror ac/roles into better-auth admin plugin when enabled
+```
+
+Exports land in `@terreno/api` root: `createAccess`, `terrenoStatements`, `terrenoDefaultRoles`,
+`rbacUserPlugin`, `rbacRouter`, `IsPermitted`, `requireAccess`, plus all types.
+
+---
+
+## 4. API designs
+
+### 4.1 Permission vocabulary (statements)
+
+Terreno re-exports Better Auth's engine and ships default statements for everything the
+framework itself gates today:
+
+```typescript
+// api/src/rbac/statements.ts
+export const terrenoStatements = {
+  // Admin panel access + admin-only surfaces
+  admin: ["access", "runScripts", "viewBackgroundTasks"],
+  // Managing the RBAC system itself
+  rbac: ["read", "manageRoles", "assignRoles"],
+  // The framework user model (auth surfaces, admin user CRUD)
+  user: ["create", "list", "read", "update", "delete", "impersonate", "setPassword"],
+  // Feature flag / configuration app
+  configuration: ["read", "update"],
+} as const;
+
+export type Statements = Record<string, readonly string[]>;
+
+// Same {resource: [actions]} shape better-auth uses everywhere
+export type PermissionSet = {[resource: string]: readonly string[]};
+```
+
+The consuming app defines its own vocabulary and merges:
+
+```typescript
+// consuming app: src/access.ts
+import {createAccess, terrenoStatements} from "@terreno/api";
+
+export const statements = {
+  ...terrenoStatements,
+  patient: ["create", "read", "update", "delete", "readClinical", "updateClinical"],
+  careplan: ["create", "read", "update", "approve"],
+  staff: ["create", "read", "update"],
+} as const;
+```
+
+Notes:
+
+- `as const` is required (Better Auth's literal-type inference).
+- Actions are arbitrary strings — apps can model verbs beyond CRUD (`approve`,
+  `readClinical`), which is how "abilities" attach to roles.
+- Adding a resource/action is a code change + deploy. That is a feature: the vocabulary is the
+  contract that scopes, field views, routes, and the admin UI compile against.
+
+### 4.2 `createAccess` — the central object
+
+```typescript
+// api/src/rbac/access.ts
+import {createAccessControl} from "better-auth/plugins/access";
+
+export interface AccessOptions<S extends Statements> {
+  statements: S;
+  // Code-defined roles seeded into the DB on boot (upsert; admin can then edit non-locked ones)
+  defaultRoles?: RoleDefinition[];
+  // Document-level scopes per resource (see 4.5)
+  scopes?: ResourceScopes<S>;
+  // Field-level views per resource (see 4.6)
+  fieldViews?: ResourceFieldViews<S>;
+  // External grant providers, e.g. Healthie (see 4.10)
+  sources?: PermissionSource[];
+  // Actions treated as "read-ish" when expanding the auditor read-only sentinel
+  // (READ_ONLY_ROLE_PERMISSIONS — see 4.3). Defaults to READ_ACTIONS; apps add
+  // verbs like "readClinical".
+  readActions?: readonly string[];
+  // Role resolution cache TTL in ms (default 30_000). Roles are DB-backed;
+  // checks must not hit Mongo on every request. Keep this short for compliance:
+  // revoking a role or assignment must not linger on other replicas until TTL
+  // expiry (see cross-instance invalidation on `invalidateCache` in 4.2).
+  cacheTtlMs?: number;
+  // Escape hatch: full custom resolution of a user's permission set
+  resolvePermissions?: (args: {user: User}) => Promise<PermissionSet | null>;
+  // Optional human-readable labels for the admin permission matrix
+  // (resource → action → description). Returned by GET /rbac/statements.
+  statementDescriptions?: Record<string, Record<string, string>>;
+}
+
+export const createAccess = <S extends Statements>(options: AccessOptions<S>): TerrenoAccess<S>;
+```
+
+`TerrenoAccess` is the one object apps pass around (to `TerrenoApp`, modelRouter options,
+realtime, MCP):
+
+```typescript
+export interface AccessCheckArgs<S extends Statements> {
+  user?: User;
+  // Same shape as better-auth: {resource: [actions]}, ANDed across entries
+  permissions: PermissionRequest<S>;
+  // When present, document scopes for the resource are also evaluated
+  doc?: unknown;
+  // Extra context threaded into scope functions (req, socket, etc.)
+  context?: Record<string, unknown>;
+}
+
+export interface AccessResult {
+  allowed: boolean;
+  // Which layer denied — drives 403 vs 405 and admin debugging UI
+  deniedBy?: "role" | "scope" | "source";
+  reason?: string;
+}
+
+export interface TerrenoAccess<S extends Statements> {
+  readonly statements: S;
+  // better-auth access controller, exposed for direct use / bridging
+  readonly ac: ReturnType<typeof createAccessControl>;
+
+  // The single authorization entry point (role check + optional doc scope check)
+  can(args: AccessCheckArgs<S>): Promise<AccessResult>;
+
+  // Union of a user's effective permissions (roles + sources) — powers /auth/me,
+  // client gating, and the admin "what does this user have" view. Cached.
+  getPermissions(args: {user: User}): Promise<PermissionSet>;
+
+  // Query fragment for list endpoints/subscriptions from the resource's scopes.
+  // null means "no access" (empty list), {} means unrestricted.
+  queryFilter(args: {
+    user?: User;
+    resource: keyof S & string;
+    action: string;
+    context?: Record<string, unknown>;
+  }): Promise<Record<string, unknown> | null>;
+
+  // Field mask for a doc + user (see 4.6). Used by responseHandler, realtime, MCP.
+  // Mirrors fieldViews.select: `doc` is optional and `undefined` during create
+  // (no document exists yet), and `phase` tells the resolver which enforcement
+  // point is calling so the same selector yields read/write/create masks. Create
+  // resolves the mask from user + permissions alone (see 4.6 "Create-time view
+  // resolution"). modelRouter/realtime/MCP call sites pass `phase` explicitly.
+  fieldMask(args: {
+    user?: User;
+    resource: keyof S & string;
+    doc?: unknown; // undefined during create
+    phase?: "read" | "write" | "create"; // default "read"
+  }): Promise<FieldMask>;
+
+  // Express middleware for custom routes (see 4.8)
+  middleware(permissions: PermissionRequest<S>, options?: {getDoc?: DocLoader}): RequestHandler;
+
+  // Adapter producing a legacy PermissionMethod so existing modelRouter
+  // permission arrays keep working during migration (see 4.7)
+  permission(permissions: PermissionRequest<S>): PermissionMethod<unknown>;
+
+  // Role management used by rbacRouter + admin (see 4.9)
+  roles: RoleManager;
+
+  // Drop cached role/source hydrations for one user or all users on this process.
+  // Production multi-replica deployments (e.g. Cloud Run) also need a shared
+  // invalidation channel (Redis pub/sub, version stamp on `RbacRole.updated`, …)
+  // so every instance drops stale hydrations when roles are edited — otherwise
+  // `/auth/me`, websocket permission resolution, and `getPermissions()` on
+  // other replicas serve the old set until `cacheTtlMs` expires. The IP will
+  // specify the default transport; apps can plug a custom broadcaster.
+  invalidateCache(args?: {userId?: string}): void;
+}
+```
+
+Check semantics (matches Better Auth): within one resource entry, all listed actions must be
+allowed; across resources, entries are ANDed. A user passes a role check if **any** of their
+roles authorizes the request (union across roles) — then scopes, which are restrictions, are
+ANDed on top.
+
+### 4.3 Roles: DB-backed, hydrated through Better Auth
+
+Why not use Better Auth's role objects directly? Released Better Auth only supports **static**
+global roles (dynamic access control exists for the org plugin; the admin-plugin port is an
+unmerged PR). The supported escape hatch is to store role → permission JSON ourselves and build
+role objects at check time with `ac.newRole()` — that's exactly what we do, and it works
+identically whether the app's auth provider is JWT/Passport or Better Auth.
+
+```typescript
+// api/src/rbac/roleModel.ts
+export interface RbacRoleDocument {
+  _id: ObjectId;
+  // Stable machine name stored on users ("superadmin", "patientGuide")
+  name: string;
+  displayName: string;
+  description?: string;
+  // The better-auth permission JSON: {resource: [actions]}, validated
+  // against access.statements on write
+  permissions: PermissionSet;
+  // Role exclusion rules: users cannot hold this role together with any of
+  // these (e.g. patientGuide excludes familyGuide). Enforced symmetrically
+  // on assignment.
+  excludesRoles: string[];
+  // Shipped by Terreno or the app via defaultRoles; locked roles cannot be
+  // deleted or have their name changed (permissions remain editable unless
+  // sealed — see isSealed).
+  isLocked: boolean;
+  // When true, the role is immutable through the admin API: name, description,
+  // permissions, and excludesRoles cannot be changed or deleted. Only Terreno
+  // seeds ship sealed (today: `superadmin`). Locked-but-not-sealed roles (e.g.
+  // `admin`, `auditor`) keep a stable name while their permission matrix remains
+  // editable in the admin UI.
+  isSealed: boolean;
+  created: Date;
+  updated: Date;
+}
+```
+
+Default-role `permissions` accept a `RolePermissionSpec`: either a concrete `PermissionSet`, or
+one of two **seed-time expansion sentinels** resolved against the *merged* statements when the
+role is upserted, so app-defined resources are covered without the app editing Terreno's roles:
+
+```typescript
+// api/src/rbac/roleModel.ts
+export type RolePermissionSpec =
+  | PermissionSet
+  | "*" // every action of every resource (superadmin)
+  | typeof READ_ONLY_ROLE_PERMISSIONS; // auditor: every read-ish action
+
+// "read-ish" = the intersection of each resource's actions with READ_ACTIONS.
+// Terreno's default list; apps can extend via createAccess({readActions}).
+export const READ_ACTIONS = ["read", "list", "access", "view"] as const;
+
+// Seed-time sentinel for auditor-style read-only expansion. Reference this
+// constant in defaultRoles (`permissions: READ_ONLY_ROLE_PERMISSIONS`).
+export const READ_ONLY_ROLE_PERMISSIONS = {readOnly: true} as const;
+
+// Structural check — accepts both the exported constant and any hand-rolled
+// `{readOnly: true}` object (TypeScript's structural typing allows the latter).
+const isReadOnlySentinel = (
+  spec: RolePermissionSpec,
+): spec is typeof READ_ONLY_ROLE_PERMISSIONS =>
+  typeof spec === "object" &&
+  spec !== null &&
+  !Array.isArray(spec) &&
+  Object.keys(spec).length === 1 &&
+  (spec as {readOnly?: unknown}).readOnly === true;
+
+// Applied at seed time inside createAccess, using the merged statements as the source.
+export const expandRolePermissions = (
+  spec: RolePermissionSpec,
+  statements: Statements,
+  readActions: readonly string[],
+): PermissionSet => {
+  if (spec === "*") {
+    return mapValues(statements, (actions) => [...actions]);
+  }
+  if (isReadOnlySentinel(spec)) {
+    return filterMapValues(statements, (actions) =>
+      actions.filter((a) => readActions.includes(a)),
+    );
+  }
+  return spec;
+};
+```
+
+Terreno ships default roles (generic names — app-agnostic):
+
+```typescript
+// api/src/rbac/roleModel.ts
+export const terrenoDefaultRoles: RoleDefinition[] = [
+  {
+    name: "superadmin", // the "SoftwareEngineer" role, generically named
+    displayName: "Super Admin",
+    permissions: "*", // expands to every statement action at seed time
+    isLocked: true,
+    isSealed: true,
+  },
+  {
+    name: "admin",
+    displayName: "Admin",
+    permissions: {
+      admin: ["access"],
+      user: ["create", "list", "read", "update"],
+      configuration: ["read", "update"],
+    },
+    isLocked: true,
+  },
+  {
+    name: "auditor",
+    displayName: "Auditor",
+    // Read-only *everywhere*, including app resources: expands at seed time to
+    // every resource's read-ish actions from the merged statements (parallel to
+    // superadmin's "*"). Not a hand-listed subset — see expandRolePermissions.
+    permissions: READ_ONLY_ROLE_PERMISSIONS,
+    isLocked: true,
+  },
+  {name: "member", displayName: "Member", permissions: {}, isLocked: true},
+];
+```
+
+Because expansion runs against the merged statements at seed/upsert time, the stored
+`RbacRoleDocument.permissions` is always a concrete `PermissionSet` (the sentinel is never
+persisted), so runtime checks, the admin matrix, and diffs all see the fully expanded set.
+
+At check time, roles resolve through Better Auth:
+
+```typescript
+// api/src/rbac/resolve.ts (internal)
+const hydrateRole = (roleDoc: RbacRoleDocument) => ac.newRole(roleDoc.permissions);
+// role.authorize({patient: ["update"]}) -> {success: boolean; error?: string}
+```
+
+When the app uses the Better Auth provider, `betterAuthBridge.ts` also passes `ac` and the
+seeded roles into the better-auth `admin` plugin config so `authClient.admin.checkRolePermission`
+(sync, client-side, static roles) and `auth.api.userHasPermission` work natively; DB-edited
+roles remain authoritative server-side via `access.can()`.
+
+### 4.4 Assigning roles to users
+
+```typescript
+// api/src/rbac/userPlugin.ts
+export interface RbacUser {
+  // Role names; effective permissions are the union
+  roles: string[];
+}
+
+export const rbacUserPlugin = (schema: Schema<any, any, any, any>): void => {
+  schema.add({
+    roles: {
+      type: [String],
+      default: [],
+      index: true,
+      description: "RBAC role names assigned to this user",
+    },
+  });
+};
+```
+
+Assignment goes through `RoleManager` (never raw writes) so exclusion rules and audit hooks run:
+
+```typescript
+export interface RoleManager {
+  list(): Promise<RbacRoleDocument[]>;
+  create(args: {actor: User; role: RoleInput}): Promise<RbacRoleDocument>;
+  update(args: {actor: User; roleName: string; changes: Partial<RoleInput>}): Promise<RbacRoleDocument>;
+  remove(args: {actor: User; roleName: string}): Promise<void>;
+
+  // Throws APIError 409 with the conflicting rule if excludesRoles is violated
+  assign(args: {actor: User; userId: string; roleNames: string[]}): Promise<void>;
+  unassign(args: {actor: User; userId: string; roleNames: string[]}): Promise<void>;
+
+  // Diff previews for the admin UI (see 4.11)
+  previewRoleChange(args: {roleName: string; permissions: PermissionSet}): Promise<RoleDiff>;
+  previewAssignment(args: {userId: string; roleNames: string[]}): Promise<UserPermissionDiff>;
+}
+
+export interface RoleDiff {
+  gained: PermissionSet;
+  lost: PermissionSet;
+  affectedUserCount: number;
+}
+
+export interface UserPermissionDiff {
+  gained: PermissionSet; // net-new after union with their other roles
+  lost: PermissionSet;
+  resulting: PermissionSet;
+}
+```
+
+Guardrails baked into `RoleManager` (borrowed from Better Auth's dynamic access control):
+
+- **No escalation**: an actor can only grant (or edit a role to include, or assign) permissions
+  the actor **themselves currently holds**. Holding `rbac:manageRoles` lets an actor *manage*
+  roles but never lets them hand out actions they lack — a role editor cannot bootstrap
+  privileges they do not have. The **only** exception is `superadmin`, which (via its `"*"`
+  expansion) holds every permission and so can grant anything; this is a property of *what
+  superadmin holds*, not a special "manageRoles can escalate" rule. Concretely: the check is
+  `actorPermissions ⊇ permissionsBeingGranted`, evaluated against the actor's effective set.
+- **Vocabulary validation**: every `resource:action` in `permissions` must exist in
+  `access.statements` — writes with unknown pairs are 400s.
+- **Managing roles requires** `rbac:manageRoles`; assigning requires `rbac:assignRoles`. These
+  gate *access* to the operation and are additive to (not a substitute for) the no-escalation
+  subset check above.
+- **`excludesRoles` remediation**: assignment-time 409s are not enough when an admin later
+  *adds* an exclusion to a role that conflicts with roles users already hold. `RoleManager.update`
+  rejects the role change (400) until every affected user is remediated — the error payload lists
+  conflicting `(userId, roleA, roleB)` tuples. Admins resolve via `previewRoleChange` (shows
+  affected users) and explicit `unassign` calls; Terreno never silently leaves a violated
+  invariant in place.
+- **Audit (required)**: every successful `RoleManager` create/update/remove/assign/unassign
+  **must** emit an `RbacAudit` record (built-in collection and/or pluggable sink — see 7.4).
+  Denied escalation attempts (actor tried to grant permissions they lack) are also logged at
+  `warn` with actor, target, and the rejected permission delta for abuse detection.
+
+### 4.5 Document-level scopes (the dynamic layer)
+
+RBAC answers "can PatientGuides update patients?" Scopes answer "**this** patient?" They are
+functions in code (typed against the app's models), keyed by resource and action:
+
+```typescript
+// api/src/rbac/scopes.ts
+export interface ScopeArgs<TDoc> {
+  user: User;
+  action: string;
+  doc?: TDoc; // absent during pre-flight (create/list) checks
+  context?: Record<string, unknown>; // req, socket, mcp session...
+}
+
+export interface ResourceScope<TDoc = unknown> {
+  // Object-level predicate; runs after the role check passes.
+  // Return true/false, or a PermissionSet to demand extra permissions
+  // (e.g. editing a doc in "final" status requires careplan:approve).
+  check?: (args: ScopeArgs<TDoc>) => boolean | PermissionSet | Promise<boolean | PermissionSet>;
+  // Mongo query fragment for list/subscription filtering — the same
+  // constraint as `check`, expressed as a query. null = no access.
+  filter?: (args: ScopeArgs<TDoc>) => Promise<Record<string, unknown> | null>;
+}
+
+// Keyed "resource.action"; "resource.*" applies to all actions of the resource
+export type ResourceScopes<S extends Statements> = {
+  [key: string]: ResourceScope;
+};
+```
+
+**Coupling `check` and `filter` (no drift).** A per-document `check` and a list/subscription
+`filter` that express *different* constraints silently corrupt authorization: a list could
+return rows a per-doc read would reject, or vice versa. The design forbids that two ways:
+
+1. **`defineScope` factory (preferred).** A scope is derived from a single predicate expressed
+   once as a Mongo query fragment. The factory produces the `filter` (the fragment) and the
+   `check` (the same fragment evaluated against the in-memory doc via a lightweight matcher),
+   so the two can never disagree:
+
+   ```typescript
+   export interface ScopeDefinition<TDoc> {
+     // The one source of truth: the constraint as a query fragment (null = no access).
+     matches: (args: ScopeArgs<TDoc>) => Promise<Record<string, unknown> | null> | Record<string, unknown> | null;
+     // Optional elevation that skips the constraint for both check and filter.
+     adminBypass?: (args: ScopeArgs<TDoc>) => boolean | Promise<boolean>;
+     // How to read a field path off a loaded doc before comparison (defaults to
+     // dot-path lookup). Used when a fragment references populated refs — unwrap
+     // and normalize (e.g. string-coerce ObjectIds) here. The generated `check`
+     // evaluates the full `matches` fragment against the in-memory doc using the
+     // same semantics as Mongo (equality, `$in`, `$eq`, …) via a lightweight
+     // matcher — not only flat String equality on a single leaf.
+     fieldOf?: (doc: TDoc, path: string) => unknown;
+   }
+
+   // Returns {check, filter} whose logic is guaranteed identical.
+   export const defineScope = <TDoc>(def: ScopeDefinition<TDoc>): ResourceScope<TDoc>;
+   ```
+
+2. **Parity tests for hand-written scopes.** When an app supplies a raw `{check, filter}` pair
+   (needed for constraints not expressible as a static fragment), Terreno ships a
+   `assertScopeParity(scope, {samples})` test helper and requires each such scope key to have a
+   conformance test that feeds sample docs/users through both `check` and the `filter`-derived
+   query and asserts they agree. `createAccess` warns (dev) when a scope defines both `check`
+   and `filter` by hand without a registered parity test.
+
+Consuming-app example (the PatientGuide panel case) — **`defineScope` so check and filter
+cannot drift**:
+
+```typescript
+// One helper encodes the constraint once; both list/subscription filter and per-doc
+// check evaluate the same predicate (supervisor-of-pod, on-panel, or active PTO coverage).
+const patientUpdateScope = defineScope<PatientDocument>({
+  matches: async ({user, doc}) => {
+    const staff = user as unknown as StaffDocument;
+    const editableIds = await editablePatientIds(staff); // shared: panel + PTO + supervised pods
+    if (!editableIds.length) {
+      return null;
+    }
+    // List/subscription: constrain to the same id set the per-doc check uses.
+    return {_id: {$in: editableIds}};
+  },
+  // Per-doc check: fragment value vs doc._id (String equality, ObjectId-safe).
+  fieldOf: (doc, path) => (path === "_id" ? String(doc._id) : undefined),
+});
+
+const access = createAccess({
+  statements,
+  scopes: {
+    // Any role with patient:read can read any patient — no read scope.
+    "patient.update": patientUpdateScope,
+    "careplan.approve": defineScope<CareplanDocument>({
+      matches: ({user}) => (user ? {assignedPsychiatristId: user.id} : null),
+      fieldOf: (doc, path) =>
+        path === "assignedPsychiatristId" ? String(doc.assignedPsychiatristId) : undefined,
+    }),
+  },
+});
+```
+
+When a scope truly cannot be expressed as one Mongo fragment (rare), supply a hand-written
+`{check, filter}` pair **and** register `assertScopeParity(scope, {samples})` covering every
+branch (panel vs PTO vs cross-pod supervisor, etc.). `createAccess` warns in dev if both are
+hand-written without a parity test — the anti-pattern is divergent predicates, not hand-writing
+per se.
+
+Semantics:
+
+- Scopes are **restrictions only** — they can never grant an action the user's roles don't
+  include. Role check first, scope second. (`superadmin` does not bypass scopes by default;
+  a scope can opt in by checking permissions itself.)
+- `check` without a `doc` (create pre-flight) is only called if defined for the action; scopes
+  that need a doc are skipped pre-flight and enforced post-load — same two-phase flow the
+  current `permissionMiddleware` already implements (405 pre-object, 403 post-object).
+- `filter` is merged (`$and`) with `queryFields`/`defaultQueryParams` in list handlers and
+  websocket query subscriptions — replacing today's ad-hoc `queryFilter`/`OwnerQueryFilter`.
+
+Terreno ships the common scope as a helper, replacing `Permissions.IsOwner` + `OwnerQueryFilter`.
+Its per-document behavior must preserve today's `IsOwner` semantics exactly: **admins bypass
+ownership** — `IsOwner` returns `true` for `user.admin === true` on any document. Note the current
+`OwnerQueryFilter` does *not* share that bypass: it always narrows list queries to
+`{ownerId: user.id}` and never checks `user.admin`, so today an admin's per-document access and
+their list access disagree (admins can read/update any single owned-model doc but list endpoints
+still scope them to their own rows). `OwnerScope` deliberately unifies the two behind one
+`adminBypass` predicate (default: the legacy `user.admin` flag) applied to **both** the per-doc
+`check` and the list/subscription `filter` (where the bypass yields `{}` — no narrowing), so
+admins get consistent unrestricted read/update/delete/list access and migrated flows lose no
+privilege:
+
+```typescript
+export interface OwnerScopeOptions {
+  field?: string; // owner id path, default "ownerId"
+  // Elevated actors that skip the ownership constraint entirely.
+  // Default preserves legacy IsOwner behavior (user.admin === true) and also
+  // treats holders of the superadmin role as unrestricted.
+  adminBypass?: (args: {user?: User}) => boolean | Promise<boolean>;
+}
+
+export const OwnerScope = (options: string | OwnerScopeOptions = {}): ResourceScope => {
+  const {field = "ownerId", adminBypass = defaultAdminBypass} =
+    typeof options === "string" ? {field: options} : options;
+  return defineScope<unknown>({
+    // One predicate drives both check and filter (see below); adminBypass short-circuits both.
+    adminBypass,
+    // Mongo filter matches the raw stored ownerId (an ObjectId) against the user id.
+    matches: ({user}) => (user ? {[field]: user.id} : null),
+    // The in-memory check must mirror IsOwner exactly: unwrap a *populated*
+    // ownerId (`{_id}`) and normalize to a string so ObjectId, string, and
+    // populated-document shapes all compare equal. defineScope's generated
+    // `check` applies String(...) equality between the fragment value and this
+    // return (see fieldOf note in 4.5), matching Mongo's ObjectId coercion — so
+    // a populated `ownerId` is never falsely denied.
+    fieldOf: (doc) => {
+      const owner = (doc as Record<string, unknown> | undefined)?.[field];
+      const ownerId = (owner as {_id?: unknown} | null | undefined)?._id ?? owner;
+      return ownerId == null ? undefined : String(ownerId);
+    },
+  });
+};
+
+// defaultAdminBypass = ({user}) => Boolean((user as any)?.admin) || hasRole(user, "superadmin")
+```
+
+Because `OwnerScope` bypasses for admins, the "superadmin does not bypass scopes by default"
+rule in 4.5 is a rule about *generic* scopes; ownership-style scopes opt into elevation
+explicitly through `adminBypass` so no privilege is silently lost during migration.
+
+### 4.6 Field-level views (attribute permissions)
+
+Named projections per resource, chosen by a function of user + doc, applied everywhere a
+document is serialized (REST responses, realtime emits, MCP tool output) and validated on write:
+
+```typescript
+// api/src/rbac/fieldViews.ts
+export interface FieldMask {
+  read: string[] | "*"; // dot paths; "*" = all
+  write: string[] | "*";
+  omit?: string[]; // always stripped even from "*" (hash, salt, ...)
+}
+
+export interface ResourceFieldViews<S extends Statements> {
+  [resource: string]: {
+    views: Record<string, FieldMask>;
+    // Pick a view for this user + (maybe) doc. Function escape hatch: return a
+    // FieldMask directly for fully dynamic cases.
+    //
+    // `doc` is OPTIONAL because it is absent at create time (no document exists
+    // yet). `phase` tells the selector which enforcement point is calling:
+    //   - "read"  : serializing a loaded doc (doc always present)
+    //   - "write" : validating an update body against an existing doc (doc present)
+    //   - "create": validating a create body — doc is undefined; the selector
+    //               must decide from user + permissions alone.
+    // Selectors that branch on `doc` fields must handle `doc === undefined` for
+    // the create phase (see create-time resolution below).
+    select: (args: {
+      user?: User;
+      doc?: unknown; // undefined during create
+      permissions: PermissionSet; // the user's effective set, pre-resolved
+      phase: "read" | "write" | "create";
+    }) => string | FieldMask | Promise<string | FieldMask>;
+  };
+}
+```
+
+**Create-time view resolution.** Because no document exists yet, create validation resolves the
+write mask from the user's permissions only:
+
+- The selector is called with `phase: "create"` and `doc: undefined`. It should return a view
+  keyed off `user`/`permissions` (the common case — the `patient` example below already does
+  this, since its branches read only `permissions`).
+- If a selector *needs* a doc and returns nothing usable when `doc` is undefined, `createAccess`
+  requires an explicit `createView?: string | FieldMask` (or `createView: "deny"`) per resource
+  as the fallback; omitting it while a selector dereferences `doc` is a boot-time config error,
+  not a silent full-access default.
+- The chosen mask's `write` paths are the create allow-list; body keys outside it are rejected
+  exactly as in update. `read`/`omit` from the same mask then shape the create response.
+
+Consuming-app example (Patient vs Staff vs SuperUser views):
+
+```typescript
+fieldViews: {
+  patient: {
+    views: {
+      self: {read: ["name", "email", "appointments", "careTeam"], write: ["name", "email"]},
+      staff: {read: "*", write: ["name", "email", "podId", "notes"], omit: ["ssn"]},
+      full: {read: "*", write: "*", omit: []},
+    },
+    select: ({user, doc, permissions}) => {
+      if (permissions.patient?.includes("updateClinical")) {
+        return "full";
+      }
+      if (permissions.staff?.includes("read")) {
+        return "staff";
+      }
+      return "self";
+    },
+  },
+},
+```
+
+Enforcement points:
+
+- **Read**: `defaultResponseHandler` and `realtimeResponseHandler` call
+  `access.fieldMask()` and strip; MCP handlers do the same.
+- **Write**: create/update handlers reject (400 with field-level errors) any body key outside
+  the mask's `write` — replacing the deprecated `TerrenoTransformer.transform`. Update resolves
+  the mask with the loaded doc (`phase: "write"`); create resolves it without a doc
+  (`phase: "create"`) per the create-time rule above.
+- The OpenAPI spec documents the superset; masks are runtime behavior (same as today's
+  responseHandler stripping).
+
+### 4.7 modelRouter integration
+
+New `access` option; `permissions` arrays stay supported (deprecated) for migration:
+
+```typescript
+export interface ModelRouterAccessOptions {
+  // Must be a key of access.statements
+  resource: string;
+  // Optional REST-method → action override. Defaults:
+  // list → "list" if the resource declares it, else "read"; read → "read";
+  // create → "create"; update → "update"; delete → "delete".
+  actions?: Partial<Record<RESTMethod, string | null>>; // null disables the method
+  // Per-route additions layered on the registry-level config
+  scope?: ResourceScope;
+  // Per-method function escape hatch, same signature as today's
+  // PermissionMethod — ANDed after the RBAC check
+  also?: Partial<Record<RESTMethod, PermissionMethod<unknown>[]>>;
+  allowAnonymous?: boolean;
+}
+
+export interface ModelRouterOptions<T> {
+  /** @deprecated use `access` */
+  permissions?: RESTPermissions<T>;
+  access?: ModelRouterAccessOptions;
+  // queryFilter still works and is $and-merged with scope filters
+  // ...
+}
+```
+
+Usage:
+
+```typescript
+export const patientRouter = modelRouter("/patients", Patient, {
+  access: {
+    resource: "patient",
+    actions: {delete: null}, // disabled, like today's []
+  },
+  queryFields: ["_id", "podId", "status"],
+  sort: "-created",
+});
+```
+
+Route behavior (unchanged status semantics): missing role permission pre-object → 405 with the
+verb omitted from OpenAPI only when statically disabled (`actions.delete = null`); scope denial
+post-object → 403. `instanceActions`/`collectionActions` gain the same
+`access?: {resource, action}` option alongside their `permissions` arrays.
+
+For apps not ready to restructure a router, the adapter keeps the old shape working:
+
+```typescript
+permissions: {
+  create: [IsPermitted(access, {patient: ["create"]})],
+  list: [IsPermitted(access, {patient: ["read"]})],
+  read: [IsPermitted(access, {patient: ["read"]})],
+  update: [IsPermitted(access, {patient: ["update"]}), SomeLegacyCheck],
+  delete: [],
+},
+```
+
+`IsPermitted` returns a standard `PermissionMethod` — it calls `access.can()` with the doc when
+present, so it slots into existing arrays and AND-composes with legacy checks.
+
+### 4.8 Custom routes, websockets, MCP
+
+**Custom routes** — one middleware replaces the ad-hoc `adminGuard`s:
+
+```typescript
+router.post("/patients/:id/discharge", [
+  authenticateMiddleware(),
+  access.middleware({patient: ["update"], careplan: ["approve"]}, {
+    getDoc: (req) => Patient.findOneOrThrow({_id: req.params.id}), // enables scope checks
+  }),
+  createOpenApiBuilder(options)./* ... */.build(),
+], asyncHandler(async (req, res) => { /* ... */ }));
+```
+
+**Websockets** — `RealtimeApp` swaps its internals to the same object:
+
+- `subscribe:model` / `subscribe:query` → `access.can({permissions: {[resource]: [listAction]}})`
+  plus `access.queryFilter()` merged into the subscription query.
+- Per-event emission (`canReadDocument`) → `access.can({..., doc})`, then
+  `access.fieldMask()` before serializing — so a patient and a staff member in the same room
+  receive different payloads.
+- **Identity**: socket users are currently rebuilt from JWT claims only. Because roles are
+  DB-editable, the socket path resolves roles through `access.getPermissions()` (cached,
+  invalidated on role edit) rather than trusting `decodedToken.admin`. `generateJWTPayload`
+  may still embed `roles` as a hint, but the DB is authoritative.
+
+**MCP** — the planned modelRouter MCP handlers (docs/tasks/model-router-mcp.md) already route
+through `checkPermissions()`; they call `access.can()`/`fieldMask()` instead, with
+`context: {transport: "mcp"}` so scopes can distinguish transports if needed.
+
+### 4.9 RBAC HTTP surface
+
+Mounted by registering the router (a `TerrenoPlugin`), colocated with the admin basePath:
+
+```typescript
+new TerrenoApp({userModel: User, accessControl: access})
+  .register(rbacRouter({access, userModel: User}))
+  .register(patientRouter)
+  .start();
+```
+
+| Method | Path | Permission | Purpose |
+|---|---|---|---|
+| GET | `/rbac/statements` | `rbac:read` | Full vocabulary (+ optional `statementDescriptions`) for the admin UI |
+| GET | `/rbac/roles` | `rbac:read` | List roles with permissions + user counts |
+| POST | `/rbac/roles` | `rbac:manageRoles` | Create role |
+| PATCH | `/rbac/roles/:name` | `rbac:manageRoles` | Edit role (validates vocabulary, escalation, locks) |
+| DELETE | `/rbac/roles/:name` | `rbac:manageRoles` | Delete (blocked for locked roles / roles in use) |
+| POST | `/rbac/roles/:name/preview` | `rbac:manageRoles` | `RoleDiff`: permissions gained/lost + affected user count |
+| GET | `/rbac/users/:id/permissions` | `rbac:read` | Effective `PermissionSet` + which role/source grants each |
+| PUT | `/rbac/users/:id/roles` | `rbac:assignRoles` | Replace assignments (409 on exclusion conflicts) |
+| POST | `/rbac/users/:id/roles/preview` | `rbac:assignRoles` | `UserPermissionDiff` for the confirmation modal |
+
+`GET /auth/me` additionally returns `roles: string[]` and `permissions: PermissionSet` so
+clients can gate UI without extra round-trips (server remains authoritative).
+
+### 4.10 External permission sources (Healthie)
+
+Healthie (and future integrations) contribute grants without owning the model:
+
+```typescript
+// api/src/rbac/resolve.ts
+export interface PermissionSourceGrants {
+  roles?: string[]; // must exist in RbacRole
+  permissions?: PermissionSet; // direct grants, validated against statements
+  deny?: PermissionSet; // hard denials — win over every grant
+}
+
+export type StaleOnFailurePolicy =
+  | "deny" // default — drop this source's grants on refresh failure (fail closed)
+  | "use-stale" // reuse last successful grants (never for elevation-only sources)
+  | "use-stale-bounded"; // reuse stale grants only if younger than staleMaxAgeMs
+
+export interface PermissionSource {
+  name: string;
+  ttlMs?: number; // per-source cache (default: access cacheTtlMs)
+  // What to do when getGrants() fails after a prior successful fetch.
+  // Default "deny": external grants are omitted; local DB roles still apply.
+  // Sources that can elevate beyond local roles must use "deny" or
+  // "use-stale-bounded" with a short staleMaxAgeMs — never unbounded stale reuse.
+  staleOnFailure?: StaleOnFailurePolicy;
+  staleMaxAgeMs?: number; // required when staleOnFailure === "use-stale-bounded"
+  getGrants(args: {user: User}): Promise<PermissionSourceGrants | null>;
+}
+```
+
+Consuming-app sketch:
+
+```typescript
+const healthieSource: PermissionSource = {
+  name: "healthie",
+  ttlMs: 5 * 60_000,
+  getGrants: async ({user}) => {
+    const staff = await Staff.findOneOrNone({userId: user.id});
+    if (!staff?.healthieId) {
+      return null;
+    }
+    const healthieRole = await healthieClient.getProviderRole(staff.healthieId);
+    return {roles: [healthieRoleMap[healthieRole] ?? "member"]};
+  },
+};
+```
+
+Resolution order inside `getPermissions()` / `can()`:
+`union(user.roles, source roles, source permissions)` minus `source denies`.
+
+**Source refresh failures (fail closed by default).** When `getGrants()` throws or times out,
+behavior is per-source `staleOnFailure` (default `"deny"`):
+
+| Policy | Behavior |
+|---|---|
+| `"deny"` (default) | Omit this source's grants for the request. Local `user.roles` and other sources still apply. Revoked upstream access cannot linger because a dependency is down. |
+| `"use-stale-bounded"` | Reuse the last successful grants only if younger than `staleMaxAgeMs` (hard cap). Suitable for read-only hints, not elevation. |
+| `"use-stale"` | Reuse last successful grants until TTL expiry. **Not permitted** for sources that can grant roles/permissions beyond what local roles already provide — elevation paths must fail closed. |
+
+`PermissionSource.deny` already fails closed; grant caching matches that posture for elevation.
+Logged at `warn` with source name and policy applied.
+
+### 4.11 Admin UI (first-class)
+
+New screens in `admin-frontend` / `admin-spa`, driven entirely by the 4.9 endpoints:
+
+- **Roles list** (`/admin/roles`): every role, its permission matrix (resources × actions
+  grid from `/rbac/statements`), user count, locked/sealed badges.
+- **Role editor**: checkbox matrix; on save, shows the `/preview` `RoleDiff` in a confirmation
+  modal — "PatientGuide will **gain** `careplan:approve` and **lose** `user:create`; affects
+  212 users."
+- **User role assignment** (embedded in the admin user detail): multi-select of roles with
+  exclusion conflicts surfaced inline; confirmation modal shows `UserPermissionDiff` (total
+  permissions gained/lost after union with their remaining roles).
+- **Effective permissions inspector**: per user, each permission annotated with its source
+  ("via PatientGuide", "via healthie").
+
+The admin panel itself migrates from `IsAdmin` to `admin:access` (+ per-model resources), which
+finally makes graded admin access possible (the `auditor` role gets `admin:access` + read-only
+model permissions).
+
+### 4.12 Client-side helpers
+
+- `@terreno/rtk`: `useSelectPermissions()` / `useCan({patient: ["update"]})` selectors reading
+  the `permissions` from `/auth/me`. When the Better Auth provider is active, static roles also
+  work with `authClient.admin.checkRolePermission` via the bridge.
+- `@terreno/ui`: nothing required; apps gate with `useCan` + existing components.
+
+---
+
+## 5. Migration path
+
+1. **Ship the module inert.** `createAccess` etc. exist; nothing changes unless an app passes
+   `access` options. Legacy `Permissions.*` remain exported.
+2. **Legacy shims.** `Permissions.IsAdmin` becomes `IsPermitted(access, {admin: ["access"]})`
+   semantics when an access registry is configured: seed maps `user.admin === true` →
+   `superadmin` role (a one-time backfill script Terreno provides:
+   `bunx terreno rbac:backfill-admins --role-map ./rbac-role-map.json`). The map file is
+   required when legacy role names do not match Terreno defaults (e.g. Flourish StaffRole →
+   RBAC role name); the script dry-runs by default and supports per-tenant overrides.
+   `IsOwner`/`OwnerQueryFilter` → `OwnerScope`.
+3. **Router-by-router adoption** in consuming apps via `IsPermitted` in existing arrays, then
+   the full `access:` option. The `also:` escape hatch and function-based scopes mean any
+   existing bespoke check can be ported verbatim as a function first, refined later.
+4. **Flip the admin packages** to `admin:access`, ship the roles UI.
+5. **Realtime + MCP** switch internally to `access.can()` (no consumer API change).
+6. Deprecate `RESTPermissions` arrays in a future major.
+
+## 6. Staff roles — recommendation (open for discussion)
+
+The question posed: single staff role (PG/FG/Therapist/Psychiatrist) vs. rules that disallow
+combinations.
+
+**Recommendation: keep StaffRole as consuming-app domain data, and use `excludesRoles` for the
+constraint** rather than forcing single-role:
+
+- `excludesRoles` (4.3) gives "cannot be both PG and FG" declaratively, enforced at assignment
+  time with a clear 409, and is visible in the admin UI. It generalizes (Supervisor+Auditor
+  could also be excluded) without a schema change.
+- A hard single-role rule couples Terreno to one org design and dies the first time someone is
+  legitimately dual-hatted (Therapist who supervises). Exclusion rules express the actual
+  invariant ("these two conflict") instead of a blanket cardinality.
+- StaffRole-as-domain-concept (what appears on schedules, care team displays, Healthie sync)
+  should *reference* an RBAC role for its permissions but remain a separate model in the
+  consuming app — permissions are what the RBAC system owns; job titles are not. The Healthie
+  source (4.10) maps Healthie provider types onto RBAC roles the same way.
+- The pod-scoped supervisor problem ("Onyx PG Supervisor shouldn't touch Lilac PGs") is
+  deliberately **not** a role: it's a scope (4.5) keyed on the supervision relationship, so one
+  `supervisor` role works across pods without a role-per-pod explosion.
+
+New scoped roles like "Human Resources" (`staff:create`, `user:create`, no `patient:*`) then
+fall out of the admin UI with zero code — the exact win the RBAC move is for.
+
+## 7. Resolved decisions (formerly open questions)
+
+1. **Top role name**: **`superadmin`** (generic machine name; apps customize `displayName`).
+2. **Should scopes ever grant?** **No — restrictions only.** Grant cases use extra actions
+   (`readClinical`) instead.
+3. **Per-permission scope bypass for superadmin**: **Default off**; opt in per scope via
+   `adminBypass` (as `OwnerScope` does).
+4. **Role assignment audit trail**: **Separate `RbacAudit` collection** from consuming-app
+   audit logs (e.g. Flourish `AuditLogEvent`), but **every** successful role/assignment write
+   must emit an audit record — built-in and/or pluggable sink; optional/minimal logging is not
+   sufficient for HIPAA consumers. Fields: actor, action, target role/user, permission delta,
+   timestamp. Denied escalation attempts are logged too (see 4.4).
+5. **JWT `roles` claim**: **Hint only** (DB authoritative, cached). Multi-replica cache
+   invalidation is part of the IP so `/auth/me` and websockets do not lag role edits across
+   Cloud Run instances (see `invalidateCache` in 4.2).
+6. **Deny semantics**: **Only `PermissionSource.deny`** — roles do not carry negative
+   permissions (union semantics stay simple; matches Better Auth).
+
+## 8. Phasing sketch (full task breakdown in the IP)
+
+1. **Core**: statements/merge, `createAccess`, resolve+cache, `RbacRole` model + seeds,
+   `rbacUserPlugin`, `IsPermitted`, `requireAccess` middleware. Tests.
+2. **modelRouter**: `access` option, scope-aware permission middleware, filter merging,
+   field-mask response handling, actions support.
+3. **HTTP surface**: `rbacRouter`, previews, `/auth/me` extension, backfill script.
+4. **Admin**: roles screens, diffs, user assignment, `admin:access` migration.
+5. **Realtime + MCP**: swap internals to `access.can()`/`fieldMask()`.
+6. **Sources + client**: `PermissionSource`, rtk selectors, Better Auth bridge, docs +
+   example-backend/-frontend demonstration (example app gets a `manager` role and a scoped
+   todo example).