M5c-2 plan: task 00 done; the outline follows the recordings

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

docs/plans/M5c2/README.md

@@ -29,7 +29,10 @@ Honcho sources and chats outside its state lock, and answers `ask_memory`.
 2. **Two workspaces per `ask_memory` call**, both asked at once, so both answer inside
    `brokerd`'s wait; the model asks again for more.
 3. **New recordings from rift** for the fake server (task 00), in a throwaway workspace deleted
-   afterwards, as in M5c-1.
+   afterwards, as in M5c-1. They changed two things (spec, `891f413`): `ask_memory`
+   always asks at `minimal`, since a `low` chat on rift returned raw tool-call markup; and a
+   Honcho hit is kept only when it shares a term with the query, since search has no relevance
+   cutoff.
 
 ## What the code already has, and what it lacks
 
@@ -69,12 +72,12 @@ Honcho sources and chats outside its state lock, and answers `ask_memory`.
 
 | # | Delivers | Crates |
 |---|---|---|
-| 00 | (the design model, before the run) recordings from rift: workspace search with a limit, conclusion queries for two peers, chat at `minimal` and `low`, and what a missing workspace answers | — |
+| 00 | (done by the design model, `718e66d`) recordings from rift: workspace search with a limit and with no match, conclusion queries for two peers, and what a missing workspace answers | memoryd fixtures |
-| 01 | Wire: `AskMemoryArgs { question, workspaces, reasoning }`, its name and its checks (question at most 2,000 characters; one or two workspace names, no repeats; `minimal` or `low`); fixtures | bxcore |
+| 01 | Wire: `AskMemoryArgs { question, workspaces }`, its name and its checks (question at most 2,000 characters; one or two workspace names, no repeats); fixtures | bxcore |
 | 02 | `brokerd`: `ask_memory` as a built-in memory tool (grant, parsing, routing to `memoryd`); a per-tool wait on `memoryd`, 170 s for `ask_memory` and 30 s for the others | brokerd |
 | 03 | `loopd`: `ask_memory`'s schema as a core tool in a new registry; a per-tool wait on `brokerd`, 180 s for `ask_memory` and `[broker] timeout_ms` for the others; the system prompt's line on memory tools | loopd |
 | 04 | `memoryd`: read clients, one per `[[honcho.read]]` workspace, the fleet and the agent's own two, with a 5 s limit for searches and 150 s for chat | memoryd |
-| 05 | `memoryd`, pure: Honcho messages and conclusions as `recall` items (tag, source name, class, neutralised, capped), interleaved with the local hits to `k`, the local index first | memoryd |
+| 05 | `memoryd`, pure: Honcho messages and conclusions as `recall` items (tag, source name, class, neutralised, capped), kept only when they share a term with the query, interleaved with the local hits to `k`, the local index first | memoryd |
 | 06 | `memoryd`: `recall`'s Honcho sources, each on its own thread with its own limit, after the local search and outside the lock; `<source>: unavailable`; a query holding a secret sends nothing | memoryd |
 | 07 | `memoryd`: `ask_memory`: workspace names checked against `[honcho]`, both chats at once, each answer tagged and capped, labels, `<workspace>: unavailable`; a question holding a secret sends nothing | memoryd |
 | 08 | `memoryd` serves `ask_memory` beside `recall` and `memory`, outside the lock; `bxctl`'s usage and the runbook where a new message needs a pointer | memoryd, bxctl |