CheckRegistry interface

The catalog of every check Venus knows, and the global switch that turns one off for everyone.

api.checks()
Signature	Description
`Collection<Check> all()`	Global definitions, scanned from the plugin. Works with nobody online.
`Collection<Check> of(User user)`	The live checks for one tracked user, carrying violation state.
`Optional<Check> byName(String name)`	One definition by name or stable key.
`Optional<Check> byName(User user, String name)`	One live check for a user.
`boolean enabled(String name)`	Whether the check is currently on for everyone. Unknown names report false.
`void setEnabled(String name, boolean enabled)`	Switches a check off or on globally, and re-applies it to every tracked user.
`int count()`	Number of checks in the catalog.

Definitions versus live checks

Definitions come from the catalog and always report a violation level of 0 and a null handle, because they belong to no session. Live checks come from a user and report real state. The distinction matters when you write a panel: the catalog is what exists, the per-user list is what is happening.

both views

VenusApi api = VenusAPIProvider.get();

// Everything, with nobody online. Good for a web panel or a startup report.
for (Check check : api.checks().all()) {
    System.out.println(check.name() + " [" + check.type() + "] enabled=" + check.enabled());
}

// One player's live state.
api.users().queryUserByName("Notch").ifPresent(user -> {
    for (Check check : api.checks().of(user)) {
        if (check.violationLevel() <= 0) continue;
        System.out.println(check.name() + " VL=" + check.violationLevel());
    }
});

Global toggles

setEnabled is not a one-shot: Venus re-applies the toggle after a configuration reload, because the enable flag is recomputed from checks.yml at that point. A plugin that switches a check off during a maintenance window does not have to re-apply it on every reload.

maintenance window

api.checks().setEnabled("Reach", false);
// ... the maintenance is over
api.checks().setEnabled("Reach", true);

Names

Both lookups accept either the display name (BadPacketsX) or the stable key (badpackets.duplicate_slot). Prefer the stable key in anything you persist: display names occasionally change, keys do not. See Check for the rest of the accessors.