@bastani/atomic 0.9.18 → 0.9.19-alpha.10

package/dist/builtin/intercom/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bastani/intercom",
-  "version": "0.9.18",
+  "version": "0.9.19-alpha.10",
   "private": true,
   "description": "Atomic extension providing a private coordination channel between parent and child agent sessions. Fork of: https://github.com/nicobailon/pi-intercom",
   "contributors": [
@@ -10,7 +10,7 @@
   "license": "MIT",
   "type": "module",
   "engines": {
-    "bun": ">=1.4.0"
+    "bun": ">=1.4.2"
   },
   "main": "./index.ts",
   "types": "./index.ts",

package/dist/builtin/intercom/recipient-purpose.ts

@@ -0,0 +1,9 @@
+import type { SessionInfo } from "./types.js";
+
+export const NON_AGENT_RECIPIENT_REFUSAL = "Target is an internal non-agent connection and cannot receive Intercom messages";
+export const TERMINAL_CHILD_ASK_REFUSAL = "Target noninteractive child is terminal and cannot reply; launch a fresh child with explicit context";
+
+/** Older host registrations omit purpose and continue to represent agents. */
+export function isAgentRecipient(session: Pick<SessionInfo, "recipientPurpose">): boolean {
+	return session.recipientPurpose === undefined || session.recipientPurpose === "agent";
+}

package/dist/builtin/intercom/recoverable-disconnect.ts

@@ -14,9 +14,8 @@
  * non-recoverable initialization failure — stays actionable.
  */
 
-/** Model-visible recovery direction for a stale broker socket. */
-export const RECOVERABLE_DISCONNECT_MESSAGE =
-	"Client disconnected. Retry the same Intercom call up to three times to reconnect.";
+/** Transport diagnosis. Delivery tools own bounded recovery, not their callers. */
+export const RECOVERABLE_DISCONNECT_MESSAGE = "Client disconnected";
 
 /**
  * Bound on the `cause` chain walk. Intercom wraps failures with `cause` on the

package/dist/builtin/intercom/retry-policy.ts

@@ -1,8 +1,10 @@
 /** Existing maximum wait for an `ask` reply. */
 export const ASK_REPLY_TIMEOUT_MS = 10 * 60 * 1000;
-/** Bounded opportunity to repeat a typed recoverable-disconnect result after the ask wait. */
+/** Bounded reconnect opportunity after the ask wait. */
 export const RETRY_IDENTITY_RETRY_OPPORTUNITY_MS = 60 * 1000;
-/** An operation identity covers the full ask wait plus one explicit retry opportunity. */
+/** An operation identity covers the full ask wait plus reconnect recovery. */
 export const RETRY_IDENTITY_TTL_MS = ASK_REPLY_TIMEOUT_MS + RETRY_IDENTITY_RETRY_OPPORTUNITY_MS;
 /** Broker authority outlives client-held identities so a boundary retry cannot lose acceptance proof in transit. */
 export const DELIVERED_MESSAGE_TTL_MS = RETRY_IDENTITY_TTL_MS + RETRY_IDENTITY_RETRY_OPPORTUNITY_MS;
+/** Three reconnect attempts, used independently before initialization and during delivery. */
+export const RECONNECT_DELAYS_MS = [1_000, 2_000, 5_000] as const;

package/dist/builtin/intercom/skills/intercom/SKILL.md

@@ -67,11 +67,11 @@ intercom({
 
 ### Pattern 2: Quick Status Check
 
-Before sending, verify who's connected. The full session ID printed by `list` is directly usable by `send`, `ask`, and targeted `reply`:
+Before sending, verify who's connected. Each list row leads with a copyable full session ID or canonical workflow path. Names are secondary; redundant generated aliases are omitted from the list but remain valid targets.
 
 ```typescript
 intercom({ action: "list" })
-// → • planner (6332faab-1111-4222-8333-123456789abc) — /workspace (model) [idle]
+// → - `6332faab-1111-4222-8333-123456789abc` [idle] /workspace (model) name: planner
 intercom({ action: "ask", to: "6332faab-1111-4222-8333-123456789abc", message: "Which option should I use?" })
 ```
 
@@ -128,7 +128,7 @@ intercom({ action: "pending" })
 intercom({ action: "reply", to: "planner", message: "Use exponential backoff starting at 100ms." })
 ```
 
-`reply` still preserves exact threading under the hood by sending the response with the original `replyTo` value.
+Explicit `to` selects that sender's pending ask even if another message triggered the current turn. Use `pending` and an exact `replyTo` when the sender has several asks. Stale, unknown, empty, or sender-mismatched explicit selectors fail without replying to another thread. Omit both selectors only when you intend to reply to the active message, or otherwise the single pending ask.
 
 ### Pattern 4: Broadcast to Multiple Workers
 
@@ -358,6 +358,7 @@ If neither `cmux` nor `tmux` is available, skip this path and use normal `interc
 
 ### `ask` Limitations
 
+- **Terminal noninteractive children**: Completed, failed, interrupted, or cancelled subagents cannot reply, even if listed as `idle`. New asks fail immediately; an admitted ask fails if the child terminates before replying. Launch a fresh child with explicit context. Live interactive idle sessions and reply-capable workflow post-mortem conversations remain askable; `send` semantics are unchanged.
 - **10-minute timeout**: If no reply comes within 10 minutes, the ask fails
 - **Bounded concurrency**: Up to `maxPendingAsks` asks (default: 6) may wait concurrently; additional calls receive a structured capacity error
 - **Exact correlation**: Same-target and mixed-target asks may run together; out-of-order replies and peer disconnects settle only the matching sender/message pair
@@ -493,13 +494,13 @@ if (!result.delivered) {
 
 ### Connection lost
 
-Sessions automatically reconnect if the broker restarts. If an explicit `send`, `ask`, or `reply` fails with the typed `Client disconnected` error, copy the opaque `retryToken` from the tool result and repeat the exact action and arguments with it. Make at most three claimed attempts. Never attach that token to a different action, target, message, attachment sequence, attachment presence (`attachments` omitted is not explicit `[]`), or reply thread, and omit it for every fresh operation—even a deliberately byte-identical one. Invalid, expired, foreign-session, mismatched, concurrent, exhausted, and settled claims fail without sending.
+Sessions automatically reconnect if the broker restarts. A single `send`, `ask`, or `reply` call also owns up to three internal retries after a typed recoverable disconnect, with 1, 2, and 5 second delays. Do not supply a retry token. The tool preserves the original message ID, arguments, and reply route, and never extends the original 11-minute deadline. Confirmation appears only once.
 
-The token keeps the original message ID and deadline (11 minutes from the initial attempt: the 10-minute ask window plus one minute). A claimed retry that returns `delivered: false`, `Session not found`, durable-authority uncertainty/capacity refusal, or another typed disconnect returns the same token for the next bounded claim; each claim consumes one attempt and never extends the deadline. Delivered or queued success settles it. Initial tokenless nondelivery and unrelated/non-recoverable failures do not create retry state.
+Every new tool call is a new operation, even with identical text. If recovery cannot establish the result, the tool returns a terminal error with `outcome: "unknown"`: delivery may already have occurred. Do not repeat that operation automatically. Check with the recipient before intentionally sending again. Cancellation stops new attempts; a successful receipt still reports success. An accepted ask cancelled or timed out before its reply also warns against resending. Initial nondelivery and unrelated errors do not start recovery.
 
-Broker acceptance is retained for 12 minutes, so acknowledgement loss does not duplicate delivery and a deduplicated ask remains replyable. Implicit public reply prefers the recorded exact sender ID while live and falls back to authorized reconnect resolution only after departure. A retained implicit reply keeps its original sender/question snapshot, so later inbound asks cannot redirect its token claim. Durable SQLite stores fixed keyed HMAC digests rather than message/attachment text; its paired key and database artifacts are owner-only on POSIX. Missing, malformed, uncertain, or capacity-bound authority fails closed rather than risking a duplicate.
+Broker acceptance is retained for 12 minutes, so acknowledgement loss does not duplicate delivery and a deduplicated ask remains replyable. An implicit reply keeps its original sender/question snapshot across retries, so later inbound asks cannot redirect it. Durable SQLite stores keyed HMAC digests rather than message/attachment text; its key and database artifacts are owner-only on POSIX. Missing, malformed, uncertain, or capacity-bound authority fails closed rather than risking a duplicate.
 
-Retry safety is bounded: fresh client operations reserve one of 1,000 identity slots before confirmation, target resolution, or send, while valid existing claims remain usable at capacity. The broker and local result relay allow 10,000 live delivery records; the broker also bounds digest/routing authority to 64 MiB. At a limit Intercom refuses new work before its delivery side effect rather than evicting a still-valid identity.
+Fresh calls reserve one of 1,000 client identity slots before confirmation, target resolution, or send; existing internal retries remain usable at capacity. Client retry state is released when the call ends, without deleting broker authority. The broker and local result relay allow 10,000 live delivery records; the broker also bounds digest/routing authority to 64 MiB. Capacity refusal never evicts a still-valid delivery identity.
 
 If the session remains disconnected after those retries:
 

package/dist/builtin/intercom/types.ts

@@ -1,5 +1,9 @@
 export interface SessionInfo {
   id: string;
+  /** Host-declared connection purpose; omitted by legacy agent clients. Immutable after registration. */
+  readonly recipientPurpose?: "agent" | "control";
+  /** Host-owned execution capability, independent of idle/thinking presence. */
+  replyCapability?: "live" | "terminal";
   name?: string;
   cwd: string;
   model: string;
@@ -25,6 +29,13 @@ export interface WorkflowStageRosterEntry {
 	readonly sessionId?: string;
 }
 
+/** Internal run-tree edge used to resolve known recipients before dispatching to the owner. */
+export interface WorkflowRunParentAnnouncement {
+	readonly runId: string;
+	/** Boundary spellings that resolve uniquely to this child, with stage-ID precedence applied by the host. */
+	readonly stageKeys: readonly string[];
+}
+
 export interface WorkflowPossibleStageAnnouncement {
 	/** Canonical depth-faithful path target, e.g. `workflow:<rootRunId>/orchestrator-*`. */
 	readonly target: string;
@@ -52,6 +63,8 @@ export interface WorkflowStageRosterAnnouncement {
 	readonly target: string;
 	readonly lifecycle: "pending" | "running";
 	readonly routeEligible: boolean;
+	/** Host-declared node purpose, independent of legacy pending-route eligibility. */
+	readonly recipientPurpose?: "agent" | "control";
 	/** Actual stage group after workflow invocation ownership resolution. */
 	readonly group: string;
 }
@@ -68,7 +81,7 @@ export interface Message {
   timestamp: number;
   replyTo?: string;
   expectsReply?: boolean;
-  /** Actionable remote failure for a correlated ask reply. */
+  /** Correlated delivery refusal: settles a waiting ask, otherwise surfaces as send feedback. */
   replyError?: string;
   source?: {
     subagentRunId: string;
@@ -111,7 +124,7 @@ export type ClientMessage =
 	| { type: "join_group"; requestId: string; group: string }
 	| { type: "leave_group"; requestId: string; group?: string }
   | { type: "authorize_supervisor"; requestId: string; childName: string; capability?: string }
-  | { type: "send" | "supervisor_send"; to: string; logicalTarget?: string; requirePendingReply?: true; message: Message; attemptId?: string }
+  | { type: "send" | "supervisor_send"; to: string; logicalTarget?: string; requirePendingReply?: true; expectedRecipientId?: string; resolveReplyTarget?: true; message: Message; attemptId?: string }
 	| {
 			type: "send_pending_stage_notification";
 			runId: string;
@@ -123,7 +136,7 @@ export type ClientMessage =
 			attemptId?: string;
 	  }
 	| { type: "pending_stage_notification_result"; requestId: string; delivered: boolean }
- | { type: "register_pending_stage_route"; runId: string; group: string; capability: string; stages?: WorkflowStageRosterAnnouncement[]; possibleStages?: WorkflowPossibleStageAnnouncement[] }
+ | { type: "register_pending_stage_route"; runId: string; group: string; capability: string; stages?: WorkflowStageRosterAnnouncement[]; possibleStages?: WorkflowPossibleStageAnnouncement[]; parent?: WorkflowRunParentAnnouncement }
   | {
       type: "register_live_workflow_stage_route";
       requestId: string;
@@ -144,6 +157,7 @@ export type ClientMessage =
       type: "presence";
       name?: string;
       status?: string;
+      replyCapability?: SessionInfo["replyCapability"];
       model?: string;
       groups?: string[];
       /** Legacy single-group membership; accepted alongside `groups` for compatibility. */
@@ -154,6 +168,7 @@ export type ClientMessage =
 export type BrokerMessage =
   | { type: "registered"; sessionId: string; supervisorSessionId?: string }
   | { type: "registration_failed"; reason: string }
+  | { type: "question_target"; messageId: string; attemptId: string; sessionId: string }
  | { type: "sessions"; requestId: string; sessions: SessionInfo[]; workflowStages?: WorkflowStageRosterEntry[]; workflowFutureStages?: WorkflowFutureStageRosterEntry[] }
 	| { type: "groups"; requestId: string; groups: GroupSummary[] }
 	| { type: "membership_ack"; requestId: string; groups: string[] }

package/dist/builtin/mcp/CHANGELOG.md

@@ -7,6 +7,12 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.9.19-alpha.2] - 2026-09-08
+
+### Fixed
+
+- MCP call headers now identify the server before results arrive, including pending direct tools and gateway calls with explicit or unambiguous targets.
+
 ## [0.9.15] - 2026-08-21
 
 Cumulative release of the `0.9.15-alpha.1` prerelease. The summary below covers the user-visible outcome of that work; the per-change detail remains in the prerelease section below.

package/dist/builtin/mcp/README.md

@@ -342,6 +342,8 @@ Prefer `.mcp.json` for project-local shared MCP config. Use `.pi/mcp.json` only
 | Connect | `mcp({ connect: "server-name" })` |
 | UI messages | `mcp({ action: "ui-messages" })` |
 
+MCP call headers show the server name while pending, without waiting for a result. Direct tools use their registered server; gateway calls use an explicit target or an unambiguous match in available metadata or configured prefixes. Unknown or ambiguous targets keep the operation/tool name without guessing a server. Rendering never connects to a server.
+
 MCP proxy and direct-tool results render compactly by default: long text shows the first three lines plus a `ctrl+o Expand` hint, while the full result remains available when expanded and is still returned unchanged to the model.
 
 Search includes both MCP tools and Pi tools (from extensions). Pi tools appear first with `[pi tool]` prefix. Space-separated words are OR'd.