dsh-tongflow

dsh plugin --profile web add dsh-tongflow

dsh-tongflow

TongFlow as a DeepSeek Harness (dsh) plugin — a media studio inside your agent.

Three layers, never mixed up:

Layer · Owns

dsh · the harness: sessions, model routing, tools, jobs, web UI

the agent · creativity: the plan, the folder structure, briefs, scripts, prompts, review notes — plain files

TongFlow · deterministic generation: every image / voice / music / video / 3D asset is produced by running a saved workflow file (<name>.tongflow.json) through the TongFlow engine and its plugins

The studio itself is host-neutral — [tongflow-studio](../tongflow-studio) holds the projects, the engine runner and the tongflow_* tools, and serves the same tools as an MCP server (and a [Claude Code plugin](../../claude-plugin/tongflow)). This package is the dsh adapter: it adds the Studio panel and the embedded canvas.

There is deliberately no "generate an image" tool and no project template. The agent studies what the user wants to make (with web research when useful), proposes a folder structure, writes it down, and then — for every asset — creates a workflow file where that asset belongs, runs it, reviews the result, and builds the next stage on it. Users open the same .tongflow.json on the embedded canvas, tweak it, and re-run; they can also reorganize the folders by hand at any time.

Install

npx @deepseek-ai/dsh@next plugin --profile web add dsh-tongflow      # from npm
# or from a tarball:  pnpm --filter dsh-tongflow pack  →  dsh plugin --profile web add ./dsh-tongflow-x.y.z.tgz
npx @deepseek-ai/dsh@next web

Requirements: dsh ≥ 0.1.2-rc.1 — the 0.1.2-rc, 0.1.3-alpha, 0.1.5, 0.1.7, 0.2.0 and 0.2.1-alpha lines are supported (engines.dsh; verified releases are listed in dsh.compatibility.dshReleases); 0.1.1-rc and older are not (the client Runtime package they build on was removed upstream, so upgrade dsh rather than pinning an old plugin). Because npm only matches a prerelease when a range clause carries its exact major.minor.patch, each new dsh prerelease line needs its own clause in peerDependencies. From 0.2.0 on dsh checks those ranges itself and does not load a plugin whose @deepseek-ai/dsh-* peers exclude the running version (unless you grant dsh plugin allow-version), so a host on a line newer than the ones listed needs a newer plugin. Also Node ≥ 22.19, Python ≥ 3.10 on PATH (or pythonPath in the plugin config), git, and ffmpeg for video contact sheets. On first use the plugin creates ~/.dsh/tongflow/venv with the tongflow SDK and shallow-clones every official TongFlow plugin into ~/.dsh/tongflow/plugins (the live list from config/official-plugins.json; set autoInstallOfficial: false to install by hand), so the canvas offers the same node/plugin catalog as the hosted app. Keys and Modal deploys are only needed when something runs.

Start a session whose first message begins with @tongflow — that session becomes a studio session: the conversation view turns into the Studio (chat column · the project's folder tree · preview / editor / canvas · a runs drawer, all in the UI language of your browser), and the agent gets the tongflow_* tools and skill. Any other session is untouched dsh. In the Studio: create a project (a title and a brief — what you want to make), install TongFlow plugins and paste API keys under Plugins & keys, then talk to the agent — or click any file to preview / edit it, click a workflow to open it on the canvas.

Chat model

Any model dsh can route works. For the agent to see generated images (tongflow_look) use a vision-capable route, e.g. in $DSH_HOME/settings.yaml:

llm-pi-ai:
  providers:
    google:
      apiKeyEnv: GEMINI_API_KEY
    my-qwen:                          # a self-hosted Qwen3.8-27B behind vLLM
      apiKeyEnv: QWEN_API_KEY
      api: openai-completions
      baseURL: http://127.0.0.1:8000/v1
      models:
        - id: Qwen/Qwen3.8-27B
          input: [text, image]

Video and audio are reviewed through TongFlow's own describe / transcribe slots (tongflow_perceive), so they work with any chat model.

The project (a plain folder)

~/.dsh/tongflow/projects/<id>/
  project.json                     title, brief, locale — the only fixed file
  README.md                        the agent's plan: what the folders are, in what order things get made
  …whatever the work needs…        e.g. characters/, ep01/sh010/, music/, export/ — designed per project

The one rule: every AI-generated asset comes from a workflow file that sits next to its outputs.

characters/mei/
  mei.md                    what the agent wrote about her
  mei_ref.tongflow.json     the workflow that renders her reference sheet
  mei_ref.01.png            run 1
  mei_ref.02.png            run 2  (a run never overwrites — fix the workflow, run again)
  mei_ref.runs.json         provenance of every run: inputs, plugins, note, timing

• Multi-output runs keep the workflow's output names: mei_ref.03.image.png + mei_ref.03.caption.txt; text outputs are written as .txt too.
• Workflows reference project files by path: ./mei_ref.02.png / ../style/palette.png (relative to the workflow file) or characters/mei/mei_ref.02.png (relative to the project root); URLs pass through.
• Text files can be included in prompts: {{../style.md}} {{./mei.md}} full-body sheet — expanded at run time, so a shared style note is written once.
• Compose: tongflow_workflow_compose({ folder }) merges the small workflows of a folder (or an explicit list) into one <folder>_all.tongflow.json — a data node that references another part's output file (./ref.01.png) becomes an edge from that part's producing node, parts are ordered by those dependencies, every stage stays an output labelled after its part (shot_all.01.i2v.mp4 via meta.outputLabels), the parts are un

…(truncated)