@agent-native/core 0.157.4 → 0.157.5

package/docs/content/client-overview.mdx

@@ -92,7 +92,7 @@ The one architectural difference from a typical frontend: this layer has no back
 
 ## Where the Client Fits {#role}
 
-Browser requests, the agent loop, and external API clients all resolve to the same actions and the same SQL database — there is no separate "app backend" this layer talks to that the agent can't also reach. Building a feature here means building a UI on top of an operation the agent already has, or defining a new action and getting a UI for it at the same time. See [Actions](/docs/actions) for the operation side of that contract.
+Browser requests, the agent loop, and external API clients all resolve to the same actions and the same SQL database — there is no separate "app backend" this layer talks to that the agent can't also reach. Building a feature here means building a UI on top of an operation the agent already has, or defining a new action and getting a UI for it at the same time. See [Actions](/docs/actions-overview) for the operation side of that contract.
 
 This page covers the directories you build in and the pieces of the browser runtime nothing else documents (`root.tsx`, `public/`). The React hooks that connect your components to actions and to the agent live on their own focused pages:
 
@@ -201,6 +201,6 @@ import { cn } from "@agent-native/toolkit/utils";
 - [**Sync Internals**](/docs/client-sync-internals) — `useChangeVersion` for syncing a raw `useQuery`
 - [**Entry Points**](/docs/client-entry-points) — SSR bootstrap customization
 - [**Routing**](/docs/client-routing) — file-based pages, dynamic params, and navigation
-- [**Actions**](/docs/actions) — the `defineAction` surface behind every data hook
+- [**Actions**](/docs/actions-overview) — the `defineAction` surface behind every data hook
 - [**Custom Design Systems**](/docs/custom-design-system) — swapping in your own component library via `app/design-system.ts`
 - [**Authentication**](/docs/authentication) — the session checks `AppProviders` runs on private paths

package/docs/content/components.mdx

@@ -526,7 +526,7 @@ reasoning.
 
 - [**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
+- [**Actions**](/docs/actions-overview) — `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
 - [**Toolkit piece: Toolkit UI Primitives**](/docs/toolkit-ui) — the shared shadcn-style building blocks and app-adapter pattern behind these exports

package/docs/content/data-programs.mdx

@@ -14,7 +14,7 @@ search: "data program emit rows schema providerFetch dashboard panel program sou
 
 A **data program** is a named, stored, agent-authored JS script that fetches, joins, filters, or aggregates data — provider APIs via `providerFetch` / `providerFetchAll` / `providerSearchAll`, app data via `appAction`, or Resources-backed workspace files — and calls `emit(rows, schema)` exactly once with the result. The result is cached in SQL and any chart/table component can render it, refreshed on a policy you choose instead of on every page view.
 
-It ships automatically wherever [`run-code`](/docs/actions) is available — there is nothing to mount or configure per app. If your app already has run-code enabled, `save-data-program`, `preview-data-program`, `run-data-program`, `list-data-programs`, `get-data-program`, and `delete-data-program` are already registered actions.
+It ships automatically wherever [`run-code`](/docs/actions-overview) is available — there is nothing to mount or configure per app. If your app already has run-code enabled, `save-data-program`, `preview-data-program`, `run-data-program`, `list-data-programs`, `get-data-program`, and `delete-data-program` are already registered actions.
 
 <Diagram id="doc-block-dp-overview" title="From ad-hoc query to live panel" summary="A run-code script becomes a stored program once it calls emit(); any dashboard panel can bind to it and the cache/refresh policy takes over from there.">
 
@@ -330,6 +330,6 @@ Any app can implement the same adoption for its own dashboards/tables: call `run
 ## 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.
+- [Actions](/docs/actions-overview) — the `run-code` conventions and sandbox globals (`providerFetch`, `appAction`, etc.) data programs are built on.
 - [Sharing & Privacy](/docs/sharing) — the org-internal, never-public sharing model data programs use.
 - [Security](/docs/security) — the framework's credential-handling and access-scoping invariants.

package/docs/content/database.mdx

@@ -314,4 +314,4 @@ step instead of on the first request. The Chat template provides
 - [**Sharing**](/docs/sharing#building) — `ownableColumns()` and the visibility model for shared resources
 - [**Server**](/docs/server-routes#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`
+- [**Actions**](/docs/actions-access-control#access-control) — a complete, paste-ready action that reads and writes through `getDb`/`schema`

package/docs/content/deployment.mdx

@@ -557,7 +557,7 @@ Three things to keep in mind:
 
 - **Turning caching off does not make SSR personalized.** Cookies are still stripped before render and SSR loaders still see the anonymous branch. Per-user data must still be resolved client-side. This variable controls cache _duration_ only.
 - **It is deployment-wide, not per-route, by design.** A per-route or per-request cache override is how one visitor's payload ends up in another visitor's shared CDN entry, so the framework does not offer one — `guard:ssr-cache-shell` enforces it.
-- **For mutation-fresh data, prefer actions over disabling the cache.** App data belongs in [actions](/docs/actions), read from the client with `useActionQuery` / `useActionMutation` and kept live by `useDbSync()` polling; none of that goes through the SSR shell cache. Keep SSR loaders rendering the public shell, and reach for this variable only when you genuinely want loader data fresher.
+- **For mutation-fresh data, prefer actions over disabling the cache.** App data belongs in [actions](/docs/actions-overview), read from the client with `useActionQuery` / `useActionMutation` and kept live by `useDbSync()` polling; none of that goes through the SSR shell cache. Keep SSR loaders rendering the public shell, and reach for this variable only when you genuinely want loader data fresher.
 
 ## Environment Variables {#environment-variables}
 

package/docs/content/docs-components.mdx

@@ -147,7 +147,7 @@ Each step is a `###` heading followed by the body content. Steps work best for 3
 
 <Cards>
 
-### [Actions](/docs/actions)
+### :components: [Actions](/docs/actions-overview)
 
 Typed operations callable from the agent, UI, CLI, and HTTP. Define once, call from anywhere.
 
@@ -168,7 +168,7 @@ Plain-text instruction files that give the agent domain knowledge and task-speci
 ```mdx
 <Cards>
 
-### [Actions](/docs/actions)
+### :components: [Actions](/docs/actions-overview)
 
 Typed operations callable from the agent, UI, CLI, and HTTP. Define once, call from anywhere.
 
@@ -187,7 +187,18 @@ Plain-text instruction files that give the agent domain knowledge and task-speci
 </Cards>
 ```
 
-Each card is a `###` heading (optionally linked) followed by the description. Cards without a link render as plain info boxes with no hover state or arrow.
+Each card is a `###` heading (optionally linked) followed by the description. Cards without a link render as plain info boxes with no hover state or arrow. Prefix the heading with `:icon-name:` to add an icon in its own column to the left of the title and body — useful for a set of cards that represent distinct categories rather than a features list. Icons come from a curated set, not an arbitrary Tabler icon name:
+
+| Icon key     | Renders                                 |
+| ------------ | --------------------------------------- |
+| `robot`      | agent / autonomous behavior             |
+| `components` | UI, hooks, composable pieces            |
+| `server`     | backend, transport, infrastructure      |
+| `plug`       | integrations, connected tools           |
+| `network`    | cross-app or distributed communication  |
+| `terminal`   | CLI, scripts, terminal-driven workflows |
+
+The grid defaults to 3 columns. Set `columns` (1-4) on the opening tag to override it, e.g. `<Cards columns={2}>`. Below 640px the grid always collapses to a single column regardless of `columns`.
 
 ---
 

package/docs/content/drop-in-agent.mdx

@@ -294,7 +294,7 @@ const { mutate, isPending } = useActionMutation("reply-to-email");
 </Button>;
 ```
 
-Type-safe arguments come from the zod schema in your `defineAction()`. See [Actions](/docs/actions) for the full action system.
+Type-safe arguments come from the zod schema in your `defineAction()`. See [Actions](/docs/actions-overview) for the full action system.
 
 <Callout id="doc-block-1757zi5" tone="decision">
 
@@ -352,7 +352,7 @@ The user sees a chat button in the header, can open it, and can talk to the agen
 
 ## What's next
 
-- [**Actions**](/docs/actions) — `defineAction()` and `useActionMutation()`
+- [**Actions**](/docs/actions-overview) — `defineAction()` and `useActionMutation()`
 - [**Context Awareness**](/docs/context-awareness) — selection, navigation, view-screen
 - [**Agent Resources**](/docs/agent-resources) — what the Resources tab contains (skills, memory, MCP servers, scheduled jobs)
 - [**Voice Input**](/docs/voice-input) — the microphone in the chat composer

package/docs/content/durable-resume.mdx

@@ -107,6 +107,6 @@ Together the two layers mean an interrupted run that already had a real side eff
 ## What's next
 
 - [**Real-Time Sync**](/docs/real-time-collaboration) — how the durable run ledger streams to the client and replays on reconnect.
-- [**Actions**](/docs/actions) — `readOnly` marks reads as safe to re-run; everything else is treated as side-effecting.
+- [**Actions**](/docs/actions-overview) — `readOnly` marks reads as safe to re-run; everything else is treated as side-effecting.
 - [**In-Loop Processors**](/docs/processors) — another loop-internal hardening seam.
 - [**Durable Background Runs**](/docs/durable-background-runs) — moving a long turn onto a separate background function.

package/docs/content/evals.mdx

@@ -265,5 +265,5 @@ A regression that drops any scorer below threshold fails the step and blocks the
 ## What's next
 
 - [**Observability**](/docs/observability) — post-hoc scoring of real production runs (the complementary layer)
-- [**Actions**](/docs/actions) — the tools/actions that show up in `toolCalls`
+- [**Actions**](/docs/actions-overview) — the tools/actions that show up in `toolCalls`
 - [**Agent Teams**](/docs/agent-teams) — sub-agents an eval might exercise

package/docs/content/extensions.mdx

@@ -716,7 +716,7 @@ You also won't see this in normal use, but the agent has a third related concept
 ## What's next
 
 - [**Templates**](/docs/cloneable-saas) — the host apps extensions extend
-- [**Actions**](/docs/actions) — the operations an extension calls via `appAction`
+- [**Actions**](/docs/actions-overview) — the operations an extension calls via `appAction`
 - [**Data Programs**](/docs/data-programs) — the no-UI sibling primitive for cached, refreshable data sources
 - [**Sharing & Privacy**](/docs/sharing) — how extension visibility, org sharing, and per-user grants work
 - [**Onboarding & API Keys**](/docs/onboarding) — how secrets surface in the settings UI

package/docs/content/external-agents-catalog.mdx

@@ -403,7 +403,7 @@ export default defineAction({
 });
 ```
 
-`GET` + `readOnly` keeps the action side-effect-free and out of the screen-refresh change event. `publicAgent` is the **explicit opt-in** — a public web route never implies public MCP/A2A exposure; see [Actions](/docs/actions). Design/content ingest actions MUST read **live** state (the Yjs collaborative document, not the stale DB snapshot column) so the external agent sees what the user actually has on screen. Content's `pull-document` flushes any open live collab session to SQL first; design's `get-design-snapshot` returns the live Yjs file contents plus the user's resolved tweak values.
+`GET` + `readOnly` keeps the action side-effect-free and out of the screen-refresh change event. `publicAgent` is the **explicit opt-in** — a public web route never implies public MCP/A2A exposure; see [Actions](/docs/actions-overview). Design/content ingest actions MUST read **live** state (the Yjs collaborative document, not the stale DB snapshot column) so the external agent sees what the user actually has on screen. Content's `pull-document` flushes any open live collab session to SQL first; design's `get-design-snapshot` returns the live Yjs file contents plus the user's resolved tweak values.
 
 ## Advanced: local development & manual setup {#advanced}
 
@@ -532,5 +532,5 @@ The fallback hosted `connect` flow never copies the deployment's shared secret.
 - [MCP Server](/docs/mcp-protocol) — the auto-mounted MCP server and `ask-agent` meta-tool
 - [MCP Clients](/docs/mcp-clients) — the symmetric direction: your app consuming local/remote MCP servers
 - [A2A Protocol](/docs/a2a-protocol) — the `ask-agent` meta-tool and JSON-RPC peer calls
-- [Actions](/docs/actions) — defining actions, `publicAgent`, GET / `readOnly`
+- [Actions](/docs/actions-overview) — defining actions, `publicAgent`, GET / `readOnly`
 - [Context Awareness](/docs/context-awareness) — the `navigate` / `application_state` contract the open route bridges to

package/docs/content/external-agents.mdx

@@ -344,5 +344,5 @@ See the full tool catalog, MCP Apps compatibility matrix, generic cross-app verb
 - [MCP Server](/docs/mcp-protocol) — the auto-mounted MCP server and `ask-agent` meta-tool.
 - [MCP Clients](/docs/mcp-clients) — the symmetric direction: your app consuming local/remote MCP servers.
 - [A2A Protocol](/docs/a2a-protocol) — the `ask-agent` meta-tool and JSON-RPC peer calls.
-- [Actions](/docs/actions) — defining actions, `publicAgent`, GET / `readOnly`.
+- [Actions](/docs/actions-overview) — defining actions, `publicAgent`, GET / `readOnly`.
 - [Context Awareness](/docs/context-awareness) — the `navigate` / `application_state` contract the open route bridges to.

package/docs/content/generative-ui.mdx

@@ -275,4 +275,4 @@ template actions that resolve credentials server-side.
 - [Native Chat UI](/docs/native-chat-ui) — typed first-party React widgets for
   action results.
 - [MCP Apps](/docs/mcp-apps) — inline app routes in external MCP hosts.
-- [Actions](/docs/actions) — the app/API surface generated UI should call.
+- [Actions](/docs/actions-overview) — the app/API surface generated UI should call.

package/docs/content/getting-started.mdx

@@ -5,7 +5,7 @@ description: "Create a Chat app and configure an agent, then extend it with an a
 
 # Getting Started
 
-Agent-Native apps give the agent and the UI the same [actions](/docs/actions),
+Agent-Native apps give the agent and the UI the same [actions](/docs/actions-overview),
 SQL data, and application state. This path starts with Chat, which already
 creates the framework tables it needs and stores chat history in local SQLite by
 default. Add your own tables only when your app needs to persist domain data.

package/docs/content/http-api.mdx

@@ -14,7 +14,7 @@ search: "HTTP API bearer token service token connect CLI curl action endpoint se
 | Let an AI host discover and call every action        | [MCP Server](/docs/mcp-protocol)         |
 | Connect Claude, ChatGPT, Codex, Cursor to your app   | [External Agents](/docs/external-agents) |
 | Have another agent-native app delegate work to yours | [A2A Protocol](/docs/a2a-protocol)       |
-| Define the operation in the first place              | [Actions](/docs/actions)                 |
+| Define the operation in the first place              | [Actions](/docs/actions-overview)        |
 
 Every `defineAction` in `actions/` is already an HTTP endpoint. The frontend calls it through `useActionQuery` / `useActionMutation` with a session cookie, but the same route accepts an `Authorization: Bearer` token, so anything that can make an HTTPS request can call it. There is no separate "public API" to build and no REST wrapper to maintain — the action you wrote for the agent and the UI is the API.
 
@@ -156,7 +156,7 @@ curl -sS \
   -H "Authorization: Bearer $AGENT_NATIVE_TOKEN"
 ```
 
-`http: { path: "..." }` changes the mounted URL for direct HTTP callers only, and `http: false` removes the endpoint entirely. See [Actions — HTTP config](/docs/actions#http) for the full option set.
+`http: { path: "..." }` changes the mounted URL for direct HTTP callers only, and `http: false` removes the endpoint entirely. See [Actions — HTTP config](/docs/actions-defining#http) for the full option set.
 
 ### Errors {#errors}
 
@@ -238,7 +238,7 @@ Because `list-org-service-tokens` reports `lastUsedAt`, it doubles as a cleanup
 - Give each caller its own named service token (`--service-token support-desk`, `--service-token ci`) so you can revoke one without breaking the others, and so `lastUsedAt` tells you who is actually calling.
 - Prefer the shortest `--ttl-days` the caller can live with.
 - A service token acts as an org **`member`, and only ever `member`.** The synthetic `svc-*@service.<orgId>` identity is never inserted into `org_members`; it resolves an implicit member role for the org it was minted against, and nothing higher. So it can read and write that org's data like any member, but it cannot mint further tokens, revoke existing ones, or manage org members and settings — every one of those is admin-gated. It can still do everything a normal member can do with the org's data, so scope it deliberately.
-- Actions you never want reachable this way should set `http: false` (agent and CLI only) or `toolCallable: false`. See [Actions — Exposure flags](/docs/actions#exposure-flags).
+- Actions you never want reachable this way should set `http: false` (agent and CLI only) or `toolCallable: false`. See [Actions — Exposure flags](/docs/actions-access-control#exposure-flags).
 
 </Callout>
 
@@ -259,7 +259,7 @@ A `401` means the token was not accepted at all. A `403` means the token _was_ a
 
 ## What's next {#related-docs}
 
-- [**Actions**](/docs/actions) — define the operation once; HTTP, MCP, A2A, CLI, and the UI all call the same one
+- [**Actions**](/docs/actions-overview) — define the operation once; HTTP, MCP, A2A, CLI, and the UI all call the same one
 - [**Authentication**](/docs/authentication) — session auth, orgs, and static `ACCESS_TOKEN` bearers
 - [**MCP Server**](/docs/mcp-protocol) — the tool-catalog surface these tokens are audience-bound to
 - [**A2A Protocol**](/docs/a2a-protocol) — agent-to-agent delegation between agent-native apps

package/docs/content/human-approval.mdx

@@ -151,6 +151,6 @@ The canonical (and intentionally rare) use of this gate in the framework is the
 
 ## What's next
 
-- [**Actions**](/docs/actions#needs-approval) — the full `defineAction` surface, including `outputSchema` for validating return values.
+- [**Actions**](/docs/actions-access-control#needs-approval) — the full `defineAction` surface, including `outputSchema` for validating return values.
 - [**Security**](/docs/security) — when to reach for an approval gate vs. hiding an action from the model.
 - [**Mail template**](/docs/template-mail) — `send-email` is the reference example.

package/docs/content/key-concepts.mdx

@@ -364,7 +364,7 @@ graph LR
 - **CLI:** `pnpm action fetch-data --source=signups` for scripting and agent dev loops.
 - **MCP tool / A2A tool:** when MCP server or A2A is enabled, the same action shows up there too.
 
-Every consumer calls the same underlying function, so there is only one implementation to write and maintain. See [Actions](/docs/actions) for the full reference.
+Every consumer calls the same underlying function, so there is only one implementation to write and maintain. See [Actions](/docs/actions-overview) for the full reference.
 
 ## Live sync {#polling-sync}
 

package/docs/content/mcp-apps.mdx

@@ -248,5 +248,5 @@ Test MCP Apps with the lightweight fixtures around `embedApp()` and `McpAppRende
 - [External Agents](/docs/external-agents) — connecting Claude, ChatGPT, Codex, and Cursor to hosted apps; deep links.
 - [External Agents Catalog](/docs/external-agents-catalog) — catalog tiers, the MCP Apps compatibility matrix, and the `link` builder for template authors.
 - [MCP Server](/docs/mcp-protocol) — the auto-mounted MCP server, auth, tools, and `ask-agent`.
-- [Actions](/docs/actions) — `defineAction`, the `link` builder, `publicAgent`.
+- [Actions](/docs/actions-overview) — `defineAction`, the `link` builder, `publicAgent`.
 - [Generative UI](/docs/generative-ui) — generated inline UI inside the app's own chat.

package/docs/content/mcp-clients.mdx

@@ -598,4 +598,4 @@ MCP tools run on your machine with whatever permissions the spawned process has.
 - [**MCP Server**](/docs/mcp-protocol) — the opposite direction: making your app an MCP server other hosts consume
 - [**External Agents**](/docs/external-agents) — connecting Claude, Cursor, and other hosts to your app
 - [**Multi-App Workspace**](/docs/multi-app-workspace) — the shared-resource model behind Dispatch workspace MCP resources
-- [**Actions**](/docs/actions) — how your own actions show up alongside MCP tools in the agent's registry
+- [**Actions**](/docs/actions-overview) — how your own actions show up alongside MCP tools in the agent's registry

package/docs/content/mcp-protocol.mdx

@@ -433,4 +433,4 @@ Claude Code calls: ask-agent(message: "Prepare a full breakdown of Q3 signups by
 - [**MCP Apps**](/docs/mcp-apps) — inline UI resources for hosts that render them
 - [**MCP Clients**](/docs/mcp-clients) — the other direction: your app consuming external MCP servers
 - [**A2A Protocol**](/docs/a2a-protocol) — the sibling protocol for agent-to-agent calls
-- [**Actions**](/docs/actions) — how an action becomes an MCP tool
+- [**Actions**](/docs/actions-overview) — how an action becomes an MCP tool

package/docs/content/native-chat-ui.mdx

@@ -414,7 +414,7 @@ if it matures, it should adapt into this same explicit runtime/widget contract.
 
 ## What's next {#whats-next}
 
-- [Actions](/docs/actions) — define the operations that return native widget data.
+- [Actions](/docs/actions-overview) — define the operations that return native widget data.
 - [Agent Surfaces](/docs/agent-surfaces) — decide whether you need headless, chat, sidecar, or full app.
 - [Drop-in Agent](/docs/drop-in-agent) — the tutorial for mounting the standard chat runtime.
 - [Component API](/docs/components) — the per-export API map for chat layers, runtimes, and tool renderers.

package/docs/content/observability.mdx

@@ -436,6 +436,6 @@ Identity fields explicitly set via `setUser({ id, email, username })` are preser
 ## What's next
 
 - [**Tracking**](/docs/tracking) — product analytics (PostHog, Mixpanel, Amplitude) for your app's own events
-- [**Actions**](/docs/actions) — the operations that appear as tool calls in traces
+- [**Actions**](/docs/actions-overview) — the operations that appear as tool calls in traces
 - [**Security**](/docs/security) — data scoping and credential handling
 - [**Toolkit piece: Observability Kit**](/docs/toolkit-observability) — the dashboard and feedback UI built on this data model

package/docs/content/organizations-teams-permissions.mdx

@@ -264,7 +264,7 @@ const { role } = useAppRole("coach");
 `useAppRoles`, `useAppRole`, and `useSetAppMemberRole` are progressive
 disclosure only. Every guarded operation re-resolves the role on the server, so
 a client that shows the wrong affordance still cannot perform the operation.
-See [Actions → Authorization](/docs/actions#authorize) for how `authorize`
+See [Actions → Authorization](/docs/actions-access-control#authorize) for how `authorize`
 differs from `needsApproval` and from row-level access guards.
 
 ## Resource permissions (sharing RBAC)

package/docs/content/processors.mdx

@@ -53,7 +53,7 @@ A `Processor` is a loop-internal **observer/guardrail** for the agent run. It wa
 
 <Callout id="doc-block-proc1cfg" tone="warning">
 
-A processor is **configuration**, not a tool, not an action, and not an authoring DSL. Processors only observe, mutate their own stream-scoped state, and `abort()`. They never define app behavior, replace actions, or appear to the model. App operations belong in [actions](/docs/actions).
+A processor is **configuration**, not a tool, not an action, and not an authoring DSL. Processors only observe, mutate their own stream-scoped state, and `abort()`. They never define app behavior, replace actions, or appear to the model. App operations belong in [actions](/docs/actions-overview).
 
 </Callout>
 

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

@@ -165,7 +165,7 @@ persistent objects.
 
 - [**Getting Started**](/docs/getting-started) — the chat-first tutorial from action to inline result to durable page
 - [**Agent Surfaces — Automation-first app**](/docs/agent-surfaces#headless) — the full decision guide and APIs
-- [**Actions**](/docs/actions) — the operations your automation calls
+- [**Actions**](/docs/actions-overview) — the operations your automation calls
 - [**Messaging the agent**](/docs/messaging) — how users talk to the agent across web, Slack, Telegram, and email
 - [**Recurring Jobs**](/docs/recurring-jobs) — scheduled prompts the agent runs on its own
 - [**Dispatch**](/docs/template-dispatch) — the workspace control plane for shared secrets, scheduled jobs, and delegated work

package/docs/content/recurring-jobs.mdx

@@ -277,7 +277,7 @@ Recurring jobs are "how do I make the agent act on its own?" The scheduling pack
 
 - [**Automations**](/docs/automations) — the primary Scheduled/Event product model and management workflow
 - [**Agent Resources**](/docs/agent-resources) — where jobs live alongside skills, memory, and custom agents
-- [**Actions**](/docs/actions) — the tools a job calls
+- [**Actions**](/docs/actions-overview) — the tools a job calls
 - [**MCP Clients**](/docs/mcp-clients) — connect remote or local MCP tools and OAuth grants
 - [**Agent Teams**](/docs/agent-teams) — jobs often spawn sub-agents to do parallel work
 - [**Toolkit piece: Toolkit Capability Modules**](/docs/toolkit-capability-packages) — how this differs from the installable Scheduling package

package/docs/content/server-database.mdx

@@ -441,6 +441,6 @@ const { rows } = await getDbExec().execute({
 - [**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
 - [**Plugins**](/docs/server-plugins): the startup plugin lifecycle where migrations run
-- [**Actions**](/docs/actions): the surface where actions call `getDb()` to read and write data
+- [**Actions**](/docs/actions-overview): the surface where actions call `getDb()` to read and write data
 - [**Deployment**](/docs/deployment#persistent-database): connecting a persistent database per deploy target
 - [**Real-Time Sync**](/docs/key-concepts#polling-sync): `useDbSync()` and the full client-side sync model

package/docs/content/server-overview.mdx

@@ -5,7 +5,7 @@ description: "The Nitro server layer in an agent-native app: what it's for, when
 
 # Server
 
-The `server/` directory is the infrastructure layer of an agent-native app. It handles startup tasks, authentication, and the HTTP surfaces that actions don't cover. Most product behavior belongs in [Actions](/docs/actions). The server is what makes those actions available.
+The `server/` directory is the infrastructure layer of an agent-native app. It handles startup tasks, authentication, and the HTTP surfaces that actions don't cover. Most product behavior belongs in [Actions](/docs/actions-overview). The server is what makes those actions available.
 
 <Diagram id="doc-block-server-overview-1" title="How requests flow through the server" summary="Callers reach the Nitro server, which handles most requests through Actions. Middleware and Routes cover cases Actions can't. Both paths can query the database.">
 
@@ -223,11 +223,11 @@ Agent Native architecture is different. Whenever you think of a new feature for
 - MCP and A2A-callable tools.
 - CLI commands for development.
 
-Use custom `/api/*` routes only when you need a route-shaped protocol or binary/streaming behavior. For more details, visit [Actions](/docs/actions).
+Use custom `/api/*` routes only when you need a route-shaped protocol or binary/streaming behavior. For more details, visit [Actions](/docs/actions-overview).
 
 ## What's next {#whats-next}
 
-- [**Actions**](/docs/actions): the default operation surface. Reach for a custom route only when it doesn't fit.
+- [**Actions**](/docs/actions-overview): the default operation surface. Reach for a custom route only when it doesn't fit.
 - [**Database**](/docs/server-database): the `getDb()`/schema pattern custom routes and actions both import
 - [**Middleware**](/docs/server-middleware): auth guards and the `server/middleware/` directory
 - [**Plugins**](/docs/server-plugins): startup plugins for auth, the agent, and optional app-owned migrations

package/docs/content/server-routes.mdx

@@ -51,7 +51,7 @@ Actions cover the vast majority of app operations. Reach for a file route in `se
 
 - Operations the UI and agent both need
 - Reading or writing app data
-- HTTP-shaped endpoints (use the `http` option in [Actions](/docs/actions))
+- HTTP-shaped endpoints (use the `http` option in [Actions](/docs/actions-overview))
 - Anything that should be an agent tool, MCP tool, or CLI command
 - Standard JSON request/response APIs
 
@@ -193,7 +193,7 @@ Every SSR response is an impersonal, public shell cached at the CDN. Never read
 
 ## What's next {#whats-next}
 
-- [**Actions**](/docs/actions): the preferred surface for app operations; reach for a route only when it doesn't fit
+- [**Actions**](/docs/actions-overview): the preferred surface for app operations; reach for a route only when it doesn't fit
 - [**Plugins**](/docs/server-plugins): startup plugins and their initialization behavior
 - [**Middleware**](/docs/server-middleware): auth guards that protect all routes including `/api/*`
 - [**Security**](/docs/security#access-guards): `accessFilter`/`assertAccess` and the full data-scoping model

package/docs/content/template-analytics-developers.mdx

@@ -282,6 +282,6 @@ For new capabilities — a new chart type, a new provider, a new admin view —
 - [**Dashboards, Analyses, and the Data Dictionary**](/docs/template-analytics-dashboards) — the user-facing surface this data model backs
 - [**Monitoring, Errors, and Session Replay**](/docs/template-analytics-monitoring-and-sessions) — the user-facing surface for monitors, errors, and replay
 - [**Connecting and Extending Data Sources**](/docs/template-analytics-connectors) — the full connector catalog
-- [**Actions**](/docs/actions) — the action system this template is built on
+- [**Actions**](/docs/actions-overview) — the action system this template is built on
 - [**Data Programs**](/docs/data-programs) — the full data-program authoring contract
 - [**Sharing**](/docs/sharing) — the share-grant model dashboards, analyses, and error issues build on

package/docs/content/template-assets-developers.mdx

@@ -452,5 +452,5 @@ on the integrations page.
 - [**Using Assets from other apps and agents**](/docs/template-assets-integrations) — embedding, A2A, Creative Context, and the packaged skill bundle
 - [**Sharing & Privacy**](/docs/sharing#building) — `ownableColumns()` and the visibility model this template relies on
 - [**Database**](/docs/database) — migrations, dialects, and `getDb`/`schema`
-- [**Actions**](/docs/actions#access-control) — the action system powering every entry above
+- [**Actions**](/docs/actions-access-control#access-control) — the action system powering every entry above
 - [**Assets**](/docs/template-assets) — back to the overview

package/docs/content/template-brain-developers.mdx

@@ -377,6 +377,6 @@ data surface. See [Key Concepts](/docs/key-concepts#agent-modifies-code).
 - [**Connecting & Reviewing Sources**](/docs/template-brain-sources) — provider setup, the Slack rollout, and source health
 - [**Asking, Citations & Knowledge**](/docs/template-brain-knowledge) — the Ask/Search/Knowledge/Review surfaces
 - [**Talking to the Agent & Cross-App Use**](/docs/template-brain-agent) — prompts, `federatedCoverage`, and A2A
-- [**Actions**](/docs/actions) — the action system Brain is built on
+- [**Actions**](/docs/actions-overview) — the action system Brain is built on
 - [**A2A Protocol**](/docs/a2a-protocol) — cross-app delegation
 - [**Extensions**](/docs/extensions) — the sandboxed widget system available from Brain's Settings page

package/docs/content/template-calendar-developers.mdx

@@ -362,5 +362,5 @@ If you add a feature, remember to update all four areas: UI, action, skill or AG
 - [**Events, Availability & Finding Time**](/docs/template-calendar-scheduling) — the user-facing behavior these actions power
 - [**Booking Links**](/docs/template-calendar-booking-links) — the user-facing behavior this data model powers
 - [**Talking to the Agent**](/docs/template-calendar-agent) — how the agent chooses between these actions and the raw Google Calendar API
-- [**Actions**](/docs/actions) — the action system this template is built on
+- [**Actions**](/docs/actions-overview) — the action system this template is built on
 - [**Sharing**](/docs/sharing) — the share-grant model `booking_link_shares` uses

package/docs/content/template-chat-first-edits.mdx

@@ -141,5 +141,5 @@ Use this when your model orchestration already lives elsewhere, but you still wa
 
 - [**Chat Template**](/docs/template-chat) — what ships by default and when to pick it
 - [**Chat — runtime and admin surfaces**](/docs/template-chat-developers) — core tables, auth, and the admin pages
-- [**Actions**](/docs/actions) — the action system chat and UI both call
+- [**Actions**](/docs/actions-overview) — the action system chat and UI both call
 - [**Native Chat UI**](/docs/native-chat-ui) — chat surface primitives and runtime options

package/docs/content/template-chat.mdx

@@ -132,6 +132,6 @@ Use it for scheduled jobs, queues, CLI loops, or external-agent workflows where
 - [**Getting Started**](/docs/getting-started) — build the chat-first path from action to inline result to app page
 - [**Templates**](/docs/cloneable-saas) — the Cloneable SaaS 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
+- [**Actions**](/docs/actions-overview) — the action system chat and UI both call
 - [**Native Chat UI**](/docs/native-chat-ui) — chat surface primitives and runtime options
 - [**Automation-First Apps**](/docs/pure-agent-apps) — no-browser workflows for jobs, queues, scripts, and external agents

package/docs/content/template-content-developers.mdx

@@ -360,5 +360,5 @@ The agent can make most of these changes itself — ask it to "add a tags column
 - [Databases, properties & forms](/docs/template-content-databases) — the full inline-database and external-source data model
 - [Local files, Notion & Builder CMS sync](/docs/template-content-sync) — the non-developer view of every sync surface
 - [Database](/docs/database) — the framework's Drizzle conventions and migration rules
-- [Actions](/docs/actions) — the action system every operation above is built on
+- [Actions](/docs/actions-overview) — the action system every operation above is built on
 - [Sharing](/docs/sharing) — the share-grant model `document_shares` builds on

package/docs/content/template-forms-developers.mdx

@@ -191,5 +191,5 @@ If you need new capabilities such as file uploads, signatures, or custom field w
 - [**Forms**](/docs/template-forms) — the product overview and non-developer tour
 - [**Building and publishing a form**](/docs/template-forms-building-publishing) — field types, conditional logic, and public-form protections
 - [**Responses, insights, and destinations**](/docs/template-forms-responses) — analyzing, exporting, and routing submissions
-- [**Actions**](/docs/actions) — the action system powering the builder
+- [**Actions**](/docs/actions-overview) — the action system powering the builder
 - [**Sharing**](/docs/sharing) — the `form_shares` role model

package/docs/content/template-forms.mdx

@@ -116,5 +116,5 @@ Live demo: [forms.agent-native.com](https://forms.agent-native.com).
 - [**Responses, insights, and destinations**](/docs/template-forms-responses) — analyzing, exporting, and routing submissions
 - [**Forms — data model and actions**](/docs/template-forms-developers) — the SQL schema and action reference, for developers
 - [**Templates**](/docs/cloneable-saas) — the Cloneable SaaS model
-- [**Actions**](/docs/actions) — the action system powering the builder
+- [**Actions**](/docs/actions-overview) — the action system powering the builder
 - [**Messaging**](/docs/messaging) — Slack and other submission destinations

package/docs/content/template-mail-developers.mdx

@@ -329,7 +329,7 @@ Emails flowing through the API have the shape `{ id, threadId, from, to, cc, sub
 
 Mail is yours to change. Everything important lives in a handful of places — start there.
 
-**Adding an agent capability.** Add a new file under `templates/mail/actions/` using `defineAction`. Your action becomes an agent tool, a CLI command (`pnpm action <name>`), and a typed frontend hook surface through `useActionQuery` / `useActionMutation`. Look at `templates/mail/actions/star-email.ts` for a short example or `templates/mail/actions/manage-automations.ts` for one with multiple sub-actions. See the [actions](/docs/actions) docs for the full pattern.
+**Adding an agent capability.** Add a new file under `templates/mail/actions/` using `defineAction`. Your action becomes an agent tool, a CLI command (`pnpm action <name>`), and a typed frontend hook surface through `useActionQuery` / `useActionMutation`. Look at `templates/mail/actions/star-email.ts` for a short example or `templates/mail/actions/manage-automations.ts` for one with multiple sub-actions. See the [actions](/docs/actions-overview) docs for the full pattern.
 
 **Changing the UI.** Routes are in `templates/mail/app/routes/` and components in `templates/mail/app/components/email/` and `templates/mail/app/components/layout/`. The app uses shadcn/ui primitives from `app/components/ui/` and Tabler Icons — stick to those.
 
@@ -354,6 +354,6 @@ data surface. See [Key Concepts](/docs/key-concepts#agent-modifies-code).
 - [**Inbox, Search & Automations**](/docs/template-mail-inbox) — the user-facing triage and automation flows
 - [**Drafting, Scheduling & the Draft Queue**](/docs/template-mail-drafts-and-queue) — the user-facing drafting flow
 - [**Talking to the Agent**](/docs/template-mail-agent) — prompts and the provider-API escalation path
-- [**Actions**](/docs/actions) — the action system this page's inventory is built on
+- [**Actions**](/docs/actions-overview) — the action system this page's inventory is built on
 - [**Extensions**](/docs/extensions) — building a widget for Mail's contact-sidebar slot
 - [**Automations**](/docs/automations) — the event-triggered engine mail's auto-triage rules build on

package/docs/content/toolkit-org-team.mdx

@@ -123,7 +123,7 @@ re-resolves the caller's app role on every guarded operation, and assignment
 edits require the org `owner`/`admin` role regardless of what the client
 believes. See
 [Organizations, Teams & Permissions → App roles](/docs/organizations-teams-permissions#app-roles-per-app-rbac)
-for the role model and [Actions → Authorization](/docs/actions#authorize) for
+for the role model and [Actions → Authorization](/docs/actions-access-control#authorize) for
 the server-side `authorize` guard.
 
 ## UX Standard {#ux-standard}

package/docs/content/tracking.mdx

@@ -390,6 +390,6 @@ The framework also tracks `builder connect clicked` from Connect Builder CTAs, a
 
 ## What's next
 
-- [**Actions**](/docs/actions) — where most tracking calls originate
+- [**Actions**](/docs/actions-overview) — where most tracking calls originate
 - [**Server Plugins**](/docs/server-plugins) — `registerBuiltinProviders()` runs in the core-routes plugin at startup
 - [**Security — Secrets Management**](/docs/security#secrets) — manage API keys for tracking providers

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

@@ -197,7 +197,7 @@ import { AgentSidebar } from "@agent-native/core/client/agent-chat";
 <AgentSidebar />;
 ```
 
-One action definition powers the UI button, the agent tool, an HTTP endpoint, an MCP surface, an A2A integration, and a CLI command. See [Actions](/docs/actions) for the full reference.
+One action definition powers the UI button, the agent tool, an HTTP endpoint, an MCP surface, an A2A integration, and a CLI command. See [Actions](/docs/actions-overview) for the full reference.
 
 ## How to get started {#how-to-get-started}
 

package/package.json

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