hq/04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md

status, opened, located-in, fixed-by, amended-design

status	opened	located-in	fixed-by	amended-design
open	2026-10-01

186 — A release across repositories is an order in a person's head, and a build is a line in a queue nobody keeps

What was observed

On 2026-10-01 one decision (ADR 0161) was built as three pull requests in three repositories that must land in order: the controller first, so the seat exists and a report's profile is kept; the host second, so every machine reports the capability; the catalogue last, so a claim names a seat that exists and a holder is not refused on every machine. That order is written in a work-order file and in the pull requests' descriptions. The mesh holds none of it. A merge is handled as a merge: build the modules whose recorded source is that repository, record what came back. Nothing says what the mesh should end up as, and nothing checks whether it got there.

The same day showed what a build is. The build machine takes asks from an in-memory queue; when it was itself rebuilt in the middle of a wave of forty-three asks, the machine rolled, the new one started with an empty queue, and forty asks were gone without a word — the wave read "one of forty-three" for two hours. A merge announcement that asks forty builds waits for them inside the controller's one receive loop (issue 184). "Did everything I asked for succeed" was answered by counting lines in two containers' logs.

Why this is here

Every single step is sound: a build is reproducible, a push composes a machine from the store as it is, memberships are last-per-subject, so the mesh converges to the right state once every build is recorded and every machine pushed. What is missing is the whole: the mesh has no durable account of work it has asked for and no account of the state a release is aiming at, so the two faults that matter most to an operator — work silently lost, and a dependency between repositories merged in the wrong order — are detected by nobody. The rule that a manifest word ships one release ahead of its use is a discipline a person keeps, and a person kept it by hand eleven times this week.

What a decision would settle

• Whether a build ask is a durable message on the bus (a work queue the build machine takes from and acknowledges, as the build outcome already is an event), so a restarted builder resumes rather than forgets, and builds can list what is asked and not yet built.
• Whether a release across repositories is a thing the mesh records — a set of commits that belong together with the order they land in — so that a merge out of order is refused or held rather than built, and status can say what a release still waits for.
• What the smallest honest surface is in the meantime: at least builds listing the asked and the running beside the built, so a person polling logs becomes a person reading one table.

How this would be checked: a builder restarted between an ask and its build still builds it; a merge of a dependent repository before its prerequisite is held and named; builds lists asked, running and built.