diff --git a/04-ISSUES/229-a-rollout-cannot-be-followed-through-the-meshs-tools/00-report.md b/04-ISSUES/229-a-rollout-cannot-be-followed-through-the-meshs-tools/00-report.md
index ec71d3c..2b6a662 100644
--- a/04-ISSUES/229-a-rollout-cannot-be-followed-through-the-meshs-tools/00-report.md
+++ b/04-ISSUES/229-a-rollout-cannot-be-followed-through-the-meshs-tools/00-report.md
@@ -11,7 +11,7 @@ amended-design:
 ## 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. Five times it left those tools
+controller seat's `status`, `plans`, `command`, and the forge's merge. Four 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,
@@ -24,13 +24,12 @@ and posted JSON-RPC by hand to the node console's HTTP endpoint with `curl`:
 3. **To read one module out of `module list`,** whose output was too long to read whole for one line.
 4. **To call a tool that arrived after the agent's session began.** The modules rolled out in that same
    session added `node-login-shell.execute` and `zsh.zsh_config` to one machine. The agent's MCP
-   connection to the mesh had listed its tools once, when the session started, and never listed them
-   again: no list-changed notice reached it, and a search of its tools found neither verb. So the only
-   way to prove the new verb through the mesh was the console's `mesh_call`, posted by hand.
-5. **To reach the console's own generic tools at all.** The console serves `mesh_overview`,
-   `mesh_machine`, `mesh_search`, `mesh_describe` and `mesh_call`. The MCP connection the agent had
-   flattens every module's tools into one list, and exposes none of those five. The one surface that
-   can reach any tool by address is therefore missing from the connection agents use.
+   connection had been opened before the console moved to discovery ([ADR 0195](../../02-DECISIONS/0195-the-meshs-tools-are-found-by-address-not-announced-whole.md)).
+   It still held the flat catalogue the console announced then, which lacks both the new verbs and the five discovery tools (`mesh_call` among
+   them) the console announces now. Clearing a session does not reconnect its MCP servers, and the
+   console never sends a list-changed notice, so nothing told the client its list was stale. The agent
+   posted `mesh_machine` and `mesh_call` by hand. Reconnecting the server would have given it the
+   discovery tools, which reach any tool by address the moment it exists.
 
 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)
@@ -54,8 +53,9 @@ rollout needs.
   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.
-- **A tool list that follows the mesh.** When a module's tools arrive or leave, the connection says so
-  (MCP's list-changed notification). Failing that, it always carries the console's addressable
-  `mesh_call` and `mesh_describe`, so a new verb is reachable without leaving the agent's tools.
+- **A client is told when the console's own surface changes.** The console announces `listChanged`
+  and sends the notice when what it lists changes, for example after an upgrade that changes its
+  tools. A long-running session then never keeps a list the console no longer serves. Discovery
+  already makes every module's tools reachable without the list changing.
 
 How each is checked belongs to the record that settles it.