konzept vertraulich owner: matus

Review: „TuxAmetrics Hi-Fi Prototyp Daniel" (2026-08-19)

Status: offen · Adressat: Entwicklung (Stufe A sofort startbar) + Product Owner (Stufe D) · Quelle: C:\Users\matus\Downloads\TuxAmetrics Hi-Fi Prototyp Daniel.html (Claude-Artifact-Bundle, 10 Screens 00–09, dekodiert nach TODO-raw/extracted/) sowie fünf bereits vorher abgelegte Screenshots derselben Design-Linie unter TODO-raw/*.png.

Dieses Dokument beantwortet dieselbe Frage wie frontend-spezifikation-v1-review.md, nur für ein UI-Artefakt statt eines Prozess-Textdokuments: was ist sofort baubar, was widerspricht getroffenen Entscheidungen, und was braucht erst eine Scope-Entscheidung?

Provenienz — hier unkritisch

Anders als die BPMN-Spezifikation vom 2026-08-13 zitiert dieses Artefakt keine FACH-NNN-Nummern und behauptet keine fachliche Quelle — es ist ein reines UI/UX-Zielbild. Die Provenienzfrage aus v13-fachlicher-backlog-epics.md Befund 1 greift hier nicht.

Wichtiger Befund vorab: Fünf der zehn Screens sind keine neue Vorgabe. Die PNGs in TODO-raw/ (DASHBOARD.png, LETZTE_DAELLE.png, Patient Detail.png, Patienten Liste.png, Stammdaten_regelwerk.png) sind exakt die Mockups, auf die sich navConfig.ts und HomeRoute.tsx bereits heute berufen ("Dashboard-Mockup", 2026-08-17/18 umgesetzt). Das HTML-Bundle ist die Ablauf-Ergänzung dazu: die sechs Schritte einer einzelnen Fallbearbeitung (01–06), die in den PNGs nicht vorkamen. Nur diese sechs plus der bisher fehlende Screen 08 sind wirklich neu.

Leitplanken-Check (gute Nachricht zuerst)

Im Gegensatz zur Spezifikation vom 2026-08-13 verletzt dieses Artefakt die CLAUDE.md-Leitplanken an den zwei kritischen Stellen nicht:

Kein E2 irgendwo. Screen 04 Ergebnis zeigt eine einzige Auffälligkeits-Tabelle (Wert/Ergebnis/Laborreferenz/Zielbereich/Einschränkung) — keine E1/E2/E3-Tabs, keine „Störungsebenen". Konsistent mit Leitplanke 3.
Keine Medikamenten-Interaktionsprüfung. Screen 02 Angaben zeigt bei einem Medikament nur „nicht erkannt — zuordnen" (Erfassung), keine „betrifft B12, Magnesium, Eisen [ST]"-Bewertung wie die alte Spezifikation. Kein Konflikt mit Leitplanke 4.
GM-7 durchgängig sichtbar. Screen 05 Therapie: annehmen/ändern/ablehnen pro Empfehlung, „Ohne Entscheidung keine Freigabe". Screen 06 Freigabe: „Fall freigeben" ist mechanisch gesperrt („Freigabe ist gesperrt"), bis eine Checkliste abgearbeitet ist, und trennt explizit blockierende Punkte (rot, „Noch zu erledigen") von reinen Hinweisen (gelb, „halten die Freigabe nicht auf"). Das ist exakt die Trennung, die frontend-spezifikation-v1-review.md als E-14 (Stufe B, Punkt 6) führt — dieses Mockup liefert dafür erstmals ein konkretes UI-Bild.

Ein echter Konflikt bleibt: Screen 09 Kataloge & Regelwerk zeigt eine editierbare Regelwerk-Pflegefläche (Dosisobergrenzen-Einträge hinzufügen, Versionsverwaltung, „Vorschläge aus der Fallarbeit in R-Praxis übernehmen"). Das steht gegen gold-path-scope.md („R-Praxis bleibt draußen", P2) und gegen die bereits getroffene, begründete Entscheidung in navConfig.ts, den entsprechenden Menüpunkt durch „Systemsteckbrief" zu ersetzen, weil Regelkatalog.java keinen Lese-Endpunkt hat. Dieser Screen ist Stufe D (siehe unten) — an dieser Stelle nichts anfassen ohne Product-Owner-Freigabe.

Screen-für-Screen-Ist-Abgleich

Screen	Ist-Stand	Einordnung
`00 Home`	Bereits überholt: `HomeRoute.tsx` (2026-08-17) ist eine ausgereiftere, datenehrliche Version derselben Mockup-Linie (KPI-Kacheln statt Hero-Zeile). Die zwei Elemente, die dieser HTML-Screen zusätzlich zeigt — namentliche Begrüßung, „Befund hochladen"-Button — sind dort bereits bewusst und begründet weggelassen (kein Anzeigename via `/me/capabilities`, kein Upload-Endpunkt).	Nichts zu tun — Regression ggü. Ist-Stand, nicht Fortschritt
`01 Neue Auswertung`	Patientensuche/-auswahl: `PatientResource.search` existiert. Befund-Upload mit Hintergrund-Auslesen: keine Upload-/OCR-Pipeline im gesamten Repo (kein `multipart`-Endpoint, kein Konsument dafür).	Patientenwahl Stufe A; Upload Stufe D (siehe unten)
`02 Angaben`	Basisdaten-Bestätigung: Scope-Gate-Logik existiert backendseitig vollständig (`FACH-017`, seit 2026-08-13 gebaut), UI zeigt sie bisher nur als Badge. Medikament/Supplement-Erfassung: `POST .../medikation`, `POST .../supplemente` existieren. Sicherheitsfragen (Gewichtsverlust/Anämie/Infekt): decken sich mit dem bereits gebauten 8-Item-Katalog von `RedFlagScreening` (`FACH-029`) — zu verifizieren, ob Wortlaut/Umfang identisch sind. „Medikament nicht erkannt → zuordnen" (Substanzauflösung) ist nicht baubar (`OF-07`).	Größtenteils Stufe A — Ausnahme Substanzauflösung
`03 Werte prüfen`	Deckt sich mit vorhandenem `MesswertTable.tsx` + `korrigiereMesswert`-Endpoint. Der Screen ist im Kern eine fokussierte Ein-Wert-nach-dem-anderen-Ansicht desselben Datenbestands. Split-View mit Original-PDF und Sprung zur Fundstelle braucht das Dokument aus Schritt `01` — nicht vorhanden.	Wertprüfung Stufe A; PDF-Split-View Stufe D
`04 Ergebnis`	Direktes Gegenstück zu `FindingTable.tsx` (E1/E3) + einer „nur auffällige Werte"-Filteransicht von `MesswertTable`. Die „Zuerst zu klären"-Sperrbox entspricht dem bereits existierenden Sperrmechanismus (Red-Flag/kritischer Befund → keine Empfehlung).	Stufe A
`05 Therapie`	Deckungsgleich mit `TherapieplanPage.tsx`, laut `frontend-spezifikation-v1-review.md` bereits „am besten abgedeckter Schritt" — `annehmen/ändern/ablehnen` über `empfehlungen/{key}/entscheidung`. Tageszufuhr-Balken und Tagesverlauf-Einnahmeplan sind eine Restyle-Frage, keine neue Datenquelle (Dosisstatus/Zufuhrbilanz-Text existiert laut Review bereits). Präferenzen-Chips: `PatientCreate`/`Patient`-Modell trägt bereits `veganPraeferenz`, `maxPraeparateProTag`, `abgelehnteSubstanzen` etc. — Datenquelle vorhanden.	Stufe A, eine Restyle-Aufgabe
`06 Freigabe & Bericht`	`TherapieplanResource.freigabe` + `BerichtResource`-Vorschau existieren bereits. Die Blockierend/Hinweis-Trennung ist `E-14` aus der alten Spezifikations-Review, dort in Stufe B mit der Einschränkung „ohne `FACH-031` nur 8 von 10 Kategorien". `FACH-031` (vierstufige klinische Tragweite) wurde laut Nachtrag desselben Dokuments am 2026-08-13 nachträglich gebaut. `E-14` ist damit voraussichtlich neu zu bewerten — höchster Einzelwert dieser ganzen Review, siehe unten.	Zwei Berichts-Vorschauen Stufe A; die Checklisten-Trennung Stufe A, aber mit Re-Check von `E-14`
`07 Patientenübersicht`	Deckt sich mit `PatientUebersichtPage.tsx` (237 Zeilen, bereits aus derselben Mockup-Linie gebaut).	Vermutlich größtenteils erledigt — Abgleich der Filter-Tabs offen
`08 Patient anlegen`	Echte Lücke. Es gibt nur `PatientAnlegenDialog.tsx` — ein Minimal-Dialog mit genau einem Feld (`interneReferenz`). `PatientCreate.java` unterstützt serverseitig bereits alle Felder, die der Prototyp zeigt: Alter/Geburtsjahr, Referenzgeschlecht, dauerhafte Sicherheitsmerkmale (`PatientResource./sicherheitsmerkmale`), sämtliche Präferenzfelder. Keine Backend-Lücke — reine Frontend-Aufgabe.	Stufe A, höchstes Aufwand/Nutzen-Verhältnis
`09 Kataloge & Regelwerk`	Editierbare Regelwerkspflege inkl. `R-Praxis`-Governance. Kein Lese-Endpunkt für `Regelkatalog.java` (bestätigt in `navConfig.ts`-Kommentar), `R-Praxis` explizit draußen (`gold-path-scope.md`).	Stufe D — Scope-Entscheidung nötig, nicht anfassen

Vorschlag

Stufe A — sofort startbar, keine Backend-Lücke, kein Scope-Konflikt:

08 Patient anlegen als echte Seite statt Dialog. Größter Sofortwert: Backend trägt bereits alle Felder (Alter, Geschlecht, dauerhafte Sicherheitsmerkmale, Präferenzen), nur das Frontend zeigt sie nicht. Route + Formular analog zum Mockup, patientApi.create mit vollem PatientCreate statt nur interneReferenz.
Fallbearbeitung als geführter Schritt-Wizard statt drei flacher Reiter. AuswertungFrame.tsx (Befund & Findings / Therapieplan / Bericht) auf die Screens 02–06 abbilden: Angaben bestätigen → Werte prüfen → Ergebnis → Therapie → Freigabe & Bericht, mit Fortschrittsanzeige „Schritt X von 6" wie im Mockup. Nutzt ausschließlich bereits vorhandene Endpunkte (messwerte/medikation/supplemente/findings/empfehlungen/freigabe/bericht). Das ist die größte Einzelaufgabe dieser Liste — eine UX-Rearchitektur, kein neues Backend.
01 Neue Auswertung ohne Upload-Versprechen. Patientenwahl (bestehend) + AuswertungCreate (Material/Laborprofil-Auswahl) + manuelle Messwert-Eingabe statt „Befund hochladen" — mit Formulierung, die keinen Upload behauptet (dieselbe Disziplin wie HomeRoute.tsxs Umgang mit demselben Button).
Scope-Gate/Basisdaten-Bestätigung als echter Screen statt nur Badge — Logik existiert seit FACH-017 (2026-08-13).
06 Blockierend/Hinweis-Checkliste (E-14) neu bewerten — jetzt, wo FACH-031 gebaut ist, könnte die zuvor auf „8 von 10 Kategorien" begrenzte Einschätzung aus frontend-spezifikation-v1-review.md überholt sein. Vor Implementierung kurz gegenzuprüfen, nicht blind übernehmen.

Stufe B — nutzbar, aber an eine Verifikation oder kleine Fachklärung gekoppelt:

Sicherheitsfragen in Screen 02 gegen den bestehenden RedFlagScreening-8-Item-Katalog abgleichen (vermutlich deckungsgleich, nicht geprüft).
07 Patientenübersicht-Filtertabs (Alle/Laufende Auswertung/Kontrolle fällig/Angaben veraltet/Sicherheitsmerkmale) gegen den bestehenden Code abgleichen — vermutlich größtenteils vorhanden, nicht Zeile für Zeile verifiziert.

Stufe C — kein Vorschlag ohne neue Backend-Fähigkeit:

Befund-Upload + Hintergrund-Auslesen (Screens 01, 03) — keine OCR-/Extraktions-Pipeline im Repo, keine Fundstelle dafür in FACH-*. Eigenes Epic, kein Frontend-Task.
„Medikament nicht erkannt → zuordnen" — Substanzauflösung, blockiert durch OF-07.

Stufe D — Scope-Entscheidung nötig, nicht anfassen:

09 Kataloge & Regelwerk komplett — steht gegen gold-path-scope.md (R-Praxis P2, draußen). Wenn gewünscht: eigene Product-Owner-Entscheidung, kein Nachbau des Mockups „weil es da ist".

Umsetzungsstand (2026-08-19)

Alle fünf Stufe-A-Punkte sind gebaut und getestet:

Patient anlegen als volle Seite (PatientAnlegenPage/PatientAnlegenRoute) statt des bisherigen Ein-Feld-Dialogs — alle PatientCreate-Felder (Basisdaten, Präferenzen). PatientAnlegenDialog.tsx entfernt (verwaist).
Fallbearbeitung als Fünf-Schritte-Wizard statt drei flacher Reiter: die vormals monolithische AuswertungDetailPage ist in AngabenPage/WertePruefenPage/ErgebnisPage aufgeteilt, AuswertungFrame zeigt nummerierte Schritte (2 Angaben, 3 Werte prüfen, 4 Ergebnis, 5 Therapie, 6 Freigabe & Bericht) plus einen statischen „Fall anlegen"-Haken davor.
Neue Auswertung-Screen (AuswertungAnlegenPage/-Route) — Patientenwahl, Fallangaben, ausdrücklich ohne Upload-Versprechen. Verlinkt aus HomeRoute, AuswertungUebersichtRoute und (rückwärts) aus Patient anlegen → „Anlegen und Auswertung starten".
Basisdaten-Bestätigung als echter Schritt statt Badge — Teil von AngabenPage, nutzt AuswertungUpdate.basisdatenBestaetigt.
E-14 blockierend/Hinweis-Trennung — Product-Owner-Entscheidung in dieser Session eingeholt (Scope-Erweiterung laut v12-nachzug-scope.md Punkt 1), dann gebaut: neuer Endpoint GET .../freigabe-checkliste, FreigabePanel zeigt getrennte Blöcke vor jedem Freigabeversuch.

Zusätzlich, weil beim Bauen als echte Lücken sichtbar wurden (nicht ursprünglich in der Stufe-A- Liste, aber ohne sie wäre der neue Wizard nicht benutzbar gewesen):

auswertungApi/patientApi hatten für weite Teile des Backends gar keine Schreib-Methoden im Frontend (create, Messwert-Korrektur, Medikation/Supplement-Erfassung, Sicherheitsmerkmal- Erfassung, auswerten) — alle ergänzt.
MesswertTable/MedikationTable waren reine Anzeige ohne jede Aktion; SupplementTable gab es gar nicht (Supplemente waren nirgends im UI sichtbar).
Kein Auslöser für POST .../auswerten existierte im UI — ein manuell angelegter Fall hätte nie Findings bekommen. Jetzt ein Knopf in ErgebnisPage.
PatientSicherheitsmerkmaleCard konnte nur entfernen, nie hinzufügen — ergänzt.

Zwei neue Backend-Tests in ReferenzfallGoldPathTest (E-14-Blocker + Checkliste), ein bestehender Test angepasst (Ferritin im Referenzfall braucht jetzt eine explizite Bestätigung vor der Freigabe). Voller Maven-Reactor (159 Tests) und tuxametrics-ui Typecheck/Build grün.

Nicht angefasst, wie geplant: Substanzauflösung (Stufe C, weiterhin durch OF-07 blockiert — eine UI-Zuordnung würde eine Fachtatsache vortäuschen, die das Material nicht liefert).

Nachtrag (2026-08-24) — Stufe C und Stufe D umgesetzt

Der Product Owner hat beide verbliebenen Stufen freigegeben:

Stufe C — Befund-Upload als bewusster Mock. AuswertungAnlegenPage zeigt jetzt einen Datei-Upload, der nichts hochlädt oder liest: ein Dateiname löst eine Demo-Verzögerung und drei fest hinterlegte, absichtlich unplausible „erkannte" Werte aus (999.9, erkennungsunsicherheit: hoch, GG-META-0005 §9 - implausibel statt geraten-plausibel). Die UI benennt an jeder Stelle, dass kein echtes Auslesen stattfindet. Keine neue Backend-Fähigkeit — die Werte laufen über das bestehende ergaenzeMesswert.

Stufe D — Kataloge & Regelwerk als Scope-Erweiterung. ADR-0010 holt den Menüpunkt zurück: GET .../regelkatalog liest Regelkatalog.java unverändert (Dosisobergrenzen, kritische Schwellen, Kontraindikationen, Sicherheitshinweise, Reevaluationsintervalle), R-Praxis ist ein echter, getesteter Verwaltungsmechanismus (Entwurf → Freigabe/Ablehnung, Pflichtbegründung, NUR_MENSCHEN für Entscheidungen). Kein Rückkanal in die Auswertungslogik und keine automatische Ableitung von Regelkandidaten aus der Fallarbeit — beides ist im Material nicht belegt und bleibt deshalb draußen (siehe ADR-0010 für die vollständige Abgrenzung).

Nicht abschließend verifiziert

Die Zuordnung in der Tabelle stammt aus gezielten Greps und dem Lesen der genannten Dateien (AuswertungResource, TherapieplanResource, PatientResource, PatientCreate, HomeRoute, navConfig, PatientAnlegenDialog), nicht aus einer vollständigen Testsuiten-Prüfung. Insbesondere offen: ob TherapieplanPage.tsx die Tageszufuhr-Bilanz bereits als Balken oder nur als Text zeigt, und ob die Sicherheitsfragen-Formulierungen in RedFlagScreening wortgleich zum Mockup sind.