rich message component

[harryalbert]

Description

Renders MessagesReceivedFromAgents in the Warp TUI as rich, collapsed-by-default participant rows. Each row shows the sender's conversation-status glyph, deterministic orchestration identity, and display name; expanding it reveals the message body with hanging indentation and falls back to the subject when the body is blank. Opaque EventsFromAgents ids no longer produce placeholder transcript rows, and exchanges containing only intentionally hidden orchestration output now render at zero height instead of leaving blank transcript blocks.

Why participant resolution lives in history/topology

An incoming ReceivedMessageDisplay contains a server-side sender_agent_id, but not the sender's display name, status, or local conversation id. The current transcript block supplies a local AIConversationId, so rendering needs two small semantic lookups:

1. Current conversation → immediate parent/orchestrator agent id.
2. Sender agent id → loaded sender conversation through the history model's reverse index.

This is not a second graph traversal. BlocklistAIHistoryModel is already the canonical owner of run-id indexing, loaded conversations, immediate-parent links, sibling ordering, names, and ConversationStatus. The shared helpers in app/src/ai/blocklist/orchestration_topology.rs expose that identity discovery to both GUI and TUI.

TuiOrchestrationModel intentionally remains an ephemeral session materializer. It owns only child-conversation → background-session and session → event-consumer mappings. Mirroring participant metadata there would create a second source of truth and would not cover restored, remote, or otherwise pre-existing conversations that did not pass through the current TUI coordinator.

After semantic resolution, each frontend owns presentation: the GUI chooses avatars/navigation behavior, while the TUI chooses terminal glyph/color identities. The TUI reads ConversationStatus directly for participant rows; tool calls retain a separate ToolCallDisplayState because constructing and pending are tool-call states, not conversation lifecycle states.

Testing

• I have manually tested my changes locally with ./script/run-tui
  https://www.loom.com/share/d4108705287743fba6797c4b93599122

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[harryalbert]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• add product and tech spec #13855
• Add TUI orchestration tab bar specs #13832
• add reusable TUI tab bar component #13831
• rich message component #13777 👈 (View in Graphite)
• Add local child agents to TUI #13776
• add TUI multi-session registry and focused-session root projection #13775
• add TUI orchestration permission and configuration card #13717
• add reusable TUI option selector over shared option snapshots #13716 : 1 other dependent PR (#13830 )
• add reusable TUI editor view #13817
• route TUI editor input by owning-view focus #13771
• add option snapshots and adapt GUI orchestration pickers onto them #13714
• extract orchestration edit state into a frontend-neutral module #13707
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[oz-for-oss]

@harryalbert

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR updates the TUI orchestration transcript to render received agent messages as rich collapsed participant rows, factors participant resolution into shared history/topology helpers, removes placeholder lifecycle-event transcript rows, and consolidates TUI tool-call state styling helpers. It includes TUI render tests, topology tests, and linked visual evidence for the user-facing behavior.

Concerns

• No blocking correctness, security, or spec-alignment concerns found in the reviewed diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[kevinyang372]

Should display_name be a method on OrchestrationParticipantKind?

It could be

pub enum OrchestrationParticipantKind {
    Orchestrator { name: String },
    Agent,
    Unknown,
}

impl OrchestrationParticipantKind {
    fn display_name() { ... }
}