update.sh meldet nach dem Neustart ein Event (POST /api/v1/events/system, Admin-Key).
upsertPullRequest markiert bereits vorhandene Tickets als Pull Request, damit sie den
/pulls/-Link bekommen.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
PRs werden beim Sync als Tickets (is_pull_request) angelegt, mit
Projektfarbe, schwarzen Querstreifen und PR-Nummer; im Spalten-Modal
mit Link auf den PR.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Der sync-Container legt api/data/deploy-requested an, sobald die Zahl offener
PRs sinkt. deploy-webhook.py prueft dann per git fetch, ob origin/main vor dem
lokalen Stand liegt, und startet nur dann update.sh. Fallback fuer einen
verpassten Push-Webhook ohne zusaetzliche Codeberg-Verbindung.
Ausloeser waehrend eines laufenden Updates werden nicht mehr verworfen,
sondern loesen einen Folgelauf aus.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Die Spalten-Ansicht selbst braucht weiterhin "aeltestes zuerst" fuer
die Board-Regel (aelteste 4 einzeln, Rest als Stapel, F3), daher wird
die Liste nur fuer die Modal-Ausgabe (Klick auf eine Kanban-Spalte)
umgedreht.
Schließt #102
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Das Event-Modal zeigte bisher die volle vom Server gelieferte Liste
(bis zu 200 Events) ungefiltert an und war dadurch schnell unuebersichtlich.
filterEventsForToday() schraenkt die Anzeige auf Events des aktuellen
Kalendertags (lokale Zeitzone, wie formatEventTime()) ein.
Schliesst #100
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
updateAgentsLayer() referenzierte nach dem Voice-Bot-Umbau (be1d613) noch
isRealAgent, obwohl die Variable in isVoiceBot umbenannt wurde. Das warf bei
jedem Rendern und jedem Ticket-getriebenen Board-Besuch einen ReferenceError,
der die Aktualisierung der Agenten-Schicht abbrach - dadurch blieb der PO
unsichtbar und Ticket-Statuswechsel wurden nicht mehr visuell nachvollzogen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der PO laeuft auf dem Monitoring-Server selbst und repraesentiert dessen
interne Prozesse. Bisher wurde er als "abwesend" gezeichnet, sobald der
Browser die API kurzzeitig nicht erreichen konnte (isLive=false) - obwohl
der Server und seine Prozesse in diesem Fall weiterliefen. Der feste
PO-Platz zeigt den PO jetzt unabhaengig von isLive.
Schliesst #97
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
refresh() zeigte den roten Banner bisher fuer jeden Fehler im gesamten try-Block, auch wenn
loadLiveData() laengst erfolgreich war und erst das anschliessende Verarbeiten/Zeichnen der
Live-Daten scheiterte (Issue #94: Produktion meldete "API nicht erreichbar", obwohl ein
direkter curl-Aufruf die API nachweislich erreichte). Jetzt entscheidet ausschliesslich der
Erfolg von loadLiveData() ueber Banner/Demo-Fallback; ein spaeterer Fehler beim Verarbeiten
wird nur noch geloggt, ohne die Erreichbarkeit faelschlich zu verneinen.
Getestet: composer test (262 Tests) und npm test/frontend (98 Tests) in Docker, beide gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
update.sh startete api/web/sync bereits neu, bevor die Testsuiten liefen - schlugen sie
danach fehl, brach das Skript per set -e ab, aber die Produktion lief bereits mit dem
fehlerhaften Stand weiter. deploy-webhook.py meldet einen solchen Abbruch nirgends aktiv,
nur still im Log - ein Update konnte so unbemerkt eine kaputte Version live schalten.
Zusaetzlich: setApiBanner(true) steht jetzt in einem eigenen finally im Demo-Fallback von
boot()/refresh() - ein Fehler beim Neuzeichnen der Szene darf nicht mehr verhindern, dass
der "API nicht erreichbar"-Banner erscheint.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
