Improve Frontend Message Rendering and Classification

Summary

Please start a worktree project for a few issues related to the frontend rendering of messages

https://github.com/market-dot-dev/traces/issues/65
https://github.com/market-dot-dev/traces/issues/70
https://github.com/market-dot-dev/traces/issues/73

Please review these issues, and see if there's a generic XSLT like layer we need to introduce into the frontend to make handling these more consistent. Please review component structure for message types as part of this.

So, I want a generalized plan that:

Fixes these specific issues
Gives us a framework for frontend transforms
Is FAST!

Based on my analysis of the issues and the codebase, here is a comprehensive plan to introduce a Message Transformation Layer. This "XSLT-like" layer will strictly separate the raw message content from its presentation, allowing us to consistently handle specific tags and format requirements across the application.

1. Analysis & Strategy

The core issue is that UserMessage and AssistantMessage currently render textContent directly into a Markdown component. We need a processing pipeline that intercepts the content before rendering to:

Strip internal protocol tags (Issues #70, #73).
Transform structured tags into rich UI components (Issue #65).

Strategy: Implement a useMessageTransforms hook that runs a pipeline of "Transformers". Each transformer takes a string or existing render parts and returns a modified list of parts (strings or React Nodes).

2. Architecture: The Transformation Pipeline

We will introduce a new module at frontend/lib/message-transforms.

Directory Structure

text

Core Logic (`useMessageTransforms`)

The hook will implement a "split-and-replace" algorithm using useMemo for performance.

Input: message.textContent (String).
Initial State: [message.textContent].
Process: Iterate through registered transformers.
- Each transformer scans string parts using Regex.
- Matches are replaced with React Components (e.g., <CommandBlock />) or removed (replaced with empty strings).
- Unmatched text remains as strings.
Output: (String | ReactNode)[].

Rendering:
Components will map over the output:

Strings -> Wrapped in <Markdown />.
ReactNodes -> Rendered directly.

3. Specific Fixes

Issue	Problem	Transformer Solution
#70	Codex leaks `<environment_context>`	`StripEnvironmentContext`: Regex match `/<environment_context>[\s\S]*?<\/environment_context>/` and replace with `""`. If the resulting message is empty, the UI handles it gracefully.
#73	Agent Teams leaks `<teammate-messages>`	`StripTeammateMessages`: Regex match `/<teammate-messages>[\s\S]*?<\/teammate-messages>/` and replace with `""`.
#65	Claude `<command-...>` tags	`RenderCommandTags`: Regex match `/<(command-[-\w]+)(?:\s+[^>])?>([\s\S]?)<\/\1>/`. Transform into a new `<CommandBadge>` or `<CodeSnippet>` component to distinguish it from user text.

4. Implementation Steps

Setup Worktree & Structure:
- Create worktree fix/message-rendering.
- Create frontend/lib/message-transforms structure.
Implement Core Logic:
- Define MessageTransformer type.
- Implement applyTransformers utility and useMessageTransforms hook.
Implement Transformers:
- Write regex-based transformers for #70 and #73 (Stripping).
- Write component-based transformer for #65 (Rendering).
- Create a simple UI component for the command tags (e.g., a styled badge or code block).
Integrate:
- Modify frontend/components/messages/UserMessage.tsx to use the hook.
- Modify frontend/components/messages/AssistantMessage.tsx (for consistency).
Verification:
- Verify that tags from issues #70 and #73 are gone.
- Verify that command tags from #65 are rendered distinctively.
- Ensure standard Markdown rendering still works and performance is not impacted.

This plan is FAST (regex-based, memoized), Generic (easy to add new tags later), and Consistent (applied centrally).

User Approval:
Shall I proceed with creating the worktree and implementing this plan?

- Verify that command tags from #65 are rendered distinctively. < These should be hidden in higlights view without any adapter specific code in that tab (right now we only select user messages/assistant responses as highlight views). Perhaps user messages that show these should be rendered as a special "inserted-user" (terrible name, pelase fix that). They're pseudo assistnat messages but for some reason stored as user messages.

In highlights they shouldn't appear but in full trace they should show kind of like the toolcalls (and should be collapsible)

For the skills we should show some kind of "Attachment" message that shows that the agent is attaching skill files

For the "Sub agent" messages provide a reocmmendation on the way they should be structured visually.

Yes, go ahead create worktree and start implementing

I have analyzed the codebase and created the worktree fix/message-rendering. Based on your requirements and the existing architecture, here is the detailed implementation plan.

1. Classification Logic

I will create a central utility to identify these special message types without polluting the core Message type.

File: frontend/lib/message-classification.ts

Enums: SpecialMessageCategory (COMMAND, TEAMMATE_CONTEXT, ENVIRONMENT_CONTEXT, SKILL_ATTACHMENT).
Patterns: Regex for:
- <command-*>...</command-*>
- <teammate-messages>...</teammate-messages>
- <environment_context>...</environment_context>
- <skill_attachment>...</skill_attachment> (Implied by "Attachment message")
Functions: identifyMessageCategory(message) and parseSpecialMessageContent(message).

2. New Components

I will create a new directory frontend/components/messages/special/ for these specialized views.

Component	Purpose	Visual Style
`CommandMessage`	Renders `<command-*>`.	Terminal Log: Dark header with command name, collapsible body with monospace content. Distinct from tool calls but similar structure.
`TeammateMessage`	Renders `<teammate-messages>`.	Threaded Context: A distinct block (perhaps with a left border/quote style) titled "Teammate Context". Collapsible.
`EnvironmentMessage`	Renders `<environment_context>` & Skills.	Attachment: A discreet "paperclip" style row. Title: "Environment Context" or "Attached Skill". Content is hidden by default (collapsed).

3. Integration Points

A. `MessageItem.tsx` (Rendering)

I will modify frontend/components/messages/MessageItem.tsx to switch on the detected category.

Current: Checks user_message -> renders UserMessage.
New: Checks identifyMessageCategory.
- If COMMAND -> render CommandMessage.
- If TEAMMATE_CONTEXT -> render TeammateMessage.
- If ENVIRONMENT_CONTEXT -> render EnvironmentMessage.
- Else -> render UserMessage.

B. `HighlightsPage` (Filtering)

I will modify frontend/app/s/[id]/(highlights)/page.tsx to exclude these messages.

Current: Filters for user_message or agent_text.
New: Will strictly filter out any message identified as SpecialMessageCategory (Command, Teammate, etc.).
Result: These messages will be completely hidden in the "Highlights" tab, as requested.

C. `FullTracePage`

No changes needed to filtering.
Because MessageItem is updated, these messages will appear in the "Full Trace" tab but with the new, collapsible, distinct UI instead of looking like raw user prompts.

4. Execution Steps

Create frontend/lib/message-classification.ts.
Create the special components in frontend/components/messages/special/.
Update frontend/components/messages/MessageItem.tsx to route to these new components.
Update frontend/app/s/[id]/(highlights)/page.tsx to filter them out.
Verify against the issue examples (#65, #70, #73).

Mode Check: I am currently in Plan Mode. Please confirm if I should proceed with these changes in Implementation Mode.

Go ahead

Implemented in the new worktree on branch fix/message-rendering at /Users/tarunsachdeva/code/traces-worktrees/fix-message-rendering.

I added a centralized transform/classification layer in frontend/lib/message-transforms.ts that detects and parses:
- command tags (<command-...>)
- environment/skills payloads (<environment_context>, <skill_content>, <available_skills>, # AGENTS.md instructions)
- sub-agent payloads (<teammate-messages>)
I introduced a synthetic message type agent_context in frontend/lib/types.ts, and wired it into frontend/lib/message-utils.ts so classification is global (not tab-specific).
Because highlights already only renders user_message + agent_text, command/env/teammate injected user messages are now hidden there automatically (no adapter-specific highlights logic).
In full trace, those same messages now render as collapsible, tool-style rows via frontend/components/messages/special/AgentContextMessage.tsx, routed from frontend/components/messages/MessageItem.tsx.
Skills now show as an “Attachment” message, with parsed sections shown inside the collapsible body.
I also updated accordion previews/labels for these transformed messages in frontend/components/messages/MessageAccordion.tsx, and added filter typing guards in frontend/components/filters/TraceFilterChips.tsx and frontend/components/filters/TraceFilterSidebar.tsx.

Sub-agent visual recommendation (and current direction):

Use a collapsed summary row (“Sub-agent exchange”, count of updates).
Expand into per-message cards with clear speaker labels (implemented baseline).
Next refinement: group by sub-agent run and show request/result pairings as mini threads for faster scanning.

Validation:

Ran bun run build in frontend (passes; existing dynamic route warning unchanged).
Ran bun run lint in frontend (only pre-existing warnings, no new errors).

If you want, I can now do a quick polish pass on copy/labels (e.g., “Attachment” vs “Context Attachment”, “Sub-agent exchange” wording) and then prepare a commit.

Did we reposition where the command tags go?

Yes — at the frontend rendering layer.

Command-tag messages are no longer treated as normal prompts; they’re retyped as agent_context in frontend/lib/message-utils.ts.
Highlights now naturally excludes them (since it only keeps user_message + agent_text) in frontend/app/s/[id]/(highlights)/page.tsx.
Full trace still keeps chronological order, but renders them as collapsible tool-style rows via frontend/components/messages/MessageItem.tsx + frontend/components/messages/special/AgentContextMessage.tsx.
Detection/parsing is centralized in frontend/lib/message-transforms.ts.

So: repositioned in presentation/category, not moved in stored message order/data.

yeah that's great, but are they completely hidden now I mean? did the presentation layer completely remove them or are they

Great question — not completely removed.

They are fully hidden in Highlights because they’re reclassified as agent_context in frontend/lib/message-utils.ts, and Highlights only renders user_message + agent_text in frontend/app/s/[id]/(highlights)/page.tsx.
They are still shown in Full Trace (by design), rendered as collapsible context rows in frontend/components/messages/special/AgentContextMessage.tsx, routed via frontend/components/messages/MessageItem.tsx.
They are not deleted from stored data; this is presentation-layer behavior only.

So: hidden in Highlights, visible (collapsed-style) in Full Trace.

can u just show them for one second, i wanna see if it actually caught things