Development Log.

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.