Two DSH plugin memory stores: conflicts and migration

Two memory plugins looked like a sensible upgrade until sessions began forgetting facts they had just confirmed. The interesting part was not the failure but the shape of it: some content vanished, while other content appeared twice in every answer. This is how I separated the two DSH plugins with a token count and then decided whether to merge them or layer them.

The first symptom is forgetting, not a DSH plugin error

The first symptom was forgetting, and the second was duplication, which made a single cause unlikely.

I installed one plugin for session memory and another for project knowledge, and the first week looked successful. Each one had a sensible description and a clean install, and neither reported an error in the plugin list. The trouble started quietly, with facts that had been saved a day earlier and could not be recalled. Nothing crashed, which is why the failure took a while to name.

Forgetting had a physical explanation once I looked at the storage directories. Both plugins wrote records with similar timestamps, and the later write replaced the earlier one without a warning. A save that appears to succeed can still be lost when two indexers own the same file. The symptom looked like a recall bug, but the data was already gone before recall ran.

Duplication showed up in the answers rather than in the files. The model repeated a preference twice in one reply and used noticeably more tokens than before. Two memory blocks were being injected into the same request, each with overlapping content. That is not a smarter bot; it is the same context paid for twice.

Both symptoms can coexist because they come from different stages of the same pipeline. Writes collide, and then injections duplicate whatever survived. I fixed the write path first, because data loss is harder to reverse than a long prompt.

Reading two memory stores without trusting either DeepSeek Harness plugin

Before changing configuration I read what each DeepSeek Harness plugin actually stored and when.

The storage directories answered the first question: who owns which file. I listed file names, modification times and sizes, then compared the two trees for shared paths. One plugin kept a clean per-project directory, while the other wrote a single flat index that both sessions and projects used. That overlap explained the overwrites better than any log message.

Configuration answered the second question: what each plugin was allowed to do. I checked the storage path, the namespace setting, the automatic injection flag and the recall limit. Only one of them had a namespace configured, which meant the other was free to mix projects. A default value can create a conflict just as effectively as a deliberate setting.

Recall logs answered the third question: what the model actually received. Each plugin logged its retrieved items and the order in which they were injected. The logs showed two separate blocks with similar content, one longer than the other. Neither plugin was broken; they were both doing their job in the same slot.

I resisted drawing a conclusion until those three views agreed. The directories explained writes, the configuration explained scope, and the logs explained duplication. Once the stories matched, the experiment had a clear question to answer.

A token-based experiment isolates the responsible DSH plugin

A fixed prompt and a token count turned two suspects into one responsible DSH plugin.

I created a disposable profile, loaded ten known facts, and asked one fixed question that required all ten. The baseline ran with no memory plugin at all, which gave me the token cost of the question itself. Then I ran the same question with each plugin alone and with both enabled.

1. Record the baseline prompt tokens with memory disabled.
2. Run the question with only the first plugin installed.
3. Run it again with only the second plugin installed.
4. Run it once with both plugins active.
5. Compare the injected blocks, not just the totals.
6. Disable one plugin's automatic injection and repeat the pair.

The numbers were less ambiguous than the prose in either README. The first plugin added a stable block of about nine hundred tokens, and its answers used all ten facts. The second added a similar block but repeated four of the same facts, and the pair together crossed eighteen hundred tokens. The second plugin was also the one rewriting the shared index during writes.

That result narrowed the problem to a specific stage: the second plugin's writer and injector overlapped with the first. It was not a generic incompatibility between memory plugins, and it was not a model quality issue. The experiment did its job by turning a vague coexistence worry into two named mechanisms.

Merge or layer: what the DeepSeek Harness plugin setup should keep

The decision was merge or layer, and the data made the choice narrower than it first looked.

Merging meant keeping one store and moving anything unique from the other. The export has to include the memory files, the index and the session-level records, because files without an index are invisible to recall. Then the surviving plugin rebuilds its index, and three test sessions confirm that old facts still surface. The cost is a short migration window and the risk of importing noise.

Layering meant giving each plugin a distinct scope, with one owning session memory and the other owning cross-project knowledge. That only works when the scopes are genuinely separate and both plugins honor namespaces. Automatic injection has to be disabled on one side, or the duplication returns immediately. Clear ownership is the whole value of layering, and shared content destroys it.

I chose the merge because most of the second plugin's content already existed in the first. Its unique records were few, and its maintenance history was thinner than the plugin I kept. Layering would have preserved two moving parts to protect a small amount of data. The decision would flip if the two stores had held cleanly separated knowledge with little overlap.

The criterion is worth keeping even when the plugins change. Two stores earn their keep only when each answers a different kind of question and neither rewrites the other's files. Otherwise one store with a backup is the cheaper design.

What I changed in the DSH plugin profile afterward

The profile now runs one automatic injection, and the second DSH plugin is pinned rather than trusted.

I removed the second plugin through the normal removal flow after re-reading its DSH Plugin Hub entry, kept a copy of its directory, and rebuilt the index in the survivor. Three sessions with older facts confirmed that recall still worked and that writes stopped disappearing. The profile now has one injection point, which makes token growth easy to attribute. A future second plugin would need a namespace and a different scope before it gets installed.

Version pinning matters more after an incident than before one. I recorded both package versions in the deployment notes and checked the changelog before the next upgrade. After any upgrade I watch the token count on a fixed question, because that number reveals an injection change faster than a UI label.

DSH plugins can add real memory, but two of them do not add two kinds of intelligence. They add two chances to overwrite a file and two blocks in every prompt. The useful upgrade was not more memory; it was knowing which store owned which fact.