@dxos/plugin-assistant 0.8.4-main.f5c0578 → 0.8.4-main.fcc0d83b33

package/src/components/ChatThread/sync.test.ts

@@ -0,0 +1,259 @@
+//
+// Copyright 2025 DXOS.org
+//
+
+// @vitest-environment jsdom
+
+import { EditorView } from '@codemirror/view';
+import { describe, it } from '@effect/vitest';
+import * as Effect from 'effect/Effect';
+
+import { Obj } from '@dxos/echo';
+import { type Mutable } from '@dxos/echo/internal';
+import { type ContentBlock, type Message } from '@dxos/types';
+
+import { createMessage } from '#testing';
+
+import { createBlockRenderer } from './registry';
+import { type BlockRenderer, MessageSyncer, type MessageThreadContext, type TextModel } from './sync';
+
+class TestDocument implements TextModel {
+  private readonly _view = new EditorView({ extensions: [] });
+
+  get length() {
+    return this._view.state.doc.length;
+  }
+
+  get content() {
+    return this._view.state.doc.toString();
+  }
+
+  async setContent(text: string) {
+    this._view.dispatch({
+      changes: { from: 0, to: this._view.state.doc.length, insert: text },
+    });
+  }
+
+  async append(text: string) {
+    this._view.dispatch({
+      changes: { from: this._view.state.doc.length, insert: text },
+    });
+  }
+
+  updateWidget(_id: string, _value: any) {}
+}
+
+describe('reducers', () => {
+  it.effect(
+    'basic sync',
+    Effect.fn(function* ({ expect }) {
+      const doc = new TestDocument();
+      const syncer = new MessageSyncer(doc, createBlockRenderer('thinking'));
+
+      const messages = [
+        createMessage('user', [{ _tag: 'text', text: 'Hello' }]),
+        createMessage('assistant', [{ _tag: 'text', text: 'Hi there!' }]),
+      ];
+
+      syncer.update(messages);
+      expect(doc.content).toEqual(['<prompt>Hello</prompt>', 'Hi there!', ''].join('\n'));
+
+      Obj.update(messages[1], (obj) => {
+        obj.blocks.push({ _tag: 'text', text: 'How can I help?' });
+      });
+      syncer.update(messages);
+      expect(doc.content).toEqual(['<prompt>Hello</prompt>', 'Hi there!', 'How can I help?', ''].join('\n'));
+    }),
+  );
+
+  it.effect(
+    'sync with partial updates',
+    Effect.fn(function* ({ expect }) {
+      const doc = new TestDocument();
+      const syncer = new MessageSyncer(doc, createBlockRenderer('thinking'));
+
+      const messages = [
+        createMessage('user', [{ _tag: 'text', text: 'Hello' }]),
+        createMessage('assistant', [{ _tag: 'text', text: 'Hi there!', pending: true }]),
+      ];
+
+      syncer.update(messages);
+      expect(doc.content).toEqual(['<prompt>Hello</prompt>', 'Hi there!'].join('\n'));
+
+      Obj.update(messages[1], (obj) => {
+        const block = obj.blocks[0] as Mutable<ContentBlock.Text>;
+        block.text = 'Hi there! How are you?';
+        block.pending = false;
+      });
+      syncer.update(messages);
+
+      Obj.update(messages[1], (obj) => {
+        obj.blocks.push({ _tag: 'text', text: 'How can I help?' });
+      });
+      syncer.update(messages);
+      expect(doc.content).toEqual(
+        ['<prompt>Hello</prompt>', 'Hi there! How are you?', 'How can I help?', ''].join('\n'),
+      );
+    }),
+  );
+
+  // Regression: streaming reasoning text that passes through a bare list-marker state
+  // (e.g. `"…\n1. "`) used to make `stripBulletLikeLinePrefixes` collapse the line to empty,
+  // breaking the prefix-diff invariant in `MessageSyncer` and producing a duplicate `<reasoning>`
+  // opening tag in the document.
+  it.effect(
+    'streaming reasoning with list-marker transitions does not duplicate opening tag',
+    Effect.fn(function* ({ expect }) {
+      const doc = new TestDocument();
+      const syncer = new MessageSyncer(doc, createBlockRenderer('thinking'));
+
+      const setReasoning = (message: Message.Message, text: string, pending: boolean) => {
+        Obj.update(message, (message) => {
+          const block = message.blocks[0] as Mutable<ContentBlock.Reasoning>;
+          block.reasoningText = text;
+          block.pending = pending;
+        });
+      };
+
+      const messages = [createMessage('assistant', [{ _tag: 'reasoning', reasoningText: 'abc\n1', pending: true }])];
+
+      // Tick 1: `"abc\n1"` — `\d+[.)]\s` regex does not match (no dot/space yet).
+      syncer.update(messages);
+
+      // Tick 2: `"abc\n1."` — still no match (no trailing whitespace).
+      setReasoning(messages[0], 'abc\n1.', true);
+      syncer.update(messages);
+
+      // Tick 3: `"abc\n1. "` — line `"1. "` matches and is stripped to empty.
+      setReasoning(messages[0], 'abc\n1. ', true);
+      syncer.update(messages);
+
+      // Tick 4: `"abc\n1. foo"` — list item with content.
+      setReasoning(messages[0], 'abc\n1. foo', true);
+      syncer.update(messages);
+
+      // Tick 5: finalize.
+      setReasoning(messages[0], 'abc\n1. foo', false);
+      syncer.update(messages);
+
+      const openTagCount = (doc.content.match(/<reasoning>/g) ?? []).length;
+      const closeTagCount = (doc.content.match(/<\/reasoning>/g) ?? []).length;
+      expect(openTagCount).toBe(1);
+      expect(closeTagCount).toBe(1);
+    }),
+  );
+
+  // Regression: prompt "respond with your name inside an xml tag" produces a streamed
+  // reasoning block followed by a text block containing a non-registered XML tag
+  // (`<name>Claude</name>`). The text block must appear in the document AFTER the
+  // closed reasoning block — the bug symptom is the reasoning tag rendering with no
+  // follow-up response visible.
+  it.effect(
+    'reasoning block followed by text containing a non-registered xml tag',
+    Effect.fn(function* ({ expect }) {
+      const doc = new TestDocument();
+      const syncer = new MessageSyncer(doc, createBlockRenderer('thinking'));
+
+      const setReasoning = (message: Message.Message, text: string, pending: boolean) => {
+        Obj.update(message, (message) => {
+          const block = message.blocks[0] as Mutable<ContentBlock.Reasoning>;
+          block.reasoningText = text;
+          block.pending = pending;
+        });
+      };
+
+      const setText = (message: Message.Message, text: string, pending: boolean) => {
+        Obj.update(message, (message) => {
+          const block = message.blocks[1] as Mutable<ContentBlock.Text>;
+          block.text = text;
+          block.pending = pending;
+        });
+      };
+
+      // Tick 1: reasoning starts streaming.
+      const messages = [createMessage('assistant', [{ _tag: 'reasoning', reasoningText: 'Thinking', pending: true }])];
+      syncer.update(messages);
+
+      // Tick 2: reasoning grows.
+      setReasoning(messages[0], 'Thinking about the answer', true);
+      syncer.update(messages);
+
+      // Tick 3: reasoning closes.
+      setReasoning(messages[0], 'Thinking about the answer', false);
+      syncer.update(messages);
+
+      // Tick 4: text block appears, pending and empty (model has started emitting but text is still '').
+      Obj.update(messages[0], (message) => {
+        message.blocks.push({ _tag: 'text', text: '', pending: true });
+      });
+      syncer.update(messages);
+
+      // Tick 5: partial text — opening tag only.
+      setText(messages[0], '<name>', true);
+      syncer.update(messages);
+
+      // Tick 6: full text streamed.
+      setText(messages[0], '<name>Claude</name>', true);
+      syncer.update(messages);
+
+      // Tick 7: text finalised.
+      setText(messages[0], '<name>Claude</name>', false);
+      syncer.update(messages);
+
+      // Both the closed reasoning tag and the response text must be present.
+      expect(doc.content).toContain('<reasoning>Thinking about the answer</reasoning>');
+      expect(doc.content).toContain('<name>Claude</name>');
+
+      const openReasoning = (doc.content.match(/<reasoning>/g) ?? []).length;
+      const closeReasoning = (doc.content.match(/<\/reasoning>/g) ?? []).length;
+      expect(openReasoning).toBe(1);
+      expect(closeReasoning).toBe(1);
+    }),
+  );
+
+  // Direct test of `MessageSyncer`'s tolerance for non-monotonic renderer output —
+  // any renderer that produces a shorter string for the same streaming block (e.g., due
+  // to whitespace normalisation or future transforms) must not produce duplicate output.
+  it.effect(
+    'non-monotonic renderer output does not duplicate previously-emitted content',
+    Effect.fn(function* ({ expect }) {
+      const doc = new TestDocument();
+
+      const renderer: BlockRenderer = (_ctx: MessageThreadContext, _msg: Message.Message, block: ContentBlock.Any) => {
+        if (block._tag !== 'reasoning') {
+          return undefined;
+        }
+        const text = block.reasoningText ?? '';
+        // Simulate a non-monotonic transform: collapse a line that is a sole digit+dot+space.
+        const normalised = text
+          .split(/\r?\n/)
+          .map((line) => line.replace(/^\s*\d+[.)]\s$/, ''))
+          .join('\n')
+          .trim();
+        return block.pending ? `<reasoning>${normalised}` : `<reasoning>${normalised}</reasoning>\n`;
+      };
+
+      const syncer = new MessageSyncer(doc, renderer);
+
+      const messages = [createMessage('assistant', [{ _tag: 'reasoning', reasoningText: 'abc\n1.', pending: true }])];
+
+      syncer.update(messages);
+      Obj.update(messages[0], (obj) => {
+        const block = obj.blocks[0] as Mutable<ContentBlock.Reasoning>;
+        block.reasoningText = 'abc\n1. ';
+      });
+      syncer.update(messages);
+      Obj.update(messages[0], (obj) => {
+        const block = obj.blocks[0] as Mutable<ContentBlock.Reasoning>;
+        block.reasoningText = 'abc\n1. tail';
+        block.pending = false;
+      });
+      syncer.update(messages);
+
+      const openTagCount = (doc.content.match(/<reasoning>/g) ?? []).length;
+      const closeTagCount = (doc.content.match(/<\/reasoning>/g) ?? []).length;
+      expect(openTagCount).toBe(1);
+      expect(closeTagCount).toBe(1);
+    }),
+  );
+});

package/src/components/ChatThread/sync.ts

@@ -0,0 +1,150 @@
+//
+// Copyright 2025 DXOS.org
+//
+
+import { type DXN } from '@dxos/echo';
+import { type MarkdownStreamController } from '@dxos/react-ui-markdown';
+import { type ContentBlock, type Message } from '@dxos/types';
+import { type StateDispatch, type XmlWidgetStateManager } from '@dxos/ui-editor';
+
+import { rehydrateToolWidgetsFromMessages } from './tool-widget-state';
+
+/**
+ * Update document.
+ */
+export type TextModel = Pick<MarkdownStreamController, 'length' | 'setContent' | 'append' | 'updateWidget'>;
+
+/**
+ * Renders a block to markdown.
+ *
+ * Contract: for any block whose lifetime spans multiple invocations (i.e. a streaming block
+ * with `pending: true` whose content grows over time, transitioning to `pending: false`), the
+ * sequence of returned strings must be monotonically extending — each subsequent value must be
+ * a string-extension of the previous. The {@link MessageSyncer} relies on this invariant to
+ * compute appendable deltas without diffing.
+ */
+export type BlockRenderer = (
+  context: MessageThreadContext,
+  message: Message.Message,
+  block: ContentBlock.Any,
+) => string | undefined;
+
+/**
+ * Thread context passed to renderer.
+ */
+export class MessageThreadContext implements Pick<MarkdownStreamController, 'updateWidget'> {
+  constructor(private readonly _widgetState?: XmlWidgetStateManager) {}
+
+  updateWidget<T>(id: string, value: StateDispatch<T>) {
+    this._widgetState?.updateWidget(id, value);
+  }
+
+  // TODO(burdon): Resolve name from hypergraph.
+  getObjectLabel(_id: DXN) {
+    return 'Object';
+  }
+}
+
+/**
+ * Syncs messages with the editor.
+ *
+ * Reflects the AI streaming contract:
+ * - Messages and their blocks are appended in order.
+ * - Only the last block in `messages` may be `pending`; all earlier blocks are finalized.
+ * - The renderer's output for a streaming block grows monotonically (see {@link BlockRenderer}).
+ * - The document is read-only outside this syncer.
+ *
+ * Under those rules the syncer needs only:
+ * - `_completed`: the flat-block index past which everything has been fully appended.
+ * - `_trailing`: chars of the in-flight block (at index `_completed`) already appended.
+ * - `_threadId`: identity sentinel; if `messages[0]?.id` changes, the document is replaced.
+ */
+export class MessageSyncer {
+  private _threadId?: string;
+  private _completed = 0;
+  private _trailing = 0;
+
+  private readonly _context: MessageThreadContext;
+
+  constructor(
+    private readonly _document: TextModel,
+    private readonly _renderer: BlockRenderer,
+  ) {
+    this._context = new MessageThreadContext(this._document);
+  }
+
+  get context() {
+    return this._context;
+  }
+
+  /**
+   * Replace the document with the rendering of `messages`. Use on mount, on thread switch,
+   * and from {@link update} when it detects an identity change in `messages[0]`.
+   */
+  reset(messages: Message.Message[] = []): void {
+    this._threadId = messages[0]?.id;
+    this._completed = 0;
+    this._trailing = 0;
+    const buffer = this._walk(messages);
+    // Match the pre-rewrite behaviour: rendering from a steady state (initial mount with
+    // non-empty messages, or thread switch) lands the entire content via `setContent` — which
+    // uses `wireBypass`, so the editor jumps straight to the final text and `update()` returns
+    // `true` so the caller can scroll to the bottom. Live streaming partials that arrive
+    // *after* this initial render flow through `update()`'s incremental path → `_document.append`
+    // → wire's drip filter, preserving the char-by-char typewriter for incoming text.
+    void this._document.setContent(buffer).then(() => {
+      rehydrateToolWidgetsFromMessages(this._context, messages);
+    });
+  }
+
+  /**
+   * Stream the suffix of the rendered messages into the document.
+   * Returns `true` if the document was replaced (initial mount or thread switch), `false`
+   * if the call was a streaming append (or a no-op).
+   */
+  update(messages: Message.Message[]): boolean {
+    if (messages[0]?.id !== this._threadId) {
+      this.reset(messages);
+      return true;
+    }
+    const buffer = this._walk(messages);
+    if (buffer.length > 0) {
+      void this._document.append(buffer);
+    }
+    return false;
+  }
+
+  /**
+   * Walk flat blocks starting at `_completed`, advancing the cursors and returning the chars
+   * to append. Blocks before `_completed` are skipped — their renderer is never re-invoked,
+   * which preserves single-shot side effects (e.g. tool widget state mutation).
+   */
+  _walk(messages: Message.Message[]): string {
+    let buffer = '';
+    let index = 0;
+    outer: for (const message of messages) {
+      for (const block of message.blocks) {
+        if (index < this._completed) {
+          index++;
+          continue;
+        }
+        const rendered = this._renderer(this._context, message, block) ?? '';
+        if (rendered.length > this._trailing) {
+          buffer += rendered.slice(this._trailing);
+        }
+        if (block.pending) {
+          // Stay on this block; record how far we've appended so the next call can resume.
+          // `Math.max`-style guard against a non-monotonic renderer output without shrinking the doc.
+          if (rendered.length > this._trailing) {
+            this._trailing = rendered.length;
+          }
+          break outer;
+        }
+        this._completed = index + 1;
+        this._trailing = 0;
+        index++;
+      }
+    }
+    return buffer;
+  }
+}

package/src/components/ChatThread/testing/reasoning.md

@@ -0,0 +1,25 @@
+<prompt>How should I structure a CLI tool with subcommands?</prompt>
+
+<reasoning>
+The user is asking about CLI subcommand structure. Let me think through what they likely care about:
+
+1. Discoverability — every subcommand needs help text and a flat top-level listing.
+2. Composability — subcommands should be invokable individually for scripting.
+3. Shared concerns — auth, config, logging should not be duplicated per command.
+
+A few patterns worth considering:
+
+- A single binary that dispatches to subcommand handlers (like `git`, `kubectl`).
+- A plugin model where subcommands live in separate binaries on the PATH (like `git-foo`).
+- A library that each subcommand wraps as a thin executable.
+
+The plugin model wins for very large surfaces but adds packaging cost. For a tool with under ~30 subcommands the dispatcher pattern stays clearer.
+</reasoning>
+
+For a CLI with a moderate set of subcommands, the dispatcher pattern is usually the right default:
+
+1. One binary, one entry point.
+2. Subcommands registered as handlers off a shared root.
+3. Cross-cutting concerns (auth, config, logging) wired in at the root and inherited.
+
+If you grow past ~30 subcommands or want third-party extensions, switch to a plugin model where binaries named `<tool>-<subcommand>` are discovered on the `PATH`.

package/src/components/ChatThread/testing/thinking.md

@@ -0,0 +1,21 @@
+<prompt>create a project to track what I order online based on my emails, dont asak me questions</prompt>
+<reasoning>The user wants me to create a project that tracks their online orders based on emails. They don't want me to ask questions - just go ahead and create it. Let me first get the project rules and query for available mailboxes/inboxes.</reasoning>
+<status>Getting the project rules and finding your mailboxes to set this up...</status>
+<toolCall id="toolu_01QJcUw8RZDyemLdvMe8nSGZ" />
+<toolCall id="toolu_01JJZrCc17JqV5r36aR9wcaj" />
+<toolCall id="toolu_012r3VQFxvWZ9UmKxMNiJP48" />
+<reasoning>The mailbox query failed. Let me try a different approach to find mailboxes. Let me also enable the inbox blueprint to find mailboxes, and create the Order schema first. Let me first search for mailboxes with a different query approach.</reasoning>
+<status>Looking for your mailboxes...</status>
+<toolCall id="toolu_01P4ekwYwYJfxUnGFPHNhcCu" />
+<toolCall id="toolu_017NHbtinMDcjmwqN6vLaNQp" />
+<reasoning>I found the mailbox with DXN `dxn:echo:B6ON2Y6HN4KLJWZD75VUUDCUQ552ERQSG:01KNHKXSWWCBZX6TCPMF1M0PDE`. Now I need to: 1. Create an Order schema for tracking online orders 2. Create the project with the right blueprints and subscriptions Let me first create the Order schema, then create the project.</reasoning>
+<status>Found your mailbox. Now creating an Order schema and setting up the project...</status>
+<toolCall id="toolu_01Gk4RcfdB4ttzsVN9mnatWn" />
+<status>Order schema created. Now creating the project...</status>
+<toolCall id="toolu_01QmJcua6jmRx15wnxo5bkNQ" />
+<reasoning>The service isn't available. Let me try again.</reasoning>
+<status>Encountered a temporary service issue. Retrying...</status>
+<toolCall id="toolu_01X4CVxXuBjgW2JESGUEsm6f" />
+<reasoning>The service seems to be temporarily unavailable. Let me try once more.</reasoning>
+<toolCall id="toolu_01S9vi1pMnwqUuxNpe5FU731" />
+Got the project created. Let me know if you need anything else.

package/src/components/ChatThread/testing/thread-1.md

@@ -0,0 +1,30 @@
+<prompt>What is markdown?</prompt>
+
+<reasoning>
+The user is asking me to think deeply about what markdown is.
+
+But given the context of our conversation - we've been trying to scrape slab data from a website - I think they might be hinting at something specific.
+</reasoning>
+
+### Markdown
+
+Markdown is a lightweight markup language used to format plain text in a simple and readable way.
+
+It allows you to create structured documents using conventions for headings, lists, emphasis (bold/italic), links, images, code, blockquotes, tables, and horizontal rules.
+
+Markdown documents look like this
+
+```
+# Markdown
+
+This is a plain text.
+```
+
+Composer supports extended components via XML tags.
+
+<summary>
+The user asked about Markdown.
+
+We responded with a summary.
+
+</summary>

package/src/components/ChatThread/testing/thread-2.md

@@ -0,0 +1,56 @@
+<prompt>hi</prompt>
+Hi! I'm Kai, your AI assistant powered by DXOS. I see you have a document in your context. Let me take a look at it to see how I can help you.
+<toolCall id="toolu_012MB5XWrQhsyjUBoBCr7jXB" />
+
+<summary>OK (1 tool uses · 2.62k tokens · 4.8s)</summary>
+I can see you have a comprehensive welcome document for Composer by DXOS. This document explains what Composer is - an extensible collaborative application with features like documents, diagrams, tables, and sheets.
+
+Here are some suggestions based on what's available:
+<suggestion>Create a new document</suggestion>
+<suggestion>Edit the welcome document</suggestion>
+<suggestion>Create a table to organize information</suggestion>
+<suggestion>Create a sketch for diagrams</suggestion>
+<suggestion>Learn about collaboration features</suggestion>
+
+Is there something specific you'd like to do with this document or would you like to explore other features of Composer?
+
+<summary>OK (3.91k tokens · 7.0s)</summary>
+<prompt>Create a table to organize information</prompt>
+I'll help you create a table to organize information. Let me check what table creation tools are available.
+<toolCall id="toolu_01Gk8ZNGYQEczAjGkbDZ9n1D" />
+<summary>OK (1 tool uses · 3.99k tokens · 3.4s)</summary>
+I need to check what artifact definitions are available for creating tables. Based on the blueprint instructions, I should first query for available artifact definitions to see what table-related tools I can use.
+
+However, I notice that the function definitions provided don't include the artifact-related tools mentioned in the blueprint (like `require_artifact_definitions` or table creation tools). The available functions are focused on document operations (open, diff, add-to-context, open-item) and analysis mode.
+
+Let me work with what's available. Since I can't directly create a table artifact with the current tools, I can help you create a table structure within a markdown document instead.
+
+Would you like me to:
+
+1. Create a simple markdown table structure in a new document that you can use to organize your information?
+2. Or would you prefer to use Composer's built-in Tables plugin (as mentioned in the welcome document) by creating one through the Composer interface?
+
+What kind of information are you looking to organize? This will help me suggest the best table structure for your needs.
+<toolCall id="toolu_01CQXUsyLw2uoV3k1mPLqFee" />
+
+<summary>OK (1 tool uses · 4.28k tokens · 11.1s)</summary>
+<summary>OK (4.30k tokens · 1.6s)</summary>
+
+<reasoning>Based on the rules, this is similar to the "Parcel tracking" example. I should: 1. First create an Order schema 2. Query for mailboxes to subscribe to 3. Query for available blueprints 4. Create the project Let me first ask a couple of qualifying questions, then proceed. Actually, the example is pretty clear - let me set things up. But first let me check for mailboxes and blueprints. Let me query for mailboxes and blueprints in parallel.</reasoning>
+
+<reasoning>I found a mailbox at `dxn:echo:B6ON2Y6HN4KLJWZD75VUUDCUQ552ERQSG:01KNHKXSWWCBZX6TCPMF1M0PDE`. Now I have everything I need to create the CRM project. The project should:
+
+1. Subscribe to the mailbox
+2. Use database, web-search, and browser blueprints
+3. Extract People and Organizations from emails
+4. Research contacts on the web
+5. Save to database avoiding duplicates
+6. Now I'm building the project structure to tie all these components together.</reasoning>
+
+<reasoning>I found the mailbox. Now I have all the information I need to create the CRM project. Let me create it with the appropriate blueprints and subscription to the mailbox. The project should:
+
+- Subscribe to the mailbox
+- On every email, extract People and Organizations
+- Save them to the database (checking for duplicates first)
+- Run web searches to enrich contact/org data
+- Blueprints needed: database, web-search, browser</reasoning>

package/src/components/ChatThread/testing/thread-widgets.md

@@ -0,0 +1,79 @@
+<prompt>Analyze this codebase and suggest improvements.</prompt>
+
+<reasoning>
+The user wants a comprehensive analysis of their codebase. I should examine the project structure, identify key patterns, and look for areas that could be improved. Let me start by reviewing the main source files and dependencies.
+</reasoning>
+
+I'll start by examining the project structure and key files.
+
+<toolCall id="toolu_01ABC123analyze" />
+
+<summary>Analyzed 42 files across 8 packages. Found 3 areas for improvement.</summary>
+
+Here's what I found after reviewing the codebase:
+
+## Architecture
+
+The project follows a modular plugin architecture with clear separation of concerns. Each plugin manages its own state and communicates through a shared event bus.
+
+## Suggested Improvements
+
+1. **Type Safety** — Several utility functions use `any` types that could be narrowed. This would catch bugs at compile time rather than runtime.
+
+2. **Error Handling** — The API layer could benefit from structured error types using discriminated unions instead of thrown exceptions.
+
+3. **Performance** — The subscription handlers in the data layer create new closures on every update. Memoizing these would reduce GC pressure.
+
+<reference ref="dxn:echo:@:123e4567-e89b-12d3-a456-426614174000">ProjectConfig</reference>
+
+Would you like me to dive deeper into any of these areas?
+
+<select>
+<option>Improve type safety</option>
+<option>Refactor error handling</option>
+<option>Optimize performance</option>
+</select>
+
+<suggestion>Show me the specific files that need type improvements</suggestion>
+
+<suggestion>Generate a refactoring plan as a document</suggestion>
+
+<stats>3 tool uses · 12.4k tokens · 18.2s</stats>
+
+<prompt>Improve type safety</prompt>
+
+<reasoning>
+The user chose to focus on type safety improvements. I should identify the specific files and patterns where `any` types are used unnecessarily and propose concrete fixes with before/after examples.
+</reasoning>
+
+Let me find all the locations where type safety can be improved.
+
+<toolCall id="toolu_01DEF456typescan" />
+
+<summary>Scanned 42 files. Found 17 instances of unnecessary `any` usage across 6 modules.</summary>
+
+Here are the key changes I recommend:
+
+### `src/utils/transform.ts`
+
+The `transform` function currently accepts `any` for its input parameter. We can use a generic constraint instead:
+
+```typescript
+// Before
+const transform = (input: any) => { ... }
+
+// After
+const transform = <T extends Record<string, unknown>>(input: T) => { ... }
+```
+
+### `src/handlers/events.ts`
+
+The event handler map uses `any` for callback types. A mapped type would preserve type information:
+
+```typescript
+type EventHandlers = {
+  [K in keyof EventMap]: (event: EventMap[K]) => void;
+};
+```
+
+<stats>1 tool use · 8.7k tokens · 12.1s</stats>

package/src/components/ChatThread/tool-widget-state.test.ts

@@ -0,0 +1,34 @@
+//
+// Copyright 2026 DXOS.org
+//
+
+import { describe, expect, test } from 'vitest';
+
+import { createMessage } from '#testing';
+
+import { rehydrateToolWidgetsFromMessages } from './tool-widget-state';
+
+describe('rehydrateToolWidgetsFromMessages', () => {
+  test('replays toolCall then toolResult in order', () => {
+    const calls: Array<{ id: string; kind: 'object' | 'function' }> = [];
+    const sink = {
+      updateWidget: (id: string, value: unknown) => {
+        calls.push({ id, kind: typeof value === 'function' ? 'function' : 'object' });
+      },
+    };
+
+    const messages = [
+      createMessage('assistant', [
+        { _tag: 'toolCall', toolCallId: 't1', name: 'foo', input: '{}', providerExecuted: false },
+        { _tag: 'toolResult', toolCallId: 't1', name: 'foo', result: '{}', providerExecuted: false },
+      ]),
+    ];
+
+    rehydrateToolWidgetsFromMessages(sink, messages);
+
+    expect(calls).toEqual([
+      { id: 't1', kind: 'object' },
+      { id: 't1', kind: 'function' },
+    ]);
+  });
+});