Brainversum · tuxametrics Graph Admin

konzept vertraulich owner: matus

Implementation Gaps

Implementation Gaps

Key: PG-ARCH-0002 · Domain: Projekt · siehe ../INDEX.md

Was bewusst nicht implementiert ist. Getrennt vom Backlog: der Backlog führt Aufgaben, dieses Dokument führt Erwartungen, die jemand beim Lesen des Codes haben könnte und die nicht erfüllt sind.

Der fachliche Nicht-Umfang steht in gold-path-scope.md. Hier steht, was innerhalb des Schnitts anders oder gar nicht gebaut wurde.

Fachliche Lücken

Lücke Was fehlt Warum jetzt so
Keine Dosierungsregel Jede erzeugte Empfehlung trägt dosisstatus = ohne-konkrete-dosis. elementareTagesdosis bleibt null, bis ein Therapeut sie setzt. Das Material enthält Obergrenzen, Reevaluationsintervalle und Kontrollparameter — aber keine einzige Dosierungsregel. FACH-067 sieht den Zustand „Empfehlung ohne konkrete Dosis" ausdrücklich als zulässig vor. Eine erfundene Dosis wäre die gefährlichste Zahl in diesem Repo.
Anamnesekern nur zweifeldrig Von den acht Bereichen aus FACH-020 sind nur anamneseDialyse und anamneseOnkologischeSystemtherapie abgebildet — genau die zwei, die das Scope-Gate braucht. Der Werteraum der acht Bereiche ist nicht festgelegt (OF-28): „Kilian definiert, welche Angaben für P0 fachlich zwingend sind" ist ein Auftrag, kein Ergebnis. Mehrfachauswahl? Freitext daneben? Kategoriengrenzen bei Alkohol? Unbekannt.
Kein Labordokument als eigenes Objekt labor, befunddatum und untersuchungsmaterial liegen als Feldgruppe an der Auswertung; Messwerte hängen direkt am Fall. Mehrere Dokumente je Auswertung sind laut Material möglich (Z. 643), im Gold Path aber nicht gebraucht. Die Konfliktregel aus FACH-036 (gleicher Analyt + Matrix + Datum) ist damit nicht implementiert — sie braucht mehrere Dokumente, um überhaupt auslösen zu können.
evidenzsaeule fehlt als eigenes Feld Es gibt quellenklasse (Q1–Q7) und evidenzgrad, aber kein Säulen-Feld, obwohl FACH-065 es als Pflichtangabe führt. Die Namen der drei Säulen nach GM-5 stehen nicht in der extrahierten Ergebniszone. Sie zu erfinden wäre eine Fachaussage; die Zuordnung Quellenklasse → Säule existiert laut Material, ist aber nicht aufgezählt.
Keine Patientenpräferenzen TEILWEISE GEBAUT 2026-08-17 (FACH-052) Applikationsform (als Ablehnung), vegan/vegetarisch, maximale Präparate-/Einnahmezeitpunktzahl, Kostenrahmen (Freitext), abgelehnte Substanzen, Hilfsstoff-Unverträglichkeiten, Allergien (Freitext, direkt am Patienten) sind erfasst und in der Patientenakte anzeig-/bearbeitbar (PatientEntity, PatientPraeferenzCard). Product-Owner-Entscheidung 2026-08-17 (AskUserQuestion): reine Anzeige/Erfassung, ohne Priorisierungslogik — die maximale Präparatezahl ist zwar laut Quelle Eingangsgröße der Priorisierung nach FACH-051, die ohne Ebene E2 nicht existiert. Diese Verdrahtung bleibt Lücke. Allergien vereinfacht: Freitext direkt am Patienten statt über den vollen Anamnesekern-Promotionspfad aus FACH-020.
Keine Zurückstellung in der Praxis Der Zustand ZURUECKGESTELLT existiert im Modell, wird aber von keiner Regel gesetzt. Zurückstellung folgt aus Behandlungspriorität (FACH-051) — nicht im Schnitt (Patientenpräferenz FACH-052 ist seit 2026-08-17 teilweise gebaut, s. o., aber ohne die Priorisierung, die den Zustand setzen würde). Der Zustand bleibt, weil ihn der Bericht als Pflichtinhalt kennt.
Keine Versionskette nach Freigabe vorgaengerAuswertungKey existiert als Feld, aber es gibt keinen Endpunkt, der eine Korrekturversion erzeugt. FACH-080 verlangt sie („neue Version mit Bezug auf die vorherige"). Der Fall tritt erst auf, wenn ein freigegebener Fall korrigiert wird — im Backlog, nicht im Gold Path. Bis dahin lehnt der Service Änderungen mit 409 und einem Verweis darauf ab.
Reevaluationen erzeugen keine falluebergreifende Fälligkeitenliste reevaluationszeitpunkt steht an der Empfehlung und im Bericht. Seit 2026-08-17 gibt es zusätzlich EmpfehlungRepository#naechsteReevaluation — den frühesten offenen Reevaluationszeitpunkt je Patient, in der Patientenübersicht als Spalte „Kontrolle" und Kachel „Fällige Kontrollen" sichtbar. Das ist ausdrücklich keine falluebergreifende, nach Dringlichkeit sortierte Aufgabenliste über alle Patienten einer Praxis. FACH-081/FACH-091 fordern Sichtbarkeit fälliger Kontrollen außerhalb eines Falls; welche Form diese Praxis-weite Liste hat, ist weiterhin unbelegt (OF-47) — Product-Owner-Entscheidung 2026-08-17, die minimale patientenbezogene Ableitung zu bauen, aber keine neue Aufgaben-Infrastruktur. Das Material nennt die Reevaluationstreue „der wahrscheinlichste stille Schaden dieses Produkts" — die Praxis-weite Lücke bleibt deshalb keine Kleinigkeit. Siehe auch agentic-engineering/backlog/faellige-kontrollen-panel.md, das denselben Punkt für die „Letzte Fälle"/Auswertungsübersicht diskutiert — dort mit einem anderen, noch offenen Mechanismus (Besuchs-/Blutabnahme-Ereignis statt Retest-Intervall je Analyt).
Keine Frist für Eskalationshinweise Kein Timer, keine Eskalationsstufe. Es gibt im ganzen Material keine Zielzeit (OF-46), obwohl FACH-102 die Zeit bis zur Bearbeitung misst und sie „die einzige Kennzahl, bei der Verzögerung unmittelbar Patientenrisiko bedeutet" nennt. Eine erfundene Frist wäre schlimmer als keine.
Wertkorrektur löst keine Kaskade aus Nur Änderungen an Einheit, Analyt oder Matrix setzen Findings und Empfehlungen zurück. Der Wortlaut von FACH-032 nennt genau diese drei. Dass eine reine Wertkorrektur Findings ebenso verändert, ist offensichtlich und trotzdem nicht belegt (OF-30). Der Service folgt dem Wortlaut, statt die Frage still zu entscheiden.
Scope-Gate bricht nicht ab Es sammelt alle Ausschlussgründe, statt nach dem ersten zu stoppen. OF-55 fragt genau das. Gewählt wurde die sammelnde Variante, weil eine abbrechende dem Nutzer beim zweiten Anlauf einen neuen Grund präsentieren würde, den es schon beim ersten gab.

Belegbar seit Backlog v1.2 — und trotzdem nicht gebaut

Diese Lücken sind neu in dieser Liste (2026-08-09). Bis v1.1 waren es keine Lücken, sondern offene Fragen: das Material legte die Werte schlicht nicht fest. Die Kundenfassung quelle-01-v1.2.md hat sie entschieden — der Einbau ist trotzdem unterblieben, weil er den Gold-Path-Schnitt erweitern würde. Leitregel: korrigiert wird, was v1.2 widerlegt; nicht gebaut wird, was v1.2 neu ermöglicht. Begründung je Punkt: ../../agentic-engineering/backlog/v12-nachzug-scope.md.

Lücke Was fehlt Warum jetzt so
Freigabepunkte blockieren weiterhin alle Die 6 blockierenden / 4 nicht blockierenden Kategorien aus E-14 sind nicht abgebildet; auch die Anzeigeregel „getrennte Blöcke" nicht. Was vorher galt: bewusst implausibler Platzhalter A6, weil OF-04b offen war. Seit v1.2 entschieden (FACH-079 Z. 1741–1757) — A6 ist damit kein Platzhalter mehr, sondern eine bewusst aufgeschobene Änderung, siehe den Nachtrag in ADR-0004. Der Punkt mit dem besten Aufwand-Wirkungs-Verhältnis: R1-Empfehlungen würden die Freigabe nicht mehr aufhalten. Nicht allein umsetzbar — die Kategorie „unsichere Extraktion bei hoher Tragweite" braucht die Zeile darunter.
Keine klinische Tragweite je Analyt ERLEDIGT 2026-08-13 FACH-031 ist nicht abgebildet Regelkatalog.klinischeTragweite(analyt), vier Stufen (KlinischeTragweite), automatische Pflichtprüfung in AuswertungService#pruefstatus ab mittlerer Erkennungsunsicherheit bei HOCH/HOCH_WEGEN_HEBELWIRKUNG. Scope-Erweiterung vom Product Owner freigegeben, v12-nachzug-scope.md Punkt 2. Weiterhin nicht abgebildet: die Verdrahtung als Freigabeblocker (E-14, Punkt 1 desselben Dokuments) — eigener, noch offener Punkt trotz erfüllter Vorbedingung. Was vorher galt: OF-05 offen, Platzhalter A4 („alle hoch"). Seit v1.2 entschieden: vier Stufen (FACH-031 Z. 851–863), darunter die eigenständige Stufe „Hoch wegen Hebelwirkung" (CRP, Albumin). Der Werteraum steht in v1.2 zweimal verschieden im Dokument — drei Stufen im Widget „Prüfliste Extraktion" (Z. 1000), vier in FACH-031. Die vierstufige ist die richtige (OF-76), so umgesetzt.
Aktualitätsgrenze wird gar nicht geprüft Kein Vergleich von befunddatum gegen eine Grenze; kein Wegfall der Therapieableitung auf E3 Stufe 4. Was vorher galt: OF-08 offen, im Material nur ein Vorschlag „6 Monate pauschal", Platzhalter A2 („1 Tag"). Seit v1.2 entschieden und analytdifferenziert: 3 / 6 / 12 Monate in drei Gruppen (FACH-024 Z. 682–694). Der pauschale Vorschlag ist damit überholt. Jenseits der Grenze bleibt der Befund für Darstellung und Verlaufsvergleich nutzbar — es ist eine Kappung, kein Ausschluss.
Kein eGFR-Modifikator FACH-007 ist ohne ihn gebaut (so schreibt es §9 vor); Risikoklasse und Dosisobergrenze reagieren nicht auf die Nierenfunktion. Was vorher galt: OF-06 offen, Platzhalter A3 (< 999 ml/min/1,73 m²). Seit v1.2 entschieden: fünf Stufen (FACH-007 Z. 333–348), getrennt für Magnesium und Kalium und übrige Nährstoffe. Greift in zwei Dinge gleichzeitig ein. Dazu gehören zwingend die Stufenkappung GM-1.1 bei fehlender eGFR und die 3-Monats-Grenze der eGFR selbst. Eine Zahl fehlt weiterhin: Stufe 45–59 ist nur qualitativ („reduziert", „verkürzt") — OF-75.
Keine kontextabhängige Verschärfung kritischer Schwellen Kalium bleibt bei > 6,0 mmol/l kritisch, unabhängig von der eGFR; für Calcium unter Vitamin-D-Therapie gibt es keine Sonderprüfung. Auch die Vorrangregel „strengere Grenze gewinnt" fehlt. Neu in v1.2 (FACH-045 Z. 1151–1160): Kalium ist bereits ab 5,5 mmol/l kritisch, wenn die eGFR < 45 liegt. Braucht die eGFR zum Prüfzeitpunkt und hängt damit an der Zeile darüber. Die Calcium-Verschärfung ist nicht quantifiziert — „oberer Normbereich" ist keine Schwelle (OF-69). Die Vorrangregel setzt laborseitige Alarmwerte im Datenmodell voraus, die es nicht gibt.
Eisen-Sonderregel nicht abgebildet Der Katalogeintrag steht als SicherheitswertArt.KEIN_WERT, aber ohne die daran gebundene Steuerung: keine Zielwertbindung, keine Dauerbegrenzung, keine Sperre bei Transferrinsättigung > 45 %. Neu in v1.2 (FACH-072 Z. 1601–1610). Was vorher dastand: „keine allgemein anerkannte Obergrenze" — eine Leerstelle. Hier fehlt nicht der Scope, sondern die Zahl: OF-67. v1.2 sagt dass es Zielwerte für Ferritin und Transferrinsättigung und eine harte Dauergrenze gibt, nicht welche. Erfunden wird nichts. Der Eintrag sagt deshalb „geprüft, kein Wert ableitbar" — ausdrücklich nicht „unbedenklich" (Z. 1576).
Kontraindikation Vitamin D bei eGFR < 30 fehlt Der Kontraindikationsmechanismus kennt nur den absoluten Fall (Hämochromatose). Neu in v1.2 (FACH-044 Z. 1122), relativ: eingeschränkte renale Hydroxylierung, Hyperkalzämierisiko mit Calcium. v1.2 führt sie ausdrücklich hier und nicht über den eGFR-Modifikator, „weil sie nicht die Dosis begrenzt, sondern die Substanzwahl betrifft" — die Trennung ist Teil der Aussage. Nach GM-7 ein Hinweis mit Pflichtbestätigung, keine Sperre.
Evidenzklasse X-3 ist nicht in X-3a/X-3b geteilt Das Evidenzschema führt weiterhin 8 statt 9 Klassen. Neu in v1.2 (FACH-057 Z. 1320–1328, E-10): X-3a (Leitlinien, offizielle Referenzwerte) trägt alle Ebenen uneingeschränkt, X-3b (Beobachtungsstudien) E3 Stufe 4 nur mit Kennzeichnung und Pflichtprüfung. Es ist die Aufteilung eines bestehenden Enum-Werts und damit eine Migrationsfrage: was mit bereits als X-3 gekennzeichneten Findings, Empfehlungen und freigegebenen Berichten geschieht, sagt v1.2 nicht (OF-73). Eine Umstellung im Code würde diese Frage still beantworten.

Zahlenlücken, die v1.2 offengelassen hat

Hier steht null und eine offene Frage — auch nach v1.2. Geschätzt wird nichts.

ID Was fehlt Stand
OF-10 Nationale Höchstmengenempfehlungen Der Mechanismus ist seit v1.2 belegt: zweistufiger Referenzrahmen — der europäische Sicherheitswert (UL) ist die Erzeugungsgrenze, die nationale Höchstmenge die Warnschwelle; ihre Überschreitung hebt auf R2 und verlangt eine dokumentierte Begründung (FACH-072 Z. 1571–1573). Die Spalte ist im Material selbst leer und ausdrücklich „nicht zu schätzen" (Z. 1599). Platzhalter A5 bleibt, jetzt anders begründet. Das ist die Lücke, die in den nutzersichtbaren Texten an die Stelle des überholten „UNBESTAETIGT (E-8)" getreten ist.
OF-67 Eisen-Zielwerte (Ferritin, Transferrinsättigung) und die Dauergrenze Ohne Zielwert endet die Empfehlung nie; ohne Dauergrenze ist die „nicht erzeugbare unbefristete Eisengabe" nicht prüfbar.
OF-69 Calcium-Verschärfung unter Vitamin-D-Therapie „Kontrollpflicht bereits im oberen Normbereich" — anders als die Kalium-Verschärfung (5,5 mmol/l) ohne Zahl.
OF-75 eGFR-Stufe 45–59 „Obergrenze reduziert, verkürztes Kontrollintervall" — um wie viel, sagt v1.2 nicht. Die übrigen vier Stufen tragen eine eindeutige Wirkung.
OF-01 Auffälligkeitsbereiche je Verhältnis Unverändert offen (E-7). Platzhalter A1 bleibt. Keine Lücke, sondern die zentrale Scope-Entscheidung — siehe unten.

Technische Lücken

Lücke Was fehlt Warum jetzt so
Keine Capability-Registrierung ERLEDIGT 2026-08-10 Kein CapabilityRegistrar. Alle 18 Schlüssel (17 Schreib-Capabilities plus txm.auswertung.read) werden beim Start bei tuxametrics-platform-service angemeldet. CapabilityRegistrarTest bindet die registrierte Menge maschinell an die tatsächlichen require(...)-Aufrufe — beide Driftrichtungen brechen jetzt den Build. (Die Zahl war bis 2026-08-10 an vier Stellen „14"; sie stimmt jetzt und kann nicht mehr auseinanderlaufen.) Die Authority steht: ADR-0005.
Ein Service-Account für drei Services (2026-08-14: von vier auf drei verkleinert) tuxametrics-services wird von laborauswertung, virtual-identity und dem betriebenen zwirn-testmanagement-service genutzt. Alle drei teilen sich damit actorKey und Grants — ein Recht, das einer braucht, hat der andere mit. Bewusste DEV-Vereinfachung, dieselbe wie in dkfz-prozesswerkstatt. Für echten Betrieb nach Zwirn-ADR-0039 (dedizierte Service-Actors je Tenant) aufzuteilen. Der erste Schritt ist gemacht: zwirn-autoimprove-service hat seit ADR-0007 einen eigenen Client (tuxametrics-autoimprove-service) — dieselbe Wahl wie in DOT (ADR-0071). Kosten pro weiterem Service: eine Zeile in seedBootstrapGrant() und ein Testfall. Benannt in keycloak/README.md.
IdentityStatusGuard nicht verdrahtet Eine über _deactivate deaktivierte Identity — auch eine agentische — verliert ihre CapabilityGrants nicht automatisch. Sie bleiben bis zum Entzug wirksam. Die generische Kopplung (IdentityStatusGuard/IdentityStatusClient aus zwirn-security-java-core, Zwirn-ADR-0008) ist strikt opt-in mit NoopIdentityStatusClient als Default und ist heute in keinem Zwirn-Produkt verdrahtet. Das ist so vorgesehen und kein Mangel des Kerns — für dieses Produkt aber eine echte Lücke, weil ein Kill-Switch, der nichts abschaltet, keiner ist.
VID ist gebaut, aber unbenutzt — und der identityKey ist NICHT der actorKey tuxametrics-virtual-identity-service erzeugt beim Anlegen einer Person einen opaken Business-Key (praxis01-vid-idn-{nanoid8}). Der user_key im Keycloak-Token, gegen den jeder Grant und jedes created_by läuft, ist davon völlig unabhängig — kein Code, kein Constraint und kein Abgleich verbindet die beiden. Am 2026-08-13 stand in vid_identity auf der Runtime-VM null Zeilen: das Register existiert, kennt aber niemanden. Das ist kein Versehen dieses Repos, sondern der Stand aller drei Geschwisterprodukte. In dot ist die Gleichsetzung JWT user_key == VID identityKey als Konvention dokumentiert (dot-ADR-0019) und in keiner Zeile Code erzwungen — entsprechend tragen dort mehrere Konten von Hand getippte Pseudo-NanoIds (fin4nc01, test1 mit 5 statt 8 Zeichen), die der Generator gar nicht erzeugen kann. In evepop wurde ein Konto Monate ohne VID-Datensatz betrieben. Wer die Kopplung will, braucht eine Vermittlungsschicht, die es in keinem der Produkte gibt: VID ist Capability-Konsument und darf per GG-ARCH-SERVICES-0005 gar keine Grants vergeben, Keycloak-User-Provisioning gibt es nur für Agents/Service-Clients (dot-ADR-0021). Bis dahin ist der user_key das, was er ist: ein Pseudonym, das ein Mensch vergibt — jetzt wenigstens per Zufallsgenerator statt per Fantasie.
Keycloak tenant_key als feste Liste Der Protocol-Mapper auf tuxametrics-services schreibt ["platform","praxis01"] hartcodiert. Jede neue Praxis braucht eine Keycloak-Konfigurationsänderung. Prototyping-Vereinfachung. Für echten Mehrmandantenbetrieb durch einen dynamischen Mapper (User-Attribut oder Custom-SPI) zu ersetzen. Bei menschlichen Nutzern ist es bereits gelöst: dort kommt tenant_key aus einem Benutzerattribut.
Keine DB-Migrationen hibernate-orm.database.generation=update. Kein Flyway/Liquibase. DEV-Phase, noch kein Betrieb. Muss vor dem ersten echten Einsatz ersetzt werden — update löscht nichts und benennt nichts um, jede Spaltenänderung würde still danebenlaufen.
Kein Löschen, nirgends Weder Patient noch Auswertung noch Sicherheitsmerkmal haben einen DELETE-Endpunkt. Bei den Sicherheitsmerkmalen verlangt das Material das ausdrücklich („nicht ohne dokumentierte Entscheidung", FACH-018). Bei der Auswertung tritt Archivierung mit dokumentiertem Grund an die Stelle (FACH-016). Beim Patienten ist es schlicht noch nicht gebraucht worden — und bei Gesundheitsdaten ist „noch nicht gebaut" die bessere Ausgangslage als „schnell hingebaut".
gesamtplanCheckTreffer als Textspalte Die benannte Liste wird zeilengetrennt in eine Spalte geschrieben und beim Lesen gesplittet. Eine @ElementCollection wäre sauberer, aber eine zusätzliche Tabelle für ein Feld, das nur gelesen und ganz ersetzt wird. Wenn Treffer je einzeln adressierbar werden müssen (z. B. „abgehakt"), ist das der Zeitpunkt zum Umbau.
docker compose build / Vollstart nicht ausgeführt Der Compose-Stack ist geschrieben — seit 2026-08-10 mit Keycloak, Authority und VID, also 15 Container statt 10 — aber nicht gelaufen. Bei der Erstanlage fehlten .env und OPA-Bundle. Am 2026-08-10 kam ein zweiter Grund dazu: auf der Maschine liefen 59 Container dreier anderer Produkte, die ~10 GB des 15-GB-Docker-Budgets hielten. Ein Kaltstart wäre nicht aussagekräftig gewesen. Verifikationslücke, keine bekannte Fehlfunktion — vor dem ersten Einsatz zu schließen.
„Service startet" nur im @QuarkusTest belegt Kein Start gegen den echten Keycloak. Bis 2026-08-09: kein IdP entschieden. Seit 2026-08-10 gibt es einen, aber der Vollstart oben ist nicht gelaufen — die Aussage bleibt damit unverändert offen, nur aus einem anderen Grund.
Nativer Bau belegt, nativer START nicht Alle drei Quarkus-Module bauen nativ (Probeläufe 2026-08-10, drei grüne Binaries). Gestartet wurde keines davon. „Baut nativ" und „läuft nativ" sind zwei Aussagen: native-image verschiebt Fehlerklassen gern von der Bau- in die Startzeit (eine fehlende Reflection-Registrierung schlägt erst beim ersten Request zu). Siehe native-image-tooling.md.
user_key-Pseudonymisierung ist Konvention, keine Regel Nichts hindert daran, einen Klarnamen als user_key zu vergeben. Gefunden am 2026-08-12 im laufenden Stack: ein Konto trug den Klarnamen der Person im user_key (korrigiert auf praxis01-user-admin01, bevor ein Fachdatensatz existierte). Geprüft wird der Wert seitdem von scripts/keycloak-user-key-setzen.py — das ist ein Skript, keine Durchsetzung: wer den Nutzer in der Keycloak-Konsole anlegt, umgeht sie. Zwirn hat dazu keine Regel — die Lücke liegt eine Ebene höher. GG-GOV-GDPR-0002 (zwirn/guidelines/architecture/service/data-lifecycle.md, „User Keys und Pseudonymisierung") begründet die DSGVO-Konformität des Löschkonzepts mit dem Satz „Der Key selbst ist nicht personenbezogen"; dass er es sein muss, steht nirgends. zwirn/guidelines/architecture/service/java/java-audit.md und db-architecture.md führen sogar user:matus als kanonisches Beispiel. Warum das hier mehr wiegt als anderswo: der Actor-Key landet über AuditableEntity.createdBy (updatable = false) an jedem Patienten- und Auswertungsdatensatz und über den Audit-Stream in zwirn-audit-service — ein Klarname wäre dort nicht mehr korrigierbar, in einem Datenmodell, das beim Patienten ohne Klarnamen auskommt und ihn seit 2026-08-24 nur optional führt (FACH-011; Pflicht bleibt das Pseudonym interneReferenz) — der Actor-Key hat diese Wahl nicht. Vorschlag an Zwirn: eigene Regel GG-GOV-GDPR-0001.6 in global-dsgvo-uuid-hiding.md.
62 von 63 Testfällen ohne Mock-Szenario Der Testfallkatalog (tuxametrics-ui, Nav-Sektion „Testfälle") zeigt alle 63 Fälle, aber nur TC-AUS-013 hat einen „Ausführen"-Button — die übrigen zeigen ehrlich „Kein Mock-Szenario hinterlegt". tuxametrics hat genau einen ausgearbeiteten synthetischen Referenzfall (ReferenzfallService). Weitere Mock-Szenarien sind fachlicher Aufwand (neue init-bundle-Datensätze je Fall), kein Verdrahtungsproblem. Siehe testmanagement-integration.md.

Was hier bewusst NICHT als Lücke geführt wird