84 lines
2.0 KiB
Markdown
84 lines
2.0 KiB
Markdown
# 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.
|