Preface¶

The DeepSeek Harness (DSH) ecosystem emphasizes that “everything is a plugin.” When the same business action is exposed through different surfaces such as CLI, MCP, and GUI, developers need to confirm whether these entry points point to the same stable action core, rather than each having its own implementation, declarations, and state transitions.

dsh-action-parity is used to generate this type of consistency evidence. It does not execute business actions, nor does it pixel-test buttons. Instead, it checks bindings, content-addressed declarations, and replay observations to confirm whether multiple surfaces produce consistent results for the same fixture.

Below, we introduce the positioning, verifiable content, installation method, and typical usage of dsh-action-parity.

What Is This¶

dsh-action-parity is a DSH plugin maintained by dongsheng123132, with the repository located at:

https://github.com/dongsheng123132/dsh-action-parity

It is used to verify whether CLI, MCP, and GUI bindings reach the same DeepSeek Harness action core. Verified facts show that the version in package.json is 0.2.0, the license is MIT, and it requires Node.js >=22.

The positioning of this plugin is inspection and reporting, not business execution. It focuses on binding declarations, stable action IDs, content-addressed hashes, fixture replay results, state transitions, and security input constraints.

Core Features¶

Verify That CLI, MCP, and GUI Use the Same Action Core¶

dsh-action-parity can check the following:

• Verify whether CLI, MCP, and GUI bindings use the same stable actionId / coreActionId.
• Validate SHA-256 content-addressing for action-core, binding declarations, and replay fixtures.
• Check whether the same fixture produces the same result digest, success state, and state-version transition across all surfaces.
• Make stale mutations fail closed with STALE_STATE without advancing state.
• Enforce confirmation for confirmation-required actions across all surfaces.
• Output missing/stale evidence and parity failures into a deterministic content-addressed report.
• Register dsh_action_parity_inspect and dsh_action_parity_verify.
• Provide proof-only MCP tools action_parity_manifest_inspect and action_parity_observations_verify.

Input and Output Boundaries¶

In addition to parity verification, this plugin also constrains its own input and write behavior:

• Rejects inputs containing fields shaped like secret, prompt, chat, raw input/output, argv, stdout, or stderr.
• Enforces paths to be within workspaceRoot.
• Rejects symlink inputs and output directories.
• Only writes to the explicit artifactDir.
• Performs atomic publication with SHA-256 read-back verification.

Installation and Enablement¶

The runtime environment requires Node.js >=22. Use the official installation command:

dsh plugin --profile web add github:dongsheng123132/dsh-action-parity

This bundle will register:

dsh_action_parity_inspect
dsh_action_parity_verify

Typical Usage¶

Inspecting the Manifest¶

First, inspect the manifest to confirm that binding declarations and content-addressing relationships meet expectations:

dsh-action-parity inspect --workspace-root examples/basic --manifest action-parity.manifest.json

This command uses examples/basic as the workspace root and reads action-parity.manifest.json.

Verifying Observations¶

After the inspection step above, parity verification can be performed using observations:

dsh-action-parity verify --workspace-root examples/basic --manifest action-parity.manifest.json --observations observations.jsonl --artifact-dir artifacts

This command performs verification based on the manifest and observations.jsonl, writing results to the explicit --artifact-dir artifacts.

Exit codes are as follows:

Proof-Only MCP Tools¶

This plugin also provides two proof-only MCP tools:

• action_parity_manifest_inspect: validates an inline manifest.
• action_parity_observations_verify: checks inline JSONL envelopes against that manifest.

These MCP tools are proof-only: they do not read the filesystem, dereference declaration paths, execute actions, or write artifacts. Therefore, declaration content hashes are reported as not verified.

For workspace-bounded file hash verification, as well as reports with atomic publication and read-back verification, use DSH tools or the CLI.

Applicable Scenarios and Considerations¶

Appropriate for the following scenarios:

• DSH developers need to prove whether CLI, MCP, and GUI bindings point to the same stable action core.
• Need to check consistency of actionId / coreActionId, SHA-256 content-addressing, fixture digests, and state-version transitions.
• Need to reject inputs containing fields shaped like secret, prompt, chat, raw input/output, argv, stdout, or stderr.
• Need to output parity failures as a deterministic content-addressed report.

Considerations:

• This plugin does not execute business actions, nor does it pixel-test buttons.
• The plugin runs with the current dsh process permissions — inspect the source and license before installation.
• Proof-only MCP tools do not read the filesystem, dereference declaration paths, execute actions, or write artifacts.
• Paths must be within workspaceRoot; symlink inputs and output directories are rejected.

Conclusion¶

The value of dsh-action-parity lies in turning “whether CLI, MCP, and GUI consistently invoke the same DSH action core” into checkable, reportable, and reproducible evidence. It focuses on stable action IDs, content addressing, fixture replay results, and state transitions, making it suitable for consistency verification during DSH plugin development.

GitHub:

https://github.com/dongsheng123132/dsh-action-parity

The catalog page URL does not appear in the verified materials, so no link is provided in this article.