DSH rc.8 改了 SQLite 存储格式（不兼容）——升级前请先看这条

DeepSeek Harness rc.8 里最有分量的一行，不是一个功能，而是埋在「Chores / 其他变更」下面：SQLite 后端读写更快、分叉更快、体积更小——但数据结构不兼容了。如果你一直把 DSH 的升级当成「无脑更新」，这个版本会告诉你：不是了。

到底改了什么

rc.8 重构了 SQLite 后端。好处是真的：读写性能更好、大历史的分叉更快、磁盘占用更小。代价是兼容性：新的存储格式不向后兼容旧版本写出来的数据。

「不兼容」实操上意味着什么

• 旧数据不会直接打开。 rc.7（或更早）写出来的存储，不保证能被 rc.8 读取。
• 会话和存储可能带不过去。 如果你的工作流依赖 SQLite 里持久化的会话，没准备好就升级，看起来会像「数据丢了」——其实是格式断了。
• 这种事要在升级前发现，而不是之后。 一旦升级完、新版已经往存储里写了数据，回退本身就是另一个麻烦。

怎么规划这次升级

1. 先备份数据目录。 不管 DSH 把存储写在哪，升级前先复制一份。
2. 看官方 release notes 里的迁移路径。 权威步骤在官方发布/升级文档里——把第三方摘要当线索，别当操作手册。
3. 导出你丢不起的东西。 会话或设置如果重要，跳版本前先导出或记下来。
4. 先在一台机器上验证。 在可丢弃的环境里跑通迁移，再滚到你真正依赖的那台。

真正的教训

DSH 大约一周三更，而破坏性变更往往藏在「Chores / 其他变更」这种低调标签下。rc.7 把 settings.plugin.item 槽位改成了 keyed，rc.8 又断了 SQLite 格式。规律很清楚：在这个节奏下，changelog 是你升级清单的一部分，不是事后补课。 小字也要读——尤其是那些看起来不像「功能」的行。