前言¶
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 後「功能變少」可以從零散日誌線索收斂到一張可重複打開的自檢報告；在修復前基線保持不變，便於對照同一組缺失項直到環境重新健康。
