monitor/Detailfragen.md

Detailfragen zur Neuausrichtung (Büro-Visualisierung)

Diese Liste sammelt offene Fragen zum Plan in Visualization.md. Die Nummern (F1, F2, ...) werden dort referenziert. Antworten können schrittweise erfolgen, grundsätzliche Technik-Fragen (F10–F14) sollten idealerweise vor Phase 1 geklärt sein.

Rollen & Mitarbeitende

• F1: Welche Rollen soll es initial geben (z. B. Manager, Entwickler:in, Product Owner, Tester:in, DevOps, Support)? Für jede Rolle: Name, Aussehen/Avatar, typische Schreibtisch-Deko, erlaubte Aktionen (z. B. wer darf Board-Karten verschieben)?
• F2: Welche "externen" Rollen gibt es (Kunde, User, Lieferant, ...)? Was genau löst ihr Erscheinen an der Tür aus (z. B. neues Support-Ticket, neuer externer Event)? Verschwinden sie nach einer festen Zeit wieder oder bei einem bestimmten Ereignis (z. B. Ticket beantwortet)?
• Wie viele Agenten/Mitarbeitende können gleichzeitig aktiv sein, wenn es mehr als 8 reale Agenten gibt als Schreibtische vorhanden sind? Warteliste, Rotation, oder zusätzliche Schreibtische dynamisch?
• Wie wird ein realer/entfernter Agent (der über die REST-API meldet) einem Schreibtisch/Avatar zugeordnet? Feste Zuordnung bei Registrierung, oder erste-frei-Prinzip?

Kanban-Board

• F3: Wie sollen die Board-Spalten genau heißen und wie viele soll es geben? Vorschlag im Plan: Backlog → In Arbeit → Testing → Fertig. Passt das, oder gibt es weitere Spalten (z. B. "Review", "Blocked")?
• F4: Woher kommen die "echten Issues", die im Modal angezeigt werden sollen – ausschließlich aus der neuen REST-API, oder sollen z. B. auch Codeberg-Issues direkt eingebunden/verlinkt werden?
• Sollen Ticket-Prioritäten oder -Typen visuell unterscheidbar sein (z. B. Zettelfarbe für Bug vs. Feature)? Wenn ja, welches Farbschema?
• Gibt es ein Limit an gleichzeitig sichtbaren Zetteln pro Spalte, bevor z. B. nur noch ein Zähler angezeigt wird?

Monitore

• F5: Event-Monitor – was genau zählt als Event (nur Fehler/Warnungen, oder auch informative Meldungen)? Wie viele Zeilen sind gleichzeitig sichtbar, gibt es eine Auto-Scroll-Historie? Werden alte Events archiviert oder verworfen?
• F6: System-Monitor – wie viele Systeme/Kacheln sollen initial dargestellt werden? Ist das eine 1:1-Weiterführung von hosts.conf/check_fds.sh, oder ein komplett neues, von den Agenten gemeldetes Konzept? Gibt es unterschiedliche Icon-Typen je Systemart?
• F7: KPI-Monitor – welche konkreten Kennzahlen sollen initial gezeigt werden (z. B. Anzahl offener Tickets, durchschnittliche Bearbeitungszeit, Fehlerquote, Uptime)? Woher stammen diese Werte – berechnet das Backend sie aus den anderen Daten, oder melden Agenten sie separat über POST /api/v1/kpis/{key}?
• Soll es weitere Monitore/Wand-Elemente geben, die später ergänzt werden (Erweiterbarkeit über Konfiguration oder nur über Code)?

Interaktion & Animation

• F8: Nach welcher Regel wird bestimmt, welcher Mitarbeitende auf ein Ereignis reagiert (z. B. zufällig unter den "idle"-Agenten, oder anhand einer Rollen-/Zuständigkeitszuordnung, z. B. nur Entwickler:innen reagieren auf Fehler-Events)?
• F9: Welcher visuelle Stil ist gewünscht – flach-illustrativ (Cartoon), Pixel-Art, oder isometrisch? Gibt es Referenzbilder/Vorbilder? Soll die Szene responsiv/skalierbar sein (Desktop und Mobile), oder ist eine Mindestbildschirmgröße akzeptabel?
• Wie schnell/langsam sollen Laufwege und Zustandswechsel animiert werden (z. B. realistisches Tempo vs. beschleunigt, damit man auf einen Blick Aktivität erkennt)?
• Was passiert bei sehr vielen gleichzeitigen Ereignissen (z. B. 20 Tickets in einer Sekunde) – Warteschlange der Animationen, oder Zusammenfassen/Überspringen?

Technik

• F10: Welche Visualisierungsbibliothek (falls überhaupt) soll für den KPI-Monitor verwendet werden? Optionen im Plan: kein Lib (eigenes SVG-Zeichnen), uPlot (MIT, sehr klein), Chart.js (MIT, verbreitet), D3.js (ISC, sehr flexibel). Bitte Präferenz nennen oder "kein Lib" bestätigen.
• F11: Welche Persistenzform ist gewünscht – einfache JSON-/Textdateien (wie bisher status.txt), oder SQLite (in PHP/Python-Standardbibliotheken enthalten, kein externer DB-Server nötig)?
• F12: Soll die REST-API primär in PHP oder in Python umgesetzt werden (oder beides, je nach Endpunkt-Gruppe)? Das hängt vom Ziel-Hosting ab (klassisches PHP-Webhosting mit CGI/FPM vs. ein eigener Python-Prozess/WSGI-Server) – welches Hosting-Setup ist vorgesehen?
• F13: Soll das Frontend die Daten per Polling (wie heute per 60s-Refresh, ggf. schneller via fetch-Intervall) oder über eine Push-Technik (Server-Sent Events, in Vanilla-PHP/Python umsetzbar) aktualisieren?
• F14: Wie soll die Authentifizierung der Agenten gegenüber der REST-API aussehen – ein statischer API-Key pro Agent (einfachste Lösung), oder etwas Anspruchsvolleres (Token mit Ablauf, HMAC-Signatur)? Wie/wo werden diese Keys verwaltet und ausgegeben?

Tests

• F15: Die Vorgabe "keine Libraries, keine externen Tools" bezieht sich vermutlich auf die Produktivanwendung, nicht auf Test-/Entwicklungswerkzeuge (PHPUnit, pytest, Coverage-Tools, der bereits vorhandene Playwright-Runner) – bitte bestätigen, damit für Tests Standard-Testwerkzeuge der jeweiligen Sprache genutzt werden dürfen.
• Gibt es eine bevorzugte CI-Umgebung, in der Tests (inkl. Coverage-Schwelle 60 % und Playwright-E2E-Tests) automatisch laufen sollen, oder wird das vorerst nur lokal/manuell ausgeführt?

Migration / Bestand

• F16: Soll die bisherige tabellarische Statusseite (html/mon.html) nach der Umstellung komplett entfallen, als Fallback-Ansicht (z. B. /legacy) erhalten bleiben, oder in ein Detail-Modal der neuen Szene integriert werden?
• Bleiben check_fds.sh, mail_fds.py und die Mail-Benachrichtigung bei Ping-Fehlern unverändert bestehen und speisen künftig lediglich den System-Monitor über die neue API, oder werden sie durch die REST-API-Agenten vollständig abgelöst?
• Soll die bestehende Zeitzonen-Einstellung (Cookie-basiert, siehe script.js) in der neuen Oberfläche weitergeführt werden (z. B. für Zeitstempel in Event-/KPI-Modals)?