@agent-native/core 0.122.4 → 0.123.0

package/corpus/core/src/templates/workspace-core/AGENTS.md

@@ -4,140 +4,78 @@ These instructions apply to every app in the {{APP_TITLE}} workspace. Keep
 only rules that should be shared across all apps here. App-specific behavior
 belongs in that app's own `AGENTS.md` or `.agents/skills/` directory.
 
-## Framework Docs Lookup
-
-Version-matched Agent Native docs ship with `@agent-native/core` in
-`node_modules/@agent-native/core/docs`. A source-only corpus of core and
-first-party template patterns ships in `node_modules/@agent-native/core/corpus`.
-
-- From an app directory, use `pnpm action docs-search --query "<topic>"`,
-  `pnpm action docs-search --slug <slug>`, or `pnpm action docs-search --list`.
-  Use `pnpm action source-search --query "<pattern>"` or
-  `pnpm action source-search --path <path>` when source examples matter.
-- If the action runner is unavailable, read
-  `node_modules/@agent-native/core/docs/AGENTS.md` and search
-  `node_modules/@agent-native/core/docs/content/` directly with `rg`. Search
-  `node_modules/@agent-native/core/corpus/` for source examples.
-- For advanced workspace features, start with `workspace`, `multi-app-workspace`,
-  `a2a-protocol`, `pure-agent-apps`, `automations`, `recurring-jobs`,
-  `external-agents`, `mcp-protocol`, `feature-flags`, `sharing`, and `security`.
-
-Use package docs for framework APIs, the package corpus for reusable
-framework/template patterns, and this `AGENTS.md` plus `.agents/skills/` for
-workspace-specific conventions.
-Before building common workspace or agent UI, read `agent-native-toolkit` to
-inventory existing public kits and installed package seams. Read
-`customizing-agent-native` before adapting shared UI. Use the supported
-ladder: configure → compose → eject the smallest unit → propose a shared seam.
-Preview before `--apply`, commit `agent-native.ejections.json`, and never edit
-`node_modules` or eject protected runtime contracts.
+## Skills
+
+Read the matching skill in `.agents/skills/` before working in that area.
+
+| Skill | Read before |
+| --- | --- |
+| `workspace-conventions` | Shared vs app-owned code, file/blob storage, env and secrets, scratch files, Dispatch Resources |
+| `adding-workspace-apps` | Creating, scaffolding, mounting, or branding an app under `apps/<app-name>` |
+| `agent-native-docs` | Looking up version-matched framework docs, slugs, or the bundled source corpus |
+| `agent-native-toolkit` | Building workspace or agent UI, app chrome, settings, sharing, or collaboration |
+| `customizing-agent-native` | Adapting, overriding, or ejecting shared framework UI |
+| `delegate-to-agent` | Building agent-driven UI or any "AI" feature |
+| `actions` | Adding or changing an app operation the agent and UI share |
+| `composable-mini-apps` | Cross-app workflows, headless mini-apps, and A2A handoffs |
+| `shadcn-ui` | Adding, updating, or debugging a shadcn/ui primitive |
+| `security`, `sharing` | Access scoping, ownable data, and sharing user-authored resources |
+| `automations` | Event-triggered or scheduled background work (with `recurring-jobs`) |
 
 ## Shared Context
 
 Add company, product, compliance, or support-context notes that every app
 agent should know.
 
-## Shared Conventions
-
-- All AI/LLM behavior goes through the app's agent chat. UI and server code
-  must not call model providers, AI SDK `generateText()` / `streamText()`, or
-  other inline LLM APIs directly. Use `sendToAgentChat()` for local app-agent
-  work, including hidden `context` and `submit: false` prefill/review flows.
-  Only use `useAgentChatContext`, `setAgentChatContextItem`,
-  `listAgentChatContext`, `removeAgentChatContextItem`, and
-  `clearAgentChatContext` when UI needs two-way sync with staged context chips.
-  Read `.agents/skills/delegate-to-agent/SKILL.md` before building agent-driven
-  UI or "AI" features.
-- Put shared code in `packages/shared` only when multiple apps need it.
-- Keep app-specific screens, actions, state, and skills inside `apps/<app>`.
-- SQL is for structured records, metadata, references, and searchable text. Store
-  large files/blob payloads (base64, `data:` URLs, images, video/audio, PDFs,
-  ZIPs, screenshots, thumbnails, session replay chunks) in configured file/blob
-  storage and persist only URLs, ids, or handles.
-- Store shared runtime configuration in the workspace root `.env`; use
-  `apps/<app>/.env` only for app-specific overrides. Never hardcode API keys,
-  tokens, webhook URLs, signing secrets, private Builder/internal data, customer
-  data, or credential-looking literals in source, docs, prompts, fixtures,
-  application state, action responses, or generated app content. Use
-  secrets/OAuth/runtime configuration and obvious placeholders in examples.
+## Core Rules
+
+- All AI/LLM behavior goes through the app's agent chat. UI and server code must
+  not call model providers or AI SDK `generateText()` / `streamText()` directly;
+  use `sendToAgentChat()`. Read `.agents/skills/delegate-to-agent/SKILL.md`
+  before building agent-driven UI or "AI" features.
+- Normal app data must flow through actions. Define `defineAction` files in
+  `actions/`, mark reads with `http: { method: "GET" }`, and call them from React
+  with `useActionQuery` / `useActionMutation`. Do not add `/api/*` routes that
+  duplicate, wrap, proxy, or re-export an action.
+- Keep app-specific screens, actions, state, and skills inside `apps/<app>`. Put
+  shared code in `packages/shared` only when multiple apps need it.
+- App database code must be provider-agnostic: `@agent-native/core/db/schema`
+  helpers plus Drizzle's query builder. Never import `drizzle-orm/sqlite-core`
+  or `drizzle-orm/pg-core` from an app.
+- SQL is for structured records, metadata, references, and searchable text.
+  Large files and blob payloads belong in configured file/blob storage; persist
+  only URLs, ids, or handles.
+- Never hardcode API keys, tokens, webhook URLs, signing secrets, private
+  Builder/internal data, customer data, or credential-looking literals anywhere,
+  including application state, action responses, and generated app content. Use
+  secrets/OAuth/runtime configuration and obvious placeholders.
+- Never hardcode `localhost`, `127.0.0.1`, or a dev port. Use relative workspace
+  links like `/<app-name>`; the workspace gateway origin owns the port.
+- Do not implement a new app by adding routes, pages, or files to `apps/chat` or
+  another existing app unless the user explicitly asks to modify that app. Read
+  `adding-workspace-apps` first.
 - Prefer framework defaults until the workspace has a real custom rule,
   component, plugin, action, or skill to share.
-- Keep the Workspace files view for user-authored or user-requested resources.
-  Agents may create hidden `agent_scratch` resources for temporary working
-  notes, scripts, task plans, or intermediate outputs, but should promote them
-  to normal workspace visibility only when the user explicitly asks to keep or
-  manage the file.
-- Runtime-editable global resources can be managed from Dispatch Resources.
-  Use `AGENTS.md` or `instructions/<slug>.md` for always-on guardrails,
-  `skills/<slug>/SKILL.md` for workspace skills, `context/<slug>.md` for
-  personas/positioning/messaging/company facts/brand guidelines, and
-  `agents/<slug>.md` for custom agent profiles. Scope them to All apps when
-  every workspace app should inherit them. All-app resources are inherited at
-  runtime; do not copy or sync them into individual apps.
+- Before building common workspace or agent UI, read `agent-native-toolkit` to
+  inventory existing public kits and installed package seams. Read
+  `customizing-agent-native` before adapting shared UI: configure → compose →
+  eject the smallest unit → propose a shared seam. Never edit `node_modules`.
 
-## Adding Apps
+## Framework Docs
 
-When a user asks from Dispatch chat or through `@agent-native` in Slack or
-Telegram to create, build, make, scaffold, or generate an "agent", classify
-the ask first.
-Simple Dispatch-native behavior such as a reminder, digest, monitor, routing
-rule, saved instruction, or recurring workflow can stay in Dispatch as a
-recurring job/resource/destination. Robust unique products or teammates that
-need their own UI, data model, actions, integrations, or domain workflow should
-become a separate workspace app under `apps/<app-name>`, mounted at
-`/<app-name>`.
+Version-matched Agent Native docs and a source-only corpus of core and
+first-party template patterns ship with `@agent-native/core`. From an app
+directory, use `pnpm action docs-search --query "<topic>"` and
+`pnpm action source-search --query "<pattern>"`. Read `workspace-conventions`
+for slugs, the `--list` / `--slug` / `--path` options, and the `rg` fallback.
 
-Do not implement a new app by adding a route, page, component, or file to
-`apps/chat` or another existing app unless the user explicitly asks to modify
-that existing app.
-
-Dispatch vault access is workspace-wide by default: every saved vault key is
-available to every workspace app. Only create or request per-app vault grants
-when Dispatch's vault access setting is switched to manual mode.
-
-Workspace apps are discovered from `apps/<app-name>/package.json`. There is no
-separate workspace app registry to edit for Dispatch to list the app. Always
-save a concise, human-readable `description` there; Dispatch lists and A2A
-connected-agent context use the app name plus description so agents know what
-the app does. Use relative workspace links like `/<app-name>` and never
-hardcode `localhost`, `127.0.0.1`, `8080`, `8100`, or any dev port in app
-cards, instructions, redirects, or navigation; the active workspace
-gateway/browser origin owns the port. React Router apps must preserve
-`APP_BASE_PATH` / `VITE_APP_BASE_PATH` in
-`app/entry.client.tsx` via `appBasePath()` so the app hydrates correctly when
-mounted at `/<app-name>`. Use the framework/template UI stack for standard UI:
-shadcn/ui components and `@tabler/icons-react`. Do not add `lucide-react` or
-another icon library. Read `.agents/skills/shadcn-ui/SKILL.md` before adding,
-updating, or debugging shadcn components.
-
-Normal app data must flow through actions. For CRUD that the agent can perform,
-create `defineAction` files in `actions/`, mark reads with
-`http: { method: "GET" }`, and call them from React with `useActionQuery` /
-`useActionMutation`. Do not add duplicate JSON CRUD routes under `/api/*` for
-the same data unless the route is for uploads, streaming, webhooks, OAuth, or
-another route-only concern. Do not add routes whose main job is to wrap,
-proxy, or re-export an action; the action endpoint already exists at
-`/_agent-native/actions/:name`. Action-backed UI is what makes agent-created or
-agent-edited records appear without a manual refresh.
-
-App database code must be provider-agnostic. Define schemas with
-`@agent-native/core/db/schema` helpers and write app reads/writes with Drizzle's
-query builder and portable `drizzle-orm` operators. Do not import from
-`drizzle-orm/sqlite-core` or `drizzle-orm/pg-core` in app templates. Keep raw SQL
-for additive migrations, health checks, or carefully scoped maintenance, and
-never write SQLite-only or Postgres-only product code. Do not use SQL as object
-storage; file bytes belong in upload/private-blob providers with only references
-saved to app tables.
+Use package docs for framework APIs, the package corpus for reusable
+framework/template patterns, and this `AGENTS.md` plus `.agents/skills/` for
+workspace-specific conventions.
 
-In local development, run
-`pnpm exec agent-native create <app-name> --template=<template>` from the
-workspace root. In production, Dispatch posts new-app requests to Builder
-branch creation; Builder should still scaffold the separate workspace app. The
-workspace dev gateway (`pnpm dev`) detects new `apps/<app-name>` directories
-automatically.
+## Actions
 
-When using the chat template, treat it as scaffolding only. The finished app
-must be branded as the requested app, with its own home screen, navigation,
-package metadata, manifest, and domain workflow. Do not leave visible
-`Chat`, `Starter`, `Blank app`, `Start building`, or `New app` UI in a chat-derived
-app.
+| Action | Purpose |
+| --- | --- |
+| `docs-search` | Search version-matched framework docs by query or slug, or list |
+| `source-search` | Search the bundled core/template source corpus by pattern or path |

package/corpus/core/src/templates/workspace-root/AGENTS.md

@@ -76,6 +76,9 @@ refreshes framework-provided shared skills and repairs `CLAUDE.md` /
 
 ## Workspace Scope
 
+- Scale effort to the task. A small, well-specified change is a short read, the
+  edit, and the existing checks — not a codebase survey, unrequested tests, or
+  browser automation.
 - Keep root changes focused on workspace orchestration, shared configuration,
   deploy settings, and monorepo tooling.
 - Keep application routes, actions, server plugins, and app state inside the
@@ -156,7 +159,9 @@ refreshes framework-provided shared skills and repairs `CLAUDE.md` /
   for the same data unless the route is for uploads, streaming, webhooks,
   OAuth, or another route-only concern. Do not add routes whose main job is to
   wrap, proxy, or re-export an action; the action endpoint already exists at
-  `/_agent-native/actions/:name`. Action-backed UI is what makes agent-created
+  `/_agent-native/actions/:name`. If you are about to create a file under
+  `server/routes/api/`, or middleware to guard one, stop and write a
+  `defineAction` instead. Action-backed UI is what makes agent-created
   or agent-edited records appear without a manual refresh.
 - App database code must be provider-agnostic. Define schemas with
   `@agent-native/core/db/schema` helpers and write app reads/writes with

package/corpus/core/src/triggers/dispatcher.ts

@@ -18,6 +18,7 @@ import {
   getOwnerActiveApiKey,
   type ActionEntry,
 } from "../agent/production-agent.js";
+import { runAgentLoopDirectWithSoftTimeout } from "../agent/run-loop-with-resume.js";
 import { attachToolSearch } from "../agent/tool-search.js";
 import type { AgentChatEvent } from "../agent/types.js";
 import { createThread } from "../chat-threads/store.js";
@@ -485,24 +486,34 @@ ${body}`;
           null;
 
         try {
-          triggerUsage = await runAgentLoop({
-            engine,
-            model,
-            systemPrompt,
-            tools,
-            availableTools,
-            messages,
-            actions,
-            send: (event) => events.push(event),
-            signal: controller.signal,
-            threadId: thread.id,
-            actionCaller: "automation",
-            automation: {
-              triggerId: resource.id,
-              triggerName,
-              policyId: meta.delegatedPolicyId,
+          // Wrapper, not raw `runAgentLoop`: an automation runs with nobody
+          // watching, so a transport-level cut (gateway 45s, socket hang up)
+          // has to be resumed inside this invocation or the trigger silently
+          // does nothing. `undefined` budget + the hosted default keeps the
+          // soft timeout under the serverless wall on hosts that have one and
+          // disabled locally.
+          triggerUsage = await runAgentLoopDirectWithSoftTimeout(
+            {
+              engine,
+              model,
+              systemPrompt,
+              tools,
+              availableTools,
+              messages,
+              actions,
+              send: (event) => events.push(event),
+              signal: controller.signal,
+              threadId: thread.id,
+              actionCaller: "automation",
+              automation: {
+                triggerId: resource.id,
+                triggerName,
+                policyId: meta.delegatedPolicyId,
+              },
             },
-          });
+            undefined,
+            { useHostedDefault: true },
+          );
         } finally {
           clearTimeout(timeout);
         }

package/corpus/core/src/vite/client.ts

@@ -1648,18 +1648,30 @@ function baseRedirectGuard(): Plugin {
         if (serveMountedEmbedRuntimeModule(server, req, res, base)) {
           return;
         }
-        // Nitro's pre-middleware only intercepts document/iframe/frame/empty
-        // fetch-dest requests. For video/audio/image etc. it calls next() and
-        // the post-internal Nitro middleware handles them instead. If we strip
-        // the base path here for those requests, Vite's base middleware sees the
-        // stripped path (e.g. /api/video/:id without /clips/) and responds with
-        // a "did you mean /clips/api/video/:id" error before Nitro can handle it.
-        // Only strip when the request type matches Nitro's pre-middleware gate.
+        // stripMountedDevApiPath only rewrites paths that resolve to /api/**
+        // (see isApiDevPath below), so this never touches static asset or
+        // document requests — only mounted API calls. Nitro's dev router
+        // matches routes against req.url with the mount prefix still in
+        // place (its own baseURL is unset in dev), so a mounted API request
+        // must have that prefix stripped before Nitro's router ever sees it,
+        // regardless of Sec-Fetch-Dest — otherwise it falls through to
+        // Vite/connect's generic 404 instead of the real handler. This used
+        // to be gated to document/iframe/frame/empty only, because stripping
+        // for video/audio/image previously made Vite's base middleware see
+        // the stripped path (e.g. /api/video/:id without /clips/) before
+        // Nitro's router got a chance to match it. That gate is stale: image
+        // and video requests hit the exact same "Cannot GET" fallback today,
+        // because the browser sends Sec-Fetch-Dest: image/video/audio/track
+        // for <img>/<video>/<audio> fetches, not empty — so those requests
+        // were never actually reaching Nitro pre-strip in the first place.
         const secFetchDest = req.headers["sec-fetch-dest"] as
           | string
           | undefined;
         const isNitroPreHandled =
-          !secFetchDest || /^(document|iframe|frame|empty)$/.test(secFetchDest);
+          !secFetchDest ||
+          /^(document|iframe|frame|empty|image|video|audio|track)$/.test(
+            secFetchDest,
+          );
         if (isNitroPreHandled) {
           req.url = stripMountedDevApiPath(req.url, base);
         }

package/corpus/templates/analytics/.agents/skills/actions/SKILL.md

@@ -18,6 +18,8 @@ Actions in `actions/` are the **single source of truth** for app operations. The
 
 Before creating any custom REST/API route for app data, inspect `actions/` and the action table in `AGENTS.md`. If an action already exists, call it directly from the agent or with `useActionQuery` / `useActionMutation` from the UI. If the capability is missing, create or update a `defineAction`. Do not add `/api/*`, `server/routes/*`, or other pass-through endpoints whose main job is to call, repackage, or re-export an action.
 
+**Stop trigger:** the moment you are about to create a file under `server/routes/api/` — or add server middleware to guard one — stop and check it against the exception list in *When You Still Need Custom `/api/` Routes* below. If it is not on that list, write a `defineAction` instead. This applies even when you already started the route; abandoning a half-written action to hand-roll routes is the exact failure this rule exists to prevent.
+
 ## Why
 
 Actions give the agent callable tools with structured input/output, AND they give the frontend a typed client contract through hooks. One implementation serves both the agent and the UI. They keep the agent's chat context clean, they're reusable, and they can be tested independently.
@@ -390,12 +392,28 @@ This is the canonical approach for new apps. Action names must be lowercase with
 
 ## When You Still Need Custom `/api/` Routes
 
-Most operations should be actions. You only need custom routes in `server/routes/api/` for:
+This is the complete exception list. A route in `server/routes/api/` is only
+justified when the caller is not your own UI or agent, or when the payload is
+not JSON:
 
 - **File uploads** — actions receive JSON params, not multipart form data
 - **Streaming responses** — SSE or chunked responses that need direct H3 control
 - **Webhooks** — external services POST to a specific URL
 - **OAuth callbacks** — redirect-based flows that need specific URL patterns
+- **Public unauthenticated endpoints** — SEO/OG images, share links, and other
+  URLs opened directly by a browser or crawler
+- **Binary or non-JSON responses** — media, exports, generated assets
+
+Everything else is an action: CRUD, settings, search, list/detail reads, auth
+state, and anything the UI fetches as JSON. If a route needs new middleware to
+scope it to the current user, that is a signal it should be an action — actions
+already run inside request context with access checks.
+
+Existing first-party templates still contain a shrinking, explicitly
+grandfathered set of older `/api/*` CRUD routes for app data. The repository's
+`guard:no-action-twin-routes` CI check ratchets that baseline down across the
+first-party template route trees (with the separately owned Plan template
+fenced out); it is not a substitute for keeping generated apps action-first.
 
 When the agent needs a durable image or file URL, call the core `upload-image`
 action or use `uploadFile()` in server code. Do not write base64 into SQL,

package/corpus/templates/analytics/.agents/skills/dashboard-management/SKILL.md

@@ -120,12 +120,49 @@ pnpm action navigate --view=adhoc --dashboardId=weekly-metrics
 
 The save path dry-runs BigQuery panels before persisting. If validation returns a provider error, fix the query and retry. Never work around validation by writing directly to a table.
 
+## Dual-Axis Charts
+
+`line`, `area`, and `bar` panels can plot series against two y-axes. Reach for
+this whenever series share an x-axis but not a unit — a count next to a rate, or
+revenue next to a conversion percent. On a single axis the smaller series
+flattens into the baseline and reads as "no data."
+
+```json
+{
+  "id": "signups-vs-conversion",
+  "title": "Signups vs conversion rate",
+  "source": "first-party",
+  "chartType": "line",
+  "width": 1,
+  "sql": "SELECT day, signups, conversion_rate FROM ...",
+  "config": {
+    "timeScope": "dashboard",
+    "xKey": "day",
+    "yKeys": ["signups", "conversion_rate"],
+    "yFormatter": "number",
+    "rightYKeys": ["conversion_rate"],
+    "rightYFormatter": "percent"
+  }
+}
+```
+
+- `rightYKeys` names series from `yKeys`; everything unnamed stays on the left.
+- `rightYFormatter` defaults to `yFormatter` when omitted.
+- Each axis is labelled with its series names (up to two per side), and tooltip
+  values use the formatter of the axis the series belongs to.
+- At least one series must remain on the left. If `rightYKeys` names every
+  series, or names a column the query never returned, the panel falls back to a
+  single axis and shows a config warning rather than dropping the series.
+- Scheduled email reports render the same two scales, so a dual-axis panel is
+  safe to put on a subscribed dashboard.
+
 ## When To Use An Extension Instead
 
 Native Analytics dashboards are JSON configs rendered by the built-in dashboard
 components. Use native dashboard actions only when the request fits that model:
 standard panels, supported chart types, filters, variables, sections, and grid
-layout.
+layout. Dual-axis charts are part of that model — build one with
+`config.rightYKeys`, never as an extension.
 
 If the user asks for a dashboard or analytical surface that needs bespoke UI or
 code beyond the dashboard JSON/component model, create an extension and embed it
@@ -413,6 +450,9 @@ type PanelConfig = Record<string, unknown> & {
   // Use "dashboard" for AI-generated first-party panels by default.
   timeScope?: PanelTimeScope;
   // Fixed bar width in pixels for bar charts.
+  // Series to plot against a second, right-hand y-axis. See "Dual-Axis Charts".
+  rightYKeys?: string[];
+  rightYFormatter?: "number" | "currency" | "percent";
 };
 
 type PanelPatch = {

package/corpus/templates/analytics/.agents/skills/dashboard-ops/SKILL.md

@@ -2,10 +2,11 @@
 name: dashboard-ops
 description: >-
   Deployment and runtime internals for dashboard email reports and analytics
-  alert rules: Playwright/Chromium capture, serverless timing budgets, cron
-  wiring, and notification delivery env vars. Use when configuring, deploying,
-  or debugging report/alert delivery infrastructure — not when just creating a
-  report subscription or alert rule via the action surface.
+  alert rules: server-side SVG/PNG report rendering, serverless timing
+  budgets, cron wiring, and notification delivery env vars. Use when
+  configuring, deploying, or debugging report/alert delivery infrastructure —
+  not when just creating a report subscription or alert rule via the action
+  surface.
 scope: dev
 ---
 
@@ -17,27 +18,54 @@ surfaces. This skill covers the deployment/runtime machinery behind them —
 the agent chatting with an end user does not need this; it only needs the
 action names and the user-facing constraints already in `AGENTS.md`.
 
-## Dashboard Email Report Capture
+## Dashboard Email Report Rendering
 
-- Report PNGs are Playwright captures of the real dashboard route in
-  `reportScreenshot=1` mode, authenticated by a short-lived embed-session
-  token, and embedded inline in the email as ordered CID images.
-- Complete dashboards are captured sequentially in four-panel windows matching
-  the browser's four-query concurrency limit. Every window must match the
-  panel ids snapshotted at the start; a failed or mismatched window
-  invalidates the entire image set so the scheduler retries instead of
-  sending a partial report.
-- Capture is capped at 10 windows and 14 MiB of raw PNG data. Subscriptions
-  are capped at five distinct recipients — recommend a mailing-list address
-  for larger audiences.
-- The serverless capture deadline reserves 90 seconds of the 300-second
-  worker budget for cleanup and delivery.
+- Scheduled reports render entirely server-side. They do not use a headless
+  browser, Chromium pack download, or the old `reportScreenshot=1` embed-session
+  screenshot URL; interactive dashboard screenshot capture remains separate.
+- Each panel's query runs through the same source dispatcher the UI uses
+  (`runDashboardPanelQuery`), inside the subscription owner's request
+  context, so per-source access scoping (BigQuery/Gong/HubSpot credentials,
+  org scoping) is preserved exactly as if the owner loaded the dashboard.
+- Chart panels are drawn as SVG and rasterized to PNG with `@resvg/resvg-js`,
+  then embedded in the email as `cid:` attachments. Fonts come from
+  `resolveOgFontFiles()` — **resvg has no system fonts in a Lambda runtime,
+  so chart text silently renders blank (not an error) unless those bundled
+  font files are passed to it.** Never drop that font wiring when touching
+  chart rendering.
+- Non-chart panels (`section`, `metric`, `callout`, `table`, `heatmap`) render
+  as real email HTML, not images. `extension` panels cannot be rendered for
+  email at all and instead link out to the live dashboard.
+- A panel that fails to query renders a visible error card in its place and
+  marks the whole run `degraded`; a degraded report is never sent or recorded
+  as if it were complete. If every panel fails, nothing is sent and the
+  subscription errors out instead of emailing an empty report.
+- Subscriptions are capped at five distinct recipients
+  (`MAX_DASHBOARD_REPORT_RECIPIENTS`) — recommend a mailing-list address for
+  larger audiences.
 - The ten-minute retry delay is an eligibility floor, not a guarantee; the
   `*/15` sweep runs the retry on its first tick after that floor.
-- PNG rendering uses local Chrome in development and `playwright-core` plus
-  `@sparticuz/chromium-min` in serverless runtimes. Set
-  `DASHBOARD_REPORT_CHROMIUM_PACK_URL` only when overriding the default
-  Chromium pack location.
+- The serverless delivery deadline (`SERVERLESS_REPORT_DELIVERY_BUDGET_MS` in
+  `server/jobs/dashboard-report.ts`) reserves 220 seconds of the
+  `dashboard-report-sweep-background` function's 300-second `netlify.toml`
+  timeout for rendering and delivery, leaving the remainder for cleanup.
+- Netlify sweeps process up to 5 subscriptions per tick
+  (`SERVERLESS_MAX_REPORTS_PER_SWEEP`) — no longer forced to 1, since capture
+  no longer drives a per-subscription browser. Long-lived (non-Netlify)
+  runtimes default to the same limit of 5, overridable with
+  `DASHBOARD_REPORT_SWEEP_LIMIT`.
+
+### Env Vars
+
+- `DASHBOARD_REPORT_BASE_URL` — overrides the dashboard link URL in emails; if
+  unset, falls back to `getAppProductionUrl()` (the `APP_URL` /
+  `WORKSPACE_OAUTH_ORIGIN` / `BETTER_AUTH_URL` chain).
+- `RESEND_API_KEY` or `SENDGRID_API_KEY` plus `EMAIL_FROM` — required to send
+  the report email at all.
+- `DASHBOARD_REPORTS_CRON_SECRET` — bearer token external cron callers must
+  send to `POST /api/dashboard-reports/run`.
+- `DASHBOARD_REPORT_SWEEP_LIMIT` — overrides the per-tick sweep size on
+  non-Netlify runtimes (see above).
 
 ## Cron Wiring
 

package/corpus/templates/analytics/.agents/skills/data-querying/SKILL.md

@@ -57,7 +57,7 @@ Fence keys: `src` (required, same-origin path), `title`, and either `height` (px
 - `sql` — required, non-empty.
 - `source` — required, one of `bigquery`, `ga4`, `amplitude`, `first-party`, `demo`, `prometheus`. `program` is deliberately **not** embeddable.
 - `chartType` — required, one of `line`, `area`, `bar`, `metric`, `table`, `pie`. Dashboard-layout types (`section`, `heatmap`, `callout`, `extension`) are rejected.
-- `id` (defaults `"embed"`), `title` (rendered above the chart), `width` (dashboard-only, ignored here), `config` (passed through unvalidated — `xKey`/`yKeys`, `colors`, `yFormatter`, `columns`, `stacked`, `legend`, …).
+- `id` (defaults `"embed"`), `title` (rendered above the chart), `width` (dashboard-only, ignored here), `config` (passed through unvalidated — `xKey`/`yKeys`, `colors`, `yFormatter`, `rightYKeys`/`rightYFormatter` for a dual-axis line/area/bar chart, `columns`, `stacked`, `legend`, …).
 
 An unknown `source`/`chartType` or blank `sql` renders an error card, not a chart.
 

package/corpus/templates/analytics/.agents/skills/data-querying/references/inline-chart-embeds.md

@@ -78,6 +78,14 @@ Any other `source`/`chartType` value, or a missing/blank `sql`, makes
   auto-detection.
 - `colors` / `color` — series colors.
 - `yFormatter` — `"number"` | `"currency"` | `"percent"`.
+- `rightYKeys` / `rightYFormatter` — `line`, `area`, and `bar` only: plot the
+  named series against a second, right-hand y-axis with its own scale and
+  formatter. Use this whenever series share an x-axis but not a unit (counts
+  next to a rate, revenue next to a conversion percent) — on one axis the
+  smaller series flattens into the baseline. At least one series must stay on
+  the left axis; if `rightYKeys` names every series, or names a column the
+  query never returned, the chart falls back to a single axis and the panel
+  shows a config warning.
 - `columns` — `table` chartType only: `{ key, label?, format?, linkKey?, hidden? }[]`.
 - `stacked`, `legend`, `pivot`, `limit`, `valueLabels`, `description` — see
   `SqlPanelConfig` in `types.ts` for the full list.

package/corpus/templates/analytics/.agents/skills/frontend-design/SKILL.md

@@ -1,14 +1,17 @@
 ---
 name: frontend-design
 description: >-
-  Create distinctive, production-grade frontend interfaces with high design
-  quality. Use when building web components, pages, artifacts, posters, or
-  applications (websites, landing pages, dashboards, React components,
-  HTML/CSS layouts, or when styling/beautifying any web UI). Generates
-  creative, polished UI that avoids generic AI aesthetics.
+  Sets the visual direction for a new or redesigned surface, with production
+  quality that avoids generic AI aesthetics. Use when building a new page,
+  app, or marketing surface, defining visual identity, or doing a design pass
+  ("make this look good"). Do not load it for routine UI edits: adding a field
+  to an existing form, fixing spacing, wiring a button, or changing copy.
 scope: dev
 license: Complete terms in LICENSE.txt
 source: https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md
+local-changes: >-
+  Description narrowed and Verification rescoped deliberately; an upstream sync
+  must not restore the broad auto-load triggers or screenshot-everything step.
 metadata:
   internal: true
 ---
@@ -141,11 +144,22 @@ Avoid:
 
 ## Verification
 
+Match verification effort to the size of the change. For one component, one
+form, one page, or a restyle, run the app's existing checks — formatter,
+`pnpm typecheck`, existing tests — and stop there.
+
+Escalate to browser verification only when the user asks for it, or when the
+change is a multi-step user-visible flow that cannot be confirmed any other
+way. Never author a new Playwright/Puppeteer script, add a browser-automation
+dependency, or stand up an e2e harness to check work the user did not ask you
+to test that way; use an available browser tool, or say what you could not
+verify.
+
 For substantial frontend work:
 
 1. Run the relevant formatter/checks.
 2. Start the dev server when the app needs one.
-3. Verify with browser screenshots at desktop and mobile widths.
+3. Verify with the available browser tooling at desktop and mobile widths.
 4. Check interactive states: hover, focus, loading, empty, error, and destructive confirmations.
 5. When registering or changing a company adapter, run
    `@agent-native/toolkit/conformance`, including mixed-overlay focus,

package/corpus/templates/analytics/.agents/skills/security/SKILL.md

@@ -127,6 +127,8 @@ Two more CI guards (also wired into `pnpm prep`) target the 2026-04 cross-tenant
 - `scripts/guard-no-env-mutation.mjs` — bans `process.env.<KEY> = …` (and bracket / compound forms) anywhere in production code. On serverless, every warm container handles many concurrent requests in one Node process, so `process.env` mutation leaks across in-flight requests (the "restore" line at the end of a handler races and never helps — most recently the Zoom webhook). Use `runWithRequestContext({ userEmail, orgId, timezone }, fn)` from `@agent-native/core/server` instead — it's AsyncLocalStorage-backed and per-request safe. Allowlisted paths: `scripts/`, `*.spec.ts` / `*.test.ts`, `packages/core/src/dev**`, `templates/*/test/`, anything under `/cli/` or `/scaffold/`. Per-line opt-out: `process.env.X = y // guard:allow-env-mutation — <reason>`.
 - `scripts/guard-no-localhost-fallback.mjs` — bans the literal `"local@localhost"` / `'local@localhost'` / `` `local@localhost` `` in production code. The bug class: `getRequestUserEmail() ?? "local@localhost"` silently pools every unauthenticated request into a single shared tenant, leaking credentials, tools, and `application_state` rows between accounts. The right behavior is to throw / 401 when there's no session. Allowlisted paths: the dev-mode auth shim (`packages/core/src/server/auth.ts`), `packages/core/src/dev**`, tests, `scripts/`, `seed/` / `seeds/`, plus a few framework helpers that intentionally inspect or migrate the dev identity. SQL DDL `DEFAULT 'local@localhost'` and the Drizzle helper `.default('local@localhost')` are skipped per-line — schema column defaults are intentional dev fixtures, not the dangerous fallback pattern. Per-line opt-out: `email ?? "local@localhost" // guard:allow-localhost-fallback — <reason>`.
 
+  The same guard also bans the **ambient process identity** as a request-scoped fallback: `?? process.env.AGENT_USER_EMAIL`, `|| process.env.WORKSPACE_OWNER_EMAIL`, and `?? getAmbientUserEmail()`. Those name the identity of the *deployment*, not the caller, so a handler reading one authorizes whoever the deploy env names rather than whoever signed in — it fails open toward more privilege. Exempt paths are the ones with no request by construction: `scripts/` (including `templates/*/scripts/`), `src/cli/`, `src/scripts/`, `script-helpers.ts` / `script-entries.ts`, tests, and seeds. It deliberately matches only the `??` / `||` fallback position, so reading the same env var to build an admin allowlist (`envEmails("WORKSPACE_OWNER_EMAIL").includes(email)`) is untouched. Known gaps, both requiring dataflow analysis the guard does not do: an env read aliased through a local (`const fallback = process.env.AGENT_USER_EMAIL; … ?? fallback`) and a destructured `const { AGENT_USER_EMAIL } = process.env`.
+
 ## Auth
 
 - All actions are protected by the auth guard automatically.