FDS2610/monitor
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
monitor/api
History
fds2610-bot be1d61350b Sprachaufnahmen: eine Warteschlange fuer alle statt Zuweisung an Agenten 
In Produktion lag eine Sprachnachricht unbearbeitet in der Warteschlange des
OPs-Agenten: aufgenommen wurde ueber seine Figur, abgeholt wird aber nur von
der Maschine, auf der whisper.cpp laeuft. Die Agent-Zuweisung hat eine
Zustaendigkeit vorgetaeuscht, die es nicht gibt - welches Ticket in welchem
Repo entsteht, entscheidet der abholende Bot anhand des Transkripts.

- Migration 007: voice_recordings ohne agent_id. Bestehende Aufnahmen behalten
  ihren Status, die haengengebliebene wandert damit in die globale Warteschlange.
- Migration 008: neue Agenten-Rolle "voice" fuer den Voice-Bot.
- Endpunkte ohne Agent im Pfad: POST/GET /api/v1/recordings,
  GET /api/v1/recordings/{id}/audio, PATCH /api/v1/recordings/{id} - und ohne
  Ownership-Check, an dem die Abholung mit fremdem Key bisher scheiterte.
- GET /api/v1/agents traegt pending_recordings jetzt neben der Liste statt an
  jedem Agenten.
- Frontend: nur noch die Figur des Voice-Bots verlinkt auf record.html (ohne
  ?agent=), Zaehler und Mikrofon-Deko sitzen an seinem Schreibtisch. Die
  Aufnahmeseite nennt den abholenden Bot und bittet darum, das Projekt am
  Anfang der Aufnahme zu nennen.

Die Bot-Seite (bin/voice-recording-agent.sh) folgt in fds2610/Agent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-21 13:41:47 +02:00
..
bin Neue KPI: offene PRs ueber alle Projekte (Issue #59) 2026-08-21 11:57:08 +02:00
docker Sprachaufnahme: Agent-Kachel, Aufnahme-Webseite und API-Warteschlange 2026-09-03 21:26:28 +02:00
public Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
src Sprachaufnahmen: eine Warteschlange fuer alle statt Zuweisung an Agenten 2026-09-21 13:41:47 +02:00
tests/Unit Sprachaufnahmen: eine Warteschlange fuer alle statt Zuweisung an Agenten 2026-09-21 13:41:47 +02:00
.dockerignore Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
composer.json Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
composer.lock composer.lock einchecken 2026-07-27 20:17:18 +02:00
phpunit.xml Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten 2026-07-27 19:38:52 +02:00
README.md Codeberg-Sync als Dauerlaeufer statt manuellem Aufruf 2026-07-28 23:29:40 +02:00

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.