Commit graph

5 commits

Author SHA1 Message Date
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
fds2610-bot
79d97985f3 OPs-Agent repariert seine Praesenz nach dem naechsten Update selbst
Der OPs-Agent war seit seiner Registrierung am 31.08. nie praesent: seine
monitor-api.conf stammt von vor Issue #75 und kennt MONITOR_AGENT_ID nicht,
report_activity() in check_fds.sh meldete deshalb stillschweigend nichts -
waehrend die Systemmeldungen mit demselben Key weiter ankamen.

- API: jeder mit X-Api-Key authentifizierte Request frischt last_seen_at auf
  (AgentRepository::touch(), Zustand/Ticket bleiben). Greift auch, wenn auf dem
  Ping-Rechner noch ein aelteres check_fds.sh liegt.
- API: neuer Endpunkt GET /api/v1/agents/me liefert den Agenten zum Key.
- check_fds.sh: fehlt MONITOR_AGENT_ID, wird sie ueber /agents/me ermittelt
  und in monitor-api.conf nachgetragen (ohne Admin-Key).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F5rnDxZCwLYiEVyfrAvsAA
2026-09-13 21:47:32 +02:00
fds2610-bot
9426406ee5 Sprachaufnahme: Agent-Kachel, Aufnahme-Webseite und API-Warteschlange
Setzt den in #84 skizzierten Workflow um: record.html nimmt im
Handy-Browser eine Sprachnotiz per MediaRecorder auf und laedt sie
unauthentifiziert zu POST /api/v1/agents/{id}/recordings hoch. Ein
Klick auf die Personen-Figur jedes registrierten Agenten in der
Buero-Visualisierung verlinkt dorthin, ein Zaehler am Schreibtisch
zeigt offene Aufnahmen. Der Agent selbst holt seine Warteschlange
ueber die bestehenden Api-Key-authentifizierten Endpunkte ab
(GET .../recordings, GET /recordings/{id}/audio) und markiert eine
Aufnahme nach der Transkription per PATCH als erledigt - die
eigentliche Transkription (whisper.cpp/faster-whisper) bleibt
agent-seitig, siehe fds2610/Agent#17.

Schliesst #85
2026-09-03 21:26:28 +02:00
fds2610-bot
09a3b928ab Vier fehlschlagende Tests behoben
1. AgentRepository::updateActivity() schrieb current_ticket_id ungeprueft. Eine
   unbekannte Ticket-ID lief in die FOREIGN-KEY-Constraint und kam als
   ungefangene PDOException samt Stacktrace und Dateipfaden beim Client an.
   Jetzt wird die Existenz vorab geprueft (422). Zusaetzlich faengt
   Application::handle() unerwartete Throwables ab und antwortet mit einem
   generischen 500 - Details gehen nur noch ins Log.

2. Die Normalisierung der Codeberg-Label-Farbe ("#" davor) lag im
   CurlCodebergClient statt im CodebergSyncService. Damit haetten andere
   Client-Implementierungen unterschiedliche Farbformate ins Ticket geschrieben.
   Verschoben in die Domaenenschicht, leere Farben ergeben jetzt null.

3. Config::get() griff selbst auf getenv() zurueck, wodurch ein in der Umgebung
   gesetzter CODEBERG_TOKEN in eine explizit gebaute Config durchschlug - im
   Testlauf landete der Token im Klartext in der PHPUnit-Ausgabe. Die Umgebung
   wird jetzt ausschliesslich in fromEnvironment() eingesammelt.

Regressionstests fuer alle drei Punkte ergaenzt: 104 Tests, 181 Assertions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-27 20:17:31 +02:00
fds2610-bot
857fc88834 Phase 1 der Neuausrichtung: REST-API fuer Tickets/Events/Systeme/KPIs/Agenten
Setzt Phase 1 aus Visualization.md um: Vanilla-PHP-REST-API mit SQLite-Persistenz,
statischen API-Keys pro Agent, Codeberg-Sync fuer Backlog/Done, PHPUnit-Tests und
vollstaendiger API.md-Dokumentation - Vorgaben aus Detailantworten.md (F1-F16)
umgesetzt. Entwicklung/Build/Test laufen komplett in Docker-Compose-Containern
(PHP 8.2 + SQLite + Composer + PHPUnit/pcov), analog zum NC-Gantt-Projekt ist auf
dem Host kein PHP/Composer noetig.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-27 19:38:52 +02:00