Composability as a Product Discipline

DSH Desktop answers the opening question—how can a native application add control without becoming a forked replacement for DeepSeek Harness?—with a conditional answer. It keeps the upstream runtime and Web client authoritative, makes the desktop shell an ordinary plugin on the same composition path, and treats each running arrangement as a generation with explicit contracts and health boundaries. The useful final judgment is therefore not whether DSH Desktop is “modular” in the abstract, but whether its ownership rules remain clear enough for users, plugin authors, and maintainers to work within them.

That judgment matters beyond one Electron application. A composable agent runtime concentrates several kinds of power in one place: it can load code, invoke tools, manage sessions, reach model providers, and operate on a local workspace. Turning such a runtime into a desktop product adds another layer of power through windows, processes, installers, and network access. The risk is not simply that the codebase becomes large. It is that one layer quietly assumes authority over another, until a visual convenience can change a profile, a package operation can rewrite the live runtime, or a local access decision is mistaken for authentication.

The product works by keeping authority separate

The strongest design choice in DSH Desktop is negative: it does not rebuild the things it can preserve. The pinned DeepSeek Harness runtime continues to own agents, models, tools, sessions, and Web-client behavior. The shared HTTP/WebSocket carrier continues to connect Host and Client. The official Web UI remains part of the composition, and third-party DSH plugins continue to use ordinary services, routes, client metadata, and slots. Electron supplies the native entry point and the surrounding lifecycle rather than becoming a competing agent platform.

This separation gives the product a recognizable center. A user who moves from a command-line or ordinary Web profile into DSH Desktop is still operating DSH profiles and plugins, not a parallel data model that happens to resemble them. The desktop adds a window, tray, terminal, update flow, profile selection, and recovery surfaces, but those additions are framed as ways to enter and manage the Harness. That is why the project can be useful while remaining an independent community effort rather than an official DeepSeek product. Technical compatibility is the relationship; it is not an affiliation or endorsement.

Treating the shell as an ordinary plugin makes the division of authority testable. The shell can contribute native behavior through the Host and Client faces, while third-party plugins meet it through declared services and slots. The public profile service identifies the active composition and makes selection a restart operation. The package service supplies a bounded way to run the packaged toolchain. The Client window service describes geometry and effective material without giving a Web plugin the power to move a native window or call Electron. Each interface answers a particular need without implying that the caller owns the whole application.

The same logic governs presentation. Compatibility mode leaves the official layout, sidebar, and conversation below an independent Desktop frame. Extended mode changes the owner of the root layout and sidebar surface while preserving official occupants inside it. Enhanced, or “advanced” in the package contract, uses another explicit root registration and compact native geometry while retaining selected upstream rows. The important result is not that the modes look different. It is that each mode states which layer owns the root and which upstream occupants remain valid. A plugin that targets a declared slot can reason about that arrangement; a plugin that relies on a private DOM position cannot.

This is a more demanding idea of compatibility than preserving a familiar button. Compatibility means that the owner of a capability and the lifetime of that capability remain intelligible as the surrounding system evolves. A private Electron object may work today but has no standing as a third-party promise. A public service can be tested, documented, and changed with a known contract. The boundary is narrower than raw access, but that narrowness is what prevents every internal refactor from becoming an ecosystem-wide event.

There is a corresponding limit. Composability is not isolation. The project’s ecosystem manifesto advocates composition first, clear declarations, and backward compatibility, but its proposed Community Fabric remains a Draft rather than a released interoperability or security standard. A manifest can describe a capability; it does not by itself confine in-process JavaScript. Installed plugins and their dependencies still run locally with the user’s permissions. DSH Desktop’s public boundary reduces hidden coupling, not the authority of code the user has chosen to install.