feat(web): redesign usage insights#7147

usage/UsageProviderChart.tsx:411

This hand-rolls a glass surface instead of using the shared glass composition. Every other translucent floating surface in apps/web goes through the surface-glass / dropdown-glass utilities (index.css), which are driven by --glass-opacity, --glass-blur and --glass-saturation and are re-tuned under @variant dark. bg-background/65 backdrop-blur-xl backdrop-saturate-150 pins those values at the call site, so the tooltip is more transparent than the token contract (80%) over the coloured chart fills and does not pick up the dark-theme glass adjustments. Consider keeping only the border/radius/shadow locally and letting the utility own the glass:

No longer relevant as of acf68768ff7a71042c0b70d826ce9edc8d8e04e4

usage/UsagePage.tsx:147

h-auto py-2 overrides the core geometry WorkspacePageHeader owns. That height is not just visual: --workspace-topbar-height resolves to env(titlebar-area-height) under .wco, and the fixed sidebar-toggle / native-control strips are sized and positioned from the same variable (AppSidebarLayout.tsx, ChatView.tsx). Because the header content is flex-wrap with basis-full below sm, the header (and the Electron drag region) grows past the titlebar area on narrow widths, and the vertically centred breadcrumb no longer lines up with those overlay controls — a divergence from every other workspace surface (settings, project settings, pull requests), and the reason the onboarding header is regression-tested against py- in routes/-chatIndexTitlebar.test.ts.

Suggest dropping the override and keeping the shared topbar height, condensing the controls when space is tight instead of growing the bar (e.g. SegmentedTab density="compact", or a compact menu like the Pull Requests header uses).

No longer relevant as of acf68768ff7a71042c0b70d826ce9edc8d8e04e4

Zero-activity providers enter merge

Low Severity

The new session loop writes every owned source into providerAccumulator, including scanned directories with distinctSessions of 0 and no buckets. merged.providers can therefore include all-zero rows. Callers that hide the provider list when it is empty, such as mobile, now show unused providers as $0 / 0 sessions.

^{Reviewed by Cursor Bugbot for commit e093685b241e8da2a56784b57fe113095f559688. Configure here.}

usage/UsagePage.tsx:63

UsageHeaderMenu re-creates CompactFilterMenu (apps/web/src/routes/_chat.pull-requests.tsx:1619) — same component shape, same MenuTrigger + MenuRadioGroup wiring, and a byte-identical trigger class string (git grep "inline-flex h-7 shrink-0 items-center gap-1 rounded-md px-1.5" now matches exactly these two sites).

That trigger geometry and muted-ghost treatment is durable, shared header-bar styling, so it belongs in one named owner rather than a copied call-site string: the height, radius, padding, hover colors and chevron tone can only drift apart from here, and neither copy picks up Button's cursor/focus/hit-target contract. Consider extracting the compact menu (or at least the trigger) into a shared component — e.g. MenuTrigger render={<Button size="xs" variant="ghost-muted" />} inside one HeaderFilterMenu — and leaving only popup align/min-w-* and the option list at each call site.

No longer relevant as of 5e96339b38370155e7f0227d7d5a8fed3f0aaad5

🟡 Medium components/HeaderFilterMenu.tsx:41

When value is absent from options, the trigger displays options[0] but MenuRadioGroup receives the unmatched value, so no radio item is selected and the filter UI shows conflicting state. Pass the normalized current.value to MenuRadioGroup so the displayed label and selection stay aligned.

✅ Resolved in 4e4d9b33a0846e071081993ad5fc0b0654b97853

usage/UsagePage.tsx:221

The chart still encodes each provider purely by color (PROVIDER_PRESENTATION[provider].color drives the fills and strokes), but this PR deletes both UsageChartLegend and the colored share bars that used to live in these summary rows, so color is no longer rendered anywhere outside the chart itself. The only remaining color-to-provider mapping is the hover tooltip, which is mouse-only (UsageProviderChart binds onMouseMove/onMouseLeave and nothing pointer/touch/keyboard), so on touch and keyboard the two series become unidentifiable.

Smallest fix is to keep a static swatch next to the provider label here (or restore a legend next to the chart heading) so the mapping survives without hover:

No longer relevant as of 4e4d9b33a0846e071081993ad5fc0b0654b97853

density="compact" (and the segmented-compact size it selects in toggle.tsx) has no call site — all three usages here use the default density. Adding a size to the shared toggleVariants contract that nothing renders means its geometry is never validated against a real surface. Suggest dropping density and the segmented-compact size until a second surface needs the smaller pill, and adding them back with that consumer.

^{Posted via Macroscope — UI Consistency}

Fixed by removing the unused compact density and segmented-tabs wrapper.

HeaderFilterMenu is the same control as CompactFilterMenu (apps/web/src/routes/_chat.pull-requests.tsx:1619): same Menu + MenuTrigger + MenuRadioGroup shape, same chevron glyph, and the optional icon / disabledReason props map one-to-one onto that component's option.Icon / option.unavailable while having no consumer on this page.

Leaving both means the same header filter control now exists twice with divergent trigger behavior: this one inherits the Button compact / ghost-muted contract (focus-visible ring, coarse-pointer hit target, muted icon color), while the pull-requests copy keeps a hand-rolled trigger class string with no focus ring. Consider migrating those three call sites to this component (Icon -> icon, unavailable -> disabledReason) and deleting the local copy, so the two prop generalizations have the consumer they were shaped for. If that migration is out of scope for this PR, dropping icon and disabledReason until something uses them keeps the new contract to what it actually serves.

^{Posted via Macroscope — UI Consistency}

Fixed by removing the duplicate HeaderFilterMenu and using the shared control.

🟡 Medium components/HeaderFilterMenu.tsx:21

Passing options={[]} makes HeaderFilterMenu throw while rendering because current becomes undefined and current.label is read. The public ReadonlyArray prop type permits this value even though the component requires at least one option; require a non-empty tuple (or handle the empty state).

✅ Resolved in e8d00a2e96aafa9eaf8d8922a94c62e2d2ccede4

SegmentedTabList reconstructs ToggleGroup (apps/web/src/components/ui/toggle-group.tsx), the primitive the other single-select segmented controls already compose (DiffPanel.tsx:752, PullRequestCodeTab.tsx:1098). A raw role="group" div with per-item pressed/onClick drops what the Base UI group owns: value/onValueChange single-selection semantics and the composite keyboard model (one tab stop, arrow keys to move between segments — here each segment is its own tab stop and arrows do nothing), plus the group's coarse-pointer hit-target normalisation (*:pointer-coarse:after:min-w-auto), so on touch each 24px-tall pill keeps a 44px ::after overlay that spills onto its neighbour and the content below.

Since the segmented size/variant you added live on the shared toggleVariants, ToggleGroupItem can already wear them; suggest keeping the track styling (rounded-lg bg-muted/45 p-0.5) as a ToggleGroup className and letting variant === "segmented" take the gap-0.5 branch rather than the joined-border branch, instead of shipping a second group primitive next to the existing one.

^{Posted via Macroscope — UI Consistency}

Fixed. Usage now composes the existing Base UI ToggleGroup instead of a second group implementation.

SegmentedTabList reconstructs ToggleGroup (apps/web/src/components/ui/toggle-group.tsx), the primitive the other single-select segmented controls already compose (DiffPanel.tsx:752, PullRequestCodeTab.tsx:1098). A raw role="group" div with per-item pressed/onClick drops what the Base UI group owns: value/onValueChange single-selection semantics and the composite keyboard model (one tab stop, arrow keys to move between segments — here each segment is its own tab stop and arrows do nothing), plus the group's coarse-pointer hit-target normalisation (*:pointer-coarse:after:min-w-auto), so on touch each 24px-tall pill keeps a 44px ::after overlay that spills onto its neighbour and the content below.

Since the segmented size/variant you added live on the shared toggleVariants, ToggleGroupItem can already wear them; suggest keeping the track styling (rounded-lg bg-muted/45 p-0.5) as a ToggleGroup className and letting variant === "segmented" take the gap-0.5 branch rather than the joined-border branch, instead of shipping a second group primitive next to the existing one.

^{Posted via Macroscope — UI Consistency}

Fixed with the same migration to the shared ToggleGroup primitive.

ui/toggle-group.tsx:33

The new segmented variant only owns the item styling here — the track (rounded-lg bg-muted/45 p-0.5) is repeated verbatim at all three call sites this PR adds (UsagePage.tsx:116, :133, :306). That splits one treatment across two owners: variant="segmented" alone renders a transparent, unpadded group, so the next surface that reaches for the variant gets pressed pills with no track unless it copies the same string, and re-tuning the track means editing every consumer.

Suggest folding the track into the segmented branch and keeping only contextual layout at the call sites:

(the existing orientation branches then nest one level deeper), and drop className="rounded-lg bg-muted/45 p-0.5" from the three ToggleGroup usages.

No longer relevant as of 9ac145fda6f2ac9c93d06e06357b4627b1c38515

ui/toggle-group.tsx:33

The new segmented variant only owns the item styling here — the track (rounded-lg bg-muted/45 p-0.5) is repeated verbatim at all three call sites this PR adds (UsagePage.tsx:116, :133, :306). That splits one treatment across two owners: variant="segmented" alone renders a transparent, unpadded group, so the next surface that reaches for the variant gets pressed pills with no track unless it copies the same string, and re-tuning the track means editing every consumer.

Suggest folding the track into the segmented branch and keeping only contextual layout at the call sites:

(the existing orientation branches then nest one level deeper), and drop className="rounded-lg bg-muted/45 p-0.5" from the three ToggleGroup usages.

No longer relevant as of 9ac145fda6f2ac9c93d06e06357b4627b1c38515

Electron header controls still drag

Medium Severity

Metric, period, and refresh controls were moved into WorkspacePageHeader with electron={isElectron}, which applies drag-region. Shared CSS only marks button/a/inputs as no-drag, so padding and gaps around the segmented groups still start a window drag. Elsewhere (DiffPanel) interactive header clusters wrap the whole control row in [-webkit-app-region:no-drag].

^{Reviewed by Cursor Bugbot for commit f399a1b81e49fc256f12d16b309d6958be95921a. Configure here.}

ui/toggle.tsx:33

The pressed pill and the group track resolve to the same token in the default dark theme: index.css sets --muted and --accent both to --alpha(var(--color-white) / 4%) under @variant dark (:root), so the track bg-muted/45 (added in toggle-group.tsx) computes to ~1.8% white while data-pressed:bg-accent computes to 4% white — roughly #0e0e0e vs #141414 over neutral-950, and data-pressed:shadow-xs/5 adds nothing on a dark surface. hover:bg-accent/45 computes to exactly the track color, so a hovered unselected segment ends up looking like the selected one (both get text-foreground). All three new controls (UsagePage.tsx metric, period, breakdown) then communicate selection by text color alone in dark mode.

Suggest lifting the pressed/hover states with the token the primitive already uses for pressed state (bg-input/64 in the base class and dark:data-pressed:bg-input in outline), which stays above muted in both themes; data-pressed:bg-background plus a dark-only lift would work too if a white pill is wanted in light mode.

No longer relevant as of 8156179d91f5f5bd9bb77ef8766f729f6d7dfe00

usage/UsagePage.tsx:110

The / between crumbs is hand-rolled here, but the breadcrumb module already exports WorkspaceBreadcrumbSeparator, which every other workspace header uses (_chat.pull-requests.tsx:1861, SettingsBreadcrumb.tsx:26, ProjectSettingsPanel.tsx:215) and which renders the glyph as its own aria-hidden <li> with the text-icon-muted treatment. Nesting a <span aria-hidden> inside the crumb <li> re-declares that treatment at the call site and gives this header a different <ol> structure from the rest of the app.

The reason for the local copy looks like the responsive hide, since the shared separator takes no className. Suggest adding an optional className to WorkspaceBreadcrumbSeparator and rendering <WorkspaceBreadcrumbSeparator className="hidden md:flex" /> before the window crumb, so the separator stays in one owner.

No longer relevant as of ad49e563b67e030ef8846428afe158f1247b4583

usage/UsagePage.tsx:588

This placeholder no longer matches the geometry of the chart it stands in for: UsageProviderChart renders a w-14 axis gutter plus gap-2 beside the h-56 plot and an x-axis label row under it (UsageProviderChart.tsx:327-457), and the loaded heading is a text-sm h2 (20px), so the skeleton is ~20px shorter and its block starts 64px further left than the real chart. The section — and everything below it once the columns stack under lg — shifts when the last device answers, which is what the mirrored skeleton geometry existed to prevent.

Suggest reserving the gutter and the label row:

No longer relevant as of ad49e563b67e030ef8846428afe158f1247b4583

components/WorkspacePageContainer.tsx:61

This adds a shared export whose only consumer is UsagePage, and it makes the same header action align differently per page: the Pull Requests header renders the identical ghost refresh button flush inside the header padding with a size-4 glyph (_chat.pull-requests.tsx:1905-1912), and the Settings header places its trailing action flush too (settings.tsx:78-80). The offset is also tied to one call site's geometry rather than a durable contract — -me-[7px] optically centers a 28px button around a 14px glyph, which is size="icon-sm" only at sm and up (size-8 sm:size-7), so below sm the button is 32px and the glyph lands 2px inside the edge this helper exists to touch.

Suggest either dropping the wrapper and rendering the button flush like the other workspace headers, or moving the optical inset into WorkspacePageHeader itself so every workspace header's trailing icon action inherits it instead of one page opting in.

No longer relevant as of 4421251ac3996468d6a3cf3a015c9ee06df69557

ui/toggle-group.tsx:34

The segmented treatment is still split across two knobs: the track lands on variant="segmented" here, but the pill geometry it is padded for lives in size="segmented" (toggle.tsx:21-22). Nothing couples them, so every call site has to pass both (UsagePage.tsx:118, :134, :322) and variant="segmented" on its own renders default 36px rounded-lg items inside a p-0.5 track.

Suggest letting the variant own its geometry by defaulting the size from it, so consumers pass one prop:

No longer relevant as of af1fc0e676da1acbee1833e22bbfc2bf30b751a6

usage/UsageProviderChart.tsx:251

The layered zero-baseline drawing still depends on three non-obvious invariants whose explanations this PR removes: the scale tops out at the largest single provider-period rather than the summed peak (line 224-228), PLOT_TOP reserves headroom so the constant-width stroke is not shaved off at a peak (line 231), and this sort plus the separate fill and stroke passes (lines 375-392) keep the heavier series from burying the lighter one. With the rationale gone, the sort and the two-pass paint read as arbitrary and are easy to "simplify" away later — the same class of regression the niceScale and buildDayColumns tests already guard with explicit comments.

Suggest keeping a one-line reason next to each, e.g. here:

No longer relevant as of 4b69cf3c6748436adfce3203477b6f409aa38897

usage/UsagePage.tsx:575

The loaded provider row now starts with an 8px color dot plus an 8px gap (UsagePage.tsx:239-245), but the skeleton row still begins at the brand mark, so every provider row jumps 16px to the right when the last device answers — the shift this skeleton exists to prevent (and the same mismatch that was just fixed for the chart gutter below).

Suggest mirroring the dot here; the skeleton already renders the real ProviderMark, so the real swatch keeps the two states identical:

No longer relevant as of 095cd9edb12a39a89dc174831cc8b84592d59df2

usage/UsagePage.tsx:585

These placeholders are shorter than the content they stand in for, so the summary column still reflows when the data lands — the shift this skeleton exists to prevent, and below lg (where the columns stack) it moves the Totals and Breakdown sections too.

Loaded geometry: the headline is text-4xl (40px line box) over a text-xs caption (16px) (UsagePage.tsx:216-225), and each provider row is a text-sm line (~20px) over a text-xs detail (16px) (UsagePage.tsx:238-267). Here they are 32/12 and 16/12 — roughly 30px short across the column.

Suggest sizing the blocks to the text they replace:

No longer relevant as of 91c8fa29e612b494a22717243483848f7a0f59ee

This makes variant silently own the item geometry, and all three new call sites depend on it (UsagePage.tsx:113, :128, :311 pass variant="segmented" and no size). Nothing pins the contract: reordering the ternary or adding a variant would render default 36px rounded-lg items inside the 2px p-0.5 track with no test failing. Since this is defaulting logic on a shared primitive, a focused test would be worth adding — button.test.tsx already covers geometry contracts this way:

^{Posted via Macroscope — UI Consistency}

Fixed on the latest head. toggle-group.test.tsx now pins the segmented group and item size contract, including data-size="segmented" and h-6.

usage/UsagePage.tsx:354

The per-row border-b border-border/50 is dropped here and replaced with hover:bg-muted/20, which is effectively invisible in both themes: light --muted is zinc-50 on a zinc-25 background and dark --muted is --alpha(var(--color-white) / 4%) (index.css:1036, :1098), so /20 resolves to well under 1% delta against the page. The breakdown tables can run 90 rows, so they end up with neither delineation nor hover feedback.

Every other data table in the app pairs that same tint with separators — <tbody className="divide-y divide-border/50"> (ResourceTelemetryDiagnostics.tsx:622, DiagnosticsSettings.tsx:468) — and the shared TableRow contract is border-b transition-colors hover:bg-muted/50 (ui/table.tsx:46). Suggest matching that contract here (and on the time-breakdown row at line 401):

No longer relevant as of 5147b582cf9c1bed036d8b567c986cf5e50389ec

usage/UsagePage.tsx:162

These two new popups (:162 metric, :178 period) are the only align="end" SelectPopups in apps/web that do not pass alignItemWithTrigger={false} — SettingsPanels.tsx:409, ProjectSettingsPanel.tsx:883, IntegrationsSettings.tsx:303, ThemeSearchSection.tsx:259, ConnectionsSettings.tsx:2864 and the rest all disable it. SelectPopup defaults it to true (select.tsx:116), so these open in Base UI's item-aligned mode: the popup is anchored so the selected item covers the trigger and the positioner reports side=none, which also switches items to the in-data-[side=none]:min-w-[calc(var(--anchor-width)+1.25rem)] width path (select.tsx:190) off a w-auto min-w-0 trigger. In a topbar pinned to the top edge there is no room above, so the menu lands over the header with the scroll arrows engaged instead of dropping below the trigger like every other header/compact select.

Suggest matching the convention on both popups:

No longer relevant as of 77e09a2e9de223184c85d85616887e86d326a6c5

usage/UsagePage.tsx:162

These two new popups (:162 metric, :178 period) are the only align="end" SelectPopups in apps/web that do not pass alignItemWithTrigger={false} — SettingsPanels.tsx:409, ProjectSettingsPanel.tsx:883, IntegrationsSettings.tsx:303, ThemeSearchSection.tsx:259, ConnectionsSettings.tsx:2864 and the rest all disable it. SelectPopup defaults it to true (select.tsx:116), so these open in Base UI's item-aligned mode: the popup is anchored so the selected item covers the trigger and the positioner reports side=none, which also switches items to the in-data-[side=none]:min-w-[calc(var(--anchor-width)+1.25rem)] width path (select.tsx:190) off a w-auto min-w-0 trigger. In a topbar pinned to the top edge there is no room above, so the menu lands over the header with the scroll arrows engaged instead of dropping below the trigger like every other header/compact select.

Suggest matching the convention on both popups:

No longer relevant as of 77e09a2e9de223184c85d85616887e86d326a6c5

ui/toggle.tsx:33

In the default dark theme this makes a hovered unselected segment read the same as the selected one. The track added in toggle-group.tsx:34 is bg-input/40, and dark --input is --alpha(var(--color-white)/8%) (index.css:1106), so the track is 3.2% white over --background #0a0a0a (#121212). hover:bg-background/55 composites 55% of #0a0a0a back over that (#0e0e0e) and data-pressed:bg-background is #0a0a0a — a ~1.4% delta — while hover:text-foreground already matches the pressed text and data-pressed:shadow-xs/10 is a black shadow on a near-black surface, so it adds no lift. Net effect: with the pointer in the group, selection appears to follow the cursor. Light mode is fine (white pill over a ~#eeeeef track).

Suggest keeping the light treatment and letting the pill lift rather than sink in dark, the way the other toggle variants already do (data-pressed:bg-input/64 on the base, dark:data-pressed:bg-input on outline); exact ratios are worth tuning against the real header:

No longer relevant as of 8156179d91f5f5bd9bb77ef8766f729f6d7dfe00