Everything Is a Plugin: Announcement vs Source

The demo below turns the four plugin lists into a switchable panel. Hit the four mode buttons and watch cards light up or go dark: green means added, red means removed, amber means same name but different config. The caption at the bottom narrates each step. Play until it clicks — every idea later already ran once on this panel.

What problem it solves.Imagine a monolith Agent product where you want a different session-log format. You fork the repo, hunt the logging code across hundreds of thousands of lines, rebuild, then re-merge patches every upstream release. That’s just a side feature — swapping the agent loop is basically rewriting the product. Capabilities welded to product source turn every deep customization into long-term maintenance debt.

What the idea is.DSH shrinks the kernel to the minimum. The Cordis framework vendored into the repo does only three things: load plugins into a shared context, unload them, and record every registration as a reversible side effect that rolls back on unload. Zero business logic. Every capability moves into packages/ — 49 groups, 219 packages, all plugins: model adapters, tools, session logs, even the agent loop itself. Line 3 of the root AGENTS.md says in bold English “everything is a plugin.” The official docs put it this way:

You can add capabilities to DSH without touching its repo. Out-of-tree plugins (outside the official repo) install into a profile with dsh plugin --profile <name> add <package>, mount at runtime, and roll back registered side effects on unload. The README also asks plugin repos to tag the dsh-plugin topic so they’re discoverable. The launch post invites co-building the ecosystem — the mechanism is already there.

Why it lasts.The microkernel idea is older than this codebase. Mach and L4 from OS class, browser extension systems, VS Code’s plugin ecosystem — same path: fast-changing capabilities on the outer ring, nearly fixed load/unload mechanics in the core. If DSH rewrites the agent loop next year, Cordis’s load/unload logic doesn’t move a line; rewrite the whole harness in another language and the layering still holds. So remembering this course’s structure beats memorizing its code — the code is just one implementation of the idea.

What problem it solves.Most products hard-code modes: scattered branches like if (mode === 'lite'), with the mode count frozen the day the code is written. Adding a mode means change code, pass tests, wait for a release; tweaking one capability inside a mode is the same pipeline. Users get even less choice — pick among a few official packages.

What the idea is.In DSH a mode is a directory under apps/cli/config/agent-presets/ with two files. preset.yml is just 3 lines for UI display name and sort order; agent.cordis.yml is the plugin list — at boot Cordis mounts it line by line and outputs an assembled Agent. Switching modes means swapping lists and reassembling; there are no mode branches in source. The four-mode differences fit on four cards:

One marketing word to puncture. Line 1 of code/preset.yml says name: PTC 模式, but the directory is code; source comments and docs call the mechanism Code Mode, and there’s no PTC-named implementation anywhere in the repo. PTC lives only in UI copy — when you talk source, say Code Mode so it lines up.

Why it lasts.This idea has a common name: configuration as architecture. Fold behavioral differences between systems into a declarative list, and architecture problems shrink into text problems. Diff two YAMLs to see how modes differ; copy a directory and tweak a few lines for a new mode; roll back the list when things break. Kubernetes declares clusters in YAML, Docker declares images with Dockerfiles — same idea at different layers. Even if every DSH plugin implementation is rewritten someday, the list abstraction still holds.

Everything-is-a-plugin only clicks when you put peers beside it. Same question — add a new capability to an Agent, do you need to touch its repo source — three answers from three shops:

None of the three is absolutely better. Grok trades compile-time composition for Rust’s type and performance guarantees; Claude Code trades a monolith for product iteration speed; DSH trades a plugin tree for runtime swappability. If you want a replaceable, auditable runtime, DSH is the only one of the three that lets a third party replace deep capabilities without forking the repo.