Follow-up carved out of #216 / #217 (kept separate as agreed — a perf concern, not the #216 correctness bug).
Problem
self.requests grows unbounded per unlocked session: propose inserts, expire_stale() only flips
status in place, terminal records are never pruned (no remove/retain), and the map is only ever
cleared wholesale on Unlock (daemon.rs). The 200-cap on activity_feed() was masking this. Now
that the INBOX correctly reads the uncapped pending_list() (#217), both pending_list() and
activity_feed() iterate and serialize the full map on every ~2s poll — over a long agent session
that's a growing per-poll frame/serialize cost, and the live-Pending set itself has no admission
bound.
Direction (not a decision)
- Bound the settled tail via a retention/prune policy (keep the newest N settled + all open),
applied in expire_stale/resolve/execute.
- Optionally bound the live-
Pending set via proposal admission (rate-limit / cap concurrent
open proposals per session).
Hard invariant (from #216)
Never apply a cap to the pending/Pending subset. Any cap on the inbox re-opens #216 (a waiting
approval hidden/unreachable). Only the settled LOG is safe to bound.
Severity: ~P3 (perf/memory over a long session; no wrong trust cue).
Follow-up carved out of #216 / #217 (kept separate as agreed — a perf concern, not the #216 correctness bug).
Problem
self.requestsgrows unbounded per unlocked session:proposeinserts,expire_stale()only flipsstatus in place, terminal records are never pruned (no
remove/retain), and the map is only evercleared wholesale on Unlock (
daemon.rs). The 200-cap onactivity_feed()was masking this. Nowthat the INBOX correctly reads the uncapped
pending_list()(#217), bothpending_list()andactivity_feed()iterate and serialize the full map on every ~2s poll — over a long agent sessionthat's a growing per-poll frame/serialize cost, and the live-
Pendingset itself has no admissionbound.
Direction (not a decision)
applied in
expire_stale/resolve/execute.Pendingset via proposal admission (rate-limit / cap concurrentopen proposals per session).
Hard invariant (from #216)
Never apply a cap to the pending/
Pendingsubset. Any cap on the inbox re-opens #216 (a waitingapproval hidden/unreachable). Only the settled LOG is safe to bound.
Severity: ~P3 (perf/memory over a long session; no wrong trust cue).