dsh-atlas

The constellation view of a project's memory, as a DeepSeek Harness conversation tab.

Your agent writes to a canon store while it works. This adds a third tab beside Chat and Trajectory that draws what it has written: documents as lit spheres, references as gossamer links, semantic clusters as colored regions of the map. Click a star and the camera flies to it, its neighborhood lights while the rest of the sky dims, and the article opens in a reader.

It is the same renderer canon-atlas ships, so the tab and the command line show you the same map.

Install

dsh plugin --profile web add dsh-atlas

Restart dsh. Nothing is disabled: the tab joins the ring after Chat and Trajectory and is chosen by the reader.

By default it reads .canon under each session's workspace, which is where dsh-canon writes. A session whose workspace has no store gets a sentence saying so rather than an error.

Configuration

- id: atlas
  name: 'dsh-atlas'
  config:
    # Store location. Relative resolves under each session's own workspace, so
    # every project draws its own. Absolute pins one atlas across every session.
    root: .canon

How it works

Two halves. The host half runs in the harness process, where the store is. The browser half is a client plugin: one prebuilt bundle the harness serves at /plugins/dsh-atlas/client.js, which registers into the conversation.view slot.

The tab is a frame, not a renderer. canon-atlas ships a stylesheet that styles :root, *, and html, body, and an app that captures its DOM when it evaluates. Mounting that into the harness's own document would put those global rules on the harness. So the tab frames a page instead, and the page it frames is the one canon-atlas build writes, served rather than written to a file. There is one renderer, and the view cannot drift from the tool.

Read only. corpusApi reports its mode as live, which turns on the renderer's editing door and points its writes at canon-atlas's own server rather than at this route. This route does not answer that door, so the mode is restated as what is actually served. Edit through canon or through canon-atlas serve.

The workspace is not a prop. The view reads it off the session list, so a tab opened on another session draws that session's store rather than the first one seen.

What it can read. cwd arrives from the browser, so it is resolved and checked: an absolute path naming a directory that exists, with a store under it. What that reaches is what canon-atlas standalone reaches, a directory of markdown the harness process can already read, and canon-atlas confines every path it follows to the store's real root. The route inherits the web server's own browser-trust fence, which is loopback unless the deployment widened it. If you serve the harness on a LAN with --trusted-host, those viewers can read the store too.

Cost. canon-atlas is imported on the first request rather than at boot, so a profile that never opens the tab pays nothing for having the plugin installed. The page is generated per view and carries the whole corpus inline, which is a few megabytes over a large store. Opening the tab is a scan; leaving it open is free.

Development

The client half is written by hand rather than built. A client plugin ships as one bundle in the module loader's factory format, and the preset that emits it lives in the harness repository rather than in a published package. The wrapper is six lines, so it is written out. require there is synchronous and resolves only against the shell's seeded modules, which is why the browser half imports nothing but react.

npm run check   # typecheck the host half
npm test        # the gate suite
npm run build   # emit lib/

The suite drives the route handler directly and pins which state each request lands in, including the two that are easy to lose silently: that both halves name the same route, and that the served page is a reader.

License

MIT