permdock 0.6.0 → 0.8.0

package/skills/permdock-credentials/references/tokens-keys-links.md

@@ -47,11 +47,13 @@ const decision = await decideCredential(
 );
 if (decision.outcome === "granted") {
   const key = generateApiKey(decision.credential.id);
-  await db.insert(apiKeys).values({
-    id: decision.credential.id,
-    hash: await hashApiKey(key),
-    credential: decision.credential,
-  });
+  await db
+    .insert(apiKeys)
+    .values({
+      id: decision.credential.id,
+      hash: await hashApiKey(key),
+      credential: decision.credential,
+    });
   return key; // shown once
 }
 ```
@@ -123,7 +125,7 @@ const subject = await subjectFromCapability(token, {
 - The result is a `kind: 'link'` principal with one `{ on, roles, via: 'link' }` membership. It never holds a scope or global role.
 - `linkPolicy` returns the tenant's `LinkPolicy` (`maxLifetime`, `redeemers`, `once`). Passing the same policy to `signCapability` refuses to mint a link the resolver would refuse.
 - Never an unguessable id without expiry, and never a security-definer RPC that reads the guest page's rows.
-- The one exception is resolving a stored link. When links live in better-supabase's share-links block, its `resolve_share_link` is `security definer` and reads only the link table. `subjectFromShareLink(token, { shareLinks, links, ttl })` from `permdock/better-supabase` turns the row into the same link subject. The page's rows are then read through `exchangeCapability` and RLS, as for a signed link. `links` maps each `subjectType` to a resource and maps the row's role to PermDock roles. An unmapped type or role, and a revoked or expired row, are anonymous. A link pinned to a version is refused, because a capability reads the current rows; read it through better-supabase's `versions.getShared(token)`. See [row-backed links](https://permdock.com/docs/concepts/capabilities#row-backed-links).
+- The one exception is resolving a stored link. When links live in better-supabase's share-links block, its `resolve_share_link` is `security definer` and reads only the link table. `subjectFromShareLink(token, { shareLinks, links, ttl })` from `permdock/better-supabase` turns the row into the same link subject. The page's rows are then read through `exchangeCapability` and RLS, as for a signed link. `links` maps each subject type (`subject.type` from better-supabase 0.14, `subjectType` before it) to a resource and maps the row's role to PermDock roles. An unmapped type or role, and a revoked or expired row, are anonymous. A link pinned to a version is refused, because a capability reads the current rows; read it through better-supabase's `versions.getShared(token)`. See [row-backed links](https://permdock.com/docs/concepts/capabilities#row-backed-links).
 
 With Supabase, let RLS serve the link through an exchange, never the link token itself:
 

package/skills/permdock-data/references/queries-and-rls.md

@@ -36,16 +36,20 @@ pnpm exec permdock rls verify --introspect
 ```
 
 - List the scope instances a permission reaches in process with `permdock.permittedIds(permission, scope, { within })`, never a loop of `can` over memberships with a made-up row.
-- Generated policies call `permdock_has('<key>')` and one `permitted_<scope>_ids('<key>')` per declared scope, which Postgres runs once per statement. Hand-written policies that only need membership (an organization switcher) call `member_<scope>_ids()` instead of inventing a permission key. Trusted SQL that acts for a stored user (a job, a trigger, a deferred approval) calls `permdock_has_for(p_user, '<key>')` and `permitted_<scope>_ids_for(p_user, '<key>')` in `database` mode, or the generated `permitted_<resource>_rows_for`, never a hand-written function that rewrites `request.jwt.claims`. With `rls.rowHelpers`, a hand-written policy or function that needs the rows a permission reaches through the graph calls `permitted_<resource>_rows('<permission key>')` instead of restating closure walks, link hops and `includes`. A table's own `select` or `insert` policy calls the row-valued `permitted_<resource>_row(<table>, '<permission key>')` instead, so `insert ... returning` sees the new row. Hand-written policies and functions that apply no row condition call `permitted_<scope>_ids_by_permission('<permission key>')` or `permdock_has_permission('<permission key>')` instead of spelling a positional `#n` grant key. A screen or RPC that checks many permissions on one organization calls `permitted_<scope>_permission_keys(<id>)` once (or `(<id>, array['<key>', ...])` for a few keys) instead of one helper call per key. A role editor or admin screen lists a role's keys with `permdock_role_permissions(p_role, p_scope, p_tenant, p_scope_id)` (declared roles, and custom roles of the caller's tenant in `database` mode) and the catalog with `permdock_permission_keys()` (`permdock_permission_keys('<scope>')` for the keys a role on that scope can hold), instead of joining `role_permissions` and the custom-role tables by hand; server code reads any tenant's roles with `permdock_trusted_role_permissions`, granted through `rls.trustedReaders`. Set `--tenant-type` (or `rls.tenantType`, `rls.scopeTypes`) to the scope columns' types.
+- Generated policies call `permdock_has('<key>')` and one `permitted_<scope>_ids('<key>')` per declared scope, which Postgres runs once per statement. Hand-written policies that only need membership (an organization switcher) call `member_<scope>_ids()` instead of inventing a permission key. A policy that passes a user id, such as better-supabase's team sharing, calls `member_team_ids_of(<user>)` on Supabase: it answers only when the id is the caller's. Trusted SQL that acts for a stored user (a job, a trigger, a deferred approval) calls `permdock_has_for(p_user, '<key>')` and `permitted_<scope>_ids_for(p_user, '<key>')` in `database` mode, or the generated `permitted_<resource>_rows_for`, never a hand-written function that rewrites `request.jwt.claims`. With `rls.rowHelpers`, a hand-written policy or function that needs the rows a permission reaches through the graph calls `permitted_<resource>_rows('<permission key>')` instead of restating closure walks, link hops and `includes`. A table's own `select` or `insert` policy calls the row-valued `permitted_<resource>_row(<table>, '<permission key>')` instead, so `insert ... returning` sees the new row. Hand-written policies and functions that apply no row condition call `permitted_<scope>_ids_by_permission('<permission key>')` or `permdock_has_permission('<permission key>')` instead of spelling a positional `#n` grant key. A screen or RPC that checks many permissions on one organization calls `permitted_<scope>_permission_keys(<id>)` once (or `(<id>, array['<key>', ...])` for a few keys) instead of one helper call per key. A role editor or admin screen lists a role's keys with `permdock_role_permissions(p_role, p_scope, p_tenant, p_scope_id)` (declared roles, and custom roles of the caller's tenant in `database` mode) and the catalog with `permdock_permission_keys()` (`permdock_permission_keys('<scope>')` for the keys a role on that scope can hold), instead of joining `role_permissions` and the custom-role tables by hand; server code reads any tenant's roles with `permdock_trusted_role_permissions`, granted through `rls.trustedReaders`. Set `--tenant-type` (or `rls.scopeTypes`, keyed by scope name or `tenant` and `team`) to the scope columns' types.
 - `--authorize database` (default) reads the membership tables per statement; map each under `rls.memberships.scopes.<scope>` with `columns` for its id and its ancestors', and `via` so roles with `for` apply: a column name, or `{ value: 'staff' }` when every row has that kind (never add a generated column for it). `--authorize jwt` reads token claims and stays stale until the token refreshes; keep the token lifetime at 3600 seconds or less (PD019).
+- When the role column holds values that are not role keys, give the membership source `role: { column, map: { value: 'role' } }`; a value mapped to `null` grants nothing. `permdock rls explain` prints the tables, membership sources, custom roles table and triggers a generate run binds to, without writing a file. `rls.seeds: 'function'` writes the `role_permissions` rows as `<schema>.seed()` instead of inserts; run `select <schema>.seed();` after each deploy, and PD054 checks the function body.
+- `rls verify --introspect` checks each `security definer` helper by its full signature, so every overload is checked on its own. A helper finding id names the signature (`helper-definer:permdock.permdock_has(text):helper`); write `rls.verify.ignore` entries with it.
+- `permdock rls verify --kind pgtap` writes `supabase/tests/permdock_rls.test.sql` (or `--out`) and, in `database` mode, inserts each fixture's memberships before it switches role.
 - The helpers narrow to the tenant claim (`rls.tenantClaim`) whenever the token carries one; the Supabase hook writes it from `activeFrom`. When the app takes the tenant from the URL and one session spans tenants, set `rls.tenants: 'all'` so the database admits every member tenant, and keep filtering each query by the URL's tenant.
 - `--policy-per-role` keeps one policy per role for review. `--custom-roles` (or `rls.customRoles: true`) resolves tenant-defined roles inside the `permdock_ceiling` view. In `database` mode, save a custom role with `permdock_replace_custom_role_grants(tenant, scope, scope_id, role, allow, deny, include)` and rename or delete it with `permdock_rename_custom_role_grants` and `permdock_delete_custom_role_grants`, never with hand-written `security definer` functions or direct writes; failures raise `22023` or `42501` with the reason as the `hint`. A platform custom role passes a null tenant and scope `global`; a shared custom role passes a null tenant and scope id at its scope. Seeds, jobs and backends with no member caller use the `permdock_trusted_*` variants, which keep the definition checks; grant `execute` on them to a backend role in a migration of your own, never to `authenticated`. Set `rls.customRoleWrites.requires` to the permission your role editor asserts (or `'manageRoles'`) so the database refuses members who may not manage roles (`manage-roles`).
 - `--force` (or `rls.force: true`) only when the app connects as the table owner. Create views over RLS tables `with (security_invoker = true)` (PD022).
-- When read grants set `fields` and clients read tables directly, add `--fields views --revoke-columns`: clients read `<table>_visible`, whose restricted columns are null unless a grant covers them. PD030 names columns still readable.
+- When read grants set `fields` and clients read tables directly, add `--fields views --revoke-columns`: clients read `<table>_visible`, whose restricted columns are null unless a grant covers them. PD030 names columns still readable. When a `security definer` RPC or other owner-rights SQL returns those rows, use `--fields mask` and select through `cross join lateral permdock.<table>_mask(t) m`, never a hand-written `case` per column.
 - `rls.suspension` drops suspended users' roles and memberships of suspended scope instances, live in both modes. `scopes.<scope>.keep: [permissions.org.restore]` lets members of a suspended instance still hold those permissions (restore, cancel deletion, export) in the helpers, `authorize()`, the token hook and in process, where the membership carries `keep`; `doctor` PD061 lists them.
 - When support or impersonation tokens (an `act` claim) reach the Data API, set `rls.readOnlyActors: true`: each table and write command the policies grant gets a restrictive `{table}_{op}_read_only_actors` policy that refuses the write unless `act.read_only` is `false`. Never hand-write that policy per table. With `--helpers-only`, every hand-written insert, update and delete policy calls `(select permdock.permdock_actor_may_write())`, and `rls verify --introspect` names the ones that do not.
 - To list who holds a permission in one organization (notification fan-out, an approver list), server SQL calls `permitted_<scope>_users('<permission key>', <id>)` in `database` mode, never a hand-written join of memberships and `role_permissions`. No client role may execute it; grant it to the backend's Postgres role.
 - When a backend queries Postgres for a verified API key, set `rls.apiKeys` and put the key in the `api_key` claim (`scopes` as permission keys, `tenant` and `roles` for a key that belongs to a tenant): the helpers cap every allow at the scopes and treat a tenant key without `sub` as a service principal of that tenant. A user key whose claim names a `tenant` is held to that tenant even with `rls.tenants: 'all'`, and `permdock_has` is false for it. Never write a `has_scope` check per policy.
+- When OAuth clients, MCP clients or agents (a `client_id` or an agent `act` claim) reach the Data API, set `rls.tokenScopes: true`: the helpers and helper-free allows then pass a grant only when the token's `scope` claim reaches its permission, through the same map better-supabase's `delegation.scopes` reads. A policy delegation does not compile into SQL, so such a client needs permission scopes or `oauthScopes` in its token. Never hand-write a scope check per policy.
 - On Supabase every generated helper and policy reads the subject through `permdock_user_id()`: the `sub` in `request.jwt.claims`, and null for the empty `sub` of a tenant service key. It ignores the legacy `request.jwt.claim.sub` setting; SQL that impersonates a user sets `request.jwt.claims`. A hand-written policy such a token reaches calls `(select permdock.permdock_user_id())`, never `auth.uid()`, which fails the uuid cast.
 - `rls.assignments` puts a `permdock_assignment` trigger on each mapped membership table, the global-roles table `rls.roles` and each table in `tables`; `ownRole: 'refuse'` (or a map of tables) also refuses a client write to the caller's own row. `doctor` PD064 names a guarded table no migration puts the trigger on.
 - SQL that assigns roles calls `permdock_can_assign_any(role, tenant, scope, scope_id)`, which covers declared and custom roles; SQL acting later for a stored user (an invitation accept re-checking the inviter) calls `permdock_can_assign_any_for(user, ...)`. `permdock supabase inspect` lists both in the manifest's `rls.helpers`.

package/skills/permdock-tenancy/SKILL.md

@@ -60,7 +60,7 @@ A policy declares its scopes in order (an organization, the customers inside it)
 3. **Load memberships.** Return memberships as `{ scope, id, within, roles, via, expiresAt }` from the subject resolver, or pass a `MembershipSource` (one, or an array) as `memberships` on `createPermDock`. A person's access ending is the membership's `expiresAt`.
    ✓ `permdock doctor` reports no PD025 for the `doctor.memberships` fixture.
 
-   An organisation role that reaches only the principal's teams is an organisation role with `where: { team_id: { in: principal.claims.team_ids } }`, not a team role. On Supabase, write the claim with `supabase.hook.claims` ([team reach](https://permdock.com/docs/concepts/tenancy#organisation-roles-with-team-reach)).
+   An organisation role that reaches only the principal's teams is an organisation role with `where: { team_id: { in: claim("team_ids") } }` (`claim` from `permdock` is `principal.claims.team_ids`, typed under `noUncheckedIndexedAccess`), not a team role. On Supabase, write the claim with `supabase.hook.claims` ([team reach](https://permdock.com/docs/concepts/tenancy#organisation-roles-with-team-reach)).
 
 4. **Put ownership on the roles.** Set `min: 1` on the role that manages each scope, `assigns` for who hands out what, `for: ['staff']` on admin-like roles, and `meta.audience` for the surface. Every server action that changes a membership calls `decideRoleChange(permdock, ...)` with the target's current membership and the holder count before it writes. -> [references/ownership-and-custom-roles.md](references/ownership-and-custom-roles.md)
    ✓ PD026 is clean, and removing the last owner is denied with `last-holder`.

package/skills/permdock-tenancy/references/ownership-and-custom-roles.md

@@ -79,7 +79,7 @@ type CustomRole = {
 
 - The ceiling of a scope is the code allows of the declared roles marked `assignable` in that scope. A custom role never exceeds it, and hosted grants never widen it.
 - An own allow inherits the conditions of the ceiling grants for that permission. To keep a narrower condition ("own posts only"), include the declared role that has it.
-- A resource may declare `levels: { own: { ownerId: principal.id }, team: { teamId: { in: principal.teamIds } }, all: {} }`. A grant `{ permission: 'job.read', level: 'team' }` ANDs that condition into the ceiling grant. An undeclared level, or a level on a collection action, is dropped as `unknown-level` and removes the permission; a level on a deny is `condition-not-allowed`. `permdock.assignableLevels(leaf)` lists the levels the subject may hand out.
+- A resource may declare `levels: { own: { ownerId: principal.id }, team: { teamId: { in: principal.teamIds } }, all: {} }`. A grant `{ permission: 'job.read', level: 'team' }` ANDs that condition into the ceiling grant. An undeclared level, or a level on a collection action, is dropped as `unknown-level` and removes the permission; a level on a deny is `condition-not-allowed`. `permdock.assignableLevels(leaf)` lists the levels the subject may hand out. Levels are unordered: holding `team` does not hand out `own`. Add `orderedLevels: true` to the resource when the levels nest from narrowest to widest in declaration order; a held level then also hands out every earlier one, and evaluation is unchanged.
 - An own deny removes the permission from this custom role only. Deny it in code when it must win across roles.
 - Pass a `CustomRoleSource` (`memoryCustomRoleSource(roles)` in tests), or a `CustomRoleSourceFactory` `(subject) => CustomRoleSource` when the source reads one principal's roles, as `customRoles` on `createPermDock` or any adapter. To add every role of a tenant on a role-management request, `await permdock.derive({ customRoles })` instead of building a second instance. Build it with `customRoleSource({ rolesFor })`, where `rolesFor(tenant)` reads every custom role of the tenant, not only the held ones: `assignableRoles` and `decideRoleChange` see only what the source returns. `{ read: 'held', policy }` skips the read on requests that never manage roles. Check it with `testCustomRoleSource(source, { every })`.
 - `permdock.assignableRoles({ tenant })` lists declared roles, then the tenant's custom roles whose every permission and level the subject may hand out at the custom role's scope. `decideRoleChange` assigns and revokes a custom role like a declared one, with no holder count; it inherits `for` and `exclusiveWith` from its included roles.
@@ -90,3 +90,4 @@ type CustomRole = {
 - A stored grant under a key renamed with `definePermissions(..., { renamed })` still resolves; `validateCustomRole` lists it in `renamed` as `{ from, to }`, and `permdock doctor` PD055 prints the `update` that rewrites it.
 - For generated RLS, add `--custom-roles` (or `rls.customRoles: true`) to `permdock rls generate`. Platform roles are rows with `scope = 'global'` and a null `tenant_id`, or the top-level `role_grants` claim in `jwt` mode. With levels, `custom_role_permissions` gains a `level` column and the claim writes `key@level`.
 - To adopt custom roles the app already stores in its own tables, set `rls.customRoles.from` and `rls.customRoleWrites.roles`, then run `permdock rls generate --backfill-out <migrations dir>/`. The migration saves each role through the trusted replace function, drops entries outside the ceiling with a warning, and skips roles that already have rows; never write the copy by hand ([backfill](https://permdock.com/docs/cli/rls#backfill-from-existing-tables)).
+- To keep the copy current instead of copying once, set `rls.customRoles.from.sync: 'trigger'`: after-row triggers on the app's permission and include tables rewrite the copy through the trusted replace function. Before-row triggers hold a signed-in write to the checks of `permdock_replace_custom_role_grants` against the copy as it stood before the statement, so a member who manages roles cannot add a permission they lack, even to a role they hold. A write path of your own calls the stable `permdock_custom_role_guard(p_tenant, p_scope, p_scope_id, p_role)` first, then `permdock_custom_role_beyond(p_tenant, p_scope, p_scope_id, p_allow, p_deny, p_include)` on the new entries only, from a `security definer` trigger that runs before the copy changes. The generated name guard on `rls.customRoleWrites.roles` refuses a tenant row named like a declared role (`declared-role`) or a shared role (`name-taken`). A stored entry is `<permission>[@<level>]`; check one with `parseCustomRoleEntry(policy, entry, { scope })` in process or `permdock_custom_role_entry_problem(p_scope, p_entry)` in SQL, which answer `unknown-permission`, `outside-ceiling` or `unknown-level`.

package/skills/permdock-wire/references/adapters.md

@@ -17,9 +17,7 @@ export const {
   requirePermission,
   PermDockProvider,
   permdockHandler,
-} = createPermDock(policy, {
-  subject: async () => getUser(),
-});
+} = createPermDock(policy, { subject: async () => getUser() });
 ```
 
 Needs Next.js 16.3 or later. Guard with `getPermission(permissions.post.update, post)` or `assert`. For a page or Server Action that must stop on a denial, `await requirePermission(permission, data, { tenant })` calls `forbidden()` (or `unauthorized()` for a signed-out user); enable `experimental.authInterrupts` and add `app/forbidden.tsx` and `app/unauthorized.tsx`. When only part of a page is gated, let a Server Component `assert` inside `<PermissionBoundary denied={...} approval={...}>` from `permdock/next/client` (with a `Suspense` inside it); `usePermissionBoundary()` in the fallback gives the permission, the approval `token` and `retry()`. Client components use `permdock/react` inside the server `PermDockProvider`, which never awaits: it streams a `snapshotPromise`, and permission hooks answer `pending` until it lands (add `suspend` to make them suspend).
@@ -104,9 +102,7 @@ import { createPermDock } from "permdock/authzen";
 
 export const { permdockHandler } = createPermDock(policy, {
   subject: fromBearer,
-  resources: {
-    post: { data: (id) => loadPost(id), list: () => listPosts() },
-  },
+  resources: { post: { data: (id) => loadPost(id), list: () => listPosts() } },
 });
 ```
 
@@ -137,7 +133,7 @@ import { PermDockProvider, usePermission } from "permdock/react-native";
 
 `subjectId` is required: the signed-in user's id, or `null` when signed out. A stored snapshot of another principal is cleared. `storage` is `{ getItem, setItem, removeItem }`; `secureStoreStorage(SecureStore)` and `mmkvStorage(mmkv)` wrap Expo SecureStore and MMKV. `snapshotUrl` revalidates in the background; `subscribeForeground={appStateForeground(AppState)}` revalidates on return to the foreground. For Expo Router guards use `usePermissionGuard(permission, data?)`, which is `false` while `pending`, and `useSnapshotReady()` for a splash screen. `permdock.clear()` drops the persisted snapshot on sign-out. Do not import `policy.ts` on the client.
 
-To answer guards from synced rows, write `localSnapshotManifest(policy)` (from `permdock`) to a JSON file at build time and pass `source={localSnapshot({ manifest, read, subscribe })}`. `read()` returns `{ principal: { id, tenant, roles, memberships, attributes }, customRoles }` from the local database; `subscribe` re-reads on row changes. It decides like the server snapshot except relation grantees (server-only) and the assignable lists (empty). Never import `policy.ts` into the app for this. Docs: [local snapshot](https://permdock.com/docs/adapters/react-native#local-snapshot).
+To answer guards from synced rows, write `localSnapshotManifest(policy)` (from `permdock`) to a JSON file at build time and pass `source={localSnapshot({ manifest, read, subscribe })}`. `read()` returns `{ principal: { id, tenant, roles, memberships, attributes }, customRoles }` from the local database; `subscribe` re-reads on row changes. It decides like the server snapshot except relation grantees (server-only). With a `tenant`, the assignable roles, permissions and levels match the server's for the same rows. Never import `policy.ts` into the app for this. Docs: [local snapshot](https://permdock.com/docs/adapters/react-native#local-snapshot).
 
 For an offline app on PowerSync, set `powersync: { out: 'sync-config.yaml' }` in `permdock.config.ts` and run `permdock powersync generate`: one edition 3 Sync Stream per resource, from the `rls.tables` and `rls.memberships` the RLS generator reads. It under-syncs, never over-syncs: a resource with a deny grant gets no stream, and a grant with a global role, approval, break-glass, validity, request context or a condition without a Sync Streams form syncs nothing, each with a warning. The app reads what does not sync from the server. It also writes `permdock_*` streams for the user's own membership, global-role and custom-role rows; with `powersync.manifest` set it writes the manifest too, and `powerSyncSource(db, { manifest, queries, read })` from `permdock/react-native` builds the local snapshot from `db.watch` queries. `permdock powersync verify` fails when a stream holds a fixture row the policy denies; doctor PD058 flags a stale file or manifest. Doctor PD065 lists server-only grants read from React Native code, which the device denies offline. Docs: [`permdock powersync`](https://permdock.com/docs/cli/powersync).
 
@@ -193,11 +189,13 @@ export const { middleware, protect } = createPermDock(policy, {
   subject: ({ store }) => store.user ?? null,
 });
 
-const app = new Elysia().use(middleware()).delete("/posts/:id", handler, {
-  beforeHandle: protect(permissions.post.delete, ({ params }) =>
-    loadPost(params.id),
-  ),
-});
+const app = new Elysia()
+  .use(middleware())
+  .delete("/posts/:id", handler, {
+    beforeHandle: protect(permissions.post.delete, ({ params }) =>
+      loadPost(params.id),
+    ),
+  });
 ```
 
 Fetch-native plugin via `derive`. Denials are `403 application/problem+json`; anonymous callers get `401` plus `WWW-Authenticate`. For `.ws` routes, `connection(ws, { permission })` in `open` returns the socket's connection (memoised); it closes the socket with `1008` when revoked.
@@ -278,9 +276,7 @@ import { createPermDock } from "permdock/node";
 
 export const { getPermDock, protect, send, permdockHandler } = createPermDock(
   policy,
-  {
-    subject: (req) => userFromCookie(req.headers.cookie),
-  },
+  { subject: (req) => userFromCookie(req.headers.cookie) },
 );
 ```
 
@@ -360,9 +356,7 @@ import { PermDockProvider, Protected, usePermission } from 'permdock/solid';
 ```ts
 import { instrument } from "permdock/otel";
 
-instrument(permdock, {
-  logger: { info: console.info, warn: console.warn },
-});
+instrument(permdock, { logger: { info: console.info, warn: console.warn } });
 ```
 
 HTTP adapters accept the same options as `otel`. `@opentelemetry/api` is optional; without it the adapter writes only through `logger`.
@@ -397,6 +391,20 @@ export const scim = scimHandler({
 
 The handler writes users and groups. It never decides. Unknown or non-assignable role names are stored and dropped when memberships are read. Pass the app's `revocations` feed so a deprovisioned member's open streams revalidate and close.
 
+In production, keep the directory in Postgres: `permdock scim generate` writes the tenant-keyed tables (`supabase/schemas/permdock/scim.sql` by default; `--dialect`, `--schema`), and `postgresDirectoryStore(query)` reads and writes them through the same `SqlQuery` function `tableMembershipSource` takes:
+
+```ts
+import { postgresDirectoryStore } from "permdock/scim";
+import pg from "pg";
+
+const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
+const directory = postgresDirectoryStore((text, values) =>
+  pool.query(text, [...values]),
+);
+```
+
+Read memberships through `directoryMembershipSource(directory)`, never through a `tableMembershipSource` over the SCIM tables: the source applies the `externalId` / `userName` match, drops inactive users and enforces `assignable`. The tables are revoked from `anon` and `authenticated`; the store's connection must own them or be granted on them, never `service_role` in generated SQL.
+
 ## Cloud — `permdock/cloud`
 
 No factory for a `PermDock`. `cloud({ url, key, environment })` returns `approvals`, `sink` and `policies` to pass into any adapter, `snapshotsFor(token)` (a `SnapshotSource` for the subject an `at+jwt` proves, sent as `PermDock-Subject`), `catalog.push`, plus the environment `issuer` (`<url>/v1/environments/<environment>`) and its `jwks` URL; `cloudEndpoints({ url, environment })` computes the same two without a key. It never implements `MembershipSource` or `CustomRoleSource` and never decides.
@@ -493,7 +501,7 @@ const subject = subjectFromSupabase(claims, {
 
 Write the claims with `permdock supabase hook generate`; `permdock supabase inspect --out` writes the manifest (helper names, tenant claim, budget, claims written) that `authorizationProvider` from `permdock/better-supabase` turns into better-supabase's `authorization` config. No `@supabase/supabase-js` peer. Pair with `permdock rls generate`, or keep SQL as authority and run `permdock rls verify --db-url-stdin` against `sqlFunction` twins ([database-first](https://permdock.com/docs/adapters/rls)); the generic RLS workflow is in the `permdock-data` skill.
 
-With better-supabase, set `authorization: authorizationProvider({ manifest, catalog })` in `better-supabase.config.ts` (with `rls.customRoles` its `canAssign` and `canAssignFor` call `permdock_can_assign_any` and its `_for` form, so custom roles are assignable through better-supabase; regenerate the manifest after turning custom roles on), pass `authorizer({ policy })` to the server (`createNext`, `createHono`, `createMcp`) so every `permission` a resource, action, route guard or tool declares is decided by PermDock from the verified claims (`operations` maps tables for `permissions: true`; a missing or anonymous claim denies), build bucket and topic `access` policies with `bucketPolicy` and `topicPolicy`, and map its session with `subjectFromBetterSupabase(session)` (all from `permdock/better-supabase`): the active tenant's `features` become `principal.plans`. Pass `plans: { keys }` when better-supabase's `entitlements.claim.keys` shortens feature keys, and `apiKeys: { permissions, manifest }` so an `apiKey` session maps to the key's credential subject instead of the anonymous one. For `createMcp` tools, put the permission in `meta` and spread `toolPolicy({ permdock })` into the options: tools without one are hidden and refused, and approval-required calls are refused because `createMcp` collects no approvals. Wrap a `CredentialProvider` with `credentialGuard(provider, { permdock, use, revoke? })` so PermDock decides each token use. `authorizationProvider({ ..., approver })` lets holders of that permission approve AI tool calls, never their own. `approvers: { 'ai-tool': holder(p), 'support-session': ..., 'invoice.send': ... }` fills `isApprover` through `permdock_is_approver` (needs `rls.approvals`); only `user()`, `holder()` and `anyOf()` approvers, and a kind it does not name has no approver. `accessReviewApplier({ client, reviews, policy, demoteTo?, email?, permdockFor? })` applies a review's revoked items: `update_member_role` to the `demoteTo` role when that role lacks the permission, else `remove_member`, plus `revoke_invitation` for the member's matching invitations, then `markApplied`; pass the reviewer's client so the blocks' own checks run. better-supabase's `createAgentRuntime({ toolApproval })` takes `toolApproval` from `permdock/ai-sdk` as it is. Validate its claims with `betterSupabase.claims(supabaseClaims().extend(appSchema))` (`supabaseClaims` from `permdock/supabase`, any Standard Schema as `appSchema`) instead of a hand-written copy of the claim shape. A `supabase.hook.claims` function that needs the user's organizations calls `<schema>.member_organization_ids_for(user_id)` (generated by `rls generate`, executable by `supabase_auth_admin` only) instead of querying the membership tables itself. A token Supabase's OAuth server issued to a third-party app (`client_id`) becomes an `oauth-client` actor limited to its `scope`; `deny(permission, { to: actor('oauth-client') })` keeps such apps out, in the app and, through `rls generate`, in Postgres. A better-supabase support session (`act.kind: 'support'`) is actor kind `support` with `sessionId` and `readOnly`, and `actingAs` (`act.kind: 'impersonation'`) is kind `impersonation`; neither has a delegation, so they reach nothing until a policy delegation names `actor('support')` or `actor('impersonation')`, and `readOnly: true` (also when `read_only` is absent) narrows that to read-only permissions. Generated RLS reads memberships, not `act`, so a support token sent to the Data API writes as the user: add a restrictive `for update` (and `insert` / `delete`) policy per writable table that requires `act ->> 'read_only' = 'false'` when `act` is a support or session level ([support access](https://permdock.com/docs/guides/support-access)). With `rls.anonymousSignIns: 'deny'`, pass `anonymousSignIns: 'deny'` to the subject mapper too (doctor PD057). Check a deployed database against the generated policies with `permdock rls verify --introspect`.
+With better-supabase, set `authorization: authorizationProvider({ manifest, catalog })` in `better-supabase.config.ts` (with `rls.customRoles` its `canAssign` and `canAssignFor` call `permdock_can_assign_any` and its `_for` form, so custom roles are assignable through better-supabase; regenerate the manifest after turning custom roles on), pass `authorizer({ policy })` to the server (`createNext`, `createHono`, `createMcp`) so every `permission` a resource, action, route guard or tool declares is decided by PermDock from the verified claims (`operations` maps tables for `permissions: true`; a missing or anonymous claim denies), build bucket and topic `access` policies with `bucketPolicy` and `topicPolicy`, and map its session with `subjectFromBetterSupabase(session)` (all from `permdock/better-supabase`): the active tenant's `features` become `principal.plans`. Pass `plans: { keys }` when better-supabase's `entitlements.claim.keys` shortens feature keys, and `apiKeys: { permissions, manifest }` so an `apiKey` session maps to the key's credential subject instead of the anonymous one. For `createMcp` tools, put the permission in `meta` and spread `toolPolicy({ permdock })` into the options: tools without one are hidden and refused, and approval-required calls are refused because `createMcp` collects no approvals. Wrap a `CredentialProvider` with `credentialGuard(provider, { permdock, use, revoke? })` so PermDock decides each token use. `authorizationProvider({ ..., approver })` lets holders of that permission approve AI tool calls, never their own. `approvers: { 'ai-tool': holder(p), 'support-session': ..., 'invoice.send': ... }` fills `isApprover` through `permdock_is_approver` (needs `rls.approvals`); only `user()`, `holder()` and `anyOf()` approvers, and a kind it does not name has no approver. `accessReviewApplier({ client, reviews, policy, demoteTo?, email?, permdockFor? })` applies a review's revoked items: `update_member_role` to the `demoteTo` role when that role lacks the permission, else `remove_member`, plus `revoke_invitation` for the member's matching invitations, then `markApplied`; pass the reviewer's client so the blocks' own checks run. better-supabase's `createAgentRuntime({ toolApproval })` takes `toolApproval` from `permdock/ai-sdk` as it is. Validate its claims with `betterSupabase.claims(supabaseClaims().extend(appSchema))` (`supabaseClaims` from `permdock/supabase`, any Standard Schema as `appSchema`) instead of a hand-written copy of the claim shape. A `supabase.hook.claims` function that needs the user's organizations calls `<schema>.member_organization_ids_for(user_id)` (generated by `rls generate`, executable by `supabase_auth_admin` only) instead of querying the membership tables itself. With a scope named `team` or `teams`, `authorizationProvider` fills better-supabase's `teamIdsOf` with `<schema>.member_team_ids_of(user)`, which answers only for the caller, so with `blocks.access.model: 'provider'` better-supabase's `team_ids_of()` and team-sharing policies read PermDock's memberships. A token Supabase's OAuth server issued to a third-party app (`client_id`) becomes an `oauth-client` actor limited to its `scope`; `deny(permission, { to: actor('oauth-client') })` keeps such apps out, in the app and, through `rls generate`, in Postgres. A better-supabase support session (`act.kind: 'support'`) is actor kind `support` with `sessionId` and `readOnly`, and `actingAs` (`act.kind: 'impersonation'`) is kind `impersonation`; neither has a delegation, so they reach nothing until a policy delegation names `actor('support')` or `actor('impersonation')`, and `readOnly: true` (also when `read_only` is absent) narrows that to read-only permissions. Generated RLS reads memberships, not `act`, so a support token sent to the Data API writes as the user: add a restrictive `for update` (and `insert` / `delete`) policy per writable table that requires `act ->> 'read_only' = 'false'` when `act` is a support or session level ([support access](https://permdock.com/docs/guides/support-access)). With `rls.anonymousSignIns: 'deny'`, pass `anonymousSignIns: 'deny'` to the subject mapper too (doctor PD057). Check a deployed database against the generated policies with `permdock rls verify --introspect`.
 
 The other better-supabase slots, all from `permdock/better-supabase` ([better-supabase](https://permdock.com/docs/adapters/better-supabase)): `hookCan(permdock)` and `handlerCan({ getPermDock })` are the `can` options of `authorizeHook` and `protectWebHandler` in `better-supabase/workflow-sdk`; they decide with no row, so a permission with a row condition denies there and is checked inside the handler, and `handlerCan` answers `undefined` (401) without a signed-in principal. `supportPolicy({ policy, options?, writable?, approval?, approved? })` is the `authorize` option of `supportSessions`; it decides each start with `decideSupportSession` as the admin, and an `approval-required` start passes only once `approved(input, pending)` returns `{ approvedBy }` for an approver other than the admin. `subscriberPolicy({ policy, principals, events, row?, sender? })` filters outbox, webhook or realtime subscribers to those who may read the event (exact type, then the longest `prefix.*`, then `*`; a type with no entry reaches no one). `principalSource({ claims, identities? })` is a `PrincipalSource` over the claims better-supabase mints, for `decideFor`, `subscribersFor` and delivery; only links the app created through a signed-in flow or a verified address go in `identities`. `authorizationHooks({ policy, claims, service?, principals?, events?, approvers?, support?, tickets? })` is the `authorization` option of `createServer`: it answers automation publish and run-as, delegated OAuth scopes, `approverOf`, identities, delivery audiences, support sessions and run tickets from the claims better-supabase mints now, never from the request.
 
@@ -526,9 +534,7 @@ import { createPermDock } from "permdock/supabase/middleware";
 const { withPermDock, permdockHandler } = createPermDock(policy, {
   subject: (ctx) =>
     subjectFromSupabase(ctx.jwtClaims, {
-      claims: {
-        roles: "user_role",
-      },
+      claims: { roles: "user_role" },
       declared: ["member", "admin"],
     }),
 });

package/skills/permdock-wire/references/policy-options.md

@@ -36,6 +36,7 @@ Adopting PermDock in an app with its own keys, SQL helpers and tokens is a step-
 - Put application-owned metadata in `meta.x`; PermDock carries it and never reads it (see App data below).
 - Rename a key later with `definePermissions(tree, { renamed: { "old.key": "new.key" } })`. Remove the alias only when `permdock doctor` PD055 and PD056 are quiet; `permdock diff` reports the removal as the breaking `alias-removed`.
 - Generate helpers beside legacy SQL with `permdock rls generate --helpers-only --shims`, then rewrite policies with `permdock rls migrate`.
+- `permdock rls migrate` and `rls import` need `pgsql-parser` 18 or later; the CLI names the installed version when it is older. A hook that should carry team ids sets `supabase.hook.teams: { table, user, team, tenant? }` and writes the `team_ids` claim within the same size budget as `memberships`.
 
 ## App data and app obligations
 

package/dist/catalog-BoWglDPI.js

@@ -1 +0,0 @@
-export { t as catalogFile, n as runCatalog } from "./catalog-HD2gf5mY.js";

package/dist/collect-D7eQDffE.js

@@ -1 +0,0 @@
-export { r as runCollect } from "./collect-mLTY4nwb.js";

package/dist/config-bs_kZeYq.js

@@ -1,162 +0,0 @@
-import { r as isRecord } from "./compact-CAf557ZB.js";
-import { n as CliError } from "./errors-CWTY6uih.js";
-import { existsSync } from "node:fs";
-import { relative, resolve } from "node:path";
-//#region src/cli/project/config-schema.ts
-const SECTIONS = {
-	collect: {
-		srcPath: true,
-		out: true,
-		barrel: true
-	},
-	catalog: { out: true },
-	openapi: { doc: true },
-	rls: {
-		tables: true,
-		dialect: true,
-		memberships: true,
-		membershipSources: true,
-		suspension: true,
-		functions: true,
-		inlineFunctions: true,
-		force: true,
-		fixtures: true,
-		tenantClaim: true,
-		tenantType: true,
-		teamType: true,
-		scopeTypes: true,
-		roleClaim: true,
-		roleValues: true,
-		gucPrefix: true,
-		out: true,
-		drizzle: true,
-		prisma: true,
-		schema: true,
-		authorize: true,
-		policyPerRole: true,
-		customRoles: true,
-		triggers: true,
-		audit: true,
-		capabilities: true,
-		anonymousSignIns: true,
-		fields: true,
-		revokeColumns: true,
-		policyName: true,
-		rbac: true,
-		roles: true,
-		actions: true,
-		helpersOnly: true,
-		rowHelpers: true,
-		treeValues: true,
-		trustedReaders: true,
-		migrate: true,
-		shims: true,
-		tenants: true,
-		customRoleWrites: true,
-		anonExecute: true,
-		assignments: true,
-		approvals: true,
-		jsonSchema: true,
-		ownershipTriggers: true,
-		readOnlyActors: true,
-		apiKeys: true,
-		realtime: true,
-		storage: true
-	},
-	supabase: {
-		hook: true,
-		schemas: true
-	},
-	powersync: {
-		out: true,
-		resources: true,
-		action: true,
-		manifest: true
-	},
-	doctor: {
-		sensitiveActions: true,
-		memberships: true,
-		credentials: true,
-		clientEntries: true,
-		migrations: true,
-		claims: true,
-		srcPath: true
-	}
-};
-const TOP_LEVEL = /* @__PURE__ */ new Set([
-	"permissions",
-	"policy",
-	"operations",
-	...Object.keys(SECTIONS)
-]);
-function isSection(key) {
-	return Object.hasOwn(SECTIONS, key);
-}
-/**
-* Checks the shape a command relies on before it reads the config: module
-* paths are strings and each section is an object. A key PermDock does not
-* read is a warning, so a config written for a newer version still loads.
-*/
-function parseConfig(value, file) {
-	if (value === void 0) return {
-		config: {},
-		warnings: []
-	};
-	if (!isRecord(value)) throw new CliError("usage", `PermDock CLI: ${file} must export a config object as default (use defineConfig)`);
-	const warnings = [];
-	const unknown = (path, known) => `${file}: unknown key ${path}; PermDock reads ${[...known].join(", ")}`;
-	for (const [key, entry] of Object.entries(value)) {
-		if (key === "permissions" || key === "policy" || key === "operations") {
-			if (entry !== void 0 && typeof entry !== "string") throw new CliError("usage", `PermDock CLI: ${file}: ${key} must be a module path string`);
-			continue;
-		}
-		if (!isSection(key)) {
-			warnings.push(unknown(key, TOP_LEVEL));
-			continue;
-		}
-		if (entry === void 0) continue;
-		if (!isRecord(entry)) throw new CliError("usage", `PermDock CLI: ${file}: ${key} must be an object`);
-		const known = SECTIONS[key];
-		for (const child of Object.keys(entry)) if (!Object.hasOwn(known, child)) warnings.push(unknown(`${key}.${child}`, Object.keys(known)));
-	}
-	return {
-		config: value,
-		warnings
-	};
-}
-//#endregion
-//#region src/cli/project/config.ts
-const CONFIG_FILES = [
-	"permdock.config.ts",
-	"permdock.config.mts",
-	"permdock.config.js",
-	"permdock.config.mjs"
-];
-function defineConfig(config) {
-	return config;
-}
-function isConfigFile(name) {
-	return CONFIG_FILES.some((file) => file === name);
-}
-async function readConfig(cwd, fromFlag, options) {
-	const path = fromFlag ? resolve(cwd, fromFlag) : CONFIG_FILES.map((name) => resolve(cwd, name)).find((file) => existsSync(file));
-	if (path === void 0) return {
-		config: {},
-		warnings: [],
-		file: void 0
-	};
-	if (!existsSync(path)) throw new CliError("usage", `PermDock CLI: config file not found: ${path}`, { code: "config_not_found" });
-	const { loadModule, pickNamed } = await import("./load-BxEtwlBS.js");
-	return {
-		...parseConfig(pickNamed(await loadModule(path, options), ["default"]), relative(cwd, path).replaceAll("\\", "/")),
-		file: path
-	};
-}
-async function loadConfig(cwd, fromFlag, options) {
-	return (await readConfig(cwd, fromFlag, options)).config;
-}
-function resolveCwd(cwd, fallback) {
-	return cwd === void 0 ? fallback : resolve(fallback, cwd);
-}
-//#endregion
-export { resolveCwd as a, readConfig as i, isConfigFile as n, loadConfig as r, defineConfig as t };

package/dist/denied-text-CiFQNuMV.d.ts

@@ -1,19 +0,0 @@
-import { Nn as Decision } from "./policy-types-n0uRTsW8.js";
-import { w as Permission } from "./vocabulary-CN8H_9UF.js";
-//#region src/agent/denied-text.d.ts
-/** What an agent adapter's `deniedText` receives: the refusal and the text PermDock wrote for it. */
-type DeniedTextEvent = {
-  readonly decision: Exclude<Decision, {
-    readonly outcome: "granted";
-  }> | null;
-  readonly permission: Permission | undefined;
-  readonly text: string;
-};
-/**
- * Replaces the human-readable text of a refusal, and nothing else: the
- * outcome, `isError`, the structured content and the approval token stay.
- * `undefined` keeps PermDock's text.
- */
-type DeniedText = (event: DeniedTextEvent) => string | undefined;
-//#endregion
-export { DeniedTextEvent as n, DeniedText as t };

package/dist/fields-OYG_JR78.js

@@ -1,203 +0,0 @@
-import { i as configError } from "./errors-CWTY6uih.js";
-import { s as jsonSchemaOf } from "./catalog-doc-Cdn7-0pQ.js";
-import { F as quoteQualified, N as quoteIdent, P as quoteLiteral, j as helperSchema, s as signedIn } from "./shared-BAK8t4Uo.js";
-import { c as branchClauses, i as orSql, s as andSql, u as wrapSql } from "./policies-DP2nqRoF.js";
-//#region src/cli/rls/fields.ts
-/** Names of the field-view objects. Part of the SQL contract. */
-const FIELD_VIEWS = {
-	/** `<table>_visible`: the `security_invoker` view clients read. */
-	view: "_visible",
-	/** `<table>_visible_fields`: the owner-rights companion `--revoke-columns` adds. */
-	companion: "_visible_fields",
-	/** The companion's row-key column, joined to the base table's key. */
-	key: "permdock_key",
-	/** Marks the companion so doctor PD022 knows it reads as its owner on purpose. */
-	comment: "permdock:field-companion"
-};
-function covers(branch, column) {
-	return branch.fields === void 0 || branch.fields.includes(column);
-}
-/**
-* A read grant that only shapes columns: a field-limited deny (it never
-* denies the row) or an allow with an empty list (it grants nothing). With
-* field views it leaves the row policy and lives in the view's masks.
-*/
-function fieldOnly(branch) {
-	if (branch.command !== "select" || branch.fields === void 0) return false;
-	return branch.effect === "deny" || branch.fields.length === 0;
-}
-/** Branches the row policies keep when field views compile. */
-function rowBranches(branches) {
-	return branches.filter((branch) => !fieldOnly(branch));
-}
-/**
-* Whether the reader is signed in, for branches with no helper call: a grant
-* to any signed-in user relies on `to authenticated` in its policy, which a
-* view does not have.
-*/
-function audience(ctx, branch) {
-	if (branch.access !== void 0 || branch.roles.length !== 1) return;
-	if (branch.roles[0] === "authenticated") return signedIn(ctx);
-	return branch.roles[0] === "anon" ? `not (${signedIn(ctx)})` : void 0;
-}
-function clause(ctx, branch) {
-	return andSql(audience(ctx, branch), branchClauses(branch).using) ?? "true";
-}
-/**
-* `can(permission, row, { field })` in SQL: an allow that covers the column
-* holds for the row and no covering deny does. Every access term is the
-* uncorrelated helper call the row policy uses, so it runs once per statement.
-*/
-function maskSql(ctx, allows, denies, column) {
-	const allowed = allows.filter((branch) => covers(branch, column)).map((branch) => clause(ctx, branch));
-	if (allowed.length === 0) return "false";
-	const denied = denies.filter((branch) => covers(branch, column)).map((branch) => clause(ctx, branch));
-	const allow = orSql(allowed);
-	if (denied.length === 0) return allow;
-	const deny = orSql(denied);
-	return allow === "true" ? `not ${wrapSql(deny)}` : `${wrapSql(allow)} and not ${wrapSql(deny)}`;
-}
-function schemaColumns(policy, resource) {
-	const node = policy.resources.get(resource);
-	const schema = node === void 0 ? null : jsonSchemaOf(node);
-	const properties = schema !== null && typeof schema === "object" ? schema.properties : void 0;
-	return properties !== null && typeof properties === "object" ? Object.keys(properties) : void 0;
-}
-function viewName(table, suffix) {
-	return `${table}${suffix}`;
-}
-/**
-* `<helper schema>.<table>_visible_fields`: outside the Data API's schemas,
-* so its owner rights reach clients only through the `_visible` join.
-*/
-function companionName(ctx, table) {
-	const base = table.startsWith("public.") ? table.slice(7) : table.replaceAll(".", "_");
-	return `${helperSchema(ctx)}.${viewName(base, FIELD_VIEWS.companion)}`;
-}
-/**
-* One view per table whose read grants limit fields. A column is restricted
-* when some read allow lists fields without it or some read deny lists it;
-* every other column, and the row key, passes through unchanged.
-*/
-function fieldViews(policy, ctx, branches, options, warnings) {
-	const byTable = /* @__PURE__ */ new Map();
-	for (const branch of branches) {
-		if (branch.command !== "select" || branch.coverage === true) continue;
-		byTable.set(branch.table, [...byTable.get(branch.table) ?? [], branch]);
-	}
-	const views = [];
-	for (const [table, reads] of byTable) {
-		const allows = reads.filter((branch) => branch.effect === "allow" && branch.fields?.length !== 0);
-		const denies = reads.filter((branch) => branch.effect === "deny");
-		const limited = reads.some((branch) => branch.fields !== void 0);
-		const resource = reads.find((branch) => branch.resource !== void 0)?.resource;
-		if (!limited || allows.length === 0 || resource === void 0) continue;
-		const names = schemaColumns(policy, resource);
-		if (names === void 0) throw configError(`PermDock CLI: --fields views needs the ${resource} schema's JSON Schema (Standard JSON Schema) to list the columns of ${table}`);
-		const key = policy.resources.get(resource)?.id ?? "id";
-		const restricted = (column) => column !== key && (allows.some((branch) => branch.fields !== void 0 && !branch.fields.includes(column)) || denies.some((branch) => branch.fields?.includes(column) === true));
-		const columns = names.map((name) => {
-			quoteIdent(name);
-			return restricted(name) ? {
-				name,
-				mask: maskSql(ctx, allows, denies, name)
-			} : { name };
-		});
-		if (columns.every((column) => column.mask === void 0)) continue;
-		const view = viewName(table, FIELD_VIEWS.view);
-		if (allows.some((branch) => branch.fields !== void 0 && !branch.fields.includes(key))) warnings.push(`field view ${view}: the key ${key} passes through, although a read grant on ${resource} omits it`);
-		const hidden = columns.filter((column) => column.mask !== void 0).map((column) => column.name);
-		if (options.helpersOnly === true) warnings.push(`field view ${view}: ${table} still returns ${hidden.join(", ")} to direct reads; revoke select on those columns from client roles in your own grants, or read them through a function`);
-		else if (!options.revokeColumns) warnings.push(`field view ${view}: ${table} still returns ${hidden.join(", ")} to direct reads; add --revoke-columns so clients read through the view`);
-		views.push({
-			resource,
-			table,
-			view,
-			key,
-			columns,
-			roles: reads.some((branch) => branch.roles.includes("anon")) ? ["anon", "authenticated"] : ["authenticated"],
-			...options.revokeColumns ? { companion: companionName(ctx, table) } : {}
-		});
-	}
-	return views;
-}
-/** Columns of `view`'s table that `anon` and `authenticated` keep on the base table with `--revoke-columns`. */
-function readableColumns(view) {
-	return view.columns.filter((column) => column.mask === void 0).map((column) => column.name);
-}
-function restrictedColumns(view) {
-	return view.columns.filter((column) => column.mask !== void 0).map((column) => column.name);
-}
-function columnList(names) {
-	return names.map(quoteIdent).join(", ");
-}
-function selectList(lines) {
-	return lines.map((line) => `  ${line}`).join(",\n");
-}
-function grantView(name, roles) {
-	return [`revoke all on table ${quoteQualified(name)} from anon, authenticated, public;`, `grant select on table ${quoteQualified(name)} to ${roles.join(", ")};`].join("\n");
-}
-function inlineViewSql(view) {
-	const targets = view.columns.map((column) => column.mask === void 0 ? quoteIdent(column.name) : `case when ${column.mask} then ${quoteIdent(column.name)} end as ${quoteIdent(column.name)}`);
-	return `create or replace view ${quoteQualified(view.view)} with (security_invoker = true) as
-select
-${selectList(targets)}
-from ${quoteQualified(view.table)};`;
-}
-function companionSql(view, companion) {
-	const restricted = view.columns.filter((column) => column.mask !== void 0);
-	const targets = [`${quoteIdent(view.key)} as ${quoteIdent(FIELD_VIEWS.key)}`, ...restricted.map((column) => `case when ${column.mask} then ${quoteIdent(column.name)} end as ${quoteIdent(column.name)}`)];
-	const any = orSql(restricted.map((column) => column.mask ?? "false"));
-	const name = companion.slice(0, companion.indexOf("."));
-	const schema = quoteIdent(name);
-	return `${name === "public" ? "" : `create schema if not exists ${schema};
-revoke all on schema ${schema} from public;
-grant usage on schema ${schema} to ${view.roles.join(", ")};
-`}create or replace view ${quoteQualified(companion)} with (security_barrier = true) as
-select
-${selectList(targets)}
-from ${quoteQualified(view.table)}
-where ${any};
-comment on view ${quoteQualified(companion)} is ${quoteLiteral(`${FIELD_VIEWS.comment} ${view.view}`)};`;
-}
-function joinedViewSql(view, companion) {
-	const targets = view.columns.map((column) => column.mask === void 0 ? `t.${quoteIdent(column.name)}` : `f.${quoteIdent(column.name)}`);
-	return `create or replace view ${quoteQualified(view.view)} with (security_invoker = true) as
-select
-${selectList(targets)}
-from ${quoteQualified(view.table)} t
-left join ${quoteQualified(companion)} f on f.${quoteIdent(FIELD_VIEWS.key)} = t.${quoteIdent(view.key)};`;
-}
-/** `select` on only the unrestricted columns (and the key) of the base table, for `--revoke-columns`. */
-function columnGrantSql(view, role) {
-	return `grant select (${columnList(readableColumns(view))}) on table ${quoteQualified(view.table)} to ${role};`;
-}
-function columnRevokeSql(view) {
-	return `revoke select (${columnList(restrictedColumns(view))}) on table ${quoteQualified(view.table)} from anon, authenticated;`;
-}
-/**
-* The view SQL: the `security_invoker` view, and with `--revoke-columns` the
-* owner-rights companion it joins for the restricted columns. The companion
-* masks every column with the full field decision and keeps only rows where
-* one is readable, so reading it directly shows nothing `pick` would not.
-*/
-function fieldViewsSql(views) {
-	return views.map((view) => {
-		const head = `-- field view over ${view.table}: ${restrictedColumns(view).join(", ")} read as null unless a read grant covers the column for the row`;
-		if (view.companion === void 0) return [
-			head,
-			inlineViewSql(view),
-			grantView(view.view, view.roles)
-		].join("\n");
-		return [
-			head,
-			`-- ${view.companion} reads ${view.table} as its owner; ${view.view} reads the rows as the caller and joins it`,
-			companionSql(view, view.companion),
-			grantView(view.companion, view.roles),
-			joinedViewSql(view, view.companion),
-			grantView(view.view, view.roles)
-		].join("\n");
-	}).join("\n\n");
-}
-//#endregion
-export { fieldViewsSql as a, fieldViews as i, columnGrantSql as n, rowBranches as o, columnRevokeSql as r, viewName as s, FIELD_VIEWS as t };