Nested LLM node content: ordered chat blocks

0. Current implementation (checked against current code)

1. Expanded layout

• Render text directly as Markdown, with no LLM Reply heading.
• Reasoning summaries appear where they occurred and are collapsible by default. Show them only when the model returns a displayable summary; never infer or generate one.
• Function rows appear at invocation time; expand to view arguments, progress, results and errors from the referenced node.
• New text after a function follows its row and must not merge into the preceding text block.
• Internal signatures are not chat content.
• “Complete” means all displayable content is accessible. Large tool results may collapse or load on demand, but a truncated preview must not be the only accessible representation.

2. Execution tree and node-content responsibilities

• Collapsed card: name, status, duration and short preview.
• Expanded cards and right-side details use the same LlmNodeContent component; two implementations are prohibited.
• A function row references a real execution node. Clicking locates that node in the tree; do not copy tool state or results.

3. Model calls inside functions

• Recursion is supported: expanded functions show inner LLM calls using the same content component.
• Default: expand the selected LLM; show internal functions as summary rows until the user expands them.
• At the recursion limit, show an explicit boundary and an Open in details action; the detail panel renders that DAG node as a new content root.
• Persist expansion state by node_id, attempt_id, block_id in session UI state; streaming updates and remounting do not reset it.
• Render at most eight nested content levels. The limit hides further inline content only; it does not change the execution tree, tool state or history.
• Ordinary code functions show arguments, status, logs and return values. Nest model content only when the function contains model calls.

4. Parallel functions

• Only when execution actually starts a concurrent batch with known membership may multiple tool_call entries become one parallel_group block. The current Python dispatcher executes tool_call entries sequentially, so it does not publish group_id.
• Group order is invocation order, stably. Completion order changes status only, never row order.
• Every member carries the same group_id from its first publication. If the group ID is created only when the second member arrives, publish updated events with that ID for all earlier members. The frontend must not infer parallelism from adjacent tool rows.
• Function rows update independently; early completion must not move a row ahead of text.

5. Ordered block protocol (execution_stream.v1 extension)

Each LLM node_id maintains, within each attempt, ordered blocks[]. Execution determines ordering; the frontend must not infer it from WS arrival time.

Continuation vs. failure retry

• Continuation after normal tools: append text / tool_ref within the same attempt.
• Failure retry: create a new attempt and show the boundary; new output must not join the prior incomplete Markdown.
• Duplicate events: the same qualified occurrence_id does not create a second row; raw tool_call_id may repeat in different provider rounds.
• Late tool node: first show a placeholder tool_ref with a stable ID, then fill in tree data.
• If a provider round produces tool results, the next model request continues writing to the same attempt. A new attempt appears only when the recovery policy explicitly calls start_attempt(reason=...).

{
  "type": "execution_stream",
  "schema_version": 1,
  "op": "block_started",
  "node_id": "call_9f3e",
  "attempt_id": "att_2",
  "block_id": "blk_tool_7",
  "block_index": 4,
  "kind": "tool_ref",
  "tool_call_id": "call_abc",
  "occurrence_id": "occ_7e4c",
  "ref_node_id": "exec_read_file_01",
  "group_id": "par_1"
}

6. Markdown streaming and scrolling

• Reuse the top-level chat renderMarkdown / ThinkingStep / FunctionStep presentation and safety policies.
• Incrementally update active text blocks; do not rerender entire completed blocks.
• Unclosed code fences, tables or links must not make the whole region disappear.
• Virtualize large content by block or load it on demand.
• Follow while at the bottom; scrolling up stops following. Function expansion and syntax highlighting should preserve the reading position.
• Copy text differs from Copy full execution record; the latter may include reasoning and tool arguments.

7. Disconnect / refresh / failure

• Persist ordered blocks, function references and attempts. Do not store only the final reply and reconstruct interleaving from the tree later.
• After refresh, interleaving matches the live view; completed functions must not appear running.
• Retain incomplete text and mark interruption, cancellation or failure.
• For reasoning not persisted, show “This content was not saved” rather than an empty success state.
• Recover from snapshots; never call a model merely to render history.
• Live and durable snapshots retain complete displayable block content; only compatibility preview fields may be limited.
• Historical reads prefer metadata.stream.snapshot; for legacy records, build a single legacy attempt from metadata.blocks and retain persisted tool blocks. Unresolved references show an unresolved state and retain tool_call_id.

8. Implementation order

1. Ordered protocol and persistence: extend kinds, tool_ref and parallel_group; persist complete attempt.blocks in metadata and checkpoints.
2. Unified content component LlmNodeContent: reuse chat Markdown, collapsible reasoning and function rows that read the tree only.
3. Connect node details: remove Reply/Reasoning sections and verify sequence, refresh and recovery.
4. Reuse the same component for expanded cards.
5. Parallelism, recursion, retry boundaries and scrolling acceptance.

9. Required acceptance scenarios

The model emits Markdown, calls two functions in parallel, one function calls an inner model with read_file, and the outer model continues. Disconnect and refresh during execution. After recovery, block order, function states and hierarchy must match the earlier live state.

• No Reply/Reasoning header bars.
• Parallel members are not reordered by completion.
• Retries show attempt boundaries without joining incomplete Markdown.
• tool_ref and tree nodes correspond one to one without duplicate result copies.
• After the owner disappears, historical reads restore identical block ordering; recovered tool state comes from persistent DAG nodes.

Implementation status

Interaction example