Roadmap

Modi und Bildschirme

• Kill Confirmed, Respawn und Leben und Check-in lesen signierte NFC-Tags der Spielenden.
• Das Medic-Kit: Wer getroffen wurde, scannt den eigenen Tag und hält einen Knopf, um geheilt zu werden, mit einer begrenzten Zahl an Heilungen.
• Money Factory: Fabriken machen Geld, solange ein Team sie hält; wer spielt, sammelt es mit dem eigenen Tag ein und zahlt es an einer anderen Box ein, und der Controller merkt sich, was jede Person trägt.
• Modus-Bildschirme in YAML beschrieben, von Field Box und App gleich gezeichnet.

Spielende und Marshals

• Spielende checken am Feld ein, indem sie einen gedruckten Aushang scannen (kein Konto, kein Internet), geben an, welche Repliken sie nutzen, und sehen, ob sie den Chrono bestanden haben.
• Chrono beim Check-in: Energie, Limits pro Klasse, Stichproben, Messwerte von Marshal signiert. Marshals arbeiten die Liste „Repliken zum Chronen“ ab, und ihre signierten Messwerte markieren jede Replik als bestanden oder abgelehnt; sie haben auch das Replik-Register und die Tags der Spielenden.
• Spielende können während eines Spiels ihre Position teilen, und der Controller entscheidet, wer sie sieht.
• Ein Feld oder Club mit eigenem Controller kann sein Logo, Hintergrundbild und seine Farbe in der App, auf der Anzeigetafel und auf dem Aushang zeigen und seinen Teams Namen und Wappen geben.
• Die Konsole der Orga meldet, wenn sich der Check-in-Aushang nach dem Druck geändert hat.
• Die Marshal- und Chrono-Bildschirme sagen, was die App wirklich tut, und die Limitlisten sind übersetzt.
• Die App hält mehr ihrer Geheimnisse mit dem Android Keystore versiegelt: den Schlüssel des Site-Servers, die Geheimnisse der Spieler und die Anmeldung am Site-Server.
• Die NFC-Tags der Spielenden werden vom Feld-Controller signiert und von der Konsole der Orga, dem Handy-Controller oder der Marshal-App geschrieben. Marshals halten dafür den Feldschlüssel nicht mehr.
• Replik-Labels: Die App zeigt, teilt oder druckt den QR-Aufkleber jeder Replik, und die Konsole druckt sie für alle, die eingecheckt sind. Die Warteschlange der Marshals scannt sie.
• Positionen in Gebäuden: Die Spielleitung setzt BLE-Beacons auf den Plan, und ein Handy, das eines hört, meldet seinen Raum statt GPS. Unter Android in Software und mit Attrappen, nicht mit echten Beacons ausprobiert. Auf einem iPhone leistet ein Plugin über Apples CoreLocation dasselbe, solange die App im Vordergrund ist (sonst GPS und die letzte Etage); es ist gebaut und kompiliert in der CI, und auf einem iPhone ist es nicht ausprobiert.
• Die App folgt einem Spiel über den QR-Code der Anzeigetafel, auch wenn der Handy-Controller HTTPS mit seiner eigenen Feld-CA anbietet. In Software, nicht an einem echten Handy ausprobiert.
• Spielende sagen, auf welcher Ebene sie sind, und sehen den Feldplan mit den Positionen, die sie sehen dürfen.
• Spielverlauf in der App: die Spiele, an denen jemand teilgenommen hat, das neueste zuerst.
• Anmeldung mit Google, Microsoft, Apple oder einem Passkey in der App, mit einem Kontobildschirm. Android und, in Swift, auch iOS (der Browser der Social-Anmeldung als ASWebAuthenticationSession, Passkeys über Apples Plattform-Zugangsdaten; Passkeys unter iOS sind beim Bauen optional zuzuschalten und brauchen das kostenpflichtige Apple-Programm). Der iOS-Teil wird in der CI kompiliert und ist auf einem iPhone nicht ausgeführt worden; die Anmeldung der App ist auf einem echten Handy nicht ausprobiert (die Seite des Site-Servers wurde mit Google und Microsoft ausprobiert, siehe Phase 4).
• Der Feldplan des Spielers kann das Raster des Feldes und die eigene Zelle des Spielers zeigen.
• Schiedsrichter können beim Registrieren einen NFC-Sticker an eine Replik binden.
• Das Handy eines Marshals behält den Beitrittsschlüssel des Feldes nicht mehr: nur ein Prop (seine Beitrittskarte) und der Handy-Controller tun das, und ein Update löscht ihn vom Handy eines Marshals.
• Scoreboard-Links, die die eigene CA des Feldes festlegen, werden pro Feld gemerkt und vergessen, wenn sich die CA ändert.
• Solange ein laufendes Spiel in der Spielendenansicht offen ist, hält ein Android-Vordergrunddienst mit einer Benachrichtigung die App am Laufen, damit das Vibrieren auch bei geschlossener App oder ausgeschaltetem Bildschirm kommt. Nicht auf iOS. Nicht auf einem echten Handy probiert.
• Die Field Boxen zählen als Beacons: Eine platzierte Box registriert sich als Beacon neben denen der Spielleitung, und ein Handy, das schon teilt, übernimmt Änderungen am Verzeichnis während des Spiels. In Software, nicht mit einem Handy und einer echten Box ausprobiert.
• Die Datenschutzerklärung in der App: eine Aufforderung Lesen und bestätigen, wenn dem Konto zuletzt eine andere Version gezeigt wurde, die Erklärung in der Sprache der App, nichts wird blockiert. Die App kann ein Konto anlegen (mit Passwort oder per Social Login), nachdem sie den Hinweis gezeigt hat, mit dem Feld „Ich bin 16 oder älter“; Jüngere checken am Spielfeld ohne Konto ein. Eine Registrierung per Social Login trägt die Version der Erklärung, die die Person sah, und eine Anmeldung funktioniert weiter mit einem älteren selbst betriebenen Server. Der Chrono-Link zwischen den Feldern eines gehosteten Hubs (ein Einmalcode) erscheint nur im gehosteten Modus. In Software.
• Die Kartenprüfung beim Check-in: Prüft das Feld die Mitgliedschaft, bleibt ein Check-in offen, bis eine Marshal-Person oder die GM mit der echten Karte in der Hand „Karte gesehen, stimmt“ ankreuzt; die Mitgliedsnummer wird dann auf dem Controller gelöscht (Ergebnis und Ablaufdatum bleiben), und ohne Karte lässt sich jemand trotzdem durchwinken, mit Begründung im Protokoll und nie mit der Nummer. In der Konsole, in der Marshal-Warteschlange der App und in beiden Controllern. Nur Software.
• Das Teilen der Position ist beim Check-in eine eigene, nicht vorangekreuzte Wahl (in der App und beim Handeintrag der Konsole), mit der Angabe, wer sie sieht; Ablehnen verhindert weder den Check-in noch das Spiel, und jede Person kann sie jederzeit ein- oder ausschalten. Ohne sie lehnt der Controller die Positionen ab. Nur Software.
• Das Sicherheits-Review der App: Eine angeheftete Feld-CA ist genau ein Zertifikat, kein App-weites unverschlüsseltes HTTP auf Android (nur Loopback, der Host des Emulators, 192.168.4.1 und atalaia.local), eine Release-APK, die nie aus Versehen mit dem Debug-Schlüssel signiert wird, und ein Ticket der Social-Anmeldung, das an die App-Instanz gebunden ist. Auf einem echten Handy nicht ausprobiert; den Signaturschlüssel für Releases muss der Maintainer noch erzeugen.
• Die Ereignisliste und der Spielverlauf der Spielenden lassen Routine-Ereignisse ohne Text für Spielende weg (eine Box, die ihr Setup bestätigt, Nodes online oder offline, Tag-Scans, Treffer auf Ziele), statt rohe Typnamen zu zeigen.

Android-Props und I/O-Pod

• Ein Android-Prop nimmt am Spiel des Controllers über das WLAN des Felds teil, oder über seinen Funk mit einem I/O-Pod.
• Die Firmware des Pods leiht dem Handy per USB oder Bluetooth die Team-Knöpfe, das Tastenfeld, die Lichter, die Sirene, den NFC-Leser, den Gehäuseschalter und den LoRa-Funk eines Heltec-Boards.
• Die App verbindet sich mit einem verlorenen I/O-Pod von selbst wieder. Nicht mit einem echten Pod ausprobiert.
• Android-Props holen signierte Modus-Pakete von ihrem Controller, wie die Boxen. In Software.
• Die GM-Konsole kann die Einstellungen eines I/O-Pods per Funk schicken: die Farben der vier Knöpfe, die Helligkeit des LED-Rings, die Lautstärke und ob der Gehäuseschalter meldet. Der Pod prüft den Befehl wie jeden anderen, speichert die Einstellungen in seinem Flash und antwortet; der Controller sendet ihn erneut, bis er eine Antwort hört. Vorher wurden sie beim Bauen der Firmware festgelegt. In Software und gegen den Code des Pods auf einem Computer, nicht mit einem echten Pod probiert.
• Die Strafe einer Box eines Android-Props erreicht den Controller jetzt, über die WLAN-Verbindung und die Funkverbindung. In Software.

Das Handy als Feld-Controller

• Die Spiel-Engine, mit field.lua eines Modus auf dem gemeinsamen Kern, einem MQTT-Broker und einem Positionsfilter; die REST-API, der Live-Stream und die MQTT-Topics; Spiele über einen Neustart hinweg; Beitritts-Payloads.
• Android-Props in seinem WLAN, ein I/O-Pod als sein Funk, der Check-in am Feld mit Spieler-Tokens, die Liste „Repliken zum Chronen“ und die Positionen der Spielenden. Geprüft mit denselben Vertragsfällen wie der Pi-Controller und ausgeführt mit dem Code von Pod und Field Box auf einem Computer.
• Sein Bildschirm: die Rolle auf dem Startbildschirm der App, auch bei ausgeschaltetem Bildschirm weiterlaufend, die GM-Konsole aus der App ausgeliefert und HTTPS mit einer Feld-CA, die auf dem Handy erzeugt wird.
• Der Feldplan (ein Plan pro Ebene, seine Kartenposition, Kartenobjekte mit der Feldgrenze, das aus einer Karte geladene Feld, sodass die Warnung beim Verlassen der Grenze dort auch funktioniert) und der Funkkanal, mit der Suche nach einem ruhigen Kanal über den I/O-Pod.
• Die Boxen über Funk: versiegelte Einladungen ins nächste Spiel; das Spielende, den Boxen mitgeteilt, auch wenn das Handy ohne den Spielschlüssel neu gestartet wurde; neue Boxen, aufgenommen über den Code, den sie zeigen, oder über eine Feldkarte, die das Handy per NFC schreibt; Firmware-Updates zwischen den Spielen, über den I/O-Pod oder das USB-Funkmodem des Pi, und das Handy sagt, warum, wenn sein Funk sie nicht tragen kann.
• Presets, Modus-Uploads und signierte Modus-Pakete, an Boxen geschickt, denen sie fehlen; auf dem Handy kompilierte Szenarien; Rollenpakete in einem Spiel; Teamnamen und Wappen.
• Auch alles Übrige, was der Pi kann: Failover (ein Handy und ein Pi können gegenseitig ihre Reserve sein), der Sync mit dem Site-Server (Spiele, Logs und Punkte gehen raus, wenn Internet da ist; Anmeldelisten, Branding und Szenario-Bibliothek kommen von dort), die Remote-Spielleitung und der ATAK-Feed.
• Die Konsole der Orga passt auf ein Handy: Check-in- und Marshal-Tabellen stapeln sich, ohne seitliches Scrollen.
• Der eigene Bildschirm des Handy-Controllers importiert eine Anmeldeliste (eine CSV- oder JSON-Datei, gewählt mit der Dateiauswahl von Android), ganz ohne GM-Konsole.
• Ein Bereitschafts-Controller übernimmt die Beacon-Einstellungen der Boxen (den Feldschalter, die abgeschalteten Boxen, die Räume) und die Plätze der Boxen aus seinem Beitritt, sodass Handys nach einem Failover dasselbe Beacon-Verzeichnis bekommen; eine Konsole, die auf dem Bereitschafts-Controller schon offen ist, verschiebt die Marker der Boxen sofort, ohne Neuladen. In Software, in beiden Controllern; die Verschiebung der Marker ist in einem Headless-Browser getestet.
• Der Handy-Controller zieht mit der Sicherheitsprüfung des Pi-Controllers gleich: Der Widerruf signierter Modi schlägt sicher fehl (mit einer Untergrenze je Modus und einer Altersgrenze für ein Handy ohne Netz, beides im Bildschirm Modus-Pakete), und der ATAK-Feed für die Spielleitung läuft über TLS mit einer festgelegten Zertifizierungsstelle. In Software getestet; nicht auf einem Handy im Feld.

iOS

• Das Projekt liegt im Repository, die CI baut es auf einem Mac, und es lief schon auf einem iPhone.
• Am 26.10.2026 bestand seine Checkliste auf dem Gerät auf einem iPhone: 12 automatische Prüfungen und, von Hand, QR-Scannen mit der Kamera, Check-in mit dem Aushang des Felds über HTTPS, Positionsfreigabe bei sichtbarer App, die Warnung beim Verlassen der Grenze mit ihrer Vibration und atalaia://-Links.
• Beacons in Gebäuden: ein Swift-Plugin über CoreLocation, auf denselben Kanälen wie unter Android, braucht nur die Ortungserlaubnis und funktioniert, solange die App im Vordergrund ist. Es kompiliert in der CI; auf einem iPhone ist es noch nicht gelaufen.

Modi

• Master und Satelliten: Satelliten, die man mit dem Master hält, erhöhen seine Punkte; wechselt der Master den Besitzer, werden sie frei.
• Das Hacking-Terminal: ein Rätsel am Tastenfeld, das einen Code verrät oder das Terminal erobert.
• VIP / Payload: Ein Team eskortiert seinen VIP oder ein Handy mit GPS zu einer Extraktionszone; Checkpoint-Boxen punkten, solange sie gehalten werden; Positionen bleiben auf dem Feld-Controller und dem Handy.
• Die Regeln von Zielfenster: Ein Treffer, während das Ziel die Farbe eines Teams zeigt, punktet für dieses Team. Das Ziel-Addon ist noch nicht gebaut.
• Geo-Funktionen im Kern: Entfernungen und Zonen für jedes Skript, auf jeder Plattform identisch.

Eigene Szenarien

• Die Laufzeit: Ein Szenario läuft auf dem Feld-Controller und sagt den Boxen des eingebauten Ziele-Pakets, was sie sind (ein Punkt zum Erobern, ein Code, Tags oder Karten zum Scannen, ein Bombenplatz); sie melden, das Szenario punktet.
• Der Compiler: ein YAML-Szenario mit sieben Zieltypen, mit Abhängigkeiten, Enthüllungen und Zeitfenstern, geprüft mit jedem Problem verortet und erklärt, und von der Kommandozeile kompiliert.
• In der GM-Konsole: ein Editor, der jedes Problem auflistet, während die Orga tippt, und das Szenario installiert; die Boxen bekommen die Namen des Szenarios beim Beitritt.
• In der App: Spielende sehen die Ziele, die für sie gedacht sind, mit Namen und Stand, ein verstecktes erst nach der Enthüllung; jeder Squad kann seine eigene Kette haben, ein Ziel nach dem anderen, dem ganzen Squad oder nur dem Squad-Lead gesagt.

ATAK und die Feldkarte

• Der ATAK-Feed: Boxen und Zonen auf ATAK-Karten über das Feld-WLAN, in den Farben ihrer Besitzer, platziert, indem man zwei Ecken des Feldbilds ihre Kartenposition gibt.
• Die Spielleitung markiert Sicherheitszonen, Respawn und HQ jedes Teams, den Parkplatz, Erste Hilfe und Ziele auf dem Plan des Felds, als Pin, Kreis oder Fläche, jedes für alle, für ein Team oder nur für die Orga sichtbar, in der Konsole und auf ATAK.
• Das Feld lässt sich aus einer Karte laden: Die Spielleitung findet es von ihrem Standort oder über einen Ortsnamen und zeichnet seinen Umriss auf OpenStreetMap, und der Browser zeichnet das Feldbild aus den Daten von OpenStreetMap über den offenen Luftbildern des Landes (das portugiesische Festland, Spanien, Frankreich samt Übersee, die Niederlande, Belgien, Luxemburg, die Schweiz, Liechtenstein, elf deutsche Länder, Polen und Tschechien). Der Umriss wird zur Feldgrenze, das Außen abgedunkelt.
• Die Handys der Spielenden warnen mit einem Banner und einer Vibration, wenn sie die Grenze verlassen, mit ihrem eigenen GPS, ohne etwas zu senden.
• Spielerpositionen gehen nie an alle, nur an Staff-Geräte, wenn das Feld es einschaltet. Staff außerhalb des Felds bekommt dasselbe über den Site-Server, über eine verschlüsselte Verbindung mit einem Zertifikat pro Gerät, das das Feld ausstellt und sofort widerrufen kann; Positionen gehen nur an Zertifikate von Spielleitung oder Marshals.
• Mehrstöckige Felder in der Konsole: ein Grundriss pro Ebene und jede Box auf ihrer Ebene.
• Noch nicht mit einem echten ATAK-Handy ausprobiert, auch nicht auf einem echten Feld.
• Eine Box, die Progressive Domination zur aktiven gemacht hat, sagt das auf ATAK.
• Die Feldkarten-Seite läuft auch auf dem Handy als Feld-Controller.
• ATAK zeigt Spielende in Gebäuden am Ort ihres Beacons, mit dem Raum in den Bemerkungen.
• Das Raster in ATAK und eine druckbare Rasterkarte.
• Der Remote-GM sieht die Positionen der Spieler, wenn sie sie teilen.
• ATAK-Gerätezertifikate gelten 90 Tage (vorher 7), und die ATAK-Seite für die Mitarbeitenden warnt, wenn eines in 14 Tagen abläuft.
• Das Feld kann das Laden von Karten in der Konsole abschalten (Einstellungen, Kartenabruf): dann erreicht „Feld aus einer Karte laden“ weder OpenStreetMap noch Overpass, Nominatim oder die Luftbilder. Standardmäßig an.

Site-Server, Konten und Daten

• Sein Gerüst: Datenbank, Migrationen und ein Health-Check, in einem eigenen Container.
• Konten: Passwörter, Zwei-Faktor-Codes Pflicht für Orga und Marshals, Sitzungen und Rollen pro Feld.
• Rechte an persönlichen Daten: Auskunft, Export, Berichtigung, Löschung, Einwilligungsnachweise und eine tägliche Löschung nach Aufbewahrungsfrist.
• Controller-Sync: Feld-Controller schieben ihre Spiele, Logs und Punkte, offline zuerst und gefahrlos wiederholbar. Noch nicht über eine echte 4G-Verbindung.
• Das Chrono-Register: signierte Messwerte geprüft und so gespeichert, wie sie signiert wurden, nur öffentliche Schlüssel, Austausch zwischen Feldern mit Einwilligung. Noch nicht mit einem echten Chronographen.
• reset-totp: Der Betreiber setzt den Zwei-Faktor-Code eines Kontos zurück, das seinen Authenticator verloren hat.
• Feld-Controller holen die Chrono-Messwerte anderer Felder für die Spielenden auf ihrer Liste, nur mit der Einwilligung jeder Person. Sie halten sie getrennt von den eigenen Messwerten und bewerten sie nie.
• Die Controller holen die Einstellungen und das Erscheinungsbild des Felds vom Site-Server, und eine Änderung kommt sofort beim Pi und beim Handy-Controller an. In Software.
• Anmeldung mit Google, Microsoft oder Apple und mit Passkeys. Passwörter sind optional; das Personal braucht weiterhin einen zweiten Faktor. Google und Microsoft wurden auf dem Testserver (tests.atalaia-project.link) mit den echten Anbietern ausprobiert; Apple noch nicht.
• Eine Kontoseite für das Personal, auf der jede Person ihre eigenen Anmeldungen verwaltet: Passkeys, verknüpfte Konten, Passwort und Zwei-Faktor-Code.
• Änderungen an Szenarien, Presets und Terminen erreichen die Controller sofort.
• Wie lange ein Feld Daten behält, ist eine Einstellung des Feldes: Spielverlauf und Chrono-Einträge haben je eine Aufbewahrungsdauer, einzustellen am Controller, in der GM-Konsole oder auf der Einstellungsseite des Site-Servers: der Spielverlauf standardmäßig 90 Tage (Teamergebnisse ohne Spieler-IDs 365), Chrono-Einträge 365. Die tägliche Bereinigung löscht ein beendetes Spiel dieses Alters, nie bevor der Site-Server alles davon hat. Das ungenutzte Aufbewahrungsfeld pro Konto ist weg.
• Die Löschung einer Person an einem Feld-Controller erreicht den Site-Server mit der nächsten Synchronisierung von selbst (nie mit einem Namen) und löscht dort auch die Chrono-Einträge dieser Person.
• Vorlagen für den Datenschutzhinweis, den Auftragsverarbeitungsvertrag und die Bedingungen für die Freigabe zwischen Feldern, auf Portugiesisch und Englisch (der Vertrag auch auf pt-PT), dazu eine Vorlage für die Datenschutz-Folgenabschätzung: Sie geben die Positionen wieder, die der Anwalt oder die Anwältin des Maintainers am 30. Oktober 2026 gebilligt hat (Konten auf Vertragsbasis mit Mindestalter 16, die Mitgliedskarte beim Check-in geprüft und die Nummer gelöscht, Verstöße aufgrund berechtigter Interessen, Positionsfreigabe per Einwilligung, kein Datenschutzbeauftragter). Weiterhin Vorlagen, die jedes Feld ausfüllt, keine Rechtsberatung für ein bestimmtes Feld.
• Der Site-Server veröffentlicht den Datenschutzhinweis, den der Betrieb ihm gibt, als Seite und über die API in vier Sprachen und zeigt ihn den Konten erneut, wenn sich seine Version ändert (ein Konto beruht auf dem Vertrag, nicht auf einer Einwilligung). Nichts wird gesperrt: Export und Löschung bleiben möglich. Auf einem Computer getestet.
• Ein Social-Login-Konto wählt seinen Benutzernamen auf der Kontoseite gleich nach dem Anlegen (überspringbar; der Name des Anbieters nur, wenn die Person es verlangt). Jedes Konto kann sich mit seiner eigenen Anmeldemethode umbenennen, und zwei Konten einer Person lassen sich zusammenführen, wenn die Person beide nachgewiesen hat (nie in ein Konto mit Personalrolle hinein oder aus ihm heraus). Der Fehler bei fehlender Einwilligung erscheint am Kontrollkästchen. Auf einem Computer getestet; der Schritt Benutzername und das Zusammenführen sind auf dem Testserver noch auszuprobieren.
• Eine Registrierung per Social Login hält die Version der Datenschutzerklärung fest, die die Person tatsächlich sah: Der Server lehnt eine veraltete ab und prüft vor dem Anlegen des Kontos noch einmal. Auf einem Computer getestet.
• Die tägliche Aufbewahrungsbereinigung löscht auch anonymisierte Konten (was eine Löschung oder ein Zusammenführen hinterlässt), sobald nichts mehr auf sie verweist. Auf einem Computer getestet.
• Wer die Anmeldung eines Kontos ändert, braucht einen zweiten Faktor: Passkeys hinzufügen, umbenennen oder entfernen, Zwei-Faktor-Codes einrichten oder abschalten, das Passwort ändern, eine Social-Anmeldung verknüpfen und ein Zusammenführen bestätigen werden abgelehnt, wenn die Sitzung keinen TOTP- oder Passkey-Schritt durchlaufen hat (eine Social-Anmeldung allein zählt nicht); ein Zusammenführen bringt nie Passkeys in ein Personalkonto. Die Kontoseite des Personals und die App fragen zuerst diesen Schritt ab. Auf einem Computer getestet, nicht bei den echten Anbietern.
• Das eigene Sicherheits-Review des Site-Servers: Anfragekörper begrenzt (413 ab 1 MiB, 4 MiB bei Uploads), dieselbe Antwort auf „kein solches Konto“ und auf eine abgelehnte Rollenvergabe, der Feld-Export mit nur den Audit-Zeilen des Feldes, der Schalter der öffentlichen Seite in der Feldsuche der App beachtet, eine Pflicht-URL, der Aussteller einer Social-Anmeldung zusammen mit ihrem Subjekt gespeichert, HTTP-Anfragen hinter einem Proxy auf HTTPS umgeleitet und ein Health-Check, der nur ok sagt. Zum Teil auf dem Preview-Server gefunden.
• Konten beruhen auf dem Vertrag, nicht auf einer Einwilligung: Bei der Anmeldung wird festgehalten, welche Version des Datenschutzhinweises gezeigt wurde, mit einem Kästchen „Ich bin 16 oder älter“ (auf der Personalseite und in der App); ein Geburtsdatum wird nicht gespeichert; ohne veröffentlichten Hinweis ist die Registrierung geschlossen. Alte Einwilligungen wurden zu Hinweis-Einträgen. Auf einem Computer getestet.
• Der Code des Datenschutz-Reviews: Die Netzwerkadresse eines Audit-Eintrags wird nach 180 Tagen gelöscht (einstellbar); ein Konto, das 24 Monate nicht benutzt wurde, bekommt eine Warnung und wird 30 Tage später anonymisiert; die Löschung einer Person oder eine zurückgezogene Chrono-Einwilligung erreicht die Controller anderer Felder, die ihre Kopien verwerfen; Löschungen bleiben als Hashes in einem Verzeichnis außerhalb der Datenbank und werden nach einer Wiederherstellung erneut angewendet; eine neue Personalseite markiert Wiederholungstäter nur als Hinweis (eine einfache Verwarnung zählt nie), und eine Sperre endet standardmäßig nach 12 Monaten; der Spielverlauf bleibt 90 Tage mit Spieler-IDs erhalten, die Teamergebnisse ohne sie 365. Auf einem Computer getestet.
• Ein Feld nimmt die Bedingungen für die Freigabe zwischen Feldern an (die Administration, auf der Einstellungsseite), bevor es Chrono-Einträge teilt; Version, Datum und Konto werden festgehalten, und ändern sich die Bedingungen, ruht die Freigabe, bis sie angenommen sind. Das Feld ist Verantwortlicher für die Daten seiner Spielenden, der Hub-Betreiber sein Auftragsverarbeiter, und die Felder, die teilen, sind nur für diesen Schritt gemeinsam Verantwortliche. Auf einem Computer getestet.
• Wer den Server betreibt, kann über die Kommandozeile ein Passwort für ein bestehendes Konto setzen (set-password, zweimal ohne Echo abgefragt, nie in der Kommandozeile): der Ausweg für ein Staff-Konto ohne zweiten Faktor, das seine Anmeldemethoden deshalb nicht über die Seite ändern kann.

Spiele, Clubs und Staff-Seiten

• Spielplanung, mit einer öffentlichen Seite pro Feld und offenen iCalendar- und JSON-Feeds seiner Spiele (ohne persönliche Daten).
• Die Anmeldung zu diesen Spielen, mit vorab angegebenen Repliken und einem Check-in-Ticket: Der Feld-Controller holt die Liste und meldet, wer gekommen ist. Anmeldung aus der App; Import einer Anmeldeliste (CSV oder JSON), die von einer anderen Plattform exportiert wurde.
• Club-Profile: Name, Farbe, Logo und Wappen, Mitglieder, eine öffentliche Seite, standardmäßig aus, mit Melde-Knopf und Moderation. Branding und gespeicherte Teams eines Felds werden mit seinen Controllern synchronisiert, sodass das Wappen eines Clubs jedes Feld erreicht, das sein Team gespeichert hat.
• Spielverlauf: Punkteverlauf und Ereignislog jedes Spiels; Spielende und Zuschauende sehen ein laufendes Spiel eine Minute verzögert, ohne Geheimnisse oder Spieler-IDs. Eine öffentliche Anzeigetafel pro Feld (standardmäßig aus).
• Die Szenario-Bibliothek des Felds mit ihren Spiel-Presets, so geprüft, wie der Feld-Controller sie prüft, und von jedem Controller des Felds installiert, einer Reserve eingeschlossen.
• Webseiten für das Staff des Felds, auf Portugiesisch und Englisch und auf dem Handy: Anmeldung mit dem Zwei-Faktor-Code, Spielverlauf, Szenario-Bibliothek (jedes Problem vor dem Speichern gezeigt, Revisionen und Presets), Gerätezustand sowie Live-Ansicht und Befehle der Remote-Spielleitung. Im Headless-Browser getestet, noch nicht auf einem echten Server.
• Controller entfernen ein Szenario oder Preset, das der Site-Server archiviert oder gelöscht hat, außer ein Spiel nutzt es noch.
• Staff-Seiten für den Spielplan: Spiele auflisten, anlegen, bearbeiten, veröffentlichen und absagen, mit Zeiten in der Zeitzone des Felds.
• Staff-Seiten für die Anmeldungen: wer sich angemeldet hat, Name, Team oder Verbandsnummer ändern, eine Anmeldung zurückziehen sowie CSV-Export und -Import.
• Eine druckbare Spieltagsliste, mit der Angabe, wann ein Controller sie zuletzt geholt hat.
• Staff-Aktionen an einer Anmeldung: bezahlt oder nicht bezahlt (der Server nimmt kein Geld an), nicht erschienen, in ein anderes Spiel verschieben, wiederherstellen, die Repliken bearbeiten. Im Headless-Browser getestet, nicht auf einem echten Server.
• Seiten für das Personal zu Rollen, Sync-Schlüsseln, Erscheinungsbild, Clubs, Plattform-Verknüpfungen, Firmware und Verwaltung.
• Die Seite des Remote-GM aktualisiert sich live, ohne Neuladen.
• Die Mitgliedschaft in einem Verband wird bei der Anmeldung und beim Check-in geprüft: APDs bei Spielfeldern in Portugal, anderswo jeder Verein oder Verband.
• Eine Seite für das Personal mit den Einstellungen des Spielfelds: öffentliche Seite, Check-in-Regeln, Mitgliedschaft, Chrono-Freigabe und Land.
• Chrono-Einträge zeigen, wie weit eine Replik über dem Limit lag, und markieren Wiederholungstäter.
• Eine Seite für das Personal des Feldes mit dem Datenexport und dem Verbrauch der Kontingente.
• Punkteverläufe in Spielzeit.
• Die Seite eines Clubs listet die Felder auf, auf denen er spielt, auch die Seite für die Mitarbeitenden.
• Der Controller importiert eine Anmelde-CSV selbst, ganz ohne Site-Server.
• Die Konsole warnt, wenn ein Name Buchstaben hat, die die Boxen nicht zeichnen können: Teamnamen, der Name des Spiels, der eines Szenarios und die seiner Ziele.
• Anmeldelisten tragen die Verbands-ID und das Ablaufdatum der Mitgliedschaft als optionale Spalten, und der Export der Anmeldungen lässt sich unverändert wieder importieren.

Boxen und das Feld

• Gerätezustand: Akku, Verbindung und Firmware jeder Box aus dem, was die Controller senden; der Feld-Controller meldet eine Box, die verstummt oder zurückkommt, und einen niedrigen Akkustand, den eine Box mit Akku-Anzeige auch selbst meldet. Noch nicht auf echten Boards.
• Ein Firmware-Katalog, der nur mit einem vertrauenswürdigen Schlüssel signierte Releases auflistet, und Firmware-Updates per Funk für die Field Box: Die Spielleitung lädt ein signiertes Release in den Feld-Controller hoch und aktualisiert die Boxen zwischen den Spielen, nie während eines; jede Box lädt es über das Feld-WLAN, prüft die Signatur mit Schlüsseln, die in ihre Firmware eingebaut sind, installiert es in ihrem freien Slot und kehrt zur alten Firmware zurück, wenn die neue nicht startet. In Software, noch nicht auf einem echten Board.
• Boxen ins Feld aufnehmen mit einer NFC-Feldkarte, dem USB-Kabel des Controllers oder dem 6-stelligen Code, den die Box zeigt, gekoppelt über Funk. In Software, noch nicht auf einem echten Board.
• Boxen per Funk ins nächste Spiel einladen, ohne Karte oder QR-Code (der Beitritt reist verschlüsselt unter einem aus dem Feld-Beitrittsschlüssel abgeleiteten Schlüssel), und ein Start, der wartet, bis jede Rolle eine Box hat, außer die Spielleitung wählt „Trotzdem starten“. Auf zwei Labortisch-Boards mit dem Feld-Controller getestet.
• Boxen, die in jedem neuen Spiel gehört werden (der Nonce-Zähler des Funks ist jetzt pro Spiel, eine Korrektur vom Labortisch), und Box-Bildschirme, die dem Spiel folgen (Bereit, Warten, Neutral), in der Sprache des Felds, Englisch oder Portugiesisch. Auf zwei Labortisch-Boards getestet.
• Ein mitten im Spiel neu gestarteter Controller nimmt das Spiel wieder auf; einer, der den Spielschlüssel verloren hat, sagt seinen Boxen über das Feld-Funknetz trotzdem, dass das Spiel vorbei ist; falsche Admin-PINs warten immer länger, über Neustarts hinweg gezählt, ohne Standard-PIN auf einer echten Box. In Software, noch nicht auf den Labortisch-Boards.
• Die Remote-Spielleitung: Eine Orga mit der GM-Rolle, per Zwei-Faktor-Code angemeldet, sieht das laufende Spiel und startet, pausiert, setzt fort oder beendet es, oder schickt eine Nachricht oder einen Modus-Befehl, über eine Verbindung, die der Feld-Controller selbst öffnet, nur wenn das Feld es einschaltet, jeder Befehl auf beiden Seiten protokolliert.
• Der Tab Controller der Konsole listet den Zustand der Remote-Spielleitung und jeden Befehl, den sie bekam.

Deployment und Hosted-Modus

• Das Deployment: HTTPS über Caddy mit automatischem Zertifikat, ein Setup-Skript, das alle Geheimnisse erzeugt, verschlüsselte tägliche Backups und eine Wiederherstellung in eine frische Datenbank. In Docker auf einem Computer getestet, nicht auf einem echten Server mit echter Domain.
• Hosted-Modus: ein Server für viele Felder, jedes in einem eigenen Datenbankschema unter eigener Adresse, mit Row-Level-Security darunter, sodass kein Feld je die Daten eines anderen sieht, und die Befehle der Betreiber, um die Daten eines Felds zu exportieren oder zu löschen. Gegen PostgreSQL in Docker getestet.
• Sein Deployment: ein Setup-Skript, das die Datenbankrollen des Hubs anlegt, jedes Feld unter eigener Adresse mit einem Zertifikat, das nur der Name eines aktiven Felds bekommen kann, und verschlüsselte Backups, wiederhergestellt mit jedem Feld getrennt von den anderen. In Docker getestet, nicht auf einem echten Hosted-Server mit echter Domain.
• Gehosteter Modus: ein Kontingent pro Feld, ein Datenexport, den die Verwaltung eines Felds herunterladen kann, und die offenen Verbindungen eines gelöschten Felds werden sofort geschlossen.
• Hosted-Modus: ein Speicherkontingent und eigene Domains pro Feld.
• Hosted-Modus: Jedes Feld hat eine eigene Datenbankrolle, so dass eine SQL-Injection nicht mehr auf die Daten eines anderen Feldes umschalten kann, indem sie die Einstellung ändert, die die Zeilensicherheit nutzte. Eine Lücke, die eine zweite SQL-Anweisung braucht, bleibt offen und ist dokumentiert. Gegen PostgreSQL in Docker getestet.
• Hosted-Modus: Felder, die Chrono-Einträge teilen, tun das jetzt auch zwischen den Feldern eines Hubs, über eine schreibgeschützte Ansicht, die eine Einwilligung braucht; eine Person verknüpft ihre Konten bei zwei Feldern mit einem Einmalcode, und nichts wird über E-Mail oder Namen zugeordnet. Gegen PostgreSQL in Docker getestet.
• Eine schreibgeschützte Live-Demo für den Vorschau-Server: Der echte Feld-Controller mit drei simulierten Field Boxen spielt endlos Spiele, abwechselnd auf einem offenen Feld und in einem erfundenen dreistöckigen Gebäude (ein Plan je Etage, fünfzehn Beacons, zwölf simulierte Spielende: sechs per Beacon verortet, fünf per GPS mit gewählter Etage, eine Person unsicher), und Besuchende sehen die GM-Konsole, die Anzeigetafel und eine Spielendenansicht, ohne etwas ändern zu können und ohne personenbezogene Daten. Seit dem 29. Oktober 2026 online unter demo.atalaia-project.link; ihre Spielendenansicht wird in einem Headless-Browser getestet.
• Hosted-Modus: ein einziger Rückruf der Social-Anmeldung für den ganzen Hub (optional): Der Betreiber trägt pro Anbieter eine Weiterleitungsadresse ein; der Hub signiert den Zustand, prüft das Feld in seinem Register und übergibt an den eigenen Rückruf des Feldes. In Docker getestet, nicht bei den echten Anbietern.
• Eine Go-live-Checkliste für den Betreiber: sechs Bedingungen, bevor irgendein Feld den Hosted-Modus bekommt (ein unterschriebener Auftragsverarbeitungsvertrag pro Feld, die Freigabebedingungen, jeder Unterauftragsverarbeiter im Anhang und in der EU, ein ausgefüllter Datenschutzhinweis, die eigenen Unterlagen des Betreibers, wenn er eine natürliche Person ist, und ein Nachweis auf einem echten Server).
• Der Preview-Server (tests.atalaia-project.link) läuft seit dem 30. Oktober mit all dem und hat einen eigenen Datenschutzhinweis (Version preview-2026-10-31: Konten auf Vertragsbasis, 16 oder älter, kein Datenschutzbeauftragter).
• Der Preview-Server installiert seine Datenschutzerklärung bei jedem Start und Update selbst (und hält an, wenn die Dateien einer Version fehlen), die Live-Demo sendet HSTS, und ein Wegwerf-Teststack (ein gehosteter Hub, ein falscher Login-Anbieter und ein Feld-Controller, nur auf 127.0.0.1) lässt einen autorisierten Sicherheitstest gegen den heutigen Code laufen.