permdock 0.8.0 → 0.9.0

package/dist/workflow/index.d.ts

@@ -1,5 +1,5 @@
-import { a as AutomationSource, i as AutomationRequest, l as memoryAutomationSource, n as AutomationDecision, r as AutomationMode, s as MemoryAutomationSource, t as Automation, u as parseAutomation } from "../automation-DqEoWHBc.js";
-import { i as pollingApprovalWaiter, n as ApprovalWaiter, r as PollingApprovalWaiterOptions, t as ApprovalWaitOptions } from "../waiter-Bu9zAlE0.js";
-import { a as WorkflowPermDockOptions, i as WorkflowPermDock, n as AwaitApprovalOptions, o as createPermDock, r as StartAutomationResult, t as AutomationOptions } from "../create-CM1FciYG.js";
+import { a as AutomationSource, i as AutomationRequest, l as memoryAutomationSource, n as AutomationDecision, r as AutomationMode, s as MemoryAutomationSource, t as Automation, u as parseAutomation } from "../automation-C6Jg75xq.js";
+import { i as pollingApprovalWaiter, n as ApprovalWaiter, r as PollingApprovalWaiterOptions, t as ApprovalWaitOptions } from "../waiter-CqUKX6CY.js";
+import { a as WorkflowPermDockOptions, i as WorkflowPermDock, n as AwaitApprovalOptions, o as createPermDock, r as StartAutomationResult, t as AutomationOptions } from "../create-BamXmeob.js";
 import "../index-CaxrMD1A.js";
 export { type ApprovalWaitOptions, type ApprovalWaiter, type Automation, type AutomationDecision, type AutomationMode, type AutomationOptions, type AutomationRequest, type AutomationSource, type AwaitApprovalOptions, type MemoryAutomationSource, type PollingApprovalWaiterOptions, type StartAutomationResult, type WorkflowPermDock, type WorkflowPermDockOptions, createPermDock, memoryAutomationSource, parseAutomation, pollingApprovalWaiter };

package/dist/workflow/index.js

@@ -3,7 +3,7 @@ import { n as freezeDeep } from "../freeze-jjan0lCv.js";
 import { n as findPermission } from "../permission-registry-B8tYxPIt.js";
 import { n as isThenable } from "../thenable-BNSM1U2R.js";
 import { n as memoryAutomationSource, r as parseAutomation } from "../automation-x3KEUusw.js";
-import { l as withApp, t as getPermDock } from "../permdock-L-_I_3zP.js";
+import { l as withApp, t as getPermDock } from "../permdock-BvjivVb9.js";
 import { o as automationEvent } from "../sink-D9_vh372.js";
 import { a as requestApproval, s as resumeDecision } from "../helpers-DJicaG6f.js";
 import { i as subjectFromRunTicket, r as signRunTicket } from "../run-ticket-Dv7aF7Dk.js";

package/dist/workflow-sdk/index.d.ts

@@ -1,8 +1,8 @@
-import { Ln as Decision } from "../policy-types-CCiDRZBH.js";
+import { Un as Decision } from "../policy-types-DGIO_gxq.js";
 import { u as Permission } from "../permission-types-CAY-GU7e.js";
-import { a as PermDock } from "../permdock-B6Sf4T_S.js";
-import { n as ApprovalWaiter } from "../waiter-Bu9zAlE0.js";
-import { i as WorkflowPermDock, r as StartAutomationResult, t as AutomationOptions } from "../create-CM1FciYG.js";
+import { a as PermDock } from "../permdock-CprAPN3w.js";
+import { n as ApprovalWaiter } from "../waiter-CqUKX6CY.js";
+import { i as WorkflowPermDock, r as StartAutomationResult, t as AutomationOptions } from "../create-BamXmeob.js";
 //#region src/workflow-sdk/index.d.ts
 /**
  * The part of a Workflow SDK `Hook` the waiter reads: awaiting it suspends the

package/dist/{wrap-DlJE3gS_.d.ts → wrap-DxXB54Wu.d.ts}

@@ -1,5 +1,5 @@
-import { j as PolicyVocabulary } from "./policy-types-CCiDRZBH.js";
-import { a as PermDock } from "./permdock-B6Sf4T_S.js";
+import { j as PolicyVocabulary } from "./policy-types-DGIO_gxq.js";
+import { a as PermDock } from "./permdock-CprAPN3w.js";
 //#region src/core/wrap.d.ts
 /** A wrapper an adapter applies to each instance it builds, as `withOtel` does. */
 type PermDockWrap = <V extends PolicyVocabulary>(permdock: PermDock<V>) => PermDock<V>;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "permdock",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "description": "Typed permissions for TypeScript apps, APIs, databases, and AI agents, with the permdock CLI and test runners.",
   "keywords": [
     "ai-agents",
@@ -364,7 +364,7 @@
     "fastest-levenshtein": "1.0.16",
     "fastify": "5.12.7",
     "h3": "2.0.2",
-    "happy-dom": "20.14.5",
+    "happy-dom": "21.0.4",
     "hono": "4.13.13",
     "jose": "6.2.12",
     "kysely": "0.29.6",

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

@@ -36,7 +36,7 @@ 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. 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.
+- 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. A function that checks a known set of rows (one tenant's, a page, a batch) calls `permitted_<resource>_rows('<permission key>', <text[] of ids>)`, which reads only those ids, instead of the one-argument form, which reads the whole table, or a `permitted_<resource>_row` call per 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.

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

@@ -517,7 +517,8 @@ Supabase specifics for generated RLS (the generic flags and parity checks are in
 - Under `migra`, generate `--split helpers,seeds,policies,hook --out supabase/schemas/identity/056_permdock_{part}.sql --seeds-out supabase/migrations/` and write the schema and function privileges and the `security_invoker` view option with `--grants-out` into a migration created by `supabase migration new` after the first `db diff`; `db diff` drops those, so never append them to a migration by hand. Table grants and policies stay in the schema files, where `db diff` keeps them. Keep the helpers part ahead of every file that calls the helpers in `schema_paths` (`permdock doctor` PD042, PD043).
 - `--authorize jwt` reads the hook's claims: enable the printed `[auth.hook.custom_access_token]` stanza in `supabase/config.toml`. The generated hook writes the canonical `memberships` claim from the `rls.memberships.scopes` tables, so do not hand-write one.
 - For more than one membership table, declare `tableMembershipSource` / `junctionMembershipSource` sources once (from `permdock/supabase`, with a `query` on the server), pass the array as `memberships` (wrapped in `claimsFirst(sources, { version: authzVersion({ query }) })` to trust the token until it is truncated or stale), put the same sources under `supabase.hook.memberships` in `permdock.config.ts`, and run `permdock supabase hook generate`; add the printed `config.toml` block (`jwt_expiry = 900`). List member-removal and payout permissions in `definePolicy({ fresh })`.
-- When the server has only supabase-js (no `SqlQuery`), never re-read memberships, global roles or custom roles with the admin client: grant `subject_for(p_user)` and `authz_version_for(p_user)` (written next to the hook) to the backend role, expose them through `public` wrappers when `permdock` is not an exposed schema, and use `postgrestSources(admin, { schema, fn, versionFn, policy })`: `claimsFirst(sources.memberships)` (with `onStale: 'reread'` a fresh token costs one version call, and with `policy` a token that claims a custom role costs one `subject_for` call), `customRoles: sources.customRoles(principal)`, and `await sources.subject(userId)` for a job acting for a stored user.
+- When the server has only supabase-js (no `SqlQuery`), never re-read memberships, global roles or custom roles with the admin client: grant `subject_for(p_user)` and `authz_version_for(p_user)` (written next to the hook) to the backend role, expose them through `public` wrappers when `permdock` is not an exposed schema, and use `postgrestSources(admin, { schema, fn, versionFn, policy })`: `claimsFirst(sources.memberships)` (with `onStale: 'reread'` a fresh token costs one version call, and with `policy` a token that claims a custom role costs one `subject_for` call), `customRoles: sources.customRoles(principal)`, and `await sources.subject(userId)` for a job acting for a stored user. Create `postgrestSources` and the `claimsFirst` source once at module scope, never per request or per cache scope: they keep no answers, and `getPermDock` shares each read within one instance.
+- When a page builds many instances (Next.js `'use cache: private'` islands, PPR) or an API serves many `GET`s per user, add `versions: memoryVersionCache({ maxStaleMs: 5_000 })` to `claimsFirst(sources.memberships, { onStale: 'reread' })` at module scope. Rendering and `GET` / `HEAD` / `OPTIONS` use intent `read` and share one version call per `maxStaleMs`; `protectAction`, other HTTP methods and core `getPermDock` use `write` and read live. Before a mutation outside `protectAction` in Next.js, call `getPermDock({ intent: 'write' })`. After a role change call `versions.evict(userId)` ([freshness and the version cache](https://permdock.com/docs/adapters/supabase#freshness-and-the-version-cache)).
 - When a role table stores a role id (`user_roles.role_id`, `organization_users.role_id` referencing `roles`), read the key through it with `{ through: 'roles', on: { role_id: 'id' }, column: 'key' }`: in `rls.roles`, in `tableMembershipSource` `columns.role` or `junctionMembershipSource` `roles`, and in an `rls.memberships` table's `role`. Never copy keys into the membership table. Keep tenant custom-role keys apart from declared role names.
 - When one membership row holds roles in several columns (a `tier` and a `role_id`), list them instead of building a union view: `role: ['tier', { through: 'roles', on: { role_id: 'id' }, column: 'key' }]` in `rls.memberships` and `tableMembershipSource` `columns.role`, `roles: { sources: [...] }` in `junctionMembershipSource`. The row holds every non-null key, and the holder-count triggers stay on the real table.
 - When a membership table names a profile instead of a login (`customer_contacts.contact_profile_id` referencing `contact_profiles`, whose `user_id` is the login), read the user through it with `junctionMembershipSource` `user` or `tableMembershipSource` `columns.user`: `{ through: 'contact_profiles', on: { contact_profile_id: 'id' }, column: 'user_id' }`. Never copy `user_id` onto the membership rows. Keep `contact_profiles.user_id` server-owned (PD028).

package/dist/catalog-mRQQQhNK.js

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

package/dist/collect-B5BL3klN.js

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

package/dist/powersync-Djf-zCpB.js

@@ -1 +0,0 @@
-export { n as runPowerSync } from "./powersync-DHNQX06W.js";

package/dist/pull-B65ndFNZ.js

@@ -1 +0,0 @@
-export { n as runCloudPull } from "./pull-CwpGaQSi.js";

package/dist/run-D-JE8QWb.js

@@ -1 +0,0 @@
-export { t as run } from "./run-Bz26OTfO.js";

package/dist/supabase-hook-H-MtE9Wd.js

@@ -1 +0,0 @@
-export { i as runSupabase } from "./supabase-hook-B-yXnzUl.js";

package/dist/usage-CYeXek0p.js

@@ -1 +0,0 @@
-export { t as runUsage } from "./usage-CxEzS4ey.js";

package/dist/watch-DB42U1ib.js

@@ -1 +0,0 @@
-export { i as watchCollect } from "./watch-Cx_WciLE.js";