Health checks for DeepSeek Harness: plugin manifest/patch/entry/build/pack/install verification, model-callable plugin_check, profile host-shadowing detection, and environment diagnostics (node/pnpm/dsh PATH, web port).
Health checks for DeepSeek Harness plugins — the practical answer to the dsh plugin check idea from RFC #1629, until the official command exists.
It works in two ways:
CLI (dsh-plugin-doctor / node lib/bin.js) — run it in your terminal or CI before opening a PR.
Plugin shell (dsh plugin add) — once installed in DeepSeek Harness, the agent can call the plugin_check tool directly: "check whether this plugin is ready to publish", no shell needed.
What it checks
Check
What it verifies
Default
manifest
package.json exists; dsh.bundle + dsh.bundle.patch + prepare + main present
✅
patch
cordis.patch.yml parses as YAML and contains at least one insert row with an id
✅
entry
main target exists (warns when not built yet)
✅
files
a files allowlist is declared
✅
build
pnpm run build succeeds
--build
pack + install + config
pnpm pack, install into a fresh DSH_HOME profile, and confirm the plugin id in --dump-config
--full
profile-shadow
dsh-plugin-doctor · DSH Hub
a dsh profile has no real-directory @deepseek-ai/* copy shadowing the host instance (discussion #1697)
--profile
node / pnpm / dsh-path / port-3080
environment diagnostics: toolchain on PATH and the Web UI port free (the dsh doctor idea from discussion #1719)
--env
Exit code is 0 when nothing failed, 1 otherwise. --json prints a machine-readable report for CI.
Run from the repo without installing (after pnpm build):
node lib/bin.js --full ./my-plugin
Plugin usage (agent-callable)
Install the plugin into a DeepSeek Harness profile:
dsh plugin --profile web add dsh-plugin-doctor # from npm
# or from a local build:
dsh plugin --profile web add ./dsh-plugin-doctor-1.3.0.tgz
Then ask the agent inside DSH:
检查一下这个插件能不能发布 —— 先跑 build，再做完整验证。
Check whether this plugin is ready to publish — run the build first, then do a full verification.
The agent calls the plugin_check tool (dir, optional build/full flags). The tool returns PASS/WARN/FAIL per check plus an overall ok flag.
What "full" really proves
--full does not just load the bundle. It:
runs pnpm pack on the real project;
creates a fresh DSH_HOME profile (no pollution of your real one);
runs dsh plugin add ;
runs dsh --dump-config and asserts the plugin id from cordis.patch.yml actually appears in the composed config.
This is the same path the awesome-dsh-plugin maintainers use when they review plugin PRs.
Why it exists
pnpm can silently link an older RC into a plugin's peer slot, and "loads fine" does not mean "works" (see the template runtime guard and troubleshooting).
A repeatable local check (manifest → build → install → config) catches the failures that only show up on other people's machines.
The dsh web boot step currently runs on Windows in CI because the upstream npm CLI lacks the linux-x64 pty.node prebuild (discussion #1686); doctor's install/config verification is platform-independent.
A profile-hoisted real-directory copy of @deepseek-ai/dsh-tools can shadow the host instance and crash every tool call (discussion #1697); --profile flags exactly that precondition before anything boots.
Environment friction (missing pnpm, Node version, PATH, occupied web port) is the other big setup-time failure class; --env turns it into one command (the dsh doctor idea from discussion #1719).
Related community tools
moonquake2004/dsh-doctor — offline profile/session/env diagnostics with 19 checks mapped to community failure reports. Complementary: dsh-plugin-doctor covers the pre-publish plugin path, dsh-doctor covers the offline profile/session path. Its P5 check and our profile-shadow check flag the same host-shadowing precondition from two sides.