[CatarinaGamboa]

Found while converting the study exercises (proposal D) to the value form from #502.

@ExternalRefinementsFor("java.awt.Window")
@StateSet(name = "display", value = {"notDisplayable", "displayable"})
interface WindowRefinements { ... }

@ExternalRefinementsFor("java.awt.Component")
interface ComponentRefinements {
    @Refinement("_ ? display(this) == displayable : display(this) == notDisplayable")
    boolean isDisplayable();
}

On main this reports Not Found Error: Variable 'displayable' could not be found at the call, while the shorthand _ ? displayable(this) : notDisplayable(this) is accepted. #510 reads the value form only against sets declared on the argument's type or its supertypes, and display is declared on Window, a subtype of Component.

A Component can be a Window, so a set now also applies when it is declared on a subtype of the argument's type (TypeChecker.isRelatedTo). Sets of unrelated classes are still ignored, so the wrong-set and unrelated-same-name cases from #510 behave as before.

Test: classes/state_value_set_of_subtype_correct (the study's Frame/Window case, with dispose requiring display(this) == displayable); it fails on main with the error above. Full suite: 726 tests pass.

🤖 Generated with Claude Code

[CatarinaGamboa]

Codex review (round 1): No actionable defect was confirmed. The new example passes verification; diagnostics seen during a concurrent full-suite run could not be reproduced when the affected example was run independently.

Clean-code audit (clean-code-principles): nothing to change. The change is one predicate (isRelatedTo) used by both readers of the value form (specs and aliases), so the two stay in sync (core-dry); the name and javadoc say why a supertype's argument may use a subtype's set (doc-why-not-what). One fixture, failing on main (lean tests).

🤖 Generated with Claude Code