Add web overview with worker progress and separate correction token charts

docs/intake-api.md

@@ -39,6 +39,7 @@ Weitere Projekte benötigen passende Adapter/Profile, keine separat gepflegten F
 | `GET /healthz` | Minimale öffentliche Erreichbarkeitsprüfung |
 | `GET /v1/profiles` | Für diesen Client freigegebene Projekte/Profile |
 | `GET /v1/schema` | Öffentliches JSON-Schema der Übergabemetadaten |
+| `GET /v1/overview` | Projektbezogene Worker-/Fallübersicht und Tokenstatistik |
 | `POST /v1/submissions` | Multipart-Upload, `201` bei neuer Einreihung, `200` bei Wiederholung |
 | `GET /v1/submissions/{id}` | Quittung und aktueller verwalteter Zustand |
 | `GET /v1/submissions/{id}/package` | Abgeschlossene Akte herunterladen; sonst `409` |

docs/test-results/web-console-20261021.md

@@ -0,0 +1,40 @@
+# Webübersicht – lokale Prüfung vom 2026-10-21
+
+Ausgangspunkt `012a8d8`. Keine kostenpflichtigen Modellanfragen und kein echter
+Analyseworker gegen Nutzeraufträge gestartet.
+
+224 automatisierte Tests bestanden: Dashboard/Zuordnung, Worker/Intake,
+Antwortreparatur, Response-Recovery, Gateway, Fehlerdiagnostik und Cache.
+Die Verbrauchszuordnung ergänzt ein optionales Feld im gespeicherten LLM-Aufruf;
+vorhandene Aufrufe bleiben unverändert und bestehende Schemas kompatibel.
+
+Geprüft wurden insbesondere:
+
+- Zugriffsschutz und Projektfreigaben des Overview-Endpunkts;
+- Fallname, Fortschritt nach abgeschlossenen Stufen und Ausblenden abgeschlossener Fälle;
+- keine Anzeige alter Worker-Snapshots als lebender Worker;
+- regulärer erster Aufruf und zusätzliche Korrektur als disjunkte Kategorien;
+- abgeleitete Dokumente und doppelte Checkpoint-Verweise nicht erneut als Aufrufe gezählt;
+- Denktokens nicht erneut auf die Ausgabe addiert;
+- unbekannte Messwerte/Zuordnungen kenntlich gemacht;
+- Auslieferung lokaler Assets mit Content Security Policy.
+
+Zusätzlich realer Browser-Smoke-Test mit unsichtbarem Edge und synthetischer
+temporärer API: Desktop 1440×1200 und Mobil 390×1200, keine horizontale Überbreite,
+keine JavaScript-/CSP-Konsolenfehler. Projektfilter liefert dieselbe Summe,
+Rückgabeformular schaltet korrekt um, Abmeldung entfernt angezeigte Daten. Kein
+Token wurde im Local Storage abgelegt. Die erste Wiederholung des Browsertests
+traf eine zu frühe Testinteraktion vor Ausführung des defer-Scripts; die
+Wartebedingung wurde auf vollständige Dokument-/Scriptbereitschaft korrigiert.
+
+Die Vorschau zeigte genau einen aktiven Worker/Fall bei 57 %, einen bereits
+abgeschlossenen Fall ausschließlich in der Verbrauchsbilanz und 37.800 synthetische
+Tokens mit 20,6 % Korrekturanteil. Diese Werte sind **UI-Fixtures, keine gemessenen
+Analyse- oder Abrechnungskosten**. Screenshots liegen als lokale Prüfergebnisse
+unter `service-data/ui-preview/desktop.png` und `mobile.png`. Vollständige
+Testpakete und Browserprofile werden nicht als dauerhaftes Ergebnis archiviert.
+
+Speicheraudit vor den Tests: 16.939.129.428 Bytes Trial-Workspaces,
+2.471.041 Bytes Fehlerkorpus und 11.156.187 Bytes vorhandene pytest-Temporärdaten;
+die neuen synthetischen Tests/Screenshots sind klein und bleiben innerhalb der
+20-GB-Grenze. Temporäre Vorschauakten wurden entfernt.

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.