@xneog/dsh-workflow-worker-thread 0.1.0 → 0.1.3-alpha.1

package/README.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write packages/workflow/workflow-worker-thread/README.md
-README.md: ba32c9dab4e870dd52c8f8acba3cfa627fa78000
-README.zh.md: 99107aec40a45c8460f10082f2b75b908e3e8692
+README.md: 954682f166b7aa51f07d14dae3046bb40dbc52a6
+README.zh.md: 2252616d4d58c3a543ead79246973037be498a8c

package/README.md

@@ -1,90 +1,132 @@
+---
+description: "The worker-thread workflow engine: executes model-written orchestration scripts off the host event loop, for users and maintainers choosing or configuring execution isolation."
+kind: "package-reference"
+---
+
 # @xneog/dsh-workflow-worker-thread
 
 English | [中文](README.zh.md)
 
-This package implements `WorkflowEngine` with one Node worker thread per run. The worker executes the orchestration script; child agents remain on the host and are reached through `ctx.subagents` over a typed host/worker protocol.
+## Summary
 
-The package root exports the default engine plugin and its `Config`; the worker protocol, runtime, and session modules stay private to the implementation. The operational `./worker` entry remains the engine's spawn target.
+`dsh-workflow-worker-thread` implements the workflow engine with one Node worker thread per run: the orchestration script executes inside a fresh worker while its `agent()` calls reach host subagents over a typed host/worker protocol. A synchronous script loop cannot block the harness event loop, and a script that ignores cancellation can be terminated with its worker. The isolation is containment, not a security boundary — a model-written script has the same trust premise as the model's existing bash access, and escaping the `node:vm` context recovers the worker's process authority. Mount this engine to give `ctx.workflowEngine` a concrete implementation; a composition that loads it with `dsh-tool-workflow` gives the model the `workflow` tool.
 
-The split has one primary purpose: a synchronous script loop cannot block the harness event loop, and a script that ignores cancellation can be terminated with its worker. It is not a security sandbox.
+## Table of Contents
 
-## Trust and isolation boundary
+- [Use this package](#use-this-package)
+- [Understand the implementation](#understand-the-implementation)
+- [Further Exploration](#further-exploration)
+- [Model Experience](#model-experience)
+- [Known Limitations and Deferred Work](#known-limitations-and-deferred-work)
+- [Dev Note](#dev-note)
 
-Workflow scripts are model-written and have the same trust premise as the model's existing bash access. `node:vm` inside a worker is an API-shaping mechanism, not a security boundary: an escaped script can recover Node capabilities with the host process's privileges.
+-----
 
-The worker still provides useful containment:
+<a id="use-this-package"></a>
+## Use this package
 
-- Script CPU work and synchronous spins stay off the host event loop.
-- `worker.terminate()` gives disposal a real final stop.
-- The worker starts with an empty environment, except unbuilt loader plumbing, so ambient credentials do not cross through `process.env`.
-- Host/worker messages use structured-clone data, with plain-JSON validation at the script boundary.
+Mount this engine when a composition needs the workflow capability: each orchestration script runs in its own worker thread, off the host event loop, and the `workflow` and `ralph` tools in the shipped composition execute on it. Do not use it as a sandbox for genuinely untrusted scripts — hostile code needs a separate-process or container engine.
 
-A genuinely untrusted-script sandbox would require a different engine behind the same workflow seam.
+### Minimal configuration
 
-## Script contract
+Loading the engine registers `ctx.workflowEngine`; adding `dsh-tool-workflow` on top gives the model the `workflow` tool. Every config field is optional:
 
-The workflow's `meta` is host-provided data, not evaluated script text. The engine validates its required `name` and `description`, rejects unknown fields, and parse-checks the body before returning a run.
+```yaml
+- name: '@xneog/dsh-workflow-worker-thread'
+- name: '@xneog/dsh-tool-workflow'
+```
 
-Inside the worker, the script receives `args` and these hooks:
+| Field | Default | Meaning |
+|---|---|---|
+| `provider` | `spawn` | Host-side subagent provider used by `agent()` calls. |
+| `maxConcurrentAgents` | `0` | Concurrent `agent()` ceiling; `0` resolves from available CPU parallelism. |
+| `maxTotalAgents` | `1000` | Total `agent()` calls one run may start — the runaway-loop backstop. |
+| `maxItemsPerCall` | `4096` | Items accepted by one `parallel()` or `pipeline()` call. |
+| `syncTimeoutMs` | `5000` | VM timeout for the script's initial synchronous slice, in milliseconds. |
+| `disposeGraceMs` | `5000` | Bound before force-settlement and worker termination; also bounds `dispose()`. |
 
-- `agent(prompt, { label, phase, schema, model })` starts one host-side subagent. With a schema it returns the structured value; otherwise it returns final text. An ordinary failed child yields `null`.
-- `parallel(thunks)` runs thunks under the configured concurrency limit.
-- `pipeline(items, ...stages)` passes `(previous, item, index)` without a cross-stage barrier.
-- `phase(title)` and `log(message)` emit observer narration.
+An owning consumer may set `WorkflowStartRequest.subagentProvider` and `WorkflowStartRequest.maxTotalAgents` for one run — engine-level policy, not script hooks; the ordinary `workflow` tool leaves both unset, and a per-run total-child cap may lower but never raise the configured ceiling. The generated [configuration catalog](../../../docs/config-catalog.md#xneogdsh-workflow-worker-thread) is the exhaustive source for every accepted field.
 
-Unknown options, malformed arguments, unsupported schemas, tripped caps, provider-start failures, and infrastructure result failures are fatal workflow errors. No timers, filesystem API, or Node globals are intentionally injected, though the trust caveat above still applies.
+### What a run gives you
 
-## Run sequence
+When a run starts, the script body executes in the worker with top-level `await` and the hooks `agent()`, `parallel()`, `pipeline()`, `phase()`, and `log()`; `meta` and `args` arrive as plain JSON data, never evaluated code. Every `agent()` call starts a host-side subagent under the configured provider, with the run's parent as the parent of every child. The run settles with the script's final JSON value; an ordinary child failure resolves `agent()` to `null` so the script can handle it.
 
-`start()` validates meta, parses the body, resolves a registered normalized provider route, and resolves any per-run total-child cap before creating a worker or publishing `workflow/start`. A requested `maxTotalAgents` must be a positive safe integer no greater than the engine's configured deployment ceiling. Source mode installs TypeScript transforms through a data-URL bootstrap; built mode passes sibling `lib/worker.cjs` as a filesystem path because pkg's VFS hook expects CommonJS. Both work under ordinary Node. A ready/go handshake prevents a start-signal cancellation racing worker boot from executing the script's initial synchronous slice.
+A malformed meta block, a body that does not parse, an unavailable provider route, or a per-run cap above the ceiling is rejected synchronously before a worker exists, so the caller sees a violation list and can correct the call. During execution, hook misuse and tripped caps kill the script with a fatal workflow error. Cancellation is bounded: a script that ignores it is force-settled as cancelled and its worker terminated after `disposeGraceMs`.
 
-For each `agent()` call:
+### Trust expectations
 
-1. The worker sends `child-start` with a plain-data prompt and options.
-2. The host calls the start request's provider override, or otherwise the configured provider, through async `SubagentRuntime.start`, passing the workflow's parent and one canonical per-run abort signal. Provider choice applies to every child in that run and is not visible to the script.
-3. If start rejects, the host sends `child-start-error`; provider startup has already reached quiescence and no child lifecycle event is emitted.
-4. If start fulfills while the workflow still admits work, the host records the run, observes `result`, then sends `child-started`. Even an already-settled result is forwarded afterward, preserving start-before-result order.
-5. The worker emits paired `workflow/agent-start` and `workflow/agent-end` narration and requests child disposal after collection.
+Script CPU work and synchronous spins stay off the host event loop, `worker.terminate()` gives disposal a real final stop, and the worker starts with a scrubbed environment — only platform temp paths and, in source mode, `TSX_TSCONFIG_PATH` — so ambient credentials do not cross through `process.env`. Host/worker messages use structured-clone data with plain-JSON validation at the script boundary.
 
-Provider starts are tracked separately from published children. If cancellation, worker death, or normal workflow settlement closes admission while a start is pending, the shared signal aborts it. A provider that nevertheless fulfills after closure is disposed by the host and never announced to the worker.
+None of this is a security boundary: no timers, filesystem API, or Node globals are intentionally injected, but escaped code can still reach Node with the worker's process authority.
 
-## Value boundary
+-----
 
-Values leaving the script pass through `materializeFromRealm`, which accepts plain, lossless JSON data and rejects exotic prototypes, functions, symbols, cycles, sparse arrays, non-finite numbers, and nested `undefined`. The walk runs in the worker, and defines object keys as data properties so `__proto__` cannot mutate a prototype.
+<a id="understand-the-implementation"></a>
+## Understand the implementation
 
-Child results are projected and snapshotted before crossing from the host to the worker. This is a real process-like serialization boundary; it is deliberately different from trusted same-process workflow and subagent event payloads, which are borrowed immutable values.
+<details>
+<summary>Implementation internals — click to expand</summary>
 
-## Cancellation and disposal
+This section explains the engine's isolation design and run mechanics; observable behavior is fully covered in [Use this package](#use-this-package).
 
-`WorkflowRun.cancel()` records the first reason, tells the worker to cancel, aborts the one signal shared by every pending and published child, and arms the `disposeGraceMs` timer. Worker hooks then throw `CANCELLED` at their next await. If the run remains unsettled at the deadline, the host resolves it as cancelled, pairs stranded child lifecycle events, and terminates the worker.
+### Design concept
 
-The subagent seam has one cancellation channel: the request signal. There is no separate child-cancel RPC. Published child teardown uses `run.dispose()`; pending provider starts remain provider-owned until their promise rejects or fulfills.
+One worker thread per run keeps a misbehaving script from stalling the host and makes force termination possible: the script runs in an escapable `node:vm` context inside the worker, and `agent()` calls cross a typed host/worker protocol back to `ctx.subagents`. The vm context shapes the script's API surface; it is not a security sandbox.
 
-Normal settlement also aborts pending starts and begins disposing any published fire-and-forget children before the result becomes externally settled. The host's quiescence condition includes both pending starts and published child disposals, so cleanup does not forget an async startup transaction.
+### Source map
 
-`dispose()` is idempotent. It cancels the run, starts host-driven disposal immediately, waits for result plus child quiescence up to the same grace, terminates the worker unconditionally, and performs a final survivor sweep. Per-child disposal is memoized so worker RPC, host cancellation, death cleanup, and public disposal all join one operation.
+| File | Role |
+|---|---|
+| [`src/index.ts`](src/index.ts) | Plugin entry: `Config` schema, up-front validation, `start()` wiring |
+| [`src/host.ts`](src/host.ts) | Host side of a run: worker spawn, child orchestration, settlement, disposal |
+| [`src/worker.ts`](src/worker.ts) | Worker entry: script execution, hook implementation, value materialization |
+| [`src/runtime.ts`](src/runtime.ts) | Script runtime: hook contracts, `parallel()` and `pipeline()` combinators |
+| [`src/realm.ts`](src/realm.ts) | Cross-realm materialization: plain-JSON acceptance and rejection rules |
+| [`src/protocol.ts`](src/protocol.ts) | Typed host/worker message protocol |
+| [`src/meta.ts`](src/meta.ts) | `meta` shape validation and normalization |
+| [`src/session.ts`](src/session.ts) | Child run projection and snapshotting before crossing to the worker |
+| — | No runtime invariant companion is published; this process-boundary implementation exposes no same-process event relation; worker protocol and built-worker tests cover it. |
 
-## Outcome and event guarantees
+### Run sequence
 
-Terminal outcome is first-wins at host claim points. An accepted external cancellation overrides a later non-cancelled worker result; a result or worker death that claims first cannot be rewritten by reentrant cleanup callbacks.
+`start()` validates the meta block, parses the body, resolves the provider route, and resolves the per-run total-child cap before creating a worker or publishing `workflow/start`. A ready/go handshake prevents a start-signal cancellation racing worker boot from executing the script's initial synchronous slice; source mode installs TypeScript transforms through a data-URL bootstrap, while built mode passes the sibling `lib/worker.cjs` bundle.
 
-Worker error, message failure, or premature exit closes message admission before cleanup, then resolves `error` unless cancellation already owns the run. Late queued messages cannot create children or narrate after that logical boundary.
+For each `agent()` call the worker sends a `child-start`; the host starts the provider (the request's override, or the configured provider) through the subagent seam, attributes the child to the run's parent, and reports start or start-error back. Provider choice applies to every child in the run and is not visible to the script. Provider starts are tracked separately from published children, so a pending start is aborted by the shared signal when cancellation, worker death, or normal settlement closes admission.
 
-The host keeps a ledger of forwarded child starts. A graceful worker supplies their ends; death or force termination synthesizes any missing end as cancelled. Every forwarded `workflow/agent-start` is therefore paired exactly once, although cleanup after an already-arrived workflow result may complete afterward.
+### Value boundary
 
-## Config
+Values leaving the script pass through realm materialization, which accepts plain lossless JSON data and rejects exotic prototypes, functions, symbols, cycles, sparse arrays, non-finite numbers, and nested `undefined`. Child results are projected and snapshotted before crossing from host to worker — a real process-like serialization boundary, deliberately different from the borrowed immutable values of same-process workflow events.
 
-| Key | Default | Meaning |
-|---|---|---|
-| `provider` | `spawn` | Host-side subagent provider used by `agent()`. |
-| `maxConcurrentAgents` | `0` | Concurrent `agent()` ceiling; `0` resolves from available CPU parallelism. |
-| `maxTotalAgents` | `1000` | Total `agent()` calls in one run. |
-| `maxItemsPerCall` | `4096` | Items accepted by one `parallel()` or `pipeline()` call. |
-| `syncTimeoutMs` | `5000` | VM timeout for the script's initial synchronous slice. |
-| `disposeGraceMs` | `5000` | Bound before force-settlement/termination and for public disposal. |
+### Cancellation and disposal
+
+`cancel()` records the first reason, tells the worker to cancel, aborts the one signal shared by every pending and published child, and arms the `disposeGraceMs` timer; worker hooks then throw `CANCELLED` at their next await. If the run remains unsettled at the deadline, the host resolves it as cancelled, pairs stranded child lifecycle events, and terminates the worker.
+
+`dispose()` is idempotent: it cancels the run, starts host-driven disposal immediately, waits for result and child quiescence up to the same grace, terminates the worker unconditionally, and performs a final survivor sweep. Per-child disposal is memoized so worker RPC, host cancellation, death cleanup, and public disposal all join one operation.
+
+### Outcome and event guarantees
+
+Terminal outcome is first-wins at host claim points: an accepted external cancellation overrides a later non-cancelled worker result, and a result or worker death that claims first cannot be rewritten by reentrant cleanup callbacks. Worker error, message failure, or premature exit closes message admission before cleanup, then resolves `error` unless cancellation already owns the run.
+
+The host keeps a ledger of forwarded child starts; a graceful worker supplies their ends, while death or force termination synthesizes any missing end as cancelled — every forwarded `workflow/agent-start` is paired exactly once.
+
+</details>
 
-An owning consumer may set `WorkflowStartRequest.subagentProvider` and `WorkflowStartRequest.maxTotalAgents` for one run. These are engine-level policy, not script hooks or model-facing options; the ordinary `workflow` tool leaves both unset. A per-run total-child cap may lower but never raise the configured `maxTotalAgents` ceiling.
+-----
 
+<a id="further-exploration"></a>
+## Further Exploration
+
+Read these pages when the engine-level contract is not enough. They move from the seam contract to the model-facing consumers and the design decisions.
+
+- [Workflow subsystem](../../../docs/subsystems/workflow.md) — the seam contract this engine implements.
+- [Workflow seam](../workflow/README.md) — the run and result vocabulary behind `ctx.workflowEngine`.
+- [workflow tool](../tool-workflow/README.md) — the model-facing consumer that runs scripts on this engine.
+- [Group map](../README.md) — the workflow capability family and its packages.
+- [Dynamic workflows Agent Note](../../../.agents/notes/implemented/feature/2026-07-05-dynamic-workflows.md) — the seam design and its decisions.
+
+-----
+
+<a id="model-experience"></a>
 ## Model Experience
 
 ### Child-agent requests
@@ -105,7 +147,7 @@ Independent of the parent request cache and of sibling children. Each child can
 
 #### What the model sees
 
-Through [`dsh-tool-workflow`](../tool-workflow/README.md), success exposes only the materialized final JSON value and child count in that consumer's wrapper. This engine supplies stable errors including `workflow script does not parse: <error>`, `invalid meta: <violations>`, `agent() requires a non-empty prompt string`, `agent() could not start a child: <error>`, `child agent run failed: <error>`, and its exact `parallel()`, `pipeline()`, `phase()`, option, schema, and JSON-boundary validation messages. Intermediate child outputs are available to the script but not the parent model.
+Through [`dsh-tool-workflow`](../tool-workflow/README.md), success exposes only the materialized final JSON value and child count in that consumer's wrapper. This engine supplies stable errors including `workflow script does not parse: <error>`, `invalid meta: <violations>`, `agent() requires a non-empty prompt string`, `agent() could not start a child: <error>`, and `child agent run failed: <error>`, plus its exact `parallel()`, `pipeline()`, `phase()`, option, schema, and JSON-boundary validation messages. Intermediate child outputs are available to the script but not the parent model.
 
 #### Token effect
 
@@ -117,8 +159,25 @@ Append-only; newly visible content follows the reusable request prefix and does
 
 ## Known Limitations and Deferred Work
 
-- **The worker/vm is not a security boundary** — model-written code can escape `node:vm` and reach the worker's process authority; a hostile-code deployment needs a separate-process or container engine.
+<a id="known-limitations-and-deferred-work"></a>
+
+
+These limits define when the engine is a poor fit or needs special operational care. They are current constraints, not a task backlog.
+
+- **The worker and vm are not a security boundary** — model-written code can escape `node:vm` and reach the worker's process authority; a hostile-code deployment needs a separate-process or container engine.
 - **One worker thread is paid per run** — there is no pool, warm runtime, or cross-run script cache.
-- **No ambient timers, filesystem, or network are injected, but escaped code can still reach Node** — the missing globals are portability API, not containment.
+- **No ambient timers, filesystem, or network are injected, but escaped code can still reach Node** — the missing globals are a portability API, not containment.
 - **Termination can only report host-observed starts** — `agentsStarted` excludes worker-side calls still queued behind concurrency when a forced termination makes them unknowable.
 - **Cross-realm errors fail `instanceof Error` inside scripts** — workflow authors must branch on stable fields such as `name` and `code`.
+
+<a id="dev-note"></a>
+### Dev Note
+
+<details>
+<summary>Working context for maintainers — click to expand</summary>
+
+This Dev Note is working context for maintainers: measured artifacts and directions that are not decided. It is explicitly non-authoritative — shipped behavior, limits, and accepted rationale live in the sections above, the package code, and the linked Agent Notes.
+
+Open directions: a pooled or warm runtime and a cross-run script cache to avoid one worker per run; a genuine process or container engine for untrusted scripts behind the same seam. The built `./worker` entry ships as a CommonJS bundle because pkg's VFS hook expects CommonJS; source mode installs tsx transforms through a data-URL bootstrap.
+
+</details>

package/README.zh.md

@@ -1,111 +1,153 @@
+---
+description: "worker-thread 工作流引擎：在宿主事件循环之外执行由模型编写的编排脚本，供选择或配置执行隔离的用户与维护者阅读。"
+kind: "package-reference"
+---
+
 # @xneog/dsh-workflow-worker-thread
 
 [English](README.md) | 中文
 
-本包为 `WorkflowEngine` 提供实现，每次运行使用一个 Node worker thread。worker 执行编排脚本；子 agent（智能体）留在宿主上，脚本通过带类型的宿主／worker 协议经由 `ctx.subagents` 访问它们。
+## 概述
 
-包根目录默认导出引擎插件及其 `Config`；worker 协议、运行时和会话模块均为实现私有。操作入口 `./worker` 仍是引擎的 spawn 目标。
+`dsh-workflow-worker-thread` 以每次运行一个 Node worker thread 的方式实现工作流引擎：编排脚本在一个全新 worker 内执行，其 `agent()` 调用通过带类型的宿主／worker 协议触达宿主 subagent。同步脚本循环不会阻塞 harness 事件循环，忽略取消的脚本可以连同其 worker 一起终止。这种隔离只是 containment（隔离），不是安全边界——由模型编写的脚本与模型已有的 bash 访问具有相同的信任前提，逃逸 `node:vm` 上下文即可重新取得 worker 的进程权限。挂载本引擎即为 `ctx.workflowEngine` 提供具体实现；与 `dsh-tool-workflow` 一起加载的组合会把 `workflow` 工具交给模型。
 
-这种拆分只有一个主要目的：同步脚本循环不能阻塞 harness 事件循环，忽略取消的脚本可以连同其 worker 一起终止。它不是安全沙箱。
+## 目录
 
-## 信任与隔离边界
+- [使用本包](#use-this-package)
+- [理解实现](#understand-the-implementation)
+- [进一步探索](#further-exploration)
+- [模型体验](#model-experience)
+- [已知限制与延期工作](#known-limitations-and-deferred-work)
+- [开发备注](#dev-note)
 
-工作流脚本由模型编写，信任前提与模型已有的 bash 访问相同。worker 内的 `node:vm` 是塑造 API 的机制，不是安全边界：逃逸的脚本可以用宿主进程权限重新取得 Node 能力。
+-----
 
-worker 仍提供实用的隔离：
+<a id="use-this-package"></a>
+## 使用本包
 
-- 脚本 CPU 工作和同步自旋不会占用宿主事件循环；
-- `worker.terminate()` 为 dispose（资源释放）提供真实的最终停止手段；
-- 除未构建 loader 所需的衔接配置外，worker 以空环境启动，因此环境凭据不会通过 `process.env` 跨越边界；
-- 宿主/worker 消息使用结构化克隆数据，并在脚本边界执行普通 JSON 校验。
+当组合需要工作流能力时挂载本引擎：每个编排脚本都在独立 worker thread 中、宿主事件循环之外运行，已发布组合中的 `workflow` 与 `ralph` 工具都在其上执行。不要把它当作真正不可信脚本的沙箱——恶意代码需要独立进程或容器引擎。
 
-真正的不可信脚本沙箱需要在同一工作流 seam 背后采用不同引擎。
+### 最小配置
 
-## 脚本约定
+加载本引擎即注册 `ctx.workflowEngine`；在其上添加 `dsh-tool-workflow` 会把 `workflow` 工具交给模型。每个配置字段都是可选的：
 
-工作流的 `meta` 是宿主提供的数据，而不是待求值的脚本文本。引擎会校验必需的 `name` 和 `description`、拒绝未知字段，并在返回运行前检查脚本正文能否解析。
+```yaml
+- name: '@xneog/dsh-workflow-worker-thread'
+- name: '@xneog/dsh-tool-workflow'
+```
 
-在 worker 内，脚本会收到 `args` 以及以下钩子：
+| 字段 | 默认值 | 含义 |
+|---|---|---|
+| `provider` | `spawn` | `agent()` 调用使用的宿主侧 subagent 提供方。 |
+| `maxConcurrentAgents` | `0` | 并发 `agent()` 上限；`0` 会根据可用 CPU 并行度解析。 |
+| `maxTotalAgents` | `1000` | 一次运行最多启动的 `agent()` 调用总数——失控循环的后备闸。 |
+| `maxItemsPerCall` | `4096` | 一次 `parallel()` 或 `pipeline()` 调用接受的条目数。 |
+| `syncTimeoutMs` | `5000` | 脚本最初同步片段的 VM 超时时间，单位为毫秒。 |
+| `disposeGraceMs` | `5000` | 强制结算与终止 worker 前的期限；同时约束 `dispose()`。 |
 
-- `agent(prompt, { label, phase, schema, model })` 启动一个宿主侧 subagent。提供 schema 时返回结构化值，否则返回最终文本。普通子 agent 失败会产生 `null`；
-- `parallel(thunks)` 在已配置的并发限制下运行 thunk；
-- `pipeline(items, ...stages)` 在没有跨阶段屏障的情况下传递 `(previous, item, index)`；
-- `phase(title)` 和 `log(message)` 发出观察器叙述。
+负责该引擎的消费方可以为一次运行设置 `WorkflowStartRequest.subagentProvider` 与 `WorkflowStartRequest.maxTotalAgents`——这是引擎级策略，不是脚本钩子；普通 `workflow` 工具两者都不设置，单次运行的子 agent 总数上限可以降低、但绝不能提高已配置的上限。生成的[配置目录](../../../docs/config-catalog.zh.md#xneogdsh-workflow-worker-thread)是每个受支持字段的穷尽式真源。
 
-未知选项、格式错误的参数、不支持的 schema、超出上限、提供方启动失败和基础设施结果失败都属于致命工作流错误。有意不注入 timer、文件系统 API 或 Node 全局变量，但上述信任注意事项仍然适用。
+### 运行会得到什么
 
-## 运行顺序
+运行启动后，脚本正文在 worker 中以顶层 `await` 执行，并可使用钩子 `agent()`、`parallel()`、`pipeline()`、`phase()` 与 `log()`；`meta` 与 `args` 以普通 JSON 数据到达，绝不作为代码求值。每次 `agent()` 调用都会在配置的提供方下启动一个宿主侧 subagent，并以运行的父级作为每个子 agent 的父级。运行以脚本的最终 JSON 值结算；普通子 agent 失败会把 `agent()` 兑现为 `null`，由脚本处理。
 
-`start()` 会校验 meta、解析脚本正文、解析一个已注册且规范化的提供方路由，并解析每次运行的子 agent 总数上限，然后才创建 worker 或发布 `workflow/start`。请求的 `maxTotalAgents` 必须是正安全整数，且不能超过引擎配置的部署上限。源代码模式通过 data URL bootstrap 安装 TypeScript 转换；构建模式把同级 `lib/worker.cjs` 作为文件系统路径传入，因为 pkg 的虚拟文件系统（VFS）钩子要求 CommonJS。两者都能在普通 Node 下运行。ready/go 握手可以避免启动信号取消与 worker 启动发生竞态，导致脚本最初的同步片段被执行。
+格式错误的 meta 块、无法解析的正文、不可用的提供方路由或高于上限的单次运行上限，都会在 worker 存在之前被同步拒绝，调用方因此看到违规清单并可以修正调用。执行期间，钩子误用与超出上限会用致命工作流错误终止脚本。取消是有界的：忽略取消的脚本会在 `disposeGraceMs` 后被强制以 cancelled 结算，其 worker 被终止。
 
-对于每次 `agent()` 调用：
+### 信任预期
 
-1. worker 发送 `child-start`，其中包含普通数据提示词和选项。
-2. 宿主通过异步 `SubagentRuntime.start` 调用启动请求中指定的提供方，否则调用已配置的提供方；调用会传入工作流父级和该次运行共用的唯一中止信号。提供方选择应用于该次运行的每个子 agent，对脚本不可见。
-3. 如果启动被拒绝，宿主会发送 `child-start-error`；提供方启动已经完全停稳，不会发出子 agent 生命周期事件。
-4. 如果启动兑现时工作流仍接纳工作，宿主会记录该运行、观察 `result`，然后发送 `child-started`。即使结果已经结算，也只会随后转发，以保持先启动、后结果的顺序。
-5. worker 发出成对的 `workflow/agent-start` 和 `workflow/agent-end` 叙述，并在收集后请求 dispose 子 agent。
+脚本的 CPU 工作与同步自旋不会占用宿主事件循环，`worker.terminate()` 为 dispose（资源释放）提供真实的最终停止手段，worker 以清理后的环境启动——只注入平台临时路径以及（源码模式下）`TSX_TSCONFIG_PATH`——因此环境凭据不会通过 `process.env` 跨越边界。宿主／worker 消息使用结构化克隆数据，并在脚本边界执行普通 JSON 校验。
 
-提供方启动与已发布子 agent 分开跟踪。如果启动仍在等待，而取消、worker 死亡或正常工作流结算关闭了接纳，共享信号会中止该启动。即便提供方随后兑现，宿主也会 dispose 它，且绝不向 worker 通知。
+以上都不是安全边界：有意不注入 timer、文件系统 API 或 Node 全局变量，但逃逸代码仍可以 worker 的进程权限触达 Node。
 
-## 值边界
+-----
 
-离开脚本的值会经过 `materializeFromRealm`；该函数接受普通的无损 JSON 数据，并拒绝特殊原型、函数、symbol、循环、稀疏数组、非有限数和嵌套 `undefined`。遍历在 worker 内执行，并把对象键定义为数据属性，使 `__proto__` 无法改变原型。
+<a id="understand-the-implementation"></a>
+## 理解实现
 
-子 agent 结果从宿主跨越到 worker 之前，会先投影并制作快照。这是真正近似进程的序列化边界；它有意不同于可信的同进程工作流和 subagent 事件 payload，后者以不可变方式借用值。
+<details>
+<summary>实现细节——点击展开</summary>
 
-## 取消与 dispose
+本节解释引擎的隔离设计与运行机制；可观察行为已在[使用本包](#use-this-package)中完整说明。
 
-`WorkflowRun.cancel()` 会记录第一个原因、通知 worker 取消、中止每个待处理及已发布子 agent 共享的唯一信号，并启动 `disposeGraceMs` 定时器。worker 钩子会在下次 await 时抛出 `CANCELLED`。如果运行到期限仍未结算，宿主会将其以已取消状态兑现、为悬空的子 agent 生命周期事件配对，并终止 worker。
+### 设计理念
 
-subagent seam 只有一个取消通道：请求信号。不存在单独的子 agent 取消 RPC。已发布子 agent 使用 `run.dispose()` 清理；待处理的提供方启动在其 promise 拒绝或兑现前仍由提供方负责。
+每次运行一个 worker thread，让行为异常的脚本无法拖垮宿主，并使强制终止成为可能：脚本在 worker 内可逃逸的 `node:vm` 上下文中运行，`agent()` 调用通过带类型的宿主／worker 协议回到 `ctx.subagents`。vm 上下文塑造脚本的 API 表面；它不是安全沙箱。
 
-正常结算也会中止待处理启动，并在结果对外结算前开始 dispose 所有已发布但无需等待的子 agent。宿主的完全停稳条件同时包括待处理启动和已发布子 agent 的 dispose，因此清理不会遗漏异步启动事务。
+### 源码地图
 
-`dispose()` 是幂等的。它会取消运行、立即启动宿主驱动的 dispose、在同一宽限时间内等待结果和子 agent 完全停稳、无条件终止 worker，并执行最后一次幸存项扫描。每个子 agent 的 dispose 都会记忆化，使 worker RPC、宿主取消、死亡清理和公开 dispose 都汇入同一操作。
+| 文件 | 职责 |
+|---|---|
+| [`src/index.ts`](src/index.ts) | 插件入口：`Config` schema、前置校验、`start()` 接线 |
+| [`src/host.ts`](src/host.ts) | 一次运行的宿主侧：worker 启动、子 agent 编排、结算、dispose |
+| [`src/worker.ts`](src/worker.ts) | worker 入口：脚本执行、钩子实现、值物化 |
+| [`src/runtime.ts`](src/runtime.ts) | 脚本运行时：钩子契约、`parallel()` 与 `pipeline()` 组合器 |
+| [`src/realm.ts`](src/realm.ts) | 跨 realm 物化：普通 JSON 的接受与拒绝规则 |
+| [`src/protocol.ts`](src/protocol.ts) | 带类型的宿主／worker 消息协议 |
+| [`src/meta.ts`](src/meta.ts) | `meta` 形状校验与规范化 |
+| [`src/session.ts`](src/session.ts) | 子 agent 运行在跨入 worker 前的投影与快照 |
+| — | 不发布运行时不变式伴生入口；worker 测试覆盖该边界。 |
 
-## 结果与事件保证
+### 运行顺序
 
-在宿主的结果确认点，终态结果遵循先到者胜。已接受的外部取消会覆盖后到的非取消 worker 结果；先完成确认的结果或 worker 死亡不能被可重入清理回调改写。
+`start()` 在创建 worker 或发布 `workflow/start` 之前校验 meta 块、解析正文、解析提供方路由并解析单次运行的子 agent 总数上限。ready/go 握手可以避免启动信号取消与 worker 启动发生竞态、导致脚本最初的同步片段被执行；源代码模式通过 data URL bootstrap 安装 TypeScript 转换，构建模式则传入同级 `lib/worker.cjs` 包。
 
-worker 错误、消息失败或提前退出会在清理前关闭消息接纳，然后以 `error` 兑现；如果取消已经接管该运行，则不覆盖取消。后到的排队消息无法在该逻辑边界后创建子 agent 或发出叙述。
+每次 `agent()` 调用，worker 都会发送 `child-start`；宿主通过 subagent seam 启动提供方（请求的覆盖值，或配置的提供方），把子 agent 归属于运行的父级，并回报启动成功或启动错误。提供方选择应用于该运行的每个子 agent，对脚本不可见。提供方启动与已发布子 agent 分开跟踪，因此当取消、worker 死亡或正常结算关闭接纳时，待处理启动会被共享信号中止。
 
-宿主会维护已转发子 agent 启动的台账。优雅退出的 worker 会提供对应的结束事件；死亡或强制终止会把缺失的结束事件合成为已取消。因此，每个已转发的 `workflow/agent-start` 都会且只会配对一次，不过已经到达的工作流结果之后的清理可能稍后才完成。
+### 值边界
 
-## 配置
+离开脚本的值会经过 realm 物化；该过程接受普通无损 JSON 数据，拒绝特殊原型、函数、symbol、循环、稀疏数组、非有限数与嵌套 `undefined`。子 agent 结果在从宿主跨入 worker 之前先投影并快照——这是真正近似进程的序列化边界，刻意区别于同进程工作流事件以不可变方式借用的值。
 
-| 键 | 默认值 | 含义 |
-|---|---|---|
-| `provider` | `spawn` | `agent()` 使用的宿主侧 subagent 提供方。 |
-| `maxConcurrentAgents` | `0` | 并发 `agent()` 上限；`0` 会根据可用 CPU 并行度解析。 |
-| `maxTotalAgents` | `1000` | 一次运行中的 `agent()` 调用总数。 |
-| `maxItemsPerCall` | `4096` | 一次 `parallel()` 或 `pipeline()` 调用接受的条目数。 |
-| `syncTimeoutMs` | `5000` | 脚本最初同步片段的 VM 超时时间。 |
-| `disposeGraceMs` | `5000` | 强制结算/终止之前的期限，也是公开 dispose 的期限。 |
+### 取消与 dispose
+
+`cancel()` 记录第一个原因、通知 worker 取消、中止所有待处理与已发布子 agent 共享的唯一信号，并启动 `disposeGraceMs` 定时器；worker 钩子随后在下次 await 时抛出 `CANCELLED`。如果运行到期限仍未结算，宿主会将其以 cancelled 兑现、为悬空的子 agent 生命周期事件配对，并终止 worker。
+
+`dispose()` 是幂等的：它取消运行、立即启动宿主驱动的 dispose、在同一宽限期内等待结果与子 agent 完全停稳、无条件终止 worker，并执行最后一次幸存项扫描。每个子 agent 的 dispose 都会记忆化，使 worker RPC、宿主取消、死亡清理与公开 dispose 都汇入同一操作。
+
+### 结果与事件保证
+
+在宿主的认领点，终态结果遵循先到者胜：已接受的外部取消会覆盖后到的非取消 worker 结果，先认领的结果或 worker 死亡不能被可重入清理回调改写。worker 错误、消息失败或提前退出会在清理前关闭消息接纳，然后以 `error` 兑现；除非取消已接管该运行。
+
+宿主维护已转发子 agent 启动的台账；优雅退出的 worker 提供对应的结束事件，死亡或强制终止则把缺失的结束事件合成为已取消——每个已转发的 `workflow/agent-start` 都会且只会配对一次。
+
+</details>
 
-负责该引擎的消费方可以为一次运行设置 `WorkflowStartRequest.subagentProvider` 和 `WorkflowStartRequest.maxTotalAgents`。它们属于引擎级策略，不是脚本钩子或面向模型的选项；普通 `workflow` 工具不会设置两者。每次运行的子 agent 总数上限可以降低、但绝不能提高已配置的 `maxTotalAgents` 上限。
+-----
 
+<a id="further-exploration"></a>
+## 进一步探索
+
+当引擎级契约不够用时阅读以下页面。它们从 seam 契约逐步进入面向模型的消费方与设计决策。
+
+- [工作流子系统](../../../docs/subsystems/workflow.zh.md)——本引擎实现的 seam 契约。
+- [工作流 seam](../workflow/README.zh.md)——`ctx.workflowEngine` 背后的运行与结果词汇。
+- [workflow 工具](../tool-workflow/README.zh.md)——在本引擎上运行脚本的模型侧消费方。
+- [组地图](../README.zh.md)——工作流能力家族及其包。
+- [动态工作流 Agent Note](../../../.agents/notes/implemented/feature/2026-07-05-dynamic-workflows.zh.md)——seam 设计及其决策。
+
+-----
+
+<a id="model-experience"></a>
 ## 模型体验
 
 ### 子 agent 请求
 
-#### 模型看到的内容
+#### 模型看到什么
 
-脚本每次调用 `agent()`，都会把提示词原样发送给 subagent 提供方，并附带可选模型或结构化输出 schema。每个子 agent 看到该提供方自己的上下文；phase 和 log 叙述只留在观察器事件中。
+脚本每次调用 `agent()`，都会把提示词原样发送给 subagent 提供方，并附带可选模型或结构化输出 schema。每个子 agent 看到该提供方自己的上下文；phase 与 log 叙述只留在观察器事件中。
 
 #### Token 影响
 
-可能需要为许多独立子 agent 上下文支付 token 成本，数量受 `maxConcurrentAgents`、`maxTotalAgents` 和 `maxItemsPerCall` 限制；这些上下文绝不会直接加入父级历史。
+可能需要为许多独立子 agent 上下文支付 token，数量受 `maxConcurrentAgents`、`maxTotalAgents` 与 `maxItemsPerCall` 限制；这些上下文绝不会直接加入父级历史。
 
 #### KV Cache 影响
 
-与父级请求缓存和同级子 agent 缓存相互独立。每个子 agent 只能在其自身提供方、模型、提示词和 schema 下复用逐字节相同的前缀；其后续历史仅追加增长。
+与父级请求缓存及同级子 agent 相互独立。每个子 agent 只能在其自身提供方、模型、提示词与 schema 下复用逐字节相同的前缀；其后续历史仅追加增长。
 
 ### 父级工具结果（间接）
 
-#### 模型看到的内容
+#### 模型看到什么
 
-通过 [`dsh-tool-workflow`](../tool-workflow/README.md)，成功结果只会在该消费方的包装层中公开实体化的最终 JSON 值和子 agent 数量。本引擎提供稳定错误，包括 `workflow script does not parse: <error>`、`invalid meta: <violations>`、`agent() requires a non-empty prompt string`、`agent() could not start a child: <error>`、`child agent run failed: <error>`，以及其精确的 `parallel()`、`pipeline()`、`phase()`、选项、schema 和 JSON 边界校验消息。中间子 agent 输出可供脚本使用，但不提供给父模型。
+通过 [`dsh-tool-workflow`](../tool-workflow/README.zh.md)，成功结果只会在该消费方的包装层中公开实体化的最终 JSON 值与子 agent 数量。本引擎提供稳定错误，包括 `workflow script does not parse: <error>`、`invalid meta: <violations>`、`agent() requires a non-empty prompt string`、`agent() could not start a child: <error>` 与 `child agent run failed: <error>`，以及其精确的 `parallel()`、`pipeline()`、`phase()`、选项、schema 与 JSON 边界校验消息。中间子 agent 输出可供脚本使用，但不提供给父模型。
 
 #### Token 影响
 
@@ -115,10 +157,27 @@ worker 错误、消息失败或提前退出会在清理前关闭消息接纳，
 
 仅追加；新增可见内容位于可复用请求前缀之后，不会使现有 KV Cache 条目失效。
 
-## 已知限制与暂缓事项
+## 已知限制与延期工作
+
+<a id="known-limitations-and-deferred-work"></a>
+
+
+这些限制说明本引擎何时不合适，或何时需要特别的运维注意。它们是当前约束，不是任务积压。
+
+- **worker 与 vm 不是安全边界**——模型编写的代码可以逃逸 `node:vm` 并取得 worker 的进程权限；不可信代码部署需要独立进程或容器引擎。
+- **每次运行都要支付一个 worker thread**——没有池、预热运行时或跨运行脚本缓存。
+- **不注入默认可用的定时器、文件系统或网络，但逃逸代码仍可触达 Node**——缺失的全局变量属于可移植性 API，而非隔离措施。
+- **终止只能报告宿主观察到的启动**——`agentsStarted` 不包括因并发限制仍在 worker 侧排队、且在强制终止后无法得知的调用。
+- **跨 realm 错误在脚本内无法通过 `instanceof Error`**——工作流作者必须根据 `name` 与 `code` 等稳定字段分支。
+
+<a id="dev-note"></a>
+### 开发备注
+
+<details>
+<summary>维护者的工作上下文——点击展开</summary>
+
+本开发备注是维护者的工作上下文：实测产物与尚未决定的探索方向。它明确不具权威性——已交付的行为、限制与既定理由以上文、包代码与相关 Agent Note 为准。
+
+开放方向：用池化或预热运行时与跨运行脚本缓存来避免每次运行一个 worker；在同一 seam 背后为不可信脚本提供真正的进程或容器引擎。构建产物 `./worker` 入口以 CommonJS 包形式发布，因为 pkg 的虚拟文件系统（VFS）钩子要求 CommonJS；源代码模式通过 data URL bootstrap 安装 tsx 转换。
 
-- **worker/vm 不是安全边界**：模型编写的代码可以逃逸 `node:vm` 并取得 worker 的进程权限；不可信代码部署需要独立进程或容器引擎。
-- **每次运行都要支付一个 worker thread 的成本**：没有池、预热运行时或跨运行脚本缓存。
-- **不注入默认可用的定时器、文件系统或网络，但逃逸代码仍可访问 Node**：这些缺失的全局变量属于可移植性 API 设计，而非隔离措施。
-- **终止只能报告宿主观察到的启动**：`agentsStarted` 不包括因并发限制仍在 worker 侧排队、且在强制终止后无法得知的调用。
-- **跨 realm 错误在脚本内无法通过 `instanceof Error`**：工作流作者必须根据 `name` 和 `code` 等稳定字段分支。
+</details>

package/lib/index.js

@@ -5,8 +5,7 @@ import z from "@xneog/schemastery";
 import WorkflowEngine, { WorkflowError, WorkflowRunId } from "@xneog/dsh-workflow";
 import { Worker } from "node:worker_threads";
 import { fileURLToPath } from "node:url";
-import { assertNever } from "@xneog/dsh-llm";
-import { snapshotJsonValue } from "@xneog/dsh-session";
+import { assertNever, snapshotJsonValue } from "@xneog/dsh-util-values";
 //#region lib/types/realm.js
 /**
 * Materializes values leaving the script vm into plain JSON before they cross the worker
@@ -187,7 +186,11 @@ var HostToWorkerType;
 * @module @xneog/dsh-workflow-worker-thread/host
 */
 /**
-* The scrubbed worker environment: no ambient credentials, no loader flags.
+* The scrubbed worker environment: no ambient credentials, no loader flags, and deliberately no
+* proxy policy. A worker thread does not inherit the host's global dispatcher, so a workflow's own
+* requests go direct — the alternative is handing the worker a proxy URL that may carry
+* `user:password`, and this worker executes the model-authored script body. That is the same
+* containment the code runtime keeps, and `docs/defensive-patterns.md` requires it.
 * Windows derives `os.tmpdir()` from `TMP`/`TEMP` and falls back to the
 * literal relative path `undefined\temp` when the environment is empty, so
 * tsx's transform cache would land in a cwd-relative `undefined/temp`

package/lib/types/host.d.ts

@@ -12,7 +12,11 @@ import type { WorkflowMeta, WorkflowResult, WorkflowRun, WorkflowRunId } from '@
 import type { ExecutionObserver } from './runtime.ts';
 import type { WorkerInit } from './types.ts';
 /**
- * The scrubbed worker environment: no ambient credentials, no loader flags.
+ * The scrubbed worker environment: no ambient credentials, no loader flags, and deliberately no
+ * proxy policy. A worker thread does not inherit the host's global dispatcher, so a workflow's own
+ * requests go direct — the alternative is handing the worker a proxy URL that may carry
+ * `user:password`, and this worker executes the model-authored script body. That is the same
+ * containment the code runtime keeps, and `docs/defensive-patterns.md` requires it.
  * Windows derives `os.tmpdir()` from `TMP`/`TEMP` and falls back to the
  * literal relative path `undefined\temp` when the environment is empty, so
  * tsx's transform cache would land in a cwd-relative `undefined/temp`

package/lib/worker.cjs

@@ -21,10 +21,10 @@ var __toESM = (mod, isNodeMode, target) => (target = mod != null ? __create(__ge
 }) : target, mod));
 //#endregion
 let node_worker_threads = require("node:worker_threads");
-let _xneog_dsh_llm = require("@xneog/dsh-llm");
+let _xneog_dsh_util_values = require("@xneog/dsh-util-values");
 let node_vm = require("node:vm");
 node_vm = __toESM(node_vm, 1);
-let _xneog_dsh_session = require("@xneog/dsh-session");
+let _xneog_dsh_brand = require("@xneog/dsh-brand");
 let _xneog_dsh_tools = require("@xneog/dsh-tools");
 let _xneog_dsh_workflow = require("@xneog/dsh-workflow");
 //#region lib/types/protocol.js
@@ -433,7 +433,7 @@ var WorkflowExecution = class {
 				seq,
 				label,
 				...phase !== void 0 ? { phase } : {},
-				childId: (0, _xneog_dsh_session.SessionId)(run.id)
+				childId: (0, _xneog_dsh_brand.brandString)(run.id)
 			};
 			this.observer.agentStart(info);
 			try {
@@ -763,7 +763,7 @@ async function runWorkerSession(port, init) {
 				children.onChildDisposed(message.callId);
 				break;
 			/* v8 ignore next 2 -- closed engine-owned union; the arm only makes adding a message type a compile error */
-			default: (0, _xneog_dsh_llm.assertNever)(message, "host-to-worker message");
+			default: (0, _xneog_dsh_util_values.assertNever)(message, "host-to-worker message");
 		}
 	});
 	post(WorkerToHostType.Ready, {});

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@xneog/dsh-workflow-worker-thread",
   "description": "worker-thread workflow engine: executes model-written orchestration scripts off the host event loop, bridging agent() calls back to ctx.subagents",
-  "version": "0.1.0",
+  "version": "0.1.3-alpha.1",
   "publishConfig": {
     "access": "public"
   },
@@ -18,10 +18,6 @@
       "types": "./lib/types/index.d.ts",
       "default": "./lib/index.js"
     },
-    "./invariant": {
-      "types": "./lib/types/invariant.d.ts",
-      "default": "./lib/invariant.js"
-    },
     "./worker": {
       "types": "./lib/types/worker.d.ts",
       "default": "./lib/worker.cjs"
@@ -31,39 +27,39 @@
   },
   "files": [
     "lib/index.js",
-    "lib/invariant.js",
     "lib/worker.cjs",
     "lib/types/**/*.d.ts"
   ],
   "license": "MIT",
   "peerDependencies": {
-    "@xneog/dsh-agent": "0.1.0",
-    "@xneog/dsh-brand": "0.1.0",
-    "@xneog/dsh-invariants": "0.1.0",
-    "@xneog/dsh-llm": "0.1.0",
-    "@xneog/dsh-session": "0.1.0",
-    "@xneog/dsh-subagent": "0.1.0",
-    "@xneog/dsh-tools": "0.1.0",
-    "@xneog/dsh-workflow": "0.1.0",
-    "@xneog/cordis": "0.1.0"
+    "@xneog/cordis": "^4.0.2",
+    "@xneog/dsh-agent": "^0.1.3-alpha.1",
+    "@xneog/dsh-llm": "^0.1.3-alpha.1",
+    "@xneog/dsh-subagent": "^0.1.3-alpha.1",
+    "@xneog/dsh-workflow": "^0.1.3-alpha.1",
+    "@xneog/dsh-tools": "^0.1.3-alpha.1",
+    "@xneog/dsh-session": "^0.1.3-alpha.1"
   },
   "dependencies": {
-    "@xneog/schemastery": "0.1.0"
+    "@xneog/dsh-brand": "^0.1.3-alpha.1",
+    "@xneog/dsh-util-values": "^0.1.3-alpha.1",
+    "@xneog/schemastery": "^3.18.2"
   },
   "devDependencies": {
-    "@xneog/dsh-agent": "0.1.0",
-    "@xneog/dsh-agent-loop": "0.1.0",
-    "@xneog/dsh-agent-loop-testkit": "0.1.0",
-    "@xneog/dsh-brand": "0.1.0",
-    "@xneog/dsh-invariants": "0.1.0",
-    "@xneog/dsh-llm": "0.1.0",
-    "@xneog/dsh-session": "0.1.0",
-    "@xneog/dsh-subagent": "0.1.0",
-    "@xneog/dsh-subagent-spawn-in-process": "0.1.0",
-    "@xneog/dsh-system-prompt": "0.1.0",
-    "@xneog/dsh-tools": "0.1.0",
-    "@xneog/dsh-workflow": "0.1.0",
-    "@xneog/cordis": "0.1.0",
-    "tsx": "^4.19.2"
+    "tsx": "^4.19.2",
+    "@xneog/cordis": "^4.0.2",
+    "@xneog/dsh-agent": "^0.1.3-alpha.1",
+    "@xneog/dsh-agent-loop-testkit": "^0.1.3-alpha.1",
+    "@xneog/dsh-llm": "^0.1.3-alpha.1",
+    "@xneog/dsh-session": "^0.1.3-alpha.1",
+    "@xneog/dsh-subagent": "^0.1.3-alpha.1",
+    "@xneog/dsh-subagent-spawn-in-process": "^0.1.3-alpha.1",
+    "@xneog/dsh-session-projection": "^0.1.3-alpha.1",
+    "@xneog/dsh-agent-loop": "^0.1.3-alpha.1",
+    "@xneog/dsh-invariants": "^0.1.3-alpha.1",
+    "@xneog/dsh-system-prompt": "^0.1.3-alpha.1",
+    "@xneog/dsh-tools": "^0.1.3-alpha.1",
+    "@xneog/dsh-workflow": "^0.1.3-alpha.1",
+    "@xneog/dsh-http-proxy": "^0.1.3-alpha.1"
   }
 }

package/lib/invariant.js

@@ -1,23 +0,0 @@
-//#region lib/types/invariant.js
-/**
-* Package-owned invariant companion for `@xneog/dsh-workflow-worker-thread`.
-* @module @xneog/dsh-workflow-worker-thread/invariant
-*/
-const PACKAGE_NAME = "@xneog/dsh-workflow-worker-thread";
-/** Cordis companion plugin name. */
-const name = "workflow-worker-thread-invariant";
-/** Service required before the companion can reserve package ownership. */
-const inject = ["invariants"];
-/**
-* No runtime invariant: this process-boundary implementation exposes no same-process event relation;
-* worker protocol and built-worker tests cover it.
-*/
-const install = () => {};
-/**
-* Register this package's invariant companion.
-* @param ctx - Cordis context carrying the invariant service.
-* @returns the installed registration's disposer after setup succeeds.
-*/
-const apply = (ctx) => Promise.resolve(ctx.invariants.register(PACKAGE_NAME, install));
-//#endregion
-export { apply, inject, name };

package/lib/types/invariant.d.ts

@@ -1,16 +0,0 @@
-/**
- * Package-owned invariant companion for `@xneog/dsh-workflow-worker-thread`.
- * @module @xneog/dsh-workflow-worker-thread/invariant
- */
-import type { Context } from '@xneog/cordis';
-/** Cordis companion plugin name. */
-export declare const name = "workflow-worker-thread-invariant";
-/** Service required before the companion can reserve package ownership. */
-export declare const inject: string[];
-/**
- * Register this package's invariant companion.
- * @param ctx - Cordis context carrying the invariant service.
- * @returns the installed registration's disposer after setup succeeds.
- */
-export declare const apply: (ctx: Context) => Promise<() => void>;
-//# sourceMappingURL=invariant.d.ts.map