morz-infoboard/TODO.md

# Info-Board Neu - Umsetzungs-Todo

## Phase 0 - Projektbasis

- [x] Projektverzeichnisstruktur unter `/srv/docker/info-board-neu` festlegen
- [x] Namenskonventionen fuer Server, Player, Rollen und Pakete definieren
- [x] Dokumentationsstruktur fuer Architektur, Betrieb und Deployment anlegen
- [x] Entscheidung fuer Server-Tech-Stack dokumentieren
- [x] Entscheidung fuer Player-Implementierung dokumentieren
- [x] Sprachentscheidung dokumentieren: `Go` als bevorzugte Sprache fuer Agent und moeglichst viele Backend-Komponenten

## Phase 1 - Fachliches Fundament

- [x] Rollenmodell fuer `admin` und monitorgebundene Nutzer final festschreiben
- [x] Datenmodell fuer `tenant`, `screen`, `user`, `media_asset`, `playlist`, `playlist_item`, `screen_status`, `screen_snapshot` definieren
- [x] Playlist-Semantik mit `duration`, `valid_from`, `valid_until`, `load_timeout`, `cache_policy`, `on_error` spezifizieren
- [x] Fallback-Regel fuer ungeplante oder leere Inhalte verbindlich definieren
- [x] Statusmodell fuer Online/Offline/Degraded/Error definieren
- [x] Kommandokatalog fuer Admin-Aktionen finalisieren
- [x] Template- und Kampagnenmodell fuer globale monitoruebergreifende Uebersteuerung finalisieren
- [x] Prioritaetsregel `campaign > tenant_playlist > fallback` verbindlich festschreiben
- [x] Entscheidung dokumentieren, dass `playlist_items.screen_id` entfernt wird
- [x] Entscheidung dokumentieren, dass Gruppen bei Kampagnen serverseitig in Einzel-Assignments expandiert werden

## Phase 2 - Technische Zielarchitektur

- [x] Server-Komponentenliste finalisieren
- [x] API-Schnittstellen grob definieren
- [x] MQTT-Topic-Struktur finalisieren
- [x] HTTPS- und MQTT-Aufgabentrennung dokumentieren
- [x] Screenshot-/Vorschaustrategie spezifizieren
- [x] Offline- und Cache-Strategie bis auf Dateiebene festlegen
- [x] Sicherheitsmodell fuer Uploads, Login und Rechte pruefen
- [x] API fuer Templates, Kampagnen, Aktivierung und Deaktivierung ausarbeiten
- [x] Provisionierungs-Workflow fuer neue Screens technisch durchplanen
- [x] Secret-Handling fuer initiale Root-Passwoerter oder Bootstrap-Zugaenge definieren
- [x] API-Fehlermodell und gemeinsame Fehlerantworten festlegen
- [x] ACK-Timeout-Strategie fuer `device_command` festlegen
- [x] `message_wall`-Rendering serverseitig verbindlich entscheiden
- [x] Netzwerktopologie fuer SSH-basierte Erstprovisionierung als Worker-/Jumphost-faehiges Modell festlegen

## Phase 3 - Player-Design

- [x] Minimalen Paketbedarf fuer den Player auf Raspberry Pi OS Debian 13 ermitteln
- [x] X11-Minimalkonzept fuer Chromium-Kiosk dokumentieren
- [x] Startmechanismus fuer Chromium ohne Desktop-Umgebung definieren
- [x] Verzeichnislayout auf dem Player festlegen
- [x] `player-agent` fachlich zuschneiden
- [x] `player-ui` fachlich zuschneiden (lokale Kiosk-Seite mit Splash + Sysinfo-Overlay)
- [ ] Watchdog-Konzept fuer Browser und Agent definieren
- [x] Offline-Overlay-Verhalten spezifizieren
- [x] Fehlerbehandlung fuer Web-Inhalte und Timeouts ausarbeiten
- [x] Display-Steuerung fuer An/Aus, Rotation und Neustart planen
- [x] Sysinfo-Overlay erweitern: load, freier RAM, IP-Adresse(n) anzeigen

## Phase 4 - Server-Design

- [x] API-Backend fachlich schneiden
- [x] Admin-Oberflaeche in Hauptbereiche aufteilen
- [ ] Firmen-/Monitor-Oberflaeche in Hauptbereiche aufteilen
- [x] Storage-Konzept fuer Uploads, Cache-Dateien und Screenshots festlegen
- [x] Authentifizierungskonzept festlegen
- [x] Mandantentrennung im Datenmodell und in den APIs absichern
- [ ] Logging- und Monitoring-Konzept definieren
- [ ] Template-Editor fuer globale Kampagnen fachlich schneiden
- [ ] Aktivierungsoberflaeche fuer saisonale oder temporäre Kampagnen planen
- [ ] Gruppierung oder Slot-Modell fuer monitoruebergreifende Layouts planen
- [x] Provisionierungs-UI fuer neue Screens fachlich und technisch schneiden
- [ ] Jobrunner-Konzept fuer Ansible-gestuetzte Erstinstallation planen

## Phase 5 - Prototyping

- [x] Minimalen Server-Prototyp bauen
- [x] Minimalen Player-Agent-Prototyp bauen
- [x] Minimale Player-UI bauen
- [ ] Lokale Test-Playlist mit Bild, Video, PDF und Webseite anlegen
- [ ] **BUG**: Datei `120papag.mpg` ist als `type: image` gespeichert, muss `type: video` sein – Player-UI versucht `<img>`-Laden, was fehlschlägt
- [x] Fallback-Verzeichnisbetrieb demonstrieren
- [ ] `valid_from`/`valid_until` im Prototyp pruefen
- [x] Offline-Sync mit lokalem Cache pruefen
- [ ] MQTT-Kommandos `reload`, `restart_player`, `reboot`, `display_on`, `display_off` testweise durchspielen
- [ ] globale Kampagne testen, die tenantbezogenen Content temporär ueberschreibt
- [ ] Rueckfall auf Normalbetrieb nach manueller Deaktivierung pruefen

## Phase 6 - Betriebsfaehigkeit

- [x] Docker-Compose-Setup fuer den Server anlegen
- [x] systemd-Units fuer den Player erstellen
- [x] Chromium-Kiosk-Startskript erstellen
- [ ] Screenshot-Erzeugung auf dem Player integrieren
- [x] Heartbeat- und Statusmeldungen integrieren
- [ ] Fehler- und Wiederanlaufverhalten verifizieren

## Phase 7 - Ansible-Automatisierung

- [ ] Rolle `signage_base` erstellen
- [x] Rolle `signage_player` erstellen
- [x] Rolle `signage_display` erstellen
- [ ] Rolle `signage_server` erstellen
- [ ] Rolle `signage_provision` erstellen
- [x] Inventar-/Variablenmodell fuer mehrere Monitore entwerfen
- [x] Screen-spezifische Variablen wie `screen_id`, Rotation und Aufloesung abbilden
- [x] Erstinstallation eines neuen Players automatisieren
- [x] Update-Rollout eines bestehenden Players automatisieren
- [x] Bootstrap ueber Root-Passwort auf SSH-Key und dauerhafte Verwaltung umstellen

## Phase 8 - Pilotbetrieb

- [ ] Einen Referenzmonitor fuer den Pilotbetrieb auswaehlen
- [ ] Pilotmonitor neu aufsetzen
- [ ] Verbindung zum Zentralserver herstellen
- [ ] Upload- und Playlist-Pflege mit einem Testmandanten pruefen
- [ ] Admin-Funktionen am Pilotmonitor pruefen
- [ ] globale Template-Aktivierung fuer einen oder mehrere Monitore im Pilot testen
- [ ] Offline-Betrieb real testen
- [ ] Browser-/Renderer-Stabilitaet ueber laengeren Zeitraum beobachten
- [ ] komplette Neu-Provisionierung eines frischen Test-Screens aus dem Admin-Backend pruefen

## Phase 9 - Migration der Bestandsmonitore

- [ ] Migrationsreihenfolge fuer `info01` bis `info09` festlegen
- [ ] Rueckfallstrategie pro Monitor definieren
- [ ] Altinhalte in das neue Medienmodell ueberfuehren
- [ ] Playlists uebernehmen oder neu modellieren
- [ ] Monitore nacheinander umstellen
- [ ] Nach jeder Umstellung Stabilitaet und Fernsteuerung pruefen

## Phase 10 - Nacharbeiten

- [ ] Betriebsdokumentation schreiben
- [ ] Admin-Handbuch schreiben
- [ ] Kurzhandbuch fuer Firmen-Nutzer schreiben
- [ ] Backup- und Restore-Konzept dokumentieren
- [ ] Update- und Release-Prozess festlegen
- [ ] Langfristige Wayland-Neubewertung fuer spaetere Version vormerken

## Querschnittsthemen

- [ ] Datensicherung fuer Datenbank und Medien einplanen
- [ ] TLS-/Reverse-Proxy-Konzept festlegen
- [ ] Ressourcenverbrauch auf Raspberry Pi beobachten
- [ ] Verhalten bei grossen Videos optimieren
- [ ] Verhalten bei defekten externen Webseiten absichern
- [ ] Datenschutz- und Rechtefragen fuer Screenshots/Vorschauen pruefen

## Erste konkrete Abarbeitungsreihenfolge

- [x] 1. Projektstruktur im neuen Verzeichnis vervollstaendigen
- [x] 2. Datenmodell in eigener Datei ausformulieren
- [x] 3. API- und MQTT-Vertrag definieren
- [x] 4. Player-Minimalkonzept fuer Raspberry Pi OS Debian 13 festzurren
- [x] 5. Server-Compose-Grundgeruest erstellen
- [x] 6. Player-Prototyp mit lokalem Browser-Renderer bauen
- [x] 7. Offline-Cache und Fallback robust machen
- [x] 8. UIs fuer Admin und Firmen schrittweise aufbauen
- [x] 9. Ansible-Rollen erstellen
- [ ] 10. Pilotmonitor migrieren