dsh-dot-plugin

English | 简体中文

Your personal assistant for DeepSeek Harness. You hand Dot an outcome, Dot runs the team, and Dot comes back with the result.

Quick start

Paste this into Plugins → install in DeepSeek Harness Desktop, then restart once:

https://github.com/1315577677/dsh-dot-plugin/releases/download/v1.0.0/dsh-dot-plugin-1.0.0.tgz

Then open DSH Dot in the sidebar and say what you want. More install options · What it does · How it works

Before and after

What is DSH Dot?

DeepSeek Harness gives you workspaces, sessions, and as many parallel conversations as you can start. Keeping track of all of them becomes a job in itself.

DSH Dot is the layer above that. It is not another coding session — it is the one place you talk to, and it owns the work:

• you say what you want;
• Dot acknowledges immediately, breaks the request into tasks, and delegates;
• background workers do the research, edits, and commands in real DeepSeek Harness sessions;
• Dot reviews what comes back, pushes back when it is wrong, and tells you when it is done.

You never switch windows to manage the work. You can watch it if you want — every worker is a real session — but you do not have to.

What Dot can do for you

How Dot works

Dot is a manager with a loop, not a model that happens to be called from a chat.

   you
    │  request
    ▼
 ┌──────────────┐          ┌──────────────────────────────────────────┐
 │  Dot chat    │─────────▶│               DOT (manager)              │
 │  (only UI)   │          │  1 intake    acknowledge in 1–2 lines    │
 └──────────────┘◀─────────│  2 plan      task + next action          │
    ▲  result              │  3 delegate  assign a worker             │
    │                      │  4 review    check evidence, push back   │
    │                      │  5 report    result, or one question     │
    │                      │  6 archive   complete with evidence      │
    │                      └───────┬──────────────────────┬───────────┘
    │                              │ assign               │ approve
    │                              ▼                      ▼
    │                    ┌──────────────────┐   ┌────────────────────┐
    │                    │  Worker agent    │   │  Executor agent    │
    │                    │  own Session     │   │  own Session       │
    │                    │  task workspace  │   │  approved tools    │
    │                    │  r/w/edit/bash   │   │  one approved act  │
    │                    └────────┬─────────┘   └─────────┬──────────┘
    │                             │ result / progress      │ result
    │                             ▼                        ▼
    │                    ┌──────────────────────────────────────┐
    └────────────────────│  events → task state → Dot review    │
                         └──────────────────────────────────────┘

The loop, concretely:

1. Intake. You send a message. Dot answers first — what it understood and what it will do — before any work starts.
2. Plan. The request becomes a task with a title, a request, a plan, and a next action.
3. Delegate. dot_assign_worker hands the task to the coordinator. If a slot is free the worker starts now; otherwise the task is queued and Dot tells you what it is behind.
4. Work. The worker runs in its own Harness session, scoped to the task workspace. It may edit files and run commands there. It reports progress and a final result.
5. Review. The worker returning wakes Dot. Dot reads the result, compares it with the request, and either accepts it, sends another instruction to the same worker, or asks you one question.
6. Report. A verified result becomes plain messages in the Dot chat. The task closes only with an artifact or a verified summary.

Alongside the loop:

• Interruptions are expected. New messages arrive while work is running. Dot classifies each one: append to the running task, dependent new task, or unrelated new task. Nothing is silently dropped and nothing waits that should not.
• Everything is inspectable. Task events, artifacts, worker sessions, and memory files are on disk. A Dot run is never a black box.
• Nothing consequential happens alone. Approval is user-only. Workers cannot approve their own work, and the executor only does what was approved.
• Dot never does the work itself. In manager mode Dot has no read, write, bash, or web tools. If it cannot delegate, it reports the blocker instead of quietly becoming the worker.

v1.0.0

The first stable release after the 0.x iterations. It adds Dot-owned scheduled tasks, the opt-in proactive workspace scanner, the plugin settings page, and the final chat receipt/quote behavior.

Install

Option A — Install from the plugin directory (easiest)

DeepSeek Harness Desktop installs a plugin from a spec. Use the package name once it is published to a registry, or a tarball URL / local folder:

dsh-dot-plugin

https://github.com/1315577677/dsh-dot-plugin/releases/download/v1.0.0/dsh-dot-plugin-1.0.0.tgz

Steps:

1. Open DeepSeek Harness Desktop.
2. Open 插件 / Plugins in the left sidebar.
3. Paste the spec above into the install field and confirm.
4. Wait until it reports installed, then restart the app once.

After restart, DSH Dot appears in the sidebar under 自动化任务. Click it: the Dot chat opens.

A build without a published tarball can be installed by absolute path (/absolute/path/to/package or link:/absolute/path/to/package).

Option B — From source (contributors)

git clone https://github.com/1315577677/dsh-dot-plugin.git
cd dsh-dot-plugin
pnpm install
pnpm build        # tsc for host and client
pnpm test         # node --test

Then install the cloned folder with Option A, using its absolute path.

Option C — Tarball release

Every GitHub release attaches dsh-dot-plugin-<version>.tgz, the same artifact npm pack produces. It contains the built lib/, cordis.patch.yml, the client bundle, and the locales, so it installs without a toolchain.

Requirements

• DeepSeek Harness Desktop 0.2.1-rc.2 or newer
• Node.js 22+ only for a source build
• A workspace to point Dot at; the current workspace is the default

First run

1. Click DSH Dot in the sidebar.
2. Say something concrete: “Check the failing tests in this workspace and fix them.”
3. Dot answers in a line or two, creates a task, and assigns a worker.
4. A Dot · <task> session appears in the workspace list. Open it if you want to watch.
5. Dot reports back in the chat when the work is verified.

Configuration

The bundle patch creates one plugin row. Useful fields in cordis.patch.yml (or your profile override):

- insert:
    - id: dsh-dot-plugin
      name: 'dsh-dot-plugin'
      config:
        enabled: true
        orchestrator: true          # manager mode; false = legacy research mode
        agentPreset: standard
        maxWorkers: 4               # 2–8 worker slots
        workerTimeoutMs: 600000
        executionTools:             # tools the approved executor may use
          - write
          - edit
        systemProactive:            # off by default; read-only background scan
          enabled: false
          intervalMinutes: 240
          activeWindowHours: 48
          minConfidence: 0.8
          maxMessagesPerDay: 1
          quietHours: '22:00-08:00'

The same settings are editable from the plugin's page in Plugins → DSH Dot. The page writes the profile patch through the Host configEditor service; it is not a separate configuration file.

State lives next to the plugin data directory: state.json (tasks, chat, proposals, triggers), system-proactive.json (separate scanner state), memory/ (facts, profile, journals), worker-limit.json.

Safety model

• The manager cannot read files, run commands, or touch the network. It can only manage tasks and talk to you.
• A worker is confined to its task's workspace, for reads, writes, and commands.
• External actions (send, publish, pay, delete, invite, account changes) and cross-workspace work become a proposal.
• Worker approval requests are reviewed by Dot. Safe, task-consistent actions may be allowed once; unsafe actions are rejected; uncertain requests are shown to you in the Dot chat.
• Approving a Dot proposal starts a separate executor session with only the approved tools. The manager never executes.
• dot_remember refuses secrets and requires a real, verifiable source.

Development

pnpm install
pnpm typecheck
pnpm build
pnpm test

src/host/               Host half: runtime, state, tasks, HTTP routes
src/host/orchestrator/  manager tools, coordinator, worker manager, capacity
src/host/memory/        facts, digests, recall index
src/host/proactive/     opt-in read-only proactive scanner
src/client.ts           Client half: the Dot chat page
test/                   node --test suites
specs/                  design notes

Pull requests: keep the delegation boundary and the manager-reviewed/user-approved approval model intact. A change that broadens execution authority needs a threat-model note and a test. See CONTRIBUTING.md for the full ground rules, the review checks, and what the project will not accept.

License

MIT — see LICENSE.

DSH Dot is inspired by the capability model of personal-assistant agents, but it is an independent open-source project. It is not affiliated with, endorsed by, or connected to OpenAI.