0.1.2-rc.1 升级后无法选择工作空间/会话，回退 0.1.1-rc.2 恢复正常

[tsjbjgs]

现象

• 环境：macOS 15.7.9（Apple Silicon），node v24.15.0，npm 11.12.1
• 步骤：npm install -g @deepseek-ai/dsh@latest（解析到 0.1.2-rc.1）→ 重启 dsh web
• 结果：Web UI 无法选择工作空间 / 会话（历史会话列不出、选不中）
• 回退：npm install -g @deepseek-ai/dsh@0.1.1-rc.2 后完全恢复正常

环境

• DSH：0.1.1-rc.2（正常） vs 0.1.2-rc.1（异常）
• profile 插件：dshmarket@1.41.0、@anionex/dsh-vision-toolkit、@mlgbnb/dsh-archive-manager、dsh-better-sidebar@0.18.0

已做的隔离排查（未动真实数据）

1. 数据完好、格式兼容：workspace 域 version=2、session_projcache 域 version=3 与 0.1.1 完全一致；会话物理格式 SESSION_FORMAT_VERSION=0 未变，且 0.1.2 的 fromHeaderLine 对旧 header 做了兼容翻译 → 排除「数据/格式不兼容」。
2. 干净启动：用最小 profile 对着真实数据的副本启动，日志无报错、无崩溃 → 不是崩溃类问题，而是选择器读取路径的回归。
3. 会话读取路径在 0.1.1-rc.2 → 0.1.2-rc.1 之间有较大重构（正是工作空间/会话选择器取数的路径）：
   • 移除 SQLite 会话后端
   • Session.events → seq / eventAt() / snapshotEvents()（代码侧可见新增导出 SessionSeq、SessionLogOffset、decodeSeqRanges / encodeSeqRanges）
   • 新增 session 锁（同一 session 至多被一个进程持有）
   • header 语义 seedLength → isSeeded + inheritedEventCount
   • 工作空间选择器 dsh-client-ui-workspace 是纯客户端，通过 typed-RPC 从 dsh-api-session-controller / dsh-api-workspace-controller 取数

一个值得注意的点

@deepseek-ai/dsh@0.1.2-alpha.5 的依赖声明是 ^0.1.2-alpha.5，npm 会解析到满足范围的最新版 0.1.2-rc.1，因此会话/工作空间相关 bundle（dsh-session、dsh-workspace、dsh-session-persistence、dsh-session-persistence-jsonl、dsh-session-projection-cache、dsh-client-ui-workspace 等）实际装的是 0.1.2-rc.1——即 alpha.5 与 rc.1 在这条路径上是同一份代码。

期望 vs 实际

• 期望：升级后能正常列出并选择已有工作空间与历史会话
• 实际：选择器无法列出 / 无法选中

请教

1. 这是否是已知问题？有没有 workaround？
2. 目前 latest / next 都指向 0.1.2-rc.1（rc 预发布，且项目尚未发布正式稳定版），是否有推荐的稳定版本，或预计修复的版本？

[argszero]

Your isolation work is solid — data-compat excluded, crash excluded, so this is a reader/UI-path regression in the 0.1.2-rc.1 window. Two families in that window are directly relevant, and your report needs one more discriminating data point to pick between them.

Family A — stale-plugin / version-skew breakage against the rc.1 refactor (documented this week, #5846):
The rc.1 line removed Session.events (→ seq/eventAt()/snapshotEvents()), added session locks, and reworked the header semantics. #5846 showed the failure mode with an official hooks bridge: a bridge built against the pre-refactor host killed every tool call on live sessions (agent.session.events is not iterable), purely because the published artifact embedded the old shape. Your profile runs four web-mounted plugins (dshmarket 1.41.0, dsh-vision-toolkit, dsh-archive-manager, dsh-better-sidebar 0.18.0). dsh-better-sidebar in particular owns sidebar chrome around exactly the workspace/session list — if it (or dshmarket) touches removed APIs, the selector pane can fail to render rows while the host logs stay clean. This is the top suspect for "workspace selector can't list" given #5846 proved the same mechanism in the same window.

Family B — host-side cold-list/projection regression (#5843/#5857):
The cold listing path was rewritten (projectionsFor seeded short-circuit etc.). But that family drops projection columns / titles, not whole session rows — your symptom ("列不出 / 选不中" = rows absent) is more severe, so I'd only land here if Family A is ruled out.

The discriminating test: you said a minimal profile against a real-data copy showed no errors — but did historical sessions actually list in that run? That's the fork in the road:

1. Minimal profile + real data → sessions still fail to list = host-side reader regression; high value for maintainers, and I'll source-trace the list path (api-session-controller list → persistence read → typed RPC) against the rc.1 refactor.
2. Minimal profile lists fine, full profile fails = plugin interplay. Bisect the four plugins (start by disabling better-sidebar + dshmarket) and grab the browser console on the workspace pane — an error like session.events is not iterable or a failed typed-RPC call names the culprit immediately. Workaround = stay on 0.1.1-rc.2 (you're already there) or drop the offending plugin until its author ships a refactor-compatible build.

On your version question: correct — latest/next both resolve to 0.1.2-rc.1 (npm range ^0.1.2-alpha.5 pulls rc.1), and there is no stable release yet. For a production-ish setup the pragmatic choice is 0.1.1-rc.2 until the next alpha/rc lands, exactly because the rc.1 window has this cluster of refactor-adjacent regressions (#5843/#5857 cold-list, #5846 stale artifact, your selector report). If you get a clean Family-B repro (minimal profile + real data), that's the one the maintainers most need — please post the exact repro and I'll dig into the list path.

[tsjbjgs]

感谢定位，这个判别实验做完了，结论落在 Family A（插件偏斜）。

判别实验：最小 profile（仅 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app，不含任何第三方插件），对着真实数据副本（storages + sessions）启动 0.1.2-rc.1（由 @deepseek-ai/dsh@0.1.2-alpha.5 解析而来）。

结果：host 侧会话读取路径正常——

• 启动无报错、无崩溃；
• 启动后 session_projcache 里 16 个历史会话全部存在、标题逐一一致（0 缺失 / 0 新增 / 0 变化）。

这说明 host 侧冷列表/投影（Family B）没问题，问题出在真实环境里那 4 个第三方插件（dsh-better-sidebar、dshmarket、dsh-vision-toolkit、dsh-archive-manager）之一或多个，与 0.1.2-rc.1 的 Session.events 移除 / APIProxy → Remote 网关 重构不兼容——与你列的 #5846 同机制。

下一步我按你说的对 4 个插件做二分（先关 dsh-better-sidebar + dshmarket），拿到浏览器控制台的具体报错后再来更新。

[argszero]

That's exactly the discriminator result I was hoping for — Family A confirmed, host-side cold-list/projection path exonerated. Thanks for running it cleanly.

A note to make the bisect faster: with Session.events removal and the APIProxy → Remote gateway refactor both in the rc.1 window, the two error signatures to grep the browser console for are:

1. is not iterable / agent.session.events — the [Bug] Mounting dsh-hooks-claude-code paralyzes the host: every tool call dies with "agent.session.events is not iterable" #5846 shape (code touching the removed .events iterator);
2. any typed-RPC/gateway failure on the workspace/session list calls — the APIProxy→Remote shape (a plugin intercepting or proxying the old client API surface).

Both will surface as a failed render or a thrown error in the workspace pane's console rather than a host crash, since the host side is healthy (your 16/16 projection check proves it). When you find the culprit, the fix is its author rebuilding against rc.1 — and if the plugin is unmaintained, disabling that one row is the durable workaround. If any of the four turns out to be a maintained/notable plugin, posting which one + the exact error here gives its author a direct bug report with a known cause.