03-DESIGN/01-to-be/22-the-work-ahead.md

@@ -87,11 +87,19 @@ a protocol that agrees, a registry to publish to. Issue 051.
       binds `0.0.0.0` from genesis so a mesh consumer can reach it, but the packet filter is
       installed later — a brief pre-filter window where `mesh-store` is open before `from: mesh`
       clamps it; bring the filter up earlier or bind narrower at genesis.)*
-- [ ] 3.2 the broker is adopted — one `lavinmq`, the `/` vhost for the mesh bus, a vhost per
-      consumer that requires `amqp`; the second server gone
-- [ ] 3.3 an upgrade of each, proven: a store the controller reads from, a broker over the
-      broker, each with a stated window
-- [ ] 3.4 `status` can say the foundation is behind its source, which today it cannot form
+- [x] 3.2 the broker is adopted — one `lavinmq`, the `/` vhost for the mesh bus, a vhost per
+      consumer that requires `amqp`; the second server gone. *(Adopted in place like the store; the
+      module names mesh-broker with the foundation's TLS spec, the provisioner runs host-networked
+      as lavinmq's default guest, amqp-ping reaches it. Proven 22/22.)*
+- [x] 3.3 an upgrade of each, proven: a store the controller reads from, a broker over the
+      broker, each with a stated window. *(Lab steps S1/S2: move each module's source, build, roll
+      out, then a full push applies the server change and recreates the container. The store's
+      window is a pool reconnect; the broker's is longer — recreating the bus the push travels over,
+      so the mesh reconnects to the one that returns. Data survives on the named volumes.)*
+- [x] 3.4 `status` can say the foundation is behind its source, which today it cannot form.
+      *(Given by the adoption: postgres/lavinmq are ordinary modules with a source now, so
+      `module list`/`status` reports them behind or current like any other — the question could
+      not form when they were bundle containers.)*
 
 **Done when.** A mesh built from bare metal runs one postgres and one lavinmq, and can upgrade
 either — so the twelve-module floor has no specialty left in it.

04-ISSUES/051-the-mesh-cannot-update-what-it-depends-on/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: open
+status: fixed
 opened: 2026-09-14
-located-in: []
-fixed-by:
+located-in: [mesh-host, mesh-catalog]
+fixed-by: mesh-host 56124c3; mesh-catalog 5e4dc37; mesh-lab 440e265
 amended-design:
 ---
 
@@ -117,3 +117,17 @@ broker upgrade is the mesh asking the machine to replace the thing the request a
 | The mesh can say its substrate is out of date | The store's source moves and `status` reports it behind, the way it does for any module. |
 | The mesh can deliver a substrate update | A store or broker is upgraded on a running mesh and the control plane is answering afterwards, with its records intact. |
 | Nothing runs twice without a reason | A mesh with one machine runs one postgres unless somebody asked for two. |
+
+## Resolution
+
+The foundation's store and broker are adopted in place as the ordinary `postgres` and `lavinmq`
+modules (WBS Phase 3). Each module declares the container the foundation raised — the same name,
+image, ports, volumes and args — so the applier reconciles it rather than raising a second server;
+`mesh-host`'s `InstallStore` (phase3.go) carries in the genesis credentials the mesh cannot invent.
+The servers bind mesh-wide so consumers reach them, and their provisioners run host-networked. An
+upgrade of each is proven through its stated window — the store's a pool reconnect, the broker's the
+harder case of recreating the bus the push travels over — and `status` now reports both as ordinary
+modules that can be behind their source. A mesh built from bare metal runs one postgres and one
+lavinmq, proven 22/22 in the one-node lab. Two follow-ups are tracked: [054](../054-the-adopted-store-and-broker-are-open-before-the-filter/00-report.md)
+(the pre-filter exposure window) and [055](../055-the-adopted-store-and-broker-may-be-reachable-on-one-node-only/00-report.md)
+(multi-node reachability).