Preface¶

In the DSH plugin ecosystem, actions such as recovery, rollback, failed rollback, and stale plan rejection are typically performed by external recovery executors. For users, the key point is not whether a plugin executes recovery on someone’s behalf, but whether verifiable evidence can be left behind after a drill concludes: whether the relevant objects are still regular files in the workspace, whether the SHA-256 and revision match, whether the phase sequence complies with the manifest, whether the RTO meets the target, and whether missing or stale evidence is explicitly disclosed.

The following introduces dsh-recovery-proof. It is a read-only recovery drill evidence verification plugin for DeepSeek Harness.

What This Is¶

dsh-recovery-proof is a read-only recovery drill evidence verifier. The repository address is:

https://github.com/dongsheng123132/dsh-recovery-proof

Verified information is as follows:

• Maintainer: dongsheng123132
• Version: 0.2.0
• License: MIT
• Runtime requirement: Node.js >=22

It does not restore files, create checkpoints, or replace recovery executors such as Turn Rewind or Checkpoint Rewind. Its responsibility is to check whether an external recovery drill has left verifiable evidence and output a content-addressed JSON report.

Core Features¶

1. Verify Whether Referenced Objects Actually Exist¶

The plugin checks whether the prestate, rescue, restored, or rollback objects referenced in the manifest satisfy the following conditions:

• They are regular files in the workspace;
• They have the declared SHA-256;
• They have the declared revision.

This means it focuses on whether “objects are present in the workspace as declared,” rather than executing the recovery action itself.

2. Verify Whether Phase Sequence Complies with the Manifest¶

The plugin checks whether the following flows follow the exact phase sequence declared in the manifest:

• recovery;
• failed-apply rollback;
• stale-plan rejection.

It also checks more specific semantic constraints:

• rescue evidence must appear before apply;
• a failed apply must be followed by a successful rollback;
• stale plans must be rejected.

3. Verify Whether RTO Meets Scenario Thresholds¶

The plugin checks whether the cumulative duration of structural events remains within the RTO threshold for each scenario. The input here is structured event files, not chat content or prompt content.

4. Output a Content-Addressed JSON Report¶

The plugin generates a content-addressed JSON report that discloses:

• missing evidence;
• stale evidence;
• failed rules.

In other words, the verification result does not simply provide a pass or fail; it writes the failure points and evidence gaps into the report.

5. Register DSH Bundle Tools¶

The plugin registers the following bundle tools:

dsh_recovery_proof_inspect
dsh_recovery_proof_verify

It also provides the CLI inspect and verify commands, with inputs requiring an explicit specification of workspace, manifest, event, and artifact-dir.

6. Provide Codex Plugin and Proof-Only MCP Server¶

The plugin also provides a Codex plugin and a proof-only MCP server, where the MCP exposes two tools:

recovery_manifest_inspect
recovery_evidence_verify

This MCP side is used only for restricted verification and does not execute recovery actions.

Installation and Enablement¶

The installation command is as follows:

dsh plugin install github:dongsheng123132/dsh-recovery-proof

After installation, use the following command to enable the plugin in the plugin system:

dsh plugin compose dsh-recovery-proof

Typical Usage¶

inspect Usage¶

The inspect command accepts an explicit workspace-root and manifest path:

dsh-recovery-proof inspect --workspace-root ./examples/basic --manifest recovery.manifest.json

This step is used to check the recovery drill structure declared in the manifest without writing artifacts.

verify Usage¶

The verify command reads event files and outputs to an explicit artifact-dir:

dsh-recovery-proof verify --workspace-root ./examples/basic --manifest recovery.manifest.json --events recovery.events.jsonl --artifact-dir artifacts

This step executes the full evidence verification process and writes the report to the artifacts directory.

Input and Output Boundaries¶

1. Input is Explicit JSON/JSONL Files¶

The plugin’s input consists of explicit JSON or JSONL files. The following content will be rejected:

• secret-shaped fields;
• token-shaped fields;
• prompt-shaped fields;
• chat-shaped fields;
• content-shaped fields.

In other words, the plugin does not make determinations by reading chat content, prompts, or secret material; it works around structured evidence.

2. Paths Must Remain Within workspaceRoot¶

All input paths and output directories must be located under workspaceRoot. The following input will be rejected:

• symlink input;
• symlink output directory.

Output is only written to an explicitly specified workspace-relative artifactDir, using atomic write and SHA-256 read-back checks.

3. No Recovery Actions Are Executed¶

The plugin’s boundaries are relatively clear:

• no shell is spawned;
• no network is used;
• no recovery action is executed;
• no install lifecycle scripts.

It only performs evidence verification, not recovery execution.

4. MCP Side Does Not Access the File System¶

The MCP tools do not access the file system, do not dereference object paths, do not write artifacts, and do not execute recovery actions. Their results will explicitly state: object-content verification was not performed.

If you need to cross-check object hashes and content-addressed reports against the workspace, you should use the DSH or CLI entry points.

Applicable Scenarios and Notes¶

This plugin is suitable for the following scenarios:

• There is already an external recovery drill process, and drill evidence needs to be verified;
• There is a need to check whether objects referenced in the manifest match the declared SHA-256 and revision;
• There is a need to check the phase sequence of recovery, failed-apply rollback, and stale-plan rejection;
• There is a need to check whether RTO meets scenario thresholds;
• There is a need to write missing/stale evidence and failed rules into a report.

Scenarios where it is not applicable include:

• Needing the plugin to directly restore files;
• Needing the plugin to create checkpoints;
• Needing the plugin to replace recovery executors such as Turn Rewind or Checkpoint Rewind.

Please note: the plugin runs with the permissions of the current dsh process. You should review the source code and license before installation.

Conclusion¶

The value of dsh-recovery-proof lies in separating recovery drills from “executing actions” to “verifying evidence.” It does not replace recovery executors but checks whether an external drill has left verifiable object evidence, phase evidence, and RTO evidence, writing failed items into a content-addressed JSON report.

The currently verified materials provide the GitHub repository address:

https://github.com/dongsheng123132/dsh-recovery-proof

An independent directory page address was not provided in the verified materials.