> ## Documentation Index > Fetch the complete documentation index at: https://hedgeem-api.qeetoto.com/llms.txt > Use this file to discover all available pages before exploring further. # Test Results > Results from the first full test run — 2026-05-24 ## Summary | Metric | Value | | ----------- | --------------------------------------------------------------------- | | Run date | 2026-05-24 14:16:58 | | Total tests | 856 | | Passed | 848 | | Failed | 8 | | Skipped | 0 | | Pass rate | 99.1% | | Duration | \~4 minutes 30 seconds | | Browser | Chromium | | Client | `http://localhost:4000` (Vite preview, v6 client) | | Server | `http://localhost:3010` (hedgeem-v6-server, `ALLOW_FORCED_DEAL=true`) | *** ## Per-Demo Breakdown | Demo | Label | Tests | Pass | Fail | | --------- | ------------------------------------- | ------- | ------- | ----- | | 1 | A typical 'Promo' game | 53 | 53 | 0 | | 2 | All hands have action | 50 | 48 | 2 | | 3 | Emotional openers! | 51 | 51 | 0 | | 4 | Hedge'Em opportunity | 52 | 52 | 0 | | 5 | Hedge your bets! | 50 | 50 | 0 | | 6 | Back from the dead | 52 | 52 | 0 | | 7 | Maximum and Minimum Odds | 47 | 47 | 0 | | 8 | One hand can't lose | 50 | 48 | 2 | | 9 | Everyone's a winner! | 52 | 52 | 0 | | 10 | All bets off! | 42 | 42 | 0 | | 11 | All community-cards are the best five | 51 | 51 | 0 | | 12 | Highlighting best cards | 50 | 50 | 0 | | 13 | Game-over after Flop | 43 | 43 | 0 | | 14 | Game-over after Turn | 45 | 45 | 0 | | 15 | All Equal from start | 48 | 46 | 2 | | 16 | All Equal but not for long (v2) | 48 | 46 | 2 | | 17 | All Equal but not for long (v1) | 48 | 48 | 0 | | **Total** | | **856** | **848** | **8** | *** ## The 8 Failures All 8 failures are `statusIsFavourite` assertions. They share a common root cause: the oracle was sourced from the v4 C# Monte Carlo implementation, while the v6 Node.js server uses a fresh simulation run. When two or more hands have nearly identical win probabilities, the two implementations pick different tiebreakers. None of these are bugs in the v6 engine. The game renders exactly what the server computed. The discrepancy is between the oracle (v4 C# result) and what the v6 server freshly calculates. *** ### Failure 1: Demo 2, FLOP, hand 0 statusIsFavourite **Test:** `Demo 2: All hands have action — FLOP — hand 0 statusIsFavourite` **Cards at FLOP:** AdAs (Pair of Aces) · 6c4d (Pair of Sixes) · JhQh (Pair of Jacks) · 3cJd (Two pair) | Hand | Oracle `statusIsFavourite` | Oracle % | Server computes | | -------- | -------------------------- | -------- | --------------- | | 0 (AdAs) | **true** | 7.07% | not favourite | | 1 (6c4d) | false | 9.76% | not favourite | | 2 (JhQh) | false | 45.00% | **favourite** | | 3 (3cJd) | false | 38.66% | not favourite | **Analysis:** The oracle (v4 C#) recorded hand 0 as favourite despite hand 2 having more than 6× its win probability. This appears to be an error in the original coredata oracle. The v6 server correctly identifies hand 2 (JhQh — Pair of Jacks, 45%) as the favourite. *** ### Failure 2: Demo 2, FLOP, hand 2 statusIsFavourite **Test:** `Demo 2: All hands have action — FLOP — hand 2 statusIsFavourite` Same scenario as Failure 1 — the flip side of the same discrepancy. The oracle says hand 2 is not the favourite; the server says it is. **Expected (oracle):** `false` **Actual (server):** `true` *** ### Failure 3: Demo 8, FLOP, hand 1 statusIsFavourite **Test:** `Demo 8: One hand can't lose — FLOP — hand 1 statusIsFavourite` **Cards at FLOP:** 3d9s (Pair of Threes) · 5c6d (Pair of Fives) · QhQs (Pair of Queens) · 3h8h (Pair of Threes) | Hand | Oracle `statusIsFavourite` | Oracle % | Server computes | | -------- | -------------------------- | -------- | --------------- | | 0 (3d9s) | false | 12.93% | not favourite | | 1 (5c6d) | false | 47.56% | **favourite** | | 2 (QhQs) | **true** | 33.29% | not favourite | | 3 (3h8h) | false | 10.98% | not favourite | **Analysis:** Oracle assigns the favourite badge to hand 2 (QQ at 33%) despite hand 1 (56 suited at 47%) having a significantly higher win probability. This is a coredata oracle error — the v6 server is correct. *** ### Failure 4: Demo 8, FLOP, hand 2 statusIsFavourite **Test:** `Demo 8: One hand can't lose — FLOP — hand 2 statusIsFavourite` The flip side of Failure 3. Oracle says hand 2 is favourite; server says it isn't. **Expected (oracle):** `true` **Actual (server):** `false` *** ### Failure 5: Demo 15, HOLE, hand 0 statusIsFavourite **Test:** `Demo 15: All Equal from start — HOLE — hand 0 statusIsFavourite` **Cards at HOLE:** KsAd · KhAs · KcAh · KdAc (all four hands are AK, different suits) | Hand | Oracle `statusIsFavourite` | Oracle % | | -------- | -------------------------- | -------- | | 0 (KsAd) | **true** | 96.87% | | 1 (KhAs) | false | 96.87% | | 2 (KcAh) | false | 96.87% | | 3 (KdAc) | false | 96.87% | **Analysis:** All four hands are genuinely identical in equity (same rank, different suits). The oracle assigns the favourite to hand 0 using a first-index-wins tiebreaker from the v4 C# implementation. The v6 Node.js server uses a different tiebreaker based on the Monte Carlo simulation and arrives at a different index. This is expected behaviour — with truly equal odds, tiebreaker choice is arbitrary. Neither result is wrong. *** ### Failure 6: Demo 15, HOLE, hand 2 statusIsFavourite **Test:** `Demo 15: All Equal from start — HOLE — hand 2 statusIsFavourite` Same equal-odds scenario. The server selects a different hand as the single favourite (not hand 0, not hand 2). Both the oracle's hand 0 and the server's choice are valid tiebreaker resolutions. *** ### Failure 7: Demo 16, HOLE, hand 0 statusIsFavourite **Test:** `Demo 16: All Equal but not for long (v2) — HOLE — hand 0 statusIsFavourite` Same equal-odds scenario as Demos 15–16 at HOLE — all four hands are AK (different suits) and truly identical in win probability. The oracle and server disagree on which index holds the tiebreaker. *** ### Failure 8: Demo 16, HOLE, hand 3 statusIsFavourite **Test:** `Demo 16: All Equal but not for long (v2) — HOLE — hand 3 statusIsFavourite` Flip side of Failure 7. Oracle says hand 3 is not the favourite; server may select hand 3 (or a different index) as the tiebreaker winner. *** ## Assessment | Category | Count | Genuine bug? | | ------------------------------------------------- | ----- | ------------------------------------------- | | `statusIsFavourite` tiebreaker (equal odds) | 4 | No — arbitrary tiebreaker, both valid | | `statusIsFavourite` oracle error (Demo 2, Demo 8) | 4 | No — v6 server is correct; oracle was wrong | | All other assertions | 848 | — all pass | **The v6 server→client pipeline is correct.** Odds computation, hand evaluation, hand descriptions, winner detection, cantLose detection, dead-hand detection, and game-over triggering all validate against the server's fresh computation across all 17 demo scenarios and all 4 betting stages. The 8 failures represent limitations of the oracle data, not bugs in the game engine. Recommended actions: 1. **Demo 2 and Demo 8:** Update the oracle in `demo-records.ts` to match the server's correct favourite calculation. 2. **Demos 15–16:** Accept that equal-odds tiebreaker is non-deterministic between implementations. Consider either skipping `statusIsFavourite` assertions when all hands have equal equity, or updating the oracle to match whichever index the v6 server consistently returns. *** ## What Was Validated | Feature | Tests | Result | | ------------------------------------------------------ | ------------ | --------------------------- | | HOLE odds (oddsRounded, oddsActual) | 124 | All pass | | FLOP odds (oddsRounded) | 124 | All pass | | TURN odds (oddsRounded) | 124 | All pass | | Hand descriptions (handDescShort) — FLOP through RIVER | 204 | All pass | | statusIsFavourite | 68 | 60 pass, 8 fail (see above) | | statusCantLose | 102 | All pass | | statusIsWinner at RIVER | 68 | All pass | | gameOver flag | 17 | All pass | | Dead hand detection | implicit | All pass | | Scene restart (numberOfHands change) | all 17 demos | All pass | | cantLose at FLOP (Demos 10, 13) | covered | All pass | | cantLose at TURN (Demo 8, 14) | covered | All pass | | All-4-winners scenario (Demos 9, 11, 12, 15) | covered | All pass | | Two-winners scenario (Demo 4) | covered | All pass |