Development Log.

Bis heute lief diese Seite auf einem HP-Mini-PC: Ghost und MySQL in Docker, davor nginx, nach außen erreichbar über die Pangolin-Edge in AWS Frankfurt und einen ausgehenden Newt-Tunnel. Das funktionierte, passte aber nicht mehr zum Rest der Plattform. Snapshots, Sicherungen und Ressourcen sollten dort liegen, wo alles andere auch läuft: auf Proxmox.

Statt die Platte zu klonen, habe ich neu gebaut. Eine frische Ubuntu-VM aus dem Cloud-Image, per cloud-init eingerichtet, dann Schritt für Schritt dieselben Pakete und Konfigurationen wie auf dem Mini-PC: nginx, SSH, sysctl, auditd, fail2ban, ufw, Postfix. Die Docker-Images sind auf dieselben Digests gepinnt, die Anwendungsdaten wurden aus dem gestoppten Stack roh kopiert und gegen ein Manifest geprüft. Jeder Schritt ist ein etckeeper-Commit, der Unterschied zwischen alt und neu bleibt damit nachlesbar.

Ein Stolperstein: Die erste VM hatte nach dem ersten Start kein Netz. Der Grund war ein Wettlauf beim Umbenennen der Netzwerkschnittstelle durch cloud-init, das Gerät war in dem Moment noch belegt. Mit dem Standard-Maschinentyp statt q35 lief der zweite Anlauf ohne Eingriff durch.

Die Umschaltung selbst war eine Zeile im Newt-Blueprint: neues Ziel für Weiterleitung und Health-Check, Container neu gestartet. Von außen war die Seite 66 Sekunden nicht erreichbar, danach antwortete die VM. Eine Lehre aus dem Vorlauf: Was man im Pangolin-Dashboard von Hand ändert, überschreibt der Blueprint beim nächsten Start wieder. Geändert wird deshalb nur dort.

Der Rückweg blieb am Tag der Umschaltung offen: Der Mini-PC stand mit gestoppten Diensten bereit, die alte Blueprint-Fassung lag als Sicherung daneben, zwei Befehle hätten zum alten Stand geführt. Gebraucht wurde er nicht. Inzwischen ist der Mini-PC selbst ein Proxmox-Knoten, von seinem alten Stand bleibt ein Archiv auf dem NAS, und die Platten der VM liegen auf gemeinsamem Speicher.

Inzwischen ist diese Seite eine statische Seite ohne Ghost und MySQL. Zwei Container und eine Datenbank, die für eine Handvoll Seiten nie nötig waren, sind damit überflüssig.

Die erste Live-Runde um C03 hat ihre lokale Abnahmegrenze überschritten. Zwei isolierte Browser-Sitzungen können nun einen temporären Raum erstellen und ihm beitreten, die vom Server zugewiesenen Rollen Operations und Archives erhalten, ihre Bereitschaft melden und die Runde durch einen ausdrücklichen Start des Hosts beginnen.

Der Abnahmelauf folgt dem gesamten spielbaren Pfad und endet nicht bei einem Verbindungstest. Operations erhält den aktuellen Türzustand und sendet den begrenzten Schließen-Intent. Archives behält den elf Jahre alten Versiegelungseintrag und erhält anschließend die rollenspezifische Aktualisierung derselben kanonischen Zustandsänderung. Nach einem Neuladen stellt der Host-only HttpOnly-Cookie ausschließlich diesen Teilnehmer und seine Projektion wieder her.

Mehrere vollständige Durchläufe machten Details sichtbar, die im früheren Unit-Schnitt verborgen blieben. Lobby-Clients benötigten vor dem ersten Snapshot einen spielerspezifischen Startzustand. Eine abgeschlossene Aktion brauchte ein bewusstes Ziel für den Tastaturfokus. Spieler mussten klar darauf hingewiesen werden, dass gewöhnliche Tabs desselben Browserprofils den Wiederaufnahme-Cookie teilen. Außerdem musste eindeutig sein, dass das Beenden des Raums beide Operatoren trennt. Jeder Punkt wurde behoben und anschließend erneut geprüft.

Frische produktionsnahe Builds bestehen das vollständige Szenario in Playwright Chromium und im lokal installierten Microsoft-Edge-Kanal. Die automatisierte Grenze prüft außerdem die Trennung der Rollenprojektionen, Cookie-Attribute, leeren skriptlesbaren Browser-Speicher, ausschließlich projektkontrollierte Netzwerkziele, rechtliche Seiten, Tastaturbedienung und schmale Viewports. Insgesamt bestehen 92 Protokoll-, Engine-, Property-, API-, Laufzeit- und direkte WebSocket-Tests.

Die erste Implementierung einer Live-Sitzung hält das Experiment bewusst klein: ein Raum nur auf Einladung, zwei Operatoren und der bereits durch die deterministische Engine abgedeckte C03-Widerspruch.

Ein Host erstellt einen Raum und teilt dessen zufälligen Code außerhalb der Anwendung. Ein zweiter Teilnehmer tritt bei, der Server weist Operations und Archives zu, beide Verbindungen melden ihre Bereitschaft und der Host startet ausdrücklich. Aktionen enthalten einen Intent und die erwartete Revision, aber weder Spieler noch Rolle. Der Server leitet diese Berechtigung aus der authentifizierten Verbindung ab und gibt jedem Operator eine eigene Projektion zurück.

Die Wiederherstellung nach einem Neuladen führt den ersten browserseitigen Zustand dieses Ausschnitts ein. Ein zufälliger 256-Bit-Nachweis liegt ausschließlich in einem Host-only HttpOnly-Cookie mit SameSite=Strict. Er erscheint weder in Anwendungs-JSON, WebSocket-Nachrichten, URLs noch im Web Storage. Der Server hält im Arbeitsspeicher nur einen SHA-256-Hash.

Diese Speichergrenze ist zugleich die aktuelle Einschränkung. Authentifizierte Aktivität verlängert die Gültigkeit eines Raums auf zwei Stunden; ein Serverneustart entfernt jedoch alle Räume und macht sämtliche Wiederaufnahme-Cookies ungültig. PostgreSQL ist nicht beteiligt, und dies ist weder ein öffentlicher noch ein produktiver Dienst.

Der lokale Integrationsmeilenstein besteht diese Grenze nun. Frische produktionsnahe Builds wurden in zwei unabhängigen Browser-Kontexten vom Einstieg bis zum Abschluss gespielt – sowohl mit Playwright Chromium als auch im installierten Microsoft Edge. Jeder Durchlauf umfasste Erstellen, Beitreten, Bereitschaft, Host-Start, getrennte C03-Projektionen, die autoritative Schließen-Aktion, die Aktualisierung für Archives und die Wiederherstellung nach einem Neuladen, ohne die Projektionsgrenze zu überschreiten.

Die Verifikation deckte konkrete Fehler auf und beseitigte sie: Der erste Startübergang lieferte Lobby-Clients keinen Startzustand für die laufende Sitzung, eine inhaltslose Wiederaufnahmeabfrage erzeugte mehrdeutige Browserdiagnosen, eine Abschlussaktualisierung konnte den Tastaturfokus verlieren, gewöhnliche Tabs waren nicht klar von isolierten Browserprofilen abgegrenzt, das Beenden eines Raums wirkte weniger endgültig als es ist und ein Testhelfer akzeptierte zu breite Frame-Serialisierungen. Das lokale Gate umfasst nun 92 Unit-, Property-, Protokoll-, API-, Laufzeit- und direkte WebSocket-Tests sowie acht Browserszenarien je Browser-Engine. Die Docker-Laufzeitprüfung bleibt das nächste Übergabe-Gate. Dieser Stand ist lokal und wartet vor einer Veröffentlichung auf die Abnahme durch den Betreiber.

SIGNAL//LOST beginnt mit einer eng umrissenen Frage: Was passiert, wenn zwei Spieler anhand unvereinbarer Beweise aus demselben System handeln müssen?

Der erste Implementierungsschnitt nutzt Schleuse C03. Operations erhält den aktuellen Steuerungszustand „offen“, während Archives die Versiegelung als intakt führt und nur einen elf Jahre alten Prüfzeitpunkt ausweist. Der Server hält den kanonischen Zustand, akzeptiert ausschließlich validierte Intents und sendet jeder Rolle eine separat erzeugte Projektion.

Dieser kleine Fall schafft die Grenzen, die das größere Spiel benötigt: deterministische Zustandsänderungen, monoton steigende Revisionen, Replay-Schutz, Rollenberechtigungen und Tests auf Informationslecks in serialisierten Spielerdaten.

Der nächste Meilenstein verbindet diesen Ausschnitt über eine einladungsbasierte Sitzung für zwei Spieler. Beide Perspektiven werden in getrennten Browser-Kontexten verifiziert, bevor ORPHEUS-17 erweitert wird.