ADR 0162: a merge produces a tiered plan the mesh keeps; dependencies are one relation; design 30; issues 184, 186

03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md

@@ -2,8 +2,10 @@
 layer: to-be
 status: proposed
 code: []
-updated: 2026-09-27
+updated: 2026-10-01
 decisions:
+  - 02-DECISIONS/0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md
+  - 02-DECISIONS/0157-a-build-narrates-on-the-bus.md
   - 02-DECISIONS/0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md
   - 02-DECISIONS/0120-a-roster-fact-carries-its-format-as-a-template.md
 ---
@@ -114,6 +116,19 @@ automate the freeze.
   (this is how the uplink managers and the re-registrations above were done). Only image-bearing
   modules need the build machine, which narrows what the deadlock above can block.
 
+## What a merge does now (2026-10-01)
+
+Revision, [ADR 0162](../../02-DECISIONS/0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md). The
+trigger exists: the forge announces a merge on the bus and the controller acts on it (ADR 0157 made
+the build narrate; this makes the merge a plan). A module's dependencies are one relation in the
+catalogue — `depends-on` edges of four kinds: stands-on, packages, built-by, declared. A merge takes
+what changed and everything reachable from it along those edges, sorts the set into tiers, writes the
+plan to the store, asks the first tier and returns. Each outcome advances the plan; a tier whose
+rolled-out modules a later tier is built by waits until the machines report them applied; a
+controller replaced mid-plan resumes from the store. `status` lists open plans and names one that
+has waited too long. The transition discipline for breaking changes in the list above is still
+unwritten, and still the next thing.
+
 ## Why now, and why not yet
 
 **Why it matters:** self-update is the difference between a mesh a person maintains by typing