From string-concatenation to a real DSH bundle: one link, six verified plugins

A developer at DeepSeek Harness (DSH) replaced a fragile shell-command chain for bundling six plugins with a native profile-based approach, after discovering the original string concatenation had a URL bug causing all installs to fail. The new solution uses a single tarball with a profile manifest, resolving dependency issues and passing a Docker-based acceptance test.

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. DeepSeek Harness DSH has a precise vocabulary: dsh.bundle with a cordis.patch.yml layer. The patch rows reference packages by name, resolved through the profile's node modules. $DSH HOME/profiles/<name whose manifest dsh.profile lists an 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. blockExoticSubdeps. The first design was an aggregation package whose dependencies pointed at our own hosted tarballs. pnpm refused: URL dependencies are not allowed in sub dependencies. Moving the URLs to the profile's own dependencies folder 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. 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. 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.