Module engine

Expand description

The apply engine: plan from selection + ledger + cache, check, then execute.

plan is a pure function over values the caller has already read, so the decision table is testable anywhere and a plan is reproducible.

Modules§

execute 🔒: Carrying out a plan. The order is fixed: open a restore point holding the ledger as it is now, run the uninstalls, then per package copy out what it replaces, write its ledger entry as installing, and extract.
overlap 🔒
plan 🔒
preflight 🔒
watcher 🔒

HostFacts: What the caller measures through Win32, so this module stays testable off Windows.
Outcome: What a run did, for the summary.
Overlap: A file more than one package in a plan writes. Not an error: the later package wins, the log says so, and the server is told (installer/CLAUDE.md).
Plan
PlanInput
Preflight: What execute reuses, so no archive is opened twice.
Silent: A watcher that ignores everything.

Watcher: Where a run is, and what happened, for the progress bar and the log.

check_writable: Whether this account can write to game_dir, asked when the user settles on it and before anything is installed, so it removes whatever the probe created: a folder the user then abandons keeps no trace.
execute: Carries out plan with what preflight prepared for it.
overlaps: Compared folded, as the filesystem compares names; the file lists come from the caller, who reads each zip once.
plan: Uninstalls always come first, because the style packages ship identical paths and the other order would delete what was just written.
preflight: Everything that can fail is checked before the first file is touched, since a failure after an uninstall leaves neither the old content nor the new.
record_configured: Puts the hashes of the files a game’s configuration step edited back into the ledger, or uninstall would read our own edit as someone else’s.
snapshot_path: The ledger as it was before the run that followed point.