Introduction¶

The philosophy of DSH is “everything is a plugin,” and the community plugin directory is also a standalone site, not the DeepSeek official app store. For scenarios using DSH for agent development, giving the Agent a requirement directly and allowing it to freely modify can easily lead to two types of problems: task boundaries slowly drifting in long sessions, and the availability of modification capabilities like bash, write, and edit after the task is completed.

dsh-governed-workflow attempts to converge such workflows into a more explicit sequence: first read task authority from public GitHub Issues, only allow protected modifications after the task enters RUNNING; after the task enters BLOCKED, COMPLETED, or REVIEW_PENDING, protected modifications are prohibited again, and final acceptance is left outside the Builder Runtime.

What is this¶

dsh-governed-workflow is a standalone community plugin for DeepSeek Harness agents, with the package name dsh-governed-workflow. The repository address appearing in the documentation is:

https://github.com/zcx369658780/governed-workflow-for-dsh

The current documentation does not explicitly label a maintainer; zcx369658780 in the repository path is only derived from the GitHub address clues and is not written here as a confirmed maintainer identity.

Confirmed versions and attribution information are as follows:

Current Stage: V0.9 Developer Technical Preview
Verified Baseline: @deepseek-ai/dsh@0.1.0-rc.6
Package Name: dsh-governed-workflow
License: MIT
This project is not affiliated with DeepSeek and does not represent official endorsement from DeepSeek

The repository slug is governed-workflow-for-dsh, and the package name is dsh-governed-workflow. This article uses the package name appearing in the documentation as the plugin name.

Core Features¶

The core of dsh-governed-workflow is to change the Agent workflow from “direct modification” to “confirm authority first, then allow modification, and finally enter independent acceptance.”

The workflow is as follows:

GitHub Issue Authority
        ↓
     OBSERVE
        ↓
      ADMIT
        ↓
       RUN
        ↓
BLOCK / COMPLETE
        ↓
      REVIEW

Specific capabilities include:

GitHub Issue Authority
An optional provider can read a machine-parsable authority block from a public GitHub Issue. The Builder should not infer task permissions from old chat history, branch existence, or its own plan.
Lifecycle State Machine
The task progresses in the following order:

   AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING → BLOCKED/COMPLETED → REVIEW_PENDING

Illegal transitions will fail closed.

RUNNING-only Mutation Guard
The current protected DSH mutation tools are:

   bash
   write
   edit

If there is no accepted authority, or the task status is not RUNNING, these protected modification actions will be rejected.

Model-side Governance Tools
The plugin provides two model-side tools:

governance_status: Read-only status query
governance_transition: State transitions within a restricted action set

Final State Freeze
After the task enters BLOCKED, COMPLETED, or REVIEW_PENDING, protected modifications are prohibited again.
Independent Acceptance Boundary
The Builder cannot accept, merge, or close an accepted task on its own, nor can it create or activate subsequent tasks. Final decisions are left outside the Builder Runtime.
Governance Evidence
Authority observation and lifecycle transition are recorded as restricted governance evidence for review and replay.

Installation and Activation¶

Current documentation has not confirmed a published one-click install command. The documentation provides an IH-1 candidate install script, which is explicitly labeled as pending independent acceptance; before the IH-1 merge, this script is not in main, so it is not currently used as a published one-click install command.

The candidate script path is:

scripts/install-dsh-governed-workflow.mjs

The candidate invocation method is:

node scripts/install-dsh-governed-workflow.mjs --profile governed --ref <40-bit Git commit SHA>

This step requires explicitly providing the DSH profile and immutable source ref; it does not default to installing the floating main.

After installation, execute:

dsh --profile governed --dump-config

This step is used to confirm that the five default components of Governed Workflow have been loaded. The current candidate script does not automatically enable the optional GitHub Issue network-authority bootstrap.

Package Information and Installation Boundaries¶

Confirmed package.json fields show that this plugin declares the following permission list:

[
  "harness:tool",
  "harness:skill",
  "harness:guard",
  "session:append",
  "network:read",
  "credentials:none",
  "subprocess:none",
  "native-code:none"
]

Other displayed fields include:

{
  "name": "dsh-governed-workflow",
  "version": "0.1.0",
  "license": "MIT",
  "type": "module",
  "dshVersions": ["0.1.0-rc.6"]
}

Installation-related fields are:

{
  "install": {
    "mode": "transactional",
    "adapter": "profile-bundle",
    "failurePolicy": "generation-rollback",
    "touchesCurrentBeforeActivation": false
  },
  "lifecycle": {
    "activation": "restart-profile",
    "dispose": "unknown"
  }
}

Please note: The package.json in the documentation is truncated and does not display full fields, so it is not possible to complete other configurations based on this. The V0.9 Developer Technical Preview appearing in the README and version: 0.1.0 in package.json may indicate different version systems; this article does not unify them into the same version number.

Typical Usage¶

After the above installation and configuration confirmation steps, the workflow proceeds roughly in the following order:

Task authority comes from a machine-parsable authority block in a public GitHub Issue. The documentation does not provide the specific format of the authority block, so format details are not expanded here.
Task status progresses according to the lifecycle state machine:

AUTHORITY_OBSERVED → TASK_ADMITTED → RUNNING

Only when an accepted authority already exists and the status is RUNNING, are the protected bash, write, and edit allowed to execute. Otherwise, execution will be rejected.
After the task ends, it enters a terminal state:

BLOCKED
COMPLETED
REVIEW_PENDING

After entering these states, protected modifications are prohibited again.

Acceptance takes place outside the Builder Runtime. The Builder cannot accept, merge, or close an accepted task on its own, nor can it create or activate subsequent tasks.

Applicable Scenarios and Notes¶

This process incurs process costs such as Issues, state transitions, and Review compared to free-form vibe coding, so it sacrifices some speed. It is more suitable for projects that need clear stopping conditions, review, rollback, and acceptance.

More suitable for:

Medium to large-scale projects
Multi-file modifications
Long-session tasks
Multi-stage delivery
Scenarios requiring running commands or modifying real code
Vibe-coding projects with high deployment or data risk
Apps, backend services, research tools, automation systems, and long-term maintenance repositories

Less suitable for:

One-off small scripts
A few-minute throwaway prototype
Completely disposable experiments
Scenarios where governance costs are significantly higher than benefits

Special attention is needed during use: this is not a complete OS sandbox. allowedPaths filesystem hard isolation, Git command semantics, GitHub merge/close API, etc., are still not enforced boundaries by the Runtime. The plugin will run with the current DSH process permissions, so you should check the source code, license, permission fields, and the status of the candidate install script before installing.

Links and Next Steps¶

The value of dsh-governed-workflow lies in explicitly visualizing the Agent’s task authority, lifecycle, and acceptance boundaries: first there is authority, then protected modifications are allowed during RUNNING, and finally the terminal state freeze is handed over to independent acceptance.

The Community Directory page URL has not appeared in the verified documentation, so this article does not add unconfirmed links. The currently verifiable repository address is:

https://github.com/zcx369658780/governed-workflow-for-dsh

dsh-governed-workflow: Add task authorization, lifecycle, and acceptance boundaries to DSH