The native operator connection

Native operator connection

Desktop calls Stado's HTTP APIs. It does not search PATH for a Stado command, start that command, or fall back to it when an API request fails. Hosts, Services, Releases, Products, Databases, Inference, Cloudflare routes, Vast, Scratch targets and credential inspection use the same selected source as the console. Existing typed registry, convergence and storage APIs remain separate from the operator command API.

The command API is POST /api/operator/run, with Content-Type: application/json and X-Stado-Action: operator-command. A read request such as {"args":["database","list","--json"]} carries no mutation confirmation. A reviewed change adds "confirmation":"RUN_MUTATION". For example the Databases declaration corresponds to stado database declare NAME --engine postgres --scope read --consumer CONSUMER --json. The server refuses an unconfirmed write with HTTP 403 before executing it. Any top-level command the CLI's own clap tree declares is reachable; a family it does not declare is refused. Command words below the family are read against the same tree: a word that names no command at its level, before the first option or a command's own positional arguments, is refused with HTTP 400 as stado <words> has no command "<word>"; it declares: <its commands>, before any judgement or run. Whether a request only reads is judged by a model through Oko's schema-bound call (oko gateway object) from the argv and the command's own help: the answer is one object whose choice is READ or CHANGES, with its reason, bound to a strict JSON Schema, so --dry-run, --check or --apply count as that command's help says; --help and --version are reads by the parser's own answer. A request whose judgement could not be obtained is treated as a change, the cause is written to the service's log, and the confirmation is required. Loopback retains local trust; remote access uses the operator's authorized Wisent session.

Receipts retain the operation's exit code, stdout, stderr and refusal. A missing exit code is not converted to zero. Truncated output is not accepted as a complete result. Connection and API failures identify the requested endpoint and operation; installing a local CLI is not their fallback. Responses from a previously selected source are not shown as the new source's results. A mutation already accepted by the server is not undone by switching sources.

Service declarations send their JSON in the request's input field and use $INPUT in the argument array. Desktop does not pass a Mac-local temporary filename to a remote service. Secret standard input remains the separate stdin field. A request whose arguments name $INPUT and carry no input is refused with HTTP 400 (args name $INPUT but the request carries no input to stage), never run on an empty file. The receipt's structured member is the command's stdout parsed as JSON, or null when the command printed anything else; the text is always in stdout.

Every operation runs a CLI path the console declares, and those paths are checked against the CLI twice. The API refuses a request whose words name no command, stado <words> has no command "<word>"; it declares: <commands> (HTTP 400), before anything runs. And Stado --operation-paths prints every operation's group, id, path, fixed arguments and the options its fields pass (options) as JSON and exits before a window opens; tests/desktop_api/operation_paths.rs runs each path's --help through the built stado (the Desktop executable named by STADO_TEST_DESKTOP_BIN) and names every operation whose path the CLI does not have, and every option an operation passes that the command's help does not name (` passes

to stado , whose help names no such option`).

Product desktop and CLI installation still targets this Mac, not the selected fleet server. Those lifecycle operations use this device's listener, at the address this device declares: WC_DASHBOARD_BIND and WC_DASHBOARD_PORT, then dashboard.bind and dashboard.port from the Stado profile, then the --bind and --port its com.wisent.stado LaunchAgent runs with — and when that unit runs --port 0, the address its listener announced ([dashboard] listening on http://…) in the unit's error log. Nothing is assumed: with none of them Desktop says so and names the declaration to add. Service lifecycle operations retain the selected source and explicit host. Profile lookup follows STADO_CONFIG, ./stado.config.json, ~/.config/stado/config.json, then ~/.stado/config.json.

Products shows a recipe's declared local signing keychain beside each surface. A source installation of Skarbiec signs from that keychain on the installation host, even while Skarbiec cannot answer; an absent named keychain or identity refusal appears in the mutation result rather than as a successful install. The completed surface displays the receipt's actual keychain and each installed native file's observed signing authority, team and identifier. An exact published release does not sign again. The screen sends the same installation command through the native operator API and keeps its refusal; it has no second credential reader.

The This Mac backend starts com.wisent.stado with --port 0 and takes its endpoint from that announcement.

Cloud deployment setup exposes Installer API. An existing Stado API returns its exact release installer through the read-only equivalent of stado bootstrap --print-install-script. The cloud image verifies and installs that release; Desktop does not run a local Stado command to obtain it. A missing API, refusal or incomplete installer stops provisioning with its error. Local backend hosting still needs the actual Stado service executable because launchd runs that backend, not because Desktop uses it as a command transport. Third-party provider tools retain their own contracts.

Its How it works section takes what the control plane runs with, none of which Desktop or Stado assumes: the control-plane interval in seconds, the container port, the container's CPU and memory written as the provider takes them (Cloud Run and Azure Container Apps 1 and 2Gi, AWS App Runner 1 vCPU and 2 GB), and on Google Cloud the requests one container serves at once. An empty field, or a port, interval or request count that is not a whole number above zero, refuses the deployment by name before anything is created. The selected infrastructure target must state its region (Azure: location) in its metadata; a target without one is refused rather than placed in a region Desktop picked.

The source-bound API journey is kompilator test --manifest-path stado-rs/Cargo.toml --test service-journeys -- journey:: --nocapture. It starts a real isolated service, creates, changes and removes a database declaration, checks its persisted configuration and independent CLI reads, and checks unconfirmed and invalid-input refusals. It retains source identity, executable digest, requests, statuses and logs under .build/desktop-api/.