Poker With Friends · פוקר עם חברים

A private poker-night manager for groups of friends. It does not deal cards — people play a real, physical game around a real table. The app handles the money: buy-ins, chips issued, the clock, the final chip count, profit and loss, and who owes whom at the end of the night.

The interface is Hebrew-first and RTL, designed for a phone in one hand.

Setup: see docs/SETUP.md for the Supabase and Vercel configuration. Nothing in this repository needs editing to get running.

---

What it does

Open a table	Buy-in amount, chips per buy-in, max entries, start and end time, join mode, visibility, counting mode. Defaults: 50₪ = 500 chips, 6 entries max.
Invite	A 5-character join code (A7K92) with a share link and native share sheet. The code never grants admin rights.
Join	Registered users, or guests with no account at all.
Play	Live dashboard: players, entries, pot, chips on the table, countdown. Players request another entry; the admin approves or rejects.
Count	Admin counting or self-counting, with chip-discrepancy detection before anything is finalised.
Settle	Profit/loss per player and the minimal set of transfers: "דניאל מעביר לאילן 80₪".
Remember	History, statistics, records, profit charts and per-group leaderboards.
Compare	An opt-in global leaderboard of registered players, ranked on realised profit from finished games only.
Tidy up	A table that never started can be deleted by its owner.
Leave early	A player can cash out mid-game: they declare their chips, their result is settled by the same accounting as everyone else, and the game carries on.

---

Architecture

src/
  app/                    routes (App Router, all screens Hebrew/RTL)
    table/[id]/           live dashboard, counting, results, leaderboard
    join/[code]/          guest and member joining
    profile/              overview · history · stats · tables · settings
  components/
    ui/                   design-system primitives (RTL-aware)
    table/ join/ profile/ charts/ layout/
  lib/
    domain/               pure, unit-tested business logic
    actions/              server actions — the only write path
    data/                 server-side read models
    supabase/             browser · server · service-role · middleware clients
supabase/migrations/      schema, functions, RLS, realtime, storage
tests/                    Vitest suites over the domain layer

Where the rules actually live

Every mutation goes through a Server Action → SECURITY DEFINER Postgres function. Those functions derive the actor from auth.uid() themselves and take row locks before they read totals, so the rules hold under concurrency and cannot be bypassed by a crafted request. The TypeScript in src/lib/domain/permissions.ts mirrors the same rules purely so the UI can hide controls that would fail — if the two ever disagree, the database wins.

Leaving a game in progress

The source of truth for seated-versus-left is table_players.left_at — null while seated, a timestamp once the leave flow completed. Nothing else decides it: not a chip submission, not an approved count, not a status value. The predicates in src/lib/domain/participation.ts treat anything that is not a real timestamp as seated, so a missing column can never mark a playing participant as having left.

A player who cashes out keeps status = 'ACTIVE' and gains a left_at timestamp. That is deliberate: their buy-ins are in the pot and their issued chips came off the rack, so they are still a participant in that game. compute_final_rows, the chip-conservation check and finalize_game all select status = 'ACTIVE' and are therefore untouched — the leaver's profit and loss is computed by exactly the same code as everyone else's. There is no second accounting path. What left_at changes is only the right to keep playing: no further buy-ins and no rebuy requests.

Money and chips

• Money is stored as integer agorot. No floating point touches a financial value.
• buyin_transactions is an append-only ledger. A mistaken entry is corrected with a REVERSAL row, never by editing history.
• Totals (total_paid, chips_issued, buy_in_count) are derived by a view over that ledger. There is no client-written counter anywhere.
• Chips convert back to cash with the largest-remainder method, so the sum of every player's final value is exactly the pot and profit/loss sums to exactly zero — no stray agora.
• finalize_game recomputes the results itself and rejects any settlement plan that does not exactly resolve every balance.

Concurrency

• Approving a rebuy locks the request row, then writes a ledger row whose request_id is covered by a unique index. A double-tap, or two admins tapping at once, cannot produce two buy-ins.
• Max entries are re-counted from the ledger inside a lock on the player row, so two concurrent approvals cannot exceed the cap.
• A partial unique index allows only one open rebuy request per player.
• Reversals are keyed by reverses_transaction_id, so a buy-in can be reversed at most once.

Guests

A visitor who joins with a code is given a Supabase anonymous session, minted server-side, stored in httpOnly cookies. That means a guest holds a real signed JWT and a real auth.uid(), so:

• RLS and Realtime treat guests exactly like registered users;
• the server never trusts a player id that came from the browser — a guest cannot touch another player's record by changing an id;
• the session survives a refresh or a closed tab;
• signing up later links an email to the same user, so the games already played carry over. Nobody is ever merged by display name.

This is the beginning of the README. Read the rest at the original. Read the full README ↗