@bastani/atomic 0.9.16-alpha.6 → 0.9.16-alpha.8

package/CHANGELOG.md

@@ -2,6 +2,25 @@
 
 ## [Unreleased]
 
+## [0.9.16-alpha.8] - 2026-08-27
+
+### Breaking Changes
+
+- Removed the public `workflow send` action. Use `workflow answer` for pending workflow prompts and ordinary Intercom for workflow-stage communication.
+- Workflow source that typechecks against the legacy bare `@bastani/workflows` specifier must migrate to `@bastani/atomic/workflows`; removing the broken ambient declaration bridge intentionally removes TypeScript resolution for the legacy name. Runtime loading remains backward compatible because Atomic continues to alias `@bastani/workflows` to the in-memory SDK. ([#2716](https://github.com/bastani-inc/atomic/issues/2716))
+
+### Added
+
+- Added fast-mode support for eligible GitHub Copilot models advertised by the signed-in account, alongside the existing OpenAI priority service tier. Chat and workflow scopes remain independently configurable with `/fast`.
+
+### Fixed
+
+- Fixed `/model` and `/thinking` Ctrl+S failing to persist startup defaults in isolated interactive mode. The engine RPC dropped the persist flag, so `settings.json` never received `defaultProvider`/`defaultModel` or the thinking default. Isolated mode now refreshes the host settings view and remote scoped-model catalog after the engine acknowledges persist, and `set_thinking_level` can include the engine's clamped level plus the provider/model the engine persisted against so a later `model_changed` cannot re-key the saved thinking override. Isolated `/thinking` set and cycle update the host session immediately so rapid cycles and UI refresh do not wait for ACK, while a later `thinking_level_changed` still wins over an older ACK. An unsupported requested level is clamped with the same nearest-supported scan as the engine, so hiding `minimal` via `thinkingLevelMap` becomes `low` immediately rather than `off`. `RpcClient.setThinkingLevel(level)` remains one-argument `Promise<void>`; isolated persist reads that ACK through an internal client path, and data-less `set_thinking_level` success responses remain valid. `set_model`, `cycle_model`, and `set_thinking_level` accept optional `persist`. ([#2727](https://github.com/bastani-inc/atomic/issues/2727))
+- Fixed installed packages where the intercom broker failed to start on every launch, leaving both the `intercom` and `subagent` tools entirely non-functional.
+- Fixed Bun-compiled binaries crashing when a transformed extension performed a second `proper-lockfile` operation. Compiled extension imports now reuse the host's lockfile module instead of transforming and proxy-wrapping its mutable internals.
+
+- Fixed the published workflow SDK so importing `@bastani/atomic` no longer injects the workflows graph into every consumer's TypeScript program, consumers can typecheck against the package again, and workflow authoring types no longer silently collapse to `any`. ([#2716](https://github.com/bastani-inc/atomic/issues/2716))
+
 ## [0.9.16-alpha.6] - 2026-08-26
 
 ### Changed

package/dist/builtin/intercom/CHANGELOG.md

@@ -4,6 +4,12 @@ All notable changes to the `pi-intercom` extension will be documented in this fi
 
 ## [Unreleased]
 
+## [0.9.16-alpha.8] - 2026-08-27
+
+### Added
+
+- Extended ordinary `send` delivery to known workflow stages whose sessions have not initialized, with durable FIFO queueing, a distinct `queued` acknowledgment, same-group enforcement, bounded per-stage capacity, structured pre-start `ask` refusal, and delivery through the existing Intercom path before the stage's first model turn. ([#2717](https://github.com/bastani-inc/atomic/issues/2717))
+
 ## [0.9.16-alpha.5] - 2026-08-26
 
 ### Added

package/dist/builtin/intercom/README.md

@@ -334,7 +334,7 @@ The supervisor can reply with plain JSON or a fenced `json` block. If the reply
 | Parameter | Type | Description |
 |-----------|------|-------------|
 | `action` | string | `"list"`, `"join"`, `"leave"`, `"send"`, `"ask"`, `"reply"`, `"pending"`, or `"status"` |
-| `to` | string | Exact session name or exact full session ID (for send/ask, or targeted reply) |
+| `to` | string | Exact session name/full session ID, or `<runId>:<stageKey>` for `send` to a not-yet-started workflow stage (for send/ask, or targeted reply) |
 | `message` | string | Message text (for send/ask/reply) |
 | `attachments` | array | Optional `file`, `snippet`, or `context` attachments |
 | `replyTo` | string | Optional message ID for threading or replying to an `ask` |
@@ -364,11 +364,11 @@ Only registered in sessions where `pi-subagents` supplied the required child bri
 
 **`list`** — Returns the current session plus other active intercom-connected sessions with name, full session ID, working directory, model, and live status. Every displayed full session ID can be passed directly to `send`, `ask`, or targeted `reply`.
 
-Target lookup accepts only an exact full session ID or an exact case-insensitive session name. Targeting is also **group-scoped** — see [Groups](#groups) below.
+Live target lookup accepts only an exact full session ID or an exact case-insensitive session name. Ordinary `send` also accepts `<runId>:<stageKey>` for a known workflow stage whose session has not initialized. The run ID is a full UUID and the stage key is exact. Unknown runs and stages retain the ordinary unknown-target failure. All targeting remains **group-scoped** — see [Groups](#groups) below.
 
-**`send`** — Sends a message to the specified session. By default it sends immediately, including in interactive sessions. Set `confirmSend: true` in config if you want a confirmation dialog for non-reply sends. Replies that include `replyTo` skip confirmation. Returns delivery confirmation.
+**`send`** — Sends through ordinary Intercom. Live workflow-stage sessions receive messages immediately and return `delivered`. For a known pending stage, Atomic persists the message and returns the distinct `queued` result with its FIFO position, then delivers it through the ordinary inbound path when the stage session initializes. Each exact run/stage key retains at most 50 queued messages; the next send is refused rather than evicting an older one. Only sessions in the run's Intercom group may queue messages. Delivery occurs before the first model turn under **Messages received before you started**, with sender identity and `Sent:` timestamp separate from the task prompt. Resume/replay, broker restart, and stage-attempt restart preserve exactly-once delivery by logical message ID. Skipped, cancelled, and terminal-before-initialization destinations make pending messages undeliverable and notify the sender. If the sender reconnects with a new broker UUID, notification fallback requires one unique same-group match for the immutable registration-time name; mutable presence names/groups, cross-group matches, and ambiguous duplicates are rejected. The broker trusts that initial name/group as host-orchestration metadata, while the original display/provenance remains unchanged in the durable record. Live sends remain immediate by default; `confirmSend: true` still enables confirmation for non-reply sends.
 
-**`ask`** — Sends a message and waits for the recipient to reply (10-minute timeout). A recipient disconnect after delivery fails only that peer's exact wait promptly; the timeout remains the backstop while the recipient stays connected. Up to `maxPendingAsks` blocking asks (default: 6) may run concurrently, including same-target and mixed-target fan-out. Replies resolve by exact sender and message ID, so out-of-order replies cannot cross-settle another call. When capacity is full, new asks receive a structured refusal. Use this when the agent needs the answer to continue working.
+**`ask`** — Sends a message and waits for a live recipient to reply (10-minute timeout). An ask to a known workflow stage whose session has not initialized is refused with `pending_stage_ask_unsupported` and recommends ordinary `send`, because holding a reply waiter until a stage eventually starts would be unbounded. A recipient disconnect after live delivery fails only that peer's exact wait promptly; the timeout remains the backstop while the recipient stays connected. Up to `maxPendingAsks` blocking asks (default: 6) may run concurrently, including same-target and mixed-target fan-out. Replies resolve by exact sender and message ID, so out-of-order replies cannot cross-settle another call. When capacity is full, new asks receive a structured refusal.
 
 **`reply`** — Replies to the current intercom-triggered message if there is one. Otherwise it falls back to the single unresolved inbound ask. If multiple asks are pending, pass an exact name/full session ID in `to`, or the listed message ID in `replyTo`; use `pending` to inspect them first. `replyTo` also disambiguates multiple asks from the same sender. Under the hood this is still a normal `send` with the exact `replyTo` value.