dsh-memory

English · 简体中文

dsh-memory · Long-term memory plugin for DeepSeek Harness

A two-phase memory pipeline (per-session extraction → global consolidation), a summary that is always injected into new sessions, and four on-demand retrieval tools.

Why long-term memory

Without memory, every session restates user preferences and re-steps known landmines. dsh-memory extracts durable knowledge from finished sessions and periodically consolidates it into a dense navigation summary (injected into every session) plus a grep-friendly handbook, so future sessions need fewer repeated instructions, waste fewer tool calls, and avoid known failure modes.

The design is adapted from the Codex memories system (two-phase extraction/consolidation, three-layer artifact layout, job claims, cooldown, redaction) and re-composed for DSH: no SQLite, no git baseline, no resident consolidation subagent.

Features

• 🧠 Phase 1 per-session extraction: after a session turns stop (debounced, 3 min default), its log is read, filtered, rendered, and redacted, then a model extracts structured memory (raw_memory + rollout_summary + slug). Low-signal sessions produce an empty no-op.
• 🧩 Phase 2 global consolidation: on a cooldown (6 h default) the new raw memories are merged into MEMORY.md (handbook) and memory_summary.md (dense index, exact v1 first line); raw input is rotated into an archive and never consolidated twice.
• 📥 Always-injected summary: memory_summary.md (hard size cap) is injected through the system prompt of every session — zero effort for the model to see the index.
• 🔍 Four memory tools: memory_list / memory_read / memory_search / memory_add (writes only on explicit user request).
• 🔒 Safety discipline: session content is treated as data, never instructions; secrets are redacted on both input and output; memory paths are confined to the memory root.
• 🔁 Reliable scheduling: one durable claim per session (KV-persisted); restarts never re-extract or double-consolidate; failures retry with backoff; orphaned claims recover.
• ⚙️ Settings page: Settings → Long-term memory for stats, manual runs, and config.

How it works

turn end ──► Phase 1 (per session) ──► rollout_summaries/<slug>.md + raw_memories.md
                                            │
                              (cooldown elapsed / new memories)
                                            ▼
                                     Phase 2 (global)
                                            │
              ┌─────────────────────────────┴────────────────────────────┐
              ▼                                                          ▼
   memory_summary.md (injected into every session)     MEMORY.md (searched on demand)

Installation

[!NOTE] Requires DeepSeek Harness.

Naming: @nanmicoder/dsh-memory is the package identifier (@nanmicoder is the npm-style scope, dsh-memory the name). This plugin is distributed via GitHub (not npm):

dsh plugin --profile web add 'git+https://github.com/yan5236/dsh-memory.git#main'

Then verify the composition and start:

dsh --profile web --dump-config
dsh web

Open Settings → Long-term memory. Memory files live in $DSH_HOME/memories/ by default.

[!TIP] If dump-config does not contain the - id: dsh-memory row, the package is missing from the profile's dsh.profile.bundles array (the bundle patch layer is not applied) — add "@nanmicoder/dsh-memory" to that array.

📋 One-prompt install: let DSH do it

Copy the whole block and paste it into a DSH conversation; the agent installs, registers, and verifies the plugin for you:

Please install the DSH long-term memory plugin `dsh-memory` into the `web` profile.
GitHub repo: https://github.com/yan5236/dsh-memory

Requirements:
1. Run: dsh plugin --profile web add 'git+https://github.com/yan5236/dsh-memory.git#main'
2. Check $DSH_HOME/profiles/web/package.json: dependencies should include
   "@nanmicoder/dsh-memory", and the dsh.profile.bundles array should contain
   "@nanmicoder/dsh-memory" (add it if missing — without it the plugin's patch layer
   is not applied).
3. Run: dsh --profile web --dump-config — confirm the output contains "- id: dsh-memory"
   with no errors.
4. Restart DSH: stop the running `dsh web` process, then run `dsh web` again.
5. Verify: the settings page shows "Long-term memory", and the session tool list contains
   memory_list / memory_read / memory_search / memory_add.
6. If any step that writes into the DSH profile directory ($DSH_HOME/profiles) is blocked
   by a permission policy, ask the user to switch to Full access or approve the operation —
   do not bypass it or fail silently.

Configuration

The composition config provides the base layer (the bundled config: {} uses all defaults); the settings page overrides common entries and persists them to DSH storage:

- id: dsh-memory
  config:
    memoryRoot: C:/path/to/memories   # default $DSH_HOME/memories
    provider: deepseek-official       # optional: pin the pipeline model route
    model: deepseek-v4-flash          # paired with provider
    consolidationCooldownMs: 21600000 # consolidation cooldown (6 h default)
    idleDebounceMs: 180000            # post-turn idle window (3 min default)
    maxRolloutsPerRun: 3              # sessions extracted per run
    maxSummaryChars: 8000             # injected-summary character cap

See README_ZH.md for the full option table.

Memory layout

<memoryRoot>/
├── memory_summary.md          # injected navigation summary (first line `v1`)
├── MEMORY.md                  # handbook: preferences, procedures, failure shields
├── raw_memories.md            # Phase 1 output awaiting consolidation
├── raw_memories.archive.md    # rotated history of consolidated raw blocks
├── rollout_summaries/         # per-session recaps (evidence layer)
├── skills/                    # reusable procedures promoted by consolidation
└── extensions/ad_hoc/notes/   # user-requested ad hoc notes

Development

pnpm install
pnpm verify
git diff --check

Design and decisions: DESIGN.md.

License

MIT