monitor/Detailantworten.md

Antworten zu Detailfragen zur Neuausrichtung (Büro-Visualisierung)

Diese Liste sammelt Antworten auf die offenen Fragen zum Plan in (Detailfragen.md)(Visualization.md). Die Nummern (F1, F2, ...) werden dort referenziert.

Rollen & Mitarbeitende

• F1: eine Rolle Entwickler. Er nimmt sich Tickets vom Board (meisst Spalte "Bereit") und darf Tickets auf dem Board verschieben. Er nimmt sich nur Tickets, die umsetzbar sind und keine offenen Fragen mehr haben. Eine Rolle ProdurctOwnerin. Sie nimmt sich Tickets vom Board (meisst Spalte Backlog), analysiert sie und stellt Rückfragen. Bei reinen Frage-, Analyse- oder Planungstickets beantwortet sie die Tickets. Sie darf sich welche vom Board nehmen und auf dem Board verschieben. Antworten auf Fragen und Rückfragen kommen in Spalte fertig. Tickets, die keine Rückfragen mehr haben, kommen in Spalte bereit. Wenn es nur Tests erstellen oder durchführen ist, kommt es in Spalte QA. Eine Rolle QA / Tester. Er schreibt neue Tests und führt sie aus. Er darf sich Tickets nehmen, die in der Spalte QA sind und legt sie in Spalte fertig, wenn alle Tests ok sind. Wenn tests nicht OK sind, prüft er, ob es am Test oder am Code liegt. Wenn es am Code liegt, gibt er das Ticket zurück in Spalte "Bereit". Wenn es am Test liegt, behebt er den Fehler. Er darf Tickets nehmen und verschieben. Wenn er beim Testen Bugs findet, die nicht unbedingt mit dem aktuellen Ticket zusammenhängen, kann er neue Bug Tickets eröffnen und die Fehler beschreiben. Diese kommen ins Backlog.

• F2: eine Rolle User. er hat keinen festen Sitzplatz. Wenn ein ticket im BAcklog erscheint, dass nicht von einer der rollen dort hingelegt wurde, kommt der user herein und legt es aufs Board ins Backlog. Wenn ein Ticket in Spalte fertig erscheint, kommt er herein, schaut sich das Ticket an und geht wieder. Wenn ein Tciket geschlossen wird, kommt der User rein, verschiebt das Ticket in Spalte "Done" und geht wieder. In Spalte Done werden Tickets nicht wie in anderen Spalten untereinander dargestellt, sondern bilden über die Zeit einen Stapel. Dieser Stapel repräsentiert die closed Tickets.

• Sollten wirklich alle Schreibtische besetzt sein, kommen weitere Agenten durch die Tür, machen Ihre Aufgaben und gehen wieder. Es können alle gleichzeitig etwas machen.

• Agenten erhalten bei der Registrierung eine feste Zuordnung.

Kanban-Board

• F3: Backlog → Bereit → In Arbeit → QA → Testing → Fertig → Done

• F4: Die echten Issues - vor allem Backlog und Done - werden regelmässig von Codeberg ausgelesen. Die anderen Bewegungen auf dem Board ergeben sich immer aus den Meldungen der Agenten.

• Ich habe bisher nur Ticket-Typen und keine Prioritäten. Diese können mit den Codeberg-Farben dargestellt werden.

• Wenn mehr als 5 Tickets in einer Spalte sind, werden die ältesten 4 Tickets untereinander dargestellt und alle weiteren als "Stapel". Der Stapel enthält in der Mitte die Anzahl der gestapelten Tickets (also ohne die vier darüber).

Monitore

• F5: Events werden über die API gemeldet. Sie enthalten eine System-ID, Namen, Eventbeschreibung, Severity und Uhrzeit des Auftretens. Eine Zeile pro Event. Max 5 Events. Es gibt Warnungen (gelb) und Fehler (rot). Der neueste Event erscheint oben und der rest scrollt runter.

• F6: System-Monitor - es werden maximal 9 Kacheln dargestellt. die bestehenden Systeme werden übernommen. Derzeit das alte System, später sollen REST Meldungen möglich sein. Pro System ein "Server" Icon.

• F7: KPI-Monitor – alles offen derzeit. kommt später.

Interaktion & Animation

• F8: Die Mitarbeiter werden den Agenten zugeordnet. die Mitarbeiter visualisieren, dass ein Agent etwas gemeldet hat. Nur idle Aktivitäten wie Kaffetrinken, oder Schwätzchen halten steuert das System selber random.

• F9: visuelle Stil am liebsten Zeichentrick wie die Eisprinzessin. gerne 3D.

• Bildschirm mindestens Full-HD. Darüber Skalierbar.

• Laufwege und Zustandswechsel relistisch animieren werden

• bei sehr vielen gleichzeitigen Ereignissen (z. B. 20 Tickets in einer Sekunde) – Warteschlange der Animationen

Technik

• F10: keine Lib, eigene SVG.

• F11: Persistenzform wie bisher eine einfache JSON-/Textdateien (wie bisher status.txt) für die Monitoring-Anteile. Alles Neue in SQLite (in PHP/Python-Standardbibliotheken enthalten)

• F12: primär PHP.

• F13: Frontend via PHP Push aktualisieren (Server-Sent)

• F14: API Authentifizierung über statische API Keys pro Agent. Keys werden in SQLite gespeichert.

Tests

• F15: für Tests dürfen Libraries verwendet werden: (PHPUnit, pytest, Coverage-Tools, der bereits vorhandene Playwright-Runner).

• CI-Umgebung vorerst nur lokal/manuell

Migration / Bestand

• F16: bisherige tabellarische Statusseite (html/mon.html) kann entfallen

• Es 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

• Zeitzonen-Einstellung entfernen. Alles läuft in CEST bzw CET im Winter.