Injector transactions and recovery

InjectorService owns mutations to a recognized Fluxer installation. Discovery and diagnosis establish whether a target is compatible before any commit.

Target validation

Real installations must use resources/app.asar, a recognized Fluxer package identity, a resolvable ESM main entry, an application-owned preload, compatible Electron isolation settings, and the expected executable identity.

Compatibility is structural, not a fixed Fluxer version allowlist. The controlled fake-Fluxer fixture is recognized separately.

Preview to commit

The service stages proposed output, verifies it, computes affected-file hashes, and reports backup/restart effects. A confirmation digest binds approval to the inspected inputs. Preview staging uses temporary storage.

Execution rechecks those inputs. A stale confirmation is refused. Mutations are backed up and committed through the service; the frontend must not implement parallel file-editing paths.

A no-op reinjection must not unnecessarily rewrite a working installation. Restoration must recover byte-identical pristine archive data when the verified backup and current state permit it.

Process and backup state

Process checks and backup health are separate observations. Backup states include missing, valid, corrupt, stale, and unreadable; presence alone does not imply restorability.

Close first requests graceful shutdown. Force quit is a separate confirmation bound to observed process identities. Avoid PID-only assumptions because process IDs can be reused.

Migration and recovery

Recognized BetterFluxer modifications require explicit digest-bound migration from a validated clean backup. Normal injection does not layer runtimes.

Preserve recovery diagnostics and refuse unsafe operations. Validate changes with injector integration tests covering preview/commit agreement, no-op injection, stale refusal, and pristine restoration.