8.5 KiB
AGENTS.md
Project Purpose
Audiogame Manager installs and launches Windows audio games under Wine or UMU/Proton on Linux. Contributions must preserve keyboard and screen-reader accessibility in both console dialog and graphical yad modes.
Repository Map
audiogame-manager.sh: main entry point, game menu, launcher, removal flow, and shared runtime state..install/: one sourced Bash installer per game. The filename, minus.sh, is the game name shown in the install menu..includes/: shared bottle, UMU, download, dialog, desktop, help, update, and URL helpers..includes/ipfs.sh: centralized IPFS URLs for core files and games.game-scripts/: scripts installed or used by particular games after installation.speech/: speech-related helper and setup scripts.wine/: distribution-specific dependency installers and Wine utilities.tests/: isolated shell regression tests with mocked external programs.
Runtime Architecture
- This is a Bash project, not a POSIX
shproject. Arrays, associative arrays,mapfile,[[ ... ]], and Bash parameter expansion are used intentionally. - Installer files in
.install/are sourced by the main process. They share functions and exported state fromaudiogame-manager.shand.includes/; they are not independent programs. - Common installer state includes
game,cache,WINEPREFIX,WINEARCH,winetricksSettings, and helper functions such asdownload,install_wine_bottle,install_proton_bottle,install_with_progress,add_launcher, andadd_umu_launcher. - The launcher configuration is pipe-delimited. Keep its field order compatible with
create_game_array()andprocess_launcher_flags(). - Native Wine and UMU/Proton are separate backends. Use the helpers for the selected backend; do not mix their bottle paths, environment setup, launcher functions, or shutdown functions.
- The main script performs dependency checks, bottle setup, update checks, and other startup work before command dispatch. Do not source it casually in tests. Source the smallest
.includes/file needed and mock its external commands.
Game Installer Conventions
- Name a new installer
.install/Game Name.sh; that filename becomes the menu label. - A first line beginning with
#//hides an installer from the menu. Preserve this convention when editing disabled installers. - Quote paths and expansions, especially game names and Windows paths containing spaces.
- Use
downloadso caching, progress reporting, retries, and validation remain consistent. - Use
install_with_progressfor archive extraction or copies that could otherwise prompt invisibly. Extraction must be non-interactive and safe to repeat. - Use
install_wine_bottleplusadd_launcherfor the Wine backend. - Use
install_proton_bottle, the UMU helpers, andadd_umu_launcherfor the UMU backend. - After installation, verify the expected executable exists before recording a launcher when failure would otherwise produce a broken menu entry.
- Set game-specific environment or winetricks values in the installer rather than changing global defaults for one game.
- Prefer idempotent installation steps. Re-running an installer should not hang on overwrite prompts or silently corrupt an existing bottle.
- Do not delete a shared Wine or Proton bottle to remove one game. Removal code must target only the selected game's files and launcher entry.
Portability and Dependencies
- Contributors and coding agents may use any locally installed tools, including ripgrep (
rg), while searching, reviewing, testing, or editing the repository. This restriction applies only to commands invoked by scripts shipped to users. - Keep commands used by shipped scripts portable. Do not make runtime code depend on ripgrep or other modern command-line tools that are not commonly installed by default when classic Unix tools can provide the required behavior.
- Prefer broadly available classic Unix tools such as
grep,sed,awk, andfindwhen they provide the required behavior. - A nonstandard runtime dependency is acceptable when there is no practical portable alternative, but it must be declared and checked rather than assumed.
- Add every new runtime dependency to
.includes/checkup.sh, including itspackageListentry soaudiogame-manager.sh -Preports it. Update the relevant distribution-specific dependency scripts underwine/when they manage packages for that platform. - If Audiogame Manager cannot perform its basic startup or core functions without a dependency, also add it to the startup checks in
check_requirements()alongside critical commands such assoxanddialog. - Do not assume a developer's interactive shell aliases, local utilities, desktop session, or current working directory are available.
- Resolve repository files relative to
scriptDirorBASH_SOURCE, as appropriate. - Do not add compatibility fallbacks or legacy paths unless they are an explicit requirement.
Shell Style
- Follow the surrounding file's style and keep edits narrowly scoped.
- For new code, use camelCase variables and snake_case functions. Use PascalCase only for class-like concepts if any are introduced.
- Quote variable expansions unless intentional splitting or pattern matching is required.
- Prefer arrays for argument lists; do not construct commands in strings and evaluate them.
- Treat sourced shared globals deliberately. Add a focused ShellCheck suppression with a reason when a value is populated by the caller; do not broadly silence actionable warnings.
- Logging timestamps follow the message:
message [date]. - Do not add colored output unless requested.
Accessibility and Interaction
- Screen-reader and keyboard users are first-class users.
- Use the
agm_*wrappers from.includes/dialog-interface.shinstead of invokingdialogoryaddirectly. Changes must continue to work in both interfaces. - Keep every workflow operable without a mouse. Do not introduce keyboard traps or communicate state only through color, sound, or visual layout.
- Do not use
spd-sayor direct Speech Dispatcher calls in graphical interfaces. Expose information through accessible controls and the existing dialog wrappers. - Avoid commands that can stop at an invisible prompt behind a progress box. Supply non-interactive flags and handle failures explicitly.
- When changing accessibility behavior, verify the exact affected console and GUI workflow when those environments are available. Automated shell checks do not prove live screen-reader behavior.
Downloads, URLs, and External State
- Treat remote URLs, archive layouts, executable names, and installer behavior as changeable external state. Verify them when working on a download or installer rather than relying on an old report.
- Keep reusable IPFS references centralized in
.includes/ipfs.shand preserve their explicitfilenamequery when the cache filename depends on it. - Never include credentials, private tokens, personal usernames, or live user paths in code, fixtures, logs, or examples.
- Do not run destructive installer or removal tests against the real home directory, Wine prefixes, or game data.
Testing and Verification
-
For every edited Bash or
.shfile, run:bash -n path/to/file.sh shellcheck path/to/file.sh -
Fix real ShellCheck findings. A narrow suppression is acceptable for intentionally sourced globals or dynamic source paths when it includes a reason.
-
Run the smallest relevant test under
tests/. Tests must use a temporary directory, replace external programs with stubs, and avoid network, GUI, Wine, and real user-state changes. -
For UMU helper changes, run:
bash tests/umu_backend_tests.sh -
For changes spanning many shell files, syntax-check every changed shell file rather than assuming one successful check covers sourced code.
-
Before handing work back, run
git diff --checkand inspectgit status --short --untracked-files=allplus the final diff. -
Distinguish automated verification from live acceptance. Installer, Wine, audio, focus, controller, and screen-reader behavior may still require a real installation or launch test.
Repository Hygiene
- Preserve unrelated tracked and untracked work. Do not reset, clean, overwrite, or incorporate files outside the requested scope.
- Do not edit generated caches, Wine prefixes, downloaded game data, or logs as source changes.
- Keep contributor changes reviewable; avoid unrelated formatting or refactors in installer fixes.
- Do not commit, merge, push, or alter remote state unless explicitly requested.