[Bug] 0.2.0-rc.2 无法读取 0.1.x 历史会话：冻结 v0 清单漏声明 permission/preset.origin，整份会话被拒

[peng-shao-stay]

0.2.0-rc.2 无法读取 0.1.x 历史会话：v0 迁移器漏声明 origin，整份会话被拒。

实测 10/11 会话受影响，无官方绕过方式。

复现、根因、修复与验收

影响面

从 0.1.x 升级上来的用户，凡 delegationDepth=0 的顶层会话全部无法加载（实测 10/11 受影响，剩余 1 个是子会话，本身不写该事件）。必须改 node_modules 才能绕过。

复现步骤

1. 用 0.1.x（如 dsh-v0.1.1-rc.1）正常使用，产生若干会话
2. 升级到 0.2.0-rc.2（npm i @deepseek-ai/dsh@0.2.0-rc.2 --ignore-scripts）
3. 启动后打开任意历史会话

实际结果

会话加载失败，报错：

failed to observe session "session-<id>":
@deepseek-ai/dsh-session-format-v0-to-v1 refuses this format v0 Session:
permission/preset 0 data has unexpected member "origin";
source v0 artifact remains unchanged

报错事件位于 seq 0，即会话第一条事件，直接中断整份 artifact。

根因

写入方与校验方的声明不一致。

写入方（0.1.x）明确声明 origin 合法 —— packages/interaction/permission-presets/src/index.ts:53：

'permission/preset': { preset: string; origin?: 'default' | 'selection' | 'inferred' }

该文件 439 / 465 / 478 三处 session.append('permission/preset', ...) 均写入 origin，默认值 'default'。

校验方（0.2.0）漏声明 —— packages/session/session-format-v0-to-v1/lib/index.js:119：

"permission/preset": disposition(["preset"]),   // optional 列表为空

disposition(required, optional, opaque) 本身支持声明可选成员与 opaque 成员，但该条目两处都未声明 origin。

校验函数 assertReleasedV0Keys（同文件 257-263 行）是封闭式校验：

const allowed = new Set([...required, ...optional]);
const unexpected = Object.keys(record).find((key) => !allowed.has(key));
if (unexpected !== void 0) throw new SessionFormatError(...);

为什么影响这么大

1. permission/preset 只写在顶层会话上（子会话实测 0 条该事件），因此凡 delegationDepth=0 必中
2. 0.1.1 三处写入点全部带 origin，且默认 'default'
3. 事件落在 seq 0，第一时间中断
4. 失败粒度是整份 artifact，不是单条事件 —— 一个字段导致全部历史不可读

一处值得注意的设计意图反转

0.1.1 源码注释（permission-presets/src/index.ts:49-51）说明：

origin is optional so logs written before origin tracking remain readable but are never mistaken for refreshable defaults.

即：把 origin 设为可选，目的正是让 origin 追踪功能上线前写入的日志保持可读。0.1.x 为向后兼容做的设计，0.2.0 恰好在读取这批日志时失败。

已验证的修复

单行改动即可：

- "permission/preset": disposition(["preset"]),
+ "permission/preset": disposition(["preset"], ["origin"]),

只需改 dsh-session-format-v0-to-v1 一处：v1->v2 的表由 v0 表派生（retained = Object.fromEntries(Object.entries(RELEASED_V0_EVENT_DISPOSITIONS)...)，session-format-v1-to-v2/lib/index.js:6），v2->v3 再引用 v1->v2 的表，补丁沿迁移链自动传播到 v4。

实测（全链路 createRestore(header, {recovery:'strict', validation:'current'}) + V3→V4 子会话证据）：

	通过	失败
修复前	0 / 11	11
修复后	10 / 11	1（另一问题，见下）

同类问题：subagent/descriptor v2 同样被拒

同一批次还有一个性质相同的问题。子会话报：

subagent/descriptor 0 uses unsupported descriptor version 2

• 0.1.x 写入 v2：packages/subagent/subagent/src/descriptor.ts:47 → SUBAGENT_DESCRIPTOR_VERSION = 2
• 0.2.0 只认 v3：dsh-subagent/lib/index.js:1309 → = 3，且 1368 行 if (version !== 3) return void 0
• 迁移器两处硬编码拒绝：session-format-v0-to-v1/lib/index.js:1584（data["version"] !== 3 抛错）、:1290（literalValue(data["version"], [3], ...)）

与 origin 的区别：origin 是漏声明，一行可修；descriptor 是主动弃用，需同时改两处并确认 v2 载荷能过 continuable 分支校验。

缓解情况：读取子会话失败会被降级处理（dsh-session-persistence-jsonl/lib/index.js:2226-2234 推入 descriptor:null 的 unavailable 证据；dsh-session-format-v3-to-v4/lib/index.js:1534 的 const entry = fact ?? {version:1, ..., mode:"unknown"}），父会话仍能加载，子会话 catalog 记为 mode:"unknown"。

环境

• dsh：0.2.0-rc.2（0.2.1-alpha.2 复测同样存在，未修复）
• 来源版本：dsh-v0.1.1-rc.1
• OS：Windows 11
• Node：v22.22.2 / v24.18.0 均可复现
• 会话存储：~/.dsh/sessions/<project>/<session-id>/session.jsonl.zstd（多帧 zstd，逐行一帧）

为什么可能没被测出来

v0 编解码器是 0.2.0 新增代码。若测试夹具由同一份清单（或同一套代码）生成，测试会自洽通过，但与真实 0.1.x 产物不符。建议在 CI 中加入由 0.1.x 真实导出的 session 样本做回归。

验收条件

• 0.1.x 会话（含 permission/preset 带 origin）在 0.2.x 下可正常加载
• 顶层会话与 subagent 子会话均可加载，子会话 catalog 应还原为真实 mode 而非 unknown
• 新增回归夹具：一份由 0.1.1 真实导出的会话样本

---

说明：本报告基于真实升级场景定位，含源码行号与可复现的会话产物。相关讨论：#9264（pre-V4 会话性能）、#9319（会话迁移）。

[argszero]

I can confirm this from source on the current tip, and confirm the part that makes the fix one line.

Still present at 5badb15009 (release-dsh-0.2.1-alpha.1). The frozen v0 inventory is packages/session/session-format-v0-to-v1/src/dispositions.ts:76:

'permission/preset': disposition(['preset']),

while the members around it that gained optional fields do declare them — 'sandbox/mode': disposition(['mode'], ['source']), 'request/context': disposition(['provider', 'model'], ['contextWindow']), 'llm/retry': disposition([...], ['maxRetries']). So this is one entry that missed an optional member, not a table that does not do optional members. The closed-set check you located is the one driven by that entry (assertReleasedV0Keys(record, required, optional, label), payload-validation.ts:305), and the per-type validation at payload-validation.ts:149 reads preset and nothing else, so admitting origin is the whole of the v0 side.

Your derivation claim holds, and the blast radius is a little wider than the report implies. session-format-v1-to-v2/src/dispositions.ts builds its table as ...retained from RELEASED_V0_EVENT_DISPOSITIONS, filtering out only assistant/chunk, assistant/message, session-log-deepseek/delivery-accepted and session/end-seed — and permission/preset is not one of the four. v2→v3 and v3→v4 reference that table again. So the omission is not a v0 defect that leaks forward; it is a single entry in the v0 table that all four released generations inherit, which is why one line repairs all of them and also why the failure reaches sessions that were never anywhere near a v0 writer.

One thing worth adding to the write-up: at the tip, the writer no longer writes origin at all. packages/interaction/permission-presets/src/index.ts:59 now declares 'permission/preset': { preset: string }, and the three append sites (:416, :440, :448) pass { preset: name } alone. That is consistent with your reading of the 0.1.x comment — the field was introduced with tracking and later dropped — but it changes what the frozen table is for here: it is now the only place where a member that real released v0 artifacts carry is still admissible. A generation that stops writing a member cannot stop the member existing in the artifacts it already wrote, and the frozen inventory is the record of what exists on disk, not of what the current writer emits.

On "why it wasn't tested": I think your diagnosis of the mechanism is right and it is worth stating as a general rule. This package's fixtures are built from the same inventory it validates against, so the suite is self-consistent by construction and green for any entry in the table — the table's correctness is the one thing the suite structurally cannot check, because the table is both the input and the expectation. A fixture exported by the released writer is the only artifact that can disagree with it. That is also the argument for the acceptance item you listed; it is the difference between testing the parser and testing the inventory.

On the second half of your report — I would keep it as a separate item. subagent/descriptor v2 being refused is a different animal from origin, and your own phrasing already draws the line: origin is an admitted-member omission, while the descriptor is an active deprecation with a version constant moved from 2 to 3 and two hard-coded [3] checks. The origin bug is repaired by widening one frozen inventory so released bytes stay readable; the descriptor question is whether a released generation stays readable at all, which is a policy decision about the migration's obligations rather than a missing member. Both are worth fixing, but a single "v0 migration is too strict" item would lose the distinction — and the degradation path you measured (parent loads, child catalog records mode: "unknown") is the piece of information that makes them weigh differently.

[argszero]

Two tag-level checks on your second half, because the answer changes the category it belongs to.

subagent/descriptor v2 is released data, not a development-build value. SUBAGENT_DESCRIPTOR_VERSION per tag, read from packages/subagent/subagent/src/descriptor.ts:

tag	value
dsh-v0.1.0-rc.7	2
dsh-v0.1.0-rc.8	2
dsh-v0.1.1-rc.1	2
dsh-v0.1.1-rc.2	2
dsh-v0.1.2-alpha.1	3

So v2 was written by every shipped build of the 0.1.0-rc.7 → 0.1.1-rc.2 span, and 0.1.2 is the first line that moved to 3. That puts it in the same category as origin — bytes a released writer produced, which a frozen reader now refuses — rather than in the "value that only ever existed in a development build" category, where refusal is correct. What differs between the two halves is only the cost of the repair (one inventory entry versus the version constant plus two [3] checks) and whether the payload still satisfies the current branch's validation, not whether the artifacts deserve to be readable.

And the origin population is narrower than "0.1.x", which matters for the fixture. Reading packages/interaction/permission-presets/src/index.ts at each tag: dsh-v0.1.0-rc.8 declares 'permission/preset': { preset: string } and appends { preset: name }; dsh-v0.1.1-rc.1 declares { preset: string; origin?: 'default' | 'selection' | 'inferred' } (line 53, as you quoted) and writes it; dsh-v0.1.1-rc.2 is back to { preset: string } and appends { preset: name }. The field's lifetime is that window, so the artifacts that need the widened inventory come from builds inside it — a fixture exported from a build outside it will be green whether or not the entry is fixed, which is a second way the regression can pass while the bug stands. Your own source version being dsh-v0.1.1-rc.1 is consistent with 10/11 sessions carrying it.

[xiaoshenming]

补一条和你们上面「必须改 node_modules 才能绕过」有关的：已经写坏的工件可以离线修，不用动装树。

这个形状（permission/preset 带 origin）我们的健康码是 v0-preset-extra-member，修法就一步：从该事件 data 里删掉 origin、保留 preset，其余成员不动。是无损的 —— origin ∈ {default, inferred, selection} 不被任何后续代际携带，所以没有"该归一成哪个值"的歧义。subagent/descriptor 的 version 2 同理，2 → 3（v1→v2 与 v2→v3 完全不碰这个事件类型，v3→v4 的 childCatalogFact 白名单是 [1,2,3] 且 2 与 3 处理完全相同）。两条在 #9421 里我写全了，形状和你们这里报的是同一族，就不重复贴了。

一个和你们"10/11 受影响"口径有关的补充：这条闸门不只让那一条会话打不开。persistence observer 会把每条已存 v0 会话都喂进这个 payload 闸门，所以一个坏工件会让整个 store 的 session-search 查询全部失败（SESSION_QUERY_PERSISTENCE_FAILED），不是只坏它自己 —— 我们在 #7995 上量过。所以"改完 node_modules 之后搜索才恢复"这个现象，根因是这条，不是搜索层自己坏了。

边界：我们只修已经落盘的工件，不替官方改代际；上游那行 disposition（'permission/preset': disposition(['preset']) → 加可选 origin）仍然是该有的长期修复 —— 两者互补，你的 10 条会话不用等新版本也能开。

用法：dsh-session-surgeon repair <id>（默认 dry-run，--apply 先写 .bak.<utc>）；先停写者再修。