📦 Install the shop

Two tracks. They do the same thing; pick the one that matches who is reading.

🧑 For people

Prerequisites: Node.js. Running the harness itself needs no install — the upstream-documented form is npx -y @deepseek-ai/dsh web. Plugin management goes through dsh plugin, which spawns both the dsh command and pnpm — install them once with npm install -g @deepseek-ai/dsh pnpm and verify with dsh --version and pnpm --version.

# dsh on PATH (global install). Pin the version: pnpm 11 holds back very
# recent releases, so a bare `add dsh-plugin-shop` can hand you an older
# version for a while. This is the current release — refresh it with
# `npm view dsh-plugin-shop version`.
dsh plugin --profile web add dsh-plugin-shop@0.8.2
# or straight through npx, nothing installed:
npx -y @deepseek-ai/dsh plugin --profile web add dsh-plugin-shop@0.8.2

Replace web with your profile if you use another one. Restart dsh once — a newly added bundle is not applied to a running process — then open

Settings → Plugins → Plugin shop

🤖 For agents

Non-interactive. --profile is mandatory; without it dsh plugin exits with error: required option '--profile <name>' not specified.

# 1. resolve a profile name ($DSH_HOME defaults to ~/.dsh; node_modules is not a profile)
ls -1 "${DSH_HOME:-$HOME/.dsh}/profiles" | grep -v '^node_modules$'

# 2. install — pin the version: it bypasses pnpm's release cooldown and
#    deterministic installs are the point of the agent path
dsh plugin --profile <profile> add dsh-plugin-shop@0.8.2

# 3. verify — a zero exit above only means pnpm resolved the package
dsh plugin --profile <profile> list --depth 0   # dsh-plugin-shop must appear

# 4. restart the profile; a new bundle is not hot-applied
dsh --profile <profile>

The same fact as step 3 lives in $DSH_HOME/profiles/<profile>/package.json under dsh.profile.bundles, if you would rather read the manifest than parse CLI output. Per-failure diagnostics are in the package README.

🖼️ Screenshots

Installing an unreviewed plugin requires an explicit acknowledgement	The same shelf in the dark theme

✨ Highlights

• 🌐 Whole-registry harvest — every npm package keyed dsh-plugin or deepseek-harness, plus every GitHub repository using them as topics. Nothing is submitted here; there is no queue to join.
• 🧹 Hard filtering — every candidate is gated mechanically on every build, and one that fails becomes a named rejection carrying one of seventeen recorded reasons, in words its author can read. The plugins and filtered badges above count both sides, live.
• 🔌 Dependency check on your machine — your installation resolves each recorded peer name against your own profile, the question dsh's loader asks at mount, so a card reads Incompatible only when the modules are really missing here.
• 🗓️ Daily rebuild — committed to git, so every change is a reviewable diff. A new plugin lands the next morning; a repository that disappears drops out the same way.
• 🗂️ Seven categories — an author who declares dsh.catalog picks their own; the rest are classified for them.

🗺️ How it fits together

In this repository — the daily build. Everything here is registry/.

flowchart TB
  subgraph HARVEST["1 · Harvest — the whole public registry, every day"]
    direction LR
    NPM(["npm packages<br/>keyword dsh-plugin<br/>keyword deepseek-harness"])
    GH(["GitHub repositories<br/>the same keywords,<br/>used as topics"])
  end

  subgraph GATE["2 · Gate — every candidate must clear all five, on every build"]
    direction LR
    G1["a plugin at all?<br/><br/>a dsh.bundle the<br/>loader can mount"]
    G2["auditable?<br/><br/>a license,<br/>a live repository"]
    G3["installable?<br/><br/>not deprecated on npm ·<br/>repo listings also need<br/>no build scripts and<br/>no workspace: deps"]
    G4["what it claims?<br/><br/>tarball integrity, publish time,<br/>not a near-miss of another name"]
    G5["anything to show?<br/><br/>a valid dsh.catalog,<br/>or an npm description"]
  end

  subgraph SHELVE["3 · Shelve — what the catalog records"]
    direction LR
    CAT["one of 7 categories"]
    PEER["the declared peer NAMES,<br/>never their version ranges"]
  end

  NPM --> G1
  GH --> G1
  G1 -.-> REJ
  G2 -.-> REJ
  G3 -.-> REJ
  G4 -.-> REJ
  G5 -.-> REJ
  REJ[["rejected — one author-readable reason per name"]]
  G5 ==>|"all five clear"| CAT
  PEER ==> PUB[["4 · Publish — content-addressed JSON, committed to git, then GitHub Pages and npm"]]

On your machine — the npm package. Everything here is packages/dsh-plugin-shop/. The two halves share no code, only the schema.

flowchart LR
  CAT[["the catalog<br/>index.json + plugins.sha256.json"]]
  CAT ==> HOST["5 · Host half<br/>races every origin<br/>verifies sha256 · caches"]
  HOST ==> DEP{"6 · Dependency check<br/>resolve each recorded peer<br/>against YOUR profile"}
  DEP -->|"one or more absent"| BAD["Incompatible<br/>the card names<br/>what is missing"]
  DEP -->|"all resolve"| GOOD["installable"]
  BAD --> CLIENT["Client half — the Settings tab<br/>nine shop/* methods<br/>no network · no filesystem"]
  GOOD --> CLIENT
  CLIENT ==>|"dsh plugin add"| PROF[("your dsh profile")]

Two parts are worth naming, because they are the ones people expect to work differently:

• The gate rejects; it never silently drops. Every candidate that fails becomes a named rejection with a reason, attached to the build.
• The dependency check is not a catalog fact. The build records only the peer names — never their version ranges, because nearly every dsh plugin declares "*" and the harness's own prereleases do not satisfy ordinary ranges, so checking them would accuse plugins that work. Whether a name resolves is decided by your installation, against your profile.

✅ What it is

🚫 What it is not

It is not a sandbox. A dsh plugin, once mounted, holds the full ctx — your filesystem, your shell, and the requests going to the model. Installing one is complete trust. This project does not change that; it tells you the truth before you click.

It also carries no download counts, ratings, or reviews, and it will never offer an "install from arbitrary URL" button. That capability stays in dsh plugin add, where enabling build scripts and pinning a commit are decisions you make explicitly.

📚 The catalog

Built daily and published as static JSON, to two places at once: the npm package dsh-plugin-shop-catalog and GitHub Pages. Your installation races them — the registry you have configured, npmmirror, npmjs, then Pages — and takes whichever answers first, because the link to one of them can be far slower than the link to another from where you sit. All of them carry the same bytes, and the sha256 in the pointer is checked before any of them is trusted. DSH_SHOP_CATALOG_URL opts out of the race and reads only what you name.

Each build's rejection report, carrying an author-readable reason for every rejected package, is attached to the workflow run. Nothing disappears without a reason attached to its name.

The data files are content-addressed, so each build publishes new names and the previous ones stop existing, while the pointer above them is cached for ten minutes. If you fetch /v1/ yourself, re-read index.json whenever a data URL answers 404 — or read the same bytes from the npm package dsh-plugin-shop-catalog, where the pointer and the data it names always ship in one tarball.

🏷️ Listing a plugin

Add a harvest keyword (dsh-plugin or deepseek-harness) to your package.json and publish to npm; the daily build picks it up. A plugin that never publishes to npm is listed from its GitHub repository instead: add the same keyword as a repo topic and keep a package.json at the root with a name and dsh.bundle — the catalog pins the default-branch commit as the version. A dsh.catalog section is optional — declare it to control your own category, summary and capabilities, or omit it and the catalog derives a listing from your npm description instead.

{
  "name": "dsh-hello-plugin",
  "keywords": ["dsh-plugin"],
  "dsh": {
    "bundle":  { "patch": "./cordis.patch.yml" },
    "catalog": {
      "category": "tool",
      "summary": { "en": "...", "zh": "..." },
      "capabilities": ["fs", "shell"]
    }
  }
}

Full field reference: docs/schema.md.

Not listed, and why: a package without dsh.bundle is a library rather than an installable plugin. A package without a license or a repository cannot be audited. A package with neither a dsh.catalog section nor an npm description has nothing to show.

🌾 Which packages are harvested?

The harvest reads declared keywords, never package names: dsh-plugin and deepseek-harness are the two it accepts, in npm keywords and as GitHub repo topics. cordis-plugin names the underlying framework, so it does not show that a package is an installable DSH bundle. The plugins that ship inside dsh are a separate matter: they declare no npm keywords at all, so no keyword choice would reach them.

If your community plugin is built on Cordis and integrates with DSH, declare one of those two keywords and put a dsh.bundle section where the harvest reads it: on the npm path, in the manifest of the package you publish; on the GitHub path, in the root package.json, which also needs a name, or, in a monorepo, in the subpackage that is the plugin. A reusable Cordis library with no dsh.bundle is a library rather than an installable plugin.

🗂️ Repository layout

🛠️ Development

pnpm install
pnpm test        # vitest
pnpm typecheck

pnpm build:catalog runs the real harvest against npm and GitHub — thousands of live requests and several minutes. The tests cover every policy decision without a network, so reach for it only when you have changed the fetching or writing layer.

Status and open work: docs/plans/2026-08-18-remaining-work.md. Specification: docs/design/2026-08-18-dsh-plugin-shop-design.md.

🤝 Contributing

Three ways in, cheapest first.

• Correct a verdict. Categories and competing-market judgements are made by a classifier, and the build report names every call it made with no human behind it. Fixing one is a single line of YAML — no network, no TypeScript, no local build.
• Get a plugin listed. Add a harvest keyword and publish. If the shelf still does not show it, that same report says why, per package, in terms written for the author.
• Change the pipeline. docs/design/ is the specification and the authority; CLAUDE.md is the working agreement.

All three in full: CONTRIBUTING.md. Be decent to each other: Code of Conduct. Vulnerabilities and malicious plugins go privately, never to a public issue.

📄 License

Apache-2.0 © LivXue