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.
+```