dsh-living-memory

dsh plugin --profile web add dsh-living-memory

dsh-living-memory




Built by 暖暖 (NuanNuan) — an AI assistant that built its own memory system.

A living, self-tending memory plugin for DeepSeek Harness (DSH).

Every conversation the agent has, every lesson it learns, every decision it makes is captured into a local

SQLite knowledge base — then actively tended: deduplicated, merged, decayed, cross-linked into a knowledge

graph, and patrolled every night. Memories fade when unused and resurface when relevant, like a hippocampus

rather than a log file.

Everything is local. One SQLite file. No telemetry leaves your machine; the optional embedding path is

off unless you configure it.

---

Why "living"?

Most agent-memory tools are retrieval layers: you write, you search. dsh-living-memory additionally runs a

nightly patrol that reorganizes the store on its own:

• Dedupe & merge — near-duplicate entries and high-similarity pairs are folded together.
• Temporal decay — entries lose retrieval weight over time unless reinforced; stale todos sink.
• Conflict detection — when a new memory contradicts an old one, both are flagged for review instead of

silently overwriting history.

• Knowledge graph — entities and co-occurrence edges are extracted continuously; Personalized PageRank

propagates relevance through the graph at query time.

• Snapshot & audit — daily snapshots, an on-disk audit trail, and telemetry panels in the DSH web GUI.

Hybrid recall — seven signals, one rank

A query fans out into seven independent signals fused by RRF:

# · Signal · Source

1 · Full-text · SQLite FTS5 with jieba tokenization (first-class Chinese)

2 · Vector · local KNN over embeddings (optional, see below)

3 · Decay · age × reinforcement score

4 · Relevancy · per-entry quality weight

5 · Co-occurrence · query-term pair statistics

6 · PPR · graph proximity from seed hits

7 · Hop · edge-distance boost

If any channel fails (e.g. no embedding key), ranking degrades gracefully to the remaining channels —

the plugin never hard-fails on a missing optional dependency.

Feature matrix

· dsh-living-memory · mem0 · Zep · Letta · graph-memory

Fully local, single SQLite file · ✅ · partial · ❌ · ❌ · ✅

Self-tending nightly patrol · ✅ · ✅ (cloud) · ✅ · ❌ · ❌

Temporal decay / reinforcement · ✅ · ❌ · ✅ · ❌ · ❌

Knowledge graph + PPR · ✅ · ❌ · ✅ · ❌ · ✅

Conflict detection · ✅ · ❌ · ❌ · ❌ · ❌

Chinese-first tokenization · ✅ · ❌ · ❌ · ❌ · ❌

Web GUI telemetry panels · ✅ · ❌ · ❌ · ✅ · ❌

Designed for DeepSeek Harness · ✅ · ❌ · ❌ · ❌ · ❌

Quick start

dsh plugin --profile web add dsh-living-memory

dsh plugin forwards to the profile's package manager — replace web with your own profile name

under $DSH_HOME/profiles. After a DSH restart the plugin registers its tools automatically:

• memory — search / timeline / stats / read_episodic / read_evolution
• memory_write — typed writes (fact / decision / todo / lesson) with optional relation edges

The bundled cordis.patch.yml mounts both roles (host + write) automatically — zero config.

To restrict write access to selected agent presets, remove the living-memory-write row from

that file and add it to those presets instead (comments inside explain how).

Data lives in ~/.dsh/dsh-living-memory/ (database + daily snapshots).

Optional: enable the vector channel

The vector signal uses a DashScope text-embedding endpoint via the DSH credentials pipe. Configure the

credential EMBEDDING_BAILIAN_KEY and the channel activates itself; without it, ranking runs on the six

remaining local signals. Your key is read through DSH's credential manager and never stored by this plugin.

How the agent uses it (intended workflow)

1. Search before acting — memory search <topic> is the first call when past decisions might matter.

2. Write what matters — decisions, lessons, and todos go in through memory_write with relation edges.

3. Read the timeline — memory timeline gives a reverse-chronological digest for orientation.

4. Let the patrol work — overnight consolidation keeps the store small, linked, and honest.

Project layout

index.cjs                 host plugin (SQLite schema, recall engine, nightly patrol)
client.js                 web-GUI slot (telemetry panels)
cordis.patch.yml          bundle patch — mounts the host + write roles, zero config
dict-custom.json          jieba dictionary, layer 1 (generic technical terms)
guard-rules.default.json  content-safety rules, shipped generic default set
scripts/preflight.cjs     prepublishOnly contamination gate (four-class scan)

Guard rules and dictionary are data, not code (0.1.4)

Everything the plugin blocks, warns about, or treats as a proper noun lives in JSON data

files rather than in index.cjs. Two reasons: you can tune the defense without patching

code, and a published package never has to ship a site-specific blocklist — an exhaustive

one would tell any reader exactly what slips through it.

Guard rules — three layers, first readable file wins as a whole (no per-rule union,

because a half-applied ruleset is much harder to debug than a replaced one):

Layer · Path · Contents

1 · ~/.dsh/dsh-living-memory/guard-rules.json · your machine's rules (chmod 600 recommended)

2 · <package>/guard-rules.default.json · shipped generic set: credential / prompt-injection / encoded-payload shapes

3 · GUARD_FLOOR in index.cjs · built-in last resor

…(truncated)