The problem I needed to solve
A seven-zero hand differs from an ordinary win, and the Hakem’s team matters when classifying it. I did not want that exception duplicated across scoring and interface text.
Implementation in this snapshot
HokmKotRuleResolver.Resolve first checks KotEnabled. Only a seven-zero result enters Kot classification: the Hakem team’s win produces Kot, and the opposing team’s win produces HakemKot.
The design decision and its cost
HokmHandWinType and a separate result preserve that classification. Configurable points come from the game configuration, while feedback can display the appropriate outcome name.
Current boundaries
Classification depends on a valid hand-ended result. A large HUD number alone is insufficient, and disabling Kot must produce the normal outcome.
The same zero score, two different outcomes
Consider two hands in which the losing team wins no tricks. Resolve produces Kot if the Hakem team wins, and HakemKot if the opposing team wins. Zero alone does not determine the outcome name. hakemTeamId is essential context, and the service validates it against the two supported teams. Celebration text, points and recorded results can share one classification rather than independently infer a name from the numbers.
The conditions named teamAWonSevenZero and teamBWonSevenZero compare the winner’s count with config.HandTargetTricks. They do not hardcode seven. The normal Hokm target gives the familiar interpretation, but changing configuration also changes this classification condition. Configuration contracts therefore matter: variable names or product text do not guarantee that every possible setting preserves the intended game meaning.
KotEnabled is checked before special classification; disabling it returns NormalHandPoints. Outcomes that do not meet the target-versus-zero condition are also normal. KotPoints and HakemKotPoints come from configuration, and the resolver does not mutate match scores itself. A caller must apply the outcome through match scoring. The class does not reconstruct hand history either: receiving a classification does not replace validating the hand-ended event.
What this stage taught me
For me, this showed how an exception can become a small, explicit rule. Changing Kot scoring does not need to rewrite hand flow and celebration animation at the same time.
