Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

@@ -121,3 +121,3 @@
 `SystemMetricsCollector` samples CPU (`/proc/stat` deltas), RAM and swap (`/proc/meminfo`), the swap-out (`pswpout` of `/proc/vmstat` over five minutes, PR#146), the load average (`/proc/loadavg`), the pressure-stall information (`/proc/pressure/cpu`, `/proc/pressure/memory` and `/proc/pressure/io`, PSI `some avg60`), disk, and repository size every 15s, but only after `ServerMetricsLifecycle` (server profile) calls `start()` — like the watcher, nothing is scheduled in CLI runs or tests. Min/max/avg aggregation state persists as JSON in the instance's state home (`${XDG_STATE_HOME:-~/.local/state}/werkator/system-metrics-state.json`, moved there from the artifact root once, PR#33), so restarts continue the series. Unavailable sources (e.g. no `/proc` outside Linux) yield null metrics served as HTTP 200 by `GET /api/system` — the `/system` page shows `n/a`, never an error.
 
-The same state file carries the sample history (`MetricsHistory`, PR#27), three tiers: every 15 s sample for four hours, one point per minute for a day and one per quarter hour for a month, the aggregated tiers with average *and maximum*, column-wise (one timestamp list, one value list per metric key) so the file stays a few hundred kilobytes; a minute is aggregated from the samples when the next one opens, a quarter from the minutes, so no accumulator is persisted, and the file is written once a minute (`PERSIST_EVERY_SAMPLES`) and on shutdown. `GET /api/system/history?range=1h|4h|24h|7d|30d` serves a cut of one tier (samples up to four hours, minutes up to a day, quarters beyond) with its peaks (`HistoryPeaks`: the highest value, when, and the `UtilizationLevel` it reached against the *current* total) — the evidence for a capacity decision. The verdict is computed on the server (`SystemHealth.assess`, `healthy`/`pressure`/`overloaded` with the rules that fired as reasons) and only rendered by the page, so a later executor change can act on the very same rules; CPU utilization alone never counts, waiting does (load above the core count, pressure, swap). `CapacitySizing.of` (PR#30, corrected in PR#42 and PR#58) sizes the machine from the quarter-hour tier. RAM is judged by *waiting*, never by a fill level (RFC 0004): a quarter hour counts as stalled when its average `memoryPressure` reached `SystemHealth.MEMORY_OVERLOAD_PERCENT` — shared, so a machine the health verdict calls healthy cannot be red in the sizing — and RAM is `tight` from 1 % and `upgrade` from 5 % of stalled quarter hours, the share CPU already uses; swap occupancy plays no part. The peak is named in the reason and never judged, with the single exception that it may still prove slack for a downsize — without the 40 % gate CPU and disk keep (PR#79), since the smaller bookable GiB that holds peak, headroom and reserve is the whole proof; it sizes a raise when one is due, rounded up and at least one step above what is booked, because a stall proves the peak was the ceiling. Disk is judged by the level it *holds* — the 95th percentile of the quarter-hour maxima of the last seven days (`DISK_LEVEL_DAYS`), the percentile the CPU watch band already uses, so a single quarter hour is a moment and not a level (PR#78; upgrade from 90 %, `tight` from 80 % where there is something to raise; the recommendation leaves a fifth free, a third for disks) — and by its growth, the median of the daily deltas of the last week, so a step counts on one day and a trend on most, extrapolated thirty days ahead from the level, only from seven days of history on. The window maximum is named in the reason and vetoes a downsize (under 40 %), never asks for a raise. Every size is rounded to what can be booked (`BookableSteps`, a parameter of `of(...)` that the controllers derive from `HostingEnvironments.bookableSteps` — for Hostsharing 10 GiB per quota, 250 GB per volume, 1 GiB RAM; elsewhere the whole unit), and a downsize is advised only when the next bookable size down would still leave the target headroom, otherwise `fits` with a reason saying why. The steps, unlike the hosting itself, reach every viewer: they name nothing, and one machine must not advise two different things depending on who asks. `ioPressure` (PR#69) is sampled and shown like the other two but read by neither the health verdict nor the sizing, in RFC 0004's order — the series has to exist before anyone can say what a number means, and on a shared hive the disks are the part shared hardest, so it will say more about the neighbours than about this instance until somebody has watched it. `oomKills` is sampled into the history from `/proc/vmstat` as the count per bucket but deliberately not read by the sizing — the counter is machine-wide, so on a shared hive it counts every webspace's kills. CPU is sized from the quarter-hour *averages*, never the maxima — waiting (load above the thread count in more than 5 % of the quarters, the 95th percentile of those loads being the recommendation) and, below that, the 95th percentile of sustained utilization for the watch band. A CPU is counted in hardware threads (`CapacitySizing.CPU_UNIT`), which is what `availableProcessors` reports and what a webspace is billed by. RAM is advised in bookable whole GiB: the visible total rounded up is the booked size, and the difference the reserve the host keeps. Nothing is advised from less than a day. Served as `capacity` on `GET /api/system` and shown as colour-coded chips in the verdict panel; where the instance can tell it runs on a Hostsharing Managed Webspace (`HostingEnvironments.detect`, served as `hosting`) the chips carry an order button that composes a German mail to the service desk from the changes the user ticks — the page sends nothing itself. The `/system` page is a verdict line with the sizing chips beneath it, one gauge card per resource (percentage, bar, level pill, inline-SVG sparklin
+The same state file carries the sample history (`MetricsHistory`, PR#27), three tiers: every 15 s sample for four hours, one point per minute for a day and one per quarter hour for a month, the aggregated tiers with average *and maximum*, column-wise (one timestamp list, one value list per metric key) so the file stays a few hundred kilobytes; a minute is aggregated from the samples when the next one opens, a quarter from the minutes, so no accumulator is persisted, and the file is written once a minute (`PERSIST_EVERY_SAMPLES`) and on shutdown. `GET /api/system/history?range=1h|4h|24h|7d|30d` serves a cut of one tier (samples up to four hours, minutes up to a day, quarters beyond) with its peaks (`HistoryPeaks`: the highest value, when, and the `UtilizationLevel` it reached against the *current* total) — the evidence for a capacity decision. The verdict is computed on the server (`SystemHealth.assess`, `healthy`/`pressure`/`overloaded` with the rules that fired as reasons) and only rendered by the page, so a later executor change can act on the very same rules; CPU utilization alone never counts, waiting does (load above the core count, pressure, swap). `CapacitySizing.of` (PR#30, corrected in PR#42 and PR#58) sizes the machine from the quarter-hour tier. RAM is judged by *waiting*, never by a fill level (RFC 0004): a quarter hour counts as stalled when its average `memoryPressure` reached `SystemHealth.MEMORY_OVERLOAD_PERCENT` — shared, so a machine the health verdict calls healthy cannot be red in the sizing — and RAM is `tight` from 1 % and `upgrade` from 5 % of stalled quarter hours, the share CPU already uses; swap occupancy plays no part. The peak is named in the reason and never judged, with the single exception that it may still prove slack for a downsize — without the 40 % gate CPU and disk keep (PR#79), since the smaller bookable GiB that holds peak, headroom and reserve is the whole proof; it sizes a raise when one is due, rounded up and at least one step above what is booked, because a stall proves the peak was the ceiling. Disk is judged by the level it *holds* — the 95th percentile of the quarter-hour maxima of the last seven days (`DISK_LEVEL_DAYS`), the percentile the CPU watch band already uses, so a single quarter hour is a moment and not a level (PR#78; upgrade from 90 %, `tight` from 80 % where there is something to raise; the recommendation leaves a fifth free, a third for disks) — and by its growth, the median of the daily deltas of the last week, so a step counts on one day and a trend on most, extrapolated thirty days ahead from the level, only from seven days of history on. The window maximum is named in the reason and vetoes a downsize (under 40 %), never asks for a raise. Every size is rounded to what can be booked (`BookableSteps`, a parameter of `of(...)` that the controllers derive from `HostingEnvironments.bookableSteps` — for Hostsharing 10 GiB per quota, 250 GB per volume, 1 GiB RAM; elsewhere the whole unit), and a downsize is advised only when the next bookable size down would still leave the target headroom, otherwise `fits` with a reason saying why. The steps, unlike the hosting itself, reach every viewer: they name nothing, and one machine must not advise two different things depending on who asks. `ioPressure` (PR#69) is sampled and shown like the other two but read by neither the health verdict nor the sizing, in RFC 0004's order — the series has to exist before anyone can say what a number means, and on a shared hive the disks are the part shared hardest, so it will say more about the neighbours than about this instance until somebody has watched it. `oomKills` is sampled into the history from `/proc/vmstat` as the count per bucket — a counted series (`MetricsHistory.COUNTED_KEYS`, PR#147) whose buckets hold the sum, not the average, and whose range total `GET /api/system/history` serves as `totals` for the OOM kills tile — but deliberately not read by the sizing — the counter is machine-wide, so on a shared hive it counts every webspace's kills. CPU is sized from the quarter-hour *averages*, never the maxima — waiting (load above the thread count in more than 5 % of the quarters, the 95th percentile of those loads being the recommendation) and, below that, the 95th percentile of sustained utilization for the watch band. A CPU is counted in hardware threads (`CapacitySizing.CPU_UNIT`), which is what `availableProcessors` reports and what a webspace is billed by. RAM is advised in bookable whole GiB: the visible total rounded up is the booked size, and the difference the reserve the host keeps. Nothing is advised from less than a day. Served as `capacity` on `GET /api/system` and shown as colour-coded chips in the verdict panel; where the instance can tell it runs on a Hostsharing Managed Webspace (`HostingEnvironments.detect`, served as `hosting`) the chips carry an order button that composes a German mail to the service desk from the change

@@ -74,9 +74,11 @@ data class HistoryTier(
         ) = indices.mapNotNull { source[key]?.getOrNull(it) }
         return Bucket(

@@ -0,0 +6,4 @@
+ * or month. `null` where the range holds no point of the series, so a range sampled before the
+ * series existed says `n/a` rather than `0`.
+ */
+object HistoryTotals {