Tianyi Cui
ebcfab1621
pkg stores application files in a virtual filesystem, and its worker_threads hook discovers worker entry points only when they are passed as filesystem strings. Convert the code-runtime entry with fileURLToPath() and return the workflow built entry as a string while retaining its source-mode data URL bootstrap. Emit worker entry bundles as CommonJS .cjs files. pkg executes a VFS-backed string-path worker through Module._compile, so an ESM-only entry can be present in the executable yet still fail when launched. Keep the public hosts ESM, adapt worker startup accordingly, and align exports, package file lists, workspace constraints, documentation, and built-worker tests with the actual artifact format. Expand the custom-config executable smoke to load the Code Mode and workflow plugins and script real run_code and zero-agent workflow calls. Require both tools to return 42 from workers launched inside the pkg VFS, turning worker support from an asset-presence assumption into an end-to-end runtime contract. Update the implemented RFC and verification gates to describe and exercise the supported built-worker path. This adds no tool or JSON-RPC protocol shape; it fixes how existing worker-backed capabilities are located and executed in the single-file distribution.
workflow/ — dynamic-workflow capability family
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) |
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 proposal, decisions, and deferred work: docs/rfc/implemented/feature/2026-07-05-dynamic-workflows.md.