` element for the `fallback="text"` kind's preformatted
result text (only present in that mode). `fallback-copy` — the `` shown when
`copyable` is set alongside the `fallback="text"` kind (only present when both are set).

**Themeable custom properties:** `--lr-tool-result-view-font` (default `var(--lr-font-mono)`, the
library's shared monospace stack, so a `--lr-theme-font-family-mono` override reaches it) — only used by the
`fallback="text"` kind's `[part='fallback-text']`. Otherwise none — the component's own styling is
deliberately minimal; all visible styling comes from whatever renderer/``/
``/`` child is currently mounted.

**Optional peer deps:** none required by the component itself — individual registered renderers may
of course pull in whatever they need (a charting library, a markdown renderer), which is exactly what
the lazy `load()` path in the registry exists for.

```html


```

### `registerToolRenderer()` and the tool-renderer registry (`registry.ts`)

A type-keyed dispatch registry — a tiny plugin system so a host app can teach
`` how to draw the result of e.g. a `get_weather` or `run_query` tool call
without this library knowing anything about either. Every registered instance dispatches against
this same module-level registry unless a given ``'s `registry` property is
set to a different readonly map snapshot.

**`ToolRendererDefinition`** — an exclusive
`DirectToolRendererDefinition | LazyToolRendererDefinition` union. Runtime registration, custom
registry lookup, and loaded-module boundaries validate the same shape, so plain JavaScript cannot
silently register `{}`, combine `render` with `load`, or cache an invalid loaded definition:

- direct: `render: (result: unknown, args: unknown, context?: ToolRenderContext) => unknown` and
  `load?: never` — renders the
  result (and the args that produced it) as UI. Typed as `unknown` rather than Lit's
  `TemplateResult` so any lit-html-renderable value works (a plain string, a DOM node, an array of
  templates) — consumers already own their own Lit import and don't need this module to add one.
  The 3rd `context` argument is additive: it's the _last_ positional parameter, so a pre-existing
  2-arg `render(result, args)` function stays assignable to this type unchanged — JS/TS function
  assignability allows an implementation with fewer parameters than its declared type. Direct
  callers may omit `context`; component invocations always provide it. Use
  `context?.reportStatus(status)` (see `ToolRenderContext` below) to signal a non-throwing outcome
  — e.g. an application-level failure the renderer still drew real UI for — instead of throwing,
  which discards that UI for the `` fallback instead
- either branch may include `matches?: (payload: unknown) => boolean` — facade/shape-based dispatch predicate, consulted only
  when no exact `toolName` key matches (see dispatch order below); only ever consulted _before_
  `load` resolves when supplied inline at registration time — a definition that needs shape-based
  dispatch and also wants to lazy-load its `render` should register a lightweight synchronous
  `matches` up front alongside `load`
- lazy: `load: () => Promise` and `render?: never` — lazy loader
  for a code-split renderer, so a host app can defer the cost of a rarely-used or heavy renderer
  (e.g. one pulling in a charting library) instead of paying for it on every page that merely
  registers it. Resolves to either a definition directly, or a `{ default }`-shaped module namespace
  object, so `load: () => import('./my-renderer.js')` works unmodified when that module's default
  export is itself a `ToolRendererDefinition`

**`ToolRenderContext`** — the shape of `render()`'s 3rd argument:

- `reportStatus: (status: ToolResultStatus) => void` — reports this render's outcome without
  throwing. `ToolResultStatus` is `'pending' | 'running' | 'success' | 'error' | 'denied'`, the same
  union ``/`` use, re-exported from this module. Calling
  it is entirely optional: a renderer that never calls it leaves ``'s `status`
  property at its default, `'success'`. This threads through the lazy `load()` path exactly the
  same way — a `render()` resolved via `load()` receives the same 3rd `context` argument as one
  registered directly.

```ts
registerToolRenderer("run_query", {
  render: (result, _args, context) => {
    if ((result as { rows?: unknown[] })?.rows === undefined) {
      context?.reportStatus("error");
      return html`
The query returned no result set.
`;
    }
    return html``;
  },
});
```

**Exports:**

- `registerToolRenderer(name: string, def: ToolRendererDefinition): void` — registers (or
  overwrites) the renderer for `name` in the module-level default registry
- `getDefaultToolRendererRegistry(): ToolRendererRegistry` — returns the default `Map` that
  `registerToolRenderer()` writes to and every `` reads from unless its own
  `registry` prop is set
- `findToolRenderer(toolName: string, payload: unknown, registry?: ToolRendererRegistry):
ToolRendererDefinition | undefined` — the dispatch function `` calls
  internally on every resolve; exposed for direct use too
- `loadToolRenderer(def: ToolRendererDefinition): Promise` — resolves `def`
  to a definition guaranteed to carry a real `render`, awaiting/unwrapping `def.load()` when present
  (or returning `def` unchanged otherwise)
- `clearToolRenderers(): void` — clears the default registry and its `load()` cache

**Dispatch order** (`findToolRenderer`), exactly as ``'s own `resolve()` uses
it:

1. An exact `toolName` key match in the registry.
2. Failing that, the first entry — in registration order, since a `Map` already iterates that way —
   whose `matches(payload)` returns `true`. Useful when several tool names share one result shape
   (e.g. every `*_search` tool returning `{ results: [...] }`) or when the caller doesn't reliably
   know the tool name at all.
3. `undefined` if neither matches — `` falls back to `` and
   fires `lr-render-error`.

Once a definition is found, if it carries `load`, `` shows a
decorative `` while `loadToolRenderer()` resolves it.
The nested skeleton has announcements disabled; the stable `base` busy state and an ordinary,
visually hidden localized Loading label expose the in-progress state without creating a shadow-root
live region. The resolved
`load()` promise is cached keyed by _definition object identity_ (a `WeakMap`, not by tool-name
string) — two different registries that happen to reuse the same tool-name string get independently
cached loads, and any given lazy definition's `load()` runs at most once no matter how many times
it's dispatched to, across every `` instance that resolves to it. A **rejected**
`load()` is _not_ cached — nor is a load that resolves to an invalid/another-lazy definition. The
definition stays registered, so a later resolution attempt (e.g. after a transient network failure)
gets a fresh `load()` call rather than being stuck replaying one failed promise forever.

```ts
import { registerToolRenderer } from "@aceshooting/lyra-ui/components/agent-tools/tool-result-view/registry.js";

registerToolRenderer("get_weather", {
  render: (result, args) =>
    html``,
});

// Lazily loaded, shape-based fallback for every *_search tool:
registerToolRenderer("web_search", {
  matches: (payload) =>
    typeof payload === "object" && payload !== null && "results" in payload,
  load: () => import("./search-result-renderer.js"), // default export is a ToolRendererDefinition
});
```

**Known gotchas:**

- `` re-resolves (re-runs the full dispatch → load → render pipeline)
  whenever `toolName`, `result`, `args`, or `registry` changes, or on first update — a stale
  in-flight `load()` superseded by a newer change is detected via an internal generation counter and
  its result is discarded rather than clobbering a more recent render
- registering under the same `name` twice silently overwrites the earlier definition — there is no
  warning or error
- `matches` is a linear scan over every registered definition's `matches` in registration order; it
  only runs when the exact-name lookup misses, so tool names with a direct registration never pay
  that scan cost
- `status` is reset to `'success'` immediately before every `render()` call, not merely at
  construction — a renderer that reported `'error'` on one result does not leave that status
  behind once dispatch moves on to a different (quiet) renderer; a `reportStatus()` call that
  arrives asynchronously after a _newer_ resolve has already started (a stale promise the previous
  render kicked off) is detected via the same generation counter as the `load()` staleness guard
  and discarded rather than clobbering the newer status
- **don't type a custom renderer against a hand-rolled, over-generic function signature** (e.g.
  `render: (...args: any[]) => unknown`, or a locally-declared narrower alias then cast to
  `ToolRendererDefinition`) — write the registration as a plain object literal (as in every example
  above) or annotate it as `ToolRendererDefinition` directly, so TypeScript checks the actual
  current `render`/`matches`/`load` shape, including the `context: ToolRenderContext` 3rd
  parameter and the exact `ToolResultStatus` string union `reportStatus` accepts. A loosened/`any`
  signature type-checks either way but silently gives up the compiler's ability to catch a typo'd
  status string or a dropped `context` parameter
- `fallback` implements exactly two kinds, `"json"` and `"text"`; any _other_ runtime value
  normalizes to reflected `"json"`, while `"text"` with a non-string result uses the JSON view.
  Only `"text"` renders
  `[part="fallback-text"]`/`[part="fallback-copy"]`

---