dsh-statecore — auditable project memory: auto-ingest, auto-inject, five native tools, digest on the host model

[yul761]

dsh-statecore gives dsh sessions persistent, auditable project memory: every fact carries an evidence id and a version chain, and forgetting is a logged retirement, not a delete.

Repo: https://github.com/yul761/dsh-statecore (dsh-plugin topic) · npm: dsh-statecore · Engine: StateCore

What it does

• Auto-ingest — every user/message / assistant/message flows into per-project memory via ctx.on('session/event'). No model cooperation needed; an MCP memory server can only be pull, a native plugin can also push.
• Auto-inject — an agent/pre-step waterfall folds a budgeted memory digest into context each session, mirroring the fold pattern @deepseek-ai/dsh-agent-instructions uses for AGENTS.md. In the transcript it shows up as its own Context injection · dsh-statecore row next to dsh's first-party injectors.
• Five native tools — remember / recall / facts / why / forget registered through dsh-tools with honest JSON output.schema, so Code Mode can await tools.why({factId}) and get a structured evidence chain. Registration is an effect; dispose unregisters cleanly (HMR-safe, tested).
• Digest on the host's own model — consolidation runs through ctx.llm. Whatever model you already pointed dsh at drives memory distillation; there is no second API key to configure.
• Cross-tool shared store — the same ~/.statecore store is served to any MCP client by statecore-mcp. In my live test, a fact remembered inside a dsh web session was immediately visible from Claude Code's facts tool, because both resolve the same project scope.

Install

dsh plugin --profile web add -w dsh-statecore
dsh --profile web

The package declares "dsh": { "bundle": { "patch": "./statecore.cordis.yml" } }, so profile bundle reconciliation wires it up automatically — no manual --patch after install.

Verified live against dsh@0.1.0-rc.6 (web app, DeepSeek-V4-Flash): plugin row in --dump-config, both consumers active, all five tools callable by the model, and a second session receiving the first session's facts by injection alone.

Two small rc.6 findings from real installs (feedback)

1. dsh plugin --profile <p> add <pkg> needs -w today: profiles ship a pnpm-workspace.yaml, and pnpm refuses to add to a workspace root without it. Either passing -w internally or documenting it would smooth the first-plugin experience.
2. pnpm inside a profile skips dependencies' postinstall (build-script approval), which bites any plugin whose deps generate code at install time (Prisma here). A note in the plugin-install docs — or surfacing pnpm approve-builds in the CLI output — would help plugin authors.

Both are documented with workarounds in the plugin README. Happy to file issues for either if useful.

I tried to build this the way dsh's own AGENTS.md asks its packages to be built — real-composition tests over actual dsh-tools/dsh-session/dsh-agent registries rather than mocks, HMR/disposal coverage, config with no hardcoded tunables, misconfig failing loud — because the harness's conventions are genuinely good and the best way to showcase a plugin system is to follow them. Feedback very welcome.

[leenkcool]

#1728 可以自己提PR收录 。记得互相赞赏。

[yul761]

Update: dsh-statecore@0.2.0 — compaction that doesn't forget, plus a Settings page 🧠

Two new capabilities since the original post, both live-verified on dsh@0.1.0-rc.6.

1. Compaction that doesn't forget

The most common complaint about long agent sessions everywhere: after a compact, the model forgets what you told it. This release closes that loop through dsh's compaction seam — a plain session/event consumer listens for the seam's compaction/summary record (so it composes with any compaction backend, first-party or third-party, with zero package coupling — @deepseek-ai/dsh-compaction is a types-only devDependency), and reacts twice:

1. Distill now, not at the threshold. Everything shadowed was already auto-ingested as it happened; compaction is the moment its raw form leaves the model's view, so the plugin demands an immediate digest via the engine's new MemoryBackend.digestNow() (threshold-1, honest outcome union, never rejects).
2. Re-inject after the replacement. A compaction can shadow the previously injected memory context, and the plugin's dedupe fingerprint would otherwise skip re-injection because the memory content is unchanged. The fingerprint is dropped on compaction/summary, so the next agent/pre-step folds memory back into the post-compaction surface.

Here's the live transcript: /compact runs, and the very next turn re-injects Context injection · dsh-statecore — the model confirms the fact (by id) survived the compact without calling a single tool:

Behind that screenshot, the compaction-demanded digest also ran for real — through the host's own ctx.llm (DeepSeek-V4-Flash in my test), writing a fresh digest row seconds after the compact. No separate key, same as before.

2. A "StateCore Memory" page in Web Settings

The plugin now ships a browser half: pick a project scope, browse its grouped facts, open any fact's evidence chain (why — ids, evidence, confidence, timestamps), and retire facts with a two-click audited forget (nothing is deleted; the record is kept and marked retired).

Ecosystem note for other plugin authors: the client half is built with plain esbuild — no host-internal build presets needed. A dsh.client declaration plus exports["./client"] pointing at a bundle in the loader's factory format (window.__ModuleLoader__.load({id, factory}), platform modules like react left external) is everything the client module system requires from an out-of-tree package. The data side is a nested plugin gated on inject: ['webServer'], so headless hosts just leave that fiber pending. Happy to write this up in more detail if it's useful to others.

Also in this release

• Ingest now only records the conversation, not the scaffolding: machine-composed user/messages (AGENTS.md context injections, compaction checkpoints, the plugin's own memory injection) are recognized by MessageSource and skipped. Only kind: 'user' turns and assistant messages feed memory.
• Team memory guide: one self-hosted StateCore deployment as the shared brain for every agent your team runs (dsh via url, any MCP host via --url, one audit trail) — docs/team-memory.md.

dsh plugin --profile web add -w dsh-statecore   # or update the pinned version in your profile

Repo: https://github.com/yul761/dsh-statecore · npm: dsh-statecore@0.2.0 + statecore-mcp@0.3.0

[yul761]

Update: dsh-statecore@0.4.0 on statecore-mcp@1.0.0 🧠

The engine underneath this plugin just reached 1.0, and the plugin now depends on it:

• No install scripts, no native modules. The embedded store moved from Prisma to Node's built-in node:sqlite. The pnpm approve-builds / manual postinstall step from the original post is gone — dsh plugin --profile web add -w dsh-statecore is the whole install. Needs Node ≥ 22.13.
• Data files are versioned. ~/.statecore/statecore.db carries a schema version and upgrades in place; 0.6.x files open unchanged. statecore-mcp export dumps everything (events, digests, active fact registry, handoffs) as JSON.
• Keyless use is visible instead of silent. remember reports whether distillation was scheduled or deferred; the facts tool reports how many captured events are still waiting; statecore-mcp digest runs one pass on demand once a key is configured.
• Stable surface. The six tools and the CLI are frozen additive-only for 1.x (README "Stability" section). --url mode's facts now carries factId too (engine contract 1.7.0), so why needs no recall detour.
• The same store is now also fed by a Claude Code plugin with hook capture (plugins/claude-code in the engine repo) — a fact remembered there shows up in your dsh session and vice versa, same as with statecore-mcp before.

Repo: https://github.com/yul761/dsh-statecore · npm: dsh-statecore@0.4.0 · engine release notes: https://github.com/yul761/StateCore/releases/tag/v1.7.0