@bastani/atomic 0.9.11-alpha.4 → 0.9.11-alpha.6

package/dist/builtin/workflows/src/extension/lifecycle-notifications.ts

@@ -56,6 +56,8 @@ export interface WorkflowLifecycleNoticeDetails {
   readonly promptMessage?: string;
   readonly error?: string;
   readonly failedStageId?: string;
+  readonly toolNodeId?: string;
+  readonly toolName?: string;
   readonly durationMs?: number;
   readonly active?: boolean;
   readonly createdAt: number;
@@ -212,7 +214,7 @@ export function installWorkflowLifecycleNotifications(
     }
 
     const key = terminalRunKey(kind, run);
-    if (state.deliveredTerminalRuns.has(key) || state.pendingTerminalRuns.has(key)) return;
+    if (state.deliveredTerminalRuns.has(key) || state.pendingTerminalRuns.has(key) || state.retryableTerminalRuns.has(key)) return;
     if (state.suppressionDepth > 0) {
       state.deliveredTerminalRuns.add(key);
       state.retryableTerminalRuns.delete(key);
@@ -300,10 +302,11 @@ export function formatWorkflowLifecycleNoticeText(details: WorkflowLifecycleNoti
     return `✓ Workflow "${workflowName}" completed (run ${details.runId}). Inspect: /workflow status ${details.runId}`;
   }
   if (details.kind === "failed") {
-    const stage = details.stageName ?? details.failedStageId;
-    const stageText = stage ? `, stage ${stage}` : "";
+    const stage = details.stageName ?? details.failedStageId ?? details.stageId;
+    const tool = lifecycleToolOrigin(details);
+    const originText = stage ? `, stage ${stage}` : tool !== undefined ? `, tool ${tool}` : "";
     const errorText = details.error ? `: ${details.error}` : "";
-    return `✗ Workflow "${workflowName}" failed (run ${details.runId}${stageText})${errorText}. Inspect: /workflow status ${details.runId}`;
+    return `✗ Workflow "${workflowName}" failed (run ${details.runId}${originText})${errorText}. Inspect: /workflow status ${details.runId}`;
   }
   if (details.kind === "blocked") {
     const errorText = details.error ? `: ${details.error}` : "";
@@ -328,6 +331,8 @@ function makeTerminalNotice(
   const failedStage = run.failedStageId
     ? run.stages.find((stage) => stage.id === run.failedStageId)
     : undefined;
+  const failedToolNodeId = kind === "failed" && run.failedStageId === undefined ? run.failedToolNodeId : undefined;
+  const failedTool = (run.toolNodes ?? []).find((node) => node.id === failedToolNodeId);
   const activeBlocked = kind === "blocked" && isActiveRecoverableBlockedRun(run);
   const error = activeBlocked
     ? run.failureMessage ?? structuredRecoverableWorkflowFailureText(run) ?? run.error
@@ -342,6 +347,8 @@ function makeTerminalNotice(
     ...(error ? { error: truncateSnippet(error) } : {}),
     ...(run.failedStageId ? { failedStageId: run.failedStageId } : {}),
     ...(failedStage ? { stageId: failedStage.id, stageName: failedStage.name } : {}),
+    ...(failedToolNodeId !== undefined ? { toolNodeId: failedToolNodeId } : {}),
+    ...(failedTool !== undefined ? { toolName: failedTool.name } : {}),
     ...(run.durationMs !== undefined ? { durationMs: run.durationMs } : {}),
     createdAt: lifecycleOccurrenceAt(run, kind) ?? Date.now(),
   };
@@ -405,7 +412,9 @@ function awaitingInputKey(runId: string, stage: StageSnapshot): string {
 function runAwaitingInputKey(runId: string, prompt: PendingPrompt): string {
   return `awaiting_input:${runId}:run:${prompt.id}`;
 }
-
+function lifecycleToolOrigin(details: WorkflowLifecycleNoticeDetails): string | undefined {
+  return details.toolName !== undefined && details.toolName.length > 0 ? details.toolName : details.toolNodeId;
+}
 function truncateSnippet(value: string): string {
   const normalized = value.replace(/\s+/g, " ").trim();
   if (normalized.length <= LIFECYCLE_NOTICE_SNIPPET_LIMIT) return normalized;
@@ -447,6 +456,7 @@ function renderLifecycleNoticeCard(
         : "WORKFLOW COMPLETE";
   const glyph = details.kind === "failed" ? "✗" : details.kind === "awaiting_input" ? "？" : details.kind === "blocked" ? "!" : "✓";
   const stage = details.stageName ?? details.failedStageId ?? details.stageId;
+  const tool = stage === undefined ? lifecycleToolOrigin(details) : undefined;
   const headline = details.kind === "failed"
     ? `Workflow "${details.workflowName}" failed`
     : details.kind === "awaiting_input"
@@ -463,6 +473,7 @@ function renderLifecycleNoticeCard(
       { label: "workflow", value: details.workflowName },
       { label: "run", value: details.runId },
       { label: "stage", value: stage },
+      { label: "tool", value: tool },
       { label: "prompt", value: details.promptMessage, tone: "muted" },
       { label: "error", value: details.error, tone: "error" },
       { label: "duration", value: formatDurationMs(details.durationMs), tone: "muted" },

package/dist/builtin/workflows/src/extension/render-result.ts

@@ -11,7 +11,7 @@
  *  - pi-subagents src/extension/index.ts renderResult slot
  */
 
-import type { PendingPrompt, RunSnapshot, StageInputRequest, StageSnapshot, StageStatus } from "../shared/store-types.js";
+import type { PendingPrompt, RunSnapshot, RunStatus, StageInputRequest, StageSnapshot, StageStatus } from "../shared/store-types.js";
 import type { WorkflowRunStatusFilter, WorkflowRunStatusSummary } from "./workflow-status-summary.js";
 import type { WorkflowDetails } from "../shared/types.js";
 import type { RunDetail } from "../runs/background/status.js";
@@ -143,7 +143,21 @@ type TranscriptResult = {
   fallbackNote?: string;
   inlineMode?: TranscriptInlineMode;
 };
-type SendResult = { action: "send"; runId: string; stageId: string; delivery: string; status: "ok" | "noop"; message: string };
+type SendResult = {
+  action: "send";
+  runId: string;
+  stageId: string;
+  delivery: string;
+  message: string;
+} & (
+  | { status: "ok" | "noop" }
+  | {
+      status: "failed";
+      code: "WORKFLOW_TERMINAL";
+      workflowStatus: RunStatus;
+      error: string;
+    }
+);
 type PauseResult = { action: "pause"; runId: string; status: string; message: string };
 type ReloadResult = WorkflowReloadReport & { action: "reload"; status: "ok" | "noop"; message: string };
 type InterruptResult = { action: "interrupt"; runId: string; status: string; message: string };

package/dist/builtin/workflows/src/extension/runtime-durable-resume.ts

@@ -2,6 +2,7 @@ import type { WorkflowExecutionPolicy } from "../shared/types.js";
 import type { StageAdapters } from "../runs/foreground/stage-runner.js";
 import type { RunOpts } from "../runs/foreground/executor.js";
 import type { Store } from "../shared/store.js";
+import type { RunSnapshot } from "../shared/store-types.js";
 import type { JobTracker } from "../runs/background/job-tracker.js";
 import type { WorkflowRegistry } from "../workflows/registry.js";
 import {
@@ -51,6 +52,7 @@ export interface DurableResumeRuntimeDeps {
   readonly ensureReady: () => Promise<void>;
   readonly resolveDefaultStageSessionDir?: () => string | undefined;
   readonly baseRunOpts: (policy?: WorkflowExecutionPolicy) => RunOpts;
+  readonly beforeRestoreCompleted?: (snapshots: readonly RunSnapshot[]) => void;
   readonly jobs?: JobTracker;
 }
 
@@ -141,6 +143,7 @@ export function createDurableResumeRuntime(
         adapters: deps.adapters,
         cwd: handle?.workflowCwd ?? handle?.invocationCwd ?? deps.runtimeCwd,
         defaultSessionDir: deps.resolveDefaultStageSessionDir?.(),
+        beforeRestore: deps.beforeRestoreCompleted,
       }, catalog);
     },
   };

package/dist/builtin/workflows/src/extension/runtime.ts

@@ -77,6 +77,8 @@ export interface ExtensionRuntimeOpts {
   cwd?: string;
   /** Resolve the host's non-default session directory for workflow stage transcripts. */
   resolveDefaultStageSessionDir?: () => string | undefined;
+  /** Seed lifecycle state before historical completed snapshots are restored. */
+  beforeRestoreCompleted?: (snapshots: readonly RunSnapshot[]) => void;
 }
 // ---------------------------------------------------------------------------
 // Public interface
@@ -135,6 +137,7 @@ export function createExtensionRuntime(opts: ExtensionRuntimeOpts = {}): Extensi
   const jobs = opts.jobs;
   const runtimeCwd = opts.cwd ?? process.cwd();
   const resolveDefaultStageSessionDir = opts.resolveDefaultStageSessionDir;
+  const beforeRestoreCompleted = opts.beforeRestoreCompleted;
   const ensureDbosReady = async (): Promise<void> => {
     // Deliberately not memoized: the factory revalidates its memoized backend
     // against the current DBOS lifecycle generation, so caching a permanently
@@ -321,6 +324,7 @@ export function createExtensionRuntime(opts: ExtensionRuntimeOpts = {}): Extensi
       ensureReady: ensureDbosReady,
       resolveDefaultStageSessionDir,
       baseRunOpts: (policy) => runOptions(policy),
+      beforeRestoreCompleted,
       ...(jobs !== undefined ? { jobs } : {}),
     }),
 

package/dist/builtin/workflows/src/extension/wiring.ts

@@ -221,7 +221,9 @@ function makeWorkflowStageOrchestrationContext(
   meta: StageExecutionMeta,
   pi: RuntimeWiringSurface,
 ): NonNullable<CreateAgentSessionOptions["orchestrationContext"]> {
-  const intercomGroup = stageHasIntercomAccess(meta.stageOptions) ? resolveStageGroup(meta.stageOptions) : undefined;
+  const intercomGroup = stageHasIntercomAccess(meta.stageOptions)
+    ? resolveStageGroup(meta.stageOptions, meta.workflowIntercomGroup)
+    : undefined;
   return {
     kind: "workflow-stage",
     workflowRunId: meta.runId,

package/dist/builtin/workflows/src/extension/workflow-command-surfaces.ts

@@ -26,6 +26,7 @@ function fallbackRunDetailFromResult(
     durationMs: 0,
     inputs,
     stages,
+    tools: [],
     result: result.result,
     error: result.error,
     exited: result.exited,

package/dist/builtin/workflows/src/extension/workflow-durable-resume-command.ts

@@ -23,6 +23,8 @@ export interface WorkflowRunControlDeps {
   overlay: GraphOverlayPort;
   runtimeForContext: (ctx?: PiCommandContext) => ExtensionRuntime;
   ensureWorkflowResourcesLoaded: () => Promise<void> | void;
+  /** Seed lifecycle state before the direct completed-inspection fallback restores history. */
+  beforeRestoreCompleted?: (snapshots: readonly RunSnapshot[]) => void;
 }
 
 export interface WorkflowResumeCatalog {
@@ -108,7 +110,7 @@ export async function handleDurableResume(
       return await resumeDurableTarget(resolved.workflowId, ctx, reporter, deps, runtime);
     }
 
-    const completedAttempt = openCompleted(runtime, target, catalog.completed);
+    const completedAttempt = openCompleted(runtime, target, catalog.completed, deps.beforeRestoreCompleted);
     if (!completedAttempt.ok && completedAttempt.reason !== "not_found") {
       fail(completedAttempt.message);
       return true;
@@ -176,7 +178,9 @@ export function resolveWorkflowResumeTarget(
     targets.set(entry.workflowId, { kind: "durable", workflowId: entry.workflowId, name: entry.name });
   }
   for (const entry of completed) {
-    targets.set(entry.workflowId, { kind: "completed", workflowId: entry.workflowId, name: entry.name });
+    if (!targets.has(entry.workflowId)) {
+      targets.set(entry.workflowId, { kind: "completed", workflowId: entry.workflowId, name: entry.name });
+    }
   }
   for (const run of liveRuns.filter(isExplicitResumeCandidate)) {
     targets.set(run.id, {
@@ -228,7 +232,7 @@ function openCompletedTarget(
   deps: WorkflowRunControlDeps,
   runtime: ExtensionRuntime,
 ): boolean {
-  const result = openCompleted(runtime, workflowId, catalog);
+  const result = openCompleted(runtime, workflowId, catalog, deps.beforeRestoreCompleted);
   if (!result.ok) reporter.error(result.message);
   else {
     reporter.info(result.message);
@@ -243,11 +247,13 @@ function openCompleted(
   runtime: ExtensionRuntime,
   workflowIdOrPrefix: string,
   catalog: readonly ResumableWorkflowEntry[],
+  beforeRestoreCompleted?: (snapshots: readonly RunSnapshot[]) => void,
 ) {
   return runtime.openCompletedDurableWorkflow?.(workflowIdOrPrefix, catalog)
     ?? openCompletedDurableWorkflow(workflowIdOrPrefix, {
       durableBackend: getDurableBackend(),
       store,
+      beforeRestore: beforeRestoreCompleted,
     }, catalog);
 }
 

package/dist/builtin/workflows/src/extension/workflow-module-loader.ts

@@ -10,10 +10,15 @@ import { createJiti } from "jiti/static";
 import * as typeboxModule from "typebox";
 import * as workflowsSdkSurface from "../sdk-surface.js";
 import { isBrandedWorkflowDefinition } from "../authoring/workflow.js";
-import deepResearchCodebase from "../../builtin/deep-research-codebase.js";
+import adversarialVerification from "../../builtin/adversarial-verification.js";
+import classifyAndAct from "../../builtin/classify-and-act.js";
+import fanOutAndSynthesize from "../../builtin/fan-out-and-synthesize.js";
+import generateAndFilter from "../../builtin/generate-and-filter.js";
 import goal from "../../builtin/goal.js";
+import loopUntilDone from "../../builtin/loop-until-done.js";
 import openClaudeDesign from "../../builtin/open-claude-design.js";
 import ralph from "../../builtin/ralph.js";
+import tournament from "../../builtin/tournament.js";
 
 const WORKFLOWS_MODULE_SPECIFIER = "@bastani/workflows";
 const WORKFLOWS_BUILTIN_MODULE_SPECIFIER = `${WORKFLOWS_MODULE_SPECIFIER}/builtin`;
@@ -23,10 +28,15 @@ const WORKFLOWS_SDK_MODULE: Record<string, unknown> = {
   ...workflowsSdkSurface,
 };
 const WORKFLOWS_BUILTIN_MODULE: Record<string, unknown> = {
-  deepResearchCodebase,
+  adversarialVerification,
+  classifyAndAct,
+  fanOutAndSynthesize,
+  generateAndFilter,
   goal,
+  loopUntilDone,
   openClaudeDesign,
   ralph,
+  tournament,
 };
 const TYPEBOX_MODULE: Record<string, unknown> = {
   ...typeboxModule,
@@ -35,10 +45,15 @@ const WORKFLOWS_VIRTUAL_MODULES: Record<string, unknown> = {
   [WORKFLOWS_MODULE_SPECIFIER]: WORKFLOWS_SDK_MODULE,
   [WORKFLOWS_BUILTIN_MODULE_SPECIFIER]: WORKFLOWS_BUILTIN_MODULE,
   [TYPEBOX_MODULE_SPECIFIER]: TYPEBOX_MODULE,
-  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/deep-research-codebase`]: { default: deepResearchCodebase },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/adversarial-verification`]: { default: adversarialVerification },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/classify-and-act`]: { default: classifyAndAct },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/fan-out-and-synthesize`]: { default: fanOutAndSynthesize },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/generate-and-filter`]: { default: generateAndFilter },
   [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/goal`]: { default: goal },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/loop-until-done`]: { default: loopUntilDone },
   [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/open-claude-design`]: { default: openClaudeDesign },
   [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/ralph`]: { default: ralph },
+  [`${WORKFLOWS_BUILTIN_MODULE_SPECIFIER}/tournament`]: { default: tournament },
 };
 
 const workflowModuleLoader = createJiti(import.meta.url, {

package/dist/builtin/workflows/src/extension/workflow-prompts.ts

@@ -2,7 +2,7 @@ export const WORKFLOW_TOOL_DESCRIPTION =
   "Run named builtin, project, user, or package workflows; custom definitions may import reusable project/package workflows or builtin definitions from @bastani/workflows/builtin and nest them with ctx.workflow(...), including deeper composition within the configured maxDepth; " +
   "when workflow execution fits but another shape would better achieve the task, author a custom TypeScript workflow({...}) inline with normal coding tools, reload it, and run it; " +
   "discover with list/get/inputs/models, list session runs with status (no runId; statusFilter narrows the list), inspect status/stages/stage details, " +
-  "send prompt answers or steering, pause/resume/interrupt/quit runs, and reload workflow resources. " +
+  "send prompt answers or steering only while the root workflow is nonterminal, pause/resume/interrupt/quit runs, and reload workflow resources. " +
   "For large stage handoffs, write context to files/artifacts, pass paths via reads, and prompt downstream agents to 'Read the file at <path>...' instead of injecting large previous text. " +
   "For transcripts, prefer status/stages/stage to get sessionFile/transcriptPath, " +
   "quote the exact path without rewriting separators (Windows backslashes are valid), " +
@@ -12,12 +12,25 @@ export const WORKFLOW_TOOL_DESCRIPTION =
 
 export const DEFAULT_PROMPT_GUIDANCE: string[] = [
   `**Workflows**: Treat workflows as the default execution path for any non-trivial task and for any request that has inherent structure plus an objective you can make verifiable. Use the \`workflow\` tool for existing named workflows; when the task needs a graph that is not installed, author a custom TypeScript \`workflow({...})\` inline with normal coding tools, reload workflow resources, and run it.
-  - Decide the execution mode before your first tool call on a new request and state it in one short line: inline (tiny, deterministic, low-risk) or workflow. Reconnaissance counts as inline execution, so an unstated "explore first" default must not silently commit you to an unbounded inline session.
   - Workflow fit check: prefer a workflow for implementation, build, debug/diagnosis, bug-fix, migration, new-feature, scoped multi-file, or docs/code changes with validation; and whenever there are multiple steps, dependencies, handoffs, uncertainty, review/validation needs, long-running work, measurable done criteria, or an outcome that needs evidence.
   - Treat loop or stop-condition wording as a strong workflow signal, especially "do X until Y", "repeat until", "iterate until", "review/fix until passing", "run checks and fix until green", "keep going until done", or any prompt that names an approval gate or evidence requirement.
-  - Do not force-fit an installed workflow or builtin such as \`goal\` or \`ralph\`. When another graph better matches the task, write a task-specific TypeScript workflow inline. Use and combine the documented starter patterns: Classify-and-act for runtime routing, Fan-out-and-synthesize for independent slices, Adversarial verification for worker/reviewer/reducer repair, Generate-and-filter or Tournament for competing candidates, and Loop until done for bounded convergence. Rich custom workflows may use deterministic branching, dynamic fan-out, child workflows, artifacts, structured outputs, human-in-the-loop prompts, gates, retries, and explicit stop conditions.
-  - Compose workflows instead of rebuilding every capability in one graph. Workflow definitions are normal TypeScript modules: import reusable project/package definitions or builtins from \`@bastani/workflows/builtin\`, then call \`ctx.workflow(childDefinition, { inputs, stageName })\`. Imported children may nest more workflows up to \`maxDepth\`; their stages, HIL prompts, control, durability, and declared outputs remain part of the expanded parent graph. Pass definitions, not registry-name strings or paths.
-  - Composition examples: import \`deepResearchCodebase\`, then conditionally nest \`goal\` or \`ralph\` for implementation; wrap \`openClaudeDesign\` with project-specific approval/export stages; or build a reusable user-defined research child and import it into several parent workflows. Prefer composing a proven builtin or shared child over copying its prompt/graph.
+  - Do not force-fit an installed workflow. When another graph better matches the task, write a task-specific TypeScript workflow inline. Rich custom workflows may use deterministic branching, dynamic fan-out, child workflows, artifacts, structured outputs, human-in-the-loop prompts, gates, retries, and explicit stop conditions.
+  - Before launching any workflow for a non-trivial task, perform a short workflow-architecture pass. Derive implementation lifecycle needs, whole-codebase research needs, independent slices, competing strategies, exact API/type/build contracts, schema or generated-artifact contracts, state transitions/lifecycle behavior, deterministic stop conditions, and required evidence. Use a compact internal coverage matrix: \`requirement/risk | required evidence | workflow/stage that produces it | gap\`. Add the topology row \`acyclic topology | node/edge sketch for branches and loops | architecture pass | unresolved back-edge\`. Unresolved material rows or back-edges must change the graph before launch.
+  - In that architecture pass, sketch each branch, loop, and nested workflow boundary. Identify which stages repeat, require distinct tracked work for every iteration, name the current frontier before each repeat, reject self-edges and ancestor edges, compose nested workflows through \`ctx.workflow(...)\` boundaries rather than recursive \`run\` invocation, and preserve stable per-iteration identity and call order for resume/replay.
+  - Compare candidate workflows by guarantees, not broad objectives: run one named workflow only when it covers the lifecycle and produces evidence for every material requirement/risk. A generic implementation workflow may cover the lifecycle without covering exact API/type/build contracts, schemas/generated artifacts, state transitions, or domain-specific gates. Do not treat "has reviewers" as proof that a task-specific risk is covered.
+  - Use these routing signals without adding decorative stages: broad repository uncertainty → Fan-out-and-synthesize with repository-focused branches; independent slices → Fan-out-and-synthesize; plausible-but-wrong contract risk → Adversarial verification or a task-specific verification stage; competing architectures or implementations → Generate-and-filter or Tournament; an explicit repeat-until condition → Loop until done; implementation lifecycle → a task-specific worker/reviewer loop; exact API/build/schema requirements → dedicated deterministic gates.
+  - For a request containing several implementation items, enumerate every item before launch and classify it as independent, dependent, or clustered. Inspect stated issue/PR/branch dependencies, whether prerequisites are already merged into each selected base, and likely shared files, API contracts, migrations, generated artifacts, decisions, approvals, and release effects.
+  - Do not infer a cross-item sequence from list order or from "create a PR after" when "after" naturally refers to that item's own implementation/review/check/PR lifecycle. Prove the dependency before serializing independent workflow items; if a material dependency remains unclear after research, ask one grouped clarification.
+  - Run independent implementation items as separate concurrent top-level named workflow runs with bounded concurrency. Give each item its own explicitly supported worktree path, branch, run ID, root lifecycle, and failure boundary, then report an item → run ID → worktree → branch → result/PR map. Compose or sequence only real dependencies; run independent clusters in parallel and preserve ordering inside each cluster.
+  - For a mixed queue with dependent A → B and unrelated C, compose only the A → B dependency cluster. Launch C as its own concurrent top-level named workflow with its own root failure boundary. One real cross-item dependency does not put the whole queue in one parent.
+  - A first item's review, repair, or check failure must not block unrelated items. Keep other top-level runs active, report the failed item separately, and fill an open dispatcher slot when policy permits. Several worktrees inside one sequential root provide checkout isolation, not concurrent top-level execution or independent root failure boundaries.
+  - A first named workflow launch commits the selected execution shape for the turn. For one task, end after the single launch. For an independent queue, issue the complete bounded wave of planned per-item top-level launches before ending the turn; do not casually chain unplanned unrelated launches. Each top-level run keeps an independent root lifecycle and failure boundary. When one task needs multiple capabilities or one dependency cluster needs ordered handoffs, design one custom parent before launch for that task or cluster, import reusable project/package definitions or builtins from \`@bastani/workflows/builtin\`, and compose them with \`ctx.workflow(childDefinition, { inputs, stageName })\`. Keep unrelated queue items out of that parent. Imported children may nest more workflows up to \`maxDepth\`; their stages, HIL prompts, control, durability, and declared outputs remain part of the expanded parent graph and root failure boundary. Pass definitions, not registry-name strings or paths.
+  - Workflow definitions are normal TypeScript modules. Composition examples: nest \`fanOutAndSynthesize\` for repository mapping; wrap \`openClaudeDesign\` with project-specific approval/export stages; or build a reusable user-defined research child and import it into several parent workflows. Map typed inputs and consume only declared outputs.
+  - When plausible-but-wrong behavior is a material risk in an arbitrary task-specific workflow, prefer a bounded evidence-backed adversarial loop. Give a fresh-context grumpy/skeptical-but-fair reviewer the literal objective and require actionable, evidence-backed falsification probes without invented requirements. Have it emit a structured verifier plan containing each exact probe, inputs, command/assertion, expected success condition, and requirement/risk covered.
+  - Support both verifier shapes: for explicit known contracts, author direct task-specific \`ctx.tool(...)\` gates before launch; for risks requiring adversarial discovery, let the model select high-value probes through structured output, then execute the selected compile, test, schema generation/validation, runtime, or artifact-inspection checks authoritatively through durable \`ctx.tool(...)\` calls. Actual tool results—not model self-report—must feed skeptical evaluation, consolidated evidence-backed repair findings, and reruns after the implementation child repairs them.
+  - Define bounded pass, repair, failure, and iteration-limit conditions before launch. Use \`ctx.tool\` for workflow-owned external checks and side effects whose results should be durably checkpointed. Each \`ctx.tool\` call is tracked as a durable, non-chat graph node and may run before, between, after, or without model stages; a tool-only workflow is valid tracked execution; keep pure transformations as ordinary TypeScript, and do not wrap every model-stage action in a tool call.
+  - Choose the cheapest graph that covers every material coverage row. Avoid decorative composition and duplicated research or review loops. Prefer composing a proven builtin or shared child over copying its prompt/graph.
+  - Before the first launch, state the selected graph, why one broad builtin is sufficient or insufficient, the evidence each major stage produces, and the stop/repair conditions. A simple direct match may use one sentence; a composed graph must briefly name its children and task-specific gates. For a custom adversarial loop, also name the skeptical reviewer, deterministic \`ctx.tool\` verifier gates, how model-selected plans become tool executions, and how failures reach bounded repair.
   - Example custom shapes: classify a request and dispatch category-specific stages; fan out per package and synthesize artifact-backed results; implement, run fresh-context verifiers, reduce findings, and loop through repairs until approved; generate several plans and filter or tournament-rank them; or rerun checks and fixes until green with a progress ledger and max-iteration escape hatch.
   - Budget reconnaissance: once workflow fit is clear, keep pre-workflow exploration to a few quick reads that sharpen the objective and validation criteria. Put deep research, upstream/design comparison, and behavior probing inside the workflow. Pass large context through files/artifacts and \`reads\` rather than injecting it into prompts.
   - Course-correct instead of drifting: after roughly ten exploratory tool calls with no artifact, edit, or commit, or repeated "let me verify one more thing" loops, stop, write findings to a context file, and hand the task to the best-fit named or custom workflow. Sunk inline research transfers through files; it is not a reason to stay inline.
@@ -25,16 +38,21 @@ export const DEFAULT_PROMPT_GUIDANCE: string[] = [
   `**Workflow discovery and lifecycle**:
   - For unfamiliar named workflows, discover with \`action: "list"\`, inspect with \`action: "get"\` or \`action: "inputs"\`, and run with \`action: "run"\`, \`workflow\`, and validated \`inputs\`; do not invent workflow names or input keys.
   - In interactive chat, named workflow launches run in the background. Run \`/workflow connect <run>\` to see agents working and chat with and steer each stage. Inspection and control calls (\`status\`, \`stages\`, \`stage\`, \`transcript\`, \`send\`, \`pause\`, \`resume\`, \`interrupt\`, \`quit\`) remain available while work runs.
-  - Natural-language instructions to create or use a worktree do not enable runner isolation. A named workflow must declare and implement any worktree inputs it supports; inspect its inputs before launching it.
-  - Once you run a workflow, end the current turn and wait for user input or a lifecycle notice. Do not use sleep/status polling loops: key start, finish, and failure events arrive automatically. Use targeted \`status\`/\`stages\`/\`stage\` checks only when the user asks or the next step needs them, and use \`send\`/\`pause\`/\`resume\`/\`interrupt\`/\`quit\` only to answer, steer, or honor control requests.
+  - \`workflow send\` is nonterminal-only: once the authoritative root run has completed, failed, skipped, been cancelled or killed, or ended terminal-blocked, start a new workflow if tracked work remains. Proceed inline only when the remaining task is small, deterministic, and low risk. Use explicit \`/workflow attach <run> <stage>\` for user-driven post-mortem chat; it does not resume or modify workflow execution.
+  - Natural-language instructions to create or use a worktree do not enable runner isolation. A named workflow must declare and implement any worktree and feature-branch inputs it supports; inspect its inputs and pass a distinct path and branch for each concurrent item. Reusable \`baseBranch\` binding creates a missing target as a detached checkout from that base or reuses an existing same-repository worktree as-is; neither case checks out a separate feature-branch input.
+  - Once you have started the selected single run or every run in the selected bounded wave, end the current turn and wait for user input or lifecycle notices. Do not use sleep/status polling loops: key start, finish, and failure events arrive automatically. Use targeted \`status\`/\`stages\`/\`stage\` checks only when the user asks or the next step needs them, and use \`send\`/\`pause\`/\`resume\`/\`interrupt\`/\`quit\` only to answer, steer, or honor control requests.
   - For transcripts, avoid whole-file reads. Get \`sessionFile\`/\`transcriptPath\` from \`stages\` or \`stage\`, preserve the exact path and platform separators, search with \`rg\`/\`grep\`, and read small relevant ranges; use explicit \`tail\` or \`limit\` only for a bounded preview.`,
   `**Workflow authoring and handoffs**:
   - When a user asks to create or edit a workflow, clarify only unresolved requirements that materially affect its purpose, inputs, stages, handoffs, validation, success criteria, or starter pattern. Read the workflow docs/examples, implement the TypeScript definition with normal coding tools, reload it, and run representative test inputs before presenting it. Use the create-spec skill when it adds value; it is not mandatory when context is already sufficient.
   - When creating or editing a workflow that pins an explicit stage \`model\` or \`fallbackModels\`, consult \`packages/coding-agent/docs/models/model-selection.md\` for role-based recommendations, then call \`workflow({ action: "models" })\` to see the models actually present in the user's configured catalog. Use only the catalog's returned \`fullId\` values as model strings, and append a thinking suffix only when that exact level appears in the entry's \`availableThinkingLevels\`; treat an absent or empty \`availableThinkingLevels\` as no suffix support rather than inferring one. If a guide-recommended model for the role is unavailable, try another guide-recommended model that is present in the catalog. If no recommendation intersects with the catalog, leave the stage unpinned rather than inventing a substitute, and mention the limitation, asking the user only if the workflow requires an explicit model choice. If the catalog is empty, continue with unpinned stages, state that no configured models were returned, and do not fabricate model IDs. Do not inspect or infer credentials, environment variables, auth files, token validity, entitlements, or the reason a model is absent; \`isCurrent\` marks the active selection, not a quality recommendation.
   - Consult docs/workflows.md and its starter patterns (Classify-and-act, Fan-out-and-synthesize, Adversarial verification, Generate-and-filter, Tournament, and Loop until done) when designing a stage graph.
   - Treat workflow composition as a first-class authoring option. Before duplicating stages, inspect reusable workflow modules and builtin exports; import their definitions and invoke them with \`ctx.workflow(...)\`, mapping typed inputs and consuming only declared outputs. Nested workflows can themselves import children, so combine small reusable graphs into a richer parent while respecting \`maxDepth\`.
-  - Unless the user requests otherwise, give each workflow invocation its own intercom group so stage and subagent chatter stays isolated from the parent chat and from other concurrent runs. When authoring a workflow, mint one invocation-scoped literal group name inside the run function (for example \`const group = "myflow-" + randomUUID();\` from \`node:crypto\`) and pass it via the \`group\` option on each stage, task, or parallel step that should share it; \`group: true\` (or the \`"auto"\` sentinel) mints one shared UUID group per \`ctx.parallel(...)\` set but a fresh UUID per non-parallel stage, so it isolates stages from each other rather than grouping the whole run. Ungrouped sessions all share the \`"default"\` group, so launching without a group lets cross-run intercom traffic reach the parent chat. Subagents inherit their launching stage's group, group assignment is skipped for stages without intercom access, and \`contact_supervisor\` still crosses group boundaries for escalation.
-  - Prefer \`ctx.tool(name, args, fn)\` for workflow-owned TypeScript operations with side effects, such as filesystem writes, network mutations, and external API actions. A completed \`ctx.tool\` call is durably checkpointed with its serializable result, so resume replays that result without rerunning \`fn\`. Keep pure computation and side-effect-free transformations as ordinary TypeScript. Do not wrap agent-stage internals or every function call indiscriminately; this rule applies to side effects orchestrated directly by the workflow definition.
+  - Atomic \`workflow({ run })\` definitions are imperative, dynamic TypeScript. Discovery validates module loading, imports, and definition shape, including schemas and the \`run\` function, but it does not compile \`run\` into a complete graph or prove acyclicity. Runtime inputs, branches, loops, files, network data, model or human output, helpers, and nested workflows determine the materialized graph during execution.
+  - Cyclic workflow graphs are unsupported. Workflow authors and coding agents MUST NOT create self-edges or dependency edges from the current frontier to an existing ancestor. Every materialized execution topology must remain a DAG. Redesign or stop before launch if a cycle cannot be removed.
+  - Bounded loops must create distinct tracked work for every iteration; never reopen an ancestor below its downstream work. If a retained session receives follow-up without new dependency work, keep it as non-topological activity metadata rather than adding a back-edge. Before launch, sketch nodes and dependencies for every branch and loop and reject any proposed parent edge to the node itself or an ancestor.
+  - Treat dynamic graph validation during execution, replay, and DBOS hydration as the authoritative cycle boundary. If runtime topology code changes, require incremental edge checks and DBOS hydration validation; prompt guidance and TypeScript types cannot replace those runtime checks.
+  - Every workflow invocation automatically receives one stable, non-default Intercom group. Intercom-capable stages inherit it, nested workflows keep the top-level invocation group, and subagents inherit their launching stage's group. Do not mint or thread group names through ordinary workflow definitions. Use an explicit \`group\` only for an intentional override: a named group or \`group: true\` creates a subgroup, while \`group: "default"\` opts into the shared default group. Stages without Intercom access receive no group, and \`contact_supervisor\` still crosses group boundaries for authorized escalation.
+  - Prefer \`ctx.tool(name, args, fn)\` for workflow-owned TypeScript operations with side effects, such as filesystem writes, network mutations, and external API actions. It creates a tracked, non-attachable durable graph node before invoking \`fn\`; it may be used before, between, after, or without model stages. A completed \`ctx.tool\` call is durably checkpointed with its serializable result, so resume replays that result without rerunning \`fn\`. For checks that may fail during a bounded repair loop, opt into \`failureMode: "return"\`, branch on the typed outcome, and pass only the needed error fields to the repair stage or artifact yourself; Atomic does not inject failure evidence into later prompts. Cancellation and storage faults still throw. Keep pure computation and side-effect-free transformations as ordinary TypeScript. Do not wrap agent-stage internals or every function call indiscriminately; this rule applies to side effects orchestrated directly by the workflow definition.
   - Pass large stage context through files/artifacts and \`reads\` with an explicit \`Read the file at <path>...\` prompt rather than large \`previous\` payloads or injected session history.
   - Separate implementation/review acceptance from explicitly authorized final actions such as PR/MR/review creation, release tagging, deployment, or publication. Stop implementation loops once acceptance is proven and carry a remaining final action separately.
   - A model stage sees its local prompt, artifacts, tools, and reads, not the graph name or surrounding implementation. State the concrete action, evidence, and success criteria directly.`,

package/dist/builtin/workflows/src/extension/workflow-status-summary.ts

@@ -20,6 +20,7 @@ import type {
   StageInputRequest,
   StageSnapshot,
   StageStatus,
+  ToolNodeStatus,
 } from "../shared/store-types.js";
 import { effectiveRunStatus } from "../shared/returned-run-status.js";
 import { elapsedRunMs } from "../shared/timing.js";
@@ -53,6 +54,26 @@ export interface WorkflowStatusAwaitingInput {
   readonly message?: string;
 }
 
+/** Non-chat durable tool-node status included additively in run summaries. */
+export interface WorkflowStatusToolNode {
+  readonly id: string;
+  readonly name: string;
+  readonly status: ToolNodeStatus;
+  readonly ordinal: number;
+  readonly executionOrder?: number;
+  readonly parentIds: readonly string[];
+  readonly startedAt?: number;
+  readonly endedAt?: number;
+  readonly replayed?: boolean;
+  readonly resultSummary?: string;
+  readonly error?: string;
+  readonly attachable: false;
+  /** Owning run identity; emitted for summaries, optional for source compatibility. */
+  readonly runId?: string;
+  readonly runName?: string;
+  readonly depth?: number;
+}
+
 /**
  * Concise, JSON-stable summary of one top-level run for the `status`
  * listing. `runId` feeds pause/resume/interrupt/quit/send directly;
@@ -70,6 +91,8 @@ export interface WorkflowRunStatusSummary {
   /** Pause-adjusted elapsed milliseconds (prior sessions included). */
   readonly elapsedMs: number;
   readonly activeStages: readonly WorkflowStatusActiveStage[];
+  /** Durable, non-attachable ctx.tool graph nodes in authored order. */
+  readonly tools?: readonly WorkflowStatusToolNode[];
   readonly awaitingInputCount: number;
   readonly awaitingInput: readonly WorkflowStatusAwaitingInput[];
   readonly exitReason?: string;
@@ -146,6 +169,26 @@ export function summarizeRunSnapshot(
       name: stage.name,
       status: stage.status,
     })),
+    tools: (run.toolNodes ?? []).map((tool) => {
+      const owner = tool as typeof tool & { readonly runId?: string; readonly runName?: string; readonly depth?: number };
+      return {
+        id: tool.id,
+        name: tool.name,
+        status: tool.status,
+        ordinal: tool.ordinal,
+        executionOrder: tool.executionOrder,
+        parentIds: [...tool.parentIds],
+        startedAt: tool.startedAt,
+        endedAt: tool.endedAt,
+        replayed: tool.replayed,
+        resultSummary: tool.resultSummary,
+        error: tool.error,
+        attachable: false,
+        runId: owner.runId ?? run.id,
+        runName: owner.runName ?? run.name,
+        depth: owner.depth ?? 0,
+      };
+    }),
     awaitingInputCount: awaitingInput.length,
     awaitingInput,
     exitReason: run.exitReason,

package/dist/builtin/workflows/src/extension/workflow-targets.ts

@@ -1,7 +1,12 @@
 import { getEnvValue, WORKFLOW_STAGE_SUBAGENT_GUARD_ENV } from "@bastani/atomic";
 import type { RunStatus } from "../shared/store-types.js";
 import { store } from "../shared/store.js";
-import { expandWorkflowGraph, expandedStageLabel, stageMatchesExpandedIdentifier } from "../shared/expanded-workflow-graph.js";
+import {
+  expandWorkflowGraph,
+  expandedStageLabel,
+  stageMatchesExpandedIdentifier,
+  type ExpandedWorkflowStage,
+} from "../shared/expanded-workflow-graph.js";
 import { topLevelWorkflowRuns } from "../shared/run-visibility.js";
 import type { OverlayPiSurface } from "../tui/overlay-adapter.js";
 import type { PiExecuteContext } from "./public-types.js";
@@ -35,10 +40,14 @@ export function inFlightRunCount(): number {
 
 export function topLevelExpandedSnapshots() {
   const snapshot = store.snapshot();
-  return topLevelWorkflowRuns(snapshot.runs).map((run) => ({
-    ...structuredClone(run),
-    stages: expandWorkflowGraph(snapshot, run.id).stages.map((stage) => structuredClone(stage)),
-  }));
+  return topLevelWorkflowRuns(snapshot.runs).map((run) => {
+    const graph = expandWorkflowGraph(snapshot, run.id);
+    return {
+      ...structuredClone(run),
+      stages: graph.stages.map((stage) => structuredClone(stage)),
+      toolNodes: graph.tools.map((tool) => structuredClone(tool)),
+    };
+  });
 }
 
 
@@ -119,34 +128,22 @@ export function resolveStageTarget(runId: string, stageTarget?: string): ToolSta
   const target = stageTarget?.trim();
   if (!target) return { ok: true, runId };
   const graph = expandWorkflowGraph(store.snapshot(), runId);
-  const exactId = graph.stages.find(
-    (stage) => stage.id === target || stage.workflowGraphTarget.stageId === target,
-  );
-  if (exactId !== undefined) {
-    return {
-      ok: true,
-      runId: exactId.workflowGraphTarget.runId,
-      stageId: exactId.workflowGraphTarget.stageId,
-    };
-  }
+  const exactVirtualIds = graph.stages.filter((stage) => stage.id === target);
+  if (exactVirtualIds.length === 1) return resolvedStageTarget(exactVirtualIds[0]!);
+  if (exactVirtualIds.length > 1) return ambiguousStageTarget(target, exactVirtualIds);
+  const exactLocalIds = graph.stages.filter((stage) => stage.workflowGraphTarget.stageId === target);
+  if (exactLocalIds.length === 1) return resolvedStageTarget(exactLocalIds[0]!);
+  if (exactLocalIds.length > 1) return ambiguousStageTarget(target, exactLocalIds);
   const exactNames = graph.stages.filter((stage) => stage.name === target);
-  if (exactNames.length === 1) {
-    const stage = exactNames[0]!;
-    return {
-      ok: true,
-      runId: stage.workflowGraphTarget.runId,
-      stageId: stage.workflowGraphTarget.stageId,
-    };
-  }
-  if (exactNames.length > 1) {
-    return { ok: false, message: `Ambiguous stage identifier "${target}" matches: ${exactNames.map(expandedStageLabel).join(", ")}` };
-  }
+  if (exactNames.length === 1) return resolvedStageTarget(exactNames[0]!);
+  if (exactNames.length > 1) return ambiguousStageTarget(target, exactNames);
   const matches = graph.stages.filter((stage) => stageMatchesExpandedIdentifier(stage, target));
   if (matches.length === 0) return { ok: false, message: `Stage not found in run ${runId.slice(0, 8)}: ${target}` };
-  if (matches.length > 1) {
-    return { ok: false, message: `Ambiguous stage identifier "${target}" matches: ${matches.map(expandedStageLabel).join(", ")}` };
-  }
-  const stage = matches[0]!;
+  if (matches.length > 1) return ambiguousStageTarget(target, matches);
+  return resolvedStageTarget(matches[0]!);
+}
+
+function resolvedStageTarget(stage: ExpandedWorkflowStage): ToolStageTarget {
   return {
     ok: true,
     runId: stage.workflowGraphTarget.runId,
@@ -154,6 +151,13 @@ export function resolveStageTarget(runId: string, stageTarget?: string): ToolSta
   };
 }
 
+function ambiguousStageTarget(target: string, stages: readonly ExpandedWorkflowStage[]): ToolStageTarget {
+  return {
+    ok: false,
+    message: `Ambiguous stage identifier "${target}" matches: ${stages.map(expandedStageLabel).join(", ")}`,
+  };
+}
+
 export function resolveToolStageTarget(runId: string, stageTarget?: string): ToolStageTarget {
   return resolveStageTarget(runId, stageTarget);
 }

package/dist/builtin/workflows/src/extension/workflow-tool-content.ts

@@ -39,17 +39,24 @@ function truncateStatusText(text: string): string {
 }
 
 function statusRunHint(run: WorkflowRunStatusSummary): string | undefined {
+  const tools = run.tools ?? [];
+  const toolHint = tools.length > 0
+    ? `tools: ${tools.map((tool) => `${tool.name} (${tool.status})`).join(", ")}`
+    : undefined;
+  let primary: string | undefined;
   if (run.awaitingInputCount > 0) {
     const stages = run.awaitingInput
       .map((entry) => entry.stageName ?? entry.stageId)
       .filter((name): name is string => name !== undefined && name.length > 0);
     const suffix = stages.length > 0 ? `: ${stages.join(", ")}` : "";
-    return `awaiting input (${run.awaitingInputCount})${suffix}`;
-  }
-  if (run.status === "paused") return "awaiting resume";
-  if (run.activeStages.length > 0) {
-    return `stage: ${run.activeStages.map((stage) => stage.name).join(", ")}`;
+    primary = `awaiting input (${run.awaitingInputCount})${suffix}`;
+  } else if (run.status === "paused") {
+    primary = "awaiting resume";
+  } else if (run.activeStages.length > 0) {
+    primary = `stage: ${run.activeStages.map((stage) => stage.name).join(", ")}`;
   }
+  if (primary !== undefined) return toolHint === undefined ? primary : `${primary} · ${toolHint}`;
+  if (toolHint !== undefined) return toolHint;
   if (run.error !== undefined && run.error.length > 0) return truncateStatusText(run.error);
   if (run.exitReason !== undefined && run.exitReason.length > 0) {
     return truncateStatusText(run.exitReason);