format v4 message requires a producer-owned source kind 报错排查：DSH插件会话写入

format v4 message requires a producer-owned source kind 表示 DeepSeek Harness 的会话格式 v4 在做准入校验时，拒绝了一条消息的 source kind——v4 要求消息源报出「生产者自有的 kind」，而它看到的还是 v3 时代那个通用的 kind: 'plugin' 包装。对应动作是「把插件升级到适配 v4 的版本、或按官方说明把 source kind 改成本生产者自有 kind；改不动就卸载这个不兼容插件」（来源）。

这句报错的关键在于：它不是「会话文件坏了」，而是一条消息在写入前就被格式校验挡下了。有用户实跑遇到，/carry 这类由插件写入的消息在会话格式升到 v4 之后直接抛这句；判据在 dsh-session-format-v3-to-v4 的准入断言里，编码与解码两条路径都会调用，所以既是写不进去、也是读不出来（来源）。下面讲清含义、修法与它和「迁移被拒」的区别。

format v4 报错含义：为什么拒绝 plugin 这类 source kind

v4 的准入校验直接拒绝 kind: 'plugin' 这种泛型包装，只接受「生产者自己命名的 kind」——所以老插件沿用 v3 写法写出来的消息，在 v4 里连门都进不去（来源）。 形状对照看：

按顺序认一遍：

1. 它是「准入失败」，不是「数据损坏」：校验发生在消息写入或读取的入口，事件还没落进日志就被拒绝。预期：日志里可能看不到这条消息的痕迹。
2. 它同时影响读写两条路径：assertV4SourceRowAdmission / assertV4MessageSources 在编码与解码两侧都调用，所以不只是「写不进去」，旧写法存在的消息读回来也会被挡。预期：升级或修正形状后，读写都恢复正常。
3. 它是一次全回合失败，不只是这条消息失效：当消息在某个步骤能运行之前就被追加、又抛了错，整个回合会失败。预期：修好 source kind 后，该回合能正常跑完。

记住一句话：v4 要的是「谁写的就用谁的名字」，通用包装被退休了。

别把它读成会话文件损坏。 在准入环节被挡下的消息根本没写进日志，磁盘上的会话不受这个错影响；真的会话损坏是另一类报错（seq 缺口、格式版本拒绝）。此时去跑会话修复工具是方向错了——没有东西被写坏，没什么可修的。

4. 这个命名约定是刻意设计的：要求 producer-owned kind，v4 才能让读端在不需要中心注册表的前提下，区分官方 checkpoint 与第三方插件的标记，消息来源因此自描述。预期：按约定实现的插件，在 v4 下能正确读回自己写的旧消息。

format v4 报错怎么修：升级插件、卸载不兼容插件与会话迁移

修法有三条主线：优先把插件升级到适配 v4 的修复版本；升级不了就按官方说明把 source kind 改回生产者自有 kind；实在不兼容就用市场卸载它，再按迁移流程处理受影响的会话。 按顺序执行：

1. 升级插件：把触发报错的插件更新到适配 v4 的版本（dsh plugin --profile web add <包名>@latest，或在其来源通道拉最新）。预期：升级后再执行同一操作，不再抛 format v4 message requires a producer-owned source kind。
2. 按官方说明改 source kind：如果插件源码在你手里，把消息来源从 kind: 'plugin' 包装改成生产者自有的 kind——第三方插件按约定是带插件名前缀的形式，如 plugin:<插件名>（来源）。预期：改完重跑，消息能通过 v4 准入。
3. 卸载不兼容插件：拿不到修复版本、又没法改源码时，在 DSH Plugin Hub 的已安装列表里核对版本与来源，然后把不兼容的那个卸载掉，避免它继续往会话里写非法形状。预期：列表里不再出现该插件，相关操作不再触发校验失败。
4. 处理受影响会话：对已经因为这条消息而失败、打不开或写不进新内容的会话，按官方会话迁移流程处理（不要手工改文件）。预期：会话能重新加载，后续写入不再被拒。
5. 回归验证：重跑一次原本报错的操作（例如那条插件的命令），再打开受影响会话确认可读。预期：两步都通过，才算修完。

边界：如果你的现象是「升级 DeepSeek Harness 后老会话整体打不开、报 refuses this format v0」，那是另一个问题，属于迁移清单问题，见下方对比。

为什么升级比改源码省事：还在写退休包装的插件，通常没跟宿主的同一条发行线打过补丁，所以你在本地把某处调用改掉，只是造了个本地 fork，下次宿主升级又会漂移。升级到在维护的版本，能让 source kind 约定与执行它的宿主保持对齐；只有在你拥有该插件、又没有可用发行版时，才回退到改源码。

与 session format migration refusal 的区别

两者的共同点只是「都涉及会话格式」，机制完全不同：本篇是 v4 对 source kind 的准入失败，另一篇是旧数据迁移清单漏项导致的拒读（来源）。 对照看：

1. 方向相反：本错是「新格式不允许旧形状写入」，迁移拒读是「读端不认识自己过去写出的形状」。预期：先判断报错串，再选对应处理。
2. 处理代价不同：本错多半升级或换插件就好；迁移拒读涉及历史数据，必须先备份再动。预期：不明白机制时，不要手工改会话文件。
3. 别混为一谈：迁移被拒的完整背景在《DSH plugin 升级后老会话打不开？refuses this format v0 迁移拒读排查》里，本篇不重复。预期：两篇各修各的，不互相覆盖。

还有一组值得区分：v4 准入失败说的是消息来源的「形状」，而工具调用抛出的 schema / 校验错误说的是插件传入的「参数」。两者可能出现在同一个失败的回合里，所以要看报错串：这一条点名 source kind，另一条点名某个参数。修参数 schema 解不开 source kind 的错，反过来也一样。

DSH插件 排查注意事项

1. 先看报错串：v4 source kind 准入与迁移拒读是两码事，按串选处理。
2. 别手工改会话文件：格式与来源形状互相关联，改错一处会把可修复问题变成真损坏。
3. 优先升级插件：能拿到适配 v4 的版本，就别去改源码。
4. 卸载是最稳的兜底：不兼容插件先移除，再谈迁移历史会话。
5. 回归验证两步：重跑原操作 + 打开受影响会话，都过才算修好。

DSH插件 消息 source kind 的官方约定

官方约定一句话：v4 之后消息来源必须由生产者自己命名，通用包装被退休；同一版还改了会话事件访问方式，插件需要跟着适配。 两点说明：

1. 生产者自有 kind 是硬要求：v4 准入拒绝 kind: 'plugin'，官方 checkpoint 用官方自己的类型，第三方插件用带插件名前缀的形式，两代读回同一个 kind（来源）。预期：插件作者按此约定改一次即可长期适配。
2. 同一版还有别的破坏性变更：会随宿主升级而漂移，升级 dsh 之后先跑一遍插件的离线冒烟/自检再上生产（来源）。预期：把「升级后先自检」当固定动作，能提前发现这类准入问题。

与其为一个 v4 不兼容的插件到处找补丁，不如先在 DSH Plugin Hub 的已安装列表里核对版本、把不兼容的那个卸掉再来。

来源：deepseek-ai/deepseek-harness（官方仓库）、社区插件 dsh-tui-compact-carry、Web UI 指南（官方文档）。