adr vertraulich owner: matus

ADR-0011: R-Praxis bekommt einen echten Rückkanal — Vorrangregel nach `E-11`, Momentaufnahme je Fall, Änderungshistorie

ADR-0011: R-Praxis bekommt einen echten Rückkanal — Vorrangregel nach E-11, Momentaufnahme je Fall, Änderungshistorie

Status

Angenommen (2026-08-24) — Nachfolger von ADR-0010, das dadurch in einem Punkt überholt ist (siehe „Was sich gegenüber ADR-0010 ändert").

Kontext

ADR-0010 hat „Kataloge & Regelwerk" als Verwaltungsmechanismus ins Scope genommen und dabei ausdrücklich keinen Rückkanal gebaut. Die Begründung dort, wörtlich:

Vorrangregel R-Praxis vs. R-Global. Nicht spezifiziert, deshalb nicht gebaut.

Diese Begründung war gegen quelle-01.md (v1.1) richtig und ist gegen quelle-01-v1.2.md falsch. E-11 ist in v1.2 entschieden (Z. 61: „Festlegung, welche Regelarten praxisseitig veränderbar sind und welche dauerhaft gesperrt bleiben — ✅ entschieden 08.08."), und FACH-063 trägt seither eine vollständige Tabelle (Z. 1397–1421). Dazu kommen die vier Regeln GM-6.1 bis GM-6.4 (Z. 172–178), die in v1.1 bereits standen, aber ohne den Katalog aus E-11 nicht umsetzbar waren:

• GM-6.1 (Z. 172) — „Eine Regel aus R-Praxis kann eine Regel aus R-Global auf den Ebenen E2 und E3 ergänzen, verändern oder deaktivieren. Sie kann keine Regel der Sicherheitsebene E1 aufheben oder abschwächen."
• GM-6.2 (Z. 174) — „Jede Aussage im Produkt weist aus, ob sie aus R-Global oder R-Praxis stammt."
• GM-6.3 (Z. 176) — R-Praxis wirkt ausschließlich in der Praxis, in der sie hinterlegt wurde.
• GM-6.4 (Z. 178) — beide Ebenen eigenständig versioniert, jede Auswertung führt beide Kennungen mit.

Der gefilterte Testfallkatalog dieses Repos führt die drei zugehörigen Fälle bereits — sie waren bis heute alle status: TODO: TC-GOV-011 (gesperrte Regelart → Ablehnung mit Grund und Verweis auf die Einzelfallübersteuerung), TC-GOV-012 (Reevaluationsintervall nur verkürzbar), TC-GOV-013 (Kaskade bei Deaktivierung einer globalen Regel).

Warum das trotzdem ein ADR braucht und keinen Commit. Die Leitregel aus CLAUDE.md lautet:

Korrigiert wird, was v1.2 widerlegt. Nicht gebaut wird, was v1.2 neu ermöglicht.

Der Rückkanal ist beides. Die Begründung von ADR-0010 ist widerlegt und wird korrigiert; die Funktion ist neu ermöglicht und damit eine Scope-Erweiterung. Der Product Owner hat sie am 2026-08-24 entschieden — mit zwei Zusätzen, die im Material nicht stehen und deshalb hier als Produktentscheidung benannt sind: Änderungshistorie und Nicht-Rückwirkung auch für laufende Fälle.

Was sich gegenüber ADR-0010 ändert

ADR-0010	ADR-0011
„Kein Rückkanal in die Auswertungslogik."	Ein gültiger R-Praxis-Wert wirkt auf neue Auswertungen.
„Vorrangregel … nicht spezifiziert, deshalb nicht gebaut."	Vorrangregel ist GM-6.1 + FACH-063/E-11; sie ist gebaut.
R-Praxis-Einträge wirken auf nichts.	Der Kandidatenfluss aus ADR-0010 wirkt weiterhin auf nichts (siehe unten). Der direkte Regelwert wirkt.

Alles andere aus ADR-0010 bleibt in Kraft: der Lesezugriff auf Regelkatalog.java als einzige Quelle, das fehlende DELETE, die ehrliche Leermeldung bei „Kandidaten aus der Fallarbeit", der Verzicht auf die 29 Mockup-Kataloge.

Entscheidung

1. Vorrangregel

Ein R-Praxis-Regelwert schlägt den R-Global-Wert pro Paar (Regelart, Regelschlüssel) — nicht pro Katalog und nicht pro Praxis. Wo kein R-Praxis-Wert liegt, gilt R-Global unverändert. Der R-Global-Wert wird dabei nie kopiert: er wird bei jeder Anzeige live aus Regelkatalog.java gelesen. Zwei gespeicherte Kopien derselben Zahl wären zwei Wahrheiten, und Regelkatalog.java ist laut CLAUDE.md die eine Stelle.

2. Genau eine Regelart wird veränderbar: Reevaluationsintervalle

FACH-063/E-11 (Z. 1399–1410) unterscheidet fünf veränderbare und sieben gesperrte Regelarten. Von den fünf veränderbaren führt Regelkatalog.java genau eine:

Veränderbar laut E-11	In Regelkatalog.java geführt?
Funktionelle Zielbereiche nach FACH-041	nein — E-9 ist in v1.2 entschieden, der Nachzug ist nicht im Schnitt (v12-nachzug-scope.md)
Präparatepräferenzen und Applikationsformen nach FACH-062	nein — Präparateebene existiert im Prototyp nicht
Dosisstrategie innerhalb der Sicherheitswerte (Einstiegsdosis, Titration, Dauer)	nein — es gibt keine Dosierungsregel, jede Empfehlung ist OHNE_KONKRETE_DOSIS
Eigene Findings und Musterregeln auf Ebene E2	nein — E2 kommt in diesem Repo nirgends vor (Leitplanke 3)
Reevaluationsintervalle nach FACH-074	ja — REEVALUATION_WOCHEN

Also: Reevaluationsintervalle, und nur sie. Mit der Einschränkung, die E-11 selbst mitliefert (Z. 1405 und Z. 1417):

Reevaluationsintervalle sind bewusst nur in eine Richtung veränderbar. Eine Praxis darf enger kontrollieren als das Regelwerk vorsieht, nicht lockerer.

Eine Verlängerung wird abgelehnt und begründet (TC-GOV-012). Ein Element ohne R-Global-Standard kann nicht überschrieben werden — es gibt dort keine Regel, die Vorrang hätte.

3. Die vier übrigen Kataloge bleiben gesperrt — sichtbar, nicht weggelassen

Regelkatalog.java führt fünf Tabellen. Vier davon sind nach E-11 nicht veränderbar, und die Oberfläche zeigt sie trotzdem in derselben Liste — mit Status „gesperrt" und dem jeweiligen Grund. Das ist keine Nettigkeit, sondern die Anforderung aus TC-GOV-011: „Der Versuch, eine gesperrte Regelart zu verändern, wird abgelehnt und begründet. Der Nutzer wird auf die Möglichkeit der Einzelfallübersteuerung nach FACH-083 hingewiesen."

Katalog	E-11-Zeile	Grund
Dosisobergrenzen (OBERGRENZEN)	„Sicherheitswerte der Zufuhr nach FACH-072 — nein" (Z. 1409)	Erzeugungsgrenze nach GM-7; sie begrenzt die Therapie, sie gestaltet sie nicht
Kritische Schwellen (KRITISCHE_SCHWELLEN)	„Kritische Schwellen nach FACH-045 — nein" (Z. 1407)	Ebene E1; GM-6.1 schließt sie namentlich aus
Kontraindikationen (GESPERRTE_ELEMENTE)	„Kontraindikationen nach FACH-044 — nein" (Z. 1406)	Ebene E1; der vorgesehene Weg ist GM-7.2, nicht der Katalog
Sicherheitshinweise (SICHERHEITSHINWEISE)	im E-11-Katalog nicht geführt	Nicht genannt heißt nicht freigegeben. Warnzeichen begrenzen die Therapie (GM-6.1-Trennlinie), und FACH-090 richtet sie an den Patienten

Der Screenshot des Product Owners zeigt genau den Fall, den E-11 verbietet — „Regel bearbeiten: Dosisobergrenze Vitamin D, 4000 I.E./Tag". 4000 I.E. sind 100 µg und damit exakt der Sicherheitswert aus FACH-072 Z. 1585. Das ist keine Kleinigkeit und deshalb steht es hier: Das Mockup ist an dieser Stelle nicht umsetzbar, ohne GM-6.1 zu brechen. Umgesetzt ist stattdessen der Zustand, den das Material vorsieht — die Regel ist sichtbar, ihr Originalwert ist sichtbar, die Sperre ist sichtbar, und der Verweis auf FACH-083 steht daneben.

Die Trennlinie in einem Satz, wörtlich aus Z. 1416: „veränderbar ist, was die Therapie gestaltet; gesperrt ist, was sie begrenzt."

4. Nicht rückwirkend — als Mechanismus, nicht als Zusage

Beim Anlegen einer Auswertung werden die zu diesem Zeitpunkt gültigen R-Praxis-Regelwerte als Momentaufnahme in den Fall geschrieben (auswertung_regelbindung). Jeder spätere Auswertungslauf liest ausschließlich diese Momentaufnahme, nie den aktuellen Katalog. Das ist dasselbe Muster wie bei den klinischen Basisdaten (FACH-013, Z. 443: „Eine spätere Änderung der Patientendaten verändert eine bereits freigegebene Auswertung nicht") — hier auf das Regelwerk angewandt.

Dadurch stimmt der Satz aus der Oberfläche wörtlich: eine Regeländerung wirkt auf neue Auswertungen. Ein laufender Fall behält seinen Stand auch dann, wenn er nach der Änderung noch zehnmal neu ausgewertet wird — und ein freigegebener Fall ist ohnehin unveränderlich (FACH-080).

Das ist strenger als das Material. OF-54 fragt ausdrücklich: „Was geschieht mit einer LAUFENDEN, noch nicht freigegebenen Auswertung, deren Regelversion während der Bearbeitung deaktiviert wird? Das Material regelt nur die Rückwirkungsfreiheit für bereits freigegebene Fälle." Der Product Owner hat diese Frage am 2026-08-24 in die strengere Richtung entschieden: auch laufende Fälle bleiben unberührt. Das ist eine Produktentscheidung ohne Beleg, und sie steht deshalb hier und nicht bloß im Code. OF-54 ist damit für dieses Repo beantwortet, im Material weiterhin offen.

Zusätzlich trägt jede Auswertung ihre R-Praxis-Versionskennung als Zähler der bis dahin erfolgten Regeländerungen (GM-6.4, TC-GOV-001). Damit ist die Rückwärtssuche aus TC-GOV-006 („welche Auswertungen liefen unter dieser Regelversion") beantwortbar, ohne dass die Werte doppelt gespeichert wären.

5. Änderungshistorie, append-only

Jede Aktion an einem Regelwert — angelegt, geändert, auf Original zurückgesetzt — erzeugt genau einen Historieneintrag mit Altwert, Neuwert, Pflichtbegründung, Akteur und Zeitstempel. Nichts wird überschrieben und nichts gelöscht; dieselbe Disziplin wie beim fehlenden DELETE aus ADR-0010.

Der Originalwert aus R-Global wird in der Historie nicht dupliziert. Wo ein Historieneintrag ihn zeigt, ist er beim Schreiben aus Regelkatalog.java formatiert worden und als „(R-Global)" gekennzeichnet — er ist Text im Protokoll, keine zweite Katalogquelle. Die aktuelle Ansicht liest den Originalwert immer live.

„Auf Original zurücksetzen" ist damit kein Löschen, sondern eine dokumentierte Handlung mit Pflichtbegründung. Das beantwortet zugleich das letzte offene Akzeptanzkriterium von FACH-063 (Z. 1422): „Es ist festgelegt, ob und wie eine Praxis den Bestand ihrer eigenen Regeln einsehen und zurücksetzen kann."

6. Herkunft ist an der Empfehlung sichtbar (GM-6.2)

Empfehlung.herkunftsebene stand bisher fest auf R_GLOBAL. Ist an einer Empfehlung mindestens eine R-Praxis-Regel wirksam geworden, steht sie auf R_PRAXIS, und die betroffene Angabe benennt den Ursprung im Klartext („… Wochen bis zur Reevaluation — R-Praxis, verkürzt von … Wochen").

Die strenge Lesart ist Absicht: GM-6.2 verlangt, dass „eine praxiseigene Regel nie als allgemeingültige fachliche Grundlage dargestellt" wird. Eine Empfehlung, deren Kontrollintervall aus der Praxis stammt, ist nicht mehr vollständig R-Global — auch wenn ihr fachlicher Kern es ist.

7. Eine eigene Capability, NUR_MENSCHEN

txm.regelwerk.regel.aendern (Setzen und Zurücksetzen), allowedActors=[USER].

Sie ist nicht dieselbe wie txm.regelwerk.rpraxis.write aus ADR-0010, und der Unterschied ist genau der Gegenstand dieses ADR: der Kandidatenfluss ist wirkungslos, der Regelwert ist wirksam. Zwei verschieden folgenreiche Handlungen hinter einem Schlüssel wären eine Freischaltung, die mehr erlaubt, als sie verspricht.

NUR_MENSCHEN folgt derselben Erwägung wie txm.demo.cleanup und txm.regelwerk.rpraxis.freigeben — nicht aus GM-7-Zwang, sondern aus Tragweite. Bei ADR-0010 war das noch die schwächere Variante des Arguments („ein Katalog, der später Empfehlungen beeinflussen könnte"). Hier ist das „später" eingetreten.

GM-7 selbst bleibt unberührt

Die drei Capabilities der GM-7-Kette sind nicht angefasst. Eine Katalogänderung ist keine Therapieentscheidung — das Material trennt beides ausdrücklich (Z. 199):

Eine Regel aus R-Praxis kann eine Sicherheitsregel nicht dauerhaft abschalten. Eine Einzelfallentscheidung des Therapeuten kann sie im konkreten Fall übersteuern. Der Unterschied liegt zwischen stehender Regel und dokumentierter Einzelentscheidung.

Genau diese Trennung ist der Grund, warum die Kontraindikationen hier gesperrt bleiben, obwohl sie über GM-7.2 pro Fall übersteuerbar sind. Ein Katalog-Override wäre die dauerhafte Abschaltung — der Weg, den GM-6.1 verbietet und für den GM-7.2 die Alternative ist.

Was ausdrücklich draußen bleibt

• Alles außer Reevaluationsintervallen. Siehe die beiden Tabellen oben. Nicht „noch nicht", sondern in vier von fünf Fällen nicht ohne einen weiteren Katalog (FACH-041, FACH-062, Dosierungsregeln, E2) und in vier weiteren Fällen von E-11 verboten.
• Kaskade bei Deaktivierung einer globalen Regel (TC-GOV-013, Z. 1419: darauf aufbauende R-Praxis-Regeln werden ausgesetzt und erneut vorgelegt). Braucht FACH-120 — den Korrekturprozess mit Sofort-Deaktivierung, den dieses Repo nicht hat (Regelkatalog.java-Klassenjavadoc: „Er ist nicht versioniert steuerbar"). Ohne deaktivierbare globale Regel gibt es nichts, was kaskadieren könnte.
• Konfliktanzeige R-Global ↔ R-Praxis. Z. 1420 lautet „Es ist festgelegt, wie ein Konflikt … dem Nutzer angezeigt wird" — das ist eine Anforderung, kein Ergebnis. E-11 hat den Katalog geliefert, nicht die Anzeige. Gebaut ist die Gegenüberstellung „Original / eigener Wert" auf der Detailseite; das ist eine Darstellung, keine Konfliktauflösung.
• Kandidaten aus der Fallarbeit. Unverändert nicht angebunden (ADR-0010): GM-7.4 nennt das Konzept, die Ableitungsregel fehlt. Der Rückkanal ändert daran nichts — er beginnt beim gesetzten Regelwert, nicht bei der Übersteuerung.
• Vier-Augen-Prinzip für Regelwerte. Der Kandidatenfluss aus ADR-0010 verlangt eine zweite Person, der direkte Regelwert nicht. Das ist eine bewusste Ungleichheit und keine Nachlässigkeit: der Freigabeschritt in ADR-0010 war eine Erfindung dieses Repos (FACH-119/FACH-120 existieren nicht), und eine erfundene Regel wird nicht auf einen zweiten Mechanismus ausgedehnt. Nachvollziehbarkeit läuft hier über die Historie und die Pflichtbegründung — beides belegt (GM-6.2, FACH-061: „Je Regel sind Anlass, fachliche Begründung … und verantwortliche Person dokumentiert").
• Evidenzgrad I-1 bis I-3 je Regel. FACH-061 verlangt ihn. Welcher Grad wann gilt, sagt das Material nicht — er würde geraten. Die Pflichtbegründung tritt an seine Stelle.
• Kontrollparameter je Intervall. FACH-074 (Z. 1653–1660) nennt sie je Intervention („Zink und Kupfer, CRP"). Regelkatalog.java führt nur die Wochen und die eine Begleitkontrolle aus FACH-073. Die Spalte nachzuziehen wäre eine eigene Scope-Erweiterung.

Bewusst offen gelassen

• Die R-Praxis-Version ist ein Änderungszähler, keine SemVer-Zahl — dieselbe Vereinfachung wie in ADR-0010, jetzt aber monoton und pro Auswertung eingefroren.
• Kein Wiederherstellen eines früheren Werts aus der Historie. Die Historie ist ein Protokoll, keine Zeitmaschine. Wer einen alten Wert zurück will, setzt ihn neu — mit eigener Begründung.
• Die Vorschau auf der Detailseite ist ein Zahlenvergleich, kein simulierter Fall. Sie sagt, um wie viele Wochen früher die Praxis kontrolliert und wie viele bereits angelegte Fälle die Änderung nicht mehr erreicht. Sie behauptet keinen Beispielpatienten. Eine Vorschau „wie hätte sich Referenzfall X verhalten" wäre TC-GOV-009 — und die ist durch OF-41/E-18 blockiert: die 13 Referenzfälle sind benannt, aber ohne Eingangs- und Erwartungswerte.

Konsequenzen

• + GM-6.1 bis GM-6.4 sind erstmals im Code und nicht nur im Domänenmodell. TC-GOV-011 und TC-GOV-012 sind ausführbar; TC-GOV-001/TC-GOV-002 bekommen mit der Momentaufnahme einen echten Mechanismus statt einer Zusicherung.
• + Die Oberfläche zeigt zum ersten Mal, warum eine Regel nicht änderbar ist. Das ist fachlich der wertvollere Teil dieses Screens: die Trennlinie „gestaltet / begrenzt" wird sichtbar, statt dass gesperrte Kataloge einfach fehlen.
• − Der Screen kann weniger, als das Mockup zeigt. Wer nur die zwei Screenshots kennt, hält die gesperrte Dosisobergrenze für einen unfertigen Stand. Sie ist das Gegenteil.
• − Genau eine änderbare Regelart ist wenig Ertrag für einen ganzen Mechanismus (Entity, Historie, Momentaufnahme, Detailseite). Der Mechanismus ist bewusst regelartgenerisch gebaut: die vier weiteren Regelarten aus E-11 brauchen jeweils nur ihren Katalog, nicht diese Maschinerie noch einmal.
• − Regelkatalog.java bleibt die einzige Quelle für R-Global, ist aber jetzt nicht mehr die einzige Quelle für den wirksamen Wert. Wer eine Zahl im Bericht sucht, muss zwei Stellen ansehen — deshalb ist GM-6.2 (Herkunft an jeder Aussage) hier keine Kosmetik.

Nachtrag: globaler Änderungsverlauf entfallen (2026-08-26)

Abschnitt 5 (Änderungshistorie) bleibt inhaltlich vollständig gültig — jede Aktion an einem Regelwert erzeugt weiterhin genau einen Historieneintrag. Geändert hat sich nur, WO diese Historie sichtbar ist: die eigene Seite „Änderungsverlauf des Regelwerks" (RegelAenderungsverlaufPage, Route :tenantKey/kataloge-regelwerk/aenderungen, verlinkt über einen Header-Button auf Screen 09) ist ersatzlos entfallen.

Warum. Der Product Owner verstand den Button nicht ("Änderungsverlauf verstehe ich nicht - löschen"). Bei genauerem Hinsehen ist die globale Liste auch redundant: RegelDetailPage zeigt seit Abschnitt 5 dieselbe Historie bereits je Regel (Abschnitt „Änderungshistorie" dort), und genau das ist die Reihenfolge, in der sie gebraucht wird — man kommt über eine konkrete Regel dorthin, nicht über eine globale, nach Zeitpunkt sortierte Liste aller Regeln zugleich. Eine zweite, globale Ansicht derselben Daten beantwortete keine Frage, die die erste nicht schon beantwortet, kostete aber einen eigenen Menüpunkt.

Konsequenz für den Katalog-Screen: Klick auf eine Tabellenzeile öffnet jetzt für jede Regel (änderbar oder gesperrt) direkt RegelDetailPage — dort stehen Originalwert, bei änderbaren Regeln das Formular zum Ändern, und die Änderungshistorie dieser einen Regel an einer Stelle. Der frühere Tabellenlink „Original ansehen"/„bearbeiten" ist entfallen (redundant zum Zeilenklick).

GET /regelkatalog/aenderungen (Backend) ist unverändert vorhanden — es hat nur keinen Konsumenten mehr im Frontend. Kein Rückbau des Endpunkts, nur der UI-Anbindung.

• ADR-0010 — Vorgänger; dessen Abschnitt „Kein Rückkanal in die Auswertungslogik" ist durch dieses ADR abgelöst
• ADR-0004 — GM-7.2 als der andere, fallbezogene Abweichungsweg
• quelle-01-v1.2.md — GM-6 (Z. 166–178), FACH-061–FACH-063 inkl. E-11-Tabelle (Z. 1362–1422), FACH-074 (Z. 1640–1660)
• tuxamed Bearbeitet/testfaelle/08-regelwerk-governance.md (gefilterte Fassung: documentation/testfaelle-gold-path.md) — TC-GOV-001, TC-GOV-002, TC-GOV-006, TC-GOV-011, TC-GOV-012, TC-GOV-013
• agentic-engineering/backlog/v12-nachzug-scope.md — der Rahmen, in dem v1.2-Nachzüge entschieden werden