The feed pages by cursor, not by page number: a long timeline loads in constant time and never repeats or skips a post when new ones arrive #10396

The feed can now be read as a plain newest-first timeline with before=<cursor>, one page costing the same at any depth. I ran tsc, gate.ts, design-lint, mcp-size and the feed, home, events, openapi and mcp-feed tests, and they pass. I did not run the whole suite; fast.ts named 1,990 test files for this diff, which is too broad to run here. test/home-fit.test.ts and test/home-buttons-rest.test.ts skipped because no chromium starts in the sandbox.

The existing feed is ranked over a window of the 300 newest events, so it cannot go deeper than that. A cursor into that ranking can't give "constant time, no repeat or skip", so I added a second mode beside it instead of redesigning it.

What changed

• New mode (src/feed/timeline.ts): GET /api/v1/feed?before=now answers { items, next_cursor }. Pass each next_cursor back as before.
• Same mode elsewhere: MCP feed takes before (no new tool, and mcp-size passes), and /feed?before=… renders it as a page.
• The cursor is an event id (a ULID, so time and identity in one). Posts arriving between two requests land above the cursor, so nothing repeats or skips. Equal timestamps order by the log's write order.
• Bad cursors: a malformed cursor, or before combined with cursor, is a 422. A well-formed before only picks where to start; visibility still comes from the log query. A test has Bob use Alice's private event id and read nothing hidden.
• Supporting edits: listEventsVisibleTo now honours beforeId. The event-to-candidate loop became eventCandidates in items.ts, and the page decoration became decorate in feed.ts, so both modes share them. The OpenAPI route and docs/features/feed-cursor.md are updated.
• No script needed: "Older posts" is a plain link. The ranked page's last line links to "Everything, newest first", which is the way in.
• Tests (test/feed-cursor.test.ts):

- posts inserted between page one and page two leave no duplicate and no gap; - an equal-timestamp burst keeps its order; - walking 50 pages of 20 on 5,000 seeded posts gives 1,000 distinct posts; - the 50th page's time is checked against the first page's time, with a generous bound.

What I left out

• Timeline contents: it has no shares, asks or other standing items (they aren't in the log), no burst folding (a fold would straddle a page), and no quiet-run count. Mutes, dismissals and chips still apply.
• Ranked feed: unchanged, so it still ends at its window.
• Short pages: if filters hide most of a batch, a page can come back short but still carries a cursor, because each read is capped at 5 rounds of 100 events.
• Query plan: I did not add a hot-reads-indexed plan test for the new read. It uses the existing event ordering and its index.
• Pre-push hook: it demanded a Try: line in the commit message, so I added one.

Try it: open /feed?before=now and follow "Older posts", or call /api/v1/feed?before=now&limit=20 and pass next_cursor back as before.

Closes #10392

The feed can now be read as a plain newest-first timeline with before=<cursor>, one page costing the same at any depth. I ran tsc, gate.ts, design-lint, mcp-size and the feed, home, events, openapi and mcp-feed tests, and they pass. I did not run the whole suite; fast.ts named 1,990 test files for this diff, which is too broad to run here. test/home-fit.test.ts and test/home-buttons-rest.test.ts skipped because no chromium starts in the sandbox.

The existing feed is ranked over a window of the 300 newest events, so it cannot go deeper than that. A cursor into that ranking can't give "constant time, no repeat or skip", so I added a second mode beside it instead of redesigning it.

What changed

• New mode (src/feed/timeline.ts): GET /api/v1/feed?before=now answers { items, next_cursor }. Pass each next_cursor back as before.
• Same mode elsewhere: MCP feed takes before (no new tool, and mcp-size passes), and /feed?before=… renders it as a page.
• The cursor is an event id (a ULID, so time and identity in one). Posts arriving between two requests land above the cursor, so nothing repeats or skips. Equal timestamps order by the log's write order.
• Bad cursors: a malformed cursor, or before combined with cursor, is a 422. A well-formed before only picks where to start; visibility still comes from the log query. A test has Bob use Alice's private event id and read nothing hidden.
• Supporting edits: listEventsVisibleTo now honours beforeId. The event-to-candidate loop became eventCandidates in items.ts, and the page decoration became decorate in feed.ts, so both modes share them. The OpenAPI route and docs/features/feed-cursor.md are updated.
• No script needed: "Older posts" is a plain link. The ranked page's last line links to "Everything, newest first", which is the way in.
• Tests (test/feed-cursor.test.ts):

- posts inserted between page one and page two leave no duplicate and no gap; - an equal-timestamp burst keeps its order; - walking 50 pages of 20 on 5,000 seeded posts gives 1,000 distinct posts; - the 50th page's time is checked against the first page's time, with a generous bound.

What I left out

• Timeline contents: it has no shares, asks or other standing items (they aren't in the log), no burst folding (a fold would straddle a page), and no quiet-run count. Mutes, dismissals and chips still apply.
• Ranked feed: unchanged, so it still ends at its window.
• Short pages: if filters hide most of a batch, a page can come back short but still carries a cursor, because each read is capped at 5 rounds of 100 events.
• Query plan: I did not add a hot-reads-indexed plan test for the new read. It uses the existing event ordering and its index.
• Pre-push hook: it demanded a Try: line in the commit message, so I added one.

Try it: open /feed?before=now and follow "Older posts", or call /api/v1/feed?before=now&limit=20 and pass next_cursor back as before.

This pull makes the home feed page by cursor: before=<event id> reads the log newest first, so the 50th page costs the same as the first. This round addresses all of Sentinel's points.

What changed this round

• Terminal door: the feed screen in src/tui/screens/feed.ts has a t key. It switches between the ranked feed and every post, newest first, using readTimeline, and n pages on by cursor. Access is the same as the page, since both go through the same readTimeline. A TUI test covers it.
• Dead end without script: caughtUp returns null only when the page is empty and next is also null. A page the filters emptied now says "Nothing to show on this page" and still shows the Older posts link. A test covers this: 600 hidden events, an empty page that still has a cursor, the HTML link, and following it reaches posts.
• 50th-page test: the wall-clock bound is gone. The test now asserts that page 50 runs exactly one event read batch, and that its query plan has no temp b-tree and no full scan of event.
• Untested paths now covered:

- MCP before: paging gives disjoint pages, and before with cursor or a garbage before is refused. - API: a timeline page answers 304 to its own ETag, and a different before gets a different ETag and a 200.

• Tidy: the src/http/feed.ts import is with the others, and the home_last.ts import sits beside its sibling feed import. data-timeline is removed. The wording is now "That's every post" in the timeline, and "That's everything" on the ranked page, as it was before. "Everything, newest first" appears once, as the link.

Not done: shares, asks and the folding of bursts stay out of the timeline, as before. Nothing beyond the feed was touched.

How to try it: open /feed, follow "Everything, newest first" and then Older posts, or call GET /api/v1/feed?before=now. The MCP feed tool takes before. In the terminal, open Feed and press t.

Checks: tsc, gate.ts and design-lint are clean. scripts/fast.ts said the diff was too broad to name tests, so I ran the feed, home-feed, TUI, MCP and hot-reads suites by hand: 222 pass, 0 fail. I did not run the full suite.