@genesislcap/ai-assistant 14.421.1 → 14.422.0

package/docs/sub_agent.md

@@ -1,310 +1,248 @@
-# Sub-Agent Architecture
+# Sub-Agents
 
 ## Overview
 
-Sub-agents are specialist agents embedded inside a parent agent. Tool handlers on the parent invoke them explicitly via `requestSubAgent` — a sibling to the existing `requestInteraction` API. Each sub-agent runs its own full tool loop to completion and returns its final response to the calling handler as a resolved promise. From the LLM's perspective, it called a normal tool and got a result back — it has no visibility into the sub-agent that produced it.
+Sub-agents are specialist agents embedded inside a parent agent. Tool handlers on the parent invoke them explicitly via `requestSubAgent` — a sibling to the existing `requestInteraction` API. Each sub-agent runs its own full tool loop to completion and returns its result to the calling handler as a resolved promise.
 
-The goal is to improve quality and reduce hallucinations by routing bounded, well-defined tasks (data extraction, validation, enrichment, judge passes) to purpose-built agents with focused prompts and tight tool sets, without burdening the parent's context window.
+From the LLM's perspective, it called a normal tool and received a result — it has no visibility into the sub-agent that produced it. Sub-agents are an implementation detail of a tool call, not a visible actor in the conversation.
 
----
-
-## Motivating Example
-
-**Trade File Extraction sub-agent**
-
-A user attaches a CSV of trades they want booked. The parent (Trades Agent) is good at booking and querying trades but is not the right place to parse arbitrary file formats, normalise field names, and resolve ambiguous values. Instead, the parent's `process_trade_file` tool handler delegates to a sub-agent:
-
-```ts
-const processTradeFile: ChatToolHandler = async (args, { requestSubAgent }) => {
-  const result = await requestSubAgent('trade_file_extractor', {
-    task: `Extract and normalise all trades from this file content: ${args.file_content}`,
-  });
-  // result is the sub-agent's final assistant message — a JSON string of normalised trades
-  return result;
-};
-```
-
-The sub-agent runs its own tool loop — calling `parse_csv`, `resolve_instrument`, `validate_trade_fields` etc. — and when it finishes, its final message is handed back to the parent handler. The parent then proceeds to book each trade with its own tools.
-
-Other natural candidates in the trades domain:
-- **Risk Judge sub-agent** — called inside a `confirm_trade` handler to validate against risk limits before confirming. The same sub-agent can be reused across multiple handlers with different `task` descriptions and `context` payloads.
-- **Counterparty Resolver sub-agent** — called inside a search handler to resolve raw counterparty names to canonical IDs. Multiple handlers can call it in parallel if they are invoked in the same LLM turn.
+The goal is to improve quality and reduce hallucinations by routing bounded, well-defined tasks — data extraction, validation, enrichment, judge passes — to purpose-built agents with focused prompts and tight tool sets, without burdening the parent agent's context window.
 
 ---
 
-## Config
+## Declaring sub-agents
 
-Sub-agents are declared on the parent `AgentConfig` using a new optional `subAgents` field. They use the identical `AgentConfig` shape — no new interface is needed. The `name` field is used to look up the sub-agent at call time.
+Sub-agents are declared on the parent `AgentConfig` using the `subAgents` field, which takes an array of `AgentConfig` objects. The `name` field is used to look up the sub-agent at call time.
 
 ```ts
-// config.ts  (BaseAgentConfig addition)
-interface BaseAgentConfig {
-  // ... existing fields ...
+import { defineAgent } from '@genesislcap/ai-assistant';
 
-  /**
-   * Sub-agents available to this agent's tool handlers via `requestSubAgent`.
-   * Sub-agents are leaf nodes — their own `subAgents` field is ignored.
-   */
-  subAgents?: AgentConfig[];
-
-  /**
-   * When this config is used as a sub-agent, caps the number of parent history
-   * messages passed as context. If unset, full history is passed. Messages within
-   * the cap are passed verbatim; messages older than the cap have tool args and
-   * results masked (same transform used by OrchestratingDriver for cross-agent history).
-   */
-  historyCap?: number;
-}
-```
-
-Example declaration in the host app:
-
-```ts
-const tradesAgent: SpecialistAgentConfig = {
-  name: 'Trades Agent',
-  description: 'Books, searches, and manages trades',
+const tradesAgent = defineAgent({
+  name: 'Trades Assistant',
+  description: 'Books, searches, and manages trades.',
   systemPrompt: '...',
   toolDefinitions: [...tradeTools],
   toolHandlers: { ...tradeHandlers },
   subAgents: [
     {
       name: 'trade_file_extractor',
-      description: 'Extracts and normalises trade data from uploaded files',
-      historyCap: 4,
+      description: 'Extracts and normalises trade data from uploaded files.',
       systemPrompt: `You are a data extraction specialist. Your only job is to parse the
-        provided file content and return a JSON array of normalised trade objects.
-        Each trade must have: instrument, quantity, side, price, counterparty.
-        Do not book trades. Do not ask the user questions. Just extract.`,
-      toolDefinitions: [parseCsvDefinition, resolveInstrumentDefinition],
-      toolHandlers: { parse_csv: parseCsvHandler, resolve_instrument: resolveInstrumentHandler },
-    },
-    {
-      name: 'risk_judge',
-      description: 'Validates a proposed action against risk limits',
-      systemPrompt: `You are a risk validation specialist. Assess the provided action
-        against the supplied risk limits and return a JSON object with approved (boolean)
-        and reason (string).`,
-      toolDefinitions: [getRiskLimitsDefinition],
-      toolHandlers: { get_risk_limits: getRiskLimitsHandler },
+        provided file and return structured trade rows.
+        Do not book trades. Do not ask questions. Just extract.`,
+      toolDefinitions: [returnExtractedTradesDefinition],
+      toolHandlers: { return_extracted_trades: returnExtractedTradesHandler },
     },
   ],
-};
+});
+```
+
+### `defineAgent` helper
+
+Use `defineAgent` when you need the config's `name` type preserved as a string literal — required for typed `requestSubAgent` calls and `ChatToolHandlers` generic wiring (see [TypeScript types](#typescript-types)):
+
+```ts
+import { defineAgent } from '@genesislcap/ai-assistant';
+
+export const tradeFileExtractorAgent = defineAgent({
+  name: 'trade_file_extractor',
+  // ...
+});
 ```
 
+Without `defineAgent`, TypeScript widens `name` to `string`, which loses the type safety on `requestSubAgent`'s name parameter.
+
 ---
 
-## Invocation API
+## Invoking a sub-agent
 
-Sub-agents are invoked from within tool handlers via `requestSubAgent`, available on the handler context alongside `requestInteraction`:
+Tool handlers receive `requestSubAgent` on their context object alongside `requestInteraction`:
 
 ```ts
-// ChatToolHandlers context (extended)
-context: {
-  requestInteraction: <T>(componentName: string, data: any) => Promise<T>,
-  requestSubAgent: <T = never>(name: string, options?: SubAgentRequestOptions) => Promise<T | string>,
+const processTradeFile = async (args, context) => {
+  const { file_name } = args as { file_name: string };
+
+  const result = await context.requestSubAgent('trade_file_extractor', {
+    task: `Extract all trade rows from the attached file named "${file_name}".`,
+  });
+
+  // result is either the structured value from completeSubAgent, or the
+  // sub-agent's final assistant message text as a string fallback.
+  return result;
+};
+```
+
+`requestSubAgent` is only present on the context when `subAgents` is declared on the parent agent config. Guard for its existence in reusable handlers:
+
+```ts
+if (!context.requestSubAgent) {
+  return { error: 'Sub-agent support is not available in this context.' };
 }
+```
 
+### `SubAgentRequestOptions`
+
+```ts
 interface SubAgentRequestOptions {
-  /** Plain-language description of what this specific invocation should do. */
+  /** Plain-language task description for this specific invocation. */
   task?: string;
-  /** Per-call override of the config-level historyCap. */
+
+  /**
+   * Caps how many parent history messages the sub-agent receives.
+   * Messages within the cap are passed verbatim; older messages have
+   * their tool call args and results masked. Overrides any config-level
+   * historyCap for this call.
+   */
   historyCap?: number;
+
   /**
-   * Extra dynamic data for this invocation. Injected as a primer message before
-   * the task so the sub-agent sees it as part of its context.
+   * Extra dynamic data for this invocation. Injected as a primer message
+   * immediately before the task, so the sub-agent sees it naturally as
+   * part of its context.
    */
   context?: Record<string, unknown>;
 }
 ```
 
-The return type is `T | string`:
-- `T` — when the sub-agent explicitly calls `completeSubAgent(result)` from within one of its tool handlers. The result is the structured value passed to `completeSubAgent`, fully typed.
-- `string` — when the sub-agent finishes its tool loop naturally with a plain text response, without calling `completeSubAgent`. This is always valid and requires no special tooling.
-
-With `T` defaulting to `never`, `T | string` collapses to `string` when no type parameter is provided — so untyped callers get a plain string with no extra ceremony.
-
-The `name` must match a declared sub-agent on the parent config — validated at call time with a clear error if not found.
-
-### `completeSubAgent`
-
-Sub-agent tool handlers receive `completeSubAgent` on their context. Calling it signals explicit completion with a structured result:
+---
 
-```ts
-// Sub-agent tool handler context
-context: {
-  requestInteraction: <T>(componentName: string, data: any) => Promise<T>,
-  completeSubAgent: (result: unknown) => void,
-}
-```
+## Returning structured results: `completeSubAgent`
 
-Example — a judge sub-agent with an explicit completion tool:
+By default, `requestSubAgent` returns the sub-agent's final assistant message text as a `string`. For structured data, define a completion tool on the sub-agent and call `completeSubAgent` from its handler:
 
 ```ts
-toolHandlers: {
-  submit_judgment: async (args, { completeSubAgent }) => {
-    completeSubAgent({ approved: args.approved, feedback: args.feedback });
-    return 'Judgment submitted.'; // still appended to the trace for debug visibility
+const toolHandlers: ChatToolHandlers = {
+  return_extracted_trades: async (args, context) => {
+    const { rows } = args as ExtractedTrades;
+    context.completeSubAgent?.({ rows });
+    return `Extracted ${rows.length} trade row(s).`; // still appended to trace
   },
-  get_risk_limits: async (args) => {
-    // normal tool — no completeSubAgent call needed
-    return fetchRiskLimits();
-  },
-}
+};
 ```
 
-When `completeSubAgent` is called, `SubAgentRunner` stores the result, and after that tool iteration completes the loop exits and resolves `requestSubAgent` with the stored value. If no tool ever calls `completeSubAgent`, the runner falls back to the final assistant message text.
+When `completeSubAgent` is called, the sub-agent's tool loop exits and `requestSubAgent` resolves with the value passed to `completeSubAgent`. If `completeSubAgent` is never called, the sub-agent runs to natural completion and returns its final text.
 
-The parent handler then gets fully typed structured data with no `JSON.parse`:
+The return type of `requestSubAgent<T>` is `T | string`:
+- `T` — when the sub-agent called `completeSubAgent(result)`. Fully typed, no `JSON.parse`.
+- `string` — when the sub-agent finished naturally without calling `completeSubAgent`.
+
+With `T` defaulting to `never`, `T | string` collapses to `string` when no type parameter is provided — untyped callers get a plain string with no extra ceremony.
 
 ```ts
-const result = await requestSubAgent<{ approved: boolean; feedback: string }>('risk_judge', {
-  task: `Validate this trade: ${JSON.stringify(args.trade)}`,
-  context: { limits: getCurrentRiskLimits() },
+const result = await context.requestSubAgent<ExtractedTrades>('trade_file_extractor', {
+  task: `Extract all trades from "${file_name}".`,
 });
 
 if (typeof result === 'string') {
-  // sub-agent returned plain text — handle gracefully
+  // handle gracefully — sub-agent returned plain text
 } else {
-  const { approved, feedback } = result;
+  const { rows } = result; // fully typed
 }
 ```
 
 ---
 
-## Runtime Mechanics
-
-### SubAgentRunner
+## TypeScript types
 
-A lightweight class that owns a sub-agent's execution. Creates its own private `ChatDriver` instance, completely isolated from the parent's history.
+`ChatToolHandlers` accepts an optional type parameter that narrows the `name` argument of `requestSubAgent` to the declared sub-agent names. Pass the agent config type via `typeof`:
 
-```
-SubAgentRunner
-  ├── Creates its own ChatDriver instance (sub-agent config)
-  ├── Builds the history snapshot from the parent (applying historyCap + masking if set)
-  ├── Prepends any call-time context as a primer message
-  ├── Sends the task string as the initial user message
-  └── Runs the tool loop to completion → returns the final assistant message text + trace
-```
-
-The parent's `ChatDriver` never sees the sub-agent's intermediate messages. It only receives the final string result when the handler's promise resolves — exactly as for any other tool.
+```ts
+import { defineAgent } from '@genesislcap/ai-assistant';
+import type { ChatToolHandlers } from '@genesislcap/foundation-ai';
 
-### Parallel execution
+const tradeFileExtractorAgent = defineAgent({
+  name: 'trade_file_extractor',
+  // ...
+});
 
-No special work needed. The parent's tool loop already runs all tool calls from a single LLM turn in parallel via `Promise.all`. If two tool handlers both call `requestSubAgent`, their `SubAgentRunner` instances start concurrently and the parent resumes after the last one resolves.
+// requestSubAgent name param is now typed as 'trade_file_extractor'
+const handlers: ChatToolHandlers<typeof tradeFileExtractorAgent> = {
+  process_trade_file: async (args, context) => {
+    // context.requestSubAgent('trade_file_extractor', ...) — type-checked
+    // context.requestSubAgent('typo', ...) — TypeScript error
+  },
+};
+```
 
-### History passed to the sub-agent
+For multiple sub-agents use a union:
 
-By default the sub-agent receives a read-only snapshot of the full parent history as primer context. With `historyCap: N`:
-- The last N messages are passed verbatim with full fidelity.
-- Messages older than N have tool call args and results masked — using the same `transformHistoryForAgent` function already in `OrchestratingDriver`. No new logic needed.
+```ts
+type Handlers = ChatToolHandlers<typeof agentA | typeof agentB>;
+```
 
-Any `context` object passed at call time is injected as an additional primer message immediately before the task, so the sub-agent sees it naturally as part of the conversation.
+The default (`{ name: string }`) leaves the name as `string` — no breaking change for existing handlers.
 
 ---
 
-## History & Debug
-
-All sub-agent activity is hidden behind the existing `showToolCalls` toggle — no new UI settings needed. Sub-agents are an implementation detail of a tool call and are treated as such.
-
-### What the parent sees (always)
+## History passed to the sub-agent
 
-A single `tool` role message containing the sub-agent's result. Compact, no noise.
+By default the sub-agent receives a snapshot of the full parent conversation history as context. The in-flight assistant message (the one containing the tool call that triggered the sub-agent) is excluded — it has unresolved tool calls that would confuse the sub-agent.
 
-```
-[tool] process_trade_file → '[{"instrument":"AAPL","qty":100,...}, ...]'
-```
-
-### What the debug view sees (`showToolCalls: true`)
-
-The `tool` message carries an additional `subAgentTrace` field (UI-only, stripped from provider calls — same pattern as `foldPath`/`foldEvent`):
+Use `historyCap` to limit how much history the sub-agent sees:
 
 ```ts
-// Extension to ChatToolResult
-interface ChatToolResult {
-  toolCallId: string;
-  content: string;
-  /** Full message history from the sub-agent run, for debug display only. */
-  subAgentTrace?: ChatMessage[];
-}
+subAgents: [
+  {
+    name: 'trade_file_extractor',
+    historyCap: 4,  // pass only the last 4 messages verbatim; mask older ones
+    // ...
+  },
+],
 ```
 
-The trace is rendered as a nested, collapsible conversation inside the parent tool call. It is breadcrumbed with the sub-agent name — consistent with how `foldPath` labels tool calls inside folds:
+Or override per call:
 
-```
-▼ process_trade_file
-    Trades Agent › trade_file_extractor
-    ├── [assistant] I'll parse the file and extract the trade data.
-    ├── [tool call] parse_csv(...)
-    ├── [tool result] ...
-    └── [complete] { trades: [...], warnings: [...] }
+```ts
+await context.requestSubAgent('trade_file_extractor', {
+  historyCap: 2,
+  task: '...',
+});
 ```
 
-The `agentName` field is already set on every message by `ChatDriver.appendToHistory` — the UI uses it as the breadcrumb label without any additional tagging.
-
-### Live activity indicator
-
-While a sub-agent is running, `SubAgentRunner` fires `sub-agent-start` / `sub-agent-stop` events (with `detail: { name: string }`) via an `onProgress` callback provided by the parent `ChatDriver`. The parent dispatches these on itself so `FoundationAiAssistant` can show a contextual activity label (e.g. "Consulting risk judge...") in the same overlay used for the orchestrating classifier. Hidden behind `showToolCalls: false` by default — visible only when tool calls are shown.
+Messages older than the cap have their tool call args and results replaced with a placeholder — the same masking used by the orchestrating driver for cross-agent history.
 
 ---
 
-## State Sharing
+## Parallel execution
 
-**Structured result via `completeSubAgent` (preferred)**
+No special work is required. The parent's tool loop runs all tool calls from a single LLM turn in parallel. If two tool handlers both call `requestSubAgent`, their executions start concurrently and the parent resumes after the last one resolves.
 
-Define an explicit completion tool on the sub-agent. When called, `completeSubAgent` resolves the `requestSubAgent` promise with a typed object — no `JSON.parse`, no brittle string parsing.
+---
 
-**Plain text fallback**
+## Live activity indicator
 
-If no tool calls `completeSubAgent`, the sub-agent's final assistant message text is returned as a `string`. Sufficient for simple cases where the sub-agent's response is human-readable prose the parent just forwards on.
+While a sub-agent is running, `FoundationAiAssistant` exposes two reactive properties you can bind in the host application:
 
-**Shared store via tools (for side-effects)**
+| Property | Type | Description |
+|---|---|---|
+| `liveSubAgentName` | `string \| null` | Name of the currently-running sub-agent, or `null` when idle. |
+| `liveSubAgentTrace` | `ChatMessage[]` | Growing history from the sub-agent's active tool loop. Cleared on stop. |
 
-A sub-agent that needs to write to shared application state can be given tools that do so directly. The parent reads that state via its own tools. No built-in bridge needed — this is normal tool use, wired up by the host app.
+These update in real time as the sub-agent produces messages, letting the host app show a live indicator (e.g. "Consulting trade extractor...") or stream the sub-agent's intermediate steps. The built-in template renders a `live-sub-agent-trace` panel while a sub-agent is active and hides it when it stops.
 
 ---
 
-## Implementation Plan
+## Debug trace
 
-### 1. Config (`config.ts`)
-- Add `subAgents?: AgentConfig[]` and `historyCap?: number` to `BaseAgentConfig`.
+When tool calls are visible (`showToolCalls: true`), each tool call that involved a sub-agent displays a collapsed trace panel. The trace shows the sub-agent's full message history — assistant turns, tool calls, and tool results — nested inside the parent tool call card, labelled with the sub-agent name.
 
-### 2. Types (`chat.types.ts`)
-- Add `SubAgentRequestOptions` interface.
-- Extend `ChatToolHandlers` handler context with `requestSubAgent` and `completeSubAgent`.
+The trace is stored on `ChatToolCall.subAgentTrace` (UI-only — never sent to the AI provider, same as `foldPath`).
 
-### 3. SubAgentRunner (`sub-agent-runner.ts`)
-New class, lives alongside `ChatDriver`:
-- Constructor: `(aiProvider, subAgentConfig, parentHistory: readonly ChatMessage[], onProgress: (event: 'start' | 'stop', name: string) => void)`
-- Method: `run(task: string, options?: SubAgentRequestOptions): Promise<{ result: unknown | string; trace: ChatMessage[] }>`
-- Applies `historyCap` masking, prepends `context` as a primer message, creates a `ChatDriver`.
-- Fires `onProgress('start', name)` before `sendMessage` and `onProgress('stop', name)` when the loop completes.
-- Provides `completeSubAgent` in the handler context. When called, stores the result and sets a completion flag.
-- After each tool iteration, checks the flag — if set, exits the loop and resolves with the stored value.
-- If the loop ends without `completeSubAgent` being called, resolves with the final assistant message text.
-- Ignores `subAgents` on the sub-agent config and logs a warning if present (leaf-only, v1).
-
-### 4. ChatDriver — `requestSubAgent` in handler context
-- In `applyAgent`, store `config.subAgents` as a map keyed by name.
-- When building the handler context object (currently `{ requestInteraction }`), add `requestSubAgent`: looks up the sub-agent config by name, constructs a `SubAgentRunner` with an `onProgress` callback that dispatches `sub-agent-start` / `sub-agent-stop` `CustomEvent`s on the `ChatDriver` itself, calls `runner.run(task, options)`, and returns the result.
-- If the sub-agent name is not found in the declared sub-agents, throws a descriptive error listing available names. This is caught by the existing tool error handler in `runToolLoop` and returned to the LLM as a tool result string — no special error path needed.
+---
 
-### 5. `ChatToolResult` — trace field (`chat.types.ts`)
-- Add `subAgentTrace?: ChatMessage[]` to `ChatToolResult`.
-- In `ChatDriver.runToolLoop`, after a handler resolves, attach the trace if present.
-- Strip `subAgentTrace` in `providerHistoryTransform` so it is never sent to the AI provider.
+## Complete example
 
-### 6. Debug UI
-- In the tool-calls panel, detect `toolResult.subAgentTrace` and render a collapsible nested conversation.
-- Style it distinctly (indented, labelled with the sub-agent name).
+The showcase app contains a working end-to-end example:
 
----
+- **Sub-agent config:** `packages/showcase/client-app/client/src/routes/ai/trades-assistant/sub-agents/trade-file-extractor.ts`
+- **Parent tool handler:** `process_trade_file` in `packages/showcase/client-app/client/src/routes/ai/trades-assistant/tools/trades-tools.ts`
+- **Parent agent wiring:** `packages/showcase/client-app/client/src/routes/ai/genesis-assistant/genesis-assistant.ts`
 
-## Resolved Questions
+The sub-agent (`trade_file_extractor`) defines a single `return_extracted_trades` tool that calls `completeSubAgent` with the parsed rows. The parent's `process_trade_file` handler calls `requestSubAgent<ExtractedTrades>('trade_file_extractor', { task: ... })` and receives the typed `ExtractedTrades` result.
 
-1. **Sub-agent of sub-agent?** Not supported in v1. Sub-agents are leaf nodes — `SubAgentRunner` ignores `subAgents` on the sub-agent config and logs a warning. Revisit if a concrete use case emerges.
-
-2. **Abort / cancellation**: Not needed. The driver registry PR (FUI-2495-ai-redux-store) decouples driver lifetime from DOM lifetime — a sub-agent that outlives a component disconnect simply completes against an unobserved driver. No abort mechanism required for v1.
+---
 
-3. **Token budget / concurrency cap**: Deferred. A concurrency cap can be added later as a semaphore in `SubAgentRunner` without any interface changes.
+## Constraints (v1)
 
-4. **History truncation**: Handled via `historyCap` on the sub-agent config (or overridden per-call). Messages within the cap are passed verbatim; older messages are masked using the existing `transformHistoryForAgent` function from `OrchestratingDriver`.
+- Sub-agents are leaf nodes — their own `subAgents` field is ignored. Nesting is not supported.
+- Sub-agents share the same `AIProvider` instance as the parent. They each make independent LLM calls.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@genesislcap/ai-assistant",
   "description": "Genesis AI Assistant micro-frontend",
-  "version": "14.421.1",
+  "version": "14.422.0",
   "license": "SEE LICENSE IN license.txt",
   "main": "dist/esm/index.js",
   "types": "dist/ai-assistant.d.ts",
@@ -64,24 +64,24 @@
     }
   },
   "devDependencies": {
-    "@genesislcap/foundation-testing": "14.421.1",
-    "@genesislcap/genx": "14.421.1",
-    "@genesislcap/rollup-builder": "14.421.1",
-    "@genesislcap/ts-builder": "14.421.1",
-    "@genesislcap/uvu-playwright-builder": "14.421.1",
-    "@genesislcap/vite-builder": "14.421.1",
-    "@genesislcap/webpack-builder": "14.421.1",
+    "@genesislcap/foundation-testing": "14.422.0",
+    "@genesislcap/genx": "14.422.0",
+    "@genesislcap/rollup-builder": "14.422.0",
+    "@genesislcap/ts-builder": "14.422.0",
+    "@genesislcap/uvu-playwright-builder": "14.422.0",
+    "@genesislcap/vite-builder": "14.422.0",
+    "@genesislcap/webpack-builder": "14.422.0",
     "@types/dompurify": "^3.0.5",
     "@types/marked": "^5.0.2"
   },
   "dependencies": {
-    "@genesislcap/foundation-ai": "14.421.1",
-    "@genesislcap/foundation-logger": "14.421.1",
-    "@genesislcap/foundation-redux": "14.421.1",
-    "@genesislcap/foundation-ui": "14.421.1",
-    "@genesislcap/foundation-utils": "14.421.1",
-    "@genesislcap/rapid-design-system": "14.421.1",
-    "@genesislcap/web-core": "14.421.1",
+    "@genesislcap/foundation-ai": "14.422.0",
+    "@genesislcap/foundation-logger": "14.422.0",
+    "@genesislcap/foundation-redux": "14.422.0",
+    "@genesislcap/foundation-ui": "14.422.0",
+    "@genesislcap/foundation-utils": "14.422.0",
+    "@genesislcap/rapid-design-system": "14.422.0",
+    "@genesislcap/web-core": "14.422.0",
     "dompurify": "^3.3.1",
     "marked": "^17.0.3"
   },
@@ -96,5 +96,5 @@
   "peerDependencies": {
     "@microsoft/fast-react-wrapper": ">=0.3.0"
   },
-  "gitHead": "ef3efc54221d1c0af5c842f0b98225ca813b4042"
+  "gitHead": "d596005408a80737f514e2d49b50c9dcc34b6913"
 }