@palbase/backend 30.0.1 → 33.0.0

package/docs/README.md

@@ -73,7 +73,7 @@ service the controllers call.
 
 > **Never** emit `defineController`, `defineHandler`, `defineEndpoint`, `route.get(...)`,
 > `req.input`, `req.params`, or `req.errors` — those are the removed legacy model
-> and will not compile against `@palbase/backend` 30.
+> and will not compile against `@palbase/backend` 33.
 
 ### Complete CRUD example (copy-pasteable, compiles)
 

package/docs/auth.md

@@ -39,35 +39,117 @@ interface User {
 Every field is **server-resolved** from the verified profile — nothing here is
 client-settable. `metadata` is your own `auth.users.metadata` (set through the
 admin users API); `role` is the **database** role RLS reads and is always
-`"authenticated"` for a signed-in user, so application roles belong in
-`metadata`, not there.
+`"authenticated"` for a signed-in user, so `user.role === "admin"` is always
+false and reads like a working check.
 
-`emailVerified` is likewise read from the verified profile rather than a JWT
-claim: a claim is only true as of when the token was minted, so a user who
-verifies mid-session would keep reporting `false` until their token expired.
-Profile reads are cached for ~30 seconds, so a change shows up within that
-window, not on the very next request.
+Application roles are **`user.roles`** — a `string[]` resolved per request from
+`auth.user_roles`, the table `palbase roles` writes. They were once kept in
+`metadata`; they are not any more, and a role written there gates nothing.
 
-## Roles
+`emailVerified`, `email`, `role` and `metadata` come from the **verified token**,
+so they say what was true when it was minted: a user who confirms their address
+mid-session keeps reporting `false` until their next token. `roles` is the
+exception, and deliberately so — it is read from the table on every request, so
+a grant or a revocation lands immediately.
 
-`auth: { role: "admin" }` gates on the caller's `metadata.role`:
+## Roles and permissions
+
+Roles are **yours**. There is no built-in "admin": you declare the roles your
+app has, and what each one is allowed to do, from the command line —
+
+```bash
+palbase roles create member    --default --permissions notes.create
+palbase roles create moderator           --permissions notes.create,notes.delete_any
+palbase roles assign usr_01a0… moderator
+```
+
+— and `palbase spec` brings them back as constants, so a misspelled permission
+is a compile error rather than a silent `403`:
 
 ```ts
-@Controller("/admin", { auth: { role: "admin" } })
-export default class AdminController {
-  @Get("/stats")
-  stats(): Promise<Stats> { … }   // only metadata.role === "admin" reaches here
+import { Roles, Permissions } from "./palbe.gen";
+Roles.moderator            // 'moderator'
+Permissions.notesDeleteAny // 'notes.delete_any'
+```
+
+`--default` marks the one role every new sign-up receives, written in the same
+transaction as the user row.
+
+### The endpoint gate
+
+```ts
+@Controller("/notes")
+export default class NotesController {
+  // Anyone signed in.
+  @Get("") list(@User() user: UserT) { … }
+
+  // Only a caller holding the permission — the handler never runs otherwise.
+  @Delete("/{id}", { auth: { permission: "notes.delete_any" } })
+  remove(@Param("id") id: string) { … }
+
+  // Or by role, when the check really is "is this caller a moderator".
+  @Get("/queue", { auth: { role: "moderator" } })
+  queue() { … }
 }
 ```
 
-Not signed in → `401`. Signed in with a different (or missing) role → `403`. A
-role gate implies authentication, so the caller is resolved even on a route with
-no `@User()` parameter.
+Not signed in → `401`: declaring a permission or a role implies authentication,
+so the caller is resolved even on a route with no `@User()` parameter. Signed in
+without it → `403`, and the body names what was missing:
+
+```json
+{ "error": "forbidden",
+  "error_description": "This endpoint requires the \"notes.delete_any\" permission" }
+```
+
+If you deliberately open a route with `auth: { required: false, permission: … }`,
+an unauthenticated caller reaches the gate and is refused with `403` — no
+identity means no roles, and the gate answers that rather than waving them
+through.
+
+**Authority is in no claim.** The gate reads `auth.user_roles` inside the
+transaction your handler is about to use — never a JWT claim — so
+`palbase roles revoke` closes the door on the **very next request**, with the
+same access token, no refresh and no re-login. Nothing is cached, and there is
+no epoch to bump.
+
+### The RLS half
+
+The gate decides whether the handler runs. It cannot decide which **rows** the
+handler sees — that is Postgres's job, and the same permissions are available
+there:
+
+```ts
+policies: () => [
+  policy("notes_owner").for("all").to("authenticated")
+    .using("user_id = (select auth.uid())")
+    .withCheck("user_id = (select auth.uid())"),
+
+  // Moderation. Permissive policies are OR'd, so these widen only.
+  policy("notes_moderate_read").for("select").to("authenticated")
+    .using("(select auth.has_permission('notes.delete_any'))"),
+  policy("notes_delete_any").for("delete").to("authenticated")
+    .using("(select auth.has_permission('notes.delete_any'))"),
+]
+```
+
+**The read policy is not optional, and leaving it out is the trap.**
+`DELETE … WHERE id = $1` has to FIND the row first, and that read is governed by
+the SELECT policies. With only the DELETE policy, a moderator holding the
+permission deletes **nothing**: the row is invisible to them, the `WHERE`
+matches nothing, and the statement answers `DELETE 0` — a silent no-op, not an
+error. The rule: **if a permission writes to somebody else's row, a SELECT
+policy has to show them that row.**
+
+Two helpers are available in every policy body:
+
+| helper | answers |
+|---|---|
+| `auth.has_permission(text)` | does the caller hold this permission, through any role they carry |
+| `auth.app_roles()` | the caller's roles as `text[]`, sorted, `{}` when none |
 
-The role is read from the verified profile, not from a claim baked into the
-token, so revoking it takes effect **within ~30 seconds** — the runtime caches a
-verified identity for that long — rather than whenever the token happens to
-expire.
+Both take the caller from `auth.uid()` and accept no user id, so a policy cannot
+ask about somebody else.
 
 ## Email verification
 

package/docs/database.md

@@ -171,6 +171,35 @@ that arrives in a request body is NOT a column reference and is refused as an
 unknown operator, so spreading untrusted input into a filter cannot turn a
 tenant predicate into a tautology.
 
+### A table name from a variable does not compile — use a literal
+
+Inside `Database.$transaction`, reading the table name out of a VARIABLE stops
+compiling once a schema grows:
+
+```ts
+const purge = (t: keyof Tables) =>
+  Database.$transaction((tx) => [tx.public[t].deleteWhere({ id })]);
+//                                         ^
+// error TS2590: Expression produces a union type that is too complex to represent.
+```
+
+**Measured:** clean up to seven tables, **failing at eight** — and at 12, 20, 26
+and 40. What decides it is the table count together with tables carrying
+DIFFERENT relation name sets; **the column count does not matter** (8 tables × 2
+columns fails, 4 tables × 200 columns is clean), so "use fewer columns" is not a
+remedy. The cause is TypeScript's own complexity ceiling: a variable key forces
+the compiler to intersect every table's `where` parameter at once.
+
+**Write the table name as a literal:**
+
+```ts
+await Database.$transaction((tx) => [tx.public.payments.deleteWhere({ id })]);
+```
+
+If the name really is only known at runtime, use the raw ops — `Database.$query`,
+`Database.$deleteMany` — which take the table as a string. The same limit made
+Kysely withdraw the pattern in v0.28; Drizzle never offered it.
+
 ### Filtering through a relation — `has`
 
 A filter on the row next to yours is the most common reason to drop to raw SQL,
@@ -220,6 +249,31 @@ await Database.$transaction((tx) => {
 });
 ```
 
+### Fetching related rows — `with`
+
+`has` FILTERS through a relation; `with` FETCHES through it. Same relation
+graph, same names, one query:
+
+```ts
+const rows = await Database.public.users.findMany({
+  where: { active: true },
+  with: { orders: { select: ["id", "amount"], limit: 5 } },
+});
+rows[0].orders[0].amount;   // string — exact
+```
+
+It compiles to a `LEFT JOIN LATERAL` with `json_agg` — one statement, one round
+trip, both tables' RLS applied. A `many` relation is an ARRAY (`[]` when empty,
+never `null`, so `.map()` needs no guard); a `one` relation is a single row or
+`null`.
+
+The inner options are the same language: `select`, `where`, `orderBy`, `limit`.
+
+**Money survives.** Every `numeric` and `bigint` column is cast to text on its
+way into the JSON. Without that cast a `numeric` becomes a JSON *number* and
+loses precision — measured on live pg16, `100000000000000000000000000` comes
+back as `1e+26`. `integer` is left alone: it fits a double exactly.
+
 ### Ordering and paging
 
 ```ts

package/docs/llms-full.txt

@@ -81,7 +81,7 @@ service the controllers call.
 
 > **Never** emit `defineController`, `defineHandler`, `defineEndpoint`, `route.get(...)`,
 > `req.input`, `req.params`, or `req.errors` — those are the removed legacy model
-> and will not compile against `@palbase/backend` 30.
+> and will not compile against `@palbase/backend` 33.
 
 ### Complete CRUD example (copy-pasteable, compiles)
 
@@ -741,35 +741,117 @@ interface User {
 Every field is **server-resolved** from the verified profile — nothing here is
 client-settable. `metadata` is your own `auth.users.metadata` (set through the
 admin users API); `role` is the **database** role RLS reads and is always
-`"authenticated"` for a signed-in user, so application roles belong in
-`metadata`, not there.
+`"authenticated"` for a signed-in user, so `user.role === "admin"` is always
+false and reads like a working check.
 
-`emailVerified` is likewise read from the verified profile rather than a JWT
-claim: a claim is only true as of when the token was minted, so a user who
-verifies mid-session would keep reporting `false` until their token expired.
-Profile reads are cached for ~30 seconds, so a change shows up within that
-window, not on the very next request.
+Application roles are **`user.roles`** — a `string[]` resolved per request from
+`auth.user_roles`, the table `palbase roles` writes. They were once kept in
+`metadata`; they are not any more, and a role written there gates nothing.
 
-## Roles
+`emailVerified`, `email`, `role` and `metadata` come from the **verified token**,
+so they say what was true when it was minted: a user who confirms their address
+mid-session keeps reporting `false` until their next token. `roles` is the
+exception, and deliberately so — it is read from the table on every request, so
+a grant or a revocation lands immediately.
 
-`auth: { role: "admin" }` gates on the caller's `metadata.role`:
+## Roles and permissions
+
+Roles are **yours**. There is no built-in "admin": you declare the roles your
+app has, and what each one is allowed to do, from the command line —
+
+```bash
+palbase roles create member    --default --permissions notes.create
+palbase roles create moderator           --permissions notes.create,notes.delete_any
+palbase roles assign usr_01a0… moderator
+```
+
+— and `palbase spec` brings them back as constants, so a misspelled permission
+is a compile error rather than a silent `403`:
+
+```ts
+import { Roles, Permissions } from "./palbe.gen";
+Roles.moderator            // 'moderator'
+Permissions.notesDeleteAny // 'notes.delete_any'
+```
+
+`--default` marks the one role every new sign-up receives, written in the same
+transaction as the user row.
+
+### The endpoint gate
 
 ```ts
-@Controller("/admin", { auth: { role: "admin" } })
-export default class AdminController {
-  @Get("/stats")
-  stats(): Promise<Stats> { … }   // only metadata.role === "admin" reaches here
+@Controller("/notes")
+export default class NotesController {
+  // Anyone signed in.
+  @Get("") list(@User() user: UserT) { … }
+
+  // Only a caller holding the permission — the handler never runs otherwise.
+  @Delete("/{id}", { auth: { permission: "notes.delete_any" } })
+  remove(@Param("id") id: string) { … }
+
+  // Or by role, when the check really is "is this caller a moderator".
+  @Get("/queue", { auth: { role: "moderator" } })
+  queue() { … }
 }
 ```
 
-Not signed in → `401`. Signed in with a different (or missing) role → `403`. A
-role gate implies authentication, so the caller is resolved even on a route with
-no `@User()` parameter.
+Not signed in → `401`: declaring a permission or a role implies authentication,
+so the caller is resolved even on a route with no `@User()` parameter. Signed in
+without it → `403`, and the body names what was missing:
+
+```json
+{ "error": "forbidden",
+  "error_description": "This endpoint requires the \"notes.delete_any\" permission" }
+```
+
+If you deliberately open a route with `auth: { required: false, permission: … }`,
+an unauthenticated caller reaches the gate and is refused with `403` — no
+identity means no roles, and the gate answers that rather than waving them
+through.
+
+**Authority is in no claim.** The gate reads `auth.user_roles` inside the
+transaction your handler is about to use — never a JWT claim — so
+`palbase roles revoke` closes the door on the **very next request**, with the
+same access token, no refresh and no re-login. Nothing is cached, and there is
+no epoch to bump.
+
+### The RLS half
+
+The gate decides whether the handler runs. It cannot decide which **rows** the
+handler sees — that is Postgres's job, and the same permissions are available
+there:
+
+```ts
+policies: () => [
+  policy("notes_owner").for("all").to("authenticated")
+    .using("user_id = (select auth.uid())")
+    .withCheck("user_id = (select auth.uid())"),
+
+  // Moderation. Permissive policies are OR'd, so these widen only.
+  policy("notes_moderate_read").for("select").to("authenticated")
+    .using("(select auth.has_permission('notes.delete_any'))"),
+  policy("notes_delete_any").for("delete").to("authenticated")
+    .using("(select auth.has_permission('notes.delete_any'))"),
+]
+```
+
+**The read policy is not optional, and leaving it out is the trap.**
+`DELETE … WHERE id = $1` has to FIND the row first, and that read is governed by
+the SELECT policies. With only the DELETE policy, a moderator holding the
+permission deletes **nothing**: the row is invisible to them, the `WHERE`
+matches nothing, and the statement answers `DELETE 0` — a silent no-op, not an
+error. The rule: **if a permission writes to somebody else's row, a SELECT
+policy has to show them that row.**
+
+Two helpers are available in every policy body:
+
+| helper | answers |
+|---|---|
+| `auth.has_permission(text)` | does the caller hold this permission, through any role they carry |
+| `auth.app_roles()` | the caller's roles as `text[]`, sorted, `{}` when none |
 
-The role is read from the verified profile, not from a claim baked into the
-token, so revoking it takes effect **within ~30 seconds** — the runtime caches a
-verified identity for that long — rather than whenever the token happens to
-expire.
+Both take the caller from `auth.uid()` and accept no user id, so a policy cannot
+ask about somebody else.
 
 ## Email verification
 
@@ -1057,6 +1139,35 @@ that arrives in a request body is NOT a column reference and is refused as an
 unknown operator, so spreading untrusted input into a filter cannot turn a
 tenant predicate into a tautology.
 
+### A table name from a variable does not compile — use a literal
+
+Inside `Database.$transaction`, reading the table name out of a VARIABLE stops
+compiling once a schema grows:
+
+```ts
+const purge = (t: keyof Tables) =>
+  Database.$transaction((tx) => [tx.public[t].deleteWhere({ id })]);
+//                                         ^
+// error TS2590: Expression produces a union type that is too complex to represent.
+```
+
+**Measured:** clean up to seven tables, **failing at eight** — and at 12, 20, 26
+and 40. What decides it is the table count together with tables carrying
+DIFFERENT relation name sets; **the column count does not matter** (8 tables × 2
+columns fails, 4 tables × 200 columns is clean), so "use fewer columns" is not a
+remedy. The cause is TypeScript's own complexity ceiling: a variable key forces
+the compiler to intersect every table's `where` parameter at once.
+
+**Write the table name as a literal:**
+
+```ts
+await Database.$transaction((tx) => [tx.public.payments.deleteWhere({ id })]);
+```
+
+If the name really is only known at runtime, use the raw ops — `Database.$query`,
+`Database.$deleteMany` — which take the table as a string. The same limit made
+Kysely withdraw the pattern in v0.28; Drizzle never offered it.
+
 ### Filtering through a relation — `has`
 
 A filter on the row next to yours is the most common reason to drop to raw SQL,
@@ -1106,6 +1217,31 @@ await Database.$transaction((tx) => {
 });
 ```
 
+### Fetching related rows — `with`
+
+`has` FILTERS through a relation; `with` FETCHES through it. Same relation
+graph, same names, one query:
+
+```ts
+const rows = await Database.public.users.findMany({
+  where: { active: true },
+  with: { orders: { select: ["id", "amount"], limit: 5 } },
+});
+rows[0].orders[0].amount;   // string — exact
+```
+
+It compiles to a `LEFT JOIN LATERAL` with `json_agg` — one statement, one round
+trip, both tables' RLS applied. A `many` relation is an ARRAY (`[]` when empty,
+never `null`, so `.map()` needs no guard); a `one` relation is a single row or
+`null`.
+
+The inner options are the same language: `select`, `where`, `orderBy`, `limit`.
+
+**Money survives.** Every `numeric` and `bigint` column is cast to text on its
+way into the JSON. Without that cast a `numeric` becomes a JSON *number* and
+loses precision — measured on live pg16, `100000000000000000000000000` comes
+back as `1e+26`. `integer` is left alone: it fits a double exactly.
+
 ### Ordering and paging
 
 ```ts
@@ -1648,6 +1784,38 @@ export const invoices = defineTable("invoices", {
 });
 ```
 
+## Exact-precision columns: `bigint` / `numeric`
+
+Both arrive as **`string`**, and that is correct: a JS number cannot hold
+Postgres' full `int8` range or an arbitrary-precision decimal. The driver
+serialises them as strings and the generated types say so.
+
+Application code usually wants a number anyway, and rewriting
+`Number(row.amount)` / `String(x)` in every caller is where the two directions
+drift apart. Declare the conversion ONCE, on the column:
+
+```ts
+amount_kurus: bigint().asNumber(),    // row.amount_kurus: number
+rate:         numeric().asDecimal(),  // row.rate: string — declared, not defaulted
+```
+
+| Declaration | Generated type | Runtime |
+|---|---|---|
+| `bigint()` / `numeric()` | `string` | untouched |
+| `.asNumber()` | `number` | `Number(v)` in, `String(v)` out |
+| `.asDecimal()` | `string` | `String(v)` — the same value, said out loud |
+
+`.asNumber()` loses precision above 2^53; use `.asDecimal()` (and a decimal
+library) for values that can exceed it. Both are available only on `bigint()`
+and `numeric()` — any other column type refuses the call by name.
+
+> **`.transform<T>()` is refused.** Its target type is a type parameter and does
+> not exist at runtime, so the type generator could never learn it: it printed
+> `string` while the engine handed back a number, silently. A codec is NAMED
+> instead of typed, which is what lets one declaration produce both the
+> conversion and the type. `palbase build` names the table and column when it
+> finds one.
+
 ## Column builders
 
 | Builder | Postgres type |
@@ -2089,6 +2257,32 @@ once per statement (an initPlan) instead of once per row. `auth.role()` and
 `auth.uid()` is `NULL`, so an `owner = (select auth.uid())` policy matches no
 rows.
 
+**`auth.has_permission('resource.action')`** answers whether the caller holds
+that permission through any role they carry, and **`auth.app_roles()`** returns
+their roles as a sorted `text[]` (`{}` when they hold none). Both read
+`auth.user_roles` — the table `palbase roles` writes — and both take the caller
+from `auth.uid()`, so a policy cannot ask about somebody else. A revoked role is
+gone from the very next statement; there is nothing cached.
+
+```ts
+policy("notes_owner").for("all")
+  .using("user_id = (select auth.uid())")
+  .withCheck("user_id = (select auth.uid())"),
+
+// Moderation. Permissive policies are OR'd, so these widen only.
+policy("notes_moderate_read").for("select")
+  .using("(select auth.has_permission('notes.delete_any'))"),
+policy("notes_delete_any").for("delete")
+  .using("(select auth.has_permission('notes.delete_any'))"),
+```
+
+> **The read policy is not optional.** `DELETE … WHERE id = $1` has to FIND the
+> row first, and that read is governed by the SELECT policies. With only the
+> DELETE policy above, a moderator holding the permission deletes **nothing** —
+> the row is invisible to them, so the `WHERE` matches nothing and the statement
+> answers `DELETE 0`. No error, no log. If a permission writes to somebody
+> else's row, a SELECT policy has to show them that row.
+
 > Name policies with a `pb_` prefix. Palbase reconciliation only manages
 > policies it authored (`pb_`-prefixed) and never touches policies created by
 > other modules (storage, cron, …).

package/docs/schema.md

@@ -107,6 +107,38 @@ export const invoices = defineTable("invoices", {
 });
 ```
 
+## Exact-precision columns: `bigint` / `numeric`
+
+Both arrive as **`string`**, and that is correct: a JS number cannot hold
+Postgres' full `int8` range or an arbitrary-precision decimal. The driver
+serialises them as strings and the generated types say so.
+
+Application code usually wants a number anyway, and rewriting
+`Number(row.amount)` / `String(x)` in every caller is where the two directions
+drift apart. Declare the conversion ONCE, on the column:
+
+```ts
+amount_kurus: bigint().asNumber(),    // row.amount_kurus: number
+rate:         numeric().asDecimal(),  // row.rate: string — declared, not defaulted
+```
+
+| Declaration | Generated type | Runtime |
+|---|---|---|
+| `bigint()` / `numeric()` | `string` | untouched |
+| `.asNumber()` | `number` | `Number(v)` in, `String(v)` out |
+| `.asDecimal()` | `string` | `String(v)` — the same value, said out loud |
+
+`.asNumber()` loses precision above 2^53; use `.asDecimal()` (and a decimal
+library) for values that can exceed it. Both are available only on `bigint()`
+and `numeric()` — any other column type refuses the call by name.
+
+> **`.transform<T>()` is refused.** Its target type is a type parameter and does
+> not exist at runtime, so the type generator could never learn it: it printed
+> `string` while the engine handed back a number, silently. A codec is NAMED
+> instead of typed, which is what lets one declaration produce both the
+> conversion and the type. `palbase build` names the table and column when it
+> finds one.
+
 ## Column builders
 
 | Builder | Postgres type |
@@ -548,6 +580,32 @@ once per statement (an initPlan) instead of once per row. `auth.role()` and
 `auth.uid()` is `NULL`, so an `owner = (select auth.uid())` policy matches no
 rows.
 
+**`auth.has_permission('resource.action')`** answers whether the caller holds
+that permission through any role they carry, and **`auth.app_roles()`** returns
+their roles as a sorted `text[]` (`{}` when they hold none). Both read
+`auth.user_roles` — the table `palbase roles` writes — and both take the caller
+from `auth.uid()`, so a policy cannot ask about somebody else. A revoked role is
+gone from the very next statement; there is nothing cached.
+
+```ts
+policy("notes_owner").for("all")
+  .using("user_id = (select auth.uid())")
+  .withCheck("user_id = (select auth.uid())"),
+
+// Moderation. Permissive policies are OR'd, so these widen only.
+policy("notes_moderate_read").for("select")
+  .using("(select auth.has_permission('notes.delete_any'))"),
+policy("notes_delete_any").for("delete")
+  .using("(select auth.has_permission('notes.delete_any'))"),
+```
+
+> **The read policy is not optional.** `DELETE … WHERE id = $1` has to FIND the
+> row first, and that read is governed by the SELECT policies. With only the
+> DELETE policy above, a moderator holding the permission deletes **nothing** —
+> the row is invisible to them, so the `WHERE` matches nothing and the statement
+> answers `DELETE 0`. No error, no log. If a permission writes to somebody
+> else's row, a SELECT policy has to show them that row.
+
 > Name policies with a `pb_` prefix. Palbase reconciliation only manages
 > policies it authored (`pb_`-prefixed) and never touches policies created by
 > other modules (storage, cron, …).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@palbase/backend",
-  "version": "30.0.1",
+  "version": "33.0.0",
   "description": "Palbase Backend SDK — class controllers (@Controller/@Get/@Post + @Body/@QueryParams/@Param), error classes, schema DSL",
   "license": "MIT",
   "repository": {

package/template/db/public.ts

@@ -30,6 +30,29 @@ const notes = defineTable("notes", {
       .to("authenticated")
       .using("user_id = (select auth.uid())")
       .withCheck("user_id = (select auth.uid())"),
+
+    // MODERATION, when you want it — delete these two if you do not.
+    //
+    // Roles are yours and there is no built-in "admin": you declare them from
+    // the command line (`palbase roles create moderator --permissions
+    // notes.delete_any`) and `auth.has_permission` answers from the roles the
+    // caller actually holds right now. Permissive policies are OR'd, so these
+    // widen only: the owner rule above keeps working untouched.
+    //
+    // THE READ POLICY IS NOT OPTIONAL. `DELETE … WHERE id = $1` has to FIND the
+    // row first, and that read is governed by the SELECT policies — with only
+    // the delete rule below, a moderator holding the permission deletes NOTHING
+    // and gets no error, because the row is invisible to them and the WHERE
+    // matches nothing. If a permission writes to somebody else's row, a SELECT
+    // policy has to show them that row.
+    policy("notes_moderate_read")
+      .for("select")
+      .to("authenticated")
+      .using("(select auth.has_permission('notes.delete_any'))"),
+    policy("notes_delete_any")
+      .for("delete")
+      .to("authenticated")
+      .using("(select auth.has_permission('notes.delete_any'))"),
   ],
 });
 

package/template/package.json

@@ -9,7 +9,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@palbase/backend": "^30.0.0",
+    "@palbase/backend": "^33.0.0",
     "reflect-metadata": "^0.2.2"
   },
   "engines": {