VianoBugAnalysis/docs/web-console.md

# 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.
  Die Legende zeigt Fallaufbau, Fallplanung, Hypothesen, Untersuchung, Diagnose und
  Codingauftrag auch bei null gemessenen Tokens. Nullwerte erzeugen keinen
  künstlichen Tortenanteil. Gemeinsame Planungsaufrufe bleiben einmal gezählt.
- 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.