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)

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?