@agent-native/core 0.70.0 → 0.70.1

package/README.md

@@ -21,18 +21,6 @@ export default defineAction({
 - **Agent runtime**: Chat, tools, skills, memory, jobs, observability, and handoffs ship together.
 - **Backend agnostic**: Plug in any Drizzle-supported SQL database and Nitro-compatible host.
 
-## Agents and UIs, Fully Connected
-
-The agent and the UI are equal citizens of one system. Every action works both ways: click it or ask for it.
-
-![Agents and UIs fully connected](https://cdn.builder.io/api/v1/file/assets%2FYJIGb4i01jvw0SRdL5Bt%2Fadc1e9e9368e4a8cb1b4dbb5aae5aaa2)
-
-- **Everything syncs**: One database, one state. Changes from either side show up instantly on the other.
-- **Real-time multiplayer**: Humans and agents edit the same document together, with the agent as a first-class peer.
-- **Context-aware**: The agent knows what you're looking at. Select text, hit Cmd+I, and tell it what to do.
-- **Agents call agents**: Tag another agent from any app and they coordinate over A2A.
-- **Self-improving**: The agent can add features, fix bugs, and refine the UI over time.
-
 ## Templates
 
 Start with a full featured template. Each one is a complete, 100% free and open-source SaaS app: cloneable, not scaffolded, except you own the code and can customize everything.
@@ -43,11 +31,11 @@ Start with a full featured template. Each one is a complete, 100% free and open-
 
 **Clips**
 
-<a href="https://agent-native.com/templates/clips"><img src="https://cdn.builder.io/api/v1/image/assets%2FYJIGb4i01jvw0SRdL5Bt%2F678be5a501a14ab8a508e5f7bc92c468?format=webp&width=800" alt="Clips template" width="100%" /></a>
+<a href="https://agent-native.com/templates/clips"><img src="https://cdn.builder.io/api/v1/image/assets%2FYJIGb4i01jvw0SRdL5Bt%2F189ebd9b2f2b4f0ead3b33138d4e4c10?format=webp&width=800" alt="Clips template" width="100%" /></a>
 
-**Agent-Native Loom**
+**Agent-Native Loom + Jam**
 
-Record your screen with auto-transcripts, shareable links, and an agent that summarizes, captions, and edits clips on demand.
+Record your screen with auto-transcripts and captured browser debug logs, share a link, and let an agent read the transcript, see timestamped frames, and fix the bug.
 
 </td>
 <td width="33%" align="center" valign="top">
@@ -112,6 +100,18 @@ Connect analytics data sources, prompt for real charts, and build reusable dashb
 
 View the full template gallery at **[agent-native.com/templates](https://agent-native.com/templates)**.
 
+## Agents and UIs, Fully Connected
+
+The agent and the UI are equal citizens of one system. Every action works both ways: click it or ask for it.
+
+![Agents and UIs fully connected](https://cdn.builder.io/api/v1/file/assets%2FYJIGb4i01jvw0SRdL5Bt%2Fadc1e9e9368e4a8cb1b4dbb5aae5aaa2)
+
+- **Everything syncs**: One database, one state. Changes from either side show up instantly on the other.
+- **Real-time multiplayer**: Humans and agents edit the same document together, with the agent as a first-class peer.
+- **Context-aware**: The agent knows what you're looking at. Select text, hit Cmd+I, and tell it what to do.
+- **Agents call agents**: Tag another agent from any app and they coordinate over A2A.
+- **Self-improving**: The agent can add features, fix bugs, and refine the UI over time.
+
 ## Try it with a skill
 
 Don't want to scaffold a whole app yet? Add visual planning and PR recaps to Claude Code, Codex, Cursor, Pi, OpenCode, GitHub Copilot / VS Code, and similar agents with one command:

package/corpus/README.md

@@ -27,5 +27,5 @@ rg -n "defineAction|useActionQuery" node_modules/@agent-native/core/corpus
 
 ## Generated Counts
 
-- core files: 1143
-- template files: 3969
+- core files: 1146
+- template files: 3993

package/corpus/core/CHANGELOG.md

@@ -1,5 +1,66 @@
 # @agent-native/core
 
+## 0.70.1
+
+### Patch Changes
+
+- 8003c56: Coerce gateway-stringified tool arguments before action validation. Some model gateways (notably Builder's Gemini-backed gateway) hand structured tool-call arguments back as JSON strings — an array param arrives as `"[{...}]"`, a boolean as `"true"`. Standard Schema (zod) validation does not coerce, so these calls failed validation and the agent could thrash retrying different shapes (and hang). The validation wrapper now coerces a string value to the type its schema field declares (array/object via `JSON.parse`, boolean, number/integer) when — and only when — the schema expects a non-string type and the string parses cleanly to it; ambiguous or unparseable values are left untouched so the normal validation error still surfaces.
+- 8003c56: Composer model picker improvements. The picker now supports an optional secondary "image model" menu via a new `imageModelMenu` prop on `AgentChatSurface` / `AssistantChat` (opt-in; chat-only apps are unaffected) — apps that drive a separate generation model (e.g. Assets' image model) can surface it in the same dropdown so it's clear which model reasons about the request and which produces the output. The reasoning-effort list is now a collapsed-by-default accordion (matching the provider groups) instead of always-expanded, keeping the menu compact. Model catalog: the Builder gateway list now lists Opus 4.8 (was 4.7) and drops the retired GPT-5.1 Codex Mini entry.
+- 8003c56: Remove the setup/onboarding checklist that appeared above the agent chat (the
+  "Setup N of 5" panel with Connect an AI engine / image & video generation /
+  asset storage / email / GitHub steps) and its header "Setup" re-open button.
+  Setup is now surfaced in better places — the settings panel and per-feature
+  setup affordances — so the panel no longer takes up sidebar space in any app.
+- 8003c56: Feedback submissions now forward a `clientSurface` hint (web / electron / tauri)
+  alongside the existing page URL, so form owners can tell whether feedback came
+  from the Agent Native desktop app, a Tauri shell (e.g. Clips), or a browser.
+  Detection is exposed as a reusable `getClientSurface()` client helper and is
+  passed through as hidden metadata — it never appears as a visible form field.
+- 8003c56: Fix the "Sign in with Google" button getting stuck disabled when the OAuth
+  window is closed without finishing (e.g. to retry in a different browser
+  profile). The button was only ever re-enabled on an explicit OAuth error or
+  the 5-minute poll timeout, so a cancelled sign-in left the primary CTA greyed
+  out with no way to retry short of refreshing. The sign-in screen now re-enables
+  the button (and stops the pending exchange poll) when the window regains focus
+  or becomes visible again — mirroring the existing email-verification recovery.
+- 8003c56: Add observability and a safety valve for inline MCP App embeds, on top of the
+  Codex/Cursor transplant fix already shipped in 0.70.0.
+
+  When an inline embed cannot load in a host, the shell now reports a bounded,
+  structured diagnostic (stage, message, HTTP status, host, render mode, bridge
+  type) to a new CORS-open `POST /_agent-native/mcp/embed-error` route, which
+  forwards it to Sentry via `captureError` — so embed failures across Codex,
+  Cursor, ChatGPT, and Claude are inspectable instead of an opaque spinner. The
+  failure card also surfaces the specific cause (e.g. "Embedded app returned HTTP
+  500" / session-expired) and promotes "Open in new tab" to the primary action.
+
+  Adds a deploy-toggleable kill switch for inline MCP App embeds, **off by
+  default**. Set `AGENT_NATIVE_MCP_APPS_INLINE=1` to enable inline embeds for an
+  environment; while it is off, accounts listed in
+  `AGENT_NATIVE_MCP_APPS_INLINE_ALLOW_EMAILS` (comma/space separated) still get
+  them, so a fix can be verified in production before it reaches normal users.
+  When disabled, no `ui://` resource is advertised or referenced and tool results
+  fall back to their deep-link text — no skills/instructions change required.
+
+- 8003c56: Show a friendly "You're all set" confirmation page after authorizing an MCP
+  client whose redirect is a native deep link (cursor://, vscode://, …). Instead
+  of leaving the browser tab dangling on a blank page after the OS handed the code
+  to the app, the tab now shows a checkmark, a "return to your agent to continue"
+  message, and re-fires the deep link so the client still receives the code.
+  https/loopback callbacks keep the standard redirect.
+- 8003c56: Clarify the "Where should visual plans and recaps live?" install prompt: move
+  the "(recommended)" marker into the hosted option's label and tighten its
+  description to "100% free and open source. Supports comments, browser editor,
+  and sharing. Requires one-time browser sign-in."
+- 8003c56: When a hosted run is cut off mid-step and exhausts its in-invocation
+  continuation budget without finishing, the chat now ends with a loud,
+  unambiguous "stopped before finishing" terminal instead of a silent stall or a
+  misleading clean `done`. The terminal carries a machine-readable
+  `run_budget_exhausted` error code that is deliberately excluded from the
+  client's auto-recoverable allow-list, so the chain terminates rather than
+  looping another continuation into the same wall, and any half-streamed partial
+  text is cleared so the message stands alone.
+
 ## 0.70.0
 
 ### Minor Changes

package/corpus/core/docs/design/durable-agent-runs.md

@@ -0,0 +1,217 @@
+# Design: Durable / Checkpointed Agent Runs
+
+Status: proposed
+Owner: core / run-manager
+Related code: `packages/core/src/agent/run-manager.ts`,
+`packages/core/src/agent/engine/builder-engine.ts`
+
+## Problem
+
+Hosted agent runs are bounded by a ~40s soft timeout enforced in
+`run-manager.ts` (`DEFAULT_HOSTED_RUN_SOFT_TIMEOUT_MS = 40_000`, also the
+`HOSTED_SOFT_TIMEOUT_CEILING_MS`). That budget is deliberate and correct: it
+sits just under a stack of upstream walls that the framework does not control.
+
+When the soft timeout fires, the run-manager aborts the current chunk, persists
+the partial turn, writes a terminal event, and emits an `auto_continue` event
+(`reason: "run_timeout"`) so the client transparently resumes the turn in a
+fresh chunk. This works well for a single long model call that just needs more
+wall-clock time.
+
+It does **not** work well for long _multi-step_ operations. A turn that performs
+many sequential side effects — for example an agent appending many dashboard
+panels through many separate write calls, or any "do N independent mutations in
+a loop" workflow — fails in a characteristic way:
+
+- **Continuation thrash / re-hydration.** Each `auto_continue` chunk starts the
+  model over from the rebuilt context. If the work isn't expressed as resumable
+  progress, the model frequently re-reasons about and re-issues steps it already
+  attempted in the previous chunk instead of advancing. Successive chunks burn
+  their entire 40s budget re-deciding rather than completing new steps.
+- **Partial or zero net progress.** Because each chunk can be cut mid-step and
+  the next chunk may redo earlier steps, the run can churn for many chunks while
+  the _persisted_ end state barely moves — or, when nothing reaches a committed
+  state before each cutoff, moves not at all.
+- **Silent "looked-done" failure.** A tool call that returned a success marker
+  (✓) in an aborted chunk does not guarantee its effect was committed and
+  survived the cutoff. The model can reasonably believe a step succeeded, report
+  the whole task complete, and leave nothing (or only some rows) actually
+  persisted. The user is told it worked; the data says otherwise.
+
+Net effect: long multi-step runs can spin indefinitely, never finish, and
+terminate with an untruthful "done" state.
+
+## Goals
+
+1. Long multi-step runs **complete reliably** — they make monotonic forward
+   progress across continuation chunks rather than re-doing work.
+2. The user always gets a **truthful terminal state**: either "completed, here
+   is concrete proof (N of N persisted, ids …)", or an honest "did not finish,
+   here is what was committed (M of N) and what remains" — never a false
+   success.
+3. No change to the upstream walls and no raising of the 40s soft timeout (see
+   Guardrail).
+
+## Non-goals
+
+- Raising or removing the soft timeout. It is correct; see Guardrail.
+- Changing the gateway, serverless function limits, or model call timeout.
+- Replacing `auto_continue`. Both approaches below build on it.
+
+## Guardrail: the 40s soft timeout is correct and must not be raised
+
+`DEFAULT_HOSTED_RUN_SOFT_TIMEOUT_MS` / `HOSTED_SOFT_TIMEOUT_CEILING_MS` =
+`40_000` is intentional headroom under the upstream hard walls. Raising it does
+not buy more time — it just converts a graceful hand-off into a hard kill. The
+walls, in order:
+
+1. **Builder model gateway hard cap — ~45s.**
+   `MAX_BUILDER_GATEWAY_TIMEOUT_MS = 45_000` in
+   `packages/core/src/agent/engine/builder-engine.ts`. A single model call is
+   killed at the gateway after 45s. **Not raisable** by the framework.
+2. **Serverless function kill — ~60–65s.** The hosting function is terminated
+   shortly after; the heartbeat then reaps the run row as `stale_run`.
+
+40s leaves ~5s under the gateway wall to abort, persist the partial turn, write
+the terminal event, and emit a clean `auto_continue` so the client resumes. A
+larger value (production saw per-template overrides like `240_000`) pushes the
+cutoff past both walls, so `auto_continue` never fires and the run dies as
+`builder_gateway_timeout` / `stale_run` instead. The ceiling clamp in
+`resolveRunSoftTimeoutMs` exists precisely to defeat that footgun. **Do not
+raise it. Fix durability above the timeout, not by moving the timeout.**
+
+## Approach options
+
+Both options keep the 40s budget and build on the existing `auto_continue`
+mechanism. They differ in _where the long work lives_.
+
+### Option A — Checkpointed / idempotent continuation
+
+Keep the work inside the normal run/`auto_continue` loop, but make each
+continuation chunk **resume from committed progress instead of restarting**.
+
+Mechanism:
+
+- **Persist a progress record** for the operation (a checkpoint): the planned
+  unit of work (the N items / steps), and which units are already committed.
+  This lives in SQL so it survives chunk boundaries and function recycling, the
+  same way run rows do.
+- **Idempotent steps.** Each step keys off a stable identity so re-issuing a
+  completed step is a no-op (upsert by natural key, or "skip if checkpoint says
+  done"). Re-hydration after `auto_continue` then can't double-apply or
+  thrash — a redone step costs a cheap check, not a duplicate write.
+- **Resume, don't replan.** On `auto_continue`, the next chunk reads the
+  checkpoint, skips committed units, and continues with the remainder. Progress
+  is monotonic: every chunk that does anything moves the committed count up.
+- **Truthful terminal state from the checkpoint.** "Done" means the checkpoint
+  shows N of N committed. If the run is cut for good (e.g. it exhausts a
+  continuation budget), the checkpoint still reports M of N committed and the
+  exact remainder — so the terminal message is honest by construction.
+
+Interaction with the walls and the 40s budget:
+
+- Fully respects the 40s soft timeout and the gateway/function walls — it never
+  needs a single chunk to outlast them. It just makes the _sequence_ of chunks
+  productive.
+- Works hand-in-glove with `auto_continue`: today a continuation can redo work;
+  with a checkpoint, a continuation can only advance.
+
+Tradeoffs:
+
+- Pro: smallest change to the runtime model; no new infrastructure; the user
+  keeps watching one live turn; degrades gracefully (even a half-finished run is
+  truthful and re-runnable).
+- Pro: directly kills re-hydration thrash, the actual failure mode.
+- Con: still bounded by however many continuation chunks the client/turn budget
+  allows. A truly enormous job (thousands of steps) can still run out of chunks
+  — but it now ends _truthfully partial and resumable_, not silently empty.
+- Con: requires per-operation work to define the unit of progress and make
+  steps idempotent. Best paid down once at the primitive/action layer (see
+  Tie-in) so individual agents don't have to.
+
+### Option B — Out-of-band durable background execution
+
+Hand a long run to a **queued background job** that executes beyond the
+function/gateway lifetime and reports progress back into the run/event stream.
+
+Mechanism:
+
+- The foreground turn **enqueues** a durable job (the full operation + its
+  inputs) and returns immediately with "started, tracking as job X". The
+  user-facing run does not try to do the work itself within 40s.
+- A durable worker (outside the per-request serverless function lifetime — e.g.
+  the core run-manager / agent-teams background infrastructure the framework
+  already mandates for background agents) runs the job to completion, free of
+  the 45s gateway cap and the ~60s function kill on the _original_ request.
+- The worker **streams progress** (committed counts, ids, errors) back so the
+  UI and the agent can observe and the final state is truthful.
+
+Interaction with the walls and the 40s budget:
+
+- Sidesteps the gateway/function walls for the _long_ work by moving it off the
+  request path. The walls still apply to each individual model call the worker
+  makes, so the worker itself should checkpoint internally (i.e. Option B is
+  strongest when it contains Option A).
+- `auto_continue` becomes a lightweight "is the job still running / what's its
+  progress" poll on the foreground turn rather than the vehicle for the work.
+
+Tradeoffs:
+
+- Pro: removes the hard ceiling on total operation length — genuinely large
+  jobs can finish.
+- Pro: the foreground turn stays responsive and cheap; the user can leave and
+  come back.
+- Con: more infrastructure and lifecycle complexity (job queue, durable worker,
+  progress fan-in, failure/retry semantics, surfacing job state in the UI and
+  to the agent).
+- Con: changes the UX from "one live turn" to "fire-and-track"; needs clear
+  status surfacing so it doesn't become its own kind of silent failure.
+
+## Recommendation
+
+Build **Option A first**, then layer **Option B** for the genuinely unbounded
+cases. Option A delivers the most reliability per unit of effort: it directly
+removes re-hydration thrash and silent looked-done failure for the common case
+(tens of steps), needs no new infrastructure, and makes terminal state truthful
+by construction. Option B is the right ceiling-remover but is a larger build and
+is most valuable _on top of_ a checkpointed core (the durable worker should
+itself checkpoint).
+
+### Phased plan
+
+1. **Phase 0 — Stop hitting the ceiling so often (near-term, cheapest).** Land
+   the mitigations in the Tie-in below (one-call atomic primitives,
+   self-documenting actions, loud termination, proof-of-done verification).
+   These don't fix the ceiling but sharply cut how often multi-step loops are
+   even attempted, and make the failures that remain _loud and truthful_ instead
+   of silent. Capture the agent-facing half as the `reliable-mutations` skill.
+2. **Phase 1 — Checkpointed continuation (Option A).** Add a SQL-backed progress
+   checkpoint for long operations and make their steps idempotent/resumable so
+   each `auto_continue` chunk advances committed progress instead of replanning.
+   Drive terminal state ("N of N", or "M of N + remainder") from the checkpoint.
+   This is the primary reliability win.
+3. **Phase 2 — Durable background execution (Option B).** For operations that
+   can exceed any reasonable number of continuation chunks, enqueue them onto the
+   core background infrastructure, have the durable worker run them to completion
+   (checkpointing internally per Phase 1), and stream truthful progress back to
+   the foreground run and UI.
+
+## Tie-in: cheaper near-term mitigations reduce, but do not replace, the fix
+
+The following reduce _how often_ the 40s ceiling is hit and make the remaining
+failures honest. They are valuable and should ship first (Phase 0), but the
+**actual fix is durable/checkpointed runs** (Phases 1–2):
+
+- **One-call atomic primitives.** Where an action can accept the whole batch
+  (e.g. "set all panels" / "append many in one call"), a single call commits
+  atomically inside one chunk instead of looping N writes that race the budget.
+- **Self-documenting actions.** Action descriptions that steer agents toward the
+  atomic/batch call and away from per-item loops.
+- **Loud termination.** On a time-budget cutoff, fail loud with what was and
+  wasn't committed — never report success on an aborted chunk.
+- **Proof-of-done verification.** After a write, re-read the end state and report
+  concrete proof (counts/ids) rather than trusting a tool ✓.
+
+The agent-facing rules for these live in the `reliable-mutations` skill
+(`.agents/skills/reliable-mutations/SKILL.md`). They lower the blast radius;
+checkpointed and durable runs remove the ceiling itself.

package/corpus/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.70.0",
+  "version": "0.70.1",
   "type": "module",
   "engines": {
     "node": ">=22"

package/corpus/core/src/action.ts

@@ -908,6 +908,94 @@ function zodDefToJsonSchema(def: any): any {
 // Runtime validation wrapper
 // ---------------------------------------------------------------------------
 
+const NO_COERCE = Symbol("no-coerce");
+
+/**
+ * Coerce a single stringified value to one of the JSON-schema types the field
+ * expects. Returns NO_COERCE when nothing safe applies, so the caller leaves
+ * the original value untouched and the normal validation error still surfaces.
+ */
+function coerceStringToSchemaType(raw: string, types: string[]): unknown {
+  const trimmed = raw.trim();
+  if (types.includes("boolean")) {
+    if (trimmed === "true") return true;
+    if (trimmed === "false") return false;
+  }
+  if (
+    (types.includes("array") &&
+      trimmed.startsWith("[") &&
+      trimmed.endsWith("]")) ||
+    (types.includes("object") &&
+      trimmed.startsWith("{") &&
+      trimmed.endsWith("}"))
+  ) {
+    try {
+      const parsed = JSON.parse(trimmed);
+      if (types.includes("array") && Array.isArray(parsed)) return parsed;
+      if (
+        types.includes("object") &&
+        parsed &&
+        typeof parsed === "object" &&
+        !Array.isArray(parsed)
+      ) {
+        return parsed;
+      }
+    } catch {
+      // fall through — leave the original so validation reports the real error
+    }
+  }
+  if (
+    (types.includes("number") || types.includes("integer")) &&
+    trimmed !== "" &&
+    Number.isFinite(Number(trimmed))
+  ) {
+    const n = Number(trimmed);
+    if (types.includes("number") || Number.isInteger(n)) return n;
+  }
+  return NO_COERCE;
+}
+
+/**
+ * Defensively coerce gateway-stringified tool arguments to the types the schema
+ * expects. Some model gateways (notably Builder's Gemini-backed gateway) hand
+ * back structured tool-call arguments as JSON strings — an array param arrives
+ * as `"[{...}]"`, a boolean as `"true"`. Standard Schema (zod) `validate` does
+ * not coerce, so these fail validation and the agent thrashes retrying shapes
+ * (and can hang). We only touch a string value when the schema expects a
+ * non-string type and the string parses cleanly to it; anything ambiguous
+ * (schema also allows string) or unparseable is left as-is. Operates on
+ * top-level properties only — once an array/object param is parsed, its nested
+ * members are already native and validate normally.
+ */
+function coerceGatewayStringifiedArgs(
+  args: unknown,
+  parameters?: ActionTool["parameters"],
+): unknown {
+  const properties = parameters?.properties as
+    | Record<string, { type?: string | string[] }>
+    | undefined;
+  if (!properties) return args;
+  if (!args || typeof args !== "object" || Array.isArray(args)) return args;
+  let out: Record<string, unknown> | null = null;
+  for (const [key, raw] of Object.entries(args as Record<string, unknown>)) {
+    if (typeof raw !== "string") continue;
+    const spec = properties[key];
+    if (!spec) continue;
+    const types = Array.isArray(spec.type)
+      ? spec.type
+      : spec.type
+        ? [spec.type]
+        : [];
+    // No declared type, or the field legitimately accepts a string → leave it.
+    if (types.length === 0 || types.includes("string")) continue;
+    const coerced = coerceStringToSchemaType(raw, types);
+    if (coerced === NO_COERCE) continue;
+    if (!out) out = { ...(args as Record<string, unknown>) };
+    out[key] = coerced;
+  }
+  return out ?? args;
+}
+
 /**
  * Wrap an action's run function with schema validation.
  * Invalid inputs get a clear error message (including what was actually passed)
@@ -919,6 +1007,7 @@ function wrapWithValidation(
   toolParameters?: ActionTool["parameters"],
 ): (args: any, ctx?: ActionRunContext) => any {
   return async (args: any, ctx?: ActionRunContext) => {
+    args = coerceGatewayStringifiedArgs(args, toolParameters);
     const result = await schema["~standard"].validate(args);
     if (result.issues) {
       // Split issues into "missing required field" vs other validation errors

package/corpus/core/src/agent/model-config.ts

@@ -39,7 +39,6 @@ const MODEL_CONTEXT_WINDOWS: Record<string, number> = {
   "gpt-5-5": 1_050_000,
   "gpt-5-4": 1_050_000,
   "gpt-5-4-mini": 400_000,
-  "gpt-5-1-codex-mini": 128_000,
 
   // ── Gemini (Builder gateway IDs) ─────────────────────────────────────────
   "gemini-3-1-pro": 1_048_576,
@@ -145,7 +144,6 @@ export const AGENT_MODEL_CONFIG = {
       FRAMEWORK_DEFAULT_BUILDER_OPENAI_MODEL,
       "gpt-5-4",
       "gpt-5-4-mini",
-      "gpt-5-1-codex-mini",
       "gemini-3-1-pro",
       "gemini-3-5-flash",
       "gemini-3-1-flash-lite",

package/corpus/core/src/agent/run-loop-with-resume.ts

@@ -90,6 +90,24 @@ async function appendToolCallJournalNote(
  */
 export const MAX_RUN_LOOP_CONTINUATIONS = 6;
 
+/** Machine-readable code carried on the give-up terminal `error` event so the
+ * client renders a loud "stopped before finishing" terminal instead of an
+ * ambiguous silent stall. Deliberately NOT in the client's auto-recoverable
+ * allow-list (`isAutoRecoverableError`) so it terminates the chain rather than
+ * looping another POST that would hit the same wall. */
+export const RUN_BUDGET_EXHAUSTED_ERROR_CODE = "run_budget_exhausted";
+
+/** User-facing terminal message when a hosted run is cut off mid-step and
+ * exhausts its in-invocation continuation budget without finishing. Generic and
+ * framework-level (not app-specific). Mirrors the `reliable-mutations` skill's
+ * "fail loud, retry as a single bulk action" guidance so the user understands
+ * the turn stopped before finishing and was not partially saved by the run
+ * itself. */
+export const RUN_BUDGET_EXHAUSTED_MESSAGE =
+  "I ran out of time before finishing this step (hosted runs have a ~40s budget). " +
+  "I stopped rather than leave things half-done — nothing was partially saved by me here. " +
+  "Please retry, ideally as a single bulk action.";
+
 /**
  * Internal entry point used by the agent-chat plugin's run handler. Wraps
  * `runAgentLoop` with soft-timeout + resumable-error continuation recovery.
@@ -124,8 +142,16 @@ export async function runAgentLoopDirectWithSoftTimeout(
   };
 
   let attempts = 0;
+  // Tracks whether the most recent attempt ended by scheduling another
+  // continuation (soft-timeout or resumable error → `continue`) rather than
+  // returning a finished turn. When the loop then exits because the budget is
+  // exhausted (NOT because the user aborted and NOT because the turn finished),
+  // this is the silent give-up case: emit a loud terminal so the user sees an
+  // unambiguous "stopped before finishing" instead of a bare done/"…".
+  let lastAttemptWasUnfinishedContinuation = false;
   while (!upstreamSignal.aborted && attempts < MAX_RUN_LOOP_CONTINUATIONS) {
     attempts++;
+    lastAttemptWasUnfinishedContinuation = false;
     const controller = new AbortController();
     const abortFromUpstream = () => controller.abort();
     if (upstreamSignal.aborted) {
@@ -150,6 +176,7 @@ export async function runAgentLoopDirectWithSoftTimeout(
       });
       addUsage(nextUsage);
       if (softTimedOut && !upstreamSignal.aborted) {
+        lastAttemptWasUnfinishedContinuation = true;
         appendAgentLoopContinuation(opts.messages, "run_timeout");
         await appendToolCallJournalNote(opts.messages, opts.threadId);
         continue;
@@ -159,6 +186,7 @@ export async function runAgentLoopDirectWithSoftTimeout(
       if (softTimedOut && !upstreamSignal.aborted) {
         // Clear partial text the client received before the abort so the
         // resumed model doesn't re-emit it and produce duplicated output.
+        lastAttemptWasUnfinishedContinuation = true;
         opts.send({ type: "clear" });
         appendAgentLoopContinuation(opts.messages, "run_timeout");
         await appendToolCallJournalNote(opts.messages, opts.threadId);
@@ -178,6 +206,7 @@ export async function runAgentLoopDirectWithSoftTimeout(
       // (the partial text was already sent to the client but never entered
       // the in-memory messages array, so the next attempt re-emits it).
       if (!upstreamSignal.aborted && isResumableEngineError(err)) {
+        lastAttemptWasUnfinishedContinuation = true;
         opts.send({ type: "clear" });
         appendAgentLoopContinuation(
           opts.messages,
@@ -193,5 +222,24 @@ export async function runAgentLoopDirectWithSoftTimeout(
     }
   }
 
+  // The loop exited without a clean return. If the user aborted, that's a Stop —
+  // stay silent. Otherwise we only get here by exhausting
+  // MAX_RUN_LOOP_CONTINUATIONS while the last attempt was still trying to
+  // continue (soft-timeout / resumable error). That is the genuinely-silent
+  // give-up the run-manager would otherwise report as a clean `done`: emit a
+  // loud, non-auto-continuing terminal so the user knows the turn stopped
+  // before finishing and nothing was partially saved by the run itself.
+  if (!upstreamSignal.aborted && lastAttemptWasUnfinishedContinuation) {
+    // Discard any partial text already streamed for the unfinished attempt so
+    // the terminal message stands alone instead of trailing a half sentence.
+    opts.send({ type: "clear" });
+    opts.send({
+      type: "error",
+      error: RUN_BUDGET_EXHAUSTED_MESSAGE,
+      errorCode: RUN_BUDGET_EXHAUSTED_ERROR_CODE,
+      recoverable: true,
+    });
+  }
+
   return usage;
 }

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

@@ -4033,8 +4033,8 @@ async function promptForPlanMode(
     options: [
       {
         value: "hosted",
-        label: "Hosted plans, shareable links",
-        hint: "Recommended. 100% free and open source. Stores plans at plan.agent-native.com with sharing, comments, and browser editor. Requires one-time browser sign-in.",
+        label: "Hosted plans, shareable links (recommended)",
+        hint: "100% free and open source. Supports comments, browser editor, and sharing. Requires one-time browser sign-in.",
       },
       {
         value: "local-files",

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

@@ -147,9 +147,11 @@ const SetupButton = lazy(() =>
   })),
 );
 
-// Setup/onboarding widget appears above chat until required setup is complete,
-// and can be reopened from the header after dismissal.
-const SHOW_ONBOARDING = true;
+// The setup/onboarding checklist that used to appear above chat is disabled
+// for every app — setup (AI engine, image/video gen, asset storage, email,
+// GitHub, etc.) is surfaced in better places (the settings panel and the
+// per-feature setup affordances). Keep this off; do not re-enable globally.
+const SHOW_ONBOARDING = false;
 
 const CLI_STORAGE_KEY = "agent-native-cli-command";
 const CLI_DEFAULT = "claude";

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

@@ -86,6 +86,7 @@ import { agentNativePath } from "./api-path.js";
 import {
   TiptapComposer,
   type ComposerSubmitIntent,
+  type ComposerImageModelMenu,
   type TiptapComposerHandle,
 } from "./composer/TiptapComposer.js";
 import { AgentComposerFrame } from "./composer/AgentComposerFrame.js";
@@ -712,6 +713,11 @@ export interface AssistantChatProps {
   onModelChange?: (model: string, engine: string) => void;
   /** Callback when user picks a reasoning effort from the picker */
   onEffortChange?: (effort: ReasoningEffort) => void;
+  /**
+   * Optional secondary model menu (e.g. an image-generation model) shown inside
+   * the composer's model picker. Opt-in; chat-only apps omit it.
+   */
+  imageModelMenu?: ComposerImageModelMenu;
   /** Callback when user clicks "Fork Chat" in the message actions menu */
   onForkChat?: () => void | boolean | Promise<void | boolean>;
   /** Override Builder/provider connect routing for embedded hosts. */
@@ -977,6 +983,7 @@ const AssistantChatInner = forwardRef<
     availableModels,
     onModelChange,
     onEffortChange,
+    imageModelMenu,
     onForkChat,
     onConnectProvider,
     plusMenuMode = "full",
@@ -3392,6 +3399,7 @@ const AssistantChatInner = forwardRef<
                     availableModels={availableModels}
                     onModelChange={onModelChange}
                     onEffortChange={onEffortChange}
+                    imageModelMenu={imageModelMenu}
                     onConnectProvider={onConnectProvider}
                     toolbarSlot={composerToolbarSlot}
                     contextItems={composerContextItems}