initial commit
This commit is contained in:
commit
b811d93560
12 files changed
+952
No files matched your search
@@ -0,0 +1,83 @@
|
||||
# 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.
|
||||
Reference in new issue
Block a user