紧凑模式：只要还能「加载更早」，所有已关闭轮次都不折叠（含刚结束的那个）—— 建议折叠门禁从会话级 hasMore 改为逐轮次 turn/start / Compact mode: no closed Turn folds while older history is still loadable, including the one that just finished — gate folding on the Turn's own turn/start instead of session-wide hasMore

[BrokenReflection]

compact-fold-per-turn.patch

摘要

「紧凑」显示模式下，只要会话还能点「加载更早」，所有已关闭轮次都会保持展开、折叠控件也不出现 —— 包括刚从尾部结束的那个轮次。根因是折叠门禁用了会话级的 hasMore，而它真正要防的风险只存在于「自身起始边界尚未加载」的那一个轮次。建议把判据改为逐轮次，并附上基于当前 master 的补丁。

现象

对话显示使用默认的「紧凑」时，若会话打开后仍可点「加载更早」（更早历史尚未加载完），推理行、上下文注入、工具行与较早的 Assistant 内容会一直保持展开，轮次过程控件也不出现 —— 对每一个轮次都是如此，包括刚结束的那个。只有把「加载更早」点到底、历史全部加载完之后，所有合格的已关闭轮次才会一起收起。

复现

1. 打开一个日志长度超过首屏的会话 —— 客户端打开会话时只加载最后 50 条消息（PAGE_MESSAGES = 50，packages/api/session-controller/src/client/sessions/session.ts），所以大多数真实会话都符合条件。
2. 发一条会产生推理或工具调用的消息。
3. 等 turn/end：过程行保持展开，折叠控件不出现。
4. 一直点「加载更早」直到按钮消失：所有合格的已关闭轮次立即收起。

为什么确实需要某种限制

当某个轮次自己的 turn/start 不在已加载窗口内时，processStartSeq 会回退到「已加载的最早证据」（packages/client/ui-chat/src/client/conversation-nodes/turn-process.ts）：

processStartSeq: turn.start?.seq ?? (Number.isFinite(externalProcessSeq) ? externalProcessSeq : answer.finalNode.seq),

此时折叠并不安全：翻入更早的一页会扩大这个范围、并移动控件锚点（controlAnchorSeq），于是刚进入窗口的行会落进已收起的组里 —— 而那正是读者翻上去要看的内容。

建议

把折叠门禁从会话级 hasMore 改为按轮次自身的起始边界判定：

// packages/client/ui-chat/src/client/chat/ChatNodeSeat.tsx
const processWindowReady = processSpec !== undefined
  && processPresentation !== undefined
  && compactTranscript
  && processSpec.answerAnchorSeq !== null
  && processPresentation.turn === processSpec.turn
  && processPresentation.turnClosed
  && processPresentation.membersLoaded   // 原为：&& !historyIncomplete

membersLoaded 由轮次自身的边界派生（packages/client/ui-chat/src/client/conversation-nodes/turn-process-presentation.ts）：

membersLoaded: location.turn.start !== undefined

TurnLocation.start 恰好在该轮次的 turn/start 事件位于已加载窗口之外时为 undefined（packages/client/ui-conversation/src/client/contract/conversation.ts）。由于已加载窗口是一个连续的 [head, tail] 区间，起始落在窗口内的轮次，其全部过程成员必然都已加载 —— 折叠它不可能隐藏尚未翻入的行。

改动后的行为：

• 起始已加载的已关闭轮次立即折叠，无论还剩多少更早的历史；
• 只有窗口头部那个起始页尚未翻入的轮次保持过程行可见，等该页到达后再收起 —— 会话级门禁原本提供的保护，被限定到真正需要它的那个轮次上。

补丁（基于当前 master）

附件 compact-fold-per-turn.patch 由 git format-patch 生成，基线是当前的 master：

• 基线提交：ddefc45fbc（2026-09-17，Merge pull request #4469 … release-dsh-0.1.6-alpha.2），即版本 0.1.6-alpha.2 的 master 顶端
• 补丁提交：c8aad2f88d（2026-09-20）
• 规模：12 个文件，+125 / −24 —— 4 处产品代码与契约、2 个测试文件、双语 README 与配对记录、Agent Note 三件套
• 应用：git am compact-fold-per-turn.patch（保留提交信息）或 git apply compact-fold-per-turn.patch；若 master 已有前进，可 git apply --3way
• 若只想跑测试：pnpm vitest run packages/client/ui-chat

证据

• 组件测试覆盖两个方向（起始页未加载的已关闭轮次保持可见；起始已加载的已关闭轮次在「加载更早」仍在时即折叠），测试 fixture 也已建模 TurnLocation.start：packages/client/ui-chat/tests/chat-view.client.spec.tsx、packages/client/ui-chat/tests/chat-snapshot-fixture.client.ts。
• packages/client/ui-chat 测试套件 358/358 通过。
• 在组装后的 Web GUI 中用长会话手测确认。

希望了解

1. 会话级门禁（hasMore）是有意为之，还是这里本就该用逐轮次的 turn/start 边界？
2. 如果规则确实要保持会话级，它保护的、而逐轮次边界覆盖不到的场景是什么？

---

Summary

With the default Compact conversation display, as long as a Session can still load older history (the Load earlier button is visible), every closed Turn stays expanded and the folding control never appears — including the Turn that just finished at the tail. The fold gate reads the session-wide hasMore, while the risk it guards against only exists for the one Turn whose own start boundary is not loaded yet. The proposal below gates on the Turn itself, with a patch based on the current master.

What happens today

With the default Compact display, while older history is still loadable, reasoning rows, Context injection, Tool rows and earlier Assistant material stay expanded and no Turn-process control appears — for every Turn, including the one that just finished. Only after Load earlier has been clicked until history is exhausted does every eligible closed Turn collapse at once.

Reproduction

1. Open a Session whose log is longer than the first page — the client opens a Session with its last 50 messages (PAGE_MESSAGES = 50, packages/api/session-controller/src/client/sessions/session.ts), so most real Sessions qualify.
2. Send a prompt that produces reasoning or Tool calls.
3. Wait for turn/end: the process rows stay expanded and no folding control appears.
4. Click Load earlier until the button disappears: every eligible closed Turn collapses immediately.

Why some restriction is needed

When a Turn's own turn/start is outside the loaded window, processStartSeq falls back to the earliest loaded evidence (packages/client/ui-chat/src/client/conversation-nodes/turn-process.ts):

processStartSeq: turn.start?.seq ?? (Number.isFinite(externalProcessSeq) ? externalProcessSeq : answer.finalNode.seq),

Folding such a Turn is unsafe: paging an older page in widens that range and moves the control's anchor (controlAnchorSeq), so rows that just landed in the window would be hidden inside an already collapsed group — exactly the rows the reader paged up to read.

Proposal

Gate the fold on the Turn's own start boundary instead of the session-wide hasMore:

// packages/client/ui-chat/src/client/chat/ChatNodeSeat.tsx
const processWindowReady = processSpec !== undefined
  && processPresentation !== undefined
  && compactTranscript
  && processSpec.answerAnchorSeq !== null
  && processPresentation.turn === processSpec.turn
  && processPresentation.turnClosed
  && processPresentation.membersLoaded   // previously: && !historyIncomplete

membersLoaded is derived from the Turn's own boundary (packages/client/ui-chat/src/client/conversation-nodes/turn-process-presentation.ts):

membersLoaded: location.turn.start !== undefined

TurnLocation.start is undefined exactly when that Turn's turn/start event is outside the loaded window (packages/client/ui-conversation/src/client/contract/conversation.ts). Since the loaded window is one contiguous [head, tail] range, a Turn whose start is inside it has all of its process members already loaded — folding it can never hide rows that are still to be paged in.

Resulting behavior:

• every closed Turn with a loaded start folds immediately, no matter how much older history remains;
• only the Turn at the window head, whose start page is still paged out, keeps its process rows visible until that page arrives — the protection the session-wide gate provided, scoped to the Turn that actually needs it.

Patch (based on the current master)

The attached compact-fold-per-turn.patch is produced by git format-patch and targets the current master:

• Base commit: ddefc45fbc (2026-09-17, Merge pull request #4469 … release-dsh-0.1.6-alpha.2), the tip of master at version 0.1.6-alpha.2
• Patch commit: c8aad2f88d (2026-09-20)
• Size: 12 files, +125 / −24 — four production/contract files, two test files, the bilingual README and its pairing record, and the Agent Note triplet
• Apply with git am compact-fold-per-turn.patch (keeps the commit message) or git apply compact-fold-per-turn.patch; use git apply --3way if master has moved
• To run only the tests: pnpm vitest run packages/client/ui-chat

Evidence

• Component tests cover both directions (a closed Turn whose start is paged out stays visible; a closed Turn whose start is loaded folds while Load earlier still owns the head), and the fixture models TurnLocation.start: packages/client/ui-chat/tests/chat-view.client.spec.tsx, packages/client/ui-chat/tests/chat-snapshot-fixture.client.ts.
• packages/client/ui-chat suite: 358/358 passing.
• Verified by hand in the assembled Web GUI on a long Session.
  compact-fold-per-turn.patch

What I would like to know

1. Is the session-wide gate (hasMore) intended, or is the per-Turn turn/start boundary the rule you would want here?
2. If the rule should stay session-wide on purpose, what case does it protect that the per-Turn boundary does not?