混合代际会话（v0 header + v4 才有的 source.kind）在升级时被整份拒绝，建议改为逐条降级

[yuyulz]

环境：dsh 0.2.0-rc.2（Windows），从 0.1.1-rc.2 升级上来。

现象：升级后有一个老会话打不开。迁移链在
dsh-session-format-v2-to-v3/lib/index.js:123-125 的 assertSource() 抛
SessionFormatUnsupportedMigrationError: "cannot safely transform unclassified
message source"，整份迁移中止，该会话永久无法加载（日志内容完好、帧结构完整）。

根因：这份日志的 header 是 version 0（老代际），但里面混有若干条
source.kind="dsh-knowledge" —— 那是 dsh-knowledge 0.5.x 在 v4 下写的
"生产者自有 kind"（对 v4 合法），而 v2→v3 的 SOURCE_KINDS 白名单
（同文件 L14-30）里没有它。

建议：迁移器对"不认识的 source.kind"改成逐条降级（例如包一层
{kind:"plugin", plugin:<原 kind>}）并记 warning，而不是整份拒绝；
否则一条历史消息就让整个会话永久不可读。这也符合官方文档
2026-08-31-released-session-format-migrations.zh.md 里
"不可读子会话不再阻断健康父历史"的同一条原则。

补充（手工修复路径，供参考）：
把该 kind 改回 {kind:"plugin", plugin:"dsh-knowledge"}，并按原帧边界重压 ——
第一帧必须只装 header 一行，若把整个日志压成单帧会被判
"corrupt Zstandard session log: first frame is not exactly one header line"。

相关：dsh-knowledge 0.5.0 CHANGELOG 的 "use a producer-owned dsh-knowledge
source for auto-retrieval messages, avoiding DSH v4's rejection of legacy
plugin wrappers" 修好了 v4 侧，但老代际会话仍会被 v2→v3 白名单卡住。

[PerryLink]

定位对的，但你建议的降级形态恰好是 v4 现在拒绝的那一种，按它改会把"v2→v3 迁移中止"换成"v4 读不出来"。

白名单确实在源码里

packages/session/session-format-v2-to-v3/src/payload.ts:10：

const SOURCE_KINDS = new Set(['user', 'plugin', 'model', 'tool', 'agent-instructions', 'session-reference', 'team-message', 'goal', 'skill-invocation', 'skill-catalog', 'coordinator', 'subagent-report', 'subagent-settled', 'webhook', 'agent-message'])

15 个，确实没有 dsh-knowledge。判据在 :110-112，而它被 :81（user/message）、:82（assistant/message 与 tool/result）、:92（一批消息）分别调用 —— 所以一条历史消息就足以中止整份迁移，和你观察一致。

（你引的是 lib/index.js:14-30 / :123-125，那是构建产物；源码位置是上面这个 payload.ts。给维护者时引源码行号更稳。）

为什么"包一层 plugin"不行

v2→v3 的白名单里有 plugin，看起来正好是逃生口。但 v4 的准入把它退役了 —— packages/session/session-format-v3-to-v4/src/message-sources.ts:9：

if (!isSessionFormatJsonObject(value) || typeof value['kind'] !== 'string' || value['kind'].length === 0 || value['kind'] === 'plugin') {
  throw new SessionFormatError('format v4 message requires a producer-owned source kind')
}

判据只有三条：是对象、kind 是非空字符串、且不等于字面量 plugin。而 :1 的注释写明这是故意的："preserves unknown attribution and refuses retired plugin wrappers" —— 未知来源被保留，被拒的只是这个退役写法。

所以 {kind:"plugin", plugin:"dsh-knowledge"} 在 v3 侧能过、到 v4 侧会被同一类校验拒掉。你引的 dsh-knowledge CHANGELOG 那句其实已经在说这件事：它正是为了"avoiding DSH v4's rejection of legacy plugin wrappers"才改用 producer-owned kind 的。把老日志降级回 wrapper，等于把它退回那个已经被判定为不可读的形状。

更小也更一致的改法

不要降级，把白名单放宽。v4 的规则是"任意非空字符串，除了 plugin"；v2→v3 这份 15 项白名单才是异类。让 assertSource 与 v4 同构（非空字符串、不等于 plugin），dsh-knowledge 这类 producer-owned kind 就能原样穿过三代迁移，不需要任何重写、也不会产生新的不合规形状。

这样改还有两个附带好处：一是与你引的那份文档里"不可读子会话不再阻断健康父历史"的原则同向 —— 单条未知 kind 不再能否决整份 artifact；二是它把"哪些 kind 合法"收敛到一个规则上，而不是维护三份各自演进的名单。

一处残留风险要说清：'plugin' 之外是否还有别的 v3 时代写法会在 v4 被拒（比如带 plugin: 前缀的变体），我只能确认字面量 plugin 这一条。如果你的日志里还有别的老形态，建议在报告里把它们逐条列出来，否则放宽白名单后仍可能卡在下一道校验上。

[yuyulz]

感谢分享，确实有用。补一条：v4 对 plugin 分两条路——迁移路径 rewriteV3MessageSource（dsh-session-format-v3-to-v4/lib/index.js:115-120）遇到 plugin 会 rewritePluginSource() 改写后放行；原生准入 source()（同文件 :124-126）才直接拒。所以“包一层 plugin 到 v4 必死”严格说只在原生准入成立；但 v2→v3 的白名单是第一道闸，dsh-knowledge 在那儿就被拦下，走不到 v4 迁移，结论不变——放宽 v2→v3 白名单仍是唯一正确改法。

[yuyulz]

补一段同一个病在另一处的表现（原常用文件夹需要反复提权审批），供后来搜到这条讨论的人参考。
我这个「白名单太窄 ⇒ 一处不符就整份中止」的模式，在 DSH 0.2.0 的 Windows 沙箱里有一模一样的版本，只是换了层面：
表现：往工作区的子目录（_diag\、_备份\、工作流教学\ 等）写文件 → Access is denied，每次都要给一次性提权（danger-full-access）才能写。
根因：dsh-sandbox-windows-acl\lib\runner.js:144 —— workspace-write 模式下 writableDirs 只有工作区根目录这一个（0.1.1 是递归授权，0.2.0 收窄了）；而且沙箱子进程还跑在低完整性级别，只能写带低完整性标签的对象。
本质：和 SOURCE_KINDS 完全同构 —— 名单太窄 + 一项不符就整体失败。
但改法不能照搬：SOURCE_KINDS 是引擎源码，改 npm 包会被下次升级覆盖；沙箱这边可以不碰引擎就给目录补白名单：
bat
icacls <目录> /grant "username:(OI)(CI)F" /C /Qicacls <目录> /setintegritylevel "(OI)(CI)L" /C /Q
两步缺一不可：
只 grant 不给低完整性标签 ⇒ 低完整性子进程照样写不进；
只给标签不 grant ⇒ icacls 自己就 Access denied。
我把 7 个常用目录（_tmp／_diag／_备份／工作流教学／研究产物／交接／手册）各补了一遍，实测 7/7 不提权可写，一次投入之后再没提过权。代价是每个新目录要补一次（可以写进自己的初始化脚本）。
如果官方愿意从根上修，建议两条，第二条比第一条更根本：
1.writableDirs 恢复成递归，或至少默认包含「工作区子目录」；
2.把「白名单不匹配」从致命错误降级为警告/跳过 —— 这跟你说的「单条未知 kind 不该否决整份 artifact」是同一个哲学：一处不符 ≠ 整体不可用。现在这两处都是「一票否决」，用户看到的现象是「整个功能不可用」，而不是「有一个东西没处理」，排查成本极高。
另附一条源码勘误（如果对你有用）：v4 对 kind === "plugin" 其实分两条路 ——
迁移路径 rewriteV3MessageSource（dsh-session-format-v3-to-v4/lib/index.js:115-120）遇到 plugin 会 rewritePluginSource() 改写后放行；
原生准入 source()（同文件 :124-126，也就是你引的那段）才是直接拒。
所以「包一层 plugin 到 v4 必死」严格说只在原生准入成立。「但 v2→v3 的白名单是第一道闸，dsh-knowledge 在那儿就被拦下、走不到 v4 迁移」——这个结论不受影响，放宽 v2→v3 白名单仍是唯一正确改法。
★ 你说的残留风险我也记下了：plugin 之外是否还有别的 v3 时代写法会在 v4 被拒（如带 plugin: 前缀的变体），确实需要把日志里所有老形态逐条列出来才能排除。