Settings > Diagnostics: the resource monitor has drifted from the rest of Settings

[xxashxx-svg]

Settings > Diagnostics has drifted away from the rest of Settings, and I'd like to check the direction before opening a PR.

I have the work done and verified locally. Per CONTRIBUTING this needs agreement on direction and scope first, so this is that ask, not a PR announcement.

What looks off today

Every label in these four sections is uppercase with wide tracking, which nothing else in Settings does. The six stat tiles sit in a divide-x divide-y grid that leaves stray rules, and none of them show a trend. The three group cards repeat the same four metrics side by side, so you can't compare CPU across groups without reading three separate 2x2 grids. The history chart draws three 1px-wide bars per bucket, which is unreadable at any realistic bucket count. Status pills are hand-rolled rather than Badge. Muted text uses nine different opacity steps.

There are also a few things I'd call defects rather than taste:

• The heaviest-processes table is min-w-[1020px] and the live process tree is min-w-[1320px], both inside a pane that's roughly 850px at a 1240px window. Both use hideScrollbars, so the Write and PID columns are unreachable and nothing indicates they exist.
• In the Host & collection panel, first:border-t-0 never applies, because PanelHeading is the first child. A stray rule shows under one heading and not the other.
• bg-violet-500 is a raw palette colour where every neighbouring dot uses a theme token.

What I'm proposing

Rank the three headline stats and give each a sparkline, move reads, writes and the speed limit into a compact strip, and replace the three group cards with one table you can read across. Redraw the timeline as a CPU area chart with labelled ticks and a zero baseline, plus a stacked I/O strip beneath it sharing the x axis. Narrow the process tables so their columns fit, pair each rate with its running total, and move the category under the process name.

Scope is three files, all under apps/web/src/components/settings. No contract, server or mobile changes.

Before and after

Dark theme, 1240px. Captured against a near idle dev server with three T3 processes and no desktop host, so the numbers are small.

Resource monitor

Before	After

Resource timeline

Before	After

Live process tree

Before	After

Host and collection

Before	After

Two decisions I'd want your opinion on

Both chart scales size to the 90th percentile of the window rather than the max, so a single spike can't flatten everything else into the floor. Clamped buckets get a diamond marker and the caption names the true peak. The alternative is scaling to the real max and accepting that the average line sits in the bottom fifth whenever something spikes. I went back and forth on this one and could be talked out of it.

resourceSampledBuckets drops leading buckets with no samples instead of drawing them as a measured 0%. That's more honest, but it means that shortly after a restart the 5m, 15m, 30m and 1h buttons all render the same short range, which could read as the control doing nothing.

Verification

vp run check:changed passes: format, lint, both knip passes, typecheck, tests, react compiler. Four new cases in the existing ResourceTelemetryDiagnostics.logic.test.ts cover the scale rounding, the percentile, dropping unsampled buckets, and the path geometry including the single-sample and flat-series edges. Checked by hand in a dev build on Windows against the native collector, in both themes, at 1240px.

Happy to split the clipped-column and first: selector fixes into their own PR and drop the rest if the redesign isn't a direction you want.

Written with Claude Opus 5 in T3 Code.