Add web overview with worker progress and separate correction token charts

docs/web-console.md

@@ -0,0 +1,101 @@
+# Webübersicht
+
+Die Betriebsübersicht wird durch die bestehende Übergabe-API ausgeliefert:
+
+```powershell
+.\.venv\Scripts\python.exe -m viano_bug_analysis.api serve --config config/api.local.toml
+```
+
+Anschließend `http://127.0.0.1:8080/` öffnen und mit einem freigegebenen **API-Token**
+anmelden. Dies ist nicht der Gemini-Schlüssel. Der Token bleibt ausschließlich im
+Arbeitsspeicher des Tabs, nicht in Cookies, Local Storage oder URLs. Für entfernte
+Zugriffe HTTPS verwenden. Der Analyseworker läuft unabhängig davon wie unter
+[Analyseworker](analysis-worker.md) beschrieben. Das Öffnen der Übersicht löst
+keine Modellanfragen aus.
+
+## Worker und Fortschritt
+
+Die Startseite listet lebende Worker und darunter den jeweils bearbeiteten Fall
+mit seinem Namen und einem Ladebalken. Der bestehende Dienst erlaubt einen Worker
+je Workspace; die Darstellung ist bereits als Liste aufgebaut. Die Einführung
+eines parallelen Worker-Pools ist damit nicht verbunden.
+
+Der Balken folgt abgeschlossenen Arbeitsschritten, nicht vergangener Zeit. Seine
+sieben Anteile entsprechen intern Aufnahme, Fallaufbau, Interpretation,
+Hypothesenbildung, Untersuchung, Diagnose und Codingauftrag. Die Oberfläche führt
+diese Stufen nicht einzeln auf. Der Codingauftrag ist die letzte Stufe, auch wenn
+sein Dokument fachlich erklärt, dass kein Codingauftrag benötigt wird. Bei
+gemeinsamer Interpretation/Hypothesengenerierung können zwei Anteile gleichzeitig
+fertig werden. Eine lang laufende Untersuchung füllt den Balken nicht künstlich.
+
+Der aktive Fall verschwindet bei `OUTPUT_READY`, `HANDED_OFF` oder
+`FAILED_TO_ANALYZE` aus der Workeransicht und der Tabelle laufender Fälle. Er bleibt
+in der Verbrauchsstatistik enthalten. Wartende Fälle bleiben in der Fallübersicht,
+belegen aber keinen arbeitenden Worker. Ein alter Dienstsnapshot ohne lebenden
+Telemetrie-Heartbeat wird nicht als aktiver Worker dargestellt.
+
+## Verbrauch
+
+- Kreisdiagramm: bekannte Eingabe- und Ausgabetokens je Phase; zusätzliche
+  Korrektur-/Reparatur-/Wiederholungsaufrufe haben ein eigenes orangefarbenes Segment.
+- Balkendiagramm: Eingabe und Ausgabe einschließlich Denken je Kategorie.
+- Der erste reguläre Aufruf bleibt bei seiner Phase, auch wenn sein Ergebnis später
+  zurückgewiesen wurde. Seine Korrektur wird ausschließlich dem Korrektursegment
+  zugeordnet. Abgeleitete, deterministisch reparierte Antwortdokumente sind keine
+  zusätzlichen Anbieteraufrufe und werden nicht erneut gezählt.
+- Denktokens sind bereits Bestandteil der Ausgabetokens. Sie werden weder zum
+  Kreisdiagramm noch zum Gesamtverbrauch noch einmal hinzuaddiert.
+- Neue LLM-Runden speichern ihre Verbrauchszuordnung deterministisch aus der
+  Operationskennung. Das verändert keine Prompts, Modellparameter oder Budgets.
+  Bereits gespeicherte Aufrufe bleiben unverändert. Bei älteren Akten wird nur
+  eindeutig erkennbare Korrekturinformation übernommen; sonst erscheint der Anteil
+  als „Nicht zugeordnet“.
+- Fehlende Messwerte bleiben unbekannt. Die Diagramme summieren nur bekannte Werte
+  und weisen unvollständige Aufrufe aus. Bei vollständig fehlender Tokennutzung
+  lässt sich deren Größe nicht als Kreisanteil darstellen.
+
+Der Messumfang umfasst **alle erhaltenen, für den Client freigegebenen Akten und
+deren Revisionen** im konfigurierten Workspace. Er ist keine Google-Abrechnung und
+keine lebenslange Statistik bereits gelöschter Akten. Dauerhafte Testbilanzen unter
+`docs/test-results/token-usage/` bleiben davon unabhängig. Ein Projektfilter wendet
+sich auf Fallliste, Worker und Diagramme gleichzeitig an. Gemeinsame Planungsaufrufe
+werden einmal als Fallplanung gezählt, nicht zusätzlich als Hypothesengenerierung.
+
+## Übergabe
+
+Die Oberfläche bietet ein einfaches Formular für neue wowdiag-/wowsrc-Aufträge und
+für abgeschlossene ZIP-Akten mit Testerfeedback. Es verwendet dieselbe Multipart-
+API und denselben Idempotenzmechanismus wie externe Programme. Bei unveränderten
+Eingaben verwendet eine Wiederholung denselben Schlüssel. Anhänge und Fallakten
+werden nicht clientseitig bearbeitet. Vollständige Falldetailansichten und eine
+Bedienoberfläche für administrative Worker-Eingriffe bleiben weitere Ausbauschritte.
+
+## Datenschutz und Betrieb
+
+`GET /v1/overview` benötigt einen Bearer-Token und liefert nur freigegebene Projekte.
+Prompts, vollständige Modellantworten, lokale Pfade und Zugangsdaten werden nicht
+an den Browser übergeben. Fallnamen werden als Text dargestellt. Die Seite lädt
+keine externen Fonts, Chartbibliotheken oder Analysedienste; Diagramme werden lokal
+mit Canvas/CSS gezeichnet. Eine Content Security Policy begrenzt Ressourcen auf
+denselben Ursprung. Abmeldung entfernt dargestellte Daten und Formularinhalte;
+verzögert eintreffende Antworten aus einer vorherigen Anmeldung werden ignoriert.
+
+Die Ansicht aktualisiert sich alle vier Sekunden. Validierte Darstellungen werden
+für unveränderte Paketgenerationen im API-Prozess zwischengespeichert; dies ist
+eine Anzeigeoptimierung, kein fachlicher Zustand und kein Analysecache.
+
+## Lokale Prüfung
+
+```powershell
+.\.venv\Scripts\python.exe -m pytest tests/test_dashboard.py -q
+node tests/dashboard-smoke.mjs
+```
+
+Der Browser-Smoke-Test verwendet einen lokalen temporären API-Server, einen
+unsichtbaren Edge-Browser und ausdrücklich künstliche Fall-/Verbrauchsdaten. Er
+prüft Desktop, Mobilansicht, Projektfilter, Formularumschaltung, Abmeldung,
+Tokenanzeige, Fortschritt und Browserfehler. Unter Windows wird der installierte
+Edge erwartet; über `BROWSER_PATH` lässt sich ein anderes Chromium angeben.
+Die Testserver/-browser werden beendet, ihre erzeugten temporären Verzeichnisse
+nach Pfadprüfung entfernt. Screenshots als Prüfergebnis liegen unter
+`service-data/ui-preview/`. Es werden keine LLM- oder Datenbankanbieter aufgerufen.