initial commit

docs/open-questions.md

@@ -0,0 +1,104 @@
+# Answered Product Questions
+
+This file preserves the planning answers that shaped the current implementation plan. It is not an active blocker list.
+
+## Product Scope
+
+1. Who is the first target user: you personally, power users with large libraries, or a general Steam audience?
+   Target users are Steam users with large libraries and many unplayed or lightly played games.
+2. Should the first version optimize for "pick something right now" or for long-term backlog management?
+   The first version should optimize for picking something to play right now.
+3. Should the app recommend exactly one game, a ranked shortlist, or both?
+   It should produce a short-term dynamic list, with one primary recommendation.
+4. Should recommendations feel mostly practical, playful, or a mix of both?
+   Recommendations should depend on short questions the user answers.
+5. Should the app include a pure random mode even when it ignores scoring?
+   Yes. The app should include a true-random toggle.
+
+## Platforms
+
+1. Which operating systems must be supported first: macOS, Windows, Linux, or all three from day one?
+   All three from day one.
+2. Are there specific minimum OS versions to support?
+   Windows 10+, macOS 26+, and Linux AppImage.
+3. Do you care more about small app size or faster development?
+   Small app size.
+
+## Steam Access
+
+1. Are you comfortable requiring users to provide a Steam Web API key during the MVP?
+   Yes. Users should be guided to supply a Steam Web API key. SteamDB may be investigated only after validating availability and terms.
+2. Should the app support private profiles through manual import or local Steam files if API access fails?
+   No. This is out of scope for the MVP.
+3. Should the app launch games directly through Steam, or only help users choose?
+   The app should support Steam app ID launch links.
+
+## Recommendation Inputs
+
+1. What should matter most when picking a game: available time, genre, mood, completion progress, review score, randomness, or something else?
+   Available time, optional genre, completion progress, review score, and randomness should all be inputs.
+2. Should the user be able to define moods such as "relaxing", "story-heavy", "challenging", "mindless", or "social"?
+   Out of scope for now.
+3. Should the app avoid games the user has not installed?
+   No.
+4. Should installed status be detected automatically if feasible?
+   Installed status is out of scope. Include all library games regardless of installed state.
+5. Should free-to-play games, demos, tools, soundtracks, and DLC be excluded by default?
+   Free-to-play games should be included. Demos, tools, soundtracks, and DLC should be excluded.
+
+## Metadata
+
+1. Is estimated time-to-beat required for MVP?
+   Yes. Use a HowLongToBeat-compatible API or provider after validation.
+2. Are third-party metadata providers acceptable?
+   Yes, if they are open or require a key.
+3. Should users be able to manually edit genres, tags, and time estimates?
+   No. Metadata should come from reliable sources.
+4. Should the app use public Steam review data as a recommendation signal?
+   Yes.
+
+## User Data
+
+1. Should all data remain local for the first version?
+   Yes. All data should stay local.
+2. Do you want import/export in the MVP?
+   No. Import/export is out of scope.
+3. Should recommendation history be kept?
+   No. Recommendation history is out of scope for now.
+4. Should the app track whether the user accepted or rejected a recommendation?
+   No. Accepted/rejected tracking is out of scope for now.
+
+## Interface
+
+1. Do you prefer a dense library-management interface or a more guided picker interface?
+   Use a guided picker interface. Dense library management is out of scope.
+2. Should the first screen be the recommendation flow or the full library?
+   The first screen should be recommendations.
+3. Should there be a visual picker mode such as a wheel, cards, or slot-machine style animation?
+   Use a slot-machine style animation.
+4. Should keyboard navigation be a priority?
+   Yes. The app should be accessible via keyboard.
+
+## Technical Preferences
+
+1. Do you prefer Tauri, Electron, or another desktop framework?
+   Tauri is preferred over Electron. Flutter is also acceptable if needed.
+2. Are you comfortable with Rust in the project if using Tauri?
+   Yes.
+3. Do you have a preferred frontend framework?
+   Svelte/SvelteKit.
+4. Should the project prioritize automated tests from the beginning?
+   Prioritize code coverage on actual featureful code.
+5. Should this repo be initialized with Git as part of the setup?
+   No. The owner will initialize Git.
+
+## Distribution
+
+1. Is this intended for personal use, open-source release, or commercial distribution?
+   Personal use, designed for open source.
+2. Should app signing and auto-update be planned early?
+   Try to self-sign binaries where practical. Auto-update should use Git releases.
+3. Do you want CI builds for each platform?
+   Yes. Use Gitea and Gitea runners first, with possible GitHub publication later. Build arm64 locally and x86 on runners.
+4. Should the app have a public website or just release artifacts?
+   The app will be managed through personal Gitea.