@dbx-tools/appkit-mastra 0.1.13 → 0.1.14

package/src/processors/strip-stale-charts.ts

@@ -1,105 +0,0 @@
-/**
- * Mastra input processor that strips `chartId` fields from every
- * tool-invocation result in prior assistant messages before they
- * reach the model.
- *
- * Why: chartIds are only meaningful within the assistant turn that
- * minted them - the writer events backing them are gone after the
- * stream closes. When the model sees old chartIds in memory recall
- * (Mastra Memory persists tool results), it's tempted to type
- * those ids into the new turn's `[[chart:<id>]]` markers, leaving
- * the chat client's chart slots stuck with no matching event. This
- * processor removes the temptation by deleting `chartId` keys from
- * every assistant message's tool results before the prompt is
- * built. The current turn's tool results don't exist yet at
- * `processInput` time, so they pass through unmodified.
- *
- * The strip is recursive - any nested `chartId` field is removed,
- * regardless of which tool produced the result. This covers Genie's
- * `datasets[].chartId` and `render_data`'s top-level `chartId`
- * uniformly without coupling to specific tool ids.
- */
-
-import { logUtils } from "@dbx-tools/appkit-shared";
-import type {
-  InputProcessor,
-  ProcessInputArgs,
-} from "@mastra/core/processors";
-
-const log = logUtils.logger("mastra/processor/strip-stale-charts");
-
-/**
- * Recursively clone `value`, omitting any property whose key is
- * `chartId`. Arrays are mapped element-wise; primitives are
- * returned as-is. The result is structurally identical to the
- * input minus chartIds, so downstream message-shape consumers
- * keep working.
- */
-function stripChartIds(value: unknown): unknown {
-  if (Array.isArray(value)) {
-    return value.map(stripChartIds);
-  }
-  if (value && typeof value === "object") {
-    const obj = value as Record<string, unknown>;
-    const out: Record<string, unknown> = {};
-    for (const [key, val] of Object.entries(obj)) {
-      if (key === "chartId") continue;
-      out[key] = stripChartIds(val);
-    }
-    return out;
-  }
-  return value;
-}
-
-/**
- * Input processor that scrubs `chartId` from every tool-invocation
- * result in the message list. Wired onto every agent by default
- * via {@link buildAgents}; opt out with
- * `MastraPluginConfig.stripStaleCharts: false`.
- */
-export const stripStaleChartsProcessor: InputProcessor = {
-  id: "strip-stale-charts",
-  description:
-    "Removes chartId fields from prior tool-invocation results so the model can't reuse turn-scoped ids from memory.",
-  processInput(args: ProcessInputArgs) {
-    let stripped = 0;
-    for (const message of args.messages) {
-      if (message.role !== "assistant") continue;
-      const parts = message.content?.parts;
-      if (!Array.isArray(parts)) continue;
-      for (const part of parts) {
-        // Tool-invocation parts hold the persisted tool result.
-        // We don't scrub the input args (`rawInput` / `args`) because
-        // the chartId there is the model's outgoing claim, not
-        // anything it could re-reference; only `result` carries
-        // ids that subsequent turns might copy.
-        if (
-          (part as { type?: unknown }).type !== "tool-invocation"
-        ) {
-          continue;
-        }
-        const inv = (part as { toolInvocation?: { result?: unknown } })
-          .toolInvocation;
-        if (!inv || inv.result === undefined) continue;
-        const before = inv.result;
-        const after = stripChartIds(before);
-        // Cheap structural check via JSON length - the actual
-        // strip writes a fresh object only when chartId keys
-        // existed, so different stringification length is a
-        // reliable signal that something was removed.
-        if (
-          typeof before === "object" &&
-          before !== null &&
-          JSON.stringify(before).length !== JSON.stringify(after).length
-        ) {
-          inv.result = after;
-          stripped += 1;
-        }
-      }
-    }
-    if (stripped > 0) {
-      log.debug("stripped", { results: stripped });
-    }
-    return args.messages;
-  },
-};

package/src/tools/email.ts

@@ -1,147 +0,0 @@
-/**
- * Mastra tool: `send_email`. Gated behind {@link requireApproval}
- * so the model can call it freely but execution is paused until a
- * human approves via the chat UI.
- *
- * The execute body is a stub - it logs the would-be email to the
- * server console (via `logUtils.logger`) and returns success. Swap
- * in a real SMTP / SES / Resend / Workspace Mail call later by
- * editing the `execute` body; the tool surface and approval gate
- * stay the same.
- *
- * Approval flow (Mastra + AI SDK V5):
- *
- * 1. Model calls the tool with `{ to, subject, body, ... }`.
- * 2. Mastra evaluates `requireApproval` (here always `true`),
- *    pauses the agent loop, and emits a `tool-call-approval`
- *    chunk on the response stream.
- * 3. The chat client renders an approve/deny prompt against the
- *    `state: 'approval-requested'` tool part. On approve, it sends
- *    a `MastraToolApproval` response back; on deny, the tool call
- *    is rejected and the model sees an error.
- * 4. On approve, this `execute` runs and logs the email.
- *
- * The tool is intentionally NOT auto-installed on every agent -
- * email is domain-specific, not infrastructure. Spread it into the
- * specific agents that should be able to draft emails.
- */
-
-import { logUtils, stringUtils } from "@dbx-tools/appkit-shared";
-import { createTool } from "@mastra/core/tools";
-import { z } from "zod";
-
-const log = logUtils.logger("mastra/tool/send-email");
-
-const emailInputSchema = z.object({
-  to: z.string().describe(stringUtils.toDescription`
-    Single recipient email address (e.g. "alice@example.com"). For
-    multiple recipients, comma-separate them yourself.
-  `),
-  subject: z.string().describe(stringUtils.toDescription`
-    Subject line.
-  `),
-  body: z.string().describe(stringUtils.toDescription`
-    Email body. Plain text or markdown; the renderer downstream
-    decides which to honour. Be specific - the recipient may not
-    have any context the model has from prior chat turns.
-  `),
-  cc: z
-    .array(z.string())
-    .optional()
-    .describe(stringUtils.toDescription`
-      Optional CC recipients.
-    `),
-  bcc: z
-    .array(z.string())
-    .optional()
-    .describe(stringUtils.toDescription`
-      Optional BCC recipients.
-    `),
-});
-
-const emailOutputSchema = z.object({
-  sent: z.boolean().describe(stringUtils.toDescription`
-    True when the email was dispatched. The current implementation
-    always returns true after console-logging the would-be email;
-    swap in a real provider to make this meaningful.
-  `),
-  recipient: z.string().describe(stringUtils.toDescription`
-    Echo of the \`to\` field for confirmation.
-  `),
-});
-
-/** Options accepted by {@link buildEmailTool}. */
-export interface BuildEmailToolOptions {
-  /**
-   * Override the tool id. Defaults to `"send_email"`. Useful if a
-   * caller wants `send_internal_email` / `send_external_email`
-   * variants.
-   */
-  id?: string;
-  /**
-   * Replace the default execute body with a real provider call.
-   * Receives the validated input and must return `{sent, recipient}`.
-   * The console-log default is meant for demos / dev; production
-   * deployments should wire SMTP / SES / Resend / Workspace Mail
-   * here.
-   */
-  send?: (input: z.infer<typeof emailInputSchema>) => Promise<void> | void;
-}
-
-/**
- * Build the `send_email` tool. Approval-gated by default; the
- * execute body either calls the supplied {@link send} hook or
- * logs the email to the server console as a demo stub.
- *
- * @example
- * ```ts
- * import { buildEmailTool, createAgent, mastra } from "@dbx-tools/appkit-mastra";
- *
- * const support = createAgent({
- *   instructions: "...",
- *   tools(plugins) {
- *     return {
- *       ...(plugins.genie?.toolkit() ?? {}),
- *       send_email: buildEmailTool(),
- *     };
- *   },
- * });
- * ```
- */
-export function buildEmailTool(opts: BuildEmailToolOptions = {}) {
-  return createTool({
-    id: opts.id ?? "send_email",
-    description: stringUtils.toDescription`
-      Send an email on the user's behalf. Pass a recipient
-      address, subject, and body; the user will be prompted to
-      approve the send before it goes out (the tool is
-      approval-gated). Use this when the user explicitly asks
-      to send / forward / share something via email - never
-      autonomously. Keep subjects short and bodies focused; the
-      recipient may not have any of the chat context.
-    `,
-    inputSchema: emailInputSchema,
-    outputSchema: emailOutputSchema,
-    requireApproval: true,
-    execute: async (input) => {
-      const { to, subject, body, cc, bcc } = input as z.infer<
-        typeof emailInputSchema
-      >;
-      // Default behaviour: dump the email to the server console so
-      // demos can see the gate fire end-to-end without a real
-      // provider. Replace by passing `opts.send`.
-      log.info("send", {
-        to,
-        ...(cc && cc.length > 0 ? { cc } : {}),
-        ...(bcc && bcc.length > 0 ? { bcc } : {}),
-        subject,
-        bodyLength: body.length,
-        body,
-      });
-      if (opts.send) {
-        await opts.send(input as z.infer<typeof emailInputSchema>);
-      }
-      return { sent: true, recipient: to };
-    },
-  });
-}