@agent-native/core 0.114.16 → 0.115.3

package/dist/templates/chat/.agents/skills/agent-native-docs/SKILL.md

@@ -66,6 +66,33 @@ state, auth, and agent-chat runtime contracts. Never edit `node_modules` or
 deep-import its private source. Manual copying is only the fallback described by
 an unknown third-party package's add-style blueprint.
 
+## Reuse Proven Patterns (rg + cp)
+
+Version-matched installed source outranks web docs or memory: it is the exact
+code shipping with this app. `node_modules/@agent-native/core/corpus/templates/`
+holds source for every first-party template, not just the one this app started
+from, so a pattern from the mail template is fair game for a tasks app. Grep
+across it, then copy a whole file as a starting point instead of writing the
+pattern from scratch:
+
+```bash
+# Find how other templates solved a similar problem
+rg -n "drag.*drop|reorder" node_modules/@agent-native/core/corpus/templates
+
+# Grab a proven action file as a starting point, then adapt names/schema
+cp node_modules/@agent-native/core/corpus/templates/mail/actions/archive-email.ts \
+   actions/archive-item.ts
+
+# Read the full framework source behind an API, not just the corpus copy
+rg -n "defineAction" node_modules/@agent-native/core/src/action.ts
+```
+
+Copying template-level app code (actions, components, skill files) is the
+expected reuse path — templates exist to be forked. This is different from
+copying `core`/`toolkit` **runtime internals**: for those, follow
+`customizing-agent-native`'s configure/compose/eject ladder instead of
+hand-duplicating framework logic.
+
 ## Useful Slugs
 
 | Need                           | Slugs                                                         |

package/dist/templates/chat/AGENTS.md

@@ -1,4 +1,4 @@
-# {{APP_NAME}} — Agent Guide
+# Chat — Agent Guide
 
 Chat is the minimal chat-first agent-native app template. Keep chat as the
 primary surface, add actions for real capabilities, and add screens only when a

package/dist/templates/default/.agents/skills/agent-native-docs/SKILL.md

@@ -66,6 +66,33 @@ state, auth, and agent-chat runtime contracts. Never edit `node_modules` or
 deep-import its private source. Manual copying is only the fallback described by
 an unknown third-party package's add-style blueprint.
 
+## Reuse Proven Patterns (rg + cp)
+
+Version-matched installed source outranks web docs or memory: it is the exact
+code shipping with this app. `node_modules/@agent-native/core/corpus/templates/`
+holds source for every first-party template, not just the one this app started
+from, so a pattern from the mail template is fair game for a tasks app. Grep
+across it, then copy a whole file as a starting point instead of writing the
+pattern from scratch:
+
+```bash
+# Find how other templates solved a similar problem
+rg -n "drag.*drop|reorder" node_modules/@agent-native/core/corpus/templates
+
+# Grab a proven action file as a starting point, then adapt names/schema
+cp node_modules/@agent-native/core/corpus/templates/mail/actions/archive-email.ts \
+   actions/archive-item.ts
+
+# Read the full framework source behind an API, not just the corpus copy
+rg -n "defineAction" node_modules/@agent-native/core/src/action.ts
+```
+
+Copying template-level app code (actions, components, skill files) is the
+expected reuse path — templates exist to be forked. This is different from
+copying `core`/`toolkit` **runtime internals**: for those, follow
+`customizing-agent-native`'s configure/compose/eject ladder instead of
+hand-duplicating framework logic.
+
 ## Useful Slugs
 
 | Need                           | Slugs                                                         |

package/dist/templates/default/.agents/skills/app-branding/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: app-branding
+description: >-
+  How to rename or rebrand the app so every surface — title, package metadata,
+  PWA manifest, and icons — stays consistent. Use when a prompt establishes or
+  implies a new app name, title, or visual identity, OR when you generate an app
+  title, theme, or icon yourself while scaffolding an app from an initial prompt.
+scope: dev
+metadata:
+  internal: true
+---
+
+# App Branding
+
+## Trigger
+
+Read this skill whenever the app's name, title, or visual identity is being
+established or changed — whether the user states it or **you derive it yourself**.
+
+- **Explicit** — the prompt names the app: "rename this app to …", "this is a
+  Todo app called …", "call this app …".
+- **Implicit / agent-generated** — the prompt describes what to build but leaves
+  the branding to you: "build me a habit tracker", "turn this into a recipe
+  manager", "make a CRM for my studio". The moment you decide on a title, theme
+  color, or icon from that prompt, treat it as a branding change and apply the
+  full checklist so your generated identity lands on every surface — not just
+  the one screen you happen to be building.
+
+If you are inventing an app title, theme, or icon as part of scaffolding a new
+app from an initial prompt, that counts — run the checklist in the same pass.
+
+## Rule
+
+Apply **all** of the updates below in a single consistent pass. Depending on the
+template, the app name may live in one source-of-truth module or be spread
+across several files — either way, a partial rename leaves the app half-branded
+(a stale tab title, launcher label, or icon).
+
+Derive three values once, then reuse them everywhere:
+
+- **Title** — human-readable display name, e.g. `"My Task App"`.
+- **Slug** — URL/npm-safe form: lowercase letters, digits, and hyphens only,
+  e.g. `"my-task-app"`.
+- **Description** — one sentence describing what the app does.
+
+## Locate the layout first
+
+Branding lives in different places depending on the template. Detect which
+layout you are in before editing:
+
+- **Centralized layout** — `app/lib/app-config.ts` exists. It is the single
+  source of truth for the name and title; the frontend surfaces (`<title>`,
+  route `meta()`, header, sidebar, index heading, `apple-mobile-web-app-title`)
+  derive from its `APP_NAME` / `APP_TITLE` exports, so you change the name in one
+  place.
+- **Inlined layout** — no `app/lib/app-config.ts`. The name and title are
+  written directly into `package.json`, each route's `meta()`, and
+  `app/root.tsx`. You must update each surface individually.
+
+When in doubt, `grep -rn` the current title and slug across `app/`, `server/`,
+`package.json`, and `public/` and fix every real hit — the two layouts share the
+manifest and icon steps regardless.
+
+## The Checklist
+
+### Step 1 — App name + title source
+
+**Centralized layout** (`app/lib/app-config.ts`): change both constants and stop —
+the rest of the frontend derives from them.
+
+- `rawAppName` → the **slug**.
+- `rawAppTitle` → the **title**.
+
+**Inlined layout** (no `app-config.ts`): set the title/slug at each surface.
+
+- Every route `meta()` title under `app/routes/*.tsx` (e.g. `_index.tsx`,
+  `agent.tsx`, `settings.tsx`) — replace the app title. These are seeded from a
+  `{{APP_TITLE}}` placeholder at scaffold time and become plain literals
+  afterward.
+- Any `useActionQuery("hello", { name: … })` in `app/routes/_index.tsx` seeded
+  with the title.
+- `app/root.tsx` `apple-mobile-web-app-title` — a literal (often `"App"`); set it
+  to the **title**.
+
+### Step 2 — `package.json` (both layouts)
+
+- `displayName` → the **title** (add the field if the template omits it).
+- `description` → the **description** (add if absent).
+- `name` → the **slug**. Only change this if the user explicitly asks to rename
+  the package (it is the npm package identifier).
+
+### Step 3 — Login / auth title (centralized layout only)
+
+If `server/plugins/auth.ts` exists it keeps its **own** duplicate `rawAppTitle`,
+used on the login/signup pages. Set it to the same **title** as
+`app/lib/app-config.ts`. (The inlined layout's `server/middleware/auth.ts`
+carries no app title — skip this step there.)
+
+### Step 4 — `public/manifest.json` (both layouts)
+
+This is a static file (not generated by a plugin). Update:
+
+- `name` → the **title** (full install name in OS app drawers).
+- `short_name` → a compact launcher label; keep it ≤12 characters, abbreviating
+  the title if needed.
+- `description` → the same **description** used in `package.json`.
+
+### Step 5 — Icon SVG files (both layouts)
+
+Replace the icon files with a new mark that reflects the app's identity. The set
+present depends on the template; update each one you find:
+
+| File | Purpose |
+| --- | --- |
+| `public/favicon.svg` | Browser tab favicon |
+| `public/icon-180.svg` | Apple touch icon (iOS home screen) |
+| `public/icon-192.svg` | PWA install icon (Android / Chrome) |
+| `public/icon-512.svg` | PWA install icon (large / splash) |
+
+Build the icon from **SVG primitives** — do not embed a base64-encoded PNG. All
+files should share the same visual design; only the `width` and `height`
+attributes differ. A simple, reliable approach: a filled rounded square in the
+brand color with the first letter (or a relevant glyph) centered in white.
+
+Template to adapt (change `fill`, the letter/glyph, and `rx` to suit the brand):
+
+```svg
+<svg xmlns="http://www.w3.org/2000/svg" width="192" height="192" viewBox="0 0 192 192">
+  <rect width="192" height="192" rx="40" fill="#2563EB"/>
+  <text x="96" y="130" font-family="system-ui, sans-serif" font-size="110"
+        font-weight="700" fill="white" text-anchor="middle">A</text>
+</svg>
+```
+
+Keep `width`/`height` at `180`, `192`, and `512` for the respective icon files;
+`favicon.svg` can use any of these sizes (the `viewBox` keeps it scalable).
+
+## What NOT to change
+
+These are stable identifiers or template-internal files, not user-facing brand:
+
+- `configureTracking({ app, template })` in `app/root.tsx` — analytics
+  identifiers seeded at scaffold time; leave them. This holds even in the inlined
+  layout, where `app` was seeded from the slug — changing it re-keys analytics
+  history.
+- `server/plugins/agent-chat.ts` `appId` (centralized layout) — a stable
+  platform analytics/routing key; leave it exactly as scaffolded.
+- `.github/workflows/*.yml` — template automation; references the repo/template
+  identity, not the running app.
+- `AGENTS.md` / `DEVELOPING.md` — developer docs for the template itself.
+
+## Verification
+
+- `pnpm typecheck` passes.
+- Grep for the old title/slug across `app/`, `server/`, `package.json`, and
+  `public/` — no unintended leftovers remain (except the intentional
+  "do not change" identifiers above).
+- The browser tab title, sidebar/header, and index heading all show the new
+  title.

package/dist/templates/default/.agents/skills/app-permissions/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: app-permissions
+description: >-
+  How to enable browser feature permissions (camera, microphone, geolocation,
+  screen capture, clipboard, wake-lock) that the framework's default
+  Permissions-Policy header blocks. Use when the app must access a device or
+  browser capability that is silently failing.
+scope: dev
+metadata:
+  internal: true
+---
+
+# App Permissions — Enabling Browser Features
+
+## Rule
+
+When the app needs a browser feature that the default `Permissions-Policy`
+disables, re-enable it for first-party use in
+`server/plugins/permission-policy.ts` — change only the directive the feature
+needs, never weaken the others, and never edit the `@agent-native/*` framework
+package.
+
+## Why
+
+There are **two independent layers** between the app and a device capability, and
+this skill only touches the first one:
+
+1. **The `Permissions-Policy` gate.** This HTTP response header decides whether a
+   feature is even available in the document:
+   - `feature=()` — disabled everywhere. The JS API fails and **no browser prompt
+     is possible**.
+   - `feature=(self)` — allowed for same-origin (first-party) code.
+   - `feature=*` — allowed including cross-origin iframes.
+2. **The browser's own permission prompt.** The Allow/Block dialog only appears
+   when the app's JS actually calls the API (`getUserMedia`,
+   `navigator.geolocation.getCurrentPosition`, `getDisplayMedia`, …) **and** the
+   gate above allows the feature.
+
+So this skill's job is only to **open the gate**. It does not — and cannot —
+grant the permission itself; the user still approves the browser prompt when the
+app calls the API. If the gate is closed, the prompt never even shows and the
+call silently fails, which is the symptom that brings you here.
+
+The framework sets this default on every response (via `@agent-native/core`'s
+security-headers middleware, mounted before routes, last-write-wins):
+
+```
+camera=*, microphone=(self), geolocation=(), screen-wake-lock=()
+```
+
+Note the empty allowlists: `geolocation=()` and `screen-wake-lock=()` are
+disabled document-wide by default. Camera and microphone are already open.
+
+## How
+
+1. **Locate the plugin.** If `server/plugins/permission-policy.ts` already exists,
+   edit its `PERMISSIONS_POLICY` string to add or adjust the directive the feature
+   needs. If it does not exist, create it from the template below.
+2. **Change only what's needed.** Start from the framework default string and flip
+   only the directive(s) the feature requires — e.g. `geolocation=()` →
+   `geolocation=(self)`. Keep every other directive exactly as the default unless
+   the feature genuinely needs it relaxed. Prefer `(self)` over `*`; only use `*`
+   when a cross-origin iframe must use the feature (the default already does this
+   for `camera`).
+3. **Keep the first-request deferral.** The security middleware is registered
+   during bootstrap and `Permissions-Policy` is last-write-wins. If this plugin
+   called `getH3App(nitroApp).use(...)` at bootstrap time it would register
+   *before* the security middleware and be overwritten. Registering inside the
+   first `request` hook makes the handler append **after** the security
+   middleware, so its value wins. Do not "simplify" this into a bootstrap-time
+   `.use()`.
+4. **Typecheck.** Editing server source is a Tier 2 change — run `pnpm typecheck`
+   afterward (see `self-modifying-code`).
+
+Reference implementation (`server/plugins/permission-policy.ts`):
+
+```ts
+import { getH3App } from "@agent-native/core/server";
+import { defineEventHandler, setResponseHeader } from "h3";
+
+// Framework default: camera=*, microphone=(self), geolocation=(), screen-wake-lock=()
+// Empty allowlist () disables a feature document-wide (no browser prompt).
+// Re-enable only what the app needs, for first-party (self) use.
+// Registered on first request so this .use() appends AFTER the core
+// security middleware (last write wins for Permissions-Policy).
+const PERMISSIONS_POLICY =
+  "camera=*, microphone=(self), geolocation=(self), screen-wake-lock=()";
+
+export default (nitroApp: {
+  hooks?: { hook?: (name: string, cb: () => void) => void };
+}) => {
+  const hook = nitroApp?.hooks?.hook;
+  if (typeof hook !== "function") return;
+
+  let registered = false;
+  hook.call(nitroApp.hooks, "request", () => {
+    if (registered) return;
+    registered = true;
+    getH3App(nitroApp).use(
+      defineEventHandler((event) => {
+        setResponseHeader(event, "Permissions-Policy", PERMISSIONS_POLICY);
+      }),
+    );
+  });
+};
+```
+
+## Common directives
+
+Map the capability the app needs to the `Permissions-Policy` directive to add:
+
+| Capability | Directive | Recommended value |
+| --- | --- | --- |
+| Current location | `geolocation` | `geolocation=(self)` |
+| Camera | `camera` | `camera=*` (framework default) or `camera=(self)` |
+| Microphone | `microphone` | `microphone=(self)` |
+| Screen / tab capture | `display-capture` | `display-capture=(self)` |
+| Keep screen awake | `screen-wake-lock` | `screen-wake-lock=(self)` |
+| Clipboard read/write | `clipboard-read`, `clipboard-write` | `clipboard-read=(self), clipboard-write=(self)` |
+| Fullscreen | `fullscreen` | `fullscreen=(self)` |
+| Motion / orientation sensors | `accelerometer`, `gyroscope`, `magnetometer` | `accelerometer=(self)` (etc.) |
+
+Add directives to the comma-separated string; the browser ignores tokens it
+doesn't recognize, so unknown/experimental features degrade gracefully.
+
+**Not every capability is governed by `Permissions-Policy`.** The Notifications
+API and Web Push, for example, are gated only by their own browser prompt — they
+need no directive here. For surfacing alerts to the user in-app, see the
+`notifications` skill.
+
+## Don't
+
+- **Don't edit `@agent-native/*` package files** or the core security-headers
+  middleware — Tier 4, off limits (see `self-modifying-code`). Override the header
+  from this app-owned plugin instead.
+- **Don't register the handler at bootstrap time.** It will run before the
+  security middleware and its header value will be overwritten. Use the first
+  `request` hook as shown.
+- **Don't broaden a directive to `*`** when `(self)` is enough — `*` exposes the
+  feature to cross-origin iframes.
+- **Don't blanket-enable** features the app doesn't actually use; keep the closed
+  directives closed.
+- **Don't add `/api/*` routes or client-side hacks** to work around a blocked
+  feature — the fix is the header.
+
+## Related Skills
+
+- **security** — HTTP response headers and app-level data/access permissions
+  (distinct from these browser feature permissions).
+- **self-modifying-code** — editing server source is a Tier 2 change; typecheck
+  after and checkpoint with git.
+- **notifications** — user-facing alerts and the Notifications API, which this
+  skill does not cover.
+- **adding-a-feature** — the four-area checklist when the capability is part of a
+  larger feature.

package/dist/templates/headless/.agents/skills/agent-native-docs/SKILL.md

@@ -66,6 +66,33 @@ state, auth, and agent-chat runtime contracts. Never edit `node_modules` or
 deep-import its private source. Manual copying is only the fallback described by
 an unknown third-party package's add-style blueprint.
 
+## Reuse Proven Patterns (rg + cp)
+
+Version-matched installed source outranks web docs or memory: it is the exact
+code shipping with this app. `node_modules/@agent-native/core/corpus/templates/`
+holds source for every first-party template, not just the one this app started
+from, so a pattern from the mail template is fair game for a tasks app. Grep
+across it, then copy a whole file as a starting point instead of writing the
+pattern from scratch:
+
+```bash
+# Find how other templates solved a similar problem
+rg -n "drag.*drop|reorder" node_modules/@agent-native/core/corpus/templates
+
+# Grab a proven action file as a starting point, then adapt names/schema
+cp node_modules/@agent-native/core/corpus/templates/mail/actions/archive-email.ts \
+   actions/archive-item.ts
+
+# Read the full framework source behind an API, not just the corpus copy
+rg -n "defineAction" node_modules/@agent-native/core/src/action.ts
+```
+
+Copying template-level app code (actions, components, skill files) is the
+expected reuse path — templates exist to be forked. This is different from
+copying `core`/`toolkit` **runtime internals**: for those, follow
+`customizing-agent-native`'s configure/compose/eject ladder instead of
+hand-duplicating framework logic.
+
 ## Useful Slugs
 
 | Need                           | Slugs                                                         |

package/dist/templates/workspace-core/.agents/skills/agent-native-docs/SKILL.md

@@ -66,6 +66,33 @@ state, auth, and agent-chat runtime contracts. Never edit `node_modules` or
 deep-import its private source. Manual copying is only the fallback described by
 an unknown third-party package's add-style blueprint.
 
+## Reuse Proven Patterns (rg + cp)
+
+Version-matched installed source outranks web docs or memory: it is the exact
+code shipping with this app. `node_modules/@agent-native/core/corpus/templates/`
+holds source for every first-party template, not just the one this app started
+from, so a pattern from the mail template is fair game for a tasks app. Grep
+across it, then copy a whole file as a starting point instead of writing the
+pattern from scratch:
+
+```bash
+# Find how other templates solved a similar problem
+rg -n "drag.*drop|reorder" node_modules/@agent-native/core/corpus/templates
+
+# Grab a proven action file as a starting point, then adapt names/schema
+cp node_modules/@agent-native/core/corpus/templates/mail/actions/archive-email.ts \
+   actions/archive-item.ts
+
+# Read the full framework source behind an API, not just the corpus copy
+rg -n "defineAction" node_modules/@agent-native/core/src/action.ts
+```
+
+Copying template-level app code (actions, components, skill files) is the
+expected reuse path — templates exist to be forked. This is different from
+copying `core`/`toolkit` **runtime internals**: for those, follow
+`customizing-agent-native`'s configure/compose/eject ladder instead of
+hand-duplicating framework logic.
+
 ## Useful Slugs
 
 | Need                           | Slugs                                                         |

package/dist/templates/workspace-core/.agents/skills/extensions/SKILL.md

@@ -227,25 +227,29 @@ extension content:
 { "name": "My Dashboard", "contentFromAttachment": "latest" }
 ```
 
-`update-extension` accepts the same `contentFromAttachment` for full-body
-replacement, but full-body replacement requires `allowFullReplacement: true`.
-Inline `content` still works for everything you author yourself — use
-`contentFromAttachment` only to avoid regurgitating something the user already
-pasted.
+`update-extension` accepts the same `contentFromAttachment` inside its compact
+`payloadJson` string for a full-body replacement. Use `operation: "replace"`;
+that explicit operation is the safety acknowledgement for a broad rewrite.
+Inline `content` still works inside `payloadJson` for everything you author
+yourself — use `contentFromAttachment` only to avoid regurgitating something
+the user already pasted.
 
 ## Editing an extension
 
-Use the `update-extension` action. Prefer granular `edits` for surgical
-changes instead of regenerating the full HTML. For medium/large extensions,
-add stable section comments around major blocks so future agents can target
-them without touching unrelated indentation:
+Use the `update-extension` action with exactly `id`, `operation`, and
+`payloadJson`. The payload is encoded as a JSON string so model gateways cannot
+fill every optional field with empty placeholders. Prefer `operation: "edit"`
+with granular `edits` inside `payloadJson` for surgical changes instead of
+regenerating the full HTML. For medium/large extensions, add stable section
+comments around major blocks so future agents can target them without touching
+unrelated indentation:
 
 For data-only repairs, preserve the existing layout, CSS, copy, and
 interactions. Do not reconstruct and submit the entire body. The action and
-store reject full-body replacement unless `allowFullReplacement: true` is
-explicitly supplied for a user-requested visual rewrite or complete replacement
-body. If a focused edit fails, inspect the current body and adjust its target;
-do not retry unchanged arguments.
+store reject implicit full-body replacement; choose `operation: "replace"`
+only for a user-requested visual rewrite or complete replacement body. If a
+focused edit fails, inspect the current body and adjust its target; do not retry
+unchanged arguments.
 
 ```html
 <!-- agent-native:section npm-daily-chart -->
@@ -258,8 +262,8 @@ Then update just that section:
 ```json
 {
   "id": "EXTENSION_ID",
-  "edits": "[{\"op\":\"replace-section\",\"section\":\"npm-daily-chart\",\"content\":\"<section>...</section>\"}]",
-  "format": true
+  "operation": "edit",
+  "payloadJson": "{\"edits\":[{\"op\":\"replace-section\",\"section\":\"npm-daily-chart\",\"content\":\"<section>...</section>\"}],\"format\":true}"
 }
 ```
 
@@ -278,9 +282,8 @@ Supported `edits` operations:
 
 Use `expectedMatches` when ambiguity would be dangerous. Missing required
 targets fail instead of silently doing nothing. Pass `format: true` to run
-Prettier on the final HTML after the patch. Full `content` replacement is
-still available for broad rewrites when `allowFullReplacement: true` is
-supplied.
+Prettier on the final HTML after the patch. Full `content` replacement remains
+available for broad rewrites through `operation: "replace"`.
 
 Legacy `patches` still work for simple literal replacements:
 
@@ -304,6 +307,16 @@ PUT /_agent-native/extensions/:id
 { "content": "full new HTML", "allowFullReplacement": true }
 ```
 
+For the agent action, use the compact form instead:
+
+```json
+{
+  "id": "EXTENSION_ID",
+  "operation": "replace",
+  "payloadJson": "{\"content\":\"full new HTML\"}"
+}
+```
+
 ## History and rollback
 
 Extensions keep a snapshot history in SQL. A version is recorded when an

package/dist/templates/workspace-core/.agents/skills/recurring-jobs/SKILL.md

@@ -21,6 +21,21 @@ Recurring jobs are scheduled tasks the agent executes automatically on a cron sc
 3. A scheduler polls every 60 seconds, finds due jobs, and executes them via `runAgentLoop`
 4. Job results are saved as chat threads
 
+## Connected MCPs in background jobs
+
+Jobs can use connected remote MCPs with the same server-side OAuth lifecycle as
+interactive chat. When creating a job that needs an MCP, bind the exact
+advertised `mcp__<server>__<tool>` names through `mcpTools`. The scheduler
+resolves only that allowlist under the job's persisted user/org request
+context; it never stores or exposes OAuth tokens, URLs, or arbitrary proxy
+targets. A revoked connector or missing tool fails the run clearly instead of
+silently widening access.
+
+Use an app-owned bounded import/upsert action for writes. Keep provider-specific
+response mapping, provenance, deduplication, and write policy in the app rather
+than in core. For example, a job can read meeting notes from any connected MCP
+and pass normalized action items to an app's idempotent `import` action.
+
 ## Job Tool (built in)
 
 | Tool          | Action     | Purpose                                                    |

package/dist/triggers/actions.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"actions.d.ts","sourceRoot":"","sources":["../../src/triggers/actions.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,8BAA8B,CAAC;AAwNhE,wBAAgB,2BAA2B,CACzC,cAAc,EAAE,MAAM,MAAM,GAC3B,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,CAuG7B"}
+{"version":3,"file":"actions.d.ts","sourceRoot":"","sources":["../../src/triggers/actions.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,8BAA8B,CAAC;AA4NhE,wBAAgB,2BAA2B,CACzC,cAAc,EAAE,MAAM,MAAM,GAC3B,MAAM,CAAC,MAAM,EAAE,WAAW,CAAC,CA4G7B"}

package/dist/triggers/actions.js

@@ -97,6 +97,7 @@ async function handleDefine(args, getCurrentUser) {
         condition: args.condition || undefined,
         mode: "agentic",
         domain: args.domain || undefined,
+        delegatedPolicyId: args.delegated_policy_id || undefined,
         createdBy: owner,
         runAs: "creator",
     };
@@ -124,6 +125,9 @@ async function handleUpdate(args, getCurrentUser) {
     if (args.condition !== undefined) {
         meta.condition = args.condition || undefined;
     }
+    if (args.delegated_policy_id !== undefined) {
+        meta.delegatedPolicyId = args.delegated_policy_id || undefined;
+    }
     const newBody = args.body ?? body;
     await resourcePut(resource.owner, resource.path, buildTriggerContent(meta, newBody));
     await refreshEventSubscriptions();
@@ -175,8 +179,8 @@ export function createAutomationToolEntries(getCurrentUser) {
 
 - **list-events**: List all registered event types that automations can subscribe to. Returns event names, descriptions, and payload schemas. Call this BEFORE defining an automation to discover available events.
 - **list**: List all automations (triggers). Shows name, event, condition, mode, status, and domain. Optional params: domain, enabled_only.
-- **define**: Create a new automation. IMPORTANT: Always confirm with the user before calling — show them a summary of what will be created. Required params: name, trigger_type, body. Optional: event, schedule, condition, mode, domain.
-- **update**: Update an existing automation's settings (enabled, condition, body, etc.). Required param: name. Optional: enabled, condition, body.
+- **define**: Create a new automation. IMPORTANT: Always confirm with the user before calling — show them a summary of what will be created. Required params: name, trigger_type, body. Optional: event, schedule, condition, mode, domain, delegated_policy_id.
+- **update**: Update an existing automation's settings (enabled, condition, body, delegated_policy_id, etc.). Required param: name.
 - **delete**: Delete an automation. Always confirm with the user first. Required param: name.
 - **fire-test**: Fire a test event to validate automations. Emits a test.event.fired event. Optional param: data (JSON string).`,
                 parameters: {
@@ -217,6 +221,10 @@ export function createAutomationToolEntries(getCurrentUser) {
                             type: "string",
                             description: "Domain tag for grouping (mail, calendar, clips, etc.). Used by define and list.",
                         },
+                        delegated_policy_id: {
+                            type: "string",
+                            description: "Optional app-owned stored policy id. It is passed by the trusted trigger runtime, never as action input. Only use an id documented by the app.",
+                        },
                         body: {
                             type: "string",
                             description: "The natural-language instructions for what to do when the automation fires. This becomes the agent's prompt in agentic mode. Used by define and update.",