Effortvergleich high gegen max: Effort wirkt ueber Delegation

Dieselbe TensorX-Matrix ein zweites Mal bei hoechstem Effort. Zwoelf gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens, hochgerechnet $10,53 aus der Preisliste vom 02.09.2026. Befund: In den nicht-delegierenden Zellen bewegt sich der Ertrag zwischen minus 18 und plus 44 Prozent ohne erkennbare Richtung - in der Groessenordnung der Streuung. Der eine deutliche Ausschlag ist GLM in custom mit plus 122 Prozent, erreicht mit 78 statt 30 Subagenten. Der hoehere Denkaufwand schlaegt sich in mehr Zerlegung nieder, und die traegt den Ertrag, nicht der Denkaufwand als solcher. Qwens custom-Zelle hat sich qualitativ erholt: bei high 61 Prozent ohne Beleg und 40 Prozent Hypothesen, bei max 3 Prozent ohne Beleg und 96 Prozent Primaerbeleg. Der Einbruch war ein Laufmerkmal, kein Modellmerkmal - ein weiterer Beleg, dass n gleich 1 je Zelle nicht traegt. Skill 13.2.0: analyse-anforderungen.py toleriert jetzt vier Markdown-Fassungen der Feldvorgabe. Jedes der vier eingesetzten Modelle formatierte sie anders, und jede Fassung wurde zunaechst mit null Anforderungen gezaehlt, obwohl Belege und Pruefideen vollstaendig vorlagen. Das ist ein Befund ueber den Versuchsaufbau: Die Formatvorgabe ist fuer Menschen eindeutig, fuer maschinelle Auswertung nicht. Regressionsprobe an sieben Laeufen unveraendert. _matrix.ps1 nimmt zusaetzlich -Effort und -Modi fuer einzelne Zellen. Ein Lauf fiel durch Standby des Rechners aus und wurde wiederholt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-04 13:41:01 +02:00
parent e2c3a0e8f8
commit 08d90f1ccb
159 changed files with 129328 additions and 10 deletions
@@ -10,7 +10,7 @@
 - **Endzeit:** 2026-09-02T10:42:42.1186240+02:00
 - **Dauer gesamt:** 00:45:50 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
 - **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
 - **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja

 ## Werkzeugkonfiguration
@@ -0,0 +1,5 @@
+[2026-09-03T07:29:56.953120+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\Ergebnisse)
+[2026-09-03T07:29:57.100595+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=builtin; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T08:35:25.773856+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T08:35:27.146729+00:00] OpenCode export: Exporting session: ses_f99d33280ffeMmaSnV8T9WM2tT
+[2026-09-03T08:35:27.176641+00:00] Ende: Exitcode=0; Status=success; Turns=24; Tokens=2385024; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\RawResult.json
@@ -0,0 +1,153 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Legacy C#/WPF-Client "c-entron.NET", REST-Webservice, Blazor-Webklient "c-entron Nexus", MSSQL-Datenhaltung).
+Untersuchungsgegenstand: gesamte Codebasis (Schritt 1 Scope, keine Modulbeschränkung). Analyseart: statisch, rein lesend (Schritte 2-6 der RRE-Methodenkette; Schritt 7 Validierung durch Fachexperten).
+
+## 1. Modulinventar (Schritt 0) und Abdeckungstabelle
+
+Das Inventar wurde **vor** der ersten Anforderung erstellt und während der Analyse nur ergänzt, nicht gekürzt. Granularität: Projektebene der Solution `Centron.sln` plus die 29 fachlichen Module des WPF-Clients (`src\centron\Centron.WPF.UI\Modules\*`). Die Tabelle vereint Inventar und Abdeckungstabelle (Schritt 0b/0c): jedes Modul mit Einstufung `tief | mittel | flach | nicht analysiert` und Anzahl der daraus gespeisten Anforderungen.
+
+| # | Modul / Komponente | Pfad | Fachliche Aufgabe (ein Satz) | Abdeckung | Anforderungen (IDs) |
+|---|---|---|---|---|---|
+| 1 | Administration (WPF) | src\centron\Centron.WPF.UI\Modules\Administration | Benutzerverwaltung, Rechtevergabe, Mandanten-/Filialpflege, globale Einstellungen, Login-Dienste, DSGVO-Verwaltung. | tief | 6 (SyRS-5, SyRS-44, SwRS-1, SwRS-2, SwRS-46, SwRS-53) |
+| 2 | ArtificialIntelligence (WPF) | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Assistent (Chat, Ticket-/Textentwürfe) mit Provider- und Promptverwaltung. | mittel | 2 (SyRS-43, SwRS-44) |
+| 3 | Calendar (WPF) | src\centron\Centron.WPF.UI\Modules\Calendar | Kalendereinstellungen, Outlook-/Exchange-Synchronisation, Termine aus Tickets. | mittel | 2 (SyRS-45, SwRS-47) |
+| 4 | Dashboard (WPF) | src\centron\Centron.WPF.UI\Modules\Dashboard | Modul-/Kachelübersicht und Containerkatalog für benutzerbezogene Dashboards. | flach | 2 (SyRS-51, SwRS-42) |
+| 5 | DataExchange (WPF) | src\centron\Centron.WPF.UI\Modules\DataExchange | Datenaustausch-Zentrale: Buchhaltung, EDI, Importe, Zahlungsverkehr, RMM, Telekom-Dive. | tief | 7 (SyRS-31, SyRS-32, SyRS-33, SyRS-34, SwRS-33, SwRS-34, SwRS-35) |
+| 6 | ExternalTool (WPF) | src\centron\Centron.WPF.UI\Modules\ExternalTool | Konfiguration/Vorschau externer Programmaufrufe mit Platzhaltervariablen. | flach | 1 (SwRS-55) |
+| 7 | Finances (WPF) | src\centron\Centron.WPF.UI\Modules\Finances | Finanzwesen: Belegkette, Preis-/Konditionslogik, Mahnwesen, Zahlungen, Verträge, CRM, TimerBilling. | tief | 22 (SyRS-10…18, SyRS-29, SyRS-30, SyRS-32; SwRS-9…18, SwRS-25, SwRS-51) |
+| 8 | Global (WPF) | src\centron\Centron.WPF.UI\Modules\Global | Übergreifende Hilfsfunktionen (PDF, Netzdiagnose, Mitarbeiterauswahl, MSP-Vergleich, About). | flach | 1 (SwRS-55) |
+| 9 | Gui (WPF) | src\centron\Centron.WPF.UI\Modules\Gui | Verwaltung benutzerdefinierter UI-Profile. | flach | 1 (SwRS-55) |
+| 10 | Helpdesk (WPF) | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticketverwaltung inkl. Zeiterfassung, C-FLOW, Checklisten, TaskManagement, Eskalationseinstellungen. | tief | 9 (SyRS-25, SyRS-27; SwRS-22…29) |
+| 11 | Logistic (WPF) | src\centron\Centron.WPF.UI\Modules\Logistic | Versand-/Logistikeinstellungen (Versandarten, Zonen). | flach | 2 (SyRS-35, SwRS-37) |
+| 12 | Massenupdates (WPF) | src\centron\Centron.WPF.UI\Modules\Massenupdates | Assistentengestützte Massenpreis-/Datenänderungen mit Vorschau und Vorlagen. | mittel | 2 (SyRS-40, SwRS-43) |
+| 13 | MyCentron (WPF) | src\centron\Centron.WPF.UI\Modules\MyCentron | Persönlicher Arbeitsbereich: MyDay, ToDos, Dashboard, QuickNotes, Einstellungen, Inspektoren. | mittel | 3 (SyRS-28, SwRS-27, SwRS-42) |
+| 14 | OnlineBanking (WPF) | src\centron\Centron.WPF.UI\Modules\OnlineBanking | Bankanbindung (FinTS/FinAPI/Import) und Zuordnung/Verbuchung von Kontoumsätzen. | tief | 2 (SyRS-16, SwRS-16) |
+| 15 | PasswordManager (WPF) | src\centron\Centron.WPF.UI\Modules\PasswordManager | Verschlüsselter Zugangsdaten-Vault mit Richtlinien, Audit und RDP/SSH-Modulen. | tief | 3 (SyRS-8, SwRS-6, SwRS-7) |
+| 16 | PayersAndCostCenter (WPF) | src\centron\Centron.WPF.UI\Modules\PayersAndCostCenter | Verwaltung von Kostenstellen/Kostenträgern. | flach | 2 (SyRS-53, SwRS-49) |
+| 17 | PLM (WPF) | src\centron\Centron.WPF.UI\Modules\PLM | Produktlebenszyklusverfolgung nach Verkauf (Start/Ende, Lizenzen, Wiederverkaufsmails). | mittel | 2 (SyRS-49, SwRS-31) |
+| 18 | Production (WPF) | src\centron\Centron.WPF.UI\Modules\Production | Produktionsauftragsverfolgung inkl. Maschinenverwaltung. | mittel | 2 (SyRS-46, SwRS-30) |
+| 19 | ProjectManagement (WPF) | src\centron\Centron.WPF.UI\Modules\ProjectManagement | Gemeinsame Übersicht über CRM-Projekte, Tickets, Auslastung und Terminplanung. | flach | 2 (SyRS-45, SwRS-47) |
+| 20 | ProjectPriceImport (WPF) | src\centron\Centron.WPF.UI\Modules\ProjectPriceImport | Excel-Import kunden-/projektspezifischer Preise mit Differenzprüfung. | flach | 2 (SyRS-33, SwRS-51) |
+| 21 | Purchasing (WPF) | src\centron\Centron.WPF.UI\Modules\Purchasing | Einkauf: Bestellvorschläge, Lieferantenbestellungen, EDI-Verwaltung. | tief | 4 (SyRS-22, SyRS-31, SyRS-33, SwRS-34) |
+| 22 | QM (WPF) | src\centron\Centron.WPF.UI\Modules\QM | QM-Grundfunktionen: Beleggründe, Benachrichtigungsmodi. | flach | 1 (SwRS-52, [HYPOTHESE] bzgl. Legacy-Prüfwesen) |
+| 23 | Reports (WPF) | src\centron\Centron.WPF.UI\Modules\Reports | Verwaltung DB-getriebener Berichtsdefinitionen und Abfragen. | mittel | 2 (SyRS-11, SwRS-57) |
+| 24 | Rma (WPF) | src\centron\Centron.WPF.UI\Modules\Rma | Retourenabwicklung mit Positionsstatus und Retourbelegen. | mittel | 2 (SyRS-24, SwRS-21) |
+| 25 | Sales (WPF) | src\centron\Centron.WPF.UI\Modules\Sales | Mailings, Produktmatrix, Sonderartikel-/Vertragsartikelimport. | flach | 2 (SyRS-48, SwRS-51) |
+| 26 | Statistics (WPF) | src\centron\Centron.WPF.UI\Modules\Statistics | Statistik-Dashboards: Umsatz, Tickets, Mitarbeiter, ManagementInfo, MSP. | mittel | 2 (SyRS-51, SwRS-42) |
+| 27 | Survey (WPF) | src\centron\Centron.WPF.UI\Modules\Survey | Umfragen mit Fragekategorien, Versand und Auswertung. | flach | 1 (SyRS-48) |
+| 28 | TelekomDive (WPF) | src\centron\Centron.WPF.UI\Modules\TelekomDive | Telekom-Distributor-Angebote (Dive-Profile, Export). | flach | 2 (SyRS-34, SwRS-50) |
+| 29 | Warehousing (WPF) | src\centron\Centron.WPF.UI\Modules\Warehousing | Artikel-/Lagerverwaltung: Bestände, Barcode/Seriennummern, Inventur, Kommissionierung. | tief | 5 (SyRS-20, SyRS-21, SyRS-23, SwRS-19, SwRS-20) |
+| 30 | Centron.BL | src\backend\Centron.BL | Geschäftslogikschicht mit allen Fachregeln (Belege, Rechte, Helpdesk, Finanzen, Statistik, Skripte). | tief | 13 (SyRS-1; SwRS-2, SwRS-9…14, SwRS-22, SwRS-23, SwRS-26, SwRS-27, SwRS-33, SwRS-44) |
+| 31 | Centron.Common | src\backend\Centron.Common | Geteilte Utilities: Krypto (AES/SHA), Kompression, INI, Logging. | flach | 2 (SwRS-3, SwRS-5) |
+| 32 | Centron.DAO | src\backend\Centron.DAO | NHibernate-Datenzugriff: Mappings, Repositories, NamedQueries. | mittel | 2 (SyRS-1, SwRS-8) |
+| 33 | Centron.Entities | src\backend\Centron.Entities | Entitätsmodell über allen Fachdomänen (inkl. ReceiptTable-Vererbung). | mittel | 2 (SyRS-10, SwRS-8) |
+| 34 | Centron.Gateway | src\backend\Centron.Gateway | Gateway zu Fremdsystemen: Buchhaltungsexporte, Lieferanten-EDI, SEPA, OnlineBanking, Portal-Proxy. | tief | 4 (SyRS-19; SwRS-15, SwRS-17, SwRS-35) |
+| 35 | Centron.Interfaces | src\backend\Centron.Interfaces | DTO-/Enum-Vertragsschicht zwischen REST und BL. | mittel | 4 (SyRS-1; SwRS-12, SwRS-20, SwRS-21) |
+| 36 | Centron.Api.EbInterface | src\apis\Centron.Api.EbInterface | Erzeugung österreichischer E-Rechnungen (ebInterface 4.3-XML). | flach | 1 (SyRS-52, [HYPOTHESE]) |
+| 37 | Centron.Api.Gls | src\apis\Centron.Api.Gls | GLS-Paketdienst-Client (Sendungsübergabe, Label). | flach | 2 (SyRS-35, SwRS-37) |
+| 38 | Centron.Api.Shipcloud | src\apis\Centron.Api.Shipcloud | shipcloud-Versandclient (Label, Tracking, Preis). | flach | 2 (SyRS-35, SwRS-37) |
+| 39 | Centron.APIs.CopDataAccess | src\apis\Centron.APIs.CopDataAccess | SOAP-Artikelkatalog (Produkt-/Lieferantendaten) für Belegsuche. | flach | 2 (SyRS-34, SwRS-36) |
+| 40 | Centron.APIs.EgisDataAccess | src\apis\Centron.APIs.EgisDataAccess | Egis-EBC-Marktplatz (Artikel, Preise/Verfügbarkeit, Bestellabwicklung). | flach | 2 (SyRS-34, SwRS-36) |
+| 41 | Centron.APIs.FinAPI | src\apis\Centron.APIs.FinAPI | FinAPI-Bankdienst (Konten, Umsätze, SEPA). | mittel | 2 (SyRS-16, SwRS-16) |
+| 42 | Centron.APIs.IcecatDataAccess | src\apis\Centron.APIs.IcecatDataAccess | Icecat-Produktbilder/-texte per REST/Basic Auth. | flach | 2 (SyRS-34, SwRS-36) |
+| 43 | Centron.APIs.ITscopeDataAccess | src\apis\Centron.APIs.ITscopeDataAccess | ITscope-REST-Katalog inkl. Lieferantenpreise. | flach | 2 (SyRS-34, SwRS-36) |
+| 44 | CentronNexus | src\nexus\CentronNexus | Neuer Blazor-Webklient: ServiceBoard (Tickets/MyDay), WebShop/Portal, Verwaltung, Dokumentensignatur. | tief | 8 (SyRS-7, SyRS-36, SyRS-38; SwRS-38, SwRS-40, SwRS-41, SwRS-44, SwRS-58) |
+| 45 | CentronNexus.Host | src\nexus\CentronNexus.Host | Host des Webklienten (Blazor Server, OpenIdConnect, SignalR, Windows-Dienst). | mittel | 2 (SyRS-1, SwRS-41) |
+| 46 | CentronNexus.OutlookAddIn | src\nexus\CentronNexus.OutlookAddIn | Office-JS-Add-in: Kundensuche, Mail-/Dokumentarchivierung, Ticketanlage aus Outlook. | flach | 1 (SwRS-58) |
+| 47 | Centron.Controls | src\shared\Centron.Controls | Geteilte WPF-Steuerelemente (PaintSurface, Datei-Explorer, RDP/SSH-Dialoge, Behaviors). | mittel | 3 (SwRS-6, SwRS-24, SwRS-40) |
+| 48 | Centron.Controls.Preview | src\shared\Centron.Controls.Preview | Vorschau-/Testanwendung für Dialog- und Connector-Komponenten. | flach | 1 (SwRS-56) |
+| 49 | Centron.Core | src\shared\Centron.Core | Framework-Bibliothek (MVVM, GoogleAuthenticator/TOTP, PdfScanning, Utils). | flach | 2 (SyRS-3, SwRS-56) |
+| 50 | c-entron.misc.ConnectionManager | src\webservice\c-entron.misc.ConnectionManager | Support-Werkzeug: Verbindungs-/2FA-Tests, SQLServerCheckTool. | flach | 1 (SwRS-56) |
+| 51 | Centron.Controllers | src\webservice\Centron.Controllers | ASP.NET-Core-REST-Controller (41 Stück, u. a. JwtAuth, Helpdesks, ZugferdImport). | mittel | 3 (SyRS-1, SyRS-2, SyRS-3) |
+| 52 | Centron.Host | src\webservice\Centron.Host | Webservice-Host: REST/WCF-Brücke, 37 Hintergrunddienste, SignalR, Interceptors. | tief | 3 (SyRS-1, SyRS-27, SyRS-39) |
+| 53 | Centron.Host.Console | src\webservice\Centron.Host.Console | Konsolenvariante des Webservice-Hosts (Debug/Fehlersuche). | flach | 1 (SyRS-1) |
+| 54 | Centron.Host.WindowsService | src\webservice\Centron.Host.WindowsService | Windows-Diensthülle für den Webservice-Host. | flach | 1 (SyRS-1) |
+| 55 | Centron.WebServices.Core | src\webservice\Centron.WebServices.Core | REST-Vertragsobjekte (Requests/Entities), darunter UserRightsConst und Auth-DTOs. | mittel | 2 (SwRS-1, SwRS-3) |
+
+**Inventarsumme:** 55 Module. **Abdeckung:** tief 12, mittel 17, flach 26, nicht analysiert 0. Die Mindestabdeckung (Schritt 0b: jedes Modul ≥ 1 Anforderung) ist **erfüllt** - kein Modul ohne Anforderung, kein Modul als "nicht analysiert" geführt. Eine Vertiefung (Schritt 0c) erfolgte priorisiert bei Berechtigungen/Geheimnissen (SwRS-1…7), Abrechnung/Fakturierung (SyRS-10…19, SwRS-9…18) und Beleg-/Serienlogik (SyRS-20…25, SwRS-19…21).
+
+## 2. Kennzahlen des Anforderungssets
+
+| Kennzahl | Wert |
+|---|---|
+| StRS-Anforderungen | 16 |
+| SyRS-Anforderungen | 53 |
+| SwRS-Anforderungen | 58 |
+| **Gesamt** | **127** |
+| Status `belegt` | 124 (97,6 %) |
+| Status `[HYPOTHESE]` | 3 (SyRS-52, SwRS-7, SwRS-52) |
+| Anforderungen mit PRIMÄR-Beleg | 113 |
+| Anforderungen mit SEKUNDÄR-/KONTEXT-Zusatzbeleg | 71 |
+| Konsolidierungskandidaten markiert | 22 |
+
+## 3. Konsistenzcheck (über alle 127 Anforderungen)
+
+- **Doppelte/mehrfach vergebene IDs:** keine. StRS-1…16, SyRS-1…53, SwRS-1…58 sind je Ebene eindeutig und lückenlos vergeben.
+- **Anforderungen ohne Beleg:** keine. Jeder Block führt mindestens einen Beleg; risikorelevante Anforderungen führen einen PRIMÄR-Beleg auf die durchsetzende Stelle (Datei, Klasse, Methode, Bedingung).
+- **Anforderungen ohne `Übernahmewürdigkeit`:** keine (127/127 gesetzt mit Begründung).
+- **Tracelinks auf nicht existierende IDs:** keine. Stichprobe über alle StRS- und SwRS-Blöcke bestätigt, dass referenzierte IDs existieren (SyRS-53 ist gültiges Ziel, ebenso SyRS-52/SwRS-52 für Hypothesenblöcke).
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungskennzeichnung:** keine bekannt. 22 Anforderungen tragen explizite Konsolidierungskandidaten, u. a. der im Prompt genannte Fall "Stammblätter/Drucker vs. Assets" (SyRS-23/SwRS-20 → Barcode-/Seriennummern- und Gerätesichten), die Doppelhaltung Kunden/Anschriften (SwRS-8, SwRS-49), vier Abrechnungszugänge auf Verträge (StRS-10, SyRS-30), zwei Fertigungsmodelle (SyRS-46/SwRS-30), zwei Dokumentgeneratoren (SyRS-11/SwRS-57), zwei E-Rechnungsformate (SyRS-32/SyRS-52), zwei Geheimnisspeicher (SyRS-8/SwRS-7). Ebenen-Sichten derselben Funktion (StRS↔SyRS↔SwRS) sind bewusst **nicht** als Konsolidierung markiert, sondern über Tracelinks verbunden.
+- **Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:**
+
+| ID | Titel (kurz) | PRIMÄR-Beleg | Status |
+|---|---|---|---|
+| SyRS-2 | Authentisierung Varianten | ja (AuthenticatorFactory, BasicAuthenticator) | belegt |
+| SyRS-3 | Zweifaktor-Authentisierung | ja (TwoFactorAuthBL im Auth-Fluss) | belegt |
+| SyRS-4 | Sitzungslebensdauer | ja (TicketBL, Heartbeat) | belegt |
+| SyRS-5 | Rechtebasierte Zugriffskontrolle | ja (AppRightsBL:644, HelpdeskBL:233) | belegt |
+| SyRS-6 | Mandanten-/Filialtrennung | ja (BranchBL MandantI3D-Filter) | belegt |
+| SyRS-7 | Web-Konten mit Freigabe | ja (AddressContactWebServiceBL:458) | belegt |
+| SyRS-8 | Schutz gespeicherter Geheimnisse | ja (BasicAuthenticator, AESCryptoLogic, PasswordManagementKeywordBL) | belegt |
+| SyRS-10 | Belegstatus + Storno | ja (ReceiptInvoiceBL:143-206) | belegt |
+| SyRS-12 | Preisfindungspipeline | ja (ReceiptItemPriceBL) | belegt |
+| SyRS-13 | Fälligkeitsberechnung | ja (AssetConditionBL:350) | belegt |
+| SyRS-14 | Mahnwesen | ja (DunningRunBL, cvw_InvoiceDunnings) | belegt |
+| SyRS-15 | Zahlungseingangsverbuchung | ja (ReceiptBL:4902) | belegt |
+| SyRS-16 | Online-Banking-Zuordnung | ja (3-Stufen-Heuristik) | belegt |
+| SyRS-17 | SEPA-Lastschrift | ja (SepaFileGeneratorV2, ValidateExportData) | belegt |
+| SyRS-18 | Kassenbuch-Integrität | ja (CashBookBL Abschlussschutz) | belegt |
+| SyRS-19 | Buchhaltungsübergabe | ja (DatevAscii, InvokeExportClass) | belegt |
+| SyRS-20 | Beleggebundene Bestandsverbuchung | ja (ReceiptArticleBookingBL) | belegt |
+| SyRS-25 | Ticket-Lebenszyklus mit Rechten | ja (HelpdeskBL:418-466) | belegt |
+| SyRS-29 | Vertragslaufzeit/Auto-Abschluss | ja (ContractBL:1067, 1247-1308) | belegt |
+| SyRS-30 | Kontingent-/Zählerabrechnung | ja (ReceiptContractHelperBL, AutomaticFacturaBL) | belegt |
+| SyRS-42 | DSGVO-Bereinigung | ja (CentronDataSecurityViewModel) | belegt |
+| SyRS-52 | EbInterface-Einbindung | nur Formatgenerator | **[HYPOTHESE]** |
+| SwRS-1 | Rechtekonstanten-Inventar | ja (UserRightsConst) | belegt |
+| SwRS-2 | Rechteprüfungskern | ja (AppRightsBL SQL) | belegt |
+| SwRS-3 | Auth-Komponenten/SHA1 | ja (BasicAuthenticator:46-50 + TODO-Kommentar) | belegt |
+| SwRS-5 | AES-Bibliothek/Fallback-Secret | ja (AESCryptoLogic:77) | belegt |
+| SwRS-6 | PasswordManager-Vault | ja (AES-Speicherung, Richtlinien, Logs) | belegt |
+| SwRS-7 | Legacy-Passwortspeicher | ja (Dekryptierung tut nichts), Nutzung unbelegt | **[HYPOTHESE]** |
+| SwRS-9 | Preisauflösungsreihenfolge | ja (GetBasePrice) | belegt |
+| SwRS-12 | Rechnungsstorno | ja (CancelInvoice) | belegt |
+| SwRS-13 | Mahnlauf-Durchführung | ja (DunningRunBL) | belegt |
+| SwRS-14 | Kassenbuch-Komponente | ja (Abschlussschutz) | belegt |
+| SwRS-15 | DATEV-Formate | ja (Feldkomposition, Nummernvalidierung) | belegt |
+| SwRS-16 | Banking-Zuordnung | ja (Heuristik + Verbuchung) | belegt |
+| SwRS-17 | SEPA-Generator | ja (pain.008-Erzeugung/-Validierung) | belegt |
+| SwRS-18 | Zahlungsbuchung | ja (UpdateReceiptIsPaid-Kette) | belegt |
+| SwRS-22 | Ticket-Regelkomponente | ja (CheckUserRigths, Sichtfilter) | belegt |
+| SwRS-25 | Zeitfakturierung | ja (ReceiptItemTimerBL, TimerBillingBL) | belegt |
+| SwRS-39 | Web-Konto-Freigabeprozess | ja (Zustands-/Prüfkette) | belegt |
+| SwRS-46 | DSGVO-Bereinigungskomponente | ja (Filter/Aktionen/Rechteflags) | belegt |
+| SwRS-52 | Wartung/QM-Nachfolge | ja für Nachfolgefunktionen, Legacy-Nutzung unbelegt | **[HYPOTHESE]** |
+
+Ergebnis: **39 von 42 risikorelevanten Anforderungen tragen einen PRIMÄR-Beleg auf die durchsetzende Stelle; 3 sind als [HYPOTHESE] markiert.** Ein Verstoß gegen die risikobasierte Priorisierung liegt nicht vor.
+
+- **Abgleich `Hypothesen.md` gegen Inline-Markierungen:** deckungsgleich. Genau 3 Anforderungen tragen `[HYPOTHESE]` (SyRS-52, SwRS-7, SwRS-52); `Hypothesen.md` nennt genau diese drei und keine zusätzlichen freien Fragen.
+
+## 4. Selbstbewertung
+
+- **Module tief/mittel/flach/nicht analysiert (absolute Zahlen):** 12 tief, 17 mittel, 26 flach, 0 nicht analysiert (von 55). Die flach erfassten Module sind durchweg Kleinstmodule (1-68 Dateien) oder Infrastruktur-/Werkzeugprojekte; ihre Anforderungen sind dennoch belegt.
+- **Mindestabdeckung erreicht?** Ja - jedes der 55 Inventarmodule hat mindestens eine Anforderung; die Abdeckungstabelle enthält jede Inventarzeile. Fehlende Module: keine.
+- **Dünne Belegstellen (hoher SEKUNDÄR/KONTEXT-Anteil oder HYPOTHESE):** (1) Legacy-DB-Only-Bereiche - `Wartung*`/`Prufvorschrift*`/`Prufmittel`/`Arbeitsplan*`/`CMan*`/Delphi-Webshop-Tabellen existieren nur im Schema (`SSMS_DB_SCHEMA.sql`), ohne C#-Bindung im Spiegel; daraus wurde bewusst nur SwRS-52 mit [HYPOTHESE] abgeleitet. (2) `PORTDEBI`/`Roles`/`sysuserobjects`/`KassenBuchChangeLog`/`PermanentLoginToken` sind tabellarisch belegt, aber ohne Code-Nutzung - bewusst **keine** Anforderungen daraus gebildet. (3) UI-getriebene Abläufe (WPF-Assistenten) wurden bewusst über die BL-Komponenten belegt statt über ViewModels.
+- **Hypothesengehaltung:** 3 [HYPOTHESE]-Anforderungen; Begründungen und fehlende Informationen stehen in `Hypothesen.md`. Eine Analyse ohne Hypothesen wäre angesichts des geteilten Datenbestands (Legacy-Client außerhalb des Spiegels) nicht glaubwürdig gewesen.
+- **Erkenntnisse für eine Folge-Iteration (Nachschlag lohnt sich):**
+  1. **Externes System "RiverSuite/Riverbird"**: Die RMM-Ausführung liegt außerhalb des Spiegels; eine Iteration mit Zugriff auf die Riverbird-/Crawler-Dokumentation könnte SyRS-50 präzisieren (Checkarten, Alarmierungskette, `PermanentLoginToken`-Nutzung).
+  2. **Vorgänger-Client (c-entron.NET/Delphi)**: Legacy-Tabellen (Wartung, Prüfwesen, Arbeitsplan, CMan, PORTDEBI, WebShop) sind nur dann verlässlich als `veraltet` einzustufen, wenn der Altklient geprüft wird - stärkster Einfluss auf die Übernahmewürdigkeit.
+  3. **Beleg-/Zahlungsketten Ende-zu-Ende**: Die Einzelregeln sind dicht belegt (Preisfindung, Storno, Mahnung, Banking-Matching); ein Folge-Lauf könnte die Interaktionsreihenfolge als Prozessmodelle (Ablaufdiagramme) formalisieren.
+  4. **Konsolidierungsblaupause**: Die 22 markierten Kandidaten (Doppelhaltung Kunden/Bestellungen/Zeiten, vier Abrechnungszugänge, zwei Fertigungsmodelle, zwei Dokument-/E-Rechnungsgeneratoren, drei Gerätesichten) sind als Migrationsentscheidungsvorlage aufzubereiten.
+  5. **Sicherheitsmigration**: Ungesalzenes SHA1 (`SwRS-3`), hartkodierter Fallback-Schlüssel (`SwRS-5`), unverschlüsselte 2FA-Secrets und Klartext-Legacy-Passwörter (`SwRS-7`) sind als gebündeltes "Security-Debt"-Paket mit Migrationsstrategie zu bewerten.
+- **Offene Punkte ohne zugehörige Anforderung** (gemäß Vorgabe hier statt in `Hypothesen.md`): (a) Frage nach echter Mehrmandantenfähigkeit für SaaS - Codebasis belegt nur "eine Datenbank = ein Mandant" (SyRS-6), ein Zielsystem-Entscheid ist fachlich nicht belegbar; (b) `PermanentLoginToken`-Tabelle ohne Auth-Implementierung im Spiegel (mutmaßlich RMM-/Riverbird-Token, siehe NamedQuery in `NamedQueryPool.xml`); (c) Lizenzmodell für SaaS-Abo (GUID-Dateilizenzen `LicenseGuids` vs. Abo-Verwaltung).
@@ -0,0 +1,54 @@
+# Glossar - Domänenbegriffe der Anforderungsspezifikation
+
+| Begriff | Definition (Kontext c-entron) |
+|---|---|
+| Beleg / Receipt | Geschäftsdocument der Belegkette (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholung, Bestellung, Wareneingang, Lieferantenrechnung, Kassenrechnung). Technisch `ReceiptTable`-Vererbung, Status `ReceiptState` (offen/abgeschlossen/storniert). |
+| Mandant | Rechtlich selbstständige Firma, deren Stammdaten auf Tabelle `Mandant` liegen. Eine c-entron-Datenbank führt genau einen Mandanten. |
+| Filiale (Branch) | Untereinheit des Mandanten mit eigener Nummernkreisen-Zuordnung, Lager (`FilialeToLager`) und Kundenbindung (`CustomerToBranches`). |
+| Nummernkreis (NumberGroup) | Konfigurierbare fortlaufende Nummernvergabe je Objektart (Tabelle `Nummernkreis`, `NumberGroupBL.GetNextNumber`). |
+| Lager | Bestandshaltung: Hauptlager (`ARTIK.Menge`) und Nebenlager (`NebenlagerArtikel`); Lagerorte (`Lagerort`) und Lagerplätze (`Lagerplatz`). |
+| Barcode / Seriennummer | Einzstückkennung; Barcodes dienen zugleich als EAN-/Scanträger und Seriennummern (`Barcode`, `SeriennummerToPosition`), Zustände gemäß `BarcodeState`. |
+| Stammblätter / Assets | Historische Bezeichnung für als eigene Datenhaltung geführte Hardware (Drucker/Stammblätter) gegenüber allgemeinen Assets - Konsolidierungskandidat (siehe Analysebericht). |
+| Ticket / Helpdesk | Servicevorgang auf `hlpdsk_requests` mit datengetriebenen Statuswerten (`hlpdsk_status`), Typen, Kategorien, Prioritäten. |
+| Einschränkendes Recht | Rechteart, die nicht eine Aktion erlaubt, sondern die Datenmenge filtert (z. B. "nur eigene Tickets", "nur eigene Filiale"). |
+| C-FLOW | Ticketgebundener Formular-/Zustandsautomat auf Basis der SelfCare-Formulare (`Helpdesk.CFlowStateI3D`). |
+| Timer | Abrechnungsrelevanter Zeiteintrag zu einem Ticket (`hlpdsk_timer`) mit Fakturierungsstatus und ggf. Kundensignatur. |
+| MyDay | Persönliche Tagesarbeitsansicht; Tagesabschluss = Zertifizierungsmarker in `MyDayFinalizedDays`. |
+| Vertragsart / Vertrag | Wiederkehrendes Abrechnungsobjekt (`VertragKopf/Pos`) mit Intervallen, Kontingenten, Zählermodellen und Wartungsintervallen. |
+| Kontingent | Leistungsguthaben im Vertrag (Stunden oder Geld), das durch Belegbuchungen verbraucht wird. |
+| Klickzähler | Verbrauchszähler eines Geräts (z. B. Drucker, `GeraeteClickZaehler`), importiert und abrechenbar. |
+| Mahnlauf | Gestufter Forderungsverfolger (Stufen 1-3) über `DunningRunBL` und View `cvw_InvoiceDunnings`. |
+| Zahlungseingang | Zahlbuchung zu einem Beleg (`Zahlungseingang`), Verbuchung über `ReceiptBL.UpdateReceiptIsPaid`. |
+| OPOS | Offene Posten; im Code primär als Import-/View-Tabelle, live über `cvw_InvoiceHead`/`AccountUnpaidInvoice`. |
+| SEPA-Lastschrift | pain.008-Dateiexport zur Forderungseinziehung (`SepaFileGeneratorV2`). |
+| DATEV-Export | Buchhaltungsübergabe (ASCII Format 700 / XML Online) und weitere 12 Zielformate. |
+| EDI | Elektronischer Lieferantendatenaustausch (OpenTrans 2.1, Lieferantenformate Also/Komsa/Alltron/Herweck/EGIS; ohne EDIFACT). |
+| ZUGFeRD / XRechnung | E-Rechnungsstandards; einlesen aus PDF-Anhängen und erzeugen (`ZUGFeRD_BL`, `InvoiceZugferdBL`). |
+| ebInterface | Österreichisches E-Rechnungsformat (ebInterface 4.3-XML). |
+| Multidistributor | Lieferantenzusammenführung über ITscope/EGIS im EDI-Prozess (`EdiMultidistributors`). |
+| WebCart2 | Aktueller Blazor-Webshop mit Bestellfreigabekette (Lizenz `LicenseGuids.WebCart2`); Vorgänger: Delphi-Webshop-Tabellen. |
+| Web-Konto | Endkunden-Login (`WebAccounts`) mit eigenen Rechten und Freigabeprozess (Requested→Verified→Accepted/Denied). |
+| SelfCare-Formular | Verlinkbares Kundenformular, dessen Antwort Ticket-/C-FLOW-Zustände erzeugt. |
+| Rechte-Engine | Prüfung der ~751 Rechte (`UserRightsConst`) über `AppRightsBL` (Sichtrus/Sichmemb) bzw. `WebAccountsRights`. |
+| Sichbenu/Sichmemb/Sichtrus | Legacy-Tabellen für Benutzer, Gruppenmitgliedschaft, Gruppenrechte. |
+| 2FA / TOTP | Zweifaktor-Authentisierung (`TwoFactorAuthBL`, Google-Authenticator-Secrets in `Sichbenu.TwoFactorAuthKey`, Merkgeräte in `TwoFactorAuthLastLogins`). |
+| ConnectionTicket | DB-geführtes Sitzungsticket (`ConnectionTickets`, TTL 30 Minuten). |
+| Master-Key | Schlüssel für Geheimnisverschlüsselung, aus CentronConfigurationDb oder Secure-File. |
+| PasswordManager (Vault) | Lizenzierter verschlüsselter Zugangsdatenspeicher mit Richtlinien und Audit; Vorgänger: unverschlüsseltes `PasswordManagement`. |
+| RMM | Remote Monitoring & Management: AssetManagement*-Tabellen, Monitoring-Templates, DeployablePackages; Ausführung durch externen RiverSuite/Crawler-Dienst. |
+| RiverSuite / Riverbird / CentronDivo | Externer MSP-Dienst, der Crawler-/Monitoring-/Patchdaten in die c-entron-Datenhaltung schreibt und über `RiverConnectionBL` angebunden wird. |
+| MSP | Managed Service Provider - Zielrollenmodell des Produkts (IT-Systemhaus, das c-entron für Kunden betreibt). |
+| HostedService | Hintergrunddienst im Webservice-Host (`Centron.Host\AspNetCore\HostedServices`, 37 Dienste). |
+| NamedQuery | Wiederverwendbare Abfragendefinition in `NamedQueryPool.xml`. |
+| TemporaryEntities | Legacy-Tabellenbindung (z. B. Kunden, Anschrif, BestKopf2), die parallel zu neuen Entitäten synchronisiert wird. |
+| DMS / FileManagement | Dokumentenablage in `Documents` (varbinary, versioniert) mit automatischen Objektordnern (`DirectoryReferenceProviders`). |
+| DSGVO-Bereinigung | Gefiltertes Löschen/Anonymisieren von Altbeständen (`CentronDataSecurityViewModel`) samt AVV-Verwaltung. |
+| PLM | Produktlebenszyklusinformationen (aus Rechnungen importiert, `ProductLifecycleInformation`). |
+| Skriptmethode | Nummerierte Datenbankmigrationsklasse (`ScriptMethod10000`-`10987`), per Reflection ausgeführt. |
+| Lizenz-GUID | Freischaltungsschlüssel für Fachmodule (`LicenseGuids`). |
+| Aufschlag | Preiszuschlag auf Einkaufspreis (Legacy-Tabellen Warenaufschlaege/BMEcatAufschlaege; aktiv: Kalkulationsfaktor im Artikelimport). |
+| Staffelpreis (VolumePrice) | Mengenrabattstufe (`ArtikStaffelpreise` → `ArticleVolumePrices`). |
+| Sonderpreis | Kundenindividueller Preis (`KundenSonderpreise` → `AccountSpecialPrice`). |
+| Skonto | Abzugsfrist aus Zahlungsbedingung (`Zahkond`: LaenPer1-3, Skonto1-2). |
+| Eskalation | Prioritätsabhängige dreistufige Ticket-Hochstufung mit Geschäftszeitenlogik. |
+| Rechnungsstorno | Versionierte Nullsetzung einer Rechnung mit Status Canceled (keine separate Gutschrift). |
@@ -0,0 +1,39 @@
+# Hypothesen
+
+Sammlung aller Anforderungen mit `[HYPOTHESE]`-Status. Die Datei ist deckungsgleich mit den Inline-Markierungen in `StRS.md`, `SyRS.md` und `SwRS.md` (Stand: 3 Anforderungen). Offene Punkte ohne zugehörige Anforderung sind in der Selbstbewertung des `Analysebericht.md` erfasst.
+
+---
+
+## HYP-1 (SyRS-52) - EbInterface-E-Rechnung (Österreich)
+
+**Anforderung:** Das System soll österreichische E-Rechnungen im ebInterface-Format erzeugen.
+
+**Belegsituation:** Der Formatgenerator ist vollständig belegt: `src\apis\Centron.Api.EbInterface\EbInterfaceLogic.GenerateFile` erzeugt ebInterface-4.3-XML (Namespace `http://www.ebinterface.at/schema/4p3/`) mit Knoten InvoiceNumber/Delivery/Biller/Details/Tax/PaymentMethod.
+
+**Offene Frage:** Ein Aufrufer der Logik ist im vorliegenden Codebestand nicht enthalten (nur Projektreferenz in `Centron.BL.csproj`). Unklar ist, wie die EbInterface-Erzeugung in den Rechnungsversand eingebunden ist (manueller Export? Webservice? separate Altkomponente?).
+
+**Zur Bestätigung fehlt:** Aufrufstelle bzw. Release-Historie/Produktivnutzung für österreichische Mandanten.
+
+---
+
+## HYP-2 (SwRS-7) - Legacy-Passwortspeicher (PasswordManagement)
+
+**Anforderung:** Der unverschlüsselte Legacy-Passwortspeicher soll im Zielsystem nicht fortgeführt, sondern in den AES-Vault migriert werden.
+
+**Belegsituation:** Das technische Verhalten ist eindeutig belegt: `PasswordManagementKeywordBL.GetDecryptedKeywordById` führt den Dekryptierungsschritt nicht aus (Kommentar `// decryption` ohne Code) und gibt das Passwortfeld direkt zurück; `AddNewKeyword` legt `Salt=""`, `Password=""` an; die Tabellen `PasswordManagement`/`PasswordManagementKeyword` nutzen keine Verschlüsselung (SSMS_DB_SCHEMA.sql Z. 46138).
+
+**Offene Frage:** Ob dieser Speicher in Produktivinstallationen noch aktiv genutzt wird oder bereits vollständig durch den lizenzierten PasswordManager-Vault ersetzt ist.
+
+**Zur Bestätigung fehlt:** Nutzungs-/Migrationsstatistik oder Release-Hinweise; ggf. Abfrage der Datenfüllung in einer Produktivdatenbank (im vorliegenden Lauf nicht verfügbar).
+
+---
+
+## HYP-3 (SwRS-52) - Historisches Prüfwesen und Wartungstabellen
+
+**Anforderung:** Wartungsintervalle werden vertragsgetrieben als ToDos geführt und QM-Gründe je Belegart verwaltet; das historische Prüfwesen wird als veraltet bewertet.
+
+**Belegsituation:** Die Nachfolgerfunktionen sind belegt (Vertragsfelder `WartungIntervallArt/Dauer`, ToDo-Typ `ContractService`, QM-Grundverwaltung). Die Legacy-Tabellen `Wartung`, `WartungHistory*`, `Prufvorschrift`, `PrufvorschriftMesswert`, `Pruflinge`, `Prufmittel`, `GeraeteWartung` (SSMS_DB_SCHEMA.sql Z. 54533-54780, 47733-47788) besitzen keine Entität, kein Mapping und keine BL-/UI-Bindung im vorliegenden Spiegel.
+
+**Offene Frage:** Ob diese Tabellen durch den (nicht im Spiegel enthaltenen) Vorgänger-Client (c-entron.NET/Delphi-Client) oder externe Systeme noch aktiv beschrieben werden - die Datenhaltung ist angelegt und mit Indizes/Fremdschlüsseln versehen, was auf aktive Historie hindeutet.
+
+**Zur Bestätigung fehlt:** Zugriffsnachweis (Client-Quellcode außerhalb des Spiegels, DB-Audit, Lastspuren).
@@ -0,0 +1,353 @@
+# StRS - Stakeholder Requirements Specification
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Legacy C#/WPF + Webservice + Blazor-Webklient).
+Ebene 1 von 3 (StRS → SyRS → SwRS). Belegklassen: `PRIMÄR` (durchgesetzte Regel im Code/DB-Constraint), `SEKUNDÄR` (UI-Label, Mappingtabelle, Konfiguration), `KONTEXT` (Kommentar, Dokumentation). Pfade relativ zum Codebasis-Wurzelverzeichnis.
+
+---
+
+ID:            StRS-1
+Titel:         Zentrale Stammdatenverwaltung für Geschäftspartner und Artikel
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter Vertrieb/Einkauf, Verwaltung
+Vorbedingung:  Benutzer ist authentisiert und besitzt Zugriffsrechte auf Adress-/Artikelstamm.
+Fakt:          Kunden, Lieferanten, Anschriften und Kontakte werden über die Entitäten `Account`/`AccountAddress` mit Legacy-Synchronisation auf `Kunden`/`Anschrif`/`Kontakte` geführt (`src\backend\Centron.Entities\Entities\Accounts\Account.cs`, `src\backend\Centron.DAO\Mappings\Accounts\AccountAddressMaps.cs` → Tabelle "AccountAddresses", Legacy-Mappings unter `Mappings\TemporaryEntities\`). Kundennummern vergibt ein zentraler Nummernkreis (`src\backend\Centron.BL\Accounts\AccountBL.cs:131`).
+Aussage:       Das System soll Geschäftspartner (Kunden, Lieferanten, Interessenten) und Artikel als zentrale, mandantenweit einheitliche Stammdaten verwalten, von denen alle Fachprozesse (Belege, Tickets, Lager, Verträge) abhängen.
+Ergebnis:      Jeder Fachvorgang referenziert genau einen Stammsatz; Nummern sind eindeutig.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Accounts\AccountBL.cs (Kundennummerierung via NumberGroupBL) - Begründung: durchgesetzte Nummernvergabe beim Anlegen
+  - [SEKUNDÄR] src\backend\Centron.DAO\Mappings\TemporaryEntities\KundenMaps.cs, AnschrifMaps.cs, KontakteMaps.cs - Begründung: belegt die historische Datenhaltung, die mit den neuen Account*-Tabellen synchron gehalten wird
+Prüfidee:      Neu angelegter Kunde erhält eine fortlaufende, eindeutige Nummer; Belege, Tickets und Verträge lassen sich auf ihn referenzieren.
+Tracelinks:    SyRS-37, SyRS-53, SwRS-10, SwRS-32, SwRS-49
+Konsolidierung: Kandidat: Legacy-Tabellen Kunden/Anschrif/Kontakte vs. Account/AccountAddresses (zwei Datenhaltungen für denselben Gegenstand, gepflegt über AccountRepository-Sync)
+Übernahmewürdigkeit: übernehmen - Kern des Fachmodells; die Doppelhaltung ist zu einem Konzept zusammenzuführen
+Status:        belegt
+
+---
+
+ID:            StRS-2
+Titel:          Verkaufsprozess als Belegkette Angebot - Auftrag - Lieferschein - Rechnung - Gutschrift
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Vertrieb, Sachbearbeiter
+Vorbedingung:   Kunde und Artikel sind im Stamm angelegt.
+Fakt:           Die Belegarten sind als Vererbungshierarchie `ReceiptTable` mit je eigenen Kopf-/Positionstabellen (AngKopf, AufKopf, LiefKopf, RechKopf, GutKopf, ...) und eigenen Nummernkreisen umgesetzt; Belegarten-Enum `CentronObjectKindNumeric` (Angebot=1, Auftrag=2, Lieferschein=3, Rechnung=4, Gutschrift=6, ...) (`src\backend\Centron.Interfaces\CentronObjectKindNumeric.cs`).
+Aussage:        Das System soll den Verkaufsprozess als zusammenhängende Belegkette abbilden, in der Vorgänge aus Vorgstufen (z. B. Auftrag aus Angebot) erzeugt und bis zur Rechnung/Gutschrift fortgeschrieben werden.
+Ergebnis:       Jede Verkaufsphase ist als versionsfester Beleg nachvollziehbar; Übergänge erzeugen die Folgedokumente.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.Interfaces\CentronObjectKindNumeric.cs (Belegart-Enum inkl. IsCustomerReceipt/IsSupplierReceipt) - Begründung: definiert die gültigen Belegarten systemweit
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Finances\Receipts (rund 60 Unteransichten inkl. InsertReceipts/SearchReceipts) - Begründung: belegt die fachliche Breite der Belegverarbeitung
+Prüfidee:       Aus einem Angebot lässt sich ein Auftrag und aus diesem Lieferschein und Rechnung erzeugen; Nummern stammen aus getrennten Nummernkreisen.
+Tracelinks:     SyRS-9, SyRS-10, SyRS-11, SyRS-35, SyRS-52, SwRS-8, SwRS-11, SwRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess; Legacy-Belegarten (RundschrKopf/ClickKopf ohne C#-Mapping) sind als veraltet zu prüfen
+Status:         belegt
+
+---
+
+ID:            StRS-3
+Titel:          Preis- und Konditionenfindung pro Kunde und Menge
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Vertrieb, Sachbearbeiter
+Vorbedingung:   Artikel besitzt Listenpreise; Kunde kann Sonderpreise, Vertragspreise oder Staffelpreise besitzen.
+Fakt:           Die Preisauflösung folgt einer festen Reihenfolge Vertragspreis → Kundensonderpreis → Mengenstaffel → Listenpreis (Methode `ReceiptItemPriceBL.GetBasePrice`, `src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs:154`); USt über Tabelle `MwstSatz`.
+Aussage:        Das System soll Positionsentgelte automatisch nach prioritätsgeordneten Konditionen (Vertrag, Sonderpreis, Staffel, Liste) und dem gültigen USt-Satz ermitteln, sodass Preise reproduzierbar und prüfbar sind.
+Ergebnis:       Jede Belegposition trägt einen nachvollziehbar hergeleiteten Einzelpreis.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs:154 (GetBasePrice) - Begründung: zentrale, durchgesetzte Preisauflösung
+  - [SEKUNDÄR] src\backend\Centron.DAO\Mappings\Warehousing\ArticleVolumePricesMaps.cs (ArtikStaffelpreise), Mappings\CustomerArea\CustomerDetails\CustomerSpecialPriceMaps.cs (KundenSonderpreise) - Begründung: belegt die Konditionsdatenhaltungen
+Prüfidee:       Für einen Kunden mit Sonderpreis wird dieser vor Staffel- und Listenpreis verwendet; ohne Sonderpreis greift die Mengenstaffel ab der Schwellenmenge.
+Tracelinks:     SyRS-12, SyRS-13, SwRS-9
+Konsolidierung: Kandidat: Vertragspreise (VertragBepreisung*) und Kundensonderpreise (KundenSonderpreise) sind zwei Mechanismen für "kundenindividuelle Preise"
+Übernahmewürdigkeit: übernehmen - Kern der Abrechnungslogik; ein einheitliches Preisregelwerk sollte die Sonderfälle ablösen
+Status:         belegt
+
+---
+
+ID:            StRS-4
+Titel:          Geldeingang, Mahnwesen und Bankanbindung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Buchhaltung, Sachbearbeiter Finanzen
+Vorbedingung:   Offene Rechnungen existieren; Bankverbindungen sind konfiguriert.
+Fakt:           Zahlungseingänge buchen auf `RechKopf.Payed` über `ReceiptBL.UpdateReceiptIsPaid` (`src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:4902`); ein 3-stufiger Mahnlauf setzt Mahnstufen 1-3 (`src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs`); Bankbuchungen können über FinTS/FinAPI/Tabellenimport importiert und automatisch zugeordnet werden (`src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs`); SEPA-Lastschriften werden als pain.008 exportiert (`src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs`).
+Aussage:        Das System soll den gesamten Zahlungsverkehr abdecken: Erfassung und Ausgleich von Zahlungen, gestufte Mahnung überfälliger Forderungen, Bankkontenabgleich und SEPA-Lastschriftverfahren.
+Ergebnis:       Offene Posten sind jederzeit korrekt; überfällige Forderungen werden gestuft gemahnt; Bankzahlungen sind automatisch Rechnungen zugeordnet.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingAccountTransactionsBL.cs (AutoComplete/BookAmounts) - Begründung: durchgesetzte Zuordnungs- und Verbuchungslogik
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs - Begründung: setzt Mahnstufen und protokolliert sie
+  - [SEKUNDÄR] src\backend\Centron.Gateway\DataExchange\PaymentTransactions\Sepa\SepaFileGeneratorV2.cs (pain.008.001.08) - Begründung: belegt das SEPA-Format
+Prüfidee:       Eine Zahlung in Rechnungshöhe schließt die Rechnung; eine überfällige Rechnung durchläuft nach Ablauf der Kundenvorgaben Mahnstufe 1-3.
+Tracelinks:     SyRS-14, SyRS-15, SyRS-16, SyRS-17, SwRS-13, SwRS-16, SwRS-17, SwRS-18
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess; die Heuristik-Zuordnung sollte konfigurierbar erhalten bleiben
+Status:         belegt
+
+---
+
+ID:            StRS-5
+Titel:          Buchhaltungsübergabe und Kassenbuchführung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Buchhaltung, Steuerberatung
+Vorbedingung:   Belege sind abgeschlossen; Export ist konfiguriert.
+Fakt:           13 Buchhaltungs-Zielsysteme werden über `IBookKeepingExport`-Klassen bedient, u. a. DATEV (ASCII Format 700 + XML Online) und Sage/Infoniqa (`src\backend\Centron.Entities\Entities\DataExchange\BookKeeping\Export\BookKeepingExportTypes.cs`, `src\backend\Centron.Gateway\DataExchange\BookKeeping\DatevAscii\BookKeepingExportDatevAscii.cs`); Kassenbuchbuchungen sind nach Abschluss (`ClosedDate`) unveränderlich (`src\backend\Centron.BL\Sales\CashBooks\CashBookBL.cs`).
+Aussage:        Das System soll Geschäftsvorfälle revisionssicher an Finanzbuchhaltungssysteme übergeben und Barvorgänge in einem abgeschlossenen, unveränderlichen Kassenbuch führen.
+Ergebnis:       Exportierte Daten erzeugen in der Finanzbuchhaltung korrekte Buchungen; abgeschlossene Kassenbuchzeilen sind nicht mehr änderbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\CashBooks\CashBookBL.cs (SaveCashBookBooking verweigert Änderung abgeschlossener Buchungen) - Begründung: durchgesetzte Unveränderlichkeit
+  - [PRIMÄR]   src\backend\Centron.Gateway\DataExchange\BookKeeping\DatevAscii\BookKeepingExportDatevAscii.cs - Begründung: konkretes Exportformat mit Feldzusammensetzung
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\DataExchange\BookKeeping\Export\BookKeepingExportTypes.cs (13 Ziele) - Begründung: belegt die Schnittstellenvielfalt
+Prüfidee:       Export für Debitoren erzeugt eine DATEV-Datei, deren Summen der Belegauswahl entsprechen; Änderungsversuch einer abgeschlossenen Kassenbuchzeile wird abgelehnt.
+Tracelinks:     SyRS-18, SyRS-19, SwRS-14, SwRS-15
+Konsolidierung: Kandidat: die 13 Exportformate teils mit identischer Feldlogik - im Zielsystem über ein Konfigurationsmodell zusammenführen
+Übernahmewürdigkeit: übernehmen (Kasse, DATEV); veraltet für Nischenformate ohne aktuellen Nutzer (im Zielsystem prüfen)
+Status:         belegt
+
+---
+
+ID:            StRS-6
+Titel:          Beschaffung: Bedarfsermittlung, Bestellung, Wareneingang und Lieferantendaten
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Einkauf, Lager
+Vorbedingung:   Artikel mit Mindestbestand; Lieferanten mit EDI-Konfiguration vorhanden.
+Fakt:           Bestellvorschläge werden aus `Mindestbestand` abgeleitet (`src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs`, SQL nutzt `a.Mindestbestand MinimumQuantity`); Lieferantenbestellungen laufen über das einheitliche Belegmodell (`SupplierOrders`/`SupplierOrderItems`, `src\backend\Centron.BL\Sales\Receipts\SupplierOrders\SupplierOrderBL.cs`); EDI-Anbindung je Lieferant über `SupplierEdiConfigurations` (`src\backend\Centron.BL\EDI\SupplierEDI\SupplierEdiConfigurationsBL.cs`).
+Aussage:        Das System soll den Beschaffungsprozess von der Bedarfserkennung über Lieferantenbestellung (auch maschinell per EDI) bis zum Wareneingang unterstützen.
+Ergebnis:       Bestellungen sind vollständig nachvollzogen; gelieferte Mengen erhöhen Bestände; Eingangsrechnungen sind zuordenbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs - Begründung: durchgesetzte Vorschlagslogik auf Basis Mindestbestand
+  - [PRIMÄR]   src\backend\Centron.BL\EDI\SupplierEDI\SupplierEdiBL.cs (DownloadStartAsync/ApplyDistriToCentron) - Begründung: durchgesetzter EDI-Datenfluss
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Purchasing (OrderSuggestionList, EDIManagement) - Begründung: belegt die Modulfunktionen
+Prüfidee:       Artikel unter Mindestbestand erscheint im Bestellvorschlag; Bestellung per OpenTrans an Lieferant, dessen Bestellantwort im System auftaucht.
+Tracelinks:     SyRS-22, SyRS-31, SyRS-32, SyRS-33, SyRS-34, SwRS-33, SwRS-34, SwRS-35, SwRS-36
+Konsolidierung: Kandidat: Legacy `BestKopf2/BestPos2` vs. neue `SupplierOrders/SupplierOrderItems` - zwei Datenhaltungen für Bestellungen
+Übernahmewürdigkeit: übernehmen; Legacy-Bestelltabellen als veraltet einstufen
+Status:         belegt
+
+---
+
+ID:            StRS-7
+Titel:          Lagerbewirtschaftung und Seriennummernverfolgung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Lager, Service
+Vorbedingung:   Artikel und Lagerorte sind angelegt.
+Fakt:           Bestände je Haupt-/Nebenlager (`ARTIK.Menge`, `NebenlagerArtikel`) werden beleggetrieben über `ReceiptArticleBookingBL.UpdateStock` gebucht (`src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptArticleBookingBL.cs`); Seriennummern sind Barcodes mit Zustandsmaschine `BarcodeState` (InStock, InOrder, InDeliveryList, InInvoice, InRMA, Scrapped, ...) (`src\backend\Centron.Interfaces\Warehousing\BarcodeState.cs`); Inventuren zählen und buchen (`src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs:867`).
+Aussage:        Das System soll Bestände je Lagerort führen, Belegbuchungen automatisch verbuchen und seriennummernpflichtige Artikel lückenlos vom Wareneingang bis zum Kunden/RMA verfolgen.
+Ergebnis:       Bestandsangaben stimmen mit Belegen überein; jede Seriennummer hat einen eindeutigen Zustand und eine Historie.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptArticleBookingBL.cs (BookArticles/UpdateStock) - Begründung: durchgesetzte Bestandsbuchung je Beleg
+  - [PRIMÄR]   src\backend\Centron.Interfaces\Warehousing\BarcodeState.cs - Begründung: definiert den lückenlosen Seriennummern-Lebenszyklus
+  - [SEKUNDÄR] src\backend\Centron.DAO\Mappings\Warehousing\StockManagement\*.cs (Nebenlager, Lagerort, Lagerplatz) - Begründung: belegt die Lagerdatenhaltung
+Prüfidee:       Lieferscheinbuchung verringert den Bestand und setzt Seriennummern auf InDeliveryList; nach Rechnung folgt InInvoice.
+Tracelinks:     SyRS-20, SyRS-21, SyRS-23, SyRS-24, SwRS-19, SwRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernbestandteil; Barcode/Serialnummern-Einheit im Zielsystem beibehalten
+Status:         belegt
+
+---
+
+ID:            StRS-8
+Titel:          Service- und Ticketprozess mit Priorisierung, Eskalation und Kundenbeteiligung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Servicetechniker, Dispatcher, Endkunde
+Vorbedingung:   Tickettypen, -status, -kategorien und Prioritäten sind konfiguriert.
+Fakt:           Tickets liegen auf `hlpdsk_requests` mit datengetriebenen Statuswerten; der Abschluss erfordert das Recht CLOSE_REQUEST (`src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs:433-438`); Prioritäten steuern die Fälligkeit über Bürozeiten (`HelpdeskBL.GetDueDateFromPriority`, `HelpdeskBL.cs:786`); ein Dienst eskaliert überfällige Tickets alle 15 Minuten in 3 Stufen (`src\webservice\Centron.Host\AspNetCore\HostedServices\EscalationsService.cs`); Endkunden reichen über Weblinks SelfCare-Formulare ein, die Tickets erzeugen (`src\backend\Centron.BL\WebServices\SelfCare\SelfCareWebserviceBL.cs:1863`).
+Aussage:        Das System soll einen steuerbaren Serviceprozess bieten: Erfassung, Zuweisung, priorisierungsgesteuerte Fälligkeit, automatische Eskalation sowie Beteiligung des Endkunden über Formulare und Portal.
+Ergebnis:       Kein Ticket bleibt unbehandelt eskalationslos; Kundenauskünfte und -anfragen landen strukturiert im System.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs:418-466 (CheckUserRigths) - Begründung: durchgesetzte Rechte-/Statusregeln beim Ticketabschluss
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Support\Escalation\EscalationBL.cs (DoEscalation) - Begründung: durchgesetzte Eskalationsstufen
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\CustomerArea\Support\HelpdeskPriorityBase.cs (DueDateDelayInHours, OfficeHourFrom/To) - Begründung: belegt die SLA-Parameter
+Prüfidee:       Ticket der Priorität "kritisch" erhält Fälligkeit innerhalb der Bürozeit; nach Überschreitung kommen Stufe-1-Benachrichtigungen, nach weiteren Stufen Stufe 3.
+Tracelinks:     SyRS-25, SyRS-27, SyRS-45, SwRS-22, SwRS-26, SwRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernprozess
+Status:         belegt
+
+---
+
+ID:            StRS-9
+Titel:          Leistungserfassung mit Kundennachweis und Fakturierfähigkeit
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Techniker, Kunde (Unterschrift), Abrechnung
+Vorbedingung:   Ticket existiert; Zeitartikel und Fakturierungsstatus sind konfiguriert.
+Fakt:           Zeiten werden als Stopuhr-Ereignisfolge (Start/Pause/Resume/Stop) erfasst und als `hlpdsk_timer` gespeichert (`src\backend\Centron.BL\Sales\Support\HelpdeskTimeRecordingBL.cs`); Kundenunterschriften werden als Bildbytes an Timer gebunden (`HelpdeskTimerSignatureBL.SignMultipleTimers`); Timers tragen Fakturierungsstatus und werden in Rechnungspositionen überführt (`src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemTimerBL.cs`).
+Aussage:        Das System soll geleistete Arbeit nachweisbar erfassen (inkl. Kundensignatur) und direkt fakturierbar in Belege überführen, ohne Doppel- oder Verlustbuchungen.
+Ergebnis:       Jede fakturierte Zeit ist dem Ticket, Techniker und Kundennachweis zugeordnet; Fakturierungsstatus verhindert Doppeltabrechnung.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemTimerBL.cs (FillReceiptWithTimerI3Ds/RemoveTimers) - Begründung: durchgesetzte Zuordnung Zeiten→Rechnungspositionen
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Support\HelpdeskTimeRecordingBL.cs (StartRecording/PauseRecording/StopRecording) - Begründung: durchgesetzte Erfassungsregeln
+  - [SEKUNDÄR] src\shared\Centron.Controls\Common\PaintSurface.cs (Unterschriftenfläche) - Begründung: belegt die Signaturerfassung im UI
+Prüfidee:       Signierte Zeiten lassen sich genau einmal in eine Rechnung buchen; Entfernen der Signatur erfordert eigenes Recht; nach Rechnung ist der Timer geblockt.
+Tracelinks:     SyRS-26, SyRS-28, SwRS-23, SwRS-24, SwRS-25, SwRS-27
+Konsolidierung: Kandidat: Ticketzeiten (hlpdsk_timer) und allgemeine Zeiterfassung/MyDay (MyDayWorkItems) sind zwei Zeiterfassungswelten
+Übernahmewürdigkeit: übernehmen; MyDay-Tageszertifikation als ergänzendes Konzept
+Status:         belegt
+
+---
+
+ID:            StRS-10
+Titel:          Vertrags- und Kontingentabrechnung (Pauschalen, Zähler, Leasing)
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Vertrieb, Abrechnung, Kunde
+Vorbedingung:   Vertragsart, Intervalle, Kontingente bzw. Zähler sind konfiguriert.
+Fakt:           Verträge kennen Abrechnung vor/nach Leistungszeitraum und Intervalle (Tage/Monate/Jahr) (`src\backend\Centron.Interfaces\Sales\BillingCenter\Contracts\BillingIntervalKinds.cs`); Kontingente (Stunden/Geld) werden bei Belegbuchung konsumiert (`src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptContractHelperBL.cs:135-811`); Geräte-Klickzähler werden importiert und über `AutomaticFacturaBL` abgerechnet; Leasingraten werden aus Prozentsätzen je Laufzeit gebildet (`src\centron\Centron.WPF.UI\Modules\Finances\Receipts\CalculationTab\CalculationTabViewModel.cs:294-475`).
+Aussage:        Das System soll wiederkehrende und verbrauchsabhängige Entgelte (Wartungspauschalen, Kontingente, Klick-/Verbrauchszähler, Leasing) aus Verträgen heraus automatisch abrechnen.
+Ergebnis:       Vertragskunden erhalten periodisch korrekte Rechnungen; Kontingentüberschreitungen und Zählerstände sind abgerechnet und protokolliert.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptContractHelperBL.cs (UsedContingent/UpdateContingent) - Begründung: durchgesetzte Kontingentführung bei Buchungen
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\CustomerAssets\AutomaticFactura\AutomaticFacturaBL.Contracts.cs (Klickzähler-Abgleich) - Begründung: durchgesetzte Zählerabrechnung
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\DbEntities\VertragKopf.cs (WartungIntervallArt/Dauer) - Begründung: belegt die Vertrags-Abrechnungsparameter
+Prüfidee:       Monatsvertrag wird zum Intervall fällig; Buchung über Kontingent vermindert den Restwert; importierter Klickzähler erzeugt eine Abrechnungsposition bis zur Saldierung.
+Tracelinks:     SyRS-29, SyRS-30, SyRS-26, SwRS-19, SwRS-52
+Konsolidierung: Kandidat: FlatrateBilling, AutomatedBilling, TimerBilling, ClickContracts - vier Abrechnungszugänge auf denselben Vertragsdaten
+Übernahmewürdigkeit: übernehmen - Kern der wiederkehrenden Abrechnung; Zugänge im Zielsystem auf eine Abrechnungsengine führen
+Status:         belegt
+
+---
+
+ID:            StRS-11
+Titel:          Endkunden-Beteiligung: Portal, Webshop und Kommunikation
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Endkunde (Web-Konto), Vertrieb
+Vorbedingung:   Web-Konto ist freigegeben; Artikel/Sonderpreise sind für den Kunden freigegeben.
+Fakt:           Der Blazor-Webklient bietet Kundenportal (Belege, Verträge, Tickets, Dokumente) und Webshop "WebCart2" mit Freigabekette bis zur Auftragsanlage (`src\nexus\CentronNexus\WebCart\*.razor`, `src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs:167-208`); Selbstregistrierung läuft über Requested→Verified→Accepted/Denied (`src\backend\Centron.BL\WebServices\Sales\Customers\AddressContactWebServiceBL.cs:458-650`); Kampagnen/Mailings und Umfragen adressieren Kunden proaktiv (`src\backend\Centron.BL\Accounts\Campaigns\CampaignBL.cs`, `SurveyProcessBL`).
+Aussage:        Das System soll Endkunden selbstbedient Belege, Verträge, Tickets und Artikel zugänglich machen (Webshop mit Bestellfreigabe) und proaktiv über Kampagnen, Mailings und Umfragen ansprechen.
+Ergebnis:       Bestellungen aus dem Shop erzeugen Aufträge im ERP; Kunden sehen nur ihre eigenen Daten; Marketingmaßnahmen sind nachvollziehbar dokumentiert.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\ReceiptCartReleaseSystemBL.cs (OrdererApproveCart/ForwardCartToOrder) - Begründung: durchgesetzte Freigabe- und Auftragsanlage
+  - [PRIMÄR]   src\backend\Centron.BL\WebServices\Sales\Customers\AddressContactWebServiceBL.cs (ChangeAddressContactPersonWebAccountRequestState) - Begründung: durchgesetzter Freigabeprozess für Web-Konten
+  - [SEKUNDÄR] src\nexus\CentronNexus\WebCart\CustomerPortal\*.razor - Begründung: belegt die Portal-Funktionen
+Prüfidee:       Web-Kunde bestellt Artikel → nach interner Freigabe entsteht ein Auftrag und Bestätigungsmails gehen raus; Selbstregistrierung ohne Prüfung erzeugt kein Konto.
+Tracelinks:     SyRS-7, SyRS-36, SyRS-38, SyRS-48, SwRS-38, SwRS-39, SwRS-58
+Konsolidierung: Kandidat: Legacy-Delphi-Webshop-Tabellen (WebShopKopf/Pos) vs. WebCart2 - im Zielsystem nur ein Shopkonzept
+Übernahmewürdigkeit: übernehmen (WebCart2/Portal); veraltet für die Delphi-Shop-Tabellen
+Status:         belegt
+
+---
+
+ID:            StRS-12
+Titel:          Berechtigte Datenverwendung: Rollen, Filialen und Datenschutz
+Ebene:          StRS
+Typ:            Sicherheit
+Qualitätsmerkmal:
+Akteur:         Administrator, Datenschutzbeauftragter, alle Benutzer
+Vorbedingung:   Benutzergruppen und Rechte sind konfiguriert.
+Fakt:           Rechte werden über Gruppenzugehörigkeit (Sichmemb) und Rechtezuordnung (Sichtrus) je Benutzer geprüft (`src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644-693`); einschränkende Rechte filtern Daten (z. B. Tickets nur eigene/eigene Filiale, `src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs:233-291`); Daten sind je Mandant/Filiale getrennt (`src\backend\Centron.BL\Administration\Company\BranchBL.cs:173-197`); DSGVO-Bereinigung erlaubt Löschen/Anonymisieren alter Kundendaten (`src\centron\Centron.WPF.UI\Modules\Administration\DSGVO\CentronDataSecurityViewModel.cs`).
+Aussage:        Das System soll Zugriffe rollenbasiert und datensichtbar einschränken (auch "nur eigene"/"nur eigene Filiale"), Mandanten-/Filialtrennung durchsetzen und Datenschutzanforderungen (Bereinigung, Anonymisierung, AVV-Verwaltung) erfüllen.
+Ergebnis:       Benutzer sehen und ändern ausschließlich zuständige Daten; Datenschutzauflagen sind im System abarbeitbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644 (HasUserRight mit SQL über Sichtrus/Sichmemb) - Begriffsbegründung: durchgesetzte Rechteprüfung
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs:233-291 (GetLoggedInUserShowHelpdeskRight) - Begründung: durchgesetzte einschränkende Rechte
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Administration\DSGVO\CentronDataSecurityViewModel.cs - Begründung: belegt die Bereinigungsfunktionen
+Prüfidee:       Benutzer ohne HELPDESK-Recht sieht keine Tickets; mit SHOW_HELPDESK_ONLY_OWN nur eigene; DSGVO-Bereinigung anonymisiert Kontaktdaten alter Datensätze nach Filter.
+Tracelinks:     SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6, SyRS-42, SyRS-44, SwRS-1, SwRS-2, SwRS-46
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Grundpfeiler; unsichere Legacy-Details (ungenutzter Klartextspeicher, ungesalzenes SHA1) sind als Workaround/veraltet zu ersetzen
+Status:         belegt
+
+---
+
+ID:            StRS-13
+Titel:          IT-Betreuung (MSP): Inventar-, Monitoring- und Patchdaten in Kundenservice integrieren
+Ebene:          StRS
+Typ:            Schnittstelle
+Qualitätsmerkmal:
+Akteur:         IT-Betreuer (MSP), Monitoring-Verantwortlicher
+Vorbedingung:   Crawling-/Monitoring-Dienst (RiverSuite) liefert Daten in die c-entron-Datenhaltung.
+Fakt:           Rund 75 `AssetManagement*`-Tabellen (Geräte, Checks, AD, Software, CVEs) werden per SQL-Skripten der c-entron-Datenhaltung hinzugefügt und vom externen RiverSuite/Crawler befüllt (`src\backend\Centron.BL\Administration\Scripts\ScriptMethods\SqlStatements\SQLScriptCollection1.xml`); Monitoring-Templates und Benachrichtigungszuordnungen werden im ERP konfiguriert (`MonitoringTemplates`, `MonitoringGlobalNotifications`); Patchpakete werden als `DeployablePackages` mit Job-Status-Enums geführt; Rechte (z. B. 20800015 ALLOW_RIVERSUITE_MONITORING_LOGIN) schützen die Funktion (`src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs`).
+Aussage:        Das System soll erfasste Kundengeräte, Prüfergebnisse, Monitoring-Konfiguration und Patch-Verteilung als Teil der Kundenserviceabwicklung führen und auswertbar machen.
+Ergebnis:       Techniker sehen Inventar und Check-Status beim Kundenvorgang; Monitoring-Meldungen sind zuständigkeitsgerecht verteilt.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Scripts\ScriptMethods\SqlStatements\SQLScriptCollection1.xml (AssetManagement-Tabellen) - Begründung: definiert die Datenhaltung der RMM-Integration
+  - [PRIMÄR]   src\backend\Centron.BL\RiverDivo\RiverConnectionBL.cs (GetDevices/Call) - Begründung: durchgesetzte Webservice-Anbindung an die RiverSuite
+  - [SEKUNDÄR] src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs (Riversuite-Rechte 20800015 ff.) - Begründung: belegt die Zugriffssteuerung
+Prüfidee:       Nach Crawlerlauf erscheinen Kundengeräte mit Checkergebnissen; Monitoring-Template-Zuordnung sendet Meldungen an die konfigurierte Abteilung.
+Tracelinks:     SyRS-50, SyRS-51, SwRS-54
+Konsolidierung: Kandidat: AssetManagement*-Tabellen (Crawler) vs. GeraeteKopf (verkaufte Geräte) vs. Barcode - drei Gerätesichten
+Übernahmewürdigkeit: übernehmen - Differenzierung MST-Service; im Zielsystem Gerätesichten vereinheitlichen
+Status:         belegt
+
+---
+
+ID:            StRS-14
+Titel:          Produktion und Produktlebenszyklus nach Auslieferung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Fertigung, Produktmanagement
+Vorbedingung:   Verkaufsauftrag bzw. Rechnung existiert.
+Fakt:           Produktionsaufträge verfolgen Positionen mit Status (Offen/In Bearbeitung/Beendet) und Arbeitskräften (`src\backend\Centron.Interfaces\Production\ProductionOrderItemState.cs`); PLM importiert aus Rechnungen verkaufte Produkte mit Lifecycle-Daten (Start/Ende, Lizenzschlüssel) und erzeugt Wiederverkaufs-ToDos (`src\backend\Centron.BL\Warehousing\ArticleManagement\ProductFamilyBL.cs`).
+Aussage:        Das System soll kundenspezifische Fertigung nachvollziehen und nach Auslieferung den Lebenszyklus (Ablauf, Erneuerung) der beim Kunden betriebenen Produkte steuern.
+Ergebnis:       Produktionsfortschritt ist je Auftrag sichtbar; ablaufende Kundenprodukte erzeugen rechtzeitige Angebots-/Erinnerungsaktivitäten.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.Interfaces\Production\ProductionOrderItemState.cs - Begründung: definiert die Produktions-Statusmaschine
+  - [PRIMÄR]   src\backend\Centron.BL\Warehousing\ArticleManagement\ProductFamilyBL.cs (ImportProductLifecycleInformations) - Begründung: durchgesetzter Rechnungs-PLM-Import
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\PLM\PlmViewModel.cs - Begründung: belegt die Modulfunktionen
+Prüfidee:       Aus einem Auftragsposition entsteht ein Produktionsauftrag mit Statuswechseln; importierte Lifecycle-Zeile erzeugt ein ToDo vor Enddatum.
+Tracelinks:     SyRS-46, SyRS-49, SwRS-30, SwRS-31
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen; Fertigung ohne Warenbestandsverbuchung ist bewusst schlank zu halten
+Status:         belegt
+
+---
+
+ID:            StRS-15
+Titel:          Auswertung und Controlling über alle Geschäftsbereiche
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Geschäftsführung, Controlling, Teamleitung
+Vorbedingung:   Fachdaten existieren; Statistik-Caches sind aufgefrischt.
+Fakt:           Verkaufs-, Ticket-, Auftrags- und Vertragsstatistiken werden in Cache-Tabellen (CacheSalesStatistic, CacheTicketStatistic, CacheOrderStatistic) aufbereitet (`src\backend\Centron.BL\Statistics\SaleStatistics\CacheSalesStatisticsBL.cs`); das Statistik-Modul bietet Dashboards (Sales, EmployeeAnalytics, ManagementInfo, MSP) (`src\centron\Centron.WPF.UI\Modules\Statistics\`); Berichte sind DB-getriebene FastReport-Definitionen (`src\backend\Centron.BL\ReportEngine\ReportDataBL.cs`); MSP-Lizenzdaten kommen über MspCollectors (u. a. ArrowSphere) (`src\backend\Centron.BL\Statistics\MspCollectors\MspCollectorsBL.cs`).
+Aussage:        Das System soll Umsatz, Service- und Mitarbeiterkennzahlen sowie Lizenz-/Abrechnungsdaten aggregiert und als Bericht bereitstellen.
+Ergebnis:       Leitung entscheidet auf Basis konsistenter Kennzahlen; Berichte sind ohne Programmierung anpassbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Statistics\SaleStatistics\CacheSalesStatisticsBL.cs - Begründung: durchgesetzte Statistik-Aufbereitung
+  - [PRIMÄR]   src\backend\Centron.BL\ReportEngine\ReportDataBL.cs (FastReport-Rendering) - Begründung: durchgesetzte Berichtsgenerierung
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Statistics (Dashboard\SalesStatistics, ManagementInfo, MspCollectors) - Begründung: belegt die Auswertungsvielfalt
+Prüfidee:       Nach Cache-Update zeigt das Umsatz-Dashboard Werte, die mit dem Belegbestand abstimmen; Freigabe eines Berichts erzeugt PDF mit gespeicherter Definition.
+Tracelinks:     SyRS-11, SyRS-47, SyRS-51, SwRS-42, SwRS-48, SwRS-57
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:         belegt
+
+---
+
+ID:            StRS-16
+Titel:          Automatisierte Datenversorgung, Massenpflege und KI-Unterstützung
+Ebene:          StRS
+Typ:            funktional
+Qualitätsmerkmal:
+Akteur:         Systemadministration, Einkauf, Techniker
+Vorbedingung:   Import-/Konfigurationsquellen sind eingerichtet.
+Fakt:           Lieferantenpreislisten werden per FTP/SFTP/HTTP importiert und mit Kalkulationsfaktor bepreist (`src\backend\Centron.BL\Warehousing\ArticleManagement\ArticleImportBL.cs`); Hintergrunddienste führen periodische Aufgaben aus (EDILoad, Artikelimport, Volltextindex, Erinnerungen, Vertragsabschluss, 37 HostedServices in `src\webservice\Centron.Host\AspNetCore\HostedServices\`); Massenupdates ändern Artikel-, Beleg- und Kundenpreise per Assistent (`src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs`); KI-Dienste (OpenAI, Gemini, Mistral, Claude) erzeugen u. a. Ticketzusammenfassungen und Positionstexte (`src\backend\Centron.BL\ArtificialIntelligence\OpenAiApiClient.cs`).
+Aussage:        Das System soll wiederkehrende Datenerfassung und -pflege automatisieren (Importe, Dienste, Massenänderungen, versionierte Datenbankmigrationen) und KI-Assistenz für Text- und Ticketarbeit bereitstellen.
+Ergebnis:       Stammdaten sind aktuell ohne manuelle Eingabe; Massenänderungen sind vorab prüfbar; KI-Entwürfe bleiben nachvollziehbar und konfigurierbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Warehousing\ArticleManagement\ArticleImportBL.cs (StartImport, Kalkulationsfaktor) - Begründung: durchgesetzte Import-/Preislogik
+  - [PRIMÄR]   src\webservice\Centron.Host\AspNetCore\HostedServices (37 Background-Dienste) - Begründung: belegt die Automatisierungslandschaft
+  - [SEKUNDÄR] src\backend\Centron.BL\ArtificialIntelligence\Prompts\OpenAiPrompts.cs - Begründung: belegt die KI-Einsatzzwecke
+Prüfidee:       Nach Importlauf existieren Artikel mit berechneten Verkaufspreisen; Massenpreisupdate zeigt Vorschau und schreibt Historie; KI erzeugt aus Ticketverlauf eine Zusammenfassung.
+Tracelinks:     SyRS-33, SyRS-34, SyRS-39, SyRS-40, SyRS-41, SyRS-43, SyRS-44, SwRS-33, SwRS-43, SwRS-44, SwRS-45
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen; externe KI-Abhängigkeiten datenschutzseitig prüfen
+Status:         belegt
@@ -0,0 +1,81 @@
+# Traceability
+
+Konsolidierte Traceability-Tabelle: `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+Hauptverweise: jede SwRS-Zeile über ihre SyRS-Eltern zur StRS-Ebene. SyRS-Anforderungen ohne eigene SwRS-Unterkante sind als eigene Zeilen mit SwRS "—" geführt.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (repräsentativ) |
+|---|---|---|---|
+| StRS-2, StRS-16 | SyRS-1 | SwRS-8 | src\webservice\Centron.Host\Services\CentronRestService.cs |
+| StRS-16 | SyRS-1 | SwRS-55 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs |
+| StRS-16 | SyRS-1 | SwRS-56 | src\webservice\c-entron.misc.ConnectionManager\Dialogs\TwoFactorAuthTestView.xaml.cs |
+| StRS-12 | SyRS-2 | SwRS-3 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs:46-50 |
+| StRS-12 | SyRS-3 | SwRS-3 | src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs |
+| StRS-12 | SyRS-4 | SwRS-4 | src\backend\Centron.BL\Administration\Logins\TicketBL.cs:26 |
+| StRS-8, StRS-12 | SyRS-5 | SwRS-1 | ...\UserRightsConst.cs (751 Rechtekonstanten) |
+| StRS-8, StRS-12 | SyRS-5 | SwRS-2 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644 |
+| StRS-12 | SyRS-6 | — | src\backend\Centron.BL\Administration\Company\BranchBL.cs:173-197 |
+| StRS-11, StRS-12 | SyRS-7 | SwRS-39 | ...\AddressContactWebServiceBL.cs:458-650 |
+| StRS-12 | SyRS-8 | SwRS-3 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs (SHA1) |
+| StRS-12 | SyRS-8 | SwRS-5 | src\backend\Centron.Common\TextCoding\AESCryptoLogic.cs:77 |
+| StRS-12 | SyRS-8 | SwRS-6 | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs:700 |
+| StRS-12 | SyRS-8 | SwRS-7 [HYPOTHESE] | ...\PasswordManagementKeywordBL.cs:21 |
+| StRS-1, StRS-2 | SyRS-9 | SwRS-10 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:50-94 |
+| StRS-2 | SyRS-10 | SwRS-11 | ...\AutomaticallyCloseReceiptHelperBL.cs:22-78 |
+| StRS-2 | SyRS-10 | SwRS-12 | ...\ReceiptInvoiceBL.cs:143-206 |
+| StRS-2, StRS-15 | SyRS-11 | SwRS-57 | src\backend\Centron.BL\ReportEngine\ReportDataBL.cs |
+| StRS-3 | SyRS-12 | SwRS-9 | ...\ReceiptItemPriceBL.cs:154 |
+| StRS-3 | SyRS-13 | — | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs:350 |
+| StRS-4 | SyRS-14 | SwRS-13 | ...\DunningRunBL.cs + ScriptMethod11108.cs |
+| StRS-4 | SyRS-15 | SwRS-18 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:4902 |
+| StRS-4 | SyRS-16 | SwRS-16 | ...\OnlineBankingAccountTransactionsBL.cs |
+| StRS-4 | SyRS-17 | SwRS-17 | ...\SepaFileGeneratorV2.cs |
+| StRS-5 | SyRS-18 | SwRS-14 | src\backend\Centron.BL\Sales\CashBooks\CashBookBL.cs |
+| StRS-5 | SyRS-19 | SwRS-15 | ...\BookKeepingExportDatevAscii.cs |
+| StRS-7 | SyRS-20 | SwRS-19 | ...\ReceiptArticleBookingBL.cs |
+| StRS-7 | SyRS-21 | — | ...\InventoryBL.cs:867 + SecondStockArticleBL.cs:101 |
+| StRS-6, StRS-7 | SyRS-22 | — | ...\OrderSuggestionListBL.cs |
+| StRS-7 | SyRS-23 | SwRS-20 | src\backend\Centron.Interfaces\Warehousing\BarcodeState.cs |
+| StRS-7 | SyRS-24 | SwRS-21 | src\backend\Centron.BL\CustomerArea\RmaBL.cs |
+| StRS-8 | SyRS-25 | SwRS-22 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs:418-466 |
+| StRS-8 | SyRS-25 | SwRS-28 | ...\TicketProcessExecutor.cs:25-28 + MailScannerBL.cs |
+| StRS-8 | SyRS-25 | SwRS-29 | ...\SelfCareWebserviceBL.cs:1863-1920 |
+| StRS-9 | SyRS-26 | SwRS-23 | ...\HelpdeskTimeRecordingBL.cs:172-643 |
+| StRS-9 | SyRS-26 | SwRS-24 | ...\HelpdeskTimerSignatureBL.cs:132-199 |
+| StRS-9 | SyRS-26 | SwRS-25 | ...\ReceiptItemTimerBL.cs:175-390 |
+| StRS-8 | SyRS-27 | SwRS-26 | ...\EscalationBL.cs:223-298 |
+| StRS-9 | SyRS-28 | SwRS-27 | src\backend\Centron.BL\MyDay\MyDayBL.cs:1249-1277 |
+| StRS-10 | SyRS-29 | SwRS-52 [HYPOTHESE] | src\backend\Centron.BL\ToDoArea\ToDoBL.cs:91 |
+| StRS-10 | SyRS-30 | — | ...\ReceiptContractHelperBL.cs:135-811 |
+| StRS-6, StRS-16 | SyRS-31 | SwRS-34 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs:56 + SupplierEdiBL.cs |
+| StRS-2, StRS-6 | SyRS-32 | SwRS-35 | src\backend\Centron.BL\EDI\Zugferd\ZUGFeRD_BL.cs:38,141 |
+| StRS-6, StRS-16 | SyRS-33 | SwRS-33 | ...\ArticleImportBL.cs:82-882 |
+| StRS-6, StRS-16 | SyRS-33 | SwRS-51 | src\backend\Centron.Entities\Entities\Sales\CustomerAssets\Projects\ProjectPriceImport.cs |
+| StRS-6, StRS-16 | SyRS-34 | SwRS-36 | src\apis\Centron.APIs.ITscopeDataAccess\ITscopeApi.cs (u. a. EgisApi.cs) |
+| StRS-6, StRS-16 | SyRS-34 | SwRS-50 | ...\TelekomDiveProfile.cs + TelekomDiveBL.cs |
+| StRS-2, StRS-16 | SyRS-35 | SwRS-37 | src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs |
+| StRS-11 | SyRS-36 | SwRS-38 | ...\ReceiptCartReleaseSystemBL.cs:167-208 |
+| StRS-1 | SyRS-37 | SwRS-40 | ...\DocumentBL.cs:587,843 + IndexSearchBL.cs |
+| StRS-8, StRS-11 | SyRS-38 | SwRS-41 | ...\NexusNotificationsBL.cs:178 + ChatBL.cs |
+| StRS-8, StRS-11 | SyRS-38 | SwRS-58 | src\nexus\CentronNexus.OutlookAddIn\OfficeDialog\AddEmailToFolderDialog.razor |
+| StRS-16 | SyRS-39 | — | src\webservice\Centron.Host\AspNetCore\HostedServices (37 Dienste) |
+| StRS-16 | SyRS-40 | SwRS-43 | src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs |
+| StRS-16 | SyRS-41 | SwRS-45 | ...\ScriptMethodPool.cs + ScriptMethodsCollection.cs |
+| StRS-12 | SyRS-42 | SwRS-46 | ...\CentronDataSecurityViewModel.cs |
+| StRS-16 | SyRS-43 | SwRS-44 | ...\Prompts\AiActionId.cs + Chat\*.cs |
+| StRS-12, StRS-16 | SyRS-44 | SwRS-53 | ...\AppSettingsBL.cs:20-67 |
+| StRS-12, StRS-16 | SyRS-44 | SwRS-54 | src\backend\Centron.Interfaces\Administration\Logins\LicenseGuids.cs |
+| StRS-8 | SyRS-45 | SwRS-47 | src\backend\Centron.BL\MyCentron\Schedulings\SchedulingBL.cs |
+| StRS-14 | SyRS-46 | SwRS-30 | ...\ProductionOrderWebServiceBL.cs + ProductionOrderItemState.cs |
+| StRS-1, StRS-15 | SyRS-47 | SwRS-48 | ...\CrmProjectBL.cs + AccountActivityKind.cs |
+| StRS-11 | SyRS-48 | — | ...\CampaignPhaseActionBL.cs + SurveyProcessBL.cs |
+| StRS-14 | SyRS-49 | SwRS-31 | ...\ProductFamilyBL.cs |
+| StRS-13 | SyRS-50 | — | SQLScriptCollection1.xml + RiverConnectionBL.cs |
+| StRS-13, StRS-15 | SyRS-51 | SwRS-42 | ...\CacheSalesStatisticsBL.cs + DashboardContainerBL.cs |
+| StRS-2 | SyRS-52 [HYPOTHESE] | — | src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs:22-77 |
+| StRS-1 | SyRS-53 | SwRS-8 | src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs:573-576 |
+| StRS-1 | SyRS-53 | SwRS-32 | ...\EnvironmentalProtectionMaps.cs (Table "Umweltschutz") |
+| StRS-1 | SyRS-53 | SwRS-49 | ...\AccountRepository.cs:573-576,1214,1369 |
+
+**Rückwärts-/Vorwärtsnavigation:** SwRS → SyRS über Spalte 2; SyRS → StRS über Spalte 1; Belegspalte verlinkt auf die durchsetzende Codestelle (vgl. `Fakt`-Felder der Anforderungsblöcke).
+
+**Hypothesen-Markierungen in der Tabelle:** SwRS-7 (Legacy-Passwortspeicher), SwRS-52 (Wartungs-/QM-Legacy), SyRS-52 (EbInterface-Einbindung) - Details in `Hypothesen.md`.
@@ -0,0 +1,125 @@
+# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/builtin/max
+
+> **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-03T09:29:55.0464292+02:00
+- **Endzeit:** 2026-09-03T10:35:27.1935815+02:00
+- **Dauer gesamt:** 01:05:28 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
+- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
+- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (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):** `z-ai/glm-5.3-flash`
+- **Modell (tatsaechlich):** `z-ai/glm-5.3-flash`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 16/z-ai/glm-5.3-flash/builtin/max/`
+- **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` = 10, `completed` = 10, `failed` = 0
+- **Rollen:** {"explore": 10}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 1.439.283 |
+| Output-Tokens | 90.379 |
+| Reasoning-Tokens | 32.898 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 24 |
+
+**Tokens gesamt: 2.385.024.** 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 | 12,6 % |
+| SyRS | 53 | 41,7 % |
+| SwRS | 58 | 45,7 % |
+| **Gesamt** | **127** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 72 | 56,7 % |
+| Schnittstelle | 25 | 19,7 % |
+| Sicherheit | 17 | 13,4 % |
+| Daten | 10 | 7,9 % |
+| nicht-funktional | 3 | 2,4 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 311 |
+| davon `PRIMÄR` | 216 (69,5 %) |
+| davon `SEKUNDÄR` | 92 (29,6 %) |
+| davon `KONTEXT` | 3 (1,0 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 127 (100,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 126 | 99,2 % |
+| veraltet | 1 | 0,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 124 | 97,6 % |
+| als `HYPOTHESE` gekennzeichnet | 3 | 2,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 42 | 33,1 % |
+| mit ISO-25010-Qualitätsmerkmal | 3 | 2,4 % |
+
+### 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** (33 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 127 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 127 von 127 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f99d33280ffeMmaSnV8T9WM2tT`
+- **Werkzeugaufrufe:** 44 – {"bash": 17, "glob": 1, "read": 2, "task": 10, "write": 7, "edit": 7}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 10
+- **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-03T07:29:56.953120+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\Ergebnisse)
+[2026-09-03T07:29:57.100595+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=builtin; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T08:35:25.773856+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T08:35:27.146729+00:00] OpenCode export: Exporting session: ses_f99d33280ffeMmaSnV8T9WM2tT
+[2026-09-03T08:35:27.176641+00:00] Ende: Exitcode=0; Status=success; Turns=24; Tokens=2385024; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\RawResult.json
@@ -0,0 +1 @@
+
@@ -0,0 +1,63 @@
+## 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 | 12,6 % |
+| SyRS | 53 | 41,7 % |
+| SwRS | 58 | 45,7 % |
+| **Gesamt** | **127** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 72 | 56,7 % |
+| Schnittstelle | 25 | 19,7 % |
+| Sicherheit | 17 | 13,4 % |
+| Daten | 10 | 7,9 % |
+| nicht-funktional | 3 | 2,4 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 311 |
+| davon `PRIMÄR` | 216 (69,5 %) |
+| davon `SEKUNDÄR` | 92 (29,6 %) |
+| davon `KONTEXT` | 3 (1,0 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 127 (100,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 126 | 99,2 % |
+| veraltet | 1 | 0,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 124 | 97,6 % |
+| als `HYPOTHESE` gekennzeichnet | 3 | 2,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 42 | 33,1 % |
+| mit ISO-25010-Qualitätsmerkmal | 3 | 2,4 % |
+
+### 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** (33 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 127 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 127 von 127 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\z-ai\glm-5.3-flash\builtin\max\03_Lauf_2026-09-03_092954_v13.0.0-1eaf\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-09-03T10:35:27.1935815+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/z-ai/glm-5.3-flash",
+  "permission": {
+    "*": "deny",
+    "read": "allow",
+    "glob": "allow",
+    "grep": "allow",
+    "list": "allow",
+    "edit": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "external_directory": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_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/z-ai/glm-5.3-flash",
+      "mode": "primary"
+    },
+    "general": {
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "mode": "subagent"
+    },
+    "explore": {
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "mode": "subagent"
+    }
+  },
+  "default_agent": "build"
+}
@@ -0,0 +1 @@
+2026-09-03T09:29:55.0464292+02:00