permdock 0.16.0 → 0.18.0

package/skills/permdock-approvals/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: permdock-approvals
-description: Requires human approval on PermDock grants, notifies approvers and resumes the approved call. Use when adding approval to a destructive or money-moving action (delete, publish, pay, refund, transfer), choosing approvers with approval by, user(), relation(), distinct, quorum, ttl, escalation or staleOn, ordering approvers with mode and stages, covering an approver with an ApprovalDelegation, loading approval rules as data with an ApprovalPolicySource, separating preparer and approver with exclusiveWith, labelling operations with risk and effects meta, mounting approvalsHandler with an ApprovalStore, sending approval emails (approvalEmail) or chat cards (approvalCard, approvalActions) from approvalPrompt, parking a background run on an ApprovalWaiter (pollingApprovalWaiter, workflowSdkWaiter), resuming with the PermDock-Approval header, mapping approval-required to an agent runtime, MCP elicitation or AG-UI interrupt, or fixing doctor PD017, PD018 or PD024.
+description: Requires human approval on PermDock grants, notifies approvers and resumes the approved call. Use when adding approval to a destructive or money-moving action (delete, publish, pay, refund, transfer), choosing approvers with approval by, user(), relation(), manager(), mode confirm or authorize, quorum, ttl, escalation, staleOn or approvalFingerprint, ordering approvers with combine and stages, covering an approver with an ApprovalDelegation, loading approval rules as data with an ApprovalPolicySource, separating preparer and approver with exclusiveWith, labelling operations with risk and effects meta, mounting approvalsHandler with an ApprovalStore, sending approval emails (approvalEmail) or chat cards (approvalCard, approvalActions) from approvalPrompt, parking a background run on an ApprovalWaiter (pollingApprovalWaiter, workflowSdkWaiter), resuming with the PermDock-Approval header, mapping approval-required to an agent runtime, MCP elicitation or AG-UI interrupt, or fixing doctor PD017, PD018 or PD024.
 license: MIT
 metadata:
   author: ScaleDockHQ
@@ -25,12 +25,12 @@ metadata:
 
 ## Invariants
 
-1. The requester never approves by default. The actor is always refused. The principal is refused unless the grant sets `distinct: false`, and `requireDistinctApprover` on the handler refuses it even then. A delegate is held to the same rule, and so is the delegator. One hop, and `until` is required.
+1. The requester never approves by default. The actor is always refused. The principal is refused unless the grant sets `mode: "confirm"`, and `requireDistinctApprover` on the handler refuses it even then. A delegate is held to the same rule, and so is the delegator. One hop, and `until` is required.
 2. The approver comes from authentication on the approval surface, never from the request body, a tool argument or a link.
 3. One approval resumes one call. The token binds permission, resource, subject and actor, the resume re-runs `decide`, and `consume` spends the approval once.
 4. `can` returns `false` for `approval-required`. Only `decide`, `assert` and the adapters see the third outcome.
 5. Quorum, ttl and escalation live on the grant, not in the store. A grant's `ttl` can shorten the store's window, never extend it.
-6. A `relation()` approver is matched only through facts the approvals handler reads from the app's `RelationSource` at verdict time, never from a request body.
+6. A `relation()` or `manager()` approver is matched only through facts the approvals handler reads from the app's `RelationSource` at verdict time, never from a request body.
 7. Approval rules kept as data only add stages. A source that fails to load denies every call an allow would grant.
 8. A link never approves. An email or chat prompt carries the request id, never the token, and links to the app's approval page where the approver signs in. Chat buttons carry the request id and are applied as the platform-verified clicking user.
 9. A wake carries no verdict. `waiter.wake(token)` only ends a wait; the run decides again through `resumeApproval`, which reads the store.
@@ -51,9 +51,9 @@ metadata:
    });
    ```
 
-   For sign-off in order, use `mode: 'sequential'` with `stages: [{ by, quorum? }]` (or `mode: 'all'` for any order); one person signs one stage. `user('u_cfo')` names one person, and `relation(permissions.expense, 'manager')` names whoever holds the relation on the row.
-   Add `distinct: false` only where the user confirms their own agent's call and no money, deletion or access change sits behind it.
-   ✓ `permdock doctor` reports no PD017 (sensitive verb without approval), and every PD024 (`distinct: false`) is deliberate.
+   For sign-off in order, use `combine: 'sequential'` with `stages: [{ by, quorum? }]` (or `combine: 'all'` for any order); one person signs one stage. `user('u_cfo')` names one person, and `relation(permissions.expense, 'manager')` names whoever holds the relation on the row.
+   Add `mode: "confirm"` only where the user confirms their own agent's call and no money, deletion or access change sits behind it.
+   ✓ `permdock doctor` reports no PD017 (sensitive verb without approval), and every PD024 (`mode: "confirm"`) is deliberate.
 
 2. **Bind content when it matters.** Declare `version: 'updatedAt'` (or a revision counter) on the `resource()` and add `staleOn: 'resource-change'` to the approval, so a changed row resumes as `stale-approval` and asks again.
    ✓ `definePolicy` accepts the grant (it throws when the resource has no `version` or the action is a collection action).
@@ -77,12 +77,12 @@ metadata:
 ## Verify before done
 
 - [ ] Every destructive or money-moving action an agent or a user can trigger has `approval`, or a `deny` on the same leaf.
-- [ ] Each `distinct: false` (PD024) is a deliberate self-confirmation with nothing irreversible behind it.
+- [ ] Each `mode: "confirm"` (PD024) is a deliberate self-confirmation with nothing irreversible behind it.
 - [ ] Roles that must not be held together set `exclusiveWith`, and PD018 is clean.
 - [ ] The store survives the deployment: no `memoryApprovalStore` on serverless or across replicas.
 - [ ] No resume token is read from model output or tool arguments, and each resume re-runs `decide`.
 - [ ] A custom `ApprovalStore` passes `testApprovalStore` from `permdock/testing`.
-- [ ] Grants with `relation()` approvers have a handler with `relations`, and nothing fills `verdict.relations` from client input.
+- [ ] Grants with `relation()` or `manager()` approvers have a handler with `relations`, and nothing fills `verdict.relations` from client input.
 - [ ] No email, chat message or URL carries the approval token or an approve link; `approvalUrl` is https and opens a page behind sign-in.
 - [ ] Approval recipients are decided by `deliver` from server-loaded principals, never from the request body, and the requester is not among them.
 - [ ] Chat approve and reject clicks go through `approvalActions` (or `resolveAction`), never a handler that trusts the button value alone.

package/skills/permdock-approvals/references/stores-and-resume.md

@@ -15,7 +15,7 @@ export const { protect } = createPermDock(policy, { subject, store });
 // Routes for approvers: GET /pending, GET /mine, GET /:id, GET /:id/signature, POST /:id/approve, POST /:id/reject
 const handler = approvalsHandler(store, {
   subject: (request) => approverFromSession(request), // the approver, from real authentication
-  requireDistinctApprover: false, // true refuses the principal even where a grant sets distinct: false
+  requireDistinctApprover: false, // true refuses the principal even where a grant sets mode: "confirm"
   relations, // RelationSource: needed when a grant uses relation() approvers
   permissions, // the permission tree, for relation approvers reached through links
 });
@@ -73,7 +73,7 @@ A gate in your own code resumes the same way with `resumeDecision` from `permdoc
 
 Over HTTP, the client retries the same request with the `PermDock-Approval: <token>` header. In React, `approvalHeaders(token)` builds that header and `useApproval(decision)` requests and polls an approval from the UI.
 
-A bad resume is denied with detail `approval-not-found`, `approval-pending`, `approval-rejected`, `approval-expired`, `approval-consumed` or `approval-mismatch`; a changed row is `stale-approval`. `approvalsHandler` answers `403` for an ineligible approver (`approver-not-eligible`, the actor, or the principal without `distinct: false`) and `409` for a repeated one (`approver-repeated`).
+A bad resume is denied with detail `approval-not-found`, `approval-pending`, `approval-rejected`, `approval-expired`, `approval-consumed` or `approval-mismatch`; a changed row is `stale-approval`. `approvalsHandler` answers `403` for an ineligible approver (`approver-not-eligible`, the actor, or the principal without `mode: "confirm"`) and `409` for a repeated one (`approver-repeated`).
 
 ## Delegation
 
@@ -106,4 +106,8 @@ Send the prompt with `approvalPrompt` and `permdock/delivery`: `approvalEmail` f
 
 ## Approvers
 
-`by` takes roles, `user(id)`, `relation()`, `holder(permission)` and `anyOf(...)`. A list is all-of; use `anyOf(user(id), holder(permissions.x.approve))` for "this person or anyone who holds the permission". `holder()` needs `approvalsHandler(store, { permdockFor: (approver, request) => createPermDock(policy, approver, { customRoles }) })`, so custom roles count. Stages may carry their own `escalation`.
+`by` takes roles, `user(id)`, `relation()`, `manager({ levels? })` (whoever holds `manager` on the requester's `user` record, up to `levels` steps; with better-supabase, set `rls.approvals.managers: { table, user, manager }` so SQL matches it too), `holder(permission)` and `anyOf(...)`. A list is all-of; use `anyOf(user(id), holder(permissions.x.approve))` for "this person or anyone who holds the permission". `holder()` needs `approvalsHandler(store, { permdockFor: (approver, request) => createPermDock(policy, approver, { customRoles }) })`, so custom roles count. Stages may carry their own `escalation`.
+
+## Operation fingerprints
+
+Bind an approval to the exact operation with `fingerprint`: `permdock.decide(permission, row, { fingerprint: approvalFingerprint({ id, amount, to }) })`. The token and the stored request carry it, and a resume or `consumeApproval(store, token, at, { fingerprint })` under another one fails with `approval-fingerprint-mismatch`. `approvalFingerprint` returns the same hex string as better-supabase's, synchronously.

package/skills/permdock-audit/SKILL.md

@@ -44,7 +44,7 @@ Read the app's `permissions.ts`, `policy.ts`, factory file and every adapter gua
    ✓ Every policy and custom store has its runner, or a finding.
 6. **ASI02 and ASI03.** Map the inventory onto [OWASP Agentic](https://permdock.com/docs/security/owasp-agentic); for the threat list itself, defer to the `owasp-agentic` spec skill (`npx skills add ScaleDockHQ/scaledock-skills --skill owasp-agentic`).
    - **ASI02** (tool misuse): unmapped tools, a collection permission on a row handler, a destructive tool without `approval`, capability lists that include denied tools.
-   - **ASI03** (identity and privilege abuse): a model-supplied subject or actor, an actor used as approver, `distinct: false` on a sensitive action, a resume token not bound to permission, resource, subject and actor, API keys stored in plain text or created outside `decideCredential`, keys without expiry (PD029), and a `memberships` source applied to service-key subjects.
+   - **ASI03** (identity and privilege abuse): a model-supplied subject or actor, an actor used as approver, `mode: "confirm"` on a sensitive action, a resume token not bound to permission, resource, subject and actor, API keys stored in plain text or created outside `decideCredential`, keys without expiry (PD029), and a `memberships` source applied to service-key subjects.
      ✓ Each agent adapter in the app has an ASI02 line and an ASI03 line.
 7. **Pull request review**, when the scope is one PR. Review only what the diff changes:
    - Run `permdock collect --check` and `permdock usage --json` on both sides and compare. New leaves with no grant, grants for leaves nobody checks, and new `undeclared` or `outsideInclude` findings are comments.

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

@@ -137,6 +137,8 @@ To answer guards from synced rows, write `localSnapshotManifest(policy)` (from `
 
 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).
 
+For role and tenant changes on Supabase, pass `refreshOn={nativeRefresh({ supabase, appState: AppState, netInfo, powersync: { db, connector, manifest } })}`: on the user's private `authz:<uid>` topic it refreshes the session, reconnects PowerSync so streams that read token claims see the new ones, then refreshes the snapshot. The generated `permdock_authz_version` stream lets `powerSyncSource` set `snapshot.authzVersion`. PD084 names streams that read token claims; a fixture with `after` and `expected: "changed"` makes `permdock powersync verify` check that their rows follow the change. Docs: [role and tenant changes](https://permdock.com/docs/adapters/react-native#role-and-tenant-changes).
+
 ## Express — `permdock/express`
 
 ```ts
@@ -501,7 +503,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 `auth.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.permissions.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`.
+With better-supabase, set `auth.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 })` (or `authorizer({ policy, permdockFor })` to share one instance cache with `permdockFor(...).sources(versions)` in oRPC, MCP and `permdock/next`) 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. `requestApprovers: true` also passes better-supabase's `{approvers}` (the request's current step) to the five-argument `permdock_is_approver`, so a cover from `rls.approvals.delegations` reaches users and managers a block policy names; it needs a better-supabase release that fills `{approvers}`. `rls.approvals: { store: false, delegations: true }` writes the covers without PermDock's store. `blockApprovalStore(approvals, { tenantless })` resolves through the block's `approve` and `reject` with `decidedBy`, and `blockApprovalPolicySource(approvals, { platform, permissions, effects })` maps conditions, effects, `*` and platform policies, dropping what it cannot express so a policy only gets stricter. `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.permissions.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 unless the `data` option loads one (`hookCan(permdock, { data: (tenant, key) => row })`, `handlerCan(source, { data: (request, key) => row })`), so without it a permission with a row condition denies, 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.
 

package/dist/action-result-BcudBQOF.d.ts

@@ -1,19 +0,0 @@
-import { a as ProblemDetails } from "./errors-BIM4MFsJ.js";
-//#region src/core/action-result.d.ts
-/** What a `protectAction` action resolves to; both members cross to the client. */
-type ActionResult<T> = {
-  readonly ok: true;
-  readonly value: T;
-} | {
-  readonly ok: false;
-  readonly problem: ProblemDetails;
-};
-/**
- * The server action: `approval` is the token of a granted approval request,
- * which resumes an `approval-required` decision.
- */
-type ProtectedAction<T> = (input: unknown, options?: {
-  readonly approval?: string;
-}) => Promise<ActionResult<T>>;
-//#endregion
-export { ProtectedAction as n, ActionResult as t };

package/dist/catalog-D3oS2GH3.js

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

package/dist/collect-D-eroIfV.js

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

package/dist/load-Dm0pSYH3.js

@@ -1 +0,0 @@
-export { a as loadModule, s as pickNamed } from "./load-DjSU5KXO.js";

package/dist/output-files-BHOIlrfD.js

@@ -1 +0,0 @@
-export { t as SPLIT_PARTS } from "./output-files-BIQ_9pIs.js";

package/dist/powersync-0QVP_DuR.js

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

package/dist/pull-CCAChKuy.js

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

package/dist/renames-CGj7YwcQ.js

@@ -1,175 +0,0 @@
-//#region src/cli/core/renames.ts
-const DB_COMMANDS = [
-	"rls generate",
-	"rls import",
-	"rls verify",
-	"supabase hook generate",
-	"powersync verify"
-];
-const FLAG_RENAMES = [
-	{
-		commands: DB_COMMANDS,
-		from: "--db",
-		to: "--db-url-stdin",
-		hint: "--db-url-stdin or DATABASE_URL"
-	},
-	{
-		commands: DB_COMMANDS,
-		from: "--db-url",
-		to: "--db-url-stdin",
-		hint: "--db-url-stdin or DATABASE_URL"
-	},
-	{
-		commands: ["rls generate"],
-		from: "--force",
-		to: "--force-rls"
-	},
-	{
-		commands: ["rls verify"],
-		from: "--format",
-		to: "--kind"
-	},
-	{
-		commands: ["rls verify"],
-		from: "--emit",
-		to: "--kind"
-	},
-	{
-		commands: ["catalog"],
-		from: "--format",
-		to: "--kind",
-		values: {
-			json: "catalog",
-			schema: "json-schema",
-			markdown: "markdown"
-		}
-	},
-	{
-		commands: ["openapi emit"],
-		from: "--format",
-		to: "--kind"
-	},
-	{
-		commands: [
-			"rls generate",
-			"rls verify",
-			"rls migrate",
-			"powersync generate",
-			"powersync verify",
-			"openapi emit"
-		],
-		from: "--from",
-		to: "--policy"
-	},
-	{
-		commands: ["catalog", "arazzo check"],
-		from: "--from",
-		to: "--permissions"
-	},
-	{
-		commands: ["rls import", "openapi import"],
-		from: "--schema",
-		to: "--validator"
-	},
-	{
-		commands: [
-			"usage",
-			"config",
-			"doctor"
-		],
-		from: "--strict",
-		to: "--fail-on",
-		hint: "--fail-on warning",
-		rewrite: "--fail-on warning"
-	},
-	{
-		commands: ["login"],
-		from: "--write",
-		to: "--scope",
-		hint: "--scope catalog:write",
-		rewrite: "--scope catalog:write"
-	},
-	{
-		commands: ["skills install", "skills update"],
-		from: "--agent",
-		to: "--for"
-	},
-	{
-		commands: ["skills install", "skills update"],
-		from: "--client",
-		to: "--for"
-	},
-	{
-		commands: ["init"],
-		from: "--agent",
-		to: "--integration"
-	},
-	{
-		commands: ["init"],
-		from: "--ui",
-		to: "--integration"
-	},
-	{
-		commands: ["init"],
-		from: "--src",
-		to: "--out-dir"
-	},
-	{
-		commands: [
-			"rls generate",
-			"rls verify",
-			"rls migrate"
-		],
-		from: "--rbac-scaffold",
-		to: "--rbac",
-		hint: "--rbac supabase",
-		rewrite: "--rbac supabase"
-	},
-	{
-		commands: ["rls migrate"],
-		from: "--write",
-		hint: "rls migrate writes by default; --dry-run prints the plan without writing",
-		rewrite: ""
-	},
-	{
-		commands: ["cloud push"],
-		from: "--environment",
-		to: "--project",
-		hint: "--project <id>: a project id is its environment"
-	},
-	{
-		commands: ["scan"],
-		from: "--legacy",
-		hint: "permdock scan lists the checks written without PermDock; drop --legacy",
-		rewrite: ""
-	}
-];
-const COMMAND_MOVES = [
-	{
-		from: "openapi",
-		to: "openapi emit"
-	},
-	{
-		from: "skills",
-		to: "skills install"
-	},
-	{
-		from: "arazzo",
-		to: "arazzo check"
-	}
-];
-const DEFAULT_CHANGES = [{
-	command: "rls migrate",
-	unless: ["--write", "--retire-out"],
-	add: "--dry-run"
-}];
-/** The rename that matches `flag` (as typed, before any `=`) on `command`. */
-function flagRename(command, flag) {
-	return FLAG_RENAMES.find((rename) => rename.from === flag && rename.commands.includes(command));
-}
-function renameMessage(command, rename) {
-	const replacement = rename.hint ?? rename.to;
-	return replacement === void 0 ? `${command}: ${rename.from} was removed in 0.5.0.` : rename.to === void 0 ? `${command}: ${rename.from} was removed in 0.5.0: ${replacement}.` : `${command}: ${rename.from} is ${replacement} since 0.5.0.`;
-}
-//#endregion
-export { renameMessage as i, DEFAULT_CHANGES as n, flagRename as r, COMMAND_MOVES as t };

package/dist/run-C5P3x1EI.js

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

package/dist/supabase-hook-qsewAVZY.js

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

package/dist/usage-DmmO_xjJ.js

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

package/dist/watch-CuPz0D2M.js

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