2.0 KiB
2.0 KiB
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.