showsAssistantTrace parameter is always negated by the downstream filter

AssistantTextParser.segments(from:includeThinking:) is called with includeThinking: self.showsAssistantTrace. When showsAssistantTrace is true the function returns all segments — including .thinking ones. But the immediately-following .filter { $0.kind != .thinking } then unconditionally strips every .thinking segment regardless of that flag.

The net effect is that thinking-block content is always hidden during streaming, even when showsAssistantTrace is true. The includeThinking argument is therefore dead code and the PR description's claim — "correctly excluded from streaming view when showsAssistantTrace is false" — is misleading, because exclusion happens unconditionally.

If the intent is to always suppress thinking during streaming, simplify to:

If the intent is to honour showsAssistantTrace (show thinking when the flag is true), remove the redundant filter instead:

let segments = AssistantTextParser.segments(from: self.text, includeThinking: self.showsAssistantTrace)
return segments
    .map(\.text)
    .joined(separator: "\n\n")

This is a comment left during a code review.
Path: apps/shared/OpenClawKit/Sources/OpenClawChatUI/ChatMessageViews.swift
Line: 539-543

Comment:
**`showsAssistantTrace` parameter is always negated by the downstream filter**

`AssistantTextParser.segments(from:includeThinking:)` is called with `includeThinking: self.showsAssistantTrace`. When `showsAssistantTrace` is `true` the function returns **all** segments — including `.thinking` ones. But the immediately-following `.filter { $0.kind != .thinking }` then unconditionally strips every `.thinking` segment regardless of that flag.

The net effect is that thinking-block content is **always** hidden during streaming, even when `showsAssistantTrace` is `true`. The `includeThinking` argument is therefore dead code and the PR description's claim — "correctly excluded from streaming view when `showsAssistantTrace` is **false**" — is misleading, because exclusion happens unconditionally.

If the intent is to **always** suppress thinking during streaming, simplify to:

```suggestion
        let segments = AssistantTextParser.visibleSegments(from: self.text)
        return segments
            .map(\.text)
            .joined(separator: "\n\n")
```

If the intent is to **honour** `showsAssistantTrace` (show thinking when the flag is `true`), remove the redundant filter instead:

```swift
let segments = AssistantTextParser.segments(from: self.text, includeThinking: self.showsAssistantTrace)
return segments
    .map(\.text)
    .joined(separator: "\n\n")
```

How can I resolve this? If you propose a fix, please make it concise.

Preserve thinking segments when trace mode is enabled

When showsAssistantTrace is true, this new filtering drops every .thinking segment from the streaming bubble, even though the caller still decides to render the bubble based on AssistantTextParser.hasVisibleContent(..., includeThinking: true) in ChatView. In trace mode, a response that is currently only inside <think> blocks will now render an empty bubble (and never show streaming trace text), which is a regression from the previous ChatAssistantTextBody(includesThinking:) behavior.

Useful? React with 👍 / 👎.

visibleText always filters out .thinking segments. That changes behavior vs the previous ChatAssistantTextBody(... includesThinking: showsAssistantTrace) path: when showsAssistantTrace is true, thinking content will never appear during streaming, and if the stream is thinking-only the bubble can render as an empty Text("") even though ChatView will still show the streaming bubble (because hasVisibleContent(... includeThinking: true) is true). Adjust the logic so thinking segments are included when showsAssistantTrace is true (and use response-only segments when it’s false).

The doc comment for visibleText says it "Strip[s] markdown symbols during streaming", but this property only removes thinking segments (and the PR description notes markdown symbols remain visible during streaming). Please update the comment to reflect the actual behavior to avoid misleading future changes.

Align streaming visibility with trace-filtered content

This unconditionally removes thinking segments during streaming, but OpenClawChatView still decides whether to render the streaming bubble using AssistantTextParser.hasVisibleContent(..., includeThinking: self.showsAssistantTrace) in ChatView.swift (line 218). In trace mode, a thinking-only stream (e.g. partial <think>...</think> before final text arrives) now passes the visibility check but renders Text(""), producing an empty assistant bubble; this is a regression introduced by this change unless the visibility predicate is updated to match the filtered content.

Useful? React with 👍 / 👎.

Gate streaming bubble on non-thinking content

When trace mode is enabled, this new visibleText path always strips thinking segments, but OpenClawChatView still decides to render the streaming bubble using hasVisibleContent(..., includeThinking: self.showsAssistantTrace). Fresh evidence in this commit is that includeThinking is now hard-coded to false here, so a thinking-only in-flight response will pass the ChatView visibility check and render an empty assistant bubble until non-thinking text arrives.

Useful? React with 👍 / 👎.