naro-cli 0.10.0 → 0.12.0

package/README.md

@@ -91,9 +91,11 @@ naro db dump --output backup.sql   SQL dump, streamed from Cloudflare (stdout wi
 naro db restore --bookmark <id>    Time Travel, last 30 days (or --timestamp <time>);
                                    asks first, prints the command that undoes it
 naro db pull                       Existing database, no migrations yet: writes its schema
-                                   as migrations/0001_remote_schema.sql, recorded as applied
+                                   and policies as migrations/0001_remote_schema.sql,
+                                   recorded as applied
 naro db reset [--dry-run]          Drop every table, view and trigger, clear the ledger and
-                                   apply ./migrations again (asks first; --yes in CI)
+                                   the policies, and apply ./migrations again (asks first;
+                                   --yes in CI; refuses files the server would refuse)
 naro db lint [--strict]            Check the schema for what D1 actually trips on; exits 1
                                    on an error, and on a warning too with --strict
 naro db table create posts --column "id:integer:pk:autoincrement" --column "title:text:notnull" --column "created_at:datetime:notnull:default=current_timestamp" --owner user_id
@@ -144,12 +146,19 @@ naro backend auth redirects remove https://app.example.com/auth/
                                    Exits 1, changing nothing, when it is not in the list
 naro backend auth require-verification on
                                    Refuse sign-in until the email is confirmed (needs email)
-naro policy list                   Per-table rules and conditions of the Data API
+naro policy list [--table todos]   Row-level security policies, as CREATE POLICY
+naro policy create 'CREATE POLICY "own todos" ON todos TO authenticated USING (user_id = auth.uid()) WITH CHECK (user_id = auth.uid())'
+naro policy create --file policies.sql
+                                   CREATE POLICY and DROP POLICY statements, run in order;
+                                   --allow-unindexed accepts a subquery on the outer row
+                                   that no index serves (refused otherwise)
+naro policy drop "own todos" --table todos
+                                   DROP POLICY (asks first)
 naro policy set todos --select owner --insert owner --update owner --delete owner --owner user_id
 naro policy set posts --select-when 'or(is_public.eq.true,user_id.eq.auth.uid())' --insert-when 'user_id.eq.auth.uid()'
 naro policy set posts --from-file policy.json
-                                   The policy as JSON, conditions and all
-naro policy remove todos           Back to deny (asks first)
+                                   Shorthand: writes the policies naro_select … naro_delete
+naro policy remove todos           Drop every policy on the table: back to deny (asks first)
 
 naro promote <deployment-id>       Publish a build to production
 naro rollback [deployment-id]      Back to the previous production build
@@ -184,12 +193,43 @@ reads the bookmark from just before the drops and prints it, so
 `naro db restore --bookmark <that>` puts the data back. `--dry-run` lists what
 it would drop and re-apply without touching anything.
 
+The backend's accounts, sessions, settings and the other `_naro_` tables are
+kept — except its policies: they are cleared with the schema and the migration
+files create them again. Before it reads anything, `db reset` checks the files
+as `naro db push --dry-run` does: when the control plane would refuse one, the
+re-apply would stop there with the schema already dropped, so the reset is
+refused with `VALIDATION_FAILED`, each file as `<file>: Statement <i> of <n>:
+…` (`--dry-run` prints them and exits 1). A policy that exists only in the
+database would be lost — one made with `naro policy create` or
+`naro policy set`, and the owner policy that `naro db table create --owner`,
+MCP's `create_table` and the table editor add, which no migration file holds.
+So before it asks, `db reset` lists the policies your files do not make, each
+with the SQL that makes it again — its `CREATE POLICY` and, for an owner rule,
+the `COMMENT ON POLICY … IS 'naro:owner <column>'` that keeps its column
+(`--json`: `policiesNotInFiles[].sql`); add it to a migration first to keep
+them. The policies of a table your files do not create go with that table and
+are named apart, with no SQL (`--json`: `policiesOfTablesNotInFiles`): a
+migration that made them would stop at a table that is not there. A file the
+re-apply would stop at that the check above does not catch (one whose SQL
+cannot be split) is named instead — `<file> would be refused: <reason>`
+(`--json`: `wouldBeRefused`) — and then no policy is called lost. A policy row
+that cannot be read is listed as a `-- Policy … cannot be read` comment
+instead: copying it keeps nothing, so drop that policy and create it again. A
+backend whose worker predates named policies is refused with
+`409 BACKEND_OUTDATED`: run `naro backend enable` first.
+
 `naro db lint` reads the schema and runs the checks D1 allows. Its rules are
 the ones D1 actually trips on — orphaned rows, a failed `quick_check`, a
 missing or nullable primary key, a foreign key no index starts with, a trigger
 the REST API cannot recreate, a virtual table that makes `db dump` refuse the
-whole database. There is no "unused index" guess: D1 keeps no execution
-statistics to base one on. An error exits 1, a warning exits 0 — `--strict`
+whole database. On a project with a backend it also checks the policies:
+`rls_no_policy` (a table the Data API refuses entirely),
+`rls_policy_text_default` (a number column a policy reads as a boolean whose
+`DEFAULT` is text, such as `BOOLEAN DEFAULT 'true'`) and
+`rls_policy_unindexed` (warnings), and `rls_policy_invalid`, a policy the
+backend cannot apply — one that reads a text column as true or false among
+them (an error). There is no "unused index" guess: D1 keeps
+no execution statistics to base one on. An error exits 1, a warning exits 0 — `--strict`
 makes warnings fail too, so CI can gate on it:
 
 ```bash
@@ -210,7 +250,9 @@ from a fixed list — and applies it as one migration, recorded in
 `d1_migrations` and written to `./migrations` as `NNNN_schema_<op>_<table>.sql`,
 numbered after your local files and the ledger. `naro migration list`,
 `db pull` and `db reset` see it like any other migration; with `--no-write`
-there is no file, so `db reset` will not re-apply it. `--dry-run` prints the
+there is no file, so `db reset` will not re-apply it. The owner policy
+`--owner` adds is not in that file either: `db reset` lists it, with its SQL,
+before it removes it — add that SQL to a migration to keep it. `--dry-run` prints the
 SQL and changes nothing. While a local migration is not in the ledger yet, a
 change is refused — `naro db push` it first, or the change would run before it.
 
@@ -225,11 +267,30 @@ A column is `name:type[:modifier…]`:
 Every primary key but a single `integer` one is `NOT NULL`; a foreign key must
 point at its table's primary key or a unique column. `--owner user_id` adds
 `user_id TEXT NOT NULL` and, when the backend is on and ready, an owner policy for all
-four actions; any other new table is closed to the Data API until you run
-`naro policy set` (the command says so). Policies are kept by table name: a
-drop removes the table's policy whenever the project has a backend, on or off
-(the command says so), and a rename leaves the old one behind — the command
-prints what to run.
+four actions; any other new table is closed to the Data API until you give it
+a policy (`CREATE POLICY` in a migration, or `naro policy create` or
+`naro policy set`; the command says so).
+Policies are kept by table name: a drop removes the table's policies whenever
+the project has a backend, on or off (the command says so). A rename leaves
+them under the old name, where they apply to no table — the command prints
+what to run to move them. Move them then: the next time `naro db table`
+creates a table as that name or renames one to it, renaming the table back
+included, the policies stored under the name are removed first, so a new
+table never inherits an earlier one's (except, on a project without a
+backend, one changed through `naro db table`, the table editor or MCP) — and
+neither does a table made by `naro db push` or `naro db query`. Whatever a command removes it prints
+so it can be made again: as `CREATE POLICY` statements, which
+`naro policy create` takes back, and — for owner rules, whose owner column
+`CREATE POLICY` cannot say — as the `naro policy set <table> … --owner <column>`
+command that sets them again. A statement that cannot be shown as it is (a
+control character, or a line break inside a string) prints as a `--` comment
+in its place; `--json` has the exact text.
+
+A policy reads columns and, in a subquery, other tables. When a rename or a
+drop takes one of them away, the Data API answers `500 POLICY_INVALID` to the
+requests that policy applies to — on another table, when the policy of `docs`
+reads `members`. The command names each policy the change breaks and why;
+`--dry-run` names them before anything is applied.
 
 SQLite cannot add a PRIMARY KEY, UNIQUE or NOT-NULL-without-default column, or
 drop a primary key, a unique or indexed column, or a table another table
@@ -411,21 +472,245 @@ A backend turned on before user management answers the `users` commands
 `409 BACKEND_OUTDATED`: run `naro backend enable` once to update this
 project's backend, then run the command again.
 
-Policies are default deny: a table without one refuses every anon and
-signed-in request. Each of `--select`, `--insert`, `--update` and `--delete`
-takes `none`, `public`, `authenticated` or `owner`; `owner` lets a signed-in
-user reach only rows whose `--owner` column holds their user id, and fills
-that column in on insert. What a `policy set` leaves out keeps its stored
-value. A change is live within about 10 seconds. `naro gen types` reads the
-policies too: with `--insert owner --owner user_id`, `user_id` is optional in
-the generated `Insert` even when it is `NOT NULL` with no default — run it
+### Row-level security
+
+Policies are Postgres's row-level security, as in Supabase. A table without a
+policy refuses every anon and signed-in request; the service key skips
+policies. Write a table's policies in the migration that creates it —
+`CREATE POLICY` after the `CREATE TABLE`, in the same file. `naro db push`,
+`naro migration up`, `naro db query` and the MCP tools `apply_migration` and
+`execute_sql` apply them together with the table, all or nothing. Three shapes
+cover most apps:
+
+```sql
+-- migrations/0002_todos.sql: each signed-in user reads and changes their own rows.
+CREATE TABLE todos (
+  id integer PRIMARY KEY,
+  user_id uuid NOT NULL,
+  title text NOT NULL
+);
+CREATE POLICY "own rows" ON todos FOR ALL TO authenticated
+  USING ((select auth.uid()) = user_id)
+  WITH CHECK ((select auth.uid()) = user_id);
+
+-- migrations/0003_posts.sql: anyone reads, signed in or not.
+CREATE TABLE posts (id integer PRIMARY KEY, title text NOT NULL);
+CREATE POLICY "read" ON posts FOR SELECT TO anon, authenticated USING (true);
+
+-- migrations/0004_reports.sql: an app only its admins sign in to. First run
+-- naro backend auth signups off and create the admin accounts: authenticated
+-- then means exactly those accounts.
+CREATE TABLE reports (id integer PRIMARY KEY, body text NOT NULL);
+CREATE POLICY "admins" ON reports FOR ALL TO authenticated USING (true) WITH CHECK (true);
+```
+
+A migration or a query takes `CREATE POLICY`; `DROP POLICY [IF EXISTS]` (`IF
+EXISTS` skips a missing table too, as in Postgres); `COMMENT ON POLICY p ON t
+IS 'naro:owner <column>'`, which makes `p` the owner rule `naro policy set
+--owner` writes (any other comment is ignored); and `ALTER TABLE t ENABLE |
+FORCE | NO FORCE ROW LEVEL SECURITY`, which changes nothing because
+row-level security is always on. Before anything runs, naro refuses these with
+`400 VALIDATION_FAILED` "Statement <i> of <n>: …":
+
+- `ALTER TABLE … DISABLE ROW LEVEL SECURITY` — it is always on; to let
+  everyone through, create a policy: `CREATE POLICY "open" ON t USING (true)
+WITH CHECK (true);`
+- `GRANT` and `REVOKE` — every table is behind row-level security, so write a
+  policy instead;
+- `ALTER POLICY` — `DROP POLICY` and `CREATE POLICY` again;
+- a table named `public.x` in `CREATE TABLE`, `DROP TABLE` or a rename: `SQLite
+has no schema "public": write the table name without "public."`
+- a `CREATE POLICY` that reads a column inside a subquery with no table in
+  front of it, when a later statement of the same file creates, drops, renames
+  or alters the policy's table or a table its subqueries read: `a later
+statement changes a table, so name the table of every column inside this
+policy's subqueries (for example members.user_id).` Postgres decides whose
+  column it is when the policy is created; naro binds it once the file is in,
+  when the later statement may have added that name to the subquery's table.
+  A later statement that changes only other tables — the next table of a file
+  grouped table by table — leaves the policy alone.
+
+The statements of one request apply all-or-nothing, the policies with the
+tables: a policy on a table that does not exist
+(`relation "nope" does not exist`), a name already taken, or a 33rd policy on
+one table fails the whole request with `400 DATABASE_QUERY_FAILED`, names the
+statement, and applies nothing — not even the `CREATE TABLE` before it. Policy
+statements, and statements that create, drop or rename a table, take no
+`params` (`400 VALIDATION_FAILED`): write the values into the SQL.
+
+Policies go with their table, as in Postgres: `DROP TABLE` drops them, and a
+new table never inherits the leftovers of an earlier one with the same name
+(except tables changed through the table editor on a project without a backend).
+SQLite changes a column by building the table again — `CREATE TABLE
+__new_x`, copy the rows, `DROP TABLE x`, `ALTER TABLE __new_x RENAME TO x` — so
+the drop removes `x`'s policies and the rename does not bring them back. Write
+the `CREATE POLICY` statements again after the rename, in the same migration.
+A plain `ALTER TABLE a RENAME TO b` does not move them either: they stay under
+`a`, and `b` has none until you create them again.
+The answer's `warnings` lists the policies a migration removed, with SQL you
+can paste; it also says when the project has no backend yet (the policies are
+saved and apply once `naro backend enable` turns it on) and when a policy was
+applied that the Data API refuses, with the reason. `naro db push` and
+`naro db query` print each warning as `⚠ …` on stderr (`--json` has it whole
+in `warnings`, a query's in `result.warnings`).
+
+`naro db push --dry-run` parses the policy statements of the pending files on
+your machine and prints what it would refuse as `<file>: Statement <i> of <n>:
+…` (exit 1); whether a table or a policy exists is known only when the file is
+applied. `naro db pull` writes the policies that exist at the end of the
+baseline file — `ALTER TABLE … ENABLE ROW LEVEL SECURITY;` for each table,
+then each `CREATE POLICY …;`, an owner rule's column as `COMMENT ON POLICY …
+IS 'naro:owner <column>';` (a database without policies pulls as plain
+SQLite). `naro db reset` clears the policies with the schema and creates them
+again from the migration files, so a policy that exists only in the database
+is lost; it lists those before it asks, each with the SQL to add to a
+migration to keep it (an owner rule's column as its `COMMENT ON POLICY`; a
+row that cannot be read is only a comment — drop it and create it again), and
+names apart, without SQL, the policies of tables your files do not create. It
+refuses to start when the control plane would refuse one of the files.
+`naro db lint`, on a
+project with a backend, reports `rls_no_policy` (a table the Data API refuses
+entirely), `rls_policy_text_default` and `rls_policy_unindexed` as warnings,
+and `rls_policy_invalid` — a
+policy the backend cannot apply, such as one that reads a text column as true
+or false — as an error.
+
+`naro policy create` sends the same statements to the database directly: one
+in quotes, or `--file` with several, `DROP POLICY` included. Nothing records
+them in `./migrations`, so `naro db reset` removes what your files do not
+make; use it for a table that already exists. A change is live within about 10
+seconds, and `naro policy list` prints the policies back as SQL. More complete
+policies — they give each user their own todos, everyone the published posts
+and team members their team's docs, and hide deleted docs from all of them:
+
+```sql
+-- Each signed-in user reads and changes their own todos.
+CREATE POLICY "own todos" ON todos TO authenticated
+  USING (user_id = auth.uid()) WITH CHECK (user_id = auth.uid());
+
+-- Anyone reads published posts.
+CREATE POLICY "published posts" ON posts FOR SELECT USING (published);
+
+-- Members read their team's docs. The subquery reads members through
+-- members' own select policies, so members needs one.
+CREATE POLICY "own memberships" ON members FOR SELECT TO authenticated
+  USING (user_id = auth.uid());
+CREATE POLICY "team docs" ON docs FOR SELECT TO authenticated
+  USING (EXISTS (SELECT 1 FROM members m
+                 WHERE m.team_id = docs.team_id AND m.user_id = auth.uid()));
+
+-- Deleted docs stay hidden, whatever else lets them through.
+CREATE POLICY "hide deleted" ON docs AS RESTRICTIVE FOR SELECT
+  USING (deleted_at IS NULL);
+```
+
+A request passes when at least one permissive policy for its command and role
+passes and every restrictive one does. `FOR ALL` (the default) is every
+command; `TO public` (the default) is anon and signed-in users. As in
+Postgres:
+
+- select reaches the rows the select policies pass;
+- insert writes a row only when it passes `WITH CHECK`, and with `.select()`
+  the select policies too;
+- update reaches the rows its `USING` and the select policies pass, and each
+  changed row must pass `WITH CHECK` (`USING` when there is none) and the
+  select policies — so an update that moves a row out of what select shows,
+  like a soft delete, is refused;
+- delete reaches the rows its `USING` and the select policies pass.
+
+A row outside `USING` is skipped without a word. A written row that misses a
+check writes nothing and answers `403 PERMISSION_DENIED` "New row violates
+row-level security policy for table todos." (with the name of a restrictive
+policy it missed). With no permissive policy for the command, the request is
+refused — `403 PERMISSION_DENIED` "This request is not allowed by the update
+policy of todos." — where Postgres would answer no rows.
+
+Expressions: columns, literals, comparisons, `AND`/`OR`/`NOT`, `IS [NOT] NULL`,
+`IS [NOT] DISTINCT FROM`, `[NOT] IN (…)`, `[NOT] LIKE`/`ILIKE`, `BETWEEN`,
+`EXISTS (SELECT …)` and `IN (SELECT …)`, `auth.uid()`, `auth.role()`,
+`auth.jwt() ->> 'sub' | 'role' | 'email' | 'email_verified'`, and `lower`,
+`upper`, `coalesce`, `length`, `now()`. Supabase's `(select auth.uid())` reads
+as `auth.uid()`. A subquery's table is read through its own select policies;
+policies that would expand themselves are refused ("Infinite recursion
+detected in policy for relation members."). A statement's policies bind at
+most 50 values and write at most 50,000 bytes of SQL, leaving the rest of
+D1's 100 values and 100,000 bytes to the request. A `LIKE` or `ILIKE` pattern
+is at most 50 bytes of UTF-8, which is D1's limit; `LIKE` counts each `*`,
+`?` and `[` as 3.
+
+A subquery that reads the outer row (`m.team_id = docs.team_id`) runs once for
+every row the statement looks at, so it needs an index to find its rows: the
+control plane refuses such a policy until a column its WHERE compares with `=`
+(or `IN`) to a value from outside it starts an index, and names the index to
+create — `naro db index create members team_id`. `--allow-unindexed` accepts
+it anyway; every run then reads the whole table.
+
+For anon, `auth.uid()` is NULL and `auth.jwt()` holds only `role` `'anon'`, as
+in Supabase, and NULL logic is Postgres's: `auth.uid() IS NULL` is true for
+anon, `user_id = auth.uid()` and its `NOT` match no row, and a `NOT EXISTS`
+over another table's policy reads that policy the same way. Target anon with
+`TO anon` or `auth.role() = 'anon'`. `auth.jwt() ->> 'email'` is the user's
+address only once it is verified, and NULL before — sign-up signs a user in
+before the address is confirmed, so an unverified one is only what was typed;
+`email_verified` says which. It is the text `'true'` or `'false'`: write
+`(auth.jwt() ->> 'email_verified') = 'true'`. `IS TRUE`, `IS FALSE`, `NOT x`
+and a value alone read a number or boolean column; on a claim, `auth.uid()`,
+a string, a function or a TEXT column they are refused, with the comparison
+to write — as text, `'true'` would read as false. So is comparing text with
+`TRUE` or `FALSE` — `<> false`, `= true`, `IN (true)`, `BETWEEN`,
+`IS DISTINCT FROM`, also through `coalesce` — since the text `'true'` is not
+`TRUE`: `<> false` would hold for everyone.
+
+Where naro differs from Postgres: no policy for a command is a 403, not zero
+rows; row-level security is always on; roles are only `anon` and
+`authenticated`, with no `security definer` functions; comparisons follow
+SQLite (column affinity and collation), and `lower`, `upper` and `ILIKE` fold
+ASCII only; `now()` is UTC text as `CURRENT_TIMESTAMP` stores it.
+
+`naro policy create --file` parses every statement first, so a syntax error
+sends none; then it runs them in order and stops at the first one refused,
+keeping those before it. `naro policy list` prints what `naro policy create`
+takes back, except the owner comment below. A policy whose name, table or
+string holds a control character (a line break, an escape) is not printed as
+a statement — with the character replaced it would create a different policy
+— but as a `--` comment that says so; `naro policy list --json` has its exact
+text.
+
+`naro policy drop <name>` takes the name as you type it: the policy of exactly
+that name, or else the one of its ASCII lower case. `CREATE POLICY MyPolicy`
+stores `mypolicy`, as in Postgres, and `naro policy drop MyPolicy --table
+todos` drops it; a policy created as `"MyPolicy"` is the one dropped when both
+exist.
+
+`naro policy set` is shorthand: it writes the policies `naro_select`,
+`naro_insert`, `naro_update` and `naro_delete` of a table and leaves its other
+policies alone. Each of `--select`, `--insert`, `--update` and `--delete`
+takes `none` (drops that policy), `public`, `authenticated` or `owner`;
+`owner` lets a signed-in user reach only rows whose `--owner` column holds
+their user id, and fills that column in on insert — a Naro extension SQL
+cannot say, so `naro policy list` prints it as a `-- naro: owner` comment.
+What a `policy set` leaves out keeps its stored value. `naro gen types` reads
+the policies too: with `--insert owner --owner user_id`, `user_id` is optional
+in the generated `Insert` even when it is `NOT NULL` with no default — run it
 again after changing a policy.
 
-Instead of a rule, an action can hold a condition on the row, like a Supabase
-row-level security policy, written in the filter syntax of `naro-js`'s
-`.or()` (commas are AND) with `auth.uid()` for the signed-in user's id —
-unquoted; `"auth.uid()"` is the text, and `auth.uid` without `()` is refused
-rather than read as text:
+A backend turned on before named policies answers the commands that write a
+policy — `naro policy create`, `naro policy drop` and `naro policy set` — with
+`409 BACKEND_OUTDATED`:
+``The project backend is older than named policies. Run `naro backend enable` to update it, then try again.``
+`naro backend enable` uploads the current backend and turns the stored rules
+into named policies; it also turns a backend that is off back on, so run
+`naro backend disable` again afterwards if it should stay off. `naro policy
+list` and `naro policy remove` work in the meantime. A migration or a query
+that holds a `CREATE POLICY` or `DROP POLICY` gets the same answer before
+anything runs; SQL without one runs as before.
+
+`naro policy set` refuses with `409 POLICY_EXISTS` when the table's `naro_<action>` policy is not one it wrote (for example one made with `naro policy create`): `Policy <name> on <table> is not one naro policy set wrote. Change it with naro policy create, or drop it first: naro policy drop <name> --table <table>.` A `naro_<action>` policy that cannot be read as stored (the table answers `500 POLICY_INVALID`) is not refused: setting a rule replaces it, and `none` drops it.
+
+Instead of a rule, an action can hold a condition on the row, written in the
+filter syntax of `naro-js`'s `.or()` (commas are AND) with `auth.uid()` for
+the signed-in user's id — unquoted; `"auth.uid()"` is the text, and
+`auth.uid` without `()` is refused rather than read as text:
 
 - `--select-when` and `--delete-when`: the rows reads and deletes reach.
 - `--insert-when`: what every new row must meet.
@@ -437,13 +722,26 @@ rather than read as text:
   so `not(and(is_public.eq.1,user_id.eq.auth.uid()))` matches every row that is
   not public, anon included — write what a condition lets in.
 
-When any row of an insert or an update misses its condition, nothing is
-written and the Data API answers `403 PERMISSION_DENIED` ("The new row does not
-meet the insert policy of posts."). A check reads a row as it will be stored
-and compares it with the column's collation (`COLLATE NOCASE`, `RTRIM`). So:
+A check — `WITH CHECK`, and the select policies an update's new row must
+pass — reads a row as it will be stored and compares it with the column's
+collation (`COLLATE NOCASE`, `RTRIM`). So:
 
 - a number column it reads takes numbers, booleans and null, not strings, and
-  cannot be compared with `like` or `ilike`;
+  cannot be compared with `like` or `ilike` — the Data API refuses a string
+  for a column that any policy of any table reads (an owner rule's own id
+  column excepted) with `400 INVALID_QUERY`. For a column whose declared type
+  has `INT`, `REAL`, `FLOA`, `DOUB`, `NUM`, `DEC`, `BOOL` or `BIT` in it, that
+  is every string — and even when no policy reads it, a string SQLite would
+  keep as text (`'abc'`, `'true'`; `'7'` is stored as 7), which Postgres
+  refuses as a type error and a policy written later would read inside out. A
+  column declared another type (`uuid`, `date`, `timestamptz`, `json`) keeps a
+  string as text, so Supabase's `user_id uuid` with `auth.uid() = user_id`
+  works; there the Data API refuses only a string SQLite would store as a
+  number (`'12'`), a string with a NUL character, and any string when a
+  policy reads the column as true or false or compares it with a number. On such a
+  column a `WITH CHECK` that orders it against a number (`<`, `>`, `BETWEEN`)
+  can judge a new text differently from the row it becomes, and `LIKE` or a
+  text function on it is refused as on a number column;
 - a primary key column it reads must be sent, and not as null;
 - any other column it reads may be left out only when it has no default or a
   plain one — `NULL`, `TRUE`, `FALSE`, a number, or a quoted string on a column
@@ -451,30 +749,56 @@ and compares it with the column's collation (`COLLATE NOCASE`, `RTRIM`). So:
   another expression must be sent;
 - it cannot read a generated column or a virtual table's column.
 
-One policy's conditions use at most 50 values together (an update's check
-counts each column it reads once more), leaving 50 of D1's 100 per statement
-for the request — 48 for a write with a check, which also binds the table's
-schema to make sure it checks against the table as it is now. `--from-file`
-takes the PUT body, or a policy object from `--json`
+The 50 values count an update's check once more for each column it reads, and
+a write with a check binds the table's schema too (48 left), to make sure it
+checks against the table as it is now. `--from-file` takes the PUT body, or a
+policy object from `--json`
 (`naro policy set posts --json | jq .policy > policy.json`), where
 `auth.uid()` is `{"auth":"uid"}`; its `table`, if it has one, must name the
 table being set. It cannot be combined with the other policy options.
-`naro policy list` prints each condition in filter syntax that reads back as
-the same condition, or as JSON where filter syntax cannot say it exactly
-(`deleted_at.eq.null` would be the text `"null"`, and `= NULL` is not
-`IS NULL`); `--json` gives the exact JSON.
-
-Two things a condition does not do for you. An update or delete is held to its
-own condition only, not to select's, unless it asks for rows back with
-`.select()`. With an update condition broader than select's, a caller can tell
-rows it cannot select apart without `.select()`: an update that sets a value
-the check refuses answers 403 when a hidden row matches its filters and 200
-when none does, so filter by filter it learns what those rows hold. Keep
-update and delete conditions no broader than select's. And an `--update-check`
-you give replaces the default: without `user_id.eq.auth.uid()` in it, a user
-can give a row away by changing its `user_id`. Write
+`naro policy set` prints the table's rules — each condition in filter syntax
+that reads back as the same condition, or as JSON where filter syntax cannot
+say it exactly (`deleted_at.eq.null` would be the text `"null"`, and `= NULL`
+is not `IS NULL`) — and then its policies as `CREATE POLICY`.
+
+An `--update-check` you give replaces the default: without
+`user_id.eq.auth.uid()` in it, a user can give a row away by changing its
+`user_id`. Write
 `--update-when 'user_id.eq.auth.uid()' --update-check 'user_id.eq.auth.uid(),status.eq.draft'`.
 
+## Release notes
+
+### 0.12.0
+
+- Migrations and `naro db query` take Postgres's `CREATE POLICY`,
+  `DROP POLICY` and `COMMENT ON POLICY … IS 'naro:owner <column>'` next to
+  the tables they are for (see Row-level security). `naro db reset` clears
+  the policies with the schema and creates them again from your migration
+  files; before it drops anything it checks the files as
+  `naro db push --dry-run` does, and lists the policies your files do not
+  make, with the SQL to keep them.
+- A failed `db push` keeps the server's `details.warnings` of the file that
+  failed (the policies a table rebuild took, with their SQL) and prints them
+  as `⚠` lines; the warnings of the files before it are
+  `details.appliedWarnings`.
+- **Update the CLI before you run `naro db reset`.** `naro-cli` 0.11.0
+  (published on 2026-10-05 from main `98bf538b`, PR #82) and every older
+  version know nothing of policies in migrations. On a project whose backend
+  has named policies, the control plane now drops a table's policies with
+  the table, so their `db reset` takes every policy along — without listing
+  first the ones your files do not make again, and without reading the
+  warning that names them. A table left without a policy refuses every
+  Data API request until you create one again.
+- **Check your clients before the backend updates.** The Data API now
+  refuses a string that SQLite would keep as text in a column declared with
+  INT, REAL, FLOA, DOUB, NUM, DEC, BOOL or BIT (a form's `"true"` for a
+  BOOLEAN, `"high"` for an INTEGER), even when no policy reads the column.
+  The backend worker takes this on at the project's next deploy or
+  `naro backend enable`, not when naro itself updates. Before that, look for
+  such rows: `naro db query "select count(*) from t where typeof(c) = 'text'"`
+  for each number or boolean column — a count above 0 means a client writes
+  strings there and needs fixing first.
+
 ## Machine-readable output (CI / AI agents)
 
 Every command supports `--json`: stdout carries exactly one JSON object,
@@ -497,6 +821,7 @@ Failures carry stable codes (`NOT_LOGGED_IN`, `PROJECT_NOT_LINKED`,
 `ENV_NOT_FOUND`, `DOMAIN_NOT_FOUND`, `DOMAIN_NOT_READY`,
 `BACKEND_DISABLED`, `BACKEND_NOT_READY`, `BACKEND_BUSY`,
 `BACKEND_ROTATION_FAILED`, `BACKEND_PROVISION_FAILED`, `POLICY_NOT_FOUND`,
+`POLICY_EXISTS`,
 `VALIDATION_FAILED`, `CONFIRMATION_REQUIRED`, `CANCELED`, …). A destructive
 command run non-interactively without `--yes` fails with
 `CONFIRMATION_REQUIRED` instead of silently doing nothing:
@@ -512,7 +837,8 @@ command run non-interactively without `--yes` fails with
 
 `--yes` (or `-y`) suppresses every prompt — destructive actions
 (production rollback/promote, env/domain removal, database reset, backend key
-rotation, policy removal) run unconfirmed, so use it deliberately in automation.
+rotation, policy removal and drop) run unconfirmed, so use it deliberately in
+automation.
 
 ## CI authentication
 

package/dist/artifact-types.d.ts

@@ -21,6 +21,11 @@ export interface DeploymentArtifact {
     assetsConfig?: {
         notFoundHandling: "single-page-application" | "404-page";
     };
+    /**
+     * Next.js routes ("/posts/[id]") for Speed Insights, read from the app's
+     * folders. Absent for other frameworks.
+     */
+    routes?: string[];
 }
 /** Mirrors the build log shape from the internal build package. */
 export interface BuildLog {