No description
d5f7ac9f92
Der Konfig-Dialog liess sich in der Praxis kaum oeffnen (Fehlerbericht in Issue #27). Drei Ursachen, alle reproduziert: - Ein Klick auf den PO selbst tat gar nichts: der Klick-Handler hing nur am Schreibtisch, die Figur liegt aber in der Avatar-Schicht darueber. Genau sie meint das Ticket ("bei Klick auf den PO"). Der Avatar ist jetzt klickbar, auch waehrend er am Board steht. - Klicks auf den Platz trafen nur, wenn sie zufaellig auf einem gefuellten Moebelstueck landeten - eine <g> faengt in ihren Luecken keine Klicks. Der Platz hat jetzt eine eigene Trefferflaeche, wie die Board-Spalten. - Dass hinter dem PO ueberhaupt etwas steckt, war nicht zu sehen. Ein kleines Zahnrad auf seinem Tisch (mit Tooltip) zeigt es an. Ausserdem oeffnet der Dialog jetzt auch bei nicht erreichbarer API - er meldet dann selbst, dass er die Projekte nicht laden konnte, statt tot zu wirken. Und genau dieser Fall trat leicht ein: der eingebaute PHP-Server beantwortet Anfragen nacheinander, eine offene SSE-Verbindung blockiert damit alles andere (gemessen 16s fuer ein GET /api/v1/tickets, ab dem zweiten offenen Monitor dauerhaft). Das Frontend faellt dann auf Demo-Daten zurueck. Mit PHP_CLI_SERVER_WORKERS=4 sind es 0,006s; PRAGMA busy_timeout deckt die Schreibzugriffe ab, die sich jetzt begegnen koennen. ApplicationTest::testFullFlowCreateUpdateAndDeleteRepoConfigWithAdminKey war seit dem Seed in 003_repo_configs.sql rot (legte fds2610/monitor ein zweites Mal an) - der Test nutzt jetzt ein nicht geseedetes Repo. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| api | ||
| docker/nginx | ||
| html | ||
| tests/frontend | ||
| .env.example | ||
| .gitignore | ||
| API.md | ||
| check_fds.sh | ||
| credentials-sample.conf | ||
| Detailantworten.md | ||
| Detailfragen.md | ||
| docker-compose.yml | ||
| echo | ||
| hosts-sample.conf | ||
| mail_fds.py | ||
| package.json | ||
| README.md | ||
| register-agent.sh | ||
| update.sh | ||
| Visualization.md | ||
🖥️ monitor
monitor überwacht mehrere Systeme (per Ping und/oder per REST-API-Meldungen entfernter Agenten) und zeigt den Zustand als interaktive Büro-Visualisierung (Kanban-Board + Monitor-Wand mit Agenten an Schreibtischen).
Der vollständige Umbauplan steht in Visualization.md (Roadmap Phase 0-7), die dazugehörigen Klärungen in Detailfragen.md und Detailantworten.md.
🚀 Features
- REST-API (
api/, siehe API.md) für Tickets, Events, Systeme, KPIs und Agenten-Aktivität, mit statischen API-Keys pro Agent - Büro-Visualisierung (
html/office.html) als Vanilla-SVG-Szene: Kanban-Board, Monitor-Wand (Events/Systeme/KPIs), 8 Schreibtische - zeigt live die Daten aus der REST-API (Push per Server-Sent Events, Polling-Fallback), Klick auf Board/Monitore öffnet Detail-Modals, Agenten laufen animiert zwischen Schreibtisch/Board/Monitor-Wand/Kaffee-Ecke (Phase 3-5, siehe Visualization.md Abschnitt 9). Ist die API nicht erreichbar, zeigt die Szene ersatzweise Demo-Daten — kenntlich gemacht durch einen roten Banner „API nicht erreichbar!". Die Basis-URL der API kommt ausMONITOR_API_BASE(siehe.env.example). - Klick auf den PO öffnet ein Modal, in dem sich die vom Codeberg-Sync gelesenen Projekte
(Owner/Repo + Farbe) hinzufügen, bearbeiten und löschen lassen (Issue #27) — Änderungen
wirken sofort im laufenden
sync-Dienst, ohne Neustart. Schreibende Aktionen fragen einmalig denMONITOR_ADMIN_API_KEYab und merken ihn sich im Browser. - Codeberg-Sync als Dauerläufer (Compose-Service
sync): füllt Backlog und Done automatisch aus den Issues mehrerer konfigurierter Codeberg-Projekte (je Projekt mit eigener Ticket-Farbe, siehe oben) — periodisch alleMONITOR_SYNC_INTERVALSekunden und, wenn ein Webhook eingerichtet ist, innerhalb von Sekunden nach jeder Issue-Änderung (POST /api/v1/webhooks/codeberg, HMAC-signiert perCODEBERG_WEBHOOK_SECRET). Siehe API.md Abschnitt „Codeberg-Sync" — dort steht auch die Einrichtung im Codeberg-Repo. - Weiterhin: klassische Ping-Überwachung (
check_fds.sh,hosts.conf,mail_fds.py) als eine Datenquelle für den System-Monitor; die alte tabellarische Statusseite ist mit Phase 7 entfallen (F16),status.txtspeist weiterhin den System-Monitor
📁 Projektstruktur
api/— REST-API (PHP, SQLite), siehe api/README.mdhtml/— Frontend:office.html(Büro-Visualisierung),js/,css/tests/frontend/— Node-Tests für die Frontend-Layoutlogik (node --test)check_fds.sh,mail_fds.py,hosts-sample.conf— bestehende Ping-Überwachungdocker-compose.yml— komplette Entwicklungsumgebung (siehe unten)update.sh— holt die neueste Version vom konfigurierten Git-Remote und aktualisiert die Docker-Compose-Umgebung (Abhängigkeiten, Images, Dienste, Tests)register-agent.sh— Hilfsskript, um einen neuen Agenten perPOST /api/v1/agentszu registrieren (siehe API.md Abschnitt "Agenten")
🐳 Entwicklung (nur Docker, kein lokales PHP/Node nötig)
Analog zum NC-Gantt-Projekt läuft die gesamte Ausführung (Bauen, Entwickeln, Testen) in Docker-Compose-Containern; auf dem Host muss nichts installiert werden.
cp .env.example .env # einmalig, MONITOR_ADMIN_API_KEY anpassen
docker compose up --build # API auf :8091, Buero-Visualisierung auf :8090, Sync
docker compose run --rm api composer test # PHPUnit (API)
docker compose run --rm frontend # Node-Tests (Frontend-Layoutlogik)
docker compose logs -f sync # Codeberg-Sync mitlesen
Der Browser erreicht die API nicht über das Compose-Netzwerk, sondern über die in
MONITOR_API_BASE (.env) hinterlegte URL — der Default http://localhost:8091/api/v1 passt
zum Port-Mapping oben. Wer die Ports in docker-compose.yml ändert oder das System hinter
einem Reverse Proxy betreibt, muss MONITOR_API_BASE entsprechend nachziehen, sonst zeigt
die Szene den Banner „API nicht erreichbar!" und fällt auf Demo-Daten zurück. Der Webserver
liefert den Wert zur Laufzeit als /config.js aus (docker/nginx/default.conf.template), ein
Build-Schritt ist dafür nicht nötig.
Details zur API: api/README.md. Details zu den Endpunkten: API.md.