From 2926031b4da64e311c8e22e42006ad043ff1872a Mon Sep 17 00:00:00 2001 From: "K. Isom" Date: Mon, 28 Sep 2026 07:59:30 -0700 Subject: [PATCH] docs: M5c spec: sends are at least once, skip in decided lines, sync from when Honcho is on The ledger cannot promise an item is never sent twice: a crash between a send and its sent line, or an owner removing that line, sends it again. A decided line holds a skip and its reason, as task 07's ledger does. Turns from before sync began are skipped (owner's decision, 2026-09-28). Co-Authored-By: Claude Opus 5.5 (1M context) --- docs/specs/2026-09-27-m5c-honcho.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/docs/specs/2026-09-27-m5c-honcho.md b/docs/specs/2026-09-27-m5c-honcho.md index dce21cf..5cecbe0 100644 --- a/docs/specs/2026-09-27-m5c-honcho.md +++ b/docs/specs/2026-09-27-m5c-honcho.md @@ -138,10 +138,15 @@ rebuilt from them. `honcho-send-refused`), and the worker moves on. `bxctl memory sync` lists failed entries. **The ledger**, `memory/honcho.jsonl`, is append-only JSON lines, one per event: `decided` (the -item, the workspace or `none` and why), `sent` (the item and Honcho's ids), `failed` (the item and -the status). What is decided and not sent is the outbox; there is no separate queue. An item is -never sent twice: the worker checks for its `sent` line first, and on start `memoryd` reads the -ledger through. Items are a turn (`session`, `turn`) or an edit (its journal id). +item, and the workspace it goes to or `skip` and why), `sent` (the item and Honcho's ids), `failed` +(the item and the status). What is decided and not sent is the outbox; there is no separate queue. +The worker checks for an item's `sent` line before sending it, and on start `memoryd` reads the +ledger through, so an item is sent at least once and a second time only if a crash falls between +the send and its `sent` line, or the owner removes that line (Honcho cannot delete a message). +Items are a turn (`session`, `turn`) or an edit (its journal id). + +**Sync starts when Honcho is turned on.** The ledger records when sync began, and a turn that +started before then is skipped, so turning on `[honcho]` never sends earlier conversations. Everything written to Honcho is neutralised (`sanitize::neutralise`); a reply is the model's own output and was logged as it came, so it is neutralised here, when it leaves.