Files
deepseek-harness/packages/workflow
Tianyi Cui 95c8c878e1 workflow: pin thenable-return semantics as documented async-JS behavior
Codex code-review round 4 flagged the return channel: an async IIFE
Promise-assimilates a returned thenable, so its then() runs past the sync
slice and the RESOLUTION replaces the raw object. Verified against the real
engine and judged behavior, not defect:

- Assimilation is standard JavaScript (an async function's returned thenable
  resolves before the caller sees it) and is load-bearing ergonomics: an
  un-awaited 'return agent(...)' / 'return parallel(...)' resolves to the
  intended value precisely because of it. Rejecting callable-then returns
  would break that; intercepting pre-assimilation is spec-impossible (the
  Get(v,'then') and job enqueue are internal to promise resolution).
- The realm-boundary guard applies to the RESOLUTION (a thenable resolving to
  non-JSON is still RESULT_UNSERIALIZABLE), so nothing crosses unmaterialized.
- A spin inside a returned thenable's then() is the same accepted class as any
  post-slice spin (it runs on the microtask queue, past the vm timeout's
  reach); the docs previously said 'after the first await', which was too
  narrow — reworded to 'past the initial synchronous slice (an await
  continuation, or a thenable's then invoked by promise resolution)'.

Pinned with an engine test (un-awaited return agent(); custom thenable
resolution as the return value; thenable resolving to non-JSON rejects), and
the limitation wording updated in the module doc, README, and RFC.
2026-07-05 20:57:51 +08:00
..

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-vm/ In-process node:vm engine: parses the script, injects the hooks, drives ctx.subagents (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 seam split exists for engine hardening: node:vm is in-process and cannot kill a pathological synchronous spin — a worker-thread or isolated-vm engine 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.