The lossless abstractions behind the solve

Outside the four manilhas, suit never affects strength or legality. A plain 3 of diamonds and a plain 3 of clubs therefore have the same future against every possible hand. The solver keeps one plain-3 class; the lab can print any of its four physical suits when needed.

Once plain suits are irrelevant, physical 7s are interchangeable. What matters is only how many remain. In the example below one 7 is already visible, so the tree stores one rank with three remaining copies instead of three named cards. Every newly visible 7 subtracts another copy.

The match is not solved as one monolithic tree. At every new hand, three public facts select a bounded subgame: the score, the dealer assignment, and the turn-up card. Each changes the game that follows, for a different reason.

The solver then rewrites the first two facts in role order. Seat 0 and seat 1 are service identifiers; mão leads round one and pé dealt the hand. Dealer assignment is therefore not discarded and not an extra ×2: it decides which physical player's score occupies each role slot. Rotate the dealer without changing either player's points and the ordered score swaps.

Same physical score in both cases: seat 0 has 5 · seat 1 has 7. The dealer assignment changes which ordered subgame is solved.

How many subgames does that create?

That normalization gives the grid immediately. Mão and pé can each have 0 through 11 points, so dealer-oriented score produces 12 × 12 = 144 role-ordered states. The deck has ten concrete turn-up ranks but only nine exact structural classes; the next section proves the one merge, vira 2 ≡ vira 3. Dealer is not another ×2 because it has already decided which physical score belongs to pé.

Together these are 1,296 exact one-hand subgames. This is what the lab's Score, Dealer, and Turn-up controls select: the score and dealer choose the role-ordered state, and the turn-up chooses one of its nine card trees. They are coordinates of a policy, not cosmetic labels.

How much do the coordinates matter? It has been measured, over converged neighboring solutions: neighboring turn-up classes are nearly interchangeable wherever play actually goes, while neighboring scores disagree on about a seventh of actual play, concentrated in the hand's first moves. That asymmetry is why solutions transfer across turn-ups far more cheaply than across scores.

The surprising case is vira 2 ≡ vira 3. With vira 2, the 3s become manilhas and only three plain 2s remain. With vira 3, the 4s become manilhas and only three plain 3s remain. Rename every strength one step around the deck and the structures match exactly: eight full plain ranks, one three-copy top plain rank, and four suit-ordered manilhas.

That is why the picker may show either 2 or 3 while loading the same exact solution. Your chosen or typed rank is still remembered in every concrete card label; only the strategically identical structure is shared.

Here is the real dependency. At 10 × 11, the player on 11 faces the mão-de-onze choice: accept and play the hand for 3, or fold and concede 1. Accepting makes this hand match-deciding either way. Folding instead creates the next hand at 11 × 11, with the dealer rotated. So the correct fold value is whatever the already-solved 11 × 11 game is worth to this player — not simply “minus one point.”

The solver therefore solves both dealer orientations of 11 × 11 first, across the nine turn-up classes, and stores their chance-weighted continuation values. It substitutes the appropriate stored value into the fold leaf of every 10 × 11 tree, then solves the accept-or-fold decision. Repeating that substitution moves the solution backward through the match. The current turn-up affects the accept branch; after a fold, the deck is reshuffled and the next turn-up is sampled afresh. This is exact dynamic programming, not a truncated horizon.

How large those trees get — and how much of the 1,296-subgame grid is solved so far, at what cost — is ledger material, kept with the rest of the measurements.