保守升级 oldzhang82/dsh-conservative-upgrade

DSH 保守升级 Skill

一个 skill，教 AI 安全升级 DeepSeek Harness（DSH）。核心是保守插件策略：升级前对每个已装插件做兼容性体检，绝不 fork 插件——等作者发兼容版，或保护性禁用。

背景

DSH 高速迭代，但插件作者无法快速跟随。升级后无法拉起的情况，绝大部分是插件冲突引起的，不是 core 的问题。

我们高度认可 oh-my-dsh/dsh-plugin-upgrade-skill 的做法——把已知的破坏性变更整理成机器可读的升级卡。但手动修改插件让它适配新 DSH 版本，有两个代价：

1. token 消耗巨大——agent 手改插件源码去匹配新 API，昂贵且易错。
2. 和原作品形成分叉——一旦本地改了插件，作者发兼容新版时你就无法自动升级，只能手动 merge 他们的更新到你的 fork。

因此我们采用更保守的策略：绝不 fork 插件。升级 DSH 之前，先审计每个已装插件声明的 peer 兼容性，据此行动——升级到作者的兼容版，或保护性禁用。手动改源码是最后手段，只在作者不发（也不会发）兼容版时才用。

这个 skill 做什么

SKILL.md 是一份完整的 DSH 升级 runbook（带本地改动的机器），覆盖：

- Phase 0 准备：本地改动清单 + 🔴 插件三分法体检（升级前做完）+ 备份清单
- Phase 1 git：stash / ff-only / pop，冲突时按语义重打补丁
- Phase 2 清未跟踪构建残留（一次真实事故的根因，必做）
- Phase 3 依赖 + 构建 + junction 体检
- Phase 4 preset 迁移（🔴 在第一次重启之前做）
- Phase 5 重启 + 日志体检 + 验证清单（含系统提示词对比）
- Phase 6 clean-room 预案（profile 层修复，非默认路线）
- 0.2.0 破坏性变更清单 + 坑表（血泪教训）

插件三分法（核心）

升级 DSH 之前，对每个已装插件三选一：

| 判定（查已装版本 peer 是否覆盖目标 DSH 版本） | 动作 |
| 覆盖 | 无需升级 |
| 不覆盖，但 npm 有覆盖目标版本的新版 | 先升级到作者的新版（不 fork） |
| 不覆盖，且没有兼容新版 | 保护性卸载 / 让 DSH 启动时自动跳过 / allow-version 豁免（人定） |

关键认知：插件不兼容 = 保护性拒载（跳过 + 红字），不是启动阻断。真正炸启动的是构建残留 / 坏 junction（Phase 2/3）。

安装

mkdir -p ~/.dsh/skills/dsh-conservative-upgrade
cp SKILL.md ~/.dsh/skills/dsh-conservative-upgrade/SKILL.md

或克隆：

git clone https://github.com/oldzhang82/dsh-conservative-upgrade.git ~/.dsh/skills/dsh-conservative-upgrade

致谢

- oh-my-dsh/dsh-plugin-upgrade-skill — 升级卡的方法论，我们高度认可，本 skill 在"不 fork"这一点上做了保守化。
- DeepSeek Harness — 宿主框架。

License

MIT