[orbitingflea]

This pull request makes display modes load only the history they show.

改了什么行为

Behaviour change: yes, a web or desktop user whose thread is in Messages only, Messages + Dashboard or Chat + Replies opens it on its latest shown messages (and in Chat + Replies the sub-threads of the loaded replies) instead of an empty pane with only "Load earlier turns"; "Load earlier turns" there loads earlier shown messages; the open sub-thread view has no "Load earlier turns". Normal threads, the mobile app and guest shares are unchanged.

Why

The server picked the first window and older pages by Normal rules. In a thread with many bot turns, those rows were mostly bot work that these modes hide. So the pane showed only "Load earlier turns", and the Replies list lost replies whose first message was not loaded. Now, for these modes, the server reads only shown messages.

Checks

• 15 tests fail before the fix and pass with it: 13 on the server, for the window, pages, replies, forks and the HTTP route, and 2 on the client, for snapshots and paging.
• In a browser at desktop and phone size, a thread with 90 bot turns opened on its messages in Messages only. In Chat + Replies the Replies list showed its sub-thread. Normal showed every row. A thread with 140 messages opened on its latest ones, and one "Load earlier turns" click loaded the rest.
• On a thread with 23,923 rows, the shown window held 141 messages and the Normal one 23, both in about 0.2 to 0.3 s. A shown older page took 23 to 56 ms; a Normal one took 716 to 824 ms.

Details

How it works

• Contracts. The thread subscription gets an optional shownOnly, and the HTTP bounded snapshot an optional shownOnly=1. The server reports the capability threadShownHistory. The web asks for a shown view only when the server has it, so an old server keeps today's behaviour.
• Server, in apps/server/src/fork/shownHistory/. The SQL keeps messages the user typed in the web or mobile app (not scheduled, not from another thread, not idle compaction) and calls whose tool name holds send_to_user, which also covers replace_send_to_user. In the thread itself it drops rolled-back runs and cancelled queued turns. From a fork parent it reads rows up to the fork run. One walk goes newest first across the thread and its fork parents. The shared foldCores counts messages and finds the first message of each reply.
• Limits. The window stops at 120 messages with every reply's first message, or at 600 rows or 512 KiB. A page stops at 100 messages, or at 1,000 rows or 1 MiB. A page that targets one message reads until that row is in, with double caps. When a cap stops the walk before a reply's first message, that reply comes with an older page.
• The window also keeps the thread's newest row, running items and failed errors from the same stretch, and pending request cards as before.
• The history cursor is upstream's cursor plus fv: "shown". A shown cursor goes to the shown pager. Every other cursor, and every view=work page, goes the Normal way.
• Client. A shown view is a separate keyed state with its own resume entry. It never reads or writes the saved thread snapshot. One "Load earlier turns" click sends one request.
• Web. Each thread mounts one view: shown when the server has the capability and the mode is not Normal. Until settings arrive, a per-viewer localStorage list of threads last seen in a display mode decides, so a cold start opens one view. The row cache for thread switches is keyed by mode. A shown view does not treat its oldest message as the thread start for revert. The Replies list shows loading and error states. When more history exists, it says "No replies in the loaded messages." and has a "Load earlier messages" button.

Upstream lines

+88 −16 in 15 upstream files. The rest is in fork-only files.

File	Lines
ProjectionStore.ts	+24
client-runtime state/threads.ts	+17 −8
threadHistoryPaging.ts	+11 −6
ChatView.tsx	+8 −1
http.ts	+5
ws.ts	+4
web state/threads.ts	+4 −1
boundedThreadSnapshotHttp.ts	+4
Orchestrator.ts	+2
ThreadStream.ts	+2
environment.ts	+2
orchestrationV2.ts	+2
ServerEnvironment.ts	+1
environmentHttp.ts	+1
threadSnapshotHttp.ts	+1

Left out

• Live events are not filtered. A busy bot's live rows still arrive, and the mode hides them.
• No new index. The walk uses the existing thread and ordinal index.
• The mobile app draws Normal in every mode and keeps today's requests. Guest shares are also unchanged.
• Shown views are not saved in IndexedDB.

Undo

Revert the two commits. There is no schema or data change. Without the capability, the web asks for Normal views again.

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Codex	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Codex	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Codex	Live turn WebSocket decoded	21.5 KiB	21.5 KiB	0 B (0.0%)	24.4 KiB	✅
Codex	Live turn messages	1	1	0 (0.0%)	8	✅
Claude	Total thread wire	5.0 KiB	5.0 KiB	0 B (0.0%)	6.8 KiB	✅
Claude	Thread snapshot wire	3.8 KiB	3.8 KiB	0 B (0.0%)	4.9 KiB	✅
Claude	Live turn WebSocket wire	1.2 KiB	1.2 KiB	0 B (0.0%)	2.0 KiB	✅
Claude	Live turn WebSocket decoded	21.9 KiB	21.9 KiB	0 B (0.0%)	24.4 KiB	✅
Claude	Live turn messages	1	1	0 (0.0%)	8	✅

Baseline: 53f7f31 · PR result: bea4716 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.