dsh-compact-receipt
⚠️ Beta (0.4.0-beta.1)
A default install is safe: it records, audits and guards; it does not change compaction.
The compaction takeover is experimental and has not been exercised by a real compaction yet.
Two end-to-end runs never triggered compaction (likely auto not enabled or a threshold floor),
so the pinned block has never been produced in a live session - only unit-tested.
The takeover is off by default and requires both engine: true and disabling the compaction-basic
row. Until a real compaction verifies it, do not use it on important sessions.
中文 | English
Long conversations don't forget. Nobody tells you when they started.
Context compaction in DSH is silent and lossy: a range of history is replaced by one summary,
and from then on that summary is all the model can see. The "don't touch tests/" you said 40 turns
ago may have vanished in a compaction — with nothing to indicate it.
This plugin hands you a receipt after every compaction: how much was eaten, and which of your
requirements no longer appear in the summary.
This session compacted 1 time, most recent:
Receipt #1 · 18:42:07 · ate 24 history items (~8.2k tokens)
5 commitments · 4 survived · 1 possibly lost
⚠️ Possibly lost (not found in the summary — please confirm):
1. [constraint] don't touch tests/ · turn 7
Lifetime survival: 80% (4/5)
Not another context dashboard
Existing tools measure how big the context is (dsh-context) or make it smaller (billion-context).
This one measures a different thing: after compaction, are the things you asked for still there?
- Others optimize token count; this audits semantic fidelity
- Others ask you to pin a passage by hand (
dsh-highlightpin); this is automatic and zero-config
- The audit never calls a model: the summary is a string, your requirements are strings, so the
comparison is string comparison — zero token cost, cheap enough to run on every compaction
Install
dsh plugin --profile web add github:cty-09/dsh-compact-receipt
Restart DSH. No configuration, no toggles.
Usage
| Command | Purpose |
|---|
/contract | Latest receipt, commitments still in force, lifetime survival rate |
/contract guard off | Disable blocking (on by default) |
/contract unblock <id> | Lift one rule |
Architecture (v0.3)
- Semantic classification: one batched call over the shadowed messages adds the phrasings the rules
miss ("tests 目录先别碰") to the commitment table - this is what moves coverage from rules to the model.
- Semantic judgement: commitments plus the new summary go to the model in one call that
returns kept/lost/unclear. If it cannot answer, the rule scorer runs and the receipt says so.
- Delivery is verified: an injected message echoes back as a
user/message event; the receipt
only claims "confirmed delivered" when that echo arrives. A successful write is not delivery.
- Classification probe:
/contract probe measures what a pinned policy would keep and how much
context it would cost, without changing anything.
- Rule-layer accuracy is measured, not asserted:
test/corpus.js holds 21 labelled messages and
npm test prints the score. Today the rules reach 86% (100% precision on constraints, decisions
and acceptance; 70% constraint recall) - postposed negations like "tests 目录先别碰" are the misses,
and the semantic layer covers them.
It also does two more things
1. It tells you inside the conversation. When a compaction drops requirements, a receipt card appears
in the chat — visible in the Web UI without remembering any command. That card also hands the dropped
requirements back to the model, so it is both an alert and the cheapest possible repair.
2. It blocks contradicting writes. Once "don't touch X" is recorded, a write-family tool call targeting
X is denied, with a message telling the agent to confirm with you first, or you to run
/contract unblock <id>. Only file-writing tools are covered, and matching is path-string based:
missing a block is preferable to a false block.
What counts as a requirement
Three kinds, matched by rules (Chinese and English):
| Kind | Examples |
|---|
| constraint | don't touch X, must use Y, 不要改 X, 必须用 Y |
| decision | we'll use X, 决定采用 Y |
| acceptance | acceptance: tests must pass, 验收标准是 X |
Extraction is deterministic: same input, same output. No cost, no network, reproducible.
Honest limits
This plugin does not pretend to be smarter than it is:
- "Possibly lost" means possibly. A summary that keeps the meaning but rewords it can trigger a
false alarm. The threshold deliberately prefers false alarms over silence.
- Only the compacted range is audited. Requirements still in context are not audited, because
they were never dropped.
- Rule extraction misses things. It recognizes common imperative phrasing and nothing else. It
does not guess.
- It does not prevent compaction and cannot restore the original text. It makes the loss visible and
puts the dropped requirements back in front of the model.
- Blocking is path-string matching. Only file-writing tool arguments are inspected; a different spelling
of the same path (symlink, relative form) can slip through.
- No dedicated sidebar panel. A client plugin needs the custom
window.__ModuleLoader__ bundle
format, ctx.slots, and a React build; this version does not ship one. Visibility comes from the
in-conversation card and /contract.
- It does not take over the compactor. Replacing
CompactionEngine means reimplementing
summarisation, range selection and checkpoint writes, reachable only from a long live session and
not verifiable offline. This version guarantees at the compaction boundary (re-inject + echo
confirmation) instead of replacing the engine.
- The card costs tokens. It only appears when something was actually lost — typically 4-6 lines, far
less than the loss it prevents.
How it works
DSH writes a compaction/summary event carrying the summary text and the seqs of shadowed history.
The plugin subscribes to the session event stream, extracts commitments from user messages as they
arrive, and on compaction scores each one against the summary text: exact match for Latin
identifiers, character-bigram overlap for Chinese, averaged. No model calls, no network, no extra tokens.
Development
npm test # 20 cases, including an end-to-end simulation
Zero dependencies, zero build step: the ESM in lib/ is the published artifact.
Why no imports at all: @deepseek-ai/* runtime packages exist only inside the DSH install,
not in a profile, and DSH registers no ESM resolve hook. Any third-party plugin that imports them
fails with ERR_MODULE_NOT_FOUND on a user's machine. This plugin therefore uses ctx only.
License
MIT
