@agent-native/core 0.141.5 → 0.141.7

package/corpus/README.md

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

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

@@ -715,15 +715,9 @@ state or tracker context, but docs traffic is not app usage and should not appea
 as an app/template series. Use a minimum cohort-size threshold for retention
 rates so one or two identities cannot create misleading 100% or 0% spikes.
 
-## Template Catalog And Demo Dashboards
+## Demo Dashboards
 
-`list-dashboard-templates` / `install-dashboard-template` install shipped
-dashboard templates (Node Exporter, the canonical Agent Native observability
-dashboard, etc.), and `ensure-demo-dashboards` auto-installs a per-user demo
-on first app open. See
-`references/template-catalog-and-demo.md` for the canonical-dashboard panel
-rule, Node Exporter template specifics, and the full demo-dashboard lifecycle
-(source routing, env var overrides, tombstoning, reset).
+`ensure-demo-dashboards` auto-installs a per-user demo on first app open.
 
 ## Building Large First-Party Dashboards (compose-dashboard)
 
@@ -758,21 +752,16 @@ Hosted agent runs have a **~40s budget**. Many sequential `update-dashboard` cal
   - To make nested config edits, use
     `setConfigPath("yAxis.format", "percent")` instead of resending/clobbering
     the whole nested object.
-- **To add a shipped template's panels, prefer `install-dashboard-template` with `mergePanels: true`** and the existing `dashboardId`. It appends only the template panels whose id is not already present (preserving existing panels and order) in one atomic save — you don't author each panel yourself.
 - **Always verify the returned proof-of-done and report it.**
   `mutate-dashboard` returns `panelCount`, `appliedOps`, `panelOrder`,
   `firstPanelIds`, `changedPanelIds`, `commandLog`, and a `summary` string.
-  `install-dashboard-template --mergePanels` returns `addedPanelIds`,
-  `skippedExistingIds`, and `panelCount`. Tell the user the resulting panel
-  count instead of assuming success.
+  Tell the user the resulting panel count instead of assuming success.
 
 ```bash
 # Add or edit several panels in ONE atomic call (never one call per panel)
 pnpm action mutate-dashboard --dashboardId weekly-metrics \
   --code 'dashboard.panelsMatching({"source":"first-party"}).setWidth(2);'
 
-# Append a template's panels to an existing dashboard in one call
-pnpm action install-dashboard-template --templateId skills-cli-funnel --dashboardId weekly-metrics --mergePanels true
 ```
 
 ## Archiving vs deleting

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

@@ -22,18 +22,30 @@ For events recorded by the analytics template itself via its `/track` endpoint,
 
 For first-party counts, active-user, and retention questions, prefer the compact
 tenant-scoped daily event and user-day rollups. Use `analytics_events` only for a
-bounded recent drill-down with an explicit date/time range; the built-in source
-does not require a customer warehouse connection.
+bounded recent drill-down with an explicit date/time range. For the Builder.io
+production organization after the BigQuery cutover, these logical tables are
+served by partitioned BigQuery data and views; the source still does not require
+an end user's separate warehouse connection.
 
 Before a large or historical first-party query, call
 `get-first-party-analytics-health`. Keep Neon as the default while its status is
 `healthy` or `monitor`; a `recommend_bigquery` result means the app has observed
-1M+ events, repeated slow queries, or a timeout/30-second query. If BigQuery is
-not configured, use the returned setup link or `data-source-status --key
-bigquery` to guide the user through the existing Data Sources walkthrough. Do
-not silently move the collector: `/track` still lands in first-party Analytics,
-and BigQuery is the opt-in backend for high-volume or historical analysis after
-the user connects it.
+1M+ events, repeated slow queries, or a timeout/30-second query. Treat that
+status as a compatibility name for an external-backend recommendation, not as
+a requirement to use BigQuery. The health result lists the supported options:
+
+- BigQuery for warehouse SQL and complete historical analysis.
+- Amplitude for product analytics, funnels, and retention.
+
+If a suitable backend is not configured, use its returned setup link or
+`data-source-status --key <provider>` to guide the user through the existing
+Data Sources walkthrough. Connecting a query backend alone does not move the
+collector or copy existing Neon events. For the Builder.io production
+organization, the hidden `migrate-first-party-analytics-to-bigquery` action is
+the explicit state machine: prepare dual-write, backfill with its cursor, then
+cut over with confirmation. After cutover, `/track` writes and event queries
+use BigQuery; public-key metadata, derived exception issues, and session-replay
+data remain in SQL.
 
 Example pageviews query for a local calendar day:
 

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

@@ -59,12 +59,10 @@ When a query fans out into many series, the `series` column will hold a `metric_
 
 ## Node Exporter dashboards
 
-Node Exporter dashboards are installed from the dashboard catalog:
+Use `list-sql-dashboards` to find an existing Node Exporter dashboard, then use
+`update-dashboard` to create or repair one from the supported panel definitions:
 
 ```bash
-pnpm action list-dashboard-templates
-pnpm action install-dashboard-template --templateId=node-exporter-macos
-pnpm action install-dashboard-template --templateId=node-exporter-full
 ```
 
 `node-exporter-macos` is the comprehensive Darwin/Homebrew dashboard for macOS scrapes; it covers CPU, load, macOS memory fields, swap, APFS filesystems, disk IO, network devices, battery/power, scrape health, exporter process stats, Go runtime stats, and a metric-family coverage table. `node-exporter-full` is converted from Grafana dashboard 1860 revision 45 and lives at `seeds/dashboards/node-exporter-full.json`; it contains 124 Prometheus query panels, 16 section dividers, and native tabs for Overview, CPU & Memory, System, Storage, Network, and Exporter. The Full dashboard is Linux-focused because Grafana 1860 expects Linux collectors such as `node_memory_MemAvailable_bytes`, pressure stall information, `node_sockstat_*`, `node_netstat_*`, `node_timex_*`, `node_systemd_*`, and `node_hwmon_*`; Homebrew/macOS node_exporter omits many of those, so empty panels on macOS are expected. The templates use `job`, `instance`, and `range` filters; set `instance` to the Prometheus `instance` label from `node_uname_info`.
@@ -92,7 +90,9 @@ scrape_configs:
 brew services restart prometheus    # Prometheus UI at http://localhost:9090
 ```
 
-Paste `http://localhost:9090` as the Prometheus URL in Data Sources, then install the desired Node Exporter dashboard from Catalog.
+Paste `http://localhost:9090` as the Prometheus URL in Data Sources, then use
+`list-sql-dashboards` and `update-dashboard` to manage the desired Node Exporter
+dashboard.
 
 ## Incident Investigation Pattern
 

package/corpus/templates/analytics/AGENTS.md

@@ -81,7 +81,7 @@ ladder.
 ## Application State
 
 - `navigation` exposes the current dashboard, analysis, source, chart, and
-  selection. `navigate` moves the user, including `view="catalog"`,
+  selection. `navigate` moves the user between supported Analytics surfaces,
   `"sessions"`, `"monitoring"`, and `"agents"`. Use `view-screen` when the
   active context is unclear.
 - Clicking a panel stages it as a chat context chip and writes `selected-object`
@@ -97,7 +97,7 @@ Read the relevant skill before deeper work:
 - `cross-source-analysis` for questions spanning sources (identity stitching,
   de-duplication).
 - `dashboard-management` for dashboard/panel storage, layout, extensions,
-  mutation, sharing, and the template catalog.
+  mutation and sharing.
 - `adhoc-analysis` and `analysis-workspace` for one-off answers and large
   multi-source work.
 - `provider-api` and `data-programs` for the escape hatch and durable,

package/corpus/templates/analytics/actions/compose-dashboard.ts

@@ -29,7 +29,7 @@ import {
 
 /**
  * Push the saved config through the collab layer so open dashboard editors get
- * the change in real time (mirrors update-dashboard / install-dashboard-template).
+ * the change in real time (mirrors update-dashboard).
  */
 async function syncToCollab(
   dashboardId: string,

package/corpus/templates/analytics/actions/get-first-party-analytics-health.ts

@@ -19,6 +19,17 @@ function resolveScope() {
 const healthSchema = z.object({
   status: z.enum(["healthy", "monitor", "recommend_bigquery", "unavailable"]),
   recommendation: z.enum(["none", "connect_bigquery", "use_bigquery"]),
+  externalBackendRecommendation: z.enum(["none", "connect", "use", "unknown"]),
+  externalBackends: z.array(
+    z.object({
+      id: z.enum(["bigquery", "amplitude"]),
+      label: z.string(),
+      role: z.enum(["warehouse", "product-analytics"]),
+      configured: z.boolean().nullable(),
+      missingRequiredKeys: z.array(z.string()),
+      setupLink: z.string(),
+    }),
+  ),
   reasons: z.array(z.enum(["event_volume", "slow_queries", "query_timeout"])),
   observedAt: z.string(),
   metrics: z.object({
@@ -39,6 +50,9 @@ const healthSchema = z.object({
     recommendMaxQueryMs: z.number(),
   }),
   bigQuery: z.object({
+    id: z.literal("bigquery"),
+    label: z.string(),
+    role: z.literal("warehouse"),
     configured: z.boolean().nullable(),
     missingRequiredKeys: z.array(z.string()),
     setupLink: z.string(),
@@ -47,7 +61,7 @@ const healthSchema = z.object({
 
 export default defineAction({
   description:
-    "Check whether the built-in first-party Analytics source is still a good fit for Neon/Postgres. Use this before recommending BigQuery for tracking data. It reads compact daily rollups and the small slow-query pressure ledger, never the raw event table. `healthy` means Neon is fine, `monitor` means keep Neon but watch growth, and `recommend_bigquery` means connect or use BigQuery for high-volume or historical queries. A recommendation is based on 1M+ observed events, three or more slow queries in 24 hours, or any query timeout/30-second query. The result also includes BigQuery credential status and a safe setup link without revealing credential values.",
+    "Check whether the built-in first-party Analytics source is still a good fit for Neon/Postgres. Use this before a large or historical query. It reads compact daily rollups and the small slow-query pressure ledger, never the raw event table. `healthy` means Neon is fine, `monitor` means keep Neon but watch growth, and `recommend_bigquery` means use a configured external analytics backend for high-volume or historical queries. The result reports the two supported external options with safe setup links: BigQuery for warehouse SQL and history, and Amplitude for product analytics, funnels, and retention. A recommendation is based on 1M+ observed events, three or more slow queries in 24 hours, or any query timeout/30-second query. Connecting a backend does not silently reroute `/track` events or backfill existing Neon events.",
   schema: z.object({}),
   outputSchema: healthSchema,
   http: { method: "GET" },

package/corpus/templates/analytics/actions/migrate-first-party-analytics-to-bigquery.ts

@@ -0,0 +1,135 @@
+import { defineAction } from "@agent-native/core";
+import {
+  getRequestOrgId,
+  getRequestUserEmail,
+} from "@agent-native/core/server";
+import { z } from "zod";
+
+import { requireAnalyticsAdminContext } from "../server/lib/db-admin-connections.js";
+import {
+  assertFirstPartyAnalyticsBigQueryReady,
+  backfillFirstPartyAnalyticsBatch,
+  getFirstPartyAnalyticsBackend,
+  saveFirstPartyAnalyticsBackend,
+} from "../server/lib/first-party-analytics-backend.js";
+
+async function resolveScope() {
+  const userEmail = getRequestUserEmail();
+  if (!userEmail) throw new Error("no authenticated user");
+  const orgId = getRequestOrgId();
+  if (!orgId) {
+    throw new Error(
+      "An active organization is required for the first-party Analytics migration.",
+    );
+  }
+  const admin = await requireAnalyticsAdminContext({ userEmail, orgId });
+  return { userEmail: admin.userEmail, orgId: admin.orgId };
+}
+
+const migrationSchema = z.object({
+  mode: z.enum(["status", "prepare", "backfill", "cutover"]),
+  table: z
+    .string()
+    .trim()
+    .optional()
+    .describe(
+      "Optional BigQuery table reference as dataset.table or project.dataset.table. The default is <BIGQUERY_PROJECT_ID>.analytics.first_party_analytics_events_raw.",
+    ),
+  cursor: z.string().trim().optional(),
+  limit: z.number().int().min(1).max(500).optional(),
+  confirm: z.boolean().optional(),
+});
+
+export default defineAction({
+  description:
+    "UI-only production migration for the current Analytics organization. Run prepare to validate the configured BigQuery table and enter dual-write mode, call backfill repeatedly with the returned cursor until complete, then call cutover with confirm=true. New /track events stay in Postgres during dual-write, so a BigQuery outage does not silently lose live data. Cutover is the only step that stops analytics event and rollup writes to Postgres; public-key metadata, derived exception issues, and session-replay data remain in the SQL store.",
+  schema: migrationSchema,
+  agentTool: false,
+  needsApproval: ({ mode }) => mode === "cutover",
+  run: async ({ mode, table, cursor, limit, confirm }) => {
+    const scope = await resolveScope();
+    const current = await getFirstPartyAnalyticsBackend(scope);
+    const configuredTable = table ?? current.table;
+
+    if (mode === "status") {
+      const ready =
+        current.sink === "postgres"
+          ? null
+          : await assertFirstPartyAnalyticsBigQueryReady(current.table);
+      return {
+        ...current,
+        ready: Boolean(ready),
+        rowCount: ready?.rowCount ?? null,
+        table: ready?.table.fullyQualified ?? current.table,
+      };
+    }
+
+    if (mode === "prepare") {
+      const ready =
+        await assertFirstPartyAnalyticsBigQueryReady(configuredTable);
+      await saveFirstPartyAnalyticsBackend(scope, {
+        sink: "dual",
+        table: ready.table.fullyQualified,
+        backfillCursor: null,
+        backfillCompleted: false,
+      });
+      return {
+        sink: "dual" as const,
+        table: ready.table.fullyQualified,
+        existingBigQueryRows: ready.rowCount,
+        next: "backfill",
+      };
+    }
+
+    if (mode === "backfill") {
+      if (current.sink !== "dual") {
+        throw new Error(
+          "Prepare the organization for dual-write before starting the BigQuery backfill.",
+        );
+      }
+      const result = await backfillFirstPartyAnalyticsBatch(
+        scope,
+        cursor ?? current.backfillCursor ?? null,
+        limit ?? 500,
+        current.table,
+      );
+      await saveFirstPartyAnalyticsBackend(scope, {
+        sink: "dual",
+        table: current.table,
+        backfillCursor: result.nextCursor,
+        backfillCompleted: result.complete,
+      });
+      return {
+        ...result,
+        sink: "dual" as const,
+        table: current.table,
+        next: result.complete ? "cutover" : "backfill",
+      };
+    }
+
+    if (!confirm) {
+      throw new Error(
+        "Cutover requires confirm=true because it stops first-party event and rollup writes to Postgres for this organization.",
+      );
+    }
+    if (current.sink !== "dual" || current.backfillCompleted !== true) {
+      throw new Error(
+        "Complete the dual-write backfill before cutting over to BigQuery.",
+      );
+    }
+    const ready = await assertFirstPartyAnalyticsBigQueryReady(current.table);
+    await saveFirstPartyAnalyticsBackend(scope, {
+      sink: "bigquery",
+      table: ready.table.fullyQualified,
+      backfillCursor: current.backfillCursor,
+      backfillCompleted: true,
+    });
+    return {
+      sink: "bigquery" as const,
+      table: ready.table.fullyQualified,
+      existingBigQueryRows: ready.rowCount,
+      postgresEventWrites: "stopped",
+      next: "verify dashboards",
+    };
+  },
+});

package/corpus/templates/analytics/actions/navigate.ts

@@ -50,7 +50,7 @@ export default defineAction({
       .string()
       .optional()
       .describe(
-        "View to navigate to (ask, adhoc, analyses, extensions, sessions, monitoring, agents, catalog, data-dictionary, data-sources, settings)",
+        "View to navigate to (ask, adhoc, analyses, extensions, sessions, monitoring, agents, data-dictionary, data-sources, settings)",
       ),
     dashboardId: z
       .string()

package/corpus/templates/analytics/actions/query-agent-native-analytics.ts

@@ -15,12 +15,12 @@ function resolveScope() {
 
 export default defineAction({
   description:
-    "Query the built-in first-party Analytics source: events recorded through this app's analytics collector endpoint (/track), compact daily rollups, identifiable user-day rollups, and session replay summaries recorded through /api/analytics/replay. This source does not require an external provider connection. Use it for questions about app/site traffic, product events, template/app usage, conversions, session recordings, LLM/agent observability, model cost, token volume, latency, and other first-party data collected by this analytics app. Use source-specific actions such as BigQuery, GA4, Mixpanel, PostHog, or Amplitude when the user asks for those sources or the relevant data lives there. SQL may read analytics_events, analytics_event_daily_rollups, analytics_user_days, and session_recordings; session_replay_chunks is intentionally unavailable, and reads are automatically scoped to the current user/org. Prefer analytics_event_daily_rollups for event counts and analytics_user_days for active-user or retention questions. The rollups are backfilled from existing analytics_events when this schema is upgraded and are updated transactionally with new ingest. Use analytics_events only for bounded recent drill-downs with an explicit event_date or timestamp range. Aggregate, project only needed columns, and add a LIMIT for raw or high-cardinality reads; do not issue an unbounded raw-event scan or paginate a large cohort. An explicit all-time or lifetime request remains all-time, so do not invent a default lower time bound. Safe scoped results are cached for up to five minutes for this agent action. analytics_events columns include event_name, timestamp, event_date, user_id, anonymous_id, user_key, session_id, app, template, signed_in, url, path, hostname, referrer, properties, and context. analytics_event_daily_rollups columns include tenant_key, owner_email, org_id, event_date, event_name, app, template, and event_count. analytics_user_days columns include tenant_key, owner_email, org_id, event_date, and user_key. LLM observability events use event_name = '$ai_generation'; useful properties include $ai_trace_id/run_id, $ai_session_id/thread_id, $ai_model/model, $ai_provider/provider, $ai_input_tokens/input_tokens, $ai_output_tokens/output_tokens, cache_read_tokens, cache_write_tokens, cost_cents_x100, $ai_total_cost_usd/cost_usd, duration_ms/$ai_latency, status, tool_calls, successful_tools, failed_tools, tools, tools_truncated, delegated, delegation_protocol, caller_app, delegation_task_id, a2a_task_id, parent_run_id, parent_turn_id, and error_message/$ai_error. Agent Teams child runs use delegation_protocol = 'agent-team' and retain their own run_id while linking to the launching run through parent_run_id. The bounded tools array contains names, relative start times, durations, statuses, and coarse error classes only, never args or results; failed runs and interrupted tools remain queryable. session_recordings columns include id, session_id, user_id, anonymous_id, user_key, started_at, ended_at, duration_ms, chunk_count, event_count, page_count, error_count, rage_click_count, app, template, status, first_url, last_url, path, hostname, referrer, and metadata.",
+    "Query the built-in first-party Analytics source: events recorded through this app's analytics collector endpoint (/track), compact daily rollups updated transactionally with new ingest, identifiable user-day rollups, and session replay summaries recorded through /api/analytics/replay. This source does not require an external provider connection. Use it for questions about app/site traffic, product events, template/app usage, conversions, session recordings, LLM/agent observability, model cost, token volume, latency, and other first-party data collected by this analytics app. Use source-specific actions such as BigQuery, GA4, Mixpanel, PostHog, or Amplitude when the user asks for those sources or the relevant data lives there. SQL may read analytics_events, analytics_event_daily_rollups, analytics_user_days, and session_recordings; session_replay_chunks is intentionally unavailable, and reads are automatically scoped to the current user/org. Prefer analytics_event_daily_rollups for event counts and analytics_user_days for active-user or retention questions. On the Builder.io production organization after the explicit BigQuery cutover, event and rollup reads use partitioned BigQuery tables/views while session_recordings remains in the SQL store; cross-backend joins are not supported. Before a large or historical query, call get-first-party-analytics-health and use a configured external backend when it recommends one: BigQuery supports warehouse SQL and historical analysis, while Amplitude supports product analytics, funnels, and retention. Connecting a backend does not automatically reroute /track events or copy existing Neon events; the migration action performs that explicit prepare, backfill, and cutover sequence. Aggregate, project only needed columns, use bounded recent drill-downs, and add a LIMIT for raw or high-cardinality reads; do not issue an unbounded raw-event scan or paginate a large cohort. An explicit all-time or lifetime request remains all-time, so do not invent a default lower time bound. Safe scoped results are cached for up to five minutes for this agent action. analytics_events columns include event_name, timestamp, event_date, user_id, anonymous_id, user_key, session_id, app, template, signed_in, url, path, hostname, referrer, properties, and context. analytics_event_daily_rollups columns include tenant_key, owner_email, org_id, event_date, event_name, app, template, and event_count. analytics_user_days columns include tenant_key, owner_email, org_id, event_date, and user_key. LLM observability events use event_name = '$ai_generation'; useful properties include $ai_trace_id/run_id, $ai_session_id/thread_id, $ai_model/model, $ai_provider/provider, $ai_input_tokens/input_tokens, $ai_output_tokens/output_tokens, cache_read_tokens, cache_write_tokens, cost_cents_x100, $ai_total_cost_usd/cost_usd, duration_ms/$ai_latency, status, tool_calls, successful_tools, failed_tools, tools, tools_truncated, delegated, delegation_protocol, caller_app, delegation_task_id, a2a_task_id, parent_run_id, parent_turn_id, and error_message/$ai_error. Agent Teams child runs use delegation_protocol = 'agent-team' and retain their own run_id while linking to the launching run through parent_run_id. The bounded tools array contains names, relative start times, durations, statuses, and coarse error classes only, never args or results; failed runs and interrupted tools remain queryable. session_recordings columns include id, session_id, user_id, anonymous_id, user_key, started_at, ended_at, duration_ms, chunk_count, event_count, page_count, error_count, rage_click_count, app, template, status, first_url, last_url, path, hostname, referrer, and metadata.",
   schema: z.object({
     sql: z
       .string()
       .describe(
-        "Read-only SQL over analytics_events, analytics_event_daily_rollups, analytics_user_days, and session_recordings. Use literal values, not bind placeholders. Prefer the daily rollups for counts, active-user, and retention questions. For raw analytics_events reads, use an explicit event_date or timestamp range, aggregate or project only needed columns, and add a LIMIT; do not issue an unbounded raw-event scan or paginate a large cohort. An explicit all-time or lifetime request remains all-time, so do not invent a default lower time bound. Example: SELECT event_date, event_name, SUM(event_count) AS events FROM analytics_event_daily_rollups WHERE event_date >= '2026-05-01' AND event_date < '2026-06-01' GROUP BY event_date, event_name ORDER BY event_date, events DESC",
+        "Read-only SQL over analytics_events, analytics_event_daily_rollups, analytics_user_days, and session_recordings. Use literal values, not bind placeholders. Prefer the daily rollups for counts, active-user, and retention questions. On the Builder.io production organization after the explicit BigQuery cutover, event and rollup reads use partitioned BigQuery tables/views while session_recordings remains in the SQL store; cross-backend joins are not supported. Before a large or historical query, call get-first-party-analytics-health and use a configured external backend when recommended: BigQuery for warehouse SQL and complete history, or Amplitude for product analytics, funnels, and retention. Connecting one does not automatically reroute /track events or backfill existing Neon data; the migration action performs that explicit prepare, backfill, and cutover sequence. Aggregate or project only needed columns and add a LIMIT for raw or high-cardinality reads; do not issue an unbounded raw-event scan or paginate a large cohort. An explicit all-time or lifetime request remains all-time, so do not invent a default lower time bound. Example: SELECT event_date, event_name, SUM(event_count) AS events FROM analytics_event_daily_rollups WHERE event_date >= '2026-05-01' AND event_date < '2026-06-01' GROUP BY event_date, event_name ORDER BY event_date, events DESC",
       ),
   }),
   outputSchema: z.object({

package/corpus/templates/analytics/actions/update-dashboard.ts

@@ -576,7 +576,6 @@ export default defineAction({
     "Do not use `ops` or `panelOrder` for ordinary agent edits like moving charts, adding panels to an existing dashboard, changing widths, or updating panel config; call `mutate-dashboard` once with the full edit script. " +
     "When this action is appropriate, provide only one of `ops`, `panelOrder`, or `config`; `config` replaces the whole dashboard config. " +
     "First-party event panels must bind to a declared dashboard time filter with `{{timeRange}}` or date-range variables. Intentional fixed-window, cohort-history, and all-time exceptions must be explicit in `panel.config.timeScope`; unbounded first-party SQL is rejected at save time. " +
-    "To add a shipped catalog template's panels to an existing dashboard, prefer `install-dashboard-template` with `mergePanels: true` — it appends the template's panels in one call without you having to author each panel. " +
     "The result is compact by default: `panelCount`, `appliedOps`, `panelOrder`, `firstPanelIds`, and `summary`. Set `returnConfig: true` only when you truly need the full config in the tool result. " +
     "The UI auto-refreshes after this action — do NOT call `refresh-screen`.",
   schema: z.object({

package/corpus/templates/analytics/actions/view-screen.ts

@@ -7,7 +7,6 @@ import {
 import { z } from "zod";
 
 import { listAnalyticsAlertRules } from "../server/lib/analytics-alerts";
-import { listDashboardCatalog } from "../server/lib/dashboard-catalog";
 import { getAnalysis, getDashboard } from "../server/lib/dashboards-store";
 import { getErrorIssue, listErrorIssues } from "../server/lib/error-capture.js";
 import { listAnalyticsPublicKeys } from "../server/lib/first-party-analytics.js";
@@ -391,25 +390,6 @@ export default defineAction({
           })),
         };
       }
-    } else if (nav?.view === "catalog") {
-      screen.page = "catalog";
-      const email = getRequestUserEmail();
-      if (email) {
-        const catalog = await listDashboardCatalog({
-          email,
-          orgId: getRequestOrgId() || null,
-        });
-        screen.dashboardTemplates = catalog.map((template) => ({
-          id: template.id,
-          name: template.name,
-          category: template.category,
-          dataSources: template.dataSources,
-          installed: template.installed,
-          installedDashboardIds: template.installedDashboards.map(
-            (dashboard) => dashboard.id,
-          ),
-        }));
-      }
     } else if (nav?.view === "agents") {
       screen.page = "agents";
       screen.agentsView = nav?.agentsView || "monitoring";

package/corpus/templates/analytics/app/components/layout/Header.tsx

@@ -17,7 +17,6 @@ const pageTitleKeys: Record<string, string> = {
   "/ask": "navigation.ask",
   "/data-sources": "navigation.dataSources",
   "/data-dictionary": "navigation.dataDictionary",
-  "/catalog": "navigation.templateCatalog",
   "/analyses": "navigation.analyses",
   "/sessions": "navigation.sessions",
   "/monitoring": "navigation.monitoring",

package/corpus/templates/analytics/app/hooks/use-navigation-state.ts

@@ -98,9 +98,10 @@ export function useNavigationState() {
         state.view = "data-sources";
       } else if (pathname === "/data-dictionary") {
         state.view = "data-dictionary";
-      } else if (pathname === "/catalog") {
-        state.view = "catalog";
-      } else if (pathname === "/settings") {
+      } else if (
+        pathname === "/settings" ||
+        pathname.startsWith("/settings/")
+      ) {
         state.view = "settings";
       }
 
@@ -114,7 +115,7 @@ export function useNavigationState() {
       if (cmd.view === "analyses") return "/dashboards";
       if (cmd.view === "extensions" && cmd.extensionId)
         return `/extensions/${cmd.extensionId}`;
-      if (cmd.view === "extensions") return "/settings#extensions";
+      if (cmd.view === "extensions") return "/settings/extensions";
       if (cmd.view === "sessions" && cmd.recordingId)
         return `/sessions/${encodeURIComponent(cmd.recordingId)}`;
       if (cmd.view === "sessions") return "/sessions";
@@ -146,7 +147,6 @@ export function useNavigationState() {
       }
       if (cmd.view === "data-sources") return "/data-sources";
       if (cmd.view === "data-dictionary") return "/data-dictionary";
-      if (cmd.view === "catalog") return "/catalog";
       if (cmd.view === "ask") return "/ask";
       if (cmd.view === "settings") return "/settings";
       if (cmd.view === "overview" || cmd.view === "home") return "/ask";