preflight: distinguish implicit game masters from MO2 explicit plugins

[FacundoSu1986]

Context

Discovered during the real-rig precheck for PR #580 (feat/dyndolod-pr2-external-staging, tested code SHA ea3f28fbff064a2917690d3851d9a311a388da77).

This is not a PR-2 staging bug. It is a preflight/load-order modeling issue exposed by a real MO2 profile.

Reproduction

MO2 profile Default:

plugins.txt
*EscudoDwember.esp

while loadorder.txt contains, in order:

Skyrim.esm
Update.esm
Dawnguard.esm
HearthFires.esm
Dragonborn.esm
...
EscudoDwember.esp

EscudoDwember.esp has Skyrim.esm as a TES4 MAST dependency.

The current profile resolver prefers plugins.txt when present and derives enabled_plugins from starred entries only. MissingMastersChecker then treats a master that exists on disk but is absent from enabled_plugins as disabled.

Observed preflight result:

masters: red
EscudoDwember.esp -> Skyrim.esm [disabled]

This blocks the ritual even though Skyrim.esm is the base game master and is present in the effective load order.

Root cause

The current model partially conflates:

explicitly enabled MO2 plugins
!=
effective load order
!=
implicit/official game masters

Relevant code paths:

• sky_claw/local/validators/preflight_sensors.py
• sky_claw/local/mo2/plugin_sources.py
• sky_claw/local/validators/missing_masters.py

Current behavior is roughly:

plugins.txt
  -> starred entries only
  -> enabled_plugins
  -> MissingMastersChecker
  -> master present on disk but not in enabled_plugins
  -> DISABLED

That produces a false RED for implicit official masters such as Skyrim.esm.

Required behavior

Preflight should distinguish at least:

explicit_enabled_plugins
implicit_official_masters
effective_load_order
physical_plugin_sources

A base-game master that is installed and implicitly active must not be reported as disabled merely because it is not starred in plugins.txt.

Minimum acceptable fix:

• define the contract for implicit official masters;
• ensure Skyrim.esm, Update.esm, Dawnguard.esm, HearthFires.esm, Dragonborn.esm are modeled correctly;
• handle Creation Club separately and deliberately — do not use a blanket cc* => enabled shortcut without tests/specification;
• preserve genuine RED cases where a real dependency is installed but actually disabled;
• keep MissingMastersChecker fail-closed for true missing/disabled dependencies.

Suggested design direction

Prefer a richer snapshot over one overloaded tuple, for example:

LoadOrderSnapshot
├── explicit_enabled
├── implicit_official
├── ordered_plugins
└── plugin_sources

Then derive effective_enabled explicitly rather than encoding every concept into enabled_plugins.

Acceptance tests

At minimum:

1. EscudoDwember.esp -> Skyrim.esm, with Skyrim.esm installed and present in official/effective load order but absent from starred plugins.txt => PASS.
2. Real mod dependency installed but disabled => RED.
3. Missing master => RED.
4. Base DLC master ordering remains checked correctly.
5. Creation Club behavior covered by explicit fixtures.
6. Existing master-order and plugin-limit sensors remain consistent with the same profile snapshot.

Scope / sequencing

• Do not fold this fix into PR feat(dyndolod): move PR-2 outputs to exclusive external tool roots #580.
• PR feat(dyndolod): move PR-2 outputs to exclusive external tool roots #580 should remain focused on DynDOLOD external staging/recovery acceptance.
• This issue came from the feat(dyndolod): move PR-2 outputs to exclusive external tool roots #580 rig and should be fixed in a separate PR.

Evidence

Real-rig precheck evidence was captured outside the repo under:

E:\Sky-Claw T5 Rig\evidence\PR580-ea3f28fb\2026-09-12_215312-precheck\

Key observation:

Masters check: 1 issue(s)
EscudoDwember.esp -> Skyrim.esm (disabled)

while the MO2 loadorder.txt contains Skyrim.esm before EscudoDwember.esp.