feat(dashboard): KPI-Kacheln in zwei Gruppen + Wall-Clock-Tooltip korrigiert

[TillQuandel]

Befund / Kontext

Zwei separate Nachbesserungen im selben Bereich (Dashboard-KPI-Kacheln), zusammengefasst in einem PR auf Tills Wunsch.

1) KPI-Layout (Till-Entscheid): Die 9 KPI-Kacheln im Übersicht-Abschnitt liefen bisher als eine flache Reihe (7-Spalten-Grid, 9 Kacheln => 7+2-Umbruch). Till wollte stattdessen zwei beschriftete Gruppen — explizit kein Slider/Karussell (Anti-Pattern).

2) Tooltip-Nit aus PR #266 (gh pr view 266, gh issue view 239 gelesen): Der Tooltip der Kachel „Wall-Clock (aktuell)" behauptete, bei deaktiviertem Inline-Eval sei die Wall-Clock „0,0h". Das ist fachlich falsch: insert_run() schreibt wall_clock_s beim Insert immer identisch zu duration_s (echter Messwert, orchestrator.py _wall_s = round(time.time() - _run_start, 1)). update_wall_clock_s() korrigiert die Zeile nur nach oben, wenn Stage-8 anschließend lief. Ohne Stage-8 bleibt wall_clock_s also ein echter, von 0 verschiedener Wert — 0,0h gilt nur für echte Alt-Zeilen von vor der #239-Spalte (Spalten-Default, kein Messwert).

Fix

Gruppierung (internal/dashboard/eval_dashboard.html):

• Zwei Container #kpis-quality (4 Kacheln) und #kpis-perf (5 Kacheln) statt einem #kpis, je mit eigener Sub-Head-Beschriftung — „Kosten & Performance" wiederverwendet den bereits bestehenden Sektionsnamen (id="s-cost") statt einen neuen Begriff einzuführen (SSoT).
• CSS: .kpis-quality/.kpis-perf bekommen eigene grid-template-columns (4 bzw. 5 Spalten — passt exakt in eine Zeile statt asymmetrisch umzubrechen wie vorher). Responsive Breakpoints (1200px/900px) neu und korrekt je Gruppe berechnet (die alten nth-child-Regeln waren auf die einzelne 9-Kachel-Reihe zugeschnitten und hätten bei blinder Wiederverwendung Doppel-Rahmen an der letzten Zeile erzeugt — deshalb sauber neu hergeleitet statt kopiert).
• JS (renderKpis): kpiDefs bleibt EIN Array (unverändert in Reihenfolge/Inhalt bis auf den Tooltip-Fix) — die HTML-Strings werden per .slice(0, 4)/.slice(4) auf die zwei Container verteilt. _openKpiIdx bleibt ein Index ins ungeteilte Array, Sparkline-Klick-Verhalten unverändert.
• renderSkeleton() befüllt jetzt beide Container mit passender Skeleton-Anzahl (4/5 statt vorher 7 in einem Container).
• Alle 9 Kacheln, IDs, Tooltips, Sparklines, Tone-Farben unverändert — reine Gruppierung, kein Redesign. frontend-design-Skill vor dem Layout-Entwurf geladen und dezent angewendet (bestehende Designsprache respektiert: Struktur/Beschriftung kodiert die Bedeutung, keine neuen Farben/Fonts).

Gruppenzuordnung (alle 9 Kacheln passten exakt in die von Till genannten 2×4/5 — keine zusätzlichen Kacheln im HTML gefunden):

Gruppe	Kacheln
Qualität	Automatisch akzeptiert, Fehlerquote, Belegrate, Evaluierte Notes
Kosten & Performance	Agent-Rechenzeit (Summe), Wall-Clock (aktuell), Billable Tokens, Tokens (ohne Cache), API-Kosten

Tooltip-Fix (Kachel kpi-wall, neuer Wortlaut):

Summe der ECHTEN Wall-Clock-Zeit (Beginn bis Ende) aller Läufe der aktuellen Version, in Stunden — im Gegensatz zur Kachel „Agent-Rechenzeit" daneben (Summe der Call-Dauern, mit Overlap bei Parallelität). Inklusive Stage-8-Qualitäts-Eval, sofern er lief. Bei deaktiviertem Inline-Eval (kein Stage-8) ist der Wert trotzdem echt und NICHT 0,0 h: er entspricht der real gemessenen Laufzeit bis zum Pipeline-Ende, weil dort keine separate Eval-Phase fehlt, die noch dazukäme. 0,0 h nur bei Läufen, deren Daten vor der Wall-Clock-Persistierung entstanden (#239) — dort fehlt die Spalte schlicht, kein Messwert.

TDD / RED-Beleg

RED vor der Implementierung (5 neue Tests schlugen erwartungsgemäß fehl, 6 bestehende PR-#266-Tests blieben grün):

FAILED generative/tests/test_dashboard_kpi_groups.py::test_html_has_two_labeled_kpi_group_containers
FAILED generative/tests/test_dashboard_kpi_groups.py::test_kpi_group_containers_appear_in_document_order_quality_then_perf
FAILED generative/tests/test_dashboard_kpi_groups.py::test_kpi_defs_order_matches_group_split_quality_first_four_perf_last_five
FAILED generative/tests/test_dashboard_wall_clock_kpi.py::test_wall_clock_tooltip_does_not_claim_zero_for_disabled_inline_eval
FAILED generative/tests/test_dashboard_wall_clock_kpi.py::test_wall_clock_tooltip_explains_disabled_inline_eval_as_real_nonzero_value
5 failed, 6 passed

Neue Tests (11 gesamt, alle grün nach Fix):

• generative/tests/test_dashboard_kpi_groups.py (neu, 4 Tests): zwei Container-IDs vorhanden, kein Slider/Karussell-Pattern, Container-Reihenfolge Qualität→Kosten&Performance, kpiDefs-Label-Reihenfolge + Slice-Grenze bei Index 4 verankert.
• generative/tests/test_dashboard_wall_clock_kpi.py (erweitert, 2 Tests): alte falsche Formulierung nicht mehr im HTML, neue korrekte Formulierung vorhanden.

Suite / Lint

• pytest generative lib/decision_engine/tests shared/tests -q: 5863 passed, 3 skipped, 8 deselected.
• ruff check .: sauber. ruff format --check .: 273 files already formatted.

Playwright-Sichtverifikation

Server (Port 8062, ATOMIC_DB_PATH auf Kopie der Live-DB in C:/tmp/kpi-db.db, read-only) lief korrekt, /data.json erreichbar (Status 200). Browser-Screenshot (Firefox/Playwright-MCP) ließ sich in dieser Session nicht durchführen — Launch scheiterte zweimal mit Failed to launch the browser process bei ~3,9 GB freiem RAM von 16 GB (dasselbe bekannte Ressourcenproblem wie in PR #266 dokumentiert).

Ersatzverifikation (manuelle Nachsicht im Browser empfohlen): den tatsächlich vom laufenden Server ausgelieferten HTML-Response direkt per Invoke-WebRequest abgefragt und alle neuen Marker bestätigt — id="kpis-quality", id="kpis-perf", Kosten & Performance, beide Kachel-Labels, neuer Tooltip-Wortlaut, beide Slice-Grenzen (.slice(0, 4)/.slice(4)) — alle vorhanden. Zusätzlich /data.json gegen die Live-DB-Kopie geprüft: cur_dur_h=5,2, cur_wall_h=0 (auf diesem Datenstand plausibel — Altdaten ohne persistierte Wall-Clock, exakt der im korrigierten Tooltip beschriebene Fall, kein Bug).

Scope

Nur internal/dashboard/eval_dashboard.html + neue/angepasste Tests. Keine Python-Logik-Änderungen (_calc_kpis etc. unangetastet).