# dsh-synapse draws the session map but never becomes the session

> A DeepSeek Harness plugin that puts conversations, follow-ups and branches on a draggable canvas while the native session log stays the single source of truth. The canvas layout lives in its own directory, the build is three syntax checks, and the patch supports one profile.

**liangmianya/dsh-synapse** — A visual, non-linear conversation workspace plugin for DeepSeek Harness ; A canvas-based session explorer and branching workspace for DeepSeek Harness.

- Repository: https://github.com/liangmianya/dsh-synapse
- Stars: 462 · Forks: 48
- Language: JavaScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/liangmianya-dsh-synapse

## The canvas is a projection of committed events, nothing more

The boundary statement is the design in one line: the DSH session log holds the real session content, and Synapse only projects committed events.

Four capabilities follow from that constraint. A conversation map puts consecutive follow-ups, branches and separate sessions onto one operable canvas. Real branches are preserved by connecting cards according to DSH's native fork relationships, so no second session history is manufactured. Selecting text in an answer carries it into a new follow-up, with the common supplement words being editable. And switching sessions in the map or in the native conversation keeps the current context consistent.

That last one is the point of the plugin: it is a different view onto the same session, not a parallel store you have to reconcile.

## Layout data is disposable and lives outside the session log

Canvas layout data is stored under $DSH_HOME/synapse/, and deleting it does not delete DSH sessions.

That separation is what makes the projection safe to throw away. Positions, zoom and grouping are yours and regenerable; the conversation is DSH's and persistent. Uninstalling or clearing the directory costs you the arrangement and nothing else.

It also means there is no migration story to worry about. A new version that changes its layout format can discard the old directory without touching the underlying sessions, which is the same reason there is no export button.

## The plugin patches nothing that touches a model request

Five boundaries are stated, and four of them are negative. The plugin does not modify prompts, model requests, tool schemas, provider routing, or reusable KV-cache prefixes.

That list is what a reviewer should want to see from a UI plugin, because each of those is a place where a rendering change could quietly alter behaviour. Prompts and tool schemas in particular are the two places where a project that says it is only drawing a map could still change what the model sees.

The fifth boundary is narrower rather than negative: the bundled patch supports only DSH's web profile. So a user on another profile has no install path here at all, rather than a degraded one.

## One web server, no second application

After install you switch to the session map from the top of the DSH interface, and Synapse reuses the existing DSH web server. It does not start a second application or a proxy system.

That is a deployment claim with a practical consequence. There is no second port to forward, no second process to supervise, and nothing that fails independently of the harness it lives inside.

The package manifest matches that shape. The client block names the web platform, injects the DSH client runtime package, and sets immediately to false, so the injected code does not run at load and waits for its hook. The bundle points at a cordis patch file, which is how the harness plugin mechanism receives it.

## The build is three syntax checks and the tests are node --test

The whole build script is:

```json
"build": "node --check index.js && node --check client.js && node --check app.js"
```

No bundler, no transpiler, no framework. Three files are parsed for syntax and that is the entire verification, and prepare runs the same build, so it also runs when the package is installed.

Tests are `node --test test/*.test.js`, using the test runner built into Node rather than a dependency. The devDependencies are correspondingly thin: playwright for browser tests, mprocs for running several processes, and turbo for task orchestration, with the script names showing what they drive, from dev:backend and dev:worker to dev:frame-frontend.

For a plugin of this size, that is proportionate. There is no build output to get out of sync with the source, and no compilation step between what you read and what runs.

## Install and development both go through corepack pnpm

Requirements are a DeepSeek Harness that supports the profile plugin mechanism, Node.js 22.19.0 or later, and the web profile. The install is two commands:

```powershell
corepack pnpm dsh plugin --profile web add dsh-synapse
corepack pnpm dsh web
```

Development is three more, using a frozen lockfile:

```powershell
corepack pnpm install --frozen-lockfile
corepack pnpm run build
corepack pnpm test
```

Everything routes through corepack rather than a global pnpm, which pins the package manager per project instead of using whatever version happens to be on the machine. The engines field requires Node 22.19 or later and nothing else, and the lockfile is a pnpm one.

## Four documents, two languages, and no tagged release

Documentation is split by language and by audience. A Chinese guide and an English guide both cover installation, configuration, usage, cleanup and limitations. A development and release document covers local verification, GitHub Actions, version tags and npm publication. An architecture and boundaries document covers session ownership, projection, data storage and model impact.

That last one is the document a reviewer should read first, because it is where the projection guarantee is written down rather than implied.

What is missing is any release history. The repository has no GitHub releases, the package version in the manifest is 0.4.1, and the last commit was on 2026-08-26. So the version number is in the manifest but there is no tag to install against, which means the published package and the default branch can differ.

## Conclusion

Use it if you lose the thread of a long conversation with branches and follow-ups and want to see the shape of it, since the plugin explicitly projects rather than replaces. Check that you run the web profile, because the bundled patch supports that profile only and it requires Node 22.19 or later. Read the boundary list before you adopt it: it does not touch prompts, model requests, tool schemas, provider routing or reusable cache prefixes, which is the reason it can be trusted to be a view. And note there is no tagged release, so you install whatever main holds.

## FAQ

### What does the dsh-synapse plugin do to my DSH sessions?

Nothing destructive. The DSH session log keeps the real session content and Synapse only projects committed events, with canvas layout stored separately under $DSH_HOME/synapse/ so deleting it does not delete sessions.

### How do I install dsh-synapse?

Run corepack pnpm dsh plugin --profile web add dsh-synapse, then corepack pnpm dsh web. You need DeepSeek Harness with profile plugin support, the web profile, and Node.js 22.19.0 or later.

### Does dsh-synapse modify prompts or model requests?

No. The stated boundaries say it does not modify prompts, model requests, tool schemas, provider routing or reusable KV-cache prefixes. It reuses the existing DSH web server rather than starting a second application.

### What does the dsh-synapse build actually do?

Three syntax checks, one per source file: node --check on index.js, client.js and app.js. There is no bundler or transpiler, and the tests run through the built-in node --test runner on test/*.test.js.

### Which DSH profiles does dsh-synapse support?

Only the web profile. The bundled patch is stated to support DSH's web profile, and the package manifest names web as the client platform while injecting the DSH client runtime.

## Sources

- [Issues](https://github.com/liangmianya/dsh-synapse/issues)
- [liangmianya/dsh-synapse on GitHub](https://github.com/liangmianya/dsh-synapse)
- [License: MIT](https://github.com/liangmianya/dsh-synapse/blob/main/LICENSE)
- [README](https://github.com/liangmianya/dsh-synapse/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/liangmianya-dsh-synapse