dsh-workloads

In DeepSeek Harness, operations like a dev server or file watcher lack the clean start-finish boundary of a build or a test. Treating them as ordinary Session Jobs creates a lifecycle mismatch—Jobs are session-owned and die with the session, yet a long-running service needs a stable, workspace-scoped identity that survives across sessions. dsh-workloads fills that gap with durable, workspace-owned process management for long-running services, plus a Runtime Center that keeps session jobs and workspace workloads visible without conflating their lifecycles.

Each Workload carries a stable workloadId; every start or restart mints a new runId and increments a generation counter. Records, rotating logs, and readiness evidence (log-text match, TCP probe, localhost HTTP check) are persisted outside the business repository, with bounded run history. The browser-side Runtime Center shows both Session Jobs and Workspace Workloads under a session boundary, supporting stop, restart, and stop-all—each action validated against the workspace cwd and screened for credential patterns. On the Agent side, an opt-in preset exposes seven workload_* tools so the model can start and stop long-running services conversationally, while the shared Host service remains un-isolated from any single Agent.

This plugin is a good fit if you regularly keep dev servers, watchers, local proxies, or debuggers alive inside DSH and want them in a separate, durable layer from one-shot builds and tests. The Provider is currently Windows local-process only, and the Service/API contract is still pre-1.0, so it suits DSH users comfortable with early-stage iteration.