📔 Context

The production build consumed over 80% of vertical viewport space with 5 players. Player seat positions were hardcoded, not adaptive. Adding seats was physically impossible without redesigning the entire spatial system.

🚨 Problem

• Viewport saturation at 5 players: board, pot, and player cards left no room for additional seats
• Player distribution logic was static — no proportional scaling as player count increased
• Betting controls partially below the fold on standard mobile viewports, requiring scroll during active gameplay
• No safe area compliance on modern device form factors

💊 Solution

• Defined a responsive layout grid with explicit anchor zones: table zone, hero zone, action zone, board zone
• Seat positions designed as adaptive — repositioning and resizing proportionally from 3 to 9 players
• Action zone (fold/call/raise + bet slider) locked permanently above the fold on iPhone 6 (375×667), iPhone 13 (375×812), and iPhone 16 (393×852) — the three constraint baselines that cover the full iOS market range
• All zones validated in worst-case simultaneous-load conditions: every player active, bets visible, board full, modal open
• Built a Mobile Integration Stress Test frame: the widget embedded inside the actual Odds Data mobile page template (header, navigation, live score widgets sidebar, related widgets, footer) — proving the plugin works in its real deployment context, not just in isolation

🔴 VISUAL ASSET NEEDED — Screenshot: side-by-side OLD build (dev version, 5 players max) vs. NEW redesigned version (9 players). Shows the scope of the architectural failure at a glance. Source: Scenarios page, Pre-Flop OLD vs NEW frames.

🔴 VISUAL ASSET NEEDED — Screenshot: Mobile Integration Stress Test showing the poker widget embedded inside the Odds Data mobile page template with header, nav, content, footer. Source: Image 2 (Integration & Stress Test mobile frame).

📔 Context

This was the most critical finding. A simulator that teaches incorrect poker rules is not a neutral product — it actively damages user trust and brand credibility. Several interaction states shipped in the existing build represented impossible or illegal game situations.

🚨 Problem

• Players shown as able to "Check" when a live bet was already in play — an illegal action in poker
• Raise logic inconsistent: minimum raise amounts not enforced, re-raise sizing not respected
• Acting order did not follow standard poker seat conventions
• Fold/Call/Raise button states active in contradictory combinations
• No distinction between blind posting states and active betting states

💊 Solution

• Mapped every game state against Texas Hold'em rules: pre-flop, flop, turn, river, showdown
• Defined explicit action availability rules per state: which buttons are active, which are disabled, and why
• Flagged all production errors formally to the PM with documentation — each error described as a user-facing credibility risk, not just a design issue
• Designed interaction states that enforce correct poker logic: Check only available when no live bet exists, Raise sizing respects minimum raise rules, acting order follows seat position conventions
• Built a complete scenario strip (Pre-flop → Flop → Turn → River → Result) to validate that every component has a defined placement rule at every game stage

📔 Context

The dev team had built the original product without looking at a single real poker application. No benchmarking, no competitive analysis, no reference to industry conventions. Every design decision had been made in a vacuum. Before proposing solutions, I needed to establish what "correct" looked like — not from personal opinion, but from documented evidence across the market leaders.

🚨 Problem

• Zero competitive references in the existing project — no awareness of industry conventions
• PM and dev team had no framework for evaluating whether a design decision was standard or arbitrary
• Without benchmarking evidence, every design recommendation would be perceived as subjective preference rather than domain-informed necessity

💊 Solution

• Conducted a structured competitive audit across 4 market leaders, on both mobile and desktop: GG Poker, PokerStars, 888 Poker, and Unibet Poker — capturing multiple game states from each product
• Mobile audit (16+ screens captured): documented seat positioning logic across 6, 8, and 9 player configurations; action button placement patterns (bottom-anchored across all competitors); raise slider orientation (vertical in all native apps — confirming the horizontal pivot was a novel solution specific to the embedded web context); card sizing and legibility at compressed scales; hero position conventions; pot display patterns
• Desktop audit (10+ screens captured): documented how each competitor leverages landscape orientation; seat distribution around elliptical tables; action zone positioning; typography scaling from mobile to desktop; player module sizing differences
• Key findings extracted per competitor: GG Poker — most aggressive use of avatar/animation, largest action buttons, clearest pot display hierarchy; PokerStars — cleanest information architecture, most consistent seat scaling across player counts, strongest card legibility at small sizes; 888 Poker — distinctive visual identity (checkered blue theme), most explicit bet labelling with chip amounts in front of each player; Unibet Poker — most minimalist table design, clearest fold/call/raise colour coding (red/yellow/green), best use of space in multi-table desktop view
• Compiled both audits as dedicated Figma reference pages (Mobile Ref / Desktop Ref) — available as persistent artifacts for the PM and dev team to reference during implementation, not just design phase
• Every subsequent design decision in Missions 2–5 was backed by at least one benchmark reference — seat positioning validated against PokerStars and GG Poker conventions, pot display logic cross-referenced with 888 Poker's explicit chip-in-front-of-player pattern, action button sizing and colour coding informed by Unibet's red/yellow/green system

🔴 VISUAL ASSET NEEDED — Screenshot: Mobile Ref + Desktop Ref Figma pages showing the 4 competitors side by side (GG Poker, PokerStars, 888 Poker, Unibet). Proves the audit was systematic, not casual. Source: Mobile_Ref.pdf / Desktop_Ref.pdf or screenshot of Figma reference pages.

📔 Context

Poker table layouts follow established industry conventions for seat positioning — conventions that exist because they reflect how real poker tables work and how players mentally model the game. Deviating from these conventions creates cognitive friction. The existing build had no awareness of these conventions.

🚨 Problem

• No seat positioning logic: seats were placed arbitrarily with no reference to industry standards
• No scaling system: each player count would have required a completely manual redesign
• Hero position ("You") was centered, creating visual conflict with the betting controls on the right side of the screen

💊 Solution

• Benchmarked seat positioning against GG Poker, PokerStars, 888poker, Unibet, and BetRivers — extracting the common conventions for 3, 6, 8, and 9 player configurations
• Hero intentionally positioned left of center: respects thumb reach zones, separates player cards from the raise slider and action buttons, reduces mis-tap risk during fast decisions
• All seat positions defined as anchored, adaptive zones — repositioning proportionally as player count increases
• Built dedicated frames for each configuration showing zero overlap, zero clipping at maximum density

🔴 VISUAL ASSET NEEDED — Screenshot: Mobile/Template Master Game showing 3, 6, 8, 9 seat configurations stacked vertically. Shows the scaling system at a glance. Source: Image 6 from mobile Figma overview (Mobile/Template Master Game section).

📔 Context

The existing build had no coherent component system. Elements were one-off, inconsistently sized, and used visual metaphors that bore no relationship to real poker products — betting tokens looked like generic UI chips, cards collapsed visually at small sizes, player states had no clear hierarchy.

🚨 Problem

• Cards illegible at small viewport sizes: suit symbols too similar (clubs/spades confusion), rank hierarchy unclear
• Betting tokens using generic UI metaphors instead of poker-standard chip representations
• Player module states undefined: no visual distinction between active, folded, acting, and waiting states
• Yellow table borders created visual noise that competed with the core gameplay zone
• No modal system for hand results and next-hand transitions

💊 Solution

• Redesigned card system: higher-contrast suit symbols, clearer rank/suit hierarchy, legible at compressed board scale (8–9 player worst-case)
• Betting tokens redesigned to match standard poker chip metaphors used across the industry
• Player modules built with all states defined: default, active (acting), folded, all-in, winner
• Yellow borders removed: visual hierarchy rebuilt around the green felt zone as the primary focal anchor
• Full modal system designed: hand result overlay, next hand transition, pot distribution display
• All components placed in a single Figma section with explicit usage rules and dependency documentation for engineering

🔴 VISUAL ASSET NEEDED — Screenshot: Components section overview from Figma showing Cards (full 52-card deck grid), Player modules, Bet Button states, Cursor system, Table component. Proves design system depth. Source: Image 6 right side (Components section).

📔 Context

This was one of the most technically specific problems in the project, and it only becomes visible when you understand the deployment context. Native poker apps use vertical raise sliders — moving finger upward increases the raise amount. This is the industry standard. But this plugin is embedded inside a web article. Vertical swipe gestures on a scrollable page trigger page scroll, not slider movement. The standard pattern breaks completely in this context.

🚨 Problem

• Vertical raise slider conflicts with native browser scroll behavior on mobile
• User attempting to raise triggers page scroll instead — a critical interaction failure during gameplay
• No existing poker product had solved this in an embedded web context: all competitive references were native apps with full scroll ownership

💊 Solution

• Pivoted the raise slider from vertical to horizontal orientation
• Horizontal swipe does not conflict with vertical page scroll — the browser correctly interprets the gesture direction
• Validated the pattern against thumb ergonomics: left-to-right raise input maps naturally to "more" directional logic
• Documented the rationale explicitly in Figma annotations for the dev team — preventing regression to vertical orientation during implementation

📔 Context

The desktop version could not be designed as a scaled-up mobile layout. The plugin embeds inside Odds Data article pages — a two-column layout with a sidebar (live score widgets, related widgets). The simulator occupies the main content column at a default width of 1900px. The dev team's previous attempt had simply stretched the mobile layout horizontally, wasting screen real estate and breaking spatial relationships between players.

🚨 Problem

• Existing desktop build was a stretched mobile layout — no adaptation to the wider viewport or the page context it lived in
• Seat distribution designed for portrait orientation did not translate to landscape — player positions overlapped or floated in empty space
• No integration stress test: the widget had never been validated inside the actual Odds Data page template with its navigation, sidebar, and footer
• Hand Results modal designed for mobile only — no consideration for how a 9-player result table would render on desktop without scrolling

💊 Solution

• Designed the desktop version from scratch using the Odds Data page template as the real integration context — not in isolation. Built an explicit Old vs. New comparison frame at 1900w showing the widget embedded in its actual deployment environment with navigation, sidebar, and footer visible

🔴 VISUAL ASSET NEEDED — Screenshot: Desktop Old vs. New comparison at 1900w inside Odds Data page template. Shows the widget in its real deployment context with nav, sidebar, footer. Source: Image 1 from desktop Figma screenshots (Integration & Stress Test, Old vs New).

• Built a Desktop Template Master Game frame validating all 4 seat configurations (3, 6, 8, 9 players) at desktop scale — each annotated as a layout stress test for the dev team: "This screen is a layout stress test demonstrating table configurations for 3, 6, 8, and 9 players. Its purpose is to validate seat distribution, spacing, and overall layout consistency across all supported player counts."

🔴 VISUAL ASSET NEEDED — Screenshot: Desktop Template Master Game showing 3/6/8/9 seat configurations with the "Development" annotation callout visible. Source: Image 4 from earlier desktop Figma screenshots (Desktop/Template Master Game).

• Designed a complete desktop scenario strip: Pre-Flop (4 states), Flop (2 states), Turn (1 state), River (1 state), Hand Result (4 states) — mirroring the mobile game state architecture 1:1, ensuring cross-platform behavioural parity
• Solved the Hand Results modal responsive layout: up to 7 players renders as a single-column player list; 8+ players switches to a two-column layout — preventing modal overflow and keeping all content visible on screen without scrolling. Row states defined for desktop: default (neutral), user (highlighted), winner (gold) — with hover state that previews player details, and click that selects and expands
• Desktop action zone repositioned: bet slider and action buttons moved to the right side of the hero zone, taking advantage of horizontal space. Cursor buttons (+/−) retain hover states specific to desktop (not present on mobile)

📔 Context

The PM's initial brief was explicitly "adjust the screens a bit." Accepting this framing would have meant delivering a cosmetic fix on a structurally broken product — which would have shipped, failed, and reflected on everyone involved.

🚨 Problem

• PM expected minor visual adjustments, not a full rebuild
• Dev team had already invested time in the existing build — a full rework carried internal political risk
• No shared vocabulary between PM, dev team, and designer around what "done" looked like

💊 Solution

• Documented the architectural impossibility of a partial fix with technical specificity: "the board, pot, and player cards already consume over 80% of vertical space — there is no room for additional seats without a fundamental UI architecture rework"
• Shared a WIP Figma link within days of receiving the brief — showing directional progress before asking for scope approval
• Framed the rebuild not as extra work but as the only path to a product that could actually be shipped and maintained: "a partial fix would only create more inconsistencies"

📔 Context

Worst-case frames — showing all 9 players active simultaneously with full bets visible — were designed as stress tests to prove structural robustness. The PM reviewed them as realistic gameplay screens and raised feedback about bet sizing, open frequencies, and chip display — none of which are layout issues.

🚨 Problem

• PM feedback targeting game simulation behavior, not layout validation
• Risk of derailing the design process with out-of-scope concerns
• Potential loss of confidence in the design if the purpose of each frame type was not clarified

💊 Solution

• Clarified the distinction in writing with precision: "these are not gameplay simulations — they are worst-case UI layout validations. The goal is to prove that the layout does not break under maximum load."
• Separated the two workstreams explicitly: stress-test frames (structural validation) vs. interactive prototypes (realistic gameplay demonstration)
• Delivered both: worst-case frames proving robustness, interactive prototypes demonstrating realistic flow — each serving its purpose without conflating the two

📔 Context

The raise slider is the most technically specific interaction in the product. Native poker apps use vertical sliders. This plugin is embedded in a scrollable web page — vertical swipe conflicts with browser scroll. The interaction had to be completely rearchitected for the deployment context.

🚨 Problem

• Vertical raise slider = page scroll triggered instead of raise amount change
• No existing poker product had solved this in an embedded web context
• The slider had to remain intuitive and ergonomically usable with one thumb on mobile

💊 Solution

• Horizontal slider with two explicit cursor buttons: + (right) and − (left)
• MiniCardData widget above the slider: displays current raise amount in real time with a drum-roll animation (numbers scroll vertically inside a clipped container — $120 → $130 → ... → $220)
• Percentage indicator (0% → 100%) displayed simultaneously below the amount
• 5 discrete states documented as Figma symbols: Percentage=0, 25, 50, 75, 100 — each with precise fill and cursor positioning
• Slider fill turns yellow (brand color #FFD700) at 100% — visual confirmation of all-in
• All states annotated in Figma dev mode: cursor position, fill behavior, amount display rules

🔴 VISUAL ASSET NEEDED — GIF: Cursor Bet Interaction prototype recording. Shows +/− stepping, yellow progress bar fill, drum-roll amount update, and Bet→Raise label switch in action. This is the single most impressive micro-interaction — high-impact GIF. Source: Record "Cursor Bet Interaction – Prototype" in Figma.

📔 Context

The primary action button label is not static — it changes based on the game state and the slider position. This is a core poker rule that the original build had implemented incorrectly.

🚨 Problem

• Original build showed "Bet" and "Raise" labels inconsistently with no game-state logic
• No distinction between betting into an empty pot vs. raising a live bet

💊 Solution

• Primary button shows BET when no live bet exists and slider is at minimum (new street, no prior action)
• Primary button switches to RAISE once the slider exceeds the minimum legal raise threshold
• Button displays both the action label (top, small) and the current amount (bottom, bold italic) — two-line format for at-a-glance decision-making
• All four action states fully specified as Figma symbols: Against Bet / Against No Bet / No Raise Available / Partial Raise (ALL-IN)
• Dev mode annotation on the BetButton component: "The primary action switches from Bet to Raise once the slider exceeds the minimum bet. The Bet/Raise value follows the raising amount."

📔 Context

The board card reveal is the central visual moment of each hand. Each new street (Flop = 3 cards, Turn = 4th card, River = 5th card) reveals an additional card. This needed to be prototypeable in Figma with precise frame-by-frame control.

🚨 Problem

• Cards needed to appear progressively, not all at once
• The 5th board card position needed to remain spatially consistent across all stages
• "Proto Card Asset" variant needed to differentiate the newly revealed card from existing ones to enable per-card animation triggers in Figma prototyping

💊 Solution

• 6 prototype frames built for the Turn and River sequence, showing the exact visibility state of each card slot
• Cards use hidden="true" attribute until their street arrives — then swap to visible Proto Card Asset instance
• The Component 2 instance marks the newly revealed card (distinct from Card Asset = existing visible card) — enables Figma's Smart Animate to apply entry transition to that card only
• Board Card component built in 2 sizes: S (183×47px, 5-card horizontal strip) and M (243×63px)
• Validated the full board progression across extracted game states: Pre-Flop (0 visible / 5 hidden), Flop (3 visible / 2 hidden), Turn (4 visible / 1 hidden), River (5 visible / 0 hidden) — each card slot maintains its exact spatial position (0px, 37px, 74px, 111px, 148px offset) regardless of visibility state, ensuring zero layout shift during reveal transitions

🔴 VISUAL ASSET NEEDED — GIF: Cards Appearance Turn and River prototype recording. Shows Flop→Turn→River card reveal animation — clicking Check triggers next card appearance via Smart Animate. Demonstrates the zero-layout-shift board progression. Source: Record "Cards Appearance Turn and River – Proto" in Figma.

📔 Context

Static mockups and annotated specs reduce ambiguity, but they cannot communicate timing, sequence, and interaction feel. For a real-time game product, the dev team and the PM needed to experience the flow — not just read about it. I delivered three separate interactive prototypes, each scoped to demonstrate a specific interaction layer.

🚨 Problem

• Static frames cannot convey the sequential logic of a poker hand: deal → bet → reveal → result
• The PM had no poker domain knowledge — she needed to play through a hand to understand the interaction model
• Dev team needed to see animation timing, transition sequences, and state changes in motion — not as written specs
• Risk of the dev team implementing transitions incorrectly without a playable reference

💊 Solution

• GameSimulation Prototype (20+ frames): a full single-hand simulation playable in Figma, covering the complete hand lifecycle from Pre-Flop deal through betting flow, card reveals, pot aggregation, player action states (fold, check, call, raise), conditional display of active CTAs, and visual feedback for each stage transition. Annotated with an Interaction note: "This prototype simulates a single hand from Pre-Flop to Hand End, focusing on betting flow and state transitions. It demonstrates card placement and pot aggregation, player action states, with a full fold, check, and opponent visibility when folded or active, conditional display of player active CTAs, and visual feedback for stage transitions"
• Cursor Bet Interaction Prototype: isolated demonstration of the horizontal raise slider. Shows the +/− cursor stepping behaviour, real-time amount update on the MiniCardData widget, yellow progress bar fill, percentage indicator transition, and the Bet → Raise label switch when the slider exceeds the minimum bet threshold
• Cards Appearance Turn and River Prototype: isolated demonstration of the Turn and River card reveal animations. Clicking Check triggers the card appearance sequence — Flop → Turn reveal → River reveal — with each new card entering via Smart Animate transition while existing cards remain static
• Each prototype scoped to one interaction layer — preventing confusion between game flow, slider mechanics, and card animation. Dev team could reference each prototype independently during implementation of each feature

🔴 VISUAL ASSET NEEDED — GIF: GameSimulation Prototype recording (full hand). Shows the complete Pre-Flop→Flop→Hand End flow — betting, folding, pot aggregation, card reveals, result modal. This is the hero GIF of the entire case study — proves the system works as a coherent experience, not just isolated components. Source: Record "GameSimulation Prototype" in Figma (play through 1 full hand).

📔 Context

The complete component library was built from scratch and organized as a single Components section in Figma, covering every element of the game surface at every state.

💊 Component inventory

Cards — 52-card deck × 4 suits (♥ ♠ ♦ ♣) × 5 sizes (XS / S / M / L + Back) — 208+ symbols. Suits color-coded: ♥ ♦ red, ♠ ♣ black. Each size optimized for its context: XS for opponent hole cards, M for the board, L for hero hand.

Player modules — 3 states: Default (waiting), Action (currently acting, yellow highlight), Folded (desaturated). Each state drives nameplate and card container appearance simultaneously.

Betting zone — Token, BigGroupToken (stack of 3 chips), BetLabel (left/right orientation variants), Pot display (chips visible or hidden), Dealer Button (gold glow shadow).

Action Buttons — 4 complete states as full-width mobile frames: Against Bet (FOLD / CALL $x / RAISE $x), Against No Bet (FOLD / CHECK / BET $x), No Raise Available (FOLD / CALL — raise slider hidden), Partial Raise (FOLD / CALL $x / ALL-IN $x).

Cursor system — Button Cursor (+ and −, Mobile and Desktop variants with Hover states), MiniCardData (real-time amount display), CursorIncremental (5 fill states).

Hero Hand — 3 states: Default, Action, Folded. Nameplate in 2 sizes (S for opponents, M for hero) with 2 types (name+stack, messaging).

Stage indicator — 4 states: Pre-Flop, Flop, Turn, River. Yellow Archivo Black typography, white "Stage" subtext, slight rotation for visual character.

Hand Results modal — full result overlay with Cell component (win / lost / default × Mobile/Desktop × Default / Hover / Selected / Hover Selected states), Result label (Win/Lost), and primary CTA button. Responsive layout rule: single-column player list for up to 7 players, automatic switch to two-column layout at 8+ players — preventing modal overflow on both mobile and desktop. On desktop, row hover previews player details; click selects and expands the row.

🔴 VISUAL ASSET NEEDED — GIF: Hand Results modal row interaction. Show tapping Player 2 (expand), then Player 4 (winner highlight with gold row + cards). Demonstrates expand/collapse, row states, winner highlight. Source: Record Hand Result prototype interaction (tap Player 2 then Player 4 as mentioned in the Figma annotation).

📔 Context

Pot display in poker is not a single number — it represents different things depending on the betting phase. The original build displayed a single pot number with no distinction between resolved and unresolved bets, creating visual confusion about the actual pot size.

🚨 Problem

• No visual distinction between money already committed to the pot and active bets still in play
• Players could not tell whether the pot number included the current bet they were facing
• Pot amount display inconsistent between streets — sometimes including active bets, sometimes not

💊 Solution

• Designed a dual-layer pot display system validated across all 5 streets:
• Central pot chips (visual token stack) = resolved bets only — money from completed betting rounds that has been collected into the center
• Pot label (text: "POT $x") = resolved pot + all active unresolved bets on the current street — the total amount the winner would take
• Active bet chips = displayed in front of each betting player, physically separated from the central pot — showing exactly who has bet and how much
• This three-element system was validated frame by frame: Pre-Flop ($0 resolved / $3 active blinds / label $3), Flop no-bet ($4 resolved / $0 active / label $4), Flop facing-bet ($4 resolved / $34×n active / label $76), Turn no-bet ($110 resolved / $0 active / label $110), River facing-bet ($110 resolved / $47 active / label $157)
• Each transition point (street change) triggers a merge animation: active bet chips move to center, pot label recalculates, new street begins at $0 active

📔 Context

Which buttons appear on screen at any given moment is not a design choice — it is a game rule. Check is only legal when no bet exists. Call requires matching an existing bet. Raise must respect minimum sizing rules. The original build had these wrong. I designed an explicit state matrix that engineering could implement as a lookup table.

🚨 Problem

• Check button available when a live bet existed — an illegal action
• Raise amounts not respecting minimum raise rules
• No formal logic connecting game state to button availability — developers were guessing

💊 Solution

• Designed two primary action panel configurations, each as a complete Figma frame:
• Facing No Bet (new street, or all players checked): FOLD | CHECK | BET $x — slider starts at minimum bet, label shows "BET"
• Facing a Bet (opponent has bet or raised): FOLD | CALL $x | RAISE $x — slider starts at minimum legal raise (2× current bet), label shows "RAISE"
• Two edge-case configurations also specified: No Raise Available (FOLD | CALL — slider hidden, player can only match or fold), Partial Raise / ALL-IN (FOLD | CALL $x | ALL-IN $x — when stack is insufficient for minimum raise)
• Each configuration annotated with the exact game condition that triggers it — dev team implements a state lookup, not a series of if/else assumptions
• Validated across all extracted game states: Pre-Flop initial (facing blind = Facing Bet), Pre-Flop after raise (Facing Bet, higher amount), Flop after check (Facing No Bet), Flop after bet (Facing Bet), Turn no bet (Facing No Bet), River after bet (Facing Bet)

📔 Context

Each street introduces new board cards and resets the betting round. The visual state of the table must update coherently: new cards appear, active bets merge into the pot, action resets to the first active player. I designed and validated 12 distinct game state frames covering the complete hand lifecycle.

🚨 Problem

• No formal documentation of what the UI should look like at each stage of a hand
• Developers implementing visual transitions without understanding the underlying game state changes
• Risk of inconsistent behaviour between streets (e.g., pot not resetting correctly after a betting round)

💊 Solution

• Pre-Flop (6 frames): State 0 — Table Initialized (pure setup state: cards dealt, no blinds posted yet, no betting interaction, no player is "in turn", no chips on table, pot value hidden — a distinct UI state that developers must handle separately from active gameplay), State 1 — All Bets Placed / Pre-Pot Merge (all active players have matched the current bet, individual chips remain in front of each player, pot label reflects sum of all bets but chips are not yet merged — table is visually in a "resolved but not progressed" state, signalling the betting round is complete before the merge animation fires), initial state (blinds posted, hero cards dealt), facing a raise, after a call, action skipped due to fold
• Flop (2 frames): After check (no active bet — 3 community cards revealed, all pre-flop bets merged into resolved pot, first opponent has checked, action passed to user), facing a bet (active chips in front of bettor, pot label includes unresolved amount — annotated: "The central pot shows the resolved bet only. Active bet chips remain in front of the betting player. The pot must not include the current opponent bet")
• Turn (1 frame): Facing no bet — 4th card dealt, flop bets merged, pot contains all resolved bets, no active bet on this street, user is first to act
• River (1 frame): Facing a bet (after check) — 5th card dealt, hero checked then Player 2 bet $47, Player 3 folded, active bet not merged into pot, hero is current acting player with Call $47 / Raise $94 / Fold available
• Hand Result (4 frames): Win during Pre-Flop (everybody fold — hero wins without showdown), Loss with hole cards only (Player 2 won using only hole cards, no board cards required), Loss at showdown with 9 players (full two-column layout, row states: tap to expand/collapse, winner row expanded by default), Win at showdown with board cards summary
• Each frame annotated with: board state, pot calculation breakdown, active player indicator, available actions, and the specific poker rule that governs the transition from the previous state
• OLD vs. NEW comparison included for every street: Pre-Flop, Flop, Turn, River, and Hand Result — side-by-side frames showing the original dev build (OLD) next to the redesigned version (NEW), making the scope and impact of the rebuild immediately visible to stakeholders

🔴 VISUAL ASSET NEEDED — Screenshot: Scenarios page overview showing OLD vs NEW side-by-side for all streets (Pre-Flop, Flop, Turn, River, Hand Result) with dev annotations visible. Proves the scope of the rebuild and the quality of state documentation. Source: Image 7 (Scenarios section with annotations).

• Board card progression validated: Pre-Flop (0 cards) → Flop (3 cards) → Turn (+1 = 4 cards) → River (+1 = 5 cards) — each card slot maintains its spatial position across all frames, only visibility changes

Key Results