Preface¶

In DeepSeek Harness (DSH), the common usage is a single instruction filling the main agent’s entire round: you send a task, it finishes, you send the next. If the goal is “to achieve a specific standard for something and repeatedly try and improve within the budget,” a person has to stare at the conversation and urge progress time and again.

dsh-loom transforms a “single objective + budget” into a repeatable executable work chain in the background, iterating round by round in a child session, while the main agent remains idle most of the time; only when determining patch promotion, budget depletion, or a stuck loop, does it wake you via checkpoints. The entire process is logged in an append-only event log, facilitating replay and audit. Below is an introduction to what it is, what it can do, and how to install and start a typical campaign.

What is it¶

dsh-loom is a DSH workflow plugin released by maintainer DarknessLED (Community directory: skillhub entry, Source code: GitHub). Its positioning is Human-in-the-loop recursive self-improvement for DeepSeek Harness: after the main agent submits an objective and a budget, the plugin executes a “reconnaissance → multiple candidates → mechanical verification → scoring → promotion” chain in a child session, continuing to improve on the site of the previous round across multiple turns.

The name comes from “loom”: the warp (warp threads) is the objective and budget, the weft (weft threads) is the work chain of every round; humans are mainly responsible for changing the shuttle and acceptance (accepting patches, adjusting budgets, resolving bottlenecks).

The current README indicates that capabilities cover the M0–M8 stages (campaign lifecycle, event log, worktree isolation, checkpoints, cost accounting, knowledge tree, Lean Math Gate, chain self-optimization, sidebar RSI panel, multi-window and chaos hardening, etc.). Plugin version 0.2.1 (2026-11-10), license MIT; depends on dsh >=0.2.0-rc.2 <0.3.0-0, Node ^22.19 || >=24.

What problem does it solve¶

Compared to ordinary “Q&A filling the main turn,” the RSI form expects:

1. A person says a single sentence: “Achieve X at the Y level, budget Z”;
2. The system transforms this sentence into a repeatable executable work chain;
3. The chain runs round by round in the background, continuing to improve on the site of the previous round;
4. The main agent does not participate in every round, remaining idle most of the time;
5. Humans are only woken at checkpoints at nodes such as patch acceptance, budget increase, or whether the loop is stuck;
6. Every round writes to an append-only event log, allowing replay, audit, and reproduction.

The README emphasizes: these are real capabilities within DSH (tools, sub-session dispatch, panels), not prompt templates.

Core Features (Verified parts)¶

Campaign and Work Chain¶

• Campaign: Create, pause, resume, stop, change budget, add constraints.
• Work chain spec contains four types of nodes: agent / verifier / human / map, and provides experience templates (e.g., code-fix).
• Every round: git worktree isolation → spawn sub-agent (provider spawn) → mechanical verification → diff → scoring → promotion gate; if verified, has a patch, and is not worse than the incumbent, it can autoApply, otherwise it hangs at a checkpoint waiting for human decision.

Observability and Tooling¶

The plugin exposes a set of tools to the main session, including but not limited to: rsi_start, rsi_status, rsi_control (including global loop switch), rsi_run, rsi_chain, rsi_evalset, rsi_decide, rsi_report, rsi_lean, rsi_replay, rsi_dashboard, rsi_export, rsi_doctor.

• rsi_doctor: Startup self-check (git repo, workspace clean, Node, loom home writable, current window holding loop, etc.), failures come with an executable fix.
• Event Log: Append-only ledger + pure function reduce, materialized view views/state.json.
• Cost: Summaries assistant/message.usage from sub-sessions, converts to USD based on configurable unit prices, with double budget gates.

Interaction Boundary between Human and Main Agent¶

When human decision is required, it writes to checkpoint.raised and delivers a message to the initiating session via sessionController.prompt(mode:"queue")—the README explicitly states this is the only path to wake the main agent. Humans can handle this using rsi_decide(decision:"approve" | "reject" | "stop"); when approve is used, the plugin git applys the patch into the workspace.

Loop Scheduling and Master Switch¶

• Defaults to ticking approximately every 20 seconds, advancing one round for a running campaign (up to candidates candidates per tick, each with its own worktree + sub-session).
• The global switch is written to ~/.dsh/loom/switch.json; flipping it does not write into the campaign log; rsi_control(action:"disable" | "enable") controls whether dispatch continues, without offsetting the historical seq.

Sidebar RSI Panel (M7)¶

After restarting DSH, an RSI entry will appear in the sidebar; the panel polls status approximately every 5 seconds, supporting pause / resume / stop and approve / reject. When there are multiple windows, only the newest window drives the loop via heartbeat; older windows are read-only observers. The panel text is in Chinese, and status terms have fixed translations.

Data Directory¶

Campaign and ledger data default to ~/.dsh/loom/, which can be overridden with the environment variable LOOM_HOME; deleting that directory clears the plugin data and does not affect the DSH core.

Installation and Activation¶

Install from GitHub (the current available method from the README):

dsh plugin --profile desktop add DarknessLED/dsh-loom

You can also manually add dsh-loom to the profile’s dsh.profile.bundles; the cordis.patch.yml in the repository root is the bundle manifest, and dsh plugin add will recognize it.

The README also states: after the plugin is listed in the plugin market, you can search for dsh-loom in “Settings → Plugins → Plugin Market” for one-click installation; directory metadata can be found in data/plugins/DarknessLED__dsh-loom.yml in the awesome-dsh-plugin repository.

You need to restart DeepSeek Harness after installation for it to take effect.

Typical Usage¶

The steps below are excerpted from the README’s “Typical Usage” section, showing project initiation, registering evaluation tasks, activating the chain, and starting the loop.

1. Project Initiation (can automatically propose the code-fix template chain)

rsi_start(objective:"Achieve above 90% test coverage for src/parser, do not change public API",
          workspace:"C:/Projects/demo", budgetUsd:3, budgetRounds:10, template:"code-fix")

2. Register Task Set (each task contains a prompt and a mechanical verifier)

rsi_evalset(action:"register", tasks:[
  { id:"t1", prompt:"补 parser 对行内注释的测试", verify:{ cmd:"npm test -- --coverage", timeoutMs:600000 } },
  { id:"t2", prompt:"补 parser 对嵌套模板字符串的测试", verify:{ cmd:"npm test -- --coverage", timeoutMs:600000 } }
], holdout:["t2"])

3. Activate Chain and Start Running

rsi_chain(action:"activate", version:1)
rsi_control(action:"start")

Afterward, the plugin advances automatically according to ticks; you can check rsi_status / rsi_report at any time without interrupting the loop. If you need to pause dispatch for the whole night:

rsi_control(action:"disable", reason:"今晚不跑")
rsi_control(action:"enable")

It is recommended to run rsi_doctor before starting to confirm that git, Node, loom directory, and window ownership meet the running conditions.

Use Cases and Notes¶

Who is it for

• Developers or operators who have already built or maintained agents on DSH and want automated multi-round candidate selection and mechanical verification for tasks like code fixes and test strengthening, within dollar and round budgets, and are only willing to intervene at promotions or bottlenecks.
• People who need an auditable, replayable iteration process, rather than a verbal summary of progress in a single conversation.
• People willing to maintain a clean git workspace and write verify.cmd for evaluation tasks.

Important Notes

1. Permissions: The plugin runs with the permissions of the current DSH process; sub-sessions can execute verification commands you configure and rewrite the worktree; you should read the source code and MIT license before installation to confirm that the commands and paths are trustworthy.
2. Environment: The target workspace should be a git repository; timeouts on verifiers and depletion of budgets will trigger checkpoints or stops, so ensure budgetUsd / budgetRounds are set in advance.
3. Version: package.json requires dsh >=0.2.0-rc.2 <0.3.0-0 and Node ^22.19 || >=24, consistent with the README badges.
4. Ecosystem: The DSH community plugin directory (like skillhub.cn) is an independent site with no official affiliation to DeepSeek / Facet; the installation commands in this article follow the original README text; do not splice dsh plugin add github:... forms that do not appear in the materials.

Conclusion¶

dsh-loom turns RSI into a sustainable work chain within DSH: the main agent is idle, the child sessions iterate, and humans only make decisions at checkpoints, with the event log providing a trace throughout. If you want to try a round of “objective + budget + verifiable task set” in Harness, you can install, self-check, and initiate a project with rsi_start as described above.

• Directory page: https://www.skillhub.cn/plugins/DarknessLED/dsh-loom
• GitHub: https://github.com/DarknessLED/dsh-loom