dsh-openwrite: a DeepSeek Harness plugin for writing and reviewing long novels

What the plugin actually is

dsh-openwrite is the DeepSeek Harness plugin version of OpenWrite. The division of labour is described plainly: DeepSeek Harness provides the agent and the interactive interface, OpenWrite Core provides the novel domain capabilities, and the characters, settings, outline, body text and reviews are kept in a local work directory.

The plugin is written in TypeScript and packaged under the name dsh-openwrite, currently at version 0.2.23, with the package marked as an ES module. It is licensed Apache-2.0 and the badges state a Node requirement of 22.19 or newer and a harness compatibility marker of 0.2.1-rc.2. It is also listed on the dsh plugin directory site.

The feature description in the repository description is worth quoting in translation rather than paraphrasing: a unified creation agent, ninety novel tools, a native workbench and a standard review DAG. That last term, a DAG for reviewing, is the piece that suggests this is more than a chat wrapper: a review pipeline with defined stages and dependencies rather than a single pass over a chapter.

The repository layout backs that up. There are packages for the bridge and the studio panel, a vendor directory holding a dsh-dog package, a conductor directory with Python test scripts, presets, release scripts, a dog-tools.mjs file and a cordis.patch.yml at the top level, which is the file the recovery instructions refer to when a host upgrade breaks a profile.

Installing the package and the pinned host versions

The installation command for a user who already has a matching harness version is short:

dsh plugin --profile web add -w dsh-openwrite@latest
dsh web

And for a user who wants the exact release artefact instead of the npm channel, the release tarball is installed by URL:

dsh plugin --profile web add -w https://github.com/LiPu-jpg/Openwrite/releases/download/v0.2.23/dsh-openwrite-0.2.23.tgz
dsh web

The npm package and the corresponding GitHub release use the same accepted artefact, and pinning an exact version such as [email protected] is the documented way to reproduce or roll back. The @latest tag selects the newest published npm version at the moment the install or upgrade command runs, and it does not replace a running service by itself.

The version compatibility is the sharpest constraint and it is stated precisely. The 0.2.23 standard package is compatible with exact harness versions 0.1.2-rc.1, 0.1.5-alpha.1, 0.2.0-rc.2 and 0.2.1-rc.2. All four have completed web workbench rendering and DoG data reading verification, while the Windows Electron desktop start and restore path has not been retested on real hardware. Downloadable versions, per platform acceptance results and SHA-256 checksums are attached to the GitHub release, and the default channel is the npm latest tag.

Two upgrade rules follow from this. Stop the harness before upgrading, and check the host compatibility notes for the target version. The 0.2.23 release notes also state that after upgrading you should stop and restart dsh and then refresh the browser page, because the bridge service has to load the new code.

What happens on first run

The first use downloads a fixed version of uv, Python 3.12 and locked dependencies, stored in a directory belonging to the current harness installation. You do not need Python preinstalled and you do not need to clone two branches. The target platforms are macOS arm64 and x64, Linux x64 and Windows x64, with per platform pass rates recorded in the release acceptance report. Model costs are separate.

The usage sequence is short. You run dsh web, open the browser address it prints, click OpenWrite in the sidebar, wait for the environment to be ready and choose your work directory. The entry point then creates an OpenWrite creation session automatically, and clicking the creation tab opens the workbench without needing to send a message first. The conversation model is configured in the harness, while the novel generation and review models are configured separately under the task and model settings.

That split between the conversation model and the writing models is a design detail with practical consequences. The chat model handles the interaction with the harness, and the models that actually generate prose and reviews are chosen in their own place, which means the same agent interaction can run against a cheap model for outlining and an expensive one for the final chapter.

The plugin also ships a set of npm scripts that show how the project tests itself: check:plugin chains the build, a doctor script, maintenance, profile and preset smoke tests, and the bridge and panel smoke tests together, while separate targets cover contracts, components, epochs and an end to end run.

The release notes are the documentation

This project's README is dominated by a changelog in prose form, and reading it tells you more about the state of the plugin than any feature list would. The releases between 0.2.11 and 0.2.23 each name specific issue numbers and describe concrete behaviour changes.

Version 0.2.15 lists fixes for a set of failures that are worth knowing about as a user. A leftover project.lock file on Windows permanently blocked writing and raised a WinError 87, and the Core now cleans up dead process lock residue and reports the error with context. A continuous write run would abort the whole queue when one chapter failed, with max_failures ineffective and over-length drafts discarded, and it now continues within the fault tolerance limit and keeps the over-long draft. An evaluation-in-progress detail endpoint returned 400 every time. And a reasoning model's review output budget was locked at 4096, which killed every review, so that cap is no longer fixed.

Version 0.2.14 fixed connection tests misreporting that the provider rejected the request when a system proxy set NO_PROXY to include the IPv6 loopback address, and added a health probe plus stderr logging on the bridge side to avoid a zombie state where the backend was alive but not serving. Version 0.2.13 fixed a refresh loop on the creation page, because annotation and version reads were being reported as write operations.

Version 0.2.17 and 0.2.18 added automatic model selection. Writing auto:cheapest in a model profile selects the lowest total price from the provider's price catalogue that still satisfies the context and output requirements, with the catalogue cached for an hour and price changes followed automatically, while auto:popular on OpenRouter lets the official openrouter/auto route by community usage. Version 0.2.18 then fixed a bug where zero price models participated in the comparison, so the selection fell through to a paid low price model instead.

Reading a draft against a fixed standard

The review pipeline is the part of the design that goes beyond a chat interface, and the changelog shows it being hardened rather than bolted on. Version 0.2.20 bundled Core 5.8.10 and fixed the draft recovery, task status, editing and review contracts, and added English usage support. Version 0.2.12 worked on the preset registration, navigation, workbench mounting and DoG interface, and made consecutive review passes refresh by content revision so the reading view does not flicker from polling.

Version 0.2.16 is the one that shows the review contract being treated as data. When a word count retry sequence was exhausted, the length_out_of_range and length_warning markers and the validation problems are now persisted with the draft artefact, so the export and review side can trace them. In other words, a failed length check survives as part of the draft rather than being lost.

Version 0.2.19 fixed two loading and tool problems. In some installations the OpenWrite creation preset disappeared from the list and the DoG tools were unavailable because the dsh-dog host package failed to resolve. Separately, the novel_* tools failed to preview object and array arguments when the model emitted them as a JSON string, and the data field was lost.

The repository also includes a DESIGN.md and a GOAL.md at the top level, which for a plugin of this size usually carry more of the intent than the README does, along with a docs directory holding the installation guide, the release acceptance document and the store integration notes.

Where dsh-openwrite is the wrong choice

The binding to exact host versions is the central cost. The plugin names four compatible harness versions, and it declares them in the root package and in every embedded sub-package. Version 0.2.23 specifically fixed the situation where installation and activation were rejected by the host version gate, which previously required a version exemption or a manual edit of compatibility.json.

The upgrade hazards are documented in detail, and they are the reason to read the release notes rather than clicking through. The notes warn that [email protected] does not include the fix, that the version exemption on the root package does not cover @dsh-novel/studio-panel or @dsh-external/dsh-dog, and that an old client failing to activate on a 0.2 host can trigger a desktop profile restore. If that has already happened, the recovery is to close the desktop app, back up the current profile, restore the patch from a cordis.patch.yml.bak file, and restore the original bundle list in package.json. The instruction is explicit that the install package and the work directory are usually still there, and that factory templates should not overwrite other plugin configurations.

The second limitation is scale and shape. This is a plugin for one author and one work directory on one machine, with a Python and uv runtime downloaded on first use, a bridge service and a studio panel as separate packages, and a large set of interdependencies between them. It is not a multi-user editing platform, it has no collaborative document model, and the whole write path runs through model API calls whose costs are separate.

The honest comparison for most people is a plain word processor plus a general chat assistant. OpenWrite adds structure, a review pipeline and a consistent work directory, and for a writer who plans long books that structure is the value. For anyone who mainly wants to draft and revise text, the installation complexity and the version pinning are real costs for a benefit that does not apply.

Editorial conclusion

dsh-openwrite fits an author who already works inside the DeepSeek Harness and wants a structured novel domain rather than a general chat model, and who is prepared to accept a plugin that binds itself to exact host version numbers. It does not fit a writer who wants a simple editor, a team that needs a stable plugin API across host releases, or anyone who expects the work to live anywhere other than a local directory on one machine. Before installing, read the release acceptance notes for the exact host version you have, keep the host stopped while you upgrade, and back up your work directory and cordis.patch.yml before any version change, since the documented recovery path depends on those backups.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. LiPu-jpg/Openwrite on GitHub
3. Project website
4. README
5. Releases