Lots of runs

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Analysebericht.md

@@ -0,0 +1,187 @@
+# Analysebericht
+
+## Schritt 0 — Modulinventar
+
+Granularität: Die fachlichen WPF-UI-Module (`src\centron\Centron.WPF.UI\Modules\*`) werden auf Ebene der 30 obersten Modulordner erfasst; ihre Unterordner (insgesamt > 150) sind die Belegquelle für die einzelnen Anforderungen und werden dort zitiert, bilden aber keine eigene Inventarzeile — mit Ausnahme der risikorelevanten Bereiche Finances, PasswordManager, Administration und Rma, in denen einzelne Unterordner wegen ihrer eigenständigen fachlichen Funktion zusätzlich in der Vertiefung (Schritt 0c) mit eigenen Anforderungen bedacht werden. Zusätzlich zu den WPF-Modulen sind die tragenden Architekturkomponenten (Backend-Schichten, externe API-Anbindungen, Webservice, Nexus, geteilte Bibliotheken) als eigene Inventarzeilen erfasst, da sie eigenständige, technisch wie fachlich abgrenzbare Bausteine der Codebasis sind.
+
+### A. Fachliche WPF-UI-Module (`src\centron\Centron.WPF.UI\Modules\`)
+
+| # | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| A01 | Administration | `Modules\Administration` | Systemverwaltung: Benutzer/Mitarbeiter, Mandanten, Rechte, globale Einstellungen, DSGVO-Werkzeuge, Report-Server. |
+| A02 | ArtificialIntelligence | `Modules\ArtificialIntelligence` | KI-gestützte Textgenerierung/Chat-Assistent mit Werkzeugzugriff auf Konten-, Artikel-, Ticket- und Mitarbeiterdaten. |
+| A03 | Calendar | `Modules\Calendar` | Kalenderdarstellung und Outlook-/CRM-Synchronisationseinstellungen. |
+| A04 | Dashboard | `Modules\Dashboard` | Kachelbasierte Modulübersicht (Startbildschirm) inkl. Favoriten/Autostart. |
+| A05 | DataExchange | `Modules\DataExchange` | Datenaustausch mit externen Systemen: DATEV, Bank-/SEPA-Zahlungsverkehr, DocBee, docuFORM, GfK, RMM, filialübergreifende Bestellvorschläge. |
+| A06 | ExternalTool | `Modules\ExternalTool` | Auswahl/Start konfigurierter externer Werkzeuge aus c-entron heraus. |
+| A07 | Finances | `Modules\Finances` | Abrechnung, Mahnwesen, OPOS, Zahlungen, Verträge, Vertragsauswertung, CRM-Adressstamm, Klickzähler. |
+| A08 | Global | `Modules\Global` | Modulübergreifende Dialoge: PDF-Viewer, Freifelder, Fehlerdialog, Diagnose, MSP-Lizenzvergleich, Videoportal. |
+| A09 | Gui | `Modules\Gui` | Verwaltung gespeicherter Oberflächen-Layoutprofile. |
+| A10 | Helpdesk | `Modules\Helpdesk` | Ticketsystem für Kundenservice inkl. Checklisten, Zeiterfassung, SLA-Dashboard, Prozessvorlagen. |
+| A11 | Logistic | `Modules\Logistic` | Versand-/Kommissionierungseinstellungen (Standardempfänger, Ziel-Lagerpflicht, Versandarten). |
+| A12 | Massenupdates | `Modules\Massenupdates` | Massenänderung von Preisen und Belegdaten über Vorlagen. |
+| A13 | MyCentron | `Modules\MyCentron` | Persönlicher Arbeitsbereich: Mein Tag, Kalender, Telefonie, Supremo-Fernwartung, persönliche Einstellungen. |
+| A14 | OnlineBanking | `Modules\OnlineBanking` | Bankkontenanbindung über finAPI sowie native FinTS/HBCI/EBICS-Verbindungen, Kontoumsatzabgleich. |
+| A15 | PLM | `Modules\PLM` | Produktlebenszyklus-Verwaltung (Status, Berater, verknüpfte Artikel). |
+| A16 | PasswordManager | `Modules\PasswordManager` | Verwaltung von Kundenzugangsdaten (Passwörter, VPN, RDP, SSH) mit Richtlinien-/Siegelkonzept. |
+| A17 | PayersAndCostCenter | `Modules\PayersAndCostCenter` | Verwaltung von Kostenstellen und Kostenträgern (inkl. Soft-Delete/Restore). |
+| A18 | Production | `Modules\Production` | Fertigungsauftrags- und Maschinenverwaltung. |
+| A19 | ProjectManagement | `Modules\ProjectManagement` | Ressourcenplanung speziell für die Abteilung Software-Entwicklung (CRM-Projekte + Tickets). |
+| A20 | ProjectPriceImport | `Modules\ProjectPriceImport` | Import projektspezifischer Sonderpreise aus Excel mit Preisdifferenzprüfung. |
+| A21 | Purchasing | `Modules\Purchasing` | Einkauf: Bestellvorschlagsliste, EDI-Abgleich, Reisekosten. |
+| A22 | QM | `Modules\QM` | Qualitätsmanagement-Einstellungen (Standard-Reklamationsgründe je Belegart). |
+| A23 | Reports | `Modules\Reports` | Verwaltung des Reportmotors (Reportgruppen, Druckeinstellungen, Ad-hoc-Abfragen). |
+| A24 | Rma | `Modules\Rma` | Retourenabwicklung (RMA) inkl. Versand an/Rücknahme vom Lieferanten. |
+| A25 | Sales | `Modules\Sales` | Vertrieb: Mailing-Vorlagen, Produktmatrix, Sonderartikel-/Vertrags-Preisimporte (Wortmann, Riverbird). |
+| A26 | Statistics | `Modules\Statistics` | Auswertungen: Verkaufsstatistik, Management-Info, MSP-Collector/-Statistik, Mitarbeiteranalyse. |
+| A27 | Survey | `Modules\Survey` | Umfrage-/Fragebogen-Engine, als Workflow-Prozess modelliert. |
+| A28 | TelekomDive | `Modules\TelekomDive` | Export von Angebotspositionen in die Telekom-D!VE-Marktplatzplattform. |
+| A29 | Warehousing | `Modules\Warehousing` | Lagerverwaltung: Artikelstamm, Bestand, Inventur, Barcode, Materialgruppen, Umsatzsteuer. |
+| A30 | (Purchasing/Warehousing Sub) SearchArticle/SupplierSearch | `Modules\Warehousing\SearchArticle`, `SupplierSearch` | Wiederverwendbare Such-/Auswahldialoge für Artikel und Lieferanten (mehrfach eingebunden). |
+
+### B. Architektur- und Integrationskomponenten (`src\backend`, `src\apis`, `src\webservice`, `src\nexus`, `src\shared`, root)
+
+| # | Komponente | Pfad | Fachliche/technische Aufgabe |
+|---|---|---|---|
+| B01 | Centron.BL | `src\backend\Centron.BL` | Geschäftslogikschicht (Rechte-, Abrechnungs-, Mahn-, Auth-, Vertragslogik u. v. m.). |
+| B02 | Centron.DAO | `src\backend\Centron.DAO` | Datenzugriffsschicht auf Basis NHibernate/FluentNHibernate gegen MSSQL. |
+| B03 | Centron.Entities | `src\backend\Centron.Entities` | Persistentes Domänenmodell (~1185 Entitätsklassen). |
+| B04 | Centron.Common | `src\backend\Centron.Common` | Gemeinsame Low-Level-Hilfsfunktionen (u. a. Passwort-Hashing). |
+| B05 | Centron.Gateway | `src\backend\Centron.Gateway` | EDI-/Buchhaltungs-/Banking-Gateway zu Großhändlern, DATEV u. a. Finanzbuchhaltungssystemen, SEPA. |
+| B06 | Centron.Interfaces | `src\backend\Centron.Interfaces` | Schnittstellen-/DTO-/Enum-Vertragsschicht zwischen allen Schichten. |
+| B07 | Centron.APIs.CopDataAccess | `src\apis\Centron.APIs.CopDataAccess` | SOAP-Anbindung an den Produktkatalogdienst "COP". |
+| B08 | Centron.APIs.EgisDataAccess | `src\apis\Centron.APIs.EgisDataAccess` | Anbindung an den EDI-Großhändler EGIS (Katalog, Preise, Warenkorb). |
+| B09 | Centron.APIs.FinAPI | `src\apis\Centron.APIs.FinAPI` | REST-Anbindung an den Open-Banking-Aggregator finAPI. |
+| B10 | Centron.APIs.ITscopeDataAccess | `src\apis\Centron.APIs.ITscopeDataAccess` | REST-Anbindung an den IT-Produktdatenmarktplatz ITscope. |
+| B11 | Centron.APIs.IcecatDataAccess | `src\apis\Centron.APIs.IcecatDataAccess` | Anbindung an die Produktdatenbank Icecat. |
+| B12 | Centron.Api.EbInterface | `src\apis\Centron.Api.EbInterface` | Generator für österreichische E-Rechnungen im ebInterface-XML-Format. |
+| B13 | Centron.Api.Gls | `src\apis\Centron.Api.Gls` | REST-Anbindung an den Paketdienstleister GLS. |
+| B14 | Centron.Api.Shipcloud | `src\apis\Centron.Api.Shipcloud` | REST-Anbindung an den Multi-Carrier-Versanddienst shipcloud.io. |
+| B15 | Centron.Api.docuFORM | `Centron.Api.docuFORM` (root) | OAuth2-Anbindung an die Dokumentenplattform docuFORM. |
+| B16 | Centron Webservice (Host/Controllers) | `src\webservice\Centron.Host*`, `Centron.Controllers` | Zentraler ASP.NET-Core-API-Host (Ticket-/JWT-/SecretKey-Auth, ~40 Controller). |
+| B17 | Centron.WebServices.Core | `src\webservice\Centron.WebServices.Core` | Geteilte DTO-/Serialisierungs-/Client-Bibliothek für WPF-Client, Nexus und Controller. |
+| B18 | c-entron.misc.ConnectionManager | `src\webservice\c-entron.misc.ConnectionManager` | Administrationswerkzeug zur Konfiguration/Steuerung des Webservice-Windows-Dienstes. |
+| B19 | CentronNexus (+Host) | `src\nexus\CentronNexus*` | Blazor-Server-Webanwendung "c-entron Nexus" (ServiceBoard, Kunden-Self-Service, WebCart). |
+| B20 | CentronNexus.OutlookAddIn | `src\nexus\CentronNexus.OutlookAddIn` | Outlook-Mail-Add-in zur Zuordnung von E-Mails zu Tickets/Kunden. |
+| B21 | Centron.Controls (+Preview) | `src\shared\Centron.Controls*` | Wiederverwendbare WPF-Steuerelementbibliothek (Grid, RDP/SSH-Einbettung, Reporting). |
+| B22 | Centron.Core | `src\shared\Centron.Core` | UI-unabhängige gemeinsame Basisbibliothek (MVVM-Basisklassen, TOTP, Eventaggregator). |
+
+**Summe Inventar:** 30 fachliche WPF-Module (A01–A30) + 22 Architektur-/Integrationskomponenten (B01–B22) = **52 Inventarzeilen**. Keine Zeile ist als „nicht analysiert" ohne Anforderung geführt (siehe Abdeckungstabelle unten).
+
+## Abdeckungstabelle (Schritt 0b/0c)
+
+Einstufung je Inventarzeile (`tief | mittel | flach | nicht analysiert`) und Anzahl der daraus erzeugten Anforderungen (über alle drei Ebenen StRS+SyRS+SwRS gezählt, inkl. gemeinsam genutzter übergeordneter Anforderungen).
+
+| # | Modul/Komponente | Einstufung | Anzahl Anforderungen |
+|---|---|---|---|
+| A01 | Administration (Rechte, Mandant, DSGVO, Settings) | tief | 13 |
+| A02 | ArtificialIntelligence | mittel | 3 |
+| A03 | Calendar | flach | 1 |
+| A04 | Dashboard | flach | 1 |
+| A05 | DataExchange | mittel | 10 |
+| A06 | ExternalTool | flach | 1 |
+| A07 | Finances | tief | 28 |
+| A08 | Global | flach | 2 |
+| A09 | Gui | flach | 1 |
+| A10 | Helpdesk | tief | 9 |
+| A11 | Logistic | mittel | 2 |
+| A12 | Massenupdates | mittel | 3 |
+| A13 | MyCentron | mittel | 6 |
+| A14 | OnlineBanking | mittel | 5 |
+| A15 | PLM | mittel | 3 |
+| A16 | PasswordManager | tief | 7 |
+| A17 | PayersAndCostCenter | mittel | 3 |
+| A18 | Production | mittel | 3 |
+| A19 | ProjectManagement | flach | 1 |
+| A20 | ProjectPriceImport | mittel | 3 |
+| A21 | Purchasing | tief | 9 |
+| A22 | QM | mittel | 3 |
+| A23 | Reports | flach | 1 |
+| A24 | Rma | tief | 6 |
+| A25 | Sales | mittel | 3 |
+| A26 | Statistics | mittel | 4 |
+| A27 | Survey | mittel | 3 |
+| A28 | TelekomDive | flach | 1 |
+| A29 | Warehousing | tief | 14 |
+| A30 | SearchArticle/SupplierSearch | flach | 2 (geteilt mit A29) |
+| B01 | Centron.BL | mittel* | 1 dediziert (*als Belegquelle in > 30 weiteren Anforderungen zitiert) |
+| B02 | Centron.DAO | flach | 2 |
+| B03 | Centron.Entities | flach | 1 |
+| B04 | Centron.Common | flach | 1 |
+| B05 | Centron.Gateway | mittel | 2 dediziert (+ SEPA-Beleg unter A05/A07) |
+| B06 | Centron.Interfaces | flach | 2 (als Belegquelle mehrfach zitiert) |
+| B07 | Centron.APIs.CopDataAccess | flach | 1 |
+| B08 | Centron.APIs.EgisDataAccess | flach | 1 |
+| B09 | Centron.APIs.FinAPI | flach | 1 |
+| B10 | Centron.APIs.ITscopeDataAccess | flach | 1 |
+| B11 | Centron.APIs.IcecatDataAccess | flach | 1 |
+| B12 | Centron.Api.EbInterface | flach | 1 |
+| B13 | Centron.Api.Gls | mittel | 2 |
+| B14 | Centron.Api.Shipcloud | flach | 1 |
+| B15 | Centron.Api.docuFORM | flach | 1 |
+| B16 | Centron Webservice (Host/Controllers) | tief | 5 |
+| B17 | Centron.WebServices.Core | flach | 1 |
+| B18 | c-entron.misc.ConnectionManager | flach | 1 |
+| B19 | CentronNexus | mittel | 3 |
+| B20 | CentronNexus.OutlookAddIn | mittel | 3 |
+| B21 | Centron.Controls | flach | 1 |
+| B22 | Centron.Core | flach | 1 |
+
+**Zusammenfassung:** 8 Module `tief`, 19 Module `mittel`, 25 Module `flach`, **0 Module `nicht analysiert`**. Jede der 52 Inventarzeilen trägt mindestens eine belegte Anforderung — die Mindestabdeckung aus Schritt 0b ist vollständig erreicht.
+
+## Konsistenzcheck
+
+- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. StRS-001…042, SyRS-001…044 und SwRS-001…094/096…100 (SwRS-095 wurde bei der Nachvertiefung bewusst nicht vergeben, um die Reihenfolge nicht zu verwürfeln — siehe Hinweis unten) sind je genau einmal vergeben.
+- **Anforderungen ohne Beleg:** Keine gefunden. Jede der 185 Anforderungen (42 StRS + 44 SyRS + 99 SwRS) trägt mindestens einen klassifizierten Beleg.
+- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden. Jede Anforderung trägt eine der vier Einstufungen mit Kurzbegründung.
+- **Tracelinks auf nicht existierende IDs:** Stichprobenartig und für alle Sammel-Tracelinks der StRS-/SyRS-Ebene (siehe Traceability.md) geprüft — alle referenzierten IDs existieren. Eine vollständige automatisierte Prüfung aller Einzel-Tracelinks in jedem der 185 Blöcke wurde nicht durchgeführt; das Risiko wird als gering eingeschätzt, da IDs fortlaufend beim Schreiben vergeben wurden.
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Neun Konsolidierungskandidaten wurden identifiziert und im jeweiligen Feld `Konsolidierung` vermerkt: externe Produktdatenquellen (StRS-026, SwRS-096, SwRS-097), Versanddienstleister-Anbindungen (StRS-027), Sonderpreis-Import-Varianten (StRS-040, SwRS-075), Logistik-/RMA-Versandkonfiguration (SwRS-067), Kommissionierungskonzepte Beta vs. bestehend (SwRS-079), D!VE-Export (SwRS-086) und FiBu-Exportadapter (SwRS-089). Über diese hinaus wurden bei der Durchsicht keine weiteren fachlich deckungsgleichen, nicht markierten Anforderungen gefunden.
+- **Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:**
+
+| ID | Titel | PRIMÄR-Beleg vorhanden? | Falls nein: [HYPOTHESE]? |
+|---|---|---|---|
+| StRS-001 | Mahnwesen für überfällige Kundenrechnungen | ja | – |
+| StRS-002 | OPOS-Auswertung | ja | – |
+| StRS-003 | Automatisierte Vertragsabrechnung | ja | – |
+| StRS-004 | Kontrollierte Stornierung von Rechnungen | ja | – |
+| StRS-005 | Zahlungseingangsverwaltung | ja | – |
+| StRS-006 | Vertragslaufzeit/Kündigung | ja | – |
+| StRS-007 | Abrechnung Ticketzeiten/Pauschalprojekte | ja | – |
+| StRS-008 | Sichere Verwaltung von Kundenzugangsdaten | ja | – |
+| StRS-009 | Richtlinienbasierte Rechtevergabe PasswordManager | ja | – |
+| StRS-010 | Rollen-/rechtebasierte Zugriffssteuerung | ja | – |
+| StRS-011 | Mandantenfähigkeit / Datenisolation | nein (nur für Nummernkreis) | ja, siehe Hypothesen.md |
+| StRS-012 | DSGVO-Löschung | nein (nur UI-Fakt) | ja, siehe Hypothesen.md |
+| StRS-013 | Sichere Authentifizierung | ja | – |
+| StRS-014 | Lizenzgesteuerte Freischaltung | ja | – |
+| SwRS-009/010 | Zahlungsverbuchung: Storno-Schutz/Rechteausnahme | ja | – |
+| SwRS-013 | Rechteprüfung vor Zeiterfassungs-Speicherung | ja | – |
+| SwRS-014/015/016 | PasswordManager Flag-Steuerung/Guideline-Scoping/Clipboard | ja | – |
+| SwRS-017/018 | Modul-Rechteausdruck/Rechte-Caching | ja | – |
+| SwRS-021/022 | AD-Authentifizierung/Ticket-Claims | ja | – |
+| SwRS-030 | Doppelte Rechteprüfung Artikelverwaltung | ja | – |
+| SwRS-041 | Hartkodiertes GLS-Secret (Sicherheitsbefund) | ja | – |
+| SwRS-099 | Klartext-Secrets in Docker-Beispielkonfiguration (Sicherheitsbefund) | ja | – |
+
+Alle risikorelevanten Anforderungen sind entweder mit einem `PRIMÄR`-Beleg gedeckt oder – wenn kein solcher Beleg auffindbar war – explizit als `[HYPOTHESE]` gekennzeichnet (StRS-011, StRS-012 und ihre jeweiligen SyRS-/SwRS-Ableitungen). Kein risikorelevanter Punkt bleibt ohne Kennzeichnung.
+
+- **Abgleich Hypothesen.md gegen Inline-Markierungen:** Deckungsgleich. Alle zehn mit `Status: HYPOTHESE` markierten Anforderungen (StRS-011, StRS-012, StRS-016, SyRS-013, SyRS-019, SwRS-019, SwRS-020, SwRS-076, SwRS-083, SwRS-089) sind in Hypothesen.md mit ihrer offenen Frage aufgeführt; Hypothesen.md enthält keine zusätzlichen, anforderungslosen Fragen.
+
+## Selbstbewertung
+
+**Tiefe der Analyse:** Von den 52 Inventarzeilen wurden 8 `tief` (Finances, Administration, Helpdesk, PasswordManager, Purchasing, Rma, Warehousing, Webservice-Host), 19 `mittel` und 25 `flach` analysiert; kein Modul blieb ohne Anforderung (`nicht analysiert` = 0). Die Tiefenverteilung folgt bewusst der in Schritt 0c geforderten Risikopriorisierung: Sicherheits-, Abrechnungs-/Fakturierungs- und Berechtigungslogik wurden mit sechs parallel arbeitenden Vertiefungsrecherchen (siehe Vorgehen unten) am gründlichsten untersucht, während rein konfigurative oder wenig risikobehaftete Module (z. B. Calendar, Dashboard, Gui, Reports) bewusst mit geringerer Tiefe, aber nicht ohne jede Anforderung geführt wurden.
+
+**Mindestabdeckung erreicht:** Ja. Jede der 52 Inventarzeilen trägt mindestens eine belegte Anforderung mit direktem Artefaktbezug in den Pfad der jeweiligen Komponente.
+
+**Dünne Beleglage:** Am dünnsten belegt sind die 25 `flach` eingestuften Module — dort wurde in der Regel genau eine Datei geöffnet und ein charakteristischer Fakt daraus gezogen, ohne die volle Breite des jeweiligen Unterordners zu prüfen (z. B. B03 Centron.Entities: von ca. 1185 Klassen wurde keine einzelne inhaltlich geprüft, nur die Architekturaussage über die Gesamtstruktur belegt). Der Anteil `SEKUNDÄR`/`KONTEXT`-Belege ist in den Modulen DataExchange (mehrere Exportadapter nur über Ordnerstruktur belegt, SwRS-089), ProjectManagement (SwRS-072) und den externen Marktplatzintegrationen (Sales, SwRS-076) am höchsten.
+
+**Hypothesenquote:** 10 von 185 Anforderungen (5,4 %) sind als Hypothese markiert. Dieser vergleichsweise niedrige Wert ist kein Zeichen einer erschöpfenden, lückenlosen Analyse der gesamten Codebasis — bei einer Codebasis dieser Größe (> 150 Unterordner allein in der WPF-UI, ~1185 Entitätsklassen, 44 Solution-Projekte) ist das nicht plausibel. Er erklärt sich vielmehr daraus, dass die sechs Vertiefungsrecherchen gezielt auf die Bereiche mit der höchsten Risikoklassifizierung (Finances, PasswordManager/Administration/Security, Helpdesk/Rma, Warehousing/Purchasing) konzentriert wurden und dort überwiegend eindeutige, direkt im Code sichtbare Fakten fanden; in den `flach` eingestuften Bereichen wurde entsprechend der Weisung „ohne Beleg keine Anforderung" jeweils nur eine einzelne, tatsächlich belegbare Aussage geschrieben, statt spekulativ weitere, unbelegte Aussagen als Hypothese zu formulieren. Die tatsächliche Zahl offener Punkte in der Gesamtcodebasis liegt mit hoher Wahrscheinlichkeit deutlich höher als die hier dokumentierten zehn Fälle — siehe „Empfehlung Folgeiteration" unten.
+
+**Empfehlung für eine Folge-Iteration:**
+1. Die 25 `flach` eingestuften Module (insbesondere B03 Centron.Entities, B06 Centron.Interfaces sowie die sechs bislang nur oberflächlich geöffneten FiBu-Exportadapter in Centron.Gateway) sollten in einer weiteren Vertiefungsrunde mit dediziertem Recherche-Fokus behandelt werden.
+2. Die DSGVO-Backend-Implementierung (`IDataSecurityLogic`) und die tatsächliche Datenisolation zwischen Mandanten (StRS-011/StRS-012) sollten vorrangig geklärt werden, da beide Punkte unmittelbar regulatorische bzw. sicherheitsrelevante Konsequenzen haben.
+3. Die vollständige Analyse des Datenbankschemas (`SSMS_DB_SCHEMA.sql`, ca. 3,3 MB) wurde in dieser Iteration nicht systematisch durchgeführt — DB-Constraints wurden nur dort zitiert, wo sie im Rahmen der WPF-/BL-Recherche zufällig sichtbar wurden (z. B. `cvw_InvoiceDunnings`-Sicht). Eine dedizierte Analyse des Schemas könnte zusätzliche `PRIMÄR`-Belege für bislang nur `SEKUNDÄR` gedeckte Datenregeln liefern.
+4. Die im Code selbst als „(obsolate)" bzw. „Beta" markierten Bereiche (PasswordManager, Commissioning) benötigen eine explizite Abstimmung mit dem Fachbereich, ob und in welcher Form sie in die Neuimplementierung übernommen werden.
+5. Die in dieser Iteration nur mit einer einzelnen Anforderung geführten, aber im Code auffällig gewordenen Wartbarkeitsbefunde (hartkodierte IDs/Abteilungsnamen in ProjectManagement, SwRS-072; unbegrenzte Seitengröße in der Lieferantensuche, SwRS-082) sollten in der Migrationsplanung als konkrete Technical-Debt-Posten aufgenommen werden.
+
+**Hinweis zur ID-Vergabe:** Bei der nachträglichen Ergänzung dreier SwRS-Anforderungen zu bislang unbelegten externen API-Anbindungen (COP, ITscope, ebInterface) wurde die fortlaufende ID SwRS-095 bewusst durch SwRS-096–098 ersetzt und die ursprünglich als SwRS-095 geführte Anforderung zu Docker-Secrets auf SwRS-099 umnummeriert, um die aufsteigende Reihenfolge in der Datei zu erhalten; eine weitere Ergänzung (finAPI) wurde konsequent als SwRS-100 angehängt. Dies erklärt die Lücke bei der Nummer 095 in der Zählung „SwRS-001…094, 096…100" und ist keine fehlende oder doppelt vergebene ID.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Glossar.md

@@ -0,0 +1,34 @@
+# Glossar
+
+Domänenbegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) dieser Analyse verwendet werden. Deutsche Fachbegriffe der c-entron-Codebasis wurden übernommen; technische Bezeichner (Klassen, Methoden, Spalten) sind im Original belassen.
+
+| Begriff | Bedeutung |
+|---|---|
+| **Mandant** | Rechtliche/organisatorische Einheit innerhalb einer c-entron-Installation (z. B. eigenständige Firma einer Unternehmensgruppe). Steuert laut Codebefund primär Briefkopf, Bankverbindungen und Belegnummernkreise je Filiale, **nicht** nachweislich eine Datenisolation zwischen Mandanten (siehe Hypothese H-013). |
+| **Filiale (Branch)** | Organisatorische Unterstruktur eines Mandanten; referenziert `MandatorI3D`. Steuert u. a. Belegnummernkreise und Sichtbarkeitseinschränkungen ("nur eigene Filiale"). |
+| **Beleg (Receipt)** | Sammelbegriff für alle Geschäftsdokumente (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Vertrag, Abholschein) mit gemeinsamem Zustandsmodell `ReceiptState` (`Active`/`Completed`/`Canceled`). |
+| **Ticket (Helpdesk)** | Vorgang im Kundenservice-Modul Helpdesk; Status ist vollständig admin-konfigurierbar (`HelpdeskStatusDTO`), es existiert keine feste Statusenumeration im Code. |
+| **RMA** | "Return Merchandise Authorization" – Retourenvorgang für defekte/zu tauschende Artikel, 1:1 an ein Helpdesk-Ticket gekoppelt (`HelpdeskI3D`). |
+| **SendBack / SendForth** | Zwei Teilschritte eines RMA-Vorgangs: SendBack = Versand des Artikels vom Kunden/c-entron zum Lieferanten; SendForth = Eingang der Lösung (Reparatur, Austausch, Verschrottung) vom Lieferanten zurück. |
+| **Stammblatt (Master Data List)** | Geräte-/Anlagen-Stammdatensatz (z. B. Drucker mit Zählerstand), der über `DeviceToContract` mit Verträgen verknüpft ist und Basis für Klickzähler-Abrechnung ist. |
+| **Asset** | Allgemeiner Hardware-Vermögensgegenstand außerhalb der Stammblatt-Verwaltung; laut Auftrag im Zielsystem mit Stammblättern zu einem einheitlichen Asset-Konzept zusammenzuführen (Konsolidierungskandidat). |
+| **Mahnung (Dunning)** | Erinnerungs-/Eskalationsprozess für überfällige Rechnungen mit Stufen `None → Level1 → Level2 → Level3`. |
+| **OPOS** | "Offene Posten" – reine Auswertung/Auszug offener Rechnungsbeträge; im Unterschied zur Mahnung schreibfrei (keine Zustandsänderung an der Rechnung). |
+| **Kontingent (Contingent)** | Im Vertrag vereinbartes Mengen- oder Zeitbudget (`Booked + TakeOver - Used = Rest`), das über Rechnungen/Leistungen abgebaut wird. |
+| **Klickzähler (Device Click Counter)** | Zählerstand eines Endgeräts (z. B. Drucker), der automatisiert in die Vertragsabrechnung (`AutomaticFacturaBL`) einfließt. |
+| **BVL (Bestellvorschlagsliste)** | Order Suggestion List – berechnet Nachbestellmengen aus Bestand, offenen Bestellungen und Mindestbestand. |
+| **EDI** | Electronic Data Interchange – automatisierter Belegaustausch (Auftragsbestätigung, Lieferschein, Rechnung, ZUGFeRD) mit Lieferanten/Distributoren. |
+| **ZUGFeRD** | Deutscher/europäischer Standard für strukturierte E-Rechnungen (XML in PDF eingebettet), im System sowohl importierbar (EDI-Eingang) als auch exportierbar. |
+| **Recht (User Right)** | Ganzzahlige ID (`UserRightsConst.*`), die eine Berechtigung referenziert; Prüfung erfolgt clientseitig gegen `CentronCache.Instance.CurrentUserAppRights` und/oder serverseitig gegen `AppRightsBL.CheckRightsFromUser`. |
+| **Einschränkendes Recht (Restricting Right)** | Sonderform eines Rechts, das den Sichtbereich eines bereits vorhandenen Rechts einschränkt (z. B. "nur eigene Tickets", "nur eigene Filiale") statt eine Fähigkeit freizuschalten. |
+| **Zugangsbereich (Access Area)** | Im PasswordManager definierte Kategorie von Zugangsdaten (z. B. VPN, RDP, SSH) mit konfigurierbaren benutzerdefinierten Feldern. |
+| **Richtlinie (Guideline, PasswordManager)** | Regelwerk, das einem Mitarbeiter/einer Abteilung über `PasswordManagerGuidelineRights` (Flags-Enum) feingranulare Rechte auf Zugangsdaten eines bestimmten Kunden gewährt, optional zeitlich befristet. |
+| **Siegel (Seal, PasswordManager)** | Zugriffsschutzmechanismus auf einzelne Zugangsdaten; "Siegelbruch" (SealBreak) protokolliert den bewussten Zugriff auf versiegelte Daten. |
+| **Lizenz (License)** | GUID-basiertes Freischaltmerkmal für Anwendungen oder Einzelfunktionen, geprüft über `LicenseManager.Instance.HasLicense(...)`; kann zusätzlich `count`, `valid until date/version` tragen. |
+| **Ticket (Auth-Ticket)** | Server-ausgestelltes Sitzungstoken nach erfolgreichem Login, validiert durch `AuthenticationTicketBL`/`TicketAuthenticationHandler` bei jedem Webservice-Aufruf – nicht zu verwechseln mit einem Helpdesk-Ticket. |
+| **c-entron Nexus** | Separate ASP.NET-Core-Blazor-Webanwendung ("ServiceBoard", Kunden-Self-Service, WebCart), die den Webservice über ein gemeinsames Secret ("SecretKey") und JWT als Client konsumiert. |
+| **WebCart** | Im c-entron Nexus enthaltene Bestellfunktion für Kunden auf Basis ihrer hinterlegten Sonderpreise ("Sonderpreise"). |
+| **Sonderpreis (Special Agreement)** | Kundenindividuell vereinbarter Artikelpreis, der auch die Bestandsreservierung (`SpecialAgreementQuantity`) getrennt vom allgemeinen Bestand führt. |
+| **c-entron.NET** | Der WPF-Desktop-Client der Anwendung (Alt-Bezeichnung im Unterschied zu Nexus). |
+| **I3D** | Primärschlüssel-Namenskonvention der Codebasis (Integer-ID) für praktisch alle Entitäten, z. B. `ArticleI3D`, `HelpdeskI3D`. |
+| **BL / DAO / WS (Architekturschichten)** | `BL` = direkte Datenbank-Businesslogik (NHibernate), `DAO` = Datenzugriffsschicht, `WS`/`WebServiceBL` = Zugriff über den Webservice; ein Modul implementiert i. d. R. beide Pfade hinter einer gemeinsamen `ILogic`-Schnittstelle (Dual-Implementation-Pattern, siehe SwRS zur Architektur). |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Hypothesen.md

@@ -0,0 +1,37 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]` bzw. `Status: HYPOTHESE` markierten Anforderungen. Diese Liste ist deckungsgleich mit den Inline-Markierungen in StRS.md, SyRS.md und SwRS.md (siehe Konsistenzcheck in Analysebericht.md) und enthält ausschließlich Anforderungen — keine freien, anforderungslosen Fragen (diese stehen in der Selbstbewertung).
+
+Insgesamt **10 von 184 Anforderungen (5,4 %)** sind als Hypothese markiert. Das ist niedrig für eine Codebasis dieser Größe; eine Begründung dafür liefert die Selbstbewertung in Analysebericht.md (Kurzfassung: die Analyse ist bewusst auf wenige, durch sechs parallele Vertiefungsrecherchen intensiv untersuchte Risikobereiche fokussiert, in denen die Beleglage überwiegend eindeutig war — nicht analysierte Bereiche wurden konsequent als "flach" bzw. mit Einzelanforderung geführt statt spekulativ mit Hypothesen aufgefüllt).
+
+---
+
+### StRS-011 — Mandantenfähigkeit für Briefkopf, Bankverbindung und Belegnummernkreise
+**Offene Frage:** Es konnte keine Stelle im Code gefunden werden, die Geschäftsdaten (Kunden, Belege, Tickets) nach dem Mandanten des angemeldeten Benutzers filtert. Die einzige gefundene mandantenbezogene Fachlogik betrifft Nummernkreise (`MandatoryBL.GetNumberGroup`). **Zur Bestätigung fehlt:** Auskunft des Fachbereichs bzw. der Entwickler, ob "Mandant" bewusst nur als Konfigurationskonstrukt (Briefkopf/Bank/Nummernkreis) ohne Datenisolation gedacht ist, oder ob eine Datentrennung an anderer, nicht eingesehener Stelle (z. B. serverseitige Query-Filter, die im untersuchten Codeausschnitt nicht auftauchten) existiert.
+
+### StRS-012 — DSGVO-konforme Löschung und Anonymisierung personenbezogener Daten
+**Offene Frage:** Die Backend-Implementierung von `IDataSecurityLogic.DsgvoDeleteRightDeleteContacts` und `DataSecurityExecuteCleanUpAsync` wurde im Rahmen dieser Analyse nicht aufgefunden (nur die aufrufende WPF-Schicht wurde gelesen). **Zur Bestätigung fehlt:** Lesen der tatsächlichen Backend-Methoden, um zu klären, ob Hard-Delete oder Anonymisierung erfolgt und ob die Löschung auf verknüpfte Belege/Tickets kaskadiert.
+
+### StRS-016 — Fälligkeitsüberwachung von Tickets (SLA-Transparenz ohne automatisierte Eskalation)
+**Offene Frage:** Es wurde keine automatisierte Aktion (Statuswechsel, Neuzuweisung, aktive Benachrichtigung) gefunden, die bei SLA-Verletzung ausgelöst wird — nur eine Dashboard-Anzeige. Ein Modul „EscalationsSettings" existiert, wurde aber nicht bis zur Ebene einer automatisierten Aktion vertieft. **Zur Bestätigung fehlt:** Vertiefte Analyse von `Modules\Administration\EscalationsSettings\EscalationType` sowie der zugehörigen Backend-Klassen, um zu klären, ob dort tatsächlich eine automatisierte Eskalation stattfindet.
+
+### SyRS-013 — Mandantenbezogene Vergabe von Belegnummernkreisen
+**Offene Frage:** Identisch mit StRS-011 — die Fallback-Kette auf den Standardmandanten ist belegt, eine darüber hinausgehende Datenisolation nicht. **Zur Bestätigung fehlt:** siehe StRS-011.
+
+### SyRS-019 — Dashboard-Kennzeichnung SLA-relevanter, fälliger Tickets
+**Offene Frage:** Identisch mit StRS-016 — die Dashboard-Gruppierung ist belegt, eine automatisierte Eskalationsfolge nicht. **Zur Bestätigung fehlt:** siehe StRS-016.
+
+### SwRS-019 — Fallback auf Standardmandant bei fehlender Filialzuordnung
+**Offene Frage:** Identisch mit StRS-011/SyRS-013.
+
+### SwRS-020 — Löschprotokoll als Datei- oder Zwischenablage-Ausgabe nach DSGVO-Löschung
+**Offene Frage:** Identisch mit StRS-012 — nur die UI-seitige Protokollausgabe ist belegt, die tatsächliche Löschmethodik im Backend nicht.
+
+### SwRS-076 — Zeitraumbasierter Datenabruf vom Riverbird-Server
+**Offene Frage:** Das genaue Protokoll und der Anbieter hinter dem in der UI als „Riverbird" bezeichneten Server konnten aus der UI-Schicht (`ReadRiverbirdServerDialogViewModel.cs`) nicht abschließend bestimmt werden. **Zur Bestätigung fehlt:** Analyse der zugehörigen Backend-/Gateway-Klasse (falls vorhanden) oder Rückfrage beim Entwicklungsteam, welcher externe Anbieter sich hinter "Riverbird" verbirgt und welches Protokoll verwendet wird.
+
+### SwRS-083 — Genehmigungspfad für Reisekosten/Auslagen
+**Offene Frage:** Die vollständige Definition des Enums `TransactionStatus` (alle Werte, deren numerische Reihenfolge, ob Übergänge erzwungen werden) wurde nicht geöffnet — nur Verwendungsstellen wurden per Grep bestätigt. **Zur Bestätigung fehlt:** Lesen der Enum-Definition (vermutlich in `Centron.Interfaces` oder `Centron.Entities`) sowie der Backend-Klasse, die Statusübergänge tatsächlich durchsetzt, um zu klären, ob z. B. ein direkter Sprung von "Active" zu "Closed" ohne Genehmigung technisch möglich ist.
+
+### SwRS-089 — Vendorspezifische FiBu-Export-/Importadapter über ein gemeinsames Interface
+**Offene Frage:** Die einzelnen Adapterimplementierungen unter `src/backend/Centron.Gateway/DataExchange/BookKeeping/*` (Addison, Abacus, SAP, Sage, Lexware, Navision) wurden nur über die Ordnerstruktur, nicht im Detail gelesen. **Zur Bestätigung fehlt:** Öffnen mindestens eines konkreten Adapters, um zu verifizieren, dass `IBookKeepingExport`/`IBookKeepingImportDataToCentron` tatsächlich einheitlich implementiert werden und keine adapterspezifischen Sonderregeln außerhalb des Interfaces bestehen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/StRS.md

@@ -0,0 +1,870 @@
+# Stakeholder Requirements Specification (StRS)
+
+Fachliche Sicht: Geschäftsziele, Akteure, Prozesse. Ebene: StRS. Belege beziehen sich auf die technische Implementierung, aus der die fachliche Aussage abgeleitet wurde (Reverse Engineering).
+
+---
+
+```
+ID:            StRS-001
+Titel:         Mahnwesen für überfällige Kundenrechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Kundenrechnung ist aktiv (nicht storniert) und die Fälligkeit ist überschritten.
+Fakt:          DunningBL.GenerateInvoiceExpression() selektiert Rechnungen mit State==Active und DueDate<=Today (sofern nicht explizit anders gefiltert); DunningRunBL.UpdateInvoice() führt einen dreistufigen Statuswechsel None→Level1→Level2→Level3 mit Datums-/Bearbeiterstempel je Stufe durch.
+Aussage:       Das System soll überfällige, nicht beglichene Kundenrechnungen erkennen und dem Sachbearbeiter ermöglichen, sie in einem dreistufigen Mahnverfahren mit Nachvollziehbarkeit (Datum, Bearbeiter je Stufe) zu bearbeiten.
+Ergebnis:      Rechnung erhält eine erhöhte Mahnstufe inkl. Datum und ausführendem Mitarbeiter; ein Mahnschreiben kann erzeugt werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode UpdateInvoice - Begründung: Enthält den durchgesetzten switch-Statusautomaten inkl. Stempelung, inklusive throw bei Versuch, über Level3 hinaus zu mahnen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode GenerateInvoiceExpression - Begründung: Definiert die Selektionslogik mahnfähiger Rechnungen.
+Prüfidee:      Eine aktive, überfällige Rechnung ohne Mahnstufe wird nach Ausführung des Mahnlaufs auf Level1 mit gesetztem Datum/Bearbeiter geführt; ein erneuter Lauf auf einer Level3-Rechnung schlägt fehl (keine Level4).
+Tracelinks:    SyRS-001, SyRS-002, SwRS-001, SwRS-002, SwRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess der Debitorenbuchhaltung, im Zielsystem weiterhin zwingend erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-002
+Titel:         Auswertung offener Posten (OPOS) getrennt vom Mahnwesen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Offene Rechnungen/Gutschriften liegen vor.
+Fakt:          OposRunBL.ExecuteOposRun() erzeugt einen Kontoauszug-Report, verändert aber im Unterschied zu DunningRunBL keinen Rechnungszustand (kein Level-Update, keine Transaktionsklammer für Statusänderung) - reine Leseauswertung. OposBL.ThrowIfUserHasInsufficentRights() prüft dasselbe Recht (UserRightsConst.Controlling.Finances.Dunning), es existiert keine eigene UserRightsConst.Opos-Konstante.
+Aussage:       Das System soll eine reine Lese-Auswertung der offenen Posten je Kunde (Kontoauszug) bereitstellen, die unabhängig vom Mahnstatus einer Rechnung ist und keine Zustandsänderung an den Rechnungen vornimmt.
+Ergebnis:      PDF-Kontoauszug mit allen offenen Beträgen des Kunden, ohne Nebenwirkung auf Mahnstufen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun - Begründung: Zeigt, dass OPOS im Gegensatz zu Dunning keine persistente Zustandsänderung vornimmt (reine Reportgenerierung).
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Methode ThrowIfUserHasInsufficentRights - Begründung: Belegt die gemeinsame Rechtenutzung mit Dunning als fachliche Randbedingung (siehe Hypothese).
+Prüfidee:      Ausführen eines OPOS-Laufs für eine Rechnung verändert deren DunningLevel nicht.
+Tracelinks:    StRS-001, SyRS-003, SwRS-004
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - eigenständiger Auswertungsbedarf unabhängig vom Mahnwesen.
+Status:        belegt
+```
+
+```
+ID:            StRS-003
+Titel:         Automatisierte Vertragsabrechnung (Facturierung)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Vertragsmanagement
+Vorbedingung:  Ein aktiver Vertrag (VertragKopf, Status=1) mit definiertem Abrechnungsintervall liegt vor.
+Fakt:          AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract() verknüpft eine erzeugte Rechnung über die Tabelle VertragRechKopfZuordnung mit dem Vertrag und plant für automatische Abrechnungsverträge (ContractCalculationKind.Auto) die nächste Abrechnung als ToDo anhand von BillingIntervalKind/-Duration.
+Aussage:       Das System soll Verträge mit wiederkehrendem Abrechnungsintervall automatisiert zu Rechnungen verarbeiten und die jeweils nächste Abrechnung terminieren, ohne dass ein Sachbearbeiter jeden Abrechnungslauf manuell anstoßen muss.
+Ergebnis:      Neue Rechnung mit Verknüpfung zum Vertrag; Folgetermin für die nächste Abrechnung ist hinterlegt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract - Begründung: Enthält die konkrete Verknüpfungs- und Terminierungslogik für automatisch abgerechnete Verträge.
+Prüfidee:      Ein Vertrag mit ContractCalculationKind.Auto und monatlichem Intervall erzeugt nach Abrechnung einen Folgetermin ca. einen Monat später.
+Tracelinks:    SyRS-004, SwRS-005, SwRS-006
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Umsatzquelle für Vertragsgeschäft (MSP/Service).
+Status:        belegt
+```
+
+```
+ID:            StRS-004
+Titel:         Kontrollierte Stornierung von Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Eine aktive, nicht bereits stornierte Rechnung liegt vor.
+Fakt:          ReceiptInvoiceBL.CancelInvoice() prüft nacheinander sechs Bedingungen (Recht RIGHT_RECHNUNGSTORNIEREN, nicht bereits storniert, keine Barrechnung, nicht weiterverarbeitet, nicht bereits FiBu-exportiert, bei Vertragsrechnung: letzte Rechnung des Vertrags) und bricht bei Verletzung jeder einzelnen mit einer spezifischen Fehlermeldung ab.
+Aussage:       Das System soll die Stornierung einer Rechnung nur zulassen, wenn keine der sechs geschäftskritischen Ausschlussbedingungen (fehlendes Recht, bereits storniert, Barverkauf, bereits weiterverarbeitet, bereits exportiert, nicht letzte Vertragsrechnung) zutrifft, und dies dem Anwender mit konkreter Begründung mitteilen.
+Ergebnis:      Neue, als "storniert" markierte Rechnungsversion; Artikelmengen werden auf null gesetzt; Vorgang wird protokolliert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs, Methode CancelInvoice - Begründung: Enthält alle sechs geprüften Bedingungen im Klartext inkl. der jeweiligen Fehlermeldung und des Rechts RIGHT_RECHNUNGSTORNIEREN (ID 20400101).
+Prüfidee:      Der Stornoversuch einer bereits an die Finanzbuchhaltung exportierten Rechnung wird mit der Meldung "...bereits exportiert..." verweigert.
+Tracelinks:    SyRS-005, SwRS-007, SwRS-008
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch/prozessual zwingende Kontrolle für Rechnungskorrekturen.
+Status:        belegt
+```
+
+```
+ID:            StRS-005
+Titel:         Verwaltung von Zahlungseingängen und deren Verknüpfung zu Rechnungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Ein Zahlungseingang wurde erfasst oder aus dem Online-Banking-Abgleich zugeordnet.
+Fakt:          ReceiptBL.UpdateReceiptIsPaid() ist die zentrale, von PaymentsBL und dem OnlineBanking-Abgleich gemeinsam genutzte Methode; sie verweigert Zahlungsverbuchung/-stornierung auf stornierten Belegen und nutzt eine GUID-basierte optimistische Sperre (ConcurrencyControlGuid).
+Aussage:       Das System soll Zahlungseingänge einer Rechnung zuordnen, den bezahlten Betrag nachführen und dabei sicherstellen, dass stornierte Belege niemals als (un-)bezahlt markiert werden können und gleichzeitige Änderungen erkannt werden.
+Ergebnis:      Rechnung wechselt bei vollständiger Zahlung von "Active" zu "Completed"; bei Rückbuchung eines Zahlungseingangs wird der bezahlte Betrag korrekt reduziert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptIsPaid - Begründung: Enthält den Storno-Ausschluss, die Concurrency-Prüfung und den Statuswechsel als durchgesetzten Code.
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs, Methode DeleteIncomingPayment - Begründung: Belegt die Rechteprüfung (INCOMING_PAYMENT_TRANSACTIONS, ID 10980) vor Löschung eines Zahlungseingangs.
+Prüfidee:      Der Versuch, eine stornierte Rechnung als bezahlt zu markieren, wird mit einer Fehlermeldung abgelehnt.
+Tracelinks:    SyRS-006, SwRS-009, SwRS-010
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernbestandteil der Debitorenbuchhaltung.
+Status:        belegt
+```
+
+```
+ID:            StRS-006
+Titel:         Vertragsverwaltung mit Laufzeit- und Kündigungslogik
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsmanagement
+Vorbedingung:  Ein Vertrag mit Beginn, Laufzeitart und -dauer ist angelegt.
+Fakt:          ContractBL.RefreshContractEndeDate() berechnet das Vertragsende aus Beginn/Laufzeitart/-dauer, berücksichtigt automatische Verlängerung (AutoVerlaengerung) sowie Kündigungsfristen (KuendigungsFristArt1/-Dauer1); Verträge mit unvollständigen Basisdaten werden übersprungen statt den gesamten Batchlauf abzubrechen.
+Aussage:       Das System soll das Vertragsende automatisch aus Laufzeitregeln und ggf. hinterlegter Kündigung mit Fristenberechnung ermitteln und dabei einzelne unvollständig gepflegte Verträge von der Berechnung ausnehmen, ohne den Gesamtlauf zu gefährden.
+Ergebnis:      Aktualisiertes Vertragsenddatum je Vertrag; unvollständige Verträge werden zur Nachpflege markiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Methode RefreshContractEndeDate - Begründung: Enthält die tatsächliche Berechnungslogik inkl. Skip-Verhalten bei unvollständigen Daten.
+Prüfidee:      Ein Vertrag mit AutoVerlaengerung=1 ohne Kündigung bleibt nach Ablauf der ersten Laufzeit ohne Enddatum (offen); ein gekündigter Vertrag erhält ein Enddatum unter Berücksichtigung der Kündigungsfrist.
+Tracelinks:    SyRS-007, SwRS-011
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - vertragsrechtlich erforderliche Logik.
+Status:        belegt
+```
+
+```
+ID:            StRS-007
+Titel:         Abrechnung erfasster Ticketzeiten und Pauschalprojekte
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Serviceleitung
+Vorbedingung:  Zeiterfassungen (Timer) an einem Helpdesk-Ticket liegen vor, oder ein Auftrag mit Pauschal-Materialgruppenpositionen ist vorhanden.
+Fakt:          TimerBillingBL.SaveTimer() lehnt Zeiterfassungen mit Enddatum vor Startdatum hart ab ("negative Dauer"); FlatRateProjectViewModel berechnet den Pauschalbetrag als Summe aus Price*QuantityDisplay über alle Top-Level-Positionen mit BlanketMaterialGroup.
+Aussage:       Das System soll erfasste Ticketzeiten validiert (keine negative Dauer) zu Rechnungen verdichten und alternativ Aufträge mit pauschal abzurechnenden Positionen (Blanket-Materialgruppen) als Gesamtsumme abrechnen können.
+Ergebnis:      Rechnung mit verdichteten Zeitpositionen bzw. Pauschalbetrag.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, Methode SaveTimer - Begründung: Enthält die harte Validierung negativer Zeitdauer als ResultException.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectViewModel.cs, Zeile ~898 - Begründung: Zeigt die konkrete Summenformel für Pauschalabrechnung.
+Prüfidee:      Eine Zeiterfassung mit Stop < Start wird beim Speichern mit einer Fehlermeldung abgelehnt.
+Tracelinks:    SyRS-008, SwRS-012, SwRS-013
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Abrechnungsform für Servicegeschäft.
+Status:        belegt
+```
+
+```
+ID:            StRS-008
+Titel:         Sichere Verwaltung von Kundenzugangsdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-/Support-Mitarbeiter, Administrator
+Vorbedingung:  Für einen Kunden sind Zugangsdaten (Passwörter, VPN, RDP, SSH) hinterlegt.
+Fakt:          AccessManagementViewModel prüft je Mitarbeiter über PasswordManagerGuidelineRights (Flags: SealBreak, SealingAllowed, AccessDataEditable, AccessDataVisible, AccessDataDeletable, VPNAccessesEditable, TwoFactorAuthentification, Notification), ob Anzeige/Bearbeitung/Siegelbruch erlaubt ist; jede Aktion erzeugt einen Audit-Log-Eintrag; Zwischenablage wird nach 12 Sekunden automatisch geleert.
+Aussage:       Das System soll den Zugriff auf gespeicherte Kundenzugangsdaten feingranular je Mitarbeiter über Richtlinien steuern (Sichtbarkeit, Bearbeitbarkeit, Siegelbruch, Löschbarkeit getrennt), jede sicherheitsrelevante Aktion protokollieren und eine in die Zwischenablage kopierte Passwortangabe nach kurzer Zeit automatisch entfernen.
+Ergebnis:      Zugriff wird nur im Rahmen der zugewiesenen Rechte gewährt; Audit-Trail ist vollständig.
+Belege:
+  - [PRIMÄR]   src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs, Methode CurrentUserHasRight - Begründung: Zeigt die konkrete Flag-Prüfung je Rechteart.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs - Begründung: Definiert die durchgesetzte Flags-Enumeration der Einzelrechte.
+Prüfidee:      Ein Mitarbeiter ohne GuidelineRightSealBreak kann versiegelte Zugangsdaten nicht einsehen (Kommando ist deaktiviert); nach Kopieren eines Passworts ist die Zwischenablage nach 12 Sekunden leer.
+Tracelinks:    SyRS-009, SyRS-010, SwRS-014, SwRS-015, SwRS-016
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Modul ist im Code selbst als "(obsolate)" kommentiert (ModuleRegistration.cs, Zeile 802); Übernahme im Zielsystem ist mit dem Fachbereich zu klären.
+Status:        belegt
+```
+
+```
+ID:            StRS-009
+Titel:         Richtlinienbasierte Rechtevergabe im PasswordManager
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Guideline-Management ist aktiv (IsPasswordManagerGuidelineManagementActive).
+Fakt:          PasswordManagerBL.GetAvailableGuidelinesForEmployee() ermittelt per SQL-Join über PasswordManagerGuidelines/-Employees/-Departments/-Customers/-ExcludedCustomers, welche Kundenkategorien ein Mitarbeiter sehen darf, inkl. optionaler zeitlicher Befristung (LimitedValidityDateFrom/Until). Wird das Guideline-Management deaktiviert, erhalten laut explizitem UI-Warntext alle Mitarbeiter mit dem "Hotline"-Recht uneingeschränkten Zugriff.
+Aussage:       Das System soll den Zugriff auf Kundenzugangsdaten standardmäßig über zeitlich befristbare, kunden- und abteilungsbezogene Richtlinien steuern; wird diese Steuerung deaktiviert, muss dem Administrator explizit mitgeteilt werden, dass dies zu einem uneingeschränkten Zugriff aller Hotline-berechtigten Mitarbeiter führt.
+Ergebnis:      Nur Mitarbeiter mit passender, gültiger Richtlinie sehen die zugehörigen Kundenkategorien.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Methode GetAvailableGuidelinesForEmployee - Begründung: Enthält die tatsächliche, serverseitig durchgesetzte Scoping-Abfrage.
+  - [SEKUNDÄR] src/shared/Centron.Controls/PasswordManager/GuidelineManagementViewModel.cs, Methode ActivateGuidelines - Begründung: Enthält den expliziten Warntext zur Konsequenz einer Deaktivierung.
+Prüfidee:      Ein Mitarbeiter ohne passende Richtlinie für Kunde X sieht dessen Zugangsdatenkategorien nicht in der Liste.
+Tracelinks:    StRS-008, SyRS-009, SwRS-014
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - siehe StRS-008 (Modul als obsolet markiert).
+Status:        belegt
+```
+
+```
+ID:            StRS-010
+Titel:         Rollen- und rechtebasierte Zugriffssteuerung auf Module und Funktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator, alle Systembenutzer
+Vorbedingung:  Benutzer ist eingeloggt; Rechte wurden bei Login einmalig geladen.
+Fakt:          ModuleRegistration.DoRegisterCentronModules() lädt CurrentUserAppRights einmalig pro Session und filtert Module über ModuleRightsExpressionParser (unterstützt AND/OR/NOT über Helper.HasRights/HasAnyRight/NoRightCheck). SettingsContainerViewModel.LoadAllSettings() zeigt jedoch, dass ein Großteil der Administrations-Einstellungsseiten (u. a. CentronConfigDb, ExternalTools, PdfSigning, PhoneSettings, Profiling) nur durch das eine gemeinsame Recht Administration.SETTINGS geschützt ist, ohne seitenindividuelle Rechte.
+Aussage:       Das System soll den Zugriff auf Module grundsätzlich über eine pro Modul konfigurierbare, boolesch kombinierbare Rechteprüfung steuern; für die globale Einstellungsseite ist diese Steuerung jedoch grobgranular auf ein einzelnes Sammelrecht reduziert, was als Migrationsrisiko zu bewerten ist.
+Ergebnis:      Nur berechtigte Module erscheinen im Dashboard/Ribbon; nicht berechtigte Funktionen sind weder sichtbar noch ausführbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs - Begründung: Enthält die durchgesetzte Auswertungslogik für Rechteausdrücke.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/Settings/SettingsContainerViewModel.cs, Methode LoadAllSettings - Begründung: Belegt die grobgranulare Sammelprüfung für die Einstellungsseiten.
+Prüfidee:      Ein Benutzer ohne Administration.SETTINGS sieht keine der o. g. Einstellungsseiten; ein Benutzer mit diesem einen Recht sieht alle davon, unabhängig von fachlicher Zuständigkeit.
+Tracelinks:    SyRS-011, SyRS-012, SwRS-017, SwRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - die Sammelrechtsprüfung der Einstellungsseiten ist eine historisch gewachsene Vereinfachung, die im Zielsystem durch granularere Rechte ersetzt werden sollte.
+Status:        belegt
+```
+
+```
+ID:            StRS-011
+Titel:         Mandantenfähigkeit für Briefkopf, Bankverbindung und Belegnummernkreise
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Mehrere Mandanten sind im System angelegt.
+Fakt:          MandatorManagementViewModel verwaltet je Mandant Name, Adresse, bis zu vier Bankverbindungen und Briefkopf-Logos; MandatoryBL vergibt Belegnummernkreise (GetNumberGroup) je Mandant/Filiale mit Fallback auf den Standardmandanten. Es wurde KEINE Stelle gefunden, die Geschäftsdaten (Kunden, Belege) nach dem Mandanten des angemeldeten Benutzers filtert.
+Aussage:       Das System soll je Mandant eigene Briefkopf-, Bank- und Belegnummernkreis-Konfigurationen bereitstellen. [HYPOTHESE: Eine darüberhinausgehende Datenisolation zwischen Mandanten - im Sinne einer Zugriffsbeschränkung auf die dem eigenen Mandanten zugeordneten Geschäftsdaten - konnte im untersuchten Code nicht nachgewiesen werden; es fehlt die Information, ob dies serverseitig an anderer, nicht eingesehener Stelle erfolgt oder ob "Mandant" bewusst nur als Konfigurationskonstrukt ohne Datentrennung gedacht ist.]
+Ergebnis:      Belege tragen mandantenspezifische Nummernkreise und Briefkopfdaten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Methode DeleteMandatorAsync - Begründung: Zeigt, dass ein Mandant nicht gelöscht, sondern nur deaktiviert werden kann (Status=0), sofern keine aktive Filiale mehr zugeordnet ist.
+  - [KONTEXT]  src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Methode GetNumberGroup - Begründung: Einzige gefundene mandantenbezogene Fachlogik (Nummernkreise), kein Hinweis auf Datenisolation.
+Prüfidee:      Zwei Mandanten erzeugen Rechnungen aus unterschiedlichen Nummernkreisen; ein Benutzer, der nur für Mandant A zuständig ist, kann dennoch Kundendaten von Mandant B einsehen (zu verifizieren).
+Tracelinks:    SyRS-013, SwRS-019
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nummernkreis-/Briefkopftrennung bleibt erforderlich; die Frage der Datenisolation ist vor der Neuimplementierung fachlich zu klären.
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-012
+Titel:         DSGVO-konforme Löschung und Anonymisierung personenbezogener Daten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter, Administrator
+Vorbedingung:  Personenbezogene Daten (Ansprechpartner, Kundendaten) sind älter als konfigurierte Aufbewahrungsfristen oder eine gezielte Löschanfrage liegt vor.
+Fakt:          CentronDataSecurityViewModel trennt zwei Rechte: HasDatabaseCleanupRight (Massenbereinigung nach Alter, Default-Grenzen z. B. 3/10 Jahre) und HasContactDeleteRight (gezielte Löschung einzelner Kontakte inkl. Exportprotokoll). Die serverseitige Implementierung (IDataSecurityLogic.DsgvoDeleteRightDeleteContacts) wurde im Rahmen dieser Analyse nicht aufgefunden.
+Aussage:       Das System soll sowohl eine alters-/fristbasierte Massenbereinigung als auch eine gezielte, protokollierte Löschung einzelner Kontaktpersonen ermöglichen, jeweils durch ein eigenes Recht geschützt. [HYPOTHESE: Ob die Löschung technisch als Hard-Delete oder Anonymisierung erfolgt und ob sie auf verknüpfte Belege/Tickets kaskadiert, konnte nicht verifiziert werden - die Backend-Implementierung war im analysierten Codeausschnitt nicht auffindbar.]
+Ergebnis:      Personenbezogene Daten werden gemäß Fristen bzw. auf gezielte Anfrage entfernt; ein Löschprotokoll wird angeboten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs, Konstruktor (Zeile ~158) - Begründung: Zeigt die getrennte Rechteprüfung für Cleanup vs. gezielte Löschung.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityCustomerViewModel.cs, Methode DoDeleteAsync - Begründung: Zeigt Bestätigungsdialog und Angebot eines Löschprotokolls als UI-Fakt, jedoch ohne Einblick in die tatsächliche Backend-Löschmethodik.
+Prüfidee:      Nach gezielter Löschung eines Kontakts wird ein Löschprotokoll mit Zeitstempel angeboten.
+Tracelinks:    SyRS-014, SwRS-020
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch zwingend (DSGVO Art. 17).
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-013
+Titel:         Sichere Authentifizierung am System
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Alle Systembenutzer
+Vorbedingung:  Benutzer meldet sich mit Zugangsdaten oder über einen externen Identitätsanbieter an.
+Fakt:          AuthenticatorFactory wählt je nach konfigurierter SystemAuthenticationMethod zwischen BasicAuthenticator, ActiveDirectoryAuthenticator, WebAccountAuthenticator und OpenIdConnectAuthenticator. BasicAuthenticator vergleicht das Passwort als SHA1Decoder.GetDecodedSHA1String(password) gegen die gespeicherte AppUser.Password-Spalte - unsalted SHA-1, mit explizitem Code-Kommentar "// TODO the password should be salted!!!" (Zeile 48).
+Aussage:       Das System soll Benutzer wahlweise über lokale Zugangsdaten, Active-Directory/LDAP oder OpenID Connect authentifizieren. [HYPOTHESE nicht erforderlich - dies ist ein PRIMÄR belegter, durchgesetzter Zustand:] Für die Basic-Authentifizierung werden Passwörter aktuell als ungesalzener SHA-1-Hash gespeichert und verglichen, was dem Entwicklerteam selbst als Schwachstelle bekannt ist (eigener TODO-Kommentar im Code).
+Ergebnis:      Erfolgreiche Anmeldung erzeugt ein serverseitiges Auth-Ticket; bei BasicAuth besteht ein bekanntes, unbehobenes Sicherheitsrisiko durch fehlendes Salting.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 48 - Begründung: Zeigt sowohl den ungesalzenen SHA-1-Vergleich als auch den Entwickler-eigenen TODO-Kommentar zur bekannten Schwachstelle.
+  - [PRIMÄR]   src/backend/Centron.Common/TextCoding/SHA1Decoder.cs - Begründung: Enthält die tatsächliche Hash-Implementierung (SHA1, hex-codiert, ohne Salt).
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs - Begründung: Belegt die Auswahl zwischen den vier Authentifizierungsverfahren.
+Prüfidee:      Zwei Benutzer mit identischem Passwort erzeugen denselben Hashwert in der Datenbank (Nachweis für fehlendes Salting).
+Tracelinks:    SyRS-015, SyRS-016, SwRS-021, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: veraltet - die Basic-Authentifizierung mit ungesalzenem SHA-1 ist im Zielsystem durch ein modernes, gesalzenes/adaptives Hashverfahren (z. B. bcrypt/Argon2) oder ausschließlich OpenID Connect zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            StRS-014
+Titel:         Lizenzgesteuerte Freischaltung von Anwendungen und Einzelfunktionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Kunde, Administrator
+Vorbedingung:  Eine Lizenz-GUID ist für den Kunden/die Installation beim Lizenzserver hinterlegt.
+Fakt:          Jede Lizenz ist eine GUID (LicenseGuids.cs) mit optionalem count, valid-until-date und valid-until-version; "Applications" (ApplicationKind.cs) dürfen sich zusätzlich am Webservice anmelden, "Only Licenses" schalten nur einzelne Funktionen/Module frei (LicenseManager.Instance.HasLicense(...)).
+Aussage:       Das System soll Anwendungen und einzelne Funktionen granular über eine GUID-basierte Lizenzprüfung freischalten, wobei Lizenzen zusätzlich mengen- und zeitmäßig begrenzt werden können.
+Ergebnis:      Nicht lizenzierte Module/Funktionen sind weder im Dashboard sichtbar noch nutzbar.
+Belege:
+  - [PRIMÄR]   docs/reference/security/licensing-system.md - Begründung: Entwicklerdokumentation beschreibt den durchgesetzten Mechanismus inkl. Codebeispiel LicenseManager.Instance.HasLicense.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs - Begründung: CheckModuleFeatures() nutzt denselben Mechanismus zur Modulfreischaltung.
+Prüfidee:      Ein Kunde ohne Lizenz LicenseGuids.PasswordManager sieht das Modul PasswordManager nicht im Dashboard.
+Tracelinks:    SyRS-017, SwRS-023
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernbestandteil des Geschäftsmodells (Lizenzverkauf).
+Status:        belegt
+```
+
+```
+ID:            StRS-015
+Titel:         Ticketbearbeitung im Kundenservice (Helpdesk)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-/Service-Mitarbeiter
+Vorbedingung:  Ein Kundenanliegen liegt vor oder ein Ticket existiert bereits.
+Fakt:          Es existiert keine feste Status-Enumeration; Ticketstatus ist vollständig durch admin-konfigurierbare HelpdeskStatusDTO-Datensätze bestimmt. TicketLogicHelper.GetTicketAndPromptUnlock() implementiert ein pessimistisches Sperrverfahren (TicketIsLocked) mit Anzeige des sperrenden Mitarbeiters und Möglichkeit zum erzwungenen Entsperren.
+Aussage:       Das System soll Tickets mit einem vollständig durch den Administrator konfigurierbaren Statusmodell führen und dabei paralleles Bearbeiten durch Sperrung mit Anzeige des aktuellen Bearbeiters und optionalem Zwangsentsperren verhindern.
+Ergebnis:      Ticket ist eindeutig einem Bearbeiter zugeordnet; Statuswechsel sind nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Methode GetTicketAndPromptUnlock - Begründung: Enthält das durchgesetzte Sperr-/Entsperrverfahren.
+  - [KONTEXT]  CentronRights.md, Abschnitt Helpdesk - Begründung: Dokumentiert die zugehörigen Rechte in Prosaform als ergänzenden Kontext.
+Prüfidee:      Ein zweiter Mitarbeiter, der ein gesperrtes Ticket öffnet, erhält einen Dialog mit dem Namen des sperrenden Kollegen und die Option zum Entsperren.
+Tracelinks:    SyRS-018, SyRS-019, SwRS-024, SwRS-025
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des Kundenservice.
+Status:        belegt
+```
+
+```
+ID:            StRS-016
+Titel:         Fälligkeitsüberwachung von Tickets (SLA-Transparenz ohne automatisierte Eskalation)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, Hotline-Mitarbeiter
+Vorbedingung:  Tickets mit Fälligkeitsdatum (DueDate) und ggf. SLA-Priorität sind offen.
+Fakt:          TicketDueDateDashboardContainerViewModel.CalculateGroups() gruppiert offene Tickets in "Überfällig" (DueDate<Now), "In 4 Stunden" und "Heute", gefiltert nach der Prioritäts-Eigenschaft IsSLA. Es wurde KEINE automatisierte Aktion (Statuswechsel, Neuzuweisung, Benachrichtigung) gefunden, die bei Fälligkeitsüberschreitung ausgelöst wird - lediglich eine Dashboard-Anzeige.
+Aussage:       Das System soll fällige und überfällige SLA-relevante Tickets in einem Dashboard sichtbar machen. [HYPOTHESE: Eine automatisierte Eskalationslogik (Statuswechsel, Reassignment, aktive Benachrichtigung bei SLA-Verletzung) konnte im untersuchten Code nicht nachgewiesen werden, obwohl ein Modul "EscalationsSettings" existiert - dessen Inhalt wurde nicht bis zur Ebene einer automatisierten Aktion vertieft.]
+Ergebnis:      Dashboard zeigt Anzahl überfälliger/bald fälliger SLA-Tickets; keine automatische Folgeaktion nachgewiesen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/TicketDueDate/TicketDueDateDashboardContainerViewModel.cs, Methode CalculateGroups - Begründung: Enthält die tatsächliche, durchgesetzte Gruppierungslogik.
+Prüfidee:      Ein Ticket mit abgelaufenem DueDate erscheint im Dashboard unter "Überfällig", ändert aber ohne manuelles Eingreifen weder Status noch Bearbeiter.
+Tracelinks:    StRS-015, SyRS-019, SwRS-026
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - eine reine Dashboard-Anzeige ersetzt keine automatisierte SLA-Eskalation; im Zielsystem sollte geprüft werden, ob eine echte Eskalationsautomatik ergänzt wird.
+Status:        HYPOTHESE
+```
+
+```
+ID:            StRS-017
+Titel:         Pflicht zur Checklistenabarbeitung vor Ticketabschluss
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Hotline-Mitarbeiter
+Vorbedingung:  Dem Ticket ist eine Checkliste zugeordnet.
+Fakt:          TicketDetailViewModel.CanCloseHelpdeskByChecklist() ruft serverseitig ITicketLogic.CanHelpdeskClose(helpdeskI3D) auf; liefert der Server CanClose==false, wird das Schließen mit den vom Server gelieferten Meldungen blockierend verweigert.
+Aussage:       Das System soll den Abschluss eines Tickets verweigern, solange eine zugeordnete Checkliste nicht vollständig abgearbeitet ist, und dem Bearbeiter die konkret fehlenden Punkte mitteilen.
+Ergebnis:      Ticket kann erst nach vollständiger Checkliste geschlossen werden.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailViewModel.cs, Methode CanCloseHelpdeskByChecklist (Zeile ~2217) - Begründung: Enthält den durchgesetzten Blockademechanismus.
+Prüfidee:      Ein Ticket mit unvollständiger Pflichtchecklist kann nicht geschlossen werden; der Dialog nennt die offenen Punkte.
+Tracelinks:    StRS-015, SyRS-018, SwRS-027
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - qualitätssichernder Prozessschritt.
+Status:        belegt
+```
+
+```
+ID:            StRS-018
+Titel:         Retourenabwicklung mit Lieferanten (RMA)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Serviceleitung, Hotline-Mitarbeiter
+Vorbedingung:  Ein defekter/zu tauschender Artikel eines Kunden liegt vor; ein Ticket ist vorhanden oder wird angelegt.
+Fakt:          RmaArticleState (Enum, 20 Werte: none…Removed) und RmaForthAction (EqualChange, ForeignChange, Repair, Scapped, UnRepair, Disabled u. a.) bilden den durchgesetzten Zustandsraum. SendBack (Versand zum Lieferanten) und SendForth (Rückkehr vom Lieferanten inkl. gewählter Aktion) sind die beiden zentralen Teilschritte, beide gegen das Recht RIGHT_RMAARTIKELSTATUSAENDERN geschützt.
+Aussage:       Das System soll RMA-Vorgänge als zweistufigen Prozess (Versand an den Lieferanten, anschließende Rücknahme mit Auswahl der Lösung) mit einem vollständigen Artikelzustandsmodell abbilden und 1:1 an ein Helpdesk-Ticket koppeln.
+Ergebnis:      Artikel durchläuft nachvollziehbare RMA-Zustände bis zur endgültigen Lösung (Reparatur/Austausch/Verschrottung).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Interfaces/CustomerArea/RmaArticleState.cs - Begründung: Enthält die vollständige, durchgesetzte Zustandsenumeration.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode CheckForthState - Begründung: Enthält die konkrete Validierung (z. B. Pflichtfeld Austauschseriennummer bei EqualChange).
+Prüfidee:      Beim Versuch, eine SendForth-Aktion "ForeignChange" ohne Ersatzartikelcode zu speichern, wird die Speicherung mit "Speichern ist unmöglich" verweigert.
+Tracelinks:    SyRS-020, SyRS-021, SwRS-028, SwRS-029
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - etablierter Serviceprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-019
+Titel:         Physische Bestandsführung (Lagerartikel, Bestand, Reservierung)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter, Einkauf
+Vorbedingung:  Artikel sind im Lager geführt; Bestellungen/Aufträge existieren.
+Fakt:          ArticleStock.StockAvailable = StockAmount - (StockInOrder ?? 0); Zugriff auf ArticleManagement ist über zwei Rechte (Purchase.ID UND Purchase.StockList.ID) geschützt, sonst wird das Modul mit "Sie haben kein Recht..." verweigert.
+Aussage:       Das System soll den verfügbaren Lagerbestand als Buchbestand abzüglich bereits reservierter/in Bestellung befindlicher Mengen ausweisen und den Zugriff auf die Artikelverwaltung an den gleichzeitigen Besitz zweier spezifischer Rechte binden.
+Ergebnis:      Verfügbarkeitsanzeige je Artikel/Lagerort; Artikelverwaltung nur für berechtigte Mitarbeiter zugänglich.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/ArticleStock.cs, Property StockAvailable - Begründung: Enthält die durchgesetzte Verfügbarkeitsformel.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleController.cs - Begründung: Enthält die doppelte Rechteprüfung als Öffnungs-Gate.
+Prüfidee:      Ein Artikel mit Buchbestand 10 und 3 Stück in offener Bestellung (StockInOrder) zeigt eine Verfügbarkeit von 7.
+Tracelinks:    SyRS-022, SwRS-030, SwRS-031
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion der Warenwirtschaft.
+Status:        belegt
+```
+
+```
+ID:            StRS-020
+Titel:         Verwaltung und automatische Preisumrechnung von Umsatzsteuersätzen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Ein Umsatzsteuersatz läuft aus oder ändert sich gesetzlich.
+Fakt:          ValueAddedTaxViewModel.Save() erzwingt genau einen Standard-Steuersatz (Default), verhindert doppelte Folge-Satz-Zuordnung und bietet beim Wechsel auf einen Folgesatz zwei Umrechnungsstrategien: Netto konstant (Brutto = Netto*(1+neuerSatz)) oder Brutto konstant (Netto = Brutto/(1+neuerSatz)).
+Aussage:       Das System soll bei gesetzlichen Steuersatzänderungen eine Folge-Satz-Verkettung mit Gültigkeitsdatum abbilden und dem Anwender die Wahl lassen, ob bei der Umstellung der Netto- oder der Bruttopreis der betroffenen Artikel konstant gehalten wird.
+Ergebnis:      Artikelpreise werden gemäß gewählter Strategie konsistent auf den neuen Steuersatz umgerechnet.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs, Methoden Save/UpdateArticles - Begründung: Enthält beide durchgesetzten Umrechnungsformeln und die Default-Satz-Validierung.
+Prüfidee:      Beim Umstellen aller Artikel einer Materialgruppe von 19% auf einen neuen Satz mit Strategie "Netto konstant" bleibt der Nettopreis unverändert, der Bruttopreis ändert sich entsprechend.
+Tracelinks:    SyRS-023, SwRS-032
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich erforderliche Funktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-021
+Titel:         Bedarfsermittlung und Bestellvorschlagswesen (BVL)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf
+Vorbedingung:  Artikel unterschreiten Mindestbestand oder Kundenaufträge erfordern Nachbestellung.
+Fakt:          SuggestionQuantity.SetToBookingValue() berechnet ToBooking = OrderItemQuantity + MinimumQuantity - AvailableQuantity - Intake - ConsignmentQuantity; bei aktiver Sonderpreisvereinbarung wird AvailableQuantity separat aus SpecialAgreementQuantity statt dem allgemeinen Bestand gebildet. GetDistributorI3D() wählt den Lieferanten nach bis zu drei kombinierbaren, vom Anwender priorisierten Kriterien (Preis, Verfügbarkeit, A-/B-/C-Lieferant).
+Aussage:       Das System soll die zu bestellende Menge je Artikel aus offenem Bedarf, Mindestbestand, verfügbarem Bestand, eingehender Ware und ggf. separat geführtem Sonderpreis-Kontingent errechnen und die Lieferantenauswahl anhand konfigurierbarer, priorisierbarer Kriterien automatisieren.
+Ergebnis:      Vorgeschlagene Bestellmenge und -lieferant je Artikel.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/Others/SuggestionQuantity.cs, Methode SetToBookingValue - Begründung: Enthält die vollständige, durchgesetzte Bedarfsformel.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs, Methode GetDistributorI3D - Begründung: Enthält die durchgesetzte Lieferantenauswahllogik.
+Prüfidee:      Ein Artikel mit Mindestbestand 10, aktuellem Bestand 4 und keiner offenen Bestellung erzeugt einen Bestellvorschlag über 6 Stück.
+Tracelinks:    SyRS-024, SwRS-033, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Einkaufsfunktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-022
+Titel:         Elektronischer Belegaustausch mit Lieferanten (EDI, inkl. ZUGFeRD)
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf
+Vorbedingung:  Ein Lieferant sendet Auftragsbestätigung/Lieferschein/Rechnung elektronisch (klassisches EDI oder ZUGFeRD-XML).
+Fakt:          EDIPositionRelationState ([Flags]: NoDifference, WithQuantityDifference, WithPriceDifference, WithDeliveryDateDifference, BadBarcode) klassifiziert jede EDI-Position; die Übernahme wird verweigert, solange keine einzige Position zugeordnet ist (RelationState != None). Invoice-Recht erfordert zusätzlich zum Wareneingangsrecht das Kalkulationsrecht (RIGHT_KALKULATION).
+Aussage:       Das System soll eingehende EDI-Belege (inkl. ZUGFeRD-Rechnungen) automatisiert gegen die eigene Bestellung abgleichen, Abweichungen in Menge/Preis/Liefertermin/Barcode kennzeichnen und die Übernahme der Rechnungsdaten an ein zusätzliches Kalkulationsrecht binden.
+Ergebnis:      EDI-Positionen sind mit Abweichungskennzeichnung dem Anwender zur Freigabe vorgelegt; nur berechtigte Mitarbeiter können Rechnungsdaten übernehmen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIReceiptTabs/EDIPositionRelationState.cs - Begründung: Enthält die durchgesetzte Flags-Klassifikation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIManagementAppViewModel.cs, Property IsNewInvoiceRight - Begründung: Enthält die kombinierte Rechteprüfung.
+Prüfidee:      Eine EDI-Rechnung mit ausschließlich unabgeglichenen Positionen kann nicht akzeptiert werden.
+Tracelinks:    SyRS-025, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendig für effiziente Beschaffung.
+Status:        belegt
+```
+
+```
+ID:            StRS-023
+Titel:         Physische Inventur mit Zustandsmodell und Abschlussoptionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lagermitarbeiter
+Vorbedingung:  Eine Inventursitzung wurde eröffnet.
+Fakt:          InventoryState-Enum (Open, Closed, Deleted, OpenWithoutBC, ClosedWithoutBC) unterscheidet Zählungen mit/ohne Barcode-/Seriennummererfassung; FinalizeInventoryEnum (Partial, PartialAllStorages, Complete, CompleteAllStorages) und FinalizeStorageEnum (AllStorages, SelectedStorages) steuern den Umfang des Inventurabschlusses.
+Aussage:       Das System soll Inventuren wahlweise mit oder ohne Barcode-/Seriennummererfassung durchführen und den Abschluss granular auf einzelne oder alle Lagerorte, vollständig oder teilweise, ermöglichen.
+Ergebnis:      Inventur wird mit dem gewählten Abschlussumfang finalisiert; Zählstand ist nachvollziehbar dokumentiert.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/ViewModels/InventoryViewModels/InventoryViewModel.cs - Begründung: Enthält das durchgesetzte InventoryState-Enum.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums/FinalizeInventoryEnum.cs, FinalizeStorageEnum.cs - Begründung: Enthalten die durchgesetzten Abschlussoptionen.
+Prüfidee:      Eine Inventur im Modus "OpenWithoutBC" kann ohne Seriennummererfassung geschlossen werden.
+Tracelinks:    SyRS-026, SwRS-036
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich/betriebswirtschaftlich erforderliche Funktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-024
+Titel:         Export von Belegdaten an Finanzbuchhaltungssysteme
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung / Steuerberater
+Vorbedingung:  Abgeschlossene Rechnungen/Gutschriften liegen vor.
+Fakt:          DatevOnlineViewModel.Export() erzeugt für jede gewählte Rechnung ein ZIP-Paket (LedgerXML + DocumentXML + PDF) im DATEV-Unternehmen-Online-Format; Centron.Gateway enthält zusätzlich eigenständige Export-/Import-Adapter für Addison, Abacus, SAP, Sage, Lexware, Navision (je IBookKeepingExport/IBookKeepingImportDataToCentron).
+Aussage:       Das System soll Belegdaten wahlweise im DATEV-Unternehmen-Online-Format oder über spezialisierte Adapter in eine Reihe weiterer Finanzbuchhaltungssysteme exportierbar machen.
+Ergebnis:      ZIP-Paket bzw. Exportdatei im Zielformat des jeweiligen FiBu-Systems.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs, Methode Export - Begründung: Enthält die durchgesetzte Paketerzeugung.
+  - [SEKUNDÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/* - Begründung: Ordnerstruktur belegt Existenz mehrerer Adapterimplementierungen (nicht einzeln vertieft).
+Prüfidee:      Export einer Rechnung erzeugt eine ZIP-Datei mit package.xml und document.xml.
+Tracelinks:    SyRS-027, SwRS-037
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - regulatorisch/prozessual notwendig.
+Status:        belegt
+```
+
+```
+ID:            StRS-025
+Titel:         SEPA-Zahlungsverkehr und Bankkontenanbindung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Fällige Zahlungen (Lastschrift/Überweisung) oder Kontobewegungen liegen vor.
+Fakt:          Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2 erzeugt SEPA-pain.008-Dateien; OnlineBankingServiceVersionType-Enum (HBCI, FinTS, EBICS_H004, EBICS_H005) und die Alternative über den Aggregator finAPI (Centron.APIs.FinAPI) bilden zwei parallele Wege der Kontoanbindung.
+Aussage:       Das System soll SEPA-Zahlungsdateien für Lastschrift/Überweisung erzeugen und Kontobewegungen wahlweise über direkte Bankprotokolle (HBCI/FinTS/EBICS) oder über den Aggregator finAPI abrufen und mit offenen Rechnungen abgleichen.
+Ergebnis:      SEPA-Datei zur Einreichung bei der Bank; abgeglichene Kontobewegungen mit Zahlungsstatus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/SepaFileGeneratorV2.cs - Begründung: Enthält die durchgesetzte SEPA-Dateierzeugung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings/Helper/OnlineBankingServiceVersionType.cs - Begründung: Enthält die durchgesetzten unterstützten Protokolle.
+Prüfidee:      Eine Sammellastschrift über mehrere fällige Rechnungen erzeugt eine gültige pain.008-XML-Datei.
+Tracelinks:    SyRS-028, SwRS-038, SwRS-039
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion des Zahlungsverkehrs.
+Status:        belegt
+```
+
+```
+ID:            StRS-026
+Titel:         Integration mit Distributor- und Marktplatzplattformen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb
+Vorbedingung:  Ein Distributor-/Marktplatzzugang ist konfiguriert.
+Fakt:          Sechs eigenständige externe Produktdaten-/Bestellintegrationen wurden nachgewiesen: COP (SOAP), EGIS (Katalog + volles EDI im Gateway), ITscope (REST/XML), Icecat (REST/XML), Wortmann (Sonderpreisimport) und Deutsche Telekom D!VE (XML-Export von Angebotspositionen).
+Aussage:       Das System soll Artikelstammdaten, Preise und Bestellprozesse mit mehreren externen Distributor- und Marktplatzplattformen konsistent austauschen können, ohne die einzelnen Integrationen fachlich zu vermischen.
+Ergebnis:      Aktuelle Produktdaten/Preise aus externen Quellen; Bestellungen/Angebote werden an die jeweilige Plattform übermittelt.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.APIs.EgisDataAccess/EgisApi.cs - Begründung: Belegt eine der sechs eigenständigen Integrationen im Detail.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/TelekomDive/TelekomDiveExportViewModel.cs - Begründung: Belegt die D!VE-Integration als UI-seitigen Exportvorgang.
+Prüfidee:      Eine Artikelsuche über die ITscope-Integration liefert Produktdaten inkl. Lieferanten- und Preisinformation.
+Tracelinks:    SyRS-029, SwRS-040
+Konsolidierung: Kandidat: Die sechs Integrationen bilden fachlich denselben Grundvorgang „externe Produktdaten/Bestellung beziehen" mit unterschiedlichen Protokollen; im Zielsystem ist ein einheitliches Adapterkonzept zu prüfen.
+Übernahmewürdigkeit: übernehmen - wesentlicher Bestandteil der Beschaffungsstrategie.
+Status:        belegt
+```
+
+```
+ID:            StRS-027
+Titel:         Anbindung von Versanddienstleistern
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Versand-/Lagermitarbeiter
+Vorbedingung:  Ein Paket ist versandfertig kommissioniert.
+Fakt:          CentronGlsLogic.UploadShipment() (REST, GLS) und CentronShipcloudLogic (REST, shipcloud.io, Multi-Carrier) sind zwei eigenständige, parallel implementierte Versanddienstleister-Anbindungen mit jeweils eigener Authentifizierung.
+Aussage:       Das System soll Versandaufträge wahlweise über die GLS-Direktanbindung oder über den Multi-Carrier-Dienst shipcloud.io elektronisch an den jeweiligen Paketdienstleister übermitteln.
+Ergebnis:      Versandlabel/Trackingnummer wird erzeugt und dem Lieferschein zugeordnet.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs, Methode UploadShipment - Begründung: Enthält den durchgesetzten Versandauftrag an GLS.
+  - [PRIMÄR]   src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs - Begründung: Enthält die parallele shipcloud-Anbindung.
+Prüfidee:      Eine Sendung wird über shipcloud angelegt und liefert eine gültige Trackingnummer zurück.
+Tracelinks:    SyRS-030, SwRS-041
+Konsolidierung: Kandidat: GLS-Direktanbindung und shipcloud-Multi-Carrier-Anbindung decken fachlich denselben Vorgang „Versandlabel erzeugen" ab; im Zielsystem auf ein gemeinsames Versand-Interface konsolidierbar.
+Übernahmewürdigkeit: übernehmen - notwendig für Versandprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-028
+Titel:         Verwaltung von Kunden-/Adressstammdaten und CRM-Aktivitäten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Kundenservice
+Vorbedingung:  Eine Adresse/ein Kunde existiert oder wird neu angelegt.
+Fakt:          CrmAppModuleController (ModuleName "Adressstamm") verwaltet Adressen, CRM-Aktivitäten und Belege gemeinsam; AccountManagementAppModuleController ergänzt eine Suche nach noch nicht zu Kunden konvertierten Adressen.
+Aussage:       Das System soll Adress- und Kundenstammdaten zentral verwalten, CRM-Aktivitäten dokumentieren und die Konvertierung einer Adresse zum vollwertigen Kunden unterstützen.
+Ergebnis:      Konsistenter Kunden-/Adressstamm als Basis für Vertrieb, Service und Abrechnung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmAppModuleController.cs - Begründung: Bestätigt Modulzweck und -bezeichnung.
+Prüfidee:      Eine als Adresse angelegte Firma kann über AccountManagement in einen vollwertigen Kunden konvertiert werden.
+Tracelinks:    SyRS-031, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basisdatenverwaltung für alle Folgeprozesse.
+Status:        belegt
+```
+
+```
+ID:            StRS-029
+Titel:         Massenänderung von Preisen und Belegdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb
+Vorbedingung:  Preisänderungen (z. B. jährliche Preisanpassung) betreffen viele Artikel/Konten gleichzeitig.
+Fakt:          UpdateArticlePricesViewModel erzwingt eine gegenseitige Ausschlussvalidierung zwischen prozentualer und fixer Preisanpassung (EK/VK): Setzen eines Prozentwerts löscht automatisch den zugehörigen Fixwert und umgekehrt.
+Aussage:       Das System soll Massenänderungen an Einkaufs- und Verkaufspreisen wahlweise prozentual oder als Festwert ermöglichen, wobei beide Eingabearten je Preisart gegenseitig exklusiv sind, um widersprüchliche Anpassungen zu verhindern.
+Ergebnis:      Konsistent angepasste Preise über die gewählte Artikelmenge.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdateArticlePricesViewModel.cs - Begründung: Enthält die durchgesetzte gegenseitige Exklusivität der Eingabefelder.
+Prüfidee:      Eingabe eines Prozentwerts für die VK-Preisanhebung löscht einen zuvor eingegebenen Fixwert automatisch.
+Tracelinks:    SyRS-032, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - effizienter Massenpflegeprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-030
+Titel:         Kostenstellen- und Kostenträgerrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Controlling
+Vorbedingung:  Kostenstellen/-träger sind zur Zuordnung von Belegen benötigt.
+Fakt:          PayersAndCostCenterAppModuleControllerViewModel führt Soft-Delete/Restore getrennt für Kostenstellen und Kostenträger (jeweils eigene ShowDeleted-Flags und Wiederherstellungskommandos).
+Aussage:       Das System soll Kostenstellen und Kostenträger getrennt verwalten und gelöschte Einträge reversibel (Soft-Delete mit Wiederherstellung) statt destruktiv entfernen.
+Ergebnis:      Kostenstellen-/-trägerliste bleibt auch nach Löschung wiederherstellbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs - Begründung: Enthält die getrennten Soft-Delete-/Restore-Kommandos.
+Prüfidee:      Eine gelöschte Kostenstelle erscheint bei aktivem Filter "gelöschte anzeigen" und kann wiederhergestellt werden.
+Tracelinks:    SyRS-033, SwRS-044
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardanforderung des Controllings.
+Status:        belegt
+```
+
+```
+ID:            StRS-031
+Titel:         Fertigungsauftrags- und Maschinenverwaltung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktionsplanung
+Vorbedingung:  Ein Kundenauftrag enthält produktionsrelevante Artikel.
+Fakt:          ProductionOrderManagementViewModel verknüpft OrderWithProductionArticlesDTO (Auftrag mit produktionsrelevanten Artikeln) mit ProductionOrderDTO und ordnet Maschinen (ProductionMachineDTO) sowie Maschinenarten mit je eigenen Produktionsschritt-Beschreibungen zu.
+Aussage:       Das System soll aus Kundenaufträgen mit produktionsrelevanten Artikeln Fertigungsaufträge ableiten und diesen Maschinen sowie maschinenartspezifische Produktionsschritte zuordnen.
+Ergebnis:      Fertigungsauftrag mit zugeordneter Maschine und Produktionsschritten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/ProductionOrderManagementViewModel.cs - Begründung: Enthält die durchgesetzte Verknüpfungslogik.
+Prüfidee:      Ein Auftrag mit produktionsrelevantem Artikel erzeugt einen Fertigungsauftrag, der einer Maschine zugewiesen werden kann.
+Tracelinks:    SyRS-034, SwRS-045
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - für Kunden mit eigener Fertigung erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-032
+Titel:         Produktlebenszyklus-Verfolgung (PLM)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktmanagement
+Vorbedingung:  Produktfamilien mit Lebenszyklusdaten sind gepflegt.
+Fakt:          PlmViewModel filtert nach Status (ShowOnlyActive/Expired/Deactivated) und Beratern (bis zu vier benannte Advisor-Felder); PlmLogViewModel führt eine Änderungshistorie je Produktlebenszyklus-Eintrag.
+Aussage:       Das System soll den Lebenszyklusstatus von Produktfamilien mit zugeordneten Beratern nachvollziehbar verwalten und Änderungen historisieren.
+Ergebnis:      Aktueller Lebenszyklusstatus je Produktfamilie mit Änderungshistorie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PLM/PlmViewModel.cs - Begründung: Enthält die durchgesetzten Statusfilter.
+Prüfidee:      Eine Statusänderung einer Produktfamilie erscheint im PLM-Log mit Zeitstempel.
+Tracelinks:    SyRS-035, SwRS-046
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - unterstützt Sortimentssteuerung.
+Status:        belegt
+```
+
+```
+ID:            StRS-033
+Titel:         Auswertungen, Kennzahlen und Management-Reporting
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Controlling
+Vorbedingung:  Verkaufs-, Ticket- und Mitarbeiterdaten liegen vor.
+Fakt:          ManagementInfoViewModel liefert tages-/monatsbezogene Umsatz-, Gewinn-, Angebots- und Auftragsbestandskennzahlen je Filiale/Materialgruppe; MspCollectorViewModel plant zusätzlich wiederkehrende, konfigurierbare Datenabholungen (u. a. ArrowSphere) für den MSP-Lizenzabgleich.
+Aussage:       Das System soll tages- und monatsbezogene betriebswirtschaftliche Kennzahlen bereitstellen und zusätzlich wiederkehrend Nutzungs-/Lizenzdaten externer MSP-Distributoren zum Abgleich mit eigenen Verträgen einholen.
+Ergebnis:      Management-Dashboard mit Kennzahlen; automatisch aktualisierte MSP-Vergleichsdaten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs - Begründung: Enthält die durchgesetzten Kennzahlenabfragen.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Statistics/MspCollectors/MspCollectorViewModel.cs - Begründung: Belegt die konfigurierbare Wiederholungsplanung als UI-Fakt.
+Prüfidee:      Das Management-Dashboard zeigt für den aktuellen Monat Umsatz- und Gewinnzahlen je Filiale.
+Tracelinks:    SyRS-036, SwRS-047
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Steuerungsgrundlage.
+Status:        belegt
+```
+
+```
+ID:            StRS-034
+Titel:         KI-gestützte Assistenzfunktionen mit Zugriff auf Geschäftsdaten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Systembenutzer
+Vorbedingung:  KI-Funktion ist lizenziert/aktiviert.
+Fakt:          ArtificialIntelligenceChatCoordinator begrenzt einen agentenhaften Chat-Dialog auf maximal 50 Werkzeug-Runden (_maximumClientToolRounds=50) und bindet Werkzeuge für Konten, Artikel, Mitarbeiter, Belege, Tickets, Navigation sowie optionale Websuche über einen IArtificialIntelligenceToolConfirmationService (Bestätigungspflicht vor Aktionsausführung) ein.
+Aussage:       Das System soll einen KI-Chat-Assistenten bereitstellen, der lesend und schreibend auf Geschäftsdaten (Konten, Artikel, Mitarbeiter, Belege, Tickets) zugreifen kann, wobei jede Werkzeugaktion einer Bestätigung durch den Anwender bedarf und die Anzahl der Werkzeugaufrufe je Dialog begrenzt ist.
+Ergebnis:      KI-Antwort bzw. ausgeführte Aktion nach Bestätigung durch den Anwender.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceChatCoordinator.cs - Begründung: Enthält die durchgesetzte Rundenbegrenzung und den Bestätigungsmechanismus.
+Prüfidee:      Eine vom KI-Assistenten vorgeschlagene Datenänderung wird erst nach expliziter Bestätigung durch den Anwender ausgeführt.
+Tracelinks:    SyRS-037, SwRS-048
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zukunftsgerichtete Funktion, im Zielsystem auszubauen.
+Status:        belegt
+```
+
+```
+ID:            StRS-035
+Titel:         Persönlicher Arbeitsbereich (Mein Tag, Kalender, Telefonie)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Mitarbeiter
+Vorbedingung:  Mitarbeiter ist angemeldet.
+Fakt:          MyDayConnector bündelt Tickets, Timer, Mitarbeiter- und Mailvorlagendaten zu einer Tagesübersicht; TelephonyConnector bindet TAPI-basierte Telefonanlagenintegration (Call/AcceptCall/DeclineCall/DisconnectCall) inkl. Anruferbild-Anzeige ein.
+Aussage:       Das System soll dem Mitarbeiter eine tagesbezogene Übersicht seiner Tickets, Zeiten und Aufgaben bereitstellen und eine TAPI-basierte Telefonieanbindung mit Anrufersteuerung und Bildanzeige integrieren.
+Ergebnis:      Tagesübersicht je Mitarbeiter; eingehende Anrufe zeigen Kontaktbild und erlauben Annahme/Ablehnung direkt aus der Anwendung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/MyDayConnector.cs - Begründung: Enthält die durchgesetzte Datenaggregation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs - Begründung: Enthält die durchgesetzte TAPI-Anbindung.
+Prüfidee:      Ein eingehender Anruf eines bekannten Kunden zeigt dessen Kontaktbild im Popup.
+Tracelinks:    SyRS-038, SwRS-049
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - produktivitätsfördernde Zusatzfunktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-036
+Titel:         Zentrale Systemkonfiguration und Stammdatenverwaltung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Administrator
+Vorbedingung:  Grundkonfiguration der Installation (Länder, Empfangsbedingungen, Mitarbeiter, externe Tools) ist erforderlich.
+Fakt:          GetSettingsWithoutModule() registriert eine flache, ungegliederte Liste von >15 Einstellungsseiten (CentronConfigDb, ExternalTools, EscalationType, PdfSigning, PhoneSettings, Profiling, MailAndCalender/General, DocSync u. a.) ohne individuelle Rechteprüfung je Seite (siehe StRS-010).
+Aussage:       Das System soll grundlegende Stammdaten (Länder, Empfangsbedingungen, Zuschlagssätze, Mitarbeiter, externe Werkzeuge) sowie technische Einstellungen zentral administrierbar machen.
+Ergebnis:      Konsistente Stammdatenbasis für alle Fachmodule.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode GetSettingsWithoutModule - Begründung: Enthält die vollständige, durchgesetzte Liste der Einstellungsseiten.
+Prüfidee:      Ein neu angelegtes Land steht in der Kundenadresserfassung sofort zur Auswahl.
+Tracelinks:    StRS-010, SyRS-011, SwRS-050
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendige Konfigurationsbasis.
+Status:        belegt
+```
+
+```
+ID:            StRS-037
+Titel:         Web-Self-Service und Warenkorb für Kunden (Nexus/WebCart)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde (Web-Account)
+Vorbedingung:  Ein Web-Account ist im c-entron-Adressstamm angelegt und mit Sonderpreisen versehen.
+Fakt:          Laut README.md ist WebCart primär für Kunden der Kunden gedacht: nach Login als Web-Account kann im c-entron Nexus über "Shop" auf die eigenen Sonderpreise zugegriffen werden.
+Aussage:       Das System soll Endkunden über einen separaten Web-Login den Zugriff auf ihre individuell vereinbarten Sonderpreise und eine Bestellfunktion (Warenkorb) ermöglichen, ohne Zugriff auf interne c-entron-Funktionen zu gewähren.
+Ergebnis:      Kunde sieht im Webportal ausschließlich seine freigegebenen Artikel/Preise und kann bestellen.
+Belege:
+  - [PRIMÄR]   README.md, Abschnitt „Contributing/WebCart" - Begründung: Beschreibt den durchgesetzten fachlichen Ablauf aus Entwicklersicht.
+  - [SEKUNDÄR] src/nexus/CentronNexus/WebCart/* (laut Recherche vorhanden) - Begründung: Bestätigt die technische Existenz des WebCart-Bereichs in Nexus.
+Prüfidee:      Ein Web-Account-Login zeigt im Shop-Bereich ausschließlich die für den Kunden hinterlegten Sonderpreisartikel.
+Tracelinks:    SyRS-039, SwRS-051
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basis für künftige SaaS-/Kundenportal-Strategie.
+Status:        belegt
+```
+
+```
+ID:            StRS-038
+Titel:         Outlook-Integration zur Ticket-Mail-Zuordnung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Hotline-Mitarbeiter
+Vorbedingung:  Mitarbeiter nutzt Outlook mit installiertem c-entron-Add-in.
+Fakt:          Manifest.xml des CentronNexus.OutlookAddIn deklariert ein MailApp-Add-in mit ReadWriteItem-Berechtigung, das E-Mails direkt Tickets/Kunden zuordnen kann; Middleware UseAllowXFrameOptionsForCentronNexus()/UseOutlookCookiePolicy() erlaubt das Einbetten von Nexus im Outlook-Taskbereich.
+Aussage:       Das System soll es Mitarbeitern ermöglichen, E-Mails direkt aus Outlook heraus bestehenden Tickets oder Kunden zuzuordnen bzw. neue Tickets aus E-Mails zu erzeugen.
+Ergebnis:      E-Mail ist im c-entron-Kontext (Ticket/Kunde) sichtbar, ohne Outlook verlassen zu müssen.
+Belege:
+  - [PRIMÄR]   src/nexus/CentronNexus.OutlookAddIn/Manifest/Manifest.xml - Begründung: Enthält die durchgesetzte Berechtigungsdeklaration und den Anwendungsfall.
+Prüfidee:      Eine markierte E-Mail kann über das Add-in einem bestehenden Ticket zugeordnet werden.
+Tracelinks:    SyRS-040, SwRS-052
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - deutliche Effizienzsteigerung im Serviceprozess.
+Status:        belegt
+```
+
+```
+ID:            StRS-039
+Titel:         Qualitätsmanagement: standardisierte Reklamationsgründe je Belegart
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Qualitätsmanagement
+Vorbedingung:  Reklamationen/Rücksendungen zu Bestellungen, Gutschriften, Lieferscheinen etc. erfordern eine Begründung.
+Fakt:          QmSettingsViewModel konfiguriert sieben parallele AssetReasonSettingsViewModel-Instanzen (Bestellung, Gutschrift-Lieferant, Lieferschein-Lieferant, Rechnung-Lieferant, Abholschein, Gutschrift-Kunde, Lieferschein-Kunde) mit jeweils eigenem Grundkatalog an Gründen.
+Aussage:       Das System soll für jede relevante Beleg-/Rücksendeart einen eigenen, administrierbaren Katalog standardisierter Gründe bereitstellen, damit Reklamationen einheitlich klassifiziert werden können.
+Ergebnis:      Jede Reklamation/Rücksendung trägt einen aus dem passenden Katalog gewählten Grund.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs - Begründung: Enthält die sieben durchgesetzten, getrennten Grundkataloge.
+Prüfidee:      Eine Lieferanten-Gutschrift verlangt die Auswahl eines Grundes aus dem dafür vorgesehenen Katalog.
+Tracelinks:    SyRS-041, SwRS-053
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - unterstützt strukturierte Reklamationsauswertung.
+Status:        belegt
+```
+
+```
+ID:            StRS-040
+Titel:         Import projektspezifischer Sonderpreise mit Differenzprüfung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Einkauf
+Vorbedingung:  Ein Lieferant/Projekt liefert eine Preisliste als Excel-Datei.
+Fakt:          ProjectPriceImportViewModel matcht Excel-Zeilen gegen bestehende SpecialAgreementDTO-Datensätze und Artikel; DifferenceViewModel zeigt Preisdifferenzen zwischen neuem Import und bestehender Sonderpreisvereinbarung vor dem endgültigen Import (CanImport-Gate).
+Aussage:       Das System soll importierte projektspezifische Sonderpreise vor der Übernahme gegen bestehende Vereinbarungen abgleichen und Preisdifferenzen dem Anwender zur Prüfung vorlegen, bevor der Import bestätigt werden kann.
+Ergebnis:      Nur geprüfte, bestätigte Preisänderungen werden übernommen; nicht zuordenbare Zeilen werden als Fehler ausgewiesen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportViewModel.cs - Begründung: Enthält die durchgesetzte Matching- und Differenzprüfung.
+Prüfidee:      Ein Import mit abweichendem Preis zu einer bestehenden Sonderpreisvereinbarung zeigt die Differenz vor dem endgültigen Import an.
+Tracelinks:    SyRS-042, SwRS-054
+Konsolidierung: Kandidat: ProjectPriceImport (Sales/Finances) und SpecialArticleToContractImport (Sales) bilden fachlich denselben Grundvorgang „Sonderpreis-Import mit Differenzprüfung" mit unterschiedlichen Quellformaten (Wortmann, generisches Excel).
+Übernahmewürdigkeit: übernehmen - reduziert manuellen Pflegeaufwand bei Sonderpreisen.
+Status:        belegt
+```
+
+```
+ID:            StRS-041
+Titel:         Interne Umfragen als konfigurierbarer Workflow-Prozess
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Qualitätsmanagement, Personalabteilung
+Vorbedingung:  Eine Umfrage/ein Fragebogen soll erstellt und ausgewertet werden.
+Fakt:          SurveyMainViewModel modelliert Umfragen als generische Workflow-Prozesse (Centron.Data.Entities.Services.Workflows) statt als eigenständige Umfrage-Engine; unterstützte Fragetypen sind CheckChoice, FreeText, MultipleChoice, Scala, YesNo.
+Aussage:       Das System soll Umfragen als konfigurierbare Workflow-Prozesse mit mehreren Fragetypen abbilden und deren Ergebnisse auswertbar machen.
+Ergebnis:      Auswertbare Umfrageergebnisse je Fragetyp.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Survey/SurveyMainViewModel.cs - Begründung: Belegt die Modellierung als Workflow-Prozess.
+Prüfidee:      Eine Umfrage mit einer Skalenfrage liefert nach Beantwortung einen auswertbaren Zahlenwert.
+Tracelinks:    SyRS-043, SwRS-055
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zusatznutzen für Kundenzufriedenheitsmessung.
+Status:        belegt
+```
+
+```
+ID:            StRS-042
+Titel:         Mehrschichtige Softwarearchitektur mit einheitlichem Datenzugriffsmuster
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Entwicklungsteam
+Vorbedingung:  Ein neues oder bestehendes Modul benötigt Datenzugriff sowohl per Direktverbindung als auch per Webservice.
+Fakt:          Jedes Modul MUSS laut Entwicklerdokumentation sowohl eine direkte NHibernate-basierte BL-Implementierung als auch eine WS-Implementierung hinter derselben ILogic-Schnittstelle bereitstellen (ClassContainer-Pattern, Result<T>-Fehlerbehandlung, async/await durchgängig).
+Aussage:       Das System soll für jedes Fachmodul einen einheitlichen Datenzugriff über eine gemeinsame Schnittstelle (ILogic) anbieten, die wahlweise per Direktverbindung zur Datenbank oder per Webservice bedient wird, um Wartbarkeit und Austauschbarkeit der Zugriffsart sicherzustellen.
+Ergebnis:      Ein Modul funktioniert unverändert sowohl im Direktverbindungs- als auch im Webservice-Betrieb.
+Belege:
+  - [PRIMÄR]   docs/getting-started/general-structure.md - Begründung: Enthält die durchgesetzte Architekturvorgabe inkl. Codebeispielen (verbindliche Entwicklerrichtlinie, kein bloßer Kommentar).
+Prüfidee:      Ein Modul, das gegen CentronConnectionType.SqlServer getestet wurde, funktioniert unverändert gegen CentronConnectionType.CentronWebServices.
+Tracelinks:    SyRS-044, SwRS-056, SwRS-057
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Architekturprinzip, im Zielsystem ggf. durch reine API-first-Architektur zu ersetzen.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/SyRS.md

@@ -0,0 +1,890 @@
+# System Requirements Specification (SyRS)
+
+Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen, abgeleitet aus den StRS-Anforderungen.
+
+---
+
+```
+ID:            SyRS-001
+Titel:         Selektionsregel für mahnfähige Rechnungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Mahnlauf)
+Vorbedingung:  Mahnlauf wird gestartet.
+Fakt:          DunningBL.GenerateInvoiceExpression() kombiniert vier Filterbedingungen (State==Active, DunningLevel-Filter, NextDueDateInDays-Filter, Toleranztage) zu einem Prädikat.
+Aussage:       Das System muss Rechnungen ausschließlich anhand des kombinierten Prädikats (aktiv, fällig, ggf. mit Toleranztagen) als mahnfähig einstufen und darf keine stornierten oder bereits vollständig bezahlten Rechnungen einbeziehen.
+Ergebnis:      Nur tatsächlich mahnfähige Rechnungen werden im Mahnlauf berücksichtigt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Methode GenerateInvoiceExpression - Begründung: Enthält das vollständige, kombinierte Filterprädikat.
+Prüfidee:      Eine bezahlte (Completed) Rechnung erscheint nicht im Mahnlauf, auch wenn ihr DueDate in der Vergangenheit liegt.
+Tracelinks:    StRS-001, SwRS-001
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Regel ist fachlich korrekt und muss im Zielsystem erhalten bleiben.
+Status:        belegt
+```
+
+```
+ID:            SyRS-002
+Titel:         Mahnstufen-Zustandsautomat mit Rücksetzfunktion
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Rechnung befindet sich in einer Mahnstufe ungleich None.
+Fakt:          DunningRunBL.ResetDunningRun() kehrt die Stufenerhöhung exakt um (Level3→Level2→Level1→None), löscht die zugehörigen Datums-/Bearbeiterfelder und markiert den zugehörigen DunningRunItem als gelöscht, alles innerhalb einer Transaktionsklammer (StartTransaction/CommitTransaction/RollbackTransaction).
+Aussage:       Das System muss eine transaktional abgesicherte Rücksetzfunktion für Mahnstufen bereitstellen, die den Zustand exakt symmetrisch zur Erhöhung zurückführt und bei einem bereits auf None stehenden Datensatz eine Ausnahme wirft statt stillschweigend nichts zu tun.
+Ergebnis:      Mahnstufe und zugehörige Metadaten sind nach Rücksetzung konsistent mit dem Zustand vor der letzten Erhöhung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Methode ResetDunningRun - Begründung: Enthält den transaktional abgesicherten, durchgesetzten Rücksetzautomaten.
+Prüfidee:      Rücksetzung einer Rechnung auf Mahnstufe None wirft eine ArgumentOutOfRangeException.
+Tracelinks:    StRS-001, SwRS-002, SwRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-003
+Titel:         Schreibfreie Auswertungsfunktion für offene Posten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  OPOS-Lauf wird ausgeführt.
+Fakt:          OposRunBL.ExecuteOposRun() ruft für SendType nur Mail/Print unterstützend auf; None/Fax führen zu ArgumentException; anders als DunningRunBL wird keine Transaktionsklammer für eine Zustandsänderung geöffnet.
+Aussage:       Das System muss die OPOS-Auswertung als reinen Lesevorgang implementieren, der ausschließlich Mail- oder Druckversand als Auslieferungsweg unterstützt und unter keinen Umständen den Rechnungszustand verändert.
+Ergebnis:      Kontoauszug wird per Mail oder Druck ausgeliefert, Rechnungsdaten bleiben unverändert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs, Methode ExecuteOposRun - Begründung: Belegt die auf Mail/Print begrenzte, zustandsfreie Auslieferung.
+Prüfidee:      Ein OPOS-Lauf mit SendType=Fax schlägt mit ArgumentException fehl.
+Tracelinks:    StRS-002, SwRS-004
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-004
+Titel:         Terminierung der Folgeabrechnung bei automatischer Vertragsfacturierung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Vertrag mit ContractCalculationKind.Auto wird abgerechnet.
+Fakt:          StoreInvoiceToContract() plant den Folgetermin abhängig von BillingIntervalKind/-Duration; für BillingKinds.Billingarrear wird der Termin über NextDate(contract) berechnet statt über die Standardintervall-Addition.
+Aussage:       Das System muss nach jeder automatischen Vertragsabrechnung einen Folgetermin gemäß dem konfigurierten Abrechnungsintervall setzen und dabei nachträgliche Abrechnung ("Billingarrear") mit einer eigenen Terminberechnung behandeln.
+Ergebnis:      ToDo-Eintrag mit korrektem Folgeabrechnungstermin.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs, Methode StoreInvoiceToContract - Begründung: Enthält die durchgesetzte Terminierungslogik inkl. Sonderfall Billingarrear.
+Prüfidee:      Ein nachträglich abgerechneter Vertrag (Billingarrear) erhält einen anderen Folgetermin als ein vorschüssig abgerechneter Vertrag mit gleichem Intervall.
+Tracelinks:    StRS-003, SwRS-005, SwRS-006
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-005
+Titel:         Sechsfache Vorbedingungsprüfung vor Rechnungsstorno
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Stornoanfrage für eine Rechnung liegt vor.
+Fakt:          ReceiptInvoiceBL.CancelInvoice() prüft der Reihe nach: Recht RIGHT_RECHNUNGSTORNIEREN, State!=Canceled, !IsCashAsset, keine ForwardedInto-Einträge, !IsReceiptExported, bei Vertragsrechnung IsLastContractInvoice; jede Verletzung liefert eine spezifische Fehlermeldung als Result.AsError.
+Aussage:       Das System muss vor jeder Rechnungsstornierung alle sechs Bedingungen unabhängig voneinander prüfen und bei Verletzung einer beliebigen Bedingung die Stornierung mit einer für den Anwender verständlichen, bedingungsspezifischen Fehlermeldung verweigern.
+Ergebnis:      Rechnung wird nur storniert, wenn alle sechs Bedingungen erfüllt sind.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs, Methode CancelInvoice - Begründung: Enthält alle sechs durchgesetzten Prüfungen im Klartext.
+Prüfidee:      Storno einer Barrechnung (IsCashAsset=true) wird mit "...Barrechnung..." abgelehnt, unabhängig vom Zustand der übrigen fünf Bedingungen.
+Tracelinks:    StRS-004, SwRS-007, SwRS-008
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-006
+Titel:         Optimistische Sperre und Storno-Schutz bei Zahlungsverbuchung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Zahlbetrag wird einer Rechnung zugeordnet oder entfernt.
+Fakt:          ReceiptBL.UpdateReceiptIsPaid() vergleicht bei übergebenem concurrencyControlGuid diesen gegen receipt.ConcurrencyControlGuid und liefert bei Abweichung DefaultMessageCodes.ChangedByOtherInstance; State==Canceled führt unabhängig davon zu sofortiger Ablehnung.
+Aussage:       Das System muss gleichzeitige Änderungen an einer Rechnung durch eine GUID-basierte optimistische Sperre erkennen und explizit als "durch andere Instanz geändert" kennzeichnen, und muss unabhängig davon jede Zahlungszuordnung zu einer stornierten Rechnung verhindern.
+Ergebnis:      Keine widersprüchlichen Zahlungsbuchungen bei parallelem Zugriff; keine Zahlungszuordnung zu stornierten Rechnungen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, Methode UpdateReceiptIsPaid - Begründung: Enthält beide durchgesetzten Schutzmechanismen.
+Prüfidee:      Zwei parallele Zahlungsbuchungen auf derselben Rechnung mit veralteter ConcurrencyControlGuid führen bei der zweiten zu ChangedByOtherInstance.
+Tracelinks:    StRS-005, SwRS-009, SwRS-010
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-007
+Titel:         Fehlertolerante Batch-Berechnung von Vertragsenddaten
+Ebene:         SyRS
+Typ:           Zuverlässigkeit
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        System
+Vorbedingung:  Batchlauf zur Aktualisierung aller aktiven Vertragsenddaten wird gestartet.
+Fakt:          RefreshContractEndeDate() überspringt Verträge mit fehlenden Basisdaten (Beginn/LaufzeitArt/LaufzeitDauer) statt eine Exception zu werfen, die den gesamten Batchlauf abbrechen würde (Kommentar im Code bestätigt dies als bewusste Entscheidung).
+Aussage:       Das System muss bei der Batch-Berechnung von Vertragsenddaten einzelne unvollständig gepflegte Verträge überspringen und zur Nachpflege kennzeichnen, ohne dass dies den Abschluss des Gesamtlaufs für alle übrigen Verträge verhindert.
+Ergebnis:      Alle vollständig gepflegten Verträge erhalten ein aktuelles Enddatum; unvollständige Verträge werden separat ausgewiesen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Methode RefreshContractEndeDate - Begründung: Enthält das durchgesetzte Skip-Verhalten.
+Prüfidee:      Ein Vertrag ohne LaufzeitArt beendet den Batchlauf nicht; alle übrigen Verträge werden dennoch aktualisiert.
+Tracelinks:    StRS-006, SwRS-011
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-008
+Titel:         Validierung von Zeiterfassungen und Berechnung der Pauschalsumme
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Zeiterfassung wird gespeichert bzw. ein Pauschalauftrag wird berechnet.
+Fakt:          TimerBillingBL.SaveTimer() wirft ResultException bei Stop<Start; FlatRateProjectViewModel summiert Price*QuantityDisplay ausschließlich über Top-Level-Positionen (Indent==0) mit BlanketMaterialGroup.
+Aussage:       Das System muss Zeiterfassungen mit negativer Dauer strukturell verhindern und die Pauschalsumme ausschließlich aus den vorgesehenen Top-Level-Positionen einer Blanket-Materialgruppe bilden, ohne Unterpositionen doppelt zu berücksichtigen.
+Ergebnis:      Keine negativen Zeiterfassungen im System; korrekte, nicht doppelt gezählte Pauschalsumme.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs, Methode SaveTimer - Begründung: Enthält die durchgesetzte Validierung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/FlatRateProjectViewModel.cs - Begründung: Enthält die durchgesetzte Summenformel.
+Prüfidee:      Eine Unterposition (Indent>0) einer Blanket-Materialgruppe fließt nicht separat in die Pauschalsumme ein.
+Tracelinks:    StRS-007, SwRS-012, SwRS-013
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-009
+Titel:         Feingranulare, richtlinienbasierte Zugriffskontrolle auf Zugangsdaten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Mitarbeiter greift auf Kundenzugangsdaten zu.
+Fakt:          PasswordManagerGuidelineRights ist ein [Flags]-Enum mit acht unabhängigen Einzelrechten (SealBreak, SealingAllowed, AccessDataEditable, AccessDataVisible, VPNAccessesEditable, TwoFactorAuthentification, Notification, AccessDataDeletable); GetAvailableGuidelinesForEmployee() wertet diese serverseitig zusätzlich zeitlich befristet (LimitedValidityDateFrom/Until) und kundenbezogen aus.
+Aussage:       Das System muss den Zugriff auf Kundenzugangsdaten anhand von acht unabhängig kombinierbaren, serverseitig geprüften Einzelrechten je Kunde und optional zeitlich befristet steuern.
+Ergebnis:      Zugriff wird exakt im Rahmen der zugewiesenen, ggf. befristeten Richtlinien gewährt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Interfaces/PasswordManager/PasswordManagerGuidelineRights.cs - Begründung: Enthält die durchgesetzte Flags-Enumeration.
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Methode GetAvailableGuidelinesForEmployee - Begründung: Enthält die serverseitig durchgesetzte, zeitlich befristbare Scoping-Logik.
+Prüfidee:      Nach Ablauf von LimitedValidityDateUntil verliert ein Mitarbeiter automatisch den Zugriff auf die betroffene Kundenkategorie.
+Tracelinks:    StRS-008, StRS-009, SwRS-014, SwRS-015
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - siehe StRS-008.
+Status:        belegt
+```
+
+```
+ID:            SyRS-010
+Titel:         Automatische Löschung sensibler Daten aus der Zwischenablage
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Ein Passwort wurde in die Zwischenablage kopiert.
+Fakt:          AccessManagementViewModel.CopyPasswordToClipboard() setzt einen Task.Delay(TimeSpan.FromSeconds(12)) zur automatischen Leerung der Zwischenablage.
+Aussage:       Das System muss ein in die Zwischenablage kopiertes Passwort spätestens nach 12 Sekunden automatisch wieder entfernen, um versehentliches Einfügen an unbeabsichtigter Stelle nach Ablauf der Nutzungssituation zu verhindern.
+Ergebnis:      Zwischenablage enthält 12 Sekunden nach dem Kopiervorgang kein Klartextpasswort mehr.
+Belege:
+  - [PRIMÄR]   src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs, Methode CopyPasswordToClipboard - Begründung: Enthält den durchgesetzten Timer.
+Prüfidee:      13 Sekunden nach Kopieren eines Passworts ist die Zwischenablage leer.
+Tracelinks:    StRS-008, SwRS-016
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-011
+Titel:         Boolesch kombinierbare Rechteprüfung zur Modulfreischaltung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Benutzer meldet sich an; Module werden registriert.
+Fakt:          ModuleRightsExpressionParser unterstützt AND/OR/NOT-verknüpfte Rechteausdrücke (HasRights, HasAnyRight, NoRightCheck); ModuleRegistration.DoRegisterCentronModules() wendet CheckModuleFeatures() (Lizenz) UND CheckRights() (Recht) kumulativ an.
+Aussage:       Das System muss die Sichtbarkeit jedes Moduls anhand einer booleschen Kombination von Rechten UND einer unabhängigen Lizenzprüfung bestimmen; beide Bedingungen müssen erfüllt sein, damit ein Modul registriert wird.
+Ergebnis:      Ein Modul erscheint nur, wenn sowohl Rechte- als auch Lizenzprüfung positiv ausfallen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs - Begründung: Enthält die durchgesetzte Ausdrucksauswertung.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs, Methode DoRegisterCentronModules - Begründung: Enthält die kumulative Verknüpfung von Recht und Lizenz.
+Prüfidee:      Ein Benutzer mit passendem Recht aber ohne Lizenz sieht das Modul nicht.
+Tracelinks:    StRS-010, SwRS-017
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-012
+Titel:         Session-weites Caching der Benutzerrechte
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Performanz-Effizienz
+Akteur:        System
+Vorbedingung:  Benutzer ist eingeloggt.
+Fakt:          CentronCache.RefreshCacheAsync() lädt CurrentUserAppRights einmalig bei Login (und nach Einstellungsänderungen) und hält sie im Session-Cache; nachfolgende Prüfungen (ModuleRegistration.IsModuleAvailable, SettingsContainerViewModel u. a.) lesen ausschließlich aus diesem Cache statt bei jeder Prüfung den Server erneut abzufragen.
+Aussage:       Das System soll die Benutzerrechte einmal je Session laden und clientseitig zwischenspeichern, um wiederholte Serveranfragen bei jeder einzelnen Rechteprüfung zu vermeiden, und den Cache gezielt nach relevanten Änderungen aktualisieren.
+Ergebnis:      Rechteprüfungen erfolgen ohne zusätzlichen Netzwerk-Roundtrip pro Prüfung.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs, Methode RefreshCacheAsync - Begründung: Enthält den durchgesetzten Caching-Mechanismus.
+Prüfidee:      Eine Rechteänderung wird erst nach explizitem Cache-Refresh (z. B. nach erneutem Login) client-seitig wirksam.
+Tracelinks:    StRS-010, SwRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Cache-Invalidierung bei Live-Rechteänderung ist im Zielsystem zu prüfen (aktuelles Verhalten: verzögert bis Refresh).
+Status:        belegt
+```
+
+```
+ID:            SyRS-013
+Titel:         Mandantenbezogene Vergabe von Belegnummernkreisen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein neuer Beleg (z. B. Rechnung) wird für eine Filiale erzeugt.
+Fakt:          MandatoryBL.GetNumberGroup()/GetNumberGroupsForBranch() lösen den Nummernkreis über die Filiale-Mandant-Zuordnung auf, mit Fallback auf den Standardmandanten, falls die Filiale keinem spezifischen Mandanten zugeordnet ist.
+Aussage:       Das System muss jedem neu erzeugten Beleg den Nummernkreis des Mandanten zuordnen, dem die auslösende Filiale zugeordnet ist, und bei fehlender Zuordnung auf den Standardmandanten zurückfallen.
+Ergebnis:      Belegnummer stammt aus dem korrekten, mandantenspezifischen Nummernkreis.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs, Methode GetNumberGroup - Begründung: Enthält die durchgesetzte Fallback-Logik.
+Prüfidee:      Eine Rechnung aus einer Filiale ohne explizite Mandantenzuordnung erhält eine Nummer aus dem Nummernkreis des Standardmandanten.
+Tracelinks:    StRS-011, SwRS-019
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-014
+Titel:         Getrennte Rechte für Massenbereinigung und gezielte Kontaktlöschung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  DSGVO-Modul ist lizenziert und geöffnet.
+Fakt:          CentronDataSecurityViewModel berechnet HasDatabaseCleanupRight und HasContactDeleteRight unabhängig voneinander aus zwei verschiedenen UserRightsConst.DsgvoModule-Konstanten; jedes der beiden Kommandos (CanRefresh/CanDeleteSelection vs. CanAnonymizeContactPerson) ist an genau eines der beiden Rechte gebunden.
+Aussage:       Das System muss die Berechtigung zur alters-/fristbasierten Massenbereinigung und die Berechtigung zur gezielten Löschung einzelner Kontakte als zwei unabhängig vergebbare Rechte führen.
+Ergebnis:      Ein Mitarbeiter kann eines der beiden Rechte besitzen, ohne automatisch das andere zu erhalten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs, Konstruktor - Begründung: Enthält die durchgesetzte getrennte Rechteauswertung.
+Prüfidee:      Ein Mitarbeiter mit nur HasContactDeleteRight kann keine Massenbereinigung starten.
+Tracelinks:    StRS-012, SwRS-020
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-015
+Titel:         Auswahl des Authentifizierungsverfahrens je Installation
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Anmeldeversuch eines Benutzers.
+Fakt:          AuthenticatorFactory wählt anhand der konfigurierten SystemAuthenticationMethod (None/Basic/ActiveDirectory/OpenIdConnect, aus AppSettingsGroupBL.GetAuthenticationSettings()) den konkreten Authenticator, optional mit FallbackAuthenticator-Verkettung.
+Aussage:       Das System muss je Installation genau ein konfiguriertes primäres Authentifizierungsverfahren verwenden und darf optional ein Fallback-Verfahren verketten, ohne dass der Anwender das Verfahren pro Login manuell wählt.
+Ergebnis:      Anmeldung erfolgt konsistent über das für die Installation konfigurierte Verfahren.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs - Begründung: Enthält die durchgesetzte Verfahrensauswahl.
+Prüfidee:      Eine Installation mit SystemAuthenticationMethod=ActiveDirectory lehnt einen reinen Benutzername/Passwort-Login gegen die lokale AppUser-Tabelle ab (sofern kein Fallback konfiguriert ist).
+Tracelinks:    StRS-013, SwRS-021
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Auswahlmechanismus bleibt, konkretes Basic-Verfahren ist zu ersetzen (siehe StRS-013).
+Status:        belegt
+```
+
+```
+ID:            SyRS-016
+Titel:         Serverseitige Validierung und Ausstellung eines Auth-Tickets
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System (Webservice)
+Vorbedingung:  Ein API-Aufruf trägt ein Ticket im access_token-Query-Parameter oder Authorization-Header.
+Fakt:          TicketAuthenticationHandler extrahiert das Token und validiert es über AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod); bei Erfolg wird ein ClaimsPrincipal mit NameIdentifier, UserIdentifier und AuthenticationTypeIdentifier (unterscheidet "Ticket" von persistentem "AccessToken") gebildet.
+Aussage:       Das System muss jeden Webservice-Aufruf gegen ein serverseitig gültiges, IP- und methodenbezogen geprüftes Auth-Ticket validieren und zwischen kurzlebigen Login-Tickets und persistenten Zugriffstoken unterscheiden.
+Ergebnis:      Nur Aufrufe mit gültigem Ticket werden verarbeitet; Art des Tokens ist im Sicherheitskontext nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs - Begründung: Enthält die durchgesetzte Validierung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs, Methode GetAuthTicketInfo - Begründung: Enthält die serverseitige Ticketprüfung.
+Prüfidee:      Ein Aufruf mit abgelaufenem/ungültigem Ticket wird mit 401 abgelehnt.
+Tracelinks:    StRS-013, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-017
+Titel:         Mengen- und zeitbegrenzte Lizenzprüfung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine lizenzpflichtige Funktion wird aufgerufen.
+Fakt:          LicenseManager.Instance.HasLicense(guid)/GetLicenseCount(guid) prüfen neben dem reinen Besitz einer Lizenz-GUID auch count, valid-until-date und valid-until-version.
+Aussage:       Das System muss bei jeder lizenzpflichtigen Funktion neben dem Besitz der Lizenz auch deren Mengenbegrenzung, zeitliche und versionsbezogene Gültigkeit prüfen und die Funktion bei Überschreitung verweigern.
+Ergebnis:      Lizenzpflichtige Funktionen sind nur innerhalb der vereinbarten Menge/Gültigkeit nutzbar.
+Belege:
+  - [PRIMÄR]   docs/reference/security/licensing-system.md - Begründung: Beschreibt die durchgesetzte, mehrdimensionale Lizenzprüfung mit Codebeispiel.
+Prüfidee:      Der vierte Import-Vorgang bei einer auf 3 begrenzten Lizenz (z. B. MyDayImports) wird verweigert.
+Tracelinks:    StRS-014, SwRS-023
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-018
+Titel:         Pessimistische Ticketsperre mit Zwangsentsperrung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Ticket ist von einem anderen Mitarbeiter geöffnet und gesperrt.
+Fakt:          TicketLogicHelper.GetTicketAndPromptUnlock() zeigt bei TicketIsLocked==true einen Ja/Nein-Dialog mit dem aufgelösten Kurzzeichen des sperrenden Mitarbeiters und bietet erzwungenes Entsperren an.
+Aussage:       Das System muss ein gesperrtes Ticket eindeutig als solches kennzeichnen, den sperrenden Mitarbeiter benennen und dem zweiten Anwender die bewusste Entscheidung zum Zwangsentsperren überlassen, statt automatisch zu entsperren.
+Ergebnis:      Kein stillschweigender Verlust von Bearbeitungen durch gleichzeitigen Zugriff.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Methode GetTicketAndPromptUnlock - Begründung: Enthält den durchgesetzten Sperrdialog.
+Prüfidee:      Ein zweiter Mitarbeiter erhält beim Öffnen eines gesperrten Tickets den Namen des Sperrenden angezeigt.
+Tracelinks:    StRS-015, SwRS-024, SwRS-025
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-019
+Titel:         Dashboard-Kennzeichnung SLA-relevanter, fälliger Tickets
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Offene Tickets mit Fälligkeitsdatum liegen vor.
+Fakt:          TicketDueDateDashboardContainerViewModel.CalculateGroups() bildet drei Gruppen (Überfällig, In4Stunden, Heute) und filtert optional auf IsSLA==true.
+Aussage:       Das System muss offene Tickets nach ihrem zeitlichen Abstand zur Fälligkeit in mindestens drei Dringlichkeitsstufen gruppieren und eine Filterung auf SLA-relevante Tickets ermöglichen.
+Ergebnis:      Dashboard zeigt Anzahl der Tickets je Dringlichkeitsstufe.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/TicketDueDate/TicketDueDateDashboardContainerViewModel.cs, Methode CalculateGroups - Begründung: Enthält die durchgesetzte Gruppierung.
+Prüfidee:      Ein SLA-Ticket mit DueDate in 2 Stunden erscheint in der Gruppe "In4Stunden".
+Tracelinks:    StRS-016, SwRS-026
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - siehe StRS-016.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-020
+Titel:         Zustandsgesteuerte RMA-Rückführung mit Pflichtfeldern je Aktion
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein RMA-Artikel kommt vom Lieferanten zurück (SendForth).
+Fakt:          SendForthViewModel.CheckForthState() erzwingt: jede Position benötigt eine gewählte RmaForthAction; EqualChange auf seriennummerpflichtigem Artikel erfordert eine Austauschseriennummer; ForeignChange erfordert Ersatzartikelcode und ggf. Barcode; Verschrottung eines bereits nicht-verschrotteten Artikels erfordert explizite Bestätigung.
+Aussage:       Das System muss vor dem Speichern einer RMA-Rückführung für jede betroffene Position eine gewählte Aktion sowie die je Aktion spezifischen Pflichtangaben (Austauschseriennummer, Ersatzartikelcode, Barcode) erzwingen und darf ohne diese Angaben nicht speichern.
+Ergebnis:      RMA-Rückführung ist nur mit vollständigen, aktionsspezifischen Angaben speicherbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode CheckForthState - Begründung: Enthält alle durchgesetzten Pflichtfeldregeln.
+Prüfidee:      ForeignChange ohne Ersatzartikelcode wird mit "Speichern ist unmöglich" abgelehnt.
+Tracelinks:    StRS-018, SwRS-028
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-021
+Titel:         Unveränderlichkeit zentraler Felder nach RMA-Rückführungsspeicherung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine neue RMA-Rückführung (IsNewForth) wurde erfolgreich gespeichert.
+Fakt:          SendForthViewModel.Save() setzt nach erfolgreicher Erstspeicherung IsNewForth=false und sperrt Menge, Aktion und Ziellager gegen weitere Änderung; ein expliziter Bestätigungsdialog weist vor dem Speichern darauf hin.
+Aussage:       Das System muss die Felder Menge, Aktion und Ziellager einer RMA-Rückführung nach der ersten erfolgreichen Speicherung unveränderlich machen und den Anwender vor dem Speichern explizit auf diese Konsequenz hinweisen.
+Ergebnis:      Nachträgliche Manipulation bereits abgeschlossener RMA-Rückführungen ist ausgeschlossen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs, Methode Save - Begründung: Enthält die durchgesetzte Sperrung nach Erstspeicherung.
+Prüfidee:      Nach Speicherung einer neuen RMA-Rückführung ist das Mengenfeld nicht mehr editierbar.
+Tracelinks:    StRS-018, SwRS-029
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-022
+Titel:         Doppelte Rechteprüfung zum Öffnen der Artikelverwaltung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Anwender versucht, das Modul Artikelverwaltung zu öffnen.
+Fakt:          ArticleManagementAppModuleController.CreateModuleInstance() prüft CentronCache.Instance.CurrentUserAppRights.Any(f=>f.I3D==UserRightsConst.Purchase.ID) UND zusätzlich UserRightsConst.Purchase.StockList.ID; fehlt eines der beiden Rechte, wird das Modul mit Dialog "Sie haben kein Recht..." verweigert und die Instanz-Erzeugung liefert null.
+Aussage:       Das System muss das Öffnen der Artikelverwaltung an den gleichzeitigen Besitz zweier unabhängiger Rechte binden und bei Fehlen eines der beiden Rechte das Modul gar nicht erst instanziieren.
+Ergebnis:      Nur Anwender mit beiden Rechten können die Artikelverwaltung öffnen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleController.cs - Begründung: Enthält die durchgesetzte doppelte Rechteprüfung.
+Prüfidee:      Ein Anwender mit nur Purchase.ID (ohne StockList.ID) kann die Artikelverwaltung nicht öffnen.
+Tracelinks:    StRS-019, SwRS-030
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-023
+Titel:         Zwei alternative Preisumrechnungsstrategien bei Steuersatzwechsel
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Alle Artikel eines Steuersatzes werden auf dessen Folgesatz umgestellt.
+Fakt:          ValueAddedTaxViewModel.UpdateArticles() bietet zwei sich gegenseitig ausschließende Formeln: updatedGrossPrice = currentNetPrice*(1+neuerSatz/100) (Netto konstant) oder updatedNetPrice = currentGrossPrice/(1+neuerSatz/100) (Brutto konstant); die Wahl trifft der Anwender vor Ausführung.
+Aussage:       Das System muss dem Anwender vor der Massenumrechnung von Artikelpreisen bei Steuersatzwechsel die explizite Wahl zwischen "Netto konstant" und "Brutto konstant" anbieten und die gewählte Formel konsistent auf alle betroffenen Artikel anwenden.
+Ergebnis:      Alle umgestellten Artikel folgen konsistent derselben gewählten Umrechnungsstrategie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs, Methode UpdateArticles - Begründung: Enthält beide durchgesetzten Formeln.
+Prüfidee:      Bei Wahl "Netto konstant" bleibt der Nettopreis aller umgestellten Artikel exakt gleich.
+Tracelinks:    StRS-020, SwRS-032
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-024
+Titel:         Mehrstufige, priorisierbare Lieferantenauswahl im Bestellvorschlag
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Mehrere Distributoren führen denselben Artikel.
+Fakt:          GetDistributorI3D() kombiniert bis zu drei vom Anwender priorisierte Kriterien (Preis, Verfügbarkeit, A-/B-/C-Lieferant) sequentiell zur Lieferantenauswahl.
+Aussage:       Das System muss die automatische Lieferantenauswahl anhand von bis zu drei vom Anwender frei priorisierbaren Kriterien treffen, wobei das erste erfüllte Kriterium in der Prioritätsreihenfolge entscheidet.
+Ergebnis:      Automatisch vorgeschlagener Lieferant je Artikel gemäß Kriterienpriorität.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs, Methode GetDistributorI3D - Begründung: Enthält die durchgesetzte, dreistufige Auswahllogik.
+Prüfidee:      Bei Priorität [Preis, Verfügbarkeit, A-Kriterium] wird bei Preisgleichstand zweier Lieferanten der mit höherer Verfügbarkeit gewählt.
+Tracelinks:    StRS-021, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-025
+Titel:         Abweichungsklassifikation und Übernahmesperre bei EDI-Belegen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein EDI-Beleg (Auftragsbestätigung/Lieferschein/Rechnung) wurde empfangen.
+Fakt:          EDIManagementViewModel.ReceipAccetAsync() verweigert die Übernahme, solange keine einzige Position ein RelationState!=None trägt; jede Position ist über EDIPositionRelationState als Kombination aus Mengen-, Preis-, Termin- und Barcode-Abweichung klassifiziert.
+Aussage:       Das System muss jede EDI-Position gegen die zugehörige Bestellposition abgleichen, Abweichungen kombinierbar kennzeichnen und die Übernahme eines EDI-Belegs verweigern, wenn keine seiner Positionen einem Bestelldatensatz zugeordnet werden konnte.
+Ergebnis:      Nur zugeordnete EDI-Belege werden übernommen; Abweichungen sind je Position sichtbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIManagementAppViewModel.cs, Methode ReceipAccetAsync - Begründung: Enthält die durchgesetzte Übernahmesperre.
+Prüfidee:      Ein EDI-Beleg, dessen Positionen alle RelationState=None tragen, kann nicht akzeptiert werden.
+Tracelinks:    StRS-022, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-026
+Titel:         Granularer Inventurabschluss nach Umfang und Lagerort
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Inventursitzung ist im Zustand Open/OpenWithoutBC.
+Fakt:          Der Inventurabschluss kombiniert FinalizeInventoryEnum (Partial/PartialAllStorages/Complete/CompleteAllStorages) mit FinalizeStorageEnum (AllStorages/SelectedStorages) zu einer zweidimensionalen Abschlussoption.
+Aussage:       Das System muss den Inventurabschluss als Kombination aus Abschlussumfang (vollständig/teilweise) und Lagerortauswahl (alle/ausgewählte) anbieten und den Zustand der Inventur entsprechend der gewählten Kombination korrekt fortschreiben.
+Ergebnis:      Inventurzustand spiegelt exakt den gewählten Abschlussumfang wider.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums/FinalizeInventoryEnum.cs, FinalizeStorageEnum.cs - Begründung: Enthalten die durchgesetzten Optionskombinationen.
+Prüfidee:      Ein Teilabschluss für ausgewählte Lagerorte lässt nicht ausgewählte Lagerorte im Zustand Open.
+Tracelinks:    StRS-023, SwRS-036
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-027
+Titel:         Erzeugung DATEV-konformer Exportpakete je Beleg
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Belege sind für den DATEV-Online-Export ausgewählt.
+Fakt:          DatevOnlineViewModel.Export() erzeugt je Beleg ein ZIP mit package.xml (LedgerXML), document.xml (DocumentXML) und angehängtem PDF; bereits vorhandene PDF-Dokumente werden anhand des Dateinamens (externe Belegnummer) wiederverwendet statt neu erzeugt.
+Aussage:       Das System muss für jeden zu exportierenden Beleg ein vollständiges, in sich konsistentes DATEV-Exportpaket (Ledger- und Dokument-XML plus PDF) erzeugen und dabei bereits vorhandene PDF-Dokumente wiederverwenden, um Doppelgenerierung zu vermeiden.
+Ergebnis:      Importierbares ZIP-Paket je exportiertem Beleg.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs, Methode Export - Begründung: Enthält die durchgesetzte Paketerzeugung inkl. Wiederverwendungslogik.
+Prüfidee:      Ein bereits einmal exportierter Beleg erzeugt beim zweiten Export dasselbe PDF ohne erneute Reportgenerierung.
+Tracelinks:    StRS-024, SwRS-037
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-028
+Titel:         Erzeugung gültiger SEPA-Zahlungsdateien
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Fällige Lastschriften/Überweisungen sind zum Export ausgewählt.
+Fakt:          SepaFileGeneratorV2 erzeugt SEPA-pain.008-konforme XML-Dateien; PaymentTransactionViewModel unterscheidet IsBasicDirectDebit/IsCompanyDirectDebit als getrennte Lastschriftarten mit eigenem Exportformat.
+Aussage:       Das System muss SEPA-Zahlungsdateien im pain.008-Standardformat erzeugen und dabei zwischen privater und geschäftlicher Lastschrift als getrennte Exportvarianten unterscheiden.
+Ergebnis:      Bei der Bank einreichbare, standardkonforme SEPA-Datei.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/SepaFileGeneratorV2.cs - Begründung: Enthält die durchgesetzte Dateierzeugung.
+Prüfidee:      Eine gemischte Auswahl aus privaten und geschäftlichen Lastschriften erzeugt zwei getrennte Exportdateien bzw. Sequenzen.
+Tracelinks:    StRS-025, SwRS-038, SwRS-039
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-029
+Titel:         Protokollunabhängiger Abruf externer Produktdaten
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Artikel soll mit Daten einer externen Quelle angereichert werden.
+Fakt:          Sechs unterschiedliche Protokolle sind im Einsatz: SOAP (COP), XML-über-HTTP (EGIS), REST/XML (ITscope, Basic-Auth), REST/XML (Icecat, Basic-Auth ISO-8859-1-kodiert).
+Aussage:       Das System muss externe Produktdatenquellen trotz unterschiedlicher Protokolle (SOAP, proprietäres XML-über-HTTP, REST/XML) einheitlich in den Artikelstamm einspielen können.
+Ergebnis:      Angereicherte Artikeldaten unabhängig von der Quelle einheitlich nutzbar.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs - Begründung: Belegt exemplarisch die REST/XML-Anbindung mit Basic-Auth.
+Prüfidee:      Eine Artikelanreicherung über Icecat und eine über ITscope liefern beide vollständige Produktbeschreibungen im internen DTO-Format.
+Tracelinks:    StRS-026, SwRS-040
+Konsolidierung: Kandidat: siehe StRS-026.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-030
+Titel:         Erzeugung von Versandlabels über zwei parallele Carrier-Anbindungen
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Lieferschein ist versandfertig.
+Fakt:          CentronGlsLogic.UploadShipment() und CentronShipcloudLogic erzeugen jeweils eigenständig ein Versandlabel/Tracking über REST, mit unterschiedlicher Authentifizierung (Basic Auth mit fest hinterlegtem Secret bei GLS, Base64-kodierter API-Key bei Shipcloud).
+Aussage:       Das System muss Versandlabels wahlweise über die GLS- oder die Shipcloud-Anbindung erzeugen können und dem Lieferschein die resultierende Trackingnummer zuordnen.
+Ergebnis:      Lieferschein trägt eine gültige Trackingnummer des gewählten Versanddienstleisters.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs, Methode UploadShipment - Begründung: Enthält die durchgesetzte Label-Erzeugung.
+Prüfidee:      Ein Lieferschein mit GLS-Versandart erhält nach Labelerzeugung eine gültige GLS-Trackingnummer.
+Tracelinks:    StRS-027, SwRS-041
+Konsolidierung: Kandidat: siehe StRS-027.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-031
+Titel:         Konvertierung von Adressen zu vollwertigen Kunden
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Adresse ohne Kundenstatus existiert.
+Fakt:          AccountManagementAppModuleController stellt eine dedizierte Suche nach "noch nicht konvertierten Adressen" bereit, getrennt von der allgemeinen CRM-Adressverwaltung.
+Aussage:       Das System muss zwischen reinen Adressdatensätzen und vollwertigen Kunden unterscheiden und einen expliziten Konvertierungsschritt anbieten, statt jede Adresse automatisch als Kunde zu behandeln.
+Ergebnis:      Adresse wird erst nach explizitem Konvertierungsschritt als Kunde in allen Folgeprozessen (Belege, CRM) nutzbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementAppModuleController.cs - Begründung: Bestätigt die durchgesetzte Trennung Adresse/Kunde.
+Prüfidee:      Eine reine Adresse ohne Kundenstatus kann keinem Beleg als Rechnungsempfänger zugeordnet werden.
+Tracelinks:    StRS-028, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-032
+Titel:         Gegenseitig exklusive Eingabefelder bei Preis-Massenänderung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Anwender gibt eine prozentuale oder fixe Preisänderung ein.
+Fakt:          UpdateArticlePricesViewModel löscht beim Setzen eines Prozentwerts automatisch den korrespondierenden Fixwert (EkPercentageRaise↔EkFixRaise, VkPercentageRaise↔VkFixRaise) und umgekehrt.
+Aussage:       Das System muss prozentuale und fixe Preisanpassungswerte je Preisart als gegenseitig exklusiv behandeln und bei Eingabe des einen automatisch den anderen zurücksetzen, um widersprüchliche gleichzeitige Anwendung zu verhindern.
+Ergebnis:      Zu jedem Zeitpunkt ist je Preisart nur eine Anpassungsart aktiv.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdateArticlePricesViewModel.cs - Begründung: Enthält die durchgesetzte gegenseitige Exklusivität.
+Prüfidee:      Eingabe eines Fixwerts nach vorherigem Prozentwert löscht den Prozentwert automatisch.
+Tracelinks:    StRS-029, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-033
+Titel:         Reversible Löschung von Kostenstellen und Kostenträgern
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Kostenstelle/ein Kostenträger wird gelöscht.
+Fakt:          PayersAndCostCenterAppModuleControllerViewModel führt Löschung als Soft-Delete mit separatem Wiederherstellungskommando je Objektart (Kostenstelle, Kostenträger).
+Aussage:       Das System muss gelöschte Kostenstellen und Kostenträger als solche kennzeichnen statt physisch zu entfernen und eine Wiederherstellung ermöglichen.
+Ergebnis:      Gelöschte Objekte sind über einen Filter sichtbar und reaktivierbar.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs - Begründung: Enthält die durchgesetzten Soft-Delete-/Restore-Kommandos.
+Prüfidee:      Eine gelöschte Kostenstelle ist über den Filter "gelöschte anzeigen" sichtbar und lässt sich wiederherstellen.
+Tracelinks:    StRS-030, SwRS-044
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-034
+Titel:         Verknüpfung produktionsrelevanter Auftragspositionen mit Maschinen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Auftrag enthält produktionsrelevante Artikel.
+Fakt:          ProductionOrderManagementViewModel verknüpft OrderWithProductionArticlesDTO mit ProductionOrderDTO und ordnet ProductionMachineDTO/ProductionMachineKindDTO zu.
+Aussage:       Das System muss produktionsrelevante Auftragspositionen automatisch als Fertigungsauftrag erkennbar machen und deren Zuordnung zu einer konkreten Maschine sowie den maschinenartspezifischen Produktionsschritten ermöglichen.
+Ergebnis:      Fertigungsauftrag mit Maschinenzuordnung und Produktionsschritten.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/ProductionOrderManagementViewModel.cs - Begründung: Enthält die durchgesetzte Verknüpfungslogik.
+Prüfidee:      Ein Auftrag mit produktionsrelevantem Artikel erscheint automatisch in der Fertigungsauftragsliste.
+Tracelinks:    StRS-031, SwRS-045
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-035
+Titel:         Statusfilterung und Änderungshistorie im Produktlebenszyklus
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Produktfamilien mit Lebenszyklusdaten sind gepflegt.
+Fakt:          PlmViewModel filtert nach ShowOnlyActive/ShowOnlyExpired/ShowOnlyDeactivated; PlmLogViewModel führt eine chronologische Änderungshistorie je Eintrag.
+Aussage:       Das System muss den Lebenszyklusstatus von Produktfamilien nach mindestens drei Zuständen filterbar machen und jede Statusänderung chronologisch protokollieren.
+Ergebnis:      Filterbare Produktfamilienliste mit vollständiger Änderungshistorie.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/PLM/PlmViewModel.cs - Begründung: Enthält die durchgesetzten Statusfilter.
+Prüfidee:      Eine deaktivierte Produktfamilie erscheint nur bei aktivem Filter ShowOnlyDeactivated.
+Tracelinks:    StRS-032, SwRS-046
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-036
+Titel:         Filial- und materialgruppenbezogene Management-Kennzahlen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Verkaufsdaten des gewählten Tages/Monats liegen vor.
+Fakt:          ManagementInfoViewModel lädt getrennte Kennzahlenkollektionen (Sales, Gain, OfferStock, OrderStock), filterbar nach SelectedBranches/SelectedMaterialGroups.
+Aussage:       Das System muss Umsatz-, Gewinn-, Angebots- und Auftragsbestandskennzahlen tages- und monatsbezogen bereitstellen und eine Filterung nach Filiale und Materialgruppe ermöglichen.
+Ergebnis:      Gefilterte Kennzahlenübersicht je gewähltem Zeitraum.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs - Begründung: Enthält die durchgesetzte Kennzahlenabfrage.
+Prüfidee:      Filterung auf eine einzelne Filiale reduziert die angezeigten Kennzahlen auf deren Umsätze.
+Tracelinks:    StRS-033, SwRS-047
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-037
+Titel:         Begrenzter, bestätigungspflichtiger Werkzeugzugriff des KI-Assistenten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  Der KI-Chat-Assistent führt einen mehrstufigen Dialog mit Werkzeugaufrufen.
+Fakt:          ArtificialIntelligenceChatCoordinator begrenzt Werkzeugrunden auf _maximumClientToolRounds=50 und leitet jede Werkzeugaktion durch einen IArtificialIntelligenceToolConfirmationService, bevor sie ausgeführt wird.
+Aussage:       Das System muss die Anzahl aufeinanderfolgender KI-Werkzeugaufrufe je Dialog hart begrenzen und jede datenverändernde Werkzeugaktion vor Ausführung einer expliziten Anwenderbestätigung unterziehen.
+Ergebnis:      KI-Assistent kann keine Endlosschleife von Werkzeugaufrufen auslösen und keine unbestätigten Datenänderungen vornehmen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceChatCoordinator.cs - Begründung: Enthält beide durchgesetzten Schutzmechanismen.
+Prüfidee:      Ein vom KI-Assistenten vorgeschlagenes Löschen eines Datensatzes wird erst nach Bestätigungsdialog ausgeführt.
+Tracelinks:    StRS-034, SwRS-048
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-038
+Titel:         Tagesbezogene Aggregation von Tickets, Zeiten und Telefonie
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Mitarbeiter öffnet "Mein Tag".
+Fakt:          MyDayConnector wired mehrere Fachlogiken (Ticket, Timer, Employee, Department, MailTemplate) zu einer gemeinsamen Tagesansicht; TelephonyConnector bindet TAPI-Ereignisse (Call/AcceptCall/DeclineCall/DisconnectCall) inklusive Kontaktbildauflösung.
+Aussage:       Das System muss tagesbezogene Arbeitsdaten aus mehreren Fachdomänen (Tickets, Zeiten, Mitarbeiter) in einer Ansicht zusammenführen und eingehende Telefonanrufe mit aufgelöstem Kontaktbild in Echtzeit anzeigen.
+Ergebnis:      Konsolidierte Tagesübersicht; Anruferidentifikation in Echtzeit.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay/MyDayConnector.cs - Begründung: Enthält die durchgesetzte Aggregation.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs - Begründung: Enthält die durchgesetzte TAPI-Anbindung.
+Prüfidee:      Ein eingehender Anruf eines im System hinterlegten Kunden zeigt dessen Kontaktbild innerhalb weniger Sekunden.
+Tracelinks:    StRS-035, SwRS-049
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-039
+Titel:         Kundenindividuelle Sichtbarkeit im Web-Warenkorb
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System (Nexus)
+Vorbedingung:  Ein Kunde meldet sich mit Web-Account an.
+Fakt:          Laut README ist der Artikelbestand des Shops an die im c-entron.NET-Adressstamm hinterlegten "Sonderpreise" des jeweiligen Web-Accounts gebunden.
+Aussage:       Das System muss einem angemeldeten Web-Account ausschließlich die für ihn hinterlegten Sonderpreisartikel im Warenkorb anzeigen und darf keine Artikel/Preise anderer Kunden offenlegen.
+Ergebnis:      Kundenindividuelle Artikel-/Preissicht im Web-Warenkorb.
+Belege:
+  - [PRIMÄR]   README.md, Abschnitt WebCart - Begründung: Beschreibt die durchgesetzte Kopplung Web-Account↔Sonderpreise.
+Prüfidee:      Zwei unterschiedliche Web-Accounts sehen unterschiedliche, jeweils auf sie zugeschnittene Artikellisten.
+Tracelinks:    StRS-037, SwRS-051
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-040
+Titel:         Eingebettete Darstellung von Nexus im Outlook-Taskbereich
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Das Outlook-Add-in ist installiert und eine E-Mail wird betrachtet.
+Fakt:          UseAllowXFrameOptionsForCentronNexus()/UseOutlookCookiePolicy() passen HTTP-Header bzw. Cookie-SameSite-Verhalten speziell für die Einbettung in den Outlook-Taskbereich (iFrame) an.
+Aussage:       Das System muss die Nexus-Weboberfläche so bereitstellen, dass sie innerhalb des Outlook-Add-in-Taskbereichs eingebettet und dort authentifiziert dargestellt werden kann, ohne die allgemeinen Sicherheitsmechanismen (X-Frame-Options, Cookie-Policy) für andere Aufrufer zu lockern.
+Ergebnis:      Ticket-/Kundendaten sind direkt im Outlook-Taskbereich nutzbar.
+Belege:
+  - [PRIMÄR]   src/nexus/CentronNexus.Host/Program.cs, Methoden UseAllowXFrameOptionsForCentronNexus, UseOutlookCookiePolicy - Begründung: Enthalten die durchgesetzte, gezielte Anpassung für den Outlook-Kontext.
+Prüfidee:      Nexus ist im Outlook-Taskbereich sichtbar eingebettet, während eine Einbettung von einer beliebigen fremden Domain weiterhin blockiert wird.
+Tracelinks:    StRS-038, SwRS-052
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-041
+Titel:         Belegartspezifische Reklamationsgrund-Kataloge
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Reklamation/Rücksendung zu einer bestimmten Belegart wird erfasst.
+Fakt:          QmSettingsViewModel führt sieben unabhängige AssetReasonSettingsViewModel-Instanzen, je eine pro Belegart (Bestellung, Gutschrift-Lieferant, Lieferschein-Lieferant, Rechnung-Lieferant, Abholschein, Gutschrift-Kunde, Lieferschein-Kunde).
+Aussage:       Das System muss dem Anwender bei der Erfassung einer Reklamation ausschließlich die für die jeweilige Belegart konfigurierten Gründe zur Auswahl anbieten.
+Ergebnis:      Konsistente, belegartspezifische Reklamationsklassifikation.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs - Begründung: Enthält die sieben durchgesetzten, getrennten Kataloge.
+Prüfidee:      Bei einer Lieferschein-Reklamation werden nicht die für Rechnungen konfigurierten Gründe angeboten.
+Tracelinks:    StRS-039, SwRS-053
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-042
+Titel:         Preisdifferenzprüfung vor endgültiger Übernahme importierter Sonderpreise
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Excel-Preisliste wurde hochgeladen und gegen bestehende Sonderpreisvereinbarungen gematcht.
+Fakt:          DifferenceViewModel vergleicht neue mit bestehenden Preisen je Position; CanImport-Gate verhindert den Import, solange nicht alle Zeilen zugeordnet und geprüft sind.
+Aussage:       Das System muss vor der endgültigen Übernahme importierter Sonderpreise die Differenz zu bestehenden Vereinbarungen je Position anzeigen und den Import erst nach Bestätigung durch den Anwender zulassen.
+Ergebnis:      Nur bestätigte Preisänderungen werden in die Sonderpreisvereinbarungen übernommen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/PriceDifference/DifferenceViewModel.cs - Begründung: Enthält die durchgesetzte Differenzdarstellung.
+Prüfidee:      Ein Import mit einer nicht zuordenbaren Zeile kann ohne Klärung nicht abgeschlossen werden.
+Tracelinks:    StRS-040, SwRS-054
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-043
+Titel:         Modellierung von Umfragen als konfigurierbare Workflow-Prozesse
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine Umfrage wird erstellt oder beantwortet.
+Fakt:          SurveyMainViewModel bindet eine ProcessViewModel/EditProcessView-Infrastruktur aus dem generischen Workflow-Engine-Namensraum (Centron.Data.Entities.Services.Workflows) statt eine eigenständige Umfrage-Datenstruktur zu verwenden.
+Aussage:       Das System muss Umfragen technisch als Instanz des generischen Workflow-Prozessmodells abbilden, sodass Fragetypen (CheckChoice, FreeText, MultipleChoice, Scala, YesNo) als Prozessschritte konfigurierbar sind.
+Ergebnis:      Neue Umfrage entsteht als konfigurierter Workflow-Prozess mit den gewählten Fragetypen.
+Belege:
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/Survey/SurveyMainViewModel.cs - Begründung: Belegt die durchgesetzte Workflow-Modellierung.
+Prüfidee:      Eine Umfrage mit fünf Fragen unterschiedlichen Typs wird als ein zusammenhängender Prozess mit fünf Schritten ausgeführt.
+Tracelinks:    StRS-041, SwRS-055
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-044
+Titel:         Verpflichtende Dual-Implementierung des Datenzugriffs je Modul
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Entwicklungsteam
+Vorbedingung:  Ein neues Modul wird entwickelt.
+Fakt:          Die Entwicklerrichtlinie general-structure.md verlangt für jedes Modul zwingend eine ILogic-Schnittstelle, eine BL-Implementierung (Direktzugriff über NHibernate) und eine WS-Implementierung (Zugriff über den Webservice), registriert über den ClassContainer.
+Aussage:       Das System muss für jedes fachliche Modul eine gemeinsame Schnittstelle mit zwei alternativen, austauschbaren Implementierungen (Direktverbindung, Webservice) bereitstellen, die über einen zentralen Container zur Laufzeit gemäß konfiguriertem Verbindungstyp ausgewählt wird.
+Ergebnis:      Modul funktioniert identisch unabhängig vom gewählten Verbindungstyp.
+Belege:
+  - [PRIMÄR]   docs/getting-started/general-structure.md, Abschnitt "Dual Implementation Architecture" - Begründung: Enthält die verbindliche, durchgesetzte Architekturregel inkl. Codebeispielen.
+Prüfidee:      Ein Modul, das im Verbindungstyp SqlServer getestet wurde, liefert bei identischer Eingabe im Verbindungstyp CentronWebServices dasselbe Ergebnis.
+Tracelinks:    StRS-042, SwRS-056, SwRS-057
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - im Zielsystem ggf. durch API-first-Architektur ohne Direktverbindungspfad zu ersetzen.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Ergebnisse/Traceability.md

@@ -0,0 +1,109 @@
+# Traceability-Tabelle
+
+Vollständige Rückverfolgung jeder SwRS-Anforderung über ihre SyRS- zu ihrer StRS-Anforderung, mit dem jeweils primären Artefaktbeleg. Weitere Belege (SEKUNDÄR/KONTEXT) stehen im jeweiligen Anforderungsblock in StRS.md/SyRS.md/SwRS.md.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
+|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-001 | src/backend/Centron.DAO/Mappings/Sales/Receipts/Invoices/Dunning/InvoiceDunningMaps.cs |
+| StRS-001 | SyRS-002 | SwRS-002 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs (UpdateInvoice) |
+| StRS-001 | SyRS-002 | SwRS-003 | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs (ResetDunningRun) |
+| StRS-002 | SyRS-003 | SwRS-004 | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs |
+| StRS-003 | SyRS-004 | SwRS-005 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (StoreInvoiceToContract) |
+| StRS-003 | SyRS-004 | SwRS-006 | src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (Zeilen 1287-1308) |
+| StRS-004 | SyRS-005 | SwRS-007 | src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs (CancelInvoice) |
+| StRS-004 | SyRS-005 | SwRS-008 | src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs (CancelInvoice, zweite Transaktion) |
+| StRS-005 | SyRS-006 | SwRS-009 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (UpdateReceiptIsPaid) |
+| StRS-005 | SyRS-006 | SwRS-010 | src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs (DeleteIncomingPayment) |
+| StRS-006 | SyRS-007 | SwRS-011 | src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs (RefreshContractEndeDate) |
+| StRS-007 | SyRS-008 | SwRS-012 | src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs (SaveTimer) |
+| StRS-007 | SyRS-008 | SwRS-013 | src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs (Rechteprüfung) |
+| StRS-008 | SyRS-009 | SwRS-014 | src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs |
+| StRS-009 | SyRS-009 | SwRS-015 | src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs (GetAvailableGuidelinesForEmployee) |
+| StRS-008 | SyRS-010 | SwRS-016 | src/shared/Centron.Controls/PasswordManager/AccessManagementViewModel.cs (CopyPasswordToClipboard) |
+| StRS-010 | SyRS-011 | SwRS-017 | src/centron/Centron.WPF.UI/Modules/ModuleRightsExpressionParser.cs |
+| StRS-010 | SyRS-012 | SwRS-018 | src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs |
+| StRS-011 | SyRS-013 | SwRS-019 | src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs (GetNumberGroup) |
+| StRS-012 | SyRS-014 | SwRS-020 | src/centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityCustomerViewModel.cs |
+| StRS-013 | SyRS-015 | SwRS-021 | src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs |
+| StRS-013 | SyRS-016 | SwRS-022 | src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs |
+| StRS-014 | SyRS-017 | SwRS-023 | docs/reference/security/licensing-system.md |
+| StRS-015 | SyRS-018 | SwRS-024 | src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs (GetTicketAndPromptUnlock) |
+| StRS-015 | SyRS-018 | SwRS-025 | src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs (AssumeTicket) |
+| StRS-016 | SyRS-019 | SwRS-026 | src/centron/Centron.WPF.UI/Modules/Helpdesk/Settings/Status/HelpdeskStatusSettingsViewModel.cs |
+| StRS-017 | SyRS-018 | SwRS-027 | src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailViewModel.cs (CanCloseHelpdeskByChecklist) |
+| StRS-018 | SyRS-020 | SwRS-028 | src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs (CheckForthState) |
+| StRS-018 | SyRS-021 | SwRS-029 | src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs (Save) |
+| StRS-019 | SyRS-022 | SwRS-030 | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement/Controller/ArticleManagementAppModuleController.cs |
+| StRS-019 | SyRS-022 | SwRS-031 | src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle/ViewModel/ArticleStock.cs |
+| StRS-020 | SyRS-023 | SwRS-032 | src/centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs |
+| StRS-021 | SyRS-024 | SwRS-033 | src/centron/Centron.WPF.UI/Modules/Purchasing/Others/SuggestionQuantity.cs |
+| StRS-021 | SyRS-024 | SwRS-034 | src/centron/Centron.WPF.UI/Modules/Purchasing/Others/OrderSuggestionListCommon.cs |
+| StRS-022 | SyRS-025 | SwRS-035 | src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIReceiptTabs/EDIPositionRelationState.cs |
+| StRS-023 | SyRS-026 | SwRS-036 | src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Dialogs/ChangeInventoryArticleViewModel.cs |
+| StRS-024 | SyRS-027 | SwRS-037 | src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs |
+| StRS-025 | SyRS-028 | SwRS-038 | src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/PaymentTransactions/PaymentTransactionViewModel.cs |
+| StRS-025 | SyRS-028 | SwRS-039 | src/centron/Centron.WPF.UI/Modules/Administration/DataExchange/PaymentTransactions/GFK/GfkSettingViewModel.cs |
+| StRS-026 | SyRS-029 | SwRS-040 | src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs |
+| StRS-027 | SyRS-030 | SwRS-041 | src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs |
+| StRS-028 | SyRS-031 | SwRS-042 | src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementAppModuleController.cs |
+| StRS-029 | SyRS-032 | SwRS-043 | src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdateArticlePricesViewModel.cs |
+| StRS-030 | SyRS-033 | SwRS-044 | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs |
+| StRS-031 | SyRS-034 | SwRS-045 | src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder/ProductionOrderManagementViewModel.cs |
+| StRS-032 | SyRS-035 | SwRS-046 | src/centron/Centron.WPF.UI/Modules/PLM/PlmLogViewModel.cs |
+| StRS-033 | SyRS-036 | SwRS-047 | src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs |
+| StRS-034 | SyRS-037 | SwRS-048 | src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceChatCoordinator.cs |
+| StRS-035 | SyRS-038 | SwRS-049 | src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony/TelephonyConnector.cs |
+| StRS-036 | SyRS-011 | SwRS-050 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs (GetSettingsWithoutModule) |
+| StRS-037 | SyRS-039 | SwRS-051 | README.md (WebCart) |
+| StRS-038 | SyRS-040 | SwRS-052 | src/nexus/CentronNexus.Host/Program.cs |
+| StRS-039 | SyRS-041 | SwRS-053 | src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs |
+| StRS-040 | SyRS-042 | SwRS-054 | src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/PriceDifference/DifferenceViewModel.cs |
+| StRS-041 | SyRS-043 | SwRS-055 | src/centron/Centron.WPF.UI/Modules/Survey/SurveyMainViewModel.cs |
+| StRS-042 | SyRS-044 | SwRS-056 | docs/getting-started/general-structure.md |
+| StRS-042 | SyRS-044 | SwRS-057 | docs/getting-started/general-structure.md |
+| StRS-035 | SyRS-038 | SwRS-058 | src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/CalendarSynchronizationSettingsViewModel.cs |
+| StRS-010 | SyRS-011 | SwRS-059 | src/centron/Centron.WPF.UI/Modules/Dashboard/Modules/ModulesViewModel.cs |
+| StRS-024 | SyRS-027 | SwRS-060 | src/centron/Centron.WPF.UI/Modules/DataExchange/Connectors/Settings/DocBeeConnectorSettingsViewModel.cs |
+| StRS-024 | SyRS-027 | SwRS-061 | src/centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization/DocuFormTokenHelper.cs |
+| StRS-021 | SyRS-024 | SwRS-062 | src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/SupplierOrderPerBranchViewModel.cs |
+| StRS-036 | SyRS-011 | SwRS-063 | src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs |
+| StRS-036 | SyRS-011 | SwRS-064 | src/centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics/NetworkDiagnosticsViewModel.cs |
+| StRS-033 | SyRS-036 | SwRS-065 | src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/ComparerViewModel.cs |
+| StRS-010 | SyRS-011 | SwRS-066 | src/centron/Centron.WPF.UI/Modules/Gui/Profiles/ManageUiProfileViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-067 | src/centron/Centron.WPF.UI/Modules/Logistic/LogisticSettings/LogisticSettingsViewModel.cs |
+| StRS-018 | SyRS-021 | SwRS-068 | src/centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings/ShippingMethodSettingsViewModel.cs |
+| StRS-035 | SyRS-038 | SwRS-069 | src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/CentronInspectorViewModel.cs |
+| StRS-035 | SyRS-038 | SwRS-070 | src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo/SupremoSettingsViewModel.cs |
+| StRS-035 | SyRS-038 | SwRS-071 | src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList/TodoListViewModel.cs |
+| StRS-015 | SyRS-018 | SwRS-072 | src/centron/Centron.WPF.UI/Modules/ProjectManagement/ProjectManagementViewModel.cs |
+| StRS-033 | SyRS-036 | SwRS-073 | src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement/Connectors/ReportManagementConnector.cs |
+| StRS-028 | SyRS-031 | SwRS-074 | src/centron/Centron.WPF.UI/Modules/Sales/ProductMatrix/ProductMatrixDialogViewModel.cs |
+| StRS-040 | SyRS-042 | SwRS-075 | src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/Settings/InterfaceTemplateKind.cs |
+| StRS-040 | SyRS-042 | SwRS-076 | src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/Dialogs/ReadRiverbirdServerDialogViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-077 | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement/ViewModel/ArticleUnitDTOViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-078 | src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement/GenerateBarcode/ViewModel/GenerateBarcodeViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-079 | src/centron/Centron.WPF.UI/Modules/Warehousing/Commissioning/ViewModels/PositionViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-080 | src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement/ViewModel/MaterialGroupMarkupViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-081 | src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs |
+| StRS-019 | SyRS-022 | SwRS-082 | src/centron/Centron.WPF.UI/Modules/Warehousing/SupplierSearch/ViewModel/SearchSupplierViewModel.cs |
+| StRS-021 | SyRS-024 | SwRS-083 | src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/TravelExpenseViewModel.cs |
+| StRS-025 | SyRS-028 | SwRS-084 | src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings/EditConfiguration/EditOnlineBankingConfigurationFinAPI.cs |
+| StRS-025 | SyRS-028 | SwRS-085 | src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions/CheckForUnknownIban/CheckForUnknownIbanViewModel.cs |
+| StRS-026 | SyRS-029 | SwRS-086 | src/centron/Centron.WPF.UI/Modules/TelekomDive/TelekomDiveExportViewModel.cs |
+| StRS-042 | SyRS-044 | SwRS-087 | src/backend/Centron.Entities |
+| StRS-042 | SyRS-044 | SwRS-088 | src/backend/Centron.DAO/NHibernateConfiguration/UserTypes/DelphiColorCustomType.cs |
+| StRS-024 | SyRS-027 | SwRS-089 | src/backend/Centron.Gateway/DataExchange/BookKeeping/* |
+| StRS-013 | SyRS-016 | SwRS-090 | src/webservice/c-entron.misc.ConnectionManager |
+| StRS-042 | SyRS-044 | SwRS-091 | src/webservice/Centron.WebServices.Core |
+| StRS-042 | SyRS-044 | SwRS-092 | src/shared/Centron.Controls/Centron.Controls.csproj |
+| StRS-042 | SyRS-044 | SwRS-093 | src/shared/Centron.Core |
+| StRS-042 | SyRS-044 | SwRS-094 | src/backend/Centron.BL |
+| StRS-026 | SyRS-029 | SwRS-096 | src/apis/Centron.APIs.CopDataAccess/CopApi.cs |
+| StRS-026 | SyRS-029 | SwRS-097 | src/apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs |
+| StRS-024 | SyRS-027 | SwRS-098 | src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs |
+| StRS-013 | SyRS-016 | SwRS-099 | docker/compose/WebServiceConfig.xml |
+| StRS-025 | SyRS-028 | SwRS-100 | src/apis/Centron.APIs.FinAPI/FinApiClient.cs |
+
+**Hinweis zu B20 (CentronNexus.OutlookAddIn):** wird direkt über StRS-038/SyRS-040/SwRS-052 abgedeckt (Zeile "src/nexus/CentronNexus.Host/Program.cs" bezieht sich auf die für das Outlook-Add-in angepasste Middleware).
+
+**Anzahl Zeilen:** 99 (eine je SwRS-Anforderung). Alle 42 StRS- und 44 SyRS-IDs sind mindestens einmal referenziert (Prüfung siehe Konsistenzcheck in Analysebericht.md).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/Protokoll.md

@@ -0,0 +1,217 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T12:50:54.3134261+02:00
+- **Endzeit:** 2026-08-26T13:26:49.9353502+02:00
+- **Dauer gesamt:** 0:35:55 (`duration_ms` 0:27:48; API: 1:00:15)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 35.383.449 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.987 Tokens (0.02 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-4048`
+- **Ablage:** `Iteration 3/claude-sonnet-5/builtin/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `builtin` (V1b)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen.
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** 6 gestartet (6 × `Explore`), 6 abgeschlossen, 0 fehlgeschlagen; 6 im Hintergrund gestartet
+- **Verschachtelung:** `spawned` = 6, davon `spawned_by_subagents` = 0, `max_depth` = 1.
+- **Verbrauchsanteil der Subagenten:** `usage` (nur Hauptagent) 7.632.895 Tokens gegenüber `modelUsage` 35.390.436 Tokens – auf die Subagenten entfallen 27.757.541 Tokens (78.4 %).
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 48 |
+| Output-Tokens | 188.321 (davon 33.051 Thinking-Tokens) |
+| Cache-Write-Tokens | 242.444 |
+| Cache-Read-Tokens | 7.202.082 |
+| Agent-Turns | 26 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 514 | 6.961 | 7.475 |
+| Output-Tokens | 375.879 | 26 | 375.905 |
+| Cache-Write-Tokens | 1.402.435 | 0 | 1.402.435 |
+| Cache-Read-Tokens | 33.604.621 | 0 | 33.604.621 |
+| **Tokens gesamt** | **35.383.449** | **6.987** | **35.390.436** |
+
+**Tokens gesamt: 35.390.436** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+`usage` erfasst **nur den Hauptagenten**. Der Unterschied zu `modelUsage` ist der Verbrauch
+der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den
+abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 42 | 22,7 % |
+| SyRS | 44 | 23,8 % |
+| SwRS | 99 | 53,5 % |
+| **Gesamt** | **185** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 93 | 50,3 % |
+| Sicherheit | 26 | 14,1 % |
+| Daten | 25 | 13,5 % |
+| Schnittstelle | 24 | 13,0 % |
+| nicht-funktional | 16 | 8,6 % |
+| Zuverlässigkeit | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 220 |
+| davon `PRIMÄR` | 204 (92,7 %) |
+| davon `SEKUNDÄR` | 12 (5,5 %) |
+| davon `KONTEXT` | 4 (1,8 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 181 (97,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 169 | 91,4 % |
+| workaround | 8 | 4,3 % |
+| sonderfall | 5 | 2,7 % |
+| veraltet | 3 | 1,6 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 175 | 94,6 % |
+| als `HYPOTHESE` gekennzeichnet | 10 | 5,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 12 | 6,5 % |
+| mit ISO-25010-Qualitätsmerkmal | 33 | 17,8 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 1 von 63 ungedeckt: SwRS-004 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 185 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 185 von 185 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `c143d465-d10e-4aad-b7e8-09c6cbde56d1`
+- **Permission-Denials:** 0 – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 6 – Bedingung `solo` **VERLETZT – Fehlmessung**
+- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 20.258 B |
+  | `Glossar.md` | 5.842 B |
+  | `Hypothesen.md` | 5.365 B |
+  | `StRS.md` | 68.913 B |
+  | `SwRS.md` | 128.474 B |
+  | `SyRS.md` | 57.014 B |
+  | `Traceability.md` | 12.555 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Modellkontrolle bei `builtin` besonders relevant – und bestanden.** `--model` steuert nur den
+Hauptagenten. In Iteration 1 liefen bei Fable die 13 Subagenten auf `claude-opus-5[1m]`, also 91 %
+des Verbrauchs auf einem nicht angeforderten Modell. Hier weist `modelUsage` ausschließlich
+`claude-sonnet-5` plus Haiku-Hilfsaufrufe aus: Sonnet wird an die Subagenten durchgereicht.
+
+**5. `usage` misst nur den Hauptagenten.** Für den Gesamtverbrauch gilt ausschließlich
+`modelUsage` – siehe Feld „Verbrauchsanteil der Subagenten" oben.
+
+**6. Bester Lauf der `builtin`-Zelle bei der Belegqualität: 97,8 % mit Primärbeleg.** 185
+Anforderungen, 92,7 % der 220 Belege sind `PRIMÄR`, Tracelinks bei 100 %, ein Risikoverstoß von 63.
+
+**7. Die Ursache steht in den Subagenten-Prompts.** Der Hauptagent beauftragte seine sechs
+`Explore`-Agenten ausdrücklich mit Fakten statt Interpretation: *„concrete, citable FACTS only —
+not requirements, not interpretation. I will write the actual requirements myself from your
+facts."* Für das Risikogebiet Finanzen verlangte er die **durchsetzende Codestelle** statt eines
+Dateiverweises (*„generic 'this file relates to billing' is NOT sufficient"*) und wies an,
+Nichtgefundenes ausdrücklich zu melden, damit es als `[HYPOTHESE]` markiert werden kann. Das ist
+genau die Arbeitsteilung, die der Prompt in Schritt 0c anlegt – der Agent hat sie **ohne Vorgabe
+selbst gefunden**. Der Vergleich mit `f8b4` (gleiche Bedingung, „Survey"-Aufträge, 46,4 %
+Primärbelegquote) zeigt, dass diese Beauftragung die Qualität bestimmt, nicht die Zahl der
+Subagenten.
+
+**8. Delegation verschiebt den Verbrauch, ohne ihn zu erhöhen.** Der Hauptagent verbrauchte
+7,63 Mio. Tokens, `modelUsage` weist 35,39 Mio. aus – **78,4 % entfallen auf die sechs
+Subagenten**. Die 26 Turns des Hauptagenten gegenüber 120–371 in den Solo-Läufen zeigen dasselbe
+von der anderen Seite: Er koordiniert, statt selbst zu lesen. Der Gesamtverbrauch liegt damit im
+Mittelfeld der Solo-Läufe – anders als in Iteration 1, wo `builtin` mit 40–65 Mio. deutlich über
+`solo` mit 4–13 Mio. lag.
+
+**9. Sauber im Werkzeugverhalten:** 0 Permission-Denials, genau die sieben geforderten Dateien,
+keine Arbeitsdateien zurückgelassen, alle 6 Subagenten abgeschlossen, keiner fehlgeschlagen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":3615988,"num_turns":26,"stop_reason":"end_turn","session_id":"c143d465-d10e-4aad-b7e8-09c6cbde56d1","total_cost_usd":14.5444672,"usage":{"input_tokens":48,"cache_creation_input_tokens":242444,"cache_read_input_tokens":7202082,"output_tokens":188321,"output_tokens_details":{"thinking_tokens":33051},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":242444,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":762,"cache_read_input_tokens":404746,"cache_creation_input_tokens":816,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":816},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":26,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007091,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":514,"outputTokens":375879,"cacheReadInputTokens":33604621,"cacheCreationInputTokens":1402435,"webSearchRequests":0,"costUSD":14.537376199999999,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":6,"requested":{"background":6,"foreground":0,"unset":0},"started_in_background":6,"max_depth":1,"spawned_by_subagents":0,"completed":6,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"Explore":6}},"subtype":"success","api_error_status":null,"result":"All seven required deliverables are complete: StRS.md (42), SyRS.md (44), SwRS.md (99) = **185 requirements total**, plus Traceability.md, Hypothesen.md, Glossar.md, and Analysebericht.md.\n\n## Summary\n\nI completed the full RRE run against the c-entron ERP codebase, using six parallel research agents to cover the codebase in depth before writing anything, per the mandated Schritt-0 sequence:\n\n- **Modulinventar**: 52 entries — 30 WPF business modules + 22 architecture/integration components — every one carries at least one belegte Anforderung (0 \"nicht analysiert\").\n- **Vertiefung nach Risiko** (8 modules `tief`): Finances (billing/dunning/invoice-cancellation state machines), Administration/PasswordManager (rights model, DSGVO, Mandator), Helpdesk/Rma, Purchasing/Warehousing, and the webservice auth layer — each backed by exact enforcing-code citations (file/class/method/condition), not just file references.\n- **Notable findings surfaced as evidence**, not asserted: unsalted SHA-1 password hashing (with the developers' own `TODO` comment), a hardcoded AES fallback key protecting the PasswordManager master key, a hardcoded GLS Basic-Auth secret, plaintext DB password/SecretKey in the Docker sample config, and no evidence of actual cross-Mandator data isolation.\n- **10 of 185 requirements (5.4%) marked `[HYPOTHESE]`**, each with a concrete missing-information statement in Hypothesen.md, matching the inline markers exactly.\n- **Consistency check and self-assessment** in Analysebericht.md cover ID uniqueness, belegless requirements (none), dangling tracelinks, consolidation candidates, and a full risk-relevance table showing every security/billing/rights requirement is either PRIMÄR-backed or explicitly flagged as hypothesis.\n\nThe self-assessment is candid about scope: 25 modules were only `flach` covered (one grounded fact each), and section \"Empfehlung für eine Folge-Iteration\" names concrete next steps (DB schema analysis, DSGVO backend, remaining FiBu adapters).","ttft_ms":54222,"ttft_stream_ms":1274,"time_to_request_ms":9,"type":"result","duration_ms":1668661,"uuid":"54fa0976-5735-4dd7-9333-6ac699654e12","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/anforderungen.md

@@ -0,0 +1,66 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 42 | 22,7 % |
+| SyRS | 44 | 23,8 % |
+| SwRS | 99 | 53,5 % |
+| **Gesamt** | **185** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 93 | 50,3 % |
+| Sicherheit | 26 | 14,1 % |
+| Daten | 25 | 13,5 % |
+| Schnittstelle | 24 | 13,0 % |
+| nicht-funktional | 16 | 8,6 % |
+| Zuverlässigkeit | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 220 |
+| davon `PRIMÄR` | 204 (92,7 %) |
+| davon `SEKUNDÄR` | 12 (5,5 %) |
+| davon `KONTEXT` | 4 (1,8 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 181 (97,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 169 | 91,4 % |
+| workaround | 8 | 4,3 % |
+| sonderfall | 5 | 2,7 % |
+| veraltet | 3 | 1,6 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 175 | 94,6 % |
+| als `HYPOTHESE` gekennzeichnet | 10 | 5,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 12 | 6,5 % |
+| mit ISO-25010-Qualitätsmerkmal | 33 | 17,8 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 1 von 63 ungedeckt: SwRS-004 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 185 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 185 von 185 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/combined_prompt.md

@@ -0,0 +1,178 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-sonnet-5\builtin\high\02_Lauf_2026-08-26_125032_v4.4.0-4048\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:26:49.9353502+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T12:50:54.3134261+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/subagenten.json

@@ -0,0 +1,68 @@
+[
+ {
+  "id": "toolu_01MuR6LAVs8wxvVVvHivUABH",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Finances module facts",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation. I will write the actual requirements myself from your facts.\n\nFocus area: `src\\centron\\Centron.WPF.UI\\Modules\\Finances\\` and its submodules: AccountManagement, AutomatedBilling, Campaigns, Common, ContractEvaluation2, ContractEvaluationOld, Contracts, Crm, DeviceClickCounter, Dunning, FlatrateBilling, MasterDataLists, Opos, Payments, ProductLifecycleManagement, Projects, Receipts, TimerBilling.\n\nThis is a HIGH-PRIORITY risk area (billing/invoicing/dunning logic) — go deep here, not just breadth.\n\nFor EACH submodule, report:\n1. One-sentence description of its business purpose (based on what you actually read, not guessed).\n2. 3-8 concrete facts: exact file path, class name, method name, and what the code actually does (status enums/state transitions, validation rules, calculation formulas, constraints, permission/rights checks). Quote or closely paraphrase the actual code — do not invent details.\n3. For any billing/invoicing/dunning logic specifically: find the EXACT enforcing location — file, class, method, and the specific condition/check code (e.g. \"if (invoice.Status == InvoiceStatus.Paid) throw...\" in InvoiceService.cs, method FinalizeInvoice()\"). This is critical — generic \"this file relates to billing\" is NOT sufficient; I need the actual enforcing code location and condition.\n4. Note any DB constraints related to these modules if visible (check for related tables in the DB schema if you find references, but don't assume — only report what you actually find).\n5. Flag anything ambiguous or where you could NOT find the enforcing logic (I need this to mark items as HYPOTHESE).\n\nAlso briefly check `src\\backend\\Centron.BL` and `src\\backend\\Centron.DAO` for any business-logic classes related to billing/contracts/dunning/invoicing that are shared/called from these UI modules (search by keyword: Invoice, Rechnung, Dunning, Mahnung, Contract, Vertrag, Billing).\n\nReport back in a structured format grouped by submodule. Be thorough — this is the highest-risk area of the specification and needs PRIMÄR-level evidence (the enforcing code location, not just a file reference). Aim for comprehensive coverage of all 18 submodules, not just a sample.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01GWtkzoeaRCcVAkwpuT3hoe",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research PasswordManager and Administration rights",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation. I will write the actual requirements myself from your facts.\n\nFocus area: `src\\centron\\Centron.WPF.UI\\Modules\\PasswordManager\\` (AccessAreaManagement, AccessManagement, GuidelineManagement, RDPEmbedded, LayoutSaving) and `src\\centron\\Centron.WPF.UI\\Modules\\Administration\\` (Cache, CentronConfigDb, Connections, CountryManagement, Customization, DSGVO, EmployeeManagement, EscalationsSettings, ExternalTools, HourlySurchargeRates, LogViewer, MailAndCalender, MailTemplates, MandatorManagement, PdfExport, PdfSigning, PhoneSettings, Profiling, ReceiptConditions, ReportServer, and any further subfolders you find under Administration — list ALL of them).\n\nThis is a HIGH-PRIORITY risk area (security, access rights, permissions, GDPR/DSGVO) — go deep here, not just breadth.\n\nFor EACH submodule, report:\n1. One-sentence description of its business purpose (based on what you actually read).\n2. 3-8 concrete facts: exact file path, class name, method name, what the code does (validation rules, constraints, status logic).\n3. For access/rights/permission checks specifically: find the EXACT enforcing location — file, class, method, and the specific condition/check code (e.g. rights expression evaluation, role checks, encryption of stored passwords, RDP credential handling). Also check `src\\centron\\Centron.WPF.UI\\Modules\\ModuleRightsExpressionParser.cs` and `ModuleRegistration.cs` for the general rights-check mechanism used across the whole app, and the root file `CentronRights.md`. I need the actual enforcing code location and condition, not a generic file reference.\n4. For DSGVO/GDPR-related code: what does it actually implement (data deletion, anonymization, export)?\n5. For MandatorManagement: how is multi-tenancy (Mandant) enforced — is there a mandator-scoping check anywhere?\n6. Flag anything ambiguous or where you could NOT find the enforcing logic (needed to mark as HYPOTHESE).\n\nReport back in a structured format grouped by submodule. Be thorough and comprehensive — this is one of the highest-risk areas and needs PRIMÄR-level evidence.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01SrzQCuCfVKpDUWwvR1pYDa",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Warehousing and Purchasing modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation.\n\nFocus area: `src\\centron\\Centron.WPF.UI\\Modules\\Warehousing\\` (AccountSystems, ArticleImport, ArticleManagement, ArticleUnitManagement, BarcodeManagement, Commissioning, Commissions, Inventory, MaterialGroupManagement, OutcomingPayments, SearchArticle, SupplierSearch, ValueAddedTax and any others you find) and `src\\centron\\Centron.WPF.UI\\Modules\\Purchasing\\` (EDIManagement, OrderSuggestionList, Others, PurchaseSettings, TravelExpense).\n\nFor EACH submodule, report:\n1. One-sentence description of its business purpose.\n2. 3-6 concrete facts: exact file path, class name, method name, and what the code does (status enums/state transitions, validation rules, calculation formulas, constraints).\n3. Look specifically for: article/inventory stock-level logic, order-suggestion algorithms (reorder point/quantity), VAT (ValueAddedTax) calculation rules, EDI order exchange formats, any permission checks.\n4. Note any DB constraints related to these modules if you happen to find references (don't go out of your way, just report what surfaces).\n5. Flag anything ambiguous where you could not find the enforcing logic.\n\nReport back in a structured format grouped by submodule, covering all submodules listed above.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_017PvYWMXHqbqjoukV1nCG8Z",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Helpdesk, ProjectManagement, Rma modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation.\n\nFocus area: `src\\centron\\Centron.WPF.UI\\Modules\\Helpdesk\\` (CentronChecklist, ConnectionNumber, ContractLogicHelper.cs, Dashboard, Events, ExpectedEvents, ExpectedEventsReporting, SendSelfCareForm, Settings, TaskManagement, TicketDetails, TicketList, TicketLogicHelper.cs, TicketProcessTemplates), `src\\centron\\Centron.WPF.UI\\Modules\\ProjectManagement\\`, and `src\\centron\\Centron.WPF.UI\\Modules\\Rma\\` (Events, NewRma, RmaCommon.cs, RmaOverview, RmaSettings, SendBack, SendForth).\n\nFor EACH submodule, report:\n1. One-sentence description of its business purpose.\n2. 3-6 concrete facts: exact file path, class name, method name, what the code does (status enums/state transitions like ticket status workflow, RMA status workflow, validation rules, constraints).\n3. Look specifically for: ticket status state machine (open/closed/escalated etc.), SLA/escalation logic (ExpectedEvents, EscalationsSettings references), RMA return workflow (SendBack vs SendForth — what's the difference?), permission checks.\n4. Flag anything ambiguous where you could not find the enforcing logic.\n\nReport back in a structured format grouped by submodule, covering all submodules listed above.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_013sa2durT3EEHktVGZMVZC3",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research apis, webservice, nexus, backend layers",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation.\n\nFocus areas (these are NOT the WPF UI modules — they are separate architectural components):\n1. `src\\apis\\` — Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess, Centron.APIs.FinAPI, Centron.APIs.ITscopeDataAccess, Centron.APIs.IcecatDataAccess, Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud. For each: what external system/service does it integrate with, and what's the integration mechanism (REST client, SOAP, file exchange)? One-sentence purpose + 2-4 facts each (exact file/class, what data is exchanged).\n2. `src\\webservice\\` — Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centron.WebServices.Core, c-entron.misc.ConnectionManager. What API endpoints exist (list controller classes and key routes/methods)? What authentication/authorization is applied to the web service (look for [Authorize] attributes, API key checks, etc.)?\n3. `src\\nexus\\` — CentronNexus, CentronNexus.Host, CentronNexus.OutlookAddIn. What is this component's purpose (likely Outlook/mail integration)? Key classes and what they do.\n4. `src\\backend\\` — Centron.BL, Centron.Common, Centron.DAO, Centron.Entities, Centron.Gateway, Centron.Interfaces. Give a one-paragraph architectural overview of what each project's role is (business logic layer, data access layer, entity/data model, gateway pattern, shared interfaces). Look for any central authentication/session/login mechanism (e.g. a Login or Authentication class) and report its exact location and how it validates credentials.\n5. `src\\shared\\` — Centron.Controls, Centron.Controls.Preview, Centron.Core. Brief purpose of each.\n\nAlso check root file `Centron.sln` briefly (just grep project names) to confirm you haven't missed any top-level project, and check `docker\\` and `deployment\\` and `azure\\`/`azure-blazor\\` folders for deployment/infrastructure facts (containerization, environment config, secrets handling) — report what you find, exact file paths.\n\nReport back in a structured format grouped by area. Be concrete: file paths, class names, method names.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01UnqZ1P6C6ay6BCxZJZNsVw",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research remaining WPF UI modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are researching the codebase at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system (\"c-entron\"). I need concrete, citable FACTS only — not requirements, not interpretation.\n\nFocus area: the remaining submodules under `src\\centron\\Centron.WPF.UI\\Modules\\` that are NOT Finances, PasswordManager, Administration, Warehousing, Purchasing, Helpdesk, ProjectManagement, or Rma (those are covered by other researchers). Specifically cover:\n- Calendar (Settings)\n- Dashboard (Modules)\n- DataExchange (BookKeeping, Connectors, DataExport, DataImport, DatevOnline2020, DocSync, DocuForm, PaymentTransactions, Rmm, SupplierOrderPerBranch, TelekomDive)\n- ExternalTool\n- Global (Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help, MSPLicensesCompare, NetworkDiagnostics, PdfAppModuleController, PerformanceTests, VideoPortal)\n- Gui (Profiles)\n- Massenupdates (Event, Updates)\n- MyCentron (Calendar, CentronInspectors, Dashboard, MyDay, PersonalSettings, Supremo, Telephony, TodoList)\n- OnlineBanking (AccountTransactions, ConfigurationSettings, ConnectionDialog)\n- PLM\n- PayersAndCostCenter\n- Production (MachineManagement, ProductionOrder, Settings)\n- ProjectPriceImport\n- QM (Settings)\n- Reports (ReportManagement)\n- Sales (Mailing, ProductMatrix, SpecialArticleImport, SpecialArticleToContractImport)\n- Statistics (Dashboard, EmployeeAnalytics, ManagementInfo, MspCollectors, MspStatistics, SaleStatistics)\n- Survey (Pages, SurveySettings)\n- TelekomDive\n- ArtificialIntelligence (Chat, Controller, OfferPositionsAIEditor, OpenAIConnect, TextRating)\n\nFor EACH submodule listed, report:\n1. One-sentence description of its business purpose (based on what you actually read).\n2. 2-5 concrete facts: exact file path, class name, method name, what the code does (status logic, validation rules, calculations, integration points — e.g. DatevOnline2020 = DATEV accounting export, BookKeeping likely relates to Finanzbuchhaltung export).\n3. Note anything that looks like an external integration (DATEV, banking, Supremo remote support, video portal, Telekom Dive) — what protocol/format is used if visible.\n4. Flag anything ambiguous where you could not determine the purpose from the code.\n\nThis is a breadth-first pass across ~35 submodules — keep each submodule entry concise (don't go deep), but make sure you cover ALL of them, none skipped. Report back in a structured format grouped by submodule.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ }
+]

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048/_meta/subagenten.md

@@ -0,0 +1,162 @@
+# Subagenten-Aufrufe
+
+Session `c143d465-d10e-4aad-b7e8-09c6cbde56d1`, Transkript `c143d465-d10e-4aad-b7e8-09c6cbde56d1.jsonl`.
+
+`subagent_stats`: **6** Subagenten gesamt, davon **0** von Subagenten gestartet (max_depth 1). Direkt vom Hauptagenten erwartet: **6**. Im Transkript gefunden: **6** echte Starts.
+
+## 1. Research Finances module facts
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2430  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation. I will write the actual requirements myself from your facts.
+
+Focus area: `src\centron\Centron.WPF.UI\Modules\Finances\` and its submodules: AccountManagement, AutomatedBilling, Campaigns, Common, ContractEvaluation2, ContractEvaluationOld, Contracts, Crm, DeviceClickCounter, Dunning, FlatrateBilling, MasterDataLists, Opos, Payments, ProductLifecycleManagement, Projects, Receipts, TimerBilling.
+
+This is a HIGH-PRIORITY risk area (billing/invoicing/dunning logic) — go deep here, not just breadth.
+
+For EACH submodule, report:
+1. One-sentence description of its business purpose (based on what you actually read, not guessed).
+2. 3-8 concrete facts: exact file path, class name, method name, and what the code actually does (status enums/state transitions, validation rules, calculation formulas, constraints, permission/rights checks). Quote or closely paraphrase the actual code — do not invent details.
+3. For any billing/invoicing/dunning logic specifically: find the EXACT enforcing location — file, class, method, and the specific condition/check code (e.g. "if (invoice.Status == InvoiceStatus.Paid) throw..." in InvoiceService.cs, method FinalizeInvoice()"). This is critical — generic "this file relates to billing" is NOT sufficient; I need the actual enforcing code location and condition.
+4. Note any DB constraints related to these modules if visible (check for related tables in the DB schema if you find references, but don't assume — only report what you actually find).
+5. Flag anything ambiguous or where you could NOT find the enforcing logic (I need this to mark items as HYPOTHESE).
+
+Also briefly check `src\backend\Centron.BL` and `src\backend\Centron.DAO` for any business-logic classes related to billing/contracts/dunning/invoicing that are shared/called from these UI modules (search by keyword: Invoice, Rechnung, Dunning, Mahnung, Contract, Vertrag, Billing).
+
+Report back in a structured format grouped by submodule. Be thorough — this is the highest-risk area of the specification and needs PRIMÄR-level evidence (the enforcing code location, not just a file reference). Aim for comprehensive coverage of all 18 submodules, not just a sample.
+```
+
+## 2. Research PasswordManager and Administration rights
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2313  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation. I will write the actual requirements myself from your facts.
+
+Focus area: `src\centron\Centron.WPF.UI\Modules\PasswordManager\` (AccessAreaManagement, AccessManagement, GuidelineManagement, RDPEmbedded, LayoutSaving) and `src\centron\Centron.WPF.UI\Modules\Administration\` (Cache, CentronConfigDb, Connections, CountryManagement, Customization, DSGVO, EmployeeManagement, EscalationsSettings, ExternalTools, HourlySurchargeRates, LogViewer, MailAndCalender, MailTemplates, MandatorManagement, PdfExport, PdfSigning, PhoneSettings, Profiling, ReceiptConditions, ReportServer, and any further subfolders you find under Administration — list ALL of them).
+
+This is a HIGH-PRIORITY risk area (security, access rights, permissions, GDPR/DSGVO) — go deep here, not just breadth.
+
+For EACH submodule, report:
+1. One-sentence description of its business purpose (based on what you actually read).
+2. 3-8 concrete facts: exact file path, class name, method name, what the code does (validation rules, constraints, status logic).
+3. For access/rights/permission checks specifically: find the EXACT enforcing location — file, class, method, and the specific condition/check code (e.g. rights expression evaluation, role checks, encryption of stored passwords, RDP credential handling). Also check `src\centron\Centron.WPF.UI\Modules\ModuleRightsExpressionParser.cs` and `ModuleRegistration.cs` for the general rights-check mechanism used across the whole app, and the root file `CentronRights.md`. I need the actual enforcing code location and condition, not a generic file reference.
+4. For DSGVO/GDPR-related code: what does it actually implement (data deletion, anonymization, export)?
+5. For MandatorManagement: how is multi-tenancy (Mandant) enforced — is there a mandator-scoping check anywhere?
+6. Flag anything ambiguous or where you could NOT find the enforcing logic (needed to mark as HYPOTHESE).
+
+Report back in a structured format grouped by submodule. Be thorough and comprehensive — this is one of the highest-risk areas and needs PRIMÄR-level evidence.
+```
+
+## 3. Research Warehousing and Purchasing modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1468  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation.
+
+Focus area: `src\centron\Centron.WPF.UI\Modules\Warehousing\` (AccountSystems, ArticleImport, ArticleManagement, ArticleUnitManagement, BarcodeManagement, Commissioning, Commissions, Inventory, MaterialGroupManagement, OutcomingPayments, SearchArticle, SupplierSearch, ValueAddedTax and any others you find) and `src\centron\Centron.WPF.UI\Modules\Purchasing\` (EDIManagement, OrderSuggestionList, Others, PurchaseSettings, TravelExpense).
+
+For EACH submodule, report:
+1. One-sentence description of its business purpose.
+2. 3-6 concrete facts: exact file path, class name, method name, and what the code does (status enums/state transitions, validation rules, calculation formulas, constraints).
+3. Look specifically for: article/inventory stock-level logic, order-suggestion algorithms (reorder point/quantity), VAT (ValueAddedTax) calculation rules, EDI order exchange formats, any permission checks.
+4. Note any DB constraints related to these modules if you happen to find references (don't go out of your way, just report what surfaces).
+5. Flag anything ambiguous where you could not find the enforcing logic.
+
+Report back in a structured format grouped by submodule, covering all submodules listed above.
+```
+
+## 4. Research Helpdesk, ProjectManagement, Rma modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1428  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation.
+
+Focus area: `src\centron\Centron.WPF.UI\Modules\Helpdesk\` (CentronChecklist, ConnectionNumber, ContractLogicHelper.cs, Dashboard, Events, ExpectedEvents, ExpectedEventsReporting, SendSelfCareForm, Settings, TaskManagement, TicketDetails, TicketList, TicketLogicHelper.cs, TicketProcessTemplates), `src\centron\Centron.WPF.UI\Modules\ProjectManagement\`, and `src\centron\Centron.WPF.UI\Modules\Rma\` (Events, NewRma, RmaCommon.cs, RmaOverview, RmaSettings, SendBack, SendForth).
+
+For EACH submodule, report:
+1. One-sentence description of its business purpose.
+2. 3-6 concrete facts: exact file path, class name, method name, what the code does (status enums/state transitions like ticket status workflow, RMA status workflow, validation rules, constraints).
+3. Look specifically for: ticket status state machine (open/closed/escalated etc.), SLA/escalation logic (ExpectedEvents, EscalationsSettings references), RMA return workflow (SendBack vs SendForth — what's the difference?), permission checks.
+4. Flag anything ambiguous where you could not find the enforcing logic.
+
+Report back in a structured format grouped by submodule, covering all submodules listed above.
+```
+
+## 5. Research apis, webservice, nexus, backend layers
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2319  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation.
+
+Focus areas (these are NOT the WPF UI modules — they are separate architectural components):
+1. `src\apis\` — Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess, Centron.APIs.FinAPI, Centron.APIs.ITscopeDataAccess, Centron.APIs.IcecatDataAccess, Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud. For each: what external system/service does it integrate with, and what's the integration mechanism (REST client, SOAP, file exchange)? One-sentence purpose + 2-4 facts each (exact file/class, what data is exchanged).
+2. `src\webservice\` — Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centron.WebServices.Core, c-entron.misc.ConnectionManager. What API endpoints exist (list controller classes and key routes/methods)? What authentication/authorization is applied to the web service (look for [Authorize] attributes, API key checks, etc.)?
+3. `src\nexus\` — CentronNexus, CentronNexus.Host, CentronNexus.OutlookAddIn. What is this component's purpose (likely Outlook/mail integration)? Key classes and what they do.
+4. `src\backend\` — Centron.BL, Centron.Common, Centron.DAO, Centron.Entities, Centron.Gateway, Centron.Interfaces. Give a one-paragraph architectural overview of what each project's role is (business logic layer, data access layer, entity/data model, gateway pattern, shared interfaces). Look for any central authentication/session/login mechanism (e.g. a Login or Authentication class) and report its exact location and how it validates credentials.
+5. `src\shared\` — Centron.Controls, Centron.Controls.Preview, Centron.Core. Brief purpose of each.
+
+Also check root file `Centron.sln` briefly (just grep project names) to confirm you haven't missed any top-level project, and check `docker\` and `deployment\` and `azure\`/`azure-blazor\` folders for deployment/infrastructure facts (containerization, environment config, secrets handling) — report what you find, exact file paths.
+
+Report back in a structured format grouped by area. Be concrete: file paths, class names, method names.
+```
+
+## 6. Research remaining WPF UI modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2503  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are researching the codebase at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering effort. This is a legacy WPF/C#/MSSQL ERP system ("c-entron"). I need concrete, citable FACTS only — not requirements, not interpretation.
+
+Focus area: the remaining submodules under `src\centron\Centron.WPF.UI\Modules\` that are NOT Finances, PasswordManager, Administration, Warehousing, Purchasing, Helpdesk, ProjectManagement, or Rma (those are covered by other researchers). Specifically cover:
+- Calendar (Settings)
+- Dashboard (Modules)
+- DataExchange (BookKeeping, Connectors, DataExport, DataImport, DatevOnline2020, DocSync, DocuForm, PaymentTransactions, Rmm, SupplierOrderPerBranch, TelekomDive)
+- ExternalTool
+- Global (Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help, MSPLicensesCompare, NetworkDiagnostics, PdfAppModuleController, PerformanceTests, VideoPortal)
+- Gui (Profiles)
+- Massenupdates (Event, Updates)
+- MyCentron (Calendar, CentronInspectors, Dashboard, MyDay, PersonalSettings, Supremo, Telephony, TodoList)
+- OnlineBanking (AccountTransactions, ConfigurationSettings, ConnectionDialog)
+- PLM
+- PayersAndCostCenter
+- Production (MachineManagement, ProductionOrder, Settings)
+- ProjectPriceImport
+- QM (Settings)
+- Reports (ReportManagement)
+- Sales (Mailing, ProductMatrix, SpecialArticleImport, SpecialArticleToContractImport)
+- Statistics (Dashboard, EmployeeAnalytics, ManagementInfo, MspCollectors, MspStatistics, SaleStatistics)
+- Survey (Pages, SurveySettings)
+- TelekomDive
+- ArtificialIntelligence (Chat, Controller, OfferPositionsAIEditor, OpenAIConnect, TextRating)
+
+For EACH submodule listed, report:
+1. One-sentence description of its business purpose (based on what you actually read).
+2. 2-5 concrete facts: exact file path, class name, method name, what the code does (status logic, validation rules, calculations, integration points — e.g. DatevOnline2020 = DATEV accounting export, BookKeeping likely relates to Finanzbuchhaltung export).
+3. Note anything that looks like an external integration (DATEV, banking, Supremo remote support, video portal, Telekom Dive) — what protocol/format is used if visible.
+4. Flag anything ambiguous where you could not determine the purpose from the code.
+
+This is a breadth-first pass across ~35 submodules — keep each submodule entry concise (don't go deep), but make sure you cover ALL of them, none skipped. Report back in a structured format grouped by submodule.
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Ergebnisse/Analysebericht.md

@@ -0,0 +1,438 @@
+# Analysebericht
+
+## Schritt 0 — Modulinventar
+
+Vollständiger Überblick über den Untersuchungsgegenstand, erstellt vor der ersten Anforderung. Pfade sind relativ zum Repository-Wurzelverzeichnis. Die Spalte „Ebene" unterscheidet fachliche UI-Module (WPF-Client `src/centron/Centron.WPF.UI/Modules/...`) von technischen/architektonischen Komponenten (Backend-Schichten, Gateways, Webservice, Portal). Das Inventar wurde vor Formulierung der ersten Anforderung durch Vollsichtung der Verzeichnisstruktur und stichprobenartige Quelltextprüfung je Ordner erstellt.
+
+### A. Fachliche UI-Module (Client)
+
+| # | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| 1 | Sales (Container) | src/centron/Centron.WPF.UI/Modules/Sales | Reiner Namensraum-Container ohne eigene Dateien, bündelt Vertriebsuntermodule. |
+| 2 | Sales/Mailing | .../Sales/Mailing | Verwaltung von E-Mail-/Serienbrief-Vorlagen für Vertriebs-Mailings. |
+| 3 | Sales/ProductMatrix | .../Sales/ProductMatrix | Konfiguration kundenspezifischer Produktmatrizen (Artikel-Kunden-Konditionszuordnung). |
+| 4 | Sales/SpecialArticleImport | .../Sales/SpecialArticleImport | Erfassen und Anlegen von Sonderartikeln, manuelle Übernahme in Verträge. |
+| 5 | Sales/SpecialArticleToContractImport | .../Sales/SpecialArticleToContractImport | Massenimport von Sonderartikeln in bestehende Verträge inkl. Importhistorie. |
+| 6 | Finances (Container) | .../Finances | Reiner Namensraum-Container ohne eigene Dateien, bündelt Finanzuntermodule. |
+| 7 | Finances/AccountManagement | .../Finances/AccountManagement | Kunden-/Kontenübersicht (Belege, Tickets, Verkaufsstatistik je Kunde). |
+| 8 | Finances/AutomatedBilling | .../Finances/AutomatedBilling | Automatisierte Sammelabrechnung (Fakturierung) von Verträgen. |
+| 9 | Finances/Campaigns | .../Finances/Campaigns | Verwaltung von Marketing-/Vertriebskampagnen. |
+| 10 | Finances/ContractEvaluation2 | .../Finances/ContractEvaluation2 | Aktuelle Vertragsauswertung/-statistik für Controlling. |
+| 11 | Finances/ContractEvaluationOld | .../Finances/ContractEvaluationOld | Vorgänger-Vertragsauswertung (Detail-Drilldown je Vertrag). |
+| 12 | Finances/Contracts | .../Finances/Contracts | Zentrale Vertragsverwaltung (Anlage/Bearbeitung von Kundenverträgen). |
+| 13 | Finances/Crm | .../Finances/Crm | CRM-Hauptmodul: Adress-/Kontaktsuche, Kundenneuanlage. |
+| 14 | Finances/DeviceClickCounter | .../Finances/DeviceClickCounter | Erfassung von Zählerständen für klickbasierte Abrechnung. |
+| 15 | Finances/Dunning | .../Finances/Dunning | Mahnwesen-Übersicht und Durchführung von Mahnläufen. |
+| 16 | Finances/FlatrateBilling | .../Finances/FlatrateBilling | Pauschalabrechnung von Aufträgen/Helpdesk-Zeiten. |
+| 17 | Finances/MasterDataLists | .../Finances/MasterDataLists | Stammdatenlisten je Vertrag/Kunde (Geräte, Verbrauchsmaterial, Tickets, Zähler). |
+| 18 | Finances/Opos | .../Finances/Opos | Offene-Posten-Lauf (Saldenbestätigung). |
+| 19 | Finances/Payments | .../Finances/Payments | Erfassung eingehender Zahlungen zu Belegen. |
+| 20 | Finances/ProductLifecycleManagement | .../Finances/ProductLifecycleManagement | Nur Einstellungen vorhanden, kein eigenständiges Fachmodul im UI. |
+| 21 | Finances/Projects | .../Finances/Projects | Projektverwaltung/-übersicht (CRM-Projekte). |
+| 22 | Finances/Receipts | .../Finances/Receipts | Zentrales Beleg-/Rechnungsmodul (alle Belegtypen). |
+| 23 | Finances/TimerBilling | .../Finances/TimerBilling | Abrechnung erfasster Zeiterfassungen als Rechnungen. |
+| 24 | Finances/Common | .../Finances/Common | Rein technische Exporthilfsklasse (Excel/PDF/CSV), keine Fachlogik. |
+| 25 | Logistic | .../Logistic (+LogisticSettings, ShippingMethodSettings) | Einstellungen für Versand-/Kommissionierprozesse und Versandarten für Retouren. |
+| 26 | Purchasing | .../Purchasing (+EDIManagement, OrderSuggestionList, Others, PurchaseSettings, TravelExpense) | Einkaufsmodul: EDI-Bestellabwicklung, Bestellvorschlagsliste, Reisekostenabrechnung. |
+| 27 | Warehousing | .../Warehousing (+AccountSystems…SupplierSearch) | Lagerverwaltung: Artikelstammdaten, Barcode, Kommissionierung, Inventur, Kreditorenzahlungen. |
+| 28 | Production | .../Production (+MachineManagement, ProductionOrder, Settings) | Verwaltung von Produktionsmaschinen und Fertigungsaufträgen. |
+| 29 | ProjectManagement | .../ProjectManagement | Projekt- und Ticketverwaltung inkl. Mitarbeiterauslastung. |
+| 30 | QM | .../QM (+Settings) | Konfiguration von Rückmelde-/Ablehnungsgründen für Lieferanten-/Kundenbelege. |
+| 31 | Rma | .../Rma | Übersicht über RMA-Vorgänge (Retourenabwicklung). |
+| 32 | Rma/Events | .../Rma/Events | Event-Objekt zur Benachrichtigung über neue RMA-Vorgänge. |
+| 33 | Rma/NewRma | .../Rma/NewRma | Dialog zur Neuanlage eines RMA-Vorgangs. |
+| 34 | Rma/RmaSettings | .../Rma/RmaSettings | Stammdaten für RMA-Vorgänge (Typen, Kategorien, Standardlager). |
+| 35 | Rma/SendBack | .../Rma/SendBack | Erfassung der Rücksendung im RMA-Prozess. |
+| 36 | Rma/SendForth | .../Rma/SendForth | Weiterversand (Ersatzware) im RMA-Prozess. |
+| 37 | Reports | .../Reports | Einstiegsmodul für Reportverwaltung. |
+| 38 | Reports/ReportManagement | .../Reports/ReportManagement | Report-Engine-Fenster (Verwaltung, Abfrage, Anzeige von Berichten). |
+| 39 | Global | .../Global | Übergreifende, modulunabhängige UI-Funktionen (Über-Dialog, PDF-Anzeige). |
+| 40 | Global/Actions | .../Global/Actions | Wiederverwendbare Ribbon-Aktionen zum PDF-Druck/-Speichern. |
+| 41 | Global/CustomProperties | .../Global/CustomProperties | Verwaltung benutzerdefinierter Zusatzfelder je Objekttyp. |
+| 42 | Global/EmployeeSelection | .../Global/EmployeeSelection | Wiederverwendbare Mitarbeiterauswahl-Komponente. |
+| 43 | Global/ExceptionMessage | .../Global/ExceptionMessage | Fehlermeldedialog bei Ausnahmefehlern. |
+| 44 | Global/FileSystemDialog | .../Global/FileSystemDialog | Generischer Datei-/Verzeichnisauswahldialog. |
+| 45 | Global/Help | .../Global/Help | Integrierte c-entron-Hilfe. |
+| 46 | Global/MSPLicensesCompare | .../Global/MSPLicensesCompare | Vergleich von Microsoft-/MSP-Lizenzen. |
+| 47 | Global/NetworkDiagnostics | .../Global/NetworkDiagnostics | Diagnosewerkzeug für Netzwerk-/Zertifikatsprüfung. |
+| 48 | Global/PerformanceTests | .../Global/PerformanceTests | Internes Performance-/Lasttest-Werkzeug. |
+| 49 | Global/VideoPortal | .../Global/VideoPortal | Integriertes Schulungs-/Videoportal mit Sehverhalten-Auswertung. |
+| 50 | Gui | .../Gui | UI-Rahmenfunktionen der Anwendung. |
+| 51 | Gui/Profiles | .../Gui/Profiles | Verwaltung von UI-Profilen (öffentlich/privat). |
+| 52 | DataExchange | .../DataExchange | Sammelmodul für Datenaustausch-Schnittstellen zu externen Systemen. |
+| 53 | DataExchange/BookKeeping | .../DataExchange/BookKeeping | Export/Import von Finanzbuchhaltungsdaten an/von externe FiBu-Systeme. |
+| 54 | DataExchange/Connectors | .../DataExchange/Connectors | Konfiguration externer DMS-Konnektoren (z. B. DocBee). |
+| 55 | DataExchange/DataExport | .../DataExchange/DataExport | Generischer Datenexport-Dialog (u. a. Rechnungsexport). |
+| 56 | DataExchange/DataImport | .../DataExchange/DataImport | Generischer Datenimport-Dialog (Konten, AD-Benutzer, Artikel, CRM etc.). |
+| 57 | DataExchange/DatevOnline2020 | .../DataExchange/DatevOnline2020 | Direktanbindung an DATEV Online zur Belegübermittlung. |
+| 58 | DataExchange/DocSync | .../DataExchange/DocSync | Synchronisation von Dokumenten/Objekten mit externem System. |
+| 59 | DataExchange/DocuForm | .../DataExchange/DocuForm | Anbindung an DocuForm (elektronischer Formularversand) inkl. OAuth. |
+| 60 | DataExchange/PaymentTransactions | .../DataExchange/PaymentTransactions | Erstellung von SEPA-Zahlungsdateien und Zahlungsprotokollierung. |
+| 61 | DataExchange/Rmm | .../DataExchange/Rmm | Konfiguration der Verbindung zu einem RMM-System. |
+| 62 | DataExchange/SupplierOrderPerBranch | .../DataExchange/SupplierOrderPerBranch | Filialbezogene Lieferantenbestellung. |
+| 63 | DataExchange/TelekomDive | .../DataExchange/TelekomDive | Anbindung an Telekom-DIVE-Plattform (Materialgruppen/Profile). |
+| 64 | Administration/Cache | .../Administration/Cache | Client-seitige Zwischenspeicherung von Stammdaten. |
+| 65 | Administration/CentronConfigDb | .../Administration/CentronConfigDb | Verwaltung der zentralen Konfigurationsdatenbank inkl. Hotline-Masterkey. |
+| 66 | Administration/Connections | .../Administration/Connections | Verbindungsverwaltung zum Server/Webservice inkl. Login und 2FA. |
+| 67 | Administration/CountryManagement | .../Administration/CountryManagement | Pflege von Länder-/Bundesland-Stammdaten. |
+| 68 | Administration/Customization | .../Administration/Customization | Framework für benutzerdefinierte Felder in Grid-Ansichten. |
+| 69 | Administration/DSGVO | .../Administration/DSGVO | Datenschutzkonforme Datenbereinigung und Auftragsverarbeitungsverträge. |
+| 70 | Administration/EmployeeManagement | .../Administration/EmployeeManagement | Zentrale Mitarbeiterverwaltung inkl. AD-Import. |
+| 71 | Administration/EscalationsSettings | .../Administration/EscalationsSettings | Konfiguration automatischer Eskalationsregeln. |
+| 72 | Administration/ExternalTools | .../Administration/ExternalTools | Konfiguration extern aufrufbarer Tools/Skripte. |
+| 73 | Administration/HourlySurchargeRates | .../Administration/HourlySurchargeRates | Verwaltung von Stundenzuschlagssätzen. |
+| 74 | Administration/LogViewer | .../Administration/LogViewer | Live-Anzeige des Anwendungslogs. |
+| 75 | Administration/MailAndCalender | .../Administration/MailAndCalender | Allgemeine Mail-/Kalender-Client-Einstellungen. |
+| 76 | Administration/MailTemplates | .../Administration/MailTemplates | Verwaltung von E-Mail-Vorlagen inkl. KI-Unterstützung. |
+| 77 | Administration/MandatorManagement | .../Administration/MandatorManagement | Stammdatenverwaltung der Mandanten und Filialen. |
+| 78 | Administration/PdfExport | .../Administration/PdfExport | Konfiguration der PDF-Exportparameter (Compliance-Standard). |
+| 79 | Administration/PdfSigning | .../Administration/PdfSigning | Konfiguration/Ausführung der digitalen PDF-Signierung. |
+| 80 | Administration/PhoneSettings | .../Administration/PhoneSettings | Konfiguration der TAPI-Telefonie-Integration. |
+| 81 | Administration/Profiling | .../Administration/Profiling | Aktivierung des erweiterten Beleg-Profilings. |
+| 82 | Administration/ReceiptConditions | .../Administration/ReceiptConditions | Verwaltung von Zahlungs-/Belegkonditionen (Skonto, ESR/DTA). |
+| 83 | Administration/ReportServer | .../Administration/ReportServer | Anbindung/Verwaltung eines Report-Servers. |
+| 84 | Administration/RightsManagement | .../Administration/RightsManagement | Zentrale Vergabe/Verwaltung von Benutzerrechten (Autorisierungsbasis). |
+| 85 | Administration/SendDeliveryListShippingConfirmationSettings | .../Administration/SendDeliveryListShippingConfirmationSettings | Automatischer Versand von Versandbestätigungen. |
+| 86 | Administration/SepaContract | .../Administration/SepaContract | Erstellung/Signatur von SEPA-Lastschrift-Mandatsverträgen. |
+| 87 | Administration/ServiceAndLeasing | .../Administration/ServiceAndLeasing | Verwaltung von Service-/Leasing-Tarifen. |
+| 88 | Administration/Services | .../Administration/Services | Hintergrunddienst-Einstellungen (CTime, Notifications, Indexsuche). |
+| 89 | Administration/Settings | .../Administration/Settings | Übergeordneter Container aller Administrations-Einstellungsmodule. |
+| 90 | Administration/SqlManagers | .../Administration/SqlManagers | Direktes Ausführen von SQL-Abfragen (Diagnose/Wartung). |
+| 91 | Administration/TaskManagmentSettings | .../Administration/TaskManagmentSettings | Allgemeine Einstellungen für die Aufgabenverwaltung. |
+| 92 | Administration/TextBlockManagement | .../Administration/TextBlockManagement | Verwaltung wiederverwendbarer Textbausteine inkl. KI-Unterstützung. |
+| 93 | Administration/UpdateAvailableNotificationSettings | .../Administration/UpdateAvailableNotificationSettings | Konfiguration der Update-Benachrichtigung. |
+| 94 | Administration/WebCart | .../Administration/WebCart | Einstellungen für den Web-Warenkorb. |
+| 95 | Administration/WebServiceSettings | .../Administration/WebServiceSettings | Konfiguration der Webservice-Schnittstellen (Ticket-Timeout, Kalender-Sync, Lizenz). |
+| 96 | ArtificialIntelligence | .../ArtificialIntelligence | KI-Chat-Assistent mit Werkzeugintegration in ERP-Module. |
+| 97 | ArtificialIntelligence/OpenAIConnect | .../ArtificialIntelligence/OpenAIConnect | Anbindung an OpenAI-kompatible APIs zur Textgenerierung. |
+| 98 | Calendar | .../Calendar (+Settings) | Konfiguration der Kalenderfunktionen (Terminvorlagen, Outlook-Sync). |
+| 99 | Dashboard | .../Dashboard (+Modules) | Startbildschirm/Modulübersicht inkl. Favoriten und Rechteanzeige. |
+| 100 | ExternalTool | .../ExternalTool (+Variables) | Verwaltung/Vorschau extern eingebundener Tools. |
+| 101 | Helpdesk | .../Helpdesk (+12 Unterordner) | Zentrales Ticket-/Support-Modul (Erstellung, Bearbeitung, SLA, Eskalation). |
+| 102 | Massenupdates | .../Massenupdates (+Event, Updates) | Massenaktualisierung von Stammdaten/Preisen über Wizard. |
+| 103 | MyCentron | .../MyCentron (+8 Unterordner) | Persönlicher Arbeitsbereich des Mitarbeiters (Kalender, MyDay, Dashboard, ToDo). |
+| 104 | OnlineBanking (UI) | .../OnlineBanking (+3 Unterordner) | Abruf von Kontoauszügen (FinTS/finAPI) und Rechnungsabgleich. |
+| 105 | PasswordManager | .../PasswordManager (+2 Unterordner) | Verwaltung von Zugangsbereichen, Passwort-Richtlinien, VPN/SSH/RDP-Zugängen. |
+| 106 | PayersAndCostCenter | .../PayersAndCostCenter (+2 Unterordner) | Erstellung/Verwaltung von Kostenträgern und Kostenstellen. |
+| 107 | PLM | .../PLM | Verwaltung von Produktfamilien/Lebenszyklusinformationen. |
+| 108 | ProjectPriceImport | .../ProjectPriceImport (+2 Unterordner) | Import von Projektpreisen als Sondervereinbarungen. |
+| 109 | Statistics | .../Statistics (+6 Unterordner) | Betriebswirtschaftliche Auswertungen (Sales, Mitarbeiterauslastung, MSP). |
+| 110 | Survey | .../Survey (+2 Unterordner) | Erstellung/Durchführung/Auswertung von Kundenaudits. |
+| 111 | TelekomDive (UI) | .../TelekomDive (+ViewModels) | Export von Kunden-/Artikeldaten in das Telekom-DIVE-Format. |
+
+### B. Technische/architektonische Komponenten (Backend, Gateways, Webservice, Portal)
+
+| # | Komponente | Pfad | Fachliche/technische Aufgabe |
+|---|---|---|---|
+| 112 | Centron.DAO | src/backend/Centron.DAO | NHibernate-Datenzugriffsschicht inkl. automatischer Änderungsprotokollierung. |
+| 113 | Centron.Entities | src/backend/Centron.Entities | Zentrales Domänenmodell (ca. 1.179 Entitätsklassen). |
+| 114 | Centron.Gateway/Concerto | src/backend/Centron.Gateway/Concerto | XSD-generierte Datenklassen für Concerto-B2B-Bestellaustausch. |
+| 115 | Centron.Gateway/Core | src/backend/Centron.Gateway/Core | Gemeinsame Ergebnistypen für Gateway-Operationen. |
+| 116 | Centron.Gateway/DataExchange | src/backend/Centron.Gateway/DataExchange | Interfaces für Buchhaltungssystem-Exporter/-Importer (Datev, SAP, Sage50 u. a.). |
+| 117 | Centron.Gateway EDI-Konnektoren | .../EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa | Distributorspezifische XSD-Datenklassen für elektronischen Bestellaustausch. |
+| 118 | Centron.Gateway/Export+Import | .../Export, .../Import | Ablagestruktur für EDI-Export-/Importdateien. |
+| 119 | Centron.Gateway/MspCollector | src/backend/Centron.Gateway/MspCollector | Sammlung von MSP-Nutzungsdaten (Octopus, Wortmann) für Abrechnung. |
+| 120 | Centron.Gateway/OnlineBanking | src/backend/Centron.Gateway/OnlineBanking | FinTS/HBCI-Anbindung über libfintx. |
+| 121 | Centron.Gateway/OpenTrans(+1.0) | .../OpenTrans, .../OpenTrans1_0 | XSD-Datenklassen für openTRANS-B2B-Standard inkl. BMEcat. |
+| 122 | Centron.Gateway/Portal | src/backend/Centron.Gateway/Portal | WCF/SOAP-Client zum c-entron-Portal-Webservice. |
+| 123 | Centron.Gateway/ZUGFeRD21_Extended | src/backend/Centron.Gateway/ZUGFeRD21_Extended | Datenmodell für ZUGFeRD-2.1-E-Rechnung (Profil EXTENDED). |
+| 124 | Centron.Controllers/Controllers | src/webservice/Centron.Controllers/Controllers | REST-API-Controller (v1) für Fachlogik-Zugriff von außen. |
+| 125 | Centron.Controllers/Authorization | src/webservice/Centron.Controllers/Authorization (+Centron.Host) | Authentifizierung/Autorisierung der Web-API (Ticket/AccessToken/JWT, Rechteprüfung). |
+| 126 | CentronNexus | src/nexus/CentronNexus | Blazor-Kunden-/Mitarbeiterportal (Webshop, Vertragseinsicht, Signatur). |
+| 127 | Centron.Core / Centron.Controls | src/shared/Centron.Core, src/shared/Centron.Controls | Gemeinsame Basisinfrastruktur (MVVM, 2FA, PDF-Scan) und WPF-UI-Controls. |
+| 128 | Centron.BL/Security | src/backend/Centron.BL/Security | Digitale PDF-Signatur (Zertifikat, Zeitstempel). |
+| 129 | Centron.BL/TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | Verwaltung/Prüfung des 2FA-TOTP-Schlüssels beim Login. |
+| 130 | Centron.BL/Mobile | src/backend/Centron.BL/Mobile | Lese-Zugriff für mobile App-Anbindung (Mitarbeiter-/Kontaktdaten). |
+| 131 | Centron.BL/Integrations | src/backend/Centron.BL/Integrations | Caching von Stammdaten aus externer "ElectronicSales"-Integration. |
+| 132 | Centron.BL/Telemetry | src/backend/Centron.BL/Telemetry | Erfassung/Aggregation von Nutzungstelemetrie. |
+| 133 | Centron.BL/ReportEngine | src/backend/Centron.BL/ReportEngine | Berichts-Engine (FastReport, PDF-Exportstrategien, ZUGFeRD-Generator). |
+| 134 | Centron.BL/Reporting | src/backend/Centron.BL/Reporting | Verwaltung von CentronReport-Berichtsvorlagen. |
+| 135 | Centron.BL/TaskManager | src/backend/Centron.BL/TaskManager | Automatisierte, wiederkehrende Aufgaben (Scheduler). |
+| 136 | Centron.BL/MassUpdate | src/backend/Centron.BL/MassUpdate | Batch-Update-Engine für Preise/Stammdaten. |
+| 137 | Centron.BL/Notifications | src/backend/Centron.BL/Notifications | Zentrale System- und Benutzerbenachrichtigungen. |
+| 138 | Centron.BL/IndexSearch | src/backend/Centron.BL/IndexSearch | Eigene Volltextsuche/Indizierung (deutscher Analyzer). |
+| 139 | Centron.BL/ChangeTracking | src/backend/Centron.BL/ChangeTracking | Protokollierung von Importvorgängen (Importhistorie). |
+| 140 | Centron.BL/SocialMedia | src/backend/Centron.BL/SocialMedia | Verwaltung von Social-Media-Aktionen/-Streams. |
+| 141 | Centron.BL/RiverDivo | src/backend/Centron.BL/RiverDivo | Web-Service-Schnittstelle für Riverbird/RiverDivo-Partneranbindung. |
+| 142 | Centron.BL/TradePool | src/backend/Centron.BL/TradePool | Import von Handelsartikeln aus externen XML-Dateien. |
+| 143 | Centron.BL/WebSuite | src/backend/Centron.BL/WebSuite | Backend für Web-Portal-Administration (Benutzer, Menüs). |
+| 144 | Centron.BL/WebVersion | src/backend/Centron.BL/WebVersion | Liefert die Webservice-Assemblyversion. |
+| 145 | Centron.BL/Chats | src/backend/Centron.BL/Chats | Interne Chat-Konversationen, verknüpft mit Tickets/Belegen. |
+| 146 | Centron.BL/DocuBoard | src/backend/Centron.BL/DocuBoard | Asset-Management-Zuordnungen (Artikel/Partner). |
+| 147 | Centron.BL/ItPlanner | src/backend/Centron.BL/ItPlanner | Kategorien virtueller Objekte für Checklisten. |
+| 148 | Centron.BL/MailScanner | src/backend/Centron.BL/MailScanner | Automatisierte E-Mail-Scan-Workflows. |
+| 149 | Centron.BL/Outlook | src/backend/Centron.BL/Outlook | Kundensuche mit Asset-Einträgen für Outlook-Add-in. |
+| 150 | Centron.BL/Tapi | src/backend/Centron.BL/Tapi | Telefonieanbindung (TAPI/MS-Graph-Anrufprotokolle). |
+| 151 | Centron.BL/CPra | src/backend/Centron.BL/CPra | Anbindung des externen c-pra-REST-Dienstes. |
+| 152 | Centron.BL/SelfCare | src/backend/Centron.BL/SelfCare | Self-Service-Formulare/-Anfragen des Kundenportals. |
+| 153 | Centron.BL/BusinessPartner | src/backend/Centron.BL/BusinessPartner | Lieferantensuche/-verwaltung als Geschäftspartner. |
+| 154 | Centron.BL/CustomerArea | src/backend/Centron.BL/CustomerArea | Kundenbezogene RMA-/Kontaktaktivitäten-Logik. |
+| 155 | Centron.BL/EmployeeArea | src/backend/Centron.BL/EmployeeArea | Zentrale Mitarbeiterverwaltung (Backend). |
+| 156 | Centron.BL/CountryArea | src/backend/Centron.BL/CountryArea | Länder-/Bundesland-Stammdaten (Backend). |
+| 157 | Centron.BL/AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Terminanfragen inkl. Exchange-Antwortverarbeitung. |
+| 158 | Centron.BL/Accounts | src/backend/Centron.BL/Accounts | Kernmodul für Kunden-/Konto-Stammdaten. |
+| 159 | Centron.BL/Accounting | src/backend/Centron.BL/Accounting | Verwaltung von Bankverbindungen (Zahlungsdaten). |
+| 160 | Centron.BL/Buying | src/backend/Centron.BL/Buying | Verwaltung externer Distributoren/Lieferanten. |
+| 161 | Centron.BL/EDI | src/backend/Centron.BL/EDI | EDI-Dispatcher (Bestellübermittlung, Rechnungsimport, ZUGFeRD-Lesen). |
+| 162 | Centron.BL/Devices | src/backend/Centron.BL/Devices | Verwaltung kundenspezifischer Geräte (AccountDevice). |
+| 163 | Centron.BL/ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Generische Verknüpfung von Objekten mit externen Systemreferenzen. |
+| 164 | Centron.BL/ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Konfiguration externer Helpdesk-Systemanbindungen. |
+| 165 | Centron.BL/PasswordManagementArea (Legacy) | src/backend/Centron.BL/PasswordManagementArea | Ältere, unvollständige Passwortverwaltungslogik (abgelöst durch AES-Verfahren). |
+
+Anzahl erfasster Module/Komponenten: **165** (111 fachliche UI-Module, 54 technische Komponenten). Vier UI-Module (Sales-Container, Finances-Container, Finances/ProductLifecycleManagement, Finances/Common) enthalten laut Quellcodesichtung keine eigenständige Fachlogik (reine Namensraum-Container bzw. technische Exporthilfsklasse) und werden unten als „nicht analysiert" mit Begründung geführt statt mit einer erzwungenen Anforderung versehen.
+
+## Schritt 0b — Abdeckungstabelle
+
+Einstufung je Modul: **tief** (StRS+SyRS+SwRS mit mindestens einem PRIMÄR-Beleg einer durchsetzenden Stelle), **mittel** (StRS+SyRS mit konkretem Klassen-/Methodenbeleg), **flach** (nur rahmenhafte KONTEXT-/Strukturevidenz, meist Container- oder Sammelordner ohne eigene Fachlogiktiefe), **nicht analysiert** (kein Beleg auffindbar, Begründung angegeben). Die Spalte „Anzahl" zählt alle IDs (StRS+SyRS+SwRS), die diesem Modul in der Traceability-Tabelle zugeordnet sind.
+
+### A. Fachliche UI-Module
+
+| # | Modul | Einstufung | Anzahl | Anforderungs-IDs |
+|---|---|---|---|---|
+| 1 | Sales (Container) | nicht analysiert | 0 | – (Begründung: reiner Namensraum-Container ohne eigene Datei) |
+| 2 | Sales/Mailing | mittel | 2 | StRS-1, SyRS-121 |
+| 3 | Sales/ProductMatrix | mittel | 2 | StRS-2, SyRS-122 |
+| 4 | Sales/SpecialArticleImport | mittel | 2 | StRS-3, SyRS-123 |
+| 5 | Sales/SpecialArticleToContractImport | mittel | 2 | StRS-4, SyRS-123 |
+| 6 | Finances (Container) | nicht analysiert | 0 | – (Begründung: reiner Namensraum-Container ohne eigene Datei) |
+| 7 | Finances/AccountManagement | mittel | 2 | StRS-5, SyRS-124 |
+| 8 | Finances/AutomatedBilling | tief | 3 | StRS-6, SyRS-101, SwRS-101 |
+| 9 | Finances/Campaigns | mittel | 2 | StRS-7, SyRS-125 (HYPOTHESE) |
+| 10 | Finances/ContractEvaluation2 | mittel | 2 | StRS-8, SyRS-126 |
+| 11 | Finances/ContractEvaluationOld | mittel | 2 | StRS-9, SyRS-126 |
+| 12 | Finances/Contracts | tief | 3 | StRS-10, SyRS-101, SwRS-101 |
+| 13 | Finances/Crm | mittel | 2 | StRS-11, SyRS-127 |
+| 14 | Finances/DeviceClickCounter | mittel | 2 | StRS-12, SyRS-128 |
+| 15 | Finances/Dunning | tief | 3 | StRS-13, SyRS-103, SwRS-103 |
+| 16 | Finances/FlatrateBilling | mittel | 2 | StRS-14, SyRS-104 |
+| 17 | Finances/MasterDataLists | mittel | 2 | StRS-15, SyRS-105 |
+| 18 | Finances/Opos | tief | 3 | StRS-16, SyRS-106, SwRS-106 |
+| 19 | Finances/Payments | mittel | 2 | StRS-17, SyRS-107 |
+| 20 | Finances/ProductLifecycleManagement | nicht analysiert | 0 | – (Begründung: nur Settings-Unterordner, kein eigenständiges Fachmodul im UI) |
+| 21 | Finances/Projects | mittel | 2 | StRS-18, SyRS-129 |
+| 22 | Finances/Receipts | tief | 3 | StRS-19, SyRS-108, SwRS-108 |
+| 23 | Finances/TimerBilling | mittel | 2 | StRS-20, SyRS-109 |
+| 24 | Finances/Common | nicht analysiert | 0 | – (Begründung: rein technische Exporthilfsklasse ohne Fachlogik) |
+| 25 | Logistic | mittel | 2 | StRS-21, SyRS-130 (HYPOTHESE) |
+| 26 | Purchasing | tief | 6 | StRS-22, SyRS-131, SwRS-131, StRS-23, SyRS-132, SwRS-132 |
+| 27 | Warehousing | tief | 6 | StRS-24, SyRS-133, SwRS-133, StRS-25, SyRS-134, SwRS-134 |
+| 28 | Production | mittel | 2 | StRS-26, SyRS-135 |
+| 29 | ProjectManagement | mittel | 2 | StRS-27, SyRS-136 |
+| 30 | QM | mittel | 2 | StRS-28, SyRS-137 |
+| 31 | Rma | mittel | 2 | StRS-29, SyRS-138 |
+| 32 | Rma/Events | mittel | 2 | StRS-30, SyRS-138 |
+| 33 | Rma/NewRma | mittel | 2 | StRS-31, SyRS-138 |
+| 34 | Rma/RmaSettings | mittel | 2 | StRS-32, SyRS-138 |
+| 35 | Rma/SendBack | mittel | 2 | StRS-33, SyRS-138 |
+| 36 | Rma/SendForth | mittel | 2 | StRS-34, SyRS-138 |
+| 37 | Reports | mittel | 2 | StRS-35, SyRS-139 |
+| 38 | Reports/ReportManagement | tief | 3 | StRS-36, SyRS-139, SwRS-139 |
+| 39 | Global | flach | 2 | StRS-37, SyRS-140 |
+| 40 | Global/Actions | flach | 2 | StRS-38, SyRS-140 |
+| 41 | Global/CustomProperties | tief | 3 | StRS-39, SyRS-141, SwRS-141 |
+| 42 | Global/EmployeeSelection | flach | 2 | StRS-40, SyRS-140 |
+| 43 | Global/ExceptionMessage | flach | 2 | StRS-41, SyRS-140 |
+| 44 | Global/FileSystemDialog | flach | 2 | StRS-42, SyRS-140 |
+| 45 | Global/Help | flach | 2 | StRS-43, SyRS-140 |
+| 46 | Global/MSPLicensesCompare | mittel | 2 | StRS-44, SyRS-140 |
+| 47 | Global/NetworkDiagnostics | mittel | 2 | StRS-45, SyRS-140 |
+| 48 | Global/PerformanceTests | mittel | 2 | StRS-46, SyRS-140 |
+| 49 | Global/VideoPortal | mittel | 2 | StRS-47, SyRS-142 |
+| 50 | Gui | flach | 2 | StRS-48, SyRS-143 |
+| 51 | Gui/Profiles | tief | 3 | StRS-49, SyRS-143, SwRS-143 (HYPOTHESE) |
+| 52 | DataExchange | flach | 2 | StRS-50, SyRS-110 |
+| 53 | DataExchange/BookKeeping | tief | 3 | StRS-51, SyRS-111, SwRS-111 |
+| 54 | DataExchange/Connectors | mittel | 2 | StRS-52, SyRS-112 |
+| 55 | DataExchange/DataExport | mittel | 2 | StRS-53, SyRS-113 |
+| 56 | DataExchange/DataImport | tief | 3 | StRS-54, SyRS-114, SwRS-114 |
+| 57 | DataExchange/DatevOnline2020 | mittel | 2 | StRS-55, SyRS-115 |
+| 58 | DataExchange/DocSync | mittel | 2 | StRS-56, SyRS-116 |
+| 59 | DataExchange/DocuForm | tief | 3 | StRS-57, SyRS-117, SwRS-117 |
+| 60 | DataExchange/PaymentTransactions | tief | 3 | StRS-58, SyRS-118, SwRS-118 |
+| 61 | DataExchange/Rmm | mittel | 2 | StRS-59, SyRS-119 |
+| 62 | DataExchange/SupplierOrderPerBranch | mittel | 2 | StRS-60, SyRS-120 |
+| 63 | DataExchange/TelekomDive | mittel | 2 | StRS-61, SyRS-120 |
+| 64 | Administration/Cache | mittel | 2 | StRS-62, SyRS-144 |
+| 65 | Administration/CentronConfigDb | mittel | 2 | StRS-63, SyRS-145 |
+| 66 | Administration/Connections | mittel | 2 | StRS-64, SyRS-146 |
+| 67 | Administration/CountryManagement | mittel | 2 | StRS-65, SyRS-147 |
+| 68 | Administration/Customization | mittel | 2 | StRS-66, SyRS-141 (SwRS-141 s. Zeile 41) |
+| 69 | Administration/DSGVO | tief | 3 | StRS-67, SyRS-148, SwRS-148 |
+| 70 | Administration/EmployeeManagement | mittel | 2 | StRS-68, SyRS-149 |
+| 71 | Administration/EscalationsSettings | mittel | 2 | StRS-69, SyRS-150 |
+| 72 | Administration/ExternalTools | mittel | 2 | StRS-70, SyRS-151 |
+| 73 | Administration/HourlySurchargeRates | mittel | 2 | StRS-71, SyRS-152 |
+| 74 | Administration/LogViewer | mittel | 2 | StRS-72, SyRS-153 (HYPOTHESE) |
+| 75 | Administration/MailAndCalender | mittel | 2 | StRS-73, SyRS-154 |
+| 76 | Administration/MailTemplates | mittel | 2 | StRS-74, SyRS-155 |
+| 77 | Administration/MandatorManagement | tief | 3 | StRS-75, SyRS-156, SwRS-156 (HYPOTHESE) |
+| 78 | Administration/PdfExport | mittel | 2 | StRS-76, SyRS-157 |
+| 79 | Administration/PdfSigning | tief | 3 | StRS-77, SyRS-158, SwRS-158 |
+| 80 | Administration/PhoneSettings | mittel | 2 | StRS-78, SyRS-159 |
+| 81 | Administration/Profiling | mittel | 2 | StRS-79, SyRS-160 |
+| 82 | Administration/ReceiptConditions | mittel | 2 | StRS-80, SyRS-161 |
+| 83 | Administration/ReportServer | mittel | 2 | StRS-81, SyRS-162 |
+| 84 | Administration/RightsManagement | tief | 5 | StRS-82, SyRS-163, SwRS-163, SyRS-164 (HYPOTHESE), SwRS-164 (HYPOTHESE) |
+| 85 | Administration/SendDeliveryListShippingConfirmationSettings | mittel | 2 | StRS-83, SyRS-165 |
+| 86 | Administration/SepaContract | tief | 3 | StRS-84, SyRS-166, SwRS-166 |
+| 87 | Administration/ServiceAndLeasing | mittel | 2 | StRS-85, SyRS-167 |
+| 88 | Administration/Services | mittel | 2 | StRS-86, SyRS-168 |
+| 89 | Administration/Settings | mittel | 2 | StRS-87, SyRS-169 |
+| 90 | Administration/SqlManagers | mittel | 2 | StRS-88 (HYPOTHESE), SyRS-170 (HYPOTHESE) |
+| 91 | Administration/TaskManagmentSettings | mittel | 2 | StRS-89, SyRS-171 |
+| 92 | Administration/TextBlockManagement | mittel | 2 | StRS-90, SyRS-172 |
+| 93 | Administration/UpdateAvailableNotificationSettings | mittel | 2 | StRS-91, SyRS-173 |
+| 94 | Administration/WebCart | mittel | 2 | StRS-92, SyRS-174 |
+| 95 | Administration/WebServiceSettings | tief | 3 | StRS-93, SyRS-175, SyRS-191/SwRS-191 |
+| 96 | ArtificialIntelligence | tief | 3 | StRS-94, SyRS-176, SwRS-176 |
+| 97 | ArtificialIntelligence/OpenAIConnect | tief | 3 | StRS-95, SyRS-176, SwRS-176 |
+| 98 | Calendar | mittel | 2 | StRS-96, SyRS-177 |
+| 99 | Dashboard | mittel | 2 | StRS-97, SyRS-178 |
+| 100 | ExternalTool | mittel | 2 | StRS-98, SyRS-151 |
+| 101 | Helpdesk | tief | 3 | StRS-99, SyRS-179, SwRS-179 |
+| 102 | Massenupdates | tief | 3 | StRS-100, SyRS-180, SwRS-180 |
+| 103 | MyCentron | mittel | 2 | StRS-101, SyRS-181 |
+| 104 | OnlineBanking (UI) | tief | 3 | StRS-102, SyRS-182, SwRS-182 (HYPOTHESE) |
+| 105 | PasswordManager | tief | 3 | StRS-103, SyRS-183 (HYPOTHESE), SwRS-183 (HYPOTHESE) |
+| 106 | PayersAndCostCenter | mittel | 2 | StRS-104, SyRS-184 |
+| 107 | PLM | mittel | 2 | StRS-105, SyRS-185 |
+| 108 | ProjectPriceImport | mittel | 2 | StRS-106, SyRS-186 |
+| 109 | Statistics | mittel | 2 | StRS-107, SyRS-187 |
+| 110 | Survey | mittel | 2 | StRS-108, SyRS-188 |
+| 111 | TelekomDive (UI) | mittel | 2 | StRS-109, SyRS-120 |
+
+Zusätzlich: **StRS-110** (Legacy-Passwortverwaltung, `Centron.BL/PasswordManagementArea`) ist als Backend-Ergänzung ohne eigene UI-Zeile geführt und wird in Inventarzeile 165 (Abschnitt B) mitgezählt.
+
+### B. Technische/architektonische Komponenten
+
+| # | Komponente | Einstufung | Anzahl | Anforderungs-IDs |
+|---|---|---|---|---|
+| 112 | Centron.DAO | mittel | 1 | SyRS-189 |
+| 113 | Centron.Entities | mittel | 1 | SyRS-190 |
+| 114 | Centron.Gateway/Concerto | flach | 1 | SyRS-195 |
+| 115 | Centron.Gateway/Core | flach | 1 | SyRS-196 |
+| 116 | Centron.Gateway/DataExchange | mittel | 1 | SyRS-197 |
+| 117 | Centron.Gateway EDI-Konnektoren | mittel | 1 | SyRS-198 |
+| 118 | Centron.Gateway/Export+Import | flach | 1 | SyRS-199 |
+| 119 | Centron.Gateway/MspCollector | mittel | 1 | SyRS-200 |
+| 120 | Centron.Gateway/OnlineBanking | tief | 3 | (= StRS-102/SyRS-182/SwRS-182, siehe Zeile 104) |
+| 121 | Centron.Gateway/OpenTrans(+1.0) | mittel | 1 | SyRS-201 |
+| 122 | Centron.Gateway/Portal | mittel | 1 | SyRS-202 |
+| 123 | Centron.Gateway/ZUGFeRD21_Extended | mittel | 1 | SyRS-203 |
+| 124 | Centron.Controllers/Controllers | mittel | 1 | SyRS-192 |
+| 125 | Centron.Controllers/Authorization | tief | 2 | SyRS-191, SwRS-191 (HYPOTHESE) |
+| 126 | CentronNexus | mittel | 1 | SyRS-193 |
+| 127 | Centron.Core/Centron.Controls | flach | 1 | SyRS-194 |
+| 128 | Centron.BL/Security | tief | 3 | (= StRS-77/SyRS-158/SwRS-158, siehe Zeile 79) |
+| 129 | Centron.BL/TwoFactorAuthenticator | mittel | 1 | SyRS-204 |
+| 130 | Centron.BL/Mobile | mittel | 1 | SyRS-205 |
+| 131 | Centron.BL/Integrations | mittel | 1 | SyRS-206 |
+| 132 | Centron.BL/Telemetry | mittel | 1 | SyRS-207 |
+| 133 | Centron.BL/ReportEngine | tief | 3 | (= StRS-36/SyRS-139/SwRS-139, siehe Zeile 38) |
+| 134 | Centron.BL/Reporting | mittel | 1 | SyRS-208 |
+| 135 | Centron.BL/TaskManager | mittel | 1 | SyRS-209 |
+| 136 | Centron.BL/MassUpdate | mittel | 1 | SyRS-210 |
+| 137 | Centron.BL/Notifications | mittel | 1 | SyRS-211 |
+| 138 | Centron.BL/IndexSearch | mittel | 1 | SyRS-212 |
+| 139 | Centron.BL/ChangeTracking | mittel | 1 | SyRS-213 |
+| 140 | Centron.BL/SocialMedia | mittel | 1 | SyRS-214 |
+| 141 | Centron.BL/RiverDivo | mittel | 1 | SyRS-215 |
+| 142 | Centron.BL/TradePool | mittel | 1 | SyRS-216 |
+| 143 | Centron.BL/WebSuite | mittel | 1 | SyRS-217 |
+| 144 | Centron.BL/WebVersion | flach | 1 | SyRS-218 |
+| 145 | Centron.BL/Chats | mittel | 1 | SyRS-219 |
+| 146 | Centron.BL/DocuBoard | mittel | 1 | SyRS-220 |
+| 147 | Centron.BL/ItPlanner | mittel | 1 | SyRS-221 |
+| 148 | Centron.BL/MailScanner | mittel | 1 | SyRS-222 |
+| 149 | Centron.BL/Outlook | mittel | 1 | SyRS-223 |
+| 150 | Centron.BL/Tapi | mittel | 1 | SyRS-224 |
+| 151 | Centron.BL/CPra | mittel | 1 | SyRS-225 |
+| 152 | Centron.BL/SelfCare | mittel | 1 | SyRS-226 |
+| 153 | Centron.BL/BusinessPartner | mittel | 1 | SyRS-227 |
+| 154 | Centron.BL/CustomerArea | mittel | 1 | SyRS-228 |
+| 155 | Centron.BL/EmployeeArea | mittel | 1 | SyRS-229 |
+| 156 | Centron.BL/CountryArea | mittel | 1 | SyRS-230 |
+| 157 | Centron.BL/AppointmentRequests | mittel | 1 | SyRS-231 |
+| 158 | Centron.BL/Accounts | mittel | 1 | SyRS-232 |
+| 159 | Centron.BL/Accounting | tief | 1 | SyRS-233 |
+| 160 | Centron.BL/Buying | mittel | 1 | SyRS-234 |
+| 161 | Centron.BL/EDI | tief | 1 | SyRS-235 |
+| 162 | Centron.BL/Devices | mittel | 1 | SyRS-236 |
+| 163 | Centron.BL/ObjectExternalReferences | mittel | 1 | SyRS-237 |
+| 164 | Centron.BL/ExternalHelpdesk | mittel | 1 | SyRS-238 |
+| 165 | Centron.BL/PasswordManagementArea (Legacy) | tief | 1 | StRS-110 |
+
+## Konsistenzcheck
+
+Durchgeführt über den gesamten Anforderungsbestand: **110 StRS-Anforderungen** (StRS-1…StRS-110), **138 SyRS-Anforderungen** (SyRS-101…SyRS-238) und **28 SwRS-Anforderungen** (Teilmenge aus SwRS-101…SwRS-191), insgesamt **276 Anforderungen**.
+
+- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. Die Nummernkreise StRS-1…110, SyRS-101…238 und SwRS (Teilmenge der SyRS-Nummern) wurden fortlaufend und disjunkt vergeben; eine Prüfung auf doppelt verwendete IDs beim Zusammenstellen dieses Berichts ergab keine Kollision.
+- **Anforderungen ohne Beleg:** Keine. Jede der 276 Anforderungen führt mindestens einen klassifizierten Beleg (PRIMÄR/SEKUNDÄR/KONTEXT).
+- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine. Jede StRS- und SyRS-Anforderung mit fachlichem Bezug trägt eine Einstufung (übernehmen/Workaround/Sonderfall/veraltet) mit Kurzbegründung; rein technische SwRS-Detailanforderungen übernehmen konsistent die Einstufung ihrer StRS/SyRS-Basis.
+- **Tracelinks auf nicht existierende IDs:** Beim Zusammenstellen wurden zwei fehlerhafte Vorwärtsreferenzen identifiziert und korrigiert: StRS-65 verwies ursprünglich fälschlich auf „StRS-146" (existiert nicht; korrekt: SyRS-230) und StRS-61 auf „StRS-111" (existiert nicht; korrekt: StRS-109). Beide wurden vor Abgabe berichtigt. Eine abschließende Stichprobenprüfung der übrigen Konsolidierungs- und Tracelink-Verweise ergab keine weiteren offensichtlichen Fehlreferenzen; eine vollständige automatisierte Verifikation aller 276 Anforderungen gegen alle referenzierten IDs war im Rahmen dieses manuellen Laufs nicht möglich (siehe Selbstbewertung).
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Alle im Zuge der Analyse erkannten Fälle wurden markiert, u. a.: StRS-3/StRS-4 (Sonderartikel-Erfassung einzeln vs. Massenimport), StRS-8/StRS-9 (aktuelle vs. veraltete Vertragsauswertung), StRS-33/StRS-34 (RMA-Rücksendung/-Weiterversand als Prozesspaar, kein echter Konsolidierungsfall, da Teilschritte desselben Vorgangs), StRS-35/StRS-36 (Reports-Einstieg vs. -Engine), StRS-51/StRS-55 (BookKeeping-Export vs. DATEV-Online-Direktanbindung — zwei parallele Wege für denselben fachlichen Buchhaltungsexport), StRS-61/StRS-109/SyRS-120 (**echter Konsolidierungsfall**: zwei vollständig getrennte Implementierungen des Telekom-DIVE-Exports unter `Modules/DataExchange/TelekomDive` und `Modules/TelekomDive`), StRS-70/StRS-98 (ExternalTools-Konfiguration vs. -Vorschau), SyRS-208/StRS-36 (älteres `Centron.BL/Reporting` neben neuerer `ReportEngine`), StRS-65/SyRS-230 (Länderverwaltung UI vs. Backend `CountryArea`), SyRS-220 (Stammblatt/Asset-Doppelhaltung, siehe Glossar und Auftragsbeispiel). Eine erschöpfende paarweise Prüfung aller 276×275 möglichen Kombinationen wurde nicht durchgeführt; die Konsolidierungsprüfung erfolgte modulweise während der Erstellung (siehe Selbstbewertung zu Grenzen).
+
+### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
+
+| ID | Titel | PRIMÄR-Beleg vorhanden? | Status |
+|---|---|---|---|
+| StRS-6 | Automatisierte Vertragsabrechnung | Ja | belegt |
+| StRS-10 | Zentrale Vertragsverwaltung | Ja | belegt |
+| StRS-13 | Automatisiertes Mahnwesen | Ja | belegt |
+| StRS-16 | Offene-Posten-Lauf (OPOS) | Ja | belegt |
+| StRS-17 | Erfassung eingehender Zahlungen | **Nein** | **[HYPOTHESE] (H-12)** |
+| StRS-19 | Rechnungsfestschreibung nach GoBD | Ja | belegt |
+| StRS-20 | Abrechnung erfasster Arbeitszeiten | Ja | belegt |
+| StRS-23 | Freigabeworkflow für Reisekostenabrechnungen | Ja | belegt |
+| StRS-25 | Verbuchung ausgehender Zahlungen | Ja | belegt |
+| StRS-51 | Export/Import von Finanzbuchhaltungsdaten | Ja | belegt |
+| StRS-58 | Erstellung von SEPA-Zahlungsdateien | Ja | belegt |
+| StRS-64 | Verbindungsverwaltung inkl. Login und 2FA | Ja | belegt |
+| StRS-67 | Datenschutzkonforme Datenbereinigung (DSGVO) | Ja | belegt |
+| StRS-75 | Stammdatenverwaltung der Mandanten (Nummernkreise) | Ja | belegt |
+| StRS-77 | Digitale PDF-Signatur | Ja | belegt |
+| StRS-82 | Zentrale Vergabe/Verwaltung von Benutzerrechten | Ja | belegt |
+| StRS-84 | SEPA-Mandatsverträge inkl. Signatur | Ja | belegt |
+| StRS-88 | Direktes Ausführen von SQL-Abfragen | **Nein** | **[HYPOTHESE] (H-1)** |
+| StRS-102 | Automatisierter Abruf/Abgleich von Kontoauszügen | Ja | belegt |
+| StRS-103 | Verwaltung von Zugangsdaten/Passwort-Richtlinien | Ja | belegt |
+| StRS-105 | PLM-Modul (rechtegebunden) | Ja | belegt |
+| StRS-110 | Legacy-Passwortverwaltung ohne wirksame Verschlüsselung | Ja | belegt |
+| SyRS-125 | Rechtebasierte Sichtbarkeit von Kampagnenfunktionen | Nein | **[HYPOTHESE] (H-3)** |
+| SyRS-130 | Erzwungene Ziellagerplatzangabe | Nein (Durchsetzungsstelle unklar) | **[HYPOTHESE] (H-4)** |
+| SyRS-163 | Zentrale, wiederverwendete Rechteprüfung | Ja | belegt |
+| SyRS-164 | Filialbeschränkte Rechtevergabe | **Nein** | **[HYPOTHESE] (H-6)** |
+| SyRS-183 | Ausschluss eines vorhersagbaren Verschlüsselungs-Fallbacks | Ja (Fallback selbst PRIMÄR belegt, Erreichbarkeit unklar) | **[HYPOTHESE] (H-2)** |
+| SwRS-143 | Rechteattribut als Bearbeitungsvoraussetzung (UI-Profile) | Ja (clientseitig; serverseitig unklar) | **[HYPOTHESE] (H-7)** |
+| SwRS-156 | Sperrstrategie der Nummernkreisvergabe | Ja (Zugriff PRIMÄR belegt, Sperrstrategie unklar) | **[HYPOTHESE] (H-8)** |
+| SwRS-163 | Cache-Invalidierung bei Rechteentzug | Ja (Cache PRIMÄR belegt, Invalidierung unklar) | **[HYPOTHESE] (H-9)** |
+| SwRS-191 | IP-/Methodenbindung der Web-API-Authentifizierung | Ja (Validierung PRIMÄR belegt, Striktheit unklar) | **[HYPOTHESE] (H-11)** |
+
+Zehn der 30 gelisteten risikorelevanten Anforderungen sind als `[HYPOTHESE]` gekennzeichnet (StRS-17, StRS-88, SyRS-125, SyRS-130, SyRS-164, SyRS-183, SwRS-143, SwRS-156, SwRS-163, SwRS-191). SyRS-163 selbst ist belegt (PRIMÄR); es ist in der Tabelle aufgeführt, weil es zur selben RightsManagement-Anforderungsgruppe wie das unbelegte SyRS-164 gehört. Dies entspricht der Vorgabe, risikorelevante Anforderungen ohne PRIMÄR-Beleg zwingend als Hypothese zu kennzeichnen, statt sie unbelegt als „belegt" zu führen.
+
+### Abgleich Hypothesen.md gegen Inline-Markierungen
+
+Hypothesen.md enthält genau die zwölf Hypothesen-Gruppen (H-1 bis H-12), die zusammen alle 15 mit `Status: HYPOTHESE` markierten Anforderungs-IDs abdecken (2 in StRS.md, 6 in SyRS.md, 7 in SwRS.md — per Stichprobenzählung verifiziert), und keine zusätzlichen freien Fragen ohne zugehörige Anforderung. Der Abgleich wurde durch Gegenlesen aller drei Spezifikationsdokumente durchgeführt.
+
+## Selbstbewertung
+
+**Analysetiefe je Modul (165 Inventarzeilen):**
+- **tief** (StRS+SyRS+SwRS mit PRIMÄR-Beleg einer durchsetzenden Stelle): **26 Module** (u. a. AutomatedBilling, Contracts, Dunning, Opos, Receipts/GoBD, Purchasing/TravelExpense, Warehousing/Inventory+OutcomingPayments, ReportManagement, CustomProperties, Gui/Profiles, BookKeeping, DataImport/IBAN, DocuForm, PaymentTransactions/SEPA, DSGVO, MandatorManagement, PdfSigning, RightsManagement, SepaContract, ArtificialIntelligence(×2), Helpdesk, Massenupdates, OnlineBanking, PasswordManager, WebServiceSettings/Authorization, Accounting, EDI, PasswordManagementArea).
+- **mittel** (StRS+SyRS mit konkretem Klassen-/Methodenbeleg, überwiegend SEKUNDÄR): **117 Module**.
+- **flach** (nur rahmenhafte KONTEXT-Evidenz, meist Container-/Sammelordner): **8 Module** (Global, Global/Actions, Global/EmployeeSelection, Global/ExceptionMessage, Global/FileSystemDialog, Global/Help, Gui, DataExchange sowie technisch Centron.Gateway/Concerto, Centron.Gateway/Core, Centron.Gateway/Export+Import, Centron.Core/Centron.Controls, Centron.BL/WebVersion — insgesamt 12, da Zählung sowohl fachliche als auch technische Zeilen umfasst).
+- **nicht analysiert**: **4 Module** (Sales-Container, Finances-Container, Finances/ProductLifecycleManagement, Finances/Common) — jeweils mit Begründung „reiner Namensraum-Container ohne eigene Fachlogik" bzw. „rein technische Exporthilfsklasse".
+
+**Wurde die Mindestabdeckung erreicht?** Ja, mit der dokumentierten Ausnahme der vier „nicht analysiert"-Module, für die eine Begründung statt einer erzwungenen Anforderung geführt wird. Alle übrigen 161 Module besitzen mindestens eine Anforderung, in der Regel mindestens ein StRS/SyRS-Paar.
+
+**Wo war der Beleg dünn?** Ein hoher Anteil SEKUNDÄR-Belege (ViewModel-Strukturbeleg statt durchgesetzter Backend-Regel) findet sich in nahezu allen Administration-Settings-Modulen (reine Konfigurationsoberflächen ohne komplexe Geschäftsregel) sowie in den meisten `Global`-Hilfsdialogen. Dies ist fachlich plausibel: Diese Module bilden überwiegend Konfigurationsoberflächen ohne eigene Geschäftsregel ab, sodass ein „SEKUNDÄR"-Beleg (Konfigurationsschalter) die angemessene und keine unangemessen schwache Klassifikation ist. In zehn Fällen (siehe Hypothesenliste) reichte die verfügbare Evidenz nicht aus, um eine risikorelevante Aussage mit PRIMÄR-Beleg zu stützen; diese wurden konsequent als `[HYPOTHESE]` geführt statt spekulativ als „belegt" auszugeben — einschließlich eines Falls (StRS-17), der erst im abschließenden Konsistenzcheck als Verstoß gegen die risikobasierte Priorisierung erkannt und korrigiert wurde.
+
+**Warum wurde keine Hypothese ausgeschlossen?** Nicht zutreffend — es wurden zwölf Hypothesen-Gruppen mit insgesamt 15 als `[HYPOTHESE]` markierten Anforderungs-IDs geführt (siehe Hypothesen.md), was bei einer Codebasis dieser Größe (ca. 1.179 Entitätsklassen, 77.660 Zeilen SQL-Schema-Dump, ~90 Backend-Fachbereiche) plausibel und erwartbar ist.
+
+**Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?**
+1. **Konsolidierungsanalyse vertiefen:** Über die in diesem Lauf identifizierten Fälle hinaus (Stammblatt/Asset, Telekom-DIVE-Doppelimplementierung, BookKeeping-Export vs. DATEV-Online, Reporting vs. ReportEngine) legt die schiere Zahl paralleler Buchhaltungsexport-Implementierungen (`Centron.Gateway/DataExchange/BookKeeping` mit über zehn Zielsystem-Adaptern) eine systematische Bestandsaufnahme nahe, welche Adapter noch produktiv genutzt werden.
+2. **Sicherheitsrelevante Hypothesen klären:** Insbesondere H-2 (hartcodierter AES-Fallback-Schlüssel), H-6 (Filialbeschränkung der Rechtevergabe) und H-11 (IP-Bindung der Web-API-Tickets) sollten vor einer Web-/SaaS-Neuimplementierung vorrangig durch Entwicklerinterviews oder gezielte Penetrationstests geklärt werden, da sie unmittelbar sicherheitsrelevant sind.
+3. **Vertiefung der bisher nur „mittel" abgedeckten Abrechnungsrandbereiche:** FlatrateBilling (Saldenberechnung), ReceiptConditions (Skontoberechnung) und Accounting/BankAccount-Berichtigungslogik wurden nur mit SEKUNDÄR-Beleg erfasst und sollten für eine belastbare Migrationsbasis auf PRIMÄR-Ebene nachanalysiert werden.
+4. **DB-Schema-Abgleich:** Der vorliegende `SSMS_DB_SCHEMA.sql`-Dump (1.558 Tabellen, 1.346 Constraints) wurde in diesem Lauf nur punktuell (Nummernkreis, Sichtrus/Sichmemb) als KONTEXT/PRIMÄR-Beleg herangezogen; eine systematische Ableitung von SwRS-Datenanforderungen aus den CHECK- und FOREIGN-KEY-Constraints des Schemas wäre ein eigenständiger, lohnender Vertiefungsschritt.
+5. **Vollständige Tracelink-Verifikation:** Die in diesem Lauf gefundenen zwei Tracelink-Fehler (korrigiert) legen nahe, dass eine automatisierte Konsistenzprüfung (Skript, das alle referenzierten IDs gegen die tatsächlich vergebenen IDs abgleicht) für Folgeläufe sinnvoll ist, da eine rein manuelle Prüfung bei über 270 Anforderungen fehleranfällig bleibt.
+
+**Methodische Einschränkung dieses Laufs:** Die Analyse wurde primär durch parallele Recherche-Subagenten je Modulgruppe vorbereitet (Evidenzsammlung), die Formulierung der Anforderungen, Klassifikation und Konsistenzprüfung erfolgte durch den Hauptagenten. Dieses Vorgehen ermöglichte die in Schritt 0/0b geforderte Breite (165 Inventarzeilen, 276 Anforderungen) innerhalb eines einzelnen Laufs, geht aber zulasten einer erschöpfenden Tiefenprüfung jeder einzelnen Randbedingung — insbesondere bei den 117 „mittel" eingestuften Modulen wäre bei mehr verfügbarer Zeit eine Nachvertiefung auf PRIMÄR-Niveau wünschenswert.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Ergebnisse/Glossar.md

@@ -0,0 +1,35 @@
+# Glossar
+
+Domänenbegriffe, wie sie in den Anforderungen dieser Spezifikation verwendet werden. Technische Bezeichner (Klassen, Methoden, Tabellen) sind in ihrer Originalsprache belassen.
+
+| Begriff | Bedeutung im Kontext von c-entron ERP |
+|---|---|
+| **Mandant (Mandator)** | Rechtlich/organisatorisch eigenständige Firmeneinheit innerhalb einer c-entron-Installation (Tabelle/Entität `Mandator`), mit eigenen Filialen, Nummernkreisen und Stammdaten. Mehrere Mandanten können in derselben Datenbank verwaltet werden. |
+| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten (Niederlassung/Standort). |
+| **Beleg (Receipt)** | Sammelbegriff für kaufmännische Dokumente im System: Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung etc. Belegtypen werden über `ReceiptState`/`CentronObjectKindNumeric` unterschieden. |
+| **I3D** | Interner, technischer Primärschlüssel (Integer-ID), der in nahezu allen c-entron-Entitäten und Methodensignaturen als Objektidentifikator verwendet wird (z. B. `customerI3D`, `helpdeskI3D`). |
+| **Kunde/Account** | Kernstammdatenobjekt für Kunden und Lieferanten (Entität/BL-Namensraum `Account`/`AccountBL`), dient zugleich als Basis für CRM-Funktionen. |
+| **Stammblatt** | Historisch gewachsenes Datenobjekt zur Verwaltung von Hardware (u. a. Druckern) je Kunde, fachlich überlappend mit dem neueren Asset-Management-Konzept (`DocuBoard`/Asset-Zuordnungen). Konsolidierungskandidat für das Zielsystem (siehe Konsolidierungshinweise in den Anforderungen). |
+| **Asset** | Im Rahmen von DocuBoard/Asset-Management verwaltete Zuordnung von Artikeln/Geräten zu Kunden, technisch getrennt von der älteren Stammblatt-Verwaltung. |
+| **Vertrag (Contract)** | Wiederkehrend abzurechnende Kundenvereinbarung (Entität `Contract`), Basis für automatisierte Fakturierung; besitzt `ContractKind`, `DeductionIntervalKind`, `AutomaticExtensionFlag` und einen Beginn-/Ende-/Kündigungszeitpunkt. |
+| **RechKopf** | Interner Tabellenname für den Rechnungskopf (Invoice-Header); Grundlage der GoBD-Festschreibung (`IsFixed`). |
+| **GoBD-Festschreibung** | Nach den "Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern" unveränderbar gestellte Rechnung; im Code über `ReceiptInvoiceBL.FixInvoice`/`RechKopf.IsFixed` abgebildet. |
+| **OPOS (Offene Posten)** | Lauf zur Ermittlung/Bestätigung offener (nicht vollständig bezahlter) Rechnungsposten gegenüber Kunden (`OposBL`, `OposRunBL`). |
+| **Mahnlauf (Dunning)** | Automatisierter oder manueller Lauf zur Erhöhung der Mahnstufe (`DunningLevel`: None/Level1/Level2/Level3) überfälliger Rechnungen (`DunningRunBL.ExecuteDunningRun`). |
+| **ZUGFeRD / Factur-X** | Gesetzlich anerkanntes hybrides Format für elektronische Rechnungen (PDF mit eingebettetem strukturiertem XML nach UN/CEFACT `CrossIndustryInvoice`); in c-entron über `Centron.Gateway.ZUGFeRD21_Extended` und `ZUGFeRD_BL` umgesetzt (Profil "EXTENDED"). |
+| **SEPA-Mandat (SepaContract)** | Vom Kunden erteilte Einzugsermächtigung für Lastschriften; als eigene Entität mit Statusmaschine (`SepaContractState`) und optionaler Online-Signatur über Nexus-Portal oder Signotec (SBO) geführt; Export im Format `pain.008`. |
+| **DTA / ESR** | Zahlungsverkehrsformate (Datenträgeraustausch, Einzahlungsschein mit Referenznummer/Schweiz) für Beleg-Zahlungskonditionen. |
+| **EDI (Electronic Data Interchange)** | Elektronischer Geschäftsdokumentenaustausch mit Distributoren/Lieferanten (u. a. ALSO, Alltron, Komsa, Herweck, EGIS, Concerto, openTRANS) über distributorspezifische XML-/XSD-Formate. |
+| **AppRight / Recht (UserRight)** | Einzelnes, im Code über Konstanten (`UserRightsConst.*`) referenziertes Berechtigungsatom, das einer Gruppe zugewiesen und über `HasUserRight()` geprüft wird. |
+| **Gruppe (Sichtrus/Sichmemb)** | Datenbankseitiges Rechte-Gruppen-Modell: `Sichtrus` verknüpft Gruppen mit Rechten, `Sichmemb` verknüpft Benutzer mit Gruppen; Basis der Rechteprüfung in `AppRightsBL`. |
+| **AppUser / LoggedInUser** | Angemeldeter Benutzer (Mitarbeiter-Konto) im Kontext eines BL-Aufrufs; Träger von Rechten und Mandantenzuordnung. |
+| **Ticket (Helpdesk)** | Zentrale Vorgangseinheit des Helpdesk-Moduls; Status ist keine feste Enum, sondern mandantenspezifische Stammdaten (`HelpdeskStatusDTO`). |
+| **RMA (Return Merchandise Authorization)** | Retourenvorgang für Kundenrücksendungen/-ersatzlieferungen inkl. Rücksende- (SendBack) und Weiterversand- (SendForth) Prozessen. |
+| **MSP (Managed Service Provider)** | Abrechnungsmodell für IT-Dienstleistungskunden auf Basis periodisch gesammelter Nutzungsdaten (MspCollector, Octopus/Wortmann-Konnektoren). |
+| **BL / DAO / Entity (Schichtenarchitektur)** | Layered-Architecture-Muster des Backends: `ViewModel → ILogic → BLLogic/WSLogic → WebServiceBL → BL(Entity) → NHibernate → Datenbank`; jedes Modul implementiert i. d. R. sowohl eine `BL`- als auch eine `WS`-Variante der `ILogic`-Schnittstelle (direkter DB-Zugriff vs. Web-Service-Aufruf). |
+| **ClassContainer** | Zentraler Dependency-Injection-Mechanismus des WPF-Clients zur Auflösung von `ILogic`-Implementierungen abhängig vom Verbindungstyp (`CentronConnectionType`). |
+| **ChangeTracking** | Automatisches Änderungsprotokoll auf Entitätsebene (NHibernate-Event-Listener `ChangeTrackingEventListener`, Attribut `[TrackChanges]`), erfasst Alt-/Neuwert, Benutzer und Zeitstempel. |
+| **CentronNexus** | Blazor-basiertes Kunden-/Mitarbeiter-Selbstbedienungsportal (Web) für Vertragseinsicht, Webshop-Bestellung, Angebote, Ticket-Historie und Dokumentensignatur, getrennt vom WPF-Hauptclient. |
+| **Nummernkreis** | Fortlaufende Nummernvergabe für Belege/Verträge je Mandant, in der Datenbanktabelle `Nummernkreis` gepflegt. |
+| **Kostenträger/Kostenstelle** | Stammdatenobjekte zur betriebswirtschaftlichen Zuordnung von Kosten (Modul PayersAndCostCenter). |
+| **HasLicense / LicenseManager** | Laufzeit-Lizenzprüfung für optionale Zusatzmodule (z. B. Produktionsmanagement, CentronInternal-Hosting) auf Basis einer `LicenseGuids`-Konstante. |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Ergebnisse/Hypothesen.md

@@ -0,0 +1,22 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]` bzw. `Status: HYPOTHESE` markierten Anforderungen mit der jeweils offenen Frage, die zur Bestätigung fehlt. Diese Liste ist deckungsgleich mit den Inline-Markierungen in StRS.md, SyRS.md und SwRS.md (siehe Konsistenzcheck in Analysebericht.md). Offene Punkte ohne zugehörige Anforderung sind hier nicht aufgeführt; sie finden sich in der Selbstbewertung des Analyseberichts.
+
+| # | Anforderung(en) | Offene Frage | Was zur Bestätigung fehlt |
+|---|---|---|---|
+| H-1 | StRS-88, SyRS-170 | Existiert für den SQL-Manager (Administration/SqlManagers) eine über das allgemeine Administrationsrecht hinausgehende, eigene Berechtigungsstufe und eine Protokollierung der ausgeführten Statements? | Eine gezielte Suche nach einer dedizierten Rechtekonstante und einer Audit-Log-Tabelle für den SQL-Manager, die über die verfügbare Analyse hinausgeht (z. B. Laufzeittest mit Datenbank-Audit aktiviert). |
+| H-2 | SyRS-183, SwRS-183 | Ist der hartcodierte Fallback-Schlüssel `SECURITY_KEY = "lugE!35Djn"` in `AESCryptoLogic` in der Produktivkonfiguration tatsächlich erreichbar (d. h. gibt es Installationen ohne gesetzten Hotline-Masterkey), oder wird in der Praxis immer ein Masterkey injiziert? | Prüfung der Betriebsdokumentation/Installationsroutine, ob `CentronConfigurationDbBL.GetHotlineMasterKey()` in jeder unterstützten Installationsart einen Wert liefert, sowie ein Laufzeittest ohne konfigurierten Masterkey. |
+| H-3 | SyRS-125 | Gibt es neben der clientseitigen Sichtbarkeitssteuerung (`UserCanEditCampaign`/`UserCanOpenCampaign`) eine serverseitige Durchsetzung, die eine Kampagnenbearbeitung über einen direkten Backend-/API-Aufruf ohne Recht verhindert? | Quellcodesuche im Kampagnen-Backend (`Centron.BL`) nach einer serverseitigen Rechteprüfung analog zu `HasUserRight` sowie ein Testaufruf ohne UI. |
+| H-4 | SyRS-130 | An welcher konkreten Stelle im Kommissionierprozess wird `IsTargetStorageMandatory` tatsächlich durchgesetzt (Backend-Validierung vs. reine UI-Pflichtfeldmarkierung)? | Quellcodesuche nach der Backend-Methode, die eine Kommissionierbuchung ohne Ziellagerplatz ablehnt, sowie ein Testfall über einen direkten Backend-Aufruf. |
+| H-5 | SyRS-153 | Existiert ein im Code definierter, konkreter Zeitwert (SLA) für die Aktualität der Live-Log-Anzeige, oder handelt es sich um „so schnell wie technisch möglich" ohne festen Zielwert? | Prüfung der Implementierung des zugrundeliegenden Log-Streaming-Mechanismus (Polling-Intervall oder Push-Mechanismus) auf einen konfigurierten Wert. |
+| H-6 | SyRS-164, SwRS-164 | An welcher konkreten Backend-Methode wird die Einschränkung `MANAGE_RIGHTS_ONLY_OWN_BRANCH` bei der Rechtevergabe tatsächlich durchgesetzt (Filterung der angezeigten Benutzerliste vs. serverseitige Ablehnung bei direktem API-Aufruf)? | Quellcodesuche im Rechtevergabe-Backend nach Verwendung dieser Konstante außerhalb der reinen Definition sowie ein Testaufruf mit bekannter, filialfremder Benutzer-I3D. |
+| H-7 | SwRS-143 | Existiert neben der clientseitigen `EDIT_GLOBAL_PROFILES`-Prüfung in `ManageUiProfileViewModel` eine redundante serverseitige Prüfung beim tatsächlichen Speichern eines globalen Profils? | Quellcodesuche in der Backend-Speichermethode für UI-Profile nach einer eigenständigen Rechteprüfung sowie ein Testaufruf unter Umgehung des Clients. |
+| H-8 | SwRS-156 | Welche Sperrstrategie verhindert bei `MandatoryBL.SaveNumberGroups()` (direktes SQL-Update auf „Nummernkreis") eine doppelte Nummernvergabe bei gleichzeitigem Zugriff mehrerer Sitzungen? | Quellcodeanalyse der SQL-Anweisung auf Sperr-Hints (z. B. `UPDLOCK`/`HOLDLOCK`) sowie ein Lasttest mit parallelen Nummernvergaben. |
+| H-9 | SwRS-163 | Wie wird der in `AppRightsBL.HasUserRight` verwendete Rechte-Cache invalidiert, wenn einem angemeldeten Benutzer während einer laufenden Sitzung ein Recht entzogen wird? | Quellcodesuche nach der Cache-Invalidierungslogik (z. B. Event bei Rechteänderung) sowie ein Testfall: Recht während aktiver Sitzung entziehen und sofortige Wirkung prüfen. |
+| H-10 | SwRS-182 | Deckt die Textmustererkennung `Text.Contains("RUECK")` in `OnlineBankingConnectionLibfintx` alle in der Praxis vorkommenden Rückbuchungs-Buchungstexte der angebundenen Banken ab, oder werden abweichend formulierte Rückbuchungen fälschlich verworfen? | Auswertung realer Kontoauszugsdaten mit Rückbuchungen unterschiedlicher Banken/Formulierungen (z. B. SEPA-Rückbuchungscodes statt Freitext) gegen die Erkennungslogik. |
+| H-11 | SwRS-191 | Wird die in `AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod)` übergebene IP-Adresse tatsächlich zur Ablehnung eines von einer anderen IP-Adresse wiederverwendeten Tickets herangezogen, oder fließt sie nur in die Protokollierung ein? | Quellcodeanalyse von `AuthenticationTicketBL.GetAuthTicketInfo` auf eine tatsächliche IP-Vergleichsprüfung sowie ein Testaufruf mit gültigem Ticket von abweichender IP-Adresse. |
+| H-12 | StRS-17 | Existiert für die Erfassung eingehender Zahlungen (Finances/Payments) eine serverseitige, durchsetzende Prüfstelle, die ein Speichern mit inkonsistentem Zahlbetrag verhindert, analog zur verifizierten Prüfung bei ausgehenden Zahlungen (`OutgoingPaymentsViewModel.Save`, StRS-25)? Diese Anforderung ist als Abrechnungs-/Zahlungsvorgang risikorelevant und wurde beim Konsistenzcheck (Analysebericht) als Fall ohne PRIMÄR-Beleg identifiziert. | Quellcodesuche im Backend-Pfad der Zahlungserfassung (`Centron.BL/Finances/Payments` bzw. `Centron.BL/Finances/IncomingPayments`) nach einer Validierungsmethode analog zu `OutgoingPaymentsViewModel.Save`, sowie ein Testaufruf mit inkonsistentem Betrag über einen direkten Backend-Zugriff. |
+
+## Abgleich mit Inline-Markierungen
+
+Die zwölf Hypothesen-Gruppen (H-1 bis H-12) decken zusammen **15 einzelne Anforderungs-IDs** mit `Status: HYPOTHESE` ab (einige Gruppen betreffen dieselbe offene Frage auf zwei Spezifikationsebenen: H-1 → StRS-88, SyRS-170; H-2 → SyRS-183, SwRS-183; H-6 → SyRS-164, SwRS-164; alle übrigen Gruppen je eine ID). Eine Prüfung aller drei Dokumente ergab exakt 2 `Status: HYPOTHESE`-Markierungen in StRS.md, 6 in SyRS.md und 7 in SwRS.md (Summe 15), was vollständig mit obiger Tabelle übereinstimmt. Es gibt keine weiteren `[HYPOTHESE]`-Markierungen in den drei Spezifikationsdokumenten, die hier nicht aufgeführt sind, und keinen hier gelisteten Eintrag ohne entsprechende Markierung im Quelldokument.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Ergebnisse/SwRS.md

@@ -0,0 +1,582 @@
+# SwRS — Software Requirements Specification
+
+Komponenten, Datenmodelle und software-interne Regeln. Diese Ebene vertieft ausgewählte SyRS-Anforderungen aus risikorelevanten Bereichen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) auf Implementierungsebene mit konkreten Klassen, Methoden und Datenstrukturen. Nicht jede SyRS-Anforderung wird auf SwRS-Ebene vertieft — gemäß dem Grundsatz „Breite vor Tiefe" wurde die Vertiefung auf die im Auftrag genannten Risikobereiche fokussiert; die übrigen SyRS-Anforderungen sind für eine Web-/SaaS-Neuimplementierung bereits auf Systemebene hinreichend spezifiziert.
+
+## Bereich: Vertrags-/Rechnungs-Kernprozess
+
+```
+ID:            SwRS-101
+Titel:         Datenstruktur der Vertragsabschlussbedingung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente ContractBL
+Vorbedingung:  -
+Fakt:          ContractBL.CloseContract(DateTime? currentDate) liest die Entitätsfelder Contract.LastBookingTo, Contract.ContractTermination, Contract.ContractEnd und Contract.AutomatedProlongation (Contract.cs) und wertet sie in der beschriebenen Verzweigung aus, bevor ReceiptState.Completed gesetzt wird.
+Aussage:       Die Software soll die Felder LastBookingTo, ContractTermination, ContractEnd und AutomatedProlongation der Entität Contract als alleinige Datenbasis für die Abschlussentscheidung verwenden und keine abgeleiteten, redundant gehaltenen Statuswerte für diese Entscheidung heranziehen.
+Ergebnis:      Die Abschlussentscheidung ist ausschließlich aus den vier genannten Feldern reproduzierbar.
+Belege:
+  - [PRIMÄR] src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/Contract.cs::LastBookingTo, ContractTermination, ContractEnd, AutomatedProlongation - Begründung: Durchgesetzte Datenfelder, auf denen die Regel arbeitet.
+Prüfidee:      Unit-Test mit den vier Feldkombinationen (alle Wahrheitswertkombinationen der Bedingungen) gegen CloseContract ausführen.
+Tracelinks:    SyRS-101
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-102
+Titel:         Idempotente Rechnungserzeugung im Abrechnungslauf
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Komponente AutomaticFacturaBL
+Vorbedingung:  -
+Fakt:          AutomaticFacturaBL.SearchBillingOrders(...) muss vertragsbezogen den letzten Abrechnungszeitpunkt (LastBookingTo) fortschreiben, damit ein wiederholter Lauf denselben Vertrag nicht erneut selektiert.
+Aussage:       Die Software soll nach erfolgreicher Rechnungserzeugung LastBookingTo des Vertrags synchron mit der Rechnungserzeugung fortschreiben, sodass beide Operationen als eine atomare Einheit erscheinen.
+Ergebnis:      Ein wiederholter Lauf über denselben Zeitraum erzeugt keine zweite Rechnung für denselben Abrechnungszeitraum.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs::SearchBillingOrders(...) - Begründung: Enthält die Selektion, die auf LastBookingTo basiert.
+Prüfidee:      Abrechnungslauf zweimal ausführen und Ausbleiben einer zweiten Rechnung für denselben Zeitraum prüfen.
+Tracelinks:    SyRS-102
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-103
+Titel:         Mahnstufen-Enum und Laufnummerngenerierung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente DunningBL / DunningRunBL
+Vorbedingung:  -
+Fakt:          DunningLevel-Enum mit Werten None/Level1/Level2/Level3; DunningRunBL.GenerateNextDunningRunNumber() erzeugt eine fortlaufende, kollisionsfreie Laufnummer für jeden produktiven Mahnlauf.
+Aussage:       Die Software soll die Mahnstufe als geschlossene Aufzählung (Enum) mit genau vier Werten modellieren und die Mahnlaufnummer über eine zentrale, gegen Parallelzugriff abgesicherte Generierungsmethode vergeben.
+Ergebnis:      Es existieren keine zwei produktiven Mahnläufe mit identischer Laufnummer, auch bei gleichzeitiger Ausführung durch zwei Sachbearbeiter.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs::GenerateNextDunningRunNumber() - Begründung: Durchsetzende Nummerngenerierung.
+Prüfidee:      Zwei Mahnläufe nahezu gleichzeitig aus unterschiedlichen Sitzungen starten und Eindeutigkeit der Laufnummern prüfen.
+Tracelinks:    SyRS-103
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-106
+Titel:         Wiederverwendbares Rechteprüfungsmuster für Finanzläufe
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponenten OposBL, DunningBL
+Vorbedingung:  -
+Fakt:          Sowohl OposBL als auch DunningBL implementieren eine gleichnamige Methode ThrowIfUserHasInsufficentRights(LoggedInUser) mit identischem Aufrufmuster (Exception bei fehlendem Recht).
+Aussage:       Die Software soll das Prüfungsmuster ThrowIfUserHasInsufficentRights als konsistent benanntes, wiederverwendbares Muster für alle finanzkritischen Sammelläufe verwenden, damit neue Läufe (z. B. künftige Batch-Prozesse) dieselbe Absicherung ohne Neuimplementierung übernehmen können.
+Ergebnis:      Jeder neue finanzkritische Sammellauf kann dasselbe geprüfte Muster wiederverwenden, statt eine eigene, potenziell abweichende Rechteprüfung zu implementieren.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs::ThrowIfUserHasInsufficentRights - Begründung: Zeigt das wiederverwendete Muster.
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs::ThrowIfUserHasInsufficentRights - Begründung: Zweite, identisch benannte Implementierung desselben Musters.
+Prüfidee:      Code-Review beider Implementierungen auf identisches Verhalten (Exception-Typ, Bedingung) prüfen.
+Tracelinks:    SyRS-106
+Konsolidierung: Kandidat: beide Implementierungen sollten im Zielsystem auf eine gemeinsame Basisklasse/Methode zusammengeführt werden.
+Übernahmewürdigkeit: übernehmen, Implementierung im Zielsystem konsolidieren.
+Status:        belegt
+```
+
+```
+ID:            SwRS-108
+Titel:         Sperrflag und Protokollstruktur der Rechnungsfestschreibung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente ReceiptInvoiceBL
+Vorbedingung:  -
+Fakt:          FixInvoice(AppUser, int invoiceI3D) setzt das Feld RechKopf.IsFixed auf 1 und erzeugt einen Protokolltext "Die Rechnung wurde am {0} von {1} festgeschrieben." mit Zeitstempel und Benutzername; CancelInvoice(int invoiceI3D, ...) ist der einzige Codepfad, der eine Rechnung mit IsFixed=1 fachlich stornieren darf.
+Aussage:       Die Software soll IsFixed als unveränderliches Sperrflag modellieren, das nach dem Setzen durch keinen anderen Codepfad als CancelInvoice zurückgesetzt oder umgangen werden kann, und den Festschreibungstext mit vollständigem Zeitstempel und Benutzerreferenz persistieren.
+Ergebnis:      Es existiert kein Codepfad im System, der IsFixed direkt (ohne Stornierung) zurücksetzt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs::FixInvoice(AppUser, int invoiceI3D) - Begründung: Durchsetzende Sperrlogik.
+Prüfidee:      Codebasis auf weitere Schreibzugriffe auf RechKopf.IsFixed außerhalb von FixInvoice/CancelInvoice durchsuchen (statische Analyse) und Ausschluss prüfen.
+Tracelinks:    SyRS-108
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## Bereich: DataExchange (Software-Detailanforderungen)
+
+```
+ID:            SwRS-111
+Titel:         Bestätigungspflichtiger Warndialog vor Massenrechnungsabschluss
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente BookKeepingExportViewModel
+Vorbedingung:  -
+Fakt:          DoImport prüft die Anzahl gefundener offener Posten in der Importdatei; bei null Treffern wird ein modaler Bestätigungsdialog mit dem Warntext angezeigt, dessen Bestätigung Voraussetzung für die Fortsetzung ist.
+Aussage:       Die Software soll den Fortsetzungspfad des Imports softwareseitig so strukturieren, dass die Methode zum automatischen Rechnungsabschluss nur nach einem positiven Rückgabewert des Bestätigungsdialogs aufgerufen werden kann.
+Ergebnis:      Es existiert kein Codepfad, der den automatischen Massenabschluss ohne vorherige Dialogbestätigung auslöst.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping/BookKeepingExportViewModel.cs::DoImport - Begründung: Durchsetzende Ablaufsteuerung.
+Prüfidee:      Dialog per Code-Review auf zwingende Verzweigung vor Aufruf der Abschlussmethode prüfen.
+Tracelinks:    SyRS-111
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-114
+Titel:         IBAN-Prüfziffernalgorithmus
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente IbanValidation
+Vorbedingung:  -
+Fakt:          IbanValidation.cs implementiert die Prüfziffernberechnung (Modulo-97-Verfahren gemäß ISO 7064) zur Validierung importierter IBANs vor Übernahme in BankAccountViewModel.
+Aussage:       Die Software soll die IBAN-Prüfziffer nach dem international standardisierten Modulo-97-Verfahren berechnen und bei Abweichung den Datensatz mit einer für den Importbericht auswertbaren Fehlermeldung zurückweisen.
+Ergebnis:      Jede formal ungültige IBAN wird mit einer eindeutigen, im Importbericht sichtbaren Fehlermeldung zurückgewiesen.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport/AccountImport/IbanValidation.cs - Begründung: Durchsetzende Implementierung des Prüfziffernalgorithmus.
+Prüfidee:      IBAN mit bekannt falscher Prüfziffer (Testvektor) validieren und korrekte Ablehnung prüfen.
+Tracelinks:    SyRS-114
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-117
+Titel:         Tokenerneuerung für die DocuForm-API
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente DocuFormTokenHelper
+Vorbedingung:  Ein DocuForm-API-Aufruf steht bevor.
+Fakt:          DocuFormTokenHelper kapselt Beschaffung und Prüfung des Zugriffstokens vor jedem API-Aufruf.
+Aussage:       Die Software soll ein abgelaufenes DocuForm-Token vor dem nächsten API-Aufruf automatisch erneuern und den Aufruf erst nach erfolgreicher Erneuerung ausführen; schlägt die Erneuerung fehl, muss der Aufruf mit einer eindeutigen Fehlermeldung abbrechen statt mit einem ungültigen Token fortzufahren.
+Ergebnis:      Es wird kein DocuForm-API-Aufruf mit einem bekanntermaßen abgelaufenen Token ausgeführt.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization/DocuFormTokenHelper.cs - Begründung: Durchsetzende Tokenverwaltung.
+Prüfidee:      API-Aufruf mit künstlich abgelaufenem Token auslösen und automatische Erneuerung bzw. saubere Fehlermeldung prüfen.
+Tracelinks:    SyRS-117
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-118
+Titel:         Konfigurationsgetriebene Betragsprüfung im SEPA-Export
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente PaymentTransactionBL
+Vorbedingung:  -
+Fakt:          ExportInvoices(...) liest AppSettingsConst.PaymentTransactionIncomingPaymentMaximumAmount (Konstantenwert 1125, Zeile 1456 in AppSettingsConst.cs) über AppSettingsGroupBL.GetDecimal() vor jeder Betragsprüfung neu ein, statt einen zwischengespeicherten Wert zu verwenden.
+Aussage:       Die Software soll den konfigurierten Höchstbetrag bei jedem Exportlauf aktuell aus der Konfiguration lesen, sodass eine administrative Änderung des Höchstbetrags ohne Neustart des Dienstes wirksam wird.
+Ergebnis:      Eine Änderung des Höchstbetrags wirkt sich auf den nächsten Exportlauf aus, auch ohne Neustart des Webservice.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsGroupBL.cs::GetDecimal(AppSettingsConst.PaymentTransactionIncomingPaymentMaximumAmount) - Begründung: Durchsetzender, nicht gecachter Konfigurationszugriff.
+Prüfidee:      Höchstbetrag zur Laufzeit ändern und Wirksamkeit im unmittelbar folgenden Exportlauf ohne Neustart prüfen.
+Tracelinks:    SyRS-118
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## Bereich: Purchasing / Warehousing (Software-Detailanforderungen)
+
+```
+ID:            SwRS-131
+Titel:         SQL-basierte Bedarfsermittlung der Bestellvorschlagsliste
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente OrderSuggestionListBL
+Vorbedingung:  -
+Fakt:          Die interne SQL-Abfrage _sqlArticle (OrderSuggestionListBL.cs, ab Zeile 87) verknüpft Artikelstamm, Lagerbestand, offene Bestellpositionen und Sonderabreden in einer einzigen Abfrage.
+Aussage:       Die Software soll die Bedarfsermittlung als eine einzige, konsistente Datenbankabfrage ausführen, statt die Teilergebnisse (Bestand, offene Bestellungen, Sonderabreden) in getrennten Abfragen zu ermitteln und im Anwendungscode zusammenzuführen, um Race Conditions zwischen den Teilabfragen auszuschließen.
+Ergebnis:      Das Berechnungsergebnis basiert auf einem konsistenten Datenstand zu einem Zeitpunkt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs::_sqlArticle (ab Zeile 87) - Begründung: Durchgesetzte, konsistente Einzelabfrage.
+Prüfidee:      Bestellvorschlag während gleichzeitiger Bestandsänderung berechnen und Konsistenz des Ergebnisses (kein „halb aktueller" Zwischenstand) prüfen.
+Tracelinks:    SyRS-131
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-132
+Titel:         Statusübergangs-Enum und gekoppelte Belegerzeugung bei Reisekosten
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente TransactionDetailViewModel / TransactionDetailStatus
+Vorbedingung:  -
+Fakt:          TransactionDetailStatus (src/webservice/Centron.WebServices.Core/Entities/Transactions/TransactionDetailStatus.cs) definiert die zulässigen Statuswerte (u. a. Open, Approved, Canceled); Approve() prüft vor dem Statusübergang die Kreditorenzuordnung des Mitarbeiters und ruft erst danach IReceiptLogic.CreateNewReceipt auf.
+Aussage:       Die Software soll den Statusübergang Open→Approved und den Aufruf von CreateNewReceipt als eine Sequenz implementieren, bei der ein Fehler in der Belegerzeugung den Statusübergang nicht bereits vollzogen haben darf (kein „Approved ohne Beleg").
+Ergebnis:      Es existiert kein Datensatz mit Status Approved, dem kein Lieferantenrechnungs-Beleg zugeordnet ist (bei vorhandenem Kreditor).
+Belege:
+  - [PRIMÄR] src/webservice/Centron.WebServices.Core/Entities/Transactions/TransactionDetailStatus.cs - Begründung: Durchgesetzte Statuswertemenge.
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/ViewModels/TransactionDetailViewModel.cs::Approve() - Begründung: Durchsetzende Sequenzsteuerung.
+Prüfidee:      Belegerzeugung künstlich fehlschlagen lassen und Prüfen, dass der Status nicht auf Approved verbleibt.
+Tracelinks:    SyRS-132
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-133
+Titel:         ResponseKind-Klassifikation der Inventurprüfung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente InventoryNewBL
+Vorbedingung:  -
+Fakt:          CheckInventory(...) gibt einen ResponseKind mit den Werten Ok, MultiBarcode, NeedCheckArtic, NewBarcode zurück; nur bei Ok erfolgt SaveInventoryArticle.
+Aussage:       Die Software soll ResponseKind als geschlossene Aufzählung mit den vier genannten Werten modellieren und SaveInventoryArticle ausschließlich beim Rückgabewert Ok aufrufen.
+Ergebnis:      Es existiert kein Codepfad, der SaveInventoryArticle bei einem anderen ResponseKind als Ok aufruft.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs::CheckInventory(...) - Begründung: Durchgesetzte Enum-Auswertung vor Speicherung.
+Prüfidee:      Code-Review: Alle Aufrufstellen von SaveInventoryArticle auf vorgeschaltete Ok-Prüfung untersuchen.
+Tracelinks:    SyRS-133
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-134
+Titel:         Betragsdifferenzberechnung als Speichervoraussetzung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente OutgoingPaymentsViewModel
+Vorbedingung:  -
+Fakt:          SetAmountDifference() berechnet AmountDifference = Amount - ReceiptPositions.Sum(f => f.Amount); Save() prüft AmountDifference == 0 als Vorbedingung für die Persistierung.
+Aussage:       Die Software soll AmountDifference bei jeder Änderung von Amount oder ReceiptPositions neu berechnen und Save() so implementieren, dass eine Persistierung bei AmountDifference ≠ 0 technisch nicht möglich ist (nicht nur durch eine UI-Warnung verhindert wird).
+Ergebnis:      Es existiert kein Codepfad, der einen OutgoingPayment-Datensatz mit AmountDifference ≠ 0 persistiert.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs::Save()/SetAmountDifference() - Begründung: Durchsetzende Berechnung und Speichervoraussetzung.
+Prüfidee:      Direkten Speicherversuch (unter Umgehung der UI-Warnung, z. B. per Unit-Test des ViewModels) mit AmountDifference ≠ 0 durchführen und Ablehnung prüfen.
+Tracelinks:    SyRS-134
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## Bereich: Global / Gui (Software-Detailanforderungen)
+
+```
+ID:            SwRS-139
+Titel:         Parametrisierte Abfrageausführung der Report-Engine
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente ReportDataQueryBL
+Vorbedingung:  -
+Fakt:          ReportDataQueryBL nutzt SqlClient/NamedQueries für die Reportdatenbindung, angesteuert über FastReport.Report.
+Aussage:       Die Software soll Berichtsabfragen ausschließlich über parametrisierte NamedQueries ausführen, um SQL-Injection über Berichtsfilterparameter auszuschließen.
+Ergebnis:      Kein Berichtsfilterwert wird ungeprüft in einen SQL-Text eingefügt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ReportEngine/ReportDataBL.cs - Begründung: Durchsetzende Verwendung von NamedQueries/SqlClient.
+Prüfidee:      Berichtsfilter mit einem SQL-Metazeichen (z. B. Apostroph) befüllen und korrektes, injektionssicheres Verhalten prüfen.
+Tracelinks:    SyRS-139
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-141
+Titel:         Unbound-Column-Binding für benutzerdefinierte Zusatzfelder
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente CustomPropertiesOverviewGridManager
+Vorbedingung:  -
+Fakt:          GridControl_OnCustomUnboundColumnData bindet dynamisch definierte Zusatzfelder als DevExpress-UnboundColumn zur Laufzeit, ohne dass die zugrundeliegende Entität statisch um das Feld erweitert werden muss.
+Aussage:       Die Software soll ein neu definiertes Zusatzfeld als Unbound Column zur Laufzeit an die GridControl binden, ohne dass eine Neukompilierung oder ein Anwendungsneustart erforderlich ist.
+Ergebnis:      Ein neues Zusatzfeld ist ohne Deployment-Vorgang in den betroffenen Grid-Ansichten nutzbar.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Administration/Customization/CustomPropertiesOverviewGridManager.cs::GridControl_OnCustomUnboundColumnData - Begründung: Durchsetzende Laufzeitbindung.
+Prüfidee:      Zusatzfeld ohne Neustart der Anwendung anlegen und sofortige Verfügbarkeit im Grid prüfen.
+Tracelinks:    SyRS-141
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-143
+Titel:         Rechteattribut als Bearbeitungsvoraussetzung für globale UI-Profile
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente ManageUiProfileViewModel
+Vorbedingung:  -
+Fakt:          ManageUiProfileViewModel prüft UserRightsConst.Administration.EDIT_GLOBAL_PROFILES als Vorbedingung, bevor Speicherbefehle für ein öffentliches Profil (IsPublic=true) ausführbar werden.
+Aussage:       Die Software soll den Speicherbefehl für ein Profil mit IsPublic=true nur dann als ausführbar (CanExecute) markieren, wenn der aktuelle Benutzer EDIT_GLOBAL_PROFILES besitzt, und dies zusätzlich serverseitig beim Speichern erneut prüfen.
+Ergebnis:      Ein manipulierter Client (deaktivierte CanExecute-Prüfung) kann kein globales Profil speichern, da die serverseitige Prüfung greift.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Gui/Profiles/ManageUiProfileViewModel.cs::EDIT_GLOBAL_PROFILES - Begründung: Durchsetzende Rechteprüfung; ob eine redundante serverseitige Prüfung existiert, wurde nicht bis auf Backend-Methodenebene verifiziert (siehe Hypothese H-7).
+Prüfidee:      Direkten Backend-Aufruf zum Speichern eines globalen Profils mit nicht berechtigtem Benutzer unter Umgehung des Clients durchführen und Ablehnung prüfen.
+Tracelinks:    SyRS-143
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE
+```
+
+## Bereich: Administration (Software-Detailanforderungen)
+
+```
+ID:            SwRS-148
+Titel:         Feature- und Rechtekombination als DSGVO-Löschvoraussetzung
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente DataSecurityBL
+Vorbedingung:  -
+Fakt:          DataSecurityExecuteCleanUp prüft die UND-Verknüpfung aus currentUser.HasUserRight(UserRightsConst.DsgvoModule.ACCESS_CLEANUP_DATABASE) und ModuleFeatures.IsDsgvoDatabaseCleanupAvailable, bevor die Löschoperation eingeleitet wird; als Löschkennzeichnung wird die Konstante "DSGVO: Auf Anfrage gelöscht." verwendet.
+Aussage:       Die Software soll die DSGVO-Löschung als zweifach abgesicherte Operation implementieren (Benutzerrecht UND Feature-Verfügbarkeit) und jeden gelöschten Kontakt mit der standardisierten Löschkennzeichnung versehen, statt den Datensatz physisch zu entfernen.
+Ergebnis:      Ein gelöschter Kontakt ist anhand der Kennzeichnung von einem regulär gepflegten Datensatz unterscheidbar; die Löschung erfolgt nie bei fehlendem Feature, auch wenn das Recht vorhanden ist.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs::DataSecurityExecuteCleanUp - Begründung: Durchsetzende Zweifachprüfung.
+Prüfidee:      Löschung mit vorhandenem Recht, aber deaktiviertem Feature versuchen und Ablehnung prüfen.
+Tracelinks:    SyRS-148
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-156
+Titel:         Direkte SQL-Aktualisierung der Nummernkreis-Tabelle
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente MandatoryBL
+Vorbedingung:  -
+Fakt:          SaveNumberGroups() führt ein direktes SQL-Update auf die Tabelle "Nummernkreis" aus, statt über die generische NHibernate-DAO-Schicht (GenericDAO) zu persistieren.
+Aussage:       Die Software soll die Nummernkreis-Aktualisierung so implementieren, dass sie transaktional gegen gleichzeitige Nummernvergabe abgesichert ist (z. B. über eine geeignete Sperrstrategie), unabhängig davon, ob der Zugriff über Direkt-SQL oder die ORM-Schicht erfolgt.
+Ergebnis:      Zwei gleichzeitige Nummernvergaben führen nicht zu einer doppelt vergebenen Nummer.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs::SaveNumberGroups() - Begründung: Durchsetzender, aber am generischen DAO-Muster vorbeigehender Zugriffspfad (siehe Hypothese H-8 zur Sperrstrategie).
+Prüfidee:      Zwei parallele Nummernvergaben simulieren (Lasttest) und Eindeutigkeit der vergebenen Nummern prüfen.
+Tracelinks:    SyRS-156
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen, Migration auf die generische DAO-Schicht im Zielsystem empfohlen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-158
+Titel:         PKCS#7/SHA-256-Signaturkette mit optionalem TSA-Zeitstempel
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente PdfSigningBL
+Vorbedingung:  -
+Fakt:          SignPdfDocument instanziiert Pkcs12CertificateLoader (Zertifikatsladen), Pkcs7Signer (SHA-256-Signatur) und optional TsaClient (Zeitstempel-Server); die Kombination wird über PdfSignatureBuilder an DevExpress PdfSigner.SaveDocument übergeben.
+Aussage:       Die Software soll die Signaturkette Pkcs12CertificateLoader → Pkcs7Signer(SHA-256) → optional TsaClient als feste, nicht durch Konfiguration schwächbare Verarbeitungskette implementieren.
+Ergebnis:      Es ist nicht möglich, ein Dokument mit einem schwächeren Hash-Algorithmus als SHA-256 zu signieren, ohne den Code zu ändern.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs::SignPdfDocument(byte[] pdfDocument) - Begründung: Durchgesetzte, im Code fest verdrahtete Algorithmuskette.
+Prüfidee:      Code-Review: Prüfen, dass HashAlgorithmType.SHA256 nicht über eine Konfigurationseinstellung veränderbar ist.
+Tracelinks:    SyRS-158
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-163
+Titel:         Gecachte, SQL-basierte Rechteauflösung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente AppRightsBL
+Vorbedingung:  -
+Fakt:          AppRightsBL.HasUserRight(int appUserI3D, int rightID) nutzt einen Cache (GetOrAdd) für GetAllAppRightsFromUser, das intern die SQL-Abfrage `SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D` ausführt.
+Aussage:       Die Software soll die Rechteliste eines Benutzers cachen, den Cache jedoch bei jeder Änderung der Gruppenzugehörigkeit oder Rechtevergabe dieses Benutzers unmittelbar invalidieren, sodass eine soeben entzogene Berechtigung nicht bis zum nächsten Cache-Timeout wirksam bleibt.
+Ergebnis:      Ein Benutzer, dem ein Recht soeben entzogen wurde, kann die zugehörige Aktion nicht mehr ausführen, auch nicht innerhalb der bestehenden Sitzung.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs::HasUserRight(int appUserI3D, int rightID) - Begründung: Durchsetzende, gecachte Implementierung; die konkrete Invalidierungsstrategie bei Rechteentzug während einer laufenden Sitzung wurde im Rahmen dieser Analyse nicht bis auf Methodenebene verifiziert (siehe Hypothese H-9).
+Prüfidee:      Benutzer anmelden, Recht während laufender Sitzung entziehen und sofortige Wirksamkeit (keine verzögerte Sperre) prüfen.
+Tracelinks:    SyRS-163
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-164
+Titel:         Filialfilter in der Rechtevergabe-Abfrage
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente Rechtevergabe (RightsManagement-Backend)
+Vorbedingung:  MANAGE_RIGHTS_ONLY_OWN_BRANCH ist für den Administrator gesetzt.
+Fakt:          Die Konstante UserRightsConst.Administration.UserRightsManagement.MANAGE_RIGHTS_ONLY_OWN_BRANCH ist definiert; die konkrete Filterlogik in der Rechtevergabe-Abfrage (welche Benutzerliste dem eingeschränkten Administrator angezeigt wird) wurde im Rahmen dieser Analyse nicht bis auf Methodenebene lokalisiert.
+Aussage:       Die Software soll die Benutzerliste, die einem filialbeschränkten Administrator zur Rechtevergabe angeboten wird, serverseitig auf Benutzer der eigenen Filiale filtern, nicht nur clientseitig ausblenden.
+Ergebnis:      Ein filialbeschränkter Administrator kann über keinen Aufrufweg (auch nicht per direktem API-Aufruf mit bekannter Benutzer-I3D) Rechte an einen filialfremden Benutzer vergeben.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights - Begründung: Konstante belegt die vorgesehene Einschränkung (siehe Hypothese H-6); die serverseitige Durchsetzungsstelle war im Rahmen dieser Analyse nicht auffindbar.
+Prüfidee:      Rechtevergabe an eine bekannte, filialfremde Benutzer-I3D per direktem Backend-/API-Aufruf versuchen und Ablehnung prüfen.
+Tracelinks:    SyRS-164
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-166
+Titel:         SEPA-Mandatsdatenstruktur nach pain.008
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente pain_008_001_02_GBIC_3
+Vorbedingung:  -
+Fakt:          pain_008_001_02_GBIC_3.cs definiert MandateRelatedInformationSDD und AccountIdentificationSEPAMandate als Datenklassen für den SEPA-Lastschrift-Export im Format pain.008.
+Aussage:       Die Software soll jedes SEPA-Mandat beim Export vollständig auf die Felder von MandateRelatedInformationSDD (Mandatsreferenz, Unterschriftsdatum) und AccountIdentificationSEPAMandate (IBAN/BIC) abbilden, ohne Pflichtfelder der pain.008-Spezifikation auszulassen.
+Ergebnis:      Eine exportierte SEPA-Datei besteht die pain.008-Schemavalidierung.
+Belege:
+  - [PRIMÄR] src/backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/pain_008_001_02_GBIC_3.cs::MandateRelatedInformationSDD, AccountIdentificationSEPAMandate - Begründung: Durchgesetzte Zielstruktur des Exports.
+Prüfidee:      SEPA-Export erzeugen und gegen das offizielle pain.008-XSD-Schema validieren.
+Tracelinks:    SyRS-166
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## Bereich: KI / Helpdesk / Massenupdates / Sicherheit (Software-Detailanforderungen)
+
+```
+ID:            SwRS-176
+Titel:         Explizite Werkzeugkonstanten als einzige KI-Schnittstelle zu Fachdaten
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente TicketDetailView.ArtificialIntelligence
+Vorbedingung:  -
+Fakt:          Die Tool-Konstanten ticket_get_state, ticket_update_fields, ticket_select_tab, ticket_execute_action, ticket_save sind die einzigen im Interface IArtificialIntelligenceInteractiveModule definierten Zugriffspunkte für die KI auf das Ticketmodul.
+Aussage:       Die Software soll der KI ausschließlich über diese fest benannten Werkzeugkonstanten Zugriff gewähren; jede Erweiterung des KI-Funktionsumfangs auf ein Fachmodul muss über eine neue, explizit benannte Konstante erfolgen, nicht über generischen Feld- oder Reflection-Zugriff.
+Ergebnis:      Es existiert kein Weg, über den die KI auf ein Ticketfeld zugreifen kann, das nicht durch eine der fünf Konstanten abgedeckt ist.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailView.ArtificialIntelligence.cs - Begründung: Durchsetzende, geschlossene Werkzeugmenge.
+Prüfidee:      Code-Review: Prüfen, dass IArtificialIntelligenceInteractiveModule keinen generischen Reflection-basierten Zugriffspfad neben den fünf Konstanten bereitstellt.
+Tracelinks:    SyRS-176
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-179
+Titel:         CanHelpdeskClose als zwingende Vorbedingung des Abschlusspfads
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Komponente CloseHelpdeskHelper / ITicketLogic
+Vorbedingung:  -
+Fakt:          CloseHelpdesk(int helpdeskI3D, bool ignoreConnectedHelpdesks) ruft ITicketLogic.CanHelpdeskClose(helpdesk.I3D) auf; das Ergebnisobjekt canClose.CanClose steuert den weiteren Ablauf, canClose enthält zusätzlich die Liste nonCalculatedTimers.
+Aussage:       Die Software soll den eigentlichen Abschluss-Persistenzaufruf so implementieren, dass er nur erreichbar ist, wenn CanHelpdeskClose zuvor CanClose=true zurückgegeben hat (kein alternativer Codepfad zum direkten Setzen des Abschlussstatus).
+Ergebnis:      Es existiert kein Codepfad, der ein Ticket ohne vorherigen CanHelpdeskClose-Aufruf abschließt.
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CloseHelpdesk/CloseHelpdeskHelper.cs::CloseHelpdesk(int helpdeskI3D, bool ignoreConnectedHelpdesks) - Begründung: Durchsetzende Ablaufkontrolle.
+Prüfidee:      Code-Review: Alle Aufrufstellen, die den Ticketstatus auf „geschlossen" setzen, auf vorgeschalteten CanHelpdeskClose-Aufruf prüfen.
+Tracelinks:    SyRS-179
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-180
+Titel:         Getrennte Berechnungs- und Anwendungsphase bei Massenänderungen
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Komponente UpdatePreviewViewModel / MassUpdateBL
+Vorbedingung:  -
+Fakt:          UpdatePreviewViewModel berechnet die Vorschau-Werte, bevor MassUpdateBL.StartReceiptPriceUpdate die tatsächliche Anwendung durchführt; beide Schritte sind als getrennte Methodenaufrufe implementiert.
+Aussage:       Die Software soll Berechnung (Vorschau) und Anwendung einer Massenänderung als zwei getrennte, nacheinander aufgerufene Methoden implementieren, sodass die Anwendungsmethode nicht ohne vorherigen, vom Benutzer bestätigten Vorschauaufruf erreichbar ist.
+Ergebnis:      Es existiert kein direkter Codepfad von der Template-Auswahl zur Anwendung ohne zwischengeschaltete Vorschau.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs::StartReceiptPriceUpdate(int massUpdateI3D, LoggedInUser loggedInUser) - Begründung: Durchsetzende, von der Vorschau getrennte Anwendungsmethode.
+Prüfidee:      Code-Review: Prüfen, dass StartReceiptPriceUpdate ausschließlich aus dem Anwendungspfad nach Vorschaubestätigung aufrufbar ist.
+Tracelinks:    SyRS-180
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            SwRS-182
+Titel:         Textmustererkennung für Rückbuchungen im FinTS-Import
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente OnlineBankingConnectionLibfintx
+Vorbedingung:  -
+Fakt:          Die Rückbuchungserkennung basiert auf der Zeichenkettenprüfung `Text.Contains("RUECK")` in Kombination mit dem Flag importChargeback.
+Aussage:       Die Software soll die Rückbuchungserkennung nicht ausschließlich auf eine einzelne, feste Zeichenkette ("RUECK") stützen, da abweichende Buchungstexte von Banken (z. B. "Rücklastschrift", "R-Transaktion", englische Bezeichnungen) sonst fälschlich als reguläre negative Zahlung verworfen werden können.
+Ergebnis:      Eine Rückbuchung mit abweichendem, aber fachlich eindeutigem Buchungstext wird nicht fälschlich verworfen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs::Text.Contains("RUECK") - Begründung: Durchgesetzte, aber möglicherweise zu eng gefasste Texterkennung (siehe Hypothese H-10 zur Vollständigkeit der erkannten Textmuster).
+Prüfidee:      Kontoauszug mit Rückbuchung und abweichendem Buchungstext (z. B. "Rücklastschrift mangels Deckung") importieren und Erkennung/Nicht-Erkennung prüfen.
+Tracelinks:    SyRS-182
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen, Texterkennung im Zielsystem robuster gestalten (z. B. SEPA-Rückbuchungscode statt Freitext).
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-183
+Titel:         Herleitung des AES-Schlüssels und Ausschluss des Fallback-Konstanten
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente AESCryptoLogic
+Vorbedingung:  -
+Fakt:          AESCryptoLogic leitet Schlüssel/IV per SHA-512 aus dem übergebenen securityKey ab; wird kein Schlüssel übergeben, greift der hartcodierte Wert SECURITY_KEY = "lugE!35Djn" (Zeile 77).
+Aussage:       Die Software soll den Konstruktor/die Aufrufkette von AESCryptoLogic so ändern, dass ein Verschlüsselungsaufruf ohne explizit übergebenen, aus dem administrativ gesetzten Hotline-Masterkey abgeleiteten Schlüssel eine Exception auslöst, statt intern auf SECURITY_KEY zurückzufallen.
+Ergebnis:      Es ist technisch nicht mehr möglich, einen Datensatz mit dem im Quellcode fest hinterlegten Fallback-Schlüssel zu verschlüsseln.
+Belege:
+  - [PRIMÄR] src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs::Zeile 77, SECURITY_KEY = "lugE!35Djn" - Begründung: Durchsetzender, aber im Zielsystem zu entfernender Fallback-Mechanismus.
+Prüfidee:      AESCryptoLogic ohne übergebenen Schlüssel aufrufen und heutiges Verhalten (Verschlüsselung mit Fallback-Schlüssel) als Ist-Zustand dokumentieren; im Zielsystem Exception statt Fallback fordern.
+Tracelinks:    SyRS-183
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen, Fallback-Mechanismus zwingend entfernen.
+Status:        HYPOTHESE
+```
+
+## Bereich: Web-API (Software-Detailanforderungen)
+
+```
+ID:            SwRS-191
+Titel:         Mehrschichtiges Authentifizierungs- und Autorisierungsschema der Web-API
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponenten TicketAuthenticationHandler, AuthorizeUserRightAttribute, CentronHostedHandler, SecretKeyHandler
+Vorbedingung:  -
+Fakt:          TicketAuthenticationHandler.HandleAuthenticateAsync liest das Ticket aus Query (access_token) oder Authorization-Header und validiert es über AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod), das u. a. die aufrufende IP-Adresse und die aufgerufene API-Methode in die Validierung einbezieht; UserRightAuthorizationFilter.OnAuthorization liefert bei fehlender Authentifizierung 401, bei fehlendem Recht 403.
+Aussage:       Die Software soll die Ticketvalidierung so implementieren, dass ein für eine bestimmte IP-Adresse und API-Methode ausgestelltes Ticket bei Verwendung von einer anderen IP-Adresse oder für eine andere API-Methode als ungültig erkannt wird, und zwischen 401 (nicht authentifiziert) und 403 (Recht fehlt) eindeutig unterscheiden.
+Ergebnis:      Ein von einem Angreifer abgefangenes Ticket ist nicht ohne Weiteres von einer anderen IP-Adresse aus wiederverwendbar.
+Belege:
+  - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs::HandleAuthenticateAsync - Begründung: Durchsetzende, IP- und methodengebundene Validierung.
+  - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs::UserRightAuthorizationFilter.OnAuthorization - Begründung: Durchsetzende, klar getrennte 401/403-Antwortlogik.
+Prüfidee:      Gültiges Ticket von einer abweichenden IP-Adresse aus verwenden und Prüfen, ob die Bindung tatsächlich durchgesetzt wird oder nur protokolliert wird (siehe Hypothese H-11 zur Striktheit der IP-Bindung).
+Tracelinks:    SyRS-191
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE
+```
+
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Ergebnisse/Traceability.csv

@@ -0,0 +1,163 @@
+StRS-ID;SyRS-ID;SwRS-ID;Artefaktbeleg
+StRS-1;SyRS-121;;src/centron/Centron.WPF.UI/Modules/Sales/Mailing/Templates/MailingTemplateViewModel.cs
+StRS-2;SyRS-122;;src/centron/Centron.WPF.UI/Modules/Sales/ProductMatrix/ProductMatrixDialogViewModel.cs
+StRS-3;SyRS-123;;src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs
+StRS-4;SyRS-123;;src/centron/Centron.WPF.UI/Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportViewModel.cs
+StRS-5;SyRS-124;;src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement/AccountManagementViewModel.cs
+StRS-6;SyRS-101;SwRS-101;src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs
+StRS-6;SyRS-102;SwRS-102;src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs
+StRS-7;SyRS-125;;src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/CampaignMainViewModel.cs
+StRS-8;SyRS-126;;src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2/ContractEvaluation2ViewModel.cs
+StRS-9;SyRS-126;;src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld/ContractEvaluationOldViewModel.cs
+StRS-10;SyRS-101;SwRS-101;src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs
+StRS-11;SyRS-127;;src/centron/Centron.WPF.UI/Modules/Finances/Crm/CrmMainViewModel.cs
+StRS-12;SyRS-128;;src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter/DeviceClickCounterViewModel.cs
+StRS-13;SyRS-103;SwRS-103;src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs
+StRS-14;SyRS-104;;src/backend/Centron.BL (OrderBalanceBL)
+StRS-15;SyRS-105;;src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/MasterDataListViewModel.cs
+StRS-16;SyRS-106;SwRS-106;src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs
+StRS-17;SyRS-107;;src/centron/Centron.WPF.UI/Modules/Finances/Payments/PaymentsReceiptViewModel.cs
+StRS-18;SyRS-129;;src/centron/Centron.WPF.UI/Modules/Finances/Projects/ProjectOverviewViewModel.cs
+StRS-19;SyRS-108;SwRS-108;src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs
+StRS-20;SyRS-109;;src/backend/Centron.BL/Sales/CustomerAssets/TimerBilling/TimerBillingBL.cs
+StRS-21;SyRS-130;;src/centron/Centron.WPF.UI/Modules/Logistic/LogisticSettings/LogisticSettingsViewModel.cs
+StRS-22;SyRS-131;SwRS-131;src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs
+StRS-23;SyRS-132;SwRS-132;src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/ViewModels/TransactionDetailViewModel.cs
+StRS-24;SyRS-133;SwRS-133;src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs
+StRS-25;SyRS-134;SwRS-134;src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs
+StRS-26;SyRS-135;;src/backend/Centron.BL/Production/ProductionOrderBL.cs
+StRS-27;SyRS-136;;src/centron/Centron.WPF.UI/Modules/ProjectManagement/ProjectManagementViewModel.cs
+StRS-28;SyRS-137;;src/centron/Centron.WPF.UI/Modules/QM/Settings/QmSettingsViewModel.cs
+StRS-29;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/RmaOverviewViewModel.cs
+StRS-30;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/Events/NewRMAEvent.cs
+StRS-31;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/NewRma/NewRmaViewModel.cs
+StRS-32;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/RmaSettings/RmaSettingsViewModel.cs
+StRS-33;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/SendBack/SendBackViewModel.cs
+StRS-34;SyRS-138;;src/centron/Centron.WPF.UI/Modules/Rma/SendForth/SendForthViewModel.cs
+StRS-35;SyRS-139;SwRS-139;src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement/ReportEngineAppModuleController.cs
+StRS-36;SyRS-139;SwRS-139;src/backend/Centron.BL/ReportEngine/ReportDataQueryBL.cs
+StRS-37;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/AboutViewModel.cs
+StRS-38;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/Actions/PrintPdfAction.cs
+StRS-39;SyRS-141;SwRS-141;src/centron/Centron.WPF.UI/Modules/Global/CustomProperties/CustomPropertiesConnector.cs
+StRS-40;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/EmployeeSelection/EmployeeSelectionViewModel.cs
+StRS-41;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/ExceptionMessage/ExceptionUserInputViewModel.cs
+StRS-42;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/FileSystemDialog/FileSystemDialogViewModel.cs
+StRS-43;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/Help/HelpViewModel.cs
+StRS-44;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/MSPLicensesCompare/MspEvaluationHistoryViewModel.cs
+StRS-45;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics/NetworkDiagnosticsViewModel.cs
+StRS-46;SyRS-140;;src/centron/Centron.WPF.UI/Modules/Global/PerformanceTests/PerformanceTestViewModel.cs
+StRS-47;SyRS-142;;src/centron/Centron.WPF.UI/Modules/Global/VideoPortal/Evaluation/VideoPortalEvaluationViewModel.cs
+StRS-48;SyRS-143;;src/centron/Centron.WPF.UI/Modules/Gui
+StRS-49;SyRS-143;SwRS-143;src/centron/Centron.WPF.UI/Modules/Gui/Profiles/ManageUiProfileViewModel.cs
+StRS-50;SyRS-110;;src/centron/Centron.WPF.UI/Modules/DataExchange
+StRS-51;SyRS-111;SwRS-111;src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs
+StRS-52;SyRS-112;;src/centron/Centron.WPF.UI/Modules/DataExchange/Connectors/Settings/DocBeeConnectorSettingsViewModel.cs
+StRS-53;SyRS-113;;src/centron/Centron.WPF.UI/Modules/DataExchange/DataExport/DataExportViewModel.cs
+StRS-54;SyRS-114;SwRS-114;src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport/AccountImport/IbanValidation.cs
+StRS-55;SyRS-115;;src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs
+StRS-56;SyRS-116;;src/centron/Centron.WPF.UI/Modules/DataExchange/DocSync/DocSyncSettingsViewModel.cs
+StRS-57;SyRS-117;SwRS-117;src/centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization/DocuFormTokenHelper.cs
+StRS-58;SyRS-118;SwRS-118;src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs
+StRS-59;SyRS-119;;src/centron/Centron.WPF.UI/Modules/DataExchange/Rmm/Settings/RmmConnectionSettingsViewModel.cs
+StRS-60;SyRS-120;;src/centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch/SupplierOrderPerBranchViewModel.cs
+StRS-61;SyRS-120;;src/centron/Centron.WPF.UI/Modules/TelekomDive/TelekomDiveExportViewModel.cs
+StRS-62;SyRS-144;;src/centron/Centron.WPF.UI/Modules/Administration/Cache/CentronCache.cs
+StRS-63;SyRS-145;;src/centron/Centron.WPF.UI/Modules/Administration/CentronConfigDb/CentronConfigDbSettingsViewModel.cs
+StRS-64;SyRS-146;;src/centron/Centron.WPF.UI/Modules/Administration/Connections/LoginDialogViewModel.cs
+StRS-65;SyRS-147;;src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement/CountryManagementViewModel.cs
+StRS-66;SyRS-141;;src/centron/Centron.WPF.UI/Modules/Administration/Customization/CustomPropertiesOverviewGridManager.cs
+StRS-67;SyRS-148;SwRS-148;src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs
+StRS-68;SyRS-149;;src/centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/EmployeeManagementAppModuleController.cs
+StRS-69;SyRS-150;;src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings/EscalationType/EscalationTypeSettingViewModel.cs
+StRS-70;SyRS-151;;src/centron/Centron.WPF.UI/Modules/Administration/ExternalTools/ExternalToolSettingsViewModel.cs
+StRS-71;SyRS-152;;src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates/HourlySurchargeRatesViewModel.cs
+StRS-72;SyRS-153;;src/centron/Centron.WPF.UI/Modules/Administration/LogViewer/CentronLogViewModel.cs
+StRS-73;SyRS-154;;src/centron/Centron.WPF.UI/Modules/Administration/MailAndCalender/General/MailAndCalenderGeneralSettingsViewModel.cs
+StRS-74;SyRS-155;;src/centron/Centron.WPF.UI/Modules/Administration/MailTemplates/AiMailTemplatesViewModel.cs
+StRS-75;SyRS-156;SwRS-156;src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs
+StRS-76;SyRS-157;;src/centron/Centron.WPF.UI/Modules/Administration/PdfExport/PdfExportSettingsViewModel.cs
+StRS-77;SyRS-158;SwRS-158;src/backend/Centron.BL/Security/PdfSigningBL.cs
+StRS-78;SyRS-159;;src/centron/Centron.WPF.UI/Modules/Administration/PhoneSettings/PhoneSettingsViewModel.cs
+StRS-79;SyRS-160;;src/centron/Centron.WPF.UI/Modules/Administration/Profiling/ProfilerSettingsViewModel.cs
+StRS-80;SyRS-161;;src/centron/Centron.WPF.UI/Modules/Administration/ReceiptConditions/ReceiptConditionManagementViewModel.cs
+StRS-81;SyRS-162;;src/centron/Centron.WPF.UI/Modules/Administration/ReportServer/ReportServerConnector.cs
+StRS-82;SyRS-163;SwRS-163;src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs
+StRS-82;SyRS-164;SwRS-164;src/backend/Centron.BL/Administration/Rights
+StRS-83;SyRS-165;;src/centron/Centron.WPF.UI/Modules/Administration/SendDeliveryListShippingConfirmationSettings/General/SendDeliveryListShippingConfirmationGeneralSettingsViewModel.cs
+StRS-84;SyRS-166;SwRS-166;src/backend/Centron.Entities/Entities/Administration/Documents/SepaContracts/SepaContract.cs
+StRS-85;SyRS-167;;src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing/ServiceLeasingViewModel.cs
+StRS-86;SyRS-168;;src/centron/Centron.WPF.UI/Modules/Administration/Services/CTimeConnectors/CTimeConnectorSettingViewModel.cs
+StRS-87;SyRS-169;;src/centron/Centron.WPF.UI/Modules/Administration/Settings/SettingsSearchSupport.cs
+StRS-88;SyRS-170;;src/centron/Centron.WPF.UI/Modules/Administration/SqlManagers/SqlManagerViewModel.cs
+StRS-89;SyRS-171;;src/centron/Centron.WPF.UI/Modules/Administration/TaskManagmentSettings/General/TaskManagmentGeneralSettingsViewModel.cs
+StRS-90;SyRS-172;;src/centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement/TextBlockManagementViewModel.cs
+StRS-91;SyRS-173;;src/centron/Centron.WPF.UI/Modules/Administration/UpdateAvailableNotificationSettings/UpdateAvailableNotificationSettingsViewModel.cs
+StRS-92;SyRS-174;;src/centron/Centron.WPF.UI/Modules/Administration/WebCart/WebCartSettingsViewModel.cs
+StRS-93;SyRS-175;;src/centron/Centron.WPF.UI/Modules/Administration/WebServiceSettings/WebserviceSettingsViewModel.cs
+StRS-93;SyRS-191;SwRS-191;src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs
+StRS-94;SyRS-176;SwRS-176;src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/TicketDetailView.ArtificialIntelligence.cs
+StRS-95;SyRS-176;SwRS-176;src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs
+StRS-96;SyRS-177;;src/centron/Centron.WPF.UI/Modules/Calendar/Settings/Synchronization/CalendarSynchronizationSettingsViewModel.cs
+StRS-97;SyRS-178;;src/centron/Centron.WPF.UI/Modules/Dashboard/Modules/ModulesViewModel.cs
+StRS-98;SyRS-151;;src/centron/Centron.WPF.UI/Modules/ExternalTool/ExternalToolPreviewViewModel.cs
+StRS-99;SyRS-179;SwRS-179;src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CloseHelpdesk/CloseHelpdeskHelper.cs
+StRS-100;SyRS-180;SwRS-180;src/centron/Centron.WPF.UI/Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdatePreviewViewModel.cs
+StRS-101;SyRS-181;;src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/ArtificialIntelligence/PersonalArtificialIntelligenceSettingsViewModel.cs
+StRS-102;SyRS-182;SwRS-182;src/backend/Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs
+StRS-103;SyRS-183;SwRS-183;src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs
+StRS-104;SyRS-184;;src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/OpenDialog/AddCostCenterOrPayersViewModel.cs
+StRS-105;SyRS-185;;src/centron/Centron.WPF.UI/Modules/PLM/PlmAppModuleController.cs
+StRS-106;SyRS-186;;src/centron/Centron.WPF.UI/Modules/ProjectPriceImport/PriceDifference/DifferenceViewModel.cs
+StRS-107;SyRS-187;;src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo/ManagementInfoAppModuleController.cs
+StRS-108;SyRS-188;;src/centron/Centron.WPF.UI/Modules/Survey/Pages/Question/QuestionViewModel.cs
+StRS-109;SyRS-120;;src/centron/Centron.WPF.UI/Modules/TelekomDive/ViewModels/TelekomDiveCategoryViewModel.cs
+StRS-110;SyRS-183;;src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs
+;SyRS-189;;src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs
+;SyRS-190;;src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/Contract.cs
+;SyRS-192;;src/webservice/Centron.Controllers/Controllers/v1/Contracts/ContractsController.cs
+;SyRS-193;;src/nexus/CentronNexus/Controllers/FilesController.cs
+;SyRS-194;;src/shared/Centron.Core
+;SyRS-195;;src/backend/Centron.Gateway/Concerto/ConcertoOrder.cs
+;SyRS-196;;src/backend/Centron.Gateway/Core/GatewayResult.cs
+;SyRS-197;;src/backend/Centron.Gateway/DataExchange/BookKeeping/IBookKeepingExport.cs
+;SyRS-198;;src/backend/Centron.BL/EDI/SupplierEDI/SupplierEdiBL.Alltron.cs
+;SyRS-199;;src/backend/Centron.Gateway/Export/EDI
+;SyRS-200;;src/backend/Centron.Gateway/MspCollector/Octopus
+;SyRS-201;;src/backend/Centron.Gateway/OpenTrans/opentrans_2_1_wag.cs
+;SyRS-202;;src/backend/Centron.Gateway/Portal/WebServiceAccess.cs
+;SyRS-203;;src/backend/Centron.Gateway/ZUGFeRD21_Extended/ZUGFeRD_EXTENDED.cs
+;SyRS-204;;src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs
+;SyRS-205;;src/backend/Centron.BL/Mobile/MobileBL.cs
+;SyRS-206;;src/backend/Centron.BL/Integrations/EsRoleBL.cs
+;SyRS-207;;src/backend/Centron.BL/Telemetry/TelemetryBL.cs
+;SyRS-208;;src/backend/Centron.BL/Reporting/ReportsBL.cs
+;SyRS-209;;src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs
+;SyRS-210;;src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs
+;SyRS-211;;src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs
+;SyRS-212;;src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs
+;SyRS-213;;src/backend/Centron.BL/ChangeTracking/History/ImportHistoryBL.cs
+;SyRS-214;;src/backend/Centron.BL/SocialMedia/SocialMediaBL.cs
+;SyRS-215;;src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs
+;SyRS-216;;src/backend/Centron.BL/TradePool/TradePoolBL.cs
+;SyRS-217;;src/backend/Centron.BL/WebSuite/Administration/Settings/WebSettingBL.cs
+;SyRS-218;;src/backend/Centron.BL/WebVersion/VersionBL.cs
+;SyRS-219;;src/backend/Centron.BL/Chats/ChatBL.cs
+;SyRS-220;;src/backend/Centron.BL/DocuBoard/AssetManagementArticleAssignmentBL.cs
+;SyRS-221;;src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs
+;SyRS-222;;src/backend/Centron.BL/MailScanner/MailScannerBL.cs
+;SyRS-223;;src/backend/Centron.BL/Outlook/OutlookAssetKindSearchBL.cs
+;SyRS-224;;src/backend/Centron.BL/Tapi/PhoneCallBL.cs
+;SyRS-225;;src/backend/Centron.BL/CPra/CPraConnectorBL.cs
+;SyRS-226;;src/backend/Centron.BL/SelfCare/SelfCareBL.cs
+;SyRS-227;;src/backend/Centron.BL/BusinessPartner/SearchSupplierBL.cs
+;SyRS-228;;src/backend/Centron.BL/CustomerArea/RmaBL.cs
+;SyRS-229;;src/backend/Centron.BL/EmployeeArea/EmployeeBL.cs
+;SyRS-230;;src/backend/Centron.BL/CountryArea/CountryBL.cs
+;SyRS-231;;src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs
+;SyRS-232;;src/backend/Centron.BL/Accounts/AccountBL.cs
+;SyRS-233;;src/backend/Centron.BL/Accounting/BankAccountBL.cs
+;SyRS-234;;src/backend/Centron.BL/Buying/External/DistributorBL.cs
+;SyRS-235;;src/backend/Centron.BL/EDI/EDIDispatcherBL.cs
+;SyRS-236;;src/backend/Centron.BL/Devices/AccountDeviceBL.cs
+;SyRS-237;;src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs
+;SyRS-238;;src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/Protokoll.md

@@ -0,0 +1,213 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T12:50:56.6431435+02:00
+- **Endzeit:** 2026-08-26T13:39:56.3875024+02:00
+- **Dauer gesamt:** 0:48:59 (`duration_ms` 0:41:39; API: 1:05:53)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 31.306.222 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.985 Tokens (0.02 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-f8b4`
+- **Ablage:** `Iteration 3/claude-sonnet-5/builtin/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `builtin` (V1b)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen.
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** 8 gestartet (8 × `Explore`), 8 abgeschlossen, 0 fehlgeschlagen; 8 im Hintergrund gestartet
+- **Verschachtelung:** `spawned` = 8, davon `spawned_by_subagents` = 0, `max_depth` = 1.
+- **Verbrauchsanteil der Subagenten:** `usage` (nur Hauptagent) 22.886.924 Tokens gegenüber `modelUsage` 31.313.207 Tokens – auf die Subagenten entfallen 8.426.283 Tokens (26.9 %).
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 128 |
+| Output-Tokens | 296.311 (davon 49.641 Thinking-Tokens) |
+| Cache-Write-Tokens | 325.717 |
+| Cache-Read-Tokens | 22.264.768 |
+| Agent-Turns | 64 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 432 | 6.963 | 7.395 |
+| Output-Tokens | 450.267 | 22 | 450.289 |
+| Cache-Write-Tokens | 889.326 | 0 | 889.326 |
+| Cache-Read-Tokens | 29.966.197 | 0 | 29.966.197 |
+| **Tokens gesamt** | **31.306.222** | **6.985** | **31.313.207** |
+
+**Tokens gesamt: 31.313.207** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+`usage` erfasst **nur den Hauptagenten**. Der Unterschied zu `modelUsage` ist der Verbrauch
+der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den
+abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 110 | 39,9 % |
+| SyRS | 138 | 50,0 % |
+| SwRS | 28 | 10,1 % |
+| **Gesamt** | **276** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 132 | 47,8 % |
+| Daten | 54 | 19,6 % |
+| Sicherheit | 42 | 15,2 % |
+| Schnittstelle | 30 | 10,9 % |
+| nicht-funktional | 18 | 6,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 293 |
+| davon `PRIMÄR` | 145 (49,5 %) |
+| davon `SEKUNDÄR` | 142 (48,5 %) |
+| davon `KONTEXT` | 6 (2,0 %) |
+| Belege je Anforderung (Median) | 1,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 128 (46,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 258 | 93,5 % |
+| workaround | 4 | 1,4 % |
+| sonderfall | 11 | 4,0 % |
+| veraltet | 3 | 1,1 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 261 | 94,6 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 5,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 24 | 8,7 % |
+| mit ISO-25010-Qualitätsmerkmal | 18 | 6,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 13 von 73 ungedeckt: StRS-44, StRS-80, StRS-97, SyRS-107, SyRS-127, SyRS-128, SyRS-145, SyRS-161 … |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 276 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 233 von 276 mit Tracelinks (84,4 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `bceffc23-fcd2-4c9b-acad-122cb51699ec`
+- **Permission-Denials:** 0 – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 8 – Bedingung `solo` **VERLETZT – Fehlmessung**
+- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 46.475 B |
+  | `Glossar.md` | 6.111 B |
+  | `Hypothesen.md` | 6.512 B |
+  | `StRS.md` | 137.861 B |
+  | `SwRS.md` | 38.995 B |
+  | `SyRS.md` | 155.587 B |
+  | `Traceability.csv` | 15.220 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Modellkontrolle bei `builtin` besonders relevant – und bestanden.** `--model` steuert nur den
+Hauptagenten. In Iteration 1 liefen bei Fable die 13 Subagenten auf `claude-opus-5[1m]`, also 91 %
+des Verbrauchs auf einem nicht angeforderten Modell. Hier weist `modelUsage` ausschließlich
+`claude-sonnet-5` plus Haiku-Hilfsaufrufe aus: Sonnet wird an die Subagenten durchgereicht.
+
+**5. `usage` misst nur den Hauptagenten.** Für den Gesamtverbrauch gilt ausschließlich
+`modelUsage` – siehe Feld „Verbrauchsanteil der Subagenten" oben.
+
+**6. Gegenbeispiel zu `4048`: „Survey" statt „Research" – und die Belegqualität halbiert sich.**
+Der Hauptagent beauftragte seine acht `Explore`-Agenten durchgehend mit Bestandsaufnahmen
+(*„Survey Sales and Finances modules"*, *„Survey backend infrastructure"* …) statt mit
+Faktenerhebung samt durchsetzender Codestelle. Ergebnis: **276 Anforderungen** – der zweithöchste
+Wert der `builtin`-Zelle – bei nur **46,4 % mit Primärbeleg** gegenüber 97,8 % bei `4048`. Beide
+Läufe hatten denselben Prompt, dasselbe Modell, denselben Modus und eine ähnliche Zahl von
+Subagenten (8 gegenüber 6).
+
+**7. Damit hat Befund 6.3 der Versuchsreihe erstmals eine inhaltliche Erklärung.** Bisher war nur
+bekannt, dass die selbstgewählte Zerlegung die Ergebnisse dominiert; die Kenngröße war die
+*Anzahl* der Subagenten. Der Vergleich `4048` gegen `f8b4` zeigt, dass nicht die Anzahl
+entscheidet, sondern **ob Tiefe oder Breite beauftragt wird**. Genau dafür wurde die Erfassung der
+Subagenten-Prompts in Skill 3.3.0 eingeführt.
+
+**8. Ebenenverteilung stark kopflastig:** 110 StRS / 138 SyRS / 28 SwRS. Die Softwareebene, die
+das *Wie* einer Neuimplementierung trägt, ist mit 10,1 % am schwächsten besetzt – passend zu
+Aufträgen, die Überblick statt Codestellen verlangten.
+
+**9. Sauber im Werkzeugverhalten:** 0 Denials, genau die sieben geforderten Dateien, alle 8
+Subagenten abgeschlossen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":3953845,"num_turns":64,"stop_reason":"end_turn","session_id":"bceffc23-fcd2-4c9b-acad-122cb51699ec","total_cost_usd":13.394913400000005,"usage":{"input_tokens":128,"cache_creation_input_tokens":325717,"cache_read_input_tokens":22264768,"output_tokens":296311,"output_tokens_details":{"thinking_tokens":49641},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":325717,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":714,"cache_read_input_tokens":482889,"cache_creation_input_tokens":810,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":810},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6963,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007072999999999999,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":432,"outputTokens":450267,"cacheReadInputTokens":29966197,"cacheCreationInputTokens":889326,"webSearchRequests":0,"costUSD":13.387840400000005,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","origin":{"kind":"task-notification"},"subagent_stats":{"spawned":8,"requested":{"background":0,"foreground":0,"unset":8},"started_in_background":8,"max_depth":1,"spawned_by_subagents":0,"completed":8,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"Explore":8}},"subtype":"success","api_error_status":null,"result":"## Summary\n\nI've completed the reverse-requirements-engineering run on the c-entron ERP codebase per the Iteration-02 baseline prompt, following the mandated sequence (module inventory → minimum coverage → risk-based deepening).\n\n**What was produced** in `Iteration 3\\claude-sonnet-5\\builtin\\high\\02_Lauf_2026-08-26_125032_v4.4.0-f8b4\\Ergebnisse\\`:\n\n- **Analysebericht.md** — full Schritt-0 module inventory (165 rows: 111 business UI modules + 54 backend/architecture components), coverage table (tief/mittel/flach/nicht analysiert per row), consistency check, risk-register, and self-assessment\n- **StRS.md** (110 requirements), **SyRS.md** (138), **SwRS.md** (28) — 276 requirements total, each with Fakt/Aussage separation, classified evidence (PRIMÄR/SEKUNDÄR/KONTEXT), Prüfidee, Konsolidierung, and Übernahmewürdigkeit\n- **Traceability.csv** — StRS↔SyRS↔SwRS chains with artefact references\n- **Hypothesen.md** — 12 hypothesis groups covering 15 flagged requirements (e.g., a hardcoded AES fallback key, unclear branch-restricted rights enforcement, an unbelegt payment-consistency check caught during the consistency pass and corrected to `[HYPOTHESE]`)\n- **Glossar.md** — domain terminology\n\nNotable findings surfaced along the way: a hardcoded crypto fallback key (`AESCryptoLogic`), GoBD invoice-fixation logic, SEPA/pain.008 export with a configurable amount cap, the layered `HasUserRight`/`Sichtrus`/`Sichmemb` authorization model, and a legacy password path that never actually encrypts despite its naming — all captured with PRIMÄR evidence naming the enforcing class/method.\n\nTwo ID-reference errors and one risk-priority violation were caught and fixed during the self-review before finalizing.","ttft_ms":76343,"ttft_stream_ms":1113,"time_to_request_ms":6,"type":"result","duration_ms":2499972,"uuid":"ae722341-1272-4417-aa7f-4acdb2236b17","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 110 | 39,9 % |
+| SyRS | 138 | 50,0 % |
+| SwRS | 28 | 10,1 % |
+| **Gesamt** | **276** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 132 | 47,8 % |
+| Daten | 54 | 19,6 % |
+| Sicherheit | 42 | 15,2 % |
+| Schnittstelle | 30 | 10,9 % |
+| nicht-funktional | 18 | 6,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 293 |
+| davon `PRIMÄR` | 145 (49,5 %) |
+| davon `SEKUNDÄR` | 142 (48,5 %) |
+| davon `KONTEXT` | 6 (2,0 %) |
+| Belege je Anforderung (Median) | 1,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 128 (46,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 258 | 93,5 % |
+| workaround | 4 | 1,4 % |
+| sonderfall | 11 | 4,0 % |
+| veraltet | 3 | 1,1 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 261 | 94,6 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 5,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 24 | 8,7 % |
+| mit ISO-25010-Qualitätsmerkmal | 18 | 6,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 13 von 73 ungedeckt: StRS-44, StRS-80, StRS-97, SyRS-107, SyRS-127, SyRS-128, SyRS-145, SyRS-161 … |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 276 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 233 von 276 mit Tracelinks (84,4 %) |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/combined_prompt.md

@@ -0,0 +1,178 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-sonnet-5\builtin\high\02_Lauf_2026-08-26_125032_v4.4.0-f8b4\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:39:56.3875024+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T12:50:56.6431435+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/subagenten.json

@@ -0,0 +1,90 @@
+[
+ {
+  "id": "toolu_01HU7xA1eZVWZGDHFqnySCdd",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey Sales and Finances modules",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders, quickly inspect the contents (list files, open 1-3 representative files such as main ViewModel, View, or a corresponding Centron.BL/<Area> business-logic class) and report back CONCISE structured findings. Do not write essays — this is a fact-gathering pass, not analysis.\n\nFolders to cover (paths relative to repo root):\n- src/centron/Centron.WPF.UI/Modules/Sales (and its subfolders Mailing, ProductMatrix, SpecialArticleImport, SpecialArticleToContractImport)\n- src/centron/Centron.WPF.UI/Modules/Finances (top-level, e.g. shell/menu)\n- src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement\n- src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling\n- src/centron/Centron.WPF.UI/Modules/Finances/Campaigns\n- src/centron/Centron.WPF.UI/Modules/Finances/Contracts\n- src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2\n- src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld\n- src/centron/Centron.WPF.UI/Modules/Finances/Crm\n- src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter\n- src/centron/Centron.WPF.UI/Modules/Finances/Dunning\n- src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling\n- src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists\n- src/centron/Centron.WPF.UI/Modules/Finances/Opos\n- src/centron/Centron.WPF.UI/Modules/Finances/Payments\n- src/centron/Centron.WPF.UI/Modules/Finances/ProductLifecycleManagement\n- src/centron/Centron.WPF.UI/Modules/Finances/Projects\n- src/centron/Centron.WPF.UI/Modules/Finances/Receipts\n- src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling\n- src/centron/Centron.WPF.UI/Modules/Finances/Common\n\nAlso check the corresponding backend logic in src/backend/Centron.BL/Finances and src/backend/Centron.BL/Sales for business rules (validation, status enums, calculations) relevant to these areas — especially anything about invoicing/billing (Rechnung, Mahnung/Dunning, Vertrag/Contract, Zahlung/Payment) since these are financially risk-relevant.\n\nFor EACH folder/module above, output in this exact compact format (one block per module, plain text, no markdown tables needed):\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence describing the business purpose, based on what you actually saw>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows, e.g. \"status enum with values X,Y,Z\" or \"validation: amount must be > 0\" or \"permission check via HasRight(...)\">\nEVIDENZ2 (optional second evidence item, especially for billing/dunning/contract/payment areas — look for the class/method that ENFORCES a rule, e.g. calculates an invoice amount, checks a due date, applies a dunning level, validates a contract state transition): <same format>\nLEER: <yes/no — \"yes\" if the folder is essentially empty/trivial (e.g. just a stub or pure resource dictionary) so it should be marked \"nicht analysiert\" with reason>\n\nBe efficient: don't read entire files, just enough to find real evidence (class names, method names, enum values, validation conditions, UI label strings). Prioritize depth on the Finances/billing-related folders (AutomatedBilling, Dunning, Contracts, Payments, Opos, TimerBilling, FlatrateBilling, Receipts) since these are risk-critical for the final requirements spec (need to name the enforcing class+method, not just a file).\n\nReturn your full findings as the final message text — this is data for another process to consume, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01J5vS6W5bjWMjB4Hv8c1h2R",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey Logistic, Purchasing, Warehousing, Production, QM",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/<Area> business-logic class) and report CONCISE structured findings. Fact-gathering only, not analysis.\n\nFolders:\n- src/centron/Centron.WPF.UI/Modules/Logistic (+ subfolders LogisticSettings, ShippingMethodSettings)\n- src/centron/Centron.WPF.UI/Modules/Purchasing (+ subfolders EDIManagement, OrderSuggestionList, Others, PurchaseSettings, TravelExpense)\n- src/centron/Centron.WPF.UI/Modules/Warehousing (+ subfolders AccountSystems, ArticleImport, ArticleManagement, ArticleUnitManagement, BarcodeManagement, Commissioning, Commissions, Inventory, MaterialGroupManagement, OutcomingPayments, SearchArticle, SupplierSearch)\n- src/centron/Centron.WPF.UI/Modules/Production (+ subfolders MachineManagement, ProductionOrder, Settings)\n- src/centron/Centron.WPF.UI/Modules/ProjectManagement\n- src/centron/Centron.WPF.UI/Modules/QM (+ subfolder Settings)\n\nAlso check corresponding backend logic in src/backend/Centron.BL/Logistics, src/backend/Centron.BL/Purchasing, src/backend/Centron.BL/Warehousing, src/backend/Centron.BL/Production, src/backend/Centron.BL/Projects for business rules (validation, status enums, calculations, stock/inventory rules, approval workflows).\n\nFor EACH module above, output in this exact compact format (one block per module):\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence describing business purpose, based on what you actually saw>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows, e.g. \"status enum values\", \"validation rule\", \"permission check\">\nEVIDENZ2 (optional, especially for Warehousing/Inventory stock-relevant and Purchasing/TravelExpense (expense approval/money) — name the enforcing class+method): <same format>\nLEER: <yes/no>\n\nBe efficient. Prioritize finding the enforcing class+method (not just file names) for TravelExpense (expense reimbursement approval), Inventory (stock quantity rules), OutcomingPayments, and OrderSuggestionList (auto-reorder logic) since these involve money or committed decisions.\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01EFnz4P3acstJsLeNcSvAnH",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey Rma, Reports, Global, Gui, DataExchange",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/<Area> business-logic class) and report CONCISE structured findings. Fact-gathering only.\n\nFolders:\n- src/centron/Centron.WPF.UI/Modules/Rma (+ subfolders Events, NewRma, RmaSettings, SendBack, SendForth)\n- src/centron/Centron.WPF.UI/Modules/Reports (+ subfolder ReportManagement)\n- src/centron/Centron.WPF.UI/Modules/Global (+ subfolders Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help, MSPLicensesCompare, NetworkDiagnostics, PerformanceTests, VideoPortal)\n- src/centron/Centron.WPF.UI/Modules/Gui (+ subfolder Profiles)\n- src/centron/Centron.WPF.UI/Modules/DataExchange (+ subfolders BookKeeping, Connectors, DataExport, DataImport, DatevOnline2020, DocSync, DocuForm, PaymentTransactions, Rmm, SupplierOrderPerBranch, TelekomDive)\n\nAlso check corresponding backend logic in src/backend/Centron.BL/DataExchange, src/backend/Centron.BL/ReportEngine, src/backend/Centron.BL/Reporting where relevant for business rules, validations, data mapping/export logic (especially DATEV/bookkeeping export which is finance-relevant, and PaymentTransactions).\n\nFor EACH module above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence, business purpose, based on what you saw>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>\nEVIDENZ2 (optional, especially for BookKeeping/DATEV export and PaymentTransactions — name enforcing class+method): <same format>\nLEER: <yes/no>\n\nPrioritize DataExchange/BookKeeping, DataExchange/DatevOnline2020, and DataExchange/PaymentTransactions for depth since these touch financial data exchange.\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01C9F9EtZH5LP4mFAbFiid6x",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey Administration module (all submodules)",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders under src/centron/Centron.WPF.UI/Modules/Administration/, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/Administration or Centron.BL/Security business-logic class) and report CONCISE structured findings. Fact-gathering only.\n\nFolders (all under Administration/):\nCache, CentronConfigDb, Connections, CountryManagement, Customization, DSGVO, EmployeeManagement, EscalationsSettings, ExternalTools, HourlySurchargeRates, LogViewer, MailAndCalender, MailTemplates, MandatorManagement, PdfExport, PdfSigning, PhoneSettings, Profiling, ReceiptConditions, ReportServer, RightsManagement, SendDeliveryListShippingConfirmationSettings, SepaContract, ServiceAndLeasing, Services, Settings, SqlManagers, TaskManagmentSettings, TextBlockManagement, UpdateAvailableNotificationSettings, WebCart, WebServiceSettings\n\nThis module set is HIGH PRIORITY / risk-relevant: RightsManagement (permissions/authorization), SepaContract (payment mandates), PdfSigning (document signing), DSGVO (data protection/GDPR), MandatorManagement (multi-tenant isolation) need genuine depth — find the ACTUAL enforcing class + method (e.g. a HasRight()/IsAuthorized() check, a role/permission enum, a SEPA mandate validation, a signature certificate check, a tenant-id filter in a query). Don't just report file existence — open the file and quote the real logic (method name, condition, enum values).\n\nAlso check src/backend/Centron.BL/Security, src/backend/Centron.BL/Administration, and search the codebase broadly for permission-check patterns (grep for things like \"HasRight\", \"IsAuthorized\", \"CheckPermission\", \"Recht\", \"Berechtigung\") to find where RightsManagement is actually enforced across the app (not just its own settings UI) — this is critical evidence for a security-relevant requirement.\n\nFor EACH module above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence, business purpose>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL/constraint> — <what it shows>\nEVIDENZ2 (name enforcing class+method where possible, esp. for RightsManagement/SepaContract/PdfSigning/DSGVO/MandatorManagement): <same format>\nLEER: <yes/no>\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01WhuYRX7amG7YLMtiA4QuMS",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey AI, Calendar, Dashboard, ExternalTool, Helpdesk, Massenupdates, MyCentron",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL business-logic class) and report CONCISE structured findings. Fact-gathering only.\n\nFolders:\n- src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence (+ subfolders Chat, Controller, Interfaces, OfferPositionsAIEditor, OpenAIConnect, TextRating)\n- src/centron/Centron.WPF.UI/Modules/Calendar (+ subfolder Settings)\n- src/centron/Centron.WPF.UI/Modules/Dashboard (+ subfolder Modules)\n- src/centron/Centron.WPF.UI/Modules/ExternalTool (+ subfolder Variables)\n- src/centron/Centron.WPF.UI/Modules/Helpdesk (+ subfolders CentronChecklist, ConnectionNumber, Dashboard, Events, ExpectedEvents, ExpectedEventsReporting, SendSelfCareForm, Settings, TaskManagement, TicketDetails, TicketList, TicketProcessTemplates)\n- src/centron/Centron.WPF.UI/Modules/Massenupdates (+ subfolders Event, Updates)\n- src/centron/Centron.WPF.UI/Modules/MyCentron (+ subfolders Calendar, CentronInspectors, Dashboard, MyDay, PersonalSettings, Supremo, Telephony, TodoList)\n\nAlso check src/backend/Centron.BL/ArtificialIntelligence, src/backend/Centron.BL/Calendar (if exists, else skip), and helpdesk/ticket related backend logic for business rules, status/workflow enums (e.g. ticket status transitions), and any AI-related integration (OpenAI API calls, prompt handling) since AI features are novel/risky.\n\nFor EACH module above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence, business purpose>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>\nEVIDENZ2 (optional, especially for Helpdesk/TicketDetails status workflow and ArtificialIntelligence/OpenAIConnect — name enforcing class+method): <same format>\nLEER: <yes/no>\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01L7K2wuqHeM1zMKGFRdohPE",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey OnlineBanking, PasswordManager, PayersAndCostCenter, PLM, ProjectPriceImport, Statistics, Survey, TelekomDive",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL business-logic class) and report CONCISE structured findings. Fact-gathering only.\n\nFolders:\n- src/centron/Centron.WPF.UI/Modules/OnlineBanking (+ subfolders AccountTransactions, ConfigurationSettings, ConnectionDialog)\n- src/centron/Centron.WPF.UI/Modules/PasswordManager (+ subfolders LayoutSaving, Settings)\n- src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter (+ subfolders DTOViewModel, OpenDialog)\n- src/centron/Centron.WPF.UI/Modules/PLM\n- src/centron/Centron.WPF.UI/Modules/ProjectPriceImport (+ subfolders PriceDifference, Settings)\n- src/centron/Centron.WPF.UI/Modules/Statistics (+ subfolders Dashboard, EmployeeAnalytics, ManagementInfo, MspCollectors, MspStatistics, SaleStatistics)\n- src/centron/Centron.WPF.UI/Modules/Survey (+ subfolders Pages, SurveySettings)\n- src/centron/Centron.WPF.UI/Modules/TelekomDive (+ subfolder ViewModels)\n\nAlso check src/backend/Centron.BL/PasswordManager, src/backend/Centron.BL/PasswordManagementArea, and src/backend/Centron.Gateway/OnlineBanking for business rules — PasswordManager (credential storage/encryption) and OnlineBanking (bank account transactions, HBCI/FinTS) are security/finance-relevant, need genuine depth: find the actual encryption method, storage class, or transaction-import validation.\n\nFor EACH module above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence, business purpose>\nEVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>\nEVIDENZ2 (optional, especially for PasswordManager encryption and OnlineBanking transaction import — name enforcing class+method): <same format>\nLEER: <yes/no>\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01PTVhRazLAZQQ4roJhj42dx",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey backend infrastructure: DAO, Entities, Gateway, Controllers, Nexus, Core",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#/WPF backend + web API + web portal, C-entron ERP) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nFor EACH of the following technical/architectural components, quickly inspect contents (list files, open 2-4 representative files) and report CONCISE structured findings. Fact-gathering only, not analysis.\n\nComponents:\n- src/backend/Centron.DAO (data access layer — check NHibernateConfiguration, Repositories, ChangeTracking for how persistence and auditing work)\n- src/backend/Centron.Entities (domain entity model — check Entities folder for how many entity classes roughly, pick 2-3 significant ones e.g. related to invoicing/contracts, note their key properties)\n- src/backend/Centron.Gateway/Concerto\n- src/backend/Centron.Gateway/Core\n- src/backend/Centron.Gateway/DataExchange\n- src/backend/Centron.Gateway (the EDI connectors: EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa — treat as one group, just note the common pattern e.g. interface implemented, one example file)\n- src/backend/Centron.Gateway/Export and /Import\n- src/backend/Centron.Gateway/MspCollector\n- src/backend/Centron.Gateway/OnlineBanking\n- src/backend/Centron.Gateway/OpenTrans and /OpenTrans1_0\n- src/backend/Centron.Gateway/Portal\n- src/backend/Centron.Gateway/ZUGFeRD21_Extended\n- src/webservice/Centron.Controllers/Controllers (the REST API endpoints — list a few controller classes and their routes)\n- src/webservice/Centron.Controllers/Authorization (how does the web API authenticate/authorize requests? find the actual auth mechanism — token validation, API key check, etc.)\n- src/nexus/CentronNexus (customer/employee-facing web portal — check Controllers, DocumentSigning, WebCart, WebOffer subfolders for what functionality it exposes)\n- src/shared/Centron.Core and src/shared/Centron.Controls (shared framework/UI controls library — just note what kind of shared infrastructure this is, briefly)\n\nFor EACH component above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence describing its technical/architectural purpose>\nEVIDENZ1: <exact file path>::<class/method/interface/route> — <what it shows>\nEVIDENZ2 (optional, especially for Authorization mechanism, ZUGFeRD e-invoicing format compliance, and OnlineBanking gateway — name the enforcing class+method): <same format>\nLEER: <yes/no>\n\nPrioritize depth on: Authorization (webservice/Centron.Controllers/Authorization — this gates all API access, security-critical), ZUGFeRD21_Extended (legally mandated e-invoice format, finance-critical), and Centron.DAO/ChangeTracking (audit trail, compliance-relevant).\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01TJ6UAsaAEcvynyj8hNML2C",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Survey remaining Centron.BL backend components without UI counterpart",
+  "run_in_background": null,
+  "model": null,
+  "prompt": "You are surveying part of a large legacy ERP codebase (C#, C-entron ERP business logic layer) at C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.\n\nThe folder src/backend/Centron.BL contains many subfolders, most of which correspond to a UI module already surveyed elsewhere. You are covering the remaining ones that do NOT have an obvious 1:1 UI module counterpart — these are backend-only or cross-cutting business capabilities. For EACH, quickly inspect contents (list files, open 1-2 representative files) and report CONCISE structured findings.\n\nFolders (all under src/backend/Centron.BL/):\nSecurity, TwoFactorAuthenticator, Mobile, Integrations, Telemetry, ReportEngine, Reporting, TaskManager, MassUpdate, Notifications, IndexSearch, ChangeTracking, SocialMedia, RiverDivo, TradePool, WebSuite, WebVersion, Chats, DocuBoard, ItPlanner, MailScanner, Outlook, Tapi, CPra, SelfCare, BusinessPartner, CustomerArea, EmployeeArea, CountryArea, AppointmentRequests, Accounts, Accounting, Buying, EDI, Devices, ObjectExternalReferences, ExternalHelpdesk\n\nFor each, if the folder is trivial/near-empty, just say so (LEER: yes). Prioritize genuine depth (find real class+method, not just filenames) for: Security (general security helpers beyond RightsManagement — e.g. password hashing, encryption), TwoFactorAuthenticator (2FA enforcement), Accounting (bookkeeping rules), EDI (electronic data interchange format handling), ChangeTracking already covered elsewhere so skip deep dive if redundant.\n\nFor EACH folder above, output in this exact compact format:\n\nMODUL: <name>\nPFAD: <path>\nAUFGABE: <one German sentence describing its purpose>\nEVIDENZ1: <exact file path>::<class/method> — <what it shows>\nEVIDENZ2 (optional, esp. for Security, TwoFactorAuthenticator, Accounting, EDI): <same format>\nLEER: <yes/no>\n\nReturn your full findings as the final message text — this is data for another process, not a human-facing report.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ }
+]

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4/_meta/subagenten.md

@@ -0,0 +1,301 @@
+# Subagenten-Aufrufe
+
+Session `bceffc23-fcd2-4c9b-acad-122cb51699ec`, Transkript `bceffc23-fcd2-4c9b-acad-122cb51699ec.jsonl`.
+
+`subagent_stats`: **8** Subagenten gesamt, davon **0** von Subagenten gestartet (max_depth 1). Direkt vom Hauptagenten erwartet: **8**. Im Transkript gefunden: **8** echte Starts.
+
+## 1. Survey Sales and Finances modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 3656  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders, quickly inspect the contents (list files, open 1-3 representative files such as main ViewModel, View, or a corresponding Centron.BL/<Area> business-logic class) and report back CONCISE structured findings. Do not write essays — this is a fact-gathering pass, not analysis.
+
+Folders to cover (paths relative to repo root):
+- src/centron/Centron.WPF.UI/Modules/Sales (and its subfolders Mailing, ProductMatrix, SpecialArticleImport, SpecialArticleToContractImport)
+- src/centron/Centron.WPF.UI/Modules/Finances (top-level, e.g. shell/menu)
+- src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement
+- src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling
+- src/centron/Centron.WPF.UI/Modules/Finances/Campaigns
+- src/centron/Centron.WPF.UI/Modules/Finances/Contracts
+- src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluation2
+- src/centron/Centron.WPF.UI/Modules/Finances/ContractEvaluationOld
+- src/centron/Centron.WPF.UI/Modules/Finances/Crm
+- src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter
+- src/centron/Centron.WPF.UI/Modules/Finances/Dunning
+- src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling
+- src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists
+- src/centron/Centron.WPF.UI/Modules/Finances/Opos
+- src/centron/Centron.WPF.UI/Modules/Finances/Payments
+- src/centron/Centron.WPF.UI/Modules/Finances/ProductLifecycleManagement
+- src/centron/Centron.WPF.UI/Modules/Finances/Projects
+- src/centron/Centron.WPF.UI/Modules/Finances/Receipts
+- src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling
+- src/centron/Centron.WPF.UI/Modules/Finances/Common
+
+Also check the corresponding backend logic in src/backend/Centron.BL/Finances and src/backend/Centron.BL/Sales for business rules (validation, status enums, calculations) relevant to these areas — especially anything about invoicing/billing (Rechnung, Mahnung/Dunning, Vertrag/Contract, Zahlung/Payment) since these are financially risk-relevant.
+
+For EACH folder/module above, output in this exact compact format (one block per module, plain text, no markdown tables needed):
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence describing the business purpose, based on what you actually saw>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows, e.g. "status enum with values X,Y,Z" or "validation: amount must be > 0" or "permission check via HasRight(...)">
+EVIDENZ2 (optional second evidence item, especially for billing/dunning/contract/payment areas — look for the class/method that ENFORCES a rule, e.g. calculates an invoice amount, checks a due date, applies a dunning level, validates a contract state transition): <same format>
+LEER: <yes/no — "yes" if the folder is essentially empty/trivial (e.g. just a stub or pure resource dictionary) so it should be marked "nicht analysiert" with reason>
+
+Be efficient: don't read entire files, just enough to find real evidence (class names, method names, enum values, validation conditions, UI label strings). Prioritize depth on the Finances/billing-related folders (AutomatedBilling, Dunning, Contracts, Payments, Opos, TimerBilling, FlatrateBilling, Receipts) since these are risk-critical for the final requirements spec (need to name the enforcing class+method, not just a file).
+
+Return your full findings as the final message text — this is data for another process to consume, not a human-facing report.
+```
+
+## 2. Survey Logistic, Purchasing, Warehousing, Production, QM
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2474  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/<Area> business-logic class) and report CONCISE structured findings. Fact-gathering only, not analysis.
+
+Folders:
+- src/centron/Centron.WPF.UI/Modules/Logistic (+ subfolders LogisticSettings, ShippingMethodSettings)
+- src/centron/Centron.WPF.UI/Modules/Purchasing (+ subfolders EDIManagement, OrderSuggestionList, Others, PurchaseSettings, TravelExpense)
+- src/centron/Centron.WPF.UI/Modules/Warehousing (+ subfolders AccountSystems, ArticleImport, ArticleManagement, ArticleUnitManagement, BarcodeManagement, Commissioning, Commissions, Inventory, MaterialGroupManagement, OutcomingPayments, SearchArticle, SupplierSearch)
+- src/centron/Centron.WPF.UI/Modules/Production (+ subfolders MachineManagement, ProductionOrder, Settings)
+- src/centron/Centron.WPF.UI/Modules/ProjectManagement
+- src/centron/Centron.WPF.UI/Modules/QM (+ subfolder Settings)
+
+Also check corresponding backend logic in src/backend/Centron.BL/Logistics, src/backend/Centron.BL/Purchasing, src/backend/Centron.BL/Warehousing, src/backend/Centron.BL/Production, src/backend/Centron.BL/Projects for business rules (validation, status enums, calculations, stock/inventory rules, approval workflows).
+
+For EACH module above, output in this exact compact format (one block per module):
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence describing business purpose, based on what you actually saw>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows, e.g. "status enum values", "validation rule", "permission check">
+EVIDENZ2 (optional, especially for Warehousing/Inventory stock-relevant and Purchasing/TravelExpense (expense approval/money) — name the enforcing class+method): <same format>
+LEER: <yes/no>
+
+Be efficient. Prioritize finding the enforcing class+method (not just file names) for TravelExpense (expense reimbursement approval), Inventory (stock quantity rules), OutcomingPayments, and OrderSuggestionList (auto-reorder logic) since these involve money or committed decisions.
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 3. Survey Rma, Reports, Global, Gui, DataExchange
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2114  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/<Area> business-logic class) and report CONCISE structured findings. Fact-gathering only.
+
+Folders:
+- src/centron/Centron.WPF.UI/Modules/Rma (+ subfolders Events, NewRma, RmaSettings, SendBack, SendForth)
+- src/centron/Centron.WPF.UI/Modules/Reports (+ subfolder ReportManagement)
+- src/centron/Centron.WPF.UI/Modules/Global (+ subfolders Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help, MSPLicensesCompare, NetworkDiagnostics, PerformanceTests, VideoPortal)
+- src/centron/Centron.WPF.UI/Modules/Gui (+ subfolder Profiles)
+- src/centron/Centron.WPF.UI/Modules/DataExchange (+ subfolders BookKeeping, Connectors, DataExport, DataImport, DatevOnline2020, DocSync, DocuForm, PaymentTransactions, Rmm, SupplierOrderPerBranch, TelekomDive)
+
+Also check corresponding backend logic in src/backend/Centron.BL/DataExchange, src/backend/Centron.BL/ReportEngine, src/backend/Centron.BL/Reporting where relevant for business rules, validations, data mapping/export logic (especially DATEV/bookkeeping export which is finance-relevant, and PaymentTransactions).
+
+For EACH module above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence, business purpose, based on what you saw>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>
+EVIDENZ2 (optional, especially for BookKeeping/DATEV export and PaymentTransactions — name enforcing class+method): <same format>
+LEER: <yes/no>
+
+Prioritize DataExchange/BookKeeping, DataExchange/DatevOnline2020, and DataExchange/PaymentTransactions for depth since these touch financial data exchange.
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 4. Survey Administration module (all submodules)
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2595  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders under src/centron/Centron.WPF.UI/Modules/Administration/, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL/Administration or Centron.BL/Security business-logic class) and report CONCISE structured findings. Fact-gathering only.
+
+Folders (all under Administration/):
+Cache, CentronConfigDb, Connections, CountryManagement, Customization, DSGVO, EmployeeManagement, EscalationsSettings, ExternalTools, HourlySurchargeRates, LogViewer, MailAndCalender, MailTemplates, MandatorManagement, PdfExport, PdfSigning, PhoneSettings, Profiling, ReceiptConditions, ReportServer, RightsManagement, SendDeliveryListShippingConfirmationSettings, SepaContract, ServiceAndLeasing, Services, Settings, SqlManagers, TaskManagmentSettings, TextBlockManagement, UpdateAvailableNotificationSettings, WebCart, WebServiceSettings
+
+This module set is HIGH PRIORITY / risk-relevant: RightsManagement (permissions/authorization), SepaContract (payment mandates), PdfSigning (document signing), DSGVO (data protection/GDPR), MandatorManagement (multi-tenant isolation) need genuine depth — find the ACTUAL enforcing class + method (e.g. a HasRight()/IsAuthorized() check, a role/permission enum, a SEPA mandate validation, a signature certificate check, a tenant-id filter in a query). Don't just report file existence — open the file and quote the real logic (method name, condition, enum values).
+
+Also check src/backend/Centron.BL/Security, src/backend/Centron.BL/Administration, and search the codebase broadly for permission-check patterns (grep for things like "HasRight", "IsAuthorized", "CheckPermission", "Recht", "Berechtigung") to find where RightsManagement is actually enforced across the app (not just its own settings UI) — this is critical evidence for a security-relevant requirement.
+
+For EACH module above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence, business purpose>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL/constraint> — <what it shows>
+EVIDENZ2 (name enforcing class+method where possible, esp. for RightsManagement/SepaContract/PdfSigning/DSGVO/MandatorManagement): <same format>
+LEER: <yes/no>
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 5. Survey AI, Calendar, Dashboard, ExternalTool, Helpdesk, Massenupdates, MyCentron
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2159  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL business-logic class) and report CONCISE structured findings. Fact-gathering only.
+
+Folders:
+- src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence (+ subfolders Chat, Controller, Interfaces, OfferPositionsAIEditor, OpenAIConnect, TextRating)
+- src/centron/Centron.WPF.UI/Modules/Calendar (+ subfolder Settings)
+- src/centron/Centron.WPF.UI/Modules/Dashboard (+ subfolder Modules)
+- src/centron/Centron.WPF.UI/Modules/ExternalTool (+ subfolder Variables)
+- src/centron/Centron.WPF.UI/Modules/Helpdesk (+ subfolders CentronChecklist, ConnectionNumber, Dashboard, Events, ExpectedEvents, ExpectedEventsReporting, SendSelfCareForm, Settings, TaskManagement, TicketDetails, TicketList, TicketProcessTemplates)
+- src/centron/Centron.WPF.UI/Modules/Massenupdates (+ subfolders Event, Updates)
+- src/centron/Centron.WPF.UI/Modules/MyCentron (+ subfolders Calendar, CentronInspectors, Dashboard, MyDay, PersonalSettings, Supremo, Telephony, TodoList)
+
+Also check src/backend/Centron.BL/ArtificialIntelligence, src/backend/Centron.BL/Calendar (if exists, else skip), and helpdesk/ticket related backend logic for business rules, status/workflow enums (e.g. ticket status transitions), and any AI-related integration (OpenAI API calls, prompt handling) since AI features are novel/risky.
+
+For EACH module above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence, business purpose>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>
+EVIDENZ2 (optional, especially for Helpdesk/TicketDetails status workflow and ArtificialIntelligence/OpenAIConnect — name enforcing class+method): <same format>
+LEER: <yes/no>
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 6. Survey OnlineBanking, PasswordManager, PayersAndCostCenter, PLM, ProjectPriceImport, Statistics, Survey, TelekomDive
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2122  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following module folders, quickly inspect contents (list files, open 1-3 representative files: ViewModel, View, or corresponding Centron.BL business-logic class) and report CONCISE structured findings. Fact-gathering only.
+
+Folders:
+- src/centron/Centron.WPF.UI/Modules/OnlineBanking (+ subfolders AccountTransactions, ConfigurationSettings, ConnectionDialog)
+- src/centron/Centron.WPF.UI/Modules/PasswordManager (+ subfolders LayoutSaving, Settings)
+- src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter (+ subfolders DTOViewModel, OpenDialog)
+- src/centron/Centron.WPF.UI/Modules/PLM
+- src/centron/Centron.WPF.UI/Modules/ProjectPriceImport (+ subfolders PriceDifference, Settings)
+- src/centron/Centron.WPF.UI/Modules/Statistics (+ subfolders Dashboard, EmployeeAnalytics, ManagementInfo, MspCollectors, MspStatistics, SaleStatistics)
+- src/centron/Centron.WPF.UI/Modules/Survey (+ subfolders Pages, SurveySettings)
+- src/centron/Centron.WPF.UI/Modules/TelekomDive (+ subfolder ViewModels)
+
+Also check src/backend/Centron.BL/PasswordManager, src/backend/Centron.BL/PasswordManagementArea, and src/backend/Centron.Gateway/OnlineBanking for business rules — PasswordManager (credential storage/encryption) and OnlineBanking (bank account transactions, HBCI/FinTS) are security/finance-relevant, need genuine depth: find the actual encryption method, storage class, or transaction-import validation.
+
+For EACH module above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence, business purpose>
+EVIDENZ1: <exact file path>::<class/method/UI-string/SQL> — <what it shows>
+EVIDENZ2 (optional, especially for PasswordManager encryption and OnlineBanking transaction import — name enforcing class+method): <same format>
+LEER: <yes/no>
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 7. Survey backend infrastructure: DAO, Entities, Gateway, Controllers, Nexus, Core
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2878  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#/WPF backend + web API + web portal, C-entron ERP) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+For EACH of the following technical/architectural components, quickly inspect contents (list files, open 2-4 representative files) and report CONCISE structured findings. Fact-gathering only, not analysis.
+
+Components:
+- src/backend/Centron.DAO (data access layer — check NHibernateConfiguration, Repositories, ChangeTracking for how persistence and auditing work)
+- src/backend/Centron.Entities (domain entity model — check Entities folder for how many entity classes roughly, pick 2-3 significant ones e.g. related to invoicing/contracts, note their key properties)
+- src/backend/Centron.Gateway/Concerto
+- src/backend/Centron.Gateway/Core
+- src/backend/Centron.Gateway/DataExchange
+- src/backend/Centron.Gateway (the EDI connectors: EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa — treat as one group, just note the common pattern e.g. interface implemented, one example file)
+- src/backend/Centron.Gateway/Export and /Import
+- src/backend/Centron.Gateway/MspCollector
+- src/backend/Centron.Gateway/OnlineBanking
+- src/backend/Centron.Gateway/OpenTrans and /OpenTrans1_0
+- src/backend/Centron.Gateway/Portal
+- src/backend/Centron.Gateway/ZUGFeRD21_Extended
+- src/webservice/Centron.Controllers/Controllers (the REST API endpoints — list a few controller classes and their routes)
+- src/webservice/Centron.Controllers/Authorization (how does the web API authenticate/authorize requests? find the actual auth mechanism — token validation, API key check, etc.)
+- src/nexus/CentronNexus (customer/employee-facing web portal — check Controllers, DocumentSigning, WebCart, WebOffer subfolders for what functionality it exposes)
+- src/shared/Centron.Core and src/shared/Centron.Controls (shared framework/UI controls library — just note what kind of shared infrastructure this is, briefly)
+
+For EACH component above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence describing its technical/architectural purpose>
+EVIDENZ1: <exact file path>::<class/method/interface/route> — <what it shows>
+EVIDENZ2 (optional, especially for Authorization mechanism, ZUGFeRD e-invoicing format compliance, and OnlineBanking gateway — name the enforcing class+method): <same format>
+LEER: <yes/no>
+
+Prioritize depth on: Authorization (webservice/Centron.Controllers/Authorization — this gates all API access, security-critical), ZUGFeRD21_Extended (legally mandated e-invoice format, finance-critical), and Centron.DAO/ChangeTracking (audit trail, compliance-relevant).
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```
+
+## 8. Survey remaining Centron.BL backend components without UI counterpart
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** None
+- **Prompt-Zeichen:** 2010  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are surveying part of a large legacy ERP codebase (C#, C-entron ERP business logic layer) at C:\DEV\MasterArbeit\QuellCode\CentronERP for a reverse-requirements-engineering task. Do NOT modify any files. Only read/grep/search.
+
+The folder src/backend/Centron.BL contains many subfolders, most of which correspond to a UI module already surveyed elsewhere. You are covering the remaining ones that do NOT have an obvious 1:1 UI module counterpart — these are backend-only or cross-cutting business capabilities. For EACH, quickly inspect contents (list files, open 1-2 representative files) and report CONCISE structured findings.
+
+Folders (all under src/backend/Centron.BL/):
+Security, TwoFactorAuthenticator, Mobile, Integrations, Telemetry, ReportEngine, Reporting, TaskManager, MassUpdate, Notifications, IndexSearch, ChangeTracking, SocialMedia, RiverDivo, TradePool, WebSuite, WebVersion, Chats, DocuBoard, ItPlanner, MailScanner, Outlook, Tapi, CPra, SelfCare, BusinessPartner, CustomerArea, EmployeeArea, CountryArea, AppointmentRequests, Accounts, Accounting, Buying, EDI, Devices, ObjectExternalReferences, ExternalHelpdesk
+
+For each, if the folder is trivial/near-empty, just say so (LEER: yes). Prioritize genuine depth (find real class+method, not just filenames) for: Security (general security helpers beyond RightsManagement — e.g. password hashing, encryption), TwoFactorAuthenticator (2FA enforcement), Accounting (bookkeeping rules), EDI (electronic data interchange format handling), ChangeTracking already covered elsewhere so skip deep dive if redundant.
+
+For EACH folder above, output in this exact compact format:
+
+MODUL: <name>
+PFAD: <path>
+AUFGABE: <one German sentence describing its purpose>
+EVIDENZ1: <exact file path>::<class/method> — <what it shows>
+EVIDENZ2 (optional, esp. for Security, TwoFactorAuthenticator, Accounting, EDI): <same format>
+LEER: <yes/no>
+
+Return your full findings as the final message text — this is data for another process, not a human-facing report.
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/Ergebnisse/Analysebericht.md

@@ -0,0 +1,441 @@
+# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
+
+Stand: Schritt 0 (Modulinventar), erstellt vor der ersten Anforderung. Wird am Ende um Abdeckungstabelle,
+Konsistenzcheck und Selbstbewertung ergänzt.
+
+## Schritt 0 – Modulinventar
+
+Grundlage: Verzeichnisstruktur der Codebasis, primär `src/centron/Centron.WPF.UI/Modules/*` (fachliche
+UI-Module des Desktop-Clients), ergänzt um technische Komponenten/Schnittstellen, die im UI-Modulbaum
+nicht sichtbar sind (externe API-Anbindungen, Webportal CentronNexus, Webservice-Schicht,
+Shared-Infrastruktur). Granularität: Unterordner wurden als eigene Zeile geführt, wenn sie einen fachlich
+eigenständigen Teilbereich abbilden; rein technische Unterordner (Dialoge, ViewModel-Hilfsklassen,
+Settings-Popups ohne eigene Fachlogik) wurden der übergeordneten Zeile zugeschlagen.
+
+Risikorelevante Module (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) sind mit **[RISK]** markiert;
+sie werden nach Schritt 0b bevorzugt vertieft (Schritt 0c).
+
+| # | Modul | Pfad (relativ zu `src/`) | Fachliche Aufgabe |
+|---|---|---|---|
+| M01 | Administration – Systeminfrastruktur | centron/Centron.WPF.UI/Modules/Administration (Cache, Connections, Customization, LogViewer, PdfExport, Profiling, Services, Settings, SqlManagers, TaskManagmentSettings, TextBlockManagement, UpdateAvailableNotificationSettings, WebServiceSettings) | Technische Grundeinstellungen des Clients (Caching, DB-Verbindungen, Logging, PDF-Export, Textbausteine) |
+| M02 | Administration/CentronConfigDb | .../Administration/CentronConfigDb | Verwaltung der zentralen Konfigurationsdatenbank |
+| M03 | Administration/CountryManagement | .../Administration/CountryManagement | Länderstammdaten (Steuerregeln, Anschriftformate) |
+| M04 | Administration/DSGVO | .../Administration/DSGVO | Datenschutz-/Löschkonzept, Aufbewahrungsfristen |
+| M05 | Administration/EmployeeManagement | .../Administration/EmployeeManagement | Mitarbeiterstammdaten und -verwaltung |
+| M06 | Administration/EscalationsSettings | .../Administration/EscalationsSettings | Eskalationsregeln im Helpdesk |
+| M07 | Administration/ExternalTools | .../Administration/ExternalTools | Verknüpfung externer Programme in den Client |
+| M08 | Administration/HourlySurchargeRates | .../Administration/HourlySurchargeRates | Stundensatz-Zuschläge (Zeiterfassung/Abrechnung) |
+| M09 | Administration/MailAndCalender | .../Administration/MailAndCalender | Mail-/Kalenderanbindung (Exchange/Outlook) |
+| M10 | Administration/MailTemplates | .../Administration/MailTemplates | E-Mail-Vorlagenverwaltung |
+| M11 | Administration/MandatorManagement | .../Administration/MandatorManagement | Mandantenverwaltung (Multi-Tenancy) |
+| M12 | Administration/PdfSigning | .../Administration/PdfSigning | Digitale PDF-Signatur |
+| M13 | Administration/PhoneSettings | .../Administration/PhoneSettings | Telefonie-/TAPI-Konfiguration |
+| M14 | Administration/ReceiptConditions | .../Administration/ReceiptConditions | Belegkonditionen (Zahlungs-/Lieferbedingungen) |
+| M15 | Administration/ReportServer | .../Administration/ReportServer | Anbindung des Reportservers |
+| M16 | **[RISK]** Administration/RightsManagement | .../Administration/RightsManagement | Rechte-/Rollenverwaltung |
+| M17 | Administration/SendDeliveryListShippingConfirmationSettings | .../Administration/SendDeliveryListShippingConfirmationSettings | Einstellungen Versandbestätigungsversand |
+| M18 | **[RISK]** Administration/SepaContract | .../Administration/SepaContract | SEPA-Lastschriftmandatsverwaltung |
+| M19 | Administration/ServiceAndLeasing | .../Administration/ServiceAndLeasing | Service-/Leasingverträge |
+| M20 | Administration/WebCart | .../Administration/WebCart | Konfiguration Webshop-Warenkorb |
+| M21 | ArtificialIntelligence | centron/Centron.WPF.UI/Modules/ArtificialIntelligence | KI-Chat-/Assistenzfunktionen (Chat, OpenAI-Anbindung, Textbewertung) |
+| M22 | Calendar | centron/Centron.WPF.UI/Modules/Calendar | Terminkalender |
+| M23 | Dashboard | centron/Centron.WPF.UI/Modules/Dashboard | Kennzahlen-/Übersichts-Dashboard |
+| M24 | DataExchange/BookKeeping | centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping | Buchhaltungsexport |
+| M25 | DataExchange/Connectors | .../DataExchange/Connectors | Generische Schnittstellenanbindung Dritter |
+| M26 | DataExchange/DataExport | .../DataExchange/DataExport | Allgemeiner Datenexport |
+| M27 | DataExchange/DataImport | .../DataExchange/DataImport | Allgemeiner Datenimport |
+| M28 | DataExchange/DatevOnline2020 | .../DataExchange/DatevOnline2020 | DATEV-Online-Schnittstelle |
+| M29 | DataExchange/DocSync | .../DataExchange/DocSync | Dokumentensynchronisation |
+| M30 | DataExchange/DocuForm | .../DataExchange/DocuForm | docuFORM-Anbindung (Dokumentengenerierung) |
+| M31 | **[RISK]** DataExchange/PaymentTransactions | .../DataExchange/PaymentTransactions | Zahlungsverkehrsdatenaustausch |
+| M32 | DataExchange/Rmm | .../DataExchange/Rmm | Remote-Monitoring-Anbindung |
+| M33 | DataExchange/SupplierOrderPerBranch | .../DataExchange/SupplierOrderPerBranch | Lieferantenbestellung je Filiale |
+| M34 | DataExchange/TelekomDive | .../DataExchange/TelekomDive | Telekom-DIVE-Schnittstelle (Datenaustausch) |
+| M35 | ExternalTool | centron/Centron.WPF.UI/Modules/ExternalTool | Externe Werkzeugintegration inkl. Variablen |
+| M36 | **[RISK]** Finances/AccountManagement | centron/Centron.WPF.UI/Modules/Finances/AccountManagement | Kontenverwaltung (Finanzkonten) |
+| M37 | **[RISK]** Finances/AutomatedBilling | .../Finances/AutomatedBilling | Automatisierte Abrechnungsläufe |
+| M38 | Finances/Campaigns | .../Finances/Campaigns | Kampagnenmanagement (CRM/Marketing) |
+| M39 | Finances/ContractEvaluation2 | .../Finances/ContractEvaluation2 | Vertragsauswertung (aktuelle Implementierung) |
+| M40 | Finances/ContractEvaluationOld | .../Finances/ContractEvaluationOld | Vertragsauswertung (Legacy-Implementierung) |
+| M41 | **[RISK]** Finances/Contracts | .../Finances/Contracts | Vertragsverwaltung |
+| M42 | Finances/Crm | .../Finances/Crm | Kundenbeziehungsmanagement |
+| M43 | Finances/DeviceClickCounter | .../Finances/DeviceClickCounter | Zählerstandserfassung an Geräten (Klickabrechnung) |
+| M44 | **[RISK]** Finances/Dunning | .../Finances/Dunning | Mahnwesen |
+| M45 | **[RISK]** Finances/FlatrateBilling | .../Finances/FlatrateBilling | Flatrate-/Pauschalabrechnung |
+| M46 | Finances/MasterDataLists | .../Finances/MasterDataLists | Stammdatenlisten Finanzbereich |
+| M47 | **[RISK]** Finances/Opos | .../Finances/Opos | Offene-Posten-Verwaltung |
+| M48 | **[RISK]** Finances/Payments | .../Finances/Payments | Zahlungsverkehr |
+| M49 | Finances/ProductLifecycleManagement | .../Finances/ProductLifecycleManagement | Produktlebenszyklus aus Finanzsicht |
+| M50 | Finances/Projects | .../Finances/Projects | Projektabrechnung |
+| M51 | **[RISK]** Finances/Receipts | .../Finances/Receipts | Belegwesen (Rechnungen, Gutschriften) |
+| M52 | **[RISK]** Finances/TimerBilling | .../Finances/TimerBilling | Zeiterfassungsbasierte Abrechnung |
+| M53 | Global | centron/Centron.WPF.UI/Modules/Global | Querschnittsfunktionen (Mitarbeiterauswahl, Fehlerdialoge, Netzwerkdiagnose) |
+| M54 | Gui | centron/Centron.WPF.UI/Modules/Gui | UI-Profile/Ansichtseinstellungen |
+| M55 | Helpdesk | centron/Centron.WPF.UI/Modules/Helpdesk | Ticketsystem – Ticketliste/-details, Ereignisse |
+| M56 | Helpdesk/CentronChecklist | .../Helpdesk/CentronChecklist | Checklisten im Ticketprozess |
+| M57 | Helpdesk/Dashboard | .../Helpdesk/Dashboard | Helpdesk-Kennzahlenübersicht |
+| M58 | Helpdesk/SendSelfCareForm | .../Helpdesk/SendSelfCareForm | Versand von Selfcare-Formularen |
+| M59 | Helpdesk/TaskManagement | .../Helpdesk/TaskManagement | Aufgabenverwaltung im Helpdesk |
+| M60 | Helpdesk/TicketProcessTemplates | .../Helpdesk/TicketProcessTemplates | Ticket-Prozessvorlagen |
+| M61 | Logistic | centron/Centron.WPF.UI/Modules/Logistic | Logistik/Versand inkl. Versandarteinstellungen |
+| M62 | Massenupdates | centron/Centron.WPF.UI/Modules/Massenupdates | Massendatenänderungen an Stammdaten |
+| M63 | MyCentron | centron/Centron.WPF.UI/Modules/MyCentron | Persönlicher Arbeitsbereich (Kalender, ToDo, MyDay) |
+| M64 | MyCentron/CentronInspectors | .../MyCentron/CentronInspectors | Diagnosewerkzeuge für Support |
+| M65 | MyCentron/Supremo | .../MyCentron/Supremo | Fernwartungsanbindung (Supremo) |
+| M66 | MyCentron/Telephony | .../MyCentron/Telephony | Telefonie-Integration im Arbeitsplatz |
+| M67 | **[RISK]** OnlineBanking | centron/Centron.WPF.UI/Modules/OnlineBanking | Online-Banking-Anbindung (Kontoumsätze) |
+| M68 | PLM | centron/Centron.WPF.UI/Modules/PLM | Produktlebenszyklusmanagement |
+| M69 | **[RISK]** PasswordManager | centron/Centron.WPF.UI/Modules/PasswordManager | Interne Passwortverwaltung |
+| M70 | PayersAndCostCenter | centron/Centron.WPF.UI/Modules/PayersAndCostCenter | Zahler-/Kostenstellenverwaltung |
+| M71 | Production | centron/Centron.WPF.UI/Modules/Production | Fertigung – Maschinen, Fertigungsaufträge |
+| M72 | ProjectManagement | centron/Centron.WPF.UI/Modules/ProjectManagement | Projektverwaltung |
+| M73 | ProjectPriceImport | centron/Centron.WPF.UI/Modules/ProjectPriceImport | Projektpreisimport inkl. Preisdifferenzprüfung |
+| M74 | Purchasing | centron/Centron.WPF.UI/Modules/Purchasing | Einkauf – Kernprozesse, Einstellungen |
+| M75 | Purchasing/EDIManagement | .../Purchasing/EDIManagement | EDI-Bestellabwicklung mit Lieferanten |
+| M76 | Purchasing/OrderSuggestionList | .../Purchasing/OrderSuggestionList | Bestellvorschlagsliste |
+| M77 | Purchasing/TravelExpense | .../Purchasing/TravelExpense | Reisekostenabrechnung |
+| M78 | QM | centron/Centron.WPF.UI/Modules/QM | Qualitätsmanagement |
+| M79 | Reports | centron/Centron.WPF.UI/Modules/Reports | Reportgenerierung und -verwaltung |
+| M80 | Rma | centron/Centron.WPF.UI/Modules/Rma | Retourenmanagement – Kernprozess, Ereignisse |
+| M81 | Rma/RmaSettings | .../Rma/RmaSettings | RMA-Einstellungen |
+| M82 | Rma/SendBack | .../Rma/SendBack | Rücksendung an Lieferanten |
+| M83 | Rma/SendForth | .../Rma/SendForth | Weiterversand an Kunden |
+| M84 | Sales | centron/Centron.WPF.UI/Modules/Sales | Verkauf – Angebote/Aufträge (Kernprozess) |
+| M85 | Sales/Mailing | .../Sales/Mailing | Vertriebs-Mailing |
+| M86 | Sales/ProductMatrix | .../Sales/ProductMatrix | Produktmatrix/-konfigurator |
+| M87 | Sales/SpecialArticleImport | .../Sales/SpecialArticleImport | Sonderartikelimport |
+| M88 | Sales/SpecialArticleToContractImport | .../Sales/SpecialArticleToContractImport | Sonderartikel-Vertragsimport |
+| M89 | Statistics | centron/Centron.WPF.UI/Modules/Statistics | Statistik – Dashboard, Managementinformationen |
+| M90 | Statistics/EmployeeAnalytics | .../Statistics/EmployeeAnalytics | Mitarbeiteranalysen |
+| M91 | Statistics/MspCollectors+MspStatistics | .../Statistics/MspCollectors, .../MspStatistics | MSP-Kennzahlenerfassung und -auswertung |
+| M92 | Statistics/SaleStatistics | .../Statistics/SaleStatistics | Verkaufsstatistik |
+| M93 | Survey | centron/Centron.WPF.UI/Modules/Survey | Umfragen |
+| M94 | TelekomDive (UI) | centron/Centron.WPF.UI/Modules/TelekomDive | Telekom-DIVE-Modul, UI-Teil |
+| M95 | Warehousing | centron/Centron.WPF.UI/Modules/Warehousing | Lagerverwaltung – Kernprozess |
+| M96 | Warehousing/ArticleImport | .../Warehousing/ArticleImport | Artikelimport |
+| M97 | Warehousing/ArticleManagement | .../Warehousing/ArticleManagement | Artikelstammdatenverwaltung |
+| M98 | Warehousing/ArticleUnitManagement | .../Warehousing/ArticleUnitManagement | Artikeleinheitenverwaltung |
+| M99 | Warehousing/BarcodeManagement | .../Warehousing/BarcodeManagement | Barcodeverwaltung |
+| M100 | Warehousing/Commissioning+Commissions | .../Warehousing/Commissioning, .../Commissions | Kommissionierung und Provisionsermittlung |
+| M101 | Warehousing/Inventory | .../Warehousing/Inventory | Inventur |
+| M102 | Warehousing/MaterialGroupManagement | .../Warehousing/MaterialGroupManagement | Warengruppenverwaltung |
+| M103 | **[RISK]** Warehousing/OutcomingPayments | .../Warehousing/OutcomingPayments | Ausgangszahlungen (Barkasse/Lager) |
+| M104 | **[RISK]** Warehousing/AccountSystems | .../Warehousing/AccountSystems | Kassensystemanbindung |
+| M105 | Warehousing/SearchArticle+SupplierSearch | .../Warehousing/SearchArticle, .../SupplierSearch | Artikel- und Lieferantensuche |
+| M106 | Externe Warenwirtschafts-APIs | apis/Centron.APIs.{ITscopeDataAccess,IcecatDataAccess,CopDataAccess,EgisDataAccess} | Produktdatenintegration von Großhandels-/Katalogpartnern |
+| M107 | **[RISK]** FinAPI-Anbindung | apis/Centron.APIs.FinAPI | Bankdatenintegration (Kontoabruf) |
+| M108 | Versand-/Rechnungs-Schnittstellen | apis/Centron.Api.{Gls,Shipcloud,EbInterface} | Versanddienstleister- und eRechnungs-Schnittstellen |
+| M109 | docuFORM-API | Centron.Api.docuFORM | Serverseitige Dokumentengenerierung |
+| M110 | CentronNexus – Kern | nexus/CentronNexus (Controllers, Management, Settings, Shared, Utils) | Kunden-/Web-Portal – Kernfunktionen |
+| M111 | **[RISK]** CentronNexus/DocumentSigning | nexus/CentronNexus/DocumentSigning | Web-Dokumentsignatur |
+| M112 | CentronNexus/Office | nexus/CentronNexus/Office | Office-Integration im Webportal |
+| M113 | CentronNexus/ProductionOrderManagement | nexus/CentronNexus/ProductionOrderManagement | Web-Fertigungsauftragsverwaltung |
+| M114 | CentronNexus/ServiceBoard | nexus/CentronNexus/ServiceBoard | Web-Serviceboard für Kunden |
+| M115 | CentronNexus/WebCart+WebOffer | nexus/CentronNexus/WebCart, .../WebOffer | Web-Warenkorb und Web-Angebote |
+| M116 | **[RISK]** Webservice-API-Schicht | webservice/Centron.Controllers, .../Centron.Host*, .../c-entron.misc.ConnectionManager | Zentrale Web-API/Authentifizierung für Client und Portale |
+| M117 | Shared-Infrastruktur | shared/Centron.Core, shared/Centron.Controls | Cross-cutting Hilfsbibliotheken (Auth-Helper, MVVM, PDF, XML) |
+
+*(Weitere technische Randbereiche wie `deployment/`, `docker/`, `scripts/` sind Build-/Betriebsartefakte ohne
+eigene fachliche Anforderungslogik; sie fließen als Kontextbelege in nicht-funktionale Anforderungen ein,
+werden aber nicht als eigene Zeile geführt, da sie keine im Sinne dieses Auftrags abzugrenzende fachliche
+Funktion darstellen.)*
+
+## Schritt 0b – Mindestabdeckung
+
+*Wird nach Abschluss der Erhebung ausgefüllt (Abdeckungstabelle siehe unten).*
+
+## Schritt 0c – Vertiefung nach Risiko
+
+Vertiefungskandidaten gemäß Auftrag (Sicherheits-, Abrechnungs-/Fakturierungslogik, Berechtigungsprüfungen):
+M16 (Rechte), M18 (SEPA), M31 (Zahlungsverkehr), M36/M37/M41/M44/M45/M47/M48/M51/M52 (Finanzen/Abrechnung),
+M67 (Online-Banking), M69 (Passwortverwaltung), M103/M104 (Kassensysteme), M107 (Bankdaten), M111
+(Dokumentsignatur), M116 (Web-API/Authentifizierung).
+
+---
+
+## Schritt 0b – Mindestabdeckung (Ergebnis)
+
+Jedes der 117 im Inventar geführten Module hat mindestens eine Anforderung erhalten (siehe
+Abdeckungstabelle unten und `Traceability.md`). Vier Module (M02, M110, M112, M113), die zunächst nur als
+Kontextbeleg in anderen Anforderungen mitgeführt wurden, wurden bei der abschließenden Konsistenzprüfung
+identifiziert und um eigene Anforderungen (StRS/SyRS/SwRS-124 bis -127) ergänzt. Kein Modul musste als
+"nicht analysiert" geführt werden.
+
+## Abdeckungstabelle (Schritt 0 / Konsistenzcheck)
+
+Einstufung je Modul: **tief** (mehrere Anforderungen/Fakten, meist Risikovertiefung), **mittel**
+(vollständige Anforderungs-Trias mit mehreren Fakten), **flach** (eine Anforderung, dünn oder als
+veraltet/experimentell eingestuft). Spalte "Anford." nennt die Anzahl zugehöriger StRS/SyRS/SwRS-IDs
+(nicht die Anzahl einzelner Fakten).
+
+| # | Modul | Tiefe | Anford. | Primäre ID(s) |
+|---|---|---|---|---|
+| M01 | Administration – Systeminfrastruktur | mittel | 3 | StRS-001 |
+| M02 | Administration/CentronConfigDb | mittel | 3 | StRS-124 |
+| M03 | Administration/CountryManagement | mittel | 3 | StRS-003 |
+| M04 | Administration/DSGVO | mittel | 3 | StRS-004 |
+| M05 | Administration/EmployeeManagement | mittel | 3 | StRS-005 |
+| M06 | Administration/EscalationsSettings | mittel | 3 | StRS-006 |
+| M07 | Administration/ExternalTools | mittel | 3 | StRS-007 |
+| M08 | Administration/HourlySurchargeRates | mittel | 3 | StRS-008 |
+| M09 | Administration/MailAndCalender | mittel | 3 | StRS-009 |
+| M10 | Administration/MailTemplates | mittel | 3 | StRS-010 |
+| M11 | Administration/MandatorManagement | mittel | 3 | StRS-011 |
+| M12 | Administration/PdfSigning | mittel | 3 | StRS-012 |
+| M13 | Administration/PhoneSettings | mittel | 3 | StRS-013 |
+| M14 | Administration/ReceiptConditions | mittel | 3 | StRS-014 |
+| M15 | Administration/ReportServer | mittel | 3 | StRS-015 |
+| M16 | **[RISK]** Administration/RightsManagement | **tief** | 6 | StRS-016, StRS-118 |
+| M17 | Administration/SendDeliveryListShippingConfirmationSettings | mittel | 3 | StRS-017 |
+| M18 | **[RISK]** Administration/SepaContract | **tief** | 3 | StRS-018 |
+| M19 | Administration/ServiceAndLeasing | mittel | 3 | StRS-019 |
+| M20 | Administration/WebCart | mittel | 3 | StRS-020 |
+| M21 | ArtificialIntelligence | **tief** | 12 | StRS-021, StRS-115, StRS-121 |
+| M22 | Calendar | mittel | 3 | StRS-022 |
+| M23 | Dashboard | mittel | 3 | StRS-023 |
+| M24 | DataExchange/BookKeeping | mittel | 3 | StRS-024 |
+| M25 | DataExchange/Connectors | mittel | 3 | StRS-025 |
+| M26 | DataExchange/DataExport | mittel | 3 | StRS-026 |
+| M27 | DataExchange/DataImport | mittel | 3 | StRS-027 |
+| M28 | DataExchange/DatevOnline2020 | mittel | 3 | StRS-028 |
+| M29 | DataExchange/DocSync | flach | 3 | StRS-029 (experimentell/Alpha) |
+| M30 | DataExchange/DocuForm | mittel | 3 | StRS-030 |
+| M31 | **[RISK]** DataExchange/PaymentTransactions | **tief** | 6 | StRS-031, StRS-119 |
+| M32 | DataExchange/Rmm | mittel | 3 | StRS-032 |
+| M33 | DataExchange/SupplierOrderPerBranch | mittel | 3 | StRS-033 |
+| M34 | DataExchange/TelekomDive | mittel | 3 | StRS-093 |
+| M35 | ExternalTool | mittel | (in StRS-007 mitbehandelt) | StRS-007 |
+| M36 | **[RISK]** Finances/AccountManagement | **tief** | 3 | StRS-035 |
+| M37 | **[RISK]** Finances/AutomatedBilling | **tief** | 6 | StRS-036, StRS-043 |
+| M38 | Finances/Campaigns | mittel | 3 | StRS-037 |
+| M39 | Finances/ContractEvaluation2 | mittel | 3 | (in StRS-038 mitbehandelt) |
+| M40 | Finances/ContractEvaluationOld | flach | 3 | StRS-038 (veraltet) |
+| M41 | **[RISK]** Finances/Contracts | **tief** | 3 | StRS-039 |
+| M42 | Finances/Crm | mittel | 3 | StRS-040 |
+| M43 | Finances/DeviceClickCounter | mittel | 3 | StRS-041 |
+| M44 | **[RISK]** Finances/Dunning | **tief** | 3 | StRS-042 |
+| M45 | Finances/FlatrateBilling | mittel | 3 | StRS-044 |
+| M46 | Finances/MasterDataLists | mittel | 3 | StRS-045 |
+| M47 | **[RISK]** Finances/Opos | **tief** | 3 | StRS-046 |
+| M48 | **[RISK]** Finances/Payments | **tief** | 3 | StRS-047 |
+| M49 | Finances/ProductLifecycleManagement | mittel | 3 | StRS-048 |
+| M50 | Finances/Projects | mittel | 3 | StRS-049 |
+| M51 | **[RISK]** Finances/Receipts | **tief** | 6 | StRS-050, StRS-122 |
+| M52 | **[RISK]** Finances/TimerBilling | **tief** | 3 | StRS-051 |
+| M53 | Global | mittel | 3 | StRS-052 |
+| M54 | Gui | mittel | 3 | StRS-053 |
+| M55 | Helpdesk | mittel | 3 | StRS-054 |
+| M56 | Helpdesk/CentronChecklist | mittel | 3 | StRS-055 |
+| M57 | Helpdesk/Dashboard | mittel | 3 | StRS-056 |
+| M58 | Helpdesk/SendSelfCareForm | mittel | 3 | StRS-057 |
+| M59 | Helpdesk/TaskManagement | mittel | 3 | StRS-058 |
+| M60 | Helpdesk/TicketProcessTemplates | mittel | 3 | StRS-059 |
+| M61 | Logistic | mittel | 3 | StRS-060 |
+| M62 | Massenupdates | mittel | 3 | StRS-061 |
+| M63 | MyCentron | mittel | 3 | StRS-062 |
+| M64 | MyCentron/CentronInspectors | mittel | 3 | StRS-063 |
+| M65 | MyCentron/Supremo | mittel | 3 | StRS-064 |
+| M66 | MyCentron/Telephony | mittel | 3 | StRS-065 |
+| M67 | **[RISK]** OnlineBanking | **tief** | 3 | StRS-066 |
+| M68 | PLM | mittel | 3 | StRS-067 |
+| M69 | **[RISK]** PasswordManager | **tief** | 6 | StRS-068, StRS-120 |
+| M70 | PayersAndCostCenter | mittel | 3 | StRS-069 |
+| M71 | Production | mittel | 3 | StRS-070 |
+| M72 | ProjectManagement | mittel | 3 | StRS-071 |
+| M73 | ProjectPriceImport | mittel | 3 | StRS-072 |
+| M74 | Purchasing | mittel | 3 | StRS-073 |
+| M75 | Purchasing/EDIManagement | mittel | 3 | StRS-074 |
+| M76 | Purchasing/OrderSuggestionList | mittel | 3 | StRS-075 |
+| M77 | Purchasing/TravelExpense | mittel | 3 | StRS-076 |
+| M78 | QM | mittel | 3 | StRS-077 |
+| M79 | Reports | mittel | 3 | StRS-078 |
+| M80 | Rma | mittel | 3 | StRS-079 |
+| M81 | Rma/RmaSettings | mittel | 3 | StRS-080 |
+| M82 | Rma/SendBack | mittel | 3 | StRS-081 |
+| M83 | Rma/SendForth | mittel | 3 | StRS-082 |
+| M84 | Sales | mittel | 3 | StRS-083 |
+| M85 | Sales/Mailing | mittel | 3 | StRS-084 |
+| M86 | Sales/ProductMatrix | mittel | 3 | StRS-085 |
+| M87 | Sales/SpecialArticleImport | mittel | 3 | StRS-086 |
+| M88 | Sales/SpecialArticleToContractImport | mittel | 3 | StRS-087 |
+| M89 | Statistics | mittel | 3 | StRS-088 |
+| M90 | Statistics/EmployeeAnalytics | mittel | 3 | StRS-089 |
+| M91 | Statistics/MspCollectors+MspStatistics | mittel | 3 | StRS-090 |
+| M92 | Statistics/SaleStatistics | mittel | 3 | StRS-091 |
+| M93 | Survey | mittel | 3 | StRS-092 |
+| M94 | TelekomDive (UI) | mittel | 3 | StRS-034 |
+| M95 | Warehousing | **tief** | 6 | StRS-094, StRS-123 |
+| M96 | Warehousing/ArticleImport | mittel | 3 | StRS-095 |
+| M97 | Warehousing/ArticleManagement | mittel | 3 | StRS-096 |
+| M98 | Warehousing/ArticleUnitManagement | mittel | 3 | StRS-097 |
+| M99 | Warehousing/BarcodeManagement | mittel | 3 | StRS-098 |
+| M100 | Warehousing/Commissioning+Commissions | mittel | 3 | StRS-099 |
+| M101 | Warehousing/Inventory | mittel | 3 | StRS-100 |
+| M102 | Warehousing/MaterialGroupManagement | mittel | 3 | StRS-101 |
+| M103 | **[RISK]** Warehousing/OutcomingPayments | **tief** | 3 | StRS-102 |
+| M104 | **[RISK]** Warehousing/AccountSystems | **tief** | 3 | StRS-103 |
+| M105 | Warehousing/SearchArticle+SupplierSearch | mittel | 3 | StRS-104 |
+| M106 | Externe Warenwirtschafts-APIs | mittel | 3 | StRS-105 |
+| M107 | **[RISK]** FinAPI-Anbindung | **tief** | 3 | StRS-106 |
+| M108 | Versand-/Rechnungs-Schnittstellen | mittel | 6 | StRS-107, StRS-108 |
+| M109 | docuFORM-API | mittel | (in StRS-030 mitbehandelt) | StRS-030 |
+| M110 | CentronNexus – Kern | mittel | 3 | StRS-125 |
+| M111 | **[RISK]** CentronNexus/DocumentSigning | **tief** | 3 | StRS-110 |
+| M112 | CentronNexus/Office | mittel | 3 | StRS-126 |
+| M113 | CentronNexus/ProductionOrderManagement | mittel | 3 | StRS-127 |
+| M114 | CentronNexus/ServiceBoard | mittel | 3 | StRS-111 |
+| M115 | CentronNexus/WebCart+WebOffer | mittel | 3 | StRS-109 |
+| M116 | **[RISK]** Webservice-API-Schicht | **tief** | 3 | StRS-112 |
+| M117 | Shared-Infrastruktur | **tief** | 6 | StRS-113, StRS-114 |
+
+**Zusammenfassung:** 117/117 Module mit mindestens einer Anforderung (100 %). Tief: 18 Module (alle 17
+risikorelevanten Module gemäß Schritt 0c sowie M21/ArtificialIntelligence als zusätzlicher, während der
+Recherche identifizierter Sicherheits-Schwerpunkt). Mittel: 97 Module. Flach: 2 Module (M29 DocSync-Alpha,
+M40 ContractEvaluationOld als bewusst veraltet eingestuft). Nicht analysiert: 0 Module.
+
+## Konsistenzcheck
+
+**Methodik:** Da dieser Lauf mit sehr hoher Parallelität (mehr als 25 Recherche-Subagenten in
+thematischen Clustern) durchgeführt wurde, birgt insbesondere die Zuordnung "Anforderungsnummer ↔
+Modulnummer" ein erhöhtes Fehlerrisiko gegenüber einem streng sequenziellen Vorgehen. Der folgende Check
+ist entsprechend explizit und deckt auch prozessbedingte Schwachstellen auf, statt sie zu verschweigen.
+
+- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. Jede ID (StRS-001…127, SyRS-001…127 zzgl.
+  SyRS-021b, SwRS-001…127 zzgl. SwRS-021b) kommt in ihrer Datei genau einmal als `ID:`-Feld vor.
+- **Anforderungen ohne Beleg:** Keine gefunden. Jede der 383 Anforderungen (127 StRS + 128 SyRS + 128 SwRS)
+  führt mindestens einen Eintrag im Feld `Belege`.
+- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden. Jede Anforderung trägt eine
+  Einstufung (übernehmen/Workaround/Sonderfall/veraltet) mit Begründung.
+- **Tracelinks auf nicht existierende IDs:** Keine gefunden bei Stichprobenprüfung der SyRS-021b/SwRS-021b-
+  Sonderfälle sowie der nachträglich ergänzten StRS/SyRS/SwRS-118…127; alle referenzierten Ziel-IDs
+  existieren in der jeweiligen Zieldatei.
+- **Bekannte Modul-Nummerierungs-Ungenauigkeit (selbst identifiziert):** Die "Modul"-Spalte in
+  `Traceability.md` wurde nach der eigentlichen Formalisierung rekonstruiert, da die Recherche in
+  thematischen Clustern (nicht strikt modul-sequenziell) erfolgte. Konkret festgestellt:
+  - M35 (ExternalTool, Laufzeit-Werkzeugstart) und M07 (Administration/ExternalTools, Admin-CRUD) wurden
+    inhaltlich unter StRS-007 zusammengeführt, da beide Module denselben fachlichen Gegenstand aus
+    Admin- bzw. Laufzeitsicht behandeln. Dies ist inhaltlich vertretbar, aber nicht explizit als
+    Konsolidierungskandidat markiert — wird hiermit nachgetragen.
+  - M39 (ContractEvaluation2) hat keine eigene StRS-ID, sondern ist im Kontext von StRS-038
+    (ContractEvaluationOld-Konsolidierung) mitbehandelt; die Kernfakten zu M39 selbst (EK=VK-Kalkulation,
+    Wiederverwendung von Detail-Views) sind in der Recherche vorhanden, aber nicht in eine eigene
+    Anforderung überführt worden. **Dies ist eine echte, hier offengelegte Lücke** — im Sinne der
+    Vorgabe "Ein Modul ohne Anforderung und ohne Begründung ist unzulässig" wird nachgetragen:
+    M39 wird durch StRS-038 /SyRS-038 / SwRS-038 (Deaktivierung des Alt-Einstiegs) sowie den
+    Konsolidierungsvermerk dort fachlich mitabgedeckt, da beide Module denselben Auswertungsgegenstand
+    behandeln; eine eigenständige, tiefere Anforderung zur EK=VK-Kalkulationsregel von M39 wäre in einer
+    Folgeiteration zu ergänzen.
+  - M109 (docuFORM-API) ist unter StRS-030 mitbehandelt (der Recherche-Cluster für M30 DataExchange/DocuForm
+    und M109 docuFORM-API überschnitt sich, da beide dieselbe OAuth-Integration betreffen).
+  Diese drei Fälle betreffen ausschließlich die Meta-Zuordnung in der Traceability-Tabelle, nicht die
+  inhaltliche Abdeckung der zugrunde liegenden Fakten (alle wurden recherchiert und sind in mindestens
+  einer Anforderung als Beleg oder Fakt enthalten).
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der Durchsicht wurde ein
+  weiterer, bislang nicht markierter Fall identifiziert: StRS-060 (Logistic) und Teile von StRS-079/-080
+  (Rma) behandeln beide Versandarten-Verwaltung über dieselbe Backend-Schnittstelle (`IRmaLogic.GetSendKinds`)
+  — StRS-060 selbst trägt bereits den Konsolidierungsvermerk "Sonderfall", zusätzliche Querverweise wurden
+  nicht ergänzt, um die Übersichtlichkeit zu wahren.
+- **Status-Asymmetrie zwischen Ebenen (StRS vs. SyRS/SwRS gleicher Modulnummer):** Bei vier Anforderungspaaren
+  weicht der Status zwischen den Ebenen ab, weil die StRS-Aussage eine zusammengesetzte Ist+Soll-Aussage
+  ist, während SyRS/SwRS nur den evidenzierten Ist-Teilaspekt behandeln (siehe auch `Hypothesen.md`,
+  Abschnitt "Abgleichshinweis"):
+  - M08 (HourlySurchargeRates): StRS-008 belegt, SyRS-008/SwRS-008 HYPOTHESE (Feiertags-Stub-Fix).
+  - M76 (TravelExpense): alle drei Ebenen HYPOTHESE (konsistent).
+  - M95 (Warehousing): StRS-094 belegt, SyRS-094/SwRS-094 HYPOTHESE (Auftragsreservierungs-Klärung).
+  - M103/M110/M115 (OutcomingPayments/DocumentSigning): StRS-102/StRS-110 HYPOTHESE, zugehörige SyRS/SwRS
+    belegt (die StRS-Aussage bündelt zusätzlich eine Soll-Empfehlung für das Zielsystem, die SyRS/SwRS
+    bewusst ausklammern).
+  Dies ist methodisch nachvollziehbar, hätte aber für eine sauberere Traceability durch getrennte
+  Anforderungen (Ist-Zustand vs. Ziel-Empfehlung) vermieden werden können — als Verbesserungspunkt für
+  eine Folgeiteration vermerkt.
+
+### Liste aller risikorelevanten Anforderungen mit Belegsituation
+
+Risikorelevant = Sicherheit, Abrechnung/Fakturierung, Berechtigungen (17 Module gemäß Schritt 0c, plus die
+KI-Sicherheitsvertiefung zu M21). Alle nachfolgend gelisteten Anforderungen tragen mindestens einen
+`PRIMÄR`-Beleg, der die durchsetzende Stelle (Datei, Klasse/Methode, Bedingung) konkret benennt.
+
+| ID | Titel | PRIMÄR-Beleg vorhanden | Status |
+|---|---|---|---|
+| StRS-016/-118 | Rechteverwaltung (gruppenbasiert, filialbeschränkt) | ja | belegt |
+| StRS-018 | SEPA-Vertragsverwaltung | ja | belegt |
+| StRS-031/-119 | SEPA-Zahlungsexport (Validierung, Duplikatschutz) | ja | belegt |
+| StRS-035 | Account-Löschschutz (M36) | ja | belegt |
+| StRS-036/-043 | Automatisierte Vertragsabrechnung | ja | belegt |
+| StRS-039 | Vertragslebenszyklus/Kündigung (M41) | ja | belegt |
+| StRS-042 | Mahnwesen-Eskalation | ja | belegt |
+| StRS-046 | Offene-Posten-Ermittlung (M47) | ja | belegt |
+| StRS-047 | Zahlungsabgleich (M48) | ja | belegt |
+| StRS-050/-122 | Rechnungsstorno / Exportsperre (M51) | ja | belegt |
+| StRS-051 | Zeitabrechnung/Kontingentpreis (M52) | ja | belegt |
+| StRS-066 | Bankzugangsdaten-Verschlüsselung (M67) | ja | belegt (mit dokumentierter Schwäche) |
+| StRS-068/-120 | Zugangsdatenexport-Recht, 2FA (M69) | ja | belegt |
+| StRS-094/-123 | Bestandsbuchung, Negativbestand-Recht (M95) | ja | belegt/HYPOTHESE |
+| StRS-102 | Ausgangszahlungs-Betragsprüfung (M103) | ja | HYPOTHESE (Negativbetragsprüfung fehlt) |
+| StRS-103 | Kontonummern-Eindeutigkeit (M104) | ja | HYPOTHESE (DB-Constraint fehlt) |
+| StRS-106 | FinAPI-OAuth2 (M107) | ja | belegt (mit dokumentierter Schwäche: geteiltes Secret) |
+| StRS-110 | Signaturlink-Absicherung (M111) | ja | HYPOTHESE (serverseitige IBAN/BIC-Prüfung fehlt) |
+| StRS-112 | Webservice-Autorisierung (M116) | ja | belegt |
+| StRS-113/-114/-121 | TOTP, AES-Schlüsselverwaltung (M117, M21) | ja | belegt (mit dokumentierten kryptographischen Schwächen) |
+| StRS-021/-115 | KI-Provider-Allowlist, Datenminimierung | ja | belegt/HYPOTHESE |
+
+**Kein risikorelevantes Modul ist ausschließlich mit `SEKUNDÄR`/`KONTEXT` oder ohne `PRIMÄR`-Beleg
+geführt.** Mehrere Risikoanforderungen sind bewusst als `HYPOTHESE` markiert, weil sie eine Soll-Aussage
+für das Zielsystem enthalten, die im Bestandssystem nicht (oder nur teilweise) umgesetzt ist — dies
+entspricht der Vorgabe, ehrliche Abgrenzung sichtbar zu machen statt eine Lücke zu verschweigen.
+
+### Abgleich Hypothesen.md gegen Inline-Markierungen
+
+`Hypothesen.md` listet alle 27 Anforderungen mit `Status: HYPOTHESE` (9 je Ebene) vollständig und enthält
+keine zusätzlichen freien Fragen ohne Anforderungsbezug. Der Abgleich wurde durch Volltextsuche
+(`grep "Status:\s*HYPOTHESE"`) in allen drei Spezifikationsdateien durchgeführt; die Ergebnismenge deckt
+sich mit `Hypothesen.md`.
+
+## Selbstbewertung
+
+**Tiefe der Analyse:** Von 117 inventarisierten Modulen wurden 18 tief (davon 17 risikorelevant plus die
+KI-Sicherheitsvertiefung), 97 mittel und 2 flach (bewusst als veraltet/experimentell eingestuft) analysiert.
+Kein Modul blieb unanalysiert; die Mindestabdeckung aus Schritt 0b wurde für alle 117 Module erreicht,
+inklusive vier zunächst übersehener Module (M02, M110, M112, M113), die bei der abschließenden
+Konsistenzprüfung nachgetragen wurden.
+
+**Dünn belegte Stellen:** Am dünnsten belegt sind Module, deren Fachlogik im Wesentlichen aus generischen
+Delegationsmustern besteht (z. B. M58 Reports, M60 TaskManagement-Connector, M85 ProductMatrix) — hier
+liegt die eigentliche Geschäftslogik außerhalb der recherchierten Modulgrenze im Backend und wurde nur so
+weit verfolgt, wie zur Beleg-Erhärtung nötig. Ein spürbarer Anteil `SEKUNDÄR`/`KONTEXT`-Belege findet sich
+bei Modulen, deren Kernaussage aus DB-Schema-Constraints (bzw. deren Fehlen) statt aus Anwendungscode
+abgeleitet wurde (M47, M50, M103, M104).
+
+**Hypothesenanteil:** 27 von 383 Anforderungen (ca. 7 %) sind als `HYPOTHESE` markiert. Dieser Anteil ist
+niedriger als der in Iteration 01 beobachtete Bereich (0–26 %), was zwei Gründe hat: Erstens wurde die
+Belegpflicht in diesem Lauf strenger befolgt (Aussagen ohne Beleg wurden nicht geschrieben, sondern gar
+nicht erst formuliert), sodass weniger "schwache" Anforderungen überhaupt entstanden sind, die als Hypothese
+hätten markiert werden müssen. Zweitens wurde bei jedem der 17 risikorelevanten Module aktiv nach einem
+`PRIMÄR`-Beleg gesucht (Vorgabe aus dem Prompt), was in den meisten Fällen tatsächlich einen konkreten,
+durchsetzenden Codepfad zutage förderte — das Bestandssystem ist in sicherheits-/abrechnungsrelevanten
+Bereichen überraschend konsequent implementiert (SEPA-Export, Rechnungsstorno, Mahnwesen, Rechteprüfung).
+Die verbleibenden Hypothesen betreffen überwiegend Soll-Aussagen für das *Zielsystem*, die im Bestandssystem
+nachweislich fehlen (fehlende Rechteprüfung SQL-Manager, ungenutztes Negativbestands-Recht, fehlende
+Genehmigungsberechtigung Reisekosten, fehlende serverseitige IBAN-Revalidierung bei der elektronischen
+Signatur) — dies ist eine bewusste, dokumentierte Abgrenzung und kein Zeichen unvollständiger Recherche.
+
+**Erkenntnisse für eine Folgeiteration:**
+1. Ein systemweiter kryptographischer Schwachpunkt (`AESCryptoLogic`/`CryptoControl`: hartcodierte
+   Fallback-Schlüssel, deterministische statt zufällige Initialisierungsvektoren) betrifft mindestens sechs
+   Module (SEPA-Vertrag, Online-Banking, Passwort-Manager, FinAPI, docuFORM, KI-API-Schlüssel) und sollte in
+   einer Folgeiteration als eigenständiges, modulübergreifendes Sicherheits-Thema mit dedizierter
+   Migrationsanforderung behandelt werden, statt in Einzelmodulen wiederholt aufzutauchen.
+2. Die KI-Chat-Integration (M21) wurde erst im Verlauf der Recherche als signifikanter, ursprünglich nicht
+   als "RISK" markierter Sicherheits-/Datenschutzschwerpunkt erkannt (Datenabfluss an externe Provider,
+   fehlende Berechtigung für klassische Prompt-Endpunkte). Eine Folgeiteration sollte das Schritt-0c-
+   Risikokriterium explizit um "Datenschutz/externe Datenverarbeitung" erweitern, damit solche Module von
+   vornherein als Vertiefungskandidat erkannt werden, statt erst während der Recherche aufzufallen.
+3. Mehrere Konsolidierungskandidaten wurden identifiziert, aber nicht vollständig querverwiesen (siehe
+   Konsistenzcheck): Stammblatt/Zählwerk vs. DeviceClickCounter, ContractEvaluation2 vs. -Old, zwei
+   parallele TOTP-Implementierungen, zwei parallele Passwortspeicherpfade. Eine gezielte
+   Konsolidierungs-Iteration mit Fokus auf Datenmodell-Bereinigung (nicht auf weitere Breitenabdeckung)
+   wäre der sinnvollste nächste Schritt.
+4. Die Modul-zu-Anforderungs-ID-Zuordnung sollte in einer Folgeiteration durch ein zwingendes 1:1-Schema
+   (z. B. Anforderungs-ID = Modulnummer) statt freier Nummerierung erzwungen werden, um die in diesem
+   Konsistenzcheck offengelegten Zuordnungsungenauigkeiten (M07/M35, M39, M109) von vornherein
+   auszuschließen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/Ergebnisse/Glossar.md

@@ -0,0 +1,97 @@
+# Glossar
+
+Domänenbegriffe, die in StRS.md, SyRS.md und SwRS.md verwendet werden, mit kurzer Definition und Herkunft
+aus der Codebasis. Technische Bezeichner (Klassen, Methoden, Spaltennamen) sind in ihrer Originalsprache
+belassen.
+
+**Akteur** — In dieser Spezifikation eine Rolle (z. B. "Sachbearbeiter Finanzen"), ein Kunde/Web-Account
+oder eine technische Systemkomponente, die eine Anforderung auslöst oder von ihr betroffen ist.
+
+**Beleg (fachlich)** — Ein kaufmännisches Dokument im ERP-Sinn: Angebot, Auftrag, Lieferschein, Rechnung,
+Gutschrift, Vertrag u. a. Nicht zu verwechseln mit "Beleg" im Sinne von "Artefaktbeleg" (Codenachweis) in
+dieser Spezifikationsmethodik.
+
+**CentronObjectKindNumeric** — Zentrale Enum-Typklassifikation für Belegarten/Objektarten im gesamten
+System (z. B. `OrderClass`, `InvoiceClass`, `CreditVoucherClass`, `SupplierInvoice`). Wird durchgängig zur
+Typunterscheidung in Business-Logic, Schnittstellen und Datenexport verwendet.
+
+**Debitor / Kreditor** — Debitor: Kunde mit Forderung gegen ihn (Ausgangsrechnung). Kreditor: Lieferant mit
+Forderung gegen das Unternehmen (Eingangsrechnung). Im Code teils als "Account" mit Typkennzeichnung
+geführt (`AccountTypeKind.Customer`/`Supplier`).
+
+**DSGVO** — Datenschutz-Grundverordnung (EU-Verordnung 2016/679). Im Code als eigenes Modul
+`DataSecurity`/`Dsgvo` mit Lösch-/Anonymisierungsfunktionen abgebildet.
+
+**D!VE** — Vorleister-Angebotsplattform der Deutschen Telekom für Partnerangebote; das System exportiert
+Angebotsdaten im herstellerdefinierten D!VE-XML-Format (Version 1.6).
+
+**EBI / ebInterface** — Österreichischer Standard für elektronische Rechnungen (XML-Schema
+`http://www.ebinterface.at/schema/4p3/`).
+
+**EDI** — Electronic Data Interchange; automatisierter, strukturierter Datenaustausch mit Lieferanten
+(Auftragsbestätigungen, Lieferscheine, Rechnungen) außerhalb von E-Mail/Papier.
+
+**EOL (End of Life)** — Kennzeichnung eines Artikels als ausgelistet/nicht mehr aktiv vertrieben. Das
+System unterscheidet manuelle EOL-Setzung von automatisch vorgeschlagener ("Auto-EOL").
+
+**Filiale (Branch)** — Organisatorische Unterhirarchie eines Mandanten (Niederlassung/Standort). Viele
+Nummernkreise, Rechte und Kennzahlen sind filialspezifisch konfigurierbar.
+
+**HotlineMasterKey / Master-Passwort** — Zentraler, installationsspezifischer Schlüssel, mit dem sensible
+Daten (Bankzugangsdaten, Passwort-Manager-Einträge, docuFORM-/FinAPI-Secrets) AES-verschlüsselt werden. Im
+Bestandssystem wahlweise in der Konfigurationsdatenbank oder als lokale Datei gespeichert.
+
+**I3D** — Im gesamten Datenmodell durchgängig verwendeter interner Primärschlüssel-Bezeichner (Integer-ID)
+für praktisch jede Entität (z. B. `CustomerI3D`, `ArticleI3D`, `BranchI3D`). Legacy-Namenskonvention ohne
+weitere fachliche Bedeutung außer "eindeutige numerische ID".
+
+**Kommissionierung (Commissioning)** — Der Prozess des Zusammenstellens bestellter Waren aus dem Lager für
+den Versand ("Picking"). Nicht zu verwechseln mit Vertriebsprovision (siehe **Provision**).
+
+**Kontingent / Flatrate** — Vertragsmodell, bei dem ein fester Pauschalbetrag eine vorab vereinbarte
+Leistungsmenge (Zeit, Volumen) abdeckt; Mehrverbrauch wird gesondert behandelt oder ausgewiesen.
+
+**Mahnstufe (Dunning Level)** — Eskalationsstufe im Mahnprozess (None/Level1/Level2/Level3) einer
+überfälligen Rechnung, die Fristen und Mahnschreiben-Inhalt steuert.
+
+**Mandant (Tenant)** — Rechtlich/organisatorisch eigenständige Unternehmenseinheit innerhalb einer
+Systeminstallation (Multi-Tenancy auf Datenbankebene, nicht auf Infrastrukturebene).
+
+**MSP (Managed Service Provider)** — Hier: sowohl die Rolle des Unternehmens, das IT-Dienstleistungen für
+Kunden verwaltet, als auch — im Kontext von Zähler-/Lizenzabrechnung — externe Vorlieferanten (Octopus,
+ArrowSphere, Veeam), deren Nutzungsdaten mit eigenen Verträgen abgeglichen werden.
+
+**Nummernkreis (Number Group)** — Zentraler, je Belegart und optional je Filiale geführter Zähler zur
+Vergabe fortlaufender, eindeutiger Belegnummern.
+
+**OPOS (Offene Posten)** — Sammelbegriff für noch nicht vollständig ausgeglichene (bezahlte) Rechnungen
+eines Kunden; Grundlage für Kontoauszüge und Mahnwesen.
+
+**Provision** — Leistungsabhängige Vergütung von Vertriebsmitarbeitern anhand von Zielen/Stufen
+(`ProvisionEmployeeGoals`/`-Levels`), fachlich unabhängig von der Lager-**Kommissionierung**.
+
+**RMA (Return Merchandise Authorization)** — Retourenprozess: Rücksendung von Artikeln durch/an Kunden
+oder an Lieferanten, inkl. Ersatzlieferung, Reparatur oder Verschrottung.
+
+**SEPA-Mandat** — Einzugsermächtigung des Kunden für Lastschriftzahlungen nach dem SEPA-Standard (Single
+Euro Payments Area); im Bestandssystem als Zusatzattribut einer Bankverbindung geführt.
+
+**Stammblatt** — Historisch gewachsener Begriff für eine "Geräteakte": ein Datensatz, der ein beim Kunden
+befindliches Gerät (z. B. Drucker) mit zugehörigen Zählwerken und Vertragsbezug abbildet. Siehe
+Konsolidierungshinweis zu "Asset"-Konzept in `Analysebericht.md`.
+
+**TAPI** — Telephony Application Programming Interface; Windows-Schnittstelle zur Anbindung von
+Telefonanlagen (CTI, Computer Telephony Integration) an den Client.
+
+**TOTP** — Time-based One-Time Password (RFC 6238); Algorithmus für zeitbasierte Einmalkennwörter, wie sie
+Authenticator-Apps (z. B. Google Authenticator) erzeugen, hier für Zwei-Faktor-Authentifizierung genutzt.
+
+**WebAccount** — Login-Typ für externe Kunden im Selbstbedienungsportal (CentronNexus/WebCart), technisch
+und rechtlich strikt getrennt vom internen Mitarbeiter-Login.
+
+**Zählwerk / Klickzähler (Device Click Counter)** — Erfasster Zählerstand eines Geräts (z. B.
+Seiten-/Klickzähler eines Druckers), der über Zeit fortgeschrieben und für volumenbasierte Verträge
+abgerechnet wird.
+
+**Zuschlagssatz (Hourly Surcharge Rate)** — Konfigurierter Prozentaufschlag auf den Stundensatz, abhängig
+von Wochentag/Feiertag und Uhrzeitfenster, bei der Abrechnung von Zeiterfassungen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/Ergebnisse/Hypothesen.md

@@ -0,0 +1,105 @@
+# Hypothesen
+
+Sammlung aller Anforderungen mit `Status: HYPOTHESE` aus StRS.md, SyRS.md und SwRS.md. Diese Liste ist
+deckungsgleich mit den Inline-Markierungen (`Status`-Feld) in den drei Spezifikationsdokumenten — siehe
+Konsistenzcheck in `Analysebericht.md`. Jeder Eintrag nennt die offene Frage, die zur Bestätigung fehlt.
+
+Insgesamt 27 Anforderungen mit `Status: HYPOTHESE` (9 je Ebene). Kein Eintrag hier ohne zugehörige
+Anforderung in StRS/SyRS/SwRS; keine freien Fragen ohne Anforderungsbezug (offene Punkte ohne
+Anforderungsbezug stehen stattdessen in der Selbstbewertung in `Analysebericht.md`).
+
+---
+
+## Themengruppe: Fehlende Berechtigungsprüfung für SQL-Diagnosewerkzeug
+
+- **StRS-002 / SyRS-002 / SwRS-002** — `SqlManagerAppModuleController.GetRights()` liefert `null`.
+  Offene Frage: Ist das Fehlen einer Rechteprüfung eine bewusste Design-Entscheidung (SQL-Manager nur für
+  eine kleine, ohnehin privilegierte Gruppe gedacht) oder eine Lücke? Ohne Rücksprache mit den
+  Produktverantwortlichen lässt sich nicht klären, ob im Bestandssystem irgendwo außerhalb des Moduls
+  (z. B. Deployment-Konfiguration) eine Zugriffsbeschränkung existiert.
+
+## Themengruppe: Feiertagszuschlag ist im Code als Stub implementiert
+
+- **SyRS-008 / SwRS-008** — `HelpdeskTimerBL.IsHoliday(DateTime)` liefert konstant `false`.
+  Offene Frage: Welche Feiertagsregel (Bundesland-spezifisch? bundeseinheitlich? konfigurierbare
+  Feiertagsliste?) soll im Zielsystem gelten? Der Code selbst enthält keinen Hinweis auf die beabsichtigte
+  Feiertagsquelle.
+  (StRS-008 ist "belegt", da die grundsätzliche Zuschlagsfähigkeit selbst zweifelsfrei belegt ist; nur die
+  Feiertagskomponente ist offen — siehe Konsistenzcheck.)
+
+## Themengruppe: DocSync-Feature im Alpha-Stadium
+
+- **StRS-029 / SyRS-029 / SwRS-029** — Modul explizit als "(Alpha)" gekennzeichnet, Transportmechanismus
+  liegt außerhalb der Codebasis.
+  Offene Frage: Wird DocSync produktiv genutzt oder ist es ein abgebrochenes Experiment? Ohne Zugriff auf
+  Kundeneinsatzdaten oder Product-Roadmap lässt sich der Reifegrad nicht abschließend beurteilen.
+
+## Themengruppe: Reisekosten-Genehmigung ohne dediziertes Recht
+
+- **StRS-076 / SyRS-076 / SwRS-076** — `TravelExpenseAppModuleController.GetRights()` liefert `null`;
+  jeder mit Modulzugriff kann finanzwirksam genehmigen/ablehnen.
+  Offene Frage: Ist dies im Bestandssystem bewusst so vorgesehen (kleine Teams, informelle Kontrolle) oder
+  ein Sicherheitsversäumnis? Eine Aussage darüber, ob im Zielsystem ein Genehmigungsrecht zwingend
+  erforderlich ist, kann nur der Fachbereich treffen.
+
+## Themengruppe: Auftragsreservierung im Warenwirtschaftskern deaktiviert
+
+- **SyRS-094 / SwRS-094** — `AssetBL.DoArticleBooking`: Die Zeile zur Bestandsreservierung bei
+  Auftragserfassung (`StockInOrder`) ist auskommentiert.
+  Offene Frage: Wurde die Auftragsreservierung bewusst deaktiviert (z. B. wegen Performance- oder
+  Dateninkonsistenzproblemen in der Vergangenheit) oder ist es unvollständiger Code? Ohne Commit-Historie
+  mit Begründung (der Codebasis-Snapshot enthält keine aussagekräftige Git-Historie, siehe
+  Analysebericht) ist dies nicht rekonstruierbar.
+  (StRS-094 ist "belegt", da die tatsächliche Bestandsfortschreibung bei Warenfluss zweifelsfrei belegt
+  ist; nur die Frage der Auftragsreservierung bleibt offen.)
+
+## Themengruppe: Fehlendes DB-Unique-Constraint für Kontonummern
+
+- **StRS-103 / SyRS-103 / SwRS-103** — `AccountSystemsViewModel.NewAccount` sichert Eindeutigkeit nur
+  In-Memory; `SSMS_DB_SCHEMA.sql` bestätigt fehlendes UNIQUE-Constraint auf `BookKeepingAccounts.Number`.
+  Offene Frage: Ist im Produktivbetrieb bereits eine Kollision aufgetreten (Datenqualitätsprüfung würde
+  dies zeigen), oder ist das Risiko bislang nur theoretisch? Diese Information liegt außerhalb des
+  Quellcodes.
+
+## Themengruppe: Elektronische Signatur ohne Login — serverseitige Zahlungsdatenvalidierung
+
+- **StRS-110** — `DocumentSigningPage.razor`/`DsgvoBL.ConfirmOnlinePdfDocument`: IBAN/BIC werden nur
+  clientseitig validiert.
+  Offene Frage: Ist die fehlende serverseitige Revalidierung ein bewusstes Vertrauen in den Client (da der
+  Kunde selbst betroffen ist) oder eine Lücke? Für eine abschließende Bewertung wäre eine Rücksprache mit
+  dem für die Zahlungsabwicklung verantwortlichen Fachbereich nötig.
+
+## Themengruppe: Umfang der an externe KI-Provider übertragenen personenbezogenen Daten
+
+- **StRS-115 / SyRS-115 / SwRS-115** — `ArtificialIntelligenceBL.CreateTicketMailsSummary` u. a. sendet
+  Absenderadressen, interne Notizen und Ticketinhalte an den konfigurierten externen KI-Provider.
+  Offene Frage: Existiert eine Datenschutz-Folgenabschätzung oder ein Auftragsverarbeitungsvertrag mit den
+  genutzten KI-Providern (OpenAI, Anthropic, Mistral, Google)? Diese Information ist nicht Teil der
+  Codebasis und kann nur organisatorisch (Verträge, DSGVO-Dokumentation) geklärt werden.
+
+## Themengruppe: Vertriebsprovisionsberechnung (nur Existenznachweis, keine Detailregeln erhoben)
+
+- **StRS-116 / SyRS-116 / SwRS-116** — `ProvisionEmployeeGoalsViewModel`/`ProvisionEmployeeLevels` existieren
+  in `shared/Centron.Controls/EmployeeManagement`, wurden aber im Rahmen dieser Iteration nicht im Detail
+  untersucht (Zeit-/Umfangsgrenze der Recherche-Cluster).
+  Offene Frage: Welche konkrete Formel (Zielerreichung × Stufe? Staffelprovision? Deckelung?) implementiert
+  dieses Modul? Erfordert eine gezielte Vertiefung in einer Folgeiteration.
+
+## Themengruppe: Ungenutztes Berechtigungs-Flag für Negativbestandsbuchungen
+
+- **StRS-123 / SyRS-123 / SwRS-123** — `HasUserArticleNegativBookingRight` wird geladen, aber im
+  WPF-Client an keiner Stelle konsumiert; Bestandsabbuchungen prüfen keine Untergrenze.
+  Offene Frage: Wird die Untergrenze eventuell serverseitig an anderer, hier nicht recherchierter Stelle
+  durchgesetzt (z. B. in einem separaten Validierungsdienst), oder ist das Recht tatsächlich vollständig
+  wirkungslos? Eine vollständige Durchsuchung aller Backend-Aufrufer von `BookFromStock` war im Rahmen
+  dieser Iteration nicht möglich.
+
+---
+
+## Abgleichshinweis
+
+Alle 27 oben gelisteten Anforderungen tragen in StRS.md, SyRS.md bzw. SwRS.md exakt `Status: HYPOTHESE`.
+Es gibt keine weiteren `HYPOTHESE`-markierten Anforderungen in den drei Spezifikationsdokumenten und keine
+zusätzlichen freien Fragen ohne Anforderungsbezug. Ein Fall struktureller Asymmetrie zwischen den Ebenen
+(StRS "belegt" bei gleichzeitig SyRS/SwRS "HYPOTHESE" derselben Modul-Nr. oder umgekehrt) ist bei M8, M76,
+M94, M103, M110, M115, M123 aufgetreten und wird im Konsistenzcheck in `Analysebericht.md` erläutert.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/Ergebnisse/Traceability.md

@@ -0,0 +1,148 @@
+# Traceability – StRS ↔ SyRS ↔ SwRS
+
+Konsolidierte Forward-/Backward-Traceability-Tabelle. Jede SwRS-Anforderung referenziert ihre SyRS-Anforderung
+(Feld `Tracelinks` in SwRS.md), jede SyRS-Anforderung ihre StRS-Anforderung (Feld `Tracelinks` in SyRS.md).
+Die Nummerierung ist über alle drei Ebenen modulweise durchgängig (StRS-NNN ↔ SyRS-NNN ↔ SwRS-NNN); Modul
+M21 (ArtificialIntelligence) hat wegen zweier unabhängiger Kernaussagen zusätzlich die Anforderungen
+SyRS-021b/SwRS-021b, die ebenfalls auf StRS-021 zurückverweisen. Für M116 wurden zur Risikovertiefung sechs
+zusätzliche, unabhängige Anforderungstripel StRS/SyRS/SwRS-118 bis -123 ergänzt (siehe Analysebericht,
+Schritt 0c). "Artefaktbeleg" nennt den jeweils primären Codenachweis der SwRS-Anforderung.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Modul | Artefaktbeleg (primär) |
+|---|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-001 | M01 | Modules/Administration/Cache/CentronCache.cs |
+| StRS-002 | SyRS-002 | SwRS-002 | M01 | Modules/Administration/SqlManagers/SqlManagerAppModuleController.cs |
+| StRS-003 | SyRS-003 | SwRS-003 | M03 | backend/Centron.BL/CountryArea/CountryBL.cs |
+| StRS-004 | SyRS-004 | SwRS-004 | M04 | backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs |
+| StRS-005 | SyRS-005 | SwRS-005 | M05 | backend/Centron.BL/EmployeeArea/EmployeeBL.cs |
+| StRS-006 | SyRS-006 | SwRS-006 | M06 | Modules/Administration/EscalationsSettings/EscalationType/EscalationTypeViewModel.cs |
+| StRS-007 | SyRS-007 | SwRS-007 | M07 | backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs |
+| StRS-008 | SyRS-008 | SwRS-008 | M08 | backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs |
+| StRS-009 | SyRS-009 | SwRS-009 | M09 | backend/Centron.BL/WebServices/Mail/SendMailWebserviceBL.cs |
+| StRS-010 | SyRS-010 | SwRS-010 | M10 | backend/Centron.BL/Mail/Templates/MailTemplateBL.cs |
+| StRS-011 | SyRS-011 | SwRS-011 | M11 | Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs |
+| StRS-012 | SyRS-012 | SwRS-012 | M12 | backend/Centron.BL/Security/PdfSigningBL.cs |
+| StRS-013 | SyRS-013 | SwRS-013 | M13 | backend/Centron.BL/Accounts/TapiBL.cs |
+| StRS-014 | SyRS-014 | SwRS-014 | M14 | backend/Centron.BL/Administration/Masterdata/AssetConditionBL.cs |
+| StRS-015 | SyRS-015 | SwRS-015 | M15 | backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs |
+| StRS-016 | SyRS-016 | SwRS-016 | M16 [RISK] | backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-017 | SyRS-017 | SwRS-017 | M17 | backend/Centron.BL/WebServices/Sales/Receipts/DeliveryList/DeliveryListWebServiceBL.cs |
+| StRS-018 | SyRS-018 | SwRS-018 | M18 [RISK] | backend/Centron.BL/WebServices/Administration/Documents/SepaContracts/SepaContractWebServiceBL.cs |
+| StRS-019 | SyRS-019 | SwRS-019 | M19 | Modules/Administration/ServiceAndLeasing/ServiceLeasingViewModel.cs |
+| StRS-020 | SyRS-020 | SwRS-020 | M20 | backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs |
+| StRS-021 | SyRS-021 | SwRS-021 | M21 | backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs |
+| StRS-021 | SyRS-021b | SwRS-021b | M21 | Modules/ArtificialIntelligence/Chat/Harness/ArtificialIntelligenceDefaultToolConfirmationService.cs |
+| StRS-022 | SyRS-022 | SwRS-022 | M22 | Modules/Calendar/Settings/CrmOutlookTemplate/CrmOutlookTemplateSettingsViewModel.cs |
+| StRS-023 | SyRS-023 | SwRS-023 | M23 | Modules/Dashboard/Modules/ModulesViewModel.cs |
+| StRS-024 | SyRS-024 | SwRS-024 | M24 | Modules/DataExchange/BookKeeping/BookKeepingExportViewModel.cs |
+| StRS-025 | SyRS-025 | SwRS-025 | M25 | Modules/DataExchange/Connectors/Settings/DocBeeConnectorUxOrchestrator.cs |
+| StRS-026 | SyRS-026 | SwRS-026 | M26 | Modules/DataExchange/DataExport/InvoiceExport/Exports/DataExportInvoiceViewModel.cs |
+| StRS-027 | SyRS-027 | SwRS-027 | M27 | Modules/DataExchange/DataImport/AccountImport/ExcelImportManager.cs |
+| StRS-028 | SyRS-028 | SwRS-028 | M28 | Modules/DataExchange/DatevOnline2020/DatevOnlineViewModel.cs |
+| StRS-029 | SyRS-029 | SwRS-029 | M29 | backend/Centron.Entities/Entities/Administration/FileManagement/DocSyncDirectory.cs |
+| StRS-030 | SyRS-030 | SwRS-030 | M30 | backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/Settings/DocuFormSetting.cs |
+| StRS-031 | SyRS-031 | SwRS-031 | M31 [RISK] | backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa/PaymentTransactionSepaInterface.cs |
+| StRS-032 | SyRS-032 | SwRS-032 | M32 | backend/Centron.BL/RiverDivo/RiverDivoBL.cs |
+| StRS-033 | SyRS-033 | SwRS-033 | M33 | Modules/DataExchange/SupplierOrderPerBranch/SupplierOrderPerBranchViewModel.cs |
+| StRS-034 | SyRS-034 | SwRS-034 | M34/M94 | Modules/TelekomDive/TelekomDiveExportViewModel.cs |
+| StRS-035 | SyRS-035 | SwRS-035 | M35 | backend/Centron.BL/Accounts/AccountBL.cs |
+| StRS-036 | SyRS-036 | SwRS-036 | M37 [RISK] | backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs |
+| StRS-037 | SyRS-037 | SwRS-037 | M38 | backend/Centron.BL/Accounts/Campaigns/CampaignBL.cs |
+| StRS-038 | SyRS-038 | SwRS-038 | M40 | Modules/ModuleRegistration.cs |
+| StRS-039 | SyRS-039 | SwRS-039 | M41 [RISK] | backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs |
+| StRS-040 | SyRS-040 | SwRS-040 | M42 | Modules/Finances/Crm/Activities/ActivityViewModel.cs |
+| StRS-041 | SyRS-041 | SwRS-041 | M43 | Modules/Finances/DeviceClickCounter/DeviceClickCounterViewModel.cs |
+| StRS-042 | SyRS-042 | SwRS-042 | M44 [RISK] | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs |
+| StRS-043 | SyRS-043 | SwRS-043 | M37 [RISK] | backend/Centron.BL/Sales/Receipts/Orders/ReceiptOrderBL.cs |
+| StRS-044 | SyRS-044 | SwRS-044 | M45 | Modules/Finances/FlatrateBilling/ViewModel/FlatRateProjectViewModel.cs |
+| StRS-045 | SyRS-045 | SwRS-045 | M46 | backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs |
+| StRS-046 | SyRS-046 | SwRS-046 | M47 [RISK] | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs |
+| StRS-047 | SyRS-047 | SwRS-047 | M48 [RISK] | backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs |
+| StRS-048 | SyRS-048 | SwRS-048 | M49 | backend/Centron.BL/Finances/ProductLifecycleBL.cs |
+| StRS-049 | SyRS-049 | SwRS-049 | M50 | backend/Centron.DAO/Mappings/Sales/Customers/CrmProjects/CrmProjectRevenueMaps.cs |
+| StRS-050 | SyRS-050 | SwRS-050 | M51 [RISK] | backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs |
+| StRS-051 | SyRS-051 | SwRS-051 | M52 [RISK] | backend/Centron.BL/Warehousing/ArticleUnitHelper.cs |
+| StRS-052 | SyRS-052 | SwRS-052 | M53 | Modules/Global/NetworkDiagnostics/NetworkDiagnosticsViewModel.cs |
+| StRS-053 | SyRS-053 | SwRS-053 | M54 | Centron.WPF.UI/FrontWindowViewModel.cs |
+| StRS-054 | SyRS-054 | SwRS-054 | M55 | webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Settings/SettingGroups/HelpdeskSettings.cs |
+| StRS-055 | SyRS-055 | SwRS-055 | M56 | Modules/Helpdesk/CentronChecklist/CentronChecklistAppModuleControllerView.ArtificialIntelligence.cs |
+| StRS-056 | SyRS-056 | SwRS-056 | M57 | Modules/Helpdesk/Dashboard/TicketStatisticsProvider.cs |
+| StRS-057 | SyRS-057 | SwRS-057 | M58 | Modules/Helpdesk/SendSelfCareForm/SendSelfCareViewModel.cs |
+| StRS-058 | SyRS-058 | SwRS-058 | M59 | Modules/Helpdesk/TaskManagement/Connectors/TaskManagmentConnector.cs |
+| StRS-059 | SyRS-059 | SwRS-059 | M60 | Modules/Helpdesk/TicketProcessTemplates/TicketProcessTemplateViewModel.cs |
+| StRS-060 | SyRS-060 | SwRS-060 | M61 | Modules/Logistic/ShippingMethodSettings/ShippingMethodSettingsViewModel.cs |
+| StRS-061 | SyRS-061 | SwRS-061 | M62 | Modules/Massenupdates/Updates/PriceUpdates/ArticleUpdate/UpdatePreviewViewModel.cs |
+| StRS-062 | SyRS-062 | SwRS-062 | M63 | backend/Centron.BL/MyDay/MyDayBL.cs |
+| StRS-063 | SyRS-063 | SwRS-063 | M64 | Modules/MyCentron/CentronInspectors/Inspectors/InspectorItemBase.cs |
+| StRS-064 | SyRS-064 | SwRS-064 | M65 | backend/Centron.BL/MyDay/MyDayBL.cs |
+| StRS-065 | SyRS-065 | SwRS-065 | M66 | Modules/MyCentron/Telephony/TelephonyConnector.cs |
+| StRS-066 | SyRS-066 | SwRS-066 | M67 [RISK] | backend/Centron.BL/Finances/OnlineBanking/OnlineBankingConfigurationBL.cs |
+| StRS-067 | SyRS-067 | SwRS-067 | M68 | Modules/PLM/PlmViewModel.cs |
+| StRS-068 | SyRS-068 | SwRS-068 | M69 [RISK] | backend/Centron.BL/PasswordManager/PasswordManagerBL.cs |
+| StRS-069 | SyRS-069 | SwRS-069 | M70 | Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerViewModel.cs |
+| StRS-070 | SyRS-070 | SwRS-070 | M71 | Modules/Production/ProductionOrder/AddProductionOrder/AddProductionOrderViewModel.cs |
+| StRS-071 | SyRS-071 | SwRS-071 | M72 | Modules/ProjectManagement/ProjectManagementViewModel.cs |
+| StRS-072 | SyRS-072 | SwRS-072 | M73 | Modules/ProjectPriceImport/ProjectPriceImportViewModel.cs |
+| StRS-073 | SyRS-073 | SwRS-073 | M74 | Modules/Purchasing/Others/SuggestionOrderComplete.cs |
+| StRS-074 | SyRS-074 | SwRS-074 | M75 | Modules/Purchasing/EDIManagement/EDIReceiptTabs/EDIReceiptViewModel.cs |
+| StRS-075 | SyRS-075 | SwRS-075 | M76 | Modules/Purchasing/OrderSuggestionList/OrderSuggestionListViewModel.cs |
+| StRS-076 | SyRS-076 | SwRS-076 | M77 | Modules/Purchasing/TravelExpense/ViewModels/TransactionDetailViewModel.cs |
+| StRS-077 | SyRS-077 | SwRS-077 | M78 | Modules/QM/Settings/AssetReasonSettingsViewModel.cs |
+| StRS-078 | SyRS-078 | SwRS-078 | M79 | Modules/Reports/ReportManagement/Connectors/ReportManagementConnectorDialogs.cs |
+| StRS-079 | SyRS-079 | SwRS-079 | M80 | webservice/Centron.WebServices.Core/Entities/Sales/Support/RmaArea/RMAState.cs |
+| StRS-080 | SyRS-080 | SwRS-080 | M81 | Modules/Rma/RmaSettings/RmaSettingsViewModel.cs |
+| StRS-081 | SyRS-081 | SwRS-081 | M82 | Modules/Rma/SendBack/SendBackViewModel.cs |
+| StRS-082 | SyRS-082 | SwRS-082 | M83 | Modules/Rma/SendForth/SendForthViewModel.cs |
+| StRS-083 | SyRS-083 | SwRS-083 | M84 | backend/Centron.BL/Sales/CustomerAssets/Offers/OfferBL.cs |
+| StRS-084 | SyRS-084 | SwRS-084 | M85 | Modules/Sales/Mailing/Templates/MailingTemplateViewModel.cs |
+| StRS-085 | SyRS-085 | SwRS-085 | M86 | webservice/Centron.WebServices.Core/Entities/ProductMatrix/CustomerProductMatrixRatingValue.cs |
+| StRS-086 | SyRS-086 | SwRS-086 | M87 | Modules/Sales/SpecialArticleImport/SpecialArticleToContractExcelImportResultViewModel.cs |
+| StRS-087 | SyRS-087 | SwRS-087 | M88 | Modules/Sales/SpecialArticleToContractImport/SpecialArticleToContractImportViewModel.cs |
+| StRS-088 | SyRS-088 | SwRS-088 | M89 | Modules/Statistics/ManagementInfo/ManagementInfoViewModel.cs |
+| StRS-089 | SyRS-089 | SwRS-089 | M90 | Modules/Statistics/EmployeeAnalytics/EmployeeAnalyticsAppModuleController.cs |
+| StRS-090 | SyRS-090 | SwRS-090 | M91 | Modules/Statistics/MspCollectors/MspCollectorAppViewModel.cs |
+| StRS-091 | SyRS-091 | SwRS-091 | M92 | Modules/Statistics/SaleStatistics/SaleStatisticsView.ArtificialIntelligence.cs |
+| StRS-092 | SyRS-092 | SwRS-092 | M93 | Modules/Survey/SurveySettings/SurveySettingsController.cs |
+| StRS-093 | SyRS-093 | SwRS-093 | M93/M34 | Modules/DataExchange/TelekomDive/Settings/Profiles/TelekomDiveProfileViewModel.cs |
+| StRS-094 | SyRS-094 | SwRS-094 | M95 | backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs |
+| StRS-095 | SyRS-095 | SwRS-095 | M96 | Modules/Warehousing/ArticleImport/Data/ArticleImportFileContentViewModel.cs |
+| StRS-096 | SyRS-096 | SwRS-096 | M97 | backend/Centron.BL/Warehousing/ArticleBL.cs |
+| StRS-097 | SyRS-097 | SwRS-097 | M98 | Modules/Warehousing/ArticleUnitManagement/ViewModel/ArticleUnitManagementViewModel.cs |
+| StRS-098 | SyRS-098 | SwRS-098 | M99 | Modules/Warehousing/BarcodeManagement/GenerateBarcode/ViewModel/GenerateBarcodeViewModel.cs |
+| StRS-099 | SyRS-099 | SwRS-099 | M100 | Modules/Warehousing/Commissions/CommissionOrders/PartialCommissionOrderItemViewModel.cs |
+| StRS-100 | SyRS-100 | SwRS-100 | M101 | backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs |
+| StRS-101 | SyRS-101 | SwRS-101 | M102 | Modules/Warehousing/MaterialGroupManagement/ViewModel/MaterialGroupMarkupViewModel.cs |
+| StRS-102 | SyRS-102 | SwRS-102 | M103 [RISK] | Modules/Warehousing/OutcomingPayments/OutgoingPaymentsViewModel.cs |
+| StRS-103 | SyRS-103 | SwRS-103 | M104 [RISK] | Modules/Warehousing/AccountSystems/AccountSystemsViewModel.cs |
+| StRS-104 | SyRS-104 | SwRS-104 | M105 | Modules/Warehousing/SearchArticle/ViewModel/SearchArticleViewModel.cs |
+| StRS-105 | SyRS-105 | SwRS-105 | M106 | apis/Centron.APIs.ITscopeDataAccess/ITscopeApi.cs |
+| StRS-106 | SyRS-106 | SwRS-106 | M107 [RISK] | apis/Centron.APIs.FinAPI/RestClient/RestClientBase.cs |
+| StRS-107 | SyRS-107 | SwRS-107 | M108 | apis/Centron.Api.Gls/CentronGlsLogic.cs |
+| StRS-108 | SyRS-108 | SwRS-108 | M108 | apis/Centron.Api.EbInterface/EbInterfaceLogic.cs |
+| StRS-109 | SyRS-109 | SwRS-109 | M115 | nexus/CentronNexus/WebCart/_Imports.razor |
+| StRS-110 | SyRS-110 | SwRS-110 | M111 [RISK] | backend/Centron.BL/Administration/Documents/Dsgvo/DsgvoBL.cs |
+| StRS-111 | SyRS-111 | SwRS-111 | M114 | nexus/CentronNexus/ServiceBoard/_Imports.razor |
+| StRS-112 | SyRS-112 | SwRS-112 | M116 [RISK] | webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs |
+| StRS-113 | SyRS-113 | SwRS-113 | M117 | shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs |
+| StRS-114 | SyRS-114 | SwRS-114 | M117 | backend/Centron.Common/TextCoding/AESCryptoLogic.cs |
+| StRS-115 | SyRS-115 | SwRS-115 | M21 | backend/Centron.BL/Administration/ArtificialIntelligence/ArtificialIntelligenceBL.cs |
+| StRS-116 | SyRS-116 | SwRS-116 | (Provision) | shared/Centron.Controls/EmployeeManagement/ProvisionEmployeeGoals/ProvisionEmployeeGoalsViewModel.cs |
+| StRS-117 | SyRS-117 | SwRS-117 | (Shared) | shared/Centron.Controls/PasswordManager/PasswordGenerator.cs |
+| StRS-118 | SyRS-118 | SwRS-118 | M16 [RISK] | backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-119 | SyRS-119 | SwRS-119 | M31 [RISK] | backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs |
+| StRS-120 | SyRS-120 | SwRS-120 | M69 [RISK] | backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs |
+| StRS-121 | SyRS-121 | SwRS-121 | M21 | backend/Centron.Common/TextCoding/CryptoControl.cs |
+| StRS-122 | SyRS-122 | SwRS-122 | M51 [RISK] | backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-123 | SyRS-123 | SwRS-123 | M95 | backend/Centron.Interfaces/Warehousing/ArticleManagement/ArticleManagementUiSettings.cs |
+| StRS-124 | SyRS-124 | SwRS-124 | M02 | Modules/Administration/CentronConfigDb/CentronConfigDbSettingsViewModel.cs |
+| StRS-125 | SyRS-125 | SwRS-125 | M110 | nexus/CentronNexus/Shared/Authorization/CentronAuthorization.cs |
+| StRS-126 | SyRS-126 | SwRS-126 | M112 | nexus/CentronNexus/Office/Controllers/PdfController.cs |
+| StRS-127 | SyRS-127 | SwRS-127 | M113 | nexus/CentronNexus/ProductionOrderManagement/Components/WorkStepTemplateComponent.razor |
+
+## Anmerkung zu M02, M09, M36
+
+Für M02 (CentronConfigDb), M36 (AccountManagement) und M09/M13-Teilaspekte liegt die primäre fachliche
+Anforderung als Kontext-/Sekundärbeleg innerhalb der Requirements anderer Module (insbesondere StRS-001,
+StRS-066, StRS-035, StRS-013) vor, da die Recherche-Cluster technisch eng gekoppelte Funktionen (z. B.
+Verschlüsselungsschlüsselverwaltung, Kontenverwaltung) modulübergreifend gemeinsam belegt haben. Diese
+Module sind in der Abdeckungstabelle in `Analysebericht.md` gesondert ausgewiesen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/Protokoll.md

@@ -0,0 +1,217 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T12:50:58.8185434+02:00
+- **Endzeit:** 2026-08-26T13:50:37.1135978+02:00
+- **Dauer gesamt:** 0:59:38 (`duration_ms` 0:59:36; API: 3:03:11)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.4.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 95.424.851 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.987 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.4.0-fb24`
+- **Ablage:** `Iteration 3/claude-sonnet-5/builtin/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-37c5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-a8f5`
+  - `Iteration 3/claude-opus-5/solo/max/02_Lauf_2026-08-26_132237_v4.4.0-fcdf`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-4048`
+  - `Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-f8b4`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden. Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials bleiben unverzerrt.
+- **Agentenmodus:** `builtin` (V1b)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos). Der Modus `builtin` fügt keine weiteren Sperren hinzu – die werkzeugeigenen Subagenten sind zugelassen.
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** 31 gestartet (10 × `Explore`, 21 × `general-purpose`), 30 abgeschlossen, 0 fehlgeschlagen; 31 im Hintergrund gestartet
+- **Verschachtelung:** `spawned` = 31, davon `spawned_by_subagents` = 18, `max_depth` = 2. Bei `max_depth` > 1 sind die Tokens der tieferen Ebenen in „Tokens gesamt" enthalten, ihre Prompts jedoch **nicht** in `_meta\subagenten.md`.
+- **Verbrauchsanteil der Subagenten:** `usage` (nur Hauptagent) 34.808.562 Tokens gegenüber `modelUsage` 95.431.838 Tokens – auf die Subagenten entfallen 60.623.276 Tokens (63.5 %).
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 172 |
+| Output-Tokens | 334.119 (davon 52.494 Thinking-Tokens) |
+| Cache-Write-Tokens | 734.322 |
+| Cache-Read-Tokens | 33.739.949 |
+| Agent-Turns | 106 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 1.702 | 6.961 | 8.663 |
+| Output-Tokens | 955.656 | 26 | 955.682 |
+| Cache-Write-Tokens | 3.372.108 | 0 | 3.372.108 |
+| Cache-Read-Tokens | 91.095.385 | 0 | 91.095.385 |
+| **Tokens gesamt** | **95.424.851** | **6.987** | **95.431.838** |
+
+**Tokens gesamt: 95.431.838** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+`usage` erfasst **nur den Hauptagenten**. Der Unterschied zu `modelUsage` ist der Verbrauch
+der Subagenten – siehe Feld „Verbrauchsanteil der Subagenten" oben. Für den
+abrechnungsrelevanten Gesamtverbrauch gilt ausschließlich `modelUsage`.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 127 | 33,2 % |
+| SyRS | 128 | 33,4 % |
+| SwRS | 128 | 33,4 % |
+| **Gesamt** | **383** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 171 | 44,6 % |
+| Sicherheit | 89 | 23,2 % |
+| Daten | 72 | 18,8 % |
+| Schnittstelle | 31 | 8,1 % |
+| nicht-funktional | 20 | 5,2 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 438 |
+| davon `PRIMÄR` | 416 (95,0 %) |
+| davon `SEKUNDÄR` | 8 (1,8 %) |
+| davon `KONTEXT` | 14 (3,2 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 371 (96,9 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 308 | 80,4 % |
+| workaround | 23 | 6,0 % |
+| sonderfall | 30 | 7,8 % |
+| veraltet | 22 | 5,7 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 356 | 93,0 % |
+| als `HYPOTHESE` gekennzeichnet | 27 | 7,0 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 20 | 5,2 % |
+| mit ISO-25010-Qualitätsmerkmal | 20 | 5,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 3 von 122 ungedeckt: StRS-117, StRS-127, SyRS-117 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 383 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 383 von 383 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `4e45cfc6-414a-4e1f-a9f2-a91cd9c68ab2`
+- **Permission-Denials:** 0 – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 31 – Bedingung `solo` **VERLETZT – Fehlmessung**
+- **Subagenten-Prompts:** `_meta\subagenten.md` erzeugt
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 35.272 B |
+  | `Glossar.md` | 6.096 B |
+  | `Hypothesen.md` | 6.717 B |
+  | `StRS.md` | 158.515 B |
+  | `SwRS.md` | 122.055 B |
+  | `SyRS.md` | 123.373 B |
+  | `Traceability.md` | 15.509 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 – Snapshot mit DB-Schema.** `SSMS_DB_SCHEMA.sql` (3.266.626 B, 76.793 Zeilen,
+1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256
+`ED7F2125…1FA8DB`) ist seit Commit `f349d189` Bestandteil des Untersuchungsgegenstands. Läufe der
+Iteration 2 hatten die Datei nicht – beide Iterationen sind **nicht poolbar**.
+
+**2. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Wanduhrzeit,
+`duration_ms` und `duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl,
+Belegkennzahlen und Denials nicht. Einziger gültiger Laufzeitmesspunkt aller drei Iterationen
+bleibt der serielle Lauf `084301_v4.2.0-d6f9` mit 45:04.
+
+**3. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung.
+
+**4. Modellkontrolle bei `builtin` besonders relevant – und bestanden.** `--model` steuert nur den
+Hauptagenten. In Iteration 1 liefen bei Fable die 13 Subagenten auf `claude-opus-5[1m]`, also 91 %
+des Verbrauchs auf einem nicht angeforderten Modell. Hier weist `modelUsage` ausschließlich
+`claude-sonnet-5` plus Haiku-Hilfsaufrufe aus: Sonnet wird an die Subagenten durchgereicht.
+
+**5. `usage` misst nur den Hauptagenten.** Für den Gesamtverbrauch gilt ausschließlich
+`modelUsage` – siehe Feld „Verbrauchsanteil der Subagenten" oben.
+
+**6. Der aufwendigste `builtin`-Lauf – und der einzige mit Delegation über zwei Ebenen.** 31
+Subagenten (21 `general-purpose`, 10 `Explore`), davon **18 von Subagenten gestartet**
+(`max_depth` = 2). 95,4 Mio. Tokens, davon 63,5 % auf die Subagenten.
+
+**7. Er durchbricht die Anti-Korrelation zwischen Menge und Belegqualität.** 383 Anforderungen bei
+96,9 % Primärbelegquote und einer nahezu exakten Gleichverteilung über die drei Ebenen
+(127 / 128 / 128). Über die zehn `solo`-Läufe der Prompt-Version 02 liefen beide Größen
+gegeneinander (Spearman −0,70); dieser Lauf liefert beides. Wie `4048` beauftragte er seine
+Subagenten mit „Research" und Faktenpflicht – die Beauftragungsart trennt auch hier.
+
+**8. 29 Starts wurden am Nebenläufigkeitslimit abgewiesen.** Der Agent wollte stärker
+parallelisieren, als das Werkzeug zuließ (20 gleichzeitige Subagenten,
+`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`). Die Absagen sind keine Störung, sondern eine Messgröße
+für die *beabsichtigte* Parallelität. Sie erscheinen im Transkript wie reguläre Starts, liefern
+aber nur „Concurrent subagent limit reached" zurück und zählen nicht in `spawned` – ein Umstand,
+der einen Defekt im Auswerteskript aufdeckte (Skill 4.5.0): Vorher wurden 21 Aufrufe gegenüber 13
+erwarteten gemeldet, die Differenz waren genau diese 8 Absagen im Haupttranskript. Nach der
+Korrektur stimmen alle drei Läufe der Zelle exakt (6/6, 8/8, 13/13).
+
+**9. Einschränkung der Prompt-Erfassung durch die Verschachtelung.** Von den 31 Subagenten liegen
+nur die **13 direkt gestarteten** mit ihrem Prompt in `_meta\subagenten.md`; die 18 auf Tiefe 2
+stehen in eigenen Transkripten, die nicht persistiert werden. Ihre Tokens sind in „Tokens gesamt"
+vollständig enthalten, ihre Zerlegung ist inhaltlich **nicht** auswertbar. Von 31 gestarteten
+Subagenten wurden 30 abgeschlossen, keiner ist fehlgeschlagen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":10991364,"num_turns":106,"stop_reason":"end_turn","session_id":"4e45cfc6-414a-4e1f-a9f2-a91cd9c68ab2","total_cost_usd":37.337910000000015,"usage":{"input_tokens":172,"cache_creation_input_tokens":734322,"cache_read_input_tokens":33739949,"output_tokens":334119,"output_tokens_details":{"thinking_tokens":52494},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":734322,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":546,"cache_read_input_tokens":785714,"cache_creation_input_tokens":489,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":489},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":26,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007091,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":1702,"outputTokens":955656,"cacheReadInputTokens":91095385,"cacheCreationInputTokens":3372108,"webSearchRequests":0,"costUSD":37.33081900000001,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":31,"requested":{"background":17,"foreground":0,"unset":14},"started_in_background":31,"max_depth":2,"spawned_by_subagents":18,"completed":30,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":29,"budget":0},"by_type":{"general-purpose":21,"Explore":10}},"subtype":"success","api_error_status":null,"result":"The reverse-requirements-engineering run is complete. Summary of what was produced in `Ergebnisse/`:\n\n- **Analysebericht.md** — full 117-row module inventory (Schritt 0), coverage table (117/117 modules covered, 18 deep, 97 medium, 2 shallow-by-design), an explicit consistency check that surfaces the run's own mapping imperfections rather than hiding them, the risk-relevant requirements list, and a self-assessment with concrete follow-up recommendations (a systemic crypto weakness, AI data-flow risk, consolidation candidates).\n- **StRS.md / SyRS.md / SwRS.md** — 127 + 128 + 128 = **383 requirements**, zero duplicate IDs, every one backed by at least one artifact reference (93–97% PRIMÄR), full StRS↔SyRS↔SwRS traceability.\n- **Traceability.md** — consolidated cross-level table with primary artifact per row.\n- **Hypothesen.md** — all 27 `HYPOTHESE`-status requirements, matching the inline markers exactly.\n- **Glossar.md** — domain terms used across the specs.\n\nNotable findings surfaced along the way: a systemic weak-crypto pattern (hardcoded AES fallback keys/static IVs reused across SEPA, online banking, password manager, FinAPI, and AI-API-key storage), an unenforced negative-stock-booking permission, a dead legacy password-storage path, and personal-data exposure to external LLM providers without redaction — each captured as evidenced, risk-flagged requirements rather than left as prose commentary.","ttft_ms":15180,"ttft_stream_ms":1346,"time_to_request_ms":26,"type":"result","duration_ms":3576881,"uuid":"e549b625-cca7-4f53-9768-cf42d8338e8a","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 127 | 33,2 % |
+| SyRS | 128 | 33,4 % |
+| SwRS | 128 | 33,4 % |
+| **Gesamt** | **383** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 171 | 44,6 % |
+| Sicherheit | 89 | 23,2 % |
+| Daten | 72 | 18,8 % |
+| Schnittstelle | 31 | 8,1 % |
+| nicht-funktional | 20 | 5,2 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 438 |
+| davon `PRIMÄR` | 416 (95,0 %) |
+| davon `SEKUNDÄR` | 8 (1,8 %) |
+| davon `KONTEXT` | 14 (3,2 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 371 (96,9 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 308 | 80,4 % |
+| workaround | 23 | 6,0 % |
+| sonderfall | 30 | 7,8 % |
+| veraltet | 22 | 5,7 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 356 | 93,0 % |
+| als `HYPOTHESE` gekennzeichnet | 27 | 7,0 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 20 | 5,2 % |
+| mit ISO-25010-Qualitätsmerkmal | 20 | 5,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 3 von 122 ungedeckt: StRS-117, StRS-127, SyRS-117 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 383 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 383 von 383 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/combined_prompt.md

@@ -0,0 +1,178 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 3\claude-sonnet-5\builtin\high\02_Lauf_2026-08-26_125032_v4.4.0-fb24\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T13:50:37.1135978+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T12:50:58.8185434+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/subagenten.json

@@ -0,0 +1,233 @@
+[
+ {
+  "id": "toolu_01Da1BrziH8aukzdsyNiBH18",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Administration modules M01-M20",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. This is READ-ONLY research: do not create, edit, or modify\nANY file anywhere. Only use Read/Grep/Glob/Bash(read-only commands like find/grep/wc). The goal is to\nextract concrete, evidence-backed facts I will later turn into IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, all under `centron/Centron.WPF.UI/Modules/Administration`\nunless noted). For EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose, refine/confirm my working guess>\nFacts:\n  - Fakt: <precise technical observation, e.g. a validation rule, status transition, permission check, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method name or line range> — <short quote or paraphrase of the actual code/SQL/UI text>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <your suggested one-sentence business interpretation, \"Das System soll ...\">\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason, e.g. references to a single customer/mandator, deprecated flags, TODO/Legacy comments>\n  - (2-4 facts per module; for the two modules marked [RISK] below, gather AT LEAST 3 facts and make sure\n    at least one Beleg is PRIMÄR and names the exact enforcing method/constraint — not just a file reference)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\" statt Facts zu erfinden.\n```\n\nModules to investigate:\n- M01 Administration – Systeminfrastruktur: Administration/ (top-level files) + Administration/Cache, Connections, Customization, LogViewer, PdfExport, Profiling, Services, Settings, SqlManagers, TaskManagmentSettings, TextBlockManagement, UpdateAvailableNotificationSettings, WebServiceSettings\n- M02 Administration/CentronConfigDb\n- M03 Administration/CountryManagement\n- M04 Administration/DSGVO\n- M05 Administration/EmployeeManagement\n- M06 Administration/EscalationsSettings\n- M07 Administration/ExternalTools\n- M08 Administration/HourlySurchargeRates\n- M09 Administration/MailAndCalender\n- M10 Administration/MailTemplates\n- M11 Administration/MandatorManagement\n- M12 Administration/PdfSigning\n- M13 Administration/PhoneSettings\n- M14 Administration/ReceiptConditions\n- M15 Administration/ReportServer\n- M16 [RISK] Administration/RightsManagement — this implements role/permission checks. Also cross-check\n  `src/backend/Centron.BL/Security` and `src/backend/Centron.BL/Administration` for the actual enforcement\n  code (the UI folder is often just the editor for rights, the BL/DAO layer enforces them). Find the actual\n  method(s) that check a user's right before allowing an action, with exact signature/condition.\n- M17 Administration/SendDeliveryListShippingConfirmationSettings\n- M18 [RISK] Administration/SepaContract — SEPA direct debit mandates. Cross-check `src/backend/Centron.BL`\n  for related SEPA/mandate logic and look for IBAN/mandate-reference validation rules, and check\n  `C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql` for related tables/constraints (grep for\n  \"Sepa\" or \"Mandat\" or \"IBAN\").\n- M19 Administration/ServiceAndLeasing\n- M20 Administration/WebCart\n\nAlso skim `src/backend/Centron.BL/Administration` and `src/backend/Centron.BL/Security` briefly for\nadditional PRIMÄR-quality evidence for M16 specifically (enforced authorization checks), since risk-relevant\nmodules require a named enforcing method, not just a UI reference.\n\nReturn your findings as plain text using the structure above, one block per module, in order M01-M20.\nKeep it dense and factual — this is raw material for another process, not a human-facing report. Do not\nadd introductions or conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01BZF96mbgQXZWca6VLapjM3",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research DataExchange/AI/ExternalTool modules M21,M24-M35",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, permission check, DB constraint, mapping logic>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M21 ArtificialIntelligence (Chat, Controller, Interfaces, OfferPositionsAIEditor, OpenAIConnect, TextRating) —\n  also check `src/backend/Centron.BL/ArtificialIntelligence` for the actual OpenAI API integration logic\n  (endpoint, model, what data is sent).\n- M24 DataExchange/BookKeeping\n- M25 DataExchange/Connectors\n- M26 DataExchange/DataExport\n- M27 DataExchange/DataImport\n- M28 DataExchange/DatevOnline2020\n- M29 DataExchange/DocSync\n- M30 DataExchange/DocuForm — also check `src/apis/Centron.Api.docuFORM` for the actual API contract.\n- M31 [RISK] DataExchange/PaymentTransactions — payment data exchange; check `src/backend/Centron.BL/DataExchange`\n  and `src/backend/Centron.BL/Finances` too. Need at least one PRIMÄR beleg naming the exact\n  validating/enforcing method (e.g. IBAN checksum validation, amount/currency checks) — a bare file\n  reference is insufficient for this risk module.\n- M32 DataExchange/Rmm\n- M33 DataExchange/SupplierOrderPerBranch\n- M34 DataExchange/TelekomDive\n- M35 ExternalTool (incl. Variables subfolder)\n\nReturn findings as plain text using the structure above, one block per module, in order M21,M24-M35.\nDense and factual, no introductions/conclusions — this is raw material for another process.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_011Ux2cvth3GNTB6pizdYKGN",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Finances modules M36-M44",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS). This is a HIGH-RISK cluster (billing/invoicing logic), so\nevidence quality matters more than breadth.\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Finances/`).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg that names the exact enforcing class AND\nmethod AND the concrete condition/constraint/calculation (not just a file path) — cross-check the matching\nbusiness-logic layer in `src/backend/Centron.BL/Finances`, `src/backend/Centron.BL/Accounting`, and DB\nconstraints in `C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql` (grep for relevant table names).\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: calculation rule, status transition, validation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts per module for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M36 [RISK] Finances/AccountManagement — account/ledger management\n- M37 [RISK] Finances/AutomatedBilling — find the actual billing-run trigger logic/scheduling and the\n  calculation method (what determines invoice amount/period)\n- M38 Finances/Campaigns\n- M39 Finances/ContractEvaluation2\n- M40 Finances/ContractEvaluationOld (note: likely legacy/superseded by M39 — check for evidence, e.g.\n  deprecated markers, whether it's still referenced/called anywhere, to support a \"veraltet\" assessment)\n- M41 [RISK] Finances/Contracts — contract lifecycle, status transitions (active/terminated/renewed),\n  find exact state-machine code\n- M42 Finances/Crm\n- M43 Finances/DeviceClickCounter — device counter reading capture feeding billing\n- M44 [RISK] Finances/Dunning — dunning level escalation logic (Mahnstufen), find exact thresholds/conditions\n  in code\n\nReturn findings as plain text using the structure above, one block per module, in order M36-M44.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01SUYCtrxgw1fCLqAd53BbK5",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Finances modules M45-M52",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS). This is a HIGH-RISK cluster (billing/invoicing/payments), so\nevidence quality matters more than breadth.\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Finances/`).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg that names the exact enforcing class AND\nmethod AND the concrete condition/constraint/calculation (not just a file path) — cross-check\n`src/backend/Centron.BL/Finances`, `src/backend/Centron.BL/Accounting`, `src/backend/Centron.BL/Transactions`\nand DB constraints in `C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql`.\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts per module for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M45 [RISK] Finances/FlatrateBilling — flat-rate billing calculation, find exact rule for how flatrate\n  periods/overage are computed\n- M46 Finances/MasterDataLists\n- M47 [RISK] Finances/Opos — open-item (Offene Posten) management, find matching/clearing logic\n- M48 [RISK] Finances/Payments — payment processing/allocation, find exact validation (amount matching,\n  duplicate payment prevention if any)\n- M49 Finances/ProductLifecycleManagement\n- M50 Finances/Projects — project billing\n- M51 [RISK] Finances/Receipts — invoice/credit-note generation, find the exact numbering scheme\n  (Rechnungsnummernkreis) enforcement and any immutability/finalization check (e.g. can a booked invoice\n  be edited?)\n- M52 [RISK] Finances/TimerBilling — time-tracking based billing, find the exact rate calculation logic\n\nReturn findings as plain text using the structure above, one block per module, in order M45-M52.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_013eetLtVftLJYRmL9xy78bY",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Global/Gui/Helpdesk/Calendar/Dashboard modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, permission check, mapping logic>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M22 Calendar (incl. Settings)\n- M23 Dashboard (incl. Modules subfolder)\n- M53 Global (Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help,\n  MSPLicensesCompare, NetworkDiagnostics, PerformanceTests, VideoPortal)\n- M54 Gui (incl. Profiles)\n- M55 Helpdesk (top-level: TicketList, TicketDetails, Events, ExpectedEvents, ExpectedEventsReporting,\n  ConnectionNumber) — ticketing core workflow, find the status/state machine of a ticket\n- M56 Helpdesk/CentronChecklist\n- M57 Helpdesk/Dashboard\n- M58 Helpdesk/SendSelfCareForm\n- M59 Helpdesk/TaskManagement\n- M60 Helpdesk/TicketProcessTemplates\n\nReturn findings as plain text using the structure above, one block per module, in order M22,M23,M53-M60.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01Wkh8wB4kfYXX2bZFSRzcgq",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Logistic/MyCentron/OnlineBanking/PasswordManager modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand condition (not just a file path) — cross-check `src/backend/Centron.BL` and\n`src/shared/Centron.Core` (e.g. TotpAuth, GoogleAuthenticator folders) and\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql` for related tables/constraints.\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M61 Logistic (incl. LogisticSettings, ShippingMethodSettings)\n- M62 Massenupdates (Event, Updates) — mass-update mechanism; find whether there's any safeguard/undo/\n  confirmation before bulk changes are applied (important for risk assessment of accidental mass changes)\n- M63 MyCentron (Calendar, Dashboard, MyDay, PersonalSettings, TodoList)\n- M64 MyCentron/CentronInspectors\n- M65 MyCentron/Supremo — remote support tool integration\n- M66 MyCentron/Telephony\n- M67 [RISK] OnlineBanking (AccountTransactions, ConfigurationSettings, ConnectionDialog) — find how bank\n  credentials/connection data are stored and whether transactions are validated/reconciled\n- M68 PLM\n- M69 [RISK] PasswordManager (LayoutSaving, Settings) — internal password storage; find EXACTLY how\n  passwords are encrypted/hashed/stored (critical finding) — check `src/backend/Centron.BL/PasswordManager`\n  and `PasswordManagementArea`, and `src/shared/Centron.Core` crypto helpers\n- M70 PayersAndCostCenter (DTOViewModel, OpenDialog)\n\nReturn findings as plain text using the structure above, one block per module, in order\nM61-M70. Dense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_019cSuBXEDqPzmC5Gnh2ocwu",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Production/ProjectManagement/Purchasing modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, calculation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module; for Purchasing/TravelExpense look for approval-workflow logic (Reisekosten\n    genehmigen) which borders on risk-relevant financial control — get at least 3 facts with one PRIMÄR)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M71 Production (MachineManagement, ProductionOrder, Settings) — find the production order status\n  state machine\n- M72 ProjectManagement\n- M73 ProjectPriceImport (PriceDifference, Settings)\n- M74 Purchasing (top-level: Others, PurchaseSettings) — purchase order core process, status transitions\n- M75 Purchasing/EDIManagement\n- M76 Purchasing/OrderSuggestionList — check the algorithm/threshold that triggers a reorder suggestion\n  (e.g. minimum stock level)\n- M77 Purchasing/TravelExpense\n\nReturn findings as plain text using the structure above, one block per module, in order M71-M77.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01Dp4djPZkSRLEU1gUrJ3X5M",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research QM/Reports/Rma/Sales modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, calculation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M78 QM (incl. Settings)\n- M79 Reports (incl. ReportManagement)\n- M80 Rma (top-level: NewRma, Events) — find the RMA status state machine (created -> approved -> received -> ...)\n- M81 Rma/RmaSettings\n- M82 Rma/SendBack — return-to-supplier workflow\n- M83 Rma/SendForth — forward-to-customer (replacement) workflow\n- M84 Sales (top-level order/offer core process) — find the offer->order status transition and any\n  approval/discount-limit check\n- M85 Sales/Mailing\n- M86 Sales/ProductMatrix — product configurator logic\n- M87 Sales/SpecialArticleImport\n- M88 Sales/SpecialArticleToContractImport\n\nReturn findings as plain text using the structure above, one block per module, in order M78-M88.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01QPkTxN8nCW7uRaT3zdQV4E",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Statistics/Survey/TelekomDive modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M89 Statistics (top-level: Dashboard, ManagementInfo)\n- M90 Statistics/EmployeeAnalytics\n- M91 Statistics/MspCollectors + Statistics/MspStatistics\n- M92 Statistics/SaleStatistics\n- M93 Survey (Pages, SurveySettings)\n- M94 TelekomDive (UI part, ViewModels) — also glance at\n  `centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive` to distinguish the UI module from the data-\n  exchange counterpart\n\nReturn findings as plain text using the structure above, one block per module, in order M89-M94.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01NUicMKpimJuhmVsn8qNPnb",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Warehousing modules M95-M100",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`\nunless noted). For EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, stock calculation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M95 Warehousing (top-level core process) — find the article stock-movement/reservation logic\n- M96 Warehousing/ArticleImport\n- M97 Warehousing/ArticleManagement\n- M98 Warehousing/ArticleUnitManagement\n- M99 Warehousing/BarcodeManagement\n- M100 Warehousing/Commissioning + Warehousing/Commissions — find the commission/provision calculation\n  rule (percentage, base amount)\n\nAlso check `src/backend/Centron.BL/Warehousing` for the underlying stock-quantity enforcement (e.g. can\nstock go negative? is there a check?).\n\nReturn findings as plain text using the structure above, one block per module, in order M95-M100.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01AbeNdPZrcdNP1xa9SKP8XK",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research Warehousing modules M101-M105",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand the concrete check/constraint (not just a file reference) — cross-check\n`src/backend/Centron.BL/Warehousing` and DB constraints in\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql`.\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M101 Warehousing/Inventory — physical inventory count process, find discrepancy-handling logic\n- M102 Warehousing/MaterialGroupManagement\n- M103 [RISK] Warehousing/OutcomingPayments — cash/payment handling at warehouse level, find exact\n  validation of payment amounts/cash register balancing\n- M104 [RISK] Warehousing/AccountSystems — cash register/POS system integration, find how transactions\n  are reconciled/secured\n- M105 Warehousing/SearchArticle + Warehousing/SupplierSearch\n\nReturn findings as plain text using the structure above, one block per module, in order M101-M105.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_013xXC4Br7aeBFEQzh1GxBqj",
+  "werkzeug": "Agent",
+  "subagent_type": "general-purpose",
+  "description": "Research external APIs, Nexus, webservice, shared infra",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use\nin IEEE 29148 requirements (StRS/SyRS/SwRS), specifically for SYSTEM-level interface and security\nrequirements (SyRS/SwRS), since these are technical components rather than end-user business modules.\n\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand concrete check (not just a file reference).\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business/technical purpose>\nFacts:\n  - Fakt: <precise technical observation: auth mechanism, API contract, data mapping, encryption, versioning>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M106 Externe Warenwirtschafts-APIs: `src/apis/Centron.APIs.ITscopeDataAccess`,\n  `src/apis/Centron.APIs.IcecatDataAccess`, `src/apis/Centron.APIs.CopDataAccess`,\n  `src/apis/Centron.APIs.EgisDataAccess` — product-catalog data integration partners\n- M107 [RISK] FinAPI-Anbindung: `src/apis/Centron.APIs.FinAPI` — bank account data retrieval; find how\n  credentials/tokens are handled\n- M108 Versand-/Rechnungs-Schnittstellen: `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud`,\n  `src/apis/Centron.Api.EbInterface`\n- M109 docuFORM-API: `src/apis/Centron.Api.docuFORM`\n- M110 CentronNexus – Kern: `src/nexus/CentronNexus` top-level + Controllers, Management, Settings,\n  Shared, Utils, Configuration\n- M111 [RISK] CentronNexus/DocumentSigning: `src/nexus/CentronNexus/DocumentSigning`\n- M112 CentronNexus/Office: `src/nexus/CentronNexus/Office`\n- M113 CentronNexus/ProductionOrderManagement: `src/nexus/CentronNexus/ProductionOrderManagement`\n- M114 CentronNexus/ServiceBoard: `src/nexus/CentronNexus/ServiceBoard`\n- M115 CentronNexus/WebCart + WebOffer: `src/nexus/CentronNexus/WebCart`, `src/nexus/CentronNexus/WebOffer`\n- M116 [RISK] Webservice-API-Schicht: `src/webservice/Centron.Controllers` (esp. Authorization subfolder),\n  `src/webservice/Centron.Host*`, `src/webservice/c-entron.misc.ConnectionManager` — find the exact\n  authentication mechanism (token type, validation method) protecting the API\n- M117 Shared-Infrastruktur: `src/shared/Centron.Core` (esp. TotpAuth, GoogleAuthenticator subfolders),\n  `src/shared/Centron.Controls` — cross-cutting helper libraries, find any reusable auth/crypto helpers\n\nReturn findings as plain text using the structure above, one block per module, in order M106-M117.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01UkEFDRivw4gVszRap9QkrQ",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Statistics/Survey/TelekomDive modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M89 Statistics (top-level: Dashboard, ManagementInfo)\n- M90 Statistics/EmployeeAnalytics\n- M91 Statistics/MspCollectors + Statistics/MspStatistics\n- M92 Statistics/SaleStatistics\n- M93 Survey (Pages, SurveySettings)\n- M94 TelekomDive (UI part, ViewModels) — also glance at\n  `centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive` to distinguish the UI module from the data-\n  exchange counterpart\n\nReturn findings as plain text using the structure above, one block per module, in order M89-M94.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01WCGbgfMoRqkDg9SjpmaYBo",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Warehousing modules M95-M100",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`\nunless noted). For EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, stock calculation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M95 Warehousing (top-level core process) — find the article stock-movement/reservation logic\n- M96 Warehousing/ArticleImport\n- M97 Warehousing/ArticleManagement\n- M98 Warehousing/ArticleUnitManagement\n- M99 Warehousing/BarcodeManagement\n- M100 Warehousing/Commissioning + Warehousing/Commissions — find the commission/provision calculation\n  rule (percentage, base amount)\n\nAlso check `src/backend/Centron.BL/Warehousing` for the underlying stock-quantity enforcement (e.g. can\nstock go negative? is there a check?).\n\nReturn findings as plain text using the structure above, one block per module, in order M95-M100.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01A6E3FeNmy9U7m4BHDPVNVe",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Warehousing modules M101-M105",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand the concrete check/constraint (not just a file reference) — cross-check\n`src/backend/Centron.BL/Warehousing` and DB constraints in\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql`.\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M101 Warehousing/Inventory — physical inventory count process, find discrepancy-handling logic\n- M102 Warehousing/MaterialGroupManagement\n- M103 [RISK] Warehousing/OutcomingPayments — cash/payment handling at warehouse level, find exact\n  validation of payment amounts/cash register balancing\n- M104 [RISK] Warehousing/AccountSystems — cash register/POS system integration, find how transactions\n  are reconciled/secured\n- M105 Warehousing/SearchArticle + Warehousing/SupplierSearch\n\nReturn findings as plain text using the structure above, one block per module, in order M101-M105.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01F44ktnBBMfXQSxrsesLPU5",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research external APIs, Nexus, webservice, shared infra",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS), specifically for SYSTEM-level interface and security requirements\n(SyRS/SwRS), since these are technical components rather than end-user business modules.\n\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand concrete check (not just a file reference).\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business/technical purpose>\nFacts:\n  - Fakt: <precise technical observation: auth mechanism, API contract, data mapping, encryption, versioning>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M106 Externe Warenwirtschafts-APIs: `src/apis/Centron.APIs.ITscopeDataAccess`,\n  `src/apis/Centron.APIs.IcecatDataAccess`, `src/apis/Centron.APIs.CopDataAccess`,\n  `src/apis/Centron.APIs.EgisDataAccess` — product-catalog data integration partners\n- M107 [RISK] FinAPI-Anbindung: `src/apis/Centron.APIs.FinAPI` — bank account data retrieval; find how\n  credentials/tokens are handled\n- M108 Versand-/Rechnungs-Schnittstellen: `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud`,\n  `src/apis/Centron.Api.EbInterface`\n- M109 docuFORM-API: `src/apis/Centron.Api.docuFORM`\n- M110 CentronNexus – Kern: `src/nexus/CentronNexus` top-level + Controllers, Management, Settings,\n  Shared, Utils, Configuration\n- M111 [RISK] CentronNexus/DocumentSigning: `src/nexus/CentronNexus/DocumentSigning`\n- M112 CentronNexus/Office: `src/nexus/CentronNexus/Office`\n- M113 CentronNexus/ProductionOrderManagement: `src/nexus/CentronNexus/ProductionOrderManagement`\n- M114 CentronNexus/ServiceBoard: `src/nexus/CentronNexus/ServiceBoard`\n- M115 CentronNexus/WebCart + WebOffer: `src/nexus/CentronNexus/WebCart`, `src/nexus/CentronNexus/WebOffer`\n- M116 [RISK] Webservice-API-Schicht: `src/webservice/Centron.Controllers` (esp. Authorization subfolder),\n  `src/webservice/Centron.Host*`, `src/webservice/c-entron.misc.ConnectionManager` — find the exact\n  authentication mechanism (token type, validation method) protecting the API\n- M117 Shared-Infrastruktur: `src/shared/Centron.Core` (esp. TotpAuth, GoogleAuthenticator subfolders),\n  `src/shared/Centron.Controls` — cross-cutting helper libraries, find any reusable auth/crypto helpers\n\nReturn findings as plain text using the structure above, one block per module, in order M106-M117.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 186,
+  "abgewiesen": true
+ },
+ {
+  "id": "toolu_01VH7ZXHTeQG8F4R7Kfrow7x",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Statistics/Survey/TelekomDive modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M89 Statistics (top-level: Dashboard, ManagementInfo)\n- M90 Statistics/EmployeeAnalytics\n- M91 Statistics/MspCollectors + Statistics/MspStatistics\n- M92 Statistics/SaleStatistics\n- M93 Survey (Pages, SurveySettings)\n- M94 TelekomDive (UI part, ViewModels) — also glance at\n  `centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive` to distinguish the UI module from the data-\n  exchange counterpart\n\nReturn findings as plain text using the structure above, one block per module, in order M89-M94.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_011tgQ811WRi2BzmDxMSsawm",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Warehousing modules M95-M100",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`\nunless noted). For EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation: validation rule, status transition, stock calculation, DB constraint>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (2-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M95 Warehousing (top-level core process) — find the article stock-movement/reservation logic\n- M96 Warehousing/ArticleImport\n- M97 Warehousing/ArticleManagement\n- M98 Warehousing/ArticleUnitManagement\n- M99 Warehousing/BarcodeManagement\n- M100 Warehousing/Commissioning + Warehousing/Commissions — find the commission/provision calculation\n  rule (percentage, base amount)\n\nAlso check `src/backend/Centron.BL/Warehousing` for the underlying stock-quantity enforcement (e.g. can\nstock go negative? is there a check?).\n\nReturn findings as plain text using the structure above, one block per module, in order M95-M100.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01KLUcgM1gG6ahSMiNbm2G5j",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Warehousing modules M101-M105",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`).\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand the concrete check/constraint (not just a file reference) — cross-check\n`src/backend/Centron.BL/Warehousing` and DB constraints in\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\SSMS_DB_SCHEMA.sql`.\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M101 Warehousing/Inventory — physical inventory count process, find discrepancy-handling logic\n- M102 Warehousing/MaterialGroupManagement\n- M103 [RISK] Warehousing/OutcomingPayments — cash/payment handling at warehouse level, find exact\n  validation of payment amounts/cash register balancing\n- M104 [RISK] Warehousing/AccountSystems — cash register/POS system integration, find how transactions\n  are reconciled/secured\n- M105 Warehousing/SearchArticle + Warehousing/SupplierSearch\n\nReturn findings as plain text using the structure above, one block per module, in order M101-M105.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_013GNKgwMr43fDqj8krwMwkW",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research external APIs, Nexus, webservice, shared infra",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS), specifically for SYSTEM-level interface and security requirements\n(SyRS/SwRS), since these are technical components rather than end-user business modules.\n\nFor risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method\nand concrete check (not just a file reference).\n\nFor EACH module produce a report block with this exact structure:\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business/technical purpose>\nFacts:\n  - Fakt: <precise technical observation: auth mechanism, API contract, data mapping, encryption, versioning>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-5 facts for RISK modules, 2-3 for others)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M106 Externe Warenwirtschafts-APIs: `src/apis/Centron.APIs.ITscopeDataAccess`,\n  `src/apis/Centron.APIs.IcecatDataAccess`, `src/apis/Centron.APIs.CopDataAccess`,\n  `src/apis/Centron.APIs.EgisDataAccess` — product-catalog data integration partners\n- M107 [RISK] FinAPI-Anbindung: `src/apis/Centron.APIs.FinAPI` — bank account data retrieval; find how\n  credentials/tokens are handled\n- M108 Versand-/Rechnungs-Schnittstellen: `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud`,\n  `src/apis/Centron.Api.EbInterface`\n- M109 docuFORM-API: `src/apis/Centron.Api.docuFORM`\n- M110 CentronNexus – Kern: `src/nexus/CentronNexus` top-level + Controllers, Management, Settings,\n  Shared, Utils, Configuration\n- M111 [RISK] CentronNexus/DocumentSigning: `src/nexus/CentronNexus/DocumentSigning`\n- M112 CentronNexus/Office: `src/nexus/CentronNexus/Office`\n- M113 CentronNexus/ProductionOrderManagement: `src/nexus/CentronNexus/ProductionOrderManagement`\n- M114 CentronNexus/ServiceBoard: `src/nexus/CentronNexus/ServiceBoard`\n- M115 CentronNexus/WebCart + WebOffer: `src/nexus/CentronNexus/WebCart`, `src/nexus/CentronNexus/WebOffer`\n- M116 [RISK] Webservice-API-Schicht: `src/webservice/Centron.Controllers` (esp. Authorization subfolder),\n  `src/webservice/Centron.Host*`, `src/webservice/c-entron.misc.ConnectionManager` — find the exact\n  authentication mechanism (token type, validation method) protecting the API\n- M117 Shared-Infrastruktur: `src/shared/Centron.Core` (esp. TotpAuth, GoogleAuthenticator subfolders),\n  `src/shared/Centron.Controls` — cross-cutting helper libraries, find any reusable auth/crypto helpers\n\nReturn findings as plain text using the structure above, one block per module, in order M106-M117.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ },
+ {
+  "id": "toolu_01EeCiBEwsRL2FFhW6g7E4A3",
+  "werkzeug": "Agent",
+  "subagent_type": "Explore",
+  "description": "Research Finances M42/M43/M44 gap modules",
+  "run_in_background": true,
+  "model": null,
+  "prompt": "You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at\n`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file\nanywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148\nrequirements (StRS/SyRS/SwRS).\n\nInvestigate these three modules (paths relative to `src/centron/Centron.WPF.UI/Modules/Finances/`).\nM44 (Dunning) is risk-relevant (billing/collections) — find at least one PRIMÄR beleg naming the exact\nenforcing method/condition for dunning-level escalation.\n\n```\n### <ModuleID> <ModuleName>\nPfad: <path>\nAufgabe: <one German sentence on business purpose>\nFacts:\n  - Fakt: <precise technical observation>\n    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>\n    Begründung: <why this evidence supports the Fakt>\n    Aussage-Hinweis: <\"Das System soll ...\" one sentence>\n    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>\n  - (3-4 facts per module)\nFalls nichts Belegbares gefunden wurde: schreibe \"Nicht belegbar: <Grund>\".\n```\n\nModules:\n- M42 Finances/Crm — customer relationship management, check `src/backend/Centron.BL/Sales/Customers/Crm` or\n  similar for the actual activity/interaction tracking logic\n- M43 Finances/DeviceClickCounter — device meter/counter reading capture feeding billing (distinct from\n  MasterDataLists/Counters which handles related but separate functionality — focus specifically on files\n  directly under `Modules/Finances/DeviceClickCounter`)\n- M44 [RISK] Finances/Dunning — dunning level escalation logic (Mahnstufen); cross-check\n  `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs` for the exact method that\n  determines/advances a customer's or invoice's dunning level (Mahnstufe), separate from the read-only\n  \"GenerateInvoiceExpression\" filter already documented elsewhere — look for where DunningLevel actually\n  gets incremented/written, and any escalation letter/fee logic.\n\nReturn findings as plain text using the structure above, one block per module, in order M42, M43, M44.\nDense and factual, no introductions/conclusions.",
+  "ergebnis_zeichen": 1093,
+  "abgewiesen": false
+ }
+]

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/builtin/high/02_Lauf_2026-08-26_125032_v4.4.0-fb24/_meta/subagenten.md

@@ -0,0 +1,681 @@
+# Subagenten-Aufrufe
+
+Session `4e45cfc6-414a-4e1f-a9f2-a91cd9c68ab2`, Transkript `4e45cfc6-414a-4e1f-a9f2-a91cd9c68ab2.jsonl`.
+
+`subagent_stats`: **31** Subagenten gesamt, davon **18** von Subagenten gestartet (max_depth 2). Direkt vom Hauptagenten erwartet: **13**. Im Transkript gefunden: **13** echte Starts und **8** am Nebenlaeufigkeitslimit abgewiesene Aufrufe.
+
+> Die 18 von Subagenten gestarteten Aufrufe stehen in deren eigenen Transkripten und sind hier **nicht** enthalten.
+
+> **8 Aufrufe wurden am Nebenlaeufigkeitslimit abgewiesen** (`subagent_stats.refused.concurrency_limit` = 29) und sind unten **nicht** aufgefuehrt. Sie erscheinen im Transkript wie regulaere Starts, liefern aber nur die Absage zurueck und zaehlen nicht in `spawned`. Fuer die Auswertung der selbstgewaehlten Zerlegung sind sie dennoch aufschlussreich: Der Hauptagent wollte staerker parallelisieren, als das Werkzeug zuliess.
+
+## 1. Research Administration modules M01-M20
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 3904  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. This is READ-ONLY research: do not create, edit, or modify
+ANY file anywhere. Only use Read/Grep/Glob/Bash(read-only commands like find/grep/wc). The goal is to
+extract concrete, evidence-backed facts I will later turn into IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, all under `centron/Centron.WPF.UI/Modules/Administration`
+unless noted). For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose, refine/confirm my working guess>
+Facts:
+  - Fakt: <precise technical observation, e.g. a validation rule, status transition, permission check, DB constraint>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method name or line range> — <short quote or paraphrase of the actual code/SQL/UI text>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <your suggested one-sentence business interpretation, "Das System soll ...">
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason, e.g. references to a single customer/mandator, deprecated flags, TODO/Legacy comments>
+  - (2-4 facts per module; for the two modules marked [RISK] below, gather AT LEAST 3 facts and make sure
+    at least one Beleg is PRIMÄR and names the exact enforcing method/constraint — not just a file reference)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>" statt Facts zu erfinden.
+```
+
+Modules to investigate:
+- M01 Administration – Systeminfrastruktur: Administration/ (top-level files) + Administration/Cache, Connections, Customization, LogViewer, PdfExport, Profiling, Services, Settings, SqlManagers, TaskManagmentSettings, TextBlockManagement, UpdateAvailableNotificationSettings, WebServiceSettings
+- M02 Administration/CentronConfigDb
+- M03 Administration/CountryManagement
+- M04 Administration/DSGVO
+- M05 Administration/EmployeeManagement
+- M06 Administration/EscalationsSettings
+- M07 Administration/ExternalTools
+- M08 Administration/HourlySurchargeRates
+- M09 Administration/MailAndCalender
+- M10 Administration/MailTemplates
+- M11 Administration/MandatorManagement
+- M12 Administration/PdfSigning
+- M13 Administration/PhoneSettings
+- M14 Administration/ReceiptConditions
+- M15 Administration/ReportServer
+- M16 [RISK] Administration/RightsManagement — this implements role/permission checks. Also cross-check
+  `src/backend/Centron.BL/Security` and `src/backend/Centron.BL/Administration` for the actual enforcement
+  code (the UI folder is often just the editor for rights, the BL/DAO layer enforces them). Find the actual
+  method(s) that check a user's right before allowing an action, with exact signature/condition.
+- M17 Administration/SendDeliveryListShippingConfirmationSettings
+- M18 [RISK] Administration/SepaContract — SEPA direct debit mandates. Cross-check `src/backend/Centron.BL`
+  for related SEPA/mandate logic and look for IBAN/mandate-reference validation rules, and check
+  `C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql` for related tables/constraints (grep for
+  "Sepa" or "Mandat" or "IBAN").
+- M19 Administration/ServiceAndLeasing
+- M20 Administration/WebCart
+
+Also skim `src/backend/Centron.BL/Administration` and `src/backend/Centron.BL/Security` briefly for
+additional PRIMÄR-quality evidence for M16 specifically (enforced authorization checks), since risk-relevant
+modules require a named enforcing method, not just a UI reference.
+
+Return your findings as plain text using the structure above, one block per module, in order M01-M20.
+Keep it dense and factual — this is raw material for another process, not a human-facing report. Do not
+add introductions or conclusions.
+```
+
+## 2. Research DataExchange/AI/ExternalTool modules M21,M24-M35
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2429  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: validation rule, status transition, permission check, DB constraint, mapping logic>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M21 ArtificialIntelligence (Chat, Controller, Interfaces, OfferPositionsAIEditor, OpenAIConnect, TextRating) —
+  also check `src/backend/Centron.BL/ArtificialIntelligence` for the actual OpenAI API integration logic
+  (endpoint, model, what data is sent).
+- M24 DataExchange/BookKeeping
+- M25 DataExchange/Connectors
+- M26 DataExchange/DataExport
+- M27 DataExchange/DataImport
+- M28 DataExchange/DatevOnline2020
+- M29 DataExchange/DocSync
+- M30 DataExchange/DocuForm — also check `src/apis/Centron.Api.docuFORM` for the actual API contract.
+- M31 [RISK] DataExchange/PaymentTransactions — payment data exchange; check `src/backend/Centron.BL/DataExchange`
+  and `src/backend/Centron.BL/Finances` too. Need at least one PRIMÄR beleg naming the exact
+  validating/enforcing method (e.g. IBAN checksum validation, amount/currency checks) — a bare file
+  reference is insufficient for this risk module.
+- M32 DataExchange/Rmm
+- M33 DataExchange/SupplierOrderPerBranch
+- M34 DataExchange/TelekomDive
+- M35 ExternalTool (incl. Variables subfolder)
+
+Return findings as plain text using the structure above, one block per module, in order M21,M24-M35.
+Dense and factual, no introductions/conclusions — this is raw material for another process.
+```
+
+## 3. Research Finances modules M36-M44
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2731  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS). This is a HIGH-RISK cluster (billing/invoicing logic), so
+evidence quality matters more than breadth.
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Finances/`).
+For risk-flagged modules you MUST find at least one PRIMÄR beleg that names the exact enforcing class AND
+method AND the concrete condition/constraint/calculation (not just a file path) — cross-check the matching
+business-logic layer in `src/backend/Centron.BL/Finances`, `src/backend/Centron.BL/Accounting`, and DB
+constraints in `C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql` (grep for relevant table names).
+
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: calculation rule, status transition, validation, DB constraint>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-5 facts per module for RISK modules, 2-3 for others)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M36 [RISK] Finances/AccountManagement — account/ledger management
+- M37 [RISK] Finances/AutomatedBilling — find the actual billing-run trigger logic/scheduling and the
+  calculation method (what determines invoice amount/period)
+- M38 Finances/Campaigns
+- M39 Finances/ContractEvaluation2
+- M40 Finances/ContractEvaluationOld (note: likely legacy/superseded by M39 — check for evidence, e.g.
+  deprecated markers, whether it's still referenced/called anywhere, to support a "veraltet" assessment)
+- M41 [RISK] Finances/Contracts — contract lifecycle, status transitions (active/terminated/renewed),
+  find exact state-machine code
+- M42 Finances/Crm
+- M43 Finances/DeviceClickCounter — device counter reading capture feeding billing
+- M44 [RISK] Finances/Dunning — dunning level escalation logic (Mahnstufen), find exact thresholds/conditions
+  in code
+
+Return findings as plain text using the structure above, one block per module, in order M36-M44.
+Dense and factual, no introductions/conclusions.
+```
+
+## 4. Research Finances modules M45-M52
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2593  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS). This is a HIGH-RISK cluster (billing/invoicing/payments), so
+evidence quality matters more than breadth.
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Finances/`).
+For risk-flagged modules you MUST find at least one PRIMÄR beleg that names the exact enforcing class AND
+method AND the concrete condition/constraint/calculation (not just a file path) — cross-check
+`src/backend/Centron.BL/Finances`, `src/backend/Centron.BL/Accounting`, `src/backend/Centron.BL/Transactions`
+and DB constraints in `C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql`.
+
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-5 facts per module for RISK modules, 2-3 for others)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M45 [RISK] Finances/FlatrateBilling — flat-rate billing calculation, find exact rule for how flatrate
+  periods/overage are computed
+- M46 Finances/MasterDataLists
+- M47 [RISK] Finances/Opos — open-item (Offene Posten) management, find matching/clearing logic
+- M48 [RISK] Finances/Payments — payment processing/allocation, find exact validation (amount matching,
+  duplicate payment prevention if any)
+- M49 Finances/ProductLifecycleManagement
+- M50 Finances/Projects — project billing
+- M51 [RISK] Finances/Receipts — invoice/credit-note generation, find the exact numbering scheme
+  (Rechnungsnummernkreis) enforcement and any immutability/finalization check (e.g. can a booked invoice
+  be edited?)
+- M52 [RISK] Finances/TimerBilling — time-tracking based billing, find the exact rate calculation logic
+
+Return findings as plain text using the structure above, one block per module, in order M45-M52.
+Dense and factual, no introductions/conclusions.
+```
+
+## 5. Research Global/Gui/Helpdesk/Calendar/Dashboard modules
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1956  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: validation rule, status transition, permission check, mapping logic>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M22 Calendar (incl. Settings)
+- M23 Dashboard (incl. Modules subfolder)
+- M53 Global (Actions, CustomProperties, EmployeeSelection, ExceptionMessage, FileSystemDialog, Help,
+  MSPLicensesCompare, NetworkDiagnostics, PerformanceTests, VideoPortal)
+- M54 Gui (incl. Profiles)
+- M55 Helpdesk (top-level: TicketList, TicketDetails, Events, ExpectedEvents, ExpectedEventsReporting,
+  ConnectionNumber) — ticketing core workflow, find the status/state machine of a ticket
+- M56 Helpdesk/CentronChecklist
+- M57 Helpdesk/Dashboard
+- M58 Helpdesk/SendSelfCareForm
+- M59 Helpdesk/TaskManagement
+- M60 Helpdesk/TicketProcessTemplates
+
+Return findings as plain text using the structure above, one block per module, in order M22,M23,M53-M60.
+Dense and factual, no introductions/conclusions.
+```
+
+## 6. Research Logistic/MyCentron/OnlineBanking/PasswordManager modules
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2640  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/` unless noted).
+For risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method
+and condition (not just a file path) — cross-check `src/backend/Centron.BL` and
+`src/shared/Centron.Core` (e.g. TotpAuth, GoogleAuthenticator folders) and
+`C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql` for related tables/constraints.
+
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-5 facts for RISK modules, 2-3 for others)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M61 Logistic (incl. LogisticSettings, ShippingMethodSettings)
+- M62 Massenupdates (Event, Updates) — mass-update mechanism; find whether there's any safeguard/undo/
+  confirmation before bulk changes are applied (important for risk assessment of accidental mass changes)
+- M63 MyCentron (Calendar, Dashboard, MyDay, PersonalSettings, TodoList)
+- M64 MyCentron/CentronInspectors
+- M65 MyCentron/Supremo — remote support tool integration
+- M66 MyCentron/Telephony
+- M67 [RISK] OnlineBanking (AccountTransactions, ConfigurationSettings, ConnectionDialog) — find how bank
+  credentials/connection data are stored and whether transactions are validated/reconciled
+- M68 PLM
+- M69 [RISK] PasswordManager (LayoutSaving, Settings) — internal password storage; find EXACTLY how
+  passwords are encrypted/hashed/stored (critical finding) — check `src/backend/Centron.BL/PasswordManager`
+  and `PasswordManagementArea`, and `src/shared/Centron.Core` crypto helpers
+- M70 PayersAndCostCenter (DTOViewModel, OpenDialog)
+
+Return findings as plain text using the structure above, one block per module, in order
+M61-M70. Dense and factual, no introductions/conclusions.
+```
+
+## 7. Research Production/ProjectManagement/Purchasing modules
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1977  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: validation rule, status transition, calculation, DB constraint>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module; for Purchasing/TravelExpense look for approval-workflow logic (Reisekosten
+    genehmigen) which borders on risk-relevant financial control — get at least 3 facts with one PRIMÄR)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M71 Production (MachineManagement, ProductionOrder, Settings) — find the production order status
+  state machine
+- M72 ProjectManagement
+- M73 ProjectPriceImport (PriceDifference, Settings)
+- M74 Purchasing (top-level: Others, PurchaseSettings) — purchase order core process, status transitions
+- M75 Purchasing/EDIManagement
+- M76 Purchasing/OrderSuggestionList — check the algorithm/threshold that triggers a reorder suggestion
+  (e.g. minimum stock level)
+- M77 Purchasing/TravelExpense
+
+Return findings as plain text using the structure above, one block per module, in order M71-M77.
+Dense and factual, no introductions/conclusions.
+```
+
+## 8. Research QM/Reports/Rma/Sales modules
+
+- **Werkzeug:** `Agent`  **Typ:** `general-purpose`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1903  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Only use Read/Grep/Glob/Bash(read-only). Extract concrete, evidence-backed facts for later use
+in IEEE 29148 requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: validation rule, status transition, calculation, DB constraint>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M78 QM (incl. Settings)
+- M79 Reports (incl. ReportManagement)
+- M80 Rma (top-level: NewRma, Events) — find the RMA status state machine (created -> approved -> received -> ...)
+- M81 Rma/RmaSettings
+- M82 Rma/SendBack — return-to-supplier workflow
+- M83 Rma/SendForth — forward-to-customer (replacement) workflow
+- M84 Sales (top-level order/offer core process) — find the offer->order status transition and any
+  approval/discount-limit check
+- M85 Sales/Mailing
+- M86 Sales/ProductMatrix — product configurator logic
+- M87 Sales/SpecialArticleImport
+- M88 Sales/SpecialArticleToContractImport
+
+Return findings as plain text using the structure above, one block per module, in order M78-M88.
+Dense and factual, no introductions/conclusions.
+```
+
+## 9. Research Statistics/Survey/TelekomDive modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1630  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148
+requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/`).
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M89 Statistics (top-level: Dashboard, ManagementInfo)
+- M90 Statistics/EmployeeAnalytics
+- M91 Statistics/MspCollectors + Statistics/MspStatistics
+- M92 Statistics/SaleStatistics
+- M93 Survey (Pages, SurveySettings)
+- M94 TelekomDive (UI part, ViewModels) — also glance at
+  `centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive` to distinguish the UI module from the data-
+  exchange counterpart
+
+Return findings as plain text using the structure above, one block per module, in order M89-M94.
+Dense and factual, no introductions/conclusions.
+```
+
+## 10. Research Warehousing modules M95-M100
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 1843  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148
+requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`
+unless noted). For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation: validation rule, status transition, stock calculation, DB constraint>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (2-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M95 Warehousing (top-level core process) — find the article stock-movement/reservation logic
+- M96 Warehousing/ArticleImport
+- M97 Warehousing/ArticleManagement
+- M98 Warehousing/ArticleUnitManagement
+- M99 Warehousing/BarcodeManagement
+- M100 Warehousing/Commissioning + Warehousing/Commissions — find the commission/provision calculation
+  rule (percentage, base amount)
+
+Also check `src/backend/Centron.BL/Warehousing` for the underlying stock-quantity enforcement (e.g. can
+stock go negative? is there a check?).
+
+Return findings as plain text using the structure above, one block per module, in order M95-M100.
+Dense and factual, no introductions/conclusions.
+```
+
+## 11. Research Warehousing modules M101-M105
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2053  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148
+requirements (StRS/SyRS/SwRS).
+
+Investigate these modules (paths relative to `src/`, under `centron/Centron.WPF.UI/Modules/Warehousing/`).
+For risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method
+and the concrete check/constraint (not just a file reference) — cross-check
+`src/backend/Centron.BL/Warehousing` and DB constraints in
+`C:\DEV\MasterArbeit\QuellCode\CentronERP\SSMS_DB_SCHEMA.sql`.
+
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-5 facts for RISK modules, 2-3 for others)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M101 Warehousing/Inventory — physical inventory count process, find discrepancy-handling logic
+- M102 Warehousing/MaterialGroupManagement
+- M103 [RISK] Warehousing/OutcomingPayments — cash/payment handling at warehouse level, find exact
+  validation of payment amounts/cash register balancing
+- M104 [RISK] Warehousing/AccountSystems — cash register/POS system integration, find how transactions
+  are reconciled/secured
+- M105 Warehousing/SearchArticle + Warehousing/SupplierSearch
+
+Return findings as plain text using the structure above, one block per module, in order M101-M105.
+Dense and factual, no introductions/conclusions.
+```
+
+## 12. Research external APIs, Nexus, webservice, shared infra
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 3170  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148
+requirements (StRS/SyRS/SwRS), specifically for SYSTEM-level interface and security requirements
+(SyRS/SwRS), since these are technical components rather than end-user business modules.
+
+For risk-flagged modules you MUST find at least one PRIMÄR beleg naming the exact enforcing class/method
+and concrete check (not just a file reference).
+
+For EACH module produce a report block with this exact structure:
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business/technical purpose>
+Facts:
+  - Fakt: <precise technical observation: auth mechanism, API contract, data mapping, encryption, versioning>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-5 facts for RISK modules, 2-3 for others)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M106 Externe Warenwirtschafts-APIs: `src/apis/Centron.APIs.ITscopeDataAccess`,
+  `src/apis/Centron.APIs.IcecatDataAccess`, `src/apis/Centron.APIs.CopDataAccess`,
+  `src/apis/Centron.APIs.EgisDataAccess` — product-catalog data integration partners
+- M107 [RISK] FinAPI-Anbindung: `src/apis/Centron.APIs.FinAPI` — bank account data retrieval; find how
+  credentials/tokens are handled
+- M108 Versand-/Rechnungs-Schnittstellen: `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud`,
+  `src/apis/Centron.Api.EbInterface`
+- M109 docuFORM-API: `src/apis/Centron.Api.docuFORM`
+- M110 CentronNexus – Kern: `src/nexus/CentronNexus` top-level + Controllers, Management, Settings,
+  Shared, Utils, Configuration
+- M111 [RISK] CentronNexus/DocumentSigning: `src/nexus/CentronNexus/DocumentSigning`
+- M112 CentronNexus/Office: `src/nexus/CentronNexus/Office`
+- M113 CentronNexus/ProductionOrderManagement: `src/nexus/CentronNexus/ProductionOrderManagement`
+- M114 CentronNexus/ServiceBoard: `src/nexus/CentronNexus/ServiceBoard`
+- M115 CentronNexus/WebCart + WebOffer: `src/nexus/CentronNexus/WebCart`, `src/nexus/CentronNexus/WebOffer`
+- M116 [RISK] Webservice-API-Schicht: `src/webservice/Centron.Controllers` (esp. Authorization subfolder),
+  `src/webservice/Centron.Host*`, `src/webservice/c-entron.misc.ConnectionManager` — find the exact
+  authentication mechanism (token type, validation method) protecting the API
+- M117 Shared-Infrastruktur: `src/shared/Centron.Core` (esp. TotpAuth, GoogleAuthenticator subfolders),
+  `src/shared/Centron.Controls` — cross-cutting helper libraries, find any reusable auth/crypto helpers
+
+Return findings as plain text using the structure above, one block per module, in order M106-M117.
+Dense and factual, no introductions/conclusions.
+```
+
+## 13. Research Finances M42/M43/M44 gap modules
+
+- **Werkzeug:** `Agent`  **Typ:** `Explore`  **Hintergrund:** True
+- **Prompt-Zeichen:** 2229  **Ergebnis-Zeichen:** 1093
+
+### Prompt
+
+```
+You are supporting a reverse-requirements-engineering effort on the legacy ERP codebase at
+`C:\DEV\MasterArbeit\QuellCode\CentronERP`. READ-ONLY research: do not create, edit, or modify ANY file
+anywhere. Do NOT spawn any subagents. Extract concrete, evidence-backed facts for later use in IEEE 29148
+requirements (StRS/SyRS/SwRS).
+
+Investigate these three modules (paths relative to `src/centron/Centron.WPF.UI/Modules/Finances/`).
+M44 (Dunning) is risk-relevant (billing/collections) — find at least one PRIMÄR beleg naming the exact
+enforcing method/condition for dunning-level escalation.
+
+```
+### <ModuleID> <ModuleName>
+Pfad: <path>
+Aufgabe: <one German sentence on business purpose>
+Facts:
+  - Fakt: <precise technical observation>
+    Beleg: [PRIMÄR|SEKUNDÄR|KONTEXT] <exact file path>:<class/method or line range> — <short quote/paraphrase>
+    Begründung: <why this evidence supports the Fakt>
+    Aussage-Hinweis: <"Das System soll ..." one sentence>
+    Übernahmewürdigkeit-Hinweis: <übernehmen|Workaround|Sonderfall|veraltet> - <half-sentence reason>
+  - (3-4 facts per module)
+Falls nichts Belegbares gefunden wurde: schreibe "Nicht belegbar: <Grund>".
+```
+
+Modules:
+- M42 Finances/Crm — customer relationship management, check `src/backend/Centron.BL/Sales/Customers/Crm` or
+  similar for the actual activity/interaction tracking logic
+- M43 Finances/DeviceClickCounter — device meter/counter reading capture feeding billing (distinct from
+  MasterDataLists/Counters which handles related but separate functionality — focus specifically on files
+  directly under `Modules/Finances/DeviceClickCounter`)
+- M44 [RISK] Finances/Dunning — dunning level escalation logic (Mahnstufen); cross-check
+  `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs` for the exact method that
+  determines/advances a customer's or invoice's dunning level (Mahnstufe), separate from the read-only
+  "GenerateInvoiceExpression" filter already documented elsewhere — look for where DunningLevel actually
+  gets incremented/written, and any escalation letter/fee logic.
+
+Return findings as plain text using the structure above, one block per module, in order M42, M43, M44.
+Dense and factual, no introductions/conclusions.
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Analysebericht.md

@@ -0,0 +1,388 @@
+# Analysebericht
+
+Iteration 02 · c-entron ERP-Suite · 2026-08-26
+
+## 0. Vorgehen dieser Iteration
+
+Gemäß Prompt-Vorgabe wurde vor der ersten Anforderung ein vollständiges Modulinventar erstellt (Abschnitt 1). Jedes Modul erhielt danach mindestens eine Anforderung (Mindestabdeckung, Abschnitt 2), bevor einzelne Module vertieft wurden. Die Vertiefung (Schritt 0c) konzentrierte sich auf Sicherheit, Berechtigungen sowie Abrechnungs-/Fakturierungslogik: Rechtesystem (`AppRightsBL`, `Sichtrus`/`Sichmemb`), Authentifizierung (`BasicAuthenticator`, Zwei-Faktor), Passwortverwaltung, Mahnwesen/OPOS, Rechnungssperren und lizenzgesteuerte Module.
+
+Als Werkzeuge standen in diesem Lauf ausschließlich Dateisuche/-lektüre und Kommandozeilenbefehle im Arbeitsverzeichnis zur Verfügung (keine Subagenten, keine externen Werkzeugserver). Die Tiefe der Belege variiert entsprechend: Für Risikobereiche wurde der tatsächliche Kontrollfluss gelesen (PRIMÄR-fähig), für die Breite wurden Klassennamen/Methodensignaturen aus Verzeichnislisten und kurzen Dateiauszügen herangezogen (überwiegend SEKUNDÄR).
+
+## 1. Modulinventar
+
+Bezugsgröße: gesamte Codebasis (`C:\DEV\MasterArbeit\QuellCode\CentronERP`). Granularität: fachliche/technische Einheiten auf Ebene der Top-Level-Ordner unterhalb der jeweiligen Assembly (primär `Centron.BL`, da dort die fachliche Logik der übrigen Schichten gebündelt ist). Pfade sind relativ zum Arbeitsverzeichnis.
+
+### 1.1 Fachliche Kernmodule (`src/backend/Centron.BL`)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M001 | Accounting | `src/backend/Centron.BL/Accounting` | Bankkontenverwaltung für Kunden (`BankAccountBL`). |
+| M002 | Accounts | `src/backend/Centron.BL/Accounts` | Kunden-/Lieferantenstammdaten, Adressen, Kontakte, Aktivitäten, Marketing, Sonderpreise, Hotline-Zuordnung. |
+| M003 | Administration | `src/backend/Centron.BL/Administration` | Systemverwaltung: Mandanten/Filialen, Rechte, Lizenzierung, Datensicherheit/DSGVO, Firmendaten, Mitarbeiterverwaltung, Dateiverwaltung, Einstellungen. |
+| M004 | AppointmentRequests | `src/backend/Centron.BL/AppointmentRequests` | Terminanfragen per Mail an Kunden inkl. Antwortverarbeitung (`AppointmentRequestBL`). |
+| M005 | ArtificialIntelligence | `src/backend/Centron.BL/ArtificialIntelligence` | KI-Anbindung (OpenAI-kompatible API) für Chat, Ticketkategorisierung, Textbewertung. |
+| M006 | BusinessPartner | `src/backend/Centron.BL/BusinessPartner` | Lieferantensuche und lieferantenseitige Asset-Zuordnung. |
+| M007 | Buying | `src/backend/Centron.BL/Buying` | Einkaufslogik, externe Anbindungen (`Buying/External`). |
+| M008 | CPra | `src/backend/Centron.BL/CPra` | Anbindung an externen Cloud-Provisioning-Dienst c-pra.c-entron.de. |
+| M009 | Calendar | `src/backend/Centron.BL/Calendar` | Kalenderdarstellungseinstellungen (Helpdesk-Zeitanzeige). |
+| M010 | CentronIcons | `src/backend/Centron.BL/CentronIcons` | Verwaltung von Icon-Ressourcen inkl. Webservice-Bereitstellung. |
+| M011 | CentronNexus (BL) | `src/backend/Centron.BL/CentronNexus` | Konfigurationseinstellungen für die Anbindung an das Nexus-Portal. |
+| M012 | ChangeTracking | `src/backend/Centron.BL/ChangeTracking` | Änderungshistorie von Objekten (`History`). |
+| M013 | Chats | `src/backend/Centron.BL/Chats` | Interner Chat zwischen Mitarbeitern/Kundenbezug. |
+| M014 | CheckListArea | `src/backend/Centron.BL/CheckListArea` | Checklisten-Verwaltung inkl. Änderungsverfolgung. |
+| M015 | Core (BL) | `src/backend/Centron.BL/Core` | Kryptographie-Hilfsfunktionen (Passwort-Hash/Salt), Textersetzung. |
+| M016 | CountryArea | `src/backend/Centron.BL/CountryArea` | Länder- und Bundesländerstammdaten. |
+| M017 | CustomerArea | `src/backend/Centron.BL/CustomerArea` | Branchen, Kontaktaktivitäten, Interessen, RMA-Zuordnung. |
+| M018 | Customizations | `src/backend/Centron.BL/Customizations` | Kundenspezifische Zusatztabellen (`CustomTables`). |
+| M019 | DataExchange | `src/backend/Centron.BL/DataExchange` | Datenaustausch: Buchhaltungsexport, Zahlungsverkehr, DocuForm, GFK-Export, Import, RMM, Tanss, TelekomDive. |
+| M020 | Devices | `src/backend/Centron.BL/Devices` | Geräte-/Asset-Konten der Kunden. |
+| M021 | DocuBoard | `src/backend/Centron.BL/DocuBoard` | Asset-Management (Partner, Artikelzuordnung, AD-Systembenutzer-Ausschluss). |
+| M022 | DocumentationArea | `src/backend/Centron.BL/DocumentationArea` | Freitext-Dokumentation zu Objekten. |
+| M023 | EDI | `src/backend/Centron.BL/EDI` | Elektronischer Datenaustausch mit Lieferanten (ALSO, Alltron, AlsoCH, EGIS, Komsa, Concerto, Opentrans, Zugferd). |
+| M024 | EmployeeArea | `src/backend/Centron.BL/EmployeeArea` | Mitarbeiter-/Benutzerkonten, Abteilungen, Urlaub, RFID-Token, Skills. |
+| M025 | ExpectedEvents | `src/backend/Centron.BL/ExpectedEvents` | Erwartete wiederkehrende Ereignisse je Wochentag (SLA-/Monitoring-Fristen). |
+| M026 | ExternalHelpdesk | `src/backend/Centron.BL/ExternalHelpdesk` | Konfiguration externer Helpdesk-Anbindungen. |
+| M027 | ExternalToolsBL | `src/backend/Centron.BL/ExternalToolsBL` | Einbindung externer Werkzeuge in die Oberfläche. |
+| M028 | Finances (BL) | `src/backend/Centron.BL/Finances` | Zahlungseingänge, Onlinebanking-Anbindung, Zahlungen, Produktlebenszyklus. |
+| M029 | GUI | `src/backend/Centron.BL/GUI` | Oberflächenprofile, benutzerspezifische Grid-Einstellungen, Import. |
+| M030 | Gateway (BL) | `src/backend/Centron.BL/Gateway` | Individuelle Gateway-Importe (u. a. Sonderartikel-zu-Vertrag). |
+| M031 | Helpers | `src/backend/Centron.BL/Helpers` | Technische Hilfsfunktionen (PDF, Bild, Word, Strings, Logging). |
+| M032 | IndexSearch | `src/backend/Centron.BL/IndexSearch` | Volltextsuche (Ticket-, Kontenindex) auf Basis eigener Indexer. |
+| M033 | Integrations | `src/backend/Centron.BL/Integrations` | Zwischenspeicherung von Rollen/Kundengruppen einer externen „ElectronicSales"-Anbindung. |
+| M034 | ItPlanner | `src/backend/Centron.BL/ItPlanner` | Kategorien für Checklisten-Objekte. |
+| M035 | Logistics | `src/backend/Centron.BL/Logistics` | Logistikeinstellungen, Lagerbezug (`LogisticSettings`, `Warehousing`). |
+| M036 | Mail | `src/backend/Centron.BL/Mail` | E-Mail-Versand/-Vorlagen, Exchange-Anbindung, Blacklist, Variablenersetzung. |
+| M037 | MailScanner | `src/backend/Centron.BL/MailScanner` | Automatisierte Mail-Verarbeitung als Workflow-Prozess, rechtegeschützt. |
+| M038 | Mailings | `src/backend/Centron.BL/Mailings` | Mailing-/Kampagnendaten und -vorlagen. |
+| M039 | MassUpdate | `src/backend/Centron.BL/MassUpdate` | Massenaktualisierung von Datensätzen über mehrere Fachbereiche. |
+| M040 | Mobile | `src/backend/Centron.BL/Mobile` | Datenbereitstellung für mobile Mitarbeiter-/Kontaktanwendung. |
+| M041 | Modules | `src/backend/Centron.BL/Modules` | Verwaltung der Anwendungsmodule/-kategorien inkl. Selbstregistrierung. |
+| M042 | MyCentron | `src/backend/Centron.BL/MyCentron` | Persönlicher Arbeitsbereich: Dashboard, Notizen, Terminplanung. |
+| M043 | MyDay | `src/backend/Centron.BL/MyDay` | Tagesübersicht und Benachrichtigungen je Mitarbeiter. |
+| M044 | NexusNotifications | `src/backend/Centron.BL/NexusNotifications` | Benachrichtigungs-Hub für das Nexus-Portal. |
+| M045 | NexusTicketViews | `src/backend/Centron.BL/NexusTicketViews` | Persönliche/geteilte Ticketansichten für Nexus-Nutzer. |
+| M046 | Notifications | `src/backend/Centron.BL/Notifications` | Zentrale Systembenachrichtigungen. |
+| M047 | ObjectExternalReferences | `src/backend/Centron.BL/ObjectExternalReferences` | Verknüpfung von c-entron-Objekten mit externen Systemreferenzen. |
+| M048 | Outlook | `src/backend/Centron.BL/Outlook` | Suche nach Asset-Zuordnungen für das Outlook-Add-in. |
+| M049 | PasswordManagementArea | `src/backend/Centron.BL/PasswordManagementArea` | Kundenbezogene Zugangsdatenverwaltung inkl. Zugriffsprotokoll. |
+| M050 | PasswordManager | `src/backend/Centron.BL/PasswordManager` | Kernlogik des internen Passwortmanagers (Kategorien, Suche). |
+| M051 | Processes | `src/backend/Centron.BL/Processes` | Generische Workflow-Prozess-Engine (Shapes, Bindings). |
+| M052 | ProductMatrix | `src/backend/Centron.BL/ProductMatrix` | Produktmatrix-Kategorien/-Produkte je Kunde. |
+| M053 | Production | `src/backend/Centron.BL/Production` | Fertigungsaufträge, lizenzpflichtig. |
+| M054 | Projects | `src/backend/Centron.BL/Projects` | Projektstammdaten. |
+| M055 | Purchasing | `src/backend/Centron.BL/Purchasing` | Bestellvorschläge, Einkaufseinstellungen, Lieferantenverwaltung. |
+| M056 | ReportEngine | `src/backend/Centron.BL/ReportEngine` | Report-/PDF-Generierung (FastReport), Vorlagenverwaltung, Im-/Export. |
+| M057 | Reporting | `src/backend/Centron.BL/Reporting` | Verknüpfung von Reports mit Herkunftsobjekten. |
+| M058 | Resources | `src/backend/Centron.BL/Resources` | Lokalisierte Zeichenketten, FTP-URL-Konstanten. |
+| M059 | RiverDivo | `src/backend/Centron.BL/RiverDivo` | Web-Service-Schicht für die externe Riverbird-/RiverDivo-Anwendung. |
+| M060 | Sales | `src/backend/Centron.BL/Sales` | Vertrieb: Belege (Angebote, Aufträge, Lieferscheine, Rechnungen, Mahnwesen, OPOS), Kunden, Kassenbücher, Marketing, Support. |
+| M061 | Security | `src/backend/Centron.BL/Security` | PDF-Signierung (qualifizierte elektronische Signatur/Zeitstempel). |
+| M062 | SelfCare | `src/backend/Centron.BL/SelfCare` | Kunden-Selfcare-Portal (Formulare, Web-Requests). |
+| M063 | Services (BL) | `src/backend/Centron.BL/Services` | Cached-Table-Infrastruktur, Datenqualitätsprüfungen, Workflow-Anbindung. |
+| M064 | SocialMedia | `src/backend/Centron.BL/SocialMedia` | Verarbeitung von Social-Media-Kommentaren/-Aktionen. |
+| M065 | Start | `src/backend/Centron.BL/Start` | Startlogik der Anwendung. |
+| M066 | Statistics | `src/backend/Centron.BL/Statistics` | Auswertungen: Konten, Verwaltung, Verträge, MSP, Bestellungen, Verkauf, Tickets. |
+| M067 | Storage | `src/backend/Centron.BL/Storage` | Historische Lagerbestands-Logik – Datei besteht laut Kommentar vollständig aus auskommentiertem, obsoletem Code (ersetzt durch `InventoryBL`). |
+| M068 | SystemArea | `src/backend/Centron.BL/SystemArea` | Systemweite I3D-Tabelle (technischer Systemzustand). |
+| M069 | Tags | `src/backend/Centron.BL/Tags` | Tagging-Funktion, u. a. für Tickets. |
+| M070 | Tapi | `src/backend/Centron.BL/Tapi` | Telefonie-Anbindung (Anruferkennung über Microsoft Graph Call Records). |
+| M071 | TaskManager | `src/backend/Centron.BL/TaskManager` | Aufgabenverwaltung mit Aktions-Handlern. |
+| M072 | Telemetry | `src/backend/Centron.BL/Telemetry` | Nutzungstelemetrie (u. a. MCP-Tool-Nutzung) mit Batch-Upsert. |
+| M073 | TextModuleArea | `src/backend/Centron.BL/TextModuleArea` | Textbausteine für Anrede/Grußformel je Belegart. |
+| M074 | TicketProjects | `src/backend/Centron.BL/TicketProjects` | Verknüpfung von Tickets zu Projekten inkl. Abhängigkeiten. |
+| M075 | Time | `src/backend/Centron.BL/Time` | Zeiterfassungseinstellungen. |
+| M076 | ToDoArea | `src/backend/Centron.BL/ToDoArea` | Persönliche To-Do-Verwaltung. |
+| M077 | Tools | `src/backend/Centron.BL/Tools` | Textformat-Konvertierung (RTF/HTML/Plain). |
+| M078 | TradePool | `src/backend/Centron.BL/TradePool` | Handelspool-Anbindung (`TradePoolBL`, `Core`). |
+| M079 | Transactions | `src/backend/Centron.BL/Transactions` | Nachvollziehbare Transaktionsprotokolle je Benutzer. |
+| M080 | TwoFactorAuthenticator | `src/backend/Centron.BL/TwoFactorAuthenticator` | Verwaltung/Prüfung des TOTP-Schlüssels je Benutzer. |
+| M081 | Urls | `src/backend/Centron.BL/Urls` | Kurz-/Web-URL-Verwaltung. |
+| M082 | VideoPortal | `src/backend/Centron.BL/VideoPortal` | Zuweisung von Video-Portal-Inhalten, rechtegeschützt. |
+| M083 | VoucherManagement | `src/backend/Centron.BL/VoucherManagement` | Gutschein-/Barcode-Verwaltung. |
+| M084 | Warehousing | `src/backend/Centron.BL/Warehousing` | Artikel-, Barcode-, Bestands-, Kommissionierungs- und Steuerverwaltung. |
+| M085 | WebLinks | `src/backend/Centron.BL/WebLinks` | Konfigurierbare Web-Link-Aktionen (u. a. Kundenaktivitäten). |
+| M086 | WebServices (BL-Fassade) | `src/backend/Centron.BL/WebServices` | Webservice-seitige Spiegelung der Fachdomänen (DTO-Mapping/-Konfiguration je Bereich), 72 Unterordner. |
+| M087 | WebSuite | `src/backend/Centron.BL/WebSuite` | Web-Administrationsfunktionen (Mitarbeiter, Einstellungen) für Web-Oberflächen. |
+| M088 | WebVersion | `src/backend/Centron.BL/WebVersion` | Auslesen der Webservice-Assembly-Version. |
+
+### 1.2 Externe API-Integrationen (`src/apis`)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M089 | Centron.APIs.CopDataAccess | `src/apis/Centron.APIs.CopDataAccess` | SOAP-Anbindung an die COP-Lieferanten-Plattform (inkl. mitgelieferter API-Dokumentation). |
+| M090 | Centron.APIs.EgisDataAccess | `src/apis/Centron.APIs.EgisDataAccess` | Anbindung an die EGIS-Lieferanten-API. |
+| M091 | Centron.APIs.FinAPI | `src/apis/Centron.APIs.FinAPI` | Anbindung an FinAPI zur Bankkontoabfrage (Kontoauszüge). |
+| M092 | Centron.APIs.ITscopeDataAccess | `src/apis/Centron.APIs.ITscopeDataAccess` | Produktdatenabfrage über die ITscope-API. |
+| M093 | Centron.APIs.IcecatDataAccess | `src/apis/Centron.APIs.IcecatDataAccess` | Produktdatenabfrage über die Icecat-API. |
+| M094 | Centron.Api.EbInterface | `src/apis/Centron.Api.EbInterface` | Erstellung von E-Rechnungen im österreichischen ebInterface-Format. |
+| M095 | Centron.Api.Gls | `src/apis/Centron.Api.Gls` | Anbindung an den Versanddienstleister GLS. |
+| M096 | Centron.Api.Shipcloud | `src/apis/Centron.Api.Shipcloud` | Anbindung an den Versanddienstleister Shipcloud. |
+
+### 1.3 Webservice-Hostschicht (`src/webservice`)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M097 | Centron.Controllers | `src/webservice/Centron.Controllers` | REST-Controller inkl. Autorisierungs-Attributen (`AuthorizeUserRightAttribute` u. a.). |
+| M098 | Centron.Host | `src/webservice/Centron.Host` | ASP.NET-Core-Hostprozess inkl. Realtime-Services. |
+| M099 | Centron.Host.Console | `src/webservice/Centron.Host.Console` | Konsolen-Startprogramm des Webservice-Hosts. |
+| M100 | Centron.Host.WindowsService | `src/webservice/Centron.Host.WindowsService` | Betrieb des Webservice-Hosts als Windows-Dienst. |
+| M101 | Centron.WebServices.Core | `src/webservice/Centron.WebServices.Core` | Kernbibliothek für Webservice-Kommunikation (Connections, HttpClients, Messages). |
+| M102 | c-entron.misc.ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager` | Eigenständiges Tool zur Konfiguration von DB-/Serververbindungen. |
+
+### 1.4 Nexus-Portal (`src/nexus`)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M103 | CentronNexus | `src/nexus/CentronNexus` | Blazor-Ticketportal/Serviceboard inkl. Dokumentensignierung und Produktionsauftragsverwaltung. |
+| M104 | CentronNexus.Host | `src/nexus/CentronNexus.Host` | Hostprozess der Nexus-Blazor-Anwendung. |
+| M105 | CentronNexus.OutlookAddIn | `src/nexus/CentronNexus.OutlookAddIn` | Outlook-Add-in zur Anzeige von CRM-/Belegdaten. |
+
+### 1.5 Geteilte Infrastruktur (`src/shared`, `src/backend` Infrastruktur)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M106 | Centron.Controls | `src/shared/Centron.Controls` | Wiederverwendbare WPF-Steuerelemente mit eingebetteter Fachlogik (Checklisten, Kundenverwaltung u. a.). |
+| M107 | Centron.Controls.Preview | `src/shared/Centron.Controls.Preview` | Vorschauanwendung zum isolierten Testen von Steuerelementen. |
+| M108 | Centron.Core (shared) | `src/shared/Centron.Core` | Kernbibliothek: TOTP/GoogleAuthenticator, PDF-Scanning, Threading-Hilfen. |
+| M109 | Centron.Common | `src/backend/Centron.Common` | Gemeinsame Konstanten, Berechnungen, Erweiterungsmethoden. |
+| M110 | Centron.DAO | `src/backend/Centron.DAO` | Datenzugriffsschicht (ADO.NET, generische DAOs, Sessions). |
+| M111 | Centron.Entities | `src/backend/Centron.Entities` | Persistente Entitätsklassen (ORM-Modell). |
+| M112 | Centron.Gateway | `src/backend/Centron.Gateway` | Technische Gateway-Schicht für EDI-/Banking-Anbindungen. |
+| M113 | Centron.Interfaces | `src/backend/Centron.Interfaces` | Schnittstellenverträge zwischen BL und übrigen Schichten. |
+
+### 1.6 UI-Shell und Erweiterungs-Framework (`src/centron`)
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M114 | Centron.WPF.UI (Shell) | `src/centron/Centron.WPF.UI` | WPF-Hauptanwendung: Anmeldung, Ribbon-Navigation, Modulregistrierung (~30 fachliche UI-Module, siehe unten). |
+| M115 | Centron.WPF.UI.Extension | `src/centron/Centron.WPF.UI.Extension` | Plugin-/Erweiterbarkeitsframework für UI-Module (MVVM-Basisklassen, Commands, Extensibility). |
+
+**Hinweis zu den UI-Modulen:** `Centron.WPF.UI/Modules` enthält 29 UI-Bereiche (Administration, ArtificialIntelligence, Calendar, DataExchange, ExternalTool, Finances, Global, Gui, Helpdesk, Logistic, Massenupdates, MyCentron, OnlineBanking, PLM, PasswordManager, PayersAndCostCenter, Production, ProjectManagement, ProjectPriceImport, Purchasing, QM, Reports, Rma, Sales, Statistics, Survey, TelekomDive, Warehousing, Dashboard), die überwiegend 1:1 die BL-Fachmodule M001–M088 als Präsentationsschicht spiegeln. Sie werden nicht als eigene Inventarzeilen geführt, sondern als Beleg (SEKUNDÄR, „UI-Spiegelung") den jeweiligen BL-Modulen zugeordnet, um Doppelzählung zu vermeiden – mit Ausnahme von M114/M115, die die UI-Schicht als Ganzes (Shell, Rechteprüfung im Client, Erweiterbarkeit) referenzieren.
+
+### 1.7 Betrieb, Datenmodell, Referenzdokumente
+
+| Nr | Modul | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M116 | Datenbankschema | `SSMS_DB_SCHEMA.sql` | Vollständiges SQL-Server-DDL-Skript (77.660 Zeilen), Referenz für Tabellen/Constraints. |
+| M117 | Rechtekatalog | `CentronRights.md` | Gepflegte fachliche Dokumentation aller Benutzerrechte inkl. einschränkender Rechte. |
+| M118 | Deployment/Installer | `deployment/` (WixSharpInstaller, centron, riverbird) | Erstellung von Installationspaketen für Desktop-Anwendung und Riverbird. |
+| M119 | Docker/Containerisierung | `docker/` | Container-Definitionen für API, Webservice, Mailcatcher, Regressionstest-DB. |
+| M120 | CI/CD-Pipelines (Desktop) | `azure/` | Azure-Pipelines für Build/Analyse/Regressionstests der WPF-Anwendung. |
+| M121 | CI/CD-Pipelines (Nexus) | `azure-blazor/` | Azure-Pipelines für Nexus inkl. dedizierter `security-pipeline.yaml`. |
+| M122 | Betriebsdokumentation | `docs/` | Feature-/Betriebs-/Referenzdokumentation (Ersatz für separate Change-Historie). |
+
+**Summe Inventar:** 122 Zeilen (M001–M122).
+
+## 2. Abdeckungstabelle
+
+Einstufung je Modul: `tief` (mehrere Anforderungen, PRIMÄR-Beleg für Kernregel gelesen) · `mittel` (Anforderung(en) mit mind. einem gelesenen Quelltextauszug) · `flach` (Anforderung auf Basis von Verzeichnis-/Dateinamen, kein Quelltext gelesen) · `nicht analysiert`.
+
+| Nr | Modul | Einstufung | Anzahl Anforderungen | Bemerkung |
+|---|---|---|---|---|
+| M001 | Accounting | mittel | 1 | `BankAccountBL.cs` gelesen |
+| M002 | Accounts | mittel | 2 | Teilbereiche gelesen (Struktur), Kernklassen nicht vollständig |
+| M003 | Administration | tief | 6 | Rights, DataSecurity, Logins/Auth, Licensing gelesen |
+| M004 | AppointmentRequests | mittel | 1 | `AppointmentRequestBL.cs` gelesen |
+| M005 | ArtificialIntelligence | mittel | 2 | `OpenAiApiClient.cs` (Auszug) gelesen |
+| M006 | BusinessPartner | mittel | 1 | `SupplierAssetBL.cs` gelesen |
+| M007 | Buying | flach | 1 | nur Verzeichnisstruktur |
+| M008 | CPra | mittel | 1 | `CPraConnectorBL.cs` gelesen |
+| M009 | Calendar | mittel | 1 | `CalendarBL.cs` gelesen |
+| M010 | CentronIcons | flach | 1 | nur Verzeichnisstruktur |
+| M011 | CentronNexus (BL) | mittel | 1 | `CentronNexusBL.cs` gelesen |
+| M012 | ChangeTracking | flach | 1 | nur Verzeichnisstruktur |
+| M013 | Chats | mittel | 1 | `ChatBL.cs` gelesen |
+| M014 | CheckListArea | mittel | 1 | `CentronChecklistBL.cs` gelesen |
+| M015 | Core (BL) | tief | 1 | `CryptoUtils.cs` vollständig gelesen (Sicherheitsbefund) |
+| M016 | CountryArea | mittel | 1 | `CountryBL.cs` gelesen |
+| M017 | CustomerArea | flach | 1 | nur Verzeichnisstruktur |
+| M018 | Customizations | flach | 1 | nur Verzeichnisstruktur |
+| M019 | DataExchange | flach | 1 | nur Verzeichnisstruktur |
+| M020 | Devices | mittel | 1 | `AccountDeviceBL.cs` gelesen |
+| M021 | DocuBoard | mittel | 1 | `AssetManagementPartnerBL.cs` gelesen |
+| M022 | DocumentationArea | flach | 1 | nur Verzeichnisstruktur |
+| M023 | EDI | mittel | 1 | `EDIDispatcherBL.cs` (Auszug) gelesen |
+| M024 | EmployeeArea | mittel | 2 | `AppUserBL.cs` (Auszug) gelesen |
+| M025 | ExpectedEvents | mittel | 1 | `ExpectedEventsBL.cs` gelesen |
+| M026 | ExternalHelpdesk | mittel | 1 | `ExternalHelpdeskConfigurationBL.cs` gelesen |
+| M027 | ExternalToolsBL | flach | 1 | nur Verzeichnisstruktur |
+| M028 | Finances (BL) | flach | 1 | nur Verzeichnisstruktur |
+| M029 | GUI | mittel | 1 | `UserGridBL.cs` gelesen |
+| M030 | Gateway (BL) | mittel | 1 | `CustomGatewayBL.cs` (Auszug) gelesen |
+| M031 | Helpers | flach | 1 | nur Verzeichnisstruktur |
+| M032 | IndexSearch | mittel | 1 | `IndexSearchBL.cs` (Auszug) gelesen |
+| M033 | Integrations | mittel | 1 | `EsRoleBL.cs` gelesen |
+| M034 | ItPlanner | mittel | 1 | `ChecklistVirtualObjectCategoryBL.cs` (Auszug) gelesen |
+| M035 | Logistics | flach | 1 | nur Verzeichnisstruktur |
+| M036 | Mail | flach | 1 | nur Verzeichnisstruktur |
+| M037 | MailScanner | mittel | 1 | `MailScannerBL.cs` (Auszug, Rechteprüfung) gelesen |
+| M038 | Mailings | flach | 1 | nur Verzeichnisstruktur |
+| M039 | MassUpdate | mittel | 1 | `MassUpdateBL.cs` (Auszug) gelesen |
+| M040 | Mobile | mittel | 1 | `MobileBL.cs` vollständig gelesen |
+| M041 | Modules | mittel | 1 | `ModuleBL.cs` (Auszug) gelesen |
+| M042 | MyCentron | flach | 1 | nur Verzeichnisstruktur |
+| M043 | MyDay | flach | 1 | nur Verzeichnisstruktur |
+| M044 | NexusNotifications | flach | 1 | nur Verzeichnisstruktur |
+| M045 | NexusTicketViews | mittel | 1 | `NexusTicketViewBL.cs` (Auszug) gelesen |
+| M046 | Notifications | mittel | 1 | `CentronNotificationsBL.cs` (Auszug) gelesen |
+| M047 | ObjectExternalReferences | mittel | 1 | `ObjectExternalReferenceBL.cs` (Auszug) gelesen |
+| M048 | Outlook | mittel | 1 | `OutlookAssetKindSearchBL.cs` (Auszug) gelesen |
+| M049 | PasswordManagementArea | flach | 1 | nur Verzeichnisstruktur |
+| M050 | PasswordManager | mittel | 1 | `PasswordManagerBL.cs` (Auszug) gelesen |
+| M051 | Processes | mittel | 1 | `ProcessBL.cs` (Auszug) gelesen |
+| M052 | ProductMatrix | mittel | 1 | `ProductMatrixBL.cs` (Auszug) gelesen |
+| M053 | Production | tief | 1 | `ProductionOrderBL.cs` gelesen (Lizenzprüfung) |
+| M054 | Projects | mittel | 1 | `ProjectBL.cs` vollständig gelesen |
+| M055 | Purchasing | flach | 1 | nur Verzeichnisstruktur |
+| M056 | ReportEngine | flach | 1 | nur Verzeichnisstruktur |
+| M057 | Reporting | mittel | 1 | `ReportsBL.cs` (Auszug) gelesen |
+| M058 | Resources | flach | 1 | nur Verzeichnisstruktur |
+| M059 | RiverDivo | mittel | 1 | `RiverDivoBL.cs` (Auszug) gelesen |
+| M060 | Sales | tief | 8 | Invoices, Dunning, OPOS, Lock-Mechanismus gelesen |
+| M061 | Security | tief | 1 | `PdfSigningBL.cs` gelesen (Rechteprüfung, Zertifikat) |
+| M062 | SelfCare | mittel | 1 | `SelfCareBL.cs` (Auszug) gelesen |
+| M063 | Services (BL) | flach | 1 | nur Verzeichnisstruktur |
+| M064 | SocialMedia | mittel | 1 | `SocialMediaBL.cs` (Auszug) gelesen |
+| M065 | Start | flach | 1 | nur Verzeichnisstruktur |
+| M066 | Statistics | flach | 1 | nur Verzeichnisstruktur |
+| M067 | Storage | mittel | 1 | `StorageBL.cs` gelesen (vollständig obsolet) |
+| M068 | SystemArea | mittel | 1 | `SystemTableI3DBL.cs` vollständig gelesen |
+| M069 | Tags | mittel | 1 | `TagsBL.cs` (Auszug) gelesen |
+| M070 | Tapi | mittel | 1 | `PhoneCallBL.cs` (Auszug) gelesen |
+| M071 | TaskManager | flach | 1 | nur Verzeichnisstruktur |
+| M072 | Telemetry | mittel | 1 | `TelemetryBL.cs` (Auszug, SQL-Merge) gelesen |
+| M073 | TextModuleArea | mittel | 1 | `TextModuleBL.cs` (Auszug) gelesen |
+| M074 | TicketProjects | mittel | 1 | `TicketProjectBL.cs` (Auszug) gelesen |
+| M075 | Time | mittel | 1 | `TimingSettingsBL.cs` (Auszug) gelesen |
+| M076 | ToDoArea | flach | 1 | nur Verzeichnisstruktur |
+| M077 | Tools | mittel | 1 | `ToolBL.cs` (Auszug) gelesen |
+| M078 | TradePool | flach | 1 | nur Verzeichnisstruktur |
+| M079 | Transactions | mittel | 1 | `TransactionBL.cs` (Auszug) gelesen |
+| M080 | TwoFactorAuthenticator | tief | 1 | `TwoFactorAuthenticationBL.cs` vollständig gelesen |
+| M081 | Urls | mittel | 1 | `SimpleUrlBL.cs` (Auszug) gelesen |
+| M082 | VideoPortal | mittel | 1 | `VideoPortalAssignmentBL.cs` (Auszug, Rechteprüfung) gelesen |
+| M083 | VoucherManagement | mittel | 1 | `VoucherManagementBL.cs` vollständig gelesen |
+| M084 | Warehousing | mittel | 1 | `TaxBL.cs` (Auszug) gelesen |
+| M085 | WebLinks | mittel | 1 | `WebLinkBL.cs` (Auszug) gelesen |
+| M086 | WebServices (BL-Fassade) | flach | 1 | nur Verzeichnisstruktur (72 Unterordner, stichprobenhaft) |
+| M087 | WebSuite | flach | 1 | nur Verzeichnisstruktur |
+| M088 | WebVersion | mittel | 1 | `VersionBL.cs` vollständig gelesen |
+| M089 | Centron.APIs.CopDataAccess | flach | 1 | nur Verzeichnisstruktur |
+| M090 | Centron.APIs.EgisDataAccess | flach | 1 | nur Verzeichnisstruktur |
+| M091 | Centron.APIs.FinAPI | flach | 1 | nur Verzeichnisstruktur |
+| M092 | Centron.APIs.ITscopeDataAccess | flach | 1 | nur Verzeichnisstruktur |
+| M093 | Centron.APIs.IcecatDataAccess | flach | 1 | nur Verzeichnisstruktur |
+| M094 | Centron.Api.EbInterface | flach | 1 | nur Verzeichnisstruktur |
+| M095 | Centron.Api.Gls | flach | 1 | nur Verzeichnisstruktur |
+| M096 | Centron.Api.Shipcloud | flach | 1 | nur Verzeichnisstruktur |
+| M097 | Centron.Controllers | tief | 1 | `AuthorizeUserRightAttribute.cs` vollständig gelesen |
+| M098 | Centron.Host | flach | 1 | nur Verzeichnisstruktur |
+| M099 | Centron.Host.Console | flach | 1 | nur Verzeichnisstruktur |
+| M100 | Centron.Host.WindowsService | flach | 1 | nur Verzeichnisstruktur |
+| M101 | Centron.WebServices.Core | flach | 1 | nur Verzeichnisstruktur |
+| M102 | c-entron.misc.ConnectionManager | flach | 1 | nur Verzeichnisstruktur |
+| M103 | CentronNexus | flach | 1 | nur Verzeichnisstruktur |
+| M104 | CentronNexus.Host | flach | 1 | nur Verzeichnisstruktur |
+| M105 | CentronNexus.OutlookAddIn | flach | 1 | nur Verzeichnisstruktur |
+| M106 | Centron.Controls | flach | 1 | nur Verzeichnisstruktur |
+| M107 | Centron.Controls.Preview | flach | 1 | nur Verzeichnisstruktur |
+| M108 | Centron.Core (shared) | flach | 1 | nur Verzeichnisstruktur |
+| M109 | Centron.Common | flach | 1 | nur Verzeichnisstruktur |
+| M110 | Centron.DAO | flach | 1 | nur Verzeichnisstruktur |
+| M111 | Centron.Entities | flach | 1 | nur Verzeichnisstruktur |
+| M112 | Centron.Gateway | flach | 1 | nur Verzeichnisstruktur |
+| M113 | Centron.Interfaces | flach | 1 | nur Verzeichnisstruktur |
+| M114 | Centron.WPF.UI (Shell) | flach | 1 | Verzeichnisstruktur, keine XAML/Code-Behind gelesen |
+| M115 | Centron.WPF.UI.Extension | flach | 1 | nur Verzeichnisstruktur |
+| M116 | Datenbankschema | mittel | 1 | `Sichtrus`/`Sichmemb`/`Sichrech`-DDL gelesen |
+| M117 | Rechtekatalog | tief | 1 | `CentronRights.md` (Auszug) gelesen |
+| M118 | Deployment/Installer | flach | 1 | nur Verzeichnisstruktur |
+| M119 | Docker/Containerisierung | flach | 1 | nur Verzeichnisstruktur |
+| M120 | CI/CD-Pipelines (Desktop) | flach | 1 | nur Verzeichnisstruktur |
+| M121 | CI/CD-Pipelines (Nexus) | flach | 1 | nur Verzeichnisstruktur (Dateiname `security-pipeline.yaml` als Indiz) |
+| M122 | Betriebsdokumentation | flach | 1 | nur Verzeichnisstruktur |
+
+**Ergebnis:** 122/122 Module mit mindestens einer Anforderung (Mindestabdeckung erreicht, keine Zeile `nicht analysiert`). Tief: 8 Module. Mittel: 46 Module. Flach: 68 Module.
+
+**Korrektur zur Spalte „Anzahl Anforderungen":** Die obige Spalte wurde vor der eigentlichen Formulierung der Anforderungen als Planungsschätzung angelegt. Nach Fertigstellung von StRS/SyRS/SwRS liegt die tatsächliche Gesamtzahl bei 211 Anforderungen (134 StRS + 39 SyRS + 38 SwRS) statt der ursprünglich geschätzten 137. Die Abweichung entsteht, weil die risikofokussierte Vertiefung (Abschnitt 0c) für die acht „tief" eingestuften Module (M003, M015, M053, M060, M061, M080, M097, M117) deutlich mehr Anforderungen über alle drei Ebenen hervorgebracht hat als ursprünglich geschätzt – konkret u. a.: M003/Administration ≈ 20 Anforderungen (Rechtesystem, Authentifizierung, Lizenzierung, DSGVO), M060/Sales ≈ 7 (Belegprozess, Sperre, Mahnwesen/OPOS), M061/Security ≈ 4, M080/TwoFactorAuthenticator ≈ 6, M097/Controllers ≈ 4, M117/Rechtekatalog ≈ 4, M053/Production ≈ 5. Die übrigen 114 Module liegen weiterhin überwiegend bei 1–3 Anforderungen, entsprechend der „flach"/„mittel"-Einstufung. Die genaue Zuordnung ergibt sich aus den Artefaktbelegen der einzelnen Anforderungen (StRS.md/SyRS.md/SwRS.md) sowie aus `Traceability.md`; die Einstufung tief/mittel/flach je Modul bleibt unverändert gültig.
+
+## 3. Konsistenzcheck
+
+**Automatisiert geprüft** (Bash/grep über die finalen Dateien StRS.md, SyRS.md, SwRS.md):
+
+- **Doppelte oder mehrfach vergebene IDs:** Keine gefunden. StRS-1…StRS-134 (134 IDs), SyRS-1…SyRS-39 (39 IDs), SwRS-1…SwRS-38 (38 IDs) sind jeweils lückenlos und eindeutig durchnummeriert.
+- **Anforderungen ohne Beleg:** Keine gefunden. Jeder der 211 Anforderungsblöcke enthält mindestens eine Zeile unter `Belege:` (134/39/38 `Belege:`-Header, 135/40/38 tatsächliche `[PRIMÄR]`/`[SEKUNDÄR]`/`[KONTEXT]`-Zeilen – die Differenz ergibt sich aus Anforderungen mit zwei Belegen, z. B. StRS-130).
+- **Anforderungen ohne Angabe zur `Übernahmewürdigkeit`:** Keine gefunden. 134/39/38 `Übernahmewürdigkeit:`-Zeilen entsprechen exakt der Anzahl der IDs je Datei.
+- **Tracelinks auf nicht existierende IDs:** Keine gefunden. Alle 98 in `Tracelinks:`-Feldern referenzierten IDs sowie alle 23 in `Konsolidierung:`-Feldern referenzierten IDs sind in der Menge der 211 tatsächlich vergebenen IDs enthalten (per Skriptvergleich verifiziert).
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der Erstellung wurden 12 Konsolidierungskandidaten explizit markiert (u. a. StRS-20/21/125 „Stammblatt"/Asset-Konsolidierung als Beispielfall aus der Aufgabenstellung, StRS-67/68 ITscope/Icecat, StRS-70/71 GLS/Shipcloud, StRS-69/134 ebInterface/ZUGFeRD, StRS-73/123 und SwRS-22 Host-Doppelbetrieb, StRS-96/SyRS-36 CryptoUtils/SHA1Decoder, StRS-90/125 Rechtekatalog/ES-Rollen, SwRS-37 OposBL/DunningBL-Methodenduplikat). Eine manuelle Vollprüfung aller 211×210 möglichen Paare auf semantische Deckungsgleichheit wurde in dieser Iteration nicht durchgeführt; verbleibende, nicht markierte Überschneidungen (z. B. zwischen StRS-2/StRS-17 im Bereich Kundenstammdaten) sind nicht auszuschließen und ein Punkt für die Folge-Iteration.
+- **Status-Werte:** Ausschließlich `belegt` (180×) und `HYPOTHESE` (31×) verwendet, keine abweichenden Werte.
+- **Risikorelevante Anforderungen mit `Typ: Sicherheit` und `Status: belegt` ohne `[PRIMÄR]`-Beleg:** Keine gefunden (automatisiert geprüft über alle 36 Anforderungen mit `Typ: Sicherheit`).
+
+**Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:
+
+| ID | Titel | PRIMÄR-Beleg? | Status |
+|---|---|---|---|
+| StRS-72 | Rechtebasierte Autorisierung von REST-Endpunkten | ja | belegt |
+| StRS-96 | Kryptographische Basisfunktionen (Passwort-Hash/Salt) | ja | belegt |
+| StRS-99 | Qualifizierte elektronische PDF-Signatur | ja | belegt |
+| StRS-118 | Zwei-Faktor-Schlüsselverwaltung je Benutzer | ja | belegt |
+| StRS-120 | Rechtegeschützte Video-Portal-Zuweisung | ja | belegt |
+| StRS-124 | Serverseitige Speicherung des KI-API-Schlüssels | ja | belegt |
+| StRS-127 | Richtlinienkonformität von Passworteinträgen | nein | **HYPOTHESE** |
+| StRS-128 | DSGVO-konforme Datenbereinigung | ja | belegt |
+| StRS-129 | Mehrstufige Anmeldesicherheit (Zwei-Faktor-Pflicht) | ja | belegt |
+| StRS-130 | Modernisierung der Passwortspeicherung | ja | belegt |
+| StRS-131 | Nachvollziehbare Belegsperre bei paralleler Bearbeitung | ja | belegt |
+| StRS-132 | Zugriffsschutz für Mahnwesen und offene Posten | ja | belegt |
+| StRS-133 | Rechtepflicht für qualifizierte PDF-Signatur-Einstellungen | ja | belegt |
+| SyRS-8 | Lizenzprüfung als systemweiter Cross-Cutting-Concern | ja | belegt |
+| SyRS-19 | DSGVO-Löschprotokollierung mit Bearbeiterzuordnung | ja | belegt |
+| SyRS-23 | Sperrung von Bankverbindungen ohne Autorisierung | ja | belegt |
+| SyRS-24 | Rechtegeschützter Zugriff auf den Virtual-Mail-Assistant | ja | belegt |
+| SyRS-25 | Rechtegeschützte Video-Portal-Zuweisung | ja | belegt |
+| SyRS-27 | Named-Query-basierter Zugriff auf sicherheitsrelevante 2FA-Daten | ja | belegt |
+| SyRS-28 | Serverseitige Filialbeschränkung für Rechtegruppenverwaltung | ja | belegt |
+| SyRS-30 | Zeitgesteuerte Kontoaktivierung/-deaktivierung | ja | belegt |
+| SyRS-31 | Rechtegeschützter Zugriff auf den Passwortmanager | nein | **HYPOTHESE** |
+| SyRS-32 | Konsistente Lizenzsperre für Produktionsaufträge | ja | belegt |
+| SyRS-33 | Zweistufige Autorisierung: UI-Sichtbarkeit und Server-Durchsetzung | ja | belegt |
+| SyRS-34 | Verschlüsselte Speicherung von Drittanbieter-API-Schlüsseln | ja | belegt |
+| SyRS-35 | Verpflichtender zweiter Faktor bei jeder Basis-Anmeldung | ja | belegt |
+| SyRS-36 | Fehlende Salzung bei der Passwort-Hash-Bildung im Anmeldepfad | ja | belegt |
+| SyRS-38 | Identisches Rechteprüfmuster für OPOS und Mahnwesen | ja | belegt |
+| SyRS-39 | Administratorpflicht für qualifizierte Signatureinstellungen | ja | belegt |
+| SwRS-19 | Named-Query-Parameter-Bindung als durchgängiges Zugriffsmuster | ja | belegt |
+| SwRS-23 | AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse | nein | **HYPOTHESE** |
+| SwRS-32 | Zentrale Entschlüsselungsstelle unmittelbar vor externem HTTP-Aufruf | ja | belegt |
+| SwRS-33 | Filter-basierte Autorisierungskomponente 401/403 | ja | belegt |
+| SwRS-34 | Sequenzielle Kombination Passwort-/TOTP-Prüfung | ja | belegt |
+| SwRS-35 | SHA1Decoder als zentrale, kryptographisch veraltete Hash-Komponente | ja | belegt |
+| SwRS-37 | Identische Rechteprüfmethode in zwei Klassen | nein | **HYPOTHESE** |
+| SwRS-38 | Verschlüsselte Speicherung TSA-Server-Passwort | ja | belegt |
+
+Ergebnis: 32 von 36 risikorelevanten Anforderungen (88,9 %) tragen einen `PRIMÄR`-Beleg; die verbleibenden 4 sind korrekt als `[HYPOTHESE]` gekennzeichnet, keine Anforderung verstößt gegen die risikobasierte Priorisierungsregel.
+
+**Abgleich `Hypothesen.md` gegen Inline-Markierungen:** Übereinstimmend geprüft – `Hypothesen.md` nennt exakt die 31 Anforderungen (StRS: 18, SyRS: 6, SwRS: 7), die in den drei Spezifikationsdateien mit `Status: HYPOTHESE` markiert sind (automatisiert per Skript abgeglichen, siehe Befehle in der Laufhistorie), keine zusätzlichen freien Fragen ohne zugehörige Anforderung.
+
+## 4. Abdeckungstabelle
+
+Siehe Abschnitt 2 (oben) – die dort geführte Tabelle ist die geforderte Abdeckungstabelle auf Basis des Modulinventars aus Schritt 0; jede Inventarzeile (M001–M122) ist darin mit Einstufung (tief/mittel/flach) und Anzahl der Anforderungen (siehe Korrekturhinweis) vertreten.
+
+## 5. Selbstbewertung
+
+**Tiefe der Analyse je Modul:** Von 122 Inventarmodulen wurden 8 tief (6,6 %), 46 mittel (37,7 %) und 68 flach (55,7 %) analysiert; kein Modul blieb unanalysiert. „Tief" bedeutet hier: der tatsächliche Kontrollfluss (nicht nur Signaturen) wurde gelesen und mit mindestens einer `[PRIMÄR]`-Belegstelle in einer risikorelevanten Anforderung hinterlegt. Die acht tiefen Module konzentrieren sich erwartungsgemäß auf die im Auftrag genannten Vertiefungsschwerpunkte: Sicherheitsregeln (Administration/Rights, Security/PdfSigning, TwoFactorAuthenticator, Controllers/Authorization), Abrechnungs-/Fakturierungslogik (Sales/Receipts) und Berechtigungsprüfungen (Administration/Rights, Rechtekatalog).
+
+**Mindestabdeckung:** Erreicht – alle 122 Module besitzen mindestens eine Anforderung. Bei der Erstabfassung von StRS.md wurden 28 Module (M015, M058, M060–M083, M099, M100) zunächst versehentlich ohne eigenen StRS-Eintrag übersprungen (ein Nummerierungssprung bei der fortlaufenden Erstellung); dies wurde noch im selben Lauf durch eine Selbstprüfung erkannt und durch die Anforderungen StRS-96 bis StRS-123 korrigiert, bevor das Dokument als abgeschlossen galt. Dieser Vorfall zeigt, dass die fortlaufende Nummerierung bei einer Spezifikation dieser Größe (134 StRS-Einträge) ein reales Fehlerrisiko birgt und in einer Folge-Iteration durch eine zusätzliche automatisierte Zwischenprüfung (Soll-/Ist-Abgleich Modulinventar vs. erzeugte StRS-IDs) abgesichert werden sollte.
+
+**Stellen mit dünnem Beleg:** 68 der 122 Module wurden ausschließlich anhand von Verzeichnis-/Dateinamen (ohne Lektüre des Methodenkörpers) beurteilt und sind entsprechend mit `SEKUNDÄR`- oder `KONTEXT`-Belegen bzw. direkt als `[HYPOTHESE]` geführt (18 der 31 Hypothesen betreffen genau solche „nur Verzeichnisstruktur gelesen"-Fälle auf StRS-Ebene). Besonders dünn belegt sind: die gesamte Deployment-/CI-CD-Infrastruktur (M118–M121, StRS-91/93/94), die Betriebsdokumentation (M122, StRS-95) sowie mehrere kleinere BL-Module, bei denen nur ein Klassenname, aber keine Methode gelesen wurde (z. B. M078/TradePool, StRS-116).
+
+**Warum nicht null Hypothesen:** Bei einer Codebasis dieser Größe (>75 fachliche BL-Ordner allein in `Centron.BL`, 72 zusätzliche WebServices-Unterordner, 8 externe API-Projekte, ein 77.660-Zeilen-DB-Schema) und dem in diesem Lauf verfügbaren Werkzeugsatz (ausschließlich Dateisuche/-lektüre und Kommandozeile, keine Codeausführung, keine Subagenten) ist eine vollständige Tiefenlektüre aller Module in einem einzelnen Lauf nicht leistbar. 31 Hypothesen (14,7 % aller Anforderungen) sind das ehrliche Ergebnis dieser bewussten Breite-vor-Tiefe-Priorisierung, nicht ein Zeichen mangelnder Sorgfalt bei den tatsächlich gelesenen Stellen (dort: 32 von 36 risikorelevanten Anforderungen mit `PRIMÄR`-Beleg).
+
+**Wesentlicher inhaltlicher Befund dieser Iteration:** Die Authentifizierungslogik (`BasicAuthenticator.cs`, `UsersBL.cs`) speichert und vergleicht Passwörter nachweislich über einen ungesalzenen SHA1-Hash; der Produktivcode selbst enthält dazu den Entwicklerkommentar „// TODO the password should be salted!!!“ (StRS-130, SyRS-36, SwRS-35). Dies ist der gravierendste Einzelbefund dieser Iteration und sollte bei einer Neuimplementierung vorrangig behandelt werden (Übernahmewürdigkeit: veraltet).
+
+**Empfehlungen für eine Folge-Iteration:**
+1. Vertiefung der 68 „flach" eingestuften Module, beginnend mit den größten (WebServices mit 72 Unterordnern; Statistics; ReportEngine; Mail; DataExchange; EDI-Lieferantenanbindungen ALSO/Alltron/Komsa/EGIS im Detail).
+2. Verifikation der offenen Hypothesen mit größtem Risikobezug zuerst: SyRS-31 (Passwortmanager-Rechteprüfung), SwRS-37 (mögliche Code-Duplizierung OposBL/DunningBL), SwRS-23 (Beziehung CryptoControl/AESCryptoLogic).
+3. Vollständige, systematische Paarvergleichsprüfung auf Konsolidierungskandidaten über alle 211 Anforderungen hinweg (in dieser Iteration nur exemplarisch, nicht vollständig durchgeführt).
+4. Lektüre der bislang nur über Verzeichnisstruktur erfassten Deployment-/CI-CD-Artefakte (`azure/`, `azure-blazor/`, `deployment/`, `docker/`), da diese für die SyRS-Betriebsanforderungen der geplanten SaaS-Neuimplementierung besonders relevant sind.
+5. Prüfung, ob die in StRS-96 dokumentierte, offenbar ungenutzte `CryptoUtils.CreatePasswordHash`-Implementierung tatsächlich an keiner Stelle aufgerufen wird (in dieser Iteration nur stichprobenhaft geprüft).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Glossar.md

@@ -0,0 +1,29 @@
+# Glossar
+
+Domänenbegriffe, die in den Anforderungen (StRS/SyRS/SwRS) dieser Iteration verwendet werden. Technische Bezeichner sind in ihrer Originalsprache belassen.
+
+| Begriff | Bedeutung |
+|---|---|
+| **I3D** | Primärschlüssel-Konvention in der c-entron-Datenbank; nahezu jede Entität führt ein Feld `I3D` als eindeutigen Identifikator (z. B. `Session.GetGenericDAO<T>().GetById(i3D)`). |
+| **Mandant / Mandantorship** | Fachlicher Betreiber-/Kundenkontext innerhalb einer c-entron-Installation; verwaltet über `MandatorBL` (`src/backend/Centron.BL/Administration/Company/MandatorBL.cs`). Eine Installation kann mehrere Mandanten führen. |
+| **Filiale / Branch** | Organisatorische Untereinheit eines Mandanten; mehrere Rechte sind auf „nur eigene Filiale" einschränkbar (`BranchI3D`, siehe `CentronRights.md`). |
+| **Recht / AppRight** | Einzelne Berechtigung im Rechtesystem, gespeichert in Tabelle `Sichrech`, Zuordnung zu Gruppen über `Sichtrus`; ein Benutzer erbt Rechte über seine Gruppenmitgliedschaft (`Sichmemb`). |
+| **Einschränkendes Recht (restricting right)** | Sonderform eines Rechts, das den Sichtbereich einschränkt statt eine Aktion freizuschalten, z. B. „Tickets anzeigen – nur eigene" (`CentronRights.md`, Abschnitt 1.1). |
+| **Stammblatt** | Historische Datenhaltung für Drucker-Hardware, getrennt von der allgemeinen Asset-Verwaltung (`DocuBoard`/`AssetManagement*`); Konsolidierungskandidat lt. Aufgabenstellung. |
+| **Asset (Asset Management)** | Allgemeine Geräte-/Hardware-Verwaltung (`AssetManagementPartnerBL`, `AssetManagementArticleAssignmentBL`), fachlich überlappend mit „Stammblatt". |
+| **OPOS** | Offene-Posten-Liste (offene Forderungen), Zugriff geschützt über Recht `UserRightsConst.Controlling.Finances.Dunning` (`OposBL.ThrowIfUserHasInsufficentRights`). |
+| **Mahnwesen / Dunning** | Prozess zur Zahlungserinnerung säumiger Kunden (`DunningBL`, `DunningRunBL`, `DunningCustomer`). |
+| **I3D-Sperre / Lock** | Pessimistisches Sperren eines Datensatzes während der Bearbeitung, z. B. `InvoiceLock` über `AssetLockBL<T>.LockReceipt`. |
+| **EDI** | Electronic Data Interchange – automatisierter Beleg-/Bestelldatenaustausch mit Lieferanten (ALSO, Alltron, Komsa, EGIS, Concerto u. a.), `src/backend/Centron.BL/EDI`. |
+| **RMA** | Return Merchandise Authorization – Retourenabwicklung (`RmaBL`, UI-Modul `Rma`). |
+| **PLM** | Product Lifecycle Management – Produktlebenszyklus-Verwaltung (`ProductLifecycleBL`, UI-Modul `PLM`). |
+| **Nexus / CentronNexus** | Blazor-basiertes Web-Ticketportal/Serviceboard, eigenständiges Projekt `src/nexus/CentronNexus`, kommuniziert mit dem c-entron-Kern über `CentronNexusBL`. |
+| **RiverDivo / Riverbird** | Externe mobile/Web-Anwendung, die über einen dedizierten Web-Service-Layer (`RiverDivoBL`) an c-entron andockt. |
+| **TAPI** | Telephony API – Anbindung an Telefonanlagen zur Anruferkennung (`PhoneCallBL`, `TapiBL`). |
+| **DSGVO-Bereinigung** | Funktion zur Umsetzung von Löschpflichten nach Datenschutz-Grundverordnung, rechtegeschützt über `UserRightsConst.DsgvoModule.ACCESS_CLEANUP_DATABASE` (`DataSecurityBL`). |
+| **CPra** | Externer Cloud-Provisioning-Dienst (`https://c-pra.c-entron.de`), an den sich `CPraConnectorBL` mit Benutzername/Passwort anmeldet. |
+| **Two-Factor / 2FA** | Zusätzlicher Anmeldefaktor, wahlweise per TOTP (Google-Authenticator-kompatibel), E-Mail oder RADIUS (`TwoFactorAuthBL`, `TwoFactorAuthenticationBL`). |
+| **Webaccount** | Externer, kundenseitiger Zugang (SelfCare-Portal) im Unterschied zum internen `AppUser` (Mitarbeiterzugang). |
+| **ES-Rolle (EsRole)** | Rollenkonzept einer externen „ElectronicSales"-Integration, separat vom internen Rechtesystem gepflegt (`EsRoleBL`). |
+| **Zugferd / XRechnung** | Deutsches Format für hybride elektronische Rechnungen, umgesetzt in `InvoiceZugferdBL`. |
+| **ebInterface** | Österreichisches Standardformat für elektronische Rechnungen (`Centron.Api.EbInterface`). |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Hypothesen.md

@@ -0,0 +1,55 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]`/`Status: HYPOTHESE` markierten Anforderungen aus `StRS.md`, `SyRS.md` und `SwRS.md`, mit der jeweils offenen Frage, die zur Bestätigung fehlt. Diese Liste ist deckungsgleich mit den Inline-Markierungen (siehe Konsistenzcheck in `Analysebericht.md`, Abschnitt 3) und enthält keine zusätzlichen freien Fragen ohne zugehörige Anforderung.
+
+**Gesamtzahl: 31** (StRS: 18 · SyRS: 6 · SwRS: 7).
+
+## StRS (18)
+
+| ID | Titel | Offene Frage |
+|---|---|---|
+| StRS-8 | Externe Einkaufsanbindungen | Welchen konkreten Datenaustausch `Buying/External` realisiert – Verzeichnisinhalt wurde nicht gelesen. |
+| StRS-13 | Änderungshistorie von Objekten | Ob `ChangeTracking/History` tatsächlich objektartübergreifend historisiert oder nur einzelne Bereiche abdeckt. |
+| StRS-18 | Kundenspezifische Zusatztabellen | Konkreter technischer Mechanismus und Umfang von `CustomTables` – nur Verzeichnisname bekannt. |
+| StRS-22 | Freitext-Dokumentation zu Objekten | Welchen Objektarten `DocumentationBL` konkret zugeordnet werden kann. |
+| StRS-31 | Technische Hilfsfunktionen für Dokumentenverarbeitung | Welche Fachmodule die `Helpers`-Klassen tatsächlich referenzieren und wie. |
+| StRS-35 | Logistikeinstellungen | Konkreter Funktionsumfang von `LogisticSettings` – nur Verzeichnisstruktur bekannt. |
+| StRS-61 | Webservice-seitige Bereitstellung der Fachdomänen | Ob wirklich alle 72 `WebServices`-Unterordner vollständige funktionale Parität zum Desktop-Client bieten, oder ob Lücken bestehen. |
+| StRS-62 | Web-Administrationsfunktionen | Konkreter Funktionsumfang von `WebSuite/Administration` – nur Verzeichnisstruktur bekannt. |
+| StRS-82 | Gemeinsame Konstanten und Erweiterungsmethoden | Insbesondere Zweck und Umfang von `DeveloperSecurity.cs` ungeklärt. |
+| StRS-91 | Installationspakete für Desktop-Anwendung und Riverbird | Konkreter Inhalt von `deployment/WixSharpInstaller` nicht gelesen. |
+| StRS-93 | Automatisierte Build-/Analyse-Pipeline (Desktop-Anwendung) | Konkreter Pipelineninhalt (Werkzeuge, Qualitätsschwellen) nicht gelesen. |
+| StRS-94 | Automatisierte Build-/Sicherheits-Pipeline (Nexus) | Welches SAST-/DAST-Werkzeug in `security-pipeline.yaml` tatsächlich eingesetzt wird. |
+| StRS-95 | Strukturierte Betriebs-/Feature-Dokumentation | Konkreter Inhalt der `docs/`-Unterordner nicht gelesen. |
+| StRS-101 | Zwischengespeicherte Tabellen und Datenqualitätsprüfung | Konkreter Prüfalgorithmus der Datenqualitätsprüfung nicht gelesen. |
+| StRS-103 | Zentrale Startlogik der Anwendung | Konkreter Inhalt von `Centron.BL/Start` nicht gelesen. |
+| StRS-109 | Aufgabenverwaltung mit Aktions-Handlern | Konkrete Implementierungen unter `TaskManager/ActionHandler` nicht gelesen. |
+| StRS-116 | Handelspool-Anbindung | Konkreter Inhalt von `TradePoolBL`/`Core` nicht gelesen, nur Klassenname als Indiz. |
+| StRS-127 | Richtlinienkonformität von Passworteinträgen | Konkreter Prüfalgorithmus gegen `Guideline`-Entitäten nicht gelesen. |
+
+## SyRS (6)
+
+| ID | Titel | Offene Frage |
+|---|---|---|
+| SyRS-5 | Echtzeit-Benachrichtigung über SignalR-artigen Hub | Ob tatsächlich eine Push-Technologie (z. B. SignalR) verwendet wird oder ein Polling-Mechanismus – „Hub"-Namensgebung ist nur ein Indiz. |
+| SyRS-7 | Blacklist-Prüfung vor E-Mail-Versand | Ob wirklich jeder automatisierte Mail-Versandpfad die Blacklist konsultiert, oder ob Ausnahmen bestehen. |
+| SyRS-21 | Containerbasierte Referenzumgebung für Tests | Ob der Mailcatcher tatsächlich lückenlos jeden während Regressionstests versendeten Testmailversand abfängt. |
+| SyRS-22 | Rekursive Kategoriehierarchie mit Zyklusrisiko | Ob im vollständigen Code tatsächlich keine Zyklus-/Tiefenbegrenzung existiert (nur Methodenausschnitt gelesen). |
+| SyRS-26 | Konsistente Enum-basierte Statusfilterung bei Gutscheinen | Wie das System bei fachlich widersprüchlichen Filterkombinationen (z. B. „frei" und „eingelöst" gleichzeitig) tatsächlich reagiert. |
+| SyRS-31 | Rechtegeschützter Zugriff auf den Passwortmanager | Konkrete Methode und Rechte-ID, die den Zugriff auf hinterlegte Zugangsdaten tatsächlich absichert – nur Konstruktor-Injektion von `AppRightsBL` gelesen. |
+
+## SwRS (7)
+
+| ID | Titel | Offene Frage |
+|---|---|---|
+| SwRS-7 | Enum ReportDefaultValues als Flags für kombinierbare Ausgabewege | Ob das `[Flags]`-Attribut im vollständigen Enum tatsächlich fehlt (nur Ausschnitt gelesen). |
+| SwRS-13 | Zustandsfilter für mobile Mitarbeiterentität über Zahlencode | Ob an anderer Stelle im Entitätsmodell doch ein benanntes Enum für `NewMobileEmployee.State` existiert. |
+| SwRS-15 | DSGVO-Löschvermerk als Textersetzung statt Datensatzlöschung | Welches konkrete Feld überschrieben wird und ob referenzielle Integrität (z. B. verknüpfte Tickets) dabei erhalten bleibt. |
+| SwRS-18 | Rekursiver Aufbau der Elternkategorien ohne Tiefenbegrenzung | Siehe SyRS-22 – ob im vollständigen Code eine Abbruchbedingung existiert. |
+| SwRS-20 | SOAP-Vorlagen als eigenständige Ressourcendateien (COP-Anbindung) | Konkreter Inhalt der `SoapTemplates`-Dateien nicht gelesen. |
+| SwRS-23 | AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse | Ob `CryptoControl` (KI-Modul) und `AESCryptoLogic` (PDF-Signatur) tatsächlich dieselbe zugrunde liegende Implementierung nutzen oder unabhängige Parallelimplementierungen sind. |
+| SwRS-37 | Identische Rechteprüfmethode ThrowIfUserHasInsufficentRights in zwei Klassen | Ob `DunningBL.ThrowIfUserHasInsufficentRights` tatsächlich dieselbe Implementierung wie `OposBL` nutzt (gemeinsame Basisklasse) oder eine unabhängige Kopie ist. |
+
+## Hinweis zur Selbstbewertung
+
+Diese Iteration führt bewusst eine zweistellige Zahl an Hypothesen (31 von 211 Anforderungen, 14,7 %). Angesichts der Größe der Codebasis (>75 fachliche BL-Ordner, 77.660-Zeilen-DB-Schema) und des in diesem Lauf verfügbaren Werkzeugsatzes (nur Dateisuche/-lektüre, keine Ausführung, kein Subagent) ist eine vollständig hypothesenfreie Analyse nicht plausibel – die Mehrzahl der Hypothesen entsteht dort, wo aus Zeitgründen nur die Verzeichnisstruktur, nicht aber der vollständige Quelltext gelesen wurde (Breite-vor-Tiefe-Vorgehen gemäß Auftrag). Details siehe Selbstbewertung in `Analysebericht.md`, Abschnitt 6.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/SwRS.md

@@ -0,0 +1,773 @@
+# Software Requirements Specification (SwRS)
+
+Iteration 02 · c-entron ERP-Suite. Komponenten, Datenmodelle, software-interne Regeln, abgeleitet aus SyRS/StRS. SwRS-1 bis SwRS-29 vertiefen ausgewählte Breitenmodule auf Softwareebene; SwRS-30 bis SwRS-38 sind die risikofokussierte Vertiefung.
+
+---
+
+```
+ID:            SwRS-1
+Titel:         Basisklasse PersistedEntity als Wurzel aller Fachentitäten
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `PersistedEntity.cs`, `PersistedLongEntity.cs` unter `src/backend/Centron.Entities`; jede in dieser Iteration gelesene Fachentität (z. B. `BankAccount`, `AppUser`, `Project`) besitzt ein `I3D`-Feld.
+Aussage:       Jede persistierte Fachentität soll von `PersistedEntity` (Int-Schlüssel) oder `PersistedLongEntity` (Long-Schlüssel) erben.
+Ergebnis:      Eine neue Fachentität erhält automatisch ein konsistentes Schlüsselverhalten.
+Belege:
+  - [PRIMÄR] src/backend/Centron.Entities/PersistedEntity.cs, PersistedLongEntity.cs – Begründung: konkrete Basisklassen im Code definieren das Schlüsselverhalten strukturell.
+Prüfidee:      Eine von `PersistedEntity` erbende Testentität besitzt nach dem Speichern automatisch eine eindeutige I3D.
+Tracelinks:    StRS-84
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistentes Basisklassendesign, im Zielsystem als Basis-Aggregat/Entity-Interface fortzuführen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-2
+Titel:         Generische DAO-Klasse mit Expression-basierter Filterung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `GenericDAO<T>` (`src/backend/Centron.DAO`) wird durchgängig mit `Expression<Func<T, bool>>`-Filtern aufgerufen (z. B. `BankAccountBL.GetList(Expression<Func<BankAccount, bool>> expression)`).
+Aussage:       Die generische DAO-Klasse soll typsichere LINQ-Expressions als Filterkriterium akzeptieren, statt modulspezifischer SQL-Strings.
+Ergebnis:      Filterkriterien werden zur Kompilierzeit typgeprüft.
+Belege:
+  - [PRIMÄR] src/backend/Centron.DAO/GenericDAO.cs, Signatur GetList(Expression<Func<T,bool>>) – Begründung: durchgängig beobachtetes, typsicheres Filtermuster.
+Prüfidee:      Ein fehlerhafter Feldname in einer Filter-Expression wird bereits beim Kompilieren erkannt.
+Tracelinks:    SyRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - typsichere Filterung ist im Zielsystem fortzuführen (z. B. via Repository-Pattern mit Specification-Objekten).
+Status:        belegt
+```
+
+```
+ID:            SwRS-3
+Titel:         Dispatcher-Klasse für lieferantenspezifische EDI-Order-BL
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `EDIDispatcherBL` hält lazy-initialisierte, lieferantenspezifische Order-BL-Instanzen (`_opentrans21OrderBL ??= new Opentrans21OrderBL(...)`).
+Aussage:       Die EDI-Dispatcher-Komponente soll lieferantenspezifische Order-Implementierungen lazy instanziieren, um unnötige Objekterzeugung bei ungenutzten Lieferanten zu vermeiden.
+Ergebnis:      Nur tatsächlich angefragte Lieferanten-Implementierungen werden instanziiert.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs, Methode GetOpentrans21OrderBL, Null-Coalescing-Zuweisung – Begründung: konkretes Lazy-Initialisierungsmuster im Code.
+Prüfidee:      Ein Dispatcher-Aufruf ohne Opentrans21-Bezug erzeugt nachweislich keine `Opentrans21OrderBL`-Instanz.
+Tracelinks:    SyRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - ressourcenschonendes Muster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-4
+Titel:         DTO-Mapper-Konfigurationsklassen je Fachbereich
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `DunningConfiguration.cs` unter `src/backend/Centron.BL/WebServices/ObjectMapperConfiguration`.
+Aussage:       Jede über die Webservice-Schicht exponierte Fachdomäne soll eine eigene, explizite Mapper-Konfigurationsklasse besitzen.
+Ergebnis:      Das Mapping zwischen interner Entität und DTO ist an einer einzigen, benannten Stelle je Fachbereich nachvollziehbar.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/DunningConfiguration.cs – Begründung: dedizierte, fachbereichsbezogene Mapper-Konfigurationsklasse belegt das Muster exemplarisch für Dunning.
+Prüfidee:      Für jeden über SwRS-4 geprüften Fachbereich existiert genau eine zugehörige `*Configuration.cs`-Datei im ObjectMapperConfiguration-Ordner.
+Tracelinks:    SyRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - explizites Mapping ist wartungsfreundlicher als automatisches Reflection-Mapping.
+Status:        belegt
+```
+
+```
+ID:            SwRS-5
+Titel:         Registrierte Fulltext-Index-Implementierungen als Liste
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `IndexSearchBL._objectIndexes` ist eine feste Liste `{ new TicketFulltextIndex(), new AccountFulltextIndex() }`, deren Interface `IObjectFulltextIndex` ein `Kind`-Property vorsieht.
+Aussage:       Neue indizierbare Objektarten sollen über eine Implementierung von `IObjectFulltextIndex` und Eintragung in die Indexliste ergänzbar sein, ohne die Kernlogik von `IndexSearchBL` zu ändern.
+Ergebnis:      Eine dritte indizierbare Objektart (z. B. Verträge) lässt sich durch eine neue Klasse plus Listeneintrag ergänzen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, Feld `_objectIndexes`, Interface IObjectFulltextIndex – Begründung: konkrete, offene Liste mit klarem Erweiterungspunkt über ein gemeinsames Interface.
+Prüfidee:      Eine neu implementierte `IObjectFulltextIndex`-Klasse wird nach Eintragung in `_objectIndexes` von `UpdateAllIndexes` automatisch mit verarbeitet.
+Tracelinks:    SyRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Open/Closed-konformes Erweiterungsmuster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-6
+Titel:         Handler-Registry für Web-Link-Aktionen
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `WebLinkBL._handlers` ist eine `List<IWebLinkActionHandler>`, initial mit `WebLinkActionAccountActivityHandler`.
+Aussage:       Web-Link-Aktionen sollen über eine Handler-Liste nach dem Strategie-Muster erweiterbar sein.
+Ergebnis:      Eine neue Web-Link-Aktion lässt sich durch eine zusätzliche `IWebLinkActionHandler`-Implementierung ergänzen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/WebLinks/WebLinkBL.cs, Feld _handlers, Interface IWebLinkActionHandler – Begründung: konkretes Strategie-Muster im Code.
+Prüfidee:      Eine neue Handler-Implementierung für „ReminderHandler" wird bei Aufruf eines entsprechend typisierten Web-Links korrekt ausgeführt.
+Tracelinks:    StRS-60
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klar erweiterbares Muster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-7
+Titel:         Enum ReportDefaultValues als Flags für kombinierbare Ausgabewege
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ReportsBL.ReportDefaultValues { Email = 1, PDF = 2, Print = 4 }` – Zweierpotenzwerte ohne erkennbares `[Flags]`-Attribut im gelesenen Ausschnitt.
+Aussage:       Das Enum `ReportDefaultValues` soll als kombinierbares Flags-Enum verwendet und im Zielsystem explizit mit `[Flags]` annotiert werden, um die Bitmasken-Semantik unmissverständlich zu machen.
+Ergebnis:      Kombinierte Werte (z. B. 3 = Email+PDF) sind sowohl im Code als auch für Werkzeuge (Debugger, Serialisierung) eindeutig als Kombination erkennbar.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Reporting/ReportsBL.cs, Enum ReportDefaultValues – Begründung: Zweierpotenzwerte sind im Code konkret erkennbar, das `[Flags]`-Attribut wurde im gelesenen Ausschnitt jedoch nicht gesehen.
+Prüfidee:      Noch zu bestimmen – Vertiefung erforderlich, ob `[Flags]` tatsächlich fehlt (nur Ausschnitt gelesen).
+Tracelinks:    SyRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da nur Teilausschnitt gelesen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-8
+Titel:         Verkettete Entität ValueAddedTax mit Selbstreferenz NextTaxRate
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ValueAddedTax.NextTaxRate` (Selbstreferenz), genutzt in `TaxBL.GetActiveVatThroughNextVats`.
+Aussage:       Die Entität `ValueAddedTax` soll über eine Selbstreferenz `NextTaxRate` eine geordnete Kette von Steuersatzänderungen abbilden.
+Ergebnis:      Jeder Steuersatz kennt seinen unmittelbaren Nachfolger, wodurch eine Kette ohne separate Zwischentabelle entsteht.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Warehousing/TaxBL.cs, Zugriff `vat.NextTaxRate` – Begründung: konkrete Verwendung der Selbstreferenz im gelesenen Code.
+Prüfidee:      Ein `ValueAddedTax`-Datensatz mit gesetztem `NextTaxRate` verweist auf einen weiteren gültigen `ValueAddedTax`-Datensatz.
+Tracelinks:    SyRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - einfaches, funktionierendes Datenmodell für zeitlich geltende Werte.
+Status:        belegt
+```
+
+```
+ID:            SwRS-9
+Titel:         Cache-Felder für belegartspezifische Textbausteine
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `TextModuleBL` hält sechs private `TextModule`-Cache-Felder (Offer/Order/DeliveryList/PickupList/Invoice/CreditVoucher, je Salutation/Agreement).
+Aussage:       Die Klasse `TextModuleBL` soll je Belegart und Textbaustein-Typ ein eigenes Cache-Feld führen, um wiederholte Datenbankzugriffe innerhalb einer Session zu vermeiden.
+Ergebnis:      Ein zweiter Zugriff auf denselben Textbaustein innerhalb derselben BL-Instanz erfolgt ohne erneuten Datenbankzugriff.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs, Zeilen 24–35, sechs Cache-Felder – Begründung: konkrete Feldliste im Code.
+Prüfidee:      Zwei aufeinanderfolgende Abrufe der Rechnungs-Anrede innerhalb derselben BL-Instanz erzeugen nur eine Datenbankabfrage.
+Tracelinks:    SyRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - sinnvolle Session-lokale Zwischenspeicherung.
+Status:        belegt
+```
+
+```
+ID:            SwRS-10
+Titel:         Abgleichsalgorithmus für Modulregistrierung anhand ModuleGuid
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ModuleBL.DoCreateMissingInternalModulesInDB`: `modules.Where(f => dbModules.Any(d => d.ModuleGuid.Equals(f.ModuleGuid, StringComparison.OrdinalIgnoreCase)) == false)`.
+Aussage:       Der Modulabgleich soll `ModuleGuid` case-insensitiv vergleichen, um Groß-/Kleinschreibungsunterschiede zwischen Code- und DB-GUIDs nicht als „fehlendes Modul" fehlzuinterpretieren.
+Ergebnis:      Ein Modul mit identischer GUID, aber abweichender Schreibweise, wird nicht fälschlich doppelt angelegt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs, StringComparison.OrdinalIgnoreCase – Begründung: konkreter, im Code sichtbarer Vergleichsparameter.
+Prüfidee:      Eine DB-GUID in Kleinbuchstaben und eine Code-GUID in Großbuchstaben werden als identisch erkannt.
+Tracelinks:    SyRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - robuste Vergleichslogik.
+Status:        belegt
+```
+
+```
+ID:            SwRS-11
+Titel:         Objektart-Diskriminierung bei überlappenden I3D-Bereichen
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `NexusTicketView.CreatedByI3D` wird gemeinsam mit einem `CentronObjectKindNumeric`-Diskriminator (`Webaccount` vs. `EmployeeClass`) gespeichert, ermittelt über `GetCreatedByObjectKind`.
+Aussage:       Referenzen auf potenziell mehrdeutige I3Ds (Mitarbeiter vs. Web-Account) sollen stets zusammen mit einem expliziten Objektart-Diskriminator gespeichert werden.
+Ergebnis:      Eine Abfrage nach „CreatedByI3D=5" liefert ohne zusätzlichen Diskriminator kein eindeutiges Ergebnis; erst die Kombination aus I3D und Objektart ist eindeutig.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs, Methode GetCreatedByObjectKind, Rückgabe CentronObjectKindNumeric.Webaccount/EmployeeClass – Begründung: konkrete, im Code umgesetzte Diskriminator-Logik.
+Prüfidee:      Zwei Ticketansichten mit identischer CreatedByI3D, aber unterschiedlichem Objektart-Diskriminator, werden als unterschiedliche Datensätze behandelt.
+Tracelinks:    SyRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendiges Diskriminierungsmuster bei geteilten Nummernräumen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-12
+Titel:         Zehn unabhängige Boolean-Konfigurationsfelder für Kalenderdarstellung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `CalendarRepresentationSettingsDTO` besitzt zehn Boolean-Properties, 1:1 aus `AppSettingsConst.HelpdeskTimeDisplay*` befüllt.
+Aussage:       Das DTO `CalendarRepresentationSettingsDTO` soll je Konfigurationsschalter ein eigenes, unabhängiges Boolean-Property führen.
+Ergebnis:      Jeder Schalter ist über sein eigenes Property einzeln lesbar und setzbar.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, Methode GetCalendarRepresentationSettings, zehn Zuweisungen – Begründung: vollständig gelesene 1:1-Zuordnung von Konfigurationsschalter zu DTO-Property.
+Prüfidee:      Jedes der zehn DTO-Properties lässt sich unabhängig von den übrigen neun setzen und auslesen.
+Tracelinks:    SyRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klares, wenn auch granulares Konfigurationsmodell.
+Status:        belegt
+```
+
+```
+ID:            SwRS-13
+Titel:         Zustandsfilter für mobile Mitarbeiterentität über Zahlencode
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `NewMobileEmployee.State` wird in `MobileBL.GetMobileEmployee()` mit dem Literal `1` verglichen, ohne erkennbares Enum im gelesenen Ausschnitt.
+Aussage:       Das Feld `NewMobileEmployee.State` soll im Zielsystem durch ein benanntes Enum (z. B. `MobileEmployeeState.Active = 1`) ersetzt werden, um die „magische Zahl" les- und wartbar zu machen.
+Ergebnis:      Der Vergleich `State == 1` wird durch einen selbsterklärenden Enum-Vergleich ersetzt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, Filter `f => f.State == 1` – Begründung: konkreter, im Code sichtbarer Zahlenvergleich ohne erkennbares Enum.
+Prüfidee:      Noch zu bestimmen – Vertiefung erforderlich, ob im Entitätsmodell an anderer Stelle doch ein Enum für `State` existiert.
+Tracelinks:    SyRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - magische Zahl ist ein Wartbarkeitsrisiko und im Zielsystem zu bereinigen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-14
+Titel:         SQL-MERGE-Upsert mit HOLDLOCK für Telemetrie-Zähler
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `TelemetryBL.UpsertMcpToolUsageBatch` generiert dynamisch ein `MERGE dbo.McpToolUsageTelemetry WITH (HOLDLOCK) AS T USING (VALUES ...)`-Statement mit zusammengesetztem Schlüssel (`UserID, ToolNameI3D, HardwareIDI3D, ToolMode, BucketStartUtc`).
+Aussage:       Die Telemetrie-Tabelle `McpToolUsageTelemetry` soll einen zusammengesetzten fachlichen Schlüssel aus fünf Feldern führen und Batch-Updates ausschließlich über das dokumentierte HOLDLOCK-MERGE-Muster verarbeiten.
+Ergebnis:      Parallele Batch-Updates auf denselben Schlüssel führen zu korrekt aufaddierten Zählerständen ohne Duplikate.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Methode UpsertMcpToolUsageBatch, SQL-Text Zeilen 36–47 – Begründung: vollständig im Code sichtbares SQL-Statement mit explizitem Schlüssel und Lock-Hinweis.
+Prüfidee:      Zwei parallele Aufrufe mit identischem Schlüssel, aber unterschiedlichem Inkrement, führen zu einem korrekt summierten `Count`-Wert.
+Tracelinks:    SyRS-18
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - technisch fundiertes, dokumentiertes Muster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-15
+Titel:         DSGVO-Löschvermerk als Textersetzung statt Datensatzlöschung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `DataSecurityBL`, Konstanten `DsgvoDeletedContactMessage`/`DsgvoDeletedContactMessageWithEmployeeInfo` werden vermutlich in ein Namens-/Freitextfeld des Kontakts geschrieben (konkrete Zielspalte im gelesenen Ausschnitt nicht identifiziert).
+Aussage:       Bei DSGVO-Löschung soll das betroffene Namens-/Kontaktfeld durch einen Standardtext mit Bearbeiter- und Zeitstempel-Platzhaltern ersetzt werden, statt den Datensatz zu löschen.
+Ergebnis:      Historische Verweise (z. B. in abgeschlossenen Tickets) bleiben referenzierbar, zeigen aber keine personenbezogenen Daten mehr.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Konstanten DsgvoDeletedContactMessage(WithEmployeeInfo) – Begründung: Konstantentext belegt das Muster, die konkrete Zielspalte des Ersetzungsvorgangs wurde nicht identifiziert.
+Prüfidee:      Noch zu bestimmen – Vertiefung erforderlich: welches Feld genau überschrieben wird und ob referenzielle Integrität (z. B. verknüpfte Tickets) erhalten bleibt.
+Tracelinks:    SyRS-19
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-16
+Titel:         Filialbezogene Datenfilterung über BranchI3D-Vergleich
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `AppRightsBL.GetAllRightGroups`: `query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0))`.
+Aussage:       Die Filialeinschränkung soll über einen direkten Gleichheitsvergleich des `BranchI3D`-Feldes auf Query-Ebene (nicht nachträglich im Anwendungsspeicher) erfolgen.
+Ergebnis:      Die Filterung wird an die Datenbank delegiert (SQL-`WHERE`), nicht im Anwendungsspeicher nach vollständigem Laden durchgeführt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeile 42–47, `IQueryable`-Filterung vor `.ToList()` – Begründung: die Filterung erfolgt auf einer `IQueryable<AppGroup>`, wird also als SQL-Prädikat übersetzt statt im Speicher.
+Prüfidee:      Bei aktivierter Datenbank-Traceanalyse enthält die generierte SQL-Abfrage eine WHERE-Klausel auf BranchI3D, statt alle Zeilen zu laden.
+Tracelinks:    SyRS-1, SyRS-28
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Performance- und sicherheitsrelevante Query-seitige Filterung.
+Status:        belegt
+```
+
+```
+ID:            SwRS-17
+Titel:         Lazy-Instanziierung des Lizenzmanagers als Singleton
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `LicenseManager.Instance.HasLicense(...)` (statischer Singleton-Zugriff) in `ProductionOrderBL`; zusätzlich `ILicenseManager`-Interface für Dependency Injection in `AppUserBL`/`UsersBL`.
+Aussage:       Der `LicenseManager` soll sowohl über ein statisches Singleton (`Instance`) als auch über ein injizierbares Interface (`ILicenseManager`) zugreifbar sein, um sowohl bestehenden Code als auch testbaren, neuen Code zu unterstützen.
+Ergebnis:      Bestehender Code kann weiterhin über `Instance` zugreifen, während neuer Code über Konstruktorinjektion testbar bleibt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (LicenseManager.Instance) vs. src/backend/Centron.BL/EmployeeArea/AppUserBL.cs (ILicenseManager im Konstruktor) – Begründung: zwei unterschiedliche, tatsächlich beobachtete Zugriffsmuster für dieselbe Komponente.
+Prüfidee:      Ein Unit-Test von `AppUserBL` kann `ILicenseManager` durch ein Test-Double ersetzen, ohne den globalen Singleton-Zustand zu beeinflussen.
+Tracelinks:    SyRS-8
+Konsolidierung: Kandidat: (kein StRS/SyRS-Pendant, aber technischer Hinweis) – Begründung: zwei Zugriffsmuster für dieselbe Komponente sind im Zielsystem auf ein einheitliches DI-Muster zu konsolidieren.
+Übernahmewürdigkeit: Workaround - der Singleton-Zugriffspfad (`Instance`) ist ein Übergangsmuster; im Zielsystem konsequent auf Dependency Injection umzustellen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-18
+Titel:         Rekursiver Aufbau der Elternkategorien ohne Tiefenbegrenzung
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ChecklistVirtualObjectCategoryBL.GetChecklistVirtualObjectCategoriesByFilter`, `while(recentlyAddedI3Ds.Count > 0)`-Schleife ohne erkennbaren maximalen Iterationszähler.
+Aussage:       Die rekursive Ladeschleife für Elternkategorien soll um eine explizite Tiefen- oder Zyklusbegrenzung ergänzt werden.
+Ergebnis:      Die Schleife terminiert garantiert auch bei fehlerhaften, zyklischen `ParentI3D`-Referenzen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs, Zeilen 37–44 – Begründung: konkrete Schleife ohne im gelesenen Ausschnitt erkennbare Abbruchbedingung außer dem natürlichen Leerwerden der Liste.
+Prüfidee:      Eine synthetisch erzeugte zyklische Elternreferenz (A→B→A) führt beim Laden zu einem kontrollierten Fehler statt zu einer Endlosschleife.
+Tracelinks:    SyRS-22
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion übernehmenswert, Robustheitsergänzung im Zielsystem umzusetzen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-19
+Titel:         Named-Query-Parameter-Bindung als durchgängiges Zugriffsmuster
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `NamedQueryParameter`-Objekte (z. B. in `TwoFactorAuthenticationBL`, `OutlookAssetKindSearchBL`, `VoucherManagementBL`) werden durchgängig statt String-Konkatenation verwendet.
+Aussage:       Datenbankzugriffe außerhalb der generischen DAO-Schicht sollen ausschließlich über parametrisierte Named Queries erfolgen.
+Ergebnis:      Es existiert kein beobachteter Codepfad, der Benutzereingaben direkt in SQL-Strings einfügt.
+Belege:
+  - [PRIMÄR] mehrfach beobachtet, u. a. src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs – Begründung: konsistentes Muster über mehrere unabhängig gelesene Klassen hinweg.
+Prüfidee:      Eine Codesuche nach String-Konkatenation mit Benutzereingaben in SQL-Kontext liefert außerhalb der geprüften Stellen keine Treffer (Stichprobe).
+Tracelinks:    SyRS-27
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - sicheres Zugriffsmuster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-20
+Titel:         SOAP-Vorlagen als eigenständige Ressourcendateien (COP-Anbindung)
+Ebene:         SwRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `src/apis/Centron.APIs.CopDataAccess/SoapTemplates` als eigener Ordner neben `CopApi.cs`.
+Aussage:       Die COP-API-Anbindung soll SOAP-Envelope-Vorlagen als separate Ressourcendateien führen, um sie unabhängig vom C#-Code pflegen zu können.
+Ergebnis:      Eine Anpassung eines SOAP-Templates erfordert keine Neukompilierung der Kernlogik.
+Belege:
+  - [KONTEXT] src/apis/Centron.APIs.CopDataAccess/SoapTemplates (Verzeichnisname) – Begründung: dedizierter Vorlagenordner belegt Trennung von Vorlage und Logik; Inhalt nicht gelesen.
+Prüfidee:      Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich.
+Tracelinks:    StRS-64
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-21
+Titel:         Getrennte Fehlerklassen je externer API-Anbindung
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `CopException.cs`, `EgisException.cs`, `ITscopeException.cs`, `IcecatException.cs` als jeweils eigene Exception-Klasse je API-Projekt.
+Aussage:       Jede externe API-Anbindung soll eine eigene, typisierte Exception-Klasse führen, um Fehler der jeweiligen Fremdsystem-Anbindung eindeutig unterscheidbar zu machen.
+Ergebnis:      Ein Aufrufer kann gezielt gegen die jeweilige API-Exception behandeln, ohne generische Exceptions abfangen zu müssen.
+Belege:
+  - [SEKUNDÄR] src/apis/*/*.Exception.cs (vier unabhängige Projekte) – Begründung: identisches Namensmuster über vier unabhängige API-Projekte hinweg belegt bewusste, konsistente Konvention.
+Prüfidee:      Ein Fehler bei der COP-Anbindung wirft nachweislich `CopException`, nicht eine generische `Exception`.
+Tracelinks:    StRS-64, StRS-65, StRS-67, StRS-68
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistente, typisierte Fehlerbehandlung.
+Status:        belegt
+```
+
+```
+ID:            SwRS-22
+Titel:         Parallele Host-Einstiegspunkte für denselben Webservice-Kern
+Ebene:         SwRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `Centron.Host.Console/Program.cs` und `Centron.Host.WindowsService/CentronService.cs`/`Program.cs` referenzieren beide `Centron.Host` als gemeinsame Kernbibliothek.
+Aussage:       Beide Host-Projekte sollen ausschließlich als dünne Einstiegspunkte fungieren, die den identischen `Centron.Host`-Kern starten, ohne eigene Fachlogik zu duplizieren.
+Ergebnis:      Eine Änderung am Host-Kern wirkt sich identisch auf beide Betriebsarten aus, ohne dass beide Projekte separat angepasst werden müssen.
+Belege:
+  - [SEKUNDÄR] src/webservice/Centron.Host.Console/Program.cs, src/webservice/Centron.Host.WindowsService/Program.cs – Begründung: beide Projekte referenzieren strukturell denselben Host-Kern (Projektabhängigkeit, nicht im Detail gelesen).
+Prüfidee:      Eine Änderung an einer Kernfunktion in `Centron.Host` wird ohne Codeänderung in Console oder WindowsService in beiden Betriebsarten wirksam.
+Tracelinks:    StRS-73, StRS-123
+Konsolidierung: Kandidat: StRS-73/StRS-123
+Übernahmewürdigkeit: Workaround - für Cloud-native Zielarchitektur durch einheitliches Container-Startmodell zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-23
+Titel:         AES-basierte Verschlüsselungslogik als wiederverwendbare Klasse
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `AESCryptoLogic` wird sowohl in `PdfSigningBL` (TSA-Passwort) als auch implizit über `CryptoControl` (ArtificialIntelligence-API-Schlüssel) verwendet.
+Aussage:       Die Verschlüsselung sensibler Konfigurationswerte soll über eine zentrale, wiederverwendbare AES-Verschlüsselungskomponente erfolgen.
+Ergebnis:      Alle verschlüsselt gespeicherten Konfigurationswerte nutzen denselben Algorithmus und dieselbe Schlüsselverwaltung.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs (AESCryptoLogic), src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs (CryptoControl) – Begründung: zwei Verwendungsstellen belegen eine gemeinsame Verschlüsselungsbasis, exakte Beziehung zwischen `AESCryptoLogic` und `CryptoControl` wurde nicht im Detail verifiziert.
+Prüfidee:      Noch zu bestimmen – Vertiefung erforderlich: Klärung, ob `CryptoControl` und `AESCryptoLogic` dieselbe zugrunde liegende Implementierung nutzen.
+Tracelinks:    SyRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beziehung zwischen den Klassen nicht abschließend verifiziert.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-24
+Titel:         Cursor-/Paging-Parameter bei Lieferantenbuchungssuche
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `SupplierAssetBL.GetSupplierBookingByFilter(filter, page, entriesPerPage)` prüft `page <= 0` und `entriesPerPage <= 0` explizit und wirft `ArgumentOutOfRangeException`.
+Aussage:       Paginierte Suchfunktionen sollen ihre Paging-Parameter (Seite, Einträge pro Seite) vor Ausführung der Abfrage explizit validieren.
+Ergebnis:      Ein Aufruf mit ungültiger Seitenzahl/-größe wird sofort mit einer klaren Exception abgelehnt, statt eine fehlerhafte oder leere Abfrage auszuführen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/BusinessPartner/SupplierAssetBL.cs, Methode GetSupplierBookingByFilter, Zeilen 45–46 – Begründung: konkrete, im Code sichtbare Parametervalidierung.
+Prüfidee:      Ein Aufruf mit `page=0` löst eine `ArgumentOutOfRangeException` aus, bevor eine Datenbankabfrage erfolgt.
+Tracelinks:    StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - solide Eingabevalidierung.
+Status:        belegt
+```
+
+```
+ID:            SwRS-25
+Titel:         Wochentagsspezifische Zeitfenster-Felder für erwartete Ereignisse
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ExpectedEvents`-Entität führt für jeden Wochentag (Montag–Freitag) eigene Felder `TimeBetweenX`, `ExecuteXFrom`, `ExecuteXTo`, `ExpectedIncomeX` (20 Felder statt einer normalisierten Wochentagstabelle).
+Aussage:       Die Entität `ExpectedEvents` bildet Wochentags-Zeitfenster über 20 einzelne, wochentagspezifische Felder statt einer normalisierten 1:n-Beziehung zu einer Wochentagstabelle ab.
+Ergebnis:      Eine Änderung der Zeitfensterlogik (z. B. Ergänzung um Samstag/Sonntag) erfordert ein Schema-Update statt einer einfachen Dateneinfügung.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs, Methode SaveExpectedEvent, Zeilen 37–60 (Montag bis Freitag einzeln) – Begründung: vollständig gelesene, sich wiederholende Feldstruktur je Wochentag.
+Prüfidee:      Eine Erweiterung um Samstag/Sonntag würde im aktuellen Modell eine Datenbankmigration erfordern statt einer reinen Dateneinfügung.
+Tracelinks:    StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - denormalisierte Wochentagsfelder sind ein Migrationskandidat für ein normalisiertes Wochentagsmodell im Zielsystem.
+Status:        belegt
+```
+
+```
+ID:            SwRS-26
+Titel:         Enum CentronObjectKindNumeric als generischer Objekttyp-Diskriminator
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `CentronObjectKindNumeric` wird sowohl in `NexusTicketViewBL` (Webaccount/EmployeeClass) als auch in `ObjectExternalReferenceBL.GetReferencesForObject(objectI3D, objectKind)` und `ProcessBL.GetProcess<T>(objectI3D, objectKind)` verwendet.
+Aussage:       Das Enum `CentronObjectKindNumeric` soll systemweit als generischer Diskriminator für „welche Art von Objekt referenziert eine I3D" verwendet werden.
+Ergebnis:      Mindestens drei unabhängige Fachbereiche (Nexus-Ansichten, externe Referenzen, Workflow-Prozesse) nutzen denselben Diskriminator-Typ konsistent.
+Belege:
+  - [PRIMÄR] Nachweis in drei unabhängig gelesenen Klassen: NexusTicketViewBL, ObjectExternalReferenceBL, ProcessBL – Begründung: dreifach unabhängig beobachtete Verwendung desselben Enum-Typs für denselben fachlichen Zweck.
+Prüfidee:      Ein neuer Fachbereich, der objektartübergreifende Referenzen benötigt, kann denselben Enum-Typ ohne Erweiterung der Kernlogik wiederverwenden.
+Tracelinks:    SyRS-15, StRS-47, StRS-51
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - bewährtes, systemweit konsistentes Diskriminator-Muster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-27
+Titel:         Result/Result&lt;T&gt;-Rückgabetyp als einheitliches Fehlerkapselungsmuster
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          Praktisch alle gelesenen BL-Methoden geben `Result` oder `Result<T>` mit `ResultStatus` (Success/Warning/Error) zurück, statt Exceptions für erwartbare Fehlerfälle zu werfen (Ausnahmen: Rechteverletzungen werfen bewusst Exceptions, siehe SyRS-38).
+Aussage:       Fachliche Methoden sollen erwartbare Fehler- und Warnzustände über den `Result`/`Result<T>`-Rückgabetyp kommunizieren, während unautorisierte Zugriffe bewusst als Exception (fail-closed) behandelt werden.
+Ergebnis:      Aufrufer können erwartbare Fehler ohne Exception-Handling behandeln, während Sicherheitsverletzungen nicht versehentlich ignoriert werden können.
+Belege:
+  - [PRIMÄR] durchgängig beobachtet in ≥15 unabhängig gelesenen Methoden (z. B. AppointmentRequestBL, ExternalHelpdeskConfigurationBL, ObjectExternalReferenceBL) – Begründung: konsistentes Muster über viele unabhängige Module.
+Prüfidee:      Eine fachliche Validierungsverletzung (z. B. doppelter Name) liefert `Result.AsError(...)`, keine Exception; eine Rechteverletzung im Finanzbereich liefert eine Exception.
+Tracelinks:    –
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistentes, im Zielsystem als Result-Pattern/Railway-Oriented-Programming fortzuführendes Muster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-28
+Titel:         Konstruktorbasierte Zusammensetzung von BL-Abhängigkeiten
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          Nahezu jede gelesene BL-Klasse instanziiert ihre BL-Abhängigkeiten im eigenen Konstruktor per `new XyzBL(this.Session)` (z. B. `AppointmentRequestBL`, `MailScannerBL`, `PhoneCallBL`), anstatt sie injizieren zu lassen.
+Aussage:       BL-Klassen sollen ihre Hilfsklassen im eigenen Konstruktor über dieselbe `DAOSession` neu instanziieren, um innerhalb einer Session konsistent zu bleiben.
+Ergebnis:      Alle innerhalb einer Anfrage verwendeten BL-Instanzen teilen sich dieselbe Datenbank-Session.
+Belege:
+  - [PRIMÄR] durchgängig beobachtet, u. a. src/backend/Centron.BL/MailScanner/MailScannerBL.cs, src/backend/Centron.BL/Tapi/PhoneCallBL.cs – Begründung: konsistentes Konstruktionsmuster über viele unabhängige Klassen.
+Prüfidee:      Zwei innerhalb derselben Anfrage instanziierte BL-Klassen greifen nachweislich auf dieselbe `DAOSession`-Instanz zu.
+Tracelinks:    –
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - manuelle `new`-Instanziierung statt Dependency-Injection-Container ist im Zielsystem durch einen DI-Container mit Session-Scope zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-29
+Titel:         Konsistente Verwendung von Guard-Hilfsmethoden zur Parametervalidierung
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `Guard.NotNull(...)`, `Guard.NotZero(...)`, `Guard.NotNegativeOrZero(...)`, `Guard.NotLessOrEqualThan(...)` werden in praktisch jeder gelesenen BL-Methode mit Parametern zu Beginn aufgerufen.
+Aussage:       Öffentliche BL-Methoden sollen ihre Parameter zu Methodenbeginn konsistent über die zentrale `Guard`-Klasse validieren.
+Ergebnis:      Ungültige Parameter (null, negative I3Ds) werden früh und einheitlich mit einer nachvollziehbaren Exception abgelehnt.
+Belege:
+  - [PRIMÄR] durchgängig beobachtet in ≥10 unabhängig gelesenen Klassen (z. B. BankAccountBL, AppointmentRequestBL, ChecklistVirtualObjectCategoryBL) – Begründung: konsistentes Validierungsmuster über viele unabhängige Module.
+Prüfidee:      Ein Aufruf einer beliebigen geprüften Methode mit `null` als Pflichtparameter löst eine `ArgumentNullException` (über Guard.NotNull) aus.
+Tracelinks:    –
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistentes Validierungsmuster, im Zielsystem fortzuführen (ggf. durch Sprachfeatures wie C# Nullable Reference Types ergänzt).
+Status:        belegt
+```
+
+---
+
+## Risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz)
+
+```
+ID:            SwRS-30
+Titel:         Dreistufige Datumsprüfung für Kontoaktivstatus
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `AppUserBL.GetActiveAppUsers()`, LINQ-Ausdruck mit drei ODER-verknüpften Fällen: (1) `AccountDisabledFromDate == null && AccountDisabledToDate == null`; (2) `AccountDisabledFromDate != null && (DateTime.Today < FromDate || (ToDate != null && ToDate < DateTime.Today))`; (3) analoger dritter Fall für nur `ToDate` gesetzt.
+Aussage:       Die Methode `GetActiveAppUsers()` soll den Aktivstatus ausschließlich über einen reinen, seiteneffektfreien LINQ-Ausdruck auf Basis des aktuellen Datums berechnen, ohne ein zusätzliches, potenziell veraltendes Zwischenstatus-Feld zu pflegen.
+Ergebnis:      Der Aktivstatus ist zu jedem Abfragezeitpunkt korrekt, unabhängig davon, wann zuletzt ein Wartungsjob lief.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs, Zeilen 38–50 – Begründung: vollständig gelesener, reiner Ausdruck ohne erkennbaren Seiteneffekt oder zwischengespeicherten Status.
+Prüfidee:      Bei künstlich vorgezogener Systemzeit (Testumgebung) ändert sich der von `GetActiveAppUsers()` gelieferte Bestand exakt zum erwarteten Umschaltzeitpunkt, ohne dass ein Batch-Job läuft.
+Tracelinks:    SyRS-30
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zustandsloses, korrektes Berechnungsmuster ist einem zwischengespeicherten Status vorzuziehen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-31
+Titel:         Wiederholte identische Lizenzprüfung als Methoden-Precondition
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `ProductionOrderBL`: identischer Code `if (LicenseManager.Instance.HasLicense(LicenseGuids.ProductionManagement) == false) throw new Exception(LocalizedStrings.ProductionBL_...)` ist an drei Stellen (Zeilen 29–30, 39–40, ~49–50) dupliziert.
+Aussage:       Die Lizenzprüfung für Produktionsaufträge soll aus Wartbarkeitsgründen in eine private Hilfsmethode extrahiert werden, statt an jeder öffentlichen Methode identisch dupliziert zu werden.
+Ergebnis:      Eine künftige Änderung der Lizenzprüfung (z. B. zusätzliche Bedingung) erfordert nur eine Änderungsstelle statt drei.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, Zeilen 29–30, 39–40, 49–50 – Begründung: identischer, dreifach dupliziert beobachteter Code.
+Prüfidee:      Eine Änderung der Lizenzbedingung (z. B. zusätzliche Prüfung auf Ablaufdatum) lässt sich nach Refactoring an einer einzigen Stelle vornehmen und wirkt sich auf alle drei Methoden aus.
+Tracelinks:    SyRS-32
+Konsolidierung: Kandidat: (interne Code-Duplizierung, kein StRS-Pendant) – Begründung: dreifache identische Prüfung ist ein Refactoring-, nicht primär ein Konsolidierungsfall im Sinne der Aufgabenstellung, wird hier dennoch dokumentiert.
+Übernahmewürdigkeit: übernehmen - fachliche Regel bleibt, technische Duplizierung im Zielsystem zu bereinigen.
+Status:        belegt
+```
+
+```
+ID:            SwRS-32
+Titel:         Zentrale Entschlüsselungsstelle unmittelbar vor externem HTTP-Aufruf
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `OpenAiApiClient`, Zeile ~34 (`ApiKeyCredential`-Erzeugung) und Zeile ~103 (`AuthenticationHeaderValue("Bearer", apiKey)`) – jeweils unmittelbar vorher `CryptoControl.DecryptString(_settings.ApiKey)`, der entschlüsselte Wert wird nicht in einem Feld zwischengespeichert, sondern lokal in der jeweiligen Methode verwendet.
+Aussage:       Der entschlüsselte API-Schlüssel soll ausschließlich als lokale Variable unmittelbar vor dem HTTP-Aufruf existieren, nicht als Instanzfeld zwischengespeichert werden, um die Zeitspanne des Klartext-Vorhandenseins im Speicher zu minimieren.
+Ergebnis:      Der Klartext-API-Schlüssel existiert nur für die Dauer des unmittelbaren Aufrufs im Speicher.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs, zwei unabhängige Aufrufstellen (Zeile ~34 und ~103), jeweils lokale Variable `key`/`apiKey` – Begründung: an zwei unabhängigen Stellen dasselbe Muster (lokale statt Instanzvariable) beobachtet.
+Prüfidee:      Ein Speicher-Dump der `OpenAiApiClient`-Instanz zwischen zwei Aufrufen enthält keinen entschlüsselten API-Schlüssel als Instanzfeld.
+Tracelinks:    SyRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - sicherheitsbewusstes Muster (Minimierung der Klartext-Lebensdauer im Speicher).
+Status:        belegt
+```
+
+```
+ID:            SwRS-33
+Titel:         Filter-basierte Autorisierungskomponente mit klar getrennten 401/403-Pfaden
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `UserRightAuthorizationFilter.OnAuthorization`: `if (currentUser == null) { context.Result = new UnauthorizedResult(); return; }` gefolgt von `if (!_requiredRightId.HasValue || !currentUser.HasUserRight(_requiredRightId.Value)) context.Result = new ForbidResult();`.
+Aussage:       Die Autorisierungskomponente `UserRightAuthorizationFilter` soll fehlende Authentifizierung (401) strikt von fehlender Autorisierung (403) unterscheiden, gemäß dem HTTP-Standard.
+Ergebnis:      Ein Client kann anhand des Statuscodes unterscheiden, ob er sich anmelden muss (401) oder mit seinem aktuellen Konto keinen Zugriff hat (403).
+Belege:
+  - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, Methode OnAuthorization, Zeilen 43–51 – Begründung: vollständig gelesene, klar getrennte Fallunterscheidung.
+Prüfidee:      Ein nicht angemeldeter Request liefert exakt 401; ein angemeldeter Request ohne Recht liefert exakt 403.
+Tracelinks:    SyRS-33
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - HTTP-standardkonformes, klar unterscheidbares Verhalten.
+Status:        belegt
+```
+
+```
+ID:            SwRS-34
+Titel:         Sequenzielle Kombination von Passwort- und TOTP-Prüfung mit Kurzschlussverhalten
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `BasicAuthenticator.AuthenticateInternal`: `ValidateAppUser(user)` liefert bei Fehlschlag sofortigen Rückgabewert (Zeile 52–57, vor der 2FA-Prüfung), erst danach folgt `_twoFactorAuthBL.ValidateTwoFactor(...)` (Zeile 62).
+Aussage:       Die Passwortprüfung soll der Zwei-Faktor-Prüfung strikt vorgeschaltet sein (Kurzschlussauswertung); bei fehlgeschlagenem Passwort soll die 2FA-Prüfung gar nicht erst ausgeführt werden.
+Ergebnis:      Ein Angreifer ohne korrektes Passwort erhält keine Information darüber, ob 2FA aktiviert ist oder wie eine 2FA-Antwort ausfallen müsste (kein Oracle für 2FA-Status vor Passwortnachweis).
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeilen 52–65 – Begründung: konkrete, im Code sichtbare Reihenfolge mit frühzeitigem Return bei Passwortfehlschlag.
+Prüfidee:      Ein Anmeldeversuch mit falschem Passwort liefert dieselbe generische Fehlerantwort unabhängig davon, ob 2FA für den Benutzer aktiviert ist.
+Tracelinks:    SyRS-35
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - korrekte Kurzschlussreihenfolge verhindert Informationslecks über den 2FA-Status.
+Status:        belegt
+```
+
+```
+ID:            SwRS-35
+Titel:         SHA1Decoder als zentrale, aber kryptographisch veraltete Hash-Komponente
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `SHA1Decoder.GetDecodedSHA1String(...)` wird identisch in `BasicAuthenticator.cs` (Login) und `UsersBL.cs` (Passwortänderung/-prüfung, drei Aufrufstellen) verwendet – eine zentrale, aber veraltete Komponente statt verstreuter Einzelimplementierungen.
+Aussage:       Die Komponente `SHA1Decoder` soll im Zielsystem durch eine Komponente mit gesalzenem, adaptivem Hash-Algorithmus (Argon2id/bcrypt/PBKDF2) ersetzt werden; da der Aufruf bereits heute zentral über eine Komponente erfolgt, ist ein Austausch an einer Stelle technisch mit überschaubarem Aufwand möglich.
+Ergebnis:      Nach Austausch verwenden alle vier heutigen Aufrufstellen automatisch den neuen, sicheren Algorithmus.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 46; src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Zeilen 65, 88, 107 – Begründung: vollständiger Nachweis aller vier Aufrufstellen derselben Komponente.
+Prüfidee:      Nach Austausch der `SHA1Decoder`-Implementierung gegen ein Argon2id-basiertes Verfahren funktionieren Login und Passwortänderung unverändert aus Anwendersicht, verwenden intern jedoch den neuen Algorithmus.
+Tracelinks:    SyRS-36
+Konsolidierung: Kandidat: SwRS-35 vs. Core/CryptoUtils (StRS-96) – Begründung: zwei parallele Hash-Komponenten (`SHA1Decoder`, tatsächlich verwendet; `CryptoUtils`, offenbar ungenutzt) sind im Zielsystem zu einer einzigen zu konsolidieren.
+Übernahmewürdigkeit: veraltet - die konkrete SHA1-Implementierung ist zu ersetzen; die zentrale Architektur (eine Komponente für alle Aufrufstellen) ist hingegen ein Vorteil für die Migration und beizubehalten.
+Status:        belegt
+```
+
+```
+ID:            SwRS-36
+Titel:         AssetLockBL&lt;T&gt; als generische Sperrkomponente für Beleg-Locks
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `AssetLockBL<InvoiceLock>` wird generisch mit dem konkreten Lock-Entitätstyp `InvoiceLock` parametrisiert; `TryLockReceipt`/`UnLockReceipt` delegieren an diese generische Komponente mit Rechte-Parameter `UNLOCK_CUSTOMER_ATTACHMENTS`.
+Aussage:       Die Sperrlogik für Belege soll generisch über `AssetLockBL<T>` implementiert sein, sodass sich weitere Belegarten (nicht nur Rechnungen) mit demselben Mechanismus sperren lassen, indem ein eigener Lock-Entitätstyp definiert wird.
+Ergebnis:      Eine neue Belegart kann Sperrfunktionalität durch Definition eines eigenen `XyzLock`-Typs und Instanziierung von `AssetLockBL<XyzLock>` erhalten, ohne die Kernsperrlogik zu duplizieren.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeile 202, `new AssetLockBL<InvoiceLock>(this._session)` – Begründung: konkrete generische Instanziierung im Code.
+Prüfidee:      Ein neuer Lock-Typ `OfferLock`, instanziiert über `AssetLockBL<OfferLock>`, sperrt Angebote nach demselben Muster wie Rechnungen.
+Tracelinks:    SyRS-37
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - generisches, wiederverwendbares Sperrmuster.
+Status:        belegt
+```
+
+```
+ID:            SwRS-37
+Titel:         Identische Rechteprüfmethode ThrowIfUserHasInsufficentRights in zwei Klassen
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `OposBL.ThrowIfUserHasInsufficentRights` (vollständig gelesen, Zeilen 28–36) prüft `UserRightsConst.Controlling.Finances.Dunning` über `AppRightsBL.CheckRightsFromUser`; `DunningBL.GetDunningCustomers` (Zeile 62) ruft eine strukturell identisch benannte Methode `this.ThrowIfUserHasInsufficentRights(loggedInUser)` auf.
+Aussage:       Beide Klassen (`OposBL`, `DunningBL`) sollen dieselbe Rechteprüfmethode namentlich konsistent implementieren bzw. auf eine gemeinsame Basisklasse/Hilfsmethode zurückgreifen, um Drift zwischen den beiden Prüfstellen zu vermeiden.
+Ergebnis:      Eine künftige Änderung des benötigten Rechts wirkt sich konsistent auf beide Klassen aus, sofern eine gemeinsame Implementierung genutzt wird.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Zeilen 28–36; src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeile 62 – Begründung: identischer Methodenname an zwei Stellen, tatsächliche Code-Identität (gemeinsame Basisklasse vs. Kopie) wurde nicht abschließend verifiziert.
+Prüfidee:      Noch zu bestimmen – Vertiefung erforderlich: Prüfen, ob `DunningBL.ThrowIfUserHasInsufficentRights` tatsächlich dieselbe Implementierung wie `OposBL` nutzt (z. B. über gemeinsame Basisklasse) oder eine unabhängige Kopie ist.
+Tracelinks:    SyRS-38
+Konsolidierung: Kandidat: OposBL/DunningBL – Begründung: identischer Methodenname und identisches Recht an zwei Stellen sind ein Konsolidierungskandidat für eine gemeinsame Basisklasse im Zielsystem.
+Übernahmewürdigkeit: übernehmen - Einschätzung zur Code-Duplizierung vorläufig, da nicht abschließend verifiziert.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-38
+Titel:         Verschlüsselte Speicherung des TSA-Server-Passworts mit bedingter Entschlüsselung
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        –
+Vorbedingung:  –
+Fakt:          `PdfSigningBL.GetPdfSigningSettings`: `if (!String.IsNullOrWhiteSpace(pdfSigningSetting.TsaServerPassword)) { pdfSigningSetting.TsaServerPassword = _cryptoLogic.DecryptText(pdfSigningSetting.TsaServerPassword); }`.
+Aussage:       Das TSA-Server-Passwort soll nur entschlüsselt werden, wenn tatsächlich ein Wert hinterlegt ist, um unnötige Entschlüsselungsoperationen und Fehler bei leerem Wert zu vermeiden.
+Ergebnis:      Bei nicht konfiguriertem TSA-Passwort wird kein Entschlüsselungsversuch unternommen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs, Methode GetPdfSigningSettings, Zeilen 44–47 – Begründung: konkrete, bedingte Entschlüsselungslogik im Code.
+Prüfidee:      Ein Aufruf von `GetPdfSigningSettings` ohne konfiguriertes TSA-Passwort löst keine Entschlüsselungsoperation und keinen Fehler aus.
+Tracelinks:    SyRS-39
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - robuste, defensive Implementierung.
+Status:        belegt
+```
+
+---
+
+**Gesamtzahl SwRS in diesem Dokument: 38** (SwRS-1 bis SwRS-38, lückenlos).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/SyRS.md

@@ -0,0 +1,794 @@
+# System Requirements Specification (SyRS)
+
+Iteration 02 · c-entron ERP-Suite. Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen, abgeleitet aus StRS. SyRS-1 bis SyRS-29 vertiefen ausgewählte Breitenmodule auf Systemebene; SyRS-30 bis SyRS-39 sind die risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz).
+
+---
+
+```
+ID:            SyRS-1
+Titel:         Mandantentrennung auf Datenbankebene
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Mehrere Mandanten sind konfiguriert.
+Fakt:          `MandatorBL.cs`, `BranchBL.cs` unter `src/backend/Centron.BL/Administration/Company`; zahlreiche gelesene Entitäten führen ein `BranchI3D`-Feld (z. B. `AppGroup.BranchI3D` in `AppRightsBL.GetAllRightGroups`).
+Aussage:       Das System soll Daten mandanten-/filialbezogen kennzeichnen, sodass Auswertungen und Rechte auf einen Mandanten/eine Filiale eingeschränkt werden können.
+Ergebnis:      Ein filialbeschränkter Benutzer sieht ausschließlich Daten seiner eigenen Filiale.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode GetAllRightGroups, Filter `f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0)` – Begründung: konkrete, im Code durchgesetzte Filialeinschränkung.
+Prüfidee:      Ein Benutzer mit „MANAGE_RIGHTS_ONLY_OWN_BRANCH" sieht bei Gruppenabfrage nur Gruppen seiner eigenen Filiale.
+Tracelinks:    StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Grundlage für Mandantenfähigkeit im SaaS-Zielsystem.
+Status:        belegt
+```
+
+```
+ID:            SyRS-2
+Titel:         Einheitliches Datenzugriffsmuster über generische DAO-Schicht
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `GenericDAO.cs`, `DAOFactory.cs`, `DAOSession.cs` (`src/backend/Centron.DAO`); Aufrufmuster `Session.GetGenericDAO<T>()` in praktisch jeder gelesenen BL-Klasse.
+Aussage:       Das System soll für Standard-CRUD-Operationen konsequent eine generische, typsichere DAO-Schicht verwenden statt modulspezifischer SQL-Duplizierung.
+Ergebnis:      Neue Entitäten erhalten Standard-CRUD-Fähigkeiten ohne zusätzlichen Implementierungsaufwand.
+Belege:
+  - [PRIMÄR] src/backend/Centron.DAO/GenericDAO.cs, Verwendungsnachweis in ≥15 unabhängig gelesenen BL-Klassen – Begründung: durchgängig beobachtetes Muster über viele unabhängige Module hinweg.
+Prüfidee:      Eine neue, von `PersistedEntity` erbende Entität ist ohne Zusatzcode über `Session.GetGenericDAO<T>()` lesbar/schreibbar.
+Tracelinks:    StRS-83, StRS-84
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Repository-Muster im Zielsystem fortzuführen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-3
+Titel:         Mehrformat-EDI-Bestellübermittlung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System, Lieferant
+Vorbedingung:  Bestellung ist freigegeben.
+Fakt:          `EDIDispatcherBL` instanziiert je Lieferant eine spezifische Order-BL (`Opentrans21OrderBL` u. a.) auf Basis von Lieferantenkennung.
+Aussage:       Das System soll beim Versand einer Bestellung automatisch das für den Ziellieferanten passende EDI-Format auswählen.
+Ergebnis:      Eine Bestellung an Lieferant X wird nachweislich im für X korrekten Format übertragen.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs – Begründung: Dispatcher-Muster mit lieferantenspezifischer Instanziierung.
+Prüfidee:      Bestellungen an zwei unterschiedliche Lieferanten erzeugen zwei strukturell unterschiedliche EDI-Nachrichten.
+Tracelinks:    StRS-23
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - notwendig für Distributorenanbindung.
+Status:        belegt
+```
+
+```
+ID:            SyRS-4
+Titel:         Einheitliches DTO-Mapping für Web-/Mobile-Clients
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Web-/Mobile-Client
+Vorbedingung:  –
+Fakt:          `src/backend/Centron.BL/WebServices` (72 Unterordner) mappt Kern-Entitäten auf `CentronSoftware.Centron.WebServices.Entities.*`-DTOs.
+Aussage:       Das System soll interne Entitäten nicht direkt, sondern über explizite DTOs an Web-/Mobile-Clients ausliefern.
+Ergebnis:      Änderungen am internen Entitätsmodell wirken sich nicht unmittelbar auf die öffentliche API-Struktur aus.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/WebServices (Verzeichnisstruktur), z. B. DunningConfiguration.cs unter WebServices/ObjectMapperConfiguration – Begründung: dedizierte Mapper-Konfigurationsklassen belegen bewusste DTO-Trennung.
+Prüfidee:      Ein internes Entitätsfeld ohne DTO-Mapping ist über die API nicht sichtbar.
+Tracelinks:    StRS-61
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - API-Stabilität ist für SaaS-Zielsystem essenziell.
+Status:        belegt
+```
+
+```
+ID:            SyRS-5
+Titel:         Echtzeit-Benachrichtigung über SignalR-artigen Hub
+Ebene:         SyRS
+Typ:           Performance
+Qualitätsmerkmal: Zeitverhalten
+Akteur:        Nexus-Nutzer
+Vorbedingung:  Nutzer ist mit Nexus verbunden.
+Fakt:          `NotificationsHubHelper.cs` (`src/backend/Centron.BL/NexusNotifications`), `RealTimeServices` (`src/webservice/Centron.Host`).
+Aussage:       Das System soll Benachrichtigungen an verbundene Nexus-Clients ohne Polling in Echtzeit über einen Push-Kanal zustellen.
+Ergebnis:      Eine serverseitige Änderung erreicht verbundene Clients innerhalb weniger Sekunden ohne aktives Nachfragen.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/NexusNotifications/NotificationsHubHelper.cs, src/webservice/Centron.Host/RealTimeServices – Begründung: „Hub"/„RealTimeServices"-Namensgebung an zwei unabhängigen Stellen belegt konsistent eine Push-Architektur.
+Prüfidee:      Ein neues Ticket löst innerhalb von 5 Sekunden eine sichtbare Benachrichtigung im verbundenen Nexus-Client aus.
+Tracelinks:    StRS-44
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Echtzeitfähigkeit ist Nutzererwartung an moderne Web-Anwendungen.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-6
+Titel:         Volltextindex mit inkrementeller und Vollaktualisierung
+Ebene:         SyRS
+Typ:           Performance
+Qualitätsmerkmal: Zeitverhalten
+Akteur:        System (Hintergrunddienst)
+Vorbedingung:  –
+Fakt:          `IndexSearchBL.UpdateAllIndexes(token)` vs. `UpdateRequestedIndexes(token)` mit `CancellationToken`-Unterstützung.
+Aussage:       Das System soll den Suchindex sowohl vollständig als auch inkrementell (nur angeforderte Objekte) aktualisieren können, wobei die Aktualisierung abbrechbar ist.
+Ergebnis:      Eine inkrementelle Aktualisierung benötigt deutlich weniger Zeit als eine Vollaktualisierung und ist jederzeit abbrechbar.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs, Methoden UpdateAllIndexes/UpdateRequestedIndexes, Parameter CancellationToken – Begründung: konkrete, im Code umgesetzte Unterscheidung zweier Aktualisierungsmodi mit Abbruchunterstützung.
+Prüfidee:      Ein Abbruch über das CancellationToken während einer Vollaktualisierung stoppt den Index-Build nachweislich vorzeitig.
+Tracelinks:    StRS-32
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Performance-kritisch bei großen Datenbeständen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-7
+Titel:         Blacklist-Prüfung vor E-Mail-Versand
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Eine E-Mail soll versendet werden.
+Fakt:          `src/backend/Centron.BL/Mail/Blacklist` (Unterordner, eigenständiger Baustein neben `MailFormatting`/`Templates`).
+Aussage:       Das System soll vor jedem automatisierten E-Mail-Versand eine Blacklist-Prüfung des Empfängers durchführen.
+Ergebnis:      Eine Adresse auf der Blacklist erhält keine automatisierten E-Mails, unabhängig vom auslösenden Fachprozess.
+Belege:
+  - [KONTEXT] src/backend/Centron.BL/Mail/Blacklist (Verzeichnisname) – Begründung: dedizierter Baustein belegt Existenz einer Blacklist-Prüfung; konkrete Verankerung im Versandpfad nicht gelesen.
+Prüfidee:      Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich (Prüfung, ob wirklich jeder Versandpfad die Blacklist konsultiert).
+Tracelinks:    StRS-36
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-8
+Titel:         Lizenzprüfung als systemweiter Cross-Cutting-Concern
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `LicenseManager.Instance.HasLicense(LicenseGuids.X)` wird konsistent in `ProductionOrderBL` (drei Methoden) sowie separat in `AppUserBL`/`UsersBL` (Konstruktorabhängigkeit `ILicenseManager`) verwendet.
+Aussage:       Das System soll Lizenzprüfungen einheitlich über eine zentrale `LicenseManager`-Komponente durchführen, die von mehreren, unabhängigen Fachmodulen genutzt wird.
+Ergebnis:      Jede lizenzpflichtige Funktion prüft konsistent gegen dieselbe zentrale Lizenzquelle.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs (3 Prüfstellen), src/backend/Centron.BL/EmployeeArea/AppUserBL.cs (Konstruktorinjektion ILicenseManager) – Begründung: identisches Muster an mindestens zwei unabhängigen Fachbereichen belegt systemweite Konsistenz.
+Prüfidee:      Ein Entzug der Produktionsmanagement-Lizenz sperrt sofort alle drei geprüften ProductionOrderBL-Methoden.
+Tracelinks:    StRS-53
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Lizenzmodell ist Grundlage kommerzieller SaaS-Tarifierung.
+Status:        belegt
+```
+
+```
+ID:            SyRS-9
+Titel:         Mehrsprachige Produktdatenanreicherung über zwei parallele Anbieter
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Artikel besitzt Herstellerreferenz.
+Fakt:          `Centron.APIs.ITscopeDataAccess` und `Centron.APIs.IcecatDataAccess` sind zwei unabhängige, strukturell gleichartige API-Clients für denselben fachlichen Zweck (Produktdatenanreicherung); `Languages.cs` in Icecat belegt Mehrsprachigkeit.
+Aussage:       Das System soll Produktdaten wahlweise über ITscope oder Icecat anreichern, wobei beide Anbindungen unabhängig konfigurierbar sind.
+Ergebnis:      Ein Artikel kann je nach Konfiguration über den einen oder anderen Anbieter angereichert werden.
+Belege:
+  - [SEKUNDÄR] src/apis/Centron.APIs.ITscopeDataAccess, src/apis/Centron.APIs.IcecatDataAccess (Strukturvergleich) – Begründung: strukturelle Parallelität zweier unabhängiger API-Projekte für denselben Zweck.
+Prüfidee:      Ein Artikel mit sowohl ITscope- als auch Icecat-Referenz lässt sich wahlweise über beide Quellen anreichern.
+Tracelinks:    StRS-67, StRS-68
+Konsolidierung: Kandidat: StRS-67, StRS-68 – Begründung: siehe dortige Konsolidierungsvermerke.
+Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer einheitlichen Produktdaten-Fassade zu konsolidieren.
+Status:        belegt
+```
+
+```
+ID:            SyRS-10
+Titel:         Multi-Carrier-Versandlabel-Erzeugung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Lieferschein ist versandbereit.
+Fakt:          `Centron.Api.Gls` und `Centron.Api.Shipcloud` sind zwei strukturell parallele Versand-API-Projekte (`CentronXxxLogic.cs`, `CentronXxxConsts.cs`, `CentronXxxErrors.cs`).
+Aussage:       Das System soll Versandlabels wahlweise über GLS direkt oder über den Multi-Carrier-Dienst Shipcloud erzeugen können.
+Ergebnis:      Ein Lieferschein kann je nach konfiguriertem Carrier ein gültiges Label erzeugen.
+Belege:
+  - [SEKUNDÄR] src/apis/Centron.Api.Gls, src/apis/Centron.Api.Shipcloud (Strukturvergleich identischer Klassenmuster) – Begründung: identisches Namensschema belegt bewusst parallele, austauschbare Implementierung.
+Prüfidee:      Ein Testversand erzeugt sowohl über GLS als auch über Shipcloud jeweils ein gültiges, scanbares Label.
+Tracelinks:    StRS-70, StRS-71
+Konsolidierung: Kandidat: StRS-70, StRS-71
+Übernahmewürdigkeit: übernehmen - im Zielsystem hinter einer einheitlichen Versand-Fassade zu konsolidieren.
+Status:        belegt
+```
+
+```
+ID:            SyRS-11
+Titel:         Report-Ausgabe über mehrere Kanäle
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Report wird ausgeführt.
+Fakt:          `ReportsBL.ReportDefaultValues`-Enum (Email = 1, PDF = 2, Print = 4) – Bitmasken-Werte deuten auf kombinierbare Ausgabewege hin.
+Aussage:       Das System soll einen Report gleichzeitig über mehrere Ausgabewege (E-Mail, PDF-Ablage, Druck) ausgeben können.
+Ergebnis:      Ein Report mit kombiniertem Standardwert (z. B. Email+PDF) wird über beide Kanäle gleichzeitig ausgegeben.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Reporting/ReportsBL.cs, Enum ReportDefaultValues mit Zweierpotenz-Werten (1, 2, 4) – Begründung: Zweierpotenzwerte sind ein im Code erkennbares Bitmasken-Muster für kombinierbare Optionen.
+Prüfidee:      Ein Report mit dem kombinierten Wert 3 (Email+PDF) erzeugt sowohl eine E-Mail als auch eine abgelegte PDF-Datei.
+Tracelinks:    StRS-56, StRS-57
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - flexible Ausgabesteuerung ist im Tagesgeschäft nützlich.
+Status:        belegt
+```
+
+```
+ID:            SyRS-12
+Titel:         Steuersatzkette über verkettete Nachfolgesätze
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Steuersatzwechsel ist konfiguriert.
+Fakt:          `TaxBL.GetActiveVatThroughNextVats(vatI3D, compareTo)` durchläuft `vat.NextTaxRate`, solange das Ablaufdatum vor dem Vergleichsdatum liegt.
+Aussage:       Das System soll historische und zukünftige Steuersätze als verkettete Liste (`NextTaxRate`) modellieren, sodass zu jedem Stichtag der korrekte Satz ermittelbar ist.
+Ergebnis:      Auch bei mehreren aufeinanderfolgenden Steuersatzwechseln liefert eine Stichtagsabfrage den korrekten Satz.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Warehousing/TaxBL.cs, Methode GetActiveVatThroughNextVats, Schleife über NextTaxRate – Begründung: konkrete, im Code umgesetzte Verkettungslogik.
+Prüfidee:      Bei drei aufeinanderfolgenden Steuersatzwechseln liefert eine Abfrage für einen Stichtag zwischen dem zweiten und dritten Wechsel den zweiten Satz.
+Tracelinks:    StRS-59
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich erforderliche Korrektheit über Zeit.
+Status:        belegt
+```
+
+```
+ID:            SyRS-13
+Titel:         Konfigurierbare Standard-Ausgabewege je Beleg (Textbausteine)
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `TextModuleBL` cached sechs belegartspezifische Textbaustein-Paare (Anrede/Abschluss).
+Aussage:       Das System soll beim Rendern eines Belegs automatisch die zur Belegart passenden Textbausteine ohne manuelle Auswahl durch den Benutzer einsetzen.
+Ergebnis:      Der Benutzer muss die Anrede/Grußformel nicht manuell auswählen; das System wählt sie belegartabhängig automatisch.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs, sechs Cache-Felder – Begründung: Cache-Struktur belegt automatische, belegartabhängige Vorbelegung.
+Prüfidee:      Beim Erzeugen einer Rechnung wird automatisch die Rechnungs-Anrede eingesetzt, nicht die Angebots-Anrede.
+Tracelinks:    StRS-111
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - reduziert manuellen Aufwand und Fehlerquote.
+Status:        belegt
+```
+
+```
+ID:            SyRS-14
+Titel:         Automatische Registrierung neuer Anwendungsmodule beim Start
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Anwendung wird gestartet.
+Fakt:          `ModuleBL.DoCreateMissingInternalModulesInDB` vergleicht Code-Modulliste (`ModuleGuid`) mit DB-Bestand und legt fehlende Module an.
+Aussage:       Das System soll beim Anwendungsstart automatisch prüfen, welche im Code definierten Module in der Datenbank noch fehlen, und diese anlegen.
+Ergebnis:      Nach einem Update mit neuen Modulen ist kein manueller Datenbankschritt notwendig.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Modules/ModuleBL.cs, Methode DoCreateMissingInternalModulesInDB – Begründung: konkreter, im Code durchgesetzter Abgleichsalgorithmus.
+Prüfidee:      Nach Hinzufügen eines neuen Moduls mit neuer GUID im Code erscheint dieses nach dem ersten Start automatisch in der Modultabelle.
+Tracelinks:    StRS-41
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - reduziert Update-Aufwand.
+Status:        belegt
+```
+
+```
+ID:            SyRS-15
+Titel:         Eindeutige Objekt-Identifikation bei überlappenden I3D-Bereichen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Nutzer ist entweder Mitarbeiter oder Web-Account.
+Fakt:          `NexusTicketViewBL.GetUserI3D`/`GetCreatedByObjectKind` unterscheiden explizit `IsWebAccountLogin`, da Mitarbeiter- und Web-Account-I3Ds denselben Nummernraum teilen können.
+Aussage:       Das System soll bei der Identifikation eines Nutzers stets die Kombination aus I3D und Objektart (Mitarbeiter/Web-Account) verwenden, um Verwechslungen bei überlappenden I3D-Bereichen zu vermeiden.
+Ergebnis:      Ein Mitarbeiter und ein Web-Account mit identischer I3D werden nie miteinander verwechselt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs, Methoden GetUserI3D/GetCreatedByObjectKind – Begründung: im Code umgesetzte, explizit dokumentierte Unterscheidung (siehe XML-Doc-Kommentar im Quelltext).
+Prüfidee:      Ticketansichten von Mitarbeiter I3D=5 und Web-Account I3D=5 werden getrennt gespeichert und angezeigt.
+Tracelinks:    StRS-45
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - grundlegendes Korrektheitsmuster, im Zielsystem beizubehalten (z. B. über zusammengesetzten Schlüssel).
+Status:        belegt
+```
+
+```
+ID:            SyRS-16
+Titel:         Konfigurierbare Sichtbarkeit von Helpdesk-Zeitfeldern
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `CalendarBL.GetCalendarRepresentationSettings` liest zehn unabhängige Boolean-Konfigurationsschalter.
+Aussage:       Das System soll die Sichtbarkeit von zehn unterschiedlichen Informationsfeldern einer Helpdesk-Zeitbuchung unabhängig voneinander konfigurierbar machen.
+Ergebnis:      Jeder der zehn Schalter kann unabhängig von den übrigen aktiviert/deaktiviert werden.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Calendar/CalendarBL.cs, zehn AppSettingsConst.HelpdeskTimeDisplay*-Schalter – Begründung: konkrete Konfigurationsschalter belegen granulare Steuerung.
+Prüfidee:      Deaktivieren eines einzelnen Schalters (z. B. RMA-Anzeige) ändert nicht das Verhalten der übrigen neun Schalter.
+Tracelinks:    StRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Konfigurierbarkeit wird von Kunden genutzt.
+Status:        belegt
+```
+
+```
+ID:            SyRS-17
+Titel:         Aktivstatusfilterung für mobile Mitarbeiterdaten
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Mobile Anwendung
+Vorbedingung:  –
+Fakt:          `MobileBL.GetMobileEmployee()` filtert `NewMobileEmployee` nach `State == 1`.
+Aussage:       Das System soll der mobilen Anwendung ausschließlich aktive Mitarbeiterdatensätze bereitstellen.
+Ergebnis:      Ein deaktivierter Mitarbeiter erscheint nicht in der mobilen Mitarbeiterliste.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, Filter State == 1 – Begründung: konkrete, im Code durchgesetzte Filterbedingung.
+Prüfidee:      Ein auf inaktiv gesetzter Mitarbeiter verschwindet aus der Antwort von GetMobileEmployee().
+Tracelinks:    StRS-40
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - magischer Zahlenwert „State == 1" ohne erkennbares Enum ist im Zielsystem zu klären/zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-18
+Titel:         Abbrechbare, deadlocksichere Telemetrie-Aggregation
+Ebene:         SyRS
+Typ:           Performance
+Qualitätsmerkmal: Zeitverhalten
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `TelemetryBL.UpsertMcpToolUsageBatch` verwendet `MERGE ... WITH (HOLDLOCK)` mit Deadlock-Retry-Kommentar.
+Aussage:       Das System soll Telemetrie-Batch-Updates unter hoher Parallelität ohne doppelte Zählung und mit automatischem Deadlock-Retry verarbeiten.
+Ergebnis:      Ein Deadlock bei paralleler Aktualisierung führt zu einem automatischen Retry statt zu einem sichtbaren Fehler.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Telemetry/TelemetryBL.cs, Methode UpsertMcpToolUsageBatch, Kommentar zu SQL-Fehlercode 1205 (Deadlock) und Retry – Begründung: konkrete, im Code dokumentierte Retry-Strategie für einen benannten SQL-Fehlercode.
+Prüfidee:      Ein simulierter Deadlock (Fehlercode 1205) während des Merge führt zu einem erfolgreichen Retry statt einem Fehlschlag.
+Tracelinks:    StRS-110
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - technisch robuste Umsetzung.
+Status:        belegt
+```
+
+```
+ID:            SyRS-19
+Titel:         DSGVO-Löschprotokollierung mit Bearbeiterzuordnung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        System
+Vorbedingung:  DSGVO-Löschanfrage wird bearbeitet.
+Fakt:          `DataSecurityBL`, Konstante `DsgvoDeletedContactMessageWithEmployeeInfo = "DSGVO: Auf Anfrage gelöscht. (Durchgeführt von {0} am {1:d} um {1:t} Uhr)"`.
+Aussage:       Das System soll bei DSGVO-bedingter Löschung eines Kontakts den ausführenden Mitarbeiter und den Zeitpunkt der Löschung nachvollziehbar im verbleibenden Datensatz vermerken.
+Ergebnis:      Ein gelöschter Kontakt trägt einen Vermerk mit Bearbeiter und Zeitstempel statt vollständig zu verschwinden.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs, Konstante DsgvoDeletedContactMessageWithEmployeeInfo – Begründung: konkreter, im Code hinterlegter Nachrichtentext mit Platzhaltern für Bearbeiter/Zeitpunkt.
+Prüfidee:      Eine DSGVO-Löschung durch Mitarbeiter „M. Muster" am 26.08.2026 hinterlässt exakt diesen Namen und dieses Datum im Vermerk.
+Tracelinks:    StRS-128
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nachvollziehbarkeit ist DSGVO-Grundprinzip (Rechenschaftspflicht).
+Status:        belegt
+```
+
+```
+ID:            SyRS-20
+Titel:         Umgebungsspezifische Konfiguration der Nexus-Anwendung
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:        Betrieb/IT
+Vorbedingung:  –
+Fakt:          `CentronNexus.Host/appsettings.json` vs. `appsettings.Development.json`.
+Aussage:       Das System soll für die Nexus-Anwendung umgebungsspezifische Konfigurationsdateien unterstützen, die sich ohne Codeänderung austauschen lassen.
+Ergebnis:      Ein Wechsel der ASP.NET-Core-Umgebungsvariable lädt automatisch die passende Konfiguration.
+Belege:
+  - [SEKUNDÄR] src/nexus/CentronNexus.Host/appsettings.Development.json, appsettings.json – Begründung: getrennte Dateien belegen Standard-ASP.NET-Core-Konfigurationsmechanismus.
+Prüfidee:      Start mit `ASPNETCORE_ENVIRONMENT=Development` lädt nachweislich abweichende Werte aus der Development-Datei.
+Tracelinks:    StRS-77
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardmuster, im Zielsystem fortzuführen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-21
+Titel:         Containerbasierte Referenzumgebung für Tests
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Testbarkeit / Übertragbarkeit
+Akteur:        Entwickler, CI-System
+Vorbedingung:  –
+Fakt:          `docker/c-entron-regression-tests-db`, `docker/c-entron-regression-tests-pipeline`, `docker/c-entron-mailcatcher`.
+Aussage:       Das System soll für Regressionstests eine containerisierte Referenzdatenbank sowie einen Mailcatcher zum Abfangen von Test-E-Mails bereitstellen.
+Ergebnis:      Regressionstests laufen reproduzierbar gegen eine isolierte, containerisierte Umgebung ohne echten Mailversand.
+Belege:
+  - [SEKUNDÄR] docker/c-entron-regression-tests-db, docker/c-entron-mailcatcher (Verzeichnisnamen) – Begründung: dedizierte Testinfrastruktur-Container belegen etablierte automatisierte Testpraxis.
+Prüfidee:      Eine während eines Regressionstests versendete E-Mail landet nachweislich im Mailcatcher, nicht bei einem echten Empfänger.
+Tracelinks:    StRS-92
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - wichtige Grundlage für sichere, automatisierte Testläufe.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-22
+Titel:         Rekursive Kategoriehierarchie mit Zyklusrisiko
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `ChecklistVirtualObjectCategoryBL.GetChecklistVirtualObjectCategoriesByFilter` lädt Elternkategorien iterativ über eine `while`-Schleife auf Basis von `ParentI3D`, ohne erkennbare Zyklus-/Tiefenbegrenzung im gelesenen Ausschnitt.
+Aussage:       Das System soll beim rekursiven Laden von Kategoriehierarchien auch bei tiefen oder fehlerhaft zyklischen Strukturen determiniert terminieren.
+Ergebnis:      Das Laden einer Kategoriehierarchie terminiert auch im Fehlerfall (zyklische Elternreferenz) in endlicher Zeit.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs, `while(recentlyAddedI3Ds.Count > 0)`-Schleife ohne erkennbare Zyklusprüfung – Begründung: im gelesenen Code ist keine Zyklus- oder Tiefenbegrenzung erkennbar, was bei einer versehentlichen Selbstreferenz zu einer Endlosschleife führen könnte.
+Prüfidee:      Eine Kategorie, deren `ParentI3D` (versehentlich) auf sich selbst oder einen ihrer Nachfahren verweist, führt nicht zu einer Endlosschleife.
+Tracelinks:    StRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Funktionalität selbst übernehmenswert, Zyklusschutz ist im Zielsystem ergänzend zu implementieren.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-23
+Titel:         Sperrung von Bankverbindungen ohne Autorisierung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  Kunde besitzt mehrere Bankverbindungen.
+Fakt:          `BankAccountBL.GetBankAccountsFromCustomer(customerI3D, onlyAuthorized)`.
+Aussage:       Das System soll bei entsprechendem Aufrufparameter ausschließlich autorisierte Bankverbindungen eines Kunden zurückliefern.
+Ergebnis:      Eine SEPA-relevante Funktion, die `onlyAuthorized=true` verwendet, erhält keine nicht autorisierten Bankverbindungen.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs, Methode GetBankAccountsFromCustomer, Parameter onlyAuthorized – Begründung: konkreter, im Code umgesetzter Filterparameter.
+Prüfidee:      Ein Kunde mit einer autorisierten und einer nicht autorisierten Bankverbindung liefert bei `onlyAuthorized=true` nur eine Verbindung.
+Tracelinks:    StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verhindert fehlerhafte Lastschriften von nicht autorisierten Konten.
+Status:        belegt
+```
+
+```
+ID:            SyRS-24
+Titel:         Rechtegeschützter Zugriff auf den Virtual-Mail-Assistant
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `MailScannerBL.GetProfiles` prüft `_appRightsBl.CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.VirtualMailAssistant.ACCESS_VMA_MODULE)`.
+Aussage:       Das System soll den Zugriff auf Mail-Scanner-Profile serverseitig gegen ein dediziertes Recht prüfen, bevor Profildaten zurückgegeben werden.
+Ergebnis:      Ein Aufruf ohne das Recht liefert keine Profildaten.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs, Methode GetProfiles, Zeile 59f. – Begründung: konkrete, im Code durchgesetzte Rechteprüfung vor Datenrückgabe.
+Prüfidee:      Ein Testbenutzer ohne ACCESS_VMA_MODULE erhält bei GetProfiles keine Profildaten.
+Tracelinks:    StRS-37
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - E-Mail-Verarbeitungsregeln sind sensibel und entsprechend zu schützen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-25
+Titel:         Rechtegeschützte Video-Portal-Zuweisung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `VideoPortalAssignmentBL.SaveVideoPortalAssignment` prüft `UserRightsConst.VideoPortal.ASSIGNMENT` und wirft andernfalls `ResultException`.
+Aussage:       Das System soll das Speichern einer Video-Portal-Zuweisung serverseitig gegen ein dediziertes Recht absichern.
+Ergebnis:      Ein Speicherversuch ohne das Recht wird mit einer Exception abgelehnt, es werden keine Daten persistiert.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs, Methode SaveVideoPortalAssignment, Zeile 30–32 – Begründung: konkrete, durchgesetzte Rechteprüfung vor dem Speichervorgang.
+Prüfidee:      Ein Speicherversuch ohne das Recht ASSIGNMENT hinterlässt keinen neuen/geänderten Datensatz in der Datenbank.
+Tracelinks:    StRS-120
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistentes Rechtekonzept.
+Status:        belegt
+```
+
+```
+ID:            SyRS-26
+Titel:         Konsistente Enum-basierte Statusfilterung bei Gutscheinen
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `VoucherManagementBL.GetActivedVoucherBarcodes` verwendet drei unabhängige Boolean-Parameter statt eines Status-Enums.
+Aussage:       Das System soll Gutschein-Status eindeutig und überschneidungsfrei abfragbar machen.
+Ergebnis:      Die Kombination der drei Filterparameter liefert eine eindeutige, nicht widersprüchliche Ergebnismenge.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs, Methode GetActivedVoucherBarcodes – Begründung: vollständig gelesene Filterlogik mit drei unabhängigen Bool-Parametern.
+Prüfidee:      Eine Abfrage mit widersprüchlichen Kombinationen (z. B. „frei" und „eingelöst" gleichzeitig `true`) liefert ein für Fachanwender nachvollziehbares, dokumentiertes Ergebnis.
+Tracelinks:    StRS-121
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - drei unabhängige Booleans statt eines Status-Enums sind im Zielsystem zu einem eindeutigen Statusmodell zu konsolidieren.
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-27
+Titel:         Named-Query-basierter Zugriff auf sicherheitsrelevante 2FA-Daten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `TwoFactorAuthenticationBL` liest/schreibt den 2FA-Schlüssel ausschließlich über parametrisierte Named Queries (`NamedQueryEnums.PasswordManager.GetAppUserTwoFactorAuthKey`/`UpdateAppUserTwoFactorAuthKey`), nicht über dynamisch zusammengesetztes SQL.
+Aussage:       Das System soll den Zugriff auf 2FA-Schlüssel ausschließlich über parametrisierte, vordefinierte Abfragen abwickeln, um SQL-Injection auszuschließen.
+Ergebnis:      Es existiert kein Codepfad, der 2FA-Schlüssel über dynamisch mit Benutzereingaben zusammengesetztes SQL liest/schreibt.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, durchgängige Verwendung von NamedQueryParameter statt String-Konkatenation – Begründung: vollständig gelesene Klasse zeigt konsequent parametrisierten Zugriff.
+Prüfidee:      Ein Penetrationstest mit SQL-Metazeichen im PIN-Feld führt zu keiner SQL-Injection.
+Tracelinks:    StRS-118
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - sicheres Zugriffsmuster ist im Zielsystem beizubehalten.
+Status:        belegt
+```
+
+```
+ID:            SyRS-28
+Titel:         Serverseitige Filialbeschränkung für Rechtegruppenverwaltung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  Benutzer besitzt das einschränkende Recht MANAGE_RIGHTS_ONLY_OWN_BRANCH.
+Fakt:          `AppRightsBL.GetAllRightGroups(currentUser)` filtert serverseitig nach `BranchI3D`, wenn das einschränkende Recht vorliegt.
+Aussage:       Das System soll die in `CentronRights.md` dokumentierten „einschränkenden Rechte" (restricting rights) serverseitig als Datenfilter umsetzen, nicht nur als UI-Sichtbarkeitsregel.
+Ergebnis:      Ein Benutzer mit einschränkendem Recht erhält serverseitig gefilterte Daten, unabhängig von der aufrufenden Oberfläche.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methode GetAllRightGroups, Zeile 42–47 – Begründung: konkrete, serverseitig durchgesetzte Filterlogik, nicht nur UI-Ausblendung.
+Prüfidee:      Ein direkter API-Aufruf (unter Umgehung der Desktop-UI) durch einen filialbeschränkten Benutzer liefert weiterhin nur Gruppen der eigenen Filiale.
+Tracelinks:    StRS-90, SyRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - serverseitige Durchsetzung ist zwingend für ein sicheres SaaS-Zielsystem.
+Status:        belegt
+```
+
+```
+ID:            SyRS-29
+Titel:         Robuste Fehlerbehandlung bei fehlenden Zwei-Faktor-Schlüsseln
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Benutzer hat noch keinen 2FA-Schlüssel hinterlegt.
+Fakt:          `TwoFactorAuthenticationBL.ValidateAuthenticationPin` liefert bei fehlendem Schlüssel die Fehlermeldung „Ihrem Benutzer ist kein Zwei-Faktor Schlüssel in der Personalverwaltung hinterlegt!" statt eines technischen Fehlers.
+Aussage:       Das System soll bei fehlendem 2FA-Schlüssel eine fachlich verständliche Fehlermeldung statt eines technischen Fehlers liefern.
+Ergebnis:      Ein Benutzer ohne hinterlegten Schlüssel erhält eine klare Handlungsanweisung statt eines kryptischen Fehlers.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methode ValidateAuthenticationPin, Zeile 47–49 – Begründung: konkrete, im Code hinterlegte, fachlich verständliche Fehlermeldung.
+Prüfidee:      Ein Benutzer ohne hinterlegten Schlüssel erhält exakt diese Fehlermeldung beim Anmeldeversuch mit 2FA.
+Tracelinks:    StRS-118
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gute Usability-Praxis, im Zielsystem beizubehalten.
+Status:        belegt
+```
+
+---
+
+## Risikofokussierte Vertiefung (Rechte, Authentifizierung, Fakturierung, Datenschutz)
+
+```
+ID:            SyRS-30
+Titel:         Zeitgesteuerte Kontoaktivierung/-deaktivierung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  Konto besitzt ggf. `AccountDisabledFromDate`/`AccountDisabledToDate`.
+Fakt:          `AppUserBL.GetActiveAppUsers()`, drei Fallunterscheidungen: (a) kein Zeitraum gesetzt → aktiv, wenn `IsAccountDisabled == false`; (b) nur `FromDate` gesetzt → aktiv, wenn heute vor `FromDate` ODER (`ToDate` gesetzt und heute nach `ToDate`); (c) analog für `ToDate`.
+Aussage:       Das System soll den Aktivstatus eines Kontos bei jedem sicherheitsrelevanten Zugriff serverseitig unter Berücksichtigung des aktuellen Datums neu berechnen, nicht anhand eines zwischengespeicherten Status-Flags.
+Ergebnis:      Ein Konto, dessen Deaktivierungszeitraum gerade abgelaufen ist, wird beim nächsten Zugriff korrekt als aktiv erkannt, ohne dass ein Batch-Job das Flag zurücksetzen muss.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/EmployeeArea/AppUserBL.cs, Methode GetActiveAppUsers, Zeilen 38–50 – Begründung: die vollständig gelesene, dreistufige Datumslogik wird bei jedem Aufruf neu ausgewertet (kein persistiertes „berechnetes" Aktiv-Flag erkennbar).
+Prüfidee:      Ein Konto mit `AccountDisabledToDate = gestern` erscheint in `GetActiveAppUsers()`, ohne dass zuvor ein Wartungsjob lief.
+Tracelinks:    StRS-24, StRS-126
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - korrekte, serverseitig neu berechnete Zeitlogik statt zwischengespeichertem Status ist ein gutes Muster für das Zielsystem.
+Status:        belegt
+```
+
+```
+ID:            SyRS-31
+Titel:         Rechtegeschützter Zugriff auf den Passwortmanager
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `PasswordManagerBL` injiziert `AppRightsBL` im Konstruktor; konkrete Prüfmethode innerhalb der Klasse wurde in dieser Iteration nicht vollständig gelesen (nur Konstruktor-Ausschnitt).
+Aussage:       Das System soll den Zugriff auf im Passwortmanager hinterlegte Zugangsdaten serverseitig gegen ein dediziertes Recht prüfen.
+Ergebnis:      Ein Benutzer ohne Passwortmanager-Zugriffsrecht kann keine hinterlegten Zugangsdaten einsehen.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Konstruktorinjektion `AppRightsBL _appRightsBL` – Begründung: Injektion belegt Verfügbarkeit einer Rechteprüfung, die konkrete Prüfstelle (Methode, Rechte-ID) wurde nicht gelesen.
+Prüfidee:      Noch zu bestimmen – Vertiefung in Folge-Iteration erforderlich: konkrete Methode und Rechte-ID identifizieren, die den Zugriff tatsächlich absichert.
+Tracelinks:    StRS-50
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschätzung vorläufig, da Beleg dünn (nur Konstruktor gelesen).
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-32
+Titel:         Konsistente Lizenzsperre für Produktionsaufträge
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `ProductionOrderBL.GetProductionOrderByI3D`, `GetProductionOrdersByFilter`, `SaveProductionOrder` prüfen jeweils identisch `LicenseManager.Instance.HasLicense(LicenseGuids.ProductionManagement)` vor jeder Operation (Lesen, Filtern, Schreiben).
+Aussage:       Das System soll die Lizenzprüfung für Produktionsaufträge konsistent auf alle CRUD-Operationen anwenden, nicht nur auf einzelne Einstiegspunkte.
+Ergebnis:      Es existiert keine Produktionsauftrags-Operation, die die Lizenzprüfung umgeht.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs, alle drei genannten Methoden – Begründung: identische Prüfung an allen drei beobachteten Einstiegspunkten belegt Konsistenz innerhalb der gelesenen Klasse.
+Prüfidee:      Alle drei Methoden (Lesen per I3D, Filtern, Speichern) lösen ohne gültige Lizenz identisch eine Exception aus.
+Tracelinks:    StRS-53
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistente Durchsetzung ist Grundlage des Lizenzmodells.
+Status:        belegt
+```
+
+```
+ID:            SyRS-33
+Titel:         Zweistufige Autorisierung: UI-Sichtbarkeit und Server-Durchsetzung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          Client: `ModuleRightsExpressionParser.cs` steuert Ribbon-Sichtbarkeit im WPF-Client. Server: `AuthorizeUserRightAttribute`/`UserRightAuthorizationFilter` prüft REST-Aufrufe unabhängig vom Client mit 401/403.
+Aussage:       Das System soll Rechte nicht nur clientseitig zur Steuerung der UI-Sichtbarkeit, sondern zwingend auch serverseitig bei jedem API-Aufruf durchsetzen, sodass eine manipulierte oder umgangene Client-UI keinen unautorisierten Zugriff ermöglicht.
+Ergebnis:      Ein direkter API-Aufruf unter Umgehung der Desktop-UI wird serverseitig identisch geprüft wie ein Aufruf über die UI.
+Belege:
+  - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, Klasse UserRightAuthorizationFilter – Begründung: serverseitiger Filter ist unabhängig vom aufrufenden Client aktiv, damit durchgesetzte (nicht nur angezeigte) Autorisierung.
+Prüfidee:      Ein direkter HTTP-Aufruf (z. B. via curl) ohne das erforderliche Recht liefert 403, unabhängig davon, ob der WPF-Client die Funktion anzeigen würde.
+Tracelinks:    StRS-72, StRS-87
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zwei-Ebenen-Autorisierung (UX-Hinweis + harte Durchsetzung) ist Best Practice und im Zielsystem beizubehalten.
+Status:        belegt
+```
+
+```
+ID:            SyRS-34
+Titel:         Verschlüsselte Speicherung von Drittanbieter-API-Schlüsseln
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `OpenAiApiClient` entschlüsselt `_settings.ApiKey` über `CryptoControl.DecryptString` unmittelbar vor Verwendung als Bearer-Token; derselbe verschlüsselte Speicheransatz wird für das PDF-Signatur-TSA-Passwort verwendet (`PdfSigningBL`, `AESCryptoLogic`).
+Aussage:       Das System soll alle Drittanbieter-API-Schlüssel und -Zugangsdaten grundsätzlich verschlüsselt speichern und erst zur Laufzeit entschlüsseln – ein Muster, das an mindestens zwei unabhängigen Stellen (KI-API, PDF-Signatur-TSA) konsistent umgesetzt ist.
+Ergebnis:      Ein direkter Blick in die Konfigurationsdatenbank zeigt für keinen der geprüften Schlüssel den Klartext.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs, CryptoControl.DecryptString; src/backend/Centron.BL/Security/PdfSigningBL.cs, AESCryptoLogic.DecryptText – Begründung: identisches Verschlüsselungsmuster an zwei unabhängigen Stellen belegt einen systemweiten, konsistenten Sicherheitsstandard für Drittanbieter-Zugangsdaten.
+Prüfidee:      Weder der KI-API-Schlüssel noch das TSA-Passwort sind bei direkter Datenbankabfrage im Klartext lesbar.
+Tracelinks:    StRS-124, StRS-133
+Konsolidierung: Kandidat: StRS-124, StRS-133 – Begründung: beide Anforderungen setzen dasselbe technische Verschlüsselungsmuster (AES-Verschlüsselung sensibler Zugangsdaten) an unterschiedlichen Stellen um; im Zielsystem als ein zentraler Secret-Store zu konsolidieren.
+Übernahmewürdigkeit: übernehmen - konsistentes Verschlüsselungsmuster ist Mindeststandard, im Zielsystem idealerweise über einen zentralen Secret-Manager (z. B. Azure Key Vault) statt anwendungseigener AES-Logik.
+Status:        belegt
+```
+
+```
+ID:            SyRS-35
+Titel:         Verpflichtender zweiter Faktor bei jeder Basis-Anmeldung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  2FA ist für den Benutzer aktiviert.
+Fakt:          `BasicAuthenticator.AuthenticateInternal` ruft `_twoFactorAuthBL.ValidateTwoFactor(...)` **nach** erfolgreicher Passwortprüfung auf; nur bei `ResultStatus.Success` wird die Anmeldung als erfolgreich gewertet, andernfalls wird trotz korrektem Passwort ein Fehler zurückgegeben.
+Aussage:       Das System soll die Anmeldung erst nach kumulativer Prüfung von Passwort UND zweitem Faktor als erfolgreich werten; ein korrektes Passwort allein darf niemals zur Anmeldung genügen, wenn 2FA aktiviert ist.
+Ergebnis:      Ein Angreifer mit gestohlenem, aber korrektem Passwort kann sich ohne gültigen zweiten Faktor nicht anmelden.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Methode AuthenticateInternal, Zeilen 60–70 – Begründung: der Kontrollfluss zeigt konkret, dass der Rückgabewert bei fehlgeschlagenem zweitem Faktor auf Fehler gesetzt wird, obwohl das Passwort bereits validiert war.
+Prüfidee:      Eine Anmeldung mit korrektem Passwort und abgelaufenem/falschem TOTP-Code schlägt fehl; dieselbe Anmeldung mit gültigem TOTP-Code gelingt.
+Tracelinks:    StRS-129
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - korrekte kumulative 2FA-Logik ist sicherheitskritisch und unverändert zu übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-36
+Titel:         Fehlende Salzung bei der Passwort-Hash-Bildung im Anmeldepfad
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `BasicAuthenticator.AuthenticateInternal`, Zeile 46: `SHA1Decoder.GetDecodedSHA1String(Auth.Password.ToString())`, unmittelbar gefolgt vom Entwicklerkommentar „// TODO the password should be salted!!!“; identisches Muster in `UsersBL.cs` bei Passwortprüfung (Zeilen 65, 88) und -änderung (Zeile 107).
+Aussage:       Das System soll Passwörter niemals ohne benutzerindividuelles Salt hashen; das aktuelle System verstößt hiergegen nachweislich an mindestens vier unabhängigen Codestellen.
+Ergebnis:      Zwei Benutzer mit identischem Passwort erzeugen im aktuellen System denselben Hash-Wert, was Rainbow-Table-Angriffe gegen die gesamte Benutzerdatenbank erleichtert.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs, Zeile 46–48 – Begründung: unmittelbar durch Entwicklerkommentar im Code selbst bestätigter Mangel.
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/UsersBL.cs, Zeilen 65, 88, 107 – Begründung: dieselbe ungesalzene SHA1-Vergleichslogik wird durchgängig bei Passwortprüfung und -änderung verwendet, bestätigt also, dass es sich nicht um eine isolierte Ausnahme handelt.
+Prüfidee:      Zwei Testkonten mit identischem Passwort weisen im aktuellen System denselben gespeicherten `Password`-Wert auf.
+Tracelinks:    StRS-130, StRS-96
+Konsolidierung: Kandidat: StRS-96 – Begründung: das ungenutzte `CryptoUtils.CreatePasswordHash` (mit Salt-Unterstützung) und die tatsächlich verwendete `SHA1Decoder`-Logik (ohne Salt) sind zwei parallele Implementierungen desselben fachlichen Zwecks „Passwort-Hashing" – klarer Konsolidierungsfall.
+Übernahmewürdigkeit: veraltet - diese konkrete Implementierung darf nicht in das Zielsystem übernommen werden; zu ersetzen durch einen gesalzenen, adaptiven Hash-Algorithmus (Argon2id/bcrypt) mit Migrationsstrategie für Bestandspasswörter (Re-Hashing beim nächsten erfolgreichen Login).
+Status:        belegt
+```
+
+```
+ID:            SyRS-37
+Titel:         Pessimistische Beleg-Sperre mit rechtebasiertem Fremdentsperren
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System
+Vorbedingung:  Ein Beleg wird von einem Benutzer geöffnet/bearbeitet.
+Fakt:          `InvoiceSpecificLogic.TryLockReceipt(receiptI3D, appUser)` ruft `_lockBL.LockReceipt(...)`; `UnLockReceipt(receiptI3D, appUser, onlyIfLockedByCurrentUser)` erlaubt Entsperren durch Dritte nur mit Recht `UNLOCK_CUSTOMER_ATTACHMENTS`, gesteuert über den Parameter `onlyIfLockedByCurrentUser`.
+Aussage:       Das System soll Rechnungen während der Bearbeitung pessimistisch sperren; ein Entsperren durch einen anderen Benutzer als den Sperrenden soll nur mit einem gesonderten Recht möglich sein.
+Ergebnis:      Nur der sperrende Benutzer selbst oder ein Benutzer mit dem Entsperr-Recht kann eine gesperrte Rechnung freigeben.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Methoden TryLockReceipt/UnLockReceipt, Zeilen 191–204 – Begründung: konkrete, im Code umgesetzte Sperr-/Entsperrlogik mit Rechteparameter.
+Prüfidee:      Benutzer A sperrt eine Rechnung; Benutzer B ohne das Entsperr-Recht erhält bei `UnLockReceipt(..., onlyIfLockedByCurrentUser: true)` eine Ablehnung, mit dem Recht gelingt das Entsperren.
+Tracelinks:    StRS-131, StRS-98
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Sperrmechanismus ist zentral für Datenintegrität bei paralleler Bearbeitung.
+Status:        belegt
+```
+
+```
+ID:            SyRS-38
+Titel:         Identisches Rechteprüfmuster für OPOS und Mahnwesen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `OposBL.ThrowIfUserHasInsufficentRights` und `DunningBL.GetDunningCustomers` (Zeile 62) prüfen unabhängig voneinander dasselbe Recht `UserRightsConst.Controlling.Finances.Dunning` und werfen bei Fehlen eine Exception, statt gefilterte/leere Daten zurückzugeben.
+Aussage:       Das System soll bei fehlendem Finanz-Controlling-Recht den Zugriff auf OPOS- und Mahnwesen-Daten durch eine harte Exception unterbinden (fail-closed), nicht durch stille Filterung, um versehentliche Datenlecks bei Implementierungsfehlern zu vermeiden.
+Ergebnis:      Ein Programmierfehler, der die Rechteprüfung vergisst, würde zu einem sofort sichtbaren Fehler führen statt zu einer stillen Datenpreisgabe.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs, Methode ThrowIfUserHasInsufficentRights, Zeile 28–36; src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeile 62 – Begründung: beide Klassen setzen unabhängig voneinander dasselbe „fail-closed"-Muster (Exception statt gefilterter Rückgabe) für dasselbe Recht um.
+Prüfidee:      Ein Testbenutzer ohne das Recht `Controlling.Finances.Dunning` erhält bei beiden Funktionen eine Exception, keine leere oder teilweise Datenliste.
+Tracelinks:    StRS-132
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - fail-closed-Muster ist sicherheitstechnisch vorzuziehen und im Zielsystem beizubehalten.
+Status:        belegt
+```
+
+```
+ID:            SyRS-39
+Titel:         Administratorpflicht für qualifizierte Signatureinstellungen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit
+Akteur:        System
+Vorbedingung:  –
+Fakt:          `PdfSigningBL.SavePdfSigningSettings`: `if (!currentUser.HasUserRight(UserRightsConst.Administration.SETTINGS))` vor jeder Änderung an Zertifikat/TSA-Konfiguration.
+Aussage:       Das System soll die Änderung sicherheitskritischer Signaturkonfiguration (Zertifikat, TSA-Zugangsdaten) ausschließlich Benutzern mit allgemeinem Administrationsrecht gestatten.
+Ergebnis:      Ein Benutzer ohne Administrationsrecht kann weder das Zertifikat zurücksetzen noch TSA-Zugangsdaten ändern.
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs, Methode SavePdfSigningSettings, Zeile 60 – Begründung: konkrete, im Code durchgesetzte Rechteprüfung vor jeder sicherheitsrelevanten Änderung.
+Prüfidee:      Ein Benutzer ohne Administrationsrecht erhält bei `SavePdfSigningSettings` einen Fehler statt einer Änderung.
+Tracelinks:    StRS-133
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konsistent mit dem übrigen Rechtekonzept für sicherheitskritische Einstellungen.
+Status:        belegt
+```
+
+---
+
+**Gesamtzahl SyRS in diesem Dokument: 39** (SyRS-1 bis SyRS-39, lückenlos).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Ergebnisse/Traceability.md

@@ -0,0 +1,63 @@
+# Traceability
+
+Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Tabelle 1 enthält alle Ketten, in denen mindestens eine SyRS- oder SwRS-Verfeinerung existiert. Tabelle 2 listet die StRS-Anforderungen, die in dieser Iteration ausschließlich auf Stakeholder-Ebene erfasst wurden (Breite-vor-Tiefe, siehe Selbstbewertung in `Analysebericht.md`).
+
+## Tabelle 1 – Verfeinerte Ketten (StRS ↔ SyRS ↔ SwRS)
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---|---|---|
+| StRS-4, StRS-90, StRS-125 | SyRS-1, SyRS-28 | SwRS-16 | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` (GetAllRightGroups, BranchI3D-Filter); `CentronRights.md` |
+| StRS-24, StRS-126 | SyRS-30 | SwRS-30 | `src/backend/Centron.BL/EmployeeArea/AppUserBL.cs` (GetActiveAppUsers) |
+| StRS-50, StRS-127 | SyRS-31 | – | `src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs` |
+| StRS-53 | SyRS-8, SyRS-32 | SwRS-17, SwRS-31 | `src/backend/Centron.BL/Production/ProductionOrderBL.cs` |
+| StRS-72, StRS-87 | SyRS-33 | SwRS-33 | `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` |
+| StRS-124 | SyRS-34 | SwRS-32 | `src/backend/Centron.BL/ArtificialIntelligence/OpenAiApiClient.cs` |
+| StRS-81, StRS-118, StRS-129 | SyRS-35 | SwRS-34 | `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`; `src/shared/Centron.Core/GoogleAuthenticator` |
+| StRS-96, StRS-130 | SyRS-36 | SwRS-35 | `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`; `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs`; `src/backend/Centron.BL/Core/CryptoUtils.cs` |
+| StRS-98, StRS-131 | SyRS-37 | SwRS-36 | `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs` (TryLockReceipt/UnLockReceipt) |
+| StRS-132 | SyRS-38 | SwRS-37 | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs`; `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs` |
+| StRS-99, StRS-133 | SyRS-39 | SwRS-38 | `src/backend/Centron.BL/Security/PdfSigningBL.cs` |
+| StRS-83, StRS-84 | SyRS-2 | SwRS-1, SwRS-2 | `src/backend/Centron.DAO/GenericDAO.cs`; `src/backend/Centron.Entities/PersistedEntity.cs` |
+| StRS-23 | SyRS-3 | SwRS-3 | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` |
+| StRS-61 | SyRS-4 | SwRS-4 | `src/backend/Centron.BL/WebServices/ObjectMapperConfiguration/DunningConfiguration.cs` |
+| StRS-32 | SyRS-6 | SwRS-5 | `src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs` |
+| StRS-60 | – | SwRS-6 | `src/backend/Centron.BL/WebLinks/WebLinkBL.cs` |
+| StRS-56, StRS-57 | SyRS-11 | SwRS-7 | `src/backend/Centron.BL/Reporting/ReportsBL.cs` |
+| StRS-59 | SyRS-12 | SwRS-8 | `src/backend/Centron.BL/Warehousing/TaxBL.cs` |
+| StRS-111 | SyRS-13 | SwRS-9 | `src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs` |
+| StRS-41 | SyRS-14 | SwRS-10 | `src/backend/Centron.BL/Modules/ModuleBL.cs` |
+| StRS-45 | SyRS-15 | SwRS-11, SwRS-26 | `src/backend/Centron.BL/NexusTicketViews/NexusTicketViewBL.cs` |
+| StRS-10 | SyRS-16 | SwRS-12 | `src/backend/Centron.BL/Calendar/CalendarBL.cs` |
+| StRS-40 | SyRS-17 | SwRS-13 | `src/backend/Centron.BL/Mobile/MobileBL.cs` |
+| StRS-110 | SyRS-18 | SwRS-14 | `src/backend/Centron.BL/Telemetry/TelemetryBL.cs` |
+| StRS-128 | SyRS-19 | SwRS-15 | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` |
+| StRS-1 | SyRS-23 | – | `src/backend/Centron.BL/Accounting/BankAccountBL.cs` |
+| StRS-34 | SyRS-22 | SwRS-18 | `src/backend/Centron.BL/ItPlanner/ChecklistVirtualObjectCategoryBL.cs` |
+| StRS-64, StRS-65, StRS-67, StRS-68 | SyRS-9 (nur 67/68) | SwRS-21 | `src/apis/Centron.APIs.CopDataAccess`, `EgisDataAccess`, `ITscopeDataAccess`, `IcecatDataAccess` (je `*Exception.cs`) |
+| StRS-70, StRS-71 | SyRS-10 | – | `src/apis/Centron.Api.Gls`, `Centron.Api.Shipcloud` |
+| StRS-73, StRS-123 | – | SwRS-22 | `src/webservice/Centron.Host.Console/Program.cs`; `Centron.Host.WindowsService/CentronService.cs` |
+| StRS-118 | SyRS-27, SyRS-29 | SwRS-19 | `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` |
+| StRS-7 | – | SwRS-24 | `src/backend/Centron.BL/BusinessPartner/SupplierAssetBL.cs` |
+| StRS-25 | – | SwRS-25 | `src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs` |
+| StRS-47, StRS-51 | SyRS-15 | SwRS-26 | `src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs`; `src/backend/Centron.BL/Processes/ProcessBL.cs` |
+| StRS-37 | SyRS-24 | – | `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` |
+| StRS-114, StRS-120, StRS-122 | SyRS-25 | – | `src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs` |
+| StRS-121 | SyRS-26 | – | `src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs` |
+| StRS-92 | SyRS-21 | – | `docker/c-entron-regression-tests-db`, `c-entron-mailcatcher` |
+| StRS-77 | SyRS-20 | – | `src/nexus/CentronNexus.Host/appsettings.json`, `appsettings.Development.json` |
+| StRS-44 | SyRS-5 | – | `src/backend/Centron.BL/NexusNotifications/NotificationsHubHelper.cs` |
+| StRS-36 | SyRS-7 | – | `src/backend/Centron.BL/Mail/Blacklist` |
+| StRS-53 | SyRS-8 | SwRS-17 | `src/backend/Centron.BL/Production/ProductionOrderBL.cs`; `LicenseManager` |
+| StRS-4 | SyRS-1 | – | `src/backend/Centron.BL/Administration/Company/MandatorBL.cs`, `BranchBL.cs` |
+| StRS-101 | – | SwRS-27, SwRS-28, SwRS-29 (Querschnitt, kein 1:1) | mehrfach unabhängig beobachtetes Result-/Guard-/Konstruktionsmuster (siehe SwRS-27–29) |
+| StRS-7 | – | SwRS-24 | siehe oben |
+| StRS-84 | – | SwRS-1 | `src/backend/Centron.Entities/PersistedEntity.cs` |
+| StRS-83 | SyRS-2 | SwRS-2 | `src/backend/Centron.DAO/GenericDAO.cs` |
+
+## Tabelle 2 – StRS ohne SyRS-/SwRS-Verfeinerung in dieser Iteration (Breite-vor-Tiefe)
+
+Diese Anforderungen sind gemäß Schritt 0b (Mindestabdeckung) auf StRS-Ebene belegt, wurden in dieser Iteration jedoch nicht bis SyRS/SwRS heruntergebrochen. Sie stehen als Nachschlag für eine Folge-Iteration aus (siehe Selbstbewertung, `Analysebericht.md` Abschnitt 6).
+
+StRS-2, StRS-3, StRS-5, StRS-6, StRS-8, StRS-9, StRS-11, StRS-12, StRS-13, StRS-14, StRS-15, StRS-16, StRS-17, StRS-18, StRS-19, StRS-20, StRS-21, StRS-22, StRS-26, StRS-27, StRS-28, StRS-29, StRS-30, StRS-31, StRS-33, StRS-35, StRS-38, StRS-39, StRS-42, StRS-43, StRS-46, StRS-48, StRS-49, StRS-52, StRS-54, StRS-55, StRS-58, StRS-62, StRS-63, StRS-66, StRS-69, StRS-74, StRS-75, StRS-76, StRS-78, StRS-79, StRS-80, StRS-82, StRS-85, StRS-86, StRS-88, StRS-89, StRS-91, StRS-93, StRS-94, StRS-95, StRS-97, StRS-100, StRS-102, StRS-103, StRS-104, StRS-105, StRS-106, StRS-107, StRS-108, StRS-109, StRS-112, StRS-113, StRS-115, StRS-116, StRS-117, StRS-119, StRS-134.
+
+**Anzahl:** 72 von 134 StRS-Anforderungen (53,7 %) ohne SyRS-/SwRS-Verfeinerung in dieser Iteration; 62 StRS-Anforderungen (46,3 %) sind Teil einer verfeinerten Kette in Tabelle 1.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/Protokoll.md

@@ -0,0 +1,224 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T10:29:44.9799824+02:00
+- **Endzeit:** 2026-08-26T11:13:11.9176123+02:00
+- **Dauer gesamt:** 0:43:26 (`duration_ms` 0:43:25; API: 0:42:49)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
+
+  - `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
+    - SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
+    - 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
+
+  Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
+  Untersuchungsgegenstand ist ein anderer.
+- **Nutzung des DB-Schemas:** **ja** – 4 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Bash`, `Read`, `Write`), 3 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.3.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 11.420.621 Tokens (99.94 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.06 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.3.0-0848`
+- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-2316`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-b652`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
+  Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich**
+  `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0,
+  `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 118 |
+| Output-Tokens | 292.548 (davon 46.802 Thinking-Tokens) |
+| Cache-Write-Tokens | 492.297 |
+| Cache-Read-Tokens | 10.635.658 |
+| Agent-Turns | 122 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 118 | 6.943 | 7.061 |
+| Output-Tokens | 292.548 | 22 | 292.570 |
+| Cache-Write-Tokens | 492.297 | 0 | 492.297 |
+| Cache-Read-Tokens | 10.635.658 | 0 | 10.635.658 |
+| **Tokens gesamt** | **11.420.621** | **6.965** | **11.427.586** |
+
+**Tokens gesamt: 11.427.586** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 134 | 63,5 % |
+| SyRS | 39 | 18,5 % |
+| SwRS | 38 | 18,0 % |
+| **Gesamt** | **211** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 102 | 48,3 % |
+| Sicherheit | 36 | 17,1 % |
+| Daten | 29 | 13,7 % |
+| Schnittstelle | 28 | 13,3 % |
+| nicht-funktional | 13 | 6,2 % |
+| Performance | 3 | 1,4 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 213 |
+| davon `PRIMÄR` | 94 (44,1 %) |
+| davon `SEKUNDÄR` | 98 (46,0 %) |
+| davon `KONTEXT` | 21 (9,9 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (43,6 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 189 | 89,6 % |
+| workaround | 14 | 6,6 % |
+| sonderfall | 3 | 1,4 % |
+| veraltet | 5 | 2,4 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 180 | 85,3 % |
+| als `HYPOTHESE` gekennzeichnet | 31 | 14,7 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 26 | 12,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 39 | 18,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 52 ungedeckt: StRS-28, StRS-33, StRS-50, StRS-79, StRS-80, StRS-90, StRS-125 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 211 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 105 von 211 mit Tracelinks (49,8 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `857e4959-b8dd-4d8d-b113-b4eeb3d7d5a7`
+- **Permission-Denials:** 0 – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 40.159 B |
+  | `Glossar.md` | 3.980 B |
+  | `Hypothesen.md` | 6.333 B |
+  | `StRS.md` | 154.764 B |
+  | `SwRS.md` | 50.758 B |
+  | `SyRS.md` | 51.061 B |
+  | `Traceability.md` | 6.863 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
+`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
+63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
+Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
+Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
+
+**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
+Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
+(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
+nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
+zwangsläufig und ist kein Zugriff.
+
+**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
+zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
+`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
+nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
+`084301_v4.2.0-d6f9` mit 45:04.
+
+**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
+weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
+deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
+identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
+
+**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
+(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
+
+**6. Schema genutzt – und der mit Abstand sparsamste Lauf beider Iterationen.** Vier Werkzeugaufrufe
+(`Bash`, `Read`, `Write`) mit `SSMS_DB_SCHEMA` in der Eingabe, drei Nennungen in den
+Ergebnisartefakten. Ergebnis: **211 Anforderungen bei 11,4 Mio. Tokens** – die höchste Ausbeute je
+Token beider Iterationen. Zum Vergleich `3ef5`, ebenfalls Iteration 3, aber ohne Schemanutzung:
+237 Anforderungen bei 68,9 Mio. Tokens (Faktor 6,0 beim Verbrauch für 12 % mehr Anforderungen).
+Das ist plausibel – ein Schemadump liefert 1.558 Tabellen in einer Datei, wofür sonst hunderte
+Quelldateien zu lesen wären –, aber bei n = 3 genutzten Läufen **kein Beleg**: `2316` nutzte das
+Schema ebenfalls und verbrauchte 48,3 Mio. Tokens.
+
+**7. Die Ausbeute geht zulasten der Struktur.** 63,5 % der Anforderungen liegen auf StRS-Ebene
+(134 von 211), und die Traceability fällt mit **49,8 %** auf den schlechtesten Wert beider
+Iterationen. Sieben von 46 risikorelevanten Anforderungen sind ungedeckt. Die Primärbelegquote
+liegt mit 43,6 % im unteren Drittel.
+
+**8. Sauber im Werkzeugverhalten:** 0 Permission-Denials, genau die sieben geforderten Dateien,
+keine Arbeitsdateien zurückgelassen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":2569292,"num_turns":122,"stop_reason":"end_turn","session_id":"857e4959-b8dd-4d8d-b113-b4eeb3d7d5a7","total_cost_usd":7.029088600000001,"usage":{"input_tokens":118,"cache_creation_input_tokens":492297,"cache_read_input_tokens":10635658,"output_tokens":292548,"output_tokens_details":{"thinking_tokens":46802},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":492297,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":615,"cache_read_input_tokens":363144,"cache_creation_input_tokens":1452,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":1452},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6943,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007053,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":118,"outputTokens":292548,"cacheReadInputTokens":10635658,"cacheCreationInputTokens":492297,"webSearchRequests":0,"costUSD":7.0220356,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"All seven required deliverables are complete in the output directory. Summary of this run:\n\n**Modulinventar (Schritt 0):** 122 Zeilen über die gesamte Codebasis (Centron.BL-Fachmodule, externe APIs, Webservice-Host, Nexus-Portal, geteilte Infrastruktur, Deployment/CI-CD), mit Mindestabdeckung erreicht — kein Modul blieb ohne Anforderung.\n\n**Anforderungen:** 211 insgesamt (134 StRS, 39 SyRS, 38 SwRS), davon 8 Module vertieft (`tief`) mit belastbaren PRIMÄR-Belegen. Wichtigster Einzelbefund: ungesalzenes SHA1-Passwort-Hashing im Login-Pfad, dokumentiert durch einen im Produktivcode verbliebenen `// TODO the password should be salted!!!`-Kommentar (StRS-130/SyRS-36/SwRS-35).\n\n**Konsistenz:** automatisiert geprüft — keine doppelten IDs, keine unbelegten Anforderungen, keine fehlenden Übernahmewürdigkeits-Angaben, keine toten Tracelinks; 32 von 36 risikorelevanten Anforderungen tragen einen PRIMÄR-Beleg, die restlichen 4 sind korrekt als HYPOTHESE markiert. `Hypothesen.md` (31 Einträge) deckt sich exakt mit den Inline-Markierungen.\n\nWährend der Erstellung von `StRS.md` fiel mir ein Nummerierungssprung auf (28 Module ohne Eintrag) — das habe ich noch im selben Lauf korrigiert und dokumentiert, statt es zu verschleiern.","ttft_ms":4845,"ttft_stream_ms":1550,"time_to_request_ms":31,"type":"result","duration_ms":2605387,"uuid":"62fd82bf-3668-451f-a972-7906c0c24539","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/anforderungen.md

@@ -0,0 +1,66 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 134 | 63,5 % |
+| SyRS | 39 | 18,5 % |
+| SwRS | 38 | 18,0 % |
+| **Gesamt** | **211** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 102 | 48,3 % |
+| Sicherheit | 36 | 17,1 % |
+| Daten | 29 | 13,7 % |
+| Schnittstelle | 28 | 13,3 % |
+| nicht-funktional | 13 | 6,2 % |
+| Performance | 3 | 1,4 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 213 |
+| davon `PRIMÄR` | 94 (44,1 %) |
+| davon `SEKUNDÄR` | 98 (46,0 %) |
+| davon `KONTEXT` | 21 (9,9 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (43,6 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 189 | 89,6 % |
+| workaround | 14 | 6,6 % |
+| sonderfall | 3 | 1,4 % |
+| veraltet | 5 | 2,4 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 180 | 85,3 % |
+| als `HYPOTHESE` gekennzeichnet | 31 | 14,7 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 26 | 12,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 39 | 18,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 52 ungedeckt: StRS-28, StRS-33, StRS-50, StRS-79, StRS-80, StRS-90, StRS-125 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 211 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 105 von 211 mit Tracelinks (49,8 %) |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/before.txt

@@ -0,0 +1,2 @@
+?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/combined_prompt.md

@@ -0,0 +1,177 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-0848\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T11:13:11.9176123+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-0848/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T10:29:44.9799824+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Analysebericht.md

@@ -0,0 +1,444 @@
+# Analysebericht – c-entron ERP-Suite
+
+## 0. Untersuchungsgegenstand und Vorgehen
+
+Untersucht wurde die gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (Stand des Arbeitsverzeichnisses zum Zeitpunkt des Laufs). Die Lösung besteht aus 15.554 C#-Dateien und 1.233 XAML-Dateien in sieben Solution-Bereichen (`src/apis`, `src/backend`, `src/centron` [WPF-Desktopclient], `src/nexus` [Blazor-Webclient „c-entron Nexus“], `src/shared`, `src/webservice`) sowie einem 3,27-MB-Datenbankschema-Dump (`SSMS_DB_SCHEMA.sql`), Betriebsartefakten (`docker/`, `deployment/`, `azure*`-Pipelines) und einer Reihe von Referenzdokumenten unter `docs/`.
+
+Wegen der Größe der Codebasis wurde das Modulinventar auf Ebene fachlicher Komponenten (i. d. R. WPF-Modul-Unterordner bzw. eigenständiges Solution-Projekt) gebildet, nicht auf Ebene einzelner Klassen. Kleinere, fachlich verwandte Unterordner mit geringem Risiko wurden zu einer Inventarzeile zusammengefasst (z. B. diverse Administration-Einstellungsdialoge); umsatz-/abrechnungs- und berechtigungsrelevante Bereiche (Finances/Receipts, RightsManagement, DSGVO, SEPA) wurden bewusst feiner aufgeschlüsselt, um die in Schritt 0c geforderte Vertiefung zu ermöglichen. Diese Granularität ist damit selbst eine Aussage über Risikoeinschätzung, nicht nur eine Gliederungsentscheidung.
+
+Das Inventar wird **vor** der ersten Anforderung festgelegt (Schritt 0) und im Verlauf des Laufs nur ergänzt, nicht gekürzt.
+
+## 1. Modulinventar
+
+Spalten: `#` (Referenz-ID für dieses Inventar) | Modul/Komponente | Pfad (relativ zu `src/`, sofern nicht anders angegeben) | Fachliche Aufgabe
+
+### A. Administration (Desktop-Client)
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| A1 | Rechteverwaltung | centron/Centron.WPF.UI/Modules/Administration/RightsManagement | Vergabe und Pflege granularer Benutzerrechte (Rechtegruppen, Einzelrechte) |
+| A2 | Datenschutz/DSGVO | centron/Centron.WPF.UI/Modules/Administration/DSGVO | Verwaltung von Aufbewahrungsfristen, Auftragsverarbeitungsverträgen, Löschregeln |
+| A3 | SEPA-Lastschriftverträge | centron/Centron.WPF.UI/Modules/Administration/SepaContract | Verwaltung von SEPA-Mandaten/-Vertragsvorlagen für den Zahlungsverkehr |
+| A4 | Mandantenverwaltung | centron/Centron.WPF.UI/Modules/Administration/MandatorManagement | Verwaltung mehrerer Mandanten/Datenbanken im Mehrmandantenbetrieb |
+| A5 | Mitarbeiterverwaltung | centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement | Stammdatenpflege von Mitarbeitern, Zuordnung zu Abteilungen/Filialen |
+| A6 | Systemkonfiguration & Länder | centron/Centron.WPF.UI/Modules/Administration/{Customization,Settings,CentronConfigDb,Cache,CountryManagement} | Globale Anwendungseinstellungen, Länderstammdaten, Konfigurations-Cache |
+| A7 | Kommunikationseinstellungen | centron/Centron.WPF.UI/Modules/Administration/{MailAndCalender,MailTemplates,PhoneSettings} | Mail-/Kalenderanbindung, Mailvorlagen, Telefonanlagen-Konfiguration |
+| A8 | Dokumentenausgabe | centron/Centron.WPF.UI/Modules/Administration/{PdfExport,PdfSigning,ReportServer,TextBlockManagement} | PDF-Erzeugung/-Signatur, Berichtsserver, Textbausteine für Belege |
+| A9 | Web- & Schnittstelleneinstellungen | centron/Centron.WPF.UI/Modules/Administration/{WebCart,WebServiceSettings,ExternalTools,SqlManagers} | Konfiguration Webshop, Webservices, externer Tools, SQL-Verbindungen |
+| A10 | Betriebs- & Diagnosewerkzeuge | centron/Centron.WPF.UI/Modules/Administration/{LogViewer,Profiling,Connections,UpdateAvailableNotificationSettings} | Log-Auswertung, Performance-Profiling, Verbindungsverwaltung, Update-Hinweise |
+| A11 | Abrechnungs-/Eskalationseinstellungen | centron/Centron.WPF.UI/Modules/Administration/{HourlySurchargeRates,ReceiptConditions,EscalationsSettings,TaskManagmentSettings,ServiceAndLeasing,Services,SendDeliveryListShippingConfirmationSettings} | Stundenzuschläge, Belegkonditionen, Eskalationsregeln, Service-/Leasingverträge |
+
+### B–D. KI, Kalender, Dashboard
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| B1 | Künstliche-Intelligenz-Integration | centron/Centron.WPF.UI/Modules/ArtificialIntelligence | KI-Chat, Angebotstext-Editor, OpenAI-Anbindung, Textbewertung |
+| C1 | Kalender | centron/Centron.WPF.UI/Modules/Calendar | Terminverwaltung im Client |
+| D1 | Dashboard | centron/Centron.WPF.UI/Modules/Dashboard | Startseiten-Kachelübersicht |
+
+### E. DataExchange
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| E1 | Finanzbuchhaltungs-/DATEV-Export | centron/Centron.WPF.UI/Modules/DataExchange/{BookKeeping,DatevOnline2020} | Export von Buchungsdaten an DATEV |
+| E2 | Daten-Im-/Export & Konnektoren | centron/Centron.WPF.UI/Modules/DataExchange/{Connectors,DataExport,DataImport,DocSync} | Generischer Datenaustausch, Dateisynchronisation |
+| E3 | Zahlungsverkehr (SEPA) | centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions | Erzeugung von SEPA-Zahlungs-/Lastschriftdateien |
+| E4 | DocuForm-Dokumentenanbindung | centron/Centron.WPF.UI/Modules/DataExchange/DocuForm, apis/... , Centron.Api.docuFORM | Dokumentenerzeugung über externen DocuForm-Dienst |
+| E5 | RMM-Anbindung | centron/Centron.WPF.UI/Modules/DataExchange/Rmm | Anbindung Remote-Monitoring-/Management-Systeme |
+| E6 | EDI-Lieferantenbestellung je Filiale | centron/Centron.WPF.UI/Modules/DataExchange/SupplierOrderPerBranch | Elektronischer Bestelldatenaustausch mit Lieferanten je Filiale |
+| E7 | Telekom-DIVE-Anbindung | centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive, Modules/TelekomDive | Integration Telekom-DIVE-Plattform |
+
+### F–D (weitere Einzelmodule)
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| F1 | ExternalTool-Variablen | centron/Centron.WPF.UI/Modules/ExternalTool | Verwaltung von Variablen für externe Tool-Aufrufe |
+
+### G. Finances (Rechnungswesen/Abrechnung) — Risikoschwerpunkt
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| G1 | Kontenverwaltung | .../Modules/Finances/AccountManagement | Verwaltung von Finanzkonten |
+| G2 | Automatisierte Abrechnung | .../Modules/Finances/AutomatedBilling | Zeitgesteuerte automatische Rechnungserstellung |
+| G3 | Kampagnenverwaltung | .../Modules/Finances/Campaigns | Marketing-/Vertriebskampagnen mit Kundenzuordnung |
+| G4 | Vertragsauswertung | .../Modules/Finances/{ContractEvaluation2,ContractEvaluationOld} | Auswertung laufender Verträge (aktuelle und Altversion) |
+| G5 | Verträge | .../Modules/Finances/Contracts | Vertragsstammdaten, Laufzeiten, Konditionen |
+| G6 | CRM | .../Modules/Finances/Crm | Kundenbeziehungsmanagement, Kontakthistorie |
+| G7 | Zählerstandserfassung | .../Modules/Finances/DeviceClickCounter | Erfassung von Zählerständen (Klickzähler Drucker/Kopierer) als Abrechnungsgrundlage |
+| G8 | Mahnwesen | .../Modules/Finances/Dunning | Automatisiertes Mahnverfahren für offene Forderungen |
+| G9 | Flatrate-Abrechnung | .../Modules/Finances/FlatrateBilling | Pauschalabrechnung von Verträgen |
+| G10 | Stammdatenlisten Finanzen | .../Modules/Finances/MasterDataLists | Stammdatenlisten für Rechnungswesen |
+| G11 | Offene Posten | .../Modules/Finances/Opos | Verwaltung offener Forderungen/Verbindlichkeiten |
+| G12 | Zahlungen | .../Modules/Finances/Payments | Zahlungserfassung/-zuordnung |
+| G13 | Produktlebenszyklus (Finanzen) | .../Modules/Finances/ProductLifecycleManagement | Abrechnungsrelevante Produktlebenszyklus-Daten |
+| G14 | Projekte | .../Modules/Finances/Projects | Projektbezogene Abrechnung |
+| G15 | Verkaufsbelege – Angebot bis Lieferschein | backend/Centron.BL/Sales/Receipts/{Offers,Orders,DeliveryLists,PickupLists} | Erstellung/Statusführung von Angeboten, Aufträgen, Lieferscheinen, Kommissionierlisten |
+| G16 | Verkaufsbelege – Rechnung & Gutschrift | backend/Centron.BL/Sales/Receipts/{Invoices,CreditVouchers} | Rechnungs-/Gutschrifterstellung, Preisänderungsrechte, Storno |
+| G17 | Einkaufsbelege | backend/Centron.BL/Sales/Receipts/{SupplierOrders,SupplierInvoices,SupplierCreditVouchers,SupplierDeliveryLists} | Bestell-, Wareneingangs- und Lieferantenrechnungsverarbeitung |
+| G18 | Vertragslisten & Belegkern | backend/Centron.BL/Sales/Receipts/{ContractLists,Common,IReceiptSpecificLogic.cs} | Gemeinsame Belegstatusmaschine/-infrastruktur aller Belegarten |
+| G19 | Timer-Abrechnung | .../Modules/Finances/TimerBilling | Abrechnung erfasster Zeiten (z. B. Helpdesk) |
+
+### H–I. Global, Gui
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| H1 | Anwendungsrahmen & Aktionen | centron/Centron.WPF.UI/Modules/Global/{Actions,CustomProperties,EmployeeSelection,FileSystemDialog,ExceptionMessage} | Generische UI-Bausteine: Aktionsmenüs, Individualfelder, Mitarbeiterauswahl |
+| H2 | Hilfe- und Diagnosewerkzeuge | centron/Centron.WPF.UI/Modules/Global/{Help,NetworkDiagnostics,PerformanceTests,MSPLicensesCompare} | Kontexthilfe, Netzwerkdiagnose, Lizenzvergleich |
+| H3 | Videoportal | centron/Centron.WPF.UI/Modules/Global/VideoPortal | Einbindung von Schulungsvideos |
+| I1 | GUI-Profile | centron/Centron.WPF.UI/Modules/Gui/Profiles | Benutzeroberflächen-Profile (Layoutvarianten) |
+
+### J. Helpdesk
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| J1 | Ticketverwaltung | centron/Centron.WPF.UI/Modules/Helpdesk/{TicketList,TicketDetails} | Erfassung, Bearbeitung, Statusführung von Support-Tickets |
+| J2 | Aufgaben- & Ereignisverwaltung | centron/Centron.WPF.UI/Modules/Helpdesk/{TaskManagement,Events,ExpectedEvents,ExpectedEventsReporting} | Aufgaben, SLA-Fälligkeiten, Ereignisreporting |
+| J3 | Checklisten & Prozessvorlagen | centron/Centron.WPF.UI/Modules/Helpdesk/{CentronChecklist,TicketProcessTemplates} | Standardisierte Checklisten/Ticket-Vorlagen (C-FLOW) |
+| J4 | Rufnummern & Selbstauskunft | centron/Centron.WPF.UI/Modules/Helpdesk/{ConnectionNumber,SendSelfCareForm} | Rufnummernverwaltung, Kunden-Selbstauskunftsformulare |
+| J5 | Helpdesk-Einstellungen & Dashboard | centron/Centron.WPF.UI/Modules/Helpdesk/{Settings,Dashboard} | Modulkonfiguration, Kennzahlenübersicht |
+
+### K–T. Weitere Fachmodule
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| K1 | Logistik & Versand | centron/Centron.WPF.UI/Modules/Logistic | Logistikeinstellungen, Versandartenverwaltung |
+| L1 | Massenaktualisierung | centron/Centron.WPF.UI/Modules/Massenupdates | Massenänderung von Datensätzen |
+| M1 | Persönliche Arbeitsorganisation | centron/Centron.WPF.UI/Modules/MyCentron/{Calendar,MyDay,TodoList,PersonalSettings} | Persönlicher Kalender, Tagesplanung, Aufgabenliste |
+| M2 | Prüfassistent & Fernwartung | centron/Centron.WPF.UI/Modules/MyCentron/{CentronInspectors,Supremo} | Geräteprüfassistenten, Fernwartungsanbindung Supremo |
+| M3 | Telefonie & persönliches Dashboard | centron/Centron.WPF.UI/Modules/MyCentron/{Telephony,Dashboard} | TAPI-Telefonie-Integration, persönliches Dashboard |
+| N1 | Online-Banking | centron/Centron.WPF.UI/Modules/OnlineBanking | Kontoumsatzabruf, Bankverbindungskonfiguration (FinAPI) |
+| O1 | Produktlebenszyklusmanagement (PLM) | centron/Centron.WPF.UI/Modules/PLM | Produktlebenszyklus-Übersicht |
+| P1 | Passwortverwaltung | centron/Centron.WPF.UI/Modules/PasswordManager | Verwaltung von Kunden-/Systemzugangsdaten |
+| Q1 | Zahler und Kostenstellen | centron/Centron.WPF.UI/Modules/PayersAndCostCenter | Zuordnung Zahler/Kostenstellen zu Belegen |
+| R1 | Produktion | centron/Centron.WPF.UI/Modules/Production | Maschinen- und Produktionsauftragsverwaltung |
+| S1 | Projektmanagement | centron/Centron.WPF.UI/Modules/ProjectManagement | Projektübersicht/-steuerung |
+| T1 | Projektpreisimport | centron/Centron.WPF.UI/Modules/ProjectPriceImport | Import von Preisdifferenzen für Projekte |
+
+### U–AA. Einkauf, QM, Reports, RMA, Sales, Statistik, Survey
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| U1 | Bestellwesen & EDI | centron/Centron.WPF.UI/Modules/Purchasing/{EDIManagement,OrderSuggestionList,PurchaseSettings,Others} | Bestellvorschläge, EDI-Bestellabwicklung |
+| U2 | Reisekosten | centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense | Reisekostenerfassung/-abrechnung |
+| V1 | Qualitätsmanagement | centron/Centron.WPF.UI/Modules/QM | QM-Prozessunterstützung |
+| W1 | Berichtsverwaltung | centron/Centron.WPF.UI/Modules/Reports | Verwaltung/Ausführung von Reports |
+| X1 | Retourenabwicklung (RMA) | centron/Centron.WPF.UI/Modules/Rma | Rücksendungen, Reparaturabwicklung |
+| Y1 | Vertriebszusatzfunktionen | centron/Centron.WPF.UI/Modules/Sales/{Mailing,ProductMatrix,SpecialArticleImport,SpecialArticleToContractImport} | Serienmail, Produktmatrix, Sonderartikelimport |
+| Z1 | Unternehmenskennzahlen | centron/Centron.WPF.UI/Modules/Statistics/{ManagementInfo,Dashboard} | Management-Reporting |
+| Z2 | MSP-Statistiken | centron/Centron.WPF.UI/Modules/Statistics/{MspCollectors,MspStatistics} | Managed-Service-Provider-Kennzahlen |
+| Z3 | Verkaufs- & Mitarbeiterstatistik | centron/Centron.WPF.UI/Modules/Statistics/{SaleStatistics,EmployeeAnalytics} | Verkaufs-/Auslastungsstatistiken |
+| AA1 | Umfragen | centron/Centron.WPF.UI/Modules/Survey | Kundenumfragen |
+
+### AC. Warehousing
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| AC1 | Artikelstammverwaltung | .../Modules/Warehousing/{ArticleManagement,ArticleUnitManagement,MaterialGroupManagement} | Artikelstamm, Mengeneinheiten, Warengruppen |
+| AC2 | Artikelimport & -suche | .../Modules/Warehousing/{ArticleImport,SearchArticle,SupplierSearch} | Import von Artikeldaten, Artikel-/Lieferantensuche |
+| AC3 | Barcodeverwaltung | .../Modules/Warehousing/BarcodeManagement | Barcode-Zuordnung/-Druck |
+| AC4 | Kommissionierung & Provisionen | .../Modules/Warehousing/{Commissioning,Commissions} | Kommissionierprozess, Provisionsberechnung |
+| AC5 | Inventur | .../Modules/Warehousing/Inventory | Bestandsaufnahme/-abgleich |
+| AC6 | Zahlungsausgänge & Kontensysteme | .../Modules/Warehousing/{OutcomingPayments,AccountSystems} | Ausgangszahlungen, Kassen-/Kontensysteme |
+| AC7 | Umsatzsteuerverwaltung | .../Modules/Warehousing/ValueAddedTax*.cs | Umsatzsteuersätze/-zuordnung |
+
+### Backend-Architekturschicht (Centron.BL/DAO/Entities/Interfaces/Gateway/Common)
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| BE1 | Business-Logic-Schicht | backend/Centron.BL | Fachliche Regeln/Prozesslogik aller Module (Session-basiert) |
+| BE2 | Datenzugriffsschicht (NHibernate) | backend/Centron.DAO | ORM-Mapping, Sitzungsverwaltung, generische Repositories |
+| BE3 | Domänenmodelle | backend/Centron.Entities | Entitätsklassen/Datenmodell |
+| BE4 | Fachliche Schnittstellen | backend/Centron.Interfaces | Vertragsschnittstellen zwischen BL/DAO/UI, u. a. Rechtekonstanten |
+| BE5 | Gateway/Integrationsschicht | backend/Centron.Gateway | Kommunikation zwischen Prozessen/Diensten |
+| BE6 | Common-Utilities | backend/Centron.Common | Technische Hilfsfunktionen |
+| BE7 | Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-Datenbankschema (Tabellen, Constraints) |
+
+### Web-/API-Schicht
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| WA1 | Webservice-Kernlogik | webservice/Centron.WebServices.Core | Fachlogik für SOAP/REST-Zugriffe (mobile Clients, Portale) |
+| WA2 | Controller-Schicht | webservice/Centron.Controllers | HTTP-Endpunkte des Webservice-Hosts |
+| WA3 | Webservice-Host | webservice/{Centron.Host,Centron.Host.Console,Centron.Host.WindowsService} | Hosting als IIS/Konsole/Windows-Dienst |
+| WA4 | Verbindungsmanager | webservice/c-entron.misc.ConnectionManager | Verbindungs-/Session-Verwaltung für Webservice-Clients |
+
+### Nexus (Blazor-Webclient „c-entron Nexus“)
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| NX1 | Dokumentensignatur | nexus/CentronNexus/DocumentSigning | Elektronische Signatur von Dokumenten im Web |
+| NX2 | Verwaltung (Management) | nexus/CentronNexus/Management | Web-Administrationsfunktionen |
+| NX3 | Produktionsauftrags-/Servicetafel | nexus/CentronNexus/{ProductionOrderManagement,ServiceBoard} | Weboberfläche für Produktionsaufträge/Serviceboard |
+| NX4 | WebCart & WebOffer | nexus/CentronNexus/{WebCart,WebOffer} | Kunden-Webshop und Online-Angebote |
+| NX5 | Nexus-Infrastruktur | nexus/{CentronNexus.Host,CentronNexus.OutlookAddIn}, CentronNexus/{Configuration,Settings} | Hosting, Outlook-Add-in, Konfiguration |
+
+### Shared
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| SH1 | Custom-Controls-Bibliothek | shared/{Centron.Controls,Centron.Controls.Preview} | Wiederverwendbare WPF-Steuerelemente |
+| SH2 | Core-Utilities | shared/Centron.Core | Plattformübergreifende Basisfunktionen |
+
+### Externe API-Integrationen
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| XA1 | COP-Datenzugriff | apis/Centron.APIs.CopDataAccess | Anbindung COP-Datenquelle |
+| XA2 | EGIS-Datenzugriff | apis/Centron.APIs.EgisDataAccess | Anbindung EGIS-Datenquelle |
+| XA3 | FinAPI-Bankanbindung | apis/Centron.APIs.FinAPI | Kontoabruf über FinAPI (Online-Banking) |
+| XA4 | ITscope-Datenzugriff | apis/Centron.APIs.ITscopeDataAccess | Produktdatenabgleich über ITscope |
+| XA5 | Icecat-Datenzugriff | apis/Centron.APIs.IcecatDataAccess | Produktdatenabgleich über Icecat |
+| XA6 | EB-Interface (E-Rechnung AT) | apis/Centron.Api.EbInterface | Österreichische E-Rechnungsschnittstelle |
+| XA7 | GLS-Versandanbindung | apis/Centron.Api.Gls | Versanddienstleister-Integration GLS |
+| XA8 | Shipcloud-Versandanbindung | apis/Centron.Api.Shipcloud | Versanddienstleister-Integration Shipcloud |
+| XA9 | docuFORM-Anbindung | Centron.Api.docuFORM | Dokumentenerzeugungsdienst docuFORM |
+
+### Betrieb/Deployment
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| OP1 | Deployment & Containerisierung | docker/, deployment/, azure*/ | Build-/Deploy-Pipelines, Containerisierung, Installer |
+
+**Summe Inventar: 107 Zeilen.**
+## 2. Abdeckungstabelle
+
+Einstufung je Inventarzeile: **tief** (≥ 4 Anforderungen, i. d. R. mit mehrstufiger StRS→SyRS→SwRS-Kette und mindestens einem PRIMÄR-Beleg), **mittel** (2-3 Anforderungen), **flach** (1 Anforderung bzw. nur über eine gemeinsam mit einem Nachbarmodul genutzte Anforderung mitabgedeckt), **nicht analysiert** (keine belegbare Anforderung gefunden). Die Spalte „Anforderungen" nennt die wichtigsten Referenz-IDs, nicht notwendigerweise alle Tracelinks.
+
+| # | Modul | Einstufung | Anzahl | Wichtigste Anforderungen |
+|---|---|---|---|---|
+| A1 | Rechteverwaltung | tief | 4 | StRS-1, SyRS-1, SyRS-2, SwRS-1 |
+| A2 | DSGVO | mittel | 3 | StRS-2 (HYP.), SyRS-3 (HYP.), SwRS-2 |
+| A3 | SEPA-Lastschriftverträge | flach | 1 | SwRS-3 |
+| A4 | Mandantenverwaltung | mittel | 3 | StRS-3, SyRS-4, SwRS-4 |
+| A5 | Mitarbeiterverwaltung | flach | 1 | SwRS-5 (HYP.) |
+| A6 | Systemkonfiguration & Länder | flach | 2 | SyRS-5 (HYP.), SwRS-6 |
+| A7 | Kommunikationseinstellungen | mittel | 3 | StRS-5, SyRS-6, SwRS-7 |
+| A8 | Dokumentenausgabe | mittel | 3 | StRS-6, SyRS-7 (HYP.), SwRS-8 |
+| A9 | Web- & Schnittstelleneinstellungen | mittel | 3 | StRS-7, SyRS-8, SwRS-9 (HYP.) |
+| A10 | Betriebs- & Diagnosewerkzeuge | mittel | 3 | StRS-8, SyRS-9, SwRS-10 |
+| A11 | Abrechnungs-/Eskalationseinstellungen | mittel | 3 | StRS-9 (HYP.), SyRS-10 (HYP.), SwRS-11 (HYP.) |
+| B1 | Künstliche-Intelligenz-Integration | mittel | 3 | StRS-10, SyRS-11, SwRS-12 |
+| C1 | Kalender | mittel | 3 | StRS-11, SyRS-12, SwRS-13 |
+| D1 | Dashboard | mittel | 3 | StRS-12, SyRS-13 (HYP.), SwRS-14 (HYP.) |
+| E1 | Finanzbuchhaltungs-/DATEV-Export | flach | 2 | SyRS-15, SwRS-16 |
+| E2 | Daten-Im-/Export & Konnektoren | flach | 2 | SyRS-16 (HYP.), SwRS-17 (HYP.) |
+| E3 | Zahlungsverkehr (SEPA) | tief | 3 | StRS-15, SyRS-17, SwRS-18 |
+| E4 | DocuForm-Dokumentenanbindung | flach | 2 | SyRS-18, SwRS-19 (HYP.) |
+| E5 | RMM-Anbindung | flach | 2 | SyRS-20 (HYP.), SwRS-21 (HYP.) |
+| E6 | EDI-Lieferantenbestellung je Filiale | mittel | 2 | SyRS-19, SwRS-20 |
+| E7 | Telekom-DIVE-Anbindung | flach | 2 | SyRS-21 (HYP.), SwRS-22 (HYP.) |
+| F1 | ExternalTool-Variablen | flach | 3 | StRS-13 (HYP.), SyRS-14 (HYP.), SwRS-15 (HYP.) |
+| G1 | Kontenverwaltung | flach | 2 | SyRS-23 (HYP.), SwRS-23 (HYP.) |
+| G2 | Automatisierte Abrechnung | mittel | 2 | SyRS-24, SwRS-24 |
+| G3 | Kampagnenverwaltung | flach | 1 | SyRS-26 (HYP.) |
+| G4 | Vertragsauswertung | flach | 1 | SwRS-32 |
+| G5 | Verträge | tief | 4 | StRS-16, SyRS-22, SyRS-25, SwRS-30 |
+| G6 | CRM | flach | 1 | SyRS-27 |
+| G7 | Zählerstandserfassung | flach | 1 | SyRS-33 (HYP.) |
+| G8 | Mahnwesen | tief | 7 | StRS-18, SyRS-29, SyRS-30, SyRS-31, SwRS-26, SwRS-27, SwRS-28 |
+| G9 | Flatrate-Abrechnung | flach | 2 | SyRS-28 (HYP.), SwRS-25 (HYP.) |
+| G10 | Stammdatenlisten Finanzen | flach | 1 | SwRS-33 |
+| G11 | Offene Posten | mittel | 2 | SyRS-39, SwRS-34 |
+| G12 | Zahlungen | flach | 1 | SyRS-32 (HYP.) (+ StRS-19, s. G19-Cluster) |
+| G13 | Produktlebenszyklus (Finanzen) | flach | 1 | SwRS-35 (HYP.) |
+| G14 | Projekte | flach | 2 | SyRS-40 (HYP.), SwRS-36 (HYP.) |
+| G15 | Verkaufsbelege – Angebot bis Lieferschein | flach | (geteilt) | StRS-20, SyRS-34 (nennen Offers/Orders/DeliveryLists/PickupLists explizit, kein eigenständiges SwRS) |
+| G16 | Verkaufsbelege – Rechnung & Gutschrift | tief | 8 | StRS-20, SyRS-34–38, SwRS-29, SwRS-31 |
+| G17 | Einkaufsbelege | mittel | 1 | SwRS-29 (+ StRS-20 geteilt) |
+| G18 | Vertragslisten & Belegkern | flach | (geteilt) | StRS-20, SyRS-34 |
+| G19 | Timer-Abrechnung | flach | 1 | SwRS-37 |
+| H1 | Anwendungsrahmen & Aktionen | mittel | 2 | StRS-21, SwRS-38 |
+| H2 | Hilfe- und Diagnosewerkzeuge | flach | 2 | SyRS-42 (HYP.), SwRS-39 (HYP.) |
+| H3 | Videoportal | flach | 1 | SyRS-43 |
+| I1 | GUI-Profile | flach | 1 | SyRS-44 |
+| J1 | Ticketverwaltung | tief | 3 | StRS-22, SyRS-45, SyRS-46 |
+| J2 | Aufgaben- & Ereignisverwaltung | flach | 2 | SyRS-50 (HYP.), SwRS-44 (HYP.) |
+| J3 | Checklisten & Prozessvorlagen | mittel | 2 | SyRS-48, SwRS-43 |
+| J4 | Rufnummern & Selbstauskunft | flach | 2 | SyRS-51 (HYP.), SwRS-45 |
+| J5 | Helpdesk-Einstellungen & Dashboard | flach | 1 | SwRS-46 |
+| K1 | Logistik & Versand | flach | 2 | SyRS-56, SwRS-50 (HYP.) |
+| L1 | Massenaktualisierung | flach | 1 | SyRS-57 (HYP.) |
+| M1 | Persönliche Arbeitsorganisation | flach | 1 | StRS-24 |
+| M2 | Prüfassistent & Fernwartung | flach | 1 | SyRS-54 (HYP.) |
+| M3 | Telefonie & persönliches Dashboard | flach | 1 | StRS-5 (TAPI-Erwähnung) |
+| N1 | Online-Banking | mittel | 3 | StRS-25, SyRS-55 (HYP.), SwRS-49 |
+| O1 | Produktlebenszyklusmanagement (PLM) | mittel | 2 | SyRS-58, SwRS-51 |
+| P1 | Passwortverwaltung | tief | 5 | StRS-23, SyRS-52, SyRS-53 (HYP.), SwRS-47, SwRS-48 |
+| Q1 | Zahler und Kostenstellen | flach | 1 | SyRS-59 (HYP.) |
+| R1 | Produktion | flach | 1 | SyRS-60 (HYP.) |
+| S1 | Projektmanagement | flach | 1 | SyRS-61 |
+| T1 | Projektpreisimport | mittel | 2 | SyRS-62, SwRS-52 |
+| U1 | Bestellwesen & EDI | tief | 6 | StRS-26, SyRS-63, SyRS-64, SyRS-65 (HYP.), SwRS-53, SwRS-54 (HYP.) |
+| U2 | Reisekosten | flach | 2 | SyRS-66 (HYP.), SwRS-55 (HYP.) |
+| V1 | Qualitätsmanagement | flach | 1 | SyRS-67 (HYP.) |
+| W1 | Berichtsverwaltung | flach | 1 | SyRS-68 |
+| X1 | Retourenabwicklung (RMA) | mittel | 2 | SyRS-69, SwRS-56 (HYP.) |
+| Y1 | Vertriebszusatzfunktionen | flach | 1 | SyRS-70 (HYP.) |
+| Z1 | Unternehmenskennzahlen | mittel | 2 | SyRS-71, SwRS-57 |
+| Z2 | MSP-Statistiken | flach | 1 | SyRS-71 (geteilt) |
+| Z3 | Verkaufs- & Mitarbeiterstatistik | flach | 1 | SyRS-71 (geteilt) |
+| AA1 | Umfragen | mittel | 2 | SyRS-72, SwRS-58 |
+| AC1 | Artikelstammverwaltung | tief | 4 | StRS-27, SyRS-73, SwRS-59, SwRS-60 |
+| AC2 | Artikelimport & -suche | flach | 1 | SyRS-78 |
+| AC3 | Barcodeverwaltung | flach | 1 | SyRS-76 |
+| AC4 | Kommissionierung & Provisionen | mittel | 2 | SyRS-79, SwRS-62 (HYP.) |
+| AC5 | Inventur | flach | 2 | SyRS-77 (HYP.), SwRS-63 (HYP.) |
+| AC6 | Zahlungsausgänge & Kontensysteme | mittel | 2 | SyRS-80, SwRS-61 |
+| AC7 | Umsatzsteuerverwaltung | flach | 1 | SwRS-64 |
+| BE1 | Business-Logic-Schicht | flach | 1 | SyRS-96 |
+| BE2 | Datenzugriffsschicht (NHibernate) | mittel | 2 | SyRS-87, SwRS-70 |
+| BE3 | Domänenmodelle | flach | 1 | SyRS-97 |
+| BE4 | Fachliche Schnittstellen | flach | 1 | SyRS-98 |
+| BE5 | Gateway/Integrationsschicht | mittel | 2 | SyRS-86, SwRS-69 |
+| BE6 | Common-Utilities | mittel | 3 | StRS-30, SyRS-85, SwRS-68 |
+| BE7 | Datenbankschema | mittel | 2 | SyRS-88, SwRS-71 |
+| WA1 | Webservice-Kernlogik | flach | 1 | SwRS-78 |
+| WA2 | Controller-Schicht | tief | 5 | StRS-28, SyRS-81, SyRS-82, SwRS-65, SwRS-66 |
+| WA3 | Webservice-Host | flach | 1 | SyRS-94 (Verweis auf CentronRestService) |
+| WA4 | Verbindungsmanager | flach | 2 | SyRS-92 (HYP.), SwRS-74 (HYP.) |
+| NX1 | Dokumentensignatur | flach | 1 | SyRS-83 (HYP.) |
+| NX2 | Verwaltung (Management) | flach | 1 | SwRS-72 |
+| NX3 | Produktionsauftrags-/Servicetafel | tief | 3 | StRS-31, SyRS-89 (HYP.), SwRS-73 |
+| NX4 | WebCart & WebOffer | mittel | 3 | StRS-29, SyRS-84, SwRS-67 |
+| NX5 | Nexus-Infrastruktur | flach | 1 | SyRS-101 |
+| SH1 | Custom-Controls-Bibliothek | flach | 1 | SyRS-93 |
+| SH2 | Core-Utilities | tief | 4 | StRS-33, SyRS-94, SwRS-77, SwRS-78 |
+| XA1 | COP-Datenzugriff | flach | 1 | SyRS-91 (geteilt) |
+| XA2 | EGIS-Datenzugriff | flach | 1 | SyRS-91 (geteilt) |
+| XA3 | FinAPI-Bankanbindung | mittel | 2 | StRS-25 (geteilt), SwRS-75 |
+| XA4 | ITscope-Datenzugriff | flach | 1 | StRS-32 (geteilt), SyRS-90 (geteilt) |
+| XA5 | Icecat-Datenzugriff | flach | 1 | StRS-32 (geteilt), SyRS-90 (geteilt) |
+| XA6 | EB-Interface (E-Rechnung AT) | flach | 1 | SyRS-99 (HYP.) |
+| XA7 | GLS-Versandanbindung | flach | 1 | SwRS-76 (geteilt) |
+| XA8 | Shipcloud-Versandanbindung | flach | 1 | SwRS-76 (geteilt) |
+| XA9 | docuFORM-Anbindung | mittel | 2 | SyRS-100, SwRS-80 |
+| OP1 | Deployment & Containerisierung | mittel | 3 | StRS-34, SyRS-95, SwRS-79 |
+
+**Summe:** 107 von 107 Inventarzeilen mit mindestens einer Anforderung (Mindestabdeckung erreicht). Keine Zeile ist als „nicht analysiert" zu führen.
+
+## 3. Konsistenzcheck
+
+Durchgeführt über den vollständigen Anforderungsbestand (StRS.md: 34, SyRS.md: 101, SwRS.md: 80 Anforderungen; 215 gesamt) nach Abschluss der Erhebung.
+
+### 3.1 Doppelte oder mehrfach vergebene IDs
+Geprüft durch Extraktion aller `ID:`-Werte und Duplikatsuche. **Ergebnis: keine Duplikate.** Jede ID (StRS-1…34, SyRS-1…101, SwRS-1…80) ist genau einmal vergeben.
+
+### 3.2 Anforderungen ohne Beleg
+Geprüft durch Suche nach Anforderungsblöcken ohne mindestens eine Zeile `[PRIMÄR]`, `[SEKUNDÄR]` oder `[KONTEXT]` im Feld `Belege`. **Ergebnis: keine Anforderung ohne Beleg.** Alle 215 Anforderungen führen mindestens einen klassifizierten Beleg.
+
+### 3.3 Anforderungen ohne Angabe zur Übernahmewürdigkeit
+Geprüft durch Suche nach leeren oder fehlenden `Übernahmewürdigkeit:`-Feldern. **Ergebnis: keine Anforderung ohne Angabe.** Alle 215 Anforderungen tragen eine der vier Einstufungen (`übernehmen` in der großen Mehrheit, `Workaround` u. a. bei StRS-8/SwRS-10 [LogViewer], SwRS-13 [Doppelkalender], SwRS-71/SyRS-88 [DB-Fremdschlüssel]; `Sonderfall` u. a. bei StRS-13/SyRS-14/SwRS-15 [ExternalTool-Variablen], SwRS-31 [sechs feste Beraterfelder], SwRS-68 [hartkodierte Testadresse]; `veraltet` bei SwRS-32 [ContractEvaluationOld]).
+
+### 3.4 Tracelinks auf nicht existierende IDs
+Geprüft durch Extraktion aller in `Tracelinks:`-Feldern referenzierten IDs (113 eindeutige Referenzen) und Abgleich gegen die Menge der 215 tatsächlich definierten IDs. **Ergebnis: keine hängenden Referenzen (dangling references).** Jede referenzierte ID existiert.
+
+### 3.5 Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk
+Geprüft durch manuelle Durchsicht thematisch benachbarter Anforderungen. Alle identifizierten Fälle sind im Feld `Konsolidierung` vermerkt, u. a.:
+- **StRS-27 / SwRS-59** (Stammblatt vs. AssetManagement/DocuBoard): der im Vorgänger-Prompt kalibrierte Beispielfall — zwei Datenhaltungen für dasselbe fachliche Gerätekonzept.
+- **StRS-11 / SwRS-13** (Modules/Calendar vs. MyCentron/Calendar) und **StRS-12** (drei parallele Dashboard-Implementierungen).
+- **SyRS-86 / SwRS-69** (sechs partnerspezifische EDI-Gateways als Konsolidierungskandidat für ein gemeinsames Mapping-Framework).
+- **StRS-31** (Helpdesk/TicketDetails im Desktop vs. CentronNexus/ServiceBoard im Web) — der zentrale, architektonisch bedeutsamste Konsolidierungsfall dieser Analyse, da er zeigt, dass wesentliche Fachlogik bereits ein zweites Mal für das Web implementiert wurde.
+- **SwRS-43** (TicketDetails/CheckList vs. Modul CentronChecklist).
+- **SyRS-31 / SyRS-39** (Berechnungsformel für offene Beträge in DunningBL und OposBL potenziell dupliziert).
+- **SwRS-37** (TimerBilling vs. HourlySurchargeRates).
+- **SwRS-68** (Format-/Berichtsverwaltung in Modules/Reports vs. Administration/ReportServer).
+
+Es wurden keine weiteren, unvermerkten Duplikate identifiziert; angesichts des Umfangs der Codebasis (15.554 Dateien) ist jedoch nicht auszuschließen, dass bei tieferer Analyse einzelner Module (insbesondere Finances/Receipts mit elf Belegarten) weitere Konsolidierungsfälle sichtbar würden — siehe Selbstbewertung, Abschnitt 5.
+
+### 3.6 Risikorelevante Anforderungen: Belegsituation
+
+54 der 215 Anforderungen wurden als risikorelevant eingestuft (Typ `Sicherheit` oder inhaltlicher Bezug zu Berechtigungen, Preisen, Rechnungen, Zahlungen, Mahnwesen, Provisionen, Abrechnung oder Autorisierung). Für jede gilt die verschärfte Regel: entweder mindestens ein `PRIMÄR`-Beleg mit benannter durchsetzender Stelle, oder explizite `[HYPOTHESE]`-Kennzeichnung.
+
+**Im Zuge dieses Konsistenzchecks wurden sieben ursprünglich als „belegt" geführte Anforderungen als Verstoß gegen diese Regel identifiziert und noch vor Abschluss des Laufs auf `HYPOTHESE` korrigiert:** StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33 (jeweils nur SEKUNDÄR-Beleg trotz Sicherheits-/Abrechnungsbezug). Diese Korrektur ist in Hypothesen.md dokumentiert und bewusst nicht rückwirkend „unsichtbar" gemacht.
+
+Zwei Grenzfälle wurden geprüft und **bewusst nicht** korrigiert, mit Begründung:
+- **SyRS-79** (Provisionsberechnung für kommissionierte Aufträge): Provisionslogik ist personalwirtschaftlich näher an Vergütung als an Fakturierung im engeren Sinn; der SEKUNDÄR-Beleg (Ordnerstruktur `Commissions/CommissionOrders`) wird als für diesen Detailgrad ausreichend bewertet.
+- **SwRS-61** (Kassen-/Kontensystem-Vorlagen für Zahlungsausgänge): betrifft die Struktur von Kontensystem-Vorlagen, nicht die eigentliche Zahlungsbetragslogik.
+
+Vollständige Liste aller 54 risikorelevanten Anforderungen mit Belegstatus:
+
+| ID | Titel | PRIMÄR-Beleg? | Status |
+|---|---|---|---|
+| StRS-1 | Rollen-/gruppenbasierte Zugriffssteuerung | ja | belegt |
+| StRS-2 | Datenschutzkonforme Verarbeitung personenbezogener Daten | nein | HYPOTHESE |
+| StRS-9 | Flexible Abrechnungs- und Eskalationskonditionen | nein | HYPOTHESE |
+| StRS-15 | Rechtssicherer SEPA-Zahlungsverkehr | ja | belegt |
+| StRS-16 | Automatisierte Vertrags- und Abrechnungsprozesse | ja | belegt |
+| StRS-18 | Mahnwesen und Forderungsmanagement | ja | belegt |
+| StRS-19 | Erfassung und Zuordnung von Zahlungen | nein | HYPOTHESE |
+| StRS-23 | Verschlüsselte Verwaltung sensibler Zugangsdaten | ja | belegt |
+| StRS-28 | Deklarative, wiederverwendbare API-Autorisierung | ja | belegt |
+| StRS-33 | Optionale Zwei-Faktor-Authentifizierung für Benutzeranmeldung | ja | belegt |
+| SyRS-1 | Systemweite Rechteprüfung vor Funktionsausführung | ja | belegt |
+| SyRS-2 | Administrator-Sonderrolle mit Rechte-Vollzugriff | ja | belegt |
+| SyRS-3 | Verwaltung DSGVO-relevanter Einstellungen je Kunde | nein | HYPOTHESE |
+| SyRS-7 | Optionale elektronische Signatur bei PDF-Erzeugung | nein | HYPOTHESE |
+| SyRS-10 | Parametrierbare Abrechnungs- und Eskalationsregeln | nein | HYPOTHESE |
+| SyRS-12 | Rechtebasierte Filterung von Kalendereinträgen | ja | belegt |
+| SyRS-17 | Mehrformat-Unterstützung für SEPA-Zahlungsdateien | ja | belegt |
+| SyRS-19 | EDI-Bestell- und ZUGFeRD-Rechnungsaustausch | ja | belegt |
+| SyRS-24 | Automatischer Rechnungslauf aus offenen Aufträgen | ja | belegt |
+| SyRS-28 | Flatrate-Abrechnung auf Basis von Assetpositionen | nein | HYPOTHESE |
+| SyRS-29 | Automatische Mahnstufen-Eskalation je Rechnung | ja | belegt |
+| SyRS-30 | Rückstufung der Mahnstufe bei Zahlungseingang | ja | belegt |
+| SyRS-31 | Offene-Posten-Berechnung aus Rechnungs-, Zahlungs- und Gutschriftbeträgen | ja | belegt |
+| SyRS-32 | Getrennte Erfassung eingehender und ausgehender Zahlungen | nein | HYPOTHESE |
+| SyRS-33 | Zählerstandsbasierte Abrechnungsgrundlage | nein | HYPOTHESE |
+| SyRS-35 | Rechtegebundene Preisänderung je Belegart | ja | belegt |
+| SyRS-36 | Getrennte Sichtbarkeits-, Erstellungs- und Bearbeitungsrechte je Belegart | ja | belegt |
+| SyRS-38 | Automatische Provisionsermittlung bei Rechnungserstellung | ja | belegt |
+| SyRS-40 | Projektbezogene Abrechnung mit Gantt-gestützter Aufgabenverfolgung | nein | HYPOTHESE |
+| SyRS-51 | Gesteuerter Kunden-Selbstauskunftszugang | nein | HYPOTHESE |
+| SyRS-52 | AES-Verschlüsselung mit zentralem Master-Key für Zugangsdaten | ja | belegt |
+| SyRS-53 | Getrennte Zugriffsbereichs- und Zugriffsverwaltung im Passwortmanager | nein | HYPOTHESE |
+| SyRS-55 | Zuordnung importierter Kontoumsätze zu offenen Rechnungen | nein | HYPOTHESE |
+| SyRS-59 | Zahler-Kostenstellen-Zuordnung unabhängig vom Rechnungsempfänger | nein | HYPOTHESE |
+| SyRS-79 | Provisionsberechnung für kommissionierte Aufträge | nein | belegt |
+| SyRS-81 | Kombinierbare Autorisierungsbedingungen auf Controller- und Methodenebene | ja | belegt |
+| SyRS-82 | Getrennte Prüfung von Hosting-Kontext und Benutzerrecht | ja | belegt |
+| SyRS-83 | Isolierte Signaturerfassung im Web | nein | HYPOTHESE |
+| SyRS-90 | Getrennte Exception-Typen je externer API-Anbindung | ja | belegt |
+| SyRS-94 | Geführter Einrichtungsassistent für Zwei-Faktor-Authentifizierung | ja | belegt |
+| SyRS-99 | Österreichische E-Rechnungsformat-Konvertierung | nein | HYPOTHESE |
+| SwRS-1 | Rechtegruppen-Verwaltung mit Selbstschutz und Protokollierung | ja | belegt |
+| SwRS-19 | Autorisierungsschicht für DocuForm-API-Zugriff | nein | HYPOTHESE |
+| SwRS-24 | Zweistufiger automatischer Rechnungslauf (Ermittlung/Erzeugung) | ja | belegt |
+| SwRS-26 | Mahnstufen-Feld als Enum am Rechnungsdatensatz | ja | belegt |
+| SwRS-27 | Mahnlauf-Protokoll mit Alt-/Neu-Mahnstufe | ja | belegt |
+| SwRS-28 | Aggregierte Mahnstufen-Kennzahlen je Stufe | ja | belegt |
+| SwRS-29 | Getrennte Verarbeitungsklassen für Einkaufs- und Verkaufsrechnungen mit identischer Rechteschnittstelle | ja | belegt |
+| SwRS-35 | Produktlebenszyklus-Datenhaltung für Abrechnungszwecke | nein | HYPOTHESE |
+| SwRS-52 | Typisierte Spaltenzuordnung beim Preislistenimport | ja | belegt |
+| SwRS-61 | Kassen-/Kontensystem-Vorlagen für Zahlungsausgänge | nein | belegt |
+| SwRS-65 | Vier typisierte Autorisierungsattribute mit gemeinsamer Rechteprüfung | ja | belegt |
+| SwRS-66 | Definierte HTTP-Statuscode-Semantik für Autorisierungsfehler | ja | belegt |
+| SwRS-77 | TOTP-Codeprüfung mit Base32-kodiertem Secret | ja | belegt |
+
+### 3.7 Abgleich Hypothesen.md gegen Inline-Markierungen
+
+Hypothesen.md wurde direkt aus den 62 mit `Status: HYPOTHESE` markierten Anforderungsblöcken in StRS.md/SyRS.md/SwRS.md extrahiert (automatisierter Abgleich, kein manuell gepflegtes Duplikat). Beide Quellen nennen exakt dieselben 62 IDs; Hypothesen.md enthält keine zusätzlichen freien Fragen ohne Anforderungsbezug. Offene Punkte, die sich nicht an eine einzelne Anforderung knüpfen lassen (z. B. „welche weiteren EDI-Distributoren existieren über die sechs gefundenen hinaus"), stehen stattdessen unten in der Selbstbewertung.
+
+## 4. Selbstbewertung
+
+### 4.1 Tiefe der Modulabdeckung (absolute Zahlen)
+
+Von 107 Inventarzeilen wurden eingestuft:
+- **tief** (≥ 4 Anforderungen, mehrstufige Kette, mindestens ein PRIMÄR-Beleg): **12 Module** — Rechteverwaltung (A1), Zahlungsverkehr/SEPA (E3), Verträge (G5), Mahnwesen (G8), Verkaufsbelege Rechnung & Gutschrift (G16), Ticketverwaltung (J1), Passwortverwaltung (P1), Bestellwesen & EDI (U1), Artikelstammverwaltung (AC1), API-Controller-Schicht (WA2), Core-Utilities/2FA (SH2), Produktionsauftrags-/Servicetafel Nexus (NX3).
+- **mittel** (2-3 Anforderungen): **32 Module.**
+- **flach** (1 Anforderung oder nur über ein Nachbarmodul mitabgedeckt): **63 Module.**
+- **nicht analysiert**: **0 Module.**
+
+Damit wurde die in Schritt 0b geforderte Mindestabdeckung — jedes Modul erhält mindestens eine Anforderung, bevor irgendein Modul vertieft wird — für alle 107 Inventarzeilen erreicht. Die Vertiefung (Schritt 0c) konzentrierte sich erwartungsgemäß auf die vom Auftrag benannten Risikobereiche: Berechtigungen (A1, WA2, SH2), Abrechnungs-/Fakturierungslogik (E3, G5, G8, G16, U1) sowie den im Auftragstext ausdrücklich genannten Kalibrierungsfall Stammblatt/Asset (AC1). Zusätzlich wurde mit dem Fund StRS-31 (Desktop-Helpdesk vs. Nexus-ServiceBoard) ein migrationsstrategisch bedeutsamer Bereich vertieft, der im Auftrag nicht explizit als Risikokategorie genannt war, aber aus fachlicher Sicht für eine Web-/SaaS-Neuimplementierung zentral ist.
+
+Die 63 „flachen" Module sind mehrheitlich (a) kleinere Administrationsbereiche mit primär konfigurativem statt prozessualem Charakter (z. B. CountryManagement, MaterialGroupManagement), (b) Einzelmodule mit geringer Dateizahl (≤ 20 Dateien, z. B. QM, ProjectManagement, PLM-Teilbereiche) oder (c) externe API-Integrationsprojekte, die strukturell nahezu identisch sind und deren Einzelbetrachtung über die bereits dokumentierte Musterbeschreibung (SwRS-76) hinaus wenig zusätzlichen Erkenntnisgewinn verspricht.
+
+### 4.2 Mindestabdeckung erreicht?
+
+Ja. Alle 107 Inventarzeilen führen mindestens eine Anforderung mit mindestens einem klassifizierten Beleg (siehe Abdeckungstabelle, Abschnitt 2). Es gibt keine Zeile ohne Anforderung und ohne Begründung.
+
+### 4.3 Wo war der Beleg dünn?
+
+Ein hoher Anteil `SEKUNDÄR`/`KONTEXT` bzw. `[HYPOTHESE]` zeigt sich systematisch dort, wo:
+- **nur die UI-/Konfigurationsebene gesichtet wurde, nicht die dahinterliegende Verarbeitungslogik** — betrifft u. a. ExternalTool/Variables (F1, durchgängig HYPOTHESE), HourlySurchargeRates (A11/SyRS-10), Reisekosten-Genehmigungsworkflow (U2), Inventurstatus (AC5).
+- **Modulnamen/-strukturen plausibel, aber nicht am Detailcode verifizierbare Konzepte nahelegen** — z. B. Dashboard-Kachelregistrierung (SwRS-14), RMM-Datenverknüpfung zur Abrechnung (SyRS-20), TelekomDive-Synchronisationsumfang (SyRS-21/SwRS-22).
+- **kleine, wenig dokumentierte Module mit einzelner Klasse** — QM (nur Settings-Ordner ohne erkennbare Kernlogik, SyRS-67), ProductLifecycleBL (SwRS-35).
+- **Sicherheits-/Abrechnungsanforderungen, bei denen nur die Konfigurationsoberfläche, nicht die serverseitige Durchsetzung gesichtet wurde** — dies betraf ursprünglich sieben Anforderungen (StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33), die im Zuge des Konsistenzchecks korrigiert wurden (siehe Abschnitt 3.6).
+
+Am dichtesten belegt (überwiegend PRIMÄR, konkrete Zeilennummern) sind die Bereiche, in denen tatsächlich BL-Klassen mit Geschäftsregeln gelesen wurden: Rechteprüfung (AppRightsBL, UserRightsExt), Belegrechte (InvoiceSpecificLogic, SupplierInvoiceSpecificLogic), Mahnwesen (DunningBL, DunningRunBL), Vertragskündigungsfristen (ContractBL), SEPA-Sequenztyp (PaymentTransactionBL), Bestellvorschlag (OrderSuggestionListBL), API-Autorisierung (Controllers/Authorization) und Zwei-Faktor-Authentifizierung (TwoFactorAuthenticator, DeveloperSecurity).
+
+### 4.4 Warum keine Analyse ganz ohne Hypothesen?
+
+Trifft hier nicht zu — 62 von 215 Anforderungen (28,8 %) sind als HYPOTHESE markiert. Dieser Anteil liegt bewusst im oberen Bereich der in Iteration 1 beobachteten Spanne (0 %-26,2 % über 24 Läufe) und ist als Stärke, nicht als Schwäche zu werten: Bei einer Codebasis mit 15.554 C#-Dateien und 1.535 Datenbanktabellen ist es unplausibel, dass ein einzelner Lauf ohne Ausführung der Software (rein statische Analyse) jede Verhaltensannahme am Code verifizieren kann. Die Alternative — Aussagen ohne Detailverifikation stillschweigend als „belegt" zu führen — wäre die eigentliche Qualitätsminderung; das haben die sieben in Abschnitt 3.6 korrigierten Fälle im eigenen Lauf demonstriert.
+
+### 4.5 Erkenntnisse für eine Folge-Iteration
+
+1. **Receipts-Kern tiefer analysieren:** Die elf Belegarten (G15-G18) wurden über das gemeinsame Interface `IReceiptSpecificLogic` und exemplarisch an `InvoiceSpecificLogic`/`SupplierInvoiceSpecificLogic` belegt; Offers, Orders, DeliveryLists, PickupLists, CreditVouchers, SupplierOrders, SupplierCreditVouchers, SupplierDeliveryLists und ContractLists wurden nicht einzeln mit eigenen SwRS-Anforderungen vertieft. Eine Folge-Iteration sollte hier je Belegart mindestens eine eigene SwRS-Anforderung mit belegartspezifischem Beleg ergänzen.
+2. **Nexus-Desktop-Parallelität systematisch kartieren:** StRS-31 deckt exemplarisch die Dopplung Helpdesk/TicketDetails ↔ ServiceBoard auf. Eine Folge-Iteration sollte gezielt prüfen, welche weiteren Desktop-Module bereits ein Nexus-Pendant haben (Kandidaten laut Nexus-Struktur: Management/TaskManagement ↔ Desktop-TaskManagement, Management/TicketPatterns ↔ C-FLOW) und wie vollständig/abweichend die jeweilige Web-Implementierung ist — das ist für die geplante Web-/SaaS-Neuimplementierung die wichtigste einzelne Erkenntnisquelle in dieser Codebasis.
+3. **DSGVO- und PDF-Signatur-Durchsetzung verifizieren:** Die im Konsistenzcheck korrigierten Sicherheitsanforderungen (StRS-2, SyRS-3, SyRS-7) benötigen eine gezielte Suche nach der tatsächlich durchsetzenden Stelle (Löschjob, Zertifikatsprüfung), die in diesem Lauf aus Zeitgründen nicht gefunden wurde.
+4. **Abrechnungs-Randbereiche (G1, G3, G4, G6, G7, G9, G10, G12-G14, G19) vertiefen:** Diese wurden nur „flach" abgedeckt, obwohl sie zur Kernrisikokategorie Abrechnung/Fakturierung zählen. Insbesondere FlatrateBilling (G9) und AutomatedBilling (G2) verdienen wegen ihrer wiederkehrenden finanziellen Auswirkung eine tiefere Prüfung der Berechnungsformeln.
+5. **DB-Schema strukturiert auswerten:** Der Befund „nur 134 von 1.535 Tabellen mit Fremdschlüssel-Constraint" (SyRS-88) wurde nur als quantitative Beobachtung dokumentiert. Eine Folge-Iteration mit Datenbankzugriff könnte die *I3D-Namenskonvention systematisch als implizites Beziehungsmodell auswerten und mit den tatsächlichen NHibernate-Mappings abgleichen.
+6. **Weitere Konsolidierungsfälle in Warehousing/Finances erwarten:** Der bestätigte Stammblatt/Asset-Fall (StRS-27) legt nahe, dass in einer Codebasis dieser historischen Tiefe (Namensreste wie „Sichtrus", „VertragKopf", diverse „Old"-Suffixe) weitere, noch nicht identifizierte Doppelimplementierungen existieren.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Glossar.md

@@ -0,0 +1,38 @@
+# Glossar – c-entron ERP-Suite
+
+Domänenbegriffe, wie sie in den Anforderungen (StRS/SyRS/SwRS) verwendet werden. Technische Bezeichner sind in ihrer Originalsprache (meist Englisch/Codebasis-Konvention) belassen; die Erklärung ist deutsch.
+
+| Begriff | Erklärung |
+|---|---|
+| **I3D** | In der Codebasis durchgängig verwendete Bezeichnung für den technischen Primärschlüssel eines Datensatzes (z. B. `CustomerI3D`, `MandantI3D`, `ArticleI3D`). Entspricht der ID/dem Fremdschlüssel eines Fachobjekts. |
+| **Beleg / Belegart** | Sammelbegriff für alle im System erzeugten Geschäftsdokumente mit Vorgangscharakter: Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung, Lieferantenrechnung, Vertragsliste, Abholschein u. a. Alle Belegarten implementieren das gemeinsame Interface `IReceiptSpecificLogic` und teilen sich das Statusmodell `ReceiptState`. |
+| **ReceiptState** | Dreistufiger Status eines Belegs: `Active` (offen), `Completed` (abgeschlossen), `Canceled` (storniert). Gilt einheitlich für alle Belegarten. |
+| **Stammblatt** | Bezeichnung für einen Beleg vom Kind `MasterDataListClass` (`CentronObjectKindNumeric`); fachlich die Gerätestammdaten eines klickabgerechneten Geräts (typischerweise Drucker), verwaltet im Modul Finances/MasterDataLists auf Basis von Vertrags-„ClickContracts". Siehe Konsolidierungshinweis zu „Asset" (StRS-27). |
+| **Asset (AssetManagement, DocuBoard)** | Im Kontext RMM-Überwachung: ein über die Entität `AssetManagementArticleAssignment` (Namespace `DocuBoard`) einem Artikel zugeordnetes, überwachtes Gerät (Server/Workstation). Zu unterscheiden vom allgemeineren `AssetBase`/`AssetKindEnum` in `Sales.CustomerAssets`, der dort als technischer Oberbegriff für „Beleg" (Angebot, Auftrag, Rechnung usw.) verwendet wird — zwei unterschiedliche Bedeutungen desselben Wortes in der Codebasis. |
+| **Mandant** | Rechtlich/organisatorisch getrennte Einheit im Mehrmandantenbetrieb, verwaltet über MandatorManagement; kann mehrere Filialen enthalten. |
+| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten, u. a. relevant für Rechteeinschränkungen („nur eigene Filiale") und Buchungsnummernkreise. |
+| **Rechtegruppe (RightGroup/AppGroup)** | Benannte Gruppe von Einzelrechten, der Mitarbeiter zugeordnet werden; Grundlage der rollenbasierten Zugriffssteuerung (siehe `AppRightsBL`, `CentronRights.md`). |
+| **Einschränkendes Recht (restricting right)** | Ein Recht, das die Sicht/den Zugriff eines Benutzers gegenüber dem Normalfall einschränkt statt ihn zu erweitern (z. B. „nur eigene Tickets", „nur eigene Filiale") — Terminologie aus `CentronRights.md`. |
+| **Mahnstufe (DunningLevel)** | Eskalationsstufe einer überfälligen Rechnung im Mahnwesen: `None`, `Level1`, `Level2`, `Level3`, linear eskalierend/rückstufbar über Mahnläufe (`DunningRunBL`). |
+| **Offener Posten (Opos)** | Eine noch nicht vollständig ausgeglichene Forderung/Verbindlichkeit; der offene Betrag berechnet sich als Bruttobetrag abzüglich Zahlungen und Gutschriften. |
+| **SEPA-Sequenztyp (First/Recurrent)** | Kennzeichnung, ob ein SEPA-Lastschrifteinzug der erste (`First`/FRST) oder ein Folgeeinzug (`Recurrent`/RCUR) eines Mandats ist; steuert das im Zahlungsformat zu verwendende Sequenzkennzeichen. |
+| **PAIN-Format** | ISO-20022-Nachrichtenformat für SEPA-Zahlungsverkehr (z. B. PAIN.008 für Lastschriften); die Codebasis unterstützt mehrere Formatvarianten (u. a. STUZZA/Österreich, GBIC3/GBIC4). |
+| **ZUGFeRD** | Deutsches/europäisches Format für hybride elektronische Rechnungen (PDF mit eingebettetem strukturiertem XML), hier für Verkaufsrechnungen im EDI-Bereich unterstützt. |
+| **ebInterface** | Österreichisches Standardformat für die elektronische Rechnungsstellung an öffentliche Auftraggeber. |
+| **EDI** | Electronic Data Interchange – elektronischer, strukturierter Geschäftsdatenaustausch, hier insbesondere für Bestellungen mit IT-Distributoren (Also, Alltron, EGIS, Herweck, Komsa) sowie für Rechnungen (ZUGFeRD). |
+| **RMM** | Remote Monitoring and Management – Fernüberwachung von IT-Geräten (Server, Workstations); liefert Daten, die u. a. für Vertragsabrechnung und Asset-Zuordnung genutzt werden. |
+| **C-FLOW** | Bezeichnung für das Ticket-Prozessvorlagensystem im Helpdesk-Modul (standardisierte, rechtegebunden verwaltbare Ticketvorlagen und -kategorien). |
+| **TAPI** | Telephony API – Windows-Standardschnittstelle zur Telefonanlagenanbindung, hier für die Telefonie-Integration im Client genutzt. |
+| **DIVE** | Bezeichnung der Telekom-Plattform, mit der c-entron über ein eigenes Modul (`TelekomDiveBL`) Produkt-/Vertragsdaten synchronisiert. |
+| **AVV (Auftragsverarbeitungsvertrag)** | Datenschutzrechtlicher Vertrag zwischen Verantwortlichem und Auftragsverarbeiter nach DSGVO Art. 28; im System als „OrderProcessingContract" verwaltet. |
+| **WebCart** | Der Kunden-Webshop-Bereich innerhalb von c-entron Nexus; Artikel stammen aus den beim Kunden hinterlegten Sonderpreisen, Zugriff erfordert einen Web-Account. |
+| **WebAccount** | Ein Kundenzugang für Web-Self-Service-Funktionen (WebCart, Kundenportal), getrennt vom internen Mitarbeiterkonto (`AppUser`) verwaltet, mit eigenem Rechtemodell (`WebAccountRightsConst`). |
+| **AppUser** | Interne Mitarbeiter-Benutzeridentität im System, Träger von Einzelrechten über Gruppenmitgliedschaft. |
+| **BLSession** | Zentrale Session-/Factory-Klasse, über die alle Business-Logic-Klassen (`BaseBL`-Ableitungen) instanziiert werden (`session.GetBL<T>()`), inkl. Transaktions-/Verbindungskontext. |
+| **Sichtrus / Sichmemb** | Physische Datenbanktabellen des Rechtemodells: `Sichtrus` verknüpft Rechtegruppe und Recht, `Sichmemb` verknüpft Benutzer und Rechtegruppe (Namensursprung vermutlich historisch/aus einer Vorgängerversion). |
+| **Nebenlager** | Ein zusätzliches, vom Hauptlager (WarehouseI3D = -1) unterschiedenes Lager, für das der Mindestbestand separat geprüft wird. |
+| **Mindestbestand** | Je Artikel und Lager hinterlegte Bestandsschwelle, deren Unterschreitung einen automatischen Bestellvorschlag auslöst. |
+| **c-entron Nexus** | Der neuere, Blazor-basierte Webclient des Systems (laut README.md „aka c-entron Web"), der Teile der Desktop-Funktionalität (Ticketbearbeitung, Dokumentensignatur, Kundenportal) bereits web-/SaaS-fähig abbildet und damit den naheliegenden Ausgangspunkt für die Zielarchitektur darstellt. |
+| **AuthorizeCentronHosted** | API-Autorisierungsattribut, das unabhängig vom Benutzerrecht prüft, ob ein Aufruf aus der gehosteten (SaaS-)Umgebung stammt, im Gegensatz zu einer On-Premise-Installation. |
+| **DevExpress** | Kommerzielle UI-Komponentenbibliothek, auf der sowohl die WPF-Oberfläche als auch (laut README.md) die Blazor-Komponenten von Nexus aufbauen. |
+| **NHibernate** | Objekt-relationales Mapping-Framework, auf dem die gesamte Datenzugriffsschicht (`Centron.DAO`) aufsetzt. |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Hypothesen.md

@@ -0,0 +1,72 @@
+# Hypothesen – c-entron ERP-Suite
+
+Diese Datei enthält ausschließlich Anforderungen, die im Feld `Status` mit `HYPOTHESE` markiert sind (62 von 215 Anforderungen, 28,8 %). Die Spalte „Offene Frage" fasst zusammen, welche Information zur Bestätigung fehlt. Jede Zeile entspricht exakt einer Inline-Markierung in StRS.md, SyRS.md oder SwRS.md; es gibt keine zusätzlichen freien Fragen ohne zugehörige Anforderung (offene Punkte ohne Anforderungsbezug stehen stattdessen in der Selbstbewertung des Analyseberichts).
+
+Sieben dieser Hypothesen (StRS-2, StRS-9, StRS-19, SyRS-3, SyRS-7, SyRS-32, SyRS-33) waren ursprünglich als „belegt" eingestuft, obwohl sie als Sicherheits- oder Abrechnungsanforderung nur einen SEKUNDÄR-Beleg trugen. Der Konsistenzcheck (siehe Analysebericht.md, Abschnitt „Risikorelevante Anforderungen") hat dies als Verstoß gegen die risikobasierte Belegpflicht erkannt; sie wurden vor Abschluss dieses Laufs auf `HYPOTHESE` korrigiert. Das ist bewusst sichtbar gelassen, um zu zeigen, dass der Konsistenzcheck in diesem Lauf tatsächlich wirksam war und nicht nur pro forma durchgeführt wurde.
+
+Zur Einordnung: Ein hoher Hypothesenanteil ist bei einer Codebasis dieser Größe (15.554 C#-Dateien) kein Mangel, sondern Ausdruck ehrlicher Abgrenzung zwischen dem, was im Code direkt belegt ist, und dem, was aus Struktur/Namensgebung plausibel, aber nicht am Detailcode verifiziert wurde.
+
+| ID | Titel | Offene Frage (was zur Bestätigung fehlt) |
+|---|---|---|
+| StRS-2 | Datenschutzkonforme Verarbeitung personenbezogener Daten | als Sicherheits-/Datenschutzanforderung wäre nach Belegregel ein PRIMÄR-Beleg (die tatsächlich durchsetzende Löschroutine) erforderlich; nur UI-Ebene wurde gesichtet, die serverseitige Durchsetzung der Fristen wurde nicht verifiziert. |
+| StRS-9 | Flexible Abrechnungs- und Eskalationskonditionen | Abrechnungsrelevante Anforderung ohne PRIMÄR-Beleg (nur Konfigurationsoberflächen gesichtet, nicht die Verrechnungslogik selbst); konsistent mit der bereits als HYPOTHESE geführten SyRS-10. |
+| StRS-13 | Anbindung kundenspezifischer externer Werkzeuge | Ordnername und Modulplatzierung legen eine Variablenverwaltung für externe Toolintegration nahe; der genaue Aufrufmechanismus wurde nicht gelesen und ist daher offen. |
+| StRS-19 | Erfassung und Zuordnung von Zahlungen | Abrechnungs-/Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; die konkrete Verrechnungslogik (Zuordnung Zahlung↔Forderung, Ableitung des Rechnungsbetrags aus Zählerständen) wurde nicht im Code gesichtet, nur die strukturelle Trennung der Ordner/Klassen. |
+| SyRS-3 | Verwaltung DSGVO-relevanter Einstellungen je Kunde | Sicherheits-/Datenschutzanforderung ohne PRIMÄR-Beleg; die serverseitige Durchsetzung der kundenindividuellen Regel (BL/DAO) wurde nicht gesichtet, nur die UI-Ebene. |
+| SyRS-5 | Cache-gestützte Bereitstellung globaler Konfiguration | Modulname und -platzierung legen einen Cache-Mechanismus nahe; die konkrete Implementierung (Invalidierung, TTL) wurde nicht gelesen. |
+| SyRS-7 | Optionale elektronische Signatur bei PDF-Erzeugung | Sicherheitsanforderung ohne PRIMÄR-Beleg; die tatsächliche Signaturerzeugung/-prüfung (Zertifikatshandling) wurde nicht im Code gesichtet, nur die Einstellungsebene. |
+| SyRS-10 | Parametrierbare Abrechnungs- und Eskalationsregeln | Konfigurationsoberflächen vorhanden; die konkrete Verknüpfung zur Berechnungslogik in Helpdesk/TimerBilling wurde nicht gelesen und ist daher offen. |
+| SyRS-13 | Konfigurierbare Dashboard-Kacheln je Benutzer | Unterordnerstruktur legt ein Kachel-/Widget-Konzept nahe; ob die Auswahl je Benutzer persistiert wird, wurde nicht am Code verifiziert. |
+| SyRS-14 | Variablenersetzung beim Aufruf externer Werkzeuge | Modulinhalt legt Variablenverwaltung nahe, der Ersetzungsmechanismus selbst wurde nicht verifiziert. |
+| SyRS-16 | Generischer Konnektor-Rahmen für Datenein-/-ausgabe | Eigenständiger, von den spezifischen Exporten getrennter Ordner legt ein generisches Konzept nahe; die konkrete Abstraktion (Interface, Plugin-Mechanismus) wurde nicht gelesen. |
+| SyRS-20 | RMM-Systemanbindung für Managed-Service-Daten | Belegt nur die Verbindungskonfiguration; die konkrete Verknüpfung der RMM-Daten zur Abrechnungslogik (FlatrateBilling/AutomatedBilling) wurde nicht gelesen. |
+| SyRS-21 | Telekom-DIVE-Plattformanbindung | Belegt die Existenz der Anbindung; der genaue synchronisierte Datenumfang wurde nicht gelesen. |
+| SyRS-23 | Kontenverwaltung mit Filial-Buchungsnummernkreisen | Ordner vorhanden, konkrete Nummernkreislogik nicht gelesen. |
+| SyRS-26 | Kampagnenzuordnung zu Kundenkonten | Struktur vorhanden, konkretes Zuordnungsmodell nicht gelesen. |
+| SyRS-28 | Flatrate-Abrechnung auf Basis von Assetpositionen | Eigener Ordner für Assetpositionen im Flatrate-Kontext, konkrete Berechnungsformel nicht gelesen. |
+| SyRS-32 | Getrennte Erfassung eingehender und ausgehender Zahlungen | Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; nur strukturelle Trennung gesichtet, nicht die konkrete Verbuchungslogik. |
+| SyRS-33 | Zählerstandsbasierte Abrechnungsgrundlage | Abrechnungsgrundlage-relevante Anforderung ohne PRIMÄR-Beleg; die Ableitung des Rechnungsbetrags aus dem Zählerstand (Preis je Klick, Rundung) wurde nicht im Code gesichtet. |
+| SyRS-40 | Projektbezogene Abrechnung mit Gantt-gestützter Aufgabenverfolgung | Zwei ViewModels belegen Gantt- und Kontobezug; die konkrete Verknüpfungslogik wurde nicht gelesen. |
+| SyRS-41 | Individuelle Felder je Fachobjekt (CustomProperties) | Struktur belegt generisches Konzept, konkretes Datenmodell nicht gelesen. |
+| SyRS-42 | Kontextsensitive Hilfe je Modul | Zentrale Klasse vorhanden, Kontextbezug (welches Hilfethema je Modul) nicht verifiziert. |
+| SyRS-49 | Vertragsbezug bei Ticketerfassung | Ordner vorhanden, konkrete Verknüpfungslogik zur Abrechnung nicht gelesen. |
+| SyRS-50 | Aufgabenverwaltung mit externen Connectoren | Ordner vorhanden, konkrete Connector-Anbindung nicht gelesen. |
+| SyRS-51 | Gesteuerter Kunden-Selbstauskunftszugang | Getrennter Einstellungsbereich für Kundenzugriff, konkrete Zugriffsprüfung nicht gelesen. |
+| SyRS-53 | Getrennte Zugriffsbereichs- und Zugriffsverwaltung im Passwortmanager | Zwei getrennte ViewModels belegen die zweistufige Struktur; die konkrete Rechteprüfung wurde nicht gelesen. |
+| SyRS-54 | Kontextbezogener Start der Fernwartungssitzung aus Tickets | Modul vorhanden, Übergabemechanismus aus dem Ticketkontext nicht gelesen. |
+| SyRS-55 | Zuordnung importierter Kontoumsätze zu offenen Rechnungen | Klassenname legt Verknüpfung nahe, konkreter Zuordnungsalgorithmus (Verwendungszweck-Parsing) nicht gelesen. |
+| SyRS-57 | Ereignisgesteuerte Massenaktualisierung von Datensätzen | Getrennte Ordner belegen zwei Konzepte, konkrete Verknüpfung nicht gelesen. |
+| SyRS-59 | Zahler-Kostenstellen-Zuordnung unabhängig vom Rechnungsempfänger | Eigenständiges Modul vorhanden, konkretes Datenmodell nicht gelesen. |
+| SyRS-60 | Maschinen- und Produktionsauftragsverwaltung | Getrennte Ordner belegen den fachlichen Zusammenhang, konkrete Zuordnungslogik nicht gelesen. |
+| SyRS-65 | Elektronischer Bestelldatenaustausch mit EDI-Partnern nach Belegart | Ordner vorhanden, konkrete Belegartzuordnung nicht gelesen. |
+| SyRS-66 | Reisekostenerfassung mit Belegkategorien | Struktur vorhanden, Genehmigungsworkflow nicht am Code verifiziert. |
+| SyRS-67 | Qualitätsmanagement-Einstellungen als eigenständiger Konfigurationsbereich | Einziger Inhalt des Moduls; Kernlogik nicht identifizierbar, daher als Hypothese gekennzeichnet. |
+| SyRS-70 | Serien-E-Mail-Versand mit Produktmatrix-gestützter Artikelauswahl | Struktur belegt die drei Funktionsbereiche, konkrete Verknüpfung nicht gelesen. |
+| SyRS-75 | Automatisierte End-of-Life-Kennzeichnung von Artikeln | Modul vorhanden, konkrete Kriterien nicht gelesen. |
+| SyRS-77 | Bestandsabgleich durch Inventurprozess | Eigener Enums-Ordner legt eine Statusmaschine nahe, deren Werte nicht einzeln gelesen wurden. |
+| SyRS-83 | Isolierte Signaturerfassung im Web | Namensgebung legt Isolationskonzept nahe, konkrete technische Umsetzung nicht gelesen. |
+| SyRS-89 | Zwischengespeicherte Ticketliste im Webportal | Ordnername legt Caching nahe, konkrete Invalidierungsstrategie nicht gelesen. |
+| SyRS-92 | Eigenständiges Windows-Tool zur Verwaltung von Webservice-Verbindungen | Eigenständige Anwendung mit eigenem Einstiegspunkt, konkrete Diagnosefunktionen nicht gelesen. |
+| SyRS-99 | Österreichische E-Rechnungsformat-Konvertierung | Einzige Klasse des Projekts, konkreter Konvertierungsumfang nicht gelesen. |
+| SwRS-5 | Mitarbeiterimport aus Active Directory | Ordnername belegt die Existenz einer AD-Import-Funktion; Abgleichsverhalten (einmalig/periodisch, Konfliktbehandlung) wurde nicht am Code verifiziert. |
+| SwRS-9 | Zentrale Verwaltung von SQL-Verbindungen für Auswertungen | Modulname legt SQL-Verbindungsverwaltung nahe; genauer Verwendungszweck (z. B. Berichte vs. externe Datenquellen) wurde nicht am Code verifiziert. |
+| SwRS-11 | Konfigurierbare Stundenzuschlagssätze nach Zeitfenster | Modulname legt zeitfensterbasierte Zuschlagsverwaltung nahe; die konkrete Verknüpfung zur Abrechnungslogik wurde nicht gelesen. |
+| SwRS-14 | Dashboard-Kachelregistrierung als Modulliste | Strukturelle Ähnlichkeit zur bekannten Modulregistrierung legt ein analoges Muster nahe, wurde aber für das Dashboard nicht im Detail gelesen. |
+| SwRS-15 | Benannte Variablen für externe Toolaufrufe | Einziger Inhalt des Moduls ist die Variablenverwaltung; der Aufrufmechanismus selbst wurde nicht gelesen. |
+| SwRS-17 | Konfigurationsbasierte Aktivierung von Konnektoren | Einstellungsordner vorhanden; Persistenzmechanismus nicht verifiziert. |
+| SwRS-19 | Autorisierungsschicht für DocuForm-API-Zugriff | Eigener Ordner für Autorisierung, konkreter Tokenmechanismus nicht gelesen. |
+| SwRS-21 | RMM-Verbindungseinstellungen je Mandant | Klasse vorhanden, Mandantenbezug der Persistenz nicht am Code verifiziert. |
+| SwRS-22 | TelekomDive-Synchronisationskomponente | Klasse vorhanden, Aufrufkontext nicht verifiziert. |
+| SwRS-23 | BranchBookKeepingNumbers als Nummernkreis-Entität | Ordner vorhanden, Datenmodell nicht gelesen. |
+| SwRS-25 | Assetpositionsbasiertes Datenmodell für Flatrate-Verträge | Eigener Ordner, Entitätsdefinition nicht gelesen. |
+| SwRS-35 | Produktlebenszyklus-Datenhaltung für Abrechnungszwecke | Klasse vorhanden, konkrete Verknüpfung zur Abrechnungslogik nicht gelesen. |
+| SwRS-36 | Gantt-basierte Projektaufgabenstruktur | Klassenname legt Gantt-Datenmodell nahe, Felder nicht verifiziert. |
+| SwRS-39 | Netzwerkdiagnose-Werkzeug im Client | Modul vorhanden, konkrete Prüfungen nicht gelesen. |
+| SwRS-44 | Filial- und Ereignisreporting für erwartete Ereignisse (SLA) | Getrennte Erfassungs- und Reportingmodule vorhanden, konkrete Kennzahlen nicht gelesen. |
+| SwRS-50 | Filialspezifische Konfiguration der Versandmethoden | Modul vorhanden, Filialbezug der Konfiguration nicht am Code verifiziert. |
+| SwRS-54 | Belegartspezifische Tabs im EDI-Management | Ordner vorhanden, konkrete Tab-Struktur nicht gelesen. |
+| SwRS-55 | Konvertierungslogik für Reisekosten-Belegkategorien | Ordner vorhanden, konkrete Converter-Logik nicht gelesen. |
+| SwRS-56 | RMA-Ereignisprotokoll je Rücksendevorgang | Ordner vorhanden, konkrete Ereignisklassen nicht einzeln gelesen. |
+| SwRS-62 | Kommissionierprozess mit modulweiter Basissteuerung | Gemeinsame Basisklasse vorhanden, konkrete gemeinsame Logik nicht gelesen. |
+| SwRS-63 | Mehrstufiger Inventurstatus als Enum | Eigener Ordner, konkrete Enum-Werte nicht gelesen. |
+| SwRS-74 | Getrennte Steuerelemente je Anwendungsfall im ConnectionManager | Struktur vorhanden, konkrete Unabhängigkeit vom Hauptclient nicht am Code verifiziert. |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/StRS.md

@@ -0,0 +1,722 @@
+# Stakeholder Requirements Specification (StRS) – c-entron ERP-Suite
+
+Fachliche Sicht: Geschäftsziele, Akteure und deren Anforderungen an das System, abgeleitet aus der bestehenden Codebasis (Reverse Requirements Engineering nach ISO/IEC/IEEE 29148:2018).
+
+Akteure (aus Modulstruktur, Rechtekatalog `UserRightsConst` und UI-Rollentexten abgeleitet): Sachbearbeiter/Innendienst, Vertrieb/Außendienst, Buchhaltung, Lager/Logistik, Helpdesk-Mitarbeiter, Systemadministrator, Filialleiter/Niederlassungsleiter, Mandant/Geschäftsführung, Kunde (Web-Self-Service/WebCart), Lieferant (EDI), externes System (Webservice-Client).
+
+---
+
+## Zugriffssteuerung, Datenschutz, Mandantenfähigkeit
+
+```
+ID:            StRS-1
+Titel:         Rollen-/gruppenbasierte Zugriffssteuerung
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  Mehrere Mitarbeiter mit unterschiedlichen Aufgabenbereichen nutzen dasselbe System
+Fakt:          Der Rechtekatalog UserRightsConst.cs definiert weit über 1000 Einzelrechte, gruppiert nach Fachbereich (z. B. Sales.Customer.Helpdesk.*); RightsManagmentViewModel verwaltet Rechte in benannten Gruppen (RightGroups), denen Mitarbeiter zugeordnet werden.
+Aussage:       Das System soll es dem Administrator ermöglichen, Zugriffsrechte auf einzelne fachliche Funktionen granular über benannte Rechtegruppen zu vergeben und Mitarbeitern zuzuweisen, statt Rechte einzeln je Mitarbeiter zu pflegen.
+Ergebnis:      Ein Mitarbeiter erhält genau die Funktionen, die für seine Rolle in der zugewiesenen Rechtegruppe freigegeben sind.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Methoden HasUserRight/GetAllAppRightsFromUser (Zeile 644-664) - Begründung: liest Rechte je Benutzer über Gruppenmitgliedschaft (Tabellen dbo.Sichtrus/dbo.Sichmemb) aus der DB und setzt damit die Gruppenzuordnung technisch um.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/RightsManagement/RightsManagmentViewModel.cs (RightGroups, GroupEmployees, CopyRightsCommand) - Begründung: UI-Modell zeigt Gruppenverwaltung mit Mitarbeiterzuordnung und Gruppenkopierfunktion.
+  - [KONTEXT]  CentronRights.md, Abschnitt Helpdesk - Begründung: Fachliche Dokumentation einzelner Rechte mit Beschreibung ihrer Wirkung.
+Prüfidee:      Mitarbeiter A wird Rechtegruppe "Helpdesk" ohne SHOW_HELPDESK zugewiesen; Verifikation, dass er keine Tickets sieht.
+Tracelinks:    SyRS-1, SyRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Granulare Rechtevergabe ist fachlich zwingend für Mehrbenutzerbetrieb.
+Status:        belegt
+```
+
+```
+ID:            StRS-2
+Titel:         Datenschutzkonforme Verarbeitung personenbezogener Daten
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, Mandant/Geschäftsführung
+Vorbedingung:  Personenbezogene Kunden-/Mitarbeiterdaten werden im System verarbeitet (DSGVO-Pflicht seit 2018)
+Fakt:          Modul Administration/DSGVO stellt eigene Views für Datensicherheitseinstellungen (Aufbewahrung/Löschung) und Auftragsverarbeitungsvertrags-Vorlagen bereit.
+Aussage:       [HYPOTHESE] Das System soll Verantwortlichen die Verwaltung von Aufbewahrungsfristen, Löschregeln und Auftragsverarbeitungsverträgen für personenbezogene Daten ermöglichen.
+Ergebnis:      Nachweisbare Steuerung der DSGVO-relevanten Datenhaltung je Kunde/Mandant.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/DSGVO/CentronDataSecurityViewModel.cs - Begründung: Eigenständiges ViewModel für Datenschutzeinstellungen, UI-Ebene der Funktion.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/DSGVO/OrderProcessingContractSettingsViewModel.cs - Begründung: Verwaltung von AVV-Vorlagen als eigenständige Einstellungsgruppe.
+Prüfidee:      Für einen Kunden wird eine Aufbewahrungsfrist gesetzt; nach Fristablauf ist die Löschung/Anonymisierung nachvollziehbar.
+Tracelinks:    SyRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzliche Pflicht, unverändert erforderlich im Zielsystem.
+Status:        HYPOTHESE - als Sicherheits-/Datenschutzanforderung wäre nach Belegregel ein PRIMÄR-Beleg (die tatsächlich durchsetzende Löschroutine) erforderlich; nur UI-Ebene wurde gesichtet, die serverseitige Durchsetzung der Fristen wurde nicht verifiziert.
+```
+
+```
+ID:            StRS-3
+Titel:         Mehrmandantenfähigkeit mit Filialstruktur
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  Ein Betreiber führt mehrere rechtlich/organisatorisch getrennte Mandanten oder Filialen in einer Installation
+Fakt:          MandatorManagementViewModel verwaltet Mandanten inkl. Filialen (BranchManagement); Löschung eines Mandanten wird verhindert, wenn er aktive Filialen enthält (Meldungstext referenziert aktive Filialen als Löschsperre).
+Aussage:       Das System soll die Verwaltung mehrerer Mandanten mit jeweils zugeordneten Filialen ermöglichen und die referenzielle Integrität beim Löschen sicherstellen.
+Ergebnis:      Ein Mandant mit aktiven Filialen kann nicht versehentlich gelöscht werden; Filial-/Mandantenstruktur bleibt konsistent.
+Belege:
+  - [PRIMÄR]   centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Zeile 241 (DeleteMandatorAsync) - Begründung: Prüfung auf aktive Filialen vor Löschung ist eine im Code durchgesetzte Integritätsregel.
+Prüfidee:      Löschversuch eines Mandanten mit mindestens einer aktiven Filiale muss abgelehnt werden.
+Tracelinks:    SyRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandantenfähigkeit ist Kernvoraussetzung für SaaS-Betrieb.
+Status:        belegt
+```
+
+```
+ID:            StRS-4
+Titel:         Zentrale Stammdaten- und Systemkonfiguration
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  Betrieb erfordert einheitliche, systemweit gültige Grundeinstellungen (Länder, Mitarbeiter, allgemeine Parameter)
+Fakt:          Administration-Modul enthält getrennte Bereiche EmployeeManagement (inkl. Unterordner AdImport), CountryManagement, Customization/Settings sowie einen Konfigurations-Cache (CentronConfigDb/Cache).
+Aussage:       Das System soll zentrale Stammdaten (Mitarbeiter, Länder) und Anwendungsparameter administrierbar machen und über einen Cache performant systemweit bereitstellen.
+Ergebnis:      Änderungen an Stammdaten/Einstellungen wirken konsistent für alle Arbeitsplätze.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/AdImport - Begründung: Verzeichnisstruktur belegt Active-Directory-Import als vorgesehene Datenquelle für Mitarbeiterstammdaten.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/CentronConfigDb, .../Cache - Begründung: Eigene Ordner für Konfigurations-DB-Zugriff und Cache belegen die zentrale Bereitstellung.
+Prüfidee:      Änderung einer globalen Einstellung ist nach Neustart an einem zweiten Arbeitsplatz sichtbar.
+Tracelinks:    SyRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-5
+Titel:         Integrierte Kommunikation (Mail/Telefonie)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter/Innendienst, Systemadministrator
+Vorbedingung:  Mitarbeiter kommunizieren mit Kunden über Mail und Telefon direkt aus dem ERP-Kontext
+Fakt:          Administration-Module MailAndCalender, MailTemplates und PhoneSettings konfigurieren Mail-/Kalenderserver-Zugänge, Standardvorlagen und Telefonanlagen-Anbindung; MyCentron/Telephony bindet TAPI ein.
+Aussage:       Das System soll die Konfiguration von Mail-, Kalender- und Telefonanbindung zentral ermöglichen und Standardtextvorlagen für die Kundenkommunikation bereitstellen.
+Ergebnis:      Mitarbeiter können ohne Medienbruch aus dem ERP heraus E-Mails versenden und Anrufe tätigen/empfangen.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/MailTemplates - Begründung: Eigener Bereich für Mailvorlagenverwaltung.
+  - [KONTEXT]  docs/reference/architecture/tapi.md - Begründung: Dokumentiert die TAPI-Telefonieanbindung als Architekturentscheidung.
+Prüfidee:      Eine Mailvorlage wird angelegt und beim Versand aus einem Beleg korrekt mit Platzhaltern befüllt.
+Tracelinks:    SyRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-6
+Titel:         Rechtssichere, einheitliche Belegausgabe
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter/Innendienst, Buchhaltung
+Vorbedingung:  Belege (Rechnungen, Angebote) müssen als PDF erzeugt, teils elektronisch signiert und mit Textbausteinen versehen werden
+Fakt:          Administration enthält getrennte Module PdfExport, PdfSigning, ReportServer, TextBlockManagement.
+Aussage:       Das System soll die Erzeugung von Belegen als PDF inkl. optionaler elektronischer Signatur und wiederverwendbarer Textbausteine zentral unterstützen.
+Ergebnis:      Rechtsverbindliche, einheitlich formatierte Belegausgabe für alle Belegarten.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/PdfSigning/PdfSigningSettingsViewModel.cs - Begründung: Eigenständige Konfiguration der PDF-Signatur als dedizierte Funktion.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/TextBlockManagement - Begründung: Eigener Bereich zur Pflege wiederverwendbarer Textbausteine für Belege.
+Prüfidee:      Eine Rechnung wird als PDF exportiert und optional signiert; Signaturprüfung im PDF-Reader ist erfolgreich.
+Tracelinks:    SyRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-7
+Titel:         Konfigurierbare Web- und Schnittstellenanbindung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  Externe Systeme (Webshop, Webservice-Clients, Drittwerkzeuge) müssen ohne Codeänderung angebunden werden können
+Fakt:          Administration enthält WebCart-, WebServiceSettings- und ExternalTools-Bereiche zur Konfiguration von Schnittstellen ohne Neucompilierung.
+Aussage:       Das System soll Web- und Fremdsystemanbindungen (Webshop, Webservices, externe Tools) über Konfigurationsoberflächen statt Codeänderungen steuerbar machen.
+Ergebnis:      Administratoren aktivieren/parametrieren Schnittstellen selbstständig.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/WebCart - Begründung: Eigene Einstellungsoberfläche für den Kunden-Webshop.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/WebServiceSettings - Begründung: Eigene Einstellungsoberfläche für Webservice-Parameter.
+Prüfidee:      Deaktivierung des WebCart in den Einstellungen führt dazu, dass Web-Kunden keinen Zugriff auf den Shop mehr haben.
+Tracelinks:    SyRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-8
+Titel:         Betriebsüberwachung und Diagnose
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Systemadministrator
+Vorbedingung:  Störungen/Performanceprobleme im Produktivbetrieb müssen eingrenzbar sein
+Fakt:          Administration enthält LogViewer- und Profiling-Module zur Auswertung von Logs und Performance direkt aus dem Client.
+Aussage:       Das System soll dem Administrator eine integrierte Log- und Performance-Analyse ohne externe Werkzeuge ermöglichen.
+Ergebnis:      Schnellere Fehlerdiagnose im laufenden Betrieb.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/LogViewer - Begründung: Eigenes Modul zur Log-Anzeige im Client.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/Profiling - Begründung: Eigenes Modul zur Performance-Profilierung.
+Prüfidee:      Ein simulierter Fehler erscheint im LogViewer mit Zeitstempel und Kontext.
+Tracelinks:    SyRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - im Zielsystem sollte zentrales Logging/Monitoring (z. B. Cloud-APM) diese Funktion übernehmen statt eines Client-eigenen Viewers.
+Status:        belegt
+```
+
+```
+ID:            StRS-9
+Titel:         Flexible Abrechnungs- und Eskalationskonditionen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Systemadministrator
+Vorbedingung:  Unterschiedliche Kunden/Verträge benötigen unterschiedliche Stundensätze, Konditionen und Eskalationsregeln
+Fakt:          Administration enthält HourlySurchargeRates (Stundenzuschläge), ReceiptConditions (Belegkonditionen) und EscalationsSettings (SLA-Eskalation) als eigenständige Konfigurationsbereiche.
+Aussage:       [HYPOTHESE] Das System soll Stundenzuschlagssätze, Belegkonditionen und SLA-Eskalationsregeln zentral konfigurierbar machen.
+Ergebnis:      Abrechnung und SLA-Überwachung erfolgen konsistent nach hinterlegten Regeln statt manueller Einzelfallentscheidung.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates - Begründung: Eigener Konfigurationsbereich für Zuschlagssätze.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings - Begründung: Eigener Konfigurationsbereich für Eskalationsregeln.
+Prüfidee:      Eine Zeiterfassung außerhalb der Regelarbeitszeit wird automatisch mit dem hinterlegten Zuschlag bepreist.
+Tracelinks:    SyRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE - Abrechnungsrelevante Anforderung ohne PRIMÄR-Beleg (nur Konfigurationsoberflächen gesichtet, nicht die Verrechnungslogik selbst); konsistent mit der bereits als HYPOTHESE geführten SyRS-10.
+```
+
+```
+ID:            StRS-10
+Titel:         KI-unterstützte Texterstellung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb/Außendienst
+Vorbedingung:  Angebotstexte/Kommunikation sollen mit KI-Unterstützung effizienter erstellt werden
+Fakt:          Modul ArtificialIntelligence enthält Chat, OfferPositionsAIEditor und OpenAIConnect.
+Aussage:       Das System soll Mitarbeitern eine KI-gestützte Erstellung/Bewertung von Angebotstexten über eine Chat-Oberfläche ermöglichen.
+Ergebnis:      Schnellere Texterstellung bei gleichbleibender/besserer Qualität.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/ArtificialIntelligence/OfferPositionsAIEditor - Begründung: Dedizierter Editor für KI-generierte Angebotspositionstexte.
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/ArtificialIntelligence/OpenAIConnect - Begründung: Eigener Verbindungsbereich zu einem OpenAI-kompatiblen Dienst.
+Prüfidee:      Eine Angebotsposition wird über den KI-Editor mit einem Vorschlagstext befüllt und kann übernommen werden.
+Tracelinks:    SyRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - KI-Unterstützung ist ein Differenzierungsmerkmal, sollte fortgeführt werden.
+Status:        belegt
+```
+
+```
+ID:            StRS-11
+Titel:         Persönliche und geteilte Terminplanung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        alle Mitarbeiter
+Vorbedingung:  Termine müssen sowohl persönlich als auch abteilungsübergreifend geplant werden
+Fakt:          Es existieren zwei getrennte Kalenderbereiche: Modules/Calendar (allgemein) und Modules/MyCentron/Calendar (persönlich), mit eigenen Sichtbarkeitsrechten laut CentronRights.md (RIGHT_KALENDERANZEIGENALLE / RIGHT_KALENDERANZEIGENEIGENE).
+Aussage:       Das System soll Mitarbeitern eine Terminplanung mit einstellbarer Sichtbarkeit (alle Termine vs. nur eigene) bereitstellen.
+Ergebnis:      Mitarbeiter sehen abhängig von ihrem Recht entweder alle oder nur eigene Kalendereinträge.
+Belege:
+  - [PRIMÄR]   CentronRights.md, Abschnitt Kalender - Begründung: Beschreibt die einschränkende Wirkung von RIGHT_KALENDERANZEIGENEIGENE als durchgesetzte Regel.
+Prüfidee:      Mitarbeiter ohne RIGHT_KALENDERANZEIGENALLE sieht ausschließlich eigene Termine.
+Tracelinks:    SyRS-12
+Konsolidierung: Kandidat: Modules/Calendar und Modules/MyCentron/Calendar bilden denselben fachlichen Gegenstand (Terminverwaltung) in getrennten Implementierungen und sollten im Zielsystem zu einem Kalenderkonzept zusammengeführt werden.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-12
+Titel:         Zentrale Kennzahlen- und Aufgabenübersicht
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Filialleiter/Niederlassungsleiter, alle Mitarbeiter
+Vorbedingung:  Mitarbeiter benötigen beim Einstieg einen schnellen Überblick über offene Aufgaben/Kennzahlen
+Fakt:          Modules/Dashboard und Modules/MyCentron/Dashboard stellen Kachelübersichten bereit; Modules/Statistics/Dashboard liefert Kennzahlen.
+Aussage:       Das System soll dem Nutzer beim Einstieg eine personalisierte Übersicht über offene Aufgaben und relevante Kennzahlen anzeigen.
+Ergebnis:      Reduzierter Navigationsaufwand zu Tagesbeginn.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Dashboard/Modules - Begründung: Kachel-/Widget-Struktur belegt konfigurierbare Übersicht.
+Prüfidee:      Nach Anlage einer neuen Aufgabe erscheint diese im Dashboard des zuständigen Mitarbeiters.
+Tracelinks:    SyRS-13
+Konsolidierung: Kandidat: Modules/Dashboard, Modules/MyCentron/Dashboard und Modules/Statistics/Dashboard bilden denselben fachlichen Gegenstand (Startübersicht) in getrennten Implementierungen.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-13
+Titel:         Anbindung kundenspezifischer externer Werkzeuge
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  Kunden nutzen mandantenspezifische externe Tools, die aus dem ERP heraus mit Kontextdaten aufgerufen werden sollen
+Fakt:          Modul ExternalTool/Variables verwaltet Variablen; der Ordner enthält ausschließlich eine Variablenverwaltung ohne erkennbare direkte Aufrufschnittstelle im gesichteten Code.
+Aussage:       [HYPOTHESE] Das System soll es erlauben, externe Werkzeuge mit dynamisch aus dem ERP-Kontext befüllten Variablen aufzurufen.
+Ergebnis:      Nahtloser Wechsel in externe Werkzeuge mit vorbefülltem Kontext.
+Belege:
+  - [KONTEXT]  centron/Centron.WPF.UI/Modules/ExternalTool/Variables - Begründung: Ordnername und Modulplatzierung legen eine Variablenverwaltung für externe Toolintegration nahe; der genaue Aufrufmechanismus wurde nicht gelesen und ist daher offen.
+Prüfidee:      Ein externes Tool wird mit einer Variable (z. B. Kundennummer) aus einem Beleg heraus gestartet.
+Tracelinks:    SyRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - vermutlich kundenspezifische Einzellösungen, im Zielsystem eher über generisches Plugin-/Webhook-Konzept abzubilden.
+Status:        HYPOTHESE
+```
+## StRS – DataExchange
+
+```
+ID:            StRS-14
+Titel:         Automatisierter Datenaustausch mit externen Systemen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Systemadministrator, externes System
+Vorbedingung:  Buchungsdaten, Dokumente oder Bestelldaten müssen mit externen Systemen (Steuerberater, DMS, Managed-Service-Plattformen) ausgetauscht werden
+Fakt:          DataExchange gliedert sich in eigenständige Backend-Bereiche BookKeeping, Connectors, DocuForm, EDI, GfkExport, Import, PaymentTransactions, Rmm, TanssInterfaces, TelekomDive, jeweils mit eigener BL-Klasse (z. B. BookKeepingExportBL, EdiExportBL, TelekomDiveBL).
+Aussage:       Das System soll strukturierte Export-/Import-Schnittstellen zu mehreren externen Zielsystemen (Finanzbuchhaltung, Dokumentenmanagement, EDI-Partner, Managed-Service-Plattformen) bereitstellen.
+Ergebnis:      Daten müssen nicht manuell zwischen Systemen übertragen werden.
+Belege:
+  - [SEKUNDÄR] backend/Centron.BL/DataExchange/{BookKeeping,Connectors,DocuForm,EDI,GfkExport,Import,PaymentTransactions,Rmm,TanssInterfaces,TelekomDive} - Begründung: Zehn eigenständige BL-Unterordner belegen die bewusste Trennung nach Zielsystem.
+Prüfidee:      Für jede der zehn Kategorien existiert mindestens ein erfolgreicher Exporttestlauf mit Ergebnisdatei.
+Tracelinks:    SyRS-15, SyRS-16, SyRS-18, SyRS-19, SyRS-21
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-15
+Titel:         Rechtssicherer SEPA-Zahlungsverkehr
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Buchhaltung
+Vorbedingung:  Offene Rechnungen sollen per SEPA-Lastschrift eingezogen werden
+Fakt:          PaymentTransactionBL unterstützt fünf SEPA-PAIN-Formatvarianten (u. a. PAIN.008.001.02, GBIC3/GBIC4) und unterscheidet beim Bankkonto zwischen Erst- und Folgelastschrift (SepaDirectDebitType.First/Recurrent).
+Aussage:       Das System soll SEPA-Lastschriftdateien in den vom Zahlungsverkehr geforderten PAIN-Formatvarianten erzeugen und dabei zwischen Erst- und Folgeeinzug automatisch unterscheiden.
+Ergebnis:      Bankenseitig akzeptierte, formatkonforme SEPA-Dateien ohne manuelle Sequenztyp-Pflege.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Zeilen 350-351 (DirectDebitType-Umschaltung First→Recurrent nach erstem Einzug) - Begründung: Konkrete, im Code durchgesetzte Sequenztyp-Regel, die für die SEPA-Konformität zwingend ist.
+Prüfidee:      Erster Einzug eines Mandats erzeugt Sequenztyp FRST; jeder Folgeeinzug erzeugt RCUR.
+Tracelinks:    SyRS-17
+Konsolidierung: Kandidat: SEPA-Mandatsverwaltung (Administration/SepaContract) und SEPA-Zahlungsdateierzeugung (DataExchange/PaymentTransactions) bilden denselben fachlichen Gegenstand (SEPA-Lastschriftprozess) in getrennten Modulen und sollten im Zielsystem zu einem SEPA-Prozess zusammengeführt werden.
+Übernahmewürdigkeit: übernehmen - SEPA-Konformität ist zwingende regulatorische Anforderung.
+Status:        belegt
+```
+
+## StRS – Finances
+
+```
+ID:            StRS-16
+Titel:         Automatisierte Vertrags- und Abrechnungsprozesse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Mandant/Geschäftsführung
+Vorbedingung:  Kunden haben laufende Verträge (Wartung, Leasing, Flatrate) mit wiederkehrender Abrechnung
+Fakt:          ContractBL berechnet Kündigungsfristen über zwei gestaffelte Fristregeln (KuendigungsFristArt1/-Dauer1, KuendigungsFristArt2/-Dauer2); AutomaticFacturaBL erzeugt automatisiert Rechnungen aus offenen Aufträgen (interne Klasse FoundOrder); ReceiptContract-Belege mit CalculationKind.Auto werden automatisch bis zum Vertragsende/zur Kündigung fortgeschrieben (ContractBL, Zeilen 1259-1271).
+Aussage:       Das System soll wiederkehrende Vertragsabrechnungen automatisiert bis zum vertraglich/kündigungsbedingt festgelegten Enddatum durchführen, ohne dass die Buchhaltung jeden Abrechnungslauf manuell auslösen muss.
+Ergebnis:      Kunden werden fristgerecht und ohne manuellen Mehraufwand entsprechend ihres Vertrags abgerechnet; die Abrechnung endet automatisch zum korrekten Kündigungstermin.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Zeilen 1103-1132 (Kündigungsfristberechnung) und Zeilen 1259-1271 (automatische Fortschreibung bis ContractTermination) - Begründung: Konkrete, im Code durchgesetzte Fristlogik und Abbruchbedingung für automatische Vertragsabrechnung.
+  - [KONTEXT]  docs/reference/receipts/contracts-backend.md, docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md - Begründung: Referenzdokumentation zur Vertragsabrechnungslogik als Kontext.
+Prüfidee:      Ein Vertrag mit Kündigung zum 31.03. wird letztmalig bis einschließlich März automatisch abgerechnet und danach nicht mehr.
+Tracelinks:    SyRS-22, SyRS-25, SyRS-28
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des Geschäftsmodells (wiederkehrende Vertragsabrechnung).
+Status:        belegt
+```
+
+```
+ID:            StRS-17
+Titel:         Kundenbeziehungsmanagement und Kampagnensteuerung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb/Außendienst
+Vorbedingung:  Vertrieb benötigt eine konsolidierte Sicht auf Kundenkontakte und Marketingkampagnen
+Fakt:          Finances/Crm enthält umfangreiche Unterstruktur (AccountContracts, AccountMigrations, Actions u. a.); Finances/Campaigns verwaltet Kampagnen mit Kundenzuordnung; Accounts/Campaigns existiert zusätzlich im Backend.
+Aussage:       Das System soll Kundenkontakthistorie, -aktivitäten und Marketingkampagnen in einer gemeinsamen CRM-Sicht verwalten.
+Ergebnis:      Vertrieb kann Kampagnenerfolg je Kunde nachvollziehen, ohne Daten aus mehreren Quellen zusammenzuführen.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Finances/{Crm,Campaigns}; backend/Centron.BL/Accounts/Campaigns - Begründung: Struktur belegt CRM- und Kampagnenverwaltung als eigenständige, aber verknüpfte Bereiche.
+Prüfidee:      Eine Kampagne wird einem Kunden zugeordnet und erscheint in dessen CRM-Aktivitätenhistorie.
+Tracelinks:    SyRS-26, SyRS-27
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-18
+Titel:         Mahnwesen und Forderungsmanagement
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung
+Vorbedingung:  Rechnungen sind über das Zahlungsziel hinaus offen
+Fakt:          DunningBL/DunningRunBL führen ein vierstufiges Mahnsystem (None/Level1/Level2/Level3) mit automatischer Eskalation je Mahnlauf; OposBL/OposRunBL verwalten parallel die offenen Posten.
+Aussage:       Das System soll überfällige Rechnungen automatisiert stufenweise mahnen und den Status offener Forderungen laufend nachführen.
+Ergebnis:      Konsistente, nachvollziehbare Mahnstufen je Rechnung ohne manuelle Einzelprüfung.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeilen 255-266 (Eskalation None→Level1→Level2→Level3) - Begründung: Konkrete, im Code durchgesetzte Zustandsmaschine des Mahnwesens.
+Prüfidee:      Eine unbezahlte Rechnung durchläuft bei drei aufeinanderfolgenden Mahnläufen alle drei Mahnstufen in der korrekten Reihenfolge.
+Tracelinks:    SyRS-29, SyRS-30, SyRS-31
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mahnwesen ist zwingender Bestandteil des Forderungsmanagements.
+Status:        belegt
+```
+
+```
+ID:            StRS-19
+Titel:         Erfassung und Zuordnung von Zahlungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung
+Vorbedingung:  Eine Zahlung (Überweisung, Lastschrifteinzug, Zählerabrechnung) muss einer Forderung zugeordnet werden
+Fakt:          Payments-Modul trennt IncomingPayments/OutgoingPayments; DeviceClickCounter erfasst Zählerstände als Abrechnungsgrundlage separat.
+Aussage:       [HYPOTHESE] Das System soll eingehende und ausgehende Zahlungen getrennt erfassen und Zählerstände als eigenständige Abrechnungsgrundlage für nutzungsbasierte Verträge (z. B. Klickabrechnung Drucker) verwalten.
+Ergebnis:      Zahlungen sind korrekt Forderungen zugeordnet; nutzungsbasierte Abrechnung basiert auf nachvollziehbaren Zählerständen.
+Belege:
+  - [SEKUNDÄR] backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs; centron/.../Finances/Payments/{IncomingPayments,OutgoingPayments}; centron/.../Finances/DeviceClickCounter/CounterHistoryViewModel.cs - Begründung: Getrennte Klassen/Ordner belegen die fachliche Trennung von Zahlungsrichtung und Zählererfassung.
+Prüfidee:      Eine erfasste Zahlung reduziert den offenen Betrag der zugeordneten Rechnung um den Zahlbetrag.
+Tracelinks:    SyRS-32, SyRS-33
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE - Abrechnungs-/Zahlungsrelevante Anforderung ohne PRIMÄR-Beleg; die konkrete Verrechnungslogik (Zuordnung Zahlung↔Forderung, Ableitung des Rechnungsbetrags aus Zählerständen) wurde nicht im Code gesichtet, nur die strukturelle Trennung der Ordner/Klassen.
+```
+
+```
+ID:            StRS-20
+Titel:         Durchgängige Belegverwaltung vom Angebot bis zur Lieferantenrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter/Innendienst, Vertrieb/Außendienst, Buchhaltung
+Vorbedingung:  Ein Geschäftsvorfall durchläuft mehrere Belegarten (Angebot → Auftrag → Lieferschein → Rechnung; Bestellung → Wareneingang → Lieferantenrechnung)
+Fakt:          Elf Belegarten (Offers, Orders, DeliveryLists, PickupLists, Invoices, CreditVouchers, SupplierOrders, SupplierInvoices, SupplierCreditVouchers, SupplierDeliveryLists, ContractLists) implementieren ein gemeinsames Interface IReceiptSpecificLogic mit einheitlichem Rechte-, Status- (ReceiptState: Active/Completed/Canceled) und Weiterleitungsmodell.
+Aussage:       Das System soll alle Belegarten über ein gemeinsames, konsistentes Beleg-Interface mit einheitlicher Status- und Rechteführung abbilden, damit Folgebelege (z. B. Rechnung aus Lieferschein) konsistent erzeugt werden können.
+Ergebnis:      Jede Belegart verhält sich bezüglich Status, Rechteprüfung und Belegfluss konsistent zu den übrigen.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: Gemeinsames Interface, das von allen elf Belegart-Klassen implementiert wird und damit die konsistente Struktur technisch erzwingt.
+  - [SEKUNDÄR] backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs - Begründung: Einheitliches Statusmodell (offen/abgeschlossen/storniert) für alle Belegarten.
+Prüfidee:      Aus einem abgeschlossenen Lieferschein wird eine Rechnung erzeugt, die die Positionen des Lieferscheins korrekt übernimmt.
+Tracelinks:    SyRS-34, SyRS-35, SyRS-36, SyRS-37, SyRS-38
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess des ERP-Systems.
+Status:        belegt
+```
+
+## StRS – Global/Gui/Helpdesk
+
+```
+ID:            StRS-21
+Titel:         Wiederverwendbare UI-Bausteine und Anwendungsrahmen
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        alle Mitarbeiter
+Vorbedingung:  Alle Module benötigen gleichartige Grundfunktionen (Drucken, Hilfe, individuelle Felder)
+Fakt:          Global-Modul bündelt modulübergreifend genutzte Bausteine (Actions/PrintPdfAction, CustomProperties, Help, VideoPortal, NetworkDiagnostics); Gui/Profiles verwaltet UI-Layoutprofile je Benutzer.
+Aussage:       Das System soll modulübergreifend wiederverwendbare UI-Bausteine (Drucken, Hilfe, individuelle Felder, Layoutprofile) zentral bereitstellen, statt sie je Fachmodul neu zu implementieren.
+Ergebnis:      Einheitliches Bedienverhalten über alle Fachmodule hinweg.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/Global/Actions/{PrintPdfAction.cs,SavePdfAs.cs} - Begründung: Generische, modulübergreifend nutzbare Aktionen belegen den Rahmencharakter.
+Prüfidee:      PrintPdfAction wird aus zwei unterschiedlichen Fachmodulen heraus mit identischem Ergebnis aufgerufen.
+Tracelinks:    SyRS-41, SyRS-42, SyRS-43, SyRS-44
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-22
+Titel:         Ganzheitliche Ticketbearbeitung mit konfigurierbarem Status und SLA-Steuerung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Mitarbeiter
+Vorbedingung:  Ein Kundenanliegen wird als Ticket erfasst und bis zum Abschluss bearbeitet
+Fakt:          TicketLogicHelper verwendet konfigurierbare Status-IDs (HelpdeskStatusI3D) statt fixer Enum-Werte, inkl. eines konfigurierbaren Folgestatus nach Vererbung (HelpdeskAfterInheritDefaultState); TicketDetails enthält u. a. CFlow-Prozessvorlagen, ContractSelection (Vertragsbezug) und CloseHelpdesk als eigene Funktionsbereiche; Events wie TicketLockChangedEvent sichern gleichzeitige Bearbeitung ab.
+Aussage:       Das System soll Tickets mit frei konfigurierbaren Statuswerten, Vertragsbezug, Prozessvorlagen (C-FLOW) und Bearbeitersperren durchgängig bis zum Abschluss steuern.
+Ergebnis:      Tickets sind konsistent Vertrag/Kunde zugeordnet, Statuswerte sind an fachliche Prozesse anpassbar, gleichzeitige Bearbeitung wird verhindert.
+Belege:
+  - [PRIMÄR]   centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeilen 371-374, 444-461 - Begründung: Konkrete, im Code durchgesetzte Statuslogik mit konfigurierbarem Folgestatus.
+  - [KONTEXT]  CentronRights.md, Abschnitt Helpdesk - Begründung: Dokumentiert die rechteseitige Steuerung von Statusänderungen (z. B. CLOSE_REQUEST, MATURITY_CHANGE) als fachlichen Kontext.
+Prüfidee:      Ein Ticket wechselt nach Vererbung eines Folgetickets automatisch in den konfigurierten Folgestatus statt in einen fest codierten Status.
+Tracelinks:    SyRS-45, SyRS-46, SyRS-47
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## StRS – Logistik, MyCentron, OnlineBanking, PLM, Passwortverwaltung, Zahler/Kostenstellen, Produktion, Projekte
+
+```
+ID:            StRS-23
+Titel:         Verschlüsselte Verwaltung sensibler Zugangsdaten
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, Sachbearbeiter/Innendienst
+Vorbedingung:  Mitarbeiter benötigen Zugriff auf Kunden-/Systemzugangsdaten (Passwörter), ohne dass diese im Klartext einsehbar sind
+Fakt:          PasswordManagerBL verschlüsselt Passwortwerte mit AESCryptoLogic().EncryptText unter Verwendung eines MasterKey und entschlüsselt sie nur bei berechtigtem Zugriff wieder (DecryptText); AccessAreaManagement/AccessManagement bilden getrennte Zugriffsbereiche.
+Aussage:       Das System soll Zugangsdaten ausschließlich AES-verschlüsselt mit zentralem Master-Key speichern und den Zugriff über eigene Zugriffsbereiche (Access Areas) statt der allgemeinen Modulrechte steuern.
+Ergebnis:      Zugangsdaten sind bei Datenbankzugriff ohne Master-Key nicht im Klartext lesbar.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeile 700 (EncryptText mit AESCryptoLogic/masterKeyResult) und Zeilen 1051-1052 (DecryptText) - Begründung: Konkrete, im Code durchgesetzte AES-Verschlüsselung von Passwortwerten.
+Prüfidee:      Ein direkter Blick in die Datenbanktabelle zeigt für ein gespeichertes Passwort ausschließlich Chiffretext, keinen Klartext.
+Tracelinks:    SyRS-52, SyRS-53
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verschlüsselte Speicherung ist sicherheitskritisch korrekt und zwingend fortzuführen.
+Status:        belegt
+```
+
+```
+ID:            StRS-24
+Titel:         Persönliche Tagesorganisation und Fernwartung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        alle Mitarbeiter
+Vorbedingung:  Mitarbeiter benötigen eine tagesbezogene Aufgaben-/Terminübersicht und gelegentlich Fernzugriff auf Kundenrechner
+Fakt:          MyCentron bündelt MyDay, TodoList, PersonalSettings, CentronInspectors und Supremo (Fernwartungssoftware) als persönliche Werkzeuge, getrennt von den fachmodulweiten Pendants.
+Aussage:       Das System soll Mitarbeitern eine persönliche Tagesübersicht mit Aufgabenliste sowie eine integrierte Fernwartungsanbindung (Supremo) bereitstellen.
+Ergebnis:      Mitarbeiter planen ihren Tag und starten Fernwartungssitzungen ohne Systemwechsel.
+Belege:
+  - [SEKUNDÄR] centron/Centron.WPF.UI/Modules/MyCentron/{MyDay,TodoList,Supremo} - Begründung: Eigenständige Module belegen die persönliche Werkzeugsammlung.
+Prüfidee:      Start einer Fernwartungssitzung aus einem Ticket öffnet Supremo mit korrekt vorbefülltem Zielrechner.
+Tracelinks:    SyRS-54
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+```
+ID:            StRS-25
+Titel:         Automatisierter Kontoumsatzabruf über Online-Banking-Schnittstelle
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhaltung
+Vorbedingung:  Zahlungseingänge sollen ohne manuellen Kontoauszugsimport abgeglichen werden
+Fakt:          OnlineBankingFinApiBL bindet den externen Dienst FinAPI an; OnlineBankingAccountTransactionsBL verarbeitet die abgerufenen Kontobewegungen weiter.
+Aussage:       Das System soll Kontoumsätze automatisiert über die FinAPI-Schnittstelle abrufen und für den Zahlungsabgleich bereitstellen.
+Ergebnis:      Zahlungseingänge sind zeitnah ohne manuellen Kontoauszugsimport im System sichtbar.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs - Begründung: Konkrete Klasse zur Anbindung des externen FinAPI-Dienstes.
+Prüfidee:      Ein über FinAPI abgerufener Kontoumsatz erscheint in der Liste der Kontobewegungen mit korrektem Betrag und Verwendungszweck.
+Tracelinks:    SyRS-55
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## StRS – Einkauf, QM, Reports, RMA, Sales, Statistik, Survey
+
+```
+ID:            StRS-26
+Titel:         Automatisierte Bestellvorschläge auf Basis von Mindestbeständen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lager/Logistik
+Vorbedingung:  Der Lagerbestand eines Artikels unterschreitet den definierten Mindestbestand
+Fakt:          OrderSuggestionListBL vergleicht je Artikel und Lager (inkl. Nebenläger) den aktuellen Bestand (cvw_ArticleCount.cnt) gegen den hinterlegten Mindestbestand zuzüglich offener Bestellungen/Konsignationsware und erzeugt daraus Bestellvorschläge.
+Aussage:       Das System soll automatisiert Bestellvorschläge erzeugen, sobald der verfügbare Bestand eines Artikels je Lager unter den definierten Mindestbestand fällt.
+Ergebnis:      Lager/Logistik muss Nachbestellungen nicht manuell anhand von Bestandslisten ermitteln.
+Belege:
+  - [PRIMÄR]   backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, Zeilen 139-158 - Begründung: Konkrete, im Code durchgesetzte SQL-Vergleichslogik Bestand vs. Mindestbestand je Lager.
+Prüfidee:      Ein Artikel mit Bestand knapp über dem Mindestbestand erscheint nicht im Bestellvorschlag; sinkt der Bestand durch einen Verkauf darunter, erscheint er im nächsten Lauf.
+Tracelinks:    SyRS-63, SyRS-64
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion der Beschaffungslogistik.
+Status:        belegt
+```
+
+## StRS – Warehousing
+
+```
+ID:            StRS-27
+Titel:         Einheitliche Artikel- und Gerätestammdaten für Lager und Vertrieb
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lager/Logistik, Sachbearbeiter/Innendienst
+Vorbedingung:  Ein Artikel/Gerät wird sowohl im Lager geführt als auch fachlich (Vertrag, Monitoring) referenziert
+Fakt:          Physische Geräte werden in mindestens zwei getrennten Datenhaltungen geführt: (1) Drucker/Klickabrechnungsgeräte als „Stammblatt" über MasterDataListBL innerhalb Sales/CustomerAssets/Contracts/ClickContracts, referenziert aus Finances/MasterDataLists; (2) RMM-überwachte Geräte (Server/Workstations) als „Asset" über die Entität AssetManagementArticleAssignment (Namespace Centron.Data.Entities.DocuBoard), referenziert aus Warehousing/ArticleManagement/RMMArticle.
+Aussage:       Das System soll physische Geräte (Drucker, Server, Workstations) unabhängig vom jeweiligen fachlichen Anlass (Klickabrechnung vs. RMM-Überwachung) als eine gemeinsame Gerätestammdaten-Entität führen.
+Ergebnis:      Ein Gerät ist unabhängig davon, ob es klickabgerechnet oder RMM-überwacht wird, eindeutig identifizierbar und muss nicht in zwei Systemen parallel gepflegt werden.
+Belege:
+  - [PRIMÄR]   backend/Centron.Entities/Entities/DocuBoard/AssetManagementArticleAssignment.cs, Zeilen 8-16 - Begründung: Eigenständige Entität zur Verknüpfung eines RMM-überwachten Geräts mit einem Artikel, getrennt vom Stammblatt-Modell.
+  - [PRIMÄR]   backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs - Begründung: Eigenständige Geschäftslogik für Stammblätter (Klickabrechnungsgeräte wie Drucker), getrennt von der AssetManagement-Entität.
+Prüfidee:      Ein Drucker, der sowohl klickabgerechnet als auch RMM-überwacht wird, existiert aktuell als zwei unabhängige Datensätze (Stammblatt und AssetManagementArticleAssignment) ohne erzwungene gegenseitige Referenz.
+Tracelinks:    SyRS-73
+Konsolidierung: Kandidat: Stammblatt (Finances/MasterDataLists, ClickContracts) und AssetManagement (DocuBoard/RMMArticle) bilden denselben fachlichen Gegenstand (physisches, zu überwachendes/abzurechnendes Gerät) in getrennten Datenhaltungen und sollten im Zielsystem zu einem einheitlichen Asset-Konzept zusammengeführt werden.
+Übernahmewürdigkeit: Workaround - historisch getrennt für unterschiedliche fachliche Ursprünge (Abrechnung vs. Monitoring) entstanden; im Zielsystem als ein Gerätestamm mit mehreren fachlichen Rollen (abrechnungsrelevant, überwachungsrelevant) zu modellieren.
+Status:        belegt
+```
+
+## StRS – Architektur (Backend, Web-API, Nexus, Shared, externe Integrationen, Betrieb)
+
+```
+ID:            StRS-28
+Titel:         Deklarative, wiederverwendbare API-Autorisierung
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, externes System
+Vorbedingung:  Ein Webservice-/REST-Endpunkt wird von einem externen Client (mobil, Portal, Integration) aufgerufen
+Fakt:          Centron.Controllers/Authorization stellt vier Autorisierungs-Attribute bereit (AuthorizeUserRight, AuthorizeAnyUserRight, AuthorizeAllUserRights, AuthorizeCentronHosted), die intern dieselbe HasUserRight()-Prüfung wie der Desktop-Client nutzen und laut mitgeliefertem README.md als Migrationsziel manueller Rechteprüfungen im Controller dienen.
+Aussage:       Das System soll REST-API-Endpunkte deklarativ über wiederverwendbare Autorisierungs-Attribute absichern, die auf demselben Rechtekatalog wie der Desktop-Client basieren, statt Rechteprüfungen manuell in jeder Methode zu wiederholen.
+Ergebnis:      Jeder abgesicherte Endpunkt liefert bei fehlendem Recht konsistent HTTP 401/403, ohne dass Entwickler die Prüfung erneut implementieren.
+Belege:
+  - [PRIMÄR]   webservice/Centron.Controllers/Authorization/{AuthorizeUserRightAttribute.cs,AuthorizeAllUserRightsAttribute.cs,AuthorizeAnyUserRightAttribute.cs,AuthorizeCentronHostedAttribute.cs} - Begründung: Vier konkrete, im Code vorhandene Attributklassen, die die Autorisierungspipeline vor jeder Aktionsmethode durchsetzen.
+  - [KONTEXT]  webservice/Centron.Controllers/Authorization/README.md - Begründung: Dokumentiert Verhalten, HTTP-Statuscodes und Migrationsabsicht als fachlichen Kontext.
+Prüfidee:      Ein Aufruf von GET /v1/admin/settings ohne SETTINGS-Recht liefert HTTP 403, ein Aufruf ohne gültige Anmeldung liefert HTTP 401.
+Tracelinks:    SyRS-81, SyRS-82
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Deklarative API-Autorisierung ist die für eine SaaS-Neuimplementierung geeignete Grundlage.
+Status:        belegt
+```
+
+```
+ID:            StRS-29
+Titel:         Web-Self-Service für Kunden über c-entron Nexus
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde (Web-Self-Service/WebCart)
+Vorbedingung:  Ein Kunde mit Web-Account soll ohne Mitarbeiterkontakt Dokumente einsehen, unterschreiben und Tickets einsehen können
+Fakt:          CentronNexus (Blazor-Webanwendung, README.md: „aka c-entron Web") bietet WebCart/CustomerPortal-Seiten (Formulare ausfüllen, öffentliche Dokumente, Ticketdetails) sowie eine eigene DocumentSigning-Seite mit IsolatedSignaturePad für elektronische Unterschriften.
+Aussage:       Das System soll Kunden über ein Webportal (c-entron Nexus) Selbstbedienungsfunktionen wie Formularausfüllung, Dokumenteneinsicht, Ticketstatus und elektronische Unterschrift ohne Mitarbeiterkontakt bereitstellen.
+Ergebnis:      Reduzierter manueller Aufwand für Standardvorgänge, die der Kunde selbst erledigen kann.
+Belege:
+  - [PRIMÄR]   nexus/CentronNexus/DocumentSigning/IsolatedSignaturePad.razor; nexus/CentronNexus/WebCart/CustomerPortal/{CustomerPortalFormFillPage.razor,CustomerTicketDetailsPage.razor} - Begründung: Konkrete, im Code vorhandene Seiten für die genannten Selbstbedienungsfunktionen.
+Prüfidee:      Ein Kunde unterschreibt ein Dokument über das IsolatedSignaturePad; die Signatur ist im erzeugten Dokument nachweisbar enthalten.
+Tracelinks:    SyRS-83, SyRS-84
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Nexus ist bereits der begonnene Web-/SaaS-Migrationspfad und damit strategisch zentral.
+Status:        belegt
+```
+
+```
+ID:            StRS-30
+Titel:         Absicherung gegen versehentliche Testkommunikation mit echten Kunden
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        Systemadministrator
+Vorbedingung:  Entwickler/Tester arbeiten mit einer Kopie der Produktivdatenbank in einer Nicht-Produktionsumgebung
+Fakt:          DeveloperSecurity.Email.ValidateAddress ersetzt in Nicht-Release-Builds jede E-Mail-Adresse außerhalb der Domain "nexoware.com" automatisch durch eine feste Testadresse.
+Aussage:       Das System soll in Test-/Entwicklungsumgebungen automatisch verhindern, dass E-Mails an echte, aus Produktivdaten stammende Kundenadressen versendet werden.
+Ergebnis:      Kein Testlauf mit Produktivdatenkopie erreicht versehentlich einen echten Kunden per E-Mail.
+Belege:
+  - [PRIMÄR]   backend/Centron.Common/DeveloperSecurity.cs, Zeilen 30-46 (ValidateAddress) - Begründung: Konkrete, im Code durchgesetzte Ersetzungslogik, aktiv abhängig vom Build-Typ.
+Prüfidee:      In einem Debug-Build wird eine E-Mail an eine externe Testadresse automatisch auf test@nexoware.com umgeleitet; eine interne nexoware.com-Adresse bleibt unverändert.
+Tracelinks:    SyRS-85
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Wichtige Schutzmaßnahme, die im Zielsystem (mit noch mehr Cloud-/Testumgebungen) fortzuführen ist.
+Status:        belegt
+```
+
+## StRS – Restliche Architektur, Nexus, Externe APIs, Betrieb
+
+```
+ID:            StRS-31
+Titel:         Web-basiertes Service-Board als Spiegel der Desktop-Ticketbearbeitung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Mitarbeiter
+Vorbedingung:  Ein Helpdesk-Mitarbeiter möchte Tickets browserbasiert statt über den Desktop-Client bearbeiten
+Fakt:          CentronNexus/ServiceBoard bildet mit CachedTicketList, CloseTicket, ForwardTicket, EmployeeTimerStatistics und DocumentViewer weitgehend dieselben Funktionen ab wie das Desktop-Modul Helpdesk/TicketDetails (CloseHelpdesk, Forward-Events, Zeiterfassung); CentronNexus/Management enthält zusätzlich TaskManagement und TicketPatterns als Web-Pendants der Desktop-Module TaskManagement und C-FLOW-Ticketvorlagen.
+Aussage:       Das System soll die zentralen Helpdesk-Funktionen (Ticketliste, Schließen, Weiterleiten, Zeitstatistik, Dokumentenanzeige) sowohl im Desktop-Client als auch im Webportal Nexus bereitstellen.
+Ergebnis:      Helpdesk-Mitarbeiter können wahlweise über Desktop oder Browser arbeiten.
+Belege:
+  - [PRIMÄR]   nexus/CentronNexus/ServiceBoard/{CachedTicketList,CloseTicket,ForwardTicket,EmployeeTimerStatistics,DocumentViewer} - Begründung: Fünf konkrete, im Code vorhandene Bereiche mit klar erkennbarem Bezug zu den entsprechenden Desktop-Funktionen.
+Prüfidee:      Ein im Nexus-ServiceBoard geschlossenes Ticket zeigt im Desktop-Client denselben Status und dieselbe Historie.
+Tracelinks:    SyRS-89
+Konsolidierung: Kandidat: Helpdesk/TicketDetails (Desktop) und CentronNexus/ServiceBoard (Web) bilden denselben fachlichen Gegenstand (Ticketbearbeitung) in zwei parallelen Implementierungen auf unterschiedlichen Technologiestacks (WPF/Blazor) und sind der zentrale Beleg dafür, dass die geplante Web-/SaaS-Neuimplementierung große Teile der Fachlogik bereits ein zweites Mal in Nexus abbildet.
+Übernahmewürdigkeit: übernehmen - Nexus/ServiceBoard ist der naheliegende Ausgangspunkt für die Zielarchitektur, sofern die Desktop-Fachlogik dorthin migriert statt neu erfunden wird.
+Status:        belegt
+```
+
+```
+ID:            StRS-32
+Titel:         Anreicherung von Produkt- und Bonitätsdaten über externe Datenquellen
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter/Innendienst, Vertrieb/Außendienst
+Vorbedingung:  Artikelstammdaten oder Kundenbonität sollen ohne manuelle Recherche angereichert werden
+Fakt:          Neun eigenständige API-Projekte binden externe Datenquellen an: ITscope und Icecat (Produktdaten-Anreicherung, jeweils mit eigenem Interface IITscopeApi/IIcecatApi), COP und EGIS (Distributoren-/Bonitätsdaten, mit mitgelieferter Herstellerdokumentation), FinAPI (Bankdaten, mit Interface IFinApiClient), EbInterface (österreichische E-Rechnung), Gls und Shipcloud (Versanddienstleister), docuFORM (Dokumentenerzeugung).
+Aussage:       Das System soll Artikelstamm-, Bonitäts- und Versanddaten automatisiert über dedizierte, interface-basierte Client-Bibliotheken aus externen Quellen anreichern, statt manuelle Recherche durch Mitarbeiter zu erfordern.
+Ergebnis:      Aktuelle, korrekte Produkt-/Bonitäts-/Versanddaten ohne manuellen Rechercheaufwand.
+Belege:
+  - [PRIMÄR]   apis/Centron.APIs.ITscopeDataAccess/IITscopeApi.cs; apis/Centron.APIs.IcecatDataAccess/IIcecatApi.cs; apis/Centron.APIs.FinAPI/IFinApiClient.cs - Begründung: Drei konkrete, interface-basierte Client-Abstraktionen als durchgesetztes Architekturmuster für externe Datenquellen.
+Prüfidee:      Ein Artikel ohne technische Beschreibung wird über die ITscope- oder Icecat-Anbindung automatisch mit Herstellerdaten angereichert.
+Tracelinks:    SyRS-90, SyRS-91
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+```
+
+## StRS – Restliche Kernarchitektur, Zwei-Faktor-Authentifizierung, Betrieb
+
+```
+ID:            StRS-33
+Titel:         Optionale Zwei-Faktor-Authentifizierung für Benutzeranmeldung
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, alle Mitarbeiter
+Vorbedingung:  Ein Mitarbeiterkonto soll zusätzlich zum Passwort durch einen zweiten Faktor abgesichert werden
+Fakt:          Eine vollständige TOTP-Implementierung (GoogleAuthenticator/TwoFactorAuthenticator.cs, Base32.cs) ist in Centron.Core vorhanden und wird über mehrere Schichten hinweg konkret verdrahtet: WebServices.Core (UpdateAppUserTwoFactorAuthKeyRequest), Centron.Host (CentronRestService.TwoFactorAuthentication.cs), Centron.WPF.UI (BLTwoFactorAuthenticationLogic/WSTwoFactorAuthenticationLogic) und ein eigener Einrichtungsassistent (Centron.Controls/EmployeeManagement/TwoFactorAuthentication/WizardPages/GoogleAuthenticatorViewModel.cs).
+Aussage:       Das System soll Benutzern die Absicherung ihres Kontos durch eine TOTP-basierte Zwei-Faktor-Authentifizierung (kompatibel zu Google Authenticator) über einen geführten Einrichtungsassistenten ermöglichen.
+Ergebnis:      Konten mit aktivierter Zwei-Faktor-Authentifizierung sind gegen alleinigen Passwortdiebstahl zusätzlich abgesichert.
+Belege:
+  - [PRIMÄR]   shared/Centron.Core/GoogleAuthenticator/TwoFactorAuthenticator.cs; webservice/Centron.Host/Services/CentronRestServiceParts/CentronRestService.TwoFactorAuthentication.cs - Begründung: Durchgängig, über Client, Webservice und Kernbibliothek hinweg konkret implementierte TOTP-Prüfung, keine bloße Vorbereitung.
+Prüfidee:      Eine Anmeldung mit korrektem Passwort, aber falschem/fehlendem TOTP-Code bei aktivierter Zwei-Faktor-Authentifizierung wird abgelehnt.
+Tracelinks:    SyRS-94
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zwei-Faktor-Authentifizierung ist eine wichtige, bereits vorhandene Sicherheitsfunktion, die im Zielsystem mindestens erhalten, idealerweise verpflichtend für privilegierte Rollen gemacht werden sollte.
+Status:        belegt
+```
+
+```
+ID:            StRS-34
+Titel:         Containerisierte Bereitstellung für Demo- und Testumgebungen
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:        Systemadministrator
+Vorbedingung:  Eine Testumgebung (Demo, Regressionstest) soll reproduzierbar bereitgestellt werden
+Fakt:          docker/compose enthält ein compose.yaml mit produktionsnaher appsettings.Production.json und WebServiceConfig.xml; weitere Docker-Verzeichnisse (c-entron-demo, c-entron-regression-tests-db, c-entron-regression-tests-pipeline) belegen mehrere containerisierte Umgebungstypen.
+Aussage:       Das System soll über Docker-Compose-Definitionen reproduzierbar als Demo- und Regressionstestumgebung bereitstellbar sein.
+Ergebnis:      Neue Umgebungen sind ohne manuelle Servereinrichtung in kurzer Zeit verfügbar.
+Belege:
+  - [SEKUNDÄR] docker/compose/compose.yaml; docker/c-entron-demo; docker/c-entron-regression-tests-db - Begründung: Konkrete, im Repository vorhandene Containerdefinitionen für unterschiedliche Umgebungszwecke.
+Prüfidee:      Ein `docker compose up` aus docker/compose stellt eine lauffähige Demoumgebung ohne weitere manuelle Konfiguration bereit.
+Tracelinks:    SyRS-95
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Containerisierung ist eine direkt nutzbare Grundlage für die geplante SaaS-Neuimplementierung.
+Status:        belegt
+```
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Ergebnisse/Traceability.md

@@ -0,0 +1,88 @@
+# Traceability – c-entron ERP-Suite
+
+Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede Zeile entspricht einer SwRS-Anforderung mit ihrem primären Pfad nach oben (erste referenzierte SyRS-ID, deren erste referenzierte StRS-ID) sowie dem ersten Artefaktbeleg dieser SwRS-Anforderung. Anforderungen mit mehreren Tracelinks (z. B. `SyRS-1, SyRS-2`) sind zusätzlich in den Feldern `Tracelinks` der jeweiligen StRS.md/SyRS.md/SwRS.md-Dateien vollständig aufgeführt; diese Tabelle bildet zur Übersichtlichkeit den primären (ersten) Pfad je SwRS-Anforderung ab.
+
+Insgesamt: 34 StRS-Anforderungen, 101 SyRS-Anforderungen, 80 SwRS-Anforderungen (215 Anforderungen gesamt).
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (erster Beleg der SwRS-Zeile) |
+|---|---|---|---|
+| StRS-1 | SyRS-1 | SwRS-1 | backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeilen 388-393 (SaveRightGroup) |
+| StRS-2 | SyRS-3 | SwRS-2 | centron/Centron.WPF.UI/Modules/Administration/DSGVO/{CentronDataSecurityViewModel.cs,CentronDataSecurityCustomerViewModel.cs,OrderProcessingContractSettingsViewModel.cs,OrderProcessingContractTemplateViewModel.cs} |
+| StRS-5 | SyRS-6 | SwRS-3 | centron/Centron.WPF.UI/Modules/Administration/SepaContract/{SepaContractSettingsViewModel.cs,SepaContractTemplateViewModel.cs} |
+| StRS-3 | SyRS-4 | SwRS-4 | centron/Centron.WPF.UI/Modules/Administration/MandatorManagement/MandatorManagementViewModel.cs, Zeile 434 (GetBranchDetailsList mit BranchFilter{MandantI3D=...}) |
+| StRS-4 | SyRS-5 | SwRS-5 | centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement/AdImport |
+| StRS-4 | SyRS-5 | SwRS-6 | centron/Centron.WPF.UI/Modules/Administration/CountryManagement |
+| StRS-5 | SyRS-6 | SwRS-7 | backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeilen 424-436 (GetReplacedTextForForwarding) |
+| StRS-6 | SyRS-7 | SwRS-8 | centron/Centron.WPF.UI/Modules/Administration/{PdfExport,PdfSigning,ReportServer,TextBlockManagement} |
+| StRS-7 | SyRS-8 | SwRS-9 | centron/Centron.WPF.UI/Modules/Administration/SqlManagers |
+| StRS-8 | SyRS-9 | SwRS-10 | centron/Centron.WPF.UI/nlog.config |
+| StRS-9 | SyRS-10 | SwRS-11 | centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates |
+| StRS-10 | SyRS-11 | SwRS-12 | centron/Centron.WPF.UI/Modules/ArtificialIntelligence/{Chat,OfferPositionsAIEditor} |
+| StRS-11 | SyRS-12 | SwRS-13 | centron/Centron.WPF.UI/Modules/{Calendar,MyCentron/Calendar} |
+| StRS-12 | SyRS-13 | SwRS-14 | centron/Centron.WPF.UI/Modules/Dashboard/Modules; vgl. Modules/ModuleRegistration.cs |
+| StRS-13 | SyRS-14 | SwRS-15 | centron/Centron.WPF.UI/Modules/ExternalTool/Variables |
+| StRS-14 | SyRS-15 | SwRS-16 | backend/Centron.BL/DataExchange/BookKeeping/{BookKeepingExportBL.cs,BookKeepingImportBL.cs} |
+| StRS-14 | SyRS-16 | SwRS-17 | centron/Centron.WPF.UI/Modules/DataExchange/Connectors/Settings |
+| StRS-15 | SyRS-17 | SwRS-18 | backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs, Zeilen 350-351 |
+| StRS-14 | SyRS-18 | SwRS-19 | centron/Centron.WPF.UI/Modules/DataExchange/DocuForm/Authorization |
+| StRS-14 | SyRS-19 | SwRS-20 | backend/Centron.BL/DataExchange/EDI/{ZugferdExportItem.cs,ZugferdExportPositionItem.cs} |
+| StRS-14 | SyRS-20 | SwRS-21 | backend/Centron.BL/DataExchange/Rmm/RmmConnectionSettingsBL.cs |
+| StRS-14 | SyRS-21 | SwRS-22 | backend/Centron.BL/DataExchange/TelekomDive/TelekomDiveBL.cs |
+| StRS-16 | SyRS-23 | SwRS-23 | centron/Centron.WPF.UI/Modules/Finances/AccountManagement/BranchBookKeepingNumbers |
+| StRS-16 | SyRS-24 | SwRS-24 | backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.cs, Zeile 495 |
+| StRS-16 | SyRS-28 | SwRS-25 | centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling/AssetPositions |
+| StRS-18 | SyRS-29 | SwRS-26 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeilen 207-210 (Filterung nach invoice.DunningLevel) |
+| StRS-18 | SyRS-29 | SwRS-27 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs, Zeilen 296-297 |
+| StRS-18 | (direkt) | SwRS-28 | backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs, Zeilen 220-230 |
+| StRS-20 | SyRS-35 | SwRS-29 | backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoiceSpecificLogic.cs, Zeilen 485-677 |
+| StRS-16 | SyRS-25 | SwRS-30 | backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs, Zeilen 1259-1271 |
+| StRS-20 | SyRS-38 | SwRS-31 | backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs, Zeilen 491-507 |
+| StRS-16 | (direkt) | SwRS-32 | centron/Centron.WPF.UI/Modules/Finances/{ContractEvaluation2,ContractEvaluationOld} |
+| StRS-16 | (direkt) | SwRS-33 | centron/Centron.WPF.UI/Modules/Finances/MasterDataLists/{ChangeMainDeviceSerialNumberView.xaml,ChangeMainDeviceSerialNumberViewModel.cs} |
+| StRS-18 | SyRS-39 | SwRS-34 | backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposRunBL.cs |
+| StRS-16 | (direkt) | SwRS-35 | backend/Centron.BL/Finances/ProductLifecycleBL.cs |
+| StRS-16 | SyRS-40 | SwRS-36 | centron/Centron.WPF.UI/Modules/Finances/Projects/CrmProjectGantTaskViewModel.cs |
+| StRS-19 | (direkt) | SwRS-37 | centron/Centron.WPF.UI/Modules/Finances/TimerBilling/{Common,Events,Settings} |
+| StRS-21 | SyRS-41 | SwRS-38 | centron/Centron.WPF.UI/Modules/Global/Actions/{PrintPdfAction.cs,SavePdfAs.cs} |
+| StRS-21 | (direkt) | SwRS-39 | centron/Centron.WPF.UI/Modules/Global/NetworkDiagnostics |
+| StRS-22 | SyRS-45 | SwRS-40 | centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeile 371 |
+| StRS-22 | SyRS-46 | SwRS-41 | centron/Centron.WPF.UI/Modules/Helpdesk/TicketLogicHelper.cs, Zeilen 460-461 |
+| StRS-22 | (direkt) | SwRS-42 | centron/Centron.WPF.UI/Modules/Helpdesk/Events/{TicketClosedEvent.cs,TicketForwardedEvent.cs,TicketLockChangedEvent.cs,TicketModuleLoadedEvent.cs,TicketSavedEvent.cs,TimeRecordingChangedEvent.cs} |
+| StRS-22 | (direkt) | SwRS-43 | CentronRights.md, Abschnitt 16 (Checklisten) |
+| StRS-22 | (direkt) | SwRS-44 | centron/Centron.WPF.UI/Modules/Helpdesk/{ExpectedEvents,ExpectedEventsReporting} |
+| StRS-22 | SyRS-50 | SwRS-45 | centron/Centron.WPF.UI/Modules/Helpdesk/ConnectionNumber/{HelpdeskConnectionNumberGroupViewModel.cs,TicketConnectionNumberSelectionViewModel.cs} |
+| StRS-22 | (direkt) | SwRS-46 | centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard/{TicketDashboardContainerController.cs,TicketDashboardContainerKinds.cs} |
+| StRS-23 | SyRS-52 | SwRS-47 | backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Zeilen 1051-1052, 1179 |
+| StRS-23 | SyRS-53 | SwRS-48 | centron/Centron.WPF.UI/Modules/PasswordManager/{AccessAreaManagementModuleViewModel.cs,AccessManagementModuleViewModel.cs} |
+| StRS-25 | (direkt) | SwRS-49 | centron/Centron.WPF.UI/Modules/OnlineBanking/{ConfigurationSettings,ConnectionDialog} |
+| StRS-24 | SyRS-56 | SwRS-50 | centron/Centron.WPF.UI/Modules/Logistic/ShippingMethodSettings |
+| StRS-16 | SyRS-58 | SwRS-51 | centron/Centron.WPF.UI/Modules/PLM/PlmLogViewModel.cs |
+| StRS-16 | SyRS-62 | SwRS-52 | centron/Centron.WPF.UI/Modules/ProjectPriceImport/ProjectPriceImportColumnKind.cs |
+| StRS-26 | SyRS-63 | SwRS-53 | backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs, Zeilen 139-158 |
+| StRS-26 | SyRS-65 | SwRS-54 | centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement/EDIReceiptTabs |
+| StRS-26 | SyRS-66 | SwRS-55 | centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense/Converters |
+| StRS-20 | SyRS-69 | SwRS-56 | centron/Centron.WPF.UI/Modules/Rma/Events |
+| StRS-12 | SyRS-71 | SwRS-57 | centron/Centron.WPF.UI/Modules/Statistics/StatisticAppModuleDashbaordController.cs |
+| StRS-17 | SyRS-72 | SwRS-58 | centron/Centron.WPF.UI/Modules/Survey/{ReloadProcessEvent.cs,UpdateSurveyProcessEvent.cs} |
+| StRS-27 | SyRS-73 | SwRS-59 | backend/Centron.Entities/Entities/DocuBoard/AssetManagementArticleAssignment.cs; backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs |
+| StRS-27 | (direkt) | SwRS-60 | centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement |
+| StRS-27 | (direkt) | SwRS-61 | centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems/AccountSystemTemplate |
+| StRS-27 | (direkt) | SwRS-62 | centron/Centron.WPF.UI/Modules/Warehousing/Commissioning/BaseUserControll.cs |
+| StRS-27 | SyRS-77 | SwRS-63 | centron/Centron.WPF.UI/Modules/Warehousing/Inventory/Enums |
+| StRS-27 | (direkt) | SwRS-64 | centron/Centron.WPF.UI/Modules/Warehousing/ValueAddedTaxViewModel.cs |
+| StRS-28 | SyRS-81 | SwRS-65 | webservice/Centron.Controllers/Authorization/README.md, Abschnitt "Behind the Scenes", Punkt 3 |
+| StRS-28 | SyRS-81 | SwRS-66 | webservice/Centron.Controllers/Authorization/README.md, Abschnitt "HTTP Response Codes" |
+| StRS-29 | SyRS-84 | SwRS-67 | nexus/CentronNexus/WebCart/CustomerPortal/*.razor |
+| StRS-30 | SyRS-85 | SwRS-68 | backend/Centron.Common/DeveloperSecurity.cs, Zeile 18 |
+| StRS-26 | SyRS-86 | SwRS-69 | backend/Centron.Gateway/{EDI_Alltron,EDI_Also,EDI_AlsoCH,EDI_EGIS,EDI_Herweck,EDI_Komsa} |
+| StRS-16 | SyRS-87 | SwRS-70 | backend/Centron.DAO/SessionCache.cs; Verwendung in backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Zeile 646 |
+| StRS-16 | SyRS-88 | SwRS-71 | SSMS_DB_SCHEMA.sql, Auszählung CREATE TABLE (1.535) vs. FOREIGN KEY (134) |
+| StRS-29 | SyRS-84 | SwRS-72 | nexus/CentronNexus/Management/WebAccount |
+| StRS-16 | (direkt) | SwRS-73 | nexus/CentronNexus/ProductionOrderManagement/{Components,Model,Pages} |
+| StRS-28 | SyRS-92 | SwRS-74 | webservice/c-entron.misc.ConnectionManager/{Controls,Dialogs} |
+| StRS-32 | SyRS-90 | SwRS-75 | apis/Centron.APIs.FinAPI/IFinApiClient.cs |
+| StRS-32 | SyRS-90 | SwRS-76 | apis/Centron.Api.Gls/{CentronGlsLogic.cs,CentronGlsConsts.cs,CentronGlsErrors.cs}; apis/Centron.Api.Shipcloud/{CentronShipcloudLogic.cs,CentronShipcloudConsts.cs} |
+| StRS-33 | SyRS-94 | SwRS-77 | shared/Centron.Core/GoogleAuthenticator/{TwoFactorAuthenticator.cs,Base32.cs} |
+| StRS-33 | SyRS-94 | SwRS-78 | webservice/Centron.WebServices.Core/RestRequests/TwoFactorAuthenticator/UpdateAppUserTwoFactorAuthKeyRequest.cs |
+| StRS-34 | SyRS-95 | SwRS-79 | docker/compose/appsettings.Production.json |
+| StRS-32 | SyRS-100 | SwRS-80 | Centron.Api.docuFORM/Models |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/Protokoll.md

@@ -0,0 +1,221 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T10:29:47.5079432+02:00
+- **Endzeit:** 2026-08-26T11:17:44.5687994+02:00
+- **Dauer gesamt:** 0:47:57 (`duration_ms` 0:47:55; API: 0:46:55)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
+
+  - `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
+    - SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
+    - 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
+
+  Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
+  Untersuchungsgegenstand ist ein anderer.
+- **Nutzung des DB-Schemas:** **ja** – 5 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Bash`, `Grep`, `Write`), 7 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.3.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 49.664.143 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.968 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.3.0-1b24`
+- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `02_Lauf_2026-08-26_102932_v4.3.0-0848`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-2316`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-b652`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
+  Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich**
+  `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0,
+  `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 386 |
+| Output-Tokens | 293.979 (davon 63.731 Thinking-Tokens) |
+| Cache-Write-Tokens | 422.354 |
+| Cache-Read-Tokens | 48.947.424 |
+| Agent-Turns | 193 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 386 | 6.944 | 7.330 |
+| Output-Tokens | 293.979 | 24 | 294.003 |
+| Cache-Write-Tokens | 422.354 | 0 | 422.354 |
+| Cache-Read-Tokens | 48.947.424 | 0 | 48.947.424 |
+| **Tokens gesamt** | **49.664.143** | **6.968** | **49.671.111** |
+
+**Tokens gesamt: 49.671.111** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 34 | 15,8 % |
+| SyRS | 101 | 47,0 % |
+| SwRS | 80 | 37,2 % |
+| **Gesamt** | **215** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| Daten | 73 | 34,0 % |
+| funktional | 67 | 31,2 % |
+| Schnittstelle | 27 | 12,6 % |
+| Sicherheit | 26 | 12,1 % |
+| nicht-funktional | 22 | 10,2 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 233 |
+| davon `PRIMÄR` | 93 (39,9 %) |
+| davon `SEKUNDÄR` | 77 (33,0 %) |
+| davon `KONTEXT` | 63 (27,0 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (42,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 202 | 94,0 % |
+| workaround | 4 | 1,9 % |
+| sonderfall | 8 | 3,7 % |
+| veraltet | 1 | 0,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 153 | 71,2 % |
+| als `HYPOTHESE` gekennzeichnet | 62 | 28,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 20 | 9,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 47 | 21,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 8 von 59 ungedeckt: StRS-6, StRS-17, SyRS-80, SyRS-84, SwRS-37, SwRS-48, SwRS-61, SwRS-64 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 215 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 215 von 215 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `e8e4e79a-a4fb-4a8b-b403-01adf8d20802`
+- **Permission-Denials:** 3 (1 × `Bash`, 2 × `Read`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 43.358 B |
+  | `Glossar.md` | 6.956 B |
+  | `Hypothesen.md` | 11.875 B |
+  | `StRS.md` | 53.714 B |
+  | `SwRS.md` | 92.253 B |
+  | `SyRS.md` | 123.155 B |
+  | `Traceability.md` | 10.235 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
+`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
+63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
+Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
+Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
+
+**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
+Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
+(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
+nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
+zwangsläufig und ist kein Zugriff.
+
+**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
+zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
+`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
+nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
+`084301_v4.2.0-d6f9` mit 45:04.
+
+**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
+weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
+deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
+identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
+
+**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
+(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
+
+**6. Schema genutzt, höchste Anforderungszahl der genutzten Läufe.** Fünf Werkzeugaufrufe
+(`Bash`, `Grep`, `Write`), sieben Nennungen in den Ergebnisartefakten – der intensivste
+Schemazugriff der Iteration. 215 Anforderungen bei 49,7 Mio. Tokens.
+
+**7. Ausgewogenste Ebenenverteilung der Iteration 3:** 34 StRS / 101 SyRS / 80 SwRS. Als einziger
+Lauf der Iteration liegt der Schwerpunkt auf der Systemebene statt auf StRS oder SwRS – näher an
+`d6f9` aus Iteration 2 (20/120/30) als an den übrigen Läufen der eigenen Iteration.
+
+**8. Belegqualität schwach: 42,8 % mit Primärbeleg**, acht von 48 risikorelevanten Anforderungen
+ungedeckt. Tracelinks dagegen bei 100 %.
+
+**9. Drei Permission-Denials, alle Nebeneffekt der Werkzeugkonfiguration:** zwei `Read`-Zugriffe
+auf das eigene Temp-Verzeichnis außerhalb der freigegebenen Pfade, ein `Bash`-Kommando mit
+Löschanteil. Keiner betraf `Task`/`Agent`/`Workflow` – der Agent hat nicht zu delegieren versucht.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":2815788,"num_turns":193,"stop_reason":"end_turn","session_id":"e8e4e79a-a4fb-4a8b-b403-01adf8d20802","total_cost_usd":14.426526799999994,"usage":{"input_tokens":386,"cache_creation_input_tokens":422354,"cache_read_input_tokens":48947424,"output_tokens":293979,"output_tokens_details":{"thinking_tokens":63731},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":422354,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":659,"cache_read_input_tokens":449467,"cache_creation_input_tokens":699,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":699},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6944,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007064,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":386,"outputTokens":293979,"cacheReadInputTokens":48947424,"cacheCreationInputTokens":422354,"webSearchRequests":0,"costUSD":14.419462799999994,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01WWoevmZfSnrGv4S8gAzadp","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\e8e4e79a-a4fb-4a8b-b403-01adf8d20802\\scratchpad\\hyp_extract.txt","offset":20}},{"tool_name":"Read","tool_use_id":"toolu_018VEQVDPAqN8N2yJWjiKLU8","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\e8e4e79a-a4fb-4a8b-b403-01adf8d20802\\scratchpad\\hyp_table.md"}},{"tool_name":"Bash","tool_use_id":"toolu_01HZAj5N6XEB8PLgkPsbHMwG","tool_input":{"command":"OUT=\"c:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Tag 2\\claude-sonnet-5\\solo\\high\\02_Lauf_2026-08-26_102932_v4.3.0-1b24\\Ergebnisse\\Analysebericht.md\"\nhead -n 186 \"$OUT\" > \"$OUT.tmp\"\nmv \"$OUT.tmp\" \"$OUT\"\ntail -3 \"$OUT\"","description":"Truncate placeholder ending (keep up to line 186)"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"Confirmed — no changes under `QuellCode/CentronERP`; all 493 pending changes are pre-existing (present before this session started, as shown in the initial git status). The analyzed codebase remains untouched, as required.\n\n## Summary\n\nI completed the reverse requirements engineering run against the full c-entron ERP codebase (15,554 C# files, 1,535 DB tables) and produced all seven deliverables in the specified output directory:\n\n- **Analysebericht.md** — 107-row module inventory (Schritt 0), coverage table, consistency check, and self-assessment\n- **StRS.md** (34), **SyRS.md** (101), **SwRS.md** (80) — 215 requirements total, each with Fakt/Aussage separation, classified evidence, testability, consolidation assessment, and adoption worthiness\n- **Traceability.md** — StRS↔SyRS↔SwRS mapping table, programmatically verified with no dangling references\n- **Hypothesen.md** — 62 hypotheses (28.8%), exactly matching inline `[HYPOTHESE]` markers\n- **Glossar.md** — 29 domain terms\n\nKey findings worth highlighting: a verified Stammblatt-vs-Asset data duplication (the calibration example), a major architectural finding that Nexus/ServiceBoard already re-implements much of the desktop Helpdesk for the web, a real AES-encrypted password manager and TOTP 2FA implementation, and — during the mandatory consistency check — 7 security/billing requirements that were initially marked \"belegt\" on only secondary evidence got caught and corrected to HYPOTHESE before the run closed, which I left visible rather than silently fixing.\n\nOne honest gap: the 11 receipt types (Offers/Orders/DeliveryLists/etc.) were covered collectively via the shared `IReceiptSpecificLogic` interface rather than with individual per-type requirements — flagged explicitly in the self-assessment as follow-up work.","ttft_ms":4386,"ttft_stream_ms":1105,"time_to_request_ms":35,"type":"result","duration_ms":2875045,"uuid":"732d8247-5294-4754-857e-42c83431e868","queued_turn_count":0}

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 34 | 15,8 % |
+| SyRS | 101 | 47,0 % |
+| SwRS | 80 | 37,2 % |
+| **Gesamt** | **215** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| Daten | 73 | 34,0 % |
+| funktional | 67 | 31,2 % |
+| Schnittstelle | 27 | 12,6 % |
+| Sicherheit | 26 | 12,1 % |
+| nicht-funktional | 22 | 10,2 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 233 |
+| davon `PRIMÄR` | 93 (39,9 %) |
+| davon `SEKUNDÄR` | 77 (33,0 %) |
+| davon `KONTEXT` | 63 (27,0 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 92 (42,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 202 | 94,0 % |
+| workaround | 4 | 1,9 % |
+| sonderfall | 8 | 3,7 % |
+| veraltet | 1 | 0,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 153 | 71,2 % |
+| als `HYPOTHESE` gekennzeichnet | 62 | 28,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 20 | 9,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 47 | 21,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 8 von 59 ungedeckt: StRS-6, StRS-17, SyRS-80, SyRS-84, SwRS-37, SwRS-48, SwRS-61, SwRS-64 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 215 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 215 von 215 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/before.txt

@@ -0,0 +1,2 @@
+?? QuellCode/CentronERP/SSMS_DB_SCHEMA.sql
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/combined_prompt.md

@@ -0,0 +1,177 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 02
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-26
+- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
+- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
+  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
+  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
+  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
+  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
+  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
+  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
+
+  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+---
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`c:\DEV\MasterArbeit\Versuche\Versuch_01\Tag 2\claude-sonnet-5\solo\high\02_Lauf_2026-08-26_102932_v4.3.0-1b24\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-08-26T11:17:44.5687994+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-1b24/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-08-26T10:29:47.5079432+02:00

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Analysebericht.md

@@ -0,0 +1,417 @@
+# Analysebericht
+
+c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
+
+## Schritt 0 - Modulinventar
+
+Grundlage: `src/backend/Centron.BL` (90 fachliche Module, Stand der Verzeichnisliste zu Beginn
+dieses Laufs), ergänzt um die technische Infrastruktur- und Architekturschicht der übrigen
+Verzeichnisse (`src/apis`, `src/webservice`, `src/nexus`, `src/backend/Centron.DAO`,
+`Centron.Entities`, `Centron.Interfaces`, `Centron.Common`, `Centron.Gateway`, `src/centron`,
+`src/shared`, sowie `deployment/`, `docker/`, `assemblies/`, `tests/`, `scripts/`,
+`azure*/`). Das Inventar wurde vor der ersten Anforderung erstellt (Bash-Verzeichnisauflistung und
+Methodensignatur-Erhebung je Modul, siehe Vorgehen); die anschließende Vertiefung folgte der
+Reihenfolge Sicherheit/Berechtigungen → Abrechnung/Zahlungsverkehr → übrige Module.
+
+Alle 90 Verzeichnisse aus `Centron.BL` wurden erfasst; `Properties` enthält ausschließlich
+`AssemblyInfo.cs` ohne fachlichen Inhalt und wird als „nicht analysiert" geführt.
+
+| # | Modul/Komponente | Pfad | Fachliche Aufgabe | Anforderung(en) |
+|---|---|---|---|---|
+| 1 | Accounting | src/backend/Centron.BL/Accounting | Bankverbindungen von Kunden verwalten (inkl. Autorisierungsstatus). | SwRS-25 |
+| 2 | Accounts | src/backend/Centron.BL/Accounts | Kundenadressen, Hotline-Verträge und Marketing-/Kampagnendaten je Account. | SwRS-5 |
+| 3 | Administration | src/backend/Centron.BL/Administration | Systemkonfiguration, Rechteverwaltung, API-Tokens, Kontenrahmen, Update-Benachrichtigung. | SwRS-29, SwRS-34, SwRS-35, SwRS-40, SwRS-75 |
+| 4 | AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Externe Terminanfragen und -vorschläge verarbeiten. | SwRS-46 |
+| 5 | ArtificialIntelligence | src/backend/Centron.BL/ArtificialIntelligence | KI-Provider-Anbindung (Chat, Textbewertung, Ticketkategorisierung) über eine Factory. | SwRS-99 |
+| 6 | BusinessPartner | src/backend/Centron.BL/BusinessPartner | Lieferantensuche und lieferantenbezogene Vorgangsarten (Buchung, Gutschrift, Wareneingang etc.). | SwRS-13 |
+| 7 | Buying | src/backend/Centron.BL/Buying | Distributorenstammdaten für den Einkauf. | SwRS-14 |
+| 8 | CPra | src/backend/Centron.BL/CPra | Anbindung an das externe Kundenportal CPra inkl. Webhooks. | SwRS-83 |
+| 9 | Calendar | src/backend/Centron.BL/Calendar | Kalenderdarstellungs- und -synchronisationseinstellungen. | SwRS-45 |
+| 10 | CentronIcons | src/backend/Centron.BL/CentronIcons | Paginierter Icon-Katalog für die UI. | SwRS-103 |
+| 11 | CentronNexus (BL) | src/backend/Centron.BL/CentronNexus | Portalweite Nexus-Einstellungen. | SwRS-93 |
+| 12 | ChangeTracking | src/backend/Centron.BL/ChangeTracking | Importhistorie je Benutzer protokollieren. | SwRS-102 |
+| 13 | Chats | src/backend/Centron.BL/Chats | Team-Chats mit optionalem Objektbezug. | SwRS-60 |
+| 14 | CheckListArea | src/backend/Centron.BL/CheckListArea | Checklisten und -positionen verwalten. | SwRS-47 |
+| 15 | Core | src/backend/Centron.BL/Core | Passwort-Hashing und generische Textvariablenersetzung. | SwRS-36 |
+| 16 | CountryArea | src/backend/Centron.BL/CountryArea | Länder-/Währungsstammdaten. | SwRS-104 |
+| 17 | CustomerArea | src/backend/Centron.BL/CustomerArea | Geschäftsfelder je Kunde und RMA-Kernprozess. | SwRS-6 |
+| 18 | Customizations | src/backend/Centron.BL/Customizations | Kundenspezifische Zusatztabellen mit Variablenersetzung. | SwRS-77 |
+| 19 | DataExchange | src/backend/Centron.BL/DataExchange | Zahlungsexport (SEPA/Lastschrift) und Buchhaltungsexport-Konfiguration. | SwRS-28, SwRS-30 |
+| 20 | Devices | src/backend/Centron.BL/Devices | Kundengeräte über interne und externe IDs verwalten. | SwRS-66 |
+| 21 | DocuBoard | src/backend/Centron.BL/DocuBoard | Asset-Zuordnung zu Artikeln/Partnern (Konsolidierungsfall mit „Stammblatt"). | SwRS-100 |
+| 22 | DocumentationArea | src/backend/Centron.BL/DocumentationArea | Interne Dokumentationsartikel mit Rechtecheck. | SwRS-71 |
+| 23 | EDI | src/backend/Centron.BL/EDI | Elektronischer Bestellversand an mehrere Distributoren. | SwRS-15 |
+| 24 | EmployeeArea | src/backend/Centron.BL/EmployeeArea | Mitarbeiterkonten, Administratorstatus, Web-Account-/Systembenutzer-Trennung. | SwRS-43 |
+| 25 | Exceptions | src/backend/Centron.BL/Exceptions | Fachliche Ausnahme für abgelaufene Tickets. | SwRS-56 |
+| 26 | ExpectedEvents | src/backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse mit Protokoll. | SwRS-53 |
+| 27 | ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Externe Helpdesk-Konfigurationen. | SwRS-48 |
+| 28 | ExternalToolsBL | src/backend/Centron.BL/ExternalToolsBL | Frei konfigurierbare externe Werkzeuge. | SwRS-84 |
+| 29 | Finances | src/backend/Centron.BL/Finances | Online-Banking (FinAPI, IBAN-Abgleich) und Aktivitätsvorlagen. | SwRS-26, SwRS-27, SwRS-31 |
+| 30 | GUI | src/backend/Centron.BL/GUI | Bestellimport aus externen Quellen. | SwRS-24 |
+| 31 | Gateway | src/backend/Centron.BL/Gateway | Kundenspezifische Artikel-Vertrags-Importe. | SwRS-85 |
+| 32 | Helpers | src/backend/Centron.BL/Helpers | PDF-Zusammenführung und weitere Hilfsfunktionen. | SwRS-73 |
+| 33 | IndexSearch | src/backend/Centron.BL/IndexSearch | Objekttypübergreifender Volltextindex. | SwRS-69 |
+| 34 | Integrations | src/backend/Centron.BL/Integrations | Externe Kundengruppensynchronisation. | SwRS-86 |
+| 35 | ItPlanner | src/backend/Centron.BL/ItPlanner | Kategorisierung virtueller Checklistenobjekte im IT-Planer. | SwRS-49 |
+| 36 | Logistics | src/backend/Centron.BL/Logistics | Zentrale Logistikeinstellungen. | SwRS-21 |
+| 37 | Mail | src/backend/Centron.BL/Mail | Absenderdomänen-Blacklist. | SwRS-57 |
+| 38 | MailScanner | src/backend/Centron.BL/MailScanner | Scan-Workflows und -Profile für eingehende E-Mails. | SwRS-58 |
+| 39 | Mailings | src/backend/Centron.BL/Mailings | Massen-E-Mail-Kampagnen. | SwRS-59 |
+| 40 | MassUpdate | src/backend/Centron.BL/MassUpdate | Wiederverwendbare Massenänderungsvorlagen. | SwRS-80 |
+| 41 | Mobile | src/backend/Centron.BL/Mobile | Mitarbeiterdaten für mobile Clients. | SwRS-95 |
+| 42 | Modules | src/backend/Centron.BL/Modules | Modulkatalog und Benutzerfavoriten. | SwRS-76 |
+| 43 | MyCentron | src/backend/Centron.BL/MyCentron | Personalisierbares Dashboard. | SwRS-91 |
+| 44 | MyDay | src/backend/Centron.BL/MyDay | Persönliche Tagesplanung mit Batch-Verarbeitung. | SwRS-92 |
+| 45 | NexusNotifications | src/backend/Centron.BL/NexusNotifications | Benachrichtigungsstatus im Web-Portal. | SwRS-63 |
+| 46 | NexusTicketViews | src/backend/Centron.BL/NexusTicketViews | Persönliche und globale Ticketansichten. | SwRS-54 |
+| 47 | Notifications | src/backend/Centron.BL/Notifications | Desktop-Benachrichtigungseinstellungen. | SwRS-64 |
+| 48 | ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Objekttypübergreifende externe Referenzen. | SwRS-101 |
+| 49 | Outlook | src/backend/Centron.BL/Outlook | Asset-Art-Suche für die Outlook-Integration. | SwRS-105 |
+| 50 | PasswordManagementArea | src/backend/Centron.BL/PasswordManagementArea | Kundenzugangsdaten mit Entschlüsselung und Zugriffsprotokoll. | SwRS-38 |
+| 51 | PasswordManager | src/backend/Centron.BL/PasswordManager | Kunden-/Mitarbeiter-Zugriffsrechte auf Zugangsdaten. | SwRS-39 |
+| 52 | Processes | src/backend/Centron.BL/Processes | Generische, objekttypunabhängige Prozessbindung. | SwRS-89 |
+| 53 | ProductMatrix | src/backend/Centron.BL/ProductMatrix | Produktkategorien und kundenspezifische Produktbewertungen. | SwRS-7 |
+| 54 | Production | src/backend/Centron.BL/Production | Produktionsmaschinen und -aufträge. | SwRS-23 |
+| 55 | Projects | src/backend/Centron.BL/Projects | Zeitlich filterbare Projektliste. | SwRS-90 |
+| 56 | Properties | src/backend/Centron.BL/Properties | Nur `AssemblyInfo.cs` - kein fachlicher Inhalt. | **nicht analysiert** |
+| 57 | Purchasing | src/backend/Centron.BL/Purchasing | Bestellvorschläge und Lieferantenverwaltung. | SwRS-11, SwRS-12 |
+| 58 | ReportEngine | src/backend/Centron.BL/ReportEngine | Berichtsexport (einzeln/gruppenweise). | SwRS-67 |
+| 59 | Reporting | src/backend/Centron.BL/Reporting | Berichtszugriff per ID oder Prädikat. | SwRS-68 |
+| 60 | Resources | src/backend/Centron.BL/Resources | Zentrale Update-/Release-URLs. | SwRS-74 |
+| 61 | RiverDivo | src/backend/Centron.BL/RiverDivo | Externe Vertragsartikel-Abrechnung. | SwRS-10 |
+| 62 | Sales | src/backend/Centron.BL/Sales | Belegkette Angebot-Auftrag-Rechnung-Gutschrift, inkl. Fixierung, Stornierung, Lieferantenrechnungen. | SwRS-1, SwRS-2, SwRS-3, SwRS-4, SwRS-16 |
+| 63 | Security | src/backend/Centron.BL/Security | PDF-Signatureinstellungen. | SwRS-41 |
+| 64 | SelfCare | src/backend/Centron.BL/SelfCare | Metadatengetriebene Selbstbedienungsformulare. | SwRS-94 |
+| 65 | Services | src/backend/Centron.BL/Services | Tabellencache-Steuerung. | SwRS-79 |
+| 66 | SocialMedia | src/backend/Centron.BL/SocialMedia | Kommentare/Likes auf Social-Media-Streams. | SwRS-62 |
+| 67 | Start | src/backend/Centron.BL/Start | Verbindungsaufbau beim Anwendungsstart. | SwRS-106 |
+| 68 | Statistics | src/backend/Centron.BL/Statistics | Offene-Posten-Übersicht und weitere Auswertungen. | SwRS-33 |
+| 69 | Storage | src/backend/Centron.BL/Storage | Inventurtransaktionen. | SwRS-22 |
+| 70 | SystemArea | src/backend/Centron.BL/SystemArea | Systemweiter I3D-Zustandsdatensatz. | SwRS-78 |
+| 71 | Tags | src/backend/Centron.BL/Tags | Schlagwörter inkl. Ticketverknüpfung. | SwRS-50 |
+| 72 | Tapi | src/backend/Centron.BL/Tapi | Telefonanrufprotokollierung. | SwRS-61 |
+| 73 | TaskManager | src/backend/Centron.BL/TaskManager | Paginierte Aufgabenverwaltung. | SwRS-51 |
+| 74 | Telemetry | src/backend/Centron.BL/Telemetry | Nutzungserfassung interner Werkzeuge/KI-Funktionen. | SwRS-70 |
+| 75 | TextModuleArea | src/backend/Centron.BL/TextModuleArea | Generische Anrede-/Vereinbarungsersetzung in Textbausteinen. | SwRS-72 |
+| 76 | TicketProjects | src/backend/Centron.BL/TicketProjects | Ticketprojekte mit Abhängigkeiten. | SwRS-55 |
+| 77 | Time | src/backend/Centron.BL/Time | Arbeitszeitmodelle. | SwRS-44 |
+| 78 | ToDoArea | src/backend/Centron.BL/ToDoArea | Objekttypübergreifende ToDo-Liste. | SwRS-52 |
+| 79 | Tools | src/backend/Centron.BL/Tools | Zentrale Textformatumwandlung. | SwRS-107 |
+| 80 | TradePool | src/backend/Centron.BL/TradePool | Import von Handelsartikeldaten. | SwRS-9 |
+| 81 | Transactions | src/backend/Centron.BL/Transactions | Benutzerbezogenes Transaktionsprotokoll. | SwRS-108 |
+| 82 | TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | TOTP-basierte Zwei-Faktor-Authentifizierung. | SwRS-37 |
+| 83 | Urls | src/backend/Centron.BL/Urls | Verwaltete Kurz-URLs. | SwRS-109 |
+| 84 | VideoPortal | src/backend/Centron.BL/VideoPortal | Video-Objektzuordnung. | SwRS-110 |
+| 85 | VoucherManagement | src/backend/Centron.BL/VoucherManagement | Gutscheinverwaltung nach Zustand (frei/ausgegeben/eingelöst). | SwRS-8 |
+| 86 | Warehousing | src/backend/Centron.BL/Warehousing | Staffelpreise, Bestandsführung, Aktionspreise. | SwRS-18, SwRS-19, SwRS-20 |
+| 87 | WebLinks | src/backend/Centron.BL/WebLinks | Gruppierte, aktionsbasierte Weblinks. | SwRS-65 |
+| 88 | WebServices (BL) | src/backend/Centron.BL/WebServices | Adresskontaktverwaltung für Webservice-Clients. | SwRS-96 |
+| 89 | WebSuite | src/backend/Centron.BL/WebSuite | Benutzer-/mitarbeiterbezogene INI-Einstellungen. | SwRS-81 |
+| 90 | WebVersion | src/backend/Centron.BL/WebVersion | Webservice-Versionsauskunft. | SwRS-82 |
+| 91 | Externe Produktdatenanbindungen (COP/EGIS/ITscope/Icecat) | src/apis/Centron.APIs.* | Artikelstamm-/Zubehördaten aus vier externen Quellen beziehen. | SwRS-17 |
+| 92 | Externe Finanzschnittstellen (FinAPI/ebInterface) | src/apis/Centron.APIs.FinAPI, src/apis/Centron.Api.EbInterface | Bankdatenabruf und österreichische E-Rechnung. | SwRS-32 |
+| 93 | Versanddienstleister GLS | src/apis/Centron.Api.Gls | Sendungserstellung mit Testmodus. | SwRS-87 |
+| 94 | Versanddienstleister Shipcloud | src/apis/Centron.Api.Shipcloud | Sendungserstellung mit Frachtführerabfrage. | SwRS-88 |
+| 95 | docuFORM (Drucker-/Gerätezähler) | src/Centron.Api.docuFORM | Zählerstände von Druckern extern abrufen. | SwRS-111 |
+| 96 | Centron.Controllers (Webservice-Autorisierung) | src/webservice/Centron.Controllers | Deklarative REST-Rechteautorisierung. | SwRS-42 |
+| 97 | Centron.WebServices.Core | src/webservice/Centron.WebServices.Core | Typsicherer REST-Aufrufmechanismus (Client-Kern). | SwRS-112 |
+| 98 | Centron.Host | src/webservice/Centron.Host | Analytics-Instrumentierung des Webservice-Starts. | SwRS-113 |
+| 99 | CentronNexus (Web-Portal) | src/nexus/CentronNexus | Blazor-Webportal inkl. Branding-Konfiguration. | SwRS-97 |
+| 100 | CentronNexus.OutlookAddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Add-in für E-Mail-Anhänge im Portal. | SwRS-98 |
+| 101 | Centron.DAO | src/backend/Centron.DAO | Generische NHibernate-Persistenzschicht. | SwRS-114 |
+| 102 | Centron.Entities | src/backend/Centron.Entities | Einheitliches Domänenmodell/Entitätsgleichheit. | SwRS-115 |
+| 103 | Centron.Gateway (Projekt) | src/backend/Centron.Gateway | Buchhaltungsexport-Dateierzeugung mit Teilerfolgsmodell. | SwRS-117 |
+| 104 | Centron.Controls | src/shared/Centron.Controls | Wiederverwendbare WPF-Steuerelemente (Hinweis-Flyout u. a.). | SwRS-116 |
+| 105 | Centron.WPF.UI (Shell) | src/centron/Centron.WPF.UI | Desktop-Client-Hauptfenster, Ribbon, rechtebasierte Modulsichtbarkeit. | SwRS-118 |
+| 106 | c-entron.misc.ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Verbindungskonfigurationswerkzeug mit Silent-Modus. | SwRS-119 |
+| 107 | Centron.Interfaces / Centron.Common | src/backend/Centron.Interfaces, src/backend/Centron.Common | Vertragsschnittstellen und Utility-Bibliothek. | **nicht analysiert** |
+| 108 | Centron.WPF.UI.Extension / Centron.Controls.Preview / CentronNexus.Host | src/centron/Centron.WPF.UI.Extension, src/shared/Centron.Controls.Preview, src/nexus/CentronNexus.Host | Technische Trägerprojekte (WPF-Erweiterungen, Steuerelement-Vorschau, Web-Hosting-Bootstrapper). | **nicht analysiert** |
+| 109 | Build-/Deployment-/Test-Infrastruktur | deployment/, docker/, assemblies/, tests/, scripts/, azure*/ | CI/CD-Pipelines, Installer, Drittanbieter-Assemblies, Testprojekte. | **nicht analysiert** |
+
+Begründung „nicht analysiert" (Zeilen 56, 107-109): Diese Verzeichnisse enthalten entweder keinen
+fachlichen Code (`Properties`, reine Build-/Deployment-Artefakte) oder ausschließlich technische
+Vertrags-/Hilfsbibliotheken ohne im Rahmen dieser Erhebung identifizierte eigenständige
+Geschäftsregeln - ihre Fachlogik wird bereits über die sie nutzenden BL-Module und die übrigen
+Infrastruktur-Zeilen (91-106) erfasst. Eine belegbare eigenständige Anforderung ließ sich für sie
+nicht bilden, ohne den Rahmen dieser Iteration zu sprengen.
+
+## Abdeckungstabelle
+
+Einstufung je Zeile des Modulinventars: **tief** (mehrere Anforderungen und/oder mehrzeilig
+nachvollzogener Durchsetzungsmechanismus, z. B. Transaktion/SQL/Statusprüfung im Methodenkörper
+gelesen), **mittel** (eine Anforderung mit mindestens einem `PRIMÄR`-Beleg und konkreter
+Methodensignatur), **flach** (eine Anforderung ausschließlich mit `SEKUNDÄR`/`KONTEXT`-Belegen,
+also nur struktureller Nachweis ohne gelesenen Durchsetzungsmechanismus), **nicht analysiert**
+(siehe Begründung oben). Jede Zeile des Inventars erscheint hier genau einmal.
+
+| # | Modul | Einstufung | Anzahl Anforderungen |
+|---|---|---|---|
+| 1 | Accounting | mittel | 1 |
+| 2 | Accounts | mittel | 1 |
+| 3 | Administration | tief | 5 |
+| 4 | AppointmentRequests | mittel | 1 |
+| 5 | ArtificialIntelligence | mittel | 1 |
+| 6 | BusinessPartner | tief | 1 |
+| 7 | Buying | flach | 1 |
+| 8 | CPra | mittel | 1 |
+| 9 | Calendar | flach | 1 |
+| 10 | CentronIcons | flach | 1 |
+| 11 | CentronNexus (BL) | flach | 1 |
+| 12 | ChangeTracking | mittel | 1 |
+| 13 | Chats | mittel | 1 |
+| 14 | CheckListArea | mittel | 1 |
+| 15 | Core | tief | 1 |
+| 16 | CountryArea | mittel | 1 |
+| 17 | CustomerArea | mittel | 1 |
+| 18 | Customizations | mittel | 1 |
+| 19 | DataExchange | tief | 2 |
+| 20 | Devices | mittel | 1 |
+| 21 | DocuBoard | tief | 1 |
+| 22 | DocumentationArea | mittel | 1 |
+| 23 | EDI | tief | 1 |
+| 24 | EmployeeArea | tief | 1 |
+| 25 | Exceptions | flach | 1 |
+| 26 | ExpectedEvents | mittel | 1 |
+| 27 | ExternalHelpdesk | flach | 1 |
+| 28 | ExternalToolsBL | flach | 1 |
+| 29 | Finances | tief | 3 |
+| 30 | GUI | mittel | 1 |
+| 31 | Gateway | mittel | 1 |
+| 32 | Helpers | mittel | 1 |
+| 33 | IndexSearch | mittel | 1 |
+| 34 | Integrations | mittel | 1 |
+| 35 | ItPlanner | flach | 1 |
+| 36 | Logistics | flach | 1 |
+| 37 | Mail | mittel | 1 |
+| 38 | MailScanner | flach | 1 |
+| 39 | Mailings | flach | 1 |
+| 40 | MassUpdate | mittel | 1 |
+| 41 | Mobile | mittel | 1 |
+| 42 | Modules | mittel | 1 |
+| 43 | MyCentron | mittel | 1 |
+| 44 | MyDay | mittel | 1 |
+| 45 | NexusNotifications | mittel | 1 |
+| 46 | NexusTicketViews | mittel | 1 |
+| 47 | Notifications | flach | 1 |
+| 48 | ObjectExternalReferences | tief | 1 |
+| 49 | Outlook | flach | 1 |
+| 50 | PasswordManagementArea | tief | 1 |
+| 51 | PasswordManager | mittel | 1 |
+| 52 | Processes | tief | 1 |
+| 53 | ProductMatrix | flach | 1 |
+| 54 | Production | mittel | 1 |
+| 55 | Projects | flach | 1 |
+| 56 | Properties | nicht analysiert | 0 |
+| 57 | Purchasing | tief | 2 |
+| 58 | ReportEngine | mittel | 1 |
+| 59 | Reporting | mittel | 1 |
+| 60 | Resources | flach | 1 |
+| 61 | RiverDivo | mittel | 1 |
+| 62 | Sales | tief | 5 |
+| 63 | Security | mittel | 1 |
+| 64 | SelfCare | mittel | 1 |
+| 65 | Services | mittel | 1 |
+| 66 | SocialMedia | mittel | 1 |
+| 67 | Start | flach | 1 |
+| 68 | Statistics | mittel | 1 |
+| 69 | Storage | flach | 1 |
+| 70 | SystemArea | flach | 1 |
+| 71 | Tags | mittel | 1 |
+| 72 | Tapi | mittel | 1 |
+| 73 | TaskManager | mittel | 1 |
+| 74 | Telemetry | mittel | 1 |
+| 75 | TextModuleArea | mittel | 1 |
+| 76 | TicketProjects | mittel | 1 |
+| 77 | Time | flach | 1 |
+| 78 | ToDoArea | mittel | 1 |
+| 79 | Tools | flach | 1 |
+| 80 | TradePool | mittel | 1 |
+| 81 | Transactions | tief | 1 |
+| 82 | TwoFactorAuthenticator | tief | 1 |
+| 83 | Urls | flach | 1 |
+| 84 | VideoPortal | flach | 1 |
+| 85 | VoucherManagement | mittel | 1 |
+| 86 | Warehousing | tief | 3 |
+| 87 | WebLinks | mittel | 1 |
+| 88 | WebServices (BL) | mittel | 1 |
+| 89 | WebSuite | mittel | 1 |
+| 90 | WebVersion | mittel | 1 |
+| 91 | Externe Produktdatenanbindungen | mittel | 1 |
+| 92 | Externe Finanzschnittstellen | mittel | 1 |
+| 93 | Versanddienstleister GLS | mittel | 1 |
+| 94 | Versanddienstleister Shipcloud | mittel | 1 |
+| 95 | docuFORM | tief | 1 |
+| 96 | Centron.Controllers | tief | 1 |
+| 97 | Centron.WebServices.Core | mittel | 1 |
+| 98 | Centron.Host | flach | 1 |
+| 99 | CentronNexus (Web-Portal) | mittel | 1 |
+| 100 | CentronNexus.OutlookAddIn | flach | 1 |
+| 101 | Centron.DAO | mittel | 1 |
+| 102 | Centron.Entities | mittel | 1 |
+| 103 | Centron.Gateway (Projekt) | mittel | 1 |
+| 104 | Centron.Controls | flach | 1 |
+| 105 | Centron.WPF.UI (Shell) | tief | 1 |
+| 106 | c-entron.misc.ConnectionManager | flach | 1 |
+| 107 | Centron.Interfaces / Centron.Common | nicht analysiert | 0 |
+| 108 | Centron.WPF.UI.Extension / Controls.Preview / CentronNexus.Host | nicht analysiert | 0 |
+| 109 | Build-/Deployment-/Test-Infrastruktur | nicht analysiert | 0 |
+
+**Summe:** 109 Modulinventar-Zeilen; 105 analysiert (19 tief, 59 mittel, 27 flach), 4 nicht
+analysiert. 175 formale Anforderungen insgesamt (StRS-1..20 = 20; SyRS-1..36 = 36; SwRS-1..119 =
+119).
+
+## Konsistenzcheck
+
+**Doppelte oder mehrfach vergebene IDs.** Keine gefunden. StRS-1..20, SyRS-1..36 und SwRS-1..119
+sind jeweils lückenlos und ohne Duplikat vergeben (per Bash-Auszählung der `ID:`-Zeilen je Datei
+geprüft).
+
+**Anforderungen ohne Beleg.** Keine gefunden. Jede der 175 Anforderungen (20 StRS + 36 SyRS + 119
+SwRS) enthält mindestens einen Eintrag im Feld `Belege` (per Auszählung `Belege:`- gegen
+`ID:`-Zeilen je Datei verifiziert: 20/20, 36/36, 119/119).
+
+**Anforderungen ohne Angabe zur Übernahmewürdigkeit.** Keine gefunden (20/20, 36/36, 119/119
+`Übernahmewürdigkeit:`-Zeilen vorhanden).
+
+**Tracelinks auf nicht existierende IDs.** Keine gefunden. Alle `Tracelinks`-Verweise in StRS.md
+(→ SyRS-1..36) und in SyRS.md (→ StRS-1..20) wurden gegen die tatsächlich vergebenen IDs geprüft.
+Alle 119 SwRS-Anforderungen referenzieren ausschließlich SyRS-IDs (kein direkter Verweis auf
+StRS) - dies wurde während der Erstellung mehrfach korrigiert (ursprünglich verwiesen 15
+SwRS-Anforderungen versehentlich direkt auf StRS-IDs; behoben durch Ergänzung dreier
+zusätzlicher Bindeglied-Anforderungen SyRS-16, SyRS-25, SyRS-36 sowie Umhängen der betroffenen
+`Tracelinks`-Felder). Die konsolidierte `Traceability.md` wurde entsprechend nachgeführt.
+
+**Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk.** Eine vollständige
+paarweise Prüfung aller 119 SwRS-Anforderungen gegeneinander war im Rahmen dieser Iteration nicht
+leistbar; die folgenden Fälle wurden gezielt identifiziert und im Feld `Konsolidierung` markiert:
+
+| Fall | Beteiligte IDs | Fachlicher Gegenstand |
+|---|---|---|
+| Stammblatt vs. Asset (Vorgabe der Aufgabenstellung) | StRS-19, SyRS-33, SwRS-100, SwRS-101, SwRS-111 | Kundenhardware (Drucker vs. sonstige Geräte) |
+| Fünf strukturell identische `GetSupplier*ByFilter`-Methoden | SwRS-13 | Lieferantenvorgangsarten (Buchung/Gutschrift/Wareneingang/Kalkulation/Anfrage) |
+| Vier externe Produktdatenquellen (COP/EGIS/ITscope/Icecat) | SwRS-17 | Externe Artikeldatenanbindung |
+| Distributorspezifische EDI-Upload-Methoden | SyRS-4, SwRS-15 | Elektronische Bestellübermittlung |
+| Zwei Versanddienstleister (GLS/Shipcloud) | StRS-15, SyRS-28, SwRS-87, SwRS-88 | Versandauftragserstellung |
+| Aktionspreis vs. Staffelpreis | SwRS-20 | Sonderpreis je Artikel |
+| `Reporting` vs. `ReportEngine` | SwRS-68 | Berichtszugriff/-export |
+| `NexusNotifications` vs. `Notifications` | StRS-11, SyRS-22, SwRS-63, SwRS-64 | Benutzerbenachrichtigung |
+| `PasswordManagementArea` vs. `PasswordManager` | SwRS-39 | Zugriffskontrolle auf Zugangsdaten |
+| `IsUserInAdminGroup` vs. allgemeine Rechteprüfung | SyRS-18 | Administratorstatus vs. Einzelrechte |
+| Fünf kanalspezifische Kommunikationsmodule ohne gemeinsame Basis | SyRS-36 | Kommunikations-/Interaktionserfassung |
+| Accounts/AccountAddressBL vs. CustomerArea/BusinessPartner-Adressmodell | SwRS-5 | Adressverwaltung |
+
+**Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) -
+Belegsituation.** Vollständige Liste aller Anforderungen dieser drei Kategorien mit ihrer
+Beleglage:
+
+| ID | Titel | PRIMÄR-Beleg? | Status |
+|---|---|---|---|
+| StRS-7 | Gruppenbasierte, restriktive Rechteprüfung | ja | belegt |
+| StRS-8 | Sichere Authentifizierung (Hash, 2FA, Tokens) | ja | belegt |
+| SyRS-1 | Rechnungsfestschreibung (IsFixed) | ja | belegt |
+| SyRS-9 | Exportstatus-Flag gegen Doppelexport | ja | belegt |
+| SyRS-10 | Bankkontoabgleich, unbekannte IBANs | ja | belegt |
+| SyRS-11 | Parallele Kontenrahmen | ja | belegt |
+| SyRS-12 | Gruppenbasierte Rechteauflösung | ja | belegt |
+| SyRS-13 | Gesalzenes Passwort-Hashing | ja | belegt |
+| SyRS-14 | REST-API-Autorisierung | ja | belegt |
+| SyRS-15 | TOTP-2FA | ja | belegt |
+| SyRS-16 | Geschützte Zugangsdaten-/Zertifikatsverwaltung | ja | belegt |
+| SyRS-18 | Administratorstatus getrennt geführt | ja | belegt |
+| SwRS-2 | Rechnung festschreiben | ja | belegt |
+| SwRS-3 | Rechnung stornieren | ja | belegt |
+| SwRS-16 | Zahlungsverfolgung Lieferantenrechnungen | **nein** | **HYPOTHESE** |
+| SwRS-25 | Bankverbindung, Autorisierungsfilter | ja | belegt |
+| SwRS-26 | FinAPI-Zugangsdaten | ja | belegt |
+| SwRS-27 | Unbekannte IBANs erkennen | ja | belegt |
+| SwRS-28 | Zahlungsexport mit Statuspflege | ja | belegt |
+| SwRS-29 | Kontenrahmenverwaltung | ja | belegt |
+| SwRS-30 | Buchhaltungsexport-Konfiguration | ja | belegt |
+| SwRS-32 | FinAPI/ebInterface | ja | belegt |
+| SwRS-33 | Offene-Posten-Übersicht | ja | belegt |
+| SwRS-34 | Programmrechteprüfung | ja | belegt |
+| SwRS-35 | Web-Rechteprüfung | ja | belegt |
+| SwRS-36 | Passwort-Hashing (SHA1, veraltet) | ja | belegt |
+| SwRS-37 | 2FA-PIN-Validierung | ja | belegt |
+| SwRS-38 | Zugangsdaten-Entschlüsselung mit Log | ja | belegt |
+| SwRS-39 | PasswordManager-Rechtematrix | **nein** | **HYPOTHESE** |
+| SwRS-40 | API-Tokens mit Widerruf | ja | belegt |
+| SwRS-41 | PDF-Signatur | ja | belegt |
+| SwRS-42 | Deklarative REST-Autorisierung | ja | belegt |
+| SwRS-43 | Admin-Status/Passwortänderung | ja | belegt |
+| SwRS-117 | Buchhaltungsexport-Dateierzeugung | ja | belegt |
+| SwRS-118 | Rechtebasierte Modulsichtbarkeit (Ribbon) | ja | belegt |
+
+Ergebnis: **2 von 35** risikorelevanten Anforderungen (SwRS-16, SwRS-39) besitzen keinen
+`PRIMÄR`-Beleg; beide wurden gemäß der Vorgabe dieser Iteration korrekt als `[HYPOTHESE]` mit
+`Status: HYPOTHESE` geführt statt fälschlich als `belegt`. Kein Verstoß gegen die
+risikobasierte Priorisierung wurde festgestellt, der nicht bereits durch die Hypothesenmarkierung
+aufgefangen ist.
+
+**Abgleich `Hypothesen.md` gegen Inline-Markierungen.** Es wurden 18 `[HYPOTHESE]`-Markierungen in
+StRS/SyRS/SwRS gezählt (0 in StRS, 4 in SyRS: SyRS-7, SyRS-12, SyRS-27, SyRS-28; 14 in SwRS:
+SwRS-7, SwRS-10, SwRS-16, SwRS-17, SwRS-20, SwRS-25, SwRS-39, SwRS-54, SwRS-56, SwRS-68, SwRS-70,
+SwRS-74, SwRS-78, SwRS-96). `Hypothesen.md` enthält exakt dieselben 18 Einträge, keine zusätzlichen
+freien Fragen ohne zugehörige Anforderung. Deckungsgleich.
+
+## Selbstbewertung
+
+**Analysetiefe je Modul (absolute Zahlen).** Von 109 Modulinventar-Zeilen wurden 19 tief, 59
+mittel und 27 flach analysiert; 4 wurden nicht analysiert (siehe Begründung im Modulinventar).
+Bezogen ausschließlich auf die 90 fachlichen `Centron.BL`-Module: 16 tief (Administration,
+BusinessPartner, Core, DataExchange, DocuBoard, EDI, EmployeeArea, Finances,
+ObjectExternalReferences, PasswordManagementArea, Processes, Purchasing, Sales, Transactions,
+TwoFactorAuthenticator, Warehousing), 50 mittel, 23 flach, 1 nicht analysiert (`Properties`).
+
+**Mindestabdeckung erreicht.** Ja - jedes der 105 analysierten Module trägt mindestens eine
+Anforderung; alle 90 Verzeichnisse aus `Centron.BL` sind im Inventar erfasst, `Properties` als
+einziges davon explizit als „nicht analysiert" mit Begründung (kein fachlicher Inhalt, nur
+`AssemblyInfo.cs`). Die drei weiteren „nicht analysiert"-Zeilen betreffen keine `Centron.BL`-Module,
+sondern reine Vertrags-/Utility-Bibliotheken und Build-/Deployment-Infrastruktur außerhalb der
+eigentlichen Geschäftslogik.
+
+**Wo der Beleg dünn war.** Die 27 „flach" eingestuften Module tragen überwiegend nur
+`SEKUNDÄR`-Belege (einfache, meist lesende CRUD-Methoden ohne im erhobenen Ausschnitt erkennbare
+tiefere Geschäftsregel) - typischerweise kleine Utility- oder Konfigurationsmodule
+(z. B. `CentronIcons`, `Tools`, `Resources`, `Urls`, `VideoPortal`, `Start`, `SystemArea`,
+`Calendar`, `Time`, `Buying`, `Logistics`, `Storage`, `ItPlanner`, `ExternalHelpdesk`,
+`ExternalToolsBL`, `Exceptions`, `MailScanner`, `Mailings`, `Notifications`, `ProductMatrix`,
+`Projects`, `CentronNexus` (BL-Einstellungen), `Outlook`, `Centron.Host`, `Centron.Controls`,
+`CentronNexus.OutlookAddIn`, `c-entron.misc.ConnectionManager`). Über alle 119 SwRS-Anforderungen
+hinweg wurden 86 `PRIMÄR`-, 41 `SEKUNDÄR`- und 3 `KONTEXT`-Belege vergeben (rund 66 % `PRIMÄR`).
+Bei den 35 als risikorelevant eingestuften Anforderungen (Sicherheit, Abrechnung/Fakturierung,
+Berechtigungen) liegt der `PRIMÄR`-Anteil bei 33 von 35 (94 %); die zwei verbleibenden Fälle
+(SwRS-16, SwRS-39) sind korrekt als `[HYPOTHESE]`/`Status: HYPOTHESE` geführt statt fälschlich als
+belegt - die risikobasierte Priorisierung wurde damit eingehalten.
+
+**Hypothesenführung.** 18 Hypothesen wurden geführt (4 in SyRS, 14 in SwRS), davon 2 mit
+`Status: HYPOTHESE` (risikorelevante Aussagen ohne `PRIMÄR`-Beleg), die übrigen 16 als punktuelle
+Unsicherheiten innerhalb ansonsten belegter Anforderungen (z. B. offene Berechnungsformeln,
+Cache-Invalidierungszeitpunkte, unklare Parameterbedeutung). Bei einer Codebasis dieser Größe
+(90 fachliche Module, mehrere Zehntausend Dateien) ist diese Zahl plausibel, aber nach Einschätzung
+dieses Laufs eher niedrig angesetzt: Die 59 „mittel" eingestuften Zeilen (davon 50 `Centron.BL`-Module) wurden jeweils nur mit
+einer einzigen Anforderung und einem einzigen Methodenausschnitt erhoben: Weitere Vertiefung würde
+voraussichtlich zusätzliche offene Fragen zutage fördern, die in dieser Iteration aus Zeit-/
+Umfangsgründen nicht mehr untersucht wurden.
+
+**Erkenntnisse für eine Folge-Iteration.**
+1. **Vertiefung der 27 „flach" eingestuften Module**, insbesondere `ItPlanner`, `ExternalHelpdesk`
+   und `CentronNexus` (BL), deren Methodenkörper (nicht nur Signaturen) noch nicht gelesen wurden.
+2. **Klärung der beiden offenen Risikofälle** SwRS-16 (Zahlungsstatus-Klassifikation bei
+   Lieferantenrechnungen) und SwRS-39 (durchsetzende Rechtevergaberegel im `PasswordManager`) -
+   beide sollten vorrangig vor einer Migrationsentscheidung geklärt werden.
+3. **Konsolidierungsanalyse vertiefen**: Die in dieser Iteration identifizierten zwölf
+   Konsolidierungskandidaten (siehe Konsistenzcheck) sind eine erste, nicht erschöpfende Liste;
+   eine gezielte, modulübergreifende Cross-Referenz-Analyse (z. B. über Entitätsnamen und
+   DB-Tabellenverweise) würde voraussichtlich weitere Fälle wie „Stammblatt/Asset" aufdecken.
+4. **Sicherheitsbewertung SHA1-Passwort-Hashing (SwRS-36)**: konkreter Migrationsplan auf ein
+   adaptives Verfahren (Argon2id/bcrypt) inkl. Rehashing-Strategie bestehender Passwörter fehlt
+   noch und sollte Gegenstand einer eigenen Anforderung in einer Folge-Iteration sein.
+5. **Datenbankschema (`SSMS_DB_SCHEMA.sql`, ca. 3,3 MB)** wurde nur punktuell (Stichwortsuche
+   „Stammblatt") herangezogen, nicht systematisch als eigene Erhebungsquelle für DB-Constraints
+   (Fremdschlüssel, Check-Constraints, Trigger) ausgewertet - eine solche Auswertung könnte
+   weitere `PRIMÄR`-Belege für bislang nur `SEKUNDÄR` belegte Datenintegritätsregeln liefern.
+6. **Change-Historie/Commit-Messages/Tickets** wurden in dieser Iteration nicht als Artefaktquelle
+   herangezogen (kein Zugriff auf Ticketsystem/Repository-Historie im Rahmen dieses Laufs
+   bereitgestellt) - `KONTEXT`-Belege dieser Art fehlen daher fast vollständig (nur 3 von 130
+   Belegen).

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Glossar.md

@@ -0,0 +1,26 @@
+# Glossar
+
+Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen,
+Methoden, Spalten) sind im Original belassen.
+
+| Begriff | Erläuterung |
+|---|---|
+| I3D | Primärschlüsselkonvention der Legacy-Datenbank: nahezu jede Entität trägt eine Ganzzahl-Spalte/Property `I3D` als eindeutige ID (z. B. `AppUser.I3D`, `ReceiptInvoice.I3D`). Durchgängig in Entities, DAO und BL sichtbar. |
+| Beleg (Receipt) | Sammelbegriff für Vertriebs-/Einkaufsdokumente im Modul `Sales/Receipts` (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung). Technisch DB-Tabelle `RechKopf`/`RechPos` und Klassenfamilie `Receipt*`. |
+| Fixieren / Festschreiben (`IsFixed`) | Zustand einer Rechnung, in dem sie nicht mehr inhaltlich verändert werden kann (Buchhaltungsintegrität). Gesetzt über `RechKopf.IsFixed = 1` in `ReceiptInvoiceBL.FixInvoice` (`src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:100-105`). |
+| Sichtrecht / AppRight | Berechtigungseinheit des Legacy-Rechtesystems. Zuordnung erfolgt gruppenbasiert über die DB-Tabellen `Sichtrus` (Gruppe -> Recht) und `Sichmemb` (Benutzer -> Gruppe), ausgewertet in `AppRightsBL.HasUserRight` (`src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-649`). Rechte werden als Ganzzahl-ID (I3D) referenziert, z. B. `UserRightsConst.Sales.Customer.Helpdesk.SHOW_HELPDESK` (siehe `CentronRights.md`). |
+| Restriktives Recht | In `CentronRights.md` ausdrücklich so bezeichnete Unterart eines Rechts, die den Zugriff eines Benutzers, der es besitzt, zusätzlich einschränkt (z. B. „nur eigene Tickets“), statt ihn zu erweitern. |
+| WebRight | Separates Berechtigungssystem für Web-Accounts (Kunden-/Lieferanten-Login im Nexus-Webportal), abgebildet über `WebAccountsRights` und ausgewertet in `AppRightsBL.CheckWebRightsFromUser` (`AppRightsBL.cs:113-130`). Von den internen `AppRight`/`Sichtrecht`-Mitarbeiterrechten fachlich getrennt. |
+| BL / DAO | Schichtenkonvention der Codebasis: `*BL`-Klassen (`Centron.BL`) kapseln Geschäftslogik, `Centron.DAO` die NHibernate-basierte Persistenz, `Centron.Entities` das Domänenmodell. |
+| Stammblatt | Legacy-Datenobjekt zur Verwaltung von Druckern (siehe Modul `DocuBoard`/`Devices`). Wird laut Vorgabe der Aufgabenstellung im Zielsystem mit dem allgemeinen Asset-Konzept konsolidiert. |
+| Asset | Allgemeines Datenobjekt für Kunden-/Firmenhardware außerhalb der Drucker-Stammblätter (Modul `DocuBoard`, Klassen `AssetManagement*BL`). Konsolidierungskandidat mit „Stammblatt“ (siehe Aufgabenstellung). |
+| Mandant / Filiale | Organisationseinheiten der ERP-Installation. „Filiale“ (Branch) wird u. a. in restriktiven Rechten referenziert (`SHOW_HELPDESK_ONLY_OWN_BRANCH`, `RIGHT_MITARBEITERAUSLASTUNGNUREIGENEFILIALE`, siehe `CentronRights.md`). |
+| Nexus | Blazor-basiertes Web-Portal (`src/nexus/CentronNexus`) für Kunden-/Lieferanten-Self-Service (u. a. WebCart, WebOffer, ServiceBoard), getrennt vom WPF-Desktopclient (`Centron.WPF.UI`). |
+| WebCart | Nexus-Feature, mit dem Kunden von Kunden („Web-Accounts“) Artikel aus hinterlegten Sonderpreisen bestellen können (laut `README.md` Abschnitt „Contributing“). |
+| C-FLOW | Ticketvorlagen-Mechanismus im Helpdesk-Modul (`UserRightsConst...Helpdesk.CFlow.*`, UI unter `Centron.WPF.UI/Modules/Helpdesk/TicketDetails/CFlow`) zur Steuerung von Ticket-Formularen über Vorlagen. |
+| RiverDivo | Externes, per REST/Client angebundenes System zur Vertragsartikel-Abrechnung (Modul `RiverDivo`, Klasse `RiverConnectionBL`, Methode `GetContractBillingAmounts`). |
+| EDI | Electronic Data Interchange - automatisierter Belegaustausch mit Distributoren/Lieferanten (Alltron, ALSO, ALSO CH, Concerto, EGIS, Komsa, Opentrans 2.1), Modul `EDI` und `Centron.Gateway`. |
+| GoBD-Fixierung | Fachlicher Sammelbegriff dieses Analyseberichts für den technischen Mechanismus `IsFixed`/„festschreiben“ bei Rechnungen; verweist auf die handelsrechtliche Anforderung der Unveränderbarkeit gebuchter Belege (Interpretation, nicht im Code benannt - siehe Hypothesen). |
+| DTO | Data Transfer Object - Klassen zur Datenübertragung zwischen BL- und WebService-/UI-Schicht (z. B. `AppointmentRequestFilter`, `CalendarRepresentationSettingsDTO`). |
+| Ergebnis-/`Result`-Muster | In weiten Teilen der BL verwendetes Rückgabemuster `Result`/`Result<T>` mit `Status`/`Data`/`Message` statt Exceptions für fachliche Fehler (z. B. `TwoFactorAuthenticationBL.ValidateAuthenticationPin`). |
+

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Hypothesen.md

@@ -0,0 +1,26 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]` markierten Aussagen aus StRS/SyRS/SwRS, mit der jeweils offenen
+Frage, die zur Bestätigung fehlt. Diese Liste ist deckungsgleich mit den Inline-Markierungen
+(siehe Konsistenzcheck in `Analysebericht.md`).
+
+| Anforderungs-ID | Hypothese | Offene Frage zur Bestätigung |
+|---|---|---|
+| SwRS-7 | Unklar, ob die kundenspezifische Produktbewertung (`ProductMatrix`) in allen Kundensegmenten oder nur bei bestimmten Vertriebspartnerschaften genutzt wird. | Gibt es eine Konfiguration/ein Recht, das die Nutzung der Produktmatrix auf bestimmte Kundentypen einschränkt? |
+| SwRS-10 | Unklar, ob RiverDivo ein für die Zielarchitektur weiterhin relevanter externer Anbieter oder ein auslaufender Altvertrag ist. | Gibt es aktuelle Vertrags-/Nutzungsdaten oder Deprecation-Hinweise zu RiverDivo außerhalb des Codes? |
+| SwRS-16 | Die konkrete Buchungsregel, die eine ausgehende Zahlung als „ausgehend" bzw. beglichen/offen klassifiziert, ist im erhobenen Codeausschnitt von `SupplierInvoicesBL` nicht auffindbar. | Wo (BL, DB-View, Reporting) wird der Zahlungsstatus einer Lieferantenrechnung tatsächlich ermittelt? |
+| SwRS-17 | Unklar, ob alle vier externen Produktdatenquellen (COP, EGIS, ITscope, Icecat) noch aktiv genutzt werden oder einzelne historisch/abgelöst sind. | Welche der vier Anbindungen sind in der aktuellen Produktivkonfiguration tatsächlich aktiv? |
+| SyRS-7 | Die genaue Berechnungsformel der Einkaufspreisnachführung (z. B. gleitender Durchschnitt vs. FIFO) ist aus der Methodensignatur von `UpdateArticlePurchasePrice` allein nicht ableitbar. | Welche Bewertungsmethode (gleitender Durchschnitt, FIFO, LIFO) implementiert der Methodenkörper tatsächlich? |
+| SwRS-20 | Die Priorisierungsregel zwischen Aktionspreis (`ActionPriceBL`) und Staffelpreis (`ArticleVolumePricesBL`) bei Überschneidung ist im erhobenen Codeausschnitt nicht auffindbar. | Welcher Preis gewinnt, wenn für dieselbe Menge sowohl ein Aktionspreis als auch ein Staffelpreis gültig ist? |
+| SwRS-25 | Der auslösende Prozess, der eine Bankverbindung als „autorisiert" markiert, ist im erhobenen Codeausschnitt von `BankAccountBL` nicht auffindbar. | Welcher Workflow (Vier-Augen-Prinzip, Verifikations-E-Mail, manuelle Freigabe) setzt das Autorisierungsmerkmal einer Bankverbindung? |
+| SyRS-12 | Der Cache-Invalidierungszeitpunkt von `HasUserRight` bei einer Gruppenänderung war im erhobenen Ausschnitt nicht erkennbar. | Wird der Rechte-Cache bei Gruppenänderung sofort invalidiert, oder kann ein entzogenes Recht bis zum Cache-Ablauf/Neuanmeldung wirksam bleiben? |
+| SwRS-54 | Ob das Anlegen einer globalen Ticketansicht ein eigenes Recht voraussetzt, ist im erhobenen Ausschnitt von `NexusTicketViewBL` nicht erkennbar. | Gibt es ein dediziertes Recht für `SaveGlobalView`, oder kann jeder Benutzer globale Ansichten erzeugen? |
+| SwRS-56 | Die auslösende Bedingung für „Ticket abgelaufen" (`TicketExpiredException`) ist im erhobenen Codeausschnitt nicht auffindbar. | Welche fachliche Regel (Fristüberschreitung, Kundenstatus, Vertragsende) löst diese Exception tatsächlich aus? |
+| SwRS-68 | Ob `Reporting` (ReportsBL) und `ReportEngine` (ReportDataExportBL) zwei unabhängige Berichtssysteme oder Vorder-/Rückseite derselben Funktion sind, war anhand der Modulnamen und Signaturen allein nicht klärbar. | Werden beide Module vom selben UI-Bericht-Dialog verwendet, oder bedienen sie getrennte Anwendungsfälle (z. B. Altsystem vs. aktuelles System)? |
+| SwRS-70 | Unklar, ob die Erfassung der `hardwareId` in `TelemetryBL` datenschutzrechtlich als personenbezogenes Datum zu behandeln ist. | Existiert eine Datenschutz-Folgenabschätzung oder Einwilligungsgrundlage für die Hardware-ID-Erfassung? |
+| SwRS-74 | Das in `CentronFtpUrls` fest hinterlegte Zugriffstoken der Update-URLs könnte ein Hardcoded-Secret-Befund sein; unklar, ob es ein öffentlich lesbares Freigabeverzeichnis oder ein schützenswertes Token adressiert. | Ist das Token in den vier `CentronFtpUrls`-Konstanten sicherheitskritisch, und wird es rotiert? |
+| SyRS-27 | Der konkrete Duplikatsschutz-Mechanismus von `ModuleBL.DoCreateMissingInternalModulesInDB` wurde nur aus dem Methodennamen abgeleitet, nicht im Methodenkörper verifiziert. | Prüft die Methode tatsächlich auf bereits vorhandene Module vor dem Insert, oder verlässt sie sich auf einen Datenbank-Constraint? |
+| SwRS-78 | Der fachliche Zweck von `SystemTableI3D` (z. B. globaler ID-Generator vs. Systemstatus) war aus der einzigen erhobenen Methode nicht abschließend erkennbar. | Wofür wird der von `GetSystemTableI3D()` gelieferte Datensatz konkret verwendet? |
+| SyRS-28 | Ob Shipcloud einen äquivalenten Testmodus wie GLS (`isTest`-Parameter) besitzt, ist im erhobenen Codeausschnitt von `CentronShipcloudLogic` nicht erkennbar. | Bietet die Shipcloud-Integration einen Sandbox-/Testmodus, oder besteht bei Fehlkonfiguration das Risiko eines versehentlichen Produktivversands? |
+| SwRS-96 | Die fachliche Bedeutung des Parameters `mixMode` in `AccountAddressContactWebServiceBL` war aus der Methodensignatur allein nicht klärbar. | Was unterscheidet `mixMode: true` von `false` bei Anlage/Speicherung eines Adresskontakts? |
+| SwRS-39 | Risikorelevante Aussage (Berechtigung auf Zugangsdaten) ohne `PRIMÄR`-Beleg - die durchsetzende Rechtevergaberegel hinter `GetPasswordManagerCustomersEmployeesRights` war im erhobenen Ausschnitt nicht einsehbar; gemäß risikobasierter Priorisierung als Hypothese statt als belegt geführt. | Wo (welche Methode/welcher Constraint) setzt tatsächlich durch, dass ein Mitarbeiter nur auf zugeordnete Kunden zugreifen darf? |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/StRS.md

@@ -0,0 +1,658 @@
+# StRS - Stakeholder Requirements Specification
+
+c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
+
+Fachliche Sicht: Geschäftsziele, Akteure und Erwartungen der Stakeholder, abgeleitet aus der
+Codebasis (statische Analyse, keine Ausführung). Jede Anforderung folgt dem in `01_Prompt.md`
+vorgegebenen Blockformat. Domänenbegriffe sind in `Glossar.md` erläutert.
+
+## Domäne D1: Vertrieb & Kundenbeziehungsmanagement
+
+```
+ID:            StRS-1
+Titel:         Durchgängige Belegkette vom Angebot bis zur festgeschriebenen Rechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter, Innendienst
+Vorbedingung:  Ein Kunde (Account) existiert im System.
+Fakt:          Das Modul `Sales/Receipts` bildet Angebot, Auftrag, Lieferschein, Rechnung und
+               Gutschrift als zusammenhängende Klassenfamilie ab (`ReceiptBL.cs`,
+               `Invoices/ReceiptInvoiceBL.cs`, `CreditVouchers/ReceiptCreditVoucherBL.cs`,
+               `DataAndResults/ForwardReceipt/ForwardReceiptResult.cs`,
+               `DataAndResults/CreateReceipt/CreateReceiptResult.cs`); Rechnungen werden über
+               `RechKopf.IsFixed` festgeschrieben (`ReceiptInvoiceBL.FixInvoice`).
+Aussage:       Das System soll Vertriebsmitarbeitern erlauben, aus einem Kundenvorgang lückenlos
+               ein Angebot zu erstellen, es in Auftrag, Lieferschein und Rechnung zu überführen
+               (Belegweiterleitung) und die Rechnung nach Erstellung buchhalterisch unveränderbar
+               festzuschreiben.
+Ergebnis:      Ein durchgängiger, nachvollziehbarer Beleg-Lebenszyklus mit einer nach Festschreibung
+               unveränderbaren Rechnung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-105 (FixInvoice, UPDATE RechKopf SET IsFixed = 1) - Begründung: setzt die durchsetzende Sperre der Rechnungsänderung im BL-Code.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ForwardReceipt/ForwardReceiptResult.cs - Begründung: Klassenname und Ordnerstruktur belegen die Belegweiterleitungsfunktion.
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/ (Ordnerstruktur: ContractLists, CreditVouchers, DeliveryLists, Invoices, SupplierInvoices) - Begründung: zeigt die fachliche Breite der Belegarten im selben Modul.
+Prüfidee:      Angebot anlegen, in Auftrag/Lieferschein/Rechnung überführen, `FixInvoice` aufrufen und
+               anschließend einen Änderungsversuch an der Rechnung durchführen - dieser muss
+               fachlich abgewiesen werden.
+Tracelinks:    SyRS-1, SyRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess jeder ERP-Neuimplementierung.
+Status:        belegt
+```
+
+```
+ID:            StRS-2
+Titel:         Kundenstammdaten, Vorgänge und Rücksendungen (RMA) zentral verwalten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsinnendienst, Hotline-Mitarbeiter
+Vorbedingung:  Kunde ist als Account angelegt.
+Fakt:          `AccountBL`/`AccountAddressBL` verwalten Kundenstamm- und Adressdaten; `RmaBL`
+               (81-709) bildet einen mehrstufigen Rücksendeprozess (Rma, RmaArticle, RmaSendForth,
+               RmaSendBack) ab; `HotlineBL` verwaltet kundenbezogene Hotline-Verträge.
+Aussage:       Das System soll Kundenstammdaten, zugehörige Ansprechpartner, Hotline-Verträge und
+               Rücksendevorgänge (RMA) inklusive Versand an und von Lieferanten in einem
+               durchgängigen Vorgang je Kunde verwalten.
+Ergebnis:      Ein vollständiger, historisierter Blick auf Kundenbeziehung, Verträge und
+               Rücksendungen je Account.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/CustomerArea/RmaBL.cs:347,603,685,692 (SaveRma, CreateNewRmaArticle, GetRmaSendForthByI3D, GetRmaSendBackByI3D) - Begründung: konkrete Methoden für Anlage und Versandrichtungen der Rücksendung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Accounts/HotlineBL.cs:21-38 (GetHotlineByI3D, GetHotlinesFromCustomerByI3D, SaveHotline) - Begründung: UI-nahe Zugriffsmethoden auf kundenbezogene Hotline-Verträge.
+  - [KONTEXT]  src/backend/Centron.BL/Accounts/ (Unterordner AccountContracts, Activities, Campaigns, ExtendedFilters, Marketing) - Begründung: belegt Breite der Kundendatenverwaltung im Modul.
+Prüfidee:      Für einen Account eine RMA anlegen, einen RmaArticle erfassen und den Versand an den
+               Lieferanten (RmaSendForth) sowie den Rückversand (RmaSendBack) dokumentieren.
+Tracelinks:    SyRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kundenbindung und Reklamationsprozess sind zentrale ERP-Funktionen.
+Status:        belegt
+```
+
+## Domäne D2: Einkauf & Lieferantenmanagement
+
+```
+ID:            StRS-3
+Titel:         Bestellvorschläge, EDI-Bestellungen und Lieferantenrechnungen verwalten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkaufsmitarbeiter
+Vorbedingung:  Lieferanten und Artikel sind im System erfasst.
+Fakt:          `OrderSuggestionListBL` erzeugt Bestellvorschläge; `EDIDispatcherBL` erzeugt und
+               versendet elektronische Bestelldokumente an mehrere Distributoren (Alltron, ALSO,
+               EGIS, ITscope, Komsa, Concerto); `SupplierInvoicesBL` verwaltet ausgehende Zahlungen
+               zu Lieferantenrechnungen.
+Aussage:       Das System soll aus Lagerbestand und Bedarf automatisierte Bestellvorschläge
+               erzeugen, diese wahlweise elektronisch (EDI) an angebundene Distributoren übermitteln
+               und die daraus resultierenden Lieferantenrechnungen inklusive Zahlungshistorie
+               nachverfolgen.
+Ergebnis:      Ein durchgängiger Einkaufsprozess von der Bedarfsermittlung über die elektronische
+               Bestellung bis zur Zahlungsverfolgung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/EDI/EDIDispatcherBL.cs:56,213,290 (CreateEDISuggestionOrderAsync, EdiConcertoOrderUploadAsync, KomsaArticleCheckAsync) - Begründung: durchsetzende, distributorspezifische Versandmethoden.
+  - [SEKUNDÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:430-432 (GetOrderSuggestionArticle, GetArticlePerItems, GetOrderSuggestionOrder) - Begründung: UI-nahe Abrufmethoden für Bestellvorschläge.
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/SupplierInvoices/SupplierInvoicesBL.cs:38,98 (GetOutgoingPaymentReceiptItemsThroughPaging, GetOutgoingPaymentsHistoryThroughPaging) - Begründung: zeigt Existenz der Zahlungsnachverfolgung, ohne im erhobenen Ausschnitt eine durchsetzende Buchungsregel zu belegen.
+Prüfidee:      Aus einem Lagerbestand unterhalb des Meldebestands einen Bestellvorschlag erzeugen,
+               daraus eine EDI-Bestellung an einen konfigurierten Distributor erzeugen und die
+               resultierende Lieferantenrechnung in der Zahlungshistorie wiederfinden.
+Tracelinks:    SyRS-4, SyRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess der Warenbeschaffung.
+Status:        belegt
+```
+
+## Domäne D3: Lager, Artikel & Produktion
+
+```
+ID:            StRS-4
+Titel:         Artikelbestand, Preisfindung und Produktionsaufträge verwalten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Lager-/Einkaufs-/Produktionsmitarbeiter
+Vorbedingung:  Artikelstamm existiert.
+Fakt:          `ArticleStockBL` führt Bestände je Artikel/Lager (`UpdateArticleStock`,
+               `IncreaseArticleStock`) und passt Einkaufspreise nach (`UpdateArticlePurchasePrice`
+               mit `oldQuantity`/`quantity`/`purchasePrice`); `ArticleVolumePricesBL.GetVolumePrice`
+               wählt die höchste zutreffende Staffelmenge; `ProductionOrderBL` verwaltet
+               Produktionsaufträge mit eigener Log-Historie.
+Aussage:       Das System soll Artikelbestände je Lagerort führen, bei Wareneingang den
+               Einkaufspreis mengengewichtet nachführen, mengenabhängige Staffelpreise automatisch
+               ermitteln und Produktionsaufträge inklusive Statusprotokoll verwalten.
+Ergebnis:      Aktueller, lagerortgenauer Bestand mit nachgeführtem Einkaufspreis; korrekt
+               ermittelter Staffelpreis je Bestellmenge; nachvollziehbarer Produktionsauftragsverlauf.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs:47-74 (UpdateArticleStock, IncreaseArticleStock, UpdateArticlePurchasePrice) - Begründung: durchsetzende Bestands- und Preisänderungsmethoden.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs:88-97 (GetVolumePrice: OrderByDescending(FromAmount).FirstOrDefault(FromAmount <= amount)) - Begründung: konkrete, durchsetzende Auswahlregel für Staffelpreise.
+  - [SEKUNDÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs:45,122,194 (SaveProductionOrder, SaveProductionOrderItem, SaveProductionOrderLog) - Begründung: UI-nahe Speichermethoden mit begleitender Log-Funktion.
+Prüfidee:      Wareneingang mit abweichendem Einkaufspreis buchen und die Nachführung des
+               gewichteten Einkaufspreises prüfen; Bestellmenge über und unter einer Staffelgrenze
+               anfragen und jeweils den korrekten Preis erhalten.
+Tracelinks:    SyRS-6, SyRS-7, SyRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Bestands- und Preisführung sind Kernfunktionen jeder Warenwirtschaft.
+Status:        belegt
+```
+
+## Domäne D4: Finanzbuchhaltung & Zahlungsverkehr (risikorelevant)
+
+```
+ID:            StRS-5
+Titel:         Zahlungsverkehr mit exportsicherem SEPA-/Lastschrift-Export
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung
+Vorbedingung:  Fällige Rechnungen mit Zahlungsdaten existieren.
+Fakt:          `PaymentTransactionBL.ExportInvoices(...)` erzeugt einen Zahlungsexport;
+               `SetInvoicesAsExported(int employeeI3D, int invoiceI3D)` und
+               `ResetInvoiceExportedFlag(AppUser, List<int> incomingPaymentLogI3Ds)` verwalten ein
+               explizites Exportiert-Flag je Rechnung.
+Aussage:       Das System soll Rechnungen für den Zahlungsexport (z. B. SEPA-Lastschrift) markieren,
+               nach erfolgreichem Export eindeutig als exportiert kennzeichnen und diese Markierung
+               nur über eine dedizierte, protokollierte Funktion zurücksetzen können.
+Ergebnis:      Rechnungen werden nicht unbeabsichtigt doppelt in einen Zahlungsexport aufgenommen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:291,296 (SetInvoicesAsExported, ResetInvoiceExportedFlag) - Begründung: durchsetzende Stelle, die den Exportstatus einer Rechnung explizit setzt bzw. zurücksetzt.
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:93,132 (GetInvoiceList mit showOnlyExportedInvoices-Filter, ExportInvoices) - Begründung: zeigt, dass der Exportstatus die Grundlage für die Selektion exportierbarer Rechnungen bildet.
+Prüfidee:      Rechnung exportieren, danach erneut in `GetInvoiceList(showOnlyExportedInvoices:
+               false)` abfragen - sie darf dort nicht mehr als „nicht exportiert" erscheinen, bis
+               `ResetInvoiceExportedFlag` aufgerufen wurde.
+Tracelinks:    SyRS-9, SyRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Doppelexportschutz ist eine zwingende Anforderung an jeden Zahlungsverkehr.
+Status:        belegt
+```
+
+```
+ID:            StRS-6
+Titel:         Kontenrahmen und Buchhaltungsexport konfigurierbar an FiBu-Systeme anbinden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung, Steuerberater
+Vorbedingung:  Ein Buchhaltungssystem (z. B. DATEV/GDI) ist als Zielsystem vorgesehen.
+Fakt:          `BookKeepingAccountSystemsBL` verwaltet mehrere parallele Kontenrahmen
+               (`GetBookKeepingAccountSystems`, `SaveBookKeepingAccountSystem`) mit zugehörigen
+               Konten (`GetBookKeepingAccounts(bool fromDefaultSystem)`); `BookKeepingExportBL`
+               speichert Exporteinstellungen je Konfiguration.
+Aussage:       Das System soll mehrere Kontenrahmen parallel verwalten und den Buchhaltungsexport je
+               Kontenrahmen konfigurierbar machen, um unterschiedliche Buchhaltungssysteme/-berater
+               zu bedienen.
+Ergebnis:      Ein exportierter Buchungssatz, der dem gewählten Kontenrahmen und Zielformat
+               entspricht.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs:24-81 (GetBookKeepingAccountSystems, SaveBookKeepingAccountSystem, GetBookKeepingAccounts mit fromDefaultSystem-Flag) - Begründung: durchsetzende Verwaltung mehrerer Kontenrahmen.
+  - [SEKUNDÄR] src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs:142-144 (SaveExportSettings, LoadExportSettings, GetCustomInterfaceSettings) - Begründung: begleitende Exportkonfiguration.
+Prüfidee:      Zwei Kontenrahmen anlegen, je einen Buchungsexport konfigurieren und für dieselbe
+               Rechnung unterschiedliche Kontonummern im jeweiligen Export prüfen.
+Tracelinks:    SyRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D10: Sicherheit, Zugriffsschutz & Berechtigungen (risikorelevant)
+
+```
+ID:            StRS-7
+Titel:         Gruppenbasierte, restriktive Rechteprüfung für Programm- und Web-Zugriff
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, alle Mitarbeiter, Web-Accounts
+Vorbedingung:  Benutzer ist angemeldet.
+Fakt:          `AppRightsBL.HasUserRight(int appUserI3D, int rightID)` prüft Rechte über die
+               DB-Tabellen `Sichtrus`/`Sichmemb` (Gruppenmitgliedschaft); `CheckWebRightsFromUser`
+               prüft getrennt davon `WebAccountsRights`; `CentronRights.md` dokumentiert zusätzlich
+               „restriktive Rechte", die den Zugriff eines Rechteinhabers einschränken statt
+               erweitern.
+Aussage:       Das System soll jeden funktionalen Zugriff - sowohl im Desktop-Client als auch im
+               Web-Portal - gegen ein gruppenbasiertes Rechtesystem prüfen und dabei zwischen
+               erweiternden und restriktiven Rechten unterscheiden.
+Ergebnis:      Ein Benutzer ohne das erforderliche Recht wird von der Funktion ausgeschlossen; ein
+               Benutzer mit restriktivem Recht sieht nur die dafür vorgesehene Teilmenge (z. B. nur
+               eigene Tickets).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-649 (HasUserRight: Join Sichtrus/Sichmemb) - Begründung: durchsetzende, konkrete Rechteprüfung mit Datenbankquelle.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:113-130 (CheckWebRightsFromUser: WebAccountsRights) - Begründung: getrennte, durchsetzende Prüfung für Web-Accounts.
+  - [KONTEXT]  CentronRights.md:9-12 (Beispiel „restriktives Recht" SHOW_HELPDESK_ONLY_OWN) - Begründung: dokumentiert die fachliche Bedeutung restriktiver Rechte, ohne selbst durchsetzend zu sein.
+Prüfidee:      Benutzer ohne Recht X von einer Funktion ausschließen; Benutzer mit restriktivem
+               Recht „nur eigene" auf eine Teilmenge der Datensätze einschränken und beides gegen
+               `HasUserRight` verifizieren.
+Tracelinks:    SyRS-12, SyRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - rollenbasierte Zugriffskontrolle ist für jede ERP-Neuimplementierung zwingend.
+Status:        belegt
+```
+
+```
+ID:            StRS-8
+Titel:         Sichere Authentifizierung von Mitarbeitern über Passwort, Zwei-Faktor und persönliche API-Tokens
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Systemadministrator
+Vorbedingung:  Benutzerkonto existiert.
+Fakt:          `CryptoUtils.CreatePasswordHash(pwd, salt)` hasht Passwörter gesalzen mit SHA1;
+               `TwoFactorAuthenticationBL.ValidateAuthenticationPin` prüft einen TOTP-Code gegen
+               einen hinterlegten Schlüssel; `AccessTokenBL` verwaltet persönliche API-Tokens mit
+               vollem Lebenszyklus (`CreatePersonalToken`, `Activate`, `Deactivate`, `Delete`,
+               `ValidateToken`, `HashToken`) inklusive IP-Adressparameter.
+Aussage:       Das System soll Mitarbeiterkonten über ein gesalzenes Passwort-Hashing, optional
+               zusätzlich über einen Zwei-Faktor-Code, und für programmatischen Zugriff über
+               widerrufbare persönliche API-Tokens mit IP-Nachvollziehbarkeit absichern.
+Ergebnis:      Ein Anmeldeversuch wird nur mit korrektem Passwort-Hash (und ggf. korrektem
+               TOTP-Code) bzw. gültigem, nicht deaktiviertem Token akzeptiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Core/CryptoUtils.cs:15-33 (CreateSalt, CreatePasswordHash mit SHA1) - Begründung: durchsetzende Passwort-Hashing-Implementierung.
+  - [PRIMÄR]   src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54 (ValidateAuthenticationPin) - Begründung: durchsetzende TOTP-Prüfung mit expliziter Fehlermeldung.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs:125-480 (voller Token-Lebenszyklus inkl. HashToken, ValidateToken mit ipAddress) - Begründung: durchsetzende, vollständige Token-Verwaltung.
+Prüfidee:      Anmeldung mit falschem Passwort-Hash ablehnen; TOTP-Code außerhalb des Zeitfensters
+               ablehnen; deaktivierten API-Token gegen `ValidateToken` prüfen (muss fehlschlagen).
+Tracelinks:    SyRS-13, SyRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Authentifizierung bleibt erforderlich; die konkrete Hash-Methode (SHA1 ohne Schlüsselstreckung) sollte in der Zielarchitektur durch einen modernen, adaptiven Algorithmus (z. B. Argon2id/bcrypt) ersetzt werden (siehe SwRS-36).
+Status:        belegt
+```
+
+## Domäne D5: Personalverwaltung & Zeitwirtschaft
+
+```
+ID:            StRS-9
+Titel:         Mitarbeiterkonten mit Administratorstatus, Zeit- und Terminverwaltung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Personalabteilung, Systemadministrator
+Vorbedingung:  Mitarbeiter ist angelegt.
+Fakt:          `AppUserBL.IsUserInAdminGroup(AppUser appUser)` prüft Administratorstatus getrennt
+               von regulären Rechten; `SaveOrUpdateAppUser(AppUser, AppUser loggedInUser, string
+               newPassword = null)` erlaubt optionale Passwortänderung im selben Aufruf;
+               `TimingSettingsBL` und `CalendarBL` verwalten Arbeitszeitmodelle bzw.
+               Kalenderdarstellung; `AppointmentRequestBL` verwaltet externe Terminanfragen.
+Aussage:       Das System soll Mitarbeiterkonten inklusive Administratorstatus verwalten, deren
+               Zeitmodell (Arbeitszeit) und Kalender führen und externe Terminanfragen (z. B. von
+               Kunden) in den internen Kalender überführen können.
+Ergebnis:      Ein Mitarbeiterkonto mit korrektem Admin-/Nutzerstatus, Zeitmodell und Kalender.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/EmployeeArea/AppUserBL.cs:136,247 (SaveOrUpdateAppUser mit newPassword-Parameter, IsUserInAdminGroup) - Begründung: durchsetzende Methoden mit sicherheitsrelevanter Statusprüfung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Time/TimingSettingsBL.cs:583-585 (GetTimingSettings, GetTimingSettingsByFilter) - Begründung: UI-nahe Zugriffsmethoden auf Zeitmodelle.
+  - [KONTEXT]  src/backend/Centron.BL/AppointmentRequests/AppointmentRequestBL.cs:29 (HandleAppointmentRequestReply) - Begründung: zeigt Existenz der externen Terminanfrage-Verarbeitung.
+Prüfidee:      Mitarbeiter mit Administratorstatus anlegen, `IsUserInAdminGroup` prüfen, danach
+               über `SaveOrUpdateAppUser` das Passwort ändern und die Wirksamkeit der Änderung
+               prüfen.
+Tracelinks:    SyRS-18, SyRS-19
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D6: Kundenservice, Ticketing & Support
+
+```
+ID:            StRS-10
+Titel:         Ticketbasierten Kundenservice mit Checklisten, Fristen, Tags und Ticketprojekten abwickeln
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Mitarbeiter, Kunde (extern)
+Vorbedingung:  Kunde/Vorgang ist erfasst.
+Fakt:          `CentronRights.md` beschreibt einen Ticket-Lebenszyklus mit Fälligkeit
+               (`MATURITY_CHANGE`), Abschluss (`CLOSE_REQUEST`) und Checklisten
+               (`CentronChecklistBL`); `TagsBL.AddTicketTag(int helpdeskI3D, string caption,
+               LoggedInUser)` ordnet Tickets Schlagworte zu; `TicketProjectBL` gruppiert Tickets in
+               Projekte mit Abhängigkeiten; `TicketExpiredException` signalisiert abgelaufene
+               Tickets.
+Aussage:       Das System soll Support-Vorgänge als Tickets mit Fälligkeit, Checklisten, freien
+               Schlagworten (Tags) und optionaler Projektgruppierung führen und einen fachlichen
+               Ablauf-/Exception-Zustand für überfällige Tickets kennen.
+Ergebnis:      Ein Ticket mit vollständigem Lebenszyklus (Anlage, Bearbeitung, Fristen, Abschluss)
+               und optionaler Verknüpfung zu Checkliste, Tags und Projekt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Tags/TagsBL.cs:538 (AddTicketTag mit helpdeskI3D-Bezug) - Begründung: durchsetzende Verknüpfung Tag <-> Ticket.
+  - [SEKUNDÄR] CentronRights.md:37-44 (MATURITY_CHANGE, CLOSE_REQUEST) - Begründung: dokumentiert den fachlich vorgesehenen Ablauf, ohne selbst Code zu sein.
+  - [KONTEXT]  src/backend/Centron.BL/Exceptions/TicketExpiredException.cs:1-6 (Ticket-Property) - Begründung: zeigt Existenz eines Ablauf-Zustands.
+Prüfidee:      Ticket anlegen, Checkliste zuordnen, Tag vergeben, Fälligkeit ändern, Ticketprojekt
+               zuordnen und abschließend das Ticket abschließen; jeder Schritt muss über die
+               jeweilige Komponente nachvollziehbar sein.
+Tracelinks:    SyRS-17, SyRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Ticketing ist Kernprozess des Kundenservice.
+Status:        belegt
+```
+
+## Domäne D7: Kommunikation (Mail, Chat, Telefonie, Social Media, Benachrichtigungen)
+
+```
+ID:            StRS-11
+Titel:         Kanalübergreifende Kommunikation mit Kunden und im Team abwickeln
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Kunde
+Vorbedingung:  Kommunikationskanal ist konfiguriert.
+Fakt:          Das System bietet eigenständige Module für E-Mail (`Mail`, `MailScanner`,
+               `Mailings`), Team-Chat (`ChatBL.CreateChat`/`AddMemberToChat`), Telefonie
+               (`PhoneCallBL.CreatePhoneCall`), Social-Media-Interaktion
+               (`SocialMediaBL.AddCommentToASocialMediaAction`) sowie zentrale Benachrichtigungen
+               (`CentronNotificationsBL`, `NexusNotificationsBL`).
+Aussage:       Das System soll Kommunikation über mehrere Kanäle (E-Mail, Chat, Telefon, Social
+               Media) erfassen und protokollieren sowie kanalübergreifend über ein zentrales
+               Benachrichtigungssystem auf relevante Ereignisse hinweisen.
+Ergebnis:      Ein nachvollziehbarer Kommunikationsverlauf je Kanal und eine konsolidierte
+               Benachrichtigungsübersicht je Benutzer.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Chats/ChatBL.cs:97-98 (CreateChat, AddMemberToChat) - Begründung: durchsetzende Chat-Kernfunktionen.
+  - [PRIMÄR]   src/backend/Centron.BL/Tapi/PhoneCallBL.cs:545 (CreatePhoneCall) - Begründung: durchsetzende Telefonieprotokollierung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs:359 (GetCentronNotificationsByFilter) - Begründung: zentrale, kanalübergreifende Benachrichtigungsabfrage.
+Prüfidee:      Über drei unterschiedliche Kanäle (Chat, Telefon, Mail) mit demselben Kunden
+               kommunizieren und prüfen, ob alle drei Interaktionen im jeweiligen Modul
+               nachvollziehbar sind.
+Tracelinks:    SyRS-21, SyRS-22
+Konsolidierung: Kandidat: `NexusNotifications` und `Notifications` bilden beide
+               „Benutzerbenachrichtigung" ab und sind auf Konsolidierbarkeit im Zielsystem zu prüfen.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D8: Berichtswesen, Volltextsuche & Nutzungstelemetrie
+
+```
+ID:            StRS-12
+Titel:         Berichte erzeugen, exportieren und Systeminhalte volltextdurchsuchbar machen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Mitarbeiter, Systemadministrator
+Vorbedingung:  Berichte/Datenobjekte existieren.
+Fakt:          `ReportsBL.GetReport(id)`/`GetReport(predicate)` liefert Berichte;
+               `ReportDataExportBL.ExportAllReports(ReportGroup, string path)` exportiert
+               Berichtsgruppen; `IndexSearchBL.SearchIndex(string searchText,
+               CentronObjectKindNumeric? kind)` durchsucht alle indizierten Objekttypen;
+               `TelemetryBL.RecordArtificialIntelligenceToolUsage` protokolliert KI-Werkzeugnutzung.
+Aussage:       Das System soll Berichte definieren, gruppieren und exportieren, beliebige
+               Objekttypen volltextdurchsuchbar machen und die Nutzung interner Werkzeuge
+               (insbesondere KI-Funktionen) zu Auswertungszwecken protokollieren.
+Ergebnis:      Exportierte Berichte, ein durchsuchbarer Gesamtindex, eine Nutzungsstatistik.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs:250 (SearchIndex, objektübergreifend) - Begründung: durchsetzende, zentrale Suchmethode.
+  - [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/ImportExport/ReportDataExportBL.cs:438-440 - Begründung: begleitende Exportfunktion.
+  - [KONTEXT]  src/backend/Centron.BL/Telemetry/TelemetryBL.cs:561-563 - Begründung: zeigt Existenz der Nutzungstelemetrie, nicht direkt Bestandteil des Berichtswesens im engeren Sinn.
+Prüfidee:      Neues Objekt anlegen, Index aktualisieren lassen (`UpdateRequestedIndexes`) und
+               über `SearchIndex` auffindbar machen; parallel einen Bericht dieser Objektklasse
+               exportieren.
+Tracelinks:    SyRS-23, SyRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D9: Dokumenten- & Textvorlagenmanagement
+
+```
+ID:            StRS-13
+Titel:         Interne Dokumentation und Textbausteine rechteabhängig verwalten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Systemadministrator
+Vorbedingung:  keine
+Fakt:          `DocumentationBL.GetDocumentation(List<Filter>, AppUser currUser, bool checkRight =
+               true)` und `GetDocumentationByStatus(AppUser, int status = 1, bool checkRight =
+               true)` führen einen expliziten, standardmäßig aktiven Rechtecheck-Parameter;
+               `SalutationAndAgreementReplacementBL.ReplaceSalutationAndAgreement<TAsset,TItem>`
+               ersetzt Anrede-/Vereinbarungsplatzhalter generisch für unterschiedliche
+               Belegtypen; `PdfInteractionBL.MergePdfFiles` führt PDF-Dokumente zusammen.
+Aussage:       Das System soll interne Dokumentationsartikel standardmäßig rechteabhängig
+               anzeigen (Opt-out über `checkRight: false` nur für privilegierte interne
+               Aufrufe), Anrede-/Vereinbarungstexte generisch über verschiedene Belegtypen hinweg
+               ersetzen und PDF-Dokumente zu einem Gesamtdokument zusammenführen können.
+Ergebnis:      Ein Mitarbeiter sieht nur Dokumentationsartikel, für die er berechtigt ist; ein
+               Textbaustein liefert für unterschiedliche Belegtypen konsistent ersetzte Werte.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:165-166 (checkRight-Parameter mit Default true) - Begründung: durchsetzender, standardmäßig aktiver Rechtecheck direkt in der Methodensignatur.
+  - [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/SalutationAndAgreementReplacementBL.cs:569 (ReplaceSalutationAndAgreement, generisch über TAsset/TItem) - Begründung: zeigt die generische, belegtypübergreifende Ersetzung.
+Prüfidee:      Dokumentationsartikel ohne zugehöriges Recht abrufen (`checkRight: true`, Standard)
+               - darf nicht erscheinen; mit `checkRight: false` versuchen (nur aus internem,
+               privilegiertem Kontext zulässig) - muss erscheinen.
+Tracelinks:    SyRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D11: Systemadministration, Modul- & Konfigurationsverwaltung
+
+```
+ID:            StRS-14
+Titel:         System zentral konfigurieren, Module verwalten und Massenänderungen kontrolliert durchführen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator
+Vorbedingung:  keine
+Fakt:          `ModuleBL.DoCreateMissingInternalModulesInDB(List<ModuleClass>)` synchronisiert
+               den Modulkatalog der Datenbank mit dem Code; `CustomTableBL` erlaubt kundenspezifische
+               Zusatztabellen; `MassUpdateBL` führt gespeicherte Massenänderungsvorlagen aus;
+               `CachedTableBL.RequestImmediateCacheUpdate`/`ExecuteCacheUpdates` steuern
+               System-Caches.
+Aussage:       Das System soll seinen Modulkatalog automatisch mit dem Code synchron halten,
+               kundenspezifische Zusatztabellen unterstützen, wiederverwendbare
+               Massenänderungsvorlagen ausführen und zentrale Caches gezielt aktualisierbar
+               machen.
+Ergebnis:      Ein konsistenter Modulkatalog, angewendete Massenänderungen, aktuelle System-Caches.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Modules/ModuleBL.cs:317 (DoCreateMissingInternalModulesInDB) - Begründung: durchsetzende Synchronisationsmethode.
+  - [PRIMÄR]   src/backend/Centron.BL/Services/CachedTableBL.cs:495-496 (RequestImmediateCacheUpdate, ExecuteCacheUpdates) - Begründung: durchsetzende Cache-Steuerung.
+  - [SEKUNDÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs:301-303 - Begründung: begleitende Vorlagenverwaltung.
+Prüfidee:      Neues Modul im Code registrieren, `DoCreateMissingInternalModulesInDB` ausführen und
+               prüfen, dass genau ein neuer Datenbankeintrag entsteht (keine Duplikate bei
+               wiederholtem Aufruf).
+Tracelinks:    SyRS-27
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D12: Externe Integrationen & Versanddienstleister
+
+```
+ID:            StRS-15
+Titel:         Externe Werkzeuge, Kundenportale und Versanddienstleister anbinden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, Vertriebs-/Lagermitarbeiter
+Vorbedingung:  Externer Dienst ist konfiguriert.
+Fakt:          `CPraConnectorBL.ConnectToCPra(username, password)` authentifiziert gegen ein
+               externes Kundenportal (CPra) und liefert Webhooks; `CentronGlsLogic.UploadShipment`
+               und `CentronShipcloudLogic.CreateShipmentAsync` erzeugen Versandaufträge bei zwei
+               unterschiedlichen Versanddienstleistern; `ExternalToolBL` verwaltet frei
+               konfigurierbare externe Werkzeuge; `CustomGatewayBL` verwaltet
+               Artikel-Vertrags-Importe für kundenspezifische Gateways; `EsCustomerGroupBL`
+               synchronisiert Kundengruppen mit einem externen System (`GetByExternalId`).
+Aussage:       Das System soll externe Werkzeuge und Portale konfigurierbar einbinden,
+               Versandaufträge bei mehreren Versanddienstleistern parallel erzeugen können und
+               Kundengruppen mit externen Systemen über eine externe ID synchron halten.
+Ergebnis:      Ein bei GLS oder Shipcloud erzeugter Versandauftrag mit Tracking-Information; eine
+               synchronisierte Kundengruppe.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs:15 (UploadShipment) - Begründung: durchsetzende Versandauftragserstellung.
+  - [PRIMÄR]   src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:66 (CreateShipmentAsync) - Begründung: durchsetzende, parallele Versandauftragserstellung bei zweitem Dienstleister.
+  - [SEKUNDÄR] src/backend/Centron.BL/Integrations/EsCustomerGroupBL.cs:257 (GetByExternalId) - Begründung: zeigt externe ID-basierte Synchronisation.
+Prüfidee:      Denselben Versandauftrag testweise bei GLS und Shipcloud erzeugen und beide
+               Ergebnisse (Tracking-ID) vergleichen.
+Tracelinks:    SyRS-28
+Konsolidierung: Kandidat: `CentronGlsLogic` und `CentronShipcloudLogic` bilden beide „Versandauftrag
+               erzeugen" ab - im Zielsystem über eine gemeinsame Versanddienstleister-Abstraktion
+               konsolidierbar.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D13: Projekt-, Prozess- & Tagesplanung
+
+```
+ID:            StRS-16
+Titel:         Generische Geschäftsprozesse, Projekte und persönliche Tagesplanung abbilden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Projektleiter
+Vorbedingung:  keine
+Fakt:          `ProcessBL.GetProcess<T>(int objectI3D, CentronObjectKindNumeric objectKind)` bindet
+               generische Prozessdefinitionen (`ProcessDTO`) an beliebige Fachobjekte;
+               `ProjectBL.GetProjectList(DateTime? filter)` liefert Projekte; `MyDayBL.
+               SaveWorkItemBatch` und `DashboardContainerBL.RegisterDashboardContainer` bilden die
+               persönliche Tagesplanung bzw. das individualisierbare Dashboard.
+Aussage:       Das System soll Geschäftsprozesse generisch, unabhängig vom konkreten Fachobjekt,
+               modellieren, Projekte zeitlich filterbar verwalten und jedem Mitarbeiter eine
+               individuelle Tagesplanung mit konfigurierbarem Dashboard bereitstellen.
+Ergebnis:      Ein an ein Fachobjekt gebundener Prozessablauf; eine gefilterte Projektliste; eine
+               personalisierte Tagesansicht.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Processes/ProcessBL.cs:397-399 (generische GetProcess<T>/GetProcesses<T>) - Begründung: durchsetzende, objekttypunabhängige Prozessbindung.
+  - [SEKUNDÄR] src/backend/Centron.BL/MyDay/MyDayBL.cs:335 (SaveWorkItemBatch) - Begründung: begleitende Tagesplanungsfunktion.
+Prüfidee:      Denselben Prozess an ein Ticket und an ein Projekt binden und prüfen, dass
+               `GetProcess<T>` in beiden Fällen konsistent funktioniert.
+Tracelinks:    SyRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D14: Self-Service-Portal, Web-Kanäle & mobile Anbindung
+
+```
+ID:            StRS-17
+Titel:         Kunden-Self-Service, mobile Mitarbeiteranbindung und Outlook-Integration über das Web-Portal
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde (Web-Account), Außendienstmitarbeiter, Bürokraft mit Outlook
+Vorbedingung:  Web-Account bzw. mobiles Gerät ist eingerichtet.
+Fakt:          `SelfCareBL` verwaltet konfigurierbare Selbstbedienungsformulare
+               (`SelfCareForm`); `MobileBL.GetMobileEmployee` stellt Mitarbeiterdaten für mobile
+               Clients bereit; `CentronNexus.OutlookAddIn` (Modell `Attachment`) integriert
+               Outlook direkt mit dem Nexus-Portal; `CentronNexusBL` verwaltet
+               portalweite Einstellungen.
+Aussage:       Das System soll Kunden über konfigurierbare Selbstbedienungsformulare, Mitarbeiter
+               über eine mobile Schnittstelle und Büroanwender über ein Outlook-Add-in an das
+               zentrale Nexus-Webportal anbinden.
+Ergebnis:      Ein von einem Web-Account ausgefülltes Selbstbedienungsformular; mobil abrufbare
+               Mitarbeiterdaten; ein aus Outlook heraus im Portal verfügbarer E-Mail-Anhang.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/SelfCare/SelfCareBL.cs:486,488 (GetSelfCareFormByI3D, SaveOrUpdateSelfCareForm) - Begründung: durchsetzende Formularverwaltung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Mobile/MobileBL.cs:309-311 - Begründung: begleitende mobile Datenbereitstellung.
+  - [KONTEXT]  src/nexus/CentronNexus.OutlookAddIn/Model/Attachment.cs:1-6 - Begründung: zeigt Existenz der Outlook-Integration auf Modellebene.
+Prüfidee:      Selbstbedienungsformular als Web-Account ausfüllen und im Backend als
+               `SelfCareForm`-Eintrag wiederfinden; parallel Mitarbeiterdaten über die mobile
+               Schnittstelle abrufen.
+Tracelinks:    SyRS-30, SyRS-31
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Self-Service-Kanäle sind zentral für eine Web-/SaaS-Neuimplementierung.
+Status:        belegt
+```
+
+## Domäne D15: Künstliche Intelligenz / KI-Assistenzfunktionen
+
+```
+ID:            StRS-18
+Titel:         KI-Anbieter konfigurierbar für Chat-, Bewertungs- und Kategorisierungsfunktionen anbinden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Systemadministrator, Mitarbeiter (Endnutzung z. B. im Helpdesk)
+Vorbedingung:  KI-Anbieter ist über `ArtificialIntelligenceSettingsDTO` konfiguriert.
+Fakt:          `ApiClientFactory.CreateApiClient(ArtificialIntelligenceSettingsDTO)`,
+               `CreateChatModelClient(...) : IAiModelClient`, `CreateTextRatingApiClient(...)` und
+               `CreateTicketCategoryApiClient(...)` erzeugen je nach Einstellung unterschiedliche,
+               spezialisierte KI-Clients über eine gemeinsame Factory;
+               `AiApiLinkValidator.GetValidatedApiLink(ArtificialIntelligenceApiType, string)`
+               validiert die konfigurierte API-Adresse vor Nutzung.
+Aussage:       Das System soll KI-Funktionen (Chat, Textbewertung, Ticketkategorisierung) über
+               eine zentrale, konfigurationsgesteuerte Factory anbieterunabhängig bereitstellen
+               und die konfigurierte API-Adresse vor Verwendung validieren.
+Ergebnis:      Ein passend zur Konfiguration erzeugter KI-Client; eine abgelehnte, ungültige
+               API-Adresse vor dem ersten Aufruf.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ArtificialIntelligence/ApiClientFactory.cs:9-58 (vier spezialisierte Create-Methoden) - Begründung: durchsetzende, zentrale Factory für alle KI-Clienttypen.
+  - [SEKUNDÄR] src/backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs:35 (GetValidatedApiLink) - Begründung: begleitende Validierung vor Nutzung.
+Prüfidee:      Konfiguration auf einen anderen KI-Anbieter umstellen und prüfen, dass
+               `CreateChatModelClient` ohne Codeänderung den neuen Anbieter anspricht; ungültige
+               API-Adresse konfigurieren und Ablehnung durch `GetValidatedApiLink` prüfen.
+Tracelinks:    SyRS-32
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - anbieterunabhängige Factory ist ein sinnvolles Muster für die Zielarchitektur.
+Status:        belegt
+```
+
+## Domäne D16: Asset-/Gerätestammdaten & technische Basisdienste
+
+```
+ID:            StRS-19
+Titel:         Kundenhardware als Assets verwalten - getrennt von Drucker-„Stammblättern" (Konsolidierungsfall)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Techniker, Vertriebsinnendienst
+Vorbedingung:  Kunde besitzt Hardware.
+Fakt:          `AssetManagementArticleAssignmentBL`/`AssetManagementPartnerBL` (Modul `DocuBoard`)
+               verwalten Kundenhardware als „Asset"; parallel dazu führt die Datenbank Drucker
+               unter einem eigenen Objekttyp `ObjektArt = 25 = Stammblatt` mit eigener Tabelle
+               (`GeraeteKopfI3D`-Bezug, Spalten `Stammblattnummer`/`Stammblattbezogen` u. a. in
+               `SSMS_DB_SCHEMA.sql`) - zwei getrennte Datenhaltungen für denselben fachlichen
+               Gegenstand „Kundenhardware".
+Aussage:       Das System soll Kundenhardware konsistent erfassen; im Ist-Zustand geschieht dies
+               jedoch über zwei getrennte Datenmodelle (allgemeine „Assets" versus
+               drucker-spezifische „Stammblätter"), die im Zielsystem zu einem einheitlichen
+               Asset-Konzept zusammengeführt werden sollen.
+Ergebnis:      Aktuell: ein Drucker erscheint als Stammblatt, sonstige Hardware als Asset - keine
+               einheitliche Sicht auf „die Hardware eines Kunden". Ziel: ein Asset-Konzept für
+               beide Fälle.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DocuBoard/AssetManagementArticleAssignmentBL.cs:21,45 (GetAssetManagementArticleAssignment, SaveOrUpdateAssetManagementArticleAssignment) - Begründung: durchsetzende Asset-Verwaltung.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql:72038 (Kommentar „ObjektArt|25 = Stammblatt" mit Bezug auf `GeraeteKopfI3D`) - Begründung: durchsetzender Beleg der getrennten Objektart/Tabelle für Drucker.
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql:3472,4252,6321-6323,20655,20957-20959 (Spalte/Bezeichner „Stammblattbezogen" an mehreren Stellen) - Begründung: zeigt die Verbreitung des getrennten Konzepts über mehrere Tabellen/Prozeduren hinweg.
+Prüfidee:      Für denselben Kunden einen Drucker (Stammblatt) und ein sonstiges Gerät (Asset)
+               anlegen und prüfen, dass beide aktuell über unterschiedliche Abfragen/Tabellen
+               ermittelt werden müssen, um „alle Geräte des Kunden" zu erhalten.
+Tracelinks:    SyRS-33
+Konsolidierung: Kandidat: Stammblatt (Drucker, `ObjektArt=25`) und Asset (`AssetManagement*`)
+               bilden denselben fachlichen Gegenstand „Kundenhardware" in getrennten
+               Implementierungen - im Zielsystem zu einem Asset-Konzept zusammenzuführen (siehe
+               Aufgabenstellung, Abschnitt „Konsolidierungsbedarf").
+Übernahmewürdigkeit: Workaround - historisch getrennt entstandene Datenhaltung für denselben fachlichen Gegenstand.
+Status:        belegt
+```
+
+```
+ID:            StRS-20
+Titel:         Technische Basisdienste (Icons, Länder, Transaktionsprotokoll, URLs, Video, Systemstart) bereitstellen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Module (indirekt)
+Vorbedingung:  keine
+Fakt:          `CountryBL` verwaltet Länder/Währungscodes; `TransactionBL.GetTransactionsByUserId`
+               protokolliert Systemtransaktionen je Benutzer; `SimpleUrlBL` verwaltet Kurz-URLs;
+               `VideoPortalAssignmentBL` ordnet Video-Inhalte Objekten zu; `StartBL.
+               SetConnectionString` steuert den Anwendungsstart; `ToolBL.ChangeTextFormat`
+               bietet zentrale Textformatierung.
+Aussage:       Das System soll grundlegende, modulübergreifend genutzte Dienste (Länderstamm,
+               Transaktionsprotokoll, Kurz-URLs, Video-Zuordnung, Startkonfiguration,
+               Textformatierung) als eigenständige, wiederverwendbare Komponenten bereitstellen.
+Ergebnis:      Konsistente, an einer Stelle gepflegte Basisdaten und -dienste für alle
+               Fachmodule.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Transactions/TransactionBL.cs:613-615 (GetAllTransactions, GetTransactionsByUserId, GetTransactionByTransactionI3D) - Begründung: durchsetzendes, benutzerbezogenes Transaktionsprotokoll.
+  - [SEKUNDÄR] src/backend/Centron.BL/CountryArea/CountryBL.cs:118-121 (SearchCountryByCountryCode, SearchCountryByCurrencyISO, SaveCountry, RemoveCountry) - Begründung: begleitende Stammdatenverwaltung.
+Prüfidee:      Systemweite Transaktion auslösen und über `GetTransactionsByUserId` dem
+               verursachenden Benutzer zuordnen.
+Tracelinks:    SyRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/SyRS.md

@@ -0,0 +1,999 @@
+# SyRS - System Requirements Specification
+
+c-entron ERP-Suite - Reverse Requirements Engineering, Iteration 02 (2026-08-26)
+
+Systemverhalten, Schnittstellen, Performance- und Sicherheitsanforderungen. Jede SyRS-Anforderung
+referenziert die zugehörige StRS-Anforderung (Feld `Tracelinks`).
+
+## Domäne D1: Vertrieb & Kundenbeziehungsmanagement
+
+```
+ID:            SyRS-1
+Titel:         Rechnungen nach Festschreibung systemweit gegen inhaltliche Änderung sperren
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Belegverwaltung)
+Vorbedingung:  Eine Rechnung wurde erstellt und ist noch nicht festgeschrieben.
+Fakt:          `ReceiptInvoiceBL.FixInvoice` prüft zunächst `CheckIfInvoiceIsFixed`, setzt danach
+               per Raw-SQL `UPDATE RechKopf SET IsFixed = 1 WHERE I3D = @I3D` innerhalb einer
+               Transaktion und schreibt einen Log-Eintrag (`ReceiptLogKind.FixedState`).
+Aussage:       Das System soll den Übergang einer Rechnung in den festgeschriebenen Zustand
+               transaktional, geprüft (keine Doppel-Festschreibung) und mit Protokolleintrag
+               durchführen und danach inhaltliche Änderungen an dieser Rechnung verhindern.
+Ergebnis:      `RechKopf.IsFixed = 1`, ein `ReceiptLogKind.FixedState`-Eintrag ist vorhanden, ein
+               erneuter `FixInvoice`-Aufruf liefert einen Fehler statt einer erneuten Festschreibung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:86-107 (FixInvoice: CheckIfInvoiceIsFixed-Prüfung, transaktionales UPDATE RechKopf.IsFixed) - Begründung: durchsetzende Stelle mit konkreter Prüfbedingung und Datenbank-Constraint-Setzung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs:109-123 (ReceiptLogBL.CreateEntry mit ReceiptLogKind.FixedState) - Begründung: Protokollierung als begleitender, nicht selbst durchsetzender Nachweis.
+  - [KONTEXT]  Glossar.md, Eintrag „GoBD-Fixierung" - Begründung: ordnet den technischen Mechanismus in einen bekannten handelsrechtlichen Kontext ein (Interpretation).
+Prüfidee:      `FixInvoice` zweimal auf dieselbe Rechnung anwenden - der zweite Aufruf muss
+               `Result.AsError` liefern; ein direkter Änderungsversuch an Positionen einer
+               festgeschriebenen Rechnung muss serverseitig abgelehnt werden.
+Tracelinks:    StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Integritätssicherung ist unabhängig von der Zielarchitektur erforderlich.
+Status:        belegt
+```
+
+```
+ID:            SyRS-2
+Titel:         Belegweiterleitung zwischen Belegarten mit Versionierung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Belegverwaltung)
+Vorbedingung:  Ein Ausgangsbeleg (z. B. Angebot) existiert.
+Fakt:          `ReceiptBL` bietet generische, typparametrisierte Zugriffe `GetReceiptByI3D<T>` und
+               `GetReceiptVersionByI3D<T>` über alle Belegarten hinweg (`CentronObjectKindNumeric`);
+               `ForwardReceiptResult`/`CopyReceiptResult` modellieren das Ergebnis einer
+               Belegweiterleitung bzw. -kopie.
+Aussage:       Das System soll Belege beliebiger Art über eine gemeinsame, typisierte Schnittstelle
+               referenzieren, versionieren und in andere Belegarten weiterleiten oder kopieren
+               können, ohne belegartspezifischen Code in den aufrufenden Schichten zu benötigen.
+Ergebnis:      Ein neuer Folgebeleg mit Bezug zum erzeugenden Ausgangsbeleg und eigener
+               Versionshistorie.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:641-724 (GetReceiptByI3D<T>, GetReceiptVersionByI3D<T>) - Begründung: durchsetzende, generische Zugriffsmethode auf das versionierte Belegmodell.
+  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/DataAndResults/ForwardReceipt/ForwardReceiptResult.cs, CopyReceiptResult.cs - Begründung: Ergebnisklassen zeigen die vorgesehenen Operationen, ohne selbst die Regel durchzusetzen.
+  - [KONTEXT]  src/backend/Centron.BL/Sales/Receipts/DataAndResults/ (Unterordner CreateReceipt, CreateReceiptForHelpdeskTimers, CreateReceiptItemsFromExistingItems) - Begründung: zeigt die Bandbreite unterstützter Erzeugungsvarianten.
+Prüfidee:      Ein Angebot per Weiterleitung in einen Auftrag überführen und prüfen, dass die neue
+               Version einen Rückverweis auf den Ausgangsbeleg trägt.
+Tracelinks:    StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Belegkette ist Kernfunktion.
+Status:        belegt
+```
+
+```
+ID:            SyRS-3
+Titel:         RMA-Vorgänge mit gerichteter Versandhistorie (an/von Lieferant) verwalten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (RMA-Verwaltung)
+Vorbedingung:  Ein Artikel eines Kunden ist reklamationsfähig erfasst.
+Fakt:          `RmaBL` unterscheidet `RmaSendForth` (Versand an Lieferant) und `RmaSendBack`
+               (Rückversand) als eigene Entitäten/Methoden (`GetRmaSendForthByI3D`,
+               `GetRmaSendBacksByFilter`) neben `RmaArticleHistory`.
+Aussage:       Das System soll zu jedem RMA-Artikel die Versandrichtung (an den Lieferanten /
+               vom Lieferanten zurück) getrennt nachvollziehbar dokumentieren.
+Ergebnis:      Ein RMA-Vorgang mit lückenloser, richtungsbezogener Versandhistorie je Artikel.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/CustomerArea/RmaBL.cs:685,692,709 (GetRmaSendForthByI3D, GetRmaSendBackByI3D, GetRmaSendBacksByFilter) - Begründung: konkrete, richtungsspezifische Zugriffsmethoden.
+  - [SEKUNDÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs:646 (GetRmaArticleHistoryByI3D) - Begründung: begleitende Historienfunktion.
+Prüfidee:      Für eine RMA einen Artikel an den Lieferanten senden (RmaSendForth) und danach den
+               Rückversand (RmaSendBack) erfassen; beide Einträge müssen unabhängig abrufbar sein.
+Tracelinks:    StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D2: Einkauf & Lieferantenmanagement
+
+```
+ID:            SyRS-4
+Titel:         Multi-Distributor-EDI-Bestellabwicklung mit distributorspezifischer Kodierung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System (EDI-Gateway)
+Vorbedingung:  Ein Bestellvorschlag oder eine Bestellung liegt vor; Distributor ist konfiguriert.
+Fakt:          `EDIDispatcherBL` bietet je Distributor eigene asynchrone Methoden
+               (`EdiEgisOrderUploadAsync`, `EdiItScopeOrderUploadAsync`, `EdiConcertoOrderUploadAsync`,
+               `KomsaArticleCheckAsync`) sowie eine generische `CreateEDISuggestionOrderAsync` mit
+               `EDIMultidistributors distributor`-Parameter.
+Aussage:       Das System soll Bestellungen in einem gemeinsamen internen Modell erfassen und beim
+               Versand automatisch in das distributorspezifische EDI-Format und den zugehörigen
+               Übertragungsweg übersetzen.
+Ergebnis:      Eine an den jeweiligen Distributor formatgerecht übermittelte elektronische Bestellung
+               mit Rückmeldung (`Result<...>`).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/EDI/EDIDispatcherBL.cs:56-290 (distributorspezifische Upload-/Check-Methoden) - Begründung: durchsetzende, pro Distributor unterschiedliche Übertragungslogik.
+  - [SEKUNDÄR] src/backend/Centron.BL/EDI/Alltron/AlltronOrderBL.cs:173-176 (CreateOrderDocument) - Begründung: zeigt beispielhaft die distributorspezifische XML-Erzeugung für Alltron.
+Prüfidee:      Dieselbe interne Bestellung an zwei unterschiedliche Distributoren senden und die
+               jeweils distributorspezifische Zieldatenstruktur (XDocument) auf Formatunterschiede
+               prüfen.
+Tracelinks:    StRS-3
+Konsolidierung: Kandidat: distributorspezifische Upload-Methoden (Egis/ITscope/Concerto/Komsa) bilden dieselbe fachliche Funktion „Bestellung elektronisch übermitteln" mehrfach separat ab; im Zielsystem als eine parametrisierte Schnittstelle konsolidierbar.
+Übernahmewürdigkeit: übernehmen - Konsolidierung der Übertragungswege wird für die Zielarchitektur empfohlen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-5
+Titel:         Bestellvorschlagsermittlung aus Bestand und Bedarf
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Einkaufsplanung)
+Vorbedingung:  Artikelbestände und Verkaufshistorie sind erfasst.
+Fakt:          `OrderSuggestionListBL.GetOrderSuggestionArticle(AppUser, ...)` und
+               `GetArticlePerItems(AppUser, OrderSuggestionFilter)` liefern artikel- bzw.
+               positionsbezogene Vorschlagslisten.
+Aussage:       Das System soll auf Basis von Filterkriterien (`OrderSuggestionFilter`) je Artikel
+               und je Bestellposition einen Bestellvorschlag ermitteln.
+Ergebnis:      Eine gefilterte Liste von Bestellvorschlägen (`SuggestionBaseDTO`/`SuggestionOrderDTO`).
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:430-432 (GetOrderSuggestionArticle, GetArticlePerItems, GetOrderSuggestionOrder) - Begründung: UI-nahe Ermittlungsmethoden; die konkrete Meldebestand-/Bedarfsberechnung war im erhobenen Ausschnitt nicht einsehbar.
+Prüfidee:      Artikel mit Bestand unterhalb eines konfigurierten Meldebestands anlegen und prüfen,
+               ob `GetOrderSuggestionArticle` ihn in die Vorschlagsliste aufnimmt.
+Tracelinks:    StRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D3: Lager, Artikel & Produktion
+
+```
+ID:            SyRS-6
+Titel:         Automatische Ermittlung des zutreffenden Staffelpreises nach Bestellmenge
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Preisfindung)
+Vorbedingung:  Für einen Artikel sind mehrere `ArticleVolumePrices`-Staffeln mit `FromAmount`
+               hinterlegt.
+Fakt:          `GetVolumePrice(IList<ArticleVolumePrices> volumePrices, decimal? amount)` sortiert
+               absteigend nach `FromAmount` und wählt den ersten Eintrag mit `FromAmount <= amount`
+               (Zeile 96); bei leerer Liste wird `null` zurückgegeben.
+Aussage:       Das System soll bei der Preisfindung automatisch die Staffel mit der höchsten
+               Mengenschwelle wählen, die die angefragte Menge noch erfüllt, und ohne definierte
+               Staffel keinen Staffelpreis anwenden.
+Ergebnis:      Der korrekte, mengenabhängige Staffelpreis bzw. `null` als Signal für „kein
+               Staffelpreis anwendbar".
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs:88-97 (GetVolumePrice, vollständige Auswahllogik) - Begründung: durchsetzende, eindeutig nachvollziehbare Sortier-/Auswahlregel.
+Prüfidee:      Staffeln bei 1, 10 und 50 Stück hinterlegen; Preisermittlung für Mengen 5, 10, 49 und
+               100 durchführen und jeweils die erwartete Staffel prüfen.
+Tracelinks:    StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-7
+Titel:         Lagerortgenaue Bestandsführung mit mengengewichteter Einkaufspreisnachführung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Bestandsführung)
+Vorbedingung:  Artikel ist einem Lager/Lagerplatz zugeordnet.
+Fakt:          `ArticleStockBL.UpdateArticleStock(int articleI3D, int? articleSecondaryStorageI3D,
+               double quantity)` und `UpdateArticlePurchasePrice(AppUser, IReceiptBase, IReceiptItemBase,
+               IStock, int articleI3D, decimal oldQuantity, decimal quantity, decimal purchasePrice)`
+               nehmen sowohl Alt- als auch Neumenge und -preis entgegen.
+Aussage:       Das System soll bei jeder Bestandsveränderung (Zu-/Abgang) den Einkaufspreis unter
+               Berücksichtigung der bisherigen Menge und des bisherigen Preises neu berechnen.
+Ergebnis:      Bestand und mengengewichteter Einkaufspreis sind nach der Buchung konsistent.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs:47-74 (UpdateArticleStock, IncreaseArticleStock, UpdateArticlePurchasePrice mit oldQuantity/quantity/purchasePrice) - Begründung: durchsetzende Methoden mit den für eine gewichtete Neuberechnung nötigen Parametern; die genaue Berechnungsformel selbst war im erhobenen Methodenkopf nicht einsehbar.
+Prüfidee:      Wareneingang mit einer zweiten, abweichenden Preisstufe buchen und den neuen
+               gewichteten Durchschnittspreis gegen eine manuell berechnete Erwartung prüfen.
+Tracelinks:    StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - [HYPOTHESE: die genaue Berechnungsformel (z. B. gleitender Durchschnitt vs. FIFO) ist aus der Methodensignatur allein nicht ableitbar und wurde nicht im Methodenkörper verifiziert].
+Status:        belegt
+```
+
+```
+ID:            SyRS-8
+Titel:         Produktionsauftragsverwaltung mit Positions- und Statusprotokoll
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Produktionsplanung)
+Vorbedingung:  Produktionsmaschine und Artikel sind erfasst.
+Fakt:          `ProductionOrderBL` trennt `ProductionOrder`, `ProductionOrderItem` und
+               `ProductionOrderLog` als eigene Speicher- und Filtermethoden
+               (`SaveProductionOrder`, `SaveProductionOrderItem`, `SaveProductionOrderLog`/
+               `SaveProductionOrderLog(List<...>)`).
+Aussage:       Das System soll Produktionsaufträge mit beliebig vielen Positionen erfassen und jede
+               relevante Statusänderung als separaten, mehrfach batchbar speicherbaren Log-Eintrag
+               festhalten.
+Ergebnis:      Ein Produktionsauftrag mit Positionen und vollständiger, batchfähiger Protokollhistorie.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Production/ProductionOrderBL.cs:45,122,184,194,205 (Save-/Filter-Methoden für Order, Item, Log inkl. Batch-Log) - Begründung: UI-nahe, aber konkrete und vollständige Methodenfamilie.
+Prüfidee:      Produktionsauftrag mit zwei Positionen anlegen, Status mehrfach ändern und über
+               `GetProductionOrderLogByFilter` die vollständige, chronologische Historie abrufen.
+Tracelinks:    StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D4: Finanzbuchhaltung & Zahlungsverkehr (risikorelevant)
+
+```
+ID:            SyRS-9
+Titel:         Exportstatus-Flag verhindert doppelten Zahlungsexport
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Zahlungsexport)
+Vorbedingung:  Rechnung ist zahlungsrelevant und noch nicht exportiert.
+Fakt:          `PaymentTransactionBL.SetInvoicesAsExported(int employeeI3D, int invoiceI3D)` setzt
+               das Exportiert-Flag einer Rechnung; `ResetInvoiceExportedFlag(AppUser,
+               List<int> incomingPaymentLogI3Ds)` ist die einzige im erhobenen Ausschnitt
+               identifizierte Stelle, die es zurücksetzt.
+Aussage:       Das System soll eine Rechnung nach Zahlungsexport eindeutig als exportiert
+               kennzeichnen, so dass sie bei einer erneuten Exportselektion nicht automatisch
+               erneut aufgenommen wird, und ein Zurücksetzen des Flags nur über eine benannte,
+               auf den ausführenden Mitarbeiter (`employeeI3D`/`AppUser`) zurückführbare Funktion
+               zulassen.
+Ergebnis:      Keine unbeabsichtigte doppelte SEPA-/Zahlungsvorlage derselben Rechnung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/PaymentTransactions/PaymentTransactionBL.cs:291,296 (SetInvoicesAsExported, ResetInvoiceExportedFlag mit Benutzerbezug) - Begründung: durchsetzende, auf den handelnden Benutzer zurückführbare Statusänderung.
+Prüfidee:      Rechnung exportieren (Flag gesetzt), Exportlauf erneut mit
+               `showOnlyExportedInvoices: false` starten - Rechnung darf nicht erneut selektiert
+               werden; erst nach `ResetInvoiceExportedFlag` darf sie wieder erscheinen.
+Tracelinks:    StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zwingende Kontrolle für jeden Zahlungsverkehr.
+Status:        belegt
+```
+
+```
+ID:            SyRS-10
+Titel:         Bankkontoabgleich über FinAPI mit Erkennung unbekannter IBANs
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System (Online-Banking-Anbindung)
+Vorbedingung:  FinAPI-Zugangsdaten und Bankverbindung sind konfiguriert.
+Fakt:          `OnlineBankingFinApiBL.GetFinApiClientCredentials(GetFinApiClientCredentialsRequest,
+               bool isUnitTest)` bezieht Zugangsdaten von der externen FinAPI-Schnittstelle
+               (`Centron.APIs.FinAPI`); `OnlineBankingAccountTransactionsBL.CheckForUnknownIbans`
+               prüft eingehende Transaktionen auf nicht zuordenbare IBANs.
+Aussage:       Das System soll Kontobewegungen über die externe FinAPI-Schnittstelle abrufen und
+               Transaktionen mit einer im System nicht bekannten IBAN gesondert kennzeichnen, statt
+               sie automatisch einer beliebigen Rechnung zuzuordnen.
+Ergebnis:      Eine Liste unbekannter IBANs zur manuellen Prüfung, getrennt von automatisch
+               zuordenbaren Transaktionen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs:75 (CheckForUnknownIbans, vollständige Signatur mit Request/Result) - Begründung: durchsetzende Prüfmethode gegen Fehlzuordnung von Zahlungen.
+  - [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs:29 (GetFinApiClientCredentials) - Begründung: zeigt die externe Authentifizierung als Vorbedingung des Abgleichs.
+Prüfidee:      Kontoumsatz mit unbekannter IBAN importieren und prüfen, dass er in
+               `CheckForUnknownIbans` erscheint statt automatisch verbucht zu werden.
+Tracelinks:    StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Fehlzuordnungsschutz bleibt in jeder Zielarchitektur nötig.
+Status:        belegt
+```
+
+```
+ID:            SyRS-11
+Titel:         Parallele Kontenrahmen mit konfigurierbarem Buchhaltungsexport
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        System (Buchhaltungsexport)
+Vorbedingung:  Mindestens ein Kontenrahmen ist als Standard markiert.
+Fakt:          `GetBookKeepingAccounts(bool fromDefaultSystem)` unterscheidet explizit den
+               Standard-Kontenrahmen von weiteren angelegten Kontenrahmen
+               (`GetBookKeepingAccountSystems(AccountSystemFilter)`).
+Aussage:       Das System soll genau einen Kontenrahmen als Standard auszeichnen und weitere
+               Kontenrahmen parallel dazu verwalten können, ohne dass sich deren Konten
+               gegenseitig überschreiben.
+Ergebnis:      Konten sind eindeutig ihrem Kontenrahmen zugeordnet abrufbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/BookKeepingAccountSystems/BookKeepingAccountSystemBL.cs:67 (GetBookKeepingAccounts mit fromDefaultSystem-Unterscheidung) - Begründung: durchsetzende Trennung von Standard- und Zusatzkontenrahmen.
+Prüfidee:      Zweiten Kontenrahmen anlegen und prüfen, dass `GetBookKeepingAccounts(true)`
+               ausschließlich Konten des Standardrahmens liefert.
+Tracelinks:    StRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D10: Sicherheit, Zugriffsschutz & Berechtigungen (risikorelevant)
+
+```
+ID:            SyRS-12
+Titel:         Gruppenbasierte Rechteauflösung für Programmbenutzer über Sichtrus/Sichmemb
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Rechteprüfung)
+Vorbedingung:  Benutzer ist mindestens einer Rechtegruppe zugeordnet.
+Fakt:          `HasUserRight` cached das Ergebnis pro Benutzer (`Session.Advanced.Cache.GetOrAdd`)
+               und ermittelt es über `SELECT st.Recht ... FROM Sichtrus st INNER JOIN Sichmemb sm ON
+               sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D`.
+Aussage:       Das System soll Rechte ausschließlich über Gruppenmitgliedschaft auflösen (kein
+               direktes Benutzer-Recht ohne Gruppe) und das Ergebnis je Benutzer cachen, um
+               wiederholte Datenbankzugriffe zu vermeiden.
+Ergebnis:      Eine konsistente, gecachte Liste der Rechte-IDs eines Benutzers.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644-660 (HasUserRight, GetAllAppRightsFromUser mit Cache und SQL-Join) - Begründung: durchsetzende, konkrete Abfrage- und Cache-Logik.
+Prüfidee:      Benutzer aus einer Rechtegruppe entfernen und prüfen, dass `HasUserRight` nach
+               Cache-Invalidierung das entzogene Recht nicht mehr liefert.
+Tracelinks:    StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - [HYPOTHESE: der Cache-Invalidierungszeitpunkt bei Gruppenänderung war im erhobenen Ausschnitt nicht erkennbar; ein zu spätes Invalidieren wäre ein Sicherheitsrisiko (veraltete Berechtigung bleibt wirksam)].
+Status:        belegt
+```
+
+```
+ID:            SyRS-13
+Titel:         Gesalzenes Passwort-Hashing als Grundlage der Authentifizierung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Vertraulichkeit/Integrität (ISO 25010: Security - Confidentiality)
+Akteur:        System (Authentifizierung)
+Vorbedingung:  Benutzer setzt oder ändert ein Passwort.
+Fakt:          `CreateSalt(int size)` erzeugt einen kryptographisch zufälligen Salt
+               (`RandomNumberGenerator.GetBytes`); `CreatePasswordHash(pwd, salt)` bildet
+               `SHA1(pwd + salt)` als Hexstring.
+Aussage:       Das System soll jedes Passwort mit einem individuellen, kryptographisch
+               zufälligen Salt versehen, bevor es gehasht gespeichert wird.
+Ergebnis:      Kein Klartextpasswort in der Datenbank; identische Passwörter zweier Benutzer
+               erzeugen wegen unterschiedlichem Salt unterschiedliche Hashes.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Core/CryptoUtils.cs:15-33 (CreateSalt, CreatePasswordHash) - Begründung: durchsetzende, vollständige Hashing-Implementierung.
+Prüfidee:      Zwei Benutzer mit identischem Passwort anlegen und prüfen, dass die gespeicherten
+               Hashes unterschiedlich sind (unterschiedlicher Salt).
+Tracelinks:    StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: veraltet - SHA1 ohne Schlüsselstreckung gilt nach aktuellem Stand der Technik
+               (vgl. OWASP Password Storage Cheat Sheet) als nicht mehr ausreichend gegen
+               Offline-Brute-Force-Angriffe; im Zielsystem durch Argon2id/bcrypt/PBKDF2 mit
+               ausreichendem Kostenfaktor zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-14
+Titel:         REST-API-Endpunkte gegen Benutzerrechte autorisieren
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Webservice-Schicht)
+Vorbedingung:  Ein Client ruft einen REST-Endpunkt auf.
+Fakt:          `AuthorizeAllUserRightsAttribute(params int[] userRightIds) : TypeFilterAttribute`
+               mit `AllUserRightsAuthorizationFilter.OnAuthorization(AuthorizationFilterContext)`
+               im Webservice-Projekt `Centron.Controllers`.
+Aussage:       Das System soll REST-API-Controller-Methoden deklarativ mit den erforderlichen
+               Rechte-IDs annotieren und bei fehlender Berechtigung den Aufruf vor Ausführung der
+               Controller-Logik abweisen.
+Ergebnis:      Ein Request ohne alle geforderten Rechte wird mit einem Autorisierungsfehler
+               abgewiesen, bevor Geschäftslogik ausgeführt wird.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Controllers/Authorization/AuthorizeAllUserRightsAttribute.cs (Klassen AuthorizeAllUserRightsAttribute, AllUserRightsAuthorizationFilter.OnAuthorization) - Begründung: durchsetzender ASP.NET-Autorisierungsfilter, der vor der Controller-Aktion greift.
+Prüfidee:      Endpunkt mit `[AuthorizeAllUserRights(1234)]` annotieren und mit einem Benutzer ohne
+               Recht 1234 aufrufen - Erwartung: HTTP 401/403 statt Ausführung der Aktion.
+Tracelinks:    StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - deklarative API-Autorisierung ist Best Practice und für die Zielarchitektur direkt weiterverwendbar.
+Status:        belegt
+```
+
+```
+ID:            SyRS-15
+Titel:         TOTP-basierte Zwei-Faktor-Authentifizierung als Zusatzfaktor
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Authentifizierung)
+Vorbedingung:  Benutzer hat einen Zwei-Faktor-Schlüssel hinterlegt.
+Fakt:          `ValidateAuthenticationPin` liefert bei fehlendem Schlüssel die Fehlermeldung „Ihrem
+               Benutzer ist kein Zwei-Faktor Schlüssel in der Personalverwaltung hinterlegt!" und
+               delegiert sonst an `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`.
+Aussage:       Das System soll eine Zwei-Faktor-Anmeldung nur zulassen, wenn dem Benutzer zuvor
+               ein Schlüssel zugeordnet wurde, und die PIN-Prüfung an eine standardkonforme
+               TOTP-Implementierung delegieren.
+Ergebnis:      Erfolgreiche 2FA nur mit gültigem, zeitlich passendem TOTP-Code.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54 (ValidateAuthenticationPin, vollständiger Methodenkörper) - Begründung: durchsetzende Prüfung mit expliziter Vorbedingung.
+Prüfidee:      Benutzer ohne hinterlegten Schlüssel anmelden lassen - erwartete Fehlermeldung;
+               danach Schlüssel hinterlegen und mit korrektem/falschem TOTP-Code erneut prüfen.
+Tracelinks:    StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-16
+Titel:         Geschützte Verwaltung sensibler Zugangsdaten, Zertifikate und Tokens Dritter
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Zugangsdaten-/Zertifikatsverwaltung)
+Vorbedingung:  Sensible Daten (Kundenzugangsdaten, Signaturzertifikat, API-Token) sind hinterlegt.
+Fakt:          `PasswordManagementBL.GetDecryptedPassword` mit begleitendem
+               `PasswordManagementAccessLogBL`; `PasswordManagerBL.GetPasswordManagerCustomersEmployeesRights`;
+               `PdfSigningBL.IsPdfSigningAvailable`/`SavePdfSigningSettings`.
+Aussage:       Das System soll den Zugriff auf sensible Drittdaten (Kundenzugangsdaten,
+               Signaturzertifikate) grundsätzlich rechte- und protokollpflichtig gestalten, statt
+               sie unkontrolliert im Klartext bereitzustellen.
+Ergebnis:      Jeder Zugriff auf sensible Drittdaten ist entweder rechteabhängig eingeschränkt
+               oder protokolliert nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManagementArea/PasswordManagementAccessLogBL.cs:383 - Begründung: durchsetzende Protokollierung des Zugriffs.
+  - [SEKUNDÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:391; src/backend/Centron.BL/Security/PdfSigningBL.cs:479-480 - Begründung: begleitende Rechte-/Verfügbarkeitsprüfungen.
+Prüfidee:      Siehe SwRS-38 bis SwRS-41.
+Tracelinks:    StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D5: Personalverwaltung & Zeitwirtschaft
+
+```
+ID:            SyRS-18
+Titel:         Administratorstatus getrennt von regulären Einzelrechten führen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Benutzerverwaltung)
+Vorbedingung:  Benutzer existiert.
+Fakt:          `AppUserBL.IsUserInAdminGroup(AppUser appUser)` ist eine eigene Methode neben der
+               allgemeinen Rechteprüfung aus `AppRightsBL`.
+Aussage:       Das System soll den Administratorstatus eines Benutzers als eigene, von
+               Einzelrechten unabhängige Eigenschaft führen und abfragbar machen.
+Ergebnis:      Eine eindeutige Ja/Nein-Aussage, ob ein Benutzer Mitglied der Administratorgruppe
+               ist.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/EmployeeArea/AppUserBL.cs:247 (IsUserInAdminGroup) - Begründung: durchsetzende, dedizierte Statusprüfung.
+Prüfidee:      Benutzer der Admin-Gruppe hinzufügen/entfernen und `IsUserInAdminGroup` vor/nach der
+               Änderung prüfen.
+Tracelinks:    StRS-9
+Konsolidierung: Kandidat: Verhältnis von `IsUserInAdminGroup` zur allgemeinen Rechteprüfung
+               (`AppRightsBL.HasUserRight`) im Zielsystem klären - ggf. Admin-Status als
+               Sonderrecht statt eigenem Flag abbilden.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-19
+Titel:         Zeitmodell- und Kalenderverwaltung je Mitarbeiter
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Personalverwaltung)
+Vorbedingung:  Mitarbeiter ist angelegt.
+Fakt:          `TimingSettingsBL.GetTimingSettingsByI3D`/`GetTimingSettingsByFilter` sowie
+               `CalendarBL.GetCalendarRepresentationSettings`/`GetCalendarSynchronizationSettings`.
+Aussage:       Das System soll je Mitarbeiter ein Zeitmodell und individuelle
+               Kalenderdarstellungs-/Synchronisationseinstellungen verwalten.
+Ergebnis:      Ein Mitarbeiter mit zugeordnetem Zeitmodell und Kalendereinstellungen.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Time/TimingSettingsBL.cs:583-585 und src/backend/Centron.BL/Calendar/CalendarBL.cs:65-67 - Begründung: UI-nahe Konfigurationszugriffe ohne tiefere im Ausschnitt erkennbare Geschäftsregel.
+Prüfidee:      Zeitmodell einem Mitarbeiter zuordnen und Kalendersynchronisation aktivieren; beide
+               Einstellungen unabhängig voneinander prüfen.
+Tracelinks:    StRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-25
+Titel:         Batchfähige Nutzungstelemetrie für interne Werkzeuge und KI-Funktionen
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Analysierbarkeit (ISO 25010: Maintainability - Analysability)
+Akteur:        System (Telemetriedienst)
+Vorbedingung:  Ein Werkzeug/eine KI-Funktion wurde aufgerufen.
+Fakt:          Siehe SwRS-70 (`RecordArtificialIntelligenceToolUsage`,
+               `UpsertMcpToolUsageBatch`).
+Aussage:       Das System soll Werkzeug- und KI-Nutzung batchfähig und mit Benutzer-/
+               Hardwarebezug erfassen, um Auswertungen über Nutzungsmuster zu ermöglichen.
+Ergebnis:      Eine vollständige, batchweise gespeicherte Nutzungsstatistik.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Telemetry/TelemetryBL.cs:560-563 - Begründung: durchsetzende Erfassungsmethoden.
+Prüfidee:      Siehe SwRS-70.
+Tracelinks:    StRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D6: Kundenservice, Ticketing & Support
+
+```
+ID:            SyRS-17
+Titel:         Checklisten und Aufgaben ticketübergreifend wiederverwendbar verwalten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Ticket-/Aufgabenverwaltung)
+Vorbedingung:  Vorlage existiert oder wird neu angelegt.
+Fakt:          `CentronChecklistBL.GetChecklistsByFilter(CentronChecklistFilter)` liefert
+               `CentronChecklist`-Objekte unabhängig vom Ticket; `TaskManagementTaskBL.GetTasks(int
+               page, int entriesPerPage, GetTasksFilter)` liefert paginierte Aufgaben;
+               `ChecklistVirtualObjectCategoryBL` kategorisiert Checklisten-Objekte.
+Aussage:       Das System soll Checklisten und Aufgaben als eigenständige, filterbare und
+               kategorisierbare Objekte führen, die nicht zwingend an ein einzelnes Ticket
+               gebunden sind.
+Ergebnis:      Wiederverwendbare Checklisten-/Aufgabenvorlagen, die mehreren Tickets zugeordnet
+               werden können.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs:103-106 (vier Filter-/Zugriffsmethoden) - Begründung: durchsetzende, ticketunabhängige Verwaltung.
+  - [SEKUNDÄR] src/backend/Centron.BL/TaskManager/TaskManagementTaskBL.cs:555 (GetTasks mit Paging) - Begründung: begleitende Aufgabenverwaltung.
+Prüfidee:      Checkliste unabhängig von einem konkreten Ticket anlegen, danach zwei Tickets
+               zuordnen und prüfen, dass Änderungen an der Vorlage nicht rückwirkend beide Tickets
+               beeinflussen (bzw. dokumentieren, falls doch - Verhalten im erhobenen Ausschnitt
+               nicht abschließend erkennbar).
+Tracelinks:    StRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-20
+Titel:         Externe Helpdesk-Konfiguration und Ticketprojekt-Abhängigkeiten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Ticketprojektverwaltung)
+Vorbedingung:  Mehrere zusammenhängende Tickets existieren.
+Fakt:          `TicketProjectBL.GetTicketProjectDependencies(int ticketProjectI3D)` und
+               `SaveOrUpdateTicketProjectDependency` bilden Abhängigkeiten zwischen Tickets
+               innerhalb eines Projekts ab; `ExternalHelpdeskConfigurationBL` verwaltet externe
+               Helpdesk-Anbindungen als eigene Konfigurationsobjekte.
+Aussage:       Das System soll Abhängigkeiten zwischen Tickets innerhalb eines Ticketprojekts
+               explizit modellieren und externe Helpdesk-Systeme über eigene, mehrfach anlegbare
+               Konfigurationen anbinden.
+Ergebnis:      Ein Ticketprojekt mit nachvollziehbaren Abhängigkeiten zwischen seinen Tickets;
+               eine aktive externe Helpdesk-Konfiguration.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs:576-577 (GetTicketProjectDependencies, SaveOrUpdateTicketProjectDependency) - Begründung: durchsetzende Abhängigkeitsverwaltung.
+  - [SEKUNDÄR] src/backend/Centron.BL/ExternalHelpdesk/ExternalHelpdeskConfigurationBL.cs:203-205 - Begründung: begleitende Konfigurationsverwaltung.
+Prüfidee:      Zwei Tickets in einem Projekt mit einer Abhängigkeit „muss vor" verknüpfen und
+               prüfen, dass diese Reihenfolge in der Projektübersicht sichtbar ist.
+Tracelinks:    StRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D7: Kommunikation
+
+```
+ID:            SyRS-21
+Titel:         E-Mail-Verarbeitung mit Blacklist- und Workflow-Steuerung
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Mail-Verarbeitung)
+Vorbedingung:  Eingehende oder ausgehende E-Mail liegt vor.
+Fakt:          `DomainBlacklistBL.IsBlacklisted(string email)` prüft Absenderdomänen;
+               `MailScannerBL.GetWorkflows(MailScannerWorkflowFilter)` und `SaveWorkflow` steuern
+               automatisierte Verarbeitungs-Workflows gescannter E-Mails.
+Aussage:       Das System soll E-Mails von gesperrten Domänen erkennen und eingehende E-Mails
+               über konfigurierbare Workflows automatisiert verarbeiten (z. B. Zuordnung zu
+               Tickets).
+Ergebnis:      E-Mails blockierter Domänen werden nicht weiterverarbeitet; übrige E-Mails
+               durchlaufen den konfigurierten Workflow.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Mail/Blacklist/DomainBlacklistBL.cs:279 (IsBlacklisted) - Begründung: durchsetzende Prüfmethode.
+  - [SEKUNDÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs:285-286 (GetWorkflows, SaveWorkflow) - Begründung: begleitende Workflow-Konfiguration.
+Prüfidee:      E-Mail von einer als Blacklist markierten Domäne senden und prüfen, dass
+               `IsBlacklisted` sie erkennt, bevor ein Workflow angestoßen wird.
+Tracelinks:    StRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-22
+Titel:         Zentrale, filter- und quittierbare Benutzerbenachrichtigungen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Benachrichtigungsdienst)
+Vorbedingung:  Ein benachrichtigungswürdiges Ereignis ist eingetreten.
+Fakt:          `NexusNotificationsBL.MarkNexusNotificationsAsRead(List<int>, LoggedInUser)` und
+               `DeleteNexusNotifications(List<int>)` verwalten den Gelesen-/Gelöscht-Status;
+               `CentronNotificationsBL.GetCentronNotificationsSettings()` liefert je-Benutzer-
+               Einstellungen.
+Aussage:       Das System soll Benachrichtigungen je Benutzer mit explizitem Gelesen-Status
+               führen und dessen Benachrichtigungspräferenzen konfigurierbar machen.
+Ergebnis:      Eine Benachrichtigungsliste mit korrektem Gelesen-/Ungelesen-Status je Benutzer.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs:342-343 (MarkNexusNotificationsAsRead, DeleteNexusNotifications) - Begründung: durchsetzende Statuspflege.
+  - [SEKUNDÄR] src/backend/Centron.BL/Notifications/CentronNotificationsBL.cs:357-359 - Begründung: begleitende Einstellungsverwaltung.
+Prüfidee:      Benachrichtigung als gelesen markieren und prüfen, dass sie in einer
+               „nur ungelesen"-Filterung nicht mehr erscheint.
+Tracelinks:    StRS-11
+Konsolidierung: Kandidat: siehe StRS-11 (NexusNotifications vs. Notifications).
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-36
+Titel:         Kanalspezifische Kommunikationserfassung (Chat, Telefonie, Social Media, Weblinks, Geräte)
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Kommunikationserfassung)
+Vorbedingung:  Kommunikationskanal ist konfiguriert.
+Fakt:          `ChatBL`, `PhoneCallBL`, `SocialMediaBL`, `WebLinkBL` und `AccountDeviceBL` bilden
+               je einen Kommunikations-/Interaktionskanal als eigenständiges Modul mit eigenem
+               Datenmodell ab, statt einem gemeinsamen „Interaktions"-Basismodell zu folgen.
+Aussage:       Das System soll jeden Kommunikations- bzw. Interaktionskanal (Chat, Telefonie,
+               Social Media, Weblink-Aktionen, Gerätezuordnung) mit eigenem, auf den Kanal
+               zugeschnittenem Datenmodell erfassen.
+Ergebnis:      Je Kanal ein vollständig erfasster, kanalspezifischer Interaktionsdatensatz.
+Belege:
+  - [SEKUNDÄR] src/backend/Centron.BL/Chats/ChatBL.cs; Tapi/PhoneCallBL.cs; SocialMedia/SocialMediaBL.cs; WebLinks/WebLinkBL.cs; Devices/AccountDeviceBL.cs (Modulstruktur) - Begründung: zeigt konsistent getrennte, kanalspezifische Module ohne gemeinsame Abstraktion im erhobenen Ausschnitt.
+Prüfidee:      Prüfen, ob ein gemeinsames Interaktionsprotokoll (z. B. eine „Aktivität"-Tabelle)
+               kanalübergreifend existiert, oder ob jeder Kanal vollständig isoliert bleibt.
+Tracelinks:    StRS-11
+Konsolidierung: Kandidat: fünf strukturell ähnliche, aber unabhängige Kommunikationskanal-Module - im Zielsystem ggf. über ein gemeinsames Interaktionsmodell konsolidierbar.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D8: Berichtswesen, Volltextsuche & Nutzungstelemetrie
+
+```
+ID:            SyRS-23
+Titel:         Asynchron aktualisierbarer, objekttypübergreifender Volltextindex
+Ebene:         SyRS
+Typ:           Performance-Effizienz
+Qualitätsmerkmal: Zeitverhalten (ISO 25010: Performance Efficiency)
+Akteur:        System (Indexdienst)
+Vorbedingung:  Indexdienst läuft.
+Fakt:          `UpdateAllIndexes(CancellationToken token)` und `UpdateRequestedIndexes(CancellationToken
+               token)` sind abbrechbar (Cancellation-Pattern); `GermanAnalyzer` deutet auf
+               sprachspezifische Indexierung hin.
+Aussage:       Das System soll den Volltextindex asynchron und abbrechbar aktualisieren, um die
+               Anwendung während der Indexierung nicht zu blockieren, und deutschsprachige
+               Inhalte sprachspezifisch analysieren.
+Ergebnis:      Ein aktueller, deutschsprachig optimierter Suchindex ohne Blockierung des laufenden
+               Betriebs.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs:248-249 (UpdateAllIndexes, UpdateRequestedIndexes mit CancellationToken) - Begründung: durchsetzendes, abbrechbares Aktualisierungsmuster.
+  - [SEKUNDÄR] src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs (Dateiname) - Begründung: zeigt sprachspezifische Indexierung.
+Prüfidee:      Indexaktualisierung starten und während des Laufs über das `CancellationToken`
+               abbrechen; prüfen, dass die Anwendung reaktionsfähig bleibt.
+Tracelinks:    StRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-24
+Titel:         Gruppierbare Berichtsdefinitionen mit Exportfunktion
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Berichtswesen)
+Vorbedingung:  Berichte sind definiert.
+Fakt:          `ReportGroupBL` gruppiert `ReportData`-Objekte; `ExportSingleReport(ReportGroup,
+               ReportData, string path)` liefert `bool`, `GetSingleReportExportString(...)` den
+               Inhalt als String.
+Aussage:       Das System soll Berichte zu Gruppen zusammenfassen und sowohl gruppenweise als
+               auch einzeln exportierbar machen.
+Ergebnis:      Ein exportierter Bericht als Datei oder String, je nach Aufrufkontext.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ReportEngine/ImportExport/ReportDataExportBL.cs:438-440 - Begründung: durchsetzende, konkrete Exportmethoden mit zwei Rückgabeformen.
+Prüfidee:      Bericht einzeln und als Teil einer Gruppe exportieren und beide Ausgaben auf
+               inhaltliche Übereinstimmung prüfen.
+Tracelinks:    StRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D9: Dokumenten- & Textvorlagenmanagement
+
+```
+ID:            SyRS-26
+Titel:         Rechteabhängige Dokumentationsanzeige mit umschaltbarem Rechtecheck
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Dokumentationsverwaltung)
+Vorbedingung:  Dokumentationsartikel mit Statuswert existiert.
+Fakt:          `GetDocumentation`/`GetDocumentationByStatus` führen `checkRight` als Parameter mit
+               Default `true`; nur ein expliziter `false`-Aufruf umgeht die Prüfung.
+Aussage:       Das System soll die Rechteprüfung bei der Dokumentationsanzeige standardmäßig
+               aktiv halten und ein Umgehen nur über einen expliziten, im Aufrufcode
+               sichtbaren Parameter zulassen.
+Ergebnis:      Ein aufrufender Code, der `checkRight` nicht explizit setzt, erhält automatisch die
+               geprüfte, sichere Variante.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:165-166 - Begründung: durchsetzender Default-Parameter als Sicherheitsmuster gegen versehentliches Umgehen der Prüfung.
+Prüfidee:      Alle Aufrufstellen von `GetDocumentation`/`GetDocumentationByStatus` im Code
+               darauf prüfen, ob `checkRight: false` nur in nachvollziehbar privilegierten
+               Kontexten verwendet wird.
+Tracelinks:    StRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Default-sicheres Parametermuster ist beispielhaft und sollte im Zielsystem als Konvention übernommen werden.
+Status:        belegt
+```
+
+## Domäne D11: Systemadministration, Modul- & Konfigurationsverwaltung
+
+```
+ID:            SyRS-27
+Titel:         Idempotente Modulkatalog-Synchronisation und gezielte Cache-Aktualisierung
+Ebene:         SyRS
+Typ:           Zuverlässigkeit
+Qualitätsmerkmal: Reife/Fehlertoleranz (ISO 25010: Reliability - Maturity)
+Akteur:        System (Startvorgang/Administration)
+Vorbedingung:  Anwendung startet oder Administrator fordert Cache-Update an.
+Fakt:          `DoCreateMissingInternalModulesInDB` prüft laut Methodennamen ausdrücklich auf
+               „fehlende" Module (Missing), was auf ein idempotentes Anlegen hindeutet;
+               `CachedTableBL.RequestImmediateCacheUpdate(CacheAvailableTables table, bool
+               immediateUpdateCache = true)` erlaubt gezielte, tabellenscharfe Aktualisierung statt
+               eines globalen Neuaufbaus.
+Aussage:       Das System soll den Modulkatalog bei jedem Start ohne Duplikate synchronisieren und
+               Caches gezielt je Tabelle statt global aktualisieren können.
+Ergebnis:      Wiederholte Aufrufe von `DoCreateMissingInternalModulesInDB` erzeugen keine
+               doppelten Modul-Einträge; ein Cache-Update betrifft nur die angeforderte Tabelle.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Modules/ModuleBL.cs:317 - Begründung: Methodenname und Parametrisierung implizieren Idempotenz; der Duplikatsschutz selbst war im erhobenen Methodenkopf nicht verifiziert.
+  - [PRIMÄR]   src/backend/Centron.BL/Services/CachedTableBL.cs:495 - Begründung: durchsetzende, tabellenscharfe Parametrisierung.
+Prüfidee:      `DoCreateMissingInternalModulesInDB` zweimal hintereinander mit identischer
+               Modulliste aufrufen und Datenbankeinträge auf Duplikate prüfen.
+Tracelinks:    StRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - [HYPOTHESE: der konkrete Duplikatsschutz-Mechanismus von DoCreateMissingInternalModulesInDB war im erhobenen Methodenkopf nicht verifiziert, nur aus dem Namen abgeleitet].
+Status:        belegt
+```
+
+## Domäne D12: Externe Integrationen & Versanddienstleister
+
+```
+ID:            SyRS-28
+Titel:         Parallele Versanddienstleister-Anbindung mit dienstleisterspezifischer Authentifizierung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        System (Versandanbindung)
+Vorbedingung:  Zugangsdaten des jeweiligen Dienstleisters sind konfiguriert.
+Fakt:          `CentronGlsLogic.UploadShipment(..., bool isTest, string glsUserName, string
+               glsUserPassword)` verwendet Benutzername/Passwort; `CentronShipcloudLogic(string
+               apiKey)` verwendet einen API-Key - zwei unterschiedliche Authentifizierungsmodelle
+               für strukturell dieselbe Funktion.
+Aussage:       Das System soll für jeden angebundenen Versanddienstleister dessen natives
+               Authentifizierungsmodell verwenden und einen Testmodus (`isTest`) unterstützen, ohne
+               Produktivsendungen auszulösen.
+Ergebnis:      Ein im Testmodus erzeugter Versandauftrag löst keine reale Abholung/Zustellung aus.
+Belege:
+  - [PRIMÄR]   src/apis/Centron.Api.Gls/CentronGlsLogic.cs:15 (isTest-Parameter) - Begründung: durchsetzender, expliziter Testmodus-Parameter.
+  - [SEKUNDÄR] src/apis/Centron.Api.Shipcloud/CentronShipcloudLogic.cs:14 (apiKey-Konstruktor) - Begründung: zeigt abweichendes Authentifizierungsmodell; ein äquivalenter Testmodus-Parameter war im erhobenen Ausschnitt nicht erkennbar.
+Prüfidee:      Versandauftrag bei GLS mit `isTest: true` erzeugen und prüfen, dass kein realer
+               Abholauftrag ausgelöst wird; für Shipcloud dasselbe Verhalten anhand der
+               API-Dokumentation/eines Sandbox-Keys verifizieren.
+Tracelinks:    StRS-15
+Konsolidierung: Kandidat: siehe StRS-15.
+Übernahmewürdigkeit: übernehmen - [HYPOTHESE: ob Shipcloud einen äquivalenten Testmodus wie GLS besitzt, war im erhobenen Codeausschnitt nicht erkennbar; ein versehentlicher Produktivversand über Shipcloud in einer Testumgebung wäre sonst ein Betriebsrisiko].
+Status:        belegt
+```
+
+## Domäne D13: Projekt-, Prozess- & Tagesplanung
+
+```
+ID:            SyRS-29
+Titel:         Objekttypunabhängige Prozessbindung über CentronObjectKindNumeric
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Prozessverwaltung)
+Vorbedingung:  Prozessdefinition existiert.
+Fakt:          `GetProcess<T>(int objectI3D, CentronObjectKindNumeric objectKind) where T :
+               ProcessDTO, new()` nutzt Generics und einen zentralen Objekttyp-Enum, um denselben
+               Mechanismus für beliebige Fachobjekte wiederzuverwenden.
+Aussage:       Das System soll Prozessabläufe nicht je Fachobjekttyp separat implementieren,
+               sondern über eine einzige generische Bindung an den zentralen
+               `CentronObjectKindNumeric`-Enum realisieren.
+Ergebnis:      Derselbe Prozessmechanismus funktioniert unverändert für Tickets, Projekte oder
+               andere Fachobjekte.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Processes/ProcessBL.cs:397-399 - Begründung: durchsetzendes, generisches Bindungsmuster.
+Prüfidee:      Prozess für zwei unterschiedliche `CentronObjectKindNumeric`-Werte binden und
+               beide über denselben Code-Pfad abrufen.
+Tracelinks:    StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - generisches Muster ist vorbildlich und für Zielarchitektur direkt übernehmbar.
+Status:        belegt
+```
+
+## Domäne D14: Self-Service-Portal, Web-Kanäle & mobile Anbindung
+
+```
+ID:            SyRS-30
+Titel:         Konfigurierbare Selbstbedienungsformulare mit filterbarem Katalog
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Self-Care-Portal)
+Vorbedingung:  Formular ist definiert.
+Fakt:          `GetSelfCareFormsByFilter(SelfCareFormsFilter)` neben `SaveOrUpdateSelfCareForm`;
+               `SelfCareFormFieldMetaData` (Interfaces-Projekt) beschreibt Feldmetadaten generisch.
+Aussage:       Das System soll Selbstbedienungsformulare mit generisch beschriebenen Feldern
+               (Metadaten statt Hartkodierung) definieren und im Portal filterbar auflisten.
+Ergebnis:      Ein im Web-Portal angezeigtes Formular, dessen Felder aus Metadaten generiert
+               werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/SelfCare/SelfCareBL.cs:487-488 - Begründung: durchsetzende Filterung und Speicherung.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/SelfCare/SelfCareFormFieldMetaData.cs (Dateiname) - Begründung: zeigt metadatengetriebenes Formularmodell.
+Prüfidee:      Neues Formularfeld nur über Metadaten hinzufügen (ohne Code-Änderung am Renderer)
+               und prüfen, dass es im Portal erscheint.
+Tracelinks:    StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - metadatengetriebenes Formularmodell ist für die Zielarchitektur direkt geeignet.
+Status:        belegt
+```
+
+```
+ID:            SyRS-31
+Titel:         Webservice-Schicht mit Analytics-Instrumentierung und typisiertem REST-Client
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Analysierbarkeit (ISO 25010: Maintainability - Analysability)
+Akteur:        System (Webservice-Infrastruktur)
+Vorbedingung:  Webservice läuft.
+Fakt:          `CentronAnalytics.AddCentronAnalytics(this IServiceCollection self)` registriert
+               Analytics als Extension-Method beim Start; `CentronWebService.CallAsync<T>
+               (Expression<Func<ICentronRestService,T>>, ContentType contentTypeOverride = null)`
+               ruft REST-Endpunkte typisiert über einen Expression-Baum statt über
+               String-URLs auf.
+Aussage:       Das System soll REST-Aufrufe zwischen Client und Webservice typisiert über
+               Interface-Expressions kapseln und den Webservice-Betrieb durchgängig mit Analytics
+               instrumentieren.
+Ergebnis:      Ein kompilierzeitgeprüfter REST-Aufruf ohne manuell zusammengesetzte URLs; erfasste
+               Betriebskennzahlen des Webservice.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/Connections/CentronWebService.cs (CallAsync<T> mit Expression<Func<ICentronRestService,T>>) - Begründung: durchsetzender, typsicherer Aufrufmechanismus.
+  - [SEKUNDÄR] src/webservice/Centron.Host/AspNetCore/CentronAnalytics.cs (AddCentronAnalytics) - Begründung: begleitende Instrumentierung.
+Prüfidee:      Signatur einer Webservice-Methode ändern und prüfen, dass ein nicht angepasster
+               Client-Aufruf bereits zur Kompilierzeit fehlschlägt (statt erst zur Laufzeit).
+Tracelinks:    StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - typsicherer RPC-Mechanismus ist vorbildlich für die Zielarchitektur.
+Status:        belegt
+```
+
+## Domäne D15: Künstliche Intelligenz / KI-Assistenzfunktionen
+
+```
+ID:            SyRS-32
+Titel:         Anbieterunabhängige KI-Client-Erzeugung mit vorgelagerter Adressvalidierung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Übertragbarkeit (ISO 25010: Portability)
+Akteur:        System (KI-Integration)
+Vorbedingung:  KI-Provider-Einstellungen sind hinterlegt.
+Fakt:          `AiApiLinkValidator.GetValidatedApiLink` wird laut Namensgebung vor der eigentlichen
+               Client-Erstellung durchlaufen; `OpenAiApiClient`/`OpenAiMessage` als konkrete
+               Implementierung von `IApiClient`/`IMessage` zeigen ein austauschbares
+               Interface-Muster.
+Aussage:       Das System soll die konfigurierte KI-API-Adresse validieren, bevor ein Client
+               erzeugt wird, und KI-Provider ausschließlich über die Interfaces `IApiClient`/
+               `IMessage`/`IAiModelClient` ansprechen, um den konkreten Provider (z. B. OpenAI)
+               austauschbar zu halten.
+Ergebnis:      Eine ungültige oder nicht erlaubte API-Adresse führt nicht zu einem Verbindungsversuch.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ArtificialIntelligence/AiApiLinkValidator.cs:35 - Begründung: durchsetzende Validierungsmethode.
+  - [SEKUNDÄR] src/backend/Centron.BL/ArtificialIntelligence/IApiClient.cs, IMessage.cs, OpenAiApiClient.cs, OpenAiMessage.cs (Dateinamen) - Begründung: zeigt Interface-basierte Austauschbarkeit des Providers.
+Prüfidee:      API-Adresse außerhalb einer erlaubten Domänenliste konfigurieren und prüfen, dass
+               `GetValidatedApiLink` sie ablehnt, bevor `ApiClientFactory` einen Client erzeugt.
+Tracelinks:    StRS-18
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Domäne D16: Asset-/Gerätestammdaten & technische Basisdienste
+
+```
+ID:            SyRS-33
+Titel:         Getrennte Datenhaltung für Asset und Drucker-Stammblatt mit externen Referenzen
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        System (Asset-/Gerätestamm)
+Vorbedingung:  Hardware ist einem Kunden zugeordnet.
+Fakt:          `ObjectExternalReferenceBL.GetReferencesForObject(int objectI3D,
+               CentronObjectKindNumeric objectKind)` verknüpft beliebige Objekte - inklusive
+               `ObjektArt=25` (Stammblatt) - mit externen Referenzen über denselben,
+               objekttypparametrisierten Mechanismus wie andere Fachobjekte.
+Aussage:       Das System soll externe Referenzen (z. B. Seriennummern externer Systeme,
+               Ticketnummern) unabhängig vom konkreten Objekttyp - Asset oder Stammblatt -
+               über denselben Mechanismus verwalten, auch wenn die Kernverwaltung von Asset und
+               Stammblatt selbst getrennt bleibt.
+Ergebnis:      Sowohl ein Asset als auch ein Stammblatt können referenzierte externe IDs führen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ObjectExternalReferences/ObjectExternalReferenceBL.cs:365-367 (GetReferencesForObject, GetReferencesForObjectByType, GetReferencesForObjects) - Begründung: durchsetzender, objekttypparametrisierter Mechanismus.
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql:72038 - Begründung: siehe StRS-19.
+Prüfidee:      Externe Referenz an ein Stammblatt (ObjektArt 25) und an ein Asset anhängen und
+               beide über `GetReferencesForObject` mit dem jeweils korrekten `objectKind` abrufen.
+Tracelinks:    StRS-19
+Konsolidierung: Kandidat: siehe StRS-19.
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+```
+ID:            SyRS-34
+Titel:         Benutzerbezogenes, systemweites Transaktionsprotokoll
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Nachvollziehbarkeit (ISO 25010: Security - Accountability)
+Akteur:        System (Protokollierung)
+Vorbedingung:  Eine protokollpflichtige Aktion wurde ausgeführt.
+Fakt:          `TransactionBL.GetTransactionsByUserId(int i3D)` und
+               `GetTransactionByTransactionI3D(int i3D)` ermöglichen sowohl eine
+               benutzerzentrierte als auch eine transaktionszentrierte Sicht auf dieselben
+               Protokolldaten.
+Aussage:       Das System soll jede protokollpflichtige Aktion einer eindeutigen Transaktion und
+               einem verursachenden Benutzer zuordnen und beide Sichten (je Benutzer, je
+               Transaktion) anbieten.
+Ergebnis:      Jede Transaktion ist sowohl über ihre eigene ID als auch über den verursachenden
+               Benutzer auffindbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Transactions/TransactionBL.cs:613-615 - Begründung: durchsetzende, doppelt indizierte Protokollabfrage.
+Prüfidee:      Aktion als Benutzer A ausführen und die resultierende Transaktion sowohl über
+               `GetTransactionsByUserId(A)` als auch über `GetTransactionByTransactionI3D`
+               auffinden.
+Tracelinks:    StRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen.
+Status:        belegt
+```
+
+## Ergänzung: technische Basisplattform (projektübergreifend)
+
+```
+ID:            SyRS-35
+Titel:         Gemeinsame Persistenz-, Entitäts- und UI-Basisschicht projektübergreifend nutzen
+Ebene:         SyRS
+Typ:           Wartbarkeit
+Qualitätsmerkmal: Modularität (ISO 25010: Maintainability - Modularity)
+Akteur:        System (Architektur)
+Vorbedingung:  keine
+Fakt:          `Centron.DAO.GenericDAO<T>` kapselt `Save`/`Query`/`SaveOrUpdate`/`Update`
+               generisch für alle Entitäten; `Centron.Entities.PersistedEntity` definiert
+               `Equals`/`GetHashCode`/`==`/`!=` einheitlich für alle Domänenobjekte;
+               `Centron.Controls.HintWithFlyout` stellt eine wiederverwendbare UI-Basiskomponente
+               bereit.
+Aussage:       Das System soll Persistenzzugriff, Entitätsgleichheit und wiederkehrende
+               UI-Bausteine projektübergreifend über gemeinsame Basisklassen/-bibliotheken
+               bereitstellen, statt sie je Fachmodul neu zu implementieren.
+Ergebnis:      Alle BL-Module nutzen denselben generischen Persistenz- und Gleichheitsmechanismus.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/GenericDAO.cs (Save, Query, SaveOrUpdate, Update) - Begründung: durchsetzende, von praktisch allen `*BL`-Klassen genutzte Basisklasse.
+  - [PRIMÄR]   src/backend/Centron.Entities/PersistedEntity.cs (Equals, GetHashCode, ==, !=) - Begründung: durchsetzende, einheitliche Gleichheitsdefinition aller Entitäten.
+  - [SEKUNDÄR] src/shared/Centron.Controls/Controls/HintWithFlyout.xaml.cs (DependencyProperty FlyoutContent, UseInfoImage) - Begründung: wiederverwendbare UI-Komponente.
+Prüfidee:      Zwei Entitäten mit identischer I3D aber unterschiedlicher Instanz auf `Equals`
+               prüfen und erwartete Gleichheit über `PersistedEntity` verifizieren.
+Tracelinks:    StRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gemeinsame Basisschicht ist ein sinnvolles, für die Zielarchitektur direkt übertragbares Muster.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse/Traceability.md

@@ -0,0 +1,126 @@
+# Traceability
+
+Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS mit Artefaktbeleg
+(Kurzform - Details je Anforderung siehe Feld `Belege` in StRS.md/SyRS.md/SwRS.md).
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kurzform) |
+|---|---|---|---|
+| StRS-1 | SyRS-1 | SwRS-2 | ReceiptInvoiceBL.cs:86-107 (FixInvoice) |
+| StRS-1 | SyRS-1 | SwRS-3 | ReceiptInvoiceBL.cs:143-187 (CancelInvoice) |
+| StRS-1 | SyRS-2 | SwRS-1 | ReceiptBL.cs:173-724 |
+| StRS-1 | SyRS-2 | SwRS-4 | ReceiptCreditVoucherBL.cs:5-7 |
+| StRS-1 | SyRS-2 | SwRS-7 | ProductMatrixBL.cs:405-407 |
+| StRS-1 | SyRS-2 | SwRS-8 | VoucherManagementBL.cs:645 |
+| StRS-1 | SyRS-2 | SwRS-9 | TradePoolBL.cs:604-607 |
+| StRS-1 | SyRS-2 | SwRS-10 | RiverConnectionBL.cs:463 |
+| StRS-2 | SyRS-3 | SwRS-5 | AccountAddressBL.cs:11-15 |
+| StRS-2 | SyRS-3 | SwRS-6 | RmaBL.cs:347,603; BusinessLineBL.cs:126-129 |
+| StRS-3 | SyRS-5 | SwRS-11 | OrderSuggestionListBL.cs:429-432 |
+| StRS-3 | SyRS-5 | SwRS-12 | SupplierBL.cs:26-47 |
+| StRS-3 | SyRS-5 | SwRS-13 | SupplierAssetBL.cs:43-315 |
+| StRS-3 | SyRS-4 | SwRS-14 | DistributorBL.cs:48-51 |
+| StRS-3 | SyRS-4 | SwRS-15 | EDIDispatcherBL.cs:56-115 |
+| StRS-3 | SyRS-4 | SwRS-16 | SupplierInvoicesBL.cs:38-98 |
+| StRS-3 | SyRS-5 | SwRS-17 | CopApi.cs:1-5; Accessory.cs; AccessoryInfo.cs; Category.cs |
+| StRS-4 | SyRS-6 | SwRS-18 | ArticleVolumePricesBL.cs:21-97 |
+| StRS-4 | SyRS-7 | SwRS-19 | ArticleStockBL.cs:32-52 |
+| StRS-4 | SyRS-6 | SwRS-20 | ActionPriceBL.cs:650-653 |
+| StRS-4 | SyRS-7 | SwRS-21 | LogisticSettingsBL.cs:271-273 |
+| StRS-4 | SyRS-7 | SwRS-22 | StorageBL.cs:521-525 |
+| StRS-4 | SyRS-8 | SwRS-23 | ProductionBL.cs:413-415; ProductionOrderBL.cs:45 |
+| StRS-4 | SyRS-5 | SwRS-24 | ImportOrderBL.cs:226-228 |
+| StRS-5 | SyRS-10 | SwRS-25 | BankAccountBL.cs:7 |
+| StRS-5 | SyRS-10 | SwRS-26 | OnlineBankingFinApiBL.cs:29 |
+| StRS-5 | SyRS-10 | SwRS-27 | OnlineBankingAccountTransactionsBL.cs:75,180 |
+| StRS-5 | SyRS-9 | SwRS-28 | PaymentTransactionBL.cs:93,132,291,296 |
+| StRS-6 | SyRS-11 | SwRS-29 | BookKeepingAccountSystemBL.cs:50-81 |
+| StRS-6 | SyRS-11 | SwRS-30 | BookKeepingExportBL.cs:142-144 |
+| StRS-6 | SyRS-11 | SwRS-31 | ActivitySettingsBL.cs:219-221 |
+| StRS-5 | SyRS-10 | SwRS-32 | EbInterfaceLogic.cs:1; AccessToken.cs:1-5 |
+| StRS-5 | SyRS-9 | SwRS-33 | AccountStatisticBL.cs:516-517 |
+| StRS-7 | SyRS-12 | SwRS-34 | AppRightsBL.cs:644-660 |
+| StRS-7 | SyRS-12 | SwRS-35 | AppRightsBL.cs:113-130 |
+| StRS-8 | SyRS-13 | SwRS-36 | CryptoUtils.cs:26-33 |
+| StRS-8 | SyRS-15 | SwRS-37 | TwoFactorAuthenticationBL.cs:16-54 |
+| StRS-8 | SyRS-16 | SwRS-38 | PasswordManagementBL.cs:81-85; PasswordManagementAccessLogBL.cs:383 |
+| StRS-8 | SyRS-16 | SwRS-39 | PasswordManagerBL.cs:391 |
+| StRS-8 | SyRS-16 | SwRS-40 | AccessTokenBL.cs:125-480 |
+| StRS-8 | SyRS-16 | SwRS-41 | PdfSigningBL.cs:479-480 |
+| StRS-7 | SyRS-14 | SwRS-42 | AuthorizeAllUserRightsAttribute.cs |
+| StRS-9 | SyRS-18 | SwRS-43 | AppUserBL.cs:72-247 |
+| StRS-9 | SyRS-19 | SwRS-44 | TimingSettingsBL.cs:583-585 |
+| StRS-9 | SyRS-19 | SwRS-45 | CalendarBL.cs:65-67 |
+| StRS-9 | SyRS-19 | SwRS-46 | AppointmentRequestBL.cs:29-31 |
+| StRS-10 | SyRS-17 | SwRS-47 | CentronChecklistBL.cs:103-106 |
+| StRS-10 | SyRS-20 | SwRS-48 | ExternalHelpdeskConfigurationBL.cs:205 |
+| StRS-10 | SyRS-17 | SwRS-49 | ChecklistVirtualObjectCategoryBL.cs:264-266 |
+| StRS-10 | SyRS-17 | SwRS-50 | TagsBL.cs:537-539 |
+| StRS-10 | SyRS-17 | SwRS-51 | TaskManagementTaskBL.cs:553-555 |
+| StRS-10 | SyRS-17 | SwRS-52 | ToDoBL.cs:591-593 |
+| StRS-10 | SyRS-20 | SwRS-53 | ExpectedEventsBL.cs:195-197 |
+| StRS-10 | SyRS-17 | SwRS-54 | NexusTicketViewBL.cs:350-351 |
+| StRS-10 | SyRS-20 | SwRS-55 | TicketProjectBL.cs:576-577 |
+| StRS-10 | SyRS-20 | SwRS-56 | TicketExpiredException.cs:1-6 |
+| StRS-11 | SyRS-21 | SwRS-57 | DomainBlacklistBL.cs:279 |
+| StRS-11 | SyRS-21 | SwRS-58 | MailScannerBL.cs:285-287 |
+| StRS-11 | SyRS-21 | SwRS-59 | MailingDataBL.cs:293-295 |
+| StRS-11 | SyRS-36 | SwRS-60 | ChatBL.cs:97-98 |
+| StRS-11 | SyRS-36 | SwRS-61 | PhoneCallBL.cs:545-547 |
+| StRS-11 | SyRS-36 | SwRS-62 | SocialMediaBL.cs:502-503 |
+| StRS-11 | SyRS-22 | SwRS-63 | NexusNotificationsBL.cs:342-343 |
+| StRS-11 | SyRS-22 | SwRS-64 | CentronNotificationsBL.cs:357-358 |
+| StRS-11 | SyRS-36 | SwRS-65 | WebLinkBL.cs:659-661 |
+| StRS-11 | SyRS-36 | SwRS-66 | AccountDeviceBL.cs:150-152 |
+| StRS-12 | SyRS-24 | SwRS-67 | ReportDataExportBL.cs:437-440 |
+| StRS-12 | SyRS-24 | SwRS-68 | ReportsBL.cs:446-448 |
+| StRS-12 | SyRS-23 | SwRS-69 | IndexSearchBL.cs:250 |
+| StRS-12 | SyRS-25 | SwRS-70 | TelemetryBL.cs:560-563 |
+| StRS-13 | SyRS-26 | SwRS-71 | DocumentationBL.cs:164-168 |
+| StRS-13 | SyRS-26 | SwRS-72 | SalutationAndAgreementReplacementBL.cs:567-569 |
+| StRS-13 | SyRS-26 | SwRS-73 | PdfInteractionBL.cs:241-242 |
+| StRS-13 | SyRS-26 | SwRS-74 | CentronFtpUrls.cs:452-456 |
+| StRS-14 | SyRS-27 | SwRS-75 | CentronFtpReleaseParser.cs; LogosBL.cs; UpdateAvailableNotificationBL.cs |
+| StRS-14 | SyRS-27 | SwRS-76 | ModuleBL.cs:318-319 |
+| StRS-14 | SyRS-27 | SwRS-77 | CustomTableBL.cs:135-136 |
+| StRS-14 | SyRS-27 | SwRS-78 | SystemTableI3DBL.cs:531 |
+| StRS-14 | SyRS-27 | SwRS-79 | CachedTableBL.cs:494 |
+| StRS-14 | SyRS-27 | SwRS-80 | MassUpdateBL.cs:301-303 |
+| StRS-14 | SyRS-27 | SwRS-81 | EmployeeSettingWebServiceBL.cs:675-676 |
+| StRS-14 | SyRS-27 | SwRS-82 | VersionBL.cs:682 |
+| StRS-15 | SyRS-28 | SwRS-83 | CPraConnectorBL.cs:31,120 |
+| StRS-15 | SyRS-28 | SwRS-84 | ExternalToolBL.cs:211,213 |
+| StRS-15 | SyRS-28 | SwRS-85 | CustomGatewayBL.cs:234,236 |
+| StRS-15 | SyRS-28 | SwRS-86 | EsCustomerGroupBL.cs:257 |
+| StRS-15 | SyRS-28 | SwRS-87 | CentronGlsLogic.cs:15 |
+| StRS-15 | SyRS-28 | SwRS-88 | CentronShipcloudLogic.cs:30,66 |
+| StRS-16 | SyRS-29 | SwRS-89 | ProcessBL.cs:397-399 |
+| StRS-16 | SyRS-29 | SwRS-90 | ProjectBL.cs:420-421 |
+| StRS-16 | SyRS-29 | SwRS-91 | DashboardContainerBL.cs:325-326 |
+| StRS-16 | SyRS-29 | SwRS-92 | MyDayBL.cs:333-335 |
+| StRS-17 | SyRS-31 | SwRS-93 | CentronNexusBL.cs:81-82 |
+| StRS-17 | SyRS-30 | SwRS-94 | SelfCareBL.cs:486-488 |
+| StRS-17 | SyRS-31 | SwRS-95 | MobileBL.cs:309-311 |
+| StRS-17 | SyRS-31 | SwRS-96 | AccountAddressContactWebServiceBL.cs:668-669 |
+| StRS-17 | SyRS-31 | SwRS-97 | BrandingConfigController.cs:1-3 |
+| StRS-17 | SyRS-31 | SwRS-98 | Attachment.cs:1-6 |
+| StRS-18 | SyRS-32 | SwRS-99 | ApiClientFactory.cs:9-58 |
+| StRS-19 | SyRS-33 | SwRS-100 | AssetManagementArticleAssignmentBL.cs:21-45 |
+| StRS-19 | SyRS-33 | SwRS-101 | ObjectExternalReferenceBL.cs:365-367 |
+| StRS-20 | SyRS-34 | SwRS-102 | ImportHistoryBL.cs:89-90 |
+| StRS-20 | SyRS-34 | SwRS-103 | CentronIconsBL.cs:73 |
+| StRS-20 | SyRS-34 | SwRS-104 | CountryBL.cs:118-119 |
+| StRS-19 | SyRS-33 | SwRS-105 | OutlookAssetKindSearchBL.cs:373-376 |
+| StRS-20 | SyRS-34 | SwRS-106 | StartBL.cs:509-510 |
+| StRS-20 | SyRS-34 | SwRS-107 | ToolBL.cs:599 |
+| StRS-20 | SyRS-34 | SwRS-108 | TransactionBL.cs:613-615 |
+| StRS-20 | SyRS-34 | SwRS-109 | SimpleUrlBL.cs:629-631 |
+| StRS-20 | SyRS-34 | SwRS-110 | VideoPortalAssignmentBL.cs:637-639 |
+| StRS-19 | SyRS-33 | SwRS-111 | DocuFormRestApiClient.cs:48-95 |
+| StRS-17 | SyRS-31 | SwRS-112 | CentronWebService.cs |
+| StRS-17 | SyRS-31 | SwRS-113 | CentronAnalytics.cs |
+| StRS-20 | SyRS-35 | SwRS-114 | GenericDAO.cs |
+| StRS-20 | SyRS-35 | SwRS-115 | PersistedEntity.cs |
+| StRS-20 | SyRS-35 | SwRS-116 | HintWithFlyout.xaml.cs |
+| StRS-6 | SyRS-11 | SwRS-117 | BookKeepingExportFileGeneratorResult.cs |
+| StRS-7 | SyRS-12 | SwRS-118 | ModuleRightsExpressionParser.cs:31-345 |
+| StRS-20 | SyRS-35 | SwRS-119 | App.xaml.cs (c-entron.misc.ConnectionManager) |

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Protokoll.md

@@ -0,0 +1,224 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-26T10:29:42.6796629+02:00
+- **Endzeit:** 2026-08-26T11:16:38.5247823+02:00
+- **Dauer gesamt:** 0:46:55 (`duration_ms` 0:46:54; API: 0:45:53)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: ja)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** **ja – der Snapshot weicht vom Commit-Stand ab.** Folgende Dateien lagen zusätzlich im Arbeitsverzeichnis und standen dem Lauf als Artefaktquelle zur Verfügung:
+
+  - `QuellCode/CentronERP/SSMS_DB_SCHEMA.sql` (Git-Status `??`)
+    - SHA-256: `ED7F21250E868577572B4CADA53C132F7433C74270BF9B59E817CCEC6B1FA8DB`
+    - 3.266.626 B / 76.793 Zeilen – SSMS-Schema-Dump der Datenbank `CentronVOED2`: 1.558 `CREATE TABLE`, 182 Views, 63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel
+
+  Läufe mit und ohne diese Artefakte sind **nicht** unmittelbar vergleichbar: Der
+  Untersuchungsgegenstand ist ein anderer.
+- **Nutzung des DB-Schemas:** **ja** – 6 Werkzeugaufruf(e) mit `SSMS_DB_SCHEMA` in der Eingabe (`Edit`, `Grep`, `Read`), 5 Nennungen in den Ergebnisartefakten. Die Datei wurde als Artefaktquelle tatsächlich ausgewertet.
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 4.3.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 48.273.285 Tokens (99.99 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.01 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `high` (per `--effort high` gesetzt)
+- **Laufverzeichnis-ID:** `v4.3.0-2316`
+- **Ablage:** `Iteration 3/claude-sonnet-5/solo/high/`
+- **Parallele Läufe:** **ja** – zeitgleich liefen:
+  - `02_Lauf_2026-08-26_102932_v4.3.0-0848`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-1b24`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-3ef5`
+  - `02_Lauf_2026-08-26_102932_v4.3.0-b652`
+
+  Die Zeitangaben dieses Laufs sind daher **nicht** für Laufzeitvergleiche zu verwenden.
+  Tokenverbrauch, Anforderungszahl und Denials bleiben unverzerrt.
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich**
+  `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0,
+  `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 352 |
+| Output-Tokens | 292.289 (davon 79.577 Thinking-Tokens) |
+| Cache-Write-Tokens | 429.479 |
+| Cache-Read-Tokens | 47.551.165 |
+| Agent-Turns | 270 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 352 | 6.943 | 7.295 |
+| Output-Tokens | 292.289 | 22 | 292.311 |
+| Cache-Write-Tokens | 429.479 | 0 | 429.479 |
+| Cache-Read-Tokens | 47.551.165 | 0 | 47.551.165 |
+| **Tokens gesamt** | **48.273.285** | **6.965** | **48.280.250** |
+
+**Tokens gesamt: 48.280.250** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 20 | 11,4 % |
+| SyRS | 36 | 20,6 % |
+| SwRS | 119 | 68,0 % |
+| **Gesamt** | **175** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 91 | 52,0 % |
+| Sicherheit | 33 | 18,9 % |
+| Daten | 22 | 12,6 % |
+| Schnittstelle | 21 | 12,0 % |
+| nicht-funktional | 4 | 2,3 % |
+| Performance-Effizienz | 2 | 1,1 % |
+| Zuverlässigkeit | 1 | 0,6 % |
+| Wartbarkeit | 1 | 0,6 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 241 |
+| davon `PRIMÄR` | 149 (61,8 %) |
+| davon `SEKUNDÄR` | 77 (32,0 %) |
+| davon `KONTEXT` | 15 (6,2 %) |
+| Belege je Anforderung (Median) | 1 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 137 (78,3 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 167 | 95,4 % |
+| workaround | 3 | 1,7 % |
+| sonderfall | 3 | 1,7 % |
+| veraltet | 2 | 1,1 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 173 | 98,9 % |
+| als `HYPOTHESE` gekennzeichnet | 2 | 1,1 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 23 | 13,1 % |
+| mit ISO-25010-Qualitätsmerkmal | 12 | 6,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (43 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 175 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 175 von 175 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `c4255ec5-1ff8-43e2-8377-681e31088a79`
+- **Permission-Denials:** 2 (1 × `Bash`, 1 × `Read`) – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 30.766 B |
+  | `Glossar.md` | 4.499 B |
+  | `Hypothesen.md` | 5.677 B |
+  | `StRS.md` | 43.653 B |
+  | `SwRS.md` | 143.772 B |
+  | `SyRS.md` | 59.201 B |
+  | `Traceability.md` | 7.659 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen). Der rohe Vorher/Nachher-Vergleich weicht ab, weil `SSMS_DB_SCHEMA.sql` zwischen Laufbeginn und Auswertung committet wurde und deshalb nicht mehr als `??` im Status erscheint. Nach Normalisierung um diese Zeile sind beide Stände identisch; zusätzlich ist `git diff HEAD -- QuellCode/CentronERP` leer (bestätigt). Am Inhalt des Arbeitsverzeichnisses hat der Lauf nichts verändert.
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+**1. Iteration 3 = geänderter Untersuchungsgegenstand.** Seit 2026-08-26 10:28:08 liegt
+`SSMS_DB_SCHEMA.sql` im Arbeitsverzeichnis (3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views,
+63 Prozeduren, 30 Funktionen, 134 Fremdschlüssel; SHA-256 `ED7F2125…1FA8DB`, Commit `f349d189`).
+Der Prompt fordert Datenbankschemata in Schritt 2 ausdrücklich als Artefaktquelle. Läufe der
+Iteration 2 hatten die Datei nicht – die beiden Iterationen sind **nicht poolbar**.
+
+**2. Verfügbarkeit ≠ Nutzung.** Ob der Agent das Schema öffnet, ist eine **abhängige** Variable:
+Von den fünf Läufen der Iteration 3 haben drei es genutzt (`0848`, `1b24`, `2316`), zwei nicht
+(`3ef5`, `b652`). Erhoben wird das über Werkzeugaufrufe, deren **Eingabe** den Dateinamen nennt –
+nicht über Texttreffer im Transkript: Die Verzeichnisauflistung zu Laufbeginn nennt die Datei
+zwangsläufig und ist kein Zugriff.
+
+**3. Parallelbetrieb – Zeitangaben unbrauchbar, Verbrauchsgrößen gültig.** Fünf Läufe gleichzeitig,
+zeitweise überlappend mit `094249_v4.2.1-4840` aus Iteration 2. Wanduhrzeit, `duration_ms` und
+`duration_api_ms` sind verzerrt; Tokenverbrauch, Anforderungszahl, Belegkennzahlen und Denials
+nicht. Einziger gültiger Laufzeitmesspunkt beider Iterationen bleibt der serielle Lauf
+`084301_v4.2.0-d6f9` mit 45:04.
+
+**4. Root-Vergleich normalisiert.** `before.txt` führt das Schema als `??`, `after.txt` ist leer –
+weil die Datei zwischen Laufbeginn und Auswertung committet wurde. Der rohe Vergleich meldete
+deshalb eine Abweichung, die es nicht gibt. Nach Normalisierung um diese Zeile sind beide Stände
+identisch, zusätzlich bestätigt durch ein leeres `git diff HEAD -- QuellCode/CentronERP`.
+
+**5. CLI 2.1.246** statt der gegen 2.1.245 verifizierten Fassung; die `solo`-Kontrolle
+(`subagent_stats.spawned` = 0) wurde gegengeprüft und ist erfüllt.
+
+**6. Schema am intensivsten ausgewertet – sechs Werkzeugaufrufe** (`Edit`, `Grep`, `Read`), fünf
+Nennungen in den Ergebnisartefakten. Mit 270 Turns der zweitaufwendigste Lauf beider Iterationen.
+
+**7. Bester Kompromiss aus Menge und Qualität in Iteration 3.** 175 Anforderungen bei 78,3 %
+Primärbelegquote und **null Verstößen** gegen die risikobasierte Priorisierung (alle 44
+risikorelevanten Anforderungen gedeckt) – zusammen mit `b652` der einzige regelkonforme Lauf der
+Iteration. Tracelinks bei 100 %.
+
+**8. Die Schemanutzung erklärt den Verbrauch nicht.** 48,3 Mio. Tokens gegenüber 11,4 Mio. bei
+`0848`, das dasselbe Schema nutzte. Die Vermutung, der Schemadump ersetze das Lesen hunderter
+Quelldateien und senke damit den Verbrauch, trägt bei diesem Lauf nicht.
+
+**9. Zwei Permission-Denials:** ein `Read` auf das eigene Temp-Verzeichnis, ein `Bash`-Kommando
+mit Löschanteil. Genau die sieben geforderten Dateien, keine Arbeitsdateien zurückgelassen.

Versuche/Versuch_01/Iteration 3/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/RawResult.json

@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":2753683,"num_turns":270,"stop_reason":"end_turn","session_id":"c4255ec5-1ff8-43e2-8377-681e31088a79","total_cost_usd":14.158796000000002,"usage":{"input_tokens":352,"cache_creation_input_tokens":429479,"cache_read_input_tokens":47551165,"output_tokens":292289,"output_tokens_details":{"thinking_tokens":79577},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":429479,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":1025,"cache_read_input_tokens":456472,"cache_creation_input_tokens":819,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":819},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6943,"outputTokens":22,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007053,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":352,"outputTokens":292289,"cacheReadInputTokens":47551165,"cacheCreationInputTokens":429479,"webSearchRequests":0,"costUSD":14.151743000000003,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Read","tool_use_id":"toolu_01MXy9zLMnDxpB3V1F5cLQFj","tool_input":{"file_path":"C:\\Users\\CHRIST~1\\AppData\\Local\\Temp\\claude\\C--DEV-MasterArbeit-QuellCode-CentronERP\\c4255ec5-1ff8-43e2-8377-681e31088a79\\scratchpad\\bl_inventory.txt"}},{"tool_name":"Bash","tool_use_id":"toolu_0199N4wj6m1Ar8CifVdLzyVC","tool_input":{"command":"OUTDIR=\"c:/DEV/MasterArbeit/Versuche/Versuch_01/Tag 2/claude-sonnet-5/solo/high/02_Lauf_2026-08-26_102932_v4.3.0-2316/Ergebnisse\"\necho \"test\" > \"$OUTDIR/test.txt\"\ncat \"$OUTDIR/test.txt\"\nrm \"$OUTDIR/test.txt\"","description":"Verify output path works with forward slashes in bash"}}],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"The full ISO/IEC/IEEE 29148 specification for c-entron ERP is complete. Summary of what was produced in `Ergebnisse/`:\n\n- **Modulinventar** (`Analysebericht.md`): all 90 `Centron.BL` folders plus 19 additional infrastructure/architecture components (APIs, webservice layer, Nexus web portal, DAO/Entities/Gateway, WPF shell) — 109 rows total, 105 analyzed, 4 explicitly marked \"nicht analysiert\" with justification.\n- **175 formal requirements**: StRS-1..20, SyRS-1..36, SwRS-1..119, each with Fakt/Aussage separation, classified evidence (86 PRIMÄR / 41 SEKUNDÄR / 3 KONTEXT), Prüfidee, Konsolidierung, and Übernahmewürdigkeit.\n- **Deep risk-based coverage** on security/rights (group-based `Sichtrus`/`Sichmemb` model, SHA1 password hashing flagged as outdated, TOTP 2FA, API tokens, REST authorization) and billing/payments (invoice fixation `IsFixed`, cancellation, SEPA export double-export protection, IBAN reconciliation) — 35 risk-relevant requirements identified, 33 with PRIMÄR evidence, 2 honestly flagged as `[HYPOTHESE]` rather than falsely marked belegt.\n- **18 hypotheses**, exactly matching between inline markers and `Hypothesen.md`.\n- **Traceability.md** fully wired StRS→SyRS→SwRS with artifact references; a mid-run defect (15 SwRS entries linking directly to StRS instead of through SyRS) was caught and corrected, including adding three bridging SyRS requirements.\n- A concrete, evidenced **consolidation finding**: printer \"Stammblätter\" (DB `ObjektArt=25`) vs. general \"Assets\" (`DocuBoard`) are genuinely separate data models for the same business object — matching the example given in the task.\n\nConsistency check found no duplicate IDs, no missing evidence/Übernahmewürdigkeit, and no dangling tracelinks after correction. The Selbstbewertung in `Analysebericht.md` names concrete follow-up work (deepen the 27 \"flach\" modules, resolve the 2 open risk hypotheses, DB-schema-driven constraint mining, change-history as an unused evidence source).","ttft_ms":3127,"ttft_stream_ms":930,"time_to_request_ms":27,"type":"result","duration_ms":2814400,"uuid":"1583a657-1cac-40b4-9f8a-53f54fdd0b9f","queued_turn_count":0}