v0.1.6

The Desktop installer is fixed

Three defects in scripts/install-desktop.ps1, all found by driving it rather than reading it:

1. It deleted its own download. The script fetches the release asset over HTTPS and installs from that file, which makes pnpm record file:<path> as the profile's dependency — and then it removed the file on the way out. The profile was left pointing at nothing: dsh plugin list still looked fine (node_modules was already populated) but the next pnpm install, which Desktop's own profile maintenance runs, died with ENOENT. The download now lands in <harness home>\.plugin-cache\team-flowise.tgz under a stable name and is deliberately kept.
2. One download attempt was not enough on a network that reaches github.com intermittently — measured here, a plain GET alternates between succeeding and timing out inside the same minute. Now four attempts with growing backoff.
3. The running-app guard was too broad. It refused whenever DSH Desktop was running, even when -DshHome pointed at a home that instance does not own. It now compares the two and only refuses a real collision.

validation/desktop-install.mjs pins all three by consequence: it drives the real script, asserts the recorded dependency still exists and is not under %TMP%, then runs a real pnpm install and requires that it does not fail. It serves the tarball over loopback so a GitHub outage cannot make it red.

If the market's install button failed for you

That button runs github:Drkoh-wz/team-craft#path:/packages/team-flowise, and pnpm resolves the github: shorthand to git+ssh://git@github.com/.... It therefore needs git to be reachable from the Desktop process and GitHub's ssh host key to be known; without them the failure surfaces inside pnpm's resolveGit as Host key verification failed or a bare exit 128.

Two ways out, easiest first:

Run the script (never invokes git):

.\scripts\install-desktop.ps1

Or paste the explicit https command (needs git, but no ssh key):

$exe = (Get-Process 'DSH Desktop' | Select-Object -First 1).Path   # resolve it before quitting
$Desktop = Split-Path $exe
$env:DSH_HOME = "$env:APPDATA\dsh-desktop\harness"
$env:ELECTRON_RUN_AS_NODE = '1'
& "$Desktop\DSH Desktop.exe" "$Desktop\resources\harness-node-entry.mjs" `
  "$Desktop\resources\app.asar\node_modules\@deepseek-ai\dsh\lib\bin.js" `
  plugin --profile web add "git+https://github.com/Drkoh-wz/team-craft.git#path:packages/team-flowise"

Also in this release

• Delete controls for roles, board cards, tasks, workflows and runs, with in-place confirmation; a task a worker is still writing and a run whose scheduler is still advancing are refused, and the button renders disabled with the reason.
• The progress page owns its scroll container, so the right pane's lower half (role detail, reviews) is reachable.
• A worker that dies for an infrastructure reason is re-dispatched automatically (bounded, with backoff) — a work failure is deliberately not retried. A run that ended short can be continued, reusing its completed nodes.

Verified

Release gate	72/0 — installs the package every published way into throwaway profiles, boots one, drives its whole HTTP surface. Run against DSH Desktop 0.2.0-rc.2.
Packer	31/0
Offline battery	1223/0 across 12 suites (including the new Desktop installer suite)
Mutation harnesses	9/9 — each breaks one behaviour and asserts the named check goes red

v0.1.5

Delete what you no longer need

Every list in the Settings board now has a delete control — roles, board cards, tasks, workflows, runs. Each asks once, in place, because these records are not undoable and the same row also carries the open/edit action.

Two removals are refused on purpose, and the button renders disabled with the reason instead of failing after the click: a task a worker is still writing, and a run whose scheduler is still advancing. Deleting either would be undone by the next state write, so reporting success would be a lie. A role's row also shows how many workflow nodes reference it.

The progress pane scrolls to the bottom

The progress page is mounted in two very different containers: the full-page slot, and the fixed-height right sidebar pane. Without a scroll container of its own, the pane's lower half — role detail and the review verdicts — was simply unreachable. The page now owns its scroll, which is a no-op in the full-page case.

A flaky role no longer costs you the whole run

Automatic retry. A worker that dies for an infrastructure reason — an adapter error, a spawn that hit its ceiling, a dropped connection — is re-dispatched automatically (twice by default, with backoff). The classification is a deliberately narrow allow-list: a work failure (a bad prompt, a real tool error) is not retried, because a second dispatch would only buy the same answer at the price of another full timeout, and it would hide the fact that the task itself is the problem. Tighten the bound per node or workflow with maxRetries (0 disables it); it can only be lowered, never raised.

While it waits, the node is retrying — its own status and colour, because during the backoff nothing is running, and that is exactly the window that looks stuck. The attempt count is recorded on the node, so "it only succeeded on the third try" is evidence rather than a silent extra run.

Continue a run. A run that ended without everything succeeding can be continued instead of started over: its completed nodes are reused and only the failed ones and whatever was cut off behind them are dispatched again. It lands as a new run record linked to the old one by resumedFrom, so the previous attempt's node states survive — they are the evidence you consult to decide whether continuing is safe at all. In the UI, "继续运行" sits on every unfinished run in the run list and next to the failure explanation on the progress page.

Verified

Release gate	72/0 — installs the package every published way into throwaway profiles, boots one, drives its whole HTTP surface. Run against DSH Desktop 0.2.0-rc.2.
Packer	31/0
Offline battery	1208/0 across 11 suites
Mutation harnesses	9/9 — each breaks one behaviour and asserts the named check goes red

Install

dsh on your PATH:

dsh plugin --profile web add github:Drkoh-wz/team-craft#path:/packages/team-flowise

DSH Desktop (no dsh command): see the README — one script, shipped in this release's archive.

Install from the path you downloaded it to, not from a URL: an https tarball-URL dependency fails permanently once pnpm's store has seen that URL (ERR_PNPM_MISSING_TARBALL_INTEGRITY), and deleting the lockfile does not recover it.

v0.1.4

Makes the desktop install work on a machine whose network and pnpm store are not
cooperative, which is how it was found.

A green release gate was hiding two broken specs that the docs told people to run.

1. An https tarball-URL dependency fails permanently once pnpm's store holds that URL:

   ERR_PNPM_MISSING_TARBALL_INTEGRITY  its lockfile entry has no integrity field
   

   Measured: it reproduces on a second install into a second profile sharing the store, for a version-free latest/ URL and a version-pinned one alike, and deleting the lockfile does not recover it - only a fresh store does. git specs and local files are unaffected. The gate never caught it because its "tarball" route installs from a local path; it was never testing the URL the README and the catalog entry used.

2. A git spec needs git-over-HTTPS to github.com. On the machine this was found on, that was reset again (an IP pin added in September had started pointing at an address that drops the TLS handshake), so pnpm fell back to ssh and died on host key verification.

So the published shape is now: fetch the asset over plain HTTPS, install from the file it lands in. scripts/install-desktop.ps1 does that itself (its default spec is the release asset; it downloads it, then installs from the local path, so pnpm never resolves a URL), -DryRun no longer downloads anything, and the READMEs name the failure so nobody simplifies it back to a URL.

The gate gained the assertion that would have caught the first one: the documented git route is installed a second time into a second profile - the warm-store state every machine is in after its first install. 64/0 with it.

Verified by running it: the shipped script installs the local package into a fresh home in ~1.5 s (exit 0), a second fresh home sharing the warm store behaves identically, and that home then boots on DSH Desktop 0.2.0-rc.2 with the plugin live - 13/13. Packer 31/0.

Assets:

• team-flowise.tgz - the package as a package manager consumes it (0.1.4).
• team-flowise-plugin-0.1.4.tar.gz - the offline installer archive: package + skill + install.mjs, uninstall.mjs and install-desktop.ps1.

MIT.

v0.1.3

Adds scripts/install-desktop.ps1, and puts it in this archive.

DSH Desktop has no dsh on PATH -- it carries the harness inside its own bundle and owns the profile -- so the previous release documented a six-line PowerShell incantation for installing before the catalog lists this plugin. That is now one command:

.\scripts\install-desktop.ps1

It finds the app (running process, then the usual locations), refuses to run while DSH Desktop is up, because the app owns the profile and its own maintenance can reconcile the change away; picks up the pnpm the app ships when the shell has none; drives the bundled harness through the app's own binary (it has to: lib/bin.js sits inside app.asar, which plain node cannot load); and prints what to check after restart. -Action uninstall|check, -Spec, -DshHome, -DesktopRoot, -DryRun and -Force are the rest, with comment-based help.

Two bugs were found by running it rather than reading it, and both are fixed here:

• The harness logs to stderr, and under Windows PowerShell 5.1 a native command's stderr is an ErrorRecord: with $ErrorActionPreference='Stop' a normal run became a terminating error, $LASTEXITCODE came back empty so a failed install exited 0, and the output saying why was hidden.
• A .ps1 without a BOM is read as ANSI by Windows PowerShell 5.1, so the one Chinese UI label it named printed as mojibake for exactly the users it is written for. The script is pure ASCII now, and the packer fails the build on any non-ASCII byte in it.

Verified by running it: against an isolated home it installs this release's package URL (exit 0, dependency and bundle entry land, the composed tree carries the flowise-team row), and that home then boots on DSH Desktop 0.2.0-rc.2 with the plugin live - 13/13, including the four storage domains, the write path, the scheduler and the progress/role/models routes. The running-app guard was tested against the real running app. Release gate 57/0, packer 31/0.

Assets:

• team-flowise.tgz - the package as a package manager consumes it (unchanged in shape; version 0.1.3).
• team-flowise-plugin-0.1.3.tar.gz - the offline installer archive: package + skill + scripts/install.mjs, scripts/uninstall.mjs and now scripts/install-desktop.ps1.

MIT.

v0.1.2

Documentation release: the install instructions now cover DSH Desktop.

The 0.1.1 README documented dsh plugin --profile web add . and nothing else. That command is right for the CLI and does not exist for the packaged desktop app, which carries the harness inside its own bundle and keeps no dsh on PATH.

The install section now splits by client. Desktop gets its own part: its plugin panel is the install surface, and until this plugin is listed there, a block drives the bundled harness directly - through the app's own binary, because lib/bin.js sits inside app.asar and plain node cannot load it. It also states the desktop-side gate: a plugin whose declared @deepseek-ai/dsh-* peers do not include the running harness stays installed but startup denies it until an exemption is granted for those exact versions. This build declares >=0.2.0-rc.2 <0.3.0-0, so it matches.

"Did it work?" no longer pins 127.0.0.1:3080: on Desktop the port is chosen per launch and a local request without the boot token is answered 401, so that row was untestable there. The three UI checks hold on both clients.

No plugin code changed. The version moves because README.md ships inside the package and inside the installer archive, and the two assets here are the ones that carry the corrected text.

• team-flowise.tgz - the package as a package manager consumes it.
• team-flowise-plugin-0.1.2.tar.gz - the offline installer archive (package + skill + scripts).

MIT.

v0.1.1

Fixes the plugin on DeepSeek Harness 0.2.x, where the 0.1.0 build was refused at startup.

What was wrong. The plugin declared @deepseek-ai/dsh-tools and @deepseek-ai/dsh-storage-domain as regular dependencies, so a local install left a copy of them inside the package. Node resolves a linked plugin's imports from the plugin's own directory first, so that copy won -- and when the harness moved to 0.2.0, the stale copy died importing CallId from the host's dsh-llm:

flowise-team (required)
SyntaxError: The requested module '@deepseek-ai/dsh-llm' does not provide an export named 'CallId'
dsh: startup failed: 1 required plugin did not activate

That is a hard stop, not a degraded panel: the whole bootstrap refuses to come up.

What changed.

• Those packages are now peerDependencies, where the harness expects them; it supplies them at import time. The package directory carries none of them, and the range says >=0.2.0-rc.2 <0.3.0-0, measured rather than guessed -- on 0.1.5-rc.1 a peers-only plugin cannot import at all, so declaring the old line compatible would only have let the harness through to a confusing failure.
• zod, the plugin's own dependency, stays a dependency. Install it with npm install --omit=peer in the package directory for a link-style install.
• scripts/uninstall.mjs could not run at all on Windows: rmSync(p, { recursive: false }) on a junction throws ERR_FS_EISDIR, the first step died, and the run reported "0 removed / 0 already absent / 0 left over" under the error. unlinkSync removes the link alone. recursive: true was not an option: measured on Node 24, it removes the junction and the target's contents, i.e. the plugin source.

Verified. DSH Desktop 0.2.0-rc.2 (linked install: mounts, four storage domains, write path, scheduler, progress/role/models) and the dsh CLI 0.2.0-rc.2 (dsh plugin add, same surface): 13/13 checks each. The release gate passes on all three install routes. 1149 checks, 0 failures across the offline suites.

Asset team-flowise-plugin-0.1.1.tar.gz is the offline installer archive (package + skill + scripts); team-flowise.tgz is the package as a package manager consumes it.

MIT.

v0.1.0

Superseded by v0.1.1 for DeepSeek Harness 0.2.x.

This build declares the harness packages as dependencies, so it carries its own copy of them; on 0.2.0-rc.2 the harness refuses it at startup (does not provide an export named 'CallId'). Use v0.1.1 or later.

The plugin as a package, built from the repository at this tag.

Install it into a dsh profile:

dsh plugin --profile web add "git+https://github.com/Drkoh-wz/team-craft.git#path:packages/team-flowise"

Or from the attached prebuilt tarball:

dsh plugin --profile web add "https://github.com/Drkoh-wz/team-craft/releases/latest/download/team-flowise.tgz"

Restart dsh afterwards, then check GET /api/team-flowise/ping - it should answer {"ok":true,"pong":true,...} with four storage domains, and a new session's tool list should carry the seven team_* tools. The README records the DeepSeek Harness version this was verified against.

Assets:

• team-flowise.tgz - the package as a package manager consumes it.
• team-flowise-plugin-0.1.0.tar.gz - the offline installer archive (package + skill + scripts/install.mjs).

MIT.