Foreword¶

Anyone who has implemented an agent loop will encounter a common situation: after the model enters a “solving state,” it loses metacognition and repeatedly attacks the same problem in the same direction. It designs experiments biased toward the current hypothesis (confirmation bias), refuses to change direction (sunk cost), and rushes to conclude the story (narrative closure). The official repeat-tool-reminder is advisory; it only reminds the model that it repeated exactly the same call, but the reminder itself has no coercive force.

dsh-pain-point-check takes a different path: a veto-style guard. After an experiment on the same question fails to converge twice, the plugin injects three questions. Before the model answers the three questions in its reply text, it refuses all non-investigation tool calls and prevents retrying in the same direction. Below is an introduction to the plugin’s positioning, principles, and steps to enable it.

What is it¶

dsh-pain-point-check is a mandatory pain-point-check guard plugin for DeepSeek Harness (dsh), maintained by ICCuse, licensed under MIT, version 0.1.0, not yet published to npm, requiring installation directly from the GitHub repository.

It solves a specific problem: forcing the agent to return to the bottleneck itself after consecutive failures. The guard forces the model to answer questions related to the bottleneck before taking the next shot, turning negative results into information rather than skipping them directly. This also aligns with dsh’s “everything is a plugin” extension style—the guard logic does not invade the main loop but mounts as a plugin.

How it Works¶

The plugin orchestrates the guard through four hooks:

1. tools/result: Counts the number of experiments on the current question per agent, including failed (error) calls and consecutive identical calls.
2. agent/pre-step: Resets counters when the real user inserts a new question; when the guard is pending, it appends a three-question check block in the next step.
3. tools/pre-execute: When the guard is pending, it rejects all non-investigation tool calls. Tools in the allowlist can still be called, including read, read_image, glob, grep, web_search, ask_user_question, skill, todo_write—investigation and asking for help are not blocked.
4. session/event: Identifies answers to the three questions from the model’s reply text (e.g., bottleneck=… exclusion=… cost-effectiveness=…), also accepting English markers. The guard is lifted once identified.

The three questions injected are:

• Is this bottleneck still the most critical problem?
• What did the last negative result actually exclude?
• Which path offers the highest cost-effectiveness (not necessarily the cheapest)?

The second question is key: if the model cannot articulate what the negative result excluded, it has no falsifiable hypothesis. The check text requires it to write out a hypothesis first rather than firing another shot.

Installation and Enablement¶

The package is not published to npm; install directly from the repository:

npm install github:ICCuse/dsh-pain-point-check
# or: pnpm add github:ICCuse/dsh-pain-point-check

After installation, mount it in a profile combination. Taking the web profile as an example, add a line to ~/.dsh/profiles/web/cordis.patch.yml:

- id: pain-point-check
  name: 'dsh-pain-point-check'
  config:
    failureThreshold: 2
    repeatThreshold: 2

After restarting the harness (dsh web), the guard takes effect for each session.

Configuration¶

Available configuration options are as follows:

Both thresholds must be integers >= 1; configuration errors will be thrown directly during plugin loading, and the plugin will not run with errors.

The plugin declares two peerDependencies: @deepseek-ai/cordis ^4.0.1 and @deepseek-ai/schemastery ^3.18.1.

Development and Testing¶

The lib/ directory is pre-built (by the DeepSeek Harness monorepo toolchain) and can be installed and used directly. If you want to run tests:

npm install
npm test

The test suite drives the real agent loop using a scripted mock adapter, has no network dependencies, and covers triggering, rejection, allowlist, lifting, partial answers, resetting, and configuration validation.

Use Cases and Notes¶

Suitable scenarios: debugging, troubleshooting, long experimental tasks—places where the model is prone to repeatedly firing in the same direction. If your workflow frequently involves the model submitting similar failed experiments consecutively, this guard can pull it back to the bottleneck itself. If it is just occasional repeated calls, the official advisory repeat-tool-reminder might be sufficient; the trade-off lies in whether you need coercive force.

A few notes:

1. The plugin runs with the permissions of the current dsh process; you should check the source code and confirm the license (MIT) meets your requirements before installing.
2. During the guard pending period, investigation tools in the allowlist are unaffected; the model can still read files, search, and ask you questions.
3. The thresholds are set to 2 by default, meaning two failures or two identical calls will trigger it; if the task involves frequent trial and error, you can raise them as needed.
4. The package is not published to npm; version evolution follows the GitHub repository.

The value of this plugin lies in turning “negative results” from skipped noise into digested information. See the directory page at https://www.skillhub.cn/plugins/ICCuse/dsh-pain-point-check and source code at https://github.com/ICCuse/dsh-pain-point-check.