🇮🇱 עברית

Settings and persistence

NavAid stores browser state under navaid.* keys. The working route and view, UI choices, overlays, profile fields, and saved-route library survive reloads. Transient selection/modal state uses sessionStorage.

The enforceable key policy lives in tests/settings-sync-allowlist.spec.js: every key literal must be in the Drive settings allowlist or have a documented device-local reason. See LocalStorage Schema for the families and sync protocol.

Google Drive

Drive features are opt-in. Saved routes sync in their own app-data file. When Sync settings too is enabled, an allowlisted settings snapshot syncs in a separate file with tombstones, conflict handling, monotonic timestamps, and a local baseline snapshot. API keys, panel geometry, the working route, and any setting that controls where data is sent (such as the AIS filing destination) remain device-local.

Clearing browser storage removes local state but does not implicitly delete Drive app-data. The route library UI owns its Drive actions.

Data flows

Most editing is local. Route/profile content leaves the browser only when the user enables or invokes a feature: Drive sync, an AI-provider request using the user's key, or flight-plan filing. Ordinary external map/asset and selected live weather/aviation requests also occur. Separately, startup automatically fetches a small tuning-config JSON from a GitHub Gist unless ?nogist or ?gist=0 is used; that request carries no route/profile payload. It is not correct to describe the app as always local-only.

The shipped defaults now carry the deployed configuration, so that fetch corrects nothing on an ordinary load — it exists so a value can be changed without a release. The last config seen is cached in navaid.gistCache and applied before the first paint, which is what stopped colours and sizes visibly jumping a moment after every load; the fetch still wins when it lands, and ?nogist ignores the cache as well as the request.