M5c-2 plan: task 08, recall's Honcho part; the wiring split out as task 09
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -80,11 +80,12 @@ Honcho sources and chats outside its state lock, and answers `ask_memory`.
|
||||
| 05 | `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; each source's label; `recall_sources` and `resolve`; `own`, `untrusted` and `fleet` reserved as read agents' names | memoryd |
|
||||
| 06 | `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 |
|
||||
| 07 | `memoryd`: local `recall` items in task 06's form, one indented line each, through one shared `snippet` and `item`; `recall::local` gives the items, their count and their label apart (T37) | memoryd |
|
||||
| 08 | `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 |
|
||||
| 09 | `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 |
|
||||
| 10 | `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 |
|
||||
| 08 | `memoryd`: `recall`'s Honcho part (`honcho/search.rs`): every source of `recall_sources` at once, each on its own thread with a limit of 5 s from the start; a read agent's workspace is a search and two conclusion queries; `<source>: unavailable`; a query holding a secret asks nothing; the answer from the local items and Honcho's, with the stricter label | memoryd |
|
||||
| 09 | `memoryd`: `recall` with `[honcho]` runs the local part under the state lock and the Honcho part outside it; the readers taken at start; without `[honcho]`, `recall` as before | memoryd |
|
||||
| 10 | `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 |
|
||||
| 11 | `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 |
|
||||
|
||||
After task 10, the design model runs the M5c-2 device check (spec 13) on straylight, rift and the
|
||||
After task 11, the design model runs the M5c-2 device check (spec 13) on straylight, rift and the
|
||||
owner's Mattermost: a second `memoryd` under its own name writes a fleet note that `recall` finds,
|
||||
tagged `memory-tainted`, turning the session untrusted; `ask_memory` answers from the agent's own
|
||||
trusted workspace within its limit; with rift down, `recall` answers from the local index with
|
||||
@@ -105,6 +106,7 @@ The gate count is the passed total of `cargo test --workspace` plus one, for the
|
||||
| 05 | 1403 | 24, 24 |
|
||||
| 06 | 1414 | 22, 22 |
|
||||
| 07 | 1418 | 15, 15 |
|
||||
| 08 | 1430 | 19, 19 |
|
||||
|
||||
**A flaky test, fixed before the run:** `bxctl`'s `chat_approvals` test
|
||||
`json_prints_only_json_and_never_asks_brokerd` failed once in 5 loaded runs of the whole workspace
|
||||
|
||||
Reference in New Issue
Block a user