59 lines
2.0 KiB
Markdown
59 lines
2.0 KiB
Markdown
# AGENTS.md
|
|
|
|
## Project Mission
|
|
|
|
Build Steam Backlog Helper, a small cross-platform Tauri desktop app that helps Steam users with large backlogs pick a game to play now.
|
|
|
|
The MVP is a picker, not a full library manager.
|
|
|
|
## Naming
|
|
|
|
- Official app name: Steam Backlog Helper.
|
|
- Repository name: `steam-backlog-helper`.
|
|
- Package ID: `com.boris.backloghelper`.
|
|
- Internal slug: `backlog-helper`.
|
|
- Avoid putting `steam` in package IDs, bundle IDs, database names, or internal crate/package names unless an external integration specifically requires it.
|
|
|
|
## Confirmed Stack
|
|
|
|
- Tauri
|
|
- Rust
|
|
- Svelte/SvelteKit
|
|
- TypeScript
|
|
- SQLite
|
|
|
|
## Product Constraints
|
|
|
|
- Support Windows 10+, macOS 26+, and Linux AppImage.
|
|
- Keep all user data local.
|
|
- Use user-provided API keys.
|
|
- Include free-to-play games.
|
|
- Exclude demos, tools, soundtracks, and DLC from recommendations by default.
|
|
- Do not build private-profile fallback import for the MVP.
|
|
- Do not build import/export, recommendation history, accepted/rejected tracking, mood tagging, installed-game detection, or manual metadata editing for the MVP.
|
|
|
|
## Development Rules
|
|
|
|
- Prefer small, direct changes over broad refactors.
|
|
- Keep recommendation logic testable outside UI components.
|
|
- Add tests for featureful scoring, parsing, persistence, and integration code.
|
|
- Do not chase coverage on empty scaffolding.
|
|
- Use strict TypeScript.
|
|
- Keep Rust commands narrow and typed.
|
|
- Never commit real Steam, HowLongToBeat, or other provider API keys.
|
|
- Do not log secrets.
|
|
- Make setup and recommendation flows keyboard accessible.
|
|
|
|
## Documentation Rules
|
|
|
|
- Update `docs/implementation-plan.md` when milestone scope changes.
|
|
- Update `docs/architecture-decisions.md` when a meaningful technical decision changes.
|
|
- Update `SECURITY.md` when credential handling changes.
|
|
|
|
## Release Assumptions
|
|
|
|
- Gitea is the primary forge.
|
|
- Gitea runners should handle x86 builds where practical.
|
|
- arm64 builds may be produced locally.
|
|
- GitHub publication may happen later, so avoid Gitea-only assumptions in application code.
|