dsh-flow

Long-running or highly complex multi-agent workflows rarely stall because of missing tools. They stall because the executor cannot be swapped, state has no single source of truth, and module boundaries are never asserted. A task that has been running for hours crashes once, and you cannot say how far it got; changing how work is executed means changing the core, and so does adding a new kind of team source. dsh-flow treats all three as kernel-shape problems: the 25 modules under rules/ touch neither IO nor runtime context, execution and team sources are declared seams, and kernel.js is the single composition root that decides which implementation this deployment attaches at startup. Adding another execution mode is writing one more Provider; adding another team-data source is one register() call. The core and the tool layer stay untouched.

Once the plugin is running, an Agent Canvas tab appears above the conversation area. User requirement turns are drawn on the main timeline, and the team grows as a nested region beneath them. Each member owns a sub-region holding task chips wired by dependency depth and speech cards laid out in time order. Assignment is expressed by containment, dependency by arrows, and dialogue flow by the turn chain crossing regions. Clicking a task row opens the full attempt timeline: how every attempt ended and which one was rolled back. Unreadable import lines land in the on-canvas import report with line-number annotations. The runner can be fixed to manual mode at composition time, letting you inspect and edit the view without triggering any execution.

The state layer treats an append-only events.jsonl as the single source of truth; state.json is merely one projection of it. When the two disagree, the log wins, and any difference that cannot be expressed is refused rather than silently resolved. The plugin has zero runtime dependencies - clone it and it runs. Canvas modules are served over HTTP per file, invalidated by mtime and revalidated via ETag, so a one-line change takes effect on a page refresh with no build step and no restart. 434 tests finish in 1.1 seconds, and seven layer-boundary assertions run on every build to verify that the pure core never touches IO, that the canvas never reaches into host layers, and that dependencies point inward only. It is aimed at developers and teams who run long-horizon multi-agent collaboration on DeepSeek Harness and care about pluggable, testable, migrable workflows with consistent state and enforceable boundaries.