1d43ea3cd5
A new capability family at packages/workflow/ in the bash seam shape,
modeled on Claude Code's dynamic workflows: the model writes a JavaScript
orchestration script (export const meta = {...} + plain-JS body), a runtime
executes it, and the script — not the conversation — holds the loop, the
branching, and the intermediate results.
- dsh-workflow (ctx.workflows): abstract WorkflowService + run vocabulary
(WorkflowRun whose result NEVER rejects) + observe-only workflow/* events
carrying data snapshots (id + meta, never the live run), per-listener
contained like subagent/*.
- dsh-workflow-vm: in-process node:vm engine. Meta extraction via a
string/comment-aware scanner (template interpolation rejected; literal
evaluated alone in an empty timed context; statement blanked line-
preservingly so stacks keep script line numbers). Hooks: agent(prompt,
{label, phase, schema, model}) over ctx.subagents, parallel(), pipeline()
(no cross-stage barrier), phase(), log(), args. Fatal-vs-null discipline:
hook misuse (unknown/deferred options, bad arguments, unsupported
schemas, tripped caps, seam start failures, cancellation) throws fatal
WorkflowErrors the combinators RE-THROW — never dissolved into the
per-item null reserved for child failures. Realm boundary: inbound values
materialized by descriptor walks that never invoke accessors (defineProperty
copies, __proto__-safe); outbound values rebuilt in-realm via the
context's own JSON.parse. Determinism bans (Date.now/Math.random/argless
new Date) kept so future resume support cannot break scripts. Caps and
timeouts are validated Config. Every hook promise carries a no-op
rejection consumer (app-boot exits on unhandled rejections).
- dsh-tool-workflow: the model-facing workflow tool, synchronous like
dsh-tool-subagent (start → await → try/finally dispose; abort bridged;
non-completed → isError). Generic render card titled by a textual
meta.name sniff. The tool description carries the authoring contract.
Wired into examples/{coding-agent,acp-agent} with explicit-ask-only
guidance. Coverage at every tier: unit (meta scanner, materializer incl.
counting-getter and __proto__ regressions, combinator semantics,
concurrency ceiling, caps, cancellation, no-unhandled-rejection abandon),
integration over the real spawn stack, with-key e2e (real two-phase run +
the tool through the registry pipeline), and a recorded ACP snapshot
scenario (workflow-run, 1 child session). RFC:
docs/rfc/implemented/feature/2026-07-05-dynamic-workflows.md (deferred
work explicitly listed). AGENTS.md budget 1575 → 1590 for the new group's
layout line.
160 lines
6.8 KiB
YAML
160 lines
6.8 KiB
YAML
# The acp-agent plugin tree: the ACP server. Also the snapshot RECORD config
|
|
# (the dsh-acp-agent bin selects it for DSH_SNAPSHOT=record): a real llm-deepseek
|
|
# run whose persisted log the snapshot harness harvests. The swappable DeepSeek
|
|
# adapter, local bash/filesystem executors, the ACP server app
|
|
# (@deepseek-ai/dsh-acp-agent), and the optional model-facing fs/subagent/todo
|
|
# tools loaded below.
|
|
#
|
|
# CRITICAL: this tree loads NO stdout logger and NO hmr — stdout is reserved for
|
|
# the ACP JSON-RPC protocol (see packages/ui/acp). That guarantee is now a
|
|
# property of @deepseek-ai/dsh-acp-agent (it contains no logger entry), not a
|
|
# leaf convention: there is no logger here to get wrong.
|
|
#
|
|
# Requires DEEPSEEK_API_KEY (and optionally DEEPSEEK_BASE_URL) — the
|
|
# dsh-acp-agent bin loads the gitignored repo-root .env first (on STDERR only).
|
|
|
|
# The DeepSeek adapter.
|
|
- id: llm-deepseek
|
|
name: '@deepseek-ai/dsh-llm-deepseek'
|
|
config:
|
|
apiKey: !!js process.env.DEEPSEEK_API_KEY
|
|
baseURL: !!js process.env.DEEPSEEK_BASE_URL
|
|
models:
|
|
- deepseek-v4-flash
|
|
- deepseek-v4-pro
|
|
|
|
# Local bash executor for agent-core's tool-bash schema.
|
|
# FIXME(config-comments): keep this executor note from implying bash is the
|
|
# whole tool set; filesystem, subagent, and todo_write are loaded below.
|
|
- id: bash
|
|
name: '@deepseek-ai/dsh-bash-local'
|
|
config:
|
|
timeoutMs: 60000
|
|
|
|
# The ACP server app: the agent-core spine + JSONL persistence + the ACP bridge.
|
|
# Persistence root: $DSH_SNAPSHOT_SESSIONS_ROOT when the snapshot harness sets it
|
|
# (so it can harvest / isolate the log), else ./.sessions for the demo.
|
|
- id: acp-agent
|
|
name: '@deepseek-ai/dsh-acp-agent'
|
|
config:
|
|
model: deepseek-v4-flash
|
|
persistenceRoot: !!js process.env.DSH_SNAPSHOT_SESSIONS_ROOT ?? './.sessions'
|
|
systemPrompt: |
|
|
You are a coding assistant driven over the Agent Client Protocol.
|
|
|
|
Your tools are read/write/edit for file operations, bash (plus
|
|
bash_output/bash_kill for background tasks), and subagent. Use read to
|
|
inspect UTF-8 text files, write to create or replace files, and edit for
|
|
targeted literal replacements. Use bash for shell commands, tests,
|
|
searches, and operations that are not ordinary file reads or edits. Each
|
|
bash call runs in a fresh shell — pass workdir instead of cd. Check the
|
|
[exit code: N] marker; verify your work. Keep answers brief and factual.
|
|
|
|
Use the subagent tool to delegate a focused, self-contained subtask to
|
|
a fresh child agent (it works in its own context and returns only its
|
|
final result) — give it a complete, standalone instruction. Use
|
|
subagent_fork instead when the subtask needs THIS conversation's
|
|
context: the child inherits the log so far.
|
|
|
|
Use the workflow tool ONLY when the user explicitly asks for a
|
|
workflow or for large multi-agent orchestration: you write a
|
|
JavaScript script (its description documents the exact format) that
|
|
fans work out across many subagents with phases and structured
|
|
results. For one or two delegations, prefer plain subagent calls.
|
|
|
|
For multi-step work, use the todo_write tool to track a task list:
|
|
send the WHOLE list each call (it replaces the previous one), keep at
|
|
most one task in_progress (exactly one while work remains), and mark a
|
|
task completed as soon as it is done. Skip it for trivial single-step
|
|
tasks.
|
|
|
|
# The subagent seam + both in-process backends + two model-facing tools, as leaf
|
|
# entries after the app (which provides ctx.agents/ctx.tools). spawn (a fresh
|
|
# child) and fork (a child seeded with the parent's completed-turn prefix) are
|
|
# both reachable by the model: dsh-tool-subagent is loaded once per backend with
|
|
# a distinct toolName (subagent → spawn, subagent_fork → fork), so a multi-child
|
|
# scenario can exercise both transports.
|
|
- id: subagent
|
|
name: '@deepseek-ai/dsh-subagent'
|
|
|
|
- id: subagent-spawn
|
|
name: '@deepseek-ai/dsh-subagent-spawn'
|
|
config:
|
|
providerName: spawn
|
|
|
|
- id: subagent-fork
|
|
name: '@deepseek-ai/dsh-subagent-fork'
|
|
config:
|
|
providerName: fork
|
|
|
|
- id: tool-subagent
|
|
name: '@deepseek-ai/dsh-tool-subagent'
|
|
config:
|
|
provider: spawn
|
|
toolName: subagent
|
|
|
|
- id: tool-subagent-fork
|
|
name: '@deepseek-ai/dsh-tool-subagent'
|
|
config:
|
|
provider: fork
|
|
toolName: subagent_fork
|
|
|
|
|
|
# Dynamic workflows: the node:vm engine (ctx.workflows) over the spawn subagent
|
|
# backend above, plus the model-facing `workflow` tool. The model writes a
|
|
# JavaScript orchestration script (meta + body); the engine runs it in-process
|
|
# and fans agent() calls out as spawn children.
|
|
- id: workflow-vm
|
|
name: '@deepseek-ai/dsh-workflow-vm'
|
|
config:
|
|
provider: spawn
|
|
|
|
- id: tool-workflow
|
|
name: '@deepseek-ai/dsh-tool-workflow'
|
|
# The model-facing todo_write tool: whole-list task tracking written to the
|
|
# session log (todo/write), surfaced to the ACP client as a `plan` update.
|
|
- id: tool-todo
|
|
name: '@deepseek-ai/dsh-tool-todo'
|
|
|
|
# Filesystem capability stack: local provider, read-before-write/edit policy
|
|
# gate, then the model-facing read/write/edit tools. Relative filesystem paths
|
|
# resolve from the server launch cwd; the documented Zed setup launches this
|
|
# demo from the harness checkout with `pnpm --dir`.
|
|
- id: fs-local
|
|
name: '@deepseek-ai/dsh-fs-local'
|
|
config:
|
|
cwd: !!js process.cwd()
|
|
|
|
- id: fs-policy
|
|
name: '@deepseek-ai/dsh-fs-policy'
|
|
|
|
- id: tool-fs
|
|
name: '@deepseek-ai/dsh-tool-fs'
|
|
|
|
# The Claude Code hook bridge. `configPath` is PROCESS-LEVEL: it is read ONCE at
|
|
# load and the relative `./hooks.json` resolves against the ACP server's launch
|
|
# cwd, NOT each `session/new.cwd`. So a single `hooks.json` next to where the
|
|
# server starts applies to every session; a project-local, per-session hooks.json
|
|
# is NOT discovered (per-session config resolution is a TODO — see the bridge
|
|
# README). With no file present the parse fails-soft and the bridge registers
|
|
# nothing (a silent no-op). Hooks THEMSELVES run in the session cwd (the bridge
|
|
# passes it as the workdir); only WHERE the config is read from is process-level.
|
|
# stdout is the ACP JSON-RPC channel — the bridge's warnings go through ctx.logger
|
|
# (no exporter here), never to stdout.
|
|
- id: hooks-claude
|
|
name: '@deepseek-ai/dsh-hooks-claude'
|
|
config:
|
|
configPath: ./hooks.json
|
|
|
|
# The Codex hook bridge, loaded alongside the Claude one. It reads its OWN config
|
|
# file (`./codex-hooks.json`, Codex's snake_case five-event dialect) — the two
|
|
# bridges cannot share one file, so each owns a distinct path. Same process-level
|
|
# read-once semantics and same fails-soft-when-absent contract: a launch cwd with
|
|
# no `codex-hooks.json` registers nothing (a silent no-op through ctx.logger, never
|
|
# stdout). The example ships both bridges so a scenario can exercise EITHER dialect
|
|
# end-to-end by seeding the matching file in its workspace/.
|
|
- id: hooks-codex
|
|
name: '@deepseek-ai/dsh-hooks-codex'
|
|
config:
|
|
configPath: ./codex-hooks.json
|