@dreb/coding-agent 2.72.0 → 2.73.0

package/README.md

@@ -398,7 +398,7 @@ Task tracking is prompt-driven: the system prompt includes guidelines for when t
 
 ## Subagents
 
-The optional `subagent` tool runs focused, role-matched work in independent child agent processes. Each subagent runs in its own process with its own context window, and notifies the parent when complete. In the dashboard, a live child's transcript view can accept the user's own steering messages directly; repeated messages use that child's configured one-at-a-time or all-at-once steering queue. Completed and rehydrated transcripts remain read-only.
+The optional `subagent` tool runs focused, role-matched work in independent child agent processes. Each subagent runs in its own process with its own context window, and notifies the parent when complete. In that notification the child's own output sits between `--- agent output ---` and `--- end of agent output ---` lines (`--- agent output (partial) ---` when the child was cancelled or failed). System lines such as execution metadata, warnings, errors, and the session log stay outside those lines. A chain delimits each step's output. In the dashboard, a live child's transcript view can accept the user's own steering messages directly; repeated messages use that child's configured one-at-a-time or all-at-once steering queue. Its ■ stop cancels just that child — the parent and other subagents keep running, and the parent gets a cancellation notice (with any partial output) without being woken. Esc in the TUI (or the parent's stop) cancels all running subagents. Stops are graceful: the child aborts its own run first, so running tools such as a hung bash command are killed rather than orphaned. Completed, cancelled, and rehydrated transcripts remain read-only.
 
 When `agent` is omitted, dreb selects the default `Explore` agent. Explore retrieves concrete, bounded evidence: files, symbols, documentation, call sites, exact snippets, tests for a named behavior, and explicitly named data flows. The primary agent must synthesize that evidence and owns root-cause diagnosis, ambiguous-requirement interpretation, architecture/design decisions, implementation recommendations, planning, and final conclusions.
 
@@ -419,7 +419,7 @@ Set `backgroundAgents.maxConcurrentSubagents` in `/settings`, dashboard Settings
 
 **Per-agent model overrides:** The model used by each agent type can be overridden via the `agentModels.models` setting (a map of agent name → ordered fallback list) without copying or editing the agent definition `.md` files. Configure it in `settings.json` or via `/settings` → **Agent Models**. Resolution order: per-invocation `model` override → `agentModels` setting → agent definition `model` → parent session model. See [docs/agent-models.md](docs/agent-models.md).
 
-**Single model mode:** The `singleModelMode` setting (default `false`) forces every subagent to run on the parent session's model. When enabled, per-invocation `model` overrides, `agentModels` fallback lists, agent-definition models, spawn-time probes, and the dispatch arbiter are all bypassed, and any requested model selection — even one identical to the parent's — is reported to the parent by prepending a `[WARNING: ...]` note to the child's output. If nothing requested a model, no warning appears. If the parent session has no model, the spawn fails loudly. Configure it in the TUI (`/settings`), dashboard Settings, or `settings.json`. See [docs/agent-models.md](docs/agent-models.md#single-model-mode).
+**Single model mode:** The `singleModelMode` setting (default `false`) forces every subagent to run on the parent session's model. When enabled, per-invocation `model` overrides, `agentModels` fallback lists, agent-definition models, spawn-time probes, and the dispatch arbiter are all bypassed, and any requested model selection — even one identical to the parent's — is reported to the parent as a `[WARNING: ...]` note just before the child's output. If nothing requested a model, no warning appears. If the parent session has no model, the spawn fails loudly. Configure it in the TUI (`/settings`), dashboard Settings, or `settings.json`. See [docs/agent-models.md](docs/agent-models.md#single-model-mode).
 
 **Optional Dispatch Arbiter:** A global-only `subagentArbiter` setting can enable a fully headless, direct model call after the proposal above resolves but before each child process spawns. It uses the validated routing guide, live explicit model scope, and bounded title-setter-style parent activity including useful tool outputs; existing secret scrubbing applies before inference. It may change only the existing agent type, exact scoped provider/model, and supported thinking level. It has no tools, cannot rewrite the task/cwd or agent definitions, and fails closed on configuration, guide, scope, inference, output, or validation errors. It runs once per single/parallel child and after `{previous}` substitution for every chain step. Interactive `/settings` and dashboard Settings both expose enable/disable, exact model selection, thinking, guide path, and loud readiness/validation feedback. Safe typed changed/unchanged/failure records are persisted outside parent model context and relayed to the TUI, JSON/RPC, and dashboard. See [Dispatch Arbiter](docs/agent-models.md#dispatch-arbiter) and [settings](docs/settings.md#dispatch-arbiter).
 

package/dist/core/agent-session.d.ts

@@ -71,7 +71,10 @@ export type AgentSessionEvent = AgentEvent | SubagentArbitrationEvent | {
     type: "background_agent_end";
     agentId: string;
     agentType: string;
+    /** True only for a clean, non-cancelled finish (always false when `cancelled`). */
     success: boolean;
+    /** True when the user stopped the agent (single-agent stop or stop-all). */
+    cancelled: boolean;
     model?: string;
     thinking?: ThinkingLevel;
     steps?: SubagentStepMetadata[];
@@ -199,6 +202,11 @@ export declare class AgentSession {
     private _unsubscribeAgent?;
     private _eventListeners;
     private _agentEventQueue;
+    /**
+     * Agent events queued on `_agentEventQueue` that haven't finished processing yet.
+     * Persistence happens there, so the session log lags agent state until this is 0.
+     */
+    private _agentEventsInFlight;
     /** Tracks pending steering messages for UI display. Removed when delivered. */
     private _steeringMessages;
     /** Tracks pending follow-up messages for UI display. Removed when delivered. */
@@ -219,6 +227,14 @@ export declare class AgentSession {
     private _retryResolve;
     private _bashAbortController;
     private _pendingBashMessages;
+    /**
+     * Background-agent cancellation notices that arrived while the parent was busy (see
+     * `_canDeliverCancellationNotices`). Appending them then could land a user message
+     * between an assistant tool call and its result, or ahead of messages not yet persisted.
+     * They are held until the parent is idle again, or are persisted to their session before
+     * it is replaced.
+     */
+    private _pendingCancellationNotices;
     private _extensionRunner;
     private _turnIndex;
     private _resourceLoader;
@@ -742,6 +758,24 @@ export declare class AgentSession {
     get isBashRunning(): boolean;
     /** Whether there are pending bash messages waiting to be flushed */
     get hasPendingBashMessages(): boolean;
+    /**
+     * Whether deferred cancellation notices can be appended now without landing inside
+     * work that is still changing the transcript. Not while the agent streams, while
+     * earlier agent events are still being processed or persisted (the session log would
+     * get the notice ahead of them), while an auto-retry is pending (its backoff or the
+     * retried run), or while compaction or branch summarization runs.
+     */
+    private _canDeliverCancellationNotices;
+    /**
+     * Append deferred background-agent cancellation notices to agent state and the session
+     * log, in arrival order, and render them, if the parent is idle (see
+     * `_canDeliverCancellationNotices`). Otherwise they stay queued. They are retried after
+     * each processed agent event (`_processAgentEvent`), before the next prompt, and after manual compaction or
+     * branch navigation. Never triggers a response.
+     */
+    private _flushPendingCancellationNotices;
+    private _appendPendingCancellationNotices;
+    private _persistPendingCancellationNoticesBeforeSessionChange;
     /**
      * Flush pending bash messages to agent state and session.
      * Called after agent turn completes to maintain proper message ordering.