@agent-native/core 0.147.0 → 0.148.0

package/corpus/README.md

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

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

@@ -2,16 +2,19 @@
 name: frontend-design
 description: >-
   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.
+  quality that avoids generic AI aesthetics. Use when building, redesigning, or
+  cleaning up any user-facing UI, including screenshot-driven feedback, copy or
+  density reduction, settings, control placement, or a design pass ("make this
+  look good"). Do not load it only for purely mechanical wiring or formatting.
 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.
+  Description deliberately widened on 2026-08-09 because the previous narrow
+  trigger excluded routine UI edits, including screenshot-driven cleanup, copy
+  and density changes, settings, and control placement. An upstream sync must
+  not re-narrow it. Verification remains deliberately rescoped; an upstream
+  sync must not restore screenshot-everything or broad browser-automation steps.
 metadata:
   internal: true
 ---
@@ -26,10 +29,12 @@ The user may ask for a component, page, full app, dashboard, marketing surface,
 
 Before coding, decide:
 
-- **Purpose**: What workflow does this surface make easier? What is the primary action?
+- **Purpose**: What workflow does this surface make easier? What does the user
+  need to understand, decide, or do next?
 - **Audience**: Who will use it repeatedly, and what should feel fast, calm, playful, premium, editorial, technical, or utilitarian?
 - **Tone**: Choose a concrete aesthetic direction: refined minimal, dense operations console, editorial, playful, industrial, warm handmade, high-contrast data tool, etc.
-- **Information hierarchy**: What must be visible in the first five seconds, and what should be progressively disclosed?
+- **Information hierarchy**: What must be visible to orient and act, and what
+  can wait until context or intent makes it relevant?
 - **Differentiation**: What makes this feel designed for this exact domain?
 
 Then implement working code that is cohesive, accessible, responsive, and polished in small details: typography, spacing, copy, motion, empty states, loading states, focus states, and error states.
@@ -50,46 +55,80 @@ before selecting its accent family. Shared behavior and semantic token names
 should stay consistent; palette, density, composition, type contrast, and
 shape language should not be identical by default.
 
-## Minimalism And Progressive Disclosure
-
-Default to Apple/Linear-level restraint: make the primary workflow obvious, then remove everything that does not help that workflow right now. A polished UI often has fewer visible controls, fewer borders, fewer labels, and fewer explanatory surfaces than the first reasonable implementation.
-
-### Progressive Disclosure Is A Design Requirement
-
-Treat an all-at-once interface as a defect to fix during design, not as a
-styling preference. Before coding, inventory every piece of content and action
-on the surface, then assign each one to the smallest useful visibility level:
-
-1. **Immediate** — the page title, current state, one primary action, and the
-   compact context needed to choose what to do next.
-2. **Expanded** — the details needed for the selected item or active workflow.
-3. **On demand** — advanced settings, diagnostics, credentials, metadata,
-   destructive actions, documentation, and rarely used tools.
-
-Use single-select accordions or simple disclosure rows for sibling panels when
-the user is choosing one item at a time. Inside an expanded panel, keep another
-layer for independent concerns instead of dumping every form, explanation, and
-secondary action into the first reveal. Prefer one flat panel with alignment,
-dividers, and whitespace over nested cards; provider or product icons should
-not receive decorative borders or containers unless the container communicates
-state or interaction. A collapsed row should still show the item name, status,
-and a concise summary so the user can scan the whole surface without opening
-everything.
-
-Before shipping, ask: “What can disappear until the user asks for it?” Then
-verify collapsed, expanded, loading, empty, error, and narrow-width states.
-If the first viewport contains multiple forms, repeated explanatory copy,
-documentation links, and controls for unrelated tasks, the surface has not
-passed this requirement yet.
-
-- **Start by subtracting**: Before adding a visible control, banner, toolbar row, card, or explanatory block, ask what can be removed, merged, renamed, or moved into an existing affordance.
-- **One primary action**: Each surface should have one dominant next action. Secondary actions belong in menus, popovers, command palettes, disclosure rows, or contextual hover/focus states unless they are used constantly.
-- **Progressively disclose rare work**: Advanced options, diagnostics, metadata, settings, import/export, destructive actions, and inspection tools should stay tucked away until requested. Prefer small icon triggers with tooltips, popovers, drawers, or detail panels over permanent chrome.
-- **Keep chrome quiet**: Avoid new always-visible bars, badges, callouts, helper text, and counters unless they prevent mistakes or are central to repeated use. Status can often be a dot, ring, muted count, or tooltip.
-- **Favor content over containers**: Do not wrap every section in a card. Use whitespace, alignment, typography, dividers, and full-width bands before adding boxes.
-- **Design for repeated use**: Production app UI should feel calm after the hundredth use. If a control shouts, animates, explains itself, or occupies a full row for an occasional action, hide or compress it.
-- **Make absence intentional**: Empty states should be sparse and action-oriented. Do not fill blank space with marketing copy, decorative art, or lists of features just because the screen feels empty.
-- **Use familiar primitives**: Icon buttons need clear tooltips. Menus, popovers, tabs, switches, and segmented controls should carry complexity instead of exposing every option at once.
+## High-Signal Minimalism And Progressive Disclosure
+
+Minimalism means fewer competing kinds of UI, not less useful information. Keep
+surfaces dense and scannable: reduce redundant prose, decorative containers,
+borders, badges, accent colors, and persistent controls before removing content
+that helps the user orient, compare, decide, or recover. The reference class is
+calm productivity software such as ChatGPT/Codex, Linear, and Vercel, not empty
+whitespace.
+
+### Product UX Philosophy
+
+Apply these principles as binding decision rules:
+
+- **Purpose over presence**: Every visible element must support orientation,
+  state comprehension, a decision, an action, or recovery. Before adding one,
+  name which; if it supports none or duplicates another element, remove or
+  defer it.
+- **Clarity over cleverness**: Use plain language, familiar patterns, explicit
+  hierarchy, and visible state. Do not make decoration or invented terminology
+  carry meaning. Preserve the labels, hit targets, focus states, and recovery
+  paths required for accessible use.
+- **Simple first, powerful on demand**: Keep the current task and state in the
+  default presentation. Put advanced, rare, diagnostic, and secondary work
+  behind contextual disclosure, menus, or Settings. Do not turn a discoverability
+  concern into permanent chrome, and do not hide information needed for the
+  current decision.
+- **Hierarchy over chrome**: Use typography, spacing, alignment, and restrained
+  emphasis to organize information. Treat prose, controls, borders, cards,
+  badges, and accent colors as a competition budget: reduce competing kinds of
+  elements before reducing useful information. When a surface has one clear
+  next decision, give it dominant emphasis and move secondary actions out of
+  the default path. Do not wrap every section in a card or add borders for
+  grouping alone; use spacing, alignment, typography, or dividers first. A
+  container must communicate grouping, state, or interaction.
+- **Coherence over novelty**: Reuse the product's primitives, interaction
+  patterns, and language. When given a screenshot or reference product, match
+  its underlying hierarchy, density, and behavior; do not copy decoration or
+  introduce a second visual language without a product reason.
+- **Quiet continuity**: Feedback must be immediate, contextual, and honest.
+  Preserve the user's place and layout, make loading, empty, and error states
+  understandable, and use motion only to explain a change.
+- **Respect repeated use**: Optimize for the hundredth use, not the first
+  impression. If a control repeats an explanation, occupies persistent space
+  for an occasional task, or turns routine work into ceremony, remove it or
+  move it to the contextual surface that owns it.
+
+### Progressive Disclosure And Information Timing
+
+Expose information and controls according to relevance, frequency, and
+consequence. Before coding, inventory the content and actions and assign them to
+the smallest useful visibility layer:
+
+1. **Orient and act**: location, current state, and context needed for the next
+   meaningful choice.
+2. **Support active work**: details and controls for the selected item or
+   current workflow.
+3. **Available on demand**: advanced settings, diagnostics, credentials,
+   metadata, destructive actions, documentation, and rare tools.
+
+Use a disclosure pattern that matches the task. Keep independent concerns easy
+to scan inside an expanded area instead of dumping every form, explanation,
+and secondary action into the first reveal. A collapsed row must retain its
+label and essential state; remove explanatory subtext unless it changes the
+next decision. For configuration with a known current state, show that state
+first and expose editing contextually instead of defaulting to a full form.
+
+Before shipping, verify collapsed, expanded, loading, empty, error, and
+narrow-width states. The default state fails review when its first viewport
+contains multiple unrelated forms, repeated explanatory copy, documentation
+links, or controls for unrelated tasks. It also fails when useful information
+has been replaced with empty whitespace or extra clicks solely to look minimal.
+The default state passes when users can identify their location, current state,
+current task, and relevant next choice without reading documentation, while
+the useful information remains dense and scannable.
 
 ## Aesthetic Guidelines
 
@@ -166,26 +205,28 @@ passed this requirement yet.
 
 ### Product Surface Review
 
-Before shipping a new app or a substantial redesign, review the first viewport
-as an operator would use it repeatedly:
-
-- Show one clear job title, the current state, and one primary next action.
-- Put optional inputs, provider choices, diagnostics, long explanations, and
-  secondary actions behind a disclosure, a later step, a menu, or the agent
-  sidebar. Do not put multiple unrelated forms side by side by default.
-- Prefer a short step flow or a focused page per domain job over one giant
-  dashboard. A route can have several states, but it should reveal one state
-  at a time and preserve the user's progress.
+Before shipping a new app or a substantial redesign, review the surface as an
+operator would use it repeatedly:
+
+- Can users identify where they are, what state they are in, and what
+  meaningful choices or next steps are available?
+- Remove competing or redundant elements, then place optional inputs, provider
+  choices, diagnostics, long explanations, and secondary actions where they
+  remain discoverable without crowding the current task.
+- Match the composition to the workflow. Use a focused page or step flow when
+  the work is sequential; use an overview when comparing or monitoring several
+  things is genuinely the job. Preserve the user's progress in either case.
 - Remove generic hero copy, feature tours, repeated helper text, nested cards,
   status-chip soup, and decorative AI treatment before adding more styling.
-- For review flows, stack the source/original first and the generated or safe
-  result second by default. Use side-by-side comparison only when the content
-  is short enough to scan without excessive horizontal reading.
+- For review flows, choose stacking, side-by-side comparison, or another
+  composition based on content length, scanability, and the user's comparison
+  task.
 - Compare the result with sibling apps. Shared toolkit behavior should feel
   consistent, but a repeated palette, hero composition, type pairing, and
   radius language without a product reason is visual drift, not consistency.
-- Check the result at the target desktop width and a narrow width. If the first
-  viewport feels like documentation instead of a tool, subtract again.
+- Check the result with realistic content at the target desktop width and a
+  narrow width. If it feels like documentation instead of a tool, reduce noise
+  or clarify the hierarchy.
 
 ## shadcn/ui Design Rules
 
@@ -203,18 +244,24 @@ as an operator would use it repeatedly:
   not show generic "Loading..." text for content loads; reserve `Spinner` for
   brief mutations, uploads, and progress actions. Use the app's existing
   loading primitive when it is a genuine design-system adapter. Empty states
-  should have one clear next action.
+  should communicate the state and offer the appropriate next step or small set
+  of choices.
 
 ## Anti-Patterns
 
-Avoid:
+Avoid patterns that add visual noise, obscure state, or compete with the user's
+task without a clear product reason:
 
 - Generic AI aesthetics: purple gradients, glassy cards everywhere, vague sparkle language, decorative blobs, and context-free hero sections.
 - Custom reimplementations of shadcn primitives.
 - Raw color overrides on shared components when semantic tokens or variants would work.
-- New always-visible controls for rare actions. Prefer menus, popovers, sheets, tabs, collapsibles, or advanced sections.
-- Full-width banners, persistent helper rows, decorative cards, or explanatory chrome for status that could be a compact affordance.
-- Treating progressive disclosure as optional. If a control is not part of the main daily workflow, hide it until context, hover, focus, or explicit user intent makes it relevant.
+- New always-visible controls for rare actions when a contextual surface would
+  preserve discoverability and reduce noise.
+- Full-width banners, persistent helper rows, decorative cards, or explanatory
+  chrome for status that could be communicated more clearly with less weight.
+- Hiding essential meaning or operability behind progressive disclosure. Defer
+  complexity when it is contextual or infrequent, but preserve labels, focus,
+  hit targets, accessibility, and recovery paths.
 - UI cards nested inside other cards.
 - Text or icons that resize or shift fixed-format UI on hover/loading.
 

package/corpus/templates/analytics/DEVELOPING.md

@@ -190,8 +190,15 @@ for an explicitly selected organization. It is dry-run by default. It uses the
 scoped credential resolver, fixed high-water marks, separate organization and
 legacy-owner cursors, atomic local checkpoints, a local lock, and a durable
 database lease shared with the shipped worker. The tuple-paging indexes are
-installed by the additive analytics migration. It does not change the Analytics
-sink or perform cutover.
+installed by the additive analytics migration, including a filtered cursor
+index for the default `http.response` exclusion. By default it copies the most
+recent 60 days, paging from the oldest eligible row to the newest so an
+existing checkpoint can resume without duplicates or gaps. Use
+`--lookback-days=30` when a 30-day window is sufficient; the worker accepts
+30-60 days only. It skips the high-volume `http.response` infrastructure
+telemetry by default. Override the exclusion list with `--skip-events=<csv>`;
+an empty value includes every event name. It does not change the Analytics sink
+or perform cutover.
 
 ```bash
 pnpm backfill:first-party-bigquery \
@@ -217,8 +224,48 @@ AGENT_NATIVE_ANALYTICS_BIGQUERY_BACKFILL_ALLOW=1 pnpm backfill:first-party-bigqu
   --max-batches=100
 ```
 
+The shipped durable worker uses the same policy. Set
+`ANALYTICS_BIGQUERY_BACKFILL_LOOKBACK_DAYS` and
+`ANALYTICS_BIGQUERY_BACKFILL_SKIP_EVENTS` to override its 30-60 day window and
+comma-separated event exclusions. The default exclusion is only
+`http.response`; action responses, exceptions, pageviews, session events,
+agent-run events, A2A invocations, session replay, and public-key metadata are
+preserved.
+
+### Postgres event volume guard
+
+New tenants that remain on the default Postgres sink are capped at 1,000,000
+accepted events per fixed UTC 30-day window. The reservation is atomic per
+organization (or per owner for legacy personal keys), so concurrent `/track`
+requests cannot overshoot the cap. Once reached, `/track` returns HTTP 429 with
+guidance to connect an external analytics database or BigQuery. SQL-only
+exception issues and public-key last-used metadata are still preserved for a
+rejected batch; session replay uses its separate quota path.
+
+Operators can raise or lower the guard with:
+
+```bash
+ANALYTICS_FIRST_PARTY_POSTGRES_EVENT_VOLUME_LIMIT=1000000
+ANALYTICS_FIRST_PARTY_POSTGRES_EVENT_VOLUME_WINDOW_DAYS=30
+```
+
+The guard applies only while an organization uses the `postgres` sink. Dual
+write and BigQuery-only organizations continue to accept events through the
+warehouse path while the migration state machine controls cutover.
+
+Postgres cleanup is intentionally a separate bounded action:
+`purge-first-party-analytics-postgres` is dry-run by default, limits work to a
+30-60 day window, counts only the current organization (legacy owner rows are
+opt-in), and compares the scoped BigQuery count before any delete. It never
+removes exception issues, session replay, public-key metadata, migration state,
+or volume counters. A write also requires a completed BigQuery cutover, the
+exact `PURGE_FIRST_PARTY_POSTGRES_EVENTS` confirmation, normal action approval,
+and parity unless `allowUncopiedEvents=true` is explicitly accepted.
+
 The checkpoint file contains cursors and counts, not event payloads or
-credentials. A short page triggers a fresh high-water check so rows written
+credentials. A v1 checkpoint is upgraded in place with the bounded source
+window and event filter while retaining its cursor and copied counts. A short
+page triggers a fresh high-water check so rows written
 while the worker is running are included. A partial BigQuery acknowledgement
 does not advance the cursor; retry it promptly, or run an insertId-deduplication
 or `MERGE` pass on the target table before finalizing.

package/corpus/templates/analytics/actions/purge-first-party-analytics-postgres.ts

@@ -0,0 +1,190 @@
+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,
+  getFirstPartyAnalyticsBackend,
+  getFirstPartyAnalyticsBigQueryMetrics,
+} from "../server/lib/first-party-analytics-backend.js";
+import {
+  countFirstPartyAnalyticsPostgresRows,
+  purgeFirstPartyAnalyticsPostgresRows,
+} from "../server/lib/first-party-analytics-purge.js";
+
+const confirmation = "PURGE_FIRST_PARTY_POSTGRES_EVENTS" as const;
+const DAY_MS = 24 * 60 * 60 * 1000;
+
+async function resolveScope() {
+  const userEmail = getRequestUserEmail();
+  const orgId = getRequestOrgId();
+  const admin = await requireAnalyticsAdminContext({ userEmail, orgId });
+  return { userEmail: admin.userEmail, orgId: admin.orgId };
+}
+
+export default defineAction({
+  description:
+    "Dry-run or explicitly purge a bounded 30-60 day window of the current organization's first-party event rows and derived rollups from Postgres after BigQuery cutover. The default is read-only. The write path requires the BigQuery sink, a completed backfill, exact confirmation, and normal action approval; exception issues, session replay, public-key metadata, migration state, and volume counters are never deleted.",
+  agentTool: false,
+  schema: z.object({
+    lookbackDays: z
+      .number()
+      .int()
+      .min(30)
+      .max(60)
+      .optional()
+      .default(60)
+      .describe("Bound the purge to the most recent 30-60 days (default 60)."),
+    dryRun: z
+      .boolean()
+      .optional()
+      .default(true)
+      .describe("Inspect counts without deleting when true (default)."),
+    includeLegacyOwnerRows: z
+      .boolean()
+      .optional()
+      .default(false)
+      .describe(
+        "Include legacy rows with this owner's email and no org id. Keep false unless the dry-run proves those rows belong to this migration.",
+      ),
+    allowUncopiedEvents: z
+      .boolean()
+      .optional()
+      .default(false)
+      .describe(
+        "Allow deletion when the scoped BigQuery event count is lower than Postgres. Keep false to prevent data loss from skipped historical event types.",
+      ),
+    confirm: z
+      .literal(confirmation)
+      .optional()
+      .describe(
+        "Required for deletion: PURGE_FIRST_PARTY_POSTGRES_EVENTS. Do not send it for a dry run.",
+      ),
+  }),
+  needsApproval: ({ dryRun }) => !dryRun,
+  run: async ({
+    lookbackDays,
+    dryRun,
+    includeLegacyOwnerRows,
+    allowUncopiedEvents,
+    confirm,
+  }) => {
+    const scope = await resolveScope();
+    if (!dryRun && confirm !== confirmation) {
+      throw new Error(
+        `Refusing to delete first-party Postgres events without confirm=${confirmation}. Run a dry run first, then repeat with the exact confirmation token.`,
+      );
+    }
+
+    const backend = await getFirstPartyAnalyticsBackend(scope);
+    const startReceivedAt = new Date(
+      Date.now() - lookbackDays * DAY_MS,
+    ).toISOString();
+    const window = {
+      startReceivedAt,
+      startEventDate: startReceivedAt.slice(0, 10),
+    };
+    const postgres = await countFirstPartyAnalyticsPostgresRows(
+      scope,
+      includeLegacyOwnerRows,
+      window,
+    );
+    let bigQuery: {
+      eventCount: number;
+      dailyRollupRows: number;
+      firstEventDate: string | null;
+      lastEventDate: string | null;
+    } | null = null;
+    let bigQueryError: string | null = null;
+    if (backend.table) {
+      try {
+        await assertFirstPartyAnalyticsBigQueryReady(backend.table, {
+          includeRowCount: false,
+        });
+        bigQuery = await getFirstPartyAnalyticsBigQueryMetrics(
+          scope,
+          backend.table,
+          { includeLegacyOwnerRows, startDate: window.startEventDate },
+        );
+      } catch (error) {
+        bigQueryError = error instanceof Error ? error.message : String(error);
+      }
+    }
+
+    const uncopiedEventRows = bigQuery
+      ? Math.max(0, postgres.eventRows - bigQuery.eventCount)
+      : null;
+    const safeToDelete =
+      backend.sink === "bigquery" &&
+      backend.backfillCompleted === true &&
+      bigQueryError === null &&
+      bigQuery !== null &&
+      uncopiedEventRows === 0;
+
+    if (!dryRun) {
+      if (backend.sink !== "bigquery") {
+        throw new Error(
+          "Postgres purge is blocked until this organization has completed the normal BigQuery cutover.",
+        );
+      }
+      if (backend.backfillCompleted !== true) {
+        throw new Error(
+          "Postgres purge is blocked until the durable BigQuery backfill reports completed.",
+        );
+      }
+      if (bigQueryError || !bigQuery) {
+        throw new Error(
+          `Postgres purge is blocked because BigQuery readiness could not be verified: ${bigQueryError ?? "unknown warehouse state"}`,
+        );
+      }
+      if (uncopiedEventRows !== 0 && !allowUncopiedEvents) {
+        throw new Error(
+          `Postgres purge is blocked: ${uncopiedEventRows} scoped event rows are not present in BigQuery. Keep allowUncopiedEvents=false unless this loss is explicitly accepted.`,
+        );
+      }
+      const deleted = await purgeFirstPartyAnalyticsPostgresRows(
+        scope,
+        includeLegacyOwnerRows,
+        window,
+      );
+      return {
+        dryRun: false,
+        lookbackDays,
+        window,
+        deleted,
+        bigQuery,
+        uncopiedEventRows,
+        includeLegacyOwnerRows,
+        preserved: [
+          "analytics_exception_events",
+          "error_issues",
+          "error_issue_occurrences",
+          "session_recordings",
+          "session_replay_chunks",
+          "session_replay_ingests",
+          "analytics_public_keys",
+          "analytics_event_volume_usage",
+        ],
+      };
+    }
+
+    return {
+      dryRun: true,
+      lookbackDays,
+      window,
+      sink: backend.sink,
+      backfillCompleted: backend.backfillCompleted === true,
+      postgres,
+      bigQuery,
+      bigQueryError,
+      uncopiedEventRows,
+      includeLegacyOwnerRows,
+      safeToDelete,
+      confirmationRequired: confirmation,
+    };
+  },
+});

package/corpus/templates/analytics/app/i18n/index.ts

@@ -1,34 +1,19 @@
-import { type AgentNativeI18nCatalog } from "@agent-native/core/client/i18n";
+import { createAgentNativeI18nCatalog } from "@agent-native/core/client/i18n";
 
 import enUS from "./en-US";
 
-export const i18nCatalog = {
-  sourceLocale: "en-US",
+export const i18nCatalog = createAgentNativeI18nCatalog({
   messages: enUS,
-  loadMessages: async (locale) => {
-    switch (locale) {
-      case "zh-CN":
-        return (await import("./zh-CN")).default;
-      case "zh-TW":
-        return (await import("./zh-TW")).default;
-      case "es-ES":
-        return (await import("./es-ES")).default;
-      case "fr-FR":
-        return (await import("./fr-FR")).default;
-      case "de-DE":
-        return (await import("./de-DE")).default;
-      case "ja-JP":
-        return (await import("./ja-JP")).default;
-      case "ko-KR":
-        return (await import("./ko-KR")).default;
-      case "pt-BR":
-        return (await import("./pt-BR")).default;
-      case "hi-IN":
-        return (await import("./hi-IN")).default;
-      case "ar-SA":
-        return (await import("./ar-SA")).default;
-      default:
-        return null;
-    }
+  localeLoaders: {
+    "zh-CN": () => import("./zh-CN"),
+    "zh-TW": () => import("./zh-TW"),
+    "es-ES": () => import("./es-ES"),
+    "fr-FR": () => import("./fr-FR"),
+    "de-DE": () => import("./de-DE"),
+    "ja-JP": () => import("./ja-JP"),
+    "ko-KR": () => import("./ko-KR"),
+    "pt-BR": () => import("./pt-BR"),
+    "hi-IN": () => import("./hi-IN"),
+    "ar-SA": () => import("./ar-SA"),
   },
-} satisfies AgentNativeI18nCatalog;
+});