[Bug] 已完成轮次的过程折叠会吞掉「工具调用前的正文」——整轮折叠忽略分组已切出的 response 部分（0.2.0-rc.2 / 0.2.1-alpha.2）

[moekyo]

TL;DR (EN) — Whole-Turn process folding hides an Assistant reply that appears before a tool call. The process grouping already lifts groupPart: "response" out of the process group as an independent root, but the fold's processMember test still treats it as process material, and the only groupPart exemption is granted to answerStep. So a turn whose first step is [reasoning, text, tool-call] loses that opening text when the turn collapses. Reproduces on 0.2.0-rc.2 and is unchanged in 0.2.1-alpha.2.

摘要

一个已完成的轮次里，如果模型在调用工具之前先输出一段正文，收起抬头「已完成，用时 N 秒」后，这段正文会整条消失，展开才可见。可见回答于是从半句话开始，读起来像被砍了头。

本机实测的那一轮：

• step 1 = [reasoning, text("明白，我一路做到完，不再中途问你。先立个目标把这件事绑住（避免半路停下）："), tool-call(create_goal)]
• step 2 = [reasoning, text("目标已立（上限 6 轮…）…")] ← 最终答案
• 轮次结束后：step 2 的正文可见；step 1 的正文被折叠吞掉。

流式期间看不到这个问题：轮次未关闭时 liveProcess / alwaysOpen 为真，整轮控件强制展开；turn/end 之后折叠才生效——所以现象只在「完成输出之后」出现，用户会以为模型漏答了开场。

环境

• @deepseek-ai/dsh@0.2.0-rc.2（当前 latest），Web GUI
• 在 @deepseek-ai/dsh-client-ui-chat@0.2.1-alpha.2 复核：判定逻辑相同，因此不是已修问题
• 工作步骤展示：compact / standard / detailed 均可复现（foldCompletedTurns: true）；verbose 不折叠，不复现

代码定位

本机只有发布包、没有源码仓库；下面的 region 名取自 bundle 内的构建注释，源码路径按 region 命名推断（如有出入请以实际文件为准）。

切分侧（region lib/types/client/conversation-nodes/process-groups.js，推断源码 packages/client/ui-chat/src/client/conversation-nodes/process-groups.ts）在 rebuild() 里已经明确区分两部分——推理进过程组，正文作为过程组之外的独立根节点：

else if (node.kind === "assistant-step") {
  if (reasoning(node)) pending.push({ kind: "node", key, groupPart: "reasoning" });        // 推理 → 过程组成员
  if (reply(node)) { flush(true); emit(key, { kind: "node", key, groupPart: "response" }); } // 正文 → 过程组外的根节点
}

折叠侧（region lib/types/client/chat/ChatNodeSeat.js，推断源码 packages/client/ui-chat/src/client/chat/ChatNodeSeat.tsx）的整轮成员判定只看锚点窗口，唯一照顾 groupPart 的豁免只给「最终答案那一步」：

const processMember = routedNode !== void 0 && processWindowReady
  && !TURN_PROCESS_INDEPENDENT_KINDS.has(routedNode.kind)
  && routedNode.anchorSeq >= processSpec.processStartSeq
  && (liveProcess
      || processSpec.answerAnchorSeq === null
      || routedNode.anchorSeq < processSpec.answerAnchorSeq
      || groupPart === "reasoning" && routedNode.kind === "assistant-step" && routedNode.data.step === processSpec.answerStep);
// …
const processHidden = controllerInactive || foldable && processMember && !processOpen; // 直接 hidden

于是出现内部矛盾：同一个 assistant-step 节点，切分器判定「正文不属于过程」，折叠器判定「属于过程」，并且只有 answerStep 享受 groupPart 豁免。只要轮次里存在「工具调用前的正文」，它就会连同 reasoning、工具行一起被隐藏。

answerAnchorSeq 来自 region lib/types/client/conversation-nodes/turn-process.js 的 latestAnswer()：只承认最后一步、不含 tool-call、且有正文的那一步。TurnProcessSpec.messageCount 的注释本身就写着 "Reply-bearing durable Assistant messages before the final answer"——这些正文被计入过程窗口，但它们在 UI 上属于回复而不是过程。

期望行为

1. groupPart === "response" 的 assistant 位置永远不应成为过程成员；可折叠的应只有 reasoning 部分与工具/过程行。这样「隐藏思考」的心智模型成立，正文在任何模式下都完整。
2. 建议改法（一行守卫）：

const processMember = routedNode !== void 0 && processWindowReady
  && !TURN_PROCESS_INDEPENDENT_KINDS.has(routedNode.kind)
  && !(groupPart === "response" && routedNode.kind === "assistant-step")   // ← 新增
  && routedNode.anchorSeq >= processSpec.processStartSeq
  && (…原条件不变…);

3. 加固（可选）：抬头目前只渲染 label + duration，messageCount 仅作为 data-turn-process-messages 存在。让它显示「· 已折叠 N 条过程消息」，可以避免任何内容无声消失。

备注

• packages/client/ui-chat/README.md#turn-process-folding 的措辞是「收起符合条件的已完成轮次，不隐藏最终答案」。按最小契约只有最终答案被保证可见，所以这可以被读成「设计如此」；但分组侧已经切出 response 这一事实说明实现内部并不认为正文属于过程——把两者对齐，比收缩文档承诺更接近本意。
• 0.2.1-alpha.2 新增了 data-turn-process-member 属性，看起来成员判定近期正在被调试，但规则未变。
• 影响面：这不是罕见边界。模型「先回一句 → 调工具 → 继续说完」是常态，用户会看不到自己已经收到过的开场句，尤其在 goal / 多步执行轮次里很容易误判为漏答。

[PerryLink]

你的定位全对，而且你能只凭 bundle 就推断出 region 对应的源码路径，相当准。我把你没拿到的那部分补齐：准确文件与行号、以及一条会拦住你那个一行修法的既有测试（这条最关键 —— 你没有源码仓库，看不到它）。

1. 你推断的源码路径全部命中

你的推断	实际位置（origin/master = d743267388 = dsh-v0.2.1-alpha.2）
packages/client/ui-chat/src/client/conversation-nodes/process-groups.ts	✅ :172 groupPart: 'reasoning' / :175 groupPart: 'response'
packages/client/ui-chat/src/client/chat/ChatNodeSeat.tsx	✅ processMember 在 :77-82；:109 `const processHidden = controllerInactive
packages/client/ui-chat/src/client/conversation-nodes/turn-process.ts	✅ :117 function latestAnswer(...)；:163 answerAnchorSeq: answer.finalNode.seq
packages/client/ui-chat/README.md#turn-process-folding	✅ 该节存在

你引的那段 processMember 与 :82 那条唯一的 groupPart 豁免，在 ChatNodeSeat.tsx:77-82 上逐字一致。

2. 你说的"内部矛盾"确实存在 —— 而且 :82 就是作者本意的证据

:82 的第四个析取项：

|| (groupPart === 'reasoning' && routedNode.kind === 'assistant-step' && routedNode.data.step === processSpec.answerStep)

它专门为 reasoning 渲染在 answerStep 上开口子。⇒ 作者要的是「reasoning 进折叠、response 不进」。缺口只是第三个析取项（routedNode.anchorSeq < processSpec.answerAnchorSeq）没有把 response 那一半排除掉。你的读法（分组侧已切出 response，折叠侧却仍当它是过程材料）完全正确。

3. ⭐ 你没看到的关键：测试套件对正文的可见性完全没有断言

packages/client/ui-chat/tests/chat-view.client.spec.tsx:2363：

it('folds Think and Tool rows before the final answer without unmounting them', () => {

夹具在 :2364-2370 —— 正是同一种形状（同一步里 reasoning + text，且早于最终答案；差别只是这一步没有 tool-call）：

const first = {
  ...assistant(2, 'earlier reply', 1, 1),
  blocks: [
    { kind: 'reasoning' as const, text: 'inspect the repository' },
    { kind: 'text' as const, text: 'earlier reply' },
  ],
}

断言（:2389-2400）：

• :2389-2390 → [data-turn-process-member] 共 3 个
• :2391-2392 → 三个 member 全部 hidden='until-found'
• :2393 → expect(members[0]?.textContent).toContain('inspect the repository')
• :2394-2395 → members[1] 含 'bash:a'、members[2] 含 'subagent:b'
• :2396 → expect(view.getByText('final answer')).toBeTruthy()
• :2398-2400 → 展开后三个 member 的 hidden 全部变 null

⚠️ 请注意这里的精确事实（我第一遍读快了，更正一下）：三个 member 是 [reasoning 成员, bash:a, subagent:b] —— 'earlier reply' 根本不在 member 集合里（它对该节点的 textContent 只在 :2393 被间接带过，而且查的是 reasoning 那一份）。也就是说：

这条测试既没有断言正文可见、也没有断言正文被隐藏。它对「正文去哪了」是空白的 —— 这正是这个 bug 能长期存在的原因。

⇒ 对你 PR 的实际影响（与我上一版说法不同，请以这版为准）：

1. 不能指望这条测试会拦住你，所以它也不会因为你的补丁变红 —— 但反过来说，你的 PR 必须自己新增一条断言（对 groupPart === 'response' 的那份正文断言其可见），否则这个缺陷在测试层面依然无保护；
2. 必须保持 :2391-2392 的现状：三个 member 全 until-found 是正确的（reasoning 与工具行就该折叠）⇒ 你的守卫不能把 reasoning 成员放出来，否则这条才真的会红。

4. ⭐ 仓库自己带一条反向断言，能把你的诉求从"期望之争"变成"现状违约"

chat-view.client.spec.tsx:3069：

expect(view.getByText('final answer').closest('[hidden]')).toBeNull()

⇒ 「最终回答的祖先里不能有 [hidden]」是被测试写下来的契约。

⭐ 而且这个断言形态在整个文件里出现 21 次（git grep -c "closest('\[hidden\]')" …chat-view.client.spec.tsx → 21）—— 也就是说这不是随手一条，而是一条成体系的可见性契约：回答不能被折叠藏住。

缺口正如下：这 21 条全都只针对 'final answer'，没有一条针对"轮次中较早的正文"。你备注里那句担心很对（README 的措辞只保证"不隐藏最终答案"，可以被读成"设计如此"）—— 这 21 条断言正好补上那个缺口：

折叠已经为"回答必须可见"建立了成体系的可验收契约，而它的实现只对最后一步兑现了这条契约；同一步里 groupPart === 'response' 的那份正文同样是回答，却被当成过程材料。

把它放在报告最前面，你的诉求就不再是"我希望正文可见"，而是"实现没有把它自己已经建立的契约贯彻到所有回答上"。

5. 你的版本观察我复核了

你写"0.2.0-rc.2 复现；在 0.2.1-alpha.2 的 dsh-client-ui-chat 上复核判定逻辑相同"。我对着 origin/master 核了：ChatNodeSeat.tsx:77-109、turn-process.ts:117/163、process-groups.ts:172/175 都未改动 ⇒ 你的结论对最新线成立，不是已修问题。

你注意到的 0.2.1-alpha.2 新增 data-turn-process-member 也对得上：成员判定近期确实在被观测（那条属性正是给测试/诊断用的），但规则没变。

6. 关于你的第 3 条建议（加固抬头）

我支持，但建议降为可选：抬头显示"· 已折叠 N 条过程消息"能避免"无声消失"，但它不修复"正文被折叠"，只是让消失变得可察。⇒ 把它与第 1 条分开提（一条是缺陷，一条是改进），否则维护者可能只采纳容易的那条，而正文仍然被藏。

7. 补充一条影响面证据（你可以直接引）

TurnProcessSpec.messageCount 的语义就是 Reply-bearing durable Assistant messages before the final answer —— 也就是说这些正文被计入过程窗口，但在语义上它们是"回复"。这从命名层面印证了你的判断：计数把它当过程，UI 把它当回复。

8. 边界

我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2）。你那份现场跑在 0.2.0-rc.2，而上面第 1、3、4 节的行号是 master 源码行 —— 引用时请标明基准（bundle 行号与源码行号不同，你已经做对了这一点）。