M5c-2 plan: task 02, brokerd knows ask_memory; the outline split to nine tasks

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/plans/M5c2/01-wire-ask-memory.md

@@ -11,8 +11,8 @@ M5c-2 adds a core tool, `ask_memory`, that asks Honcho, a memory server shared b
 agents, a question about one or two of its workspaces (M5c spec, section 9). This task adds only
 the tool's arguments to `bxcore`, with their shape checks, the way `recall`'s are there
 (`RecallArgs`, its name constant `RECALL`, its limit `MAX_QUERY`, and `RecallArgs::check`). Later
-tasks use them: task 02 (`brokerd` parses the arguments with them), task 03 (`loopd` declares the
-tool), task 07 (`memoryd` answers it).
+tasks use them: task 02 (`brokerd` parses the arguments with them), task 04 (`loopd` declares the
+tool), tasks 08 and 09 (`memoryd` answers it).
 
 ```json
 {"question":"Who wrote the launch note?","workspaces":["fleet","boxmaker1"]}
@@ -24,7 +24,7 @@ tool), task 07 (`memoryd` answers it).
 - **`workspaces`**: optional; at most two names, none empty, none repeated, each 1 to 512
   characters of ASCII letters, digits, `_` and `-`. Missing, or `[]`, means the one workspace
   `own`, the agent's own trusted one. Whether a name is one this agent's `[honcho]` configuration
-  has is **not** checked here: `memoryd` checks that in task 07.
+  has is **not** checked here: `memoryd` checks that in task 08.
 - There is no other field, and an unknown field is refused, as in every argument type we define.
   (An earlier draft of the spec had a `reasoning` field; it was removed, and a given test sends
   it and expects a refusal.)