[Bug] 项目目录迁移后 dsh 启动崩溃（corrupt session log），希望支持会话重新归属

[Gaaahao]

环境

• 系统：Windows 11
• Node：v25.2.1
• 版本：0.1.0-rc.5（master 源码运行，pnpm dsh web）

问题描述

我把一个项目目录从 E:\Users\<用户名>\Desktop\<项目> 迁移到了 E:\Code\Agent\<项目>。dsh 里没有把旧分区的会话迁移到新分区的功能，我又不想丢掉里面的会话记录，于是手动把 C:\Users\<用户名>\.dsh\sessions 下旧分区目录里的会话文件夹移动到了新分区目录。

结果 dsh web 每次启动都会直接崩溃：

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include):
failed to apply loader entry workspace (@deepseek-ai/dsh-workspace): corrupt session log
"C:\Users\<用户名>\.dsh\sessions\--E-Code-Agent-~91CF~5316~5065~8EAB--\session-xxx\session.jsonl.zstd":
header id "session-xxx" and cwd identify
"C:\Users\<用户名>\.dsh\sessions\--E-Users-<用户名>-Desktop-~91CF~5316~5065~8EAB--\session-xxx\session.jsonl.zstd"

排查结论

崩溃来自 packages/session/session-persistence-jsonl 的 assertStoredIdentity：
会话文件头里记录的 cwd 必须与文件实际所在的存储目录一致，否则整个启动失败。
分区目录名由 projectKey(cwd) 编码生成，文件头才是会话归属的唯一事实来源，
所以手动移动会话文件夹后身份校验必然失败。

另外这个校验是在启动时全量扫描会话库执行的，只要有一个会话损坏，整个 dsh 就起不来，没有跳过/隔离机制。

临时解决办法

我把每个 session.jsonl.zstd 首帧里的 header 行 cwd 改写为新路径后恢复了正常，
会话在新分区下完整可见。但普通用户不太可能自己做到这一步。

希望改进

1. 项目路径变更时提供官方的会话迁移 / 重新归属功能（例如给分区提供"更改路径"操作）
2. 个别会话损坏时启动不应整体崩溃，建议跳过或隔离，并在 UI 中提示用户处理

[PerryLink]

你的排查结论完全正确，我把关键代码位置补上，并说明这条校验目前在启动路径上的行为。

1. 校验本身

packages/session/session-persistence-jsonl/src/index.ts:1514   private async assertStoredIdentity(path, storedVersion, meta, expectedId?, signal?)
:1522   if (expectedId !== undefined && meta.id !== expectedId) throw new Error(`corrupt session log "${path}": requested id … does not match header id …`)
:1527   expectedPath = generationLogPath(this.root, meta.cwd, meta.id, storedVersion, this.compression)

被调用于打开日志的两处（:803、:1132）。所以你的判断准确：存储路径是由 header 里的 cwd 推导出来的（generationLogPath(root, meta.cwd, meta.id, …)），header 才是归属的唯一事实来源；手动搬动目录后，路径与 header 必然不一致 —— 这不是"文件坏了"，而是"文件不在 header 说的位置上"。

2. "一个坏会话拖垮整个启动"这件事，已经动过一半

当前树里有一条隔离行为：

packages/session/session-persistence-jsonl/tests/catalog-migration.spec.ts:138
  it('isolates a corrupt child catalog and reports its path', …)

⇒ 至少目录/子目录目录（catalog）层面已经会隔离并报出路径。但你遇到的是工作区会话扫描路径（报错来自 dsh-workspace 这个插件的激活），我没有核实那条路径现在是否也做了同样的隔离 —— 这是你这条报告里最值得上游回答的一问：隔离是否已覆盖 workspace 启动扫描；如果还没有，那就是同一条原则只落了一半。

3. 你的两条诉求我建议这样提

1. 「更改路径 / 重新归属」：现在可行的口径是让会话重新指向一个新的 cwd（等价于你手工改写 header 的 cwd）。把它做成一个操作，而不是让用户去改 zstd 首帧。
2. 「坏会话不得阻断启动」：把上面那条 catalog 隔离的原则扩展到工作区扫描：跳过并记录（最好在 UI 里给出可处理的提示），而不是让 plugin tree failed to load。你原文里"只要有一个会话损坏，整个 dsh 就起不来，没有跳过/隔离机制"这句，是这条报告最有价值的一句。

顺带一句：你已经找到的手工解法（改写首帧 header 的 cwd）仍然是当前唯一可行的办法 —— 我没有看到任何把"迁移后的会话"自动认领回来的路径。

边界：读的是 00102833df（dsh-v0.1.7-alpha.2）的提交树；你报的是 0.1.0-rc.5。这两个版本之间会话持久化改过（有 v2→v3 的迁移测试），所以我引用的行号在你的版本上不成立，字段名（assertStoredIdentity、generationLogPath）可以用来在你的版本里定位。我没有复现你的崩溃。