@agent-native/core 0.92.12 → 0.94.0

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

@@ -6,8 +6,12 @@ search: "adapters sandbox adapter cli adapter run-code SandboxAdapter CliAdapter
 
 # Adapters
 
-> **Who is this for:** host authors extending the runtime. App developers rarely
-> need this — the defaults work out of the box.
+<Callout id="doc-block-adap1who" tone="info">
+
+**Who is this for:** host authors extending the runtime. App developers rarely
+need this — the defaults work out of the box.
+
+</Callout>
 
 Agent-Native has two adapter seams that factor a concern out behind a narrow,
 swappable interface:
@@ -26,15 +30,15 @@ not run on edge/worker runtimes — see [Edge and serverless](#edge-serverless).
 | You want to…                                                               | Use                                          |
 | -------------------------------------------------------------------------- | -------------------------------------------- |
 | Swap the backend that runs the agent's **`run-code` tool**                 | **Sandbox adapters** (this page)             |
-| Wrap a CLI tool (`gh`, `ffmpeg`) for the agent to call                     | **CLI adapters** (this page)                 |
+| Wrap a CLI tool (`gh`, `ffmpeg`) for the agent to call                     | [CLI Adapters](/docs/cli-adapters)           |
 | Render a Claude-Code/Codex-style **coding workspace UI**                   | [Agent-Native Code UI](/docs/code-agents-ui) |
 | Run Claude Code / Codex / Pi **as the agent**, with their own loop + tools | [Harness Agents](/docs/harness-agents)       |
 
-# Sandbox Adapters
+## Sandbox Adapters {#sandbox-adapters}
 
 The `run-code` tool runs agent-supplied JavaScript in an isolated environment. **Sandbox adapters** factor the _execution_ concern out of that tool so the backend can be swapped — a local child process by default, or a Docker / remote / durable runner — without touching the agent loop, `run-code.ts`, the localhost bridge, the env scrub, or the output formatting.
 
-## Why a seam {#why}
+### Why a seam {#why}
 
 The default backend spawns a locked-down local Node child process. That's bounded by the hosting process: on the hosted platform it shares the agent loop's soft execution ceiling (~40s before timeout/continuation thrash). A remote or durable adapter is the lever to exceed that ceiling — it runs large data jobs to completion independently of the request lifecycle.
 
@@ -86,14 +90,13 @@ Keeping the contract narrow means a remote adapter inherits the same security po
 
 </Diagram>
 
-## The interface {#interface}
+### The interface {#interface}
 
 The seam lives in core at `packages/core/src/coding-tools/sandbox/` — `adapter.ts` (the contract), `index.ts` (selection: `getSandboxAdapter()` / `registerSandboxAdapter()`), and `local-child-process-adapter.ts` (the default). It is wired in-package by `run-code.ts`; a host plugs in a different backend through the `index.ts` registration helper (or, for a Docker backend, via the [blueprint](/docs/blueprint-installer) that edits these files directly).
 
 <FileTree
   id="doc-block-b1k8n3"
   title="The sandbox seam in core"
-  title="packages/core/src/coding-tools/sandbox/"
   entries={[
     {
       path: "adapter.ts",
@@ -160,7 +163,7 @@ interface SandboxRunResult {
 }
 ```
 
-## The default: `LocalChildProcessAdapter` {#default}
+### The default: `LocalChildProcessAdapter` {#default}
 
 Out of the box, `getSandboxAdapter()` returns `LocalChildProcessAdapter` (`id: "local-child-process"`). It preserves the historical `run-code` behavior byte-for-byte:
 
@@ -170,10 +173,13 @@ Out of the box, `getSandboxAdapter()` returns `LocalChildProcessAdapter` (`id: "
 - A timeout sends `SIGTERM`, then `SIGKILL` after a 2s grace period.
 - Temp files are cleaned up best-effort after the run.
 
-> [!WARNING]
-> The default adapter uses `node:child_process`, which does not exist on edge/worker runtimes. Run `run-code` in a standard Node.js environment, or register a remote adapter — see [Edge and serverless](#edge-serverless).
+<Callout id="doc-block-adap1def" tone="warning">
+
+The default adapter uses `node:child_process`, which does not exist on edge/worker runtimes. Run `run-code` in a standard Node.js environment, or register a remote adapter — see [Edge and serverless](#edge-serverless).
+
+</Callout>
 
-## Selecting an adapter {#selection}
+### Selecting an adapter {#selection}
 
 Resolution order — an explicitly registered adapter wins; otherwise the env var selects a built-in; otherwise the local default is used:
 
@@ -181,7 +187,7 @@ Resolution order — an explicitly registered adapter wins; otherwise the env va
 registerSandboxAdapter(adapter)  →  AGENT_NATIVE_SANDBOX  →  local default
 ```
 
-### `AGENT_NATIVE_SANDBOX` env var {#env}
+#### `AGENT_NATIVE_SANDBOX` env var {#env}
 
 Selects a built-in adapter by id. Currently only `local` (the default) is wired; unknown values fall back to local rather than failing the run.
 
@@ -189,7 +195,7 @@ Selects a built-in adapter by id. Currently only `local` (the default) is wired;
 AGENT_NATIVE_SANDBOX=local   # the default — explicit
 ```
 
-### `registerSandboxAdapter()` {#register}
+#### `registerSandboxAdapter()` {#register}
 
 A host process overrides the backend for all subsequent `run-code` invocations through the seam's `index.ts` — for example, to run every call in a remote container:
 
@@ -211,7 +217,7 @@ registerSandboxAdapter(new RemoteSandboxAdapter());
 // Pass `null` to clear the override and fall back to env-var / default resolution.
 ```
 
-## The seam for a durable runner {#durable}
+### The seam for a durable runner {#durable}
 
 This interface is deliberately the seam for a future remote/durable sandbox. A remote or durable adapter (Docker, a Vercel-Sandbox-style runner, or a queued background worker) would:
 
@@ -221,54 +227,25 @@ This interface is deliberately the seam for a future remote/durable sandbox. A r
 
 Register it under a new `AGENT_NATIVE_SANDBOX` value (e.g. `remote`) and/or via `registerSandboxAdapter()`. The agent loop and `run-code.ts` never change.
 
-> [!TIP]
-> The `agent-native add sandbox docker` blueprint emits a full, self-contained recipe for implementing a Docker adapter against this seam. See [Blueprint Installer](/docs/blueprint-installer).
+<Callout id="doc-block-adap1tip" tone="info">
 
-# CLI Adapters
+The `agent-native add sandbox docker` blueprint emits a full, self-contained recipe for implementing a Docker adapter against this seam. See [Blueprint Installer](/docs/blueprint-installer).
 
-The other adapter seam 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. Every CLI adapter implements `CliAdapter`:
+</Callout>
 
-```ts
-import type { CliAdapter, CliResult } from "@agent-native/core/adapters/cli";
+## CLI Adapters {#cli-adapters}
 
-interface CliAdapter {
-  name: string; // "gh", "stripe", "ffmpeg"
-  description: string; // What the agent sees during discovery
-  isAvailable(): Promise<boolean>;
-  execute(args: string[]): Promise<CliResult>;
-}
+The other adapter seam wraps a single command-line tool (`gh`, `ffmpeg`, `stripe`, `aws`) behind a `CliAdapter` contract, so the agent can discover it, check whether it's installed, and run it with a consistent stdout/stderr/exit-code result.
 
-interface CliResult {
-  stdout: string;
-  stderr: string;
-  exitCode: number;
-}
-```
+See [CLI Adapters](/docs/cli-adapters) for the `CliAdapter` contract, `ShellCliAdapter`, `CliRegistry`, and the action-wrapping pattern — this page only covers the seam it shares with sandbox adapters.
 
-For most CLIs, `ShellCliAdapter` wraps any binary with sensible defaults, and `CliRegistry` collects adapters for runtime discovery:
-
-```ts
-import { CliRegistry, ShellCliAdapter } from "@agent-native/core/adapters/cli";
-
-const cliRegistry = new CliRegistry();
-cliRegistry.register(
-  new ShellCliAdapter({
-    command: "gh",
-    description: "GitHub CLI — manage repos, PRs, issues, and releases",
-  }),
-);
-
-await cliRegistry.describe(); // [{ name, description, available }] for discovery
-const gh = cliRegistry.get("gh");
-const result = await gh?.execute(["pr", "list", "--json", "title,url"]);
-```
+## Edge and serverless {#edge-serverless}
 
-Wrap a CLI call in `defineAction` to expose it on the action surface. See the [CLI Adapters](/docs/cli-adapters) quick reference for `ShellCliAdapter` options, custom adapters, and the action-wrapping pattern.
+<Callout id="doc-block-adap1edge" tone="warning">
 
-## Edge and serverless {#edge-serverless}
+Both adapter seams rely on Node.js system bindings. The sandbox `LocalChildProcessAdapter` and CLI adapters (`ShellCliAdapter` and custom adapters) use `node:child_process` (`execFile` / `spawn`), which **does not exist** on edge/worker runtimes such as Cloudflare Workers or Netlify Edge Functions. If you deploy server routes to these edge presets, executing these adapters throws a runtime exception. Run adapter endpoints and tasks in a standard Node.js environment (traditional server containers or serverless Node functions) — or, for the sandbox seam, register a remote adapter that ships work out of process.
 
-> [!WARNING]
-> Both adapter seams rely on Node.js system bindings. The sandbox `LocalChildProcessAdapter` and CLI adapters (`ShellCliAdapter` and custom adapters) use `node:child_process` (`execFile` / `spawn`), which **does not exist** on edge/worker runtimes such as Cloudflare Workers or Netlify Edge Functions. If you deploy server routes to these edge presets, executing these adapters throws a runtime exception. Run adapter endpoints and tasks in a standard Node.js environment (traditional server containers or serverless Node functions) — or, for the sandbox seam, register a remote adapter that ships work out of process.
+</Callout>
 
 ## What's next
 

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

@@ -415,3 +415,11 @@ AGENT_NATIVE_KEYS_WORKSPACE_FALLBACK=1
 ```
 
 Workspace-scope secret writes still require org owner/admin role regardless of this flag.
+
+## What's next
+
+- [**Authentication**](/docs/authentication) — auth modes, cookie realms, and session details this page builds on
+- [**Multi-Tenancy**](/docs/multi-tenancy) — the org-membership model behind `org_id` scoping
+- [**Sharing**](/docs/sharing) — the `ownableColumns()` and access-guard pattern applied to shareable resources
+- [**Messaging**](/docs/messaging#env-vars) — per-integration webhook signing secrets referenced in the checklist above
+- [**Deployment**](/docs/deployment) — the production environment variables this checklist assumes are set

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

@@ -96,8 +96,7 @@ server/routes/
 
 Each route exports a `defineEventHandler`:
 
-```ts
-// server/routes/api/health.get.ts
+```ts filename="server/routes/api/health.get.ts"
 import { defineEventHandler } from "h3";
 
 export default defineEventHandler(() => ({
@@ -137,8 +136,7 @@ Use the action `http` option to shape direct HTTP access: actions are `POST` by
 
 For a read-only status endpoint, keep it as an action:
 
-```ts
-// actions/get-status.ts
+```ts filename="actions/get-status.ts"
 import { defineAction } from "@agent-native/core/action";
 import { z } from "zod";
 
@@ -171,8 +169,7 @@ what happened. For narrow server-side transforms that intentionally do not need
 tools, chat history, or run state, use `completeText()` as an explicit escape
 hatch.
 
-```ts
-// actions/classify-message.ts
+```ts filename="actions/classify-message.ts"
 import { defineAction } from "@agent-native/core/action";
 import { completeText } from "@agent-native/core/server";
 import { z } from "zod";
@@ -237,8 +234,7 @@ Actions mounted by the framework automatically run with request context. Custom
 
 Plugins live in `server/plugins/` and run at startup. Use them for migrations, provider setup, recurring jobs, integration adapters, and framework plugin configuration.
 
-```ts
-// server/plugins/db.ts
+```ts filename="server/plugins/db.ts"
 import { runMigrations } from "@agent-native/core/db";
 
 export default runMigrations(
@@ -416,8 +412,11 @@ Inbound webhooks should verify, persist, and return quickly. Long-running agent
 
 </Diagram>
 
-> [!WARNING]
-> Do not rely on unawaited promises after returning a response — serverless hosts freeze the execution. See [Messaging](/docs/messaging) for the canonical integration queue.
+<Callout tone="warning">
+  Do not rely on unawaited promises after returning a response — serverless
+  hosts freeze the execution. See [Messaging](/docs/messaging) for the canonical
+  integration queue.
+</Callout>
 
 ## Advanced: Escape Hatches {#advanced-escape-hatches}
 
@@ -459,3 +458,11 @@ const handler = createProductionAgentHandler({
   systemPrompt: "You are the app agent...",
 });
 ```
+
+## What's next
+
+- [**Actions**](/docs/actions) — the default operation surface; reach for a custom route only when it doesn't fit
+- [**Database**](/docs/database) — the `getDb()`/`schema` pattern custom routes and actions both import
+- [**Security**](/docs/security#access-guards) — `accessFilter`/`assertAccess` and the full data-scoping model
+- [**Messaging**](/docs/messaging) — the canonical inbound-webhook integration queue pattern
+- [**MCP Protocol**](/docs/mcp-protocol) — the `/_agent-native/mcp` endpoint this server mounts automatically

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

@@ -1,13 +1,13 @@
 ---
 title: "Sharing & Privacy"
-description: "Google-Docs-style sharing, built into the framework. Every user-created resource — docs, dashboards, designs, decks, clips, recordings, forms — gets the same private-by-default model with one consistent share UI."
+description: "Familiar, consistent sharing built into the framework. Every user-created resource — docs, dashboards, designs, decks, clips, recordings, forms — gets the same private-by-default model with one consistent share UI."
 ---
 
 # Sharing & Privacy
 
 Every resource a user creates in an agent-native app — a document, a dashboard, a design, a deck, a screen recording, a meeting transcript, a form, a booking link — is **private to the creator by default**. Other people see it only when the creator explicitly shares it, or changes its visibility to `org` or `public`.
 
-It looks and works like Google Docs. The same share button, the same dialog, the same three-tier visibility model, the same per-user/per-org grants — across every template, with no per-app reinvention.
+It's one familiar sharing model everywhere: the same share button, the same dialog, the same three-tier visibility model, the same per-user/per-org grants — across every template, with no per-app reinvention.
 
 ## Why one model {#why}
 
@@ -92,7 +92,7 @@ Every template that stores user-authored work uses this model. Concretely:
 - **Content** — documents
 - **Slides** — decks
 - **Design** — designs and assets
-- **Clips** — screen recordings (Loom-style)
+- **Clips** — screen recordings
 - **Plan** — visual plans and PR recaps
 - **Forms** — form definitions
 - **Calendar** — events and booking links
@@ -115,7 +115,7 @@ Every shareable resource gets a share button in its header. Clicking it opens a
 
 - Visibility selector (`Private` / `Organization` / `Public link`).
 - "Add people or teams" autocomplete — search users in the org or paste an email.
-- A Google Docs-style `Notify people` checkbox for individual email grants.
+- A `Notify people` checkbox for individual email grants.
 - A list of current grants with role pickers and a remove control.
 - A copy-link button that respects the current visibility.
 
@@ -294,7 +294,7 @@ export const deckShares = createSharesTable("deck_shares");
 
 One registration call in `server/db/index.ts`:
 
-```ts
+```ts filename="server/db/index.ts"
 import { registerShareableResource } from "@agent-native/core/sharing";
 
 registerShareableResource({
@@ -339,9 +339,9 @@ For resources that execute code or carry elevated trust (like extensions), set `
 
 Sharing rides on the framework's broader data-scoping model — list/read/write access to ownable tables goes through `accessFilter()` / `resolveAccess()` / `assertAccess()`, and `org_id`-tagged resources are invisible across orgs. See [Security → Data Scoping](/docs/security#data-scoping) for the full pipeline, the CI guard, and the threat surface.
 
-## See also {#see-also}
+## What's next {#see-also}
 
-- [Security & Data Scoping](/docs/security) — the access-filter and ownership model that sharing rides on.
-- [Authentication](/docs/authentication) — sessions, organizations, and how identity flows into the request context.
-- [Extensions](/docs/extensions#sharing) — sharing in the sandboxed mini-app surface.
-- [Creating Templates](/docs/creating-templates) — wiring `ownableColumns` into a new template's schema.
+- [**Security — Data Scoping**](/docs/security#data-scoping) — the access-filter and ownership model that sharing rides on
+- [**Authentication**](/docs/authentication) — sessions, organizations, and how identity flows into the request context
+- [**Extensions**](/docs/extensions#sharing) — sharing in the sandboxed mini-app surface
+- [**Creating Templates**](/docs/creating-templates) — wiring `ownableColumns` into a new template's schema

package/corpus/core/docs/content/skills-guide.mdx

@@ -5,7 +5,7 @@ description: "How skills work in agent-native: framework skills, domain skills,
 
 # Skills Guide
 
-Skills are Markdown files that give the agent deep knowledge about specific patterns and workflows.
+Skills are Markdown files that give the agent deep knowledge about specific patterns and workflows. Instead of cramming every rule into one system prompt, you split knowledge into focused files the agent loads only when a task actually needs them — keeping the default context small while still letting the agent go deep on demand.
 
 ## What are skills {#what-are-skills}
 
@@ -124,7 +124,11 @@ Current app-backed skills include `visual-plan`, `visual-recap`, and
 `visualize-repo` from Plan, `visual-edit` from Design, `assets` from Assets, and
 `content` for repo-backed docs/blog/MDX editing.
 
-> **Full details below:** the mechanics of app-backed skills (manifest format, CLI commands, marketplace adapters, auto-update hashing) are covered in [App-backed skills — full details](#app-backed-skills-full).
+<Callout tone="info">
+
+**Full details below:** the mechanics of app-backed skills (manifest format, CLI commands, marketplace adapters, auto-update hashing) are covered in [App-backed skills — full details](#app-backed-skills-full).
+
+</Callout>
 
 ## Creating custom skills {#creating-skills}
 
@@ -179,7 +183,11 @@ The frontmatter `name` and `description` are used by the agent's tool system for
 
 Save the file at `.agents/skills/my-skill/SKILL.md`. The directory name should match the `name` in frontmatter.
 
-> **See also:** [Writing Agent Instructions](/docs/writing-agent-instructions) for how to word skill descriptions, apply progressive disclosure, and keep `AGENTS.md` lean. Both pages use the `project-imports` skill as a running example.
+<Callout tone="info">
+
+**See also:** [Writing Agent Instructions](/docs/writing-agent-instructions) for how to word skill descriptions, apply progressive disclosure, and keep `AGENTS.md` lean. Both pages use the `project-imports` skill as a running example.
+
+</Callout>
 
 ## Skill scope: runtime vs dev {#skill-scope}
 
@@ -269,33 +277,37 @@ This replaces the old hack of relying on Claude Code only reading `.claude/skill
 
 </Diagram>
 
-> **See also:** [Writing Agent Instructions](/docs/writing-agent-instructions) for how to word skill descriptions, apply progressive disclosure, and keep `AGENTS.md` lean.
-
 ## Skills vs AGENTS.md {#skills-vs-agents-md}
 
-> **AGENTS.md** — The overview. Lists all scripts, describes the data model, explains the app architecture. The agent reads this first to understand the app.
->
-> **Skills** — Deep dives. Each skill focuses on one pattern with detailed rules, code examples, and do/don't lists. The agent reads these when it needs to follow a specific pattern.
+<Callout tone="info">
+
+**AGENTS.md** — The overview. Lists all scripts, describes the data model, explains the app architecture. The agent reads this first to understand the app.
+
+**Skills** — Deep dives. Each skill focuses on one pattern with detailed rules, code examples, and do/don't lists. The agent reads these when it needs to follow a specific pattern.
+
+</Callout>
 
 `AGENTS.md` tells the agent _what_ the app does. Skills tell the agent _how_ to do specific things correctly. Both are needed — `AGENTS.md` for orientation, skills for execution.
 
 ## Skills vs memory {#skills-vs-memory}
 
-> **Skills** — Authored, reusable how-to guides. Apply to every user, invoked on demand when the task matches.
->
-> **Memory (`LEARNINGS.md` / `memory/MEMORY.md`)** — Shared project learnings and personal structured memory loaded every turn.
+<Callout tone="info">
+
+**Skills** — Authored, reusable how-to guides. Apply to every user, invoked on demand when the task matches.
+
+**Memory (`LEARNINGS.md` / `memory/MEMORY.md`)** — Shared project learnings and personal structured memory loaded every turn.
+
+</Callout>
 
 If the knowledge applies to _everyone_ working in the app ("always prefer CTEs over subqueries"), it's a skill or shared `LEARNINGS.md`. If it's about _this particular user_ ("Steve likes concise answers"), it belongs in `memory/MEMORY.md`. See [Workspace Memory](/docs/workspace#memory) for the full treatment.
 
----
+## Skills vs SQL resources {#skills-vs-resources}
 
-# Advanced
+This page frames a skill as a file at `.agents/skills/<name>/SKILL.md`. [Workspace](/docs/workspace#skills) frames the same skill as a SQL resource at path `skills/<slug>/SKILL.md`, scoped workspace/shared/personal. These are the same concept from two angles: Code mode reads and writes the file directly; App mode stores it as a resource row so it works without a filesystem. Author the content using this page's format either way.
 
 ## App-backed skills — full details {#app-backed-skills-full}
 
-App-backed skills package an agent-native app as a skill marketplace artifact.
-The bundle can include agent instructions, exported skills, MCP connector
-metadata, hosted/local launch instructions, and UI surfaces such as MCP Apps.
+The manifest format, CLI commands, marketplace adapters, and auto-update hashing behind [app-backed skills](#app-backed-skills) in full:
 
 Each app-backed skill starts with `agent-native.app-skill.json` at the app root:
 
@@ -412,3 +424,10 @@ npx @agent-native/core@latest skills update scaffold --project
 `AGENTS.md` and `.agents/skills` stay canonical. The update command also repairs
 Claude compatibility links (`CLAUDE.md` and `.claude/skills`) so Claude Code sees
 the same instructions without maintaining a second copy.
+
+## What's next {#whats-next}
+
+- [**Writing Agent Instructions**](/docs/writing-agent-instructions) — word skill descriptions and split guidance across AGENTS.md, skills, and memory
+- [**Workspace**](/docs/workspace#skills) — where skills live as SQL resources in App mode
+- [**Agent Mentions**](/docs/agent-mentions) — the `/`-command trigger that invokes a skill in chat
+- [**Plan plugin & marketplace**](/docs/plan-plugin) — a real app-backed skill's end-to-end install and auto-update flow

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

@@ -1,6 +1,6 @@
 ---
 title: "Analytics"
-description: "Ask analytics questions in plain English, get charts and dashboards back. An open-source replacement for Amplitude, Mixpanel, and Looker."
+description: "Ask analytics questions in plain English, get charts and dashboards back — connect your own warehouse and event sources, and own the code and the data."
 ---
 
 # Analytics
@@ -11,12 +11,12 @@ Ask analytics questions in plain English, get charts and dashboards back. The ag
   <Screen
     surface="desktop"
     html={
-      "<div style='display:flex;flex-direction:column;gap:14px;padding:18px;min-height:500px;box-sizing:border-box'><h1 style='margin:0'>Agent-Native Templates</h1><p class='wf-muted' style='margin:0'>Adoption and engagement across the last 12 weeks.</p><div style='display:grid;grid-template-columns:repeat(3,1fr);gap:12px'><div class='wf-card'><small class='wf-muted'>Weekly active users</small><br/><strong>24,318</strong><br/><span class='wf-pill accent'>+12.4%</span></div><div class='wf-card'><small class='wf-muted'>New signups</small><br/><strong>1,842</strong><br/><span class='wf-pill accent'>+8.7%</span></div><div class='wf-card'><small class='wf-muted'>Revenue MRR</small><br/><strong>$48,210</strong><br/><span class='wf-pill accent'>+21.3%</span></div></div><div style='display:grid;grid-template-columns:1fr 1fr;gap:12px;flex:1'><div class='wf-card' style='display:flex;flex-direction:column;gap:10px'><strong>Weekly active users</strong><div style='flex:1;display:flex;align-items:end;gap:8px'><div style='height:38%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:44%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:58%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:74%;flex:1;background:var(--wf-accent-soft)'></div></div></div><div class='wf-card' style='display:flex;flex-direction:column;gap:10px'><strong>Revenue over time</strong><div style='flex:1;display:flex;align-items:end;gap:8px'><div style='height:32%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:48%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:63%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:80%;flex:1;background:var(--wf-accent-soft)'></div></div></div></div><div class='wf-card'><strong>Signups by source</strong><br/><small class='wf-muted'>Lower chart begins below the main charts.</small></div></div>"
+      "<div style='display:flex;flex-direction:column;gap:14px;padding:18px;min-height:500px;box-sizing:border-box'><h1 style='margin:0'>Agent-Native Templates</h1><p class='wf-muted' style='margin:0'>Adoption and engagement across the last 12 weeks.</p><div style='display:grid;grid-template-columns:repeat(3,1fr);gap:12px'><div class='wf-card'><small class='wf-muted'>Weekly active users</small><br/><strong>24,318</strong><br/><span class='wf-pill accent'>+12.4%</span></div><div class='wf-card'><small class='wf-muted'>New signups</small><br/><strong>1,842</strong><br/><span class='wf-pill accent'>+8.7%</span></div><div class='wf-card'><small class='wf-muted'>Revenue MRR</small><br/><strong>$48,210</strong><br/><span class='wf-pill accent'>+21.3%</span></div></div><div style='display:grid;grid-template-columns:1fr 1fr;gap:12px;flex:1'><div class='wf-card' style='display:flex;flex-direction:column;gap:10px'><strong>Weekly active users</strong><div style='flex:1;display:flex;align-items:end;gap:8px'><div style='height:38%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:44%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:58%;flex:1;background:var(--wf-accent-soft)'></div><div style='height:74%;flex:1;background:var(--wf-accent-soft)'></div></div></div><div class='wf-card' style='display:flex;flex-direction:column;gap:10px'><strong>Revenue over time</strong><div style='flex:1;position:relative;background:linear-gradient(115deg,var(--wf-accent-soft) 0%,transparent 60%);border-radius:6px'><div style='position:absolute;inset:0;display:flex;align-items:end;gap:10px;padding:0 6px 6px'><span style='width:7px;height:7px;border-radius:50%;background:var(--wf-accent);margin-bottom:14%'></span><span style='width:7px;height:7px;border-radius:50%;background:var(--wf-accent);margin-bottom:30%'></span><span style='width:7px;height:7px;border-radius:50%;background:var(--wf-accent);margin-bottom:48%'></span><span style='width:7px;height:7px;border-radius:50%;background:var(--wf-accent);margin-bottom:72%'></span></div></div></div></div><div class='wf-card'><strong>Signups by source</strong><div style='display:flex;flex-direction:column;gap:6px;margin-top:10px'><div style='display:flex;align-items:center;gap:8px'><span class='wf-muted' style='width:60px;font-size:11px'>Organic</span><div class='wf-box' style='height:12px;width:70%;padding:0'></div></div><div style='display:flex;align-items:center;gap:8px'><span class='wf-muted' style='width:60px;font-size:11px'>Referral</span><div class='wf-box' style='height:12px;width:45%;padding:0'></div></div><div style='display:flex;align-items:center;gap:8px'><span class='wf-muted' style='width:60px;font-size:11px'>Paid ads</span><div class='wf-box' style='height:12px;width:28%;padding:0'></div></div></div></div></div>"
     }
   />
 </WireframeBlock>
 
-It's an open-source replacement for Amplitude, Mixpanel, and Looker — for teams that want to own the code, the queries, and the data.
+It's an open-source analytics stack for teams that want to own the code, the queries, and the data.
 
 <Diagram id="doc-block-9n9ub7" title="Question to chart" summary="The agent consults the data dictionary, writes SQL, validates it against the warehouse, then renders a chart or saves a panel.">
 
@@ -125,11 +125,6 @@ Create a new Analytics app from the CLI:
 
 ```bash
 npx @agent-native/core@latest create my-analytics --standalone --template analytics
-```
-
-Local dev:
-
-```bash
 cd my-analytics
 pnpm install
 pnpm dev
@@ -371,3 +366,11 @@ To add a new data source, drop a script in `actions/` that calls the provider an
 To add a new chart type, extend the `ChartType` union in `app/pages/adhoc/sql-dashboard/types.ts`, handle it in `SqlChartCard.tsx`, and the agent can use it in any panel.
 
 For the broader pattern on extending templates, see the [Skills guide](/docs/skills-guide) and [Actions](/docs/actions).
+
+## What's next
+
+- [**Templates**](/docs/cloneable-saas) — the clone-and-own model, and every other domain template to start from
+- [**Getting Started**](/docs/getting-started) — the framework fundamentals: actions, application state, and live sync
+- [**Actions**](/docs/actions) — the action system dashboards, analyses, and the dictionary are built on
+- [**Sharing**](/docs/sharing) — the share-grant model dashboards and analyses build on
+- [**Automations**](/docs/automations) — schedule recurring dashboard refreshes or alerts

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

@@ -88,6 +88,18 @@ When you open the app, the selected library, prompt, references, and generated c
 - **Other apps need an asset picker or generator** — Slides, Design, Content, a blog editor, or a site builder can embed the picker or call Assets over A2A.
 - **You want brand media available from your coding agent** — Codex, Claude Code, Claude, or ChatGPT can generate and pick assets without leaving the chat.
 
+## What you can do with it
+
+- **Create asset libraries.** Group reference images, videos, canonical logos, style notes, palettes, folders, and generated output by brand, campaign, product, or category.
+- **Generate through chat.** The home composer and library Generate controls send the prompt to the agent with `sendToAgentChat()`, so users can inspect variants, give feedback, and iterate.
+- **Generate images and videos.** Builder-managed image generation is available when enabled, and Gemini powers video generation plus the manual image fallback.
+- **Upload and describe references.** Add images or videos from the library UI or prompt composer attachment button, then search by title, description, alt text, prompt, model, media type, status, role, folder, or collection.
+- **Keep a generation audit log.** Every run records prompts, model, aspect ratio, references, source asset, lineage, generated assets, status, errors, and timestamps for later design review.
+- **Preserve logo accuracy.** The agent can generate a placeholder area and the server composites the uploaded canonical logo onto the final image instead of relying on the image model to redraw it.
+- **Embed as a picker.** Other apps can iframe `/picker` and listen for the `chooseAsset` event from `@agent-native/embedding`, turning Assets into an asset picker/generator for blog editors, site builders, slide decks, and custom apps. The picker also emits the legacy `chooseImage` alias for existing image-only hosts.
+- **Install as an app-backed skill.** The `agent-native.app-skill.json` manifest exports an Assets skill plus MCP connector metadata so marketplaces can install the app, its instructions, and its picker together.
+- **Serve other agents.** Slides, Design, Content, Mail, and Dispatch can call Assets through A2A to list libraries, generate batches, create videos, refine an asset, fetch exports, and render inline previews where embedding is allowed.
+
 ## Getting started
 
 Live demo: [assets.agent-native.com](https://assets.agent-native.com).
@@ -249,18 +261,6 @@ For deeper prompting guidance on the underlying models, see OpenAI's
 - "Turn this uploaded diagram into a cleaner product explainer image."
 - "Create a video storyboard and save the best frame set to this library."
 
-## What you can do with it
-
-- **Create asset libraries.** Group reference images, videos, canonical logos, style notes, palettes, folders, and generated output by brand, campaign, product, or category.
-- **Generate through chat.** The home composer and library Generate controls send the prompt to the agent with `sendToAgentChat()`, so users can inspect variants, give feedback, and iterate.
-- **Generate images and videos.** Builder-managed image generation is available when enabled, and Gemini powers video generation plus the manual image fallback.
-- **Upload and describe references.** Add images or videos from the library UI or prompt composer attachment button, then search by title, description, alt text, prompt, model, media type, status, role, folder, or collection.
-- **Keep a generation audit log.** Every run records prompts, model, aspect ratio, references, source asset, lineage, generated assets, status, errors, and timestamps for later design review.
-- **Preserve logo accuracy.** The agent can generate a placeholder area and the server composites the uploaded canonical logo onto the final image instead of relying on the image model to redraw it.
-- **Embed as a picker.** Other apps can iframe `/picker` and listen for the `chooseAsset` event from `@agent-native/embedding`, turning Assets into an asset picker/generator for blog editors, site builders, slide decks, and custom apps. The picker also emits the legacy `chooseImage` alias for existing image-only hosts.
-- **Install as an app-backed skill.** The `agent-native.app-skill.json` manifest exports an Assets skill plus MCP connector metadata so marketplaces can install the app, its instructions, and its picker together.
-- **Serve other agents.** Slides, Design, Content, Mail, and Dispatch can call Assets through A2A to list libraries, generate batches, create videos, refine an asset, fetch exports, and render inline previews where embedding is allowed.
-
 ## Using it from your coding agent
 
 Generate and pick brand media without leaving Codex, Claude Code, Claude, or ChatGPT.
@@ -303,10 +303,13 @@ Generate and pick brand media without leaving Codex, Claude Code, Claude, or Cha
 
 The rest of this doc is for anyone forking the Assets template or extending it.
 
-### Scaffolding
+### Quick start
 
 ```bash
 npx @agent-native/core@latest create my-assets --standalone --template assets
+cd my-assets
+pnpm install
+pnpm dev
 ```
 
 ### Data model

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

@@ -203,7 +203,7 @@ Postgres, Neon, D1, Turso, and similar hosts. Application state mirrors the
 current route, filters, and selected IDs so the agent always knows the current
 navigation and selection.
 
-Brain's schema lives in `templates/brain/server/db/schema.ts`. Eight tables:
+Brain's schema lives in `templates/brain/server/db/schema.ts`. Nine tables:
 
 | Table                    | What it holds                                                                                                                                  |
 | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -551,3 +551,5 @@ Ask the agent to make changes for you — it can edit its own source. See
 - [**Dispatch template**](/docs/template-dispatch) — the scaffolded coordination app
 - [**Workspace**](/docs/workspace) — shared resources across apps
 - [**A2A Protocol**](/docs/a2a-protocol) — cross-app delegation
+- [**Templates**](/docs/cloneable-saas) — the clone-and-own model, and every other domain template to start from
+- [**Getting Started**](/docs/getting-started) — the framework fundamentals: actions, application state, and live sync

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

@@ -1,11 +1,11 @@
 ---
 title: "Calendar"
-description: "An agent-powered calendar with Google Calendar sync and Calendly-style booking links. Schedule, find slots, and manage availability through plain English."
+description: "An agent-powered calendar with Google Calendar sync and shareable booking pages. Schedule, find slots, and manage availability through plain English."
 ---
 
 # Calendar
 
-An agent-powered calendar app. Connect your Google Calendar and the agent can read your schedule, find free slots, create events, and manage Calendly-style booking links — all in plain English. It replaces the Google Calendar + Calendly combo with one app you own.
+An agent-powered calendar app. Connect your Google Calendar and the agent can read your schedule, find free slots, create events, and manage shareable booking links — all in plain English. It brings your calendar and public booking pages into one app you own.
 
 <WireframeBlock id="doc-block-6wsrao">
   <Screen
@@ -167,7 +167,7 @@ Under the hood the agent calls actions like `list-events`, `check-availability`,
 Defined in `templates/calendar/server/db/schema.ts`. Only non-event data is stored locally:
 
 - `bookings` — confirmed appointments from public booking pages. Stores name, email, start, end, slug, optional notes, custom field responses, meeting link, a `cancelToken` for the public manage URL, and a `confirmed` or `cancelled` status.
-- `booking_links` — the Calendly-style link definitions. Slug, title, description, primary `duration`, optional `durations` list, `customFields`, `conferencing`, `color`, and an `isActive` flag. Uses the framework's `ownableColumns` so the sharing system applies.
+- `booking_links` — the booking-page link definitions. Slug, title, description, primary `duration`, optional `durations` list, `customFields`, `conferencing`, `color`, and an `isActive` flag. Uses the framework's `ownableColumns` so the sharing system applies.
 - `booking_slug_redirects` — remembers old slugs when a link is renamed so existing public URLs keep working.
 - `booking_link_shares` — share grants for booking links.
 
@@ -181,7 +181,7 @@ Defined in `templates/calendar/server/db/schema.ts`. Only non-event data is stor
     {
       id: "booking_links",
       name: "booking_links",
-      note: "Calendly-style link definitions (ownable)",
+      note: "Booking-page link definitions (ownable)",
       fields: [
         {
           name: "id",
@@ -375,3 +375,11 @@ Every part of the app is editable source. Start here:
 - `templates/calendar/shared/api.ts` — the shared TypeScript types (`AvailabilityConfig`, `BookingLink`, `ExternalCalendar`, etc.) used by both the server and the client.
 
 If you add a feature, remember to update all four areas: UI, action, skill or AGENTS.md entry, and any application state the agent needs to see. That is what keeps the agent and the UI in parity.
+
+## What's next
+
+- [**Templates**](/docs/cloneable-saas) — the clone-and-own model, and every other domain template to start from
+- [**Getting Started**](/docs/getting-started) — the framework fundamentals: actions, application state, and live sync
+- [**Mail**](/docs/template-mail) — a sibling domain template covering inbox and automations
+- [**Automations**](/docs/automations) — trigger jobs off calendar and booking events
+- [**Sharing**](/docs/sharing) — the share-grant model booking links build on

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

@@ -111,7 +111,7 @@ That's the point. Chat is a thin, useful default shell for your own agent, not a
 ## Scaffolding {#scaffolding}
 
 ```bash
-npx @agent-native/core@latest create my-chat-app --template chat
+npx @agent-native/core@latest create my-chat-app --standalone --template chat
 cd my-chat-app
 pnpm install
 pnpm dev
@@ -162,8 +162,7 @@ Use it for scheduled jobs, queues, CLI loops, or external-agent workflows where
 
 The chat page is intentionally thin:
 
-```tsx
-// app/routes/_index.tsx
+```tsx filename="app/routes/_index.tsx"
 import { AgentChatSurface } from "@agent-native/core/client";
 
 export default function ChatRoute() {
@@ -196,7 +195,8 @@ The agent should add a Drizzle schema, actions, route, navigation, and instructi
 
 ## What's next
 
-- [**Getting Started**](/docs) — build the chat-first path from action to inline result to app page
+- [**Getting Started**](/docs/getting-started) — build the chat-first path from action to inline result to app page
+- [**Templates**](/docs/cloneable-saas) — the clone-and-own model, and every domain template to start from instead
 - [**Agent Surfaces**](/docs/agent-surfaces) — chat, inline UI, app pages, embedded, automation, and external-agent patterns
 - [**Actions**](/docs/actions) — the action system chat and UI both call
 - [**Native Chat UI**](/docs/native-chat-ui) — chat surface primitives and runtime options