Design question: compaction preserves tool receipts but discards tool results — is receipts-only the intended contract? #879

Not a bug — a question about what compaction is meant to preserve

Filed separately from #878 (which is a reachability defect) because this one is a design choice and deserves its own answer.

compactMessages keeps the first user message, subsequent user messages as "decisions", and then receipts of tool calls — name, category, issue, reference — but not their results (src/compaction.ts).

The consequence, once #878 is fixed: after compaction the agent remembers that it read config.txt successfully, but not what was in it. For a coding agent the file contents are usually the reason the turn happened at all, so the summary preserves the audit trail and drops the payload.

Why I noticed

I compared oh-my-cli against opencode on a local MLX server with a ~24k-token usable ceiling. opencode's compaction, once its context limit is declared, keeps enough of the content that a value read from a file in turn 1 is still answerable after compaction, without re-reading the file — verified end to end.

That is a different bet: receipts are cheap and auditable, content is expensive and useful. Both are defensible, but they lead to very different behaviour on long sessions, and the current docs do not say which one a user should expect.

Question

Is receipts-only the intended contract, or a first iteration? If intended, it would help to say so where --compact-threshold is documented — a user who reads "compaction" will assume the agent still knows what it learned.

A middle ground that would fit the existing structure: keep tool results for the most recent N turns verbatim (a tail_turns-style knob), receipts only beyond that.