jheapsandClaude Opus 5
71c198cf2e
The pot wizard printed a figure beside every name under the words "up to". It was that player's own remaining contribution, which is not what winning pays them, and the gap was large and in the wrong direction. Three players in for $250 each: all three rows read "up to $250" while the prompt directly above them said "$765 is in play" — and $765 is what the winner was handed. A dealer who trusted the row would have short-paid by two thirds. With a real side pot it was worse in a more confusing way. The breakdown box at the top of the same dialog announced "Main pot $765 · all 3", and Bob's row three lines under it said "up to $250". One dialog, two numbers for the same money, and the wrong one next to the checkbox the dealer actually ticks. resolveRound caps the pool at the winner's own remaining contribution and then takes min(remaining, cap) from every entry, dead money included — so the ceiling is that sum, and PotCalculator.ceilingFor computes it. Bob's row now says $765, which is the main pot, which is what the breakdown box three lines above has been saying all along. It is also only said where it binds. A ceiling equal to everything on the table is the prompt's own figure repeated once per row — redundant data-ink, and on a pot everybody covered that was all it ever was. It now appears on exactly the rows where picking that winner leaves a side pot still to award, which is the one time a dealer needs telling. The flat pot's three rows carry a name and nothing else; the side pot's carries one number, on Bob. The test that matters is not that the ceiling equals a figure written out by hand but that it equals what resolveRound pays, so every case checks the label against the function that moves the chips — across seven shapes of pot, ragged contributions and cent-sized stakes included. 1082 tests pass; the 418-audit sweep is clean. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb