DSH plugin bot memory tree: a directory walkthrough

A dsh bot memory tree is just Markdown on disk, yet its shape decides what the bot can recall and what it will confuse. A DSH plugin reads the directory structure as a map of scope, so a misplaced file becomes a misplaced belief. The sections below walk from the root to a single entry and show what breaks at each level.

Why a DSH plugin bot stores memory as a tree

A tree makes scope visible, which is why a dsh bot remembers some things everywhere and others only in one project.

A flat file grows into an unsearchable pile, and retrieval cannot tell whether a sentence applies globally or to one repository. Directories add a second signal: the path itself says where a fact belongs. That signal is cheap for humans to read and cheap for a plugin to filter.

The tree also survives changes in tooling. Because the content is plain Markdown, it can be reviewed in a pull request, backed up with Git or opened in any editor. The DSH Plugin Hub is a good place to compare dsh bot variants, but the storage model tends to remain a directory of files. Portability is the reason teams tolerate the lack of schema.

The root of a DeepSeek Harness plugin memory tree

The root is a boundary, not a dumping ground, and everything below it should be memory.

Logs, caches, temporary exports and scratch notes do not belong at the root, because search will eventually retrieve them as if they were knowledge. The root should hold the topic directories and one index file that explains the layout. That index is the first thing a new maintainer reads.

memory/
  index.md
  conventions/
    naming.md
    review.md
  projects/
    atlas/
      decisions.md
  preferences/
    tone.md

A DeepSeek Harness plugin may create the directory automatically, but it cannot infer intent from a messy root. When unrelated files sit beside real memory, the boundary between observation and knowledge disappears. The usual symptom is a bot quoting an old export or a debug dump as though it were a team convention. Cleaning the root is therefore a recall fix, not just housekeeping.

Topic directories in a DeepSeek Harness bot memory tree

Topic directories answer what kind of knowledge lives here, so naming them by subject beats naming them by date.

Conventions, projects, preferences and debugging notes are stable categories that a person can predict. Dates and incident names multiply quickly and say nothing about the content inside. A small set of broad topics is easier to maintain than a deep taxonomy nobody remembers.

Pick one classification dimension and stay with it. A topic-first tree works well for personal bots and cross-project knowledge, while a project-first tree works better when several repositories must not leak into each other. Mixing the two creates paths like a project directory inside a conventions directory, and the scope of a fact becomes anyone's guess. The tree should make that question answerable from the path alone.

Directories also need an index or a short description. Without one, duplicate topics appear under slightly different names and recall splits between them. Periodic merging is normal, and it is cheaper than teaching every session which of two similar directories is authoritative. A directory that no longer has a clear purpose should be archived rather than left to accumulate.

What belongs in each DSH plugin memory file

A file is the smallest unit a bot can retrieve, so one topic per file is a retrieval decision rather than a formatting preference.

Each file should open with a short scope statement that says what the file covers and what it does not. That statement helps both a human reader and a parser decide whether the file is relevant. A file without a scope becomes a catch-all that is retrieved for the wrong questions.

The body should hold conclusions, not the process that produced them. A date, a source and a one-line reason make an entry verifiable, while a transcript of attempts makes it expensive to read. If the reasoning matters, link to the session or the decision record instead of pasting it into memory. This keeps the file small and keeps the evidence in the place that can correct it.

Heading structure should be preserved when editing by hand. A dsh bot may rely on headings to split entries, so flattening the hierarchy can silently change what is retrievable. Back up the file, keep the existing levels and verify recall with a question that depends on the edit. Direct editing is allowed, but it is still a schema change from the parser's point of view.

Failures caused by writing at the wrong level in DSH plugins

Writing at the wrong level does not look like an error, it looks like a bot with a strange memory.

A project-specific rule stored globally leaks into unrelated repositories, and the bot appears to ignore context. A global preference stored inside one project disappears as soon as another project is opened. Both failures are silent, because every individual file looks reasonable on its own.

File-level concurrency produces a different kind of silence. Two sessions editing the same file can overwrite each other, and the last write wins without any warning. The content that vanishes is usually the newer conclusion, which makes the loss hard to notice until someone relies on it. Splitting files by topic, or serializing writes, is more reliable than trying to merge after the fact.

1. Decide whether the fact is global, project-specific or session-only.
2. Move the entry to the directory that matches that scope.
3. Split any file that mixes two topics.
4. Remove process notes and keep the conclusion.
5. Add a scope line and a source to each entry.
6. Re-run a recall test from a different project.

The repair is mostly moving text, which is why it is tempting to postpone. But every misplaced entry keeps teaching the bot the wrong boundary, and later entries tend to follow the same pattern. A short review after the move confirms that the tree now answers the scope question correctly. DSH plugins that keep one fact in one place give a dsh bot a memory that can be explained, corrected and trusted.