Issue 229: a rollout cannot be followed through the mesh's tools

2026-10-04 10:51:45 +02:00
parent a8ffc2b94b
commit 8d83d94659
1 changed files with 49 additions and 0 deletions
@@ -0,0 +1,49 @@
 ---
 status: open
 opened: 2026-10-04
 located-in: []
 fixed-by:
 amended-design:
 ---
 # 229 — A rollout cannot be followed through the mesh's tools, so an agent goes round them
 ## What was observed
 2026-10-04, rolling out to-be 41. An agent drove the rollout through the mesh's MCP tools: the
 controller seat's `status`, `plans`, `command`, and the forge's merge. Three times it left those tools
 and posted JSON-RPC by hand to the node console's HTTP endpoint with `curl`:
 1. **To wait for a plan.** `plans` answers once, with prose. Nothing waits for a plan to reach a tier,
   finish or fail. An agent's tools cannot be called from a shell loop, so the only way to be told
   when a plan moved was a background `curl` loop polling the console every twenty seconds and
   matching the plan's line with `grep`.
 2. **To read `status`.** `status` answers a paragraph of prose (the bus's user list), then a JSON
   document, both inside one string. Picking out `behind`, `waiting` and `reported` took a script
   that cut the string at the first brace and parsed the rest.
 3. **To read one module out of `module list`,** whose output was too long to read whole for one line.
 The calls were authorised, because the console is the operator's own surface. But each is a raw call
 the mesh's tools were meant to make unnecessary ([ADR 0154](../../02-DECISIONS/0154-the-meshs-own-verbs-are-the-controller-seats-tools.md)
 puts the controller's verbs behind the seat). Each is also a script that breaks silently when a
 sentence in the prose changes.
 ## Why it matters beyond this instance
 Every rollout an agent drives has the same shape: merge, wait for a plan, push, wait for reports,
 check `status`. When the tools answer only once and only in prose, every agent writes its own poller
 and its own parser. Those are invisible to review, different each time, and wrong the first time the
 wording moves. An agent that cannot wait also tends to act early, which is the opposite of what a
 rollout needs.
 ## What a fix has to settle
 - A way to **wait** on the mesh's own progress. For example, `plans` and `status` could take a plan
  or node and a bound, and answer when it moves or the bound passes. Or a verb could follow one plan
  to its end.
 - **Structured answers** from the controller's verbs, with the prose as a field beside the data, not
  around it.
 - Whether `command`'s generic answer should take a filter, or whether the verbs it is used for most
  (`module list`, `node show`) deserve verbs of their own.
 How each is checked belongs to the record that settles it.