DeepSeek Harness extension points: DSH plugin mechanism map

A DSH plugin feature is never attached at random: the official docs publish a feature-to-mechanism map that ties every product feature to a listener on a documented extension point, which is what makes the microkernel claim verifiable — no line edits the agent loop itself (source). This article turns that table into a searchable "I want X → attach at Y" handbook and explains the three-way ownership test; the three extension-point kinds (core / seam / bundle) are already covered in the site's DSH plugin core services and capability seams, so this article does not repeat them.

Why the DeepSeek Harness feature-to-mechanism map makes the microkernel verifiable

The official docs turn the microkernel claim into a checkable statement: every product feature maps to a listener on a documented extension point, so you can audit features one by one instead of trusting any "we changed one line in the loop" story (source). The cookbook further groups extensions into four extension patterns:

1. Tool plugin — registers on ctx.tools; defineTool is the typed helper, but raw JSON Schema works too (that is how MCP-sourced tools arrive).
2. Hook plugin — runs at interception points, illustrated by a permission gate (tools/pre-execute returns { kind: 'deny', reason } or calls next()); sandbox, permission, and plan-mode plugins reuse the same extension point.
3. UI plugin — renders from the session/event stream and drives input back with agent.followup() / agent.steer().
4. External protocol driver — bridges a protocol peer into ctx.agents, serving a UI or an automation client.

The four patterns are themselves a first answer: whichever pattern your plugin matches tells you the extension point it mainly attaches to.

The DeepSeek Harness feature-to-mechanism table

The official table lines product features up with plugin mechanisms, covering everything from the hook system to plugin hot reload (source). An excerpt:

Use it in reverse: write the feature name you want, find the plugin mechanism it maps to, then read that mechanism's detail doc. If there is no row for it, you are building a cohesive standalone domain service rather than attaching a listener to an existing extension point.

Extension-point ownership in a DSH plugin: the three-way test and self-checks

There is only one test — what are you replacing (source). In practice, four steps:

1. Replace the implementation of a capability — plug into an existing service seam such as ctx.llm, ctx.fs, ctx.shell, ctx.compaction, or ctx.sessionPersistence. Expect: zero changes to upper tools.
2. Extend a pipeline stage — add an event listener whose waterfall returns a typed decision; do not replace a spine service. Expect: a reversible, unloadable extension; see DSH plugin events.
3. Assemble a product form — pick a provider at the composition layer with composition packages and bundle points. Expect: swapping an implementation only touches the composition.
4. None of the above — implement it as a cohesive standalone domain service, such as a domain-scoped registry. Expect: no confusion with the spine or a seam.

Two official caveats are easy to miss: first, system-prompt/assemble is a collaborative whole-assembly transform whose returned result is authoritative, so listener authors are responsible for preserving the contributions of active Code Mode and structured output protocols; second, tool filtering that must keep display, lookup, and execution aligned should prefer ctx.tools.restrict() over maintaining your own visible set. Three self-checks after writing: does the feature really map to some extension point; did you mistake "extend the flow" for "replace an implementation"; and are all subscriptions and registrations kept inside apply so they roll back with the fiber. To compare community implementations on the same extension point, search the DSH Plugin Hub; for the three extension-point kinds see core services and capability seams, and for tool contract details see tool authoring.