dsh-plugins

DSH Plugins

A collection of plugins for DeepSeek Harness (DSH). Each plugin lives in its own package under packages/ and is installed into a DSH profile independently.

How a plugin is put together

A DSH plugin is a package with up to two halves:

• A host half (the package's main entry) runs inside the Harness server process. It can register HTTP routes on the Harness web server, shell out, and read local files — everything a browser cannot do.
• A client half (the ./client export) is a browser bundle registered through window.__ModuleLoader__.load. It renders React components into the shell's slot system and talks to its own host half over same-origin fetch.

The split is why a plugin can show local data (git, CLI tools, filesystem) in the browser without exposing credentials to it. packages/workboard is a worked example of the whole shape: a /workboard route family on the host side and a slot registration on the client side.

The package manifest declares which half is which:

{
  "dsh": {
    "client": {
      "platform": "web",
      "inject": ["@deepseek-ai/dsh-client-runtime", "@deepseek-ai/dsh-client-ui-layout"]
    }
  }
}

Installing a plugin into a profile

DSH profiles live under $DSH_HOME/profiles/<name> (by default ~/.dsh/profiles). A profile is a package that depends on the plugins it uses and a cordis.patch.yml that lists them.

Through the built-in installer

Every package here declares dsh.bundle, so DSH's own plugin manager can install it: open Plugins in the Web sidebar, choose Add plugin, and paste the package's Git address. The same operation is on the CLI:

dsh plugin --profile <name> add "github:virgoC0der/dsh-plugins#path:/packages/workboard"
dsh plugin --profile <name> add "github:virgoC0der/dsh-plugins#path:/packages/browser"

#path: is pnpm's subdirectory form, which is what makes a monorepo package installable by address. The manager adds the dependency, selects the bundle, and recomposes a live profile; a browser refresh is enough afterwards.

The package's own cordis.patch.yml is the bundle layer, so nothing has to be added to the profile by hand. A plugin installed this way is managed from the Plugins page — switch it off, or uninstall it, from there.

By hand, from a local checkout

The manual route stays the one to use while developing a plugin: it installs by link, so an edit is picked up without reinstalling.

1. Add the package as a dependency of the profile. A local checkout installs by link, which is what makes development against it practical:

   // ~/.dsh/profiles/web/package.json
   {
     "dependencies": {
       "dsh-workboard": "link:/absolute/path/to/dsh-plugins/packages/workboard"
     }
   }
   

   cd ~/.dsh/profiles/web && pnpm install
   

2. Add it to the profile's patch layer:

   # ~/.dsh/profiles/web/cordis.patch.yml
   - insert:
       - id: dsh-workboard
         name: dsh-workboard
   

3. Restart the Harness web server. Route registration and the boot graph are computed at startup, so a new host half needs a restart; after that a browser refresh is enough for client-half changes.

Each package's own README covers its configuration, its routes, and how to verify it.

Repository layout

Development

There is no root build step: each plugin ships its host entry and client bundle as plain ESM, so the repository is consumed directly through the profile link above. Type-checking, linting, and bundling are each plugin's own concern.

Verification here is expected to be empirical rather than assumed. The workboard plugin carries scripts that drive the real GUI in a real browser over the Chrome DevTools Protocol, using a browser binary its dependencies already put on disk and Node's global WebSocket — so nothing extra has to be installed:

cd packages/workboard
node scripts/probe-routes.mjs      # every host route, without restarting the Harness
node scripts/verify-ui.mjs         # geometry, overlap, folding, placement — in the running GUI

License

MIT — see LICENSE.