feat(web): redesign usage insights - #7147

💭 I want to check the current state of the PR at head commit 3fa0aed to see whether the previously flagged issues have been addressed, so I'll look at the key files as they stand now. I'm checking whether the current head commit still has the dark hover/pressed contrast issue flagged in the prior review, since toggle.tsx now includes separate dark-mode hover and pressed opacity overrides that may have already addressed it. The latest commit seems to address the dark state fix, though the referenced prior commit isn't in this history, likely due to a rebase. I should check the diff of that last commit and review the current UsagePage to confirm the fix holds up. I'm checking how tailwind-merge resolves conflicting hover and pressed background classes between the base variant string and the new override, confirming the later class wins for same modifier/utility combos, then moving on to check the dark mode hover background conflict too. Now I'm working through the actual alpha math in dark mode: the track uses bg-input/40 which is white at roughly 3.2% opacity, but the hover state at dark:hover:bg-input/32 comes out to about 2.56% white — slightly less than the track itself, meaning hovering an unselected segment could make it marginally darker rather than lighter, which seems like an odd inverted effect worth flagging. Actually, compositing the layers properly, the hovered item ends up around 5.7% effective white over the page while pressed reaches roughly 8.7%, giving a noticeable ~3% delta between hover and pressed states — that's distinguishable enough, so this particular contrast concern resolves itself and I shouldn't re-flag it. Now I want to move on and check whether other previously noted issues remain unaddressed, and look at the current state of UsagePage.tsx and other newly added files to see if there are fresh problems worth reporting. I notice WorkspacePageHeader is imported but not part of this diff, so it must already exist on main. WorkspacePageContainer is new though, and I see it defaults to gap-6 with UsagePage using the "wide" width variant instead of the old max-w-6xl. Let me check WorkspacePageHeader's implementation. I should check UsageProviderChart and confirm surface-glass exists along with the tooltip changes. I'm also verifying WorkspacePageContainer's className merging with cn—since twMerge resolves conflicting gap classes by keeping the later one, a consumer-passed gap-12 would correctly override the base gap-6, so that's fine. The tooltip now uses the shared surface-glass utility, addressing that earlier finding. I'm checking whether the color-only encoding issue is resolved since provider rows now include color dots restoring the color-to-provider mapping, confirming the toggle group's data-size attribute has test coverage, and starting to look at whether the skeleton geometry issue from before still needs fixing. Going through the skeleton dimensions carefully, the headline, caption, provider row, and chart column heights all line up reasonably well with their loaded counterparts, with only minor discrepancies like the x-axis label height and a missing min-w-0 class that seem trivial. The axis gutter spacing also checks out correctly against the real chart's width plus gap. Now I want to verify the Metric element's height matches the loaded text-base line height, and I'm noticing a small RTL inconsistency where ml-16 is used instead of a logical property while the chart itself uses pl-16 elsewhere—not a big deal though. I should also confirm that the Select component actually supports the "compact" size and "ghost" variant being used for the mobile triggers, so I'm going to check select.tsx for those options. I'm checking whether the ghost variant's width classes make that redundant className a real issue or just a no-op, and now looking at how matchTriggerWidth's default behavior affects the popup's min-width via the anchor-width variable. Next I'm verifying consistency across other consumers of ghost/compact select triggers in headers, confirming the earlier alignItemWithTrigger fix holds up. I'm also checking whether WorkspacePageContainer's padding matches the prior settings container (it does, since it's a faithful extraction), noting the usage page's intentional width/padding change from max-w-6xl to the new "wide" preset, and looking at how drag-region interacts with interactive elements in WorkspaceBreadcrumb. Now I want to confirm the .drag-region CSS rules actually exclude button elements so that ToggleGroup's nested buttons stay clickable inside Electron's draggable header area. Buttons are fine since toggles and select triggers render as buttons, which are no-drag by default. Checking the mobile/desktop duplication with hidden toggle groups and selects — both render in the DOM but the hidden one uses display:none, so it's removed from the accessibility tree and there's no duplicate naming issue. Now I'm looking at whether having an h1 inside a breadcrumb li inside a nav landmark is semantically odd — the page title nested in a navigation element seems unusual. I want to check if other workspace pages follow this same pattern or if this was already flagged in a prior review. There's a discrepancy between what git_grep shows at that revision versus what I saw in the file view—different import statements and line numbers. I must have passed the revision differently between the two calls, so I need to double check which revision I'm actually looking at. The diff in the prompt matches what the view tool showed: UsagePage imports WorkspacePageHeader from its own file, and WorkspacePageContainer.tsx is a separate new file. So the grep result that showed a combined import is likely from a different commit than the one I intended to check. I see now that the earlier grep without a specific rev hit a different default branch, so I should use explicit revs going forward. WorkspacePageHeader already exists, and the PR is extracting a shared WorkspacePageContainer similar to how Settings has its own SettingsPageContainer with custom widths. I'm checking whether other pages duplicate this container pattern and could benefit from reusing it too. Now I'm focusing on remaining genuine issues on the current head: whether WorkspacePageContainer's padding and gap defaults conflict with usage elsewhere, whether the chart tooltip's surface-glass class duplicates border/background styling already defined in index.css, and whether the tooltip positioning logic has a timing issue on first hover since positionTooltip runs before the ref is set and only gets corrected on the next layout effect triggered by hoverIndex changes. I'm satisfied the positioning logic handles size changes via ResizeObserver and that tooltip placement stays scoped to its own module, so this isn't a real inconsistency. Now I want to check how surface-glass is actually defined in index.css to confirm there's no redundant styling at the tooltip call site. Good, surface-glass is used properly, and the hover-only tooltip issue is pre-existing so not something to flag. I consider scanning for other segmented ToggleGroup users like DiffPanel.tsx and PullRequestCodeTab, but that's unrelated cleanup, not something to pursue here. I want to check how data-size and data-variant propagate through the Toggle component within the group. The segmented variant's default sizing logic looks correct, and tests cover the explicit size override case. I also check whether the pointer-coarse hit-target overlay on compact segmented toggles causes overflow, but that's pre-existing behavior across compact sizes, not a new issue. I verify that formatPercent and cn imports are still used in UsagePage and settingsLayout, confirming no dead code was introduced. Now I want to check what happened to SETTINGS_PAGE_WIDTH_CLASS since it was removed, so I'm going to look at the settingsLayout container to see how that's handled now. I'm checking that className merge order lets consumers override gap and max-width classes correctly via twMerge precedence, confirming the later className wins over the base defaults. Now I want to verify there's no remaining layout inconsistency in how headers are structured across consumers — checking whether UsagePage's extra wrapper div and other settings pages structure their children similarly to WorkspacePageHeader's built-in gap and padding. I notice the PR page uses a size-4 refresh icon while the usage page uses size-3.5 — a small inconsistency worth checking, since the earlier offset issue seems resolved now. I want to check whether the Button component's "icon-sm" variant sets a default SVG size that would explain this mismatch. I also notice the usage page's content container matches the shape of the new shared WorkspacePageContainer, though pull-requests hasn't been migrated to it — that's unrelated cleanup, not something to flag. The ScrollArea usage on the usage page versus the scroll-fade pattern elsewhere is a pre-existing, unchanged choice. Now I want to verify the last three commits for correctness — distinguishing segmented dark states, aligning usage filter menus, and restoring usage table rows — starting with the filter menu alignment commit. With that resolved, I'm scanning for other spots that might need attention—checking the usage breakdown toggle group's header layout and the accessibility of the period toggle group. Actually, I want to verify the single-select semantics on that metric toggle group, since it uses a multi-select array API under the hood. Each call site guards against the empty-array deselect case by checking the value before updating state, so clicking an already-active toggle just leaves things unchanged rather than clearing the selection—I want to cross-check this against how DiffPanel handles the same pattern. Everything else checks out, including the toggle group sizing overrides. Let me focus back on the dark-state fix since it's the newest change and most likely to have introduced a regression. I'm tracing through how cva orders the base, size, and variant classes, then how twMerge resolves conflicting hover and pressed-state background utilities between the base and segmented variant, including the dark-mode specific overrides that apply alongside the light-mode ones rather than replacing them. Now I'm considering how the dark custom variant is likely defined using :where(.dark, .dark *), which carries zero specificity, meaning the cascade order in the generated stylesheet—not specificity—determines which hover background wins between the dark and non-dark utilities, and I'm trying to recall how Tailwind v4 orders combined variants like dark:hover: relative to single variants like hover:. I notice this exact pattern—pairing dark:hover:bg-input/64 with base hover:bg-accent, and dark:data-pressed:bg-input with base data-pressed:bg-input/64—already exists elsewhere in this codebase and presumably works correctly, so the new segmented dark classes are just following an established convention and shouldn't be flagged as an issue. I'm now wondering whether hovering a pressed segment in dark mode could cause the hover background to override the pressed background unexpectedly, since both conditions could apply simultaneously. I need to figure out which variant wins in Tailwind's cascade order—whether data-pressed or hover takes precedence. Looking at the existing outline variant pattern, the author wrote dark:data-pressed:bg-input before dark:hover:bg-input/64, which might hint at the intended precedence order. In light mode that's a slight dimming of the selected item on hover, which seems like a plausible intentional design choice rather than a bug, especially since the dark mode case was already flagged and fixed. I don't think this needs further nitpicking. Checking scope, usageProviders.ts only has a comment change, and usageMerge.ts lives in packages/shared which is outside the apps/web/src review scope. Now I want to do a final pass on remaining review criteria, like whether responsive geometry is preserved. UsagePage now uses the shared WorkspacePageHeader with an electron flag instead of its old custom fixed-height header, and it correctly uses the workspace topbar height variable with window-controls-overlay handling, matching other pages. The drag-region setup also looks correct: the header content sits in a drag region while interactive elements like the ToggleGroup buttons and Select trigger are properly excluded as no-drag since they're buttons. I do notice the WorkspacePageContainer padding changed from py-6 to pt-6 pb-12, which is worth double-checking against the original spacing. Looking more closely, I'm checking whether the skeleton's summary column matches the loaded state's layout classes, and I notice the skeleton is missing a min-w-0 class that the loaded version has -- but since the skeleton content is fixed-width and smaller than its grid column, this isn't an actual regression. I'm also checking the provider row's baseline alignment versus the skeleton's centered alignment, and since both rows are the same height, the visual difference is negligible. The color dot next to the ProviderMark looks like it might duplicate an existing legend swatch pattern, so I'm checking whether the repo already has a shared dot or swatch component before flagging it as worth raising. Now I'm tracing how icon color gets applied through the Button component, specifically whether the ghost variant with icon-sm size still routes SVG color through the muted icon token the way the default variant does, since the refresh button migrated from an outline icon button to a ghost one and I want to confirm its tone stays consistent. The icon color inheritance looks consistent between the usage refresh icon and the PR page refresh icon, both resolving to muted-foreground appropriately. I've verified the segmented size default derivation works correctly with Toggle's context-based size resolution, so I don't see any remaining concrete issues to flag. Checking WorkspacePageContainer, it's properly scoped as a plain div without data-slot, consistent with how other root-level components are structured alongside WorkspacePageHeader. The gap defaults and className merging patterns across SettingsPageContainer and WorkspacePageContainer look fine, and the bg-input/40 token usage checks out since --input exists in the theme. I'm confident there are no remaining findings here — everything checks out clean. Let me do one more pass on the UsagePage mobile Selects before finalizing, specifically the ghost variant SelectTrigger with compact size — checking whether the width override classes at the call site are redundant but harmless, and whether other ghost SelectTrigger usages follow the same pattern for consistency. Nothing else stands out as a violation, and since the prior findings were all addressed in the latest commit, I'll report success with the summary set to exactly "All clear" as instructed.