SQLite owns the tasks and only an authenticated human can write done

Only an authenticated human operation can accept work as done

The permission model is stated in two sentences and enforced by the shape of the tool surface rather than by a runtime check. SQLite is the sole task authority, while Harness sessions, goals, workspaces, tools, permissions and the web client remain the owners of execution and conversation. Agents can submit verified work to a review status, but only an authenticated human operation in the interface or the command line can accept it as done. The agent tools are described in the same list as having no accept and no generic status mutation, which means there is no tool that can write the terminal state regardless of what the model decides to do. The seven statuses are a five-step chain from backlog through todo and in progress to in review and done, plus blocked and canceled. So the boundary is structural: a model cannot accept its own work because the function does not exist for it.

The peer range is a wildcard and compatibility rests on five tested prereleases

The host version policy is stated as one sentence with two halves. DSH runtime peers use a wildcard, which the file glosses as no version gate, and installation and loading have been tested against five specific builds: one alpha from the 0.1.6 line, two release candidates from 0.1.7 and two from 0.2.0. The requirements table repeats the openness, saying the Harness is needed as a checkout or an installation with the web profile and no DSH version constraint. So compatibility is asserted through a list of prereleases in prose rather than through a range in the manifest, and a user on a stable build outside that list has no signal. The smoke test's failure note widens the peer set to include react alongside the platform packages, which is a browser-facing dependency in a plugin that also runs headless.

Install success is three conditions on disk, not a message

The file does not accept a clean exit as success. Three conditions must all hold. The profile's package.json must list the package in dependencies. The same file's profile bundle list must place it after the base package, with the order called out as significant. And the installed copy inside node_modules must exist and contain both the compiled directory and a patch file named cordis.patch.yml. There is a specific diagnostic for the second failure: the command warns that a package declares no bundle, which means the manifest is missing a dsh block pointing at that patch file, and the file names the exact fragment to add. The instruction that follows is the right one: rebuild and reinstall rather than editing the installed copy by hand, because an edit inside node_modules is destroyed by the next install.

The workspace-root flag is mandatory because the profile directory is itself a workspace

Adding the plugin from a local tarball goes through one command, and one flag in it is not optional. The profile directory is a pnpm workspace root whose packages list is just the current directory, so the workspace-root flag has to be passed or pnpm refuses with its adding-to-root error. The same step is documented as destructive by design: the command may rewrite the profile's package.json, its lockfile and its node_modules, and the file says that is expected. That is a fair trade for a plugin installed into a real application rather than a vendored copy, but it means the installation is not reversible by uninstalling the plugin alone. The permissions table anticipates the other requirement by asking for write access to the home directory and the ability to restart the Harness process, and a restart script sits at the repository root.

The port is documented as 3080 and then told not to be trusted

The constants table gives a default web port of 3080 and puts a parenthetical next to it saying to detect it and not assume. Step 1 then does the detecting:

PORT=3080
lsof -iTCP:"$PORT" -sTCP:LISTEN
# then, with the listener PID:
lsof -p <PID> -a -d cwd

Finding the port gives you the working directory too, which is the other thing the step needs. If nothing is listening there, the instruction is to search other common ports or ask the operator for the URL they use. The same logic governs how the command line itself is invoked: if the working directory looks like a source checkout, detected by a workspace file and a script entry in the manifest, every later command runs through the package runner from that root, and otherwise a globally available binary is used directly. Everything after this point is written against a placeholder for whichever form was chosen, which is why the port is stated twice and trusted once.

Both the compiled output and a generated directory are committed beside the source

The top-level listing contains src/, lib/ and generated/, plus a build configuration file and four separate TypeScript configurations named for the base, the build, the host and the runtime. The committed lib/ is not an accident: the file states that the Git, npm and release routes all carry prebuilt host and client artifacts, that installing from Git includes that directory, and that consumer installation runs no build at all. Developers working from source run a frozen install, a build and a release pack instead. So the repository ships the result of its own compiler, which is what makes the install-from-Git route possible without a TypeScript toolchain, and it is also what allows the tag and the tree to disagree about what is compiled. The generated directory has no explanation anywhere in the file.

Thirteen export paths, two of them hiding a host and remote pair

The manifest publishes thirteen subpaths from one package, each with its own types and default entries. Beyond the root there are paths for domain, sqlite, cli, tool, workflow, automation, execution and client, plus two more that are worth reading closely. One public path named for the type layer resolves to a file whose name ends in host, and the public path named for remote resolves to a file named for a remote client. So a consumer writes two short import names and the mapping to the host and remote build is made for them, and the split between a host-side module and its remote counterpart is visible only inside the lib tree. The files array visibly covers compiled output and re-lists two of those host paths after globs that already reach them, and the patch file the install check requires is exposed as its own export.

The README is addressed to an agent before it is addressed to a person

The second paragraph says the document is written so that a human or another coding agent can install the plugin into a live profile, verify it and start using it without guessing, and the install section opens by telling an installing agent to jump straight to the procedure and follow every step in order. The prose reinforces that in small ways. Use these constants, read live values from disk, do not invent a different package name. Read the declared version from the manifest rather than copying a number out of the document. After packing, use the tarball that was actually written. The result is an installation guide written for a reader that will not notice a stale number, which is a sensible choice for a plugin whose whole point is to be installed by something other than a person.

Editorial conclusion

DSH-taskboard is worth installing if you run DeepSeek Harness with multiple agent sessions against one project and want a durable task list that outlives any single conversation, since SQLite is the declared sole authority and the keys are readable ones like DSH-42 rather than opaque identifiers. It is the wrong tool if you want agents to close their own work, because that capability is absent from the tool surface rather than merely discouraged, and it is the wrong tool if your Harness runs somewhere you cannot restart or write to, because installation mutates the profile and a restart is required. Before you start, follow the three filesystem conditions rather than trusting the CLI's exit status, check your Harness port instead of assuming the documented one, and read the peer policy, since the runtime range is a wildcard backed by testing against five prerelease builds rather than by a constraint.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shengsheng90/DSH-taskboard on GitHub