3 files changed, 103 insertions, 0 deletions

diff --git a/docs/GAMES.md b/docs/GAMES.md
new file mode 100644
index 0000000..cbe355e
--- /dev/null
+++ b/docs/GAMES.md
@@ -0,0 +1,74 @@
+# Games and the play audit
+
+## Implemented
+
+| Game | Status | Notes |
+| --- | --- | --- |
+| Slots | Done | 5 reels x 3 rows, 5 paylines, 98.6% RTP |
+
+## Planned
+
+| Game | Shape | Main open decisions |
+| --- | --- | --- |
+| Roulette | One spin, many bets | European/French/American wheel; which bet types; 35:1 straight and other payouts |
+| Blackjack | Multi-step hand | Dealer hits/stands soft 17; double/split/insurance; blackjack payout; shoe persistence |
+| Crash | Real-time round | Crash-point distribution; cashout latency; provable fairness |
+
+Roulette fits the current one-request-settle model most easily. Blackjack needs
+server-side hand state and player actions. Crash needs a timed round loop and a
+cashout action, so it should come last unless we redesign the loop first.
+
+## Audit schema
+
+Every settled play is one row in `plays`:
+
+```
+plays (
+    session_id TEXT PRIMARY KEY,
+    username TEXT NOT NULL,
+    game_type TEXT NOT NULL,
+    bet_amount INTEGER NOT NULL,
+    winnings INTEGER NOT NULL,
+    balance_after INTEGER NOT NULL,
+    details TEXT NOT NULL DEFAULT '{}',
+    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
+)
+```
+
+`game_type` is the game that was played. `details` is a JSON object whose shape
+depends on the game:
+
+```json
+// slots
+{"reels":"CCCCLLCLODGSDGS","win_type":"win","win_lines":"1","win_cells":"0,3,6"}
+
+// rumoured future examples
+{"player":["AS","10H"],"dealer":["9D","7C"],"outcome":"blackjack"}
+{"bets":[{"kind":"straight","number":17,"amount":10}],"winning":17}
+{"crash_point":2.41,"cashout":1.80}
+```
+
+The balance updates and the `plays` insert happen in one transaction
+(`database::apply_play`). The slots-specific wire fields (`reels`, `win_lines`,
+`win_cells`) are still in `GAME_RESULT`, but the database no longer assumes
+them.
+
+## Protocol gap
+
+The current exchange is slots-shaped:
+
+```
+PLAY_START <game> <bet>
+GAME_RESULT <session> <winnings> <bet> <balance> <reels> <win_type> <win_lines> <win_cells>
+```
+
+Before blackjack, roulette, or crash can be added, the game session needs a
+generic state/action protocol. A possible shape:
+
+```
+GAME_START <game> <bet>
+GAME_ACTION <action> [json]
+GAME_STATE <json>          # cards, bets, multiplier, legal actions, result
+```
+
+That is a wire-protocol change and will be its own major version.
diff --git a/docs/SERVER_SETUP.md b/docs/SERVER_SETUP.md
index e2f3177..62d1a9c 100644
--- a/docs/SERVER_SETUP.md
+++ b/docs/SERVER_SETUP.md
@@ -69,6 +69,22 @@ On first contact the client prints the SPKI fingerprint and pins it. If you
 regenerate the server identity, the client will reject the new key; run
 `forget-host` in the client if the change is intentional.
 
+## Database
+
+The server creates `server.db` in the current directory on first use. It holds
+users, balances, and the per-game `plays` audit. The client keeps its own
+`client.db` for host fingerprints and stored credentials.
+
+During development, delete both files to reset users, balances, history, and
+trust:
+
+```sh
+rm -f server.db client.db
+```
+
+The `plays` schema is not auto-migrated from the old slots-only shape; a stale
+database must be removed.
+
 ## Windows
 
 `--init` shells out to `openssl`, so OpenSSL must be installed and on `PATH`
diff --git a/docs/TESTING.md b/docs/TESTING.md
index 2a3572d..4d46855 100644
--- a/docs/TESTING.md
+++ b/docs/TESTING.md
@@ -23,6 +23,19 @@ shared global database. Each test owns its state.
 `tests/tofu.rs` and `tests/server_setup.rs` shell out to `openssl`, so run them
 on a machine where the `openssl` CLI is available.
 
+## Development resets
+
+The server creates `server.db` in its working directory; the client creates
+`client.db` for host trust and stored credentials. While the software is in
+testing, delete both after a schema or trust change:
+
+```sh
+rm -f server.db client.db
+```
+
+The audit schema is not auto-migrated from the pre-2.0 slots-only `plays`
+table. Starting against an old database will fail until it is removed.
+
 ## Manual TUI checklist
 
 There is no CI. Run this on Linux and on a Windows VM before a release.