naro-cli 0.19.0 → 0.20.0

package/README.md

@@ -93,9 +93,12 @@ naro env add DATABASE_URL production
 naro env remove DATABASE_URL       The production, preview and all values; an environment's only with its name
                                    (naro env remove DATABASE_URL qa)
 naro env pull [.env.local]         Preview's values by default; --env production, or --env qa for an environment
-                                   (its own value wins over all; an unknown name fails before anything is written)
+                                   (its own value wins over all; an unknown name fails before anything is written,
+                                   and so does a value no dotenv line reads back)
 naro env import .env.qa qa         Upload every variable in a dotenv file to one target (all by default; asks first,
-                                   --yes in CI; invalid keys or values over 5 KB stop it before any request)
+                                   --yes in CI; an unclosed quote, an invalid key, ASSETS or a value over 5 KB
+                                   stops it before any request, and so does a key a storage binding already uses
+                                   when there are over 100 variables; an empty value is uploaded and shown (empty))
 
 naro environments                  List the project's environments: address, branch, protection, and how many the plan allows
 naro environments create qa --branch qa
@@ -195,6 +198,7 @@ naro policy remove todos           Drop every policy on the table: back to deny
 
 naro storage                       Naro Storage: on or off, limits, usage, today's operations, buckets
 naro storage enable                Turn it on: the project's R2 bucket, bound to the backend
+naro storage disable [--yes]       Turn it off and keep the files: Storage calls and file URLs answer 404 until enable (asks first)
 naro storage bucket create avatars --public --file-size-limit 5MiB --allowed-mime-types image/png,image/jpeg
 naro storage bucket update avatars --private | --file-size-limit none | --allowed-mime-types any
 naro storage bucket update docs --public   (asks first: anyone with an object's URL can download it)
@@ -202,10 +206,12 @@ naro storage bucket list | empty <name> | remove <name> [--empty]   (empty and r
 naro storage ls naro://avatars/u1 [--recursive] [--search <text>]   Names that start with <text>, ASCII case ignored
 naro storage cp ./me.png naro://avatars/u1/me.png [--upsert]   Up to the object limit, under 4 GiB (over 50 MiB in parts), with the service key
 naro storage cp naro://docs/team-1/plan.pdf ./                  Replaces a local file of the same name
+naro storage cp naro://docs/a.pdf naro://docs/b.pdf [--upsert]  Inside one bucket, up to 5 GiB − 5 MiB
+naro storage mv naro://docs/a.pdf naro://docs/old/a.pdf         Inside one bucket, up to 5 GiB − 5 MiB; never replaces
 naro storage rm naro://avatars/u1/old.png [--recursive]   (asks first)
 naro storage rm naro://avatars/u1/ --recursive   Everything under u1/; written u1, an object u1 too
 
-naro promote <deployment-id>       Publish a build to production
+naro promote <deployment-id> [--to <environment>]   Publish a build to production, or to an environment (0.20.0); says rebuild or reupload first, then asks
 naro rollback [deployment-id]      Back to the previous production build
 ```
 
@@ -326,10 +332,11 @@ 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 go with their table, as in Postgres and as `naro db push` does it,
-in the same migration: a drop removes the table's policies, and a rename
+in the same migration: a drop removes the table's policies, a rename
 moves them to the new name and rewrites the policies of other tables that
-read it (the command says which). A rename such a policy cannot follow is
-refused before anything runs. A table the command creates, or renames onto a
+read it, and `rename-column` rewrites every policy that reads the column,
+an owner rule's column included (the command says which). A rename such a
+policy cannot follow is refused before anything runs. A table the command creates, or renames onto a
 name, never inherits what an earlier table of that name left there: that is
 removed first. A change that fails changes no policy. Whatever a command
 removes it prints so it can be made again: as `CREATE POLICY` statements, which
@@ -588,8 +595,16 @@ 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.
+statements, statements that create, drop or rename a table, and statements
+that add a generated column take no `params` (`400 VALIDATION_FAILED`): write
+the values into the SQL.
+
+`ALTER TABLE t ADD COLUMN c … AS (…)` computes the generated column for the
+rows already in `t` right after it, as Postgres does: a row it cannot be
+computed for (`json_extract` over text that is not JSON) fails the request
+with SQLite's error (`400 DATABASE_QUERY_FAILED` `malformed JSON:
+SQLITE_ERROR`) and nothing changes. Fix those rows first, in an earlier
+statement.
 
 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
@@ -601,6 +616,11 @@ the `CREATE POLICY` statements again after the rename, in the same migration.
 A plain `ALTER TABLE a RENAME TO b` in a migration moves `a`'s policies to `b`,
 and a policy of another table that reads `a` is written to read `b` — do not
 create them again on `b`: a policy of the same name already there is refused.
+`ALTER TABLE t RENAME COLUMN c TO d` writes every policy that reads `t.c` —
+`t`'s own, another table's through a subquery, an owner rule's column — to
+read `t.d`, so each keeps reading the column it read, as in Postgres. A rename
+a policy cannot follow, such as giving a column the name of a dropped one that
+a policy still reads, is refused before anything runs.
 `naro db table`, the table editor and MCP do the same.
 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
@@ -826,6 +846,277 @@ An `--update-check` you give replaces the default: without
 
 ## Release notes
 
+### 0.20.0
+
+0.19.1 went out on 2026-10-24 without these.
+
+- `naro promote <deployment-id> --to <environment>` publishes a build to a
+  named environment. `--to` takes `production` (what no `--to` does) or an
+  environment's slug; an empty value, only blanks or `preview` fails before
+  any request with `VALIDATION_FAILED`
+  `--to must be production or an environment name.` The usage line is
+  `Usage: naro promote <deployment-id> [--to <environment>]`.
+  - Before it asks, it says what the promotion will do, from the control
+    plane's preview (`GET …/promote?target=`, which changes nothing):
+    `▸ rebuild: builds the same commit again with qa's variables` or
+    `▸ reupload: publishes the stored build`, then each warning as
+    `⚠ <warning>`. Without `--to` the same line is printed for production
+    (`… with production's variables`); that is one request more than 0.19.1
+    sent.
+  - A build moving between an environment and another surface (a preview or
+    production build to `qa`, a `qa` build to `staging` or to production) is
+    built again from its commit with the target's variables, and counts
+    against the plan's builds. Any other build is published as stored: one
+    promoted within its own surface, and a preview to production.
+  - The question is `Promote <id> to qa (<subdomain>--qa)?`; for production it
+    is the one it always was, `Promote <id> to production (<subdomain>)?`.
+    `--json` or no terminal without `--yes` still fails
+    `CONFIRMATION_REQUIRED`.
+  - Progress is `▸ promoting <id> to qa (rebuild)` (`(reupload)`), and the
+    result `✅ qa now serves a rebuild of <id>` or `✅ qa now serves <id>`; for
+    production `✅ Production now serves a rebuild of <id>` or, as before,
+    `✅ Production now serves <id>`. A rebuild is waited for up to 15 minutes
+    (a published build, 5 as before), and a failed one fails with its own
+    code and message. While a rebuild runs its build log lines print the way
+    `naro logs --type build --follow` prints them (`[BUILDING] next build`,
+    `[BUILDING] ✗ <error>`), on stderr with `--json` so stdout stays one
+    object; a published build prints none.
+  - `--json` adds `target` (`null` without `--to`) and `mode` (`rebuild` or
+    `reupload`): `{ deploymentId, sourceDeploymentId, projectId, target, mode, status, url }`.
+    `naro rollback`'s result gains `mode` too (as MCP's `rollback_deployment`
+    says it) and has no `target`: a rollback is always production's.
+  - `409 PROMOTE_NEEDS_GIT_SOURCE`
+    `Only deployments built from Git can be promoted to another environment. Deploy the code again with naro deploy instead.`
+    for a deployment `naro deploy` uploaded. This and every other refusal of
+    the preview (`404 ENVIRONMENT_NOT_FOUND` `Environment not found.`) stop
+    it in the control plane's words before it asks, and nothing is promoted.
+  - A rebuild checks out the pinned commit as a detached HEAD, not the
+    branch, so a build script that reads the branch name from git
+    (`git branch --show-current`, `git rev-parse --abbrev-ref HEAD`) sees
+    none.
+  - Against a control plane from before named environments 2a, which has no
+    preview (it answers 405) and whose promote ignores the target and
+    republishes to production, `--to <environment>` stops before it promotes
+    anything: `PROMOTE_TARGET_UNSUPPORTED`
+    `This control plane cannot promote to an environment yet. Deploy the latest web first, then try again.`
+    With no `--to` or `--to production` the 405 is ignored: no preview line,
+    and the promotion goes as it always did.
+- `--to` belongs to `naro promote`; `naro rollback` refuses it before any
+  request with `VALIDATION_FAILED`
+  `--to is for naro promote: naro rollback always rolls production back.`
+  (it always targets production, and ignoring `--to` would roll production
+  back for someone who named an environment).
+- Any other command given `--to` fails before any request with
+  `VALIDATION_FAILED` `--to is only for naro promote.`, so a flag a command
+  does not read is never dropped silently.
+- `naro promote` and `naro rollback` refuse `--env` and any word after the
+  deployment id before any request, with `VALIDATION_FAILED`
+  `--env is not an option of naro promote: use --to <environment>.`,
+  `--env is not an option of naro rollback: naro rollback always rolls production back.`
+  or the usage line (`Usage: naro promote <deployment-id> [--to <environment>]`,
+  `Usage: naro rollback [deployment-id]`), instead of acting on production for
+  someone who named an environment (`naro promote d1 --env qa --yes` and
+  `naro promote d1 qa --yes` promoted to production in 0.19.1).
+- A control plane with named environments 2a rebuilds a deployment of an
+  environment that is promoted to production, which it used to refuse with
+  `400 DEPLOYMENT_NOT_PROMOTABLE`. `naro promote <id>` says so before it
+  asks (`▸ rebuild: … with production's variables`) and waits up to 15
+  minutes; `naro rollback <id>` waits 15 minutes for such a rebuild too and
+  prints `✅ Production now serves a rebuild of <id>`. The build that
+  `naro rollback` picks on its own is never one.
+- `naro storage disable [--yes]` turns the project's Storage off and keeps
+  its files (Storage 3-1k). It asks first —
+  `Turn Storage off for this project? Its Storage calls and file URLs answer 404 until naro storage enable; buckets and files are kept.`
+  — and without a terminal or with `--json` only `--yes` answers it. The
+  backend is uploaded again without the bucket: the app's Storage calls and
+  file URLs answer `404 STORAGE_NOT_ENABLED` until `naro storage enable`
+  binds the same bucket again, and the buckets, the files and their storage
+  cost stay. To delete the files instead, remove the buckets with
+  `naro storage bucket remove <name> --empty` while Storage is on. Storage
+  that was never turned on prints `Storage is already off.` and changes
+  nothing; Storage that is already off is finished without asking again (a
+  turn-off whose upload stopped answers `BACKEND_PROVISION_FAILED` and says
+  to run it again).
+- `naro storage` says
+  `Storage:     off since <YYYY-MM-DD HH:MM> UTC — buckets and files are kept`
+  while it is off, with the buckets.
+- `naro storage ls`, `cp`, `mv` and `rm` read the Storage state before the
+  service key and stop with `STORAGE_OFF`
+  ``Storage is turned off for this project. Turn it on with `naro storage enable` first.``
+  while it is off. `naro storage bucket create` on Storage that is off gets
+  the control plane's `409 STORAGE_OFF`: it turns Storage on by itself only
+  when Storage was never on.
+- Published naro-cli 0.19.1 and earlier show Storage that is off as `off`
+  and pass the backend's `404 STORAGE_NOT_ENABLED` on from `ls`, `cp`,
+  `mv` and `rm`; their `bucket create` stops at `409 STORAGE_OFF` too.
+
+### 0.19.1
+
+0.19.0 went out on 2026-10-19 without these.
+
+- `naro git connect` says what to do when the link alone is not enough. The
+  control plane now records, for each team, only the repositories the people
+  who connected GitHub could read themselves (known-issues #232), and for an
+  account the team already holds it hands out an import link
+  (`/api/github/authorize`) rather than an install one. Without a terminal
+  or with `--json` the error reads
+  `Naro cannot reach <owner/repo> yet. Open <url> to give Naro access (if the repository is not among the ones the Naro GitHub App was granted on GitHub, add it there first), then run: naro git connect`
+  (0.19.0: `… Install the Naro GitHub App at <url>, then run: naro git connect`);
+  in a terminal, after `Opening <url>`, it adds
+  `If the repository is not among the ones the Naro GitHub App was granted on GitHub, add it there first.`
+- `deployDirectory`, the library export the MCP server uses, now refuses
+  `production: true` with any `environment` (`""` too):
+  `VALIDATION_FAILED` `environment and production cannot be used together.`,
+  the control plane's own words, before any value is read, asked for or
+  sent and before the deployment is created (the MCP `deploy` tool still
+  signs in and looks the team up first). 0.19.0 sent both and left the
+  refusal to the control plane (a caller passing `onMissingEnv` was asked
+  for missing values first); a control plane from before named
+  environments 1b-2 ignores `environment` and would deploy to production.
+- `naro env remove KEY` with no target, for a key only environments hold,
+  fails `ENV_NOT_FOUND`
+  `No KEY variable found outside named environments. Pass the environment to remove it: qa, staging.`
+  (`--json` details: `key`, `environments`) and still removes nothing. It
+  said `No KEY variable found.`, which a key no row has still gets.
+- `naro env import` refuses more before any request, in this order:
+  `Cannot read <file>.`, `Unclosed quote in <file> at line <n>.`,
+  `No variables found in <file>.`, `Invalid keys in <file>: A-B, 1X.`,
+  `ASSETS is reserved for the project's static files; pick another name.`
+  (the env route's words) or `Values over 5 KB in <file>: BIG.` An empty
+  value (`KEY=`) is uploaded like any other and listed as `(empty)`, so a
+  file `naro env pull` wrote for a project holding one imports back. Past
+  100 variables, and after you say yes, it reads the project's binding
+  names once (its storage bindings, `ASSETS`, and `DB` on a project with
+  the managed database) and fails `VALIDATION_FAILED`
+  `<KEY> is already used by a storage binding.` for the first key of the
+  file that is one, before the first request; the route refuses such a
+  key per request, which left the batches before it saved. Up to 100
+  variables ask nothing: one request is atomic on the server. Any other
+  refusal of a later request (a role, a race) still leaves the earlier
+  ones saved.
+- Dotenv files are read the way Next.js reads them (dotenv 16, what
+  `next dev` runs), for `naro env import` and for the values `naro deploy`
+  reads from `.env.local` once you agree, so the value saved is the one
+  your app saw locally. A value in `'`, `"` or `` ` `` runs to its closing
+  quote over several lines (a PEM key, as `.env.local` for Next.js often
+  holds one). Inside double quotes `\n` and `\r` are a line break and a
+  carriage return and every other backslash stays as written (`\\` is two,
+  `\"` a backslash and a quote); single quotes and backticks are read as
+  written. An unquoted value ends at its first `#` (`abc#def` is `abc`).
+  CRLF ends a line, inside quotes too. A quote that never closes stays in
+  the value, as Next.js reads it (`naro env import` refuses the file). Unlike
+  Next.js, `$VAR` and `${VAR}` are not expanded: a value built from another
+  variable is saved as written. Before, a multi-line value was cut to its
+  first line, opening quote included, and a base64 line ending in `=`
+  became a key of its own.
+- `naro env pull` writes each value so that dotenv and `naro env import`
+  read it back as it was (known-issues #224): bare when nothing in it needs
+  quoting, else in single quotes, in backticks when it holds `'`, or in
+  double quotes when it holds `'` and `` ` ``. A value with a carriage
+  return is written in double quotes with the carriage return as `\r`
+  (dotenv reads a carriage return written as is for a line break). A value
+  ending in a backslash is written bare. Next.js reads every value back as
+  it was except those with a `$`: it expands `$NAME` and `${NAME}`
+  (dotenv-expand) whatever the quotes, so a bcrypt hash `$2b$10$…` is cut
+  down (to `""`, or to what follows its first `.` or `/`) and `pa$$word` is
+  `pa$` for `next dev`, while `naro env import` reads them
+  unchanged. A value no dotenv line reads back fails before the overwrite
+  question and before anything is written, with `VALIDATION_FAILED`
+  ``Cannot write KEY1, KEY2 to a dotenv file: their values hold ', " and ` together.``
+  or, for the rarer carriage return beside `"`, backslash at the end, or
+  written-out `\n` beside `'` and `` ` ``,
+  `Cannot write KEY to a dotenv file: dotenv would not read their values back unchanged.`
+  followed by how to store such a value: without carriage returns or one of
+  the quote characters (a service-account JSON from a CRLF file:
+  `tr -d '\r' < sa.json | naro env add KEY`), or read it with
+  `naro env list --reveal` (`--json` details: `keys`). Before, it wrote such
+  values in double quotes with `\` and `"` escaped, which Next.js reads with
+  the backslashes: pull a file an earlier version wrote
+  again.
+- On a backend from before named policies, renaming a column answers
+  `409 BACKEND_OUTDATED` until `naro backend enable` runs, as creating,
+  dropping or renaming a table does — through `naro db table`,
+  `naro db push` and `naro db query` alike.
+- `naro db table rename-column`, and `ALTER TABLE … RENAME COLUMN` in
+  `naro db push` and `naro db query`, rewrite the Data API policies that read
+  the column, an owner rule's column included (known-issues #90): the
+  command prints
+  `⚠ Rewrote 1 policy that read members.user_id to read members.uid: docs.team.`.
+  Before, a policy reading the old name answered `500 POLICY_INVALID`, and
+  two columns swapped in one change left it reading the other column. The
+  warning that told you to run `naro policy set <table> --owner <new>` is
+  gone. A rename a policy cannot follow is refused before anything runs.
+- `naro db push` and `naro db reset` check a migration's `ALTER TABLE …
+RENAME` the way the control plane now reads it: a column rename whose
+  names cannot be read (`ALTER TABLE t RENAME COLUMN c TO` with nothing
+  after it, `t.c` for the column) is
+  `Statement <i> of <n>: the column name could not be read.` before anything
+  runs. Before, it reached D1 and failed as SQLite's syntax error.
+- `naro storage mv naro://<bucket>/<from> naro://<bucket>/<to>` moves an
+  object inside its bucket, and `naro storage cp` between two `naro://`
+  paths of one bucket copies one there (Storage 3-1i), each up to
+  5 GiB − 5 MiB. Over that the backend answers `413 OBJECT_TOO_LARGE`:
+  `Objects over 5,363,466,240 bytes (5 GiB − 5 MiB) cannot be copied or moved.`
+  A destination ending in `/`, or the bucket alone (`naro://docs`), takes the
+  object's name. `mv` never replaces an
+  object — a name that is taken answers `409 OBJECT_EXISTS`
+  `Object <path> already exists in bucket <bucket>. A move never replaces an object: remove it or choose another name.`
+  — and takes no `--upsert`, `--content-type` or `--cache-control`; `cp`
+  replaces one with `--upsert` and keeps the type and cache-control
+  (`--content-type` and `--cache-control` are refused).
+  Both refuse two buckets before any request:
+  `naro storage cp and mv work inside one bucket: both sides must be in naro://<bucket>.`
+  A name an upload or a download would refuse is refused before any request,
+  in the same words (`INVALID_PATH`
+  `The object path is not valid: it has an empty segment (//).`), and
+  `--recursive` is refused rather than dropped:
+  `naro storage mv takes no --recursive: it moves one object, naro://<bucket>/<path>. --recursive is for naro storage ls and rm.`
+  (`cp` between two `naro://` paths:
+  `A copy inside Storage takes no --recursive: it copies one object, naro://<bucket>/<path>. --recursive is for naro storage ls and rm.`).
+  A project backend from before this release answers them with
+  `BACKEND_OUTDATED`:
+  ``The project backend is older than this Storage command. Run `naro backend enable` to update it, then try again.``
+  `cp` between two `naro://` paths used to answer
+  `Copying inside Storage is not supported yet.` `--json` of a copy carries
+  `object` (`{ id, path, fullPath }`).
+- `naro db lint` measures a `storage.objects` move too (Storage 3-1i): a
+  move binds its new name at every read of the UPDATE policy's check, so a
+  set whose UPDATE check reads `name` many times can now be refused before
+  it is pushed, though an overwrite under it fits; the backend would answer
+  every move `500 POLICY_INVALID`. A copy's claim is an upload's and changes
+  nothing.
+- A table's policy can read `storage.objects` in a subquery (Storage 3-1j),
+  and so can a `realtime.messages` policy. `naro db push --dry-run`,
+  `naro db reset` and `naro policy create` take such a policy here, where
+  0.18.0 and 0.19.0 refused it locally, before changing anything, with
+  `A policy cannot read storage.objects in a subquery yet at character <n>.`,
+  and `naro db lint` no longer reports a stored one as `rls_policy_invalid`
+  (known-issues #227). `naro db reset` lists a stored one your files do not
+  make with the SQL that keeps it, where 0.18.0 and 0.19.0 showed
+  `-- Policy <p> on <t> cannot be read (…)` in its place (in `--json` too)
+  and, once confirmed, dropped it with no SQL to make it again. The backend reads it through the caller's
+  `storage.objects` policies and only files that are fully there (not still
+  uploading or being removed); write `bucket_id = '<bucket>'` in the
+  subquery (`bucket_id in ('a', 'b')` for several buckets). A check never
+  finds a new file being uploaded or copied, or a move's new name, as in
+  Postgres. A backend
+  from before Storage 3-1j answers such a policy with
+  `409 BACKEND_OUTDATED`:
+  ``storage.objects is not available on this backend yet. Run `naro backend enable` to update it.``
+  `naro db lint` measures those policies inside the table's statement, and
+  for a signed-in caller whose email is not verified too.
+- `naro db reset` refuses, before it drops anything (and on `--dry-run`
+  too), migration files the backend would stop at for Storage: a policy that
+  reads `storage.objects` in a subquery while the backend's ledger lacks
+  system migration 7 (it reads the ledger only when a file has one), and
+  a statement that needs `storage.objects` (CREATE POLICY, DROP POLICY without
+  IF EXISTS, the `naro:owner` COMMENT) on a backend from before Storage or a
+  project with none. It fails `BACKEND_OUTDATED`
+  ``0002_b.sql needs storage.objects (statement 2 of 2), which is not available on this backend yet, so the reset would stop there with the schema already dropped. Nothing was changed. Run `naro backend enable` to update it, then try again.``
+  (`--json` details: `migration`, `statement`). Before, the checks passed,
+  the schema was dropped and the re-apply stopped at the control plane's
+  `409 BACKEND_OUTDATED`, with `The schema is dropped and the re-apply stopped.`
+
 ### 0.19.0
 
 - `naro environments` manages a project's named environments, QA or staging
@@ -905,9 +1196,10 @@ An `--update-check` you give replaces the default: without
   deploy gets. A production deploy now lists a key set only for preview as
   missing, and a preview deploy one set only for production; an environment
   deploy counts the `all` values and that environment's own. On an
-  environment deploy, the values typed at the env prompt are saved for that
-  environment alone, so a developer, who cannot change `all`, has them saved
-  instead of listed under `⚠ skipped env:`. Production and preview deploys
+  environment deploy, the values the deploy reads from your dotenv file
+  (once you agree to it) are saved for that environment alone, so a
+  developer, who cannot change `all`, has them saved instead of listed under
+  `⚠ skipped env:`. Production and preview deploys
   still save them for `all`. The hint names the environment too:
   `npx naro-cli env add DATABASE_URL qa`.
 - `naro env add` and `naro env remove` take an environment's slug as the
@@ -948,6 +1240,11 @@ An `--update-check` you give replaces the default: without
   reads as `KEY`. Values with `\"` or `\\` inside double quotes are read as
   written, not unescaped, so a file `naro env pull` wrote with such a value
   does not import back as it was (known-issues #224).
+  A value in quotes that runs over several lines (a PEM key) is cut to
+  its first line, opening quote included, and a base64 line ending in
+  `=` becomes a key of its own, though the result says `✅ Imported`.
+  The values `naro deploy` reads from `.env.local` once you agree are cut
+  the same way, with no warning. Use 0.19.1 for such a file.
 - `naro env add` with a value typed at the prompt no longer loses it to a
   refusal. It reads the project first, so a `--project` of another team or
   of a deleted project fails `404 NOT_FOUND "Project not found."` before the
@@ -962,6 +1259,9 @@ An `--update-check` you give replaces the default: without
   another. A piped value works as before.
 - `naro usage` names a project that has moved to another team
   `Moved to another team <id>`. Before, it read `Deleted project <id>`.
+- `naro usage` prints `<1%` for a meter that is used but under 1% of its
+  limit (9,056 of 1,000,000 requests). Before, it printed `0%`, as if
+  nothing had been used.
 - `naro db reset` reads the migration files the way the control plane now
   runs them: `ALTER TABLE a RENAME TO b` moves `a`'s policies to `b`
   (known-issues #87), so a policy a renamed table took along is no longer
@@ -1369,7 +1669,7 @@ not fail but no strategy can ship it, `NO_DEPLOYMENT_STRATEGY`. Either way the m
 what each strategy failed at.
 
 `--yes` (or `-y`) suppresses every prompt — destructive actions
-(production rollback/promote, env/domain/environment removal, `naro env import`, turning off an environment's protection, database reset, backend key
+(production rollback, promote to production or to an environment, env/domain/environment removal, `naro env import`, turning off an environment's protection, database reset, backend key
 rotation, policy removal and drop, opening the preview with
 `naro protection disable`, replacing or removing the bypass secret) run
 unconfirmed, so use it deliberately in
@@ -1405,5 +1705,5 @@ credentials live in `~/.naro/credentials.json` (0600).
 | ------------------------ | ---------------------------------------------- |
 | `NARO_TOKEN`             | CI/agent access token (skips `naro login`)     |
 | `NARO_CONTROL_PLANE_URL` | Custom control plane (default https://naro.sh) |
-| `NARO_SERVICE_KEY`       | Service key for `naro storage ls\|cp\|rm`      |
+| `NARO_SERVICE_KEY`       | Service key for `naro storage ls\|cp\|mv\|rm`  |
 | `NARO_SUPABASE_URL/KEY`  | Auth backend override (self-hosted setups)     |