Add readable case details and completed results browser

docs/test-results/web-case-details-20261021.md

@@ -0,0 +1,29 @@
+# Falldetailansicht und Ergebnisliste – 2026-10-21
+
+Ziel: Erhaltene Fallakten direkt im Browser lesen, ohne ZIP-Verzeichnisse manuell
+zu durchsuchen. Keine Änderung an Analyseprompts, Budgets oder Architekturvorgaben.
+
+Implementierung: projektgebundene Leseendpunkte, Ergebnisliste mit Suche und
+Projektfilter, Revisionsauswahl, Beobachtungen, Interpretation, Hypothesen mit
+Confidence und Befunden, Diagnose, Coding-/Human-Dev-Aufträge, API-Patchfeedback,
+Sperrhinweise und vollständiger aktueller ZIP-Download.
+
+Prüfungen:
+
+- `pytest tests/test_dashboard.py -q`: 18 bestanden. Authentifizierung, Projektscope,
+  vollständiger ZIP-Download, ungültige Revisionen und wiedereröffnete Fallakte:
+  alte Interpretation bleibt in Revision 1, erscheint nicht in Revision 2.
+- Zusammen mit `tests/test_worker.py`: 36 Tests bestanden.
+- `node tests/dashboard-smoke.mjs`: PASS im echten unsichtbaren Edge-Browser,
+  Desktop und 390-Pixel-Mobilansicht, keine horizontalen Überläufe oder JS-Fehler.
+  Ergebnisnavigation, Coding-/Human-Aufträge und Datenentfernung bei Abmeldung.
+- Browserdaten sind rein synthetisch; ihre 35.300 Tokens sind Anzeigeprüfwerte,
+  keine realen Modellmessungen. Keine kostenpflichtigen LLM-/DB-Anfragen.
+- Vor Testbeginn: Test-Workspaces 16.939.129.428 Bytes, zusätzlich kleines
+  Fehlerkorpus und temporäre pytest-Daten deutlich unter 20 GB insgesamt.
+  Browser-/Server-Testverzeichnisse werden nach geprüften Pfaden entfernt.
+
+Grenzen: Sperrhinweise sind Information, keine administrative Freigabeoberfläche.
+Das Belegverzeichnis ersetzt nicht die vollständigen Recherchepayloads im ZIP.
+Große Darstellungen werden gekennzeichnet gekürzt; Paketinhalt bleibt unverändert.
+Die Revisionshistorie benötigt keine aufbewahrten älteren ZIP-Generationen.

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