monitor/Detailfragen.md

# Detailfragen zur Neuausrichtung (Büro-Visualisierung)

Diese Liste sammelt offene Fragen zum Plan in [Visualization.md](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)?