# Datenbank für Demo-Runden

Eagle Rush überträgt abgeschlossene Engine-17/18/19/20/21/22/23/24/25/26/27/28/29-Runden einschließlich Erstattungen aus dem dauerhaften Browserjournal an `/api/telemetry`. Die Wallet bleibt die vorhandene lokale Demo-Wallet. Es entsteht kein Echtgeldkonto und keine serverseitig autorisierte Zufallsziehung. Frühere Engines und die anderen Spiele werden mit dieser Anbindung nicht rückwirkend importiert. Engine 29 hat eine eigene Modell-/Seedkennung; ältere Belege werden weiterhin mit ihrem historischen Modell geprüft.

## Inhalt und Identität

Der Browser erzeugt eine zufällige 256-Bit-Zugangkennung und speichert sie unter `nest-eagle-round-sync-v1`. Auf dem Server steht nur deren SHA256-Hash als Spielerkennung. Keine Namen, E-Mail-Adressen oder Zahlungskonten. Die Kennung authentifiziert die eigene Bilanz, nicht eine reale Person. Browserprofile beziehungsweise Geräte sind getrennte Spieler. Nach Löschen der Browserdaten ist die alte Zuordnung verloren; es gibt keine Kontowiederherstellung.

Gespeichert werden Runden-ID, Engine-/Mathematikversion, Testwährung, Einsatz und Auszahlung als ganze Cents, Kraft, interner Physikwinkel, Welt-/Finanzseed, Bedingungen-ID und Sequenz, Start-/Abschluss-/Empfangszeit, Erstattungs-/Recoverystatus und Prüfmethode. Der UI-Winkel hat das umgekehrte Vorzeichen zum gespeicherten Physikwinkel. Benutzerzeiten sind Browserangaben; die Empfangszeit kommt vom Server.

Der Server rechnet reguläre Runden mit begrenztem Rechenbudget nach und lehnt abweichende Auszahlungen ab. Das beweist die Konsistenz mit diesen Bedingungen, nicht deren serverseitige Herkunft, vollständige Meldung aller Browserrunden oder zertifizierten Zufall. Ein veränderter Client kann andere gültige Seeds erzeugen oder Belege verschweigen. Die Daten sind beobachtete Demo-Telemetrie, kein unabhängiger allgemeiner RTP-Nachweis.

`(dataset, player_id, round_id)` ist eindeutig. Wiederholungen desselben normalisierten Belegs liefern Erfolg, andere Belege derselben ID werden abgelehnt. Uploads verändern niemals Guthaben. Transportfehler lassen den Journalbeleg stehen; erneute Übertragung erfolgt mit wachsendem Abstand und nach Wiederverbindung. Dauerhafte Validierungsfehler werden sichtbar als zu prüfende Belege markiert. Bei beschädigter Kennung wird keine Ersatzidentität erzeugt. Die Bestätigungsliste wächst wie das bestehende Journal; Speichergrenzen bleiben möglich.

Keine automatische Löschfrist für Rundendaten in dieser Demo. Der Betreiber kann Belege nach Spielerhash in der Datenbank löschen. Zugangstoken und Servergeheimnisse gehören nicht in Tickets, Git oder öffentliche Dateien. Die Missbrauchsbremse speichert kurzzeitig nur einen Adresshash und Minutenbucket; alte Buckets werden bei folgenden Uploads entfernt. Höchstens 120 Uploadanfragen je Adresse/Minute, vier Runden je Anfrage und 64 KiB Nutzdaten. Vorschauen erhalten keine Produktionszugangsdaten; Entwicklung und Produktion werden zusätzlich im Schema getrennt.

## Besuche und Langzeitverlauf

Landingpage, Lobby, Eagle Rush und die getrennte3D-Demo melden Seitenaufrufe über dieselbe vorhandene Browserkennung. `eagle_visits_v1` speichert Seitenpfad, zufällige Besuchs-ID, Empfangszeit und optional einen HMAC-SHA256 der normalisierten IP-Adresse. Der zufällige Serverwert `EAGLE_VISITOR_HASH_KEY` bleibt ausschließlich als Vercel-Secret in Production; Entwicklungswerte sind getrennt. Kein Roh-IP-Eintrag in dieser Analysedatenbank. Ein Schlüsselwechsel trennt alte und neue Adressgruppen. Fehlender Schlüssel verhindert nur die IP-Gruppierung, nicht Rundenspeicherung oder Besuche.

IP-Adressen sind keine Personen: Haushalte können eine Adresse teilen, Mobilgeräte können wechseln, gelöschte Browserdaten verlieren ihre Zuordnung. Unterschiedliche Browserkennungen werden deshalb auch bei gleicher IP nicht zu einer Wallet zusammengeführt. GET zeigt nur die eigene Zusammenfassung; die globale Browser-/Adressanzahl bleibt hinter dem bestehenden Betreiberzugang. Besuche sind wiederholbar durch ihre eindeutigeID, ohne Doppelzählung derselben Meldung. Auch hier gibt es keine automatische Löschfrist; gezielte Löschung erfolgt durch den Betreiber in der Datenbank. Plattform-/Hostingprotokolle sind unabhängig von dieser Anwendung.

Eigene Langzeitsummen umfassen alle gespeicherten Eagle-Rush-Versionen, getrennt nach Testwährung. Tageswerte verwenden das UTC-Abschlussdatum; die Oberfläche zeigt die jüngsten sieben Tage, ältere bleiben gespeichert. Die Statistik beginnt nicht täglich neu. Aufladungen und tägliche Gratis-Credits zählen nicht als Auszahlungen. Ein großer Gewinn an einem Tag verändert weder die Chance noch Auszahlung an späteren Tagen. Es gibt keine persönliche Gewinnsperre, feste Verlustschuld oder nachträgliche96%-Angleichung.

## Auswertung und 96-%-Ziel

RTP = Summe der Bruttoauszahlungen / Summe der belasteten Einsätze. Nettogewinn/-verlust = Auszahlung − Einsatz. Teilrückzahlung kann Verlust bedeuten; genau der Einsatz ist unentschieden. Erstattungen sind separat und aus RTP und Gewinn-/Verlustzahlen ausgeschlossen. Bonus und Aufladungen sind keine Auszahlungen. Centaggregate bleiben auch oberhalb der sicheren JavaScript-Ganzzahlgrenze als Dezimalstrings exakt.

Die Auswertung trennt Mathematikversion und Währung; der Betreiberbericht zusätzlich Kraft, Winkel und Einsatz. Der Rückfluss selbst gewählter Einstellungen ist kein gleichgewichtetes 171-Zellen-Raster. Der Bericht zeigt das deskriptive gleichgewichtete Zellmittel erst bei vollständiger Rasterabdeckung und weist die kleinste Zellstichprobe aus. Auch vollständige beobachtete Abdeckung beseitigt Selektion anhand der sichtbaren Welt nicht.

Kein Rückkanal aus Spielerbilanzen in Zufall, Welt, Physik oder Auszahlung. Keine individuelle Verlustkompensation oder nachträglicher Faktor. Daten helfen, überzahlende oder schlecht abgedeckte Einstellungen zu finden. Änderungen erfolgen gemeinsam an versionierten sichtbaren Modellparametern und werden mit frischem Seed-Namespace separat geprüft. Historische Belege behalten ihre Regeln. `targetVerified: false` bleibt stehen. Aktuelle Engine-29-Messungen und Grenzen: [HYBRID_FLIGHT.md](HYBRID_FLIGHT.md).

## Betrieb

Cloudbetrieb: Neon Postgres `eagle-rush-rounds` am bestehenden Vercel-Projekt `eagle-rush`, Free-Tarif, Frankfurt. Die Verbindung wurde mit echten Schreibvorgängen im getrennten Entwicklungsbestand geprüft. `DATABASE_URL` bleibt ausschließlich serverseitig. Die native HTTPS-SQL-Schnittstelle verwendet gebundene Parameter; keine zusätzliche Laufzeitabhängigkeit. Schema und Indizes werden beim ersten Zugriff idempotent angelegt. Keine lokale SQLite-Datei als Cloudspeicher verwenden.

Lokal kann Node 24 mit `EAGLE_DB_PROVIDER=sqlite` und optional `EAGLE_SQLITE_PATH` in der ignorierten `.env.local` SQLite unter `.artifacts/eagle-rounds.sqlite` öffnen. Ohne SQLite-Option wird die Neon-Entwicklungsverbindung verwendet. Ohne Konfiguration liefert die API 503; die Demo-Wallet funktioniert weiter. Der Server lädt `.env.local`, blockiert Serverquellen und versteckte Dateien. Der statische Build schließt `src/server/` aus. Das eigenständige ZIP enthält keinen Backenddienst oder Zugangsdaten; Synchronisierung benötigt die API desselben Ursprungs.

`GET /api/telemetry` mit Browser-Bearerkennung zeigt ausschließlich deren eigene aggregierte Bilanz. Der Transparenzdialog zeigt gespeicherte Adlerbilanz, Lebenszeit-/Tageswerte und Verbindung. `POST` nimmt maximal vier geschlossene Journalbelege entgegen. Keine öffentliche Spielerliste.

`npm run db:report` liest Entwicklungsdaten, `npm run db:report -- --production` den Produktionsbestand, jeweils mit Modell-/Währungs-/Zielwahlgruppen. Produktionszugangsdaten dafür gezielt lokal bereitstellen. Optional schützt `EAGLE_ANALYTICS_KEY` (mindestens 32 Zeichen, zufälliger Serverwert) den globalen Bericht `GET /api/telemetry?action=report&byAim=1`. Ohne Schlüssel bleibt der globale HTTP-Bericht gesperrt. Niemals an Spielclients ausliefern.

Reale Einrichtung, Prüfung und Veröffentlichung stehen mit tatsächlichem Status in COMMUNICATION_FILE.md. Vor Abschluss keine Online-Aktivierung behaupten.