dsh-safe

让 DeepSeek Harness (DSH) 在插件加载失败时自动禁用坏插件并继续启动的 PowerShell 守护脚本。

面向的场景：DSH 升级后，某些第三方插件与新版不兼容，导致启动直接 fatal load failure 退出。dsh-safe 包在 dsh 外面，识别启动错误、自动禁用问题插件（或移除坏 bundle）、重试启动，让 DSH 正常跑起来。

解决的问题

DSH 的启动审计（dsh-app-boot 的 assertEntriesActivated / assertEntriesLoaded）会在以下任一情况让整个进程失败退出，没有"跳过坏插件"的兜底：

报错	含义	dsh-safe 的动作
cannot resolve profile bundle "X"	bundle 包解析不到	从 dsh.profile.bundles 移除 X
profile bundle "X" declares no dsh.bundle	包不是合法 bundle	从 dsh.profile.bundles 移除 X
plugin(s) failed to load: X	条目包导入失败	在 cordis.patch.yml 中 disabled 该条目
N entries did not activate	激活抛错 / 注入服务缺失	在 cordis.patch.yml 中 disabled 该条目

为什么是"进程外的程序"而不是插件

坏插件把启动搞崩后，管理类插件自己也起不来（鸡生蛋）。"自动禁用"必须发生在 DSH 进程之外，所以这是包装 dsh 的脚本，不是一个 Cordis 插件。

安装 / 使用

方式 A：直接运行脚本

# 等价于 `dsh web`，失败时自动禁用坏插件并重试（默认最多重试 4 次）
.\dsh-safe.ps1

# 等价于 `dsh web --port 9999`，额外参数透传给 dsh web
.\dsh-safe.ps1 web --port 9999

# 指定 profile 与重试次数
.\dsh-safe.ps1 tui -MaxRetries 2

# 只 dump 组合、不改动、不启动（诊断用）
.\dsh-safe.ps1 -Diagnose

方式 B：安装为 npm 包（可被 dshmarket 识别）

# 本地开发安装到当前 web profile
dsh plugin --profile web add link:../../../Desktop/other/dsh/dsh-safe

安装后 dsh-safe bin 会出现在 profile 的 node_modules/.bin 下；也可从源码目录直接运行 bin/dsh-safe.js（自动调用同目录的 dsh-safe.ps1）。

依赖：Windows 上的 PowerShell（pwsh）、Node.js（dsh 本身就需要）、dsh 与 pnpm 已在 PATH。

安全设计

• 只在确认是启动失败时才动手：仅当输出命中 fatal load failure / did not activate / failed to load / cannot resolve profile bundle / declares no dsh.bundle 时才改文件；普通 Ctrl+C 退出、运行期崩溃一律不碰。
• 改前先备份：package.json 与 cordis.patch.yml 改动前各自备份为同目录下 <文件>.dsh-safe.bak。
• 幂等：重复运行不会重复追加 disabled 条目。
• 不死循环：识别不出坏插件或无法安全修复时直接退出并提示；最多重试 -MaxRetries 次。
• 格式一致：改 package.json 用 node 按 DSH 自身 JSON.stringify(m, null, 2) 的格式写回。

已知限制

• "启动崩 → 自动禁用 → 重启成功"的闭环需要一次真实故障才能端到端验证；建议先用一个不重要的 profile 或临时塞一个坏包测试。

• 只处理启动期的加载失败；插件运行期的逻辑错误不在守护范围内。

• 包括README，插件全由V4pro完成，我也不知道有没有重复造轮子，不过一堆黑话是真

License

MIT