那天晚上我只是点了「框架升级」，DSH 就再也没起来：页面转圈，终端里躺着一行 exit code=1。
我用的插件叫 DSH 插件门控中心（仓库 Noob-stupid/dsh-plugin-gating-hub，npm 包名 @noob-stupid/dsh-plugin-console —— 三个名字都不一样，这点后面还会讲）。它的定位是「为 DSH 做框架升级安全 + 插件版本门禁」，底座之上再叠一层多源插件市场做发现层。当初装它只图一句话：失败的升级会回滚。
复盘下来最该早点想清楚的是：这类故障分成两个类别，而我把第二类当成第一类处理，白折腾了一小时。
先交代插件本身：Star 102（站点快照 101）、周下载 3,044（站点快照 3,795）、MIT；信任档位「已验证」（4 天前在 dsh 0.2.0-rc.2 下真实安装成功）；安全扫描 🔵「含敏感能力」（可执行外部命令、读写删除本地文件、发起外部网络请求，涉及外部主机 gitee.com），且尚无人工评估。
先分清：坏的是配置，还是包本身
一句话：恢复配置层的动作，对包载荷被清空的故障毫无作用。
两类故障都是「服务起不来」，但根因不同：
- 配置层坏了：
cordis.patch.yml被失败的升级写坏，包都还在； - 包载荷没了：框架包被清空或删除，此时
cordis.patch.yml完好无损，配置恢复一百遍也没用。
第一类：配置坏了，回滚点就是救命的
路径一，界面上的「回滚到上一版」。升级前它会做两件事：备份配置 + 建一个全树回滚点；安装或重启失败就自动把整棵树回滚。框架卡片上常驻的「回滚到上一版」按钮走完整流程：停服务 → 恢复全树 → 拉起 → 健康检查。
路径二，服务已经起不来时，用插件目录里的脚本 —— 这段我最常用，因为它不依赖界面：
node scripts/safe-boot.mjs --list
node scripts/safe-boot.mjs --restore-last-good
node scripts/safe-boot.mjs --disable-suspects
node scripts/safe-boot.mjs --mark-good依次是：看有哪些快照、整份逐字节恢复到最近的良好快照、只给点名的可疑行追加 disabled: true（不删任何行）、把某份快照标记为「良好」（永不随保留策略删除）。
有个细节值得单独记：安全启动快照存在 dshHome()/plugin-console/safe-boot/，不在 profile 目录里。我第一次找不到快照，就是一直在 profile 目录里翻。习惯走接口的话，路由是 POST /plugin-console/safe-boot 加 {"action":"restore-last-good"}，它会先把当前状态再备份一份。
让我踏实的是这套设计的一个性质：每次自动禁用，距离一次回滚都只有一条命令。它只在有硬证据时动手（包的解析基准上全解析不到、file:// 目标真不存在、启动日志点名该行），@deepseek-ai/* 与受保护 / 核心行永不被自动禁用，没什么可写时一个字节都不写。每次自动禁用都在 dshHome()/plugin-console/auto-disable.log 留一条记录：时间 / 行 id / 证据 / 恢复命令。
第二类：包载荷被清空，恢复配置真的没用
这一类我是从真实事故里学到的：2026-10-14，cordis 的 store 实体被清空，dsh-llm / dsh-tools / dsh-web 变成空目录，最终表现为 54 plugins failed to import，服务以 exit code=1 退出。
最扎心的是两点：cordis.patch.yml 完好，所以恢复配置毫无作用；而这个控制台自己就跑在 dsh 里 —— dsh 起不来，它就根本没被加载过。指望一个没被加载的插件去修一个让它无法加载的问题，逻辑上就不成立。
所以这一类要的是进程外的闭包预检，同样不需要服务在跑：
node scripts/fw-preflight.mjs --check
node scripts/fw-preflight.mjs --repair--check 只诊断、列出无法解析的包、写任何东西都不写；--repair 按 lock 完整性从本地 npm 缓存恢复，然后复验。
这里有一条判据，我认为是全文最值得抄走的一点：判据是「依赖闭包能否解析」，而不是「目录是否为空」。后者对「壳还在、里面被清空」完全失明 —— 实测里，一场朴素的空目录扫描报了 237 个误报；换成闭包判据后，全部 287 个包都通过，并精确点名了唯一出问题的那一个。237 对 1，就是判据选错的代价。
几个边界也值得知道：--repair 是离线的、从不猜版本（lock 里没有的包如实报成 no-lock-entry），且绝不杀进程、绝不启进程、绝不占端口 —— 抢端口恰恰就是 "The application could not start or stopped unexpectedly" 的来源。修完，服务要你自己重启。
我现在的处理顺序
先看日志定性：出现「包级」报错就直接跳到闭包预检，别在配置上耗时间；判断是配置层，先 node scripts/safe-boot.mjs --list 找快照再 --restore-last-good，服务起来后进界面点「回滚到上一版」交叉确认；日志指向包本身，就跑 node scripts/fw-preflight.mjs --check，需要修才 --repair。最后一步永远是自己重启服务 —— 不要为了「快点生效」去 kill 端口，手工重拉会和宿主抢端口。
总结
这次事故教我的不是「回滚有多强」，而是先判断坏的是配置还是包：配置层坏了，一份安全启动快照加一条命令就能回来；包载荷被清空时，唯一有效的是那条进程外的闭包预检，判据是依赖闭包能不能解析，而不是目录空不空。同类插件的中文清单与安装形态见 DeepSeek Harness Hub 插件清单。
适合与不适合
适合：长期跟进 DSH 框架升级、常被新版打断的人；需要「升级失败必须能回到上一版」这条底线的团队；桌面端与 Web 端共用一套门控的人。
不适合：只想装个插件来用、几乎不碰框架升级的人，收益接近于零还多背一个常驻面板；完全不接受外部网络请求（含 gitee.com）的离线环境，它在扫描里就是「含敏感能力」且尚无人工评估；以及指望它替你判断插件业务正确性的人。
标签：dsh-plugin-gating-hub、DeepSeek Harness、框架升级安全
本文由 DeepSeek Harness Hub 自动整理，数据来源于插件详情页。