# Smash Kitchen — Einrichtung und Übergabe

Enthalten: servergespeicherte Tickets, Küchen-/Servicerolle, Status Neu → In Arbeit → Bereit → Ausgegeben, Stornieren, vorherigen Status zurücknehmen, 15-Minuten-Countdown, Pause/Fortsetzen, +5 Minuten und frei einstellbarer Neustart (1–120 Minuten). Abgleich alle vier Sekunden; bei Verbindungsproblemen keine Statusänderungen. Optionaler Ton bei neuen Tickets nach Aktivierung.

Die öffentliche Burger-Demo bleibt eine lokale Simulation. Nur der ausdrücklich aktivierte, angemeldete Team-Modus überträgt Testtickets. Standardmäßig ist `test_mode` aktiv. Keine Zahlung, keine Kasse, kein Bondruck, kein öffentlich zugängliches Echtbestellsystem. Die Software ist ein Pilot, keine Zusicherung für unbeaufsichtigten Restaurantbetrieb.

## 1. Hosting vorbereiten

- PHP 8.1+ mit Sessions, PDO und PDO_SQLite aktivieren. Für diese Fassung wird keine MySQL-Datenbank benötigt.
- Gültiges HTTPS ist für Anmeldung, Bestellübertragung und Kontaktformular erforderlich. Die öffentliche Demo funktioniert auch ohne Server. HTTPS-Prüfungen nicht abschalten.
- Genau eine Domain für alle Teamgeräte verwenden (z. B. 438cloud.com, nicht auf einem Gerät www und auf einem anderen ohne www).
- Vorhandene Dateien sichern. ZIP-Inhalt mit assets direkt in das Domainverzeichnis laden. Nur eine Startseite: `index.htm`. Kein automatischer Upload erfolgt.

## 2. Privaten Speicher und Setup-Schlüssel eintragen

`kitchen-config.php` in einem Texteditor bearbeiten:

- `storage_dir`: absoluter Pfad zu einem privaten Verzeichnis **außerhalb aller öffentlich erreichbaren Domainverzeichnisse**. Der vorgeschlagene Nachbarordner ist nur ein Ausgangspunkt. Ist deine Domain direkt auf das Account-Hauptverzeichnis gerichtet, einen separaten nicht öffentlichen Speicherbereich mit dem Hoster festlegen. Der übergeordnete Ordner muss existieren und für PHP beschreibbar sein. Die Anwendung lehnt Speicher unter ihrem erkannten Webroot ab; zusätzliche Domains/Aliase musst du selbst berücksichtigen.
- `setup_key`: zufälliges Geheimnis mit mindestens 32 Zeichen aus einem Passwortmanager eintragen. Kein Standardpasswort wird mitgeliefert. Schlüssel nicht per URL, HTML oder JavaScript verteilen.
- `default_minutes` bleibt **15**; `test_mode` bleibt zunächst **true**.
- `hosts` nur ändern, falls du eine andere Domain nutzt.

Dann `https://438cloud.com/kueche.html` öffnen. Setup-Schlüssel, neues Küchenpasswort und neues Servicepasswort eingeben (je 12–128 Zeichen, unterschiedliche zufällige Passwörter empfohlen). Nach erfolgreichem Setup `setup_key` wieder auf eine leere Zeichenfolge setzen. Das Setup ist nach Einrichtung auch mit bekanntem Schlüssel gesperrt.

## 3. Ablauf auf zwei Geräten testen

1. Küchentablet: `kueche.html` als **Küche** anmelden. Bildschirm geöffnet lassen und Energiesparmodus für den Test vermeiden. „Ton aktivieren“ ist optional.
2. Bestellgerät: `kueche.html` als **Service** anmelden; „Bestellung erfassen“ öffnen. Dadurch startet `demo-smash.html?kitchen=1`.
3. Burger mit Extra Cheese und Ohne Zwiebeln sowie Fries wählen; Tisch 3 auswählen. „Testticket an Küchenserver senden“ anklicken.
4. Erst eine Serverbestätigung mit Ticketnummer bedeutet, dass das Ticket gespeichert wurde. Es erscheint gewöhnlich beim nächsten Vier-Sekunden-Abgleich in der Küche.
5. „Zubereiten“, „Bereit“ und „Status zurück“ testen. Bei Bereit hält der Timer an; bei Rücknahme läuft die verbliebene Zeit weiter, auch wenn sie negativ/überfällig ist. Ein manuell pausierter Timer bleibt nach Statusrücknahme pausiert.
6. Pause/Fortsetzen, +5 Minuten, Timerneustart und Storno samt Rücknahme testen. Servergerät/Browser neu laden: Tickets und Countdown müssen erhalten bleiben.
7. Dasselbe Ticket auf zwei Küchenfenstern ändern: ein veralteter Stand wird abgelehnt und neu geladen, nicht still überschrieben.
8. Netzwerk kurz trennen: sichtbare Warnung, keine erfolgreichen Änderungen vortäuschen. Nach Wiederverbindung aktualisieren. Die Zeit läuft serverbasiert weiter.

Bei unklarer Übertragung keine neue Bestellung blind erfassen. „Offene Übertragung prüfen“ auf dem Bestellgerät sendet dieselbe gespeicherte Vorgangskennung erneut; der Server liefert das bestehende Ticket zurück. Bei Erfolg wird die lokale Demo-Bag geleert. Dies funktioniert innerhalb desselben Browser-Tabs, auch nach Neuladen. Tab/Sitzungsspeicher nicht vor der Klärung löschen. Bei verlorenem Tab den Ticketbestand in der Küche prüfen. Der Warenkorb selbst wird nicht dauerhaft gespeichert.

## 4. Betrieb, Zugriff und Grenzen

- Küchenrolle darf Tickets und Timer ändern; Service darf Tickets erfassen und ansehen. Beide nutzen Rollenpasswörter, keine individuellen Mitarbeiterkonten. Der Verlauf zeigt daher Rollen, nicht Personen.
- „Status zurück“ betrifft ausschließlich Statuswechsel, nicht Timerneustarts oder Zeitverlängerungen. Letzte 100 Ereignisse je Ticket werden angezeigt/gespeichert; Statusrücknahmen maximal 100 Schritte.
- Höchstens 100 offene Tickets einschließlich Bereit. Alle offenen sowie die letzten 50 ausgegebenen/stornierten Tickets werden angezeigt. Ältere bleiben in der Datenbank; es gibt keine automatische Löschung/Archivierung. Für längeren Einsatz Aufbewahrung, Export/Archivierung, Überwachung und Kapazität gesondert planen.
- Preise werden aus `kitchen-menu.json` serverseitig berechnet. Bei Menüänderungen auch `demo-data.js` und statische Preistexte in `demo-smash.html` abstimmen.
- Datenbank enthält Produkte, Mengen, Tisch, Zeiten, Status und Rollenverlauf, keine Namen/Adressen der Gäste. Login-Spamschutz speichert gehashte IPs und Versuchszähler; abgelaufene Einträge werden beim nächsten Anmelde-/Setupversuch nach 15 Minuten entfernt. Session-Cookie: `smash_kitchen`, Secure, HttpOnly, SameSite Strict; Anmeldung läuft nach 12 Stunden Inaktivität ab. Gehashte IPs sind keine garantierte Anonymisierung.
- Datenbank `kitchen.sqlite` und eigene Konfiguration regelmäßig sichern. Für eine konsistente einfache Dateisicherung den Betrieb kurz pausieren; keine laufenden Schreibzugriffe während der Kopie. Wiederherstellung vor Produktiveinsatz testen. Die ZIP enthält keine Datenbank und keine Zugangsdaten.
- Bei späteren Updates die eingerichtete `kitchen-config.php` und den privaten Datenordner **nicht überschreiben/löschen**. Bei vergessenem Rollenpasswort ist eine gezielte administrative Passwortänderung nötig; nicht einfach die Datenbank löschen.
- Browser können Hintergrundtabs/Audio aussetzen. Keine Push-Benachrichtigung bei geschlossenem Browser. Küche sichtbar geöffnet halten; bei Serverausfall auf einen vorher festgelegten manuellen Ablauf wechseln.
- Öffentlicher Gast-Checkout, Bezahlung, Drucker, POS/Kasse, Lieferdienst-Anbindung und verifizierte Allergendaten sind nicht enthalten. Anbieter-/Datenschutzhinweise, echte Betriebsdaten und belastbare Ausfallprozesse fehlen noch für einen echten Restaurantstart.

## Prüfstatus dieser Lieferung

Automatisierte PHP-8.3-Tests in einer isolierten Testlaufzeit: Timer/Status-Modell, Eingabevalidierung, serverseitige Preise, Setup, Login, HTTPS-/Origin-/CSRF-Schutz, Rollenrechte, Ticketpersistenz zwischen Anfragen, Doppelübertragung und Versionskonflikte. Zusätzlich JavaScript- und statische HTML-/Assettests. Diese Tests ersetzen keinen tatsächlichen Zwei-Geräte-Test auf ALL-INKL.

Nicht geprüft: dein Hosting mit PDO_SQLite und privaten Dateirechten, reale Netzwerklatenz, Tablet-/Browserdarstellung im Betrieb, Last-/Langzeitverhalten und tatsächlicher E-Mail-Eingang. Keine Serverdateien wurden durch uns hochgeladen.