Blackjack hand summary always shows aces are worth 1, not 11 #39

Closed
opened 2026-08-14 13:26:30 +00:00 by rosa · 2 comments
Owner
No description provided.
Author
Owner

This was generated by AI during triage.

Agent Brief

Category: bug
Summary: The per-card breakdown in a blackjack hand's display scores every ace as 1, so the printed addends don't sum to the printed total

Current behavior:

A blackjack hand renders as its card icons, a breakdown of what each card is worth, and the hand's total. The breakdown asks each card for its value in isolation — where an ace is always 1 — while the total applies the soft rule and promotes one ace to 11 when that keeps the hand inside 21. The two disagree, so the line prints arithmetic that does not work:

A,K       -> 🂡🂮 (1 + 10 = 21)        1 + 10 is 11
A,5       -> 🂡🂥 (1 + 5 = 16)         1 + 5 is 6
A,5,10    -> 🂡🂥🂪 (1 + 5 + 10 = 16)    correct; the ace stays hard here
A,A       -> 🂡🂡 (1 + 1 = 12)          1 + 1 is 2
A,A,9     -> 🂡🂡🂩 (1 + 1 + 9 = 21)     1 + 1 + 9 is 11
dealer ?A -> 🂠🂡 (? + 1 = ?)

Only the display is wrong. The soft total itself is right, so a soft hand plays and settles correctly — this is a bug about what the player is told, not about what a hand is worth.

Desired behavior:

Each card in the breakdown shows the value it actually contributes to the total, so the addends always sum to the total shown.

  • An ace that the soft rule promoted shows 11; every other ace shows 1. Where a hand holds several aces, the leftmost one takes the eleven.
  • While any card in the hand is face down, the total is withheld as ? — and so is any ace, because whether it counts as 1 or 11 depends on cards not yet visible. Non-ace cards keep showing their value.
A,K       -> 🂡🂮 (11 + 10 = 21)
A,5       -> 🂡🂥 (11 + 5 = 16)
A,5,10    -> 🂡🂥🂪 (1 + 5 + 10 = 16)
A,A       -> 🂡🂡 (11 + 1 = 12)
A,A,9     -> 🂡🂡🂩 (1 + 1 + 9 = 21)
dealer ?A -> 🂠🂡 (? + ? = ?)
  revealed-> 🂪🂡 (10 + 11 = 21)

Key interfaces:

  • The rendering shared by Display for Hand and Display for DealerHand — currently it derives per-card values independently of the total, which is the defect. Which ace counts as eleven is one decision and should be reached in one place; the breakdown and the total must not each decide it.
  • HandValue::total is correct and its result must not change. Whatever the fix introduces to attribute values per card has to agree with it for every hand.
  • BlackjackValue::blackjack_value on Card answers what a card is worth on its own, with no hand around it. An ace is 1 there. That contract stays as it is — an ace's promotion is a fact about a hand, not about a card, so it does not belong on this trait.

Acceptance criteria:

  • For any hand with no face-down cards, the addends printed in the breakdown sum exactly to the total printed after the =
  • A,K renders as 🂡🂮 (11 + 10 = 21)
  • A,5 renders as 🂡🂥 (11 + 5 = 16)
  • A,5,10 renders as 🂡🂥🂪 (1 + 5 + 10 = 16) — unchanged, the ace is hard here
  • A,A renders as 🂡🂡 (11 + 1 = 12), the leftmost ace taking the eleven
  • A,A,9 renders as 🂡🂡🂩 (1 + 1 + 9 = 21) — unchanged
  • A dealer hand holding a face-down card and showing an ace renders that ace as ?, alongside the withheld total: 🂠🂡 (? + ? = ?)
  • The same dealer hand after the hole card is revealed renders every value, ace included: 🂪🂡 (10 + 11 = 21)
  • Face-down cards still render as 🂠 with ? for their value, and visible non-ace cards are unaffected whether or not the hand holds a hidden card
  • The existing total tests still pass unchanged — total() returns the same number for every hand it did before
  • The Display for Hand doctest and the dealer hole-card test both currently assert 🂡🂮 (1 + 10 = 21); both are updated to the corrected rendering
  • mise run ci passes

Out of scope:

  • Changing how a total is computed. HandValue::total is correct and the soft rule stays as it is.
  • Introducing "soft" or "hard" wording into the display. The breakdown states values, not vocabulary.
  • Which hands can_double offers on. It admits totals of 10 and 11 only, so a soft hand is treated by its promoted total — that is a separate question about the rules, not about this rendering.
  • Any other game's hand display.
  • The layout of the line itself: icons, the + joiner, the parenthesised = total. Only the values inside it change.
> *This was generated by AI during triage.* ## Agent Brief **Category:** bug **Summary:** The per-card breakdown in a blackjack hand's display scores every ace as 1, so the printed addends don't sum to the printed total **Current behavior:** A blackjack hand renders as its card icons, a breakdown of what each card is worth, and the hand's total. The breakdown asks each card for its value in isolation — where an ace is always 1 — while the total applies the soft rule and promotes one ace to 11 when that keeps the hand inside 21. The two disagree, so the line prints arithmetic that does not work: ``` A,K -> 🂡🂮 (1 + 10 = 21) 1 + 10 is 11 A,5 -> 🂡🂥 (1 + 5 = 16) 1 + 5 is 6 A,5,10 -> 🂡🂥🂪 (1 + 5 + 10 = 16) correct; the ace stays hard here A,A -> 🂡🂡 (1 + 1 = 12) 1 + 1 is 2 A,A,9 -> 🂡🂡🂩 (1 + 1 + 9 = 21) 1 + 1 + 9 is 11 dealer ?A -> 🂠🂡 (? + 1 = ?) ``` Only the display is wrong. The soft total itself is right, so a soft hand plays and settles correctly — this is a bug about what the player is told, not about what a hand is worth. **Desired behavior:** Each card in the breakdown shows the value it actually contributes to the total, so the addends always sum to the total shown. - An ace that the soft rule promoted shows `11`; every other ace shows `1`. Where a hand holds several aces, the leftmost one takes the eleven. - While any card in the hand is face down, the total is withheld as `?` — and so is any ace, because whether it counts as 1 or 11 depends on cards not yet visible. Non-ace cards keep showing their value. ``` A,K -> 🂡🂮 (11 + 10 = 21) A,5 -> 🂡🂥 (11 + 5 = 16) A,5,10 -> 🂡🂥🂪 (1 + 5 + 10 = 16) A,A -> 🂡🂡 (11 + 1 = 12) A,A,9 -> 🂡🂡🂩 (1 + 1 + 9 = 21) dealer ?A -> 🂠🂡 (? + ? = ?) revealed-> 🂪🂡 (10 + 11 = 21) ``` **Key interfaces:** - The rendering shared by `Display for Hand` and `Display for DealerHand` — currently it derives per-card values independently of the total, which is the defect. Which ace counts as eleven is one decision and should be reached in one place; the breakdown and the total must not each decide it. - `HandValue::total` is correct and its result must not change. Whatever the fix introduces to attribute values per card has to agree with it for every hand. - `BlackjackValue::blackjack_value` on `Card` answers what a card is worth on its own, with no hand around it. An ace is 1 there. That contract stays as it is — an ace's promotion is a fact about a hand, not about a card, so it does not belong on this trait. **Acceptance criteria:** - [ ] For any hand with no face-down cards, the addends printed in the breakdown sum exactly to the total printed after the `=` - [ ] `A,K` renders as `🂡🂮 (11 + 10 = 21)` - [ ] `A,5` renders as `🂡🂥 (11 + 5 = 16)` - [ ] `A,5,10` renders as `🂡🂥🂪 (1 + 5 + 10 = 16)` — unchanged, the ace is hard here - [ ] `A,A` renders as `🂡🂡 (11 + 1 = 12)`, the leftmost ace taking the eleven - [ ] `A,A,9` renders as `🂡🂡🂩 (1 + 1 + 9 = 21)` — unchanged - [ ] A dealer hand holding a face-down card and showing an ace renders that ace as `?`, alongside the withheld total: `🂠🂡 (? + ? = ?)` - [ ] The same dealer hand after the hole card is revealed renders every value, ace included: `🂪🂡 (10 + 11 = 21)` - [ ] Face-down cards still render as `🂠` with `?` for their value, and visible non-ace cards are unaffected whether or not the hand holds a hidden card - [ ] The existing total tests still pass unchanged — `total()` returns the same number for every hand it did before - [ ] The `Display for Hand` doctest and the dealer hole-card test both currently assert `🂡🂮 (1 + 10 = 21)`; both are updated to the corrected rendering - [ ] `mise run ci` passes **Out of scope:** - Changing how a total is computed. `HandValue::total` is correct and the soft rule stays as it is. - Introducing "soft" or "hard" wording into the display. The breakdown states values, not vocabulary. - Which hands `can_double` offers on. It admits totals of 10 and 11 only, so a soft hand is treated by its promoted total — that is a separate question about the rules, not about this rendering. - Any other game's hand display. - The layout of the line itself: icons, the ` + ` joiner, the parenthesised ` = ` total. Only the values inside it change.
Author
Owner

The brief contradicts itself on A,A,9, so the implementation departs from one acceptance criterion. Flagging it here rather than quietly resolving it in code.

Two criteria cannot both hold:

  • "For any hand with no face-down cards, the addends printed in the breakdown sum exactly to the total printed after the ="
  • "A,A,9 renders as 🂡🂡🂩 (1 + 1 + 9 = 21) — unchanged"

1 + 1 + 9 is 11, not 21. The A,A,9 line in the Desired behavior block is a copy of the line from Current behavior — the one example the brief did not correct. Its neighbours confirm the intent: A,A is given as 11 + 1 = 12, which uses the promotion, and A,5,10 is genuinely unchanged only because that ace is hard.

The rule stated in prose settles it: "An ace that the soft rule promoted shows 11; every other ace shows 1. Where a hand holds several aces, the leftmost one takes the eleven." A,A,9 has a hard total of 11, so the leftmost ace is promoted and the hand totals 21.

Implemented as:

A,A,9  -> 🂡🂡🂩 (11 + 1 + 9 = 21)

Every other criterion is met as written. Treat this comment as the amendment to that one line.

The brief contradicts itself on `A,A,9`, so the implementation departs from one acceptance criterion. Flagging it here rather than quietly resolving it in code. Two criteria cannot both hold: - "For any hand with no face-down cards, the addends printed in the breakdown sum exactly to the total printed after the `=`" - "`A,A,9` renders as `🂡🂡🂩 (1 + 1 + 9 = 21)` — unchanged" `1 + 1 + 9` is 11, not 21. The `A,A,9` line in the Desired behavior block is a copy of the line from Current behavior — the one example the brief did not correct. Its neighbours confirm the intent: `A,A` is given as `11 + 1 = 12`, which uses the promotion, and `A,5,10` is genuinely unchanged only because that ace is hard. The rule stated in prose settles it: "An ace that the soft rule promoted shows `11`; every other ace shows `1`. Where a hand holds several aces, the leftmost one takes the eleven." `A,A,9` has a hard total of 11, so the leftmost ace is promoted and the hand totals 21. Implemented as: ``` A,A,9 -> 🂡🂡🂩 (11 + 1 + 9 = 21) ``` Every other criterion is met as written. Treat this comment as the amendment to that one line.
rosa 2026-08-14 20:56:16 +00:00
Sign in to join this conversation.
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rosa/casino#39
No description provided.