JoshHeaps.Net/tests/holdem/README.md

Hold'em dealer tests

Unit tests for the money logic behind /Casino/TexasHoldem — the betting engine, the side-pot calculator, the split calculator and the table state.

node --test tests/holdem/*.test.js

No install step, no package.json, no dependencies. The browser modules are plain script-tag files that each end with a module.exports guard, so Node can require them as-is; load.js puts them on globalThis under the same names they use to find each other in the page, in the load order from TexasHoldem.cshtml.

What's covered

File	Covers
potCalculator.test.js	Main and side pots, dead money, uncalled bets, odd-cent distribution
betting.test.js	Blinds, street completion, raises reopening the action, all-in run-outs
state.test.js	Button rotation, which seats post blinds, session standings
splitCalculator.test.js	Chopped pots, odd chips, unmakeable denominations
handRank.test.js	What beats what: categories, the wheel, kickers, best five of seven
readingTheShowdown.test.js	The board, the picker that fills it, and who wins a side pot
theRail.test.js	A phone on its side: which shape the bar is in, what it leaves under the felt, how a name is shortened, how the ring is pulled back onto the table
feltShape.test.js	What shape the felt is at each phone size, resolved through the media queries in source order (see below)
potBreakdown.test.js	How each pot says who can win it, and the nesting property that wording rests on (see below)
sidebarPanels.test.js	What the sidebar's panels are called and what lives in each (see below)
chipLegend.test.js	Removing a chip colour, and whether the warning's number is the one the table loses (see below)
invariants.test.js	1000 randomised hands per property (see below)

The layout audit

The unit tests above cover the money. uiAudit.js covers the thing you can only see in a browser: whether a dealer can actually reach every control.

node tests/holdem/runUiAudit.js          # needs Playwright and the site running

It checks WCAG AA contrast, touch target sizes, touch-action and tap highlights, that fields stay selectable and are large enough not to trigger iOS zoom, that nothing important is covered or off-screen with no way to scroll to it, that no grid column has collapsed to nothing, that no text is painted outside its box, that no seat covers another seat's writing, and that no bet chip is hidden behind a seat or another chip. It runs over the table, the raise pad, all five overlays and Quick Split, at thirteen viewports from a 360px phone to a 1600px desktop and the same phones on their side — each viewport twice, once with a mouse and once with a thumb, and at three table shapes, mid-hand: the sweep posts blinds, deals and calls three times before it measures anything, so the bets layer has chips on it. It used to audit a table nobody had ever bet at, which is a third of what is on the felt during a hand left unlooked at.

The raise pad is newer than the rest and was worth every second it costs. It is part of the bar rather than an overlay, so nothing here had a step that opened it, and it is both the tallest thing the bar ever holds and the only place in the tool a dealer types an amount. The first sweep that opened it found a 36px-tall field on every phone in the list: the hover: none rule that sizes fields for a thumb names the settings panels and the seat form, and the one field on the one surface built for thumbs was not in the list. It also found the rail squeezing its own status line under the pad, which is the kind of thing that only happens in the state nobody was looking at.

"Covered" and "out of view" are told apart before anything is hit-tested. An element clipped away by a panel that scrolls is not covered by whatever happens to be painted at that height, and reporting it that way is a diagnosis of something that isn't happening: the pot wizard's third winner, below the fold in a list, came back for four viewports running as "fully covered by button Confirm Winner(s)".

Text is measured where it was painted, not where its box is. The two are different things and the difference is not academic: a name is centred, so its box is wider than its ink, and a name kept clear of the dealer's chip by a float is out of the way on the line beside the chip and full width on the line below. The check used to model that as "box minus padding", which is one way of keeping text out of somewhere and not the only one — it called every seat in the sweep an offender while the text sat exactly where it was meant to. Range rects ask the question directly, so padding, floats, centring, wrapping and a short label in a wide box all come out right without any of them being modelled.

Offenders say how much is covered rather than that something is. "Is under a badge" reads the same for a stack a dealer cannot read and for a badge's rounded corner grazing the last digit, and the difference decides whether it is worth fixing. Probing the whole line and counting turned the residual this sweep has carried for three rounds into "1/7 under SB" — one probe of seven, on one configuration, in a thumb context only.

More than one table shape is also newer than it sounds. The sweep ran on one — five players at a nine-handed table — for its whole life, and how much room the felt has depends on how many people are sitting down far more than on anything a viewport can report. A full table is where the seats crowd and it had never been looked at: the first sweep that did found one player's name or stack painted under another on eighteen of the configurations, on every phone in the list.

The third shape is the same five players with the board turned on and five cards on it. It is deliberately the same roster in the same chairs as the second, so the only thing that differs between the two rows is the board — a seventh player would have told us that a seven-handed table crowds, which is true, already known, and not what that row is there to find out. It earned its place immediately: the board takes the middle of the felt, or a strip above it where the middle is too small, and the strip costs the felt height. The seats follow a felt that changes size on their own, being placed in percentages of it; the chips anchored inside them do not, being placed in pixels. They were laid out for a felt 23px taller than the one they were painted on.

What the sweep taught the layout

For a long run of rounds the seat ring was predicted onto the table: work out the widest ring whose outermost puck still finishes inside the rail, place the seats, and trust it. The prediction is correct arithmetic and it was wrong on the page anyway, because every input to it moves after it is taken — the width search settles on a narrower puck, a name wraps to a second line or gets shortened out of one, the board appears in the middle. Each of those is up to 15px of puck height arriving after the answer. Ninety-six of the ninety-eight offenders this sweep could find were that.

So render.js now finishes the way the audit judges it. After the seats are placed it measures where they actually landed, and if the worst of them hangs 6px past the rail the ring comes in by 6px and they are placed again — the same question this file asks, asked by the code that has to get it right. Two passes, bounded, because each one is a forced layout of the whole felt and it runs after every tap a dealer makes.

That is the general shape of the lesson here: a layout that predicts itself has to be right about the future, and a layout that measures itself only has to be right about the present.

That last part, and two of those checks, are newer than this paragraph claiming them. runAll() did not include the contrast check at all, and touch targets sat behind an opt-in flag nothing passed, so "the audit is clean" meant nine checks rather than eleven for a long run of rounds. Both were written and tested and simply never called. The mouse/thumb pair matters for the same reason: the 44px rule stands itself down where hover: hover says there is a pointer, and a headless desktop browser is a pointer, so a single pass had never measured a touch target at any viewport. Between them they found a 9px seat label at 3.39:1, a 37px-tall amount field and a 30px delete button on Quick Split.

A check that decides it doesn't apply says so in the output rather than reporting no offenders, which reads identically to a pass. The same goes for the two exemptions that exist: a disabled control, which WCAG itself excuses, and a link inside a sentence, whose size is set by the line it sits in.

Deliberately not in CI: the unit suite is dependency-free and runs in about five seconds, while this one needs a browser and a running site. Run it after any change that adds or resizes a control. With no Playwright to hand, paste uiAudit.js into devtools and call LayoutAudit.runAll().

The contrast check is built so it cannot report a false positive: backgrounds composite through alpha, and 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. Two earlier attempts at this got it wrong in both directions — one read only background-color and scored text on a gradient against nothing, the other treated low-alpha stops as opaque — so uiAudit.js is checked against known-answer cases before it is believed.

Touch targets are measured by probing outward with elementFromPoint rather than by reading the element box, because the box lies in both directions: a small control can be padded out with a transparent ::after and respond well beyond its painted size, and a checkbox inside a label is hit by tapping the label. The 44px rule is only enforced where hover: none says there's no mouse.

It exists because these checks were being re-typed into a console every time something changed, and each time they only covered whatever had just been touched. That is how the standings table shipped with a player-name column zero pixels wide and kept it for two rounds.

Which rule wins

feltShape.test.js is here because of a change that measured as correct and was a no-op. The felt on a phone was made an upright oval by setting --feltAspect inside @media (max-width: 700px), and forty lines below it @media (max-width: 900px) set the same property back to 1. Both queries match a phone, the declarations have the same specificity, and the later one wins — so the property was 1 on every phone on the site while the rule that was supposed to change it sat there reading perfectly.

Nothing in the suite could have caught it and nothing in review did. A stylesheet is not a list of rules for viewports; it is a list of rules in an order, and the question "what does a 390px phone get?" has an answer that no single rule knows. So the test walks the media queries the way the cascade does — every declaration of a property on a selector, in source order, keeping the last one whose query matches — and asks what each of five real phone sizes actually ends up with. It carries just enough of a media-query engine for the forms this stylesheet uses, and refuses loudly rather than guessing when it meets one it doesn't know.

The same file records a second thing, which is a floor that was added and removed. The max-height that keeps the felt above the action bar has no lower bound, so a tall enough bar presses the table flat; flooring it at the desktop oval looked obviously right. Measured, it was worse: twelve players all in with nine side pots takes the bar to 341px, which at 360x640 leaves 142px of room, and a felt floored to 242px keeps its shape by putting five of the twelve seats behind the bar. Unfloored it is flat and all twelve are visible. The slit the floor defended against turned out to be unreachable — it came from forcing the custom property by hand. A test now asserts the floor is absent, with the numbers, so it doesn't get re-added by someone reasoning the same way.

A property the wording depends on

potBreakdown.test.js covers how the pot breakdown says who can win each pot, and it leans on something potCalculator.test.js now proves: pot eligibility is nested. The main pot is everyone still live, and each side pot above it drops whoever was all-in below, so every side pot's players are a strict subset of the pot beneath it.

That makes "who is in" and "who is out" complements, which is what lets the line name whichever of the two is shorter and never spell out more than half the table. Listing every eligible player instead meant the main pot's line was every name at the table and each side pot repeated it minus one — and the lines too long to fit were exactly the ones nobody needed, while the short ones at the bottom were the side pots a dealer actually announces by name.

The nesting check runs 20,000 random tables, and it asserts on its own generator as well as on the code: if a change to the shapes stopped producing side pots, every assertion in the loop would be vacuous and the test would still pass, so it also requires that more than ten thousand of those tables had one.

Writing that check is where a comparison against Set.length went in — a Set has .size, so here.length < below.length was 2 < undefined, which is false. As an assertion it failed everything; as a filter in a throwaway script it had passed everything, which is how it survived long enough to be written down. Both readings are silent. Prefer asserting the count you expect over comparing two things whose shapes you have not checked.

Testing a fault that broke nothing

sidebarPanels.test.js reads TexasHoldem.cshtml rather than any JavaScript, because the fault it covers was not a bug. Every control worked and every id resolved. What was wrong was which panel a thing was in and what that panel was called.

The sidebar was Table Setup, Session, Chip Legend, Keyboard and Table Notes, and Session held the standings, a waiting list, the hand log and the save/load/reset buttons — a topic, a task, a log and three utilities under one word. It measured 1206px and 103 visible elements against 555 and 29 for the next biggest, and "The table itself" sat 1052px down inside it, so reaching Reset table meant opening a panel called Session and scrolling past the money and the log to find it.

Three things are asserted, and each of them is a claim a future edit could quietly undo:

• The names say what is inside them. The list is checked literally, because the failure mode is a word like "Session" that could hold anything.
• Each name is a heading. A <summary> is announced as a button, so the sidebar's names — its whole navigation — were not reachable by heading. Splitting Session also removed the four subheads that had been the only headings down there, so without a heading in each summary the page would have come out of this with a worse outline than it went in with.
• No panel goes back to being a grab-bag. Not a size limit — Table Setup is legitimately long. It counts subjects: a panel that needs its own headings to list its parts is holding more than one thing. Two subheads survive, and the test names them, because Settle up is the standings at the end of the night and Stacks in chips is the chip legend counted out — the same subject at a different moment, which is what a subhead is for.

The panels are split on the opening tag rather than parsed, which is sound only because a sidebar panel never contains another one; Table Setup's sub-panels carry a different class. That assumption is worth knowing about if one ever does.

A warning is only worth having if its number is right

chipLegend.test.js covers removing a chip colour, which was one click of an unlabelled 24px button and was never a change to a legend. computeContribution() prices a seat by running the legend over that seat's chip counts, so a colour that leaves takes every chip counted in it off the table. Measured in a browser on a three-handed table: deleting the $500 row took $22,500 of $26,874 with it, with no confirmation, nothing said afterwards, and no way back — a colour added again is a new colour with a new id, while the counts stay keyed to the one that left.

Most of the file is about the number in the warning rather than the removal, because a warning that overstates is worse than none. The obvious way to work it out — chips times value — is wrong in both directions:

• a seat with a typed amount is priced from that and its counts are never read, so a colour it holds is worth nothing to it;
• a seat whose chips all leave falls through to the table's standing ante rather than to zero, so it loses less than its chips were worth.

So the figure is the difference between pricing every seat with the colour and without it, and a randomised check across 2,000 tables asserts that what the warning claims is exactly what the table then does. That check found a third case nobody would have written by hand: fourteen $1 chips against a $200 ante, where removing the colour puts the table up $186. The wording says so in that direction too.

The friction is conditional on purpose. A colour nobody has counted deletes on one click; only one that is holding money asks. A confirmation that fires every time is one nobody reads by the third night, and this is a tool where four other confirmations already compete for that attention.

Every control says what it is

uiAudit.js gained controlNames(), which is the general form of the bug above: the × had no accessible name, so it was announced as a button and nothing else — five of them in a column, identical, each deleting a different colour.

It treats a symbol as no name even though × is technically text. The rule is that a name has to contain a letter or a digit, which is the difference between "×" and "Undo". Names are resolved the way the accessibility tree does it — aria-label, then aria-labelledby, then a field's wrapping or pointing <label>, then placeholder, then text content, then an image's alt, then title — and anything under aria-hidden is skipped rather than judged, since it is not in the tree to begin with.

Removing the one aria-label this round added makes it report all five buttons, which is how it was checked.

Where the keyboard lands

Two checks in uiAudit.js cover WCAG 2.2 SC 2.4.11, which says a focused control must not be completely hidden by something the page has put on top of it. Tabbing the whole page on a 390x844 phone found 16 stops resting completely covered and 27 more partly, under the action bar; on the desktop, four more under a toast.

They are checked as the fix rather than as the symptom, because the symptom needs a keyboard and this file has no automation of its own:

• focusHasRoom() — scroll-padding-bottom on the scroll container has to reserve at least as much room as the fixed furniture standing at the bottom of the window. Only furniture crossing the middle of the screen counts, or the rail a landscape phone puts down the right-hand side would demand scroll padding the height of the whole window; and sticky elements inside a panel that scrolls on its own are excluded, because scroll-padding on the document would do nothing about them.
• focusablesReachable() — nothing focusable may sit entirely outside the viewport inside a position: fixed subtree, since scrolling can never bring it back. The seat editor's bottom sheet was put away with transform: translateY(105%), which moves a thing without putting it away: its Done button sat at y=850 on an 844px screen, still in the tab order and still on the accessibility tree. visibility: hidden puts it away.

Half a fix looks exactly like a whole one

scroll-padding-bottom alone was written up as the answer and it is only half of it. It applies when the browser has to scroll to reach the control at all; a control the browser already considers visible is one it will not scroll to, and a fixed overlay on top of it does not enter into that decision. Measured: tabbing to Common rulings with a toast up left it 100% covered, and scrollIntoView({block: "nearest"}) moved nothing, because "nearest" was already satisfied. The sweep had shown clean only because 89 tab presses outlast an eight-second toast.

So the other half is a focusin handler that measures the overlap and scrolls by it — and, when the page has no room left to scroll (26px available against 94px wanted, at 1280x900), dismisses the toast instead. Sizing the page's bottom padding for the toast as well would have fixed it by making the page grow and shrink by 64px every time anything was announced, which is worse than the fault.

A sweep only measures the states it reaches

The action bar is fixed over the felt, so its height is the felt's budget — and the bar carries the side-pot breakdown, which drew one row per all-in with no ceiling. Measured on a 360x640 phone: five players idle put the bar at 151px, six all-in at 303px, and twelve all-in at 411px — 64% of the screen, leaving 96px of felt to draw twelve seats in.

Nothing here could see it, and the reason is worth writing down. Every check in uiAudit.js asks whether some element is covered, clipped or unreachable; not one asked how much room the covering element had taken. But the deeper miss was the sweep itself: all 294 audits drove their table with Call and Check, so no table in the history of this file ever had a player all-in, and the one thing on the bar whose height depends on the table was empty in every single measurement. runUiAudit.js now has a fourth shape, twelve players shoved in for twelve different amounts — there is no one-tap shove, so it takes the raise pad's All-in preset and confirms, or Call all-in for anyone who cannot cover.

• furnitureBudget() — the fixed bottom band, measured against the window. Failing above 50%, which is the line that needs no taste to defend: furniture larger than the content it serves is a shape fault whatever it is showing. Warning above 30%, the published guidance for persistent chrome, which the shortest phone does not meet at rest — the bar is 151px of a 640px screen before anything happens — and a sweep that is always red stops being read.

Cutting the middle out of a list, and which end to keep

The cap is four layers, and past it the bar draws the main pot, one line for everything between, and the newest side pot. The two ends are not an arbitrary choice: side pots are paid from the newest one back down to the main pot, so the top layer is the next thing that happens and the main pot is the last, and those are exactly the two a live dealer says out loud while the chips are being stacked — "main pot 7,200, side pot 4,500". The layers between are the middle of that count-down, wanted at showdown, which is the pot wizard — the same builder, passing no cap, in a dialog that scrolls.

potBreakdownRoom.test.js checks the parts that could go wrong quietly:

• the row count is a function of the cap, not of the table — eight, nine, ten, eleven and twelve all-in all draw three lines
• the drawn amounts still add up to every pot, so a dealer counting the announcement against the chips in the middle finds no shortfall the tool caused
• the elision sits where the gap is, not appended after the list, so the amounts still read in the order the pots were made
• it never fires when it would not buy anything: at exactly the cap the middle is one row, and swapping one row for one row loses an amount and gains a sentence

Three injected faults — the cap ignored, the summary carrying only the first elided pot's money, the elision appended rather than kept in place — fail 6, 1 and 5 of the 11 tests respectively, and the audit check reports the original 64% when the cap is taken out.

Two empty rows were setting how far apart twelve seats had to sit

Every seat puck carries four rows: the name, the hole cards, the amount that player has put in, and their stack. Two of those are empty most of the time, and both held their space anyway.

The amount pill was worse than empty space. It has a background, a pill radius and side padding, so with no text it painted an 8x11px green lozenge — measured on seven of nine seats at an ordinary table. One of those is a component holding its place; nine is a rash, and a dealer has to learn to ignore a colour that on the other two seats means "this player has money out".

The space was not free either. seatRingRadii sizes the ring from the tallest puck on it, so two rows nobody had filled were setting the spacing for the whole table:

	before	after
iPhone 14, 9 seats	78x88 puck	78x63
iPhone 14, 12 seats	44x65	66x55
Pro Max, 9 seats	84x88	96x63
Galaxy S8, 12 seats	8 overlapping pairs, 1556px²	4 pairs, 87px²

• emptyDecoration() — nothing inside #pokerTableWrap may paint a background or a border with no content in it. The rule is about paint, not space: an element may hold its place invisibly, and several do. With the old reservation restored it reports all seven pills; live it reports none.

The one exemption, .betChipDisc, is on the list because the check reported it, not because it was predicted — it is a 13x13px circle filled with the denomination colour of the chip beside it, so the colour is the content. Three other exemptions were written from memory first and matched no element on the page at all, which is the argument for building that list from a run.

The collapse is only safe because the cache key moved

resolveSeatLayout measures ten candidate widths, each one a forced layout, and caches the result against seatShapeSignature(). That signature listed the names and the dealer seat — everything that could wrap a name onto a second line. It did not mention the two rows, because they always held their space and so could never change a puck's height.

Once they collapse, they can. seatPuckShape.test.js checks the key moves when the first chips go in and when a hole card is entered, and — just as important — that it does not move for the second player to bet, or when an amount merely gets wider. It is a boolean over the whole table because that is what the measurement is: measuredSeatBox takes the tallest puck on the ring, so what matters is whether anybody has one. A per-seat key would be correct and would throw away the cache on every single tap.

Measured on the running page: the ring settles by 24-26px when the blinds are posted — and it settled by 23-25px there before this round too, because the action bar changes height at that moment and the felt is measured against it. The one place the ring moves is a place it already moved.

A test that passed for the wrong reason

The signature joins names on a control character so that "ann" + "abel" and "anna" + "bel" stay distinguishable. The first version of that test used Ann/Abel against Anna/Bel — which can never collide whatever the separator, because the capitals land in different places. It passed with the separator deleted and proved nothing. Lower case is what makes it a test. Four faults were injected in total; the other three (dropping the two flags, letting the count into the key instead of a boolean, and counting only hand bets so a table playing antes is missed) fail 3, 2 and 1 of the eight.

Room the felt had and the type never got

The felt grows with the window and the pucks did not — 96px was the only ceiling there was. Nine-handed, the seats covered 19% of the felt on a phone, 11% on a 1280px desktop and 8% at 1440px and beyond, with the stack figure a dealer reads at 10px on a 2560px monitor, the same 10px as on a 360px phone.

Two things stop the fix costing more than it buys, and seatWidthSearch.test.js checks both:

• Every candidate width is a forced layout. Raising the ceiling for everybody took the layout pass from 24ms to 73ms twelve-handed on a desktop. A screen that cannot use the wider widths must not measure them, so a phone is checked to measure exactly the ten widths it measured before — same list, same order — and the measured cost on a phone is unchanged (10.7ms against 10.4ms, which is noise).
• A wide puck on a narrow felt is worse than a small one. The first version let phones through, and a 144px puck on an iPhone's 278px ring is half the width of the table: six-handed, all six seats sat over the rail by 15px against 5px before, and it read as a stack of cards rather than a table with people around it.

So the ceiling is a fifth of the felt's shorter span, capped at 144. Five is measured, not chosen: the shorter span is 233-303px on every phone in the sweep including sideways, and 617-714px on tablets and desktops, so any divisor between 3.2 and 6.4 separates them. The test pins both ends, so if the felt ever changes shape enough to bring those together it says so rather than letting the phones quietly start paying.

Above the ordinary ceiling the puck also takes the larger type — .seatsRoomy, two steps up the scale for the two numbers read across the table and one for the chair number. Steps rather than a clamp(), for the same reason the tight set is: the width is a continuum and the type is a set of deliberate sizes.

nine-handed	before	after
iPad puck / name	96px / 12px	134px / 15px
desktop 1440 puck / name	96px / 12px	140px / 15px
seats as a share of the felt, 1440	8%	12%
every phone, every seat count	unchanged	unchanged

What the rail check is actually measuring, which is not the rail

Found while checking the above and not fixed — written down here because the number is worth having and the fix is not a small one.

#pokerTable is border-radius: 50%. Both the settle pass in render.js and seatsOnTheTable() in the audit compare a puck against the four edges of the table's bounding box, which is a different and much slacker question than the one the message "hangs Npx past the rail" claims to answer: at the top and bottom of the ring the oval curves away from its own box, so a puck can be comfortably inside the box and visibly outside the felt.

Measured against the ellipse instead — a point is outside when (dx/a)² + (dy/b)² > 1, and the ray from the centre crosses the boundary at 1/√t of the way out — across 35 configurations the check is seeing 303px of overhang as zero, including 46px on a phone held sideways that has been there for as long as the check has.

Settling against the ellipse was tried and reverted, because it is not the local fix it looks like. Pulling the ring in far enough to clear the oval crowds the seats, and on a twelve-handed phone with everybody all-in it put seat 3's centre inside seat 4 — the one trade the width search explicitly refuses to make, since a dealer can see a puck over the rail but cannot see a tap answering for the wrong player. Guarding against that instead leaves the ring out and the overhang worse: the sweep went from 6 failing configurations to 77, with 355 rail reports.

Which is the finding. On a crowded table keeping the seats off the rail and keeping them off each other are in genuine conflict, and resolving it needs the two settled together rather than one bolted onto the other.

And then measured again, and dropped

Re-probed across 40 configurations — four table shapes at ten viewports — the gap is real and systematic: 31 of 40 sit further past the oval than the box says, worst 34px against a box overhang of 0 everywhere. The 303px above was the all-in shape, which is the extreme rather than the case.

Then it was looked at rather than measured, and 12–17px of a rounded puck's corner crossing the rail reads as players at a rail — which is what the thing is a picture of. The measurement gap is worth writing down and the appearance is not worth a round, so the lead is closed rather than carried forward. Worth the re-measure to find that out: the number that made it look urgent was the worst cell in the table, not a typical one.

Eight rows that said only their own names

The sidebar is eight <details>, and every one measured exactly 60px shut with nothing on it but its label — 480px of a phone's screen, and 480px of a 660px desktop column, spent saying "Standings", "Hands", "Waiting list". Whether the box balances, whether anyone is waiting for a seat, how many hands have been played: the page had all three worked out already, and charged a tap for each of them, on rows two thirds of which were empty.

That is the disclosure pattern's named failure — a header you have to open to find out whether it was worth opening — and the answer the design systems give is the same one: put the status on the header. So each shut panel now carries the one fact you would have opened it for, and the panel keeps the sentence. "Off by $300" is the alarm; which seat is holding chips nobody wrote down is a paragraph, and that is the half that belongs behind the tap.

Two rules hold it together, and panelGlance.test.js checks both.

A glance appears only when it has something a dealer would act on. Eight rows that always say something are eight rows that say nothing again, and a row reading "Nobody waiting" all night is the clutter this went in to remove. So no waiting list, no notes and no hands yet are all silence, and the bank check stays quiet over a table nobody has bought into — which is what the panel does with its own check, for the same reason.

A glance never says something the panel under it would contradict. It is read off the same state, never off the panel's DOM — a shut <details> has no rendered body to read — and one test walks three buy-in figures asserting the glance's colour agrees with bankReconciliation's verdict and its number carries the same difference.

The layout half is glancesFitTheirRows in the audit, and it took three goes.

The first version asked only whether a row had grown taller than a row with nothing on it, which sounds like the whole question and is not: a glance floated back into flow and allowed to wrap sailed straight through it, because a float does not expand the box it sits in — two lines of note hung out of a row that still measured exactly 44px. Asking where the glance actually ended up, in both axes, is the question that has an answer.

The second version was wrong in the other direction, and the sweep caught it on its first clean run: 94 failing configurations, 91 of the offenders this check's own. It takes the shortest row in the sidebar as its idea of a bare one, and the Keyboard panel is display: none under pointer: coarse — a touch device has no keys to press — so on every viewport visited with a thumb the bar was a row that wasn't drawn at all, 0px, and all seven real rows read as grown. Seven rows times thirteen viewports is exactly the 91. Rows that aren't rendered aren't rows.

Which is the point of running the sweep against a check as well as against the page. A narrowing fix has to be shown not to have blinded the thing it quietened, so the four broken versions are re-run with the Keyboard panel hidden — the condition that was breaking it — and each is still caught, while the unbroken page stays clean.

Why the hand evaluator is tested the way it is

handRank.js is the only module here that can pay the wrong person without anybody noticing. A pot wizard that asks "who won?" is never more wrong than the dealer ticking the box; one that answers the question itself is wrong on its own account, silently, and a table that has come to trust it will not check.

So besides the hand-written cases — every category against every other, the wheel, three kickers deep, the counterfeited two pair, the board that plays — it is checked against a second evaluator written a different way, on twenty thousand random seven-card hands and four thousand random pairs of them. The second one is in the test file and shares no helper with the module: it scores a hand by counting ranks into a sortable list rather than by asking about shapes. That pass is most of the suite's running time and it is worth it; three deliberately introduced bugs — an ace that keeps its value in the wheel, a dropped two-pair kicker, a flush read only by its top card — are each caught by it as well as by the cases written for them.

Why the randomised suite exists

Every correctness bug found in this tool so far has been shape-dependent: blinds posted to empty chairs, the button skipping past players, heads-up acting out of order, an overbet announced as a side pot. None of them show up on a full six-handed table with equal stacks, which is the table anyone writes a fixed example for.

invariants.test.js deals a thousand hands across random seat counts, random empty chairs, random stack depths and random dealer input, and checks the things a dealer would notice being wrong:

• chips are never created or destroyed during play
• the pot breakdown plus the uncalled returns always equal the money that went in
• paying the pot out settles it to the cent
• once uncalled chips are handed back, nobody is still betting above the whole table
• the button and both blinds always land on players who are actually in the hand

The generator is seeded, so a failure reproduces from the seed printed in the message rather than being a flake to re-run.