Issues 190, 259, 262: resolved and verified

04-ISSUES/190-the-runtimes-configuration-is-written-by-modules-that-are-not-the-runtime/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-01
 located-in: [mesh-catalog modules/dnsmasq, mesh-catalog modules/docker, mesh-controller internal/overlay/generator.go, mesh-controller internal/catalogue/resolve.go (checkResources), mesh-controller internal/catalogue/seat_into.go, mesh-host internal/apply/apply.go (orphan removal)]
-fixed-by:
+fixed-by: novox/mesh-controller#62 (d84c969), novox/mesh-catalog#72 (5c89eaf), novox/mesh-host#26 (a192bcc), novox/mesh-controller#63 (c34b937)
 amended-design:
 ---
 
@@ -109,3 +109,10 @@ gives that module declared settings with defaults. The fix, once both are accept
 - **The adopted machine's predecessor values.** The runtime module adopting a file with a
   hand-written `dns` and `live-restore: false` replaces both. That is intended, and is the one
   restart the operator must make on that machine.
+
+## Verified
+
+2026-10-05: on every machine `insecure-registries` is now the runtime's module's own, filled from the
+store's seat; the private network's two generated resources are gone. The handover kept the list
+member throughout, and the old reload record was forgotten, not given back ("docker.runtime still
+holds the unit"), so the runtime was never stopped.

04-ISSUES/259-a-named-push-sent-every-machine/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-05
 located-in: [mesh-controller]
-fixed-by:
+fixed-by: novox/mesh-controller#64 (002d5e5)
 amended-design: 03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md
 ---
 
@@ -39,3 +39,8 @@ says one machine, and the command's output is the only place that says otherwise
 - Should the flush send a machine only what changed as a consequence: grants, user lists and bound
   facts, not module versions held by a policy?
 - Or should it list such machines as behind and leave them, as `push --behind` would find them?
+
+## Verified
+
+2026-10-05: after the fix, a named push sent only the machine named. Upgrades held by a policy were
+then sent with `push --behind`, as ADR 0221 has it.

04-ISSUES/262-an-alpine-container-could-not-find-a-machine-by-its-mesh-name/00-report.md

@@ -1,8 +1,8 @@
 ---
-status: located
+status: resolved
 opened: 2026-10-05
 located-in: [mesh-catalog]
-fixed-by: novox/mesh-catalog#71 (20603b6)
+fixed-by: novox/mesh-catalog#71 (20603b6), novox/mesh-controller#65 (df9231c), novox/mesh-catalog#73 (b4b86c1)
 amended-design:
 ---
 
@@ -48,3 +48,12 @@ requires one host record per machine should be added.
 *2026-10-05:* that test is added with [ADR 0223](../../02-DECISIONS/0223-the-mesh-has-two-resolvers-and-a-machine-lists-only-them.md)
 — mesh-controller's composition test renders the resolver's machine list and requires exactly one
 host record per machine. The live check stays by hand, on each resolver.
+
+## Verified, and what else was found
+
+2026-10-05: the host record fixed the IPv6 answer, but Alpine programs still failed when they read the
+machine's resolver file directly (host networking, docker's default bridge). They asked the mesh's
+resolver and the public fallback at once and took the public "no such name". ADR 0223 removes the
+public fallback: a machine lists only the mesh's resolvers, now two. Afterwards an Alpine container
+resolved a machine's name ten times out of ten, with host networking and on the default bridge, and
+the build machines built with no hosts-file line.