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>
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
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
Das dreispaltige Kachelraster im System-Monitor wird durch eine einspaltige
Liste ersetzt: halb so grosse Kacheln, rechts daneben der Servername. Der Name
wird auf die verbleibende Breite gekuerzt, der ungekuerzte Name bleibt als
<title>-Tooltip erhalten (Issue #73).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011GQ56Rs4sxgwwBjowtThpr
Jede Kachel trug zwei Rack-Balken mit je einer LED. Beide LEDs hingen an
derselben Statusklasse der Kachelgruppe und zeigten damit immer dasselbe -
zwei gruene Punkte pro Server ohne zusaetzliche Aussage.
Stattdessen jetzt ein Symbol pro Kachel: gruener Haken bei "ok", rotes X
bei "error" (mehr kennt SystemRepository::STATUSES nicht). Gezeichnet als
Pfad statt als Textglyphe, damit eine fehlende Schriftart auf dem
Wandmonitor keine leere Kachel ergibt, und ueber die volle Kachelflaeche
skaliert - seit Issue #73 steht der Servername im Tooltip, die Flaeche ist
also frei.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011GQ56Rs4sxgwwBjowtThpr
Bisher meldeten Agenten walking_to_board/interacting_with_board fuer
Ticket-Uebernahmen faktisch nie, wodurch das Ticket ohne sichtbaren
Board-Besuch die Spalte wechselte. office-render.js taktet den Besuch
jetzt selbst (analog zu PO-/Tuerbesuchen): der zustaendige Agent laeuft
vom eigenen (dann leeren) Schreibtisch zum Board, verschiebt dort
sichtbar das Ticket und laeuft zurueck. Eine echte Meldung des Agenten
(walking_to_board/interacting_with_board) hat weiterhin Vorrang und
unterdrueckt den selbst getakteten Besuch.
Schliesst #76
check_fds.sh rief last_seen_at des OPs-Agenten nie an - der Agent fiel zehn
Minuten nach seiner Registrierung dauerhaft vom Schreibtisch, obwohl der
Ping-Check normal weiterlief. Das Skript meldet jetzt zu Beginn "working" und
am Ende (auch bei einem fruehen Abbruch, per trap) "idle" per
POST /api/v1/agents/{id}/activity, analog zum Cron-Skript des
Entwickler-Agenten. Fehler dabei werden nur protokolliert, nicht fatal.
Dafuer braucht monitor-api.conf zusaetzlich MONITOR_AGENT_ID:
register-ops-agent.sh schreibt sie bei einer Neuregistrierung mit und
traegt sie bei einer bestehenden, aber noch unmigrierten Datei ohne
Neuregistrierung nach.
Schliesst #75.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bei mehreren Kacheln ueberlagerten sich die fest eingezeichneten
Servernamen im mittleren (Status-)Monitor. Der Name erscheint jetzt
nur noch als SVG-<title>-Tooltip beim Hoover ueber die jeweilige
Kachel, deren gesamte Flaeche als Hoover-Bereich dient.
Schliesst #73
Auf dem Produktionsserver scheiterte "update.sh" an der untracked hosts.conf:
seit Issue #70 schreibt check_fds.sh diese Datei bei jedem Lauf neu, versioniert
ist nur hosts-sample.conf - in .gitignore stand sie aber (anders als
monitor-api.conf und credentials.conf) nicht.
- hosts.conf in .gitignore aufgenommen
- update.sh blockiert nur noch bei Aenderungen an versionierten Dateien und
listet sie auf; unversionierte Dateien werden nur als Hinweis geloggt, denn
der ff-only-Pull laesst sie unangetastet bzw. bricht selbst kontrolliert ab
- neuer Notausgang UPDATE_ALLOW_DIRTY=1 fuer den Fall, dass doch einmal an einer
versionierten Datei gedreht wurde
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HBVdYcfaXNq49bMdQQcZue
Wer einen Server aus der Ping-Ueberwachung nehmen wollte, musste sich bisher auf den
Rechner mit check_fds.sh einloggen und die hosts.conf editieren - und die Kachel blieb
danach trotzdem im System-Monitor stehen, weil ein einmal gemeldetes System nirgends
wieder geloescht werden konnte.
Die Liste steht jetzt in der Datenbank und ist ueber ein Zahnrad neben der Ueberschrift
"Systeme" pflegbar, analog zum Zahnrad am PO-Platz (Issue #27). Jeder Host gehoert dem
OPs-Agenten (Issue #66), der ihn anpingt: API und Ping-Check laufen nicht zwangslaeufig
auf demselben Rechner, die API kann die hosts.conf also nicht selbst schreiben.
check_fds.sh holt sie stattdessen bei jedem Lauf mit seinem Agenten-Key ab und schreibt
daraus die lokale Datei; ist die API nicht erreichbar, pingt es unveraendert nach der
zuletzt geschriebenen Liste weiter.
Beim ersten Lauf laedt der Check seine bestehende hosts.conf hoch, damit die bereits
ueberwachten Server nicht von Hand nachgetragen werden muessen. Dass die API das nur
einmal annimmt (Marker in host_config_imports) und "noch nie konfiguriert" per 204 von
"im Frontend geleert" per 200 unterscheidet, ist noetig, damit ein Ping-Rechner mit alter
lokaler Datei die dort geloeschten Hosts nicht wieder anlegt.
Loeschen raeumt mit auf: Ein entfernter Host nimmt seine Kachel mit - beide Ids, denn der
status.txt-Import benennt ihn nach dem Hostnamen, die REST-Meldung nach dessen Slug.
Kacheln ohne zugehoerigen Host (Selbstmelder oder Reste laengst entfernter Hosts) stehen
im selben Dialog unter "Weitere Kacheln im System-Monitor" und sind dort einzeln
loeschbar - dafuer gibt es neu DELETE /api/v1/systems/{id}.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015vNjbfr8M3HSfWMee92GTE
Bisher hatte nur der Service sync ein "restart: unless-stopped". Nach einem
Reboot, einem OOM-Kill (512 MiB RAM in der Produktion) oder einem Docker-Neustart
kam deshalb nur sync von allein zurueck, waehrend api (8091) und web (8090)
liegen blieben. "docker compose ps" zeigte dann genau einen laufenden Container
und der Monitor war ueber die Firewall-Weiterleitung nicht mehr erreichbar - ein
Fehlerbild, das nach Firewall/Reverse Proxy aussieht, obwohl schlicht nichts auf
den Ports lauschte.
unless-stopped statt always, damit ein bewusstes "docker compose stop" bestehen
bleibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fuer den Betrieb fehlte bisher eine Rolle: "user" meldet zwar Daten, bleibt in der
Buero-Visualisierung aber unsichtbar, weil sie nie einen Schreibtisch bekommt. Der
Ping-Check aus check_fds.sh (Weg 3 im README) lief deshalb als "user" und tauchte im
Buero nicht auf.
"ops" fuellt die Luecke: die Schreibtischvergabe in AgentRepository::register() greift
automatisch, sobald die Rolle erlaubt ist - nur "user" bleibt ohne Platz.
Der CHECK-Constraint auf agents.role braucht dafuer eine eigene Migration. Ein Edit von
001_initial.sql wuerde nur frische Datenbanken erreichen: bestehende Installationen haben
die Migration laut schema_migrations laengst angewandt und wuerden bei role='ops'
weiterhin abbrechen. SQLite kann CHECK nicht per ALTER TABLE aendern, 004 baut die Tabelle
deshalb neu (Verfahren aus der SQLite-Doku, foreign_keys kurz aus, weil
tickets.assignee_agent_id auf agents zeigt).
Im Frontend bekommt die Rolle Label "OPs", eine Akzentfarbe und ein Zahnrad als
Schreibtisch-Deko - ohne Eintrag in der ROLES-Map rendert der Avatar grau und ohne Label.
Neu ist ausserdem register-ops-agent.sh neben der docker-compose.yml: es liest Admin-Key
und Basis-URL aus der .env, registriert den lokalen OPs-Agenten und schreibt den nur
einmalig ausgegebenen API-Key mit chmod 600 nach monitor-api.conf - also genau die beiden
Schritte aus Weg 3, die hosts.conf und credentials.conf nicht abdecken. Eine vorhandene
monitor-api.conf ueberschreibt es nicht, und ein zweiter Agent gleichen Namens (der einen
weiteren der acht Schreibtische belegen wuerde) wird vorher abgefangen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Laufen check_fds.sh und die API auf verschiedenen Rechnern, erreicht der
Legacy-Import die API nie: SystemController::index() liest MONITOR_STATUS_FILE
als lokale Datei, waehrend status.txt auf dem Ping-Host liegt. Der
LegacyStatusFileReader liefert dann stillschweigend ein leeres Array und der
System-Monitor zeigt dauerhaft "Keine Systeme gemeldet" - ohne Fehlermeldung,
die auf die Ursache hinweisen wuerde.
check_fds.sh meldet die Ping-Ergebnisse jetzt zusaetzlich per
POST /api/v1/systems/{id}/status (online -> ok, offline -> error) und schreibt
status.txt unveraendert weiter. Die Zugangsdaten stehen in monitor-api.conf
(Vorlage: monitor-api-sample.conf); fehlt die Datei, bleibt das Verhalten
unveraendert. Eine unerreichbare API bricht den Check nicht ab, sondern
protokolliert nur eine Warnung.
Die System-ID wird aus dem Hostnamen slugifiziert, weil der Router auf dem
rohen, nicht dekodierten Pfad matcht - "Nextcloud(intern)" landete sonst
prozentkodiert in der Datenbank. Der lesbare Name geht im Feld "name" mit.
Das README beschreibt den kombinierten Weg als "Weg 3" und weist bei Weg 1
darauf hin, dass der Legacy-Import eine lokale Datei erwartet.
Ausserdem zwei Fehler im selben Skript behoben:
- Pfade werden relativ zum Skript statt zum Arbeitsverzeichnis aufgeloest.
- Die letzte Zeile der hosts.conf wurde ohne abschliessenden Zeilenumbruch
stillschweigend verschluckt, ein zuletzt angehaengter Host also nie geprueft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
README erklaert jetzt beide Wege (hosts.conf-Ping-Ueberwachung und
direkte Statusmeldung per REST-API), damit neue Systeme im
System-Monitor auftauchen. hosts-sample.conf bekommt dazu einen
Format-Hinweis; check_fds.sh ueberspringt dafuer Kommentar-/Leerzeilen
in hosts.conf, statt sie faelschlich als Host misszuinterpretieren.
Bislang wurde ein Ticket beim Wechsel von/zu "in_arbeit" sofort an seiner neuen
Spalte gezeichnet, unabhaengig davon, ob der zustaendige Entwickler laut eigenem
gemeldetem state ("walking_to_board") ueberhaupt schon am Board angekommen war -
die Animation wirkte dadurch unvollstaendig/vorgezogen. Analog zu der fuer
Tuer-/PO-Besuche in Issue #55 eingefuehrten Merge-Logik haelt office-render.js
das Ticket nun an seiner alten Stelle, bis der zustaendige Agent laut aktuellstem
Poll das Board erreicht hat (oder nicht mehr feststellbar ist).
detectAgentOwnedTicketChanges() und hasAgentReachedBoard() in office-scene.js
kapseln die dafuer noetige Erkennungs-/Entscheidungslogik pur und testbar.
CodebergSyncService berechnet am Ende jedes Sync-Laufs (periodisch und
webhook-getriggert, auch bei PR-Aenderungen) die Summe der offenen Pull
Requests aller konfigurierten Projekte und speichert sie als KPI
"open_prs" im bestehenden generischen KPI-Repository - sie erscheint
damit automatisch im KPI-Monitor der Wand und im KPI-Modal.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die per PING ueberwachten lokalen Server (check_fds.sh -> status.txt ->
LegacyStatusFileReader -> SystemRepository) landen bereits als Kacheln im
System-Monitor, dem mittleren der drei Monitore an der Buero-Wand - das ist
exakt der "alte Monitor" aus dem Issue. GET /api/v1/systems liefert
last_check_at dafuer schon mit, das Klick-Modal hat den Wert aber bisher
weder abgeholt noch angezeigt.
buildSystemModalContent() (office-scene.js) formatiert last_check_at jetzt
ueber die neue formatSystemCheckTime() - sie kommt sowohl mit ISO-8601
(API-gemeldete Systeme) als auch mit dem "YYYY-MM-DD HH:MM"-Format der
Legacy-status.txt klar. renderSystemModalBody() (office-render.js) zeigt den
Zeitpunkt nur bei Status "ok" an ("zuletzt erfolgreich geprüft: ..."), da nur
dann Erreichbarkeit UND Ping-Erfolg zusammenfallen - bei "Fehler" bliebe eine
Zeitangabe ohne Aenderung an check_fds.sh irrefuehrend.
Bewusst nicht Teil dieser Aenderung: Die im Issue zusaetzlich genannte
Portscan-Liste (Detailseite fuer weitere, nur manuell zu pruefende Server)
ist als "koennten" markiert und ohne konkrete Vorgabe zu unscharf fuer eine
automatisierte Umsetzung. Die sechs konkret genannten Hosts/IPs gehoeren in
die lokale, nicht versionierte hosts.conf (Analogon zu credentials.conf) und
damit auf den Produktivserver, nicht in dieses oeffentliche Repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher wurde ein Ticket sofort an seiner neuen Spalte gezeichnet, sobald ein
Statuswechsel erkannt wurde - der Tuerbesuch (Rolle "user") bzw. PO-Besuch
liefen davon unabhaengig erst danach als reine Kosmetik ab. Jetzt haelt
office-render.js das betroffene Ticket an seiner alten Stelle (neue Tickets
bleiben ganz verborgen), bis die zugehoerige Persona am Board angekommen ist
("interacting_with_board"), verschiebt es dann sichtbar und laesst die
Persona danach eine Sekunde stehen, bevor sie den Rueckweg antritt.
applyPendingTicketMoves() in office-scene.js kapselt die dafuer noetige
Merge-Logik pur und testbar; office-render.js reicht die passenden
onArrived-Callbacks an triggerDoorVisit()/triggerPoVisit() durch.
Nach dem Anlegen/Bearbeiten eines Projekts im Konfig-Dialog prueft ein neuer Endpunkt
(POST /api/v1/repo-configs/{id}/check), ob fds2610-bot dort Schreibrechte hat und ein
aktiver Webhook auf diese monitor-Instanz zeigt. Das Ergebnis erscheint als gruener Haken
bzw. rotes Kreuz rechts neben den Bearbeiten-/Loeschen-Symbolen, mit Tooltip zum geprueften
Service bzw. zur Fehlerursache.
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>
Der Agent (fds2610/Agent#9) setzt "help wanted" auf Issues, waehrend er auf
die Erfuellung einer externen Voraussetzung wartet. Solche Issues sollen im
Monitor-Board in der Spalte "QA" auftauchen statt im Backlog zu verschwinden.
"qa" wird dafuer wie "backlog"/"bereit"/"in_arbeit"/"testing"/"done" zur
sync-verwalteten Spalte; nur "fertig" bleibt weiterhin fuer ein zukuenftiges
Label reserviert und rein manuell.
