@bastani/atomic 0.9.19-alpha.7 → 0.9.19-alpha.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -53,6 +53,8 @@ Sent and received messages are recorded in session history as `intercom_sent` /
53
53
 
54
54
  Live-session lookup accepts only an exact full Intercom session ID or an exact case-insensitive session name. Workflow stages use the canonical `workflow:<rootRunId>/<segment>[/<segment>...]` path printed by `intercom list` and workflow status surfaces; an exact target works while the row is `PENDING` and after it becomes `RUNNING`. Each segment may be a stage name, run id, or glob: `*` matches one segment and may be embedded, while `**` matches any depth. Status surfaces label pending stages whose pre-start delivery capability is unavailable without presenting a usable target and never advertise a retained pending stage after its run terminates. The `sessionId` shown by `workflow status` belongs to the workflow SDK and is **not** an Intercom target.
55
55
 
56
+ Agent list rows put the copyable exact ID or canonical workflow path first, followed by status and working directory. Meaningful names remain secondary metadata; redundant generated aliases are hidden only in the list, not removed from lookup. Pending and future workflow rows retain lifecycle and queued counts. Copy the target rather than reconstructing it from a name.
57
+
56
58
  Known non-agent IDs, names, and workflow paths are refused rather than delivered or queued for a future agent. This includes run-level `ctx.ui` prompts, synthetic prompt stages (including retained completed prompts), and `ctx.tool` nodes. Knowing an internal connection's ID does not bypass this broker policy, and supervisor delivery cannot bypass it either. Workflow patterns and `workflow:<rootRunId>/**` still queue for future agent stages, but never deliver to prompt/tool nodes or routing connections.
57
59
 
58
60
  This refusal also covers nested paths using boundary-stage names or IDs, mixed with materialized run-ID segments. The same spellings still resolve genuine agent stages.
@@ -100,6 +102,8 @@ An `idle` registration does not guarantee reply capability. Completed, failed, i
100
102
 
101
103
  **`reply`** is receiver-side sugar for replying to an inbound ask. In the turn triggered by an incoming intercom message, `intercom({ action: "reply", message: "..." })` targets that exact sender and message automatically. If you reply later, it falls back to the single unresolved inbound ask; with multiple pending asks, use `pending` and pass `to`, or pass the listed message ID as `replyTo` to disambiguate multiple asks from the same sender. Under the hood this is still a normal `send` with the exact `replyTo` value.
102
104
 
105
+ Explicit selectors override the active turn: `to` selects a pending ask from that exact name/full session ID, and `replyTo` selects only that pending ask or the exact active ordinary message. Stale, unknown, or empty thread IDs fail without falling back. If both selectors are supplied, the sender must match the thread. If an asker is still waiting, inspect `pending` and reply using its exact message ID rather than replying implicitly to an unrelated notification. Multiple asks from the same sender require `replyTo`.
106
+
103
107
  ### Attachments
104
108
 
105
109
  `send`, `ask`, and `reply` accept an `attachments` array of `{ type, name, content, language? }` objects where `type` is `"file"`, `"snippet"`, or `"context"`. Attachment content is included in the recipient's agent-visible message body. When a parent-targeted foreground `ask` is terminally handed off at the source, the same ordered attachment array is retained and rendered with the question for the launching parent; duplicate names and content are not rewritten. Attachments are supported in the protocol but not in the ALT+M compose overlay.
package/docs/intercom.md CHANGED
@@ -81,10 +81,10 @@ The agent can list sessions and send messages using the `intercom` tool. Tool ca
81
81
  ```typescript
82
82
  // List active sessions
83
83
  intercom({ action: "list" })
84
- // → **Current session:**
85
- // → executor (20d43841-1111-4222-8333-123456789abc) ~/projects/api (claude-sonnet-4) [self, idle]
86
- // → **Other sessions:**
87
- // → research (6332faab-1111-4222-8333-123456789abc) ~/projects/api (claude-sonnet-4) [same cwd, thinking]
84
+ // → **Current session** (groups: default):
85
+ // → - `20d43841-1111-4222-8333-123456789abc` [self, idle] ~/projects/api (claude-sonnet-4) name: executor
86
+ // → **Other visible sessions and workflow stages:**
87
+ // → - `6332faab-1111-4222-8333-123456789abc` [same cwd, thinking] ~/projects/api (claude-sonnet-4) name: research
88
88
 
89
89
  // Send a message
90
90
  intercom({ action: "send", to: "research", message: "Check if UserService.validate() handles null" })
@@ -22,6 +22,16 @@ For a video, include the question in `prompt`:
22
22
  {"urls": ["/path/to/recording.mp4"], "prompt": "What error appears on screen?"}
23
23
  ```
24
24
 
25
+ For webpages, `urls` is enough. `prompt` and `model` apply to video analysis, not webpage filtering or extraction. `forceClone` applies only to GitHub repositories.
26
+
27
+ Use `frames` and `timestamp` only when you want images from YouTube or local video files. Omit both for readable text or transcripts. `frames` alone samples the whole video; `timestamp` accepts seconds, a time such as `1:25`, or a range such as `1:25-2:00`.
28
+
29
+ ```json
30
+ {"urls": ["/path/to/recording.mp4"], "timestamp": "1:25-2:00", "frames": 3}
31
+ ```
32
+
33
+ Frame extraction requires ffmpeg, plus yt-dlp for YouTube. Non-video inputs ignore `frames` and `timestamp` and are fetched normally, even in a batch containing videos. Video inputs still validate timestamps and report extraction errors.
34
+
25
35
  Existing prompts or integrations using `{"url": "..."}` must change to `{"urls": ["..."]}`. The singular `url` field is no longer accepted by `fetch_content`. This does not change the `url` selector on `get_search_content`.
26
36
 
27
37
  Atomic can normalize a scalar `urls` string into a one-item array. Always use the documented array form in prompts and integrations; the legacy `url` field is not normalized.
@@ -27,6 +27,10 @@ Send material updates through Intercom to every affected workflow stage, includi
27
27
 
28
28
  At 80 columns and wider, each `BACKGROUND` card keeps the full run identity and preserves its mode, progress, live-tool details, and elapsed/status metadata. When the remaining single-row budget permits, it adds bounded pending-stage details: a target is either shown exactly or replaced by a `stage`-labeled canonical ID, and `… N more` reports omitted pending stages. If no bounded pending-stage form fits, the pending label is omitted entirely rather than displacing the existing metadata. Tool nodes are read-only durable graph nodes, not attachable stage chats. Below 80 columns, the panel keeps its aggregate collapsed form and omits run IDs, stage identities, targets, and tool names.
29
29
 
30
+ The shared background widget occupies at most **10 rows**, including its scroll hint, and at most one third of the terminal height, rounded down with a one-row minimum. From the main editor, use **Alt+PageUp** and **Alt+PageDown** to scroll one row at a time. Every row remains reachable even when a multiline draft leaves room for only one widget row. The row range at the bottom shows your position when there is room for the hint. Ordinary typing, arrows, PageUp/PageDown, and mouse scrolling keep their existing editor and transcript behavior.
31
+
32
+ Below 80 columns the widget remains a single count line, truncated to fit when necessary; widen the terminal to scroll the cards or use `/workflow connect` to inspect runs at narrow widths.
33
+
30
34
  The panel's stage progress includes recursively nested child workflows and updates as new stages appear. The numerator counts completed, failed, and skipped stages; the denominator counts all currently materialized stages, not future work. Expanded children replace their workflow boundary rather than counting both, and durable tool nodes are not stages. A failed, skipped, missing, or invalid child expansion keeps its boundary summary. `single`/`chain` follows this same stage count.
31
35
 
32
36
  For chat surfaces such as workflow status, run detail, dispatch confirmation, and the run picker, a full id wraps onto continuation rows when the card is narrower than the id. Pending-stage targets in run detail use the same rule: the exact address wraps instead of being ellipsized, and narrow status cards wrap the canonical stage ID or drop its display-name decoration rather than rendering a partial ID. The renderer keeps the card border closed at its minimum layout width, while terminals below that floor — including sub-30-column terminals — can hard-clip the box. An awaiting-input attribution banner is titled `AWAITING INPUT` and contains the same two identity rows — `?` plus the full run id, then the workflow name and optional metadata — while the existing prompt question and options remain below it in the normal prompt UI.
@@ -122,7 +126,7 @@ If you copy a HIL workflow example into a headless session, it can pass dispatch
122
126
 
123
127
  <p align="center"><img src="../images/workflow-input-picker.png" alt="Workflow Input Picker" width="600" /></p>
124
128
 
125
- Graph node cards show each model stage's effective model and thinking level beneath its status, including after fallback and durable resume. Long model names are truncated first, preserving the complete thinking level and a canonical `-fast` model suffix. This suffix is model identity, not a separate fast-mode switch or proof of service tier. Thinking `off` is omitted; unresolved model identity shows `—`. Tool nodes retain their `durable tool` body, and the `BACKGROUND` summary is unchanged.
129
+ Graph node cards show each model stage's effective model and thinking level above its status, including after fallback and durable resume. Long model names are truncated first, preserving the complete thinking level and a canonical `-fast` model suffix. This suffix is model identity, not a separate fast-mode switch or proof of service tier. Thinking `off` is omitted; stages without a model show no model placeholder. Tool nodes retain their `durable tool` body, and the `BACKGROUND` summary is unchanged.
126
130
 
127
131
  ## Workflow Commands
128
132
 
@@ -159,7 +163,7 @@ Surface behavior:
159
163
  - **Graph vs. stage chat** - Use `connect` for the workflow graph. Use `attach` when you want a chat pane for a specific stage.
160
164
  - **Hierarchy chord** - `ctrl+x` is the workflow hierarchy chord: in an attached stage chat it means **return to graph**, and in the graph it means **return to main chat**. The workflow surface handles `ctrl+x` before configurable editor or tool actions, including while a composer draft, primitive prompt, custom question, stage switcher, or legacy prompt card owns input.
161
165
  - **Draft preservation** - Leaving a stage preserves unsent composer and prompt drafts and keeps pending custom questions unresolved so they reappear when you attach again.
162
- - **Queued-message survival** - Steering and follow-up entries queued from a stage chat live on the stage session, not on the pane. Detaching to the graph and reattaching rehydrates the pending `Steering:` / `Follow-up:` rows, and while you are detached the stage's graph node shows a `✉ N queued` badge so a pending message stays visible without attaching. The attached chat shows the pending text; the detached node shows only their count. Both read one projection that the stage handle keeps current from the session's complete `queue_update` snapshots, so rows and badge shrink together as the agent consumes entries. That projection is fed by the events rather than by a concrete Atomic `AgentSession`, so a stage backed by a custom `AgentSessionAdapter` keeps this behavior as long as it publishes ordinary `queue_update` events; each snapshot replaces the previous steering and follow-up lists rather than adding to them. A queue can also outlive the session holding it — a stage session that fails over to a fallback model hands its pending messages to the session replacing it, and a completed stage reopened as a post-mortem chat is restored holding whatever it was queued. Those messages were announced before the projection could reach the new session, so Atomic reads it once as it attaches and the rows and badge show them too.
166
+ - **Queued-message survival** - Steering and follow-up entries queued from a stage chat live on the stage session, not on the pane. Detaching to the graph and reattaching rehydrates the pending `Steering:` / `Follow-up:` rows, and while you are detached the stage's graph node shows a `✉ N queued` badge on its own row so a pending message stays visible without attaching. The attached chat shows the pending text; the detached node shows only their count. Both read one projection that the stage handle keeps current from the session's complete `queue_update` snapshots, so rows and badge shrink together as the agent consumes entries. That projection is fed by the events rather than by a concrete Atomic `AgentSession`, so a stage backed by a custom `AgentSessionAdapter` keeps this behavior as long as it publishes ordinary `queue_update` events; each snapshot replaces the previous steering and follow-up lists rather than adding to them. A queue can also outlive the session holding it — a stage session that fails over to a fallback model hands its pending messages to the session replacing it, and a completed stage reopened as a post-mortem chat is restored holding whatever it was queued. Those messages were announced before the projection could reach the new session, so Atomic reads it once as it attaches and the rows and badge show them too.
163
167
  - **Reserved keys** - `ctrl+d` and `q` do not navigate workflow surfaces; `ctrl+d` keeps its ordinary editor or prompt behavior where applicable, and `q` remains printable in text-owning prompts. Existing `esc`, `ctrl+c`, and graph `h` close/hide controls are unchanged.
164
168
  - **Wheel and trackpad** - While the workflow graph is active, vertical wheel/trackpad gestures pan it up and down, and horizontal gestures pan wide graphs left and right when the terminal exposes horizontal wheel events. Focused graph and stage-chat overlays receive those gestures through the fullscreen application route, so scrolling stays inside the active workflow surface instead of falling through to terminal or main-chat scrollback.
165
169
  - **Fullscreen mouse routing and selection** - A focused workflow graph or attached stage chat overlay receives wheel/trackpad and click input through the host's application-owned input route before the fullscreen viewport. Events the overlay does not consume fall through to pi-tui's viewport, while non-overlay focused components leave pi-tui's transcript scrolling, scrollbar interaction, and drag-selection path intact. Graph panning, stage-chat scrolling, node click-to-attach, and drag or multi-click selection therefore work without a separate selection mode. Copy uses OSC 52; terminals that refuse OSC 52 writes still support the modifier-drag bypass (Shift/Option, as provided by the terminal). `ctrl+t` is not a workflow control: focused workflow overlays leave it to the host `app.thinking.toggle` action, while inline tree selectors keep `app.tree.filter.noTools`.
@@ -170,6 +174,7 @@ Surface behavior:
170
174
  - **Run control** - Use `pause` and `resume` for resumable live work. Pause holds a stage's queued steering and follow-up items in place without dequeuing them or starting continuation; `resume` releases those items once in their existing per-queue order, but queue release alone does not start a model turn. `resume` on a non-paused run reopens the saved snapshot or overlay. Use `quit` to pause a live run gracefully while preserving it for `/workflow resume`. `/workflow pause` selects the active run by default, accepts a full run id or `--all`, and does not open a stage picker. Use the workflow tool's `stageId` for stage or tool-node targeting.
171
175
  - **Rediscovery** - Use `/workflow reload` after adding, editing, installing, or removing workflow resources or package manifest workflow entries and you want Atomic to rediscover them in-process ([Reloading workflow resources](/workflows/operations#reloading-workflow-resources)).
172
176
  - **Status listing** - `/workflow status` lists all retained active and terminal top-level runs by default; implementation-owned nested child runs are flattened into their parent workflow rather than listed separately. `/workflow status --all` is retained as a compatibility alias.
177
+ - **Status times** - `/workflow status <run-id>` displays `started` and `ended` in the system local timezone as `HH:mm:ss`. If they differ from your expected clock, check the timezone of the machine or container running Atomic and any inherited `TZ` environment setting. Elapsed durations and raw timestamps in structured results are unchanged.
173
178
 
174
179
  `/workflows` is the retained-run history alias for `/workflow resume`: with no id it opens the same mixed picker, but the resumable section lists only runs that the resume path can actually accept and the completed section is read-only inspection. A run with no durable checkpoint, missing/pruned artifacts, or explicit deletion is omitted from the resume picker; an explicit `/workflow resume <id>` still returns an explanatory error. It is intentionally different from `/workflow list`, which lists installed workflow definitions. See [`/workflow resume` — cross-session resume selector](#/workflow-resume-—-cross-session-resume-selector) for the full picker semantics.
175
180
 
@@ -464,7 +469,7 @@ Repeated, sibling, sequential, parallel, and multi-level child calls keep indepe
464
469
 
465
470
  ### `ctx.tool` — durable cached tool execution
466
471
 
467
- The `ctx.tool(name, args, fn, options?)` primitive runs arbitrary TypeScript code as a first-class durable graph node and caches the result durably. The node is non-attachable and has no stage chat controls, and its graph card body is the constant `durable tool` in every state status, timing, and dependency rows keep their own rows, and the card does not preview the result or error. In the graph viewer, focusing the node and pressing Enter, clicking it, or choosing it from the switcher opens a read-only host-style operator card from the snapshot: a status-tinted shaded rectangle with the same inner padding and header/body gap as the main-chat tool block, inset from the orchestrator header and footer bars, a `$ <tool-name>` call header, an optional short argument summary, and the result or error as its body. Running and completed call headers have no status marker; pending, failed, cached, and cancelled calls retain their quiet markers. It is collapsed by default and wraps the fully bounded result or error before showing its last visual rows, with `... (N earlier lines, ctrl+o Expand)` above the tail when the action is bound; the configured `app.tools.expand` action (`ctrl+o` by default) toggles the full bounded result or error and then a muted callback-source block when source exists. The graph statusline advertises the resolved expand key with `expand` or `collapse` alongside return-to-graph and scroll hints, including remapped keys, and omits that segment entirely when the action is unbound. The footer says `Took` for settled calls or `Elapsed` for running calls, using the same second-resolution duration as the main-chat tool block, with cached/replayed markers kept as a quiet suffix. The operator surface has no ARGS/RESULT/SOURCE/TIMING/MARKERS debug table and does not expose raw clock fields. Source capture uses `fn.toString()` at registration without re-executing the callback or reading a file. `↑`/`↓`, `PageUp`/`PageDown`, `Home`/`End`, the wheel, and the scrollbar all scroll the block, so a long payload stays readable on a keyboard-only session or a terminal without mouse reporting; Escape or `ctrl+x` returns to the graph. The message block is read-only and never offers chat attachment, steering, pause, or resume. Bounded payloads remain width-safe and mark truncation explicitly with `… [truncated]`; source tabs expand and control bytes become `\xNN`, while cyclic payloads, throwing `toJSON`, or throwing property getters render `<cycle>`, `<unserializable>`, or `<unreadable>` instead of crashing the view. The same cap applies to what the live run snapshot retains for a tool node, while durable checkpoints keep the exact output, raw-args `argsHash`, and replay behavior unchanged.
472
+ The `ctx.tool(name, args, fn, options?)` primitive runs arbitrary TypeScript code as a first-class durable graph node and caches the result durably. The node is non-attachable and has no stage chat controls, and its graph card body is the constant `durable tool` in every state. The card shows status separately and does not preview the result or error. In the graph viewer, focusing the node and pressing Enter, clicking it, or choosing it from the switcher opens a read-only host-style operator card from the snapshot: a status-tinted shaded rectangle with the same inner padding and header/body gap as the main-chat tool block, inset from the orchestrator header and footer bars, a `$ <tool-name>` call header, an optional short argument summary, and the result or error as its body. Running and completed call headers have no status marker; pending, failed, cached, and cancelled calls retain their quiet markers. It is collapsed by default and wraps the fully bounded result or error before showing its last visual rows, with `... (N earlier lines, ctrl+o Expand)` above the tail when the action is bound; the configured `app.tools.expand` action (`ctrl+o` by default) toggles the full bounded result or error and then a muted callback-source block when source exists. The graph statusline advertises the resolved expand key with `expand` or `collapse` alongside return-to-graph and scroll hints, including remapped keys, and omits that segment entirely when the action is unbound. The footer says `Took` for settled calls or `Elapsed` for running calls, using the same second-resolution duration as the main-chat tool block, with cached/replayed markers kept as a quiet suffix. The operator surface has no ARGS/RESULT/SOURCE/TIMING/MARKERS debug table and does not expose raw clock fields. Source capture uses `fn.toString()` at registration without re-executing the callback or reading a file. `↑`/`↓`, `PageUp`/`PageDown`, `Home`/`End`, the wheel, and the scrollbar all scroll the block, so a long payload stays readable on a keyboard-only session or a terminal without mouse reporting; Escape or `ctrl+x` returns to the graph. The message block is read-only and never offers chat attachment, steering, pause, or resume. Bounded payloads remain width-safe and mark truncation explicitly with `… [truncated]`; source tabs expand and control bytes become `\xNN`, while cyclic payloads, throwing `toJSON`, or throwing property getters render `<cycle>`, `<unserializable>`, or `<unreadable>` instead of crashing the view. The same cap applies to what the live run snapshot retains for a tool node, while durable checkpoints keep the exact output, raw-args `argsHash`, and replay behavior unchanged.
468
473
 
469
474
  When the workflow body fulfills but one or more admitted tool calls failed, Atomic promotes the first observed failure to the terminal run failure, regardless of admission order, and persists that selected tool-node identity for status inspection and lifecycle output. A direct uncaught `await ctx.tool(...)` rejection keeps the original error and persists its failed-node link through session and durable restore. First-event arbitration also preserves the selected node when concurrent failures throw the same object or primitive; unrelated later stage or body errors do not inherit a caught tool's origin. Tool admission remains open while author code can catch a failure and continue. Once the body settles and failure has won before any real cancellation, Atomic closes admission, cancels remaining non-failed tool nodes, waits for observed failed nodes to finish publication, and publishes the failed root without waiting for callbacks that ignore cancellation.
470
475
 
@@ -1,16 +1,16 @@
1
1
  {
2
2
  "name": "@bastani/atomic",
3
- "version": "0.9.19-alpha.7",
3
+ "version": "0.9.19-alpha.9",
4
4
  "lockfileVersion": 3,
5
5
  "requires": true,
6
6
  "packages": {
7
7
  "": {
8
8
  "name": "@bastani/atomic",
9
- "version": "0.9.19-alpha.7",
9
+ "version": "0.9.19-alpha.9",
10
10
  "license": "MIT",
11
11
  "dependencies": {
12
- "@bastani/atomic-natives": "0.9.19-alpha.7",
13
- "@bastani/pi-ai": "0.9.19-alpha.7",
12
+ "@bastani/atomic-natives": "0.9.19-alpha.9",
13
+ "@bastani/pi-ai": "0.9.19-alpha.9",
14
14
  "@dbos-inc/dbos-sdk": "4.25.14",
15
15
  "@earendil-works/pi-agent-core": "0.85.1",
16
16
  "@earendil-works/pi-client": "0.85.1",
@@ -518,18 +518,18 @@
518
518
  }
519
519
  },
520
520
  "node_modules/@bastani/atomic-natives": {
521
- "version": "0.9.19-alpha.7",
522
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.19-alpha.7.tgz",
521
+ "version": "0.9.19-alpha.9",
522
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives/-/atomic-natives-0.9.19-alpha.9.tgz",
523
523
  "license": "MIT",
524
524
  "optionalDependencies": {
525
- "@bastani/atomic-natives-darwin-arm64": "0.9.19-alpha.7",
526
- "@bastani/atomic-natives-darwin-x64": "0.9.19-alpha.7",
527
- "@bastani/atomic-natives-linux-arm64-gnu": "0.9.19-alpha.7",
528
- "@bastani/atomic-natives-linux-arm64-musl": "0.9.19-alpha.7",
529
- "@bastani/atomic-natives-linux-x64-gnu": "0.9.19-alpha.7",
530
- "@bastani/atomic-natives-linux-x64-musl": "0.9.19-alpha.7",
531
- "@bastani/atomic-natives-win32-arm64-msvc": "0.9.19-alpha.7",
532
- "@bastani/atomic-natives-win32-x64-msvc": "0.9.19-alpha.7"
525
+ "@bastani/atomic-natives-darwin-arm64": "0.9.19-alpha.9",
526
+ "@bastani/atomic-natives-darwin-x64": "0.9.19-alpha.9",
527
+ "@bastani/atomic-natives-linux-arm64-gnu": "0.9.19-alpha.9",
528
+ "@bastani/atomic-natives-linux-arm64-musl": "0.9.19-alpha.9",
529
+ "@bastani/atomic-natives-linux-x64-gnu": "0.9.19-alpha.9",
530
+ "@bastani/atomic-natives-linux-x64-musl": "0.9.19-alpha.9",
531
+ "@bastani/atomic-natives-win32-arm64-msvc": "0.9.19-alpha.9",
532
+ "@bastani/atomic-natives-win32-x64-msvc": "0.9.19-alpha.9"
533
533
  },
534
534
  "engines": {
535
535
  "bun": ">=1.4.2",
@@ -537,8 +537,8 @@
537
537
  }
538
538
  },
539
539
  "node_modules/@bastani/atomic-natives-darwin-arm64": {
540
- "version": "0.9.19-alpha.7",
541
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.19-alpha.7.tgz",
540
+ "version": "0.9.19-alpha.9",
541
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-arm64/-/atomic-natives-darwin-arm64-0.9.19-alpha.9.tgz",
542
542
  "license": "MIT",
543
543
  "os": [
544
544
  "darwin"
@@ -549,8 +549,8 @@
549
549
  "optional": true
550
550
  },
551
551
  "node_modules/@bastani/atomic-natives-darwin-x64": {
552
- "version": "0.9.19-alpha.7",
553
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.19-alpha.7.tgz",
552
+ "version": "0.9.19-alpha.9",
553
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-darwin-x64/-/atomic-natives-darwin-x64-0.9.19-alpha.9.tgz",
554
554
  "license": "MIT",
555
555
  "os": [
556
556
  "darwin"
@@ -561,8 +561,8 @@
561
561
  "optional": true
562
562
  },
563
563
  "node_modules/@bastani/atomic-natives-linux-arm64-gnu": {
564
- "version": "0.9.19-alpha.7",
565
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.19-alpha.7.tgz",
564
+ "version": "0.9.19-alpha.9",
565
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-gnu/-/atomic-natives-linux-arm64-gnu-0.9.19-alpha.9.tgz",
566
566
  "license": "MIT",
567
567
  "os": [
568
568
  "linux"
@@ -576,8 +576,8 @@
576
576
  "optional": true
577
577
  },
578
578
  "node_modules/@bastani/atomic-natives-linux-arm64-musl": {
579
- "version": "0.9.19-alpha.7",
580
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.19-alpha.7.tgz",
579
+ "version": "0.9.19-alpha.9",
580
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-arm64-musl/-/atomic-natives-linux-arm64-musl-0.9.19-alpha.9.tgz",
581
581
  "license": "MIT",
582
582
  "os": [
583
583
  "linux"
@@ -591,8 +591,8 @@
591
591
  "optional": true
592
592
  },
593
593
  "node_modules/@bastani/atomic-natives-linux-x64-gnu": {
594
- "version": "0.9.19-alpha.7",
595
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.19-alpha.7.tgz",
594
+ "version": "0.9.19-alpha.9",
595
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-gnu/-/atomic-natives-linux-x64-gnu-0.9.19-alpha.9.tgz",
596
596
  "license": "MIT",
597
597
  "os": [
598
598
  "linux"
@@ -606,8 +606,8 @@
606
606
  "optional": true
607
607
  },
608
608
  "node_modules/@bastani/atomic-natives-linux-x64-musl": {
609
- "version": "0.9.19-alpha.7",
610
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.19-alpha.7.tgz",
609
+ "version": "0.9.19-alpha.9",
610
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-linux-x64-musl/-/atomic-natives-linux-x64-musl-0.9.19-alpha.9.tgz",
611
611
  "license": "MIT",
612
612
  "os": [
613
613
  "linux"
@@ -621,8 +621,8 @@
621
621
  "optional": true
622
622
  },
623
623
  "node_modules/@bastani/atomic-natives-win32-arm64-msvc": {
624
- "version": "0.9.19-alpha.7",
625
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.19-alpha.7.tgz",
624
+ "version": "0.9.19-alpha.9",
625
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-arm64-msvc/-/atomic-natives-win32-arm64-msvc-0.9.19-alpha.9.tgz",
626
626
  "license": "MIT",
627
627
  "os": [
628
628
  "win32"
@@ -633,8 +633,8 @@
633
633
  "optional": true
634
634
  },
635
635
  "node_modules/@bastani/atomic-natives-win32-x64-msvc": {
636
- "version": "0.9.19-alpha.7",
637
- "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.19-alpha.7.tgz",
636
+ "version": "0.9.19-alpha.9",
637
+ "resolved": "https://registry.npmjs.org/@bastani/atomic-natives-win32-x64-msvc/-/atomic-natives-win32-x64-msvc-0.9.19-alpha.9.tgz",
638
638
  "license": "MIT",
639
639
  "os": [
640
640
  "win32"
@@ -645,8 +645,8 @@
645
645
  "optional": true
646
646
  },
647
647
  "node_modules/@bastani/pi-ai": {
648
- "version": "0.9.19-alpha.7",
649
- "resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.19-alpha.7.tgz",
648
+ "version": "0.9.19-alpha.9",
649
+ "resolved": "https://registry.npmjs.org/@bastani/pi-ai/-/pi-ai-0.9.19-alpha.9.tgz",
650
650
  "license": "MIT",
651
651
  "dependencies": {
652
652
  "@anthropic-ai/sdk": "0.124.0",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@bastani/atomic",
3
- "version": "0.9.19-alpha.7",
3
+ "version": "0.9.19-alpha.9",
4
4
  "description": "Atomic coding agent CLI with read, bash, edit, write tools and session management",
5
5
  "type": "module",
6
6
  "atomicConfig": {
@@ -79,8 +79,8 @@
79
79
  "prepublishOnly": "bun run clean && bun run build && bun run shrinkwrap"
80
80
  },
81
81
  "dependencies": {
82
- "@bastani/atomic-natives": "0.9.19-alpha.7",
83
- "@bastani/pi-ai": "0.9.19-alpha.7",
82
+ "@bastani/atomic-natives": "0.9.19-alpha.9",
83
+ "@bastani/pi-ai": "0.9.19-alpha.9",
84
84
  "@dbos-inc/dbos-sdk": "4.25.14",
85
85
  "@earendil-works/pi-agent-core": "0.85.1",
86
86
  "@earendil-works/pi-client": "0.85.1",