@hubaking/dsh-community-plugins

dsh-community-plugins

A DeepSeek Harness (dsh) plugin that teaches agents how to discover, evaluate and install community plugins — and gives them two tools to check those plugins against the dsh build actually running on this machine: one that stays offline, and one that fetches a package before it is installed.

English · 中文

---

This bundle adds three things to every session:

1. A skill (dsh-community-plugins) — how to find plugins through the GitHub dsh-plugin topic, curated indexes and npm; how to vet one before installing; how to install through the official dsh plugin mechanism; how to verify the result.
2. An offline tool (dsh_plugin_audit) — compares installed plugins against this machine's dsh build and reports, per plugin, what is broken, what is merely risky, and what could not be determined. It fetches nothing.
3. A networked tool (dsh_plugin_inspect) — downloads a package's published tarball, verifies it against the registry's published hash, unpacks it into a temporary directory, and judges it before it is installed. It never installs anything and never runs the package's lifecycle scripts.

The two tools are separate on purpose. The audit's promise is that it touches no network; a flag that sometimes made it fetch would make the promise conditional, and a conditional promise is not one. Two tools, two guarantees, and each says which one it is.

Why this plugin

DeepSeek Harness provides plugin capabilities through two complementary mechanisms: Tools and Skills.

	Tool (e.g. market_search)	Skill (registered by this plugin)
Nature	Capability channel: callable functions	Context knowledge: when, why, and how to call
Effect alone	Tool exists, but the agent does not recognize it	No marketplace interface to call

A marketplace tool alone is not enough, because agent behavior is driven by context knowledge. web_search has an intuitive description and is any model's default approach; market_search is DSH-specific. Without this skill the agent does not know it exists, does not associate it with installing plugins, and does not understand the local profile layout, the bundle mechanism, the vetting workflow, or the restart requirement.

And knowledge alone is not enough either: the ecosystem's one hard practical question — "will upgrading dsh break what I have installed?" — cannot be answered reliably by hand, because the rc-prerelease rule below defeats eyeballing.

Why a live probe instead of a compatibility dataset

Upstream declares the API surface unstable on purpose:

• README.md — "THERE WILL BE COMPATIBILITY-BREAKING CHANGES."
• AGENTS.md — "Public APIs are pre-stable; update every consumer."

A cached snapshot of that API surface therefore starts decaying the moment it is written. Measured here: 16 0.x prereleases in one month — roughly one breaking change a week. A dataset would need continuous maintenance and would be wrong between updates, and a verification tool that is confidently wrong is worse than no tool at all.

So this plugin stores nothing. dsh_plugin_audit reads the dsh install root and the profile on every call and answers for this machine, right now; dsh_plugin_inspect reads the tarball it just downloaded and answers against that same build. No telemetry, no cache, no data to keep fresh — and when something genuinely cannot be checked, both say unknown and give the reason instead of guessing.

This is the difference from the ~75 marketplace plugins, the 3+ static auditors already in the ecosystem, and even the official runtime inspector: those list, rank, scan for security, or describe what is live right now. None compare a plugin's declared ranges and actual API usage against your dsh build, and none can do it for a plugin that is not installed yet.

Complementary to the official runtime inspector. @deepseek-ai/dsh-tool-cordis ships cordis_inspect_*, which queries the live runtime exactly (Service.listService, Event.listEvents, Tool.listTools, and Slots.listSubTree for real client-side slot props). For "what does the runtime look like right now", that is strictly the better tool. This plugin answers a different question — "do the declarations on disk still line up with the build installed here" — and it still works where the inspector cannot: a plugin that failed to load is not in the live runtime, so the inspector cannot see it at all. Static inspection reads the disk; the inspector reads the process. Both are needed.

Neither predicts a future upgrade. Both only ever see the build installed on this machine; the honest answer to "what will break after I upgrade" is to run them again after upgrading.

The offline audit tool

dsh_plugin_audit({})                                  # every third-party plugin in the profile
dsh_plugin_audit({ target: 'dsh-llm-local-token' })   # one package (name or directory)

Per plugin it reports:

Check	Source of truth
Can its bundle layer be mounted?	whether dsh.bundle.patch exists on disk, and whether the package is named in dsh.profile.bundles
peerDependencies ranges satisfied?	the version of each package actually on this machine, including vendor/
Imported @deepseek-ai/* packages still exist?	the dsh install root (packages/, vendor/, node_modules/@deepseek-ai)
Are the named exports those imports need still exported?	the package's declaration entry, walked through export * re-exports, unioned with its runtime entry
Registered client slots still defined?	slot contracts extracted from official packages/client + packages/core source
inject service names resolvable?	the live Cordis context
Install-time risk signals?	npm lifecycle scripts, child_process, eval, remote import, network

Verdicts are graded, not binary:

Verdict	Meaning
compatible	every check this tool can perform passed
at-risk	a declared range no longer matches or its layer is not composed in, though the code may still run — the normal state of this ecosystem
incompatible	hard evidence: a package, export or slot it needs is gone from this build, or its bundle layer cannot be mounted
unknown	something needed a check that cannot be done offline; the reason is always stated

Symbol-level checking, and why "the package still exists" is not enough

A plugin that does import { PiAiAdapter } from '@deepseek-ai/dsh-llm' keeps working only while that package still exports PiAiAdapter. A rename or a split leaves the package in place and the binding gone — and an ESM named import of a binding the module does not provide is a link-time throw, not a degraded feature.

Confirming that is harder than grepping one file, because a package's export surface is a graph. Official declarations are barrels, and TypeScript emits the source extension:

export * from './attribution.ts';          // the file shipped beside it is attribution.d.ts
export { BlockAssembler } from './assembler.ts';

A single-file scan reports every re-exported symbol as missing. So the check walks the graph — relative specifiers, the .ts/.js → .d.ts mapping, bare specifiers into other packages — and keeps two things strictly apart:

• the set of symbols it confirmed, and
• whether that set is complete.

Only a complete graph licenses the word removed. An incomplete one yields unknown, because "I could not resolve it" is not "it is gone". The declared-type surface is unioned with the runtime entry's own export list, so a stale declaration cannot manufacture a failure.

Validated on this machine (2026-09, dsh 0.1.5-rc.1): 279 official packages inspected, 276 declaration graphs resolved completely, 1,874 runtime export names checked, 0 unconfirmed. The three incomplete graphs are reported as unknown, never as removals. The suite re-runs this sweep on whatever machine it is run on.

A bad plugin can stop dsh from booting

This is why the layer check comes first. Three of these throw rather than degrade, so the whole profile fails to start:

Situation	Upstream behaviour
Declares dsh.bundle.patch but the package does not contain that file	failed to read overlay — throws (packages/boot/app-boot/src/index.ts:315-323)
Declares dsh.bundle with no patch path	declares no dsh.bundle — throws (packages/boot/app-boot/src/profile.ts:792-797)
dsh.profile.bundles names a package that cannot be resolved	layer resolution fails — throws (same file)

And one that fails silently: a readable patch whose package is not in dsh.profile.bundles — the layer is never applied, so the plugin does nothing at all. The usual cause is installing with pnpm add inside the profile instead of dsh plugin add, which is what reconciles that list (apps/cli/src/plugin.ts:59-91).

The tool prints one layer … line per plugin and raises the rest as blockers, so you can see all of this before restarting dsh. These particular judgements are exact — they read package.json and the filesystem, not source heuristics.

The rc-prerelease trap this exists to catch

^0.1.0-rc.5 expands to >=0.1.0-rc.5 ⚠️ **Always use the @hubaking/scope for the npm form.** The unscoped namedsh-community-plugins on npm belongs to a **different project** ([funcodingdev/dsh-community-plugins](https://github.com/funcodingdev/dsh-community-plugins), TypeScript, with build scripts), so dsh plugin add dsh-community-plugins` silently installs that other package.

⚠️ The scoped package is not on npm yet. dsh plugin add @hubaking/dsh-community-plugins returns 404 as of 2026-09; the release workflow publishes it on a v* tag once NPM_TOKEN is configured. Use one of