v0→v1 session migration refuses logs whose permission/preset event carries origin (producer/schema drift)

[felixzhang-glitch]

Summary

Sessions written around 0.1.2-rc.1 (2026-09-06 era) stamp the permission/preset event with an extra origin member:

{"type":"permission/preset","seq":0,"time":1787364897008,"data":{"preset":"danger-full-access","origin":"default"}}

@deepseek-ai/dsh-session-format-v0-to-v1 declares the released v0 shape as exactly { preset } (disposition(["preset"]), no optional members), so assertReleasedV0Keys throws on origin and the whole session is refused:

failed to observe session "…": @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

Current builds (0.1.6-alpha.2, and master as of 2026-09-19) no longer write origin, so this is producer/schema drift from a version window — but the affected v0 logs on disk stay permanently unloadable, and the session list plus any usage aggregation silently skips them.

Minimal reproduction

A v0 session.jsonl containing only:

{"type":"session","version":0,"id":"session-00000000-0000-0000-0000-000000000000","createdAt":1787364896985,"cwd":"/tmp","delegationDepth":0,"agentPreset":"standard"}
{"type":"permission/preset","seq":0,"time":1787364897008,"data":{"preset":"danger-full-access","origin":"default"}}

framed as a zstd log (first frame = header line) fails migration with the error above. Removing "origin" lets it migrate cleanly.

Suggested fix

Admit origin as optional in the v0 disposition for permission/preset and strip it during migration (a small normalizeLegacyPermissionPreset alongside the other normalizers in migration.ts), so the emitted v1 event stays schema-exact. More generally, the v0→v1 migration could tolerate and drop unknown informational members instead of refusing the whole session — fail-closed on unknown event types still makes sense.

(Issues are disabled on this repo, hence posting here. Observed on 20 real sessions across several workspaces; all load fine after locally stripping the member. Happy to send a PR if you agree with the approach.)

[xiaoyuyu6420]

这个形态是社区已经归档并处理过的家族成员——#6151 的四类清单里第 1 类就是它（permission/preset 多 origin 成员），dsh-session-surgeon 已支持（处理方式：只保留 preset 成员、剥掉 origin，权限语义不变；同帖还覆盖 subagent/descriptor v2 和插件 source 的 summary/form 形态）。#6297 也从生产者侧记录过同一 drift。

如果不想自己维护清理脚本可以直接用 surgeon；无论用哪个，动文件前的老三样：停 dsh 进程、dry-run、整目录留一份副本。

你的报告有一个对维护者有用的增量：0.1.6-alpha.2 和 master 仍未修的确认（与 #6779 的逐字节比对结论一致），以及这个形态在真实日志里的原文样例。建议把它并进 #6520 的未修复清单——那一帖正在聚拢「迁移器应接受自家已发布写端的产物」的证据面。