dsh-inspect: An Adversarial Check-Fix-Review Closed-Loop Plugin for DeepSeek Harness
omdsh-dev/dsh-inspect
Adversarial closed-loop toolkit for DSH: checkup finds issues, fix repairs, review verifies, built on the official workflow engine.
dsh-inspect provides checkup, fix, and review tools for DeepSeek Harness, using adversarial mechanisms to ensure issue discovery, repair, and review are rigorously verified in a closed loop.
dsh plugin --profile web add github:omdsh-dev/dsh-inspect- Category
- Workflow & Automation
- Platform
- DSH-Plugin
- Author
- omdsh-dev
- Distribution
- Plugin
dsh-inspect Key Features
dsh-inspect Repository
dsh-inspect Repo Summary
dsh-inspect is an adversarial closed-loop plugin (DSH plugin) for DeepSeek Harness, maintained by omdsh-dev, licensed under MIT, and last updated in 2026-08. It addresses the problem of disconnected "find → fix → review" workflows with weak verification, providing a set of check/fix/review tools built on the official workflow engine. The three tools—checkup, fix, and review—share an "adversarial check" mechanism: default suspicion, find counterexamples, and only accept evidence verified on the spot.
What core features does the dsh-inspect DSH plugin's checkup tool offer for finding issues?
The checkup tool uses adversarial inspectors (each looking from one angle) → red-team attack validation (attempt to refute the issue claim; only those that survive are kept) → summary with severity levels (critical/major/suggestion). It emphasizes that "discovery is suspicion, verification is conviction"—issue claims must withstand attacks, and each issue must provide a mutually verifiable validation method (re-run reproduction / log comparison / input-output comparison / dual-path comparison). Issues that cannot be verified through system feedback are not reported.
How does the fix tool in dsh-inspect implement repair delivery?
The fix tool decomposes issues and implements fixes in parallel. Each implementer follows a three-step process: find root cause (trace data flow to the source of deviation) → implement → re-run reproduction validation (feedback closure). Then adversarial checks are applied, and after convergence of fix rounds, a delivery report is produced. It emphasizes that fixes must be falsifiable: find the source first, don't patch the surface; after fixing, re-run the original reproduction—if the issue persists, the root cause was not correctly identified, and analysis restarts.
How does the review tool in dsh-inspect perform quality review?
Review uses adversarial reviewers (each looking from one angle) to summarize with severity levels, and can accept a fixed_issues list to re-run reproduction for each item to confirm the issues are truly gone. If review fails or human feedback indicates dissatisfaction, the feedback re-enters fix, forming a closed loop. The three tools can be used independently or chained: checkup's issue list → fix's repair tasks → review's gatekeeping.
How to install dsh-inspect?
The package declares dsh.bundle.patch (cordis.patch.yml), installable via dsh plugin into any profile (replace <profile> with tui / headless / web or a custom profile):
dsh plugin --profile <profile> add git+https://github.com/dsh-external/dsh-inspect.git
dsh --profile <profile> # restart to activate: checkup / fix / review injected with profile
If pnpm rewrites the https URL to git+ssh, use the git+https:// form above; if dsh plugin prompts for allowBuilds, add a line to $DSH_HOME/profiles/<name>/pnpm-workspace.yaml as instructed.
What are the dependency requirements and development/checking methods for dsh-inspect?
The profile combination must include the official workflow engine and tool registration service—the official dsh base combination includes them, no extra installation needed; peer dependencies (such as @deepseek-ai/dsh-tools) are provided by the combination, and setting autoInstallPeers: false in the profile avoids requests to the registry. For development, use pnpm install (only typescript/@types/node), pnpm run typecheck (tsc -b, types resolved from sibling deepseek-harness checkout), and cd plugins/dsh-inspect && node --test for regression tests. Source is runtime: the package entry points directly to src/index.ts with no build step, requiring erasable-only TS syntax (no enum/namespaces, etc.).