Improve Message Filtering and Avatar Display

Summary

Are we filtering for messages like

<local-command-caveat>Caveat: The messages below were generated by the user while running local commands. DO NOT respond to these messages or otherwise consider them in your response unless the user explicitly asks you to.</local-command-caveat>

User
<local-command-stdout></local-command-stdout>

in the frontend they show up in the claude adapter, see the PR about messages just merged https://github.com/market-dot-dev/traces/pull/131

Short answer: no, not currently.

In the merged message-rendering work, agent-context detection in frontend/lib/message-transforms.ts only recognizes patterns like <command-*>, <teammate-messages>, <environment_context>, <skill_content>, and <available_skills>.
Tags like <local-command-caveat> and <local-command-stdout> do not match those patterns, so frontend/lib/message-utils.ts falls back to user_message.
The Claude adapter also passes user text through as-is in cli/src/adapters/claude-code/v1.ts, so those blocks make it to the frontend unchanged.

If you want, I can patch this so <local-command-*> gets treated as agent_context (and hidden from Highlights like other context messages).

yea please do

just push to main its a small change

Done — local command wrappers are now treated as agent context, so those caveat/stdout payloads won’t be shown as normal user prompts in Highlights.

Updated command-context detection in frontend/lib/message-transforms.ts:31 and frontend/lib/message-transforms.ts:37 to recognize both <command-*> and <local-command-*> prefixes.
Updated command tag parsing in frontend/lib/message-transforms.ts:41 and frontend/lib/message-transforms.ts:130 so <local-command-caveat> / <local-command-stdout> are parsed by the same command-context path.
Committed and pushed directly to main as requested: ef3f457 (fix(frontend): classify local command caveats as context).

I also attempted to run frontend lint, but bun is not available in this environment (command not found: bun).

find bun silly

Found it 😄

bun is at /Users/tarunsachdeva/.bun/bin/bun (version 1.3.8)
bunx is at /Users/tarunsachdeva/.bun/bin/bunx
The earlier failure happened because this shell didn’t have ~/.bun/bin in PATH.

I also reran lint with the explicit binary:

"$HOME/.bun/bin/bun" run lint in frontend/
Result: 0 errors, 4 warnings (unrelated existing warnings)

I’ve also set PATH in this shell session now, so subsequent commands here can use bun directly.

[Image 1] also notice user avatars on the actual trace component not rendering, seems inconsistent, somethings up

Good catch — you were right. The trace header used real profile data, but message rows were still hardcoded to a generic "User" avatar path.

I fixed the avatar data flow so trace messages now use the trace owner identity consistently (userName + userAvatar) instead of fallback defaults.
I threaded identity through the message render pipeline: frontend/app/s/[id]/(highlights)/page.tsx and frontend/app/s/[id]/full/page.tsx → frontend/components/messages/MessageList.tsx → frontend/components/messages/MessageItem.tsx → frontend/components/messages/UserMessage.tsx.
I also fixed accordion previews and nested message rendering so user icons there match too in frontend/components/messages/MessageAccordion.tsx.
Root cause was exactly the inconsistency you spotted: header used trace.userAvatar, but message components and accordion icons were using Avatar userName="User".

Validation I ran:

"$HOME/.bun/bin/bun" run lint in frontend/ (passes with existing unrelated warnings only)
export PATH="$HOME/.bun/bin:$PATH" && bun run build in frontend/ (build completes)

I haven’t committed/pushed this avatar fix yet.

If you want, I can commit and push it to main now.

pls do