@ornncompute/cli 0.1.9 → 0.2.1

package/README.md

@@ -17,13 +17,23 @@ curl -fsSL https://compute.ornn.com/cli/install | sh
 
 The installer requires Node.js 20 or newer and npm. It installs `@ornncompute/cli`
 globally, exposes the `ornn` binary, adds the npm global bin directory to the
-user's shell profile when needed, and records the Ornn host that served it as
-`authBaseUrl` in `~/.config/ornn/config.json`, so `ornn login` reaches the right
-host from the shell that ran the installer. The
+user's shell profile when needed, and records the web browser handoff as
+`authBaseUrl` plus the API gateway as `apiBaseUrl` in
+`~/.config/ornn/config.json`. The
 installer prints a short Ornn Compute welcome banner and next steps; set
 `ORNN_INSTALL_BANNER=0` to skip it or `ORNN_INSTALL_ANIMATION=0` to keep it
 static.
 
+`ornn whoami`, `ornn logout`, and `ornn status` call the API gateway's
+`/v1/cli/session` and `/v1/cli/status` contracts. The gateway resolves the CLI
+bearer itself; it never trusts caller-supplied identity or authorization-admin
+headers. Logout asks the gateway to revoke the remote credential, then always
+clears the local bearer. If revocation cannot be confirmed, the CLI reports
+that the remote credential may remain active. Updated legacy installs that
+saved only a deployed web/auth
+origin map that known Ornn origin to its API gateway automatically; custom and
+localhost combined endpoints are left unchanged.
+
 ## Commands
 
 ```bash
@@ -35,14 +45,20 @@ ornn status [--json]
 ornn listings list [--gpu-type <type>] [--facility <name>] [--operator <name>] [--json]
 ornn listings show <listing-id> [--open] [--json]
 ornn buy <listing-id> [--no-open] [--json]
-ornn exchange create <listing-id> --gpu-count <n> --min-gpu-count <n> --start-date <yyyy-mm-dd> --end-date <yyyy-mm-dd> --price <usd> [--no-open] [--json]
+ornn exchange create <listing-id> --node-count <n> [--min-node-count <n>] --start-date <yyyy-mm-dd> --end-date <yyyy-mm-dd> --price <usd> [--no-open] [--json]
 ornn exchange list [--limit <1-500>] [--cursor <last-id>] [--json]
-ornn exchange show <bid-id> [--open] [--json]
-ornn exchange update <bid-id> --gpu-count <n> --min-gpu-count <n> --start-date <yyyy-mm-dd> --end-date <yyyy-mm-dd> --price <usd>
-ornn exchange withdraw <bid-id>
+ornn exchange show <exchange-id> [--open] [--json]
+ornn exchange update <exchange-id> --node-count <n> --min-node-count <n> --start-date <yyyy-mm-dd> --end-date <yyyy-mm-dd> --price <usd>
+ornn exchange withdraw <exchange-id>
+
+Bid create/update prefer `--node-count` and `--min-node-count`. Legacy
+`--gpu-count` and `--min-gpu-count` remain available; they convert using the
+listing's GPUs per node before the gateway translates the request to the
+Commerce bid contract.
+
 ornn gpus list [--status <status>] [--limit <1-500>] [--cursor <last-id>] [--json]
-ornn gpus show <reservation-id> [--open] [--json]
-ornn gpus checkout <reservation-id> [--no-open] [--json]
+ornn gpus show <gpu-id> [--open] [--json]
+ornn gpus checkout <gpu-id> [--no-open] [--json]
 ornn nodes list [--json]
 ornn nodes show <node-id> [--json]
 ornn nodes launch <reservation-id> --key <path|id|label> [--mode bare-metal|vm] [--username <name>] [--network public|private] [--storage-load-drive-id <id>] [--storage-save-drive-id <id>] [--wait] [--json]
@@ -55,15 +71,17 @@ ornn nodes keys attach <node-id> --key <path|id|label> [--json]
 ornn nodes keys list <node-id> [--json]
 ornn node health <node-id> [--json]
 ornn node diagnose <node-id> [--json]
+ornn node list [--operator <id-or-slug>] [--facility <id>] [--json]
+ornn node reboot <node-id> [--json]
+ornn node hard-reset <node-id> [--json]
+ornn node off-grid <node-id> [--json]
+ornn node on-grid <node-id> [--json]
+ornn node terminate <node-id> [--reason <text>] [--force] [--json]
+ornn node admin-key <node-id> [--generate] [--json]
 ornn node deenroll <node-id> [--reason <text>] [--keep-record] [--json]
-ornn fleet clean <ip>... --operator <id-or-slug> --ib-island <name> --identity-file <path> --dry-run [--policy <path>] [--policy-out <path>] [--ssh-user <non-root-linux-user>] [--json]
-ornn fleet clean <fleet-id> --identity-file <path> --dry-run [--policy <path>] [--policy-out <path>] [--json]
-ornn fleet clean <fleet-id> --identity-file <path> --confirm-clean <plan-hash> [--json]
-ornn fleet enroll <fleet-id> --identity-file <path> [--confirm-takeover <ip[,ip...]>] [--json]
-ornn fleet delete <fleet-id> --confirm-delete <fleet-id> [--json]
-ornn reservations commerce list --tenant <email-or-id> [--fleet <fleet-id>] [--json]
-ornn reservations commerce create --tenant <email> --listing <listing-id> --fleet <fleet-id> [--start-at <timestamp>] [--end-at <timestamp>] [--price-per-gpu-hour <rate>] [--json]
-ornn fleet deploy <fleet-id> --tenant <contact-email> [--user <email-or-id>] --commerce-reservation <id> [--network public|private] [--json]
+ornn reservations commerce list --tenant <email-or-id> [--listing <listing-id>] [--json]
+ornn reservations commerce create --tenant <email> --listing <listing-id> [--node-count <n>] [--node <node-id>] [--start-at <timestamp>] [--end-at <timestamp>] [--price-per-gpu-hour <rate>] [--json]
+ornn reservations deploy <node-id> --target-tenant <id> --commerce-reservation <id> [--target-user <id>] [--network public|private] [--json]
 ornn ssh <node-or-reservation-id> [--print] [--identity-file <path>] [--user <name>] [--json]
 ornn metrics nodes [--json]
 ornn metrics node <node-id> [--json]
@@ -106,10 +124,13 @@ ornn storage volumes create --name <name> [--source <drive-id>] [--json]
 ornn storage volumes refresh <drive-id> [--json]
 ornn storage volumes clear <drive-id> [--json]
 ornn storage volumes delete <drive-id> [--json]
+ornn storage files ls <drive-id> [--prefix <path>] [--json]
 ornn storage files upload <drive-id> <local-file> [--destination <path>] [--content-type <type>] [--json]
-ornn storage deploy <drive-id> --reservation <reservation-id> [--all-nodes] [--mount-path <path>] [--read-only|--read-write] [--json]
-ornn storage deploy status --reservation <reservation-id> [--json]
-ornn storage undeploy --reservation <reservation-id> [--json]
+ornn storage files download <drive-id> <remote-path> [--output <path>] [--json]
+ornn storage targets [--json]
+ornn storage deploy <drive-id> --reservation <reservation-id> [--all-nodes] [--read-only|--read-write] [--json]
+ornn storage status --reservation <reservation-id> [--watch] [--interval <seconds>] [--timeout <seconds>] [--json]
+ornn storage detach --reservation <reservation-id> [--json]
 ornn storage buckets list [--json]
 ornn storage buckets show <drive-id> [--json]
 ornn storage buckets connect gcs|s3|r2 --bucket <bucket>|--url <url> [--name <name>] [--prefix <prefix>] [--region <region>] [--account-id <id>|--endpoint-url <url>] [--access-key-id <id> --secret-access-key-file <path>] [--read-only|--read-write] [--verify] [--json]
@@ -117,26 +138,26 @@ ornn storage buckets update-credentials <drive-id> --access-key-id <id> --secret
 ornn storage buckets verify <drive-id> [--json]
 ornn storage buckets disconnect <drive-id> [--json]
 ornn keys list [--json]
-ornn keys add [<public-key-file>] [--public-key <key>] [--label <label>] [--json]
+ornn keys add [<public-key-file>] --label <label> [--public-key <key>] [--json]
 ornn keys delete <key-id> [--json]
 ornn access show <reservation-id> [--json]
 ornn access activate <reservation-id> --key <path|id|label> [--mode bare-metal|vm] [--username <name>] [--network public|private] [--storage-load-drive-id <id>] [--storage-save-drive-id <id>] [--wait] [--no-open] [--json]
 ornn access switch <reservation-id> --network public|private --key <path|id|label> [--mode bare-metal|vm] [--username <name>] [--wait] [--json]
 ornn access push-keys <reservation-id> --ssh-key-id <id> [--json]
 ornn access keys list <reservation-id> [--json]
-ornn access keys add <reservation-id> --public-key <key> [--label <label>] [--json]
-ornn access keys add <reservation-id> --public-key-file <path> [--label <label>] [--json]
+ornn access keys add <reservation-id> --public-key <key> --label <label> [--json]
+ornn access keys add <reservation-id> --public-key-file <path> --label <label> [--json]
 ornn access keys push <reservation-id> --ssh-key-id <id> [--json]
 ornn access keys status <reservation-id> [--json]
 ornn ssh-keys list [--json]
-ornn ssh-keys add --public-key <key> [--label <label>] [--json]
-ornn ssh-keys add --public-key-file <path> [--label <label>] [--json]
+ornn ssh-keys add --public-key <key> --label <label> [--json]
+ornn ssh-keys add --public-key-file <path> --label <label> [--json]
 ornn ssh-keys delete <key-id> [--json]
 ornn billing summary [--json]
 ornn billing invoices [--json]
 ornn billing showback --start <yyyy-mm-dd> --end <yyyy-mm-dd> [--json]
 ornn billing open [--no-open] [--json]
-ornn api <get|post|patch|put|delete> <compute-path> [--data <json>] [--raw]
+ornn api <get|post|patch|put|delete> <allowlisted-path> [--data <json>] [--raw]
 ornn logout
 ```
 
@@ -145,11 +166,37 @@ active VM or Bare Metal machines, adding the key automatically queues the
 current user's complete reservation key set on those machines. Use
 `ornn access keys push` to explicitly re-sync keys that are already attached.
 
-`ornn storage deploy status` prints reconciled object and byte progress once the
+`ornn storage status` prints reconciled object and byte progress once the
 managed transfer has reported progress, plus the number of target nodes that
 have acknowledged the mount. Internal placement bucket details are not shown.
 AWS S3 and external GCS sources use the managed transfer path. Cloudflare R2
 buckets can be connected and verified, but deployment support is coming soon.
+The mount path is always `/home/tenant/volume`; node agents resolve `tenant` to the
+machine's real Linux user at mount time.
+
+`ornn storage status --watch` polls the same status endpoint on an interval
+(10 seconds by default) instead of returning after a single check, re-printing
+the human summary on each poll. It exits 0 once the attachment is attached and
+every scoped node has mounted, exits 1 with an error on stderr if the
+attachment detaches before that happens, and exits 1 with a timeout message on
+stderr after 1800 seconds (or the value passed to `--timeout`) without
+success. Use `--interval <seconds>` to change the poll cadence. `--interval`
+and `--timeout` require `--watch`. Combined with `--json`, only a single JSON
+payload is printed, at the end, instead of a stream of per-poll output.
+
+`ornn storage detach` detaches the drive from the reservation's storage
+attachment. Detach is origin-aware: if your reservation individually joined a
+drive that another reservation already had attached, detach releases only
+your reservation's own mount and leaves the rest of the attachment alone. If
+your reservation started the attachment, or it is the last member still
+joined, detach flushes and unmounts every node before releasing the whole
+attachment. A node that fails to unmount is left in a retryable state with
+the reported error; run `ornn storage detach` again with the same
+`--reservation` to retry it. A reservation that detached from a shared drive
+can rejoin it later by running `ornn storage deploy` again. Mounted state is
+tracked per node, not by attachment membership, so `ornn storage status`
+can show one node as unmounted while the rest of the attachment
+stays mounted.
 
 `ornn storage files upload` adds a file to the drive's current colocated copy.
 You can upload while a direct FUSE mount is active; every mounted node sees the
@@ -159,27 +206,31 @@ same mount out across every compatible node in the node group. Avoid writing
 the same file path concurrently from multiple nodes because object storage is
 not a POSIX shared filesystem.
 
+`ornn storage files download` streams a single object from the drive straight
+to disk. Pass `--output <path>` to control where it's written; without it, the
+file is saved under the remote path's basename in the current directory.
+
 For a connected bucket, deploy once before uploading. The first deploy imports
 the source into an Ornn-managed colocated working copy. That copy remains the
 drive's durable data when you unmount, detach, or mount it elsewhere. Ornn
 does not write changes back to the original connected bucket.
 
 UI aliases are first-class in the CLI: `listings` maps to the older
-`availability` command, `exchange` maps to `bid`, and `gpus` maps to
+`availability` command, `exchange` maps to `bid`, `gpus` maps to
 `reservations`. The older command names remain available for scripts.
 Bid and reservation list commands return a bounded page (500 rows by default);
-use `--limit` and `--cursor` to traverse older history. Pass the final row ID
-from one page as the next page's cursor. `show` and `checkout`
+use `--limit`, `--json`, and the response's opaque `next_cursor` to traverse
+older history. Replay that cursor exactly; it is not an item ID. `show` and `checkout`
 use exact tenant-owned item lookups, so they are not limited to the current page.
 
 ## Operator commands
 
 The `ornn node` commands are for Ornn operators and reviewers, not tenants. They
-wrap internal-reviewer-gated compute endpoints. Prefer `ornn login` as an
-internal-allowed staff user (`ORNN_AUTH_BASE_URL`); the CLI calls
-`/api/cli/operator/*` and the web server attaches the review secret — it never
-downloads to the laptop. Optionally set `ORNN_INTERNAL_REVIEW_SECRET` plus
-`ORNN_COMPUTE_BASE_URL` for direct compute access (CI / break-glass):
+wrap internal-reviewer-gated endpoints. Run `ornn login` as an
+internal-allowed staff user. The CLI calls `/v1/cli/operator/*`; the gateway
+resolves the user bearer and applies staff authorization without downloading a
+review or service secret to the laptop. There is no direct-service break-glass
+path.
 
 - `ornn node health <node-id>` shows launch readiness (ready/blocked plus
   reasons), passive fault reasons, and the last validation status.
@@ -199,17 +250,16 @@ downloads to the laptop. Optionally set `ORNN_INTERNAL_REVIEW_SECRET` plus
 - `ornn node terminate <node-id> [--reason <text>] [--force]` best-effort cleans
   the host, removes the Ornn agent, and hard-deletes the node record from the
   platform. It does not return the host to a tenant.
-- `ornn node admin-key <node-id>` prints the Ornn admin SSH keypair for the node
-  (including the private key) so an operator can SSH into the host. Treat the
-  output as a secret.
-- `ornn node deenroll <node-id>` removes a node from the environment: it first
-  gracefully terminates the enrollment (revokes the node claim, retires any
-  listing, and queues the node-agent self-uninstall packet), then dereferences
-  (hard-deletes) the `gpu_nodes` record so nothing lingers. Pass `--keep-record`
-  to stop after termination and leave the row in a `deenrolled` state, or
-  `--reason <text>` to annotate the audit log. The command is idempotent: an
-  already-removed node reports success. Terminate is forced by default so a
-  dead/unreachable node does not block on workload drain.
+- `ornn node admin-key <node-id> [--generate]` prints the Ornn admin SSH keypair
+  for the node (including the private key) so an operator can SSH into the host.
+  `--generate` always mints a new pair, stores it, and installs the public key
+  on the live host. Treat the output as a secret.
+- `ornn node deenroll <node-id>` gracefully terminates the enrollment (revokes
+  the node claim, retires any listing, and queues the node-agent self-uninstall
+  packet) while retaining the node row as a `deenrolled` audit record. The
+  legacy `--keep-record` flag remains accepted but is now a no-op. Pass
+  `--reason <text>` to annotate the audit log. The command is idempotent, and
+  termination is forced by default so an unreachable node does not block drain.
 
 The operator resource commands share the same reviewer auth:
 
@@ -223,136 +273,51 @@ The operator resource commands share the same reviewer auth:
   command.
 - `ornn tokens revoke <token-id>` revokes an enrollment token.
 
-Fleet handoff is an ordered, Compute-backed workflow:
-
-- Before first contact, independently verify each host key and add it to the
-  operator's SSH `known_hosts`; fleet SSH uses strict host-key checking and will
-  not trust a key first presented during cleanup.
-- `fleet clean ... --dry-run` tries `ubuntu`, `admin`, then `ornn`, or the
-  explicit non-root account supplied with `--ssh-user`. It binds the
-  inventory to the host's hardware identity, records the plan in Compute, and
-  writes an editable mode-`0600` policy beside the local fleet manifest (or to
-  `--policy-out`). Inventory covers accounts and orphan homes, authorized SSH
-  keys, tenant/log/temp/platform paths, workload and listener processes, GPU
-  consumers, custom systemd services, Docker/Podman objects and bind-mount
-  dependencies, and every block drive. Each resource advertises its own valid
-  actions. Suggestions are never applied silently: unresolved choices and
-  conflicts are recorded as plan data, so edit the policy and re-run the same
-  fleet with `--policy`; planning is not terminalized just because a choice is
-  needed. `--source-user` and `--preserve-user` remain legacy user-only
-  shortcuts and cannot be mixed with a policy file.
-  Coverage gates also inventory listeners, GPU and container-runtime visibility,
-  non-block mounts, advanced SSH sources, filesystem scope, root-owned workloads,
-  network state, groups/sudo, IPC, swap/RAM, and active block stacks. A verified
-  gate is kept automatically. A present or uninspectable gate must be explicitly
-  ignored with a reason, so the receipt exposes the excluded scope.
-- `fleet clean <fleet-id> ... --confirm-clean <plan-hash>` is shown only after
-  every choice is resolved. Execution rechecks hardware and resource identity,
-  runs an idempotent per-resource journal, preserves the management SSH key,
-  enforces key-only SSH, and returns exact deleted, preserved, exception, and
-  drive-assurance evidence. `ignore` requires a reason and produces
-  `clean_with_exceptions`; it is never reported as residue-free deletion.
-  Kept files and directories are content-hashed; process identity, container
-  replacement state, and exact drive topology are rechecked. Data-drive actions
-  are selectable: `logical_clean`, `discard`, `sanitize`, or
-  `reformat`. The system drive and drives without a unique serial/WWN are
-  locked to keep/ignore for in-band cleanup. Logical clean is offered only when
-  every filesystem in the approved topology is mounted and can be emptied and
-  verified; it never substitutes `wipefs` for data deletion. Discard and NVMe
-  sanitize require device-reported support, and strong actions refuse active or
-  unverified block stacks. `sanitize` requires NVMe plus
-  controller-reported completion. Logical cleanup, discard, and reformat are
-  not certified physical-media erasure, and the system drive requires an
-  out-of-band reimage for that assurance.
-  If the local SSH command times out while a long device operation is still in
-  progress, the recorded run remains resumable; re-run the same
-  `--confirm-clean <plan-hash>` command instead of creating a different plan.
-  Plans created by a pre-v7 runner must be replanned with `--dry-run` before
-  approval. This keeps newly discovered resources bound to a fresh reviewed
-  hash instead of adapting a legacy account-only plan during execution.
-
-In the generated policy, change only `action`, plus `reason` for `ignore` or
-`replacement` for `replace`; keep each generated `identity_hash` intact. `keep`
-leaves a resource running, `stop_keep` stops but retains it, `stop` terminates a
-process, `delete` removes it, `restart` restarts a service, and `replace`
-recreates a container from the supplied image/name/network/command/labels/mounts
-specification. The generated `suggested_action` is review guidance, not an
-automatic decision. Do not put secrets in replacement commands or labels; use
-the platform secret manager or a reviewed secret mount.
-
-- `fleet enroll <fleet-id>` refuses nodes without successful cleanup proof,
-  live-revalidates each receipt under the current enrollment attempt, then
-  issues and revokes one cleanup- and attempt-bound token per host, installs the
-  agent,
-  assigns the IB island, verifies the same management account still has
-  key-based SSH and passwordless sudo, and records the resulting GPU node IDs
-  in Compute. A private executor credential prevents two CLIs from sharing an
-  active lease. Retries reconcile nodes already registered by the same attempt
-  before rerunning cleanup or installation. Generic enrollment tokens retain
-  the legacy enrollment sanitizer.
-- `fleet delete <fleet-id> --confirm-delete <fleet-id>` hard-deletes only an
-  abandoned cleanup plan or an unassigned legacy enrollment record. It saves a
-  local audit manifest first and refuses any Commerce/tenant/deployment link,
-  active enrollment, assigned GPU node, or completed/running cleanup evidence.
-  It never deletes the linked GPU-node records.
+Staff Commerce reservations are listing-backed, not fleet-backed:
+
 - `reservations commerce create --tenant <email> --listing <listing-id>
---fleet <fleet-id>` creates and activates the tenant's Commerce reservation.
-  GPU count comes from the enrolled fleet; start, end, and hourly rate default
-  from the listing. Start and end overrides must remain inside the listing's
-  allowed window; the hourly rate can also be overridden explicitly.
-- `reservations commerce list --tenant <email-or-id> [--fleet <fleet-id>]`
-  lists active reservations in their live window; with `--fleet`, it returns
-  only reservations whose listing exactly matches that fleet's operator,
-  facility, GPU model, per-node size, and total GPU count.
-- `fleet deploy <fleet-id> --tenant <contact-email>
-[--user <email-or-id>] --commerce-reservation <id>` requires a live,
-  tenant-owned Commerce reservation whose listing exactly matches the fleet.
-  The user defaults to the tenant's primary administrator. Deployment succeeds
-  only after that user's SSH access and passwordless sudo are ready on every
-  node; Commerce is stamped only after the entire fleet reports deployed. A
-  Commerce reservation can be linked to only one fleet.
-
-Compute Postgres is authoritative. The mode-0600 files under
-`~/.config/ornn/fleets/` include a short-lived enrollment resume credential;
-treat them as sensitive and do not copy them into tickets or source control.
-Cleanup proves “no
-observable residue under the verification scope,” not certified physical-media
-erasure. Root is never the preserved management account. `--confirm-takeover`
-names only fleet IPs whose existing node claims may be replaced. The IB-island
-is a locality label, not cluster creation. Test scheduling remains a separate
-control-plane policy.
+[--node-count <n>] [--node <node-id>]` creates and activates the tenant's
+  Commerce reservation. Node count defaults to the listing capacity; start,
+  end, and hourly rate default from the listing. Optional `--node` values pin
+  specific catalog ids. Start and end overrides must remain inside the
+  listing's allowed window; the hourly rate can also be overridden explicitly.
+- `reservations commerce list --tenant <email-or-id> [--listing <listing-id>]`
+  lists active reservations in their live window, optionally filtered to one
+  listing.
 
 Reservation lifecycle verbs also run under the operator surface:
 
 - `ornn reservations commerce create|list` creates or discovers a validated
-  Commerce reservation for an enrolled fleet. These actions require a staff
-  `ornn login`; the direct review-secret path cannot bypass Web validation.
-- `ornn reservations withdraw <reservation-id>` withdraws a reservation's
-  acceptance, returning the node(s) to tenant inventory.
+  Commerce reservation from a listing. These actions require a staff
+  `ornn login` session; the gateway `/v1/cli/operator/*` allowlist enforces
+  staff authorization — there is no review-secret break-glass that bypasses
+  that gate.
 - `ornn reservations transfer <reservation-id> --target-tenant <id>
 [--target-user <id>] [--node <id>] [--strategy reject|park] [--confirm]`
   transfers a reservation to another tenant.
 - `ornn reservations deploy <node-id> --target-tenant <id>
 --commerce-reservation <id> [--target-user <id>] [--network public|private]`
-  deploys one node only after Web verifies that the live tenant-owned Commerce
-  reservation and listing match that node.
+  deploys one node only after the gateway operator contract verifies that the
+  live tenant-owned Commerce reservation and listing match that node.
 
-The tenant `ornn reservations list|show|checkout` verbs still use the tenant CLI
-login and `/api/cli` proxy. Staff Commerce actions use the Web operator proxy;
-`withdraw|transfer|deploy` retain the operator path above.
+The tenant `ornn reservations list|show|checkout` verbs use the tenant CLI
+login and `/v1/cli/compute` gateway contract. Staff Commerce actions use the
+gateway operator contract; `transfer|deploy` retain the operator path above.
 
 Staff happy path:
 
-- `ORNN_AUTH_BASE_URL` — web/auth origin
+- `ORNN_AUTH_BASE_URL` — web/browser handoff origin
+- `ORNN_API_BASE_URL` — API gateway origin
 - `ornn login` as a user allowed by `INTERNAL_ALLOWED_*` on that environment
 
-Optional direct compute override:
+Optional installer gateway base for `ornn tokens create` install one-liners:
 
-- `ORNN_COMPUTE_BASE_URL` — compute origin (for example `http://localhost:8000`)
-- `ORNN_INTERNAL_REVIEW_SECRET` — reviewer secret (`X-Internal-Review-Secret`)
+- `ORNN_INSTALLER_URL` - base serving `enrollment/install` (for deployed
+  gateways, `https://<gateway>/v1/orchestrator`), falling back to
+  `NEXT_PUBLIC_INSTALLER_URL`. Unset prints the token without an install command.
 
-Without a staff login session or the review-secret pair, operator commands fail
-with a clear error before making a network request.
+Without a staff login session, operator commands fail with a clear error before
+making a network request.
 
 Commands print concise human-readable output by default. Use `--json` on
 read/show/list commands and transaction handoffs when you need structured
@@ -365,7 +330,7 @@ cannot open a browser, copy the printed URL into any browser and sign in there;
 the terminal keeps polling until the login is approved or expires.
 
 Run `ornn --help` for the full command list and `ornn api` for the
-allowlisted compute API escape hatch.
+allowlisted gateway API escape hatch.
 
 WireGuard client configs use the current tenant-scoped `/nodes` routes:
 
@@ -376,10 +341,21 @@ ornn api post /nodes/reservations/<reservation-id>/vpn/peers \
 ornn api delete /nodes/reservations/<reservation-id>/vpn/peers/<peer-id> --raw
 ```
 
-The legacy `/standalone-vms/*` prefix is not exposed through the CLI proxy.
+The legacy `/standalone-vms/*` prefix is not exposed through the gateway
+`/v1/cli/*` allowlist.
 Deleting a peer is the supported way to replace its key; switching a node
 between Public and Private VPN preserves the peer.
 
 ## Updating
 
 The CLI checks the npm registry for a newer version at most once per day and prints a one-line notice on stderr when one exists. Run `ornn update` to install it (the command detects npm, pnpm, yarn, or bun installs). The check is skipped in CI and non-interactive shells.
+
+## Deployment
+
+`deploy-cli-pipeline.yml` publishes `@ornncompute/cli` from `main`. Staging
+publishes the package.json version to the npm `next` dist-tag; production then
+promotes that same version to `latest`. Manual rolls use
+`deploy-cli-service.yml`. Runtime changes under `apps/cli` or
+`packages/capabilities` must bump `apps/cli/package.json` so npm receives a
+new release. Re-running the pipeline is idempotent when that version is
+already published.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ornncompute/cli",
-  "version": "0.1.9",
+  "version": "0.2.1",
   "description": "Command-line interface for Ornn compute access workflows.",
   "type": "module",
   "bin": {
@@ -9,6 +9,7 @@
   "files": [
     "bin",
     "src",
+    "vendor",
     "README.md"
   ],
   "homepage": "https://compute.ornn.com",
@@ -26,7 +27,11 @@
     "registry": "https://registry.npmjs.org/"
   },
   "scripts": {
-    "test": "node --test"
+    "test": "node --test",
+    "prepack": "node scripts/vendor-capabilities.mjs"
+  },
+  "devDependencies": {
+    "@ornn/capabilities": "0.1.0"
   },
   "engines": {
     "node": ">=20"