Command surface¶
Brama's invocable surface is larger than its command tree, because Brama Desktop, the
account routes and the agent routes reach the same subscription operations over HTTP
that an operator reaches over argv. This page measures both at one named
revision, names the capabilities that replace the verbs which accumulated one per
incident, and states the order in which the replacement lands.
What was measured, and with what¶
Revision 76b7b987b33f950db9c6540d8a001b184d93b539 of
wisent-ai/brama, crate version
0.2.78, measured on darwin-arm64. The
binary states its own revision, so the numbers below are bound to a build and not to
prose:
git fetch origin && git rev-parse origin/main
BRAMA_SOURCE_REVISION=$(git rev-parse origin/main) BRAMA_BUILD_PLATFORM=darwin-arm64 \
cargo build --release --bin brama
target/release/brama version
{"product":"brama","version":"0.2.78","source_revision":"76b7b987b33f950db9c6540d8a001b184d93b539","platform":"darwin-arm64","built_at":"not-recorded"}
BRAMA_BIN=target/release/brama node --test tests/docs/cli-commands.probierz.spec.mjs
That last command is the measurement. It walks brama help from the root to
every leaf, reads one invocation per HTTP method per registered path out of the router in
src/core/server.rs, and reads the site's own rewrite table in
vercel-ingress/vercel.json to decide which of those invocations resolve to a
published page. It writes nothing. A number on this page that the command does not print
does not belong on this page.
The counts¶
39 leaf invocations in 6 groups. 13 of them are command-tree leaves in 2 command groups carrying 42 options between them; the other 26 are HTTP method invocations over 22 registered paths.
| Group | Leaf invocations |
|---|---|
/v1/admin | 12 |
brama (root) | 12 |
/v1 | 10 |
/ (public and process) | 3 |
brama subscription | 2 |
/v1/account | 1 |
Two families have landed. It was 50 invocations in 7 groups at
070275a036f35130918948b66f4be8b7e26fcf50 and 42 in 6 at
15c27474b3a870e1a399697068e2b96f4e72d8dd. The eleven the subscription pool
replaced and the four the plan-usage capability replaced are gone from the router, the
command tree and this site: two invocations stand where eleven did,
brama subscriptions list no longer parses, and one
POST /v1/plan-usage stands where four per-audience refreshes did.
/v1/account is down to its last invocation, and every route that carried an
audience in its own path is now either a capability or one of the three families still to
land.
/v1/admin is the largest group and it is the one that grew per incident:
every diagnostic and repair reached for during an outage was added beside the last one
rather than in place of it. The command tree is small by comparison, and its duplication
shows up in options instead — brama onboard carries 6
--adopt-* options, which is the whole brama adopt command
spelled a second time at a second entry point.
The families, and what replaces each¶
A family here is one operation spelled more than once because a different audience asked for it. 15 of the 39 invocations still fall into three unlanded families, and two are done. Each capability is named by Brama's own vocabulary, and each reads a declaration rather than taking an operator's word for the current state.
| Family | Count | Capability that replaces it | Declaration it reads |
|---|---|---|---|
| subscription inventory, once per audience | 11 → 0, landed | the subscription pool (GET and POST /v1/subscription-pool) | the vault entitlement declaration: brama:subscription with its brama:agent, brama:provider and brama:id tags |
| plan-usage reading, once per audience | 4 → 0, landed | subscription plan usage (POST /v1/plan-usage) | the usage ledger and the provider's own usage report |
| credential repair, once per incident | 7 | subscription credential state | the usage ledger's recorded credential state and the journal's subscription_refresh records |
| route adoption, once per entry point | 5 | the alias registry | the route registry BRAMA_INFERENCE_ROUTES_FILE names and the launcher table BRAMA_MODEL_ALIASES |
| provider credential administration | 3 | capability redemption at final use | the provider capability declaration this installation was given |
Subscription inventory (11 → 0, landed). It was
brama subscriptions list;
GET, POST and DELETE /v1/subscriptions/:agent_id;
GET and POST /v1/account/subscriptions;
DELETE /v1/account/subscriptions/:subscription_id;
GET and POST /v1/admin/subscriptions/:agent_id;
DELETE /v1/admin/subscriptions/:agent_id/:subscription_id;
GET /v1/admin/subscription-pool. Three audiences, one question: which
subscriptions exist and who owns them. The pool capability now answers it once from the
vault declaration over GET
and POST /v1/subscription-pool and
brama subscription list, scoping the
answer by the caller's proven identity, which is where ownership already lives
(entitlement). All eleven were deleted in the
same change: their routes, their handlers, their tests, the desktop calls that reached
them and their paragraphs on this site. A signed agent, an account holder and this
installation's own console get one answer narrowed by who they are.
Credential repair (8).
brama subscription refresh; brama subscription login (one verb
and one route since the former manual sign-in became its --by hand and the
route's "by": "hand"; held, import, sync and
/v1/admin/subscription-pool/grant were removed in 0.4.4x);
POST /v1/account/subscription-sign-in/:subscription_id;
POST /v1/admin/subscription-sign-in/:agent_id/:subscription_id;
POST /v1/admin/subscriptions/:agent_id/:subscription_id/probe;
POST /v1/admin/subscription-pool/sign-in;
POST /v1/admin/subscription-pool/sign-in/:sign_in_id;
POST /v1/admin/subscription-pool/refresh. Each of these was added because
one incident needed one repair, and each requires the operator to already know which
repair applies. The ledger records why a credential is unusable —
needs_reauthorization, a recorded quota block, a definitive refusal — so the
capability reads that state and performs the repair the state names, instead of offering
one verb per guess (capability,
runbook).
Route adoption (5). brama adopt;
PUT and DELETE /v1/admin/routes;
POST /v1/admin/configuration-adoption/preview;
POST /v1/admin/configuration-adoption/apply, plus the 6
--adopt-* options on brama onboard. Reviewing and adopting
aliases is one operation with one declaration behind it; it currently has three entry
points and two implementations of the same review
(alias).
Plan-usage reading (4 → 0, landed). It was
POST /v1/subscription-usage/:agent_id;
POST /v1/account/subscription-usage;
POST /v1/admin/subscription-usage/:agent_id;
POST /v1/admin/subscription-pool/usage. One sweep, one ledger, four ways to
ask for it. The capability answers it once over
POST /v1/plan-usage, reading
the usage ledger and each provider's own usage report through the sweep's own bounded
operation, and narrowing the answer by the identity the caller proved — the same
PoolScope the pool resolves, so this gateway has one scoping decision rather
than one per family (entitlement). All four were
deleted in the same change: their routes, their handlers, the desktop calls that reached
them and their paragraphs on this site. Three of them also named an audience in the path
while none of them was reachable by a model-scoped bearer, which is the shape every
workload identity has, so the one audience that signs for itself could not read its own
usage on any of the four.
Provider credential administration (3).
GET, PUT and DELETE /v1/admin/credentials.
Skarbiec is the authority for credentials and Brama holds capability handles until final
use; a credential-administration surface inside the routing gateway is a second authority
for something Brama does not own (architecture).
The 24 primitives that stay¶
Nothing replaces these, because none of them is a second way to do something else.
Inference and translation: POST /v1/chat/completions,
POST /v1/messages, POST /v1/responses,
POST /v1/embeddings, POST /v1/moderations. Reading what this
gateway can serve: GET /v1/models, GET /v1/aliases,
GET /v1/admin/snapshot, GET /stats, brama aliases.
The two subscription capabilities, which are capabilities rather than per-audience verbs:
GET and POST /v1/subscription-pool,
POST /v1/plan-usage, brama subscription list.
Liveness and readiness, which answer different questions:
GET /health, GET /readyz. Process and operator primitives:
brama serve, brama version, brama detect,
brama mcp, brama onboard, brama test,
brama collect-task-quality, brama help.
Invocations with no prose page¶
Still three, at the revision measured:
GET, PUT and DELETE /v1/admin/credentials, which
the HTTP API page does not mention at all. They are the
family this page says Brama should not own; they will be documented by their removal, not
by a new page. It was four at
070275a036f35130918948b66f4be8b7e26fcf50: brama aliases had a
page file in the site source with no rewrite pointing at it, so
/docs/cli/aliases was linked from the CLI tree and did not resolve. That
route is registered. POST /v1/plan-usage was undocumented for exactly as
long as it took to write
its section in the same change that
registered it.
The removal rule¶
A replaced command is deleted in the same change as its replacement. Not deprecated, not left answering with a notice, not kept "until callers move" — deleted, with its route, its option, its example and its documentation paragraph, in the one commit that introduces what replaces it. A superseded command standing beside its replacement is a second source of truth, and a second source of truth is not a documentation problem: it is an operator reading the wrong state during an incident, which is how a refused authorization came to be reported as capacity and cost a day (errors). This is Brama's instance of the fleet rule that a replacement and its predecessor do not coexist.
Migration order¶
- Subscription inventory (11 invocations). Landed at
15c27474b3a870e1a399697068e2b96f4e72d8dd. First, because every other family names a subscription, so the identity and ownership scoping had to be settled before anything else could be expressed in terms of them. - Plan-usage reading (4 invocations). Landed at
76b7b987b33f950db9c6540d8a001b184d93b539. Second, because the usage ledger is what the repair capability reads to decide which repair applies; a capability that reads a declaration cannot land before the declaration is single-sourced. - Credential repair (13). Third, and only now, because it is the family that consumes the previous two: it selects a subscription from the pool and a verdict from the ledger. The manual sign-in belongs to it as the repair for an account only a person can log into; it stays a separate verb until the capability can ask the person.
- Route adoption (5). Fourth. It is independent of the subscription
families and can be sequenced anywhere after them; it goes here because collapsing three
entry points into one changes
brama onboard, and changing a first-use path while the pool is mid-migration puts both risks in one release. - Provider credential administration (3). Last, because it is the only family whose replacement is a boundary decision rather than a consolidation: the surface moves to Skarbiec, and removing it needs the consumers named in the service directory to have stopped calling it.
The order is dependency-first and blast-radius-second. Reversing it would mean building the repair capability on inventory that still has three owners, which is the defect this page exists to remove rather than relocate.
The command tree itself is the CLI reference; the routes are the HTTP API.