adr vertraulich owner: matus

Architecture Decision Records — tuxametrics

Eigene ADR-Kette dieses Produkts, ab 0001. Nie rückwirkend gelöscht, nur „Superseded" markiert.

Löst eine Entscheidung hier eine globale Regel aus (etwas, das ohne Kenntnis der Fachdomäne dieses Produkts Sinn ergäbe): ein Zwirn-ADR mit Herkunft: tuxametrics ADR-NNNN schreiben (siehe ../../../zwirn/GOVERNANCE.md) und von hier aus zurückverlinken.

Seit 2026-08-17 ist das einmal passiert, und der Satz, der hier bis dahin stand („bisher ist das nicht passiert"), ist damit überholt: ADR-0008 hat Zwirn-ADR-0043 ausgelöst (Capability-Profile im zwirn-platform-service, PROFILE wird kein ActorType). Beides war generisch — es ergibt ohne jede Kenntnis der orthomolekularen Medizin Sinn — und wurde deshalb zuerst in Zwirn gebaut und erst danach hier nachgezogen. Das ist die vorgesehene Reihenfolge, nicht die Ausnahme. GG-META-0002/-0005 sind davon unberührt: dieses Produkt benutzt sie weiterhin und ändert sie nicht.

Template

# ADR-NNNN: {Titel}

## Status
{Vorgeschlagen | Angenommen | Abgelehnt | Superseded durch ADR-XXXX} ({Datum})

## Kontext
{Warum musste entschieden werden}

## Entscheidung
{Was wurde entschieden}

## Konsequenzen
{Was folgt daraus, auch Trade-offs}

Bisherige Entscheidungen

ADR	Titel	Status
0001	Provenienz und Scope — Gold Path E1/E3, E2 bewusst ausgeschlossen	Angenommen (2026-08-09)
0002	Der regulatorische Status ist UNGEKLÄRT — externe Klärung ausstehend	Angenommen (2026-08-09)
0003	Der Pilot-Betriebsmodus ist UNGEKLÄRT	Angenommen (2026-08-09)
0004	Die vier „unbequemen" Elemente sind Zustände im Datenmodell; GM-7 verbietet die harte Sperre	Angenommen (2026-08-09)
0005	Eigene Capability-Authority (`tuxametrics-platform-service`), Keycloak-Realm `digital-labs`, eigene Virtual Identity mit agentischen Identitäten	Angenommen (2026-08-10)
0006	Feedback-Triage als eigenes Prozessmodul (`tuxametrics-feedback-process`) — und ausdrücklich nicht „Autoimprove"	~~Angenommen (2026-08-13)~~ Abgelöst durch 0007 (2026-08-14)
0007	tuxametrics betreibt `zwirn-autoimprove-service` — und nur ihn. `zwirn-feedback-service` außer Betrieb, das Prozessmodul aus 0006 entfernt, erster `AGENT`-Actor des Produkts	Angenommen (2026-08-14)
0008	Zwei Capability-Profile (`platform-owner`, `product-owner`) für den zweiten menschlichen Actor; `PROFILE` wird kein `ActorType`; GM-7 bekommt eine fünfte Verteidigungslinie (nie über ein Profil grantbar)	Angenommen (2026-08-17)
0009	Echtes Keycloak-Client-Provisioning für agentische Identitäten (`AgentDefinition`/`AgentToken`, `KeycloakAdminClient`) — Quarkus-Port von dot-ADR-0021, verschlankt um Kill Switch/Session-TTL/e2e-Realm	Angenommen (2026-08-17)
0010	„Kataloge & Regelwerk" (R-Praxis-Governance) als Scope-Erweiterung — Verwaltungsmechanismus statt Fachzahl, kein Rückkanal in die Auswertungslogik	Angenommen (2026-08-24), Abschnitt „kein Rückkanal" abgelöst durch 0011
0011	R-Praxis bekommt einen echten Rückkanal: Vorrangregel nach `E-11`/`GM-6.1` (genau eine änderbare Regelart — Reevaluationsintervalle, nur verkürzend), Momentaufnahme je Fall statt Live-Lookup, append-only Änderungshistorie	Angenommen (2026-08-24)
0012	Substanzstammdaten als eigener Service (`tuxametrics-substanzstammdaten-service`, Port 8128): Wirkstoff ist die Entität, Handelsname referenziert genau einen. Nicht patientenbezogen, nicht mandantengebunden (Sentinel `platform`), API trotzdem tenant-skopiert. Löst Handelsname → Wirkstoff auf — ohne die Interaktionsprüfung freizuschalten	Angenommen (2026-08-26)

Die eine Zeile, die man bei ADR-0012 überliest, und dann falsch weiterbaut: die Wirkstoff-Auflösung existiert ab jetzt, die Interaktionsprüfung entsteht dadurch nicht. Leitplanke 4 in CLAUDE.md bleibt in der Substanz gültig; Medikationseintrag.interaktionspruefung bleibt ein Enum mit einem Wert. Eine Prüfung bräuchte zusätzlich einen Interaktionskatalog (Wirkstoff × Mikronährstoff) — eine völlig andere Quelle, die es nicht gibt. FACH-021 nennt die Auflösung als notwendige, nicht als hinreichende Bedingung.

ADR-0010 und ADR-0011 wurden am selben Tag angenommen, und das hat einen Grund, der hierher gehört. ADR-0010 begründet den fehlenden Rückkanal mit „Vorrangregel … nicht spezifiziert" — das stimmt gegen quelle-01.md (v1.1) und ist gegen quelle-01-v1.2.md falsch: E-11 ist dort entschieden und FACH-063 trägt eine vollständige Tabelle veränderbarer und gesperrter Regelarten (Z. 1397–1421). Kein Meinungswechsel, sondern eine übersehene Fundstelle — dieselbe Fehlerart wie bei ADR-0006/0007, nur diesmal innerhalb eines Tages bemerkt. Der Text von 0010 bleibt unverändert stehen; die abgelöste Stelle ist oben markiert.

Die wichtigste Zeile aus 0011 steht nicht im Titel: von den fünf laut E-11 veränderbaren Regelarten führt Regelkatalog.java genau eine. Die Dosisobergrenzen — der Fall aus dem Mockup — sind nach E-11 ausdrücklich nicht praxisseitig veränderbar (FACH-072, „Sicherheitswerte der Zufuhr — nein"). Wer den Screen sieht und die gesperrte Dosisobergrenze für einen unfertigen Stand hält, liest das Gegenteil dessen, was dort entschieden wurde.

ADR-0006 hat genau einen Tag gehalten, und der Grund gehört hierher. Sie begründet den Verzicht auf „Autoimprove" mit einem DOT-Visionspapier, das im Quellrepo selbst als „nicht gebaut, zurückgestellt" markiert ist — und übersieht dabei, dass der kanonische zwirn-autoimprove-service in Zwirn längst existiert, gebaut und capability-gegatet. Das war ein Recherchefehler, kein Meinungswechsel; ADR-0007 benennt ihn so. Wer nur die Tabelle liest, hielte 0006 sonst für eine abgewogene Alternative, die sie nicht war. Der Text von 0006 bleibt unverändert stehen — als Beleg, nicht als Systembeschreibung.

Was ADR-0007 ausdrücklich nicht sagt: dass zwirn-feedback-service in Zwirn überholt wäre. Zwirn bietet beide Bausteine unabhängig an; die Wahl trifft jedes Produkt für sich, und sie ist ein Entweder-oder. tuxametrics hat die Pipeline gewählt.

Der Recherchefehler hatte eine zweite Hälfte, und sie steht hier, weil sie sich wiederholen kann: auch bei ADR-0007 wurde zunächst im falschen DOT-Verzeichnis gesucht (C:\dev\dot\dot, ein totes Checkout) und daraus „kein Präzedenzfall" geschlossen. Das lebende Repo ist C:\dev\dl-controlling\dot, und dort steht ADR-0071 (2026-08-03) mit exakt demselben Schnitt — inklusive dediziertem Keycloak-Client und lokal nachgebautem Melde-Dialog. tuxametrics ist damit der zweite Fall desselben Musters, nicht der erste. Wer künftig „wie macht DOT das?" prüft, prüft C:\dev\dl-controlling\dot.

ADR-0004 und ADR-0005 lesen sich zusammen, und die Reihenfolge ist wichtig: 0004 sagt, dass es keine technische Sperre gegen eine klinische Therapeutenentscheidung geben darf. 0005 sperrt etwas anderes — nämlich dass ein Agent an ihrer Stelle entscheidet. Wer die beiden verwechselt, liest in 0005 einen Widerspruch zu GM-7 hinein, den es nicht gibt: Zugriffskontrolle (wer darf das System benutzen) und klinische Entscheidungsfreiheit (was darf ein Therapeut entscheiden) sind zwei verschiedene Fragen.

ADR-0002 und ADR-0003 sind die beiden Leitplanken, die jede weitere Ausbaustufe binden. Sie sind von ADR-0005 unberührt: dass die Autorisierung entschieden ist, sagt über die regulatorische Einstufung und den Pilot-Betriebsmodus nichts — das sind Fragen an Dritte. Beide sind als Startgate implementiert und durch Tests festgehalten; beide können nur durch ein Nachfolge-ADR aufgelöst werden, das die externe Fundstelle nennt.

Herkunft der Repo-Struktur: zwirn-project-template (siehe dessen CHANGELOG.md), Servicemuster zwirn/samples/sample-data-service-quarkus, Frontendmuster zwirn/samples/sample-frontend-react. Abweichungen vom Template sind in ADR-0001 und im Kommentar der Root-pom.xml (Reactor-Aggregation des Quarkus-Moduls) begründet.