[ChakraFusion]

The next standalone PR from the order on #21, rebuilt on dev-public without save versions. Builds on #52 (its commit is the first one here; this PR's own change is the second).

The problem. A game that keeps its settings beside its saves had one PC's graphics settings handed to every other. Crimson Desert's save/user_engine_option_save.xml is one example: the Steam Deck got the desktop's 4K ultra settings, and the desktop got the Deck's back.

Where the list comes from. The game database (the Ludusavi manifest) already says which files are a game's settings: it tags them config rather than save, 16,700 entries.

• The index keeps those now (indexedGame.Config, index format v3, so the index is rebuilt once after updating).
• For each tracked game, the entries inside its save folder become exclusion patterns relative to it (presets.DeviceSettings). They're matched component by component, so a template's <storeUserId> wildcard meets the folder actually tracked, with either path separator (Track a game from the game database; one folder, one game #73's relativeUnder).
• An entry tagged both config and save is a save. A pattern that would cover the whole folder is never applied: a wrong exclusion loses saves, a missed one only syncs a setting.

How they're applied. Exactly like #52's launcher files, through the one function everything that applies exclusions now uses (syncengine.Engine.IgnoreText):

• never synced in either direction, and never deleted on another device;
• still in every snapshot, and kept on this device by a restore;
• the game's own rules come after them, so a ! line brings one back;
• a per-game switch, "Sync these settings between devices too" in the configuration tab, syncs them all. The tab lists the files. The column is migration 0040; the tab's new text is in the catalogs (en, zh-CN), as agreed with Janlhin on Track a game from the game database; one folder, one game #73.

Updating doesn't count as a change. At the first start with this build, files start being left out without anyone writing a rule. A game's last-snapshot hash is re-taken under the new list wherever the save is still the one it was recorded for, so the watcher doesn't snapshot and sync a game nobody played. A save that did change keeps its old hash and its change counts. The base agreed with each device needs nothing: since #52, the sync engine translates a base recorded under other exclusions.

Left for a follow-up: recognising settings files the game database doesn't list, by their contents. It's in my fork, but it's larger and deserves its own review.

Tests:

• presets/devicesettings_test.go: patterns from config entries, a both-tagged entry staying a save, a pattern covering the whole folder never applied, the store-user wildcard.
• syncengine/devicesettings_test.go: settings left out of both directions, the switch syncing them, a game's own ! rule bringing one back.
• daemon/devicesettings_test.go: an unchanged save's last-snapshot hash carried over to the new view, a changed save's not, and a second start changing nothing.

Checks: unit tests, frontend tests and the related e2e tests pass locally; fork CI is green.

🤖 Generated with Claude Code

[vercel]

@ChakraFusion is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Omar-VF]

Reviewed and approved, thanks. Only reading the catalogue's config tags, with the guessing left for later, is the right call. It conflicts with dev-public in the translation files, and with #54 too. Could you rebase it on top of #54 once that's rebased, so the two merge one after the other without another round? It also builds on #52, which is about to be merged.

[ChakraFusion]

Rebased on top of #54 as asked (60f40d0): #52's commit dropped out now that it's merged, so this PR's diff is #54's two commits and its own. Only the catalogs conflicted, and both sides' keys are kept. Unit, frontend and the related e2e tests pass locally.