Building a Small Personal Plugin Stack (Tools, Runtime, UI)

Once you can install a bundle and you know the security defaults you refuse to violate, the next failure mode is collecting plugins like browser extensions. This note sketches a small personal stack for DeepSeek Harness: enough to make the agent useful on your machine, not enough to turn every Discover listing into a dependency.

The bias throughout is deliberate under-installation. You can always add a fourth plugin next week. Removing a tangle of half-configured runtime packages is the expensive direction.

Draw the minimum useful stack first

Ignore brand names for a minute and pick roles:

1. Retrieval or memory. Something that helps the agent find your notes, repo facts, or prior decisions without pasting megabytes into the prompt by hand.
2. Notification or outbound channel. A narrow way to ping you when a long job finishes—chat, email bridge, or desktop notice—without giving the agent a general-purpose spam cannon.
3. Spend / quota visibility. A UI or tool that makes token and dollar burn obvious. Silent cost is how playgrounds become invoices.

Community indexes often sort packages into rough buckets such as tools (model-callable), runtime (reshape harness services), and ui (human-facing panels). Use those labels as shopping filters, not as moral categories. A “ui” plugin can still ship powerful host code. A “tools” plugin can still open network sockets you did not expect.

Write the three roles on paper before you open Discover. If a candidate does not map to a role, it waits.

Tools vs runtime vs UI

Layer	Who notices	What changes	Default caution
Tools	The model	Callable schemas and side effects the agent may request	Medium — still review shell/network
Runtime	The host	Services, policies, adapters, persistence, orchestration	High — rewrites the rules
UI	You	Panels, discoverability, controls, status	Medium — verify it is only UI

A healthy stack usually has more restraint at the runtime layer than at the tool layer. Runtime plugins rewrite the rules of the game; tools add moves inside those rules. UI plugins should make the rules legible—not smuggle new privileged services without saying so. When a README is vague about which layer it occupies, read the Cordis inserts before you install.

Minimum plugin shape (recap)

When you eventually write your own instead of only installing, the public Cordis tutorial pattern still holds:

export const name = 'greeter'

export function apply(ctx) {
  // register reversible effects on ctx
}

Pair that with the Cordis / Harness config row that inserts your package into the tree. Official “first plugin” tutorials walk the exact file layout; do not invent a parallel loader. The point of Harness is that your plugin looks like the ones DeepSeek already ships.

For local iteration, start in repository mode against a subpath, keep the patch file in git, and only cut a bundle when someone else needs a one-line install. That sequence matches the previous note’s selection guide and keeps your early mistakes off other people’s machines.

Maintain an allowlist, not a wishlist

Practical maintenance beats clever architecture:

• Pin commits or versions for every non-official package.
• Dump config on a schedule—after installs, before upgrades, and when something “feels off.”
• Read changelogs for permission expansions, not only for features.
• Remove aggressively. A plugin you used once for a demo is still code in your host.
• Record why. One line in a NOTES.md beats archaeology three months later.

mkdir -p ~/dsh-dumps
dsh --profile web --dump-config > ~/dsh-dumps/web-$(date +%F).txt
diff -u ~/dsh-dumps/web-yesterday.txt ~/dsh-dumps/web-$(date +%F).txt

That diff is often more informative than memory. Unexpected new rows after an “unrelated” upgrade are your cue to stop and read before you keep working.

Optional: a personal plugin index

Some community workflows now point Discover at a custom static index: a small JSON/YAML list of packages you already trust, with versions and notes. Useful when you bounce between machines or teammates. Keep the ambition low. An index is a bookmark list with structure—not a private app store with implied review.

If you publish an index, say what it is not: no security guarantees, no SLA, pins may lag. Honesty keeps readers from treating your gist like DeepSeek’s signature.

Preview-era mindset

DeepSeek Harness remains in developer preview. Compatibility will break. The stack that survives is the one you can rebuild from pins and a checked-in patch file, not the one that depends on a snowflake machine. Prefer reversible composition: if a Tuesday upgrade ruins Thursday’s muscle memory, you should be able to unload the offender and boot yesterday’s tree.

Budget time for upgrades the way you budget time for dependency updates in any serious Node project. Skimming three changelogs is cheaper than debugging a profile that silently dropped a service your tools inject.

Closing the series

Across these five notes we covered the product shape, a first install afternoon, bundle versus repository choice, security posture from public 2026 discussions, and a deliberately small personal stack. Official sources remain authoritative: the Harness repository, product docs, plugin guides, and safety notices. This site is a set of working notes for people wiring plugins into Cordis trees—not a marketplace, not a VPN page, and not an official DeepSeek property.

If you take one habit from the series, take dump-config before and after every install. The tree does not lie as often as memory does.