What the Desktop screens show

The Hosts, Services, and Releases screens of Stado Desktop show the product's own reports. Their commands and refusal handling are described below and in the CLI reference.

• Fleets → Plan expansion… compares sourced investment bundles with current bottlenecks under a total expenditure budget. It edits and saves the versioned catalog, shows missing evidence and exclusions, calculates the selected portfolio's costs, cash gain, ROI and payback through the same CLI implementation, and reads immutable saved plans. Blank money is unknown; neither saving a catalog nor a plan buys or enrolls anything. See Expansion and payback for inputs and refusals.

• Compute providers (Fleet) runs the provider operations of the CLI through the selected native API: stado capabilities --json, stado instances list [--provider P] --json, stado doctor --json and stado quota show read; stado config validate, stado config set|unset <key> and stado credentials item put --host H --role cloud-<provider> --type T change state behind the review dialog, the credential JSON travelling on standard input. It enables any of the fourteen GPU and cloud compute vendors the same way the CLI does and keeps each command's receipt on screen.

• Earning → Provider prices reads stado cost prices --json through the selected native API. It shows the recorded book, observation time and source failures. Enter exact job IDs and choose Read allocation quotes for stado cost quote --json -- JOB_ID...: each row keeps the actual allocation, sourced quote or refusal. Exit zero does not mean every allocation was priced. The full stdout/stderr receipt and exit status stay visible; switching sources discards the previous source's result. No local CLI or copied pricing table is used. See Costs for matching, missing-observation and real qualification requirements.

• Hosts keeps two paths separate. Host-control routes reads stado host link <target> --json, lists the preferred SSH destination and every ordered fallback with its live probe answer, and marks the route Stado selected for a real operation. Beacon network path is the direct/relay path the host reported when it published its beacon; it does not claim to be a host-control route. Manage host-control routes reviews the exact stado registry host path set|remove ... --json invocation before changing the registry, reprobes every route afterwards, and never offers to remove the preferred primary route. Disk scans is the beacon's scans block as the same command carries it: the one-minute load the host's latest scan admission was decided on against its ceiling and the ceiling's source, then every scan standing skipped above that ceiling and since when (Beacon); a standing skip is shown as a warning, a beacon from before the block as "Not reported". When that same command proves a reachable host's beacon publisher is being refused because the dashboard verifier is unavailable, Hosts shows Repair beacon publication. It runs stado repair stado --step link <target> --json, keeps the command's receipt on screen, and refreshes only that host after the CLI has observed a newer beacon and closed the silence. Other publisher failures have no repair button; the app does not guess.

• Services separates what is declared from what is running: declared units, the fleet as the health beacons report it, and processes no unit owns. running_binary is a column rather than a detail, and orphan processes are a list of their own — both facts were learned the expensive way. Beacon-reported states are printed with the beacon's own timestamp, so an active from a five-day-old beacon reads as five days old; the console never re-asks a host to fill the gap.

• Services → Web hosting reads stado web status [product] --json through the selected Stado API. It shows the selected edge, the product's verdict, DNS and port observations, and the complete edge_error. The sheet retains the command, source endpoint, exit code and complete returned output even when the command fails; Desktop does not calculate a second verdict.

• Releases shows one row per product target with the verdict stado release doctor reached, desired and observed versions side by side, and blockers in the CLI's own words — it reads verdict, failed, and findings out of status --json and re-derives none of them. A host's quarantined digests are listed with the one the registry desires first, then newest first, so the digest actually blocking a rollout is not buried under refusals that are already history.

• Inference shows which model each router alias reaches and the declared deployments behind it. It reads stado inference list --json and, per deployment, stado inference status <name> --json: an alias that lands on a declared deployment is shown with that deployment's exact repository@revision, an alias that leaves the fleet with the remote model name the router uses, and each deployment with its host, engine, GPU mode, context length, endpoint and the beacon's last state and GPU memory figure. A host whose beacon could not be read says so on its row in the command's own words; the screen never shows a state it did not read. It changes nothing: replanning a deployment stays with stado inference plan and apply.

• Cloudflare routes runs stado tunnel list|status|route|remove --provider cloudflare, the commands the tunnel reference describes, shows the exact argv before a change runs, and keeps each receipt on screen.

• Dashboard state decoding presents the published backend snapshot — each worker shows its admission decision, running jobs, live CPU and RAM, per-device accelerator availability, and VRAM. Job, failure, and onboarding labels reflect what the backend recorded, not optimistic placeholders.

The console reads a product report before judging its result code. host gates, release version show, web status, and release status can report failure together with a complete JSON result. Desktop keeps that result on its screen rather than replacing it with a generic command error.

Services report mode calls GET /api/service/converge?target=<host>. The apply sheet selects the host and all declared binaries or one binary, then sends POST /api/service/converge?target=<host>[&binary=<name>] with no body. The sheet also shows the equivalent stado release version converge --host <host> [--binary <binary>] --json command. Both interfaces call the same product implementation; Desktop does not launch the CLI for convergence or calculate its verdict.

A completed request returns HTTP 200 with {"exit_code": <code>, "report": {...}}, including when delivery failed. Desktop retains the complete JSON document and the product's exit code through the following refresh. It shows every release, stado-readers.detail, refusal, undeliverable item and final binary row without discarding fields it does not recognize. Missing or unauthorized client actions return 401; unavailable verifier state returns 503 with its diagnostic. Malformed query parameters or a request body return 400. A failure before a report exists returns 503 with SERVICE_CONVERGE_FAILED and its cause.

Apply has no shorter Desktop watchdog than the product's bounded host stages. Changing the selected source does not cancel delivery already accepted by the server, but a response from the old source is not shown as a result for the new one. Read-only requests keep their ordinary 120-second deadline.

Desktop never infers reader-resume support from a numeric version banner. Partial-state reader resume requires a target receiver built from a release containing the retained-archive command arguments. A receiver built without that contract rejects the apply; Desktop keeps the product's failed receipt rather than converting the older source into success.