dsh-longhorizon
用于长期运行 DSH 工作的已验证进度账本：独立验证器为每个声称完成的步骤进行认证；指纹检查会使任何修改了工作区的验证器所作的判定失效；已接受的轮次可在崩溃、压缩或新会话后继续保留。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:lion231226/dsh-longhorizon#a1c6691d8a35f96dad8542bca194899fe3d52b78Longhorizon 以 dsh-longhorizon 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A verified-progress ledger for long-running DSH work — where a verdict only counts if the thing that produced it provably stayed read-only.
A long-running task fails in a specific way: the agent reports progress it cannot prove, the report enters the transcript, and the next turn builds on a claim that was never checked. Nothing downstream can tell a verified step from an optimistic one, so the error compounds until the final answer is confidently wrong.
This plugin adds the missing check. When the agent claims a step is done, an independent verifier with a fresh context inspects the real workspace and returns a structured verdict. Only a clean, aligned, complete verdict enters the ledger. A rejected step stays in the ledger as evidence — it is never promoted to progress.
claim ──▶ independent verification ──▶ verdict
│
complete + clean + aligned ──▶ ledger (progress)
│
anything else ──▶ ledger (evidence only)
Read-only verifiers are usually enforced by asking the verifier to behave and by removing the write tools from its tool set. Both are prevention, and both are defeated by anything the tool filter does not name.
This plugin detects instead. The workspace is fingerprinted — every file's
size and mtime, plus a SHA-256 for files under the hash limit — immediately
before and after each verification episode. If anything changed, the verifier
mutated the workspace during a read-only audit, so its own findings are voided by
construction: the round is recorded as blocked / violation and can never be
promoted to progress, no matter how clean its report reads.
That matters because a verifier that writes is not a neutral witness. It can create the evidence it then reports, and no amount of prompt discipline or tool allow-listing proves it did not. A fingerprint comparison does not have to trust the verifier at all — which is why the ledger's admission rule can be absolute:
integrity === "violation" || contract !== "aligned" ⟹ status !== "complete"
This is enforced in code, not requested in a prompt. A verifier that omits a
control line degrades conservatively — an unstated integrity is read as
suspect, never as clean — because a placeholder must never be the thing that
certifies work as done.
1. Independent verification instead of self-report. The verifier is a separate subagent that inherits no conversation context. It reads the files and answers with three control lines:
Status: complete | incomplete | blocked
Integrity: clean | suspect | violation
Contract audit: aligned | unknown | needs_revision | invalid
2. A durable verified-progress ledger. Accepted steps are appended to
ledger.jsonl (one JSON object per line, fsync'd per append) with a last-wins
projection in state.json. A crashed process, a compacted context, or a fresh
session can reopen the run and answer: what is verified, what was rejected and
why, and what is left. Rejected rounds are preserved as evidence rather than
discarded, so a later turn can see which claims were already tried and failed.
3. Mutation detection. Described above; it is the admission rule for the ledger, not a side feature.
| Tool | Purpose |
|---|---|
longhorizon_verify | Verify one claimed step against the workspace; records the verdict in the ledger. |
longhorizon_ledger | Read back verified progress, rejected claims, and what remains. |
longhorizon_state | Current run state: verified rounds, pending claims, open items. |
dsh plugin --profile web add dsh-longhorizon
Then restart the harness. No build step: the package ships plain ESM and has no runtime dependencies.
Everything lives under the harness state directory, not in your project:
<state>/longhorizon/runs/<runId>/ledger.jsonl
<state>/longhorizon/runs/<runId>/state.json
<runId> is derived from the session id when there is one, otherwise from a hash
of the working directory, so reopening the same session reopens the same run.
The loop design is ported from LongHorizon-Harness (AMAP-ML, MIT) — manager/executor/auditor rounds, a durable round ledger, and an auditor that cannot certify a dirty result.
That project is a Python orchestrator that wraps an agent CLI. It does not run on
Windows: its persistent layer requires os.O_NOFOLLOW, os.O_DIRECTORY and
supports_dir_fd (all absent on win32) and it shells out with POSIX
VAR=value cmd templates. It also, by its own design, drives one agent CLI per
role episode — so on DeepSeek Harness it can only read the final answer of each
dsh --profile headless run, not the intermediate tool events.
This plugin takes the parts that carry the value — independent verification, the downgrade invariant, the verified-state ledger, the mutation guard — and implements them natively in the harness, where the events are available and no POSIX-only primitive is needed. Its workspace-mutation detection is its own contribution; the upstream project guards against verifier writes only through the same prompt-and-allow-list prevention described above.
npm test # 37 tests: verdict grammar, guard, ledger, tools, extraction
npm run verify # acceptance probe against the packed artifact
npm run verify is not a unit test run. It rebuilds the package from the
files list in package.json, loads the tool set out of that artifact, and
runs three scenarios against a real file system with a scripted verifier:
| Scenario | What it must show |
|---|---|
clean-verdict-is-progress | a clean verdict becomes progress, in one verifier episode |
positive-control-mutation-voids-verdict | a verifier that edits a file is caught; the round is blocked / violation and never becomes progress |
ledger-survives-a-fresh-context | a brand-new context reads verified progress back off disk |
The middle scenario is a positive control: if the fingerprint guard ever
stops noticing a mutation, positiveControlTripped turns false and the probe
exits non-zero, so a broken detector cannot be reported as a pass. The probe also
proves it ran — it records the artifact it loaded, the tool names it found, and
that all three scenarios reached a deciding assertion.
The result of the last run is committed: verify/acceptance-report.json
and the raw tool results and ledger contents in
verify/acceptance-evidence.json.
A subagent provider that does not inherit the parent context. The plugin
injects tools and subagents; the spawn provider shipped with the web and
headless profiles satisfies this. If only the fork provider is available, the
plugin refuses to certify anything and says so in the tool result rather than
silently falling back to a verifier that can see the executor's reasoning.
Windows: a PowerShell that can actually be spawned. DSH resolves pwsh
through a fixed candidate list (@deepseek-ai/dsh-pwsh-local); a Microsoft
Store PowerShell can leave a zero-byte execution alias in
%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exe. That alias is a regular file to
lstat, so it is selected, and Node then fails with
spawn ...\WindowsApps\pwsh.exe ENOENT. If your harness will not start for that
reason, point the resolver at a real binary:
# profile cordis.patch.yml
- id: pwsh-local
config:
pwshPath: 'C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe\pwsh.exe'
This is a host resolution issue, not a plugin one, but it is recorded here because it is the first thing that stops a Windows acceptance run.
MIT