Add readable case details and completed results browser

docs/web-console.md

@@ -70,8 +70,35 @@ Die Oberfläche bietet ein einfaches Formular für neue wowdiag-/wowsrc-Aufträg
 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.
+werden nicht clientseitig bearbeitet. Administrative Worker-Eingriffe bleiben ein
+weiterer Ausbauschritt.
+
+## Fallakte und Ergebnisse
+
+Fallnamen verlinken auf eine lesbare Detailansicht mit Testerbeobachtungen,
+Interpretation, Hypothesen, Confidence, stützenden und widersprechenden Befunden,
+Diagnose sowie Coding- und Human-Dev-Auftrag. Befunde bleiben ausdrücklich
+KI-Bewertungen mit Belegreferenzen. Das Belegverzeichnis zeigt Herkunft und
+Abdeckungsinformationen; die vollständigen Recherchepayloads stehen im ZIP.
+Ein expliziter Auftrag „Kein Auftrag“ wird von einem noch nicht erstellten Dokument
+unterschieden. Die separate Ergebnisliste enthält abgeschlossene und zur
+menschlichen Prüfung ausgeleitete Fälle, mit Projektfilter und Suche.
+
+Die Revisionsauswahl liest akzeptierte Artefakte aus der Checkpointhistorie der
+aktuellen vollständigen Akte. Ergebnisse neuerer Revisionen erscheinen nicht in
+älteren Ansichten. Über die Übergabe-API erfasste Patch-Rückmeldungen werden bis
+zur gewählten Revision dargestellt. Bei gesperrten Fällen erscheinen Sperrgrund
+und passende Betreiberhinweise; die Ansicht setzt keine Budgets zurück und hebt
+keine Sperren auf.
+
+`GET /v1/cases/{key}?revision=N` liefert diese projektgebundene Ansicht.
+`GET /v1/cases/{key}/package` lädt die vollständige aktuelle Akte einschließlich
+aller erhaltenen Revisionen herunter, auch als Zwischenstand eines laufenden Falls.
+Beide Endpunkte benötigen denselben Bearer-Token und verwenden `no-store`.
+Der Schlüssel stammt aus der Übersicht, nicht aus einem lokalen Dateipfad.
+Große Anzeigeinhalte werden begrenzt und als gekürzt gekennzeichnet. Der Download
+bleibt vollständig; die Anzeige verändert keine Paketgeneration und löst keine
+LLM-Aufrufe aus.
 
 ## Datenschutz und Betrieb
 
@@ -97,7 +124,9 @@ 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
+Tokenanzeige, Fortschritt, Ergebnisliste, Falldetails, Aufträge und Browserfehler.
+Die API-Tests prüfen zusätzlich Projektzugriff, ZIP-Download und Revisionsisolation.
+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