@1e0zj/dsh-plugin-mall

dsh-plugin-mall

An open plugin marketplace for DeepSeek Harness (dsh): search every GitHub repo tagged topic:dsh-plugin, automatically verify which ones are real dsh plugins, install and update with one click.

[中文说明](#中文说明) · [Install](#install) · [Why another marketplace](#why-another-marketplace) · [Roadmap](ROADMAP.md)

Two surfaces: a Settings → Plugins → Marketplace tab in the dsh web UI, and five agent tools usable from any session.

Why another marketplace?

Curated lists only show what has been reviewed and merged. This marketplace is open by construction: any repo tagged topic:dsh-plugin is discoverable the moment it is pushed — no submission, no approval queue. To keep that openness usable:

• Automatic verification — every search result's package.json is fetched (jsDelivr/raw dual-source CDN, no API quota) and checked for the official dsh.bundle / dsh.client manifest. Verified plugins get a green badge; the default "verified only" view filters out ~73% of topic noise (empty repos and unrelated projects riding the tag).
• Browse-time compatibility badges — each card is also statically scanned against your profile before you click anything: declared conflicts, exclusive groups, loader-id collisions (from the repo's patch file), rows the candidate's patch would switch off or reconfigure in the profile you already run, host-module shadowing, and peer/Node/OS ranges. Cards show 适配 / 有风险 / 冲突 / 适配未知 accordingly — advisory only; the install preflight remains the enforcing gate.
• Anti-squatting — an install prefers the npm tarball only when the registry entry's repository URL points back to the same GitHub repo; anything else falls back to the explicit github: spec.
• npm-first installs — registry tarballs are smaller than whole-repo GitHub downloads and come with integrity checks. Lookups follow the registry pnpm actually installs from (profile .npmrc → pnpm config get registry → npmjs), so a mirror user keeps npm-first instead of silently falling back to whole-repo clones.
• Update management — installed plugins are compared against the registry latest; one-click update per plugin.
• Conflict guard — every install runs an isolated preflight first: the candidate is installed with scripts disabled into a throwaway directory and scanned against the live profile for loader-id collisions, double mounts, host-module shadowing and version/OS/peer ranges. A patch layer is not read entry by entry but composed the way the loader applies it — the profile is assembled with and without the candidate's layer, in the position dsh would apply it, and the two trees are diffed. That composition is checked against the loader's own applyEntryPatches on every test run, over fixed shapes and 300 generated patch combinations, so "what dsh would boot" is not a guess. What gets reported is what would actually change: disabling, re-enabling or replacing the config of someone else's rows warns and names them, past ten such rows the candidate is a rival composition rather than an addition and is blocked, and a bundle that is itself another front door (own bin, terminal peers, no browser half) is blocked once it switches rows on or off or rewrites a protection row — the fingerprint corroborates, it never blocks on its own. A hard conflict is blocked, warnings require explicit confirmation. The profile's load-bearing files are snapshotted before pnpm touches them and restored on failure. A pending install is resolved on the next start, however you start it: this plugin runs recovery as it loads, which only happens because dsh booted far enough to compose the profile. Starting through guard launch adds a grace window on top, so a plugin that boots and then crashes seconds later is rolled back and restarted once (see [Startup protection](#startup-protection-guard-cli)).
• Resilience — rate-limit circuit breaker, GitHub's 1000-result search window handled gracefully, corepack enable pnpm self-heal when pnpm is missing, one-click dsh restart (loopback-only, allowRestart: false to disable). The outgoing Host exits only after the on-disk helper explicitly acknowledges the current handoff protocol and stays alive through a stability window; a missing, stale or incompatible helper leaves the existing Web service running. The successor then waits for the outgoing host to be gone before it binds — starting into an occupied port would read as "the pending plugin crashed dsh" and roll back an install that was fine. On Windows started from an interactive terminal, the restart runs in a visible console window (cmd /c start; the wrapped argv travels as a JSON plan file, never through the cmd command line): output is teed to the window and to the log, and closing the window terminates the whole guard/dsh tree (the close event bypasses console input processing entirely, so it always works). Ctrl+C in the window is honored best-effort — live testing showed a component inside dsh can flip the console into raw mode, after which no process on that console receives Ctrl+C at all; closing the window is the reliable stop. Service/scheduled-task/TTY-less Windows and every other platform keep the fully background behavior — no stray console, no re-opened browser (the page that asked is still there and reconnects on its own); whatever the restart prints lands in <home>/guard/restart-<profile>.log.

Install

# from npm
dsh plugin --profile web add @1e0zj/dsh-plugin-mall

# from GitHub
dsh plugin --profile web add github:1e0zj/dsh-plugin-mall

# local development — currently unusable, see the note below
dsh plugin --profile web add link:C:\path\to\dsh-plugin-mall

Restart dsh after installing.

link: cannot be set up right now, for reasons upstream of this plugin. Under

link: Node loads from the project's real path, so bare imports must resolve from

the project's ow

…(truncated)