@agent-native/core 0.214.0 → 0.217.0

package/dist/usage/actions/get-usage-metrics.js

@@ -1,6 +1,7 @@
 import { z } from "zod";
-import { defineAction } from "../../action.js";
-import { ALL_USAGE_APPS, listAppUsageMetrics, USAGE_APP_FILTER_ALL, USAGE_APP_FILTER_CURRENT, } from "../metrics-store.js";
+import { defineAction, fail } from "../../action.js";
+import { isOrgMember } from "../../org/membership.js";
+import { ALL_USAGE_APPS, canViewWorkspaceUsage, listAppUsageMetrics, USAGE_APP_FILTER_ALL, USAGE_APP_FILTER_CURRENT, } from "../metrics-store.js";
 import { resolveUsageAppKey } from "../store.js";
 function resolveAppSelection(app, appId) {
     if (appId !== undefined) {
@@ -16,12 +17,17 @@ function resolveAppSelection(app, appId) {
     return app;
 }
 export default defineAction({
-    description: 'Get LLM usage metrics for Settings › Usage: lookback totals, the daily trend split by feature, app, model and surface (dailyBy), top features, models, apps, chats and people, tool calls per day, recent prompts, and the apps with usage. Covers every app unless app names one. Members see only their own usage; scope "workspace" (everyone in the organization) is for owners and admins. billing.unit identifies Builder.io credits, estimated dollars, mixed billing, or unknown when historical engine metadata is missing.',
+    description: "Reports this workspace's own agent/LLM usage (Settings › Usage) for members of this organization only; it does NOT cover usage, credits, or activity of external customers, accounts, companies, or product usage, use this app's own customer or billing actions for those, or the app that owns that data (see <relevant-apps>, or search with describe-workspace-apps). Returns lookback totals, the daily trend (dailyBy feature, app, model and surface), top features, models, apps, chats and people, tool calls per day, and recent prompts, across every app unless app names one. Members see only their own usage; scope \"workspace\" (everyone in the organization) is for owners and admins. billing.unit identifies Builder.io credits, estimated dollars, mixed billing, or unknown.",
     http: { method: "GET" },
     schema: z.object({
         sinceDays: z.coerce.number().int().min(1).max(365).default(30),
         scope: z.enum(["me", "workspace"]).default("me"),
-        userEmail: z.string().trim().min(1).optional(),
+        userEmail: z
+            .string()
+            .trim()
+            .min(1)
+            .optional()
+            .describe("Email of a member of this organization to filter usage to. Not for customers or other external accounts."),
         app: z
             .string()
             .trim()
@@ -39,6 +45,23 @@ export default defineAction({
     run: async ({ sinceDays, scope, userEmail, app, appId }, ctx) => {
         if (!ctx?.userEmail)
             throw new Error("Not authenticated.");
+        // scope "me" ignores userEmail, so only a workspace lookup is checked.
+        if (scope === "workspace" &&
+            userEmail &&
+            ctx.orgId &&
+            userEmail.toLowerCase() !== ctx.userEmail.toLowerCase()) {
+            // Unauthorized callers get one answer whether or not the email is a
+            // member, so the lookup cannot be used to probe the roster.
+            if (!(await canViewWorkspaceUsage({
+                ownerEmail: ctx.userEmail,
+                orgId: ctx.orgId,
+            }))) {
+                fail(`get-usage-metrics cannot answer this. For a teammate in this organization, only owners and admins can look up their usage. For a customer or other external user, get-usage-metrics has no data: use this app's own customer or billing actions if it has any, or find the app that owns that data with describe-workspace-apps query="<what you need>" and delegate with call-agent.`, { errorCode: "usage_user_lookup_forbidden", statusCode: 403 });
+            }
+            if (!(await isOrgMember(ctx.orgId, userEmail))) {
+                fail(`${userEmail} is not a member of this organization, so get-usage-metrics has no data on them. For a customer's or account's usage or credits, use this app's own customer or billing actions if it has any, or find the app that owns that data with describe-workspace-apps query="<what you need>" and delegate with call-agent.`, { errorCode: "usage_user_not_org_member", statusCode: 404 });
+            }
+        }
         const selection = resolveAppSelection(app, appId);
         return listAppUsageMetrics({ sinceDays, scope, userEmail, builderCreditsEnabled: true }, {
             ownerEmail: ctx.userEmail,

package/dist/usage/actions/manage-usage-alert.js

@@ -15,6 +15,11 @@ export default defineAction({
         channels: z.array(channel).min(1).optional(),
         enabled: z.boolean().optional(),
     }),
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: false,
+        openWorldHint: false,
+    },
     run: async ({ operation, scope, ruleId, appId, unit, period, limit, channels, enabled }, ctx) => {
         if (!ctx?.userEmail)
             throw new Error("Not authenticated.");

package/dist/vite/client.js

@@ -982,7 +982,6 @@ function getDefaultOptimizeDeps(cwd) {
             specifier: "@modelcontextprotocol/ext-apps/app-bridge",
             packageName: "@modelcontextprotocol/ext-apps",
         },
-        { specifier: "@paper-design/shaders-react" },
         { specifier: "@radix-ui/react-accordion" },
         { specifier: "@radix-ui/react-alert-dialog" },
         { specifier: "@radix-ui/react-aspect-ratio" },
@@ -3482,11 +3481,14 @@ const DEFAULT_VITE_WATCH_IGNORED_DIRS = new Set([
     "build",
 ]);
 export function defaultViteWatchIgnored(root) {
-    return (file) => path
-        .relative(root, file)
-        .split(/[\\/]/)
-        .slice(0, -1)
-        .some((segment) => DEFAULT_VITE_WATCH_IGNORED_DIRS.has(segment));
+    return (file) => {
+        const segments = path.relative(root, file).split(/[\\/]/);
+        return segments
+            .slice(0, -1)
+            .some((segment, index) => segment === ".generated" && index === 0 && segments[1] === "bridge"
+            ? false
+            : DEFAULT_VITE_WATCH_IGNORED_DIRS.has(segment));
+    };
 }
 function forceServeOnly(pluginOrPreset) {
     if (Array.isArray(pluginOrPreset))

package/dist/workspace-connections/actions/bulk-update-workspace-user-groups.js

@@ -12,6 +12,11 @@ export default defineAction({
             .describe("Workspace member email addresses to change."),
         operation: z.enum(["add", "remove"]).describe("Membership operation."),
     }),
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: false,
+    },
     run: async (args, ctx) => {
         await assertWorkspaceUserGroupManager(ctx?.orgId, ctx?.userEmail);
         return updateWorkspaceUserGroupMembers({

package/dist/workspace-connections/actions/delete-workspace-user-group.js

@@ -7,6 +7,11 @@ export default defineAction({
     schema: z.object({
         id: z.string().min(1).describe("User group ID to delete."),
     }),
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: false,
+    },
     run: async ({ id }, ctx) => {
         await assertWorkspaceUserGroupManager(ctx?.orgId, ctx?.userEmail);
         const orgId = ctx?.orgId ?? "";

package/dist/workspace-connections/actions/upsert-workspace-user-group.js

@@ -11,6 +11,11 @@ export default defineAction({
             .default([])
             .describe("Workspace member email addresses in this group."),
     }),
+    mcpAnnotations: {
+        readOnlyHint: false,
+        destructiveHint: true,
+        openWorldHint: false,
+    },
     run: async (args, ctx) => {
         await assertWorkspaceUserGroupManager(ctx?.orgId, ctx?.userEmail);
         return upsertWorkspaceUserGroup({

package/docs/content/actions-access-control.mdx

@@ -164,9 +164,9 @@ A handful of actions are too consequential to let the agent run on its own, like
 
 When `needsApproval` is omitted, behavior is byte-for-byte unchanged. There is no extra cost on the common path.
 
-This works the same way for legacy `parameters`-style actions and for schema-based actions. It also works the same way for the in-app agent, sub-agents, A2A, and MCP callers, because every agent surface routes through the same loop.
+This works the same way for legacy `parameters`-style actions and for schema-based actions. The in-app agent and sub-agents pause in the agent loop. MCP and A2A use their own approval flows.
 
-Calls over the [HTTP API](/docs/http-api) cannot give approval. When a call needs it, the route refuses with a `409` and `errorCode: "approval_required"`, whether the caller holds a bearer token, an API key, an MCP OAuth token, an org service token, or an A2A identity. A service identity can never approve. Only the app's own signed-in UI runs such a call directly, because the person using it is the one approving. A browser call proves it comes from that UI with a short-lived UI capability. A call that claims to be the app without one gets a `403` with `errorCode: "ui_capability_required"`, and the app's client mints the capability and retries once. To have an agent's calls approved, connect it over [MCP](/docs/external-agents) or have it ask in the app's agent chat.
+Direct calls to the [HTTP API](/docs/http-api) cannot provide human approval. The action route runs a gated call only for the proven app UI or the app's MCP directory widget. Other direct HTTP callers receive a `409` with `errorCode: "approval_required"`, and a service identity cannot approve. The shared client sends a short-lived UI capability with signed-in writes. A call without proof receives `403` with `errorCode: "ui_capability_required"`, then the client mints the capability and retries once. A2A tasks use their own approval flow, not this HTTP response. The task pauses until its owner approves, then replays the approved tool call. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat this field as an approval flow, not an authorization boundary.
 
 ### How the loop pauses {#loop}
 
@@ -403,12 +403,12 @@ A create action calls neither helper. It only needs to stamp `ownerEmail` (and `
 
 The four mechanisms are not interchangeable:
 
-| Mechanism                         | Question it answers                                   | Applies to                       |
-| --------------------------------- | ----------------------------------------------------- | -------------------------------- |
-| `access`                          | Does the caller hold the declared role or membership? | All six dispatch sites           |
-| `authorize`                       | May this caller perform the operation at all?         | All six dispatch sites           |
-| `needsApproval`                   | Should a human approve this specific permitted call?  | Every surface                    |
-| `accessFilter()`/`assertAccess()` | Which rows may this permitted caller see or write?    | Inside `run()`, per query or row |
+| Mechanism                         | Question it answers                                   | Applies to                                                      |
+| --------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------- |
+| `access`                          | Does the caller hold the declared role or membership? | All six dispatch sites                                          |
+| `authorize`                       | May this caller perform the operation at all?         | All six dispatch sites                                          |
+| `needsApproval`                   | Should a human approve this specific permitted call?  | Agent, MCP, A2A. HTTP gates unproven calls. Local CLI bypasses. |
+| `accessFilter()`/`assertAccess()` | Which rows may this permitted caller see or write?    | Inside `run()`, per query or row                                |
 
 A restricted write action typically needs both `authorize` and a row check. The first keeps non-coaches out of the operation. The second keeps a coach out of another org's plan. The row check is `assertAccess()`, or `access` when the row's id is an input field. `needsApproval` is a separate axis. It never restricts who may call, only whether the agent may proceed unattended.
 

package/docs/content/actions-defining.mdx

@@ -385,14 +385,15 @@ A network drop, a proxy's HTML error page, and a bare status line author no mess
 
 ### What each throw produces {#failure-shapes}
 
-| Thrown from `run()`                             | HTTP status       | Response body                                | Reported to error tracking |
-| ----------------------------------------------- | ----------------- | -------------------------------------------- | -------------------------- |
-| `fail(msg)`                                     | 400               | `{ error: msg, errorCode: "action_failed" }` | No                         |
-| `fail(msg, { errorCode, statusCode, details })` | your `statusCode` | `{ error, errorCode, details }`              | No                         |
-| `new ActionContractError(msg, { errorCode })`   | 409               | `{ error, errorCode, details }`              | No                         |
-| `new AgentActionStopError(msg)`                 | 500               | `{ error: msg }`                             | No                         |
-| `new Error(msg)`                                | 500               | `{ error: "Internal server error" }`         | Yes                        |
-| Input that fails `schema`                       | 400               | `{ error: "Invalid action parameters..." }`  | No                         |
+| Thrown from `run()`                                                | HTTP status       | Response body                                  | Reported to error tracking |
+| ------------------------------------------------------------------ | ----------------- | ---------------------------------------------- | -------------------------- |
+| `fail(msg)`                                                        | 400               | `{ error: msg, errorCode: "action_failed" }`   | No                         |
+| `fail(msg, { errorCode, statusCode, details })`                    | your `statusCode` | `{ error, errorCode, details }`                | No                         |
+| `new ActionContractError(msg, { errorCode })`                      | 409               | `{ error, errorCode, details }`                | No                         |
+| `new AgentActionStopError(msg)`                                    | 500               | `{ error: msg }`                               | No                         |
+| A PostgreSQL deadlock (`40P01`) or serialization failure (`40001`) | 409               | `{ error, errorCode: "transaction_conflict" }` | No                         |
+| `new Error(msg)`                                                   | 500               | `{ error: "Internal server error" }`           | Yes                        |
+| Input that fails `schema`                                          | 400               | `{ error: "Invalid action parameters..." }`    | No                         |
 
 `AgentActionStopError` is the one to throw when the agent should end its turn rather than read the failure and try again. `ActionContractError` is what `fail()` raises for you, so reach for it directly only when 409 is the status you want.
 

package/docs/content/deployment-environment-variables.mdx

@@ -20,7 +20,7 @@ hosting behavior.
 | `APP_URL`                                   | Optional canonical public origin. Checked ahead of `BETTER_AUTH_URL` when resolving the A2A JWT audience, the OAuth public origin, self-dispatch webhook targets, and generated resource links. Set it explicitly on preview/staging deploys where the request host is unreliable.                                                                                      |
 | `AGENT_PROD_CODE_EXECUTION`                 | Optional production code-execution mode: `off` (default), `sandboxed`, or `trusted`. See [Production Code Execution](/docs/actions-agent-tools#production-code-execution).                                                                                                                                                                                              |
 | `AGENT_NATIVE_SSR_CACHE`                    | Deployment-wide SSR shell cache policy: unset/`on` keeps the default hard-cache, `off` sends `no-store`, or a duration such as `30s` / `5m` sets a shorter freshness. See [SSR Caching](/docs/ssr-caching).                                                                                                                                                             |
-| `AGENT_NATIVE_HEAD_SCRIPT_SRC`              | Optional HTTPS URL of a script loaded with `defer` in the `<head>` of every server-rendered page. Use it for deployment-specific tooling such as an internal feedback widget, without changing app source. Non-HTTPS URLs fail config validation.                                                                                                                       |
+| `AGENT_NATIVE_HEAD_SCRIPT_SRC`              | Optional HTTPS URL of a script added to the `<head>` of every server-rendered page. Where the consent banner shows, it waits for analytics consent, like Google Analytics. Use it for deployment-specific tooling such as an internal feedback widget, without changing app source. Non-HTTPS URLs fail config validation.                                              |
 | `AGENT_NATIVE_ENABLE_KEEP_WARM`             | Opt into the Netlify keep-warm scheduled function. Unset by default. See [Keep-warm](/docs/netlify#netlify-keep-warm).                                                                                                                                                                                                                                                  |
 | `AGENT_NATIVE_DISABLE_KEEP_WARM`            | Compatibility kill switch for the Netlify keep-warm scheduled function. See [Keep-warm](/docs/netlify#netlify-keep-warm).                                                                                                                                                                                                                                               |
 | `AGENT_NATIVE_KEEP_WARM_SCHEDULE`           | Override the keep-warm cadence with a 5-field cron expression (default `* * * * *` when enabled). An unparseable value fails the build. See [Keep-warm](/docs/netlify#netlify-keep-warm).                                                                                                                                                                               |

package/docs/content/environment-variables.mdx

@@ -95,7 +95,7 @@ public app behavior, use the config paths above instead.
 | `ACCESS_TOKEN` / `ACCESS_TOKENS`               | Static bearer fallback for MCP and Connect clients.                                                                                                                            | One token or a delimited token list; these are not browser auth.                                                        |
 | `AGENT_PROD_CODE_EXECUTION`                    | Production code-execution policy.                                                                                                                                              | `off`, `sandboxed`, or `trusted`. See [Production Code Execution](/docs/actions-agent-tools#production-code-execution). |
 | `AGENT_NATIVE_SSR_CACHE`                       | Deployment-wide public SSR shell cache policy.                                                                                                                                 | Unset/`on`, `off`, or a duration such as `30s` or `5m`. See [SSR Caching](/docs/ssr-caching).                           |
-| `AGENT_NATIVE_HEAD_SCRIPT_SRC`                 | Extra script injected into every server-rendered page head with `defer`.                                                                                                       | An absolute `https://` URL; non-HTTPS values fail config validation.                                                    |
+| `AGENT_NATIVE_HEAD_SCRIPT_SRC`                 | Extra script added to every server-rendered page head. Where the consent banner shows, it waits for analytics consent, like Google Analytics.                                  | An absolute `https://` URL; non-HTTPS values fail config validation.                                                    |
 | `AGENT_NATIVE_ENABLE_KEEP_WARM`                | Opts into the Netlify keep-warm scheduled function; unset by default.                                                                                                          | `1`; see [Keep-warm](/docs/netlify#netlify-keep-warm).                                                                  |
 | `AGENT_NATIVE_DISABLE_KEEP_WARM`               | Compatibility kill switch for the Netlify keep-warm scheduled function.                                                                                                        | `1`; see [Keep-warm](/docs/netlify#netlify-keep-warm).                                                                  |
 | `AGENT_NATIVE_KEEP_WARM_SCHEDULE`              | Keep-warm cadence override when enabled.                                                                                                                                       | A 5-field cron expression such as `*/5 * * * *`; an unparseable value fails the build.                                  |

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

@@ -134,15 +134,15 @@ Every design-specific operation is a TypeScript file in
 
 ### Motion and shaders
 
-| Action                   | What it does                                |
-| ------------------------ | ------------------------------------------- |
-| `get-motion-timeline`    | Read an element's motion timeline           |
-| `apply-motion-edit`      | Add or edit a keyframe on a motion timeline |
-| `remove-motion-timeline` | Remove a motion timeline                    |
-| `apply-shader`           | Apply a shader effect                       |
-| `apply-shader-fill`      | Apply a shader as a fill                    |
-| `preview-shader-fill`    | Preview a shader fill before applying it    |
-| `get-shader`             | Read a shader's current parameters          |
+| Action                   | What it does                                          |
+| ------------------------ | ----------------------------------------------------- |
+| `get-motion-timeline`    | Read an element's motion timeline                     |
+| `apply-motion-edit`      | Add or edit a keyframe on a motion timeline           |
+| `remove-motion-timeline` | Remove a motion timeline                              |
+| `get-shader`             | Inspect native definitions and saved effect manifests |
+| `edit-native-shader`     | Apply, edit, approve, or remove native effects        |
+
+Native WebGPU effects use WGSL. Custom authoring uses `edit-native-shader` with `define-definition`, `get-shader` to read the saved `executionHash`, `approve-definition` with that `expectedExecutionHash`, then `apply` with the exact definition ID/version. Each edit requires `designId`, `fileId`, and the current `expectedVersionHash`. Re-read the file hash after each write. CPU schema validation does not compile GPU code, so verify the Design preview. Previously saved GLSL effects remain renderable and removable.
 
 ### Quality {#quality}
 

package/docs/content/template-design-features.mdx

@@ -175,9 +175,7 @@ when they apply to the current selection:
 
 - **Fill** and **Stroke**: color, gradient, or image paint, with a
   document color palette to reuse existing colors.
-- **Effects**: drop shadow, layer blur, background blur, and a
-  code-backed shader effect with named sliders (speed, color, center
-  point) and a Code panel for the raw GLSL.
+- **Effects**: Drop shadow, layer blur, background blur, and native WebGPU effects with editable properties. Shader creation opens the agent chat to author native WGSL. Previously saved GLSL effects remain renderable and removable.
 - **Position & layout**, **Typography**, **Appearance** (corner radius,
   blend mode, visibility): the standard per-element property groups.
 - **Layout** and **Auto layout**: flex-style arrangement for a frame's

package/docs/content/turn-into-app.mdx

@@ -43,6 +43,10 @@ A host counts as local when it has a real working directory, a terminal, and a w
 
 On a browser host the skill requires the Agent-Native Dispatch MCP connector (`https://dispatch.agent-native.com/mcp`, OAuth) and calls its `start-workspace-app-creation` action. The host cannot run or inspect the app, so the report stays pending or unverified until the branch Dispatch returns is built. The skill reports what Dispatch actually returned and never invents a branch URL. For a ChatGPT Project, or any host that only exposes MCP, put the skill instructions in the Project instructions or knowledge files.
 
+## Local prerequisites
+
+On a local host, install Node.js 22.22.0 or newer (which includes npm and npx) and pnpm before starting. Browser hosts use Dispatch and do not run these commands.
+
 ## Sources {#sources}
 
 - **Threads.** The last concrete, repeatable job is the product.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.214.0",
+  "version": "0.217.0",
   "description": "The agentic application framework for building autonomous agents with intuitive UIs",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -527,6 +527,7 @@
     "./client/changelog/use-changelog-seen": "./dist/client/changelog/use-changelog-seen.js",
     "./client/chat-model-groups": "./dist/client/chat-model-groups.js",
     "./client/client-status-requests": "./dist/client/client-status-requests.js",
+    "./client/consent": "./dist/client/consent.js",
     "./client/context-xray/format": "./dist/client/context-xray/format.js",
     "./client/dev-overlay/builtins": "./dist/client/dev-overlay/builtins.js",
     "./client/error-reporting": "./dist/client/error-reporting.js",
@@ -551,6 +552,7 @@
     "./client/onboarding/first-run-registry": "./dist/client/onboarding/first-run-registry.js",
     "./client/onboarding/first-run-status": "./dist/client/onboarding/first-run-status.js",
     "./client/onboarding/use-onboarding": "./dist/client/onboarding/use-onboarding.js",
+    "./client/onboarding/use-onboarding-checklist": "./dist/client/onboarding/use-onboarding-checklist.js",
     "./client/onboarding/use-preview-mode": "./dist/client/onboarding/use-preview-mode.js",
     "./client/org/hooks": "./dist/client/org/hooks.js",
     "./client/resources/mcp-connection-resume": "./dist/client/resources/mcp-connection-resume.js",
@@ -600,6 +602,7 @@
     "./notifications/types": "./dist/notifications/types.js",
     "./observability/types": "./dist/observability/types.js",
     "./onboarding/types": "./dist/onboarding/types.js",
+    "./onboarding/status": "./dist/onboarding/status.js",
     "./onboarding/workspace-services": "./dist/onboarding/workspace-services.js",
     "./onboarding/app-profile-data": "./dist/onboarding/app-profile-data.js",
     "./org/app-roles": "./dist/org/app-roles.js",
@@ -727,8 +730,8 @@
     "yaml": "^2.9.0",
     "yjs": "^13.6.33",
     "zod": "^4.3.6",
-    "@agent-native/agentkit": "^0.214.0",
-    "@agent-native/recap-cli": "^0.5.83"
+    "@agent-native/agentkit": "^0.217.0",
+    "@agent-native/recap-cli": "^0.5.86"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.71",

package/src/templates/chat/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/src/templates/default/.agents/skills/actions/references/action-fields.md

@@ -140,6 +140,6 @@ export default defineAction({
 
 When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". It receives its own copy of the prepared snapshot of the validated arguments, defaults applied, and the approval binds to the snapshot's hash, so an approved call runs only with the arguments that were approved (a Date binds by its time). The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run.
 
-Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other HTTP caller (bearer or API key, MCP OAuth token, org service token, A2A, extension iframe, mobile app) gets `409 approval_required`, and a service identity can never approve. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. Every surface evaluates the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. A caller that must run unattended needs a different action, never a bypass of the gate.
+Approval is given in the app, so HTTP never grants it. The HTTP action route and the generated Workers entry run a gated call only for the proven app UI (a frontend call from the signed-in user, same origin, holding the short-lived UI capability; `isProvenUiRequest`, the proof `uiOnly` uses) or the app's MCP directory widget. Every other direct HTTP caller (bearer or API key, MCP OAuth token, org service token, extension iframe, or mobile app) gets `409 approval_required`, and a service identity can never approve. A2A tasks use their separate approval flow. The task pauses until its owner approves, then replays the approved tool call under its approval lease. The shared client presents the capability with every write from a signed-in session (minted once per user, reused for nine minutes, never for reads or public pages), so a gated button works on its first request. A call without proof gets `403 ui_capability_required`; the client then re-mints and retries once, which is only the fallback for an expired or rejected capability. The agent loop, plan mode registry, HTTP action route, generated Workers entry, and MCP dispatch evaluate the gate through `preparedCallNeedsApproval`, so a throwing predicate asks there too. The local `pnpm action ...` CLI calls `handler.run()` directly and does not evaluate `needsApproval`. Treat it as a local development tool, not an approval boundary. A caller that must run unattended needs a different action, never a bypass of the gate.
 
 **Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc.

package/src/templates/factory/.agents/skills/review-latest-feedback/SKILL.md

@@ -21,25 +21,15 @@ Four phases, in order. Phase 0 comes before any investigation, not after.
 2. **Fix** what the evidence actually proves, at the owning boundary.
 3. **Reply** with useful questions, then recap.
 
-Output is fixes. For every unheld in-scope report root this task owns, keep one concise, current same-actor status reply after the latest human message. It names every verified `✅` scope and its evidence, every open scope, and each `🎫` action and owner (or why a mark does not apply). Add and read back root `✅` as soon as direct post-change proof verifies a scope, and root `🎫` as soon as another person or team must act. An `👀` alone never completes the status. Preserve all reaction history, and follow [`slack-reaction-replies.md`](references/slack-reaction-replies.md). Do not reply on held, person-assigned, or `:mag:` items.
-
-### Read the root marks as history; use the reply for current status
-
-- `👀` records this workflow's claim. It does not mean the report is still open.
-- `✅` records a scope that passed direct post-change proof. Add it as soon as
-  any scope passes, even when another scope remains open; name the verified
-  scope and evidence in the status reply.
-- `🎫` records a distinct action another person must take, including a reporter
-  request. Keep the reaction as history after that action is completed,
-  answered, or abandoned; the current reply must say whether the action is
-  still open or historical.
-- Every owned root needs one current same-actor reply after the latest human
-  reply. Reuse it while the disposition and evidence remain current; do not
-  send a duplicate progress reply on every sweep. The reply names verified
-  scopes, open scopes, human actions and owners, and why either `✅` or `🎫` is
-  absent. An eye-only root is correct when no scope is verified and no separate
-  human action is pending; say whether the next step is this workflow's
-  investigation or no further action.
+Output is fixes. For every unheld in-scope report root this task owns, keep one
+current same-actor status reply after the latest human message. Write one short
+sentence in plain, non-technical language. Say what changed. Use `🎫` only for
+unresolved work; when you use it, briefly say what still needs investigation or
+what action is needed, and name its owner when known. Do not mention or explain
+absent reactions. Keep scope details and proof in the internal ledger. Add and
+read back root reactions as soon as their proof bar passes, preserve reaction
+history, and follow [`slack-reaction-replies.md`](references/slack-reaction-replies.md).
+Do not reply on held, person-assigned, or `:mag:` items.
 
 ## Slack channels and ownership
 
@@ -133,11 +123,13 @@ source window, the three matching owned-mark searches, and older roots linked
 by in-window replies. For every unheld owned root, compare the latest human
 message, current status reply, verified scopes, open scopes, and root marks.
 Add and read back `✅` for each newly verified scope and `🎫` for each distinct
-pending human action; the status reply must follow the latest human message and
-name current evidence, remaining work, and owners. An `👀` with a verified
-scope missing `✅`, a pending human action missing `🎫`, or no current status is
-unfinished. Finish the complete bounded set once, then stop; do not chase
-unrelated historical marks.
+pending human action; keep evidence, scopes, and full actions/owners in the
+internal ledger. The status reply must follow the latest human message and use
+the concise reply rule above: say what changed, and when `🎫` applies, briefly
+name the unresolved action and its owner when known. A verified scope missing
+`✅`, a pending human action missing `🎫`, or no current status is unfinished.
+Finish the complete bounded set once, then stop; do not chase unrelated
+historical marks.
 
 Split reports into distinct scopes. Add root `✅` as soon as any named scope
 passes direct post-change proof, even while its PR is open; say **Verified
@@ -146,9 +138,10 @@ proof. Add root `🎫` for each distinct unfinished action another human must ta
 including a requested reporter URL, access grant, evidence, or clarification.
 The mark tracks an outstanding human action, not an accepted team handoff.
 Record reporter requests in `reporterRequests[]`, separately from
-team/engineering `handoffs[]`. Enumerate each verified scope, open scope,
-reporter request, and handoff in the status reply; explain any absent mark. Keep
-marks after completion and never remove them. For a closed reporter request,
+team/engineering `handoffs[]`. Keep verified scopes, open scopes, reporter
+requests, and handoffs in the internal ledger; keep the Slack reply focused on
+the current outcome and any `🎫` follow-up. Keep marks after completion and
+never remove them. For a closed reporter request,
 preserve its request and closure evidence in the historical ticket record; see
 [`slack-reaction-replies.md`](references/slack-reaction-replies.md).
 
@@ -382,29 +375,22 @@ instruction or prompt exception.
 Thank issue reporters for opening issues and Slack reporters for sharing.
 Before posting, inspect the full thread and follow the one-reply gate in
 `address-feedback-with-replies` and the [Slack reply reference](references/slack-reaction-replies.md):
-send one concise disposition covering done, remaining, and next action/owner.
-Do not reply again to announce merge, publication, or live beta; answer direct
-reporter follow-ups. End Slack replies with `this was sent from a bot.`.
-
-Reporter-facing replies are one or two sentences: the change or question, its limit, and the next step. Do not explain workflow mechanics, ledgers, or external tracker tickets. Never send **Open**/**pending** or a symptom recap. Ask for reporter input only when it changes the next step; never request supplied evidence or internal access. Keep hashes, branches, CI, publisher, and run details in the recap.
-
-Every root this actor marks with `👀`, `✅`, or `🎫` also needs the current
-same-actor status reply required by the Slack reaction reference. One concise
-reply may serve both purposes when it answers the reporter and records the
-current disposition, verified/open scopes, owner/action, and any reason a mark
-is absent. This status requirement takes precedence over the reporter-facing
-brevity rule only for those facts; do not explain ledger mechanics or external
-tracker tickets. A Slack `🎫` reaction tracks a distinct human action, not an
-external ticket, and remains as history after the action closes. Never imply
-that an external ticket was created or assigned.
-
-Keep publisher and beta checks in the internal recap after the disposition;
-they do not trigger a second reporter reply.
-
-### After a PR merges
-
-Track publisher state and beta verification in the internal recap. Do not send
-a routine post-merge reporter reply; answer only a direct reporter follow-up.
+send one short sentence in plain, non-technical language, then end with the
+exact bot disclosure `this was sent from a bot.` Say what changed. Use `🎫`
+only for unresolved work; when it is used, briefly say what still needs
+investigation or action and name its owner when known. Do not explain absent
+reactions or mention a closed, historical `🎫`. Keep hashes, branches, CI,
+publisher details, and proof in the internal recap. Never explain workflow
+mechanics or external tracker tickets in Slack. Never send **Open**/**pending**
+or a symptom recap. Ask for reporter input only when it changes the next step.
+
+Every root this actor marks with `👀`, `✅`, or `🎫` also needs a current
+same-actor status reply after the latest human reply. One concise reply can
+answer the reporter and record the disposition. Keep verified scopes, open
+scopes, reaction history, and evidence in the internal ledger; do not enumerate
+them or explain absent reactions in Slack. A Slack `🎫` reaction tracks a
+distinct human action, not an external ticket, and remains as history after the
+action closes. Never imply that an external ticket was created or assigned.
 
 For a fixed behavior with a Slack `🎫` handoff, state the done behavior and
 remaining action/owner separately; don't imply the fixed scope is open. The
@@ -453,36 +439,6 @@ otherwise draft the reply, leave the feedback unresolved, and link it in the
 recap. This exception is only for PR review feedback, not proactive PR comments
 or issue comments.
 
-## Publishing
-
-Use this worktree's branch. Batch fixes with one
-`corepack pnpm ship:push -m "<specific fix>"`; each head reruns CI. Sync
-`origin/main` only for GitHub conflicts during review-only work. If the same
-task is already running an explicitly authorized `/ship`, follow that skill's
-safe-sync rule for a confirmed required-check fix on `origin/main`; do not ask
-for another approval. Behind/pending alone never justify syncing.
-
-Use `/ship` for PR ownership, push, and merge checks. Never push to another
-person's PR without explicit authorization for that exact PR in this request.
-Push-only authorization means `ship_mode=ready-only`; merging requires separate
-authorization for that PR. Without push authorization, hand off as pending.
-Carry feedback evidence and dispositions into PRs; reference only issues the
-PR fixes.
-Keep source-tested, built, deployed, and observed-live claims separate.
-
-Carry exact tracker row ids and the reproduction ledger into the PR or release
-recap; tracker status is not shipping evidence. Mark each row independently: a
-reaction, checkmark, or "reviewed" cannot cover multiple rows, including
-expected, docs-owned, cross-team, or duplicate items. Link each source/docs
-change to its exact PR or commit, and each non-coding disposition to its
-evidence or owner.
-
-If no fix is verified, recap why shipping did not start. Unavailable connectors
-and external failures are not shipping blockers.
-While waiting, **Clarification needed** stays open with `👀` and no `✅`; it
-must not block independent fixes unless it could affect a PR change. Later runs
-skip the eye under the ownership gate.
-
 ## Recap
 
 Every eligible item gets a row. Report gated skips by count only, without