dsh-approval-first

A DeepSeek Harness (DSH)
plugin: install it into a profile alongside your own plugins.

[!WARNING]
Interim shim, expect deprecation. This plugin works by shadowing the
harness edit and write tools with frozen copies that add an approval
step. When DSH grows native one-turn escalation this bundle becomes
obsolete and should be removed. Until then a harness update can change the
shipped tools underneath it, so the plugin ships with a drift tripwire
that refuses to boot when the copies no longer match (see
Deprecation and drift).

Approval prompts on the first call. Under a confining sandbox, a file
mutation the policy denies fails first, then the model has to send the same
call again with sandbox_permissions and justification before the user
sees an approval prompt. This plugin shows the prompt on the first call
instead. If you like to review generated code, the review object is the
diff on the card, not model-written prose, and a rejection is a normal
result (edit rejected by the user; file unchanged), never a red error.

Asking only happens where the standing policy would deny the write anyway.
Inside the workspace nothing changes: writes stay silent, same as the
shipped tools.

How to install

Requires a DeepSeek Harness checkout and a profile (here web):

git clone https://github.com/joao-paulo-santos/dsh-approval-first

# from the harness checkout
pnpm dsh plugin --profile web add /path/to/dsh-approval-first

# verify the profile still composes
pnpm dsh --profile web --dump-config

Then (re)start the harness; the host half loads at boot. No profile patch
and no configuration: the plugin is active by itself in any session whose
standing mode is not danger-full-access.

What happens when

Shadow tools are registered per agent and follow the session's current
standing mode: switching the mode mid-session arms or disarms them on the
next call, no restart needed.

Apart from the approval step the shadows mirror the shipped tools: same
schemas, same validation and error texts, same diff cards and success
phrasing. An approved write runs under a one-directory grant (the parent of
the target), never danger-full-access.

Unobserved edit targets

Asking first has one exception. The shipped edit tool refuses a file the
session has never read (edit requires reading "..." first) before any
sandbox check runs, so asking approval for such an edit would spend a card
on a call that is certain to fail the moment it is allowed. The plugin
probes that same read-first gate and, when it would refuse, steps aside:
the call runs the native path and the model gets the harness's own error in
the same turn, with no prompt from anyone. The skip never denies anything;
it only chooses who runs the check, so its errors cost a card, never a
consent. write is not affected: creating a file the session considers
new is real work and still asks.

Deprecation and drift

• When DSH grows one-turn escalation natively, remove this bundle
  (dsh plugin --profile web remove dsh-approval-first). No files, no
  settings, no services to clean up.
• Because the shadows are frozen copies, a harness update that changes
  edit/write would otherwise leave this plugin serving stale behavior
  with no error anywhere. The drift tripwire compares the copies against
  the live tool definitions at boot and refuses to activate on mismatch.
  driftMode: 'warn' downgrades that to a logged warning. Renames and
  removals upstream are caught too, so the plugin never serves tools that
  no longer exist.
• maintenance.md holds the copied-from inventory (each
  frozen piece mapped to its upstream source file), the post-update ritual
  and a table of symptoms, causes and fixes.

Scope: edit and write only. Bash keeps the classic escalation path. If
another plugin already shadows these tools for an agent, that agent is
skipped.

Testing

Plain Node scripts, no build step. The fake context enforces the Cordis
inject guard, so the suite can actually fail:

node test/plugin.test.mjs        # 74 checks
node test/diff-parity.test.mjs   # 31 cases, oracles against the harness's own diff package

Maintenance

After every harness update, run the ritual in
maintenance.md: both suites, check the boot row (a failed
approval-first row is the tripwire working), one manual smoke of each
column in the behavior table.