Age-based synthetic reclaim can silently discard still-relevant tool output

[tracycam]

Problem

Magic Context currently has a positional two-pass reclaim path for tool results:

1. an execute-class pass advances tool_reclaim_watermark /
   last_execute_ordinal to the current frontier;
2. a later mutating execute or hard-fold pass selects every older tool arc at or
   below that frontier;
3. those arcs are dropped even when there was no explicit ctx_reduce request,
   no semantic supersession, and no emergency context pressure.

This makes tool output disappear as a side effect of an otherwise unrelated
context mutation. Age alone is not a reliable indication that a tool result is no
longer useful, so the behavior can remove evidence the model still needs and make
context changes difficult to attribute or debug.

The same policy exists in the OpenCode plugin, Pi plugin, and Rust module selector.

Expected behavior

Normal tool-result removal should have an attributable trigger:

• an explicit agent ctx_reduce request;
• a configured smart_drops supersession rule; or
• emergency context-pressure protection.

A previous execute watermark should not silently select a tool result for removal.

Proposed change

• Remove the age/watermark synthetic reclaim selector and watermark advancement
  from OpenCode and Pi.
• Remove the equivalent selector from the Rust module.
• Keep explicit ctx_reduce, smart_drops, Historian/Dreamer behavior, and
  emergency cleanup unchanged.
• Retain the legacy storage fields as inert compatibility data so existing
  databases and serialized state do not require a migration.
• Update documentation and generated schema/reference wording so smart_drops
  no longer implies general age-based cleanup.

Compatibility / trade-off

No schema migration is required. Context may retain more old tool output when
neither explicit reduction nor a supersession rule applies; emergency cleanup
remains the final pressure guard.

[ualtinok]

Thanks for the detailed report and for taking the time to build a full PR — this prompted a source-level re-audit of the reclaim gates on our side, and the result is: part of your report identifies a real gap we will fix, but the removal itself we don't want to take. Here's the full picture.

Where the report is right. The age sweep is supposed to be a pressure valve, but there is one path where it fires without genuine pressure: the OpenCode consumer treats a hard-fold pass (m0HardFoldThisPass) as a qualifying reclaim pass, and hard folds can be triggered by non-pressure events (idle TTL expiry, model switch). On such a pass at low usage, with any other pending op mutating, the sweep drops every pre-watermark tool arc even though nothing needed reclaiming. That is exactly the "removal as a side effect of an unrelated context mutation" you describe, and it's a real defect. Two smaller gaps from the same audit: the sweep has no minimum-size floor (it will spend a drop on a tiny read result) and no todowrite exclusion (only the smart_drops supersession path has keep-newest-1).

Where we read the design differently.

1. The trigger is pressure, not position. Outside the fold-path defect above, the watermark only advances and the sweep only fires on execute-class passes, and the scheduler only decides "execute" when context usage crosses the execute threshold. A session that stays below the threshold never runs the sweep. The eligibility rule (arc existed at the previous execute pass) is a recency guarantee: the model had a full pressure cycle to reference the output and didn't.
2. The drops are not silent or unrecoverable. Every dropped arc leaves a [dropped §N§] placeholder carrying its tag id on the wire (the newest 20 keep their full tool_use/tool_result shell), the original bytes are retained in the source_contents table indefinitely, and ctx_expand recovers any dropped output in full by tag or message ordinal. The agent-facing guidance documents exactly this contract.
3. Removing the lane makes the failure mode worse, not better. For any agent that doesn't call ctx_reduce diligently — which is most real-world usage — this lane is what keeps long sessions in the healthy band between the execute threshold and the emergency boundary. Without it, old tool output accumulates until the ≥85% emergency planner runs, and that removal is larger, tier-based, and less attributable than the gradual sweep. The PR's own compatibility note ("context may retain more old tool output... emergency cleanup remains the final pressure guard") describes precisely this trade, and we think it's the wrong side of it.

What we'll do. Rather than removing the lane, we're tightening it so every firing is genuinely pressure-attributable:

• gate the age sweep on the scheduler's execute decision only (usage above the execute threshold), excluding non-pressure hard-fold passes — this closes the defect you found;
• add a minimum-size floor so drops only spend where they reclaim meaningful tokens;
• exclude the newest todowrite from the age sweep to match the supersession rule.

That lands in the next release with credit to this report. On PR #240 itself: beyond the design disagreement, the branch is against v0.32.x and the Rust selector/transform have since moved substantially (the selection surface is also part of a cross-component contract with the Claude Code integration layer, where reclaim semantics are pinned by a protocol epoch), so we're closing it rather than reworking it — but the report did its job: it found a real hole, and the fix is coming. Thank you.