@agent-native/core 0.84.35 → 0.84.36

package/corpus/core/docs/content/pure-agent-apps.mdx

@@ -1,27 +1,29 @@
 ---
-title: "Pure-Agent Apps"
-description: "Apps where the agent is the whole product: the app-agent loop is the front door, and UI is added only when humans need it."
+title: "Automation-First Apps"
+description: "No-browser Agent-Native apps for scheduled jobs, queues, scripts, integration workers, and external agents."
 ---
 
-# Pure-Agent Apps
+# Automation-First Apps
 
-A pure-agent app is the minimal end of agent-native: the app-agent loop is the
-product, not a dashboard. You send a request from the terminal, Slack, email, a
-scheduled job, another agent, or Chat — "summarize my unread emails," "post the
-daily metrics to Slack" — and the agent acts and returns the result wherever it
-belongs. It is still a real app: actions, sessions, app state, history,
-settings, credentials, and share records all live in SQL.
+Most Agent-Native products should start with chat and grow into inline results
+and durable app pages. Use this pattern when the primary surface is not a
+browser UI yet: scheduled reports, queues, integration workers, CLI loops, or
+another app or agent calling this app over MCP/A2A.
 
-<Diagram id="doc-block-1rfgtal" title="The app-agent loop is the front door" summary={"Many entry points reach one agent loop over SQL-backed actions and state; results return to wherever the request came from. UI is added only when humans need to supervise."}>
+Automation-first does **not** mean stateless. The app-agent loop still uses the
+same Agent-Native contract: actions, sessions, app state, history, settings,
+credentials, and share records live in SQL.
+
+<Diagram id="doc-block-automation-first" title="Automation-first still uses the app contract" summary={"Jobs, scripts, channels, and external agents reach one Agent-Native loop over SQL-backed actions and state."}>
 
 ```html
 <div class="diagram-pure">
   <div class="diagram-col">
-    <div class="diagram-pill">Terminal</div>
-    <div class="diagram-pill">Slack · email</div>
     <div class="diagram-pill">Scheduled job</div>
+    <div class="diagram-pill">Queue worker</div>
+    <div class="diagram-pill">CLI script</div>
+    <div class="diagram-pill">Slack · email</div>
     <div class="diagram-pill">Another agent (A2A)</div>
-    <div class="diagram-pill">Chat</div>
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
   <div class="diagram-panel center" data-rough>
@@ -30,7 +32,9 @@ settings, credentials, and share records all live in SQL.
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
   <div class="diagram-box" data-rough>
-    Result returns<br /><small class="diagram-muted">to where it belongs</small>
+    Result returns<br /><small class="diagram-muted"
+      >to the channel that asked</small
+    >
   </div>
 </div>
 ```
@@ -62,20 +66,36 @@ settings, credentials, and share records all live in SQL.
 </Diagram>
 
 Reach for this shape when the work runs in the background, the output leaves the
-app, the domain is one-shot, or you're prototyping. The agent still needs a UI —
-not a dashboard, but a place for humans to supervise, configure, and steer it —
-which is why even pure-agent apps usually mount the built-in Chat shell.
+app, the domain is one-shot, or you are building a callable workflow for another
+system. If users need to inspect, compare, correct, or share persistent objects,
+start with [Chat](/docs/template-chat) or add a small app page around the same
+actions.
+
+## Scaffold {#scaffold}
+
+Use the no-browser scaffold when you know you do not want a browser UI yet:
 
-This is the **headless** product shape. The full decision guide, what ships in
-the box, the scaffold, repo access, and run sharing now live in one place:
+```bash
+npx @agent-native/core@latest create my-agent --headless
+cd my-agent
+pnpm install
+```
+
+Then add actions and instructions exactly as you would in a chat app:
+
+```bash
+pnpm agent "Run the daily response-insights report and post the summary."
+```
 
-→ [**Agent Surfaces — Headless agent**](/docs/agent-surfaces#headless)
+The `--headless` flag only chooses the initial scaffold. It does not choose a
+different architecture. You can later move the same `actions/`, instructions,
+skills, and SQL state into a chat app or full application surface.
 
-## What's next
+## What to add next {#whats-next}
 
-- [**Agent Surfaces — Headless**](/docs/agent-surfaces#headless) — the full headless decision guide and APIs
-- [**Getting Started**](/docs/getting-started) — create a chat app or headless agent first
-- [**Dispatch**](/docs/template-dispatch) — the workspace template that's a great pure-agent starting point
-- [**Messaging the agent**](/docs/messaging) — how users talk to the agent across web, Slack, Telegram, email
+- [**Getting Started**](/docs/getting-started) — the chat-first tutorial from action to inline result to durable page
+- [**Agent Surfaces — Automation-first app**](/docs/agent-surfaces#headless) — the full decision guide and APIs
+- [**Actions**](/docs/actions) — the operations your automation calls
+- [**Messaging the agent**](/docs/messaging) — how users talk to the agent across web, Slack, Telegram, and email
 - [**Recurring Jobs**](/docs/recurring-jobs) — scheduled prompts the agent runs on its own
-- [**Actions**](/docs/actions) — the tools your pure-agent will call
+- [**Dispatch**](/docs/template-dispatch) — the workspace control plane for shared secrets, scheduled jobs, and delegated work

package/corpus/core/docs/content/template-chat.mdx

@@ -5,9 +5,9 @@ description: "A minimal chat-first agent-native app: durable chat threads, actio
 
 # Chat Template
 
-Chat is the basic agent-native app starting point. It gives you a clean ChatGPT-style shell with chat at the center, a threads list on the left, standard app navigation, auth, live sync, actions, and one example action. Start here when you want a real browser app you can build on without committing to a domain template.
+Chat is the basic agentic app starting point. It gives you a clean ChatGPT-style shell with chat at the center, a threads list on the left, standard app navigation, auth, live sync, actions, and one example action. Start here when you want a real browser app you can build on before committing to a domain template.
 
-If you want the smallest action-only runtime with no browser UI, start with [Pure-Agent Apps](/docs/pure-agent-apps). If you want a finished domain product shape, start from [Calendar](/docs/template-calendar), [Mail](/docs/template-mail), [Content](/docs/template-content), [Forms](/docs/template-forms), [Analytics](/docs/template-analytics), or another domain template.
+If you want a finished domain product shape, start from [Calendar](/docs/template-calendar), [Mail](/docs/template-mail), [Content](/docs/template-content), [Forms](/docs/template-forms), [Analytics](/docs/template-analytics), or another domain template. If you truly do not need a browser UI yet, see [Automation-First Apps](/docs/pure-agent-apps).
 
 <WireframeBlock id="doc-block-1qu69ww">
   <Screen
@@ -104,7 +104,7 @@ That's the point. Chat is a thin, useful default shell for your own agent, not a
 ## When to pick it {#when-to-pick}
 
 - **You want a basic app users can talk to immediately** and then extend with actions and UI.
-- **You have a headless app that needs chat** as the first browser surface.
+- **You want the default Agent-Native on-ramp**: chat first, then actions, native results, and app pages.
 - **You want to plug your own agent backend into a familiar chat UI** while keeping Agent-Native's actions, state, auth, and deployment shape.
 - **You are prototyping a custom internal tool** that does not match a domain template.
 
@@ -117,13 +117,13 @@ pnpm install
 pnpm dev
 ```
 
-Or start with no UI and add a chat surface later:
+The no-browser scaffold is still available for automation-first work, but it is not the main Chat template path:
 
 ```bash
 npx @agent-native/core@latest create my-agent --headless
 ```
 
-From there, copy the Chat template's `/` route and sidebar thread list into your app, or scaffold a Chat app and move the actions from your headless agent into its `actions/` directory. The key invariant stays the same: actions are the shared surface for chat, UI, HTTP, MCP, A2A, and CLI.
+Use it for scheduled jobs, queues, CLI loops, or external-agent workflows where chat and app pages are not useful yet. The key invariant stays the same: actions are the shared surface for chat, UI, HTTP, MCP, A2A, and CLI.
 
 ## First code to inspect {#first-code}
 
@@ -196,8 +196,8 @@ The agent should add a Drizzle schema, actions, route, navigation, and instructi
 
 ## What's next
 
-- [**Getting Started**](/docs) — choose between headless, chat, and domain templates
-- [**Agent Surfaces**](/docs/agent-surfaces) — headless, chat, embedded, and full-app patterns
+- [**Getting Started**](/docs) — build the chat-first path from action to inline result to app page
+- [**Agent Surfaces**](/docs/agent-surfaces) — chat, inline UI, app pages, embedded, automation, and external-agent patterns
 - [**Actions**](/docs/actions) — the action system chat and UI both call
 - [**Native Chat UI**](/docs/native-chat-ui) — chat surface primitives and runtime options
-- [**Pure-Agent Apps**](/docs/pure-agent-apps) — action-only apps that can grow into Chat later
+- [**Automation-First Apps**](/docs/pure-agent-apps) — no-browser workflows for jobs, queues, scripts, and external agents

package/corpus/core/docs/content/using-your-agent.mdx

@@ -99,7 +99,7 @@ The agent isn't a separate app you tab over to. It ships as a handful of React c
 
 Not every app needs a full dashboard. When the agent _is_ the product, you can skip most of the custom UI: open the app, ask for what you want, and let the agent do the rest. The agent still has its management surface — history, workspace, settings — but the primary interaction is conversation rather than clicks.
 
-→ [**Pure-Agent Apps**](/docs/pure-agent-apps) — apps where the agent is the whole product.
+→ [**Automation-First Apps**](/docs/pure-agent-apps) — no-browser apps for jobs, queues, scripts, and external agents.
 
 ## You co-edit with it {#you-co-edit}
 
@@ -113,5 +113,5 @@ When you and the agent are working on the same document, you don't take turns. W
 - [**Agent Mentions**](/docs/agent-mentions) — direct it with `@`-mentions
 - [**Voice Input**](/docs/voice-input) — direct it by speaking
 - [**Drop-in Agent**](/docs/drop-in-agent) — embed it in any React app
-- [**Pure-Agent Apps**](/docs/pure-agent-apps) — go UI-light when the agent is the product
+- [**Automation-First Apps**](/docs/pure-agent-apps) — use no-browser apps for jobs, queues, scripts, and external agents
 - [**Real-Time Collaboration**](/docs/real-time-collaboration) — co-edit the same document together

package/corpus/core/docs/content/what-is-agent-native.mdx

@@ -5,13 +5,13 @@ description: "Why most AI apps feel half-built, what makes an app truly agent-na
 
 # What Is Agent-Native?
 
-Agent-native is a way of building software where the AI agent and the product surface around it are **equal partners**. That surface can be a headless agent with one custom action, a rich chat, or a full UI. The important part is that agents and humans share the same actions, database, and state.
+Agent-native is a way of building software where the AI agent and the product surface around it are **equal partners**. The usual path starts with chat, adds typed actions, renders structured results inline, and grows into durable app pages around the same SQL state. The important part is that agents and humans share the same actions, database, and state.
 
 If you only remember one thing from this page, remember this: most AI apps today stop one step short of being useful, and that gap is the biggest mistake in the space right now.
 
 ## What it looks like as a user {#what-it-looks-like}
 
-Picture a background worker, inbox, calendar, form builder, or analytics dashboard. Sometimes there is no custom screen yet: you run one action or one headless app-agent prompt. Sometimes the first screen is chat: you ask what you want, the agent guides setup, shows a table or chart, and opens the right app view. Sometimes chat is docked on the right side of a full application. Across those shapes, you can:
+Picture a background worker, inbox, calendar, form builder, or analytics dashboard. Often the first screen is chat: you ask what you want, the agent guides setup, shows a table or chart, and opens the right app view. Sometimes chat is docked on the right side of a full application. Sometimes there is no custom screen yet because the workflow is a scheduled job, queue, script, or external-agent integration. Across those shapes, you can:
 
 - **Start with the real operation.** One durable action can run from the CLI, HTTP, MCP, A2A, the app-agent loop, and later a UI.
 - **Click anything you'd normally click when there is a UI.** All the buttons, lists, dashboards, keyboard shortcuts — they all call the same operations the agent can call.
@@ -116,7 +116,7 @@ Even when the agent does all the heavy lifting, humans still need to:
 
 At minimum, "a UI for the agent" is an observability and management dashboard. At maximum, it's a full SaaS app with the agent embedded as a co-pilot. Both ends count as agent-native, and the surface can grow from one without a rewrite.
 
-You don't have to choose a shape up front. The agent can run headless, sit behind a rich chat, or live inside a full application around the same action surface — see [Agent Surfaces](/docs/agent-surfaces) for the concrete shapes and APIs.
+You don't have to choose every surface up front. The agent can start in rich chat, render native inline UI, live inside a full application, or run from automation and external-agent channels around the same action surface — see [Agent Surfaces](/docs/agent-surfaces) for the concrete shapes and APIs.
 
 ## Why every app benefits from an agent {#why-every-app-benefits-from-an-agent}
 
@@ -124,7 +124,7 @@ The flip side is just as important. Existing SaaS products keep hitting the same
 
 Agent-native flips that. Because every action in the app is defined once and exposed as both a button and an agent tool, the agent can do everything the buttons can — and more — without a separate "AI world" to maintain. Natural language becomes a first-class input alongside clicks.
 
-The argument isn't "agents replace UI." It's "**agents belong inside applications, with a UI on top, as equal partners**." Even an app where the agent _is_ the product still needs a UI for humans to supervise, configure, and steer it — see [Agent Surfaces — Headless](/docs/agent-surfaces#headless).
+The argument isn't "agents replace UI." It's "**agents belong inside applications, with a UI on top, as equal partners**." Even an automation-first app still needs some surface for humans to supervise, configure, and steer it — usually chat, a job history, or a small status page. See [Agent Surfaces — Automation-first app](/docs/agent-surfaces#headless).
 
 ## Agent + UI parity {#agent-ui-parity}
 
@@ -394,8 +394,8 @@ One action, many surfaces: the agent calls it as a tool, the UI calls it as a ty
 
 ## What's next {#whats-next}
 
-- [**Getting Started**](/docs/getting-started) — start with one action, pick a template, or install a skill
-- [**Agent Surfaces**](/docs/agent-surfaces) — choose headless, rich chat, embedded sidecar, or full app
+- [**Getting Started**](/docs/getting-started) — start with chat, add an action, render a native result, and grow into a page
+- [**Agent Surfaces**](/docs/agent-surfaces) — choose chat, native inline UI, full app pages, embedded sidecar, automation, or external agent access
 - [**Key Concepts**](/docs/key-concepts) — the architecture: SQL, actions, polling sync, context awareness, portability
 - [**Templates**](/docs/cloneable-saas) — templates as complete products you own
 - [**Workspace**](/docs/workspace) — the per-user customization layer (skills, memory, instructions, MCP) backed by SQL, not files

package/corpus/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.84.35",
+  "version": "0.84.36",
   "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {

package/corpus/core/src/cli/skills.ts

@@ -762,15 +762,13 @@ background, text, border, ring, fill, stroke, gradient, placeholder, decoration,
 or shadow color, rewrite it to renderer tokens or remove it. Layout-only classes
 are still discouraged; inline flex/grid styles are safer and easier to review.
 
-**Keep Rough.js sparse.** \`.wf-card\` and \`.wf-box\` already render with
-theme-safe filled backgrounds (\`--wf-card\`) and soft tokenized borders that work
-in both light and dark mode. Do not add \`data-rough\` to broad root wrappers,
-dialog shells, page panels, grid cells, or nested containers unless that single
-container is the visual point. The renderer sketches the outer frame and
-standard controls by default; use \`data-rough\` only for a deliberate one-off
-shape. If a mockup starts looking like stacked/overlapping sketch lines, remove
-rough targets from parent containers and let backgrounds plus spacing separate
-the surfaces.
+**Keep Rough.js sparse.** The renderer sketches the outer frame, standard
+\`.wf-*\` primitives, controls, and inline border dividers by default. Do not add
+\`data-rough\` to broad root wrappers, dialog shells, page panels, grid cells, or
+nested containers unless that single container is the visual point. Use
+\`data-rough\` only for a deliberate one-off shape. If a mockup starts looking
+like stacked/overlapping sketch lines, remove rough targets from parent
+containers and let backgrounds plus spacing separate the surfaces.
 
 **Use literal CSS lengths for spacing.** The \`--wf-*\` tokens are for colors and
 renderer-owned visual styling, not layout spacing. Do not use guessed spacing

package/corpus/core/src/client/MultiTabAssistantChat.tsx

@@ -2685,6 +2685,8 @@ export function MultiTabAssistantChat({
                 <RunStuckBanner
                   threadId={tabId}
                   apiUrl={apiUrl}
+                  autoRetry
+                  autoRetryOwnerId={browserTabId}
                   onRetry={() => {
                     const handle = chatRefs.current.get(tabId);
                     handle?.sendRecoveryMessage(

package/corpus/core/src/client/RunStuckBanner.tsx

@@ -38,21 +38,119 @@ export interface RunStuckBannerProps {
    * observability events (Sentry, PostHog) at the call site.
    */
   onStuckStateChange?: (state: RunStuckState) => void;
+  /**
+   * Automatically abort and retry once when the server reports a run is
+   * alive but has stopped making real progress. Manual controls remain visible
+   * as the fallback if the automatic recovery cannot clear the run.
+   */
+  autoRetry?: boolean;
+  /**
+   * Stable browser-tab/window id used to coordinate automatic retries across
+   * multiple mounted chat views for the same thread. A local id is generated
+   * when omitted.
+   */
+  autoRetryOwnerId?: string;
   /** Extra class on the outer container. */
   className?: string;
 }
 
+const AUTO_RETRY_CLAIM_TTL_MS = 5 * 60 * 1000;
+
+type BusyState = { type: "none" } | { type: "cancel" | "retry"; runId: string };
+
+type MaybeLockManager = {
+  request<T>(
+    name: string,
+    options: { mode?: "exclusive" | "shared"; ifAvailable?: boolean },
+    callback: (lock: unknown) => T | Promise<T>,
+  ): Promise<T>;
+};
+
+function createAutoRetryOwnerId() {
+  const cryptoApi =
+    typeof crypto !== "undefined" && typeof crypto.randomUUID === "function"
+      ? crypto
+      : null;
+  return cryptoApi?.randomUUID() ?? `owner-${Math.random().toString(36)}`;
+}
+
+function autoRetryClaimKey(threadId: string, runId: string) {
+  return `agent-native:stuck-auto-retry:${threadId}:${runId}`;
+}
+
+function markAutoRetryClaim(key: string, ownerId: string) {
+  if (typeof window === "undefined") return true;
+  const now = Date.now();
+  try {
+    const raw = window.localStorage.getItem(key);
+    if (raw) {
+      const existing = JSON.parse(raw) as {
+        ownerId?: unknown;
+        expiresAt?: unknown;
+      };
+      const expiresAt =
+        typeof existing.expiresAt === "number" ? existing.expiresAt : 0;
+      if (expiresAt > now && existing.ownerId !== ownerId) return false;
+    }
+    window.localStorage.setItem(
+      key,
+      JSON.stringify({ ownerId, expiresAt: now + AUTO_RETRY_CLAIM_TTL_MS }),
+    );
+    const confirmed = JSON.parse(window.localStorage.getItem(key) ?? "{}") as {
+      ownerId?: unknown;
+    };
+    return confirmed.ownerId === ownerId;
+  } catch {
+    // Private browsing or disabled storage: fall back to in-tab retry. The
+    // server abort is idempotent, and manual controls remain available.
+    return true;
+  }
+}
+
+async function claimAutoRetryAttempt(
+  threadId: string | null | undefined,
+  runId: string,
+  ownerId: string,
+) {
+  if (!threadId) return true;
+  const key = autoRetryClaimKey(threadId, runId);
+  const locks =
+    typeof navigator !== "undefined"
+      ? (navigator as Navigator & { locks?: MaybeLockManager }).locks
+      : undefined;
+  if (locks?.request) {
+    try {
+      return await locks.request(
+        key,
+        { mode: "exclusive", ifAvailable: true },
+        (lock) => (lock ? markAutoRetryClaim(key, ownerId) : false),
+      );
+    } catch {
+      return markAutoRetryClaim(key, ownerId);
+    }
+  }
+  return markAutoRetryClaim(key, ownerId);
+}
+
 export function RunStuckBanner({
   threadId,
   apiUrl,
   stuckThresholdMs,
   onRetry,
   onStuckStateChange,
+  autoRetry = false,
+  autoRetryOwnerId,
   className,
 }: RunStuckBannerProps) {
   const state = useRunStuckDetection({ threadId, stuckThresholdMs, apiUrl });
   const abortRun = useAbortRun(apiUrl);
-  const [busy, setBusy] = useState<"none" | "cancel" | "retry">("none");
+  const [busy, setBusy] = useState<BusyState>({ type: "none" });
+  const autoRetriedRunIdsRef = useRef<Set<string>>(new Set());
+  const generatedOwnerIdRef = useRef<string | null>(null);
+  if (!generatedOwnerIdRef.current) {
+    generatedOwnerIdRef.current = createAutoRetryOwnerId();
+  }
+  const ownerId = autoRetryOwnerId ?? generatedOwnerIdRef.current;
 
   const lastReportedRef = useRef<{
     isStuck: boolean;
@@ -77,39 +175,92 @@ export function RunStuckBanner({
     }
   }, [state, onStuckStateChange, threadId]);
 
-  // Reset the busy spinner once the underlying run has flipped away from
-  // running — no need to keep showing a stale "Retrying…" indicator.
+  // Reset the busy spinner once the underlying run is no longer the one we
+  // acted on. A recovery continuation can start quickly enough that polling
+  // never observes an idle state between run ids.
   useEffect(() => {
-    if (state.status !== "running") {
-      setBusy("none");
+    setBusy((current) => {
+      if (current.type === "none") return current;
+      if (state.status !== "running") return { type: "none" };
+      if (state.runId && state.runId !== current.runId) return { type: "none" };
+      return current;
+    });
+  }, [state.runId, state.status]);
+
+  useEffect(() => {
+    if (
+      !autoRetry ||
+      !state.isStuck ||
+      !state.runId ||
+      busy.type !== "none" ||
+      autoRetriedRunIdsRef.current.has(state.runId)
+    ) {
+      return;
     }
-  }, [state.status]);
+
+    const runId = state.runId;
+    void claimAutoRetryAttempt(threadId, runId, ownerId).then((claimed) => {
+      autoRetriedRunIdsRef.current.add(runId);
+      if (!claimed) return;
+      setBusy({ type: "retry", runId });
+      trackEvent("agent_chat_stuck_auto_retry", {
+        runId,
+        threadId: threadId ?? null,
+        stuckSinceMs: state.stuckSinceMs ?? null,
+      });
+      void abortRun(runId, "auto_stuck_retry").then((aborted) => {
+        if (aborted) {
+          onRetry?.(aborted);
+          return;
+        }
+        setBusy((current) =>
+          current.type !== "none" && current.runId === runId
+            ? { type: "none" }
+            : current,
+        );
+      });
+    });
+  }, [
+    abortRun,
+    autoRetry,
+    busy,
+    onRetry,
+    ownerId,
+    state.isStuck,
+    state.runId,
+    state.stuckSinceMs,
+    threadId,
+  ]);
 
   if (!state.isStuck || !state.runId) return null;
 
   const handleCancel = async () => {
-    if (!state.runId || busy !== "none") return;
-    setBusy("cancel");
+    if (!state.runId || busy.type !== "none") return;
+    const runId = state.runId;
+    setBusy({ type: "cancel", runId });
     trackEvent("agent_chat_stuck_cancel", {
-      runId: state.runId,
+      runId,
       threadId: threadId ?? null,
       stuckSinceMs: state.stuckSinceMs ?? null,
     });
-    await abortRun(state.runId, "user_stuck_cancel");
+    await abortRun(runId, "user_stuck_cancel");
   };
 
   const handleRetry = async () => {
-    if (!state.runId || busy !== "none") return;
-    setBusy("retry");
+    if (!state.runId || busy.type !== "none") return;
+    const runId = state.runId;
+    setBusy({ type: "retry", runId });
     trackEvent("agent_chat_stuck_retry", {
-      runId: state.runId,
+      runId,
       threadId: threadId ?? null,
       stuckSinceMs: state.stuckSinceMs ?? null,
     });
-    const aborted = await abortRun(state.runId, "user_stuck_retry");
+    const aborted = await abortRun(runId, "user_stuck_retry");
     if (aborted) onRetry?.(aborted);
   };
 
+  const busyType = busy.type;
+
   const stuckSeconds =
     state.stuckSinceMs != null ? Math.floor(state.stuckSinceMs / 1000) : null;
 
@@ -134,16 +285,19 @@ export function RunStuckBanner({
             No progress
             {stuckSeconds != null ? ` for ${stuckSeconds}s` : ""}. The agent may
             have hit a server timeout or lost its connection.
+            {autoRetry && busyType === "retry"
+              ? " Retrying automatically now."
+              : ""}
           </span>
         </div>
         <div className="flex flex-wrap items-center gap-2">
           <button
             type="button"
             onClick={handleRetry}
-            disabled={busy !== "none"}
+            disabled={busyType !== "none"}
             className="inline-flex h-7 cursor-pointer items-center gap-1.5 rounded-md bg-foreground px-2.5 text-[11px] font-medium text-background transition-colors hover:bg-foreground/90 disabled:cursor-not-allowed disabled:opacity-60"
           >
-            {busy === "retry" ? (
+            {busyType === "retry" ? (
               <IconLoader2
                 size={12}
                 className="animate-spin"
@@ -155,10 +309,10 @@ export function RunStuckBanner({
           <button
             type="button"
             onClick={handleCancel}
-            disabled={busy !== "none"}
+            disabled={busyType !== "none"}
             className="inline-flex h-7 cursor-pointer items-center gap-1.5 rounded-md border border-border bg-background px-2.5 text-[11px] font-medium text-foreground transition-colors hover:bg-accent disabled:cursor-not-allowed disabled:opacity-60"
           >
-            {busy === "cancel" ? (
+            {busyType === "cancel" ? (
               <IconLoader2
                 size={12}
                 className="animate-spin"

package/corpus/core/src/client/blocks/library/wireframe-kit.tsx

@@ -26,10 +26,10 @@ import type {
  * DECOUPLING: the only behavioral change from the plan copy is theme detection —
  * core blocks read `document.documentElement.classList.contains("dark")` (the
  * MermaidBlock precedent) instead of importing `next-themes`. Everything else
- * (the `.plan-wf` / `[data-rough]` class contract the rough overlay measures,
- * the `--wf-*` / `--ink` / `--paper` token names every primitive reads) is
- * preserved exactly, so the kit looks identical in plan and renders correctly in
- * any app once the matching tokens exist in `core/styles/blocks.css`.
+ * (the `.plan-wf` / `.wf-*` / `[data-rough]` class contract the rough overlay
+ * measures, the `--wf-*` / `--ink` / `--paper` token names every primitive
+ * reads) is preserved exactly, so the kit looks identical in plan and renders
+ * correctly in any app once the matching tokens exist in `core/styles/blocks.css`.
  */
 
 /* ========================================================================== */
@@ -211,7 +211,7 @@ export function Screen({
         // clipping. The frame shell (`ArtboardFrame`) owns the height policy; a
         // caller can still override via `style.height` for a fixed canvas.
         minHeight: "100%",
-        background: V.paper,
+        background: "transparent",
         color: V.ink,
         fontFamily: V.hand,
         fontSize: V.fs,
@@ -1425,9 +1425,9 @@ const gen = rough.generator();
 
 type RoughPath = { d: string; stroke: string; strokeWidth: number };
 
-/** The default selector used for HTML mockups: controls plus explicit opt-ins. */
+/** The default selector used for HTML mockups: standard wireframe primitives plus explicit opt-ins. */
 export const HTML_ROUGH_SELECTOR =
-  "[data-rough],button,input,textarea,select,hr";
+  "[data-rough],button,input,textarea,select,hr,.wf-btn,.wf-card,.wf-box,.wf-pill,.wf-chip,.wf-icon-fallback,[style*='border:'],[style*='border-top:'],[style*='border-right:'],[style*='border-bottom:'],[style*='border-left:']";
 
 /** Stable per-element seed so a frame doesn't re-wobble on every measure. */
 function seedFrom(...parts: Array<string | number>): number {
@@ -1528,6 +1528,50 @@ function elementStroke(node: Element, fallback: string): string {
   return fallback;
 }
 
+function visibleBorderSides(
+  node: Element,
+): Array<"top" | "right" | "bottom" | "left"> {
+  const cs = getComputedStyle(node);
+  const sides: Array<"top" | "right" | "bottom" | "left"> = [];
+  for (const [side, widthProp, colorProp] of [
+    ["top", "borderTopWidth", "borderTopColor"],
+    ["right", "borderRightWidth", "borderRightColor"],
+    ["bottom", "borderBottomWidth", "borderBottomColor"],
+    ["left", "borderLeftWidth", "borderLeftColor"],
+  ] as const) {
+    const width = parseFloat(cs[widthProp]);
+    const color = cs[colorProp];
+    if (
+      width > 0 &&
+      color &&
+      color !== "rgba(0, 0, 0, 0)" &&
+      color !== "transparent"
+    ) {
+      sides.push(side);
+    }
+  }
+  return sides;
+}
+
+function inferRoughKind(node: HTMLElement): string {
+  const explicit = node.getAttribute("data-rough");
+  if (explicit) return explicit;
+  if (node.tagName === "HR") return "line:middle";
+  const sides = visibleBorderSides(node);
+  if (sides.length !== 1) return "rect";
+  switch (sides[0]) {
+    case "top":
+      return "line:top";
+    case "right":
+      return "line:right";
+    case "bottom":
+      return "line:bottom";
+    case "left":
+      return "line:left";
+  }
+  return "rect";
+}
+
 function build(
   scope: HTMLElement,
   opts: {
@@ -1602,7 +1646,7 @@ function build(
     const w = r.width / zoom;
     const h = r.height / zoom;
     if (w < 2 || h < 2) return;
-    const kind = node.getAttribute("data-rough") || "rect";
+    const kind = inferRoughKind(node);
     const rawStroke = elementStroke(node, sketch);
     const stroke =
       sameColor(rawStroke, ink) || (line !== "" && sameColor(rawStroke, line))
@@ -1621,11 +1665,15 @@ function build(
     let drawable: unknown;
     if (kind === "ellipse") {
       drawable = gen.ellipse(x + w / 2, y + h / 2, w, h, o);
+    } else if (kind === "line:left") {
+      drawable = gen.line(x, y, x, y + h, o);
     } else if (kind === "line:right") {
       drawable = gen.line(x + w, y, x + w, y + h, o);
     } else if (kind === "line:bottom") {
       drawable = gen.line(x, y + h, x + w, y + h, o);
-    } else if (kind === "line:top" || node.tagName === "HR") {
+    } else if (kind === "line:top") {
+      drawable = gen.line(x, y, x + w, y, o);
+    } else if (kind === "line:middle") {
       drawable = gen.line(x, y + h / 2, x + w, y + h / 2, o);
     } else {
       const cr = parseFloat(getComputedStyle(node).borderTopLeftRadius) || 0;