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>
2026-09-02 16:21:31 +02:00
parent 6c5c26a2e4
commit e2c3a0e8f8
135 changed files with 102006 additions and 17 deletions
@@ -0,0 +1,5 @@
+[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
+[2026-09-02T11:11:03.862020+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=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
+[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
@@ -0,0 +1,221 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Baseline, prompt-only). Stand: nach Konsistenzbereinigung.
+Stufen: **tief** = mehrere Anforderungen inkl. verifizierter Durchsetzungsstellen; **mittel** = eigene Anforderung(en) mit PRIMÄR-Beleg; **flach** = Modulinventar + Stichprobe (API-Sicht), keine/eine Requirement; **nicht analysiert** = mit Begründung.
+
+## 1. Ergebnisübersicht
+
+| Kennzahl | Wert |
+|---|---|
+| Anforderungen gesamt | 199 (StRS 16, SyRS 49, SwRS 134) |
+| Belegzeilen | 323 (davon 256 PRIMÄR, Rest SEKUNDÄR/KONTEXT) |
+| Anforderungen ohne Beleg | 0 |
+| Anforderungen ohne Übernahmewürdigkeit | 0 |
+| Hypothesen | 23 (5 SyRS, 18 SwRS, 0 StRS) → Hypothesen.md |
+| Konsolidierungskandidaten | 165 |
+| Verdikte ≠ „übernehmen" | 31 (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischformen 6) |
+| Analysierte Module (Inventar) | 117 von 117 (=100 %); nicht-analysiert-Anteil 0 % (Ziel ≤10 % eingehalten) |
+
+## 2. Modulinventar und Abdeckung
+
+### 2.1 Backend-Fachmodule `src\backend\Centron.BL\` (88 Module, ohne bin/obj/Properties/Resources)
+
+| Modul | .cs | Stufe | Anf. | Kernsatz |
+|---|---|---|---|---|
+| Administration | 959 | tief | 42 | Rechte, Logins/2FA, Lizenzen, Settings, Config-DB, Customizing, Diagnostik, Themes, KI |
+| Sales | 248 | tief | 24 | Belegfluss, Rechnungen, Mahnen, Zahlungen, Helpdesk/SLA, Shop-Preisstellung |
+| WebServices | 464 | mittel | 4 | *WebServiceBL-Schicht als REST-Backend (strukturell analysiert, Details je Fachbereich offen) |
+| Warehousing | 40 | mittel | 2 | Kommissionierung/Barcode mit Rechteprüfung, EK-Fortschreibung |
+| Accounts | 29 | mittel | 4 | Account-Stamm, Nummernvergabe, Filterzwang für Web-Accounts |
+| EDI | 27 | mittel | 1 | EDIDispatcher: Bestellungen hinaus, Antworten herein |
+| DataExchange | 23 | mittel | 5 | Buchhaltungsexport (DATEV/SAP), E-Rechnung, Exportkonfiguration |
+| Mail | 20 | mittel | 1 | austauschbare Mail-Protokollclients, verschlüsselte Secrets |
+| Statistics | 16 | mittel | 1 | Cache-Statistiken + benutzereigene Definitionen |
+| Services | 11 | mittel | 1 | CachedTableBL-Selbstreparatur/Sofortaktualisierung |
+| EmployeeArea | 9 | mittel | 5 | Employee↔AppUser-Mapping, Verfügbarkeit, Dispatcher, Abteilungen, Einstellungen |
+| Finances | 9 | mittel | 1 | PaymentsBL-Rückbuchung über zentralen Buchungspunkt |
+| CustomerArea | 7 | mittel | 1 | Branchenzuweisungen atomar ersetzen |
+| Purchasing | 4 | mittel | 2 | Bestellvorschlagsliste, bereichsübergreifender Lieferantenexport |
+| TaskManager | 4 | mittel | 2 | wiederkehrende Aufgaben mit Lizenz-/Aktionsvalidierung |
+| MyDay | 7 | flach | 1 | Tagesplanungs-Batches mit gemeinsamer BatchId |
+| Production | 2 | flach | 2 | Fertigungsaufträge filterbar; Lizenzpflicht |
+| NexusTicketViews | 1 | flach | 2 | Ticket-Ansichten mit Besitzer-/Namensregeln |
+| CountryArea | 2 | mittel | 3 | Inlandsland, Defaultland, EZB-Kursimport |
+| IndexSearch | 7 | flach | 1 | deutsche Volltextsuche (Stemming, ALL-Semantik) |
+| ReportEngine | 26 | mittel | 1 | PDF-Strategien mit PDF/A3-Fallback; Berichte/Archivierung |
+| RiverDivo | 4 | flach | 1 | Gegenstelle externes Ticketsystem (River Suite) |
+| WebLinks | 4 | flach | 1 | Weblink→CRM-Aktivität |
+| Modules | 3 | flach | 1 | Modulstamm-Autoanlage, Favoriten |
+| CheckListArea | 3 | flach | 1 | Checklisten-Pflicht-Caption, transaktional |
+| Mailings | 2 | flach | 1 | Mailing-Gesamtaggregat laden |
+| Notifications | 2 | flach | 1 | Empfängerlisten-Sync + Meldungs-Cleanup |
+| NexusNotifications | 2 | flach | 1 | rohe SQL-Verwaltung je Empfänger |
+| MyCentron | 4 | flach | 1 | benutzergetrennte Dashboardcontainer |
+| TextModuleArea | 2 | flach | 1 | Textbaustein-Resolver benutzer>kunde>global |
+| TradePool | 2 | flach | 1 | Handelspool-XML-Import |
+| Urls | 2 | flach | 1 | durchsuchbare Objekt-URLs |
+| ToDoArea | 2 | flach | 1 | zentraler ToDo-Typkatalog (>30 Objektarten) |
+| SelfCare | 2 | flach | 1 | Formular→Helpdesk-Ticket (Kette teiloffen) |
+| Integrations | 2 | flach | 1 | ElectronicSales-Gruppen/Rollen-Spiegel (Hypothese) |
+| CPra | 2 | flach | 1 | c-pra-Token/Webhooks |
+| WebSuite | 5 | flach | 1 | Web-Einstellungen nach Login-Art getrennt |
+| PasswordManagementArea | 6 | flach | 1 | Alt-Passwortverwaltung (Hypothese: Nutzung offen) |
+| Security | 1 | flach | 1 | PDF-Signatur mit Zertifikatskonfiguration |
+| TwoFactorAuthenticator | 1 | flach | 1 | personengebundener 2FA-Schlüssel (Erzwingerstelle Hypothese) |
+| PasswordManager | 1 | flach | 1 | Export nur mit Recht/Lizenz/Masterkey |
+| DocumentationArea | 1 | flach | 1 | interne Doku nur mit Leserecht |
+| Tags | 1 | flach | 1 | Tag-Reaktivierung beim Verschlagworten |
+| Tapi | 1 | flach | 1 | CTI-Rufnummern-Suchkaskade |
+| Outlook | 1 | flach | 1 | Kundensuche nach Gerätenummer (Modulminimal) |
+| SocialMedia | 1 | flach | 1 | Kommentare/Likes via DB-Prozeduren (Hypothese) |
+| VideoPortal | 1 | flach | 1 | Videozuweisung rechtsgeprüft + ToDo-Kopplung |
+| DocuBoard | 3 | flach | 1 | Partner-Aggregat-Speicherung |
+| AppointmentRequests | 1 | flach | 1 | Terminanfrage-Antwort gegen Exchange |
+| Calendar | 1 | flach | 1 | Kalender-/Outlook-Sync-Einstellungen |
+| Chats | 1 | flach | 1 | Chat-Guards (250 Zeichen, Autor, Soft-Delete) |
+| MassUpdate | 1 | flach | 1 | Massenänderungs-Vorlagen (Rechte offen) |
+| Processes | 1 | flach | 1 | Prozessmodell-Validierung/Atomarität |
+| ExpectedEvents | 1 | flach | 1 | Überwachungsdefinitionen mit Löschkaskade |
+| Devices | 1 | flach | 1 | Geräte-Soft-Delete mit Protokoll |
+| Logistics | 1 | flach | 1 | Umlagerungsprotokoll validiert |
+| Buying | 1 | flach | 1 | Distributor-Autoanlage bei Import |
+| ProductMatrix | 1 | flach | 1 | Kunden-Produktmatrix mit Historie |
+| Projects | 1 | flach | 1 | nur Lese-API (Hypothese: auslaufend) |
+| TicketProjects | 1 | flach | 1 | Nummernkreis + Soft-Delete-Aufgaben |
+| Time | 1 | flach | 1 | Zeiterfassungs-Settings (Zweck offen) |
+| Transactions | 1 | flach | 1 | Transaktionen je Benutzer (Zweck offen) |
+| VoucherManagement | 1 | flach | 1 | Gutschein-Barcodes per NamedQuery (Hypothese) |
+| ExternalHelpdesk | 1 | flach | 1 | Config-CRUD je Kunde/Kundenort |
+| ExternalToolsBL | 1 | flach | 1 | externe Tools mit Variablenersetzung |
+| ItPlanner | 1 | flach | 1 | virtuelle Checklistenkategorien-Sync |
+| ObjectExternalReferences | 1 | flach | 1 | typisierte Fremdsystem-Referenzen |
+| Telemetry | 1 | flach | 1 | Telemetrie-Buckets mit Upload-Markierung |
+| WebVersion | 1 | flach | 1 | Versionsauskunft |
+| Reporting | 1 | flach | 1 | Legacy-Report-BLOB-Verwaltung |
+| Gateway | 1 | flach | 1 | Custom-Gateway openTRANS (Hypothese) |
+| Customizations | 1 | flach | 1 | Custom-Tabellen-Platzhalter |
+| MailScanner | 1 | flach | 1 | VMA-Profile recht+verschlüsselt |
+| SystemArea | 1 | flach | 1 | Systemzähler-Einzelinstanz |
+| ArtificialIntelligence | 25 | mittel | 1 | KI-Chat-Historie; Provider-Familie (OpenAI/Gemini/Mistral/Claude) |
+| Accounting | 1 | flach | 0 | BankAccount-CRUD inkl. Belegrückgriff (gelesen, keine eigene Requirement) |
+| BusinessPartner | 2 | flach | 0 | Lieferanten-Suche/Anlagen-Buchungen (gelesen; Datenmodell in StRS-005) |
+| Core | 2 | flach | 0 | CryptoUtils, Variablen-Ersetzung (gelesen) |
+| Exceptions | 1 | flach | 0 | TicketExpiredException (gelesen) |
+| GUI | 6 | flach | 0 | UserGrid/ImportOrder/UiProfile (APIs gelesen) |
+| Helpers | 6 | flach | 0 | Graph/PDF/Word/Image-/String-Helfer (APIs gelesen) |
+| Mobile | 1 | flach | 0 | MobileEmployee-Lesen inkl. Bild (gelesen) |
+| Start | 1 | flach | 0 | Mapping-Start/ConnectionString (gelesen) |
+| Storage | 2 | flach | 0 | StorageBL komplett auskommentiert („obsolete"), nur statischer InventoryArticlePool |
+| Tools | 1 | flach | 0 | ToolBL nur ChangeTextFormat (gelesen) |
+| ChangeTracking | 1 | flach | 0 | ImportHistoryBL; Kernlistener liegt unter Centron.DAO |
+| CentronNexus | 1 | flach | 0 | Nexus-Settings Get/Update (gelesen) |
+| CentronIcons | 2 | flach | 0 | Icon-/Ressourcenbestand ohne Fachlogik |
+
+### 2.2 Persistenz und Verträge
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.DAO (Mappings, NamedQueries, Repositories, ChangeTracking, UserTypes) | tief | 10 | ORM-Konventionen, Query-Pool, Audit-/Historie-Erzeugung |
+| Centron.Entities (1179 Dateien) | mittel | 4 | I3D-/Legacy-Abbildung, ObjectType-Nummern, Audit-Basisklasse |
+| Centron.Interfaces | mittel | 2 | Contract-First-Schicht (Details nur oberflächlich) |
+| Centron.Common | flach | 1 | Querschnittsbibliothek Logging/Netzwerk/Codierung |
+| src\shared\Centron.Core (TotpAuth) | flach | 1 | TOTP-Bibliothek |
+| SSMS_DB_SCHEMA.sql | mittel | 5 | RechKopf/RechPos, Zahkond, cvw_InvoiceDunnings als Datenbasis |
+
+### 2.3 Webservice (5 Projekte)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.Host (Host-Regie, Auth-Schemas, TicketHandler) | tief | 6 | globales RequireAuthorization, HttpSys/Kestrel, Dienstbetrieb |
+| Centron.Controllers (Authorization-Filter, API-Versionierung, GlobalExceptionFilter) | tief | 4 | 401/403-Filter, Namespace-Versionierung, 500-Pfad |
+| Centron.WebServices.Core (CentronWebService-Client) | flach | 1 | RESTC-Kanal, Kompression, Proxy |
+| Centron.Host.WindowsService | flach | 1 | Fehlerkapselung OnStart/OnStop |
+| c-entron.misc.ConnectionManager | flach | 1 | Diagnose-Werkzeug |
+
+### 2.4 Nexus (6 Bereiche)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| CentronNexus.Host (Program.cs) | tief | 3 | Cookie+OIDC-Registrierung, iframe/Cookie-Middleware |
+| WebCart (Kundenportal) | tief | 6 | Port-/Loginzwang, Sortiment, Preis, Prüfstufe, Ticketseiten |
+| ServiceBoard | mittel | 3 | Login-/Lizenz-/Portschutz, Kanban, TicketCache |
+| Shared (Auth, TicketCache, NotificationHub, SignalR) | tief | 6 | Open-Redirect-Schutz, AuthController, Push-Zustellung |
+| Office (PdfController/FilePreview) | flach | 1 | Cache-PDF-Auslieferung |
+| DocumentSigning + WebOffer | mittel | 3 | Signatur-/Akzeptanzstrecke, tokenierte Angebotsseite |
+
+### 2.5 Desktop (1 Modul) und APIs (9 Adapter)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.WPF.UI (Shell, Login, Module, Finances-Masken) | tief | 6 | Single-Instance, Login-Gate, Layout/Pflichtfelder/Feldvalidierung |
+| Centron.Api.Gls | flach | 2 | Sendungsupload mit Vorabvalidierung |
+| Centron.Api.Shipcloud | flach | 1 | Sendungsanlage/Carrier-Abruf |
+| Centron.Api.EbInterface | flach | 1 | eb:interface 4.3 (AT) |
+| Centron.APIs.CopDataAccess | flach | 1 | SOAP-Session-Produktdaten |
+| Centron.APIs.EgisDataAccess | flach | 2 | EGIS-Artikelsuche |
+| Centron.APIs.FinAPI | flach | 1 | PSD2-Bankdaten |
+| Centron.APIs.IcecatDataAccess | flach | 1 | Produktinhalte je EAN |
+| Centron.APIs.ITscopeDataAccess | flach | 2 | Produkte/Angebote/Deals |
+| Centron.Api.docuFORM | flach | 1 | Gerätezähler OAuth2-PKCE |
+
+### 2.6 Dokumentation/Modelle
+
+| Artefakt | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| README.md | flach | 2 | WebCart-Zieldefinition |
+| CentronRights.md | flach | 2 | Semantik einschränkender Rechte |
+
+### 2.7 Abdeckungsblatt (Stufen je Komponente)
+
+| Stufe | Module | Anteil |
+|---|---|---|
+| tief | 8 (Administration, Sales, DAO, Centron.Host, Controllers, WebCart, Shared, WPF-UI) | 6,8 % |
+| mittel | 24 | 20,5 % |
+| flach | 85 | 72,6 % |
+| nicht analysiert | 0 | 0 % |
+
+Damit ist jede Inventarzeile mindestens flach erfasst; tiefe Durchdringung liegt planmäßig bei Sicherheit, Abrechnung, Portal und Plattform.
+
+## 3. Risikorelevante Anforderungen (Sicherheit, Abrechnung, Berechtigungen)
+
+Prüfregel: jede riskante Anforderung hat PRIMÄR-Beleg der Durchsetzungsstelle **oder** ist als HYPOTHESE markiert. Ergebnis: 32/32-Sicherheitsanforderungen erfüllt (30 mit PRIMÄR, 2 als HYPOTHESE markiert).
+
+### 3.1 Zugriff & Authentifizierung (PRIMÄR-belegt)
+StRS-004 (AppRightsBL, AppUserGroupBL), SyRS-001 (UserRightAuthorizationFilter), SyRS-002 (TwoFactorAuthBL/RadiusClient/EmailValidator), SyRS-003 (CentronHostedHandler), SyRS-004 (DataSecurityBL), SyRS-005 (Authenticator/LicenseManager/TicketBL), SyRS-006 (TicketAuthenticationHandler + RequireAuthorization), SyRS-007 (Nexus Program.cs/AuthController), StRS-006/SyRS-016/SyRS-018 (ReceiptCartBL-Guards), SwRS-001 (AppRightsBL fail-closed), SwRS-003 (BasicAuthenticator), SwRS-018 (OrderCommissionBL), SwRS-024 (ProductionBL), SwRS-044 (ServiceBoard _Imports), SwRS-051 (AuthController Redirect), SwRS-053/054 (TicketAuthenticationHandler), SwRS-066/070 (docuFORM PKCE, MailScanner), SwRS-077 (VideoPortalAssignmentBL), SwRS-107 (DocumentationBL), SwRS-127 (HelpdeskBL.CheckUserRigths), SwRS-129 (FrontWindow.Login), SwRS-040 (ReceiptCartBL Rechte-/Prüfstufenguard, nachgetragen), SwRS-008 (PasswordManagerBL), SwRS-009 (DataSecurityBL Anonymisierung).
+
+### 3.2 Sicherheit mit Hypothesenstatus (offene Erzwingerstelle)
+SwRS-004 (2FA-PIN: Erzwingerstelle im Login-Ablauf offen), SwRS-005 (Alt-Passwortnutzung offen), SwRS-006 (Rechtsprüfung bei Signatur-Settings offen), SwRS-007 (Datenfilter „nur eigene Tickets" auf BL-Seite offen), SwRS-055 (TOTP-Prüfstelle offen), SyRS-019/020/021 (Token-Lebenszyklus, Servervalidierung, Cache-Id-Zugriff).
+
+### 3.3 Abrechnung/Berechtigung (PRIMÄR-belegt)
+StRS-003/StRS-011/StRS-016; SyRS-010 (ReceiptBL.UpdateReceiptNumber), SyRS-011 (HandleIsAlreadyExported/CancelInvoice), SyRS-012 (DunningRunBL transaktional), SyRS-013 (UpdateReceiptIsPaid mit ConcurrencyGuid), SyRS-014 (InvoiceSpecificLogic), SyRS-015/017 (ReceiptCartBL), SyRS-041 (Skonto), SwRS-010..014 (Storno/Preise), SwRS-019 (EK-Fortschreibung), SwRS-102 (PDF/A3), SwRS-108 (Textbausteine), SwRS-123 (Gutscheine, HYPOTHESE), SwRS-131 (Pflichtfelder).
+
+## 4. Konsistenzprüfung (Ergebnis nach Bereinigung)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Doppelte IDs | 0 (199 eindeutige IDs: StRS-001..016, SyRS-001..049, SwRS-001..134, lückenlose Sequenzen) |
+| Anforderungen ohne Belege | 0 |
+| Anforderungen ohne Übernahmewürdigkeit | 0 |
+| Verwaiste Trace-Links | 0 (vor Bereinigung: 0 toter Verweis, aber 29 semantisch falsche Eltern→Kind-Referenzen; alle korrigiert) |
+| Kind→Elter-Rückwärtsverfolgung | vollständig (100 %) |
+| Elter→Kind-Vorwärtsverfolgung | selektiv geführt; vollständige Rekonstruktion über Kind→Elter (in Traceability.md begründet) |
+| Deckungsgleiches ohne Konsolidierungsmarkierung | 0 aufgefundene Duplikatpaare bleiben unmarkiert; u.a. markiert: NumberGroupBL↔MandatoryBL (SwRS-099), AppSettings-Zwillinge (SyRS-029/SwRS-096), Abteilungs-Parallelimplementierung (SwRS-032), Alt-/Neu-Reports (SwRS-103), Portal-Rechtefamilie (SyRS-016..018) |
+| Hypothesen-Abgleich | 23 Inline-Markierungen = 23 Einträge Hypothesen.md |
+| Sicherheits-/Abrechnungsregeln | 32/32 mit PRIMÄR oder HYPOTHESE (siehe 3.) |
+| Konsolidierungszähler StRS↔SyRS↔SwRS | Geschwisterlinks SyRS-010↔044, SyRS-039↔011 als Querverweise kenntlich gemacht |
+
+## 5. Dünne Belegstellen (Nachsteuerung nötig)
+
+1. Logik außerhalb des Quellcode-Bestands: DB-Prozeduren „SocialMedia.*" (SwRS-075), NamedQuery-SQL (SwRS-123), gespeicherte Sichten.
+2. Erzwingerstellen nicht ablesbar: 2FA-PIN-Aufrufpfad (SwRS-004/055), PDF-Signatur-Settings (SwRS-006), WebCart-Ticketfilter (SwRS-007), Token-Erzeugung WebOffer (SyRS-019), Backend-Signaturvalidierung (SyRS-020), Cache-Id-Autorisierung (SyRS-021).
+3. Zweck/Nutzung unklar: Projects, Transactions, Time/TimingSettings, VoucherManagement, ElectronicSales-Sync (SwRS-119/122/121/123/134), Alt-Passwortkeywords (SwRS-005).
+4. Nebenläufigkeit/Risiken dokumentiert, aber nicht bewertet: Mahnlauf „Max+1" (SyRS-012), Auto-Sync bei Abfrage (SwRS-118), best-effort ChangeLog (SwRS-093).
+
+## 6. Selbstbewertung (absolut)
+
+- Erfasst: 199 Anforderungen; 16 StRS decken 100 % der SyRS-Eltern; jede SyRS hat 1–2 StRS-Eltern; 84 % der SwRS (113/134) nennen eine SyRS als direkten Elter, der Rest referenziert direkt die StRS (begründet: Ein-Modul-Funktionalitäten ohne Systemverhalten eigener Art).
+- Belegt: 323 Belege, davon 256 PRIMÄR (Durchsetzungsstelle), 199/199 Anforderungen mindestens ein Beleg.
+- Hypothesen: 23 (11,6 %), alle mit Prüffrage in Hypothesen.md; keine Requirement ohne Status.
+- Verworfen/abgestuft statt „übernehmen": 31 Verdikte (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischungen 6).
+- Modulinventar: 117 Zeilen, alle mit Kennsatz; Stufen: tief 8, mittel 24, flach 85, nicht analysiert 0.
+- Bekannte Grenzen des Laufs: WebServices-Schicht (464 Klassen) nur strukturell; Entities/DAO nur stichprobenartig; ReportEngine, Calendar, Statistics, Warehousing nur anzapfend; DB-Prozeduren/NamedQuery-SQL nicht im Bestand; UI (WPF/Nexus-Seiten) nur an Belegstellen gelesen; Performanz-/Verfügbarkeits-NFVs außerhalb des Quellcodes nicht messbar (deshalb 0 Benchmark-Anforderungen).
@@ -0,0 +1,95 @@
+# Glossar
+
+Fach- und Systembegriffe der c-entron ERP-Suite, wie aus den Artefakten abgeleitet. Links in eckigen Klammern zeigen auf prägende Anforderungen.
+
+## Identität, Rechte, Lizenz
+
+| Begriff | Bedeutung |
+|---|---|
+| I3D | Zentraler ganzzahliger Primärschlüssel aller Datenbankobjekte (allgegenwärtige Konvention `Id(a => a.I3D)`). [SyRS-034] |
+| Employee | Personalstammdatensatz (Mitarbeiter); eigenständige Identität neben dem Zugang. [StRS-007] |
+| AppUser | Interner Systemzugang (Login, Rechtegruppen, 2FA); per Mapping an einen Employee gebunden. [SwRS-029] |
+| Web-Account | Portalzugang eines Endkunden; dritte Identitätsart mit eigener Rechtequelle WebRights. [StRS-006] |
+| Recht / Rechtegruppe | Deklarierte Berechtigung, gruppenweise über Sichusr/Sichmemb an AppUser; Prüfung zentral über AppRightsBL.HasUserRight (Fail-closed). [SwRS-001] |
+| Einschränkendendes Recht (restricting right) | Recht, das andere Rechte entzieht; in der Admin-Gruppe nur eingeschränkt zuweisbar. [StRS-004] |
+| WebRights | Portalrechte (z. B. "Warenkorb bestellen", "Tickets abschließen"), serverseitig erzwungen. [SyRS-018] |
+| Lizenz / CentronInternal | Modulare Lizenzpflicht; interne Funktionen nur mit CentronInternal-Lizenz. [SyRS-003] |
+| Sitzungsticket | Zeitlich begrenztes Authentifizierungsticket je Anwendung (30/5/1440 Minuten). [SyRS-005] |
+| Access-Token | Personengebundener API-Nachweis (Bearer/access_token), mit Client-Kontext validiert. [SwRS-002, SwRS-054] |
+| 2FA / TOTP | Zweitfaktor per RADIUS, E-Mail-Link (Login) oder TOTP-Bibliothek (Schlüssel). [SyRS-002, SwRS-004, SwRS-055] |
+| Masterkey | AES-Master-Passwort der Konfigurations-DB zum Entschlüsseln von Secrets. [SyRS-030] |
+
+## Organisation und Mandantenmodell
+
+| Begriff | Bedeutung |
+|---|---|
+| Mandant | Rechtlich-organisatorische Oberinstanz mit eigenem Default-Land und Nummernkreisen. [StRS-009, StRS-016] |
+| Filiale (Branch) | Unterhalb des Mandanten mit genau einem Default-Lager plus Sekundärlagern. [StRS-010] |
+| Inlandsland | Über den Default-Mandanten deterministisch abgeleitetes Steuer-/Preisland. [SwRS-042] |
+| Account / Kunde / Lieferant | Neuer, maßgeblicher Adressstamm (Account*, AccountCustomer, AccountSupplier) als Migrationsziel der Altstämme Customer/Address/Supplier. [StRS-005] |
+
+## Beleg- und Zahlungswesen
+
+| Begriff | Bedeutung |
+|---|---|
+| Beleg / Belegart | Urkundentypisiertes Fachobjekt mit Kopf/Positionen (Tabelle RechKopf/RechPos), nummernkreis- und pflichtgeführt. [StRS-003, StRS-016] |
+| Belegfluss / Herkunft | Verknüpfung Ursprungs→Folgebeleg über RechPos.UrsprungI3D/UrsprungArt. [SwRS-010] |
+| Zahkond / Zahlungsbedingung | Zentral gepflegte Kondition mit Zahlungsziel und bis zu drei Skontostaffeln. [StRS-011] |
+| Skonto | Skonto1..3 (Prozent/Tage) je Zahlungsbedingung, mit Textbaustein-Vorschau gegen Testrechnung. [SwRS-012, SwRS-034] |
+| Mahnstufe | Eskalationsstufe None→1→2→3 im transaktionalen Mahnlauf über fällige aktive Rechnungen. [SyRS-012] |
+| Opos | Offene Posten; Auswertung auf derselben Belegbasis wie der Mahnlauf. [StRS-003] |
+| IsReceiptExported | Kennzeichnung "an Buchhaltung übergeben"; steuert Versionszwang und Stornoverbot. [SyRS-011] |
+| Sonderpreis / Sondervereinbarung | Kundenindividuelle Artikelvereinbarung; begrenzt das Shop-Sortiment und die Nettopreisstellung. [SyRS-017, SyRS-015] |
+| Preishierarchie | Preisfindung Vertrag > Sonderpreis > Staffelpreis, zweistufig gerundet. [SwRS-013, SwRS-014] |
+
+## Helpdesk und Organisation
+
+| Begriff | Bedeutung |
+|---|---|
+| Ticket (Helpdesk) | Servicevorgang mit Statusmaschine, SLA-Priorität, Historie und Abschluss-Checkliste. [StRS-013, SyRS-043, SwRS-127] |
+| SLA-Priorität | Aus dem Servicevertrag erzwungene Ticketpriorität inkl. abgeleitetem Fälligkeitsdatum. [StRS-012] |
+| Abschluss-Checkliste | Checkliste mit CanClose-Punkten; offen ⇒ Abschluss blockiert. [SwRS-127, SwRS-114] |
+| ToDo / Wiedervorlage | Bereichsübergreifende Aufgabenliste mit über 30 registrierten Objektarten. [StRS-014] |
+| ObjectKind / ObjectI3D / ObjectType | Typisierte Objektreferenz mit zentraler, unveränderlicher Typnummernliste. [SwRS-112] |
+
+## Portal, Kanäle und Integrationen
+
+| Begriff | Bedeutung |
+|---|---|
+| WebCart / Kundenportal | Endkunden-Selfservice (Shop, Warenkorb, Tickets, Dokumente) auf eigenem Port, nur Web-Account-Login. [SyRS-016] |
+| Prüfstufe | Vier-Augen-Freigabe im Warenkorb (bereit zur Prüfung → geprüft). [SwRS-040] |
+| ServiceBoard | Mitarbeiter-Browserarbeitsplatz im Nexus mit Login-, Lizenz- und Portschutz. [SwRS-044] |
+| WebOffer | Loginfreie, token-gesteuerte Angebotsansicht. [SyRS-019] |
+| SharedDocument / Signierstrecke | Token-basierte Dokumentenfreigabe mit Zeichnungs-/Typ-/Upload-Signatur (SEPA: IBAN-Pflicht). [SyRS-020] |
+| RESTC | Standardisierter komprimierter REST-Kanal des Zentralklienten. [SyRS-025] |
+| openTRANS | XML-Austauschformat für EDI-Bestellungen/Antworten; Custom-Gateway für Sonderfälle. [SyRS-045, SwRS-133] |
+| ZUGFeRD / XRechnung / eb:interface | Normkonforme E-Rechnungsformate (DE/AT). [SyRS-040, SwRS-058] |
+| Handelspool / EGIS / ITscope / Icecat / Cop | Distributor-/Poolquellen für Fremdarticlelnhalte und -preise. [SyRS-046] |
+| c-pra | Externer Freigabe-/Workflowdienst (Nexoware Smartflow) mit Token-Login und Webhooks. [SwRS-115] |
+| Riverbird / River Suite | Externes Ticketsystem mit Helpdesk-Gegenstelle und DB-/WebService-Trennregel. [SyRS-048, SwRS-098] |
+| docuFORM | Gerätezähler-Fernübermittlung per OAuth2-PKCE. [SwRS-066] |
+
+## Technik und Plattform
+
+| Begriff | Bedeutung |
+|---|---|
+| WebServiceBL | Service-spezifische BL-Schicht der REST-Dienste (464 Klassen). [SyRS-028] |
+| NamedQuery / NamedQueryPool | Zentral gepflegte SQL-/HQL-Abfragen statt SQL im Code. [SyRS-035] |
+| DBUpdate / ScriptEngine | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll. [SyRS-023] |
+| ChangeTracking / ChangeLog | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer (Update-only, best-effort). [SyRS-033, SwRS-093] |
+| CreatedBy/CreatedDate/CreatedVersion | Auditfelder der DBEntity-Basisklasse, Repository-erzwungen. [SwRS-110] |
+| Soft-Delete | Löschung durch Deaktivierung (IsActive/Deleted) statt Zeilenentfernung. [SwRS-023, SwRS-120] |
+| Nummernkreis (NumberGroup) | Fortschreibender Zähler je Mandant/Filiale/Belegart mit Intervall und Delegation. [SyRS-044, SwRS-099] |
+| HostedService / ExecuteServices | Hintergrunddienste, zentral per Konfigurationsflag schaltbar. [SyRS-022, SwRS-084] |
+| TicketCache (Nexus) | Prozessweiter Singleton-Cache mit HostedService-Synchronisation. [SyRS-037] |
+| AppSetting / ApplicationSetting | Zwei Settings-Generationen mit fehlertolerantem On-Demand-Default. [SyRS-029, SwRS-096] |
+| DSGVO-Löschung / Anonymisierung | Rechtegebundene Nullung personenbezogener Ansprechpartnerfelder mit Löschprotokoll. [SyRS-004, SwRS-009] |
+
+## Arbeitsbegriffe dieser Spezifikation
+
+| Begriff | Bedeutung |
+|---|---|
+| PRIMÄR / SEKUNDÄR / KONTEXT | Belegklassen: Durchsetzungsstelle im Quelltext / Struktur- oder Modellbeleg / dokumentarischer Kontext. |
+| HYPOTHESE | Status: fachliche Regel plausibel, aber Durchsetzung/Zweck nicht vollständig artefaktbelegt; offen in Hypothesen.md. |
+| Übernahmewürdigkeit | Verdikt für das Migrationsziel: übernehmen / Workaround / Sonderfall / veraltet / unklar. |
+| Konsolidierung | Markierung von Anforderungen, die inhaltlich zusammenzuführen sind (Duplikate/Parallelimplementierungen). |
@@ -0,0 +1,102 @@
+# Hypothesen-Liste
+
+Enthält exakt die Anforderungen mit `Status: HYPOTHESE` aus StRS.md, SyRS.md und SwRS.md (Abgleich: 0 StRS, 5 SyRS, 18 SwRS = 23). Zu jeder Hypothese: Grund der Markierung und offene Frage zur Bestätigung.
+
+## SyRS
+
+### SyRS-019 – Token-basierte Angebotsansicht ohne Login
+- Offen: Token-Erzeugung, Ablauf und Rate-Limiting sind nicht nachgewiesen; der Token-Erzeugungscode wurde nicht gefunden.
+- Prüfen: Erzeugungsstelle des Receipt-Access-Tokens incl. Gültigkeitsdauer und Wiederverwendungsschutz.
+
+### SyRS-020 – Signatur- und Akzeptanzstrecke für freigegebene Dokumente
+- Offen: serverseitige Validierung außerhalb der UI (CanAccept) nicht nachgewiesen.
+- Prüfen: Confirm/Decline-Endpunkte im Backend auf unabhängige Signatur-/IBAN-Prüfung.
+
+### SyRS-021 – PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt
+- Offen: Zugriffskontrolle auf Cache-Ids nicht sichtbar.
+- Prüfen: `getcachedfile/{id}/{filename}` mit fremder/erratener Cache-Id (Authorisierung, Ratenbegrenzung).
+
+### SyRS-025 – Standardisierter komprimierter REST-Kanal „RESTC"
+- Offen: „unbegrenztes Timeout" nur durch Kommentar belegt.
+- Prüfen: tatsächliche Timeout-/CancellationToken-Implementierung des CentronWebService-Clients.
+
+### SyRS-039 – Buchhaltungsexport in austauschbare Zielsystemformate
+- Offen: Detailregeln je Zielformat (DATEV, SAP, ...) nicht analysiert; nur Struktur und Default-Regel belegt.
+- Prüfen: Format-Builder je Zielsystem inkl. Kontenfindung und Stornologik.
+
+## SwRS
+
+### SwRS-004 – Prüfung des personengebundenen Zwei-Faktor-Schlüssels
+- Offen: aufrufende Erzwingerstelle im Login-Ablauf nicht nachgewiesen.
+- Prüfen: alle Login-Endpunkte/Masken daraufhin, ob `ValidateAuthenticationPin` zwingend aufgerufen wird.
+
+### SwRS-005 – Alt-Passwortverwaltung (Keywords) – Migrationsbedarf
+- Offen: keine Belege für aktive Nutzung (UI-/Aktivierungsnachweis fehlt).
+- Prüfen: Referenzsuche nach Konsumenten; Entsorgung entscheiden.
+
+### SwRS-006 – Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration
+- Offen: Rechtsprüfung beim Pflegen der Signatur-Einstellungen nicht im Detail verifiziert.
+- Prüfen: Save-Pfad von `PdfSigningBL` auf Rights-Guard.
+
+### SwRS-007 – Ticketansichten im Kundenportal nach Web-Rechten differenzieren
+- Offen: eigentliche Datenfilterung „nur eigene Tickets" nicht im Detail nachgewiesen.
+- Prüfen: BL-Seite der Ticketlisten im WebCart auf WebAccount-/Vertriebsgebietsfilter.
+
+### SwRS-035 – Preis- und Rabatttransparenz im Shop
+- Offen: Priorisierung von Sondervereinbarungen innerhalb der Preisfindung nicht vollständig nachverfolgt.
+- Prüfen: `ReceiptPriceHelper`-Kette bei gleichzeitiger Sondervereinbarung + Staffelpreis.
+
+### SwRS-036 – SelfCare-Formular erzeugt Helpdesk-Ticket
+- Offen: Trigger→Ticket-Ausführungskette nicht vollständig verfolgt.
+- Prüfen: ActionHandler-Kette vom Formular-Save bis zur Helpdesk-Anlage.
+
+### SwRS-046 – Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl
+- Offen: fachliche Vervollständigung unklar.
+- Prüfen: Rückfrage an Fachbereich Produktion; Seiten-Rohtext lesen.
+
+### SwRS-054 – Client-Kontext (IP, API-Methode) in der Access-Token-Validierung
+- Offen: konkrete IP-/Methoden-Bindungsregel in `AccessTokenBL.ValidateToken` nicht eingesehen.
+- Prüfen: ValidateToken-Quelltext inkl. Edge Cases (Proxy-IP, Methodswechsel).
+
+### SwRS-055 – TOTP-Zwei-Faktor-Bibliothek im Plattformkern
+- Offen: erzwungene Prüfstelle im Login-Pfad nicht gezeigt.
+- Prüfen: Konsumenten von `Totp.cs` im Anmelde-/Einstellungen-Pfad.
+
+### SwRS-056 – Schnittstellenmodul als Contract-First-Schicht
+- Offen: Einzelinterface-Inhalte nur oberflächlich geprüft.
+- Prüfen: Stichprobe der Interface-Definitionen gegen Implementierungen.
+
+### SwRS-057 – Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung)
+- Offen: Detailverhalten der Klassen nicht gelesen.
+- Prüfen: AESCryptoLogic-Schlüsselherkunft und Logging-Rotation.
+
+### SwRS-075 – Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren
+- Offen: Kernlogik liegt in DB-Prozeduren, deren Inhalt nicht im Artefaktbestand liegt.
+- Prüfen: Prozeduren „SocialMedia.*" aus SSMS-Export oder Server beschaffen.
+
+### SwRS-119 – Projektliste mit Erstellungsdatumfilter (rumpfhaft)
+- Offen: Save/Delete nirgends belegt; Modul möglicherweise auslaufend.
+- Prüfen: Referenzsuche nach `ProjectBL`-Konsumenten.
+
+### SwRS-121 – Zeiterfassungs-Stammeinstellungen pflegen
+- Offen: fachlicher Zweck der Settings nicht ableitbar (keine Konsumenten belegt).
+- Prüfen: Konsumenten von `TimingSetting` identifizieren (Timer/CTime).
+
+### SwRS-122 – Benutzerbezogene Transaktionen mit Kategorie-Details
+- Offen: Verwendungszweck nicht aus Artefakten belegt.
+- Prüfen: UI-/Webservice-Konsumenten der TransactionBL.
+
+### SwRS-123 – Aktive Gutschein-Barcodes per NamedQuery
+- Offen: SQL im NamedQuery-Pool; Zustandssemantik nicht verifizierbar.
+- Prüfen: NamedQuery `VoucherManagementGetVoucherArticles` + Flags gegen Testdaten.
+
+### SwRS-133 – Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen
+- Offen: Methodenumfang nicht gelesen; REST-Aufrufverbindung nur vermutet.
+- Prüfen: `CustomGatewayBL`-Methoden und `CentronRestService.CustomGateway.cs` durchgehen.
+
+### SwRS-134 – Externe ElectronicSales-Gruppen/Rollen lokal spiegeln
+- Offen: eigentlicher Sync-Abruf liegt außerhalb des Moduls; End-to-End-Verhalten unbelegt.
+- Prüfen: Sync-Initiator (Hintergrunddienst/Webservice) identifizieren.
+
+## Begründung der Hypothesen-Quote
+Die 23 Hypothesen betreffen überwiegend (a) Logik außerhalb des Quellcode-Bestands (DB-Prozeduren, NamedQuery-SQL, externe Systeme), (b) nicht gelesene Konsumenten-/Erzwingerstellen und (c) möglicherweise auslaufende Module. Alle Sicherheits- und Abrechnungsanforderungen mit zweifelhaftem Durchsetzungsbeleg sind markiert; keine StRS-Hypothese, weil jede StRS mehrere unabhängige PRIMÄR-Belege hat.
@@ -0,0 +1,345 @@
+# StRS - Stakeholder Requirements Specification
+
+Quelle: c-entron ERP-Suite (Reverse Requirements Engineering, ISO/IEC/IEEE 29148:2018).
+Alle Pfade relativ zum Arbeitsverzeichnis. Belegklassen: PRIMÄR / SEKUNDÄR / KONTEXT.
+
+---
+
+ID:            StRS-001
+Titel:         Ein gemeinsames ERP-System für alle Fachprozesse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        ERP-Anwender (Vertrieb, Einkauf, Lager, Service, Finanzen)
+Vorbedingung:  Client ist gestartet, Benutzer ist angemeldet
+Fakt:          WPF-Shell `FrontWindow` exportiert `OpenModule/CloseModule/DockModule`; unter `src\centron\Centron.WPF.UI\Modules\` existieren 29 Fachmodule (Finances, Helpdesk, Warehousing, Production, ...), jedes mit Modul-Controller; das Webfront CentronNexus ergänzt Browser-Zugriffe.
+Aussage:       Das System soll alle ERP-Fachprozesse (Angebot bis Rechnung, Einkauf bis Lager, Helpdesk bis Finanzen) in einer gemeinsamen, modular erweiterbaren Anwendung bereitstellen.
+Ergebnis:      Alle Fachbereiche sind über eine Shell mit öffn-/schließbaren Modulen erreichbar; kein Fachbereich läuft als Insellösung.
+Belege:
+  - [PRIMÄR] src\centron\Centron.WPF.UI\FrontWindow.xaml.cs, OpenModule/CloseModule/DockModule - Begründung: zentraler Modulvertrag der Gesamtleistung
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\ (29 Modulordner), src\centron\Centron.WPF.UI.Extension\Modules\ICentronAppModule.cs - Begründung: Modularchitektur als Systemprinzip
+Prüfidee:      Jedes der 29 Fachmodule lässt sich ohne Neustart öffnen, andocken und schließen.
+Tracelinks:    SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - modulare Gesamt-ERP-Idee ist das tragende Produktversprechen
+Status:        belegt
+
+---
+
+ID:            StRS-002
+Titel:         Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Endkunde eines c-entron-Kunden (Web-Account), Kundenadministrator
+Vorbedingung:  Mandant hat WebCart-Lizenz, Kunde besitzt Sonderpreise und Web-Accounts
+Fakt:          README: "The webcart is a feature primarily intended for the customers of our customers"; Portal unter `/customerportal` mit Tickets, Formularen, Dokumenten, Belegen/Verträgen sowie Shop/Warenkorb; Bestell-/Prüfrechte werden serverseitig in `ReceiptCartBL` erzwungen.
+Aussage:       Das System soll Endkunden den kompletten Selbstbedienungspfad (Sonderpreis-Sortiment → Warenkorb → Bestellung, Tickets/Formulare/Dokumente) ohne ERP-Benutzer öffnen, wobei der Kundenadministrator Rechte und Benutzer selbst verwaltet.
+Ergebnis:      Bestellungen und Servicevorgänge erreichen das ERP ohne manuelle Erfassung durch den c-entron-Kunden.
+Belege:
+  - [SEKUNDÄR] README.md, Zeilen 31-36 - Begründung: dokumentiertes Ziel des WebCart
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Rechte-/Portprüfungen (Zeilen 133, 859-864) - Begründung: der Selbstbedienungspfad ist serverseitig erzwungen implementiert
+  - [SEKUNDÄR] src\nexus\CentronNexus\WebCart\CustomperPortalHomePage.razor, Route `/customerportal` - Begründung: Portalbündel als eigene Startseite
+Prüfidee:      Durchlauf ohne ERP-Benutzer: Shop-Suche → Warenkorb → Bestellung mit Bestellrecht; Formular erzeugt Helpdesk-Ticket.
+Tracelinks:    SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Wachstums-/Entlastungsziel
+Status:        belegt
+
+---
+
+ID:            StRS-003
+Titel:         Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Debitorenbuchhaltung
+Vorbedingung:  Auftrag oder Lieferschein mit Positionen existiert
+Fakt:          `ReceiptProgressionBL.GetRelatedItemsForObject` ermittelt Ursprungs-/Folgebelege über `RechPos.UrsprungI3D/UrsprungArt`; `InvoiceSpecificLogic` deklariert `CanBeForwardedFrom/Into`; Mahnwesen/Opos greifen auf dieselbe RechKopf-Basis zu (View `cvw_InvoiceDunnings`).
+Aussage:       Das System soll jeden Beleg über seine Positionsherkunft lückenlos mit Ursprungs- und Folgebelegen verknüpfen und diese Kette für Fakturierung, Mahnwesen und Debitorensteuerung nutzbar machen.
+Ergebnis:      Zu jeder Rechnung sind Vorbelege und Weiterverarbeitungen eindeutig bestimmbar; nur überfällige aktive Rechnungen erreichen Mahn-/Opos-Läufe.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs, GetRelatedItemsForObject/CreateOriginReceiptsSql - Begründung: Belegkette technisch über alle Belegarten erzwungen
+  - [SEKUNDÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs, CanBeForwardedFrom/Into (Zeilen 279-280) - Begründung: definierte Übergänge des Belegflusses
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, View [dbo].[cvw_InvoiceDunnings] - Begründung: Auswertungen setzen auf derselben Belegbasis auf
+Prüfidee:      Auftrag → Rechnung; beide erscheinen im Belegfluss; bezahlte Rechnung taucht im Mahnlauf nicht auf.
+Tracelinks:    SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041
+Konsolidierung: Kandidat: Sammelthema "Belegfluss Auftragsabwicklung" mit Lieferschein/RMA-Verzweigungen (ReceiptProgressionBL)
+Übernahmewürdigkeit: übernehmen - tragendes Prinzip der Auftragsabwicklung
+Status:        belegt
+
+---
+
+ID:            StRS-004
+Titel:         Wer darf was - selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Benutzer mit Recht UserRightsManagement; Administratoren
+Vorbedingung:  Anmeldung an der c-entron-Verwaltung
+Fakt:          `AppRightsBL.SaveRightGroup` prüft `HasUserRight(UserRightsManagement)` und bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` die Filialzugehörigkeit; `DeleteRightGroup` verbietet das Löschen der Gruppe I3D==6/"Administratoren"; in der Admin-Gruppe sind nur freigegebene einschränkende Rechte zuweisbar.
+Aussage:       Das System soll das Anlegen, Ändern und Löschen von Rechtegruppen nur berechtigten Benutzern gestatten, bei Filialbindung auf die eigene Filiale beschränken und die Administratorengruppe gegen Löschung/Entrechtung schützen.
+Ergebnis:      Nicht berechtigte/filialfremde Anfragen werden abgewiesen; Admin-Gruppe bleibt erhalten.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs, SaveRightGroup/DeleteRightGroup - Begründung: exakte Durchsetzungsstellen inkl. Bedingungen
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppUserGroupBL.cs, IsAdministratorGroupI3D (`groupI3D == 6`) - Begründung: harter Admin-Gruppenschutz
+  - [SEKUNDÄR] CentronRights.md, Abschnitt "This is a restricting right" - Begründung: Fachsemantik einschränkender Rechte
+Prüfidee:      Benutzer ohne UserRightsManagement legt Gruppe an → Fehler; Admin-Gruppe löschen → Fehler; filialfremde Gruppe bei MANAGE_RIGHTS_ONLY_OWN_BRANCH → Fehler.
+Tracelinks:    SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klare Gewaltenteilung und Selbstschutzregel
+Status:        belegt
+
+---
+
+ID:            StRS-005
+Titel:         Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Datenverantwortliche, Systemarchitektur
+Vorbedingung:  Altstruktur (Customer/Address/ContactPerson) und neuer Account-Stamm koexistieren
+Fakt:          Entities `CustomerArea\Customer.cs` (DeliveryConditionI3D) und `Accounts\AccountCustomer.cs` (ReceiptConditionDeliveryI3D) führen Parallelfelder; `Supplier` (Businesspartner) und `AccountSupplier` (Accounts) führen Frachtfelder doppelt; `AccountMigrationBL` nutzt NamedQuery "MigrateWebAccountsFromOldCustomerStructure".
+Aussage:       Das System soll Kunden-, Liefer- und Ansprechpartnerdaten an einer maßgeblichen Stelle (Account-Stamm) führen; das Zielsystem überführt die Altbestände (CustomerArea, Supplier) und legt sie still.
+Ergebnis:      Ein Kundenstamm mit einer Konditionenquelle; keine Divergenz zwischen Supplier.Name und Account.Name/Frachtsätzen.
+Belege:
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs, DeliveryConditionI3D - Begründung: Altmodell mit Konditionsfeldern
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\Accounts\AccountCustomer.cs, ReceiptConditionDeliveryI3D - Begründung: Neumodell mit denselben Fachmerkmalen
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountMigrations\AccountMigrationBL.cs, MigrateWebAccountsFromOldCustomerStructure - Begründung: dokumentierter Migrationslauf Alt→Neu
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\Businesspartner\Supplier.cs vs. src\backend\Centron.Entities\Entities\Accounts\AccountSupplier.cs - Begründung: doppelter Lieferantendatenbestand
+Prüfidee:   Zähl-Query: Module, die noch Customer/Address (alt) lesen, vs. Account/AccountAddress; Ziel: Differenz = 0.
+Tracelinks:    SwRS-027, SwRS-028, SwRS-031, SwRS-132
+Konsolidierung: Kandidat: Muster "zwei Datenhaltungen für denselben Fachgegenstand" wie beim Prompt-Beispiel Drucker-Stammblätter vs. Assets
+Übernahmewürdigkeit: Workaround - Parallelhaltung ist Migrations-Zustand, Ziel ist der eine Stamm
+Status:        belegt
+
+---
+
+ID:            StRS-006
+Titel:         Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Endkunde (Web-Account-Login)
+Vorbedingung:  Web-Account ist mit Account/Customer verknüpft
+Fakt:          `AccountAddressBL` erzwingt `filter.AccountI3Ds = { WebAccount.AccountI3D }`; `AccountSearchBL` filtert bei `IsWebAccountLogin` auf `WebAccount.CustomerI3D`; `ReceiptCartBL.SearchArticles` begrenzt auf `WebAccount.CustomerI3D` (Zeilen 228-244).
+Aussage:       Das System soll jede Adress-, Konto-, Beleg- und Artikelsuche im Kundenportal zwingend auf den Stammkunden des angemeldeten Web-Accounts einschränken.
+Ergebnis:      Kunden sehen im Self-Service nur eigene Daten; Mandantendaten bleiben abgeschottet.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountAddressBL.cs, Filterzwang (Zeilen 75-79) - Begründung: erzwungener Mandantenzwang
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountSearchBL.cs, IsWebAccountLogin-Filter (Zeilen 294-299) - Begründung: gleiche Regel zweite Stelle
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Zeilen 228-244 - Begründung: Kundenisolierung im Shop
+Prüfidee:   Webservice-Aufruf mit Web-Account-Token; fremde Kunde-I3D im Filter muss ignoriert/abgewiesen werden.
+Tracelinks:    SyRS-016, SyRS-017, SyRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Mandantentrennung des Portals
+Status:        belegt
+
+---
+
+ID:            StRS-007
+Titel:         Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Administration, System
+Vorbedingung:  Employee existiert; Zugangsdaten werden unabhängig gepflegt
+Fakt:          `AppUserBL.GetAppUserObjectForEmployee(employeeId)`/`GetAppUserI3DForEmployee` mappen Mitarbeiter→Login; `SaveOrUpdateAppUser` führt separates Passwortargument; Web-Accounts sind dritte Identitätsart mit eigener Rechtequelle (`WebRights`).
+Aussage:       Das System soll Personalstammdaten und Zugangsdaten als getrennte Konzepte mit definierter Zuordnung führen, damit Passwort-/Lizenzverwaltung den Personalstamm nicht ändert.
+Ergebnis:      Sperrung/Änderung eines Zugangs ohne Eingriff in Personaldaten; drei Akteursidentitäten (Employee, AppUser, Web-Account) sauber unterscheidbar.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\EmployeeArea\AppUserBL.cs, GetAppUserObjectForEmployee - Begründung: explizite Mapping-Methoden belegen Zwei-Konzept-Design
+  - [SEKUNDÄR] src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs, Doku zu geteiltem I3D-Bereich von Employee/Web-Account - Begründung: Identitäten teilen sich Nummernkreise, daher Typ needed
+Prüfidee:   AppUser eines Employees sperren; Employee-Daten bleiben lesbar, Zugriffe des Logins scheitern.
+Tracelinks:    SwRS-029, SwRS-032, SwRS-052
+Konsolidierung: Kandidat: Identitätskonzepte Employee/AppUser/Web-Account im Zielsystem auf ein Identitätsmodell führen
+Übernahmewürdigkeit: übernehmen - saubere Rollen-/Identitätstrennung
+Status:        belegt
+
+---
+
+ID:            StRS-008
+Titel:         Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Disponent
+Vorbedingung:  Mitarbeiter ist aktiv (`IsActiveEmployeeCompact`-Prüfung)
+Fakt:          `EmployeeBL` bietet `SetDispatcher`, `IsActiveEmployeeCompact`, `UpdateEmployeeAvailability(employeeI3D, EmployeeAvailability)`.
+Aussage:       Das System soll je Mitarbeiter eine schaltbare Verfügbarkeit und eine Dispatcher-Eigenschaft führen und diese vor weiterleitungsrelevanten Aktionen (Ticketweitergabe, Zuteilung) prüfen.
+Ergebnis:      Tickets/Aufgaben erreichen nur verfügbare, rollengerecht eingestellte Mitarbeiter.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs, SetDispatcher/UpdateEmployeeAvailability/IsActiveEmployeeCompact (Zeilen 67-127) - Begründung: Steuerungsmethoden inkl. Aktivitätsprüfung
+Prüfidee:   Inaktiven Mitarbeiter als Dispatcher setzen → Fehlerresult; Zuweisung an Abwesenden verhindert.
+Tracelinks:    SyRS-002
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-009
+Titel:         Deterministische Länder-, Währungs- und Inlandsbasis
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:       _any user; Buchhaltung
+Vorbedingung:  Default-Mandant mit Land gepflegt; genau ein Defaultland markiert
+Fakt:          `CountryBL.GetInlandCountry` liefert `MandatorBL.GetDefaultMandator().Country` (offenes TODO zur Filialland-Prüfung); `GetDefaultCountry` filtert `f.Default`; `UpdateCurrencyRateByRateDictionary` importiert EZB-Kurse.
+Aussage:       Das System soll das für Preise/Steuern maßgebliche Inlandsland deterministisch aus dem Default-Mandanten ableiten und tagesaktuelle Wechselkurse je Währung bereitstellen.
+Ergebnis:      Belege, Steuern und Fremdwährungspreise rechnen auf einer eindeutigen Länderbasis.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, GetInlandCountry/GetDefaultCountry - Begründung: Implementierung inkl. TODO als bekannte Lücke
+  - [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, UpdateCurrencyRateByRateDictionary (EZB-XML) - Begründung: Kursimport durchgesetzt
+Prüfidee:   Default-Mandant auf zweites Land setzen; Inlandslogik neuer Belege folgt dem neuen Land.
+Tracelinks:    SwRS-041, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (TODO Filialland als Nachsteuerung)
+Status:        belegt
+
+---
+
+ID:            StRS-010
+Titel:         Filial- und Lagerstruktur je Mandant
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Administration, Logistik
+Vorbedingung:  Mandant mit Filialen angelegt
+Fakt:          `BranchBL.SaveAssignedSecondaryStocks` verwaltet je Filiale genau ein Default-Lager plus Sekundärlager atomar; `GetBranchesForSelection` stellt Pseudo-Einträge "Hauptsitz"/"Alle Filialen" bereit.
+Aussage:       Das System soll Mandanten, Filialen und Lager mit je genauem Default-Lager je Filiale abbilden und in allen Masken einheitlich auswahlbar machen.
+Ergebnis:      Deterministische Lager- und Filialzuordnung von Belegen, Beständen und Benutzern.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, SaveAssignedSecondaryStocks (Zeilen 72-154) - Begründung: Default-Lager-Rotation im Transaktionsblock
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, GetBranchesForSelection/IsBranchEqual - Begründung: einheitliche Filialfilter-Semantik
+Prüfidee:   Zweites Default-Lager setzen → altes entfällt; Filialauswahl enthält genau einen "Alle Filialen"-Eintrag.
+Tracelinks:    SwRS-030, SwRS-031
+Konsolidierung: Kandidat: Organisationskonzepte Firma (Company) vs. Mandant vs. Filiale zusammenführen
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-011
+Titel:         Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Finanz-/Einkaufsabteilung
+Vorbedingung:  Masterdatenpflege geöffnet
+Fakt:          `AssetCondition` führt bis zu drei Skonto-Staffeln (Skonto1..3 OffDay/Percent) mit verwalteten Texten; `AssetConditionBL.GetAssetConditionTextPreview` rendert Platzhalter gegen eine Testrechnung und meldet Fehler ohne Rechnungsbestand.
+Aussage:       Das System soll Zahlungs-/Lieferkonditionen mit Skonto-Staffeln zentral pflegen, in Belege, Textbausteine und E-Rechnung übernehmen und die Auswirkung per Vorschau verifizierbar machen.
+Ergebnis:      Einheitliche Konditionen für Belege/Materialgruppen; Fälligkeit und Skonto sind aus einer Quelle abgeleitet.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs, GetAssetConditionTextPreview (Zeilen 34-55) - Begründung: Skonto-Feldsemantik und Fehlerpfad belegt
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Zahkond] mit Skonto1/Skonto2, LaenPer1..3 - Begründung: Datenmodell der Skontostufen
+Prüfidee:   Zahlungsbedingung "2 % / 14 Tage, netto 30"; Rechnung speichern → Fälligkeit und Skontotext stimmen; E-Rechnung enthält SKONTO-Angaben.
+Tracelinks:    SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-012
+Titel:         SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Bearbeiter, Kunde mit Servicevertrag
+Vorbedingung:  Ticket einem Servicevertrag zugeordnet
+Fakt:          `UpdateHelpdeskBL.UpdatePriority` verwirft abweichende Prioritäten ("Die Priorität wird durch den gewählten Vertrag vorgegeben."); `GetDueDateFromPriority` leitet das Fälligkeitsdatum ab; `HelpdeskPriority.IsSLA` und `Contract.SLAPriority` verknüpfen Vertrag und Ticket.
+Aussage:       Das System soll bei SLA-Verträgen die Ticketpriorität verbindlich aus dem Vertrag ableiten und daraus das Fälligkeitsdatum automatisch berechnen; manuelle Abweichungen sind unzulässig.
+Ergebnis:      Verträge werden eingehalten; Fälligkeit/Priorität springen automatisch bei Vertragswechsel; Beteiligte werden benachrichtigt.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs, UpdatePriority (Zeilen 281-326), SetContract (Zeilen 430-455) - Begründung: Durchsetzungsstellen der SLA-Kette
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\CustomerArea\Support\HelpdeskPriority.cs, IsSLA - Begründung: SLA-Kennzeichen im Datenmodell
+Prüfidee:   SLA-Vertrag setzen, abweichende Priorität wählen → Fehler; Vertragswechsel → Priorität+DueDate springen.
+Tracelinks:    keine abgeleitete Anforderung - SLA-Kette abschließend in UpdateHelpdeskBL belegt
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Service-Vermarktungsmerkmal
+Status:        belegt
+
+---
+
+ID:            StRS-013
+Titel:         Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Interne Bearbeiter, Kunde (Web-Account)
+Vorbedingung:  Ticket existiert, Benutzer angemeldet
+Fakt:          `HelpdeskBL.GetHelpdeskRequest` prüft Vertriebsgebietsrechte (`EmployeeToSalesAreaBL`) und blendet `IsOnlyInternalVisible`-Tickets für Web-Logins mit einheitlichem Fehler "Ticket nicht gefunden!" aus.
+Aussage:       Das System soll Ticketzugriff nach internen Rechten (Vertriebsgebiet) und Kanälen (Kunde/sichtbarkeit) steuern, ohne Kunden die Existenz interner Tickets zu verraten, und jede Statusänderung historisieren.
+Ergebnis:      Berechtigte sehen Tickets, Unberechtigte erhalten einen einheitlichen Nicht-gefunden-Fehler; Statushistorie ist vollständig.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, GetHelpdeskRequest (Zeilen 113-146) - Begründung: Rechte-/Kanalfilter durchgesetzt
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, SetHelpdeskAction (Zeilen 558-609) - Begründung: Statushistorie im Speicherpfad
+Prüfidee:   Web-Account öffnet internes Ticket → CouldNotFindData; fremdes Vertriebsgebiet → RightCheckFailed; Statuswechsel erzeugt Historieneintrag.
+Tracelinks:    SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-014
+Titel:         Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        alle Fachbereiche
+Vorbedingung:  Quellvorgang (Beleg, Helpdesk, Urlaub, Kommissionierung ...) erzeugt Wiedervorlage
+Fakt:          `ToDoBL.FillObjectKindsListe` registriert über 30 `ToDoObjectKind`-Einträge (Name, Area, AssetKind); `TaskManagementTaskBL.SaveOrUpdateTask` erzwingt valide Aktion/Wiederkehr und Lizenz.
+Aussage:       Das System soll Wiedervorlagen aller Fachbereiche in einer strukturierten ToDo-Liste mit Typ/Bereich/Objektbezug führen und wiederkehrende Aufgaben nur bei valider, lizenzierter Aktion anlegen.
+Ergebnis:      Ein Einstiegspunkt zeigt bereichsübergreifende Aufgaben; keine defekten oder unlizenzierten Automationen.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\ToDoArea\ToDoBL.cs, FillObjectKindsListe (Zeilen 69-118) - Begründung: zentraler Typkatalog
+  - [PRIMÄR] src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs, SaveOrUpdateTask (Zeilen 40-97) - Begründung: Validierungs-/Lizenzprüfung
+Prüfidee:   ToDo je registriertem Typ anlegen → in Liste mit korrektem Bereichstext; Aufgabe mit ungültiger Wiederkehr → Fehlerresult.
+Tracelinks:    SwRS-074, SwRS-077, SwRS-079
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-015
+Titel:         Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann)
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit / Sicherheitsfunktionalität (ISO 25010)
+Akteur:        Prüfer, Fachanwender, System
+Vorbedingung:  Änderung an getracktem Objekt durch angemeldeten Benutzer
+Fakt:          `ChangeTrackingEventListener` (NHibernate IPreUpdateEventListener) schreibt je geänderter Property Alt-/Neuwert, Benutzer und Datum in `ChangeLog`; Repositories belegen CreatedBy/CreatedDate/CreatedVersion automatisch; Soft-Delete plus Log Tabellen (Geräte, Umlagerungen, Belegprotokolle) ergänzen.
+Aussage:       Das System soll Änderungen an als überwachungswürdig deklarierten Feldern automatisch mit Alt-/Neuwert, Benutzer und Zeitpunkt protokollieren und Herkunftsfelder (Ersteller/-zeitpunkt/-version) beim Anlegen zwangsläufig setzen.
+Ergebnis:      Auditgrundlage ohne Fachcode; Löschung erfolgt,revidierbar per Soft-Delete mit Log.
+Belege:
+  - [PRIMÄR] src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs, OnPreUpdate/CreateChangeLog (Zeilen 52-142) - Begründung: zentrale, automatische Protokollierung
+  - [PRIMÄR] src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs, CreateNewAccount (Zeilen 39-52) - Begründung: Auditfelder im Repository-Muster
+Prüfidee:   Getrackte Property ändern → genau ein ChangeLog-Satz mit korrektem Benutzer; Neuanlage setzt CreatedVersion = Assemblyversion.
+Tracelinks:    SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Audit-Basis; Lücken (kein Insert/Delete-Tracking) im Zielsystem schließen
+Status:        belegt
+
+---
+
+ID:            StRS-016
+Titel:         Lückenlose, prüfsichere Nummernvergabe (GoBD)
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Funktionale Sicherheit (ISO 25010)
+Akteur:        System bei jeder Beleg-/Stammdatenanlage
+Vorbedingung:  Nummernkreise je Mandant/Filiale gepflegt
+Fakt:          `NumberGroupBL.GetNextNumber` vergibt und fortschreibende Nummern je Mandant/Filiale; `MandatoryBL` priorisiert filialbezogene Kreise vor dem Standardmandanten und überspringt verbrauchte (`Aktuell<=0`); Vergabe ohne manuelle Eingabe in allen Belegarten.
+Aussage:       Das System soll alle Nummern (Belege, Adressen, Ticketprojekte) fortlaufend, lückenlos und mandanten-/filialbezogen aus Nummernkreisen vergeben, ohne dass Benutzer Nummern setzen können.
+Ergebnis:      Keine Doppelvergabe; Nummerierung ist revisionssicher und je Mandant/Filiale getrennt.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs, GetNextNumber/CreateNumberGroups - Begründung: zentrale Vergabestelle
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs, GetNumberGroup (ORDER BY Mandantenpriorität) - Begründung: Delegation Mandant→Filiale→Standard
+Prüfidee:   Paralleles Neuanlegen → keine Duplikate, Zähler monoton; Filiale mit eigenem Kreis wird vor Standardmandant gezogen.
+Tracelinks:    SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120
+Konsolidierung: Kandidat: Nummernkreislogik (Company) und Nummernkreis-Delegation (Mandatory) zusammenführen
+Übernahmewürdigkeit: übernehmen - GoBD-Kernanforderung
+Status:        belegt
@@ -0,0 +1,224 @@
+# Traceability-Matrix
+
+Rückwärts-/Vorwärtsverfolgung über alle 199 Anforderungen (16 StRS, 49 SyRS, 134 SwRS).
+„Verfolgung" = Inhalt des Feldes Tracelinks im jeweiligen Anforderungsblock; „Hauptartefakt" = erster PRIMÄR-Beleg (sonst SEKUNDÄR/KONTEXT). Alle Pfade relativ zum Arbeitsverzeichnis.
+
+## StRS-Ebene
+
+| StRS-ID | Titel | Verfolgung (abgeleitete Anforderungen) | Hauptartefakt |
+|---|---|---|---|
+| StRS-001 | Ein gemeinsames ERP-System für alle Fachprozesse | SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| StRS-002 | Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab | SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021 | README.md (SEKUNDÄR); ReceiptCartBL.cs (PRIMÄR) |
+| StRS-003 | Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf | SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041 | src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs |
+| StRS-004 | Wer darf was – selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz | SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
+| StRS-005 | Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen | SwRS-027, SwRS-028, SwRS-031, SwRS-132 | src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs |
+| StRS-006 | Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden | SyRS-016, SyRS-017, SyRS-018 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
+| StRS-007 | Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten | SwRS-029, SwRS-032, SwRS-052 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
+| StRS-008 | Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung | SyRS-002 | src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs |
+| StRS-009 | Deterministische Länder-, Währungs- und Inlandsbasis | SwRS-041, SwRS-042 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| StRS-010 | Filial- und Lagerstruktur je Mandant | SwRS-030, SwRS-031 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
+| StRS-011 | Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar | SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
+| StRS-012 | SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen | keine abgeleitete Anforderung (SLA-Kette abschließend in UpdateHelpdeskBL belegt) | src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs |
+| StRS-013 | Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit | SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| StRS-014 | Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln | SwRS-074, SwRS-077, SwRS-079 | src\backend\Centron.BL\ToDoArea\ToDoBL.cs |
+| StRS-015 | Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann) | SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| StRS-016 | Lückenlose, prüfsichere Nummernvergabe (GoBD) | SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs |
+
+## SyRS-Ebene
+
+| SyRS-ID | Titel | Eltern (StRS) | Kinder | Hauptartefakt |
+|---|---|---|---|---|
+| SyRS-001 | API-Aufrufe nur mit deklariertem Benutzerrecht | StRS-004 | SwRS-001, SwRS-002 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs |
+| SyRS-002 | Mehrstufiger Anmeldeprozess mit Zweitfaktor (RADIUS oder E-Mail-Link) | StRS-004, StRS-008 | SwRS-003, SwRS-004 | src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs |
+| SyRS-003 | Lizenz- und Hosted-Schranke für interne Funktionen und Modulzugriffe | StRS-004 | SwRS-006, SwRS-024 | src\webservice\Centron.Controllers\Authorization\CentronHostedAuthorization.cs |
+| SyRS-004 | DSGVO-Löschung personenbezogener Daten nur für Berechtigte, mit Protokoll | StRS-004, StRS-015 | SwRS-009 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
+| SyRS-005 | Ticketvergabe nach Rechts- und Lizenzprüfung, zeitlich befristet | StRS-004 | SwRS-003 | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs |
+| SyRS-006 | Every REST request must pass ticket/token authentication | StRS-004 | SwRS-002, SwRS-053, SwRS-054 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SyRS-007 | Nexus-Host authentifiziert per Cookie/Ticket oder OIDC und stellt Sitzung aus | StRS-004 | SwRS-044, SwRS-051 | src\nexus\CentronNexus.Host\Program.cs |
+| SyRS-008 | Umschaltung der Systemauthentifizierung auf OpenID Connect (Entra ID) | StRS-004 | – | src\nexus\CentronNexus\Configuration\OpenIdConnectConfigurationService.cs |
+| SyRS-009 | Outlook-AddIn-Einbettung mit iframe-fähiger Cookie-Policy | StRS-004 | – | src\nexus\CentronNexus.Host\Program.cs |
+| SyRS-010 | Fortlaufende Rechnungsnummern je Nummernkreis | StRS-016, StRS-003 | SyRS-044 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-011 | Rechnungsexport-Kennzeichnung steuert Änderung und Storno | StRS-003 | SwRS-011 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-012 | Mahnlauf: stufenweise Eskalation überfälliger Rechnungen, transaktional | StRS-003 | – | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs |
+| SyRS-013 | Zahlungsstatus nur über zentralen, protokollierten Buchungspunkt | StRS-003, StRS-011 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-014 | Belegweiterverarbeitung nur entlang definierter Regeln je Belegart | StRS-003 | SwRS-010 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
+| SyRS-015 | Kundenindividuelle Preise im Web-Shop mit nachvollziehbarer Rabattanzeige | StRS-002, StRS-011 | SwRS-013, SwRS-035 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-016 | Kundenportal nur für Web-Account-Login über den Kundenportal-Port | StRS-002, StRS-006 | SwRS-007, SwRS-036 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-017 | Shop-Sortiment auf aktive Sonderpreise des Kunden beschränken | StRS-002, StRS-006 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-018 | Warenkorb-Bestellung nur mit Web-Recht und Prüfstufe | StRS-002, StRS-006 | SwRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-019 | Token-basierte Angebotsansicht ohne Login | StRS-002 | – | src\backend\Centron.BL\WebServices\Sales\Receipts\ReceiptWebServiceBL.cs |
+| SyRS-020 | Signatur- und Akzeptanzstrecke für freigegebene Dokumente | StRS-002 | – | src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor |
+| SyRS-021 | PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt | StRS-002 | – | src\nexus\CentronNexus\Office\Controllers\PdfController.cs |
+| SyRS-022 | Hintergrunddienste zentral über Konfigurationsflag steuerbar | StRS-001 | SwRS-084 | src\webservice\Centron.Host\CentronHost.cs |
+| SyRS-023 | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll | StRS-001 | – | src\backend\Centron.BL\Administration\Scripts\ScriptEngineBL.cs |
+| SyRS-024 | REST-API-Versionierung und einheitliche Fehlerbehandlung | StRS-001 | – | src\webservice\Centron.Host\AspNetCore\RegisterCentronApiVersioning.cs |
+| SyRS-025 | Standardisierter komprimierter REST-Kanal „RESTC" | StRS-001 | – | src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs |
+| SyRS-026 | Plattformabhängiger Webserver-Betrieb (HttpSys/Kestrel) | StRS-001 | – | src\webservice\Centron.Host\CentronHost.cs |
+| SyRS-027 | Betrieb als Windows-Dienst mit Fehlerkapselung | StRS-001 | – | src\webservice\Centron.Host.WindowsService\CentronService.cs |
+| SyRS-028 | Service-spezifische BL-Schicht (*WebServiceBL) | StRS-001 | – | src\backend\Centron.BL\WebServices\Administration\Logins\TicketWebServiceBL.cs |
+| SyRS-029 | Zentrales Konfigurationswertesystem (AppSettings/ApplicationSettings) | StRS-001 | SwRS-096 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
+| SyRS-030 | Zentrale Konfigurations-DB mit verschlüsseltem Hotline-Masterkey | StRS-004 | – | src\backend\Centron.BL\Administration\CentronConfigDb\CentronConfigurationDbBL.cs |
+| SyRS-031 | WebService-Konfigurationsdatei mit verschlüsselten Geheimnissen | StRS-004 | – | src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfigSerializer.cs |
+| SyRS-032 | Client-Verbindungsprofile mit AES-verschlüsselten Passwörtern | StRS-004 | – | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
+| SyRS-033 | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer | StRS-015 | – | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| SyRS-034 | Einheitliches ORM-Mapping auf Legacy-Schema (PK I3D) | StRS-001 | – | src\backend\Centron.DAO\Mappings\BaseMaps.cs |
+| SyRS-035 | Zentrale SQL-Abfragen in einem NamedQuery-Pool | StRS-001 | – | src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs |
+| SyRS-036 | Rohe SQL-Zugriffe transaktionsgebunden über die ORM-Session | StRS-001 | – | src\backend\Centron.DAO\AdoNETDataAccess\RawSqlAccessDAO.cs |
+| SyRS-037 | Serverseitiger Ticket-Cache mit Hintergrund-Synchronisation | StRS-013, StRS-001 | SwRS-048 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
+| SyRS-038 | Push-Zustellung von Benachrichtigungen per SignalR | StRS-013 | SwRS-049, SwRS-050 | src\nexus\CentronNexus\Shared\Services\SignalRNotificationsService.cs |
+| SyRS-039 | Buchhaltungsexport in austauschbare Zielsystemformate | StRS-003, StRS-016 | SyRS-011, SwRS-067, SwRS-133 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
+| SyRS-040 | Normkonforme E-Rechnungsformate (ZUGFeRD/XRechnung, eb:interface) | StRS-003, StRS-011 | – | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs |
+| SyRS-041 | Zahlungsziel- und Skontoermittlung aus der Zahlungsbedingung | StRS-003, StRS-011 | SwRS-012 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-042 | Statistik-Caches mit Selbstreparatur und Sofortaktualisierung | StRS-001 | SwRS-104 | src\backend\Centron.BL\Services\CachedTableBL.cs |
+| SyRS-043 | Helpdesk-Statusmaschine als konfigurierbare Übergänge | StRS-013 | SwRS-043, SwRS-045, SwRS-047, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SyRS-044 | Nummernkreis-Delegation Mandant→Filiale→Standard | StRS-016 | SyRS-010, SwRS-026, SwRS-099 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
+| SyRS-045 | Lieferanten-EDI: Bestellungen hinaus, Antworten herein | StRS-001, StRS-003 | SwRS-016, SwRS-065 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs |
+| SyRS-046 | Fremddaten-Produktanreicherung über Distributor-/Poolschnittstellen | StRS-001 | – | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
+| SyRS-047 | Paketversand über externe Carrier-Plattformen | StRS-001 | – | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
+| SyRS-048 | Helpdesk-Gegenstelle für externes Ticketsystem (River Suite/Riverbird) | StRS-013 | – | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs |
+| SyRS-049 | Mandanten-Installationsstatus und Installer-Download | StRS-001 | – | src\backend\Centron.BL\Administration\Portal\PortalWebServiceAccessBL.cs |
+
+## SwRS-Ebene
+
+| SwRS-ID | Titel | Eltern | Hauptartefakt |
+|---|---|---|---|
+| SwRS-001 | Zentrale, gecachte Rechtsprüfung mit Fail-closed-Semantik | SyRS-001, StRS-004 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
+| SwRS-002 | Sichere Behandlung personengebundener API-Access-Tokens | SyRS-001, SyRS-006, StRS-004 | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs |
+| SwRS-003 | Passwortanmeldung nur für aktive, nicht gesperrte Konten | SyRS-002, SyRS-005, StRS-004 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs |
+| SwRS-004 | Prüfung des personengebundenen Zwei-Faktor-Schlüssels | SyRS-002, StRS-004 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs |
+| SwRS-005 | Alt-Passwortverwaltung (Keywords) – Migrationsbedarf | SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs (SEKUNDÄR) |
+| SwRS-006 | Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration | SyRS-003, StRS-003 | src\backend\Centron.BL\Security\PdfSigningBL.cs |
+| SwRS-007 | Ticketansichten im Kundenportal nach Web-Rechten differenzieren | SyRS-016, StRS-002 | src\nexus\CentronNexus\WebCart\CustomerTicketDetailsPage.razor (SEKUNDÄR) |
+| SwRS-008 | Passwort-Manager: Export nur mit Recht, Lizenz und Masterkey | SyRS-003, SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs |
+| SwRS-009 | Anonymisierung von Ansprechpartnern mit Löschprotokoll | SyRS-004, StRS-004 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
+| SwRS-010 | Weiterverarbeitungsregeln und Herkunftsbindung je Belegart | SyRS-014, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
+| SwRS-011 | Rechnungsstorno: Guard-Kette und historisierende Neufassung | SyRS-011, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs |
+| SwRS-012 | Skontoberechnung und -text je Zahlungsbedingung | SyRS-041, StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionTextReplacementBL.cs |
+| SwRS-013 | Preishierarchie der Belegposition (Vertrag > Sonderpreis > Staffelpreis) | StRS-011, SyRS-015 | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs |
+| SwRS-014 | Zweistufige Preisrundung mit artikelbezogener Genauigkeit | StRS-011, SyRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptPriceHelperBL.cs |
+| SwRS-015 | Distributoren automatisch bei Import anlegen | StRS-001 | src\backend\Centron.BL\Buying\External\DistributorBL.cs |
+| SwRS-016 | Bestellvorschlagsliste aus öffentlichem Bedarf und Mindestbestand | StRS-001, SyRS-045 | src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs |
+| SwRS-017 | Bereichsübergreifender Export von Lieferantenrechnungen/Timerleistungen | StRS-003 | src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs |
+| SwRS-018 | Rechteprüfung in Kommissionierung und Barcodeerzeugung | SyRS-001, StRS-004 | src\backend\Centron.BL\Warehousing\Commissions\OrderCommissionBL.cs |
+| SwRS-019 | Fortschreibung des Artikel-EK aus Wareneingangspreisen | StRS-003, StRS-011 | src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs |
+| SwRS-020 | Validierte Protokollierung von Lagerumlagerungen | StRS-015 | src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs |
+| SwRS-021 | Kunden-Produktmatrix mit Bewertungshistorie | StRS-001 | src\backend\Centron.BL\ProductMatrix\ProductMatrixBL.cs |
+| SwRS-022 | Fertigungsaufträge nach Maschine/Maschinenart filterbar | StRS-001 | src\backend\Centron.BL\Production\ProductionOrderBL.cs |
+| SwRS-023 | Geräteverwaltung mit Soft-Delete und Protokoll | StRS-015 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs |
+| SwRS-024 | Produktionsmanagement durchgehend lizenzgeprüft | SyRS-003, StRS-004 | src\backend\Centron.BL\Production\ProductionBL.cs |
+| SwRS-025 | Handelspool-Artikelimport aus Distributor-XML | SyRS-046, StRS-001 | src\backend\Centron.BL\TradePool\Core\TradePoolXmlLogic.cs |
+| SwRS-026 | Automatische Nummernvergabe für Account, Kunde und Lieferant | StRS-016, SyRS-044 | src\backend\Centron.BL\Accounts\AccountBL.cs |
+| SwRS-027 | Genau eine Standardadresse je Account | StRS-005 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
+| SwRS-028 | Branchenzuweisungen atomar ersetzen | StRS-005 | src\backend\Centron.BL\CustomerArea\BusinessLineBL.cs |
+| SwRS-029 | Explizite Zuordnung Employee → AppUser | StRS-007 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
+| SwRS-030 | Filialauswahl mit Pseudo-Einträgen Hauptsitz/Alle Filialen | StRS-010 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
+| SwRS-031 | Firmenübersicht als reines Lese-API | StRS-005, StRS-010 | src\backend\Centron.BL\Administration\CompanyInformations\CompanyBL.cs |
+| SwRS-032 | Abteilungen benutzerbezogen laden und pflegen (Parallelimplementierung) | StRS-007 | src\backend\Centron.BL\Administration\Employees\EmployeeDepartmentBL.cs |
+| SwRS-033 | Persistente persönliche Mitarbeitereinstellungen | StRS-001 | src\backend\Centron.BL\Administration\Employees\EmployeeSettingBL.cs |
+| SwRS-034 | Konditionstextvorschau gegen echte Testrechnung | StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
+| SwRS-035 | Preis- und Rabatttransparenz im Shop | SyRS-015, StRS-002 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SwRS-036 | SelfCare-Formular erzeugt Helpdesk-Ticket | SyRS-016, StRS-002 | src\backend\Centron.BL\SelfCare\SelfCareBL.cs |
+| SwRS-037 | Weblink-Aktion legt CRM-Aktivität für den Betreuer an | StRS-001 | src\backend\Centron.BL\WebLinks\WebLinkActionAccountActivityHandler.cs |
+| SwRS-038 | Versionsauskunft des Webservices | StRS-001 | src\backend\Centron.BL\WebVersion\VersionBL.cs |
+| SwRS-039 | Web-Einstellungen strikt nach Login-Art getrennt | StRS-006, StRS-001 | src\backend\Centron.BL\WebSuite\Administration\Settings\WebSettingBL.cs |
+| SwRS-040 | Warenkorb-Prüfstufe und Kundenadmin-Oberfläche | SyRS-018, StRS-002 | src\nexus\CentronNexus\WebCart\Helpers\UserViewModel.cs (SEKUNDÄR) |
+| SwRS-041 | Täglicher Devisenkursimport aus dem EZB-Feed | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| SwRS-042 | Inlandsland aus dem Default-Mandanten ableiten | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| SwRS-043 | Ticket-Statuswechsel per Drag-and-Drop im Kanban | SyRS-043, StRS-013 | src\nexus\CentronNexus\ServiceBoard\CachedTicketList\Components\KanbanBucket.razor |
+| SwRS-044 | ServiceBoard-Seiten durch Login-, Lizenz- und Portschutz | SyRS-007, SyRS-003, StRS-013 | src\nexus\CentronNexus\ServiceBoard\_Imports.razor |
+| SwRS-045 | Automatische Status-Defaults bei Anlage und Übernahme | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-046 | Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl | StRS-001 | src\nexus\CentronNexus\ProductionOrderManagement\Pages\ProductionOrderOverView.razor |
+| SwRS-047 | Lückenlose Ticketstatus-Historie im Speicherpfad | SyRS-043, StRS-013, StRS-015 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-048 | Prozessweiter Ticketcache im Nexus (Singleton + HostedService) | SyRS-037, StRS-013 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
+| SwRS-049 | NexusNotifications je Empfänger verwalten (Raw-SQL) | SyRS-038, StRS-013 | src\backend\Centron.BL\NexusNotifications\NexusNotificationsBL.cs |
+| SwRS-050 | NotificationHub filtert pro Benutzer und unterscheidet Schedule-Typen | SyRS-038, StRS-013 | src\nexus\CentronNexus\Shared\Services\NotificationHub.cs |
+| SwRS-051 | Nur lokale Redirect-Ziele bei An-/Abmeldung (Open-Redirect-Schutz) | SyRS-007, StRS-004 | src\nexus\CentronNexus\Shared\Auth\AuthController.cs |
+| SwRS-052 | Ticket-Ansichten mit Besitzer- und Namensregeln | StRS-013, StRS-007 | src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs |
+| SwRS-053 | Ticketauthentifizierungs-Handler als Durchsetzungsstelle | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SwRS-054 | Client-Kontext (IP, API-Methode) in der Access-Token-Validierung | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SwRS-055 | TOTP-Zwei-Faktor-Bibliothek im Plattformkern | StRS-004 | src\shared\Centron.Core\TotpAuth\Totp.cs |
+| SwRS-056 | Schnittstellenmodul als Contract-First-Schicht | StRS-001 | src\backend\Centron.Interfaces (Ordnerstruktur) |
+| SwRS-057 | Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung) | StRS-001 | src\backend\Centron.Common\Network\IpAddressHelper.cs |
+| SwRS-058 | eb:interface-4.3-E-Rechnung für Österreich | SyRS-040, StRS-003 | src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs |
+| SwRS-059 | GLS-Sendungsupload mit Vorabvalidierung | SyRS-047, StRS-001 | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
+| SwRS-060 | Sendungsanlage und Carrier-Abruf über Shipcloud | SyRS-047, StRS-001 | src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs |
+| SwRS-061 | Produktdaten per SOAP-Session vom Cop-System | SyRS-046, StRS-001 | src\apis\Centron.APIs.CopDataAccess\CopApi.cs |
+| SwRS-062 | EGIS-Artikelsuche mit Preis und Verfügbarkeit | SyRS-046, StRS-001 | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
+| SwRS-063 | PSD2-Bankdatenabruf über finapi | StRS-003, StRS-011 | src\apis\Centron.APIs.FinAPI\FinApiClient.cs |
+| SwRS-064 | Icecat-Produktinhalte (Text/Bild/Specs) je EAN | SyRS-046, StRS-001 | src\apis\Centron.APIs.IcecatDataAccess\IcecatApi.cs |
+| SwRS-065 | ITscope-Produkte, Angebote und Deals inkl. Archivierung | SyRS-046, SyRS-045 | src\apis\Centron.APIs.ITscopeDataAccess\ITscopeApi.cs |
+| SwRS-066 | docuFORM-Gerätezähler über OAuth2-PKCE | StRS-001, StRS-003 | Centron.Api.docuFORM\DocuFormRestApiClient.cs |
+| SwRS-067 | Eindeutige Standard-Exportkonfiguration je Mandant | SyRS-039, StRS-003 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
+| SwRS-068 | E-Mail-Versand über austauschbare Protokollclients, Secrets verschlüsselt | StRS-001 | src\backend\Centron.BL\Mail\Factory\CentronMailFactory.cs |
+| SwRS-069 | Mailing als vollständiges Aggregat laden | StRS-001 | src\backend\Centron.BL\Mailings\MailingDataBL.cs |
+| SwRS-070 | MailScanner-Profile nur mit VMA-Recht, Passwörter verschlüsselt | SyRS-001, SyRS-030, StRS-004 | src\backend\Centron.BL\MailScanner\MailScannerBL.cs |
+| SwRS-071 | Chat-Nachrichten: Mitgliederzugriff, Autorschaft, Löschschutz | StRS-001 | src\backend\Centron.BL\Chats\ChatBL.cs |
+| SwRS-072 | Kundensuche im Outlook-AddIn über Gerätenummer | SyRS-035, StRS-001 | src\backend\Centron.BL\Outlook\OutlookAssetKindSearchBL.cs |
+| SwRS-073 | CTI-Anruferidentifikation über mehrstufige Rufnummernsuche | StRS-001 | src\backend\Centron.BL\Tapi\PhoneCallBL.cs |
+| SwRS-074 | Empfängerlisten je Objekt deckungsgleich halten, Meldungen auto-cleanupen | StRS-014 | src\backend\Centron.BL\Notifications\UserNotificationBL.cs |
+| SwRS-075 | Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren | StRS-001 | src\backend\Centron.BL\SocialMedia\SocialMediaBL.cs |
+| SwRS-076 | DocuBoard-Partner als konsistentes Aggregat speichern | StRS-001 | src\backend\Centron.BL\DocuBoard\AssetManagementPartnerBL.cs |
+| SwRS-077 | Videozuweisungen rechtsgeprüft mit ToDo-Kopplung | StRS-014, StRS-004 | src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs |
+| SwRS-078 | Terminanfrage-Antwort gegen Exchange-Kalender verarbeiten | StRS-001 | src\backend\Centron.BL\AppointmentRequests\AppointmentRequestBL.cs |
+| SwRS-079 | Wiederkehrende Aufgaben nur mit valider Aktion und Lizenz | StRS-014 | src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs |
+| SwRS-080 | Kalenderdarstellung und Outlook-Synchronisation konfigurieren | StRS-001 | src\backend\Centron.BL\Calendar\CalendarBL.cs |
+| SwRS-081 | Tagesplanungs-Batches mit gemeinsamer Kennung | StRS-001 | src\backend\Centron.BL\MyDay\MyDayBL.cs |
+| SwRS-082 | Erwartete Ereignisse je Kunde mit Löschkaskade | StRS-015, StRS-001 | src\backend\Centron.BL\ExpectedEvents\ExpectedEventsBL.cs |
+| SwRS-083 | Persönliche Dashboardcontainer je Benutzer | StRS-001 | src\backend\Centron.BL\MyCentron\Dashboard\DashboardContainerBL.cs |
+| SwRS-084 | Hintergrunddienste namentlich erfassen und zentral aktivieren | SyRS-022, StRS-001 | src\backend\Centron.BL\Administration\BackgroundServices\BackgroundServiceBL.cs |
+| SwRS-085 | SQL-Server-Betriebsdiagnostik für Administratoren | StRS-001 | src\backend\Centron.BL\Administration\SQLManagement\SQLManagementBL.cs |
+| SwRS-086 | Automatische, referenzierte Objektverzeichnisse im Dokumentenmanagement | StRS-001, StRS-015 | src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\DirectoryReferenceProviderBase.cs |
+| SwRS-087 | Theme-Verwaltung mit unantastbarem Standard-Theme | StRS-001 | src\backend\Centron.BL\Administration\Themes\ThemeBL.cs |
+| SwRS-088 | Strukturierter Netzwerk-/SQL-Diagnosebericht | StRS-001 | src\backend\Centron.BL\Administration\NetworkDiagnostics\NetworkDiagnosticsBL.cs |
+| SwRS-089 | Profilaufzeichnungen aufbewahrungsgesteuert aggregieren | StRS-001 | src\backend\Centron.BL\Administration\Profiling\ProfilerBL.cs |
+| SwRS-090 | Telefonie-Einstellungen in drei Ebenen | StRS-001 | src\backend\Centron.BL\Administration\PhoneSettings\PhoneSettingsBL.cs |
+| SwRS-091 | Benutzerdefinierte Modul-Eigenschaften ohne Schemaänderung | StRS-001 | src\backend\Centron.BL\Administration\Customization\ModuleCustomPropertyBL.cs |
+| SwRS-092 | Custom-Tabellen mit Platzhalterbefüllung aus dem Fachobjekt | StRS-001 | src\backend\Centron.BL\Customizations\CustomTables\CustomTableBL.cs |
+| SwRS-093 | ChangeLog-Schreibregeln des ChangeTracking-Listeners | SyRS-033, StRS-015 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| SwRS-094 | Wiederverwendbare Massenänderungs-Vorlagen | StRS-001, StRS-015 | src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs |
+| SwRS-095 | Prozessmodelle nur mit gültigen Schritttypen, atomar gespeichert | StRS-001 | src\backend\Centron.BL\Processes\ProcessBL.cs |
+| SwRS-096 | Fehlende ApplicationSettings on-demand mit Default anlegen | SyRS-029, StRS-001 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
+| SwRS-097 | Verbindungsdatei mit Fallbackkette und Trust-Optionen | SyRS-032 | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
+| SwRS-098 | Registry-Präferenzen und Typ-Isolation WebService/DB | StRS-001 | src\backend\Centron.BL\Administration\Environments\RegistryBL.cs |
+| SwRS-099 | Nummernkreis-Fortschreibung mit Intervall und Restzähler | SyRS-044, StRS-016 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
+| SwRS-100 | Versionsmeldung je Maschine/Benutzer mit Portal-Upload | SyRS-049, StRS-001 | src\backend\Centron.BL\Administration\Applications\ApplicationVersionBL.cs |
+| SwRS-101 | Systemzähler als Einzelinstanz-Lieferant | StRS-001 | src\backend\Centron.BL\SystemArea\SystemTableI3DBL.cs |
+| SwRS-102 | PDF-Ausgabestrategie mit PDF/A3-Pflicht-Fallback | StRS-003, StRS-001 | src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs |
+| SwRS-103 | Alt-Reportdefinitionen (Legacy "Reports") verwalten | StRS-001 | src\backend\Centron.BL\Reporting\ReportsBL.cs |
+| SwRS-104 | Statistiken aus vorberechneten Cache-Tabellen mit Eigenstatistiken | SyRS-042, StRS-001 | src\backend\Centron.BL\Statistics\OrderStatistics\CacheOrderStatisticsBL.cs |
+| SwRS-105 | Deutsche Volltextsuche mit Stemming UND-Verknüpfung | StRS-001 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs |
+| SwRS-106 | Telemetrie-Buckets mit Upload-Kennzeichnung | StRS-001 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs |
+| SwRS-107 | Interne Dokumentation nur mit Leseberechtigung | StRS-004 | src\backend\Centron.BL\DocumentationArea\DocumentationBL.cs |
+| SwRS-108 | Spezifischster Textbaustein je Benutzer/Kunde ermitteln | StRS-011, StRS-003 | src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs |
+| SwRS-109 | Tags beim Verschlagworten reaktivieren | StRS-013 | src\backend\Centron.BL\Tags\TagsBL.cs |
+| SwRS-110 | Auditfelder beim Anlegen über Repositories erzwingen | StRS-015 | src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs |
+| SwRS-111 | Feldlängen über typisierte UserTypes abbilden (Trunkierungsschutz) | StRS-001 | src\backend\Centron.DAO\UserTypes\TruncatedStringUserType.cs |
+| SwRS-112 | Zentrale Objekttyp-Nummern als domänenübergreifender Standard | StRS-001 | src\backend\Centron.Entities\Entities\ObjectTypes\ObjectType.cs |
+| SwRS-113 | KI-Chats strikt benutzergetrennt mit persistierter Historie | StRS-001 | src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatBL.cs |
+| SwRS-114 | Checklisten an Objekte mit Pflicht-Caption, atomar gespeichert | StRS-013 | src\backend\Centron.BL\CheckListArea\CentronChecklistBL.cs |
+| SwRS-115 | Anbindung an c-pra (Nexoware Smartflow) | SyRS-046 | src\backend\Centron.BL\CPra\CPraConnectorBL.cs |
+| SwRS-116 | Externe-Helpdesk-Konfiguration je Kunde/Kundenort | StRS-013 | src\backend\Centron.BL\ExternalHelpdesk\ExternalHelpdeskConfigurationBL.cs |
+| SwRS-117 | Externe Tools mit Namenspflicht und Variablenersetzung | StRS-001 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs |
+| SwRS-118 | Helpdesk-Typen/Kategorien automatisch als virtuelle Checklistenkategorien | StRS-013 | src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs |
+| SwRS-119 | Projektliste mit Erstellungsdatumfilter (rumpfhaft) | StRS-001 | src\backend\Centron.BL\Projects\ProjectBL.cs |
+| SwRS-120 | Ticketprojekte mit eigener Nummer und Soft-Delete-Aufgaben | StRS-016, StRS-013 | src\backend\Centron.BL\TicketProjects\TicketProjectBL.cs |
+| SwRS-121 | Zeiterfassungs-Stammeinstellungen pflegen | StRS-001 | src\backend\Centron.BL\Time\TimingSettingsBL.cs |
+| SwRS-122 | Benutzerbezogene Transaktionen mit Kategorie-Details | StRS-001 | src\backend\Centron.BL\Transactions\TransactionBL.cs |
+| SwRS-123 | Aktive Gutschein-Barcodes per NamedQuery | StRS-003 | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs |
+| SwRS-124 | URLs als sichtbare, durchsuchbare Objekt-Links | StRS-001 | src\backend\Centron.BL\Urls\SimpleUrlBL.cs |
+| SwRS-125 | Objekt↔Fremdsystem-Referenzen typisiert verwalten | StRS-001 | src\backend\Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs |
+| SwRS-126 | Modulstamm automatisch ergänzen, Favoriten je Mitarbeiter | StRS-001 | src\backend\Centron.BL\Modules\ModuleBL.cs |
+| SwRS-127 | Ticketabschluss nur mit Recht und erledigter Abschluss-Checkliste | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-128 | Single-Instance-Start der Desktop-Anwendung | StRS-001 | src\centron\Centron.WPF.UI\App.xaml.cs |
+| SwRS-129 | Anmeldung als Pflicht-Gate vor der Arbeitsfläche | SyRS-002, StRS-004 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| SwRS-130 | Modul-Layout je Benutzerprofil speichern/zurücksetzen | StRS-001 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| SwRS-131 | Konfigurierbare Pflichtfelder in der Belegmaske | StRS-011, StRS-003 | src\centron\Centron.WPF.UI\Modules\Finances\Receipts\ReceiptViewModel.cs |
+| SwRS-132 | Inline-Feldvalidierung E-Mail/IBAN in der Adressmaske | StRS-005 | src\centron\Centron.WPF.UI\Modules\Finances\Crm\Info\CrmInfoTabView.xaml.cs |
+| SwRS-133 | Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen | SyRS-039, StRS-001 | src\backend\Centron.BL\Gateway\CustomGatewayBL.cs |
+| SwRS-134 | Externe ElectronicSales-Gruppen/Rollen lokal spiegeln | StRS-001 | src\backend\Centron.BL\Integrations\EsCustomerGroupBL.cs |
+
+## Hinweise zur Matrix
+
+1. Die Verfolgung ist vollständig in Richtung Kind→Elter: jede Anforderung listet ihre Eltern in Tracelinks. In Richtung Elter→Kind werden die wesentlichen direkten Kinder genannt; SwRS, die nur eine StRS als groben Rahmen referenzieren, werden dort nicht repetitiv aufgelistet (Deduplizierung über die Kind→Elter-Spalten).
+2. SyRS-010↔SyRS-044 und SyRS-039↔SyRS-011 sind Geschwisterlinks (Querverweise, keine Eltern-Kind-Beziehungen).
+3. StRS-012 besitzt keine abgeleitete Anforderung; die Durchsetzung ist vollständig im PRIMÄR-Beleg (UpdateHelpdeskBL) dokumentiert.
@@ -0,0 +1,129 @@
+# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/builtin/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-02T13:11:02.2153173+02:00
+- **Endzeit:** 2026-09-02T14:03:38.1060735+02:00
+- **Dauer gesamt:** 00:52:32 (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/builtin/high/`
+- **Agentenmodus:** `builtin`
+- **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` = 13, `completed` = 13, `failed` = 0
+- **Rollen:** {"explore": 13}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 501.335 |
+| Output-Tokens | 194.782 |
+| Reasoning-Tokens | 68.781 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 71 |
+
+**Tokens gesamt: 7.830.882.** 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 | 8,0 % |
+| SyRS | 49 | 24,6 % |
+| SwRS | 134 | 67,3 % |
+| **Gesamt** | **199** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 95 | 47,7 % |
+| Sicherheit | 32 | 16,1 % |
+| nicht-funktional | 28 | 14,1 % |
+| Schnittstelle | 26 | 13,1 % |
+| Daten | 17 | 8,5 % |
+| Datenschutz | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 323 |
+| davon `PRIMÄR` | 256 (79,3 %) |
+| davon `SEKUNDÄR` | 66 (20,4 %) |
+| davon `KONTEXT` | 1 (0,3 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 171 | 85,9 % |
+| workaround | 9 | 4,5 % |
+| sonderfall | 12 | 6,0 % |
+| veraltet | 4 | 2,0 % |
+| (sonstige Angabe) | 3 | 1,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 176 | 88,4 % |
+| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 170 | 85,4 % |
+| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9e2f37dbffePXP0P4ACRLx8cN`
+- **Werkzeugaufrufe:** 116 – {"bash": 50, "task": 13, "grep": 2, "write": 10, "read": 6, "edit": 35}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 13
+- **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)*
@@ -0,0 +1,5 @@
+[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
+[2026-09-02T11:11:03.862020+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=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
+[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
@@ -0,0 +1 @@
+
@@ -0,0 +1,67 @@
+## 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 | 8,0 % |
+| SyRS | 49 | 24,6 % |
+| SwRS | 134 | 67,3 % |
+| **Gesamt** | **199** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 95 | 47,7 % |
+| Sicherheit | 32 | 16,1 % |
+| nicht-funktional | 28 | 14,1 % |
+| Schnittstelle | 26 | 13,1 % |
+| Daten | 17 | 8,5 % |
+| Datenschutz | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 323 |
+| davon `PRIMÄR` | 256 (79,3 %) |
+| davon `SEKUNDÄR` | 66 (20,4 %) |
+| davon `KONTEXT` | 1 (0,3 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 171 | 85,9 % |
+| workaround | 9 | 4,5 % |
+| sonderfall | 12 | 6,0 % |
+| veraltet | 4 | 2,0 % |
+| (sonstige Angabe) | 3 | 1,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 176 | 88,4 % |
+| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 170 | 85,4 % |
+| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,175 @@
+# 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, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
+die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, 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\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-09-02T14:03:38.1060735+02:00
@@ -0,0 +1,234 @@
+{
+  "$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/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "external_directory": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_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",
+      "general": "allow",
+      "explore": "allow"
+    },
+    "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"
+}
@@ -0,0 +1 @@
+2026-09-02T13:11:02.2153173+02:00
@@ -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
@@ -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.*
@@ -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 |
@@ -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. |
@@ -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
+
+---
@@ -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)
+
+---
@@ -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
+
+---
@@ -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 |
@@ -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)*
@@ -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
@@ -0,0 +1 @@
+
@@ -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 %) |
+
@@ -0,0 +1 @@
+
@@ -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).
@@ -0,0 +1 @@
+2026-09-02T13:11:01.6994339+02:00
@@ -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"
+}
@@ -0,0 +1 @@
+2026-09-02T12:51:54.8940173+02:00