| 8 |
|
This program will: |
| 9 |
|
- Organize these ROM images into a database and on the file system. |
| 10 |
|
- Deduplicate them by not allowing the import of ROM files where by the MD5 Hash that game ROM already exists |
| 11 |
< |
- Using the DAT files from TOSEC and NoIntro, will properly label the ROM images that are misslabled. |
| 11 |
> |
- Using the DAT files from TOSEC and NoIntro, will properly label the ROM images that are misslabled, in the database. The main UI will look to the name from the TOSEC or NoIntro values before defaulting to the file name. |
| 12 |
|
- Games ROMs that dont have matching MD5 Hash values in the DAT files will still be indexed and added. The main focus of the program is still |
| 13 |
|
deduplication. |
| 14 |
+ |
- This confirmed name will also help with matching for artwork and scraped metadata information. However, to increase the chances for a match, if a match doesnt exist with the full confirmed DAT file name, the file name will also be used. The DAT confirmed name will help to narrow the result where as the fallback to using the file name for matching will help to match when one is not intially found. |
| 15 |
+ |
- DAT imports provide authoritative metadata rows (No-Intro/TOSEC) keyed by hash. |
| 16 |
+ |
- When presenting games, Gromulus resolves display name in this order: local game_name, then No-Intro name, then TOSEC name, then filename fallback.” |
| 17 |
+ |
- For artwork/scraper matching, Gromulus attempts normalized name matching using that same priority and falls back to filename stem when needed.” |
| 18 |
+ |
- Unmatched ROM hashes are still imported and deduplicated by MD5.” |
| 19 |
|
- Will also ingest, organize, and display game artwork. |
| 20 |
+ |
- Clicking on the atwork previews will open a modal window with the artwork in full size. |
| 21 |
+ |
- The artwork preview boxes are a set size but the images within scale to fit within that box without changing the aspect ratio, so they dont get stretched. |
| 22 |
|
- Will display these in on a list GUI, for browsing the collection. |
| 23 |
|
- Uses wxPython for the GUI |
| 24 |
|
- main_app_file_hash is central to matching logic. |
| 25 |
|
- The program remembers the last time a DAT file was ingested, with version tracking, so that the user knows if it should be updated. |
| 26 |
< |
- The program handles file naming issues where two rom files have the same name but different hash values. The program adds an incrementing number to the end, so that you have both files in the directory. |
| 26 |
> |
- The program handles file naming issues where two rom files have the same name but different hash values. The program adds an incrementing number to the end, so that you have both files in the directory. |
| 27 |
|
|
| 28 |
|
This file represents my spec-driven development workflow and will be continuously refactored as a living contract for change boundaries and acceptance criteria. |
| 29 |
|
|
| 35 |
|
- Will also support reading the games on these SD cards to show which games have been copied to the card and which have not, so the user can |
| 36 |
|
add additional games to the card. |
| 37 |
|
|
| 38 |
+ |
|
| 39 |
+ |
## Metadata Precedence and Overrides (Working Spec) |
| 40 |
+ |
### Objective |
| 41 |
+ |
Keep user-entered values separate from imported metadata so users can control final displayed values without losing source data lineage. |
| 42 |
+ |
|
| 43 |
+ |
### Data Ownership |
| 44 |
+ |
- main_app.* fields are user-owned application fields. |
| 45 |
+ |
- DAT metadata remains source-owned in no_intro_main and tosec_main. |
| 46 |
+ |
- Future scraped metadata should live in separate scraper/source tables, not overwrite source tables or user fields directly. |
| 47 |
+ |
### Precedence Rules (Display/Matching) |
| 48 |
+ |
1) User override value (when present). |
| 49 |
+ |
2) User/base value in main_app (for example game_name). |
| 50 |
+ |
3) No-Intro metadata value. |
| 51 |
+ |
4) TOSEC metadata value. |
| 52 |
+ |
5) Filename fallback (main_app_file_hash.file_name then main_app.container_file_name). |
| 53 |
+ |
### Write Rules |
| 54 |
+ |
- DAT import updates only DAT tables and import history. |
| 55 |
+ |
- Scraper import updates only scraper/source tables. |
| 56 |
+ |
- User edits update only user-owned fields (or explicit override fields). |
| 57 |
+ |
- No automated process may overwrite user-entered values unless explicitly requested by user action. |
| 58 |
+ |
### Planned User Features |
| 59 |
+ |
- Notes: |
| 60 |
+ |
- Continue using main_app.user_notes as user-owned text. |
| 61 |
+ |
- Favorites: |
| 62 |
+ |
- Add main_app.is_favorite (boolean/int, default false). |
| 63 |
+ |
### Override Model (Future) |
| 64 |
+ |
- Per-field override capability (for example title, description, artwork). |
| 65 |
+ |
- UI should allow selecting source per field: user | no_intro | tosec | scraper. |
| 66 |
+ |
- Selected source should be persisted so display is deterministic across sessions. |
| 67 |
+ |
### Acceptance Criteria |
| 68 |
+ |
- DAT import does not modify main_app.game_name. |
| 69 |
+ |
- A user-edited title remains unchanged after DAT/scraper import. |
| 70 |
+ |
- Favorite and notes persist and are visible in game detail/list contexts. |
| 71 |
+ |
- Display name resolution follows precedence rules consistently in list view, detail view, and artwork/scraper matching workflows. |
| 72 |
+ |
|
| 73 |
|
--- |
| 74 |
|
|
| 75 |
|
## Spec Template (Working Draft) |
