前言¶
DeepSeek Harness（DSH）把能力拆成大量插件与客户端模块，由宿主在启动时完成组合。升级宿主后，各插件包会按 engines.dsh 做兼容性准入：不满足条件的会被静默跳过，日志里往往只有一行 skipping profile bundle "<name>"，侧栏菜单、面板或工具可能就此消失，却不容易第一时间对上原因。
下面介绍 ColdRainLab 维护的 dsh-feature-check（分类 admin-security）：在每次 DSH 启动时，把当前状态与「上次健康启动」留下的基线对比，把 Loader 条目、客户端模块和被兼容性检查跳过的插件包缺失变成一份可查看的报告，而不是靠人工逐个对日志猜。
这是什么¶
dsh-feature-check 是 DSH 内置设置里的一块「启动自检」能力：启动后自动对比基线，仅在本次启动判定为健康且无缺失时更新基线；发现问题时保留旧基线，后续启动会持续报告同一批缺失，直到环境修复。结果集中在 设置 → 内置插件 → 启动自检 标签页（不再占用侧栏底部入口）。仓库：https://github.com/ColdRainLab/dsh-feature-check，当前资料中的版本为 0.1.2，许可证 MIT，engines.dsh 为 >=0.2.1-rc.2（开放上界）。
检查什么¶
自检覆盖宿主组合与启动图层面上的四类信息，与 README 中的表格一致：
| 检查项 | 说明 | 失败示例 |
|---|---|---|
| 客户端模块 | /plugins 启动图（clientModules.graph()）里的模块 id 与基线对比 |
UI 插件被跳过 / 客户端 bundle 构建失败 |
| Loader 条目 | 当前活跃 Loader 条目名与基线对比 | 宿主侧插件没有启动 |
| 插件包诊断 | pluginManager.listBundles() 中「已启用但带 error」的 bundle |
incompatible-version（升级后 engines 不匹配） |
| 升级识别 | 运行时版本与基线版本不同 | 0.2.1-rc.2 → 0.2.1-rc.3 |
用户在插件页主动禁用的插件不计入缺失（记为提示，不算问题）。单个插件内部路由或业务逻辑报错不在检查范围内；插件也不联网、不做遥测，只读宿主服务并写入本地 JSON。
数据落盘位置¶
自检读写目录为 <DSH_HOME>/feature-check/（卸载插件时不会自动删除，需手动清理）：
<DSH_HOME>/feature-check/
├─ baseline.json # 上次健康启动的基线（Loader 条目 / 客户端模块 / 运行时版本）
├─ report.json # 最近一次自检报告（面板展示的同一份数据）
└─ expect.json # 可选：手工追加必须存在的条目（不会被自动改写）
若某功能是在「第一次健康基线」之后才安装、但希望始终被视为必须存在，可在 expect.json 中固定条目，例如：
{
"clientModules": ["dsh-session-delete", "dsh-worktable"],
"entries": ["dsh-session-delete"]
}
注意：基线代表「上次健康启动」；若功能在第一次启动时就已经缺失，自检无法推断它「曾经存在」，只能依赖 expect.json 补充期望。
设置页与 HTTP 接口¶
打开 设置 → 内置插件，顶部标签栏中与「插件列表」并列有 「启动自检」。页面展示 DSH 版本、本次是否升级、总体结论（通过 / N 项功能缺失）、缺失项（插件包 / 客户端模块 / 宿主条目，含处理建议）、检查时间与报告路径；底部有「重新检查」。检测到问题时不会自动弹窗，仅在该页显示红色结论；进入页面会自动刷新一次最新报告。页面说明：只读组合与模块清单，不读取会话内容。
对外路由（桌面端 /api 需登录态，设置页经宿主 __DSH_TRANSPORT__.fetch 请求）：
| 方法 | 路径 | 说明 |
|---|---|---|
| GET | /api/feature-check/health |
{ ok, version } |
| GET | /api/feature-check/status |
{ ok, report, pending }（设置页读取） |
| POST | /api/feature-check/run |
立即重新检查并返回新报告 |
安装与卸载¶
安装命令须以你本机 DSH 发行包中的 dsh.cmd（或等价 CLI）路径和已下载的 .tgz 包路径为准。README 中的示例如下（Windows，指向本机归档路径 v0.1.2）：
& "D:\Program Files\Deepseek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add "C:/Users/ROG-STRIX/.dsh/plugin-archives/dsh-feature-check/v0.1.2/dsh-feature-check-0.1.2.tgz"
安装后宿主热加载，一般无需重启；刷新页面后在 设置 → 内置插件 中应出现「启动自检」标签。首次健康启动会建立功能基线，页面可能显示「已建立功能基线」。
卸载示例：
& "D:\Program Files\Deepseek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop remove dsh-feature-check
~/.dsh/feature-check/ 下的基线与报告文件卸载后仍保留，需要时请自行删除。
典型用法¶
- 完成 DSH 或插件大版本升级并重启（或热加载）宿主后，打开 设置 → 内置插件 → 启动自检，查看是否识别为升级启动，以及总体结论是否为通过。
- 若结论为「N 项功能缺失」，按页面列出的插件包、
incompatible-version、缺失的客户端模块或 Loader 条目逐条处理（常见做法是调整插件engines.dsh或安装与当前宿主匹配的插件版本）。 - 修复后再次启动或点击「重新检查」；仅当本次启动健康且无缺失时，基线才会更新，此后对比以新环境为准。
- 对必须在清单中出现的模块，维护
expect.json，避免「晚于首条基线才安装」的条目无法被历史基线覆盖。
也可在已登录桌面的前提下，对 POST /api/feature-check/run 触发立即检查（与设置页「重新检查」同效）。
适用场景与注意¶
适合谁：经常在同一台机器上升级 DSH、堆叠较多社区插件的开发者或运维；希望在菜单突然变少时先拿到结构化缺失列表，而不是翻完整启动日志。
运行与权限：插件以当前 DSH 进程权限读写宿主服务与 feature-check 目录；安装前应自行审阅源码与 MIT 许可证，确认符合你对 admin-security 类插件的信任要求。
已知限制（摘自 README）：
- 若 DSH 发生破坏性接口变更导致自检插件自身无法加载，不会仍有自动告警，需查 DSH 日志或重装新版自检插件。
- 首启即缺失的功能无法靠历史基线发现，需
expect.json。 - 仅覆盖宿主组合 / 启动图层面，不代替各插件内部自检。
- 不联网、无遥测。
作者在 DSH 0.2.1-rc.3 上验证过自动建基线、报告生成与「升级后 bundle 被 incompatible-version 跳过」时的报出与基线保留行为；你所在环境的条目数量会与 README 中的 205 / 79 等示例不同，以本机报告为准。
社区目录页：https://www.skillhub.cn/plugins/ColdRainLab/dsh-feature-check（独立站点，与 DeepSeek / 幻方无官方从属关系）。源码与 issue：https://github.com/ColdRainLab/dsh-feature-check。
经过上面的步骤，升级 DSH 后「功能变少」可以从零散日志线索收敛到一张可重复打开的自检报告；在修复前基线保持不变，便于对照同一组缺失项直到环境重新健康。
