feat(superadmin): migrate internal docs from docusaurus to guava kb

docs/superadmin-kb/de/01-grundlagen/01-operations-manual.md

@@ -0,0 +1,167 @@
+---
+title: Betriebshandbuch & Ops-Startseite
+---
+
+Willkommen im Betriebshandbuch von Fotospiel. Dieses Dokument ist der Einstiegspunkt für alle, die die Plattform betreiben: Infrastruktur‑Ops, On‑Call, Support mit erweiterten Rechten und Produkt‑Owner, die Auswirkungen von Änderungen verstehen möchten.
+
+Ziel ist, dass du von hier aus schnell zu den relevanten Runbooks und Referenzen springen kannst.
+
+## 1. Systemübersicht & Verantwortlichkeiten
+
+- **Rollen & Verantwortlichkeiten**
+  - Wer ist für welche Ebene zuständig? (App‑Verfügbarkeit, Infrastruktur, Sicherheit, Abrechnung, Support.)
+  - Empfehlung: definiere mindestens _On‑Call_, _Plattform‑Ops_ und _Support (2nd Level)_ als feste Rollen – diese Seite ist für alle drei.
+- **Systemlandschaft (High‑Level)**
+  - Laravel App + Nginx + Redis + MySQL.
+  - Async‑Pipeline: Queues (`default`, `media-storage`, `media-security`, `notifications`) und Horizon.
+  - Satelliten: Photobooth‑FTP + Control‑Service, SuperAdmin Knowledge Base (`/super-admin/docs`), Monitoring/Dokploy.
+  - Externe Dienste: Lemon Squeezy (Billing), RevenueCat (Mobile‑Abos), E‑Mail Provider, Logging/Monitoring (Loki/Grafana o.ä.).
+
+> TODO: Ergänze ein Architekturdiagramm aus Sicht des Betriebs (z.B. als PNG oder PlantUML) und verlinke es hier.
+
+## 1.1 Superadmin‑Kontrollfläche & Zugriffs‑Matrix
+
+Die Superadmin‑Konsole ist für operative Kontrolle und Eskalation gedacht – nicht für tägliche Tenant‑Arbeit. Ziel ist eine minimale, aber vollständige Kontrollfläche.
+
+**Minimaler Control Surface (Superadmin)**
+- **Tenant‑Lifecycle & Limits:** Aktivieren/Sperren, Grace‑Periode, Löschung/Anonymisierung, Limits (Fotos/Event, Storage), Audit‑Timeline.
+- **Commercial & Billing:** Pakete/Addons, Tenant‑Pakete, Käufe/History, Gutscheine/Coupons.
+- **Event‑Oversight:** Events/Fotos global, Moderations‑Queues, Tenant‑Feedback.
+- **Plattform & Compliance:** Legal Pages, Datenexporte, Audit‑Log.
+- **Infra & Storage:** Storage Targets, Photobooth Settings, Deployments/Logs.
+
+**Zugriffs‑Matrix (Soll)**
+
+| Bereich | Superadmin | Tenant‑Admin | Gast |
+| --- | --- | --- | --- |
+| Tenant‑Lifecycle & Limits | RW | R (own) | – |
+| Tenant‑Pakete & Billing | RW | R (own) | – |
+| Events/Photos (global) | RW | RW (own) | R/W (event scope) |
+| Moderation/Feedback | RW | RW (own) | – |
+| Tasks/Emotions/Event‑Types | RW | RW (own) | R (event scope) |
+| Users (Platform) | RW | R (own) | – |
+| Legal/Content | RW | R | R (public) |
+| Storage/Photobooth/Infra | RW | R | – |
+| Audit‑Log (Admin‑Aktionen) | R | – | – |
+
+**Nicht‑Ziele**
+- Superadmin ersetzt keine Tenant‑Admins für Tagesgeschäft, nur Eskalation.
+- Kein zusätzliches Tracking/PII‑Logging ohne Privacy‑Update.
+- Keine Infrastruktur‑Mutation ohne explizite Freigabe.
+
+## 1.2 Superadmin‑Roadmap (geplante Seiten & Zweck)
+
+Diese Seiten sollen praktische Steuerung über Tenant‑Admins und die Guest‑Experience geben, ohne ins Tagesgeschäft abzurutschen.
+
+- **Moderation‑Queue (Guest‑Content):** Flagged Fotos/Feedback sammeln, bulk hide/delete/resolve, sauberes Audit.
+- **Guest‑Policy‑Settings:** Default‑Toggles (Downloads/Sharing), Rate‑Limits, Retention‑Defaults, damit neue Events konsistent starten.
+- **Ops‑Health‑Dashboard:** Queue‑Backlog, failed jobs, Storage‑Schwellen, Upload‑Pipeline‑Health auf einen Blick.
+- **Compliance‑Tools:** DSGVO‑Export‑Requests und Retention‑Overrides pro Tenant/Event.
+- **Superadmin‑Audit‑Log:** Jede Admin‑Aktion nachvollziehbar (ohne PII‑Payloads).
+- **Tenant‑Announcements:** Zielgerichtete Hinweise/Release‑Notes an Tenant‑Admins, inkl. Zeitplanung.
+- **Integrations‑Health:** Status‑Board für Lemon Squeezy/RevenueCat/Webhooks inkl. Störungen.
+
+## 2. Deployments & Infrastruktur
+
+Diese Kapitel erklären, wie die Plattform in Docker/Dokploy betrieben wird.
+
+- **Docker-Deployment (Compose‑Stack)**
+  - `docs/ops/deployment/docker.md` – Referenz für `docker-compose.yml`, Services, Volumes, Migrations und Scheduler‑Setup.
+- **Dokploy-Deployment (PaaS)**
+  - `docs/ops/deployment/dokploy.md` – Wie die gleichen Services als Dokploy‑Compose‑Stacks betrieben werden, inkl. SuperAdmin‑Integration.
+- **Join-Token-Analytics & Public API**
+  - `docs/ops/deployment/join-token-analytics.md` – Konfiguration der Analytics‑Pfade für Join‑Tokens.
+  - `docs/ops/deployment/public-api-incident-playbook.md` – Runbook für Public‑API‑Störungen (Rate‑Limits, Abuse, Outages).
+- **Lokale Podman/Dev-URLs**
+  - `docs/ops/deployment/lokale-podman-adressen.md` – Übersicht über lokale Services/Ports bei Podman‑Setups.
+
+Fragen zur Infrastruktur (Netzwerk, TLS, DNS, Backups) sollten immer zuerst gegen diese Dokumente geprüft werden.
+
+## 3. Queues, Storage & Medien-Pipeline
+
+Fotos sind das Herz des Produkts – entsprechend wichtig ist ein klarer Blick auf die Medien‑Pipeline.
+
+- **Queues & Worker**
+  - `docs/ops/queue-workers.md` – Wie die Worker‑Container (`queue`, `media-storage-worker`, `media-security-worker`, `notifications`) gestartet, skaliert und überwacht werden.
+- **Media Storage & Archivierung**
+  - `docs/ops/media-storage-spec.md` – Detaillierte Beschreibung, wie Uploads in den „hot“‑Storage laufen, wie `event_media_assets` gepflegt werden und wie Archive‑Jobs funktionieren.
+- **Upload-Gesundheit & Notifications**
+  - `docs/ops/guest-notification-ops.md` – Runbook für das Notification‑Center, Push‑Registrierung und Upload‑Health‑Alerts.
+
+> TODO: Ergänze ein zentrales „Storage & Queues Monitoring“-Kapitel mit konkreten Schwellenwerten und Alarmierung (z.B. Einbindung von Horizon, Redis‑Monitoring, Log-Channels).
+
+## 4. Photobooth-Pipeline
+
+Die Photobooth‑Integration hat eigene Betriebsanforderungen:
+
+- `docs/ops/photobooth/README.md` – Überblick über Photobooth‑Setup und Datenfluss.
+- `docs/ops/photobooth/control_service.md` – Steuer‑API (User‑Provisionierung, Credentials, Rate‑Limits).
+- `docs/ops/photobooth/ops_playbook.md` – Operatives Playbook für Aktivierung, Fehleranalyse und Incident‑Response rund um Photobooth‑Uploads.
+
+> Prüfe vor großen Events mit gebuchten Photobooths diese Playbooks und stelle sicher, dass Volumes, Credentials und Scheduler korrekt konfiguriert sind.
+
+## 5. Störungs- & Incident-Runbooks
+
+Die folgenden Dokumente sind deine erste Anlaufstelle im Incident‑Fall:
+
+- **Major Incidents & Eskalation**
+  - `docs/ops/incidents-major.md` – genereller Rahmen (SEV‑Levels, Triage, Kommunikation, Postmortems) und Verweise auf die spezifischen Runbooks unten.
+- **Public API Störungen**
+  - `docs/ops/deployment/public-api-incident-playbook.md` – Schritt‑für‑Schritt‑Plan bei Missbrauch, Fehlerspitzen oder Ausfällen der öffentlichen APIs.
+- **Upload-/Medien-Probleme**
+  - `docs/ops/media-storage-spec.md` – Referenz, welche Queues/Jobs beteiligt sind und wie man Fehlerzustände erkennt (z.B. lange „pending“-Assets, gescheiterte Archivierung).
+  - `docs/ops/guest-notification-ops.md` – Upload‑Alerts und Gastbenachrichtigungen.
+- **Photobooth-Incidents**
+  - `docs/ops/photobooth/ops_playbook.md` – Vorgehen bei ausfallendem FTP, Ingest‑Fehlern oder Sicherheitsvorfällen (Credentials).
+
+Zusätzlich gibt es kurze „How‑to“-Runbooks für häufige Supportfälle:
+
+- `docs/ops/howto-tenant-package-not-active.md` – Zahlung erfolgreich, Paket nicht aktiv.
+- `docs/ops/howto-guest-upload-failing.md` – Gäste können nicht hochladen.
+- `docs/ops/howto-photobooth-no-photos.md` – Photobooth‑Uploads landen nicht im Event.
+- `docs/ops/howto-dsgvo-delete-photo.md` – DSGVO‑Löschung eines konkreten Fotos.
+
+> TODO: Ergänze ein allgemeines „Major Incident“‑Kapitel (SEV‑1/2 Definition, Kommunikationskanäle, Vorlagen) und verlinke es hier.
+
+## 6. Prozesse, Roadmap & Änderungen
+
+Der Betreiber muss wissen, welche größeren Änderungen anstehen oder kürzlich live gegangen sind.
+
+- **Roadmap & Epics**
+  - Aktive Epics und offene Arbeitspakete werden in bd gepflegt (`bd list --status=open`, `bd ready`).
+- **Changes & Retro-Notizen**
+  - Lessons Learned, Follow-ups und Incident-Maßnahmen werden als bd-Issues oder Issue-Notizen festgehalten.
+
+Als Betreiber lohnt es sich, vor größeren Deployments die offenen bd-Issues zu prüfen, um Seiteneffekte zu antizipieren.
+
+## 7. Tests, Qualität & Releases
+
+Stabile Releases sind Grundvoraussetzung für ruhigen Betrieb:
+
+- **E2E-Tests & Qualität**
+  - `docs/testing/e2e.md` – beschreibt, welche End‑to‑End‑Tests existieren und wie sie als Smoke‑Suite für Releases verwendet werden können.
+- **Release-Prozess (Entwurf)**
+  - `docs/ops/releases.md` – Checkliste für CI‑Pipelines, Staging‑Deploy, Prod‑Rollout, Smoke‑Tests und Rollback‑Überlegungen.
+
+## 8. Nächste Schritte für das Betriebshandbuch
+
+Die folgenden Kapitel sind als eigenständige Runbooks angelegt und sollten mit der Zeit weiter gefüllt werden:
+
+- **Rollen & On-Call-Handbuch**
+  - `docs/ops/oncall-roles.md` – definiert Platform‑Ops, On‑Call, Support und Produktrollen sowie Eskalationswege.
+- **On-Call Cheat Sheet**
+  - `docs/ops/oncall-cheatsheet.md` – schnelle Übersicht über wichtige Kommandos, Logs und Dashboards für Incidents.
+- **Support & Eskalation**
+  - `docs/ops/support-escalation-guide.md` – beschreibt, welche Informationen Support von Kunden einsammeln sollte, bevor an Ops eskaliert wird.
+- **Backup & Restore / Disaster Recovery**
+  - `docs/ops/backup-restore.md` – Was gesichert werden muss, Restore‑Szenarien und DR‑Übungen.
+- **DSGVO & Compliance-Operationen**
+  - `docs/ops/compliance-dsgvo-ops.md` – Praktische Abläufe für Auskunfts‑/Löschanfragen, Retention und Dokumentation.
+- **Billing & Zahlungs-Operationen**
+  - `docs/ops/billing-ops.md` – Umgang mit Zahlungsproblemen, Webhook‑Fehlern und Paket‑Inkonsistenzen.
+- **Monitoring & Observability**
+  - `docs/ops/monitoring-observability.md` – Welche Signale, Metriken und Alerts es geben sollte.
+- **Architektur-Diagramme**
+  - `docs/ops/diagrams.md` – Mermaid‑Diagramme für Media‑Pipeline und Checkout/Billing‑Flow.
+
+Das Betriebshandbuch bleibt damit ein lebendes Dokument. Neue Runbooks sollten unter `docs/ops/` entstehen und hier verlinkt werden, damit Operatoren einen klaren Einstiegspunkt behalten.

docs/superadmin-kb/de/01-grundlagen/02-oncall-roles.md

@@ -0,0 +1,125 @@
+---
+title: Rollen & On-Call-Handbuch
+---
+
+Dieses Dokument beschreibt, **wer** im Betrieb wofür zuständig ist und **wie** On‑Call‑Bereitschaft organisiert wird. Es ergänzt die technischen Runbooks um eine klare Verantwortungsebene.
+
+> Hinweis: Konkrete Namen/Kontaktdaten sollten nicht in Git stehen, sondern getrennt (z.B. in einem internen Adressbuch oder Passwort‑Safe). Dieses Dokument definiert Rollen und Prozesse.
+
+## 1. Rollenübersicht
+
+### 1.1 Platform Ops
+
+- Verantwortlich für:
+  - Infrastruktur (Docker/Dokploy‑Stacks, Netzwerke, TLS, Backups).
+  - Technische Verfügbarkeit der Services (App, Queues, DB, Redis, Storage).
+  - Umsetzung und Pflege der Runbooks unter `docs/ops/`.
+- Typische Aufgaben:
+  - Deployments koordinieren (`docker-compose`, Dokploy, Migrations).
+  - Monitoring/Alerting pflegen (`ops/monitoring-observability.md`).
+  - Incident‑Response bei SEV‑1/SEV‑2 (`ops/incidents-major.md`).
+
+### 1.2 On-Call Engineer
+
+- Rolle, die im wechselnden Turnus (z.B. wöchentlich) On‑Call ist.
+- Verantwortlich für:
+  - Reaktion auf laufende Alerts (Monitoring, Pager, Chat‑Bots).
+  - Erstes Triage nach `ops/incidents-major.md`.
+  - Eskalation an weitere Rollen (z.B. Platform Ops, Produkt, Security).
+- Voraussetzungen:
+  - Zugriff auf Produktions‑Logs, Monitoring‑Dashboards, Dokploy/Horizon.
+  - Vertraut mit den wichtigsten Runbooks (Public‑API, Storage, Photobooth, Billing).
+
+### 1.3 Support / Customer Success
+
+- Verantwortlich für:
+  - Kontakt mit Tenants (E‑Mail/Telefon/Chat).
+  - Übersetzung technischer Probleme in Kundensprache.
+  - Sammeln aller relevanten Informationen, bevor an On‑Call/Platform Ops eskaliert wird.
+- Typische Aufgaben:
+  - Tickets aus dem Help‑System triagieren.
+  - Proaktive Kommunikation bei Events („Wir haben ein Upload‑Problem identifiziert, wir arbeiten daran“).
+
+### 1.4 Produkt / Engineering Leads
+
+- Verantwortlich für:
+  - Entscheidungen bei Feature‑Flags, Rollbacks, Hotfix‑Releases.
+  - Priorisierung langfristiger Maßnahmen nach Incidents (bd-Issues als Roadmap/Backlog).
+- Typische Aufgaben:
+  - Teilnahme an Postmortems.
+  - Freigabe von riskanteren Änderungen (z.B. große Migrations).
+
+## 2. On-Call-Modell
+
+### 2.1 Bereitschaftszeiten
+
+Empfohlene Einteilung (anpassbar an dein Team):
+
+- **Bürozeiten (z.B. 09:00–17:00)**  
+  - On‑Call ist die jeweils zuständige Platform‑Ops‑Person des Tages.
+  - Reaktionsziel: 15 Minuten bei SEV‑1/2, 60 Minuten bei SEV‑3.
+- **Außerhalb der Bürozeiten / Event-Spitzen**  
+  - Optional: Rotierender On‑Call‑Dienst mit Rufbereitschaft.  
+  - Reaktionsziel: nach individueller Vereinbarung (z.B. 30–60 Minuten bei SEV‑1).
+
+> Wenn ihr keinen formalen 24/7‑Dienst habt, sollte klar dokumentiert sein, **wann** keine garantierte Reaktionszeit besteht (z.B. nachts/wochenends) und wie das Kunden gegenüber kommuniziert wird.
+
+### 2.2 Rotation & Übergabe
+
+- On‑Call‑Rotation (z.B. wöchentlich) im Teamtool (Kalender/Issue‑Tracker) pflegen.
+- Vor Start einer Schicht:
+  - Offene Incidents und bekannte Problemzonen durchgehen.
+  - Sicherstellen, dass Aufrufwege funktionieren (Chat, Telefon, Pager).
+- Nach Schicht:
+  - Kurze Übergabe an nächste On‑Call‑Person (offene Themen, laufende Beobachtungen).
+
+## 3. Eskalationspfad bei Incidents
+
+### 3.1 Standard-Eskalation (SEV-2/3)
+
+1. On‑Call nimmt Alert entgegen, prüft grob die Lage (`ops/incidents-major.md` → Triage).
+2. Wenn Problem lösbar erscheint:
+   - Runbooks anwenden (z.B. Public‑API‑Playbook, Medien‑Runbook, Photobooth‑Ops).
+   - Kundenkommunikation via Support abstimmen.
+3. Wenn unklar oder größer:
+   - Platform‑Ops bzw. Engineering Lead im Chat markieren.
+   - Incident‑Thread mit Statusupdates führen.
+
+### 3.2 SEV-1 (kritisch)
+
+1. On‑Call ruft sofort **Platform‑Ops** und ggf. **Produkt‑Lead** in den Incident‑Thread.
+2. Falls nötig, mit Produkt die Entscheidung für:
+   - Rollback auf letztes Release,
+   - temporäre Abschaltung einzelner Features (Feature‑Flags),
+   - Aktivierung einer Maintenance‑Seite
+   treffen.
+3. Support/Success informieren betroffene Tenants mit kurzem Status und ETA (auch wenn ETA noch grob ist).
+
+## 4. Tools & Zugänge
+
+Für On‑Call/Platform‑Ops sollten mindestens folgende Zugänge eingerichtet und getestet sein:
+
+- **Dokploy / Docker-Orchestrierung**
+  - Zugriff auf Compose‑Stacks, Logs, Health‑Checks.
+- **Horizon / Queue-Monitoring**
+  - Zugriff auf `/horizon` (nur für SuperAdmins).
+- **Logs**
+  - Zentralisierte Logs (Loki/ELK) oder SSH‑Zugriff zur Maschine mit `storage/logs`.
+- **Monitoring/Alerts**
+  - Zugang zu Uptime‑/Monitoring‑Service (Status‑Dashboard, Alert‑Konfiguration).
+
+> Stelle sicher, dass On‑Call‑Personen ausprobiert haben, ob sie diese Tools tatsächlich erreichen können (VPN, 2FA, etc.), bevor eine Schicht beginnt.
+
+## 5. Verbindung zu den Runbooks
+
+Bei einem Incident sollte die On‑Call‑Person immer vom **Betriebshandbuch** aus denken:
+
+- Einstieg über `docs/ops/operations-manual.md` (Knowledge-Base-Startseite im SuperAdmin-Panel).
+- Je nach Symptome:
+  - **API-/Frontend-Probleme** → Public‑API‑Playbook (`ops/deployment/public-api-incident-playbook.md`), ggf. Marketing/Guest‑PWA‑Spezifikationen in `docs/prp/` (in PRP, nicht im Ops‑Bereich).
+  - **Upload/Storage-Probleme** → `ops/media-storage-spec.md`, `ops/guest-notification-ops.md`.
+  - **Photobooth** → `ops/photobooth/ops_playbook.md`.
+  - **Abrechnung** → `ops/billing-ops.md`.
+  - **DSGVO-Fälle** → `ops/compliance-dsgvo-ops.md`.
+
+Dieses Dokument soll nicht alle technischen Details wiederholen, sondern sicherstellen, dass immer klar ist, **wer** reagiert und **welches** Runbook als nächstes geöffnet werden sollte.

docs/superadmin-kb/de/01-grundlagen/03-oncall-cheatsheet.md

@@ -0,0 +1,46 @@
+---
+title: On‑Call Cheat Sheet
+---
+
+Dieser Spickzettel ist für On‑Call‑Personen gedacht, die im Incident schnell handeln müssen. Er konzentriert sich bewusst auf die wichtigsten Kommandos, Dashboards und Checks.
+
+## 1. Top‑10 Kommandos
+
+- App‑Container Logs (Laravel / Horizon):
+  - `docker compose logs -f app`
+  - `docker compose logs -f horizon`
+- Queue‑Status:
+  - `php artisan queue:failed`
+  - `php artisan horizon:status`
+- Storage‑Health:
+  - `php artisan storage:monitor`
+  - `php artisan storage:check-upload-queues`
+- Datenbank‑Checks (Beispiele):
+  - `php artisan tinker` → gezielte Queries zu `events`, `event_media_assets`, `checkout_sessions`.
+
+## 2. Erstdiagnose bei „Nichts geht mehr“
+
+- Statusseite / Monitoring prüfen (HTTP‑Status, Fehler‑Rate, Queue‑Länge).
+- `docker compose ps` → welche Services sind „unhealthy“ oder down?
+- Logs der auffälligen Services anschauen (App, Queue, DB, Nginx).
+- Kurz festhalten:
+  - Wann trat das Problem auf?
+  - Betrifft es **alle** Tenants oder einzelne?
+  - Nur Guest‑PWA, nur Tenant‑Admin oder beides?
+
+## 3. Wichtigste Dashboards (Beispiele)
+
+- API‑Fehler‑Rate (5xx, 4xx für Public API).
+- Queue‑Backlog (`default`, `media-storage`, `media-security`, `notifications`).
+- Response‑Time Guest‑/Tenant‑PWA.
+- Lemon Squeezy‑Webhook‑Fehler (falls im Monitoring abgebildet).
+
+> Ergänze hier konkrete Links zu euren Grafana/Datadog‑Dashboards, sobald diese stabil sind.
+
+## 4. Wann eskalieren?
+
+- SEV‑1: Plattform weitgehend nicht nutzbar (> 15 Minuten Ausfall, viele Tenants betroffen).
+- SEV‑2: Kritische Kernfunktion (Uploads, Logins, Zahlungen) länger als 30 Minuten gestört.
+- SEV‑3: Einzelne Tenants oder Funktionen, Workaround vorhanden.
+
+Siehe auch `docs/ops/incidents-major.md` für detaillierte SEV‑Definitionen und Kommunikationsregeln.

docs/superadmin-kb/de/01-grundlagen/04-support-escalation-guide.md

@@ -0,0 +1,48 @@
+---
+title: Support → Ops Eskalationsleitfaden
+---
+
+Dieses Dokument beschreibt, welche Informationen der Support einsammeln sollte, bevor ein Ticket an Ops eskaliert wird. Ziel: weniger Ping‑Pong, schnellere Lösung.
+
+## 1. Pflichtinfos pro Ticket
+
+- **Tenant‑ID** bzw. Tenant‑Slug.
+- **Event‑ID** bzw. Event‑Slug.
+- **Zeitstempel** der Beobachtung (lokale Zeit + Zeitzone).
+- **Betroffene User**:
+  - Gast‑Session ID (falls verfügbar).
+  - E‑Mail (für Tenant‑Admins).
+- **Umgebung**:
+  - Browser + Version.
+  - Betriebssystem / Device.
+  - Mobil / Desktop.
+- **Screenshots / Screenrecording**:
+  - Fehlermeldungen.
+  - UI‑Zustand (z.B. Upload hängt bei 90 %).
+
+## 2. Typische Fälle & Zusatzinfos
+
+- **Upload schlägt fehl**
+  - URL des Join‑Links.
+  - Anzahl betroffener Gäste (einige / viele / alle).
+  - Grobe Dateigröße (Handyfoto, stark komprimiert, RAW etc.).
+- **Photobooth‑Fotos fehlen**
+  - Name/Typ der Photobooth.
+  - Zeitpunkt der letzten sichtbaren Fotos.
+  - Ob die Photobooth selbst Fehler anzeigt.
+- **Paket nicht aktiv / Limits falsch**
+  - Bestellnummer / Lemon Squeezy‑Checkout‑ID (falls vorhanden).
+  - Zeitpunkt der Zahlung.
+  - Welches Paket wurde erwartet?
+
+## 3. Wie an Ops übergeben?
+
+- Ticket im Tracker mit Label „ops“ versehen.
+- Kurzes Summary in ein bis zwei Sätzen:
+  - „Gäste können seit 18:30 Uhr im Event XYZ keine Fotos hochladen. Fehler: ‚Upload fehlgeschlagen‘.“
+- Alle oben genannten Pflichtinfos als strukturierte Liste ergänzen.
+
+Siehe auch:
+
+- `docs/ops/oncall-roles.md`
+- `docs/ops/oncall-cheatsheet.md`

docs/superadmin-kb/de/01-grundlagen/05-admin-issue-resolution.md

@@ -0,0 +1,22 @@
+# Admin Issue Resolution (Ops Playbook)
+
+Internal troubleshooting guide for superadmins and on-call.
+
+## Upload incidents
+| Symptom | Likely cause | First action |
+| --- | --- | --- |
+| Queue stuck >10 min | Workers stalled or storage pressure | Check queue workers and storage health; see `docs/ops/queue-workers.md` and `docs/ops/dr-storage-issues.md` |
+| Guests blocked | Per-device limits reached | Confirm limits and whether exceptions are allowed |
+| Thumbnails missing | Backfill jobs stalled | Run `php artisan media:backfill-thumbnails --tenant=XYZ` |
+
+## Access issues
+- **Admin cannot log in**: verify invite acceptance, check SSO mapping if enforced, re-send invite.
+- **Guest cannot join**: confirm event is published and the join link is current.
+
+## Billing and quota blocks
+- Check Lemon Squeezy / RevenueCat status dashboards.
+- Confirm webhook freshness and retry failures if needed.
+
+## Communications
+- Use the support escalation guide at `docs/ops/support-escalation-guide.md` for customer comms.
+- Log all actions and timestamps in a bd issue.

docs/superadmin-kb/de/01-grundlagen/06-live-ops-control.md

@@ -0,0 +1,34 @@
+# Live Ops Control (Ops Playbook)
+
+Use this playbook when supporting an event in real time. This is internal guidance for superadmins/on-call.
+
+## Scope
+- Moderation queues and Live Show queues.
+- High-volume events with potential backlog or device failures.
+- Incident response when content safety or performance is at risk.
+
+## Baseline checks
+1. Confirm event status and moderation mode.
+2. Verify queue counts and recent upload rate.
+3. Check if any trusted devices are bypassing review.
+
+## Triage workflow
+- **Queue backlog** (>25 items or >10 min):
+  - Increase moderation staffing.
+  - Tighten upload visibility rules.
+  - Reduce Live Show effects or layout to lower throughput pressure.
+- **Offensive content reported**:
+  - Hide the item, capture evidence, notify duty officer.
+  - Confirm the report appears in the audit log.
+- **Live Show empty**:
+  - Confirm correct show link and moderation mode.
+  - Check whether items are waiting in the queue.
+
+## Escalation
+- Reliability on-call for queue or processing failures.
+- Legal duty officer for sensitive content handling.
+- Customer Success for comms to organizers.
+
+## After action
+- Capture timeline and actions in a bd issue.
+- Add follow-ups for any repeated failure modes.