@bastani/atomic 0.9.39 → 0.9.40-alpha.1

package/docs/workflows/operations.md

@@ -20,7 +20,7 @@ Stage selectors preserve exact stage IDs and names, composite `runId:stageId` ID
 
 ### Intercom delivery to pending workflow stages
 
-A workflow stage uses the root-anchored `workflow:<rootRunId>/<segment>[/<segment>...]` path shown by `intercom list` and workflow status surfaces. A segment may be a stage name, a materialized run id, or a glob: `*` matches one segment and may be embedded, while `**` matches any depth. Model-facing `workflow status` and interactive status list/detail surfaces enumerate materialized pending stages by display name and canonical stage ID, printing the path only when `pendingStageDeliveryAvailable` is true and the owning run is nonterminal. An ended root or nested child never advertises a retained pending target. Duplicate names remain independently identifiable. The workflow SDK `sessionId` is **not** an Intercom target.
+A workflow stage uses the root-anchored `workflow:<rootRunId>/<segment>[/<segment>...]` path shown by `intercom list` and workflow status surfaces. A segment may be a stage name, a materialized run id, or a glob: `*` matches one segment and may be embedded, while `**` matches any depth. Model-facing `workflow status` and interactive status list/detail surfaces enumerate materialized pending stages by display name and canonical stage ID, printing the path only when `pendingStageDeliveryAvailable` is true and the owning run is nonterminal. An ended root or nested child never advertises a retained pending target. Duplicate names remain independently identifiable. The workflow SDK `sessionId` is the stage's Atomic session ID, not a workflow path: it reaches the stage only while the stage is connected and visible to you, and it never queues for a pending stage.
 
 Join `workflow:<rootRunId>` and run `intercom({ action: "list" })` to see live sessions, materialized `PENDING`/`RUNNING` stages, and possible future literal, glob, and nested-child targets with queued counts. Then use ordinary Intercom delivery:
 
@@ -238,7 +238,7 @@ Mounted HIL and custom prompts take precedence: a `/skill:` answer is literal pr
 
 `/tasks` opens the owner task list locally, never a skill or model message. Empty and populated lists use the same compact picker as main chat, without combining tasks from other chats. Enter inspects the selected task; focused actions offer retained transcript inspection, foreground waiting, confirmed cancellation, and stdin when available. Terminal tasks omit live actions. Escape returns to the picker with selection preserved, then to chat. A stage question arriving during inspection remains pending and is shown when you leave the inspector. Task navigation does not create a main-chat input-needed notice; genuine main-chat prompts waiting behind a visible graph still do.
 
-`/tasks` is also suggested in the stage slash menu independently of `enableSkillCommands`. Its [background-task status](/background-tasks) appears below MCP status; the graph-return shortcut does not overwrite the task-inspection hint. Pausing a workflow stage cancels its active and admitted queued background agents and commands and waits for cleanup. It blocks fresh launches immediately; already-in-flight command setup may briefly start during the transition but must drain and be cancelled before pause completes. Stage-scoped pause leaves main-chat tasks and sibling stages alone. Merely detaching the chat or ending a foreground turn does not cancel background work. Closing the stage generation still cancels remaining owned work.
+`/tasks` is also suggested in the stage slash menu independently of `enableSkillCommands`. Its [background-task status](/background-tasks) appears below MCP status; the graph-return shortcut does not overwrite the task-inspection hint. Pausing a workflow stage cancels its active and admitted queued background agents and commands and waits for cleanup. Subagents stopped this way stay resumable: the stage agent can continue them with `subagent({ action: "resume", id })`, and resuming the run after Atomic restarts restores them with the stage. Only a stage that finishes, or whose run ends or is cancelled, ends its subagents for good. It blocks fresh launches immediately; already-in-flight command setup may briefly start during the transition but must drain and be cancelled before pause completes. Stage-scoped pause leaves main-chat tasks and sibling stages alone. Merely detaching the chat or ending a foreground turn does not cancel background work. Closing the stage generation still cancels remaining owned work.
 
 If inspection fails, the host displays the error and keeps your input for retry. It does not send the command to the model.
 
@@ -301,7 +301,7 @@ Control behavior:
 - Intercom's slash-separated `target` is a messaging address, not a `workflow` `stageId`. An Intercom stage row also includes its owning `runId` and local `stageId`; pass that pair to `stage` or `transcript`, or use the expanded ID from `workflow stages` with the root run ID.
 - `transcript` is reference-first with a small preview by default: it returns metadata, transcript paths, and up to 5 recent entries. For targeted lookup, quote the exact `sessionFile`/`transcriptPath` value without changing platform separators (preserve Windows backslashes), search it with `rg` or `grep`, then read only small surrounding ranges. Text results include JSON-escaped `sessionFileJson`/`transcriptPathJson` lines for copy-safe path literals. Pass explicit `tail` or `limit` to override the 5-entry preview; `tail` overrides `limit`; `includeToolOutput` includes captured snapshot tool output in snapshot transcript results.
 - `answer` responds only to a pending primitive or structured human-input prompt. It accepts `promptId` plus `response`, `text`, or `message`, preserves prompt-kind validation, and never sends stage chat, steers, resumes, or starts a model turn.
-- Send free-form updates through ordinary Intercom to `workflow:<rootRunId>/<segment>[/<segment>...]`; `*` matches one segment and `**` any depth. Use `intercom list` inside the invocation group to see live, pending, and possible future targets. Atomic delivers immediately to live stages and queues matching future stages, delivering them before their first model turn. `workflow:<rootRunId>/**` remains sticky for every future descendant until root termination; narrower name and pattern sends reach every future match. Valid paths outside the known set queue with a `notInKnownSet` warning and settle undeliverable at terminal only if never delivered. Use `ask` once the target has a reply-capable live session. Use `workflow resume` only for paused workflow control.
+- Send free-form updates through ordinary Intercom to `workflow:<rootRunId>/<segment>[/<segment>...]`; `*` matches one segment and `**` any depth. Use `intercom list` inside the invocation group to see live, pending, and possible future targets. Atomic delivers immediately to live stages and queues matching future stages, delivering them before their first model turn. `workflow:<rootRunId>/**` remains sticky for every future descendant until root termination; narrower name and pattern sends reach every future match. Valid paths outside the known set queue with a `notInKnownSet` warning and settle undeliverable at terminal only if never delivered. Use `ask` once the target has a reply-capable live session. Use `workflow resume` only for paused workflow control. While an interrupted run waits for `/workflow resume`, the background subagents its stages launched are addressable as well: sends to them wait in the broker, not in the run's journal, and are delivered once after the resumed stage restores the subagent. If another session resumes the run, senders waiting for a subagent are told so and should send again there. If the run ends before the stage restores a subagent, the held sends return `Session not found`.
 - `pause` and `quit` can target one top-level run or `all: true`; `stageId` cannot be combined with `all: true`. Stage-scoped `pause` controls can target a visible nested child stage from the expanded graph. Atomic routes stage controls to the owning nested run internally.
 - `pause` and `quit` can also name one in-flight `ctx.tool` node with `stageId`, by expanded node id, local `tool:<argsHash>` id, or tool name. Both mean the same thing for a tool: abort that single call now. Tool nodes stay non-attachable — this is an abort control, not a chat target. Identifiers resolve exactly first and then uniquely; a name shared by two tool nodes (or by a stage and a tool) returns the same ambiguity diagnostic stages get, listing each match as `<name> (tool)`.
 - Aborting one tool node leaves every sibling stage and sibling tool node running and does not pause the run. The node becomes `cancelled`, writes no replayable checkpoint, and re-runs on a later resume. Whether the run itself survives is ordinary author control flow: an awaited `ctx.tool` that is aborted rejects, exactly as it would for any other failure, unless the workflow catches it. A node that has already settled reports that it is not running rather than silently succeeding.
@@ -309,7 +309,7 @@ Control behavior:
 - Whole-run `quit` stays authoritative even if workflow code catches the tool rejection. A catch may run cleanup, but its returned outputs do not convert the quit into a completed run: the executor suspends and quit's paused/resumable record stands. To abort one call and intentionally keep the workflow going, target that node instead of quitting the run.
 - A targeted tool abort reports the node outcome and the run separately: `status: "cancelled"` for the node it cancelled, `stageId` for that node, `abandoned` when the callback ignored its signal, and `workflowStatus` for the run status *observed* when the action returned. It never reports `paused`, and it never predicts what the run does next.
 - `pause` preserves resumable live work. With no active stage/tool handle (including initialization and between-node waits), it keeps the same executor paused rather than quitting it. Run-level `resume` on that live process releases the barrier exactly once; later tracked steps, cached replay, and run completion wait for that explicit resume. An already-started untracked JavaScript await or non-cancellable I/O may still finish; pause cannot physically freeze arbitrary author code or roll back effects. A stage declared during this pause defers registration until its asynchronous method runs after resume; synchronous session access requires resume first.
-- A stage pause cancels that generation's owned task executions, not its queued messages or future workflow stages. User and Intercom messages remain held until resume; resume allows fresh tasks and never restarts the cancelled executions. Cancellation and cleanup failures reject the pause rather than reporting a successful stop.
+- A stage pause cancels that generation's owned task executions, not its queued messages or future workflow stages. User and Intercom messages remain held until resume; resume allows fresh tasks and never restarts cancelled commands. Subagents the pause stopped stay resumable with `subagent({ action: "resume", id })`, and a resume after Atomic restarts restores them. Cancellation and cleanup failures reject the pause rather than reporting a successful stop.
 - A whole-run executor-only pause also holds already-live owned child workflows, including children with no tracked node yet. Resume persists the root's running transition before releasing those child executors; a child-scoped control leaves sibling workflows alone.
 - Live executor resume does not require a checkpoint. Cross-process resume still requires durable checkpoint or pending-prompt progress: losing a zero-progress live owner cannot reconstruct its JavaScript continuation. Cancelling the original startup request before acknowledgement remains terminal cancellation, not this live pause.
 - `resume` can target a live paused stage with `stageId`; the target may be an exact stage id or an exact stage name. `message` is forwarded to paused work. Durable/cross-process resume is whole-run only and refuses a stage selector before dispatch rather than resuming the entire root. For a live interrupted streaming prompt, Atomic preserves the existing prompt loop without duplicating the user message and injects `Continue where you left off. If you believe you are finished with your original task (or a redefined task if the user told you), stop.` when required before normal readiness-gate completion. For a paused stage that was idle waiting for a new stage-chat turn, a non-empty message resumes the stage and starts exactly one fresh prompt containing that message; an empty resume releases the pause without creating a prompt.
@@ -350,6 +350,10 @@ The same continuation applies to user messages queued into a live streaming stag
 
 Messages delivered to an idle stage start a fresh user turn immediately and receive no continuation nudge; abort, kill, workflow exit, and finalized/fail-fast stage boundaries suppress late prompt creation and continuation injection.
 
+Resuming a stage that was interrupted mid-session also restores the background subagents that stage launched. It replays the stage's interrupted Intercom messages before the stage continues, and both are visible in the stage transcript. Stages keep the same `workflow:<rootRunId>/...` Intercom targets after resume, and messages queued for them while they were down are delivered once. Opening a post-mortem chat on a completed stage does not restart its stopped subagents.
+
+Before you run `/workflow resume`, an interrupted run's stages stay reachable through Intercom: messages sent to them are queued and delivered once after resume. See [deferred delivery to pending stages](/intercom/reference#deferred-delivery-to-pending-stages).
+
 Resuming several stages can make partial progress. Inspect status after an acknowledgement or persistence error: stages already running are not retried, and genuinely paused stages remain available for another resume. A later resume can retry a failed durable-state update. Terminal runs cannot be revived.
 
 ### Post-mortem chat vs. execution resume
@@ -376,7 +380,7 @@ The target sees the original ask, and its normal `intercom.reply` remains correl
 
 This reopens only the conversation. The workflow DAG and terminal stage snapshot remain completed and are never resumed or re-dispatched. If the target run or stage was deleted, lacks a valid retained conversation, is non-resumable, or fails to reopen, the caller receives a bounded actionable `intercom.ask` tool error instead of waiting indefinitely.
 
-Workflow stages and their subagent transcripts are excluded from ordinary `/resume`, `atomic -r`, `--continue`, and global history. Use workflow inspection and resume commands for stages; terminal subagents remain transcript artifacts, not resumable children. An explicit `--session` file path can still open a stage transcript. Older unmarked workflow sessions may remain in ordinary history.
+Workflow stages and their subagent transcripts are excluded from ordinary `/resume`, `atomic -r`, `--continue`, and global history. Use workflow inspection and resume commands for stages. A stage's subagents continue through `subagent({ action: "resume", id })` from the stage that launched them; once that stage has finished, or its run has ended or been cancelled, all of them are terminal, including ones the stage paused or quit, and `resume` refuses them with an error that says their workflow stage ended (see [Run control](/subagents#run-control)). An explicit `--session` file path can still open a stage transcript. Older unmarked workflow sessions may remain in ordinary history.
 
 Embedding hosts can run the same pause, quit, and resume actions programmatically with `session.workflows`; see [Workflow run control](/sdk#workflow-run-control).
 
@@ -657,7 +661,7 @@ That history does not authorize any live release action.
 
 ### Configuring journal storage
 
-Set `workflows.journal.path` in `settings.json` or set `ATOMIC_WORKFLOW_JOURNAL_PATH` before starting Atomic to select a local SQLite file. The non-empty environment value overrides settings; SDK `RunOpts.journal` and `createAgentSession({ journal })` override both. Relative settings paths resolve against the Atomic home directory, normally `~/.atomic`. With no override, Atomic uses `~/.atomic/workflows/journal.sqlite`. To use a remote database, select an [adapter module](/storage#selecting-an-adapter) in `workflows.journal` or shared `storage`.
+Set `workflows.journal.path` in `settings.json` or set `ATOMIC_WORKFLOW_JOURNAL_PATH` before starting Atomic to select a local SQLite file. The non-empty environment value overrides settings; SDK `RunOpts.journal` and `createAgentSession({ journal })` override both. Relative settings paths resolve against the Atomic home directory, normally `~/.atomic`. With no override, Atomic uses `~/.atomic/workflows/journal.sqlite`. To use a remote database, select an [adapter module](/storage#selecting-an-adapter) in `workflows.journal` or shared `storage`. To select the journal for one process without editing settings, use `ATOMIC_WORKFLOWS_JOURNAL`, `ATOMIC_STORAGE`, or `--storage`; see [Selecting storage per process](/storage#selecting-storage-per-process).
 
 For process-local storage, use `workflows.journal.memory: true` without a non-empty settings path, or pass `journal: { memory: true }` to SDK `run()`. Memory is never selected after a storage failure. Preserve a SQLite journal and its sidecar files; use the same journal and working directory to resume an existing run. See [Workflow storage settings](/settings#workflow-storage).
 

package/npm-shrinkwrap.json

@@ -1,16 +1,16 @@
 {
 	"name": "@bastani/atomic",
-	"version": "0.9.39",
+	"version": "0.9.40-alpha.1",
 	"lockfileVersion": 3,
 	"requires": true,
 	"packages": {
 		"": {
 			"name": "@bastani/atomic",
-			"version": "0.9.39",
+			"version": "0.9.40-alpha.1",
 			"license": "MIT",
 			"dependencies": {
-				"@bastani/atomic-natives": "0.9.39",
-				"@bastani/pi-ai": "0.9.39",
+				"@bastani/atomic-natives": "0.9.40-alpha.1",
+				"@bastani/pi-ai": "0.9.40-alpha.1",
 				"@earendil-works/pi-agent-core": "1.3.0",
 				"@earendil-works/pi-codemode": "1.3.0",
 				"@earendil-works/pi-tui": "1.3.0",
@@ -18,7 +18,7 @@
 				"@modelcontextprotocol/sdk": "1.32.1",
 				"@mozilla/readability": "^0.6.0",
 				"@silvia-odwyer/photon-node": "0.3.4",
-				"@typesafe-ai/sdk": "0.6.0",
+				"@typesafe-ai/sdk": "0.7.0",
 				"brace-expansion": "5.0.12",
 				"chalk": "6.0.0",
 				"cross-spawn": "7.0.6",
@@ -427,18 +427,18 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"optionalDependencies": {
-				"@bastani/atomic-natives-darwin-arm64": "0.9.39",
-				"@bastani/atomic-natives-darwin-x64": "0.9.39",
-				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.39",
-				"@bastani/atomic-natives-linux-arm64-musl": "0.9.39",
-				"@bastani/atomic-natives-linux-x64-gnu": "0.9.39",
-				"@bastani/atomic-natives-linux-x64-musl": "0.9.39",
-				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.39",
-				"@bastani/atomic-natives-win32-x64-msvc": "0.9.39"
+				"@bastani/atomic-natives-darwin-arm64": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-darwin-x64": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-linux-arm64-gnu": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-linux-arm64-musl": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-linux-x64-gnu": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-linux-x64-musl": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-win32-arm64-msvc": "0.9.40-alpha.1",
+				"@bastani/atomic-natives-win32-x64-msvc": "0.9.40-alpha.1"
 			},
 			"engines": {
 				"bun": ">=1.4.2",
@@ -446,8 +446,8 @@
 			}
 		},
 		"node_modules/@bastani/atomic-natives-darwin-arm64": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -458,8 +458,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-darwin-x64": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"darwin"
@@ -470,8 +470,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-gnu": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -485,8 +485,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-arm64-musl": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -500,8 +500,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-gnu": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -515,8 +515,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-linux-x64-musl": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"linux"
@@ -530,8 +530,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-arm64-msvc": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -542,8 +542,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/atomic-natives-win32-x64-msvc": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"os": [
 				"win32"
@@ -554,8 +554,8 @@
 			"optional": true
 		},
 		"node_modules/@bastani/pi-ai": {
-			"version": "0.9.39",
-			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.39.tgz",
+			"version": "0.9.40-alpha.1",
+			"resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.40-alpha.1.tgz",
 			"license": "MIT",
 			"dependencies": {
 				"@anthropic-ai/sdk": "0.129.0",
@@ -1209,12 +1209,12 @@
 			"license": "MIT"
 		},
 		"node_modules/@typesafe-ai/sdk": {
-			"version": "0.6.0",
-			"resolved": "https://registry.npmjs.org/@typesafe-ai/sdk/-/sdk-0.6.0.tgz",
-			"integrity": "sha512-IddX+Q0XM+VagOUZFeP7wZjaO4SHMdvnh2zEBdrZZnXedWI3BNK1lKhMx3ayrkFWvVLbVcUHJy6AVZlY+e6Jaw==",
+			"version": "0.7.0",
+			"resolved": "https://registry.npmjs.org/@typesafe-ai/sdk/-/sdk-0.7.0.tgz",
+			"integrity": "sha512-Yg3OZArCQMJx98ut8QVkhx3rFo9ON7pz8Hjzv8c3FGz69Sk8jYftLOlz+Wf6kq6jol/1m08aBnjRAzJr2x3GoQ==",
 			"license": "MIT",
 			"engines": {
-				"node": ">=20"
+				"node": ">=22"
 			}
 		},
 		"node_modules/@xmldom/xmldom": {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/atomic",
-  "version": "0.9.39",
+  "version": "0.9.40-alpha.1",
   "description": "Atomic coding agent CLI with read, bash, edit, write tools and session management",
   "type": "module",
   "atomicConfig": {
@@ -89,8 +89,8 @@
     "prepublishOnly": "bun run clean && bun run build && bun run shrinkwrap"
   },
   "dependencies": {
-    "@bastani/atomic-natives": "0.9.39",
-    "@bastani/pi-ai": "0.9.39",
+    "@bastani/atomic-natives": "0.9.40-alpha.1",
+    "@bastani/pi-ai": "0.9.40-alpha.1",
     "@earendil-works/pi-agent-core": "1.3.0",
     "@earendil-works/pi-codemode": "1.3.0",
     "@earendil-works/pi-tui": "1.3.0",
@@ -98,7 +98,7 @@
     "@modelcontextprotocol/sdk": "1.32.1",
     "@mozilla/readability": "^0.6.0",
     "@silvia-odwyer/photon-node": "0.3.4",
-    "@typesafe-ai/sdk": "0.6.0",
+    "@typesafe-ai/sdk": "0.7.0",
     "brace-expansion": "5.0.12",
     "chalk": "6.0.0",
     "cross-spawn": "7.0.6",