Preface¶

When building DSH agents, a common requirement is to retain some execution traces after each turn ends: How many tool calls were recorded in this turn? Did any validation-like signals such as test, lint, or build appear? However, full session logs often include tool parameters, command outputs, user messages, model names, and providers, and writing them directly to disk introduces additional privacy surface.

DSH Verification Receipt is a community-maintained DeepSeek Harness passive Profile Bundle. After each durable turn/end, it appends a privacy-minimized heuristic execution summary to a local JSONL file. It neither registers new tools nor modifies the model history.

What This Is¶

DSH Verification Receipt’s one-line positioning is: Privacy-minimal heuristic per-turn execution summaries for DeepSeek Harness.

The maintainer is 030611, and the license is MIT. The documentation explicitly states that it is community-maintained and not an official DeepSeek project. It addresses the question of “how to keep a checkable execution trace locally while avoiding saving sensitive content as much as possible.”

The package.json declares dsh.bundle.patch; the cordis.patch.yml inserts a plain observer plugin.

Core Features¶

Passive Observation Only¶

According to verified documentation, the plugin does not register new tools, append Session events, add prompt sections, inject context, initiate model calls, or modify the model history.

Its impact on the model experience is: Token cost is None; the model has no new tools; the Session log remains unchanged; the Prompt and context remain unchanged.

Recording Execution Counts and Heuristic Signals¶

The summary records the tool call counts that have been logged, as well as validation-like signals based on lexical matching.

A heuristic signal is emitted when a tool name, or the command / cmd parameter of a shell-like tool, resembles the following tasks:

• test
• typecheck
• lint
• build
• check
• verify
• validate

The persisted verification signals retain only the source, a coarse-grained category, and the observed status.

What Is Not Saved¶

The persisted receipt does not include:

• Tool parameters or call IDs;
• Tool result contents or error messages;
• Assistant or user message text;
• Raw session IDs, working directories, provider names, or model names.

Installation and Activation¶

Installing to a Specific Profile¶

First, select the profile where receipts should be output. For example, web:

dsh plugin --profile web add dsh-verification-receipt
dsh --profile web --dump-config

The first command adds the plugin to the web profile. The second command exports the profile’s configuration to confirm that the plugin has taken effect.

If other profiles such as headless also need receipts, repeat the first add command with another profile name:

dsh plugin --profile headless add dsh-verification-receipt

Local Development Installation¶

For local development, after cloning the repository, run the check command, and then pass the checkout path to the DSH plugin installation command:

pnpm install --frozen-lockfile && pnpm run check

The documentation specifies that the installation method is to pass the checkout path to dsh plugin ... add, rather than just the package name.

Overriding the Output Path¶

The default output path is:

$DSH_HOME/verification-receipts/v1/receipts.jsonl

If DSH_HOME is not set, the path resolves to ~/.dsh.

Alternatively, set config.outputPath in the profile’s cordis.patch.yml to override it with an absolute private path:

- id: verification-receipt
  config:
    outputPath: /absolute/private/path/receipts.jsonl

Here, outputPath must be an absolute path.

Version and Compatibility¶

The package.json declares the plugin version as 0.1.0, with Node engines:

^22.19.0 || >=24.0.0

Compatibility evidence is based on the DeepSeek Harness commit:

47f943859bef60e4160492346772ded9b24f765a

That commit’s manifest declares:

• @deepseek-ai/dsh-session 0.1.0-rc.5
• Cordis 4.0.1
• Schemastery 3.18.1

The documentation also states that versions within the range but not listed are expected to be compatible rather than tested evidence.

Applicable Scenarios and Considerations¶

Suitable scenarios include:

• Needing to retain minimal execution summaries locally after each DSH turn ends;
• Wanting to record only tool call counts and lexical-level validation signals;
• Not wanting to write tool parameters, command outputs, message text, raw session IDs, working directories, provider names, or model names to files;
• Needing only passive observation without changing the model’s toolset, prompt, or session log.

Points to note:

• It only records execution traces; it does not prove that tests ran, commands were correct, assertions were sufficient, outputs were genuine, or assistant conclusions were correct.
• It is not an evidence audit ledger: there is no hash chain, artifact capture, claim-evidence linking, or protocol proof.
• receiptHash is a keyless SHA-256 that can be recalculated by anyone with editing permissions; it is not a signature, trusted timestamp, hash chain, commitment, or tamper-evident log.
• sessionIdHash is a deterministic, keyless, domain-separated pseudonymization identifier that can be correlated across files. If session IDs are predictable or low-entropy, observers may guess candidates offline and recalculate.
• The plugin runs with the current dsh process permissions; source code and license should be reviewed before installation; this plugin is licensed under MIT.

Conclusion¶

The value of DSH Verification Receipt lies in compressing “whether this turn has checkable execution signals” into a single local JSONL record while avoiding sensitive content as much as possible. It is suitable for lightweight observation, not for auditing, forensics, or quality gates.

Table of Contents: The current documentation does not provide a definitive URL, so uncertain directory addresses are not listed here.

GitHub Repository:

• https://github.com/030611/dsh-verification-receipt