Why
Both activity pages stop at a fixed number of events: the repository feed is truncated at 100, and the instance feed merges 100 per repository and then takes 200 before paginating. Anything older is unreachable — there is no page 2 for the repository feed, and the instance pager runs out after four pages no matter how much history exists.
Now that issues, changes, comments and state changes are index rows (#113, #126), the whole feed can be assembled from the database and paginated.
Scope
- Remove the fixed truncations; the repository feed and the instance feed each keep the whole sorted, filtered event list.
- Paginate both: 50 events per page, with the pager on the repository feed (it has none today) and the existing one on the instance feed now reaching all history.
- The filters (
kind,actor,assignee) travel through page links; changing a filter starts again at page one. - The repository pager swaps the
#activity-feedfragment over HTMX, like the chips and the filter form do. - The feed’s comment read becomes a summary query (parent, id, author, created) instead of loading every comment body it will not render.
Acceptance
- A repository with 55 events shows 50 on page one and 5 on page two; the instance page shows the same.
- The oldest event is reachable from the last page on both.
- A filtered feed keeps its filters in the next/previous links.
- The home page rail still shows only its handful of events.
Notes
The feed is assembled in memory from the index, so a page costs O(history) rather than O(page). That is acceptable at this size; if an instance’s history makes it visible, the follow-up is a SQL event stream (a UNION over the source tables) that can paginate without materialising every event.