@dxos/plugin-assistant 0.8.4-main.dedc0f3 → 0.8.4-main.dfabb4ec29

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

@@ -2,30 +2,42 @@
 // Copyright 2025 DXOS.org
 //
 
+// @vitest-environment jsdom
+
 import { EditorView } from '@codemirror/view';
 import { describe, it } from '@effect/vitest';
-import { Effect } from 'effect';
+import * as Effect from 'effect/Effect';
 
-import { type ContentBlock } from '@dxos/schema';
+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 { createMessage } from '#testing';
 
-import { blockToMarkdown } from './registry';
-import { MessageSyncer, type TextModel } from './sync';
+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 reset(text: string) {
-    this._view.dispatch({ changes: { from: 0, to: this._view.state.doc.length, insert: text } });
+  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 } });
+    this._view.dispatch({
+      changes: { from: this._view.state.doc.length, insert: text },
+    });
   }
 
   updateWidget(_id: string, _value: any) {}
@@ -36,19 +48,21 @@ describe('reducers', () => {
     'basic sync',
     Effect.fn(function* ({ expect }) {
       const doc = new TestDocument();
-      const syncer = new MessageSyncer(doc, blockToMarkdown);
+      const syncer = new MessageSyncer(doc, createBlockRenderer('thinking'));
 
       const messages = [
         createMessage('user', [{ _tag: 'text', text: 'Hello' }]),
         createMessage('assistant', [{ _tag: 'text', text: 'Hi there!' }]),
       ];
 
-      syncer.sync(messages);
-      expect(doc.content).toEqual(['\n<prompt>Hello</prompt>\n', 'Hi there!', ''].join('\n'));
+      syncer.update(messages);
+      expect(doc.content).toEqual('\n<prompt>Hello</prompt>\nHi there!\n');
 
-      messages[1].blocks.push({ _tag: 'text', text: 'How can I help?' });
-      syncer.sync(messages);
-      expect(doc.content).toEqual(['\n<prompt>Hello</prompt>\n', 'Hi there!', 'How can I help?', ''].join('\n'));
+      Obj.update(messages[1], (obj) => {
+        obj.blocks.push({ _tag: 'text', text: 'How can I help?' });
+      });
+      syncer.update(messages);
+      expect(doc.content).toEqual('\n<prompt>Hello</prompt>\nHi there!\nHow can I help?\n');
     }),
   );
 
@@ -56,26 +70,188 @@ describe('reducers', () => {
     'sync with partial updates',
     Effect.fn(function* ({ expect }) {
       const doc = new TestDocument();
-      const syncer = new MessageSyncer(doc, blockToMarkdown);
+      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.sync(messages);
-      expect(doc.content).toEqual(['\n<prompt>Hello</prompt>\n', 'Hi there!'].join('\n'));
+      syncer.update(messages);
+      expect(doc.content).toEqual('\n<prompt>Hello</prompt>\nHi there!');
+
+      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('\n<prompt>Hello</prompt>\nHi there! How are you?\nHow can I help?\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 }])];
 
-      const block = messages[1].blocks[0] as ContentBlock.Text;
-      block.text = 'Hi there! How are you?';
-      block.pending = false;
-      syncer.sync(messages);
+      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);
 
-      messages[1].blocks.push({ _tag: 'text', text: 'How can I help?' });
-      syncer.sync(messages);
-      expect(doc.content).toEqual(
-        ['\n<prompt>Hello</prompt>\n', 'Hi there! How are you?', 'How can I help?', ''].join('\n'),
-      );
+      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

@@ -2,15 +2,32 @@
 // Copyright 2025 DXOS.org
 //
 
-import { log } from '@dxos/log';
-import { type MarkdownStreamController } from '@dxos/react-ui-components';
-import { type XmlWidgetStateManager } from '@dxos/react-ui-editor';
-import { type ContentBlock, type DataType } from '@dxos/schema';
+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, 'reset' | 'append' | 'updateWidget'>;
+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.
@@ -18,96 +35,116 @@ export type TextModel = Pick<MarkdownStreamController, 'reset' | 'append' | 'upd
 export class MessageThreadContext implements Pick<MarkdownStreamController, 'updateWidget'> {
   constructor(private readonly _widgetState?: XmlWidgetStateManager) {}
 
-  updateWidget<T>(id: string, value: T) {
+  updateWidget<T>(id: string, value: StateDispatch<T>) {
     this._widgetState?.updateWidget(id, value);
   }
-}
 
-/**
- * Renders a block to markdown.
- */
-export type BlockRenderer = (
-  context: MessageThreadContext,
-  message: DataType.Message,
-  block: ContentBlock.Any,
-) => string | undefined;
+  // 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 _initialMessageId?: string;
-  private _currentMessageIndex = 0;
-  private _currentBlockIndex = 0;
-  private _currentBlockContent?: string;
+  private _threadId?: string;
+  private _completed = 0;
+  private _trailing = 0;
 
   private readonly _context: MessageThreadContext;
 
   constructor(
-    private readonly _model: TextModel,
-    private readonly _blockRenderer: BlockRenderer,
+    private readonly _document: TextModel,
+    private readonly _renderer: BlockRenderer,
   ) {
-    this._context = new MessageThreadContext(this._model);
+    this._context = new MessageThreadContext(this._document);
   }
 
   get context() {
     return this._context;
   }
 
-  reset() {
-    log('reset');
-    this._initialMessageId = undefined;
-    this._currentMessageIndex = 0;
-    this._currentBlockIndex = 0;
-    this._currentBlockContent = undefined;
-    void this._model.reset('');
+  /**
+   * 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);
+    });
   }
 
-  sync(messages: DataType.Message[]) {
-    log('sync', {
-      messages: messages.map((m) => m.blocks.length),
-      currentMessageIndex: this._currentMessageIndex,
-      currentBlockIndex: this._currentBlockIndex,
-      currentBlockContent: this._currentBlockContent,
-    });
-    if (this._initialMessageId !== messages[0]?.id) {
-      this.reset();
-      this._initialMessageId = messages[0]?.id;
+  /**
+   * 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;
+  }
 
-    let i = this._currentMessageIndex;
-    for (const message of messages.slice(this._currentMessageIndex)) {
-      if (i > this._currentMessageIndex) {
-        this._currentBlockIndex = 0;
-      }
-
-      this._currentMessageIndex = i;
-      let j = this._currentBlockIndex;
-      for (const block of message.blocks.slice(this._currentBlockIndex)) {
-        this._currentBlockIndex = j;
-        const currentBlockContent = this._blockRenderer(this._context, message, block);
-        if (currentBlockContent) {
-          let content: string = '';
-          if (this._currentBlockContent && currentBlockContent.startsWith(this._currentBlockContent)) {
-            content = currentBlockContent.slice(this._currentBlockContent.length);
-          } else {
-            content = currentBlockContent;
-          }
-
-          void this._model.append(content);
-          this._currentBlockContent = currentBlockContent;
-          log('append', { message: i, block: j, content });
+  /**
+   * 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) {
-          return;
-        } else {
-          this._currentBlockContent = undefined;
-          this._currentBlockIndex++;
+          // 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;
         }
-        j++;
+        this._completed = index + 1;
+        this._trailing = 0;
+        index++;
       }
-      i++;
     }
+    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>