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.
Three 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. On the LAN it needs no arguments and no credential at all: the vhost injects the tokens.
The dashboard covers the catalog, artifact lifecycle, repos, builds, and the fleet. The mobile app has full monitor-and-act parity across six tabs, and stores no credential of its own — the vhost injects the tokens.
An MCP server exposes both control planes to an MCP client. 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.