Preface

When collaborating with agents for development, a common pain point is that technical choices, constraints, and pitfalls established in the current session are lost in the next session. You either have to re-explain it every time, or let the model write to the memory file on its own—the latter carries the risk of no verification, meaning the model’s written content may have long since become inconsistent with the current code.

dsh-project-memory addresses this issue by transforming persistent decisions, constraints, conventions, lessons learned, and facts into versioned project records. However, the model can only propose; whether a record is stored is decided by a human. DeepSeek Harness (DSH) follows the philosophy of “everything is a plugin,” and this plugin is an extension of memory capabilities along those lines.

What is this

The positioning of dsh-project-memory can be summarized in one sentence: it provides DeepSeek Harness with “evidence-backed, human-approved” project memory. Author: luoyuejun9. License: MIT © 2026. Plugin Version: 0.1.0. Target Harness Version: 0.1.0-rc.6. It should be noted that DeepSeek Harness is currently in developer preview. As the Harness API evolves, the plugin may require updates to keep pace.

Core Design

Human Approval is a Hard Boundary

Model tools cannot approve or archive memory. Among the tools exposed to the model by the plugin, search, read, and validate are read-only; there is only one write-restricted proposal tool. The only way to promote a candidate memory to an approved one is for a human to execute /memory approve.

Evidence is Verifiable

Each memory is accompanied by evidence references, recording the project’s relative path, precise line ranges, optional symbols, and SHA-256 hashes. The source code snippets themselves are not copied into the memory. Instead, the memory stores “which file, which lines, and what the hash was at that time.” After changes to the source code, execute /memory validate; it will report the evidence status for each entry as verified, stale, or missing.

Conflict Handling

When there are conflicting active memories, you must declare the superseding relationship via supersedes, or explicitly use --keep-both to retain both simultaneously; vague coexistence is not allowed.

Local and Deterministic

The search is deterministic and local; it does not use embeddings and does not rely on cloud databases or backend services. Approved entries are Git-friendly JSON.

Installation and Enablement

dsh plugin --profile web add dsh-project-memory

After installation, you need to restart the selected Harness profile.

Environment Requirements: Node >= 22.19. Peer Dependencies: @deepseek-ai/dsh-agent, @deepseek-ai/dsh-commands, @deepseek-ai/dsh-llm, @deepseek-ai/dsh-tools (0.1.0-rc.6), and @deepseek-ai/cordis (4.0.1).

Commands and Typical Workflow

Commands provided by the plugin:

/memory capture [note]
/memory candidates
/memory approve <candidate-id> [--keep-both]
/memory reject <candidate-id> [reason]
/memory search <query>
/memory show <memory-id>
/memory validate [memory-id]
/memory archive <memory-id>
/memory timeline

The daily workflow is roughly as follows:

  1. When a decision or lesson worth documenting appears in the session, use /memory capture [note] to submit a candidate memory.
  2. Use /memory candidates to view the list of candidates.
  3. After manual review, use /memory approve <candidate-id> to approve, or /memory reject <candidate-id> [reason] to reject and note the reason. When there is a conflict, choose supersedes or --keep-both according to the rules above.

Maintenance: Use /memory search <query> for retrieval, /memory show <memory-id> to view details, /memory validate to verify evidence status after source code changes, /memory archive <memory-id> to archive, and /memory timeline to view the timeline.

Storage and Team Sharing

Storage Paths:

.dsh/project.json
.dsh/memory/index.json
.dsh/memory/entries/memory_*.json
.dsh/memory/candidates/candidate_*.json

When the team needs to share memory, simply commit .dsh/project.json, .dsh/memory/index.json, and .dsh/memory/entries/ into the repository. Candidate files can remain local until they are reviewed and approved.

Suitable Scenarios and Notes

Suitable Scenarios: Long-term evolving projects need to retain decisions and constraints across sessions; teams want to share a human-vetted memory via Git; or the environment requires memory content to be traceable to the source code without introducing embeddings or cloud services.

A few notes:

  1. DeepSeek Harness is still in developer preview. This plugin targets version 0.1.0-rc.6, and the plugin may need updates if the Harness API changes.
  2. The plugin runs with the permissions of the current dsh process. Before installing, it is recommended to read the source code and the license (MIT). The repository provides development commands; you can run npm install, npm run check, and npm pack --dry-run locally for verification.

Conclusion

dsh-project-memory splits “memory” into two steps: the model is responsible for proposing and citing evidence, the human is responsible for approval, and SHA-256 verification is responsible for detecting expiration. For DSH users who care about memory reliability, this is worth a look.

  • GitHub: https://github.com/luoyuejun9/dsh-project-memory
  • Plugin Directory Page: https://www.skillhub.cn/plugins/luoyuejun9/dsh-project-memory

The directory page is a community-maintained independent site and has no official affiliation with DeepSeek or Manifold.