The table is wider than a phone and had no box to scroll in, so the page itself
scrolled sideways and carried the header and nav with it: a reader could see
that something was wrong but not what, which is the one thing the four columns
exist to say.
And two containers can share a repository at different versions on purpose — a
sidecar held back while the app moves on. Reading whichever came last reported
the pin unapplied on a service whose app container was carrying it, so the board
named drift where there was none. A workload runs the declared version if any of
its containers does.
The board showed build runs and nothing about deployment, so a service could
serve last week's code with every row on the page looking ordinary.
Four values per service, read from the systems that own them:
head ──build──▶ built ──pin──▶ declared ──reconcile──▶ running
Every arrow is a job of the pipeline this repo publishes — `image` produces the
artifact, `rollout` writes the pin cd.hanzo.ai reconciles — so a service is
current exactly when all four agree, and each way they disagree names the arrow
that did not happen: unbuilt, unshipped, unsynced, untested.
Head is read because the other three are not enough. built, declared and running
can name the same release while main has moved on and nothing since has produced
an image; comparing them to each other cannot see that at all.
Two readings the page depends on, both taken from a run's JOBS rather than its
single conclusion. A run that fails at `gate` built nothing and a run that fails
at `receipt` has already built, pinned and proved the release live — both report
`failure`. And a commit the forge never constructed a run for is absent rather
than failed: there is no log to open, so it is drawn as a different shape.
A service is its namespace and name, not its image: ghcr.io/hanzoai/static runs
as cdn, tabs and zen-landing on three versions at once, and keying rows by image
compares one service's pin against another's running version. The image is what
joins to the forge, where several services legitimately share one repo.
Comparisons refuse to guess. An unread source is never drawn as a difference, a
tag that cannot be ordered orders against nothing, and a commit still building
has not failed to produce an image.
Reads only — no deploy, retry or promotion. The cluster is read through the pod's
own ServiceAccount (get and list on workloads, nothing else, no stored
credential) and universe through the forge token this service already holds.
scope_test.go now covers /v1/fleet and the fleet page, and drives the real
router so the assertion cannot be made against a copy of a handler.
zooqueen