From 88963bc7ae5b4e5c42947fa7a67aec28bf038352 Mon Sep 17 00:00:00 2001 From: "K. Isom" Date: Mon, 28 Sep 2026 16:21:03 -0700 Subject: [PATCH] M5c-2 plan: task 00 done; the outline follows the recordings Co-Authored-By: Claude Opus 5.5 (1M context) --- docs/plans/M5c2/README.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/docs/plans/M5c2/README.md b/docs/plans/M5c2/README.md index 8a9bbff..2d889b7 100644 --- a/docs/plans/M5c2/README.md +++ b/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 | — | -| 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 | +| 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 }`, 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; `: 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, `: 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 |