QuoxBuild

A governed build queue whose dispatches name a registered target, never a command.

Overview

A build system that accepts a command from a remote caller is a remote shell with a friendly name. QuoxBuild refuses that shape entirely.

A dispatch names a target, never a command. The target must already be registered on the host. The host refuses anything it does not already know, so the worst a caller can do is ask for a build that was already defined as safe by whoever set the host up.

There is no argument you can craft that turns a dispatch into arbitrary execution, because no part of the dispatch is ever executed as a string.

Dispatching

bash

quox build <target>                        # shorthand for dispatch
quox build dispatch <target> --host <hostId> --msg "what changed"
quox build targets --host <hostId>         # what this host will accept
quox build status --host <hostId>          # readiness, prereqs, building now

Builds serialise (one at a time per host, so two sessions cannot race each other into a corrupted artefact) and coalesce (duplicate requests inside a short window collapse into one build rather than queueing three identical ones).

This matters in practice when several agents work in parallel on the same repo. Without serialisation they interleave; without coalescing they each trigger a full rebuild of the same thing.

Receipts that mean something

Every build writes a durable receipt.

The important rule: a receipt only reads green once a post-deploy probe confirms the service actually came up. A build that compiled cleanly and then failed to start is not green here, because "the build succeeded" and "the thing works" are different claims and conflating them is how a broken deploy gets reported as a success.

bash

quox build history --host <hostId>    # durable receipts, newest first
quox build latest                     # latest receipt per target: the status board

Repeated failures are recorded against the target, so the next dispatch of a known-bad target carries that history with it rather than arriving as a surprise.

Limits and honest status

20 registered targets per org, 90 days of receipt history, on the paid tier. Free tier is zero builds per day.
Targets are registered on the host, not from the dashboard. Adding a new target is a host-side operation. This is deliberate (it is the property that keeps dispatch from becoming a shell) and it does mean adding a target is not self-service from the UI.
The surface is reached from the host card in Dev Servers, via a capability pill, rather than being a standalone screen in the sidebar. That is the intended shape: a build queue belongs to a host.
The post-deploy probe is per-target and only as good as its definition. A target whose probe checks nothing will go green on nothing.

For the current per-surface maturity map, see STATUS_AND_LIMITS_DEVSUITE.md in the dashboard repo.