The acting seat was distinguished by a rim colour and nothing else
Measured: a gold border and a 2px ring, where a live seat has a green border and a 1px one. Same fill, same size, nothing moving. That's a subtle thing to ask a dealer to spot across a table on a phone — for the one state the whole pace of the game hangs on.
It reads as lit now rather than merely outlined: a solid gold ring at full strength, a warm glow separating it from the felt, a warmer fill, and it sits above its neighbours so the ring is never clipped by the seat next to it.
There's also a slow 2.4s breath, which stops entirely under prefers-reduced-motion — the ring carries the whole job on its own for anyone who'd rather nothing moved. Checked rather than assumed: animation: none, ring still at full strength.
The lift is box-shadow, not transform
A seat's transform is what positions it around the felt, so setting one here would throw it off its spot — the same trap that nearly shipped a 38px seat displacement in #44. Verified the transform is preserved at every size.
One measurement I'm not claiming
The acting and live fills differ by only 1.1:1, because the change is a hue shift rather than a lightness one. The ring and the glow do the work; the fill just stops it looking like the same chip. Worth saying plainly rather than quoting a number that sounds better than it is.
Validation
Eight viewports: layout and contrast audits clean, exactly one acting seat everywhere, and the lit seat is the same size as its neighbours at every size — the ring adds no layout. renderAll is 1.8ms with the pulse running, so it costs nothing. Text on the warmer fill still passes contrast everywhere. 137 unit tests passing, no console errors.
One note: my first sweep flagged the acting seat's box as wrong at four sizes — that was my own hardcoded 76x72 expectation, since seats are legitimately responsive (93x73 on tablet, 111x73 on desktop). Re-checked acting against non-acting at the same viewport, which is the comparison that means something.
Asked what actually slows a home game down, and the answer from people who deal them is consistent — not how fast the cards come out:
> "Waiting for shuffling and players not realizing it's their action is going to cost much more time than how quickly you spread the flop"
Stacked on #56.
## The acting seat was distinguished by a rim colour and nothing else
Measured: a gold border and a **2px** ring, where a live seat has a green border and a **1px** one. Same fill, same size, nothing moving. That's a subtle thing to ask a dealer to spot across a table on a phone — for the one state the whole pace of the game hangs on.
It reads as **lit** now rather than merely outlined: a solid gold ring at full strength, a warm glow separating it from the felt, a warmer fill, and it sits above its neighbours so the ring is never clipped by the seat next to it.
There's also a slow 2.4s breath, which **stops entirely** under `prefers-reduced-motion` — the ring carries the whole job on its own for anyone who'd rather nothing moved. Checked rather than assumed: `animation: none`, ring still at full strength.
## The lift is box-shadow, not transform
A seat's `transform` is what positions it around the felt, so setting one here would throw it off its spot — the same trap that nearly shipped a **38px seat displacement** in #44. Verified the transform is preserved at every size.
## One measurement I'm not claiming
The acting and live fills differ by only **1.1:1**, because the change is a hue shift rather than a lightness one. The ring and the glow do the work; the fill just stops it looking like the same chip. Worth saying plainly rather than quoting a number that sounds better than it is.
## Validation
Eight viewports: layout and contrast audits **clean**, exactly one acting seat everywhere, and the lit seat is **the same size as its neighbours at every size** — the ring adds no layout. `renderAll` is **1.8ms** with the pulse running, so it costs nothing. Text on the warmer fill still passes contrast everywhere. 137 unit tests passing, no console errors.
One note: my first sweep flagged the acting seat's box as wrong at four sizes — that was my own hardcoded `76x72` expectation, since seats are legitimately responsive (93x73 on tablet, 111x73 on desktop). Re-checked acting against non-acting at the *same* viewport, which is the comparison that means something.
Sources: [As a dealer, how do I increase hands per hour?](https://www.pokerchipforum.com/threads/as-a-dealer-how-do-increase-more-hands-per-hour.114914/), [Tips and Advice to a Faster and Better Dealer](https://forumserver.twoplustwo.com/27/casino-amp-cardroom-poker/tips-advice-faster-better-dealer-241644/)
jheaps
changed target branch from feature/casino-holdem-raise-guard to master2026-09-01 09:31:48 -06:00
Two ways to lose a hand's money by accident, both found by walking the settle
flow and checking the chip count afterwards.
Next Hand destroyed an unresolved pot silently
Starting the next hand clears every seat's contribution, so money still in the
middle simply vanished. Measured at a four-handed table with $8 in the pot: the
table went from 800 chips to 792, and the toast said "Next hand — button on seat
3. Blinds posted." — not a word about the eight chips that had just left.
It now asks, names the amount, and says what will happen to it. Confirming still
works and the toast says what went. The undo was always there, but a dealer
can't undo something they were never told about.
The wizard's "Close" abandoned a payout that looked finished
After picking winners and confirming, the wizard shows "Final Payouts — Ann $8"
above two buttons: "Start Next Hand" and "Close". Close pays nobody. Under that
heading, with a name and an amount beside it, a dealer taps Close believing the
pot has been pushed — and walks away with the chips still in the middle and the
hand unlogged. The button now says "Cancel — don't pay yet", with a line
underneath spelling out that nothing has been paid.
The warning measures the right thing
The first version counted the pot badge, which was wrong in a way the tests
caught before it shipped: the table-wide base pot is a standing ante for dealers
who don't track stacks, and it re-applies to the next hand rather than being
lost. Quoting it would have put a confirmation in front of those dealers before
every single hand — a nag, on the simplest way to run a table, for money that
wasn't going anywhere.
HoldemState.unresolvedContributions() measures exactly the fields startNextHand
clears: banked contributions, chip counts, and whatever is still in front of
players on this street. Verified both ways in the browser — a base-pot table
showing a $100 pot is not asked at all, a stack-tracking table with $8 live is.
6 tests (115 total): the quoted number equals what actually leaves the table,
mid-street chips are included, a settled hand leaves nothing to warn about, five
settled hands conserve every chip, an empty table has no phantom pot, and a
standing ante is never warned about.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Ran out of things I could find by auditing the UI, so I went and read what people
who run home games actually complain about. The recurring one isn't a dealing
mistake, it's a banking one: "the last two guys go to cash out at the end of some
all-night game and there isn't enough cash to cover the chips they have."
Every chip on the table is a promise to pay cash for it later. Nothing in here
checked that the promise could be kept, and there's no way to notice by eye —
it's always a rebuy nobody wrote down, or chips taken without paying, and it
stays silent until the box is empty and two people are still holding chips.
The books now add up, or say why not
HoldemState.bankReconciliation compares the cash taken in against every chip that
could be handed back — stacks, chips in front of players, and the pot waiting to
be won. The sidebar shows both numbers and what they mean:
Balanced — the cash covers every chip on the table.
$160 more in chips than cash taken. Someone's rebuy probably wasn't
recorded — the box will be short at cash-out.
$150 more cash than chips in play. Someone has paid for chips they
haven't been given.
Money in the middle counts as chips in play, so an open pot isn't reported as a
shortfall — otherwise it would cry wolf during almost every hand.
Players who had bought in were missing from the settle-up
sessionStandings was built from the hand log, so anybody who hadn't yet been in a
recorded hand didn't appear at all. Somebody hands over $200, sits down, folds a
few, and the banker's own record doesn't mention them — then they turn up at
cash-out holding chips the list never accounted for. Anyone with money in the
game is in the list now, whether or not they've played a logged hand.
The settle-up number was already being computed and hidden
cashPosition — chips in front of them less the cash they handed over — was
calculated for every player and written to the CSV, but never shown on screen.
It's the number you read while counting out cash at the end of the night, so it's
a column now.
15 tests (127 total): a buy-in with no hands played still appears and reads as
level rather than a loss, empty chairs stay out, a player who cashed out shows
what they took, both directions of imbalance are caught, an open pot is not a
discrepancy, six played-and-settled hands never knock the books out, a proper
rebuy balances while a chip grab doesn't, and float dust isn't an alarm.
Validated with Playwright through real play — seated, blinds posted, pot open,
hand settled, rebuy — balanced at every step, plus the three seeded verdicts and
a fresh table where the panel stays hidden.
Sources: pokerlistings.com/blog/how-to-run-a-home-poker-game,
chipsoffury.com/learn/how-to-handle-poker-buy-ins-with-friends/
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Went looking at dealer procedure again and ended up checking the rule home games
argue about longest. The tool had it wrong.
Blinds 1/2. Seat 4 raises to 10 — a full raise of 8. Seat 1 calls. Seat 2 is
all-in for 13: three more, where a full raise would need eight. Under TDA rule 44
that does not reopen the betting to anyone who has already acted; they owe the
extra three or they fold. Seat 1 and seat 4 were both being handed another go.
Two things were wrong in raiseTo. Any increase at all reset hasActed for every
live player, so a short shove gave the whole table another chance to raise. And
lastRaiseSize was overwritten with the short amount, so the next legal raise was
computed off 3 instead of 8 and came out too small — a second, quieter error that
only shows up when somebody then tries to raise.
Both now key off whether the increase was actually a full raise. A player who had
not yet acted keeps full rights, which falls out naturally because their hasActed
is already false — that distinction is the part of the rule people get wrong in
the other direction.
Everyone still owes the difference: isStreetComplete already asks anyone with
chips left to call, so the short all-in is answered without being re-raiseable.
The rulings sheet now covers what the tool does for you
It had three entries. A dealer challenged on a payout couldn't look up why the
tool did what it did, even for the rules it enforces automatically. Added the
short all-in rule above, uncalled chips coming back rather than being announced
as a side pot, and the odd chip in a chopped pot going to the first player left
of the button — all three are things this tool already decides silently, and all
three are worth being able to point at when somebody objects.
10 tests (137 total): already-acted players aren't reopened but still owe the
difference, a player yet to act keeps full rights, the minimum raise isn't
shrunk, calling it ends the street, no chips are created, and — the other half of
the rule — a full-sized all-in, an ordinary raise, a raise exactly matching the
last one, and a full-sized opening bet all still reopen everyone.
Validated through the real action bar: after the short shove, lastRaiseSize stays
8 and the player who had already called stays settled, while the two who hadn't
acted keep their turn. The longer rulings sheet still fits a phone, scrolls, traps
focus and closes on Escape.
Sources: TDA rules via thelodgepokerclub.com/tda-rules/,
pokernews.com/strategy/deal-with-it-tips-for-mistake-free-dealing-in-home-games-30231.htm
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Went looking for more rules bugs and didn't find any — the blind rotation is fair
over an orbit, nobody is double-charged or skipped when players come and go, and
the big blind's option is handled correctly including heads-up and when the blind
puts them all-in. Those probes are written up below.
What I did find was a regression I shipped two rounds ago.
The name column was zero pixels wide
Adding the "Cash out" column in the bank-audit round made five columns. Four of
them are numbers with a 4.5rem minimum, which with gaps needs 320px — and the
sidebar is about 290px. The name column is the only flexible one, so it absorbed
the shortfall and collapsed to nothing. Player names were not truncated, they
were entirely invisible, and the row quietly overflowed.
Measured at 360, 390, 1024, 1280 and 1600 alike, because the sidebar is narrow at
all of them — this was not a phone problem, it was everywhere except the tablet
layout where the sidebar goes full width. Names were already down to 50px with
four columns, so this had been getting worse before I finished it off.
The table earns its columns now instead of assuming them
Narrow: player, net, cash out — the two numbers a banker settles up from. Wide
enough: the per-hand In and Won as well. A container query rather than a viewport
one, because the sidebar is 290px at both 360px and 1600px viewports and the
thing that matters is the space the table actually has. Names get a real minimum
and ellipsis rather than being crushed. Everything stays in the CSV either way.
360x640 name 0px -> 152px Player | Net | Cash out
390x844 name 0px -> 182px Player | Net | Cash out
768x1024 name -> 389px Player | In | Won | Net | Cash out
1280x900 name 0px -> 151px Player | Net | Cash out
Rules probes that came back clean, so nothing changed:
- blind rotation over 12 hands with 4 players: exactly 3 big blinds each
- a player leaving and rejoining mid-session never causes a double or a skip
- the big blind gets their option when everyone limps, can raise with it,
and checking it ends the street
- a big blind left all-in by the blind itself gets no phantom option
- heads-up, the button acts first pre-flop and the big blind still has the option
- post-flop the minimum bet falls back to the big blind
Re-checked the guarantees from earlier rounds with the sidebar open: 0 of 50
controls on touch-action auto, 0 tap-highlighted, 0 occluded, stacks still inside
their pucks, no sideways scroll, bank panel still fits and reads correctly.
137 tests still passing.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Last round I found a regression I'd shipped two rounds earlier: the standings
table's player-name column was zero pixels wide, at every viewport, and nobody
noticed because the audit that would have caught it only ever existed in a
previous session's scrollback. These checks have been re-written by hand at least
six times, and each time they covered only whatever had just changed.
So they're a file now. uiAudit.js runs in the page — no build step, no
package.json, no dependency — and checks touch-action and tap highlights, that
fields stay selectable and are big enough not to trigger iOS zoom, that nothing
important is covered or stranded off-screen, that no grid column has collapsed to
nothing, and that no text is painted outside its box. runUiAudit.js drives it over
the table, all five overlays and Quick Split at thirteen viewports. Deliberately
outside CI: the unit suite is dependency-free and runs in a second, this one needs
a browser and a running site.
Three real faults it found on its first run
Fields were 13.3px on every iPad. The 16px minimum that stops iOS zooming the page
on focus went in inside a max-width:700px block, and every iPad is wider than
that — so a dealer on a tablet, which is the device this is most likely to be
propped up on, got the table zoomed every time they touched the blind amount. The
reason for that rule was never "narrow screen", it was "iOS". Font size applies at
all widths now, and the 44px touch targets key off hover:none, which is what
actually distinguishes a finger from a mouse.
The seat menu couldn't be scrolled. It had no height limit and no overflow, so on
a phone held sideways its first two actions — Fold and All-in — sat below the
bottom of the screen with no way to reach them. A dealer in landscape could
long-press a seat and then not fold it.
The pot wizard sat under the action bar. Every other overlay is z-index 90-98; the
wizard alone was at 50, below both the action bar at 55 and the toast at 80. In
landscape one of its inputs was completely covered by the Fold button, and a toast
could sit over "Confirm Winner(s)". It was the odd one out rather than a decision.
Three faults in the audit itself, found by checking before acting
Worth recording, because each would have had me "fix" something that wasn't broken:
- an ellipsised name was reported as painting outside its seat. A Range measures
laid-out text, which runs past the element while overflow:hidden quietly clips
it. Only overflow that is actually visible can paint over a neighbour.
- every link below the fold was reported as off-screen. Something under the fold on
a page that scrolls is reachable; the check now asks whether scrolling can bring
it into view, which is the thing that actually matters.
- a button in the newly-scrollable seat menu came back "covered by null".
elementFromPoint returns null for a point outside a scrollable ancestor's clip —
scrolled out of view, not covered by anything.
A toast partly over a control is a warning rather than a failure now: it dismisses
itself and carries a close button, and on a desktop it necessarily lands over a
table that fills the content column. Fully covered by a toast is still a failure,
because that was a real bug once — a seat sat exactly under the Undo button.
Final sweep: 13 viewports, 65 overlay checks, 13 full-page audits, 4 Quick Split
audits, zero failures, one warning. 137 unit tests still passing.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Contrast is the one check I've got wrong twice, both times by being clever about
backgrounds. The first version read only background-color, so text on any of the
gradient-painted sheets was measured against transparency and the dealer puck's
dark "D" was reported at 1.2:1 against nothing. The second over-corrected and
treated low-alpha gradient stops as opaque, scoring white-on-dark at 1.0:1.
So this one is built to be incapable of false positives rather than exact.
Backgrounds composite through alpha; where a gradient is involved every colour stop
is tried and the most flattering one used. A finding means the text fails even
under the reading most generous to it.
It's checked against known answers before being believed: black on white at 21:1,
white on white at 1:1, #767676 on white at the 4.54:1 AA boundary, white over a
dark gradient, dark text on that same gradient, white over a 6% white wash on a
near-black page. Nine cases, all correct — and building them found a real bug in
the check, which walked past an opaque gradient and offered the page background as
a candidate. That made it too lenient, which is as bad as the old false positives.
What it found:
Both blind badges failed against their own gradients, in 9px bold text a dealer
reads at a glance across a table. At the worst stop: small blind 3.52:1, big blind
2.15:1. The small blind keeps its blue and darkens to 4.77:1. The big blind flips
to dark text on brighter gold, 5.84:1 — how a gold chip is marked anyway, and it
makes the two badges far easier to tell apart at speed.
Quick Split's footnote names a control the dealer is told to reach for, and that
name inherited the muted grey of the surrounding aside: 3.39:1. Emphasised text
carrying an instruction gets its own colour now.
The felt watermark came back at 1.19:1 and is meant to. It's decoration; holding it
to a reading threshold would mean making it not a watermark. It's aria-hidden now,
which says the same thing where it also does some good, and the audit skips
aria-hidden subtrees.
32 contrast passes over the table, all five overlays and Quick Split at five
viewports: zero findings, zero unmeasured. Layout audit still clean. 137 tests pass.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Ran the touch-target check that had been sitting in the audit unused. The dealer
puck is 22x22 — half what a fingertip needs — in ten places on the table, and
tapping it hands the button to that seat and re-posts the blinds. Not a cosmetic
control.
It stays 22x22. A puck should look like a puck sitting on the rim of its seat, and
growing it would take area from the seat itself, which a dealer taps far more
often. Instead an invisible pad around it catches the tap: 43x44 hittable on every
phone size, close to four times the area, with the pad pushed down and left away
from the seat the chip juts towards. Verified that no seat tap is stolen — the
occlusion audit is clean at every size.
Three things the check itself got wrong, all found before acting on them
It read element boxes, and boxes lie in both directions. A control padded out with
a transparent ::after responds well past its painted size, and a checkbox wrapped
in a label is hit by tapping anywhere on the label — so it reported the dedicated
dealer toggle as a 24px fault when it sits inside a 320x44 label that already
forwards the tap. It probes outward with elementFromPoint now, which is what a
finger actually experiences.
The probe walked a fixed 40px each way, so everything wider than 80px reported
exactly 80. Every header button came back a suspiciously round "80x42".
And it enforced 44px on desktop, where there is no fingertip. Those same header
buttons are 64px tall on a phone and 42px with a mouse, which is not a defect.
Keyed off hover:none now, the same signal used for the tablet field sizing.
Also removed a ::after pad on the dedicated-dealer checkbox that was both inert --
pseudo-elements don't render on replaced elements -- and unnecessary, since the
label already does the job.
The puck is the one documented exemption: it is deliberately small and "Give the
button" is in the seat menu at full size, so it's a shortcut rather than the only
way through. The reason sits in the code next to the exemption.
Phone sizes: dealer chip 22x22 drawn / 43x44 hittable, zero undersized controls
even with the exemption and the pointer rule forced off. Layout and contrast
audits clean at all seven sizes. 137 tests passing.
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Web search turned up the oversized-chip rule described as the single most common
cause of floor disputes, and specifically a home-game problem. Chasing that led to
checking what the bar does with an illegal raise, and the answer was: nothing.
With the minimum at $18 and a player holding $200, typing 13 was accepted without
a word. The engine then treated it as a short raise and correctly declined to
reopen the betting -- right for an all-in, wrong for somebody who just misheard
the bet, and either way the dealer was never told.
The raise entry now says what's wrong and still lets it through. This tool records
what the humans at the table actually did, and a dealer overruling the arithmetic
is right more often than the arithmetic is, so Confirm stays enabled in every case:
$13 is under the $18 minimum. A legal raise is $18 or more -- otherwise
it's a call, or all-in.
All-in for less than a full raise. Legal, but it doesn't reopen the
betting -- anyone who has already acted owes the difference or folds.
More than they have. This goes in as all-in for $200.
$10 is not above the $10 already bet -- that's a call, not a raise.
The second one surfaces the rule fixed two rounds ago at the moment it decides
something, rather than only in the rulings sheet.
Two minimums, which is where the first attempt went wrong
The pad already had a minimum, clamped to what the player can actually put in --
correct for the Min button, wrong for the warnings. For a short stack the clamped
minimum equals their all-in, so neither warning could ever fire for exactly the
player the rule exists for. Kept separate now: one for the button, the rules one
for the warnings.
A regression the audit caught, in the same round that introduced it
The note makes the raise pad taller, --actionBarHeight grows, and the toast --
which floats just above the bar since the occlusion round -- got pushed up over
the table. Measured at 360x640: bar 122px closed, 178px with the pad, 217px with a
note, and the toast climbing from y506 to y411, covering seats outright.
A toast is transient news about the action just taken; the pad is the dealer
deciding the next one. The older one gets out of the way when the pad opens --
nothing is lost, its Undo is also the bar's own undo control. The note is tighter
on short screens, and the pot breakdown hides during entry, since which side pots
exist isn't what's being read while typing an amount. Net: 210px rather than 217px,
and no seat covered that the pad wasn't already covering at 178px.
Two rulings entries, from the same search
The oversized chip -- a single big chip pushed out silently is a call, not a raise,
however big it is; to raise you say so before it lands. And what a full raise is,
which the pad now enforces in words.
137 tests passing. Raise warnings verified across four amounts on a deep stack and
three on a short one, at eight viewports: note shows, pad stays reachable, contrast
clean, Confirm never disabled. Toast still behaves normally when the pad is closed.
Sources: cardplayer.com/.../contracts-and-poker-the-oversized-chip-rule,
pokernews.com/strategy/be-careful-when-betting-essential-wsop-rules-to-remember
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
Asked what actually slows a home game down and the answer from people who deal
them is consistent: not how fast the cards come out, but players not noticing the
action is on them. "Waiting for shuffling and players not realizing it's their
action is going to cost much more time than how quickly you spread the flop."
So I measured how obvious the acting seat is, and it was distinguished by a rim
colour and nothing else -- a gold border and a 2px ring where a live seat has a
green border and a 1px one. Same fill, same size, nothing moving. That is a subtle
thing to ask a dealer to spot across a table on a phone, for the one state the
whole pace of the game hangs on.
It reads as lit now rather than merely outlined: a solid gold ring at full
strength, a warm glow separating it from the felt, a warmer fill, and it sits
above its neighbours so the ring is never clipped by the seat next to it.
There's also a slow two-and-a-half second breath, which stops entirely under
prefers-reduced-motion -- the ring carries the whole job on its own for anyone who
would rather nothing moved, and that was checked rather than assumed.
The lift is box-shadow, not transform. A seat's transform is what positions it
around the felt, so setting one here would throw it off its spot -- the same trap
that nearly shipped a 38px seat displacement a few rounds ago.
One measurement I'm not claiming: the acting and live fills differ by only 1.1:1,
because the change is a hue shift rather than a lightness one. The ring and the
glow do the work; the fill just stops it looking like the same chip.
Checked at eight viewports: layout and contrast audits clean, exactly one acting
seat everywhere, and the lit seat is the same size as its neighbours at every
size -- the ring adds no layout. renderAll is 1.8ms with the pulse running, so it
costs nothing. Text on the warmer fill still passes contrast at every size.
137 tests passing.
Sources: pokerchipforum.com/threads/as-a-dealer-how-do-increase-more-hands-per-hour.114914/,
forumserver.twoplustwo.com/27/casino-amp-cardroom-poker/tips-advice-faster-better-dealer-241644/
Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb
jheaps
merged commit e5d5b515ba into master2026-09-01 09:31:52 -06:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Asked what actually slows a home game down, and the answer from people who deal them is consistent — not how fast the cards come out:
Stacked on #56.
The acting seat was distinguished by a rim colour and nothing else
Measured: a gold border and a 2px ring, where a live seat has a green border and a 1px one. Same fill, same size, nothing moving. That's a subtle thing to ask a dealer to spot across a table on a phone — for the one state the whole pace of the game hangs on.
It reads as lit now rather than merely outlined: a solid gold ring at full strength, a warm glow separating it from the felt, a warmer fill, and it sits above its neighbours so the ring is never clipped by the seat next to it.
There's also a slow 2.4s breath, which stops entirely under
prefers-reduced-motion— the ring carries the whole job on its own for anyone who'd rather nothing moved. Checked rather than assumed:animation: none, ring still at full strength.The lift is box-shadow, not transform
A seat's
transformis what positions it around the felt, so setting one here would throw it off its spot — the same trap that nearly shipped a 38px seat displacement in #44. Verified the transform is preserved at every size.One measurement I'm not claiming
The acting and live fills differ by only 1.1:1, because the change is a hue shift rather than a lightness one. The ring and the glow do the work; the fill just stops it looking like the same chip. Worth saying plainly rather than quoting a number that sounds better than it is.
Validation
Eight viewports: layout and contrast audits clean, exactly one acting seat everywhere, and the lit seat is the same size as its neighbours at every size — the ring adds no layout.
renderAllis 1.8ms with the pulse running, so it costs nothing. Text on the warmer fill still passes contrast everywhere. 137 unit tests passing, no console errors.One note: my first sweep flagged the acting seat's box as wrong at four sizes — that was my own hardcoded
76x72expectation, since seats are legitimately responsive (93x73 on tablet, 111x73 on desktop). Re-checked acting against non-acting at the same viewport, which is the comparison that means something.Sources: As a dealer, how do I increase hands per hour?, Tips and Advice to a Faster and Better Dealer
Ran out of things I could find by auditing the UI, so I went and read what people who run home games actually complain about. The recurring one isn't a dealing mistake, it's a banking one: "the last two guys go to cash out at the end of some all-night game and there isn't enough cash to cover the chips they have." Every chip on the table is a promise to pay cash for it later. Nothing in here checked that the promise could be kept, and there's no way to notice by eye — it's always a rebuy nobody wrote down, or chips taken without paying, and it stays silent until the box is empty and two people are still holding chips. The books now add up, or say why not HoldemState.bankReconciliation compares the cash taken in against every chip that could be handed back — stacks, chips in front of players, and the pot waiting to be won. The sidebar shows both numbers and what they mean: Balanced — the cash covers every chip on the table. $160 more in chips than cash taken. Someone's rebuy probably wasn't recorded — the box will be short at cash-out. $150 more cash than chips in play. Someone has paid for chips they haven't been given. Money in the middle counts as chips in play, so an open pot isn't reported as a shortfall — otherwise it would cry wolf during almost every hand. Players who had bought in were missing from the settle-up sessionStandings was built from the hand log, so anybody who hadn't yet been in a recorded hand didn't appear at all. Somebody hands over $200, sits down, folds a few, and the banker's own record doesn't mention them — then they turn up at cash-out holding chips the list never accounted for. Anyone with money in the game is in the list now, whether or not they've played a logged hand. The settle-up number was already being computed and hidden cashPosition — chips in front of them less the cash they handed over — was calculated for every player and written to the CSV, but never shown on screen. It's the number you read while counting out cash at the end of the night, so it's a column now. 15 tests (127 total): a buy-in with no hands played still appears and reads as level rather than a loss, empty chairs stay out, a player who cashed out shows what they took, both directions of imbalance are caught, an open pot is not a discrepancy, six played-and-settled hands never knock the books out, a proper rebuy balances while a chip grab doesn't, and float dust isn't an alarm. Validated with Playwright through real play — seated, blinds posted, pot open, hand settled, rebuy — balanced at every step, plus the three seeded verdicts and a fresh table where the panel stays hidden. Sources: pokerlistings.com/blog/how-to-run-a-home-poker-game, chipsoffury.com/learn/how-to-handle-poker-buy-ins-with-friends/ Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgbWent looking for more rules bugs and didn't find any — the blind rotation is fair over an orbit, nobody is double-charged or skipped when players come and go, and the big blind's option is handled correctly including heads-up and when the blind puts them all-in. Those probes are written up below. What I did find was a regression I shipped two rounds ago. The name column was zero pixels wide Adding the "Cash out" column in the bank-audit round made five columns. Four of them are numbers with a 4.5rem minimum, which with gaps needs 320px — and the sidebar is about 290px. The name column is the only flexible one, so it absorbed the shortfall and collapsed to nothing. Player names were not truncated, they were entirely invisible, and the row quietly overflowed. Measured at 360, 390, 1024, 1280 and 1600 alike, because the sidebar is narrow at all of them — this was not a phone problem, it was everywhere except the tablet layout where the sidebar goes full width. Names were already down to 50px with four columns, so this had been getting worse before I finished it off. The table earns its columns now instead of assuming them Narrow: player, net, cash out — the two numbers a banker settles up from. Wide enough: the per-hand In and Won as well. A container query rather than a viewport one, because the sidebar is 290px at both 360px and 1600px viewports and the thing that matters is the space the table actually has. Names get a real minimum and ellipsis rather than being crushed. Everything stays in the CSV either way. 360x640 name 0px -> 152px Player | Net | Cash out 390x844 name 0px -> 182px Player | Net | Cash out 768x1024 name -> 389px Player | In | Won | Net | Cash out 1280x900 name 0px -> 151px Player | Net | Cash out Rules probes that came back clean, so nothing changed: - blind rotation over 12 hands with 4 players: exactly 3 big blinds each - a player leaving and rejoining mid-session never causes a double or a skip - the big blind gets their option when everyone limps, can raise with it, and checking it ends the street - a big blind left all-in by the blind itself gets no phantom option - heads-up, the button acts first pre-flop and the big blind still has the option - post-flop the minimum bet falls back to the big blind Re-checked the guarantees from earlier rounds with the sidebar open: 0 of 50 controls on touch-action auto, 0 tap-highlighted, 0 occluded, stacks still inside their pucks, no sideways scroll, bank panel still fits and reads correctly. 137 tests still passing. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgbWeb search turned up the oversized-chip rule described as the single most common cause of floor disputes, and specifically a home-game problem. Chasing that led to checking what the bar does with an illegal raise, and the answer was: nothing. With the minimum at $18 and a player holding $200, typing 13 was accepted without a word. The engine then treated it as a short raise and correctly declined to reopen the betting -- right for an all-in, wrong for somebody who just misheard the bet, and either way the dealer was never told. The raise entry now says what's wrong and still lets it through. This tool records what the humans at the table actually did, and a dealer overruling the arithmetic is right more often than the arithmetic is, so Confirm stays enabled in every case: $13 is under the $18 minimum. A legal raise is $18 or more -- otherwise it's a call, or all-in. All-in for less than a full raise. Legal, but it doesn't reopen the betting -- anyone who has already acted owes the difference or folds. More than they have. This goes in as all-in for $200. $10 is not above the $10 already bet -- that's a call, not a raise. The second one surfaces the rule fixed two rounds ago at the moment it decides something, rather than only in the rulings sheet. Two minimums, which is where the first attempt went wrong The pad already had a minimum, clamped to what the player can actually put in -- correct for the Min button, wrong for the warnings. For a short stack the clamped minimum equals their all-in, so neither warning could ever fire for exactly the player the rule exists for. Kept separate now: one for the button, the rules one for the warnings. A regression the audit caught, in the same round that introduced it The note makes the raise pad taller, --actionBarHeight grows, and the toast -- which floats just above the bar since the occlusion round -- got pushed up over the table. Measured at 360x640: bar 122px closed, 178px with the pad, 217px with a note, and the toast climbing from y506 to y411, covering seats outright. A toast is transient news about the action just taken; the pad is the dealer deciding the next one. The older one gets out of the way when the pad opens -- nothing is lost, its Undo is also the bar's own undo control. The note is tighter on short screens, and the pot breakdown hides during entry, since which side pots exist isn't what's being read while typing an amount. Net: 210px rather than 217px, and no seat covered that the pad wasn't already covering at 178px. Two rulings entries, from the same search The oversized chip -- a single big chip pushed out silently is a call, not a raise, however big it is; to raise you say so before it lands. And what a full raise is, which the pad now enforces in words. 137 tests passing. Raise warnings verified across four amounts on a deep stack and three on a short one, at eight viewports: note shows, pad stays reachable, contrast clean, Confirm never disabled. Toast still behaves normally when the pad is closed. Sources: cardplayer.com/.../contracts-and-poker-the-oversized-chip-rule, pokernews.com/strategy/be-careful-when-betting-essential-wsop-rules-to-remember Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_015bnp7xKUPFFSpwkYNFaPgb