Introduction

When using DeepSeek Harness (DSH for short) for agent development, you will eventually encounter a class of tasks: the goal takes days or longer, sessions break, processes crash, and progress is lost; even if the agent is running continuously, if it reports “done” itself, you cannot confirm that it is actually done in the environment.

A single session cannot solve these two problems. The idea behind dsh-mission is to split long-term goals into a task dependency DAG and hand them over to a persistent runtime to push forward: cross-session execution, independent verification for each task, failure replanning, and crash recovery. The model is only responsible for proposing and planning; state changes are decided and committed by the runtime.

Below is an introduction to the plugin’s positioning, core mechanisms, installation, and usage.

What is it

dsh-mission is a plugin maintained by qiaoy01 for DSH, available as the npm package @qiaoy01/mission, version 0.2.0, under the MIT license. It is a pure TypeScript Cordis plugin that integrates into the DSH composition as a plugin, providing exactly that missing layer: a long-cycle autonomous mission runtime.

In design, it adheres to a core principle: agent proposes, environment decides, runtime commits. At the execution level, this translates to report ≠ verify:

  1. An agent’s plan, execution, and claim are not authoritative;
  2. A report is merely a declaration by the agent to the environment; the declaration itself does not generate DONE;
  3. Verify independently aligns the declaration with the environment’s feedback. Only state changes that pass deterministic checks and are atomically committed via a single session event count.

In short: a worker cannot self-authenticate.

Core Features

Task Dependency DAG & State Machine

First, a breakdown: mission_plan submits a task dependency DAG, and the runtime derives each task’s state from it—downstream tasks enter READY only after upstream tasks are completed; otherwise, they are BLOCKED.

The state machine has two layers. The mission has five states: CREATED / RUNNING / COMPLETED / FAILED / CANCELLED. Tasks have four basic states: PENDING / CLAIMED / DONE / FAILED, plus the derived READY / BLOCKED.

Event Sourcing Persistence

All state changes are written as mission/* session events. An event represents a single atomic commit; no separate database is required. Concurrency is guarded by versioning using revision CAS (mirroring the dsh-goal GoalRef pattern); when submitting a plan, the revision must equal the current value + 1.

Autonomous Host mission-driver

The mission-driver listens to mission/changed events and automatically executes the complete loop:

claim → subagent execute → report → verify → commit

This means that after a plan is submitted, the runtime takes over: the mission-driver claims tasks, dispatches the real subagents, verifies independently, until the mission reaches COMPLETED. The README explicitly states a rule: models should not execute tasks themselves.

Lease Recycling & Crash Recovery

Claiming a task comes with a lease. Claims that expire without a report are lazily reclaimed, allowing tasks to be retried. In-flight task guards ensure that the same task is not dispatched twice. After a process crash, execution is recovered via these two mechanisms.

Failure Replanning

Stuck missions generate a new revision for replanning. DONE tasks with unchanged specifications are preserved; the system does not wipe everything and start over. By default, auto-replanning is not enabled; this is intentional conservative design (see the next section).

Optional Model Strategies

The default configuration is conservative: deterministic logic for task selection, no auto-replanning, and zero model cost. To allow the model to participate in decision-making, you need to explicitly enable it in the profile config:

  • llmDecider: The model selects the next task to execute;
  • llmReplanner: The model replans when the mission is stuck;
  • userApprovalGate: Approval gate.

Triggers & Supporting Components

  • mission-trigger: Soft guidance prompts plus the /mission slash command, routing trigger statements in the session to mission_create / mission_plan;
  • mission-invariant: A tolerant companion component, registers audit when the invariant service exists, otherwise it is a no-op;
  • UI Data Plane: The mission session projection unit. Projection is complete in Stage E, while the browser UI is still in development.

Installation & Enablement

The npm package is pre-built (in lib/), so consumers only need one command to install the plugin into a profile:

dsh plugin --profile <name> add @qiaoy01/mission

For example, installing into a profile named web:

dsh plugin --profile web add @qiaoy01/mission

If you want to modify or review the code, build from source:

git clone https://github.com/qiaoy01/dsh-mission.git
cd dsh-mission
npm install
npm run build
dsh plugin --profile <name> add file:.

file:. points to the repository root directory you just cd into. After modifying the source code, run npm run build again and re-run the add command.

Regarding dependencies, the plugin declares dependencies on @deepseek-ai/cordis, @deepseek-ai/dsh-agent, @deepseek-ai/dsh-invariants, @deepseek-ai/dsh-llm, @deepseek-ai/dsh-session, @deepseek-ai/dsh-session-projection, @deepseek-ai/dsh-subagent, @deepseek-ai/dsh-tools, @deepseek-ai/dsh-commands, @deepseek-ai/dsh-system-prompt, and zod via peerDependencies, provided by the host composition running DSH.

Typical Usage

After the installation steps above, you can use it in a session. The agent operates the mission via four model tools:

  • mission_create: Create a mission;
  • mission_plan: Submit the task DAG, revision must equal current value + 1;
  • mission_status: Read the current state;
  • mission_cancel: Cancel the mission.

The README provides a 30-second example:

# 1. Install the plugin into a dsh profile
dsh plugin --profile web add @qiaoy01/mission

# 2. In the session, say to the agent:
#    "mission: build a small web game. Use mission_create, then mission_plan,
#     then stop — the runtime will execute the tasks."

The flow is: first use mission_create to create the goal, then use mission_plan to submit the task DAG, and then the model stops. From then on, the runtime takes over: the mission-driver claims tasks, dispatches the real subagents, and verifies them one by one independently until the mission becomes COMPLETED. The model is only responsible for creation and planning, not for executing tasks.

According to the README’s records, this flow has been verified in a real composition: a 7-task DAG was driven to COMPLETED end-to-end by real subagents, with each task verified independently, achieving zero failures and zero duplicate dispatch.

By default, this flow costs zero model usage. To enable model strategies, add the following to your profile config:

- id: mission-driver
  config:
    decider: llm     # model selects next task
    replan: true     # model replans if mission is stuck

Suitable Scenarios & Notes

Suitable scenarios:

  • Goals spanning multiple sessions, requiring checkpoint resume;
  • Not trusting the agent’s self-reporting, requiring independent verification of each task on the environment side;
  • Execution environment that crashes or restarts, requiring lease recycling and recovery mechanisms.

Three notes:

  1. The default configuration is conservative (deterministic task selection, no auto-replanning); model strategies must be explicitly enabled via profile config;
  2. The browser UI is still in development; the available data plane currently is the mission session projection unit;
  3. The plugin runs with the permissions of the current dsh process. It is recommended to review the source code and license (MIT) before installing to ensure trustworthiness.

Summary

To recap: dsh-mission splits long-term goals into task dependency DAGs and has the mission-driver autonomously drive the claim → execute → report → verify → commit loop. Agent self-reporting doesn’t count; verification is completed on the environment side. Failures can be replanned, crashes can be recovered, and the default configuration has zero model cost. For DSH users who need to push long-term goals forward across sessions, this is a runtime you can try out with a single command.

(The directory page is an independent community site and has no official affiliation with DeepSeek / Huansuan.)