TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

Sechs Zellen - z-ai/glm-5.3-flash und qwen/qwen3.8-flash-next je solo,
builtin und custom - alle mit dem kompletten Artefaktsatz von sieben
Dateien. 47,1 Mio. Tokens in 6,4 Stunden, hochgerechnet rund $3,25.

Das Matrixskript heisst jetzt _matrix.ps1 und nimmt -Provider und
-Effort; die LM-Studio-Ladeparameter werden nur noch lokal uebergeben.
Vor dem Start bestaetigte ein Smoke-Test den TensorX-Pfad unter den
seither geaenderten Bedingungen (Denylist, Spiegel, Freigabemuster):
Anmeldung, Modellkontrolle, wirksame Effort-Variante und Dateiuebernahme.

Befund: Die Anforderungsanzahl haette in die Irre gefuehrt. Qwens
custom-Lauf liegt mit 157 Anforderungen im Mittelfeld, ist aber
qualitativ zusammengebrochen - 61 Prozent ohne jeden Beleg, 17 Prozent
mit Primaerbeleg, 40 Prozent Hypothesen, gegenueber 0 Prozent ohne Beleg
und 79 bis 98 Prozent Primaerbelegen in den uebrigen fuenf Laeufen. Er
lieferte zugleich weniger als builtin bei 37 Prozent mehr Tokens.

Der Moduseffekt ist modellabhaengig: Bei GLM steigt der Ertrag monoton
von 126 ueber 139 auf 216 bei durchgaengig hoher Belegqualitaet, bei Qwen
ist builtin das Optimum. Die Annahme, rollenspezialisierte Agenten seien
generell ueberlegen, traegt damit nicht.

Qwens custom-Lauf meldet exit_code 1 bei finish_reason stop und ohne
Timeout, nachdem alle 24 Subagenten zurueckkamen und sieben Dateien
entstanden. Er ist als gueltig mit Vorbehalt gefuehrt, die Ursache offen.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-02T10:51:56.684623+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse)
+[2026-09-02T10:51:56.851524+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T11:11:00.336010+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T11:11:01.630042+00:00] OpenCode export: Exporting session: ses_f9e40b88cffesSzknb1eFPiSFP
+[2026-09-02T11:11:01.680205+00:00] Ende: Exitcode=0; Status=success; Turns=93; Tokens=6432032; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Analysebericht.md

@@ -0,0 +1,160 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (statische Analyse, keine Programmausführung).
+Umfang des Arbeitsverzeichnisses: ~16.800 C#/XAML-Quelldateien, `SSMS_DB_SCHEMA.sql` mit 1.558 Tabellen-Definitionen, zusätzlich Konfigurations-, Deployment- und Dokumentationsartefakte.
+
+---
+
+## 1. Modulinventar (Schritt 0) und Abdeckungstabelle
+
+Das Inventar wurde vor der ersten Anforderung aus der Verzeichnisstruktur des Arbeitsverzeichnisses erhoben (Schritt 0) und ist Bezugsgröße der Abdeckung. Fachlich zusammengehörige Unterordner sind zu einem Modul zusammengefasst; die Spalte „Anforderungen“ verknüpft jede Zeile mit mindestens einer Requirement-ID (Schritt 0b). Einstufung: `tief` = Quellcode/Schema der durchsetzenden Stelle gelesen; `mittel` = Teile des Codes/Schema gelesen; `flach` = Belege überwiegend Dateinamen-/Ordner Ebene (SEKUNDÄR), Anforderung bewusst schmal gehalten.
+
+| # | Modul / Komponente | Pfad | Fachliche Aufgabe (ein Satz) | Einstufung | Anforderungen |
+|---|---|---|---|---|---|
+| 1 | Build- und Versionskonfiguration | `Centron.sln`, `Directory.Build.props`, `global.json`, `version.json`, `nuget.config` | Einheitliche Build-/, .NET- und Versionsverwaltung über alle Projekte. | flach | SwRS-34, SyRS-29 |
+| 2 | Datenbankschema | `SSMS_DB_SCHEMA.sql` | Vollständige DDL-Abbildung der MSSQL-Datenbank inkl. Indizes und Versionstabellen. | tief | SwRS-1..6, SwRS-11, SwRS-12, SwRS-32, SyRS-23, SyRS-27 |
+| 3 | Rechte-Dokumentation | `CentronRights.md` | Fachbeschreibung der Helpdesk-/Kalender-/Auslastungsrechte inkl. einschränkender Rechte. | tief | StRS-3, StRS-9, SyRS-4, SyRS-14, SwRS-13 |
+| 4 | Projekt-Dokumentation | `README.md`, `docs/` | Architektur- und Feature-Doku (WebCart, Helpdesk-Templates, Sync-Bugprotokoll). | mittel | StRS-8, SyRS-15, StRS-3 |
+| 5 | CI/CD-Pipelines | `azure/`, `azure-blazor/`, `.github/` | Build-, Test-, Regression-, Playwright- und Security-Pipelines. | flach | SyRS-29 |
+| 6 | Testinfrastruktur | `tests/` (Unit, Integration, EndToEnd, Playwright, Nexus) | Automatisierte Prüfung der Backend-, API- und Web-Ebene. | flach | SyRS-29 |
+| 7 | Drittbinaries/-pakete | `assemblies/`, `nugets/` | Vorhaltungen von 7-PDF, Outlook-PIAs, TAPI-, WPF-Bibliotheken. | nicht analysiert | – (Binärartefakte ohne Quellcode; fachliche Relevanz nur aus Ordnernamen erschließbar, als Beleg nicht verwertbar) |
+| 8 | Bau-/Umgebungsskripte | `scripts/` | Umgebungs-/Pfad-/Dependency-Helfer für Build und Betrieb. | nicht analysiert | – (reine Infrastruktur-Hilfsskripte ohne Fachlogik; nur Dateiauflistung erfolgt) |
+| 9 | Versand-APIs | `src/apis/Centron.Api.Gls`, `src/apis/Centron.Api.Shipcloud` | Versandanmeldung/Label bei Speditionsdienstleistern. | flach | SyRS-10 |
+| 10 | ebInterface-API | `src/apis/Centron.Api.EbInterface` | Erzeugung österreichischer E-Rechnungen (Schema 4.3). | mittel | StRS-6, SyRS-9, SwRS-22 |
+| 11 | Lieferanten-Datenzugriff | `src/apis/Centron.APIs.CopDataAccess`, `EgisDataAccess` | SOAP-/Template-basierter Lieferantenabruf (comLine, EGIS). | flach | SyRS-11 |
+| 12 | Bank-API | `src/apis/Centron.APIs.FinAPI` | REST-Zugang zum Onlinebanking-Dienstleister FinAPI. | flach | SyRS-13 |
+| 13 | Produktdaten-APIs | `src/apis/Centron.APIs.IcecatDataAccess`, `ITscopeDataAccess` | Produktstammdaten-/Vergleichsquellen für Artikelanreicherung. | flach | SyRS-12, StRS-13 |
+| 14 | docuFORM-Signatur-API | `Centron.Api.docuFORM/` | REST-Client für den elektronischen Signaturdienst docuFORM. | flach | StRS-15, SyRS-20 |
+| 15 | Beleg-/Fakturierungslogik | `src/backend/Centron.BL/Sales/Receipts/` | Anlage, Prüfung, Preise, Limit, Druck von Angebot bis Gutschrift. | tief | StRS-2, SyRS-7, SyRS-8, SyRS-30, SwRS-17..20 |
+| 16 | Helpdesk/Support | `src/backend/Centron.BL/Sales/Support/`, `BL/CheckListArea`, `BL/TaskManager`, `WPF/Modules/Helpdesk` | Ticketbearbeitung, Status, Zeiten, Checklisten, Historie. | mittel | StRS-3, SwRS-10, SyRS-14, SyRS-19 |
+| 17 | Kunden-/Vertriebsdaten | `src/backend/Centron.BL/Sales/Customers`, `Sales/CustomerAssets`, `Marketing`, `HourlySurchargeRates` | Kundenbezug der Belege, Kunden-Hardware, Markt- und Zuschlagsdaten. | flach | StRS-5, StRS-8 |
+| 18 | Adressstamm | `src/backend/Centron.BL/Accounts/` | Adresse/Anrede/Kostenstellen/Filialzuordnung von Kunden und Lieferanten. | mittel | StRS-1, SwRS-32 |
+| 19 | Zahlungsverkehr/Kasse/Bank | `src/backend/Centron.BL/Accounting/`, `Sales/CashBooks/`, `Finances/Payments`, `Finances/IncomingPayments`, `Finances/OnlineBanking`, `WPF/Modules/OnlineBanking`, `Modules/Finances/Payments|Opos` | Konten, Zahlungsein-/ausgänge, offene Posten, Banking-Kanäle. | mittel | StRS-6, SyRS-13, SwRS-3 |
+| 20 | Vertrags-/Abo-Abrechnung + Mahnwesen UI | `src/centron/Centron.WPF.UI/Modules/Finances` (AutomatedBilling, FlatrateBilling, TimerBilling, ContractEvaluation2/Old, Dunning, Campaigns, Contracts), `BL/VoucherManagement` | Wiederkehrende Abrechnung, Mahnläufe, Verträge, Gutscheine. | tief | StRS-7, StRS-6, SwRS-5, SwRS-31 |
+| 21 | Login/Administration | `src/backend/Centron.BL/Administration/Logins`, `Rights`, `WPF/Modules/Administration` | Authentifizierung, Benutzerverwaltung, Konfiguration. | tief | SyRS-2, SwRS-14, StRS-9 |
+| 22 | Kalender/Terminanfragen | `src/backend/Centron.BL/Calendar/`, `AppointmentRequests/`, `WPF/Modules/Calendar` | Terminplanung und Terminanfragen. | flach | StRS-10 |
+| 23 | Künstliche Intelligenz | `src/backend/Centron.BL/ArtificialIntelligence/` | KI-Unterstützung (u. a. Ticketkategorien, Chat in AutomatedBilling). | nicht analysiert | – (nur Dateinamen `TicketCategoryApiClient.cs`, `AutomatedBillingView.ArtificialIntelligence.cs` gesichtet; Aussagequalität für belastbare Requirement nicht erreichbar, keine Halluzination) |
+| 24 | Kernverschlüsselung | `src/backend/Centron.BL/Core/` | Passwort-Hashing/Salt, Ersetzungslogik. | tief | SyRS-6, SwRS-16 |
+| 25 | Länder-/Währungsdaten | `src/backend/Centron.BL/CountryArea/` | Länder, Standardland, Währungssymbole. | flach | SwRS-3 |
+| 26 | CPra-Konnektor | `src/backend/Centron.BL/CPra/` | Webhook-basierter Konnektor (Bedeutung der Abkürzung unbekannt). | nicht analysiert | – (nur `CPraConnectorBL`/`WebhookResponse`-Gerüst gesehen; fachliche Semantik nicht belegbar) |
+| 27 | Kundenportal-Daten/SelfCare | `src/backend/Centron.BL/CustomerArea/`, `SelfCare/`, `Controllers/SelfCare`, `Nexus/WebCart/CustomerPortal*` | Selfcare-Formulare und Kundenportal-Inhalte. | flach | StRS-8, SyRS-15 |
+| 28 | Geräte-/Assetverwaltung | `src/backend/Centron.BL/Devices/`, `Sales/CustomerAssets`, Schema `AssetManagementDevices` | Kunden-Hardware/Bestandsgeräte. | flach | StRS-5 |
+| 29 | Dokumentenablage | `src/backend/Centron.BL/Storage/`, `DocuBoard/`, `DocumentationArea/`, `WPF/CentronFileSystem` | Dateiablage mit Objektbindung. | flach | StRS-15 |
+| 30 | E-Rechnung/EDI-Export | `src/backend/Centron.BL/EDI/`, `DataExchange/EDI/` (Zugferd), `Gateway/ZUGFeRD21_Extended` | ZUGFeRD/XRechnung/Import. | mittel | StRS-6, SyRS-9, SwRS-21 |
+| 31 | Mitarbeiterdaten | `src/backend/Centron.BL/EmployeeArea/` | AppUser/Mitarbeiter-Stammdaten inkl. 2FA-Schlüsselablage. | flach | StRS-9, SwRS-15 |
+| 32 | Benachrichtigungen | `src/backend/Centron.BL/Notifications/`, `NexusNotifications/`, `ExpectedEvents/` | Ereignisbenachrichtigung an Clients. | flach | SyRS-16 |
+| 33 | Fremd-Integrationen | `BL/ExternalHelpdesk/`, `ExternalToolsBL/`, `Integrations/` (DocBee, RMM), `Controllers/Integrations/` | Anbindung Fremdsysteme an Tickets/Infrastruktur. | flach | SyRS-19, SyRS-20 |
+| 34 | EDI-Gateway | `src/backend/Centron.Gateway/` (Concerto, EDI_Alltron/Also/AlsoCH/EGIS/Herweck/Komsa, OpenTrans, Import/Export, MspCollector) | Kapselung aller Lieferanten-Nachrichtenformate. | mittel | StRS-4, SyRS-11, SwRS-23 |
+| 35 | BL-Infrastruktur | `BL/Modules`, `Helpers`, `GUI`, `Start`, `Tools`, `Exceptions`, `Processes`, `Services`, `SystemArea`, `WebServices`, `WebVersion` | Querschnittsdienste, Result-Muster, Session-Infrastruktur. | mittel | SwRS-8, SwRS-9, SyRS-1 |
+| 36 | Volltextsuche | `src/backend/Centron.BL/IndexSearch/` | Indexaufbau/-suche inkl. deutscher Sprachanalyse. | mittel | SyRS-17, SwRS-29 |
+| 37 | E-Mail/Kommunikation | `BL/Mail`, `Mailings`, `MailScanner`, `Outlook`, `Nexus.OutlookAddIn`, `docker/c-entron-mailcatcher` | Mail-Workflows, Mailscanner-Profile, Outlook-Anbindung. | mittel | StRS-10, SyRS-19 |
+| 38 | Massenupdates | `BL/MassUpdate/`, `WPF/Modules/Massenupdates` | Serienänderungen an Fachobjekten. | flach | SwRS-35 |
+| 39 | Mobiler Zugriff | `BL/Mobile/`, `DAO/Mobile/` | Eigene Daten-/Logikschicht für mobile Clients. | flach | StRS-11 |
+| 40 | Zusammenarbeit/Kollaboration | `BL/MyCentron`, `MyDay`, `ToDoArea`, `Tags`, `Chats`, `SocialMedia`, `VideoPortal`, `WPF/Modules/Dashboard|MyCentron|Survey` | Tagesplanung, Aufgaben, Tags, Chat, Umfragen. | flach | StRS-10 |
+| 41 | Telefonie | `BL/Tapi/`, `Controls/Telephony`, `WPF/Modules/TelekomDive`, `assemblies/tapi`, `TapiClientHub` | Click-to-Dial/Anrufereignisse (TAPI + TelekomDive). | flach | SyRS-21 |
+| 42 | Projekte/Fertigung/Planung | `BL/Projects`, `TicketProjects`, `Production`, `ProductMatrix`, `ItPlanner`, `WPF/Modules/ProjectManagement|Production|QM|Rma|PLM|ProjectPriceImport`, `Nexus/ProductionOrderManagement` | Projekte, Fertigungsaufträge, Qualität, Instandsetzung, IT-Planung. | flach | StRS-11, StRS-12 |
+| 43 | Einkauf/Logistik/Handel | `BL/Purchasing`, `TradePool`, `WPF/Modules/Purchasing|Logistic|Warehousing` | Bestellungen je Filiale, Gebrauchtwaren-Import, Lagerlogistik. | flach | StRS-4, SwRS-12 |
+| 44 | Berichtswesen | `BL/ReportEngine`, `Reporting`, `DAO/Statistics`, `WPF/Modules/Reports|Statistics`, `Controllers/Statistics` | Reports, Druck, Statistiken, Nexoware-Kennzahlen. | mittel | StRS-12, SyRS-18 |
+| 45 | PDF-Signatur (intern) | `src/backend/Centron.BL/Security/` | PDF-Signaturverarbeitung. | mittel | StRS-15, SyRS-20 |
+| 46 | Passwort-/2FA-Verwaltung | `BL/PasswordManager`, `PasswordManagementArea`, `TwoFactorAuthenticator`, `Core/GoogleAuthenticator|TotpAuth` | TOTP-Schlüsselverwaltung und -prüfung. | tief | StRS-9, SyRS-5, SwRS-15 |
+| 47 | Textbausteine/Vorlagen | `BL/TextModuleArea`, `DAO/TextModuleArea`, `ReceiptTemplateBL`, `HelpdeskPatternBL`, `Controllers/Tickets/TicketPatternsController.cs` | variable Texte und Vorlagen je Objektart. | flach | SyRS-30 |
+| 48 | Zeiterfassung | `BL/Time/`, `Sales/Support/HelpdeskTimer*`, `Modules/Finances/TimerBilling` | Zeiten inkl. Abrechnungsüberleitung. | mittel | SyRS-14, StRS-3, StRS-7 |
+| 49 | Riverbird-Kopplung | `BL/RiverDivo/`, `deployment/riverbird` | Synchronisation mit Abo-Plattform des Herstellers. | mittel | StRS-14, SyRS-22 |
+| 50 | Artikel-/Lagerlogik | `src/backend/Centron.BL/Warehousing/` | Artikelstamm-Pflege, Barcodes, Staffelpreise, Zweitlager. | mittel | StRS-5, SwRS-11, SwRS-12 |
+| 51 | Telemetrie/Logging | `BL/Telemetry/`, `Common/Logging/` | Laufzeitprotokolle, In-Memory-Diagnose. | mittel | SyRS-28, SwRS-26 |
+| 52 | Verweise/Links | `BL/Urls`, `WebLinks`, `ObjectExternalReferences`, `Controllers/Integrations/ObjectExternalReferences` | Externe Referenzen/Links an Fachobjekten. | flach | StRS-10 |
+| 53 | Querschnittsbibliothek | `src/backend/Centron.Common/` | Logging, Settings, Format, IniParser, Benutzer-Utilities. | mittel | SwRS-26, SwRS-8 |
+| 54 | Datenschicht | `src/backend/Centron.DAO/` (NHibernate, NamedQueries, ChangeTracking, Mappings, Statistics) | Persistierung, Abfragen, Änderungsnachverfolgung. | mittel | SwRS-7, SwRS-24, SwRS-25 |
+| 55 | Entitäten | `src/backend/Centron.Entities/` | Datenmodell-Klassen (z. B. Mahnlauf). | mittel | SwRS-5 |
+| 56 | Verträge/Schnittstellen | `src/backend/Centron.Interfaces/` | BL-/Gateway-Verträge als Interfaces. | flach | SyRS-1, SwRS-8 |
+| 57 | WPF-Client Shell+Module | `src/centron/Centron.WPF.UI/` (29 Module, Dialogs, Wizards, Localization, Managers) | Desktop-Oberfläche, Modulnavigation, Masken. | mittel | StRS-12, SwRS-27, SwRS-35 |
+| 58 | WPF-Erweiterungsbibliothek | `src/centron/Centron.WPF.UI.Extension/` | MVVM-, Commands-, Converter-Framework. | flach | SwRS-27 |
+| 59 | Steuerelements-Bibliothek | `src/shared/Centron.Controls*` | Wiederverwendbare Funktionscontrols (PositionGrid, Mail, PDF-Scan …). | mittel | StRS-10, StRS-15, SwRS-30 |
+| 60 | Kernbibliothek | `src/shared/Centron.Core/` | MVVM, TOTP, Threading, IO/Xml-Utilities. | mittel | SyRS-5, SwRS-15 |
+| 61 | API-Host | `src/webservice/Centron.Host/`, `.Console`, `.WindowsService`, `RealTimeServices` | Request-Pipeline, Auth-Schemes, SignalR-Hubs, Hosting-Varianten. | tief | StRS-16, SyRS-1, SyRS-2, SyRS-16, SwRS-8, SwRS-28 |
+| 62 | API-Controller | `src/webservice/Centron.Controllers/` | REST-Endpunkte inkl. Authorization-Attribute. | tief | StRS-9, SyRS-3, SyRS-4, SwRS-13 |
+| 63 | Webservice-Core/Clientlib | `src/webservice/Centron.WebServices.Core/` | REST-Client, Message-/Entity-Grundlage, `UserRightsConst`. | mittel | SwRS-13, SwRS-9 |
+| 64 | ConnectionManager | `src/webservice/c-entron.misc.ConnectionManager/` | Client-Konfiguration, Hardware-ID, Lizenz, SQL-Servercheck. | mittel | SwRS-33, SyRS-25 |
+| 65 | Nexus-Webanwendung | `src/nexus/CentronNexus/` (WebCart, WebOffer, ServiceBoard, Office, DocumentSigning, ProductionOrderManagement, Settings, Authorization) | Kunden-/Service-Portal und Web-Arbeitsplätze (Blazor). | mittel | StRS-8, StRS-11, SyRS-15, SwRS-20 |
+| 66 | Nexus-Host | `src/nexus/CentronNexus.Host/` | Start/Hosting der Blazor-App. | flach | SyRS-1 |
+| 67 | Outlook-AddIn | `src/nexus/CentronNexus.OutlookAddIn/` | E-Mail-Anbindung an Tickets aus Outlook. | flach | SyRS-19 |
+| 68 | Container-Betrieb | `docker/` (compose, Images für db/webservice/nexus/mailcatcher/regression-db) | Referenz-Deployment als Compose-Stack. | tief | StRS-16, SyRS-1, SyRS-19, SyRS-25, SyRS-29 |
+| 69 | Installations-/Deploy-Artefakte | `deployment/` (WixSharpInstaller, centron, riverbird) | Windows-Installer und zielgruppenspezifisches Deployment. | flach | StRS-16, StRS-14 |
+| 70 | Feature-Dokumente | `docs/features/` | Funktionsdoku (automatische Ticketanlage, Sync-Bugprotokoll). | flach | StRS-3 |
+
+**Abdeckungsstatistik:** 70 Module; tief = 10, mittel = 25, flach = 31, nicht analysiert = 4 (5,7 % < 10 %-Schwelle; Begründungen in der Tabelle).
+
+---
+
+## 2. Konsistenzcheck (skriptgestützt über alle drei Anforderungsdateien)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Doppelte/mehrfach vergebene IDs | **0 Duplikate** bei 81 Anforderungen (16 StRS, 30 SyRS, 35 SwRS; IDs je Ebene lückenlos 1..n). |
+| Anforderungen ohne Beleg | **0** – jeder Block enthält mindestens einen klassifizierten Beleg. |
+| Anforderungen ohne `Übernahmewürdigkeit` | **0** – Feld in allen 81 Blöcken gefüllt. |
+| Tracelinks auf nicht existierende IDs | **0 Verweise ins Leere** (alle referenzierten IDs vorhanden). |
+| SwRS→SyRS-Rückkopplung | Nach Korrektur verweist **jede** SwRS-Anforderung auf ≥1 SyRS; **jede** SyRS auf ≥1 StRS. |
+| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | Kontrolliert für: EDI-Partner (SyRS-11, SwRS-11-Gateway-Zeile), Vertragsbewertung Alt/Neu (StRS-7↔SwRS-31), ZUGFeRD-Alt/Neu (SyRS-9↔SwRS-21), Signatur intern/extern (SyRS-20↔StRS-15), Versand-Adapter (SyRS-10), Produktimport (StRS-13↔SyRS-12), 2FA/Passwort (SyRS-5↔SwRS-15), DMS-Vierfachpfade (StRS-15) – alle als Konsolidierungskandidat markiert bzw. über Tracelinks getrennt. |
+| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | **exakt 14 = 14**: StRS-14, SyRS-13, SyRS-20, SyRS-21, SyRS-22, SyRS-25, SwRS-5, SwRS-12, SwRS-19, SwRS-24, SwRS-25, SwRS-31, SwRS-33, SwRS-35 – identisch in beiden Nachweisen; `Hypothesen.md` enthält keine freien Punkte ohne Anforderung. |
+| `Status`-Feld nur mit `belegt`/`HYPOTHESE` | eingehalten; Workaround/Sonderfall/veraltet ausschließlich in `Übernahmewürdigkeit`. |
+
+## 3. Liste der risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
+
+| ID | Titel | PRIMÄR-Beleg vorhanden? | Belegsituation |
+|---|---|---|---|
+| StRS-2 | Verkaufsprozess inkl. Bonitätsüberwachung | ja (`ReceiptBL` Limit-/Mahnstufencode) | belegt |
+| StRS-6 | Debitoren/Mahnen/E-Rechnung | ja (`RechKopf`-Schema, `InvoiceZugferdBL`) | belegt |
+| StRS-7 | Vertrags-/Abo-Abrechnung | ja (`GutscheinZuRechnung`-Schema) | belegt |
+| StRS-9 | Benutzerberechtigungen | ja (`AuthorizeUserRightAttribute`, `ReceiptBL`) | belegt |
+| SyRS-2 | Ticket-/Token-Authentisierung | ja (`TicketAuthenticationHandler`) | belegt |
+| SyRS-3 | JWT-Login mit Anwendungsprüfung | ja (`JwtAuthController.LoginWithBearer`) | belegt |
+| SyRS-4 | Deklarative API-Rechteprüfung | ja (`AuthorizeUserRightAttribute`) | belegt |
+| SyRS-5 | 2FA (TOTP) | ja (`TwoFactorAuthenticationBL.ValidateAuthenticationPin`) | belegt |
+| SyRS-6 | Passwort-Hashing | ja (`CryptoUtils.CreatePasswordHash`) | belegt |
+| SyRS-7 | Kreditlimit-Prüfung | ja (`ReceiptBL.cs:8636`) | belegt |
+| SyRS-8 | Belegsperre ab Mahnstufe | ja (`ReceiptBL.cs:10194`) | belegt |
+| SyRS-9 | E-Rechnungsformate | ja (`InvoiceZugferdBL.GetZugferFormat`, `EbInterfaceLogic.ValidateValues`) | belegt |
+| SyRS-13 | Onlinebanking | nein (nur SEKUNDÄR) | **HYPOTHESE** (korrekt markiert) |
+| SyRS-14 | Zeiterfassung→Fakturierung | ja (`HelpdeskTimerBL.cs:554-556` Rechtsprüfung; `:119-142` Belegzuordnung) | belegt |
+| SyRS-22 | Riverbird-Sync (Vertragsdaten) | nein (nur KONTEXT-Klassendoku) | **HYPOTHESE** (korrekt markiert) |
+| SyRS-24 | Belegversionierung/Protokollierung | ja (30 `*Versions`-Tabellen, `ReceiptLogBL`-Aufrufe) | belegt |
+| SyRS-25 | Lizenz-/Hardwarebindung | nein (nur SEKUNDÄR-Umgebung) | **HYPOTHESE** (korrekt markiert) |
+| SwRS-3 | RechKopf Zahlungs-/Mahnfelder | ja (Spaltendefinitionen) | belegt |
+| SwRS-5 | Mahnlauf-Entität | nein belastbar (Entitätsdeklaration, keine Prüfung) | **HYPOTHESE** (korrekt markiert) |
+| SwRS-13 | Rechtekonstantenbaum | ja (`UserRightsConst.cs`) | belegt |
+| SwRS-14 | Ticketvalidierungsroutine | ja (`AuthenticationTicketBL.cs:25-47`) | belegt |
+| SwRS-15 | TOTP-Schlüsselverwaltung | ja (`TwoFactorAuthenticationBL`) | belegt |
+| SwRS-16 | SHA-1-Passwort-Hash | ja (`CryptoUtils.cs:26-33`) | belegt |
+| SwRS-17 | Limitalgorithmus | ja (Methode vollständig) | belegt |
+| SwRS-18 | Beleganlage-Gate | ja | belegt |
+| SwRS-21 | ZUGFeRD/Auswahl | ja | belegt |
+| SwRS-22 | ebInterface-Export | ja | belegt |
+| SwRS-25 | Change-Tracking | nein (nur Ordner/Kommentar) | **HYPOTHESE** (korrekt markiert) |
+| SwRS-31 | Vertragsbewertung Alt/Neu | nein (nur Ordnerbelege) | **HYPOTHESE** (korrekt markiert) |
+| StRS-14 | Riverbird-Geschäftsmodell | nein | **HYPOTHESE** (korrekt markiert) |
+| SwRS-35 | Massenupdates (Zugriff auf Belege/Stammdaten) | nein | **HYPOTHESE** (korrekt markiert) |
+
+Keine risikorelevante Anforderung liegt ohne PRIMÄR-Beleg mit Status `belegt` vor.
+
+## 4. Bekannte Lücken
+
+- Keine Laufzeit-/DB-Analyse möglich: Zustandsautomaten, Zahlenwerte (z. B. `MaxReceiptProgressionSize`) und Konfigurationsprofile bleiben punktuell offen.
+- `docs/`-Bestand ist dünn (wenige Feature-Dokumente); Change-Historie nur über `changelog.txt` des Nexus verfügbar, keine Commit-Messages im Spiegel.
+- Nicht gelesene Großdateien: `ReceiptBL.cs` umfasst ~11.500 Zeilen; gelesen wurden die risikorelevanten Abschnitte (Limit, Mahnstufe, Web-Änderungen, Textvariablen, Preis-/Log-Ausschnitte).
+
+## 5. Selbstbewertung
+
+- **Analysetiefe über alle 70 Module des Inventars:** 10 tief, 25 mittel, 31 flach, 4 gar nicht (`assemblies`/`nugets`, `scripts`, `BL/ArtificialIntelligence`, `BL/CPra` – Begründungen je Zeile in der Tabelle). Das sind 5,7 % nicht analysiert, unter der 10 %-Schwelle.
+- **Mindestabdeckung:** erreicht – jedes analysierte Modul hat ≥1 Anforderung; die 4 nicht analysierten Module tragen eine Begründung statt einer Requirement.
+- **Dünne Belegstellen:** hoher SEKUNDÄR-/KONTEXT-Anteil dort, wo nur Verzeichnis- und Dateinamen als Beweismittel dienten (Module 9, 11–14, 22, 25, 27, 28, 32, 38–43); `[HYPOTHESE]` bei 14 von 81 Anforderungen (17 %), schwerpunktmäßig Riverbird (2), Doku-basierte Signatur-/Telefonie/Lizenzthemen und Datenmodell-Fragezeichen (Mahnlauf-Persistenz, ChangeTracking, ContractEvaluation-Migrationsstand).
+- **Hypothesen:** 14 offene Punkte geführt – bei einer Codebasis dieser Größe (1.558 Tabellen, 16.800 Dateien) unausweichlich; das Nicht-Führen weiterer Hypothesen wäre eher ein Alarmsignal.
+- **Nachschlag für eine Folge-Iteration empfohlen:**
+  1. `HelpdeskCloseBL`/`HelpdeskTimerBookedArticlesFilter` im Detail lesen (Abrechnungs-Sperrlogik der Zeiten vollständig belegen).
+  2. `AccessTokenBL` + `AccessTokensController` (Gültigkeit, Rotation, IP-Bindung der Access-Token).
+  3. `Modules/Finances/Dunning/DunningRunViewModel` + Mahnlauf-DAO: echte Mahnstufen-Berechnungsregeln und Fristenberechnung.
+  4. Lizenz-/Hardware-ID-Prüfung im Startpfad von `CentronHost.cs`/`Program.cs` lokalisieren (risikorelevant, aktuell Hypothese).
+  5. `ContractEvaluation2`-Regelsatz extrahieren (Abrechnungslogik für Zielsystem-Spezifikation vertiefen).
+  6. `MahnlaufMaps`-Frage klären (endgültige vs. temporäre Tabelle) – relevant für Datenmigration.
+
+*Stand: Lauf vom 2026-09-02, v13.0.0-af37; Analyse rein statisch, Codebasis unverändert.*

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Glossar.md

@@ -0,0 +1,40 @@
+# Glossar
+
+Domänenbegriffe, wie sie aus der Codebasis abgeleitet wurden (technische Bezeichner in Originalsprache).
+
+| Begriff | Bedeutung im System | Erstverwendung |
+|---|---|---|
+| Mandant | Rechtliches Unternehmen/Installation auf der Plattform; Filialen tragen `MandantI3D` | StRS-1, SwRS-4 |
+| Filiale | Betriebseinheit eines Mandanten mit eigener Adresse, Preisliste, Buchhaltungsnummer; `IsDefault` steuert Standard | StRS-1, SwRS-4 |
+| Beleg | Oberbegriff für Verkaufsdokumente; Implementierung als Kopf-/Positionstabellen je Art (`AngKopf` Angebot, `AufKopf` Auftrag, `RechKopf` Rechnung, `GutKopf` Gutschrift, `RepaKopf` Reparatur) | StRS-2, SwRS-2 |
+| Belegkette / Receipt Progression | Nachverfolgbare Folge von Belegen über Herkunftsschlüssel (`OriginKind`, `OriginReceiptI3D`, `AusAuf`) | StRS-2, SwRS-19 |
+| AppUser | Interner Benutzer des Systems (Mitarbeiter), identifiziert über `AppUserI3D` | SyRS-2, SwRS-15 |
+| Web-Account | Externer Kunden-Zugang für Nexus/WebCart, im Adressstamm gepflegt, von AppUser getrennt autorisiert | StRS-8, SyRS-15 |
+| Mahnstufe | Eskalationsstufe des Mahnprozesses je Geschäftspartner (`RechKopf.Mahnstufe`, Mahnung1–3); kann Belegneuanlagen sperren | StRS-6, SyRS-8 |
+| Mahnlauf | Ausgeführter Mahndurchgang als Protokollsatz (`Mahnlauf`-Tabelle mit Alt-/Neu-Status) | SwRS-5 |
+| Kreditlimit (CreditLimit) | Vom Kunden akzeptierter offener Zahlungshöchstbetrag; Prüfung netto oder brutto (`CreditLimitCalculationKind`) | SyRS-7, SwRS-17 |
+| Restricted/Restricting Right | Einschränkung eines Fachrechts auf „nur eigene Objekte / eigene Filiale / eigene Abteilung“ (z. B. `SHOW_HELPDESK_ONLY_OWN`) | StRS-9, SwRS-13 |
+| Sonderpreise | Kundenindividuelle Preise; Grundlage des WebCart-Shops | StRS-8 |
+| HelpdeskState | Konfigurierbarer Ticketstatus inkl. Abschlussstatus; Löschschutz bei Verwendung | SwRS-10 |
+| Ticket (Helpdesk) | Supportvorgang mit Status, Priorität, Kategorien, Zeiten, Checklisten, Historie | StRS-3 |
+| Hilfe-/Ticketzeit (HelpdeskTimer) | Zeiterfassung am Ticket, mit Anfahrtsartikeln; nach Abrechnung unveränderbar | SyRS-14 |
+| Checkliste / C-FLOW | Punktelisten am Ticket; C-FLOW bezeichnet Ticketvorlagen-/Pattern-Funktion | StRS-3 (Rechte 16–17) |
+| ZUGFeRD / XRechnung | Deutsches Format strukturierte E-Rechnung; `ZugferdKind`-Enum wählte Versionen bis `XInvoice_3_0_1` | SyRS-9 |
+| ebInterface | Österreichisches E-Rechnungs-XML-Format (Schema 4.3 implementiert) | SyRS-9, SwRS-22 |
+| Concerto / OpenTrans | Lieferanten-/Bestellnachrichtenformate des Gateway-Layers | SyRS-11, SwRS-23 |
+| EDI-Partner | Implementierte Großhandelsanbindungen: Alltron, Also (DE/CH), EGIS, Herweck, Komsa, comLine (Cop) | SyRS-11 |
+| Icecat / ITscope | Externe Produktdatenquellen für Artikelanreicherung | StRS-13 |
+| FinAPI / FinTS (libfintx) | Onlinebanking-Kanäle (REST-API bzw. Bankstandard) | SyRS-13 |
+| Riverbird / RiverDivo | Abo-/Vertragsplattform des Herstellers; Sync zwischen Riverbird- und c-entron-Webservice | StRS-14, SwRS-22 (Syn. RiverDivoBL) |
+| DocBee / docuFORM | Externe Dokumenten-Processing- bzw. Signaturdienste mit eigenen Controllern/Clients | SyRS-20, StRS-10 |
+| RMM | Remote-Monitoring-&-Management-Integration (`RmmController`, `RmmConnectionSettingsController`) | StRS-10 (Kontext) |
+| TelekomDive | Cloud-Telefonie-Anbieterintegration | SyRS-21 |
+| TAPI | Windows-Telefonie-API-Legacy-Anbindung | SyRS-21 |
+| WebCart | Kunden-Shop in Nexus mit kundenspezifischen Sonderpreisen | StRS-8 |
+| ServiceBoard / ProductionOrderManagement / DocumentSigning | Nexus-Webbereiche für Service-Cockpit, Fertigungsaufträge, Dokumentenunterschrift | StRS-11 |
+| Versionstabelle (`*Versions`) | Historie je Belegkop/-position (z. B. `AngKopfVersions`) | SyRS-24, SwRS-2 |
+| LockUser | Bearbeitungssperre am Belegkopf (Sperrvermerk, wer bearbeitet) | SwRS-3 |
+| Status-Spalte / Weichlöschung | Systemweites Muster: `Status` für Gültigkeit, `Geloescht*`-Spalten statt physischem DELETE | SwRS-6 |
+| ConnectionManager | separates Konfigurations-/Diagnosetool des Desktop-Clients (Hardware-ID, Lizenz, Servercheck) | SwRS-33 |
+| Nexus | Weboberfläche (Blazor) des Systems, intern auch „c-entron Web“ | StRS-8 |
+| c-entron.NET | Bezeichnung des Desktop-Clients/Produkts in Rechten und Doku | StRS-9 |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Hypothesen.md

@@ -0,0 +1,20 @@
+# Hypothesen
+
+Sammlung aller Anforderungen, die in StRS/SyRS/SwRS mit Status `HYPOTHESE` markiert sind. Offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
+
+| ID | Titel | Offene Frage / fehlende Information |
+|---|---|---|
+| StRS-14 | Verknüpfung mit der Riverbird-Abonnementplattform | Welches Geschäftsmodell und welcher Synchronisationsumfang (Vertrag, Artikel, Status) konkret über Riverbird/Divo abgebildet wird, ist nur aus Klassendoku-Kommentaren erschlossen; Schnittstellenverträge/Beispieldaten fehlen im Artefaktbestand. |
+| SyRS-13 | Onlinebanking-Anbindung (FinAPI, HBCI/FinTS) | Die konkrete Regel, nach der importierte Kontoumsätze offenen Rechnungen zugeordnet werden (Verwendungszweck-Matching, Toleranzen), wurde in `IncomingPaymentBL` nicht nachgewiesen; ebenso, welcher Kanal (FinAPI vs. FinTS) produktiv primär ist. |
+| SyRS-20 | Dokumentensignatur über docuFORM und PDF-Signing | Das Statusmodell des Signaturflusses (welche Zustände, wer signiert, Verfallsregeln) ist aus `PdfSigningBL`/`DocuFormRestApiClient` nicht vollständig ablesbar; API-Doku des Anbieters fehlt. |
+| SyRS-21 | Telefonie-Integration (TAPI, TelekomDive) | Funktionsbreite beider Kanäle (Anruflistorik? Click-to-Dial nur ausgehend?) und ihr Nutzungsstatus sind nicht belegt; `PhoneCallBL` wurde nicht im Detail gelesen. |
+| SyRS-22 | bidirektionale Riverbird-Synchronisation | Fachlicher Umfang der Synchronisation (welche Entitäten, welche Trigger) basiert nur auf den Klassenkommentaren von `RiverConnectionBL`/`RiverDivoBL`. |
+| SyRS-25 | Lizenzierung an Hardware-ID gebunden | Der Durchsetzungspunkt der Lizenzprüfung im Startpfad (Client und Webservice) wurde nicht lokalisiert; Verhalten bei Lizenzfehler (Sperrung vs. Warnung) unbelegt. |
+| SwRS-5 | Mahnlauf-Entität als Protokollsatz je Mahnstufe | Unklar, ob `Mahnlauf` endgültige Persistenz hat oder in eine finale Tabelle überführt wird (Mapping liegt unter `TemporaryEntities`). |
+| SwRS-12 | Lagerbestand je Artikel | Bestandsbewegungsregeln (Reservierung durch Aufträge, Sperrbestand, Kommissionierbestand) sind aus `ArtikelBestand`-Tabelle und BL-Namen nicht belegbar. |
+| SwRS-19 | Belegverlauf (Receipt Progression) mit Größenbegrenzung | Konkreter Wert von `MaxReceiptProgressionSize` sowie Sortier-/Filterlogik der Progressionsanzeige wurden nicht extrahiert. |
+| SwRS-24 | Temporäres Entity-Mapping für Mahnlauf | Grund der Ablage unter `TemporaryEntities` (Restmigration? Zwischenlösung?) bleibt aus den Artefakten entscheidungslos. |
+| SwRS-25 | DAO-seitiges Change-Tracking | Funktionsumfang des `ChangeTracking`-DAO (welche Tabellen/Felder getrackt werden, Aufbewahrung) ist nicht aus dem gelesenen Code ersichtlich. |
+| SwRS-31 | Vertragsbewertung Alt (ContractEvaluationOld) neben Neu | Welche Implementierung produktiv genutzt wird und wie der Altbestand migriert wurde/wird, ist ohne Laufzeitanalyse nicht bestimmbar. |
+| SwRS-33 | Client-Konfigurations-/Verbindungsverwaltung ConnectionManager | Prüftiefe des `SQLServerCheckTool` und Verhalten bei Konfigurationsänderungen (Neustartpflicht) sind nicht belegt. |
+| SwRS-35 | Massenaktualisierung von Fachdaten | Welche Objektarten/Felder massenänderbar sind und wie Berechtigungen greifen, ist nur über die Existenz von BL- und Modulordner belegt. |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/StRS.md

@@ -0,0 +1,351 @@
+# StRS – Stakeholder Requirements Specification
+
+Quellsystem: c-entron ERP-Suite (c-entron.NET / c-entron Nexus). Alle Anforderungen rückwärts aus der Codebasis abgeleitet (statische Analyse, keine Ausführung).
+
+---
+
+ID:            StRS-1
+Titel:         Mandanten- und Filialfähiges Wirtschaftssystem
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Systemadministrator
+Vorbedingung:  Ein Unternehmen (Mandant) betreibt eine oder mehrere Filialen.
+Fakt:          DB-Tabelle `Filiale` enthält Spalten `MandantI3D`, `IsDefault`, `FilialStatus`, `Buchhaltungsnummer`, `Preisliste`; viele Fachtabellen führen `Status`/`Geloescht*`-Spalten (z. B. `GeloeschtVonI3D`, `GeloeschtAm` in `Filiale`). Rechtetexte differenzieren Datenzugriff auf Filialebene („nur eigene Filiale“, `CentronRights.md`, Punkte 1.2, 2.1).
+Aussage:       Das System soll die Daten und Prozesse mehrerer Unternehmen (Mandanten) und mehrerer Filialen je Mandant trennen und auswertbar halten.
+Ergebnis:      Fachdaten (Belege, Kunden, Filialzuordnungen) sind eindeutig Mandant und Filiale zuordenbar; Berechtigungen können auf die eigene Filiale eingeschränkt werden.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, `CREATE TABLE [dbo].[Filiale]` (Zeile ~43903, Spalten `MandantI3D`, `IsDefault`, `GeloeschtVonI3D`) - Schema schreibt Mandanten-/Filialbezug strukturell fest.
+  - [SEKUNDÄR] `CentronRights.md`, Punkte 1.2/2.1 (`SHOW_HELPDESK_ONLY_OWN_BRANCH`, `CREATE_HELPDESK_ONLY_OWN_BRANCH`) - fachliche Filialtrennung als Nutzeranforderung dokumentiert.
+Prüfidee:      Zwei Filialen anlegen; ein Benutzer mit „nur eigene Filiale“-Recht sieht Tickets/Belege der anderen Filiale nicht.
+Tracelinks:    SyRS-23, SwRS-4, SwRS-32
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandanten-/Filialfähigkeit ist Kernanforderung eines ERP-Zielsystems.
+Status:        belegt
+
+---
+
+ID:            StRS-2
+Titel:         Durchgängiger Verkaufsprozess vom Angebot bis zur Rechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Innendienst, Außendienst, Kaufmännischer Leiter
+Vorbedingung:  Kunde ist im Adressstamm gepflegt.
+Fakt:          DB enthält Belegkopf-/Positionstabellen `AngKopf`/`AngPos` (Angebot), `AufKopf`/`AufPos` (Auftrag), `RechKopf`/`RechPos` (Rechnung), `GutKopf` (Gutschrift) mit Herkunftsverweisen (`AusAuf`, `OriginKind`, `OriginReceiptI3D`); `ReceiptProgressionBL` bildet die Belegfolge ab; `ReceiptBL` prüft beim Speichern Kreditlimit und Mahnstufe des Kunden.
+Aussage:       Das System soll den Verkaufsprozess als Belegkette (Angebot → Auftrag → Lieferschein → Rechnung → Gutschrift) mit Vererbung von Positionen und Herkunftsnachweis unterstützen und dabei die Bonität des Kunden überwachen.
+Ergebnis:      Folgebelege übernehmen Positionen aus dem Ursprungsbeleg; Überschreitung des Kreditlimits oder aktive Mahnstufe lösen Warnung bzw. Sperre aus.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636` (`CheckIfCustomerLimitIsReached`), `:10194` (`CanUserCreateNewReceiptsAtCustomerOrSupplier` inkl. Mahnstufenprüfung) - durchgesetzte Geschäftsregeln.
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, Tabellen `AngKopf`, `AufKopf`, `RechKopf`, `GutKopf`; Spalten `AusAuf` (Herkunft Auftrag) in `RechKopf` - Datenmodell der Belegkette.
+  - [KONTEXT]  `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` - eigene BL für „Receipt Progression“ belegt das Konzept der Belegfolgedarstellung.
+Prüfidee:      Aus einem Auftrag einen Lieferschein erzeugen; Positionen und Kundenbezug sind identisch; nach Setzen von Mahnstufe 1 (mit Sperrkonfiguration) scheitert die Anlagen neuer Belege mit Fehlermeldung.
+Tracelinks:    SyRS-7, SyRS-8, SyRS-9, SwRS-2, SwRS-17, SwRS-18, SwRS-19
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - KERN-Prozess, für die Neuimplementierung zwingend.
+Status:        belegt
+
+---
+
+ID:            StRS-3
+Titel:         Kunden-Support mit Tickets, Zeiten und Checklisten
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Support-Mitarbeiter, technischer Dienstleister, Kunde (im Portal)
+Vorbedingung:  Ticketanlage-Berechtigung liegt vor; Tickettypen/Kategorien sind gepflegt.
+Fakt:          `CentronRights.md` beschreibt Ticketrechte inkl. einschränkender Rechte (nur eigene Tickets, eigene Filiale, Zuweisung nur an eigene Abteilungen); `HelpdeskStatusBL` verwaltet konfigurierbare Ticketstatus und blockiert das Löschen verwendeteter Status; `HelpdeskTimer*`-BL-Klasse erfasst Zeiten am Ticket; Nexus-Changelog dokumentiert Zeiterfassung, Historie, Weiterleitungen und Checklisten im Ticket.
+Aussage:       Das System soll ein Ticketssystem mit konfigurierbaren Status, Prioritäten, Kategorien, Zuweisungen, Zeiterfassung, Checklisten und Kundenkommunikation bereitstellen; Zeiten sollen abrechenbar an Belege überleitbar sein.
+Ergebnis:      Tickets sind von Erfassung bis Abschluss nachverfolgbar; geleistete Zeiten sind für die Fakturierung verfügbar und vor unberechtigter Änderung geschützt.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Support/HelpdeskStatusBL.cs:75-100` (`DeleteHelpdeskStatus` zählt Verwendung und verhindert Löschen) - erzwungene Referenzintegrität.
+  - [SEKUNDÄR] `CentronRights.md`, Helpdesk-Abschnitt 1-17 - fachliche Rechtebeschreibung.
+  - [KONTEXT]  `src/nexus/CentronNexus/changelog.txt` (Zeiteintrag, Historie, Weiterleitungen) - gelebte Nutzung.
+Prüfidee:      Ticketstatus mit referenzierenden Tickets löschen → Fehlermeldung „wird in … verwendet“. Zeit eines abgerechneten Tickets verschieben → abgelehnt (Recht `MOVE_HELPDESK_TIMER` greift nur bei nicht abgerechneten Zeiten).
+Tracelinks:    SyRS-14, SyRS-19, SwRS-10, StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Arbeitswerkzeug der Support-Rolle.
+Status:        belegt
+
+---
+
+ID:            StRS-4
+Titel:         Wareneinkauf mit elektronischer Lieferantenanbindung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf, Großhandelslieferant
+Vorbedingung:  Lieferantenstamm und EDI-Verbindung sind konfiguriert.
+Fakt:          `Centron.Gateway` enthält EDI-Implementierungen für `EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_EGIS`, `EDI_Herweck`, `EDI_Komsa`, `Concerto` (XSD `ConcertoOrder.xsd`), `OpenTrans`; `Centron.APIs.EgisDataAccess`/`CopDataAccess` mit SOAP-/Request-Templates; `Purchasing/SupplierOrderPerBranchBL.cs` (filialbezogene Bestellungen).
+Aussage:       Das System soll Bestellungen und Auftragsstatus elektronisch mit mehreren Großhandelslieferanten austauschen (EDI) und Lieferantendaten (Verfügbarkeit, Preise) übernehmen.
+Ergebnis:      Bestellung geht elektronisch beim Lieferanten ein; Artikelstammdaten und Bestellstatus werden automatisch zurückgespielt.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - verbindliches Schnittstellen-Layout einer Bestell-Schnittstelle.
+  - [SEKUNDÄR] Verzeichnisliste `src/backend/Centron.Gateway/EDI_*`, `src/apis/Centron.APIs.EgisDataAccess/RequestTemplates` - benannte Partnerintegrationen.
+  - [KONTEXT]  `src/webservice/Centron.Controllers/Controllers/DataExchange/*` (DocBee, Rmm, TelekomDive, DocuForm) - Datenaustausch-API.
+Prüfidee:      Musterbestellung an Test-EDI-Partner senden; XSD-Validierung des Ausgangsdokuments erfolgreich; Statusimport aktualisiert die Bestellposition.
+Tracelinks:    SyRS-11, SyRS-12, SwRS-23
+Konsolidierung: Kandidat: die je Lieferanten getrennten EDI-Implementierungen (EDI_Alltron, EDI_Also, EDI_EGIS, EDI_Komsa, EDI_Herweck) bilden dasselbe Konzept „Lieferantenanbindung“ ab; im Zielsystem als konfigurierbare Connector-Plattform zusammenführen.
+Übernahmewürdigkeit: übernehmen - ohne EDI ist das Tagesgeschäft (Tagesaktuelle Preise/Verfügbarkeiten) nicht möglich; konkrete Partnerliste ist Sonderfall-behaftet.
+Status:        belegt
+
+---
+
+ID:            StRS-5
+Titel:         Zentraler Artikelstamm mit Lagern und Preisen
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb, Lager
+Vorbedingung:  Artikel- und Lagerdaten sind gepflegt.
+Fakt:          DB-Tabelle `Artikel` mit Zubehör, Alternativartikel, Ersatzteilen, Stücklisten (`ArtikelStueckliste`), Arbeitsplänen (`ArtikelArbeitsplan`), `ArtikelPreis`, `ArtikelBestand`, Einheiten (`ArtikelEinheit`); `Warehousing/BarcodeBL.cs`, `ArticleVolumePricesBL.cs` (Staffelpreise), `SecondStockArticleBL.cs`.
+Aussage:       Das System soll einen zentralen Artikelstamm mit Varianten, Einheiten, Preisstrukturen (Grundpreis, Staffeln, Sonderpreise je Kunde), Beständen, Barcodes und Produktionsdaten (Stückliste, Arbeitsplan) führen.
+Ergebnis:      Alle Belegarten greifen auf denselben Artikelstamm zu; Bestands- und Preisangaben sind je Filiale/Lager auswertbar.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, Tabellen `Artikel`, `ArtikelPreis`, `ArtikelBestand`, `ArtikelStueckliste`, `ArtikelEinheit` - Datenmodell.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/ArticleVolumePricesBL.cs`, `BarcodeBL.cs` - Preis-/Barcode-Logik vorhanden.
+Prüfidee:      Artikel mit Staffelpreis anlegen; Staffelauswahl auf Auftrag wirkt auf den Nettopreis (Feld `WithStaffelPrice` im Beleg, siehe `ReceiptBL.cs:10543`).
+Tracelinks:    SyRS-12, SwRS-11, SwRS-12
+Konsolidierung: Kandidat: „Stammblätter“ (Drucker) und „AssetManagementDevices“ führen denselben Hardware-Gegenstand doppelt (Beispiel aus dem Auftrag); Zusammenführung in ein Asset-Konzept.
+Übernahmewürdigkeit: übernehmen - Artikelstamm ist Fundament aller Belegprozesse.
+Status:        belegt
+
+---
+
+ID:            StRS-6
+Titel:          Debitorenbewirtschaftung: Zahlungseingang, Mahnwesen, elektronische Rechnungsformate
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Kreditorenbuchhaltung, Kunde
+Vorbedingung:  Offene Rechnungen vorhanden; Bankkonto angebunden.
+Fakt:          `RechKopf` enthält `FaelligAm`, `Mahnung1Datum`–`Mahnung3Datum`, `Mahnstufe`, `MahnStop`, `Bezahlt`; Entität `Mahnlauf` (`src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs`) protokolliert je Mahnstufe mit Bearbeiter und Soft-Delete; `Finances/IncomingPayments`, `Finances/OnlineBanking` (FinAPI), `InvoiceZugferdBL` erzeugt ZUGFeRD/XRechnung, `EbInterfaceLogic` erzeugt ebInterface 4.3 (Österreich).
+Aussage:       Das System soll offene Posten verwalten, Zahlungseingänge (auch per Onlinebanking-Umsätzen) zuordnen, ein stufenweises Mahnwesen mit Protokollierung unterstützen und Rechnungen in gesetzlichen elektronischen Formaten (ZUGFeRD/XRechnung, ebInterface) ausleiten.
+Ergebnis:      Mahnstufen erhöhen/entsperren sich nach Vollzug; Ausgangsrechnungen sind revisionssicher als Hybrid-PDF/Elektronische Rechnung verfügbar.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `RechKopf` (`Mahnstufe`, `Mahnung1..3Datum`, `MahnStop`, `Bezahlt`) - datenbankseitige Abbildung des Mahnprozesses; `ReceiptBL.cs:10194` erzwingt Sperrlogik aus Mahnstufe.
+  - [PRIMÄR]   `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-99` (`GetZugferFormat` wählt ZUGFeRD 1.0 / XInvoice 3.0.1) - Formatentscheidung im Code.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingFinApiBL.cs` - Umsatzübernahme.
+Prüfidee:      Rechnung mit Fälligkeitsverzug in Mahnlauf aufnehmen → Mahnstufe steigt, `Mahnlauf`-Satz mit Bearbeiter geschrieben; XRechnung-Ausgabe validiert gegen Schematron.
+Tracelinks:    SyRS-8, SyRS-9, SyRS-13, SwRS-3, SwRS-5, SwRS-21
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich (E-Rechnungspflicht) und betrieblich erforderlich.
+Status:        belegt
+
+---
+
+ID:            StRS-7
+Titel:         Wiederkehrende Abrechnung eigener Verträge (Abo-/Vertragsabrechnung)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service-Vertragsgestaltung, Fakturierung
+Vorbedingung:  Kundenvertrag (Wartung/Flatrate/Lizenz) existiert.
+Fakt:          WPF-Modul `src/centron/Centron.WPF.UI/Modules/Finances` enthält `AutomatedBilling`, `FlatrateBilling`, `TimerBilling`, `ContractEvaluation2` und `ContractEvaluationOld`, `Campaigns`, `Opos`; `Finances/ProductLifecycleBL.cs`; `GutscheinZuRechnung`-Tabelle im Schema.
+Aussage:       Das System soll wiederkehrende Entgelte aus Kundenverträgen (Pauschalen, Zeiterfassungs-Abos, nutzungsbasierte Modelle) automatisch abrechnungsreif machen.
+Ergebnis:      Verträge erzeugen periodisch Abrechnungspositionen/Belege; alt- und neu-Version der Vertragsbewertung sind getrennt führbar.
+Belege:
+  - [SEKUNDÄR] Modulverzeichnisse `Modules/Finances/AutomatedBilling`, `FlatrateBilling`, `TimerBilling`, `ContractEvaluation2` - benannte Abrechnungsart-Funktionen.
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, Tabelle `GutscheinZuRechnung` - Zuordnung Gutscheine→Rechnungen erzwungen.
+  - [KONTEXT]  Vorhandensein `ContractEvaluationOld` neben `ContractEvaluation2` - Migrationshistorie.
+Prüfidee:      Monatspauschalen-Vertrag anlegen; Abrechnungslauf erzeugt Rechnung mit Vertragsposition; Kündigung stoppt weitere Abrechnung.
+Tracelinks:    SyRS-22, SwRS-31, SwRS-34
+Konsolidierung: Kandidat: `ContractEvaluationOld` und `ContractEvaluation2` bilden dieselbe Funktion in zwei Ständen ab → nur Neuversion übernehmen.
+Übernahmewürdigkeit: übernehmen (Neuversion); `ContractEvaluationOld` = veraltet.
+Status:        belegt
+
+---
+
+ID:            StRS-8
+Titel:         Selbstbedienungsportal für Kunden (c-entron Nexus)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Endkunde des c-entron-Kunden, Web-Account
+Vorbedingung:  Kunde besitzt Web-Account mit Sonderpreisliste.
+Fakt:          `README.md`: WebCart für „customers of our customers“, Artikel aus „Sonderpreise“, Login als Web-Account; Nexus-Seiten `WebCart/ContractsOverview.razor`, `ReceiptDetailsOverview.razor`, `CustomerTicketDetailsPage.razor`, `CustomerPortalPublicDocumentsPage.razor`; Autorisierungsattribute `AuthorizeLoginUserAttribute` / `AuthorizeLoginWebAccountAttribute`.
+Aussage:       Das System soll Kunden im Webportal eigene Tickets (Anlage, Historie), Verträge, Belege/Rechnungen, öffentliche Dokumente und einen Shop mit kundenspezifischen Sonderpreisen bieten.
+Ergebnis:      Externe Kunden arbeiten am Ticket mit, ohne den Desktop-Client zu benutzen; Zugriffe sind auf Web-Account-Daten beschränkt.
+Belege:
+  - [PRIMÄR]   `src/nexus/CentronNexus/Shared/Authorization/Attributes/AuthorizeLoginWebAccountAttribute.cs` - erzwungene Unterscheidung interner Benutzer vs. Web-Account.
+  - [SEKUNDÄR] `src/nexus/CentronNexus/WebCart/*.razor` - Portal-Funktionsumfang aus Seitennamen.
+  - [KONTEXT]  `README.md` Zeilen 31-36 - fachliche Beschreibung des WebCart.
+Prüfidee:      Web-Account ohne eigene Sonderpreise sieht keine Artikel; Ticketansicht zeigt nur Tickets des eigenen Kundenkreises.
+Tracelinks:    StRS-3, SyRS-15, SwRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klar differenzierendes Kundenbedürfnis.
+Status:        belegt
+
+---
+
+ID:            StRS-9
+Titel:         Feingranulare Benutzerberechtigungen im Betrieb
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter, Administration, Mitarbeiter
+Vorbedingung:  Benutzer, Rollen/Gruppen und Rechte sind gepflegt.
+Fakt:          `CentronRights.md` definiert Rechte inkl. „restricting rights“ (nur eigene Tickets, nur eigene Filiale, nur eigene Zeiten); `UserRightsConst.cs` als Konstantenbaum; API-Attribute `[AuthorizeUserRight]`, `[AuthorizeAnyUserRight]`, `[AuthorizeAllUserRights]` mit 401/403-Semantik (`Centron.Controllers/Authorization/README.md`).
+Aussage:       Das System soll für jedes Fachrecht einschränkende Varianten (nur eigene Objekte, eigene Filiale, eigene Abteilung) unterstützen und Berechtigungen sowohl im Desktop-Client als auch in der Web-API einheitlich durchsetzen.
+Ergebnis:      Datenzugriff und Funktionen sind rollenscharf begrenzt; fehlende Rechte werden konsistent abgewiesen.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` (+ `AuthorizeAnyUserRightAttribute.cs`, `AuthorizeAllUserRightsAttribute.cs`) - durchgesetzte Prüfung im Request-Pipeline; README beschreibt Filter-Ausführung und 401/403.
+  - [SEKUNDÄR] `CentronRights.md` - fachliche Rechtebeschreibung.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194ff.` (`HasRightToCreateANewReceipt` via SpecificLogics) - Rechtsprüfung vor Beleganlage.
+Prüfidee:      Benutzer ohne `ADD_NEW_HELPDESK` ruft Ticket-API auf → 403; mit `SHOW_HELPDESK_ONLY_OWN` sieht er nur Tickets, in denen er Bearbeiter/Verantwortlicher ist.
+Tracelinks:    SyRS-4, SyRS-5, SyRS-6, SwRS-13, SwRS-15, SwRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Compliance-relevant.
+Status:        belegt
+
+---
+
+ID:            StRS-10
+Titel:         Interne Kommunikation und Zusammenarbeit
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter
+Vorbedingung:  Benutzer ist angemeldet.
+Fakt:          BL-Ordner `Mail`, `Mailings`, `MailScanner` (Eingehende Mails → Workflow-Profile/Tasks), `Chats`, `Notifications`, `Calendar`, `ToDoArea`, `MyDay`, `TaskManager`, `Tags`; `HelpdeskMailBL` verknüpft Mails mit Tickets; `Outlook`-BL und `CentronNexus.OutlookAddIn`.
+Aussage:       Das System soll E-Mail-Eingang automatisiert in Aufgaben/Tickets überführen, Kalender, Aufgaben („Mein Tag“), Chat und Benachrichtigungen integrieren und Mails an Objekte (Tickets, Belege) andocken.
+Ergebnis:      Ein- und ausgehende Kommunikation ist am Vorgang nachvollziehbar; wiederkehrende Mail-Eingänge (z. B. Störungsmails) erzeugen automatisch Tickets.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` (`SaveWorkflow`, `GetProfiles`, `SaveTasks`) - durchgesetzte Workflow-/Task-Erzeugung aus Mails.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskMailBL.cs` - Mail-Ticket-Verknüpfung.
+Prüfidee:      Testmail an gescanntes Postfach; konfiguriertes Profil erzeugt Ticket/Task; Log-Eintrag vorhanden.
+Tracelinks:    SyRS-16, SyRS-19, SwRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Effizienzkernfunktionen.
+Status:        belegt
+
+---
+
+ID:            StRS-11
+Titel:         Zugriff von unterwegs und aus Browser/Office
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Außendienst, Techniker, Führungskraft
+Vorbedingung:  Benutzer hat Web-Zugang.
+Fakt:          Nexus-Blazor-App mit `ServiceBoard`, `Office`, `ProductionOrderManagement`, `DocumentSigning`, `WebOffer`; BL-Ordner `Mobile`; `CentronNexus.OutlookAddIn`; `src/apis/Centron.Api.Gls`/`Shipcloud` für Versandprozesse; changelog.txt beschreibt „Mein Tag“, Ticketplanung etc. im Web.
+Aussage:       Das System soll Kernfunktionen (Tickets, Aufträge/Produktion, Angebote, Unterschriften, Tagesplanung) plattformunabhängig im Browser und in Office bereitstellen.
+Ergebnis:      Nutzer erledigen Support- und Vertriebsvorgänge ohne Desktop-Client; Aktionen sind mit denselben Rechten abgesichert wie im Client.
+Belege:
+  - [SEKUNDÄR] Verzeichnisse `src/nexus/CentronNexus/{ServiceBoard,Office,ProductionOrderManagement,DocumentSigning,WebOffer}` - benannte Web-Funktionen.
+  - [KONTEXT]  `src/nexus/CentronNexus/changelog.txt` (Mein Tag, Zeitplanung, Ticketdetails im Web).
+Prüfidee:      Gleiche Ticketaktion (Statuswechsel) in WPF und Nexus; identische Rechteprüfung und Historieneintrag.
+Tracelinks:    SyRS-1, SyRS-15, SyRS-20, SyRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zielrichtung der Web-/SaaS-Neuimplementierung.
+Status:        belegt
+
+---
+
+ID:            StRS-12
+Titel:         Auswertung, Berichte und Kennzahlen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Controlling, Sachgebietsleitung
+Vorbedingung:  Transaktionsdaten vorhanden.
+Fakt:          WPF-Module `Reports`, `Statistics`; `Centron.DAO/Statistics`; BL `ReportEngine` (Reportvorlagen, `HelpdeskHtmlTemplateManager`, `CustomZugferdPdfGenerator`); Controller `Statistics/NexowareStatisticsController.cs`; `HelpdeskStatisticsBL`, `ReceiptProvision*BL` (Provisionen).
+Aussage:       Das System soll betriebswirtschaftliche Auswertungen (Umsatz, Provision, Ticketstatistiken, Produktlebenszyklus) als Reports und Statistiken bereitstellen und dabei Berechtigungen beachten (z. B. Recht `SALES_STATISTIC`).
+Ergebnis:      Führungskraft erhält rechtsbasiert filterbare Kennzahlen und druckbare Berichte.
+Belege:
+  - [SEKUNDÄR] `src/centron/Centron.WPF.UI/Modules/Reports`, `Modules/Statistics` - Report-/Statistik-Module.
+  - [PRIMÄR]   `src/webservice/Centron.Controllers/Authorization/README.md` (Beispiel `[AuthorizeUserRight(UserRightsConst.Controlling.Analytics.SALES_STATISTIC)]`) - Rechtegesicherte Statistik-Endpunkte.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs` u. a. - Provisionssystematik.
+Prüfidee:      Benutzer ohne `SALES_STATISTIC` ruft Statistik-Endpunkt auf → 403; Report-Export als PDF/Excel möglich.
+Tracelinks:    SyRS-18, SwRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standardbedarf; konkrete Reportvorlagen einzeln prüfen.
+Status:        belegt
+
+---
+
+ID:            StRS-13
+Titel:         Externe Produktdatenquellen für den Shop-/Vertriebsbetrieb
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf, E-Commerce-Verantwortlicher
+Vorbedingung:  Zugangsdaten zu Datenquellen hinterlegt.
+Fakt:          `Centron.APIs.IcecatDataAccess` (IcecatApi, Sprachen), `Centron.APIs.ITscopeDataAccess` (Parser), `Centron.APIs.CopDataAccess` (SOAP-Templates), `ProductMatrix`-BL-Ordner.
+Aussage:       Das System soll Produktstammdaten (Beschreibungen, Bilder, Klassifikationen) aus externen Quellen (Icecat, ITscope u. a.) übernehmen und pflegen.
+Ergebnis:      Artikel erhalten pflegierte Produktinformationen ohne manuelle Erfassung.
+Belege:
+  - [SEKUNDÄR] `src/apis/Centron.APIs.IcecatDataAccess/IcecatApi.cs`, `Languages.cs`, `src/apis/Centron.APIs.ITscopeDataAccess/Parser` - benannte Produktdaten-APIs.
+  - [SEKUNDÄR] `src/backend/Centron.BL/ProductMatrix` - Produktmatrix-Funktionalität.
+Prüfidee:      Icecat-Abruf für Artikelnummer befüllt Artikeltext/Bild-Felder (ArtikelBilder-Tabelle vorhanden).
+Tracelinks:    SyRS-12, StRS-5
+Konsolidierung: Kandidat: Produktdaten-Anreicherung (Icecat/ITscope) und Lieferantenkatalog-Importe (EDI/EGIS) verfolgen dasselbe Ziel „Artikelstammdaten anreichern“; gemeinsame Import-Pipeline im Zielsystem.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-14
+Titel:         Verknüpfung mit der Riverbird-Abonnementplattform
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        c-entron-Hersteller, Wiederverkäufer
+Vorbedingung:  Riverbird-Vertrag vorhanden.
+Fakt:          `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` Doku-Kommentar: „all calls, that the c-entron Web-Service makes to the Riverbird Web-Service“; `RBContractArticleRefInfo.cs` (Vertrags-Artikel-Referenz); `deployment/riverbird` vorhanden.
+Aussage:       Das System soll Vertrags-/Abonnementdaten mit der Riverbird-Plattform synchronisieren (in beide Richtungen).
+Ergebnis:      Riverbird-Verträge spiegeln sich als Artikel/Positionen im c-entron, Änderungsmeldungen werden übernommen.
+Belege:
+  - [KONTEXT]  `src/backend/Centron.BL/RiverDivo/RiverConnectionBL.cs` (Klassendoku) + `RiverDivoBL.cs` („methods, that the Riverbird Web-Service calls in the c-entron Web-Service“) - beidseitige Synchronisation implementiert; nur durch Doku-Kommentare gestützt.
+  - [SEKUNDÄR] `deployment/riverbird` - Deployment-Ziel für Riverbird-Variante.
+Prüfidee:      Simulierter Riverbird-Callback aktualisiert lokalen Vertragsdatensatz.
+Tracelinks:    SyRS-22
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall -herstellerseitige Plattformkopplung, für generische Neuimplementierung optional.
+Status:        HYPOTHESE (Details des Geschäftsmodells und Synchronisationsumfang nicht im Code belegt)
+
+---
+
+ID:            StRS-15
+Titel:         Digitale Dokumentenablage, Unterschrift und Dokumentenflüsse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter, Recht/Compliance
+Vorbedingung:  Dokumentenverzeichnisstruktur existiert.
+Fakt:          `src/centron/Centron.WPF.UI/CentronFileSystem`, `Centron.Controls/CentronFileSystem`; BL `Storage`, `DocuBoard`, `DocumentationArea`; `Security/PdfSigningBL.cs`; API `Centron.Api.docuFORM` (DocuFormRestApiClient); Nexus-Modul `DocumentSigning`; Tabellen `ArtikelDateiLinks`, `DocDirI3D` in `RechKopf`; Controller `DocBee*`.
+Aussage:       Das System soll Dokumente objektscharf ablegen (Belege, Tickets, Artikel), den signierbaren Durchlauf (elektronische Unterschrift) unterstützen und Lösch-/Änderungshistorie von Dokumentbezügen wahren.
+Ergebnis:      Zu jedem Fachobjekt sind Dateien und deren Historie auffindbar; unterschriftspflichtige Dokumente durchlaufen einen Signaturprozess.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Security/PdfSigningBL.cs` - Signaturverarbeitung im Code.
+  - [SEKUNDÄR] `SSMS_DB_SCHEMA.sql` `RechKopf.DocDirI3D` - Dokumentverzeichnis am Beleg.
+  - [SEKUNDÄR] `Centron.Api.docuFORM/DocuFormRestApiClient.cs` - externer Signaturdienst.
+Prüfidee:      Rechnung im Signaturprozess bereitstellen; nach Signatur ist signiertes PDF anstelle des Originals im Beleg-Dokumentenverzeichnis verknüpft.
+Tracelinks:    SyRS-20, SwRS-33
+Konsolidierung: Kandidat: interne Ablage (CentronFileSystem), DocuBoard, docuFORM und DocBee decken „Dokumentenlebenszyklus“ in vier Implementierungen ab → im Zielsystem zu einer DMS-Komponente konsolidieren.
+Übernahmewürdigkeit: übernehmen - Compliance-Relevanz.
+Status:        belegt
+
+---
+
+ID:            StRS-16
+Titel:         Betrieb im eigenen Rechenzentrum und als Container/SaaS
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:        IT-Betrieb, c-entron als Hersteller
+Vorbedingung:  Zielumgebung existiert.
+Fakt:          `docker/compose/compose.yaml` startet db (MSSQL), webservice, smtp (mailcatcher), nexus als Container; Azure-Pipelines (`azure/build-pipeline.yml`, `azure/security-pipeline.yaml`, `azure/playwright-pipeline.yml`); Installationspaket `deployment/WixSharpInstaller`; Hosts `Centron.Host.Console`, `Centron.Host.WindowsService`.
+Aussage:       Das Gesamtsystem soll sowohl klassisch (Windows-Installation, Windows-Service) als auch containerisiert (Docker, Linux) deploybar bleiben.
+Ergebnis:      Auslieferung erfolgt je nach Kundenmodell als Installer oder Compose-Stack; Build/Deployment laufen automatisiert.
+Belege:
+  - [PRIMÄR]   `docker/compose/compose.yaml` (Zeilen 1-50, Services db/webservice/smtp/nexus, `Centron.Host.Console` als Linux-Startbefehl) - Containerbetrieb real implementiert.
+  - [SEKUNDÄR] `deployment/WixSharpInstaller`, `deployment/riverbird` - klassische Auslieferung.
+  - [KONTEXT]  `azure/*.yml` - CI/CD-Ketten.
+Prüfidee:      `docker compose up` in Testumgebung bringt alle vier Services; Healthchecks grün.
+Tracelinks:    SyRS-1, SyRS-25, SyRS-29, SwRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zielarchitektur SaaS.
+Status:        belegt
+
+---

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/SwRS.md

@@ -0,0 +1,709 @@
+# SwRS – Software Requirements Specification
+
+Komponenten, Datenmodelle und software-interne Regeln. Jede Anforderung referenziert ihre übergeordnete SyRS-Anforderung.
+
+---
+
+ID:            SwRS-1
+Titel:         Monolithische MSSQL-Datenbank mit deutschsprachigem Schema
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Datenbank (MSSQL, Schema dbo)
+Vorbedingung:  Schema deployed.
+Fakt:          `SSMS_DB_SCHEMA.sql` definiert 1558 Tabellen mit deutschen Fachnamen (`Kunden`, `Artikel`, `AngKopf`, `AufKopf`, `RechKopf`, `Mahnlauf`, `Filiale`); Prim keys `I3D` (IDENTITY) bzw. `ID`; keine UNIQUE- oder CHECK-Constraints im Dump auffindbar (Integrität liegt in der Anwendung).
+Aussage:       Der Software-Kern greift auf einen MSSQL-Monolithen mit historisch gewachsenem, deutsch benanntem Schema zu; Geschäftsregeln werden nicht über DB-Constraints, sondern über die Anwendungsschicht durchgesetzt.
+Ergebnis:      Schemaverständnis ist Voraussetzung für jede Migration; Constraint-Armut bedeutet Migrationsrisiko (Datenqualität muss neu abgesichert werden).
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` (1558x `CREATE TABLE [dbo].[...]`; Suche nach `ADD CONSTRAINT ... UNIQUE` und `CHECK (` ergibt 0 Treffer) - faktischer Constraint-Zustand.
+Prüfidee:      Schema-Scan im Migrationswerkzeug zählt Tabellen/Constraints und meldet fehlende Unique-Constraints als Risiko.
+Tracelinks:    SyRS-27, SyRS-23
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (Dateninhalt), Benennung/Constraint-Armut = Neuimplementierung mit Domänenmodell.
+Status:        belegt
+
+---
+
+ID:            SwRS-2
+Titel:         Belegdatenmodell: Kopf/Position/Version je Belegart
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Rechnungs-/Auftragsmodule
+Vorbedingung:  -.
+Fakt:          Schema-Tabellen `AngKopf`/`AngPos`, `AufKopf`/`AufPos`, `RechKopf`/`RechPos`, `GutKopf`/`GutPos` plus je `...Versions`-Tabellen (30 `*Versions`-Tabellen gesamt); `RechKopf.Version`-Spalte; Herkunftsreferenzen über `OriginKind`/`OriginReceiptI3D` (Belegpositionen) und `AusAuf`.
+Aussage:       Jede Belegart ist als Kopf-/Positions-/Versionstabellen-Tripel mit Herkunftsspalten implementiert; Änderungen erzeugen Versionssätze statt Überschreiben.
+Ergebnis:      Historie je Beleg ist rekonstruierbar; Belegkette ist über Herkunftsschlüssel traversierbar.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` (`CREATE TABLE [dbo].[RechKopf]` mit `Version` NOT NULL; `GutKopfVersions`, `AngKopfVersions`, `AufKopfVersions`) - real implementiertes Muster.
+Prüfidee:      Zweimaliges Speichern eines Belegs erzeugt zwei Sätze in Kopf- und Versions-Tabelle.
+Tracelinks:    SyRS-24, StRS-2
+Konsolidierung: Kandidat: je Belegart eigene Tabellensysteme (Ang/Auf/Rech/Gut/Repa/RepEingang...) - im Ziel ein generisches Belegmodell mit Typ-Diskriminator erwägen.
+Übernahmewürdigkeit: übernehmen (Konzept), Tabellenform je Art = Historie.
+Status:        belegt
+
+---
+
+ID:            SwRS-3
+Titel:          Rechnungskopftabelle RechKopf mit Zahlungs- und Mahnfeldern
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Fakturierung, Mahnwesen
+Vorbedingung:  -.
+Fakt:          `RechKopf`-Spalten u. a.: `Netto`/`Brutto`/`SummeEK` als SQL-`float`, `Waehrungs`-Gruppe (`CurrencyString`, `CurrencyFactor`, `CurrencyI3D`), `ZahlKond`/`ZahlKondID`, `FaelligAm`, `Bezahlt`, `Mahnung1Datum`–`Mahnung3Datum` (+Bearbeiter), `MahnStop`, `Mahnstufe`, `LockUser`, `Status`, `Teillieferung`, `MwStNichtAusweisbar`, `LeistungImAusland`, abweichende Liefer-/Rechnungsadressen (`LiefKund*`, `RechKund*`).
+Aussage:       Die Rechnungskopfspeicherung umfasst Zahlungsbedingungen, Währung (mit Faktor), Zahlstatus, dreistufige Mahnhistorie, Bearbeitungssperre (`LockUser`) und Steuer-Varianten; Beträge sind als Gleitkomma (`float`) abgelegt.
+Ergebnis:      Alle Mahn-/Zahlungsregeln (SyRS-7/8) greifen auf diese Felder zu; float-Beträge erfordern in der Neuimplementierung die Umstellung auf `decimal`.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[RechKopf]` (`[Netto] [float]`, `[Mahnstufe] [int]`, `[LockUser] [nvarchar](50)`) - direkte Spaltendefinitionen.
+Prüfidee:      Roundtrip-Test 0,1+0,2: Summenberechnung über float zeigt Rundungsproblem → Migration auf decimal gefordert.
+Tracelinks:    SyRS-7, SyRS-8, StRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (Feldbreite), float-Typ = veraltet (Muss korrigiert werden).
+Status:        belegt
+
+---
+
+ID:            SwRS-4
+Titel:         Filial-/Mandantentabelle mit Weichlöschung
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Administration
+Vorbedingung:  -.
+Fakt:          `Filiale` mit `MandantI3D`, `IsDefault`, `FilialStatus`, `Status`, `GeloeschtVonI3D`, `GeloeschtAm`, `Buchhaltungsnummer`, `Preisliste`, `KundenI3D`/`AnschriftI3D`/`PersonenI3D` (Filiale ist selbst als Kunde abgebildet).
+Aussage:       Filialen werden mandantengeführt mit Default-Kennzeichen, eigener Preisliste und Buchhaltungsnummer gepflegt; das Löschen erfolgt weich über `Geloescht*`-Spalten.
+Ergebnis:      Filialstamm bleibt auswertbar; Default-Filiale steuert Standardprozesse.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[Filiale]` - Spaltenganzheit.
+Prüfidee:      Filiale löschen → Zeile bleibt, `GeloeschtAm` gesetzt, nicht mehr in Auswahl.
+Tracelinks:    SyRS-23, StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-5
+Titel:         Mahnlauf-Entität als Protokollsatz je Mahnstufe
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Mahnwesen
+Vorbedingung:  Mahnlauf wird ausgeführt.
+Fakt:          `src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs`: Felder `Datum`, `BearbeiterI3D`, `RechKopfI3D`, `Mahnart`, `MahnstatusAlt`, `MahnstatusNeu`, `MahnDatum`, `MahnBearbeiterI3D`, `MahnLaufNr`, `GeloeschtDatum`, `GeloeschtBearbeiterI3D`; NHibernate-Mapping in `Centron.DAO/Mappings/TemporaryEntities/MahnlaufMaps.cs`.
+Aussage:       Jeder Mahnvorgang wird als Mahnlauf-Satz mit Alt-/Neu-Status, Bearbeiter und Laufnummer protokolliert; Stornierte Läufe werden weich gelöscht.
+Ergebnis:      Mahnhistorie je Rechnung ist vollständig rekonstruierbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Entities/Entities/DbEntities/Mahnlauf.cs` - Entitätsfelder als Datenvertrag.
+Prüfidee:      Mahnlauf starten → Satz mit MahnstatusAlt/Neu; Mahnlauf stornieren → GeloeschtDatum gesetzt.
+Tracelinks:    SyRS-8, StRS-6
+Konsolidierung: Kandidat: Mahnstatus auch als Duplikat-Felder in `RechKopf` (Mahnung1..3Datum) - ein normalisiertes Mahnjournal im Ziel.
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE (Zuordnung „TemporaryEntities“: Ist die Persistenz endgültig oder Zwischenstand? unmöglich aus Artefakt entschieden)
+
+---
+
+ID:            SwRS-6
+Titel:         Systemweiches Status-/Soft-Delete-Muster
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        alle DAO-Schichten
+Vorbedingung:  -.
+Fakt:          Schema-Indexmuster `CREATE NONCLUSTERED INDEX [..._Status]` auf fast allen Tabellen; `Status`-Spalten (z. B. `Filiale.Status`, `Mahnlauf.Status`, `ArtikelWartungsartikel.Status`); Löschspalten `GeloeschtDatum`/`GeloeschtBearbeiterI3D`/`GeloeschtVonI3D`/`GeloeschtAm`.
+Aussage:       Die Software führt Lösch- und Gültigkeitsstatus als Spaltenmuster über alle Entitäten; Fachabfragen filtern standardmäßig nach `Status`.
+Ergebnis:      Einheitliche Lösch-/Archivsemantik; Migrationswerkzeug kann nach diesem Muster migrieren.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` (z. B. `ArtikelWartungsartikel_Status`, `AnschriftSonderartikel_Status` Indizes; Löschspalten in `Mahnlauf`, `Filiale`) - flächendeckendes Muster.
+Prüfidee:      beliebige Liste: weich gelöschte Datensätze fehlen; Statusfilter-Regression.
+Tracelinks:    SyRS-23
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Prinzip; Implementierung als Weich-Löschung beibehalten.
+Status:        belegt
+
+---
+
+ID:            SwRS-7
+Titel:         Datenschicht mit NHibernate plus NamedQueries/AdoNET
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.DAO
+Vorbedingung:  -.
+Fakt:          `Centron.DAO/NHibernateConfiguration`, `Mappings`, `NamedQueries` (`NamedQueryEnums` inkl. Familie `PasswordManager.*`), `AdoNETDataAccess`, `DAOConnections`, `NHibernateLogging`; `ChangeTracking`-Ordner.
+Aussage:       Die Datenschicht kombiniert ein ORM (NHibernate Mappings) mit benannten SQL-Queries für Massen-/Spezialoperationen; Änderungsnachverfolgung ist DAO-seitig vorbereitet.
+Ergebnis:      Datenbankzugriff ist an einer Stelle gekapselt; SQL-Details sind aus dem Code auslagerbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.DAO/NHibernateConfiguration` + `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` (Nutzung `NamedQueryEnums.PasswordManager.UpdateAppUserTwoFactorAuthKey`) - reale Verdrahtung ORM+NamedQueries.
+Prüfidee:      Query-Änderung (.hbm.xml/Named Query) ohne C#-Änderung wirksam.
+Tracelinks:    SyRS-1, SwRS-8
+Konsolidierung: Kandidat: ORM- und AdoNET-Pfade für dieselbe CRUD-Funktionalität → ein Datenzugriffsparadigma im Ziel.
+Übernahmewürdigkeit: Konzept übernehmen; NHibernate-Implementierung = Migrationsentscheidung (veraltet zugunsten moderner ORM/EF).
+Status:        belegt
+
+---
+
+ID:            SwRS-8
+Titel:         BLSession/BaseBL-Kompositionsmuster der Geschäftslogik
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.BL
+Vorbedingung:  -.
+Fakt:          Alle BL-Klassen erben `BaseBL` mit `DAOSession`-Konstruktor (`TwoFactorAuthenticationBL`, `HelpdeskStatusBL`, `RiverDivoBL` ...); Zugriff via `session.GetBL<XxxBL>()` (z. B. `TicketAuthenticationHandler`, `JwtAuthController`); `BLSession` als Unit-of-Work.
+Aussage:       Die Geschäftslogik ist in Session-gebildene Business-Logik-Klassen organisationiert, die über eine Sitzungs-Fassade gemeinsam mit Transaktions-/Session-Kontext instanziiert werden.
+Ergebnis:      Konsistenz des Datenbankkontextes über ein Use-Case; Testbarkeit über Session-Mocks.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs` (`using BLSession ... session.GetBL<AuthenticationTicketBL>()`) - real genutztes Muster.
+Prüfidee:      Use-Case über zwei BLs schreibt in einer Session; Fehler → kein teilweise Commit.
+Tracelinks:    SyRS-1, SwRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: Konzept (Service-Schicht) übernehmen; Klassenhierarchie-Details = frei neu.
+Status:        belegt
+
+---
+
+ID:            SwRS-9
+Titel:         Result-Pattern statt Exceptions für Fachregeln
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        BL-APIs
+Vorbedingung:  -.
+Fakt:          Rückgabetypen `Result`, `Result<T>` mit Status Success/Error/Warning und Meldung im gesamten Code (z. B. `ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier` liefert `Result.AsError($"Aufgrund der Mahnstufe ...")`; `Result.AsWarning` in `InvoiceZugferdBL.GetZugferFormat`); Guard-Klassen für Vorbedingungen.
+Aussage:       Fachliche Ablehnungen werden als Result-Objekte mit Meldung zurückgegeben; Exceptions bleiben technischen Ausnahmen vorbehalten.
+Ergebnis:      UI und API können Ablehnungsgründe einheitlich anzeigen; Rule-Checks sind testbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10201-10214` - fachfehler als Result.Error mit Meldung.
+Prüfidee:      Regeltests behaupten Status+Meldung ohne Exception-Fänge.
+Tracelinks:    SyRS-4, SwRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - bewährtes Muster für die Neuimplementierung.
+Status:        belegt
+
+---
+
+ID:            SwRS-10
+Titel:         Konfigurierbare Ticketstatus mit Verwendungsschutz
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Verwaltung
+Vorbedingung:  Benutzer mit Rechtekontext.
+Fakt:          `HelpdeskStatusBL.GetStatus/GetClosedHelpdeskStatus/SaveHelpdeskStatus`; `DeleteHelpdeskStatus` zählt referenzierende Tickets und antwortet mit Fehler „Der Status '...' kann nicht gelöscht werden! Er wird in ... verwendet.“; Icon-Normalisierung beim Speichern.
+Aussage:       Ticketstatus sind vom Kunden konfigurierbare Datensätze; ein Abschlussstatus ist besonders ausgezeichnet; die Löschung verwendeteter Status wird softwareseitig verhindert.
+Ergebnis:      Statuskonfiguration darf Workflows nicht brechen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Support/HelpdeskStatusBL.cs:75-100` - Löschschutz mit Referenzzählung.
+Prüfidee:      Status mit 1 Referenz löschen → Fehlermeldung mit Anzahl; ohne Referenz → Löschung ok.
+Tracelinks:    StRS-3, SyRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-11
+Titel:         Artikelstammmodell mit Preis-/Einheiten-/Strukturtabellen
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Warenwirtschaft
+Vorbedingung:  -.
+Fakt:          Schema: `Artikel`, `ArtikelPreis`, `ArtikelEinheit`, `ArtikelBestand`, `ArtikelStueckliste`, `ArtikelAlternativartikel`, `ArtikelErsatzteile`, `ArtikelZubehoer`, `ArtikelBilder`, `ArtikelText`, `ArtikelSpezifikationen`/`ArtikelToSpez`, `ArtikelKalkulation`, `ArtikelVar`; BL `Warehousing/ArticleUnitHelper`, `ArticleVolumePricesBL`, `SecondStockArticleBL`.
+Aussage:       Artikel bestehen aus Basisdatensatz plus Preis-, Bestands-, Struktur- (Stückliste/Varianten) und Merkmastabellen; Zweitlager-Artikel und Staffelpreise sind eigene Konzepte.
+Ergebnis:      Vollständige Artikelsteuerung für Beschaffung, Lager und Verkauf.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` Tabellenliste `Artikel*` - Datenmodell.
+Prüfidee:      Variante (ArtikelVar) mit eigenem Preis anlegbar; Staffelpreistabelle liefert Preis je Menge.
+Tracelinks:    StRS-5, SyRS-12
+Konsolidierung: Kandidat: `ArtikelBilder`+`ArtikelDateiLinks`+Zubehör/alternativ/Ersatzteil-Tabellen - einheitliche Artikel-Relationen im Ziel.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-12
+Titel:         Lagerbestand je Artikel (`ArtikelBestand`)
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Lager/Logistik
+Vorbedingung:  -.
+Fakt:          Tabelle `ArtikelBestand` im Schema; Barcode-Handling `BarcodeBL`/`BarcodeHistoryBL`; WPF-Module `Warehousing`, `Logistic`.
+Aussage:       Das System führt Lagerbestände je Artikel (mit Historie über Barcode-Scans) als Grundlage für Verfügbarkeitsangaben in Belegen.
+Ergebnis:      Verfügbarkeit und Kommissionierung greifen auf dieselbe Bestandsführung zu.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` Tabelle `ArtikelBestand` - Bestandsdatenhaltung.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Warehousing/BarcodeHistoryBL.cs` - Scanhistorie.
+Prüfidee:      Wareneingangs-Verbuchung erhöht Bestand; Verkauf reduziert ihn (Vorbehalten/Offen separat?).
+Tracelinks:    SyRS-1, StRS-5, StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE (Bestandsbewegungsregeln - Reservierung, Sperrbestand - nicht im Detail belegt)
+
+---
+
+ID:            SwRS-13
+Titel:         UserRightsConst: zentraler Rechtekonstantenbaum
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        alle Fachmodule
+Vorbedingung:  -.
+Fakt:          `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` als verschachtelte Konstantenklassen (`UserRightsConst.Sales.Customer.Helpdesk.*`, `UserRightsConst.Admin.*`, `Controlling.Analytics.*`); `CentronRights.md` dokumentiert Teile daraus inkl. Semantik „restricting right“; Hinweis im Pfad `EntitiesWrongPlace` (verlegter Code).
+Aussage:       Alle Fachrechte sind als eindeutige Konstanten in einem benannten Baum definiert und werden client- wie serverseitig gegen dieselbe Quelle geprüft.
+Ergebnis:      Rechte sind auffindbar, dokumentierbar und reproduzierbar prüfbar.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs` - maßgebliche Konstantenquelle.
+  - [SEKUNDÄR] `CentronRights.md` - dokumentierte Teilmengen inkl. restriktiver Semantik.
+Prüfidee:      Refintegrity-Test: jede im UI/API referenzierte Konstante existiert genau einmal.
+Tracelinks:    SyRS-4, StRS-9
+Konsolidierung: Kandidat: Pfad „EntitiesWrongPlace“ signalisiert Duplikat-/Fehlablegung → Ziel: ein Identity-/Rights-Modul.
+Übernahmewürdigkeit: übernehmen (Konzept), Dateiablegung = Workaround.
+Status:        belegt
+
+---
+
+ID:            SwRS-14
+Titel:         AuthentisierungsTicket-Validierung (Ticket → Access-Token Fallback)
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        AuthenticationTicketBL, TicketBL, AccessTokenBL
+Vorbedingung:  Token im Request.
+Fakt:          `AuthenticationTicketBL.GetAuthTicketInfo(authTicket, ipAddress, apiMethod)`: zuerst `_ticketBL.GetTicket(...)`, bei Fehlschlag `_accessTokenBL.ValidateToken(token, ipAddress, apiMethod)`; Ergebnis `AuthTicketInfo` mit `AppUserI3D`, `IsConnectedThroughAccessToken`; Exception `TicketExpiredException` existiert.
+Aussage:       Die zentrale Validierungsroutine löst zuerst Sitzungs-Tickets auf und fällt auf maschinelle Access-Token zurück, wobei IP und API-Methode in die Access-Token-Prüfung einfließen.
+Ergebnis:      Beide Authentisierungsarten münden in dieselbe Nutzeridentität für die Rechteprüfung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs:25-47` - Prüfende Stelle mit Fallback-Reihenfolge.
+Prüfidee:      Ticket- und Token-Request erzeugen dieselbe `AppUserI3D`; abgelaufenes Ticket → Fail.
+Tracelinks:    SyRS-2, SyRS-3, SwRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (Konzept); duale Tokenwelt = Migrationskonsolidierung (siehe SyRS-2).
+Status:        belegt
+
+---
+
+ID:            SwRS-15
+Titel:         TOTP-Schlüsselverwaltung je AppUser
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        TwoFactorAuthenticationBL
+Vorbedingung:  AppUser vorhanden.
+Fakt:          `TwoFactorAuthenticationBL.AppUserTwoFactorAuthKeyExists`, `UpdateAppUserTwoFactorAuthKey` (Named Query `PasswordManager.UpdateAppUserTwoFactorAuthKey`), `ValidateAuthenticationPin` via `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`; Schlüssel je `AppUserI3D` in den Personenstammdaten („in der Personalverwaltung hinterlegt“ laut Fehlertext).
+Aussage:       Der TOTP-Schlüssel wird je Benutzer persistiert, kann gesetzt/geprüft werden, und das Fehlen wird mit Fachmeldung quittiert statt still zugelassen.
+Ergebnis:      2FA ist pro Benutzer aktivierbar und prüfbar; fehlender Schlüssel ist sichtbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` (Zeilen 16-54) - vollständiger Prüf-/Setzpfad inkl. Fehlermeldungen.
+Prüfidee:      Schlüssel setzen → Exists==true; PIN gegen falschen Schlüssel → „ungültig“.
+Tracelinks:    SyRS-5, StRS-9
+Konsolidierung: Kandidat: Named-Query-Familie „PasswordManager“ für 2FA und Passwortverwaltung → Identitätsmodul.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-16
+Titel:         SHA-1-Passwort-Hash-Implementierung (Legacy)
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        CryptoUtils
+Vorbedingung:  -.
+Fakt:          `CryptoUtils.CreatePasswordHash`: `SHA1.Create().ComputeHash(UTF8(pwd + salt))`, Hex-Darstellung; Salt via `RandomNumberGenerator` (kryptografisch sicher), aber Hash-Funktion schnell/SHA-1.
+Aussage:       Die aktuelle Passwortaufbereitung verwendet SHA-1 über Passwort+Salt-Konkatenation; diese Implementierung darf im Zielsystem nur noch als Lesepfad für Migrationsexistierenden dienen.
+Ergebnis:      Kein Neusetzen von SHA-1-Hashes; Migrationspfad auf Argon2/PBKDF2.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Core/CryptoUtils.cs:26-33` - exakte Implementationsstelle.
+Prüfidee:      Unit-Test gegen bekannten Vektor; Migrationsflag „Hash-Algorythmus“ pro Benutzer.
+Tracelinks:    SyRS-6, StRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: veraltet (als Speicherverfahren), Lese-/Migrationszweck befristet übernehmen.
+Status:        belegt
+
+---
+
+ID:            SwRS-17
+Titel:         Limitberechnungsalgorithmus (Netto/Brutto, Herkunftsverrechnung)
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        ReceiptBL
+Vorbedingung:  Speichern eines Kundenbelegs.
+Fakt:          `CheckIfCustomerLimitIsReached`: Modus aus `CreditLimitCalculationKind` (1=Net, sonst Gross; null/2/`CreditLimit<=0` ⇒ Prüfung deaktiviert); Aggregation über alle Belegarten via `TakesPlaceInLimitCalculation`; Abzug bereits verbrauchter Beträge des vorherigen Versionsstands und von Herkunftsbelegen (`GetLimitUsedInOriginReceipts`); Dialog `ShowCustomerLimitExceededDialog`; Fortsetzung nur mit `SaveAlthoughCustomerLimitExceeded=true`; Fortschreibung `customer.CreditLimitAvailable`.
+Aussage:       Die Kreditlimitprüfung berechnet den Limitverbrauch belegartübergreifend netto oder brutto, verrechnet Vorversion und Herkunftbelege doppelt schützend, erzwingt eine Bestätigungsdialog-Schwelle und führt den verfügbaren Rest im Kundenstamm fort.
+Ergebnis:      deterministischer, testbarer Limitwert pro Speichervorgang ohne Doppelzählungen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636-8735` - vollständige Methode inkl. Bedingungen.
+Prüfidee:      Testfallmatriz: Modus Net/Gross; Lieferschein nach Anzahlung (Herkunft) zählt nicht doppelt; Bestätigungsflag.
+Tracelinks:    SyRS-7, SwRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Exaktgeschäftsregel für Neuimplementierung.
+Status:        belegt
+
+---
+
+ID:            SwRS-18
+Titel:         Beleganlage-Gate: Recht + Mahnstufe
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        ReceiptBL, SpecificLogics je Belegart
+Vorbedingung:  Neuanlage eines Belegs.
+Fakt:          `CanUserCreateNewReceiptsAtCustomerOrSupplier`: (1) `HasRightToCreateANewReceipt(appUser)` je Belegart sonst Fehler „Der Benutzer hat nicht das Recht neue Belege ... anzulegen.“; (2) `GetCustomerOrSupplierDunningLevel<TReceipt>() > 0` und `BlockNewReceiptsDunningLevel(...) > 0 && dunningLevel >= blockOnLevel` ⇒ Fehler.
+Aussage:       Vor jeder Belegneuanlage erzwingt eine einzige Backend-Methode beide Gates (Fachrecht, Mahnstufenschwelle je Belegart) - UI-Konfiguration kann die Prüfung nicht umgehen.
+Ergebnis:      Manipulationssichere Anlagelogik für Auftrag/Angebot/Rechnung etc.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194-10222` - Prüfende Stelle.
+Prüfidee:      Direkter Aufruf ohne UI-Rechte → Fehler; DunningLevel-Schwelle grenzwertig testen (== und >).
+Tracelinks:    SyRS-8, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-19
+Titel:         Belegverlauf (Receipt Progression) mit Größenbegrenzung
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        ReceiptProgressionBL
+Vorbedingung:  Beleg-Objektreferenz (objectI3D/objectKind).
+Fakt:          `ReceiptProgressionBL.GetReceiptProgression(objectI3D, objectKind, limit)` mit `MaxReceiptProgressionSize`; Rückgabe `ReceiptProgressionInfoDTO`-Liste; `GetDirectoryI3DsFromReceiptProgression` für Dokumentenaufrufe.
+Aussage:       Das System stellt den vollständigen Belegfolgepfad eines Objekts (Angebot→…→Rechnung, inkl. Gutschriften) begrenzt auf eine Maximaltiefe bereit und leitet Dokumentverzeichnisse daraus ab.
+Ergebnis:      Sachbearbeiter sieht Proesskette eines Vorgangs ohne unbegrenzte Abfragen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` (Methoden_signaturen inkl. limit/MaxReceiptProgressionSize) - implementierte Begrenzung.
+Prüfidee:      Kette mit 20 Stufen → genau 20 Einträge, Reihenfolge korrekt.
+Tracelinks:    StRS-2, SyRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE (konkreter Zahlenwert von MaxReceiptProgressionSize nicht extrahiert; Sortier-/Filterlogik nicht im Detail gelesen)
+
+---
+
+ID:            SwRS-20
+Titel:         Tokenbasierte Kundenänderungen an Web-Belegen
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Web-Kunde, ReceiptBL
+Vorbedingung:  Beleg mit Token/Änderungsanfrage-Bezug.
+Fakt:          `ReceiptBL.GetWebReceiptItemChangeRequests(filter)`, `ChangeWebReceiptPurchaseOrderNumber(token, ...)` (Zeile 5936), `ChangeWebReceiptAddress(token, ReceiptAddressKind, ...)` (Zeile 6116) - Änderungsvorgänge gegen Token statt gegen vollen Benutzerkontext.
+Aussage:       Das System erlaubt authentifizierte Portaländerungen (Liefer-/Rechnungsadresse, Bestellnummer) ausschließlich über gültige Belegtokens und protokolliert sie als Änderungsanfragen für den Sachbearbeiter.
+Ergebnis:      Externe Änderung ohne vollen Schreibzugriff; interne Freigabe bleibt erhalten.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5894-6116` - Token-Methoden inkl. Filtertyp.
+Prüfidee:      Ungültiger Token → Fehler; gültiger Token → Änderung landet als Change-Request, nicht als direkte Änderung.
+Tracelinks:    SyRS-15, StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-21
+Titel:         ZUGFeRD-/XRechnung-Formatauswahl und Import
+Ebene:         SwRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        InvoiceZugferdBL, ZugferdParseBL
+Vorbedingung:  Kunde mit Exportprofil.
+Fakt:          `InvoiceZugferdBL.GetZugferFormat(bool? exportZUGFeRD, ReceiptInvoiceSettingsDTO settings)` → `ZugferdKind.ZUGFeRD_1_0` (Warnung „Zugferd is deactivated for customer“), sonst `settings.ActiveZugferdInterface` (Default `ZugferdKind.ZUGFeRD_XInvoice_3_0_1`); Datei `InvoiceZugferdBL.Zugferd10.cs` (Alt-Parser), `ZugferdParseBL.cs`, Gateway `ZUGFeRD21_Extended`, `ZugferdImportController`.
+Aussage:       Format und Version der elektronischen Rechnung werden pro Konfiguration aufgelöst und gecacht; Altformate bleiben importierbar.
+Ergebnis:      Konformer Ausgang nach aktuellem Standard, Importhistorie bleibt lesbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-100` - Formatentscheidung + Cache-Key.
+Prüfidee:      Umstellung `ActiveZugferdInterface` → Ausgang wechselt Format ohne Codeeingriff.
+Tracelinks:    SyRS-9, StRS-6
+Konsolidierung: Kandidat: `Zugferd10`-Altcode vs. XInvoice - Altimport beibehalten, Ausgang nur aktuell.
+Übernahmewürdigkeit: Ausgang übernehmen; ZUGFeRD-1.0-Ausgang veraltet.
+Status:        belegt
+
+---
+
+ID:            SwRS-22
+Titel:         ebInterface-4.3-Export mit Vorvalidierung
+Ebene:         SwRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        EbInterfaceLogic
+Vorbedingung:  österreichischer Rechnungsempfänger.
+Fakt:          `EbInterfaceLogic.GenerateFile(ReceiptInfo)`: `ValidateValues` vor Dokumenterzeugung; festes Namespace-`http://www.ebinterface.at/schema/4p3/`; Datums-/Betragsformate (en-US-Kultur für Zahlen).
+Aussage:       Der ebInterface-Export validiert Rechnungswerte vor der XML-Erzeugung gegen die 4.3er-Spezifikation und nutzt stabile Formatkonstanten.
+Ergebnis:      Abweisungsarme AT-E-Rechnungen.
+Belege:
+  - [PRIMÄR]   `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` (`_ebNamespace`, `ValidateValues`, `DATEFORMAT`, `AMOUNTFORMAT`) - implementierte Validierung.
+Prüfidee:      Rechnung ohne UID → Fehler vor Ausgabe; positives XML validiert gegen Schema.
+Tracelinks:    SyRS-9, StRS-6
+Konsolidierung: Kandidat: neben ZUGFeRD zweiter E-Rechnungs-Provider → gemeinsames E-Rechnungs-Subsystem.
+Übernahmewürdigkeit: übernehmen (AT-Markt).
+Status:        belegt
+
+---
+
+ID:            SwRS-23
+Titel:         Gateway-Kapselung: XSD-gestützte Bestellnachrichten
+Ebene:         SwRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Centron.Gateway
+Vorbedingung:  -.
+Fakt:          `Centron.Gateway/Concerto/ConcertoOrder.cs` + `ConcertoOrder.xsd` ( Serialisierung via XSD), `OpenTrans`/`OpenTrans1_0` (zwei Versionen), `Import`/`Export`-Ordner, `MspCollector`.
+Aussage:       Ausgehende/nachrichtenförmige Datenaustausche werden im Gateway-Layer über typisierte, schema-validierte Modelle abgebildet; Versionsverzweigungen (OpenTrans 1.0/aktuell) sind gekapselt.
+Ergebnis:      Partnerformate ohne Einfluss auf Fachlogik austauschbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - Schema als Vertragsanker.
+  - [SEKUNDÄR] `OpenTrans`/`OpenTrans1_0` Nebeneinander - Versionskapselung.
+Prüfidee:      Serialisierte Bestellung gegen XSD validieren; ältere OpenTrans-Version testbar.
+Tracelinks:    SyRS-11, StRS-4
+Konsolidierung: Kandidat: OpenTrans 1_0 Alt +aktuell, Concerto +EDI_* Formate - ein Connector-SDK.
+Übernahmewürdigkeit: Konzept übernehmen; Altversionen = veraltet.
+Status:        belegt
+
+---
+
+ID:            SwRS-24
+Titel:         Temporäres Entity-Mapping für Mahnlauf
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.DAO/Mappings/TemporaryEntities
+Vorbedingung:  -.
+Fakt:          `MahnlaufMaps.cs` liegt im Ordner `TemporaryEntities`, obwohl `Mahnlauf` eine Dauerentität ist; reguläre Mappings liegen in `Centron.DAO/Mappings`.
+Aussage:       Das Mapping des Mahnlaufs ist provisorisch abgelegt; die finale Persistenzstrategie des Mahnjournals ist im Bestand nicht eindeutig entscheidbar.
+Ergebnis:      Bei Migration ist die Mahnlauf-Historie gezielt zu verifizieren.
+Belege:
+  - [SEKUNDÄR] `src/backend/Centron.DAO/Mappings/TemporaryEntities/MahnlaufMaps.cs` (Ordnerbezeichnung) - Ablageklassifikation „temporär“.
+Prüfidee:      Zählen der Mahnlauf-Sätze vor/nach Migrationslauf.
+Tracelinks:    SwRS-5, SyRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - provisorische Ablage gezielt auflösen.
+Status:        HYPOTHESE (Warum „Temporary“? Restmigration oder Zwischenlösung - Beleg fehlt)
+
+---
+
+ID:            SwRS-25
+Titel:         DAO-seitiges Change-Tracking
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Centron.DAO/ChangeTracking
+Vorbedingung:  -.
+Fakt:          Ordner `Centron.DAO/ChangeTracking`; Kommentar im `ReceiptBL`-Limitpfad: „Change-tracking should do the trick here“ (zur Nachführung von `CreditLimitAvailable`).
+Aussage:       Änderungen an persistierten Entitäten werden auf DAO-Ebene nachverfolgt und dienen als Grundlage für Protokollierung und abgeleitete Feldaktualisierung.
+Ergebnis:      Änderungsprotokolle speisen Revision und Statistik ohne manuelle Logging-Aufrufe.
+Belege:
+  - [SEKUNDÄR] `src/backend/Centron.DAO/ChangeTracking` (Ordner), `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs` (Kommentar zur Nutzung) - Mechanismus vorhanden.
+Prüfidee:      Feldänderung → Tracking-Eintrag ohne BL-seitiges Logging.
+Tracelinks:    SyRS-24, SwRS-7
+Konsolidierung: Kandidat: ChangeTracking + `ReceiptLogBL` + Nexus-Historie - ein Audit-Abo.
+Übernahmewürdigkeit: übernehmen
+Status:        HYPOTHESE (funktionsumfang der Tracking-Tabellen nicht aus Artefakten belegt)
+
+---
+
+ID:            SwRS-26
+Titel:         In-Memory-Logging-Ziel für Live-Diagnose
+Ebene:         SwRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        Centron.Common/Logging
+Vorbedingung:  Logging initialisiert.
+Fakt:          `InMemoryTarget.cs`/`InMemoryLogging.cs`/`LogEntry.cs` in `Centron.Common/Logging`; Nexus zeigt Log-Kategorien in Systeminfo (Changelog).
+Aussage:       Das System puffert Logeinträge speicherintern, um sie in UI-Diagnosmasken ohne Datei-/DB-Lesezugriff darzustellen.
+Ergebnis:      Support-Diagnosgespräche mit Live-Logs aus der Sitzung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Common/Logging/InMemoryTarget.cs` - implementierter Appender.
+Prüfidee:      Fehler provozieren → Eintrag sofort in Systeminfo sichtbar; Ringpuffer-Grenze (Größe?) testen.
+Tracelinks:    SyRS-28
+Konsolidierung: Kandidat: InMemory-Log vs. NLog-Datei (LogManager) - zentrale Logging-Pipeline.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-27
+Titel:         WPF-Modulsystem mit AppModuleControllern
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Centron.WPF.UI
+Vorbedingung:  Client gestartet.
+Fakt:          29 Modulordner in `Centron.WPF.UI/Modules`; je Modul `*AppModuleController.cs` + `View.xaml` + `ViewModel.cs` (Beispiel `Finances/Dunning/DunningOverviewAppModuleController.cs`); `Centron.WPF.UI.Extension` mit `Mvvm`, `Modules`, `Extensibility`.
+Aussage:       Die Desktop-Oberfläche ist modular nach Fachgebieten aufgebaut; jedes Fachmodul wird über einen Modulcontroller mit eigenem View/ViewModel-Lifecycle eingebunden.
+Ergebnis:      Funktionen sind einzeln aktivierbar; Neuimplementierung kann Modul-und Rollenmodell direkt übernehmen.
+Belege:
+  - [PRIMÄR]   `src/centron/Centron.WPF.UI/Modules/Finances/Dunning/DunningOverviewAppModuleController.cs` - Modulcontroller-Pattern real.
+  - [SEKUNDÄR] Modulverzeichnisliste (Administration … Warehousing) - Funktionsbreite.
+Prüfidee:      Modul ohne Berechtigung öffnet keine Navigation/View.
+Tracelinks:    SyRS-1, SyRS-4, StRS-9, StRS-12, SwRS-30
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (modulare Struktur), WPF-Technologie = Client-Austausch gegen Web.
+Status:        belegt
+
+---
+
+ID:            SwRS-28
+Titel:         Absicherung der Echtzeit-Hubs mit Secret Key
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        SignalR-Hubs
+Vorbedingung:  Hub-Konfiguration.
+Fakt:          `RealTimeServices/SecretKeyRequirement.cs` und `SecretKeyHandler.cs` (Handler prüft Secret beim Hub-Zugriff).
+Aussage:       Der Aufbau von SignalR-Verbindungen ist nur mit gültigem Secret Key zulässig.
+Ergebnis:      Keine anonymen Echtzeit-Abonnements von Benachrichtigungen/Chat.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs` - durchgesetzte Prüfung.
+Prüfidee:      Hub-Connect ohne Header/Query-Secret → Handshake-Fehler.
+Tracelinks:    SyRS-16, SyRS-21
+Konsolidierung: Kandidat: Secret-Key-Pfad neben Ticket/JWT - einheitliche Hub-Authentifizierung.
+Übernahmewürdigkeit: Konzept übernehmen; Secret-Key-Mechanik = Workaround.
+Status:        belegt
+
+---
+
+ID:            SwRS-29
+Titel:         IndexBuilder mit deutschem Analyzer
+Ebene:         SwRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Performance-Effizienz
+Akteur:        IndexSearch-Subsystem
+Vorbedingung:  -.
+Fakt:          `IndexSearch/IndexBuilder.cs`, `GermanAnalyzer.cs`, `Indexes/TicketFulltextIndex.cs`, `ObjectIndexingFailedException`.
+Aussage:       Die Volltextindizes werden dediziert aufgebaut und mit sprachspezifischer Analyse (Deutsch) versehen; Indexierungsfehler werden als typisierte Exception behandelt.
+Ergebnis:      Sprachlich sinnvolle Suchtreffer; robuste Index-Pipeline.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` - implementierte Sprachanalyse.
+Prüfidee:      Lemmata-Test („bestellungen“→„bestellung“); fehlgeschlagene Indexierung zählt hoch, aber reißt Suche nicht ab.
+Tracelinks:    SyRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-30
+Titel:         Wiederverwendbare Steuerelements-Bibliothek Centron.Controls
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        WPF-Clients (Desktop, ConnectionManager)
+Vorbedingung:  -.
+Fakt:          `src/shared/Centron.Controls` mit 40+ Funktionsordnern (PositionGrid, MailTemplates, PasswordManager, Telephony, PdfScanning, ExcelExport, TaskManagement, CustomerManagement, EmailTemplate, FileViewer, Webservice …) + `Centron.Controls.Preview`; `Centron.Core` (Mvvm, GoogleAuthenticator, TotpAuth, Threading, PdfScanning).
+Aussage:       UI-Funktionsbausteine und Kernutils (MVVM, TOTP, Threading, PDF) sind in gemeinsamen Bibliotheken gekapselt und werden von mehreren Hosts genutzt.
+Ergebnis:      Konsistente Bedienung; Migrationsobjekt klar abgrenzbar.
+Belege:
+  - [SEKUNDÄR] Ordnerbestand `src/shared/Centron.Controls/*` - Bausteinbibliothek real in Nutzung.
+Prüfidee:      Steuerelement in zwei Hosts mit gleicher Konfiguration testen.
+Tracelinks:    SyRS-1, StRS-10, StRS-15, SwRS-27
+Konsolidierung: Kandidat: Controls- und Nexus-Komponenten doppeln Dialoge (Mail-Editor, Datei-Viewer) → geteilte Komponenten-Bibliothek im Web-Stack.
+Übernahmewürdigkeit: übernehmen (Pattern), konkrete Controls = WPF-Sonderbau.
+Status:        belegt
+
+---
+
+ID:            SwRS-31
+Titel:         Vertragsbewertung Alt (ContractEvaluationOld) neben Neu (ContractEvaluation2)
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsabrechnung
+Vorbedingung:  Verträge im Bestand.
+Fakt:          Zwei parallele Modulordner `Centron.WPF.UI/Modules/Finances/ContractEvaluationOld` und `ContractEvaluation2` in derselben Anwendung.
+Aussage:       Die Vertragsbewertung existiert in zwei Implementierungsgenerationen gleichzeitig; der Migrationszustand (welcher Bestand nutzt welche Version?) ist aus dem Code nicht eindeutig ableitbar.
+Ergebnis:      Nur die aktuelle Generation ist in das Zielsystem zu übernehmen; Altbestand erfordert eine Datenüberführungsprüfung.
+Belege:
+  - [SEKUNDÄR] Verzeichnisse `Modules/Finances/ContractEvaluationOld`, `Modules/Finances/ContractEvaluation2` - Nebeneinander im Produktivbaum.
+Prüfidee:      Navigationsanalyse: welcher Einstieg führt noch zur Old-Version?
+Tracelinks:    SyRS-14, SyRS-22, StRS-7
+Konsolidierung: Kandidat: ContractEvaluationOld/2 = dieselbe Funktion zweier Stände; Old löschen.
+Übernahmewürdigkeit: veraltet (Old), übernehmen (2).
+Status:        HYPOTHESE (Nutzungsverteilung Alt/Neu unbekannt)
+
+---
+
+ID:            SwRS-32
+Titel:         Kunden-Filialzuordnung und Kundenkostenstellen
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Adressstamm
+Vorbedingung:  -.
+Fakt:          `Accounts/CustomerToBranchBL.cs`, `Accounts/CustomerCostCenterBL.cs`, `AccountTypeBL.cs`, `AccountAddressContactBL.cs`; Tabellen `KundeToKonzern`, `AbweichendeAnschrift`.
+Aussage:       Kunden können mehreren Filialen zugeordnet und um Kostenstellen/Konzernstrukturen sowie abweichende Anschriften erweitert werden.
+Ergebnis:      Beleg-/Auswertungslogik kann Filial- und Kostenstellenbezug nutzen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Accounts/CustomerToBranchBL.cs` + `SSMS_DB_SCHEMA.sql` (`KundeToKonzern`, `AbweichendeAnschrift`) - Modell + Pflege-BL.
+Prüfidee:      Kunde zwei Filialen zuordnen; Beleg zeigt je Filialcontext korrekte Konditionen.
+Tracelinks:    SyRS-23, StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-33
+Titel:         Client-Konfigurations-/Verbindungsverwaltung ConnectionManager
+Ebene:         SwRS
+Typ:           nicht-funktional
+Qualitätsmerkmal:
+Akteur:        IT-Betrieb
+Vorbedingung:  Client-Installation.
+Fakt:          `c-entron.misc.ConnectionManager` mit Views `ConnectionManagerView`, `HardwareIdView`, `LicenseView`, `TwoFactorAuthTestView`, `SQLServerCheckTool`, `AdditionalServiceViewModel`; Compose mountet `WebServiceConfig.xml`.
+Aussage:       Das System stellt ein Konfigurationswerkzeug bereit, mit dem Zielverbindungen (Webservice/DB), Hardware-ID/Lizenz und Zusatzdienste geprüft und gesetzt werden.
+Ergebnis:      Installation/Diagnose ohne manuelle Config-Eingriffe.
+Belege:
+  - [SEKUNDÄR] View/ViewModel-Namen in `c-entron.misc.ConnectionManager` + `docker/compose/compose.yaml` (WebServiceConfig.xml) - Funktionsumfang benannt.
+Prüfidee:      SQL-Servercheck gegen Testinstanz; Config-Änderung übernimmt Client ohne manuellen Neustart (prüfen).
+Tracelinks:    SyRS-25, SyRS-2
+Konsolidierung: Kandidat: ConnectionManager vs. zentrale Server-Konfiguration (`ConfigurationController.cs`) - ein Konfigurations-Hub.
+Übernahmewürdigkeit: übernehmen (Diagnosegedanke); Desktop-Tool = Web-Admin counterpart.
+Status:        HYPOTHESE (Prüftiefe des SQLServerCheckTool nicht belegt)
+
+---
+
+ID:            SwRS-34
+Titel:         Automatische Versionsableitung (Nerdbank.GitVersioning)
+Ebene:         SwRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Build
+Vorbedingung:  Git-Repository.
+Fakt:          `version.json` (Nerdbank.GitVersioning-Schema, `version: 2.0.2611-alpha`, cloudBuild enabled); Changelog-Versionsserien (`2409.x`) im Nexus.
+Aussage:       Die Produktversion wird aus dem Versionsverwaltungszustand automatisch abgeleitet; Buildnummern sind reproduzierbar.
+Ergebnis:      Nachvollziehbare Auslieferungen je Build.
+Belege:
+  - [PRIMÄR]   `version.json` (Schema-URL Nerdbank.GitVersioning, Version 2.0.2611-alpha) - eingerichtetes Werkzeug.
+Prüfidee:      Build-Assembly-Version == berechnete GitVersion.
+Tracelinks:    SyRS-29, StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SwRS-35
+Titel:         Massenaktualisierung von Fachdaten
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter/Administration
+Vorbedingung:  Auswahl von Zielobjekten.
+Fakt:          Dedizierte BL `src/backend/Centron.BL/MassUpdate` und WPF-Modul `src/centron/Centron.WPF.UI/Modules/Massenupdates` (Modulordner und BL-Ordner existieren nebeneinander).
+Aussage:       Das System soll Massenänderungen an Fachobjekten (Stammdaten/Belege) über eine geführte Funktion bündeln.
+Ergebnis:      Pflegeaufwand für Serienänderungen sinkt; Änderungen bleiben protokolliert (zu prüfen).
+Belege:
+  - [SEKUNDÄR] `src/backend/Centron.BL/MassUpdate` + `src/centron/Centron.WPF.UI/Modules/Massenupdates` - eigene BL+Modul für „Massenupdates“ benennen die Funktion.
+Prüfidee:      Sammeländerung an mehreren Artikeldatensätzen; Anzahl geänderter Sätze == Auswahl.
+Tracelinks:    SyRS-1, StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Standard-ERP-Pflegefunktion.
+Status:        HYPOTHESE (umgeschaltbare Felder/Objektarten und Berechtigungsanbindung aus Ordnernamen nicht ableitbar)
+
+---

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/SyRS.md

@@ -0,0 +1,631 @@
+# SyRS – System Requirements Specification
+
+Systemverhalten, Schnittstellen, Sicherheits- und Performance-Anforderungen. Ebene über den Anforderungen der SwRS.
+
+---
+
+ID:            SyRS-1
+Titel:         Dreischichtige Client-Server-Architektur mit zentralem Webservice
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        WPF-Client, Nexus-Web, c-entron Webservice (Centron.Host), MSSQL
+Vorbedingung:  Webservice Instanz läuft (Port 4321 im Compose-Stack).
+Fakt:          `docker/compose/compose.yaml` definiert Services `db` (MSSQL), `webservice` (`Centron.Host.Console`), `nexus` (`CentronNexus.Host`); WPF-Client greift über `Centron.WebServices.Core/RestRequests` auf REST-Endpunkte von `Centron.Host` zu; Host bietet Swagger/API-Versionierung (`RegisterCentronApiVersioning.cs`, `RegisterCentronSwagger.cs`).
+Aussage:       Das System soll alle Fachfunktionen zentral in einem Webservice bündeln, auf den Desktop-Client (WPF) und Web-Frontends (Nexus/Blazor) über versionierte REST-Schnittstellen zugreifen; die Datenbank (MSSQL) wird ausschließlich vom Webservice erreicht.
+Ergebnis:      Neue Frontends können ohne Geschäftslogik-Änderung angebunden werden; API-Verträge sind versioniert.
+Belege:
+  - [PRIMÄR]   `docker/compose/compose.yaml` - reale Topologie: nur webservice hat DB-Abhängigkeit (`depends_on: db`), Nexus hängt am Webservice.
+  - [SEKUNDÄR] `src/webservice/Centron.Host/Logic/RegisterCentronApiVersioning.cs` - API-Versionierung eingerichtet.
+  - [SEKUNDÄR] `src/shared/Centron.WebServices.Core/RestRequests` - Client-seitiger REST-Layer.
+Prüfidee:      Nexus ohne direkten DB-Zugriff deploybar (Environment zeigt keine Connectionstring-Abhängigkeit); gleiche Business-Regel (Kreditlimit) greift über Client und API.
+Tracelinks:    StRS-1, StRS-16, SyRS-2, SwRS-8, SwRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - genau die Zielarchitektur der Neuimplementierung.
+Status:        belegt
+
+---
+
+ID:            SyRS-2
+Titel:         Authentisierung über Authentifizierungs-Tickets und Access-Token
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Webservice (TicketAuthenticationHandler), Client, Drittsystem
+Vorbedingung:  Client hat Login durchlaufen bzw. Access-Token erhalten.
+Fakt:          `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs`: extrahiert Token aus Request, validiert über `AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod)` (erst ConnectionTicket, dann Access-Token-Fallback mit IP- und API-Methodenprüfung) und setzt Claims (`UserIdentifier`, `AuthenticationTypeIdentifier`).
+Aussage:       Das System soll jede API-Anfrage gegen ein serverseitig verwaltetes Ticket oder einen Access-Token authentisieren und dabei Client-IP und aufgerufene Methode in die Validierung einbeziehen.
+Ergebnis:      Unbekannte/abgelaufene Tokens führen zu Authentisierungsfehler; der Nutzer ist einer AppUser-Identität zugeordnet.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Host/AspNetCore/TicketAuthenticationHandler.cs` (`HandleAuthenticateAsync`, `ValidateTicketOrAccessToken` mit ipAddress/apiMethod-Parametern) - durchgesetzte Prüfung.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/AuthenticationTicketBL.cs:25-47` - Ticket-zuerst-, Access-Token-Fallback-Logik.
+Prüfidee:      Request ohne Ticket → 401 „No authentication ticket found“; Ticket fremder IP → Validierungsfehlertest gemäss Access-Token-Konfiguration.
+Tracelinks:    StRS-9, SyRS-3, SyRS-4, SwRS-14
+Konsolidierung: Kandidat: Ticket-Login (interne Clients), Access-Token (Maschine-Maschine) und WebAccount-Login (Nexus) sind drei Authentisierungswege; im Zielsystem auf ein Token-Konzept (OAuth2/OIDC) konsolidieren.
+Übernahmewürdigkeit: übernehmen (Konzept), die Ticket-Implementierung selbst ist ein Migrationskandidat (Workaround-charakter).
+Status:        belegt
+
+---
+
+ID:            SyRS-3
+Titel:         Client-Anmeldung per JWT-Bearer mit Anwendungsprüfung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        WPF-Client (Login), Authentifikator
+Vorbedingung:  Client-Installation besitzt Application-Guid; Nutzer kennt Zugangsdaten.
+Fakt:          `JwtAuthController` (`[Route("jwt")]`, `POST jwt/login`): verlangt JwtBearer-Principal, ermittelt `ApplicationGuidHelper.GetDecryptedApplicationGuid(...)` je Applikation, übergibt `JwtLoginRequest` (Device, AppVersion) an `AuthenticatorFactory.GetAuthenticator(...)`.
+Aussage:       Das System soll die Client-Anmeldung über einen JWT-Login-Endpunkt abwickeln, dabei die aufrufende Anwendung (Application-Guid), Gerät und App-Version verifizieren und die eigentliche Prüfung an eine austauschbare Authentifikator-Implementierung delegieren.
+Ergebnis:      Nur registrierte Anwendungen erhalten ein Sitzungsticket; Anmeldeversuche sind mit Gerät/AppVersion protokolliert.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs` (`LoginWithBearer`, Prüfung `ClaimsIdentity.IsAuthenticated`, Application-Guid-Abgleich) - durchgesetzte Prüfkette.
+Prüfidee:      Login mit unbekanntem Application-Parameter → BadRequest „Application not found.“; Login ohne Bearer-Token → 401.
+Tracelinks:    StRS-9, SyRS-2, SyRS-5, SyRS-25, SwRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Muster für Mandanten-/App-Registrierung im SaaS.
+Status:        belegt
+
+---
+
+ID:            SyRS-4
+Titel:         Deklarative Rechteprüfung in der Web-API (401/403)
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        API-Consumer, Authorization-Filter
+Vorbedingung:  Anfrage ist authentisiert (SyRS-2/3).
+Fakt:          `Centron.Controllers/Authorization/` implementiert `AuthorizeUserRightAttribute`, `AuthorizeAnyUserRightAttribute`, `AuthorizeUserRightsAllAttribute`/`AuthorizeAllUserRightsAttribute` sowie `AuthorizeCentronHostedAttribute`; README dokumentiert Filter-Ausführung vor der Action und HTTP-Codes 401 (nicht authentisiert) / 403 (Recht fehlt); einschränkende Rechte laut `CentronRights.md` (nur eigene, nur eigene Filiale/Abteilung).
+Aussage:       Das System soll jede API-Operation deklarativ an Fachrechte binden (einzeln, ODER-Verknüpfung, UND-Verknüpfung, Hosted-Umgebung) und fehlende Rechte mit 403 ablehnen; daten einschränkende Rechte sind zusätzlich in den Abfragen umzusetzen.
+Ergebnis:      Funktions- und Datenumfang jeder API-Antwort entsprechen dem Rollenbild des Nutzers.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs` - durchgesetzte Prüfung im Authorization-Filter.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Authorization/README.md` - dokumentierte 401/403-Semantik und Kombinierbarkeit.
+  - [SEKUNDÄR] `CentronRights.md` (restricting rights) - Datenfilter-Konzept.
+Prüfidee:      Parameterisierter Rechte-Matrix-Test: je Controller-Endpunkt mit/ohne Recht aufrufen; erwartete Codes 200/403.
+Tracelinks:    StRS-9, StRS-12, SwRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Must-have für Mehrmandanten-SaaS.
+Status:        belegt
+
+---
+
+ID:            SyRS-5
+Titel:         Zwei-Faktor-Authentisierung (TOTP) für Benutzer
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Benutzer, Authentisator-App, Webservice
+Vorbedingung:  Dem Benutzer ist ein TwoFactorAuthKey hinterlegt.
+Fakt:          `TwoFactorAuthenticationBL.ValidateAuthenticationPin` prüft PIN gegen den je AppUser gespeicherten `TwoFactorAuthKey` über `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin`; Fehler: „Ihrem Benutzer ist kein Zwei-Faktor Schlüssel … hinterlegt!“, „Die eingegebene PIN ist ungültig!“; `TwoFactorAuthController` in der API; `ConnectionManager` besitzt `TwoFactorAuthTestView`.
+Aussage:       Das System soll für Benutzer mit hinterlegtem TOTP-Schlüssel die Anmeldung um eine zeitbasierte Einmal-PIN erweitern und die PIN serverseitig gegen den Benutzerschlüssel validieren.
+Ergebnis:      Ohne gültige TOTP-PIN keine Anmeldung; Benutzer ohne Schlüssel bekommt klare Meldung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:43-54` (`ValidateAuthenticationPin`) - durchgesetzte Prüfung.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs` - API-Zugang.
+Prüfidee:      Abgelaufene TOTP-PIN (>30 s) wird abgelehnt; PIN-Validierung ohne hinterlegten Schlüssel liefert definierten Fehler.
+Tracelinks:    StRS-9, SwRS-15, SwRS-16
+Konsolidierung: Kandidat: `PasswordManager`/`PasswordManagementArea`-BL und `TwoFactorAuthenticator`-BL nutzen dieselbe Named-Query-Familie (`NamedQueryEnums.PasswordManager.*`) → im Zielsystem eine Identitätskomponente.
+Übernahmewürdigkeit: übernehmen - Sicherheitsstandard.
+Status:        belegt
+
+---
+
+ID:            SyRS-6
+Titel:         Passwort-Hashing (SHA-1 + Salt) – Migrationsrisiko
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:        Authentifizierung
+Vorbedingung:  Benutzer legt Passwort an / ändert es.
+Fakt:          `Centron.BL/Core/CryptoUtils.cs`: `CreateSalt(size)` (Base64 `RandomNumberGenerator`), `CreatePasswordHash(pwd, salt)` = SHA-1 über `pwd + salt`, Hex-Ausgabe; kein langsamer Key-Derivation-Algorithmus (kein PBKDF2/BCrypt/Argon2 im Core).
+Aussage:       Das Zielsystem soll Passwörter mit einem modernen, rechenintensiven Hashverfahren (z. B. Argon2id/PBKDF2) speichern; die bestehende SHA-1+Salt-Darstellung dient nur als Kompatibilitätsformat für die Migration.
+Ergebnis:      Migrierte Passwörter werden bei erster Anmeldung transparent hochgehängt; Neuanlagen nutzen das moderne Verfahren.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Core/CryptoUtils.cs:26-33` (`SHA1.Create()` über `pwd + salt`) - Ist-Implementierung der durchgesetzten Hashbildung.
+Prüfidee:      Migrations-Unit-Test: alter SHA1-Hash + korrektes Passwort → Login ok und Hash auf neuen Algorithmus gesetzt.
+Tracelinks:    StRS-9, SyRS-5, SwRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround (SHA1-Verfahren historisch) - Verfahren ersetzen, Anforderung (Gespeicherte Passwörter) bleibt.
+Status:        belegt
+
+---
+
+ID:            SyRS-7
+Titel:         Kreditlimit-Prüfung beim Speichern kundenbezogener Belege
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Beleg-Save-Logik, Sachbearbeiter
+Vorbedingung:  Kunde hat `CreditLimit > 0` und Limitberechnungsart (Netto/Brutto) ungleich deaktiviert.
+Fakt:          `ReceiptBL.CheckIfCustomerLimitIsReached` (Zeile 8636): summiert verbrauchtes Limit über alle belegarten (`TakesPlaceInLimitCalculation`), verrechnet Herkunftbelege, vergleicht mit `customer.CreditLimit`, setzt `ShowCustomerLimitExceededDialog` mit Differenztext „Das Limit von … wurde um … überschritten.“; speichert `CreditLimitAvailable`; Überspringbar via `SaveAlthoughCustomerLimitExceeded` (Vier-Augen-Bestätigung im UI).
+Aussage:       Das System soll beim Speichern jedes kundenbezogenen Belegs prüfen, ob das Kreditlimit des Kunden (netto oder brutto je Kundeneinstellung) durch alle offenen Belege ausgeschöpft wäre, und den Speichervorgang nur nach bewusster Bestätigung des Bearbeiters fortlassen.
+Ergebnis:      Limitüberschreitung ist sichtbar, bestätigungspflichtig und im Kundenstamm (`CreditLimitAvailable`) nachgeführt.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:8636-8692` - Prüfende Stelle inkl. Bedingung und Dialogsetzung.
+Prüfidee:      Kunde Limit 1000, offene Belege 900, neuer Beleg 200 → Dialog mit Differenz 100; ohne Bestätigung wird nicht gespeichert.
+Tracelinks:    StRS-2, StRS-6, SwRS-3, SwRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Zahlungsziel-Risikomanagement.
+Status:        belegt
+
+---
+
+ID:            SyRS-8
+Titel:         Belegsperre ab Mahnstufe des Kunden/Lieferanten
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Beleg-Neuanlage-Logik, Buchhaltung
+Vorbedingung:  Für Kunde/Lieferant existiert Mahnstufe > 0; Belegart hat Sperrkonfiguration (`BlockNewReceiptsDunningLevel`).
+Fakt:          `ReceiptBL.CanUserCreateNewReceiptsAtCustomerOrSupplier` (Zeile 10194ff.): prüft Rechts-Berechtigung der Belegart und danach `GetCustomerOrSupplierDunningLevel<TReceipt>`; bei `dunningLevel >= blockOnLevel` Fehler „Aufgrund der Mahnstufe darf kein neuer Beleg vom Typ … angelegt werden.“; Mahnstufenfelder in `RechKopf` (`Mahnstufe`, `Mahnung1..3Datum`, `MahnStop`).
+Aussage:       Das System soll die Neuanlage von Belegen je Belegart sperren, sobald der Geschäftspartner eine konfigurierte Mahnstufe erreicht hat, und die Sperre vor jeder Anlage (nicht nur im UI) durchsetzen.
+Ergebnis:      Zahlungsverzügige Kunden können keine neuen Aufträge/Rechnungen auslösen; Verstoßversuch liefert definierte Fehlermeldung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10194-10218` (`CanUserCreateNewReceiptsAtCustomerOrSupplier`) - Prüfende Stelle mit Bedingung `dunningLevel >= blockOnLevel`.
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `RechKopf.Mahnstufe`/`MahnStop` - persistierte Basis der Prüfung.
+Prüfidee:      Mahnstufe 2 setzen (Sperrschwelle 2); API-Anlage eines neuen Angebots schlägt mit der o. g. Meldung fehl; MahnStop ignoriert Sperre je nach Konfiguration.
+Tracelinks:    StRS-2, StRS-6, SwRS-5, SwRS-18
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Bonitätssteuerung.
+Status:        belegt
+
+---
+
+ID:            SyRS-9
+Titel:         Elektronische Rechnungen: ZUGFeRD/XRechnung und ebInterface
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Rechnungsausgang, Empfängerbehörden, österreichische Kunden
+Vorbedingung:  Rechnung ist erzeugt; Kundeneinstellung zum Exportprofil existiert.
+Fakt:          `InvoiceZugferdBL.GetZugferFormat` wählt `ZugferdKind` (u. a. `ZUGFeRD_1_0`, `ZUGFeRD_XInvoice_3_0_1`) aus Kundeneinstellung `ActiveZugferdInterface`, Hinweis „for the local setting the newest version of XRechnung should be used“; `Centron.Gateway/ZUGFeRD21_Extended`; `EbInterfaceLogic` mit Namespace `http://www.ebinterface.at/schema/4p3/` inkl. Vorab-Validierung (`ValidateValues`); `ZugferdImportController` (Eingangsverarbeitung), `CustomZugferdPdfGenerator` (Hybrid-PDF).
+Aussage:       Das System soll ausgehende Rechnungen je Empfängerland im vorgeschriebenen Strukturierten Format erzeugen (DE: ZUGFeRD/XRechnung, AT: ebInterface 4.3) und eingehende E-Rechnungen importieren können; Formatversionen sind konfigurierbar.
+Ergebnis:      Revisionssichere E-Rechnungs-Ausgabe und -eingangsverarbeitung; Formatwahl pro Kunde/Empfänger.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs:85-100` - Formatentscheidende Stelle.
+  - [PRIMÄR]   `src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs` (`GenerateFile` mit `ValidateValues`, Namespace 4p3) - erzwungenes Formatlayout.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Receipts/ZugferdImportController.cs` - Eingangs-Endpunkt.
+Prüfidee:      XRechnung-Validierung (Schematron) für Musterrechnung erfolgreich; ebInterface-Ausgabe validiert gegen XML-Schema 4.3; deaktivierte Kundeneinstellung erzeugt nur PDF.
+Tracelinks:    StRS-6, SwRS-21, SwRS-22
+Konsolidierung: Kandidat: ZUGFeRD 1.0 Alt-Pfade (`InvoiceZugferdBL.Zugferd10.cs`) vs. XRechnung 3 - nur aktuelles Profil übernehmen.
+Übernahmewürdigkeit: übernehmen (gesetzlich); ZUGFeRD 1.0 Alt-Parser = veraltet.
+Status:        belegt
+
+---
+
+ID:            SyRS-10
+Titel:         Versanddienstleister-Anbindung (Shipcloud, GLS)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Logistik/Versand, Spediteur
+Vorbedingung:  Beleg ist versandbereit; Versandeinstellungen konfiguriert.
+Fakt:          `src/apis/Centron.Api.Shipcloud` (Klassen `UploadResult`, `Helpers`, `Entities`), `src/apis/Centron.Api.Gls` (Klassen/Entities), `ShipcloudPackageTemplateBL.cs` und `ShipcloudPackageTemplatesController.cs` (Vorlagenverwaltung), WPF-Modul `Logistic`.
+Aussage:       Das System soll Packstücke für ausgehende Belege über Versanddienstleister (Shipcloud, GLS) anmelden und Label/Sendungsstatus in den Beleg übernehmen.
+Ergebnis:      Sendungsnummer/Label hängen am Beleg; Statusänderungen sind nachvollziehbar.
+Belege:
+  - [SEKUNDÄR] `src/apis/Centron.Api.Shipcloud/Classes/UploadResult.cs`, `src/apis/Centron.Api.Gls/Classes/UploadResult.cs` - Upload-Antwortverarbeitung zweier Dienstleister.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs` - Paketvorlagen-Verwaltung.
+Prüfidee:      Musterbeleg → Label-PDF + Sendungsnummer im Beleg; Storno löscht Referenz.
+Tracelinks:    StRS-2, StRS-11
+Konsolidierung: Kandidat: Shipcloud- und GLS-Adapter abstrahieren denselben Vorgang „Versandanmeldung“ → ein Carrier-Adapter-Konzept.
+Übernahmewürdigkeit: übernehmen (Konzept); konkrete Anbieter = konfigurierbare Konnektoren.
+Status:        belegt
+
+---
+
+ID:            SyRS-11
+Titel:         EDI-Anbindung mehrerer Großhandelslieferanten
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkaufssystem, Lieferanten-EDIs (Alltron, Also/AlsoCH, EGIS, Herweck, Komsa, Concerto, OpenTrans)
+Vorbedingung:  Partner-Konfiguration aktiv.
+Fakt:          `src/backend/Centron.Gateway/EDI_Alltron`, `EDI_Also`, `EDI_AlsoCH`, `EDI_EGIS`, `EDI_Herweck`, `EDI_Komsa` (je eigener Implementierungsordner), `Concerto/ConcertoOrder.xsd` (bestellungs-XSD), `OpenTrans`/`OpenTrans1_0` (Bestellformat), `Centron.APIs.EgisDataAccess` (RequestTemplates/Parser), `Centron.APIs.CopDataAccess` (SoapTemplates/Parser).
+Aussage:       Das System soll ausgehende Bestellungen und eingehende Auftrags-/Artikeldaten mit mehreren Lieferantenformaten konvertieren; neue Lieferanten sollen als weiterer Connector ohne Kernänderung ergänzbar sein.
+Ergebnis:      Lieferantenindividuelle Formate werden über einen Gateway-Layer (Centron.Gateway) gekapselt; Kernsystem bleibt formatfrei.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Gateway/Concerto/ConcertoOrder.xsd` - verbindliches Nachrichtenschema einer Bestellung.
+  - [SEKUNDÄR] Verzeichnisstruktur `Centron.Gateway/EDI_*` - Connector je Partner real vorhanden.
+Prüfidee:      XSD-Validierung aller ausgehenden Bestellungen eines Partners gegen dessen Schema-Ordner.
+Tracelinks:    StRS-4, StRS-13, SwRS-23
+Konsolidierung: Kandidat: alle `EDI_*`-Ordner + `CopDataAccess`/`EgisDataAccess` - gleiche Funktion „Lieferantenanbindung“ in ≥6 Implementationen; Ziel: ein Connector-Framework mit Partner-Konfiguration.
+Übernahmewürdigkeit: übernehmen - EDI ist betriebskritisch.
+Status:        belegt
+
+---
+
+ID:            SyRS-12
+Titel:         Produktdaten-Services (Icecat, ITscope)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Artikelstamm-Pflege
+Vorbedingung:  API-Zugang zu Datenquelle konfiguriert.
+Fakt:          `IcecatApi.cs`/`IIcecatApi.cs` mit Sprachenumgebung (`Languages.cs`), `ITscopeDataAccess` mit eigenem Parser-Layer, `CopDataAccess` SOAP-Templates.
+Aussage:       Das System soll Produktinformationen (Texte, Bilder, Merkmale) über definierte Services abrufen und mehrsprachig in den Artikelstamm übernehmen können.
+Ergebnis:      Artikelanreicherung erfolgt automatisiert; Quellen sind austauschbar.
+Belege:
+  - [SEKUNDÄR] `src/apis/Centron.APIs.IcecatDataAccess/IIcecatApi.cs`, `Languages.cs` - API-Vertrag + Sprachsupport.
+Prüfidee:      Abruf eines bekannten Artikels; Merkmalsliste und Bild-URLs im Datensatz.
+Tracelinks:    StRS-5, StRS-13
+Konsolidierung: Kandidat: wie StRS-13 (Import-Pipeline).
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-13
+Titel:         Onlinebanking-Anbindung (FinAPI, HBCI/FinTS)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Bank
+Vorbedingung:  Bankkonto konfiguriert (FinAPI-Zugang oder HBCI-Credentials).
+Fakt:          `Finances/OnlineBanking/OnlineBankingFinApiBL.cs` + `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` (REST-FinAPI), `Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs` (FinTS-Bibliothek), `Finances/IncomingPayments/IncomingPaymentBL.cs` (Zuordnung Zahlungseingänge), `Accounting/BankAccountBL.cs`.
+Aussage:       Das System soll Kontoumsätze und Überweisungen über Onlinebanking-Kanäle (FinAPI, alternativ FinTS) austauschen und Zahlungseingänge zur offenen-Posten-Verrechnung bereitstellen.
+Ergebnis:      Zahlungseingänge werden zur automatischen Rechnungs-Zuordnung angeboten (siehe `RechKopf.Bezahlt`); Kontoauszüge liegen im System vor.
+Belege:
+  - [SEKUNDÄR] `src/backend/Centron.Gateway/OnlineBanking/OnlineBankingConnectionLibfintx.cs` - FinTS-Verbindung implementiert.
+  - [SEKUNDÄR] `src/apis/Centron.APIs.FinAPI/FinApiClient.cs` - FinAPI-REST-Client.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs` - Eingangsverbuchung.
+Prüfidee:      Testsandbox-Umsatz → Vorschlag zur Zuordnung an Rechnung (Match über Betrag/Verwendungszweck).
+Tracelinks:    StRS-6, SwRS-3
+Konsolidierung: Kandidat: FinAPI- und FinTS-Pfade erfüllen denselben Zweck → ein Banking-Konnektor mit Kanal-Auswahl.
+Übernahmewürdigkeit: übernehmen; FinTS-Legacy-Pfad = Kandidat für Sonderfall/veraltet.
+Status:        HYPOTHESE (die konkrete Umsatz→OP-Zuordnungsregel wurde nicht im Detail gelesen)
+
+---
+
+ID:            SyRS-14
+Titel:         Zeiterfassung als Fakturierungsgrundlage
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Techniker, Support, Fakturierung
+Vorbedingung:  Ticket/Auftrag mit Zeiterfassungsrecht offen.
+Fakt:          `HelpdeskTimerBL`, `HelpdeskTimerArticleBookingBL` (Verrechnung auf Artikel), `HelpdeskTimerAddressSpecialArticlesBL` (Anfahrtsartikel), Rechte `EDIT_TIME`/`OWN_TIME_EDIT`/`MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` (CentronRights.md: Verschieben/Löschen nur, wenn Ticket „not part of a receipt“); `Finances/TimerBilling`; Nexus-Zeiterfassungs-Verbesserungen im Changelog.
+Aussage:       Das System soll geleistete Zeiten inkl. Anfahrtspauschalen erfassen, gegen Mitarbeiter-/Kundenartikel bewerten und erst nach Freigabe unveränderbar in die Abrechnung überführen; Änderungen nach Abrechnung sind gesperrt.
+Ergebnis:      Abrechnungsreife Zeiten sind manipulationssicher; Abhol-/Stornofälle bleiben konsistent.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs:554-556` (`DeleteHelpdeskTimer` prüft `HasUserRight(..., UserRightsConst.Sales.Customer.Helpdesk.DELETE_HELPDESK_TIMER)` vor Löschung) - durchgesetzte Rechtsprüfung; `:119-142` belegt die Zuordnung der Zeit zu Auftrags-/Lieferschein-/Rechnungspositionen (`OrderAssetItemI3D`, `DeliveryListAssetItemI3D`, `InvoiceAssetItemI3D`).
+  - [KONTEXT]  `CentronRights.md` Punkte 8/9 (`MOVE_HELPDESK_TIMER`, `DELETE_HELPDESK_TIMER`: „But only if the ticket is not part of a receipt“) - dokumentierte, im Rechtssystem verankerte Grenze.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Sales/Support/HelpdeskTimerArticleBookingBL.cs` - Artikel-Verrechnung der Zeiten.
+Prüfidee:      Zeit auf abgerechnetem Ticket verschieben → abgelehnt; Zeit mit Anfahrtsartikel erzeugt korrekte Belegposition.
+Tracelinks:    StRS-3, StRS-7, SwRS-31
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - direkte Erlösrelevanz.
+Status:        belegt
+
+---
+
+ID:            SyRS-15
+Titel:         Portal-Zugriff für Kunden über Web-Accounts
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Kunde, Nexus (Blazor), Webservice
+Vorbedingung:  Web-Account (Adressstamm) mit Berechtigung existiert.
+Fakt:          `AuthorizeLoginUserAttribute` vs. `AuthorizeLoginWebAccountAttribute` + zugehörige „Views“ (`AuthorizeLoginUserView`, `AuthorizeLoginWebAccountView`) im Nexus-Authorization-Ordner; `WebAccountController.cs` in der API; `WebReceipt*`-Methoden in `ReceiptBL` (Adress-/Bestellnummern-Änderung per Token durch Web-Kunden, `GetWebReceiptItemChangeRequests`); README-WebCart-Beschreibung.
+Aussage:       Das System soll externe Web-Accounts von internen Mitarbeitern daten- und funktionsseitig trennen; Web-Kunden dürfen nur an Objekten mit Token/Account-Bezug Änderungen vornehmen (z. B. Belegadresse, Bestellnummer, Artikelwunsch).
+Ergebnis:      Externe Eingaben sind auf den eigenen Datenkreis begrenzt und werden im Beleg-Workflow (Änderungsanfrage) geführt.
+Belege:
+  - [PRIMÄR]   `src/nexus/CentronNexus/Shared/Authorization/Attributes/AuthorizeLoginWebAccountAttribute.cs` - erzwungene Account-Art-Prüfung.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5894-6116` (`GetWebReceiptItemChangeRequests`, `ChangeWebReceiptAddress` per Token) - tokenbasierte Kundenänderung.
+Prüfidee:      Web-Account-Kunde ändert Belegadresse eines Fremd-Kunden (falscher Token) → Fehler; Änderungen erscheinen als Änderungsanfrage im Bearbeiter-Cockpit.
+Tracelinks:    StRS-8, SyRS-2, SwRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-16
+Titel:         Echtzeit-Benachrichtigung und Chat über SignalR
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Clients, Webservice-Hubs
+Vorbedingung:  Client authentifiziert; Hub erreichbar.
+Fakt:          `src/webservice/Centron.Host/RealTimeServices` enthält `NotificationsHub`, `ChatHub`, `AvailabilityStatusHub`, `TapiClientHub` mit `SecretKeyHandler`/`SecretKeyRequirement`; `Centron.BL/NexusNotifications`, `Notifications`, `Chats`.
+Aussage:       Das System soll Statuswechsel, Chats, Erreichbarkeit und Telefonie-Ereignisse in Echtzeit an alle aktiven Clients verteilen; Hub-Zugriff ist über Secret-Key abgesichert.
+Ergebnis:      Mehrbenutzer-Clients bleiben ohne manuelles Aktualisieren konsistent.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Host/RealTimeServices/SecretKeyHandler.cs` - durchgesetzte Hub-Absicherung.
+  - [SEKUNDÄR] Hub-Dateinamen (`NotificationsHub.cs` u. a.) - Echtzeit-Kanäle.
+Prüfidee:      Statuswechsel in Client A erscheint ohne Reload in Client B; unautorisierter Hub-Aufbau scheitert.
+Tracelinks:    StRS-10, StRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-17
+Titel:         Volltextsuche über zentrale Indizes
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Alle Fachanwender
+Vorbedingung:  Indizes sind aufgebaut.
+Fakt:          `Centron.BL/IndexSearch` mit `IndexBuilder.cs`, `GermanAnalyzer.cs`, `Indexes/TicketFulltextIndex.cs`; Exception `ObjectIndexingFailedException`.
+Aussage:       Das System soll objektübergreifende Volltextsuche (u. a. Tickets) mit deutscher Sprachanalyse bereitstellen und Indexfehler protokollieren statt die Anwendung abbrechen lassen.
+Ergebnis:      Schnelles Finden von Vorgängen über Freitext.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/IndexSearch/GermanAnalyzer.cs` + `TicketFulltextIndex.cs` - implementierte Suche/Analyse.
+Prüfidee:      Suchbegriff im Tickettext findet Ticket; Wortform „Rechnungen“ findet „Rechnung“ (Stemming-Test).
+Tracelinks:    StRS-3, StRS-12, SwRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-18
+Titel:         Report-/Berichte-Engine (FastReport, DevExpress)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Reports, Druck-/Export-Kette
+Vorbedingung:  Reportvorlage vorhanden.
+Fakt:          `Centron.BL/ReportEngine` (u. a. `CustomPdfGenerators/CustomZugferdPdfGenerator.cs`, `Templates/HelpdeskHtmlTemplateManager.cs`), `Centron.DAO/Reporting`, `Centron.Interfaces/CentronReportEngine`; `Centron.BL.csproj` referenziert `FastReport.Net.Pro`, `FastReport.Core.Skia`, `DevExpress.Document.Processor` (Serverseitige PDF-/Reportverarbeitung inkl. Skia/Linux-Native-Assets).
+Aussage:       Das System soll Berichte serverseitig rendern (PDF/Druck/Excel) und plattformunabhängig (Windows und Linux-Container) ausführen.
+Ergebnis:      Belegdruck und Reports funktionieren im Windows-Client und im Docker-Betrieb.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Centron.BL.csproj` (PackageReferences FastReport.SkiaDrawing, SkiaSharp.NativeAssets.Linux, Kommentar zu FastReport-Bug) - real genutzte Renderkette inkl. Linux.
+  - [SEKUNDÄR] ReportEngine-Ordnerstruktur - Vorlagenverwaltung.
+Prüfidee:      Beleg-Report im Linux-Container erzeugen → PDF identisch zum Windows-Lauf.
+Tracelinks:    StRS-12, StRS-6
+Konsolidierung: Kandidat: FastReport- und DevExpress-Renderpfade parallel → eine Render-Engine wählen.
+Übernahmewürdigkeit: übernehmen (Konzept), Lizenz-/Bibliotheken-Doppelung = Konsolidierungsfall.
+Status:        belegt
+
+---
+
+ID:            SyRS-19
+Titel:         E-Mail-Integration und automatisierte Ticketentstehung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Postfächer, MailScanner, Outlook
+Vorbedingung:  MailScanner-Profil konfiguriert.
+Fakt:          `MailScannerBL` (`GetProfiles`, `SaveWorkflow`, `SaveTasks`, `DeleteMailScannerLogs`), `HelpdeskMailBL`, `Outlook`-BL + `CentronNexus.OutlookAddIn`, docker `c-entron-mailcatcher` (SMTP-Test), Compose-Service `smtp` (Port 1025/1080).
+Aussage:       Das System soll eingehende E-Mails nach Profilen/Workflows verarbeiten (Antwort/Ticket/Task), Mails an Tickets andocken und Outlook-Anbindung bereitstellen; ein SMTP-Relay ist Teil der Referenzinstallation.
+Ergebnis:      Supportanfragen aus E-Mails entstehen automatisiert und sind als Mail-Historie belegbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/MailScanner/MailScannerBL.cs` - Workflow/Tasks-Engine.
+  - [SEKUNDÄR] `docker/compose/compose.yaml` Service `smtp` - betrieblicher Mail-Pfad.
+Prüfidee:      Mail an Sammeladresse erzeugt Ticket gemäß Profil; Log-Eintrag; doppelte Mail erzeugt kein Duplikat (zu prüfen).
+Tracelinks:    StRS-3, StRS-10, SwRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-20
+Titel:         Dokumentensignatur über docuFORM und PDF-Signing
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Beleg-/Vertragsprocess, docuFORM-Dienst
+Vorbedingung:  Dokument liegt vor; Signaturflow aktiviert.
+Fakt:          `Centron.Api.docuFORM/DocuFormRestApiClient.cs` (+ `DocuFormRestApiConstants`, `IDocuFormApiClient`), `src/backend/Centron.BL/Security/PdfSigningBL.cs`, Nexus-Ordner `DocumentSigning`, `DocuFormApiSettingsController.cs`.
+Aussage:       Das System soll Dokumente in einen externen Signaturdienst (docuFORM) geben, Status rückführen und signierte PDFs im Dokumentenbestand des Fachobjekts bereitstellen.
+Ergebnis:      Unterschriftenprozess medienbruchfrei; Signaturstatus am Vorgang sichtbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Security/PdfSigningBL.cs` - serverseitige Signaturlogik.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/DataExchange/DocuFormApiSettingsController.cs` - Konfigurations-API.
+Prüfidee:      Test-Signaturflow: Statusübergänge (erstellt→versendet→signiert), signiertes PDF im DocDir.
+Tracelinks:    StRS-15, StRS-11, SyRS-15
+Konsolidierung: Kandidat: docuFORM-Signatur vs. PdfSigningBL (intern) - ein Signatur-Framework mit Providern.
+Übernahmewürdigkeit: übernehmen (Konzept); docuFORM-Anbindung = austauschbarer Provider.
+Status:        HYPOTHESE (Statusmodell des Signaturflows nicht im Detail belegt)
+
+---
+
+ID:            SyRS-21
+Titel:         Telefonie-Integration (TAPI, TelekomDive)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Service-Desk-Mitarbeiter, Telefonanlage
+Vorbedingung:  TAPI-Client läuft; TelekomDive-Zugang konfiguriert.
+Fakt:          `assemblies/tapi` (Bibliothek), `Centron.Controls/Telephony`, `Centron.BL/Tapi/PhoneCallBL.cs`, `TapiClientHub` (SignalR), `TelekomDiveController.cs` + `TelekomDive`-WPF-Modul; Changelog: „Telefonnummer … anklicken, um Telefonverbindung über externe Software aufzubauen“.
+Aussage:       Das System soll Klick-zu-Call aus Kunden-/Ticketdaten und Anruf-Events (Client-Hub) unterstützen, angebunden an Telefonie-Dienste (TAPI-basiert sowie TelekomDive).
+Ergebnis:      Anrufhistorie/Verbindungsherstellung sind arbeitsplatzübergreifend verfügbar.
+Belege:
+  - [SEKUNDÄR] `src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs` - Telefonie-Ereignisverteilung.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/DataExchange/TelekomDiveController.cs` + `src/centron/Centron.WPF.UI/Modules/TelekomDive` - Providerintegration.
+Prüfidee:      Klick auf Telefonnummer im Ticket löst CTI-Aktion aus; Event erscheint im Client.
+Tracelinks:    StRS-10, StRS-11, SyRS-16
+Konsolidierung: Kandidat: TAPI (lokal) und TelekomDive (Cloud) - zwei Wege für „Click-to-Dial“.
+Übernahmewürdigkeit: TAPI = veraltet (Windows-only Legacy); TelekomDive = Sonderfall (Anbieterbindung).
+Status:        HYPOTHESE (Konkrete Funktionsbreite beider Kanäle nicht im Detail belegt)
+
+---
+
+ID:            SyRS-22
+Titel:         bidirektionale Riverbird-Synchronisation
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        c-entron Webservice, Riverbird Web-Service
+Vorbedingung:  Mandant über Riverbird bezogen.
+Fakt:          `RiverConnectionBL` (Klassendoku: ausgehende Rufe des c-entron Webservice nach Riverbird), `RiverDivoBL` (eingehende Rufe von Riverbird in c-entron), `RBContractArticleRefInfo` (Vertrag↔Artikel-Referenz), `deployment/riverbird`.
+Aussage:       Das System soll die Kopplung an die Riverbird-Plattform in beide Richtungen aufrechterhalten (Vertrags→Artikel-Beziehungen, Statusänderungen).
+Ergebnis:      Vertragsdaten bleiben über Systemgrenzen konsistent.
+Belege:
+  - [KONTEXT]  `src/backend/Centron.BL/RiverDivo/RiverDivoBL.cs` + `RiverConnectionBL.cs` (Klassendoku) - Implementierung beider Richtungen behauptet; einzelne prüfende Methoden nicht verifiziert.
+Prüfidee:      Simulierter Riverbird-Call auf `RiverDivoBL`-Methode; Referenztabelle wird nachgeführt.
+Tracelinks:    StRS-14, StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - plattformspezifische Kopplung des Herstellers.
+Status:        HYPOTHESE (fachlicher Sync-Umfang nur aus Doku-Kommentaren erschlossen)
+
+---
+
+ID:            SyRS-23
+Titel:         Datenhaltung mit Mandanten-, Filial- und Löschstatus
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Datenbank, alle Module
+Vorbedingung:  Mandant/Filiale im System gepflegt.
+Fakt:          `Filiale.MandantI3D`, `KundeToKonzern`-Tabelle, `Accounts/CustomerToBranchBL.cs`, `CustomerCostCenterBL.cs`; Rechte mit Filialbezug (`CentronRights.md`); `Status`-Spalten breit indexiert (viele `*_Status`-Indizes im Schema); Soft-Delete-Muster `Geloescht*` (z. B. `Filiale.GeloeschtVonI3D`, `Mahnlauf.GeloeschtDatum`).
+Aussage:       Das System soll Fachdaten dauerhaft mit Mandant/Filiale referenzieren, Löschungen als Kennzeichnung (Status/Deleted) statt physischem Löschen abbilden und damit Auswertbarkeit und Revision erhalten.
+Ergebnis:      Kein Datenverlust durch Löschen; Auswertungen je Filiale/Mandant möglich.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `Filiale` (`MandantI3D`, `GeloeschtVonI3D`, `Status`), Indexmuster `*_Status` - erzwungene Struktur.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Accounts/CustomerToBranchBL.cs` - Filialzuordnung gepflegt.
+Prüfidee:      Objekt „löschen“ → Datensatz bleibt mit Löschkennzeichen erhalten und verschwindet aus Fachlisten.
+Tracelinks:    StRS-1, SwRS-4, SwRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - revisionsfreundlich.
+Status:        belegt
+
+---
+
+ID:            SyRS-24
+Titel:         Versionierung und Protokollierung von Belegen und Änderungen
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Revision, Sachbearbeiter
+Vorbedingung:  Beleg wird gespeichert.
+Fakt:          30 `*Versions`-Tabellen im Schema (u. a. `AngKopfVersions`, `AufKopfVersions`, `RechKopfVersions`, `GutKopfVersions`); `ReceiptBL` schreibt Logeinträge (`ReceiptLogBL.CreateReceiptItemEntry(… "der Rabatt" …)`, `CreateWithStaffelPriceEntry`); `Centron.DAO/ChangeTracking`; Nexus-Ticket-Historie (Changelog).
+Aussage:       Das System soll jede Belegänderung als neue Version erhalten und wertändernde Eingriffe (Preise, Rabatte, Konditionen) protokollieren; die Änderungshistorie ist im Objekt einsehbar.
+Ergebnis:      Nachvollziehbarkeit wer/wann/was bei Preis- und Konditionsänderungen.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql`, 30 Tabellen `CREATE TABLE …Versions` - Versionshaltung strukturell erzwungen.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:10543-10709` (Anlage von Log-Einträgen bei Staffelpreis-/Rabattänderung) - durchgesetztes Protokollieren.
+Prüfidee:      Rabatt auf Position ändern; Log zeigt alten/neuen Wert + Benutzer + Zeit; Versionsvergleich liefert Differenz.
+Tracelinks:    StRS-2, StRS-6, SwRS-2, SwRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Audit-Anforderung.
+Status:        belegt
+
+---
+
+ID:            SyRS-25
+Titel:         Lizenzierung an Hardware-ID gebunden
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Vertrauenswürdigkeit/Sicherheit
+Akteur:        Hersteller c-entron, Betrieb
+Vorbedingung:  Installation registriert.
+Fakt:          Compose-Env `HARDWARE_ID: LinuxV1.<Base64>`; `c-entron.misc.ConnectionManager` mit `HardwareIdView/ViewModel` und `LicenseView/LicenseViewModel`; `LicenseController.cs` in der API; Nexus enthält `Management`-Bereich.
+Aussage:       Das System soll die Inbetriebnahme an eine Lizenzprüfung binden, die installationsindividuell (Hardware-ID) vergeben wird.
+Ergebnis:      Unlizenzierte Installationen nehmen den Betrieb nicht auf bzw. sind meldungspflichtig.
+Belege:
+  - [SEKUNDÄR] `docker/compose/compose.yaml` (`HARDWARE_ID`-Variable), `ConnectionManager`-Masken - Ausweis des Lizenzmodells.
+  - [SEKUNDÄR] `src/webservice/Centron.Controllers/Controllers/Administration/LicenseController.cs` - Lizenz-API.
+Prüfidee:      Start ohne/ungültige HARDWARE_ID → Lizenzfehler; gültige ID → Start.
+Tracelinks:    SyRS-3, StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Hersteller-Lizenzmodell; im SaaS-Modell durch Mandanten-Abrechnung ersetzbar.
+Status:        HYPOTHESE (Durchsetzungspunkt der Lizenzprüfung im Startpfad nicht lokalisiert)
+
+---
+
+ID:            SyRS-26
+Titel:         Zwei- und mehrsprachige Benutzeroberfläche (DE/EN)
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Anpassungsfähigkeit
+Akteur:        Deutsch-/englischsprachige Nutzer
+Vorbedingung:  Kultur am Benutzer/Browser gesetzt.
+Fakt:          Nexus-`SharedResource.resx` + `SharedResource.en-US.resx`; WPF-`Localization`-Ordner; `Centron.Host/LocalizationHandler.cs`; Nexus `CultureController.cs`; Icecat-API mit Sprachenumgebung.
+Aussage:       Das System soll UI-Texte ressourcenbasiert lokalisiert ausliefern und die Kultur pro Benutzer/Sitzung auflösen.
+Ergebnis:      Gleiche Funktionen in DE und EN; neue Sprachen ohne Codeänderung.
+Belege:
+  - [SEKUNDÄR] `src/nexus/CentronNexus/SharedResource.en-US.resx`, `SharedResource.resx`, `src/webservice/Centron.Host/Services/LocalizationHandler.cs` - Ressourcen + Laufzeitauflösung.
+Prüfidee:      Kultur auf en-US setzen → alle Labels englisch; fehlende Ressource führt zu definiertem Fallback.
+Tracelinks:    StRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-27
+Titel:         Datenbank-Performance durch Fremdenschlüssel-/Status-Indizes
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Performance-Effizienz
+Akteur:        Datenbank
+Vorbedingung:  Schema deployed.
+Fakt:          `SSMS_DB_SCHEMA.sql` enthält tausende `CREATE NONCLUSTERED INDEX`-Statements, darunter systematisch Indizes auf Fremdschlüssel (z. B. `AngKopf_KundenID`, `AufKopf_KundenID`) und Status-Spalten (`*_Status`).
+Aussage:       Das Datenmodell soll Join- und Filterpfade (Kunde, Status) durch nicht-gruppierte Sekundärindizes abdecken, damit listengestützte Fachmasken auch bei Millionendatenvolumen antworten.
+Ergebnis:      Typische Fachabfragen (Kundensicht, Statuslisten) laufen indexgestützt.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` (Indexblöcke ab Zeile ~55800, z. B. `CREATE NONCLUSTERED INDEX [AufKopf_KundenID] ON [dbo].[AufKopf]`) - real gesetzte Indizes.
+Prüfidee:      Abfrageplan für „Belege je Kunde/Status“ zeigt Index-Seek statt Table-Scan.
+Tracelinks:    StRS-2, SwRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (Prinzip; konkretes Indexwerk wird neu abgeleitet).
+Status:        belegt
+
+---
+
+ID:            SyRS-28
+Titel:         Zentrale Protokollierung und Laufzeitdiagnose
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        Betrieb, Support
+Vorbedingung:  Anwendung läuft.
+Fakt:          `Centron.Common/Logging` (`InMemoryLogging.cs`, `InMemoryTarget.cs`, `LogEntry.cs`); Log-Nutzung via `LogManager.GetCurrentClassLogger()` (log4net-artig); Changelog: „In den Logs unter Systeminfo wird nun auch der CallStack angezeigt“; Nexus-Systeminfo-Log-Kategorien.
+Aussage:       Das System soll Laufzeit- und Fehlerereignisse strukturiert protokollieren (inkl. Stack) und dem Support im Client/Web als Logbereiche bereitstellen.
+Ergebnis:      Fehlerfälle sind ohne Debugging rekonstruierbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Common/Logging/InMemoryTarget.cs` - implementierter Appender.
+  - [KONTEXT]  `src/nexus/CentronNexus/changelog.txt` (CallStack in Logs) - gelebte Diagnose.
+Prüfidee:      Provokierter Fehler → Logeintrag mit Category, Level, Stack; in Systeminfo einsehbar.
+Tracelinks:    StRS-16, SwRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-29
+Titel:         CI/CD und Sicherheitsprüfung als Build-Pipelines
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Entwicklung, Betrieb
+Vorbedingung:  Repository-Änderung.
+Fakt:          `azure/build-pipeline.yml`, `tests-pipeline.yml`, `regression-tests-pipeline.yml`, `playwright-pipeline.yml`, `security-pipeline.yaml`, `deploy-on-testenv.yaml`, `analyze-pipeline.yml`; `.github`-Ordner; `docker/c-entron-regression-tests-db`.
+Aussage:       Das System soll Build, Unit-/Integrations-/Regressionstests, UI-End-to-End-Tests und Sicherheitsanalysen als automatisierte Pipelines ausführen und auf Testumgebungen deployen.
+Ergebnis:      Qualitätssicherung ist in den Auslieferungspfad integriert.
+Belege:
+  - [SEKUNDÄR] Dateibestand `azure/*.yml` (Pipelines für build/test/regression/playwright/security/deploy) - definierte QA-Kette.
+  - [SEKUNDÄR] `tests/Centron.Tests.EndToEnd`, `tests/PlaywrightTests` - Testprojekte.
+Prüfidee:      Branch-Push löst Build+Tests+Security-Scan aus; Pipeline-Feed zeigt Ergebnisse.
+Tracelinks:    StRS-16, SwRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-30
+Titel:         Mehrsprachige Belegtexte, Textbausteine und Vorlagen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter, Fakturierung
+Vorbedingung:  Textmodule/Vorlagen gepflegt.
+Fakt:          `Centron.BL/TextModuleArea`, `Centron.DAO/TextModuleArea`; `ReceiptTemplateBL.cs`; `HelpdeskCreationTemplateBL`, `HelpdeskPatternBL`, `TicketPatternsController.cs`; `ReplaceTextVariables`/`ReplaceCommonReceiptVariableValues` in `ReceiptBL.cs:6602-6649`.
+Aussage:       Das System soll Beleg- und Tickettexte über Variablen-Textbausteine erzeugen (Belegnummern, Kundendaten, Mitarbeiterdaten eingesetzt) und Vorlagen je Beleg-/Ticketart pflegbar halten.
+Ergebnis:      Einheitliche, konfigurierbare Ausgangstexte ohne Hartcodierung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:6602-6649` (Ersetzungsmethoden) - durchgeführte Textersetzung.
+Prüfidee:      Vorlage mit `{Belegnummer}`-Variable → erzeugtes PDF enthält reale Nummer; ohne Vorlage greift Standard.
+Tracelinks:    StRS-2, StRS-3
+Konsolidierung: Kandidat: Belegvorlagen (`ReceiptTemplateBL`) und Ticketvorlagen (`HelpdeskPatternBL`, `TicketPatternsController`) - gemeinsames Template-Subsystem im Ziel.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/Traceability.md

@@ -0,0 +1,66 @@
+# Traceability
+
+Konsolidierte Traceability-Tabelle (Forward/Backward zwischen StRS ↔ SyRS ↔ SwRS). Zeilen je SyRS-Anforderung; SwRS-Spalte listet die darunter rangierenden Komponenten-/Datenanforderungen.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kernbeleg) |
+|---|---|---|---|
+| StRS-1 | SyRS-23 | SwRS-4, SwRS-6, SwRS-32 | `SSMS_DB_SCHEMA.sql` Tabelle `Filiale` (`MandantI3D`, `Geloescht*`), Indexmuster `*_Status` |
+| StRS-1 | SyRS-1 | SwRS-7, SwRS-8 | `docker/compose/compose.yaml`; `BLSession.GetBL`-Muster |
+| StRS-2 | SyRS-7 | SwRS-3, SwRS-17 | `ReceiptBL.cs:8636` (`CheckIfCustomerLimitIsReached`) |
+| StRS-2 | SyRS-8 | SwRS-5, SwRS-18 | `ReceiptBL.cs:10194` (Mahnstufengate), `RechKopf.Mahnstufe` |
+| StRS-2 | SyRS-24 | SwRS-2, SwRS-25 | 30 Tabellen `*Versions`; `ReceiptLogBL`-Aufrufe |
+| StRS-2 | SyRS-30 | SwRS-2 | `ReceiptBL.cs:6602ff.` (Textvariablen), `ReceiptTemplateBL` |
+| StRS-2 | – (Fachkette) | SwRS-19 | `ReceiptProgressionBL.cs` |
+| StRS-2 | SyRS-10 | – | `ShipcloudPackageTemplateBL.cs`, `Centron.Api.Gls/Shipcloud` |
+| StRS-3 | SyRS-14 | SwRS-10 | `CentronRights.md` 7–9; `HelpdeskTimerArticleBookingBL.cs` |
+| StRS-3 | SyRS-19 | SwRS-10 | `HelpdeskMailBL.cs`, `MailScannerBL.cs` |
+| StRS-4 | SyRS-11 | SwRS-23 | `Centron.Gateway/EDI_*`, `Concerto/ConcertoOrder.xsd` |
+| StRS-5 | SyRS-12 | SwRS-11, SwRS-12 | Tabellen `Artikel*`; `Warehousing/ArticleVolumePricesBL.cs` |
+| StRS-6 | SyRS-9 | SwRS-3, SwRS-21, SwRS-22 | `InvoiceZugferdBL.cs:85-100`; `EbInterfaceLogic.cs` |
+| StRS-6 | SyRS-13 | SwRS-3 | `OnlineBankingFinApiBL.cs`, `OnlineBankingConnectionLibfintx.cs` |
+| StRS-6 | SyRS-8 | SwRS-5 | `Mahnlauf.cs` |
+| StRS-7 | SyRS-14 | SwRS-31 | `Modules/Finances/TimerBilling`, `ContractEvaluation2` |
+| StRS-7 | SyRS-22 | SwRS-31 | `RiverDivo`-Klassendoku |
+| StRS-8 | SyRS-15 | SwRS-20 | `AuthorizeLoginWebAccountAttribute.cs`; `ReceiptBL.cs:5894-6116` |
+| StRS-9 | SyRS-2 | SwRS-14 | `TicketAuthenticationHandler.cs`, `AuthenticationTicketBL.cs:25-47` |
+| StRS-9 | SyRS-3 | SwRS-14 | `JwtAuthController.cs` |
+| StRS-9 | SyRS-4 | SwRS-13 | `AuthorizeUserRightAttribute.cs`; `UserRightsConst.cs` |
+| StRS-9 | SyRS-5 | SwRS-15, SwRS-16 | `TwoFactorAuthenticationBL.cs:43-54` |
+| StRS-9 | SyRS-6 | SwRS-16 | `CryptoUtils.cs:26-33` |
+| StRS-10 | SyRS-16 | SwRS-28 | `RealTimeServices/SecretKeyHandler.cs` |
+| StRS-10 | SyRS-19 | – | `MailScannerBL.cs` |
+| StRS-10 | – (UI) | SwRS-30 | `src/shared/Centron.Controls/*` |
+| StRS-11 | SyRS-1 | – | Compose-Topologie |
+| StRS-11 | SyRS-20 | – | `DocumentSigning` (Nexus), `Centron.Api.docuFORM` |
+| StRS-11 | SyRS-21 | – | `TapiClientHub.cs`, `TelekomDiveController.cs` |
+| StRS-12 | SyRS-17 | SwRS-29 | `IndexSearch/GermanAnalyzer.cs` |
+| StRS-12 | SyRS-18 | – | `Centron.BL.csproj` (FastReport/Skia) |
+| StRS-13 | SyRS-12 | – | `Centron.APIs.IcecatDataAccess/IIcecatApi.cs`, `ITscopeDataAccess` |
+| StRS-14 | SyRS-22 | – | `RiverConnectionBL.cs`, `RiverDivoBL.cs` |
+| StRS-15 | SyRS-20 | SwRS-33 | `PdfSigningBL.cs`; `ConnectionManager` |
+| StRS-16 | SyRS-25 | SwRS-33 | `HARDWARE_ID` (compose), `LicenseController.cs` |
+| StRS-16 | SyRS-27 | SwRS-1 | `SSMS_DB_SCHEMA.sql` Indexblöcke |
+| StRS-16 | SyRS-28 | SwRS-26 | `Common/Logging/InMemoryTarget.cs` |
+| StRS-16 | SyRS-29 | SwRS-34 | `azure/*.yml`; `version.json` |
+| StRS-1,5,6,9 | SyRS-23 | SwRS-1, SwRS-2 | Schema-Gesamtbefund (Tabellen/Constraint-Armut) |
+
+## Rückwärtskette (StRS → Mengen)
+
+| StRS | zugehörige SyRS | zugehörige SwRS |
+|---|---|---|
+| StRS-1 | SyRS-1, SyRS-23 | SwRS-1, SwRS-4, SwRS-6, SwRS-7, SwRS-8, SwRS-32 |
+| StRS-2 | SyRS-7, SyRS-8, SyRS-10, SyRS-24, SyRS-30 | SwRS-2, SwRS-3, SwRS-17, SwRS-18, SwRS-19, SwRS-25 |
+| StRS-3 | SyRS-14, SyRS-19 | SwRS-10 |
+| StRS-4 | SyRS-11, SyRS-12 | SwRS-11, SwRS-23 |
+| StRS-5 | SyRS-12 | SwRS-11, SwRS-12 |
+| StRS-6 | SyRS-8, SyRS-9, SyRS-13 | SwRS-3, SwRS-5, SwRS-17, SwRS-18, SwRS-21, SwRS-22 |
+| StRS-7 | SyRS-14, SyRS-22 | SwRS-31 |
+| StRS-8 | SyRS-15 | SwRS-20 |
+| StRS-9 | SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6 | SwRS-13, SwRS-14, SwRS-15, SwRS-16 |
+| StRS-10 | SyRS-16, SyRS-19 | SwRS-26, SwRS-28, SwRS-30 |
+| StRS-11 | SyRS-1, SyRS-15, SyRS-16, SyRS-20, SyRS-21 | SwRS-20, SwRS-33 |
+| StRS-12 | SyRS-17, SyRS-18 | SwRS-29 |
+| StRS-13 | SyRS-12 | – |
+| StRS-14 | SyRS-22 | – |
+| StRS-15 | SyRS-20 | SwRS-30, SwRS-33 |
+| StRS-16 | SyRS-25, SyRS-27, SyRS-28, SyRS-29 | SwRS-1, SwRS-26, SwRS-34 |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Protokoll.md

@@ -0,0 +1,126 @@
+# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/solo/high
+
+> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
+> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
+
+## Lauf
+- **Prompt-Datei:** `03_Prompt.md`
+- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
+- **Startzeit:** 2026-09-02T12:51:54.8940173+02:00
+- **Endzeit:** 2026-09-02T13:11:01.6994339+02:00
+- **Dauer gesamt:** 00:19:03 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
+- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
+- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 13.0.0
+- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
+- **CLI-Version:** OpenCode 1.18.25
+- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
+- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/solo/high/`
+- **Agentenmodus:** `solo`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
+- **Rollen:** {}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 110.962 |
+| Output-Tokens | 68.116 |
+| Reasoning-Tokens | 23.770 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 93 |
+
+**Tokens gesamt: 6.432.032.** Kosten `0` – lokaler Betrieb ().
+
+## Gefundene Anforderungen
+
+## 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 | 16 | 19,8 % |
+| SyRS | 30 | 37,0 % |
+| SwRS | 35 | 43,2 % |
+| **Gesamt** | **81** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 19 | 23,5 % |
+| Schnittstelle | 19 | 23,5 % |
+| Daten | 18 | 22,2 % |
+| Sicherheit | 15 | 18,5 % |
+| nicht-funktional | 10 | 12,3 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 137 |
+| davon `PRIMÄR` | 72 (52,6 %) |
+| davon `SEKUNDÄR` | 54 (39,4 %) |
+| davon `KONTEXT` | 11 (8,0 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 64 (79,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 75 | 92,6 % |
+| workaround | 2 | 2,5 % |
+| sonderfall | 4 | 4,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 67 | 82,7 % |
+| als `HYPOTHESE` gekennzeichnet | 14 | 17,3 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 31 | 38,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 11 | 13,6 % |
+
+### 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 27 ungedeckt: StRS-11, SyRS-29, SwRS-30 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9e40b88cffesSzknb1eFPiSFP`
+- **Werkzeugaufrufe:** 135 – {"bash": 80, "read": 11, "write": 8, "edit": 36}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-02T10:51:56.684623+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse)
+[2026-09-02T10:51:56.851524+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T11:11:00.336010+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T11:11:01.630042+00:00] OpenCode export: Exporting session: ses_f9e40b88cffesSzknb1eFPiSFP
+[2026-09-02T11:11:01.680205+00:00] Ende: Exitcode=0; Status=success; Turns=93; Tokens=6432032; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/anforderungen.md

@@ -0,0 +1,64 @@
+## 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 | 16 | 19,8 % |
+| SyRS | 30 | 37,0 % |
+| SwRS | 35 | 43,2 % |
+| **Gesamt** | **81** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 19 | 23,5 % |
+| Schnittstelle | 19 | 23,5 % |
+| Daten | 18 | 22,2 % |
+| Sicherheit | 15 | 18,5 % |
+| nicht-funktional | 10 | 12,3 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 137 |
+| davon `PRIMÄR` | 72 (52,6 %) |
+| davon `SEKUNDÄR` | 54 (39,4 %) |
+| davon `KONTEXT` | 11 (8,0 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 64 (79,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 75 | 92,6 % |
+| workaround | 2 | 2,5 % |
+| sonderfall | 4 | 4,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 67 | 82,7 % |
+| als `HYPOTHESE` gekennzeichnet | 14 | 17,3 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 31 | 38,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 11 | 13,6 % |
+
+### 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 27 ungedeckt: StRS-11, SyRS-29, SwRS-30 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/combined_prompt.md

@@ -0,0 +1,174 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## 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. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**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.
+- **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)
+
+```text
+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)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+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?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> 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.
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
+Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
+Webzugriff.
+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 16\qwen\qwen3.8-flash-next\solo\high\03_Lauf_2026-09-02_125154_v13.0.0-af37\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-02T13:11:01.6994339+02:00

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/opencode-config.json

@@ -0,0 +1,230 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "provider": {
+    "tensorx": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "TensorX",
+      "options": {
+        "baseURL": "https://api.tensorx.ai/v1"
+      },
+      "models": {
+        "qwen/qwen3.8-flash-next": {
+          "name": "Qwen 3.8 Flash Next",
+          "limit": {
+            "context": 262144,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.2": {
+          "name": "GLM 5.2",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.3-flash": {
+          "name": "GLM 5.3 Flash",
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "moonshotai/kimi-k3": {
+          "name": "Kimi K3",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          }
+        }
+      }
+    }
+  },
+  "model": "tensorx/qwen/qwen3.8-flash-next",
+  "permission": {
+    "*": "deny",
+    "read": "allow",
+    "glob": "allow",
+    "grep": "allow",
+    "list": "allow",
+    "edit": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "external_directory": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "bash": {
+      "*": "allow",
+      "rm *": "deny",
+      "rmdir *": "deny",
+      "mv *": "deny",
+      "cp *": "deny",
+      "dd *": "deny",
+      "truncate *": "deny",
+      "chmod *": "deny",
+      "chown *": "deny",
+      "ln *": "deny",
+      "tee *": "deny",
+      "sed -i*": "deny",
+      "git checkout*": "deny",
+      "git restore*": "deny",
+      "git clean*": "deny",
+      "git reset*": "deny",
+      "git add*": "deny",
+      "git commit*": "deny",
+      "git push*": "deny",
+      "git fetch*": "deny",
+      "git pull*": "deny",
+      "git remote*": "deny",
+      "dotnet *": "deny",
+      "msbuild *": "deny",
+      "npm install*": "deny",
+      "nuget *": "deny",
+      "Remove-Item *": "deny",
+      "Move-Item *": "deny",
+      "Copy-Item *": "deny",
+      "New-Item *": "deny",
+      "Set-Content *": "deny",
+      "Add-Content *": "deny",
+      "Clear-Content *": "deny",
+      "Out-File *": "deny",
+      "Set-ItemProperty *": "deny",
+      "Rename-Item *": "deny"
+    },
+    "task": "deny",
+    "webfetch": "deny",
+    "websearch": "deny",
+    "skill": "deny",
+    "question": "deny"
+  },
+  "agent": {
+    "build": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "primary"
+    },
+    "general": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "subagent"
+    },
+    "explore": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "subagent"
+    }
+  },
+  "default_agent": "build"
+}

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/high/03_Lauf_2026-09-02_125154_v13.0.0-af37/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-02T12:51:54.8940173+02:00