Preface

When handling multi-turn tasks, project collaboration, or long-cycle work in DSH, a common problem is that context is easily lost after sessions end: user preferences, project conventions, confirmed decisions, and lessons learned from pitfalls have no stable cross-session entry point. dsh-biomemory provides a set of cross-session memory capabilities, expanding memory from individual log entries into a combined workflow of hierarchical storage, approval gating, semantic retrieval, memory metabolism, and audit snapshots.

The DSH community directory is an independent site with no official affiliation to DeepSeek / High-Flyer. Below is an introduction to dsh-biomemory’s positioning, core capabilities, installation method, and typical usage.

What This Is

dsh-biomemory is a cross-session bio-inspired memory plugin for DeepSeek Harness (DSH). It provides hierarchical memory, approval gating, memory metabolism, transparent snapshot injection, and memory retrieval based on SQLite and local embedding models.

Verified basic information:

  • Plugin name: dsh-biomemory
  • License: MIT
  • Runtime environment: engines.node: >=22.19.0
  • Repository URL: https://github.com/KLRSL/dsh-biomemory
  • Community directory page: https://www.skillhub.cn/plugins/KLRSL/dsh-biomemory
  • Current version: 0.5.2

The plugin’s dependency compatibility with DSH-related packages is as follows:

{
  "engines": {
    "node": ">=22.19.0"
  },
  "peerDependencies": {
    "@deepseek-ai/cordis": "^4.0.1",
    "@deepseek-ai/dsh-session": ">=0.1.0-rc.5",
    "@deepseek-ai/dsh-tools": ">=0.1.0-rc.5"
  },
  "dependencies": {
    "@huggingface/transformers": "^4.2.0"
  }
}

When enabled on the web platform, the DSH client injects the following packages:

@deepseek-ai/dsh-client-runtime
@deepseek-ai/dsh-client-ui-settings
@deepseek-ai/dsh-client-ui-slots

Core Capabilities

Hierarchical Memory Layout

dsh-biomemory uses a hierarchical structure under ~/.dsh/memory/ to store memories of different priorities. The verified layout includes:

~/.dsh/memory/
├── preferences.md
├── hot/
├── projects/<name>/
├── longterm/
├── archive/
├── backups/
├── audit.log
└── audit.jsonl

Corresponding capabilities:

  • User and project preferences: preferences.md
  • Hot knowledge and behaviors: hot/
  • Project context: projects/<name>/
  • Long-term memory: longterm/
  • Metabolic archiving: archive/
  • Backup directory: backups/
  • Audit logs: audit.log and audit.jsonl

In the SQLite data layer, the database file is located at:

~/.dsh/biomemory/biomemory.db

Local embedding models are located at:

~/.dsh/models/

Frozen Snapshot Injection

At session startup, dsh-biomemory injects frozen snapshots. The verified priority logic is:

  1. Pinned memories and user preferences are injected first.
  2. Recent knowledge or behavioral memories are injected next.

This reduces the model’s cost of repeatedly guessing user preferences during each session.

Approval Gating

Important memories go through approval gating. Verified strategies include:

  • Important memories typically require human approval.
  • Ordinary facts can be saved automatically.
  • When no approval channel is available, behavior is controlled by approvalFallback.
  • approvalFallback defaults to auto.
  • It can be switched to deny to maintain fail-closed behavior.

If the default auto is used when approval is unavailable, important memories may be automatically saved via a degraded strategy, and a degradation audit will be recorded.

Memory Tools and Commands

The plugin provides a memory tool supporting the following actions:

add / query / update / remove / list / pin / unpin / dream / audit

It also provides the /memory command, supporting:

list / query / add / edit / remove / pin / unpin / dream / audit

Cross-session recall can use the memory_recall tool, suitable for scenarios like “Do you remember how we agreed on this before?”

Deduplication uses content fingerprints to avoid duplicate entries.

SQLite Data Layer and Retrieval

dsh-biomemory’s SQLite data layer uses Node’s built-in node:sqlite with WAL mode enabled. Verified information: this SQLite data layer introduces no external runtime dependencies.

The local embedding model is:

bge-small-zh-v1.5

This model is a 512-dimension quantized ONNX model, invoked via transformers.js.

Verified retrieval modes include:

exact keyword
semantic vector
hybrid RRF fusion

If the embedding model is unavailable, retrieval degrades to keyword-only; memory functionality itself remains unaffected.

Automatic Markdown Migration

The plugin supports automatic migration from existing Markdown memories to SQLite. Verified migration behavior:

  • On first startup, existing ~/.dsh/memory entries are imported in a one-time operation.
  • Markdown is retained as a read-only backup.

Memory Metabolism (Dream)

Memory metabolism is triggered via /memory dream or memory action=dream. Verified metabolism capabilities include:

  • Half-life decay
  • Reference consolidation
  • Conflict surfacing
  • Cold archiving

The metabolism process supports checkpointing, allowing it to resume from the last checkpoint after interruption.

Before actual execution, the plugin automatically backs up the entire memory store to backups/<timestamp>/. If startup self-checks detect corruption in the primary memory files, it automatically restores from the latest backup. Rollback events are recorded as ROLLBACK audit events.

Audit and Rollback

Audit logs use structured JSON Lines. Verified audit capabilities include:

  • Aggregation by action
  • Aggregation by date
  • Aggregation by entry
  • Recording rollback events
  • Recording recovery events

Single-entry rollback supports the following methods:

memory action=restore fp="..."
/memory undo <fp>
POST /entries/restore

Conflict Surfacing and Deep Reflection

When behavioral memories conflict with user preferences, the plugin surfaces conflicting entries at the top rather than silently handling them. Verified display locations include:

  • memory action=list
  • Knowledge tab
  • Frozen session snapshots

In the Reflect view, conflicting entries support:

  • Edit
  • Delete
  • Undo

Deep reflection is triggered via the following entry points:

/memory reflect
memory action=reflect

Verified local reflection capabilities include:

  • Local topic clustering
  • Trend statistics
  • Conflict reminders
  • Forgetting candidates

Knowledge Tab

The settings page provides a Knowledge tab. Verified operations include:

  • Search
  • Hierarchical filtering
  • Viewing weight, hit count, timestamp, and pin status per entry
  • One-click pin / unpin
  • Inline editing
  • Safe deletion

Installation and Enablement

First, confirm that the DSH environment meets the following requirements:

engines.node: >=22.19.0
peerDependencies:
  @deepseek-ai/cordis: ^4.0.1
  @deepseek-ai/dsh-session: >=0.1.0-rc.5
  @deepseek-ai/dsh-tools: >=0.1.0-rc.5

Then install the plugin. The verified installation command is:

dsh plugin add dsh-biomemory

If using a local link method:

pnpm add link:./dsh-biomemory

After installation, add dsh-biomemory to the dsh.profile.bundles in the profile.

Typical Usage

Editing Memory Entries

Tool method:

memory action=update fp="..." text="..."

Command method:

/memory edit <fp> <new text>

Both methods modify the text of an existing memory entry. Verified behavior: metadata (pin / weight / layer) is preserved, old vectors are cleared, and an UPDATE audit event is recorded; duplicate content is rejected.

Rolling Back a Single Memory

If you need to restore a single memory after deletion, use:

memory action=restore fp="..."

Or:

/memory undo <fp>

The API method is:

POST /entries/restore

The restore source is the latest backup database, and a RESTORE audit event is recorded.

Triggering Memory Metabolism

Run directly:

/memory dream

Preview only, without modification:

/memory dream --dry-run

Execute dry-run via the memory tool:

memory action=dream dryRun=true

Triggering Deep Reflection

Command method:

/memory reflect

Tool method:

memory action=reflect

Applicable Scenarios and Notes

dsh-biomemory is suitable for the following DSH use cases:

  • Need to preserve user preferences and project context across sessions
  • Need to set approval or degradation policies for important memories
  • Need structured audit, backup, and rollback
  • Need combined local semantic retrieval and keyword retrieval
  • Need memory decay, consolidation, archiving, and conflict handling

Important notes before use:

  1. The plugin runs with the current DSH process permissions. Before installation, check the source code, license, and dependencies.

  2. The approval degradation policy defaults to auto. If you need to maintain fail-closed behavior when the approval channel is unavailable, switch approvalFallback to deny.

  3. When the embedding model is unavailable, retrieval degrades to keyword-only; memory functionality continues to work.

  4. The desktop pet bridge (DSH↔desktop-pet bridge) has been extracted into dsh-whale-pet-bridge; dsh-biomemory only retains memory save notifications.

  5. This article is compiled based on the verified README and package.json information; the original README is truncated at the Knowledge page continuation, so some page details are not expanded.

Related Links

Community directory:

https://www.skillhub.cn/plugins/KLRSL/dsh-biomemory

GitHub:

https://github.com/KLRSL/dsh-biomemory

The value of dsh-biomemory lies in turning cross-session memory into plugin capabilities that are approvable, retrievable, metabolizable, and auditable, rather than merely appending a block of text. For developers who need to retain context over the long term in DSH, it provides a relatively complete memory management entry point.