Runtime packages and identity
The launcher generates the game's embedded native inventory from the selected horizon-mod.toml
manifests: mod id, version and side. Cargo package metadata and hook factories do not supply identity.
The game validates each compiled mod's package at
<executable directory>/horizon-native-mods/<id>/ before installing hooks or starting a world.
Missing, unreadable, content-only or identity-mismatched packages refuse startup with the affected
mods and paths; restore the packages exported with that executable or rebuild it. There is no
build-record fallback and no discovery of native runtime packages from the working directory.
Content-only mods still follow the working directory, player toggles and explicit --dev-mod paths;
a content package cannot shadow a compiled mod's id.
Move the executable, prepared resources and canonical package directory together. The copied
projects retain their flat manifest, crate, assets and data. The game's mod list and crash details
use its embedded inventory, including code-only mods. Display names and descriptions come from the
validated manifests; Controls bindings are declared through Registrar::register_key_mapping, not a separate NativeMod metadata hook.
native-mods.json is provenance and rebuild status, not game identity, authentication, announcements
or startup input. The launcher retains it for build/status displays. The separate horizon-server
supervisor may report the adjacent record as a provenance snapshot, not a query of the running engine.
Its SHA-256 values and revision describe the built binary's inputs, not the running mod set.
The launcher prepares jar data from canonical manifests as non-authoritative candidates; the engine
validates identity against its embedded inventory. Original-jar pack order and
whole-package refusal rules are in Original Java jar layers.