dsh-goal-auto

Per-session auto-resume toggle for long-running goal sessions in DeepSeek Harness (DSH).

What it does

• Adds a 🔁 toggle to the session header action bar.
• Marked sessions are resumed automatically after the harness restarts: the agent is reloaded, its agent preset is mounted, the goal is re-armed, and the goal-round-driver keeps driving rounds without any manual click.

Why resume is not enough (the three layers)

A plain agents.resume() after a restart leaves the session dead. Three things must happen before a goal session runs again:

Adaptive preset

The preset is read from the session header (header.agentPreset) and mounted per session, falling back to the configured default when the header has none.

Install

dsh plugin --profile web add file://<this repo path>

Or, as used here: keep the plugin in <DSH_HOME>/plugins/dsh-goal-auto and add a file:/link: dependency in the profile's package.json + a junction under profiles/<name>/node_modules/@huanlin/dsh-goal-auto.

HTTP surface

• GET /__goal-auto/state -> enabled map
• POST /__goal-auto/toggle -> flip a session flag (+ start now if enabled)
• POST /__goal-auto/resume-now -> force resume of one session (diagnostics)

State lives in <DSH_HOME>/goal-auto-state.json (per-instance; safe to edit by hand while the harness is stopped). Logs go to <DSH_HOME>/goal-auto.log.

Layout

• src/index.js — cordis bundle (host): state, HTTP, boot auto-resume
• src/client.js — client bundle: header 🔁 toggle
• cordis.patch.yml — loader insert for the profile

Watchdog requirement (IMPORTANT)

The plugin resumes sessions when the harness starts. It does not keep the harness process alive. If dsh web crashes, hangs (TCP alive but HTTP dead), or is killed, nothing inside the process can restart it — you must run a process watchdog outside the harness.

Without a watchdog:

• the service dies and nobody brings it back;
• after a machine reboot nothing auto-starts;
• goal sessions only resume on the next manual start.

A reference watchdog system is included in this repository under watchdog/. It is the same system used by the author:

watchdog/
  watchdog-instance.ps1   per-instance resident watchdog
                          health = TCP listening AND HTTP 200
                          sliding window catches hard hangs AND intermittent
                          "slow death" (5+ HTTP failures in last 10 probes)
                          boot grace 120s so fresh starts are never killed
  start-instance.ps1      auto-init + start one instance (seeds settings,
                          credentials, agent presets, plugin environment)
  control.ps1             unified control: start|stop|restart|status [instance]
  instances.txt           instance registry: name|home_dir|port

Design notes (all learned the hard way):

• Watchdogs are per instance (one process per instances.txt row), all sharing one script. A single mutex per instance prevents duplicates.
• Auto-start at logon via the Windows Startup folder (a small .vbs per instance calling watchdog-instance.ps1 -Name <instance>).
• instances.txt and every .ps1 must stay pure ASCII — Windows PowerShell 5.1 mis-parses UTF-8 without BOM, and the harness rejects JSON files that carry a BOM.
• Health probes use .NET HttpWebRequest, not curl.exe (curl in 5.1 intermittently returns 000 against a healthy instance).
• Add a crash circuit breaker: if an instance dies N times within a short window, stop relaunching and alert — otherwise a plugin bug turns the watchdog into an infinite restart loop.

Configure instances.txt for your own homes/ports before use. The watchdog is generic; the paths under watchdog/ reference the author's layout only as an example.