@happyvertical/smrt-users 0.45.0 → 0.45.2

package/dist/manifest.json

@@ -2,7 +2,7 @@
   "version": "1.0.0",
   "timestamp": 0,
   "packageName": "@happyvertical/smrt-users",
-  "packageVersion": "0.45.0",
+  "packageVersion": "0.45.2",
   "objects": {
     "@happyvertical/smrt-users:AccessRequestCollection": {
       "name": "accessrequestcollection",
@@ -4120,7 +4120,9 @@
         "mcp": {
           "include": []
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "UsersMagicLinkToken",
@@ -4279,7 +4281,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "Membership",
@@ -4470,7 +4474,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "MembershipOverride",
@@ -4648,7 +4654,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "Permission",
@@ -4804,7 +4812,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "Role",
@@ -5240,7 +5250,9 @@
         "mcp": {
           "include": []
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "Session",
@@ -5493,7 +5505,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "Tenant",
@@ -5784,7 +5798,9 @@
             "get"
           ]
         },
-        "cli": true,
+        "cli": {
+          "skipApiCheck": true
+        },
         "tenantScoped": {
           "mode": "required"
         }
@@ -5965,7 +5981,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "TenantPermissionOverride",
@@ -6179,7 +6197,9 @@
             "get"
           ]
         },
-        "cli": true
+        "cli": {
+          "skipApiCheck": true
+        }
       },
       "extends": "SmrtObject",
       "exportName": "User",

package/dist/smrt-knowledge.json

@@ -3,13 +3,16 @@
   "sensitiveFieldsExcluded": true,
   "generatedAt": "1970-01-01T00:00:00.000Z",
   "packageName": "@happyvertical/smrt-users",
-  "packageVersion": "0.45.0",
+  "packageVersion": "0.45.2",
   "sourceManifestPath": "dist/manifest.json",
   "agentDocPath": "AGENTS.md",
   "sourceHashes": {
-    "manifest": "0ef6f0d5d5e5f0eaba2dea9b7aabbd72805c243b5e7c739c14beae7e6e341dac",
-    "packageJson": "2216a73f97a188ef4d7b91b47016c068f98245fff399f186464e0ca1e6867a6f",
-    "agents": "0b36b90b6859635caf8854d833f6b89a494e4b55d538fd3597bc03d8dc8b3234",
+    "manifest": "fe8d99e875574123d286bdca134901aa03fe4176abc7abcec91f265b824318d7",
+    "packageJson": "5ae1849a8722c284453553b4138db5af292de381c1d632d8ee7517a33c8c3409",
+    "agents": "ec09e41d9c5e1b55abf454eb5b88a98637094e2aa67bffce2f11db0dcb68b441",
+    "moduleDoc:agents/permissions.md": "f801411ae51fc625ad99054e284fd1abc6e7b2a5555dd8797a83dfd30273db68",
+    "moduleDoc:agents/oidc-provisioning.md": "cbab59f0819466de764514ba268026effdb9fa8b651285736e6c12d246b96ab9",
+    "moduleDoc:agents/mobile-auth.md": "25e85e83f43e3a46383a92fa809f3a003b4545c3026e78dbe1bccbbc35161e18",
     "moduleDoc:agents/retention.md": "425c0a34ed33969badfef699751bfa670bdf618eda65e079e00815620aabed68"
   },
   "exports": [
@@ -9867,8 +9870,23 @@
     "polymorphicAssociations": 0,
     "uuidColumns": 58
   },
-  "agentDoc": "# @happyvertical/smrt-users\n\nMulti-tenant user management with RBAC, hierarchical tenants, session handling, and SvelteKit integration.\n\n## Modules\n\n| Module | Scope | Module doc |\n|---|---|---|\n| `src/retention.ts` | expired session/token/CLI-auth reaping and its wiring into the framework retention sweep | [agents/retention.md](agents/retention.md) |\n\n## Models (14)\n\n| Model | Key Pattern |\n|-------|-------------|\n| User | Auth identity. `profileId` is a unique cross-package reference to smrt-profiles (one User per non-null Profile). Email auto-lowercased; readonly nullable unique `emailKey` is derived on save for durable normalized uniqueness. |\n| AccessRequest | \"Request access / waitlist\" record captured before a `User` exists. CLOSED generated surface (`api`/`mcp`/`cli` = `[]`) — all access via `AccessRequestService`. Email normalized + indexed; JSON `requestContext` (NOT `context` — reserved for slug scoping). |\n| Tenant | **STI** + hierarchical parent-child. `hierarchyPath` (materialized path), `hierarchyLevel`. Max depth 10. |\n| Session | Server-side. Secure UUID. TTL in **seconds** (not ms). Status auto-updates to EXPIRED on access. |\n| MagicLinkToken | Single-use email login token. Backed by `MagicLinkService`. |\n| Role | `tenantId = null` → system role (available to all tenants). `isSystem: true` blocks deletion. `inheritsToDescendants: true` (default false) opts the role's membership authority into descendant tenants. |\n| Permission | Slug format: `resource.action`. Parsed by PermissionResolver. |\n| Membership | User + Tenant + Role junction. UNIQUE(userId, tenantId). |\n| Group | Team within a tenant. Multiple roles via GroupRole. |\n| GroupMember, GroupRole, RolePermission | Join tables. |\n| MembershipOverride | Per-user permission grant/deny. **DENY always wins.** |\n| TenantPermissionOverride | Tenant-level cascade overrides. Effect: INHERIT/GRANT/DENY. |\n\n## Permission Resolution — Precedence (broad → specific, most-specific wins)\n\n`PermissionResolver.resolvePermissions` builds the effective set in this order;\neach later layer overrides earlier ones:\n\n1. **Tenant-inherited** — walk ancestors, apply each `TenantPermissionOverride`\n   down the cascade (GRANT adds, DENY removes within the hierarchy)\n2. **Membership role** — base permissions from the user's role in the tenant\n3. **Group roles** — permissions from all groups the user belongs to **in that tenant**\n4. **Tenant-level DENY** *(removes; overrides role/group grants, tenant-wide)* — a\n   `TenantPermissionOverride` with effect `DENY` is a HARD, tenant-wide block: it\n   subtracts the DENY'd slug even if a role or group granted it (steps 2–3). It\n   sits just **above** the per-user membership overrides and **below** role/group.\n5. **Membership GRANT override** *(re-adds; most specific)* — a per-user GRANT can\n   re-add a slug a tenant DENY'd in step 4, because it is more specific.\n6. **Membership DENY override** *(absolute; always wins)* — a per-user DENY removes\n   the slug last and is never overridden.\n\nSo a permission a role grants but the tenant DENYs is **removed**, unless that\nexact user also has a membership-GRANT override for it. A membership-DENY always\nwins. Tenant-DENY of an inherited/cascade grant still blocks it (unchanged).\nThe hard block reflects the tenant cascade's **net** resolution, not an\nunconditional union of every DENY in the chain — so a more-specific tenant GRANT\n(e.g. a child sub-tenant re-granting a permission its parent DENYs) still wins.\n\n### Membership selection — hierarchical inheritance (opt-in, #1866)\n\nWhich membership feeds step 2 above:\n\n1. **A direct membership row in the target tenant always pins resolution to\n   itself** — active rows resolve normally; an inactive (pending/suspended)\n   row resolves to the **empty set**. A direct row therefore *attenuates*\n   rather than unions: \"viewer here, despite being network admin\" gives\n   viewer, and a suspension in the child is effective even for users holding\n   inheritable authority on an ancestor.\n2. **No direct row** → the resolver walks the tenant's ancestors (nearest\n   first, from `hierarchyPath`) and resolves through the **nearest ACTIVE\n   ancestor membership whose role has `inheritsToDescendants: true`**.\n   Unflagged or inactive ancestor memberships are skipped (they neither confer\n   nor block); there is **no union across the chain** — the nearest flagged\n   membership alone is used. To attenuate a specific descendant, create a\n   direct membership there or use a tenant-level DENY.\n3. **No qualifying ancestor** → empty set (byte-identical to the\n   pre-inheritance resolver; with no role flagged, nothing changes).\n\n`loadSessionContext()` exposes `tenantAuthorization`; required-tenant consumers\nmust validate it because `membership: null` can mean inherited authority.\n\nAll later layers run unchanged against the **target** tenant: the tenant\ncascade and tenant-DENY hard block come from the target tenant (a child can\ncarve authority out of an inherited role), group roles stay exact-tenant (only\ntarget-tenant groups contribute; ancestor groups never flow down), and\nmembership GRANT/DENY overrides travel with the ancestor membership used.\n`PermissionResolutionResult.inheritedFromTenantId` reports the ancestor tenant\nwhen inheritance was used (`null` for direct resolution).\n\nSafety: resolution is bounded by `MAX_TENANT_HIERARCHY_DEPTH`; malformed\n`hierarchyPath` values fail closed to the empty set — too deep,\nself-referential, duplicate ancestors, or inconsistent with the actual\n`parentTenantId` chain (the path is verified link-by-link against the loaded\nancestor rows before it is trusted as an authorization source). Tenant `status` is not consulted (parity with direct\nresolution). Caching: a long-lived `(user, tenant)` permission cache must also\ninvalidate on ancestor-membership changes and on `Role.inheritsToDescendants`\nflips — request-scoped caches (the common pattern) are unaffected.\n\nFlag roles at seed time with\n`seedSystemRoles({ inheritsToDescendants: ['owner', 'admin'] })` (additive:\nlisted slugs are flagged, omitted slugs are never unflagged; unknown slugs\nthrow). The default seed leaves every role exact-tenant.\n\n## Operation Permission Guards\n\nSMRT derives a fine-grained, per-`<collection>.<action>` permission catalog **from the\nmanifest** (`PermissionCatalogService`, including custom `@smrt` actions — not just CRUD)\nand enforces it two ways: app-side via `assertOperationPermission()` / `PermissionResolver`,\nand at the database via generated **Postgres RLS** policies\n(`generatePostgresPermissionSql()` / `applyPostgresPermissionPolicies()`) that read the\nsession-injected `smrt.permissions` / `smrt.tenant_id` (set by `withSessionPermissionContext`\nvia `set_config`). Because the RLS teeth are at the data layer, enforcement is door-agnostic\n— REST, MCP, and in-process callers are all bounded once the principal's context is set.\nSetup: README → *Manifest-derived permission catalog* and *Postgres RLS enforcement*.\n\n- Use `assertOperationPermission()` for hand-written mutations in SvelteKit form\n  actions, custom endpoints, CLI scripts, and jobs. It derives the same\n  `<collection>.<action>` slugs as `PermissionCatalogService` (`list`/`get` →\n  `read`), requires the slug to exist in the catalog, then resolves permissions\n  through `PermissionResolver`.\n- `assertOperationPermission()` throws fail-closed by default. Use\n  `{ onDeny: 'return' }`, `checkOperationPermission()`, or\n  `hasOperationPermission()` when a structured/boolean result is needed.\n- **Resource-tenant calling convention**: for resource-anchored authorization,\n  pass the **resource's** tenant id — `tenantId: resourceTenantId` — not the\n  session's current tenant. With `Role.inheritsToDescendants` flagged, a\n  root-tenant admin then passes for any descendant resource with no app-side\n  authority logic (and no membership fan-out), while per-child delegation and\n  DENY precedence keep working. Do NOT pass a session-scoped `membership`\n  alongside a different resource `tenantId` — a membership/tenant mismatch\n  fails closed by design; omit `membership` and let the resolver look it up.\n- System context and super-admin bypass context are honored for parity with\n  Postgres RLS. Pass `{ allowSuperAdminBypass: false }` on money-class or\n  separation-of-duties operations that must require an explicit permission grant.\n- **Postgres RLS and membership inheritance**: RLS policies check the\n  session-injected `smrt.permissions` list (resolved app-side by\n  `PermissionResolver`), so a session whose `smrt.tenant_id` IS the child\n  tenant gets inherited authority in RLS automatically. But RLS row filtering\n  stays bound to the session's tenant setting — a root-tenant session acting\n  on child-tenant rows is authorized by the app-level guard (resource-tenant\n  convention above), not by RLS. This is a documented divergence, mirroring\n  how #1829 handled bypass parity.\n- Seed role mappings with `RolePermissionCollection.seedRolePermissions()` or\n  `RoleCollection.seedSystemRoles({ seedPermissions: true })`. The default\n  matrix maps owner/admin to all catalog permissions, member to read/create for\n  ordinary app resources, and viewer to read-only. Member create grants\n  intentionally exclude users/RBAC authority and security resources (`users`,\n  `tenants`, `roles`, `permissions`, memberships, groups, sessions, magic-link\n  tokens, and related join/override tables). Re-seeding is additive and\n  idempotent; pruning stale mappings requires `{ prune: true }`. When a\n  contributing package registers a new built-in self-personalization\n  permission after system roles already exist, call the explicit,\n  idempotent `RolePermissionCollection.seedDefaultRolePersonalizationPermissions()`\n  upgrade helper; it targets owner/admin/member/viewer only and never grants\n  custom roles.\n\n**Critical**: `getGroupIdsForTenant(userId, tenantId)` (joins with groups table to scope by tenant). Never use `getGroupIds()` — it's cross-tenant.\n\n## Hierarchical Tenants\n\n- `TenantCollection.createChild()` auto-calculates hierarchy fields, enforces depth limit\n- `moveToParent()` updates tenant + ALL descendants' paths/levels\n- `cascadePermissions` (parent pushes down) + `inheritPermissions` (child accepts) — both must be true\n- `getTree(rootId?)` returns nested structure for UI\n- Two independent downward flows: the `TenantPermissionOverride` **cascade**\n  (tenant-level permission config, flags above) and **membership-role\n  inheritance** (`Role.inheritsToDescendants`, per-role opt-in — see\n  \"Membership selection\" above). The cascade flags do not gate membership\n  inheritance.\n\n## SvelteKit Integration\n\n```typescript\n// hooks.server.ts\nexport const handle = createSessionHandler({ db, ttl: 604800, skipPaths: ['/api/public'] });\n// Populates event.locals: { user, membership, permissions: string[], tenantId, sessionId }\n\n// +page.server.ts\nawait createSessionCookie(event, userId, tenantId, { db });\nawait destroySessionCookie(event, { db });\nawait switchSessionTenant(event, tenantId, { db });\n```\n\n## Mobile `/api/mobile` Handlers (ADR 0001 Phase 3.5, #1748)\n\n`createMobileAuthHandlers(options)` (from `/sveltekit`) returns the mountable\nserver side of the KMP mobile contract: `authStart` (`POST auth/start`,\nserver-brokered PKCE via `OidcLoginService`), `authComplete`\n(`POST auth/complete`, code + echoed `state`/`codeVerifier` → bearer\nsession), `session.GET`/`session.DELETE` (bootstrap/logout), and\n`guard`/`withSession` — the bearer middleware for app-owned mobile routes.\nCore logic lives in `MobileAuthService` (framework-agnostic; exported from\nthe package root).\n\n- **Bearer = session id** (same convention as `TerminalAuthService`); 401\n  bodies are `{ error, code }` and drive the mobile client's re-auth flow.\n- **Stateless handshake**: the OAuth `state` is an HMAC-signed token\n  (secret: `stateSecret` ?? provider `clientSecret`) carrying\n  nonce/provider/createdAt — full ID-token nonce verification with no\n  server-side pending state. The `codeVerifier` never enters a URL: it is\n  client-held per the frozen contract.\n- **Wire DTOs** come from `@happyvertical/smrt-mobile-contract`\n  (`MobileAuthStartRequest` etc.) — one owning package for the Kotlin,\n  Swift, and TypeScript shapes (compile-checked descriptors + parity test).\n- **Tenant options** honor `Role.inheritsToDescendants` (#1867): direct\n  ACTIVE memberships plus descendants of flagged memberships (nearest\n  flagged ancestor labels the option; any direct row pins; inactive direct\n  rows exclude). Session binding defaults to the first DIRECT tenant —\n  override with `resolveTenantId`.\n- **Hooks**: `resolveUser` (invite-gating; default provisions via\n  `getOrCreateFromOidc`), `resolveTenantId`, `buildExtras` (bootstrap\n  `extras`; model JSON must use `toPublicJSON({ permissions })` — #1822).\n  `buildExtras` is the only app-domain bootstrap extension point. Never emit\n  app fields such as `dashboard` at the response top level: they are outside\n  `MobileSessionBootstrap` and the Kotlin decoder ignores them.\n- **Guard** wraps `withSessionPermissionContext`, so\n  `assertOperationPermission`, tenancy context, and Postgres RLS all see the\n  bearer caller; `OperationPermissionError` maps to 403 with a\n  machine-readable `reason`.\n- **Uploads**: `resolveMobileUploadDedupKey` + the documented contract in\n  `docs/content/architecture/mobile-upload-contract.md` (`clientCaptureId`\n  field, `Idempotency-Key` header fallback); domain ingestion stays\n  app-side. Framework-model writes ride `sync/apply`, not this path.\n- Configure `redirectUris` in production — RFC 8252 scheme rules always\n  apply, but the allow list is the defense against redirecting authorization\n  responses to attacker-controlled URIs.\n\n## Security (S5 #1400)\n\n- **Generated REST/MCP surface is READ-ONLY for every RBAC/identity model.**\n  User, Tenant, Group, Membership, MembershipOverride, Role, Permission,\n  RolePermission, GroupRole, GroupMember, and TenantPermissionOverride generate\n  `list`/`get` only — `create`/`update`/`delete` are intentionally NOT\n  generated. The merged `requireRouteAuth` gate (#1540) enforces *authentication*,\n  not *authorization*, and these models are not `@TenantScoped`, so an\n  auto-generated mutating route would let any authenticated user self-grant a\n  role/permission, flip a tenant's cascade flags, or change another user's auth\n  identity. Mutate them through the permission-gated services (`TenantService`,\n  collection helpers) or consumer-owned, permission-checked handlers. A\n  structural regression test (`security-audit-1400.test.ts`) enumerates the\n  registry to assert no authority model exposes a mutating op. (`cli` stays\n  enabled — local-operator surface, outside the network/agent threat model.)\n- **`switchTenant` is fail-closed AND rotates the session id.**\n  `SessionService.switchTenant` / `switchSessionTenant` verify the session's user\n  has an ACTIVE membership in the target tenant before any write (the tenant id\n  is the isolation key for every `@TenantScoped` query). A non-member/unknown-\n  session switch returns `{ switched: false, sessionId: null, ... }` and mutates\n  nothing. On a successful switch into a NON-null tenant the session id is\n  ROTATED: a fresh `Session` (new secure id, fresh TTL, same user, new tenant,\n  device context carried over) is minted and the old session is REVOKED — so a\n  captured pre-switch id immediately stops validating, shrinking the blast radius\n  of a leaked id across a tenant boundary. `switchTenant` returns a\n  `SwitchTenantResult` (`{ switched, sessionId, session, rotated }`); callers MUST\n  persist the returned `sessionId`. `switchSessionTenant` does this for you by\n  re-setting the session cookie (preserving httpOnly/secure/sameSite) to the new\n  id. A `null` clear stays in place (no rotation, no cookie change). The\n  low-level `SessionCollection.setSessionTenant` is the UNGUARDED primitive (used\n  for the null-clear path) — never call it with an untrusted tenant id.\n- **OIDC `email_verified` is enforced.** `UserCollection.getOrCreateFromOidc`\n  refuses to provision a user when the IdP explicitly returns\n  `email_verified: false` (opt out with `{ allowUnverifiedEmail: true }`). An\n  absent claim makes no assertion and is not enforced.\n- **RFC 9207 response issuer is exact.** OIDC callbacks validate a supplied\n  `iss` against discovered metadata with exact string comparison before trusting\n  a code or error. If metadata advertises issuer-response support, `iss` is\n  required.\n- **Verified-email Profile reuse is fail-closed.** The typed canonical scenarios\n  live in\n  `packages/profiles/src/testing/oidcProvisioningDecisionMatrix.ts`; both\n  package suites execute that matrix and public docs reference it rather than\n  maintaining another behavioral table. Default provisioning reuses only one\n  unowned, global `Person`. Tenant-scoped, non-Person, duplicate-email,\n  and already-owned matches fail before User/session creation. An existing\n  issuer/subject link without a User must still be the unique global Person for\n  the current verified claim email; once owned, the stable issuer/subject link\n  reuses its canonical Person and owner.\n  Issuer and subject are opaque, case-sensitive identifiers; preserve their\n  exact value and use trim only to reject blank claims.\n- **`resolveProfile` is the application reconciliation boundary.** The\n  SvelteKit handlers, `OidcLoginService`, and `getOrCreateFromOidc` accept the\n  same hook inside the provisioning transaction. The service/handler path\n  supplies protocol-validated claims; direct collection callers must validate\n  and trust their claim source before calling `getOrCreateFromOidc`.\n  Token/userinfo merging keeps `email` and `email_verified` paired to the same\n  claim source; verification is never borrowed across sources.\n  Resolver reads/writes use the supplied `db`, and the hook must be idempotent\n  because a concurrent unique-key conflict can retry it. `undefined` chooses\n  the secure default and `null` rejects, including exact issuer/subject reuse.\n  For a new identity, a supplied Profile is still validated as the unique,\n  unowned global Person for the verified email. For an exact existing identity,\n  it must be the already-linked Profile and cannot rebind identity authority;\n  stable-link owner and canonical-Person checks still apply. The hook receives a\n  separate frozen claims snapshot; internal retry and persistence state is not\n  exposed for mutation.\n- **Owned first binding requires `authorizeProfileOwner`.** An invitation or\n  approval workflow may explicitly return both its pre-provisioned canonical\n  global `Person` and existing approved `User` from this transaction-bound\n  hook. `undefined` keeps the secure `profile_owned` default and `null`\n  rejects. SMRT treats only the selected IDs as input, reloads them in the\n  provisioning transaction, and requires `email_verified === true`, the unique\n  canonical global Person for the normalized claim email, exactly one owner,\n  that owner as the selected User, and the same normalized User email. The\n  hook runs before identity/User/session creation and may be retried, so use\n  only its supplied `db` and `users` handles and keep application authorization\n  idempotent. Never authorize from email matching alone. Existing exact\n  identities cannot be rebound; when `resolveProfile` is also present both\n  hooks must select the same Profile.\n- **OIDC first login is atomic.** The Profile, `OidcIdentity`, and User are one\n  transaction. The database arbiters are `OidcIdentity.identityKey`,\n  private `oidc_profile_email_reservations.email_key`, `User.emailKey`, and the\n  unique `User.profileId`; local callbacks acquire exact issuer/subject and normalized\n  email locks in deterministic order so changed email claims also serialize.\n  SQLite and DuckDB callbacks additionally serialize every root-handle statement\n  the coordinator owns per database URL — `_smrt_backfills` initialization, the\n  transaction, and the post-commit rebind — because one adapter multiplexes a\n  single native connection and cannot safely overlap unrelated root\n  transactions. Never overlap two statements on one such handle, inside a\n  transaction or not: rebind and owner/email candidate reads are sequential,\n  never `Promise.all`. Owner-authorized DuckDB callbacks use that same\n  root-handle serialization;\n  PostgreSQL deadlock and serialization errors use a bounded transaction retry.\n  Newly provisioned Profiles use non-semantic per-profile slugs so equal IdP\n  display names cannot trigger a natural-key upsert;\n  run\n  `smrt db:status`, `smrt db:migrate`, then `smrt db:status` before deployment.\n  Stop or upgrade old writers first. Before migration, group\n  non-null `users.profile_id` values, then reconcile duplicates. After\n  migration, run public `backfillProfileEmailKeys(db)` followed by\n  `backfillUserEmailKeys(db)` from one deploy process. Both use the shared\n  TypeScript `normalizeIdentityEmail()` implementation transactionally and are\n  idempotent; the User backfill fails before writes if normalized duplicates\n  remain. Every OIDC path requires the Profile email-key readiness marker;\n  creating a User or checking User email uniqueness additionally requires the\n  User marker. A stable issuer/subject with an existing owning User skips only\n  the User email-key lookup and marker. Full scans remain in the explicit deploy\n  step; guarded runtime paths use indexed keys and validate only returned\n  candidates. Multiple null links remain valid.\n  Legacy race keys backfill only after canonical validation. Pass a root\n  database on adapters such as DuckDB that cannot create nested savepoints.\n  Root adapters must expose `beginTransaction`; transaction-only handles are\n  ambiguous and fail closed before provisioning writes. Caller-owned\n  transactions never run `_smrt_backfills` DDL and require that table to\n  already exist; use the root database when initialization or recovery is\n  needed.\n\n## Gotchas\n\n- **seedSystemRoles() required**: call `RoleCollection.seedSystemRoles()` at app init (creates owner/admin/member/viewer)\n- **PermissionResolver casts `as any`**: collections have protected constructors — known framework limitation\n- **Session TTL in seconds**: `DEFAULT_SESSION_TTL = 7 * 24 * 60 * 60` (not milliseconds)\n- **Users are cross-tenant**: one user, many tenants via Membership. Email globally unique.\n- **Batch permission queries**: resolver fetches all permission IDs in one query, then maps to slugs (avoids N+1)\n",
+  "agentDoc": "# @happyvertical/smrt-users\n\nMulti-tenant identity, RBAC, hierarchical tenants, sessions, and SvelteKit auth.\n\n## Modules\n\nRead only the module relevant to the change; protocol and provisioning details\nare not prerequisites for unrelated user-package work.\n\n| Module | Scope | Module doc |\n|---|---|---|\n| `src/services/PermissionResolver.ts` | permission precedence, inherited memberships, guards, RLS, role seeding | [agents/permissions.md](agents/permissions.md) |\n| `src/services/OidcLoginService.ts`, collections and OIDC handlers | identity reconciliation, transaction boundaries, migration readiness | [agents/oidc-provisioning.md](agents/oidc-provisioning.md) |\n| `src/services/MobileAuthService.ts` | mobile handshake, bearer sessions, bootstrap extension boundary | [agents/mobile-auth.md](agents/mobile-auth.md) |\n| `src/retention.ts` | expired session/token/CLI-auth reaping and retention sweep wiring | [agents/retention.md](agents/retention.md) |\n\n## Models and authority\n\n- Users are global; tenant access comes through Membership (unique user/tenant).\n  User email is normalized and globally unique through readonly nullable\n  `emailKey`. `profileId` is a unique cross-package reference: at most one User\n  owns each non-null Profile.\n- Tenant uses STI and a materialized hierarchy, maximum depth 10.\n  `createChild()` calculates paths; `moveToParent()` updates all descendants.\n- Role with `tenantId = null` is available to all tenants; `isSystem` prevents\n  deletion. `inheritsToDescendants` is opt-in. Seed owner/admin/member/viewer\n  through `RoleCollection.seedSystemRoles()` at application initialization.\n- Group roles apply only in their own tenant. Use `getGroupIdsForTenant()`,\n  never cross-tenant `getGroupIds()`, for authorization.\n- Membership DENY always wins. Direct inactive membership blocks inherited\n  authority; a direct active membership pins resolution instead of unioning it\n  with ancestors. Read the permissions module before changing these rules.\n- AccessRequest has no generated API/MCP/CLI operations; access it through\n  `AccessRequestService`. Its JSON field is `requestContext`, not reserved\n  slug-scoping `context`.\n\n## Security boundaries\n\n- Generated REST/MCP operations on identity/RBAC models are list/get only.\n  Route authentication does not authorize authority mutations, and these models\n  are not tenant-scoped. Use permission-gated services or explicitly checked\n  consumer handlers. CLI remains a local-operator surface. Preserve the\n  registry assertions in `security-audit-1400.test.ts`.\n- Resource guards take the resource tenant, not the session tenant. Omit a\n  session membership when targeting a different tenant; mismatches fail closed.\n  `loadSessionContext().tenantAuthorization` must be checked by required-tenant\n  consumers: null membership can represent inherited authority.\n- Sessions use secure UUIDs; TTL is seconds (default seven days). Access marks\n  expired sessions EXPIRED. Magic-link tokens are single use.\n- Tenant switching verifies active membership before writing and rotates the\n  session ID for non-null targets, revoking the old session. Persist the returned\n  `SwitchTenantResult.sessionId`; `switchSessionTenant()` updates the cookie and\n  preserves its security settings. Failed switches mutate nothing; null clears\n  do not rotate. `SessionCollection.setSessionTenant()` is unguarded and must\n  never receive an untrusted tenant ID.\n- OIDC provisioning is atomic and fail-closed. Preserve exact issuer/subject\n  identifiers, claim-source email verification, unique global Person ownership,\n  and transaction-bound reconciliation. Read the OIDC module and canonical\n  scenario matrix before changing any provisioning path.\n\n## Entry points and validation\n\n`src/sveltekit/` owns `createSessionHandler`, `createSessionCookie`,\n`destroySessionCookie`, and `switchSessionTenant`. Use README integration examples\nrather than copying application setup into these instructions.\n\nFrom the repository root:\n\n```bash\npnpm --filter @happyvertical/smrt-users test\npnpm --filter @happyvertical/smrt-users typecheck\npnpm --filter @happyvertical/smrt-users test:postgres\n```\n\nStart with the relevant test file via `test -- src/__tests__/<file>.test.ts`.\nRun `test:postgres` for RLS, principal context, OIDC, or terminal-auth database\nchanges. `typecheck` includes Svelte accessibility checks; plain `tsc` is\ninsufficient. Follow root knowledge freshness checks before shipping.\n",
   "moduleDocs": [
+    {
+      "path": "agents/permissions.md",
+      "module": "permissions",
+      "content": "# Permissions and tenant inheritance\n\nRead for `src/services/PermissionResolver.ts`, operation guards, role seeding,\nRLS, and tenant-hierarchy changes. Integration examples live in README's\nmanifest-derived permission catalog and PostgreSQL RLS sections.\n\n## Membership selection\n\n1. A direct target-tenant membership pins resolution: active resolves normally;\n   pending/suspended returns empty. Never union direct and ancestor roles.\n2. Otherwise walk hierarchyPath nearest-first for the nearest active ancestor\n   membership whose role has inheritsToDescendants. Skip inactive/unflagged\n   ancestors; they neither grant nor block. No qualifying ancestor means empty.\n3. Run later layers against the target tenant. Only target-tenant groups apply;\n   membership overrides travel with the chosen ancestor membership.\n   inheritedFromTenantId reports that ancestor, null for direct resolution.\n\nVerify hierarchyPath link-by-link against loaded parentTenantId rows before\ntrusting it: excess depth, self-reference, duplicates or inconsistent paths\nfail closed. Bound traversal by MAX_TENANT_HIERARCHY_DEPTH. Tenant status is not\nconsulted, matching direct resolution. Long-lived user/tenant caches must\ninvalidate ancestor membership changes and inheritsToDescendants flips;\nrequest-scoped caches do not survive those requests.\n\n`loadSessionContext().tenantAuthorization` is authoritative for required-tenant\nconsumers; membership null can mean inherited authority.\n\n## Permission precedence\n\nApply these layers in order, later layers overriding earlier ones:\n\n1. Ancestor TenantPermissionOverride cascade (GRANT adds, DENY removes).\n2. Selected membership role permissions.\n3. Target-tenant group-role permissions.\n4. Tenant cascade's net DENY removes role/group grants.\n5. Membership GRANT may re-add a tenant-denied slug.\n6. Membership DENY removes last and always wins.\n\nThe tenant block is the cascade's net result, not the union of historical DENYs:\na child's more-specific GRANT can override a parent DENY. Use a direct child\nmembership or tenant DENY to attenuate inherited role authority.\n`getGroupIdsForTenant(userId, tenantId)` is required; getGroupIds is cross-tenant.\n\n## Hierarchies and seeding\n\n- createChild calculates paths/depth; moveToParent updates all descendants;\n  getTree(rootId?) returns UI structure. Maximum depth is 10.\n- Tenant override cascade requires parent cascadePermissions and child\n  inheritPermissions. These flags do not gate the independent, per-role\n  inheritsToDescendants membership flow.\n- seedSystemRoles({ inheritsToDescendants: ['owner', 'admin'] }) flags listed\n  slugs additively, never unflags omitted ones, and rejects unknown slugs.\n  Default seeds are exact-tenant.\n- RolePermissionCollection.seedRolePermissions() or\n  seedSystemRoles({ seedPermissions: true }) maps owner/admin to all catalog\n  permissions, member to ordinary-resource read/create, viewer to read. Member\n  create excludes identity/RBAC/security resources and their joins/overrides.\n  Seeding is additive/idempotent; removal requires prune: true.\n- When a package adds built-in self-personalization permissions after role\n  creation, explicitly call seedDefaultRolePersonalizationPermissions(). It\n  upgrades owner/admin/member/viewer idempotently and never grants custom roles.\n\n## Guards and RLS\n\nPermissionCatalogService derives collection.action slugs from manifests,\nincluding custom actions; list/get map to read. Hand-written mutations in form\nhandlers, endpoints, CLI and jobs use assertOperationPermission(). It requires\ncatalog presence then resolves permissions, throwing fail-closed by default.\nUse onDeny: 'return', checkOperationPermission or hasOperationPermission only\nwhen the caller handles a structured/boolean denial.\n\nResource-anchored guards receive the resource tenant ID. When it differs from\nthe session tenant, omit the session membership so the resolver selects the\nappropriate authority; mismatched supplied membership/tenant fails closed.\nInherited root-admin authority can then authorize descendant resources without\napplication-side membership fan-out.\n\nSystem context and super-admin bypass are honored. Pass\nallowSuperAdminBypass: false for money or separation-of-duties operations that\nrequire an explicit grant.\n\ngeneratePostgresPermissionSql/applyPostgresPermissionPolicies enforce generated\nRLS using smrt.permissions and smrt.tenant_id, installed with set_config by\nwithSessionPermissionContext. This bounds REST, MCP and in-process database\naccess once principal context is set. Child-tenant sessions receive resolved\ninherited permissions automatically, but RLS row filtering remains bound to the\nsession tenant: a root session's app-level guard authorization does not itself\npermit child rows through RLS. Preserve this distinction.\n"
+    },
+    {
+      "path": "agents/oidc-provisioning.md",
+      "module": "oidc-provisioning",
+      "content": "# OIDC provisioning\n\nRead for changes to `src/collections/UserCollection.ts`, `src/services/OidcLoginService.ts`,\nOIDC handlers, or identity migrations. The canonical scenario matrix is\n`packages/profiles/src/testing/oidcProvisioningDecisionMatrix.ts`.\n\n- **OIDC `email_verified` is enforced.** `UserCollection.getOrCreateFromOidc`\n  refuses to provision a user when the IdP explicitly returns\n  `email_verified: false` (opt out with `{ allowUnverifiedEmail: true }`). An\n  absent claim makes no assertion and is not enforced.\n- **RFC 9207 response issuer is exact.** OIDC callbacks validate a supplied\n  `iss` against discovered metadata with exact string comparison before trusting\n  a code or error. If metadata advertises issuer-response support, `iss` is\n  required.\n- **Verified-email Profile reuse is fail-closed.** The typed canonical scenarios\n  live in\n  `packages/profiles/src/testing/oidcProvisioningDecisionMatrix.ts`; both\n  package suites execute that matrix and public docs reference it rather than\n  maintaining another behavioral table. Default provisioning reuses only one\n  unowned, global `Person`. Tenant-scoped, non-Person, duplicate-email,\n  and already-owned matches fail before User/session creation. An existing\n  issuer/subject link without a User must still be the unique global Person for\n  the current verified claim email; once owned, the stable issuer/subject link\n  reuses its canonical Person and owner.\n  Issuer and subject are opaque, case-sensitive identifiers; preserve their\n  exact value and use trim only to reject blank claims.\n- **`resolveProfile` is the application reconciliation boundary.** The\n  SvelteKit handlers, `OidcLoginService`, and `getOrCreateFromOidc` accept the\n  same hook inside the provisioning transaction. The service/handler path\n  supplies protocol-validated claims; direct collection callers must validate\n  and trust their claim source before calling `getOrCreateFromOidc`.\n  Token/userinfo merging keeps `email` and `email_verified` paired to the same\n  claim source; verification is never borrowed across sources.\n  Resolver reads/writes use the supplied `db`, and the hook must be idempotent\n  because a concurrent unique-key conflict can retry it. `undefined` chooses\n  the secure default and `null` rejects, including exact issuer/subject reuse.\n  For a new identity, a supplied Profile is still validated as the unique,\n  unowned global Person for the verified email. For an exact existing identity,\n  it must be the already-linked Profile and cannot rebind identity authority;\n  stable-link owner and canonical-Person checks still apply. The hook receives a\n  separate frozen claims snapshot; internal retry and persistence state is not\n  exposed for mutation.\n- **Owned first binding requires `authorizeProfileOwner`.** An invitation or\n  approval workflow may explicitly return both its pre-provisioned canonical\n  global `Person` and existing approved `User` from this transaction-bound\n  hook. `undefined` keeps the secure `profile_owned` default and `null`\n  rejects. SMRT treats only the selected IDs as input, reloads them in the\n  provisioning transaction, and requires `email_verified === true`, the unique\n  canonical global Person for the normalized claim email, exactly one owner,\n  that owner as the selected User, and the same normalized User email. The\n  hook runs before identity/User/session creation and may be retried, so use\n  only its supplied `db` and `users` handles and keep application authorization\n  idempotent. Never authorize from email matching alone. Existing exact\n  identities cannot be rebound; when `resolveProfile` is also present both\n  hooks must select the same Profile.\n- **OIDC first login is atomic.** The Profile, `OidcIdentity`, and User are one\n  transaction. The database arbiters are `OidcIdentity.identityKey`,\n  private `oidc_profile_email_reservations.email_key`, `User.emailKey`, and the\n  unique `User.profileId`; local callbacks acquire exact issuer/subject and normalized\n  email locks in deterministic order so changed email claims also serialize.\n  SQLite and DuckDB callbacks additionally serialize every root-handle statement\n  the coordinator owns per database URL — `_smrt_backfills` initialization, the\n  transaction, and the post-commit rebind — because one adapter multiplexes a\n  single native connection and cannot safely overlap unrelated root\n  transactions. Never overlap two statements on one such handle, inside a\n  transaction or not: rebind and owner/email candidate reads are sequential,\n  never `Promise.all`. Owner-authorized DuckDB callbacks use that same\n  root-handle serialization;\n  PostgreSQL deadlock and serialization errors use a bounded transaction retry.\n  Newly provisioned Profiles use non-semantic per-profile slugs so equal IdP\n  display names cannot trigger a natural-key upsert;\n  run\n  `smrt db:status`, `smrt db:migrate`, then `smrt db:status` before deployment.\n  Stop or upgrade old writers first. Before migration, group\n  non-null `users.profile_id` values, then reconcile duplicates. After\n  migration, run public `backfillProfileEmailKeys(db)` followed by\n  `backfillUserEmailKeys(db)` from one deploy process. Both use the shared\n  TypeScript `normalizeIdentityEmail()` implementation transactionally and are\n  idempotent; the User backfill fails before writes if normalized duplicates\n  remain. Every OIDC path requires the Profile email-key readiness marker;\n  creating a User or checking User email uniqueness additionally requires the\n  User marker. A stable issuer/subject with an existing owning User skips only\n  the User email-key lookup and marker. Full scans remain in the explicit deploy\n  step; guarded runtime paths use indexed keys and validate only returned\n  candidates. Multiple null links remain valid.\n  Legacy race keys backfill only after canonical validation. Pass a root\n  database on adapters such as DuckDB that cannot create nested savepoints.\n  Root adapters must expose `beginTransaction`; transaction-only handles are\n  ambiguous and fail closed before provisioning writes. Caller-owned\n  transactions never run `_smrt_backfills` DDL and require that table to\n  already exist; use the root database when initialization or recovery is\n  needed.\n"
+    },
+    {
+      "path": "agents/mobile-auth.md",
+      "module": "mobile-auth",
+      "content": "# Mobile authentication\n\nRead for `src/services/MobileAuthService.ts` and `/sveltekit` mobile handlers.\n\n`createMobileAuthHandlers(options)` (from `/sveltekit`) returns the mountable\nserver side of the KMP mobile contract: `authStart` (`POST auth/start`,\nserver-brokered PKCE via `OidcLoginService`), `authComplete`\n(`POST auth/complete`, code + echoed `state`/`codeVerifier` → bearer\nsession), `session.GET`/`session.DELETE` (bootstrap/logout), and\n`guard`/`withSession` — the bearer middleware for app-owned mobile routes.\nCore logic lives in `MobileAuthService` (framework-agnostic; exported from\nthe package root).\n\n- **Bearer = session id** (same convention as `TerminalAuthService`); 401\n  bodies are `{ error, code }` and drive the mobile client's re-auth flow.\n- **Stateless handshake**: the OAuth `state` is an HMAC-signed token\n  (secret: `stateSecret` ?? provider `clientSecret`) carrying\n  nonce/provider/createdAt — full ID-token nonce verification with no\n  server-side pending state. The `codeVerifier` never enters a URL: it is\n  client-held per the frozen contract.\n- **Wire DTOs** come from `@happyvertical/smrt-mobile-contract`\n  (`MobileAuthStartRequest` etc.) — one owning package for the Kotlin,\n  Swift, and TypeScript shapes (compile-checked descriptors + parity test).\n- **Tenant options** honor `Role.inheritsToDescendants` (#1867): direct\n  ACTIVE memberships plus descendants of flagged memberships (nearest\n  flagged ancestor labels the option; any direct row pins; inactive direct\n  rows exclude). Session binding defaults to the first DIRECT tenant —\n  override with `resolveTenantId`.\n- **Hooks**: `resolveUser` (invite-gating; default provisions via\n  `getOrCreateFromOidc`), `resolveTenantId`, `buildExtras` (bootstrap\n  `extras`; model JSON must use `toPublicJSON({ permissions })` — #1822).\n  `buildExtras` is the only app-domain bootstrap extension point. Never emit\n  app fields such as `dashboard` at the response top level: they are outside\n  `MobileSessionBootstrap` and the Kotlin decoder ignores them.\n- **Guard** wraps `withSessionPermissionContext`, so\n  `assertOperationPermission`, tenancy context, and Postgres RLS all see the\n  bearer caller; `OperationPermissionError` maps to 403 with a\n  machine-readable `reason`.\n- **Uploads**: `resolveMobileUploadDedupKey` + the documented contract in\n  `docs/content/architecture/mobile-upload-contract.md` (`clientCaptureId`\n  field, `Idempotency-Key` header fallback); domain ingestion stays\n  app-side. Framework-model writes ride `sync/apply`, not this path.\n- Configure `redirectUris` in production — RFC 8252 scheme rules always\n  apply, but the allow list is the defense against redirecting authorization\n  responses to attacker-controlled URIs.\n"
+    },
     {
       "path": "agents/retention.md",
       "module": "retention",

package/dist/sveltekit.js

@@ -1,4 +1,4 @@
-import { C as decodeOidcTransaction, E as resolveOidcProviderConfig, S as OidcLoginService, T as getUsersOidcConfig, _ as readMobileBearerToken, a as TerminalAuthRateLimitError, g as MobileAuthService, h as MobileAuthError, i as TerminalAuthError, m as withSessionPermissionContext, o as TerminalAuthService, s as OperationPermissionError, v as validateMobileRedirectUri, w as encodeOidcTransaction, x as OidcLoginError, y as SessionService } from "./chunks/TerminalAuthService-DEobPLL2.js";
+import { C as decodeOidcTransaction, E as resolveOidcProviderConfig, S as OidcLoginService, T as getUsersOidcConfig, _ as readMobileBearerToken, a as TerminalAuthRateLimitError, g as MobileAuthService, h as MobileAuthError, i as TerminalAuthError, m as withSessionPermissionContext, o as TerminalAuthService, s as OperationPermissionError, v as validateMobileRedirectUri, w as encodeOidcTransaction, x as OidcLoginError, y as SessionService } from "./chunks/TerminalAuthService-Buu2oc6x.js";
 import { DiscoveryArtifactValidationError, SMRT_APP_RESULT_CONTRACT, SMRT_APP_RESULT_SCHEMA, SMRT_APP_RESULT_VERSION, SMRT_DISCOVERY_CONFORMANCE_ARTIFACT_SCHEMA, SMRT_DISCOVERY_CONFORMANCE_SCHEMA, SMRT_DISCOVERY_CONFORMANCE_VERSION, SMRT_MCP_RESULT_METADATA_KEY, canonicalizeDiscoveryArtifact, createDiscoveryConformanceArtifact, deriveCommandRequirements, validateDiscoveryConformanceArtifact } from "./app-contract.js";
 import { ObjectRegistry } from "@happyvertical/smrt-core";
 import { createLogger } from "@happyvertical/logger";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@happyvertical/smrt-users",
-  "version": "0.45.0",
+  "version": "0.45.2",
   "smrtJsdoc": "strict",
   "description": "Multi-tenant user management for the SMRT framework - users, tenants, roles, permissions, groups",
   "type": "module",
@@ -49,13 +49,13 @@
     "@happyvertical/logger": "^0.89.4",
     "@happyvertical/sql": "^0.89.4",
     "jose": "^6.2.3",
-    "@happyvertical/smrt-config": "0.45.0",
-    "@happyvertical/smrt-core": "0.45.0",
-    "@happyvertical/smrt-mobile-contract": "0.45.0",
-    "@happyvertical/smrt-profiles": "0.45.0",
-    "@happyvertical/smrt-types": "0.45.0",
-    "@happyvertical/smrt-tenancy": "0.45.0",
-    "@happyvertical/smrt-ui": "0.45.0"
+    "@happyvertical/smrt-config": "0.45.2",
+    "@happyvertical/smrt-core": "0.45.2",
+    "@happyvertical/smrt-profiles": "0.45.2",
+    "@happyvertical/smrt-tenancy": "0.45.2",
+    "@happyvertical/smrt-types": "0.45.2",
+    "@happyvertical/smrt-mobile-contract": "0.45.2",
+    "@happyvertical/smrt-ui": "0.45.2"
   },
   "devDependencies": {
     "@sveltejs/package": "^2.5.8",
@@ -67,7 +67,7 @@
     "typescript": "5.9.3",
     "vite": "8.1.4",
     "vitest": "4.1.10",
-    "@happyvertical/smrt-vitest": "0.45.0"
+    "@happyvertical/smrt-vitest": "0.45.2"
   },
   "keywords": [
     "smrt",