Stado CLI reference

This is the complete public command tree from the Stado dispatcher. Every command group and leaf has its own canonical page with the exact invocation, inputs, options, effects, and refusal boundary.

Stado accepts --help at every level. Parser or usage errors exit with code 2; runtime failures use the classified Stado failure contract documented below each command.

Command tree

• stado onboarding — Show the CLI first-use walkthrough or import an existing registry-v2 file
• stado capabilities — List Stado capability families, variants, providers and active selections
• stado overview — One operator snapshot: jobs, active workers, quota, budgets, burn and credits
• stado blast-radius — Inventory a dependency's live resources, auth, consumers, storage, and DR coverage
• stado resources — Inventory, plan, execute, verify, and restore resource operations
  • stado resources show — Show one read-only inventory across configured providers and storage
  • stado resources adopt — Explicitly adopt one observed resource into Stado ownership
  • stado resources rationalize — Produce an immutable resource rationalization plan; never mutates
  • stado resources shutdown — Produce a reversible shutdown plan; never mutates
  • stado resources apply — Execute the exact plan supplied by the operator, as its intent says: a rationalization plan or a shutdown plan
  • stado resources verify — Verify live resources against an applied or restored operation
  • stado resources restore — Restore successfully applied reversible actions
  • stado resources operations — Inspect durable operation history
    • stado resources operations list — List durable operations newest first
    • stado resources operations show — Show the archived plan, state, and events for one operation
• stado optimize — Inspect and control autonomous placement and resource reconciliation
  • stado optimize status — Show mode, safety state, inventory freshness, and latest decisions
  • stado optimize explain — Explain one immutable placement or resource decision
  • stado optimize run — Run one inventory, optimizer, reconciler, and FinOps cycle
  • stado optimize pause — Emergency-stop new autonomous mutations
  • stado optimize resume — Clear the emergency stop
  • stado optimize policy — Inspect or atomically replace the versioned autonomy policy
    • stado optimize policy show — Print the versioned autonomy policy
    • stado optimize policy apply —
• stado billing — Inspect or refresh cross-cloud costs, grants, burn, and credit balances
  • stado billing show — Read the last billing snapshot published by the coordinator
  • stado billing refresh — Query billing providers now and publish a fresh snapshot
  • stado billing watch — One billing watchdog pass: refresh, evaluate credit balance AND account health, and alert on transitions. Deliberately runnable outside the cloud it monitors; whatever schedule runs it (`stado schedule create`, cron on another machine) is its cadence
• stado cloud — Sign a cloud operator in and repair the Stado role contract; `--provider` names the cloud
  • stado cloud login — Sign in through Microsoft Account federation and encrypt the refresh token in Skarbiec
  • stado cloud roles — The role assignments Stado's control plane and agents hold
    • stado cloud roles repair — Apply Stado control-plane/agent roles and inspect a named deny assignment
• stado tunnel — Route public hostnames through a tunnel provider's ingress and DNS with Stado-held credentials; `--provider` names the provider
  • stado tunnel list — List tunnel ingress and DNS state for every hostname in one zone
  • stado tunnel status — Inspect one hostname's ingress, DNS and tunnel connection state
  • stado tunnel route — Route one hostname to an origin behind the provider's named tunnel
  • stado tunnel remove — Remove one hostname's tunnel ingress and matching tunnel DNS records
• stado waits — List the waits open on this machine, from the register every Stado wait keeps (`$STADO_WAITS_DIR` or ~/.stado/waits); a wait whose process no longer runs is reported ended and removed. `open` registers a wait for another process; `close` removes one; `cycles` names every lock-wait cycle standing on this machine
  • stado waits open — Register for process --pid a wait on --kind (one of the register's `rodzaj` words: siec, object-api, host, blokada, proces, baza, terminal, zgoda, sesja), for --what at --where. It ends when that process does or with `stado waits close <id>`
  • stado waits close — Remove the wait <id> from the register: it ended
  • stado waits cycles — Every cycle standing among this machine's lock waits: a process waiting on a lock held, directly or through other lock waits, by a process whose completion needs it. Each link names the process, its command, the lock it waits on and who holds that lock. Fails with the refusal status when any cycle stands
• stado public-status — Whether the components people rely on work: `check` asks every component the catalog declares under `public_status` once and publishes state, since when and the last failed check; `show` reads what was published; `serve` is the public status page that reads it
  • stado public-status check — Ask every declared component once, from this machine, and publish what each answered beside what the last check recorded
  • stado public-status show — The published state of every declared component: since when, and the last failed check with the answer that failed it
  • stado public-status serve — The public status page on --bind (`host:port`), as its own unit on a host apart from the products it reports on: every request reads the published document again, and one that cannot be read is answered 503 naming why. `/` is the page, `/status.json` the document
• stado machine — Stable JSON machine interface
  • stado machine submit — Submit one idempotent request from a JSON file
  • stado machine status — Read one job directly by ID; `--until terminal` holds the read until the job ends
  • stado machine logs — Read the canonical command log from a byte cursor: to the end, or at most --limit bytes
  • stado machine cancel — Durably and idempotently cancel one job
  • stado machine artifacts — Download and verify canonical artifacts for a terminal job
• stado mcp — Serve Stado's read-only MCP tools to an agent: newline-delimited JSON-RPC on stdin, one answer per line on stdout. Every tool runs a read-only, non-spending `stado` subcommand of this same binary
• stado submit — Submit a job (or batch) to the queue
• stado status — Show job status: the queue's jobs by state, or one job by its id
• stado results — Download job results
• stado quality — Read or apply the formatting this product's own quality gate checks
  • stado quality parse — Parse a command line with this exact binary without running it. Install and release admission use this to check unit argv before replacing a process's executable
  • stado quality units — Check every installed managed unit that invokes PROGRAM against the candidate's own parser, on one host or the whole registry
  • stado quality format — Format this checkout the way its declared gates of kind `format` read it. A web product, whose `format` gate is `stado web quality`, is refused: that gate runs the product's own scripts and names no formatter
  • stado quality check — Check that each committed Cargo.lock resolves its manifest (cargo fetch through the git program, then cargo metadata --locked --offline, no compile), then run every declared quality gate the product installation runs — each kind, `format`, `lint` and `test` — exactly as the release build runs it, writing nothing, so a commit that passes is not refused by its installation. On the web platform the gate is `stado web quality`, run over the exported tree with the release worker's WISENT_* contract
• stado cancel — Cancel a queued or running job, or every job still waiting in the queue
• stado job — Rerun or watch one job
  • stado job rerun — Resubmit a job's exact spec under a new job id
  • stado job set-priority — Change a queued job's scheduling priority without resubmitting it
  • stado job watch — Print a job's log, and with --follow keep printing it until the job reaches a terminal state
• stado serve — Run this host's Stado components in one supervised process
• stado quota — GPU quota inspection and increase requests across WC_PROVIDERS. Default (no subcommand) is equivalent to `quota show` — prints live cloud quota minus reservation minus running per provider.
  • stado quota show — Show GPU quota totals across all providers in WC_PROVIDERS
  • stado quota request — Quota-increase requests: submit them, and list the ones in flight
    • stado quota request create — Submit GPU quota-increase requests through the provider Quotas API: for ACCEL, or with --every-family for every GPU family the catalog reports, one request per provider and region
    • stado quota request list — Cross-provider in-flight quota requests + support communications
  • stado quota ticket — The provider support tickets quota requests turn into
    • stado quota ticket reply — Respond to open quota support tickets the provider is waiting on us for
    • stado quota ticket escalate — Post a credit-funded-subscription escalation reply on every open quota ticket whose latest provider message was a billing-side denial
  • stado quota catalog — List the full GPU catalog for each provider in WC_PROVIDERS
• stado profiles — List available submit profiles, or show one profile
• stado config — Inspect or change stado configuration: show | get | validate | init | migrate | set | unset
• stado artifact — Publish and consume immutable, versioned artifacts
  • stado artifact import — Build manifests from supported external artifact formats
    • stado artifact import activations — Verify and publish a pinned activation dataset revision
  • stado artifact list — List registered artifact versions
  • stado artifact show — Show one version or resolve an alias
  • stado artifact resolve — Resolve an alias to its immutable version
  • stado artifact publish — Validate and atomically publish a manifest JSON file
  • stado artifact alias — Manage mutable aliases that point at immutable versions
    • stado artifact alias set — Create an alias or update it with an optimistic precondition
    • stado artifact alias remove — Delete an alias while it still targets --expected-target; the versions it pointed at stay. An absent alias is reported, not refused
  • stado artifact verify — Re-run generic and type-specific verification
  • stado artifact lineage — Show producer and dependency provenance
• stado build — Build one committed source on every declared platform and keep the result; publish nothing. A release consumes a build that passed
  • stado build submit — Build one committed source on every platform its manifest declares. Snapshots the committed tree, publishes it as an immutable source object and queues one build job per platform on a live fleet builder. It ends when the jobs are queued; `stado build status` follows them. Nothing is signed, published or promoted: that is `stado release submit --build`, which consumes only a build that has passed. Repeating the command for the same source resumes the same build and re-queues only the platforms whose job failed or was cancelled.
  • stado build status — Read one build: its source, and what each platform's job did
  • stado build list — List builds, newest first: every one, or the newest --limit
  • stado build newest — Build every product in this workspace from the commit it stands on, and say what failed. Nothing is released. The same reading of the workspace as `stado release newest` — every product checkout, the commit it is on, the version that commit declares — followed by one build per product. `--plan` reads without queueing; `--wait` follows every build to its end and exits nonzero naming each product whose build failed.
• stado release — Build once, sign, promote, roll out, and roll back product releases
  • stado release keygen — Generate an Ed25519 release authority key pair
  • stado release policy — Apply, read and remove the reviewed rollout policy of each release-controlled product
    • stado release policy apply — Apply reviewed product policy without changing the active release
    • stado release policy show — Print one product's policy in the shape `apply` reads
    • stado release policy list — Every release-controlled product, its targets and desired release
    • stado release policy remove — Stop rolling a product out by release control anywhere: its policy is removed, and each former target's release agent retires the proxy and release processes it ran for the product
    • stado release policy remove-target — Stop releasing a product to one host: the target leaves the product's rollout policy, and the host's release agent then retires the proxy and the release processes it ran for the product there
  • stado release submit — Snapshot, qualify, build, sign, publish, deliver, and promote a product
  • stado release newest — Release every product in this workspace from the commit and version it already declares. One command for the whole workspace: each product checkout is read for the commit it stands on and the version that commit declares. A version a run published is skipped, a version a run of another commit holds is skipped with the new version it needs, and a commit a run is still releasing is skipped; a commit whose own run failed or was superseded is released again. The rest go through the same pipeline `submit` drives. `--plan` reads without submitting.
  • stado release changes — Hand pushed work to a later batch release, without starting a build
    • stado release changes submit — Record a pushed commit and its task without compiling or spending build budget
    • stado release changes list — Read queued work and the actual build qualification covering it
  • stado release resume — Resume a recorded release without replacing its source or running jobs
  • stado release redeliver — Re-run one delivery from an exact completed release without promotion
  • stado release catalog — Manage the Stado-owned product and source policy catalog
    • stado release catalog enroll — Set up everything a checkout's release manifest needs from the fleet: its release publisher, the build secrets its platforms and deliveries read (declared for and granted to the workload agent), for a service its rollout policy (created from runtime.port when absent) with, when the service directory does not know the service yet, its directory route called by the manifest's runtime.consumers, its own consumer with exactly `runtime.grants` and its bearer on every rollout target, and the product's entry in the release catalog the daily batch builds from; a required platform declaring no post-build tests is refused. `build submit` and `release submit` run the same steps (and name it)
    • stado release catalog sync — Register products from checked-out manifests or one central catalog
    • stado release catalog audit — Audit Stado's catalog without contacting repository hosts: every declared publisher must have a catalog entry and every required platform tests. Exits nonzero and names each finding on any refusal
    • stado release catalog declare-publisher — Declare one product's release publisher across the fleet: mint its item on the vault owner, grant the release client access, declare it on every participating host, then reconcile each host's verifier grant. `build submit` and `release submit` run this themselves for a product this host has not declared, with this host as the client and the vault owner read from `skarbiec bond status`; run it by hand only to declare further API targets or reloads
    • stado release catalog withdraw-publisher — Withdraw a retired product's release publisher declaration from the vault owner, this host and every --target, then reconcile each host's release verifier. Refuses while the release catalog still holds the product. The vault item stays, so a returning product re-declares
    • stado release catalog retire — Retire a product from the release pipeline: the inverse of `enroll`. Removes its entry from the release catalog the daily batch builds from, then withdraws its release publisher as `withdraw-publisher` does. A product the catalog does not hold is refused by name. Published releases stay; a returning product enrolls again
    • stado release catalog adopt — Add an application checkout to the release pipeline: write its release manifest and scripts from what its project states, declare its publisher, register it. Without --apply only the plan is printed
    • stado release catalog pin-input — Make one committed revision of another repository, or only the paths of it the build reads (--path, repeatable), an immutable build input of the product in CHECKOUT: archive it, store it create-only under the product's sources, and write `inputs.<name>` of its `.wisent-release.json`. The build reads it from WISENT_INPUT_<NAME>_DIR. --cargo publishes Cargo.lock's private crates, --git-bundle the commit's history, --swiftpm a Swift package's committed resolution
  • stado release destinations — Manage product delivery destinations in the canonical registry
    • stado release destinations list — List the canonical product destination declarations; does not install anything
    • stado release destinations show — Read one product's declared targets and their registry platforms
    • stado release destinations set — Replace one product's complete target set through a verified registry write
    • stado release destinations adopt — Adopt the existing catalog's explicit delivery hosts without changing them
    • stado release destinations remove — Remove a declaration. Already frozen release runs keep their destinations
  • stado release delivery — The target-side half of one delivery, run by the queue job the release's delivery step submits
    • stado release delivery worker — Apply one delivery request on this host, fenced against every coordinate but its own run's current one; the queue job's program
  • stado release prepare — Build, sign, and publish one immutable candidate coordinate
  • stado release fetch — Fetch signed, qualified archive bytes for one exact accepted source revision
  • stado release promote — Promote exact qualified candidate bytes into registry desired state
  • stado release agent — Run one reconcile pass of desired releases on this exact registry target (`--once`); the resident reconciler is the `--release-interval-seconds` role of `stado serve`
  • stado release status — Show desired and observed rollout state, and the register of recent publication attempts. The newest pipeline runs are listed with each platform's job, its state, what the build cost from the job's own clock, and the recorded failure of anything that died - the builder that refused the work, the secret that could not be resolved, or the job's own last output - so a failed publication can be read back without opening the store, and a release that is getting slower can be seen without one. Stado Desktop shows the same register, the same durations and the same failure text on its Releases screen. An unfinished platform whose job is absent from every queue state is reported as failed, with its job id and the missing-job finding. Failure of a required platform also makes the observed run failed; recorded_state retains the stored run state. A queue-read failure is reported separately as job_read_error, not treated as a missing job. These are observations: status does not resubmit work or change the stored release state.
  • stado release failed — Every Stado release a host of the fleet recorded as failed and rolled back from, as the hosts' health beacons publish them
  • stado release active — The release this host runs for a product: its executable, or a path under its release directory
    • stado release active binary — Resolve the executable this host runs for a product: the active signed release when release control rolls it out here, otherwise the version this host declares, checked against a fresh look at this host
    • stado release active dir — Print `<active.release_dir>/RELATIVE` from this host's release-state record of PRODUCT, or nothing when it records no active release
  • stado release logs — Read a release candidate's own stdout/stderr off the target host
  • stado release doctor — One verdict over desired state, the candidate, quarantine and the host's claiming gates
  • stado release quarantine — List and retire the digests a host refuses to roll out again
    • stado release quarantine list — List the digests this host will not roll out again
    • stado release quarantine clear — Retire exactly one quarantined digest so the agent retries it
  • stado release rollback — Atomically restore the previous desired release
  • stado release local — A release archive on this very host: install a delivered one, restore one an earlier delivery retained, list the retained ones, or converge the live readers of an already-installed binary
    • stado release local install — Install a delivered release archive's binary on this very host
    • stado release local restore — Reinstall a Stado release an earlier delivery retained on this very host, when the installed Stado cannot serve
    • stado release local list — Every Stado release this host retains: the installed one, the rollback target, and any that failed here with its record
    • stado release local converge — Reconcile the live readers of a native binary already installed on this host: restart every unit still executing the image it replaced
  • stado release coordinate — An immutable release coordinate: claim it for exactly one source revision before anything is published into it
    • stado release coordinate claim — Bind one immutable coordinate to exactly one source revision before anything is published into it
  • stado release version — A host's declared managed binary version: declare, unset or promote it, show it against what the host runs, or converge the host onto it
    • stado release version declare — Declare the exact version a host must run of one binary
    • stado release version unset — Remove one binary's declaration from a host
    • stado release version promote — Verify one published version and promote it into a host's declaration
    • stado release version show — Report the host's declared versions against what it runs
    • stado release version converge — Deliver host-behind versions; refuses to downgrade a host-ahead binary
  • stado release staged — A host's already-staged release
    • stado release staged activate — Activate one host's already-staged release with its own installer
  • stado release provenance — Attest the source and bytes of the release artifacts a host carries
  • stado release gate — The pull-request version gate's steps: the advertised surface, the published baseline, the versioning rule and the module reachability check `.github/workflows/version-check.yml` runs
    • stado release gate surface — Print `{"surface": [...]}`: the top-level commands BINARY advertises in `help`, or those in a saved help text
    • stado release gate baseline — Print `stado:VERSION` for the newest whole release the channel serves, or `bootstrap:VERSION` on an empty one; with --output, also write the baseline document. Run from the repository root
    • stado release gate decide — Classify the change between two surfaces and name the next version
    • stado release gate conformance — Reproduce every case of AutoVersion's FIXTURES.md with this port; fails when any class, next version or refusal differs. Without --fixtures, the file at the tag this port follows is read
    • stado release gate semver — A declared version against the one the rule requires
      • stado release gate semver reaches — Succeed when ACTUAL is a valid SemVer at least MINIMUM; a lower one fails, and an invalid one is refused with the usage status
    • stado release gate modules — The crate's module tree
      • stado release gate modules unreachable — Fail when a `.rs` file under the crate's `src/` is reachable from no crate root, or when a --known entry names a file that is gone
    • stado release gate app — The same gate for an application bundle, read from the sources its release step names
      • stado release gate app surface — Print `{"surface": [...]}` of an application tree, read from the sources named: Info.plist identity and URL schemes, Package.swift executable products, appended path literals of Swift files
      • stado release gate app baseline — Write an application's released-surface.json from the newest version tag origin serves (or the working revision while there is none); with --stdout, print it instead. Needs git history
      • stado release gate app check — An application's whole version gate, as a release quality step: the rule against AutoVersion's fixtures, the baseline against the handoff's provenance record, and the Info.plist version against the change
• stado ci — What the forge's continuous integration last did for a product: each workflow its repository declares, the newest run (of one revision with --revision) with its conclusion, and the failed job and step of a run that did not pass
  • stado ci status — The newest run of every workflow the product's repository declares, with its conclusion and, for a run that did not pass, each failed job and the step that failed in it, and the delivery routine: its plan, the step it is installing and for how long, the refused step with every refusal and its defects, and what each step last delivered. Reads the forge's API as the identity Stado's GitHub declaration names in Skarbiec; refuses by name when Skarbiec, the declaration or the forge does not answer
  • stado ci run — One pass of the delivery routine, which Stado's scheduler runs on the cadence the operator declares (`stado schedule create --cron … 'stado ci run'`): check every new commit of each step's `main` with the product's declared gates, recording each green or red (a red one in Oko, found in that commit), then install each step's last green commit, never `main` HEAD, in order, then — with `--push` declared — push `main` of every checkout. A refused install stops the pass, is recorded in Oko, exits non-zero, and resumes once a newer commit is green
  • stado ci delivery — Whether the path that delivers repairs stands on this machine: the routine's running and refused steps, each step's main check (every commit checked, its last green one), who holds the pass lock, which product operations hold build trees, and this machine's Stado unit. `stalled` names every way the path is down, a red `main` among them, one sentence each; Oko orders work by it. Reads only
  • stado ci plan — The delivery routine's declared plan
    • stado ci plan set — Declare the plan: each `--step PRODUCT:SURFACE:CHECKOUT`, in the order the routine installs them, the checkout named absolutely, and the open Oko defect the installs repair. Refused, quoting the ruling, while the operator's rulings forbid installing for that purpose
    • stado ci plan show — Print the declared plan; refused when none is declared
    • stado ci plan clear — Remove the declared plan: the routine installs nothing until one is declared again
• stado schedule — Manage recurring (cron) jobs — submit a command on a cron schedule. A schedule is evaluated every coordinator tick; when due, the coordinator submits a fresh job with the same routing/sizing and secret-reference contract. Schedules live in configured Stado storage.
  • stado schedule create — Create a recurring schedule that submits COMMAND on a cron schedule
  • stado schedule list — List all schedules
  • stado schedule show — Print one schedule: its fields as text, or its full record with --json
  • stado schedule edit — Change a schedule's command, cron expression or timezone; an enabled schedule's next run is recomputed from now
  • stado schedule rm — Delete a schedule (does not affect jobs it already submitted)
  • stado schedule pause — Disable a schedule without deleting it
  • stado schedule resume — Re-enable a paused schedule (next run recomputed from now)
  • stado schedule run — Fire a schedule once with a caller-retained retry identity
• stado cost — Per-job and per-batch cost reporting from observed wall-times
  • stado cost prices — Read the recorded provider price book, including source errors and observation times
  • stado cost quote — Match recorded allocations to observed inventory and provider price quotes
  • stado cost report — Summarize $ spent per target_kind and per model from completed jobs
  • stado cost estimate — Project total $ for a batch file using observed per-job cost
  • stado cost allocation — Show the attributed provider/owner/workload cost ledger
  • stado cost forecast — Show current burn, month-end projection, budget, and credit runway
  • stado cost anomalies — Show active cost and resource anomalies
  • stado cost savings — Show predicted versus realized savings
• stado registry — Manage the canonical compute-target registry in configured Stado storage
  • stado registry validate — Validate an explicitly selected local registry-v2 JSON document
  • stado registry import — Additively adopt an existing registry-v2 JSON document
  • stado registry push — Upload local registry.json to the canonical registry object. With --if-generation the write is conditional on the generation the document was read at: a registry that has moved since is refused with exit 75 and, under --json, a `stado.registry-push-receipt.v1` object whose state is "conflict" and which names both generations. Exit 75 means only that, so a reconcile loop can re-pull, re-apply and push again; a storage or validation failure stays exit 1.
  • stado registry pull — Print the canonical registry to stdout. Bare, this is the document alone. --with-generation prints one `stado.registry-pull-receipt.v1` object carrying the document and the token `push --if-generation` spends; --generation-only prints just the token. Both come from a single versioned read.
  • stado registry set — Change one field of the canonical registry, under the generation it was read at. The path is the one `pull --path` reads, so a field a caller can read it can write: `registry set --path targets.<host>.release_platform --value darwin-arm64`. The value is JSON when it parses as JSON and the literal text when it does not. A last field the object does not carry yet is created (`--path targets.<host>.privacy_grants --value '[...]'`), and the whole document must still pass the validation `push` runs, so a malformed value of a field the registry validates is refused; a path whose holder does not exist is refused, naming the keys or element names that do. Setting an array is how one of its entries is added, changed or removed. A registry that moved since the read is refused with exit 75, as `push --if-generation` is.
  • stado registry self — Print which registry target is this machine
  • stado registry doctor — Diff registry declarations against live host state
  • stado registry host — Manage hosts in the canonical registry
    • stado registry host show — One host's registry declaration, answered without pulling the document
    • stado registry host add — Onboard HOST into the canonical registry, validated
    • stado registry host edit — Change the SSH destination, kind or release platform `add` declared. Fields `add` does not write are changed with `stado registry set --path targets.<host>.<field>`.
    • stado registry host remove — Retire HOST from the canonical registry. Refused while any other registry entry still names HOST; the refusal lists those paths.
    • stado registry host path — Manage ordered SSH connection paths for an existing host
      • stado registry host path list — List the preferred path and ordered alternates
      • stado registry host path set — Add or replace one connection path
      • stado registry host path remove — Remove one alternate connection path
• stado fleet — Add machines to the fleet, group them, hold their SSH keys, and diagnose the workers: enroll, join/approve, key, doctor
  • stado fleet doctor — Diagnose worker health: agent grant, secret probes, beacons, capacity
  • stado fleet needs — What the fleet lacks: RAM on which host, storage where, a GPU, a platform nobody declared — from the capacity publications, the declared watermarks, the queue and the recorded refusals
  • stado fleet expansion — Compare evidenced expansion options within a total expenditure budget
    • stado fleet expansion catalog — Read the versioned catalog of sourced investment assumptions
    • stado fleet expansion set — Atomically replace the catalog; blank economic values remain unknown
    • stado fleet expansion plan — Save an exact budget-constrained comparison; never buy or enroll
    • stado fleet expansion show — Read an immutable analysis, including its original evidence and estimates
    • stado fleet expansion history — Read retained plans, newest first
  • stado fleet list — List the fleets declared in the registry with their members
  • stado fleet status — Show live state for the members of one named fleet
  • stado fleet create — Declare a new fleet in the canonical registry
  • stado fleet assign — Add a registered machine to a declared fleet
  • stado fleet unassign — Take a registered machine out of its fleet; the machine stays in the registry. A machine in no fleet is reported and left unchanged
  • stado fleet delete — Retire a declared fleet. Refused while any target still points at it: deleting the declaration under a member would leave the document naming a fleet that does not exist, and `fleet list` refuses exactly that shape. Reassign or unassign the members first
  • stado fleet enroll — One-command onboarding: register a machine, optionally fleet it, optionally install the agent
  • stado fleet invite — Mint an invite: something the machine's owner runs, no access needed
  • stado fleet invites — List minted invites with the state each is actually in
  • stado fleet revoke-invite — Retire an invite so it can no longer be redeemed
  • stado fleet ingress — Stand up, inspect or tear down the public entrance the one-line invite mode needs — a narrow enrollment listener behind a Cloudflare quick tunnel, with no Cloudflare account, token or DNS record involved
    • stado fleet ingress up — Start the narrow enrollment listener and a tunnel in front of it, verify the public address from the internet, then publish it
    • stado fleet ingress status — What is published, whether it still answers, and how old it is
    • stado fleet ingress down — Close the tunnel, stop the listener, and unpublish the address
  • stado fleet methods — Every way a machine can be added, and whether this fleet allows it
  • stado fleet join — Announce this machine to the fleet (run on the machine being added)
  • stado fleet pending — List unanswered join requests
  • stado fleet approve — Turn a pending join request into a registered target
  • stado fleet reject — Drop a pending join request
  • stado fleet catalog — Print the central enrollment and communication catalog
  • stado fleet key — SSH host keys in the globally selected credential store
    • stado fleet key add — Move an existing private key into the credential store (never printed)
    • stado fleet key ls — List stored SSH host keys (metadata only)
    • stado fleet key rm — Remove a target's SSH key from the credential store
    • stado fleet key install — Install the stored public key into the target's authorized_keys
    • stado fleet key check — Verify the stored key opens the channel to the target
    • stado fleet key generate — Generate a fresh ed25519 pair for the target into the credential store
    • stado fleet key rotate — Rotate the target's key end to end, with rollback on failure
• stado identity — Which host holds which identity, and whether that is still true
  • stado identity list — Every declared identity binding across the fleet
  • stado identity verify — Check a binding against the hosts themselves, not the declaration
• stado host — Manage operating-system resources on registry hosts
  • stado host health — Show the latest Stado health beacon and log tail for TARGET
  • stado host beacon — The health beacon each host publishes about itself: list every host's, collect this host's, or publish one collected elsewhere
    • stado host beacon list — Every registry host and its last beacon, worst first
    • stado host beacon collect — Collect THIS host's health beacon from the registry's declarations and the init system's own answers. One unit per identity the registry declares here, with the state launchd or systemd reports for it: `active`, `failed`, `inactive` when every domain answered that nothing is there, and `unreadable` with the cause when a domain refused the read or the read failed. A refused read is never published as `inactive` — the collector that did that published a loaded gateway as not loaded. Prints the document and publishes nothing unless `--publish` is given.
    • stado host beacon publish — Publish one locally collected beacon through the scoped Stado health API. The `link` block (tailnet path, sleep/wake, interface changes) is collected here, on the host, and merged into the document about this machine before it is published.
  • stado host privacy — What macOS lets TARGET's Stado process read: Documents, Desktop and Downloads, each `granted`, `denied`, `absent` or `unreadable`, beside the grants `targets[].privacy_grants` declares for TARGET. Read from TARGET's latest beacon, which the host process measures itself. Exits non-zero when a declared grant is denied, naming the program, the folder, the declared reason and the System Settings pane that allows it; a folder no grant declares is reported and fails nothing.
  • stado host reboot — Request a graceful reboot of TARGET through its approved channel
  • stado host user — Manage local macOS and Linux user accounts
    • stado host user create — Create USERNAME on selected registry-managed hosts over SSH
    • stado host user delete — Delete USERNAME from a registry-managed host over SSH. The account, and its home directory unless --keep-home, cannot be restored, so the username is repeated with --confirm
  • stado host gpu — TARGET's GPUs: the declared NVIDIA board power cap, set or unset
    • stado host gpu power — The board power cap a local target declares in the registry (`gpu_power_limit_watts`), which its agent re-asserts every poll
      • stado host gpu power set — Persist and immediately reconcile TARGET's NVIDIA board power cap
      • stado host gpu power unset — Withdraw TARGET's declared board power cap and return every GPU to the driver's default limit; the agent stops re-asserting a cap
  • stado host uptime — Report TARGET's uptime, load averages and logged-in users
  • stado host ping — Check TARGET's ssh reachability AND health-beacon age as one verdict
  • stado host gates — Report HOST's measured disk space against the disk-full rule, the published admission decision and the source, duration and error of every diagnostic read. Read-only. Each registry, host, storage, capacity and queue read retains its result or concrete error. Elapsed time is recorded, not used to end a read. Completed readings survive failures; incomplete reports use claiming=null.
  • stado host link — Why TARGET went quiet: beacon age, the path and endpoint it published, its last sleep and wake, its interface changes, the silences recorded against it, and what readers refused because of them. Read-only and safe against a live host. A control host can be unreachable for minutes and come back on a direct path with nothing in this product carrying a trace of it; this is that trace.
  • stado host port — TARGET's TCP ports: which process holds one
    • stado host port owner — Which process holds one TCP port on TARGET: its pid, user and command. A unit that exits with `Address already in use` names no owner, and `service reap` keeps a row a declared label holds, so the socket's holder was the one fault on this fleet nothing in the product could name.
  • stado host local — The halves of host verbs that run on this host itself, started over the host channel with this host's installed Stado: a lock to run under, the object API's readers, the release store's repair, the backup's audit, a port the host hands out, and the storage-root transaction's phases, steps and worker
    • stado host local run — Run PROGRAM on this host under an exclusive, non-blocking flock of LOCK; the fixed recovery programs' lock holder
    • stado host local api — The host half of the object-API recovery: its readers of this host's config, launchd definitions, route and Skarbiec release state
      • stado host local api paths — `STORE\tBACKUP_STORE\tOBJECT_URL\tNAMESPACE\tTOKEN_FILE\tLABEL\tRETIRED` for this host; LABEL is the launchd label of the host Stado process and RETIRED the comma-separated labels on this host that run the Stado program as an API listener under another label
      • stado host local api plist — The object API's launchd definition: render it, or compare two
        • stado host local api plist render — Write the object API's launchd definition to --staged, keeping every option of the installed one that recovery does not own
        • stado host local api plist equal — Succeed when both definitions parse and are equal
      • stado host local api boundary — The object boundary the server reports
        • stado host local api boundary ready — Succeed when the server's state reports a ready object boundary with no error
      • stado host local api route — The storage route of a loaded job (`launchctl print` output) or of a plist, as twelve tab-separated fields
      • stado host local api skarbiec — The Skarbiec release this host runs beside its object API
        • stado host local api skarbiec plan — The registry's Skarbiec release plan for this host, or `absent`
        • stado host local api skarbiec ownership — `owned` or `unowned` from the Skarbiec release state
        • stado host local api skarbiec upstream — The Skarbiec proxy's upstream, when it is a declared candidate
        • stado host local api skarbiec proxy — `none` or `exact\tPID\tEXECUTABLE` for the exact orphaned proxy in a `ps axww -o pid= -o command=` listing
    • stado host local repair — Return one release-catalog coordinate in this host's local stores to the managed account; the host half of the release-store repair
    • stado host local audit — The host half of `stado credentials backup audit`: classify this host's replica against its primary store and, with --reclaim true --apply true, delete the twins this pass proved. Prints the marker lines the operator side reads
    • stado host local port — A port nobody chooses: binds a free loopback port the host's own system hands out, releases it and prints its number, so `service ensure` records a catalog service's port and `service directory consumer add` a resolver adapter's in the registry
    • stado host local reconcile — The storage-root transaction (`stado repair`'s storage-root step) as it runs on this host: one receipt phase, one host step, or the resident worker
      • stado host local reconcile phase — One phase on this host's two local storage roots. Prints the marker line the transaction worker reads; the owner token and the inherited lock descriptor arrive in STADO_RECONCILE_OWNER_TOKEN and STADO_RECONCILE_LOCK_FD
      • stado host local reconcile step — The host steps outside the receipt phases: launching the resident worker, unit files, listener and object API observations
        • stado host local reconcile step launch — Start the resident transaction worker under launchd or systemd, or acknowledge the one already running. The worker arguments arrive base64-encoded JSON in --arguments
        • stado host local reconcile step unit — A unit file of the host's init system: snapshot it, or put a snapshot back
          • stado host local reconcile step unit snapshot — Print `STADO_UNIT_SNAPSHOT` with a unit file's bytes and owner
          • stado host local reconcile step unit restore — Put captured unit bytes (base64 in STADO_UNIT_BODY) back in place
        • stado host local reconcile step listener — The loopback listener of the object API
          • stado host local reconcile step listener closed — Return once nothing listens on the loopback port
        • stado host local reconcile step object — The object API's runtime state, as the transaction payload
          • stado host local reconcile step object runtime — Print the object API's runtime state as the transaction payload
        • stado host local reconcile step store — The store the object API serves
          • stado host local reconcile step store served — Name the physical root the object API serves; the preflight inventories arrive base64-encoded on stdin
      • stado host local reconcile worker — The resident transaction worker
  • stado host exec — Run one fixed approved command on TARGET (allowlist, not a shell). Provider sign-in and model requests are not host-exec operations. Use Brama's account-bound CLI, authenticated API or Desktop for them. Retained Tailscale logs are available without changing logging settings, restarting a service, or opening a test network connection. macOS: log show --last 1h --style compact --info --debug --no-pager --process Tailscale --process IPNExtension --process io.tailscale.ipn.macsys.network-extension --process tailscaled Linux: journalctl --unit tailscaled --since -1h --no-pager --output short-iso These commands retain the native timestamps and messages. Empty output does not establish that Funnel works. Missing tools and access refusals remain command failures. Changed arguments or an extra process, path, or time window are refused before the host is contacted.
  • stado host run — A managed run tree below `$HOME/.stado/work/runs` on TARGET: deliver its inputs, build its declared binary, attach to one of its programs, or remove it
    • stado host run deliver — Deliver one local file or directory into a canonical run directory on TARGET. DESTINATION is relative to the registry-approved account's home and must be below `.stado/work/runs/<canonical lowercase UUID>/`. The command refuses a missing, special, or root-symlink SOURCE; an empty or malformed file list; and any destination outside that shape before contacting TARGET. On TARGET it refuses symlinked, foreign-owned, or wrong-kind destination state before rsync transfers a byte. The destination is replaced atomically after the transfer.
    • stado host run build — Build one declared Cargo binary inside a delivered managed run tree. The command is fixed to `cargo build --locked --release`; only the manifest and binary name vary. The manifest must resolve below the selected account's `$HOME/.stado/work/runs`.
    • stado host run attach — Run one executable from a managed run tree with this process's standard input, output, and error attached. SIGHUP, SIGINT, and SIGTERM received by Stado are forwarded to the remote program. Arguments are ordinary process arguments; sensitive input belongs on stdin and never in `--arg`.
    • stado host run remove — Recursively remove one complete managed run directory. PATH must be one direct child of `$HOME/.stado/work/runs`. Absence is a retry-safe success; symlinks, foreign ownership, the shared root, and nested subdirectories are refused.
  • stado host cron — Read TARGET's crontab, and optionally prune one entry from it. The periodic table is the one place a fleet host can declare a process that no launchd domain and no registry document mentions. `@reboot` entries outside both can restart duplicates that were just retired with verified postconditions — so every repair on that host is one reboot from coming back, and without this command the only way to change the table is a bare `crontab -e` over ssh. `--prune` previews by default and refuses anything but a single matching line that references `$HOME/.stado`; `--apply` saves the whole table under `$HOME/.stado/cron-backups` first and prints the `--restore` command that puts it back.
  • stado host document — A public document TARGET renders from its own live vault
    • stado host document render — Deliver a checked-in renderer to TARGET and print the public JSON document it builds from TARGET's own live vault. Private material never leaves the host: a rendered document carrying a private key is refused
  • stado host inventory — Report TARGET's stado-managed binaries, fixed Cargo-home metadata and bin membership, forward markers and loopback listeners, and whether each marker still matches a live listener
  • stado host config — TARGET's own Stado configuration, read and changed through its fleet channel
    • stado host config show — Read TARGET's effective Stado configuration through its fleet channel
    • stado host config set — Persist one dotted Stado configuration value on TARGET
    • stado host config unset — Remove one dotted Stado configuration key from TARGET. A declaration that should never have been made is retracted, not overwritten with a null: a key present with a null value and a key that is absent read the same through `jq` and differently through the code that iterates the object.
  • stado host compiler — TARGET's compiler: its cache, read or brought to the version Stado declares
    • stado host compiler cache — Read or bring TARGET's compiler cache to the version Stado declares. The release worker installs the cache on a builder before a build's first step, so a builder that cannot install it refuses every release build, the one that would repair it included. This runs TARGET's own `stado product compiler-cache` over the fleet channel.
• stado bootstrap — Provision wisent-compute services persistently across reboots
• stado market — Offer this fleet's idle GPU on a compute marketplace, and withdraw it when the queue has work
  • stado market list — List this fleet's GPU machine on the marketplace at the given prices
  • stado market unlist — Withdraw every offer for this fleet's machine, blocking new renters. Existing rentals are not terminated
  • stado market status — Show the marketplace's current view of this fleet's machine: rentals and whether it is listed
  • stado market readiness — Whether this machine can earn on the marketplace, and which provisioning step is missing when it cannot: the Skarbiec channel this host holds, the vault that would declare the credential, and the marketplace's own answer to it. Exits non-zero unless the marketplace accepts the credential
  • stado market monitor — One snapshot of the marketplace's view beside what the queue holds
  • stado market auto-list — Keep the listing in step with the queue: list when the queue has been idle for the window, withdraw when work appears
• stado instances — Inspect and reap live agent VMs across the configured cloud providers
  • stado instances list — List every live agent VM across the configured providers, flagging the ones no queue job or lease still references
• stado recovery — Transactional outage recovery: fence, migrate, verify, and cut over
  • stado recovery migrate — Drain, copy, verify, cut over selected services, and optionally resume
• stado storage — Move queue state between storage backends (billing-outage migration)
  • stado storage copy — Copy queue state from one storage backend to another
  • stado storage backup — Copy the active queue store to the configured disaster-recovery store
  • stado storage ls — List objects under a prefix, or per-prefix counts across the whole canonical prefix set when no prefix is given
  • stado storage stat — Report one object: present, absent, or unreachable
  • stado storage cat — Write one object's body to stdout
  • stado storage verify — Compare two stores object-for-object. Read-only; copies nothing
  • stado storage archive — Package one directory as a deterministic gzip-compressed release archive. Requires storage.archive_limits, or its WC_STORAGE_ARCHIVE_LIMITS JSON override
  • stado storage put — Upload a product object through the provider-neutral Stado namespace. Release objects are always create-only, even without --if-absent
  • stado storage get — Download a product object through the provider-neutral Stado namespace
  • stado storage objects — List product objects in one provider-neutral Stado namespace
  • stado storage abort-upload — Discard the staged parts of one interrupted multipart upload. `put` stages a large body as `<key>.__stado_upload/<upload-id>/<index>` parts and composition promotes them in one step, deleting the parts as it goes. A publisher that dies between the last part and composition leaves the parts and no object: an archive sits as unfinalised parts, tens of MiB of a coordinate nothing can read, and nothing in the product could remove them - `rm` refuses the whole `releases` namespace as immutable, which is true of published objects and false of staged parts. The object API already authorizes a part's DELETE against its TARGET's publisher, so the boundary for this was in place and only the command was missing.
  • stado storage rm — Delete a product object through the provider-neutral Stado namespace. Release objects are immutable and cannot be deleted
  • stado storage url — Print an object's URL: a release object's on the declared public origin, bearer-free; any other through the configured API
• stado credentials — Read, migrate, and manage application credentials in the selected store
  • stado credentials put — Store an item in the selected credential store, reading from STDIN. Without --route a write is an owner act: it goes to the owner vault the store selects. With --route, --consumer, --grant-file and --field it replaces one field of an existing item under that consumer's own `rotate:NAME#FIELD` grant, keeping every other field, the kind, the recipients and the tags; the vault records the consumer as the writer. A missing grant, an absent or trashed item, or an item a lifecycle or Weles controls is refused with Skarbiec's answer.
  • stado credentials get — Print one credential item value or one exact string field to stdout, naming the item by its id or by the role it plays
  • stado credentials ls — List metadata for items visible to the credential-store admin
  • stado credentials rm — Delete one item from the selected credential store
  • stado credentials migrate — Move every credential to a new backend and commit the selector
  • stado credentials doctor — Report whether any key on this machine can still open the vault, and which key files a restore needs when none can
  • stado credentials vault — The Skarbiec vault: which one this machine resolves to (`show`), which the fleet holds (`list`), what one holds (`items`), and keeping copies in step with the owner (`sync`, `retire`). Every write and every authoritative read here goes through one file, and `show` says which; before it the answer lived in a discovery rule and one environment variable and surfaced only as a refusal.
    • stado credentials vault show — Report which vault this machine's credential operations resolve to, and why. Exits non-zero when nothing resolves, so a script can gate on it
    • stado credentials vault list — Which Skarbiec vaults the fleet holds: every registry host, or one
    • stado credentials vault items — Nonsecret item metadata (names, kinds, states, tags; never a field value) from one vault: a local VAULT file, or with `--host` the vault that host holds, read with the read-only `skarbiec list`
    • stado credentials vault sync — Pull a host's Skarbiec mirror into its declared live vault, or with --push publish the vault owner's live vault to the mirror
    • stado credentials vault retire — Retire one vault file on a machine that reads the vault owner and holds none: compare it with the owner item by item and report what the owner lacks; with --apply move those items onto the owner, prove the owner holds every live item of the copy, and only then remove the file
  • stado credentials harvest — Inventory credentials recoverable from agent transcripts. Reports names and counts, never values
  • stado credentials try-unlock — Test unlock phrases found in transcripts against a local or remote vault, reporting which source name worked. Never prints a phrase
  • stado credentials item — Credential item operations on the host that owns the vault
    • stado credentials item put — Store the secret that plays one role in a host's declared owner vault: the item carrying stado:role:<ROLE> is rotated, or created under a random id with that tag
    • stado credentials item show — Report one host-vault item without revealing its values
    • stado credentials item retag — Replace one host-vault item's tags, or read them when --tags is omitted
    • stado credentials item delete — Delete one owner-controlled item from a host's vault, for items whose product or role is retired; Skarbiec keeps the deletion restorable
    • stado credentials item restore — Return one deleted item from a host vault's trash, undoing delete
    • stado credentials item reclaim — Return one host-vault item from the consumer that wrote it to the vault owner's control, so retag, rename and delete may change it. Only control moves; Skarbiec refuses lifecycle- and Weles-managed items
    • stado credentials item rename — Give one host-vault item a new id, keeping its payload, history and tags; grants naming the old id must be reissued
    • stado credentials item upgrade — Bring the owner vault to Skarbiec's current schema: the v2 envelope, an item_uid on every item and a payload fingerprint on every active item, so the duplicate report and the duplicate refusal cover every row
    • stado credentials item summarize — Host primitive used by `show`: read a `skarbiec get --json` document on stdin and print each field's length and SHA-256, never a value
  • stado credentials token — Credential token operations on the host that owns the vault
    • stado credentials token mint — Mint a Skarbiec bearer, or register an existing vault field
    • stado credentials token sync — Deliver an existing bearer between matching declared vault copies, without changing grants
    • stado credentials token register — Vault-owner primitive used by `mint --token-item`: register ITEM#FIELD with `skarbiec grant issue` and keep it at STADO_TOKEN_DESTINATION
    • stado credentials token custody — Host primitive used by `sync`: export, install or check one bearer against the declared consumer grant, reading an export on stdin
  • stado credentials acquisition-scopes — Acquisition-scope operations on a host vault
    • stado credentials acquisition-scopes sync — Deliver and register an acquisition-scope catalog. Its grants keep the lifetime their current registration has left, so re-registering never extends them; a catalog with no current registration needs --ttl-seconds
  • stado credentials grant — Consumer grant operations on a host vault
    • stado credentials grant add — Add to a consumer's grant the read of one field of the item that plays a role: by the role (`read:role:<role>#<field>`, what `credentials get --role --route` asks for) and by the item playing it now. --token-file is the consumer's bearer file on the host
    • stado credentials grant consolidate — Merge retired consumer capabilities into Stado's existing bearer
    • stado credentials grant rebind — Bind the stado grant back to the bearer file the fleet holds, when that file no longer opens it: same capabilities, audience and expiry. The recovery for every credential read answering "consumer not authorized to read item field" after the owner's grant record and the fleet's bearer file diverged. Refused when the file already opens the grant; verified after.
    • stado credentials grant revoke — Revoke a retired consumer whose every capability the stado grant already holds, leaving one identity on the host's vault. Refused for `stado` and for a consumer holding anything the stado grant lacks
    • stado credentials grant show — Report one consumer's recorded grant
    • stado credentials grant renew — Renew this host's own workload-agent grant until revoked, the way the agent's tick does when the vault still records an end for it: at the authoritative vault, with the capabilities the grant already carries. The consumer is the one the workload agent's configuration names
  • stado credentials backup — Backup operations associated with credential custody
    • stado credentials backup audit — Classify a host's local replica against the store it mirrors
  • stado credentials seed — Authenticator seeds in login rows: list whether each row still holds a seed its account accepts, or enrol one for a row that has none
    • stado credentials seed list — Whether login items still hold authenticator seeds their accounts accept
    • stado credentials seed enrol — Enrol an authenticator for one login row and store its seed, so later sign-ins answer the second factor without a person's phone
  • stado credentials sparkle-key — A desktop product's Sparkle update key
    • stado credentials sparkle-key mint — Mint a desktop product's Sparkle update key: an Ed25519 pair stored under role `<product>-sparkle` (`private_key`, `public_key`), with the public half written into the app's Info.plist as SUPublicEDKey. A role that already holds a key is refused without --replace, because copies installed with the old key accept only updates it signs
  • stado credentials signing-profile — A product's code-signing provisioning profiles, stored as fields of one owner-vault item
    • stado credentials signing-profile ensure — Make or find a product's code-signing provisioning profiles through the provider's API and store them, base64, as fields of one owner-vault item
• stado queue — Maintenance mode: pause/resume dispatching, and drain the fleet
  • stado queue pause — Stop dispatching and claiming; running jobs finish untouched
  • stado queue resume — Resume dispatching and claiming
  • stado queue status — Pause state plus how much work is queued and still running
  • stado queue drain — Pause, then report whether any job is still running. Exits non-zero while running/ is not empty
  • stado queue budget — What the fleet has spent on compiling today, and the ceiling it is measured against. `--limit` declares a new ceiling
• stado alerts — Show which alert channels resolve, and page them on purpose
  • stado alerts channels — Show which alert channels resolve, and their destinations
  • stado alerts send — Page every configured channel with one message
  • stado alerts preferences — Show or record how the operator wants to be asked: the alert channels he chose, in his order. Every page goes through them
    • stado alerts preferences show — Print the channels the operator chose, in his order
    • stado alerts preferences set — Replace the operator's choice with these channels, in this order
• stado service — Manage the services registry hosts run: list, status, restart, adopt, retire, deploy, logs, env
  • stado service directory — Where a service is reachable from here, and who may use it
    • stado service directory show — Print the whole service directory
    • stado service directory profiles — The placement profiles the registry declares. A profile is what says a service is SUPPOSED to run somewhere, which is a different fact from the directory's `active_host` and from whether anything is listening. Reading it settles an argument this fleet has already had: `brama-skarbiec` declares units on two hosts, so a Brama missing from one of them is an unstarted unit rather than a service that lives elsewhere.
    • stado service directory bind — The serving parameters for the host this service is placed on. The other side of `connect`: a caller asks how to reach the service, and the placed host asks how it should serve. Both answers come from the same placement and the same host records, so moving a service needs no edit on either side. Refused on a host the service is not placed on, because a gateway that binds where nothing placed it is the thing every caller then has to be protected from.
    • stado service directory connect — A usable route to one service, derived from where it is placed. There is no other address. If the service is placed somewhere that does not answer, that is what this says -- resolving to something local instead is how a caller ends up talking to a process nobody placed. A route through an adapter this host's resolver already holds a connection on, unanswered longer than the refresh interval it declares, is refused with that connection's sentence instead of knocked on: the knock would stand behind it for as long as it stands (`stado resolver status`).
    • stado service directory doctor — Diagnose this host's admitted route and require an actual HTTP answer. HTTP reachability does not prove application authorization or inference
    • stado service directory endpoint — The address this machine should use for one service. Resolves against the asking target rather than the active host, because a loopback-bound service has a different address on every client. A target with no entry is reported as exactly that.
    • stado service directory publish — Write this machine's forward markers from the directory. Publishes declared per-caller endpoints for consumers of forward markers. Undeclared markers are reported, and removed only with `--prune`.
    • stado service directory consumer — Who may use a service: declare a consumer, or remove one
      • stado service directory consumer add — Declare that a consumer may use a service
      • stado service directory consumer remove — Remove a consumer's declaration and its resolver bindings
    • stado service directory beside — The services this host runs for its own callers beside their placement (`~/.stado/beside.json`): list them, declare one with `--url`, or take one back with `--withdraw`. `connect` on this host answers that address
  • stado service catalog — The preconfigured Wisent services, ready to deploy by name: no declaration to write, no flags to know. `service deploy <name>` and `service ensure <name>` resolve these when nothing else declares the unit
  • stado service list — Every registry-managed service across all hosts, with its state. Answered from the latest health beacons, so it costs no ssh and reports on hosts that are not currently reachable. A host that has published no beacon reports `unknown`, which is deliberately not the same answer as `missing`. `STATE` is the host beacon's report about its own unit. `OBSERVED` is the latest independent observation of the service. A silent host cannot confirm current state; `never` means no independent confirmation exists. `--unowned` lists product processes no launchd job or systemd unit owns. These processes are outside the managed unit lifecycle. A process is a product process when it executes out of a managed root or its working directory is under one, so a program started there with a relative command line (`bash release/build.sh`) is found too. `--undeclared` lists loaded launchd jobs absent from the registry. Declared-unit listing cannot find them, and owned processes do not appear in `--unowned`; all three views answer different questions.
  • stado service bootout — Boot one exact launchd label or systemd unit out of its system or user scope. `stop` and `retire` require a registry declaration. This command is for a loaded unit the registry does not declare, including an obsolete duplicate that `service list --undeclared` found. It never removes the unit's file. On Linux the selected systemd manager stops and disables only the exact requested unit, then Stado reads back that it is inactive and not enabled. On Darwin the selected launchd domain is booted out as before.
  • stado service reap — End the duplicate copies of one program on HOST that no declared label holds. Every process whose command line contains `--command` and that executes out of a managed root, or runs with its working directory under one, is listed. A row a declared launchd label or systemd unit holds is `kept` and never signalled; on Linux that includes every process in the declared unit's cgroup. Every other row reads `would_end` until `--apply` sends it SIGKILL and waits for it to exit.
  • stado service watch — Sit on HOST and name the parent of the next process matching a program, while that parent is still alive. `reap` and `list --unowned` each take one snapshot, and a snapshot taken after a respawn can only ever report `ppid 1` — the parent backgrounded the child and exited, which is precisely why nothing could say what kept restarting an undeclared `stado serve`. Driving a snapshot from here in a loop cannot sample faster than an SSH round trip; the loop has to run on the host. Reads `ps` on an interval and prints. It signals nothing, starts nothing and writes nothing, so it is safe to leave running while somebody else works on the box.
  • stado service unit — What the host init system holds under one named unit
    • stado service unit show — Ask the host init system what it holds under one named unit. This reader does not enumerate. The operator names the launchd label or systemd unit, so it can inspect a loaded unit whose file is gone. Fixed process, path, restart and trigger fields plus the five explicitly non-secret storage-routing variables are returned; no other service environment is read. A unit the host does not hold exits non-zero as `not_found`, a read the host refused as `auth`, and a read that could not decide as `infra_down`; `--json` still prints what was read first.
    • stado service unit logs — The tail of one unit's own log on HOST, named by its label whether or not the registry declares it. A crash-looping unit says why in its log and nowhere else: the health beacon reports it failed and carries no log, and `host exec` is a read-only allowlist that cannot read a file. `service logs` reads a declared service on every host that manages it; this reads one label on one host.
  • stado service verify — Go to each consumer and check the endpoint it is told to use, and that the thing answering is the service that was declared. `list` reports what hosts say about their units. This reports whether the directory's addresses answer, from the machines that must call them -- the one question every other check in this binary skips. States are `observed`, `unreachable`, `misowned` for a port a different declared unit is holding, `standby_serving` for a standby host whose own declared unit answers on its standby address (a second copy beside the active host, probed and owner-checked from that standby host), and `unverified` for a probe that could not run or a standby address that is silent or answered by some other listener; the last is never folded into the others. `misowned` exists because an answer was once the whole of `observed`'s evidence. On the service's active host the port's owner is resolved by launchd label through the same reader `service serving` uses, so a declaration pointing at a port another job holds is a failure here rather than a green row. Other hosts reach the service through their own resolver adapter and are not judged on ownership, because that socket is owned by the resolver by design. Exits non-zero on `unreachable`, `misowned` and `standby_serving`, counted separately: the first usually means the service needs attention, the second means the declaration does, the third means a standby unit is running; the service reconciler's next pass stops that declared managed service on its host, leaving it enabled (outcome action `stop_standby`).
  • stado service status — One service's state everywhere it is managed. A `failed` row carries launchd's last exit status. With `--lines` it also carries that many lines of the unit's stderr tail, read from its host the way `service logs` reads them; without it the block names the `service logs` command that reads them.
  • stado service roles — The `stado serve` roles process PID runs on this host, from its kernel argument vector, or with --resolver-state what the resolver last published here. Asked over the host channel before a role's old unit is retired or handed over
  • stado service image — The executable image a managed unit's process runs
    • stado service image refresh — Put one unit back on the file its `ProgramArguments` name, and prove it landed. The verb behind `registry doctor`'s `stale-unit-image` row. It refuses a unit that is not stale, naming the identity it found, because a command that restarts whatever it is pointed at is a restart button. It re-reads the image afterwards and exits non-zero if the restart did not change it: launchd re-execs the declared path, and a process can respawn under `KeepAlive` straight back onto the same unlinked inode it had just left. One unit per invocation. There is no `--all`: three stale units is three deliberate commands. Local only — which image a process is executing is readable only on the machine holding that process.
  • stado service runner-runtime — The macOS GitHub runner runtime an adopted service launches
    • stado service runner-runtime repair — Restore upstream signed macOS GitHub runner apphosts without restarting
  • stado service restart — Restart one managed unit, without a full host-recovery pass. The command answers when the restarted unit serves the port the service directory declares for it (SERVING `serving`), or with the unit's own reason it cannot: its port is held by another job, launchd holds no process for it, it died and launchd started another one, or its process settled on other ports than the declared one (`not_serving`, exit non-zero). A unit with no declared port answers `no_declared_port` at the kickstart. Elapsed time alone never ends it.
  • stado service recoveries — The services this host found standing and recovered: each beacon pass asks every declared service the question its catalog entry declares (`service.answering`), and one that answers nothing longer than the resolver's declared refresh interval is repaired with its declared step, restarted, recorded here and alerted. A service on another host that holds this host's resolver requests that long is recovered from here the same way, over that host's registry SSH channel, and its record names this host as `observed_by`. Reads this host's register, oldest first
  • stado service update — Move an already-managed service onto a new artifact version. `deploy` installs a unit that is not yet managed and refuses to touch one that is. This is the other half: the unit is left exactly as it is, the new version is placed beside the running one and `current` is relinked, so the change takes effect on the next restart and a rollback is a relink rather than a redeploy.
  • stado service release — Install and activate one service release, rolling back on failed readiness
  • stado service show — What a managed unit actually runs: its program, arguments and unit file. `env` answers what the unit runs *with*; nothing answered what it runs. That gap is why a restart that dropped every argument after the program path looked like a broken service rather than a broken restart.
  • stado service stop — Stop one managed unit, including a process the unit no longer owns. `retire` removes a service from management; this only stops it. The difference matters when a restart has previously spawned the program outside its own label: launchctl then disowns it, the stale process keeps the port, and every later restart dies on "address already in use" while the broken instance serves on. On Linux a refused systemctl stop names the unit, scope, exit status and host error. The command then reads the unit's actual state; an active, transitioning or unreadable answer is not a completed stop.
  • stado service secret — One Skarbiec field in a service's runtime env file
    • stado service secret sync — Synchronize one Skarbiec field into a service's runtime env file. The value is read through the isolated service-verifier grant and carried in the SSH request body. It is never printed or placed in argv.
  • stado service file — One file in a managed service's target home, copied in or out byte-exact
    • stado service file sync — Synchronize one local file into a managed service's target home. The content travels only inside the approved encrypted channel's request body. It is never printed or placed in an argument vector, and the destination is replaced atomically with owner-only permissions.
    • stado service file fetch — Copy one file OUT of a managed service's target home, byte-exact. The opposite direction of `file sync`, and the byte-exact counterpart of `env show --env-file`. That read sanitizes every value it reports — printable ASCII, quotes and backslashes replaced, long values clamped — because its job is to let an operator judge a file without a secret crossing the channel. The consequence is that it can diagnose a file and can never reproduce one byte of it, so live operator tooling that exists only on a host could not be put under version control without copying it off by hand, outside the approved channel. The host hashes the file itself, the bytes travel base64 inside the same encrypted channel's response, and the digest is recomputed HERE over the decoded bytes: a payload that lost a chunk decodes into something shorter and perfectly valid, so only two independently computed SHA-256s catch it. A mismatch writes nothing and exits non-zero. `$HOME` confinement and symlink refusal are `env show`'s, word for word. A path that is a directory inside the home answers `directory`, and a path with no file whose directory exists inside the home answers `missing`; both carry that directory's entry names (`entries` in `--json`, one per line on standard error otherwise, a directory's ending in `/`), so a guessed file name is corrected by the same read. Names only: no other file is opened and nothing is written.
  • stado service env — One managed unit's environment: show it, set or unset one key, and check the endpoints its env file declares
    • stado service env show — Show a managed unit's environment. Without `--env-file`: the effective environment the unit runs with, parsed from the plist or systemd unit and its drop-ins; a value whose variable name looks like a credential is replaced, in the table and in `--json` alike. With `--env-file` (and `--host`): the owner-controlled file a launcher `.`-sources, which on this fleet is where the interesting values live. Every assignment is listed in FILE ORDER with its line number, and a key assigned twice is reported twice — `effective` for the last assignment, `shadowed` for every earlier one — because a sourced file assigns top to bottom and a later duplicate silently wins. A value whose key looks like a credential is withheld, and a URL carrying userinfo is withheld whatever its key is called; an endpoint, a port, a flag or a `$REFERENCE` is shown whatever its key is called. The decision is made ON THE HOST, so a withheld value never crosses the channel.
    • stado service env set — Replace one key in a managed runtime env file or systemd definition. The value is read from an owner-only local file and travels only inside the approved encrypted channel's request body. A systemd unit or its own .conf drop-in is updated in place; the manager reloads changed definitions without restarting the running service.
    • stado service env unset — Remove one key from a managed env file or systemd definition
    • stado service env check — Does this unit's env file agree with what is actually listening? Every loopback URL or port the file's effective assignments declare, checked against the host's own socket table, with the process that holds each port named. `host inventory` does this for forward markers; this does it for a unit's environment. Exits non-zero when a loopback endpoint is declared and nothing is listening there, and when the check could not be performed at all.
    • stado service env write — Host primitive used by `set`/`unset` on a systemd unit: set (with --value-stdin, the base64 value on standard input) or remove one `Environment=` key in the file on this very host. The value never appears in argv, where every other process on the host could read it
  • stado service serving — Is the DECLARED unit the process on its own port? `show` reports the unit declaration; `env check` reports whether anything answers on a declared port. Neither establishes that the listener belongs to this unit. Another job can use the same argument vector while holding the declared port. Ownership is decided by launchd label, never by argv. The pid holding each port is walked up its own parent chain until a pid appears in `launchctl list`, because a launcher script is the job and the server it starts is the child that holds the socket. A label that cannot be read — a system LaunchDaemon is invisible to an unprivileged `launchctl list` — is reported `unknown`, never as "nobody owns it". Verdicts are `serving`, `not_serving`, and `unknown` for a question that could not be answered; the third is never folded into either of the others. Exits non-zero on anything but `serving`; an unreadable owner cannot establish that the declared unit serves the port.
  • stado service grant — The Skarbiec grants this service's consumers hold: show the declared ones, mint them, or reconcile one with an existing token file
    • stado service grant show — The grants this service's consumers declare, as minting would issue them; mints nothing
    • stado service grant mint — Mint every grant this service's consumers declare, through the same path `grant sync` uses, so a product's credential need is written where the service is declared instead of remembered as flags. A grant declared for Stado's own consumer is not minted, because a mint replaces every capability Stado holds: each `read:<item>#<field>` it names is added to that grant on the vault owner, keeping the bearer in the declared token file there; any capability other than a read is refused for that row
    • stado service grant sync — Reconcile one Skarbiec consumer grant with an existing owner-only token file. The bearer never leaves the managed host: its local Skarbiec reads the raw file and records only its hash while replacing the declared grant.
  • stado service token-file — The owner-only raw bearer file a host binds to the fleet object store
    • stado service token-file sync — Write one Skarbiec item field into an owner-only raw bearer file. `WC_STADO_STORAGE_TOKEN_FILE` has to name a file whose entire content is the bearer, because `queue/stado_object.rs` resolves a token file and nothing else. `secret sync` can put a Skarbiec field into a unit's env file, and `grant sync` can reconcile a grant against a token file that is already on the host, but nothing could create that file. So the only remaining way to bind a host to the fleet object store was to hand-copy a secret onto it, which is the one thing the fleet-wide "everything through Stado" rule exists to prevent. Lacking the file, a queue agent binds its `JobStorage` to a device-local store instead and publishes no capacity while fleet jobs wait on a host every surface reports as in-sync -- a fleet claim written to a device store does not fail, it succeeds where nobody else can see it. The value is read through the isolated service-verifier grant and carried in the SSH request body. It is never printed or placed in argv.
  • stado service auth — A managed service's bearer against its own loopback endpoint
    • stado service auth check — Verify a managed service's bearer against a read-only loopback endpoint. With `--repair`, a failed check atomically synchronizes the secret, restarts the unit, and checks the endpoint once more.
  • stado service adopt — Bring an existing launchd/systemd unit under management. The unit must already exist on the host — adoption claims what is there, it does not create anything. The host is probed first and the registry records what the host reported, not what was assumed.
  • stado service onboarding — Echo onboarding product metadata of managed services: attach it to one, or print every service that carries it
    • stado service onboarding set — Attach central onboarding product metadata to a managed service. The metadata becomes part of the canonical Stado registry and is emitted by `service list --json` for Echo catalog synchronization.
    • stado service onboarding catalog — Registry-managed services carrying Echo onboarding product metadata. Emits the versioned JSON envelope accepted by Echo's Stado catalog synchronization endpoint.
  • stado service retire — Remove a service from management: bootout/disable and forget. Unit files are left on disk. Retiring is a management decision, not a deletion. On Linux, systemctl mask and the following is-active read must prove the unit is no longer running. A failed mask, active or transitioning state, or unreadable answer refuses to forget the declaration and reports the observed scope and systemctl result. The unit is stopped first; the managed record and every service directory route on this host whose `managed_service` names it, by service name or unit id, are then withdrawn in one versioned registry write. A route whose replacement catalog unit is declared on the same host is handed to that unit instead. A failed stop leaves the declaration and routes untouched.
  • stado service handoff — Hand a placed logical service's lifecycle to its active signed release. The release must already be committed and ready, and the legacy unit must already be inactive. One conditional registry write then removes every legacy restart identity while preserving the logical route, placement dependency, probes, and release policy. Repeating an incomplete handoff rechecks the same release, rollout generation and exact legacy files before committing against the current registry. The prior commit remains in the receipt's recovery history. A completed receipt cannot be reapplied against a mismatching registry.
  • stado service remove — Remove a service entirely: stop it, withdraw its declaration and the directory routes that name it in one registry write, then delete its unit file from the host — the operation an operator means by "remove this service", which `retire` deliberately is not. The file path comes from the registry declaration, never from operator words. A failed stop or withdrawal leaves the declaration and file in place; a file-delete failure leaves the service retired and reports that partial state
  • stado service deploy — Install a new unit under management: render, push, bootstrap, record
  • stado service declare — Declare a service against the fleet's one contract. Writes source, run spec, observation and consumer declarations into the service directory so `deploy` can use them without repeating its inputs.
  • stado service ensure — Assert the unit a host must be running, over ssh, idempotently. Reads the current unit first: a matching running program is `already_correct`, an existing stopped unit is started in place, and a missing unit is installed. Repeated calls use the same declaration. Where the per-login launchd domain does not exist, ensure renders the unit for the system domain under /Library/LaunchDaemons. An existing matching definition is restarted in place with `kickstart -k`. When launchd's retained Program or ProgramArguments differs from the desired definition, ensure first validates the replacement executable and complete rendered plist, then reloads that definition once and verifies launchd's readback and running executable. An unreadable retained definition is refused without touching the job. For a catalog product, every other unit on the host that runs the product's program is its predecessor, found from what it runs; no unit name is listed anywhere. A unit the product replaces whole is retired before the start and its loaded and autostart identities withdrawn in every applicable launchd domain or systemd manager; one whose work is a role of the host Stado process is retired only after the ensured live program proves it runs every such role, otherwise it is reported `kept`. Failed retirement fails the command and retains the actual partial state. The autonomy reconciler uses the same proof on each pass. Catalog `acquisition_scopes` are copied from the installed release to `$HOME/.stado/files/` and registered with the host vault before retirement or startup, as with `stado credentials acquisition-scopes sync`. A missing scope file or refused registration leaves the host unchanged.
  • stado service logs — Tail a managed unit's log over the approved channel
• stado egress — Run host-local network egress processes under Stado service management
  • stado egress mobile — Route Weles through a tethered phone interface
    • stado egress mobile serve — Run a loopback HTTP proxy whose upstream sockets use one interface
• stado product — The Wisent product catalog: install, update, sign and build every product surface
  • stado product catalog — Read and validate the authoritative Wisent product catalog
  • stado product dependencies — Read from each product's source every call it makes to another catalog product (program, resolver, hosted API, state directory, environment) and refuse a product the catalog does not show running without it: a dependency undeclared, declared with no alternative (bound; by design when the catalog says why in bound_because), or with no alternative_source in the workspace
  • stado product registry — Mutate the authoritative product registry without replacing neighboring records
    • stado product registry add — Register one product
    • stado product registry set — Update one existing product
    • stado product registry rm — Remove one product from the authority
  • stado product create — Provision private repositories and a preview product through Wisent Integrations
  • stado product install — Install one product surface from its canonical recipe or exact qualified release
  • stado product update — Update one product surface while retaining exact rollback bytes
  • stado product finish — Finish, with this binary, an installation whose build an install retained after its quality gates and build passed: sign, stage, place and activate it without building again. An installation of the running Stado hands its built Stado this step; a revision with no retained build is refused
  • stado product status — Inspect recorded installation, source, signatures, actual readiness and the operation holding its lock, with its step
  • stado product remove — Remove only owned paths and the declared service surface
  • stado product rollback — Restore exact retained installation bytes without rebuilding
  • stado product locks — List every product surface lock, its recorded owner, process identity, observed state and corruption
  • stado product sync — Reconcile installed surfaces against canonical origin/main
  • stado product signing — Inspect and preserve stable Apple native code identity
    • stado product signing inspect — Inspect actual signatures on files or bundles
    • stado product signing sign — Sign staged code and atomically replace only verified targets
    • stado product signing report — Read signatures of a product's recorded installation
    • stado product signing reconcile — Repair unstable signatures on recorded installed paths
    • stado product signing residue — Report obsolete signed installer staging paths
    • stado product signing stage — Sign only the native files declared in a release manifest
    • stado product signing notarize — Notarize a signed .app with Apple's notary (AC_API_KEY_ID, AC_API_ISSUER_ID, AC_API_KEY_P8), staple it and check Gatekeeper; the notary's answer goes to --evidence, default $WISENT_OUTPUT_DIR/notary.json
  • stado product paths — Inspect actual executable ownership: PATH collisions and executables in ~/.stado/bin and ~/.local/bin no installed product owns
  • stado product cargo — Run Cargo against canonical checkouts or declared release-worker source inputs
  • stado product compiler-cache — Report, install or remove the compiler cache (Kache) every Cargo build Stado runs goes through
  • stado product build-trees — List or remove the rebuildable trees in the workspace's checkouts — CACHEDIR.TAG directories, Stado's former install runs, desktop .build — from this process
  • stado product node-runtime — Report or install the Node.js release every Node product build Stado runs uses
  • stado product source-bundle — Release build step: the checkout's files in a reproducible $WISENT_OUTPUT_DIR/release/<name> with each file's digest, and release/SOURCE_REVISION from $WISENT_SOURCE_COMMIT when it is set
  • stado product python — Release steps of a Python product: its wheel and sdist, their PyPI upload, or a zip application
  • stado product npm — Release steps of an npm package
  • stado product schema — Release steps of a database-schema product on any engine: sqlite, postgres or supabase
  • stado product deliver — Release deliveries to hosting providers, run by a manifest's deliveries
    • stado product deliver schema — Apply the verified release's migrations to the product's database on its engine. postgres: verify WISENT_RELEASE_ARCHIVE against WISENT_RELEASE_SHA256, read its one database-schema.tar, then apply the migrations the database SCHEMA_DATABASE_URL names has not recorded yet, each with its version recorded in wisent_schema_migrations; writes schema-receipt.json. supabase: push supabase-source.tar (migrations, functions) to the project SUPABASE_PROJECT_REF with SUPABASE_ACCESS_TOKEN and SUPABASE_DB_PASSWORD, carrying split migrations in as applied. Declared supabase/function-secrets.json names are resolved from injected environment values before mutations and published before functions deploy; writes supabase-receipt.json with secret names, never values. sqlite has no delivery: the product applies its own migrations on open
    • stado product deliver testflight — Upload the verified release's .ipa to App Store Connect with xcrun altool (AC_API_KEY_ID, AC_API_ISSUER_ID, AC_API_KEY_P8); writes testflight-receipt.json
    • stado product deliver github-mirror — Mirror the verified release on GitHub (WISENT_MIRROR_TOKEN): tag v<version> at the release's SOURCE_REVISION, a release titled '<title> <version>', and the archive as its asset; writes github-mirror-receipt.json
    • stado product deliver npm — Publish the verified release's npm-package.tgz unchanged (NPM_TOKEN), running no package scripts; writes npm-receipt.json
    • stado product deliver render — Start a deploy of the Render service of this name (RENDER_API_KEY); writes render-evidence.json with the deploy and the status Render answered
    • stado product deliver vercel-files — Upload the source/ files of a bundle in the verified release to Vercel (VERCEL_TOKEN) as a production deployment and wait until it is ready; writes vercel-evidence.json
  • stado product linkage — Prove each .app bundle's @rpath dependencies resolve inside it, as dyld resolves them
  • stado product crx3 — Pack a browser extension directory as a signed CRX3 and its Omaha update manifest, refusing a key whose extension id is not the pinned one
  • stado product tree-archive — Pack one directory, under its own name, as a reproducible .tar.gz: path order, no owner, time zero, modes 0755/0644, links kept
  • stado product swift — Build and index canonical Swift sources or restore release dependencies
  • stado product editor — Serve editor build settings or inspect live workspace instances
  • stado product surface — Refuse a Swift package revision whose version tag disagrees with what it did to the library's public API, as swift api-digester reads it against the released tag
  • stado product documentation — Check actual published documentation and GitHub repository policy, or generate a documentation site's search index
    • stado product documentation cli-pages — Verify linked command pages and canonical URLs on product websites
    • stado product documentation markdown-policy — Find repository Markdown beyond the root README.md
    • stado product documentation index — Generate search-index.json and the docs/index.html topic cards of a static documentation site from the pages its docs-manifest.json lists; --check writes nothing and fails when either file is stale
  • stado product changelog — Move CHANGELOG.md's Unreleased entries into changelog/: as the given release in the version-bump commit, or as spilled parts while the release is prepared
• stado placement — Atomically relocate a declared service group between registered hosts
  • stado placement move — Relocate one complete service group to another registered host, or, with --authority, take the registry authority role on --to-host while the declared authority does not answer
  • stado placement evict — Stop an instance running where the directory places nothing. `doctor`'s placement row tells the operator to end exactly this, and until now no command could: `service stop` refuses a host that declares no such unit, which is the definition of the squatter it is asked to remove. The port comes from the directory, so an instance can only be evicted from a host the directory does NOT place it on.
  • stado placement standby — Make a registered host a place this profile may move to: deliver each service's program (a managed program now; a release-controlled tree through the host's own agent), stage each unit rendered from the service catalog where the move starts it (installed, not loaded, not declared), and write the host into the profile and the directory once every unit is staged. Idempotent; a unit already running on the host is refused as a second active copy, and a pass that stops at a pending rollout says so and the next pass continues
• stado resolver — Resolve logical services and run the local Stado data plane
  • stado resolver resolve — Resolve one logical service for an authorized workload
  • stado resolver status — Whether this host's resolver is ready, and why not when it is not. Reads the registry and the state the `serve --resolver` role publishes to [`state_path`], so diagnostics remain available when the resolver's own API is down. A non-ready result exits non-zero. Every wait an adapter still stands on is listed under `waiting_opens` with its service, consumer, bind, destination host, endpoint and phase: `open` until the host answers the channel open, `answer` from the client's first byte up the channel until the service's first byte back. One waiting longer than the target's declared refresh interval is a blocker, because its client holds an accepted connection that receives nothing, and every request that would go through that adapter is refused with its sentence until it ends. The live process's `/health` endpoint remains the check for workloads already connected to it.
  • stado resolver channels — Read local published channel waits without registry access or network probes
  • stado resolver relay — One caller's own route to a service placed on another host, carried over this process's SSH session to that host while the caller holds this process (its standard input open). Prints the loopback URL to dial first, as one line (`--json`: one document). For a service placed on this host the service's own loopback URL is printed and the process ends. The route the host resolver's adapter would give, when that resolver holds no listener for it
  • stado resolver api — The host's resolution API
    • stado resolver api reassign — Give TARGET's resolution API a loopback port that TARGET hands out now (`stado host local port` run there), recorded as `targets.<target>.service_resolver.api_bind` under the generation it was read at. The host's resolver rebinds its API when it reads the registry; consumers ask the resolver at every start
• stado database — Resolve fleet databases: placement endpoint and credential coordinate
  • stado database list — List declared databases and whether each is placed. A profile with no database declaration returns an empty list. A present malformed database section is refused, not reported as empty.
  • stado database resolve — Resolve one database for an authorized consumer. Returns the placement endpoint when the service directory places the database, and always the Skarbiec item to acquire the credential from. The consumer must be declared on the database; the credential value is never printed.
  • stado database declare — Declare a database in the Stado configuration. Writes `database_api.databases.<name>` through the same validated, atomic write every other configuration change uses. The credential item `<name>-database` is implied; provision its fields with `stado credentials put <name>-database`.
  • stado database create — Place a fleet database, create a Supabase project, or declare an existing external server. The default provider is `fleet`: Stado runs postgres (default) or sqlite (`--engine sqlite`) on one fleet host -- the vault owner unless `--host` names another -- with no vendor and no bill, through `stado database place` on that host. `supabase` creates a hosted Postgres project in the organization and region of `--anchor`'s project, or, without it, the one organization and region every project the token sees shares, and refuses unless `--accept-monthly-usd` covers what one more project adds to the compute bill. `external` brings a server of any engine the user already runs anywhere (Postgres, MySQL, MongoDB, Redis, SQL Server, ...; RDS, Cloud SQL, Neon, PlanetScale, Atlas, Azure, their own server): the connection URL is read from standard input and names the engine, and `--ca-certificate` names the server's certificate authority. Every way, the credential item `<name>-database` is written into the owner vault and the database is declared for its consumers. A fleet or supabase database of that name is reused, never duplicated; an external one is re-pointed at the URL given. The database name and consumer identities are checked before placement, provider requests or credential writes. An invalid name or consumer identity exits with code 2 and names the rejected value before any database is created or its credential item is rewritten.
  • stado database place — Place a fleet database on this host: the host-side half of `create --provider fleet`. Initialises the engine's data under `~/.stado/databases/<name>/`, writes the credential item `<name>-database` into the owner vault and, for postgres, installs the managed unit `<name>-database` that serves it over TLS with a certificate authority of its own. A database already placed here is reported, never initialised twice.
  • stado database adopt — Bring a declared database's credential item in line with its hosted Supabase project. Rewrites `<name>-database` from the management API: coordinates, pooler with its transaction-mode `pooler_url` and session-mode `session_url`, the revealed API keys (legacy `anon_key` and `service_role_key`, every named key as `publishable_key_<name>` or `secret_key_<name>`) and an active custom hostname as `custom_url`. Fields another owner put on the item stay, and the password is kept from the item, read from --password-file, or, with --rotate-password, replaced: a new one is set on the project through the management API and written on the item, for a project whose password no item holds. Without NAME, every declared database whose item records a Supabase `project_ref` is adopted again, so a rotated key lands. Items are read and written in the owner vault, from any host: off the owner through the host channel. --check writes nothing and exits non-zero when an item differs.
  • stado database push — Make a host's database declarations equal to this machine's. Reads HOST's config file whole (its `config show` omits the block), writes this machine's `database_api` there through `host config set` when the two differ, and reconciles --service so the running process reads it. --check writes nothing and exits non-zero on a difference.
  • stado database remove — Remove a database declaration from the Stado configuration
  • stado database destroy — Destroy a database Stado created: the inverse of `create`. A fleet database: removes the managed unit `<name>-database` that serves a postgres database on its host; its data directory `~/.stado/databases/<name>/` is left in place and named. A Supabase database: deletes the hosted project with every row it holds, and only with `--delete-project`. Then the credential item is deleted from the owner vault (restorably, as Skarbiec deletes) and the declaration is withdrawn last, so a run that stops part-way can be run again. An external database is a server Stado does not run: it is refused, and `remove` withdraws its declaration. On the vault owner, provider metadata is read with the owner's keys, without a workload bearer. Other hosts require access to the named credential item; hosted-provider API authorization is still required.
  • stado database grant — Grant one or more consumers access to a declared database. Adds each consumer to the declaration and widens that consumer's own Skarbiec grant (`~/.stado/<consumer>-skarbiec-token`) to read the database's credential item, keeping its bearer and every capability it already holds. Granting a consumer already on the list settles its Skarbiec read again; a consumer Skarbiec still refuses is named and the command exits non-zero. The result's `declaration_changed` field reports whether this command added a consumer, not whether Skarbiec granted access. On refusal, the error distinguishes a changed consumer declaration from an unchanged one. Consumers added before a refusal remain declared; retrying settles their credential access again.
  • stado database revoke — Revoke one or more consumers' access to a declared database
  • stado database client — Let the database's library client read what `stado_database::connect` reads. A product opens its database through the `stado-database` crate as the Skarbiec consumer `<name>-database-client`. This widens that consumer's grant on the vault owner to the fields the crate reads: `pooler_url`, plus `ca_certificate` for a server and `session_url` for Postgres. The bearer in the owner's `~/.stado/<name>-database-client-skarbiec-token` is kept, so no host's copy needs syncing again. Running it again changes nothing. A client the vault owner holds no bearer for is refused with Skarbiec's answer.
• stado web — Host a web product on the fleet: build it, run it, publish its hostname
  • stado web declare — Declare a web product: where it runs, as whom, and on which hostname. With `--redirect-to` the product is a hostname and a target and nothing else: the edge answers it with a 308 and there is no unit, no release and no host, so `--host`, `--port` and `--consumer` are refused beside it.
  • stado web list — List declared web products with their host, port, hostname and unit
  • stado web remove — Remove a web product: stop and forget its unit, drop its DNS record
  • stado web deploy — Install the published release as a managed unit and deliver its environment, then verify that it answers
  • stado web status — Report each product's declared edge, live unit/port state, and observed DNS. A missing or invalid selected Stado edge is reported in edge_error, never accepted as an external edge with unknown addresses. Any non-serving product makes the command exit with status 1.
  • stado web route — Publish a declared hostname: edge, then DNS, then wait for the certificate
  • stado web schedule — Requests the product's unit is sent on a cron: declared here, sent by fleet schedules that `route` creates and `remove` deletes
    • stado web schedule set — Declare or change one scheduled request of a web product
    • stado web schedule remove — Withdraw one scheduled request from a web product's declaration
    • stado web schedule list — List declared scheduled requests and the fleet schedules sending them
  • stado web edge — The public edge: the fleet host that holds an address and terminates TLS for every `stado`-edge hostname
    • stado web edge provision — Create the edge host on Azure and record it as the fleet's edge
    • stado web edge declare — Record an edge host that already exists, provisioning nothing. The path for a host Stado did not create: an operator's own VM, a colocated box, or an edge provisioned before this command existed.
    • stado web edge status — The declared edge, whether it answers, and what it terminates
    • stado web edge hostnames — Reconcile: the hostnames the edge must terminate against the ones its proxy currently does
    • stado web edge remove — Undo `provision`: delete the edge's Azure resources and forget it. The one command that reverses the only thing in this capability that spends money. It refuses while any product still names the `stado` edge, because deleting the host those hostnames resolve to is an outage rather than a cleanup — retract them with `stado web remove` first, or pass `--orphan-hostnames` to say that is what you mean.
  • stado web origin — Public origins: the hostnames the internet reaches a Stado surface through, and whether anything outside this network can resolve them
    • stado web origin list — List every declared public origin
    • stado web origin status — Report each declared origin's public resolution, its target's publication, and the origin the live public edge actually selected. Any origin that is not `serving` makes the command exit with status 1, and an origin the edge selected that nothing declares is reported as `origin-undeclared` rather than omitted.
    • stado web origin declare — Declare one public origin in the canonical registry. Refused before any write when the hostname has no public A or AAAA record: a name nothing outside this network can resolve is not a public origin, whatever is listening behind it.
    • stado web origin remove — Withdraw one declared public origin. The declaration goes; the target's publication is left exactly as it is, because a handler table is shared by every product on that hostname and this command owns only the declaration.
    • stado web origin withdraw — Withdraw every public HTTPS Funnel handler on TARGET, including undeclared paths, and remove its public-origin declarations. Private backend processes are not stopped
    • stado web origin converge — Make the declared publication carry every declared path, then read the publication and the public name back. A `web-edge` origin converges through `stado web route` for the declaration that owns its hostname; a `tailscale-funnel` origin through the node's own handler table. Without `--apply` nothing is sent and the receipt is the plan.
    • stado web origin url — Print the public URL of PATH on the one declared origin that publishes it, with each `--query KEY=VALUE` appended URL-encoded. A desktop release stamps its Sparkle feed with `stado web origin url /api/release/appcast --query product=<product>`. Refused when no declared origin publishes PATH, or when several do.
  • stado web quality — Install the locked dependency tree and run the product's own checks. Runs on a release worker, inside the checkout Stado prepared. The recipe in `.wisent-release.json` names this command; an operator does not run it by hand.
  • stado web build — Build the checked-out web product and stage its runnable tarball. Runs on a release worker, inside the checkout Stado prepared.
• stado dns — Own the records of a DNS zone Stado manages at its registrar
  • stado dns list — Print every record in one zone, as the registrar holds it
  • stado dns set — Add or replace one record, preserving every other record in the zone. The zone is read, the one name and type are replaced, and the whole list is written back. The write is verified by reading the zone again; a record that is not visible afterwards is a failure, not a warning.
  • stado dns remove — Remove one record, preserving every other record in the zone
  • stado dns delegate — Move a zone's serving to the DNS host named by --provider: every record written there first, then the registrar's nameservers pointed at the host's and read back. Refused before any write when the zone holds a record type the host cannot carry (Namecheap URL redirects), naming those records.
  • stado dns undelegate — Hand a zone delegated to the DNS host named by --provider back to the registrar's own nameservers. Refused, naming the records, while the host serves a record the registrar's host list does not hold; nothing is changed then.
• stado inference — Plan, deploy, route and operate local OpenAI-compatible inference. Being replaced by the service declaration contract: a model server is a service like any other, declared once with `stado service declare` and deployed with `stado service deploy`. This plane keeps working while its declarations migrate; add nothing new to it.
  • stado inference plan — Inspect the target and persist an immutable, registry-bound plan
  • stado inference apply — Execute one persisted plan if its registry precondition still matches
  • stado inference list — List declared inference deployments without contacting hosts
  • stado inference status — Read one deployment's state from the latest host beacon
  • stado inference logs — Read one deployment's systemd journal over the managed host channel
  • stado inference plan-logs — Read systemd logs for a runtime that has not committed its plan
  • stado inference doctor — Inspect runtime, GPU, endpoint and authentication
  • stado inference verify — Send one minimal authenticated OpenAI-compatible completion. Without `--from` the call is made on the deployment's own host, which proves the model answers and nothing about who can reach it. `--from` sends the same completion from another registry host, so "the model is up" and "the consumer can reach it" stop being one answer.
  • stado inference route — Atomically update a logical route
    • stado inference route set —
    • stado inference route remove — Retire one alias from the route table. Refused unless `--expected` names the destination it currently has; the gateway stops serving the alias in the same commit, so remove it only after every consumer has stopped asking for it
    • stado inference route show — Per alias, what the registry declares and what the gateway host is actually serving. Exits non-zero when the two disagree; `--repair` stages and commits the declaration onto the host; `--probe-bearer-role` also sends one real request per declared alias and exits non-zero when a destination does not answer
  • stado inference rollback — Reinstall the previous deployment generation
  • stado inference blockers — List GPU compute processes with PID-reuse-safe identities
  • stado inference release — Gracefully stop one exact GPU process; optionally escalate to KILL
  • stado inference abort — Stop runtime left by an uncommitted plan and optionally remove its cache
  • stado inference retire — Stop and forget a deployment; model cache is retained by default
  • stado inference init-credential — Create the central local-inference bearer in Skarbiec
• stado stream — Provision and operate an interactive display session on a host, and stream it to a client (Moonlight): the way to use a fleet GPU interactively, since a board cannot be borrowed over a network
  • stado stream probe — Report what a host could render and encode, without changing it
  • stado stream declare — Declare that this host carries an interactive session, in the registry
  • stado stream apply — Reconcile the host to its declaration: screen, session, Sunshine, units. Retains both native service definitions in the canonical registry, so later service repairs preserve Xorg ordering and Sunshine's session preconditions. Openbox diagnostics are retained by the service journal.
  • stado stream status — What the session is doing right now, and where to point the client
  • stado stream pair — Hand Moonlight's four-digit PIN to Sunshine (no browser involved)
  • stado stream stop — Stop the session. `--purge` also removes the units and the screen
• stado doctor — Ordered deployment preflight: config, storage, provider auth, quota, release channel, agent template, VM identity, registry, queue pause state and alert channels. Exits non-zero if any check FAILs
• stado workload — Place declared work on an eligible fleet host and return its stream or receipt
  • stado workload list — List every workload kind compiled into this Stado build
  • stado workload run — Place and run one declared non-interactive workload
  • stado workload status — Read the latest report for a workload kind or receipt identifier
  • stado workload attach — Attach this process's stdin and stdout to an interactive workload
  • stado workload start — Start a detachable workload that keeps running without this process
  • stado workload sessions — List the detached sessions the fleet is running
• stado capacity — What every host has, what is held on it, and a fixed-time hold on one
  • stado capacity list — Every host's published capacity, net of the reservations held on it
  • stado capacity reservations — The reservations held on one host, or on every host
  • stado capacity hold — Take one declared workload kind's reservation on a host and hold it, heartbeating it, until this process receives SIGINT, SIGTERM or SIGHUP; the host publishes itself net of it meanwhile. Ends with the reservation released
• stado repair — Inspect and apply the ordered repair steps services declare
• stado runner — Operate declared GitHub runner profiles across registry hosts
  • stado runner list — List the runner profiles compiled into this Stado build
  • stado runner install — Install or reconcile one declared profile on a registry host
  • stado runner status — Read one or every declared profile on a registry host
  • stado runner restart — Restart one declared runner by cycling its role on the host's Stado unit, and read GitHub's view of it afterwards
  • stado runner remove — Deregister and remove one declared runner from a registry host
  • stado runner report — Read installed profiles, registration scopes, listeners and job slots fleet-wide
  • stado runner credential — Resolve the declared GitHub credential route and confront it with GitHub
  • stado runner model-review — Mint the repository's Brama model-review bearer and install it as that repository's secret. Registering a runner does not do this: a Brama that refuses the route would otherwise stop a repository from getting a runner at all, for a secret its checks may never read
  • stado runner diagnostics — Read what a runner that will not start is saying: its unit's verdict and its own diagnostic log, whole
• stado space — Read and reclaim a host's declared space, including guarded file operations
  • stado space report — Read disk, memory, inventory, build caches, and janitor state as one report
  • stado space reclaim — Reclaim only fleet-declared stages, previewing unless --apply is present
  • stado space file — Perform one guarded single-file space operation
    • stado space file remove — Remove one regular file from a Stado-managed area of TARGET
    • stado space file retire — Archive one obsolete executable or launchd declaration without deleting its bytes
    • stado space file local — The halves of `retire` and `remove` that run on the target itself, started over the host channel with the target's installed Stado
      • stado space file local retire — Archive one obsolete executable or launchd declaration on this very host, without deleting its bytes
      • stado space file local remove — Remove one regular file from a Stado-managed area of this very host; prints one `STADO_REMOVE_FILE` report line
  • stado space volume — Mount or unmount a disk the host has attached, durably, so the fleet can be told to use it
    • stado space volume mount — Mount one block device at a mount point and write its fstab line by UUID. Mounts, never formats: a device with no filesystem is refused by name. `stado space report TARGET` lists the host's block devices and which of them nothing has mounted.
    • stado space volume unmount — Unmount the filesystem at a mount point and remove the fstab line `volume mount` wrote for it; the data on the disk is untouched. A busy filesystem is refused with umount's own error and fstab is left as it was. An fstab line stado did not write is refused by name. A mount point that is neither mounted nor declared is reported and nothing changes.
  • stado space work-root — Read or declare where TARGET's agent keeps the fleet's work: job trees, build caches, published free space. With no `--path` this prints the declaration in force. With `--path` it creates the directory on the host owned by the agent's account, refuses a path on the root volume, and writes `targets[].work_root` through the canonical registry's compare-and-swap. The agent uses the new root once its unit restarts it.
  • stado space relocate — Relocate object-store keys on the host that holds their bytes
• stado route — Inspect and operate service-directory routing without naming a product
  • stado route list — List every declared service, endpoint and locally open forward
  • stado route open — Open one service's declared forward marker locally or on an endpoint holder
  • stado route close — Close the named service forward and remove its marker
  • stado route capability — Read the capability routes on the host serving SERVICE
  • stado route key — Authorize TARGET's resolver key on the declared directory authority
  • stado route placement — Publish host placement policies selected by directory placement
    • stado route placement publish — Publish to every active host, optionally only mobile-capable hosts
• stado scratch — Lease a disposable target on a registered host, and destroy it when the run ends
  • stado scratch profiles — Read every declared profile: mechanism, platforms and lifetimes
  • stado scratch hosts — Read which registry hosts a lease may be taken on, and why the others may not
  • stado scratch create — Lease a disposable target on HOST, and prove it can be entered
  • stado scratch list — Read every lease HOST holds, with each account's real presence
  • stado scratch destroy — Destroy one lease, and prove the host is clear of it
  • stado scratch reap — Destroy every expired lease on HOST, previewing without --apply