dsh-updater

A DeepSeek Harness web plugin that checks the local DSH version against the official latest and updates the installation checkout — while never touching user configuration (~/.dsh) and never discarding your own commits.

• Settings page ("Updates") — source / running / latest version, outdated badge, branch + working-tree guards, check button, update buttons, live operation log, and an update confirmation dialog with a dry-run preview (from→to versions plus the exact commits that would be added and the local commits that would be kept).
• Sidebar footer badge — a compact version pill (green = verified up to date, amber = update available or unverified, red = check error); click to refresh.
• Auto-check + toast — when the cached version check is stale (30 min) the page auto re-checks, so version data can never be older than about 30 minutes while the page is open; a newly-detected update raises a transient toast.
• One-click commit & push to your fork — when the working tree has uncommitted changes the button enables: it stages everything, commits on the current branch (local: working tree sync (dsh-updater …)), and pushes to origin (your fork). A commit that fails to push is reported as partial — your work is committed locally, only the network hop failed.
• Honest diagnostics — the official latest comes from the git upstream tag (the npm registry is a fallback, since it may lag behind the git repo); a failed upstream fetch marks the verdict unverified — never shows a false green "up to date" on stale data. A failed npm lookup is only a hard error when the upstream ref is absent.
• Host HTTP surface GET /__dsh-update/status|info,
  POST /__dsh-update/check|preview|update|commit-push.

How it works

DSH is a git checkout. "Update" means: fetch the official upstream and rebase your local-patches branch onto it. Your own commits (e.g. the local core patches used by dsh-archived-sessions) are replayed on top — a conflict stops the rebase and is reported, never auto-resolved. The "official latest" version is the tag on the tip of upstream/<branch> — the update itself rebases onto that ref, so it is the authoritative source. The npm registry is a fallback for installs without a configured upstream remote. Your user configuration lives in ~/.dsh, which is outside the checkout and is never written by this plugin.

Install

1. Clone/build this package (npm install && npm run build).

2. Add it to your web profile (~/.dsh/profiles/web):

   package.json → dependencies:

   "dsh-updater": "link:D:/PROJECT/dsh-updater"

   cordis.patch.yml:

   - insert:
      - id: dsh-updater
        name: 'dsh-updater'
        config:
          installPath: 'D:/Program Files (x86)/deepseek-harness'

3. Restart dsh web (or rely on the profile patch layer hot-apply). Open
   Settings → Updates.

Configuration

Update semantics

• Only the checkout changes. ~/.dsh (settings, credentials, profiles, sessions, attachments) is never touched.
• Dirty working tree → the update refuses. Commit or stash first. Untracked files and local commits are never silently discarded.
• Wrong branch → the update refuses. It only runs on patchesBranch (local-patches), the branch that carries your commits.
• Conflict → the rebase stops and reports the conflicted files; you resolve (or git rebase --abort). Nothing is auto-resolved.
• Restart required after updating — the running process still executes the old code. The plugin reports source-vs-running mismatch and prompts you to restart dsh web; it never restarts for you.
• Version verdict is git-first. The "official latest" and the outdated/up-to-date badge are derived from the upstream remote tip (upstream/<branch>). The npm registry is only a fallback; a stale npm latest dist-tag will never hide a real upstream update.

Development

npm install
npm run build     # tsc + tsdown (node half + client bundle)
npm run typecheck
npm run watch     # tsdown --watch

See dsh-archived-sessions for the sibling plugin this one's structure mirrors.