# Settings — Functional Specification **Status:** Approved v1 · 2026-07-21 **Scope of this document:** User-visible access to infrequently changed app preferences and support diagnostics on web, desktop, and Android. Technical implementation follows only after this specification is approved. --- ## 1. Purpose Settings gives language selection and support diagnostics a predictable home without crowding the main comparison workflow. These controls remain easy to find when deliberately sought, but they no longer compete with search, store status, results, or `Pirkumu plāns`. ## 2. Entry point - The app header contains one compact, icon-only Settings action using the conventional gear symbol. - Its localized accessible name and tooltip are equivalent to `Settings`. - The header no longer contains a language selector. - The action remains available on web, desktop, and Android, including narrow layouts, without displacing the purchase-plan action. - No separate global diagnostics icon or text link appears in the main app shell. ## 3. Settings surface - Activating Settings opens a dedicated Settings surface without navigating away from or resetting the current comparison state. - On Android and narrow web layouts it is a full-screen, native-like page with a top app bar and Back action. - On wider web and desktop layouts it is a right-side sheet, consistent with the existing `Pirkumu plāns` interaction. - Closing Settings restores the previous screen, scroll position, search, results, filters, and open purchase-plan data. - Escape and the platform-appropriate Back action close Settings before affecting the underlying app. - The surface uses the app's Spartan NG components and design tokens throughout. ## 4. Language setting - A `Language` section shows a labelled Spartan NG Select containing `Latviešu`, `Русский`, and `English`. - The selected language is visibly marked. The control must not invoke the browser or operating system's native HTML select sheet. - Selecting a language applies it immediately to the Settings surface and the underlying app and persists it under the localization specification. - Language names remain written in their own language; flags are not used. - The control is fully operable by touch, pointer, and keyboard and follows Spartan NG focus, overlay, dark-mode, and disabled-state styling. ## 5. Debug report - A `Diagnostics` section contains a secondary `Open debug report` action with a short explanation that the report is intended for troubleshooting. - Opening it shows one global report for the current diagnostic session, covering recent attempts across all stores newest-first rather than requiring the user to choose a store. - The report remains selectable and provides `Copy debug report`, with visible copied/failed feedback. - If no diagnostic attempts exist, the view explains that no recent diagnostic data is available; it does not invent log entries. - The report retains the existing safe-data rules, 50-attempt in-memory limit, and restart behavior from `FAILURE-DIAGNOSTICS-FUNCTIONAL-SPEC.md`. - Per-store retry and human-check actions remain on store statuses. The debug-report view does not duplicate those operational controls. ## 6. Removal of contextual diagnostics icons - The muted per-store information icons are removed from compact attention rows, wide store-status chips, and the mobile store-status sheet. - A store failure still exposes its existing retry or human-check action and remains visually distinct. - Removing the icons does not clear diagnostic attempts; the global Settings report continues to include them until the in-memory session evicts or clears them. ## 7. Accessibility and responsive behavior - Settings and Back have localized accessible names. - The Settings surface traps focus while open and returns focus to the Settings action when closed. - Section headings, labels, descriptions, select state, copy feedback, and empty diagnostics state are exposed to assistive technology. - The Spartan NG Select overlay stays within the visible viewport and is not clipped by the Settings sheet or Android safe areas. - The full-screen narrow layout respects system bars and safe-area insets. ## 8. Explicit non-goals The first version does not include: 1. User accounts or synchronization of settings between devices. 2. Theme selection; the app continues to follow the operating-system theme. 3. Store selection, adapter management, cache controls, or destructive data-management controls. 4. Persistent or remotely uploaded diagnostic logs. 5. Raw Android `logcat`, Chromium DevTools logs, cookies, headers, response bodies, or challenge tokens. 6. A native Android Activity or operating-system Settings screen separate from the shared app UI. ## 9. Acceptance criteria 1. A gear action opens Settings on web, desktop, and Android without resetting the current workflow. 2. Settings is full-screen on Android/narrow layouts and a right-side sheet on wider layouts. 3. Language is selected through a Spartan NG Select; no native HTML `