fix(thread): surface agent messages + plans, per-group spinner, trim noise

[adamleithp]

What

The conversation thread folded a turn's entire activity into one collapsible chip. That buried the agent's direct messages and plans, and the chip's running state was tied to the whole turn so finished work kept spinning.

• Surface direct messages — agent_message_chunk items never fold; they render as their own chat row wherever they occur in a turn (not just trailing).
• Surface plans — the switch_mode (ExitPlanMode) tool call never folds; renders via PlanApprovalView standalone.
• Per-group spinner — chip spins on the group's own in-flight tool (summary.active), not turn-level turnComplete. A turn split across chips no longer keeps finished chips spinning. While running, the chip reads what happened · what's happening with a spinner.
• Trim noise — hide an empty, done-streaming "Thinking" row.
• Styling cleanup — tighter markdown margins, selected-fill on open tool rows, drop dead variants/classes.

Verified

Driven live against the running app over CDP:

• Direct messages interleave between collapsed chips (Worked → "Checking." → 1 tool call → answer).
• Running chip: ⠏ Ran 1 command · Sleep 15 then echo ok (spinner + both labels).
• Per-group spinner fix confirmed after the regression report.

lint + typecheck clean.

🤖 Generated with Claude Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 96f888b.}

[github-actions]

Pure UI rendering fix in @posthog/ui — no business logic, data models, API contracts, or security surface touched. The core change (flushing agent messages and plans instead of peeling from buffer tail) is a sound simplification, well-documented, and display-only.

New commits pushed (delta classified non_linear_history) — stamphog approval dismissed; re-review running automatically.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/sessions/components/new-thread/ToolCallGroupChip.tsx:40
The string `"Worked"` is the sentinel return value of `buildDoneLabel` when there are no countable actions. Comparing against it here creates silent coupling — if the default label ever changes in `conversationThreadConfig.ts`, the chip will always show both labels (or never show them) with no compiler/lint signal. The intent is better expressed as a field on `GroupSummary` that `summarize` computes once, close to the data.

```suggestion
  const hasDone = summary.hasCountableWork;
```

_{Reviews (1): Last reviewed commit: "fix(thread): surface agent messages + pl..." | Re-trigger Greptile}

[stamphog]

The current-head Greptile bot flagged a valid unaddressed concern: the summary.doneLabel !== "Worked" string comparison in ToolCallGroupChip.tsx creates silent coupling to the sentinel value in buildDoneLabel. If that sentinel ever changes, the chip's label logic silently misbehaves with no compiler or lint signal. Per review policy, a bot comment with a valid concern that remains unaddressed on the current head warrants escalation.

[stamphog]

An unresolved current-head inline comment flags a valid concern: summary.doneLabel !== "Worked" couples chip logic to a sentinel string in buildDoneLabel. If that sentinel changes, the label display silently misbehaves with no compiler or lint signal. The fix is straightforward — add a hasCountableActions boolean to GroupSummary — but it was not made in this diff.

[github-actions]

Pure UI rendering fix in @posthog/ui — the bot's concern about sentinel string coupling was directly addressed by adding hasCountableWork as a typed boolean on GroupSummary, and the inline comment is resolved. No business logic, data models, API contracts, or security surfaces touched.