DeepSeek Harness · 1 of 6
Everything is a plugin
DeepSeek Harness puts its replaceable parts inside one composition model. The model adapter, tool registry, session log, loop, policies, and product surfaces are peers in a Cordis plugin tree.
§1
Read the version warning first
At the pinned revision, the repository calls DeepSeek Harness a developer preview and says compatibility-breaking changes will occur. Treat every package, type, and lifecycle claim in this extension as a description of commit 47f9438…, not a permanent API promise. Source · README 5–11
§2
The Cordis rule
Cordis gives plugins a shared context into which they contribute named services, typed events, and reversible effects. DeepSeek’s architecture document says every product part is a plugin, including the model adapter, tool registry, session log, and agent loop. Extension happens by mounting composition beside existing plugins rather than patching a privileged core. Source · architecture 9–35
A service is a contract published on the context, such as ctx.sessions, ctx.tools, or ctx.llm. An event is a typed coordination point. An effect is registration or work with a disposer, so unloading a plugin can unwind what it installed. This lifecycle is why “plugin” means more than a folder of optional code.
A Cordis context also defines visibility and lifetime. Per-agent composition can create scoped registrations without changing the host-wide registry. Fibers/effects let the host dispose a subtree coherently. Replacement, scope, and cleanup all use the same composition grammar.
§3
Profiles and bundles build the running tree
A profile names an ordered composition; bundles contribute configuration rows and the code those rows mount. Base services arrive first, then product bundles such as web or headless, followed by profile, home, and command-line patch layers. A later patch can replace a row by ID or insert another row. Source · profiles and bundles
empty plugin tree
→ base bundle: model adapters, tools, persistence, sandbox, approval
→ product bundle: web UI or headless runner
→ profile patch
→ home patch
→ command-line overlay
The useful debugging artifact is the resolved tree, not any one source configuration. The documented dsh --profile web --dump-config command shows what the selected layers actually boot.
§4
The common anatomy inside the tree
| Harness role | DeepSeek package/service | Composition meaning |
|---|---|---|
| Session state | core/session · ctx.sessions | Append-only events and the in-memory session surface. |
| Prompt assembly | core/system-prompt · ctx.systemPrompt | Plugins register prompt sections and tool-schema contributions. |
| Tool effect edge | core/tools · ctx.tools | Scoped registry plus guarded execution stages. |
| Live agent contract | core/agent · ctx.agents | Agent interface, registry, inbox/status events. |
| Default control loop | core/agent-loop · ctx.agentLoop | One provider of the agent-driving contract. |
| Model boundary | llm/llm · ctx.llm | Message/stream vocabulary and provider-adapter seam. |
The architecture documentation explicitly lists these as separate core packages and services. Their presence in one bundle does not erase their contracts; their separation allows another composition to replace a provider or omit a product surface. Source · core packages
§5
Three event domains keep different promises
Session events are durable facts intended to survive reload. Agent events coordinate live work such as inbox claims, request interception, and stopping. Capability events let policy and adapters attach to a seam without importing the loop.
This division prevents a live callback from being mistaken for a durable record. A UI that needs replayable transcript facts should consume session events; an extension that wants to rewrite the next step belongs on the live agent waterfall. Source · event domains
§6
A capability seam has three roles
DeepSeek defines a swappable capability through a service definition, one or more service providers, and a consumer. A filesystem seam, for example, needs an interface, an implementation, and callers such as tools; a lone tool wrapper is not the whole seam. Source · seam definition
The benefit is system-wide substitution. If shell, PTY, and language-server consumers share the same filesystem/subprocess world, swapping the provider can move them together into a remote sandbox. The cost is design work: every seam needs interface semantics, provider lifecycle, selection rules, failure behavior, and consumers that do not reach around it.