Every plugin store ends up doing the same thing eventually: bundling. "Install these six together." The naive implementation is a shell-command chain — six dsh plugin add calls joined by &&. I shipped exactly that. Then someone pointed out it was not a bundle at all; it was a very long string. And the string had a bug in it: the URLs contained a double slash, so every single one of the six installs 404'd. The "one-click bundle" was, in fact, a one-click failure.
The lesson was old: if you ship a command, test the command. But the deeper lesson was newer: read the platform's own docs before designing your own format.
What DSH actually calls a bundle
DeepSeek Harness (DSH) has a precise vocabulary:
- A plugin bundle is an npm package that declares
dsh.bundlewith acordis.patch.ymllayer. The patch rows reference packages by name, resolved through the profile's node_modules. - A profile is a directory at
$DSH_HOME/profiles/<name>whose manifest (dsh.profile) lists an ordered set of bundles plus dependencies. The profile is the composition; the bundles are the parts.
So "six plugins in one link" has a native answer: ship a profile. One tarball, one profiles/consensus directory, one profile manifest that lists the six member bundles. The user unpacks it, runs dsh plugin --profile consensus install, and starts dsh --profile consensus. Six plugins, one link — no shell string concatenation in sight.
Three real obstacles we hit building it
blockExoticSubdeps. The first design was an aggregation package whosedependenciespointed at our own hosted tarballs. pnpm refused: URL dependencies are not allowed in *sub*dependencies. Moving the URLs to the profile's owndependenciesfolder worked — a profile's direct dependencies are top-level, and exotic (URL) dependencies are legal there. This is the difference between "bundle that depends on URLs" (blocked) and "profile that lists URL deps" (fine).Member health audit. One of the six members had a peer-dependency range (
@deepseek-ai/dsh-workflow@^0.0.1) with no matching published version. The install failed with a confusing pnpm error. The fix wasn't technical — it was selection: audit every member's dependency/peer declarations before assembling, and swap members whose upstream deps are broken. Now "member health" is a mandatory step in our bundle assembler: we check not just "is this plugin verified?" but "can its declared dependencies actually resolve?"The reviewer rule had to grow up. Our own submission reviewer rejected the aggregated bundle: "patch loads foreign package." That rule was written to stop undeclared cross-package references — a real security boundary. But DSH's official aggregate bundles legally reference declared dependencies. So the rule evolved: a patch may load its own name or any package declared in
dependencies. Undeclared foreign loads are still blocked. The security boundary survived; the false positive didn't.
Proof, not promises
The acceptance test: inside a Docker sandbox, unpack the profile, run install, dump the resolved composition. Output: six plugin rows — genui, agent-teams, dsh-context, telemetry-redactor, memento, dsh-annotation — all loaded, all from one link. The profile tarball is 417 bytes; the real work was reading the docs and auditing dependencies.
The meta-lesson
Shipping features fast is easy. Shipping the right shape is harder, and the shape comes from the platform's own vocabulary, not from what looks convenient in a template string. When you can, read the docs; when you can't, test until the platform tells you the truth. blockExoticSubdeps and the "no matching version" failure were the docs we didn't read first, delivered as error messages. The next store that ships a bundle should ask: what is the platform's native notion of a set? The answer was already there.
