01. Zweck und Abgrenzung

Zweck

CAF steht für Core Application Framework und ist die wiederverwendbare Basis unter modules/: anwendungsneutrale ABP-Bausteine, die ein Produkt einbindet, statt sie je Produkt neu zu schreiben. Sie sind Quellcode-Bausteine, keine NuGet-Pakete (IsPackable=false) und werden per ProjectReference konsumiert; verbindlich ist je Baustein die Vertragsdatei VERTRAG.md (ADR-03).

Das RAL Gütezeichen Anhörungsportal ist der am weitesten ausgebaute Referenzhost. Der LogoLicense ContractManager ist ein zweiter ausführbarer Konsument von Authentication und UI.Blazor; sein fachlicher Umfang ist noch im Aufbau. Belegter Produktbedarf bestimmt die gemeinsame CAF-Fläche.

Das Repository umfasst zusätzlich dokumentierte Dienstverantwortungen unter services/. Diese gemeinsame Ablage erweitert den Frameworkbegriff nicht: ein Dienst ist eine eigene Betriebs-/Schnittstellenverantwortung, ein CAF-Modul wiederverwendbares In-Process-Verhalten. Den aktuellen Schnitt beschreibt Dienste und Kundenbetrieb.

Die am 13.09.2026 bestätigte Entwicklungsrichtung beginnt mit diesem Portal und führt danach zum LogoLicense ContractManager. Gemeinsame Fähigkeiten werden aus konkreten Produktbedarfen abgeleitet und schrittweise als passendes Subset zentral in CAF gepflegt. Die Anforderungsgrundlage ordnet dafür die älteren Confluence-Requirements ein; die Mapping-Matrix hält Extraktionskandidaten fest. Beide ergänzen die Planung und ändern keine bestehenden Modulverträge.

Die Grenze

Die tragende Regel ist einseitig und wird nicht durch Konvention, sondern durch Architekturtests durchgesetzt (ADR-06):

Ein Produkt darf von CAF abhängen. CAF darf nie von einem Produkt abhängen.

Konkret darf kein CAF.Modules.*-Projekt ein CAF.Applications.*-Projekt oder -Paket referenzieren, in keiner Version, und keinen produktfachlichen Namespace oder Begriff verwenden. Eine Verletzung ist ein Build-Fehler, kein Review-Befund.

Entscheidungsregel: gehört etwas nach CAF?

Ein Belang gehört nur dann in einen CAF-Baustein, wenn alle Punkte zutreffen:

1. Domänenneutral — er lässt sich ohne produktfachliche Begriffe beschreiben. DTOs, Permissions, Routen und Fachbegriffe eines Produkts bleiben beim Produkt.
2. Belegter Bedarf — es gibt einen konkreten, getesteten Anwendungsfall. Eine vorsorgliche Abstraktion ohne Konsumenten ist ausdrücklich kein Grund.
3. Stabil zusicherbar — die Fläche lässt sich in VERTRAG.md benennen und nach SemVer versionieren.

Trifft einer der Punkte nicht zu, bleibt der Belang im Produkt. Der Umzug nach CAF ist später mechanisch möglich, der Rückweg nicht.

Was CAF ausdrücklich nicht ist

Aus den Verträgen der Bausteine, nicht nachträglich interpretiert:

• Kein Policy-Owner. Rollen, Permissions, Realm-Namen und Autorisierungsentscheidungen bleiben beim Produkt.
• Kein Owner von Routing, Layout oder Render Mode. Der Host entscheidet.
• Keine Benutzerverwaltung und kein Provisioning. CAF.Modules.Authentication ist ein OIDC-Client, keine Identitätsverwaltung.
• Keine zweite Wrapper-API über Fremdbibliotheken. CAF.Modules.UI.Blazor integriert Cohesion, es kapselt es nicht in eine eigene Komponenten-API.
• Kein Sammelbecken. Ein Baustein Common oder Utils ist keine gültige Antwort auf die Ownership-Frage.

Wann ein Baustein aus CAF herausgelöst wird

Extraktionsfähigkeit ist eine Eigenschaft des Abhängigkeitsgraphen, kein Grund, heute Projekte anzulegen. Ein zweites konsumierendes Produkt ist der Beleg, der eine weitere Assembly- oder Paketgrenze rechtfertigt — nicht die Vermutung, dass es eines geben wird.

Weiter: 02. Bausteine · verbindliche Arbeitsregeln: modules/AGENTS.md

02. Bausteine

Vier Bausteine unter modules/, alle bewusst nicht packbar (IsPackable=false, keine PackageId/Version) und je mit einer verbindlichen VERTRAG.md als Quelltext-Vertrag. Der Referenzhost konsumiert sie per ProjectReference; ein Pack-Skript existiert nicht.

Die zugesicherte Fläche und die ausdrücklichen Nicht-Zusicherungen je Baustein stehen in dessen VERTRAG.md — verlinkt in der Übersicht. Dieses Kapitel fasst nur zusammen und ersetzt keinen Vertrag.

CAF-eigene Scan-/Bereinigungsprozesse können über den optionalen prozesslokalen IDocumentMutationGuard an die Mutationssperre eines Consumers gebunden werden. Der Guard läuft in der mutierenden ABP-Unit-of-Work vor der ersten Bestandsabfrage; die Reservierung bleibt bis Dispose bestehen, auch bei Rollback-Kompensation. Ohne Registrierung bleibt der Ablauf erhalten. Produktgeneration und Freigaberegeln gehören dem Consumer, nicht dem Documents-Adapter.

Produktseitige Shared-UI-Bausteine

Was in CAF.Modules.UI.Blazor nicht liegen darf — Fachwissen wie die Ton-Zuordnung eines Statusenums, die Stufen eines Verfahrens, ein Seitengerüst mit den Texten des Produkts — braucht trotzdem einen Ort, den Shell und alle Feature-*.Blazor erreichen, ohne einander zu referenzieren. Dafür darf ein Produkt ein eigenes Razor-Projekt für produktweite UI-Werte führen (Referenz: CAF.Applications.RAL.QualityMarks.HearingPortal.UI.Blazor mit HearingPortalPage, HearingPortalFilterBar, HearingStatusBadge/HearingPortalStatusTone, HearingWorkflowStepper, HearingPortalDropDownList). Regeln: es referenziert Contracts und CAF.Modules.UI.Blazor, nie eine Feature-Runtime oder ein Feature-*.Blazor; die Architekturtests klassifizieren es als Shared UI Building Block — die Kante Shell/Feature-Blazor → Produkt-UI ist die einzige, die diese Klassifikation erlaubt, jede andere Kante zwischen UI-Assemblies bleibt verboten. Die Dreiteilung Cohesion / CAF-Konvention / Produktwert ist in conventions/cohesion-boundary.md entschieden.

Persistierte Kennungen

CAF-Bausteine behalten das Präfix CAF in persistierten Bezeichnern (CAFDocumentShareGrants), unabhängig davon, welches Präfix das konsumierende Produkt verwendet. Der Präfix markiert Ownership, nicht Technologie: Beim Lesen einer Tabelle ist ohne Blick in den Quellcode erkennbar, wer sie besitzt — und es fällt auf, wenn ein wiederverwendbarer Baustein unbemerkt produktspezifisches Wissen aufnimmt.

Die Cohesion-Referenz-Ausnahme

Cohesion (Syncfusion-basiert) ist die verbindliche Komponentenbibliothek für jede von CAF oder einem CAF-Produkt erstellte Oberfläche. MudBlazor, rohes Syncfusion und Blazorise dürfen von Fachcode nicht direkt gerendert werden; ausgenommen sind die von ABP gelieferten MVC-Razor-Pages unter /Account/** auf dem LeptonX-MVC-Theme. Blazorseitig wird keine Vendor-Komponente mehr gerendert; Blazorise kommt allerdings transitiv ueber ABPs Blazor-Theming-Paket in den Graphen und wird auf Bundle-Ebene wieder entfernt.

Dabei gilt eine bewusste Ausnahme von der Regel „Fremdpakete nur über den zuständigen CAF-Baustein":

Jede Assembly, die Cohesion-Komponenten kompiliert, referenziert das Cohesion-Paket direkt per PackageReference — nicht über CAF.Modules.UI.Blazor.

Grund: Razor-Assets wirken zur Compile-Zeit (Komponenten-/TagHelper-Discovery, _Imports, Scoped CSS, Static Web Assets). Sie werden nicht verlässlich über eine ProjectReference-Kette reexportiert, anders als eine gewöhnliche Abhängigkeit auf eine kompilierte DLL. Ohne direkte Referenz bliebe ein Cohesion-Tag unaufgelöst und würde als leeres HTML-Element gerendert; die UI-Assemblies erzwingen deshalb RZ10012 als Fehler (WarningsAsErrors), womit der Build statt der Oberfläche bricht.

Daraus folgt die Rollenteilung:

• CAF.Modules.UI.Blazor ist Runtime-Integration — Registrierung, Lizenzierung, Bundles, Policy — und wird ausschließlich vom Host eingebunden.
• Razor-UI-Assemblies (Produkt-Shell, Feature-*.Blazor, und CAF.Modules.UI.Blazor selbst) referenzieren Cohesion direkt. Die Version wird zentral an einer Stelle festgelegt (Directory.Packages.props: Cohesion 3.*-*); die Projekte nennen keine eigene Version und kein VersionOverride — sonst lägen zwei Cohesion-Assemblies im selben Render-Baum. 3.*-* ist eine Floating-Version: sie löst die höchste verfügbare 3.x inklusive Prereleases auf, weil Cohesion mitentwickelt wird; ein Major-Wechsel bleibt eine bewusste Entscheidung. Bewusst kein Bereich wie [3.6.2-alpha,4.0.0): bei einem Bereich löst NuGet die niedrigste passende Version auf, die Abhängigkeit würde also still auf der Untergrenze festfrieren — und eine Untergrenze, die es auf dem Feed nicht wörtlich gibt, löst zusätzlich NU1603 aus (hier ein Fehler, weil Warnungen Fehler sind).

Bewusst in Kauf genommen: Zwei Restores desselben Commits können unterschiedliche Cohesion-Versionen auflösen. Das ist kein Versäumnis, sondern der Zweck — solange Cohesion mitentwickelt wird, ist dieser Build ein fortlaufender Integrationstest dagegen. Ein Lockfile würde eine Regression nicht verhindern, sondern ihre Entdeckung verschieben. Was es dafür braucht, ist Sichtbarkeit: die aufgelöste Version muss bei einem roten Build ablesbar sein. - Ein browser-wasm-Projekt darf das serverseitige Integrationsprojekt nicht referenzieren.

Diese direkte Referenz ist keine aufzuräumende Redundanz. Sie gegen CAF.Modules.UI.Blazor zu tauschen, bricht die Razor-Kompilierung.

Cohesion.Components und Cohesion.Components.Layout werden je Blazor-Projekt im _Imports.razor global importiert — so halten es die elf Feature-Blazor-Projekte des Referenzhosts; das _Imports.razor des Hosts selbst importiert keines von beiden. Generische Namen aus Layout wie Column können mit eigenen Komponenten kollidieren; aufgelöst wird das durch Umbenennen der eigenen Komponente, nicht durch Zurücknehmen des globalen Imports.

Kommerzielle Abhängigkeiten

Zwei Bausteine sind an kommerzielle Pakete gekoppelt, was für einen externen Konsumenten Feed-Voraussetzungen schafft:

• Authentication → Volo.Abp.Account.Pro.Public.Web (lizenzierter ABP-Feed). Ein Architekturtest pinnt die Invariante „exakt einmal referenziert, exakt ein Vendor-DependsOn".
• UI.Blazor → Cohesion aus dem GitLab-Gruppen-Feed (Quelle cohesion in NuGet.Config). Solange die aufgelöste Version ein Prerelease ist, bleibt auch der Baustein Prerelease-versioniert.

Cohesion nachschlagen statt raten

Cohesion liefert seinen Komponentenvertrag maschinenlesbar mit. Regel: Parameter werden nachgeschlagen, bevor Markup entsteht — nicht aus dem Gedächtnis rekonstruiert und nicht aus Syncfusion-Wissen abgeleitet. Cohesion besitzt seine API selbst; kein Syncfusion-Typ liegt auf einem öffentlichen Parameter, geraten wird also verlässlich falsch.

Zwei Wege, in dieser Reihenfolge:

1. MCP-Server (Primärweg). Registriert in .mcp.json im Repository-Root (Server cohesion, node tools/cohesion-mcp/dist/index.js aus dem Cohesion-Checkout). Er beantwortet Komponenten-, Parameter-, Token- und Pattern-Fragen direkt.
2. aidx/-Verzeichnis im NuGet-Cache (Offline-Weg). Das Paket bringt den Vertrag selbst mit, auch ohne Cohesion-Checkout und ohne laufenden Server:

text %USERPROFILE%\.nuget\packages\cohesion\<aufgelöste Version>\aidx\

Welche Version das gerade ist, sagt Get-ResolvedCohesionVersion bzw. der Statusbericht von setup.cmd -Verify. Hier steht bewusst keine feste Nummer: Directory.Packages.props:22 pinnt Cohesion nicht, sondern lässt die Version mit 3.*-* mitlaufen — jede hier genannte Nummer wäre binnen Tagen falsch. Inhalt:

Zwei Fallen: llms.txt verweist intern auf docs/ai-dx/…, im NuGet-Paket liegt dieser Inhalt flach unter aidx/ — der genannte Pfad existiert im Paket nicht. Und der MCP-Server liest seinen eigenen Katalog aus dem Cohesion-Checkout; er kann damit von der restaurierten Paketversion abweichen. Versionsgenau zum Build ist nur aidx/.

Der Katalog entscheidet, welche Komponenten existieren — nicht die Erinnerung an eine frühere Version. In 3.6.2 sind CohesionSelect und CohesionSearchInput nicht enthalten; der Ersatz für eine Auswahlliste heißt CohesionDropDownList. Wer solche Namen ungeprüft schreibt, erzeugt Razor-Fehler statt UI.

Override-Register

Jeder lokale Behelf für eine Cohesion-Lücke steht hier mit der Gegenleistung, die ihn zurücknimmt. Ohne diese Spalte wird ein Workaround zum Dauerzustand, weil niemand mehr weiß, worauf er wartete.

Die vier ContractManager-Zeilen gehören zum Grundgerüst RAL-LL-CM-67. Dessen Produkt-Chrome ist eine Kopie der HearingPortal-Fassung; jede kopierte Zone-2-Regel ist ein eigener Override mit eigener Zeile und wird mit ihrem HearingPortal-Gegenstück zurückgenommen. Die HearingPortal-Gegenstücke von Inhaltsabstand (hearing-portal-chrome.css) und ausgeblendetem Menüschalter (applications/RAL/QualityMarks/HearingPortal/src/Host/Components/ErrorDocument.razor.css) stehen bisher nicht in diesem Register.

Mit der restaurierten Cohesion-Version 3.6.3-alpha.0.2 entfallen die Filing-Overrides für Spaltenausrichtung und Sortierbutton-Polsterung, die zusätzliche Anzahl-/Seitengrößenleiste, Dialoginhalt im Footer und aria-hidden="false" an Bestätigungsdialogen. DLL und ausgelieferte Scoped-CSS-/JS-Assets enthalten die entsprechenden Korrekturen. Filing konsumiert AlwaysShowPager, PageSizeOptions, PageSizeText, ChildContent, InitialFocusSelector und PreventClose direkt. Die angepassten bUnit-Prüfungen und der ungefilterte integrierte BrowserGate sind in ral-qm-hp-19-review-gate-5 am 2026-09-11 um 14:01:52 MESZ bestanden. Der reale Filing-Nachweis umfasst Anzahl/Seitengröße samt zugänglicher Beschriftung, Dialoge/Fokus, Spaltenausrichtung, Tastatur, Mobilansicht und axe. Die oben genannten Rücknahmebedingungen für Aktionsdialog und Papierkorbtabelle bleiben bestehen.

Rückbau am 12.09.2026: drei Zeilen entfallen, gegen das wiederhergestellte 3.6.3-alpha.0.6 belegt. Alle drei waren schon vor dem Sprung auf .0.6 gegenstandslos — sie wurden mit 3.6.3-alpha.0.3 hinfällig oder, bei den <select>-Bridges, durch CAFs eigenen Designdurchgang. Aufgefallen sind sie erst bei der Abnahme von .0.6.

Eine vierte Zeile — ValidateOnInput — erfüllt ihre Rücknahmebedingung ebenfalls und bleibt trotzdem stehen. Der Grund steht in der Zeile selbst: sie ist die einzige der vier, deren Rückbau die Formularbindung der ganzen Anwendung berührt, und der Nachweis dafür ist ein Tastendruck im Browser, nicht ein grüner Unit-Test. Lieber eine dokumentierte Altlast als eine Entfernung, die niemand gemessen hat.

• Stepper-Beschriftung. Der Block malte nichts mehr: Cohesions Regel auf .e-step-selected/.e-step-completed .e-step-text-container.e-text trägt inzwischen !important, der Produktblock bewusst keines — und ein Autoren-!important schlägt jede normale Autorendeklaration, unabhängig von der Spezifität. Am laufenden Host auf /anhoerungen/neu (orange-dark) gemessen: rgb(254, 80, 0) bei font-weight 600, also Cohesions Token und Cohesions Gewicht. Die ausgelieferten Werte halten AA in allen vier Paletten (schlechtester Fall 4,99:1, deckungsgleich mit der Messung). Der zugehörige Test prüfte nur den Produktblock und blieb deshalb grün, während er eine Farbe zusicherte, die der Browser nicht rendert; er prüft jetzt die ausgelieferte Regel.
• Semantische Badges. Alle vier Varianten lesen seit .0.3 --coh-color-{warning,error,info,success}-fg, und jede Palette deklariert diese Rollen. Der Produkt-Mix gewann über Spezifität und ersetzte damit einen entworfenen Wert durch eine Näherung — in allen sechzehn Kombinationen die schlechtere (schlechtester ausgelieferter Wert 5,55:1 gegen 4,61:1 des Overrides).
• Native <select>-Bridges. Die Zeile nannte 29 Stellen in 10 Dateien. Es sind null — und zwar null rohe <select>, <input>, <button> und <textarea> in src/**/*.razor insgesamt. Die Migration auf CohesionDropDownList erledigte Stufe 4/5; die Zeile war Buchhaltung ohne Gegenstand. Was die Stellung hält, ist nicht diese Zeile, sondern die leere Allow-Liste RawFormElements = [] in UiDesignContractBaseline.cs, die jeder Datei Budget 0 gibt.

Nicht in der Tabelle, aber im selben Zug zurückgebaut: der workspace__card-fill-Behelf auf dem Arbeitsbereich (CohesionCard.Fill leistet mehr — Flex-Spalte auf Host und Karte, Inhaltsbereich absorbiert den Rest, Fußzeile an die Unterkante) sowie die Zweit-Hälfte des Seitenkopf-Overrides.

Die beiden Marken-Overrides — Hex-Fallbacks für --brand und --brand-ultra-light — sind zurückgenommen und deshalb aus der Tabelle verschwunden. Host/wwwroot/global-styles.css definiert die drei Produkt-Aliase heute einmal aus Cohesion-Tokens: --brand = var(--coh-color-primary), --brand-primary = var(--coh-color-primary-strong), --brand-ultra-light als color-mix gegen --coh-surface-bg. Damit gilt die Richtung, die dieses Register für Marken-Werte fordert: Cohesion-Tokens führen, das Produkt aliasiert. Eine Näherung ist bewusst dabei — --coh-color-primary-strong ist #d54300 statt des früheren #a44300 (Begründung im Kopf der Datei). Benutzt werden die drei Aliase derzeit allerdings nirgends mehr: außerhalb von global-styles.css verweist unter src/ keine Datei auf sie. Sie stehen als Anschlusspunkt bereit, nicht als wirksame Zuweisung.

Ein zweiter Fall hat das Register nie als Zeile erreicht, weil er kein Behelf war, sondern ein bewusster Verzicht: der einzeilige Kontoblock der App-Shell. Die Vorlage zeigt unter dem Namen die Rolle; Cohesions NavBarUserMenu konnte das nicht, und ein nachgebautes Vendor-DOM verbietet Zone 3 der Cohesion-Grenze — also blieb die Zeile weg (App-Shell-Spezifikation D3.1, Upstream-Punkt 17 der App-Shell-Spezifikation). Cohesion 3.6.2-alpha.0.13 liefert CohesionNavUser.Subtitle; seit dem 2026-09-09 füllt HearingPortalShellLayout es aus den RALQM-Produktrollen des angemeldeten Benutzers. Der Punkt steht hier, damit die Gegenleistung nachvollziehbar bleibt: ein Upstream-Punkt, der geliefert wurde, und ein Produkt, das ihn am selben Tag angeschlossen hat — ohne dass je ein Override zurückzunehmen war.

Stand gegenüber Cohesion 3.6.3-alpha.0.17 (gelesen am 2026-10-10): die Tabelle oben ist der vollständige Stand. Ein Block ohne Zeile wurde an diesem Tag gefunden und nachgetragen („WCAG AA, part two“, Hinweis aus Cohesions Bewertung vom 2026-10-10, Punkt 9). Vier Overrides des zugrunde liegenden Playbooks sind in 3.6.2 bereits upstream zurückgenommen und stehen deshalb nicht hier.

Die Versionswechsel im Überblick: 3.6.3-alpha.0.13 (Cohesion-MR !22, „Upstream findings remediation“, 18.09.2026) schloss am 2026-09-19 vier Zeilen: Gruppenlabel-Mix, Kopf-Padding, ValidateOnInput und den Timeline-Schlüssel. 3.6.3-alpha.0.16 schloss am 2026-10-01 fünf Zeilen (Grid-Chrome, Picker, Tooltip-Blase, Modulschienen-Panel, Stat-Kachel) und den Pager-Behelf. 3.6.3-alpha.0.17 schloss am 2026-10-10 vier Zeilen (Token --coh-color-surface, Zeilenmenü, Theme-Provider, senkrechter Stepper) und zwei Brücken, die nie eine Zeile hatten und nur mit ihrer Rücknahme eingetragen sind (Fußlinks der Teilnahmekarten, UP-27, deren Form am 2026-10-11 als eigene Zeile zurückkam, UP-63; Grid-Lesestand im Adaptor, UP-57). Am selben Tag entfielen zwei Tokenwerte am eigenen Stepper-Wrapper (UP-59, Zone 1, deshalb nie im Register) und vier Wartezeiten im BrowserGate (UP-28; Gate-Brücken, kein Override). Den Browsernachweis dieser Rücknahmen haben inzwischen geliefert: der Volllauf cohesion017full02 (2026-10-10) für die Fußlinks (UP-27), die Volläufe cohesion017full02 und final20261011 (2026-10-11) für die Wartezeiten (UP-28), der Testlauf vom 2026-10-10 für den Grid-Lesestand (UP-57) und eine Sichtmessung in allen vier Paletten am 2026-10-11 für Stepper-Linie (UP-59) und senkrechten Stepper (UP-60). UP-27 steht seit dem 2026-10-10, die übrigen seit dem 2026-10-11 im Archiv. Aus steht er noch für den Token --coh-color-surface (UP-10), das Zeilenmenü (UP-56) und den Theme-Provider (UP-58); die Zeilen sagen es einzeln.

Offen bleiben der Caret-Glyph des Dropdown-Triggers, die Modulschiene nur mit Modulen (ohne offene Cohesion-Bedingung, siehe Zeile), die beiden Filing-Zeilen, der Produkt-Picker HearingPortalDropDownList (die Bibliothek trägt seit alpha.0.13 Splat-Caching und ShouldRender an allen drei Auswahl-Wrappern; der Abbau verlangt den Portalnachweis aus UP-15), der Avatar-Behelf, die Fokusrückgabe hinter dem Kit-Dialog (eigener Vorgang mit Gate-Stufe institutions-maintenance) und der Block „WCAG AA, part two“ (Nachmessung ausstehend) und die Form der Fußaktionen der Teilnahmekarten (UP-63).

Nicht in der Tabelle, weil es ihn nicht gibt: einen Host-seitigen Logfilter für den Circuit-Abbruch aus Syncfusions ComponentDispose (Cohesion KI-008, Vendor-Anteil von UP-16). Die Upstream-Liste nannte bis 2026-10-10 „Host-seitige Logfilterung bleibt“; git grep nach KI-008, ComponentDispose und AddFilter über applications/RAL/QualityMarks/HearingPortal/src und modules findet nichts, und Cohesion liefert keinen. KI-008 bleibt in Bibliothek und Produkt unmitigiert.

Dieses Register wird bei jedem Cohesion-Versionswechsel neu gelesen, denn genau dort nimmt ein Upstream-Fix einen Behelf zurück — und ein Behelf, der nach dem Fix bleibt, ist ab dann ein Bug.

Weiter: 03. Erweiterung durch ein Produkt

03. Erweiterung durch ein Produkt

Wie ein Produkt CAF konsumiert — beschrieben am RAL Gütezeichen Anhörungsportal, dem am weitesten ausgebauten Konsumenten. Der zweite Konsument, der LL ContractManager, nutzt bisher CAF.Modules.Authentication und CAF.Modules.UI.Blazor und folgt derselben Struktur. Andere Hosts können denselben Modulvertrag übernehmen, ohne Produktrouten oder Berechtigungen zu kopieren.

Repository und gemeinsame Prüfungen

Jedes Produkt besitzt applications/<Kunde>/<Sparte>/<App>/{src,tests,docs,etc,tools}. App-Solution, Visual-Studio-Startdatei und ABP-Metadaten liegen in dessen src. CAF-Code und -Tests liegen unter modules/<Modul>/{src,tests}; CAF-Architektur bleibt unter docs/arc42. Die Gesamt-Solution CAF.slnx enthält alle Projekte; CAF.Framework.slnx enthält nur CAF. App-Solutions enthalten alle eigenen Projekte und Tests sowie die transitiv benötigten CAF-Projekte.

Die Dienstbereiche services/e-invoicing-api/, services/keycloak/, services/zammad/ und services/alfresco/ ergänzen die Repositorystruktur. CAF-7 übernimmt die vollständige E-Invoice-API samt Tests und notwendiger Registry-/Solution-/Guard-/Gatebasis als eigenständigen zustandslosen HTTP-Dienst. Namespace ist CAF.Services.EInvoicing, Service-ID e-invoicing-api. Keycloak, Zammad und Alfresco bleiben unabhängige Definitionsvorhaben. Der API-Import erweitert den Projektgraphen, begründet jedoch keine ABP-Modulkante oder Datenbank. Kundeninstanzen bleiben beim Kunden, fachliche Verwendung bei der App. Die Dienstesicht und Dienstekarte trennen den tatsächlichen Import-/Nachweisstand von Releases und Kundenbetrieb in CAF-7.

Das Anwendungsregister verbindet diese Ownership mit Solutions, Gate-Einstiegen und Berichten. Ein neuer ausführbarer Host braucht vollständige Gate-Metadaten. Unregistrierte Projekte, fehlende Projekte und unauflösbare Referenzen lassen die Prüfplanung fehlschlagen. CAF-Änderungen prüfen CAF und ihre transitiven Consumer; App-Änderungen nur die Pflichtschritte der betroffenen App-Gates. Die Vereinigung der ausgeführten Framework-/App-/Service-Solutions muss die Gesamt-Solution abdecken; zusätzliche Root-Projekte ohne Gate-Zuordnung stoppen die Planung. architectureInputs und app-eigene gateInputs registrieren zusätzliche Dateiinhalte, die .NET-Tests lesen, einschließlich Markdown. Die Auswahl folgt deren alten und neuen Zuordnungen. Quellcode in App-Stubs verlangt ebenfalls die gemeinsamen Architekturguards. Browser-, axe-, Tastatur- und Browser-Berechtigungsprüfungen sind separat zuschaltbar und standardmäßig aus. Serverseitige Berechtigungstests bleiben Pflicht. Die Gate-Regeln bestimmen Ref-Auswahl und Nachweisbindung.

Die Projektauswertung liegt gemeinsam in tools/_msbuild.py und verwendet MSBuild einschließlich Imports und bedingter Referenzen. Basis und Tipp werden aus getrennten Quellständen bewertet. Die allgemeinen Architekturguards liegen in tests/Architecture und besitzen keine App-Projektreferenz. Der zentrale Schritt architecture prüft sie auch bei reinen CAF- Teständerungen; daraus folgt kein App-Browserstart. Produktregeln bleiben bei den Anwendungen und erweitern den gemeinsamen Graphen innerhalb ihrer eigenen Testassembly.

Berichte entstehen zuerst im App-docs/publish, danach im Kunden-docs/publish und zuletzt im Root-docs/publish. Der zentrale Publisher prüft lokale Links und Kunden-Grenzen, bevor er die erzeugten Bundles übernimmt. Ein App-Stubs-Eintrag erzeugt eine Übersicht, aber keinen erfundenen Bericht. Das Umzugsspec führt die Abnahmekriterien und den aktuellen Nachweisstand. Der Kundenmodus --customer ral erzeugt und prüft nur RAL und dessen Apps. Der vollständige Publisher bleibt der Einstieg für CAF/Pages. Die Review-Korrekturen beschreibt CAF-REPO-02.

Einbindung

Ein Baustein wird über die ABP-Modulkette eingebunden, nicht über direkte Typreferenzen:

1. ProjectReference (bzw. PackageReference außerhalb dieses Repositorys) vom Host auf den Baustein.
2. Die ABP-Modulklasse des Bausteins in die DependsOn-Liste des Hostmoduls aufnehmen, z. B. typeof(CAFModulesUiBlazorModule).
3. Den typisierten Optionsbaum des Bausteins über die Konfiguration des Hosts füllen. Die Optionen validieren beim Start und brechen fail-fast ab, wenn Pflichtwerte fehlen.

Der Host ist Composition Root: Er lädt Module, verkabelt Middleware und Routing, besitzt den gemeinsamen DbContext und erzeugt Migrationen — aber keine eigene Fachlogik und keine neuen Fachentities.

Was das Produkt beitragen muss

CAF sichert bewusst nicht zu, was produktspezifisch ist. Das Produkt bringt mit:

Erweiterungspunkte

Belegt und heute genutzt:

• Typisierte Options mit Startvalidierung — jeder Baustein exponiert einen Optionsbaum, den der Host füllt. Standardmäßig deaktivierte Pfade (z. B. Cohesion ohne Lizenzschlüssel) verhindern, dass Tests oder Hilfshosts versehentlich etwas Unlizenziertes registrieren.
• ABP-Bundle-Contributors — der Baustein liefert benannte Contributors, der Host fügt jeden genau einmal dem tatsächlich verwendeten globalen Bundle hinzu. Doppelte Registrierung lädt Assets zweimal.
• Opt-in-Assets — bewusst nicht im Core enthaltene Assets (Tailwind Preflight, Font Awesome, Cohesion-Themes) ergänzt der Host explizit nach dem Core-Contributor, weil sie LeptonX-/MudBlazor-Styles zurücksetzen oder überschreiben können.
• Routen- und render-mode-freie Komponenten — der Baustein liefert Komponenten ohne Route und ohne @rendermode, damit der Host Autorisierung und Interaktivität steuert.
• Permission-freie Ports — IDocumentContentPort prüft bewusst keine Berechtigung. Der aufrufende Use Case des Produkts muss den Objektzugriff vollständig geprüft haben, bevor er den Port aufruft. Eine ID, URL oder ein Dateiname verleiht selbst nie Zugriff.
• Von außen implementierte Ports — braucht ein Baustein eine Auskunft, die nur das Produkt geben kann, wird sie als Port deklariert und vom Produkt implementiert, statt eine Rückabhängigkeit zu erzeugen.

Verträge ändern

Wer die zugesicherte Fläche eines Bausteins ändert, aktualisiert dessen VERTRAG.md im selben Änderungssatz. Die dort dokumentierte SemVer-Regel (brechend nur mit Major, additiv mit Minor, Korrekturen mit Patch) beschreibt die Absicht für den Fall einer späteren Paketierung — heute gibt es keine Paketversion, weil die Bausteine nicht packbar sind. FrameworkPackagingTests pinnt beides: die Nicht-Packbarkeit (keine PackageId, keine Version, kein PackageReadmeFile) und dass jede VERTRAG.md existiert, nicht leer ist und ihre zwei Pflichtabschnitte trägt.

Die Zuordnung von Testeingaben zum Push-Gate wird in beide Richtungen geprüft: Registry-Muster müssen versionierte Dateien treffen, und Markdown-Lesezugriffe der .NET-Tests müssen für deren eigenes Gate registriert sein. Die testexklusive Einbindung über Directory.Build.targets verändert keine CAF-Runtime- oder ABP-Modulgrenze. Ein Microsoft-Compiler-Analyzer sperrt direkte BCL-Dateileser außerhalb der gemeinsamen Testimplementierung. Verfahren, Pfadsemantik und Grenzen beschreibt die Testkonvention.

Offen

Der Pfad für einen Konsumenten außerhalb dieses Repositorys existiert nicht: Die Bausteine sind bewusst nicht packbar, es gibt also keinen Feed-, Versions- und Upgradeweg. Ein zweites Produkt im selben Repository konsumiert sie per ProjectReference und braucht das auch nicht. Siehe Bekannte Lücken.

Zurück: 01. Zweck und Abgrenzung · 02. Bausteine

04. Anforderungen und Entwicklungsrichtung

Stand: 13.09.2026. CAF bedeutet Core Application Framework. Dieses Kapitel hält die aktuelle Zielrichtung und die fachliche Einordnung der älteren Requirements fest. Es ist eine Anforderungsgrundlage für die Weiterentwicklung, keine Zusage, sämtliche genannten Funktionen zu bauen. Die geltenden Modulverträge bleiben in Kapitel 2 verankert.

Produktbedarf führt die Weiterentwicklung

Zuerst entsteht das RAL Gütezeichen Anhörungsportal (QualityMarks/HearingPortal), danach der LogoLicense ContractManager, zunächst für Stiftung Warentest. Aus den Anwendungen soll ein Subset gemeinsamer Funktionen nachträglich in CAF-Module überführt und zentral gepflegt werden. Diese Richtung wurde am 13.09.2026 vom Benutzer vorgegeben. Der parallele LogoLicense-Dokumentationsentwurf konkretisiert den nächsten Bedarf; er ist noch keine implementierte zweite Anwendung. EnvironmentalLabel bleibt ein weiterer App-Stub und liefert in dieser Betrachtung noch keinen belastbaren Wiederverwendungsnachweis.

Der Nutzen: Anwendungen konzentrieren sich auf ihre Fachregeln, während gemeinsam verwendete Funktionen konsistent weiterentwickelt und korrigiert werden. Es entsteht keine Verpflichtung, jede ähnliche Funktion zu vereinheitlichen. Ausgangspunkt einer Extraktion ist ein konkreter Anwendungsfall mit einer kleinen, stabil beschreibbaren gemeinsamen Schnittstelle.

Cohesion ist das vorhandene Beispiel für eigenständige Wiederverwendung: Die separat gepflegte Razor Class Library liefert generische UI-Komponenten. CAF integriert sie und ergänzt anwendungsneutrale UI-Konventionen. Produktoberflächen und Fachtexte entstehen in der Anwendung. Die Apps konsumieren gemeinsame Bausteine; „ableiten“ verlangt keine gemeinsame Basisklasse. Eine gemeinsame CAF-Implementierung bedeutet auch keine gemeinsame Kundendatenbank und keinen zentral betriebenen Dienst. CAF-Bausteine bleiben derzeit Quellcode-Bausteine im Repository; Cohesion besitzt bereits eine eigene Paketgrenze.

Gelesene Quellen und Verbindlichkeit

Ausgewertet wurden die Seite Reqs (Version 1, 12.01.2026; leerer Seitentext) und ihre 20 Unterseiten im Space OLCAF. Die Unterseiten wurden am 13.09.2026 vollständig als HTML gelesen, einschließlich der Requirement-Yogi-Kennungen in den Tabellen. Der folgende Katalog dokumentiert den gelesenen Versionsstand. Er enthält eine thematische Synthese, keinen vollständigen Einzelanforderungsexport. Der Workflow-Bereich enthält nur ein Gerüst ohne ausgefüllte Requirement-Zeilen.

Code Design Principles, Basisarchitektur und Projektverwaltung aus Confluence wurden auf Benutzerwunsch nicht einbezogen. Die Seite „Platform“ gehört zum verlinkten Requirements-Baum; ihre Anforderungen werden deshalb berücksichtigt, ihre alten Lösungsvorschläge jedoch nicht als neue Architekturentscheidung übernommen. Aktuelle Benutzervorgaben und Repositoryregeln gehen historischen Vorgaben vor.

Der aktuelle Produktabgleich stützt sich auf die HearingPortal-Architektur, die LogoLicense-Anforderungen und deren Quellenkatalog. Die Matrix in Kapitel 5 nennt konkrete Produktbezüge. Die dortigen LogoLicense-Story-IDs sind lokale Entwürfe, keine freigegebenen Jira-Aufträge.

Anforderungsziele für CAF

Die folgenden Ziele sind die aktuelle Synthese. Sie ersetzen keine Quell-ID und erteilen keinen Implementierungsauftrag. Für die spätere Abnahme muss jeder ausgewählte Umfang konkretisiert werden.

Historische Vorgaben mit Klärungsbedarf

Vorgehen und offene Präzisierungen

1. HearingPortal am konkreten Fachbedarf weiterentwickeln; vorhandene CAF-, ABP- und Cohesion-Funktionen nutzen.
2. Bei der Verfeinerung von LogoLicense-Stories die Kandidatenmatrix heranziehen und echte Gemeinsamkeiten sowie abweichende Regeln mit Beispielen festhalten.
3. Nur einen stabilen gemeinsamen Anteil zur Extraktion auswählen. Zunächst reicht eine Dokumentation des Vertrags und seiner Grenzen; technische Zerlegung folgt einer eigenen Aufgabe.
4. Bei späterer Umsetzung Vertrag, Konsumenten und erforderliche Tests gemeinsam ändern. Eine zusätzliche Paket- oder Dienstgrenze benötigt einen eigenen Anlass.

Die nächste fachliche Klärung betrifft vor allem den Rechnungsumfang (Erzeugen, Empfangen, Validieren, Übertragen), die Unterschiede der Vorlagenverwaltung und die externe DMS-Schnittstelle. Releaseumfang und Produktentscheidungen bleiben im bestehenden LogoLicense-Anforderungsdokument. CAF-weite Fragen werden hier geführt: Welcher gemeinsame Vertrag ist stabil, welche Daten besitzt er, und wer benötigt eine unabhängige Paketversion? Die Kandidatenmatrix ist die einzige ergänzende Zuordnung; ein zusätzlicher Roadmap- oder Entscheidungslog wird daraus nicht abgeleitet.

05. Mapping-Matrix der Wiederverwendungskandidaten

Stand: 13.09.2026. Arbeitsgrundlage für die spätere Verfeinerung der Produkte, ohne Codeänderung, Modulerweiterung oder Releasezusage. Zielrichtung und Confluence-Quellen stehen in Kapitel 4. Die Einordnung ist eine Ableitung aus diesen Quellen und dem aktuellen Dokumentations-/Quellstand, kein neuer Funktionsnachweis.

Leseregel und Produktbezüge

• Basis nutzen: Es gibt bereits einen CAF-/Cohesion-Vertrag. Seine Eignung für LogoLicense muss am jeweiligen Anwendungsfall geprüft werden.
• Abgleichen: Beide Produkte zeigen verwandten Bedarf. Der gemeinsame Anteil ist ein Kandidat, kein beschlossenes Modul.
• Später prüfen: Konkreter Bedarf besteht bislang nur in einem Produkt oder der Vertrag ist offen.
• Produkt / Werkzeug: Fachverantwortung beziehungsweise Entwicklungs-/Betriebswerkzeug; derzeit kein zusätzlicher CAF-Runtimebaustein.

HP bezeichnet das Gütezeichen-Anhörungsportal. LL bezeichnet den LogoLicense-Anforderungsentwurf. Die LL-US-Verweise führen in die Story-Entwürfe. Ein ähnlicher Name, derselbe Kunde oder derselbe Provider genügt nicht als gemeinsame Fachsemantik.

Für vier bereits im HearingPortal vorhandene Fähigkeiten liegen inzwischen einzelne Extraktionsentwürfe vor. Sie konkretisieren gemeinsame Implementierung, Produktadapter und gleichzeitige Entfernung der ersetzten Produktlogik. Die folgenden Einordnungen bleiben Kandidatenbewertungen; die Entwürfe sind noch nicht umgesetzt.

Mapping-Matrix

Noch kein Kandidat dieser beiden Produkte: AI-Assistenz/Wissenssuche (BR-AI-001/-002), Echtzeitchat (BR-CHAT-001) und ein allgemeines Vertrags-/Produktverwaltungssystem. Die Quellen bleiben im Katalog sichtbar. Ohne bestätigten Bedarf folgen daraus keine Module oder Stories. Massenmail/Newsletter (FR-MAIL-005/-006; LL-US-019) ist ebenfalls kein automatisch enthaltenes Merkmal des Versandkandidaten.

Beispiel: schmaler E-Invoice-Vertrag

Das vom Benutzer genannte Beispiel eignet sich für einen bewusst kleinen Zuschnitt. LL besitzt den Anwendungsfall Rechnung; ein späterer CAF-Baustein könnte dessen technische Formatausgabe übernehmen. Das ist ein Vorschlag, noch keine festgelegte API:

Vor einem Umsetzungsauftrag werden Beispielrechnungen einschließlich fehlerhafter Daten, Korrektur-/Stornofällen und Wiederholungen gesammelt. Danach sind Profile/Versionen, Validator, Fehlervertrag und Idempotenz festzulegen. Die konkrete API-Form (In-Process-Vertrag oder Remote-API) bleibt offen; ein CAF-Modul verlangt keinen eigenen Dienst. Eine zweite Anwendung wäre ein starker Wiederverwendungsbeleg. Sie ist nach der geltenden CAF-Regel keine starre Voraussetzung, wenn schon ein getesteter Anwendungsfall einen bewusst stabilen, anwendungsneutralen Vertrag trägt.

Wann aus einem Kandidaten eine Extraktion wird

Für jeden ausgewählten Kandidaten müssen sich fünf Fragen konkret beantworten lassen:

1. Welche realen Anwendungsfälle teilen Eingaben, Ergebnisse und Fehlerbedeutung?
2. Was leisten vorhandenes ABP, Cohesion oder ein bestehender CAF-Vertrag bereits?
3. Welche Fachregeln und Daten verbleiben ausdrücklich in jedem Produkt?
4. Ist der gemeinsame Vertrag ohne Produktnamen stabil beschreibbar und testbar?
5. Welchen nachweisbaren Wartungsnutzen bringt der Umzug gegenüber einer einfachen Lösung im Produkt?

Die konkrete Vertiefung des HearingPortal-Bestands erfolgt jetzt in den vier Drafts: Administration, HealthChecks, Incidents und EmailDelivery. Ihre vorgeschlagene Reihenfolge und die Verbindungen zwischen Störungen und Zustellung stehen im Spec-Index. Fachliche Vorlagenregeln werden weiterhin zwischen den Produkten abgeglichen. E-Invoicing wird aus LL heraus konkretisiert; beim HP wird dafür kein Bedarf erfunden. DMS benötigt den konkreten externen Schnittstellenvertrag. Die Reihenfolge ist eine Empfehlung für die Verfeinerung, keine Änderung der Releaseplanung.

Bei einer späteren Extraktion werden VERTRAG.md, Modulgrenzen, Produktkonsumenten, Architektur und erforderliche Tests im selben Änderungssatz angepasst. Dazu gehört ausdrücklich die Entfernung der ersetzten Produktimplementierung; bloßes Kopieren in CAF gilt nicht als Extraktion. Die gemeinsamen Extraktionsbedingungen machen diesen Wechsel überprüfbar. Bis dahin bleiben Matrix und Specs ein Entwurf; die vorhandene Laufzeitstruktur wird durch sie nicht verändert.

06. Dienste und Kundenbetrieb

Repository und Framework

Das CAF-Monorepo umfasst CAF-Framework-Bausteine und Kundenanwendungen. services/ ergänzt die Struktur um eigenständige technische Dienstverantwortungen. CAF als Framework bleibt der anwendungsneutrale Code unter modules/. Die Strukturentscheidung steht im Konventionsregister G-10.

Die angenommene Strategie CAF-23 legt unabhängige Versionen für Anwendungen und Dienste sowie eine gemeinsame Frameworkversion für die bestehenden Quellmodule fest. App-eigene Module und Application Services folgen ihrer Anwendung; RAL-Auth erhält ein gemeinsames Theme-/ Konfigurationsbundle. MM verantwortet Release- und getrennte Rolloutfreigaben. G-12 führt die angenommenen Startversionen und die Trennung von Produktversion, automatischer Buildnummer und Artefaktidentität. Die Implementierung ergänzt Versionsquellen, ownerbezogene MSBuild-Metadaten und das RAL-Auth-ZIP. Die vollständige Abnahme samt Releaseablage-/Berechtigungsnachweisen führt CAF-23. Als vollständige Dauerablage ist Hetzner S3 in Falkenstein beschlossen: private Buckets caf-release-archive und caf-release-acceptance, COMPLIANCE zehn Kalenderjahre mit jährlicher Verlängerung im Archiv und ein Tag für Abnahmedaten. Version-ID, Hash und Größe binden alle Releasebytes einschließlich OCI-Layern, Quellständen und Nachweisen. GitLab bleibt CI-/Imageverteilung und atomare Versionsreservierung; dessen löschbarer Paketindex ist nicht mehr die Dauerablage. Der Releaseweg prüft zusätzlich archivierte Historie, Fristen, Schutzregeln, CI-Herkunft und MM-Identität. Reale Release-/Restore-/Consumerabnahmen und aktiver Fristbetrieb sind in der Spec belegt; die Quellmodulgrenze bleibt erhalten.

Aktuelle Bausteinsicht

flowchart TB
    R["CAF-Monorepo"] --> M["modules/\nCAF-Framework"]
    R --> S["services/\nE-Invoice-Import und unabhängige Dienstdefinitionen"]
    S --> E["e-invoicing-api/"]
    S --> K["keycloak/"]
    S --> Z["zammad/"]
    S --> A["alfresco/"]
    R --> P["applications/\nKundenanwendungen"]
    P --> C["RAL/etc/\nkonkreter Kundenbetrieb"]
    R --> D["docs/services/\nkanonische Dienstekarte"]

CAF-6 lieferte diese vier Dokumentationsgerüste. Der vollständige E-Invoice-Import einschließlich Tests und Service-Gatebasis ist seit 20.10.2026 als konkreter CAF-7-Schnitt beauftragt und lokal begonnen; sein ausgeführter Nachweisstand steht in der Spec. Vorhandene Keycloak-Dateien bleiben bei RAL und den App-Lifecycles. Zammad besitzt mit CAF-25 eine lokale Compose-Bereitstellung; deren Serverabnahme bleibt offen. Alfresco bleibt ein eigenes Definitionsvorhaben.

Zuständigkeiten und Schnittstellen

Die Dienstekarte führt den aktuellen Stand pro Dienst. Ihre Service-READMEs und services/AGENTS.md sind die Einstiegspunkte im Quellbaum. Die bestehende Produkt- und Betriebsarchitektur bleibt maßgeblich für ausführbare Pfade. Eigenentwickelte Dienste beschreiben ihre Details in einer eigenen arc42-Karte, für E-Invoice unter Service-arc42. Eigene Specs und der künftige Nummernkreis EINV folgen dem gemeinsamen Prozess. Bestehende CAF-Querschnittsvorgänge bleiben an ihrem bisherigen Ort. Die interne Reportingnavigation ergänzt einen kundenneutralen Servicebereich, ohne öffentliche Kundenberichte zu erweitern; Entscheidung in G-10, Nachweise in CAF-21.

Einführung ausführbarer Dienste

Ein ausführbarer Dienst benötigt vor seiner Übernahme eine explizite Ownership, vollständige Solution-/Guard-/Gate-Zuordnung, Schnittstellen- und Kompatibilitätsnachweise sowie einen eigenen Releaseweg. CAF.slnx muss weiterhin alle eigenen .NET-Projekte erfassen. HTTP-Vertragsabhängigkeiten erfordern eine zusätzliche, belegte Auswahl neben MSBuild-Projektkanten.

Reine Compose-Betriebsdefinitionen registrieren runtime: compose, Manifest, Definitionsversion, Gate-Einstieg und CI-Job. Sie besitzen keine .NET-Projekte oder leeren Solutions. Der Planer wählt ihre realen Providerproben; fehlende, leere, übersprungene oder falsch gebundene Ergebnisse blockieren lokale und Server-Gates.

Die notwendige Register-/Solution-/Guard-/Gatebasis gehört zum begrenzten Import in CAF-7. Eigenständige Betriebssystem-Releases und Kundenbereitstellung besitzen eigene Vorgänge. Ein Quellsnapshot oder ein grüner Build bestätigt keine Zielsystem-, Konformitäts- oder Produktionsabnahme.

E-Invoice als eigenständiger Dienst

Die bestätigte Ausgangsentscheidung vom 20.10.2026 steht in G-10: services/e-invoicing-api/ besitzt die vollständige eigene HTTP-API, ihre Tests und den Releasevertrag. Service-ID ist e-invoicing-api, der .NET-Namespace CAF.Services.EInvoicing. Die gemeinsame Quellrevision erzwingt kein gemeinsames Deployment mit einer CAF-Anwendung. Interne Typumbenennungen dürfen HTTP-Routen, JSON-Nachrichten, API-Key- und Fehlervertrag nicht unbemerkt ändern.

Die API bleibt für den Import zustandslos und benötigt weder ABP noch Datenbank, Keycloak oder ContractManager. HTTP-Consumer und später der ContractManager liefern PDF und Rechnungsdaten derselben freigegebenen Fassung. Nummern, Fachstatus, SQL-Lesen, Persistenz und Versand bleiben bei ihnen. Der Dienst erhält keinen Zugang zur Legacy-SQL-Datenbank. CAF-Module sind kein erforderlicher Zwischenschritt.

flowchart LR
    REPO["CAF-Monorepo: eigener E-Invoice-Dienst"] --> REL["Eigene versionierte Artefakte\nWindows / Linux, SHA und Vertragsversion"]
    LEG["HTTP-Consumer\nPDF/JSON derselben Fassung"] -->|"HTTPS + API-Key"| API["E-Invoice-API\nzustandslos, ohne Datenbank"]
    REL --> API
    API --> PDF["PDF-Verarbeitung + XML-Einbettung"]
    API --> VAL["Gebundene XSD-/Schematron-Regeln\nMustang/Java bei vertiefter Prüfung"]
    PDF --> OUT["Dokument und prüfbare Befunde"]
    VAL --> OUT
    OUT --> LEG
    CM["Später: ContractManager\neigene Fach-/Persistenzhoheit"] -. "gleicher HTTP-Vertrag" .-> API

Die bestehende Schematron-Strecke ist kein vollständiger Peppol-Nachweis; ein Anhang allein belegt kein konformes hybrides PDF. Die reale Konformitätsregression ist CAF-12, die Validatorhärtung CAF-9. API- und Validatorversionen werden für eigene Releases gebunden und gemeinsam dokumentiert; Java wird nicht automatisch durch ein .NET-Publish mitgeliefert. Separate Windows-/Linux-Artefakte werden in CAF-10 und CAF-11 auf sauberen Zielsystemen abgenommen.

Windows-Testumgebung, lesendes Kundeninventar und IIS-Servicebetrieb mit Rückweg sind CAF-13, CAF-15 und CAF-17. Die VB.NET-Anbindung und deren Schattenvergleich übernimmt der Benutzer extern; CAF-14 und CAF-16 gehören nicht mehr zum aktiven Plan. Windows Server/IIS ist das priorisierte eigenständige Betriebsziel. Der HTTP-Vertrag setzt keine konkrete Clientimplementierung oder gemeinsame App-Auslieferung voraus. Die passive Kundeninstallation bleibt bis zu ihrem konkreten Betriebsauftrag erhalten. Der tatsächlich installierte Commit ist zu belegen, nicht aus einer vermuteten Commitdifferenz abzuleiten. Die ersten Planungspakete bleiben CAF-Querschnitt; ein neuer Dienstscope ist für den Import nicht erforderlich. Die ContractManager-Fachintegration bleibt RAL-LL-CM-29/-30 und wird nicht durch den Legacybetrieb ersetzt.

Zammad-Betrieb und App-Adapter

PO-Entscheidung vom 24.10.2026: Zammad wird als Standardprodukt unabhängig betrieben. CAF-19 schärft allgemeine Dienstdefinition und Betriebsvertrag; konkrete Instanzen bleiben im Kundenbetrieb. Der erste Adapter läuft im LogoLicense ContractManager, dessen bestehende Datenbank auch Referenzen, ausstehende Aufträge und Rückmeldungen hält. Ein zusätzlicher Middleware-Service oder eine zusätzliche Middleware-Datenbank gehören nicht zu diesem Schnitt.

UZ (EnvironmentalLabel) kann später denselben technischen Adapter gegen eine andere Instanz verwenden. App- und Instanzbindung gelten für Konfiguration, Credentials, Providerkennungen, Aufträge und Rückmeldungen. Gemeinsamer Code bedeutet keine gemeinsame Instanz oder Datenbank. Eine Extraktion erfolgt erst mit einem konkreten zweiten Consumer und seiner Umstellung; kein Zugriff auf die Runtime oder Tabellen einer anderen App. Vertrag und Entscheidung stehen in CM55 und ADR-06. CAF-19 konkretisiert die erste Produkt-/Plattformbindung im Betriebsvertrag. Entwicklung erfolgt auf Windows mit Linux-Containern, Staging auf Linux; Linux-Produktion ist vorgesehen, die konkrete Topologie bleibt offen. CAF-25 liefert jetzt getrennte lokale Instanzen mit gepinnten Images, geschützter Konfiguration und lesender Readiness. Der LL-Wrapper ruft den Dienst explizit auf; der App-Start tut dies nicht. CI nutzt den vorhandenen Linux-Runnerpool, dessen Dockerfähigkeit noch nachzuweisen ist. Providervertrag, Adapter und Betriebsabnahme bleiben CM73/CM74/CM76 zugeordnet.

CAF-Modularisierung

Eine gemeinsame Repositoryablage entscheidet keine CAF-Extraktion. Erst ein konkret benötigter anwendungsneutraler Vertrag rechtfertigt einen gemeinsamen Baustein. Bei einer Extraktion werden Implementierung und erster Consumer gemeinsam umgestellt; die ersetzte Produktimplementierung wird entfernt. Die bestehende Entscheidungsregel und die Kandidatenmatrix gelten weiter.

Zammad-Folgeplanung vom 25.10.2026

Die Dienstdefinition CAF-19 wird durch CAF-25 (Bereitstellung), CAF-26 (instanzbezogene Updates) und CAF-27 (Recovery über Systemgrenzen) umgesetzt. Die Aufgaben bleiben im CAF-Nummernkreis. CAF-25 ist beauftragt und liefert unter services/zammad die gepinnte lokale Compose-Bereitstellung mit Lifecycle und Gate. Lokales Gesamtgate und Linux-/WSL-Probe sind bestanden; die verpflichtende Linux-CI-Abnahme steht aus. CAF-26/27 bleiben Entwürfe.

Die app-eigene Basis liegt in CM72 bis CM75, ihre spätere LL-Betriebsfreigabe in CM76. Ein Versionsmanifest bindet Zammad, Compose, Begleitimages, Adapter und Konfigurations-/Job-Payloadschema. LL und später UZ wählen und aktualisieren ihre Instanzen unabhängig. Eine gemeinsame Skriptversion bedeutet keinen gemeinsamen Rollout. App-Start, Betriebsinstallation und Update bleiben getrennt.

Ungewisse externe Wirkungen erfordern belegte Korrelation oder gesperrte Klärung. Restoreproben müssen auch auseinanderlaufende App-/Zammad-Stände behandeln; keine blinde Wiederholung von Artikeln/Mails und kein pauschaler RALLL-Restore. Testkopien bleiben vor dem ersten Start quarantänisiert. Details und Abhängigkeiten stehen in der LL-Verteilungssicht. Die lokale CAF-25-Bereitstellung liefert noch keinen App-Adapter und keine Kundenbetriebsfreigabe. Maßgeblich bleibt die Nachweismatrix der jeweiligen Spec.