为什么 DeepSeek Harness 一次只报一个错，会话列表里的失败数量还在变？

在 DeepSeek Harness 里，拒读是逐条会话进行的，加载到哪一条失败就在那里停下。社区统计过一个 35 个会话的目录一次报出 15 个失败；把每个失败会话单独打开、逐条记录报错文本，才能得到完整的四类拒读清单。

DSH plugin 场景下区间 seq 编码导致的会话损坏和拒读是同一个问题吗？

DSH plugin 场景下，区间 seq 编码与格式拒读属于同一族但机制不同。区间编码问题是写入端把连续 seq 压成区间、读端只认扁平整数，且格式版本号没随变更递增；拒读问题则是迁移清单本身漏项。两者都需要官方在读写两端对齐后才能根治。

DeepSeek Harness 老会话拒读有没有只读的修复办法，能修到哪一类？

DeepSeek Harness 老会话拒读的只读修复，靠社区工具 dsh-session-surgeon 覆盖前三类，做法是只读分析并给出可应用的修复，不重写无关内容。第四类未知历史事件需要官方扩大清单才能通过；使用前务必备份整个会话目录。

DSH plugin 升级后老会话打不开？refuses this format v0 迁移拒读排查

Q: 升级 DeepSeek Harness 后老会话报 refuses this format v0 打不开是什么原因？

DeepSeek Harness 老会话报 refuses this format v0 的根因，是会话格式迁移清单只按当前主线写入端冻结，漏掉了历史版本真实写过的形状。老会话里存在 0.1.1-rc.1 写入的 permission/preset.origin、扁平的 replayState 等成员，迁移器不认识这些已发布形状，于是把合法历史数据当成非法格式直接拒读。

升级 DeepSeek Harness 后老会话报 refuses this format v0 打不开，根因是会话格式迁移清单只按当前主线的写入端冻结，漏了历史版本真实写过的形状：老数据里存在 0.1.1-rc.1 写入的 permission/preset.origin、扁平的 replayState 等成员，迁移器不认识，于是把合法历史数据当成非法格式硬拒。先备份整个会话目录，再用只读修复工具处理，不要手工改文件。

DeepSeek Harness refuses this format v0 报错是什么样

表面是一句格式拒读，实际是四类不同的成员被判非法，且一次只报一个错。 有用户实跑遇到（讨论原文）：

升级到 0.1.5 后，35 个会话里有 15 个报 refuses this format v0 Session；
报错一次只出现一条，修好一条才会有下一条，看起来像「越修越多」；
四类被拒的形状分别是：permission/preset 多出的 origin 字段、subagent/descriptor 的 version 为 2 而非 3、插件自定义消息来源 instruction-hint / at-file-mention、以及自带 ignorable: true 的未知历史事件；
另有一类更早的变体：alpha 版本写过数据后用 rc.2（当时 npm latest）打开，报 SessionPersistenceCorruptionError（讨论原文）。

DSH plugin 会话里为什么已发布的历史数据会被判成非法格式

核心矛盾是「读端按当前代码冻结白名单」，而「写端在历史上产出过更多形状」。 社区逐条核对 0.1.5-rc.1 源码后给出的机制是：

RELEASED_V0_EVENT_DISPOSITIONS 只按 master 上仍存活的写入端冻结，因此漏掉了 0.1.1-rc.1 写入的 permission/preset.origin，以及包裹信封之前的扁平 replayState（来源）；
subagent/descriptor 硬要求 version === 3，而旧数据写的是 2；v3 仅比 v2 多一个可选的 agentReasoningEffort，升号本应无损；
插件自定义消息来源属于封闭的 kind / form 集合，插件早期写入的值不在集合内；
家族里还有一处编码不一致：写端 encodeSeqRanges 把 ≥3 个连续 seq 压成 [[start,end]]，rc.2 读端 assertProvenance 只认扁平整数，而 SESSION_FORMAT_VERSION 没有随格式变更递增，版本守卫被静默绕过（来源）。

一句话：拒读不是数据坏了，而是读端不认识自己过去写出的形状。 对 DSH插件与 DeepSeek插件来说，这属于同一类向后兼容问题：只要会话由旧写入端产出，读端就可能拒收。

DSH plugin 升级后老会话拒读怎么处理，修复到哪一步

处理顺序是备份 → 只读分析 → 应用修复 → 记录未覆盖项。 具体做法：

先整体备份会话目录（~/.dsh/profiles/<name>/sessions/），修复工具只在前三类的路径上改动，备份是唯一回退手段；
用社区修复工具 dsh-session-surgeon 先跑 inspect 只读模式，确认每一条会话命中的是哪一类拒读；
确认无误后再执行 --apply 应用修复；社区实测在一个 57 个会话的目录里从「只有 1 个能打开」恢复到 57 个全部可读；
第四类（未知历史事件自带 ignorable: true）需要官方扩大迁移清单，工具的覆盖范围不含这一类，遇到就单独记录、等官方修；
版本侧线索：0.1.2-rc.1 起的读端已带 decodeSeqRanges，受区间编码影响的会话在那个版本上是健康的；根因修复仍是写端递增格式版本号；
需要确认自己装的是哪条发布线（latest / alpha / rc）时，可在「设置 → 插件市场」核对已装插件与版本，本项目的社区插件市场入口是 DSH Plugin Hub。

DSH plugin 排查注意事项

先备份、再用只读工具处理；下面两条「捷径」会把可修复的拒读直接变成真损坏。 三条要点：

不要手工编辑会话文件：版本号、事件形状、seq 编码三处互相关联，改错一处会把可修复的拒读变成真正损坏。
不要用降级版本去「打开一次再存回去」：旧读端的写入可能引入新的形状差异，让问题扩散到更多会话。
同类会话问题的完整背景还汇总在《DeepSeek Harness 会话损坏排查：枚举失败、格式拒读与恢复做法》里，可对照查看。

来源：Discussion #6151、Discussion #5818、Discussion #5160