dsh-proof

Independent read-only acceptance layer for the DeepSeek Harness.

Before each top-level turn closes, dsh-proof spawns a read-only verifier
subagent, collects its structured verdict, and steers any non-pass gaps back
into the driving agent. It is the harness's missing "is the agent actually
done" gate — no other plugin can substitute for it.

Install

dsh plugin --profile <name> add github:EvilIrving/dsh-proof

Or, from a checkout:

dsh plugin --profile <name> add ./dsh-proof

The bundle patch inserts one plugin row (dsh-proof); it needs the
subagents service (the official dsh-subagent providers), which the base
profile already mounts.

How it works

The verifier inherits the parent's tool set and is narrowed by the deny list
(see deny list); it never sees a whitelist that could
accidentally hide a newly added read-only tool. A verifier that ends with
stopReason !== 'completed' or a missing structured result is treated as
"no objection", so a failed proof never fails the user's turn.

Config

export interface Config {
  providerName: string          // default 'spawn'
  maxAttemptsPerTurn: number    // default 3
  denyTools: string[]           // default mutating-tool deny list
  verifierPrompt: string        // read-only acceptance instruction
  followupInstruction: string   // steering text after a failed verdict
}

Set any field from cordis.yml:

plugins:
  dsh-proof:
    config:
      maxAttemptsPerTurn: 2
      denyTools: [write, edit, str_replace_editor, bash, run_code, subagent]

Deny list

toolFilter.deny removes tools from the verifier's inherited full set.
tools.restrict validates every name loudly, so denyTools must name tools the
deployment actually registers. The default is
write, edit, str_replace_editor, bash, run_code, subagent, which keeps
read-only discovery tools (read, read_image, glob, grep) available. A
deployment that adds its own mutating tools must extend the list; a deployment
that forbids even shell/read access should switch to an explicit allow
whitelist (set denyTools and verifierPrompt to match, or extend the plugin
for an allowTools field).

Model Experience

Request context and condition

What the model sees

The top-level agent receives an injected user message listing the verifier's
gaps and evidence, followed by the configured followupInstruction. Only a
non-pass verdict injects anything; a passing turn adds nothing.

Token effect

Zero-direct effect on passing turns. A failing turn adds one bounded injected
message (gaps + evidence) plus the short follow-up line.

KV Cache effect

Append-only: the injected context and follow-up are appended as new user
messages, never rewriting earlier request tokens.

Known Limitations and Deferred Work

• Deny list must match the deployment's tools — tools.restrict fails loud
  on unknown names, so a mismatched default blocks verifier startup. The exact
  mutating-tool set is deployment-specific and is resolved at first install.
• No evidence normalization — the verifier gathers evidence itself; this
  plugin does not re-implement diff/test/typecheck/lint. A deployment wanting
  specific evidence channels should extend verifierPrompt.
• Best-effort spawn — a provider that is absent or rejects the request
  degrades to a no-op (logged), rather than failing the user's turn.