Module resolver 

Disk-aware resolution: given a loaded HookConfig plus a game directory and a scratch/temp directory, decide what should happen to a given rel_key for reads, writes, and deletes, including staging patched replacement files and seeding write targets.

This is deliberately an explicit, constructible type rather than a set of free functions over hidden global state. Two very different consumers need it:

• supreme_hook_proxy (the DLL): one HookResolver, loaded lazily the first time the game probes a magic trigger path, then reused for the rest of the process’s life.
• anything else that wants to know “what would happen to this path” without injecting into the game at all, e.g. a launcher page that reads/writes a game file and wants mod redirection to apply exactly as it would in-game.

Each consumer owns its own lifecycle/caching policy on top of this; the type itself has no global state and no opinion on when it should be constructed.

Structs

HookResolver

Owns a merged HookConfig plus the two directories every resolution needs: the game’s root directory (to reconstruct original paths) and a scratch directory (to stage patched replacement files).

ManagedFileSpec

One remote-backed managed file declared by a RuleTarget::Managed rule. A mod’s mod.json names the file (literal glob), its local path, the URL whose body is the file content, an optional push URL for game writes, and the auto-refresh cadence, the proxy DLL’s generic managed-file engine consumes exactly this, with no per-mod knowledge inside the DLL.

Functions

compute_target_path

Computes the full target path for a redirected file. Returns None if the rule has no target configured, there’s nothing to compute a path against.

is_write_operation

Determines whether a file open operation intends to write or create.

managed_file_specs

Collects every RuleTarget::Managed rule from the loaded config, in config order. Relative local paths are resolved against game_dir exactly like HookResolver::load does, so this accepts either a loaded resolver’s config (absolute) or a raw authored one (relative). Rules whose glob is not literal are skipped here, a wildcard glob cannot name the single file a remote URL provides, and crate::mod_config::ModConfig::validate already rejects them with a proper error at load time; this scan just stays defensive.

seed_target_file

Seeds a sibling temporary file first, then atomically creates a hard link at target_path. Other writers only see a complete copy, and linking does not overwrite a target another writer created. The temporary file is removed after the link is created (or after any error). Both paths are in the same directory, so they are on the same volume. A filesystem that cannot create a hard link fails the seed rather than exposing a partial target or modifying the original.