- DELETE /api/v1/screens/{screenId}/status loescht einzelne Screen-Eintraege
- /api/v1/meta listet jetzt 5 Tools inkl. screen-status-delete und diagnostic_ui-Pfade
- filePlayerStatusStore persistiert den Status-Store atomar in einer JSON-Datei
- MORZ_INFOBOARD_STATUS_STORE_PATH aktiviert die Datei-Persistenz (leer = In-Memory)
- Integration-Test deckt den vollstaendigen Lifecycle: POST -> list -> HTML -> JSON -> DELETE -> 404 ab
- DEVELOPMENT.md beschreibt End-to-End-Entwicklungstest und neue Env-Variable
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Auto-Refresh auf GET /status/{screenId}:
screenDetailPageData bekommt RefreshSeconds (wie statusPageData). Das
Detail-Template rendert das Meta-Tag analog zur Uebersichtsseite mit
denselben 15 Sekunden, damit ein Screen seinen Zustand (z.B. fresh ->
stale, connectivity-Wechsel) auch ohne manuellen Reload sichtbar macht.
Test: meta-refresh-Tag jetzt in TestRouterScreenDetailPageRoute geprueft.
DRY-Refactor: Fehlermeldungen vereinheitlicht:
overviewQueryErrorMessage und overviewQueryErrorCode sind jetzt in
playerstatus.go definiert -- dort wo auch die Validierungslogik lebt.
writeOverviewQueryError delegiert vollstaendig an beide Helper statt
die Meldungen selbst zu duplizieren. Die vorherige Kopie in statuspage.go
mit abweichenden Satzendezeichen und Grossschreibung wurde entfernt.
Beide Fehlerpfade (JSON und HTML) nutzen jetzt exakt dieselben
Meldungstexte.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Drei eng zusammenhaengende Aenderungen in einem Commit, da sie dieselbe
Template-Infrastruktur teilen und gemeinsam die HTML-Diagnoseansicht
abrunden:
1. CSS-Extraktion (Verbesserung, kein Verhalten geaendert)
Das bisherige Inline-CSS wurde in die Konstante statusPageCSS
ausgelagert. statusPageCSSBlock injiziert es per String-Konkatenation
in alle Templates, sodass kein Template-Inheritance-Mechanismus
benoetigt wird und jede Seite eigenstaendig ausfuehrbar bleibt.
2. GET /status/{screenId} -- neue HTML-Detailseite
Zeigt den letzten bekannten Datensatz eines einzelnen Screens:
Derived State, Player-Status, Connectivity und Frische als
Summary-Cards; Timing- und Endpoints-Details in aufgeraeuemten
Key-Value-Tabellen. Verlinkung zurueck auf /status und auf den
bestehenden JSON-Endpunkt. Bei unbekanntem Screen: 404 mit HTML-
Fehlerseite und Rueck-Link.
Route: GET /status/{screenId}
3. HTML-Fehlerseite fuer /status bei ungueltigen Query-Parametern
Bisher lieferte handleStatusPage einen rohen JSON-Fehler, wenn
z.B. ?stale=banana uebergeben wurde -- inkongruent fuer einen
HTML-Endpunkt. writeStatusPageQueryError rendert jetzt dasselbe
statusPageErrorTemplate wie der Not-Found-Fall der Detailseite
und gibt text/html mit 400 zurueck.
Neue Tests (router_test.go):
- ScreenDetailPageRoute: prueft Inhalt, Links, Content-Type
- ScreenDetailPageNotFound: prueft 404 + HTML + Rueck-Link
- StatusPageRejectsInvalidQueryParams: prueft jetzt auch text/html
fuer alle Fehlerfaelle
Docs (PLAYER-STATUS-HTTP.md):
- Query-Parameter-Validierung mit erlaubten Werten und Fehlercodes
- Neue /status/{screenId}-Seite und HTML-Fehlerseiten dokumentiert
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Bisher wurden ungueltige Werte fuer server_connectivity und stale im
Listing-Endpunkt und auf der Statusseite stillschweigend ignoriert bzw.
fuehrten zu leeren Ergebnissen ohne Fehlermeldung. Beide Parameter werden
jetzt explizit auf erlaubte Werte geprueft und liefern bei ungueltiger
Eingabe einen 400-Fehler mit beschreibendem error_code – konsistent mit
der bestehenden Validierung fuer updated_since und limit.
Neue Tests (playerstatus_test.go):
- RejectsInvalidServerConnectivity
- RejectsInvalidStale
- RejectsInvalidUpdatedSince
- RejectsInvalidLimit
Neue Tests (router_test.go):
- StatusPageRejectsInvalidQueryParams (table-driven, alle 4 Faelle)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
