Follow-up carved out of #216 / #217.
Problem
#217 fixed the INBOX (now sourced from the uncapped pending_list()). The settled LOG —
activity_settled(&self.activity), day-grouped in the Activity feed — still reads the 200-capped
activity_feed(). So in a >200-record session the oldest settled rows (executed / denied /
expired / auto-allowed history) are absent from the history band.
Unlike #216 this is display-only: it's the LOG, it gates no approval, carries no trust cue, and
the newest 200 settled rows (the ones anyone scrolls) are always present. It's the remaining edge of
the same cap.
Options
- Accept the 200-cap as the LOG's intended size bound and document it as such (the honest "this is a
capped log, not an audit trail" stance), or
- Paginate the log (cursor / "load more") if browsable session history is wanted — the LOG call is
the correct place for pagination now that the inbox is separate and complete.
Severity: ~P3 (cosmetic; capped history, no correctness/trust impact).
Follow-up carved out of #216 / #217.
Problem
#217 fixed the INBOX (now sourced from the uncapped
pending_list()). The settled LOG —activity_settled(&self.activity), day-grouped in the Activity feed — still reads the 200-cappedactivity_feed(). So in a >200-record session the oldest settled rows (executed / denied /expired / auto-allowed history) are absent from the history band.
Unlike #216 this is display-only: it's the LOG, it gates no approval, carries no trust cue, and
the newest 200 settled rows (the ones anyone scrolls) are always present. It's the remaining edge of
the same cap.
Options
capped log, not an audit trail" stance), or
the correct place for pagination now that the inbox is separate and complete.
Severity: ~P3 (cosmetic; capped history, no correctness/trust impact).