Answered Product Questions

This file preserves the planning answers that shaped the current implementation plan. It is not an active blocker list.

Product Scope

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.
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.
Should the app recommend exactly one game, a ranked shortlist, or both? It should produce a short-term dynamic list, with one primary recommendation.
Should recommendations feel mostly practical, playful, or a mix of both? Recommendations should depend on short questions the user answers.
Should the app include a pure random mode even when it ignores scoring? Yes. The app should include a true-random toggle.

Which operating systems must be supported first: macOS, Windows, Linux, or all three from day one? All three from day one.
Are there specific minimum OS versions to support? Windows 10+, macOS 26+, and Linux AppImage.
Do you care more about small app size or faster development? Small app size.

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.
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.
Should the app launch games directly through Steam, or only help users choose? The app should support Steam app ID launch links.

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.
Should the user be able to define moods such as "relaxing", "story-heavy", "challenging", "mindless", or "social"? Out of scope for now.
Should the app avoid games the user has not installed? No.
Should installed status be detected automatically if feasible? Installed status is out of scope. Include all library games regardless of installed state.
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.

Is estimated time-to-beat required for MVP? Yes. Use a HowLongToBeat-compatible API or provider after validation.
Are third-party metadata providers acceptable? Yes, if they are open or require a key.
Should users be able to manually edit genres, tags, and time estimates? No. Metadata should come from reliable sources.
Should the app use public Steam review data as a recommendation signal? Yes.

Should all data remain local for the first version? Yes. All data should stay local.
Do you want import/export in the MVP? No. Import/export is out of scope.
Should recommendation history be kept? No. Recommendation history is out of scope for now.
Should the app track whether the user accepted or rejected a recommendation? No. Accepted/rejected tracking is out of scope for now.

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.
Should the first screen be the recommendation flow or the full library? The first screen should be recommendations.
Should there be a visual picker mode such as a wheel, cards, or slot-machine style animation? Use a slot-machine style animation.
Should keyboard navigation be a priority? Yes. The app should be accessible via keyboard.

Do you prefer Tauri, Electron, or another desktop framework? Tauri is preferred over Electron. Flutter is also acceptable if needed.
Are you comfortable with Rust in the project if using Tauri? Yes.
Do you have a preferred frontend framework? Svelte/SvelteKit.
Should the project prioritize automated tests from the beginning? Prioritize code coverage on actual featureful code.
Should this repo be initialized with Git as part of the setup? No. The owner will initialize Git.

Is this intended for personal use, open-source release, or commercial distribution? Personal use, designed for open source.
Should app signing and auto-update be planned early? Try to self-sign binaries where practical. Auto-update should use Git releases.
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.
Should the app have a public website or just release artifacts? The app will be managed through personal Gitea.