[Bug]: 2.2.7 collapses assistant text written before a tool call into the "Worked for …" block

What happens

Since 2.2.7, assistant text that is written before a tool call is treated as "work" and collapsed into the Worked for MM:SS block. Only the text written after the last tool call stays visible as the answer.

The user watches the first part of the answer stream in, then the turn completes and that part disappears into the collapsed work section. It reads as if the model silently shortened its own output.

Root cause

src/features/chat/rendering/MessageRenderer.ts, method finalizeResponse(), introduced in b1dcaa3c ("feat: collapse completed chat work and reveal actions on hover", #1272):

let finalStart = blocks.length;
while (finalStart > 0 && ['text', 'citations'].includes(blocks[finalStart - 1].type)) finalStart--;

The loop walks backwards from the end and stops at the first block that is not text or citations. So "the answer" is defined as only the uninterrupted trailing run of text blocks. Any tool_use block terminates the scan, and everything before it — including assistant prose — falls outside finalStart.

That set is then everything-but-the-answer:

const answerEls = new Set(children.filter(child => child.classList.contains('claudian-text-block')
  || child.classList.contains('claudian-citations')).slice(-finalBlockCount));
const workEls = children.filter(child => !answerEls.has(child));

workEls is reparented into the claudian-work wrapper behind the claudian-work-header button and collapsed.

The assumption is that anything preceding a tool call is progress noise. For coding agents that is often true. For an assistant that explains first and then acts, the most important part of the answer is precisely what comes before the tool call.

Worked example

One real turn, block structure taken from the Claude Code session JSONL:

finalStart resolves to 2 (block 1 stops the backward scan), so finalAnswer = block 2 only. Block 0 is classified as work and collapsed. The user loses 2,272 characters of answer from view — 62 % of the turn.

Control: the same content re-sent as a single text block (3,984 chars, no tool call) renders in full and stays visible. Length is not the trigger; the split is.

Expected

Assistant text blocks are answer content regardless of their position relative to tool calls. Only tool calls, their output, and thinking blocks should be collapsible as "work".

Suggested fix

Do not use "trailing run" as the definition of the answer. Either:

1. Treat all text/citations blocks as answer, and collapse only tool_use/tool_result/thinking blocks — keeping the interleaved order intact; or
2. Keep the current grouping but leave text blocks in place visually, collapsing only the tool elements between them; or
3. Make the behaviour configurable, defaulting to "never collapse assistant text".

Environment

• Claudian 2.2.7 (installed 2026-09-12 08:37)
• Obsidian 1.13.7, Linux (NixOS, AppImage via appimage-run)
• Claude Code CLI 2.1.263
• Default theme, no CSS snippets
• Model: Claude Opus 5 (1M context)

Notes

• The text is not lost — it is reachable by expanding the Worked for … header. But it is not discoverable: the user sees text vanish while reading and has no reason to suspect it moved into a work log.
• Possibly interacts with #1304 ("defer collapsed stored tool output until expansion").

Request

This affects every answer where the assistant explains before acting, which is the normal pattern for non-coding use of the plugin. Until it is fixed, the only workaround is to tell the assistant to emit no text before any tool call, which removes all intermediate progress information from the conversation.

A quick fix would be very much appreciated.

Questions about the intent

I would genuinely like to understand the reasoning, because the change looks deliberate rather than accidental:

1. Was assistant prose written before a tool call intentionally classified as "work", or is that a side effect of using the trailing run of text blocks as the definition of "the answer"?
2. Was the "explain → act → conclude" shape considered? It is the normal pattern whenever the plugin is used for something other than coding — research, writing, analysis — and in that shape the collapsed part is usually the substance of the reply.
3. Was there a reason not to keep text blocks in place and collapse only tool_use / tool_result / thinking elements?
4. Is a setting planned to opt out of collapsing, or is the collapsed state intended to become the permanent default?

The feature itself is good — a Worked for MM:SS summary over a long tool run is genuinely useful. The issue is only which elements end up inside it.