@bastani/atomic 0.9.43 → 0.9.44-alpha.2

package/dist/builtin/subagents/skills/herdr/SKILL.md

@@ -54,9 +54,9 @@ Choose the primitive that matches the job:
 
 A pane exists whether or not it contains an agent. `agent start` requires an existing available shell pane and never creates, splits, or moves layout. Use pane commands for ordinary processes. Use agent commands when Herdr must validate agent identity or interpret `idle`, `working`, `blocked`, `done`, and `unknown` lifecycle states.
 
-Agent commands accept either a unique live agent name or the pane ID currently hosting that agent. They do not accept terminal IDs or bare agent-kind labels. Names must match `[a-z][a-z0-9_-]{0,31}` and be unique among live agents. A name follows the current pane occupant and is cleared when that agent exits, is released, or is replaced.
+Agent commands accept either a unique live agent name or the pane ID currently hosting that agent. They do not accept terminal IDs or bare agent-kind labels. Names must match `[a-z][a-z0-9_-]{0,31}` and be unique among live agents. A name follows the current pane occupant and is cleared when that agent exits, is released, or is replaced. Suspending an agent with Ctrl+Z and running a non-agent command preserves its identity while the exact process remains alive. This does not preserve the original identity across another recognized agent taking over. A retained identity does not mean the agent is in the foreground; inspect the pane before sending input.
 
-`idle` and `done` both mean the agent is ready for input. The CLI/API uses the server's seen state to distinguish them; explicit focus commands mark the target seen, while reads do not. Each TUI client tracks viewed completions independently, so its Done badge can differ from the CLI or another client's badge. `blocked` means Herdr recognized an approval or question UI. `unknown` means an agent is present but Herdr cannot classify it confidently; it does not prove completion.
+`idle` and `done` normally indicate the agent is ready for input; neither guarantees that an unfamiliar approval dialog was recognized or that a retained agent is in the foreground. The CLI/API uses the server's seen state to distinguish them; explicit focus commands mark the target seen, while reads do not. Each TUI client tracks viewed completions independently, so its Done badge can differ from the CLI or another client's badge. Antigravity and Grok can be idle while background tasks or subagents keep running, so a settled-state wait is not proof those jobs have finished. `blocked` means Herdr recognized an approval or question UI. `unknown` means an agent is present but Herdr cannot classify it confidently; it does not prove completion.
 
 ## Use IDs and caller context
 
@@ -74,7 +74,7 @@ Herdr injects the caller's context into each managed pane:
 printf '%s\n' "$HERDR_WORKSPACE_ID" "$HERDR_TAB_ID" "$HERDR_PANE_ID"
 ```
 
-Prefer `--current` when a pane command should target the calling pane. Omitting a target may use the UI-focused pane, which can belong to the user or another client.
+Prefer `--current` when a pane command should target the calling pane. An omitted `pane split` target uses the calling pane when `HERDR_PANE_ID` is available, otherwise the focused pane. Other commands may use the UI-focused pane, which can belong to the user or another client.
 
 Discover live state with:
 
@@ -88,9 +88,21 @@ herdr agent list
 
 Creation responses expose the IDs to use next. `workspace create` returns `.result.workspace`, `.result.tab`, and `.result.root_pane`. `tab create` returns `.result.tab` and `.result.root_pane`. `pane split` returns the new pane as `.result.pane`.
 
-IDs and live agent names are scoped to one server. Two saved SSH machines can both have `w1:p1` or an agent named `reviewer`. Selecting a machine in the TUI does not retarget commands running in your pane: they still use the inherited session and socket context. Run remote control commands on the intended host with its explicit session, and rediscover IDs there.
+IDs and live agent names are scoped to one server. Two saved SSH machines can both have `w1:p1` or an agent named `reviewer`. Selecting a machine in the TUI does not retarget commands running in your pane: without `--machine`, they still use the inherited session and socket context.
 
-`herdr machine list` lists saved connection profiles, not a cross-machine pane inventory; add `--json` for scripts. Only add, remove, enable, or disable profiles when the user asks. Removing a profile disconnects the client but does not stop remote sessions. Adding a machine uses the remote default session unless `--remote-session` is explicitly supplied. Setup asks before stopping an incompatible server and defaults to No; do not approve replacement without the user's consent. Experimental handoff is not part of `machine add`.
+To control a saved SSH machine, use the same global prefix for discovery and every later command:
+
+```bash
+herdr --machine <label-or-id> agent list
+herdr --machine <label-or-id> pane list
+herdr --machine <label-or-id> agent prompt <remote-agent-name> "Reply with your current status." --wait --timeout 120000
+```
+
+The selector must be an enabled saved profile ID or a unique, case-sensitive label, not an arbitrary SSH hostname. Commands use that profile's remote session without an open TUI. Do not combine `--machine` with `--session` or `--remote`. Discover IDs on that machine; inherited local IDs and `--current` do not identify remote panes.
+
+Both installations must support machine API forwarding, and the remote server must already be running and API-compatible. Forwarding never installs, starts, or restarts a server and never falls back to Local. Local configuration, session management, installation commands, and interactive attachment are not forwarded. Remote worktree paths must be absolute, `~`, or start with `~/`; plugin link paths must be absolute. A connection failure does not prove a mutation was not applied: inspect remote state before retrying.
+
+`herdr machine list` lists saved connection profiles, not a cross-machine pane inventory; add `--json` for scripts. Only add, remove, enable, or disable profiles when the user asks. Removing a profile disconnects the client but does not stop remote sessions. Interactive `machine add` discovers running remote sessions and may ask the user to pick one; non-interactive setup uses the remote default session unless `--remote-session` is explicitly supplied. Use `herdr machine status [<label-or-id>] --json` to diagnose a failing machine. `herdr machine reconnect` needs the user to complete SSH authentication in their terminal; do not run it for them. Setup asks before stopping an incompatible server and defaults to No; do not approve replacement without the user's consent. Experimental handoff is not part of `machine add`.
 
 ## Start and coordinate an agent
 
@@ -130,7 +142,7 @@ Submit work through the agent surface:
 herdr agent prompt reviewer "Review the current diff and report only actionable findings." --wait --timeout 120000
 ```
 
-`agent prompt` honors the pane's live bracketed-paste mode and sends text followed by encoded Enter as one ordered submission. It reports successful submission only after both have been written; that alone does not prove the agent started a turn. The submit delay grows with prompt size for Codex on Windows. It rejects an agent already waiting at an approval or question dialog with `agent_blocked` before sending any input. Inspect the blocked UI and ask the user before answering it. For normal agent work, `--wait` is enough: it waits for the first settled `idle`, `done`, or `blocked` state. Do not repeat those defaults with `--until`.
+`agent prompt` honors the pane's live bracketed-paste mode and sends text followed by encoded Enter as one ordered submission. It reports successful submission only after both have been written; that alone does not prove the agent started a turn. For Codex on Windows, Herdr sends a paste boundary before Enter so submission does not depend on prompt size. It rejects an agent already waiting at an approval or question dialog with `agent_blocked` before sending any input. Inspect the blocked UI and ask the user before answering it. For normal agent work, `--wait` is enough: it waits for the first settled `idle`, `done`, or `blocked` state. Do not repeat those defaults with `--until`.
 
 With `--wait`, a prompt sent from a non-working state must produce observed `working` or `blocked` activity. After submission, Herdr waits up to five seconds for that activity; unrelated `idle`, `done`, or session changes do not satisfy this gate. It returns `agent_prompt_stalled` if no activity is observed, or `timeout` if the caller's timeout expires first. The caller timeout includes submission time. Without a timeout, the settled-state wait is indefinite after activity is observed. This wait tracks lifecycle state, not an individual turn; if the agent is already working, completion of the active turn may satisfy it.
 
@@ -174,7 +186,7 @@ herdr pane wait-output <returned-pane-id> --match "test result" --timeout 120000
 herdr pane read <returned-pane-id> --source recent-unwrapped --lines 120
 ```
 
-`pane run` atomically sends command text and Enter. `pane wait-output` searches the selected snapshot immediately, so output that already exists can match. Use `--match <text>` for a literal substring or `--regex <pattern>` for a Rust regular expression. Omitting `--timeout` allows an indefinite wait.
+`pane run` queues command text and Enter together; success acknowledges admission, not command execution. On macOS, `pane run` and `agent start` reject a command that exceeds the terminal's current canonical line-input limit before queuing it. Wait for the interactive shell prompt before retrying. The check covers this submission, not an earlier incomplete line or a later terminal-mode change. `pane wait-output` searches the selected snapshot immediately, so output that already exists can match. Use `--match <text>` for a literal substring or `--regex <pattern>` for a Rust regular expression. Omitting `--timeout` allows an indefinite wait.
 
 Use the read source that matches the task:
 
@@ -185,16 +197,16 @@ Use the read source that matches the task:
 
 Use `--format ansi` when colors and terminal styling are evidence. Otherwise use text.
 
-`--lines` asks Herdr for more rows from the pane's available screen and host scrollback. If increasing it does not reveal more of a completed response, the pane is probably running the agent on the terminal's alternate screen. Rows that leave the alternate screen do not enter Herdr's host scrollback, so a larger line count cannot recover them.
+`--lines` asks Herdr for more rows from the pane's available screen and host scrollback. Alternate-screen rows do not enter ordinary host scrollback. For supported idle agents, Herdr can collect application-owned history and restore the viewport afterward, but not every application or response can be recovered this way.
 
-After that failed read, ask the agent to write its complete response as Markdown in a temporary directory and reply only with the file path, then read the file directly. Use this only as a fallback; do not request file output in the initial prompt.
+If a larger recent read still does not reveal the completed response, ask the agent to write it as Markdown in a temporary directory and reply only with the file path, then read that file on the same machine. Use this only as a fallback; do not request file output in the initial prompt.
 
 ## Safety and coordination rules
 
 - Use `--no-focus` for background work unless the user asked to switch context.
 - Use `--current`, an explicit pane ID, or a unique agent name. Do not rely on another client's focused pane.
 - Parse IDs from JSON responses. Do not derive them from sidebar order or examples.
-- Do not close workspaces, tabs, panes, or sessions you did not create unless the user explicitly asked. `workspace close --group` closes the primary workspace and its linked worktree workspaces; never add it merely to bypass `workspace_group_close_required`.
+- Do not close workspaces, tabs, panes, or sessions you did not create unless the user explicitly asked. Ordinary CLI/API closes do not inherit the TUI's last-pane confirmation. `workspace close --group` closes the primary workspace and its linked worktree workspaces; never add it merely to bypass `workspace_group_close_required`.
 - Use `--trust-repository` only after the user has verified the repository. It grants per-request Git trust; it is not a routine retry for a failed worktree command.
 - Client and server versions can differ after an update. Check `herdr status` before relying on new server features. A missing method is not permission to stop or upgrade a server.
 - Never run `herdr server stop` from an active session unless the user explicitly intends to stop the server and its pane processes.

package/dist/builtin/subagents/skills/subagent/SKILL.md

@@ -317,14 +317,15 @@ For supervisor requests, prefer `contact_supervisor`; use generic `intercom` tow
 
 ### Peer coordination
 
-Coordination is not only vertical. Children launched in the same parallel set, or in the same explicit `group`, share one Intercom group, and workflow stages share their invocation group. Any of them can run `intercom({ action: "list" })`, see live siblings, and `send` or `ask` them directly. `contact_supervisor` is reserved for the supervisor; everything peer-to-peer goes through ordinary `intercom`.
+Default to peer-to-peer (swarm) coordination. There are no limits on communication between agents; it is encouraged whenever you need to. The supervisor is not a message relay: relaying adds latency, loses detail, and bloats the supervisor's context, while direct exchange converges faster. Children launched in the same parallel set, or in the same explicit `group`, share one Intercom group, and workflow stages share their invocation group. Any of them can run `intercom({ action: "list" })`, see live siblings, and `send` or `ask` them directly. `contact_supervisor` is reserved for the supervisor; everything peer-to-peer goes through ordinary `intercom`.
 
-Use peer messaging when a sibling is the better source than the supervisor:
+Use peer messaging whenever a sibling is the better source than the supervisor:
 
 - **Debate**: a reviewer challenges another reviewer's blocking finding with concrete evidence; each still returns its own verdict (see the constructive-quorum pattern in `/skill:intercom`).
 - **Connect**: a locator hands file paths and line ranges straight to the analyzer working the same question instead of round-tripping through the parent.
 - **Learn**: a worker asks the sibling that already reproduced the bug for the exact command and environment rather than rediscovering it.
 - **Coordinate**: parallel writers claim ownership of shared files, serialize expensive suites or builds, and announce when a shared step is done.
+- **Broadcast and hand off**: share a confirmed finding with every sibling at once, or pass work along a chain of siblings without a parent hop.
 
 ```typescript
 // In a child: find who else is in the group, then talk to them
@@ -333,9 +334,11 @@ intercom({ action: "send", to: "worker-2", message: "I own src/api/*; leave thos
 intercom({ action: "ask", to: "reviewer-1", message: "You flagged the retry loop as unbounded. I read a max of 5 attempts at client.ts:88 — what did you see?" })
 ```
 
-Peer asks and one blocking supervisor request may wait concurrently in the same child; a peer reply returns to the asking child with its context intact. Mutual asks work as long as both sides process inbound work. Keep exchanges bounded and evidence-driven, do not defer to a peer's conclusion without inspecting the evidence, and still return your own complete result. Peer messages do not replace the supervisor for scope, product, or architecture decisions.
+Peer asks and one blocking supervisor request may wait concurrently in the same child; a peer reply returns to the asking child with its context intact. Mutual asks work as long as both sides process inbound work. Decide on evidence rather than deferring to a peer's conclusion, and still return your own complete result. `contact_supervisor` is for supervisor decisions; explicit user approval gates and authorization for destructive or external actions still apply.
 
-To enable this from the parent, launch related work as one parallel set (or an explicit `group`) and say in each task prompt who the peers are and what they should exchange; children do not coordinate spontaneously without that instruction. Use `group: true` to give one parallel set its own private group, or a named group to let later launches join the same conversation.
+Children coordinate spontaneously: they discover peers with `list` and talk to them without waiting for the parent to name them. Launch related work as one parallel set (or an explicit `group`) so the children share a group. Use `group: true` to give one parallel set its own private group, or a named group to let later launches join the same conversation.
+
+Scale the swarm with the task. For very complex work or requested heavy parallelism, run hundreds or thousands of agents that self-organize into teams and coordinate peer-to-peer like an organization. A child cannot call `subagent`, so nest teams through workflow stages (each runs its own parallel set) and child workflows up to `maxDepth`. `parallel.maxTasks`, `parallel.concurrency` and `parallel.runningCapacity` each default to 1000; to run more than 1000 children at once, raise all three; see the Scaling a swarm section of the user subagents guide.
 
 If intercom messages do not show up, check the bridge from the intercom side with `intercom({ action: "status" })`.
 
@@ -465,7 +468,7 @@ Give subagents specific tasks rather than vague mandates.
 
 All builtin specialists can use Intercom when permitted by the parent. Use `contact_supervisor` for parent decisions when the active bridge supplies it. Resolve known scope, product, and architecture questions before launching any writer. If the parent realizes mid-run that the scope is wrong, steer a reachable child, or `quit` it and `resume` it later with a corrected `message`.
 
-When several children work related angles, tell them to use ordinary `intercom` with each other for findings, ownership, and challenges so the parent is not the bottleneck for information that a sibling already holds. See [Peer coordination](#peer-coordination).
+When several children work related angles, they use ordinary `intercom` with each other for findings, ownership, and challenges so the parent is not the bottleneck for information that a sibling already holds. See [Peer coordination](#peer-coordination).
 
 ### Intervene only on clear control signals
 

package/dist/builtin/subagents/src/extension/index.bundle.mjs

@@ -8215,7 +8215,7 @@ Use contact_supervisor for the supervisor. It resolves the supervisor session "{
 - Meaningful progress or unexpected discoveries that change the plan: contact_supervisor({ reason: "progress_update", message: "UPDATE: <summary>" })
 - Toward the supervisor, generic intercom is the fallback only when contact_supervisor is unavailable: intercom({ action: "ask", to: "{orchestratorTarget}", message: "<question>" })
 
-Use ordinary intercom for peers. Sibling agents launched with you, and workflow stages in your invocation, share your Intercom group; intercom({ action: "list" }) shows who is live. Send or ask them directly to share findings and file locations, divide ownership of files or expensive steps, challenge a conclusion with evidence, or learn what a sibling already verified, instead of routing that through the supervisor. Peer asks and one blocking supervisor request may wait at the same time; keep exchanges bounded, decide on evidence rather than deference, and still return your own complete result. Scope, product, and architecture decisions remain supervisor decisions. Do not invent targets.
+Use ordinary intercom for peers. Sibling agents launched with you, and workflow stages in your invocation, share your Intercom group; intercom({ action: "list" }) shows who is live. Send or ask them directly to share findings and file locations, divide ownership of files or expensive steps, challenge a conclusion with evidence, or learn what a sibling already verified, instead of routing that through the supervisor. There are no limits on communication between agents; it is encouraged whenever you need to. Peer asks and one blocking supervisor request may wait at the same time; decide on evidence rather than deference, and still return your own complete result. Scope, product, and architecture decisions remain supervisor decisions. Do not invent targets.
 
 Do not use contact_supervisor or intercom for routine completion handoffs. If no coordination is needed, return a focused task result.`;
 function resolveIntercomSessionTarget(sessionName, sessionId) {
@@ -8538,9 +8538,9 @@ function resolveTempScopeId(options) {
   } catch {}
   return "shared";
 }
-var MAX_PARALLEL_TASKS = 50;
-var MAX_CONCURRENCY = 3;
-var DEFAULT_RUNNING_CAPACITY = 4;
+var MAX_PARALLEL_TASKS = 1000;
+var MAX_CONCURRENCY = 1000;
+var DEFAULT_RUNNING_CAPACITY = 1000;
 var TEMP_ROOT_DIR = path6.join(os4.tmpdir(), `${APP_NAME2}-subagents-${resolveTempScopeId()}`);
 var TEMP_ARTIFACTS_DIR = path6.join(TEMP_ROOT_DIR, "artifacts");
 var SLASH_RESULT_TYPE = "subagent-slash-result";
@@ -19568,7 +19568,7 @@ var DEFAULT_PROMPT_GUIDANCE = [
   - Let each named agent use its declared model and fallback policy: omit the explicit model argument unless the user requests an exact model or a documented task requirement needs one, and record the reason for any override before launch. Do not choose an ad hoc model merely for diversity.
   - If an agent has no declared model or fallback policy, consult packages/coding-agent/docs/models/model-selection.md for general role and effort guidance and packages/coding-agent/docs/models/evals.md for factual per-evaluation benchmark records, then use workflow({ action: "models" }) when available to inspect the configured catalog. Pin only a returned fullId and only append a thinking level listed for that entry. If the catalog tool is unavailable, the catalog is empty, or no catalog model matches the documented evidence and role constraints, leave the child unpinned and state the limitation rather than inventing a model. Do not inspect credentials or infer why a model is absent.
   - Workflow stages automatically receive their invocation-scoped Intercom group, and delegated children inherit the launching session's group across single, parallel, and follow-up work. Do not create or propagate group identifiers for ordinary workflow-stage delegation; use an explicit group only for an intentional topology override. Keep contact_supervisor available for cross-group escalation.
-  - Coordination is not only vertical. Same-group children and sibling workflow stages can discover each other with intercom list and send/ask each other directly to debate findings with evidence, hand off file locations and reproductions, claim ownership of shared files or expensive steps, and learn what a sibling already verified, instead of routing everything through the supervisor. contact_supervisor stays reserved for supervisor decisions. Children do not coordinate spontaneously: when parallel work is related, name the peers and the expected exchange in each task prompt, keep the exchange bounded, and require each child to return its own result.`
+  - Default to peer-to-peer (swarm) coordination; the supervisor is not a message relay. There are no limits on communication between agents; it is encouraged whenever you need to. Same-group children and sibling workflow stages discover each other with intercom list and send/ask each other directly to broadcast findings, debate, claim work, hand off paths and reproductions, and self-organize. contact_supervisor is for supervisor decisions, and each child still returns its own result. Scale the swarm with the task: for very complex work or when the user asks for heavy parallelism, run hundreds or thousands of agents that self-organize into teams (named Intercom groups, per-stage subagent sets, child workflows) and coordinate peer-to-peer like an organization.`
 ];
 
 // dist/builtin/subagents/src/extension/schemas.ts
@@ -19682,7 +19682,7 @@ var SubagentParams = Type.Object({
   })),
   concurrency: Type.Optional(Type.Integer({
     minimum: 1,
-    description: "Top-level PARALLEL mode only: max concurrent tasks. Defaults to config.parallel.concurrency or 3."
+    description: "Top-level PARALLEL mode only: max concurrent tasks. Defaults to config.parallel.concurrency or 1000."
   })),
   group: Type.Optional(GroupSchema),
   worktree: Type.Optional(Type.Boolean({

package/dist/builtin/web-access/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/web-access",
-  "version": "0.9.43",
+  "version": "0.9.44-alpha.2",
   "private": true,
   "description": "Atomic extension for web search, URL fetching, GitHub repo cloning, PDF/video extraction. Fork of: https://github.com/nicobailon/pi-web-access",
   "contributors": [

package/dist/builtin/workflows/CHANGELOG.md

@@ -6,6 +6,26 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+## [0.9.44-alpha.2] - 2026-10-24
+
+### Fixed
+
+- A sticky Intercom broadcast, such as `workflow:<rootRunId>/**`, that reaches many workflow stages no longer makes the workflow journal grow quadratically. Recording one more delivery used to rewrite every stage's deliveries in the run's queued-message event; each event now stores only the deliveries that changed since the run's previous event. In a 160-worker run this shrinks those events from about 160 MB to about 9 MB. Journals written by earlier versions read and resume unchanged ([#3920](https://github.com/bastani-inc/atomic/issues/3920))
+
+## [0.9.44-alpha.1] - 2026-10-24
+
+### Changed
+
+- Workflow stages now default to peer-to-peer (swarm) exchange with no limits on communication between agents: stages coordinate with each other directly instead of relaying through the supervisor, and each stage still returns its own structured result. Workflow guidance now scales swarms to hundreds or thousands of agents for very complex work or requested heavy parallelism, organized into named subgroups, per-stage subagent sets and child workflows. The `defaultConcurrency` setting, which bounds how many workflow stages and `ctx.parallel(...)` tasks run at once when no per-call `concurrency` is given, now defaults to 1000 instead of 3; set it lower to limit concurrency.
+- The `maxDepth` setting, which limits how many workflow levels `ctx.workflow(...)` can nest, now defaults to 3 instead of 4. Set it higher in the workflow config to allow deeper nesting.
+
+### Fixed
+
+- Running many local workers at once no longer freezes the interactive TUI. A local worker pool now runs its workers under a separate pool coordinator process, which handles worker messages, heartbeats, pool journal writes and the Intercom routes of pooled children. The root process only receives periodic progress summaries. If the coordinator process dies, its workers exit with it and `ctx.workflow(child)` throws a retryable `WorkflowInfrastructureError` with code `worker_lost` and the message `Local worker pool coordinator exited (…)` ([#3903](https://github.com/bastani-inc/atomic/issues/3903))
+- Local worker heartbeats and session appends no longer grow the workflow journal on every renewal or entry. Lease renewals update the child's work entry in place instead of adding a row, and session appends no longer repeat the stage checkpoint and the full request with each entry. The first time a pool opens an existing journal, it removes the stored renewal rows and keeps only a digest of each recorded pool request; older runs stay readable and resumable ([#3903](https://github.com/bastani-inc/atomic/issues/3903))
+- `/workflow status` no longer reports `durable checkpoint topology is malformed or incomplete` for a running or crashed root, for example one that was killed, whose child workflow had failed or been skipped while the root kept going. Resuming such a root also replays its completed children from their checkpoints again instead of failing ([#3903](https://github.com/bastani-inc/atomic/issues/3903))
+- Stages of child workflows that run on local workers no longer fail every Intercom call (`join`, `list`, `status`, `send`) with `Live workflow-stage route has no registered workflow owner` when a root fans out many children at once. A pooled stage now starts only after the broker holds its run's Intercom route, and a stage whose route is registering again after a dropped connection waits for it instead of failing. All pooled runs of one root invocation share one route connection, one per invocation rather than per host because the broker grants route ownership per invocation group. A run whose route the broker refuses moves to a connection of its own, so it no longer takes the other runs' routes down with it; only refused runs get one, so the number of extra connections is bounded by the refused runs, not by the number of runs. Pausing, resuming or stopping the root while a stage waits for its route still takes effect at once ([#3904](https://github.com/bastani-inc/atomic/issues/3904))
+
 ## [0.9.43] - 2026-10-24
 
 ### Added

package/dist/builtin/workflows/README.md

@@ -457,7 +457,7 @@ When an item configures both `schema` and `output`, its successful `structured_o
 
 Send material updates through Intercom to every affected workflow stage, including stages that have not started. Join `workflow:<rootRunId>` and use `intercom list` to see live, pending, and possible future targets, then send to `workflow:<rootRunId>/<segment>[/<segment>...]`; segments may be stage names, run ids, or globs (`*` matches one segment, `**` any depth). Name and pattern sends remain sticky for every future match until root termination. When shared scope or acceptance criteria change, broadcast one authoritative update to `workflow:<rootRunId>/**` (or a narrower pattern) rather than enumerating stages; live matches receive it immediately and future matches receive it before their first model turn. A valid target outside the known set queues with a `notInKnownSet` warning and settles undeliverable at terminal only if never delivered. Use `ask` only once the target is live and can reply. Workflow `answer` handles pending human-input prompts, and workflow `resume` handles paused run control.
 
-Stages are also peers of one another. Every stage in an invocation shares the `workflow:<rootRunId>` group with its siblings and with the subagents they delegate, so a live stage can `intercom list` the others and `send`/`ask` them directly to debate a finding with evidence, hand off paths and reproductions, claim shared files or an expensive step, or learn what a sibling already verified. A `send` to a known pending sibling queues until it starts; an `ask` to a completed sibling that retains a valid conversation reopens it for a post-mortem turn. Named subgroups isolate their members from sibling subgroups. Stages do not coordinate spontaneously: when parallel stages should exchange evidence, the prompt names the peers or how to discover them, bounds the exchange, and requires each stage to return its own result. See [peer coordination between stages](../coding-agent/docs/workflows/reliable-design.md#peer-coordination-between-stages).
+Stages are also peers of one another. Every stage in an invocation shares the `workflow:<rootRunId>` group with its siblings and with the subagents they delegate, so a live stage can `intercom list` the others and `send`/`ask` them directly to debate a finding with evidence, hand off paths and reproductions, claim shared files or an expensive step, or learn what a sibling already verified. A `send` to a known pending sibling queues until it starts; an `ask` to a completed sibling that retains a valid conversation reopens it for a post-mortem turn. Named subgroups isolate their members from sibling subgroups. Peer-to-peer (swarm) exchange is the default, and the supervisor is not a message relay. There are no limits on communication between agents; it is encouraged whenever you need to. Stages coordinate spontaneously and each still returns its own result. For very complex work or requested heavy parallelism, swarms scale to hundreds or thousands of agents organized into teams; see [Scaling a swarm](../coding-agent/docs/subagents.md#scaling-a-swarm) for the limits. See [peer coordination between stages](../coding-agent/docs/workflows/reliable-design.md#peer-coordination-between-stages).
 
 ### Model fallbacks
 

package/dist/builtin/workflows/builtin/{chunk-frqxd4d1.js → chunk-k8d7ehjx.js}

@@ -1368,7 +1368,13 @@ function createStoreContext(state = createStoreState()) {
     }
     return cachedGraphSnapshot;
   }
+  let batchDepth = 0;
+  let batchedNotification = false;
   function notify() {
+    if (batchDepth > 0) {
+      batchedNotification = true;
+      return;
+    }
     observation.capture();
     for (const fn of state.invalidationListeners) {
       try {
@@ -1388,6 +1394,18 @@ function createStoreContext(state = createStoreState()) {
     state.version++;
     notify();
   }
+  function batch(update) {
+    batchDepth++;
+    try {
+      return update();
+    } finally {
+      batchDepth--;
+      if (batchDepth === 0 && batchedNotification) {
+        batchedNotification = false;
+        notify();
+      }
+    }
+  }
   function findRun(runId) {
     return state.runs.find((r) => r.id === runId);
   }
@@ -1441,6 +1459,7 @@ function createStoreContext(state = createStoreState()) {
     snapshot,
     graphSnapshot,
     notify,
+    batch,
     bumpAndNotify,
     findRun,
     findStage,
@@ -2261,6 +2280,9 @@ function createRunStoreMethods(context) {
     subscribeInvalidation(fn) {
       state.invalidationListeners.add(fn);
       return () => state.invalidationListeners.delete(fn);
+    },
+    batch(update) {
+      return context.batch(update);
     }
   };
 }

package/dist/builtin/workflows/builtin/{chunk-3s95f7ry.js → chunk-qxpymnaf.js}

@@ -37,7 +37,7 @@ import {
   parseFailureDiagnostics,
   summarizeReviewConvergence,
   reverify_consolidated_batch
-} from "./chunk-frqxd4d1.js";
+} from "./chunk-k8d7ehjx.js";
 import {
   VERIFICATION_SCALE
 } from "./chunk-n1910xc4.js";

package/dist/builtin/workflows/builtin/{chunk-edhf30ef.js → chunk-zjecnjxx.js}

@@ -39,7 +39,7 @@ import {
   reviewerFailureText,
   summarizeReviewConvergence,
   reverify_consolidated_batch
-} from "./chunk-frqxd4d1.js";
+} from "./chunk-k8d7ehjx.js";
 import {
   fold_usage
 } from "./chunk-tgt0s5e5.js";

package/dist/builtin/workflows/builtin/goal.js

@@ -1,7 +1,7 @@
 import {
   goal_default
-} from "./chunk-3s95f7ry.js";
-import"./chunk-frqxd4d1.js";
+} from "./chunk-qxpymnaf.js";
+import"./chunk-k8d7ehjx.js";
 import"./chunk-2377r57g.js";
 import"./chunk-z0d03ktm.js";
 import"./chunk-n1910xc4.js";

package/dist/builtin/workflows/builtin/index.js

@@ -16,8 +16,8 @@ import {
 } from "./chunk-z3pajrfs.js";
 import {
   goal_default
-} from "./chunk-3s95f7ry.js";
-import"./chunk-frqxd4d1.js";
+} from "./chunk-qxpymnaf.js";
+import"./chunk-k8d7ehjx.js";
 import"./chunk-z0d03ktm.js";
 import {
   open_claude_design_default
@@ -27,7 +27,7 @@ import {
 } from "./chunk-dcxscfnb.js";
 import {
   ralph_default
-} from "./chunk-edhf30ef.js";
+} from "./chunk-zjecnjxx.js";
 import {
   tournament_default
 } from "./chunk-49kkbdpr.js";

package/dist/builtin/workflows/builtin/ralph.js

@@ -1,7 +1,7 @@
 import {
   ralph_default
-} from "./chunk-edhf30ef.js";
-import"./chunk-frqxd4d1.js";
+} from "./chunk-zjecnjxx.js";
+import"./chunk-k8d7ehjx.js";
 import"./chunk-2377r57g.js";
 import"./chunk-z0d03ktm.js";
 import"./chunk-n1910xc4.js";

package/dist/builtin/workflows/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/workflows",
-  "version": "0.9.43",
+  "version": "0.9.44-alpha.2",
   "private": true,
   "description": "Atomic extension for multi-stage workflow authoring and execution.",
   "contributors": [