dsh-limit-break

Four small tools for DeepSeek Harness that came out of a self-benchmark: two things an agent is normally told it cannot do, made cheap enough to just do.

Tool	What it does
memory_recall	Ranked search over a JSON fact store that outlives the session. Omit query to list everything.
memory_save	Write or overwrite one fact: { id, statement, value?, unit?, details?, tags?, source? }.
resilient_fetch	Fetch with a four-rung ladder and a report of which rung answered.
memory_stats	Where the store is, how many facts, how big.

Zero npm dependencies. No import-time side effects. Everything fails soft — a broken store or a dead network returns an error object, never an exception that could take the host down.

Recall quality. memory_recall is measured, not vibed: tools/recall-bench.mjs runs 20 hand-labelled questions against the live store and prints hit@1 / hit@3 / MRR. At 1.5.0 the ranking skips English stopwords, stems, matches whole words (with a prefix fallback, so ray finds raytracer), splits dotted ids into segments, weights each query token by inverse document frequency, and rewards a whole-phrase hit: hit@1 0.75 → 0.95, MRR 0.867 → 0.975 on the same 20 questions and the same 20 facts. The one remaining miss is a genuinely ambiguous question that matches two benchmark facts.

Runtime requirement: curl. Rung 1 of the fetch ladder is plain fetch and needs nothing; rungs 2–4 (IPv6 → IPv4 → sibling hostname) shell out to curl, so it has to be on PATH. Windows 10+, macOS and mainstream Linux all ship it. Without it the ladder degrades to rung 1 and says so in the report instead of pretending it climbed.

Why these four

Memory. A session starts from zero. A store on disk plus a read at the start is enough to beat that. Measured with two brand-new agents, zero context, the same five questions: 5/5 with the store, 0/5 without — and the control did not hallucinate, it answered "I don't have that" five times.

Network. The reflex "this host is unreachable" is wrong more often than it is right. Measured on one network, same edge IP, 75 seconds apart: api.wikimedia.org → 200 in 0.43 s, en.wikipedia.org → connection reset in 1.21 s, api.wikimedia.org again → 200 in 0.39 s. The block was keyed on the TLS hostname, not the address. So the ladder tries, in order: plain fetch → IPv6 → IPv4 → a sibling hostname of the same service whose certificate still verifies (*/wiki/Title → api.wikimedia.org/core/v1/wikipedia/<lang>/page/<Title>).

It does not disable certificate verification and does not route through a proxy that would impersonate the origin. Those are MITM, not workarounds.

Install

dsh plugin --profile <profile> add dsh-limit-break

Then restart that profile. In the desktop app, install it from Settings → Plugins instead — the desktop profile is owned by the app's plugin manager.

The package declares dsh.bundle and ships cordis.patch.yml, so dsh plugin add mounts it with no manual editing. If you are mounting it by hand, add to profiles/<profile>/cordis.patch.yml:

- insert:
    - id: limit-break
      name: dsh-limit-break

A hand-mounted entry still needs the package on the profile's dependency list — a bare insert for a package the profile does not declare is silently ignored.

The store

$DSH_HOME/memory/facts.json, schema:

{ "schema_version": 1,
  "facts": [ { "id": "", "topic": "", "statement": "", "value": "", "unit": "",
               "details": "", "source": "", "timestamp": "", "tags": [] } ] }

Plain JSON on purpose: anything that can read a file can use it, with or without this plugin. Writes are tmp-file + rename, and a save takes a .facts.lock (created O_EXCL, stolen after 15 s if its writer died) around the whole read-modify-write, so two sessions saving at the same moment both keep their facts. tools/concurrency-selftest.mjs states the numbers: 16–17 of 48 saves lost before the lock, 0 after.

Disable / remove

• Hot: set disabled: true on the entry in cordis.patch.yml — Cordis recomposes in about a second.
• Cold: dsh plugin remove dsh-limit-break, then restart.
• The store is not deleted by either. It lives in $DSH_HOME/memory/ and is safe to keep.

Known limits

Measured, not guessed — each line is something a session actually hit.

• Tools are visible only to sessions opened after the mount. A session created before the plugin mounted keeps its tool snapshot; new tools do not appear until a new session. Not fixable from the plugin side (the tool list is materialised per session).
• Concurrent saves serialise, and wait at most 8 s. A second session saving at the same moment waits for the lock instead of losing its fact; if the holder is wedged, the save returns { ok: false, code: "memory.locked" } rather than hanging. Read paths take no lock, so a save still cannot stop a reader from seeing the previous snapshot.
• The fetch ladder is hostname-level. It does not defeat IP-level blocks, TLS interception, or a proxy that terminates the connection; it does not skip certificate verification.
• memory_recall ranks by keyword overlap only (id/topic/tags/statement/details), no embeddings: stopword-filtered, crudely stemmed word matching weighted by idf, so it is good at "which fact did I mean" and bad at paraphrase. tools/recall-bench.mjs states the current numbers (hit@1 0.95 on 20 questions); a query that shares no word with a fact still misses it.
• resilient_fetch reads at most 2 MiB per response and returns at most 20 000 characters; bigger payloads are truncated, not streamed.

Privacy

Nothing leaves the machine. resilient_fetch makes the request you asked for; the memory tools read and write one local file.

License

MIT.