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

2026-10-01 16:01:45 +02:00
parent 4ae452d0ad
commit 180e3b8f7e
1 changed files with 51 additions and 0 deletions
@@ -0,0 +1,51 @@
 ---
 status: open
 opened: 2026-10-01
 located-in: []
 fixed-by:
 amended-design: []
 ---
 # 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](../184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md)).
 "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.