Everything Is a Plugin—but Not Everything Is Public

DSH Desktop’s most consequential plugin decision is also its easiest to misunderstand: the desktop shell follows the same composition path as official and third-party DSH plugins, but it does not make every part of the native application available to them. This chapter explains how that boundary works in practice. The goal is to let a plugin author—or a reader evaluating the architecture—decide what should be required, what should remain optional, and what must never be inferred from a private Electron implementation.

A plugin system is useful only when it gives extensions a predictable place to connect. If every plugin can reach into every other plugin, “extensible” quickly becomes a different name for hidden coupling. DSH Desktop treats explicit services, declared dependencies, and known UI slots as the connective tissue of the product. The desktop shell is an equal participant in that arrangement, not a privileged application layered outside it.

The shell joins the composition path

DeepSeek Harness uses plugins to assemble capabilities such as models, tools, interfaces, and workflows. DSH Desktop keeps that principle for the parts that make a Harness runtime feel native: the shell contributes window and tray behavior, profile management, terminal access, updates, and presentation effects through Host and Client faces. The upstream Web UI remains in the composition rather than being copied into a separate Electron-native application.

That structure expresses three practical rules. Composition first means an extension adds behavior through an existing service, slot, or patch instead of overriding another extension’s internals. Declare clearly means the extension states which services or slots it needs, so the host can determine whether it can load and what has to be available first. Compatibility first means an upstream or Desktop change should not silently invalidate existing compositions. These are not abstract style preferences. They determine whether a failure can be assigned to a missing dependency, an incompatible composition, or a defect inside the extension itself.

The distinction between a Desktop-only plugin and a cross-environment plugin makes the rules concrete. A plugin that has no useful behavior outside DSH Desktop can declare the Desktop profile and package services as required dependencies. The composition framework can keep it pending until those providers exist, and unload its effects if a required provider disappears with the generation. That is an honest contract: the plugin is saying that ordinary DSH is not a supported environment for that feature.

A plugin that must also work in ordinary DSH should not put Desktop services in its top-level required dependencies. Instead, it can preserve its normal DSH implementation and detect whether the Desktop profile service is present. If it is, the plugin can create a nested adapter that waits for the package service and mounts Desktop-specific effects. If it is absent, the ordinary DSH path remains authoritative. This pattern matters because optionality is not the same as guessing. A cross-environment plugin should not assume that a profile named web is active, reconstruct the profile from a URL, or invoke an ambient command and hope that it reaches the same state Desktop selected.

Imagine a plugin that manages an extension package. Under ordinary DSH, it may use the upstream command semantics and a profile chosen by its own configuration. Under DSH Desktop, the same plugin can discover the active profile through the public service, request the packaged package-manager adapter, and bind its effects to that service’s lifetime.