greenePoker
Strategie v6

0Plan-Revisionen v5 → v6

0.1 Anlass

v5 wurde am 2026-05-08 nach Abschluss von I6 erstellt und nicht weitergepflegt. Der reale Backend-Stand am 2026-05-21 liegt bei I16 (Phase C funktional vollständig für Single-Table; 341 Tests grün). Die Diskrepanz zwischen Plan-Stand und Realstand machte v5 als Steuerungsdokument unbrauchbar.

0.2 Inhaltliche Änderungen gegenüber v5

0.3 Neue Entscheidungen

• D23 — Rebuy-Mechanik: Wizard-Auswahl zwischen freeze-out (keine Rebuys), classic (Rebuy-Phase + Addon) und re-entry (Bust-Out-Re-Entry im Fenster).
• D24 — Phasen-Reihenfolge: Reihenfolge C ersetzt v5/D4. Begründet in Reviews/einschaetzung_reactMigration_vor_backend_2026-05-21.md.
• D25 — Lobby-Anzeigeumfang: Turnier-Lobby zeigt angemeldete Spieler mit Live-Stacks; Auszahlungsstruktur schematisch + konkret; Standard-Buttons modus-abhängig.

0.4 Beibehaltene Entscheidungen

D1 bis D22 aus v5 bleiben unverändert verbindlich (siehe Abschnitt 2).

1Übergeordneter Rahmen

1.1 Projekt-Vision und Phasen-Modell

Projekt: greenPoker — webbasiertes Texas-Hold'em-Spielgeld-Pokerportal für einen privaten Club. Single-Node-Deployment, ein zentraler Node-Prozess, mehrere gleichzeitige Tische, Echtzeit-Sync via Socket.IO.

Ziel-Funktionsumfang:

• Turniere (Single-Table und Multi-Table) mit Wizard, Anmeldung, Sitzzuteilung, Blind-Levels, Bounties, Payouts, Series-Punkte, Wiederholungen
• Cashgames (Phase D) — eigenständige Domäne mit Buy-In/Stand-Up, Top-Up-Logik
• Server-autoritative Hold'em-Logik: Deck-Shuffle aus crypto.randomBytes, Hand-Evaluation, Pot/Side-Pot-Verteilung, Action-Validierung
• Hand-History, Replayer mit Sichtbarkeitsfilter
• HUD-Stats (VPIP, PFR, 3-Bet, Aggression Factor)
• Chat (Club + Tisch), Moderation, Notifications, Inbox, Club-Board, Bans, Admin-Backoffice
• React-basiertes Frontend (Phase B) nach Konsolidierung Phase C

Phasen-Modell (aktualisiert durch D24):

Phase A — HTML-Politur                            ✅ abgeschlossen (Stand v45.9 / v44.26)
Phase C — Backend mit HTML-Anbindung              ✅ I1–I16; I17–I19 ausstehend (D24)
Phase B — React-Port                              ausstehend (nach I19, D24)
Phase D — Cashgame-Engine                         ausstehend (verschränkt mit Phase B, D24)
Phase E — Moderator-Rolle, E-Mail,
           optional PostgreSQL                    ausstehend (Backlog)

Multiplayer-Scope (verbindlich, unverändert seit v1):

• Ein Node-Prozess, ein SQLite-Writer
• Mehrere gleichzeitige Tische, mehrere User pro Tisch
• Socket.IO mit Rooms pro Tisch (table:<id>), pro User (user:<id>), pro Turnier (tournament:<id>), pro Club (club:global)
• Kein horizontales Scaling, kein Multi-Region-Setup, keine externe Replikation
• Reversibilitätspfad nach Postgres (Phase E) offen gehalten, aber nicht aktiv geplant

1.2 Tech-Stack — verbindliche Festlegung

Verworfene Alternativen

1.3 Backup-Strategie

• db.backup('backup/greenpoker-YYYY-MM-DD.db') via better-sqlite3 Online-Backup — WAL-sicher, kein Server-Stop nötig
• Worker (workers/backup.worker.ts, I14-Restpunkt, noch nicht implementiert) ruft Backup periodisch auf (BACKUP_INTERVAL_HOURS = 24)
• Aufbewahrung: BACKUP_KEEP_DAYS = 7 rollende Backups, ältere werden gelöscht
• Pfad backend/data/backups/ (gitignored)
• Backup ist Pflicht-Voraussetzung vor jedem Migrations-Lauf in Produktion

1.4 Session-Mechanismus — Server-Session-ID (Variante A)

Funktionsweise:

1. Login: Server prüft E-Mail + Passwort, erzeugt 32-Byte-Zufalls-ID (crypto.randomBytes(32).toString('hex')), speichert in Tabelle sessions, setzt Cookie session_id mit httpOnly; Secure; SameSite=Lax
2. Folge-Request: Cookie automatisch gesendet, Middleware liest und schlägt in sessions nach (Prepared Statement), hängt req.user an
3. Logout: DELETE FROM sessions WHERE id = ? plus Cookie-Clear
4. „Alle Geräte abmelden": DELETE FROM sessions WHERE user_id = ?
5. Cleanup-Worker löscht abgelaufene Sessions alle 60 Min

Warum nicht JWT: Single-Node-Scope macht den einzigen JWT-Vorteil (zustandslose Multi-Node-Validierung) gegenstandslos. Widerruf bei Ban/Reset ist mit Server-Session-ID eine DELETE-Query. DB-Lookup kostet bei WAL-SQLite + Prepared Statement einstellige Mikrosekunden.

SESSION_LIFETIME_DAYS = 30 mit Refresh bei jedem Request via last_seen.

1.5 Hand-History-Schema — Variante 2 (mit hand_board_cards)

Strukturelle Bestandteile:

• hands — Kopfdaten pro Hand (Tisch, Turnier, Blind-Beträge, Dealer-Sitz, board als kompakter String, Pot-Total, Rake)
• hand_board_cards — pro Karte am Board eine Zeile (street ∈ {flop,turn,river}, position 0/1/2, rank 2..14, suit ∈ {h,d,c,s}). Erlaubt analytische Queries auf Board-Texturen.
• hand_players — pro Spieler einer Hand: Sitz, Start-Stack, Hole-Cards (verschlüsselt), shown_at_showdown, gewonnener Betrag, sowie Stats-Flags vpip/pfr/three_bet/agg_factor_num/den
• actions — pro Action eine Zeile (seq, street, action ∈ {fold,check,call,bet,raise,allin}, amount, at)

Stats-Definition (D17b, PokerTracker-4-Standard): VPIP = freiwillige Geldzugabe preflop außer Blind-Posten; PFR = erste freiwillige Raise preflop; 3-Bet = erste Re-Raise preflop; AF = (Bet+Raise)/Call mit Numerator und Denominator separat gespeichert.

1.6 Zentrale Spielregel-Konstanten (D17c)

Vollständige Konstanten-Liste siehe Anhang C.

2Decision Log

Verbindliche Entscheidungen. Spätere Abweichungen müssen explizit als Plan-Revision dokumentiert werden. D23, D24, D25 sind neu in v6.

3Scope und Abgrenzung

3.1 In Scope (gesamtes Projekt)

Backend (Node + TypeScript + Express + Socket.IO + better-sqlite3 + Drizzle ORM):

• Authentifizierung mit E-Mail-Login (D18), Sessions (1.4), Registrierungs-Workflow mit Admin-Genehmigung
• User-Profile mit display_name (D19), Cooldown-Endpoint, serverseitige Preferences (D10)
• Buchungssystem (doppelte Buchführung) mit ConsistencyCheckService (SA-1/SA-2), zod-Blob-Validation (SA-3), CHECK-Constraints (SA-4)
• Tournament-Engine: Wizard, Registration, Sitzzuteilung (D22), Schedules (D9), Lifecycle, Blind-Levels, Bounty, Payout, Single-Table und Multi-Table mit Balancing (I17)
• Rebuy-Modi (D23): freeze-out / classic / re-entry
• Lobby-Anzeigeumfang (D25): Spielerliste mit Live-Stacks, Auszahlungsstruktur
• Server-autoritative Hold'em-Logik, Hand-History und Replayer (Variante 2, D21), HUD-Stats
• Chat (Club + Tisch), Moderation, Club Board, Notifications/Inbox, Bans
• Echtzeit-Sync via Socket.IO Rooms
• Cashgame-Engine (Phase D): Anforderungs-Spezifikation steht aus

Frontend: Phase A/C: HTML inkrementell durch API-Calls angebunden. Phase B: vollständige React-Port-Phase.

3.2 Nicht in Scope

• Echte Payment-Anbindung, KYC, E-Mail-Versand (SMTP)
• Moderator-Rolle (Phase E, D2)
• PostgreSQL-Migration (Reversibilitäts-Pfad, nicht aktiv geplant)
• Multi-Node-Skalierung, Multi-Region, Mobile native Apps

3.3 Aktualisierte Phasen-Folge (gemäß D24)

Phase A — HTML-Politur                                            ✅ abgeschlossen
       ↓
Phase C — Backend mit HTML-Anbindung
   I1–I16 (Auth bis HUD/Stats)                                    ✅ abgeschlossen
   I17 — Multi-Table-Balancer (in HTML)                            ausstehend
   I18 — Rebuy-Vollausbau (in HTML)                                ausstehend
   I19 — Turnier-Lobby-Anzeigeumfang (in HTML)                     ausstehend
       ↓
Phase B — React-Port
   B1 — Stack-Festlegung und Plattform-Setup                       ausstehend
   B2 — 1:1-Migration der stabilen Domänen                         ausstehend
       ↓
Phase B / D verschränkt
   B3/D1 — Cashgame-Backend + React-Cashgame-Komponenten          ausstehend
   B4 — Lobby- und UI-Strukturarbeiten in React                    ausstehend
       ↓
Phase E — Moderator-Rolle, E-Mail-Versand, optional PostgreSQL    Backlog

4Architektur-Übersicht

4.1 Schichten-Modell

Client (Browser)
  HTML + JS (fetch + socket.io-client) — heute
  React + TS (Phase B) — geplant
        ↓
Transport-Schicht
  Express HTTP REST (/api/*)  +  Socket.IO (Rooms: table:/user:/tournament:/club:)
        ↓
Anwendungs-Schicht (Sachgebiet-Module)
  Auth · User · Ban · Accounting · Tournament · Game · HandHistory · Chat · ClubBoard · Notification · Stats · Admin
        ↓
Querschnitt
  RealtimeBus · Logger · Migrator · BackupWorker · ScheduleWorker · CleanupWorker · ConsistencyCheckService · BlobValidator · PolymorphicResolver · Clock
        ↓
Persistenz-Schicht
  Drizzle ORM → better-sqlite3 (synchron, WAL) → greenpoker.db

Modul-Prinzipien (D13, Lesart 3): Ein Modul entspricht einem Sachgebiet. Innerhalb eines Moduls werden Klassen nach SRP gesplittet. Module kommunizieren über Direkt-Injektion in server.ts, Realtime-Bus für asynchrone Events oder Callbacks.

4.2 Memory-First-Strategie für Spielzustand (D20)

SeatStateMemory hält In-Memory-Map Map<tableId, Map<seatIndex, SeatState>>. DB-Tabelle seats ist Snapshot-Speicher, kein Action-Log.

4.3 Datenfluss einer Spieler-Action

Browser: socket.emit('action', { handId, type:'raise', amount: 200 })
  → game.gateway: validiert Inhaber, prüft am-Zug, prüft Stack-Decken
    → action.validator: Min-Raise, Stack-Limit
      → hand.engine: nimmt State, gibt neuen State zurück (pure)
        → hand.repository: persist action in `actions`
        → SeatStateMemory: stack-Adjustierung
        → bei Hand-Ende: snapshot in `seats` + `hand_players.won_amount`
      → realtime.bus.emit('state-update', tableId, newState)
        → io.to(`table:${tableId}`).emit('state-update', newState)
          → Browser empfängt und rendert

5Datenmodell

5.1 Migrationsreihenfolge

5.2 Vollständiges Schema (Stand I16)

Identität & Zugang

users
├── id INTEGER PK, email TEXT UNIQUE, display_name TEXT (UNIQUE NOCASE)
├── display_name_changed_at INTEGER NULL
├── password_hash TEXT, role ENUM('admin','player') default 'player'
├── status ENUM('pending','active','banned') default 'pending'
├── avatar_path TEXT NULL, created_at INTEGER, last_seen_at INTEGER NULL

sessions
├── id TEXT PK (64 hex), user_id FK → users(id) ON DELETE CASCADE
├── created_at INTEGER, expires_at INTEGER, last_seen INTEGER, user_agent TEXT NULL

bans
├── id INTEGER PK, user_id FK → users ON DELETE CASCADE
├── level ENUM('warning','play_block','full'), reason TEXT NULL
├── issued_by FK → users, issued_at INTEGER, expires_at INTEGER

Buchungen (doppelte Buchführung, D15)

accounts
├── id INTEGER PK, owner_type ENUM('user','club'), owner_id INTEGER NULL
├── name TEXT, balance_cache INTEGER default 0, currency TEXT default 'chips', created_at INTEGER

transactions
├── id INTEGER PK, ts INTEGER
├── from_account FK → accounts, to_account FK → accounts
├── amount INTEGER (> 0 per CHECK)
├── ref_type ENUM('buyin','rake','bounty','transfer','admin','donation','reverse')
├── ref_id INTEGER NULL, note TEXT NULL
├── created_by FK → users, reversed_by INTEGER NULL

ledger_entries
├── id INTEGER PK, transaction_id FK → transactions
├── account_id FK → accounts, amount INTEGER (signed), ts INTEGER

Tische & Turniere

tables
├── id INTEGER PK, name TEXT, kind ENUM('tournament','cashgame') default 'tournament'
├── tournament_id INTEGER NULL, seat_count INTEGER default 8
├── status ENUM('open','paused','breaking','closed') default 'open'
├── created_at INTEGER, created_by FK → users NULL, closed_at INTEGER NULL

seats  (Memory-First-Snapshot, D20)
├── id INTEGER PK, table_id FK → tables ON DELETE CASCADE
├── seat_index INTEGER, user_id FK → users ON DELETE SET NULL
├── stack INTEGER default 0, is_dealer INTEGER default 0
├── is_sb INTEGER, is_bb INTEGER, is_sit_out INTEGER, time_bank INTEGER default 90000
├── snapshot_at INTEGER NULL

seat_sessions
├── id INTEGER PK, table_id FK, user_id FK
├── sat_down_at INTEGER, stood_up_at INTEGER NULL

tournament_series
├── id INTEGER PK, title TEXT, description TEXT NULL
├── created_by FK → users, created_at INTEGER

tournament_schedules
├── id INTEGER PK, title TEXT
├── recurrence_json TEXT (zod-validiert), template_json TEXT (zod-validiert)
├── series_id FK → tournament_series NULL, is_active INTEGER default 1
├── created_by FK → users, created_at INTEGER

tournaments
├── id INTEGER PK, title TEXT
├── status ENUM('registering','running','paused','finished','cancelled')
├── table_id FK → tables NOT NULL (D22)
├── start_at INTEGER, buyin INTEGER, rake_pct INTEGER
├── speed ENUM('slow','normal','turbo','hyper') default 'normal'
├── payout_curve ENUM('steep','standard','flat') default 'standard'
├── rebuy_mode ENUM('none','1+addon') → I18: ENUM('freeze-out','classic','re-entry')
├── max_players INTEGER default 8, prize_pool INTEGER default 0
├── created_by FK → users, created_at INTEGER
├── schedule_id FK, series_id FK

tournament_players
├── id INTEGER PK, tournament_id FK, user_id FK
├── registered_at INTEGER, seated_at INTEGER NULL
├── final_place INTEGER NULL, prize_won INTEGER default 0
├── series_points INTEGER default 0
├── rebuy_count INTEGER default 0, addon_used INTEGER default 0
├── (bei I18) re_entry_count INTEGER default 0

blind_levels
├── id INTEGER PK, tournament_id FK ON DELETE CASCADE
├── level INTEGER, sb INTEGER, bb INTEGER, ante INTEGER default 0, duration_min INTEGER

Hand-History (D6, D21)

hands
├── id INTEGER PK, table_id FK, tournament_id FK NULL
├── started_at INTEGER, ended_at INTEGER NULL
├── sb_amount INTEGER, bb_amount INTEGER, ante INTEGER default 0
├── dealer_seat INTEGER, board TEXT NULL
├── pot_total INTEGER NULL, rake INTEGER default 0

hand_board_cards
├── id INTEGER PK, hand_id FK ON DELETE CASCADE
├── street ENUM('flop','turn','river'), position INTEGER
├── rank INTEGER (2..14), suit TEXT (h|d|c|s)

hand_players
├── id INTEGER PK, hand_id FK, user_id FK
├── seat INTEGER, stack_start INTEGER, hole_cards TEXT NULL
├── shown_at_showdown INTEGER default 0, won_amount INTEGER default 0
├── vpip, pfr, three_bet, agg_factor_num, agg_factor_den (INTEGER default 0)

actions
├── id INTEGER PK, hand_id FK, user_id FK
├── seq INTEGER, street TEXT
├── action ENUM('fold','check','call','bet','raise','allin'), amount INTEGER default 0
├── at INTEGER

Chat, Board, Notifications

chat_messages
├── id INTEGER PK, room_kind ENUM('table','club'), room_ref INTEGER NULL
├── user_id FK, text TEXT, at INTEGER
├── pinned INTEGER default 0, deleted_at INTEGER NULL, edited_at INTEGER NULL

word_filters · mutes · chat_room_settings (slow_mode_sec, updated_at)

inbox_items
├── id INTEGER PK, user_id FK, kind TEXT, title TEXT, body TEXT
├── ref_type TEXT NULL, ref_id INTEGER NULL
├── read_at INTEGER NULL, created_at INTEGER, action_required INTEGER default 0

popup_log
├── id INTEGER PK, sent_by FK, target_type ENUM('all','user'), target_id INTEGER NULL
├── title TEXT, body TEXT, sent_at INTEGER

club_board
├── id INTEGER PK, text TEXT, author_id FK
├── created_at INTEGER, edited_at INTEGER NULL, deleted_at INTEGER NULL

6Programmstruktur

6.1 Verzeichnisstruktur (Stand I16)

backend/
├── data/                           (gitignored)
│   ├── greenpoker.db
│   ├── avatars/
│   └── backups/
├── drizzle/                        (SQL-Migrationen 0001–0010)
├── scripts/seed.ts
├── src/
│   ├── config.ts                   (zentrale Konstanten, D17c)
│   ├── types.ts                    (AuthenticatedUser, Express-Augmentation)
│   ├── server.ts                   (Bootstrap, DI-Wurzel)
│   ├── db/
│   │   ├── client.ts               (PRAGMA-Setup, Drizzle-Wrapper)
│   │   ├── schema.ts
│   │   └── migrator.ts
│   ├── core/
│   │   ├── logger.ts · errors.ts · time.ts · ids.ts
│   │   ├── realtime.ts             (RealtimeBus)
│   │   ├── consistency-check.service.ts
│   │   └── polymorphic-resolver.ts
│   ├── validation/
│   │   ├── prefs.schemas.ts · auth.schemas.ts
│   │   ├── accounting.schemas.ts · schedule.schemas.ts
│   │   └── blob-versioning.ts      (SA-3)
│   ├── modules/
│   │   ├── auth/                   ✅ I1
│   │   ├── ban/                    ✅ I2
│   │   ├── accounting/             ✅ I3
│   │   ├── user/                   ✅ I4
│   │   ├── game/                   ✅ I5, I9, I10, I11
│   │   │   ├── seat-state.memory.ts · table.repository.ts
│   │   │   ├── game.gateway.ts · game.routes.ts · game.module.ts
│   │   │   ├── deck.ts · hand.engine.ts · hand.evaluator.ts
│   │   │   ├── hand.repository.ts · hand.service.ts · hand-state.memory.ts
│   │   │   ├── pot.calculator.ts · action.validator.ts · time.bank.service.ts
│   │   ├── tournament/             ✅ I6, I7, I8, I11
│   │   │   ├── tournament.repository.ts · tournament.routes.ts
│   │   │   ├── tournament.module.ts · tournament.lifecycle.service.ts
│   │   │   ├── buyin.service.ts · payout.calculator.ts
│   │   │   ├── schedule.repository.ts · schedule.service.ts · schedule.module.ts
│   │   ├── handhistory/            ✅ I15, I16
│   │   │   ├── handhistory.repository.ts · replayer.service.ts
│   │   │   ├── handhistory.routes.ts · handhistory.module.ts
│   │   │   ├── stats.flagger.ts · stats.aggregator.ts
│   │   │   └── stats.routes.ts · stats.module.ts
│   │   ├── chat/                   ✅ I12
│   │   ├── clubboard/              ✅ I14
│   │   └── notification/           ✅ I13
│   ├── workers/
│   │   ├── cleanup.worker.ts       (Sessions/Bans, 60 min)
│   │   ├── schedule.worker.ts      (Schedule-Window, 60 min)
│   │   └── (geplant: backup.worker.ts)
│   └── tests/
│       ├── helpers/app.ts
│       └── *.test.ts               (341 Tests, alle grün)

6.2 Modul-Verantwortlichkeiten

7API-Spezifikation

Alle Endpoints unter /api. Authentifizierung über Session-Cookie. Antworten als JSON. Bei Fehlern: { message: string, code?: string }.

7.1 Implementierte Endpoints (I1–I16)

Auth & Session

User & Preferences

Accounting

Tournaments

Schedules & Series (I7)

Hand-History & Stats (I15, I16)

Chat & ClubBoard

Notifications & Inbox (I13)

7.2 Geplante Endpoints (I17–I19)

7.3 Socket.IO-Events

8Querschnittsthemen

9Schema-Analyse — Risiken SA-1 bis SA-7

10Risiken R1 bis R14

11Test-Strategie

11.1 Pyramide

Integration-Tests (HTTP, gegen :memory:-DB)
────────────────────
Modul-Tests (DB, ohne Edge-Layer)
───────────────────────────
Unit-Tests (Engines, Calculator, Validator)
──────────────────────────────────────

11.2 Status nach I16

11.3 Test-Konventionen

• :memory:-SQLite-DB pro Test-Datei; vollständige Migration bei Setup
• MockClock für alle Zeit-Abhängigkeiten
• HTTP-Tests via supertest gegen app.ts-Builder
• Keine echten Sockets in Unit-Tests; RealtimeBus mit vi.fn()-Mock
• Seed-Daten ausschließlich pro Test-Suite, kein globaler State

11.4 Geplante Test-Schwerpunkte

12Roadmap mit Iterationsschritten

12.1 Prinzipien (D14)

• Eine Iteration = eine Claude-Code-Session
• Jede Iteration endet lauffähig: Server startet, Tests grün, das adressierte Feature ist im Browser klickbar
• Schema-Änderungen und Spiellogik niemals in derselben Session mischen
• Wenn eine Iteration zu groß wird: Splitten

12.2 Iterations-Übersicht

Phase C — Backend Restpunkte
   I17 — Multi-Table-Balancer
   I18 — Rebuy-Vollausbau (D23)
   I19 — Turnier-Lobby-Anzeigeumfang (D25)
       ↓
Phase B — React-Port
   B0 — Stack-Festlegung (separate Brainstorming-Session)
   B1 — Plattform-Setup
   B2.x — Domänen-Migration in mehreren Iterationen
       ↓
Phase B/D verschränkt
   D0 — Cashgame-Anforderungs-Spezifikation (separate Brainstorming-Session)
   D-Iterationen (Schema → Lifecycle → Cashier → React-Komponenten)
       ↓
Phase E — Moderator-Rolle, E-Mail, Postgres-Option

12.3 I17 — Multi-Table-Balancer

12.4 I18 — Rebuy-Vollausbau (D23)

tournaments
├── rebuy_mode ENUM('freeze-out','classic','re-entry') default 'freeze-out'
├── rebuy_phase_min INTEGER default 60          -- nur classic
├── rebuy_cost INTEGER NULL                     -- classic/re-entry; default = buyin
├── addon_cost INTEGER NULL                     -- nur classic
├── addon_chips INTEGER NULL                    -- nur classic
├── rebuy_chips INTEGER NULL                    -- nur classic (default = Startstack)
├── re_entry_window_min INTEGER default 60      -- nur re-entry
├── rebuy_phase_end_at INTEGER NULL             -- berechnet bei Tournament-Start

tournament_players
├── re_entry_count INTEGER default 0

12.5 I19 — Turnier-Lobby-Anzeigeumfang (D25)

12.6 Phase B — React-Port

Stack-Anforderungen (ohne konkrete Produkt-Wahl): Strict-TS mit noUncheckedIndexedAccess, Komponententests mit JSDOM, Routing mit Lazy-Loading, kein Singleton-Store-Anti-Pattern, Komponentenscope-Styling, Hot-Reload < 1 s, Bundle < 500 KB gzipped initial.

12.7 Phase D — Cashgame-Engine

Offene Fragen: NL Hold'em allein oder PL/FL? Buy-In-Range pro Tisch? Auto-Top-Up: User-Preference oder pro Tisch? Stand-Up-Politik? Rake-Modell? Mehrtisch-Limit?

AAnhang A — Glossar

BAnhang B — Datenbank-Indexes

Vollständige Index-Liste (Stand I16):

INDEX bans(user_id, expires_at)
INDEX ledger_entries(account_id, ts DESC)
INDEX seats(table_id)
INDEX seat_sessions(table_id, user_id, sat_down_at)
INDEX tables(status)
INDEX tournaments(status)
INDEX tournaments(schedule_id)
INDEX tournaments(series_id)
INDEX tournament_players(tournament_id)
INDEX tournament_players(user_id)
INDEX tournament_schedules(is_active)
INDEX blind_levels(tournament_id, level)
INDEX hands(table_id, started_at DESC)
INDEX hand_players(user_id)
INDEX hand_players(hand_id)
INDEX actions(hand_id, seq)
INDEX hand_board_cards(rank, suit)
INDEX hand_board_cards(hand_id, street, position)
INDEX chat_messages(room_kind, room_ref, at DESC)
INDEX inbox_items(user_id, read_at)
INDEX club_board(deleted_at, created_at DESC)

Geplant (I18): tournaments(rebuy_mode), falls Lobby-Filter nach Modus eingeführt wird.

CAnhang C — Konfigurations-Konstanten

Quelle: backend/src/config.ts. Stand I16; ergänzt für I17/I18.

export const CONFIG = {
  // Gameplay (D17c)
  TIME_PER_ACTION_DEFAULT_SEC:            30,
  TIME_BANK_INITIAL_MS:               90_000,
  TIME_BANK_REFILL_PER_HAND_MS:        5_000,
  TIME_BANK_MAX_MS:                   90_000,
  LATE_REG_DEFAULT_MIN:                   30,
  PAUSE_PATTERN_DEFAULT:            'none' as const,
  MULTI_TABLE_LIMIT:                       4,
  SHUTDOWN_GRACE_MS:                   5_000,
  // Infrastruktur
  BACKUP_INTERVAL_HOURS:                  24,
  BACKUP_KEEP_DAYS:                        7,
  SESSION_LIFETIME_DAYS:                  30,
  SCHEDULE_WINDOW_DAYS:                   28,
  SCHEDULE_WORKER_INTERVAL_MIN:           60,
  CLEANUP_WORKER_INTERVAL_MIN:            60,
  // User / Anzeigename (D19)
  DISPLAY_NAME_COOLDOWN_DAYS:             30,
  DISPLAY_NAME_MIN_LEN:                    3,
  DISPLAY_NAME_MAX_LEN:                   24,
  DISPLAY_NAME_REGEX: /^[A-Za-z0-9_\-äöüÄÖÜß ]+$/,
  // Upload
  AVATAR_MAX_BYTES:                  200_000,
  // Tisch / Sitze (I5)
  DEFAULT_SEAT_COUNT:                      8,
  DEFAULT_START_STACK:                10_000,
  // Turniere (I6 — D22, I17 — Multi-Table)
  MIN_TOURNAMENT_PLAYERS:                  2,
  MAX_TOURNAMENT_PLAYERS:                  8,
  MAX_PLAYERS_PER_TABLE:                   8,   // I17 — Default für Wizard
  // Rebuy (I18 — D23)
  REBUY_PHASE_DEFAULT_MIN:                60,
  RE_ENTRY_WINDOW_DEFAULT_MIN:            60,
  // Validation + Konsistenz (SA-1/SA-3)
  BLOB_SCHEMA_VERSION:                     2,
  CONSISTENCY_CHECK_INTERVAL_HOURS:       24,
} as const

DAnhang D — Frontend-Anpassungspunkte

Stand der HTML-Dateien nach I16: HTML/greenPoker_v45.9.html, HTML/greenPokerAdmin_v44.26.html.

D.1 — Spieler-Frontend

D.2 — Admin-Frontend

EAnhang E — Übergabe-Logs der abgeschlossenen Iterationen