In the DeepSeek Harness (DSH) development workflow, agents often “confidently make mistakes” because the code is their own. When they reread their own diff, they keep getting the same answer and cannot fix those mechanical errors—for example, file parsing failures, unrunnable Shell constructions, proofs containing sorry, or type errors. These errors do not require judgment; they require checkers.

dsh-tool-strict-check is a DSH host plugin that introduces a tool called strict_check. It uses real checkers (the Lean 4 kernel, language compilers, Harness Shell danger rules) instead of subjective judgment to validate code and commands. The plugin is located in the admin-security category, is maintained by catsenior507, and is licensed under the MIT license.

Core Features

The plugin provides four checking modes, arranged from low to high cost:

  1. status: Probes whether each checker is available. It runs --version for each checker and reports which checkers are available and which are unavailable on the current machine.
  2. lean: Runs the Lean 4 compiler. To ensure strictness, it promotes warnings to errors and uses specific command-line arguments to prevent silent failures. This ensures that the Lean kernel genuinely accepts the proof.
  3. batch: Runs language compilers or parsers, including py_compile, node --check, tsc --noEmit, and the PowerShell parser.
  4. commands: Applies static rules to Shell text. These rules do not execute commands; they only inspect text patterns to prevent known dangerous Harness Shell operations.

In lean mode, the plugin explicitly disables the default automatic implicit arguments (-DautoImplicit=false) and uses -E hasSorry to specifically check for unfinished proofs. This ensures that files containing sorry are rejected, rather than passing merely because Lean treats it as a warning.

Installation and Enabling

The plugin must be installed into a DSH profile. The installation command is as follows:

# 从 GitHub 安装
dsh plugin --profile web add github:catsenior507/dsh-tool-strict-check

web is the default GUI profile for DSH, and can also be replaced with headless, sdk, or other custom profiles. After installation, restart the DSH host and confirm with the following command:

strict_check action=status

Optional Lean 4 Configuration

The batch and commands modes do not require Lean 4, but the lean mode does. If only the other modes are used, the Lean 4 installation can be skipped.

To enable Lean 4 checking, install the elan version manager and the specified toolchain. The plugin requires Lean 4.33.1 or higher, because earlier versions have kernel soundness vulnerabilities.

# 1. 安装 elan (Windows 示例)
Invoke-WebRequest https://elan.lean-lang.org/elan-init.ps1 -OutFile "$env:TEMP\elan-init.ps1"
& "$env:TEMP\elan-init.ps1" -NoPrompt 1 -DefaultToolchain none

# 2. 安装 Lean 4.33.1
& "$env:USERPROFILE\.elan\bin\elan.exe" toolchain install leanprover/lean4:v4.33.1

The plugin automatically locates the actual compiler under <ELAN_HOME>/toolchains/*/bin. If a specific toolchain needs to be locked, leanPath can be specified in the configuration.

Configuration

The installation command usually inserts the plugin line into the configuration file. To modify the default behavior, edit the cordis.patch.yml file for the corresponding profile:

- insert:
    - id: tool-strict-check
      name: '@dsh-external/dsh-tool-strict-check'
      config:
        leanPath: '<ELAN_HOME>/toolchains/<toolchain>/bin/lean.exe'
        projectDir: '<path to a Lake project, if your specs import one>'
        timeoutMs: 120000

Notes

The plugin runs with the permissions of the current DSH process and uses pnpm as its internal dependency management tool.

Note that the plugin currently does not support mathlib. Although the core libraries can work, the tactic libraries (such as ring, norm_num, etc.) are lost. In addition, the plugin does not provide sandboxed rechecking, nor does it perform “statement vs. intent” checks. It only verifies that code meets syntax and type requirements.

Summary

dsh-tool-strict-check aims to let the compiler “speak” and reduce agent waste on mechanical errors by enforcing real compiler rules. It is suitable for development scenarios that require rigorous code validation, but it does not promise to resolve all logical errors.