dsh-std

DSH Standard

English | 中文

In plain terms, DSH Standard is a set of universal interoperability protocols. Its goal is simple: let DSH plugins, background runtimes, and various user interfaces (TUI terminals, Web UIs, desktop apps, headless daemons) decouple cleanly and work together smoothly.

@dsh-std/core is a "meta-protocol" (the protocol about protocols). Domain-specific protocols—like Command, Tool, Model, and Presentation—sit on top of this meta-protocol substrate for discovery and negotiation, each versioned independently. Different hosts and applications only implement the parts they actually need.

Reference packages provide types, validators, and pure-function negotiators. Conforming implementations are not required to depend on these npm packages, nor do they need to run inside DeepSeek Harness. What is a "Meta-protocol" (The Protocol About Protocols)?

Most protocols you deal with handle specific domain tasks: A Command protocol handles how commands are registered and executed; A Model protocol governs how LLM providers are plugged in; A Presentation protocol handles UI dialogs, questions, and approvals.

In contrast, @dsh-std/core knows zero domain business fields (it doesn't even know what a command or a model is). It is purely the "protocol about protocols": It defines universal primitives: how protocols are identified (apiVersion + kind), how participants declare what they need (requires) and what they provide (supports), and how to run pure-function negotiations to output a structured compatibility report. An analogy: It works like the USB interface specification. The core only cares about physical pinouts, slot dimensions, and handshake negotiation. Whether you plug in a mouse, keyboard, thumb drive, or webcam, the core never needs to know or change.

Why is this powerful? Monolithic frameworks hardcode every capability (commands, storage, events) into a central SDK; whenever a new domain arises, the entire framework requires a release or a breaking change. Under a meta-protocol architecture, the protocols themselves are pluggable plugins: public standards, community extensions, and private protocols alike register as standalone protocol definitions. The core never changes, letting the ecosystem evolve boundlessly on its own. Why Decouple via Adapters?

The upstream DSH core and downstream ecosystem plugins have inherently different engineering priorities: Upstream DSH focuses on rapid innovation: Its mission is to build the fastest, most capable Agent execution engine, requiring frequent iteration over model scheduling, context engineering, and internal architecture. The core should not have its hands tied by external UI variations or third-party interop standards. Downstream plugins need stable contracts: Plugin authors want to focus on feature logic without worrying that their code will break with every upstream update.

Adapter functions and implementation An adapter maps internal product services to the standard protocols the product adopts. Reusable adapters can reduce repeated product API integration work for third-party plugins. Each project can design its own adapter or use an existing implementation.

Third-party plugins target the protocol contracts they adopt; adapter internals and package names are not a shared entrypoint. @dsh-std/adapter-dsh provides a set of mappings for DeepSeek Harness. TUIs, Web frontends, remote runners, and other integrators can provide their own implementations. Compatibility depends on protocol versions, live capabilities, and product mappings. What else is great about this (Beyond stable dependencies)?

Separating protocol contracts from product implementations supports the following development patterns: Less repeated platform integration: Plugins can reuse business logic that follows protocol contracts, while each product's mappings connect it to local capabilities. On-Demand Activation & Zero Leaks (Facet model): A single plugin package can contain both frontend