@agent-native/core 0.26.9 → 0.27.0

package/docs/content/cli-adapters.md

@@ -174,12 +174,20 @@ export class DockerAdapter implements CliAdapter {
 
 Expose the registry to the UI via an API route so actions and components can discover and invoke CLIs:
 
+`createServer()` returns an H3 `{ app, router }`. Mount routes on `router` with H3 handlers (`defineEventHandler`, `readBody`, `getRouterParam`):
+
 ```ts
 // server/index.ts
 import { createServer } from "@agent-native/core";
 import { CliRegistry, ShellCliAdapter } from "@agent-native/core/adapters/cli";
-
-const app = createServer();
+import {
+  defineEventHandler,
+  readBody,
+  getRouterParam,
+  setResponseStatus,
+} from "h3";
+
+const { router } = createServer();
 const cliRegistry = new CliRegistry();
 
 cliRegistry.register(
@@ -190,23 +198,31 @@ cliRegistry.register(
 );
 
 // Discovery endpoint — agent can query this
-app.get("/api/cli", async (_req, res) => {
-  const tools = await cliRegistry.describe();
-  res.json(tools);
-});
+router.get(
+  "/api/cli",
+  defineEventHandler(async () => {
+    return await cliRegistry.describe();
+  }),
+);
 
 // Execution endpoint
-app.post("/api/cli/:name", async (req, res) => {
-  const adapter = cliRegistry.get(req.params.name);
-  if (!adapter) return res.status(404).json({ error: "CLI not found" });
+router.post(
+  "/api/cli/:name",
+  defineEventHandler(async (event) => {
+    const name = getRouterParam(event, "name");
+    const adapter = name ? cliRegistry.get(name) : undefined;
+    if (!adapter) {
+      setResponseStatus(event, 404);
+      return { error: "CLI not found" };
+    }
 
-  const { args } = req.body;
-  const result = await adapter.execute(args ?? []);
-  res.json(result);
-});
+    const { args } = await readBody(event);
+    return await adapter.execute(args ?? []);
+  }),
+);
 ```
 
-## Using from actions {#from-scripts}
+## Using from actions {#from-actions}
 
 Actions can use CLI adapters directly for structured access:
 
@@ -240,9 +256,9 @@ export default async function listPrs() {
   }
 
   const prs = JSON.parse(result.stdout);
-  const fs = await import("node:fs/promises");
-  await fs.writeFile("data/prs.json", JSON.stringify(prs, null, 2));
-  console.log(`Fetched ${prs.length} PRs`);
+  console.error(`Fetched ${prs.length} PRs`);
+  // Return the data (or persist it to SQL) — don't write durable state to data/.
+  return prs;
 }
 ```
 

package/docs/content/client.md

@@ -117,25 +117,10 @@ sendToAgentChat({
 
 ## MCP App Host Bridge {#mcp-app-host-bridge}
 
-Routes embedded by `embedApp()` should be URL-first: load the current artifact
-from path/query params, render the real React route or a focused shared
-component, and use host bridge messages only for host-owned behavior.
-
-Default direct route embeds use the standard MCP Apps `ui/*` JSON-RPC bridge.
-The exported helpers below send `ui/update-model-context`, `ui/open-link`, and
-`ui/request-display-mode` directly to the host. The explicit nested diagnostic
-mode still uses the wrapper relay:
-
-| Direction       | Message type                             | Purpose                                           |
-| --------------- | ---------------------------------------- | ------------------------------------------------- |
-| wrapper → route | `agentNative.mcpHostContext`             | Push host context such as theme/display mode      |
-| route → wrapper | `agentNative.mcpHost.updateModelContext` | Add hidden model context                          |
-| route → wrapper | `agentNative.mcpHost.openLink`           | Ask the host to open a URL                        |
-| route → wrapper | `agentNative.mcpHost.requestDisplayMode` | Ask for `inline`, `fullscreen`, or `pip`          |
-| wrapper → route | `agentNative.mcpHost.response`           | Resolve or reject a request by matching requestId |
-
-Use the exported helpers from `@agent-native/core/client` inside embedded
-routes:
+Routes embedded as MCP Apps should be URL-first: load the current artifact from
+path/query params, render the real React route or a focused shared component,
+and use the host bridge only for host-owned behavior. `@agent-native/core/client`
+exports the helpers embedded routes call:
 
 ```ts
 import {
@@ -149,10 +134,16 @@ import {
 
 `getMcpAppHostContext()` reads the latest pushed host context snapshot;
 `useMcpAppHostContext()` subscribes React components to changes. The request
-helpers return `false` outside an embedded MCP App frame, or
+helpers (`openMcpAppHostLink`, `requestMcpAppDisplayMode`,
+`updateMcpAppModelContext`) return `false` outside an embedded MCP App frame, or
 `Promise<boolean>` inside a frame. `sendToAgentChat()` uses the same bridge for
 auto-submitted prompts from embedded routes.
 
+The bridge itself — the `ui/*` JSON-RPC messages, the `agentNative.mcpHost.*`
+wrapper relay, transplant vs. controlled-frame rendering, host context, and
+display-mode requests — is owned by
+[External Agents](/docs/external-agents#mcp-app-bridge).
+
 ## Dynamic Suggestions {#dynamic-suggestions}
 
 `<AgentSidebar>`, `<AgentPanel>`, and `<AssistantChat>` merge static `suggestions` with context-aware suggestions by default. The framework reads `navigation`, `selection`, `pending-selection-context`, and the current URL from application state while an empty chat is visible, then offers prompt chips that match the current screen.

package/docs/content/code-agents-ui.md

@@ -140,7 +140,20 @@ agent-native code ui
 
 `resume` appends context and continues a run, `status` reports the latest run
 state, `stop` asks the active controller to halt work, and `ui` opens the local
-Code surface. These are run controls, not a separate implementation path.
+Code surface. These are run controls, not a separate implementation path. If a
+high-risk command pauses for approval, `approve --last` runs that one pending
+command and then points you back to resume the session.
+
+Run modes make editing policy explicit per session:
+
+| Mode          | CLI flag | Behavior                                                                                                 |
+| ------------- | -------- | -------------------------------------------------------------------------------------------------------- |
+| **Plan mode** | `--plan` | Inspect, plan, and explain without writing files or running mutations.                                   |
+| **Auto mode** | `--auto` | Edit files, run checks, and pause only for genuinely destructive file, git, publish, or data operations. |
+
+Auto mode is the default for local Agent-Native Code sessions. Use Plan mode for
+assessment, architecture, review, or any task where you want a proposal before
+edits.
 
 For cross-surface lists, dashboards, or monitoring panes, prefer the shared
 background-run exports from `@agent-native/core/code-agents` over reading Code
@@ -271,10 +284,10 @@ commands and skills are discovered from `.agents/commands/*.md` and
 `.agents/skills/*/SKILL.md`; the UI should render those packs and insert prompts
 through the shared composer.
 
-## Background Agent Harness
+## Background Agent Run-Manager
 
-Background coding-agent work should reuse the same harness as the rest of
-Agent-Native:
+Background coding-agent work should reuse the same run-manager foundation as the
+rest of Agent-Native:
 
 - Use the Code run store/executor for local Code sessions.
 - Use the shared background-run adapter/foundation when a surface needs to list,
@@ -285,8 +298,8 @@ Agent-Native:
   background sub-agent from a normal app chat.
 
 Do not add a parallel background-agent runner just because a new surface needs a
-different layout. Build a host adapter or UI slot on top of the shared harness
-instead.
+different layout. Build a host adapter or UI slot on top of the shared
+run-manager foundation instead.
 
 Regression rule for new prompt or background surfaces: Code, Brain, and the
 standard sidebar must keep using `PromptComposer` through the shared composer

package/docs/content/context-awareness.md

@@ -53,28 +53,44 @@ Every template should have a `view-screen` action. It reads navigation state, fe
 
 ```ts
 // actions/view-screen.ts
+import { defineAction } from "@agent-native/core";
 import { readAppState } from "@agent-native/core/application-state";
+import { eq } from "drizzle-orm";
+import { z } from "zod";
+import { getDb, schema } from "../server/db/index.js";
+
+export default defineAction({
+  description:
+    "See what the user is currently looking at on screen. Reads navigation state and fetches matching data.",
+  schema: z.object({}),
+  http: false,
+  run: async () => {
+    const navigation = (await readAppState("navigation")) as any;
+    const screen: Record<string, unknown> = {};
+    if (navigation) screen.navigation = navigation;
+
+    const db = getDb();
+
+    // Fetch data based on what the user is viewing
+    if (navigation?.view === "inbox") {
+      screen.emailList = await db
+        .select()
+        .from(schema.emails)
+        .where(eq(schema.emails.label, navigation.label));
+    }
+    if (navigation?.threadId) {
+      screen.thread = await db
+        .select()
+        .from(schema.threads)
+        .where(eq(schema.threads.id, navigation.threadId));
+    }
 
-export default async function main() {
-  const navigation = await readAppState("navigation");
-  const screen: Record<string, unknown> = { navigation };
-
-  // Fetch data based on what the user is viewing
-  if (navigation?.view === "inbox") {
-    const res = await fetch(
-      "http://localhost:3000/api/emails?label=" + navigation.label,
-    );
-    screen.emailList = await res.json();
-  }
-  if (navigation?.threadId) {
-    const res = await fetch(
-      "http://localhost:3000/api/threads/" + navigation.threadId,
-    );
-    screen.thread = await res.json();
-  }
-
-  console.log(JSON.stringify(screen, null, 2));
-}
+    if (Object.keys(screen).length === 0) {
+      return "No application state found. Is the app running?";
+    }
+    return screen;
+  },
+});
 ```
 
 The agent should always call `pnpm action view-screen` before acting. This is a hard convention across all templates. When adding new features, update `view-screen` to return data for the new view.

package/docs/content/database.md

@@ -5,11 +5,11 @@ description: "Connect a portable SQL database to your agent-native app and write
 
 # Database
 
-Agent-native apps use [Drizzle ORM](https://orm.drizzle.team) and support portable SQL backends. By default, apps use SQLite with a local file — set `DATABASE_URL` to connect a persistent production database.
+Agent-native apps use [Drizzle ORM](https://orm.drizzle.team) and support portable SQL backends. For anything beyond local development, connect a persistent SQL database — Postgres, libSQL/Turso, or another Drizzle-compatible backend — by setting `DATABASE_URL`. When that variable is unset, the app falls back to a zero-config local SQLite file so you can start developing immediately.
 
-## Default: SQLite {#default-sqlite}
+## Local default: SQLite file {#default-sqlite}
 
-When `DATABASE_URL` is not set, the app creates a SQLite database at `data/app.db`. This is great for local development — no setup required.
+When `DATABASE_URL` is not set, the app creates a SQLite database at `data/app.db`. This is the zero-config default for local development — no setup required. It is meant for development only; for production, set `DATABASE_URL` to a persistent SQL database.
 
 Do not rely on that local file for deployed apps. Containers, serverless functions, and preview environments may reset their filesystem, which means a local SQLite file can disappear between restarts. Set `DATABASE_URL` to a persistent hosted database before production use.
 

package/docs/content/deployment.md

@@ -11,7 +11,7 @@ Agent-native apps use [Nitro](https://nitro.build) under the hood, which means y
 
 Every deployed app needs a persistent SQL database. In local development, agent-native falls back to a SQLite file at `data/app.db`; that is convenient on your machine, but it is not durable in containers, previews, or serverless environments where the filesystem can be reset.
 
-Set `DATABASE_URL` in your deploy provider before promoting an app to production. Agent-native uses Drizzle for schema and queries, so the data layer is portable across Drizzle-compatible SQL backends. The built-in adapters auto-detect Postgres URLs, libSQL/Turso URLs, SQLite file URLs, and Cloudflare D1 bindings. Common choices include Neon or Supabase Postgres, Turso/libSQL, plain Postgres, durable SQLite, and Builder.io-managed environments when available. Turso is one option, not a requirement.
+Set `DATABASE_URL` in your deploy provider before promoting an app to production. Agent-native uses Drizzle for schema and queries, so the data layer is portable across Drizzle-compatible SQL backends and the framework auto-detects the dialect from the URL. See [Database](/docs/database#production) for the adapter list and dialect details.
 
 Use `DATABASE_AUTH_TOKEN` only when your database provider requires a separate token, such as Turso/libSQL. For workspaces, all apps inherit the root `DATABASE_URL` by default; set `<APP_NAME>_DATABASE_URL` when one app should use a different database.
 
@@ -208,13 +208,13 @@ export default defineConfig({
 
 ### Build / Runtime {#env-runtime}
 
-| Variable              | Description                                                                                                                                                                                        |
-| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `PORT`                | Server port (Node.js only)                                                                                                                                                                         |
-| `NITRO_PRESET`        | Override build preset at build time                                                                                                                                                                |
-| `APP_BASE_PATH`       | Mount the app under a prefix (e.g. `/mail`). Set automatically by `agent-native deploy`; leave unset for standalone.                                                                               |
-| `DATABASE_URL`        | Persistent SQL connection string. Required in production; common options include Neon, Supabase, Turso/libSQL, plain Postgres, durable SQLite, and Builder.io-managed environments when available. |
-| `DATABASE_AUTH_TOKEN` | Auth token for providers that require a separate token, such as Turso/libSQL.                                                                                                                      |
+| Variable              | Description                                                                                                                          |
+| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
+| `PORT`                | Server port (Node.js only)                                                                                                           |
+| `NITRO_PRESET`        | Override build preset at build time                                                                                                  |
+| `APP_BASE_PATH`       | Mount the app under a prefix (e.g. `/mail`). Set automatically by `agent-native deploy`; leave unset for standalone.                 |
+| `DATABASE_URL`        | Persistent SQL connection string. Required in production. See [Database](/docs/database#production) for adapter and dialect details. |
+| `DATABASE_AUTH_TOKEN` | Auth token for providers that require a separate token, such as Turso/libSQL.                                                        |
 
 ### Required in Production {#env-required-prod}
 

package/docs/content/dispatch.md

@@ -137,7 +137,7 @@ The whole pipeline is built to survive on every serverless host (Netlify, Vercel
 - **A2A continuation polling.** When Dispatch delegates to another app, it polls the downstream task with a bounded timeout. If the downstream agent takes too long or crashes, Dispatch records the continuation and the retry job picks it up — the user's Slack reply still arrives.
 - **Auto-signed cross-app A2A.** Hosted multi-app workspaces auto-generate per-app A2A credentials at deploy time, so apps in the same workspace can call each other without you ever pasting a JWT secret. Dispatch's agent-discovery layer reads those creds from the workspace database so newly added apps appear as callable peers automatically.
 
-This is the recently-hardened story — see PRs #439, #441, and #443 for the underlying changes. Conceptually: every step that crosses a network or a process boundary is recoverable.
+This is the hardened reliability story. Conceptually: every step that crosses a network or a process boundary is recoverable.
 
 ## Setup {#setup}
 

package/docs/content/external-agents.md

@@ -246,7 +246,11 @@ path; the MCP layer strips that ticket-bearing URL from model-visible
 `structuredContent` and normal open-link metadata. When no embed start URL is
 present, the resource falls back to the app-only `create_embed_session` helper.
 This keeps production hosts that restrict iframe-initiated tool calls on the
-direct route without leaking one-time app session URLs into the transcript.
+direct route without leaking one-time app session URLs into the transcript. If a
+user reopens an old chat after a one-time start ticket has expired, the start
+route returns a small refresh page and posts `agentNative.embedSessionExpired`
+to the wrapper; `embedApp()` clears the stale start URL and mints a fresh ticket
+through `create_embed_session` when it still has the original app route.
 
 ChatGPT gets a dedicated compatibility path through `window.openai`: the launch
 document reads `toolInput`, `toolOutput`, and `toolResponseMetadata` directly,

package/docs/content/faq.md

@@ -65,6 +65,7 @@ The framework ships with production-ready templates you can use as daily drivers
 - **[Brain](/docs/template-brain)** — full-page company chat, cited memory, sources, and review queue
 - **[Assets](/docs/template-assets)** — brand asset libraries, uploads, and generated media
 - **[Slides](/docs/template-slides)** — presentation builder
+- **[Video](/docs/template-videos)** — Remotion-based video editor
 - **[Analytics](/docs/template-analytics)** — data platform (like Amplitude/Mixpanel)
 - **[Mail](/docs/template-mail)** — full-featured email client (like Superhuman)
 - **[Clips](/docs/template-clips)** — async screen + camera recording (replaces Loom)

package/docs/content/frames.md

@@ -1,47 +1,127 @@
 ---
 title: "Frames"
-description: "Embedded agent panel and cloud frame options for running AI agents alongside your app."
+description: "The local dev frame, the embedded agent panel, and the cloud frame — the ways an AI agent runs alongside your app."
 ---
 
 # Frames
 
-Agent-native apps run with an AI agent alongside the app UI. Locally, the agent panel is embedded directly in your app. In the cloud, Builder.io provides a managed frame with collaboration and visual editing.
+Every agent-native app runs with an AI agent next to the app UI. A **frame** is
+the wrapper that hosts both: it shows your app and gives the agent a place to
+chat, run, and (in dev) edit code. There are three frames, sharing one runtime:
 
-## Embedded Agent Panel {#embedded-agent}
+- **Embedded agent panel** — ships inside every app from `@agent-native/core`.
+  This is the sidebar your app renders itself, in development and in production.
+- **Local dev frame** — a thin wrapper that loads your running app in an iframe
+  and adds the same agent panel plus an integrated CLI terminal beside it. Used
+  for local development of templates in this repo.
+- **Builder.io cloud frame** — a managed, hosted frame with collaboration,
+  visual editing, and parallel agent runs.
 
-- Ships with `@agent-native/core` — no separate package needed
-- Agent panel embedded directly in your app with chat and optional CLI terminal
-- Supports multiple AI coding CLIs — switch between them from the settings panel
-- Toggle between production mode (app tools only) and development mode (shared `bash`/`read`/`edit`/`write` coding tools plus database access)
-- Great for local development, self-hosted production, and OSS
+Your app code is identical regardless of which frame hosts it. The agent talks
+to your app through the same actions and application state in every case.
 
-## Supported CLIs {#supported-clis}
+## Embedded agent panel {#embedded-agent}
 
-| CLI         | Command    | Key Flags                                           |
-| ----------- | ---------- | --------------------------------------------------- |
-| Claude Code | `claude`   | --dangerously-skip-permissions, --resume, --verbose |
-| Codex       | `codex`    | --full-auto, --quiet                                |
-| Gemini CLI  | `gemini`   | --sandbox                                           |
-| OpenCode    | `opencode` | —                                                   |
-| Builder.io  | `builder`  | —                                                   |
+The embedded panel is the agent sidebar your app renders. It ships with
+`@agent-native/core` — there is no separate package to install — and is the same
+component in dev and prod.
 
-Switch between CLIs at any time from the agent panel settings. The terminal restarts with the selected CLI.
+- Exported as `AgentPanel` from `@agent-native/core/client`, with a
+  production-only variant `ProductionAgentPanel`.
+- Provides the full Chat / CLI / Workspace surface, so the agent input stays on
+  the shared composer stack used everywhere else in the framework.
+- Reads `application_state.navigation` every turn, so it already knows which
+  view you're in and what's selected — you don't have to re-explain "this".
 
-## [Builder.io Cloud](https://www.builder.io) {#cloud-frame}
+### Dev vs prod tool modes {#tool-modes}
 
-- Runs in the cloud
-- Real-time collaboration — multiple users can watch/interact simultaneously
-- Visual editing, roles and permissions
-- Parallel agent execution for faster iteration
-- Great for team use
+The panel runs in one of two tool modes:
 
-## How It Works {#how-it-works}
+- **Production mode** — the agent only has your app's own tools: the actions you
+  defined with `defineAction`, plus navigation and context. No filesystem or
+  shell access. This is what end users get.
+- **Development mode** — adds the shared coding tools (`bash`, `read`, `edit`,
+  `write`) and database access on top of the app tools, so the agent can change
+  the app's own source. Code requests are gated: when a message requires code
+  (`type: "code"`) and no code-capable frame is connected, the panel shows a
+  dialog explaining that code changes need Agent Native Desktop or Builder;
+  when a frame is connected, the request is routed to it and a code-agent
+  indicator shows while it works (`useSendToAgentChat`).
 
-The framework provides type-safe APIs so you never deal with raw messaging:
+In the local dev frame, the settings cog toggles between these modes. Switching
+to prod hides the frame's own sidebar and shows the app's in-app agent sidebar
+inside the iframe instead, so you can preview exactly what end users see.
 
-1. **Agent chat** — use `sendToAgentChat()` to send messages to the agent
-2. **Generation state** — use `useAgentChatGenerating()` to track when the agent is running
-3. **Polling sync** — database-backed sync keeps UI caches fresh when the agent changes state
-4. **Action system** — `pnpm action <name>` dispatches to callable actions
+## Integrated terminal and CLI switching {#cli-terminal}
 
-Your app code is identical regardless of how the agent is provided.
+In development the panel includes an embedded terminal (`AgentTerminal`, also
+from `@agent-native/core/client`) backed by a PTY server. You can run a real
+coding CLI right beside the app and switch between them; the terminal restarts
+with the selected CLI.
+
+The supported CLIs come from the core CLI registry
+(`packages/core/src/terminal/cli-registry.ts`). Only these commands are allowed
+to spawn — the PTY server validates the requested command against the registry
+allow-list to prevent injection:
+
+| CLI         | Command    | Install package             |
+| ----------- | ---------- | --------------------------- |
+| Claude Code | `claude`   | `@anthropic-ai/claude-code` |
+| Builder.io  | `builder`  | (built in)                  |
+| Codex       | `codex`    | `@openai/codex`             |
+| Gemini CLI  | `gemini`   | `@google/gemini-cli`        |
+| OpenCode    | `opencode` | `opencode-ai`               |
+
+If the selected CLI isn't found on `PATH`, the terminal falls back to running it
+through `npx --yes <install-package>` (where an install package exists). The
+default command is `claude`. Switch CLIs from the agent panel settings at any
+time.
+
+## Builder.io cloud frame {#cloud-frame}
+
+[Builder.io](https://www.builder.io) provides a managed frame that hosts the
+same app and the same agent panel, in the cloud:
+
+- Real-time collaboration — multiple users can watch and interact at once.
+- Visual editing, roles, and permissions.
+- Parallel agent execution for faster iteration.
+- Good for team use, where everyone shares one hosted environment.
+
+Code requests from the embedded panel route to the Builder frame the same way
+they route to the local dev frame, so the dev-vs-prod behavior above is
+consistent across both.
+
+## Runtime APIs {#runtime-apis}
+
+These ship with `@agent-native/core` and are what your app uses to talk to the
+agent, regardless of which frame is hosting it:
+
+1. **Send a message** — `sendToAgentChat()` sends a message to the agent. The
+   `useSendToAgentChat()` hook wraps it with the code-request gating described
+   above and returns a `codeRequiredDialog` element to render.
+2. **Generation state** — `useAgentChatGenerating()` tracks when the agent is
+   running, so the UI can show progress without polling the agent directly.
+3. **Polling sync** — database-backed sync keeps UI caches fresh when the agent
+   changes data or application state.
+4. **Action system** — `pnpm action <name>` dispatches to the same callable
+   actions the agent invokes as tools, so anything the agent can do, you can
+   script.
+
+## Running it {#running}
+
+The embedded agent panel is part of every app — scaffold a template and it's
+already there:
+
+```bash
+pnpm dlx @agent-native/core create my-app --template mail --standalone
+cd my-app
+pnpm dev
+```
+
+The local dev frame is an internal tooling package (it is not published to npm),
+used when developing templates inside this repository. It loads the active
+app's dev server in an iframe and mounts the embedded panel beside it, selecting
+the app via the `app` query param. The integrated CLI terminal requires Agent
+Native Desktop, which provides the local code and PTY access the terminal needs;
+without it, the panel shows the chat surface and prompts you to open Desktop to
+use the CLI.

package/docs/content/getting-started.md

@@ -117,20 +117,21 @@ Once your app is running, the most useful follow-ups are:
 
 Each template is a complete app with UI, agent actions, database schema, and AI instructions ready to go:
 
-| Template                            | Replaces                                        |
-| ----------------------------------- | ----------------------------------------------- |
-| [Calendar](/templates/calendar)     | Google Calendar, Calendly                       |
-| [Content](/templates/content)       | Notion, Google Docs                             |
-| [Brain](/templates/brain)           | Company chat with cited institutional memory    |
-| [Assets](/templates/assets)         | Brand asset libraries and generated media       |
-| [Slides](/templates/slides)         | Google Slides, Pitch                            |
-| [Analytics](/templates/analytics)   | Amplitude, Mixpanel, Looker                     |
-| [Mail](/templates/mail)             | Superhuman, Gmail                               |
-| [Clips](/templates/clips)           | Replaces Loom — screen + camera recording       |
-| [Design](/templates/design)         | HTML prototyping studios                        |
-| [Forms](/docs/template-forms)       | Typeform                                        |
-| [Dispatch](/docs/template-dispatch) | Workspace control plane — integrations, routing |
-| [Starter](/docs/template-starter)   | Minimal scaffold — build from scratch           |
+| Template                              | Replaces                                        |
+| ------------------------------------- | ----------------------------------------------- |
+| [Calendar](/docs/template-calendar)   | Google Calendar, Calendly                       |
+| [Content](/docs/template-content)     | Notion, Google Docs                             |
+| [Brain](/docs/template-brain)         | Company chat with cited institutional memory    |
+| [Assets](/docs/template-assets)       | Brand asset libraries and generated media       |
+| [Slides](/docs/template-slides)       | Google Slides, Pitch                            |
+| [Video](/docs/template-videos)        | Remotion-based video editing                    |
+| [Analytics](/docs/template-analytics) | Amplitude, Mixpanel, Looker                     |
+| [Mail](/docs/template-mail)           | Superhuman, Gmail                               |
+| [Clips](/docs/template-clips)         | Replaces Loom — screen + camera recording       |
+| [Design](/docs/template-design)       | HTML prototyping studios                        |
+| [Forms](/docs/template-forms)         | Typeform                                        |
+| [Dispatch](/docs/template-dispatch)   | Workspace control plane — integrations, routing |
+| [Starter](/docs/template-starter)     | Minimal scaffold — build from scratch           |
 
 Browse the [template gallery](/templates) for live demos, or see [Templates](/docs/cloneable-saas) for the full list and the clone → customize → deploy flow.
 

package/docs/content/mcp-clients.md

@@ -5,7 +5,7 @@ description: "Connect your agent-native app to local MCP servers (claude-in-chro
 
 # MCP Clients
 
-Agent-native apps can also act as MCP **clients** — connecting to locally installed MCP servers and exposing their tools to the agent chat. This is the symmetric counterpart to the [MCP Protocol](./mcp-protocol.md) (which makes your app an MCP server).
+Agent-native apps can also act as MCP **clients** — connecting to locally installed MCP servers and exposing their tools to the agent chat. This is the symmetric counterpart to the [MCP Protocol](/docs/mcp-protocol) (which makes your app an MCP server).
 
 Looking for the other direction — connecting Claude, ChatGPT, Claude Code, Codex, Cursor, or Claude Cowork to an agent-native app? Use [External Agents](/docs/external-agents).