@dbx-tools/appkit-mastra 0.1.13 → 0.1.19

package/README.md

@@ -190,65 +190,72 @@ that implements the standard `getAgentTools()` + `executeAgentTool()` +
 `executeAgentTool`, so OBO auth (`asUser`) and telemetry spans stay
 intact.
 
-`plugins.genie` is special-cased: it swaps the generic AppKit toolkit
-(which only emits a single final result chunk per call) for a
-streaming-aware tools record built on top of the plugin's
-`exports().sendMessage` AsyncGenerator. Each Genie wire event
-(`FETCHING_METADATA`, `ASKING_AI`, `EXECUTING_QUERY`, attached SQL,
-errors) is normalised into a `GenieProgress` payload and pushed
-mid-flight through Mastra's `ctx.writer`, surfacing as
-`tool-output` chunks the React client can render as inline status
-pills and SQL blocks while the LLM is still waiting on the final
-`tool-result`. Tool ids are stable: `genie` for the default alias,
-`genie-<alias>` for additional aliases, and one shared
-`genie_get_conversation`.
-
-Genie tool-result shape (LLM-bound):
+`plugins.genie` is special-cased: it talks to Genie directly via
+`@dbx-tools/genie` (`genieEventChat`) rather than calling AppKit's
+stock `genie` toolkit. Each invocation spins up a per-call inner
+Mastra `Agent` with three tools (`ask_genie`,
+`get_space_description`, `get_space_serialized`), runs it with
+`structuredOutput`, and produces a hydrated
+{@link GenieAgentResult}. AppKit's `genie()` plugin is honored
+only for its `spaces` config (and the matching
+`app.yaml`-declared resources). Tool ids are stable: `genie` for
+the default alias, `genie_<alias>` for additional aliases.
+
+Genie tool-result shape (LLM-bound) is the
+[`GenieAgentResult`](../appkit-mastra-shared/src/genie.ts) type:
 
-```
-{
-  conversationId?: string,        // pass back to continue the same Genie thread
-  genieAnswer?: string,           // Genie's prose answer; pass through verbatim
-  datasets?: [{                   // metadata only, one per executed SQL statement
-    chartId: string,              // embed [[chart:<chartId>]] to render inline
-    title?: string,
-    description?: string,
-    columns: string[],
-    rowCount: number,
-    sql?: string,
-  }],
-  suggestedFollowUps?: string[],  // UI shows as buttons; don't list in reply
-  error?: string,
-}
+```ts
+type GenieAgentResult = {
+  spaceId: string;
+  conversationId?: string;        // thread back to continue the same Genie thread
+  summary: Array<                 // ordered prose + visualize slots
+    | { type: "string"; text: string }
+    | {
+        type: "visualize";
+        statementId: string;
+        title?: string;
+        description?: string;
+        dataset: {
+          data: { columns: string[]; rows: Row[]; rowCount: number };
+          chart?: { chartId: string; chartType: "bar" | "line" | "area" | "scatter" | "pie" };
+        };
+      }
+  >;
+  error?: string;
+};
 ```
 
-`datasets[]` is metadata only - column names, row count, the SQL
-Genie ran. The actual rows ride a separate `kind: "chart"` writer
-event so the LLM never has them in context (token cost stays flat
-regardless of dataset size). The model references each dataset by
-its `chartId` via the `[[chart:<chartId>]]` marker to display the
-chart inline; see the `render_data` section below for how the
-client resolves those markers.
-
-Genie data flow:
-
-- The writer emits `kind: "started" | "status" | "sql" |
-  "suggested" | "error"` events for the live loading pill. SQL
-  text is shown via a small Shiki-highlighted block.
-- The writer **also** emits two `kind: "chart"` events per
-  executed SQL statement, sharing the same `chartId`: the first
-  carries `{chartId, title, description?, data}` (rows converted
-  to objects keyed by column name with best-effort numeric
-  coercion); the second, when the chart-planner agent finishes,
-  carries `{chartId, option}` (the resolved Echarts spec). The
-  chat client's `<ChartSlot>` merges them by `chartId` and
-  renders inline at the matching `[[chart:<chartId>]]` marker.
-  This is the exact same wire format as the `render_data` tool,
-  so Genie and hand-built charts are indistinguishable on the
-  client.
-- After a hard reload, `synthesizeToolEventsFromHistory` rebuilds
-  `suggested` events from the persisted tool-result; the SQL pill
-  and chart events are live-only and don't replay.
+The `summary` is the user-facing renderable: a mixed sequence of
+prose paragraphs (`type: "string"`) and `visualize` slots that
+mark where a chart should appear in the model's final answer.
+Visualize slots embed the dataset (rows + columns) plus a slim
+`chart` reference (just `chartId` + `chartType`); the resolved
+Echarts spec rides a separate `type: "chart"` writer event so the
+LLM never holds it in context. The host UI joins the dataset and
+the writer event by `chartId` and renders inline at the matching
+`[[chart:<chartId>]]` marker.
+
+Genie writer event flow:
+
+- The writer emits the flat
+  [`GenieWriterEvent`](../appkit-mastra-shared/src/genie.ts)
+  union for the live loading pill - the wire-derived
+  `GenieChatEvent` (status / thinking / sql / rows / suggested)
+  plus the Mastra-only lifecycle events (`started`,
+  `ask_genie_done`, `summary`, `chart`, `error`).
+- The writer emits one `type: "chart"` event per executed SQL
+  statement carrying `{chartId, title, description?, data,
+  option, statementId, messageId}`. The chat client's
+  `<ChartSlot>` renders inline at the matching
+  `[[chart:<chartId>]]` marker. This is the exact same wire
+  format as the `render_data` tool, so Genie and hand-built
+  charts are indistinguishable on the client.
+- After a hard reload, `synthesizeToolEventsFromHistory`
+  reconstructs lifecycle events from the persisted summary
+  (`error` events via `genieResultToWriterEvents`); live-only
+  events (rows, SQL pill, chart specs) don't replay because the
+  resolved Echarts spec is held off-band on the per-request
+  `RequestContext`.
 
 ### `render_data` (system-default ambient tool)
 
@@ -263,41 +270,36 @@ upstream. Input is `{ title, description?, data: Row[] }` where
 `data` is an array of objects keyed by column name (a SQL row
 set, an API response, a hand-built array, etc.).
 
-#### How it works (shared pipeline with Genie)
+#### How it works
 
-Both `render_data` and Genie's `drainGenieStream` route through
-one helper, `emitChartWithPlanning`, so the wire format and
-trace shape are consistent everywhere:
+`render_data` is a thin wrapper around `runChartPlanner`, a
+pure async function that takes a dataset and returns a fully-
+resolved Echarts `EChartsOption`. No id-then-promise dance, no
+background work: the planner runs inline, and the tool emits a
+single chart event with everything attached.
 
 1. Mint a short `chartId` (8 hex chars).
-2. Push a `{ kind: "chart", chartId, title, description?, data }`
-   event to `ctx.writer` immediately. The chat client mounts a
-   `<ChartSlot>` showing a "Rendering chart" skeleton.
-3. Kick off the chart-planner agent
-   (`modelForTier(ModelTier.Fast)`) with the dataset in the
-   background. The agent's `structuredOutput` schema is a compact
-   "chart plan" (chart type + axis labels + categories +
-   series); the helper expands the plan into an Echarts
-   `EChartsOption` JSON.
-4. When the planner resolves, push a follow-up
-   `{ kind: "chart", chartId, option }` event. The client's
-   `<ChartSlot>` merges it with the dataset event (last write
-   wins per field) and swaps in `<ReactECharts>`.
-5. If the planner fails, no follow-up event fires. Once the
-   parent tool finishes, the slot transitions to a "couldn't
-   render chart" fallback frame.
-
-The parent tool (`render_data` or Genie) `await`s the planner
-promise(s) before its `execute` returns, so chart latency shows
-up under the tool's trace span. The dataset event fires
-**immediately**, though, so the calling LLM gets back the
-`chartId` synchronously and the chat client has a layout slot
-ready before the planner resolves.
-
-The LLM-bound payload is just `{ chartId }` (for `render_data`)
-or `datasets[]` metadata (for Genie); row data and option JSON
-never reach the LLM, so token cost stays flat regardless of
-dataset size.
+2. `await runChartPlanner({ title, description?, data })`. The
+   planner is its own Mastra `Agent` (`modelForTier(ModelTier.Fast)`)
+   whose `structuredOutput` schema is a compact "chart plan"
+   (chart type + axis labels + categories + series); the helper
+   expands the plan into an `EChartsOption` JSON.
+3. Push one `{ type: "chart", chartId, title, description?, data,
+   option }` event to `ctx.writer`. The chat client's
+   `<ChartSlot>` mounts straight to the rendered Echarts
+   visualisation - no skeleton frame, because the option arrives
+   in the same event as the dataset.
+4. If the planner throws, the tool emits a `type: "error"` writer
+   event instead. The slot transitions to a "couldn't render
+   chart" fallback frame.
+
+Planner latency lands under the tool's trace span (it's
+`await`ed directly), and the LLM-bound payload is just
+`{ chartId }` so the model's context stays flat regardless of
+dataset size. The Genie agent reuses `runChartPlanner` the
+same way to embed charts in its structured summary, so the
+backbone is shared without coupling the two paths to a
+fire-and-forget writer contract.
 
 #### Inline placement contract
 
@@ -546,10 +548,10 @@ curl -s http://localhost:8000/api/mastra/models | jq
 Same payload from a sibling plugin or script (no HTTP round-trip):
 
 ```ts
-import { pluginUtils } from "@dbx-tools/appkit-shared";
+import { appkitUtils } from "@dbx-tools/shared";
 import { mastra } from "@dbx-tools/appkit-mastra";
 
-const m = pluginUtils.require(this.context, mastra).exports();
+const m = appkitUtils.require(this.context, mastra).exports();
 const endpoints = await m.asUser(req).listModels(); // user-scoped
 m.clearModelsCache(); // force the next call to re-fetch
 ```
@@ -658,10 +660,10 @@ Other plugins / route handlers can introspect the registry via the
 `exports()` surface, modeled on AppKit's:
 
 ```ts
-import { pluginUtils } from "@dbx-tools/appkit-shared";
+import { appkitUtils } from "@dbx-tools/shared";
 import { mastra } from "@dbx-tools/appkit-mastra";
 
-const m = pluginUtils.require(this.context, mastra).exports();
+const m = appkitUtils.require(this.context, mastra).exports();
 m.list(); // ["analyst", "helper"]
 m.get("analyst"); // Agent | null
 m.getDefault(); // Agent | null
@@ -715,20 +717,25 @@ function Chat() {
 mount, so a custom `mastra({ name: "myMastra" })` rewrites every path):
 
 
-| Field              | Example                             | Description                                              |
-| ------------------ | ----------------------------------- | -------------------------------------------------------- |
-| `basePath`         | `"/api/mastra"`                     | Plugin mount path.                                       |
-| `chatPath`         | `"/api/mastra/route/chat"`          | Default-agent chat URL. Use `chatUrl(config)` to get it. |
-| `chatPathTemplate` | `"/api/mastra/route/chat/:agentId"` | OpenAPI-style template for tools / docs.                 |
-| `modelsPath`       | `"/api/mastra/models"`              | `GET` cached endpoint catalogue.                         |
-| `defaultAgent`     | `"analyst"`                         | Agent id `chatRoute` binds to when none is supplied.     |
-| `agents`           | `["analyst", "helper"]`             | Every registered agent id in order.                      |
+| Field                 | Example                                | Description                                                          |
+| --------------------- | -------------------------------------- | -------------------------------------------------------------------- |
+| `basePath`            | `"/api/mastra"`                        | Plugin mount path.                                                   |
+| `chatPath`            | `"/api/mastra/route/chat"`             | Default-agent chat URL. Use `chatUrl(config)` to get it.             |
+| `chatPathTemplate`    | `"/api/mastra/route/chat/:agentId"`    | OpenAPI-style template for tools / docs.                             |
+| `modelsPath`          | `"/api/mastra/models"`                 | `GET` cached endpoint catalogue.                                     |
+| `historyPath`         | `"/api/mastra/route/history"`          | Default-agent thread history. Use `historyUrl(config, opts)`.        |
+| `historyPathTemplate` | `"/api/mastra/route/history/:agentId"` | OpenAPI-style template for tools / docs.                             |
+| `defaultAgent`        | `"analyst"`                            | Agent id `chatRoute` binds to when none is supplied.                 |
+| `agents`              | `["analyst", "helper"]`                | Every registered agent id in order.                                  |
 
 
 `chatUrl(config, agentId?)` returns `config.chatPath` for the default
 agent (the registered `chatRoute` mount that omits `:agentId`), and
-`${config.chatPath}/${encodeURIComponent(agentId)}` otherwise. Pure
-function: no React, no hooks, safe in service workers and SSR.
+`${config.chatPath}/${encodeURIComponent(agentId)}` otherwise. The
+sibling `historyUrl(config, { agentId?, page?, perPage? })` mirrors
+that pattern for the `/history` endpoint and appends pagination
+query parameters when provided. Both are pure functions: no React,
+no hooks, safe in service workers and SSR.
 
 ## License
 

package/dist/src/agents.d.ts

@@ -12,7 +12,7 @@
  * built-in analyst so the bare `mastra()` call still mounts a working
  * `chatRoute` agent for demos.
  */
-import { logUtils, pluginUtils } from "@dbx-tools/appkit-shared";
+import { appkitUtils, logUtils } from "@dbx-tools/shared";
 import { Agent } from "@mastra/core/agent";
 import type { AgentConfig, ToolsInput } from "@mastra/core/agent";
 import type { Tool } from "@mastra/core/tools";
@@ -300,7 +300,7 @@ export declare const DEFAULT_STYLE_INSTRUCTIONS: string;
  */
 export declare function buildAgents(opts: {
     config: MastraPluginConfig;
-    context: pluginUtils.PluginContextLike | undefined;
+    context: appkitUtils.PluginContextLike | undefined;
     memoryBuilder?: MemoryBuilder;
     log: logUtils.Logger;
 }): Promise<BuiltAgents>;

package/dist/src/agents.js

@@ -12,13 +12,12 @@
  * built-in analyst so the bare `mastra()` call still mounts a working
  * `chatRoute` agent for demos.
  */
-import { genie } from "@databricks/appkit";
-import { logUtils, pluginUtils, stringUtils } from "@dbx-tools/appkit-shared";
+import { appkitUtils, logUtils, stringUtils } from "@dbx-tools/shared";
 import { Agent } from "@mastra/core/agent";
 import { createTool } from "@mastra/core/tools";
 import { buildRenderDataTool } from "./chart.js";
-import { buildGenieProvider } from "./genie.js";
-import { buildModel } from "./model.js";
+import { buildGenieToolkitProvider, resolveGenieSpaces } from "./genie.js";
+import { buildModel, FALLBACK_MODEL_IDS } from "./model.js";
 import { stripStaleChartsProcessor } from "./processors/strip-stale-charts.js";
 /** Re-export of Mastra's native `createTool` for full-feature access. */
 export { createTool } from "@mastra/core/tools";
@@ -196,13 +195,52 @@ export async function buildAgents(opts) {
             ...(memory ? { memory } : {}),
             ...(inputProcessors.length > 0 ? { inputProcessors } : {}),
         });
+        // Surface the effective default model per agent so operators can
+        // see at a glance which endpoint each agent points at without
+        // having to fire a request and inspect a trace. The value is the
+        // *static* default; per-request overrides (header / query /
+        // body) and the workspace-catalogue fuzzy match still apply at
+        // call time.
+        log.info("agent registered", {
+            id,
+            name: def.name ?? id,
+            defaultModel: describeAgentDefaultModel(config, def),
+            tools: Object.keys(tools),
+        });
     }
     if (!agents[defaultAgentId]) {
         throw new Error(`mastra: defaultAgent "${defaultAgentId}" not found in registered agents (${ids.join(", ") || "none"})`);
     }
-    log.info("agents registered", { ids, defaultAgentId });
+    log.info("agents ready", { ids, defaultAgentId });
     return { agents, defaultAgentId };
 }
+/**
+ * Best-effort description of the *static* default model an agent will
+ * resolve to at call time. Walks the same precedence ladder as
+ * {@link resolveModel} / {@link buildModel}:
+ *
+ *   1. Per-agent `def.model` (string sugar -> the literal id;
+ *      function / `DynamicArgument` -> `"<dynamic>"` because the
+ *      resolver decides at call time).
+ *   2. Plugin-level `config.defaultModel` (same rules).
+ *   3. `DATABRICKS_SERVING_ENDPOINT_NAME` env var.
+ *   4. First entry of `config.defaultModelFallbacks ?? FALLBACK_MODEL_IDS`.
+ *
+ * Used for the startup `agent registered` log so operators can see
+ * which endpoint each agent points at by default. Per-request
+ * overrides (`X-Mastra-Model` etc.) and the workspace-catalogue
+ * fuzzy match are still applied at runtime.
+ */
+function describeAgentDefaultModel(config, def) {
+    const effective = def.model ?? config.defaultModel;
+    if (typeof effective === "string")
+        return effective;
+    if (effective !== undefined)
+        return "<dynamic>";
+    return (process.env.DATABRICKS_SERVING_ENDPOINT_NAME ??
+        config.defaultModelFallbacks?.[0] ??
+        FALLBACK_MODEL_IDS[0]);
+}
 /**
  * Normalize `config.agents` into a `Record<id, definition>`. Accepts
  * any of the three shapes documented on
@@ -341,19 +379,32 @@ function buildPluginsMap(config, context) {
 }
 /**
  * Pick the right {@link MastraPluginToolkitProvider} for a sibling
- * plugin lookup. Returns the streaming-aware Genie adapter when the
- * caller asks for `genie`; falls back to the generic AppKit
- * `ToolProvider` adapter for every other plugin name. `config` is
- * threaded through so Genie's tool can run the chart planner
- * inline against the same model resolver / fallback ladder the
- * agents use.
+ * plugin lookup. Returns the Genie agent-backed adapter when
+ * the caller asks for `genie` AND at least one space is reachable
+ * via {@link resolveGenieSpaces} (the explicit
+ * `config.genieSpaces`, the registered AppKit `genie()` plugin's
+ * `spaces` config, or the `DATABRICKS_GENIE_SPACE_ID` env var).
+ * Falls back to the generic AppKit `ToolProvider` adapter for
+ * every other plugin name. `config` is threaded through so the
+ * Genie agent inherits the same model resolver / fallback
+ * ladder the calling agents use.
+ *
+ * The Genie agent talks to Genie directly via `@dbx-tools/genie`
+ * (`genieEventChat`) and the workspace
+ * `statementExecution.getStatement` API. AppKit's stock `genie`
+ * plugin is honored only for its resource manifest and `spaces`
+ * config so existing `app.yaml` configs and `genie({ spaces })`
+ * wiring keep working without change.
  */
 function resolveProvider(config, context, propName) {
     if (propName === "genie") {
-        const geniePlugin = pluginUtils.instance(context, genie);
-        if (!geniePlugin)
+        const spaces = resolveGenieSpaces(config, context);
+        if (Object.keys(spaces).length === 0)
             return null;
-        return buildGenieProvider(geniePlugin, { config });
+        return buildGenieToolkitProvider({
+            spaces,
+            config,
+        });
     }
     const plugin = context?.getPlugins().get(propName);
     return adaptPluginToolkit(plugin);

package/dist/src/chart.d.ts

@@ -1,37 +1,30 @@
 /**
  * Chart-rendering primitives.
  *
- * Three surfaces, one shared brain:
- *
- * - {@link buildRenderDataTool}: a Mastra tool the model calls
- *   ("here is a dataset, render it as a chart"). The tool's
- *   `execute` emits a `kind: "chart"` event with the raw rows to
- *   `ctx.writer` synchronously, kicks off the chart-planner agent,
- *   and `await`s the planner promise before returning so the
- *   planner's latency is attributed to this tool's trace span.
- *   The LLM-bound output is just `{ chartId }`, so its context
- *   stays flat regardless of dataset size.
- *
- * - {@link emitChartWithPlanning}: the underlying helper that both
- *   `render_data` and Genie's `drainGenieStream` call. Mints the
- *   `chartId`, fires the dataset event immediately, runs the
- *   planner in the background, and returns `{ chartId,
- *   plannerPromise }` so callers can choose to await for trace
- *   shape or fire-and-forget.
+ * Two surfaces, one shared brain:
  *
  * - {@link runChartPlanner}: the chart-planner Agent + ECOption
- *   expansion as a plain async function. Used internally by
- *   {@link emitChartWithPlanning}; producers shouldn't reach for
- *   it directly so chart events keep a single wire-format
- *   contract.
+ *   expansion as a plain async function. Takes a dataset and
+ *   returns a promise that resolves to a full `EChartsOption`
+ *   JSON plus the chosen `chartType`. No background work, no
+ *   writer side-effects, no id allocation - callers stitch the
+ *   result into whatever shape their producer needs.
+ *
+ * - {@link buildRenderDataTool}: a Mastra tool the model calls
+ *   ("here is a dataset, render it as a chart"). Mints a short
+ *   `chartId`, `await`s {@link runChartPlanner} so the planner
+ *   latency is attributed to this tool's trace span, emits one
+ *   `type: "chart"` writer event carrying the dataset + resolved
+ *   `option`, and returns `{ chartId }` to the model. The
+ *   LLM-bound output stays flat regardless of dataset size.
  *
  * The model wires the chart into its reply by emitting the marker
  * `[[chart:<chartId>]]` on its own line in markdown. The chat
  * client splits the assistant text on these markers and drops a
- * `<ChartSlot>` in at the position the model placed it; the slot
- * shows a skeleton until the second `kind: "chart"` event (with
- * the resolved `EChartsOption`) arrives, then swaps in the
- * rendered Echarts visualisation.
+ * `<ChartSlot>` in at the position the model placed it. The slot
+ * resolves directly to the rendered Echarts visualisation - no
+ * skeleton state, because the option is in the same event as the
+ * dataset.
  */
 import type { RequestContext } from "@mastra/core/request-context";
 import { z } from "zod";
@@ -60,10 +53,10 @@ declare const chartPlanSchema: z.ZodObject<{
     categories: z.ZodOptional<z.ZodArray<z.ZodString>>;
     series: z.ZodArray<z.ZodObject<{
         name: z.ZodString;
-        data: z.ZodArray<z.ZodUnion<readonly [z.ZodNumber, z.ZodTuple<[z.ZodNumber, z.ZodNumber], null>, z.ZodObject<{
+        data: z.ZodArray<z.ZodCatch<z.ZodPreprocess<z.ZodUnion<readonly [z.ZodNumber, z.ZodNull, z.ZodTuple<[z.ZodNumber, z.ZodNumber], null>, z.ZodObject<{
             name: z.ZodString;
             value: z.ZodNumber;
-        }, z.core.$strip>]>>;
+        }, z.core.$strip>]>>>>;
     }, z.core.$strip>>;
 }, z.core.$strip>;
 type ChartPlan = z.infer<typeof chartPlanSchema>;
@@ -74,6 +67,12 @@ export interface RunChartPlannerOptions {
     title: string;
     description?: string;
     data: ReadonlyArray<Record<string, unknown>>;
+    /**
+     * Cooperative cancellation. Forwarded to the planner agent's
+     * `generate({ abortSignal })` call so concurrent renders can be
+     * aborted as a group when the parent Genie agent's signal fires.
+     */
+    signal?: AbortSignal;
 }
 /** Output of {@link runChartPlanner}: a fully-formed Echarts spec. */
 export interface RunChartPlannerResult {
@@ -82,89 +81,24 @@ export interface RunChartPlannerResult {
 }
 /**
  * Run the chart planner against the given dataset and return a
- * full Echarts `EChartsOption` JSON. Used by
- * {@link emitChartWithPlanning}; tools and producers shouldn't
- * call this directly (use the helper instead so chart events
- * follow the same wire-format contract everywhere).
+ * full Echarts `EChartsOption` JSON. Pure async function: no
+ * writer side-effects, no id minting, no background work.
+ * Producers (the `render_data` tool, the Genie agent,
+ * anything else that needs a chart) await this and stitch the
+ * result into whatever shape their wire contract needs.
  */
 export declare function runChartPlanner(opts: RunChartPlannerOptions): Promise<RunChartPlannerResult>;
-/**
- * Minimal `ToolStream`-shaped writer surface. Defined locally so
- * helpers can take any object with a `.write` method without
- * importing Mastra's full `ToolStream` (which would also drag in
- * agent / tool types this module doesn't otherwise need).
- */
-interface MinimalWriter {
-    write: (chunk: unknown) => unknown;
-}
-/** Inputs to {@link emitChartWithPlanning}. */
-export interface EmitChartWithPlanningOptions {
-    /** Mastra `ctx.writer`; missing or closed writers are tolerated. */
-    writer?: MinimalWriter;
-    /** Plugin config; used to resolve the planner's model. */
-    config: MastraPluginConfig;
-    /** Per-request context (OBO auth). */
-    requestContext?: RequestContext;
-    /** Title shown above the rendered chart. Required. */
-    title: string;
-    /** Optional one-line intent biasing the planner. */
-    description?: string;
-    /** Tabular dataset to chart (one object per row). */
-    data: ReadonlyArray<Record<string, unknown>>;
-}
-/** Output of {@link emitChartWithPlanning}. */
-export interface EmitChartWithPlanningResult {
-    /** Short id matching the marker `[[chart:<chartId>]]`. */
-    chartId: string;
-    /**
-     * Promise that resolves once the planner has finished and the
-     * `kind: "chart"` event with the option has been emitted (or
-     * once the planner has failed silently). Callers that want
-     * trace observability should `await` this before returning
-     * from their tool's `execute`; callers that want pure
-     * fire-and-forget can ignore it.
-     */
-    plannerPromise: Promise<void>;
-}
-/**
- * Shared chart-emission primitive used by both the `render_data`
- * tool and Genie's `drainGenieStream`. Keeps both producers on
- * one wire-format contract so the chat client only ever has to
- * understand a single chart event shape.
- *
- * Behaviour:
- *
- * 1. Generates a short `chartId` (8 hex chars).
- * 2. Immediately emits `{ kind: "chart", chartId, title,
- *    description?, data }` via the writer so the chat client can
- *    mount its `<ChartSlot>` with the rows in hand.
- * 3. Kicks off the chart-planner agent in the background. On
- *    success, emits a second `{ kind: "chart", chartId, option }`
- *    event - same `chartId`, just the spec - so the client merges
- *    the two into one rendered chart. On failure, no follow-up
- *    event fires; the client falls back to whatever it can do
- *    with the dataset alone (typically a "render failed" frame
- *    after the parent tool finishes).
- *
- * Returns `chartId` synchronously so the caller can include it in
- * the tool result (model uses it in `[[chart:<chartId>]]`
- * markers), and `plannerPromise` so the caller can choose
- * trace-spanning vs. snappy-return semantics.
- */
-export declare function emitChartWithPlanning(opts: EmitChartWithPlanningOptions): Promise<EmitChartWithPlanningResult>;
 /**
  * Build the `render_data` tool bound to the given plugin config.
  *
- * The tool is a thin wrapper around {@link emitChartWithPlanning}:
- * a single `kind: "chart"` writer event ships the raw rows to
- * the client immediately, the chart-planner agent runs alongside
- * (so the calling LLM stays unblocked while the planner thinks),
- * and a follow-up `kind: "chart"` event with the resolved
- * `EChartsOption` lands when it's ready. The tool's `execute`
- * awaits the planner promise so the planner work shows up under
- * the tool's trace span; the LLM still gets back just
- * `{ chartId }`, so its context stays small regardless of dataset
- * size.
+ * The tool awaits {@link runChartPlanner} so the planner's
+ * latency is attributed to this tool's trace span, then emits
+ * one `type: "chart"` writer event carrying the dataset and the
+ * resolved `EChartsOption`. The LLM-bound output is just
+ * `{ chartId }` so the model's context stays flat regardless of
+ * dataset size. Planner failures are caught and surfaced as a
+ * `type: "error"` writer event so the slot can fall back to
+ * "couldn't render chart" without taking the parent agent down.
  */
 export declare function buildRenderDataTool(config: MastraPluginConfig): import("@mastra/core/tools").Tool<any, any, any, any, import("@mastra/core/tools").ToolExecutionContext<any, any, unknown>, "render_data", unknown>;
 export {};