NOVA LAB // ZUGANGSPORTAL
Ein experimentelles Escape-Room-Spiel
NOVA LAB // TEILNEHMERKONFIGURATION
Wähle aus, ob das Spiel von einer Person oder gemeinsam von mehreren Personen gespielt wird. Dadurch ändert sich ausschließlich die Anrede im Spiel.
Angaben gemäß § 5 Digitale-Dienste-Gesetz (DDG)
TVG – Technische Visualistik GmbHStand: 18. September 2026
Geschäftsführer:
Dr. Ingmar Franke
E-Mail:
info@visualistik.eu
E-Mail:
info@visualistik.eu
Betreff:
Datenschutz
Diese Website wird bei der
IONOS SEgehostet.
Beim Aufruf der Website verarbeitet IONOS technisch erforderliche Zugriffsdaten. Hierzu gehören insbesondere die aufgerufene Seite beziehungsweise Datei, Zeitpunkt des Zugriffs, Referrer, Browsertyp, Betriebssystem, Gerätetyp und IP-Adresse.
Die Verarbeitung erfolgt auf Grundlage von Art. 6 Abs. 1 lit. f DSGVO.
Unser berechtigtes Interesse liegt in der sicheren und stabilen Bereitstellung der Website.
IONOS ist Empfänger der Daten und als Auftragsverarbeiter für uns tätig.
Nach Angaben von IONOS werden Webhosting-Zugriffsdaten acht Wochen gespeichert. IP-Adressen werden anonymisiert.
IONOS WebAnalytics wird zur statistischen Auswertung und technischen Optimierung eingesetzt.
Nach Angaben von IONOS verwendet WebAnalytics keine Cookies und verarbeitet IP-Adressen nach der Übermittlung in anonymisierter Form.
Wenn Sie uns per E-Mail kontaktieren, verarbeiten wir die von Ihnen übermittelten personenbezogenen Daten zur Bearbeitung Ihrer Anfrage.
Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO.
Soweit die Kontaktaufnahme der Anbahnung oder Durchführung eines Vertrags dient, ist zusätzlich Art. 6 Abs. 1 lit. b DSGVO Rechtsgrundlage.
Für die E-Mail-Kommunikation verwenden wir Microsoft 365 beziehungsweise Exchange Online der
Microsoft Ireland Operations LimitedSoweit dabei eine Verarbeitung außerhalb des Europäischen Wirtschaftsraums erfolgt, werden die hierfür erforderlichen datenschutzrechtlichen Garantien eingesetzt.
Die Daten werden für die Dauer der Bearbeitung und anschließend nur so lange gespeichert, wie gesetzliche Aufbewahrungspflichten oder berechtigte Dokumentationszwecke bestehen.
Sie haben im Rahmen der gesetzlichen Voraussetzungen insbesondere das Recht auf:
Sie haben das Recht, sich bei einer Datenschutzaufsichtsbehörde zu beschweren.
Zuständig für die TVG ist:
Landesbeauftragte für den Datenschutz Sachsen-AnhaltBrowserbasiertes 2D-Point-and-Click-Escape-Room-Spiel.
Aija Grosche
Schülerpraktikantin bei der
TVG – Technische Visualistik GmbH
September 2026
Das Spiel wurde im Rahmen des Schülerpraktikums unter Einsatz KI-gestützter Entwicklungswerkzeuge konzipiert, programmiert, geprüft und dokumentiert.
Dabei kamen insbesondere OpenAI Codex und ChatGPT-Agenten zum Einsatz.
Die KI-Systeme dienten als Entwicklungsunterstützung.
Die fachliche Auswahl, Steuerung, Prüfung und Abnahme der Umsetzung erfolgte durch die Projektbeteiligten.
Die technische Programmierbeschreibung des Projekts basiert auf der aktuellen README.md und kann nachfolgend eingesehen werden.
„NOVA – Sicherheitsprotokoll“ ist ein lokal ausführbares, browserbasiertes 2D-Point-and-Click-Escape-Room-Projekt. Das eigentliche Spiel verwendet ausschließlich semantisches HTML, CSS und modernes Vanilla-JavaScript und benötigt weder Framework, Paketmanager, Datenbank noch Server. dist/server/index.js ist lediglich ein generierter Hosting-Wrapper für eine bereitstellbare Kopie und gehört nicht zur Spiellogik. Dieser Projektstand dokumentiert keine Veröffentlichung oder neue Bereitstellung.
Der aktuelle Stand umfasst Titelbildschirm, Spielmodusauswahl, Einführung mit Systemstörung, zwei Raumdarstellungen, Dialogsteuerung, Neustart, fünf Interaktionsbereiche, die gemeinsamen technischen Rätselgrundlagen, die vollständig spielbaren Rätsel 1, 2 und 3 sowie das vollständig spielbare Finale. Nach der einmaligen menschlichen Bestätigung führt HUMAN-CTRL die Sequenz B → C → D automatisch aus, stellt die menschliche Kontrolle wieder her und entriegelt die Labortür.
index.html direkt in einem modernen Browser wie Chrome, Edge oder Firefox öffnen. Eine Installation, Internetverbindung oder ein lokaler Server ist nicht erforderlich.
Alle Projektdateien müssen in ihrer vorhandenen Ordnerstruktur zusammenbleiben, damit Stylesheets, Skripte und Grafiken geladen werden können.
Nach „Experiment betreten“ wird zwischen zwei Modi gewählt:
du, dich, dir und dein sowie Singular-Imperative.ihr, euch und euer sowie Plural-Imperative.Die Auswahl wird in gameState.playerMode als "single" oder "group" gespeichert. Sie verändert ausschließlich die direkte Anrede. Dialogreihenfolge, Zustandswechsel, Interaktionen und der vorbereitete Spielablauf bleiben identisch. Texte ohne direkte Anrede werden als gemeinsame Zeichenketten verwendet; Variantenobjekte werden durch resolvePlayerText() aufgelöst.
Die Spieler besuchen eine Testvorführung im NOVA Experience Lab. Vorgestellt werden:
Als zentraler Grundsatz wird erklärt, dass NOVA Gefahren erkennen, warnen und unterstützen darf, die endgültige Entscheidung jedoch beim Menschen bleibt.
Die Einführung besteht aus genau 16 anklickbaren Sprechertexten:
locked.Nach Schritt 16 wird die Einführung beendet und die freie Erkundung aktiviert. SIMULATION GESTARTET und die abschließende Zielanzeige zählen nicht als zusätzliche Dialogschritte. Genau 16 Dialogschritte bestätigt: INTRO_DIALOGUES enthält 16 eindeutig nummerierte Einträge von intro-01-invitation bis intro-16-transition.
In assets/images/ sind tatsächlich vorhanden:
version-1-laborraum.pngversion-2-laborraum.pngAktiv verwendet werden:
assets/images/version-1-laborraum.png: normaler, blau beleuchteter Showroom für die Schritte 2 bis 11.assets/images/version-2-laborraum.png: rot akzentuierter, abgeriegelter Raum ab Schritt 12 und während der freien Erkundung.index.html lädt zunächst version-1-laborraum.png. js/game.js definiert beide aktiven Pfade in ROOM_IMAGES und wechselt sie über setRoomImage().
Hinter dem <img>-Element liegt ein neutral beschrifteter HTML-Platzhalter. Ein programmatischer Fehlerhandler für fehlgeschlagene Bildladevorgänge ist weiterhin nicht vorhanden; bei einem Ladefehler bleibt jedoch eine verständliche Ersatzanzeige sichtbar.
Die Steuerung verwendet mehrere getrennte Ebenen:
gameState.playerMode: gewählte Anrede, null, "single" oder "group".gameState.scene: sichtbare Hauptszene "title", "mode" oder "game".data-intro-step am Spielbereich: ID des aktuell sichtbaren Dialogschritts.dialogueQueue: noch ausstehende Dialogeinträge der laufenden Sequenz.gameState.introFinished: kennzeichnet den Abschluss beziehungsweise das Überspringen der Einführung.gameState.roomState: im Code verwendeter Darstellungszustand "invitation", "showroom", "systemFailure", "locked" oder "exploration".invitation ist keine physische Raumvariante, sondern eine Einführungsphase, während der die Raumebene verborgen bleibt. showroom, systemFailure und locked beschreiben sichtbare Raumzustände. exploration kennzeichnet zugleich den abgeriegelten Raum und die freigegebene Erkundungsphase.
Fünf unsichtbare, tastaturfähige Hotspot-Schaltflächen sind vorbereitet:
Während der Einführung sind alle Hotspots über disabled deaktiviert. finishIntroduction() setzt gameState.introFinished auf true, wechselt zu exploration und aktiviert anschließend alle fünf Bereiche. Whiteboard, Exponate und Schreibtisch öffnen die gemeinsame Detailansicht für Rätsel 1; Präsentationswand und Tür zeigen weiterhin ihre zustandsabhängigen Informationen.
„Einleitung überspringen“ leert die Dialogwarteschlange und ruft über denselben Abschlussweg finishIntroduction() auf. Danach gilt laut Code:
gameState.introFinished === truegameState.roomState === "exploration"version-2-laborraum.png ist aktivDer gewählte Einzel- oder Mehrspielermodus bleibt erhalten, sodass die Zielanzeige weiterhin die passende Du-/Ihr-Variante verwendet.
Die Ereignisse sind folgendermaßen angeordnet:
simulationStarted das Attribut data-simulation="started"; dadurch erscheint „SIMULATION GESTARTET“.systemFailure den einmaligen Zustandswechsel aus.version-2-laborraum.png.roomState wird locked.exploration mit der abgeriegelten Grafik.Der NOVA-Dialog verändert sich erzählerisch von der Sicherheitsvorstellung zur Verweigerung der Türfreigabe. Eine hörbare Verriegelung ist nicht umgesetzt; die Verriegelung wird ausschließlich visuell und textlich dargestellt.
Audio ist nicht vorhanden. assets/sounds/ ist leer, und weder HTML noch JavaScript bindet Audiodateien ein oder löst einen Verriegelungston aus. Der Ordner ist lediglich für eine spätere Entwicklung vorbereitet.
Oben rechts befindet sich ein Menüsymbol. Während eines laufenden Spiels enthält das Menü den Punkt „Neustart“. resetGame() zeigt weiterhin zunächst dieselbe Sicherheitsabfrage. Nach Bestätigung werden Spielmodus, Einführung, Dialogwarteschlange, Raumzustand, Rätselstatus und Fundstücke auf ihre Anfangswerte zurückgesetzt; anschließend erscheint der Titelbildschirm.
Ein Neuladen der Browserseite setzt den aktuellen Stand ebenfalls zurück. Das Projekt verwendet weder localStorage noch sessionStorage; Zustände werden ausschließlich im Arbeitsspeicher gehalten. Eine besondere Neustartfunktion am Spielende existiert nicht; der vollständig umgesetzte Endzustand verwendet weiterhin den allgemeinen Neustart im Hauptmenü.
Tab: zwischen erreichbaren Bedienelementen wechseln.Enter oder Leertaste: fokussierte Schaltfläche aktivieren.Escape: geöffnetes Hauptmenü beziehungsweise Datenschutz-, Impressums- oder Projektinformationsfenster schließen.nova-escape-room/
├── index.html
├── css/
│ └── style.css
├── js/
│ ├── game.js
│ ├── puzzles.js
│ └── dialogue.js
├── assets/
│ ├── images/
│ │ ├── version-1-laborraum.png
│ │ └── version-2-laborraum.png
│ ├── sounds/
│ └── fonts/
├── .openai/
│ └── hosting.json
├── dist/
│ ├── client/ # synchronisierte, bereitstellbare Kopie der statischen Spieldateien
│ └── server/
│ └── index.js # generierter Hosting-Wrapper, keine Spiellogik
└── README.mdindex.html: semantische Grundstruktur für Titel, Modusauswahl, Raum, Hotspots, Effekte, Dialogfenster, Hauptmenü sowie Datenschutz-, Impressums- und Projektinformationsfenster.css/style.css: Darstellung, responsive 16:9-Bühne, Fokuszustände, Hauptmenü, Modalfenster und visuelle Störungseffekte.js/game.js: zentraler Spielzustand, Szenen-, Dialog-, Menü-, Fokus- und Ablaufsteuerung.js/dialogue.js: Daten der 16 Einführungsschritte und Du-/Ihr-Varianten.js/puzzles.js: gemeinsame Rätselgrundlagen sowie Daten und Zustandshelfer für die vollständig umgesetzten Rätsel 1, 2 und 3..openai/hosting.json: vorhandene Hosting-Konfiguration; sie wurde in diesem Arbeitsstand nicht verändert oder ausgeführt.dist/client/: synchronisierte, bereitstellbare Kopie der statischen Spieldateien; ihre Existenz ist kein Nachweis einer Veröffentlichung.dist/server/index.js: generierter Hosting-Wrapper, der Anfragen an die statischen Dateien weiterleitet; das eigentliche Spiel bleibt serverlos und lokal über index.html ausführbar.Vorhanden sind ein lokal startbarer Titelbildschirm, Modusauswahl, 16-schrittige Einführung, Du-/Ihr-Anrede, Raumgrafikwechsel, visuelle Systemstörung, Dialogfenster, Zielanzeige, fünf Hotspots, Überspringen, Hauptmenü, final integrierte Datenschutz-, Impressums- und Projektinformationsfenster, vollständiger Neustart sowie die vollständig spielbaren Rätsel 1, 2 und 3. Rätsel 1 umfasst Whiteboard, Exponate, Schreibtisch, Diagnose-Terminal, Hinweise, Fehlversuche, Diagnose und einmaligen Erfolgsdialog. Rätsel 2 umfasst seine drei Informationsquellen, Rekonstruktion, Entfernen, Austauschen und Sortieren der Textbausteine, getrennte Hinweise und Fehlversuche, Autorisierung und HUMAN-CTRL-Freischaltung.
Nach Abschluss von Rätsel 2 wechselt der zentrale Zustand zu activePuzzle === "puzzle3". Nach der in Rätsel 3 geprüften Planung werden releaseSequenceReady === true und activePuzzle === "finale" gesetzt; die Tür bleibt zu diesem Zeitpunkt weiterhin verriegelt. Erst die bestätigte Finalsequenz führt B, C und D tatsächlich aus und setzt doorUnlocked nach D auf true. Nicht vorhanden sind Audio, Spielzeitmessung und persistente Speicherung.
| Prüfpunkt | Ergebnis | Nachweis |
|---|---|---|
| Verwendete Grafikdateien | Bestanden | index.html sowie ROOM_IMAGES und setRoomImage() in js/game.js |
| Wechsel zu Variante 2 bei Schritt 12 | Bestanden | intro-12-system-failure ruft die Aktion systemFailure auf; diese setzt die Grafik auf locked |
| Genau 16 Dialogschritte | Bestanden | 16 Einträge in INTRO_DIALOGUES, nummeriert von 01 bis 16 |
| Einzel-/Mehrspielermodus | Bestanden | gameState.playerMode, selectPlayerMode() und resolvePlayerText() |
| Du-/Ihr-Anrede | Bestanden | Variantenobjekte in js/dialogue.js und finale Zielanzeige |
| Hotspots nach regulärer Einführung | Bestanden | finishIntroduction() setzt introFinished; updateGameUI() entfernt disabled |
| Hotspots nach Überspringen | Bestanden | skipIntroduction() verwendet denselben Abschluss über finishDialogueQueue() |
| Neustart | Bestanden | Menüpunkt menu-restart verwendet weiterhin resetGame() mit Sicherheitsabfrage |
| Störungseffekte | Bestanden | Schritt-12-Aktion, CSS-Animationen, Statusanzeige und Grafikwechsel |
| Audio | Nicht vorhanden | assets/sounds/ ist leer; keine Audioeinbindung in HTML oder JavaScript |
Bekannte offene technische Punkte:
invitation wird technisch in gameState.roomState gespeichert, obwohl sie keinen physischen Raumzustand darstellt.Die Oberfläche unterstützt Desktop- und Laptopfenster sowie Tablets und Smartphones im Querformat. Mobile Geräte und Tablets müssen für die eigentliche Spieloberfläche im Querformat verwendet werden. Ein Hochformat-Hinweis wird aktiviert, wenn alle folgenden Bedingungen gemeinsam gelten: orientation: portrait, höchstens 64rem Viewportbreite und entweder pointer: coarse oder hover: none. Diese Kombination verhindert, dass allein ein hochformatiges Fenster als Mobilgerät gilt.
Ein Desktopfenster mit feinem Zeiger und Hover-Funktion bleibt deshalb auch bei 800 × 1000 sichtbar und bedienbar. Das ist eine bewusste Desktop-Ausnahme.
Während der mobilen Hochformatsperre wird ausschließlich der vollflächige Drehhinweis angezeigt. Die Anwendung erhält inert und aria-hidden="true"; damit sind Maus-, Touch-, Tastatur- und assistive Bedienung der verdeckten Oberfläche deaktiviert. Beim Zurückdrehen werden Sperre und ARIA-Zustand entfernt und der zuvor fokussierte Bedienpunkt wird nach Möglichkeit wiederhergestellt. Der Spielzustand wird dabei nicht neu initialisiert.
Die Spielbühne bleibt 16:9 und nutzt vh, svh und dvh als gestaffelte Viewport-Fallbacks. Beide aktiven Raumgrafiken besitzen identische 1672 × 941 Pixel. Sie werden unverzerrt in einem gemeinsamen, mittig ausgerichteten Bildcontainer dargestellt. Wegen der minimalen Differenz zu mathematischem 16:9 bleibt an den Seiten insgesamt ungefähr 0,053 % gestalterische Hintergrundfläche sichtbar. Dies schützt in der vorgegebenen Reihenfolge Proportionen, Hotspot-Zuordnung und die vollständige Sichtbarkeit aller wichtigen Objekte.
Die fünf Hotspots verwenden Prozentkoordinaten innerhalb genau dieses Bildcontainers; Raumgrafik, Effekte und Hotspots skalieren und verschieben sich daher gemeinsam. Der Wechsel zwischen normaler und abgeriegelter Grafik verursacht keinen Geometriewechsel. Zusätzliche Bildvarianten waren nicht erforderlich und wurden nicht erstellt.
Normale Texte sind mindestens 16 CSS-Pixel groß. Reguläre Bedienelemente besitzen mindestens 44 × 44 CSS-Pixel. Dialogtexte dürfen umbrechen und bei geringer Bildschirmhöhe intern vertikal scrollen, während die Aktionsschaltflächen erreichbar bleiben. Maus, Touch, Tabulator, Enter und Leertaste werden unterstützt; sichtbare Fokusmarkierungen und prefers-reduced-motion bleiben erhalten.
Die Ziel-Viewports und Ergebnisse sind in der folgenden Prüftabelle dokumentiert.
| Viewport | Testart | Ergebnis |
|---|---|---|
| 1920 × 1080 | Praktisch und automatisiert im Browser | 16:9-Bühne, Grafik-/Hotspotcontainer deckungsgleich, kein Seitenüberlauf, sichtbare Bedienelemente mindestens 44 px |
| 1366 × 768 | Praktisch und automatisiert im Browser | Wie vorgesehen; zusätzlich normaler Ablauf bis Schritt 12 und unveränderte Geometrie beim Grafikwechsel bestätigt |
800 × 1000, pointer: fine, hover: hover | Praktisch und automatisiert im Browser | Desktop-Ausnahme aktiv: kein Drehhinweis, Raum und Dialog bedienbar, kein Seitenüberlauf |
| 1024 × 768 | Praktisch und automatisiert im Browser | Raum proportional, Dialog und Bedienelemente erreichbar, kein Seitenüberlauf |
| 844 × 390 | Praktisch und automatisiert im Browser | Kleine Querformatanordnung funktionsfähig; Hotspots mindestens 74,5 × 110,4 px, Bedienelemente mindestens 44 px |
| 667 × 375 | Praktisch, automatisiert und visuell im Browser | Kleinste Querformatansicht funktionsfähig; Dialog intern passend, Hotspots mindestens 71,6 × 106,1 px, kein Seitenüberlauf |
| 768 × 1024 | Praktisch im Browser nur mit pointer: fine/hover: hover; mobile Sperre nur anhand des Codes geprüft | Desktopartige Eingabe bleibt absichtlich entsperrt; Testbrowser konnte pointer: coarse nicht emulieren |
| 390 × 844 | Praktisch im Browser nur mit pointer: fine/hover: hover; mobile Sperre nur anhand des Codes geprüft | Desktopartige Eingabe bleibt absichtlich entsperrt; Testbrowser konnte pointer: coarse nicht emulieren |
Zusätzlich praktisch getestet wurden Einzelspielermodus, regulärer Abschluss aller 16 Einführungsschritte, Gruppenmodus, Überspringen, Hotspot-Aktivierung, Hotspotdialog, Schritt-12-Grafikwechsel und vollständiger Neustart. Die Browserkonsole enthielt keine Fehler oder Warnungen. Die Hochformatsperre mit realer Grobzeiger-/Touch-Emulation, Tab-Sperre während des Drehhinweises sowie Zustands- und Fokuswiederherstellung nach einer echten Rotation konnten mit dem verfügbaren Testbrowser nicht praktisch simuliert werden; diese Punkte wurden anhand der Media Query und der inert-/ARIA-/Fokuslogik geprüft.
Bekannte Einschränkungen: Der Bildlade-Platzhalter besitzt keinen JavaScript-Fehlerhandler. Die vorhandenen inhaltlichen Hotspotkoordinaten wurden nicht neu interpretiert; ihre responsive Abbildung ist deckungsgleich, eventuell bereits zuvor vorhandene Grundungenauigkeiten bleiben bestehen. Die minimale seitliche Hintergrundfläche resultiert aus 1672:941 gegenüber mathematischem 16:9.
Stand: 15. September 2026
Dieser Zwischenabschluss ergänzt die Zielanzeige und die Seitenkulisse für kleine Smartphones im Querformat:
Escape zum Schließen verfügbar. aria-expanded bildet den Zustand korrekt ab; beim Schließen kehrt der Fokus zu „Ziel“ zurück.Die kompakte Darstellung der Zielbedienung wird nur bei orientation: landscape, maximal 60rem Breite, maximal 25rem Höhe und pointer: coarse beziehungsweise hover: none aktiviert. Die Schaltfläche folgt direkt gameState.introFinished und gameState.scene; es existiert weder ein zweiter Zieltext noch ein paralleler Spielzustand. Vor und während der Einführung sowie nach einem Neustart bleiben Schaltfläche und Zielanzeige verborgen. Auch auf Desktop und größeren Tablets startet die Zielanzeige geschlossen und wird über „Ziel“ geöffnet.
Die dekorative Hintergrundgrafik ist mit aria-hidden="true" für assistive Technologien verborgen und erhält keine Pointer-Ereignisse. setRoomImage() weist Hauptbild und Hintergrund immer denselben vorhandenen Pfad aus ROOM_IMAGES zu. Bilddateien, Bildpfade, Hauptbild-Geometrie, Raumzustände und Hotspot-Koordinaten wurden nicht verändert.
| Prüfpunkt | Status |
|---|---|
| JavaScript-Syntax | Automatisiert bestanden (node --check) |
| Regulärer Abschluss aller 16 Dialogschritte | Im Browser simuliert; Ziel, Hotspots und abgeriegelter Raumzustand korrekt |
| Einführung überspringen | Im Browser simuliert; kompakte Zielanzeige erscheint korrekt |
| Einzel- und Gruppenansprache | Im Browser simuliert; Du-/Ihr-Zieltexte korrekt |
Wiederholtes Umschalten über „Ziel“, Schließen über × und Escape sowie Fokus | Im Browser mit Maus-, Pointer-/Touch-, Enter- und Leertastensimulation geprüft; aria-expanded und Fokusrückgabe korrekt |
| Neustart mit Bestätigung | Im Browser simuliert; Titelzustand und verborgene Zielanzeige korrekt |
844 × 390, 852 × 393, 667 × 375, 844 × 320 | Im Browser mit erzwungener Grobzeiger-Bedingung simuliert; Schaltfläche mindestens 44 px, 16:9-Bühne unverändert, Seitenkulisse aktiv |
1920 × 1080, 1366 × 768, 1024 × 768 | Im Browser simuliert; zunächst geschlossene, über „Ziel“ bedienbare Zielanzeige, unveränderte 16:9-Bühne, keine Seitenkulisse |
| Hochformat und Rückkehr ins Querformat | Im Browser mit erzwungener Grobzeiger-Bedingung simuliert; Sperre hat Vorrang, Zielbedienung verborgen, Rückkehr geschlossen mit Fokus auf „Ziel“ |
| Browserkonsole und Ressourcen | Keine Fehler oder Warnungen; CSS, drei Skripte und beide synchron verwendeten Bildelemente geladen |
Der verfügbare Desktop-Testbrowser emuliert über die Größensteuerung keinen echten Touch-/Grobzeiger. Deshalb wurde für die praktische Prüfung der mobilen Variante ausschließlich in einer temporären Kopie außerhalb des Projektordners die Gerätebedingung erzwungen. Die produktive Kombination aus Größe, Ausrichtung und Eingabeart wurde zusätzlich anhand des Codes geprüft. Die zu diesem Zwischenabschluss noch offenen echten Gerätetests wurden später durch den Nutzer für den damaligen Rätsel-1-Stand auf iPhone und iPad erfolgreich durchgeführt. Die temporäre Kopie wird nicht zum Projektstand gezählt und wurde nach Abschluss der Prüfung entfernt. Die Tag-3-Fokuskorrektur ist von diesen früheren Gerätetests nicht abgedeckt.
Stand: 16. September 2026
Das Menüsymbol ist auf Titelbildschirm, Modusauswahl, Einführung und Spielansicht oben rechts erreichbar. Vor einem laufenden Spiel enthält das Menü Impressum, Datenschutz und Projektinformationen. Sobald gameState.scene === "game" gilt – also in demselben Zustand, in dem zuvor die Neustart-Schaltfläche verfügbar war – kommt ausschließlich der Menüpunkt Neustart hinzu. Das Menü verwendet damit den vorhandenen Szenenzustand und keine zweite Navigations- oder Spielzustandsverwaltung.
Das Symbol und alle Menüpunkte besitzen mindestens 44 × 44 CSS-Pixel Bedienfläche. Das Symbol arbeitet als Umschalter und pflegt aria-expanded sowie seine zugängliche Beschriftung. Beim Öffnen erhält der erste verfügbare Menüpunkt den Fokus. Ein erneutes Aktivieren oder Escape schließt das Menü und gibt den Fokus an das Symbol zurück. Die Menüfläche liegt über der Anwendung und fängt Pointer-Ereignisse ab.
Der Menüpunkt Neustart ruft weiterhin unverändert resetGame() auf. Die vorhandene Du-/Ihr-Sicherheitsabfrage bleibt zwingend. Bei Abbruch bleiben Menü und vollständiger Spielverlauf erhalten; erst eine Bestätigung setzt das Spiel zurück. Danach zeigt das Menü im Titelzustand wieder ausschließlich Impressum, Datenschutz und Projektinformationen.
Impressum, Datenschutz und Projektinformationen öffnen dasselbe vorhandene modale Informationsfenster mit passender Überschrift und sichtbarer Schließen-Schaltfläche ×. Der Inhaltsbereich wird aus lokalen HTML-Templates befüllt und kann lange Inhalte vertikal scrollen, während Überschrift und Schließen-Schaltfläche sichtbar bleiben. Das Impressum enthält ausschließlich Anbieterangaben, die Datenschutzerklärung ausschließlich Datenschutzinformationen. Die Projektinformationen enthalten Projektdaten und die lokal eingebettete README als aufklappbare Programmierbeschreibung.
Ein Inhaltsfenster wird ausschließlich über × oder auf Tastaturgeräten über Escape geschlossen; ein Klick auf die abgedunkelte Fläche schließt es nicht. Während es geöffnet ist, sind sichtbare Szene und Hauptmenü über inert nicht bedien- oder fokussierbar. Der Fokus bleibt innerhalb des Fensters und kehrt beim Schließen zum auslösenden Menüpunkt zurück; das Hauptmenü bleibt dabei geöffnet. Menü und Inhaltsfenster verändern weder gameState noch Dialogwarteschlange, Raum-, Ziel-, Hotspot- oder Rätselzustände. Die bestehende Hochformatsperre bleibt unverändert und hat weiterhin Vorrang.
Stand: 16. September 2026
Etappe 1 stellte die gemeinsame Infrastruktur für die Rätsel bereit. Rätsel 1, Rätsel 2, Rätsel 3 und das Finale verwenden diese Grundlage vollständig.
Der zentrale gameState bleibt die einzige maßgebliche Zustandsquelle. Vor Abschluss der Einführung gilt activePuzzle === "intro". Sowohl der reguläre Abschluss über finishIntroduction() als auch „Einleitung überspringen“ verwenden denselben Abschlussweg und setzen activePuzzle auf "puzzle1", puzzlePhase auf "ready" und openDetailView auf null. Der Raum bleibt dabei im vorhandenen Zustand exploration. Der spätere Endzustand benötigt deshalb keinen zusätzlichen Raumzustand und kann als roomState === "exploration", doorUnlocked === true und activePuzzle === "complete" dargestellt werden.
js/puzzles.js stellt die gemeinsamen Schnittstellen und die Daten für Rätsel 1 bereit:
1, 2, 3, 3, ...,Die gemeinsame Rätsel-Detailansicht enthält Bereiche für Überschrift, Sachinformation, Rätselinhalt, Eingaben, Rückmeldung, Hinweis und Bedienflächen. Rätsel 1 füllt diese Bereiche mit Whiteboard, Exponatübersicht und -details, Schreibtischbereichen sowie Diagnose-Terminal. Reguläre Bedienflächen besitzen mindestens 44 × 44 CSS-Pixel. Der Inhaltsbereich kann bei geringer Höhe intern scrollen und berücksichtigt mobile Safe Areas.
Rechtsansicht und Rätsel-Detailansicht verwenden dieselbe zentrale Modal- und Fokussteuerung. Eine zweite modale Ansicht wird verhindert, solange bereits eine geöffnet ist. Beim Öffnen wird der Hintergrund mit inert gesperrt, der Fokus in die Ansicht gesetzt und dort per Tabulatortaste gehalten. Escape beziehungsweise die sichtbare Schließen-Schaltfläche schließen die Ansicht und geben den Fokus an den Auslöser zurück. Die vorhandene Hochformatsperre sperrt auch eine offene Detailansicht. Ihre Kennung und ihr Inhalt bleiben während der Rotation erhalten; nach der Rückkehr wird der zuvor aktive Fokus nach Möglichkeit wiederhergestellt.
resetGame() setzt nach bestätigter Sicherheitsabfrage Einführung, Rätselphase, Detailansicht, Hinweise, Fehlversuche, Fundstücke, Freischaltungen, gelesene Informationen, einmalige Ereignisse, Lösungsflags und Türstatus gemeinsam auf ihren Anfangszustand zurück. Bei Abbruch wird kein Zustand verändert.
Die maßgeblichen Quelldateien werden zuerst geprüft. dist/client wird erst nach bestandenen Syntax-, Struktur- und Regressionstests durch direkte Kopien der geprüften Quellen synchronisiert. Es gibt keinen separaten Buildprozess und keine eigenständige Logik in der Distribution. .openai/hosting.json und dist/server/index.js bleiben unverändert.
Stand: 16. September 2026
Rätsel 1 ist vollständig spielbar. Whiteboard, vier Exponate und Schreibtisch verwenden die zentrale Rätsel-Detailansicht. Die Exponate liefern ihre System-IDs und Prüfwerte; die Whiteboard-Reihenfolge S1 → E3 → S2 → E1 ergibt den vierstelligen Wartungscode. Das Diagnose-Terminal akzeptiert ausschließlich vier Ziffern, zählt nur vollständige falsche Eingaben als Fehlversuch und zeigt nach korrekter Lösung die Diagnose der Türverriegelung. Anschließend wird der einmalige Erfolgsdialog ausgelöst und das Ziel von Rätsel 2 angezeigt. Rätsel 2 ist inzwischen vollständig spielbar; die Labortür bleibt auch nach dessen Abschluss verriegelt.
Die drei Hinweise werden über den gemeinsamen Hinweiszustand ausgegeben und bleiben nach Stufe 3 auf Stufe 3. Untersuchte Exponate, freigeschaltete Informationen, Terminaleingabe, Diagnosefreigabe und der einmalige Erfolgsdialog liegen ausschließlich im zentralen gameState. Die Diagnose kann erneut geöffnet werden, ohne den Erfolgsdialog zu wiederholen. Ein bestätigter Neustart setzt sämtliche Rätsel-1-Zustände über den bestehenden Resetweg zurück.
Die verwendeten WebP-, SVG- und Raum-PNG-Dateien liegen unter assets/images/. Quell- und Distributionsdateien sind direkt synchronisiert. Syntax, Inhalte und Zustandshelfer wurden automatisiert geprüft. Der vollständige Ablauf wurde im Browser mit Maus und Tastatur sowie bei 1920 × 1080, 1366 × 768, 1024 × 768, 844 × 390, 852 × 393, 667 × 375, 844 × 320 und 390 × 844 geprüft. In diesen Ansichten traten weder horizontaler Seitenüberlauf noch defekte Rätselbilder auf; die Detailansicht blieb vollständig innerhalb des Viewports und ihre sichtbaren Bedienelemente mindestens 44 × 44 CSS-Pixel groß. Rätsel 1 wurde anschließend durch den Nutzer auf iPhone und iPad erfolgreich geprüft. Diese früheren Gerätetests decken die spätere Tag-3-Fokuskorrektur nicht ab; dafür bleibt ein kurzer erneuter Gerätetest offen.
Stand: 16. September 2026
Beim erstmaligen Öffnen der gemeinsamen Rätsel-Detailansicht wird der auslösende Raum-Hotspot als unverändertes Rückgabeziel gespeichert. Interne Wechsel zwischen Exponatübersicht und Exponatdetails sowie zwischen Schreibtisch, Wartungsschublade und Diagnose-Terminal überschreiben dieses Ziel nicht mehr. Sowohl die sichtbare Schließen-Schaltfläche als auch Escape schließen dieselbe Detailansicht über denselben Schließweg und geben den Fokus an den ursprünglichen Raum-Hotspot zurück. Rätselzustand, Eingabe und Fortschritt werden dadurch nicht verändert.
Rätsel 1 ist vollständig umgesetzt: Die Whiteboard-Sequenz, die vier Exponate mit System-IDs und Prüfwerten, das Diagnose-Terminal, die dreistufigen Hinweise und die Zählung vollständiger Fehlversuche führen zur Diagnose. Der Erfolgsdialog wird einmalig ausgelöst. Zum damaligen Tag-3-Stand wechselte das Ziel danach zum erst vorbereiteten Rätsel 2. Inzwischen sind Rätsel 2, Rätsel 3 und das Finale vollständig umgesetzt. doorUnlocked bleibt bis zum erfolgreichen Abschluss von Finalschritt D false.
Die drei Skripte wurden zu diesem damaligen Tag-3-Stand einheitlich mit dem Cachewert v=20260916-tag3-focusfix eingebunden. Der aktuelle Cachewert ist im Abschnitt zur abschließenden Abnahme dokumentiert. Es wurden keine zusätzlichen Cachemechanismen und keine geänderten Assetpfade eingeführt.
Desktop/Web sowie Rätsel 1 auf iPhone und iPad wurden bereits zuvor durch den Nutzer erfolgreich geprüft. Diese Nutzertests betreffen den damaligen Rätsel-1-Stand und ausdrücklich nicht die erst in diesem Tag-3-Auftrag eingebaute Fokuskorrektur. Die korrigierte Fokusrückgabe ist im Desktop-Testbrowser praktisch geprüft; ein kurzer erneuter Nutzertest der Fokuskorrektur auf echtem iPhone und iPad bleibt offen. Dabei sollten insbesondere Touchbedienung, Safari-Safe-Areas, echte Rotation und die Fokusrückgabe nach verschachtelter Navigation kontrolliert werden.
Stand: 17. September 2026
Rätsel 2 ist vollständig in die bestehende Rätsel-, Modal-, Fokus-, Hinweis- und Fehlversuchslogik integriert. Wartungsschublade, Präsentationsarchiv und Versionsvergleich liefern die Quellen. Alle Ansichten verwenden die fünf vorhandenen Raum-Hotspots und das bestehende Schreibtisch-Terminal; es gibt keine parallele Zustandsverwaltung.
Die Rekonstruktion bietet sechs Textbausteine. Genau vier können ausgewählt, entfernt und mit Auf-/Ab-Schaltflächen sortiert werden. Nur Gefahren erkennen → Risiken transparent mitteilen → Handlungsmöglichkeiten empfehlen → Entscheidungen des Menschen respektieren löst das Rätsel. Unvollständige Prüfungen zählen nicht als Fehlversuch. Vollständige falsche Prüfungen erhöhen ausschließlich den Zähler von Rätsel 2; nach Versuch zwei und vier erscheint je eine einmalige Figurenreaktion. Die Hinweise folgen getrennt von Rätsel 1 der Folge 1, 2, 3, 3, ...
Nach korrekter Rekonstruktion bestätigt Daniel Weber die lokale Autorisierung und schaltet HUMAN-CTRL frei. Danach wechselt das aktive Ziel zu Rätsel 3. Die historische Rätsel-2-Etappe endete hier; im aktuellen Gesamtstand sind Rätsel 3 und das Finale vollständig spielbar. Die Labortür bleibt bis zum erfolgreichen Finalschritt D verriegelt.
Zur Laufzeit werden ausschließlich die beiden WebP-Sachbilder und vier SVG-Prinzip-Icons des finalen Rätsel-2-Pakets verwendet, nicht die PNG-Ausgangsbilder. Der Cachewert dieses Entwicklungsschritts wurde bei der anschließenden Entfernen-Korrektur ersetzt; der damalige Abnahmewert war v=20260917-r2-removefix. Quellstand und dist/client werden nach bestandener Prüfung direkt synchronisiert; .openai/hosting.json und dist/server/index.js bleiben unverändert.
Der vollständige Ablauf wurde im Desktop-Testbrowser mit Maus und Tastatur geprüft, einschließlich Quellen, Auswahlgrenze, Abwahl, Sortierung, Fehlversuchsreaktionen, Hinweiskette, Erfolg, erneuter Ansichten, Autorisierung und Übergangsziel. Responsive Browserprüfungen decken Desktop, Tablet-Querformat und schmale Querformate ab. Diese Aussage beschreibt die damalige Prüfung vor der abschließenden Entfernen-Korrektur; deren aktueller Abnahmestand folgt im nächsten Abschnitt.
Stand: 17. September 2026
Rätsel 1 und Rätsel 2 sind vollständig umgesetzt und spielbar. Die Rekonstruktion in Rätsel 2 besitzt für jeden ausgewählten Textbaustein eine eindeutig beschriftete Entfernen-Schaltfläche. Entfernte Bausteine werden sofort wieder in der verfügbaren Auswahlliste angeboten und können erneut ausgewählt oder durch einen anderen Baustein ersetzt werden. Entfernen, Austauschen und Sortieren verändern weder Hinweisstand noch Fehlversuchszähler. Erst eine vollständige falsche Prüfung zählt als Fehlversuch; nach der korrekten Lösung werden Auswahl, Entfernen und Sortierung vollständig gesperrt.
Die Korrektur wurde von Codex im Desktopbrowser praktisch geprüft. Der Nutzer hat die Korrektur anschließend auf einem echten iPhone und einem echten iPad erfolgreich bestätigt. Diese beiden realen Gerätetests sind Nutzertests und keine von Codex selbst durchgeführten Gerätetests.
Nach erfolgreicher Rekonstruktion werden Daniel Webers Identität und gültige Berechtigung bestätigt und das HUMAN-CTRL-Notfallverfahren freigeschaltet. Zum damaligen Stand dieser Abnahme war der Übergang zu Rätsel 3 mit dem passenden Einzel- beziehungsweise Gruppen-Ziel vorbereitet; Rätsel 3 und das Finale wurden erst in den folgenden Entwicklungsschritten umgesetzt. Zu diesem historischen Zwischenstand blieb doorUnlocked auf false und die Labortür verriegelt.
Die damalige technische Abnahme von Rätsel 2 bestätigte JavaScript-Syntax, Browserablauf, Modal- und Fokussteuerung, Neustartlogik, Assetpfade, Browserkonsole sowie die Übereinstimmung sämtlicher vorhandener Gegenstücke zwischen Quelle und dist/client. Alle drei eingebundenen Skripte verwendeten in diesem Abnahmestand in Quelle und Distribution einheitlich den Cachewert v=20260917-r2-removefix.
Stand: 17. September 2026
Rätsel 1 und Rätsel 2 bleiben vollständig umgesetzt. Rätsel 3 ist in die bestehende gemeinsame Detailansicht integriert und ausschließlich über Schreibtisch → HUMAN-CTRL erreichbar; ein neuer Raum-Hotspot wurde nicht ergänzt. Vor der Freischaltung zeigt derselbe Zugang einen gesperrten Zustand. HUMAN-CTRL enthält Übersicht, jederzeit erneut lesbare Sicherheitsregeln und die Sequenzplanung.
Alle vier Module sind vor der Lösung gleichwertig auswählbar. Modul A ist zunächst weder fixiert noch als dauerhaft aktiv gekennzeichnet. Es können höchstens drei Module ausgewählt werden; ausgewählte Module lassen sich separat nach oben oder unten verschieben und entfernen. Eine vollständige Dreiersequenz mit A zählt genau einen Fehlversuch. Erst die richtige Planung B → C → D bestätigt, dass A – Sensorik unverändert aktiv bleibt und nicht ausgeführt wird. Die geplante Sequenz wird lediglich geprüft und nicht technisch ausgeführt.
Der zentrale Spielzustand speichert puzzle3Selection als geordnete Liste, failedAttempts.puzzle3, hintLevels.puzzle3, die einmaligen Reaktionen über triggeredEvents, puzzle3Solved und releaseSequenceReady. Nach Erfolg gelten puzzle3Solved === true, releaseSequenceReady === true, activePuzzle === "finale" und weiterhin doorUnlocked === false. Die Auswahl- und Sortierfunktionen sind dann gesperrt, die vorbereitete Sequenz bleibt abrufbar. Zum damaligen Abschluss von Rätsel 3 war das Finale noch nicht spielbar; seine Ausführung, HUMAN-CTRL-Aktivierung, grüne Türanzeige und Türöffnung wurden im anschließend dokumentierten Finalschritt ergänzt.
Verwendete neue Produktionsassets:
assets/images/nova-r3-modul-a-sensorik.svgassets/images/nova-r3-modul-b-entscheidungsautomatik.svgassets/images/nova-r3-modul-c-menschliche-kontrollinstanz.svgassets/images/nova-r3-modul-d-tuersteuerung.svgDie vier Dateien sind unverändert aus dem freigegebenen Komplettpaket übernommen und bytegleich nach dist/client/assets/images/ synchronisiert. Sie besitzen 64 × 64 Pixel, viewBox="0 0 64 64", transparenten Hintergrund, Linienfarbe #24D8F0, Strichstärke 3.5 und keine eingebrannten Texte oder Zustände. Wiederverwendet werden die bestehende gemeinsame Detailansicht, der neutrale Terminalhintergrund assets/images/nova-r1-terminal-neutral.webp, die bestehenden Zustandssymbole assets/images/nova-r1-status-gesperrt.svg, assets/images/nova-r1-status-verfuegbar.svg, assets/images/nova-r1-status-falsch.svg und assets/images/nova-r1-status-erfolgreich.svg sowie die vorhandenen Schaltflächen-, Fokus- und Hinweisgestaltungen. Mock-up-PNGs, Planungs-DOCX/PDF, Manifest und sonstige Arbeitsdateien aus dem Paket sind nicht als Laufzeitassets eingebunden.
Zum damaligen Rätsel-3-Abnahmestand verwendeten alle drei Skriptreferenzen in Quelle und Distribution den Cachewert v=20260917-r3. Im Desktopbrowser wurden der vollständige Einzelmodus-Ablauf, Zugang, Regeln, Modul-A-Falschlösung, unvollständige und vollständige Fehlversuche, Schwellenreaktionen, Hinweisfolge 1/2/3/3, Auswahl, Entfernen, Austausch, Sortierung, Erfolg, erneutes Öffnen, Zielwechsel, Fokus und weiterhin verriegelte Tür praktisch geprüft. JavaScript-Syntax, Zustandshelfer, Asseteigenschaften, Pfade und Quell-/Distributionsgleichheit wurden automatisiert geprüft. Responsive Regeln und die festgelegten Viewports wurden technisch kontrolliert; echte iPhone- und iPad-Tests für Rätsel 3 wurden von Codex nicht durchgeführt und bleiben als Nutzertests offen.
Stand: 17. September 2026
Das Finale ist vollständig umgesetzt und ausschließlich über Schreibtisch → HUMAN-CTRL erreichbar. Beim ersten regulären Schließen des geprüften Rätsel-3-Bereitschaftszustands erscheint genau einmal die verbindliche Dialogfolge. Anschließend zeigt HUMAN-CTRL eine amberfarbene Finalbestätigung: A – Sensorik bleibt aktiv, B, C und D sind vorgesehen. Abbrechen verlässt die Ansicht ohne Zustandsänderung. Erst MENSCHLICHE KONTROLLE WIEDERHERSTELLEN startet die tatsächliche Ausführung.
Der zentrale Spielzustand wurde um finaleExecutionState (idle, confirming, executing, complete) und finaleExecutionStep (0 bis 3) ergänzt. Eine einzige Bestätigung startet B → C → D automatisch; zwischen den Schritten ist keine weitere Eingabe nötig oder möglich. Jeder verbindliche Schritttext und anschließend ERFOLGREICH werden sichtbar dargestellt. Die Sequenz läuft bei geschlossener Detailansicht weiter, und erneutes Öffnen zeigt den aktuellen Stand, ohne neu zu starten. Einmalige Ereignisse schützen Finaldialog, Ausführungsstart, die drei Erfolge, Türentriegelung, Rot-zu-Grün-Wechsel, sichtbares KLICK, Schlussdialog und Abschlusstext.
Erst nach erfolgreichem Schritt D wird doorUnlocked auf true gesetzt. Die vorhandene Türanzeige wechselt dann ohne neue Raum- oder Türgrafik von Rot zu Grün und zeigt einmal sichtbar KLICK; Audio wird nicht verwendet. Der Abschlussstatus lautet HUMAN-CTRL AKTIV mit aktiver Sicherheitsüberwachung, gesperrter autonomer Entscheidungsgewalt, wiederhergestellter menschlicher Entscheidungshoheit und manueller Türsteuerung. Danach folgen der einmalige Schlussdialog, der Einzel- beziehungsweise Gruppen-Abschlusstext und SPIEL ABGESCHLOSSEN. HUMAN-CTRL bleibt anschließend als nicht bearbeitbare Statusansicht erreichbar.
Wiederverwendet werden die gemeinsame Detailansicht, Fokusfalle, Hintergrundsperre und Neustartlogik, assets/images/nova-r1-terminal-neutral.webp, die vier Modul-SVGs assets/images/nova-r3-modul-a-sensorik.svg bis assets/images/nova-r3-modul-d-tuersteuerung.svg sowie assets/images/nova-r1-status-verfuegbar.svg und assets/images/nova-r1-status-erfolgreich.svg. Es wurden keine neuen Hotspots, Produktionsassets, externen Bibliotheken oder parallelen Zustands-, Dialog- oder Modalsysteme ergänzt. Alle drei Skriptreferenzen und das Stylesheet verwendeten nach der Finale-Beleuchtung einheitlich v=20260917-final-lighting; der aktuelle Cachewert ist im folgenden Abschnitt dokumentiert. Der abgeschlossene Finalzustand erhält damit zusätzlich die vorhandene cyanfarbene Raumaufhellung und den angepassten HUMAN-CTRL-Systemstatus; Spielzustände, Hotspotgeometrie und Assetpfade bleiben unverändert.
Praktisch im Desktopbrowser geprüft wurden der vollständige Einzelmodus vom Start über die Lösungen 4927, die korrekte Schutzauftragsrekonstruktion und B → C → D bis SPIEL ABGESCHLOSSEN, außerdem Finaldialog, Abbrechen und erneutes Öffnen, die automatische Ausführung, Schließen während der Ausführung, Zustandsfortsetzung beim Wiederöffnen, Türstatus, Schlussdialog, Abschlussansicht und bestätigter Neustart. Automatisiert geprüft wurden JavaScript-Syntax, Cachewerte, Referenzen, DOM-/ARIA-Struktur, Assetpfade und die Bytegleichheit aller vorgesehenen Quell-/Distributionspaare. Responsive CSS, Mindestbedienflächen, interne Scrollbarkeit, Safe Areas, Hochformatsperre, Fokus- und Wiederholungsschutz wurden technisch anhand des Codes kontrolliert. Eigene Tests auf echten iPhones oder iPads wurden für das Finale nicht durchgeführt; Touchbedienung, Safari-Safe-Areas, echte Rotation, Hochformatsperre und die festgelegten Querformatgrößen bleiben Teil der Nutzerabnahme.
Stand: 18. September 2026
Alle Spiel-, Objekt-, Rätsel-, HUMAN-CTRL- und Finaleansichten verwenden weiterhin die einzige gemeinsame Detailansicht. Ihr Panel nutzt abhängig von Inhalt und Viewport bis zu 94 dvh und auf breiten Querformaten eine zweispaltige Anordnung: Sachbild beziehungsweise Navigation stehen neben dem eigentlichen Inhalt. Header, Footer, Abstände, Bilder, Karten und Modulzeilen werden bei niedrigen Querformaten kompakter, ohne Texte oder Bedienelemente abzuschneiden. Die lange Rekonstruktions- und Sequenzplanung nutzt auf ausreichend breiten Ansichten zusätzlich Spalten. Vermeidbares internes Scrollen und horizontale Überläufe wurden dadurch entfernt. Es existiert weiterhin genau ein vertikaler Fallback-Scrollbereich innerhalb der Detailansicht; er wird nur bei inhaltlich langen Ansichten und niedrigen Querformat-Viewports benötigt. Header, Schließen-Schaltfläche und Footer-Aktionen bleiben dabei außerhalb dieses Scrollbereichs erreichbar. Rechtsansichten und Dialoge verwenden dasselbe Prinzip; die Informationsansichten verwenden für ihre langen Texte weiterhin einen eigenen Inhaltsbereich. Verschachtelte vertikale Scrollcontainer für denselben Inhalt wurden nicht eingeführt.
Das bestehende dreistufige Hinweissystem bleibt die einzige Zustandsquelle. getNextPuzzleHint() schaltet unverändert höchstens die nächste Stufe frei und begrenzt den Stand auf 3. Innerhalb des geöffneten Hinweisfensters rendert renderPuzzleHint() dagegen ausschließlich bereits freigeschaltete Stufen. Dadurch gilt bei vollständiger Freischaltung für alle drei Rätsel Hinweis 1 ↔ Hinweis 2 ↔ Hinweis 3. Hinweis 1 bietet nur dann „Hinweis 2 →“, wenn Stufe 2 schon freigeschaltet ist; Hinweis 2 bietet „← Hinweis 1“ und gegebenenfalls „Hinweis 3 →“; Hinweis 3 bietet „← Hinweis 2“. Der Wechsel lässt das Fenster offen, setzt den Fokus auf die neue Hinweisüberschrift und verändert weder hintLevels, Fehlversuche, Auswahl, Rätselzustand noch Spielfortschritt. Erneutes Anzeigen zählt nicht erneut, weil keine separate Nutzungsstatistik existiert und die Navigation den Freischalthelfer nicht aufruft.
Praktisch im Browser geprüft wurden alle gemeinsamen Ansichtsarten und der komplette Einzelspielerablauf: Titel, Modusauswahl, Einführung/Überspringen, Ziel, Hauptmenü, Whiteboard, Exponatübersicht, alle vier Exponatdetails, Schreibtisch, gesperrte und geöffnete Wartungsschublade, gesperrtes und freigeschaltetes HUMAN-CTRL, Diagnose-Terminal und Ergebnis, Präsentationsarchiv, Versionsvergleich, Rekonstruktion, HUMAN-CTRL-Übersicht, Sicherheitsregeln, Sequenzplanung, Finalbestätigung, laufende Ausführung und Read-only-Abschlussansicht. Die vollständige Hinweisfolge wurde für Rätsel 1, 2 und 3 getestet; bei Rätsel 2 blieb die leere Auswahl nach der Navigation unverändert. Maus-/Klickbedienung, Tastaturfokus nach dem Hinweiswechsel, Schließen-/Zurückwege, Fokusbindung, Finale, Türstatus und game-complete wurden geprüft.
Responsive Prüfungen erfolgten praktisch bei 1920 × 1080, 1024 × 768, 844 × 393, 667 × 375 und ausdrücklich 844 × 320. Desktop und Tablet zeigen die geprüften Detailansichten ohne unnötigen vertikalen oder horizontalen Überlauf. Bei 844 × 393, 667 × 375 und 844 × 320 bleibt internes Scrollen in den langen Rekonstruktions-, Sequenz-, Finalbestätigungs- und Abschlussinhalten technisch erforderlich: 44-Pixel-Bedienflächen, lesbarer Text, vier Module beziehungsweise Textbausteine und sichere Header-/Footer-Aktionen passen nicht gleichzeitig in die geringe Höhe. Das Panel nutzt dort bereits nahezu den gesamten Viewport, Abstände und Grafiken sind reduziert und die Breite wird zweispaltig genutzt; weiteres Komprimieren würde Lesbarkeit oder Touchziele beeinträchtigen. Kurze Ansichten wie Whiteboard und Übersichten benötigen auch dort keinen vermeidbaren Scrollbereich. Horizontaler Überlauf trat nicht auf. Echte Safari-/Touch-Gerätetests wurden in diesem Arbeitsstand nicht durchgeführt.
Die nachfolgende Breitenkorrektur beseitigt zusätzlich extrem schmale Textspalten in Rekonstruktion und HUMAN-CTRL. Komplexe Editoransichten werden nicht mehr in die schmale Inhaltsspalte des allgemeinen Bild-/Detailrasters gezwungen, sondern nutzen die volle Modalbreite. Das Detailfenster darf bis zu 96vw beziehungsweise 96rem breit werden. Erst ab 75rem Viewportbreite stehen verfügbare Elemente und Auswahl nebeneinander; darunter werden sie gestapelt. Bei höchstens 46rem Breite stehen die Aktionsbuttons von Rekonstruktions- und Modulzeilen in einer eigenen Zeile unter Symbol und Bezeichnung. Normale Bezeichnungen verwenden word-break: normal und overflow-wrap: break-word statt overflow-wrap: anywhere; Mindestbreiten verhindern das Zusammenschrumpfen auf einzelne Zeichen. Textbausteine und Modulnamen bleiben damit horizontal beziehungsweise in wenigen normalen Zeilen lesbar. Notwendiges vertikales Scrollen langer Ansichten auf niedrigen Smartphones bleibt erhalten.
Die Browserkonsole blieb ohne JavaScript-Fehler. Quelle und dist/client sind für index.html, css/style.css, js/game.js und README.md bytegleich synchronisiert. Die vorhandene Informationsansicht enthält die final vorgegebenen Texte für Impressum und Datenschutz sowie die neue Projektinformation. Es wurde weder veröffentlicht noch bereitgestellt. Alle drei Skriptreferenzen und das Stylesheet verwenden jetzt einheitlich den Cachewert v=20260918-legal-project-info.
Stand: 18. September 2026
Entwicklerin des Spiels ist Aija Grosche, Schülerpraktikantin bei der TVG – Technische Visualistik GmbH. Das Projekt entstand im September 2026 im Rahmen des Schülerpraktikums. Für Konzeption, Programmierung, Prüfung und Dokumentation wurden KI-gestützte Entwicklungswerkzeuge eingesetzt, insbesondere OpenAI Codex und ChatGPT-Agenten. Diese Systeme dienten ausschließlich als Entwicklungsunterstützung; die fachliche Auswahl, Steuerung, Prüfung und Abnahme der Umsetzung erfolgte durch die Projektbeteiligten. OpenAI, Codex und ChatGPT werden weder als Betreiber noch als rechtlich Verantwortliche oder rechtliche Urheber des Angebots dargestellt.
Das Hauptmenü enthält die drei getrennten Informationsbereiche Impressum, Datenschutz und Projektinformationen. Impressum und Datenschutz verwenden weiterhin das bestehende Informationsmodal und enthalten ausschließlich die jeweils vorgegebenen rechtlichen beziehungsweise datenschutzbezogenen Inhalte. Die Projektinformationen nennen Entwicklerin, Praktikum, Projektzeitraum und Entwicklungsunterstützung. Dort ist diese vollständige README in einem nativen details-/summary-Bereich als lokal eingebettete Programmierbeschreibung auf- und zuklappbar. Sie wird nicht per fetch() geladen, benötigt keine Markdown-Bibliothek und bleibt deshalb auch über file:// verfügbar. Alle drei Ansichten besitzen genau einen vertikalen Inhalts-Scrollbereich; Header und Schließen-Schaltfläche bleiben sichtbar.
Die technische Datenschutzprüfung des Spielcodes ergab weiterhin: keine Cookies, kein localStorage, kein sessionStorage, keine IndexedDB, keine persistente Spielstandspeicherung, keine externen Fonts, CDNs, externen Medien oder APIs, kein spielseitiges Analytics- oder Tracking-Skript, keine Werbung, Benutzerkonten, Logins, Datenbank oder personenbezogenen Formulare. Die im Datenschutztext beschriebene IONOS-Verarbeitung ist hostingseitig und nicht Bestandteil des JavaScript-Spielcodes. Es wurde mit diesem Arbeitsstand weder veröffentlicht noch bereitgestellt.
Der Cachewert für Stylesheet und alle drei Skriptreferenzen lautet im finalen Informationsstand einheitlich v=20260918-legal-project-info.