前言¶
DeepSeek Harness（DSH）的配置与插件都落在 profile 里。一次 apply() 抛错、命令重复注册、或构造期读了尚未落地的文件，宿主可能在插件加载阶段就退出——此时救援类插件自己也进不了启动流程。社区里已有 dsh-fix、dsh-plugin-ops、各类备份与回滚插件，各自侧重诊断、静态规则或清单快照；dsh-rescue-guard 把「命令名冲突的启动前预检」「崩溃日志六类归类」和「不依赖 DSH 的独立 CLI」收在同一套工作流里，维护者 1250589385（raysnows）在 README 中写明设计来自本机 21 份真实崩溃日志的反推。
这是什么¶
dsh-rescue-guard 归类为工作流插件，当前包版本 0.3.1，许可证 MIT。它解决两类问题：DSH 已无法启动时，用 Node 内置模块实现的 dsh-rescue 做诊断、安全模式、快照回滚与禁用可疑 bundle；DSH 仍正常时，在启动前做启发式静态预检，并在面板里查看崩溃历史、安全模式与快照。README 强调：若崩溃发生在插件加载阶段，本插件作为 bundle 同样可能加载失败，因此独立 CLI 是核心能力，而不是可选附属。
两半分工¶
| 组件 | 何时工作 | 作用 |
|---|---|---|
独立 CLI dsh-rescue |
DSH 起不来 | 不依赖 DSH：诊断、预检、安全模式、快照、禁用/启用 bundle |
| 启动前预检 | DSH 正常 | 提前发现命令名冲突、缺失文件、可能遮蔽根路由的注册等 |
| 面板 UI | DSH 正常 | 诊断信息、安全模式、快照管理；底部提供可复制的救援命令 |
维护者在日志统计表中列出本机样本：21 份崩溃里 12 份崩在插件加载中（含 ENOENT 读缺失文件 8 次、command "rules" is already registered 2 次、1 entry did not activate 2 次等），其余涉及启动握手或运行期进程退出——这解释了为何必须保留脱离宿主的 CLI。
独立 CLI 与子命令¶
CLI 入口在插件包目录的 bin/dsh-rescue.cmd（Windows 可双击；会探测本机 Node 或 DSH 自带运行时）。子命令与全局选项以 README 为准：
dsh-rescue diagnose 看崩溃原因 + 预检 + 建议（建议先跑）
dsh-rescue crashes [--limit N] 只列归类后的崩溃历史
dsh-rescue scan 只跑启动前静态预检
dsh-rescue safe-mode status|on|off 安全模式
dsh-rescue snapshot create|list|restore <id>
dsh-rescue disable <bundle> 把某个 bundle 移出启动列表
dsh-rescue enable <bundle> 加回启动列表
--profile <dir> 配置目录（默认 ~/.dsh/profiles/desktop）
--home <dir> DSH_HOME
--json 以 JSON 输出
典型救援顺序：先 diagnose，再 safe-mode on 后尝试启动 DSH；若仍失败，按诊断中的 web_auth 等建议处理；若要定位具体插件，可用 enable 逐个加回。
启动前预检与安全模式¶
预检对应 README 所列真实事故类型：命令名冲突（例如多个插件注册同一命令导致 apply() 中断）、构造期 readFileSync 目标文件缺失、以及 prefix 挂在 / 可能影响桌面端握手。文档明确：预检是静态启发式，命中值得查，未命中不代表没问题；UI 与 CLI 都会提示这一点。0.3.x 起 scan 还检测对宿主私有事件 internal/* 的订阅，用于升级宿主前扫一眼兼容性风险。
安全模式布防后，下次启动只加载 @deepseek-ai/* 官方 bundle，第三方暂时移出；启动成功后自动还原。约束包括：不改动官方 bundle、改写清单前自动快照、原子写、幂等。插件不自动删除任何东西，只做禁用（可还原）。
快照、指纹与崩溃守护¶
每次启动会保留清单级快照（package.json / pnpm-workspace.yaml / rules.yaml），默认路径为 <profile>/.rescue/snapshots/，保留最近 10 份。清单损坏时可：
dsh-rescue snapshot list
dsh-rescue snapshot restore 2026-11-07T13-35-29.164Z
启动指纹写在 boot.json 的 fingerprint / lastGood：成功启动时记录宿主与各插件解析版本，失败时与上次成功对比并写入日志与面板。
面板可安装崩溃守护：事件驱动监听崩溃日志目录（非轮询为主），防抖后生成 <profile>/.rescue/last-crash-report.txt，含错误原文、历史归类、预检摘要与可执行建议。README 称平时零占用，主路径依赖操作系统目录变更通知。
崩溃诊断在 0.3.0 起会解析栈里第一个非 @deepseek-ai/* 的第三方帧，缩小嫌疑 bundle 范围，但文档要求人工确认链式调用场景，栈帧不是最终判决书。
与生态里其它插件的关系¶
README 对照表说明：dsh-plugin-ops 强于依赖、peer、版本兼容等静态规则，但不查命令注册冲突；本插件与之互补。与 dsh-fix 在独立 CLI 救启动上有重叠，差别在于命令冲突预检与六类崩溃归类。快照类插件侧重通用备份，本插件快照服务于救援与清单回滚。若你 primarily 需要依赖漂移类检查，文档建议优先考虑 dsh-plugin-ops；若痛点是启动崩溃、命令冲突与 profile 自救，本插件更对口。
安装与启用¶
官方安装命令：
dsh plugin add dsh-rescue-guard
安装后需要重启 DSH，路由与面板才会生效；README 写明装完不重启时 /dsh-rescue/*.json 可能 404，属预期行为。package.json 要求 Node >=20。包内自带回归测试：
node test/regression.mjs
期望 24 项全部通过。
适用场景与注意¶
适合：本地 desktop profile 插件较多、曾多次启动失败、需要在不启动 DSH 的情况下禁用 bundle 或回滚清单的开发者。
务必注意：
- 插件以当前 DSH 进程权限读写 profile；安装前应查看 GitHub 仓库 源码与 MIT 许可证。
- 不能在「插件加载期即崩溃」的场景下靠本 bundle 自救——只能用
dsh-rescueCLI。 - 不做法制意义上的安全审计；修不了
renderer exited: killed等应用层进程问题。 - 命令冲突扫描以
package.json声明为准，物理残留在node_modules但已从声明移除时可能漏报。 - 社区目录 SkillHub 插件页 与 GitHub 由社区维护，与 DeepSeek / 幻方无官方从属关系。
结尾¶
dsh-rescue-guard 把独立救援 CLI、清单快照、安全模式与启动前预检（尤其命令名冲突）放在一条工作流里，并附带可选的崩溃守护与面板运维入口。星标与版本以仓库当前信息为准；进一步了解可访问 SkillHub 目录页 与 GitHub：1250589385/dsh-rescue-guard。
