dsh-memory-evolve: five-track memory and agent dispatch inside DeepSeek Harness

Five memory tracks, one of them scoped to a git branch

A DSH session starts cold. Switch project, wait two days, open a new conversation, and the assistant no longer knows who you are. dsh-memory-evolve addresses that from inside the session instead of asking you to paste a summary back in.

The memory side has five tracks. A user profile holds preferences, company and communication habits and is visible every turn. Global facts hold environment, tooling and conventions. Project key memory is the interesting one: conventions, decisions, architecture and mistakes already paid for, injected into context automatically, with any entry markable as effective only on a particular git branch. Project logs and a daily log record what happened turn by turn and stay readable later.

Nothing lands silently either. When you tell the assistant to note something, the memory waits in a confirmation queue and only takes effect once you approve it. Archived entries stop being injected and can be brought back.

The bundle patch registers itself, and a duplicate insert stops the host

Installation is one command and a restart. The plugin ships its own cordis.patch.yml, declared in package.json as dsh.bundle.patch, so the host registers the plugin without manual configuration:

# 1. 安装到 profile（本地目录用 link:，也可用 git/registry 包地址）
dsh plugin --profile web add github:csyangwen/dsh-memory-evolve

# 2. 重启 dsh web 即生效

What you must not do is insert the plugin by hand into ~/.dsh/profiles/web/cordis.patch.yml. The bundle patch already registers that id, and a second entry makes the loader report a duplicate loader entry id and refuse to start. It is the single most common way to end up with a DSH that will not boot.

One thing worth planning for: a plugin that breaks startup can be parked without removing it, by adding a top level entry with the same id and disabled set to true, then removing that line after the bug is fixed.

Settings are top level id entries, not inserts

Configuration lives in the profile patch as a top level entry keyed by plugin id:

- id: dsh-memory-evolve
  config:
    reviewEnabled: true      # 开启回合内记忆审查（默认关）
    reviewInterval: 10       # 每 10 个用户回合审查一次

reviewEnabled turns on in-turn memory review, which is off by default, and reviewInterval decides how often it fires, here every ten user turns.

Defaults matter more in this plugin than in most. Many of the added capabilities start switched off so they do not sit in the assistant's tool list, and the guide says so before any scenario: you enable what you need in the Memory Evolve settings pane, and the documented workflows only work once several of them are on together.

Uninstalling is the mirror of installing, and the plugin claims nothing is left behind:

dsh plugin --profile web remove dsh-memory-evolve

Early users carry one migration wrinkle. If you followed older documentation and inserted the plugin manually, that insert line now collides with the automatic registration, and the fix is deleting the line.

Memory sync targets a dedicated branch, or a repo holding nothing but memory

Two machines, one project. The sync module has to be enabled in the settings pane before it appears in the session tab at all, which is a two stage switch people miss.

Where the memory lands is the real decision. By default the remote is your own code repository and the memory is stored on a dedicated branch, so your working branches stay clean. If the code is public and the memory should not be, you point the plugin at a shared memory repository instead: one repository for all projects, one dedicated branch per project, memory separated from code.

A second machine clones the project, recognises it by repository address, pulls and carries on. Writes are saved as they happen, and when both machines edited the same memory the tab offers three choices, keep local, keep remote, or keep both. Four independent track switches decide what travels, so user profile, daily log and todos only cross devices if you open them. Projects without sync enabled stay purely local.

Four todo tracks isolated by working directory, logs tagged with the branch

Todos come in four tracks: life, work, project and daily. The project track is isolated by working directory, so three repositories open at once do not bleed into each other. Telling the assistant to remember a deadline turns the sentence into a project todo with importance, urgency and a due date, and at the end of the day it reminds you what came due.

Project logs are kept per directory as well, and entries carry a branch marker such as [git main], which makes a past decision traceable to the code state it was made in. Local file search sits on top of both: ask for a document by filename, or ask which file mentioned a term and get the matching file and snippet back.

The least obvious feature is the feedback log. Judgements you make about the assistant's work, praise and frustration alike, are written into the daily and project logs as a feedback line carrying sentiment, task category and your own words. Once enough accumulate you can ask which areas you have been unhappy with and get an answer grounded in that history.

The wake chain only survives while one DSH process stays alive

A main session can create standard sessions for visual design, frontend, backend and testing, pull them into one collaboration room, and pass your model and working directory into each. An Agent preset decides a new session's tool surface and personality. Room traffic is visible to everyone, including member status, and room messages can carry images that the receiving assistant reads from a file path and can forward to an IM channel.

Dispatch stays deliberate. Ask who is working and who is idle, tell an idle session to send its result, and the main session wakes it. Nothing is woken in bulk.

Conflict handling is what matters on a shared codebase. A session declares which files it intends to change, everyone else sees the claim, and the writer gets a conflict warning if it collides, with a separate workspace activity feed reporting parallel starts, ends and membership changes.

The boundary is stated plainly: the wake chain works only while the DSH process hosting the main session keeps running. If that process is shut down or the main session goes idle, the team stops, and one message from you restarts it.

External dispatch returns a task number, and the summary lands in memory

Heavy one-off work goes to an outside CLI agent: Kimi, Codex, Grok or Hermes. You ask for a dispatch, execution runs in the background, and a task number comes back immediately so the current session never blocks. Progress can be polled in conversation or watched as a log stream in the COI scheduling pane.

Two details make dispatch usable rather than decorative. The assistant can attach your project memory to the job, so the outside agent knows your conventions, and attachments are accepted from a local path, a remote URL or an image pasted into the current session. Codex, Kimi and Hermes read those images, Grok reads images through a prompt, and zcode refuses a pure text request outright.

When the job finishes, the summary is written automatically into the project log and the daily log. That is the hinge of the design. An outside agent's output becomes memory that internal sessions read on the next turn, so a redesign run by another model arrives as a specification rather than as a wall of chat.

Bookmarks give you a branch entry the host does not offer

The host can only branch a session from its last turn. dsh-memory-evolve takes over the branch entry point for any earlier turn, either from the branch button in the bookmark list or by pressing the official branch button and confirming when a middle turn is selected. The new session is created through the official channel, so it enters the host's own branch lineage instead of a parallel system.

Bookmarks are per turn and carry a name, the turn number, a time and a summary, and the list is searchable, which is enough to jump back to the turn where a decision was made. The input ring shows live context occupancy beside them: yellow at 30 percent, red at 40 percent, the point at which bookmarking or opening a new session is the cheap move.

The prompt library is the last piece: a searchable set of categorised instructions the assistant can select and inject into itself without interrupting its reply, or that you apply once, continuously every turn, or ad hoc as a temporary injection which is then saved for reuse. Work dispatched to a sub-session or an outside agent can carry the same prompt.

MIT licence, package version 0.1.0, and date code release tags

The package is MIT licensed, private and unpublished, versioned 0.1.0, ESM, with lib/index.js as the entry point and lib/client.js exposed for the client side. package.json also injects @deepseek-ai/dsh-client-runtime and targets the web platform, which is why installation is expressed in terms of profiles and why the guide's examples use a web profile.

Testing and building need nothing but Node: the test script is node --test 'tests/*.test.js' and the build is node scripts/build.mjs, with a tests/ directory and a pnpm-lock.yaml beside a vendor/ directory in the tree.

The release tags do not match the package version. GitHub releases are date codes, v26091501, v26092801 and v26092802 published in September 2026, and the last push landed on 2026-09-29, so there is no semver series to pin.

One gap in the written guidance: the guide at the repository root is in Chinese, and the copy here stops mid sentence inside the scenario on mobile access, session filters and notifications, where a de_notify channel pushes results to Feishu, QQ or WeChat. An English README, README.en.md, sits in the tree, alongside a detailed feature document and docs/ notes on memory sync and the changelog.

Editorial conclusion

Take it if you work in DeepSeek Harness across several days and several repositories and you are tired of restating decisions, and skip it if your assistants must never persist notes, because memory writes are the product. Before installing, check that no earlier manual insert of dsh-memory-evolve is left in your profile cordis.patch.yml, since a duplicate id stops the host from starting.

Frequently asked questions

Official sources

1. csyangwen/dsh-memory-evolve on GitHub
2. Issues
3. License: MIT
4. README
5. Releases