@agent-native/core 0.141.7 → 0.144.1

package/agent-native.eject.json

@@ -31,11 +31,20 @@
         "vercel",
         "github",
         "fullstory",
+        "amplitude",
         "slack",
         "asana",
         "hubspot",
+        "apollo",
+        "builder-cms",
+        "common-room",
+        "exa",
+        "gong",
+        "google-workspace",
+        "grafana",
         "intercom",
         "monday",
+        "pylon",
         "webflow",
         "paypal",
         "box",

package/corpus/README.md

@@ -31,4 +31,4 @@ rg -n "defineAction|useActionQuery" node_modules/@agent-native/core/corpus
 
 ## Generated Counts
 
-- template files: 7705
+- template files: 7847

package/corpus/templates/analytics/.agents/skills/provider-api/SKILL.md

@@ -31,6 +31,25 @@ expose.
   counts, and column names.
 - `delete-staged-dataset` — remove a staged dataset to free scratch storage.
 
+## Custom API sources
+
+Use `provider-api-register` when a public HTTPS API is not in the built-in
+catalog. Registration stores the provider label, base URL, docs URL, auth mode,
+and credential key names only. Save the actual key in Analytics Settings before
+testing or querying it. Org-scoped registration is restricted to organization
+owners/admins; use user scope for a personal source.
+
+The Analytics Data Sources page provides a bounded GET test with an optional
+query and response items path. It returns status, row count, columns, and a few
+sample rows without returning raw headers or response bodies. After the test
+passes, use the handoff to save a manual-refresh Data Program with
+`providerFetch` and `emit(rows, schema)`. Keep pagination and scheduled refresh
+inside the Data Program rather than inventing a second cache.
+
+Custom provider base URLs must be public HTTPS. Hosted Analytics cannot resolve
+the user's localhost or private LAN; use a deployed endpoint or an approved
+secure tunnel. Never bypass the provider runtime's DNS-aware SSRF protection.
+
 ## Clay
 
 Clay is a credentialed GTM data and enrichment provider, not a messaging

package/corpus/templates/analytics/.agents/skills/turn-into-app/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: turn-into-app
+description: >-
+  Turn a proven thread, skill, or workflow into a runnable Agent-Native app
+  with simple buttons, visible agent steps, preview, and deployment handoff.
+  Use when a user invokes `/turn-into-app` or asks to make a workflow into an
+  app.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into App
+
+## Default behavior
+
+This is an end-to-end build skill, not a request for an app proposal.
+
+- With no argument, use the current thread as the source. This is the normal
+  invocation at the end of a successful workflow.
+- With a named skill or local workflow, read that source and package it
+  immediately, even at the beginning of a thread. For example,
+  `/turn-into-app /some-skill` means “turn `/some-skill` into an app.”
+- With an attachment or path, read the supplied artifact as the source.
+- Do not ask the user to restate context that is already in the thread.
+- When invoked from an Agent-Native app, keep the current thread as the source
+  and use the available workspace/coding-agent handoff when the current runtime
+  cannot edit files. Do not claim the app exists without an actual path and
+  verification result.
+
+## Source support
+
+Supported source paths today are the current Codex thread, a named skill, or a
+local workflow/transcript supplied as a path or attachment. An exported
+ChatGPT or Claude transcript can use the same local-file path today.
+
+ChatGPT shared-conversation import and Claude web conversation/project import
+are **coming soon**. Do not claim private web access, invent an importer, add
+fake OAuth, or scrape a logged-in page without an explicit supported adapter.
+If a user gives one of those URLs before an adapter exists, ask for an export or
+transcript instead and treat it as imported source material.
+
+Deliver a fresh app in a new directory, implement the repeatable workflow with
+buttons and agent handoffs, start its dev server, verify the main path, and
+continue through build/deployment handoff. Do not stop at a plan.
+
+## Source selection guard
+
+The generated app must implement the concrete workflow found in the source. It
+must not become a generic “what app do you want to make?” intake form.
+
+- In a delegated or forked task, read the actual referenced source thread and
+  the latest explicit workflow direction in the current task. If they disagree,
+  the latest concrete workflow direction wins.
+- Do not treat a thread that merely discusses building this skill as the product
+  source unless the user explicitly asks to appify that meta-workflow.
+- If the source contains several workflows, choose the latest successful,
+  repeatable job that motivated the request and name it in the handoff. If no
+  concrete job can be identified, stop and report what is missing instead of
+  inventing an app-builder UI.
+
+## UI contract for generated apps
+
+Generated apps must follow the shared Agent-Native surface model:
+
+- Keep the domain workflow on a named route (`/workflow`, `/automations`,
+  `/block`, or the source's equivalent). Preserve the scaffold's full-page
+  chat route instead of replacing it with a domain form while leaving the
+  layout configured as a chat page.
+- Use the right `AgentSidebar` for contextual AI. Every button-triggered
+  `sendToAgentChat` handoff should open or focus that sidebar and keep the user
+  on the current domain page.
+- Use a sans-first SaaS hierarchy for the app shell. Choose a named visual
+  direction in `DESIGN.md` before styling: product mode, audience, palette
+  family, type treatment, composition, shape language, and anti-references.
+  One restrained editorial cue is welcome, but warm beige plus terracotta is
+  not the default and serif type belongs in content previews or a deliberate
+  brand moment rather than the whole tool.
+- Preserve existing brand tokens. For a new unbranded app, choose a
+  product-fitting palette family and compare sibling apps before reusing their
+  accent. Keep shared semantic tokens and Agent-Native behavior consistent
+  while varying the visual world, density, composition, and shape language.
+- Give the AgentSidebar a subtle surface or divider boundary so it is visually
+  distinct from the domain page without becoming a heavy panel wall.
+- Every AI-labeled button must actually call `sendToAgentChat` with bounded
+  context and `openSidebar: true`. Keep `submit: true` for direct execution and
+  `submit: false` only when the user should edit the staged prompt first. Label
+  deterministic local actions as local, preview, or analyze instead of AI.
+- Standalone apps that render `AgentSidebar` must keep one assistant-ui runtime
+  context. Pin the versions compatible with the installed core/toolkit peer
+  graph, and add Vite dedupe/aliases when linked or transitive packages resolve
+  duplicate assistant-ui modules. Verify a fresh AI handoff has no
+  `AssistantUiStaleIndexErrorBoundary` or stale-index console error.
+- Make the left navigation describe domain destinations. Chat is a separate
+  destination, not the label for every app page.
+- Start with one primary action and one compact state. Put setup choices,
+  advanced inputs, diagnostics, and long explanations behind progressive
+  disclosure or later workflow steps.
+- Never use sparkle, wand, magic, robot, or similar decorative AI icons. Use a
+  message or neutral action icon, or no icon when the button label is enough.
+- Before handoff, inspect the first viewport for text density, repeated cards,
+  unrelated forms, and generic helper copy. Remove what the user does not need
+  until the next decision.
+- Run a `distill`, `typeset`, `colorize`, `layout`, `polish`, and `audit` pass
+  as useful named reviews. Make one intervention at a time and commit the
+  chosen direction rather than averaging several options into generic SaaS.
+- For before/after or original/generated review, stack the source first and the
+  result second by default. Reserve side-by-side layouts for short content that
+  remains comfortable to scan at the target width.
+
+## 1. Extract the workflow
+
+Read the full available source before coding. Reduce it to a short working
+brief:
+
+- the user and repeatable job;
+- inputs and outputs;
+- the 1-3 judgment-heavy agent moments;
+- the buttons, review points, and retry states a user needs;
+- data, permissions, integrations, and failure boundaries.
+
+Preserve useful judgment from the source, but do not turn a one-off answer,
+private data, or an unverified result into a product contract. If the source is
+not available or does not contain a repeatable job, say what is missing rather
+than claiming the app is complete.
+
+## 2. Create a fresh app
+
+Choose a short slug from the workflow and create a new directory. Never
+overwrite an existing app. If the user supplied a directory, use it; otherwise
+use `apps/<slug>` inside an existing Agent-Native workspace, or a new sibling
+directory when working outside one.
+
+For a new UI-bearing standalone app, use the current Agent-Native scaffold and
+then read the generated `AGENTS.md`:
+
+```bash
+npx @agent-native/core@latest create <app-directory> --template chat
+cd <app-directory>
+pnpm install
+```
+
+When working inside an existing Agent-Native workspace, create the app from
+the workspace root instead:
+
+```bash
+pnpm exec agent-native add-app <slug> --template=chat
+```
+
+Do not use `create` for an existing workspace; it scaffolds a new standalone
+workspace rather than adding an app to the current one.
+
+Use a first-party template only when it materially fits the workflow. Keep the
+new app independent from the source thread's working tree unless the user
+explicitly asks to extend an existing app.
+
+Read the generated `DESIGN.md` before building the first screen and fill in the
+visual direction as part of the app brief. Do not copy the previous app's
+palette just because its tokens are nearby.
+
+## 3. Turn the workflow into buttons and agent work
+
+Implement the smallest useful surface around the extracted brief. The app
+should make the repeated path obvious without hiding the agent's judgment:
+
+- Give each important repeated moment a clear button, such as “Analyze,”
+  “Suggest options,” “Draft,” “Review,” or “Publish.” Use the source's actual
+  vocabulary when it is clear.
+- Put deterministic reads, writes, approvals, and publishing in `actions/`
+  with `defineAction`. The UI and agent must call the same action surface.
+- Use application state for the current screen, selected item, and focused
+  object so the agent can see where the user is.
+- Use `sendToAgentChat({ message, context, submit: true })` for intentional
+  button-triggered agent work. Use `submit: false` when the user should review
+  or edit the proposed prompt first.
+- Pass IDs, URLs, and bounded summaries in context. Do not paste large provider
+  dumps into prompts, call an LLM directly from the browser, or invent fake
+  progress.
+- Make agent results visible, editable, retryable, and attributable. Keep
+  irreversible actions behind an explicit review or confirmation point.
+
+Use the existing shadcn/ui primitives, Tabler icons, shared composer, and
+optimistic action patterns. Do not add a parallel CRUD API route for an action.
+
+## 4. Keep onboarding shared
+
+Use the framework's existing setup experience. The app should offer the normal
+“Connect Builder” and “Add your own keys” paths for AI setup. Do not create a
+second credential form or hardcode a provider key.
+
+In local-development instructions, add a brief note that a developer can set
+an environment variable such as `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` before
+starting the app; after restart, the setup prompt is no longer shown when the
+key is available. Keep real secrets out of source, examples, and generated
+content.
+
+Turn-into-app apps should commit an `agent-native.json` app configuration so a
+plain `pnpm dev` has the right first-run behavior without extra flags:
+
+```json
+{
+  "version": 1,
+  "onboarding": {
+    "firstRun": {
+      "development": "connect",
+      "production": "connect-and-integrations"
+    }
+  }
+}
+```
+
+`connect` keeps the Connect Builder / Add your own keys choice visible and
+skips only the generic “This app is an agent.” integrations catalog. The
+production value includes that catalog for a hosted app. Do not replace this
+with a local credential form or remove the shared onboarding. In development,
+the shared Connect Builder card also explains the deployment-level
+`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` fallback and links to the full
+environment-variable guide.
+
+When the onboarding default needs code rather than a static mode map, add an
+optional `agent-native.config.ts` with the same returned shape:
+
+```ts
+import { defineAgentNativeConfig } from "@agent-native/core/config";
+
+export default defineAgentNativeConfig(({ isDev }) => ({
+  version: 1,
+  onboarding: {
+    firstRun: isDev ? "connect" : "connect-and-integrations",
+  },
+}));
+```
+
+The Vite preset loads this file automatically on supported Node versions. The
+JSON file remains the portable, inspectable fallback. See the [Agent-Native
+app configuration guide](/docs/agent-native-config) for precedence, supported
+modes, and the boundary between committed config and deployment secrets.
+
+For an account-free local preview, create the ignored local `.env` file with
+`AUTH_DISABLED=1` before starting the dev server. This is only for loopback
+development; never commit or deploy this setting. AI/provider connections still
+use the normal onboarding flow or the documented environment-variable keys.
+
+## 5. Run it immediately
+
+From the new app directory:
+
+```bash
+pnpm dev
+```
+
+For a fresh local test app, use the ignored `.env` with `AUTH_DISABLED=1` so the
+domain UI opens without an account; the committed app config makes shared
+onboarding visible. Keep the process running so the user can try the app. Read
+the actual server output and report the real local URL. If the app needs installation or a setup step,
+complete it when possible and distinguish “not configured” from an unavailable
+credential store.
+
+## 6. Verify, build, and deploy
+
+Exercise the actual happy path, not only the source files:
+
+1. Load the reported URL and confirm the main route renders.
+2. Confirm the shared onboarding state or a configured local key.
+3. Click the primary workflow button and confirm the intended agent handoff.
+   Also click every other AI-labeled button and confirm it opens the same
+   contextual sidebar with the expected prompt or staged context.
+4. Confirm the result, action persistence, application state, and sync path.
+5. Check the dev output for browser/runtime errors, and capture input, result,
+   and agent-sidebar states so the complete flow is reviewable.
+
+Then run the supported build. For a standalone app, use the generated app's
+documented build and hosting path. For an app inside a workspace, use the
+workspace deploy command, for example:
+
+```bash
+npx @agent-native/core@latest build
+npx @agent-native/core@latest deploy --preset netlify
+```
+
+Use `vercel` or another supported preset when that is the configured target.
+Attempt deployment when the user requested it or the project already has the
+required provider configuration. If external authentication, a production
+secret, or a hosting decision is missing, finish local verification and report
+the exact remaining handoff without claiming a live deployment.
+
+Label evidence separately: locally running, locally verified, build-ready,
+deployed, and live-verified are different states.
+
+## Handoff
+
+End with the new app directory, local URL, visual direction, what the buttons do,
+account-free local-preview status, verification performed, deployment URL if it is real,
+and one precise pending step when something could not be completed. Keep the
+handoff short enough to use in a demo or recording.

package/corpus/templates/analytics/.agents/skills/turn-into-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into App"
+  short_description: "Turn a thread or skill into a runnable app"
+  default_prompt: "Scan the current thread, turn the workflow into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/corpus/templates/analytics/.agents/skills/turn-into-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: turn-into-skill
+description: >-
+  Capture a proven thread or workflow as a reusable Agent-Native skill and save
+  it as a personal or organization resource. Use when a user invokes
+  `/turn-into-skill` or asks to save a workflow for reuse.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into Skill
+
+This is a packaging-and-save workflow, not a request for a proposal. A skill
+is the lightweight path for a repeatable job that mostly needs guidance and
+existing app actions. Use `turn-into-app` when the job needs a dedicated UI,
+new persistent domain state, or a distinct app route.
+
+## Default behavior
+
+- With no argument, use the current thread as the source.
+- With a named skill, local workflow, transcript path, or attachment, read that
+  source and package it immediately.
+- Do not ask the user to restate context already present in the source.
+- Default to a personal skill unless the user explicitly asks for a team,
+  organization, or all-app skill, or passes `shared` as the scope.
+- If the current thread only discusses creating a skill, do not package that
+  meta-workflow unless the user explicitly asks for it.
+- Treat an explicit `/turn-into-skill` invocation as authorization to save the
+  resulting skill, but never overwrite an existing skill at the target path
+  unless the user clearly asks to update it.
+
+## 1. Extract the repeatable workflow
+
+Read the full source before writing. Reduce it to a concise working brief:
+
+- the repeatable job and the user outcome;
+- when the skill should trigger;
+- required inputs, context, permissions, and integrations;
+- the ordered steps and the one to three judgment-heavy decisions;
+- expected outputs, verification, retry, and failure boundaries.
+
+Preserve the useful judgment from the source, not its transcript. Do not turn
+one-off answers, private data, customer data, secrets, or unverified claims into
+the skill's contract. If no repeatable job can be identified, stop and report
+what is missing instead of inventing generic guidance.
+
+## 2. Author the skill
+
+Create a single `SKILL.md` with:
+
+- a short hyphen-case name and a description under 40 words that says what the
+  skill does and when to use it;
+- `user-invocable: true` so it can be selected from the app's `/` picker;
+- `scope: both` so the saved skill can guide the app runtime and connected
+  coding agents;
+- concise sections for purpose, trigger, inputs, workflow, verification, and
+  failure or retry behavior.
+
+Write imperative, reusable instructions. Keep exact action names, field rules,
+and decision criteria when they matter. Use placeholders for credentials and
+provider data. Do not paste the source transcript, large dumps, or ephemeral
+thread details into the saved skill.
+
+Choose a new slug when the target path already exists. Read an existing skill
+before changing it, and update it only when the user explicitly requested an
+update.
+
+## 3. Save at the requested scope
+
+Skills are resources at `skills/<slug>/SKILL.md`.
+
+| User intent | Save path |
+| --- | --- |
+| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |
+| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |
+| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |
+| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |
+
+For an all-app workspace skill, use the workspace resource action when it is
+available. If the current app does not expose it, discover or delegate to the
+configured Dispatch workspace agent. Do not silently save a personal skill and
+report it as shared. If organization approval is queued, report that the skill
+is pending approval rather than claiming it is active.
+
+Set `visibility: "workspace"` for an explicitly requested saved skill. Use
+`agent_scratch` only for temporary drafting, then promote or rewrite it before
+reporting the skill as saved.
+
+## 4. Verify and hand off
+
+After saving, read the exact `skills/<slug>/SKILL.md` resource back at the
+target scope. Confirm that the frontmatter name, trigger description, and full
+workflow body are present. If the read-back fails or the save returned an
+approval request, say so plainly and include the actual pending state.
+
+Report:
+
+- the skill name and path;
+- whether it is personal, organization-wide, or selected-app;
+- the trigger users can invoke from `/`;
+- the verification result and any approval or setup still required.
+
+## Related skills
+
+- `turn-into-app` — package the same source as a UI-bearing app with buttons,
+  agent handoffs, and a domain workflow.
+- `create-skill` — general skill format and authoring rules.
+- `capture-learnings` — lightweight memory for preferences and corrections,
+  rather than reusable workflows.
+- `self-modifying-code` — safety boundaries when the agent edits app source.

package/corpus/templates/analytics/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into Skill"
+  short_description: "Save a proven workflow as a reusable skill"
+  default_prompt: "Read the current thread, distill the repeatable workflow into a concise user-invocable skill, save it at personal or organization scope, verify the saved resource, and report its path."

package/corpus/templates/analytics/AGENTS.md

@@ -1,50 +1,41 @@
 # Analytics — Agent Guide
 
-Analytics is an agent-native BI workspace for data sources, queries, dashboards,
-charts, and warehouse integrations. Dashboards are the canonical user-facing
-artifact; legacy analyses remain readable only for compatibility.
+Analytics is an agent-native BI workspace for sources, queries, dashboards,
+charts, and warehouse integrations. Dashboards are canonical; legacy analyses
+remain readable for compatibility.
 
-Use all connected sources and MCP tools; reason over fetched data here, and do
-not suggest another AI tool.
+Use connected sources and MCP tools; reason over fetched data here, not via
+another AI tool.
 
 Prompt cap: 6,000; put detail in `.agents/skills/*`.
 
-Before building common workspace or agent UI, read `agent-native-toolkit`; use
-`customizing-agent-native` for the configure → compose → eject → propose
-ladder.
+Before building common workspace or agent UI, read `agent-native-toolkit` to
+discover existing primitives and patterns. Read `customizing-agent-native`
+before adapting shared UI: configure → compose → eject → propose.
 
 ## How To Answer A Data Question
 
-1. **Search existing work first.** Call `search-analytics-query-catalog` before
-   writing a query. Adapt the closest saved SQL to the requested filters and
-   window, run it once, and stop.
-2. **One bounded call.** List, filter, count, and cohort questions ("which X,
-   excluding Y") are a single SQL statement, or one `run-code` script that
-   filters server-side. Never page through a cohort or fan out per item to apply
-   a filter.
-3. **Escalate only on a miss.** If the catalog returns nothing usable, make at
-   most one discovery pass (`list-data-dictionary`, `search-bigquery-schema`,
-   `data-source-status`), then query. Don't cross-check or add breakdowns
-   nobody asked for.
-4. **Answer in chat.** Give the result directly with a short table or inline
-   chart — never deflect to "check the dashboard." Keep native data widgets to
-   already-summarized data (≤50 rows); above that, state the total and show the
-   top rows.
-5. **Deliver exports in chat.** See `analysis-workspace`; never return only a
-   path or tell the user to find a download elsewhere.
-6. **Chunk only for reading.** Group into 5-10 with per-item notes only when 30+
-   items each need qualitative reading no query can do (call transcripts, ticket
-   threads). Chunking a question a query could answer is the most expensive
-   mistake available here. See `adhoc-analysis`.
+1. **Search existing work first.** Call `search-analytics-query-catalog`, adapt
+   the closest saved SQL to the requested filters/window, run it once, and stop.
+2. **One bounded call.** List/filter/count/cohort questions are one SQL statement
+   or one server-side `run-code` script; never page or fan out per item.
+3. **Escalate on a miss.** If the catalog has no usable result, make one discovery
+   pass (`list-data-dictionary`, `search-bigquery-schema`, `data-source-status`),
+   then query; don't cross-check or add unasked breakdowns.
+4. **Answer in chat.** Return a short table or inline chart, not a dashboard
+   pointer. Native widgets show summarized data (≤50 rows); above that, state the
+   total and top rows.
+5. **Deliver exports in chat.** See `analysis-workspace`; don't return only a path.
+6. **Chunk only reading.** Group 5-10 only for 30+ qualitative items when a query
+   cannot answer; don't chunk queryable questions. See `adhoc-analysis`.
 
 ## Core Rules
 
-- A sibling app asking over A2A sends a question or shaped input, never SQL. It
-  lacks this app's schema, data dictionary, dashboards, and dialect knowledge,
-  so raw-query actions (`sql`, `code`, `script`, `expression`) are not
-  sibling-invocable. Prefer natural-language delegation so this app retains its
-  instructions, source selection, and tools. Shaped reads are stable contracts,
-  not workarounds for delegation; this app still owns the query.
+- A sibling app asking over A2A sends a question or shaped input, never SQL.
+  Raw-query actions (`sql`, `code`, `script`, `expression`) are not
+  sibling-invocable because this app owns schema, source selection, and tools.
+  Prefer natural-language delegation; shaped reads are stable contracts, not
+  delegation workarounds.
 - For open-ended delegated requests, choose a safe default and label partial.
 - Data integrity first. Never invent numbers, dimensions, filters, or source
   semantics; only present values you actually retrieved, and state uncertainty.
@@ -54,9 +45,15 @@ ladder.
   access checks with raw SQL for ownable resources.
 - Provider actions are bounded shortcuts, not limits. For broad or
   absence-sensitive Gong work, stage raw API data and use
-  `query-staged-dataset` or a Data Program; if raw transcript bodies are
-  required, use `provider-corpus-job`. See `provider-api`, `data-programs`, and
-  `gong`.
+  `query-staged-dataset` or a Data Program; use `provider-corpus-job` for raw
+  transcript bodies. See `provider-api`, `data-programs`, and `gong`.
+- Custom APIs use the `provider-api-register` action for public HTTPS provider
+  metadata and `test-custom-api-connection` for bounded GET previews. Store
+  credential values in Settings, pass only key names to provider actions, and
+  hand successful endpoint tests to `save-data-program` for refreshable panels.
+- Hosted Analytics cannot reach localhost or private network APIs. Use a
+  deployed HTTPS endpoint or an explicitly supported secure tunnel; never
+  weaken the provider runtime's SSRF boundary.
 - Create dashboards, panels, or saved artifacts only when explicitly asked;
   suggest and wait otherwise. Scope them to the question, avoid decorative
   metrics, and never modify existing dashboards without a directive.

package/corpus/templates/analytics/actions/ensure-native-v2-dashboards.ts

@@ -235,7 +235,7 @@ export async function ensureNativeV2Dashboards(
 
 export default defineAction({
   description:
-    "Provision the four reusable native Analytics v2 dashboard patterns for the active organization from explicit Data Program bindings. " +
+    "Provision the reusable native Analytics v2 dashboard patterns, including On Demand Billing, for the active organization from explicit Data Program bindings. " +
     "This is an admin-only post-deploy action: it validates every program exists and exposes the manifest's required output columns, shares the bound programs with the organization, creates deterministic native-* dashboard copies, and never changes the legacy extension dashboards. " +
     "Re-running preserves existing v2 dashboard edits unless overwrite=true.",
   schema: z.object({

package/corpus/templates/analytics/actions/list-dashboard-usage-stats.ts

@@ -1,4 +1,5 @@
 import { defineAction } from "@agent-native/core/action";
+import { isPostgres } from "@agent-native/core/db";
 import { buildDeepLink } from "@agent-native/core/server";
 import { and, eq, isNull, like, or, sql } from "drizzle-orm";
 import { z } from "zod";
@@ -40,24 +41,8 @@ function toNumber(value: unknown): number {
   return 0;
 }
 
-function parseConfig(value: unknown): Record<string, unknown> {
-  if (value && typeof value === "object" && !Array.isArray(value)) {
-    return value as Record<string, unknown>;
-  }
-  if (typeof value !== "string") return {};
-  try {
-    const parsed = JSON.parse(value);
-    return parsed && typeof parsed === "object" && !Array.isArray(parsed)
-      ? parsed
-      : {};
-  } catch {
-    return {};
-  }
-}
-
-function dashboardName(row: { title: string; config: unknown }): string {
-  const config = parseConfig(row.config);
-  const configName = config.name;
+function dashboardName(row: { title: string; configName: unknown }): string {
+  const configName = row.configName;
   if (typeof configName === "string" && configName.trim()) {
     return configName.trim();
   }
@@ -66,11 +51,10 @@ function dashboardName(row: { title: string; config: unknown }): string {
 
 function dashboardPanelCount(row: {
   kind: string;
-  config: unknown;
+  panelCount: unknown;
 }): number | null {
   if (row.kind !== "sql") return null;
-  const panels = parseConfig(row.config).panels;
-  return Array.isArray(panels) ? panels.length : 0;
+  return toNumber(row.panelCount);
 }
 
 export function dashboardIdFromPath(path: string | null): string | null {
@@ -143,6 +127,16 @@ export default defineAction({
   run: async (_args, ctx) => {
     const admin = await requireDbAdminContextFromRequest(ctx);
     const db = getDb() as any;
+    const configName = isPostgres()
+      ? sql<string | null>`(${schema.dashboards.config}::jsonb ->> 'name')`
+      : sql<string | null>`json_extract(${schema.dashboards.config}, '$.name')`;
+    const panelCount = isPostgres()
+      ? sql<
+          number | null
+        >`CASE WHEN ${schema.dashboards.kind} = 'sql' AND jsonb_typeof(${schema.dashboards.config}::jsonb -> 'panels') = 'array' THEN jsonb_array_length(${schema.dashboards.config}::jsonb -> 'panels') ELSE 0 END`
+      : sql<
+          number | null
+        >`CASE WHEN ${schema.dashboards.kind} = 'sql' AND json_type(json_extract(${schema.dashboards.config}, '$.panels')) = 'array' THEN json_array_length(json_extract(${schema.dashboards.config}, '$.panels')) ELSE 0 END`;
 
     // guard:allow-unscoped — org owner/admin audit intentionally spans all
     // dashboard rows in the active org after requireDbAdminContextFromRequest.
@@ -151,7 +145,8 @@ export default defineAction({
         id: schema.dashboards.id,
         kind: schema.dashboards.kind,
         title: schema.dashboards.title,
-        config: schema.dashboards.config,
+        configName,
+        panelCount,
         ownerEmail: schema.dashboards.ownerEmail,
         visibility: schema.dashboards.visibility,
         createdAt: schema.dashboards.createdAt,