Issues 215, 221 resolved with live proof; 222 diagnosed and resolved

04-ISSUES/215-a-module-built-at-a-commit-stops-following-its-branch/00-report.md

@@ -1,5 +1,5 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-03
 located-in:
   - mesh-controller
@@ -34,3 +34,9 @@ Owner mesh-controller. **Fix direction:** a build asked at a commit does not cha
 module follows; or, if pinning is meant, the pin is said — in `module list`, in `status`, and by a
 merge's plan naming the module it leaves out and why. A test: building a module at a commit and then
 merging a change to it plans it.
+
+## Resolved
+
+Proven 2026-10-04: the catalogue merges since the fix rebuilt the module that had been pinned at an
+old commit, at the merge's commit, by an ordinary plan — the same as every other module of the
+catalogue. Nothing was asked for it by hand.

04-ISSUES/221-a-build-machine-learns-a-new-builder-only-from-a-push/00-report.md

@@ -1,5 +1,5 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-04
 located-in:
   - mesh-controller
@@ -44,3 +44,9 @@ stopping at the first failure. **How it is checked:** the next controller merge'
 build agent to the build machines before its last tier, and a build asked right after the plan
 finishes runs the new builder; then this moves to resolved. Whether the other modules roll out is
 the operator's policy, not this issue's.
+
+## Resolved
+
+Proven 2026-10-04: the next controller merge's plan logged that its first tier was built and the
+build agent sent to all four build machines, and only then asked its next tier. The builder change
+in that merge reached the build machines without a hand push.

04-ISSUES/222-an-assignment-is-refused-on-the-bus-until-the-bus-machine-is-pushed/00-report.md

@@ -1,8 +1,10 @@
 ---
-status: open
+status: resolved
 opened: 2026-10-04
-located-in: []
+located-in:
+  - mesh-tools
 fixed-by:
+  - mesh-tools#47
 amended-design:
 ---
 
@@ -33,3 +35,17 @@ tells the operator to run, leaves the module running and unreachable, with nothi
 Whether a push to one machine should also send the bus's machine when the user list it would
 compose differs from the one that machine holds. **How it is checked:** assign a module with tools
 to a machine that does not run the bus, push only that machine, and its tools answer.
+
+## Diagnosed and resolved
+
+The push did send the bus's machine: the controller's log shows both machines applying in the same
+second. The fault was the order within that second. The node's runtime subscribed before the bus
+had reloaded its user list, the bus refused, and the bus client marks a refused subscription dead.
+Nothing asked again until a later membership happened to re-serve the module.
+
+A subject the runtime answers on is now asked for again when the bus refuses it, after waits from
+two seconds to two minutes, and given up and said after about five minutes. **How it is checked:**
+a test refuses a subject and finds it asked for again and answering, given up past its attempts,
+and not asked again once stopped; and by hand against a bus whose permissions were reloaded while
+connected, the runtime answered two seconds after the grant arrived, where the runtime before the
+fix never answered.