01. Einführung und Ziele

Aufgabenstellung

LogoLicense.ContractManager soll RAL bei der Lizenzierung der Nutzung von Marken/Testlogos der Stiftung Warentest für Werbung mit Testergebnissen unterstützen. Stiftung Warentest führt die Produkttests durch und veröffentlicht die Ergebnisse. RAL übernimmt die Lizenzvermarktung und Abwicklung des Logo-Lizenzvertrags. Die RAL-Antragsprüfung bewertet die beantragte Logonutzung; sie ist keine Produktzertifizierung und erzeugt kein eigenes RAL-Testurteil. Diese Abgrenzung wurde am 13.09.2026 vom Benutzer präzisiert und wird durch die öffentlichen Darstellungen von RAL und Stiftung Warentest gestützt.

Der derzeitige Haupteingang für Test- und Produktdaten ist laut Benutzerpräzisierung ein XML-Import. Die importierten Daten bilden die Referenz dafür, welches Produkt und welches zugehörige Testergebnis dem Lizenzantrag zugrunde liegen. Die Prozessübersicht verbindet Produktsuche und Antragsprüfung mit Kundenportal, interner Sachbearbeitung, Buchhaltung und Missbrauchsverfolgung. XML-Schema, Transport, Takt und Änderungsregeln sind noch offen; im neuen ContractManager ist dieser Import noch nicht implementiert.

Die sechs Prozessbereiche sind Registrierung, Antragstellung, Antragsprüfung und -bearbeitung, Lizenzerweiterung, kontinuierliche Logo-Überwachung und Bearbeitung ihrer Fälle. Zusammen bilden sie den fachlichen Ausgangspunkt. Das erste Release umfasst ausschließlich Stiftung Warentest, bestätigt durch den Benutzer am 13.09.2026. Grüner Knopf und Nutri-Score sind darin nicht enthalten. Die Priorität und konkrete Auslieferungsfolge der StiWa-Funktionen bleiben zu klären. Getrennte Keycloak-Realms, Alfresco Community Edition als selbst gehostetes DMS und Zammad für die operative Logo-Überwachung und das Beschwerdemanagement sind ebenfalls bestätigt. Zammad führt Tickets, Zuständigkeiten, Kommunikation und Wiedervorlagen; ContractManager den Lizenzbezug und fachliche Entscheidungen; Alfresco die Dokumentakte. Integrationsdetails und Archivnachweise bleiben offen.

Fachliche Ziele

Die Formulierungen sind aus den Geschäftsanforderungen und der Prozessübersicht abgeleitet. Die stabilen Anforderungskennungen und offenen Entscheidungen werden ausschließlich im Anforderungskatalog gepflegt.

Stakeholder

Qualitätsziele und Abgrenzung

Vorrang haben serverseitige Objektberechtigung, Integrität des Freigabeprozesses, Nachvollziehbarkeit und zuverlässige Schnittstellen. Bedienbarkeit folgt der CAF-Oberfläche mit Cohesion und dem Ziel WCAG 2.1 AA. Messbare Szenarien stehen in Kapitel 10.

Das Hearing Portal liefert die Dokumentationsstruktur und technische Basis. Anhörungs-Lifecycle, Institutionsrollen und teilnehmerbezogene Gastlinks werden nicht als LogoLicense-Fachmodell übernommen. Aktuell besteht ein ausführbares Grundgerüst mit Anmeldung im eigenen Realm und interner Katalogrecherche; die übrigen Anforderungen sind nicht umgesetzt. Die Ziele dieses Kapitels sind kein Nachweis gelieferter Funktionen.

02. Randbedingungen

Gesetzte technische Basis

Die folgenden Vorgaben gelten bereits durch die Repositoryregeln und den Entwicklungsleitfaden. Die Benutzerentscheidung zu Alfresco CE und Zammad ergänzt externe Systeme mit eigenen Betriebsabhängigkeiten; die CAF-Technologiebasis bleibt bestehen. Für LogoLicense existiert noch keine ausführbare Umsetzung.

Die RAL-Vorgabe zur Realm-Trennung ist konkreter als der ältere, allgemeine SSO-Wunsch in Confluence und wurde am 13.09.2026 erneut bestätigt. Identitäten, Sessions und Berechtigungen werden deshalb nicht implizit über die drei Anwendungen hinweg geteilt. Realmübergreifendes SSO gehört nicht zur Zusage für das erste Release; ein Föderations- oder Brokeringvorhaben wird daraus nicht abgeleitet. Alfresco und Zammad erhalten eigene Clients; die Zuordnung zum LogoLicense-Realm oder eine spätere gemeinsame Nutzung durch mehrere Sparten ist in OQ-11 zu konkretisieren. Die Produktrealm-Trennung verlangt nicht automatisch einen zusätzlichen Realm für jeden Client.

Abgleich mit den Confluence-Vorschlägen

Quellen: Prozessübersicht, Top-Level Datenmodelle und nicht-funktionale Anforderungen.

Fachliche und organisatorische Grenzen

Die Quellen nennen Gebühren, Steuerberechnung, Zahlungsfristen, Abmahnschreiben und Archivierung. Diese Aussagen werden als zu bestätigende Fachvorgaben dokumentiert. Sie sind weder rechtliche Bewertung noch belastbare Abrechnungsregel ohne Tarif-, Steuer-, Frist- und Aufbewahrungsdefinition.

Jira RALGZ ist hier Referenz für Story- und AC-Struktur. Das neue Dokumentationspaket erzeugt keine Jira-Vorgänge und übernimmt keine dortigen Erfüllungsstände. Vor Implementierung benötigt jede Story bestätigte Regeln, negative Akzeptanzfälle, eine klare Modulverantwortung und passende Nachweise; siehe Story-Entwürfe.

03. Kontextabgrenzung

Fachlicher Kontext

Systemgrenze ist die künftige Anwendung LogoLicense.ContractManager: Kundenportal und interne Bearbeitung betrachten denselben fachlichen Vorgang über unterschiedliche Berechtigungen. Ein Antrag, der daraus entstehende Lizenzvertrag, dessen Rechnungen und mögliche Fälle der Logo-Überwachung bleiben eigenständige Objekte. Diese Trennung folgt dem Top-Level Datenmodell.

Stiftung Warentest besitzt die fachliche Verantwortung für Testdurchführung und veröffentlichte Ergebnisse. RAL bearbeitet die Lizenzierung der Werbung mit diesen Ergebnissen und den Marken/Testlogos. Diese am 13.09.2026 präzisierte Rollenverteilung begrenzt die Systemaufgabe: Der ContractManager verwaltet keine RAL-Produkttests oder Produktzertifizierungen.

Unternehmenszugehörigkeit und Agenturvollmacht sind fachliche Beziehungen, keine pauschale Zugriffserlaubnis. Die Abgrenzung zwischen persönlichem Vorgang, gemeinsamem Firmenzugriff und vertretender Agentur muss in der Rollen-/Objektmatrix bestätigt werden.

Technischer Kontext

Die Prozessübersicht benennt fachliche Nachbarn; die Benutzerentscheidung ergänzt Alfresco CE und Zammad. Die öffentlichen API-Dokumentationen wurden geprüft (Quellen); damit ist keine konkrete Instanz bereits angebunden oder die Produktversion festgelegt.

Jira und Confluence liefern Anforderungen und Arbeitsorganisation. Sie sind durch diesen Entwurf keine Laufzeitabhängigkeit des ContractManagers. Das bestehende Logo-Lizenz-Programm ist als Altsystemkontext der Quelle zu behandeln; ein dauerhafter Parallelbetrieb wird damit nicht festgelegt.

Vertrauens- und Produktgrenzen

Externe Nutzereingaben, importierte Produktdaten und Providerantworten werden validiert. Ein erfolgreicher Login belegt weder Firmenvertretung noch Berechtigung auf ein Dokument. Der jeweilige Anwendungsfall prüft Rechte vor jedem fachlichen Zugriff und vor dem Aufruf eines Dateivertrags.

Ein Treffer im importierten Katalog belegt den Produkt-/Ergebnisbezug für die weitere fachliche Prüfung. Er beweist nicht die Identität, Unternehmensvertretung oder Antragsberechtigung der handelnden Person und erteilt noch keine Lizenz. Seit PO-Klarstellung vom 12.10.2026 gibt es keinen manuellen Ersatzweg für fehlende Produkt-/Testfakten. Eigene Notiz/Suchkategorien werden getrennt gepflegt; importierte Fakten und historische Vertragsgrundlagen bleiben unveränderbar.

HearingPortal und EnvironmentalLabel.ContractManager sind Nachbarprodukte im Repository. Es sind keine gemeinsamen Fachentities, direkten Tabellenzugriffe oder automatisch übernommene Produktrollen vorgesehen. Datenübernahmen benötigen einen ausdrücklichen, schmalen Vertrag und einen bestätigten fachlichen Zweck.

04. Lösungsstrategie

Leitidee des Entwurfs

Der ContractManager wird als eigenständige CAF-Anwendung mit einem modularen Monolithen vorgeschlagen. Fachliche Grenzen folgen überprüfbaren Verantwortlichkeiten, nicht jeder Tabelle oder jedem als „Management“ bezeichneten Punkt der Quellsammlung. Bestehende ABP-Mechanismen übernehmen technische Aufgaben; fachliche Prüfregeln bleiben im Produkt.

Die Confluence-Geschäftsanforderungen begründen durchgängige Bearbeitung und nachvollziehbare Freigaben. Die daraus vorgeschlagenen Architekturmaßnahmen sind noch zu bestätigen:

Anwendungsschnitt statt Plattformausbau

Die in Kapitel 5 benannten Bausteine sind zunächst fachliche Verantwortungsbereiche. Ein Feature beginnt nach CAF-Konvention klein mit Contracts und Runtime. Ein weiteres Projekt ist erst bei einer realen, unabhängig nutzbaren Grenze gerechtfertigt. Ein allgemeiner Workflow-, History-, Integration- oder DMS-Baukasten wird nicht aus den Quellüberschriften abgeleitet.

Authentication, UI und schmale Dateifunktionen sollen ihre vorhandenen CAF-Verträge nutzen. Der erste Schnitt verwendet CAF.Modules.Authentication und CAF.Modules.UI.Blazor unverändert; CAF.Modules.Documents wird erst mit dem ersten Dokumentbedarf eingebunden. Die Wiederverwendung der Dokumentablage löst nicht die noch offene Ausgestaltung revisionssicherer Archivierung. Alfresco Community Edition ist als führende Dokumentakte festgelegt; ihre API-Anbindung erhält einen schmalen anwendungseigenen Vertrag. CAF.Documents bleibt unverändert, ein notwendiger Zwischenablage-/Übergabepfad ist explizit zu bestimmen.

Zammad übernimmt das bestätigte operative Ticketing. ContractManager referenziert Tickets und zeigt benötigte Statusauskünfte, besitzt aber weiterhin fachliche Fallentscheidungen zur Logo-Überwachung und Lizenzbezüge. Zuständigkeiten, Kommunikation und Wiedervorlagen werden nicht parallel nachgebaut. Der PO hat am 24.10.2026 den ersten Adapter im ContractManager und den dauerhaften Integrationszustand in dessen bestehender Datenbank bestätigt. Zammad-Betrieb bleibt getrennt; UZ kann später den technischen Adapter mit eigener Instanz/Konfiguration verwenden. ADR-06 und CM55 begrenzen den Schnitt; Implementierung und Providerabnahme stehen aus. Die Integration verwendet REST und nachvollziehbare Rückmeldungen; Zammad-Webhooks können verzögert oder mehrfach eintreffen und benötigen Wiederholungsschutz sowie periodischen Abgleich.

Erster ausführbarer Schnitt

Am 11.10.2026 hat der Product Owner das Grundgerüst im Erscheinungsbild des HearingPortals beauftragt. Der interne Eingangsvertrag ist inzwischen durch PO am 20.10.2026 in CM12 abgenommen; externe Providerfragen bleiben in CM11 offen. Im damaligen Stand vom 11.10.2026 fehlte der XML-Vertrag (RAL-LL-CM-12); die Umsetzung begann deshalb nicht mit dem Import, sondern mit den Teilen, die ohne externe Zulieferung prüfbar sind. Stand seit 11.10.2026:

Das Katalogmodell ist vorläufig (ADR-04). Seine Umbaukosten nach dem XML-Vertrag sind bewusst in Kauf genommen (Kapitel 11). Die Rollen-/Operationsmatrix ist in RAL-LL-CM-7 am 15.10.2026 fachlich abgestimmt. Ihre technischen Grants und Freigabe-/Objektguards bleiben in den Fachstories umzusetzen.

Umsetzung in fachlich prüfbaren Schritten

Ein sinnvoller fachlicher Durchstich nach dem Grundgerüst umfasst den XML-Import und die Zuordnung von Produkt, Testveröffentlichung und Ergebnis, Firmenzuordnung, Produktauswahl, Antragseinreichung, erneute Zustimmung nach Änderung und getrennte Freigabe. Die importierte Referenz und die Berechtigung des Antragstellers werden dabei getrennt geprüft. Manuelle Ergänzung bleibt ein kontrollierter Ausnahmeweg bei fehlenden Daten. Darauf können Lizenz-/Rechnungsübergabe, Erweiterungen und Prozesse der Logo-Überwachung und des Beschwerdemanagements aufbauen. Dies ist eine Abhängigkeitsbetrachtung, keine bestätigte Releaseplanung.

Jeder Durchstich muss positive und negative Objektberechtigung, fachliche Transitionen, Concurrency, Audit, Providerfehler und tatsächliche UI-Bedienung nachweisen. Ein technischer Durchstich mit einem Providerstub ist noch keine Integration in RALs Betriebsumgebung. Die Story-Entwürfe und Qualitätsszenarien liefern die Grundlage für die spätere Aufteilung.

05. Bausteinsicht

Ist-Stand und vorgeschlagene Grenze

Seit dem 11.10.2026 gibt es den ersten ausführbaren Schnitt: Grundgerüst (RAL-LL-CM-67), Anmeldung im eigenen Realm (RAL-LL-CM-3) und die interne Katalogrecherche (RAL-LL-CM-13). Die dafür angelegten Projekte stehen im Abschnitt Angelegte Projekte und Abhängigkeiten; ihre Nachweise sind offen. Die übrige Bausteinsicht bleibt ein Vorschlag zur Zuständigkeit innerhalb CAF.Applications.RAL.LogoLicense.ContractManager; sie beschreibt für alle anderen Bereiche keine angelegten Projekte, Entities oder Datenbanktabellen.

Die 18 Quellkomponenten aus LL-S23 sind gemäß ADR-01 höchstens eine Vorlage für Epics. Die folgende Tabelle benennt fachliche Zuständigkeiten; sie verlangt keinen separaten technischen Baustein für jeden Eintrag. Konkrete Featuregrenzen werden aus abgestimmten Anwendungsfällen entwickelt. Datenmodelle bleiben Vorschläge und Schnittstellen werden je Providervertrag geprüft. Die bereits ausdrücklich bestätigte Modulverantwortung Rechnungswesen wird durch diese Klarstellung nicht neu zugeschnitten.

Berichte sind zunächst lesende Anwendungsfälle ihrer fachlichen Owner. Vorlagen, Kommunikation und Dokumentreferenzen gehören zum jeweils auslösenden Prozess; ein eigener Baustein entsteht erst, wenn der konkrete Zuschnitt seine Unabhängigkeit rechtfertigt. Der spätere Host ist Composition Root und Migrationshost ohne eigene Fachentities oder Fachregeln.

Der Katalog verantwortet Import und lokale Abbildung, nicht die Durchführung von Produkttests oder die Erzeugung von Testurteilen. Diese fachliche Verantwortung bleibt bei Stiftung Warentest. Der XML-Import gehört damit zur Grundlage der Antragsprüfung. Der am 20.10.2026 ausdrücklich beauftragte technische Dateiimport liegt im vorhandenen Catalog-Feature und Host-Seedweg; ein weiteres Projekt entsteht nicht. Die spätere Nutzerklärung ergänzt einen persistenten manuellen Zuordnungsbestand und eine interne Eingangs-/Erledigt-Ansicht. Regelmäßiger Providertransport und Benachrichtigung bleiben offen. Importierte Quellfassungen sind unveränderbar; eigene Metadaten werden getrennt gepflegt (ADR-05).

Angelegte Projekte und Abhängigkeiten

Umgesetzt seit 11.10.2026. Die technischen Grundgerüstnachweise stehen in RAL-LL-CM-67; die DoD-Gesamtabnahme bleibt offen. Alle Pfade relativ zu applications/RAL/LogoLicense/ContractManager; der Namensraum beginnt jeweils mit CAF.Applications.RAL.LogoLicense.ContractManager.

Abhängigkeitsrichtung: Der Host komponiert Shell, Authorization, Catalog, LogoMonitoring, CAF.Modules.Authentication und CAF.Modules.UI.Blazor. Die Shell kennt nur Contracts, Authorization.Contracts und den UI-Baukasten. Innerhalb eines Features zeigen Runtime und Blazor auf die eigenen Contracts, nie umgekehrt; Blazor-Projekte referenzieren keine Runtime. Authorization referenziert Catalog.Contracts und LogoMonitoring.Contracts, um Rollen die Katalogberechtigung zu geben und aktive Importempfänger über einen schmalen Contract zu lesen. Der Catalog-Worker verwendet ABP BackgroundWorkers/Emailing; Authorization besitzt den nativen Konten-/Rollen-/Grantzugriff, Catalog keine fremde Runtime oder Tabelle. Es gibt genau einen UI-Baukasten je Produkt. Kein ContractManager-Projekt referenziert ein HearingPortal-Projekt und umgekehrt; CAF.Modules.Documents wird noch nicht verwendet. Shell, Rückmeldungen und UI-Baukasten sind Kopien der HearingPortal-Fassung (ADR-03).

Vorläufiges Katalogmodell

Der interne Eingangsvertrag ist durch PO am 20.10.2026 in RAL-LL-CM-12 abgenommen. Das Modell bleibt hinsichtlich offener externer Identitäts-/Lizenzsemantik begrenzt (ADR-04). Die bisherigen vier Aggregate sind FullAuditedAggregateRoot<Guid> mit ConcurrencyStamp und gehören dem Feature Catalog. Die technische Quellabbildung vom 20.10.2026 ergänzt Identitäts-, Revisions- und Prüfdatensätze im selben Feature; Quellrevisionen werden nur angehängt. Fremdschlüssel bestehen nur innerhalb des Features.

Die vier bisherigen Fachaggregate tragen ihre Herkunft Imported, Manual oder Synthetic und einen vom internen Schlüssel getrennten Quellwert. Für Imported besteht keine globale Eindeutigkeit der Quell-ID: Wechsel sind laut Benutzer bekannt, Recycling ist offen. Der ausdrücklich konfigurierte CM11-Datei-Seed ergänzt importierte Daten neben dem synthetischen Entwicklungs-Seed. Nach ADR-05 ist Manual keine zulässige neue Testdatenquelle. Direkt editierbar sind nur eigene Metadaten; die Import-Zuordnung bestätigt die Übernahme unveränderter Quellbelege.

Technische Quellabbildung (20.10.2026). Weder XML-ID noch Name sind laut Nutzerklärung verlässlich. CatalogSourceRecord bindet drei einmal vergebene interne GUIDs; eine bestätigte Fortführung übernimmt eine neue Fassung auf genau diese Produkt-, Veröffentlichungs- und Ergebnisobjekte und ergänzt eine CatalogSourceRevision, auch bei geänderter Quell-ID oder geändertem Namen. Die Revision bewahrt die jeweils damaligen Quellwerte. Eine ausdrücklich neue Testanlage erhält eigene interne IDs. Vorige Revisionen und eigene CM14-Metadaten bleiben erhalten. Bis zur bestätigten Provideridentität erhält jeder neue interne Test seine eigene Veröffentlichung; URL/Datum/ID-Präfix begründen keine gemeinsame Veröffentlichung. Künftige Vertragsgrundlagen benötigen die konkrete Quellrevision zusätzlich zur stabilen internen ID. Quellenreferenzen Ähnlichkeit/Produktgleich, Eigenschaften, Preis und Lizenzlaufzeit werden erhalten, ohne sie fachlich zu interpretieren oder relationale Produktgleichheit abzuleiten. Vollvalidierung, Lieferwiederholung und SQL-Nachweisgrenzen: CM11-Teilschnitt.

Zuordnungsprüfung (CM11). Eine Erstbefüllung ohne bekannten importierten Testbestand legt die internen IDs an; genau ein aktueller vollständiger Hash-Treffer ist unverändert. Sonst liefert ein indizierter Analyzer höchstens fünf Vorschläge aus Name/Anbieter, eindeutigem prüfzifferngültigem GTIN-Text und Veröffentlichungs-/Testmerkmalen. Score und Quell-ID sind keine automatische Verknüpfung; Notenwerte begründen keine Identität. Jede geänderte und jede neue/unklare Fassung einer Folgelieferung wird gemäß verbindlicher Benutzerentscheidung als CatalogXmlPendingItem gespeichert. Auch eine reine Notenkorrektur ändert bis zur ausdrücklichen Freigabe weder aktuelle Projektion noch Katalognote. Alte/neue Gesamt-, Gruppen- und Einzelurteile sind im Vergleich deutlich sichtbar; sie können Grundlage eines Produktaufdrucks sein. Lieferung und Prüffälle werden in derselben Importtransaktion erhalten. Die Seite /katalog/importe zeigt Eingang/Erledigt, vergleicht Quellfelder und verlangt ausdrücklich bestehender Test, neuer Test oder Zurückstellen. Serverpermission RALLL.Catalog.Import, aktuelle Pending-Concurrency und erwartete Zielrevision schützen jede einzelne atomare Entscheidung. Quellwerte bleiben nicht editierbar; keine technische Outbox.

Eigene Metadaten (CM14). Der schmale Vertrag ICatalogMetadataAppService pflegt die interne Notiz am Produkt (CatalogProduct.InternalNote, höchstens 4000 Zeichen nach Zeilenumbruch-Normalisierung) und die Suchkategorien (WebCategory: normalisierter Name, vollständige Code-Menge). Er nimmt keine importierten Felder entgegen und verlangt für jede Methode das eigene Recht RALLL.Catalog.Metadata (Admin und Referent); das Rechercherecht allein öffnet keine Notiz. Schreibvorgänge prüfen die gelesene ConcurrencyStamp; eine reine Änderung der Code-Zuordnung schreitet die Version des WebCategory-Aggregats über ABPs Navigationserkennung ebenfalls fort. Quellkategorie-Codes und der Namensschlüssel NormalizedName liegen in der binären Collation Latin1_General_100_BIN2, damit Recherche, Existenzprüfung und eindeutiger Index ordinal vergleichen; der eindeutige Index IX_RALLLWebCategories_NormalizedNameUnique ersetzt den bisherigen Namensindex. Die Änderung wird innerhalb derselben Unit of Work als lokales Ereignis (CatalogProductNoteChanged, CatalogSearchCategoryChanged) übergeben. Der produktive CM15-Empfänger persistiert den Metadatenübergang atomar in RALLLCatalogMetadataChanges innerhalb derselben Transaktion; bei fehlgeschlagener Historie bleibt auch die Fachänderung aus. Der Notiztext wird nicht als zusätzliche Kopie der Anfrage oder Historienentity ins technische Auditprotokoll übernommen. Historienansicht, Altdatenübernahme und sichere Bereinigung bleiben offen; Umfang und Grenzen stehen in Historie und Aufbewahrung.

Modul Rechnungswesen

Die eigene Modulverantwortung ist durch die Benutzerpräzisierung vom 13.09.2026 bestätigt. Als Arbeitsname dient Billing innerhalb des ContractManagers. Ein vorhandenes Projekt oder eine bereits festgelegte öffentliche API wird damit nicht behauptet. Der Zuschnitt folgt der CAF-Vorgabe Contracts und Runtime; ein eigener Dienst oder eine zweite CAF-Datenbank ist dafür nicht vorgesehen. Das externe Buchhaltungssystem behält seine eigene Buchführung.

Das Modul erhält freigegebene abrechnungsrelevante Daten über schmale Verträge, besitzt den fachlichen Rechnungsstand und koordiniert getrennte Ausgänge:

• E-Invoice-Port: Anbindung der laut Benutzer funktionierenden API. Deren tatsächlicher Umfang, Beleg-/Nummernhoheit, Formate und Fehlervertrag sind vor Umsetzung zu prüfen.
• Buchhaltungs-Port: Übertragung strukturierter Bewegungsdaten und Verarbeitung fachlicher Rückmeldungen; Addison/Connect ist der bisherige Quellkontext. Eine Rechnung als Datei ersetzt diesen Datenaustausch nicht.
• Dokument-/Versandbezug: Rechnungsausgabe in der Alfresco-Akte referenzieren und den vorgesehenen Kundenversand getrennt nachweisen. Ob die vorhandene API Teile davon übernimmt, muss ihr Vertrag zeigen; keine zweite Implementierung vor dieser Prüfung.

Lizenzregeln verbleiben beim Lizenzbereich. Rechnungsnummer, externe API-Kennung, Buchhaltungsreferenz und Dokumentversion sind verschiedene Referenzen. Eine gemeinsame Operation muss nicht deren Kennungen gleichsetzen. Rechnung, Ausgabeverarbeitung, Übergabe und Zahlungsinformation werden als getrennte fachliche Zustände behandelt. Korrekturen behalten Bezug auf den ursprünglichen Beleg.

Eine spätere Wiederverwendung über die CAF-Basis ist auf einen neutralen technischen E-Invoice-Vertrag zu begrenzen. Zuerst wird die vorhandene API geprüft; ein allgemeines CAF-Rechnungswesen oder eine neue Formatimplementierung folgt nicht aus diesem Bedarf.

Bestätigte externe Verantwortungen

Alfresco Community Edition führt die Dokumentakte; Zammad führt Tickets, Zuständigkeiten, Kommunikation und Wiedervorlagen. Beide sind eigenständige Produkte außerhalb des CAF-Modulgraphen. ContractManager-Fall-ID, Zammad-Ticket-ID und Alfresco-Dokument-/Versionsreferenz bleiben getrennt. Ein Fachfall darf nach PO-Bestätigung vom 25.10.2026 mehrere Tickets haben; RAL entscheidet manuell über Dubletten. Ein Ticket gehört höchstens einem Fachfall. Hauptticket für die Wiedervorlage und Zielticket jeder Nachricht werden ausdrücklich gewählt; Umzuordnung bleibt CM55-Vertragsarbeit. Eine identische Nummer in allen Systemen wird nicht vorausgesetzt.

Der ContractManager-Adapter darf Ticketinformationen für die Fachsicht lesen, erzeugt aber keinen zweiten führenden Ticketstatus oder Kommunikationsverlauf. Zammad besitzt operative Abläufe; eine Zammad-Aktion kann eine fachliche Prüfung anstoßen, ersetzt jedoch keine im ContractManager erforderliche Freigabe. Alfresco-Berechtigungen schützen auch direkte Zugriffe auf die Akte.

Der erste Adapter läuft im fachlich zuständigen ContractManager-Feature. Sein technischer Transportteil trennt Zammad-REST und instanzspezifische Mappings von Lizenz-/Fallregeln. Referenzen, dauerhafte Aufträge, Rückmeldungseingang und Abgleichzustand gehören diesem Feature in der bestehenden RALLL-Datenbank; Host nur als Composition Root/Migrationshost. Ein eigener Middleware-Host oder eine weitere Datenbank entstehen nicht.

Eine Ticketreferenz enthält die stabile Zammad-Instanzkennung und die Ticket-ID. Konfiguration und Credentials werden je Consumer gebunden. Eine mögliche UZ-Nutzung gegen eine andere Instanz begründet erst beim konkreten zweiten Consumer die Extraktion des technischen Teils; keine Referenz auf LogoLicense-Runtime oder gemeinsame Fachtabellen. ADR-06 ist entschieden; CM55 bleibt in Vertragsschärfung. Die hier beschriebenen zusätzlichen Bausteine sind noch nicht implementiert.

Wesentliche fachliche Objekte

Die Trennung folgt dem Top-Level Datenmodell, dessen Tabellenvorschläge hier in fachliche Begriffe übersetzt werden.

Antrag und Vertrag jeweils mit Kopf-/Positionsmodell, Kardinalitäten mehrerer Produkte sowie Genauigkeit der Versionsbezüge bleiben offen. Die 5-stellige Antragsnummer und die 6 Zeichen der Lizenznummer sind externe Fachkennungen; interne IDs dürfen nicht mit ihnen gleichgesetzt werden.

Daten- und Abhängigkeitsregeln

Jeder Owner besitzt seine Entities und EF-Konfiguration. Fremde Fachobjekte werden über stabile IDs und schmale Contracts referenziert; keine modulübergreifenden Navigationen, Foreign Keys, Repositories oder direkten SQL-Zugriffe. Relevant für eine Freigabe gespeicherte Werte sind fachliche Momentaufnahmen, keine zweite Stammdatenpflege.

ABP besitzt technische Identity-, Permission-, Audit- und Persistenzmechanismen. CAF.Modules.Documents bleibt die schmale Dateifunktion über ABP File Management. Die bestätigte Alfresco-Akte erhält einen anwendungseigenen Integrationsvertrag; vorhandene CAF-Dateien werden nicht automatisch doppelt geführt oder auf einen neuen Provider umgestellt. Das Produkt speichert fachliche Dokument-/Versionsbezüge und prüft Zugriff. Eine vorübergehende Uploadablage wäre ausdrücklich als solche mit Übergabe, Fehlerstatus und Bereinigung zu definieren. Die vorgeschlagenen documents-, roles-, rights- und generischen History-Tabellen der Quelle werden nicht wörtlich umgesetzt.

Die Graphregeln des ContractManagers setzen eigene Architekturtests unter tests/Architecture durch: Host als Composition Root, Richtung Contracts ← Runtime/Blazor je Feature, keine Kanten zwischen HearingPortal und ContractManager, genau ein UI-Baukasten, Cohesion-Vendor-Bann (keine MudBlazor-, Syncfusion- oder Blazorise-Nutzung). Die repositoryweiten Guards unter tests/Architecture gelten zusätzlich. Neue Bereiche aus der Tabelle oben erweitern diese Regeln im selben Änderungssatz.

06. Laufzeitsicht

Lesart der Szenarien

Die folgenden Abläufe konkretisieren die Prozessübersicht als Architekturentwurf. Sie sind noch nicht implementiert. Fachlich unklare Reihenfolgen, Fristen und Wirkungen werden im Anforderungskatalog entschieden; die hier verwendeten Zustandsbegriffe sind keine freigegebene API oder vollständige Transitionstabelle.

XML-Daten übernehmen und als Antragsreferenz bereitstellen

Der XML-Import ist laut Benutzerpräzisierung vom 13.09.2026 der derzeitige Haupteingang der Test- und Produktdaten; PO-Klarstellung 12.10.2026 legt ihn als einzigen regelmäßigen Testdatenweg fest. Der vorgeschlagene Ablauf konkretisiert FR-LL-061/062/084 sowie die Testdatenprüfung nach FR-LL-022. Er beschreibt noch keinen implementierten Importer und legt keinen Transport oder Ausführungsrhythmus fest.

Die Zuordnung prüft, welches getestete Produkt und welches veröffentlichte Ergebnis gemeint sind. Identität, Unternehmensvertretung, Antragsberechtigung und erlaubte Werbenutzung sind weiterhin separate Prüfungen. Lieferkennung, Schema, Transport, Takt, Voll-/Deltaimport sowie Vorrang und Auswirkung späterer Korrekturen müssen noch abgestimmt werden.

Antrag einreichen und nach Änderung erneut bestätigen

Dieser kundenseitige Ablauf folgt nach Phase 1 der internen Vertragsverwaltung (PO 12.10.2026).

Der PO hat am 15.10.2026 Änderungsklassen, Fassungsbindung, erneute Zustimmung und den Neustart beider Prüfungen bestätigt. Klärung ohne Fachänderung setzt denselben Prüfschritt fort. Phase 1 erfasst den externen E-Mail-/Dokumentbeleg; die spätere Kundensicht folgt gesondert. CM24 führt die vollständige Antrags-, Frist- und Abschlussmatrix; veraltete Zustimmungen/Freigaben berechtigen nicht zur Fortsetzung.

Getrennte Prüfung, Lizenz und Rechnung

Die Erstprüfung betrachtet unter anderem Antragsberechtigung, Produkt, Anbieter, Testfußnoten und zulässigen Zeitraum. Sie nutzt die importierte Referenz, um den beantragten Produkt-/Ergebnisbezug zu prüfen. RAL führt dabei keine erneute Produktprüfung oder Zertifizierung durch, sondern prüft die Voraussetzungen der beantragten Logonutzung. Bei Unklarheiten ist Klärung möglich. Der ergänzende Anforderungskatalog §§4.5/4.17 verlangt die Prüfung durch eine zweite Person vor Genehmigung oder Ablehnung. Die Zweitprüfung soll in der neuen Anwendung und vor Rechnungsstellung stattfinden. Ein fachlich anders geregelter Storno ist davon zu unterscheiden: Vor Genehmigung sind belegte Kundenrücknahme und begründetes Fehlanlage-Storno ohne Zweitprüfung bestätigt (PO 15.10.2026, CM24).

Die Quelle nennt gemeinsame Nummernerzeugung, Rechnungsvorschau und Lizenz-Info-Mail. Der PO bestätigt am 15.10.2026 Lizenzwirksamkeit nach Genehmigung zum vereinbarten Beginn, unabhängig vom Zahlungsstand. Eine fehlgeschlagene E-Mail oder Buchhaltungsübertragung setzt die Fachentscheidung nicht zurück. CM24 trennt Lizenz, Datenvergabe, Ausgabe, Versand, Buchhaltungsannahme und Zahlung. Nummern-/Providerverträge bleiben in CM18/28/30/32 offen.

Die genannten 14 Tage Zahlungsfrist sind eine Quellvorgabe, noch keine vollständige Fristberechnungsregel. Fristbeginn, Kalender, Ausnahmen und Korrekturbelege sind zu bestätigen.

Rechnung ausgeben und Bewegungsdaten übergeben

Die Benutzerpräzisierung trennt diese Aufgaben ausdrücklich. Das Modul Rechnungswesen verwendet einen nachvollziehbaren Rechnungsstand als Grundlage für zwei getrennte Integrationswege:

Die konkrete Reihenfolge zwischen Ausgabe, Kundenversand und Buchhaltungsübergabe bleibt OQ-17. Die Wege dürfen nicht bloß über einen gemeinsamen Status „Rechnung fertig“ gesteuert werden. Schlägt die Buchhaltungsübergabe fehl, bleibt der Beleg erhalten und die Übergabe ausstehend; die Wiederholung erzeugt keine neue Rechnung. Ist die Übernahme nach Timeout ungewiss, wird zuerst anhand der Übergabereferenz abgeglichen, um doppelte Bewegungen zu vermeiden.

Für mehrere Datensätze oder Übergabepositionen werden Annahme/Ablehnung und Abstimmung in der vereinbarten Granularität geführt. Korrektur- oder Stornobelege erhalten eine Beziehung zum ursprünglichen Beleg und eine eigene nachvollziehbare Übergabe. Ein Erfolg auf Transportebene beweist noch keine fachliche Buchung. Die Fähigkeiten und Quittungen der vorhandenen E-Invoice-API sowie des Buchhaltungswegs sind noch nicht untersucht; es wird kein konkretes Format zugesagt.

Lizenz verlängern oder erweitern

Das Konto wählt eine berechtigte Lizenz. Das System ermittelt zulässige Optionen aus Laufzeit, Testveröffentlichung, Modell und gegebenenfalls Freigabe des dritten Jahres. Fehlt eine zulässige Option, zeigt es den Grund. Für ein Upgrade nennt die Quelle frei gewählten oder unmittelbaren Beginn sowie die Verrechnung bereits gezahlter Entgelte.

Der Vorschlag behandelt die Erweiterung als eigenen nachvollziehbaren Antrag mit Referenz auf die bisherige Lizenz. Er speichert die zugrunde liegenden Preis-/Laufzeitwerte und führt Bestätigung, Prüfung und Abrechnung kontrolliert aus. Offene Tarif-, Restlaufzeit-, Steuer- und Verrechnungsregeln verhindern derzeit eine verbindliche Rechenvorschrift.

Dokumentakte und Ticket nachvollziehbar verbinden

Die Systemaufteilung ist am 13.09.2026 bestätigt. Seit 24.10.2026 sind der App-Adapter und seine dauerhafte Datenhaltung in der bestehenden ContractManager-Datenbank durch ADR-06 entschieden. Der Ablauf konkretisiert dieses Zielbild; Providerdetails und Implementierung bleiben gemäß CM55 offen:

1. ContractManager erfasst den fachlichen Vorgang und eine stabile Fallreferenz; ein Lizenzbezug darf bei einem Fall der Logo-Überwachung fehlen. Fachänderung und Übergabeauftrag werden atomar im owning Feature der bestehenden RALLL-Datenbank gespeichert. Der Auftrag bindet Quellreferenz, Operations-ID und Zielinstanz; eine spätere URL-/Zieländerung leitet ihn nicht um.
2. Der Adapter legt das Ticket an oder ordnet ein vorhandenes zu. Bei Timeout wird vor erneutem Anlegen anhand der Korrelation abgeglichen. Ohne belegtes Ergebnis bleibt der Auftrag ungewiss und zur Klärung stehen. Ticket-ID samt Instanzkennung und Fall-ID bleiben verbunden; gleiche Ticket-IDs einer möglichen UZ-Instanz sind andere Objekte.
3. Belege werden in Alfresco übernommen und mit Dokument-/Versionsreferenz dem Fall zugeordnet. Eingehende Ticketanhänge bleiben bis zur erfolgreichen Aktenübernahme als ausstehend sichtbar. Eine spätere Dokumentversion ändert nicht unbemerkt den Stand einer früheren Entscheidung.
4. Mitarbeitende nutzen Zammad für Zuständigkeit, Kommunikation und Wiedervorlage. Fachliche Prüfung und Freigabe erfolgen im ContractManager. Für ein freigegebenes Schreiben zur Logo-Überwachung gibt es genau einen Versandauftrag an Zammad; eine parallele Exchange-Sendung im ContractManager entfällt.
5. Webhooks melden Ticketänderungen. ContractManager prüft Absender, Zuordnung und aktuellen Stand, nimmt authentifizierte Rückmeldungen vor positiver Empfangsbestätigung dauerhaft im owning Feature an, verarbeitet Wiederholungen ohne doppelte Wirkung und zeigt ausgebliebene Synchronisierung an. Ein ergänzender Abgleich fängt nach begrenzten Wiederholungen verlorene Meldungen auf.
6. Ticketabschluss oder Wiedereröffnung werden mit der fachlichen Entscheidung abgeglichen. Ein geschlossenes Ticket erteilt keine Freigabe, erklärt keinen Verstoß als erledigt und ändert keine Lizenz. Unstimmigkeiten führen zu einer sichtbaren fachlichen Klärung.

Die Übergaben über Systemgrenzen sind keine gemeinsame Datenbanktransaktion. Stabile Kennungen, Wiederholungs- und Konfliktregeln sind Teil des Integrationsvertrags; REST allein garantiert keine Idempotenz. Zammad dokumentiert verzögerte und begrenzt wiederholte Webhooks.

Abgelaufene Lizenz prüfen und Fall der Logo-Überwachung bearbeiten

Im folgenden Fachablauf besitzt ContractManager Bewertung und Entscheidungen, Zammad den operativen Arbeitsvorrat, Kommunikation und Wiedervorlagen, Alfresco die zugeordneten Belegstände. Die Tabelle beschreibt den Gesamtprozess über diese Systeme, keine zusätzliche CAF-Ticketoberfläche.

Die fachliche Vorbereitung kann unabhängig vom Zammad-Betrieb beginnen: CM54 konkretisiert Fallanlage, erlaubte Übergänge und Fachhistorie; CM55 klärt Fall-/Ticketzuordnung. Die CM24-Regeln sind fachlich bestätigt; der Nachweisabgleich löst die konkrete CM24-Vorleistung für CM54. Die Readiness des internen Backend-Anlagewegs ist nach bestätigtem Feldvertrag in CM54 festgehalten; die weiteren Eingabe-/Belegwege und die übrigen Integrationsvoraussetzungen bleiben vor ihrer Umsetzung zu prüfen. Der aktuelle Backend-Schnitt liefert Anlage, Lesen und Anlagehistorie; keine Oberfläche oder Providerabnahme. Nach PO-Bestätigung vom 25.10.2026 darf ein Fachfall mehrere Tickets bündeln. RAL prüft Dubletten manuell; gleiche Firma, gleiches Produkt oder gleiche Fundstelle führen zu keiner automatischen Zusammenführung.

Der PO bestätigt am 15.10.2026 getrennte Fristarten: interne Standardwiedervorlage 7 Kalendertage mit begründeter Terminabweichung und Antwortfrist eines Abmahnschreibens 28 Kalendertage ab nachweisbarem Versand, jeweils Tagesende Europe/Berlin ohne Werktagsverschiebung. Der Versandbeginn ersetzt ausdrücklich den älteren Quellenbeginn am Schreibenserstellungsdatum. Vollständige Fall-/Fristen-/Empfängermatrix und Dringlichkeitsstufen stehen in CM24. Automatisierung von Recherche oder Fristablauf autorisiert weder Abmahnung noch Rechtseskalation; diese brauchen eine andere freigebende Person. Fachabschluss/Wiedereröffnung sind begründet durch eine Person möglich; Folgekommunikation und RAL-interne Abrechnung bleiben getrennt. Aus der älteren StiWa-Erledigungskommunikation wird kein heutiger Rückkanal abgeleitet.

07. Verteilungssicht

Aktueller Stand

Stand seit 11.10.2026 (RAL-LL-CM-67, -3, -13, -66 umgesetzt, Nachweise offen): Der ContractManager besitzt einen ausführbaren Host, eine eigene Datenbank RALLL mit Initialmigration und einen eigenen lokalen Entwicklungsstack (siehe Lokaler Entwicklungsstack). Es gibt weder ein Deployment noch provisionierte Endpunkte bei RAL; das Deploy-Setup unter applications/RAL/etc/docker/deploy kennt nur das HearingPortal. HearingPortal und ContractManager sind getrennte Hosts mit getrennten Datenbanken und Realms; die gemeinsame Dokumentationsübersicht ist keine gemeinsame Laufzeit.

Lokaler Entwicklungsstack

Der registrierte Einstieg tools/Test-BrowserGate.ps1 meldet ohne Auftrag NOT_REQUESTED. Browser, axe und Tastatur/Fokus verwenden den kanonischen App-Start mit eigener Run-ID, SQL Server, Keycloak und Mailpit. Die Prozess-Lease und die bestehenden Ownership-Guards schützen Start und automatische Bereinigung. Das Consoleprojekt tests/BrowserGate gehört zur App- und Gesamt-Solution und prüft zehn öffentliche Routen in DE/EN: die beiden neutralen Anmeldeseiten, Impressum, Datenschutz, Cookies, die interaktiven Seiten für verweigerten Zugriff und nicht gefundene Routen sowie die statischen Fehlerseiten 403/404/500. Die Fehlerseiten behalten ihren HTTP-Status; auch Rechtslinks und Rücknavigation werden per Tastatur betätigt. Ein integrierter grüner Lauf des jeweiligen Stands ist gesondert nachzuweisen; Browser-Berechtigungsprüfungen bleiben nicht implementiert und werden abgewiesen.

Vorgesehenes Betriebsbild

Die RAL-Kundenvorgabe setzt dieselbe bei RAL gehostete Keycloak-Instanz voraus. LogoLicense erhält einen eigenen Realm und eigenen OIDC-Client. Die Namen ral-logolicense und ral-logolicense-contractmanager sind lokal umgesetzt und ein Vorschlag an den RAL-Betrieb (ADR-02); produktive Redirect-URIs, Secrets und Provisionierung sind offen. Alfresco Community Edition und Zammad sind selbst gehostete Nachbarsysteme mit eigener Datenhaltung. Die Benutzerentscheidung vom 13.09.2026 bestätigt beide Produkte und ihre Keycloak-Anbindung, noch keine bestimmte Version.

Die Verbindung zwischen Anwendungen auf derselben Infrastruktur begründet keine gemeinsame Fachdatenbank. Ein SQL-Server-Principal für LogoLicense soll nur auf die eigene freigegebene Datenhaltung zugreifen. Auch eine spätere gemeinsame SQL-Server-Instanz ersetzt diese Trennung nicht. Alfresco und Zammad besitzen jeweils eine eigene logische Datenbank, eigene Principals, Migrationen und Sicherung. Ein gemeinsamer PostgreSQL-Server wäre erst nach Prüfung kompatibler Versionen und getrennter Wiederherstellung vertretbar; getrennte Server sind keine Voraussetzung für logische Trennung. CAF erhält keinen direkten Zugriff auf ihre Tabellen. Keycloak behält seine eigene Datenhaltung; bestehende RAL-Konfiguration wird nicht durch einen neuen Beispieldienst ersetzt.

flowchart LR
  KC["RAL Keycloak"] -. "eigener Client" .-> CM["ContractManager"]
  KC -. "eigene Clients" .-> AF["Alfresco Community"]
  KC -. "eigener Client" .-> ZA["Zammad"]
  CM -->|"Fachdaten"| SQL[("SQL Server")]
  CM <-->|"Dokument-API / Versionsreferenz"| AF
  CM <-->|"App-Adapter: Ticket-API / Webhooks"| ZA
  CM <-->|"E-Invoice-Vertrag offen"| EI["Vorhandene E-Invoice-API"]
  CM <-->|"Bewegungsdaten / Rückmeldung"| BH["Buchhaltung"]
  AF --> APG[("Alfresco PostgreSQL")]
  AF --> FILES[("Persistenter Dateispeicher")]
  ZA --> ZPG[("Zammad PostgreSQL")]
  ZA --> ATT[("Ticketanhänge")]

Das Diagramm zeigt Verantwortungs- und Verbindungsgrenzen, keine vollständige Containerliste. Alfresco hält den maßgeblichen Dokumentstand; Anhänge eingehender Zammad-Nachrichten benötigen eine nachvollziehbare Übernahme in die Akte, soweit sie Belege sind. Die Ticketkommunikation bleibt in Zammad; Cross-Links übertragen keine Zugriffsrechte.

Der Alfresco-Dateispeicher benötigt keinen S3-Connector, Object Lock oder WORM. Der Betrieb legt passende Speicherkapazität und Redundanz fest und sichert Content, Repository-Datenbank und Konfiguration getrennt vom laufenden Bestand. Konsistenter Restore und Referenzerhalt sind vor Betriebsfreigabe nachzuweisen; die Speicherwahl allein liefert weder Hochverfügbarkeit noch eine Archivabnahme (ADR-07).

Eine mögliche UZ-Anbindung verwendet eine getrennt konfigurierte Zammad-Instanz mit eigenen Zugängen, Rückmeldebindung und App-Integrationsdaten. Eine Codeextraktion beim tatsächlichen zweiten Consumer verbindet weder Datenbanken noch Instanzen. Die stabile Instanzkennung bleibt Bestandteil der Referenzen/Aufträge, unabhängig von der Basis-URL; neue Zielbestände brauchen eine ausdrücklich geplante Umstellung. Siehe ADR-06. Diese Topologie ist entschieden, aber weder Adapter noch zusätzliche Instanz sind geliefert.

Zammad: Initialisierung, Updates und Recovery

Planungsstand 25.10.2026, beschlossen in ADR-06. CAF-25 liefert inzwischen die lokal geprüfte Bereitstellung. CM72 beginnt auf PO-Auftrag mit einem rein lesenden Instanzprofilvalidator und einer Offline-Vorschau unter etc/zammad und tools/Preview-ZammadProfile.ps1 der App. Die Serverabnahme, mutierende Initialisierung und Adapterbasis sind noch offen.

Die automatische Installation verwendet versionierte Definitionen unter services/zammad. Konkrete RAL-Instanzprofile bleiben beim Kundenbetrieb, LL-Anforderungen und lokale Aufrufwege bei der App. Der normale App-Start prüft nur eine aktivierte Integration; er installiert oder aktualisiert Zammad nicht. Eigene ausführbare Eingaben brauchen erst ihre Registry-/Gatezuordnung; dieser Dokumentensatz registriert keine fiktive Runtime.

Konfiguration: Bootstrap mit einmaligen privilegierten Rechten, wiederholbarer Abgleich eigener Konfigurationsobjekte und Bestandsmigrationen sind getrennt. Eine Migration kann DB-Aktualisierung, Neustart und expliziten Backfill benötigen; ein neues Pflichtfeld gilt nicht rückwirkend als befüllt. Vorschau, Driftprüfung, Migrationsstand und Wiederanlauf gehören zum Vertrag. Runtimezugänge sind minimal berechtigt und unabhängig rotierbar.

Versionen und Freigabe: Ein Instanzmanifest bindet Zammad-Patch/Digests, Upstream-Compose- Commit und Begleitimages, eigene Definitions-/Adapterrevision, Konfigurationsschema und lesbare Job-Payloadversionen. 7.2.2 ist nur der am 25.10.2026 recherchierte Kandidat, kein nachgewiesener Supportstand. Tatsächliche Pins und unterstützte endliche Tupel werden in CAF-19/25 und den Providerproben ermittelt. Updatefolge: Upstream-/Securityhinweise bewerten, Änderungsvorschlag erstellen, isoliert mit Altaufträgen und Recovery prüfen, instanzbezogen freigeben, gesichert ausrollen und nachkontrollieren. Breaking Changes brauchen vorab kompatible Leser beziehungsweise eine kontrollierte Payload-/Datenmigration. Ein Container-Downgrade ohne passenden Datenstand gilt nicht als Rückweg.

LL und später UZ haben getrennte Compose-Projekte, Speicher, Credentials und gewählte Tupel. Ein LL-Update darf UZ weder aktualisieren noch stoppen. Versionierte gemeinsame Skripte sind erlaubt; jede Instanz bindet ihre freigegebene Revision. Gemeinsame Hostwartung bleibt ein gesondertes Risiko. Es gibt keine Zusage unbegrenzt unterstützter Altversionen; Supportfenster und Security-Triage sind vor Betriebsfreigabe festzulegen.

Testumgebung: Synthetische Daten sind der Normalfall. Bei Restoreproben gilt Egress- Quarantäne bereits vor dem ersten Start, danach nur eigene Mail-/Webhooksenken. Neue Testidentität und Credentials verhindern eine Produktionsbindung; die Sperre wird negativ getestet. Echtdatenkopien werden hier weder angelegt noch pauschal erlaubt.

Recovery: App- und Zammad-Sicherung sind nicht automatisch atomar. Vor Restore müssen mutierende Zugänge und Worker gesperrt, laufende externe Versuche abgegrenzt und Rückmeldungen kontrolliert gehalten werden. Sicherungspunkte und eine außerhalb restaurierter Daten geführte Recovery-Generation sichern den Wiederanlauf. Ein neuerer RALLL-Stand kann auf ein im restaurierten Zammad fehlendes Ticket zeigen; im umgekehrten Fall kann Zammad bereits Ticket oder Artikel besitzen, deren App-Auftrag zurückgesetzt wurde. Beide Fälle benötigen Abgleich oder gesperrte Klärung, niemals blindes Wiederholen. Sonstige RALLL-Geschäftsdaten werden nicht pauschal zurückgesetzt; versandte Nachrichten können nicht zurückgerollt werden. Datenbank, Anhänge, Konfiguration und Indexaufbau werden gemeinsam geprüft. RPO/RTO bleiben offen, bis konkrete Werte bestätigt und an Wiederherstellungsproben gemessen sind.

Reihenfolge der Umsetzung

Die Grafik ist aus den Planungsbeziehungen erläutert; die YAML-Vorgänge bleiben führend. Durchgezogene Pfeile bedeuten Startvoraussetzung (blocks), die gestrichelte Kante nur Abschlussvoraussetzung (finish_to_finish). Damit kann CM55 parallel geschärft werden, während CM73 technische Nachweise liefert. Auf PO-Auftrag vom 25.10.2026 darf auch CM72 lokal vor der CAF-25-Serverabnahme beginnen; CAF-25 bleibt seine Abschlussvoraussetzung. Keine Rückkante vom vollständigen CM55-Vertrag auf die technische Probe; kein zyklischer Startblocker.

flowchart LR
  C19["CAF-19 Definition"] --> C25["CAF-25 Bereitstellung"]
  C25 -.-> M72["CM72 Instanzprofil"]
  M72 --> M73["CM73 Providerproben"]
  M73 --> M74["CM74 Adapterbasis"]
  M74 --> M75["CM75 Eingang und Abgleich"]
  M73 -.-> M55["CM55 Fachvertrag"]
  M55 --> M56["CM56 Fachintegration"]
  M75 --> M56
  C25 --> C27["CAF-27 Recovery"]
  M75 --> C27
  C27 --> C26["CAF-26 Updates"]
  C26 --> M76["CM76 Betriebsfreigabe"]
  M56 --> M76

Die vorhandene CM54-Abschlussvoraussetzung für CM56 bleibt erhalten. Der Zammad-SSO-Anteil von CM5 muss für CM76 belegt sein; Alfresco-SSO und der gesamte Monitoringumfang von CM65 blockieren die technische Adapterbasis nicht. CM76 besitzt die minimale zielkonkrete Betriebsabnahme. CM56 behält seinen fachlichen End-to-End-Nachweis; gemeinsame technische Tests zählen dadurch weder als zweite Implementierung noch als automatische Fachabnahme.

Versionsabhängigkeiten und Gegencheck

Die Quellen wurden am 13.09.2026 geprüft; dies ist kein neuer Deploymenttest.

Bei der Bereitstellung Release-/Image-Stände statt beweglicher latest-Tags dokumentieren. Die offiziellen Compose-Beispiele sind eine Ausgangsbasis; ihre Testwerte, offenen Ports und Sicherheitsvereinfachungen werden nicht zur produktiven Konfiguration. Eine Dimensionierung braucht Dokument-/Ticketmengen, Dateigrößen, gleichzeitige Nutzer und die gewählte Such-/Vorschaufunktion.

Keycloak-Clients und Berechtigungsgrenzen

Die frühere Realm-Trennung zwischen HearingPortal, EnvironmentalLabel und LogoLicense bleibt bestehen. Für zunächst LogoLicense-exklusive Fremdsysteme ist die Einbindung über eigene Clients im LogoLicense-Realm ein Vorschlag. Sollen Alfresco oder Zammad mehrere Sparten bedienen, ist die Realm-/Kontenzuordnung gesondert festzulegen; die gemeinsame Keycloak-Instanz allein bietet kein realmübergreifendes SSO. Diese Topologie ist OQ-11, keine bereits eingerichtete Konfiguration.

Browseranmeldung und technische API-Identität sind getrennt. Servicezugriffe erhalten minimale Rechte und passende Audience; ein Benutzer-Token wird nicht ungeprüft an andere Clients weitergereicht. Zammad-Rollen/Gruppen und Alfresco-Berechtigungen müssen ebenso wie ABP-Objektrechte den zulässigen Zugriff begrenzen. Externe Antragsteller erhalten durch ihren Portalzugang keine Agentenrolle und keinen allgemeinen Zugriff auf Ticketing oder DMS. Kontenzuordnung erfolgt stabil und kontrolliert; keine automatische Verknüpfung privilegierter Bestandskonten nur per E-Mail.

Entwicklung und Konfiguration

Der ContractManager folgt den bestehenden PowerShell-Lifecyclewegen und Docker-Compose-Konventionen mit eigenen, aus dem HearingPortal abgeleiteten Skripten (siehe Lokaler Entwicklungsstack); einen zweiten Startweg gibt es nicht. Der vorhandene Schnelleinstieg bleibt technische Referenz, seine HearingPortal-Endpunkte und Zugangskonfigurationen sind keine LogoLicense-Vorgaben. Die gemeinsame Ableitung der Lebenszyklus-Skripte ist eine bewusste Dopplung (Kapitel 11).

Pflichtkonfiguration aktivierter Provider muss beim Start validiert werden. Secrets und Lizenzwerte bleiben außerhalb des Repositorys; Diagnose zeigt nur SET oder MISSING. Provisionierung, Datenmigration und laufende Anwendung benötigen ihrem Zweck entsprechende, getrennte Berechtigungen. Produktive Integrationen dürfen in Testumgebungen keine realen Rechnungen, Schreiben oder Kundennachrichten auslösen.

Noch fehlende Betriebsentscheidungen

Die NFR-Quelle fordert zuverlässige Integration, Überwachung und Archivierung, nennt aber keine hinreichenden SLO-, Wiederanlauf- oder Kapazitätswerte. Diese werden nicht durch erfundene Zahlen ersetzt.

08. Querschnittliche Konzepte

Identität, Unternehmensbezug und Berechtigung

Technische Identität folgt dem stabilen OIDC-Subject innerhalb der konfigurierten Vertrauensbeziehung. E-Mail ist Kontaktinformation, kein Schlüssel für automatische Verknüpfung oder Privilegierung. Keycloak authentifiziert; ABP Identity und Permission Management bilden lokale Konten und technische Grants ab. Das Produkt prüft Rolle, aktive Firmenzuordnung, Vollmacht und Objektzugriff.

Die Confluence-Bezeichnungen „normaler Benutzer“, „Supervisor“ und „Administrator“ reichen nicht für eine umsetzbare Rechtematrix. Insbesondere sind Firmenverwaltung, Agenturvertretung, Erstprüfung, Zweitprüfung, Rechnung, Fallfreigabe zur Logo-Überwachung und Administration getrennt zu prüfen. Seit PO-Entscheidung vom 12.10.2026 besitzt Admin in Phase 1 ausdrücklich auch fachlichen Inhaltszugriff; Referent darf alle fachlichen Aktionen, keine System-/Rollenadministration. Die spätere Kundenrolle bleibt auf eigene Daten und Neubestellungen begrenzt. Fachliche Invarianten und getrennte Prüfungen werden durch diese Rollenrechte nicht aufgehoben (CM7, ADR-05).

Selbstregistrierung und E-Mail-Validierung sind fachlich beschrieben; deren konkreter Keycloak-/ Provisionierungspfad ist offen. Das Feld password_hash aus dem Datenmodell begründet keine eigene Passwortspeicherung. Ebenso erzeugt die gemeinsame Keycloak-Instanz kein realmübergreifendes SSO; siehe Randbedingungen.

Für Alfresco und Zammad gilt dieselbe Trennung von Authentifizierung und Zugriff. Vorgesehen sind eigene Keycloak-Clients und kontrollierte Kontenzuordnung. Bei Zammad bleibt die OIDC-UID auf einem stabilen Subject; automatische E-Mail-Verknüpfung bleibt aus, und automatische Neuanlage ist für interne Agentenkonten zu sperren oder gezielt einzuschränken. Gruppen-/Agentenrechte werden ausdrücklich provisioniert. Für Alfresco sind Subject-/Benutzerzuordnung und die Rechte der Repository-API sowie der tatsächlich verwendeten Oberfläche zusammen zu prüfen.

Login, Logout, Kontosperre und Entzug von Gruppen-/Objektrechten sind pro System nachzuweisen. Ein Keycloak-Logout belegt noch nicht den Widerruf von API-Zugangsdaten oder lokalen Rechten. Direkte DMS-/Ticketzugriffe dürfen den fachlichen Zugriffsschutz nicht umgehen. Die Details und die Realm-Zuordnung bleiben in OQ-11; Kapitel 7 führt den Gegencheck.

Anmeldung im eigenen Realm

Umgesetzt seit 11.10.2026; die vier ACs und ihre technischen Nachweise sind mit !272 am 16.10.2026 integriert. Verbindliche Aufbewahrungs-/Löschangaben und rechtliche Freigabe bleiben offen; Details und quellengebundene Prüfstände stehen in RAL-LL-CM-3:

• Der Host meldet über CAF.Modules.Authentication ausschließlich am Realm ral-logolicense mit dem vertraulichen Client ral-logolicense-contractmanager an (Code-Flow mit PKCE S256). Aussteller und Zielgruppe werden geprüft; Token eines anderen Realms oder Clients, etwa ral/ral-qualitymarks des HearingPortals, werden abgewiesen.
• Ein lokales Konto wird ausschließlich über das Subject (sub) gefunden, nie über die E-Mail. Ein angemeldetes Subject ohne verknüpftes lokales Konto erhält kein automatisch angelegtes Konto, keine Rolle und keine Permission; es landet auf der neutralen Seite „Kein Zugang eingerichtet“ statt auf einer Fehlerseite. Ein sub, das bereits mit einem anderen lokalen Konto verknüpft ist, wird ebenso behandelt. Ein Token ohne sub und ein gestörter Identitätsanbieter enden auf der neutralen Seite „Anmeldung derzeit nicht möglich“. In allen Fällen wird nichts angelegt oder geändert.
• Der Host entscheidet in zwei Phasen. Beim Start der Anmeldung (Challenge, die Weiterleitung zu Keycloak von /Account/Login aus) fängt er ab, dass Keycloak nicht erreichbar ist, bevor eine Ausnahmeseite entsteht. Beim validierten OIDC-Rücksprung (Callback) entscheidet er, bevor ein externes Anmelde-Cookie entsteht und bevor der Konto-Rückruf von ABP läuft; dieser fiele sonst auf E-Mail-Verknüpfung oder Registrierung zurück.
• Zwei neutrale Seiten trennen fehlenden Zugang von einer technischen Störung: Ein Subject ohne verknüpftes lokales Konto landet auf „Kein Zugang eingerichtet“ (/zugang-nicht-eingerichtet), jede andere Ablehnung auf „Anmeldung derzeit nicht möglich“ (/anmeldung-nicht-moeglich). Keine der beiden Seiten nennt den Grund, auch die Adresse nicht. Jede Ablehnung schreibt genau einen strukturierten englischen Warnungseintrag des Hosts: Ereignis 4101 ContractManagerLoginRefused mit Grundcode, Phase (Challenge oder Callback), Korrelationskennung, Fingerabdruck des Subjects (die ersten 16 Hex-Ziffern seines SHA-256) und höchstens dem Typnamen einer Ausnahme, nie E-Mail, Name oder Subject im Klartext.

• Die Verknüpfungsregeln liegen im Feature Authorization: Kontosuche (ContractManagerAccountLinkReader), Verknüpfung (KeycloakExternalLoginLinker) und Entwicklungs-Seed arbeiten über zwei schmale Ports (IKeycloakSubjectLinkStore, IContractManagerAuthorizationSeedStore) mit Adaptern auf ABP Identity. Kein Codepfad sucht über E-Mail oder Benutzername. Ihre Ereignisse:

• Keycloak-Gruppen und -Rollen sowie Rechte aus anderen RAL-Anwendungen gewähren im ContractManager nichts. Rechte entstehen nur aus lokalen ABP-Rollen der Permission-Gruppe RALLL.
• Die Rollen RALLLAdministrator und RALLLCaseOfficer tragen die gelieferten Fachgrants; CM14 ergänzt die Metadatenpflege, der am 20.10.2026 beauftragte CM11-Prüfschnitt RALLL.Catalog.Import für beide Rollen. Die am 15.10.2026 fachlich abgestimmte CM7-Matrix bestätigt Admin und Referent; technische Rollenverwaltung, Firmen-/Objektgrants und Freigabeguards sind in den jeweiligen Fachstories noch umzusetzen.
• Lokale Entwicklungskonten legt der Authorization-Seed nur in der Entwicklungsumgebung und nur für konfigurierte Subjects an und verknüpft sie über ihr Subject (Synthetische Entwicklungsdaten).
• Die Seite „Kein Zugang eingerichtet“ bietet eine Abmeldung an. Sie beendet auch die Keycloak-Sitzung einer Person ohne verknüpftes Konto, damit sie sich mit einem anderen Konto anmelden kann, statt sofort wieder auf derselben Seite zu landen. Mangels lokaler Sitzung gibt es dabei kein id_token_hint; Keycloak lässt die Abmeldung deshalb bestätigen. Die Seite „Anmeldung derzeit nicht möglich“ ist anonym erreichbar und bietet einen erneuten Anmeldeversuch und die Abmeldung an.
• Eigene Cookie-Namen (eine Definition in ContractManagerCookieNames, die auch die Cookie-Seite liest): .CAF.RALLL.Identity.Application (Anmeldung), .CAF.RALLL.Identity.External (Ergebnis der externen Anmeldung) und .CAF.RALLL.Antiforgery. Damit melden HearingPortal und ContractManager einander auf localhost nicht ab. OIDC-Korrelations- und Nonce-Cookies (Name mit Zufallsanteil je Rücksprung) und das Kultur-Cookie behalten ihre Standardnamen.
• Bekannte lokale Einschränkung: CAF.Reauthenticate aus CAF.Modules.Authentication und XSRF-TOKEN von ABP tragen keine produkteigenen Namen und werden auf localhost mit dem HearingPortal geteilt. Eine Abmeldung in der einen Anwendung verlangt bei der nächsten Anmeldung in der anderen erneut die Zugangsdaten (Kapitel 11).

Produkt-/Ergebnisreferenz und Datenherkunft

Der Produktkatalog bildet die von Stiftung Warentest stammenden Daten für RALs Lizenzprüfung ab. Der XML-Haupteingang ist eine Benutzerpräzisierung vom 13.09.2026; Confluence belegt den Import- und Abgleichbedarf, spezifiziert aber damit noch kein XML-Schema oder Transportprotokoll. Am 20.10.2026 hat der Benutzer eine echte Lieferung für einen Datei-Seeder in Entwicklung und Produktion freigegeben (LL-S26); deren technischer Teilschnitt steht in CM11.

Produkt, Testveröffentlichung und zugehöriges Ergebnis benötigen nachvollziehbare Referenzen. Importkennung und interner Fachschlüssel dürfen nicht ohne Kenntnis der Quellsemantik gleichgesetzt werden. Der vollständige Item/ID-Wert ist innerhalb der beobachteten Lieferung eindeutig, aber laut Benutzer ebenso wie der Name nicht verlässlich stabil. Wiederverwendung ist unbekannt; seltene einzelne ID-Wechsel sind keine Stabilitätsgarantie. Auch sein Präfix vor ! liefert keine fachliche Identität. Importierte Quellkennungen dürfen mehrfach vorkommen. CatalogSourceRecord besitzt eine eigene interne Identität mit dauerhaften Produkt-, Veröffentlichungs- und Ergebnis-GUIDs. Eine bestätigte Fortführung behält diese drei IDs auch bei geänderter externer Kennung, geändertem Namen oder geänderter Note. Jede neue Faktenfassung wird als unveränderbare CatalogSourceRevision mit RawXml-SHA-256, Versionsnummer, Lieferkennung und UTC-Importzeit erhalten; die Recherche erhält die aktuelle Projektion. Eine zukünftige Vertragsgrundlage muss ihre konkrete Quellrevision zusätzlich binden. Der technische Import erhält einen persistenten Prüfbestand für unsichere Zuordnung nach FR-LL-062; die Benachrichtigung und Regeln, welche Korrekturen bestehende Verträge berühren, bleiben offen.

PO-Klarstellung 12.10.2026: Testdaten kommen ausschließlich aus regelmäßigem Import und bleiben als übernommene Quellfassungen unveränderbar. Admin/Referent pflegen nur getrennte eigene Metadaten; CM14 liefert interne Notiz und eigene Suchkategorien. Weitere manuelle Kataloge sind möglich, aber keine manuell angelegten Testfakten. Historische Vertragsgrundlagen dürfen durch neue Lieferungen nicht umgedeutet werden. Unabhängig von der Datenherkunft bleiben Kontoidentität, Firmenvertretung und Antragsberechtigung separat zu prüfen; ein Katalogtreffer reicht für keine dieser Berechtigungen aus.

Das vorläufige Katalogmodell setzt diese Regeln als bisherigen Leseschnitt um: Jeder Datensatz trägt seine Herkunft (Imported, Manual, Synthetic) und einen optionalen Quellschlüssel getrennt vom internen Schlüssel. Webkategorien gruppieren Quellkategorie-Codes nur für die Suche; Quellkategorie und Herkunft eines Produkts bleiben unverändert, und ein Produkt erscheint unter jeder Webkategorie, die seine Quellkategorie enthält. Die Oberfläche zeigt die Herkunft an. Manual ist Teil des bisherigen Modells, keine Freigabe zum manuellen Anlegen von Testfakten. Die in ADR-05 beschlossene Trennung eigener Metadaten ist mit CM14 für interne Notizen und Suchkategorien umgesetzt: Der gesonderte Schreibvertrag nimmt keine Importfelder entgegen und verlangt RALLL.Catalog.Metadata. Der am 19.10.2026 direkt beauftragte CM15-AC-7-Teilschnitt ergänzt atomare Fachhistorie für diese Änderungen; Historienansicht, Altdatenübernahme und Bereinigung bleiben offen.

Der technische Dateiimport vom 20.10.2026 validiert die komplette Lieferung vor dem transaktionalen SQL-Schreiben. Identische Lieferkennung und identischer Inhalts-Hash sind auch nach einem neueren Import eine Wiederholung ohne Änderung; anderer Inhalt unter derselben Kennung wird als Konflikt abgewiesen. Eine neue Kennung darf bei Rückkehr zu einer früheren Faktenlage eine weitere Revision erzeugen. Fehlende Items lösen keine Löschung aus. Der Seed läuft ausschließlich bei RALLL:CatalogXmlSeedFile; RALLL:CatalogXmlSeedDeliveryId ist optional, sonst gilt der Dateiname. Entwicklung und Produktion verwenden denselben expliziten Weg.

Eine Erstbefüllung ohne bekannten importierten Testbestand legt interne Identitäten an. Genau ein aktueller vollständiger Item-Hash-Treffer ist unverändert. Sonst bietet die indizierte Analyse höchstens fünf Kandidaten nach Name/Anbieter, eindeutigem prüfzifferngültigem EAN-/GTIN-Text und Veröffentlichungs-/Testmerkmalen an. Externe ID ist nur ein schwacher Hinweis, Notenwerte kein Identitätssignal. Scores entscheiden keine Zuordnung. Der Benutzer fordert verbindlich manuelle Bestätigung jeder Änderung: Auch eine reine Noten-, Preis- oder Laufzeitkorrektur geht in den dauerhaften CatalogXmlPendingItem-Bestand. Bei Folgeimporten gibt es nur für einen eindeutigen unveränderten aktuellen Hash-Treffer keinen Prüfbedarf. Neue/unklare Testfassungen werden ebenfalls zur Entscheidung erhalten. Lieferung und Prüfbestand werden innerhalb derselben Importtransaktion geschrieben; keine technische Outbox. Bis zur ausdrücklichen Übernahme bleiben bestätigte Projektion und Katalognote unverändert.

Die interne Import-Zuordnung unter /katalog/importe zeigt je Lieferung Eingang und Erledigt mit Kandidaten und Quellfeldvergleich. Admin/Referent mit serverseitig geprüftem RALLL.Catalog.Import wählen ausdrücklich bestehenden Test, neuen Test oder Zurückstellen. Eine freie interne Test-ID kann statt eines Vorschlags geprüft werden; Quellwerte bleiben unveränderbar. Ein einzelner Resolve ist atomar und prüft aktuelle Pending-Concurrency sowie die erwartete Zielrevision. Ein Konflikt verlangt Nachladen und erneute bewusste Zielwahl. Alte und neue Gesamt-/Gruppen-/Einzelurteile samt Noten stehen deutlich sichtbar im Vergleich, weil sie laut Benutzer Grundlage eines Produktaufdrucks sein können. Eine bewusste Zuordnung und Änderungsübernahme ist erforderlich; frühere Quellrevisionen werden nicht überschrieben. Zuordnung/Zurückstellen werden nur mit bestehender interner Bearbeiter-ID und UTC-Zeit nachvollziehbar; zusätzliche Namen, E-Mails oder IP-Adressen entstehen nicht.

Pro neuem internem Test wird bis zur Providerbestätigung eine eigene Veröffentlichung projiziert; gleiche URL, Datum oder Quellpräfix führen nicht zur Zusammenlegung. Namen, Anbieter, Urteiltexte, Eigenschaften, Preis, Lizenzlaufzeit und Referenzattribute bleiben unverändert im Quellbeleg, auch bei leeren Namen/Anbietern oder rein textuellen Noten. Nur ein abschließendes (2,1)-artiges Urteil auf der Skala 0,5–5,5 erhält eine zusätzliche numerische Projektion. Soft-Hyphens dürfen ausdrücklich im Suchtext entfernt werden, nicht aus Quelle oder Identität. Ähnlichkeit und Produktgleich werden vollständig gegen dieselbe Lieferung validiert und im Beleg erhalten; sie erzeugen keine automatische fachliche Gleichheitsentscheidung. Keine URL wird abgefragt. Parser-/Analyse-/SQL-/Proxy-/UI-/Migrationsnachweise des mit MR !300 integrierten Schnitts stehen in CM11/CM71; Commit-/CI-Bindung ist dort nachgetragen. Der anschließend akzeptierte Tagesbetrieb und Meldungsversand sind im aktuellen Arbeitsstand implementiert; UI-Upload, eigener CAF-SFTP-Transport und die Gesamtabnahme bleiben offen.

Tagesbetrieb des XML-Imports

Die Benutzerentscheidungen LL-S29 und der anschließend ausdrücklich akzeptierte CM11-Betriebsentwurf sind im aktuellen Arbeitsstand umgesetzt. Der bestehende Windows-Dienst behält SFTP und veröffentlicht vollständige, unveränderliche Dateien unter je Lieferung eindeutigem XML-Endnamen. CAF liest keine temporären Eingänge und fragt keine XML-URLs ab. RALLL:CatalogXmlImport:Enabled ist standardmäßig false; der aktive Host registriert den Catalog-eigenen ABP-Worker. Der Wartungs-/Migrationsweg ist gesondert und startet keinen Liveworker.

Verarbeitung beginnt ab 00:00 Uhr Europe/Berlin; der Worker nimmt später fertige Dateien am selben Tag an und holt ausstehende Arbeit nach Neustart nach. Berlin-Kalendertage, einschließlich 23-/25-Stunden-Tagen, steuern die standardmäßig acht Versuche je Datei/Tag; Zeitpunkte sind UTC von ABP Clock. Standardwerte: Poll 30 s, Claim 300 s, Backoff ab 30 s bis 900 s, Dateibatch 25. Ein leerer Eingang ist ohne zugesagte Lieferfrist gesund. Fehlerhafte Verzeichniskonfiguration und unsichere Einträge lösen einen sicheren Vorfall aus; eine einzelne Datei blockiert andere fertige Lieferungen nicht. Persistierte Eingangsepisoden deduplizieren fortdauernde Ausfälle, überleben Meldungsausfall und erlauben nach belegter Wiederherstellung eine neue Episode. LastObservedAtUtc schützt gegen ältere, verzögert eintreffende Beobachtungen paralleler Hosts.

Datei-Claims besitzen Token und Lease. Der echte SQL-Fence nimmt eine exklusive Zeilensperre innerhalb der tatsächlichen Import-/Archivtransaktion; alte Besitzer dürfen nach Übernahme keinen Fachabschluss oder Dateischritt mehr ausführen. Hash und bestätigte Archivphase bleiben getrennt vom unveränderlichen CM71-Lauf erhalten. Eigene Archivkopien werden atomar veröffentlicht, abweichende Ziele nie überschrieben. Identischer Zielinhalt erlaubt Replay und Recovery nach Dateiverschiebung vor SQL-Quittierung. Ein Archivfehler verändert keinen bestätigten SQL-Erfolg. Alte offene Laufstarts werden mit tatsächlicher Beobachtungszeit gemeldet, ohne Endzeit oder Rollback zu erfinden. Regulärer Dateizugriff wird am Öffnungspfad geprüft; eine reale Windows- Symlink-Gegenprobe ist mangels OS-Recht weiterhin ungeprüft, kein übersprungener Pflichtfall.

Persönliche dauerhafte Importmeldungen erscheinen auf /katalog/importe. Authorization liest aktive lokale RALLLCaseOfficer mit aktuellem RALLL.Catalog.Import über Catalog Contracts und native ABP-Konten/Rollen/Grants; Catalog greift auf keine fremde Runtime oder Tabelle zu. Vor Zugriff und jedem Mailversuch wird die aktuelle Berechtigung geprüft. Fehlende E-Mail verhindert nur die Kopie; fehlende Empfänger und ausstehende Ermittlung bleiben als berechtigter Operationsstatus sichtbar. Admin ist kein Ersatzempfänger. Fachliche Prüffälle erhalten eine getrennte interne Arbeitsinformation; ihre offene Menge bleibt von technischen Fehlern getrennt.

Erste Fehlernotiz und erster Mailversuch erfolgen sofort ohne Bündelungsfenster, auch nachts und für sämtliche aktuellen Empfänger. 08:00 Uhr ist erwartbarer menschlicher Reparaturbeginn, keine garantierte Frist oder Bereitschaft und keine nächtliche Meldungspause. Der Mailweg nutzt ABP IEmailSender, aktuelle Kontosprache und DE/EN-Klartextvorlagen. SMTP-Annahme ist keine Postfachzustellung; ein NullEmailSender zählt nicht als Annahme. Ungewisser Ausgang wird ohne automatischen Zweitversand erhalten; erneuter Versand verlangt ausdrückliche Aktion. Recovery verwendet eigene 25er-Anteile für abgelaufene Versandclaims, neue Meldungen, fällige Fehlschläge und vorübergehend unerreichbare Empfänger, damit keine Gruppe die andere verdrängt. Der erste Vorfall hat kein solches Empfängerlimit. Meldungs-/SMTP-Ausfälle rollen den bestätigten Import nicht zurück. Vollständiger Host-/SQL-Ausfall gehört zur externen Überwachung/CM65.

Produktive Pfade, Hostverfügbarkeit, Konten/SMTP, aktuelle integrierte Nachweise und rechtliche Freigabe sind weiterhin separat abzunehmen. Keine Antrags-/Vertragsbindung oder Produktivbefüllung wird aus diesem Arbeitsstand abgeleitet.

Fassungen, Zustimmungen und Vier-Augen-Prinzip

Eine Zustimmung soll auf die tatsächlich angezeigte Antragsfassung und Bedingungen verweisen. Eine Prüfung soll die konkrete Fassung, die handelnde Person, Zeitpunkt und Ergebnis festhalten. Zustimmungsrelevante Änderungen dürfen nicht unter einer bestehenden Freigabe verschwinden. Der PO bestätigt diese Fassungsbindung sowie konkrete Änderungsklassen und Rücksprünge am 15.10.2026 in CM24.

Optimistische Concurrency verhindert, dass parallel Bearbeitende eine inzwischen geänderte Fassung überschreiben. Fachliche Transitionen haben benannte Operationen mit Quellzustands-, Rechte- und Datenguards. Bestätigte Rücksprünge stehen in CM24; Vertretung handelt mit eigener Identität und eigenen Rechten nach CM7 und hebt die zweite Person nicht auf. Ein frei editierbares Statusfeld ist kein Ersatz. Die serverseitige Umsetzung bleibt in den Folge-Specs nachzuweisen.

Dokumente, Historie und Aufbewahrung

Für Vorgangsdokumente in Release 1 legt CM40 fest: Inhalte über CAF.Modules.Documents (PO 08.10.2026), jeder gespeicherte Stand unveränderlich, neue Stände nur durch Fachereignisse mit Vorgängerbezug; die Alfresco-Übergabe bleibt CM47.

Die NFR-Quelle fordert Versionierung, Historisierung und revisionssichere Archivierung. PO 12.10.2026 bestätigt Interesse an vorhandenen historischen Daten; deren konkreter Übernahmeumfang, Fristen und zulässige Korrekturen bleiben offen. Interne Historie ist für Admin und Referent fachlich zugänglich; daraus folgt kein Kundenrecht auf interne Notizen/Akteurdaten. Technische Zugriffshistorie, fachliche Änderungsbegründung und Dokumentversion sind unterschiedliche Nachweise. Die Quellforderung zur Löschung alter Produkte bzw. stornierter Anträge muss mit bestehenden Referenzen und Aufbewahrung abgeglichen werden.

Der Anforderungskatalog §§3.1–3.3 fordert einen AuditTrail für relevante Benutzer- und Systemereignisse. Diese unnummerierten Vorgaben gelten zusätzlich zu den 100 funktionalen Anforderungen. Die Ereignisabdeckung umfasst damit mehr als fachliche Statuswechsel; die genaue Matrix von Aktionen, Zugriffen und Systemereignissen, zulässigen Inhalten, Zugriffsschutz und Aufbewahrung ist zu präzisieren. Vor einer eigenen Auditkomponente wird geprüft, welche dieser Nachweise ABP Auditing bereits liefert und welche fachliche Ergänzung erforderlich ist.

Verarbeitungsinventar des gelieferten LL-Schnitts

Quellenabgleich am 19.10.2026, Grundlage a75184a4 plus CM15-AC-7-Arbeitsstand. Am 20.10.2026 um den beauftragten CM11-Datei-/Prüfschnitt ergänzt; dessen SQL-/Proxy-/UI-Nachweise sind mit MR !300 integriert und in CM11/CM71 commitgebunden nachgetragen. Das Inventar allein ersetzt keine ausführbaren Nachweise. Der akzeptierte Betriebsausbau ist im aktuellen Arbeitsstand implementiert; neue integrierte Nachweise und produktive Betriebs-/Datenschutzfreigabe bleiben separat offen. Das Inventar beschreibt technische Felder und vorhandene Zugriffspfade, keine abgeschlossene datenschutzrechtliche Freigabe. Native ABP-Schemafelder sind mögliche Speicherfelder; nicht jeder Ablauf befüllt sie. Maßgeblich sind Hostkontext, Migrationsmodell, Hostkonfiguration, Logging-Konfiguration und Programmstart.

Verarbeitungsinventar für XML-Import und Importmeldungen

Die folgenden Felder sind im aktuellen Arbeitsstand persistiert. Alle sechs Aggregate besitzen zusätzlich ihre native Id, ConcurrencyStamp und ExtraProperties; die Anwendung legt dort keine weiteren Kontakt-, XML-, Pfad- oder freien Exceptionkopien ab. Abgeleitetes CanRetry wird nicht persistiert. Das Feldinventar ist technischer Ist-Stand, keine Rechts- oder Betriebsfreigabe.

InputDirectory, ArchiveDirectory und ErrorDirectory sind getrennte Host-Dateispeicher mit vollständigen Lieferdateien; sie liegen außerhalb Repository und Browser-Speicher. Der vorhandene Windows-Dienst schreibt fertig veröffentlichte Eingänge, der CAF-Host liest/archiviert seine übernommenen Dateien, berechtigter Betrieb besitzt zusätzlich Dateizugriff. Archiv-/Fehlerdateien und Sicherungen haben eigene Zweck-, Zugriffs- und Aufbewahrungskriterien, die RAL/Betrieb konkret festlegen muss. Archiv- und Fehlerdateien löscht CatalogImportRetention 90 Tage nach Abschluss, aber nur bei übereinstimmendem ContentHash; eine fremde Datei unter gleichem Namen bleibt und wird gezählt. Jede Datei hat ihre eigene Referenz (CatalogXmlImportArchivedFile), die Bereinigung läuft auch bei abgeschaltetem Import und löst eine Referenz nur bei nachweislich fehlender Datei in erreichbarem Verzeichnis. Eingangsdateien und Sicherungen werden nicht berührt. Quelle im SQL und vollständige Lieferdatei sind verschiedene Belege; Pflicht zum Revisionserhalt erlaubt keine unbegrenzte Kopie personenbezogener Datei-/Diagnosedaten.

SMTP verarbeitet die jeweils aktuell aufgelöste Empfängeradresse/Kontosprache und den minimalen Klartextinhalt über den konfigurierten E-Mail-Dienst. Dessen konkrete Betriebsstelle, reale Log-/Queue-/Backup-Speicher und Aufbewahrung sind separat zu inventarisieren/freizugeben; SMTP-Annahme ist nur Transportannahme. Intern verbleiben Referenz, Versuch und Ergebnis. AbpAuditLogs und AbpAuditLogActions dürfen diese Vorgänge nicht zusätzlich mit Roh-XML, Kontaktadresse, Mailbody, Dateipfad oder freiem Exceptiontext duplizieren. Die Entitäten und Meldungs-AppServices sind vom zusätzlichen Audit ausgeschlossen; reale Auditsentinels prüfen Datenminimierung. Es entsteht kein neuer Browser-Speicher und keine Browser-Drittanfrage.

Die öffentliche LL-PrivacyPolicy ergänzt tatsächliche DE/EN-Abschnitte für Quellen, Importentscheidungen, Läufe, Meldungen, Empfänger und SMTP. Controller-/Datenschutzkontakte bleiben vorhandene LL-Konfiguration. HearingPortal ist Strukturvorlage, keine Übernahme seiner Fristen oder Rechtsfreigabe. Gesetzlicher Maßstab: LL-S30. Konkrete Rechtsgrundlagen, Betriebszugriffe und die Freigabe der tatsächlich verwendeten Hinweise durch die zuständige RAL-Stelle bleiben offen; die Aufbewahrungsfristen der Importdaten stehen seit dem 22.10.2026 im Hinweis und werden stündlich vom CatalogImportRetentionWorker durchgesetzt. Es gilt keine pauschale Jahresfrist für alle Importdaten, sondern die Frist je Datenart oben.

Die Fachhistorie dokumentiert einen beobachteten Übergang. ChangedAtUtc und ActorId bezeichnen die ausgeführte Änderung; PreviousValue erfindet weder frühere Autorenschaft noch Entstehungszeit des erstmals beobachteten Wertes. Keine rückwirkende Altdatenbefüllung. Die Tabellen besitzen keine fachfremden Foreign Keys und führen keine Kontaktkopie für den Akteur. ABP-Audit speichert in einer neuen UoW und kann Speicherfehler standardmäßig unterdrücken; deshalb ersetzt es den atomaren Fachnachweis nicht. Der kleine Catalog-Empfänger nutzt die vorhandene lokale Ereignisnaht ohne neue Layer. Details, ABP-Quellrevision, SQL-Proben und Grenzen: CM15-Teilschnitt.

Die noch fehlende Bereinigung verlangt einen produktiven Contracts-Port der zuständigen Antrags-/Vertragsmodule: vollständige Bezüge, spätester Abschluss, laufender/ungeklärter Status und Schutzsperren samt belastbarem Versionsstand. Fehlende Provider oder leere, unvollständige Antworten sind keine Freigabe. Schutzprüfung und Bereinigung müssen gegen neue Referenzen serialisiert werden; ein vorheriger erfolgreicher Read genügt nicht. Das ist nach dem Faktenvertrag implementierbare Entwicklungsarbeit. Die bestätigten fünf Jahre werden nicht erneut zur Kundenentscheidung gestellt. Verbindliche Entscheidungen für die anderen Datenarten und Rechtstextfreigabe bleiben bei person-001/zuständiger RAL-Stelle.

Alfresco Community Edition ist am 13.09.2026 als DMS gewählt; am 25.10.2026 wurde normaler persistenter Dateispeicher bestätigt (ADR-07). Schutz durch Rollen, konkrete Versionen, Aufbewahrungs-/Löschregeln, nachvollziehbares Audit und getrennte Sicherungen mit Restore bleibt erforderlich. S3, Object Lock, WORM und absolute Löschsperren gegenüber sämtlichen Administratoren gehören nicht zur Zusage. Die Entscheidung ersetzt keinen Nachweis der verlangten Archivqualität. Dokumentakte und Zammad-Anhänge benötigen einen eindeutigen Übergabevertrag: Ticketkommunikation bleibt in Zammad, maßgebliche Belege werden mit Herkunft und Version in Alfresco referenziert. Löschung im Ticket darf nicht unbemerkt die Aktenaufbewahrung umgehen; Kopien unterliegen einer abgestimmten Aufbewahrungs-/Bereinigungsregel.

Nummern, Geld und Zeit

Interne IDs bleiben unabhängig von Antrags-, Vertrags- und Rechnungsnummer. Die Quelle nennt 5-stellige Antragsnummern und eine Lizenznummer aus zwei Jahresziffern, zwei Buchstaben und zwei Ziffern. Zeichenvorrat, Kollisionsregeln, Jahreswechsel und Migration sind noch zu bestimmen.

Entgelte, Steueranteile und Währung brauchen explizite Dezimal- und Rundungsregeln. Historische Rechnungs-/Vertragswerte dürfen nicht durch spätere Tarif- oder Stammdatenänderungen umgedeutet werden. Die Quelle wechselt bei Modellnamen zwischen „Premium“ und „Gold“; daraus wird kein stiller zusätzlicher Tarif abgeleitet.

Persistierte technische Zeitpunkte verwenden UTC und ABP-Clock-Abstraktionen. Fachliche Datumswerte wie Vertragsende, Rechnungsfälligkeit und Wiedervorlage benötigen eine eigene bestätigte Kalenderregel. „14 Tage“, „zwei Monate“ und „vier Wochen“ werden nicht ohne diese Regel in technische Dauern übersetzt.

Integration, Kommunikation und Überwachung

Jede Integration gehört zu einem konkreten Fachprozess und erhält einen schmalen Port mit austauschbarem Adapter. Konfiguration, Timeout, Fehlerklassifikation, Korrelation und Wiederholung sind explizit zu behandeln. Nach einem ungewissen Ergebnis ist externe Abstimmung erforderlich, bevor eine Rechnung oder Nachricht erneut erzeugt wird. Ein technischer Versandauftrag und eine bestätigte Zustellung sind verschiedene Zustände. Für Kommunikation zur Logo-Überwachung führt Zammad den Versand; ContractManager liefert freigegebenen Inhalt und Empfängerbezug. Andere Produktnachrichten können weiterhin über den vorgesehenen Exchange-Adapter gehen. Eine Nachricht erhält genau einen Versandowner; weder Webhook noch Retry darf eine zweite Sendung auslösen.

Für Zammad legt CM55 den ersten App-Adapter mit dauerhaftem Auftrags-/Rückmeldungsspeicher (Outbox-/Inbox-Prinzip) in der bestehenden RALLL-Datenbank fest. Die App speichert Übergabeabsicht und auslösende lokale Änderung atomar; externe Wirkung bleibt außerhalb der SQL-Transaktion. Wiederholungsschutz, Concurrency und Abgleich berücksichtigen App-Owner, Zielinstanz und Operationsreferenz. Ein ungewisser Ausgang führt zuerst zum Abgleich, bei fehlendem Beleg zur kontrollierten Klärung. Weder eine Suche ohne Treffer noch ein erneut gestarteter Worker beweist das Ausbleiben einer externen Wirkung. Der konkrete Providervertrag steht noch aus.

Instanzkennung, Endpunkt, Credentials und Provider-Mappings werden je Consumer gebunden; Webhook-Herkunft wird am Empfangspfad verifiziert. Unbekannte Instanzen und fremde Referenzen werden abgewiesen. Ein Konfigurationswechsel darf alte Aufträge nicht auf eine andere Instanz umlenken. Diese Grenze ermöglicht UZ mit eigener Instanz und eigener App-Datenhaltung; sie aktiviert keine allgemeine Multi-Tenancy und keine gemeinsame Ticketdatenbank.

Die Prozessquelle nennt Dummy-Anträge als Monitoring. Als Umsetzungsvorschlag dienen eindeutig synthetische Datensätze, Testempfänger und isolierte Providerwege. Sie dürfen keine Kundenkommunikation, realen Buchhaltungsposten oder rechtlich wirksamen Schreiben auslösen. Kennzahlen dürfen nicht durch Testvorgänge verfälscht werden.

Die fachlich getrennte Laufhistorie aus CM71 erfasst jeden begonnenen Dateiimportversuch, auch Wiederholungen, abgewiesene Dateien und technische Fehler. Der Laufbeginn wird vor Dateizugriff und Validierung gespeichert. Erfolgreicher Abschluss und Lieferübernahme verwenden dieselbe Fachtransaktion; eine nachgewiesene Rücknahme erhält ihren Fehlerabschluss außerhalb dieser Transaktion. Nach ungewissem Commit wird der dauerhafte Zustand nachgelesen. Ohne belegbaren Abschluss bleibt der Beginn unvollständig sichtbar; ein Neustart erklärt keinen Erfolg. Die ursprünglichen Empfangsmengen bleiben bestehen, auch wenn später Prüffälle entschieden werden. Die interne Übersicht zeigt den aktuellen offenen Lieferbestand zusätzlich und getrennt. Serverseitige Paginierung und Filter verwenden das bestehende Importrecht. Tagesfilter werden in Europe/Berlin einschließlich Zeitumstellung nach UTC übersetzt; Zeiten nennen Zone und Offset. Ein Leseretry startet keinen Import. SFTP, Upload und Alarmierung bleiben gesonderte Arbeit.

Synthetische Entwicklungsdaten

Für den heutigen Umfang umgesetzt seit 11.10.2026; lokale und serverseitige Seed-/Realm-Nachweise sind am 15.10.2026 erbracht (RAL-LL-CM-66, Server-/Seed-Prüfstand 4d8fe663). Der Gesamtprozess aus AC-2 bleibt offen: Die Realm-Benutzer dev-admin, dev-sachbearbeitung und dev-user sind als synthetisch gekennzeichnet, haben Adressen unter @example.invalid und feste, nur in diesem Realm verwendete Subjects. Die synthetischen Katalogdaten tragen die Herkunft Synthetic, Quellschlüssel mit Präfix SYN- und erfundene Namen ohne reale Marken. Jeder der drei Teile hat seinen eigenen Schalter:

RALLL:SeedDemoData schaltet also nur den Katalog; wer ihn abschaltet, behält die Entwicklungskonten. Beide Seeds sind idempotent und schreiben nur in die Datenbank RALLL. dev-user hat bewusst keine Rolle und belegt, dass ohne lokale Zuweisung kein Recht entsteht. Ein durchgängiges synthetisches Szenario für Registrierung, Antrag, Freigabe, Rechnung und Erweiterung wächst mit diesen Funktionen.

Oberfläche und Fehlerbehandlung

Geführte Eingaben, Vorschauen und erkennbare Statusangaben des ContractManagers werden mit Cohesion umgesetzt. Die eigenen Oberflächen von Alfresco und Zammad bleiben Fremdprodukt-Oberflächen. Der ContractManager verlinkt berechtigte Vorgänge und zeigt benötigte Fachauskünfte; er baut ihre Bedienoberflächen nicht nach. Loading, Empty, Fehler mit Retry, Forbidden, Validierung, Speichern und veralteter Bearbeitungsstand werden sichtbar unterschieden. Tastaturbedienung, Fokus, Labels und verständliche Fehler gehören zur späteren Abnahme. Ein ausgeblendeter Button ersetzt niemals die serverseitige Prüfung.

Der Spec-Entwurf LL-UI-01 konkretisiert die geplante Übernahme gemeinsamer Seiten- und Bedienmuster aus HearingPortal sowie eines RAL-Kundenprofils. Neutrale Regeln sollen in den zentralen Konventionskatalog eingehen; LogoLicense-Stories verlinken die zutreffenden Muster und beschreiben ihre fachlichen Abläufe. Der Entwurf übernimmt keine neuen gemeinsamen Konventionen und legt keine technischen Modulgrenzen fest. Browsergruppen folgen weiterhin der ausdrücklichen Beauftragung.

Die interne Katalogliste stellt nach explizitem Reset oder Chipentfernung den Fokus auf ihre sichtbare Ergebniszusammenfassung. Erst der zur aktuellen Filterrevision gehörende Leseabschluss verbraucht diesen Auftrag; überholte Ergebnisse oder Fehler tun dies nicht. Neuere Eingaben, Kategorie-/Datumsänderungen und Dispose verwerfen ihn. Ein aktueller Ladefehler behält den Vorrang des bestehenden Fehlerziels. Der Sucheingabecallback gibt sofort zurück; sein eigener entprellter Auftrag beobachtet Abbruch und Fehler. Die öffentliche Blazor-Komponente FocusOnNavigate setzt nach echter Navigation den Fokus auf die Seitenüberschrift. Toolbar, Seitengröße und Spaltenoptionen verwenden den registrierten UP-66-Fokusring im eigenen Grid-Scope; dieser Produktbehelf bleibt bis zum belegten Upstreamabbau aktiv. Der reale DE/EN-Nachweis samt Gegenproben steht in RAL-LL-CM-13.

Die Metadatenpflege führt nach erfolgreichem Nachladen eines Konflikts den Fokus zur erhaltenen Notiz beziehungsweise zum Kategoriennamen. Nach einem erfolgreichen Lade-Retry folgt er zum Notizfeld beziehungsweise zur Aktion für eine neue Kategorie. Die ausblendenden Retry-Schaltflächen hinterlassen dadurch keinen Fokus auf dem Dokumentkörper. Fehler behalten den Vorrang der Fehlerregion; ein initialer Leseabschluss fordert keinen zusätzlichen Fokus an.

Erscheinungsbild und Lokalisierung

Umgesetzt seit 11.10.2026; technische Nachweise vorhanden, DoD-Gesamtabnahme offen (RAL-LL-CM-67): Die Shell ist eine produkteigene Kopie der HearingPortal-Shell (ADR-03). Sie verwendet dieselbe Cohesion-App-Shell, dieselben vier Themes (Orange und Neutral, jeweils hell und dunkel, Standard Orange hell), die Modul-Rail aus dem Hauptmenü, Sprach-, Farb- und Hell/Dunkel-Bedienung in der Kopfleiste, Rechtslinks sowie Fehler-, Nicht-gefunden- und Kein-Zugriff-Seiten. Eigen sind Anwendungsname „RAL Logo Lizenz“ / „RAL Logo Licence“ und der Speicherschlüssel ralll-cohesion-theme für die Darstellungswahl.

Die Oberfläche ist zweisprachig: Kulturen de-DE (Standard) und en, alle Ressourcen mit identischen Schlüsseln in beiden Sprachen, Sprachwechsel über den ABP-Kultur-Endpunkt. Sichtbare Texte kommen ausschließlich aus Ressourcen; Specs mit sichtbaren Texten wählen deshalb das DoD-Profil Lokalisierung. WCAG 2.1 AA, Tastaturbedienung und sichtbarer Fokus gehören zum DoD-Profil UI/Cohesion und gelten für alle Seiten; Pflichtnachweis sind dort Komponententests, Browsernachweise für die interne Arbeitsoberfläche erfolgen nur nach Beauftragung. Rechts-, Fehler- und Kein-Zugriff-Seiten sowie die beiden neutralen Anmeldeseiten sind öffentlich erreichbar und damit kundenseitig: Für sie gilt zusätzlich das DoD-Profil Barrierefreiheit, dessen Wahl die Browsergruppen axe und Tastatur/Fokus beauftragt (SPEC-CAF-3). Das App-BrowserGate erfasst diese zehn öffentlichen Routen in DE/EN und bei angeforderter Tastaturgruppe zusätzlich die interne Katalogbedienung. Ausgeführte Nachweise und ihre Quellrevisionen stehen in RAL-LL-CM-67, -3 und -13. Die Implementierung allein bestätigt keine DoD-Gesamtabnahme. Das bestehende Barrierenregister führt tatsächliche Befunde, Korrekturen und noch offene Nachweise (DOD-A11Y-03). Die Rechtstexte (Impressum, Datenschutz, Cookies) sind vorläufig und brauchen die Freigabe der zuständigen Stelle für LogoLicense; die Freigabe ist kein technischer Nachweis.

Logo-Überwachung: interner Fachkern

CM54 beginnt mit Fallanlage, Lesen und Anlagehistorie im Feature LogoMonitoring. Seine Tabellen RALLLLogoMonitoringCases und RALLLLogoMonitoringCaseEvents liegen in der bestehenden App-Datenbank. Der Host trägt die Migration; keine zweite Datenbank. Befundbeschreibung/Fundstelle können personenbezogene Angaben enthalten. Firma, Produkt und Lizenz sind zunächst optionale Befundtexte, keine bestätigten Fremdidentitäten. Technische Daten sind Auftragskennung, Fallbezug, Akteur und UTC-Erfassungszeit; das Beobachtungsdatum bleibt ein davon getrenntes Kalenderdatum.

Empfänger sind interne Admins/Referenten mit aktuellen nativen ABP-Grants. Jeder Leseweg fordert RALLL.LogoMonitoring, Anlage zusätzlich .Create; kein Kundenzugriff. Keine Inhalte an Zammad, Alfresco oder Mail und kein automatischer URL-Abruf in diesem Schnitt. Generisches Parameter-/Entity-Auditing ist für diese Daten ausgeschaltet; die Fachhistorie speichert ein minimales Anlageereignis atomar mit dem Fall. SQL-Sensitive-Data-Logging bleibt aus. Die Auftragskennung macht technische Wiederholungen eindeutig; sie ersetzt keine manuelle Dublettenentscheidung. Der interne Dienst besitzt keine Update-/Delete-/Statusoperation. Dies ist kein Schutz gegen Datenbankadministratoren. Aufbewahrung, Löschfreigabe, Auskunft und fachlicher Belegvertrag sind vor Produktivnutzung mit RAL zu konkretisieren.

09. Architekturentscheidungen

Entscheidungsstand

Dieses Kapitel ist der Entscheidungsabschnitt des arc42-Entwurfs. Es enthält vorhandene Vorgaben und neue Vorschläge mit ihrer jeweiligen Herkunft. Es erklärt keinen Vorschlag durch seine Dokumentation zur freigegebenen Entscheidung. Fachliche Fragen und ihre späteren Antworten bleiben im Anforderungskatalog; eine parallele Entscheidungsliste wird nicht angelegt.

Quellen für gesetzte Vorgaben: AGENTS.md, Entwicklungsleitfaden, RAL-Realm-Trennung. Fachlicher Ausgangspunkt: Prozessübersicht und Top-Level Datenmodelle.

ADR-01 Quellkomponenten als fachliche Vorlage

Datum: 06.10.2026. Status: Bestätigte Auslegung aufgrund Benutzerklarstellung.

Kontext: LL-S22/23 beschreiben historische Prozess-/Funktionsvorschläge. Die 18 Komponenten der Neuentwicklung wurden vor einer tragfähigen heutigen Modulabgrenzung zusammengestellt. Ihre Funktionsinhalte sollen erhalten bleiben, ohne den Entwurf in diesen technischen Schnitt zu pressen.

Entscheidung: Der Quellkomponentenschnitt dient höchstens als Vorlage für Epics. Er bestimmt keine Projekte, ABP-Module oder Layer. Datenmodelle sind fachliche Vorschläge. Externe Integrationen werden für jeden Anwendungsfall hinsichtlich Bedarf, Ownership, Richtung und Providervertrag geprüft.

Konsequenzen: Kapitel 5 führt vorgeschlagene fachliche Zuständigkeiten; konkrete technische Grenzen entstehen erst aus verfeinerten Anwendungsfällen und den bestehenden CAF-Regeln. Bereits bestätigte Entscheidungen zu Rechnungswesen, Alfresco, Zammad und Keycloak gelten weiter. Die PDF-Abdeckung verbindet Quellthemen mit vorhandenen Epics/Stories. Sie ist weder eine Modulfreigabe noch ein Implementierungsnachweis.

ADR-02 Eigener Realm und Clientname

Datum: 11.10.2026. Status: Lokal umgesetzt; Namensvorschlag an den RAL-Betrieb, Bestätigung und Provisionierung bei RAL offen.

Kontext: Die Kundenvorgabe verlangt einen Realm je Sparte in derselben RAL-Keycloak-Instanz (RAL-Realm-Trennung); Kennungen sollten beim Aufbau der Anwendung festgelegt werden. Das HearingPortal nutzt Realm ral und Client ral-qualitymarks. Keycloak-Kennungen (Client-, Mapper- und Benutzer-IDs) sind instanzweit eindeutig.

Entscheidung: Realm ral-logolicense (Anzeigename „RAL Logo Lizenz“), vertraulicher Client ral-logolicense-contractmanager mit Code-Flow und PKCE S256, Redirect /signin-keycloak, Rücksprung nach Abmeldung /signout-callback-keycloak und Audience-Mapper auf die eigene Client-ID. Spätere Clients desselben Realms folgen dem Muster ral-logolicense-<anwendung> (etwa für Alfresco und Zammad). Realm-Objekte erhalten keine mit dem HearingPortal geteilten festen Kennungen. Der gemeinsame Realm-Abgleich wird nur parametrisiert; Client, Mapper und Entwicklungskonten gleicht ein app-eigenes Skript ab. Gruppen sind nur die gemeinsamen Basisgruppen; Produktrollen bleiben lokale ABP-Rollen. Ein Provisionierungsclient entsteht erst mit Registrierung oder Kontenverwaltung (RAL-LL-CM-2, -6).

Konsequenzen: Lokale Stacks beider Anwendungen können nebeneinander laufen, ohne Realm ral oder den HearingPortal-Client zu verändern. Die Konfigurationsschlüssel Authentication:Authority und Authentication:ClientId zeigen auf den neuen Realm. Im RAL-Kundenbetrieb braucht der Infrastruktur-Tier einen zweiten Realm-Abgleich; das ist vor dem ersten Deployment zu klären.

ADR-03 Erscheinungsbild als produkteigene Kopie der HearingPortal-Shell

Datum: 11.10.2026. Status: Arbeitsentscheidung für das Grundgerüst (RAL-LL-CM-67); fachliche Abstimmung offen.

Kontext: Der Product Owner hat am 11.10.2026 das Grundgerüst im Erscheinungsbild des HearingPortals beauftragt. Shell, Themes, Rückmeldungen und UI-Baukasten liegen heute im HearingPortal-Produkt; eine Referenz darauf würde HearingPortal-Fachverträge mitziehen und die Produktgrenze brechen. Eine Extraktion in CAF.Modules.UI.Blazor ist nach der gemeinsamen Extraktionsbedingung G-1 bis G-8 erst abgeschlossen, wenn das HearingPortal den gemeinsamen Baustein nutzt und seine Fassung entfernt ist. Das hätte den Auftrag um eine HearingPortal-Umstellung erweitert.

Entscheidung: Der ContractManager übernimmt Shell, Layout, Themes, Chrome-Styles, Rückmeldungen, Rechts- und Fehlerseiten sowie die benötigten Teile des UI-Baukastens als produkteigene Kopie unter eigenem Namensraum, mit eigenem Anwendungsnamen und Theme-Speicherschlüssel. Kein Projekt referenziert das andere Produkt. HearingPortal-Fachseiten und -Funktionen werden nicht übernommen.

Extraktionskandidaten: Theme-Namen und -Umschaltung, CohesionNavMapper samt Modul-Rail, Sprachumschaltung (AbpLanguageSwitch), Shell-Layout und Navigation, Seitenrahmen und Filterleiste, Rückmelde-Host, Fehleransicht und Fehlerseiten-Konfiguration, Rechtsseiten mit Rechtsangaben-Optionen sowie die Chrome-Styles. Für jeden Kandidaten gilt dieselbe Regel: eine gemeinsame Implementierung, Umstellung beider Produkte und Entfernen beider Kopien im selben überprüfbaren Änderungssatz (G-1 bis G-8), nie eine dritte Kopie im Framework.

Konsequenzen: Schnelle, risikoarme Lieferung ohne Änderung am HearingPortal. Bis zur Extraktion sind Korrekturen an der Shell zweimal zu machen; diese Dopplung ist eine technische Schuld. Cohesion-Behelfe werden so übernommen, wie sie im HearingPortal stehen, damit beide Anwendungen gleich aussehen: Was das HearingPortal bereits zurückgenommen hat, wird nicht mitkopiert; was dort noch steht, wird mitkopiert, auch wenn die verwendete Cohesion-Version es nicht mehr braucht. Jede Kopie einer Zone-2-Regel hat eine eigene Zeile im Override-Register und wird zusammen mit ihrem HearingPortal-Gegenstück zurückgenommen. Ein mitkopierter Behelf, den Cohesion bereits überholt hat, ist nach conventions/cohesion-boundary.md in beiden Anwendungen ein bekannter Fehler, bis beide Kopien gemeinsam entfernt sind. Am 11.10.2026 betrifft das die Graustufen-Kontrastregel für Abschnittstitel der Seitennavigation und Brotkrumen-Links (gegen 3.6.3-alpha.0.17).

ADR-04 Vorläufiges Katalogmodell bis zum XML-Vertrag

Datum: 11.10.2026. Status: Interner Eingangsvertrag durch PO am 20.10.2026 mit CM12 fachlich abgenommen; Schreibownership durch ADR-05 präzisiert. Die technische Quellabbildung aus dem Live-Dateischnitt gilt intern. Externe Identitäts-/Lizenz-/Betriebszusagen bleiben separat in CM11 offen; der historische ADR-Titel bleibt zur Referenzstabilität erhalten.

Historischer Kontext vom 11.10.2026: Der XML-Vertrag mit Stiftung Warentest (Schema, Quellschlüssel, Korrektursemantik) fehlt. RAL-LL-CM-11 ist dadurch blockiert. Die Recherche (RAL-LL-CM-13) und spätere Antragsstories brauchen trotzdem ein prüfbares Katalogmodell.

Entscheidung: Ein vorläufiges Modell aus Produkt, Testveröffentlichung, Testergebnis mit Teilergebnissen und Webkategorie (Kapitel 5) mit Herkunft Imported/Manual/Synthetic und vom internen Schlüssel getrenntem Quellschlüssel. Die Webkategorie gruppiert Quellkategorie-Codes, ohne die Quellkategorie zu verändern. Bis zum Import gab es nur synthetische Daten; die Rechercheoberfläche bleibt lesend und nur für Mitarbeitende.

Präzisierung vom 20.10.2026, einschließlich anschließender Nutzerkorrektur: Externe Item/ID und Name sind laut Benutzer nicht verlässlich stabil. Ob Kennungen recycelt werden, ist unbekannt; grob ein bis zwei einzelne Kennungswechsel monatlich sind nur eine Orientierung. Die erste Annahme einer dauerhaften externen Schlüsselbindung ist damit ersetzt. Auch ein Präfix vor ! wird nicht als fachliche Produkt-, Test- oder Veröffentlichungskennung interpretiert. Der CM11-Schnitt ergänzt CatalogSourceRecord als eigene interne Identität, die die eigenständigen GUIDs von Produkt, Veröffentlichung und Ergebnis dauerhaft bindet. Die Quellkennung ist der zuletzt beobachtete, global nicht eindeutige Wert. Eine bestätigte Fortführung erhält die drei internen IDs auch bei später geänderter ID, geändertem Namen oder Note. CatalogSourceRevision hält neue Faktenfassungen unveränderbar mit Versionsnummer, RawXml, dessen SHA-256, Lieferkennung und UTC-Importzeit; damit bleiben frühere Namen/IDs erhalten.

Der erste Import ohne bekannten importierten Testbestand legt interne Identitäten an. Ein eindeutiger aktueller vollständiger Hash-Treffer ist unverändert. Sonst liefert ein indizierter Analyzer höchstens fünf Kandidaten aus Name/Anbieter, eindeutigem validiertem EAN-/GTIN-Text und Veröffentlichungs-/Testmerkmalen. Notenwerte sind keine Identitätssignale, Quell-ID nur ein schwacher Hinweis; Scores lösen keine Verknüpfung aus. Unsichere Fälle werden in CatalogXmlPendingItem persistiert und über eine interne Eingangs-/Erledigt-Ansicht ausdrücklich als bestehender oder neuer Test entschieden beziehungsweise zurückgestellt. Aktuelle Pending-Concurrency und erwartete Zielrevision schützen jede atomare Einzelentscheidung.

Die Vollprobe der echten Lieferung deckte eine quadratische Deduplizierung automatisch erzeugter Entity-Ereignisse in ABP 10.6 auf (UnitOfWork.GetEventsRecords, List.FindIndex). Der Catalog-eigene Adapter am ABP-Port IEntityChangeEventHelper unterdrückt deshalb nur automatische Catalog-Entity-Ereignisse innerhalb der exakt gebundenen Import-Unit-of-Work. Die explizite Quellrevision ist der Importnachweis. Fachliche LocalEvents, andere Entitäten, verschachtelte andere Unit-of-Works und parallele Anfragen behalten ihren normalen Weg; eigene Metadaten und deren Fachhistorie bleiben unverändert. Ein asynchroner Scope wird auch bei Fehlern zurückgesetzt. Die Lieferung bleibt eine einzige Transaktion. Nach dieser Korrektur importierte die isolierte SQL-Vollprobe 19.693 Items mit 81.149 Teilergebnissen in 29,942 Sekunden; der identische Wiederimport dauerte 0,833 Sekunden ohne neue IDs/Revisionen. Diese lokale Messung ist keine Zusage für andere Betriebsumgebungen.

Bis der Provider eine belastbare Veröffentlichungsidentität bestätigt, wird je neuem internem Test eine eigene Veröffentlichung projiziert; gemeinsame URL, Datum oder Schlüsselpräfix führen nicht zur Zusammenführung. Leere Namen/Anbieter sowie fehlende oder rein textuelle Noten werden als Quellfakten erhalten. Preis, Lizenzlaufzeit, Eigenschaften und Gleichheits-/Ähnlichkeitsreferenzen bleiben Rohwerte. Die Herkunft Imported ersetzt keine Aussage zur fachlichen Antragsberechtigung. Die echte Lieferung und die Grenzen des beobachteten Vertrags stehen in CM12.

Präzisierung CM71 vom 20.10.2026: Nach ausdrücklicher Spec-Akzeptanz erhält jeder Importversuch einen Catalog-eigenen Laufdatensatz. Er ist von der idempotenten Lieferung und von Quellrevisionen getrennt. Ein dauerhaft gespeicherter Beginn liegt vor Dateizugriff; erfolgreicher Abschluss und Lieferung werden gemeinsam bestätigt. Fehler nach belegtem Rollback werden separat abgeschlossen. Bei ungewissem Commit wird der dauerhafte Zustand nachgelesen; ohne Beleg bleibt der Lauf unvollständig. Endzustand und Empfangsmengen werden nicht durch Wiederholungen oder spätere manuelle Zuordnungen umgeschrieben. Die vorhandene interne Importansicht erhält geschützte Lesezugriffe, Filter und Paginierung. Keine zusätzliche Importplattform, Outbox, Transportanbindung oder freie Faktenbearbeitung.

Konsequenzen nach interner Abnahme vom 20.10.2026: CM12s Abschluss löst keine Migration oder Datenlöschung aus. Später belegte Providerregeln sind auf Auswirkungen für Felder, Schlüssel und Tabellen zu prüfen und gegebenenfalls gesondert mit Migration umzusetzen. Bestehende Quellrevisionen und eigene Metadaten bleiben geschützt. Fachliche Webkategorien und die Sichtbarkeit für Antragstellende bleiben Folgearbeit (RAL-LL-CM-11, -13). Der Umbau ist als Risiko geführt.

ADR-05 Importfakten, eigene Metadaten und Ausbauphasen

Datum: 12.10.2026. Status: Fachliche Grenze durch Product Owner bestätigt; der erste manuelle Schnitt (eigene Notiz und Suchkategorien, CM14) ist umgesetzt; Dateiimport, Versionsbindung und interne Import-Zuordnung am 20.10.2026 ausdrücklich beauftragt, die übrigen Phasen bleiben offen.

Kontext: Der vorläufige Katalog und der CM14-Entwurf erlaubten Herkunft Manual auch für Produkt-/Testfakten. Die Benutzerklärung schließt diesen Weg aus: regelmäßige Importdaten sind unveränderbare Grundlage kostenpflichtiger Verträge. Eigene Zusatzinformationen bleiben pflegbar.

Entscheidung: Quellfakten/Quellfassungen und eigene Metadaten haben getrennte Schreibownership. Nur der Import übernimmt Testdaten; interne Rollen können keine Quellwerte anlegen oder ändern. Neue Lieferfassungen erhalten ihre Herkunft, und historische Vertragsbezüge bleiben unverändert. Eigene Notiz und Suchkategorien sind der bestätigte erste manuelle Schnitt (CM14). Das bestehende Webkategorie-Mapping verändert keine Quellkategorie. Konkrete Speicherung und Providerkennungen werden in CM14/CM12 ausgearbeitet, ohne vorsorglich neue Module oder Dienste einzuführen.

Phase 1 ist interne Vertragsverwaltung: Admin darf alle administrativen/fachlichen Aktionen, Referent alle fachlichen Aktionen. Rechte heben keine Dateninvarianten, Referenzsperren oder fachlichen Freigaberegeln auf. Die spätere Kundensicht ist auf eigene Daten/Verträge begrenzt: Vertragsstand lesend, eigene Daten und Neubestellungen schreibend. Sie ist kein Phase-1-Lieferumfang.

Präzisierung vom 15.10.2026 durch Product Owner: Die CM7-Matrix trennt Produktrollen von Tätigkeiten. Admin und Referent dürfen jeweils Erst-/Zweitprüfung und Freigaben übernehmen; eine vorgeschriebene zweite Person bleibt in jeder Rollenpaarung erforderlich, auch für Admin. Sensible Firmenänderungen und jede neue E-Mail-/Dokumentvorlagenfassung werden erst nach Freigabe einer anderen internen Person wirksam/verwendbar. Firmenzuordnung und Agenturvollmacht benötigen ausdrückliche RAL-Bestätigung; Mehrfirmenkonten sind zulässig. Externe Firmenadministration und eine zusätzliche Supervisor-Rolle sind nicht vorgesehen. Kunden pflegen nur eigene persönliche Kontaktdaten direkt und beantragen Firmenänderungen bei RAL. Vertretung verwendet eigene Identität und Rechte; Entzug wird beim nächsten betroffenen Zugriff wirksam, auch in einer bestehenden Sitzung. Die vollständige fachliche Matrix bleibt in CM7; keine zweite Grant-Liste in der Architektur. Person-001 bestätigt die Entscheidung am 15.10.2026 ausdrücklich auch als verbindliche RAL-Abstimmung (CM7 AC-4); die Laufzeitumsetzung bleibt offen.

Präzisierung vom 20.10.2026 durch Benutzerauftrag: Derselbe technische Dateiimport gilt für Entwicklung und Produktion und wird nur bei explizit konfiguriertem Dateipfad ausgeführt. Die anschließende Klarstellung unzuverlässiger Quell-IDs/Namen ersetzt automatische Schlüsselverknüpfung durch eigene interne Identität und Prüfung. Eine bestätigte Fortführung übernimmt auch geänderte ID, Name oder Note in eine neue Quellrevision desselben internen Produkts, derselben Veröffentlichung und desselben Ergebnisses. Historische Fassungen werden nicht überschrieben, eigene Notizen, Schlagworte und Such-/Webkategorien werden nicht verändert. Spätere Vertragsgrundlagen müssen die konkrete Quellrevision zusätzlich zu den stabilen internen IDs binden; deren Umsetzung wird nicht durch die Katalogprojektion vorweggenommen.

Lieferkennung und Inhalts-Hash sichern Wiederholung: gleiche Kennung mit gleichem Hash bleibt ohne Änderung, auch nach einer zwischenzeitlichen neueren Lieferung; gleiche Kennung mit anderem Hash ist ein Konflikt. Eine neue Lieferkennung kann eine neue Revision auch für die Rückkehr zu einer älteren Faktenlage bilden. Die komplette Datei wird vor dem transaktionalen SQL-Schreiben validiert. Nicht gelieferte Items sind keine Löschfreigabe, Referenzen mit Produktgleich keine automatische Gleichheitsentscheidung. Der Teilschnitt führt keinen UI-Upload, Benachrichtigungsprozess oder Providertransport ein. Die interne Import-Zuordnung unter /katalog/importe erhält den eigenen serverseitigen Grant RALLL.Catalog.Import für Admin/Referent. Kandidaten und Vergleich der nicht editierbaren Quellfelder unterstützen ausdrückliche Wahl eines bestehenden Tests, Prüfung einer anderen internen Test-ID, neue Testanlage oder Zurückstellen. Erledigung/Zurückstellen erhalten nur interne ActorId und UTC-Zeit; keine zusätzlichen Namen, E-Mails oder IP-Adressen. Quelle, Prüfbeleg und Entscheidung bleiben erhalten; Bereinigung und Schutzentscheidung bleiben bei CM15. Keine technische Outbox und keine zweite Retentionengine.

Verbindliche weitere Benutzerentscheidung vom 20.10.2026: Jede Änderung wird erst manuell bestätigt. Das gilt auch für eine reine Noten-, Urteilstext-, Preis- oder Laufzeitkorrektur bei ansonsten gleichen Quellmerkmalen. Testnoten können Grundlage eines Produktaufdrucks sein; deshalb ändern Eingang oder wiederholter Import einer abweichenden Fassung weder bisherige Projektion noch bestätigte Katalognote. Nur ein eindeutiger aktueller unveränderter Hash-Treffer bleibt ohne Entscheidung unverändert; die Erstbefüllung ohne bekannten importierten Testbestand legt neue interne Identitäten an. Danach gehen jede geänderte und jede neue/unklare Fassung in den persistenten Prüfeingang. Alte/neue Gesamt-/Gruppen-/Einzelurteile samt Note werden deutlich sichtbar verglichen; bestehender oder neuer Test und Änderungsübernahme werden bewusst bestätigt. Pending-Concurrency und erwartete Zielrevision müssen aktuell sein. Die frühere Revision bleibt unveränderbar erhalten; Score und Quellenhinweise ersetzen keine Freigabe. Das deterministische Notenbeispiel und die mit MR !300 integrierten technischen Nachweise stehen in CM11 AC-5.

Konsequenzen: Die Erlaubnis manueller Testdaten aus älteren Zieltexten ist ersetzt. Das Ist-Modell aus ADR-04 mit Manual bleibt als vorhandener Code dokumentiert, erteilt aber keine Erlaubnis für einen neuen Schreibweg. CM14 erhält neue ACs; Produktgleichheit bleibt als CM68 separat offen. CM15 betrifft Quellfassungen und eigene Metadaten, einschließlich vorhandener historischer Quellen; unbekannte Vergangenheit wird nicht erfunden. Löschregeln, verfügbarer Altdatenumfang und genauer Providerliefervertrag bleiben offen. Die Ergänzung vom 20.10.2026 beschreibt den separat beauftragten CM11-Teilschnitt; dessen SQL-/Proxy-/UI-/Migrationsnachweise sind mit MR !300 integriert und in CM11/CM71 commitgebunden nachgetragen. Produktive Ausführung bleibt gesondert zu belegen; kein Nachweis einer bereits ausgeführten Produktionsbefüllung oder vollständigen Storyabnahme.

Betriebs-/Historienpräzisierung vom 20.10.2026 (LL-S29): Der bestehende Windows-Dienst stellt fertige XML-Dateien für CAF bereit; CAF verarbeitet täglich ab 00:00 Uhr. Fehler melden sofort intern mit E-Mail-Kopie an RAL-Referenten, auch nachts; menschliche Reparaturen sind erst ab 08:00 Uhr zu erwarten. Kein zugesagter Bereitschaftsdienst oder Behebungszeitpunkt. Quellrevisionen bleiben verpflichtend erhalten; sichtbare Aktuell-Markierung und Verlaufsansicht sind optional. Personenbezogene Aufbewahrung ist davon getrennt nach dem gesetzlichen Zweckmaßstab zu konkretisieren. HearingPortal liefert die Vorlage für gezielte LL-Hinweise, keine pauschale Frist oder fremde Rechtsfreigabe.

Der CM11-Betriebsentwurf setzt einen Catalog-eigenen ABP-Worker mit Claims, Europe/Berlin-Kalendertagen und bestehendem Importservice um; kein eigener SFTP-Client oder täglicher Migrationslauf. Catalog besitzt dauerhafte Importmeldungen; Authorization löst Referenten über einen schmalen Catalog-Contract auf. ABP IEmailSender versendet Kopien unabhängig vom Erhalt der internen Meldung. Diese technische Konkretisierung ist am 20.10.2026 ausdrücklich akzeptiert und im aktuellen Arbeitsstand implementiert; die früheren Teilschnitt-Abgrenzungen bleiben historische Aussagen ihres jeweiligen Lieferstands.

Implementierung des akzeptierten Betriebsumfangs (20.10.2026): Catalog besitzt ABP- Hintergrundworker, Dateiarbeit, Eingangsepisoden und Meldungs-/Versandarbeit. Der Host komponiert ABP BackgroundWorkers/Emailing, native SMTP-Konfiguration und eigene Migrationen; neue Projekte, SFTP-Clients und CAF-Benachrichtigungsplattform entstehen nicht. Authorization löst aktive lokale CaseOfficer mit aktuellem Importgrant und Kontosprache über Catalog Contracts auf. Reale SQL-Fences verriegeln den tatsächlichen Import-/Dateiabschnitt; Dateiarbeit, unveränderliche CM71-Läufe, Fachlieferung und Quellrevision bleiben getrennt. Quellen sind gegen unterstützte EF-Änderungen/ Löschung geschützt. Meldungsfehler rollen keinen bestätigten Fachimport zurück, SMTP-Ausgänge werden nicht mit Postfachzustellung verwechselt. Betriebsbereitstellung, neue integrierte Gates, öffentliche Browsernachweise und RAL-Rechtstextfreigabe sind dadurch nicht vorweggenommen. Datenumfang/Zweck/Aufbewahrungsgrenzen stehen ausschließlich im vorhandenen Verarbeitungsinventar.

ADR-06 Zammad-Adapter in der App und getrennte Instanzen

Status: Angenommen auf ausdrücklichen PO-Auftrag vom 24.10.2026; Architekturentscheidung, keine Implementierungs-, Provider- oder Betriebsabnahme.

Kontext: Zammad liefert das vorhandene Ticketing. Der Dienstordner, konkrete Kundenbetrieb und die fachliche Integration wurden bisher nicht bis zum Prozess-/Speicherort geschärft. UZ (Umweltzeichen / EnvironmentalLabel) könnte denselben Adapter später gegen eine andere Zammad-Instanz benötigen.

Entscheidung:

• Zammad bleibt unverändertes Standardprodukt mit eigenem Betrieb und eigener Datenhaltung. CAF-19 besitzt die allgemeine Dienst-/Betriebsdefinition; konkrete RAL-Instanzen gehören zum Kundenbetrieb. Eine neue Instanz wird durch diese Entscheidung nicht bereitgestellt.
• Der erste schmale Adapter läuft im LogoLicense ContractManager, im zuständigen Feature. Seine Integrationsdaten liegen in der bestehenden RALLL-Datenbank: instanzgebundene Referenzen, dauerhafte Übergabeaufträge, empfangene Rückmeldungen und Abgleichzustand. Kein separater Middleware-Service, keine Middleware-Datenbank und kein SQL-Zugriff auf Zammad.
• Zammad besitzt Tickets, Kommunikation und operative Wiedervorlagen. Fachbewertung, Freigabe, Lizenzbezug und fachlicher Abschluss bleiben in der App; kein zweiter Ticketeditor.
• Technische Kommunikation und Provider-Mappings bleiben von LogoLicense-Fachregeln getrennt. Jede App konfiguriert Endpunkt, stabile Instanzkennung, Credentials und Mappings selbst. Referenzen und ausstehende Aufträge tragen die Instanzkennung; gleiche Ticketnummern in LL und UZ dürfen nicht kollidieren. Ein Zielwechsel leitet alte Aufträge nicht automatisch um.
• UZ kann später eine eigene Zammad-Instanz anbinden und behält eigene Daten-/Rechtehoheit. Wiederverwendung bedeutet keine gemeinsame Instanz oder Datenbank. Beim konkreten zweiten Consumer wird ausschließlich der gemeinsame technische Teil nach den bestehenden CAF-Regeln extrahiert und mit beiden Consumern geprüft. UZ referenziert keine LogoLicense-Runtime. Weder neuer CAF-Baustein noch allgemeiner Multi-Instanz-Router werden vorsorglich angelegt.

Begründung und Alternativen: Der App-Adapter erlaubt Fachänderung und Übergabeabsicht in einer lokalen Transaktion und nutzt den vorhandenen Betrieb. Eine zusätzliche zustandslose HTTP-Fassade verlagert zuverlässige Übergabe weiterhin zum Aufrufer; ein selbst zuständiger Middleware-Dienst bräuchte dagegen eigenen dauerhaften Zustand und zusätzliche Betriebsabnahme. Beides ist für den ersten Consumer nicht erforderlich. Ein gemeinsamer technischer Vertrag kann später auch ohne gemeinsamen Server wiederverwendet werden.

Konsequenzen und offene Punkte: CM55 führt Operationen, Instanzvertrag, Wiederanlauf, Beispielbezüge und offene Providerfragen. Version, reale Korrelationsgarantien, Fachkardinalität, Rechte, CM70-Annahmepunkt und konkrete Betriebsnachweise bleiben offen. Retry oder Webhook allein garantiert keine einmalige Wirkung. Zustände und Secrets bleiben beim jeweiligen Owner. Der mögliche UZ-Verbrauch ist keine Lieferzusage für den App-Stub. CAF-19 und G-10 führen die zugehörigen Dienstgrenzen.

Ergänzung vom 25.10.2026: technische Basis und unabhängiger Betrieb

Status: Auf PO-Auftrag nach Review übernommen; weiterhin Architektur-/Planungsentscheidung, keine Implementierungs- oder Betriebsfreigabe.

• Die technische Basis wird mit CM72 bis CM75 separat abnehmbar. CM55 besitzt weiterhin den vollständigen fachlichen Vertrag, CM56 dessen Anwendung am Fachfall. Die technischen Providerproben benötigen keine fertige Fallbearbeitung, öffentliche Meldungsannahme oder Browser-SSO.
• Jede Instanz wählt ein nachgewiesenes Tupel aus Zammad-Patch und Image-Digests, Compose-/Begleitdienstständen, Adapterrevision, Konfigurationsschema und unterstützten gespeicherten Job-Payloadversionen. LL und später UZ besitzen getrennte Freigaben, Wartungsfenster und Rollouts. Eine gemeinsame Maschine kann ein gemeinsames Ausfallrisiko bleiben; getrennte Instanzupdates behaupten keine physische Hochverfügbarkeit.
• Installation und Update sind explizite Betriebsabläufe außerhalb des App-Starts. Erstinitialisierung, wiederholbarer Sollabgleich und versionierte Bestandsmigration haben unterschiedliche Verträge; fremde Adminwerte werden nicht überschrieben.
• Eine lokale Outbox garantiert keine einmalige Zammad-Wirkung. Ungewisse Ticket- oder Artikelanlage wird nur über ein real belegtes Korrelationsverfahren aufgelöst; sonst bleibt sie gesperrt zur Klärung. Ein leerer Suchtreffer erlaubt kein blindes Neusenden.
• Webhooks werden authentifiziert und vor 2xx dauerhaft angenommen. Sie sind Signale für den Abgleich; fehlende oder vertauschte Meldungen werden unabhängig davon behandelt. Nicht mehr sichtbare Tickets gelten nicht automatisch als gelöscht.
• Testkopien werden vor dem ersten Start im Netz quarantänisiert und erhalten eigene Identität, Credentials und Testsenken. Produktionskanäle bleiben gesperrt.
• Recovery umfasst beide Datenstände: Die App sperrt ihre Verarbeitung dauerhaft, der Betrieb bindet Sicherungspunkte und Recovery-Generation. Abweichende Referenzen werden vor Wiederanlauf geklärt. Ein Zammad-Restore setzt nicht pauschal RALLL zurück; bereits verschickte Nachrichten sind keine rücknehmbaren Datenbankänderungen.

CAF-25 besitzt Bereitstellung, CAF-26 Updateworkflow und CAF-27 Recovery; allgemeine Betriebslogik greift dafür nur auf app-eigene Contracts/Operations zu, niemals auf RALLL-Tabellen. CM76 bindet die spätere LL-Betriebsfreigabe an konkrete Zielkonfiguration und gültige Nachweise. Details und Reihenfolge stehen in der Verteilungssicht.

Arbeitsstart vom 25.10.2026: Plattform und erste Distribution

Der PO beauftragt die ersten Zammad-Aufgaben nach dem bestehenden Workflow. CAF-19 konkretisiert die erste Testdistribution im Betriebsvertrag: Zammad 7.2.2 / Image-Build 7.2.2-0012, Compose v17.5.3 und fünf abgerufene linux/amd64-Plattformdigests. Diese Wahl ist die Eingabe für CAF-25, keine Laufzeit-, Provider- oder Produktionsabnahme.

Die Entwicklerhosts bleiben Windows-basiert; Zammad läuft dort mit Docker Desktop als Linux-Container. Staging ist verbindlich Linux-basiert. Produktion wird ebenfalls für Linux vorgesehen, möglicherweise als VM auf einem Hyper-V-Cluster; die konkrete Topologie ist noch nicht beschlossen. Dasselbe Manifest gilt auf beiden Hostplattformen; Einstiegsskripte, Pfade und Secretbereitstellung müssen jeweils geprüft werden.

CAF-25 ergänzt den vorhandenen Gatevertrag für eine Compose-Betriebsdefinition ohne .NET-Host; kein Scheinprojekt und kein ungeprüfter Sonderweg. Windows-Lifecycle und Linux-Bereitstellung werden nachgewiesen. App-Adapter, Keycloak-Zuordnung und Produktionsfreigabe behalten ihre getrennten Abhängigkeiten. UZ kann später eine andere Instanz und eine eigenständig freigegebene Versionskombination verwenden.

Der CAF-25-Arbeitsstand enthält einen expliziten lokalen Wrapper unter tools/Invoke-Zammad.ps1 für ralll-local. Die allgemeine Betriebsdefinition liegt unter services/zammad; Manifestwechsel werden bei bestehenden Instanzen abgewiesen. Initiale Fachkonfiguration und API-Konto bleiben CM72. Der Compose-Prüfjob verwendet den vorhandenen Linux-Runnerpool; Dockerzugriff und tatsächliche Serverabnahme sind noch offen. Daraus folgt keine Freigabe für Staging oder Produktion.

Lokale Profilvorarbeit vor Serverabnahme am 25.10.2026

Der PO erlaubt lokale Weiterarbeit; Runner-/CI-Konfiguration wird nachgeholt. CM72 beginnt mit einem lesenden App-Werkzeug und einer wertfreien Vorlage. Das Profil bindet LL-Consumer, stabile Instanzkennung, Endpunkt, CAF-25-Distribution, Konfigurationsversion, Secretreferenzen und technische Mappingkandidaten. Die Vorschau greift auf keine Provider-API zu und gibt weder Aktivierung noch Rechte/Ownership frei. Der App-Host provisioniert weiterhin nichts. Bootstrap, Sollabgleich und Migration bleiben offen. CAF-25 wird für CM72 als Abschlussvoraussetzung geführt; seine offene CI-/DoD-Abnahme wird dadurch weder aufgehoben noch als erledigt markiert.

Fachliche Zuordnung vom 25.10.2026

Der PO bestätigt die Zuordnung mehrerer Tickets und manuelle Dublettenprüfung: Ein Fachfall der Logo-Überwachung darf mehrere Zammad-Tickets bündeln. RAL prüft anhand von Firma, Produkt und Fundstelle, ob derselbe Vorfall oder ein neuer eigenständiger Vorfall vorliegt. Es gibt keine automatische Zusammenführung. Wiedereröffnung und neue verknüpfte Fälle folgen der bestätigten CM24-Matrix.

Die Zuordnung besitzt der ContractManager; Tickets bleiben instanzgebundene Providerobjekte. Ergänzung vom 26.10.2026: Ein instanzgebundenes Ticket gehört höchstens einem Fachfall. RAL wählt ein verknüpftes Hauptticket ausdrücklich für die operative Wiedervorlage; ohne gültige Auswahl bleibt dieser operative Weg gesperrt. Jede Nachricht benennt genau ein bewusst gewähltes Ticket. Bestehende Aufträge behalten ihr Ziel auch nach einem Wechsel. Umzuordnung bleibt CM55-Vertragsarbeit; kein automatischer Sammelversand. CM54 beschreibt die interne Fachvorbereitung; CM56 besitzt die spätere Integration. Diese Entscheidung bestätigt weder Providerfähigkeiten noch eine gelieferte Fallführung.

Der bestätigte CM54-Einstieg wird im app-eigenen Feature LogoMonitoring umgesetzt: Contracts und Runtime, bestehende RALLL-Datenbank, Migrationen im Host und eigene SQL-Server-Tests. Keine zusätzliche API, Datenbank oder CAF-Abstraktion. Unbekannte Firma/Produkt und fehlende Lizenz sind bei Anlage erlaubt; Pflichtbefund und Nachreichbarkeit der Belege folgen der PO-Ergänzung. Statusübergänge werden erst mit geprüftem Belegvertrag ergänzt.

ADR-07 Alfresco Community mit normalem Dateispeicher

Status: Entschieden am 25.10.2026 durch den Benutzer: „lock das so ein, mit normalen Speicher“. Herkunft und Geltungsbereich stehen im Quellenregister. Dies ist eine Architekturentscheidung für die geplante RAL-Anbindung des LogoLicense ContractManagers, keine Implementierungs- oder Betriebsabnahme. Sie provisioniert keine UZ-Instanz und legt keine gemeinsame Akte oder spartenübergreifenden Rechte fest.

Entscheidung: Alfresco Community Edition verwendet den normalen dateisystembasierten Content Store auf einem persistenten Volume. Repository-Metadaten liegen in der eigenen Alfresco-Datenbank; ContractManager greift über die Dokument-API zu und hält Fach- und Versionsreferenzen. Das Volume kann auf geeigneter Block-/Dateispeicherinfrastruktur bereitgestellt werden. Hersteller, Medium, Kapazität und Redundanz bestimmt der Betrieb anhand der später bestätigten Last- und Wiederherstellungsziele. Flüchtiger Containerspeicher oder eine unverwaltete Dateiablage außerhalb Alfresco erfüllen diese Entscheidung nicht.

S3 als primärer Content Store, ein kostenpflichtiger Connector, Enterprise-Lizenzen, Object Lock und WORM sind keine Voraussetzungen dieses Umfangs. Auch eine technische Löschsperre gegenüber sämtlichen Repository-, Datenbank- und Infrastrukturadministratoren wird nicht zugesagt. Sie wird insbesondere nicht pauschal aus „DSGVO“ oder der bisherigen Archivierungsanforderung abgeleitet. Eine konkrete entgegenstehende Pflicht ist gesondert zu belegen und würde eine erneute Architekturentscheidung erfordern.

Erforderliche Kontrollen:

• Eigene Dienstzugänge mit minimalen Rechten; fachliche Rollen und privilegierte Betriebszugriffe getrennt regeln. Der Adapter verwendet keinen allgemeinen Adminzugang.
• Maßgebliche Dokumentstände mit konkreter Version referenzieren; zulässige Änderungen, Löschungen und zugehörige Akteure nachvollziehbar protokollieren. Zugriffe auf Auditdaten und deren Aufbewahrung gehören in den Rechte- und Betriebsvertrag.
• Aufbewahrung und Löschfreigabe je Dokumentart festlegen. Reguläre Fach- und API-Wege müssen geltende Fristen und Sperren durchsetzen; eine Frist darf nicht allein aus einem Produktstandard oder dem lokalen Test abgeleitet werden.
• Getrennte Sicherungen von Datenbank, Content Store und nötiger Konfiguration vorsehen; Wiederherstellung auf einen konsistenten Stand samt Dokument-/Versionsreferenzen testen. Ein Volume, RAID oder eine erfolgreiche Neustartprobe ersetzt keinen Restore-Nachweis.

Grenzen und Folgearbeit: Privilegierte Betreiber bleiben Teil des Vertrauensmodells; ihre Eingriffe sind über Berechtigungen, Zuständigkeiten und Betriebsverfahren zu begrenzen. Der lokale Community-Spike belegt einzelne Funktionen und administrative Löschmöglichkeiten. Diese Beobachtungen bleiben erhalten; sie sind weder eine Konformitätsabnahme noch allein ein Grund für WORM. Die dort untersuchte Imagekombination ist wegen des dokumentierten Share-Patchstands keine freigegebene Produktionsbaseline.

CM46 konkretisiert den restlichen DMS-, Rechte-, Aufbewahrungs- und Betriebsvertrag einschließlich einer geprüften Versionsbindung. CM47 bleibt davon abhängig. CAF-20 trennt weiterhin allgemeine Dienstdefinition, Kundeninstanz und App-Integration. Die Speicherentscheidung schließt keinen dieser Vorgänge und behauptet keinen regelkonformen Gesamtbetrieb. Neue rechtliche oder vertragliche Anforderungen werden vor Umsetzung geprüft, statt vorsorglich kostenpflichtige Speichertechnik vorzuschreiben.

Eignungsbewertung von Alfresco CE und Zammad

Ergebnis des Dokumentationsgegenchecks vom 13.09.2026: Die Kombination ist für die bestätigte Aufteilung sinnvoll. Alfresco liefert ein offenes Dokumentrepository mit API; Zammad liefert Ticketing und Integrationsschnittstellen. Ihre vorhandenen Funktionen sollten genutzt werden, bevor der ContractManager Dokumentverwaltung oder Ticketbearbeitung selbst nachbaut. Die Produktwahl ersetzt jedoch keinen Nachweis des konkreten Fach- und Betriebsumfangs.

Die bisherigen überwiegend erfolgreichen Versuche stammen aus dem Benutzerbericht. Dieser Gegencheck hat keine laufenden Instanzen, Geheimnisse oder Testprotokolle untersucht und keine Produktivfähigkeit bestätigt. Vor Umsetzung wird der erprobte Versionsstand reproduziert und anhand der Qualitätsszenarien geprüft.

Noch zu entscheidende Alternativen

Für keine dieser Alternativen werden neue Dienste, Tabellen oder Pakete angelegt. Vor einer Implementierung werden getroffene Entscheidungen samt Konsequenzen in diesem Kapitelsatz und den betroffenen Anforderungen eingearbeitet; Story-Entwürfe dürfen bis dahin keine falsche Eindeutigkeit vortäuschen.

10. Qualitätsanforderungen

Herkunft und Nachweisstand

Die nicht-funktionalen Anforderungen nennen Sicherheit, granularen Zugriff, Nachvollziehbarkeit, Archivierung, Monitoring, Integrationsfähigkeit, Konfigurierbarkeit, Bedienbarkeit und Datenqualität. Sie enthalten keine vollständigen messbaren Betriebsziele. Die folgenden Szenarien sind Vorschläge für die spätere Abnahme; keines wurde gegen einen LogoLicense-Host ausgeführt.

Fachlich prüfbare Qualitätsszenarien

Die Abnahme von Historisierung und Archivierung benötigt zusätzlich die noch ausstehenden Regeln je Dokumentart für Aufbewahrung, zulässige Änderungen, Sperren und Löschfreigaben. Die Speicherbasis ist mit Community und normalem Dateispeicher entschieden (ADR-07). Nachweise betreffen Rollen-/API-Schutz, Versionserhalt, Audit und Wiederherstellung; WORM oder absolute Sperren gegen sämtliche Administratoren sind keine Abnahmekriterien. Ein vorhandener PDF-Download oder Audit-Eintrag erfüllt die Archivanforderung nicht bereits.

Noch fehlende Messgrößen

Prüfstrategie bei späterer Implementierung

Es gelten die Nachweisarten des Entwicklungsleitfadens: Architektur- und Modulgrenzen, Domain-/Application-Regeln, reale SQL-Server-Persistenz, Providerverträge, UI-Zustände und vollständige Browserstrecken je sichtbarem Prozess. Bestehende HearingPortal-Testzahlen werden nicht auf LogoLicense übertragen.

Erst ein realer Integrationspfad mit passender Fachabnahme erlaubt eine Erfüllungsaussage. Fehlende Infrastruktur oder offene Fachregeln werden als ausstehend dokumentiert; ein implementierter Test oder ein übersprungener Lauf ist kein positiver Nachweis.

11. Risiken und technische Schulden

Einordnung

Die Anwendung hat seit dem 11.10.2026 einen ersten ausführbaren Schnitt (Grundgerüst, Anmeldung, interne Katalogrecherche; Nachweise offen). Seine bewusst eingegangenen Schulden stehen unter Technische Schulden des ersten Schnitts. Darüber hinaus stehen fachliche Unschärfen und Entwurfsrisiken im Vordergrund. Offene Fragen und Entscheidungen werden zentral in den Anforderungen geführt. Dieses Kapitel erläutert ihre architektonischen Folgen, ohne eine zweite Nummerierung oder konkurrierende Beschlussliste anzulegen.

Risiken vor Implementierung

Grundlage: Prozessübersicht, Datenmodell, NFR und RAL-Realm-Vorgabe.

Technische Schulden des ersten Schnitts

Bewusst eingegangen mit dem Grundgerüst vom 11.10.2026 (RAL-LL-CM-67); jede Zeile nennt den Abbau.

Bekannte Barrieren und offene Barrierefreiheitsnachweise

Stand 16.10.2026: Es ist keine WCAG-Barriere als bewusst hingenommene Ausnahme freigegeben. Die erste CM3-Erhebung fand einen Kontrastfehler der aktiven Rechtsnavigation auf /PrivacyPolicy: 3,18:1 bei 16px normal (#fe5000 auf #fffaf5). Der registrierte UP-64-Behelf setzt nur die aktive Textfarbe auf das vorhandene Vordergrundtoken; der vollständige CM3-Lauf cm3full20261016d auf 594d2c27 bleibt der historische Erstnachweis. Der Behelf bleibt bis zum geprüften Upstreamabbau.

Die CM67-Erweiterung fand im realen Lauf cm67-public-20261016b zusätzlich scrollable-region-focusable auf der Cookie-Seite. Beide Tabellen besitzen seitdem eine benannte, per Tab erreichbare Region mit sichtbarem Fokus. Der Test misst PageUp/PageDown an stabilen Scrollpositionen für beide Regionen. Das ist eigene semantische Dokumentstruktur, kein Override fremder Komponenten und keine hingenommene Ausnahme.

Der kanonische Lauf cm67masked20261016 auf sauberem 047f1ca6ed5d9c3d8e9d4c49aa83fda00b497064 besteht jetzt alle zehn öffentlichen Grundgerüstrouten in DE/EN: 20 Seitenbefunde mit null WCAG2.1-A/AA-Verstößen, Tab/Fokus und tatsächlichen Rechts-/Home-/Retry-/Logout-Aktionen. Der Home-Weg wartet bis zum eigenen Realm-Loginformular und validiert Client und Callback; ein früheres Rennen am Zwischenziel ist korrigiert. 24 Fokusbilder wurden erzeugt; Vertreter, persönliche Ansprechpartner und Datenschutzkontakt werden nur in der Bildausgabe maskiert, die DOM-Prüfungen bleiben unverändert. Maskierte Rechtsseiten, beide Cookie-Regionen sowie interaktive/statische Fehlerbilder sind gesichtet. Gesamtproof und eigener Cleanup Exit 0 sind vorhanden. Die Spec hält diesen Quellstand und spätere Pflichtgate-/CI-Belege getrennt; der Lauf zertifiziert keine andere SHA.

Dies ist keine Abnahme weiterer Produktflächen. Die interne Katalogoberfläche und künftige Kundenvorgänge gehören zu ihren Fachstories. Erhobene Barrieren sind hier mit Befund, Datum, Begründung und Abbauplan nachzuführen; Kontrast- und Alternativtextverstöße dürfen nicht als Ausnahme aufgenommen werden.

Interner Katalog: Tastaturabschluss vom 17.10.2026

Der ausdrücklich angeforderte kanonische Run cm13keyboard19-1c374f936ef64250afc6f534606d03e1 auf sauberem b8405951 prüft zusätzlich die interne Katalogliste und Detailnavigation in DE/EN. Je Sprache bestehen neun Tastaturgruppen; die zehn öffentlichen Routen wurden mit axe und Tastatur erneut geprüft. 48 Fokusbilder und eigener Cleanup Exit 0 sind vorhanden. Die CM13-Spec führt die genaue Quellbindung, Gegenproben und getrennten Pflichtgate-/Serverbelege.

Gefundene Fokusverluste nach Filterentfernung und Navigation sind im Produkt behoben. Schnelle Texteingabe, erste Kalenderöffnung und Escape-Rückfokus liefert die separat veröffentlichte Cohesion-Version 3.6.3-alpha.0.19. Der UP-66-Behelf bleibt für tatsächlichen Fokus an Toolbar, Seitengröße und Spaltenoptionen aktiv; er ist keine hingenommene Kontrastausnahme. Die ursprüngliche graue Optionsfläche erreichte nur 1,101:1. Der tokenbasierte Ring rgb(213,67,0) erreicht 4,1195:1 beziehungsweise 4,3383:1 zu seinen direkten Nachbarflächen. Entfernen nur dieser Regel wird in DE/EN rot erkannt.

Der echte Kalenderweg führt per Tab zur Tabelle und dann über Pfeil/Enter oder Escape zurück zum Eingabefeld (OpenOnFocus=false). Die direkte Pfeilgeste vom Input ist kein funktionierender Nachweis. Zehn Seedprodukte belegen Seitengrößenwahl und korrekt deaktivierte nächste/letzte Seite; echte Mehrseitenwechsel sind hier nur komponentenbasiert geprüft. Refresh belegt Aktivierung und erhaltene Anzeige/Fokus, keinen gezählten Serverread. Die Bilder betreffen die Standardpalette; eine komplette Palette-/Mobilgeräteabnahme und weitere Produktflächen sind damit nicht behauptet. UP-64 und die übrigen registrierten Behelfe bleiben unverändert offen.

Grenzen dieser ersten Fassung

Die Quellenübersicht dokumentiert die tatsächlich gelesenen Inhalte und Auswertungsgrenzen. Eine als „bestätigt“ markierte Zeile im alten Datenmodell ist kein Beleg für eine CAF-Architekturfreigabe. Historische Technikbezeichnungen und Optimierungswünsche müssen mit den aktuellen Randbedingungen abgeglichen werden.

Die Story-Entwürfe dienen dem Refinement. Sie sind weder priorisierter Sprint noch veröffentlichte Jira-Zusagen. Keines der fachlichen Risiken darf durch ein ausgefülltes AC-Häkchen oder einen angenommenen Erfüllungsstand des HearingPortals verdeckt werden.

12. Glossar

Fachbegriffe

Die Begriffe orientieren sich an Prozessübersicht und Top-Level Datenmodellen. Offene Abgrenzungen sind bewusst benannt; Definitionen ersetzen keine Fachentscheidung.

Architektur- und Nachweisbegriffe

Zurück zur Kapitelübersicht.