Preserve semantic work groups and paginate turn details

[ymichael]

Human comments

What was wrong

The timeline was conflating semantic grouping with transport grouping. A completed provider turn can contain visible assistant replies between long-running work, and its byte/event windows can overlap those replies because an item may start before a reply and complete after it. The server flattened the semantic work groups, gave completed transport fragments a shared identity, and the client merged that identity at its earliest position. Expansion then treated the row's overlapping numeric range as semantic ownership, so visible assistant replies and straddling commands could appear both at the root and inside “Worked for…”.

What changed

• Preserve separate completed-work groups around visible assistant replies. A provider turn may therefore render several “Worked for…” rows when replies are interleaved with work.
• Give every timeline transport fragment a page-local ID. The client coalesces completed-turn fragments only when they are adjacent at the exact older/newer page seam, so it can join one semantic group across byte or event windows without crossing a visible row.
• Scope the paginated detail resource to the selected row's { turnId, sourceSeqStart, sourceSeqEnd }; bind those values into its cache key and opaque cursor on desktop, mobile, the public contract, and @bb/sdk.
• Reconstruct semantic detail ownership with the neighboring assistant messages and completed-turn lifecycle as context-only inputs. Items that started before the selected semantic group stay with the earlier group even when they completed inside the selected numeric range. Lifecycle/parent closure is allowed to adjust projected bounds without making those context rows children.
• Keep the existing exact-range resource's behavior unchanged. The row-scoped resource first uses exact full-output hydration; only the former 4 MiB 413 path falls through to forward, byte-bounded pagination. Expansion fetches one page initially and exposes Load more work when another page exists—there is no automatic drain or parallel byte-window fan-out.
• No host-daemon wire contract changed, so HOST_DAEMON_PROTOCOL_VERSION is unchanged.

The complete branch is 836 net non-test lines plus 682 net regression-test lines. The product code includes the desktop/mobile/CLI/server/SDK surfaces for the new resource; the tests cover byte paging, semantic grouping, page-seam merging, context reconstruction, and straddling-item ownership.

How you verified

The new regressions fail on the old behavior and cover both correctness failures: work split by visible assistant replies, and a command that starts before a visible reply, completes after it, and has its following assistant message beyond the row's numeric range.

• After merging current main, timeline-in-turn-window.test.ts and public-thread-data.test.ts passed 31/31 and 79/79 (110 total).
• The full @bb/thread-view, @bb/client-core, @bb/server-contract, @bb/db, and @bb/sdk suites passed (23, 20, 7, 28, and 6 test files; 410 DB tests alone).
• The web query and auto-merged timeline-action tests passed 55/55; the mobile timeline grouping tests passed 7/7.
• Turbo typechecks passed for @bb/app, @bb/mobile, @bb/server, @bb/client-core, @bb/db, @bb/sdk, @bb/server-contract, @bb/thread-view, and @get-bb/plugin-sdk. The npm version guard passed for the new 0.4.21 SDK version.
• Against a validated SQLite copy of the production DB, thr_s97hwwr8ei / daccf028b3-t2 now renders 6 work rows interleaved with 16 visible assistant replies. Expanding all 6 rows produced zero visible-assistant source intersections, zero duplicate assistant IDs, and zero duplicate work IDs.
• On that production copy, all 6 rows fit the exact first response (no fallback page needed). Their post-merge local response times were 112, 33, 18, 50, 10, and 9 ms; the largest response was 2.37 MB.
• A rendered browser check at the reported message confirmed the 6 work rows and 16 replies remain in semantic DOM order. Expanding the largest row completed in 169 ms, rendered without an error or load-more fallback, and left its following visible assistant reply present exactly once.

Fixes: no filed issue; reproduced from a production thread timeline. Supersedes #2361.

AGENT GENERATED

[ymichael]

Live worktree proof: open the oversized completed-turn fixture.

The fixture is one 508-event / 12.01 MiB completed turn. Browser QA against the optimized worktree build shows one canonical Worked for 1h 24m 20s row. Opening it completes exactly one detail request and renders 83 commands plus Load more work; clicking that control completes exactly one cursor request and advances the row to 166 commands.

AGENT GENERATED

[ymichael]

Updated proof after the exact-then-fallback simplification: open the oversized completed-turn fixture.

The fixture is one 508-event / 12.01 MiB completed turn. Walking its four top-level timeline byte windows returns four disjoint source ranges with the same canonical turn-row ID, which the client merges into one Worked for… row with 250 items.

For the complete 1…508 range, the unchanged exact-range resource still returns 413 timeline_window_too_large. The logical-turn resource catches only that outcome and exposes four forward byte pages; exhausting their opaque cursors recovers all 250 unique command rows. The first fallback page contains 83 commands and Load more work. There is no 250-event detail cap or automatic page drain.

AGENT GENERATED

[ymichael]

Superseded by #2464 (oversized detail pagination) and #2466 (semantic window correctness). The replacement stack keeps the concerns reviewable separately and includes the copied-production canonical/corpus audits and explicit performance numbers.