group report signals by type/similarity?

[adboio]

problem

in some reports, there are many attached signals, and they are often very similar (e.g. related llm traces, errors, etc)

example:

suggestion

to simplify the UI and make these reports easier to parse, could we just show counts per type, with the option to dive deeper?

what do you think about something like this?

[AlexlaGuardia]

took a crack at this, following your mock: #76362. findings group by their source line with counts, collapsed by default. only kicks in at 5+ findings with a repeated type, so small reports keep the flat list.

[dmarticus]

Status update: most of this shipped in #86780 (desktop report detail).

• Evidence now groups with counts per source line (product + type, e.g. "Error tracking · New issue"), kicking in past 4 signals, with two representative cards per group and a "Show all N" expander. The wall-of-similar-cards case in the screenshot can't render anymore.
• feat(desktop): group report findings by type in the inbox detail #76362 took the same approach earlier against the old SignalsList; closed as superseded.

Still open, and what I'd re-scope this issue to: similarity grouping within a type. Forty signals that are the same error fingerprint or related LLM traces still list individually inside their section. Collapsing those ("same issue × 12") needs clustering on the signal's source identity — ideally backend-side at report generation, so every surface (including prompts that inline evidence) benefits, not just the detail view.

[AlexlaGuardia]

Makes sense, #86780 is a better home for this than my patch was. Keying past 4 with two representative cards and a "Show all N" expander is tighter than what I had.

I keyed the group off the rendered source line on purpose. Not the natural key, a stable id would've been cleaner, but it makes one class of bug impossible: the header can't disagree with the cards under it, because both read the same string. When #76579 renamed the inbox source grouping to 'External sources', nothing in my branch had to move.

Clustering at report generation gives that up. The cluster key gets computed in one place, the source line renders in another, so they're two derivations of the same idea with nothing checking they still agree. Fine while the taxonomy holds still, goes quiet the first time someone renames a source or splits a skill: counts stay right, label above them stops matching what's in the bucket. Might be worth having the generation step emit the label it clustered on, so every surface renders what was actually grouped instead of recomputing it.

Not picking this up, just didn't want the rendered-key thing to get rediscovered the hard way.