@agent-native/core 0.130.2 → 0.131.3

package/corpus/README.md

@@ -28,6 +28,6 @@ rg -n "defineAction|useActionQuery" node_modules/@agent-native/core/corpus
 
 ## Generated Counts
 
-- core files: 1635
+- core files: 1642
 - toolkit files: 160
-- template files: 6934
+- template files: 7179

package/corpus/core/CHANGELOG.md

@@ -1,5 +1,84 @@
 # @agent-native/core
 
+## 0.131.3
+
+### Patch Changes
+
+- 5b67dea: Advertise A2A action input schemas in capability details.
+- 5b67dea: Stop apps from handing each other raw queries to execute. An action whose input
+  is a program the receiver runs — `sql`, `code`, `script`, `expression` — is no
+  longer invocable by a sibling app over A2A.
+
+  The app that owns the data owns its schema, data dictionary, reference
+  dashboards, and dialect quirks. A calling app has none of that, so passing SQL
+  across apps makes every caller reimplement the owner's schema knowledge from
+  guesses, and each copy silently rots the next time the owner's shape changes.
+  Callers ask the owning app a question, or call a shaped action that takes
+  semantic parameters; the owner forms the query. `publicAgent.allowRawQueryInput`
+  opts a specific action out when that is genuinely the right call.
+
+  `query` is deliberately not treated as a raw query field: across the templates
+  it is natural-language search text (Brain's `search-everything`,
+  `search-knowledge`), and blocking it would break the ask-don't-instruct calls
+  this rule exists to encourage. MCP and in-app tool surfaces are unchanged — this
+  narrows cross-app invocation only.
+
+  Agent cards also now publish each advertised skill's `inputSchema`, and
+  `describe-workspace-apps` renders it as `input: { field*: type }`. Advertising an
+  action without its parameters is what led callers to invoke it with `{}` and fail
+  on a required field.
+
+## 0.131.2
+
+### Patch Changes
+
+- 8d4fac7: Exclude `.test.ts`/`.spec.ts` files from agent chat plugin action auto-discovery, so test/spec files are no longer registered as callable agent tools.
+- 901769d: Keep the session-authenticated remote-device relay routes under CSRF protection.
+  The `/integrations/` CSRF exemption exists for HMAC-verified webhooks, but
+  prefix matching extended it to `/integrations/remote/*`, where
+  `register`, `enqueue`, and `computer/{approvals,commands}` authenticate on the
+  `SameSite=None` session cookie. A cross-site simple-request POST could
+  therefore create and self-approve a browser-control operation — click, type, or
+  navigate on the victim's paired Chrome — without any first-party marker or
+  human approval step. Those routes are now excluded from the exemption; the
+  device's own bearer-token calls (`poll`, `result`, `heartbeat`) are unaffected.
+- 901769d: Keep completed chat history visible when a sidebar remounts.
+- 901769d: Keep background and scheduled recovery workers from starting duplicate recurring integration jobs that can exhaust shared database capacity and delay messaging replies.
+- 901769d: Keep Feedback visible in first-party Agent Native production apps even when the build-time feedback URL was not synced, while cloned apps remain opted out by default.
+- 901769d: Reuse an empty active chat for foreground requests that otherwise open a new tab.
+- Updated dependencies [901769d]
+- Updated dependencies [901769d]
+  - @agent-native/toolkit@0.11.1
+
+## 0.131.1
+
+### Patch Changes
+
+- 49e7191: Export `mutateOrgSetting` from `@agent-native/core/settings` alongside the other org-scoped helpers, so app code can perform atomic read/merge/write updates on org settings instead of racing separate `getOrgSetting`/`putOrgSetting` calls.
+
+## 0.131.0
+
+### Minor Changes
+
+- 24a5a20: Add a typed, bounded `browser-context.v1` contract for reusable readable,
+  design, and ephemeral browser-control context.
+- 24a5a20: Make extension creation and discovery opt-in, including authenticated REST
+  creation, label SQL-backed extensions as sandboxed custom blocks, and let
+  editors promote them into app code through a server-verified Builder handoff.
+
+### Patch Changes
+
+- 24a5a20: Keep scheduled automations classified correctly across scheduler writes, unify Jobs and Automations management, and give Scheduled and Event triggers one identity-checked execution lifecycle with organization scope and enforced MCP allowlists.
+- 24a5a20: Preserve source provenance when copying rendered UI between live local apps and Design files.
+- 24a5a20: Make generic public URL reads immediately available to agents and preserve
+  machine-readable discovery metadata and alternate links when extracting page
+  content, including in Plan mode. Large extensions now default to bounded,
+  targeted source excerpts so focused edits do not stall a run by loading an
+  entire generated app body.
+- 24a5a20: Let Plan mode discover every agent tool, execute calls classified as read-only, narrow mixed-tool schemas to safe inputs, and keep writes and unknown effects runtime-blocked.
+- Updated dependencies [24a5a20]
+  - @agent-native/toolkit@0.11.0
+
 ## 0.130.2
 
 ### Patch Changes

package/corpus/core/docs/content/agent-surfaces.mdx

@@ -59,7 +59,7 @@ The shared page currently provides twelve tabs across two groups:
 | Resources | **Remote agents** | A2A connections to other agent-native apps — this replaces what the Connections tab used to also show                                                                                                                |
 | Agent     | **Snapshots**     | A scope preview, token budget, ordered system sections grouped by provenance/governance/source, and the latest live-thread snapshot. Renamed from "Context"; old `#context` links redirect here.                     |
 | Agent     | **Connections**   | MCP server management only                                                                                                                                                                                           |
-| Agent     | **Jobs**          | Scoped recurring jobs and automations, with the existing pause/resume, details, and delete flows. Automations are personal-only today.                                                                               |
+| Agent     | **Automations**   | Personal and organization Scheduled/Event automations with pause/resume, details, and delete flows. The stable compatibility URL remains `/agent#jobs`.                                                              |
 | Agent     | **Settings**      | Agent model, API keys, limits, voice, and automation settings                                                                                                                                                        |
 | Agent     | **Access**        | The app MCP URL, an A2A agent card when available, and shared setup guides for Claude, ChatGPT, Cursor, Claude Code, Codex, and other clients. Links to `/mcp/connect` for the full connect flow and token fallback. |
 
@@ -165,9 +165,9 @@ is no "browse-everything-at-a-glance" view; if users need that, start from
 
 When you add the built-in Chat shell, the framework provides five management
 surfaces you don't have to build: **Chat** (the main input), **Resources**
-(skills, memory, instructions, sub-agents, connected MCP servers, scheduled
-jobs), **Job history**, **Thread history**, and **Settings**. Those are usually
-enough — talk to it, see what it's done, configure how it behaves. Reach for
+(skills, memory, instructions, sub-agents, and connected MCP servers),
+**Automations**, **Thread history**, and **Settings**. Those are usually enough
+— talk to it, see what it's done, configure how it behaves. Reach for
 [Chat](/docs/template-chat) when you're ready to add that browser UI, or the
 [Dispatch template](/docs/template-dispatch) for a workspace-style starting
 point with Slack/Telegram, scheduled jobs, and shared secrets out of the box.

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

@@ -5,9 +5,17 @@ description: "Event-triggered and scheduled automations with natural-language co
 
 # Automations
 
-An **automation** is a rule: _when X happens, do Y_ — described in natural language. The agent executes the instructions, so automations have access to every action, tool, and MCP server the agent can use in an interactive chat.
-
-Automations extend [recurring jobs](/docs/recurring-jobs) with **event triggers**, **natural-language conditions**, and **outbound HTTP** via the `web-request` tool. They use the same `jobs/<name>.md` file format, storage, and "create three ways" workflow as recurring jobs — see [Recurring Jobs](/docs/recurring-jobs#job-file) for the shared format. This page covers only what's new for event-driven automations.
+An **automation** is an agent-executed task that fires on a schedule or when an
+event occurs: _when X happens, do Y_. **Scheduled** and **Event** are the two
+trigger types, not separate products. The agent executes the instructions with
+the same action and tool lifecycle as interactive chat; connected MCP access is
+limited to the automation's explicit `mcpTools` allowlist.
+
+The framework originally exposed scheduled automations as **Recurring Jobs**.
+That name, the `jobs/<name>.md` storage path, and the `manage-jobs` tool remain
+for compatibility. New product guidance uses **Automations** as the umbrella;
+see [Recurring Jobs](/docs/recurring-jobs) when maintaining a legacy
+schedule-only integration or working with scheduler internals.
 
 <Diagram id="doc-block-jdto24" title="When X happens, do Y" summary="An event fires on the bus, an optional natural-language condition gates it, and the agent runs the automation body with full tool access.">
 
@@ -72,9 +80,21 @@ Event triggers can include a `condition` — a natural-language string evaluated
 
 The agent discovers available events, confirms the plan, and writes the automation for you.
 
-### From the settings UI
+### From the Automations UI
+
+Open **Automations** on the full-page Agent surface. It is the primary place to
+view scheduled and event-triggered automations, inspect status, pause or resume
+them, and delete them. Its compatibility URL remains `/agent#jobs`, so existing
+links and bookmarks continue to work.
+
+<Callout tone="info">
+
+**Personal and organization automations use the same management surface.**
+Organization event automations are visible to members but always run as their
+creator. An administrator can manage the definition, but cannot change who it
+runs as.
 
-Automations appear in the settings panel. Users can view, enable/disable, and delete them there.
+</Callout>
 
 The third path — writing the `jobs/<name>.md` file by hand via `resourcePut` — works exactly as it does for [recurring jobs](/docs/recurring-jobs#creating). For an event-driven automation you add the event-trigger frontmatter below to that same file. An event-triggered job sets `schedule: ""` and supplies `triggerType: event`, an `event` name, and an optional `condition`:
 
@@ -124,6 +144,26 @@ Automations share every field in the [recurring-jobs frontmatter table](/docs/re
 
 For an event trigger, `schedule` is `""` (empty); for a schedule trigger it carries the cron expression. The dispatcher also writes the same managed `lastRun` / `lastStatus` / `lastError` fields the scheduler does, plus a `"skipped"` status when a condition evaluates to false.
 
+`model` selects a per-automation model. `mcpTools` is an explicit list of MCP
+tool names such as `mcp__server__tool`. The shared execution runner exposes
+only those configured MCP tools and fails clearly if a named tool or its
+connected grant is unavailable.
+
+### Organization execution identity {#organization-identity}
+
+Organization Scheduled and Event automations are shared for visibility and
+management, not execution identity:
+
+- `createdBy` is required for an organization event automation, and `runAs` is
+  `creator`.
+- Event automations match only events emitted for that creator. An
+  organization-scoped automation is not an organization-wide event broadcast.
+- Organization administrators may update or delete the automation, but cannot
+  replace `createdBy` or retarget its identity.
+- Before execution, the framework verifies that the creator still exists and
+  remains an organization member. If the creator was removed—or membership
+  cannot be verified—the automation does not run.
+
 ## The event bus {#event-bus}
 
 Integrations register events at module load time. The bus validates payloads against [Standard Schema](https://standardschema.dev) definitions and dispatches to subscribers.
@@ -178,7 +218,9 @@ emit(
 );
 ```
 
-The `owner` in the emit metadata scopes which automations fire — only automations owned by the same user (or shared automations) are evaluated.
+The `owner` in the emit metadata scopes which automations fire. Personal and
+organization event automations both require an exact match with their
+`createdBy` identity.
 
 ## Conditions {#conditions}
 
@@ -247,7 +289,8 @@ Keys are ad-hoc secrets created by users or the agent for automation use (e.g. `
 
 ## Agent tools {#agent-tools}
 
-All automation operations are accessed through a single `manage-automations` tool with an `action` parameter:
+Trigger-aware personal and organization operations use `manage-automations`
+with an `action` parameter:
 
 | Action        | Purpose                                                              |
 | ------------- | -------------------------------------------------------------------- |
@@ -260,6 +303,10 @@ All automation operations are accessed through a single `manage-automations` too
 
 Additional tool: `web-request` — outbound HTTP with `${keys.NAME}` substitution.
 
+`define` and `update` accept personal or organization `scope`, a `model`
+override, and an `mcpTools` allowlist. `manage-jobs` remains the compatibility
+tool for existing schedule-only integrations and delivery metadata.
+
 ## API endpoints {#api}
 
 | Endpoint                               | Method | Description                     |
@@ -283,7 +330,7 @@ Confirm an automation's wiring and condition without waiting for a real provider
 
 ## How dispatch works {#dispatch}
 
-<Diagram id="doc-block-1ee1cky" title="The dispatch path" summary="From a fired event to a completed agent run, gated by ownership scope and the natural-language condition.">
+<Diagram id="doc-block-1ee1cky" title="The dispatch path" summary="Event and schedule acquisition stay separate, then converge on one identity-checked background execution lifecycle.">
 
 ```html
 <div class="disp">
@@ -299,7 +346,8 @@ Confirm an automation's wiring and condition without waiting for a real provider
   <div class="diagram-card">
     <span class="diagram-pill">scope</span
     ><small class="diagram-muted"
-      >keep only those owned by the event's owner (or shared)</small
+      >match <code>createdBy</code> to the event owner; verify org
+      membership</small
     >
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&darr;</div>
@@ -314,8 +362,8 @@ Confirm an automation's wiring and condition without waiting for a real provider
   <div class="diagram-card accent">
     <span class="diagram-pill accent">run</span
     ><small class="diagram-muted"
-      ><code>runAgentLoop</code> with body as prompt, payload as context, 5-min
-      timeout</small
+      >shared runner resolves identity, model, MCP allowlist, continuation,
+      delivery, and usage</small
     >
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&darr;</div>
@@ -380,6 +428,7 @@ notification to my webhook."_
 
 ```yaml filename="jobs/notify-on-plan-comment.md"
 ---
+schedule: ""
 triggerType: event
 event: plan.commented
 condition: "resolutionTarget is human or resolutionTarget is null"
@@ -400,7 +449,7 @@ for the full `plan.commented` payload reference and all four plan events.
 
 ## What's next
 
-- [**Recurring Jobs**](/docs/recurring-jobs) — schedule-triggered automations reuse the same scheduler
+- [**Recurring Jobs**](/docs/recurring-jobs) — legacy compatibility and advanced scheduled-job fields
 - [**Actions**](/docs/actions) — automations can call any registered action via the agent loop
 - [**Workflow Connectors**](/docs/automation-connectors) — pre-configured n8n/Zapier-style workflow invocation, for when ad-hoc `web-request` isn't a strict enough contract
 - [**Security**](/docs/security) — input validation and secret handling

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

@@ -582,7 +582,13 @@ write tools:
 export default createAgentChatPlugin({
   // Default: "read"
   databaseTools: "read", // "write" | "read" | "off"
-  extensionTools: false,
+  extensionTools: true,
+});
+```
+
+```ts filename="server/plugins/core-routes.ts"
+export default createCoreRoutesPlugin({
+  extensionTools: true,
 });
 ```
 
@@ -593,9 +599,10 @@ export default createAgentChatPlugin({
   current user/org and schema changes are blocked.
 - `databaseTools: "off"` or `false` — removes raw database tools from the
   agent surface so the app's actions are the only data access path.
-- `extensionTools: false` — removes framework extension-management actions and
-  prompt guidance (`create-extension`, `update-extension`, etc.) for apps that
-  do not want the agent creating sandboxed mini-apps.
+- `extensionTools: true` — opts the app into framework extension-management
+  actions and prompt guidance (`create-extension`, `update-extension`, etc.).
+  Set it on both plugins to also allow authenticated REST creation. Extensions
+  are disabled by default.
 
 ## Production Code Execution {#production-code-execution}
 

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

@@ -1,11 +1,18 @@
 ---
 title: "Extensions"
-description: "Mini-apps your users build inside your template — a custom KPI tile in Analytics, a meeting-prep checklist in Calendar, a contact CRM widget in Mail. No deploys, no code edits, no schema changes."
+description: "An optional toolkit capability for one-off, sandboxed custom blocks. App code remains the default for durable product behavior."
 ---
 
 # Extensions
 
-Extensions are **mini-apps your users build inside your template**.
+Extensions are an **optional toolkit capability for sandboxed custom blocks**.
+They are disabled by default. A template must opt in before its agent can create
+or manage them; Analytics uses this capability for explicitly requested,
+one-off custom visualizations.
+
+For durable behavior, edit the app code. A custom block is an agent-authored
+patch: useful when speed and local specificity matter, but not the default way
+to add a reusable product feature.
 
 When the agent needs a one-time interactive answer inside the chat itself, use
 [Generative UI](/docs/generative-ui) instead. Generative UI uses the same
@@ -37,10 +44,12 @@ Three things make extensions work:
 - **Full access to the template's data.** Extensions can call the same actions the agent calls — `list-emails` in Mail, `list-decks` in Slides, `list-recordings` in Clips — so they have everything the host app has.
 - **Built-in storage.** Each extension has its own per-user / per-org key-value store, so it can save state without you adding a new SQL table.
 
-If a template should not expose user-authored extensions, set
-`extensionTools: false` on `createAgentChatPlugin()`. That removes the
-agent-facing extension actions and prompt guidance while leaving the rest of the
-app agent intact.
+Extensions are disabled by default. To expose user-authored extensions, set
+`extensionTools: true` on both `createAgentChatPlugin()` and
+`createCoreRoutesPlugin()`. The first adds the agent-facing actions and prompt
+guidance; the second permits authenticated creation through
+`POST /_agent-native/extensions`. The sandbox runtime and existing read, edit,
+and deep-link routes remain available for compatibility either way.
 
 <Diagram id="doc-block-l8xkep" title="The sandbox bridge" summary={"Extension HTML runs in an isolated iframe and reaches the host only through a fixed set of bridge helpers — every call is scoped and access-checked."}>
 
@@ -649,33 +658,30 @@ The framework lets the agent edit the app's source code directly — components,
 routes, styles, and business logic. Use this question when either path could
 solve the request:
 
-- **Start with an extension** for a self-contained, relatively one-off widget:
-  a custom visualization or interaction, a dashboard tile, a standalone
-  utility, or an add-on in an existing slot. It is fast, requires no source
-  change, build, or deploy, and can be private or shared.
-- **Use app code** for a core feature of the template, a change to native UI,
-  layout, routes, or business logic, or anything that should be reused broadly
-  across dashboards or users. If the host has no suitable slot or the request
-  needs a new slot, use code.
-- **Promote repeated extensions.** If people keep rebuilding the same
-  extension, or maintaining copies in many places would be worse than one
-  shared implementation, move it into app code as a reusable native feature.
-
-|                       | Extension                                         | App code edit                        |
-| --------------------- | ------------------------------------------------- | ------------------------------------ |
-| **Created by**        | Agent (or user) at runtime                        | Agent editing source files           |
-| **Stored in**         | The database                                      | The git repository                   |
-| **Requires a build**  | No                                                | Yes                                  |
-| **Requires a deploy** | No                                                | Yes                                  |
-| **Scope**             | One user (or shared with org)                     | The entire product, every user       |
-| **Best for**          | Personal widgets, custom KPIs, per-team utilities | Core features that ship to all users |
-
-Rule of thumb: **if an extension can solve the problem, generally start there.**
-Use code when the extension boundary does not fit or when broad reuse and
-product-wide availability justify a native implementation. For example, a
-one-off custom visualization on a dashboard is a good extension; a new pie,
-multi-bar, or line chart type that should be available across dashboards
-belongs in the template code.
+- **Start with app code** for product behavior, native UI, layout, routes,
+  business logic, or anything that should be reused across dashboards or users.
+- **Use a custom block only when the app opts in** and the user explicitly wants
+  a bespoke, one-off visualization or interaction in an existing extension
+  surface. It is fast and requires no build or deploy, but remains a sandboxed
+  agent-authored patch.
+- **Promote durable custom blocks.** If a block becomes useful beyond its
+  original one-off context, use **Promote to app code** to hand it to the normal
+  source-change workflow. Keep the original block in place until the code
+  change is reviewed and deployed.
+
+|                       | Extension                      | App code edit                  |
+| --------------------- | ------------------------------ | ------------------------------ |
+| **Created by**        | Agent (or user) at runtime     | Agent editing source files     |
+| **Stored in**         | The database                   | The git repository             |
+| **Requires a build**  | No                             | Yes                            |
+| **Requires a deploy** | No                             | Yes                            |
+| **Scope**             | One user (or shared with org)  | The entire product, every user |
+| **Best for**          | Explicit one-off custom blocks | Durable product behavior       |
+
+Rule of thumb: **default to app code.** In an app that explicitly enables
+extensions, a one-off custom visualization on a dashboard can be a Custom
+Block; a new pie, multi-bar, or line chart type that should be available across
+dashboards belongs in the template code.
 
 If what you actually need is a cached, refreshable data source for an existing chart or table — not a new interactive widget — see [Data Programs](/docs/data-programs) instead; it shares this page's sandbox and security posture but has no UI of its own.
 

package/corpus/core/docs/content/recurring-jobs.mdx

@@ -1,19 +1,27 @@
 ---
 title: "Recurring Jobs"
-description: "Cron-scheduled prompts the agent runs on its own — daily digests, weekly reports, hourly polling."
+description: "Legacy compatibility reference for scheduled automations, cron execution, organization scope, and advanced job fields."
 ---
 
 # Recurring Jobs
 
-A **recurring job** is a prompt that runs on a cron schedule. It's how the agent does things on its own: "every morning at 7 summarize my overnight emails," "every Monday post last week's signup numbers to Slack," "every hour sweep for stale drafts and delete them."
+A **recurring job** is the legacy name for a **scheduled automation**: a prompt
+that runs on a cron schedule. New product guidance uses
+[Automations](/docs/automations) as the umbrella, with **Scheduled** and
+**Event** as trigger types.
 
-Recurring jobs fire on a clock. To react to _events_ (a booking created, an email received) — same `jobs/` file format plus conditions — see [Automations](/docs/automations).
+The Jobs name remains in file paths, APIs, and tools for compatibility.
+`manage-jobs` is schedule-only; new Scheduled and Event work uses
+`manage-automations`, including organization scope, model overrides, and MCP
+allowlists. This page remains the compatibility and scheduler reference.
 
 Jobs live in [Agent Resources](/docs/agent-resources) at `jobs/<name>.md` — just a Markdown file with YAML frontmatter. No registration, no wiring. Drop the file in and the framework picks it up.
 
 <Callout id="doc-block-rj1" tone="info">
 
-**New to recurring jobs?** Jump to [Creating a job](#creating) — most people create one by asking the agent or with the Resources tab `+` menu, not by hand-editing the file format below.
+**Creating new scheduled work?** Use the
+[Automations workflow](/docs/automations#creating). Continue here when you need
+the legacy `manage-jobs` API, delivery metadata, or scheduler internals.
 
 </Callout>
 
@@ -66,6 +74,7 @@ That's it. The body is a prompt the agent runs at each scheduled firing. The age
 | `lastStatus` | `"success"` \| `"error"` \| … | _(managed)_  | Latest outcome.                                                                                        |
 | `lastError`  | string                        | _(managed)_  | Error message if the last run failed.                                                                  |
 | `nextRun`    | ISO timestamp                 | _(managed)_  | Computed from `schedule`; used by the scheduler to decide when to fire next.                           |
+| `model`      | model id                      | _(default)_  | Optional model override for this automation.                                                           |
 | `mcpTools`   | array of MCP tool names       | _(none)_     | Optional explicit allowlist such as `mcp__server__tool`; credentials stay in the connected MCP grant.  |
 
 The `last*` and `nextRun` fields are written by the scheduler. You can read them to see the history, but don't edit them by hand — the next run will overwrite.
@@ -90,12 +99,13 @@ and external ids, a short citation, and the recording URL. Do not import the
 full transcript.
 ```
 
-The job stores tool names, not MCP URLs, access tokens, or OAuth refresh
-tokens. At run time, the framework resolves the connected grant in the job's
-creator or organization request context and exposes only the allowlisted
-tools. Keep the list narrow, and use an idempotent app action for the final
-import so overlapping runs do not create duplicates. See [MCP Clients](/docs/mcp-clients)
-for connection and OAuth setup.
+The automation stores tool names, not MCP URLs, access tokens, or OAuth refresh
+tokens. At run time, the shared background runner resolves the connected grant
+in the creator and organization request context and exposes only the
+allowlisted tools. A missing configured tool fails the run rather than widening
+access. Keep the list narrow, and use an idempotent app action for the final
+import so overlapping runs do not create duplicates. See
+[MCP Clients](/docs/mcp-clients) for connection and OAuth setup.
 
 ## Cron syntax {#cron}
 
@@ -115,9 +125,11 @@ The framework includes cron utilities (`isValidCron()` and `describeCron()`) for
 
 ## Creating a job {#creating}
 
-### From the Resources tab
+### From the Automations UI
 
-`+` → **Scheduled Task** in the Resources tab. Fill in the prompt and schedule. Saves as `jobs/<slug>.md` and starts running on the next matching tick.
+Open **Automations** on the full-page Agent surface, then create a
+**Scheduled** automation. The stable compatibility URL is `/agent#jobs`; the
+hash does not change when the visible tab name changes.
 
 ### By asking the agent
 
@@ -147,7 +159,7 @@ Summarize overnight emails.`,
 
 The scheduler is a framework plugin (the internal `processRecurringJobs()` routine) that runs in-process: a `setInterval` fires every 60 seconds (with a 10-second startup delay) inside the agent chat plugin, wherever the server is running.
 
-<Diagram id="doc-block-14nqnkx" title="One scheduler tick" summary="Every 60s the scheduler finds due jobs, runs each as a fresh agent thread, and writes the outcome back to the job file.">
+<Diagram id="doc-block-14nqnkx" title="One scheduler tick" summary="Every 60s the scheduler finds due jobs, then sends them through the same background execution lifecycle as event automations.">
 
 ```html
 <div class="sched">
@@ -170,8 +182,8 @@ The scheduler is a framework plugin (the internal `processRecurringJobs()` routi
   <div class="diagram-card accent">
     <span class="diagram-pill accent">3 &middot; run</span
     ><small class="diagram-muted"
-      >fresh agent thread, job body as the user message &mdash; actions, SQL,
-      A2A, email</small
+      >shared runner validates identity and resolves the model, MCP allowlist,
+      continuation, delivery, and usage</small
     >
   </div>
   <div class="diagram-arrow diagram-muted" aria-hidden="true">&darr;</div>
@@ -223,13 +235,18 @@ The scheduler is a framework plugin (the internal `processRecurringJobs()` routi
 
 ## Debugging a job {#debugging}
 
-- Open `jobs/<name>.md` in Agent Resources — the frontmatter shows `lastRun`, `lastStatus`, `lastError`, `nextRun`.
+- Open the automation's details in **Automations**, or inspect
+  `jobs/<name>.md` in Agent Resources — the frontmatter shows `lastRun`,
+  `lastStatus`, `lastError`, and `nextRun`.
 - **Test it without waiting:** there's no force-fire tool. To exercise the same work on demand, either paste the job's prompt into the agent chat and let it run there, or temporarily set the schedule to the next minute so the scheduler picks it up on the next tick (then restore the real cron). This only works if the scheduler is actually running — see the local-dev caveat above; set `AGENT_NATIVE_ENABLE_LOCAL_RECURRING_JOBS=1` first if you're testing on localhost.
 - **Pause it:** flip `enabled: false`. The file stays put, just stops running.
 
 ## Agent tool {#agent-tool}
 
-A single `manage-jobs` tool is registered in every template. The `action` parameter selects the operation:
+`manage-jobs` is the compatibility tool for existing schedule-only
+integrations. New Scheduled and Event automations—including organization
+scope, model overrides, and MCP allowlists—use `manage-automations`. The
+`action` parameter selects the legacy operation:
 
 | Action   | Parameters                                                                             | Purpose                                                      |
 | -------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------ |
@@ -240,7 +257,12 @@ A single `manage-jobs` tool is registered in every template. The `action` parame
 
 `model` is optional on both `create` and `update` — pass a model id to override the channel/app/engine default for that one routine.
 
-**Personal vs shared scope.** Each job lives in either personal scope (runs as and is visible only to the creator) or shared/org scope (runs on behalf of the creator but is visible to org members). The `scope` and `runAs` parameters control this at create time. Org admins can update or delete any shared job; non-admin members can only manage their own.
+**Personal vs shared scope.** Each automation lives in either personal scope
+(runs as and is visible only to the creator) or organization scope (visible to
+org members, but runs as the creator). Organization administrators can update
+or delete shared definitions but cannot change the creator identity. Before
+each organization run, the framework verifies that the creator still exists
+and remains a member; otherwise it does not execute.
 
 ## Different from the scheduling package {#vs-scheduling-package}
 
@@ -253,7 +275,7 @@ Recurring jobs are "how do I make the agent act on its own?" The scheduling pack
 
 ## What's next
 
-- [**Automations**](/docs/automations) — add event triggers and conditions to the same `jobs/` format
+- [**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
 - [**MCP Clients**](/docs/mcp-clients) — connect remote or local MCP tools and OAuth grants

package/corpus/core/docs/content/template-dispatch-operations.mdx

@@ -1,15 +1,26 @@
 ---
-title: "Operating the workspace: jobs, Dreams, and the operator console"
-description: "Recurring jobs, the Dreams memory review loop, the /operations console's Monitoring and Database tabs, and where to look for thread history, change history, and usage."
+title: "Operating the workspace: automations, Dreams, and the operator console"
+description: "Scheduled automations, the Dreams memory review loop, the /operations console's Monitoring and Database tabs, and where to look for thread history, change history, and usage."
 ---
 
-# Operating the workspace: jobs, Dreams, and the operator console
+# Operating the workspace: automations, Dreams, and the operator console
 
-Once Dispatch is coordinating a workspace, this is where you keep it healthy day to day: recurring jobs, the Dreams review loop that watches how agents are actually doing, and the operator console for monitoring, database admin, thread debugging, audit history, and usage. It's for whoever runs the workspace.
+Once Dispatch is coordinating a workspace, this is where you keep it healthy day to day: scheduled automations, the Dreams review loop that watches how agents are actually doing, and the operator console for monitoring, database admin, thread debugging, audit history, and usage. It's for whoever runs the workspace.
 
-## Scheduled jobs hub {#jobs}
+## Automations hub {#jobs}
 
-Cross-app [recurring jobs](/docs/recurring-jobs) live here: "every weekday at 7, pull yesterday's key metrics from analytics and draft a morning summary email." The **Automations** page shows enabled state, last run, next run, and last error for every job, sourced from the underlying `jobs/*.md` schedules, and lets you enable or disable a job without editing files by hand. A failed job's row links straight to **Troubleshoot in Thread Debug**. To create one, describe what you want automated in the composer — personal or organization scope — and the agent turns it into a job with `manage-automations`.
+Cross-app scheduled automations live here: "every weekday at 7, pull
+yesterday's key metrics from analytics and draft a morning summary email." The
+**Automations** page shows enabled state, last run, next run, and last error,
+sourced from the underlying `jobs/*.md` resources, and lets you enable or
+disable scheduled work without editing files by hand. A failed row links
+straight to **Troubleshoot in Thread Debug**.
+
+Describe new scheduled work in the composer and the agent creates it. Personal
+automations use the trigger-aware `manage-automations` workflow. Existing
+organization-scoped schedules remain legacy recurring jobs managed through
+`manage-jobs`; event-triggered and trigger-aware automations do not support
+organization scope today.
 
 ## Dreams {#dreams}
 
@@ -156,5 +167,6 @@ Use these for concrete thread, change-history, and usage investigations instead
 - [**Dispatch**](/docs/template-dispatch) — the workspace control plane overview
 - [**Secrets, integrations, and workspace connections**](/docs/template-dispatch-vault-integrations) — the vault and provider integrations
 - [**Messaging, routing, and approvals**](/docs/template-dispatch-messaging-routing) — channels and the approval queue
-- [**Recurring Jobs**](/docs/recurring-jobs) — scheduled tasks Dispatch runs
+- [**Automations**](/docs/automations) — scheduled and event-triggered tasks
+- [**Recurring Jobs**](/docs/recurring-jobs) — legacy scheduled-job compatibility and organization scope
 - [**Observability**](/docs/observability) — the dashboard the Monitoring tab reuses

package/corpus/core/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.130.2",
+  "version": "0.131.3",
   "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": {
@@ -72,8 +72,10 @@
     "./server/sse": "./dist/server/sse.js",
     "./server/short-lived-token": "./dist/server/short-lived-token.js",
     "./integrations": "./dist/integrations/index.js",
+    "./integrations/computer-supervision": "./dist/integrations/computer-supervision.js",
     "./integrations/runtime": "./dist/integrations/runtime.js",
     "./ingestion": "./dist/ingestion/index.js",
+    "./browser-context": "./dist/browser-context/index.js",
     "./search-utils": "./dist/search-utils/index.js",
     "./search": "./dist/search/index.js",
     "./embeddings": "./dist/embeddings/index.js",

package/corpus/core/src/a2a/types.ts

@@ -85,6 +85,12 @@ export interface AgentSkill {
   requiresAuth?: boolean;
   isConsequential?: boolean;
   publicAgent?: PublicAgentActionConfig;
+  /**
+   * JSON Schema for the action's `input`. Advertising a skill without it tells a
+   * caller the action exists but not how to call it, so callers invoke with `{}`
+   * and get a required-property error back.
+   */
+  inputSchema?: Record<string, unknown>;
 }
 
 export interface AgentCapabilities {