【缺陷】紧凑模式下，一轮中间面向用户的正文被并入「过程」折叠，只剩最后一段可见

[little3tar]

关联：#301（该折叠功能的原始诉求）、#6200 / #6250（同一功能的另外两个缺陷，讲的是折叠何时生效；本贴报告的是折叠边界选错）
相关：#4863（把 pre-result 行折成 work group；其"closing answer never folded"原则只覆盖了最后一段，未覆盖中间正文）

环境

• @deepseek-ai/dsh 0.1.5-rc.2（npm 全局安装，dsh web，Windows 11，Node v24.19.0）
• 设置：ui-chat.transcriptView 未显式配置 → 走默认 compact（紧凑）
• 客户端：DSH Web GUI（Chromium 内核浏览器）

现象

紧凑模式下，一轮结束后的折叠不只收走推理行与工具行，还会把同样面向用户的助手正文段落一并收进「过程」折叠行，只留本轮最后一段答复可见。

实际碰到的一轮结构（本贴的由来）：

助手正文A（完整的诊断结论 + 3 个可选处置）
  → ask_user_question（等待用户选择）
  → 用户回答
  → 助手正文B（"明白，那就……"收尾）
  → 轮次结束

轮次结束后，界面上只剩正文B；正文A——也就是这一轮里信息量最大的一段——被折进「过程」，需要手动展开折叠行或切到「轨迹」才能找回。

三个可感知的不一致：

1. 同一段正文，位置决定可见性：放在轮次末尾会保留，放在轮次中间（尤其隔着一次工具调用）就被折走。
2. 运行中可见、结束后消失：turnClosed 一置位，正文A 立刻被折走，没有任何提示。
3. 被折走的往往是最关键的信息：本例中被折走的正是"结论 + 待用户拍板的选项"，留下的收尾句几乎不含信息。

最小复现

1. 保持 ui-chat.transcriptView 为默认值（compact）。
2. 让 Agent 在一轮内输出两段正文，中间夹一次需要用户介入的工具调用（ask_user_question 最稳定；审批弹窗同理）。
3. 在提问环节停留时观察：正文A 完整可见（turnClosed 为假，尚未折叠）。
4. 回答后让 Agent 输出收尾正文，等轮次结束。
5. 观察：正文A 被并入「过程」折叠行，界面上只剩正文B。把「对话显示」切到「标准」后正文A 恢复可见——说明内容一直是完好的，只是被折叠边界吃掉了。

定位（0.1.5-rc.2 打包产物行号）

文件 @deepseek-ai/dsh-client-ui-chat/lib/client.js：

// L8170-8175 —— 默认即为紧凑，无需用户做任何设置
const TRANSCRIPT_VIEW_FIELD = "transcriptView";
const TRANSCRIPT_VIEW_MODES = ["normal", "compact"];
/** Default preserves the compact process disclosure introduced by Chat. */
const DEFAULT_TRANSCRIPT_VIEW_MODE = "compact";

// L6748-6754 —— 折叠锚点只看本轮"最后一个 step"
function isFinalAssistant(data) { return data?.finalNode !== void 0; }
function latestAnswer(turn) {
  const data = turn.steps.at(-1)?.data.get("assistant-step");
  if (!isFinalAssistant(data) || !hasAssistantReplyContent(data.blocks)) return null;
  return data.blocks.some((block) => block.kind === "tool-call") ? null : data;
}

// L6756-6785 —— 折叠上界 = 最后一段答复的起点；本轮其余部分全部落在下界与上界之间
const answer = latestAnswer(turn);
return {
  processStartSeq: turn.start?.seq ?? (…),
  answerAnchorSeq: answer.finalNode.seq,   // ← 折叠上界
  …
};

// L1555-1556 —— 折叠判定
const processWindowReady = … && compactTranscript && processSpec.answerAnchorSeq !== null
  && processPresentation.turn === processSpec.turn && processPresentation.turnClosed && !historyIncomplete;
const processMember = routedNode !== undefined && processWindowReady
  && !TURN_PROCESS_INDEPENDENT_KINDS.has(routedNode.kind)
  && routedNode.anchorSeq >= processSpec.processStartSeq
  && routedNode.anchorSeq <  processSpec.answerAnchorSeq;   // ← 纯正文段落同样满足

answerAnchorSeq 取的是最后一个"不含 tool-call 的 final assistant step" 的位置，因此它之前的所有节点——推理、工具调用，以及同样是面向用户正文的 step——都会被判为 processMember 折进「过程」。把上界收在"最后一段"而不是"最后一段面向用户的正文起点"，就是本贴的成因。

与 #6200 / #6250 的区别

	症状	根因
#6200	历史未加载完时，折叠完全不生效	!historyIncomplete 全局开关
#6250	刷新后折叠失效，跳转历史才恢复	同上
本贴	折叠生效，但边界把用户正文一起吃掉了	answerAnchorSeq = latestAnswer().finalNode.seq

期望行为（按侵入性递增，任选其一）

1. 最小改动：processMember 排除"面向用户的正文"节点——即只折推理行 / 工具行 / 其它过程行，任何 assistant 文本（hasAssistantReplyContent 的 text block）都留在可见区。这正是 Feature request: fold pre-result thinking/tool rows into a "work" group in the chat view #4863 的 "closing answer never folded" 原则的推广：不是"最后一个答案不折"，而是"答案都不折"。
2. 折中：若早先正文确实要收进过程，至少在折叠行上标明（例如「过程 · 含 2 段说明」）并提供一键展开，别让关键信息静默消失。
3. 交互边界视角：把"中途向用户提问/说明"视为答复边界——最近一次 ask_user_question / approval 之后的全部正文都保持可见。

补充

• 紧凑 / 标准切换位于「设置 → 通用 → 对话显示」（描述："控制已完成轮次的过程内容"），实测切到「标准」可恢复完整可见性，可作为本问题的即时规避。
• 若采纳方案 1，建议顺手把 historyIncomplete 对折叠的全局否决（【缺陷】会话历史分页未加载完时，已完成轮次的「过程折叠」被静默禁用 #6200 / Bug：compact 模式下刷新页面后会话折叠不生效，跳转到历史轮次后才恢复 #6250）一并处理，避免同一功能在两处各有一个"看起来像坏了"的入口。
• 需要会话日志、界面录屏或 DOM 片段的话我可以补。

[zhengmz]

开发了一个插件 https://github.com/zhengmz/dsh-auto-fold 补齐自动折叠能力，供参考

实现如果设置了 Compact 后，在切换对话时，会自动折叠回合。

[li7382917]

补充一个版本/现象：我这边的项目版本是 0.1.6-alpha.1，Web UI 也观察到面向用户的中文助手正文出现在「已思考」/过程折叠区域；收起后正文不可见。目前还不能确认是否必须经过 ask_user_question 或 approval 才会触发，因此不确定复现路径是否与本帖完全一致。

我对照了后续 dsh-v0.1.7-alpha.1 / alpha.2 的 UI 代码，看到 reasoning 与 response 已按 groupPart 分开处理。请问这是否就是本问题的修复？如果是，能否确认从哪个发布版本开始包含？

[linbark]

补充：在 @deepseek-ai/dsh@0.2.0-rc.2 / @deepseek-ai/dsh-client-ui-chat@0.2.0-rc.2 的 macOS Web UI、默认 Compact 模式下仍可复现。此次触发不需要 ask_user_question 或 approval，而是后台子智能体完成通知。

实际事件顺序（省略私人项目内容）

1. Agent 调用工具完成调查。
2. Step 23 写出完整的多节分析答复，不含 tool-call。
3. 子智能体完成通知在同一 Turn 到达。
4. Step 24 追加一条简短、无 tool-call 的收尾回复，例如“核查已完成，结论已纳入上述分析”。
5. Turn 结束后，默认界面只显示 Step 24；Step 23 的完整答复被归入“已完成，用时…”的折叠过程。

展开过程后，完整正文立即恢复。会话日志中两条 assistant/message 均为 surfaceOp: append，没有正文删除或替换。因此这是显示边界问题，而不是模型没生成内容。

定位与局部修复候选

packages/client/ui-chat/src/client/conversation-nodes/turn-process.ts 中 latestAnswer() 只检查 turn.steps.at(-1)。2026-10-08 获取的 master 源码仍使用这个判定。

针对本次“连续的末尾答复 + tool-free 收尾”场景，我们在本地安装产物验证了以下候选：向前扫描末尾连续、已完成、有可见答复且不含 tool-call 的 Assistant steps，以这段答复序列的第一步作为折叠上界。这样前面的正文和后续收尾都保留在可见区；遇到工具步骤、空答复或未完成步骤则停止，避免把更早的进度说明一起提到正文区。

function latestAnswer(turn: TurnLocation): Readonly<FinalAssistantChatData> | null {
  let answer: Readonly<FinalAssistantChatData> | null = null
  for (let index = turn.steps.length - 1; index >= 0; index -= 1) {
    const data: Readonly<AssistantChatData> | undefined =
      turn.steps[index].data.get('assistant-step')
    if (!isFinalAssistant(data)
      || !hasAssistantReplyContent(data.blocks)
      || data.blocks.some(block => block.kind === 'tool-call')) break
    answer = data
  }
  return answer
}

验证范围与限制

• 修改前，真实会话回放选中最后的收尾；修改后，边界回到前一条完整正文。
• 刷新原 Web 会话后，过程保持折叠，完整分析与收尾均直接可见。
• 从实际安装产物提取 latestAnswer() 执行了该真实日志模式，以及五个边界检查：单条答复；工具步骤之后的连续答复；末尾工具步骤；未完成步骤；空 Turn。均通过。
• 这是安装产物上的本地验证，尚未运行上游完整构建或测试套件。该候选没有解决“正文与收尾之间还有工具调用”的更广泛 【缺陷】紧凑模式下，一轮中间面向用户的正文被并入「过程」折叠，只剩最后一段可见 #6254 场景，也没有解决 [Bug] compact latestAnswer: empty last step (plugin same-turn steer) folds the real answer into 用时 and leaves a blank transcript #8002 的空/工具尾步骤；这两类仍需另外定义边界语义。

建议至少增加“完整正文之后，后台子智能体通知触发无工具的收尾步骤”的回归用例。遵循当前 CONTRIBUTING 中的反馈渠道，在此补充证据和修复候选，未提交外部 PR。