UpgradeCheck

Evaluates every rule with the capture as side a and the capture plus the Targets as side b. Probe results and run facts describe today's environment, so side b has none: a rule that reads one is unknown. A pending-scanner rule reads keys no scanner emits, so a key missing from the capture counts as unknown there, not as absent. The groups follow Detect's three-valued logic:

• will-break: the rule matches, every fact it reads is known, and at least one matched clause reads a project fact or an environment key that is not a target.

• may-break: every fact the rule reads on a target key is known and the verdict is unknown because another fact is missing or no scanner emits it yet.

• version-boundary: the rule matches but every clause that matched reads only a target key, so the evidence is the version crossing alone; no project fact or other environment key was read.

• outside-range: the rule matches, every fact it reads is known, and every symptom of the rule has the basis range: the source lists a compatible range and states no failure outside it. The group takes the place of will-break and version-boundary.

• unknown: the capture lacks the current value of a target key, or the target is not a version the rule can compare. A rule that matches only because that value is missing is listed here too, not as will-break.

Locked packages are checked apart from the rules: a package whose recorded runtime constraint allows the capture's runtime and excludes the target is listed in UpgradeReport.packages (see PackageConstraints); a lockfile that records no constraint is listed in UpgradeReport.unchecked.

Only rules with a condition on side b (or a cross or changed condition) that reads a target key and gives another verdict for the target than for the capture itself are reported. A rule that already matches without the targets is left out.