Issues 199 (resolved: a node-scoped seat's verb through the console) and 200 (the controller's answer to a long console call is refused by the bus)

Designs 33 and 08 revised. The first node-scoped seat with verbs: rules,
reload, remove; the nftables module holds it from a runtime with NET_ADMIN,
the first container to declare a capability.

02-DECISIONS/0169-a-machine-joins-through-the-tunnel-and-the-bus-is-never-public.md

@@ -0,0 +1,89 @@
+---
+topic: the mesh
+status: accepted
+date: 2026-10-02
+deciders: jochen
+reconstructed: false
+extends: 02-DECISIONS/0004-a-node-and-how-it-joins.md
+---
+
+# 169. A machine joins through the tunnel, and the bus is never public
+
+## Context
+
+The bus is the one channel every machine depends on: enrolment, every declaration, every tool. The
+`nats` module declares it reachable from the mesh only. The controller still opens it to the whole
+internet on the machine that runs it, as a *foundation* port that no module declares and nothing may
+close ([issue 051](../04-ISSUES/051-the-mesh-cannot-update-what-it-depends-on/00-report.md)).
+The reason is joining. [ADR 0004](0004-a-node-and-how-it-joins.md) has a new machine enrol over the bus
+**before** it has a tunnel. [ADR 0007](0007-connectivity.md) states it as a requirement: the node
+running the broker must be reachable from wherever nodes are, at a stable address.
+
+So the bus listens on the internet permanently, for an event that happens a few times a year. A
+sweep of every machine on 2026-10-02 found no client using the public path. Every connection arrives
+over the tunnel or from the machine itself. The join token does not use it either: it carries the
+controller's configured broker address, a mesh name with the old broker's port.
+
+ADR 0004 already says what a joining machine needs: *an identity, an address, and one peer to reach*.
+The tunnel can be that peer, if the hub knows the new machine's key before the machine first knocks.
+WireGuard answers nothing to a key it does not know, which is why the tunnel's own port is safe to
+leave open where the bus's is not.
+
+## Considered Options
+
+1. **Keep the bus public.** It is authenticated and encrypted, but every exposure of it, and of the
+   server behind it, is exposure of the one thing everything depends on.
+2. **Open the bus publicly only while a join token is live.** Small, and the hub is open only during a
+   join window. But the window is real, the rule is about time rather than about who may reach the
+   bus, and the opening and closing are pushes that can fail between them.
+3. **The controller makes the new machine's tunnel key and puts it in the token.** One step for the
+   operator, but the private half leaves a machine it does not belong to. ADR 0004 refuses that for
+   every key a node holds.
+4. **The machine makes its key first, and the token is issued for it.** The machine prints the public
+   half of its tunnel key. The operator issues the token for that key. The controller gives the
+   machine its address and adds it as a peer on the hub. The token carries the hub's tunnel endpoint
+   and key, the machine's address, and the bus's address on the private network. The machine brings
+   up its tunnel and enrols over it.
+
+## Decision
+
+**Option 4.**
+
+- **A machine makes its own tunnel key before it has a token**, and prints the public half. The private
+  half never leaves it, as ADR 0004 says of every key a node holds.
+- **A token is issued for a tunnel key.** Issuing it assigns the machine's address on the private
+  network, records the key, and makes the machine a peer of the hub. The hub is sent that before the
+  token is shown, so the tunnel answers the moment the machine first uses it.
+- **The token carries the one peer.** It adds the hub's tunnel endpoint and public key and the
+  machine's own address. **Where** becomes the bus's address on the private network, which needs no
+  name resolution.
+- **The machine joins through the tunnel.** It brings the tunnel up from the token alone, then enrols
+  over it exactly as before. The enrolment checks that the key it is offered is the one the token was
+  issued for.
+- **The bus is never public.** It is no longer a foundation port. Its reach is what the `nats` module
+  declares: the mesh. The tunnel's port stays open, as the one way in.
+
+This changes three things earlier records say. ADR 0004's *where* is the bus's private address, and the
+token carries the peer. ADR 0007's requirement that the broker be reachable from wherever nodes are
+becomes: **the hub's tunnel is**. Issue 051's broker port stops being a foundation port.
+
+## Consequences
+
+- Joining is two commands on the new machine, with the token issued between them. A token issued for
+  the wrong key gives a tunnel that never answers, and the machine says so rather than timing out at
+  the bus.
+- An unused token leaves a peer on the hub until it expires. Expiry removes it, the same way it voids
+  the secret.
+- A machine already in the mesh is unaffected: it reaches the bus over its tunnel today.
+- The genesis machine, the first one, raises the bus on itself and needs no tunnel to reach it.
+
+## How this is checked
+
+| Rule | Checked by |
+|---|---|
+| A token is refused without a tunnel key, and carries the hub's peer and the machine's address | a controller test |
+| Issuing a token makes the machine a peer of the hub before the token is shown | a controller test over the hub's composed tunnel |
+| An expired, unused token's peer is gone from the hub | a controller test |
+| Enrolment refuses a tunnel key other than the one the token was issued for | a controller test |
+| No machine's filter opens the bus to anywhere | a controller test over the composed filter, and the live sweep from outside the mesh |
+| A new machine joins from outside the hub's network with the bus closed to it | the lab, then by hand |

02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md

@@ -0,0 +1,84 @@
+---
+topic: the mesh
+status: accepted
+date: 2026-10-02
+deciders: jochen
+reconstructed: false
+extends: 02-DECISIONS/0168-a-converged-machine-is-filtered-by-the-mesh-alone.md
+---
+
+# 169. The firewall seat serves its verbs, and a foreign rule set is removed through one of them
+
+## Context
+
+[ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md) made the mesh say truthfully
+what filters a converged machine, and left the removal of what it did not write to the operator's
+hand. The first time that hand was needed — two machines, five rule sets a predecessor and a
+retired front end had left — there was no mesh way to lend it: the packet filter is a seat
+([ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)), a seat's
+holder serves its verbs ([ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md),
+[ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md)), and the
+firewall seat declared none. The only remaining path was a shell on the machine, which is the path
+the mesh exists to replace, and which the operator's own tooling rightly refused to an agent.
+
+A seat's verbs are the contract every holder implements, whatever filter it speaks. What a person
+asks a machine's packet filter is the same whether nftables, a front end or a legacy filter answers:
+what are the rules, reload the mesh's own, remove this thing the mesh did not write. What differs by
+filter is the holder's own business and may be its own tools beside the seat's.
+
+## Decision
+
+**1. The `node-packet-filter` seat serves three verbs**, and a module that claims it serves all
+three or is refused the claim, as with every seat:
+
+- `rules` — the packet filter as the machine enforces it now: the nftables ruleset, and the legacy
+  filter's listings where that tool exists; narrowed to one table or chain when asked. Read-only.
+- `reload` — load the mesh's own filter again from the file the mesh writes, and answer with the
+  mesh's table as loaded. The holder's own act on the holder's own rules.
+- `remove` — remove one rule set the mesh did not write, named exactly as the host reports it under
+  ADR 0168 (`chain HAL-MESH-ONLY (iptables-legacy)`, `table ip6 filter, chain DOCKER-USER`), and
+  answer with what was done. It refuses the mesh's own tables, the container runtime's own chains,
+  a built-in chain other than the runtime's user chain, and any chain of a found firewall that is
+  in force. The runtime's user chain is emptied back to its one return; another chain loses the
+  jumps into it, is flushed and deleted; a table of the machine's own is deleted whole. Each is an
+  operator's act, by name, on one thing the mesh reported — never a flush, never a rule the mesh
+  itself marked.
+
+**2. A holder may serve its own tools beside the seat's.** The nftables module keeps its reading of
+the mesh's table as its own tool, and a holder speaking a filter with specifics of its own may add
+tools for them; the seat's three are what every holder owes.
+
+**3. A container may ask for a capability.** Serving `remove` and `reload` needs the machine's
+network namespace and the right to change its packet filter; a holder's runtime declares
+`capabilities: ["NET_ADMIN"]` on its container and runs on the machine's network. The host grants
+exactly the capabilities declared, names them in the container's spec so a change recreates it, and
+refuses a name that is not a capability's. A privileged container stays undeclarable.
+
+**4. ADR 0168's "by hand" is read as "by the operator, through the seat".** Removing what the mesh
+reports as *other* is still the operator's act and is still never the mesh's own doing; the verb is
+how the act reaches the machine, recorded on the bus like every other, instead of a shell.
+
+## Consequences
+
+- The seat's row gains the three verbs; a mesh that already runs widens its row at the next
+  controller start. The nftables module claims them and gains a runtime — a tool server with the
+  packet filter's tools in its image, on the machine's network, with `NET_ADMIN`.
+- The host's container vocabulary grows by `capabilities`; an older host refuses a declaration that
+  carries it, so the host rolls before the module.
+- The two machines of this mesh that ADR 0168 found not filtered by the mesh alone are cleaned
+  through `remove`, and read *the mesh alone* afterwards; `status` returns to well without a hand on
+  either machine.
+
+## How this is checked
+
+| Rule | Checked by |
+|---|---|
+| The seat declares the three verbs; a claim that serves fewer is refused by name | the catalogue's seat tests |
+| `remove` refuses the mesh's tables, the runtime's chains, a built-in chain and an active front end's chains, and removes a user chain with its jumps, empties the user chain, deletes an own table | the module's tests over a fake command runner, with the shapes the host reported live |
+| A container's capabilities reach the runtime and its spec; an unknown name is refused | host tests |
+| Live | `node-packet-filter.remove@<node>` on the home server and the control node; `node show` reads *the mesh alone* on both; `status` is well |
+
+## References
+
+- [ADR 0168](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md), [ADR 0154](0154-the-meshs-own-verbs-are-the-controller-seats-tools.md), [ADR 0159](0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md), [ADR 0121](0121-a-system-seat-is-named-for-its-scope-and-modules-define-their-own.md)
+- [Design 33 — The tools the mesh answers](../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md), [Design 08 — Connectivity](../03-DESIGN/01-to-be/08-connectivity.md)

02-DECISIONS/0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md

@@ -0,0 +1,59 @@
+---
+topic: the mesh
+status: accepted
+date: 2026-10-02
+deciders: jochen
+reconstructed: false
+extends: 02-DECISIONS/0016-the-lab.md
+---
+
+# 172. The lab is a module, and runs a bed when the mesh asks
+
+## Context
+
+The lab raises virtual machines and runs the mesh on them, end to end, before a change reaches a real
+machine ([ADR 0016](0016-the-lab.md)). It runs on one machine of the mesh, the one with the
+virtualisation it needs. Until now the only way to start a bed there was to sign in to that machine and
+run the lab's command line by hand, with a dozen environment variables pointing at sibling checkouts.
+
+Nothing in the mesh could ask for it. An agent working through the mesh's own tools could build,
+merge and push a change, and could not prove it in the lab first. The operator's direction on
+2026-10-02: work on another machine goes through a mesh tool, not a shell on it.
+
+## Considered Options
+
+1. **Keep the lab a command line on one machine.** Every run is a person, or an agent with a shell on
+   that machine, outside the mesh.
+2. **The lab is a module.** Assigned to the machine that can run it, serving tools that run a bed
+   against named branches and say how it went.
+
+## Decision
+
+**Option 2.**
+
+- **A `lab` module, assigned where the lab can run**, serves five tools: whether this machine can run
+  beds, run beds against a branch per repository, a run's state, its log, and stopping it.
+- **A run is the lab's own suite**, against fresh checkouts of the named branches from the mesh's forge,
+  side by side as the lab expects them. It builds what the beds place from those checkouts, as the suite
+  already does. It answers at once with an id, like a build: a bed takes minutes, and a call does not.
+- **Only branches on the forge are run**, never code handed to the tool. What a run tested is what the
+  forge holds at the commit it names.
+- **The lab is reached over the mesh only.** Its tools travel the bus, and the module opens no port.
+- **No grant beyond the mesh's own.** Running a bed is root on the lab's machine, but anyone who can call
+  the mesh's tools can already do worse. The operator's judgement on 2026-10-02.
+
+## Consequences
+
+- An agent proves a change in the lab through the mesh, the same way it builds and pushes one.
+- The lab's machine carries a module whose runtime holds the virtualisation's and the container
+  runtime's sockets, and a toolchain to build the mesh with.
+- A run's checkouts are its own, so two runs never build from each other's tree. Old ones are removed
+  when their run ends.
+
+## How this is checked
+
+| Rule | Checked by |
+|---|---|
+| A run checks out exactly the named branches, and reports the commits it tested | the module's tests over a forge fixture, and each run's answer |
+| A run answers at once, and its state and log follow it to the end | by hand, the first run |
+| The module opens no port | the composed filter of the lab's machine |

02-DECISIONS/README.md

@@ -179,6 +179,9 @@ python3 00-META/checks/index.py            fail if stale
 - **0163** — [Taking a module over is a comparison: what it compares, what it refuses, and what it carries](0163-taking-a-module-over-is-a-comparison.md)
 - **0167** — [A membership carries what its module receives, and who the mesh is](0167-a-membership-carries-what-its-module-receives-and-who-the-mesh-is.md)
 - **0168** — [A converged machine is filtered by the mesh alone, and the host says what else refuses](0168-a-converged-machine-is-filtered-by-the-mesh-alone.md)
+- **0169** — [A machine joins through the tunnel, and the bus is never public](0169-a-machine-joins-through-the-tunnel-and-the-bus-is-never-public.md)
+- **0169** — [The firewall seat serves its verbs, and a foreign rule set is removed through one of them](0169-the-firewall-seat-serves-its-verbs.md)
+- **0172** — [The lab is a module, and runs a bed when the mesh asks](0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md)
 
 ### Its tiers, from the bottom up
 

03-DESIGN/01-to-be/04-lab-installation.md

@@ -1,9 +1,10 @@
 ---
 layer: to-be
 status: in-progress
-code: [mesh-lab]
-updated: 2026-09-11
+code: [mesh-lab, mesh-catalog modules/lab]
+updated: 2026-10-02
 decisions:
+  - 02-DECISIONS/0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md
   - 02-DECISIONS/0016-the-lab.md
   - 02-DECISIONS/0010-delivery.md
 ---
@@ -119,7 +120,25 @@ In order, on a machine with nothing:
 
 6. **Verification**, as above, before anything is raised.
 
-## Open
+## The lab answers the mesh
+
+*2026-10-02* ([ADR 0172](../../02-DECISIONS/0172-the-lab-is-a-module-and-runs-a-bed-when-the-mesh-asks.md)).
+Once installed, the lab is also a module: `lab`, assigned to the machine that passed `check`. Its
+tools run there and nowhere else:
+
+| tool | does |
+|---|---|
+| `lab_check` | the lab's `check`, on this machine |
+| `lab_run` | fresh checkouts of the named branches from the forge, side by side, then the suite on the named beds; answers with an id |
+| `lab_status` | where a run is, and how it ended: the commits it tested, passed and failed |
+| `lab_log` | the run's output so far |
+| `lab_stop` | ends a run |
+
+The runtime is a container holding the toolchain the suite builds with. It reaches the
+virtualisation daemon and the container runtime through their sockets on the machine, so what it
+raises is what a hand run raises. The prerequisites above stay installed by hand. The module uses
+them, and never installs them.
+
 
 - **Whether the lab's bootstrap may install packages at all**, given that the mesh's rules
   forbid installing by hand. The resolution is probably that the lab's bootstrap *is* the

03-DESIGN/01-to-be/08-connectivity.md

@@ -9,6 +9,8 @@ code:
   - mesh-host internal/apply (the service that reflects a rule set)
 updated: 2026-10-02
 decisions:
+  - 02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md
+  - 02-DECISIONS/0169-a-machine-joins-through-the-tunnel-and-the-bus-is-never-public.md
   - 02-DECISIONS/0168-a-converged-machine-is-filtered-by-the-mesh-alone.md
   - 02-DECISIONS/0167-a-membership-carries-what-its-module-receives-and-who-the-mesh-is.md
   - 02-DECISIONS/0148-the-meshs-names-are-resolved-not-copied-into-containers.md
@@ -173,6 +175,28 @@ the broker's node must be dialable by every node, at a stable address, and so mu
 reachable; on one network it does not. A mesh whose nodes are all behind NAT cannot be raised, and
 a broker node whose address moves invalidates every token issued for it.
 
+*2026-10-02.* **The order changes at step 1: the tunnel comes first, from the token**
+([ADR 0169](../../02-DECISIONS/0169-a-machine-joins-through-the-tunnel-and-the-bus-is-never-public.md)).
+The circularity above is real, and it is broken differently. The overlay is configured by the mesh,
+except for the one peer a joining machine needs, and the token carries that peer. So the sequence
+becomes:
+
+```
+0  the node has an underlay address     the machine's own
+1  the node makes its tunnel key        before any token; it prints the public half
+2  a token is issued for that key       its address assigned, and the hub sent it as a peer
+3  the tunnel comes up to the hub       from the token alone: the hub's endpoint and key, its address
+4  the node dials the bus               OVER THE TUNNEL, at the bus's private address
+5  it proves itself, and is proved to   enrolment, checking the key is the one the token named
+6  the rest of the overlay              the whole peer set, delivered as files
+7  names, filtering, routes             as before
+```
+
+The link no longer stays on the underlay. The bus is reached over the tunnel by every machine,
+including one that is joining, so it is never opened to the internet. The precondition becomes: **the
+hub's tunnel must be dialable by every node, at a stable address.** That port answers nothing to a
+key it does not know.
+
 **Whether the link should later move onto the overlay, with the underlay as fallback, is
 [open](../../02-DECISIONS/0007-connectivity.md).** It is a decision rather than a derivation: the
 gain is which network carries bytes, not what an attacker can reach, since the link is already
@@ -743,6 +767,11 @@ tests over a fixture report check the recording, the preview's fates, the status
 predicate. Live: the home server's record names the predecessor's chain as *other* and `status`
 names the machine until the chain is removed by hand.
 
+*2026-10-02, [ADR 0169](../../02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md):* removing what
+the host reports as *other* is reached through the packet filter seat's `remove` verb, an operator's act
+by name on the bus; the seat also serves `rules` and `reload`, and its holder's runtime declares the
+`NET_ADMIN` capability on the machine's network. See design 33.
+
 ## 5 — Certificates
 
 **Two authorities, kept separate on purpose.**

03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md

@@ -2,8 +2,9 @@
 layer: to-be
 status: implemented
 code: [mesh-controller, mesh-tools]
-updated: 2026-10-01
+updated: 2026-10-02
 decisions:
+  - 02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md
   - 02-DECISIONS/0160-the-mesh-issues-an-assignments-subjects-and-a-runtime-serves-what-it-is-issued.md
   - 02-DECISIONS/0159-a-tool-call-names-the-machine-and-a-holder-serves-its-seats-verbs.md
   - 02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md
@@ -169,6 +170,18 @@ either way.
 What stays as designed and not built: which verbs any *other* seat serves, and §3 for module-declared
 seats' schemas beyond the names their manifests already list.
 
+## The firewall seat's verbs, 2026-10-02
+
+[ADR 0169](../../02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md). The first node-scoped seat
+to carry verbs: `node-packet-filter` serves `rules` (the filter as the machine enforces it, nftables
+and legacy), `reload` (the mesh's own filter from its file) and `remove` (one rule set the mesh did
+not write, named as the host reports it under ADR 0168; refusing the mesh's tables, the runtime's
+own chains, a built-in chain and an active found firewall's). Every holder serves all three; the
+nftables module does so from a runtime on the machine's network with `NET_ADMIN`, which is the first
+container to declare a capability. Removing a predecessor's rule set is an operator's act reached
+through the seat, recorded on the bus, instead of a shell on the machine. *How it is checked:* ADR
+0169's table.
+
 ## What this does not settle
 
 - Which verbs each seat should serve. That is a decision per seat, and the reason to do it slowly: a

04-ISSUES/197-a-physical-link-that-is-down-is-not-filtered-when-it-comes-up/00-report.md

@@ -0,0 +1,43 @@
+---
+status: resolved
+opened: 2026-10-02
+located-in: [mesh-host internal/outward (Links reported only the links carrying a default route)]
+fixed-by: mesh-host PR 66 (a link backed by a physical device is named outward, up or down), live 2026-10-02
+amended-design: []
+---
+
+# 197 — A physical link that is down is not filtered when it comes up
+
+## What was observed
+
+A sweep of every machine's filter on 2026-10-02. A laptop-class machine connected by its radio has a
+wired port that was unplugged. Its filter guarded the radio and the tunnel, and accepted everything
+arriving on any other link:
+
+```
+iifname != { "mesh0", "<radio>" } accept
+```
+
+The wired port was not in the list. Plugged in, everything arriving on it would have been accepted,
+every port of the machine open to whatever network the cable reached. That would last until the
+machine reported again and was pushed a new filter.
+
+## Why it matters
+
+**The filter's one rule about links fails open.** [ADR 0140](../../02-DECISIONS/0140-the-filter-constrains-what-arrives-from-outside.md)
+has the filter constrain what arrives from outside, and has the machine say which links face outside.
+Everything not named is treated as the machine's own, its containers and bridges. So a link the machine
+fails to name is not filtered at all. The host named only the links carrying a default route at the
+moment it reported. A cable plugged in later is the ordinary case for a laptop. A second wired network
+that never carries the default route, such as a direct link to a storage box, is never named at all.
+
+## Open questions
+
+- A virtual link that faces outside (a VPN client's interface, a USB tether that appears as a virtual
+  device) has no physical device behind it. It is named only while it carries the default route. Is
+  that enough?
+
+## Resolved (2026-10-02)
+
+Live on the affected machine after the host was delivered and one more push: its filter now guards the
+radio, the tunnel and the unplugged wired port, before anything is plugged into it.

04-ISSUES/197-a-physical-link-that-is-down-is-not-filtered-when-it-comes-up/01-diagnosis.md

@@ -0,0 +1,14 @@
+# Diagnosis
+
+*2026-10-02.*
+
+**Located in `mesh-host` `internal/outward`.** `Links` read the kernel's routing tables and returned the
+interfaces carrying a default route. An unplugged port carries none, so it was never reported, and the
+controller rendered the filter around the links it was given.
+
+**The fix.** A link faces outside if it carries a default route **or** has a physical device behind it.
+The kernel lists every interface under `/sys/class/net`, with a `device` entry for one backed by
+hardware. A bridge, a veth, the tunnel and the loopback have none, so they stay the machine's own. The
+wired port is now reported up or down, and the filter guards it before anything is plugged in. Tested
+with a radio carrying the default route and an unplugged wired port beside a bridge, a veth, the docker
+bridge, the tunnel and the loopback: the two physical links are reported, nothing else.

04-ISSUES/198-the-lans-dns-server-ran-outside-the-mesh-and-its-filter-closed-it/00-report.md

@@ -0,0 +1,71 @@
+---
+status: resolved
+opened: 2026-10-02
+located-in: [mesh-catalog modules/dnsmasq (listens on loopback and the machine's mesh address only), the home-server's DNS (a predecessor's dnsmasq configuration the mesh did not own), the home network's DHCP (hands out the home-server as every device's DNS)]
+fixed-by: mesh-catalog PR 214 (dnsmasq listens on addresses from a setting; docker's file takes no settings), mesh-controller PR 210 (the settings verb), mesh-catalog PR 215 (unifi network DNS tools), live 2026-10-02
+amended-design: []
+---
+
+# 198 — The home network's DNS server ran outside the mesh, and the mesh's filter closed it
+
+## What was observed
+
+Every phone on the home Wi-Fi had no internet, while a laptop on the same Wi-Fi did. The router's
+DHCP hands every device the home-server's LAN address as its DNS server. The home-server's DNS daemon
+was listening on that address, and every query to it timed out. The router itself answered the same
+query at once. The laptop worked because it resolves through its own local resolver, not through the
+server DHCP names.
+
+## Why it happened
+
+The DNS daemon on the home-server was not the mesh's. It ran under a configuration file a predecessor
+generated, listening on loopback, the mesh address and the LAN address. The mesh's `dnsmasq` module was
+assigned to the other three machines and not to this one, so no module on the home-server declared
+port 53. Its filter opens only what a module declares, so DNS from the LAN was dropped. It started when
+the home-server applied the filter this morning, after nine hours of applying nothing
+([issue 194](../194-the-hosts-own-former-archive-stops-every-apply/00-report.md)).
+
+Nothing said so. The daemon reported running, the filter applied cleanly, and the mesh had no record
+that the home network depended on a service it did not know.
+
+## Why it matters
+
+**A service the mesh does not know is closed by the mesh's filter, by design, and nothing asks whether
+something depends on it.** That is the right default for an unknown port. It is the wrong outcome for
+the one service a whole network was told to use. The gap is that a machine can run something
+important outside the mesh with nothing to show it.
+
+**The mesh's `dnsmasq` could not have served the LAN either.** It listened on loopback and the mesh
+address only. The reach of its DNS endpoints opens the filter, but the daemon would not have been
+listening on the LAN address anyway.
+
+## Open questions
+
+- Should a machine report the listening services the mesh does not own, the way it reports the links
+  that face outside? This one would have been visible before the filter closed it.
+- The LAN address the home-server answers on is now a setting, beside the reach that opens the filter.
+  Two statements that must agree. Should reach `public` on a DNS endpoint imply listening beyond the
+  mesh?
+
+## Resolved (2026-10-02)
+
+The home network was pointed at the gateway for DNS while the fix was built, which got the phones back
+within minutes. Then:
+
+- the mesh's `dnsmasq` takes the addresses it listens on beside the machine's from a setting, with
+  loopback as the mesh-wide default, so no other machine changed;
+- the home-server's layer adds its LAN address, and its DNS endpoints' reach is `public`. The router
+  forwards no DNS, so that means the LAN;
+- the module and its sibling `resolv-conf` were assigned to the home-server, replacing the
+  predecessor's daemon and configuration, which were kept aside;
+- the home network was pointed back at the home-server, through a new `unifi` tool.
+
+Checked live: from another machine on the LAN, public names and mesh names both resolve through the
+home-server's LAN address, and the mesh and the machine itself resolve as before.
+
+**One fault found on the way, and caught before it reached any machine.** A module's settings are
+merged into every mergeable file the module owns. The first attempt therefore put the new setting into
+docker's `daemon.json` as well as into dnsmasq's config, and dockerd refuses keys it does not know. The
+plan showed it before any push. The change was reverted and redone with docker's file declared to take
+no settings. The general fault, a module's settings reaching files they were not meant for, is still
+there for any module with more than one file.

04-ISSUES/199-a-node-scoped-seats-verb-could-not-be-called-through-the-console/00-report.md

@@ -0,0 +1,35 @@
+---
+status: resolved
+opened: 2026-10-02
+located-in: [mesh-tools src/client.ts (toolsOn left node-scoped seats out of the listing), mesh-tools src/mcp.ts (the call resolved the key against that listing)]
+fixed-by: mesh-tools 27 — node-scoped seats are listed with their scope, the verb requires the machine, and the call carries it in the subject
+amended-design:
+---
+
+# 199 — A node-scoped seat's verb could not be called through the console
+
+## What was observed
+
+2026-10-02, the first time a node-scoped seat declared verbs
+([ADR 0169](../../02-DECISIONS/0169-the-firewall-seat-serves-its-verbs.md)). The packet filter's
+holder on every machine served `rules`, `reload` and `remove` on the seat's per-machine subjects, and
+the bus admitted them. The console answered every call with *nothing serves
+node-packet-filter.rules@<machine>*.
+
+[Design 33 §4](../../03-DESIGN/01-to-be/33-the-tools-the-mesh-answers.md) says a node-scoped seat's
+tool carries the node it is asked of, as `<seat>.<verb>@<node>`. The console's listing left
+node-scoped seats out — the comment said they *wait for a caller naming the node* — but the roles map
+the console resolves a name against is built from that same listing. So the name never resolved as a
+seat's verb, fell through to a module's subject nobody served, and the refusal named the wrong cause.
+
+## Why it matters beyond this instance
+
+A stated behaviour that did not happen, with a refusal that pointed elsewhere: the seat's verbs were
+live on four machines and unreachable from the one surface a person uses. It could only be found by a
+node-scoped seat declaring verbs, which none had.
+
+## Resolved, 2026-10-02
+
+mesh-tools 27: node-scoped seats are listed with their scope, their verbs take a required `node`, the
+call carries it in the subject, and a call without one is refused in words. Tested with a round trip
+asking one machine's holder and being refused without a machine.

04-ISSUES/200-the-controllers-answer-to-the-console-is-refused-by-the-bus/00-report.md

@@ -0,0 +1,36 @@
+---
+status: open
+opened: 2026-10-02
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 200 — The controller's answer to a long console call is refused by the bus
+
+## What was observed
+
+2026-10-02. A `push` of the control node asked through the console came back as *mesh-controller.push
+did not answer in time. Something is serving it, so this is the tool being slow rather than absent.*
+The push had run; the machine applied. The bus's log on the control node, at the same moment:
+
+```
+[ERR] 10.10.0.1:56030 - cid:4015 - Publish Violation - User "controller",
+      Subject "_INBOX.shanks.mesh-console.WRNO5V9IJ1FX35AU5NRBEB.WRNO5V9IJ1FX35AU5PN1UW"
+```
+
+The controller's reply to the console's request was refused: the controller's bus account may not
+publish to the console's reply inbox. Shorter calls (`status`, `node`, `nodes`) answer; the long ones
+(`push` of a large machine, `issue`) time out on the console's side although they succeed.
+
+## Why it matters beyond this instance
+
+A call that succeeds and is reported as a timeout sends a person to retry what already happened — a
+second push, a second issue — and reads as the mesh being slow when it is the mesh refusing itself.
+Whether the inbox prefix the console uses is the one the controller's account is allowed to answer, or
+the request outlives the inbox subscription, is what a diagnosis has to tell apart.
+
+## Open questions
+
+- Which reply inboxes may the controller's account publish to, and which does the console request on?
+- Does a reply after the requester's timeout count as a violation, or is the prefix itself refused?