Tianyi Cui
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.
159 lines
6.4 KiB
YAML
159 lines
6.4 KiB
YAML
# The coding-agent plugin tree: the REPL agent demo. The two swappable
|
|
# backends — the DeepSeek adapter and the local bash executor — plus `hmr` for
|
|
# the dev/demo reload loop, then the stdio chat app (@deepseek-ai/dsh-stdio-
|
|
# agent), which bundles the whole agent-core spine (timer, llm, sessions,
|
|
# system-prompt, tools, agents, invariants, tool-bash, agent-loop), the console
|
|
# logger, JSONL persistence, the readline UI, and a pre-created `main` agent.
|
|
#
|
|
# `hmr` is a leaf entry (not baked into dsh-stdio-agent): it is a Loader-only
|
|
# dev plugin that needs `--expose-internals` — the `demo:repl` script passes
|
|
# it. Requires DEEPSEEK_API_KEY (and optionally DEEPSEEK_BASE_URL) in the
|
|
# environment — the dsh-stdio-agent bin loads the gitignored repo-root .env
|
|
# first. cordis.yml reads them via the `!!js` tag.
|
|
|
|
# Hot-module reload for the dev/demo loop (needs `node --expose-internals`).
|
|
- id: hmr
|
|
name: '@cordisjs/plugin-hmr'
|
|
config:
|
|
root: ['.']
|
|
|
|
# The DeepSeek adapter. Swap to '@deepseek-ai/dsh-llm-pi-ai' for the pi-ai-backed
|
|
# twin (same config shape; `reasoning: high` replaces thinking/reasoningEffort).
|
|
- 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-pro
|
|
- deepseek-v4-flash
|
|
|
|
# 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 stdio chat app: the whole spine + front-door cluster, configured for a
|
|
# REPL agent demo driving a pre-created `main` agent.
|
|
- id: stdio-agent
|
|
name: '@deepseek-ai/dsh-stdio-agent'
|
|
config:
|
|
model: deepseek-v4-flash
|
|
# Set RESUME_SESSION_ID to continue a prior persisted session (the ids live
|
|
# under ./.sessions); unset starts a fresh session each run.
|
|
resumeSessionId: !!js process.env.RESUME_SESSION_ID
|
|
persistenceRoot: './.sessions'
|
|
welcome: 'agent REPL ready. Give it a coding task (its tools are read, write, edit, bash, subagent, workflow, and todo_write).'
|
|
systemPrompt: |
|
|
You are coding-agent, a CLI coding assistant.
|
|
|
|
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, and never
|
|
rely on shell state between calls.
|
|
|
|
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.
|
|
|
|
Check the [exit code: N] marker on every command; investigate
|
|
failures before moving on. Verify your work by running the code or
|
|
tests. Keep answers brief and factual.
|
|
|
|
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.
|
|
|
|
# Automatic context compaction: when the derived history approaches the model's
|
|
# context window, summarize an older range into a checkpoint so a long-running
|
|
# or tool-heavy session keeps fitting. A leaf entry (needs ctx.llm + the
|
|
# agent-loop's `agent/pre-step` seam from the app above).
|
|
- id: compact-basic
|
|
name: '@deepseek-ai/dsh-compact-basic'
|
|
config:
|
|
contextWindow: 128000
|
|
thresholdRatio: 0.8
|
|
retainTokens: 20480
|
|
summarizationModel: ''
|
|
maxTokens: 8192
|
|
compactionRetries: 1
|
|
|
|
# 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
|
|
# independent backends over the shared dsh-subagent-inprocess driver. Exposing
|
|
# both transports is pure config: load each backend, then load dsh-tool-subagent
|
|
# once per backend with a distinct toolName (the tool registry rejects a
|
|
# duplicate name) — no code change.
|
|
- 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), rendered as a stdio checklist / ACP plan.
|
|
- 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. stdio-agent is a single
|
|
# session, so relative paths resolve from the process cwd (the workspace).
|
|
- 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'
|