dsh-env-manager-plugin

dsh plugin --profile web add dsh-env-manager-plugin

DSH Environment Manager

A DSH (DeepSeek Harness) plugin that gives every session a shared, queryable view of enterprise environments, services, deployments and operation-to-Skill bindings.

Works in DSH Web and Desktop.

中文简介：这是一个 DSH 插件，让每个会话都能按需读取企业运行环境、服务目录、部署实例、分层规则以及操作与 Skill 的绑定关系。

What it does

• Environment Registry — hosts, clusters, logical roles, access endpoints, host

accounts and login audit records in one record.

• Service Catalog — Git URL, default branch, build tool, artifact and rule profile references.
• Deployment Binding — which service runs where, as native, docker or kubernetes, with instance-level variables.
• Rule Resolver — layered, field-level overrides with full provenance: every value explains where it came from and what influenced it.
• Operation Skill Router — maps an operation (deploy, redeploy, collect-logs, …) to exactly one bound Skill, detecting conflicts and enforcing approval policy.
• Session Context — a per-session default environment that never leaks into another session.
• Discovery Skill — a profile-wide dsh-env-manager Skill registers with the plugin and

makes the registry discoverable from any workspace in the same profile; its full workflow

loads only when invoked.

• Memory Bridge — a contract for feeding scoped, redacted operation records into the DSH memory plugin (P1).

Status

**Phase 1 of the environment/plane model and Phase 1.1 of the K8s node/execution model are

implemented and installed in the desktop profile.**

• 52 Vitest tests pass; npm run build emits the committed lib/ tree.
• Ten env_* tools, the same-origin /env-manager/api route and the sidebar/main panel

are implemented.

• One environment is one complete network and one configuration page. Management,

business, database and expansion are role views over the same hosts[]; a node

serving two planes is one host with two roles.

• The environment detail page is split into overview, all nodes, one tab per plane, login

records, Kubernetes/clusters, endpoints and YAML. Plane tabs filter the same node

collection.

• New environment creates only the environment shell and seeds the four standard roles.

Nodes are added inside the environment, individually or by batch import.

• Add/edit node supports multiple roles, a machine kind (vm, physical, K8s all-in-one,

K8s worker, Pod host), command access (ssh, kubectl, docker) and an optional login

credential. K8s kinds reference a cluster; a Pod host is the machine reached with

docker exec, not one record per Pod. Batch import (IP,name,roles,port,user) creates

generic VM nodes and never accepts passwords. Node search covers id, name, IP, platform,

admin user, role, kind, access, cluster, account username and web login URL.

• Accounts can carry a web login URL and username for a management or business console.

Add web login opens the account form with protocol web; Edit account can change the

URL or rotate the password. A password is written to the DSH credential service, never to

YAML.

• The Kubernetes/clusters tab creates and edits cluster metadata (kind, topology, API

endpoint, namespaces, credential reference) and derives node counts from clusterRef.

• Passwords are written to the DSH credential service; YAML keeps only

env-manager/<environmentId>/<hostId>-<username>.

• 环境 (Environments) is the default tab, and the persistent header 新增环境

action is available from every tab. 记录 (Records) is limited to services,

deployments, rule profiles and operation bindings.

• Remaining: database primary/replica/sharding topology (Phase 2), row-level delete for

nodes/accounts/logins, light-theme visual QA, and the live approval/credential probes

V4 and V6.

• No operation execution: routing returns the bound Skill and policy, it does not run it.

How agents discover the registry

The plugin ships a discovery Skill named dsh-env-manager as part of the same bundle.

It is not a separate SKILL.md, and it is not installed separately.

How it works:

1. apply() registers the Skill through ctx.skills.register() from the plugin's

unscoped context. DSH files it into the global Skill layer for the current profile.

2. The Skill catalog carries only the name, description and whenToUse. That description

is the proactive mention that lets a new workspace discover the registry.

3. The full workflow body is loaded only when the model or user invokes the Skill. It tells

the agent to use env_list / env_find first, then env_set_context, env_resolve,

and env_resolve_operation.

4. The plugin does not inject a global system-prompt section. Unrelated coding sessions

do not receive environment-manager instructions.

5. The registration is created inside the plugin effect, so disabling or uninstalling the

plugin also removes the Skill.

6. registerSkill: false in the plugin config suppresses the entry without affecting the

tools or panel.

Scope and limits:

• Same DSH profile: every workspace, including a new empty one, sees the Skill in its

catalog; no workspace AGENTS.md is required. This was verified from an empty temporary

workspace.

• Different profile or machine: the Skill is not shared; install the bundle there.
• The Skill is discovery, not execution. It does not deploy, restart or collect logs.

Those actions still need an operationBinding that points to an execution Skill.

• A catalog entry is a trigger surface, not a hard guarantee. Critical operations must still

be enforced in the execution Skill or tool layer.

• Because the Skill is registered by the plugin, its content is versioned with the plugin;

there is no workspace copy to drift.

The plugin's own tools remain registered independently of this Skill. The Skill only

…(truncated)