SikamikanikoBG/homelab-monitor

This is one PR, not a milestone. samples_1h keeps full history and scans in 0.09 ms, and /api/data already takes a range and buckets the data. Add until alongside range, and absolute from/to in the existing range selector. Write the range into the URL hash so any chart view is a shareable permalink. Label the resolution: 10 s inside 48 h (raw cap since 002f40f), 1 h beyond. Out of scope: rewinding the Map/inspector. That would mean threading t through ~12 renderers, 8 chart builders and 101 CURRENT_HOST reads. Source: pehota's v1 re-baseline review.

static/dashboard.html is served uncompressed at 865,642 bytes. With gzip it's 274,047 bytes: 3.16× smaller, or −590 KB on every first load. It's about two lines of code plus a requirements.txt pin. Done when: Content-Encoding: gzip (or br) is returned for HTML/JS/JSON. SSE /api/stream is excluded, because compression buffers the stream. The snapshot tests still pass. Source: pehota's v1 re-baseline review (reviewed at 5530ad0 / v0.37.0), re-checked against next @ 5c683e3 on 2026-10-02.

The dashboard is a single-file, dark-mode, chart-heavy page, and accessibility got no dedicated pass. Current state in static/dashboard.html: 40 aria-label attributes vs 4 tabindex, Chart.js canvases with no text alternative, and the tab/filter controls are mouse-driven. Nothing is broken in an aggressive way — but a keyboard-only or screen-reader user has a rough ride. Suggested scope (take any section — each is independently shippable) Keyboard reachability: tab order through the sidebar tabs, range filters and card actions; visible focus styles in the dark theme. Landmarks & roles: role on the data tables, labels on icon-only buttons (the inline-SVG header icons in particular). Charts: a short text summary per chart (peak/last value) so the sparklines aren't canvas-only. Colour: the status colours (green/amber/red dots) shouldn't be the only channel — a text state is already rendered next to most of them, so verify coverage. A PR that takes one section with a short "what I c

The security model is real and partly tested — tests/test_hardening.py covers the per-host posture checks, docker-compose.readonly.yml exists for a read-only setup, the MCP server documents its read-only guardrail, and API-key auth for the API surface lives in backend/auth.py. But the documentation is scattered: one paragraph in features.md, a "Security model" section in how-it-works.md (the no-login design decision, the read-write Docker/D-Bus sockets, the "keep it behind your LAN" guidance), and nothing else. There's no dedicated page, and the nav (mkdocs.yml) has no entry for it. For a self-hosted tool that SSHes into your fleet, that's the page a newcomer looks for first. Suggested scope A website/security.md page that gathers what's already true and documented in one place, and adds what's missing: the no-login design decision and why (already in how-it-works.md), the socket/D-Bus privileges and the write-action flags that reduce them, API-key auth for the API/MCP surface, the

The GPU tab decodes nvidia-smi's throttle bitmask into human reasons and feeds the sustained-throttle alert (gpu_throttle_sustain_s, default 120 s). For AMD cards that whole path is dark: throttle_mask / throttle / throttled are only ever set on the NVIDIA path (the nvidia-smi enrichment, app.py:5916-5919). _amd_enrich_card (the amdgpu counterpart) attaches mem_util, clocks, power_limit, p-state and temp_mem from amdgpu sysfs — but no throttle signal at all. The sample repo therefore stores throttle = 0 for every AMD sample (backend/db/repos/gpu_samples.py maps throttle → throttle_mask, defaulting to 0), so the kind of SW_THERMAL_SLOWDOWN ratchet an NVIDIA card reports has no AMD equivalent here and the GPU cockpit's sustained-thermal-throttle alert cannot fire on an AMD box, even when the card is genuinely clocked down. amdgpu exposes enough to derive a "throttled" verdict without ROCm: the pp_dpm_* clock tables (already read for p-state in _amd_enrich_card), hwmon frequency vs