dsh-worktable: a Cordis plugin that docks every harness project

The plugin is additive and the install writes to ~/.dsh

dsh-worktable is a Cordis plugin, described as host routes plus a web client and explicitly pure additive, meaning no official plugin is replaced. One package ships both halves: a host side that exposes `/api/worktable/*` routes for health, file system, git, file read and write, site serving, mkdir, workspaces and a native skin template, plus a WebSocket at `/api/worktable/term` that backs the terminal pane with PowerShell on Windows.

The recommended install needs no Git at all:

dsh plugin --profile web add "https://github.com/Aisland-SJL/dsh-worktable/releases/latest/download/dsh-worktable.tgz"

The `add` command registers `dsh-worktable` in the profile bundle list, writes to `~/.dsh` and may ask for authorization. If the `dsh` command is not on your path, the fallback is `npx @deepseek-ai/dsh`. After installing you restart the DSH web process, refresh the GUI, click the pinned control-room card, bind one conversation by joining an existing one or creating a new one, and then create projects from the sidebar by choosing a layout preset and a project folder.

A local link: install needs an absolute path with no spaces

The second install path is for working on the source, and it has two restrictions stated up front. `link:` accepts a local absolute path only, and the path must not contain spaces:

git clone https://github.com/Aisland-SJL/dsh-worktable.git
dsh plugin --profile web add "link:<absolute path of the cloned dsh-worktable directory>/01_content"
# e.g. cloned into D:\tools → dsh plugin --profile web add "link:D:/tools/dsh-worktable/01_content"

Note the path ends at `01_content`, not at the repository root. That is the same directory the build has to run inside, so a link install and a development build point at one place, which is convenient right up until you move the checkout to a path with a space in it and the resolver quietly stops agreeing with your shell.

The repository layout is numbered rather than named: `00_index/`, `01_content/`, `02_process/` and `04_test/`, with no `03_` directory at all.

Building from the repository root writes lib/ to the wrong place

Development is a directory change and three commands:

cd 01_content
npm install
npm run build     # lib/index.js + lib/client.js
node --check lib/index.js

The README states the constraint bluntly: the build must run inside `01_content`. Building from the repository root writes `lib/` somewhere the host never reads, and because the host keeps loading the old bundle the symptom is a plugin that installed fine and then shows yesterday's behaviour.

Two bundling decisions follow from the same file. The client keeps the `window.__ModuleLoader__.load` handshake, so the host's loader stays in charge of when the bundle runs, and `react` plus the `@deepseek-ai/*` packages stay external, which is why the client can be built without a React dependency and still render inside a host that supplies its own.

The control room mirrors host snapshots and never calls a model

The control room is the built-in default project, a pinned first entry that cannot be deleted, and it needs one management conversation bound on first open. What it shows is a configurable card grid mirroring the visible projects in three states, working, needs you and done, each with the available runtime and a cleaned message preview.

The data path is the interesting part. Status comes from a mirror of the host session runtime snapshots, subscription driven, covering running, pending and completed sessions plus jobs and subagent catalogs. The README says status monitoring does not call a model, and the control room is described as an event-driven host snapshot mirror with no model involvement.

So the grid is a view of what the host already knows, not a second opinion about it. Its cost is a subscription and its failure mode is a stale card, which is a different trade from anything that asks a model to summarise your sessions.

A window task is a widget-result.json the agent writes for you

The custom window pane is the one built-in pane that produces something rather than showing something. You send a requirement to a new or existing conversation, the agent builds it, and the result mounts itself into the window, which is then locked.

The mechanism is a file. On completion the agent writes `widget-result.json` into the project folder, and the client picks it up and mounts the artifact into the addressed window. The lock is what makes it a delivered artifact rather than a live surface.

The other built-in panes are more conventional: a file explorer, a terminal, a browser and an animation site. Around them sit declarative layout presets, described as left column, top row and main grid plus a right chat pane, with draggable dividers, per-pane tabs and per-layout width persistence. Collapsing the sidebar turns every project into an icon-only square tile.

Compatibility is declared for three host versions and tested on one

Version v0.3.4 declares compatibility with DSH Web 0.1.1-rc.2, 0.1.2-rc.1 and 0.2.0-rc.2, and then says exactly how far the testing went: the listed core Windows Web flows were tested on 0.2.0-rc.2 in this round, while the two older versions rely on prior page validation plus targeted code regressions rather than a repeated full GUI suite.

Official Desktop support has not been verified. That is the sentence to read before upgrading a host, and it comes with two instructions: back up important data and check your other plugins first.

The release titles carry the same honesty. v0.3.3 was a 0.1.2-rc.1 compatibility release with a data path fix, and v0.3.4 is the web-side compatibility update for DSH 0.2. Both land within a month of v0.3.2 on 2026-09-05, and the last push is 2026-10-02, the same day as the newest tag.

The update path is written down for the case where a host upgrade breaks the worktable. Open the worktable settings, click Check now, and when the amber update badge appears next to the title, click it and choose Copy AI prompt to hand the upgrade to an AI assistant. Re-running the install command also works, because it always installs the latest, after which you restart dsh web and refresh the GUI.

Release packaging runs 53 regressions and then checks the upload

The regression suite lives in `04_test/` and is layered by what it protects. `functional-diag.cjs` is a 20 step run with a strict gate, joined by targeted probes for the control room, the bind panel, the collapsed rail and model inheritance, a path matrix in `pathutil-matrix.cjs`, and update-check scenarios in `probe-update-scenarios.cjs`.

The release pipeline adds two more. `anchor-dom.test.mjs` runs a split-anchor DOM regression over 8 scenarios covering both host conversation-root shapes, and `server-home.test.mjs` runs data-home resolution in 3 groups: no-cycle fallback, path expansion and an official-branch fixture.

Packaging is a single entry point, `npm run pack`, and it also runs 53 input and session regressions plus installation and client-factory gates. After the upload there is one more step: `npm run verify:remote -- --expect-sha <final SHA> v0.3.4`, and the `latest` alias has to be checked separately, which is what catches a stale redirect rather than a bad artifact.

Editorial conclusion

dsh-worktable fits a person running several self-hosted agent projects at once who wants one place to see what is working, what is waiting on them and what is finished, and who already accepts a browser-scoped workspace. It does not fit a team that needs server-side state or an audited desktop path, because both live in the browser and Desktop support is explicitly unverified. Before installing, back up and check your other plugins, build from 01_content rather than the repository root, and decide whether the release-compatibility statement covers the host version you actually run.

Frequently asked questions

Official sources

1. Aisland-SJL/dsh-worktable on GitHub
2. Issues
3. License: MIT
4. README
5. Releases