[0.1.2-rc.1][Web] 压缩后的会话：轨迹导航已归档轮次不可点击；最早用户消息回放丢失（request-prompt withdrew materialized target chat）

[bb6894]

环境

• dsh 0.1.2-rc.1（npm @deepseek-ai/dsh），web profile
• Node v25.2.1 / Windows 11 (10.0.22631) / Chromium 152
• 自定义 agent preset（改编自 standard：compaction-basic + tool-result-pruner 已启用，patchReload: live）
• 会话规模：7 轮 · 48 步，累计输入 ~7.5M tokens（cache hit 72%），期间已发生多次上下文压缩

现象 1：轨迹导航中"已归档轮次"的标记无法点击加载

轨迹页的轮次导航中，已归档的第 1 轮标记按钮（aria-label="加载并跳转到第 1 轮"，class eGxaPq_mark eGxaPq_markUnloaded）无法激活：

• DevTools 显示点击被 <div class="eGxaPq_markPosition"> 拦截（装饰层覆盖在按钮上方吃掉 pointer events，真人点击同样无效）
• 键盘激活（focus + Enter）也不触发加载，class 始终保持 markUnloaded markPreview
• 其他已加载轮次（"跳转到第 N 轮"）工作正常

期望：归档轮次可以加载并回看（包括最早的用户消息）。

现象 2：压缩后的会话回放丢失最早的用户消息，控制台报错

对话视图从第 2 条用户消息开始渲染，第 1 轮的最早用户消息不显示。页面加载时控制台报错：

[session-controller] event feed subscriber failed: Error: conversation
Definition "request-prompt" withdrew materialized target "chat"; return the
same key with hidden visibility instead
    at ConversationNodeAssembler.buildTargetUpserts (…cordis-client-runner…)
    at BoundConversation.publish / accept …

推测：compaction 收回了第一条 request-prompt 的会话目标（"chat"），客户端事件回放对"已物化目标被收回"这种情况没有按提示要求的 hidden visibility 方式处理，导致该条目从渲染中消失。

相关（可能独立）的第三方插件崩溃

同一会话页面加载时，dsh-hud 插件在 conversation.composer.dock 槽位崩溃（供参考，非核心诉求）：

slot entry crashed in 'conversation.composer.dock': TypeError: Cannot read
properties of undefined (reading 'values') at latestTurnStart

期望

1. 轨迹导航中归档轮次可点击加载回看；
2. 压缩后的会话在对话视图中能保留（或明确以摘要形式展示）早期消息；事件回放对 withdrawn target 容错，不丢失后续渲染。

复现

web 长会话累计输入到数百万 token、触发多次 compaction 后，重新打开该会话即可稳定复现以上两点（浏览器控制台报错如上，确定可复现）。

相关但不同的话题：#5020（compact 输出上限导致压缩失败）、#2582（轨迹 event-id 稳定性提议）。

如需更多日志或复现细节可以在此讨论，谢谢！

[rootkiller6788]

我对照 0.1.2-rc.1 的源码并和 main 比对后，倾向认为两个现象是同一个上游 bug 的两面，main 上目前未修。

现象 2 的报错是组装器里主动抛出的契约：definition 一旦给会话渲染过节点，重建同一 context 时必须继续返回节点，返回空就直接丢弃整次 publish。request-prompt 恰好会"反悔"——它按当前请求与前一条请求提示词的对比，决定要不要显示系统提示；压缩改写更早的请求历史后，一条已显示的提示词被重放、被重新判定为不显示，于是返回空，整批节点（含最早那条用户消息）没能落地。错误信息本身写明了修法：改为 hidden visibility 保留节点而非返回空。这条契约在 main 上与 rc.1 完全一致，属定义层的 bug，客户端无法容错，建议按此向上游报。

现象 1 里圆点按钮本就设了 pointer-events:none，点击由整条轨道列接管，所以"被遮挡"并非主因；归档轮次需要先翻更早历史再跳转，走的恰是现象 2 那条会被抛断的路径，翻页失败即表现为静默无响应。若能确认点击瞬间控制台复现同一报错，即可坐实二者同源。