# Architecture Decisions ## ADR-001: Use Tauri For Desktop Shell Status: Accepted. Decision: Use Tauri instead of Electron for the desktop shell. Reasoning: - Small app size is a priority. - Tauri supports Windows, macOS, and Linux. - Rust is acceptable for native app services. Consequence: - Desktop integration and backend commands will be implemented in Rust. - The project should avoid Node-only runtime assumptions outside the frontend build. ## ADR-002: Use Svelte/SvelteKit For Frontend Status: Accepted. Decision: Use Svelte/SvelteKit with TypeScript. Reasoning: - Svelte/SvelteKit is the preferred frontend framework. - The app UI is interaction-heavy but not content-heavy. Consequence: - Frontend code should use strict TypeScript. - Shared recommendation types should be kept consistent with Rust command payloads. ## ADR-003: Keep Data Local Status: Accepted. Decision: Store app data locally in SQLite. Reasoning: - The MVP is personal-use first. - Cloud accounts and sync are out of scope. - Local storage reduces privacy and operational complexity. Consequence: - No hosted app backend is planned for the MVP. - Import/export is deferred until after the MVP. ## ADR-004: Use User-Provided API Keys Status: Accepted. Decision: Guide users to provide their own Steam Web API key and any required third-party metadata keys. Reasoning: - A hosted proxy is out of scope. - The app is local-first. Consequence: - Credential storage must be treated as security-sensitive. - Development fixtures must never contain real keys. ## ADR-005: Build A Picker Before A Library Manager Status: Accepted. Decision: The first screen and MVP workflow should be the recommendation picker, not a dense library-management UI. Reasoning: - The core problem is deciding what to play now. - Full backlog management adds scope that is not required for the first usable version. Consequence: - Statuses, notes, pinning, import/export, and recommendation history are deferred. - UI work should focus on the setup and picker flows.