626 Mod Launcher v0.6.0

v0.6.0 — the remote game-definition feed

The launcher now keeps its game support current without an app release — it fetches a signed game-definition manifest at startup and merges it over the games baked into the binary. New games on engines the launcher already knows become data PRs to a separate feed repo, not a new build.

What's new

• Added the remote game-definition feed — the launcher fetches signed game definitions from the public 626-game-manifest repo and layers them over its embedded game set.
• Game definitions now refresh without an app update — a new game on a known engine ships as a data PR to the feed, not a release.
• Added an "auto-update definitions" setting (default on) that gates the feed; turn it off and you stay on the games shipped in the binary.
• A bad or missing feed never breaks a working install — offline, bad signature, or a too-new schema all fall back silently to the embedded games. No scary dialog for a network blip.

Day-one coverage — honest

This is the feed turning on, not a flood of games. Day one it carries a small hand-curated set with verified engine + mod path (Skyrim, Oblivion, Fallout New Vegas) plus ~35 Nexus-domain entries, layered on top of the games already in the binary. Engines come from curation only — a wrong engine is worse than none, so mined-but-unverified engines don't ship. Coverage grows by data PRs to 626-game-manifest from here, no app release per game.

Under the hood

• One source of truth. Collapsed KnownEngines / NexusDomains / PopularGames into a single embedded games-manifest.json, with those classes becoming thin facades over it — zero behavior change, facade parity tests untouched.
• Trust core. Pure-Core verify/gate/merge: ECDSA P-256 + SHA-256 detached-signature verify, schemaVersion + minBinaryVersion gating, modPath re-validated through the same forbidden-paths gate as user archives, then merge-over-embedded by id. Public key pinned in the binary; the private key lives only in feed-repo CI. (Ed25519 isn't first-class in System.Security.Cryptography until .NET 11, so P-256 is the dependency-free target — sign and verify pin the same format so they can't drift.)
• App fetch glue. RemoteManifestCache (atomic write + verify-on-read) in Core; RemoteManifestSource in the shell — apply-cached runs before any facade reads, the background refresh fires on a 24h debounce mirroring the app updater.
• The miner. In-repo tools/ManifestMiner builds the feed from mined facts — Ludusavi save/Steam data for the backbone, Mod Organizer 2 mod paths merged by Steam id, then hand-curated overrides/ that win every conflict. Facts-only (uncopyrightable under Feist v. Rural); courtesy NOTICE for Ludusavi, Vortex, MO2, PCGamingWiki. No binaries or code ever bundled.
• Signer + publish filter. The signer signs the exact published bytes with the launcher's own verify format; the publish step tags each entry by the fields it earns and drops skeletal entries — the feed is ~25 KB, not 26 MB.
• Pure-core / thin-shell and reversibility laws held throughout. The manifest is descriptive only — it never describes how to enable or disable a mod; that stays code.

Not yet

• No in-app settings toggle UI for "auto-update definitions" — the field defaults on and persists, but there's no switch in the dialog yet.
• No "your game list is N days stale" nudge.
• No GOG / Epic / Game Pass probing — the schema is store-agnostic so they slot in later, but discovery is Steam-only.
• Mined-but-unverified engines don't ship until curated — breadth grows by data PR.