@agent-native/core 0.92.12 → 0.94.0

package/corpus/core/docs/content/cli-adapters.mdx

@@ -5,10 +5,14 @@ description: "Give the agent structured access to any CLI tool (gh, ffmpeg, stri
 
 # CLI Adapters
 
-> **Where this fits:** CLI adapters are one of two adapter seams in the
-> framework. The canonical guide is [Adapters](/docs/sandbox-adapters), which
-> covers both this seam and the `run-code` sandbox seam — including the shared
-> edge/serverless constraint. This page is the quick reference for the CLI side.
+<Callout id="doc-block-clia1fit" tone="info">
+
+**Where this fits:** CLI adapters are one of two adapter seams in the
+framework. The canonical guide is [Adapters](/docs/sandbox-adapters), which
+covers both this seam and the `run-code` sandbox seam — including the shared
+edge/serverless constraint. This page is the quick reference for the CLI side.
+
+</Callout>
 
 A CLI adapter wraps a single command-line tool (`gh`, `ffmpeg`, `stripe`, `aws`) so the agent can discover it, check whether it's installed, and run it with a consistent stdout/stderr/exit-code result. Without this seam, every script reinvents how to invoke a CLI and parse its output.
 
@@ -128,8 +132,7 @@ const result = await gh?.execute(["pr", "list", "--json", "title,url"]);
 
 Wrap a CLI call in `defineAction` to expose it on the action surface — `defineAction` is required when the code runs inside the server action surface; use an adapter directly in a `scripts/` file otherwise. Never call `process.exit` in an action; throw an error instead.
 
-```ts
-// actions/list-prs.ts
+```ts filename="actions/list-prs.ts"
 import { defineAction } from "@agent-native/core/action";
 import { ShellCliAdapter } from "@agent-native/core/adapters/cli";
 import { z } from "zod";

package/corpus/core/docs/content/client.mdx

@@ -11,6 +11,14 @@ These client/React APIs are exported from both `@agent-native/core` and `@agent-
 
 For file-based routing — adding pages, dynamic params, and navigation — see [Routing](/docs/routing).
 
+On this page: [data hooks](#fetching-mutating), [sendToAgentChat](#sendtoagentchat),
+[agent chat context state](#agent-chat-context-state),
+[openAgentSettings](#openagentsettings), [askUserQuestion](#ask-user-question),
+[MCP App host bridge](#mcp-app-host-bridge),
+[dynamic suggestions](#dynamic-suggestions),
+[useAgentChatGenerating](#useagentchatgenerating), [useDbSync](#usedbsync),
+[change versions](#use-change-version), and [cn](#cn).
+
 ## Fetching and Mutating Data {#fetching-mutating}
 
 The primary way to read and write app data from the browser is through the action hooks. Never hand-write `fetch` calls to `/_agent-native/*` routes — use the named helpers instead (see [Actions](/docs/actions)).
@@ -467,3 +475,11 @@ import { cn } from "@agent-native/core/client";
   className
 )} />
 ```
+
+## What's next
+
+- [**Actions**](/docs/actions) — the `defineAction` surface behind every hook on this page
+- [**Routing**](/docs/routing) — file-based pages, dynamic params, and navigation
+- [**Real-Time Sync**](/docs/key-concepts#polling-sync) — how `useDbSync` and change versions keep the UI current
+- [**Context Awareness**](/docs/context-awareness) — the `navigation`/`selection` state dynamic suggestions read
+- [**Generative UI**](/docs/generative-ui) — building richer inline chat controls beyond `askUserQuestion`

package/corpus/core/docs/content/cloneable-saas.mdx

@@ -1,13 +1,15 @@
 ---
-title: "Apps"
+title: "Templates"
 description: "Fork a working SaaS product and make it yours — agent included."
 ---
 
-# Apps
+# Templates
 
-Want to ship your own AI-powered analytics tool? Mail client? Forms builder? Pick an example app, and you've got a working SaaS in minutes — agent, database, auth, and deploy pipeline already wired up.
+Want to ship your own AI-powered analytics tool? Mail client? Forms builder? Pick a template, and you've got a working SaaS in minutes — agent, database, auth, and deploy pipeline already wired up.
 
-Most starter templates give you a blank scaffold and a long TODO list. Agent-native flips that. Each example app is a **complete, SaaS-grade product** — already runnable on day one, already shippable, and entirely yours to customize, brand, and deploy. Think of them as cloneable SaaS, not starter kits: you're forking a finished product, not staring at boilerplate.
+Most starter templates give you a blank scaffold and a long TODO list. Agent-native flips that. Each template is a **complete, SaaS-grade product** — already runnable on day one, already shippable, and entirely yours to customize, brand, and deploy. Think of them as cloneable SaaS, not starter kits: you're forking a finished product, not staring at boilerplate.
+
+Building a workflow with no browser UI at all — a Slack bot, a nightly report, a webhook responder? See [Automation-First Apps](/docs/pure-agent-apps) instead; the templates on this page all ship a full browser UI alongside the agent.
 
 ## Example apps {#catalog}
 
@@ -16,16 +18,16 @@ Each one is a real app you could use today, and the launching pad for your own v
 | App                                       | What it is                                                                                                     |
 | ----------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
 | [**Chat**](/docs/template-chat)           | Minimal chat-first app with durable threads, actions, auth, and a clean path to custom UI or your own backend. |
-| [**Mail**](/docs/template-mail)           | An agent-native Superhuman. Inbox, labels, AI triage, keyboard-first, drafts and sends through the agent.      |
-| [**Calendar**](/docs/template-calendar)   | An agent-native Google Calendar. Events, sync, public booking links, agent-driven scheduling.                  |
-| [**Content**](/docs/template-content)     | Open-source Obsidian for MDX. Local Markdown/MDX, Tiptap editor, Notion sync, real-time multi-user collab.     |
+| [**Mail**](/docs/template-mail)           | Inbox, labels, AI triage, keyboard-first, drafts and sends through the agent.                                  |
+| [**Calendar**](/docs/template-calendar)   | Events, sync, public booking links, agent-driven scheduling.                                                   |
+| [**Content**](/docs/template-content)     | Local Markdown/MDX editing with a Tiptap editor, Notion sync, and real-time multi-user collab.                 |
 | [**Brain**](/docs/template-brain)         | Clean company chat backed by cited institutional memory, approved sources, review gates, and citations.        |
 | [**Assets**](/docs/template-assets)       | Digital asset manager for brand libraries, uploads, references, and on-brand image/video generation.           |
-| [**Slides**](/docs/template-slides)       | An agent-native Google Slides. React-based decks the agent generates and edits directly.                       |
-| [**Analytics**](/docs/template-analytics) | An agent-native Amplitude/Mixpanel. Connect data sources, prompt for charts, pin to dashboards.                |
+| [**Slides**](/docs/template-slides)       | React-based decks the agent generates and edits directly.                                                      |
+| [**Analytics**](/docs/template-analytics) | Connect data sources, prompt for charts, pin to dashboards.                                                    |
 | [**Clips**](/docs/template-clips)         | Async screen + camera recording with transcription, chapters, and AI summaries.                                |
 | [**Design**](/docs/template-design)       | Agent-native HTML prototyping studio for interactive Alpine/Tailwind designs.                                  |
-| [**Forms**](/docs/template-forms)         | An agent-native Typeform. Build, share, collect, and route submissions to Slack, Sheets, webhooks, or Discord. |
+| [**Forms**](/docs/template-forms)         | Build, share, collect, and route submissions to Slack, Sheets, webhooks, or Discord.                           |
 | [**Plan**](/docs/template-plan)           | Visual plans and PR recaps with diagrams, wireframes, and annotations.                                         |
 | [**Dispatch**](/docs/template-dispatch)   | The workspace control plane: shared secrets, reusable integrations, Slack/Telegram, scheduled jobs.            |
 
@@ -165,8 +167,9 @@ You don't have to. Every example app is also available as a hosted app on `agent
 
 Not ready to scaffold? You can add agent-native superpowers to a coding agent you already use with a single command — no app needed. See the [Skills Guide](/docs/skills-guide#app-backed-skills).
 
-## Building on this
+## What's next
 
+- [**Automation-First Apps**](/docs/pure-agent-apps) — the complementary archetype for workflows with no browser UI
 - [**Getting Started**](/docs/getting-started) — create a chat-first app, add an action, render a structured result, and grow into a page
 - [**Messaging the agent**](/docs/messaging) — how users (and you) talk to the agent that ships with each app
 - [**Multi-App Workspace**](/docs/multi-app-workspace) — bundle several apps into one workspace that shares auth, brand, and agent

package/corpus/core/docs/content/code-agents-ui.mdx

@@ -354,6 +354,54 @@ Agent-Native Code treats migration as a capability, not a separate app category.
 
 `/migrate` is the built-in goal for moving an existing app, URL, or described product into Agent-Native. It is a slash goal in the Code workspace — not a separate template to scaffold and not a one-off product — so it shares the same session store, transcript, run controls, and Desktop hub as every other Code session, and you can resume, attach to, inspect, and stop it the same way.
 
+<Diagram id="doc-block-1lox5dw" title="/migrate is a Code session, not a separate app" summary={"A path, URL, or description goes in; the run shares the same store, transcript, and controls as every other Code session, and can emit a portable dossier."}>
+
+```html
+<div class="diagram-migrate">
+  <div class="diagram-col">
+    <div class="diagram-pill">./local-app</div>
+    <div class="diagram-pill">https://example.com</div>
+    <div class="diagram-pill">--describe \"...\"</div>
+  </div>
+  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
+  <div class="diagram-panel center" data-rough>
+    <span class="diagram-pill accent">/migrate goal</span
+    ><small class="diagram-muted">same store · transcript · run controls</small>
+  </div>
+  <div class="diagram-arrow diagram-muted" aria-hidden="true">&rarr;</div>
+  <div class="diagram-col">
+    <div class="diagram-box" data-rough>Migrated app</div>
+    <div class="diagram-pill ok">--emit dossier</div>
+  </div>
+</div>
+```
+
+```css
+.diagram-migrate {
+  display: flex;
+  align-items: center;
+  gap: 12px;
+  flex-wrap: wrap;
+}
+.diagram-migrate .diagram-col {
+  display: flex;
+  flex-direction: column;
+  gap: 8px;
+}
+.diagram-migrate .diagram-arrow {
+  font-size: 22px;
+  line-height: 1;
+}
+.diagram-migrate .center {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  gap: 4px;
+}
+```
+
+</Diagram>
+
 ```bash
 npx @agent-native/core@latest code /migrate ./my-next-app --out ../migrated-app
 npx @agent-native/core@latest code /migrate https://example.com --describe "marketing site plus dashboard"
@@ -363,6 +411,12 @@ npx @agent-native/core@latest migrate ./my-next-app --out ../migrated-app   # sh
 
 Local source paths are read-only; generated output must live outside the source tree. Use `--emit <dir>` to write a portable migration dossier (`AGENTS.md`, `MIGRATION_PLAYBOOK.md`, assessment, and an `ir.json` inventory when available) and hand it to another coding agent instead of opening the internal run surface. `/migrate` reuses the framework's normal credentials system — there is no migration-specific key store. The `@agent-native/migrate` package exposes a reusable engine (`createMigrationRun`, `discoverMigration`, `planMigration`, source/target adapters) for custom workflows.
 
+<Callout id="doc-block-mig8ban" tone="info">
+  The legacy hidden `migration` detail app has been removed. Use the Code
+  workspace, the Desktop Code tab, or an emitted dossier as the supported
+  surfaces.
+</Callout>
+
 Project-specific commands live in:
 
 ```text
@@ -522,3 +576,14 @@ The stylesheet uses the same shadcn-style HSL custom properties as the templates
 ## Limits
 
 The browser template is local-first. It can start and resume runs while its local Node server is alive. For native process lifecycle, terminal launch, and app webviews, use Desktop.
+
+## What's next
+
+- [**Harness Agents**](/docs/harness-agents) — run Claude Code, Codex, or Pi
+  as the agent instead of the built-in Code loop.
+- [**Adapters**](/docs/sandbox-adapters) — swap the sandbox or CLI backend
+  behind the agent's `run-code` tool.
+- [**Agent Teams**](/docs/agent-teams) — the same run-manager foundation for
+  delegating work to background sub-agents.
+- [**Durable Background Runs**](/docs/durable-background-runs) — the hosted
+  execution model behind long-running work.

package/corpus/core/docs/content/components.mdx

@@ -229,19 +229,25 @@ tool-call display.
 ## Native Tool Widgets {#native-tool-widgets}
 
 Use native tool widgets when an action result should render as app-quality UI
-inside chat instead of plain JSON. Built-in reusable outputs include
-`DataTableWidget`, `DataChartWidget`, and `DataWidgetResult`; they are exported
-from `@agent-native/core/client/chat` and the root client entry. See
-[Native Chat UI](/docs/native-chat-ui) for the action result contract.
-
-| API                              | Use when                                                                                |
-| -------------------------------- | --------------------------------------------------------------------------------------- |
-| `DataTableWidget`                | You want an action result to render rows and columns in native chat.                    |
-| `DataChartWidget`                | You want compact bar, line, or area chart output in native chat.                        |
-| `DataWidgetResult`               | You want a typed result shape for `"data-table"`, `"data-chart"`, or `"data-insights"`. |
-| `registerActionChatRenderer()`   | You need an action-declared renderer selected by exact `chatUI.renderer`.               |
-| `registerToolRenderer()`         | You need a product-specific native renderer for a non-core tool result.                 |
-| `registerReservedToolRenderer()` | Framework code needs a reserved renderer that wins before template renderers.           |
+inside chat instead of plain JSON. You don't import or mount a widget
+component yourself — an action builds its result with a server-safe helper
+(`createDataTableWidgetResult()`, `createDataChartWidgetResult()`) from
+`@agent-native/core/data-widgets`, and the runtime picks the matching built-in
+React renderer automatically. `DataTableWidget`, `DataChartWidget`, and
+`DataWidgetResult` are the **result-shape types** — exported from
+`@agent-native/core/client/chat` and the root client entry for typing action
+results, not renderable components. See
+[Native Chat UI](/docs/native-chat-ui#action-declared-widgets) for the full action result
+contract and a worked example.
+
+| API                              | Use when                                                                                 |
+| -------------------------------- | ---------------------------------------------------------------------------------------- |
+| `createDataTableWidgetResult()`  | Your action returns rows and columns that should render as a native table in chat.       |
+| `createDataChartWidgetResult()`  | Your action returns series data that should render as a native bar, line, or area chart. |
+| `DataWidgetResult`               | You need the typed union shape for `"data-table"`, `"data-chart"`, or `"data-insights"`. |
+| `registerActionChatRenderer()`   | You need an action-declared renderer selected by exact `chatUI.renderer`.                |
+| `registerToolRenderer()`         | You need a product-specific native renderer for a non-core tool result.                  |
+| `registerReservedToolRenderer()` | Framework code needs a reserved renderer that wins before template renderers.            |
 
 ## Realtime Collab And Presence {#collab-presence}
 
@@ -482,10 +488,12 @@ action so the UI and agent share the same capability.
 ```ts
 import { defineAction } from "@agent-native/core/action";
 import { completeText } from "@agent-native/core/server";
+import { z } from "zod";
 
 export default defineAction({
   description: "Classify a short message",
-  run: async ({ body }: { body: string }) => {
+  schema: z.object({ body: z.string() }),
+  run: async ({ body }) => {
     const result = await completeText({
       systemPrompt: "Return exactly one label.",
       input: body,
@@ -500,3 +508,11 @@ export default defineAction({
 Use `sendToAgentChat({ background: true, openSidebar: false })` instead when
 the work needs tools, state, auditability, user steering, or multi-step
 reasoning.
+
+## What's next {#whats-next}
+
+- [**Drop-in Agent**](/docs/drop-in-agent) — mount `<AgentSidebar>` and `<AgentPanel>` with a tutorial-first walkthrough
+- [**Native Chat UI**](/docs/native-chat-ui) — the action result contract behind data widgets and custom renderers
+- [**Actions**](/docs/actions) — `defineAction()`, schemas, and the action surface these components call
+- [**Real-Time Collaboration**](/docs/real-time-collaboration) — the collab hooks and presence components in depth
+- [**Sharing**](/docs/sharing) — `<ShareButton>` and `<ShareDialog>` wiring for ownable resources

package/corpus/core/docs/content/context-awareness.mdx

@@ -5,9 +5,13 @@ description: "How the agent knows what the user is looking at: navigation state,
 
 # Context Awareness
 
-> **Developer page.** This page is for developers wiring the app's context layer. For the end-user experience — how the agent uses that context in conversation — see [Using Your Agent](/docs/using-your-agent).
+<Callout tone="info">
 
-How the agent knows what the user is looking at -- and how the agent can control what the user sees.
+**Developer page.** This page is for developers wiring the app's context layer. For the end-user experience — how the agent uses that context in conversation — see [Using Your Agent](/docs/using-your-agent).
+
+</Callout>
+
+How the agent knows what the user is looking at — and how the agent can control what the user sees.
 
 ## Overview {#overview}
 
@@ -17,12 +21,12 @@ To understand what to put in which surface (AGENTS.md vs. skills vs. application
 
 Six patterns solve this:
 
-1. **Navigation state** -- the UI writes a `navigation` key to application-state on every route change
-2. **Current URL** -- the framework writes `__url__` so query params are visible and editable by the agent
-3. **Selection state** -- the UI writes a `selection` key when the user focuses, selects, or multi-selects something meaningful
-4. **`view-screen`** -- an action that reads application state, fetches contextual data, and returns a snapshot of what the user sees
-5. **Prompt handoff** -- UI controls call `sendToAgentChat()` when a click should become an agent turn
-6. **`navigate`** -- a one-shot command from the agent that tells the UI where to go
+1. **Navigation state** — the UI writes a `navigation` key to application-state on every route change
+2. **Current URL** — the framework writes `__url__` so query params are visible and editable by the agent
+3. **Selection state** — the UI writes a `selection` key when the user focuses, selects, or multi-selects something meaningful
+4. **`view-screen`** — an action that reads application state, fetches contextual data, and returns a snapshot of what the user sees
+5. **Prompt handoff** — UI controls call `sendToAgentChat()` when a click should become an agent turn
+6. **`navigate`** — a one-shot command from the agent that tells the UI where to go
 
 <Diagram id="doc-block-1jsrbbk" title="How the agent sees what you see" summary={"The UI writes lightweight state keys; view-screen hydrates them into real records; the agent can write navigate back to move the UI."}>
 
@@ -116,10 +120,10 @@ The UI writes a `navigation` key to application-state on every route change. Thi
 
 What to include in navigation state:
 
-- `view` -- the current page/section, such as "inbox", "form-builder", or "dashboard"
-- Item IDs -- the selected/open item, such as `threadId` or `formId`
-- Semantic aliases -- active tab, label name, or other stable app concepts that help the agent reason
-- Light focus state -- focused row, active tab, current panel
+- `view` — the current page/section, such as "inbox", "form-builder", or "dashboard"
+- Item IDs — the selected/open item, such as `threadId` or `formId`
+- Semantic aliases — active tab, label name, or other stable app concepts that help the agent reason
+- Light focus state — focused row, active tab, current panel
 
 Keep `navigation` small and semantic. It should identify the current screen, not duplicate whole records or mirror every query param. Fetch records in `view-screen` so the agent always gets fresh data.
 
@@ -349,7 +353,7 @@ import { writeAppState } from "@agent-native/core/application-state";
 await writeAppState("navigate", { view: "inbox", threadId: "thread-123" });
 ```
 
-On the UI side you never poll or delete this key by hand. Both directions -- writing `navigation` on every route change and consuming the agent's `navigate` command -- are handled by a single hook, [`useNavigationState`](#use-navigation-state), covered in the next section.
+On the UI side you never poll or delete this key by hand. Both directions — writing `navigation` on every route change and consuming the agent's `navigate` command — are handled by a single hook, [`useNavigationState`](#use-navigation-state), covered in the next section.
 
 The `navigation` key belongs to the UI; the agent must never write to it directly. The agent writes `navigate`, the UI performs the move, and that move is what updates `navigation`.
 
@@ -409,7 +413,7 @@ export function useNavigationState() {
 | `getNavigationState` — map the URL to semantic state   | `navigation` writes, tab-scoped plus a global fallback key                               |
 | `getCommandPath` — map a `navigate` command to a route | command polling, delete-after-read, duplicate-command protection, request-source tagging |
 
-`useAgentRouteState` assumes React Router. When navigation does not live in the URL -- a wizard step, a canvas selection, a non-router shell -- drop down to the lower-level `useSemanticNavigationState` instead: you hand it a ready-made `state` value plus `navigationKeys`/`commandKeys` and an `onCommand` callback, and it stays completely agnostic about React Router.
+`useAgentRouteState` assumes React Router. When navigation does not live in the URL — a wizard step, a canvas selection, a non-router shell — drop down to the lower-level `useSemanticNavigationState` instead: you hand it a ready-made `state` value plus `navigationKeys`/`commandKeys` and an `onCommand` callback, and it stays completely agnostic about React Router.
 
 ## Jitter prevention {#jitter-prevention}
 
@@ -432,7 +436,7 @@ How it works:
 - Agent writes are tagged with `requestSource: "agent"` (the action helpers do this automatically)
 - UI writes include the tab's unique ID via `X-Request-Source` header
 - The server stores the source on each event
-- When processing sync events, the UI filters out events matching its own `ignoreSource` value -- so it doesn't refetch data it just wrote
+- When processing sync events, the UI filters out events matching its own `ignoreSource` value — so it doesn't refetch data it just wrote
 - Events from agents, other tabs, and actions still come through normally
 
 <Diagram id="doc-block-t8sq6j" title="Source tagging stops self-refetch jitter" summary="A tab ignores sync events stamped with its own TAB_ID, but still reacts to agent and other-tab writes.">
@@ -478,3 +482,11 @@ How it works:
 ```
 
 </Diagram>
+
+## What's next {#whats-next}
+
+- [**Using Your Agent**](/docs/using-your-agent) — how end users experience the context the agent sees
+- [**Agent Mentions**](/docs/agent-mentions) — `@`-mention files and agents into a turn instead of relying on ambient context
+- [**Drop-in Agent**](/docs/drop-in-agent) — mount the panel that reads and writes this state
+- [**Real-Time Collaboration**](/docs/real-time-collaboration) — keep app state in sync when the agent and users edit together
+- [**Client Methods**](/docs/client) — the full `application-state` and client helper reference

package/corpus/core/docs/content/creating-templates.mdx

@@ -49,7 +49,6 @@ Every template follows the same broad layout:
 <FileTree
   id="doc-block-1pqnp29"
   title="Template project layout"
-  title="my-template/"
   entries={[
     {
       path: "app/",
@@ -175,8 +174,7 @@ The four areas of every template wire together through one shared action surface
 
 Define domain tables with the framework Drizzle helpers so schemas stay portable across SQLite, Postgres, D1, Turso, Supabase, Neon, and other supported backends:
 
-```ts
-// server/db/schema.ts
+```ts filename="server/db/schema.ts"
 import {
   table,
   text,
@@ -207,8 +205,7 @@ Schema changes must be additive. Add tables and columns through `runMigrations()
 
 For app reads and writes, use Drizzle's query builder and portable operators from `drizzle-orm`. Do not write product code with raw SQL when Drizzle can express the query, and do not import from `drizzle-orm/sqlite-core` or `drizzle-orm/pg-core` in templates.
 
-```ts
-// server/plugins/db.ts
+```ts filename="server/plugins/db.ts"
 import { runMigrations } from "@agent-native/core/db";
 
 export default runMigrations(
@@ -352,8 +349,7 @@ For app navigation, prefer one `navigate` command that includes a same-origin
 `path` when the URL is known. Do not also write `__set_url__` for the same move;
 that key is reserved for the framework URL tools and URL-only filter changes.
 
-```ts
-// actions/navigate.ts
+```ts filename="actions/navigate.ts"
 import { defineAction } from "@agent-native/core/action";
 import { writeAppState } from "@agent-native/core/application-state";
 import { z } from "zod";
@@ -447,8 +443,7 @@ Store template skills in `.agents/skills/<name>/SKILL.md`. If users should be ab
 
 If a template needs an API key, OAuth connection, or provider account, register an onboarding step instead of burying the requirement in a README.
 
-```ts
-// server/plugins/onboarding.ts
+```ts filename="server/plugins/onboarding.ts"
 import { defineNitroPlugin } from "@agent-native/core/server";
 import { registerOnboardingStep } from "@agent-native/core/onboarding";
 
@@ -523,3 +518,14 @@ The generated workspace links the local `@agent-native/core` and
 behavior, or first-party templates can be tested before publishing. The package
 `prepack` scripts build `dist` before linking, which keeps the generated
 workspace pointed at current build output.
+
+## What's next
+
+- [**Writing Agent Instructions**](/docs/writing-agent-instructions) — how to
+  keep `AGENTS.md` and skills skimmable as the template grows.
+- [**Agent-Native Toolkit**](/docs/agent-native-toolkit) — reusable sharing,
+  settings, history, and review surfaces instead of rebuilding them per app.
+- [**Multi-App Workspace**](/docs/multi-app-workspace) — make the template fit
+  naturally alongside sibling apps and Dispatch.
+- [**Cloneable SaaS**](/docs/cloneable-saas) — turn a template into a
+  publishable, monetizable product.

package/corpus/core/docs/content/cross-app-sso.mdx

@@ -9,7 +9,11 @@ Each hosted app at `*.agent-native.com` runs its own deployment with its **own s
 
 This is the same trust primitive [A2A](/docs/a2a-protocol) and [External Agents](/docs/external-agents) already use — an `A2A_SECRET`-signed JWT verified at the request boundary — applied to the human sign-in path instead of agent-to-agent calls.
 
-> **Unified deploy vs. per-domain deploy.** If you host all apps at one origin (`your-agents.com/mail`, `your-agents.com/calendar`), you already get shared login via a single cookie domain — no federation needed. Cross-App SSO is only necessary when apps run on separate domains. See [Multi-App Workspaces — Unified deploy](/docs/multi-app-workspace#deployment).
+<Callout tone="info">
+
+**Unified deploy vs. per-domain deploy.** If you host all apps at one origin (`your-agents.com/mail`, `your-agents.com/calendar`), you already get shared login via a single cookie domain — no federation needed. Cross-App SSO is only necessary when apps run on separate domains. See [Multi-App Workspaces — Unified deploy](/docs/multi-app-workspace#deployment).
+
+</Callout>
 
 ## What & why {#what-why}
 
@@ -86,15 +90,17 @@ The flow is a standard authorize → signed-token → callback redirect, with em
 
 </Diagram>
 
-1. **App → Dispatch (authorize).** The app sends the user to the identity authority:
+1. **App → Dispatch (authorize).** The app-side `GET /_agent-native/identity/login` route (what the "Sign in with Agent-Native" button links to) builds the redirect and sends the user to the identity authority:
 
-   ```
+   ```http
    GET https://dispatch.agent-native.com/_agent-native/identity/authorize
        ?app=<requesting-app>
        &redirect_uri=<app-callback-url>
        &state=<csrf-state>
    ```
 
+   `redirect_uri` is this app's own `GET /_agent-native/identity/callback` route — the route that receives the signed token in step 3.
+
 <Endpoint id="doc-block-1wojo41" title="Identity authorize endpoint" method="GET" path="/_agent-native/identity/authorize" summary="Dispatch (identity authority) authenticates the human and redirects back with a signed identity token" auth="Dispatch session (interactive login if none)" params={[
   {
     "name": "app",
@@ -143,7 +149,7 @@ The flow is a standard authorize → signed-token → callback redirect, with em
    | `scope`      | Always `"identity"` — this token authorizes sign-in only |
    | `exp`        | **≤ 2 minutes** from issue                               |
 
-4. **App verifies and JIT-links by email.** The app verifies the token signature with its own `A2A_SECRET`, checks `scope: "identity"` and `exp`, then performs **just-in-time linking strictly by verified email**:
+4. **App verifies and JIT-links by email.** The app's `GET /_agent-native/identity/callback` route verifies the token signature with its own `A2A_SECRET`, checks `scope: "identity"` and `exp`, then performs **just-in-time linking strictly by verified email**:
    - If a local user with that email exists → reuse it unchanged.
    - If not → create a local user for that email.
 
@@ -290,9 +296,13 @@ Once one app is verified, repeat steps 2–3 for the next app — setting `AGENT
 **5. Rollback = unset the env var on that app's deploy.**
 To revert any app, **remove `AGENT_NATIVE_IDENTITY_HUB_URL` from that app's environment and redeploy/restart it.** The app immediately returns to its prior auth behavior. There is **no data change to undo** — identity rows were only ever added, and unsetting the variable simply makes the federation path dormant again. Each app's cutover and rollback are independent and reversible.
 
-> Rollout logs users out as each app is enabled (they re-auth via Dispatch), but they always log back into the **same email-matched account with data intact**, because identity rows are never destroyed or renamed — only added.
+<Callout tone="info">
+
+Rollout logs users out as each app is enabled (they re-auth via Dispatch), but they always log back into the **same email-matched account with data intact**, because identity rows are never destroyed or renamed — only added.
+
+</Callout>
 
-## Related {#related}
+## What's next {#whats-next}
 
 - [Authentication](/docs/authentication) — local auth modes, sessions, orgs, the `A2A_SECRET` env var.
 - [A2A Protocol](/docs/a2a-protocol) — the signed-JWT, verify-at-the-boundary trust model this reuses.

package/corpus/core/docs/content/data-programs.mdx

@@ -321,7 +321,7 @@ The `"program"` dashboard panel source is one adoption of the primitive, impleme
 
 Any app can implement the same adoption for its own dashboards/tables: call `run-data-program` (or `runDataProgram` directly if you're inside the same server process) from your own read path, and hand the returned `rows`/`schema` to your own rendering components.
 
-## Related docs {#related}
+## What's next {#whats-next}
 
 - [Extensions](/docs/extensions) — the sandboxed mini-app primitive data programs share a security posture and sharing model with, but with a UI of its own.
 - [Actions](/docs/actions) — the `run-code` conventions and sandbox globals (`providerFetch`, `appAction`, etc.) data programs are built on.

package/corpus/core/docs/content/database.mdx

@@ -116,8 +116,7 @@ _Planned (not yet available):_ when connected to Builder.io, your app will be ab
 
 Each template creates a lazy, singleton Drizzle client by calling `createGetDb(schema)` from `@agent-native/core/db`. The canonical location is `server/db/index.ts`:
 
-```ts
-// server/db/index.ts
+```ts filename="server/db/index.ts"
 import { createGetDb } from "@agent-native/core/db";
 import * as schema from "./schema.js";
 
@@ -257,9 +256,14 @@ All database schema updates must be **strictly additive**.
 - **Do not rename tables or columns.** Renaming a column or table looks like a drop + create sequence to Drizzle, which will permanently delete your existing production data.
 - If a column needs to be renamed or replaced, add the new column alongside the old one, update your application code to read from/write to both, migrate the data, and only retire the old column in a later release once no active deployments are referencing it.
 
-> [!WARNING]
-> **Never run `drizzle-kit push` against a production database.**
-> Template database schemas only define app-specific domain tables; they do not define central framework tables (`user`, `session`, `application_state`, etc.). If you run `drizzle-kit push` against production, Drizzle will detect these framework tables as "not in schema" and attempt to drop them, causing immediate system-wide failure and data loss.
+<Callout tone="risk">
+  **Never run `drizzle-kit push` against a production database.** Template
+  database schemas only define app-specific domain tables; they do not define
+  central framework tables (`user`, `session`, `application_state`, etc.). If
+  you run `drizzle-kit push` against production, Drizzle will detect these
+  framework tables as "not in schema" and attempt to drop them, causing
+  immediate system-wide failure and data loss.
+</Callout>
 
 ### Safe Migration Path
 
@@ -298,3 +302,11 @@ Instead of pushing directly, schema changes should be applied via SQL migrations
 | --------------------- | ------------------------------------------------------------------------------------------------------- |
 | `DATABASE_URL`        | Persistent SQL connection string (unset = local SQLite; `pglite:./data/pglite` = local Postgres opt-in) |
 | `DATABASE_AUTH_TOKEN` | Auth token for providers that require a separate token, such as Turso/libSQL                            |
+
+## What's next
+
+- [**Security — Data Scoping**](/docs/security#data-scoping) — how `owner_email` and access helpers scope reads and writes
+- [**Sharing**](/docs/sharing#building) — `ownableColumns()` and the visibility model for shared resources
+- [**Server**](/docs/server#request-context) — how actions and custom routes each import `getDb`
+- [**Deployment**](/docs/deployment#persistent-database) — connecting a persistent database per deploy target
+- [**Actions**](/docs/actions#access-control) — a complete, paste-ready action that reads and writes through `getDb`/`schema`