diff --git a/04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md b/04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md
new file mode 100644
index 0000000..3246e22
--- /dev/null
+++ b/04-ISSUES/186-a-release-across-repositories-is-an-order-in-a-persons-head/00-report.md
@@ -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.