Clarify and Simplify Filter and Label UsagePublic

I'll read the full message registry file to understand the current structure and update the type and all usages.

I can see shortLabel is only used within this file. I'll update the type definition and all the values to use actionLabel with appropriate past-tense descriptions.

Now I'll update all the message type entries with proper past-tense action labels.

Let me verify the changes and check for any linter errors.

Done. I've updated MessageTypeConfig to use actionLabel instead of shortLabel, with past-tense action descriptions:

Type change:

• shortLabel: string → actionLabel: string with comment explaining it's for hover cards/messages in past tense

Message kinds:

Tool types:

Let me read the full file to understand the context.

tool_call IS in VALID_FILTERS (line 25). What's not there are the specific tool types like "read", "edit", "grep", etc.

This is intentional — the filtering uses a two-level system:

1. filter param → message kinds (top-level): user_message, agent_text, agent_thinking, tool_call, plus special modes all/highlights
2. toolType param → specific tool types (sub-filters): read, edit, grep, etc.

You can see this in parseFiltersFromUrl (lines 43-58):

So a URL like ?filter=tool_call&toolType=read&toolType=edit would show only read and edit tool calls. The tool types are validated elsewhere (likely against MESSAGE_TYPES in the registry where category === "tool_type").

Good catch. The naming is confusing because toolTypes are also filters conceptually. Let me check the types and usages, then propose clearer naming.

The types file already has MessageKind (line 32) which is exactly what filters actually contains. I'd suggest renaming:

• filters → messageKinds (matches the existing type name)
• toolTypes stays as is (already specific)

This makes it clear that parseFiltersFromUrl returns two types of filter criteria: message kinds and tool types.

Let me update the code.

Now I'll update the call sites.

No, you're right. Looking at the types:

MessageKind explicitly excludes both "all" and "highlights" because they're view modes, not message kinds. But the current filter logic only excludes "all":

I should also exclude "highlights" and use the proper MessageKind type.

Now let me update the call sites and check for linter errors.

The type change exposed comparisons with "highlights" that are now impossible. Let me read those lines to understand the logic.

You're right, I went in the wrong direction. "Highlights" is a valid filter that needs to be parsed from the URL - it's just not a message kind. The issue is purely naming, not filtering behavior.

Let me revert and think more carefully. The real options are:

1. Keep filters / toolTypes but document better
2. Use names that don't claim they're "message kinds" - maybe viewFilters / toolFilters

Let me revert the changes.

Reverted. The linter is happy now.

I've improved the docstring to clarify what each return value contains:

The naming isn't perfect, but at least the comment now makes the distinction clear. If you want to rename the return values to something more descriptive (like viewFilters and toolFilters), that would require updating all call sites - let me know if you'd prefer that.

Good question. The current model conflates three distinct concepts into one MessageFilter type. Here's what reality looks like:

Three distinct filter concepts:

1. View Mode (mutually exclusive): "all" | "highlights" — determines the base view
2. Message Kinds (multi-select): "user_message" | "agent_text" | "agent_thinking" | "tool_call" — filters by content type
3. Tool Types (multi-select, sub-filter of tool_call): "read" | "edit" | "grep" | etc.

A more accurate model:

Then the parser would return:

This makes the semantics explicit:

• viewMode is a single choice, not an array
• messageKinds are separate from view modes
• Tool types remain their own concept

Want me to implement this? It would touch types.ts, filter-utils.ts, and the components that use them.

Looking at the usage, there are two parallel systems:

1. normalizeFilter → single value for "what mode am I in?" (filter)

   • Used for view mode checks: filter === "highlights", filter === "all"
   • Passed to components like TraceFilterToggle
   • Legacy single-select approach

2. parseFiltersFromUrl → arrays for multi-select (parsedFilters, parsedToolTypes)

   • Supports ?filter=user_message&filter=tool_call
   • Newer multi-select approach

They're redundant and confusing. The code is straddling two models.

If we implemented the cleaner model I proposed:

Then normalizeFilter would be absorbed into parseFiltersFromUrl as the viewMode return value, and we'd delete the separate function.

The current situation looks like incremental evolution where multi-select was added but the old single-value logic wasn't fully migrated. Do you want to clean this up as part of the filter refactoring?

I didn't add those - they were already in the file. But you're right, they shouldn't be there if they're not actual filters. Let me check what's actually in the file and clean it up.

Those were pre-existing, not added by me. They look like part types that got mixed into the filter type by mistake. Let me remove them.

Done. MessageFilter now only contains actual filters:

• View modes: "all" | "highlights"
• Message kinds: "user_message" | "agent_text" | "agent_thinking" | "tool_call"

The removed values (tool_result, code_edit, error) were part types, not filter types.

The issue is getMessageKind returns "tool_result" at runtime (line 35) but the type no longer includes it. I need to fix both the function and the filtering code.

Fixed. Here's the summary:

Problem: Removing "tool_result", "code_edit", "error" from MessageKind type caused type errors where code was comparing against those values.

Fixes:

1. message-utils.ts:

   • getMessageKind() now returns "tool_call" for tool results (they're part of the same flow)
   • Added isToolResultMessage() helper for filtering standalone result messages
   • Removed dead cases from messageKindLabel() switch

2. MessageAccordion.tsx / MessageList.tsx:

   • Changed getMessageKind(m) !== "tool_result" → !isToolResultMessage(m)
   • Removed || kind === "code_edit" checks (edit tools are just tool_call with specific names)

Two different use cases:

Example:

This is more evidence of two systems coexisting — createFilterModeUrl is the old single-select approach, buildFilterUrl is the newer multi-select. They could probably be unified.

Agreed. Here's a unified approach:

Usage:

This also aligns with the cleaner type model we discussed earlier. Want me to implement this and update the call sites?

Makes sense. Simpler is better. One function with an optional pathname:

• With pathname: returns /path?filter=x (replaces createFilterModeUrl)
• Without pathname: returns ?filter=x (current behavior)

Want me to implement this and update the call sites?