The problem I needed to solve
In Hokm, the Hakem must choose trump before seeing the entire hand. Dealing all thirteen cards at once would remove the limited information that defines that decision.
Implementation in this snapshot
HokmDealFlowService.DealFirstBatch gives five cards to every seat. DealRemainingBatches supplies two four-card batches only after trump selection; completion requires thirteen cards each and an empty deck.
The design decision and its cost
Instead of changing the generic CardDealer, this service owns Hokm’s specialized sequence. Every stage’s counts are checked, and trump selection becomes a real pause in the flow.
Current boundaries
The service requires a 52-card deck and four distinct assignments. Logical count checks do not establish that card-flight animation or Canvas placement is correct.
Five cards as an information boundary
At hand start, DealFirstBatch clears previous hands and resets RuntimeDeck before drawing. It then checks for 52 cards and optionally shuffles. This explains why Hakem selection and the final deal need distinct logical beginnings. BuildAssignmentMap requires four distinct seat assignments. Four objects in a list are insufficient if one seat is repeated: dealing must stop rather than fill one player’s hand in place of another.
Five cards per seat means twenty have left the deck and thirty-two remain. ValidateFirstBatchResult checks that relationship and requires RequiresTrumpSelection. These counts define the stage boundary and the Hakem’s available information. DealCardsToEachSeat deals round-robin rather than delivering five consecutive cards to each player. Starting at the Hakem, seat direction and deck order all affect the actual hands and need to be understood together.
DealRemainingBatches checks trumpSelected and expects each hand to still contain five cards. It executes two four-card batches, then requires thirteen cards per player and an empty deck. The function does not choose trump; the truth of its boolean argument depends on the calling flow. Its validations also do not provide automatic rollback after partial drawing. Stage coordination must deliberately handle failures and restarts.
What this stage taught me
This stage taught me that dealing is more than distribution. The information available to a player at each moment is part of the rules and should remain visible in the architecture.
