What it does
Memory Evolve (dsh-memory-evolve) is a large pure-plugin bundle for DeepSeek Harness that starts from cross-session long-term memory and layers on optional “self-evolution” and multi-session helpers. The repository description names the headline features in one line: five-track memory, git-branch-aware project facts, in-turn self-review, skill self-evolution plus a skills manager, four-track todos, COI dispatch, session broadcast, session search, a prompt manager, and a scratch pad — “zero core changes, zero runtime dependencies.”
Install shape is GitHub-first. package.json is named dsh-memory-evolve at 0.1.0 and marked private; the npm registry returns 404 for that name. The documented install is dsh plugin --profile web add github:csyangwen/dsh-memory-evolve. The dsh block declares both a host bundle (bundle.patch: ./cordis.patch.yml) and a web client half (client.platform: "web"). There is no dsh.compatibility or peer pin, so this listing records no dshTarget and stops at L2. Scripts are only test and build — no preinstall / install / postinstall / prepare. Host-side lib/ imports Node builtins (fs, path, child_process, crypto); the client bundle expects React and DSH client runtime through the profile inject path. The README’s “zero runtime dependencies” claim is about the host package having no third-party dependencies field — not a claim that the browser half needs no framework.
The five memory tracks
Storage is plain-text markdown under $DSH_HOME/memories (default ~/.dsh/memories), not SQLite and not a graph DB. Entries use Hermes-compatible \n§\n delimiters. The five tracks:
| Track | Content | Injection | Write path |
|---|---|---|---|
User profile (user) |
Who you are, preferences | Injected each session (low-frequency, cache-friendly) | Suggestion queue → human confirms |
Global facts (memory) |
Environment, tools, conventions | Injected each session | Suggestion queue → human confirms |
Project key (key) |
Long-lived project facts | Injected for matching cwd sessions; git-branch filtered | Model suggests → confirm; UI can write directly |
Project log (project) |
Per-project progress | Not injected; read on demand | Per-turn auto-write |
Daily log (daily) |
What happened today | Not injected; read on demand | Per-turn auto-write |
Only the low-frequency tracks (user, memory, key) are injected into the snapshot, on a user-role tail with change detection so the system prompt and history prefix stay stable. Logs are written every turn (one entry per track when enabled) and fetched via the memory tool when needed — a deliberate cache-friendly split.
Key entries may carry [branch:main,dev]. At inject time the plugin runs git branch --show-current and only injects unscoped keys plus keys covering the current branch; the branch name is also injected with the key section. Log lines get an automatic [git main] tag the model cannot forge. Archiving (MEMORY-archive.md, KEY-archive.md, etc.) pulls entries out of injection without deleting them; promote restores them.
In-turn review and what is human-gated
Background “self-review” is not a subagent and not a second transcript. With reviewEnabled (default false), every N user turns (reviewInterval, default 5) the main LLM is expected to run a silent review inside its own turn, driven by a fixed snapshot hint plus memory_review_status. reviewMode: 'suggest' (default) routes global facts through memory_suggest into SUGGESTIONS.jsonl for human confirmation; auto writes globals directly. Project key suggestions always go through the confirm queue unless you write them yourself in the Memory tab.
Skills land in ~/.agents/skills by default. skill_manage enforces read-before-write (the agent’s session log must contain skill_manage action=read <name> before write). New skills default to <memoryDir>/pending-skills/ and only move into the live library when you approve; skillReviewEnabled (default false) would allow direct creation. Review can also propose optimizations to existing skills under that directory, still under the same write protections. The separate skills manager sub-tab (absorbed from the old dsh-skills-manager / dsh-skill-browser plugins — uninstall those first if you still have them) lists skills by source, can toggle enable/disable via disable-model-invocation, and manages custom skill directories. First boot migrates an old plugin’s disable list and custom dirs from its state.json once. The README’s three principles put this plainly: the AI proposes; you decide.
Todos (dtodo) are four tracks — life / work / project (cwd-isolated) / daily — as §-separated markdown with quadrants, due dates and status. You dictating a todo writes it; model-created todos must go through memory_suggest with a todo-* target. Todo bodies are never injected; the snapshot only carries a fixed hint to check due items, and the default dtodo list view is a capped smart view (overdue / today / current project / top quadrants) rather than a full dump.
A free-form scratch pad (scratch.md, 512 KiB cap, atomic write) lives as its own session tab — deliberately outside the §-parsed memory format so you can edit it freely.
What is optional (and mostly off)
Beyond memory, the package mounts many independent modules, each with its own switch and defaulting off so they do not occupy the model’s tool list until enabled: COI dispatch for external CLI agents (kimi / codex / grok / hermes plus custom adapters), session broadcast and rooms, workspace write-coordination, session search (Codex JSONL only), session orchestration (de_session spawn/wake), notify, prompt manager, canvas, bookmarks, advisor (per-session reviewer), model settings, UI settings, memory sync over git remotes, and local file search. Core memory, todos, skills and the Memory tab are on by default; the rest is opt-in via Memory Evolve Settings → 配置 (or profile config overrides). Turning a module off unregisters its tools; data files remain.
The always-on model surface is narrower than the feature list suggests: memory, memory_suggest, memory_review_status, skill_manage, dtodo, plus the Memory / Skills / Todos / Scratch tabs. Everything else (de_coi_*, de_broadcast, de_session, de_prompts, de_notify, de_canvas, …) only appears after you flip its switch. The web UI also carries many capability tabs; several modules ship in-plugin usage guides behind a 指南 sub-tab rather than a separate doc site.
Requirements and data location
- Install:
dsh plugin --profile web add github:csyangwen/dsh-memory-evolve, then restartdsh web. Do not manuallyinsertthe same id in the profile patch — the bundle patch already registers it, and a duplicate crashes the loader.disabled: trueunder the same id is the documented temporary kill-switch; uninstall isdsh plugin --profile web remove dsh-memory-evolve. - Harness version: not declared. Install docs target the 08-06+ profiles architecture; older copy-into-
~/.dsh/pluginsinstall is marked legacy. - Runtime: Node builtins on the host; client expects the web profile’s React / client runtime injects. No native compilation, no install-time scripts, no third-party host dependencies.
- Data:
~/.dsh/memories/holdsMEMORY.md,USER.md,SUGGESTIONS.jsonl, archives,scratch.md,skills-state.json, todo files, daily files, andprojects/<cwd-hash>/(project log, KEY, KEY-archive, todos). Pending skills sit inpending-skills/under the same tree. Uninstall is documented as cleaning plugin effects; treat the memories directory as yours to keep or delete manually.
Known limits
The package is huge — roughly sixty host modules plus a large client bundle — so “memory plugin” understates the surface and raises the cost of a misconfigured toggle. No harness version or peer range is stated. Most power features are off by default and do nothing until configured. Memory is curated markdown, not a ranked store: there is no vector search, no graph, no automatic decay; injection is the low-frequency tracks plus explicit tool reads. Review quality depends on the main model following the fixed turn-end protocol; a write-guard exists for missed log writes but is also off by default. Stars and commit activity are author-reported from the public repo (308 / 31 at time of writing); nothing here is an independent audit. Network is only what optional modules (sync push, COI CLI processes, notify, update checks) actually invoke — the base memory tracks are local files.
Versus the other memory plugins in this directory
graph-memory takes over the in-session history surface and recalls via a SQLite navigation graph with source-backed turns. mnemon / dsh-mnemon wrap a native Go graph engine with an external binary. dsh-memento is a typed memory service over SQLite with hard budgets and an approval gate in the service layer. Memory Evolve is different on purpose: Hermes-style file tracks, git-branch-scoped project keys, a propose-and-confirm queue, and a much wider optional toolkit (todos, skills evolution, multi-session orchestration). Use it when you want a durable working memory that grows into skills and todos without a second binary or a second LLM in the pipeline; prefer memento if you need typed service + audit budgets, graph-memory if you want turn-level source-backed recall of long chats, mnemon if you want a cross-framework graph store.
When to use it — and when not to
Reach for it if you re-explain project decisions every session, want project memory that respects git branches, and like the idea of the agent proposing skills and todos for you to approve. The five-track layout, branch filter, confirm queue and zero-dependency install are the parts the sources actually pin down.
Skip or go in carefully if you only need a thin memory layer: this is not that. Also skip if you cannot accept a large always-on footprint of tabs and tools on by default (memory/todos/skills), if you refuse any model-driven write path even behind a queue, or if you need a declared harness compatibility matrix — the sources do not provide one.
FAQ
Is the npm name installable?
No. npm returns 404 for dsh-memory-evolve; install from github:csyangwen/dsh-memory-evolve.
Does the agent write memory without asking?
Not for curated tracks. Global facts, user profile, key facts and model-created todos go through the suggestion queue; new skills wait in pending until you approve. Per-turn project and daily log lines are written automatically without confirmation — those are append-only progress logs, not injected context. reviewMode: 'auto' and skillReviewEnabled: true relax the gates for globals and skills respectively; leave them off if you want the propose-only default.
Where does my data live, and does anything leave the machine?
Local markdown under ~/.dsh/memories/ and skills under ~/.agents/skills. The base memory path makes no network calls. Optional modules you enable (memory sync push, COI external CLIs, channel notify, update checker) can use the network on their own terms.
Will it work on my harness version?
Unstated. The install docs describe the 08-06+ profile flow; there is no compatibility block in package.json. Treat version fit as unverified until you try it on your build.
How does this differ from just using Hermes-style memory files by hand?
It automates the protocol: snapshot injection with change detection, git branch tags and filtering, a suggestion queue, archive/promote, todos, skill read-before-write and confirmation, plus optional multi-session tools. The files stay human-editable markdown either way.