mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 20:42:43 +00:00
Three defects on one card of the step sub-page, all of them a surface answering a question that belongs to the metric. "Your usual range is -5,595.6-13,387.6 steps", under a chart whose own y-axis refuses to draw a negative step. Same app, same question, two answers: the axis clamped and the sentence beneath it did not. Both now read the same fact. `VALUE_RANGES` already declares every metric's plausibility floor for ingest; `value-domain.ts` reads it and answers "can this metric be negative" for the padded y-domain and for the median +/- k.MAD band alike. The band's lower edge floors at zero for a non-negative metric; `spread` stays the unclamped dispersion so a deviation-in-sigma calculation is unaffected. `buildBaselineBand` now takes the metric it is describing as a required argument, so a new caller cannot quietly reintroduce a negative edge. Two types carried no plausibility range at all, which let any number through ingest and read as "unknown" on the negativity question: walking steadiness gets the same 0-100 percent band as its two gait siblings, the loud-listening event a floor of 1 with a generous ceiling. "13,387.6 steps" also said steps to a reader of German. Five sub-page units are English words, not symbols - steps, flights, falls, years, and a "count" that was a poor label in any language. They now travel as i18n keys through a new `unitKey` on the metric-page scaffold and resolve in all six locales. The thirteen real symbols (bpm, mmHg, %, m/s, kg/m2, ...) stay literals; translating a symbol would be the opposite mistake. And the Min read "104.0 steps". Precision was a per-page prop defaulting to one decimal, so every page had to remember that its metric is a count - and the step page did not. It follows the metric now: a discrete metric (tallies, category events, closed integer instrument scores, ordinal levels) resolves zero decimals wherever it is rendered, and a page only passes the prop to override that.