Issues 184 and 188 resolved: the merge handler returns at once; a machine is resolved with its pins and a dropped one is said

04-ISSUES/184-a-merge-announcement-blocks-the-controllers-receive-loop/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-01
 located-in: [mesh-controller cmd/mesh-controller/upgrades.go (the merge handler builds inside the receive loop)]
-fixed-by:
+fixed-by: mesh-controller PR 197 (ADR 0162: the merge handler writes a plan, asks the first tier and returns; outcomes and a ticker advance it) and PR 199
 amended-design: []
 ---
 
@@ -56,3 +56,14 @@ interleaved with the merge's own.
 [ADR 0162](../../02-DECISIONS/0162-a-merge-produces-a-tiered-plan-the-mesh-keeps.md): a merge
 produces a tiered plan the store keeps; the handler asks the first tier and returns; outcomes advance
 the plan; a controller replaced mid-plan resumes it. The loop is never held by a build again.
+
+## Resolved, 2026-10-01 evening
+
+Since the controller holding ADR 0162's plan rolled, a merge announcement is handled in
+milliseconds: the plan is written, the first tier asked, the loop free. The builds the merge
+implies are asked from the store's record, tier by tier, so a controller replaced mid-plan resumes
+it rather than losing it. The first live merge under it (a controller change) is the proof the
+decision's table asks for; its tiers are read with `plans`.
+
+*How it is checked:* the plan tests in mesh-controller; live, `plans` after a merge and the loop's
+log taking reports in while the plan builds.

04-ISSUES/188-a-refusal-inside-on-the-network-drops-a-machine-silently/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-01
 located-in: [mesh-controller cmd/mesh-controller/plan.go (theRestOfTheMesh resolves every other machine without its pins and skips one that refuses, saying nothing), mesh-controller cmd/mesh-controller/network.go (onTheNetwork, the same)]
-fixed-by:
+fixed-by: mesh-controller PR 199 (each machine resolved with its own pins; a dropped machine said in both passes), rolled 2026-10-01 evening; PR 200 keeps the per-machine view quiet
 amended-design: []
 ---
 
@@ -53,3 +53,11 @@ Found by a diagnostic build counting what each machine yielded. Fixed by mesh-co
 `fix/a-machine-not-on-the-network-is-said`: each machine is resolved with its own pins, and a machine
 left out is named with the resolver's words in both places. The pin itself (`step-ca`, the issuer
 the proxy already had) was made by hand and stands.
+
+## Resolved, 2026-10-01 evening
+
+The controller holding the fix was rolled onto the control node by the operator and a colleague
+(the running one could not roll itself); after it every seat read as held again, a build asked
+through the git seat worked, all four machines resolved and pushed. The line naming a dropped
+machine spoke once too often — in the per-machine view, where the others are resolved without the
+planned machine's offers and may fail by design — and is quiet there since mesh-controller PR 200.