dsh-memory-spaces

In DeepSeek Harness, a useful decision, a project constraint, or a stated preference often stays locked inside the session where it was discussed. Copying those facts by hand is tedious and easy to skip, while dumping every conversation into one global memory pool risks leaking unrelated context into unrelated prompts. dsh-memory-spaces turns memory from a single on/off switch into a set of private, named spaces where you decide which sessions contribute, which sessions consume, and which memories actually reach the model on each turn.

The core design principle is separating contribution from consumption: a session can donate selected content without pulling in the whole space, and another can read memory without contributing anything back. No relationship silently copies conversation. Creation, membership changes, lifecycle actions, and destructive deletion are all human-governed through the UI or direct commands; the model has no tool for them. Automatic matches stay removable in the composer before you hit send, and confirmation mode injects only the candidates you explicitly select. Every memory version carries lifecycle state and application-level provenance, and the SQLite database lives entirely under the local DSH Profile with no remote invitation or cross-instance sync.

Who is it for? If you run several parallel Harness sessions-an architecture thread, a code-implementation thread, a task-tracking thread-and want their key facts, constraints, and preferences gathered into one visible, auditable, reversible shared set without letting any sensitive dialogue become globally retrievable, dsh-memory-spaces is built for that. It does not modify the Harness kernel, does not require a fork, and after a simple plugin install the Memory spaces entry appears in the sidebar ready for use.