konzept vertraulich owner: matus

Autoimprove-Kandidaten aus dem Fachlücken-Review 2026-08-15

Autoimprove-Kandidaten aus dem Fachlücken-Review 2026-08-15

Status: Vorlage · Adressat: der nächste Lauf, der daraus Karten anlegt · nicht selbst angelegt

Diese Liste ist das Zwischenergebnis eines vollständigen Abgleichs zwischen dem Fachmaterial (tuxamed Bearbeitet/, Stand quelle-01-v1.2.md) und diesem Repository am 2026-08-15. Sie enthält keine Karten — sie ist die Vorlage dafür.

Was hier NICHT hineingehört und deshalb fehlt: alles, was bereits als eigener Backlog-Eintrag geführt wird. Diese Datei dupliziert v12-nachzug-scope.md, testabdeckung-gold-path.md und ../../guidelines/project/implementation-gaps.md nicht, sondern verweist darauf und ergänzt, was beim Review neu aufgefallen ist.

---

Feldwerte, die der Service tatsächlich kennt

Geprüft in C:\dev\zwirn\feedback\autoimprove-service am 2026-08-15 — nicht geraten:

Feld	Gültige Werte	Anmerkung
type	BUG · IDEA · TASK	CardType.VALID_PATTERN. Nicht „bug/idee/aufgabe" — das sind Anzeigelabels, keine API-Werte. Ohne type entsteht ein TASK (CardType.DEFAULT)
testObjectType	TESTCASE · CUSTOM	TESTCASE ist eine lose Referenz auf den Testfallkatalog des konsumierenden Produkts — genau richtig für ein TC-*. testObjectKey = die Fallnummer, testObjectLabel = der Titel-Snapshot
moduleKey / moduleLabel	aus GET /modules	Nicht rein deskriptiv: ein gesetzter moduleKey aktiviert das Modul-Scope-Gating beim Claimen

⚠ Der Typ hat bewusst keinen Einfluss auf den Status-Automaten. BUG, IDEA und TASK durchlaufen dieselbe claim-basierte Pipeline; der Typ ist reine Klassifikation für Anzeige und Filterung. Eine „Priorität" gibt es im Modell nicht — die Angaben unten sind Einschätzungen für den Menschen, kein Feld.

⚠ Der Modul-Katalog stand am 2026-08-15 auf null Zeilen. Eine parallele Session hat scripts/autoimprove-modul-katalog.sql vorbereitet (9 Einträge, noch nicht angewandt). Die moduleLabel-Vorschläge unten benennen die dortigen Namen; wer die Karten anlegt, sollte den Katalog vorher prüfen und moduleKey nicht raten.

---

Block A — die 22 zurückgestellten Testfälle, gruppiert nach Scope-Punkt

Nicht 22 Karten. Die Fälle hängen paarweise oder in Fünfergruppen an einer Entscheidung; eine Karte je Testfall würde 22-mal dieselbe Diskussion auslösen. Vorschlag: 10 Karten, je mit den zugehörigen TC-* als testObjectKey bzw. im Beschreibungstext.

Vollständige Begründung je Punkt: v12-nachzug-scope.md. Die Testfall-Zuordnung und was genau im Code fehlt: ../../documentation/testfaelle-gold-path.md, Abschnitt „Zurückgestellt".

A1 — E-14 umsetzen: sechs blockierende, vier nicht blockierende Freigabepunkte

• Analyse: TherapieplanService#freigabeblocker lässt heute alle Punkte blockieren — der bewusst implausible Platzhalter A6. FACH-079 Z. 1741–1757 legt die Kategorisierung seit v1.2 fest. Der praktische Ertrag ist der größte im gesamten Nachzug: R1-Empfehlungen halten die Freigabe nicht mehr auf, heute muss jede der sechs Empfehlungen des Referenzfalls entschieden werden. Dazu gehört die Anzeigeregel „getrennte Blöcke, nicht eine gemischte Liste mit Symbolen" (Z. 1760) und die Begründung, die man nicht wegoptimieren darf: „Eine Blockade, die häufig ohne erkennbaren Nutzen auslöst, wird zur Gewohnheit — und mit ihr die seltene Blockade, auf die es ankommt."
• Typ: TASK · Modul: tuxametrics-laborauswertung-service (+ tuxametrics-ui für die Anzeige) · Testfälle: TC-REV-013, TC-REV-014, TC-REV-016, TC-REV-017
• Einschätzung: höchste Priorität des ganzen Blocks (bestes Aufwand-Wirkungs-Verhältnis laut v12-nachzug-scope.md Punkt 1). Aufwand mittel. Achtung: eine der sechs blockierenden Kategorien (unsichere Extraktion bei hoher Tragweite) ist A2 — die kann getrennt oder gemeinsam.

A2 — E-5 fertig verdrahten: klinische Tragweite als Freigabeblocker

• Analyse: Die Vorbedingung ist seit 2026-08-13 erfüllt — KlinischeTragweite (vier Stufen) ist gebaut, vom Product Owner freigegeben und löst die automatische Pflichtprüfung in AuswertungService#pruefstatus aus. Nicht gebaut ist die Wirkung auf das Freigabe-Gateway: eine unsichere Extraktion blockiert die Freigabe nur bei „Hoch"/„Hoch wegen Hebelwirkung", sonst ist sie Hinweis. v12-nachzug-scope.md Punkt 2 nennt das ausdrücklich als eigenen, noch offenen Punkt trotz erfüllter Vorbedingung.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfall: TC-REV-015
• Einschätzung: klein, aber abhängig von A1 — ohne die Kategorisierung gibt es keine Stufe „nur Hinweis", in die etwas fallen könnte.

A3 — E-3 bauen: analytdifferenzierte Aktualitätsgrenzen 3/6/12 Monate

• Analyse: Der Prototyp prüft die Aktualität eines Befunds heute gar nicht — befunddatum wird gespeichert und im Bericht ausgegeben, aber gegen nichts verglichen. FACH-024 Z. 682–694 entscheidet drei Gruppen. Wichtig für die Umsetzung: es ist eine Kappung, kein Ausschluss — der Befund bleibt darstellbar und verlaufsvergleichbar, nur die Therapieableitung auf E3 Stufe 4 entfällt. Vitamin D steht bewusst in der kurzen Gruppe („ein Sommerwert trägt keine Wintertherapie").
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-INT-014, TC-INT-015
• Einschätzung: mittel. Braucht einen neuen Messwert-Zustand („nicht mehr therapieleitend") und eine Gruppe im Regelkatalog. Vorbedingung für A4 (die eGFR unterliegt selbst der 3-Monats-Frist).

A4 — E-2 bauen: eGFR-Modifikator, fünf Stufen

• Analyse: §9 nimmt FACH-007 ausdrücklich „ohne eGFR-Modifikator" in den Schnitt auf; AuswertungService sagt das im Javadoc. v1.2 hat die Schwellen entschieden (FACH-007 Z. 333–348). Der Modifikator greift in zwei Dinge gleichzeitig ein — Risikoklasse und Dosisobergrenze — und betrifft ausgerechnet Magnesium und Kalium. Drei Dinge hängen zwingend mit dran: Stufenkappung GM-1.1 bei fehlender eGFR, die 3-Monats-Frist der eGFR selbst (A3), und Vitamin D wird ausdrücklich NICHT hierüber gesteuert (eigener Kontraindikationseintrag, A8).
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-SCP-004, TC-THE-016
• Einschätzung: groß, und eine Zahl fehlt weiterhin: Stufe 45–59 ist nur qualitativ beschrieben („Obergrenze reduziert, verkürztes Kontrollintervall") — OF-75. Wer baut, muss entscheiden, was mit dieser Stufe geschieht, ohne sie zu erfinden.

A5 — E-8-Zusätze: kontextabhängige Verschärfung und Laborvorrang

• Analyse: Zwei Regeln aus FACH-045 Z. 1151–1160, beide nicht gebaut. Kalium ist bereits ab 5,5 mmol/l kritisch, wenn die eGFR < 45 liegt — hängt an A4. Die Vorrangregel („wo ein Labor eigene Alarmwerte ausweist, hat die strengere Grenze Vorrang") setzt laborseitige Alarmwerte im Datenmodell voraus, die es nicht gibt. Die Calcium-Verschärfung ist nicht quantifiziert (OF-69) — „oberer Normbereich" ist keine Schwelle.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-AUS-015, TC-AUS-016
• Einschätzung: teilweise blockiert. Der Kalium-Teil ist nach A4 machbar, der Calcium-Teil nicht (Kategorie „Zahl fehlt"), der Laborvorrang braucht ein Datenmodell-Feld.

A6 — E-9 bauen: funktionelle Zielbereiche für fünf Analyte

• Analyse: Im Code existiert davon nichts — die Volltextsuche nach „Zielbereich" findet genau einen Javadoc-Kommentar. FACH-041 Z. 1055–1070 führt sie für 25-OH-Vitamin D, Ferritin, Zink, Selen und Vitamin B12/Holotranscobalamin, je mit vier Bedingungen (benannte Quelle mit Quellenklasse und Evidenzgrad · matrixbezogen · immer gemeinsam mit dem Laborreferenzbereich · Abweichung sichtbar und begründet). Die Gegenprobe ist die eigentliche Aussage: ohne freigegebenen Zielbereich gibt es für einen normwertigen Befund überhaupt keine Bewertung „suboptimal".
• Typ: TASK · Modul: tuxametrics-laborauswertung-service + tuxametrics-ui · Testfälle: TC-AUS-018, TC-AUS-019
• Einschätzung: groß — neues Katalogkonzept mit Quellenpflicht, plus Anzeige.

A7 — E-12 Eisen-Sonderregel — blockiert, nicht vergessen

• Analyse: Hier fehlt nicht der Scope, sondern die Zahl (OF-67). FACH-072 Z. 1601–1610 steuert Eisen über Indikation, Zielwert und Dauer statt über eine Dosisobergrenze — aber v1.2 sagt, dass es Zielwerte für Ferritin und Transferrinsättigung und eine harte Dauergrenze gibt, nicht welche. Ohne Zielwert endet die Empfehlung nie. Der Katalogeintrag KEIN_WERT steht deshalb bewusst ohne die Sonderregel im Code. Ein Teil ist trotzdem baubar: die Sperre bei Transferrinsättigung > 45 % ist beziffert (Z. 1607).
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-THE-013, TC-THE-014
• Einschätzung: Die Karte sollte zuerst eine Frage an den klinischen Fachexperten sein, keine Umsetzung. Der TSAT-Teil (TC-THE-014) ist davon unabhängig und klein.

A8 — Vitamin D bei eGFR < 30 als relative Kontraindikation

• Analyse: Neu in v1.2 (FACH-044 Z. 1122). Der Kontraindikationsmechanismus im Repo kennt bisher nur den absoluten Fall (Hämochromatose). v1.2 führt diese Regel 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 und beim Bauen nicht einzuebnen. Nach GM-7 ein Hinweis mit Pflichtbestätigung, keine Sperre.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfall: (keiner im Quellkatalog)
• Einschätzung: klein, aber abhängig von A4 (braucht die eGFR im Modell).

A9 — E-11 / R-Praxis: die zweite Regelwerksebene

• Analyse: R-Praxis existiert nicht. v1.2 liefert erstmals den Katalog aus 7 gesperrten und 5 veränderbaren Regelarten (FACH-063 Z. 1399–1419), mit der Trennlinie „veränderbar ist, was die Therapie gestaltet; gesperrt ist, was sie begrenzt". Dazu die einzige teilweise veränderbare Regelart im ganzen Katalog: Reevaluationsintervalle dürfen praxisseitig nur verkürzt, nie verlängert werden. Und die Kaskade: wird eine globale Regel deaktiviert, werden darauf aufbauende praxiseigene Regeln ausgesetzt und der Praxis erneut vorgelegt.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-GOV-011, TC-GOV-012, TC-GOV-013
• Einschätzung: groß und weitreichend — eine zweite Regelwerksebene ist keine Ergänzung, sondern ein Architekturschritt. Hängt zusätzlich am Korrekturprozess (FACH-120), der ebenfalls nicht im Schnitt ist.

A10 — E-17 Patientenversion: zweiter Freigabeablauf

• Analyse: Die Streichung bleibt richtig, aber die Begründung hat gewechselt. Bis v1.1 war sie mit Unklarheit aus dem Schnitt genommen (OF-20, „höchstes Missverständnisrisiko"). v1.2 sagt: sie ist im Pilot enthalten — aber sie entsteht nicht automatisch, sondern erfordert eine gesonderte Freigabe nach geprüfter Vergleichsansicht, mit getrennt dokumentiertem Zeitpunkt und Person. „Sie kostet einen Klick und erzwingt einen Blick." Das ist ein zweiter Freigabeablauf, nicht ein zweites Rendering. OF-39 wirkt fort: ohne Zuordnungsmechanismus zwischen den Versionen ist „geprüft" nicht operationalisierbar.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service + tuxametrics-ui · Testfälle: TC-BER-010, TC-BER-011
• Einschätzung: groß, und teilweise blockiert durch OF-39.

---

Block B — Testabdeckung: Fälle, deren Regel nur „im Kopf" existiert

Grundlage: testabdeckung-gold-path.md, Abschnitt „Priorität" — am 2026-08-15 neu gemessen. Zwei der fünf ursprünglichen Punkte sind inzwischen erledigt.

B1 — TC-EXT-013: die Korrekturkaskade ist implementiert, aber nicht geprüft

• Analyse: Eine Korrektur von Einheit, Analyt oder Matrix setzt Verhältnisse, Findings und Empfehlungen zurück und entwertet getroffene Therapeutenentscheidungen (FACH-032 Z. 814–815). Es ist die einzige explizite Kaskadenregel des gesamten Materials und der Grund, warum die Entscheidungshistorie ein gueltig-Flag trägt. Kein Test benennt sie.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfall: TC-EXT-013
• Einschätzung: Platz 1 der Testlücken, klein.

B2 — TC-INT-003: die Momentaufnahme ist implementiert, aber nicht geprüft

• Analyse: „Eine spätere Änderung der Patientendaten verändert eine bereits freigegebene Auswertung nicht" (FACH-013 Z. 443). Die basis*-Spalten liegen deshalb an der Auswertung. Kein Test schreibt den Patienten nach der Freigabe um und prüft die Auswertung nach.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfall: TC-INT-003
• Einschätzung: klein.

B3 — TC-EXT-008 / TC-EXT-009: toxisch gegen essenziell unter der Bestimmungsgrenze

• Analyse: Gegensätzliche Bedeutung derselben Datenlage — beim toxischen Element erwartet und günstig, beim essenziellen Nährstoff prüfbedürftig. Die Regel ist genau eine if-Abfrage weit von einem Fehler entfernt, und die Analytgruppe, an der sie hängt, ist selbst eine Ableitung (OF-29, im Parameterkatalog gar nicht vorgesehen).
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-EXT-008, TC-EXT-009
• Einschätzung: klein, hoher Sicherheitswert.

B4 — TC-THE-006 von „teilweise" auf „vollständig" heben

• Analyse: RegelkatalogV12Test prüft die Kupfer-Begleitkontrolle auf Katalogebene (Zuordnung Zink → Kupfer, Auslöseschwelle unterhalb der Erzeugungsgrenze, Standardintervall > 8 Wochen). Was kein Test prüft: dass die erzeugte Empfehlung den Kontrollparameter „Zink UND Kupfer, CRP" tatsächlich trägt (FACH-074 Z. 1657). Dasselbe gilt für TC-THE-007 — der Wertzustand KEIN_WERT ist geprüft, seine Ausweisung im Bericht nicht.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfälle: TC-THE-006, TC-THE-007
• Einschätzung: klein.

Erledigt und deshalb nicht mehr in dieser Liste: TC-AUS-009 (kritischer Kaliumwert ohne Hämolysehinweis) hat seit dem ReferenzfallKaliumpaarTest einen eigenen Test. FACH-090 (Warnzeichen je Wirkstoff) war der prominenteste Befund der alten Liste — „im gesamten gefilterten Katalog ungeprüft", weil sein einziger Fall an der Patientenversion hing. v1.2 hat den Katalog freigegeben, TC-BER-012 ist aufgenommen, der Regelkatalog führt 8 Wirkstoffe und RegelkatalogV12Test prüft den Vitamin-B6-Eintrag. Verbleibende Restlücke: dass der Bericht die beiden Spalten getrennt ausgibt, prüft kein Test (siehe B5).

B5 — Berichtsausgabe der Warnzeichen prüfen

• Analyse: BerichtService gibt je vorgeschlagenem Wirkstoff zwei getrennte Zeilen aus („erwartbar und harmlos" / „Warnzeichen mit Rücksprache") und schreibt bei leerer Spalte ausdrücklich „im Katalog nicht befüllt" statt „keine" (OF-38). Genau diese Trennung ist die fachliche Anforderung aus FACH-090 Z. 1907 — und kein Test benennt sie.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service · Testfall: TC-BER-012
• Einschätzung: klein.

---

Block C — beim Review NEU gefunden

Diese Punkte stehen in keinem bestehenden Backlog-Dokument dieses Repos.

C1 — Der Testfall-Reiter des Prozess-Cockpits bleibt leer, obwohl bpmnPath jetzt gesetzt ist

• Analyse: Seit 2026-08-15 tragen 57 der 67 Fälle ein bpmnPath und den processDefinitionKey tuxametrics-auswertung (live auf der VM, 86 Pfadelemente). Sichtbar wird davon trotzdem nichts: tuxametrics-ui/src/App.tsx reicht createProcessHubRoutes(...) kein testCases-Array — mit der ausdrücklichen und weiterhin richtigen Begründung, dass der Katalog per REST kommt und nicht doppelt gehalten werden soll. Die ursprüngliche Diagnose „es fehlt nur bpmnPath" war also unvollständig; es sind zwei Dinge. Der naheliegendere Ort ist ohnehin src/domains/testfaelle/components/GoldPathDiagramm.tsx: die Komponente lädt das BPMN bereits und verzichtet nur deshalb auf testCaseCounts/activityPath, weil „der migrierte Katalog für keinen der 63 Fälle ein bpmnPath trägt". Diese Begründung ist jetzt überholt — der Kommentar dort ist faktisch falsch geworden.
• Typ: TASK · Modul: tuxametrics-ui
• Einschätzung: klein und sofort sichtbar. Das ist der Punkt, der die ursprüngliche Nutzerbeobachtung („ich sehe da keine Testfälle") vollständig schließt.

C2 — svc-tuxametrics-services hat catalog.write, aber nicht catalog.read

• Analyse: Nachgemessen am 2026-08-15 in platform_capability_grant auf der Runtime-VM: der Service-Account hält zwirn-testmanagement.catalog.write, nicht …catalog.read. Jeder GET auf den Katalog antwortet mit 403 no_grant. scripts/migrate-testfaelle.mjs prüfte bis dahin per GET auf Existenz — hätte daraus „existiert nicht" geschlossen und wäre beim POST an 409 gescheitert. Umgangen, nicht behoben: das Skript arbeitet jetzt POST-dann-PUT und kommt ohne Lesezugriff aus (Nebeneffekt: es ist damit aktualisierend statt nur idempotent). Ob der fehlende Grant Absicht ist, konnte nicht geklärt werden — er wäre über scripts/erste-grants.py zu ergänzen, nicht per SQL an der Authority vorbei.
• Typ: BUG (asymmetrischer Grant-Satz) · Modul: tuxametrics-platform-service
• Einschätzung: klein. Zuerst klären, dann ändern — eine Rechteänderung an geteilter Infrastruktur.

C3 — Reevaluationsintervalle: sechs im Code, „sieben" im Material

• Analyse: Der Quell-Testfallkatalog spricht bei TC-THE-012 von „den sieben Standardintervallen aus FACH-074"; Regelkatalog.REEVALUATION_WOCHEN führt sechs (Vitamin D, Eisen, Zink, Vitamin B12, Magnesium, Selen). Ob der siebte Eintrag ein Nährstoff außerhalb des Gold-Path-Schnitts ist oder beim Nachziehen verloren ging, ist nicht geprüft. Das ist kein Beleg für einen Fehler — aber auch keiner für Vollständigkeit, und ein fehlendes Standardintervall würde still zu einer Empfehlung ohne Reevaluationszeitpunkt führen, die es laut FACH-074 nicht geben darf.
• Typ: BUG (Verdacht, zu verifizieren) · Modul: tuxametrics-laborauswertung-service
• Einschätzung: klein — es ist ein Nachschlagen in quelle-01-v1.2.md Z. 1651–1660.

C4 — Praeanalytik.infektgeschehen14Tage wird geschrieben und nie gelesen

• Analyse: Das Feld ist eine der fünf Pflichtangaben aus FACH-028 Z. 685, existiert im Modell, in der Entity und im Converter — und wird von keiner Regel ausgewertet. Die Konfundierungskennzeichnung nach GM-1.3 hängt allein am CRP. Das ist die zweite Hälfte der E-4-Entscheidung: die erste (akuter Infekt ist kein Red Flag mehr) ist korrekt umgesetzt, RedFlag führt 8 statt 9 Einträge mit begründendem Javadoc. Ein erfasstes, nie gelesenes Sicherheitsfeld ist unangenehmer als ein fehlendes, weil es Vollständigkeit suggeriert.
• Typ: BUG · Modul: tuxametrics-laborauswertung-service · Testfall: TC-INT-013
• Einschätzung: klein bis mittel. Klärungsbedarf: welche Analyte ein Infektgeschehen konfundiert — das Material sagt es nicht direkt, FACH-046 nennt nur den Akutphaseneffekt.

C5 — Zählangaben in testabdeckung-gold-path.md waren veraltet

• Analyse: Dort stand „21 vollständig, 8 teilweise, 34 ohne" — nachgezählt ergab dieselbe Tabelle in testfaelle-gold-path.md schon 28 / 8 / 27, nach dem v1.2-Nachzug 30 / 12 / 25. Die Prosa war einmal richtig und ist beim Nachziehen der Tabelle nicht mitgewandert. Am 2026-08-15 korrigiert und gegen scripts/testfaelle-katalog.json gemessen statt gezählt. Strukturell offen: es gibt keinen Mechanismus, der die drei Stellen (Markdown-Tabelle, Prosa, JSON) auseinanderlaufen lässt auffallen — ein kleiner Konsistenztest wäre möglich.
• Typ: IDEA · Modul: (kein Code-Modul — Dokumentation/CI)
• Einschätzung: klein.

C6 — Zehn Testfälle ohne bpmnPath, davon einer als Ermessensfrage

• Analyse: Die Zuordnungsregel (FACH-Bereich in der documentation des BPMN-Elements, oder ein im Modell benannter Zweig) lässt 10 Fälle ohne Pfad. Neun davon sind sachlich zwingend — FACH-011, FACH-017, FACH-018, FACH-119 und die reinen GM-*-Fälle erscheinen in keiner Element-Dokumentation. Einer ist eine Ermessensentscheidung: TC-REV-001 (FACH-075, „der Therapeut sieht, was das System bewusst nicht vorgeschlagen hat") grenzt an „FACH-076 bis 078" von Task_review, liegt aber außerhalb. Es ist einer der vier unbequemen Elemente aus ADR-0004 und damit ausgerechnet der Fall, dessen Sichtbarkeit am meisten zählt.
• Typ: IDEA · Modul: tuxametrics-process-hub-cockpit (BPMN-Dokumentation) oder zwirn-testmanagement-service (Zuordnung)
• Einschätzung: klein. Zwei saubere Wege: die documentation von Task_review auf „FACH-075 bis 078" erweitern (Änderung am fachlichen Modell, PO-Frage), oder es bewusst leer lassen.

C7 — 64 von 67 Testfällen ohne Mock-Szenario

• Analyse: implementation-gaps.md führt noch „62 von 63" — beide Zahlen sind überholt. Eine parallele Session hat am 2026-08-15 zwei weitere Referenzfall-Bundles ergänzt (praxis01-referenzfall-04/05.json, ReferenzfallSzenario, MOCK_SZENARIEN bildet jetzt drei Testfälle ab); mit den vier Neuzugängen im Katalog steht es damit bei 64 von 67 ohne „Ausführen"-Button. Das ist fachlicher Aufwand (neue init-bundle-Datensätze je Fall), kein Verdrahtungsproblem — und für die 13 Referenzfall-Konstellationen teilweise unmöglich, solange E-18 offen ist: sie sind benannt, aber ohne Eingangs- und Erwartungswerte (OF-41). Konstellation 12 ist dauerhaft nicht abdeckbar — sie ist eine E2-Konstellation.
• Nebenbefund derselben Session, hier nur notiert: implementation-gaps.md trägt die Zahl „62 von 63" weiterhin; sie sollte beim nächsten Durchgang gegen den Katalog gemessen werden, statt fortgeschrieben zu werden — dieselbe Klasse Fehler wie C5.
• Typ: TASK · Modul: tuxametrics-laborauswertung-service + tuxametrics-ui
• Einschätzung: groß, inkrementell abarbeitbar.

C8 — 15 FACH-Items im Schnitt ohne eigenen Testfall

• Analyse: Ein Befund am Quellmaterial, nicht an diesem Repo: FACH-087, 088, 091 (alle Epic F8) sowie FACH-006, 009, 010, 012, 014, 027, 042, 047, 066, 071, 076, 115 haben im Katalog keinen Fall. Die Liste ist gegenüber v1.1 um drei kürzer geworden: FACH-090 (durch TC-BER-012), FACH-024 und FACH-041 (durch TC-INT-014/015 bzw. TC-AUS-018/019) — Letztere haben allerdings nur die Kategorie gewechselt, von „Lücke im Material" zu „zurückgestellt in diesem Repo".
• Typ: IDEA · Modul: (kein Code-Modul — Termin mit dem klinischen Fachexperten)
• Einschätzung: kein Umsetzungsaufwand, sondern ein Tagesordnungspunkt.

C9 — OF-71: die Querbezugsregel hängt an keinem Prozessschritt

• Analyse: FACH-045 Z. 1165 legt fest, dass kritische Schwellen, Sicherheitswerte der Zufuhr und Interaktionsschwellen gemeinsam und aufeinander abgestimmt festgelegt sind — wird eine der drei Tabellen geändert, sind die beiden anderen auf Widerspruchsfreiheit zu prüfen. Genau dieser Abgleich hat OF-11 aufgedeckt (Zink 25 mg gegen 40 mg). Wo im Freigabeprozess das geschieht, ist offen. TC-THE-017 formuliert die Invariante als Testfall, ist aber zurückgestellt, weil Regelkatalog.BEGLEITKONTROLLE keine Auslöseschwelle speichert — es gäbe nichts zu prüfen.
• Typ: IDEA · Modul: tuxametrics-laborauswertung-service
• Einschätzung: klein, sobald der Katalog die Schwelle mitführt. Bis dahin eine Governance-Frage.

C10 — OF-74: „länger als 8 Wochen" trifft genau den Regelfall

• Analyse: Die Auslösebedingung der Kupfer-Begleitkontrolle lautet „ab 25 mg täglich oder länger als 8 Wochen". Das Standardintervall für Zink aus FACH-074 lautet „8 bis 12 Wochen". Ist eine geplante Gabe von genau acht Wochen erfasst oder erst ab Woche neun? Die Frage trifft damit nicht den Rand, sondern den Normalfall — und in diesem Prototyp trägt der Dauerzweig die Regel allein, weil der Dosiszweig mangels konkreter Dosen nie auswertbar ist.
• Typ: IDEA (Frage an den Fachexperten) · Modul: tuxametrics-laborauswertung-service
• Einschätzung: klein, aber sicherheitsrelevant.

C11 — OF-38 ist durch v1.2 größer geworden

• Analyse: Die Spalte „erwartbar und harmlos" ist bei vier von acht Wirkstoffen leer (Selen, Vitamin D, Jod — und neu Vitamin B6). Ob das „keine" oder „noch nicht befüllt" heißt, ist auch durch die Freigabe des Katalogs (E-16) nicht entschieden. Im Code steht deshalb null und nicht ein leerer String, und der Bericht schreibt „nicht befüllt". Bemerkenswert, weil die Katalogfreigabe eine offene Frage üblicherweise schließt — hier hat sie sie vergrößert.
• Typ: IDEA (Frage an den Fachexperten) · Modul: (kein Code-Modul)
• Einschätzung: kein Umsetzungsaufwand.

C12 — Zwirns Testmanagement-README beschreibt tuxametrics veraltet

• Analyse: C:\dev\zwirn\test\testmanagement-service\README.md sagt unter „Ehrlich zum Stand bei tuxametrics": „kein dort migrierter Testfall trägt aktuell ein bpmnPath". Das stimmt seit 2026-08-15 nicht mehr (57 von 67). Das ist ein fremdes Repo — hier nur als Hinweis, damit die Aussage nicht als Beleg zitiert wird. Änderung wäre ein Zwirn-Commit, keine tuxametrics-Karte.
• Typ: IDEA · Modul: (Zwirn, außerhalb dieses Produkts)
• Einschätzung: trivial, aber nicht in diesem Repo zu erledigen.

---

Vorschlag für den nächsten Lauf

1. Modul-Katalog prüfen (GET /api/autoimprove/v1/tenants/praxis01/modules) — er stand am 2026-08-15 auf null Zeilen; scripts/autoimprove-modul-katalog.sql liegt vorbereitet, aber unangewandt. Ohne Katalog keine moduleKey-Zuordnung, und geraten wird keine.
2. Reihenfolge: C1 zuerst (schließt die Nutzerbeobachtung), dann Block B (klein, hoher Sicherheitswert), dann A1/A2 (bestes Aufwand-Wirkungs-Verhältnis im Fachbereich).
3. testObjectType: TESTCASE konsequent setzen, wo oben ein TC-* steht — damit ist die Karte im Board an den Katalog gebunden, statt die Nummer nur im Text zu tragen.
4. A7, C10 und C11 sind Fragen, keine Aufgaben. Sie als solche anlegen (oder gebündelt als einen Tagesordnungspunkt für den nächsten Termin mit dem klinischen Fachexperten, zusammen mit C8) — eine Umsetzungskarte auf eine unbeantwortbare Frage blockiert nur das Board.