DeepSeek Harness Plugin Hub

发布与管理完整 Harness Profiles,发现适合你的插件。

探索

插件目录环境预设文档中心动态

社区

发布插件联系我们报告问题

相关链接

Plugin Hub GitHubDeepSeek Harness 官方项目系统状态隐私说明
© 2026 DeepSeek Harness Plugin HubPowered byPaxTech

独立、非官方社区项目,与 DeepSeek 官方无隶属、授权或背书关系。

Workloads Local Ui1 — DeepSeek Harness 插件(DSH Plugin)
DeepSeek Harness Plugin Hub
ProfilesPlugins分类动态文档登录管理 Profiles
ProfilesPlugins分类动态文档登录
← Plugins
W

dsh-workloads-local-ui1

Workloads Local Ui1

由工作区拥有的持久进程监控、就绪检查,以及用于 DeepSeek Harness 的 Runtime Center。

插件会安装到这里;不确定时保持 web。

npx -y @deepseek-ai/dsh plugin --profile web add github:yewenyell-lang/dsh-workloads#b38a0cda3352e1a224a2c7084792ed26d31871fa
README兼容性版本

兼容性与来源证明

Workloads Local Ui1 以 dsh-workloads-local-ui1 发布,当前版本为 0.3.0。Plugin Hub 会校验它的 manifest,并保存精确安装来源,便于复现安装结果。

DSH 兼容范围
*
运行环境
web
发布来源
github
Registry 更新时间
2026/8/21

版本

0.3.0stable
2026/8/21

相关插件

正在加载相关插件…

最新版
0.3.0
DSH
*
HMR
重启进程
Tree shaking
未声明可安全裁剪
解包体积
未提供
文件数
未提供
Surface
web
许可证
MIT
发布源
github
GitHub
★ 1
周下载
0
最近提交
2026/8/21
查看源码 ↗
README Badge

点击下方 Badge 复制 Markdown,粘贴到 README 即可。

这是你的 Plugin?认领权益 · 优先安全扫描

验证 package.json 声明的 GitHub 仓库,即可管理这个公开页面。认领后,Hub 会优先安排当前版本的安全扫描,并在通过后公开展示结果。

认领这个 Plugin →
报告问题

相关插件

继续浏览 developer-tools 分类下经过校验的插件。

Web App@deepseek-ai/dsh-web-appdsh 浏览器界面捆绑包:位于 dsh-base 之上的 Web 补丁层,加上运行时粘合插件(提供前端 dist、Web 界面提示符、bash 运行时变量和 URL 行)Sdk Minimal@deepseek-ai/dsh-sdk-minimal独立的最小 SDK 配置包:JSON-RPC、一个 DeepSeek 适配器、持久化 Shell 和 JSONL 会话Sdk App@deepseek-ai/dsh-sdk-appdsh SDK 配置包:基于 dsh-base 提供 stdio JSON-RPC 服务和进程生命周期管理Subagent Codex@deepseek-ai/dsh-subagent-codex基于官方 app-server 协议的一次性 Codex 子代理提供程序

README

DSH Workloads

English | 简体中文

Durable, workspace-owned long-running processes for DeepSeek Harness, plus a Runtime Center that keeps DSH Session Jobs and Workspace Workloads visible without conflating their lifecycles.

Current status: public installable profile bundle with a Windows local-process Provider, validated against DSH 0.1.0-rc.6. The Service/API contract remains pre-1.0.

Why Workloads are not Jobs

DSH JobDSH Workload
OwnerAgent/SessionCanonical workspace
LifetimeBounded operationLong-running service
DisposalCancel with ownerExplicit stop
StorageIn-memory registryDurable records and logs
Restart identityNew JobStable workloadId, new runId/generation
ReadinessProducer-specificLog/TCP/localhost HTTP evidence

Typical Workloads include dev servers, watchers, debuggers, proxies, local middleware, and long-running event consumers. Builds, tests, installs, and other bounded operations should remain DSH Jobs.

Package surfaces

  • . — Host plugin that provides ctx.workloads, the local-process provider, and a session-authorized Web API.
  • ./client — Web Client plugin that registers the 运行中心 entry in conversation.view.
  • ./tools — opt-in Agent-preset consumer exposing seven workload_* tools and optional proc_* compatibility aliases.

Host Service

The Host plugin provides one process-wide ctx.workloads service:

list(workspaceRoot, options)
start(workspaceRoot, spec, existing?, control?)
wait(workspaceRoot, workloadId, readiness, signal?)
logs(workspaceRoot, workloadId, maxBytes?)
stop(workspaceRoot, workloadId, control?)
stopAll(workspaceRoot, control?)
restart(workspaceRoot, workloadId, control?)
subscribe(listener)

Records are stored outside business repositories:

${DSH_HOME}/runtime/workloads/<canonical-workspace-sha256-prefix>/

Each Workload has a stable workloadId, a new runId and incremented generation per start/restart, orthogonal lifecycle phase and readiness health, process identity, timestamps, last outcome, bounded run history, readiness evidence, action audit metadata, and rotating logs.

The detached runner checks currentRunId before each metadata write, preventing a stopped older generation from overwriting a newer restart.

Workspace authority

Browser calls include the current sessionId, but neither the browser nor the model chooses the authoritative workspace boundary. The Host resolves:

sessions.get(sessionId)
→ sandboxPolicy.resolve({ session })
→ canonical workspaceRoot

A request whose cwd does not match that root is rejected. Agent tools use the same policy from exec.agent.session.

Runtime Center

The Client registers a session-scoped conversation.view entry with ID runtime-center and label 运行中心.

  • Session Jobs come directly from useSessions(state => state.jobsBySession[sessionId]); they are not polled or copied into a second state owner.
  • Workspace Workloads use a session-authorized complete snapshot every three seconds.
  • Same-cwd conversations see the same Workloads while retaining separate Session Job lists.
  • Readiness, phase, health, PID, run identity, and a redacted 32 KiB log tail are shown.
  • Each Workload card's Stop button is available in every phase (idempotent for already-terminated services); Restart keeps its original behavior.
  • The 工作区长期服务 section header shows a Stop all button only while at least one service is active; like stop/restart it needs a second-click confirmation and is re-authorized on the Host.

A future DSH-native version should replace Workload polling with an apiProxy domain and Client snapshot mirror. Session Jobs already use the native push mirror.

Agent tools

Load ./tools from an Agent preset to expose:

workload_list
workload_start
workload_wait
workload_logs
workload_stop
workload_stop_all
workload_restart

Set enableProcAliases: false to omit the seven legacy proc_* aliases (including proc_stop_all). The tool layer is a consumer only; it must not publish or isolate the shared Host workloads service.

Install

Install the tagged GitHub package into the Web profile:

dsh plugin --profile web add github:yewenyell-lang/dsh-workloads#v0.3.0

The package declares dsh.bundle.patch, so dsh plugin automatically adds it to dsh.profile.bundles. Its cordis.patch.yml mounts the Host Registry, local-process Provider, Web API, and Runtime Center with legacy migration disabled by default. Restart the existing DSH Web process and refresh the browser after installation.

Verify the composed profile without starting another server:

dsh --profile web --dump-config

To remove the bundle:

dsh plugin --profile web remove dsh-workloads-local-ui1

Add the tool consumer only to Agent presets that should control Workloads:

- id: tool-workloads
  name: dsh-workloads-local-ui1/tools
  config:
    enableProcAliases: true

The Registry belongs in the Host plane because it crosses Sessions. Only the tool consumer belongs in an Agent preset; do not isolate the shared workloads service there.

To opt into legacy migration, override the bundle row in the Web profile's later cordis.patch.yml layer and restate its complete config:

- id: dsh-workloads-local-ui1
  config:
    legacyProcessRoots:
      - C:\\absolute\\legacy-process-root

Local-process safety

  • Commands must be one line and are rejected when they contain common password, token, JWT, Bearer, URL-credential, Redis password, or connection-string shapes.
  • Requested cwd must stay inside the canonical workspace.
  • Extra environment maps are not accepted; runner/child environments remove DSH_* and common credential variable names.
  • Readiness is restricted to fixed log text, 127.0.0.1 TCP, and credential-free localhost http:// URLs.
  • Stop is fail-closed when the Windows process table is unavailable or PID creation time does not match the recorded run.
  • Windows process-tree termination is best effort: graceful taskkill /T first, /F only after the grace period.
  • Unknown application secret formats can still reach local log files. API/tool reads redact common shapes, but callers should request the minimum tail.

Optional legacy migration

legacyProcessRoots accepts absolute directories whose children are workspace-hash directories containing the earlier jobId/status/logPath record shape.

Migration is opt-in, copy-only, idempotent per target workspace, non-destructive to sources, and marked with migratedFrom: legacy-process-v1. No product-, preset-, user-, or machine-specific migration root is compiled into the package.

Development

No dependency installation is required for the current source and smoke tests.

npm run check
npm test

The suite uses temporary DSH_HOME and workspace directories and covers Client registration, optional legacy migration, start, combined readiness, redaction, stable restart identity, stop, stop-all, action audit metadata, seven workload_* tools, optional aliases, and cleanup.

Known limitations and roadmap

  1. One DSH Host per DSH_HOME is the supported coordination model. Shared multi-Host operation needs storage CAS/lease fencing.
  2. The current Web carrier is an exact session-authorized route; upstream integration should use a typed apiProxy domain/mux.
  3. Workload snapshots currently poll every three seconds; a future Client mirror should resync on connection/reset and consume Host change events.
  4. The local-process provider is Windows-only. PM2, Docker Compose, systemd, SSH, and Kubernetes should be separate Providers behind the same Registry contract.
  5. A future Service Definition package should formalize types, Provider registration, attachController(), desired state, and reconciliation leases before a stable 1.0 release.

License

MIT