Clients for how you actually work
A mirror you can only operate by remembering curl invocations is a mirror one person operates. There is one REST surface here and four things speaking it — a CLI, a dashboard, a phone app, and an MCP server — and the logic they share is held identical by a test rather than by good intentions.
Four surfaces
The world CLI is a thin REST client over the mirror, the forge, and the build coordinator, so the same commands work against a laptop instance and a production one. Where a deploy has written its config file it needs no arguments, and on the LAN no credential either: the vhost injects the tokens.
The dashboard covers the catalog, artifact lifecycle, repos, builds, and the fleet — where the fleet is five pages rather than one, because devices, runners, labels and machines are each a thing you go looking for, and burying two of them in accordions below a table means nobody finds them.
The mobile app has full monitor-and-act parity across six tabs, and stores no credential of its own — the vhost injects both tokens, so a lost phone holds nothing.
An MCP server exposes both control planes to an MCP client: 27 tools the moment it starts, and 13 more only when writes are explicitly enabled. It takes a build's per-project NUMBER rather than its internal id, so the easiest mistake cannot be expressed there at all.
Shared logic, actually shared
The dashboard and the phone app share no package, so the pure modules they both need exist twice — and are held byte-identical by a test on each side that reads both copies off disk and compares them. That guard exists because "byte-identical across the two clients" was a convention nothing enforced, and by the time anyone measured, two modules had already drifted.
The comparison is strict, with no carve-out. Its first version normalised the client names so each file's note could match, which is a rule with an exception for the very thing that breaks it.