--- 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 0170](../../02-DECISIONS/0170-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@*. [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 `.@`. 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.