dsh pm — the plugin manager DSH should have shipped with

dsh pm is the command group for DeepSeek Harness that closes the discovery → install → manage loop around the official dsh plugin flow: search the awesome list / GitHub topic / npm keyword, install from npm or GitHub with one command, list what's installed per profile, check for updates, and audit everything with doctor.

It is deliberately a thin, honest layer over the documented install mechanism: it never hand-edits a profile's cordis.yml. It drives dsh plugin --profile add|remove through the installer and records its own side-band state (a plain JSON file), so it can list, update, and audit — and if the official flow changes, one adapter changes, not four packages.

dsh pm search memory     →  discover
dsh pm install dsh-memory →  install into the configured profiles
dsh pm list               →  what pm installed, per profile
dsh pm update dsh-memory  →  reinstall if a newer version exists
dsh pm doctor             →  audit manifests, patches, sources, drift

Install

This package is the pm command group itself. Install it into the profile you run dsh pm … from:

dsh plugin --profile default add @dsh-pm/cli          # npm (when published)
dsh plugin --profile default add github:Jesse-njx/dsh-plugin-manager  # or: from the monorepo

Then invoke it:

dsh --profile default pm search memory
dsh --profile default pm install dsh-memory

The bundle patch also registers pm as a web-UI slash command (/pm search memory), so it works from the chat input as well.

Config

The config block is the PmConfig shape (spec §5.1), validated by the schemastery schema exported as Config. All fields have defaults; the block below shows the documented values:

# in the profile's cordis.patch.yml
- id: dsh-plugin-manager
  config:
    registry:
      awesomeUrl: https://raw.githubusercontent.com/awesome-dsh-plugin/awesome-dsh-plugin/main/README.md
      npmKeyword: dsh
    profiles: [default]        # which profiles install targets go into
    stateFile: ~/.dsh/pm/plugins.json
    gitInstall: { depth: 1, build: true }

Field	Default	Meaning
registry.awesomeUrl	the awesome-dsh-plugin README URL	discovery source 1
registry.npmKeyword	dsh	npm keyword search term
profiles	['default']	target profiles for install
stateFile	~/.dsh/pm/plugins.json	pm's own side-band state
gitInstall.depth / build	1 / true	passed to the installer for GitHub refs

Commands

Command	Behavior
dsh pm search	search the merged registry; table of name, source, stars, category, description
dsh pm install	resolve and install into the configured profiles; prints resulting rows
dsh pm remove	uninstall from every profile the state mentions
dsh pm list	state rows grouped per profile: version, source, enabled, last checked
dsh pm update [name|all]	check latest (npm dist-tag or GitHub HEAD); reinstall when newer
dsh pm doctor	read-only audit; exits non-zero when any finding is an error

Doctor

dsh pm doctor audits every installed plugin:

• (a) the manifest still parses (ManifestParser),
• (b) its dsh.bundle.patch file resolves on disk,
• (c) its repo/npm source is still reachable,
• (d) version drift (installed vs latest),
• (e) duplicates / conflicting entries across profiles,
• (f) unmanaged plugins present in a profile but absent from the state store,
• (g) registry reachability overall.

Doctor is read-only: it reports ok / warn / error findings with a one-line fix hint and tells you the exact dsh pm command to run — it never repairs.

How it works

dsh pm install 
  → @dsh-pm/installer resolves the source (npm / github / registry)
  → run seam shells: dsh plugin --profile 
 add 
  → @dsh-pm/core StateStore records the row (atomic temp+rename JSON)
dsh pm list
  → installer.list() reads the state store

@dsh-pm/cli is the only package that imports all three siblings (core, registry, installer); it wires them together per the frozen cross-package contract in spec §5.

Development

pnpm install
pnpm --filter @dsh-pm/cli build      # tsc → lib/
pnpm --filter @dsh-pm/cli typecheck  # tsc --noEmit (src + tests)
pnpm --filter @dsh-pm/cli test       # node --test test/*.test.ts

Unit tests cover command registration on a real Cordis ctx.commands (register/dispose restores the stock surface), output-rendering goldens, and doctor exit-code behavior over fake store + registry. The cross-package flow (real installer + real dsh CLI against a temp DSH_HOME) lives in the integration-test package.

License

MIT