Clubs that reconfigure their track (e.g. running indoors in the same
building) can now add named track layouts under Settings, each with
just a start date/time - layouts are contiguous, so a layout's end is
implicitly the next one's start, with no separate field to keep in
sync. Every session freezes which layout was active when it started,
so the "track record" audio cue and the Results Archive (which now
shows each session's layout) only compare laps run on the same
physical track. With no layouts configured, everything behaves
exactly as before - the feature is fully inert until a club uses it.
Design settled through conversation with the user: global scope (not
per class), start-date-only (no redundant stop date), and no changes
needed to driver/transponder mapping, since that's already fully
independent of track geometry in this app.
Deliberately out of scope for this pass: the mobile/driver training
profile's own cross-session personal-best trend stats still compare
across a driver's whole lap ledger regardless of layout - logged in
ROADMAP.md as a real remaining gap for a later pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Settings now shows when a newer version is available, with the real
version number read from the remote's package.json (via the git
binary already required for this deployment model, so it works
against any remote, not just GitHub), and an "Uppdatera nu" button
that stops the server, pulls, reinstalls dependencies and restarts
automatically - warning explicitly if a race is currently active.
The existing app-version poller already reloads the page once a
restart is detected, so no new client-side polling was needed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A real Windows install had sync and backups fail everywhere with
"Failed to fetch" while the server itself was fully healthy - confirmed
via Invoke-WebRequest returning 200 for every endpoint the browser
couldn't reach. The page was opened via a LAN IP while Settings still
had the Backend URL set to 127.0.0.1 from an earlier session; browsers
treat those as different origins, so the server's CORS check correctly
rejected the requests, but a CORS rejection surfaces to fetch() as an
unexplained generic error with no indication of the real cause.
Settings now detects this mismatch on every render and shows the page's
actual address with a one-click button to fix it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
