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> |
||
|---|---|---|
| .. | ||
| bin | ||
| docker | ||
| public | ||
| src | ||
| tests/Unit | ||
| .dockerignore | ||
| .phpunit.result.cache | ||
| composer.json | ||
| composer.lock | ||
| phpunit.xml | ||
| README.md | ||
monitor REST-API (Phase 1)
Vanilla-PHP-REST-API (kein Framework, siehe Visualization.md Abschnitt 5) fuer Tickets,
Events, Systeme, KPIs und Agenten. Persistenz in SQLite (api/data/monitor.sqlite).
Vollstaendige Endpunkt-Dokumentation: ../API.md.
Entwicklung nur mit Docker (kein lokales PHP/Composer noetig)
Aus dem Repo-Wurzelverzeichnis:
cp .env.example .env # einmalig, MONITOR_ADMIN_API_KEY anpassen
docker compose up --build # startet die API auf http://localhost:8080
docker compose run --rm api composer test # PHPUnit inkl. Coverage
docker compose run --rm api php bin/sync-codeberg.php # Backlog/Done einmalig ziehen (Debug)
Im laufenden Betrieb wird der Codeberg-Sync nicht manuell angestossen, sondern vom
Compose-Service sync alle MONITOR_SYNC_INTERVAL Sekunden ausgefuehrt (siehe
../API.md, Abschnitt "Codeberg-Sync").
Composer-Abhaengigkeiten (nur PHPUnit als Dev-Dependency) werden beim ersten Start
automatisch im Container installiert (docker/entrypoint.sh) - auf dem Host ist
weder PHP noch Composer noch SQLite erforderlich.