Brainversum · tuxametrics Graph Admin

konzept vertraulich owner: matus

Review: „TuxAmetrics Frontend-Spezifikation v1" (extern, 2026-08-13)

Review: „TuxAmetrics Frontend-Spezifikation v1" (extern, 2026-08-13)

Status: offen · Adressat: Product Owner (Scope-Entscheidungen) + Entwicklung (die als „sofort nutzbar" markierten Abschnitte) · Quelle: C:\Users\matus\Downloads\TuxAmetrics_Frontend_Spezifikation_v1.md (813 Zeilen, 12 Prozessschritte + drei Übersichten [ST]/[PK]/[PR]), laut eigener Kopfzeile „abgeleitet aus dem BPMN-Modell TuxAmetrics_Auswertungsprozess_v1.bpmn", nicht im Repo.

Dieses Dokument beantwortet: was von der neuen Spezifikation ist jetzt schon nutzbar, was widerspricht getroffenen Entscheidungen, und was braucht eine eigene Scope-Entscheidung, bevor daraus Code wird? Es ist eine Review, kein Umsetzungsauftrag — dieselbe Rolle wie v13-fachlicher-backlog-epics.md, nur aus UI-Perspektive und für ein Dokument, das (noch) nicht Teil des Repos ist.

⚠ Ein Befund vor jedem Schritt: dieselbe Provenienzfrage wie bei referenzfaelle/

Die Spezifikation liegt in Downloads/, außerhalb jeder versionierten Materialzone, und beruft sich auf ein BPMN-Modell, das ebenfalls nicht im Repo liegt. Das ist strukturell derselbe offene Punkt wie Befund 1 in v13-fachlicher-backlog-epics.md (dort für referenzfaelle/): Solange nicht geklärt ist, woher TuxAmetrics_Auswertungsprozess_v1.bpmn und die darin implizit vorausgesetzte Fachlogik stammen (tuxamed/Bearbeitet/ vs. eine zweite, gleichrangige Quelle), darf keine Umsetzung aus dieser Spezifikation eine FACH-NNN-Fundstelle beanspruchen, die sie nicht selbst trägt. Die Spezifikation selbst zitiert FACH-NNN-Nummern konsistent mit dem bereits im Repo bekannten Backlog v1.3 — sie ist mit hoher Wahrscheinlichkeit ein Companion-Dokument derselben Quelle, aber das ist eine Annahme, keine Prüfung.

⚠ Der zentrale Scope-Konflikt: die Spezifikation setzt Ebene E2 als gebaut voraus

Schritt 6 („Fachliche Auswertung") macht „STÖRUNGSEBENEN E2" zum strukturellen Kernstück der Ansicht „Auswertungsergebnis" (Spec Z. 336–340), referenziert in Schritt 10 (Ebenen-Tabs „E1 / E2 / E3", Z. 548) und Schritt 12 (Berichtsabschnitt „E2 Störungsebenen", Z. 672). Das widerspricht:

Code-Realität (per Agenten-Recherche verifiziert): FindingTable.tsx gruppiert ausschließlich nach E1/E3; SystemsteckbriefService.java:86 dokumentiert das Fehlen der Patientenversion, an vergleichbarer Stelle dokumentiert der Bericht E2 als bewusst leeren Abschnitt (BerichtService, laut v13-Befund 2 mit einer inzwischen falschen Begründung — „kein Auffälligkeitsbereich" ist seit v1.3 widerlegt, der Scope-Ausschluss selbst aber unentschieden).

Konsequenz für die Umsetzung: Schritt 6, die E2-Anteile von Schritt 10/12 sowie die Priorisierungsfunktion in Schritt 9 (FACH-051, laut v13 „mit E2 baubar") sind erst nach der Stufe-0-ADR-Entscheidung umsetzbar. Alles andere aus der Spezifikation ist davon unabhängig.

⚠ Zweiter Konflikt: Schritt 2 grenzt an Leitplanke 4 (Medikamenten-Interaktion)

Der Mockup in Schritt 2 (Z. 118–124) zeigt bei einem erfassten Medikament „Betrifft: B12, Magnesium, Eisen, Calcium [ST]" — das liest sich wie eine aktive Interaktionsprüfung. CLAUDE.md Leitplanke 4 und gold-path-scope.md sind hier eindeutig: Medikation wird erfasst und angezeigt, aber nicht regelbasiert geprüft (OF-07, Wirkstoffauflösung ungeklärt). Eine reine Katalog-Anzeige „dieser Wirkstoff ist in folgenden Interaktionen katalogisiert" wäre zulässig (Kennzeichnung, keine Prüfung); ein System, das daraus eine Bewertung ableitet, wäre es nicht. Bei Umsetzung von Schritt 2 muss diese Grenze im UI-Text sichtbar bleiben, nicht nur im Datenmodell.

Dritter Konflikt: zwei Schritte greifen bewusst draußen liegende Epics vor

Schrittweiser Ist-Abgleich (verifiziert gegen Code, Stand 2026-08-13)

Schritt (Spec) Ist-Stand im Repo Einordnung
1 Fall anlegen/Scope-Gate Scope-Gate existiert backendseitig vollständig (ScopeGateErgebnis, AuswertungResource.create); UI zeigt es nur als Badge/Chip (AuswertungBadge.tsx:54-66), kein geführter Screen mit vier Prüfzeilen wie im Mockup. Bestätigungsfristen (Gewicht 6 Mon., Schwangerschaft) fehlen technisch (FACH-017-Lücke, implementation-gaps.md). Sofort nutzbar als UI-Zielbild, im Schnitt
2 Intake/Anamnese Nur 2 von 8 Anamnese-Bereichen (OF-28 teilweise offen), kein eigenes UI-Modul. Nutzbar außer der Interaktions-Andeutung (s. o.)
3 Intake-Bereitschaft Kein Code, kein Doku-Begriff. v13 führt FACH-027 als „echte Lücke im Schnitt" mit fast identischer Skizze (read-only Trockenlauf). Abhängig von FACH-003 (Parametertabelle, fehlt komplett). Gutes Zielbild, aber hinter FACH-003
4 Red-Flag-Screening FindingTyp.RED_FLAG_TREFFER ist toter Enum-Wert, kein Screening-Code. v13: „größte Einzellücke in F2", Wirkpfad existiert bereits (E1→R3→Sperre), nur Eingangsseite fehlt. Bestes Aufwand/Wirkungs-Verhältnis — Mockup direkt verwendbar
5 Extraktion prüfen MesswertTable.tsx zeigt Prüfstatus, keine nach Tragweite sortierte Prüfliste. Sortierung nach klinischer Tragweite braucht FACH-031 (vier Stufen, nicht drei — OF-76), aktuell nicht gebaut. Split-View mit Original ohne Dokumenten-Upload (FACH-024/033, bewusst draußen) nicht möglich. Nutzbar erst nach FACH-031
6 Fachliche Auswertung FindingTable.tsx nur E1/E3. Blockiert durch E2-Entscheidung
7 Kritischen Befund bewerten Bereits gut abgedeckt: FindingBadge.tsx, bearbeiteFinding(), eigener Endpoint. Fehlt: strukturierte Differenzialüberlegungen + Dringlichkeitsstufe (OF-31 unbeziffert, FACH-008-Lücke b). Teilweise nutzbar, Dringlichkeit nicht erfindbar
8 Research Kein Code. Epic F5 komplett draußen. Nicht umsetzbar, kein Vorschlag
9 Therapieplan-Entwurf Am besten abgedeckter Schritt: TherapieplanPage.tsx mit vorgeschlagen/gesperrt/zurückgestellt, Dosisstatus, Zufuhrbilanz-Text. Fehlt: strukturierter Einnahmeplan, Interaktionsmatrix (1/10 Katalogeinträge, FACH-073), Patientenpräferenzen (FACH-052, P1). Priorisierungssortierung braucht E2. Größtenteils nutzbar außer Priorisierung
10 Review/Übersteuerung UebersteuerungForm.tsx entspricht dem GM-7.2-Dialog aus dem Mockup fast 1:1 (Regel+Grund vor Bestätigung, Pflicht bei E1). Bereits weitgehend deckungsgleich
11 Gesamtplan-Check/Freigabe Endpunkte vorhanden (fuehreGesamtplanCheckDurch, gibFrei). Trennung blockierend/Hinweis (E-14: 6 vs. 4 Kategorien) nicht umgesetzt — laut implementation-gaps.md blockiert weiterhin alles. Zweitbestes Aufwand/Wirkungs-Verhältnis — Mockup zeigt genau die fehlende Trennung
12 Bericht Nur Therapeutenversion (BerichtVorschauPage.tsx), Patientenversion bewusst draußen. Therapeutenversion-Teil nutzbar, Patientenversion nicht im Schnitt

Was unabhängig vom E2-Ausgang übernehmenswert ist

Die Datenklassifizierung [ST]/[PK]/[PR]/[PK→PR] samt der vier Prüffragen (Spec Z. 807–813) ist eine echte Ergänzung zu guidelines/project/domain-map.md — sie formalisiert, was dort bisher nur implizit steht (Momentaufnahme-Prinzip aus FACH-013, Versionierung aus FACH-119, Rückschreibung FACH-020→018). Unabhängig von jeder Scope-Frage übernehmbar, z. B. als neuer Abschnitt in domain-map.md.

Umsetzungsstand (2026-08-13): Die drei Stufe-A-Punkte sind gebaut und getestet - Red-Flag-Screening (FACH-029, model/RedFlag.java, AuswertungslaufService#erzeugeE1Findings, UI-Komponente RedFlagScreening), Bestätigungsfrist Körpergewicht (FACH-017, AuswertungService#scopeGate) und diese [ST]/[PK]/[PR]-Klassifizierung selbst (siehe domain-map.md). Zwei neue Tests in SicherheitUndScopeGateTest. Als Nebeneffekt wurde die bis dahin unverdrahtete „Sicherheitsebene bearbeiten"-Aktion (FindingTable → onBearbeiten) erstmals an eine Route angeschlossen (AuswertungDetailRoute) - sie existierte im Code, war aber von keiner Seite aus erreichbar.

Nachtrag (2026-08-13): Punkt 5 aus Stufe B (klinische Tragweite, FACH-031/E-5) ist ebenfalls gebaut - aber erst nach einer nachgeholten Scope-Entscheidung: E-5 stand in v12-nachzug-scope.md als Scope-Erweiterung, die eine eigene Product-Owner-Entscheidung braucht („nicht gebaut wird, was v1.2 neu ermöglicht"), nicht als gewöhnliche Lücke wie FACH-029/017. Die Umsetzung wurde einmal begonnen, dann anhand von v12-nachzug-scope.md gestoppt und zurückgesetzt, dem Product Owner vorgelegt und erst nach ausdrücklicher Freigabe erneut gebaut - Nachtrag dazu in v12-nachzug-scope.md Punkt 2. Damit ist Schritt 5 der Spec (Sortierung nach Tragweite) jetzt UI-seitig möglich (MesswertTable, vier Stufen, Sortierung). Weiterhin offen: die Verdrahtung als E-14-Freigabeblocker (Stufe-B-Punkt 6) - das bleibt ein eigener, unentschiedener Punkt.

Vorschlag

Stufe A — sofort umsetzbar, kein Scope-Konflikt, keine fehlende Fachzahl, keine Abhängigkeit:

  1. Schritt 4 Red-Flag-Screening (FACH-029) als UI-Vorlage — Wirkpfad existiert, nur Eingang fehlt. 8-Werte-Katalog liegt vollständig in quelle-01-v1.2.md Z. 764–771 vor.
  2. Schritt 1 Bestätigungsfristen (FACH-017, 6 Monate Gewicht / jedes Mal Schwangerschaft) als kleine Ergänzung am bestehenden Scope-Gate-Badge.
  3. [ST]/[PK]/[PR]-Klassifizierung in domain-map.md übernehmen.

Stufe B — nutzbar, aber an eine fehlende Fachgrundlage gekoppelt (erst wenn diese steht): 4. Schritt 3 Intake-Bereitschaft — hinter FACH-003 (Parametertabelle). 5. Schritt 5 Extraktions-Prüfliste nach Tragweite — hinter FACH-031 (vierstufige Tragweite). 6. Schritt 11 Freigabe-Checkliste (E-14) — Korrektur: entgegen der ursprünglichen Einordnung hier nicht Stufe A. ADR-0004-Nachtrag wörtlich: „E-14 ist ohne E-5 nicht umsetzbar" — eine der sechs blockierenden Kategorien („unsichere Extraktion bei hoher klinischer Tragweite") braucht FACH-031, das es im Code nicht gibt. v13-fachlicher-backlog-epics.md reiht E-14 in Stufe 4 entsprechend nach E-5 ein. Acht der zehn Kategorien sind unabhängig von FACH-031 berechenbar (offener Eskalationshinweis, unbestätigter Red-Flag-Treffer, offener kritischer Wert, Übersteuerung ohne Begründung, nicht bestätigte Basisdaten, fehlende Reevaluation) — eine Teil-Umsetzung ohne die Tragweite-Kategorie ist möglich, aber dann unvollständig gegenüber E-14 und so zu kennzeichnen. 7. Schritt 9 Einnahmeplan/Interaktionsmatrix — hinter FACH-073 (9 fehlende Katalogeinträge).

Stufe C — blockiert durch die offene Stufe-0-Entscheidung E2, nicht vor dem ADR anfassen: 8. Schritt 6 komplett, E2-Anteile aus Schritt 9/10/12.

Stufe D — kein Vorschlag, außerhalb des Gold-Path-Schnitts, eigene Scope-Entscheidung nötig: 9. Schritt 8 (Epic F5), Patientenversion in Schritt 12 (FACH-086), Interaktionsprüfung in Schritt 2 als tatsächliche Regelprüfung (FACH-021/043).

Vor Stufe A trotzdem zu klären: die Provenienz der Spezifikation selbst (s. o.) — nicht, weil sie die UI-Arbeit blockiert, sondern weil jede spätere Fundstellenangabe im Code sonst auf ein ungeklärtes externes Dokument zeigt, genau das Muster, das v13-fachlicher-backlog-epics.md Befund 1 bereits für referenzfaelle/ beschreibt.

Nicht abschließend verifiziert

Die Code-Belege in der Tabelle stammen aus einer gezielten Recherche (Grep + Lesen der genannten Dateien), nicht aus einer vollständigen Testsuiten-Prüfung. Ob Schritt 10 „Ablehnungskategorien" (fachlich vs. Präferenz) im UI bereits als Auswahl existiert, wurde nicht geprüft — nur, dass FACH-078 laut v13-fachlicher-backlog-epics.md als „gut" eingestuft ist.

Zurückgestellt (2026-08-26)

Der Product Owner hat entschieden, die aus dieser Spezifikation abgeleiteten Erweiterungen nicht weiterzuverfolgen: der Fokus liegt auf einem schnell vorführbaren ersten Prototyp auf Basis des bereits gebauten Sechs-Schritt-Gold-Path, nicht auf den hier beschriebenen Scope-Erweiterungen (Schritt 6 mit Ebene E2, Epic-F5-Research in Schritt 8, Patientenversion in Schritt 12, Interaktionsprüfung in Schritt 2).

Zurückgestellt, nicht verworfen — dieselbe Entscheidung wie in v13-fachlicher-backlog-epics.md. Der Ist-Abgleich bleibt vollständig stehen; die Stufe-0-Blockaden (Provenienz der Spec, E2-Entscheidung) bleiben offen statt beantwortet. Die fünf Leitplanken aus CLAUDE.md und die zwei externen Fragen sind unberührt.