Files
deepseek-harness/packages/workflow
Yichen Jiang fee12f1af0 refactor(llm-deepseek)!: rename the provider route to deepseek-official
The native adapter's route was named deepseek, colliding with pi-ai's
catalog provider of the same name, so the two DeepSeek paths could never
be mounted side by side. The web settings page needs both configurable at
once. Compositions, fixtures, goldens, scaffolding defaults, and docs all
move together (pre-release, no shim); TUI/session-query-spill/
missing-credential goldens re-recorded through their keyless refresh
modes because provider-name length shifts box padding and spill
truncation points.
2026-07-29 16:36:07 +08:00
..
2026-07-26 05:06:39 +08:00
2026-07-26 05:06:39 +08:00

workflow/ — dynamic-workflow capability family

English | 中文

The workflow seam: a model-written JavaScript orchestration script that fans out subagents at scale (phases, structured per-agent results, concurrency caps), modeled on Claude Code's dynamic workflows. A capability seam (see capability seams) in the bash shape: ONE engine implementation per context registers as ctx.workflows; the model-facing tool consumes it.

Package Role ctx key
workflow/ Abstract workflow seam: service base class + run vocabulary + workflow/* events ctx.workflows
workflow-workerthread/ node:worker_threads engine: one worker per run; the script's vm context lives inside the worker, agent() bridges to ctx.subagents over the message port (provides ctx.workflows)
tool-workflow/ Model-facing workflow tool over ctx.workflows (registers on ctx.tools)
tool-ralph/ Fixed fresh-agent Ralph policy over ctx.workflows and a fresh structured-output subagent provider (registers on ctx.tools)

The interface lives at workflow/workflow/. The engine's agent() hook rides the subagent seam (any registered provider; the shipped examples use spawn), and agent({ schema }) rides the structured-output support the in-process backends implement. The worker thread isolates the SCRIPT — the host never blocks on it, and a cancelled run's post-grace termination is real — but it is NOT a security boundary; an isolated-vm/separate-process engine (actual sandboxing) swaps in behind the same interface if that ever matters.

The general script engine's decisions and deferred work live in the dynamic-workflows Agent Note. The separate Ralph consumer fixes the script and fresh-provider policy rather than adding another engine or an agent-loop mode.