Module capabilities 

What the server on the other end of the wire can actually do.

One ServerCapabilities value is resolved per connection, from the version the server already reports at /System/Info/Public, and every decision that depends on the server generation reads a named flag from it.

Why flags and not version comparisons

A version < N written at the point of use re-derives a domain fact where it is consumed — the same error as a Jellyfin taxonomy in the frontend, and the reason check:boundary exists. It is also unreadable by its second occurrence (< 11 says nothing about what changed), and it cannot express a backport, where a behaviour appears in a patch release of an older line.

So the version → flags mapping lives in exactly one function (ServerCapabilities::for_version) and nothing else in the crate compares a version number.

Why an unknown version resolves forward

A server newer than this build resolves to the newest capability set we know rather than being refused. Refusing would make every JellyTau release expire the moment the server upgrades, which is the failure UR-085 exists to remove. Refusal is reserved for a version below MINIMUM_SUPPORTED_MAJOR_MINOR, where failure is certain rather than merely likely.

TRACES: UR-085 | IR-035, DR-280

Structs

ServerCapabilities

The resolved answer, carried by OnlineRepository for the life of a connection.

ServerVersion

A parsed server version.

Enums

ServerGeneration

How this build classified the server it is talking to.

Constants

MINIMUM_SUPPORTED_MAJOR_MINOR

The oldest server this build will talk to, as (major, minor).