# From string-concatenation to a real DSH bundle: one link, six verified plugins > Source: > Published: 2026-08-30 06:53:46+00:00 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/` 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.