No description
bd27923321
Manchmal werden bei Codeberg geloeschte oder anderweitig verschwundene Issues vom periodischen Sync nicht bereinigt (er upsertet nur, ruehrt fehlende Issues nie an). Neuer Knopf neben der "Kanban-Board"-Ueberschrift stoesst dafuer einen synchronen Voll-Resync an (POST /api/v1/tickets/resync, X-Admin-Key): jedes konfigurierte Projekt wird neu gelesen, Tickets zu inzwischen verschwundenen Issues werden je Projekt entfernt (auch wenn sie manuell auf eine nicht vom Sync verwaltete Spalte wie "fertig" bewegt wurden), Tickets zu weiterhin existierenden Issues bleiben unangetastet. Der PO geht dabei sichtbar ans Board und steht dort, bis die Anfrage abgeschlossen ist - anders als beim automatischen Board-Besuch (feste Animationsdauer je Stage) macht das die tatsaechliche Sync-Dauer sichtbar. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|---|---|---|
| api | ||
| deploy | ||
| docker/nginx | ||
| html | ||
| tests/frontend | ||
| .env.example | ||
| .gitignore | ||
| API.md | ||
| check_fds.sh | ||
| credentials-sample.conf | ||
| deploy-webhook.py | ||
| Detailantworten.md | ||
| Detailfragen.md | ||
| docker-compose.yml | ||
| echo | ||
| hosts-sample.conf | ||
| mail_fds.py | ||
| package.json | ||
| README.md | ||
| README_UPDATE.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. - Auto-Update auf einem Produktionsserver: Sobald ein PR nach
maingemergt wird, kanndeploy-webhook.pydenselbenupdate.shanstoßen, den auch ein manuelles Update aufruft (Push-Webhook, HMAC-signiert perMONITOR_DEPLOY_WEBHOOK_SECRET) — siehe README_UPDATE.md. - 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)deploy-webhook.py,deploy/— löstupdate.shauf einem Produktionsserver automatisch aus, sobald ein PR nachmaingemergt wird (Push-Webhook); siehe README_UPDATE.mdregister-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.