Terminal im Geraetehaus mit Offline-Betrieb ergaenzen

Phase 4: eine eigene Oberflaeche unter /kiosk fuer das Wandtablet in der
Fahrzeughalle — mit Handschuhen bedienbar und arbeitsfaehig, wenn das Netz
weg ist.

Datenmodell: Fahrt, Anwesenheit, Waescheabgabe, Inventurgang,
Inventurposten, KioskVorgang und SyncKonflikt. Die Kennung eines Vorgangs
erzeugt der Browser beim Einreihen und ist damit der Idempotenzschluessel;
kommt derselbe Vorgang nach abgebrochener Uebertragung erneut an, erkennt
ihn der Server wieder. Die Datenbank setzt vier Regeln selbst durch und
verweigert UPDATE und DELETE auf kiosk_vorgang.

Offline: von Hand geschriebener Service Worker, Warteschlange in der
IndexedDB (Dexie), Fotos als Blob daneben, sichtbarer Zustand als Leiste
ueber allem. Was sich beim Nachtragen nicht anwenden laesst, landet als
Konflikt unter /terminal statt verworfen zu werden.

Dazu: Anmeldung per Ausweis, PIN oder signierter QR-Marke vom Handy,
Hallenmonitor mit optionalen DWD-Warnungen, Installation als App.

Behoben: die Warteschlange zog ihren Wiederholungstakt bei jedem Rendern
neu auf und haette einen liegen gebliebenen Vorgang nie ein zweites Mal
geschickt. Gefunden vom Offline-E2E-Test.

31 neue Tests (20 Unit, 11 gegen eine echte Datenbank, 9 E2E je Browser).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/DEVLOG.md

@@ -15,7 +15,105 @@ Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
 | Phase 1 — Nachtrag Geräteformular | 0:50 h | 1 | 03.09.2026 |
 | Phase 2 — Wartung und Prüfung | 2:25 h | 1 | 03.09.2026 |
 | Phase 3 — Einsätze und Übungen | 2:10 h | 1 | 03.09.2026 |
-| **Summe** | **7:40 h** | **5** | |
+| Phase 4 — Kiosk-PWA im Gerätehaus | 3:00 h | 1 | 03.09.2026 |
+| **Summe** | **10:40 h** | **6** | |
+
+---
+
+## 2026-09-03 · Phase 4 — Kiosk-PWA im Gerätehaus
+
+**14:40 – 17:40 · 3:00 h · Version 0.5.0**
+
+### Was entstanden ist
+
+Das Terminal an der Wand. Sieben neue Tabellen, eine eigene Oberfläche unter
+`/kiosk`, ein Service Worker und eine Warteschlange, die den Betrieb ohne Netz
+trägt.
+
+| Bereich | Dateien |
+|---|---|
+| Datenmodell | `Fahrt`, `Anwesenheit`, `Waescheabgabe`, `Inventurgang`, `Inventurposten`, `KioskVorgang`, `SyncKonflikt` |
+| Offline | `public/sw.js`, `lib/kiosk/outbox.ts`, `components/kiosk/warteschlange.tsx` |
+| Anmeldung | `lib/kiosk/anmeldemarke.ts`, Anbieter `terminal-marke` in `lib/auth.ts`, `components/kiosk/anmeldung.tsx` |
+| Oberfläche | `app/kiosk/` mit Kacheln, sechs Wizards, Monitor und Einrichtung |
+| Verwaltung | `app/(app)/terminal/`, `app/(app)/anmeldemarke/` |
+| Server | `server/routers/kiosk/kiosk.ts`, `lib/integrations/wetter.ts` |
+| Tests | `tests/unit/kiosk-marke.test.ts`, `kiosk-outbox.test.ts`, `kiosk-datenbank.test.ts`, `tests/e2e/kiosk.spec.ts` |
+
+### Entscheidungen
+
+**Die Warteschlange ist der einzige Weg, auch online.** Es wäre naheliegend,
+online direkt zu senden und nur im Fehlerfall zu puffern. Dann gäbe es zwei
+Wege durch den Code — und der seltenere wäre der ungetestete, also genau der,
+der im Gerätehaus gebraucht wird. Jetzt läuft alles durch dieselbe Bahn, und
+der Offline-Fall ist der Normalfall mit längerer Wartezeit.
+
+**Die Kennung erzeugt der Browser, nicht der Server.** `crypto.randomUUID()`
+beim Einreihen. Damit ist sie derselbe Wert über beliebig viele Sendeversuche
+hinweg, und der Server kann einen wiederholten Vorgang erkennen, statt ihn
+doppelt zu buchen. Die Kennung ist der Primärschlüssel von `kiosk_vorgang`, und
+die Datenbank verweigert dem Anwendungszugang `UPDATE` und `DELETE` darauf —
+sonst ließe sich die Spur nachträglich glätten.
+
+**Konflikte werden nicht erzwungen und nicht verworfen.** Ein Tablet, das drei
+Tage offline war, schickt Vorgänge, deren Ziel es nicht mehr gibt oder das
+inzwischen festgeschrieben ist. Beides ist kein Fehler des Anwenders. Der
+Vorgang landet in `sync_konflikt`, verschwindet aus der Warteschlange (er ist
+angekommen) und wartet unter `/terminal` auf eine Entscheidung.
+
+**Die Prüfung bleibt online.** Der Wizard aus Phase 2 mit Checkliste, Messwerten,
+Fotos und Unterschrift lässt sich nicht sinnvoll in eine Warteschlange legen —
+und ein halb erfasstes Protokoll ist schlechter als keins. Die Kachel zeigt
+deshalb „braucht Netz" und ist ohne Verbindung gesperrt, statt ins Leere zu
+führen. `PRUEFUNG_ERFASSEN` steht trotzdem im Datenmodell: die Atemschutzprüfung
+in Phase 5 ist kurz genug dafür.
+
+**Die Anmeldemarke wird signiert, nicht gespeichert.** HMAC über Person, Wehr
+und Zeitstempel mit `AUTH_SECRET`, gültig 60 Sekunden. Keine Tabelle, kein
+Aufräumjob, kein zweiter Ort mit einem Geheimnis — und ein abfotografierter
+Code aus der Umkleide ist nach einer Minute wertlos.
+
+**Der Kartenleser hängt am Fenster, nicht an einem Eingabefeld.** Ein RFID-Leser
+tippt die Kennung in Millisekunden und schließt mit Enter ab. Wer die Karte
+auflegt, soll vorher nichts antippen müssen; unterschieden wird am
+Anschlagstempo (60 ms), nicht am Fokus.
+
+**Wetterwarnungen sind aus.** Es ist die einzige Verbindung, die FLORIAN von
+sich aus nach außen aufbaut. Wer sie einschaltet, soll das bewusst tun; ohne
+`DWD_WARNCELL` passiert nichts, und bei Ausfall bleibt die Kachel leer statt
+den Monitor aufzuhalten.
+
+### Wo es gehakt hat
+
+| Problem | Ursache | Lösung |
+|---|---|---|
+| Die Warteschlange schickte einen liegen gebliebenen Vorgang nie ein zweites Mal | `jetztSenden` hatte das Mutationsobjekt von React Query in den Abhängigkeiten. Das ist bei jedem Rendern ein neues, also änderte sich die Identität der Funktion dauernd, der Effekt lief neu, zog den 20-Sekunden-Zeitgeber neu auf — und der lief nie ab. Dazu wurde der `online`-Zuhörer ständig neu registriert und verpasste das Ereignis manchmal | Mutation, tRPC-Werkzeuge und das „läuft gerade"-Kennzeichen über Referenzen statt über Abhängigkeiten. Damit ist `jetztSenden` stabil |
+| Der Produktionsbuild brach bei `/kiosk/einrichten` ab | `useSearchParams()` ohne Suspense-Grenze lässt sich nicht vorab erzeugen | `<Suspense>` um das Formular |
+| Der Build brach bei `wetter.ts` ab | Der Hallenmonitor ist eine Client-Komponente und importierte die Warnstufentexte aus einem `server-only`-Modul | Texte nach `lib/integrations/wetter-texte.ts`, dieselbe Trennung wie bei `qr.ts` / `qr-parser.ts` |
+| Der Outbox-Test lief ins Leere | `speicherVerfuegbar()` fragt `window`, und die Testsuite läuft in Node | Diese Datei unter jsdom (`@vitest-environment`) mit `fake-indexeddb` |
+| Das Einrichtungsformular ließ sich im Test nicht abschicken | Playwright klickte, bevor der Effekt die Felder aus der Adresse gefüllt hatte — das Pflichtfeld war leer | Im Test auf die Feldwerte warten |
+| Der Idempotenztest sah in der Verwaltung kein Anmeldeformular | Im selben Browserkontext lief noch die Terminalsitzung, und `/anmelden` leitet Angemeldete weiter | Prüfung in einen eigenen Test mit frischem Kontext |
+| `getByText("B 3 Wohnhausbrand")` in den Einsatztests wurde mehrdeutig | Frühere E2E-Läufe haben Einsätze mit ähnlichem Stichwort in der Demowehr angelegt | `exact: true`; die eigentliche Ursache bleibt offen (siehe unten) |
+
+### Abweichung von der Vorgabe
+
+**Kein Auto-Logout nach 90 Sekunden.** Die Roadmap nennt 90 Sekunden, die
+Konfiguration hatte schon `KIOSK_IDLE_TIMEOUT=120`. Der konfigurierte Wert
+gewinnt — 90 Sekunden sind knapp, wenn jemand mitten in einer Mangelmeldung
+noch das Foto machen muss. Die Roadmap ist entsprechend berichtigt.
+
+**`npm run lint` läuft in diesem Projekt nicht.** Es gibt keine
+ESLint-Konfiguration; `next lint` fragt interaktiv nach einer. Das ist älter als
+diese Phase und in ihr nicht behoben — es würde quer über alle bisherigen
+Dateien Befunde erzeugen und gehört in einen eigenen Schritt.
+
+### Nachweise
+
+- `npx tsc --noEmit` — ohne Ausgabe
+- `npm run test` — 258 Tests grün, davon 19 gegen eine echte Datenbank
+- `npx playwright test tests/e2e/kiosk.spec.ts` — 18 Tests grün (Desktop und Tablet)
+- `npm run build` — 34 Routen, 103 kB gemeinsames JavaScript
+- `npm run db:seed` — Fahrtenbuch, Anwesenheiten und Wäsche angelegt
 
 ---