@runtypelabs/persona-proxy 3.26.0 → 3.32.0

package/dist/index.d.cts

@@ -86,6 +86,64 @@ declare const STOREFRONT_ASSISTANT_FLOW: RuntypeFlowConfig;
  */
 declare const WEBMCP_STOREFRONT_FLOW: RuntypeFlowConfig;
 
+/**
+ * WebMCP calendar flow for the calendar copilot demo
+ * (`examples/embedded-app/webmcp-calendar.html`).
+ *
+ * Like WEBMCP_STOREFRONT_FLOW, this agent owns **no** tools of its own. The
+ * demo page registers ten calendar tools on `document.modelContext` via WebMCP
+ * (`get_calendar_state`, `get_events`, `get_users`, `get_event_colors`,
+ * `find_availability`, `select_date`, `create_event`, `update_event`,
+ * `delete_event`, `get_page_title`); the widget snapshots them every turn and
+ * the proxy forwards them on the dispatch payload as `clientTools[]`. The
+ * model calls them by name and the widget executes them **on the page**,
+ * posting results back via `/resume` — so the calendar UI updates live.
+ *
+ * The page's tool contract is timezone-safe by design: all date-times are
+ * LOCAL wall-clock strings (`YYYY-MM-DDTHH:mm`, no "Z"/UTC offset), and
+ * `get_calendar_state` reports the current local date-time and timezone. The
+ * system prompt reinforces that contract so "8am" always lands at 8am on the
+ * visible calendar.
+ */
+declare const WEBMCP_CALENDAR_FLOW: RuntypeFlowConfig;
+
+/**
+ * WebMCP slide-editor flow for the Deck Copilot demo
+ * (`examples/embedded-app/webmcp-slides.html`).
+ *
+ * Like the other WebMCP flows, this agent owns **no** tools of its own — the
+ * demo page registers them on `document.modelContext` and the widget snapshots
+ * them every turn into `clientTools[]`. What makes this flow different is that
+ * the page's tool set is *dynamic*: selection-scoped tools
+ * (`style_selection`, `align_selection`) only exist while the user has 2+
+ * elements selected, and entering presenter mode replaces the entire editing
+ * set with show controls (`next_slide`, `prev_slide`, `jump_to_slide`,
+ * `exit_presenter_mode`). The system prompt teaches the model to treat the
+ * current tool list as authoritative rather than assuming a fixed catalog.
+ *
+ * The page also ships live editor state as `{{slides_context}}` via the
+ * widget's `contextProviders` + `requestMiddleware` (moved from
+ * `payload.context` into `inputs`): current slide, mode, and the user's
+ * selection with ids and bounding boxes — so "align these" resolves without a
+ * round-trip.
+ */
+declare const WEBMCP_SLIDES_FLOW: RuntypeFlowConfig;
+
+/**
+ * WebMCP docked-dashboard flow for the docked panel demo
+ * (`examples/embedded-app/docked-panel-demo.html`).
+ *
+ * Like the other WebMCP flows, this agent owns **no** tools of its own. The
+ * demo page registers four workspace tools on `document.modelContext` via
+ * WebMCP (`get_workspace_overview`, `switch_section`, `set_dock_layout`,
+ * `log_activity`); the widget snapshots them every turn and the proxy
+ * forwards them on the dispatch payload as `clientTools[]`. The model calls
+ * them by name and the widget executes them **on the page**, posting results
+ * back via `/resume` — so the dashboard (and even the assistant's own dock
+ * placement) updates live.
+ */
+declare const WEBMCP_DOCKED_FLOW: RuntypeFlowConfig;
+
 /**
  * Page-aware shopping assistant that can both *describe* and *act on* the page.
  *
@@ -207,4 +265,4 @@ type ChatProxyOptions = {
 declare const createChatProxyApp: (options?: ChatProxyOptions) => Hono<hono_types.BlankEnv, hono_types.BlankSchema, "/">;
 declare const createVercelHandler: (options?: ChatProxyOptions) => (req: Request) => Response | Promise<Response>;
 
-export { BAKERY_ASSISTANT_FLOW, COMPONENT_FLOW, CONVERSATIONAL_FLOW, type ChatProxyOptions, type CheckoutItem, type CheckoutSessionResponse, type CreateCheckoutSessionOptions, FORM_DIRECTIVE_FLOW, type FeedbackHandler, type FeedbackPayload, PAGE_CONTEXT_FLOW, type RuntypeFlowConfig, type RuntypeFlowStep, SHOPPING_ASSISTANT_FLOW, SHOPPING_ASSISTANT_METADATA_FLOW, STOREFRONT_ASSISTANT_FLOW, WEBMCP_STOREFRONT_FLOW, createChatProxyApp, createCheckoutSession, createVercelHandler, createChatProxyApp as default };
+export { BAKERY_ASSISTANT_FLOW, COMPONENT_FLOW, CONVERSATIONAL_FLOW, type ChatProxyOptions, type CheckoutItem, type CheckoutSessionResponse, type CreateCheckoutSessionOptions, FORM_DIRECTIVE_FLOW, type FeedbackHandler, type FeedbackPayload, PAGE_CONTEXT_FLOW, type RuntypeFlowConfig, type RuntypeFlowStep, SHOPPING_ASSISTANT_FLOW, SHOPPING_ASSISTANT_METADATA_FLOW, STOREFRONT_ASSISTANT_FLOW, WEBMCP_CALENDAR_FLOW, WEBMCP_DOCKED_FLOW, WEBMCP_SLIDES_FLOW, WEBMCP_STOREFRONT_FLOW, createChatProxyApp, createCheckoutSession, createVercelHandler, createChatProxyApp as default };

package/dist/index.d.ts

@@ -86,6 +86,64 @@ declare const STOREFRONT_ASSISTANT_FLOW: RuntypeFlowConfig;
  */
 declare const WEBMCP_STOREFRONT_FLOW: RuntypeFlowConfig;
 
+/**
+ * WebMCP calendar flow for the calendar copilot demo
+ * (`examples/embedded-app/webmcp-calendar.html`).
+ *
+ * Like WEBMCP_STOREFRONT_FLOW, this agent owns **no** tools of its own. The
+ * demo page registers ten calendar tools on `document.modelContext` via WebMCP
+ * (`get_calendar_state`, `get_events`, `get_users`, `get_event_colors`,
+ * `find_availability`, `select_date`, `create_event`, `update_event`,
+ * `delete_event`, `get_page_title`); the widget snapshots them every turn and
+ * the proxy forwards them on the dispatch payload as `clientTools[]`. The
+ * model calls them by name and the widget executes them **on the page**,
+ * posting results back via `/resume` — so the calendar UI updates live.
+ *
+ * The page's tool contract is timezone-safe by design: all date-times are
+ * LOCAL wall-clock strings (`YYYY-MM-DDTHH:mm`, no "Z"/UTC offset), and
+ * `get_calendar_state` reports the current local date-time and timezone. The
+ * system prompt reinforces that contract so "8am" always lands at 8am on the
+ * visible calendar.
+ */
+declare const WEBMCP_CALENDAR_FLOW: RuntypeFlowConfig;
+
+/**
+ * WebMCP slide-editor flow for the Deck Copilot demo
+ * (`examples/embedded-app/webmcp-slides.html`).
+ *
+ * Like the other WebMCP flows, this agent owns **no** tools of its own — the
+ * demo page registers them on `document.modelContext` and the widget snapshots
+ * them every turn into `clientTools[]`. What makes this flow different is that
+ * the page's tool set is *dynamic*: selection-scoped tools
+ * (`style_selection`, `align_selection`) only exist while the user has 2+
+ * elements selected, and entering presenter mode replaces the entire editing
+ * set with show controls (`next_slide`, `prev_slide`, `jump_to_slide`,
+ * `exit_presenter_mode`). The system prompt teaches the model to treat the
+ * current tool list as authoritative rather than assuming a fixed catalog.
+ *
+ * The page also ships live editor state as `{{slides_context}}` via the
+ * widget's `contextProviders` + `requestMiddleware` (moved from
+ * `payload.context` into `inputs`): current slide, mode, and the user's
+ * selection with ids and bounding boxes — so "align these" resolves without a
+ * round-trip.
+ */
+declare const WEBMCP_SLIDES_FLOW: RuntypeFlowConfig;
+
+/**
+ * WebMCP docked-dashboard flow for the docked panel demo
+ * (`examples/embedded-app/docked-panel-demo.html`).
+ *
+ * Like the other WebMCP flows, this agent owns **no** tools of its own. The
+ * demo page registers four workspace tools on `document.modelContext` via
+ * WebMCP (`get_workspace_overview`, `switch_section`, `set_dock_layout`,
+ * `log_activity`); the widget snapshots them every turn and the proxy
+ * forwards them on the dispatch payload as `clientTools[]`. The model calls
+ * them by name and the widget executes them **on the page**, posting results
+ * back via `/resume` — so the dashboard (and even the assistant's own dock
+ * placement) updates live.
+ */
+declare const WEBMCP_DOCKED_FLOW: RuntypeFlowConfig;
+
 /**
  * Page-aware shopping assistant that can both *describe* and *act on* the page.
  *
@@ -207,4 +265,4 @@ type ChatProxyOptions = {
 declare const createChatProxyApp: (options?: ChatProxyOptions) => Hono<hono_types.BlankEnv, hono_types.BlankSchema, "/">;
 declare const createVercelHandler: (options?: ChatProxyOptions) => (req: Request) => Response | Promise<Response>;
 
-export { BAKERY_ASSISTANT_FLOW, COMPONENT_FLOW, CONVERSATIONAL_FLOW, type ChatProxyOptions, type CheckoutItem, type CheckoutSessionResponse, type CreateCheckoutSessionOptions, FORM_DIRECTIVE_FLOW, type FeedbackHandler, type FeedbackPayload, PAGE_CONTEXT_FLOW, type RuntypeFlowConfig, type RuntypeFlowStep, SHOPPING_ASSISTANT_FLOW, SHOPPING_ASSISTANT_METADATA_FLOW, STOREFRONT_ASSISTANT_FLOW, WEBMCP_STOREFRONT_FLOW, createChatProxyApp, createCheckoutSession, createVercelHandler, createChatProxyApp as default };
+export { BAKERY_ASSISTANT_FLOW, COMPONENT_FLOW, CONVERSATIONAL_FLOW, type ChatProxyOptions, type CheckoutItem, type CheckoutSessionResponse, type CreateCheckoutSessionOptions, FORM_DIRECTIVE_FLOW, type FeedbackHandler, type FeedbackPayload, PAGE_CONTEXT_FLOW, type RuntypeFlowConfig, type RuntypeFlowStep, SHOPPING_ASSISTANT_FLOW, SHOPPING_ASSISTANT_METADATA_FLOW, STOREFRONT_ASSISTANT_FLOW, WEBMCP_CALENDAR_FLOW, WEBMCP_DOCKED_FLOW, WEBMCP_SLIDES_FLOW, WEBMCP_STOREFRONT_FLOW, createChatProxyApp, createCheckoutSession, createVercelHandler, createChatProxyApp as default };

package/dist/index.js

@@ -570,6 +570,7 @@ Rules:
 - If the shopper asks to add two (or more) specific items "at the same time" / "both", emit the add_to_cart calls together in one turn so they batch.
 - Only apply a promo code the shopper actually gives you; if it's rejected, say so and suggest they double-check the code.
 - If a tool reports an item wasn't found or isn't in the cart, relay that plainly and offer to search.
+- Tool results include product \`imageUrl\` and \`imageAlt\`. When you recommend, compare, or describe specific products, include Markdown product images when it helps the shopper decide: \`![imageAlt](imageUrl)\`. Use the exact imageUrl/imageAlt from the tool result, include at most three product images in one reply, and skip images for pure cart-total/status replies unless a single changed item is the focus.
 
 After your tool calls resolve, summarize the outcome in plain language (what you found, what's in the cart, the total). Do not describe tools, JSON, SKUs, or the WebMCP mechanism to the shopper.`,
         previousMessages: "{{messages}}"
@@ -578,6 +579,142 @@ After your tool calls resolve, summarize the outcome in plain language (what you
   ]
 };
 
+// src/flows/webmcp-calendar.ts
+var WEBMCP_CALENDAR_FLOW = {
+  name: "WebMCP Calendar Flow",
+  description: "Calendar copilot \u2014 drives page-provided WebMCP calendar tools (clientTools[])",
+  steps: [
+    {
+      id: "webmcp_calendar_prompt",
+      name: "WebMCP Calendar Prompt",
+      type: "prompt",
+      enabled: true,
+      config: {
+        model: "nemotron-3-ultra-550b-a55b",
+        reasoning: false,
+        responseFormat: "markdown",
+        outputVariable: "prompt_result",
+        userPrompt: "{{user_message}}",
+        systemPrompt: `You are the Calendar Copilot for a team scheduling dashboard. You help the user inspect availability, create, move, and delete events \u2014 the calendar on the page updates live as your tools run.
+
+Voice: helpful, concise, plain language. Keep replies short \u2014 a sentence or two around the actions you take.
+
+## Your tools come from the page
+
+The dashboard exposes its own calendar tools to you. Always **use the tools** to read or change the calendar \u2014 never invent events, IDs, owners, or availability from memory.
+
+Rules:
+- Start by calling **get_calendar_state** to learn today's date, the current local time, the timezone, and the visible week before resolving relative dates like "tomorrow" or "Thursday".
+- All date-times are LOCAL wall-clock strings in the calendar's timezone, formatted \`YYYY-MM-DDTHH:mm\`. Never append "Z" or a UTC offset \u2014 write the clock time the user said.
+- Use a real userId from **get_users** and a color from **get_event_colors** when creating events. Do not guess IDs.
+- Before proposing a meeting time, check **find_availability** for that date; the workday is 9am\u20135pm local.
+- To change or remove an event, find its eventId via **get_events** or **get_calendar_state** first.
+- After a mutation, confirm briefly what changed (title, day, time) \u2014 the page renders the calendar, so don't repeat the full schedule unless asked.
+- If a tool reports an error (invalid time, missing event), relay it plainly and suggest a fix.
+
+After your tool calls resolve, summarize the outcome in plain language. Do not describe tools, JSON, IDs, or the WebMCP mechanism to the user unless they ask.`,
+        previousMessages: "{{messages}}"
+      }
+    }
+  ]
+};
+
+// src/flows/webmcp-slides.ts
+var WEBMCP_SLIDES_FLOW = {
+  name: "WebMCP Slides Flow",
+  description: "Deck Copilot \u2014 drives a slide editor's page-provided WebMCP tools (clientTools[])",
+  steps: [
+    {
+      id: "webmcp_slides_prompt",
+      name: "WebMCP Slides Prompt",
+      type: "prompt",
+      enabled: true,
+      config: {
+        model: "nemotron-3-ultra-550b-a55b",
+        reasoning: false,
+        responseFormat: "markdown",
+        outputVariable: "prompt_result",
+        userPrompt: "{{user_message}}",
+        systemPrompt: `You are the Deck Copilot inside a live slide-deck editor. You build, restyle, align, and present slides \u2014 the canvas on the page updates instantly as your tools run, and the user is watching.
+
+Voice: concise and design-literate. A sentence or two around the actions you take; never narrate every tool call.
+
+## Your tools come from the page \u2014 and they change
+
+The editor exposes its own tools to you, and the set is dynamic:
+- While the user has 2 or more elements selected, extra selection tools appear (style_selection, align_selection) that act on the live selection without needing ids.
+- When the show starts (enter_presenter_mode), your editing tools are REPLACED by presentation controls (next_slide, prev_slide, jump_to_slide, exit_presenter_mode) until the show ends.
+
+Treat the tool list you currently see as authoritative. Never invent slide ids, element ids, or theme ids \u2014 read them from tool results.
+
+## Read before you write
+
+- Call get_deck_overview to orient yourself when you need the deck's shape; call get_slide before editing a slide's elements.
+- Mutations return the ids they created or touched \u2014 chain on those instead of re-reading the deck.
+- A {{slides_context}} block rides along with every message: the current slide, the editor mode, and the user's live selection (ids + bounding boxes). When the user says "this", "these", or "the selected boxes", use that context (or get_selection) \u2014 do not guess.
+
+## Geometry and style conventions
+
+- The canvas is 960 wide x 540 tall, origin at the top-left. Keep ~40px margins; slide titles sit around y 40-60 at fontSize 36-48.
+- Prefer theme tokens over literal colors and fonts: 'theme.text', 'theme.accent', 'theme.background', 'theme.surface', 'theme.accentText' for colors, 'theme.heading' / 'theme.body' for fonts. Token-styled elements restyle automatically when apply_theme runs \u2014 hex values do not.
+- Build slides with add_slide layouts first, then refine with update_element patches (one patch can move, resize, and restyle at once). Use align_elements / distribute_elements for clean composition instead of eyeballing coordinates.
+
+## Etiquette
+
+- Destructive or deck-wide tools (delete_slide, delete_elements, apply_theme) ask the user for confirmation \u2014 if the user declines, accept it and move on.
+- Every change you make lands on the editor's undo stack; the user can reverse you with Cmd+Z. Don't be precious about edits.
+- After mutations, confirm briefly what changed \u2014 the user can see the canvas, so don't re-describe slides in detail.
+- If a tool reports an error (unknown id, too few elements selected), relay it plainly and suggest the fix.
+- Never mention JSON, ids, tool schemas, or the WebMCP mechanism unless the user asks.
+
+## Live editor state
+
+{{slides_context}}`,
+        previousMessages: "{{messages}}"
+      }
+    }
+  ]
+};
+
+// src/flows/webmcp-docked.ts
+var WEBMCP_DOCKED_FLOW = {
+  name: "WebMCP Docked Dashboard Flow",
+  description: "Dashboard copilot \u2014 drives page-provided WebMCP workspace tools (clientTools[])",
+  steps: [
+    {
+      id: "webmcp_docked_prompt",
+      name: "WebMCP Docked Prompt",
+      type: "prompt",
+      enabled: true,
+      config: {
+        model: "nemotron-3-ultra-550b-a55b",
+        reasoning: false,
+        responseFormat: "markdown",
+        outputVariable: "prompt_result",
+        userPrompt: "{{user_message}}",
+        systemPrompt: `You are Copilot, a dashboard assistant docked beside an operations workspace. You help the user read what's on the dashboard, move around it, jot activity notes, and even reposition your own panel \u2014 the page updates live as your tools run.
+
+Voice: helpful, concise, plain language. Keep replies short \u2014 a sentence or two around the actions you take.
+
+## Your tools come from the page
+
+The dashboard exposes its own tools to you. Always **use the tools** to read or change the workspace \u2014 never invent metrics, cards, sections, or activity from memory.
+
+Rules:
+- Call **get_workspace_overview** before answering questions about the dashboard \u2014 it returns the sections, the active section, the highlight cards, and the recent-activity feed.
+- **switch_section** changes which workspace section is highlighted in the side nav. Use the exact section names from the overview.
+- **set_dock_layout** moves and resizes YOUR own panel (side left/right, width, reveal style, animation). When the user says "move yourself" or "dock on the left", this is the tool. Confirm what changed afterward.
+- **log_activity** appends an entry to the Recent activity feed. Use it when the user asks you to note, record, or log something. Keep titles short; put detail in the body.
+- After a mutation, confirm briefly what changed \u2014 the page renders the result, so don't repeat the full dashboard unless asked.
+- If a tool reports an error (unknown section, invalid width), relay it plainly and suggest a fix.
+
+After your tool calls resolve, summarize the outcome in plain language. Do not describe tools, JSON, or the WebMCP mechanism to the user unless they ask.`,
+        previousMessages: "{{messages}}"
+      }
+    }
+  ]
+};
+
 // src/flows/page-context.ts
 var PAGE_CONTEXT_FLOW = {
   name: "Page Context Assistant Flow",
@@ -1034,6 +1171,9 @@ export {
   SHOPPING_ASSISTANT_FLOW,
   SHOPPING_ASSISTANT_METADATA_FLOW,
   STOREFRONT_ASSISTANT_FLOW,
+  WEBMCP_CALENDAR_FLOW,
+  WEBMCP_DOCKED_FLOW,
+  WEBMCP_SLIDES_FLOW,
   WEBMCP_STOREFRONT_FLOW,
   createChatProxyApp,
   createCheckoutSession,