gorkem-bwl
68c1f2e281
Requested by a user who found xx.xx% more trustworthy than xx.x% on their status page. The presentational argument holds, but the stronger reason is that one decimal was actively misleading. Intl rounds to the displayed precision, so every value above 99.95% rendered as "100.0%" — a claim of zero downtime for a period that contained real outages. On a public status page that is the opposite of reassuring: the number reads as flawless during a month with a visible incident. One decimal also collapsed the range operators care about most. 99.9%, 99.95% and 99.99% are three very different commitments (8.7 hours, 4.4 hours and 52 minutes of annual downtime) and the first rendered as 99.9% while the other two were indistinguishable at 100.0%. Everything flows through the shared formatter in FormatUtils, so this covers both surfaces at once: the monitor list and diagnostics gauges in the web app, and the uptime figure, chart cells and hover tooltip on status pages. Infrastructure gauges are untouched — they format separately at zero decimals, where CPU at "43.00%" would only add noise. Server-side precision was already sufficient; the aggregation divides without rounding, so no API change is needed. Adds tests pinning the regression: 7 of the 10 fail against the previous one-decimal formatter. Note: this restores the client Vitest setup. PR #3844 introduced it, but the config, scripts and logger tests were dropped when that branch merged into develop, leaving the client with no test runner again.
This directory contains the client side (frontend) of Checkmate.