From 29278d66420a6d6cf47113f9366e202c81c71f8f Mon Sep 17 00:00:00 2001 From: Brian Miller Date: Sat, 22 Aug 2026 21:37:15 +0000 Subject: [PATCH] docs: state the CLI's real verbs on nats-account and nebula-ca The entity table listed both as `ls / get`. Both specs in cmd/entity.go declare `ls, get, update, edit` -- the commands exist, they are just rejected for every tenant role by the update rule, which is a different statement from "the CLI does not offer them". The distinction matters to the reader the table is for: someone scripting against `stone` who sees `ls / get` concludes the command is absent and looks for another way in, when what they will actually get is a 404 from an authorization rule. The prose now says which it is, and keeps the part that was already right: neither entity can be created or deleted by hand, and signing keys go through the dedicated route. Found while writing the CLI's schema-drift tests (stone-age-io/stone-cli#4), which read the same spec table this page describes. Co-Authored-By: Claude Opus 5 (1M context) --- docs/stone-cli.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/stone-cli.md b/docs/stone-cli.md index 19bac94..e72d4f5 100644 --- a/docs/stone-cli.md +++ b/docs/stone-cli.md @@ -152,10 +152,10 @@ The CLI exposes typed CRUD over the same Control Plane collections the console m | `nebula-network` | yes | `name` | full | owner/admin — including reads | | `nebula-host` | yes | `hostname` | full | owner/admin — including reads | | `leaf-node` | yes | `code` | full | read: any · write: owner/admin | -| `nats-account` | yes | `name` | `ls / get` | read: any · **all writes: operator** · signing keys: owner/admin via route | -| `nebula-ca` | yes | `name` | `ls / get` | read: any · **all writes: operator** · no rotation trigger exists | +| `nats-account` | yes | `name` | `ls / get / update / edit` | read: any · **all writes: operator** · signing keys: owner/admin via route | +| `nebula-ca` | yes | `name` | `ls / get / update / edit` | read: any · **all writes: operator** · no rotation trigger exists | -"Full" verbs are `ls / get / create / update / delete / edit`. The two limited entities (`nats-account`, `nebula-ca`) are provisioned automatically by the platform when you create an Organization, and both are now **read-only to every tenant role** — `update` requires a platform Operator, and neither can be created or deleted by hand. An owner or admin manages the account's signing keys through `POST /api/org/nats-account/keys` instead (see [Authorization §4.1](./authorization.md#41-account-signing-keys)); `nebula_ca` has no rotation trigger, so rolling a CA is an operator operation. +"Full" verbs are `ls / get / create / update / delete / edit`. The two limited entities (`nats-account`, `nebula-ca`) are provisioned automatically by the platform when you create an Organization, so neither can be created or deleted by hand. The CLI does expose `update` and `edit` on both — they exist for a platform **Operator**, not as a tenant path — but both are **read-only to every tenant role**, so an owner or admin calling them gets a 404 from the update rule rather than a change. An owner or admin manages the account's signing keys through `POST /api/org/nats-account/keys` instead (see [Authorization §4.1](./authorization.md#41-account-signing-keys)); `nebula_ca` has no rotation trigger, so rolling a CA is an operator operation. In the **Role required** column, *any* means any role in the current organization including `dashboard`, the least privileged one, and *member+* means `member`, `admin`, or `owner`. Three consequences worth internalizing before you script against the CLI: