Page giant turns' work and collapse the active-turn frontier

[SawyerHood]

Problem

Very long threads — especially a single agent turn running for hours — became progressively expensive to load and update. The worst sample turn (thr_n8ptu7bf8f) is 335 minutes / 7,025 events / 27 MB:

• Active turns never collapsed: every event rendered as a flat row, the server re-projected the whole turn per delta tick, and the un-virtualized list grew without bound → browser freezes.
• Expanding a completed giant turn fetched the entire turn's detail un-truncated in one response (~14 MB projected for the largest segment).
• The conversation outline re-read every event in the thread on each update.

#711 tried to bound responses by raw row/byte budgets and was reverted in #722 because the cut could fall mid-turn behind a generic "Load older" control. This change keeps that constraint front and center: top-level segment pagination is untouched — a visible response always starts with its initiating user message — and all new bounding happens inside a turn's "Worked for…" section.

What changed

Paged turn work ("Show earlier work")

• GET /threads/:id/timeline/turn-summary-details gains workItemLimit (newest-N page + earlierCursor) and afterSeq (exact catch-up range). Windows resolve from the indexed item/completed sequence; items straddling a window edge still project fully from their completion payload; paged rows get the timeline's 32 KB output truncation. Omitting both params keeps today's full, un-truncated detail (small turns, CLI).
• LazyTurnRowBody pages large turns (partial rows, or completed turns above 60 work items) through immutable per-window segment queries with a nested "Show earlier work" control. Expansion shows newest work first; revealed windows are keyed by summary-row id so they survive collapse/expand, live-turn growth, and the completion transition; prepends anchor scroll exactly like "Load older messages".

Active-turn frontier collapse ("Worked so far")

• Once a running turn accumulates ~48 finished work items, its settled prefix collapses into a partial turn row (partial: true, title "Worked so far (2h 5m)"). Running commands, waiting approvals, unanswered questions, and the most recent ~24–47 finished items stay flat below it.
• The frontier derives from indexed completion counts only and moves in 24-item chunks (hysteresis), so row identity churns at most once per chunk and delta payloads stay small. On completion the row converges to the normal "Worked for…" summary at the same row id; steer boundaries split partial summaries exactly like completed ones.

Targeted conversation outline

• Re-lands Bound large thread timeline responses #711's outline event selection, plus turn-lifecycle/error events so completed-turn grouping matches the timeline and interim assistant messages don't leak into the minimap.

Measured (copy of the 39 MB sample thread)

Scenario	Before	After
Latest page while the giant turn is active	~7,000 rows / 27 MB	69 rows / ~420 KB
Expanding the 980-item turn segment	13.9 MB, un-truncated, one shot	~210 KB / ~15 ms per 40-item window
Full page walk of that segment	—	24 windows, 378 ms total, full coverage, no dupes
Conversation outline	full-thread read per update	49 ms / 108 KB
HTTP paged vs full detail (485-item turn)	2.3 MB / 81 ms	94 KB / 15 ms

Validation

• New unit tests: partial collapse (frontier partition, settled-work rules, id stability across completion), work-page builder (children-only completed windows, straddled items, pending-work drop/finalize), server paging (cursor walk, catch-up ranges, degraded stale windows, chunk hysteresis), outline/timeline row-id equivalence.
• pnpm exec turbo run typecheck across the repo; full test suites for @bb/server, @bb/thread-view, @bb/db, @bb/app, @bb/server-contract, @bb/cli, @bb/sdk.
• Real-data verification against a copy of the live DB (numbers above), plus end-to-end UI QA in the dev app: expanded the 1h38m turn, paged earlier work, and confirmed the scroll anchor holds to the pixel.

Follow-up (documented in plans/long-thread-timeline-pagination.md)

• Bounded event selection: a cache-miss timeline build still reads/parses every event in the window (~600 ms on the sample thread, once per appended event batch). The collapse frontier is already computed from indexed queries, so the selection can skip collapsed-prefix payloads next.
• Optional per-item "show full output" fetch for truncated outputs inside paged windows.
• List virtualization if profiling still warrants it after this lands.

🤖 Generated with Claude Code

[SawyerHood]

Ran one multi-angle review round over the diff (8 finder angles + verification) and pushed the fixes in ff042a3. Highlights of what it caught:

• Cache determinism: the collapse-frontier queries weren't bounded by the build's maxSeq, so a response cached at revision N could bake in a frontier derived from newer events; the conversation outline also built without frontiers, breaking the minimap's row-id contract for running giant turns (jump-to-message would page the whole thread hunting for a collapsed row). Both now share the same bounded frontier.
• Index reality check: EXPLAIN QUERY PLAN showed the completion-count/nth/descending queries doing per-row table seeks (or whole-thread scans for the OFFSET variant). Added a partial covering index (thread_id, turn_id, sequence, item_kind) WHERE type='item/completed' via drizzle-kit.
• UX edges: "Show earlier work" no longer flickers out while its page loads; groupable steer messages are no longer dropped from paged windows; an empty settled prefix no longer emits a bogus "Worked so far" row; expansions refetch once on turn completion so interrupted work appears finalized instead of vanishing.
• Contract compliance: the SDK now forwards workItemLimit/afterSeq (they were accepted-but-ignored, which AGENTS.md forbids). A dedicated bb CLI surface for paging turn work is noted as follow-up.

Full suites green after the fixes (the one failing app test is the pre-existing flaky promptbox slash-token test; it passes in isolation).