diff --git a/Poker-texas-holdem.md b/Poker-texas-holdem.md
new file mode 100644
index 0000000..e558de9
--- /dev/null
+++ b/Poker-texas-holdem.md
@@ -0,0 +1,551 @@
+# Poker-Plattform Architektur-Dokumentation
+
+## 1. Ziel des Projekts
+
+Dieses Projekt ist eine Online-Poker-Plattform als Desktop-Anwendung mit `WPF` auf dem Client.  
+Die Anwendung soll mehrere Benutzer unterstuetzen, die sich registrieren, einloggen, Freunde verwalten, private Lobbys erstellen und gemeinsam Texas Hold'em spielen koennen.
+
+Die Architektur ist so ausgelegt, dass sie fuer ein MVP einfach genug bleibt, aber spaeter um weitere Features wie Ranking, Store, Matchmaking, Mini-Chat und erweiterte Profile erweitert werden kann.
+
+## 2. Hauptanforderungen
+
+### Must have
+
+- Registrierung
+- Login
+- Friendship Request
+- Erstellung von privaten Lobbys
+- Poker-Gameplay
+- vorbereitetes Monetization-System
+- Logging-System
+- Notification-System
+
+### Nice to have
+
+- Ranking-System
+- Mini-Chat
+- App-Settings
+- Matchmaking
+- Advanced Profile
+- Store
+
+## 3. Technologie-Stack
+
+### Client
+
+- `WPF`
+- `SignalR Client`
+
+### Server
+
+- `ASP.NET Core`
+- `SignalR`
+- C# Service- und Business-Logik
+
+### Datenzugriff
+
+- `ADO.NET`
+- `Microsoft.Data.SqlClient`
+
+### Datenbank
+
+- `SQL Server`
+
+## 4. Grundidee der Architektur
+
+Die Anwendung besteht aus drei Hauptteilen:
+
+1. `WPF Client`
+2. `Serverprozess`
+3. `SQL Server`
+
+### 4.1 WPF Client
+
+Der Client ist nur fuer die Darstellung und Benutzerinteraktion verantwortlich.
+
+Aufgaben des Clients:
+
+- Login- und Registrierungsoberflaechen anzeigen
+- Freundesliste und Freundschaftsanfragen darstellen
+- private Lobbys anzeigen und verwalten
+- Pokertisch visualisieren
+- Spieleraktionen an den Server senden
+- Benachrichtigungen live anzeigen
+
+Der Client darf keine kritischen Spielregeln selbst kontrollieren.  
+Er zeigt nur Daten an und sendet Benutzerabsichten wie `Raise`, `Call`, `Fold` oder `Lobby erstellen`.
+
+### 4.2 Serverprozess
+
+Der Serverprozess ist das zentrale Gehirn der Anwendung.
+
+Er enthaelt:
+
+- Session-Logik
+- Social-Logik
+- Lobby-Logik
+- Poker-Logik
+- Notification-Logik
+- Logging-Logik
+- Repository-Zugriffe auf SQL Server
+
+Der Server:
+
+- nimmt Anfragen vom Client entgegen
+- prueft Regeln und Berechtigungen
+- liest und schreibt Daten in SQL Server
+- sendet Live-Updates ueber SignalR an alle relevanten Clients
+
+### 4.3 SQL Server
+
+SQL Server speichert den dauerhaften Zustand der Anwendung.
+
+Dazu gehoeren:
+
+- Benutzer
+- Sessions
+- Freundschaften
+- Lobbys
+- Pokerhaende
+- Handaktionen
+- Notifications
+- Wallet-Daten
+- Logs
+
+## 5. Warum kein direkter Vollzugriff des Clients auf die Datenbank?
+
+Auch wenn eine WPF-App technisch direkt mit einer Connection String an SQL Server verbunden werden kann, ist das fuer ein Online-Poker-System nicht die beste Loesung.
+
+Gruende:
+
+- Spielregeln koennen sonst leichter umgangen werden
+- Sicherheitslogik waere im Client sichtbar
+- Benutzer koennten gezielt Requests manipulieren
+- Turn-Order und Anti-Cheat werden schwieriger
+- Live-Funktionen wie Lobby-Updates und Notifications brauchen ohnehin einen Server
+
+Deshalb gilt in diesem Projekt:
+
+- `WPF` ist der Client
+- `ASP.NET Core + SignalR` ist der Serverteil
+- `ADO.NET` verbindet den Server mit `SQL Server`
+
+## 6. Geplante Solution-Struktur
+
+Empfohlene Projektaufteilung:
+
+### `Poker.Client`
+
+WPF-Anwendung mit:
+
+- Views
+- ViewModels
+- Client-Services fuer SignalR
+- UI-State
+
+### `Poker.Server`
+
+ASP.NET-Core-Anwendung mit:
+
+- REST-Endpunkten fuer normale Operationen
+- SignalR-Hubs fuer Echtzeitkommunikation
+- Services fuer Geschaeftslogik
+
+### `Poker.Core`
+
+Klassenbibliothek fuer Business-Logik:
+
+- Poker-Regeln
+- Lobby-Regeln
+- Social-Regeln
+- Session-Regeln
+- Notification-Regeln
+
+Diese Schicht soll moeglichst unabhaengig von UI und SQL bleiben.
+
+### `Poker.Data`
+
+Klassenbibliothek fuer Datenzugriff:
+
+- `SqlConnectionFactory`
+- Repositories
+- SQL-Statements
+- Mapper
+- Transaktionslogik
+
+### `Poker.Contracts`
+
+Gemeinsame DTOs und SignalR-Modelle zwischen Client und Server.
+
+## 7. Schichtenmodell
+
+### Client-Seite
+
+```text
+WPF UI
+-> ViewModel
+-> Client Service
+-> SignalR / HTTP
+```
+
+### Server-Seite
+
+```text
+Hub / Controller
+-> Application Service
+-> Domain Logic
+-> Repository
+-> SQL Server
+```
+
+## 8. Feature-Bereiche
+
+### 8.1 Registrierung und Login
+
+Der Benutzer kann:
+
+- ein Konto erstellen
+- sich einloggen
+- eine Session erhalten
+
+Serverseitige Aufgaben:
+
+- Benutzername und E-Mail pruefen
+- Passwort sicher hashen
+- Session erzeugen
+- Login-Audit loggen
+
+Empfohlene Tabellen:
+
+- `Users`
+- `UserSessions`
+
+### 8.2 Friendship Requests
+
+Ein Benutzer kann:
+
+- einen anderen Benutzer als Freund anfragen
+- Anfrage annehmen
+- Anfrage ablehnen
+- Freund entfernen
+
+Serverseitige Regeln:
+
+- keine Selbstanfrage
+- keine doppelten offenen Anfragen
+- keine doppelte Freundschaft
+
+Empfohlene Tabellen:
+
+- `FriendRequests`
+- `Friendships`
+
+### 8.3 Private Lobby
+
+Der Benutzer kann:
+
+- eine private Lobby erstellen
+- Freunde einladen
+- einer Einladung folgen
+- die Lobby verlassen
+
+Der Host kann:
+
+- Spiel starten
+- Lobby schliessen
+- Spieler verwalten
+
+Empfohlene Tabellen:
+
+- `Lobbies`
+- `LobbyMembers`
+- `LobbyInvites`
+
+### 8.4 Poker
+
+Poker wird serverautoritativ umgesetzt.
+
+Das bedeutet:
+
+- der Client schlaegt nur Aktionen vor
+- der Server entscheidet, ob die Aktion erlaubt ist
+- der Server aktualisiert die Hand
+- der Server broadcastet den neuen Zustand
+
+Erste Variante:
+
+- `No-Limit Texas Hold'em Cash Game`
+
+Wichtige Regeln:
+
+- korrekte Zugreihenfolge
+- Blind-Struktur
+- gueltige Aktionen pro Runde
+- Pot-Berechnung
+- Showdown
+
+Empfohlene Tabellen:
+
+- `Tables`
+- `Hands`
+- `HandPlayers`
+- `HandActions`
+
+### 8.5 Logging-System
+
+Es werden zwei Arten von Logging unterschieden:
+
+#### Technisches Logging
+
+Fuer Fehler, Exceptions, Performance und Diagnose.
+
+#### Fachliches Logging / Audit Logging
+
+Fuer wichtige Benutzer- und Spielfluss-Ereignisse:
+
+- Registrierung
+- Login
+- Freundschaftsanfrage
+- Lobby erstellt
+- Lobby beigetreten
+- Spiel gestartet
+- Pokeraktion ausgefuehrt
+
+Empfohlene Tabelle:
+
+- `AppLogs`
+
+### 8.6 Notification-System
+
+Benachrichtigungen werden in Echtzeit ueber `SignalR` verschickt und zusaetzlich in SQL gespeichert.
+
+Anwendungsfaelle:
+
+- Freundschaftsanfrage erhalten
+- Freundschaftsanfrage angenommen
+- Lobby-Einladung erhalten
+- Lobby-Status geaendert
+- Systemmeldung
+
+Empfohlene Tabelle:
+
+- `Notifications`
+
+### 8.7 Monetization-System
+
+Im MVP wird Monetization nur vorbereitet.
+
+Das bedeutet:
+
+- Soft Currency / Wallet-Struktur wird angelegt
+- Katalog und Kaufhistorie koennen spaeter erweitert werden
+- noch kein voller Store im ersten Release
+
+Empfohlene Tabellen:
+
+- `Wallets`
+- spaeter `CatalogItems`
+- spaeter `Purchases`
+- spaeter `InventoryItems`
+
+## 9. Kommunikationsarten
+
+### 9.1 REST / HTTP
+
+Wird fuer normale fachliche Operationen verwendet, die kein permanentes Live-Streaming brauchen.
+
+Beispiele:
+
+- Registrierung
+- Login
+- Freundesliste laden
+- Lobby erstellen
+- Profil laden
+- Settings speichern
+
+### 9.2 SignalR
+
+Wird fuer Echtzeitkommunikation verwendet.
+
+Beispiele:
+
+- Poker-Zuege
+- Lobby-Updates
+- Online-Status
+- Notifications
+
+## 10. Warum trotzdem HTTP/REST auch bei einer Desktop-App?
+
+Eine Desktop-App braucht kein Web-Frontend, kann aber trotzdem mit einem Server ueber HTTP sprechen.
+
+Wichtig:
+
+- `POST` und `GET` haben nichts mit Web-App oder Browser zu tun
+- sie werden nur dann gebraucht, wenn der Client mit einem Server kommuniziert
+
+In diesem Projekt ist das sinnvoll fuer:
+
+- Registrierung
+- Login
+- Daten laden
+- einfache CRUD-Vorgaenge
+
+SignalR ist zusaetzlich fuer Live-Kommunikation da.
+
+## 11. ADO.NET Repository-Schicht
+
+Die Datenbankzugriffe werden explizit mit `ADO.NET` umgesetzt.
+
+Verwendete Klassen:
+
+- `SqlConnection`
+- `SqlCommand`
+- `SqlDataReader`
+- `SqlTransaction`
+
+Wichtige Prinzipien:
+
+- nur parametrisierte SQL-Statements
+- keine Business-Logik in Repository-Klassen
+- jede komplexe Spielaenderung in einer Transaktion
+- Mapper trennen SQL-Daten von Domain-Objekten
+
+Beispielhafte Klassen:
+
+- `SqlConnectionFactory`
+- `UserRepository`
+- `SessionRepository`
+- `FriendshipRepository`
+- `LobbyRepository`
+- `HandRepository`
+- `NotificationRepository`
+- `WalletRepository`
+
+## 12. SignalR-Hubs
+
+### `PokerHub`
+
+Zustaendig fuer:
+
+- Tischstatus senden
+- Aktionen empfangen
+- Spiel-Updates broadcasten
+
+### `LobbyHub`
+
+Zustaendig fuer:
+
+- Lobby-Status
+- Beitritt / Austritt
+- Einladungen
+- Spielstart
+
+### `NotificationHub`
+
+Zustaendig fuer:
+
+- persoenliche Benutzer-Benachrichtigungen
+
+## 13. SQL-Server-Datenmodell
+
+### Pflichttabellen
+
+- `Users`
+- `UserSessions`
+- `FriendRequests`
+- `Friendships`
+- `Lobbies`
+- `LobbyMembers`
+- `LobbyInvites`
+- `Tables`
+- `Hands`
+- `HandPlayers`
+- `HandActions`
+- `Notifications`
+- `Wallets`
+- `AppLogs`
+
+### Wichtige SQL-Regeln
+
+- IDs als `BIGINT`
+- Geld- und Chipwerte als `INT`
+- Zeitstempel als `DATETIME2`
+- Indizes auf haeufig gesuchte Felder
+- Poker-Aktionen immer in `SqlTransaction`
+
+## 14. Sicherheitsprinzipien
+
+- Passwort nie im Klartext speichern
+- Hashing mit sicherem Verfahren wie `PBKDF2` oder `BCrypt`
+- keine DB-Credentials im Client hart codieren
+- keine kritischen Spielregeln im Client erzwingen
+- jede Spieleraktion serverseitig validieren
+- Sessions zeitlich begrenzen
+- Logging fuer sicherheitsrelevante Aktionen
+
+## 15. Erweiterbarkeit fuer spaetere Features
+
+Die Architektur wird so vorbereitet, dass diese Features spaeter sauber ergaenzt werden koennen:
+
+- Ranking-System
+- Mini-Chat
+- App-Settings
+- Matchmaking
+- Advanced Profile
+- Store
+
+Dafuer werden Datenmodell und Service-Grenzen so definiert, dass spaetere Erweiterungen nicht zu einem kompletten Umbau fuehren.
+
+## 16. Empfohlene Entwicklungsreihenfolge
+
+### Phase 1
+
+- Solution aufsetzen
+- SQL-Schema anlegen
+- ADO.NET Basis
+- Benutzer und Sessions
+
+### Phase 2
+
+- Registrierung und Login
+- Logging-Basis
+- Friendship Requests
+
+### Phase 3
+
+- private Lobby
+- Lobby-Invites
+- Notification-System
+
+### Phase 4
+
+- Poker-Spielregeln
+- Hand- und Aktionspersistenz
+- PokerHub
+
+### Phase 5
+
+- Wallet-Basis
+- vorbereitete Monetization-Struktur
+
+### Phase 6
+
+- Nice-to-have-Features vorbereiten oder schrittweise umsetzen
+
+## 17. Kurzfazit
+
+Die empfohlene Architektur fuer dieses Projekt lautet:
+
+- `WPF` fuer den Client
+- `ASP.NET Core + SignalR` fuer den Serverprozess
+- `ADO.NET` fuer die Datenbankzugriffe
+- `SQL Server` fuer dauerhafte Speicherung
+
+Damit bekommst du:
+
+- klare Trennung von UI, Logik und Daten
+- saubere Grundlage fuer Online-Multiplayer
+- gute Erweiterbarkeit
+- Kontrolle ueber SQL und Datenfluss
+
+Diese Architektur ist fuer dein Projekt deutlich sinnvoller als ein reiner Direktzugriff des WPF-Clients auf die Datenbank, weil Social-, Lobby-, Notification- und Poker-Logik zentral und sicherer gesteuert werden koennen.