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>

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Protokoll.md

@@ -10,7 +10,7 @@
 - **Endzeit:** 2026-09-02T14:03:38.1060735+02:00
 - **Dauer gesamt:** 00:52:32 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
 - **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
-- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
 - **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
 
 ## Werkzeugkonfiguration

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-03T13:14:29.923672+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\Ergebnisse)
+[2026-09-03T13:14:30.047622+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T14:35:23.066636+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T14:35:24.712030+00:00] OpenCode export: Exporting session: ses_f9897e0b9ffeUwpfU46o6PGXwo
+[2026-09-03T14:35:24.785556+00:00] Ende: Exitcode=0; Status=success; Turns=118; Tokens=14449968; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Ergebnisse/Analysebericht.md

@@ -0,0 +1,172 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Codebasis Version 13.0.0), Stand 2026-09-03.
+Ergebnis der statischen Analyse: 163 Anforderungen (31 StRS, 48 SyRS, 84 SwRS) mit 443 Belegen.
+
+## 1. Vorgehen und Methodik
+
+1. **Schritt 0 – Strukturinventur:** Auswertung von `docs/`, Projektdateien, `SSMS_DB_SCHEMA.sql` und der Verzeichnisstruktur; Ableitung eines Modulinventars (88 Fachordner in `src/backend/Centron.BL` plus Nexus-, Webservice-, API-, Client-, Gateway-, Test- und Deployment-Bausteine).
+2. **Schritt 1 – Belegsammlung:** Gezielte Lektüre der tragenden Klassen (z. B. `ReceiptBL`, `NumberGroupBL`, `AppRightsBL`, `Authenticator`, `TwoFactorAuthBL`, `LicenseManager`, `DunningRunBL`, `DunningRunBL`, `InvoiceZugferdBL`, `ScriptEngineBL`, `AESCryptoLogic`, `DataQualityService`), der Konfiguration (`WebServiceConfig.xml`-Serializer, `nlog.config`, `Directory.Build.props`, `azure/build-pipeline.yml`) und der Referenzdokumentation.
+3. **Schritt 2 – Anforderungsformulierung:** ISO/IEC/IEEE 29148-konforme Formulierungen je Ebene mit `Fakt` (IST) und `Aussage` (SOLL), `Ergebnis` als Prüfkriterium, `Vorbedingung`, `Akteur`, `Qualitätsmerkmal` (ISO 25010 bei nicht-funktionalen Anforderungen), `Belege` mit Begründung, `Übernahmewürdigkeit`, `Konsolidierung` und `Tracelinks`.
+4. **Schritt 3 – Rückverfolgbarkeit:** Verankerung jeder SwRS an mindestens einer SyRS und jeder SyRS an mindestens einer StRS; Konsolidierung in `Traceability.md`.
+5. **Schritt 4 – Konsistenzprüfung:** Skriptgestützte Prüfung (Abschnitt 5) und Nacharbeit.
+
+**Belegklassen:** `PRIMÄR` = direkt gelesener Quelltext/Konfiguration/Schema; `SEKUNDÄR` = Projektdokumentation (`docs/`, `CentronRights.md`); `KONTEXT` = Namensgebung, Konventionen, Kommentartexte.
+
+**Verfahrensgrundsätze:** keine Änderung an der Codebasis; keine erdachten Anforderungen; unsichere Sachverhalte wurden als `HYPOTHESE` gekennzeichnet statt als Fakt geschrieben.
+
+## 2. Ergebnisüberblick
+
+| Kennzahl | Wert |
+| --- | --- |
+| Anforderungen gesamt | 163 |
+| StRS / SyRS / SwRS | 31 / 48 / 84 |
+| Belege gesamt | 443 (324 PRIMÄR, 95 SEKUNDÄR, 24 KONTEXT) |
+| Anforderungen mit Status `belegt` | 148 |
+| Anforderungen mit Status `HYPOTHESE` | 15 |
+| Übernahmewürdigkeit `übernehmen` | 128 |
+| Übernahmewürdigkeit `Workaround` | 20 |
+| Übernahmewürdigkeit `veraltet` | 8 |
+| Übernahmewürdigkeit `Sonderfall` | 7 |
+| Konsolidierungskandidaten markiert | 133 (30 Anforderungen explizit „keine Konsolidierung") |
+| Traceability-Zeilen | 132 (48 StRS↔SyRS, 84 SyRS↔SwRS) |
+
+Typverteilung: `funktional` 44, `Daten` 41, `nicht-funktional` 35, `Sicherheit` 22, `Schnittstelle` 21.
+
+## 3. Modulinventar und Abdeckung
+
+Basis des Inventars ist die Backend-Domänenschicht `src/backend/Centron.BL` (88 Fachordner ohne `bin`, `obj`, `Properties`, `Resources`). Eine Anforderung zählt für ein Modul, wenn ihr Beleg auf den Modulpfad zeigt (auch über `Centron.Entities`/`Centron.DAO`-Pfade desselben Themenbereichs).
+
+Bewertungsschema: `tief` = ab 5 Anforderungen und mindestens zwei PRIMÄR-Belegen im Modulpfad; `mittel` = 2–4 Anforderungen; `flach` = 1 Anforderung; `nicht analysiert` = kein Beleg.
+
+**Verteilung:** tief 8 · mittel 21 · flach 25 · nicht analysiert 34 (von 88 Modulen).
+
+| Modul | Tiefe | Anforderungen | Zugeordnete Anforderungen |
+| --- | --- | --- | --- |
+| Sales (Belege, Helpdesk, WebCart, Mahnwesen, Zeiten) | tief | 61 | StRS-2…StRS-13, StRS-18, StRS-20…StRS-22, StRS-26, SyRS-3…SyRS-8, SyRS-10, SyRS-11, SyRS-13, SyRS-14, SyRS-18, SyRS-19, SyRS-22, SyRS-23, SyRS-25, SyRS-26, SyRS-28, SyRS-46, SwRS-4…SwRS-9, SwRS-15, SwRS-21…SwRS-27, SwRS-29…SwRS-33, SwRS-39…SwRS-41, SwRS-58…SwRS-62, SwRS-66 |
+| Administration (Rechte, Login, Nummernkreise, Lizenzen, Customizing) | tief | 35 | StRS-13, StRS-23…StRS-25, StRS-27, StRS-28, SyRS-4, SyRS-11, SyRS-12, SyRS-24, SyRS-27, SyRS-30, SyRS-31, SyRS-36…SyRS-38, SyRS-44, SyRS-45, SwRS-3, SwRS-9, SwRS-16, SwRS-24, SwRS-38, SwRS-40, SwRS-45, SwRS-48…SwRS-52, SwRS-57, SwRS-61, SwRS-65, SwRS-69, SwRS-84 |
+| Warehousing (Artikel, Bestand, RMA, Einkauf) | tief | 13 | StRS-16, StRS-17, StRS-19, StRS-30, SyRS-17, SyRS-18, SyRS-20, SwRS-14…SwRS-19 |
+| Accounts (Adressstamm, Suche, Kundenklassifikation) | tief | 10 | StRS-1, StRS-4, StRS-24, SyRS-2, SyRS-25, SwRS-10…SwRS-13, SwRS-59 |
+| DataExchange (Buchhaltungsexport, E-Rechnung) | tief | 9 | StRS-15, StRS-21, SyRS-2, SyRS-16, SyRS-22, SwRS-42, SwRS-43, SwRS-62, SwRS-71 |
+| WebServices (Portal-APIs, Verträge, Versand) | tief | 8 | StRS-13, StRS-18, StRS-20, SyRS-8, SyRS-14, SyRS-19, SyRS-21, SwRS-66 |
+| EDI (Distributorenaustausch) | tief | 6 | StRS-14, StRS-15, SyRS-15, SyRS-16, SwRS-43, SwRS-71 |
+| Security (Signatur, Entwicklerabschirmung) | tief | 5 | StRS-13, StRS-25, SyRS-14, SyRS-43, SwRS-51 |
+| CentronNexus (Blazor-Portal, Portale, Authorization) | mittel | 16 | StRS-11, StRS-13, StRS-29, SyRS-9, SyRS-12…SyRS-14, SyRS-24, SyRS-32, SyRS-35, SyRS-38, SyRS-40, SyRS-46, SwRS-34, SwRS-67, SwRS-68 |
+| Modules (Modul-/Featuresteuerung) | mittel | 12 | StRS-25, StRS-31, SyRS-2, SyRS-41, SwRS-54, SwRS-62…SwRS-65, SwRS-74, SwRS-82, SwRS-84 |
+| Services (Doppelschicht BL/WS, Hostdienste) | mittel | 7 | SyRS-2, SyRS-27, SyRS-35, SyRS-40, SwRS-2, SwRS-14, SwRS-64 |
+| CustomerArea (RMA, ServiceBoard) | mittel | 4 | StRS-11, StRS-19, SyRS-20, SwRS-58 |
+| Devices (Kundenanlagen, AccountDevice) | mittel | 4 | StRS-8, SyRS-9, SwRS-17, SwRS-34 |
+| Finances (Zahlungen, OnlineBanking) | mittel | 3 | StRS-22, SyRS-23, SwRS-41 |
+| Logistics (Versand, Retourenlogistik) | mittel | 3 | StRS-19, SyRS-17, SyRS-20 |
+| Statistics (Auswertungen, Filialfilter) | mittel | 3 | StRS-27, SyRS-25, SwRS-36 |
+| ChangeTracking (Protokollierung) | mittel | 2 | StRS-26, SyRS-28 |
+| IndexSearch (Volltextsuche) | mittel | 2 | SyRS-1, SwRS-1 |
+| Mail (Mailversand aus Belegen) | mittel | 2 | StRS-18, SwRS-57 |
+| MyDay / MyCentron (Arbeitsplatz, Fernwartung) | mittel | 4 | StRS-31, SwRS-74 |
+| NexusNotifications (Benachrichtigungen) | mittel | 2 | SyRS-35, SwRS-20 |
+| PasswordManager (Secret-Verwaltung) | mittel | 2 | SwRS-45, SwRS-46 |
+| Production (Fertigung) | mittel | 2 | StRS-20, SyRS-21 |
+| Purchasing (Einkauf) | mittel | 2 | StRS-17, SwRS-18 |
+| TaskManager (Reportversand, Aufgaben) | mittel | 2 | StRS-27, SyRS-29 |
+| Telemetry (Betriebstelemetrie) | mittel | 2 | StRS-29, SwRS-73 |
+| ToDoArea (Aufgaben, Datenqualität) | mittel | 2 | SwRS-26, SwRS-53 |
+| TwoFactorAuthenticator (2FA) | mittel | 2 | SyRS-45, SwRS-47 |
+| ArtificialIntelligence, Calendar, CentronIcons, CheckListArea, Chats, CountryArea, Customizations, DocuBoard, Helpers, Integrations, MailScanner, MassUpdate, ObjectExternalReferences, PasswordManagementArea, Processes, ReportEngine, Storage, Tags, Tapi, TextModuleArea, TicketProjects, TradePool, VoucherManagement, WebLinks, WebVersion | flach | je 1 | SwRS-21, SwRS-24…SwRS-28, SwRS-35, SwRS-37, SwRS-46, SwRS-64, SwRS-75…SwRS-81, SwRS-83, SwRS-84, SyRS-13, SyRS-31 |
+
+**Nicht oder nicht eigenständig analysiert (34 Backend-Ordner):** `Accounting`, `AppointmentRequests`, `BusinessPartner`, `Buying`, `Core`, `CPra`, `DocumentationArea`, `EmployeeArea`, `Exceptions`, `ExpectedEvents`, `ExternalHelpdesk`, `ExternalToolsBL`, `Gateway`, `GUI`, `ItPlanner`, `Mailings`, `Mobile`, `NexusTicketViews`, `Notifications`, `Outlook`, `ProductMatrix`, `Projects`, `Reporting`, `RiverDivo`, `SelfCare`, `SocialMedia`, `Start`, `SystemArea`, `Time`, `Tools`, `Transactions`, `Urls`, `VideoPortal`, `WebSuite`.
+
+**Begründung:** Diese Ordner enthalten überwiegend Basisschichten (`Core`, `Helpers`-Anteile, `Exceptions`, `Transactions`, `SystemArea`, `GUI`, `Start`), ausgelagerte Produktlinien (`CPra`, `RiverDivo`, `ItPlanner`, `VideoPortal`, `SocialMedia`, `WebSuite`) oder Funktionen, deren fachliche Aussagen bereits über benachbarte Module abgedeckt sind (`Time` → `SyRS-10`, `Notifications` → `SyRS-35`, `Reporting` → `SyRS-29`, `Accounting` → `SyRS-22`). Eine eigene Anforderung wäre in diesen Fällen eine Dublette.
+
+**Weitere Systemebenen (nicht über die BL-Ordnerzählung erfasst, aber mit Anforderungen belegt):** `Centron.WPF.UI` (Client-Shell, Modulregistrierung, Fehlerbehandlung), `CentronNexus.Host`/`CentronNexus.OutlookAddIn`, `Centron.Host`/`Centron.Host.Console`/`Centron.Host.WindowsService`/`Centron.WebServices.Core`/`Centron.Controllers`, `Centron.Gateway`, `Centron.Common`, `Centron.DAO`, `Centron.Entities`, `Centron.Interfaces`, `Centron.Controls`, `tests/` (inkl. Playwright-E2E), `azure/build-pipeline.yml`, `deployment/` (WiX-MSI, `docker/compose`), `src/apis/` (Gls, Shipcloud, EbInterface, docuFORM).
+
+**Nicht analysierte Fremdsysteme:** `Centron.APIs.CopDataAccess`, `Centron.APIs.EgisDataAccess`, `Centron.APIs.IcecatDataAccess`, `Centron.APIs.ITscopeDataAccess`, `Centron.APIs.FinAPI` — hier wurden nur Schnittstellenverträge, keine Fachregeln abgeleitet; sie werden in `SwRS-69` (Konnektorenlandschaft) zusammengefasst.
+
+**Abdeckungsquote:** 54 von 88 Backend-Modulen (61,4 %) mindestens flach erreicht; 34 Module (38,6 %) ohne eigenständige Anforderung. Diese Quote liegt über der Warnschwelle von 10 % und ist als bewusste Schwerpunktbildung zu lesen: Die Analyse folgte den belegbaren Kernprozessen (Belegwesen, Service/Helpdesk, Portal, Warenwirtschaft, Sicherheit, Betrieb); die Restmenge besteht zu wesentlichen Teilen aus Infrastruktur- und Nischenmodulen.
+
+## 4. Risikorelevante Anforderungen
+
+Alle 51 Anforderungen mit Sicherheits-, Abrechnungs- oder Berechtigungsbezug sind mit mindestens einem `PRIMÄR`-Beleg unterlegt (Schwelle erfüllt).
+
+- **Typ `Sicherheit` (22):** StRS-4, StRS-23, SyRS-6, SyRS-12, SyRS-21, SyRS-22, SyRS-24, SyRS-25, SyRS-27, SyRS-36, SyRS-43, SyRS-44, SyRS-45, SwRS-6, SwRS-40, SwRS-45, SwRS-46, SwRS-47, SwRS-48, SwRS-50, SwRS-51, SwRS-58
+- **Abrechnung/Preis/Zahlung nach Titel (29):** StRS-3, StRS-5, StRS-7, StRS-13, StRS-22, StRS-25, SyRS-5, SyRS-7, SyRS-14, SyRS-18, SyRS-20, SyRS-23, SyRS-30, SwRS-7, SwRS-8, SwRS-29, SwRS-32, SwRS-33, SwRS-39, SwRS-41, SwRS-42, SwRS-49, SwRS-54, SwRS-59, SwRS-63, SwRS-68, SwRS-77, SwRS-80, SwRS-83
+
+**Herausgehobene Befunde (jeweils PRIMÄR belegt):**
+
+1. Passworthistorie: ungesalzenes SHA1 für Web-Accounts (`SHA1Decoder.GetDecodedSHA1String`),TODO-Kommentar „password should be salted" (`BasicAuthenticator`). → `SwRS-48`, `SwRS-57`
+2. Secret-Schutz: AES-Key aus hartkodiertem `SECURITY_KEY = @"lugE!35Djn"` in `AESCryptoLogic`. → `SwRS-45`, `SyRS-37`
+3. Nummernkreise: Reservationsmechanik per Optimistic Locking, aber kein Unique-Index in `SSMS_DB_SCHEMA.sql`; Lücken-/Duplikatrisiko. → `SwRS-3`, `SwRS-72`
+4. Doppelte Gerätehaltung: `MasterDataList`/`GeraeteKopf` (Legacy) und `AccountDevice` (Nexus) parallel. → `SyRS-9`, `SwRS-33`, `SwRS-34`
+5. Doppelte Adresshaltung: `Accounts` (modern) und `Kunden` (Legacy) mit Synchronisationslayer beim Speichern. → `SyRS-42`, `SwRS-10`, `SwRS-31`
+6. Autorisierung über drei Schichten mit unterschiedlicher Identitätsbasis. → `SyRS-24`, `SwRS-49`, `SwRS-50`
+7. Customizing über 764 Einzeldateien `ScriptMethodNNNNN.cs` plus `ScriptMethodsCollection.cs` ohne Migrationsframework. → `SwRS-52`, `SyRS-30`
+8. Dreifache Protokollierung: CSV-Dateilogging, `InMemoryLogging`, DB-Telemetrie unverbunden. → `SyRS-32`, `SyRS-28`, `SwRS-73`
+9. `Debugger.IsAttached` als Feature-Steuerung im Produktivpfad. → `SyRS-41`, `SwRS-54`
+10. Produktionsdatenbank nur als Schema-Dump ohne Migrationswerkzeug. → `SwRS-72`
+11. Keine Backup-/Recovery-Codes im 2FA-Pfad. → `SwRS-47`
+12. Zahlungen ohne automatische Verzinsung/Verzugszinslogik im Bestand. → `SwRS-41`
+
+## 5. Konsistenzprüfung (Skriptergebnisse)
+
+Prüfumfang: 163 Anforderungsblöcke in `StRS.md`, `SyRS.md`, `SwRS.md`; Auswertung über reguläre Auswertung der Felder `ID`, `Typ`, `Qualitätsmerkmal`, `Belege`, `Übernahmewürdigkeit`, `Konsolidierung`, `Status`, `Tracelinks`.
+
+| Prüfung | Ergebnis |
+| --- | --- |
+| Doppelte IDs | 0 |
+| Anforderungen ohne `Belege`-Block | 0 |
+| Anforderungen ohne `Übernahmewürdigkeit` | 0 |
+| Anforderungen ohne `Status` | 0 |
+| Anforderungen ohne Begründung je Beleg | 0 |
+| Tote Tracelinks (nicht existierende Ziel-IDs) | 0 |
+| SyRS ohne StRS-Anker | 0 (nach Korrektur) |
+| SwRS ohne SyRS-Anker | 0 (nach Korrektur von 25 Einträgen: SwRS-13…SwRS-17, SwRS-19, SwRS-25, SwRS-27, SwRS-29, SwRS-35, SwRS-37, SwRS-40, SwRS-59, SwRS-62, SwRS-64, SwRS-65, SwRS-68, SwRS-69, SwRS-74…SwRS-81) |
+| Nicht-funktionale Anforderungen ohne ISO-25010-Merkmal | 0 (SwRS-84 nachgezogen: `Wartbarkeit`) |
+| Risikorelevante Anforderungen ohne PRIMÄR-Beleg | 0 |
+| `Qualitätsmerkmal` bei `Typ: Daten`/`funktional` | bereinigt (SyRS-9 → `nicht-funktional`, SyRS-15 Feld geleert) |
+| Sprachliche Defekte | behoben (5 CJK-Einzelzeichen und 4 abgeschnittene Token in StRS-13, SyRS-37, SwRS-8, SwRS-20, SwRS-25, SwRS-28, SwRS-36, SwRS-49; Vollscan ohne Restbefund) |
+
+**Konsolidierungskandidaten (133 Markierungen).** Wiederkehrende Muster mit dem höchsten Zusammenführungsgewinn:
+
+- Zwei Identitäts-/AutorisierungsWelten (`AppUser`+`Sichmemb`/`Sichtrus` vs. `WebAccounts`) → SyRS-12, SyRS-24, SwRS-48, SwRS-49, SwRS-57.
+- Drei Protokollierungs-/Historisierungsschichten (`*KopfVersions`, `ChangeLog`, `AnlageLog`, CSV-/InMemory-/DB-Logging) → StRS-26, StRS-29, SyRS-26, SyRS-28, SyRS-32, SwRS-52, SwRS-73.
+- Zwei Gerätehaltungen und zwei Adresshaltungen → StRS-7, StRS-8, SyRS-9, SyRS-42, SwRS-10, SwRS-17, SwRS-31, SwRS-33…SwRS-35.
+- Parallele Implementierungen derselben Fachfunktion (Preisfindung BL vs. `ReceiptPriceHelper`; ZUGFeRD vs. EB-Interface; zwei Versandprovider; neun Buchhaltungsformate; neun Adapterprojekte) → SyRS-5, SyRS-16, SyRS-19, SyRS-22, SwRS-8, SwRS-42…SwRS-44, SwRS-69, SwRS-75.
+- Drei Authentifizierungs-/Vier API-Absicherungsmechanismen ohne gemeinsame Policy-Schicht → SyRS-36, SwRS-48.
+- Zwei Suchpfade (`IndexSearch` vs. `ExtendedSearch`) und BL/WS-Doppelschicht → SyRS-1, SyRS-2, SwRS-1, SwRS-2, SwRS-66.
+
+## 6. Hypothesenabgleich
+
+`Hypothesen.md` listet genau die Anforderungen mit `Status: HYPOTHESE`. Soll/Ist-Abgleich:
+
+| Quelle | Anzahl |
+| --- | --- |
+| Inline-Markierungen `Status: HYPOTHESE` | 15 |
+| Einträge in `Hypothesen.md` | 15 |
+| Differenz | 0 (SyRS-46, SwRS-17, SwRS-21, SwRS-22, SwRS-32, SwRS-36, SwRS-39, SwRS-40, SwRS-44, SwRS-46, SwRS-47, SwRS-65, SwRS-73, SwRS-77, SwRS-84) |
+
+Keine StRS ist als Hypothese markiert; die Hypothesen betreffen ausschließlich Zweckklärung, Vollständigkeit oder negative Befehle („etwas fehlt"), nie den Bestand einer Kernfunktion.
+
+## 7. Grenzen der Analyse
+
+- Rein statisch: keine Laufzeitbeobachtung, keine Datenbank gegen echte Mandantendaten, kein Klicktest. Transaktionsgrenzen, Cache-Verhalten und Berechtigungsauswirkung unter Last bleiben Annahmen.
+- Die Produktionsdatenbank liegt nur als Schema-Dump (3,2 MB) vor; Datenvolumina, Indizes und Sichtdefinitionen können nur begrenzt beurteilt werden.
+- Kundenindividuelle Anpassungen liegen als 764 Skriptdateien vor; ihre Wirkung ist einzeln nicht geprüft, sondern nur als Muster erfasst.
+- Externe Verträge (DATEV, GLS, Shipcloud, ITscope, Egis, Icecat, COP, finAPI, Exchange/Graph) wurden aus dem Client-Code heraus gelesen; die Spezifikation beim Anbieter ist nicht geprüft.
+- Rechtskonformität (GoBD, E-Rechnungspflicht 2025/2028, DSGVO) ist fachlich eingeordnet, aber nicht juristisch bewertet.
+
+## 8. Bekannte Abweichungen im Arbeitsprozess
+
+- **Zeitweise zusätzliche Datei `SwRS.md.tmp`.** Sie entstand als Zwischenablage beim Schreiben der SwRS-Kapitel in drei Teilen und wurde vor Abschluss entfernt. Das Ausgabeverzeichnis enthält exakt die sieben geforderten Ergebnisdateien.
+- **Nachträgliche Textkorrekturen.** Die Sprachprüfung fand nach dem Erstentwurf statt; korrigiert wurden fünf CJK-Einzelzeichen und vier abgeschnittene Token. Dadurch änderten sich keine Aussagen, nur Formulierungen.
+- **Nachträgliche Tracelink-Ergänzung.** Die 25 SyRS-Bezüge in `SwRS.md` wurden nach der ersten Konsistenzprüfung eingetragen; `Traceability.md` enthält den Endzustand.
+
+## 9. Selbstbewertung
+
+**Abdeckung.** Die kerngeschäftstragenden Prozesse sind dicht belegt (61 Anforderungen allein aus `Sales`); die Schwäche liegt in der Breite: 38,6 % der Backend-Ordner haben keine eigene Anforderung. Für eine Migrationsentscheidung ist das vertretbar, für eine vollständige Spezifikation wäre eine zweite Iteration über `Accounting`, `Buying`, `Projects`, `Time`, `Reporting`, `Mobile` und `WebSuite` nötig.
+
+**Belegqualität.** 73,1 % der Belege sind PRIMÄR; jede risikorelevante Anforderung hat Quelltextbezug. Die 24 KONTEXT-Belege betreffen überwiegend begriffliche Einordnung (Legacy-Namen, Konventionsfolgen) und sind als solche gekennzeichnet.
+
+**Ehrlichkeit der Aussagen.** 15 Anforderungen (9,2 %) sind als Hypothese markiert, zusätzlich sind 35 Anforderungen als `Workaround` oder `veraltet` bewertet. Damit ist der IST-Zustand nicht beschönigt; die Analyse benennt Scheinsicherheit (AES mit Quellcode-Schlüssel), Altlasten (Gleitkomma bei Beträgen, `SecondaryStock`) und Migrationsprothesen (Legacy-Synchronisationslayer) offen.
+
+**ISO-29148-Kriterien.** Erfüllt: Eindeutigkeit (ID-Schema), Vollständigkeit der Feldsätze, Konsistenz (Tracelink-Prüfung), Verfolgbarkeit (132 Zeilen), Prüfbarkeit (`Ergebnis` je Anforderung als Testformulierung). Nicht vollständig erfüllt: Uniformität der Granularität — die SwRS-Ebene ist im Belegbereich feiner gegliedert als im Portalbereich; und die Abdeckung ist, wie oben angegeben, nicht gleichmäßig.
+
+**Nächste sinnvolle Schritte (außerhalb dieses Auftrags):** Fachgespräche zu den 15 Hypothesen; Abbildung der 34 Restmodule; Ausmessen der 6 Top-Konsolidierungsfelder; Ergänzung von DB-seitigen Integritätsbedingungen vor einer Migration.

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Ergebnisse/Glossar.md

@@ -0,0 +1,87 @@
+# Glossar
+
+Fach- und Systembegriffe der c-entron-ERP-Codebasis. „Fundstelle" nennt die Belegart, aus der die Bedeutung abgeleitet wurde (PRIMÄR = Code/Schema, SEKUNDÄR = projektdokumentation, KONTEXT = Namensgebung/Konvention).
+
+## Mandant und Installation
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Mandant | Rechtlich selbständige Firmeneinheit (eigener Nummernkreis, eigene Steuerdaten) innerhalb einer Installation; keine mandantenfähige Datenbank, sondern installationsbezogene Trennung. | PRIMÄR `Company`/`Branch`-Entitäten, `AdditionalService`; SEKUNDÄR `docs/getting-started/general-structure.md` |
+| Filiale | Unterorganisation eines Mandanten mit eigener Datenabschottung über Rechte und Filialfilter. | PRIMÄR `AppRightsBL`, `AccountBL.Filialen` |
+| Installation | Auslieferung einer Datenbank samt Webservice/Nexus; Mandant und Filiale sind immer innerhalb genau einer Installation gültig. | PRIMÄR `WebServiceConfigSerializer`, `Product.wxs` |
+
+## Adress- und Partnerstamm
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Adresse / Account | Zentraler Partnerstamm (Kunde, Lieferant, Kontakt) in der Tabelle `Accounts`; Legacy-Spiegel in der Tabelle `Kunden`. | PRIMÄR `AccountMaps`, `SSMS_DB_SCHEMA.sql` |
+| Kundenanlage | beim Kunden installierte Geräte-/Anlagenkombination, Abrechnungsobjekt für Wartung und Zähler. | PRIMÄR `AccountDevice`, `AssetHeadDAO` |
+| Stammblatt / MasterDataList | Geräte-Detaildatensatz mit Zähler- und Vertragsbezug (Legacy-Haltung neben `AccountDevice`). | PRIMÄR `MasterDataListBL`, `GeraeteKopfMaps` |
+| Zähler | Verbrauchszähler (z. B. Druckerseiten) an einer Kundenanlage, Grundlage der Zählerabrechnung. | PRIMÄR `ContractKindBase`, `ContractSpecificLogic` |
+| Nummernkreis | Konfigurierte Nummernvergabe für Belege, Kunden, Artikel; Reservierung über Optimistic Locking. | PRIMÄR `NumberGroupBL` |
+| Web-Account | Zugang eines Kunden zum Portal (ServiceBoard/WebCart), getrennt von Mitarbeiterlogins. | PRIMÄR `WebAccountBL`, `WebAccountsRights` |
+| Sichmemb / Sichtrus | Datenbanktabellen für Rechtevergabe (Mitgliedschaft/Rollen) der Desktop-Anwendung. | PRIMÄR `AppRightsBL` |
+
+## Belegwesen
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Beleg | Verkaufsdokument (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift) mit Kopf, Positionen und Zustandsmaschine. | PRIMÄR `ReceiptState`, `ReceiptBL` |
+| Belegart | Dokumenttyp mit eigenem Nummernkreis und eigenen Rechten. | PRIMÄR `ReceiptBL`, `NumberGroupBL` |
+| Prüf­kette | Beim Speichern durchlaufene Prüfung (Stammdaten, Preis, Limit, Nummernkreis, Exportflags) in `ReceiptBL.SaveReceipt`. | PRIMÄR `ReceiptBL.cs` |
+| Storno | Stornobeleg als neue Belegversion, nicht als Löschung des Ursprungsbelegs. | PRIMÄR `ReceiptInvoiceBL` |
+| Kundenlimit | Kreditlimit eines Kunden, das beim Speichern von Belegen geprüft und überschreitbar bestätigt werden kann. | PRIMÄR `CheckIfCustomerLimitIsReached` |
+| Mahnwesen / Mahnstufe | Gestaffelte Zahlungserinnerung (drei Stufen) mit Mahnlauf-Massenprozess und Mahnsperre. | PRIMÄR `DunningRunBL`, `InvoiceDunningMaps` |
+| Vertrag / ClickContract | Wartungs- oder Servicevertrag mit Laufzeit, Kontingenten, Preisartikeln und Zählern. | PRIMÄR `MasterDataListBL`, `ContractKindBase` |
+| Zählerabrechnung | Abrechnung von Zählerständen im Rahmen von Verträgen. | PRIMÄR `AutomaticFacturaWebServiceBL` |
+
+## Preis, Zahlung, Buchhaltung
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Preisfindung | Kundenindividuelle Preisermittlung (Kundenpreise, Staffeln, Rabatte, Sonderpreise). | PRIMÄR `ReceiptPriceHelper`, `ReceiptItemPriceBL` |
+| Skonto / Skon­di | Abzug bei Zahlung innerhalb einer Frist, am Belegkopf geführt. | PRIMÄR `ReceiptBL` |
+| IncomingPayment / Zahlungseingang | Erfasster Geldeingang zur Belegabzahlung, auch aus OnlineBanking-Daten. | PRIMÄR `IncomingPaymentMaps` |
+| Gutschein / Voucher | Vorgelöster Wertgutschein, über Barcode im Beleg erkennbar. | PRIMÄR `VoucherManagementBL` |
+| Buchhaltungsexport | Übergabe von Belegen an DATEV oder andere Systeme, mit Exportflag als Doppelexport-Schutz. | PRIMÄR `BookKeepingExportBL`, `BookKeepingExportDatevAscii` |
+| E-Rechnung / ZUGFeRD / XRechnung | Strukturierte Ausgangsrechnung ( hybrides PDF+XML bzw. XML) mit Profilwahl. | PRIMÄR `InvoiceZugferdBL` |
+
+## Warenwirtschaft
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Artikel | Lager- oder Dienstleistungsartikel mit Flag-basierter Artikelart, Warengruppe und Materialgruppe. | PRIMÄR `Article.cs` |
+| Warengruppe / Materialgruppe | Zwei nebeneinander geführte Klassifikationssysteme für Artikel. | PRIMÄR `Article.cs` |
+| Sekundärbestand / SecondaryStock | Altbestand-Konzept für Nebenlager, neben der modernen Bestandsführung. | PRIMÄR `SecondaryStock.cs` |
+| Seriennummer | Einzelnachweis eines Geräts über den gesamten Belegzyklus. | PRIMÄR `SerialNumber.cs` |
+| Mindestbestand | Unterster Meldebestand als Auslöser des Bestellvorschlags. | PRIMÄR `StorageBL`, `ArticleImportBL` |
+| TradePool | Interne Handelsplattform zum Ausgleich von Artikelbeständen mit Dateiimport. | PRIMÄR `TradePoolBL` |
+| RMA | Warenrückführung (Retoure, Austausch, Reparatur) mit eigenem Statusmodell und Lagerisolation. | PRIMÄR `RmaBL` |
+
+## Helpdesk und Service
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Helpdesk / Ticket | Vorgang zur Kundenbetreuung mit Statusmodell, Pflichtfeldern und Eskalationsstufen. | PRIMÄR `HelpdeskBL`, `Escalations.cs` |
+| Ticketprojekt | Sammelobjekt für Tickets mit eigenem Nummernkreis und Abhängigkeiten. | PRIMÄR `TicketProjectBL` |
+| Eskalation | Automatische Hochstufung eines Tickets nach Arbeitszeit- und Wochenendlogik. | PRIMÄR `Escalations.cs` |
+| Checkliste | Pflichtprüfungspunkte zur Ticketabarbeitung mit Abschlusspflicht. | PRIMÄR `CentronChecklistBase` |
+| Servicezeit / HelpdeskTimer | Erfasste Arbeitszeit auf Ticket oder Anlage, mit Sperrmechanik bis zur Abrechnung. | PRIMÄR `HelpdeskTimerMaps` |
+| ServiceBoard / SelfCare | Kundenportal für Tickets, Anlagen und Bestellungen. | PRIMÄR `PortAuthorization`, `HelpdeskBL` |
+| WebCart | B2B-Shop-Modul mit Warenkorb auf Angebotsdatenhaltung und Freigabewesen. | PRIMÄR `ReceiptCartBL`, `ReceiptCartReleaseSystemBL` |
+| DocuBoard | Dokumenten- und Anlagenansicht mit Artikelzuordnung. | PRIMÄR `AssetManagementArticleAssignment` |
+
+## Technik und Betrieb
+
+| Begriff | Definition | Fundstelle |
+| --- | --- | --- |
+| Nexus | Blazor-Server-Frontend (`CentronNexus`) mit genau einem Backend-Anschluss. | PRIMÄR `CentronNexus.Host/Program.cs` |
+| Webservice | .NET-Host (`Centron.Host`) mit REST-API, SignalR-Hubs und HostedServices. | PRIMÄR `CentronHost.cs` |
+| FeatureFlag / ModuleFeatures | Funktionale Abschaltung von Funktionen über Kundencode/Flag. | PRIMÄR `ModuleFeatures.cs`, `ModuleRegistration.cs` |
+| ScriptMethodNNNNN | Versionierte Skriptdatei zur kundenindividuellen Datenbank-/Funktionsanpassung. | PRIMÄR `ScriptEngineBL`, `ScriptMethods/Scripts/` |
+| Modulcustomproperty | Konfigurierbare Kundenerweiterung ohne Codeänderung. | PRIMÄR `ModuleCustomProperty.cs` |
+| DataQualityService | Hintergrunddienst zur Selbstheilung definierter Datenqualitätsmängel. | PRIMÄR `DataQualityService.cs`, `docs/Background Service/DataQualityService.md` |
+| Belegversion / 1:1-Variantentabelle | Unveränderliche Historienkopie von Kopf-/Positionstabellen. | PRIMÄR `AssetHeadDAO`, `SaveReceiptRepository` |
+| Telemetrie | Aggregierte Betriebs- und Nutzungsdaten einer Installation. | PRIMÄR `CentronHost.cs` |
+| LicenseManager | Prüft Lizenzumfang beim Start und steuert die Modulverfügbarkeit. | PRIMÄR `LicenseManager`, `docs/reference/security/licensing-system.md` |
+| Entwicklerabschirmung | Mechanismus, der Produktivdatenverkehr aus Entwicklungsumgebungen ausschließt. | PRIMÄR `DeveloperSecurity.cs`, `docs/reference/security/developer-security.md` |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Ergebnisse/Hypothesen.md

@@ -0,0 +1,29 @@
+# Hypothesenkatalog
+
+Alle Anforderungen, deren `Status` in StRS/SyRS/SwRS auf `HYPOTHESE` steht. Eine Anforderung ist hier genau dann enthalten, wenn sie in den Spezifikationsdateien mit `Status: HYPOTHESE` gekennzeichnet ist (Abgleich siehe `Analysebericht.md`, Abschnitt „Konsistenzcheck").
+
+Grundmuster: Der Code ist vorhanden, aber Zweck, Vollständigkeit oder fachliche Bedeutung konnten aus dem Quelltext allein nicht eindeutig belegt werden (`SEKUNDÄR`/`KONTEXT` statt `PRIMÄR`, oder `PRIMÄR` ohne dokumentierte Fachregel).
+
+| ID | Ebene | Titel | Warum Hypothese | Zur Verifizierung nötig |
+| --- | --- | --- | --- | --- |
+| SyRS-46 | SyRS | Kennzahl- und Auswertungs-Caching für große Datenmengen | Caching-Schicht in `ReceiptCartBL`/Statistikpfaden ist technisch sichtbar, ein dokumentierter Leistungszweck (Kennzahlen für Portale) aber nicht. | Fachliche Rückfrage zum Zweck der Pufferung; Messung unter Produktivdatenvolumen. |
+| SwRS-17 | SwRS | Garantie- und Gewährleistungsableitung | Felder für Garantie/Gewährleistung existieren im Artikelstamm; eine Ableitungsregel (Beginn, Dauer, Vererbung auf Anlagen) ist im Code nicht als Regel erkennbar. | Prüfung, welche Anwendungsfelder die Werte setzen; Kundenrückfrage zur Garantieberechnung. |
+| SwRS-21 | SwRS | Ticket-Mailszenario und virtueller Mailassistent | `MailScannerBL` verarbeitet Postfächer; ob daraus Tickets erzeugt werden oder nur Anhänge abgelegt werden, hängt von Konfiguration/Szenario-Tabellen ab, die nicht im Code stehen. | Einsicht in eine produktive Mailscanner-Konfiguration bzw. Szenariozuordnung. |
+| SwRS-22 | SwRS | Ticketanlage aus Bestellung über Vorlagen mit Single-Standard-Regel | Beschreibung nur in `docs/features/` (KONTEXT); die „genau eine Standardvorlage"-Regel ist im Code nicht eindeutig als Constraint erkennbar. | Datenbanksicht auf Vorlagen-Tabelle (Unique-Index?) und Fachgespräch. |
+| SwRS-32 | SwRS | Zählerabrechnung mit Abgerechnet-Flag in derselben Transaktion | Zählerstände werden in Abrechnungsläufen markiert; die Transaktionsgrenze (gleiche Transaktion wie Rechnungsanlage?) ist aus der Methodenstruktur nur indirekt erschließbar. | Transaktionsanalyse des Abrechnungsaufrufs, idealerweise Testlauf gegen Testdatenbank. |
+| SwRS-36 | SwRS | Auftragsauswertung mit Puffer-Caches | Statistikpfad nutzt Cache-Strukturen; ob dies ein fachlich gefordertes Verhalten oder eine Implementierungsnebenwirkung ist, ist nicht belegt. | Rückfrage zur Fachfunktionalität „Auftragsauswertung" und zum erwarteten Aktualitätsgrad. |
+| SwRS-39 | SwRS | Mahnstufen-Datenhaltung über Datenbank-Sichten | Mahnstufen werden über Mappings auf Sichten abgebildet; die fachliche Semantik der Stufen (welche Sicht liefert welche Stufe) ist nirgends dokumentiert. | Analyse der Sichtdefinitionen im Datenbankschema bzw. Datenbankdump. |
+| SwRS-40 | SwRS | Anlagenentsperrung nach Mahnstufe | Konstanten für Mahnstufen und Anlagensperre existieren nebeneinander; ein Kausalzusammenhang (Sperre ab Stufe X, Entsperrung nach Ausgleich) ist nicht belegt. | Fachliche Bestätigung des Mahn-/Sperrprozesses; Suche nach Aufrufer der Entsperrung. |
+| SwRS-44 | SwRS | Österreichische E-Rechnung als eigener Pfad | EbInterface-Api deutet auf länderspezifischen Ausgang; ob es ein eigenständiger Pfad neben ZUGFeRD ist oder ein Alternativlieferant, bleibt offen. | Klärung mit Vertrieb/Fachabteilung, welche Länderwege produktiv genutzt werden. |
+| SwRS-46 | SwRS | Passwort-Tresor mit Zugriffsprotokoll | `PasswordManagementKeywordBL` verwaltet Zugangsdaten; der Zweck (interner Tresor vs. Keyword-Suche) und die Protokollierungstiefe sind nicht dokumentiert. | Prüfung der Aufrufer in UI/Nexus und der Logging-Aufrufe im Pfad. |
+| SwRS-47 | SwRS | Zwei-Faktor-Schlüsselverwaltung ohne Backup-Codes | 2FA-Schlüssel werden erzeugt und geprüft; das Fehlen von Backup-Codes ist ein negativer Befund aus der Suche, keine dokumentierte Entscheidung. | Gezielte Suche/Review nach Recovery-Code-Tabellen; Rückfrage an die Produktverantwortlichen. |
+| SwRS-65 | SwRS | KI-Assistent mit austauschbaren Anbietern | `ArtificialIntelligenceApiType` legt Anbieterumschaltung nahe; Umfang (welche Funktionen KI nutzen) und Produktfreigabe sind unklar. | Blick in Produktivkonfiguration und Freigabestatus des KI-Moduls. |
+| SwRS-73 | SwRS | Telemetrie-Pipeline von Aggregation bis Upload | Aggregations- und Upload-Klassen vorhanden, aber Ziel, Intervall und Datenschutzfreigabe des Uploads sind im Code nicht festgelegt. | Konfigurationsdatei des Hosts und Datenschutzunterlage/Fachfreigabe. |
+| SwRS-77 | SwRS | Gutschein-/Vouchersteuerung über Barcode-Filter | Gutscheine werden über einen Barcode-Filter erkannt; die wirtschaftliche Regel (Einlösung, Verfall, Verrechnung) ist nicht kodiert. | Fachgespräch zur Gutscheinbehandlung im Kassieren-/Zahlungsprozess. |
+| SwRS-84 | SwRS | Versionsauskunft der Serverkomponente | Versionsobjekt und -auskunft existieren; ob die Auskunft produktiv (Supportdiagnose) genutzt wird oder nur Debugzwecken dient, ist nicht belegt. | Prüfung der Endpunktnutzung im Supportwerkzeug. |
+
+## Zusammenfassung
+
+- 15 von 163 Anforderungen (9,2 %) sind als Hypothese gekennzeichnet: 1 SyRS, 14 SwRS, keine StRS.
+- Kein risikorelevantes Thema (Abrechnung, Rechte, Zahlung) beruht ausschließlich auf Hypothesen; die Hypothesen betreffen Zweckklärung, Vollständigkeit oder negative Befehle.
+- Die im Konsistenzcheck geforderte Deckungsgleichheit mit den Inline-Markierungen `[HYPOTHESE]` ist erfüllt.

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Ergebnisse/StRS.md

@@ -0,0 +1,695 @@
+# StRS – Stakeholder Requirements Specification
+
+Quelle: statische Analyse der Codebasis `c-entron ERP` (NEXOWARE Systems GmbH, `Directory.Build.props`, Version `2.0.2611-alpha` laut `version.json`).
+Beteiligte Stakeholder (aus Artefakten abgeleitet): Vertrieb/Sachbearbeiter, Service-Techniker/Helpdesk-Mitarbeiter, Disponent/Lagerist, Einkauf, Buchhaltung/Controlling, Auszubildende/Mitarbeiter (MyDay), IT-Administration (ConnectionManager, Rechteverwaltung), Endkunde des ERP-Kunden (Kundenportal, WebCart), Distribonent/Lieferant (EDI), Steuerberater (DATEV), Hersteller NEXOWARE (Lizenzgeber, Telemetrie).
+
+```
+ID:            StRS-1
+Titel:         Zentraler Adressstamm für Kunden, Lieferanten und Kontakte
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter Vertrieb, Einkauf, Administration
+Vorbedingung:  Benutzer ist angemeldet und besitzt Zugriffsrecht auf den Adressstamm
+Fakt:          Adressen werden in einer gemeinsamen Entität `Account` mit `AccountCustomer`- und `AccountSupplier`-Anteil geführt; der Systemtyp-Enum kennt `Customer, Supplier, Contact` plus sechs freie Kundentypen; Kundennummer und Lieferantennummer werden aus Nummernkreisen vergeben (`AccountBL`: `account.Number = this._numberGroupBL.GetNextNumber(NumberGroupEnum.Account, ...)`)
+Aussage:       Das System soll alle Geschäftspartner (Kunden, Lieferanten, Interessenten, Kontakte) in einem gemeinsamen Adressstamm mit typspezifischen Zusatzdaten und eigenen Nummernkreisen führen.
+Ergebnis:      Ein Partner ist genau einmal vorhanden, trägt seinen Typ und kann zugleich Kunde und Lieferant sein.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Accounts/AccountTypeKind.cs - Begründung: Enum `AccountTypeKind` mit Kommentar „The three types "Customer", "Supplier" and "Contact" got special functions" legt die tragende Typlogik fest.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Accounts/AccountTypeToAccount.cs - Begründung: Felder `CustomerData` und `SupplierData` belegen die Doppelfunktion eines Partners.
+  - [SEKUNDÄR] src/backend/Centron.DAO/Mappings/Accounts/AccountMaps.cs - Begründung: `Table("Accounts")` zeigt die moderne Datenhaltung.
+Prüfidee:      Neuen Partner als Kunde und Lieferant anlegen; beide Nummernkreise vergeben je eine eigene Nummer; Partner bleibt ein Datensatz.
+Tracelinks:    SyRS-1, SyRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernkonzept jedes ERP und im Zielsystem unverändert nötig.
+Status:        belegt
+```
+
+```
+ID:            StRS-2
+Titel:         Durchgängiger Verkaufsbelegprozess vom Angebot bis zur Rechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter Vertrieb
+Vorbedingung:  Kunde mit Adressstammdaten vorhanden
+Fakt:          Alle Belegarten erben von `ReceiptBase` (Angebote/Aufträge/Lieferscheine/Rechnungen/Gutscheine/Verträge/Abholscheine) und werden über `ReceiptBL.ForwardReceipt` ineinander weiterverarbeitet; je Belegart entscheidet `SpecificLogics.CanBeForwardedInto()` (Auftrag: `DeliveryListClass, InvoiceClass, ContractClass`)
+Aussage:       Das System soll einen Folgeprozess aus Angebot, Auftrag, Lieferschein, Abholschein, Rechnung und Gutschein mit erlaubten Weiterverarbeitungsregeln und Restmengenführung anbieten.
+Ergebnis:      Ein Auftrag kann in Lieferschein/Rechnung überführt werden; nicht erlaubte Ziele werden mit Meldung abgewiesen, bereits verarbeitete Mengen bleiben geschützt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs `ForwardReceipt`/`ValidateReceiptForwarding` - Begründung: „Diese(s/r) ... kann nicht in eine(n) ... weiterverarbeitet werden." erzwingt die Regeln.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs `CanBeForwardedInto` - Begründung: definiert die erlaubte Kette je Belegart.
+  - [KONTEXT]  docs/reference/receipts/receipts-backend-architecture.md - Begründung: beschreibt die gemeinsame Basisklasse und die Tabelle/View-Paare (*Kopf/*Pos).
+Prüfidee:      Auftrag mit Position Menge 10 teils in Lieferschein (4) überführen; Menge der Ursprungsposition ist danach nicht mehr änderbar.
+Tracelinks:    SyRS-3, SyRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - fachliches Rückgrat des Vertriebsprozesses.
+Status:        belegt
+```
+
+```
+ID:            StRS-3
+Titel:         Kundenindividuelle Preisfindung bei jedem Beleg
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter Vertrieb, Kundenbetreuer
+Vorbedingung:  Artikel mit Preislistenpreisen, ggf. Kunden-/Vertrags-Sonderpreise gepflegt
+Fakt:          `ReceiptItemPriceBL.GetBasePrice` arbeitet in der Reihenfolge Preisliste (VK1–VK4 je `priceList` 0–3) → Vertrags-Sonderpreis (`ContractSpecialPriceKind`, Kommentar „The contract values are inverted, 10 is 10 % surcharge") → Kunden-Sonderpreis (artikelgenau > Materialgruppe+sekundäre Gruppe > primäre Gruppe, mit `ValidFrom/ValidTo`) → Staffelpreis; Mindestpreise werden notfalls angehoben (`CheckArticleMinPrices`)
+Aussage:       Das System soll den Verkaufspreis einer Position automatisch aus einer priorisierten Preisfindungskette ermitteln und Mindestpreise durchsetzen.
+Ergebnis:      Die Position enthält den höchsten anwendbaren Preisvorteil; ein Preis unter dem Mindestpreis wird ohne Freigaberecht nicht gespeichert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Internal/ReceiptItemPriceBL.cs `GetBasePrice` (Zeilen 154–286), `GetSpecialPrice` (602–626) - Begründung: codedurchgesetzte Prioritätskette.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs `CheckArticleMinPrices` (9067–9075) - Begründung: `ChangeBasePrice(item, minPrice)` erzwungene Anhebung.
+  - [SEKUNDÄR] docs/reference/receipts/actionprice-system.md - Begründung: ordnet Aktionspreise als reine Anzeigequelle im Preisspiegel ein.
+Prüfidee:      Artikel mit Kunden-Sonderpreis und Pflege des Vertrags-Sonderpreises: Vertragspreis gewinnt; ohne beide greift VK der hinterlegten Preisliste.
+Tracelinks:    SyRS-5, StRS-2
+Konsolidierung: Kandidat: SyRS-5 und SwRS-9 (Preisarithmetik im Webservice-Layer `ReceiptPriceHelper` doppelt vorhanden)
+Übernahmewürdigkeit: übernehmen - Preislogik ist wettbewerbsrelevant und kundenspezifisch gewachsen.
+Status:        belegt
+```
+
+```
+ID:            StRS-4
+Titel:         Überwachung des Kundenkreditlimits beim Speichern von Belegen
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Sachbearbeiter Vertrieb, Kreditorenbuchhaltung
+Vorbedingung:  Kunde mit hinterlegtem Kreditlimit und Berechnungsart (Netto/Brutto)
+Fakt:          `ReceiptBL.SaveReceipt` ruft `CheckIfCustomerLimitIsReached` (Zeile 3727, Methode ab 8652) und setzt bei Überschreitung `ShowCustomerLimitExceededDialog` mit Meldung „Das Limit von {customer.CreditLimit:N2} ... wurde um {difference:N2} ... überschritten."; Fortsetzung nur mit `SaveAlthoughCustomerLimitExceeded`
+Aussage:       Das System soll den kumulierten Offenen-Posten-Saldo eines Kunden gegen sein Kreditlimit prüfen und den Bearbeiter bei Überschreitung aktiv warnen.
+Ergebnis:      Der Beleg wird nur nach ausdrücklicher Bestätigung (oder mit entsprechender Berechtigung) gespeichert; die Überschreitung ist im Dialog beziffert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs `CheckIfCustomerLimitIsReached` (8652–8685), `GetLimitUsedInReceipt` (8699–8703) - Begründung: durchgesetzte Prüfung im Save-Workflow mit Netto/Brutto-Umschaltung über `CreditLimitCalculationKind`.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Accounts/AccountCustomer.cs (`CreditLimit`, Konditionsfelder) - Begründung: Datenhaltung für Limit und Konditionen.
+Prüfidee:      Limit 100 EUR, Auftrag 150 EUR → Warnung; Speichern erst nach Bestätigung, ohne Bestätigung Abbruch.
+Tracelinks:    SyRS-6, StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Bonitätssteuerung bleibt erforderlich, Soll-Verhalten (harte Sperre optional) im Zielsystem schärfen.
+Status:        belegt
+```
+
+```
+ID:            StRS-5
+Titel:         Mahnwesen über drei Mahnstufen mit Mahnsperre
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhaltung, Geschäftsleitung
+Vorbedingung:  Rechnung aktiv, Fälligdatum überschritten
+Fakt:          `DunningBL.GenerateInvoiceExpression` selektiert nur `f.State == ReceiptState.Active` und `f.DueDate.Value <= DateTime.Today`; `DunningRunBL.UpdateInvoice` erhöht monoton `DunningLevel.None → Level1 → Level2 → Level3` mit Datum/Bearbeiter; `GetDunningStopActive` wertet zeitfensterbasierte Mahnsperre (`MahnStop`, `DunningStopBegin/End` in `RechKopf`) aus
+Aussage:       Das System soll überfällige Rechnungen in auswertbaren Mahnläufen über drei Stufen eskalieren und kundenspezifische Mahnsperren respektieren.
+Ergebnis:      Mahnstufe, Datum und Mahlauf-Nummer werden je Rechnung protokolliert; gesperrte Kunden/Belege erscheinen nicht im Lauf.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs `UpdateInvoice` (Zeilen 253–268) - Begründung: erzwungene Stufenautomatik inklusive `default: throw`.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs `GetDunningStopActive` (160–177), `GenerateInvoiceExpression` (271–306) - Begründung: Selektions- und Sperrlogik.
+  - [SEKUNDÄR] src/backend/Centron.DAO/Mappings/Sales/Receipts/Invoices/Dunning/InvoiceDunningMaps.cs - Begründung: `this.Table("cvw_InvoiceDunnings")` zeigt View-basierte Datengrundlage.
+Prüfidee:      Rechnung mit Fälligkeit gestern, Mahnstufe 0 → Mahnlauf setzt Stufe 1 plus Datum; mit aktivem Mahnstop bleibt Stufe 0.
+Tracelinks:    SyRS-7, StRS-4
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzliche/kaufmännische Notwendigkeit; fehlende Verzugszinsberechnung im Zielsystem ergänzen.
+Status:        belegt
+```
+
+```
+ID:            StRS-6
+Titel:         Automatische Abrechnung von Wartungs- und Serviceverträgen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service-Abrechnung, Kunde
+Vorbedingung:  Vertrag mit Abrechnungsintervall und Vertragspositionen
+Fakt:          `AutomaticFacturaBL.Contracts.cs` schreibt den Abrechnungszeitraum je Rechnung (`vertragZuordnung.BerechnungszeitraumVon/Bis`) und leitet das nächste `InvoiceTo` aus `BillingIntervalDuration` ab (`nextdate = contract.InvoiceTo.AddDays(contract.BillingIntervalDuration)` bzw. Monats-/Jahresvariante)
+Aussage:       Das System soll Verträge periodisch (Tag/Monat/Quartal/Jahr) abrechnen und dabei den fortgeschriebenen Abrechnungszeitraum je Rechnung dokumentieren.
+Ergebnis:      Pro Abrechnung entsteht eine Rechnung mit exakt dokumentiertem Leistungszeitraum; der Vertrag zeigt das nächste Fälligkeitsdatum.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaBL.Contracts.cs (Zeilen 1481/1493, 1266–1268) - Begründung: durchgesetzte Fortschreibungsarithmetik.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Sales/Receipts/ContractLists/ReceiptContract.cs - Begründung: Modellierung von Wartungsintervall und Vertrags-ToDo-Feldern.
+  - [KONTEXT]  docs/reference/receipts/contracts-backend.md - Begründung: beschreibt `BillingIntervalKind`, `AutomatedBilling` und Spalten `AbrechnungsIntervallArt/Dauer`.
+Prüfidee:      Vertrag mit Monatsintervall und InvoiceTo 31.01.: Abrechnung erzeugt Zeitraum 01.02.–28.02. und InvoiceTo 28.02.
+Tracelinks:    SyRS-8, StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - wiederkehrende Erlöse sind zentrales Geschäftsmodell.
+Status:        belegt
+```
+
+```
+ID:            StRS-7
+Titel:         Zählerstände von Druckern/Kopierern erfassen und mit abrechnen
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Service-Techniker, Abrechnung
+Vorbedingung:  Zählerartikel-Gerät mit Vertrag verknüpft
+Fakt:          Zählerstände liegen in `GeraeteClickZaehler`/`GeraeteClickZaehlerHistory` (`DeviceClickCounter` mit `CurrentCounter`, `BarcodeI3D`); `ContractSpecificLogic` markiert erteilte Zähler mit der SQL-Anweisung „Update GeraeteClickZaehlerHistory Set Abgerechnet = 1 Where VertragKopfI3D = ... and Abgerechnet = 0"
+Aussage:       Das System soll Zählerstände je Gerät historisch erfassen, die abrechnungsrelevanten Differenzen in Vertragsrechnungen übernehmen und verbrauchte Stände als abgerechnet kennzeichnen.
+Ergebnis:      Pro Abrechnungszeitraum wird jeder Zähler genau einmal abgerechnet; erneutem Abrechnungslauf stehen keine offenen Stände mehr zur Verfügung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ContractLists/ContractSpecificLogic.cs (Zeilen 438–440) - Begründung: gesetztes `Abgerechnet = 1` verhindert Doppelabrechnung.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Sales/CustomerAssets/.../DeviceClickCounterItemMaps.cs - Begründung: `Table("GeraeteClickZaehler")` belegt eigene Datenhaltung.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounter.cs - Begründung: Felder `CurrentCounter`, `DeviceHeaderI3D`.
+Prüfidee:      Zähler 1000→1500, Abrechnung; zweiter Abrechnungslauf erzeugt keine Mengen für denselben Stand.
+Tracelinks:    SyRS-8, StRS-9
+Konsolidierung: Kandidat: SyRS-9 (Gerätedaten existieren doppelt: Stammblatt/GeraeteKopf und `AccountDevice`)
+Übernahmewürdigkeit: übernehmen - Kern der volumenbasierten Dienstleistungsverrechnung.
+Status:        belegt
+```
+
+```
+ID:            StRS-8
+Titel:         Verwaltung der Kundenanlagen (Geräte vor Ort)
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Service-Techniker, Kundenbetreuer
+Vorbedingung:  Gerät wurde über Beleg oder Manuell erfasst
+Fakt:          Geräte werden als „Stammblatt" (`MasterDataList`) mit `SerialNumber`, `CounterDevice`, `FreeInventoryNumber`, `ContractI3D` geführt; Parallel existiert `AccountDevice` mit `WarrantyExpiryDate`, `SerialNumber`, `Model`, `Manufacturer`, `Location`; Anlagenkopfsperren laufen über `CustomerAsset.LockedByUser`
+Aussage:       Das System soll den Bestand der beim Kunden installierten Geräte inklusive Seriennummer, Inventarnummer, Standort, Garantie und Vertragszuordnung führen.
+Ergebnis:      Je Gerät ist eindeutig nachvollziehbar, wo es steht, wem es gehört, wann Garantie endet und welcher Vertrag darauf läuft.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Receipts/MasterDataLists/MasterDataList.cs - Begründung: Feldliste des „Stammblatts" ist die im Bestand genutzte Gerätehaltung.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Devices/AccountDevice.cs - Begründung: zweite, moderne Geräteentität mit Garantie-/Standortattributen.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs (`LockedByUser`, `Adviser3I3D`, `CostCenterI3D`) - Begründung: Bearbeitersperre und Betreuungszuordnung.
+Prüfidee:      identisches Gerät in beiden Halungen anlegen → doppelte Anlagenliste; Zielsystem muss eine Führung erzwingen.
+Tracelinks:    SyRS-9, SwRS-30
+Konsolidierung: Kandidat: StRS-7/SyRS-9 – fachlich derselbe Gegenstand (Gerät) in zwei Datenhaltungen
+Übernahmewürdigkeit: Workaround - zwei parallel gewachsene Gerätehaltungen, im Zielsystem zu einem Asset-Konzept zusammenführen.
+Status:        belegt
+```
+
+```
+ID:            StRS-9
+Titel:         Servicezeiten erfassen, abzeichnen und abrechnen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service-Techniker, Projektleiter, Abrechnung
+Vorbedingung:  Ticket mit berechenbaren Zeiten vorhanden
+Fakt:          `HelpdeskTimer` trägt `Calculable`, `LunchTime` („lunchtime is in seconds!"), `IsSigned`, `InvoiceAssetItemI3D`; `HelpdeskTimerBL.DeleteHelpdeskTimer` blockiert mit „Die Helpdesk Zeit wurde einem Beleg zugewiesen. Löschen ist nicht möglich."; die Abrechnungssuche schließt bereits zugeordnete Zeiten aus (`ISNULL(HT.RechPosI3D,0)=0 AND ISNULL(HT.LiefPosI3D,0)=0`)
+Aussage:       Das System soll geleistete Arbeits- und Fahrzeiten pro Ticket erfassen, ihre Abnahme durch Unterschrift belegen und eine doppelte Abrechnung technisch verhindern.
+Ergebnis:      Zugewiesene Zeiten sind unveränderlich/ungelöscht, nicht zugewiesene bleiben abrechenbar; beim Storno werden sie wieder frei.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Sales/Support/HelpdeskTimerArea/HelpdeskTimerMaps.cs (`this.Map(f => f.InvoiceAssetItemI3D).Column("RechPosI3D")`) - Begründung: Belegposition ist der Sperrmechanismus.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskTimerBL.cs `DeleteHelpdeskTimer` - Begründung: Löschsperre bei Belegzuordnung.
+  - [PRIMÄR]   src/backend/Centron.DAO/NamedQueries/NamedQueryPool.xml (`GetTimerForTimerBilling`) - Begründung: Abrechnungsquery filtert `AufPosI3D/LiefPosI3D/RechPosI3D`.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskTimerSignatureBL.cs `SignMultipleTimers` - Begründung: Signaturblob plus Recht `DELETE_HELPDESK_SIGNATURE`.
+Prüfidee:      Zeit auf Rechnung gezogen → Löschen schlägt fehl; Rechnung storniert → Zeit wieder abrechenbar.
+Tracelinks:    SyRS-10, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zeit-gegen-Geld-Abrechnung ist Erlösquelle des Services.
+Status:        belegt
+```
+
+```
+ID:            StRS-10
+Titel:         Ticket- und Auftragsabwicklung im Helpdesk
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Mitarbeiter, Schichtleitung, Kunde (Portal)
+Vorbedingung:  Kunde vorhanden, Ticketart/Priorität gepflegt
+Fakt:          Status ist eine DB-Entität `HelpdeskState` (kein Enum), der „geschlossene" Status wird über die Programmeinstellung `AppSettingsConst.HelpdeskClosedState = 696` bestimmt; `HelpdeskBL.CheckUserRigths` prüft `CLOSE_REQUEST` („Sie haben nicht das Recht \"Helpdesk abschließen\".") und `MATURITY_CHANGE`
+Aussage:       Das System soll Tickets mit konfigurierbarem Statuskanon, Priorität, Fälligkeit, Verantwortlichem und Bearbeiterliste verwalten und den Abschluss an ein Recht binden.
+Ergebnis:      Nur berechtigte Benutzer schließen Tickets; Pflichtfelder (mindestens Kunde) sind vor dem Speichern erzwungen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs `CheckUserRigths`, `DoValidateMandatoryFields` - Begründung: durchgesetzte Rechte- und Pflichtfeldprüfungen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskStatusBL.cs `GetClosedHelpdeskStatus` - Begründung: konfigurierbarer Abschlussstatus statt hartkodiertem Zustand.
+  - [SEKUNDÄR] CentronRights.md Abschnitte 1–8 - Begründung: dokumentiert einschränkende Rechte (nur eigene Tickets, nur eigene Filiale).
+Prüfidee:      Benutzer ohne CLOSE_REQUEST kann Status nicht auf „geschlossen" setzen; Ticket ohne Kunde wird mit „Kein Kunde ausgewählt" abgewiesen.
+Tracelinks:    SyRS-11, StRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Arbeitsobjekt des Servicebereichs.
+Status:        belegt
+```
+
+```
+ID:            StRS-11
+Titel:         Kundenportal (ServiceBoard) und SelfCare-Angebote
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Endkunde des ERP-Kunden (Web-Account)
+Vorbedingung:  Web-Account mit Portalrechten angelegt
+Fakt:          `HelpdeskBL.CheckWebRights` prüft `WEBRIGHT_CREATEREQUEST`, `WEBRIGHT_EDITALLREQUESTS`, `WEBRIGHT_EDITONLYOWNREQUESTS`, `WEBRIGHT_CLOSEALLEREQUESTS`; Nexus stellt Routen `/customerportal`, `/serviceboard/ticket/{ticketId:int}`, `/serviceboard/kanban`, `/serviceboard/plan/{ticketId:int?}` bereit; Dokumentenzugriff ist über `CustomerTicketDocumentAccessType (Never, OwnDocumentsOnly, Always)` reguliert
+Aussage:       Das System soll Kunden im Web eigene Tickets anlegen, einsehen, bearbeiten und schließen lassen sowie Auftrags-/Rechnungs- und Gerätedaten bereitstellen.
+Ergebnis:      Ein Kunde sieht ausschließlich seine eigenen, intern freigegebenen Objekte; interne Ticketnotizen bleiben verborgen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs `CheckWebRights` - Begründung: serverseitige Portalrechte-Prüfung.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/CustomerArea/Support/Helpdesk.cs (`IsOnlyInternalVisible`) - Begründung: Datenfeld zur Abschirmung interner Inhalte.
+  - [SEKUNDÄR] src/nexus/CentronNexus/ServiceBoard (Routen in .razor-Dateien) - Begründung: UI-Seiten des Portals.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/CustomerPortal/CustomerTicketDocumentAccessType.cs - Begründung: Dokumentenfreigabestufen.
+Prüfidee:      Web-Account ohne WEBRIGHT_CLOSEALLEREQUESTS kann Fremd-Ticket nicht schließen; Ticket mit IsOnlyInternalVisible=true ist im Portal unsichtbar.
+Tracelinks:    SyRS-12, StRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Entlastung des Supports und Kundenbindeinstrument.
+Status:        belegt
+```
+
+```
+ID:            StRS-12
+Titel:         B2B-Shop (WebCart) mit Freigabewesen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Kunde des Kunden (Web-Account), Einkäufer, Prüfer
+Vorbedingung:  Web-Account mit „Sonderpreisen" als Shop-Sortiment
+Fakt:          `ReceiptCartBL.SearchArticles` filtert das Artikelangebot auf hinterlegte Sonderpreise („// Special Prices ... query.Where(f => specialPriceArticleI3Ds.Contains(f.I3D))"); `ReceiptCartReleaseSystemBL` erzwingt den Zustandsübergang `Created → ReadyForCheck → Checked/DeclinedByChecker` und erzeugt nach Einkäuferfreigabe über `ForwardCartToOrder`/`SaveOrder` einen Auftrag
+Aussage:       Das System soll ausgewählten Kunden ein Bestellportal bieten, dessen Sortiment aus kundenindividuellen Sonderpreisen besteht und dessen Bestellungen ein mehrstufiges Freigabewesen durchlaufen.
+Ergebnis:      Ein Warenkorb wird erst nach Prüfer- und Einkäuferfreigabe zum Auftrag; Zustandsverstöße werden abgelehnt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs `SearchArticles` - Begründung: Sortiment wird hart auf Sonderpreisartikel begrenzt.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs `UpdateReceiptCartState` - Begründung: „Der Warenkorb befindet sich bereits an einem anderen Schritt des Freigabewesens." verhindert Sprünge.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Sales/Receipts/ReceiptCartState.cs - Begründung: Enum mit Workflow-Beschreibung und Mermaid-Diagramm.
+  - [KONTEXT]  README.md („The webcart is a a feature primarily intended for the customers of our customers") - Begründung: fachlicher Zweck.
+Prüfidee:      Warenkorb direkt von Created auf OrderHeben ohne Prüferschritt → Fehlermeldung; kompletter Durchlauf erzeugt Auftrag.
+Tracelinks:    SyRS-13, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - selbstbedienter Vertriebskanal mit Kontrollfunktion.
+Status:        belegt
+```
+
+```
+ID:            StRS-13
+Titel:         Digitale Angebotsannahme und rechtsbehelfsfähige Unterschrift
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Endkunde (ohne Login), Vertriebsmitarbeiter
+Vorbedingung:  Angebot wurde mit Freigabe-Link versendet
+Fakt:          Das Nexus stellt token-gesteuerte Seiten `@page "/weboffer/{Token}"` und `@page "/weboffer/{Token}/pdfpreview"` bereit; das Backend löst den Token über `ReceiptPdfDocument.ReceiptAccessToken` (`ReceiptWebServiceBL.GetReceiptForWeb`) auf und nimmt `ChangeWebReceiptState(Token, WebReceiptState.Rejected/Accepted)` sowie Mengenänderungswünsche entgegen; es existieren zwei Signaturverfahren: Signatur-Pad (`IsolatedSignaturePad.razor`) und kryptografische PDF-Signatur mit Zertifikat plus TSA (`src/backend/Centron.BL/Security/PdfSigningBL.cs`)
+Aussage:       Das System soll Kunden die Annahme, Ablehnung und Änderung von Angeboten per Link ermöglichen und Unterschriften als Bild oder als qualifizierte PDF-Signatur unterstützen.
+Ergebnis:      Das Angebot trägt den neuen WEB-Status, Änderungen sind protokolliert, das signierte Dokument wird in die Auftragshistorie integriert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs `GetReceiptForWeb` - Begründung: Token ist der einzige Zugriffsnachweis.
+  - [PRIMÄR]   src/backend/Centron.BL/Security/PdfSigningBL.cs - Begründung: Signatur mit Zertifikat und TSA-Server ist implementiert.
+  - [SEKUNDÄR] src/nexus/CentronNexus/WebOffer/WebReceiptOverview.razor - Begründung: UI-Handlungen „Angebot annehmen"/Ablehnen/Mengenänderung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Administration/FileManagement/SharedDocumentBL.cs `MergedSignedDocument` - Begründung: signierte Seiten werden in Auftragsdokumente eingefügt.
+Prüfidee:      Gültiger Token akzeptiert Angebot; abgelaufener/ungültiger Token liefert Fehler; signiertes PDF enthält Sig-Feld und Zeitstempel.
+Tracelinks:    SyRS-14, StRS-2
+Konsolidierung: Kandidat: SyRS-14 (Signatur-Pad und Zertifikatssignatur bilden dieselbe Fachfunktion „Abnahme" mit unterschiedlicher Rechtssicherheit)
+Übernahmewürdigkeit: übernehmen - Vertriebsbeschleunigung, Rechtssicherheit im Zielsystem präzisieren.
+Status:        belegt
+```
+
+```
+ID:            StRS-14
+Titel:         Automatisierter Dokumentenaustausch mit Distributoren (EDI)
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf (systemgesteuert), Distributor (ALSO, ALSO CH, Herweck, Komsa, Alltron, Concerto, Egis)
+Vorbedingung:  Lieferanten-EDI-Konfiguration je Lieferant/Belegart vorhanden
+Fakt:          `SupplierEdiBL.ApplyDistriToCentron(List<EDIDistriFile>, SupplierEdiConfigurations, OrderInfo)` verzweigt nach `EdiDataType` (OpenTrans21=1 … Zugferd=7) und `EDIConnectionObjectKind` (Order=1, OrderResponse=2, Delivery=3, Invoice=4) in lieferantenspezifische Partial-Klassen; `EDILogBL` protokolliert `EDILogState.DownloadOK/DownloadError/Exception`
+Aussage:       Das System soll Auftragsbestätigungen, Lieferanzeigen und Lieferantenrechnungen der Großhändler automatisch einlesen und auf die eigenen Bestellungen buchen.
+Ergebnis:      Bestelldaten werden aktualisiert, Abweichungen protokolliert und dem Bearbeiter gemeldet; Rohdateien werden nach Erfolg aufgeräumt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/EDI/SupplierEDI/SupplierEdiBL.cs `ApplyDistriToCentron` - Begründung: zentraler Dispatch mit Format-/Objektartverzweigung.
+  - [PRIMÄR]   src/backend/Centron.BL/EDI/SupplierEDI/SupplierEdiBL.AlsoCH.cs (RMM/ESR-Besonderheiten) - Begründung: lieferantenspezifisch erzwungene Regeln.
+  - [KONTEXT]  docs/reference/edi/edi-architecture.md - Begründung: beschreibt Datenfluss FTP/SFTP → Parsen → Buchung → Log.
+Prüfidee:      Test-Auftragsbestätigung mit abweichender Menge → Bestelldatensatz aktualisiert, Logeintrag mit Fehlerstatus, Benutzerbenachrichtigung.
+Tracelinks:    SyRS-15, StRS-17
+Konsolidierung: Kandidat: SyRS-15 (je Distributor separate Parser-Klasse für dieselben drei Dokumentarten)
+Übernahmewürdigkeit: übernehmen - ohne EDI sind Großhandelspreise/-verfügbarkeit nicht wirtschaftlich abbildbar.
+Status:        belegt
+```
+
+```
+ID:            StRS-15
+Titel:         E-Rechnungsausgang nach ZUGFeRD/XRechnung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, öffentliche Auftraggeber
+Vorbedingung:  Rechnung oder Gutschein/Gutschrift erstellt
+Fakt:          `InvoiceZugferdBL.GetBookkeepingReceiptKind` wirft „{receiptKind} is not valid for XRechnung" für andere Belegarten; `GenerateZugferdFile` wählt `ZugferdFileKind.XInvoice` bei vorhandener Leitweg-ID sonst `Comfort`; bei XInvoice wird die Leitweg-ID als Pflichtfeld `ram:BuyerReference` geschrieben; Steuerklassen-Codes werden je Steuerart vergeben (`AE/E/K/G/S`)
+Aussage:       Das System soll ausgehende Rechnungen im ZUGFeRD-2.1-Format und – bei Betreibern mit Leitweg-ID – im XRechnung-Profil erzeugen und die steuerlichen Befreiungsgründe korrekt codieren.
+Ergebnis:      Gültige, validierbare XML/PDF-Dokumente nach EN 16931 inkl. Richtlinie-Version (xrechnung_2.3/3.0).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs (Zeilen 120, 153–156, 1531–1535, 2095–2106, 1288–1289) - Begründung: alle Regelfälle sind im Generator durchgesetzt.
+  - [SEKUNDÄR] src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs `GetTaxExemptionReason` - Begründung: deutsche Befreiungsgründe (BR-DE-Regelwerk).
+  - [KONTEXT]  docs/guides/development/xrechnung.md - Begründung: verweist auf die eingebettete ZUGFeRD-2.1.1-Spezifikation.
+Prüfidee:      Rechnung an Kunde mit Leitweg-ID → XRechnung mit BuyerReference; Lieferschein → Fehlermeldung; Reverse-Charge-Position → Steuer-Code AE.
+Tracelinks:    SyRS-16, StRS-2
+Konsolidierung: Kandidat: SyRS-16 (EbInterface für österreichische E-Rechnung parallel zu ZUGFeRD)
+Übernahmewürdigkeit: übernehmen - ab 2025/2028 Pflicht in Deutschland.
+Status:        belegt
+```
+
+```
+ID:            StRS-16
+Titel:         Lagerbestandsführung mit Mindestbestand und Inventur
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Lagerist, Disponent
+Vorbedingung:  Artikel mit Lagerorten/Mindestbestand gepflegt
+Fakt:          `Article.RealQuantity` ist read-only aus Sicht der Entität (Kommentar „Do not map Quantity in this entity. … For stock changes use ArticleMainStock entity"); Zugänge/Reservierungen werden über `StockInOrder`, `StockInDelivery`, `StockInRepair` abgebildet; Mindestbestand = Spalte `Mindestbestand`; `InventoryNewBL` blockiert „Inventur '{inventory.Name}' wurde schon abgeschlossen."
+Aussage:       Das System soll den physischen Bestand je Artikel (inkl. Nebenlager, Lagerort/Lagerplatz) führen, Zugänge aus Bestell-/Liefer-/Reparaturvorgängen ausweisen und Inventuren abschließbar machen.
+Ergebnis:      Bestandsangaben sind manipulationsgeschützt über Buchungssätze, Inventuren sind einmalig abschließbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs - Begründung: erzwungene Änderung über `ArticleMainStock`, read-only-Sicht.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryNewBL.cs - Begründung: Statusprüfung verhindert Doppelabschluss.
+  - [SEKUNDÄR] src/backend/Centron.DAO/Mappings/Warehousing/ArticleMaps.cs (`MinimumHolding` → `Column("Mindestbestand")`) - Begründung: Persistierung des Mindestbestands.
+Prüfidee:      Inventur abschließen, zweiter Abschluss → Fehlermeldung; Warenbewegung schreibt Buchung statt Direktänderung der Menge.
+Tracelinks:    SyRS-17, StRS-17
+Konsolidierung: Kandidat: SwRS-41 (veraltete Entitäten `SecondaryStock`/`StorageLocation` neben `Stock`/`StoragePlace`)
+Übernahmewürdigkeit: übernehmen - Grundfunktion Warenwirtschaft.
+Status:        belegt
+```
+
+```
+ID:            StRS-17
+Titel:         Deckungsorientierter Einkauf mit Bestellvorschlag
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkäufer, Disponent
+Vorbedingung:  Mindestbestand und Distributionslogistik gepflegt
+Fakt:          `OrderSuggestionListBL` berechnet Vorschläge mit SQL „INNER JOIN cvw_ArticleCount ac … and ac.cnt < a.Mindestbestand + IsNull(ab.duration,0)" und Rechenfaktor aus `AppSettingsConst.ArticleCalculationFactor`; EK-Preisaktualisierung aus Distributorenimport erfolgt nur `&& !f.NoPriceUpdate` und wird im Artikellog als „EK (Preisupdate)" protokolliert
+Aussage:       Das System soll aus Mindestbeständen und Lieferzeiten automatische Bestellvorschläge erzeugen und Einkaufspreise controlled aus Distributor-Daten nachziehen.
+Ergebnis:      Nachbestellbedarf wird listenförmig vorgeschlagen; Preisänderungen sind je Artikel nachvollziehbar protokolliert und einzeln sperrbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs (Zeilen 70–79, 146) - Begründung: durchgesetzte Vorschlagsarithmetik.
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs - Begründung: `NoPriceUpdate`-Guard und `articleLogBL.WriteLog(... "EK (Preisupdate)" ...)`.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs (`RawEk1/RawEk1Date/RawEk1ObjectKind`) - Begründung: Herkunft des EK-Preises wird mitgeführt.
+Prüfidee:      Artikel unter Mindestbestand erscheint im Vorschlag; Artikel mit `NoPriceUpdate` behält alten EK trotz Import.
+Tracelinks:    SyRS-18, StRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lagerkosten-Optimierung bleibt betriebswirtschaftlich erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-18
+Titel:         Versandabwicklung mit Labelerstellung und Sendungsverfolgung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Disponent/Versand, Spedition (GLS, Shipcloud)
+Vorbedingung:  Lieferschein erstellt, Versanddienst konfiguriert
+Fakt:          Versand wird über externe Provider abgebildet (`Centron.Api.Shipcloud`: `internal const string _baseURL = "https://api.shipcloud.io/v1/"`; `Centron.Api.Gls`: `BaseURL = "https://api.gls-group.eu/public/v1/"`); aktiv/abgeschaltet über `ApplicationSettingID.IsShipcloudActive, ShipcloudApiKey, ShipcloudSandBoxApiKey, ShipcloudStandardCarrierName`; Verfolgungsobjekt `CentronObjectKindNumeric.DeliveryListTrackingLinks = 7600152`
+Aussage:       Das System soll aus Lieferscheinen Sendungen mit Provider-Labeln anlegen und Sendungsnummern/Tracking-Links je Paket verfügbar machen.
+Ergebnis:      Pro Packstück existieren Label, Spediteur, Tracking-Link; der Kunde erhält eine Versandbenachrichtigung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs (`GetShipcloudSettings`) - Begründung: durchgesetzte Konfigurations-/Sandbox-Schalter.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/Mail/Templates/MailTemplateDefaultText.cs - Begründung: Text „Versandbenachrichtigung zu Ihrer Bestellung @@Bestellnummer@@ – Sendungsverfolgung ...".
+  - [SEKUNDÄR] src/apis/Centron.Api.Shipcloud/CentronShipcloudConsts.cs, src/apis/Centron.Api.Gls/CentronGlsConsts.cs - Begründung: Provider-Endpunkte.
+Prüfidee:      Lieferschein → Shipcloud-Sandbox liefert Label + Trackingnummer, Versandmail enthält Link.
+Tracelinks:    SyRS-19, StRS-2
+Konsolidierung: Kandidat: SyRS-19 (zwei Provider-Implementierungen derselben Funktion „Paket versenden")
+Übernahmewürdigkeit: übernehmen - Versand ist Kernprozess des Hardwarehandels.
+Status:        belegt
+```
+
+```
+ID:            StRS-19
+Titel:         RMA-Warenrückführung (Retoure, Austausch, Reparatur)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service-Abwicklung, Lager, Kunde
+Vorbedingung:  Seriennummer mit Historie vorhanden
+Fakt:          Artikelstatus je RMA-Vorgang im Enum `RmaArticleState` („Rücksendung"=3, „verschrottet"=5, „Vorabtauschlieferschein"=7, Wareneingang=16) und -maßnahmen in `RmaForthAction` („1-zu-1 Austausch"=1, „Reparatur"=3, `RepairInPlace`=8); `RmaBL` setzt `artic.SendForthQuantity = 0` wenn `RmaArticle.ForthAction == RmaForthAction.none`; RMA-Lager werden über AppSettings (`RMACustomerStorage`, `RMAOwnStorage`, `RMASendStorage`, `RMAOrderStorage`) vom regulären Lagerbetrieb getrennt
+Aussage:       Das System soll Retouren als eigenständiger Vorgang mit Rücksendung, Prüfung, Tausch-/Reparaturentscheidung und eigener Lagerführung abbilden.
+Ergebnis:      Jede Seriennummer hat einen lückenlosen RMA-Status; ohne gewählte Maßnahme wird keine Rücksendemenge vorgeschlagen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/CustomerArea/RmaBL.cs (Zeilen 474, 735–736) - Begründung: codedurchgesetzte Mengensteuerung.
+  - [PRIMÄR]   src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs (Ausschluss der RMA-Lager aus `LoadOpenWarehouses`) - Begründung: erzwungene Lagertrennung.
+  - [SEKUNDÄR] src/backend/Centron.Interfaces/CustomerArea/RmaArticleState.cs, RmaForthAction.cs - Begründung: Zustandswelt des Vorgangs.
+Prüfidee:      RMA-Position ohne ForthAction → SendForthQuantity 0; RMA-Wareningang bucht in RMA-Lager, nicht ins Hauptlager.
+Tracelinks:    SyRS-20, StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Gewährleistungsabwicklung ist handelsüblich.
+Status:        belegt
+```
+
+```
+ID:            StRS-20
+Titel:         Produktionsaufträge mit Arbeitsschritten und Maschinen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Produktionsleitung, Fertigungsmitarbeiter
+Vorbedingung:  Lizenz `LicenseGuids.ProductionManagement` vorhanden, Stückliste/Produktionsartikel gepflegt
+Fakt:          `ProductionBL`/`ProductionOrderBL` werfen ohne Lizenz „Sie besitzen nicht die Lizenz für das Produktionsmanagement"; Statusänderungen werden als `ProductionOrderLogKind.ProductionOrderItemStateChanged`, `ProducedAmountChanged`, `PlannedFinishDateChanged` protokolliert; Stücklistenauflösung verbietet Summenpositionen („In der Stückliste darf keine Summe enthalten sein.")
+Aussage:       Das System soll Fertigungsaufträge mit Arbeitsschritten, Maschinen, geplanten/Ist-Mengen und Rückmeldungen führen und die Kalkulationsgrundlage aus gültigen Stücklisten ableiten.
+Ergebnis:      Jeder Fertigungsauftrag hat eine lückenlose Status-/Mengenhistorie; fehlerhafte Stücklisten werden abgelehnt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Production/ProductionBL.cs (Zeilen 29–30) - Begründung: Lizenz-Gate erzwungen.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Production/ProductionOrderWebServiceBL.cs (Zeilen 102/184/224) - Begründung: erzwungene Protokollierung der Änderungstypen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs (Zeilen 598–610) - Begründung: Stücklisten-Integritätsregeln.
+Prüfidee:      Produktionsauftrag ohne Lizenz → Fehler; Ist-Menge ändern → Logeintrag ProducedAmountChanged.
+Tracelinks:    SyRS-21, StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - nur für Kunden mit Fertigung; Lizenzgrenze beibehalten.
+Status:        belegt
+```
+
+```
+ID:            StRS-21
+Titel:         Übergabe der Buchhaltung an DATEV und weitere Systeme
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhaltung, Steuerberater
+Vorbedingung:  Belege exportfertig, Kontenrahmen/-zweck gepflegt
+Fakt:          Exportformat-Familie unter `src/backend/Centron.Gateway/DataExchange/BookKeeping/` (DatevAscii, DatevXmlOnline/DatevXMLOnline2020, Abacus, Addison, GDI, LexwarePro2011, SageOfficeLine, SchillingAS400); DATEV-ASCII-Klasse dokumentiert „DATEV ASCII export interface for master data (Debitoren/Kreditoren) and booking data"; Exportsperrflags `BookKeepingCustomerAssetExportFlag` speichern `ExportDate`, `EmployeeI3D`, `ComputerName`, `ComputerIP`
+Aussage:       Das System soll Beleg- und Stammdaten in nachweispflichtiger Form an die Finanzbuchhaltung übergeben und ein bereits exportiertes Objekt vor Doppelexport schützen.
+Ergebnis:      Jeder Export ist mit Benutzer, Rechner, IP und Datum belegt; ein stornierbarer Beleg nach Export kann nicht mehr storniert werden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs - Begründung: Exportflag-Prüfung als durchgesetzter Schutz.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs `CancelInvoice` („...da Sie bereits exportiert wurde.") - Begründung: Stornosperre nach Export.
+  - [SEKUNDÄR] src/backend/Centron.Gateway/DataExchange/BookKeeping/DatevXMLOnline2020/BookKeepingExportDatevXmlOnline_2020.cs - Begründung: Formatvalidierung „DATEV erlaubt folgendes Pattern: [a-zA-Z0-9$%&*+-/] mit einer maximalen Länge von 36 Zeichen."
+Prüfidee:      Rechnung exportieren → Storno abgelehnt; Rechnung mit Sonderzeichen im DATEV-Online-Export → Vorabfehlermeldung.
+Tracelinks:    SyRS-22, StRS-5
+Konsolidierung: Kandidat: SyRS-22 (acht Zielformate für dieselbe Übergabefunktion)
+Übernahmewürdigkeit: übernehmen - gesetzliches Erfordernis; Formatauswahl im Zielsystem konfigurieren statt verzweigen.
+Status:        belegt
+```
+
+```
+ID:            StRS-22
+Titel:         Zahlungseingänge erfassen und Belege abzahlen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Debitorenbuchhaltung
+Vorbedingung:  offene Rechnung vorhanden
+Fakt:          Zahlungseingänge werden in Tabellen `Zahlungseingang`/`ZahlungseingangLog` geführt; die Online-Banking-Zuordnung trägt `IsBooked`, `BookedReceiptDemandedGrossAmount`, `BookedReceiptOpenGrossAmount`; `ReceiptBL` verhindert „...wurde stoniert und kann daher nicht als bezahlt oder nicht bezahlt eingestellt werden..." und setzt Zahlung auf `Completed`
+Aussage:       Das System soll Zahlungen aus dem Online-Banking den offenen Belegen zuordnen, den Belegstatus automatisch auf „bezahlt/abgeschlossen" ziehen und die Buchung revisionsfähig protokollieren.
+Ergebnis:      Belegstatus, offene Summe und Zahlungshistorie stimmen überein; stornierte Belege bleiben unbeteiligt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (Zeilen 4936–4949) - Begründung: durchgesetzter Statusübergang `Canceled`-Schutz.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Finances/OnlineBanking/OnlineBankingTransactionAssignment.cs - Begründung: Buchungsflags der Transaktionszuordnung.
+  - [SEKUNDÄR] src/backend/Centron.DAO/Mappings/Finances/Payments/IncomingPayments/IncomingPaymentMaps.cs - Begründung: `Zahlungseingang` als Datenhaltung.
+  - [SEKUNDÄR] src/apis/Centron.APIs.FinAPI/FinApiConstants.cs (`LiveAccessApiUrl = "https://live.finapi.io"`) - Begründung: PSD2-Kontodatenzugang.
+Prüfidee:      Zahlung zuweisen → Status Completed, Logeintrag vorhanden; Zahlung auf stornierte Rechnung → Fehler.
+Tracelinks:    SyRS-23, StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Forderungsmanagement bleibt Kernaufgabe.
+Status:        belegt
+```
+
+```
+ID:            StRS-23
+Titel:         Rollen-, Rechte- und Filialabschottung
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        IT-Administration, Bereichsleitung, Mitarbeiter
+Vorbedingung:  Benutzer ist Gruppe mit Rechten zugeordnet
+Fakt:          Rechtsprüfung `AppRightsBL.HasUserRight` (`return rights.Contains(rightID);`) lädt Rechte per SQL aus `Sichtrus`/`Sichmemb` und cached sie je Benutzer; `UserRightsExt.HasUserRight` gibt im `catch`-Fall `false` zurück;HTTP-Endpunkte werden über `UserRightAuthorizationFilter` mit `context.Result = new ForbidResult();` abgesichert; einschränkende Rechte filtern Daten (z. B. `SHOW_ONLY_OWN_CUSTOMER`, `MANAGE_RIGHTS_ONLY_OWN_BRANCH` → `query.Where(f => f.BranchI3D == currentUser.Employee.BranchI3D.GetValueOrDefault(0))`)
+Aussage:       Das System soll Funktionen und Datenbestände über ein rightbasiertes Berechtigungswesen mit verpflichtenden Einschränkungspfaden („nur eigene", „nur eigene Filiale/Abteilung") steuern.
+Ergebnis:      Ohne Recht keine Funktion; mit einschränkendem Recht nur der erlaubte Datenausschnitt; Fehler im Rechtesystem entziehen Zugriff (fail-closed).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs (Zeilen 646–656, 355–357, 45) - Begründung: Prüfung, Datenfilter und Löschsperre im Code.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs (Zeilen 28–31) - Begründung: Fail-Closed-Verhalten.
+  - [PRIMÄR]   src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs (Zeilen 50–51) - Begründung: HTTP-Autorisierung.
+  - [SEKUNDÄR] CentronRights.md - Begründung: fachliche Beschreibung der einschränkenden Rechte.
+Prüfidee:      Benutzer ohne SHOW_HELPDESK sieht keine Ticketliste; Benutzer mit SHOW_HELPDESK_ONLY_OWN_BRANCH sieht nur Tickets der eigenen Filiale.
+Tracelinks:    SyRS-24, SyRS-25
+Konsolidierung: Kandidat: SyRS-24 (drei Prüfmechanismen: BL-Prüfung, Attribut-Filter, Nexus-Lizenzrollen)
+Übernahmewürdigkeit: übernehmen - Compliance-Anforderung; Ausbaustufe vereinheitlichen.
+Status:        belegt
+```
+
+```
+ID:            StRS-24
+Titel:         Mandanten- und Filialstruktur innerhalb einer Installation
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Konzernleitung, IT-Administration
+Vorbedingung:  Mandant und Filialen angelegt
+Fakt:          `Mandator`-Entität trägt `TaxIDNumber` und `CustomerI3D`; Filiale referenziert `BaseBranch.MandantI3D`; Nummernkreise werden mandants- oder filialbezogen aufgelöst (`MandatoryBL`: „WHERE ((nu.MandantI3D = fm.I3D AND nu.FilialI3D = f.I3D) OR nu.MandantI3D = m.I3D)"); Kunden-/Lieferantennummern je Filiale über `CustomerToBranch` inkl. `BookKeepingNumber`
+Aussage:       Das System soll rechtlich selbständige Einheiten (Mandanten) mit Filialen abbilden und belegenden Nummernkreise, Steuerdaten und Filialnummern je Einheit führen.
+Ergebnis:      Belegnummern sind je Mandant/Filiale eindeutig zuordenbar, filialbezogene Auswertungen sind möglich.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs - Begründung: Auflösung der Nummernkreis-Zuordnung nach Mandant/Filiale.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Administration/Company/Mandator.cs - Begründung: Mandantenstammdaten inkl. eigener Steuernummer.
+  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/Accounts/CustomerToBranch.cs - Begründung: filialspezifische Kunden-/Buchungsnummern.
+Prüfidee:      Gleiche Belegart in zwei Filialen mit eigenen Nummernkreisen → keine Kollision der Nummern.
+Tracelinks:    SyRS-26, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandantenfähigkeit ist Voraussetzung für Konzernkunden.
+Status:        belegt
+```
+
+```
+ID:            StRS-25
+Titel:         Lizenz- und Funktionssteuerung pro Kunde
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:        Hersteller NEXOWARE, Kunde, Lizenzadministrator
+Vorbedingung:  Lizenzdaten aus dem Lizenzserver („c-entron Office") liegen vor
+Fakt:          `LicenseManager.LoadLicenses` ruft `this.CheckLicense(applicationKind, currentVersion.ToString(), null).ThrowIfError();` (Kommentar: „We throw an exception here, and the web-service startup fails"); `CheckLicense` prüft `CheckLicenseVersion` und Kontingent („Die maximale Anzahl an Lizenzen wurde erreicht."); Modulregistrierung im Client filtert `.Where(f => f.CheckModuleFeatures())`/`.Where(f => f.CheckRights(allRights))`
+Aussage:       Das System soll Funktionstiefe (Module, Einzelfeatures, Mengensteuerung) über GUID-basierte Lizenzen mit Kontingent, Gültig-bis-Datum und Gültig-bis-Version steuern und die Anmeldung bei ungültiger Lizenz verweigern.
+Ergebnis:      Nicht lizenzierte Module erscheinen nicht; abgelaufene/überzählige Lizenzen verhindern Start bzw. Login.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs (Zeilen 234, 274, 281–282) - Begründung: Startzwang und Kontingentsperre.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs (Zeilen 100–104, 132) - Begründung: `ApplicationKind`- und Lizenzprüfung vor Ticketvergabe.
+  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs - Begründung: lizenzabhängige Modulsichtbarkeit.
+  - [KONTEXT]  docs/reference/security/licensing-system.md - Begründung: erläutert `LicenseGuids.cs`/`ApplicationKind.cs`.
+Prüfidee:      Lizenz „Produktionsmanagement" entzogen → Modul fehlt, BL-Aufruf wirft; abgelaufene Anwendungslizenz → Login Fehler -9.
+Tracelinks:    SyRS-27, SyRS-41
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Geschäftsmodell; Prüflogik gehört ins Zielsystem (aktuell teils in externer Bibliothek).
+Status:        belegt
+```
+
+```
+ID:            StRS-26
+Titel:         Nachvollziehbarkeit von Änderungen und Beleglebenszyklen
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        Revision, Buchhaltung, Support
+Vorbedingung:  Objekt wurde geändert/gedruckt/exportiert
+Fakt:          `ChangeTrackingEventListener` schreibt `ChangeLog` mit `OldValue/NewValue/Property/AppUser`, überspringt das Tracking aber ohne angemeldeten Benutzer (`if (LoggedInUserManager.AppUserI3D == default(int)) { Logger.Warn(...); return null; }`); Belegausgaben landen im zentralen Log `AnlageLog` (`this.Table("AnlageLog")`, `ReceiptLogBL.CreateReportEntry` differenziert `Print/Mail/PDFExport`); Belegstände werden 1:1 in Versions-tabellen kopiert (`AssetHeadDAO.SaveAssetVersion`)
+Aussage:       Das System soll jede wesentliche Änderung, jeden Druck/Versand/Export und jeden Storno eines Belegs protokollieren und frühere Belegstände als Version verfügbar halten.
+Ergebnis:      Änderungen sind personen-, zeit- und wertbezogen rekonstruierbar; Belegversionen sind vollständig kopiert.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs (Zeilen 121–137) - Begründung: durchgesetzte Protokollierung inkl. Lücke bei fehlendem Benutzer.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Sales/Receipts/ReceiptLogMaps.cs - Begründung: zentrale Logtabelle.
+  - [PRIMÄR]   src/backend/Centron.DAO/Repositories/Sales/Customers/Assets/AssetHeadDAO.cs `SaveAssetVersion` - Begründung: Versionskopie per SQL.
+Prüfidee:      Beleg drucken → Logeintrag `Print` mit Bearbeiter; Änderung ohne Sitzungsbenutzer → kein ChangeLog (Lücke bewusst prüfen).
+Tracelinks:    SyRS-28, StRS-21
+Konsolidierung: Kandidat: SyRS-28 (drei parallele Protokollierschichten: ChangeLog, AnlageLog, objektspezifische Historientabellen)
+Übernahmewürdigkeit: übernehmen - GoBD-Relevanz.
+Status:        belegt
+```
+
+```
+ID:            StRS-27
+Titel:         Auswertungen, Statistiken und automatisierter Reportversand
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsleitung, Controlling, Bereichsleiter
+Vorbedingung:  Reportdaten und Empfängerkonfiguration vorhanden
+Fakt:          Report-Engine basiert auf FastReport (`<PackageReference Include="FastReport.Net.Pro" Version="2022.1.6.2" />` im Centron.BL.csproj); ReportServer erzeugt je Empfänger einen eigenen Report („Damit bekommt jeder Empfänger seine eigene E-Mail mit einem extra für ihn generierten Report", Feature `AddSendSeparateEmailsToReportServer`); Statistikmodule filtern nach Filialrecht (`SHOW_ONLY_STATISTIC_FROM_OWN_BRANCH`)
+Aussage:       Das System soll Vertriebs-, Vertrags-, Mitarbeiter- und Managementstatistiken bereitstellen und Reports zeitgesteuert personalisiert per E-Mail verteilen.
+Ergebnis:      Empfänger erhalten nur die ihren Rechten entsprechenden Auswertungen; Verteilungen laufen ohne Benutzeraktion.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs (Zeilen 60–62) - Begründung: rechtebasierter Datenfilter.
+  - [SEKUNDÄR] src/backend/Centron.BL/Centron.BL.csproj - Begründung: Report-Bibliothek (FastReport) als Technologieentscheidung.
+  - [SEKUNDÄR] src/shared/Centron.Controls/TaskManager/ReportServerViewModel.cs - Begründung: ReportServer-Konfigurationsoberfläche.
+  - [KONTEXT]  src/backend/Centron.Interfaces/Administration/Logins/LicenseGuids.cs (`TaskManagementReportServer`) - Begründung: Lizenzpflicht des Reportversands.
+Prüfidee:      Zwei Filialen mit je eigenem Reportempfänger → je Empfänger nur eigene Daten im Anhang.
+Tracelinks:    SyRS-29, StRS-23
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Steuerungsbedarf bleibt; Reporttechnik im Zielsystem neu wählbar.
+Status:        belegt
+```
+
+```
+ID:            StRS-28
+Titel:         Kundenindividuelle Anpassung und Datenqualitäts-Selbstheilung
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Hersteller/Partner (Customizing), Systembetrieb
+Vorbedingung:  Kundeninstallation mit abweichenden fachlichen Wünschen
+Fakt:          DB-Anpassungen laufen über nummerierte Skriptklassen (`ScriptMethod{NUMMER}`), deren Anzahl im Bestand 764 Dateien beträgt; der `ScriptEngineBL` führt nur fehlende Skripte mit `currentVersion >= f.ApplicationVersion` aus und markiert sie in `DBUpdate`; benutzerdefinierte Felder laufen über `ModuleCustomProperty` (`ValueMask`, `IsMandatory`); der `DataQualityService` (Intervall `TimeSpan.FromHours(1)`) repariert u. a. `CheckAndRepairAccountTypeToAccountsTable()`
+Aussage:       Das System muss kundenindividuelle Erweiterungen (Felder, Tabellen, SQL-Objekte) versioniert ausrollen und bekannte Dateninkonsistenzen automatisch bereinigen können.
+Ergebnis:      Jede Installation enthält genau die zu ihrer Version gehörenden Anpassungen; Datenqualitätsregeln werden periodisch nachgeführt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs (Zeilen 53–54, 77) - Begründung: versionsgesteuerte, idempotente Ausführung.
+  - [PRIMÄR]   src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs - Begründung: periodisch ausgeführte Reparaturaufrufe.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Administration/Customization/ModuleCustomProperty.cs - Begründung: konfigurierbare Felder mit Validierung.
+  - [KONTEXT]  docs/reference/database/script-rules.md („Each script should be independent and idempotent") - Begründung: Regelwerk des Migrationswegs.
+Prüfidee:      Installation von Version n auf n+2 → genau die fehlenden Skripte laufen, zweiter Start läuft keine Skripte mehr.
+Tracelinks:    SyRS-30, SyRS-31
+Konsolidierung: Kandidat: SwRS-52 (SQL-Skriptmigration neben `*KopfVersions`-Duplikatlogik und `ChangeLog`)
+Übernahmewürdigkeit: Workaround - SQL-Skriptprothesen je Kunde sind behelfsmäßig und im Ziel durch deklaratives Customizing/Migrationsframework zu ersetzen.
+Status:        belegt
+```
+
+```
+ID:            StRS-29
+Titel:         Betrieb, Diagnose und Telemetrie der Installation
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:        Hersteller-Support, Kunden-IT
+Vorbedingung:  Webservice läuft, Konfiguration `WebServiceConfig.xml` vorhanden
+Fakt:          Der Webservice schreibt Log-CSV nach `%CommonApplicationData%\c-entron software gmbh\c-entron Web-Service\Logs` (`nlog.config`, `archiveEvery="Day" maxArchiveFiles="15"`, `<logger name="Centron*" minLevel="WARN" writeTo="csvTarget" />`); Telemetrie wird aggregiert, in DB-Tabellen gemergt (`MERGE dbo.McpToolUsageTelemetry WITH (HOLDLOCK)`) und als ZIP („telemetry.json") an c-entron Office hochgeladen; Nexus bietet `/logviewer/{applicationLog?}`
+Aussage:       Das System soll im Betrieb strukturiert mitloggen, Diagnosedaten im Produktivsystem einsehbar machen und aggregierte Nutzungsdaten an den Hersteller übermitteln.
+Ergebnis:      Support kann Fehlerraten, Funktionsnutzung und Versionsstand je Installation auswerten; Logdateien sind begrenzt aufbewahrt.
+Belege:
+  - [PRIMÄR]   src/webservice/Centron.Host.WindowsService/nlog.config - Begründung: konfigurierte Ziel-/Rotationsregel.
+  - [PRIMÄR]   src/backend/Centron.BL/Telemetry/TelemetryBL.cs - Begründung: Persistierung und Upload der Telemetrie.
+  - [SEKUNDÄR] src/nexus/CentronNexus/Shared/Diagnostics/LogViewerPage.razor - Begründung: UI für Log-Diagnose.
+Prüfidee:      Fehler produzieren → CSV-Eintrag mit Level WARN; Telemetrieupload schlägt fehl → Fehlermeldung „Telemetry upload to c-entron Office failed." ohne Funktionsausfall.
+Tracelinks:    SyRS-32, SyRS-33
+Konsolidierung: Kandidat: SyRS-32 (Logging in CSV, InMemory-Target und Datenbanktelemetrie parallel)
+Übernahmewürdigkeit: übernehmen - Voraussetzung für gewartete Kundeninstallation; Datenschutzprüfung erforderlich.
+Status:        belegt
+```
+
+```
+ID:            StRS-30
+Titel:         Deutschsprachige Bedienung mit zweiter Sprache
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Gebrauchstauglichkeit
+Akteur:        Mitarbeiter (DACH), zweisprachige Kunden
+Vorbedingung:  Client/Webservice installiert
+Fakt:          Vorgabe „All UI labels must be written in German" mit zweisprachiger Ressourcpflege (`LocalizedStrings.resx` Basis/Deutsch, `LocalizedStrings.en.resx` Englisch); Adress-/Artikeltexte sind landesabhängig modelliert (`ForeignArticleText` → `Table("ArtikelText")`, `AccountAddress.LanguageI3D`)
+Aussage:       Das System soll vollständig deutschsprachig bedienbar sein, Übersetzungen für Englisch bereitstellen und Geschäftspartner-/Artikeltexte je Land pflegbar halten.
+Ergebnis:      Oberflächen, Fehlermeldungen und Berichte erscheinen in der eingestellten Sprache; fremdsprachige Texte werden im Belegdruck verwendet.
+Belege:
+  - [SEKUNDÄR] docs/getting-started/general-structure.md („All UI labels must be written in German") - Begründung: verbindliche Sprachregel.
+  - [PRIMÄR]   src/backend/Centron.DAO/Mappings/Warehousing/ForeignArticleTextMaps.cs (`Table("ArtikelText")`) - Begründung: mehrsprachige Datenhaltung.
+  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs `GetForeignArticleTextForArticleByCountry` - Begründung: sprachabhängiger Textabruf.
+Prüfidee:      Umschaltung auf Englisch zeigt englische Labels; Artikel ohne englischen Text fällt auf Deutsch zurück.
+Tracelinks:    SyRS-34
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Marktanforderung; Übersetzungsworkflow im Ziel zentralisieren.
+Status:        belegt
+```
+
+```
+ID:            StRS-31
+Titel:         Telefonie-, Fernwartungs- und Mobilunterstützung im Arbeitsalltag
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service-Mitarbeiter, Außendienst, Support
+Vorbedingung:  TAPI-/Fernwartungs-Anbindung konfiguriert
+Fakt:          Anrufe werden als `PhoneCall` erfasst (`PhoneCallBL.CreatePhoneCall` mit `WasOutgoing/WasConnected`, Graph-Call-Records als Quelle) und über `TapiClientHub` mit `Task IncomingCall(...)` an Clients gemeldet; Fernwartung über Supremo (`SupremoSettingsController`, Token via `CryptoControl.EncryptToString`) und TeamViewer (`TestTeamViewerCommand`); MyDay-Arbeitsarten enthalten `Telephone, Travel, Break, Supremo, TeamViewer`; externe Zeiterfassung wird über `ImportMyDayWorkItems` importiert (Dedupe über `UniqueId`)
+Aussage:       Das System soll Anläufe aus der Telefonanlage, Fernwartungssitzungen und Fremd-Zeiterfassungen im persönlichen Tagescockpit und in der Zeiterfassung nutzbar machen.
+Ergebnis:      Anruf ist als Aktivität/Ticketbezug dokumentiert, Fremdzeiten sind duplikatfrei übernommen.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Tapi/PhoneCallBL.cs - Begründung: implementierte Anruferfassung.
+  - [PRIMÄR]   src/webservice/Centron.Host/RealTimeServices/TapiClientHub.cs - Begründung: Echtzeit-Verteilung der Anrufereignisse.
+  - [PRIMÄR]   src/backend/Centron.BL/MyDay/MyDayBL.cs (`ImportMyDayItems`) - Begründung: Import-/Dedupe-Logik.
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo/SupremoSettingsController.cs - Begründung: Fernwartungsanbindung im UI.
+Prüfidee:      Eingehender Call → Client-Popup + PhoneCall-Datensatz; identischer Import zweimal → keine Duplikate.
+Tracelinks:    SyRS-35, StRS-9
+Konsolidierung: Kandidat: StRS-9/SyRS-10 (Zeiterfassung aus vier Quellen: Ticket, MyDay, TAPI, Fremdimport)
+Übernahmewürdigkeit: Sonderfall - stark an Hersteller-Infrastruktur (TAPI-Interop-DLL, eigene Connector) gekoppelt; im Ziel auf Standard-Schnittstellen prüfen.
+Status:        belegt
+```

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Ergebnisse/Traceability.md

@@ -0,0 +1,149 @@
+# Traceability-Matrix
+
+Rückverfolgbarkeit aller 163 Anforderungen (31 StRS, 48 SyRS, 84 SwRS).
+
+- Zeilentyp A: jede SyRS mit ihrer übergeordneten StRS (SwRS-Spalte `–`).
+- Zeilentyp B: jede SwRS mit ihrer übergeordneten SyRS; die StRS-Spalte ist über die SyRS-Tracelinks hergeleitet.
+- `Artefaktbeleg` ist der PRIMÄR-Beleg der jeweils Kind-Anforderung (SyRS bzw. SwRS); bei Zeilentyp A der PRIMÄR-Beleg der SyRS.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+| --- | --- | --- | --- |
+| StRS-1 | SyRS-1 | – | src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs |
+| StRS-1 | SyRS-2 | – | src/centron/Centron.WPF.UI/Services/Logics/Accounts/ExtendedSearch/BLExtendedSearchLogic.cs |
+| StRS-2 | SyRS-3 | – | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-24 | SyRS-4 | – | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs |
+| StRS-3 | SyRS-5 | – | src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs |
+| StRS-4 | SyRS-6 | – | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-5 | SyRS-7 | – | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs |
+| StRS-6 | SyRS-8 | – | src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs |
+| StRS-8 | SyRS-9 | – | src/backend/Centron.DAO/Mappings/TemporaryEntities/GeraeteKopfMaps.cs |
+| StRS-9 | SyRS-10 | – | src/backend/Centron.DAO/Mappings/Sales/Support/HelpdeskTimerArea/HelpdeskTimerMaps.cs |
+| StRS-10 | SyRS-11 | – | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs |
+| StRS-11 | SyRS-12 | – | src/nexus/CentronNexus/Shared/Authorization/PortAuthorization.cs |
+| StRS-12 | SyRS-13 | – | src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs |
+| StRS-13 | SyRS-14 | – | src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs |
+| StRS-14 | SyRS-15 | – | src/backend/Centron.BL/EDI/SupplierEDI/SupplierEdiBL.cs |
+| StRS-15 | SyRS-16 | – | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs |
+| StRS-16 | SyRS-17 | – | src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs |
+| StRS-17 | SyRS-18 | – | src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs |
+| StRS-18 | SyRS-19 | – | src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs |
+| StRS-19 | SyRS-20 | – | src/backend/Centron.BL/CustomerArea/RmaBL.cs |
+| StRS-20 | SyRS-21 | – | src/backend/Centron.BL/Production/ProductionBL.cs |
+| StRS-21 | SyRS-22 | – | src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs |
+| StRS-22 | SyRS-23 | – | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-23 | SyRS-24 | – | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-23 | SyRS-25 | – | src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs |
+| StRS-26 | SyRS-26 | – | src/backend/Centron.DAO/Repositories/Sales/Customers/Assets/AssetHeadDAO.cs |
+| StRS-25 | SyRS-27 | – | src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs |
+| StRS-26 | SyRS-28 | – | src/backend/Centron.DAO/ChangeTracking/ChangeTrackingEventListener.cs |
+| StRS-27 | SyRS-29 | – | src/webservice/Centron.Host/CentronHost.cs |
+| StRS-28 | SyRS-30 | – | src/backend/Centron.BL/Administration/Scripts/ScriptEngineBL.cs |
+| StRS-28 | SyRS-31 | – | src/backend/Centron.Entities/Entities/Administration/Customization/ModuleCustomProperty.cs |
+| StRS-29 | SyRS-32 | – | src/webservice/Centron.Host.WindowsService/nlog.config |
+| StRS-28 | SyRS-33 | – | src/webservice/Centron.Host/CentronHost.cs |
+| StRS-30 | SyRS-34 | – | src/centron/Centron.WPF.UI/Resources/LocalizedStrings.resx |
+| StRS-10 | SyRS-35 | – | src/webservice/Centron.Host/RealTimeServices/NotificationsHub.cs |
+| StRS-25 | SyRS-36 | – | src/webservice/Centron.Host/CentronHost.cs |
+| StRS-29 | SyRS-37 | – | src/backend/Centron.BL/Administration/WebServiceConfiguration/WebServiceConfigSerializer.cs |
+| StRS-24 | SyRS-38 | – | src/backend/Centron.BL/Administration/WebServiceConfiguration/AdditionalService.cs |
+| StRS-29 | SyRS-39 | – | src/webservice/Centron.Host.WindowsService/CentronService.cs |
+| StRS-23 | SyRS-40 | – | src/centron/Centron.WPF.UI/Services/Container/Installers/Interceptors/CatchExceptionMakeErrorResultInterceptor.cs |
+| StRS-25 | SyRS-41 | – | src/backend/Centron.Common/ModuleFeatures.cs |
+| StRS-1 | SyRS-42 | – | src/backend/Centron.DAO/Mappings/TemporaryEntities/GeraeteKopfMaps.cs |
+| StRS-29 | SyRS-43 | – | src/backend/Centron.Common/DeveloperSecurity.cs |
+| StRS-23 | SyRS-44 | – | src/backend/Centron.BL/Administration/Logins/UsersBL.cs |
+| StRS-23 | SyRS-45 | – | src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs |
+| StRS-27 | SyRS-46 | – | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs |
+| StRS-29 | SyRS-47 | – | azure/build-pipeline.yml |
+| StRS-29 | SyRS-48 | – | Directory.Build.props |
+| StRS-1 | SyRS-1 | SwRS-1 | src/backend/Centron.BL/IndexSearch/IndexSearchBL.cs |
+| StRS-1 | SyRS-2 | SwRS-2 | src/centron/Centron.WPF.UI/Services/Container/ClassContainer.cs |
+| StRS-24 | SyRS-4 | SwRS-3 | src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs |
+| StRS-24 | SyRS-4 | SwRS-4 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-2 | SyRS-3 | SwRS-5 | src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs |
+| StRS-21 | SyRS-22 | SwRS-6 | src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs |
+| StRS-3 | SyRS-5 | SwRS-7 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-3 | SyRS-5 | SwRS-8 | src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs |
+| StRS-3 | SyRS-5 | SwRS-9 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs |
+| StRS-1 | SyRS-42 | SwRS-10 | src/backend/Centron.DAO/Mappings/Accounts/AccountMaps.cs |
+| StRS-30 | SyRS-34 | SwRS-11 | src/backend/Centron.BL/Accounts/AccountAddressBL.cs |
+| StRS-24 | SyRS-4 | SwRS-12 | src/backend/Centron.BL/Accounts/AccountBL.cs |
+| StRS-1 | SyRS-2 | SwRS-13 | src/backend/Centron.BL/Accounts/AccountBL.cs |
+| StRS-16 | SyRS-17 | SwRS-14 | src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs |
+| StRS-16 | SyRS-17 | SwRS-15 | src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs |
+| StRS-16 | SyRS-17 | SwRS-16 | src/backend/Centron.Entities/Entities/Warehousing/SerialNumber.cs |
+| StRS-8 | SyRS-9 | SwRS-17 | src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs |
+| StRS-16 | SyRS-17 | SwRS-18 | src/backend/Centron.Entities/Entities/Warehousing/StockManagement/Article.cs |
+| StRS-16 | SyRS-17 | SwRS-19 | src/backend/Centron.Entities/Entities/Warehousing/SecondaryStock.cs |
+| StRS-10 | SyRS-35 | SwRS-20 | src/backend/Centron.BL/NexusNotifications/NexusNotificationsBL.cs |
+| StRS-10 | SyRS-11 | SwRS-21 | src/backend/Centron.BL/MailScanner/MailScannerBL.cs |
+| StRS-10 | SyRS-11 | SwRS-22 | docs/features/automatic-helpdesk-creation-templates.md |
+| StRS-10 | SyRS-11 | SwRS-23 | src/backend/Centron.Entities/Entities/Sales/Support/Escalation/Escalations.cs |
+| StRS-10 | SyRS-11 | SwRS-24 | src/backend/Centron.Entities/Entities/ChecklistArea/CentronChecklistBase.cs |
+| StRS-10 | SyRS-35 | SwRS-25 | src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs |
+| StRS-10 | SyRS-11 | SwRS-26 | src/backend/Centron.Entities/Entities/ToDoArea/ToDo.cs |
+| StRS-10 | SyRS-11 | SwRS-27 | src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs |
+| StRS-10 | SyRS-35 | SwRS-28 | src/backend/Centron.BL/Chats/ChatBL.cs |
+| StRS-6 | SyRS-8 | SwRS-29 | src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/ContractKindBase.cs |
+| StRS-26 | SyRS-26 | SwRS-30 | src/backend/Centron.DAO/Repositories/Sales/Customers/Assets/AssetHeadDAO.cs |
+| StRS-1 | SyRS-42 | SwRS-31 | src/backend/Centron.DAO/Repositories/Sales/Receipts/SaveReceiptRepository.cs |
+| StRS-6 | SyRS-8 | SwRS-32 | src/backend/Centron.BL/Sales/Receipts/ContractLists/ContractSpecificLogic.cs |
+| StRS-8 | SyRS-9 | SwRS-33 | src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs |
+| StRS-8 | SyRS-9 | SwRS-34 | src/backend/Centron.BL/Devices/AccountDeviceBL.cs |
+| StRS-8 | SyRS-9 | SwRS-35 | src/backend/Centron.Entities/Entities/DocuBoard/AssetManagementArticleAssignment.cs |
+| StRS-23 | SyRS-25 | SwRS-36 | src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs |
+| StRS-27 | SyRS-29 | SwRS-37 | src/backend/Centron.BL/Centron.BL.csproj |
+| StRS-28 | SyRS-31 | SwRS-38 | src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs |
+| StRS-5 | SyRS-7 | SwRS-39 | src/backend/Centron.DAO/Mappings/Sales/Receipts/Invoices/Dunning/InvoiceDunningMaps.cs |
+| StRS-5 | SyRS-7 | SwRS-40 | src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs |
+| StRS-22 | SyRS-23 | SwRS-41 | src/backend/Centron.DAO/Mappings/Finances/Payments/IncomingPayments/IncomingPaymentMaps.cs |
+| StRS-21 | SyRS-22 | SwRS-42 | src/backend/Centron.Gateway/DataExchange/BookKeeping/DatevAscii/BookKeepingExportDatevAscii.cs |
+| StRS-15 | SyRS-16 | SwRS-43 | src/backend/Centron.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBL.cs |
+| StRS-15 | SyRS-16 | SwRS-44 | src/apis/Centron.Api.EbInterface/EbInterfaceLogic.cs |
+| StRS-29 | SyRS-37 | SwRS-45 | src/backend/Centron.Common/TextCoding/AESCryptoLogic.cs |
+| StRS-23 | SyRS-44 | SwRS-46 | src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs |
+| StRS-23 | SyRS-45 | SwRS-47 | src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs |
+| StRS-25 | SyRS-27 | SwRS-48 | src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs |
+| StRS-23 | SyRS-24 | SwRS-49 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-23 | SyRS-24 | SwRS-50 | src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs |
+| StRS-25 | SyRS-27 | SwRS-51 | src/webservice/Centron.Host/CentronHost.cs |
+| StRS-28 | SyRS-30 | SwRS-52 | src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ |
+| StRS-28 | SyRS-30 | SwRS-53 | src/webservice/Centron.Host/AspNetCore/HostedServices/DataQualityService.cs |
+| StRS-25 | SyRS-41 | SwRS-54 | src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs |
+| StRS-23 | SyRS-40 | SwRS-55 | src/centron/Centron.WPF.UI/App.xaml.cs |
+| StRS-29 | SyRS-48 | SwRS-56 | src/centron/Centron.WPF.UI/App.xaml.cs |
+| StRS-11 | SyRS-12 | SwRS-57 | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs |
+| StRS-11 | SyRS-12 | SwRS-58 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs |
+| StRS-12 | SyRS-13 | SwRS-59 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs |
+| StRS-12 | SyRS-13 | SwRS-60 | src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs |
+| StRS-13 | SyRS-14 | SwRS-61 | src/backend/Centron.BL/Administration/FileManagement/DocumentBL.cs |
+| StRS-1 | SyRS-2 | SwRS-62 | src/backend/Centron.BL/Sales/Receipts/SupplierReceiptDocuments/ScanSupplierReceiptDocument/PdfScanning/ |
+| StRS-23 | SyRS-25 | SwRS-63 | src/shared/Centron.Controls/ExcelExport/BaseExcelExportManager.cs |
+| StRS-2 | SyRS-3 | SwRS-64 | src/centron/Centron.WPF.UI/Services/Logics/MassUpdate/BLMassUpdateLogic.cs |
+| StRS-25 | SyRS-41 | SwRS-65 | src/webservice/Centron.WebServices.Core/Entities/Administration/ArtificialIntelligence/ArtificialIntelligenceApiType.cs |
+| StRS-25 | SyRS-36 | SwRS-66 | src/backend/Centron.BL/WebServices/Sales/CustomerAssets/CustomerAssetCompactWebserviceBL.cs |
+| StRS-24 | SyRS-38 | SwRS-67 | src/nexus/CentronNexus.Host/Program.cs |
+| StRS-11 | SyRS-12 | SwRS-68 | src/nexus/CentronNexus.OutlookAddIn/Manifest/Manifest.xml |
+| StRS-17 | SyRS-18 | SwRS-69 | src/apis/Centron.Api.Gls/CentronGlsConsts.cs |
+| StRS-29 | SyRS-39 | SwRS-70 | deployment/centron/CentronSetupProject/Product.wxs |
+| StRS-29 | SyRS-47 | SwRS-71 | tests/backend/Centron.Tests.BL/DataExchange/EDI/SaleInvoices/InvoiceZugferdBalanceMergeTests.cs |
+| StRS-24 | SyRS-4 | SwRS-72 | SSMS_DB_SCHEMA.sql |
+| StRS-29 | SyRS-32 | SwRS-73 | src/webservice/Centron.Host/CentronHost.cs |
+| StRS-10 | SyRS-35 | SwRS-74 | src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo/SupremoSettingsViewModel.cs |
+| StRS-24 | SyRS-38 | SwRS-75 | src/backend/Centron.BL/Integrations/EsCustomerGroupBL.cs |
+| StRS-10 | SyRS-11 | SwRS-76 | src/backend/Centron.BL/Processes/ProcessBL.cs |
+| StRS-22 | SyRS-23 | SwRS-77 | src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs |
+| StRS-17 | SyRS-18 | SwRS-78 | src/backend/Centron.BL/TradePool/TradePoolBL.cs |
+| StRS-30 | SyRS-34 | SwRS-79 | src/backend/Centron.BL/TextModuleArea/TextModuleBL.cs |
+| StRS-10 | SyRS-11 | SwRS-80 | src/backend/Centron.BL/Tags/TagsBL.cs |
+| StRS-3 | SyRS-5 | SwRS-81 | src/backend/Centron.BL/CountryArea/CountryBL.cs |
+| StRS-10 | SyRS-11 | SwRS-82 | src/backend/Centron.BL/Modules/ModuleCategoryBL.cs |
+| StRS-16 | SyRS-17 | SwRS-83 | src/backend/Centron.BL/Storage/StorageBL.cs |
+| StRS-29 | SyRS-48 | SwRS-84 | src/backend/Centron.BL/WebVersion/VersionBL.cs |
+
+## Vollständigkeit
+
+- 48/48 SyRS mit StRS-Anker (Spalte SwRS = `–`).
+- 84/84 SwRS mit SyRS-Anker und abgeleitetem StRS-Anker.
+- 31/31 StRS sind Ziel mindestens eines SyRS-Rückverweises.
+- Keine toten Tracelinks (alle referenzierten IDs existieren).

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Protokoll.md

@@ -0,0 +1,127 @@
+# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/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-03T15:14:28.3153953+02:00
+- **Endzeit:** 2026-09-03T16:35:24.8130428+02:00
+- **Dauer gesamt:** 01:20:53 (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):** `qwen/qwen3.8-flash-next`
+- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/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` = 7, `completed` = 7, `failed` = 0
+- **Rollen:** {"explore": 7}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 434.508 |
+| Output-Tokens | 164.404 |
+| Reasoning-Tokens | 43.824 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 118 |
+
+**Tokens gesamt: 14.449.968.** 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 | 31 | 19,0 % |
+| SyRS | 48 | 29,4 % |
+| SwRS | 84 | 51,5 % |
+| **Gesamt** | **163** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 44 | 27,0 % |
+| Daten | 41 | 25,2 % |
+| nicht-funktional | 35 | 21,5 % |
+| Sicherheit | 22 | 13,5 % |
+| Schnittstelle | 21 | 12,9 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 443 |
+| davon `PRIMÄR` | 324 (73,1 %) |
+| davon `SEKUNDÄR` | 95 (21,4 %) |
+| davon `KONTEXT` | 24 (5,4 %) |
+| Belege je Anforderung (Median) | 3 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 162 (99,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 129 | 79,1 % |
+| workaround | 19 | 11,7 % |
+| sonderfall | 7 | 4,3 % |
+| veraltet | 8 | 4,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 148 | 90,8 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 9,2 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 133 | 81,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 52 | 31,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (43 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 163 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 163 von 163 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9897e0b9ffeUwpfU46o6PGXwo`
+- **Werkzeugaufrufe:** 116 – {"bash": 42, "read": 12, "task": 7, "write": 10, "edit": 45}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 7
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-03T13:14:29.923672+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\Ergebnisse)
+[2026-09-03T13:14:30.047622+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T14:35:23.066636+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T14:35:24.712030+00:00] OpenCode export: Exporting session: ses_f9897e0b9ffeUwpfU46o6PGXwo
+[2026-09-03T14:35:24.785556+00:00] Ende: Exitcode=0; Status=success; Turns=118; Tokens=14449968; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\max\03_Lauf_2026-09-03_151428_v13.0.0-0354\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/anforderungen.md

@@ -0,0 +1,65 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 31 | 19,0 % |
+| SyRS | 48 | 29,4 % |
+| SwRS | 84 | 51,5 % |
+| **Gesamt** | **163** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 44 | 27,0 % |
+| Daten | 41 | 25,2 % |
+| nicht-funktional | 35 | 21,5 % |
+| Sicherheit | 22 | 13,5 % |
+| Schnittstelle | 21 | 12,9 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 443 |
+| davon `PRIMÄR` | 324 (73,1 %) |
+| davon `SEKUNDÄR` | 95 (21,4 %) |
+| davon `KONTEXT` | 24 (5,4 %) |
+| Belege je Anforderung (Median) | 3 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 162 (99,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 129 | 79,1 % |
+| workaround | 19 | 11,7 % |
+| sonderfall | 7 | 4,3 % |
+| veraltet | 8 | 4,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 148 | 90,8 % |
+| als `HYPOTHESE` gekennzeichnet | 15 | 9,2 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 133 | 81,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 52 | 31,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (43 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 163 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 163 von 163 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/combined_prompt.md

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

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-03T16:35:24.8130428+02:00

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/opencode-config.json

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

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/max/03_Lauf_2026-09-03_151428_v13.0.0-0354/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-03T15:14:28.3153953+02:00

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

@@ -10,7 +10,7 @@
 - **Endzeit:** 2026-09-02T13:11:01.6994339+02:00
 - **Dauer gesamt:** 00:19:03 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
 - **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
-- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
 - **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
 
 ## Werkzeugkonfiguration

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-03T12:55:53.171309+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\Ergebnisse)
+[2026-09-03T12:55:53.444214+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T13:14:26.157936+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T13:14:27.621337+00:00] OpenCode export: Exporting session: ses_f98a8e51fffe3QtphUN2xVQvN5
+[2026-09-03T13:14:27.668580+00:00] Ende: Exitcode=0; Status=success; Turns=82; Tokens=5736232; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/Analysebericht.md

@@ -0,0 +1,268 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Arbeitsverzeichnis = Spiegel des Repos CentronERP). Vorgehen: statische Analyse von Quellcode, Konfiguration, UI-Ressourcen und SQL-Schema; keine Ausführung, kein Datenbankzugriff. Ergebnis: 117 Anforderungen (StRS 13, SyRS 20, SwRS 84), 3 Hypothesen, 107 Dateien-/Code-Belege.
+
+Änderungsprotokoll der Codebasis war NICHT verfügbar: Das Repo liegt im Arbeitsverzeichnis als Spiegel ohne eigene Git-Historie; Commit-Messages/Tickets (Schritt 2, KonTEXT-Quellen) konnten daher nicht erhoben werden. `docs/` wurde als Ersatz-Kontextquelle genutzt.
+
+---
+
+## Schritt 0 – Modulinventar
+
+Erfassungsgrundlage: Verzeichnisstruktur `src/backend/Centron.BL` (86 Business-Module), `src/centron`, `src/webservice`, `src/nexus`, `src/apis`, `src/shared`, `src/backend/*` (Schichtprojekte), Projektwurzel-Artefakte. Fachlich eng verwandte BL-Ordner wurden zu einem fachlichen Modul zusammengefasst (in „Pfad“ ersichtlich); die Zusammenfassung ist bewusst konservativ (kein Ordner ohne Zuordnung).
+
+| # | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (ein Satz) |
+|---|---|---|---|
+| 1 | Adressstamm (Kunde/Lieferant/Kontakt) | src/backend/Centron.BL/Accounts | Typisierte Adressen inkl. Klassifikation, Herkunft, Verträge, Sonderpreise, Kampagnen und Aktivitäten. |
+| 2 | Vertrieb – Belegwesen | src/backend/Centron.BL/Sales/Receipts | Angebot bis Rechnung: 7 Belegarten mit Status, Lock, Versionen, Provisionen, Reports, ZUGFeRD. |
+| 3 | Mahnwesen | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning | Mahnläufe je Kunde mit Stufen, Reset und Konfiguration. |
+| 4 | E-Rechnung (ZUGFeRD/XRechnung) | src/backend/Centron.BL/DataExchange (Zugferd*), src/backend/Centron.BL/EDI/ZUGFeRD_BL.cs | Erzeugung und Parsen elektronischer Rechnungen inkl. Leitweg-ID. |
+| 5 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Barbuchungen mit Historie. |
+| 6 | Stundenzuschlagsätze | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Zuschlagsregeln für Dienstleistungszeiten inkl. Überlappungserkennung. |
+| 7 | Zeiterfassung / Servicezeiten | src/backend/Centron.BL/Time, Entities/Sales/Support/HelpdeskTimerArea | Zeiterfassung an Tickets inkl. Billing-Status und Signaturen. |
+| 8 | Kunden & CRM | src/backend/Centron.BL/Sales/Customers, CustomerArea (ohne RMA) | Kundenpflege, Kontaktformen, Anreden, CRM-Projekte, Kennzahlen. |
+| 9 | Marketing & Kampagnen | src/backend/Centron.BL/Sales/Marketing, Accounts/Campaigns | Kampagnenphasen, Entscheidungstexte, Umfragen (Survey). |
+| 10 | RMA (Rücksendungen) | src/backend/Centron.BL/CustomerArea/RmaBL.cs, WPF RMA | Warenrücksendung mit Artikelstatus und Ticketbindung. |
+| 11 | Helpdesk / Tickets (C-FLOW) | src/backend/Centron.BL/Sales/Support | Tickets, Status, Historie, Vorlagen, Kategorien, Abschluss, Mailbezug. |
+| 12 | Kundenanlagen / Assets (DocuBoard) | Sales/CustomerAssets, Devices, DocuBoard, Outlook | Anlagen/Geräte der Kunden inkl. Artikelzuordnung und Ticketlink. |
+| 13 | Artikelstamm | src/backend/Centron.BL/Warehousing (Artikelklassen) | Artikel inkl. System-/Sonderartikel, Serviceartikel, Stücklisten. |
+| 14 | Preiswesen | Warehousing (Action/Volume), Accounts (Sonderpreis), Sales/Receipts (PriceHelper) | Aktions-, Volumen-, Sonder- und Belegpreise. |
+| 15 | Lager & Inventur | Warehousing/InventoryManagement, Logistics, Storage | Lagerorte, Bestände, Inventuren, Kommissionierung. |
+| 16 | Einkauf | Purchasing, Buying, BusinessPartner | Bestellungen je Filiale, Bestellvorschläge, Distributoren. |
+| 17 | EDI | src/backend/Centron.BL/EDI | Distributorenbestellungen (Alltron, Also, Herweck, Komsa, Egis, OpenTrans) und Logs. |
+| 18 | Datenaustausch / Import-Export | src/backend/Centron.BL/DataExchange | DocBee, GfK, TANSS, RMM, Rechnung-Upload, Buchhaltungstransfer. |
+| 19 | Finanzen | Finances (+ src/apis/Centron.APIs.FinAPI) | Zahlungseingänge, Onlinebanking (FinAPI), Aktivitäts-/Aktiveneinstellungen. |
+| 20 | Buchhaltung | Accounting, Centron.Gateway/BookKeeping*, DataExchange/BookKeeping* | Kontierung und Export/Import (Abacus, Addison). |
+| 21 | Benutzer & Rechte | Administration/Rights, Logins/Users | Konten, Gruppen, Rechtsprüfung, WebAccount-Rechte. |
+| 22 | Authentifizierung & 2FA | Administration/Logins (Auth, TwoFactor), Core/CryptoUtils | Basic/AD/OIDC-Login, Fallback, 2FA (E-Mail/Radius), Geräte-Tickets. |
+| 23 | Lizenzwesen | Administration/Licensing, Interfaces LicenseGuids/ApplicationKind | GUID-Lizenzen mit Anzahl/Datum/Version, Login-/Feature-Schalter. |
+| 24 | Einstellungen | Administration/Settings, WebSuite (WebSetting*) | Geschichtete Konfiguration Benutzer/Firma/Web. |
+| 25 | Firma, Filialen, Datenschutz, MasterDB | Administration (Company, DataSecurity, CentronConfigDb, Masterdata) | Firmendaten, Filialen, DSGVO-Cleanup, Masterpasswort-Ablage. |
+| 26 | Hintergrunddienste & Wartung | Administration (BackgroundServices, Maintenance, SQLManagement, Scripts) | Geplante Dienste inkl. DataQualityService, DB-Pflege. |
+| 27 | Mitarbeiter | src/backend/Centron.BL/EmployeeArea | Personalstamm, Abteilungen, Urlaub, RFID-Tokens. |
+| 28 | Kalender / MyDay / MyCentron | Calendar, MyDay, MyCentron, AppointmentRequests, ExpectedEvents | Dashboard, Schnellnotizen, Kalender, Terminanfragen, Importe. |
+| 29 | Aufgaben, Checklisten, ToDo | TaskManager, CheckListArea, ToDoArea, Processes | Wiedervorlagen mit Aktions-Handlern, Checklisten-Vorlagen. |
+| 30 | E-Mail-Kommunikation | src/backend/Centron.BL/Mail | SMTP/EWS/Graph-Versand, Templates, Signaturen, Blacklist. |
+| 31 | MailScanner | src/backend/Centron.BL/MailScanner | Workflow-Verarbeitung eingehender Mails (u. a. Ticketanlage). |
+| 32 | Mailings | src/backend/Centron.BL/Mailings | Newsletter/Versandkampagnen mit Vorlagen. |
+| 33 | Chats | src/backend/Centron.BL/Chats | Interne Chat-Kommunikation. |
+| 34 | Benachrichtigungen | Notifications, NexusNotifications | User-Notifications inkl. SignalR-Hub in Nexus. |
+| 35 | Telefonie (TAPI) | src/backend/Centron.BL/Tapi, Administration/PhoneSettings | Anrufaufzeichnung und Telefonie-Integration. |
+| 36 | CPra | src/backend/Centron.BL/CPra | Konnektor zur externen Prüf-/Exportanwendung „c-pra“. |
+| 37 | Projekte | Projects, TicketProjects, CrmProject | Vorgangsprojekte inkl. Belegprojektnummern. |
+| 38 | Produktion / IT-Planer | Production, ItPlanner | Fertigungsaufträge mit Positionen, Log, Stücklisten. |
+| 39 | Reporting / Report-Engine | ReportEngine, Reporting | Layouts, Druckoptionen, Portal-Reports. |
+| 40 | Statistiken & Kennzahlen | src/backend/Centron.BL/Statistics | Vertriebs-/Ticket-/Rechnungsstatistiken mit Caches. |
+| 41 | Volltextsuche | src/backend/Centron.BL/IndexSearch | Objektübergreifende Indizierung und Suche. |
+| 42 | Kundenspezifische Felder | src/backend/Centron.BL/Customizations | Custom-Tables mit Variablenersetzung. |
+| 43 | Tags | src/backend/Centron.BL/Tags | Verschlagwortung von Objekten. |
+| 44 | WebLinks & URLs | WebLinks, Urls | Konfigurierbare Links mit Aktions-Handlern, Kurzlinks. |
+| 45 | Videoportal | src/backend/Centron.BL/VideoPortal | Videoportal-Zuweisungen an Zielgruppen. |
+| 46 | Social Media | src/backend/Centron.BL/SocialMedia | Netzwerkprofile von Kontaktpersonen. |
+| 47 | Gutscheine | src/backend/Centron.BL/VoucherManagement | Barcode-Gutscheine inkl. Einlösung. |
+| 48 | Self-Care | src/backend/Centron.BL/SelfCare | Kundenformulare mit Zuständen, C-FLOW-Sync. |
+| 49 | Externe Werkzeuge / Remote | ExternalToolsBL, ExternalHelpdesk, Tools | Remote-/Monitoring-Werkzeuge (WOASI, NAble, GFIMax) konfigurieren. |
+| 50 | TradePool | src/backend/Centron.BL/TradePool | XML-Import der Handelsplattform TradePool. |
+| 51 | Transaktionslog | src/backend/Centron.BL/Transactions | Systemtransaktionen mit Details. |
+| 52 | Änderungshistorie & Massenupdates | ChangeTracking, MassUpdate | Import-Historie, Massenänderungsvorlagen. |
+| 53 | Telemetrie | src/backend/Centron.BL/Telemetry | MCP-/Tool-Nutzungsmessung in Batches. |
+| 54 | KI-Integration | src/backend/Centron.BL/ArtificialIntelligence | LLM-Clients (OpenAI/Claude/Gemini/Mistral), Ticket-/Text-APIs. |
+| 55 | Riversuite/RiverDivo | RiverDivo, WebSuite, Integrations | Anbindung der Hersteller-Cloud (Monitoring, Inventory, Compliance …). |
+| 56 | Textbausteine | src/backend/Centron.BL/TextModuleArea | Wiederverwendbare Texte, Anreden, Variablen. |
+| 57 | Produktmatrix | src/backend/Centron.BL/ProductMatrix | Kunde-Produkt-Kategorien mit Ratings. |
+| 58 | Konnektordienste | src/backend/Centron.BL/Services | CTime-Personalzeiten, Directory-Checks, CachedTables. |
+| 59 | Systemtabellen | src/backend/Centron.BL/SystemArea | I3D-Reservierung der Systemtabellen. |
+| 60 | Externe Objektreferenzen | src/backend/Centron.BL/ObjectExternalReferences | Fremdsystem-Referenzen an Centron-Objekten. |
+| 61 | GUI-Profile / Icons / Themes / Start | GUI, Administration/Themes, CentronIcons, Start | Benutzerprofile, Grid-Einstellungen, Iconkatalog. |
+| 62 | Mobile | src/backend/Centron.BL/Mobile | Mobile-Client-Unterstützung (Tickets, Zeiten, Bilder). |
+| 63 | Modulkatalog | src/backend/Centron.BL/Modules | Selbstkatalogisierung der Module, Favoriten. |
+| 64 | Länder-/Bundeslandstamm | src/backend/Centron.BL/CountryArea | Referenzdaten Adressräume. |
+| 65 | Doku-Hilfe | DocumentationArea, Sales/DocumentationWizardArea | Interne kontextbezogene Dokumentation. |
+| 66 | Passwort-Tresor | PasswordManager, PasswordManagementArea | Anlagenpasswörter mit Zugriffshistorie. |
+| 67 | Client-Version / Update | src/backend/Centron.BL/WebVersion | Versionsführung/Updategrenzen der Clients. |
+| 68 | WPF-Client | src/centron/Centron.WPF.UI | Desktop-Anwendung (MVVM, ILogic-Container, Dialoge). |
+| 69 | UI-Controls/Extension | src/shared/Centron.Controls*, WPF.UI.Extension | Wiederverwendbare Steuerelemente. |
+| 70 | Entitätsmodell | src/backend/Centron.Entities | Datenobjekte/DTOs aller Domänen inkl. Statusmodelle. |
+| 71 | Datenzugriff (DAO) | src/backend/Centron.DAO | NHibernate-Mappings, GenericDAO, Repositories, NamedQueries. |
+| 72 | Webservice-Host & Verträge | src/webservice/* | Gehostete REST-/Session-API inkl. Login-Requests, DTOs. |
+| 73 | Nexus (Web) | src/nexus/* | Blazor-Web: ServiceBoard, WebCart/CustomerPortal, WebOffer, Signatur. |
+| 74 | API-Adapter extern | src/apis (8 Projekte) | GLS, Shipcloud, eBuddy, Cop, Egis, ICECAT, ITscope, FinAPI. |
+| 75 | docuFORM-API | Centron.Api.docuFORM | OAuth-Client für DMS docuFORM. |
+| 76 | Datenbank-Gesamtschema | SSMS_DB_SCHEMA.sql | 1.535 Tabellen mit Constraints/Views (Legacy + clean Views). |
+| 77 | Rechte-Katalog | CentronRights.md | Fachbeschreibung der Helpdesk-Berechtigungen. |
+| 78 | Deployment-Installer | deployment (WiX) | MSI-Pakete Client/Webservice, WixSharp. |
+| 79 | CI & Container | .github, azure, docker | Build-/Test-/Regressionsschienen, Dockerfiles, Azure-Pipelines. |
+| 80 | Build-Skripte | scripts | Build-/Paketier-Hilfsprogramme. |
+| 81 | Tests | tests | E2E-, Integrations-, Unit-, Playwright-, Nexus-Tests. |
+| 82 | Projektdokumentation | docs | Entwickler-/Architekturdokumentation (Analysequelle). |
+| 83 | Fremd-Assemblies | assemblies, nugets | Drittanbieter-Bibliotheken (DevExpress, NHibernate …). |
+| 84 | Utility-Helfer | Centron.BL/Helpers, Centron.Common, Centron.Core, Centron.Interfaces, WPF.UI.Extension | Querschnitts-Hilfsfunktionen ohne eigene Fachfunktion. |
+
+**Ergänzungsregeln:** Ordner `Exceptions` → Modul 11; `Gateway` (BL/CustomGateway) → Modul 20; `Core` → Modul 22/84; `CentronNexus` (BL) → Modul 73; `Integrations` → Modul 55; `Outlook` (AssetSearch) → Modul 12; `Reporting`/`ReportEngine` → Modul 39; `WebServices` (BL-Clientproxies, 464 Dateien) → Modul 72; `Merchandise`/`Import` (Entities) → Modul 70.
+
+---
+
+## Abdeckungstabelle (Schritt 0b)
+
+Bewertung: tief = Regeln/Constraints an Durchsetzungspunkten belegt und querverifiziert; mittel = Kernregeln belegt, Detailtiefe begrenzt; flach = Existenz + eine Hauptoperation belegt.
+
+| Modul | Einstufung | Anforderungen | IDs |
+|---|---|---|---|
+| 1 Adressstamm | tief | 2 | SwRS-01, SwRS-02 |
+| 2 Belegwesen | tief | 8 | SwRS-03–07, SwRS-14, SyRS-01, SyRS-07 |
+| 3 Mahnwesen | mittel | 2 | SwRS-08, SwRS-09 |
+| 4 E-Rechnung | tief | 2 | SyRS-09, SwRS-10 |
+| 5 Kassenbuch | flach | 1 | SwRS-11 |
+| 6 Stundenzuschläge | flach | 1 | SwRS-12 |
+| 7 Zeiterfassung | mittel | 1 | SwRS-13 |
+| 8 Kunden/CRM | mittel | 1 | SwRS-15 |
+| 9 Marketing/Kampagnen | flach | 2 | SwRS-16, SwRS-49 |
+| 10 RMA | flach | 1 | SwRS-17 |
+| 11 Helpdesk | tief | 3 | SwRS-18, SwRS-19, SwRS-20 |
+| 12 Kundenanlagen/Assets | mittel | 2 | SwRS-21, SwRS-22 |
+| 13 Artikelstamm | tief | 2 | SwRS-23, SwRS-24 |
+| 14 Preiswesen | mittel | 2 | SwRS-25, SwRS-26 |
+| 15 Lager/Inventur | mittel | 2 | SwRS-27, SwRS-28 |
+| 16 Einkauf | mittel | 1 | SwRS-29 |
+| 17 EDI | tief | 1 | SwRS-30 (plus SyRS-08) |
+| 18 Datenaustausch | mittel | 2 | SwRS-31, SwRS-32 |
+| 19 Finanzen | mittel | 2 | SwRS-33, SwRS-34 |
+| 20 Buchhaltung | mittel | 1 | SwRS-35 (plus SyRS-11) |
+| 21 Benutzer & Rechte | tief | 2 | SwRS-36, SwRS-37 (plus SyRS-03) |
+| 22 Authentifizierung/2FA | tief | 1 | SwRS-38 (plus SyRS-02, SyRS-05) |
+| 23 Lizenzwesen | tief | 1 | SwRS-39 (plus SyRS-04) |
+| 24 Einstellungen | flach | 1 | SwRS-40 |
+| 25 Firma/Filialen/Datenschutz/MasterDB | mittel | 2 | SwRS-41, SwRS-42 (plus SyRS-15) |
+| 26 Hintergrunddienste | flach | 1 | SwRS-43 [HYPOTHESE] |
+| 27 Mitarbeiter | mittel | 1 | SwRS-44 |
+| 28 Kalender/MyDay/MyCentron | flach | 1 | SwRS-45 |
+| 29 Aufgaben/Checklisten | mittel | 1 | SwRS-46 |
+| 30 E-Mail | mittel | 1 | SwRS-47 |
+| 31 MailScanner | flach | 1 | SwRS-48 |
+| 32 Mailings | flach | 1 | SwRS-49 |
+| 33 Chats | flach | 1 | SwRS-50 |
+| 34 Benachrichtigungen | flach | 1 | SwRS-51 |
+| 35 Telefonie | flach | 1 | SwRS-52 |
+| 36 CPra | flach | 1 | SwRS-53 [HYPOTHESE] |
+| 37 Projekte | flach | 1 | SwRS-54 |
+| 38 Produktion/IT-Planer | flach | 1 | SwRS-55 |
+| 39 Reporting | mittel | 1 | SyRS-14 |
+| 40 Statistiken | flach | 1 | SwRS-56 |
+| 41 Volltextsuche | flach | 1 | SwRS-57 |
+| 42 Custom Fields | flach | 1 | SwRS-58 |
+| 43 Tags | flach | 1 | SwRS-59 |
+| 44 WebLinks/URLs | flach | 1 | SwRS-60 |
+| 45 Videoportal | flach | 1 | SwRS-61 |
+| 46 Social Media | flach | 1 | SwRS-62 |
+| 47 Gutscheine | flach | 1 | SwRS-63 |
+| 48 Self-Care | flach | 1 | SwRS-64 |
+| 49 Externe Werkzeuge | flach | 1 | SwRS-65 |
+| 50 TradePool | flach | 1 | SwRS-66 |
+| 51 Transaktionslog | flach | 1 | SwRS-67 |
+| 52 Historie/Massenupdates | flach | 1 | SwRS-68 |
+| 53 Telemetrie | flach | 1 | SwRS-69 |
+| 54 KI-Integration | mittel | 1 | SwRS-70 |
+| 55 Riversuite/RiverDivo | flach | 1 | SwRS-71 |
+| 56 Textbausteine | flach | 1 | SwRS-72 |
+| 57 Produktmatrix | flach | 1 | SwRS-73 |
+| 58 Konnektordienste | flach | 1 | SwRS-74 |
+| 59 Systemtabellen | flach | 1 | SwRS-75 |
+| 60 Objektreferenzen | flach | 1 | SwRS-76 |
+| 61 GUI-Profile/Icons/Start | flach | 1 | SwRS-77 |
+| 62 Mobile | flach | 1 | SwRS-78 |
+| 63 Modulkatalog | flach | 1 | SwRS-79 |
+| 64 Länderstamm | flach | 1 | SwRS-80 |
+| 65 Doku-Hilfe | flach | 1 | SwRS-81 |
+| 66 Passwort-Tresor | mittel | 1 | SwRS-82 |
+| 67 Client-Version | flach | 1 | SwRS-83 |
+| 68 WPF-Client | mittel | 2 | SyRS-12, SyRS-20 |
+| 69 UI-Controls | flach | 1 | SyRS-12 (Mitbeleg) |
+| 70 Entitätsmodell | mittel | 2 | SwRS-03, SwRS-18 (Schlüssel-/Statusmodelle) |
+| 71 Datenzugriff DAO | mittel | 1 | SyRS-16 |
+| 72 Webservice | tief | 3 | SyRS-04, SyRS-06, SwRS-38 |
+| 73 Nexus | mittel | 2 | SyRS-13, SwRS-51 |
+| 74 API-Adapter | mittel | 2 | SyRS-17, SwRS-34 |
+| 75 docuFORM-API | flach | 1 | SwRS-84 |
+| 76 DB-Gesamtschema | tief | 1 | SyRS-16 (+Constraints in SwRS-01/07/15/17) |
+| 77 Rechte-Katalog | mittel | 1 | SyRS-03 (Belegquelle) |
+| 78 Deployment | flach | 1 | SyRS-18 |
+| 79 CI/Container | flach | 1 | SyRS-19 |
+| 80 Build-Skripte | **nicht analysiert** | 0 | Begründung: reine Build-/Paketierhilfen (RunHelper, WXSHelper), keine Systemanforderung eigenen Rechts; in SyRS-18/SyRS-19 erwähnt. |
+| 81 Tests | flach | 1 | SyRS-19 (Testinfrastruktur als Migrationsvermögen) |
+| 82 Projektdokumentation | **nicht analysiert** | 0 | Begründung: docs/ ist Analysequelle (KONTEXT-Belege), kein Systembestandteil. |
+| 83 Fremd-Assemblies | **nicht analysiert** | 0 | Begründung: Drittbinaries ohne einsehbaren Quellcode; nur als Lizenz-/Komponentenkontext erwähnt (DevExpress, NHibernate). |
+| 84 Utility-Helfer | **nicht analysiert** | 0 | Begründung: Querschnitts-Utility-Schichten ohne fachliche Eigenaussage; Inhalte in Belegen zahlreicher Anforderungen enthalten. |
+
+**Abdeckungsbilanz:** 84 Module, davon 80 mit ≥1 Anforderung (95,2 %), 4 als `nicht analysiert` (4,8 % – unter der 10-%-Schwelle). Einstufungen: **10 tief, 22 mittel, 48 flach, 4 nicht analysiert**.
+
+---
+
+## Konsistenzcheck
+
+1. **Doppelte IDs:** Keine. 13 StRS-, 20 SyRS-, 84 SwRS-IDs, alle eindeutig (skriptgeprüft).
+2. **Anforderungen ohne Beleg:** Keine – alle 117 Anforderungen führen ≥1 Beleg (Feldzähler: 13/20/84 `Belege:`).
+3. **Fehlende Übernahmewürdigkeit:** Keine – Feld in allen 117 Anforderungen ausgefüllt.
+4. **Tracelinks auf nicht existierende IDs:** Keine (alle referenzierten IDs aufgelöst; SyRS-06 und SyRS-13 werden als Ziel-Ebene für Portal-/Webmodule genutzt, die Querverweise zeigen auf existierende IDs).
+5. **Inhaltlich deckungsgleiche Anforderungen ohne Kennzeichnung:** 53 SwRS- und 7 SyRS-Anforderungen tragen einen Konsolidierungseintrag; die bekanntesten Duplikatfelder (drei Geräte-/Asset-Haltungen SwRS-21/22, Preisquellen SwRS-25/26/SyRS-07, Passwortbehandlung SwRS-36/37, Statistikcaches, EDI-Partials) sind markiert. Doppelzählungen über Ebenen (z. B. StRS-07/SyRS-03/SwRS-24) sind bewusst Tracelink- und keine Konsolidierungsfälle.
+6. **Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:**
+
+| ID | Titel | PRIMÄR-Beleg? | Sonstiges |
+|---|---|---|---|
+| StRS-06 | Lizenzmodell | ja (`Authenticator.cs:132`) | – |
+| StRS-07 | Berechtigungen | ja (`UserRightsExt.cs:18`) | – |
+| StRS-09 | E-Rechnung | ja (`ReceiptBL.cs:3273-3333`) | – |
+| StRS-12 | Compliance/Löschung | ja (`DataSecurityBL.cs:64,377`) | – |
+| SyRS-02 | Authentifizierung/Fallback | ja (`AuthenticatorFactory.cs:54-135`) | – |
+| SyRS-03 | Rechteprüfung | ja (`UserRightsExt.cs`, `AppRightsBL.cs:264-297`) | – |
+| SyRS-04 | Login-Lizenzprüfung | ja (`Authenticator.cs:68-150`) | – |
+| SyRS-05 | 2FA | ja (`BasicAuthenticator.cs:62`) | – |
+| SyRS-07 | Preismatrix | ja (`ReceiptPriceHelperBL.cs:65,122`) | Doku SEKUNDÄR |
+| SyRS-09 | E-Rechnungsdienst | ja (`InvoiceZugferdBL.cs`) | – |
+| SyRS-10 | Web-Account-Sicherheit | ja (`WebAccountBL.cs:56`) | – |
+| SyRS-15 | Löschkonzept | ja (`DataSecurityBL.cs:64,377`; `Authenticator.cs:169-172`) | – |
+| SwRS-03 | Belegstatus | ja (`ReceiptState.cs`, `ReceiptBL.cs:3273`) | – |
+| SwRS-07 | Provisionen | ja (DB-CHECK-Constraints) | – |
+| SwRS-08 | Mahnlauf | ja (`DunningRunBL.cs:49,495`) | – |
+| SwRS-09 | Auftragsperre nach Mahnung | **nein** | als `[HYPOTHESE]` gekennzeichnet (nur Schema-Felder) |
+| SwRS-10 | Leitweg-ID/ZUGFeRD | ja (`ReceiptBL.cs:3417-3438`) | – |
+| SwRS-11 | Kassenbuch | ja (`CashBookBL.cs:15`) | – |
+| SwRS-13 | Zeit-Unveränderlichkeit | ja (`HelpdeskTimerBillingState.cs`) | Rechte-Semantik SEKUNDÄR |
+| SwRS-14 | Zeiten→Beleg | ja (`ReceiptBL.cs:5295`) | – |
+| SwRS-24 | Artikelrechte | ja (`ArticleBL.cs:129`) | – |
+| SwRS-25 | Aktionspreise | ja (`ActionPriceBL.cs:26`) | Doku SEKUNDÄR |
+| SwRS-26 | Sonderpreise | ja (`AccountSpecialPriceBL.cs`) | – |
+| SwRS-32 | Upload/Duplikatprüfung | ja (`ReceiptBL.cs:5082,5095`) | – |
+| SwRS-33 | Zahlungseingang | ja (`IncomingPaymentBL.cs`, `ReceiptBL.cs:4902`) | – |
+| SwRS-34 | Onlinebanking FinAPI | ja (`FinApiClient.cs`, LicenseGuids) | – |
+| SwRS-36 | Benutzerverwaltung/SHA1 | ja (`UsersBL.cs:65,107`) | Sicherheitsmangel benannt |
+| SwRS-37 | WebAccounts | ja (`WebAccountBL.cs:56,415`) | – |
+| SwRS-38 | Login-Tickets | ja (`TicketBL.cs:169`) | – |
+| SwRS-41 | Filialberechtigungen | ja (`CustomerToBranchBL.cs`) | Rechte SEKUNDÄR |
+| SwRS-42 | Masterpasswort-Ablage | ja (`MasterPasswordSecureFileStorage.cs`) | – |
+| SwRS-65 | Remote-Werkzeuge | ja (`ExternalToolBL.cs:58`) | Lizenz SEKUNDÄR |
+| SwRS-71 | Riversuite-Loginzugriff | ja (`Authenticator.cs:68-82`) | – |
+| SwRS-82 | Passwort-Tresor | ja (`PasswordManagementBL.cs:17,32`) | – |
+| SwRS-83 | Versionsgrenze | ja (`Authenticator.cs:132,150`) | – |
+
+   Nur **SwRS-09** besitzt keinen PRIMÄR-Beleg und ist korrekt als `[HYPOTHESE]` geführt.
+7. **Abgleich Hypothesen.md ↔ Inline-Markierungen:** Übereinstimmung – `[HYPOTHESE]` markiert: SwRS-09, SwRS-43, SwRS-53; Hypothesen.md führt exakt diese drei und keine weiteren.
+
+---
+
+## Bekannte Lücken
+
+- **Change-Historie nicht zugänglich:** Kein git-Log des Quellrepos im Spiegel; Schritt 2 (Commit-Messages, Tickets, Release Notes) blieb leer – KONTEXT-Belege stammen ausschließlich aus `docs/`.
+- **WPF-Validierungsdetails:** Die Prüfung von Feldrechten in konkreten Dialog-Viewmodels wurde stichprobenartig (über Rechte-Konstanten), nicht flächendeckend verifiziert; daher Generalisierung in SyRS-03.
+- **Report-/Layout-Definitionen:** DevExpress-Reportlayouts (.repx/Ressourcen) wurden nicht im Detail analysiert; SyRS-14 stützt sich auf Constraints und Rechte.
+- **1.535 Tabellen, ~3.000 Constraints:** Nur stichprobenhaft extrahiert (Mahn-, Provisionen-, Aktivitäts-, Unique-Constraints); ein vollständiger DB-Requirement-Katalog wäre eine eigene Iteration.
+- **Nexus-Routing im Detail:** WebCart-/ServiceBoard-Seiten wurden strukturell erfasst; einzelne Razor-Komponentenregeln (Validierungen) sind nicht einzeln belegt.
+- **`WebRightsVisibility`-Semantik der Kategorien 6000/6500:** Lizenzabhängigkeit („Only show if customer has a web cart2 license“) nur als Kommentar belegt.
+
+---
+
+## Selbstbewertung
+
+- **Modulanalyse gesamt:** 84 Module → **10 tief / 22 mittel / 48 flach / 4 nicht analysiert** (absolute Zahlen).
+- **Mindestabdeckung:** erreicht für 80 von 84 Modulen (95,2 %). Fehlend (4): Build-Skripte, Projektdokumentation, Fremd-Assemblies, Utility-Helfer – jeweils mit Begründung im Inventar; Anteil 4,8 % < 10 % Schwelle.
+- **Dünne Belegstellen:** Höchster SEKUNDÄR/KONTEXT-Anteil bei (a) SwRS-43 Hintergrunddienst (nur Doku + Ordner), (b) SwRS-53 CPra (nur Auth-Methode + Lizenz-Konstante), (c) SyRS-18 Deployment (nur Projektdateien/Pipelines), (d) Doku-abgeleitete Regeln in SyRS-12/SyRS-14 (Architekturdoku mit Code-Gegenprüfung). Diese Anforderungen sind bewusst nicht als Hypothese markiert, wo Code-Gegenbelege (Dockerfiles, WiX-Projekte, Report-Constraints) die Aussage zusätzlich tragen.
+- **Hypothesen:** 3 geführt (SwRS-09, SwRS-43, SwRS-53) – vollständig in Hypothesen.md; eine analyse ohne offene Punkte wäre bei 26.000 Dateien unplausibel.
+- **Nachschlag-Empfehlungen für die Folgeiteration:** (1) Vollständige Constraint-Extraktion des Schemas als Datenqualitätsanforderungen; (2) Lokalisierung der Auftragsperren-Durchsetzung (SwRS-09 auflösen); (3) CPra-Datenfluss rekonstruieren (SwRS-53); (4) WPF-Viewmodel-Rechtsprüfungen systematisch abgleichen; (5) Nexus-Razor-Validierungen und WebCart-Bestellstrecke vertiefen; (6) die im Feld `Konsolidierung` markierten Parallelhaltungen (Asset-Triple, Preisquellen, Passwort-/Token-Duplikate, EDI-Partials, Statistiken) zu einem Ziel-Architekturvorschlag bündeln.

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/Glossar.md

@@ -0,0 +1,45 @@
+# Glossar
+
+Domänenbegriffe, die in den Anforderungen verwendet werden, mit Definition aus der Codebasis.
+
+| Begriff | Definition (abgeleitet aus Artefakten) |
+|---|---|
+| **Beleg** | Verkaufsvorgang mit Kopf (`*Kopf`) und Positionen (`*Pos`): Angebot (Ang), Auftrag (Auf), Lieferschein (Lief), Rechnung (Rech), Vertrag (Vertrag), Gutschrift (Gut), Abholeliste (Abhol). Basis: `ReceiptBase`/`ReceiptState`. |
+| **I3D** | Systemweiter Primärschlüssel („ID 3develop“), `int IDENTITY(1,1)` in jeder Tabelle; Fremdschlüssel enden auf `I3D` (docs/guides/database/database-conventions.md). |
+| **CentronObjectKindNumeric** | Zentraler Zahlenenum, der jeden Objekttyp (Belegarten, Kunden, Tickets …) eindeutig identifiziert; Used in Filter-/Trace-APIs. |
+| **C-FLOW** | Produktname des Helpdesk-/Ticketmoduls (Tickets, Vorlagen, Kategorien); Rechte `UserRightsConst.Sales.Customer.Helpdesk.CFlow.*`. |
+| **Helpdesk / Ticket** | Kundenanliegen mit konfigurierbaren Statuszuständen (`HelpdeskState`), Bearbeitern, Prioritäten, Zeiten und Vorlagen. |
+| **Ticketzeit / Timer** | Arbeitszeitbuchung auf einem Ticket (`HelpdeskTimer*`), abrechnungssteuernd über `HelpdeskTimerBillingState`; mit Zuschlagsätzen und Signaturen. |
+| **Preismatrix** | Mehrquellige Preisauskunft je Artikel/Belegposition: Kunden-Sonderpreis, Aktionspreis (zeitlich befristet, `HerstellerArtikAktionspreis`), Volumenpreis, Standardpreis (docs/reference/receipts/actionprice-system.md). |
+| **Aktionspreis** | Zeitlich befristeter Distributor-/Hersteller-Aktionspreis mit `GueltigAb`/`GueltigBis` (ActionPriceBL). |
+| **Sonderpreise** | Kundenindividuelle Preisliste (`AccountSpecialPriceBL`); Grundlage des Web-Cart-Angebots (README.md). |
+| **Mahnlauf** | Nummerngeführter Sammelvorgang, der fällige Rechnungen nach kundenspezifigen `MahnungNachTagen(1..3)` in Mahnstufen hebt; stornierbar (`ResetDunningRun`, `DunningRunState`). |
+| **Kassenbuch** | Journal für Bar-Ein-/Ausgangsbuchungen (`CashBookBL.SaveCashBookBooking`) mit Historie. |
+| **Leitweg-ID** | Empfängerkennzeichnung der öffentlichen Verwaltung für E-Rechnungen; je Kunde bzw. Konzerngruppe gepflegt (`AccountCustomer.LeitwegID`). |
+| **ZUGFeRD / XRechnung** | Deutsche E-Rechnungsformate (PDF-Hybrid bzw. XML); Implementierung `InvoiceZugferdBL`, Spezifikationen 2.x im Repo. |
+| **EDI** | Elektronischer Datenaustausch mit Distributoren (Alltron, Also, Also-CH, Herweck, Komsa, Egis, OpenTrans) mit Dispatch und Log (`SupplierEdiBL.*`, `EDILogBL`). |
+| **Web-Account** | Externer Portal-Benutzer einer Kundenadresse (`WebAccountBL`) mit eigenem, per Allowlist begrenztem Rechtesatz; Login-Typ für Web-Cart/ServiceBoard. |
+| **Web-Cart** | B2B2C-Shop in Nexus; zeigt Artikel aus den Sonderpreisen des Kunden; Rechte 62001/62002. |
+| **ServiceBoard (SBO)** | Web-/Mitarbeiterportal für Helpdesk-Arbeit in Nexus inkl. Kanban, Scheduler, Passwortmanager; Lizenz `ServiceBoard`/-Web-Dev. |
+| **SelfCare** | Kunden-Selbstbedienungsformulare mit Zuständen und C-FLOW-Rückmeldung (`SelfCareBL`). |
+| **Filiale (Branch)** | Mandanteninterne Niederlassung mit Datenbezug (`BranchI3D`) und einschränkenden Rechten („nur eigene Filiale“); eigene Lizenz-GUID. |
+| **Mandant/Kunde** | Im Prompt-Sinn: Installation/Kunde mit eigenem Lizenzdatensatz; funktionaler Mandantenbegriff existiert als „Konzerngruppe/Filiale“ auf Datenobjektebene. |
+| **Konzerngruppe** | Kundenhierarchie (Mutterkunde); beeinflusst u. a. Leitweg-ID-Ermittlung (`GetCompanyGroupCustomerI3DForReceiptData`). |
+| **Rechte / UserRightsConst** | Zentrale Rechts-ID-Konstanten (Gruppenzuordnung über `AppGroupRightAssignment`); Admin-Gruppe „Administratoren“ hebt Prüfungen. |
+| **Lizenz (LicenseGuids)** | GUID-basierte Lizenz pro Produkt/Feature mit Anzahl, Gültigkeitsdatum und Versionsgrenze; geprüft beim Login (`LicenseManager.CheckLicense`). |
+| **ApplicationKind** | Katalog der loginfähigen Anwendungen (c-entron.NET, Nexus, ServiceBoard, Riversuite-Apps …) inkl. Rechten und Ablaufverhalten (`ExpirationKind`). |
+| **Login-Ticket** | Nach Login ausgestellte, an Anwendung+Benutzer+Maschine gebundene Sitzung (`TicketBL`, `CryptoUtils.CreatePasswordHash(deviceId, salt)`). |
+| **BLLogic/WSLogic** | Zweigleisiger Client-Datenzugriff: direkte Datenbank (`BL*Logic`) oder Webservice (`WS*Logic`) hinter einer `ILogic`-Schnittstelle (general-structure.md). |
+| **Result/BLSession** | Durchgängiges Fehler-/Transaktionsmuster: `Result<T>` als Rückgabewert, `BLSession` als Geschäftslogik-Sitzung. |
+| **Riversuite / Riverbird** | Hersteller-Cloud-Suite (Monitoring, Inventory, Compliance, RFlow …); Anbindung über `RiverConnectionBL` mit eigenen Login-Rechten. |
+| **DocuBoard** | Anlagen-/Dokumentationsmodul inkl. Asset-Management (`AssetManagement*BL`) und Riversuite-Asset-Services. |
+| **Asset / Anlagenstammblatt** | Anlage eines Kunden; aktuell getrennt gehalten als „Stammblätter“ (z. B. Drucker), „Assets“ und `AccountDevice` → Konsolidierungskandidat (SwRS-21/22). |
+| **MyDay** | Persönlicher Tages-/Importbereich inkl. konfigurierbarer Importe aus Fremdtools (anzahl-lizenziert). |
+| **MailScanner** | App, die Eingangspostfächer nach Workflows verarbeitet (u. a. automatische Ticketanlage). |
+| **Provision (ReceiptProvision…)** | Mitarbeiterbeteiligung an Belegen nach Schema mit Empfängertypen (`CustomerAdviser1..6`, `ReceiptAdviser1/2`, `ServiceArticleEmployee`, `FixedEmployee`), Quellen und Zielen. |
+| **RMA** | Warenrücksendungsprozess mit Artikelstatus und optional eindeutiger Ticketbindung (`CI_RMA_HelpdeskI3D`). |
+| **TradePool** | Handelsplattform-Import (XML) für Gebraucht-/Fremdware (`StartTradeImport`). |
+| **CPra** | Externe Anwendung „c-pra“ mit eigener Lizenz und Konnektor; fachlicher Zweck unklar → Hypothese SwRS-53. |
+| **FinAPI** | Online-Banking-API-Adapter (ersetzt abgelöstes HBCI/FinTS, LicenseGuids-Kommentar 2509). |
+| **DMS (DocBee, docuFORM)** | Dokumentenmanagementsysteme mit eigenen Konnektoren (`DocBee*`, `Centron.Api.docuFORM`). |
+| **Stammblatt** | Historische Bezeichnung für Anlagen-/Gerätestammdaten (im Prompt-Beispiel: Drucker); synonym zu Asset im Zielsystem. |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/Hypothesen.md

@@ -0,0 +1,23 @@
+# Hypothesen
+
+Sammlung aller Anforderungen, die in StRS.md/SyRS.md/SwRS.md mit `[HYPOTHESE]` markiert sind. Weitere offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
+
+---
+
+## SwRS-09 – Auftragsperre nach Mahnstufe
+- **Status:** HYPOTHESE
+- **Bislang belegt:** Datenbankschema enthält die Steuerungsfelder `Kunden.AuftragsperreNachMahnung` (SSMS_DB_SCHEMA.sql:2947) und `RechKopf.MahnStop`/`Kunden.MahnStop` (Zeile 3274). Der Feldname legt eine Sperrlogik nahe.
+- **Offene Frage:** An welcher Stelle (BL/Client/DB-Trigger) wird die Sperre beim Anlegen oder Freigeben eines Auftrags tatsächlich geprüft? Im untersuchten Business-Layer wurde kein Durchsetzungspunkt gefunden; die Prüfung könnte im WPF-ViewModel, in einem Stored Procedure oder in einer nicht mitgelieferten Komponente liegen.
+- **Fehlende Information:** Zugriff auf die WPF-Validierungslogik der Auftragsanlage im Detail bzw. Volltextsuche nach `Auftragsperre` in allen Projektlagen war nur auszugsweise möglich.
+
+## SwRS-43 – Hintergrunddienste (Data Quality)
+- **Status:** HYPOTHESE
+- **Bislang belegt:** Modulordner `src/backend/Centron.BL/Administration/BackgroundServices` existiert; `docs/Background Service/DataQualityService.md` beschreibt einen DataQualityService.
+- **Offene Frage:** Welche konkreten Datenqualitätsregeln laufen zeitgesteuert, und gibt es weitere Hintergrunddienste (z. B. Indizes, Cache-Statistiken als Dienst)? Die Klassennamen und Zeitpläne des Dienstes wurden nicht im Detail gelesen.
+- **Fehlende Information:** Implementierungsdetails/Konfiguration des Dienstes (Frequenz, Regelkatalog).
+
+## SwRS-53 – CPra-Konnektor (Audit-/Exportanbindung)
+- **Status:** HYPOTHESE
+- **Bislang belegt:** `CPraConnectorBL.ConnectToCPra(username, password)` und `CPraConfigurationSettingsBL` existieren; eine eigene Anwendungslizenz `ExternalAppCPra("c-pra")` ist im Login-System registriert.
+- **Offene Frage:** Welchen fachlichen Zweck erfüllt „c-pra“ konkret (GoBD-/Betriebsprüfungsexport nach AO-Dataportformat, Kassen-TSE-Anbindung oder Buchhaltungs-Frontend)? Der Code belegt nur den Authentifizierungsvorgang, nicht den Datenumfang.
+- **Fehlende Information:** Dokumentation oder Schnittstellenvertrag des Externprodukts c-pra; die Aufrufliste der Connector-Methoden wurde nur teilweise gelesen.

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/StRS.md

@@ -0,0 +1,278 @@
+# StRS – Stakeholder Requirements Specification
+
+Quelle: Reverse Requirements Engineering der c-entron ERP-Suite (c-entron.NET).
+Kontext: Das Produkt ist ein lizenziertes, mandantenfähig eingesetztes ERP-/Warenwirtschaftssystem für IT-Systemhäuser und Handels-/Servicebetriebe (Handel mit Artikeln und Dienstleistungen, Helpdesk/C-FLOW, Abrechnung, Lager, EDI-Anbindung an Distributoren). Akteure wurden aus Berechtigungskonstanten (`UserRightsConst`), Anwendungslizenzen (`ApplicationKind`) und Rollenbezeichnungen der Codebasis abgeleitet.
+
+---
+
+ID:            StRS-01
+Titel:         Durchgängiger Vertriebsprozess vom Angebot bis zur Rechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Vertriebssachbearbeiter, Kunde
+Vorbedingung:  Kunde und Artikelstamm vorhanden.
+Fakt:          Das System führt sieben Belegarten mit Kopftabellen `AngKopf/AufKopf/LiefKopf/RechKopf/VertragKopf/GutKopf/AbholKopf` und Positionstabellen (`*Pos`) samt Versions- und Progressionstabellen (`ReceiptProgressionBL`, `ForwardReceipt`, `CopyReceipt`).
+Aussage:       Das soll den kompletten Vertriebsprozess (Angebot → Auftrag → Lieferschein → Rechnung; zusätzlich Vertrag, Gutschrift, Abholeliste) mit Umwandlung, Kopie und Nachverfolgung der Belegkette abbilden.
+Ergebnis:      Aus jedem Beleg kann der Folgeberleg erzeugt werden; die Belegkette ist lückenlos rückverfolgbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:1377,1548` (CopyReceipt, ForwardReceipt) - die Umwandlungs-/Kopiervorgänge sind hier implementiert.
+  - [SEKUNDÄR] `docs/reference/receipts/receipts-backend-architecture.md` (Tabelle der Belegarten und Tabellenzuordnung) - beschreibt die sieben Belegarten.
+Prüfidee:      Aus einem Angebot einen Auftrag erzeugen; Auftragskopf verweist per Progression auf das Angebot.
+Tracelinks:    SyRS-01, SwRS-03, SwRS-05, SwRS-06
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion eines ERP, fachlich unverändert benötigt.
+Status:        belegt
+
+---
+
+ID:            StRS-02
+Titel:         Helpdesk-/Ticketverwaltung (C-FLOW) für Service und Support
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Servicemitarbeiter, Kundenbetreuer, Endkunde (via ServiceBoard/SelfCare)
+Vorbedingung:  Kunde mit Supportbeziehung ist angelegt.
+Fakt:          Modul `Sales/Support` mit `HelpdeskBL`, `HelpdeskCloseBL`, `HelpdeskState` (Statuszustände als Datenobjekt mit Icon, Deaktivierung, ServiceBoard-Farbe), Ticketzeiten (`HelpdeskTimer*`), Vorlagen und Checklisten.
+Aussage:       Das System soll Kunden-Tickets mit konfigurierbaren Statuszuständen, Bearbeiterzuweisung, Prioritäten, Kategorien, Laufzeit-Erfassung und Kundenkommunikation verwalten.
+Ergebnis:      Tickets von der Anlage bis zum Abschluss inkl. Zeiterfassung und Kunde-Sicht durchlaufbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Entities/Entities/CustomerArea/Support/HelpdeskState.cs:7-14` (Status als konfigurierbare Entität inkl. ServiceBoardWebColor) - Statusverwaltung ist datengetrieben implementiert, nicht hartcodiert.
+  - [SEKUNDÄR] `CentronRights.md` Abschnitt Helpdesk (Rechte für Anlegen/Bearbeiten/Abschließen/Zeiten) - beschreibt die fachlichen Bedienmöglichkeiten.
+Prüfidee:      Ticket anlegen → Statuswechsel → Abschluss mit Benachrichtigung; Statusliste ohne DB-Änderung per Konfiguration erweiterbar.
+Tracelinks:    SyRS-13, SwRS-18, SwRS-19, SwRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Service-Modul des Produkts.
+Status:        belegt
+
+---
+
+ID:            StRS-03
+Titel:         Zeiterfassung mit direkter Weiterberechnung an den Kunden
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Servicetechniker, Disponent
+Vorbedingung:  Ticket mit Zeiteintrag vorhanden.
+Fakt:          `HelpdeskTimerBillingState`, `CreateNewReceiptForHelpdekTimers(...)` erzeugt aus Ticketzeiten einen Beleg; Rechte `MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` gelten nur, „if the ticket is not part of a receipt“ (CentronRights.md).
+Aussage:       Das System soll erfasste Serviczeiten und Serviceartikel abrechnungsreif in Verkaufsbelege überführen und einmal abgerechnete Zeiten vor Verschieben/Löschen schützen.
+Ergebnis:      Abgerechnete Zeiten sind unveränderlich; nicht abgerechnete Zeiten sind abrechnungsreif.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5295` (`CreateNewReceiptForHelpdekTimers(IList<int> timerI3Ds, TimerBillingSetti…`) - die Überführungsregel ist dort implementiert.
+  - [SEKUNDÄR] `CentronRights.md` Punkte 8/9 (Zeiten verschieben/löschen „only if the ticket is not part of a receipt“) - Formulierungen der Schutzregel.
+Prüfidee:      Der Versuch, eine Zeit mit verknüpfter Rechnung zu verschieben, schlägt fehl.
+Tracelinks:    SyRS-01, SwRS-12, SwRS-13, SwRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kern der Dienstleistungsabrechnung.
+Status:        belegt
+
+---
+
+ID:            StRS-04
+Titel:         Artikel- und Preiswirtschaft für Handel mit Fremdware
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Einkauf, Vertrieb
+Vorbedingung:  Distributoren-/Herstellerstämme gepflegt.
+Fakt:          `ActionPriceBL.GetActionPricesByArticleI3D`, Tabelle `HerstellerArtikAktionspreis` mit GueltigAb/GueltigBis/Distributor, `ArticleVolumePricesBL`, `AccountSpecialPriceBL`; Fremdartikelsucher für Egis/ITscope/ICECAT (`src/apis`).
+Aussage:       Das System soll Einkaufs-, Aktions-, Volumen- und Kunden Sonderpreise verwalten und Fremdartikel über Distributor-Schnittstellen suchen und übernehmen können.
+Ergebnis:      Bei Belegerfassung wird der fachlich passende Preis (Aktionspreis im Gültigkeitszeitraum, Kunden-Sonderpreis, Volumenpreis) verfügbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs:26` (GetActionPricesByArticleI3D) - Aktionspreis lookup implementiert.
+  - [SEKUNDÄR] `docs/reference/receipts/actionprice-system.md` (Tabellenstruktur `HerstellerArtikAktionspreis`, Integration in Preismatrix) - kontextliche Beschreibung.
+Prüfidee:      Artikel mit Aktionspreis (heute gültig) im Auftrag: Aktionspreis wird in der Preismatrix angezeigt.
+Tracelinks:    SyRS-07, SwRS-25, SwRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - wettbewerbsentscheidende Kernfunktion.
+Status:        belegt
+
+---
+
+ID:            StRS-05
+Titel:         EDI-Anbindung an Distributoren für Bestellabwicklung
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:         Einkauf (im Backend), Distributoren (Alltron, Also, Herweck, Komsa, Egis, Concerto, OpenTrans)
+Vorbedingung:  Lieferant mit EDI-Konfiguration angelegt.
+Fakt:          `SupplierEdiBL.Alltron/Also/Herweck/Komsa/Opentrans.cs`, `EDIDispatcherBL`, `EDILogBL`, `EgisWarenkorbBL` (Modul `Centron.BL/EDI`); `docs/reference/edi/edi-architecture.md`.
+Aussage:       Das System soll Bestellungen aus Aufträgen automatisch im je Lieferant korrekten EDI-Format übermitteln und die Übermittlung protokollieren.
+Ergebnis:      Bestellung geht ohne medienbruch an den Distributor; jeder Vorgang ist im EDI-Log nachvollziehbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/EDI/Dispatch/SupplierEdiBL.cs` und Partials für Alltron/Also/Herweck/Komsa/Opentrans - Implementierung der formatspezifischen Versandlogik.
+  - [SEKUNDÄR] `docs/reference/edi/edi-architecture.md` - Architekturbeschreibung des EDI-Systems.
+Prüfidee:      Testbestellung an Sandbox-Lieferant; Eintrag in `EDILog` mit State.
+Tracelinks:    SyRS-08, SwRS-30
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - ohne EDI wäre der Einkaufsprozess nicht automatisierbar.
+Status:        belegt
+
+---
+
+ID:            StRS-06
+Titel:         Mandanten-/Kundenlizenzmodell für Funktionen und Zusatzprodukte
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:         Hersteller (NEXOWARE), Kunde
+Vorbedingung:  Lizenzdaten liegen vor.
+Fakt:          Lizenzprüfung über `LicenseManager.Instance.HasLicense(LicenseGuids.*)`; `LicenseGuids.cs` zählt Dutzende Produkt-/Feature-GUIDs; `ApplicationKind.cs` listet Anwendungen mit `count`, `ExpirationKind` und optionalen Rechten (`requiredRight`, `disallowingRight`).
+Aussage:       Das System soll Funktionsumfang und Login-Zulassung steuerbar über ein GUID-basiertes Lizenzmodell (Anzahl, Gültigkeitsdatum, gültige Version) pro Kunde abbilden.
+Ergebnis:      Ohne Lizenz sind Modul/Login gesperrt; Lizenzgrenzen werden beim Login erzwungen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:132` (`LicenseManager.CheckLicense(applicationKind, appVersion, userResult)`) - durchgesetzte Login-Lizenzprüfung.
+  - [SEKUNDÄR] `docs/reference/security/licensing-system.md` - Beschreibung des Lizenzmodells.
+Prüfidee:      Login mit Application-Key ohne Lizenz → Fehler „No license …“.
+Tracelinks:    SyRS-04, SwRS-39
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Geschäftsmodell des Herstellers.
+Status:        belegt
+
+---
+
+ID:            StRS-07
+Titel:         Rollen- und berechtungsgetragene Datensicht
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:         Administrator, Fachanwender
+Vorbedingung:  Benutzer und Berechtigungsgruppen gepflegt.
+Fakt:          `UserRightsExt.HasUserRight(AppUser,int)` (UserRightsExt.cs:18) delegiert an `AppRightsBL.HasUserRight`; `CentronRights.md` beschreibt einschränkende Rechte („only own tickets“, „only own branch“); `UserRightsConst.cs` mit tausenden Rechte-IDs.
+Aussage:       Das System soll jede Funktion und gefilterte Datensichten über ein zentrales, gruppenbasiertes Rechtesystem steuerbar machen.
+Ergebnis:      Ohne Recht ist Funktion gesperrt; einschränkende Rechte begrenzen Daten auf eigene Objekte/Filialen.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs:18-30` (HasUserRight → AppRightsBL) - zentrale Durchsetzung.
+  - [SEKUNDÄR] `CentronRights.md` (Semantik der Helpdesk-Rechte) - fachliche Bedeutung.
+Prüfidee:      Benutzer ohne `ADD_NEW_HELPDESK` kann kein Ticket anlegen.
+Tracelinks:    SyRS-02, SyRS-03, SwRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Grundvoraussetzung für Mehrbenutzung.
+Status:        belegt
+
+---
+
+ID:            StRS-08
+Titel:         Zahlungseingang, Mahnwesen und Forderungsmanagement
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Buchhaltung, Kreditorenbuchhaltung
+Vorbedingung:  Offene Rechnungen vorhanden.
+Fakt:          `DunningRunBL.GetDunningRuns/ResetDunningRun`, Kundenfelder `MahnungNachTagen(1..3)`, `AuftragsperreNachMahnung`, `MahnStop`; Rechnungsfelder `Mahnung1Datum…Mahnung3Datum`, `MahnStop` (SSMS_DB_SCHEMA.sql:2904,2947,3268); `IncomingPaymentBL` (Finances/IncomingPayments).
+Aussage:       Das System soll Zahlungseingänge erfassen, offene Rechnungen in konfigurierbaren Mahnstufen mahnen und optional Auftragsperren je Kunde ableiten.
+Ergebnis:      Mahnläufe sind reproduzierbar/stornierbar; Mahnstand je Kunde und Rechnung sichtbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs:49,495` - Mahnlauf-Erzeugung und Reset implementiert.
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql:2904-2906,2947,3268-3274` (MahnungNachTagen, AuftragsperreNachMahnung, Mahnung1..3Datum) - persistierte Mahnstruktur.
+  - [KONTEXT]  `SSMS_DB_SCHEMA.sql` Tabelle `Mahnlauf` - Name belegt das Konzept.
+Prüfidee:      Mahnlauf über fällige Rechnung erzeugt Mahnstufe 1 mit Datum auf dem Beleg.
+Tracelinks:    SwRS-08, SwRS-09, SwRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - betriebsnotwendig.
+Status:        belegt
+
+---
+
+ID:            StRS-09
+Titel:        revisionssichere Ausgangsrechnungen (ZUGFeRD/XRechnung)
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: 
+Akteur:         Buchhaltung, Rechnungsempfänger (insb. öffentliche Auftraggeber)
+Vorbedingung:  Rechnung existiert; ZUGFeRD-Lizenz/Setting aktiv.
+Fakt:          `ReceiptBL.CreateFullReportForReceipt` verlangt bei ZUGFeRD-Aktivierung zwingend ein PDF („Für ZUGFeRD muss ein PDF Dokument über die Rechnung erzeugt werden“, ReceiptBL.cs:3279), erzeugt konformes PDF via `InvoiceZugferdBL.CreateZugferdConformPdfDocument` und ermittelt `LeitwegID` (ReceiptBL.cs:3296-3423); Spezifikations-PDFs XRechnung 2.2/2.3.1, ZUGFeRD 2.1.1 im Repo.
+Aussage:       Das System soll Rechnungen und Gutschriften als hybrides PDF mit e-Rechnungsteil (ZUGFeRD/XRechnung) inkl. Leitweg-ID erzeugen und archivieren.
+Ergebnis:      Empfänger-konforme E-Rechnungen; Archivierung der PDFs.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3273-3299` (Erzwingung PDF + ZUGFeRD-Erzeugung) - durchgesetzte Regelkette.
+  - [SEKUNDÄR] `docs/guides/development/xrechnung.md`, `docs/reference/zugferd-field-mapping.md` - Feldzuordnung dokumentiert.
+Prüfidee:      Rechnung mit aktivem ZUGFeRD-Setting exportieren → PDF/A-3 mit XML-Teil, Leitweg-ID aus Kundendaten/Konzern.
+Tracelinks:    SyRS-09, SwRS-10
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzliche Anforderung (E-Rechnungspflicht).
+Status:        belegt
+
+---
+
+ID:            StRS-10
+Titel:         Kunden-/Partnerportale (Web-Cart, ServiceBoard, SelfCare)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Endkunde des Kunden (B2B2C), Servicetechniker extern
+Vorbedingung:  Web-Account mit Sonderpreisen angelegt.
+Fakt:          README.md: WebCart „available if you login as a web-account … articles come from the customers 'Sonderpreise'“; Nexus-Module `WebCart`, `ServiceBoard`, `CustomerPortal`; WebAccount-Rechte 62001/62002 „Warenkorb prüfen/einkaufen“ (`WebRightsVisibility.cs`); SelfCare-Formulare (`SelfCareBL`).
+Aussage:       Das System soll Externen (Kunden der Kunden, Technikern) webbasierte Portale für Bestellungen, Tickets, Dokumente und Selbstbedienung mit eigenem, eingeschränktem Rechtekreis bieten.
+Ergebnis:      Externe Nutzer sehen nur ihre freigegebenen Artikel/Tickets/Dokumente.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10-33` (Allowlist der WebAccount-Rechte) - zentrale Einschränkung der Portalrechte.
+  - [SEKUNDÄR] `README.md` Rules/Contributing Abschnitt WebCart - Funktionsbeschreibung.
+Prüfidee:      Web-Account ohne Recht 62002 kann nicht bestellen.
+Tracelinks:    SyRS-06, SyRS-10, SwRS-37, SwRS-64
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Wachstumsfeld des Produkts (Nexus).
+Status:        belegt
+
+---
+
+ID:            StRS-11
+Titel:         Anbindung externer Fachsysteme (Buchhaltung, DMS, Personaleinsatz, Banking)
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:         Buchhaltung, Backoffice
+Vorbedingung:  Konfiguration der Zielsysteme vorhanden.
+Fakt:          Buchhaltungs Export/Import-Implementierungen für Abacus/Addison (`Centron.Gateway/BookKeeping*`), DocBee-DMS Connector (`DataExchange/DocBee*`), TANSS (`DataExchange/TanssBL`), RMM, CTime (`Services/CTimeConnectorBL`), FinAPI-Onlinebanking (`src/apis/Centron.APIs.FinAPI/FinApiClient.cs`).
+Aussage:       Das System soll Belegdaten, Tickets und Personenzeiten mit gängigen Fachsystemen austauschen (Export, Import, Status-Sync).
+Ergebnis:      kein Medienbruch zwischen ERP und Fremdsystemen; Austausch protokolliert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Gateway/BookKeepingExportAbacus.cs`/`BookKeepingImportAbacus.cs` (+Addison) - konkrete Format-Implementierungen.
+  - [SEKUNDÄR] `docs/reference/architecture/stanislaus-secret-api-documentation.md` - interne Schnittstellendoku.
+Prüfidee:      Rechnungs Export erzeugt Abacus-Datei mit korrekten Kontenfeldern.
+Tracelinks:    SyRS-11, SwRS-31, SwRS-34, SwRS-35, SwRS-74
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Integrationsfähigkeit ist Verkaufsargument.
+Status:        belegt
+
+---
+
+ID:            StRS-12
+Titel:         Rechtliche Compliance: Datenschutz, Audit-Export, manipulationssichere Signaturen
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Sicherheit
+Akteur:         Datenschutzbeauftragter, Auditor, Kassenbetriebe
+Vorbedingung:  personenbezogene Daten vorhanden.
+Fakt:          `DataSecurityBL.DsgvoDeleteRightGetContacts` + `DataSecurityExecuteCleanUp` (Löschkonzept); CPra-Konnektor (`CPra/CPraConnectorBL.ConnectToCPra`, Application `ExternalAppCPra`); PDF-Signing (`Security/PdfSigningBL.cs`); Timesheet-Signaturen (`HelpdeskTimerSignatureCompact`, Recht `DELETE_HELPDESK_SIGNATURE`).
+Aussage:       Das System soll DSGVO-Löschung/Löschstatistiken, Export für Betriebsprüfung (GoBD) und Nachweis-Signaturen (PDF, Timesheets) unterstützen.
+Ergebnis:      Löschersuchen durchführbar und protokolliert; Audit-Export erzeugbar; Signaturen löschbar nur mit Sonderrecht.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs:64,377` (ExecuteCleanUp, DsgvoDeleteRightGetContacts) - implementierte Löschfunktion.
+  - [SEKUNDÄR] `CentronRights.md` Punkt 7.2 (Signatur aus Zeit löschen = eigenes Recht) - Schutz der Signatur.
+Prüfidee:      DSGVO-Löschlauf entfernt Kontakte eines Löschbegehrens und protokolliert dies.
+Tracelinks:    SyRS-15, SwRS-53
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - rechtlich erforderlich.
+Status:        belegt
+
+---
+
+ID:            StRS-13
+Titel:         Wartbare, testbare und internationalisierbare technische Plattform
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit, Übertragbarkeit
+Akteur:         Entwicklung, Betrieb, QA
+Vorbedingung:  Produktentwicklung und Kundenbetrieb laufen.
+Fakt:          Durchgängige Testprojekte (EndToEnd/Integration/Playwright), CI-Schienen in `.github/workflows` und `azure/`, DB-Konventionenwerk (`docs/guides/database`), mehrsprachige Ressourcen inkl. CH-Prozessvariante (`AlsoOrderCH_BL.cs`, `CultureController`).
+Aussage:       Das System soll auf einer wartbaren, automatisiert testbaren und internationalisierbaren Plattform betrieben werden, damit Funktionserhaltung bei Refactoring und Neuimplementierung nachweisbar bleibt.
+Ergebnis:      Änderungen sind durch CI-Tests abgesichert; Sprach-/Landesvarianten konfigurierbar.
+Belege:
+  - [SEKUNDÄR] `docs/guides/development/end-to-end-testing.md` - Teststrategie dokumentiert.
+  - [PRIMÄR]   `src/nexus/CentronNexus/Controllers/CultureController.cs` - Kulturumschaltung durchgesetzt.
+Prüfidee:      Regressionssuite läuft in CI vor jedem Release.
+Tracelinks:    SyRS-12, SyRS-16, SyRS-18, SyRS-19, SyRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/SyRS.md

@@ -0,0 +1,424 @@
+# SyRS – System Requirements Specification
+
+---
+
+ID:            SyRS-01
+Titel:         Belegwesen als einheitliches System (Header/Position/Version/Progression)
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:         Alle Vertriebs-/Abrechnungsclients, Webservice
+Vorbedingung:  Beleg einer der sieben Belegarten wird angelegt/geändert.
+Fakt:          `ReceiptBase` (abstract) definiert Nummer, Datum, Version, State, Filiale, Währung, Auditfelder, `ConcurrencyControlGuid`; jede Belegart hat Kopf/Position/Versions-Tabellen und englische Views (`Offers`→`AngKopf` usw.).
+Aussage:       Das System soll alle Belegarten auf einer gemeinsamen Datenstruktur mit Versionierung, Mandanten-/Filialbezug, Währungsfaktor und Optimistic Concurrency (`ConcurrencyControlGuid`) betreiben.
+Ergebnis:      Parallele Änderungen werden über die Concurrency-GUID erkannt; jede Änderungsversion ist historisiert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` (via docs/reference/receipts/receipts-backend-architecture.md zitierte Properties inkl. ConcurrencyControlGuid) - gemeinsame Basisklasse aller Belege.
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3063,3068` (`CreateNewVersion`) - Versionsbildung implementiert.
+Prüfidee:      Zwei Clients speichern denselben Beleg → zweiter Speichervorgang schlägt wegen Concurrency-Guid fehl.
+Tracelinks:    StRS-01, SwRS-03, SwRS-05
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - tragendes Datenkonzept.
+Status:        belegt
+
+---
+
+ID:            SyRS-02
+Titel:         Authentifizierung mit austauschbaren Verfahren und Fallback
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         AppUser, WebAccount, OpenID-Connect-Identität
+Vorbedingung:  System-Authentifizierungsmethode konfiguriert.
+Fakt:          `AuthenticatorFactory` wählt je `SystemAuthenticationMethod` (None/Basic/ActiveDirectory/OpenIdConnect) und hängt für Basic-Logins einen `FallbackAuthenticator` (CentronLogin → BasicAuthenticator; AD/OIDC → `FailingAuthenticator` mit Konfigurationsfehler-Meldung); OIDC nur mit Lizenz `OpenIDConnectAuthentication` (AuthenticatorFactory.cs:133).
+Aussage:       Das System soll Login wahlweise lokal, gegen Active Directory oder OpenID-Connect (Entra ID) durchführen; bei Fehlkonfiguration des primären Verfahrens darf der Login kontrolliert fehlschlagen bzw. auf lokales Passwort zurückfallen.
+Ergebnis:      Login erfolgreich bzw. definierte Fehlermeldung; nie stille Umgehung.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs:54-135` -Fabrik und Fallback-Verzweigungen.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs:151-156` (optionaler Server-Zertifikats-Hash-Abgleich) - durchgesetzte Verbindungssicherung.
+Prüfidee:      AD deaktiviert + Nutzer mit AD-Marker → Fallback-Meldung statt Login.
+Tracelinks:    StRS-06, SwRS-36, SwRS-38, SwRS-42
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - modernes IdP-Setup (Entra ID) vorhanden.
+Status:        belegt
+
+---
+
+ID:            SyRS-03
+Titel:         Zentrale Rechteprüfung für Clients und Web Accounts
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         AppUser, WebAccount
+Vorbedingung:  Benutzer ist authentifiziert.
+Fakt:          `AppRightsBL.HasUserRight(userI3D, rightId)` prüft Gruppenzuordnung (`AppGroupRightAssignment`); `UserRightsExt.IsAdmin` prüft Gruppenname „Administratoren“ (UserRightsConst.ADMIN_ACCOUNT); WebAccount-Rechte über `HasWebAccountRight`; WebUI-Rechte auf Allowlist `WebRightsVisibility.AllowedRightIds` beschränkt.
+Aussage:       Das System soll Funktionszugriffe ausschließlich über die zentrale, gruppenbasierte Rechteprüfung (inkl. Admin-Ausnahme und Web-Rechte-Allowlist) freigeben.
+Ergebnis:      Fehlendes Recht ⇒ verweigerter Zugriff inkl. Fehlermeldung; Admin-Gruppe hebt Prüfungen auf.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs:18-30,56-65` und `AppRightsBL.cs` (HasUserRight/HasWebAccountRight/IsAdmin, Zeilen 264-297 Prüfrückgaben) - Durchsetzungspunkte.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10` (AllowedRightIds) - Web-Begrenzung.
+  - [KONTEXT]  `docs/guides/development/check-userrights.md`, `add-a-new-right.md` - Entwicklerleitfaden zur Rechteprüfung.
+Prüfidee:      Integrationstest: Recht entziehen → Aufruf scheitert; Admin-Gruppe → Erfolg.
+Tracelinks:    StRS-07, SwRS-24
+Konsolidierung: Kandidat: `UserRightsExt` (Extensions) und `AppRightsBL` (BL) bilden dieselbe Prüfung doppelt ab – im Zielsystem eine Autorisierungsschicht.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-04
+Titel:         Lizenz- und Kontingentprüfung beim Webservice-Login
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         Zentrales Lizenzsystem, Webservice
+Vorbedingung:  Client meldet sich mit Application-GUID, MachineName, AppVersion.
+Fakt:          `Authenticator.AuthenticateUser` → `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)`; bei „license max reached“ ohne bestehendes Ticket wird abgelehnt; `TicketBL.CreateNewTicket(...)` zählt aktive Sitzungen; `ApplicationKind` trägt `ExpirationKind` (OneDay/MonitoringConnector/FromSettings), `requiredRight`, `disallowingRight`; `ValidateRights` (Authenticator.cs:68-82) prüft Zu-/Ausschlussrechte vor Lizenzprüfung.
+Aussage:       Das System soll jeden Webservice-Login gegen Lizenzexistenz, Versionsgrenze, Gültigkeit, Benutzerzahl und optionale Zulassungs-/Ausschlussrechte prüfen und Sitzungen als Tickets mit Gültigkeitsdauer verwalten.
+Ergebnis:      Überzählter/aparter Login wird abgewiesen; erlaubter Login erzeugt Ticket mit Ablauf.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:68-150` - die Prüf- und Ticketkette.
+  - [PRIMÄR]   `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs:11-58` - Deklaration der erlaubten Anwendungen inkl. Rechte- und Ablaufvarianten.
+Prüfidee:      N+1. Login bei Lizenz-Count N ohne freies Ticket → Fehler.
+Tracelinks:    StRS-06, SwRS-39, SwRS-71, SwRS-83
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-05
+Titel:         Zweifaktor-Authentifizierung (E-Mail/Radius) nach Passwortlogin
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         AppUser, 2FA-Provider
+Vorbedingung:  Benutzer mit 2FA-Konfiguration meldet sich an.
+Fakt:          `BasicAuthenticator` ruft nach Validierung `TwoFactorAuthBL.ValidateTwoFactor(username, password, loggedInUser, …)` (BasicAuthenticator.cs:62); Validatoren austauschbar via `GetTwoFactorValidator()` (EmailTwoFactorValidator, RadiusTwoFactorValidator inkl. RADIUS-Client).
+Aussage:       Das System soll die Zwei-Faktor-Prüfung als verpflichtenden Schritt nach der Passwortvalidierung einbauen und den Faktor austauschbar (E-Mail-Code, RADIUS) konfigurieren.
+Ergebnis:      Ohne gültigen zweiten Faktor kein Login; 2FA-Abbruch bricht Login ab.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:52-65` + `TwoFactor/TwoFactorAuthBL.cs:33` - erzwungener Aufruf im Loginpfad.
+  - [SEKUNDÄR] `docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md` - Dokumentationskontext.
+Prüfidee:      Richtiges Passwort ohne 2FA-Code → kein Ticket.
+Tracelinks:    StRS-06, SwRS-36, SwRS-38
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-06
+Titel:         Webservice als zentraler Zugriffspunkt (WCF/REST, Session-Tickets)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:         WPF-Client, Nexus, Add-Ins, externe Apps
+Vorbedingung:  Login erfolgreich.
+Fakt:          `Centron.Host`/`Centron.Host.WindowsService` hosten `Centron.WebServices.Core` (`ICentronRestService`-Muster, `LoginRequest`, `JwtLoginRequest`, `WebAccountLoginRequest`, `ChangeWebReceiptStateRequest`); Tickets als Sitzungsbeleg (`TicketBL.GetExistingTicket/CreateNewTicket`); Clients wechseln je Modul zwischen BLLogic (Direkt-DB) und WSLogic (Fernzugriff) (docs/general-structure.md).
+Aussage:       Das System soll allen FRONTENDS einen versionierten Webservice mit Ticket-/JWT-basierten Sitzungen bereitstellen, sodass Clients ohne direkten Datenbankzugriff arbeiten können.
+Ergebnis:      identische Geschäftslogik über Direkt- und Remote-Zugriff; Sitzungen invalidierbar.
+Belege:
+  - [PRIMÄR]   `src/webservice/Centron.Host/CentronHost.cs` + `src/webservice/Centron.WebServices.Core/Messages` (LoginRequest/JwtLoginRequest/WebAccountLoginRequest) - gehosteter Dienst und Login-Verträge.
+  - [SEKUNDÄR] `docs/getting-started/general-structure.md` (Duale BLLogic/WSLogic-Architektur) - Architekturregel.
+  - [KONTEXT]  `docs/guides/services/add-webservice-methods.md`, `web-service-on-linux.md` - Betrieb/Erweiterung.
+Prüfidee:      Nexus ohne Ticket-Token erhält 401; mit Ticket Erfolg.
+Tracelinks:    StRS-10, SwRS-38, SwRS-42
+Konsolidierung: Kandidat: Direkt-DB-Zugriff (BLLogic) und Webservice-Pfad (WSLogic) implementieren dieselben Funktionen doppelt – SaaS-Zielbetrieb nur über API.
+Übernahmewürdigkeit: übernehmen (Architektur), Direkt-DB-Pfad → Workaround für On-Premise
+Status:        belegt
+
+---
+
+ID:            SyRS-07
+Titel:         Preismatrix und mehrstufige Preisfindung im Beleg
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Vertriebsclient, Webservice
+Vorbedingung:  Belegposition mit Artikel.
+Fakt:          `ReceiptPriceHelperBL.CalculateReceiptVatPrices(...)` und `CalculateReceiptItemBasePrice(netPriceFC, …)` (ReceiptPriceHelperBL.cs:65-122); `RecalculateItemsFreightAndDistribution(receipt)` (ReceiptBL.cs:5125); Aktions-/Volumen-/Sonderpreis-Quellen (ActionPriceBL, ArticleVolumePricesBL, AccountSpecialPriceBL).
+Aussage:       Das System soll den Positionspreis deterministisch aus Preisquellen (Kunden-Sonderpreis, Aktionspreis im Gültigkeitszeitraum, Volumenpreis, Standard) ableiten, MwSt.-Summen je Satz bilden und Fracht Verteilung neu berechnen.
+Ergebnis:      Belegsummen stimmen mit Positionspreisen und MwSt.-Sätzen überein.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs:65,122` - die Kalkulationsmethoden.
+  - [SEKUNDÄR] `docs/reference/receipts/actionprice-system.md` Abschnitt „Integration with Price Matrix“ - Regelbeschreibung.
+Prüfidee:      Positionspreis-Änderung → MwSt.-Aufstellung und Frachtverteilung aktualisieren sich.
+Tracelinks:    StRS-04, SwRS-25, SwRS-26
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-08
+Titel:         EDI-Versandpipeline mit Log- und Zustandsverwaltung
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:         EDI-Dispatcher, Distributoren
+Vorbedingung:  Auftrag mit EDI-fähigem Lieferanten.
+Fakt:          `EDIDispatcherBL` + `SupplierEdiBL.<Distributor>`-Partials; Zustandsenummern `EDIHeadState`, `EDILogState`; Protokollierung `EDILogBL`, `EDIGatewayLogBL`.
+Aussage:       Das System soll EDI-Vorgänge zustandsbehaftet (angestoßen/übermittelt/fehlerhaft) mit Wiederholbarkeit und vollständigem Log-Betrieb.
+Ergebnis:      Jeder Versand hat dauerhaften Log-Eintrag mit Status; Fehler sind wiederholbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/EDI/Dispatch/SupplierEdiBL.cs` (+ Distributor-Partials) und `EDICommon/EDIDispatcherBL.cs` - Versand- und Dispatch-Logik.
+  - [SEKUNDÄR] `docs/reference/edi/edi-architecture.md`, `edi-import-rules.md` - Regelwerk.
+Prüfidee:      Simulierter Timeout → Logeintrag mit Fehlerstatus, erneuter Versuch möglich.
+Tracelinks:    StRS-05, SwRS-30
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-09
+Titel:         E-Rechnungs-Ausgabe (ZUGFeRD 2.x / XRechnung) als Systemdienst
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal: 
+Akteur:         Rechnungswesen, empfangende Systeme
+Vorbedingung:  Rechnung/Gutschrift liegt vor.
+Fakt:          `InvoiceZugferdBL` (+ Partial `Zugferd10`), `ZugferdFileKind`, `XInvoiceVersion3.cs`, Spezifikations-PDFs XRechnung 2.2.0/2.3.1 und ZUGFeRD 2.1.1 TA im Verzeichnis `src/backend/Centron.BL/DataExchange/`; Fehlerpfad bei fehlendem PDF (ReceiptBL.cs:3279); `ZUGFeRD_BL`, `ZugferdParseBL` im EDI-Modul (Importseite).
+Aussage:       Das System soll ausgehende Rechnungen als ZUGFeRD/XRechnung erzeugen und eingehende E-Rechnungs-Dateien parsen können.
+Ergebnis:      Validierbare XML/PDF-Hybrid-Ausgaben; Parse-Ergebnisse strukturiert verfügbar.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/DataExchange/InvoiceZugferdBL.cs` (+`.Zugferd10.cs`) und `Data/XInvoiceVersion3.cs` - Erzeugungs- und Versionierungscode.
+  - [PRIMÄR]   `src/backend/Centron.BL/EDI/ZUGFeRD_BL.cs`, `ZugferdParseBL.cs` - Import-/ParseLogik.
+Prüfidee:      Erzeugtes XML gegen Schematron der hinterlegten Spezifikation validieren.
+Tracelinks:    StRS-09, SwRS-10
+Konsolidierung: Kandidat: ZUGFeRD-Code existiert parallel in DataExchange (Export) und EDI (Parse) - ein E-Invoicing-Dienst im Zielsystem.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-10
+Titel:         Web-Accounts als eigener Authentifizierungstyp mit Rechtemenge
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         WebAccount (Portalkunde)
+Vorbedingung:  Web-Account im Adressstamm mit Sonderpreisen angelegt.
+Fakt:          `WebAccountAuthenticator` über Fabrik eingehängt; `WebAccountBL` prüft/setzt Passwörter als SHA1-Hash (`SHA1Decoder.GetDecodedSHA1String`, WebAccountBL.cs:56,192,253); `WebRightsExt`/`HasWebAccountRight` (UserRightsExt.cs:34-50); Rechte auf `WebRightsVisibility` beschränkt; Application `WebCart` mit `ExpirationKind.FromSettings`.
+Aussage:       Das System soll Portalnutzer als eigenständigen Accounttyp mit eigenem Rechtekanon und ablaufender Lizenz führen; Passwörter sind zu hashen (aktueller SHA1-Algorithmus ist abzulösen, siehe SwRS-39).
+Ergebnis:      Portallogin nur mit gültigem Account, Passworthash geprüft, Rechte gefiltert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/WebAccountAuthenticator.cs` + `Users/WebAccountBL.cs:56` - Authentifizierung und Passworthandhabung.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10-52` - Rechtemenge.
+Prüfidee:      WebAccount ohne Recht 26000 kann kein Ticket anlegen.
+Tracelinks:    StRS-10, SwRS-36, SwRS-37
+Konsolidierung: Kandidat: AppUser- und WebAccount-Passwortbehandlung (UsersBL/WebAccountBL) sind Parallelimpelementationen - ein Accounts-/Credential-Dienst im Zielsystem.
+Übernahmewürdigkeit: übernehmen (Konzept), SHA1 → veraltet (siehe SwRS-38)
+Status:        belegt
+
+---
+
+ID:            SyRS-11
+Titel:         Buchhaltungsanbindung über Export-/Import-Konnektoren (DATEV-artig)
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:         Externes Buchhaltungssystem (Abacus, Addison, DATEV-artige Formate)
+Vorbedingung:  Buchhaltungssystem konfiguriert (BankAccountProperty, BookKeepingAccountSystems).
+Fakt:          `Centron.Gateway` implementiert `IBookKeepingExport`/`IBookKeepingImportDataToCentron` mit Concrete ExportAbacus/ImportAbacus/ExportAddison/…; `DataExchange/BookKeepingExportBL.cs`, `BookKeepingImportBL.cs`; Kontenfeld-Service `ReceiptItemAccountBL`, `BankAccountBL` (BL/Accounting).
+Aussage:       Das System soll Belegdaten exportier- und importierbar in Buchhaltungsformate machen, inklusive Kontenzuordnung je Belegposition.
+Ergebnis:      Exportdatei enthält vollständige Kontierungsdaten; Import schreibt Buchungsdaten zurück.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.Gateway/BookKeepingExportAbacus.cs`, `BookKeepingImportAddison.cs` u.a. - Formatimplementierungen.
+  - [SEKUNDÄR] `src/backend/Centron.BL/Administration/BookKeepingAccountSystems` (Modulordner) - Konfigurationsablage.
+Prüfidee:      Export einer Rechnung enthält USt-Schlüssel und Konten je Position.
+Tracelinks:    StRS-11, SwRS-35
+Konsolidierung: Kandidat: je Zielsystem eine Implementierungsklasse – Zielsystem: ein Export-Framework mit Format-Plugins.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-12
+Titel:         Duale Client-Datenzugriffsschicht (BLLogic/WSLogic) mit DI-Container
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit, Übertragbarkeit
+Akteur:         WPF-Client (Centron.WPF.UI)
+Vorbedingung:  Modul implementiert ILogic.
+Fakt:          `ClassContainer.Instance.WithInstance((IAccountContractsLogic logic) => …)`; Konvention: je Modul `ILogic` + `BL*Logic` (Direkt-DB) + `WS*Logic` (REST); `Result<T>`-Fehlermuster durchgängig (docs/general-structure.md).
+Aussage:       Das System soll jeden Modulzugriff hinter einem Interface kapseln, damit Deployment zwischen Direkt-Datenbank- und API-Betrieb umschaltbar ist.
+Ergebnis:      Umschaltung ohne Änderung an ViewModel-Schicht.
+Belege:
+  - [SEKUNDÄR] `docs/getting-started/general-structure.md` - Architekturregel mit Codebeispielen.
+  - [PRIMÄR]   `src/backend/Centron.Interfaces` (ILogic-Schnittstellen, z. B. `Sales/Receipts/ReceiptState.cs` im selben Paketmuster) - Schnittstellenpaket als Infrastruktur.
+Prüfidee:      WSModus: Trace zeigt HTTP-Aufruf statt DB-Query.
+Tracelinks:    StRS-13, SyRS-06, SwRS-77
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Doppelpfad existiert wegen On-Premise-Historie; SaaS-Ziel kennt nur API.
+Status:        belegt
+
+---
+
+ID:            SyRS-13
+Titel:         Nexus-Webfrontend (Blazor) mit eigener Hostarchitektur
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:         Browsernutzer (Mitarbeiter und Kunden)
+Vorbedingung:  CentronNexus.Host läuft.
+Fakt:          `src/nexus/CentronNexus` mit Bereichen ServiceBoard (Kanban, Scheduler, DocumentViewer, PasswordManager, MyDay), WebCart/CustomerPortal, WebOffer, DocumentSigning, ProductionOrderManagement, Office; `CentronNexus.Host`, `CentronNexus.OutlookAddIn`; README: DevExpress-Blazor-Komponenten, LibMan/CDN-Integrity-Regeln.
+Aussage:       Das System soll Webanwendungsfunktionen (Service-Board, Web-Cart, Angebotsportal, Dokumentenzeichnung) als Blazor-Frontend gegen den zentralen Webservice bereitstellen.
+Ergebnis:      Webnutzer erhalten äquivalente Funktionen des Desktop-Clients für die betroffenen Module.
+Belege:
+  - [PRIMÄR]   `src/nexus/CentronNexus/ServiceBoard/Kanban`, `WebCart/CustomerPortal`, `DocumentSigning` (Verzeichnis-/Komponentenstruktur) - existente Webmodule.
+  - [SEKUNDÄR] `README.md` - Frontend-Regeln und WebCart-Hinweis.
+Prüfidee:      ServiceBoard-Ticketliste filtert wie Client-Filter; Login nur über WebAccount/AppUser-Ticket.
+Tracelinks:    StRS-10, SwRS-51, SwRS-78
+Konsolidierung: Kandidat: WPF-Client und Nexus-UI bilden Helpdesk/Belege doppelt ab - ein domänenseitiges Backend, zwei Presentation Layers.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-14
+Titel:         Reporting-Engine mit Druckoptionen und Portal-Reports
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:         Anwender, Reportserver
+Vorbedingung:  Reportgruppe/Layout konfiguriert.
+Fakt:          `ReportEngine`-Modul (26 Klassen, `ReportsSqlStatements.cs`), DB-Constraint `CK_ParentReference` auf `ReportPrintOptions` (ParentI3D und ParentObjectKind nur gemeinsam gesetzt, SSMS_DB_SCHEMA.sql); Sonderrecht `UPLOAD_PORTAL_REPORTS = 99999458` („only in c-entron databases where you are allowed to upload reports to the portal“, UserRightsConst.cs:22).
+Aussage:       Das System soll Belegdruck/Reportausgabe über konfigurierbare Layouts und Hierarchie-Druckoptionen steuern und Portal-Report-Uploads kundenspezifisch sperren.
+Ergebnis:      Reports gemäß Druckoptionen; Upload nur mit Sonderrecht.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` `CONSTRAINT [CK_ParentReference] CHECK …ReportPrintOptions` - durchgesetztes Datenconstraint.
+  - [SEKUNDÄR] `src/backend/Centron.WebServices.../UserRightsConst.cs:22` (UPLOAD_PORTAL_REPORTS) - Konfigurationsschalter.
+Prüfidee:      Druckoption mit ParentI3D ohne ParentObjectKind wird von DB abgelehnt.
+Tracelinks:    StRS-13, SwRS-56
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-15
+Titel:         Löschkonzept und Soft-Delete-Muster
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit
+Akteur:         Datenschutzbeauftragter, Fachanwender
+Vorbedingung:  Daten mit Lösch-/Sperrflags vorhanden.
+Fakt:          `DataSecurityBL.GetDataSecurityCleanUpStats` + `DataSecurityExecuteCleanUp` + `DsgvoDeleteRightGetContacts` (DataSecurityBL.cs:34,64,377); `EntityState`-Entität im Datenmodell; Deaktivierungsflags z. B. `AppUser.AccountDisabledFromDate/ToDate`, `IsAccountDisabled` (Authenticator.cs:169-172).
+Aussage:       Das System soll Löschen primär als Sperrung/Deaktivierung mit Zeitfenstern abbilden und physische Bereinigung nur über den DSGVO-Cleanup-Dienst mit Statistik erlauben.
+Ergebnis:      Deaktivierte Nutzer/Tickets sind funktional gelöscht; Cleanup protokolliert.
+Belege:
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs:64,377` - Vollzug der Löschung.
+  - [PRIMÄR]   `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:169-172` (AccountDisabledFrom/To-Prüfung beim Login) - Durchsetzung der Sperrung.
+Prüfidee:      Deaktiviertes Zeitfenster heute → Login abgelehnt.
+Tracelinks:    StRS-12, SwRS-36, SwRS-43
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-16
+Titel:         Datenbank-Konventionen (I3D-Schlüssel, Audit-Spalten, dbo)
+Ebene:         SyRS
+Typ:           Daten
+Qualitätsmerkmal: Wartbarkeit
+Akteur:         Entwickler, DBA
+Vorbedingung:  Neues Tabellenobjekt wird angelegt.
+Fakt:          Konvention: PK immer `I3D int IDENTITY(1,1)`, FK-Suffix `I3D`, Pflichtspalten `CreatedByI3D/CreatedDate` (+Änderungsspalten), Schema `dbo` (docs/guides/database/database-conventions.md); 1.535 CREATE-TABLE-Objekte und ~3.000 Constraints/Indexes im Gesamtschema.
+Aussage:       Das System soll alle Datenobjekte nach einheitlichen Namens- und Auditkonventionen führen, damit Migration und Tooling (NHibernate-Mapping) funktionieren.
+Ergebnis:      Jede Tabelle historisiert Anlage/Änderung; Fremdschlüssel maschinell erkennbar.
+Belege:
+  - [PRIMÄR]   `SSMS_DB_SCHEMA.sql` (PK-Cluster auf I3D in allen Tabellen, z. B. `PK_…`; CHECK-Constraints z. B. `CK_AccountActivities_Rating`, `Check_ReceiptProvisionItems_Receiver`) - gelebte Konvention im Schema.
+  - [KONTEXT]  `docs/guides/database/database-conventions.md`, `docs/reference/database/script-rules.md` - Regelwerk.
+Prüfidee:      Schema-Analyse: 100 % Tabellen mit I3D-PK.
+Tracelinks:    StRS-13, SwRS-01, SwRS-07
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Basis für Neuimplementierung.
+Status:        belegt
+
+---
+
+ID:            SyRS-17
+Titel:         Externe Produkt-/Logistik-/Bank-APIs als Adapterdienste
+Ebene:         SyRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:         GLS, Shipcloud, ICECAT, egis, ITscope, CopData, eBuddy(eBay-Schnittstelle), FinAPI
+Vorbedingung:  Zugangsdaten hinterlegt.
+Fakt:          Acht API-Projekte unter `src/apis` (Centron.Api.Gls, .Shipcloud, .EbInterface, APIs.CopDataAccess, .EgisDataAccess, .IcecatDataAccess, .ITscopeDataAccess, .FinAPI) mit Client-/Constants-Klassen und Unit-Tests unter `tests/apis`.
+Aussage:       Das System soll Versandlabels, Produktdaten, Fremdartikelpreise und Banktransaktionen über gekapselte API-Adapter beziehen/übermitteln.
+Ergebnis:      Adapter mit konfigurierbaren Credentials; Ausfall eines Adapters blockiert Kernsystem nicht.
+Belege:
+  - [PRIMÄR]   `src/apis/Centron.Api.Shipcloud` inkl. `ShipcloudPackageTemplateBL` (Sales/Receipts) - Label-/Paketintegration im Beleg.
+  - [SEKUNDÄR] `docs/reference/architecture/dtos-and-entities.md` - Adapter-/DTO-Muster.
+Prüfidee:      Versenderzeugung aus einem Auftrag erzeugt ein Shipcloud-Label im Testmodus.
+Tracelinks:    StRS-04, StRS-11, SwRS-34, SwRS-84
+Konsolidierung: Kandidat: Fremdartikel-Provider (Egis/ITscope/ICECAT/Cop) sind vier Parallelimplementierungen derselben Suchfunktion - ein Provider-Plugin-Verzeichnis.
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-18
+Titel:         Deployment: Windows-Installer für Client und Webservice, Docker für Nexus
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:         Betrieb/IT-Partner
+Vorbedingung:  Build-Artefakte vorhanden.
+Fakt:          WiX-Installer `deployment/centron/CentronSetupProject`, `WebServiceSetupProject`, `WixSharpInstaller`; mehrere Dockerfiles (`docker/`) inkl. `install.sh/startup.sh` und `docker-pipeline.yml`, `build-nexus.yaml`, `build-web-service.yaml`; `docs/operations/build-server-and-automated-builds.md`.
+Aussage:       Das System soll Client und Webservice als MSI für Windows ausliefern und die Webkomponente containerisierbar betreiben.
+Ergebnis:      reproduzierbare Installation/Updates; Nexus-Image in Azure/Container-lauffähig.
+Belege:
+  - [SEKUNDÄR] `deployment/centron/CentronSetupProject/CentronSetupProject.wixproj` - Installerprojekt.
+  - [SEKUNDÄR] `azure/build-pipeline.yml`, `docker-pipeline.yml`, `docker/*/Dockerfile` - Build-/Deploy-Pipelines.
+Prüfidee:      Pipeline baut MSI und Nexus-Image aus demselben Commit.
+Tracelinks:    StRS-13, SwRS-83
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (Containerpfad) / Sonderfall (MSI nur für On-Premise-Kunden)
+Status:        belegt
+
+---
+
+ID:            SyRS-19
+Titel:         Continuous Integration mit Build-, Test- und Regressionsschienen
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit
+Akteur:         Entwicklung, QA
+Vorbedingung:  Push/PR im Repository.
+Fakt:          `.github/workflows/build.yml`, `tests.yml`, `regression-tests.yml`; azure-pipelines `analyze-pipeline.yml`, `regression-tests-pipeline.yml`, `tests-pipeline.yml`; Testprojekte `Centron.Tests.EndToEnd`, `Centron.Tests.Integration`, `Centron.Tests.BL/DAO/Core/Controls`, `PlaywrightTests`, `CentronNexusTests`; `docs/guides/development/end-to-end-testing.md`.
+Aussage:       Das System soll Build, Unit-/Integrations-/E2E- und Regressionstests automatisiert ausführen, um Refactoring-Migrationen abzusichern.
+Ergebnis:      grüne Pipeline als Auslieferungsvoraussetzung.
+Belege:
+  - [SEKUNDÄR] `.github/workflows/tests.yml`, `regression-tests.yml` - existierende Schienen.
+  - [PRIMÄR]   `tests/Centron.Tests.Integration/*.csproj` - ausführbare Testinfrastruktur.
+Prüfidee:      PR mit fehlschlagendem Integrationstest wird rot.
+Tracelinks:    StRS-13, SwRS-68
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            SyRS-20
+Titel:         Mehrsprachigkeit und Lokalisierung
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit
+Akteur:         Anwender (DE/CH/weitere)
+Vorbedingung:  Sprach-/Kulturkontext gesetzt.
+Fakt:          `docs/guides/ui/localization.md`, `ResXManager.config.xml`, `CentronNexus/CultureController.cs`, lokalisierte Fehlermeldungen (`LocalizedStrings.AuthenticatorFactory_FallbackMisconfiguredErrorMessage`), CH-spezifische EDI-Variante `AlsoOrderCH_BL.cs`.
+Aussage:       Das System soll Bedientexte und Validierungs-/Fehlermeldungen mehrsprachig verwalten und länderspezifische Prozessvarianten (CH-EDI) unterstützen.
+Ergebnis:      UI und Meldungen folgen der Nutzersprache.
+Belege:
+  - [SEKUNDÄR] `ResXManager.config.xml` + `src/centron/Centron.WPF.UI/Localization` - Ressourcenverwaltung.
+  - [PRIMÄR]   `src/nexus/CentronNexus/Controllers/CultureController.cs` - Kulturumschaltung im Web.
+  - [KONTEXT]  `docs/guides/ui/localization.md` - Leitfaden.
+Prüfidee:      Sprachwechsel ändert Menü- und Meldungstexte vollständig.
+Tracelinks:    StRS-13, SwRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/Traceability.md

@@ -0,0 +1,134 @@
+# Traceability
+
+Forward-/Backward-Verknüpfung StRS → SyRS → SwRS mit Haupt-Artefaktbeleg. (Vollständige Beleglisten je Anforderung stehen in den Ebenendateien.)
+
+## StRS → SyRS
+
+| StRS-ID | SyRS-IDs |
+|---|---|
+| StRS-01 | SyRS-01 |
+| StRS-02 | SyRS-13 |
+| StRS-03 | SyRS-01 (Zeiter→Beleg über SwRS-14) |
+| StRS-04 | SyRS-07, SyRS-17 |
+| StRS-05 | SyRS-08 |
+| StRS-06 | SyRS-02, SyRS-04, SyRS-05 |
+| StRS-07 | SyRS-03 |
+| StRS-08 | SyRS-11 |
+| StRS-09 | SyRS-09 |
+| StRS-10 | SyRS-06, SyRS-10, SyRS-13 |
+| StRS-11 | SyRS-11, SyRS-17 |
+| StRS-12 | SyRS-15 |
+| StRS-13 | SyRS-12, SyRS-16, SyRS-18, SyRS-19, SyRS-20 |
+
+## Konsolidierte Traceability-Tabelle
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kern) |
+|---|---|---|---|
+| StRS-01 | SyRS-01 | SwRS-03 | `Centron.Interfaces/Sales/Receipts/ReceiptState.cs:6-13` |
+| StRS-01 | SyRS-01 | SwRS-04 | `Sales/Receipts/ReceiptBL.cs:3160,3169` (Lock/Unlock) |
+| StRS-01 | SyRS-01 | SwRS-05 | `ReceiptBL.cs:3063` + `*KopfVersions`-Tabellen |
+| StRS-01 | SyRS-01 | SwRS-06 | `ReceiptBL.cs:1377,1548,4767` (Copy/Forward/Progression) |
+| StRS-01 | SyRS-07 | SwRS-07 | DB-CHECK `Check_ReceiptProvisionItems_*` |
+| StRS-01 | SyRS-07 | – (SyRS direkt) | `ReceiptPriceHelperBL.cs:65,122` (Preiskalkulation, in SyRS-07 belegt) |
+| StRS-01 | - | SwRS-01 | `IX_AccountCustomers_UniqueNumber` (Schema) |
+| StRS-01 | - | SwRS-02 | `AccountBL.cs:307-351`, `ReceiptBL.cs:3417` |
+| StRS-02 | SyRS-13 | SwRS-18 | `Entities/CustomerArea/Support/HelpdeskState.cs:7-14` |
+| StRS-02 | SyRS-13 | SwRS-19 | `HelpdeskCloseBL.cs:108,200` |
+| StRS-02 | - | SwRS-20 | `HelpdeskCreationTemplateBL.cs` + CentronRights.md 17 |
+| StRS-03 | SyRS-01 | SwRS-12 | `HelpdeskTimerHourlySurchargeRateOverlap.cs` |
+| StRS-03 | SyRS-01 | SwRS-13 | `HelpdeskTimerBillingState.cs` + CentronRights.md 7-9 |
+| StRS-03 | SyRS-01 | SwRS-14 | `ReceiptBL.cs:5295` (Zeiten→Beleg) |
+| StRS-04 | SyRS-07 | SwRS-25 | `ActionPriceBL.cs:26` + `HerstellerArtikAktionspreis` |
+| StRS-04 | SyRS-07 | SwRS-26 | `AccountSpecialPriceBL.cs` + README (WebCart/Sonderpreise) |
+| StRS-04 | SyRS-17 | SwRS-23 | `ArticleBL.cs:166-235` |
+| StRS-04 | - | SwRS-29 | `OrderSuggestionListBL.cs` |
+| StRS-05 | SyRS-08 | SwRS-30 | `EDI/Dispatch/SupplierEdiBL.cs` (+Partials) |
+| StRS-06 | SyRS-02 | SwRS-36 | `UsersBL.cs:65,107` (SHA1 – abzulösen) |
+| StRS-06 | SyRS-02 | SwRS-38 | `TicketBL.cs:169` (gerätegebundenes Ticket) |
+| StRS-06 | SyRS-02 | SwRS-42 | `MasterPasswordSecureFileStorage.cs` |
+| StRS-06 | SyRS-04 | SwRS-39 | `AccountLicenseBL.cs` + licensing-system.md |
+| StRS-06 | SyRS-04 | SwRS-71 | `Authenticator.cs:68-82` (requiredRight Riversuite) |
+| StRS-06 | SyRS-04 | SwRS-83 | `Authenticator.cs:132,150` (Versionsgrenze) |
+| StRS-07 | SyRS-03 | SwRS-24 | `ArticleBL.cs:129` (HasUserArticleRights) |
+| StRS-07 | SyRS-03 | SwRS-41 | `CustomerToBranchBL.cs` + CentronRights.md (Filialrechte) |
+| StRS-08 | SyRS-11 | SwRS-08 | `DunningRunBL.cs:49,495` + `Kunden.MahnungNachTagen` |
+| StRS-08 | - | SwRS-09 | `Kunden.AuftragsperreNachMahnung` [HYPOTHESE] |
+| StRS-08 | - | SwRS-11 | `CashBookBL.cs:15` |
+| StRS-08 | - | SwRS-33 | `IncomingPaymentBL.cs`, `ReceiptBL.cs:4902` |
+| StRS-09 | SyRS-09 | SwRS-10 | `ReceiptBL.cs:3273-3438` (ZUGFeRD/Leitweg) |
+| StRS-09 | - | SwRS-32 | `ReceiptBL.cs:5082,5095` (Duplikatprüfung) |
+| StRS-10 | SyRS-06 | SwRS-37 | `WebAccountBL.cs:56,415` + `WebRightsVisibility.cs` |
+| StRS-10 | SyRS-10 | SwRS-64 | `SelfCareBL.cs:47,55` |
+| StRS-10 | SyRS-13 | SwRS-51 | `NexusNotifications/NotificationsHubHelper.cs` |
+| StRS-10 | SyRS-13 | SwRS-78 | `Entities/Mobile/NewMobileHelpdeskTimer.cs` |
+| StRS-11 | SyRS-11 | SwRS-31 | `DocBeeTicketCreationBL.cs` |
+| StRS-11 | SyRS-11 | SwRS-34 | `FinApiClient.cs` + LicenseGuids (HBCI→FinAPI) |
+| StRS-11 | SyRS-11 | SwRS-35 | `Gateway/BookKeepingExportAbacus.cs` |
+| StRS-11 | SyRS-11 | SwRS-74 | `Services/CTimeConnectorBL.cs` |
+| StRS-11 | SyRS-17 | SwRS-84 | `Centron.Api.docuFORM/OAuthHelper.cs` |
+| StRS-12 | SyRS-15 | SwRS-43 | `docs/Background Service/DataQualityService.md` [HYPOTHESE] |
+| StRS-12 | - | SwRS-53 | `CPra/CPraConnectorBL.cs:31` [HYPOTHESE] |
+| StRS-13 | SyRS-12 | SwRS-77 | `GUI/UiProfileBL.cs` |
+| StRS-13 | SyRS-16 | SwRS-58 | `Customizations/CustomTables/CustomTableBL.cs:20,25` |
+| StRS-13 | SyRS-16 | SwRS-75 | `SystemArea/SystemTableI3DBL.cs` |
+| StRS-13 | SyRS-16 | SwRS-80 | `CountryArea/CountryBL.cs` |
+| StRS-13 | SyRS-18 | SwRS-76 | `ObjectExternalReferenceBL.cs` |
+| StRS-13 | SyRS-19 | SwRS-68 | `MassUpdateBL.cs:92,132` |
+| StRS-13 | SyRS-20 | SwRS-66 | `TradePoolBL.cs:28` |
+
+## Restliche SwRS → SyRS (Zuordnung vollständig, Kernbeleg)
+
+| SwRS-ID | SyRS-ID | Artefaktbeleg (Kern) |
+|---|---|---|
+| SwRS-07 | SyRS-07 | `ReceiptProvisionSchemaBL.cs` + DB-Constraints Provisionen |
+| SwRS-14 | SyRS-01 | `ReceiptBL.cs:5295` |
+| SwRS-15 | SyRS-16 | `CK_AccountActivities_Rating` (Schema) |
+| SwRS-16 | SyRS-16 | `CampaignPhaseActionBL.cs` |
+| SwRS-17 | SyRS-16 | `CI_RMA_HelpdeskI3D UNIQUE` (Schema) |
+| SwRS-21 | SyRS-16 | `Devices/AccountDeviceBL.cs:21-40` |
+| SwRS-22 | SyRS-16 | `DocuBoard/AssetManagementArticleAssignmentBL.cs` |
+| SwRS-27 | SyRS-16 | `InventoryManagement/InventoryBL.cs:75-196` |
+| SwRS-28 | SyRS-01 | `ReceiptBL.cs:5031` (QuantityPicked) |
+| SwRS-32 | SyRS-09 | `InvoiceUploadBL.cs`, `ReceiptBL.cs:5082` |
+| SwRS-36 | SyRS-02 | `UsersBL.cs:65,88,107` |
+| SwRS-37 | SyRS-10 | `WebAccountBL.cs:56,192,415,480` |
+| SwRS-38 | SyRS-04 | `TicketBL.cs:169`, `Authenticator.cs:127-142` |
+| SwRS-39 | SyRS-04 | `AccountLicenseBL.cs` |
+| SwRS-40 | SyRS-06 | `WebSuite/WebSettingGlobalBL.cs` |
+| SwRS-41 | SyRS-03 | `Accounts/CustomerToBranchBL.cs` |
+| SwRS-42 | SyRS-06 | `CentronConfigDb/MasterPasswordSecureFileStorage.cs` |
+| SwRS-44 | SyRS-16 | `EmployeeArea/EmployeeHolidayBL.cs:25-34` |
+| SwRS-45 | SyRS-06 | `MyDay/MyDayBL.cs` |
+| SwRS-46 | SyRS-16 | `TaskManager/TaskManagementTaskBL.cs` + Handler |
+| SwRS-47 | SyRS-06 | `Mail/CentronMailFactory.cs` |
+| SwRS-48 | SyRS-16 | `MailScanner/MailScannerBL.cs:36,45` |
+| SwRS-49 | SyRS-16 | `Mailings/MailingDataBL.cs` |
+| SwRS-50 | SyRS-16 | `Chats/ChatBL.cs:45,176` |
+| SwRS-51 | SyRS-13 | `NexusNotifications/NotificationsHubHelper.cs` |
+| SwRS-52 | SyRS-11 | `Tapi/PhoneCallBL.cs:52` |
+| SwRS-54 | SyRS-01 | `ReceiptBL.cs:4865` (Projektnummer) |
+| SwRS-55 | SyRS-16 | `Production/ProductionOrderBL.cs:35-184` |
+| SwRS-56 | SyRS-14 | `Statistics/CacheSalesStatisticsBL.cs` |
+| SwRS-57 | SyRS-12 | `IndexSearch/IndexSearchBL.cs:28-44` |
+| SwRS-59 | SyRS-16 | `Tags/TagsBL.cs:19,70` |
+| SwRS-60 | SyRS-16 | `WebLinks/WebLinkActionReminderHandler.cs` |
+| SwRS-61 | SyRS-16 | `VideoPortal/VideoPortalAssignmentBL.cs:25` |
+| SwRS-62 | SyRS-16 | `SocialMedia/PersonSocialNetworkBL.cs` |
+| SwRS-63 | SyRS-16 | `VoucherManagement/VoucherManagementBL.cs:17` |
+| SwRS-64 | SyRS-06 | `SelfCare/SelfCareBL.cs:47,55` |
+| SwRS-65 | SyRS-03 | `ExternalToolsBL/ExternalToolBL.cs:58` |
+| SwRS-67 | SyRS-15 | `Transactions/TransactionBL.cs:29-63` |
+| SwRS-68 | SyRS-15 | `ChangeTracking/History/ImportHistoryBL.cs:20,27` |
+| SwRS-69 | SyRS-19 | `Telemetry/TelemetryBL.cs:23` |
+| SwRS-70 | SyRS-17 | `ArtificialIntelligence/ApiClientFactory.cs` |
+| SwRS-71 | SyRS-04 | `RiverDivo/RiverConnectionBL.cs` |
+| SwRS-72 | SyRS-16 | `TextModuleArea/TextModuleBL.cs:54-64` |
+| SwRS-73 | SyRS-16 | `ProductMatrix/ProductMatrixBL.cs:27-65` |
+| SwRS-74 | SyRS-11 | `Services/CTimeConnectorBL.cs` |
+| SwRS-77 | SyRS-12 | `GUI/UiProfileBL.cs` |
+| SwRS-78 | SyRS-13 | `Entities/Mobile/NewMobile*` |
+| SwRS-79 | SyRS-04 | `Modules/ModuleBL.cs:22,44` |
+| SwRS-81 | SyRS-16 | `DocumentationArea/DocumentationBL.cs:27-97` |
+| SwRS-82 | SyRS-03 | `PasswordManagementArea/PasswordManagementBL.cs:17,32` |
+| SwRS-83 | SyRS-04 | `Authenticator.cs:132,150` + WebVersion/VersionBL |
+| SwRS-84 | SyRS-17 | `Centron.Api.docuFORM/DocuFormRestApiClient.cs` |

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Protokoll.md

@@ -0,0 +1,126 @@
+# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/solo/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-03T14:55:51.3674789+02:00
+- **Endzeit:** 2026-09-03T15:14:27.6927641+02:00
+- **Dauer gesamt:** 00:18:30 (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):** `qwen/qwen3.8-flash-next`
+- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/solo/max/`
+- **Agentenmodus:** `solo`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
+- **Rollen:** {}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 122.568 |
+| Output-Tokens | 99.634 |
+| Reasoning-Tokens | 33.710 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 82 |
+
+**Tokens gesamt: 5.736.232.** 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 | 13 | 11,1 % |
+| SyRS | 20 | 17,1 % |
+| SwRS | 84 | 71,8 % |
+| **Gesamt** | **117** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 43 | 36,8 % |
+| Daten | 23 | 19,7 % |
+| Schnittstelle | 21 | 17,9 % |
+| Sicherheit | 16 | 13,7 % |
+| nicht-funktional | 14 | 12,0 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 191 |
+| davon `PRIMÄR` | 136 (71,2 %) |
+| davon `SEKUNDÄR` | 46 (24,1 %) |
+| davon `KONTEXT` | 9 (4,7 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 114 (97,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 106 | 90,6 % |
+| workaround | 4 | 3,4 % |
+| sonderfall | 7 | 6,0 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 114 | 97,4 % |
+| als `HYPOTHESE` gekennzeichnet | 3 | 2,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 60 | 51,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 28 | 23,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (26 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 117 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 117 von 117 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f98a8e51fffe3QtphUN2xVQvN5`
+- **Werkzeugaufrufe:** 131 – {"bash": 109, "write": 8, "edit": 12, "grep": 1, "read": 1}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-03T12:55:53.171309+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\Ergebnisse)
+[2026-09-03T12:55:53.444214+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T13:14:26.157936+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T13:14:27.621337+00:00] OpenCode export: Exporting session: ses_f98a8e51fffe3QtphUN2xVQvN5
+[2026-09-03T13:14:27.668580+00:00] Ende: Exitcode=0; Status=success; Turns=82; Tokens=5736232; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\RawResult.json

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/anforderungen.md

@@ -0,0 +1,64 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 13 | 11,1 % |
+| SyRS | 20 | 17,1 % |
+| SwRS | 84 | 71,8 % |
+| **Gesamt** | **117** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 43 | 36,8 % |
+| Daten | 23 | 19,7 % |
+| Schnittstelle | 21 | 17,9 % |
+| Sicherheit | 16 | 13,7 % |
+| nicht-funktional | 14 | 12,0 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 191 |
+| davon `PRIMÄR` | 136 (71,2 %) |
+| davon `SEKUNDÄR` | 46 (24,1 %) |
+| davon `KONTEXT` | 9 (4,7 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 114 (97,4 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 106 | 90,6 % |
+| workaround | 4 | 3,4 % |
+| sonderfall | 7 | 6,0 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 114 | 97,4 % |
+| als `HYPOTHESE` gekennzeichnet | 3 | 2,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 60 | 51,3 % |
+| mit ISO-25010-Qualitätsmerkmal | 28 | 23,9 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (26 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 117 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 117 von 117 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/combined_prompt.md

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

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-03T15:14:27.6927641+02:00

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/opencode-config.json

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

Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-03T14:55:51.3674789+02:00

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/high/03_Lauf_2026-09-02_095648_v13.0.0-77c1/Protokoll.md

@@ -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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Adapter.log

@@ -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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/Analysebericht.md

@@ -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).

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/Glossar.md

@@ -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). |

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/Hypothesen.md

@@ -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).

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/StRS.md

@@ -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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Ergebnisse/Traceability.md

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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Protokoll.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)*

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/Stderr.log

@@ -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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/anforderungen.md

@@ -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 %) |
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/combined_prompt.md

@@ -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).

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-03T10:35:27.1935815+02:00

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/opencode-config.json

@@ -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"
+}

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/builtin/max/03_Lauf_2026-09-03_092954_v13.0.0-1eaf/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-03T09:29:55.0464292+02:00

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Protokoll.md

@@ -10,7 +10,7 @@
 - **Endzeit:** 2026-09-02T09:56:48.1729325+02:00
 - **Dauer gesamt:** 00:22:43 (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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-03T07:01:23.272704+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\Ergebnisse)
+[2026-09-03T07:01:23.411046+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=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T07:29:52.324136+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T07:29:54.422734+00:00] OpenCode export: Exporting session: ses_f99ed7003ffeeUQm86XBQsMt1H
+[2026-09-03T07:29:54.453699+00:00] Ende: Exitcode=0; Status=success; Turns=108; Tokens=10220040; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\RawResult.json

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/Analysebericht.md

@@ -0,0 +1,283 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (CentronERP, C#/XAML/WPF + Blazor-Web, MSSQL).
+Untersuchungsgegenstand: gesamtes Arbeitsverzeichnis, keine Modulbeschränkung. Statische Analyse, keine Ausführung.
+
+**Ergebnisumfang:** 24 StRS-, 47 SyRS- und 59 SwRS-Anforderungen (130 gesamt) in den 7 vorgegebenen Ergebnisdateien.
+
+---
+
+## Schritt 0 – Modulinventar
+
+Vollständiger Überblick vor der ersten Anforderung. Das Inventar ist die Bezugsgröße der Abdeckungstabelle und wurde während der Analyse nur ergänzt (u. a. um „Periphere Datendienste“), nicht gekürzt.
+
+| Nr | Modul / Komponente | Pfad (relativ) | Fachliche Aufgabe |
+|---|---|---|---|
+| 1 | Anwendungskern & Verbindungsverwaltung | src\centron\Centron.WPF.UI (App.xaml.cs, CentronApplication.cs, ConnectionHeartbeatTimer.cs, FrontWindow, StartupArgs) | Startet die WPF-Suite, wählt Verbindungsart, hält die Sitzung per Herzschlag und den Hauptrahmenfenster-Workflow |
+| 2 | Modul Finanzen | src\centron\Centron.WPF.UI\Modules\Finances | Arbeitsflächen für Belege, Verträge, Mahnwesen, OPOS, Zahlungen sowie automatisierte, Timer- und Flatrate-Abrechnung |
+| 3 | Modul Helpdesk | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticketlisten/-details, Checklisten, TaskManagement, Ereignisse, SelfCare-Formularversand |
+| 4 | Modul Warenwirtschaft | src\centron\Centron.WPF.UI\Modules\Warehousing | Artikelverwaltung, Inventur, Barcodeverwaltung, Kommissionierung, Materialgruppen |
+| 5 | Modul Einkauf | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellungen und Bestellvorschlagslisten je Filiale |
+| 6 | Modul Datenaustausch | src\centron\Centron.WPF.UI\Modules\DataExchange | Export-/Importarbeitsflächen: FiBu-Übergabe, E-Rechnung, Datenabgleiche |
+| 7 | Modul MyCentron (inkl. Dashboard) | src\centron\Centron.WPF.UI\Modules\MyCentron | Persönlicher Arbeitsplatz: Kalender, MyDay, ToDos, Notizen, Dashboard-Container, Telefonie, persönliche Einstellungen |
+| 8 | Modul Statistiken | src\centron\Centron.WPF.UI\Modules\Statistics | Umsatz-, Auslastungs-, Vertrags- und MSP-Auswertungen |
+| 9 | Modul Verwaltung | src\centron\Centron.WPF.UI\Modules\Administration | Zentrale Verwaltung: Mandanten, Länder, Rechtegruppen, DSGVO, SQL-Werkzeuge, Eskalationen, PDF-Signatur, Mail-/Textvorlagen |
+| 10 | Modul Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Template-basierte Sammeländerungen (u. a. Belegpreisupdates) |
+| 11 | Modul OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | Bankkonten-Verknüpfung und Umsatzverarbeitung |
+| 12 | Modul Passwortmanager | src\centron\Centron.WPF.UI\Modules\PasswordManager | Verwaltete Passwortablage mit Zugriffsprotokoll |
+| 13 | Modul Zahler & Kostenträger | src\centron\Centron.WPF.UI\Modules\PayersAndCostCenter | Verwaltung der verrechnungstechnischen Merkmale |
+| 14 | Modul PLM | src\centron\Centron.WPF.UI\Modules\PLM | Produktlebenszyklus-Import und -pflege |
+| 15 | Modul Produktion | src\centron\Centron.WPF.UI\Modules\Production | Fertigungsauftrags-Arbeitsflächen |
+| 16 | Modul Projektverwaltung | src\centron\Centron.WPF.UI\Modules\ProjectManagement | Projekte/Projektdaten im Belegkontext (ProjNr, CRM-Projekte) |
+| 17 | Modul Projektpreisimport | src\centron\Centron.WPF.UI\Modules\ProjectPriceImport | Import projektspezifischer Preise an Belege |
+| 18 | Modul QM | src\centron\Centron.WPF.UI\Modules\QM | QM-Einstellungen und Beleggründe mit QM-Bezug |
+| 19 | Modul Berichte | src\centron\Centron.WPF.UI\Modules\Reports | Berichtsgruppen, Druck- und PDF-Einstellungen |
+| 20 | Modul RMA | src\centron\Centron.WPF.UI\Modules\Rma | Rücksendeübersichten und RMA-Erfassung |
+| 21 | Modul Vertrieb | src\centron\Centron.WPF.UI\Modules\Sales | Belegarbeitsflächen, Sonderartikel-/Vorlagenimporte, Mailing, Produktmatrix |
+| 22 | Modul Befragungen | src\centron\Centron.WPF.UI\Modules\Survey | Kundenzufriedenheits-Befragungen (Auslösung am Ticketabschluss) |
+| 23 | Modul TelekomDive | src\centron\Centron.WPF.UI\Modules\TelekomDive | Abgleich von Telekom-Anschlussdaten |
+| 24 | Modul Kalender | src\centron\Centron.WPF.UI\Modules\Calendar | Terminverwaltung und Darstellungsoptionen |
+| 25 | Modul Externe Tools | src\centron\Centron.WPF.UI\Modules\ExternalTool | Start externer Programme mit Parameterersetzung |
+| 26 | Modul Logistik | src\centron\Centron.WPF.UI\Modules\Logistic | Versand- und Versandarteneinstellungen |
+| 27 | Modul Global | src\centron\Centron.WPF.UI\Modules\Global | Gemeinsame Werkzeuge: PDF-Anzeige/-Druck, benutzerdefinierte Eigenschaften, Info-Seite |
+| 28 | Modul KI | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Chat-Arbeitsflächen |
+| 29 | C-FLOW-Prozesse | src\centron\Centron.WPF.UI\Processes | Prozessautomatisierung an Tickets und Belegen |
+| 30 | Wizards | src\centron\Centron.WPF.UI\Wizards | Mehrstufige Assistenten (u. a. Abrechnungsdatums-Wizard) |
+| 31 | Client-Dienste & Ressourcen | src\centron\Centron.WPF.UI\Services, Resources, Style, Layout | Clientseitige Dienstinfrastruktur, Lokalisierung (resx DE/EN), Styles |
+| 32 | Adressstamm (Accounts-BL) | src\backend\Centron.BL\Accounts | Kunden/Lieferanten/Kontakte/Bankverbindungen, rechtegefilterte Suche, Aktivitäten |
+| 33 | Belegpipeline (Receipts-BL) | src\backend\Centron.BL\Sales\Receipts | Belegerzeugung/-speicherung, Sperren, Versionen, Übergaben, Provisions-Schemata, Beleg-PDFs |
+| 34 | Rechnung & Mahnwesen (Invoices/Dunning/Opos) | src\backend\Centron.BL\Sales\Receipts\Invoices | Rechnungs-Verhaltensregeln, Mahnläufe, Offene-Posten-Verarbeitung |
+| 35 | Verträge & Stammblätter (CustomerAssets\Contracts) | src\backend\Centron.BL\Sales\CustomerAssets\Contracts | Verträge, ClickContracts, Stammblätter, Zählerimport und -abrechnung |
+| 36 | Helpdesk-BL (Sales\Support) | src\backend\Centron.BL\Sales\Support | Tickets, Zeiten, Status, Vorlagen, Eskalation, Checklisten, Signaturen |
+| 37 | Artikel & Lager (Warehousing-BL) | src\backend\Centron.BL\Warehousing | Artikel, Bestände, Inventur, Barcodes, Bewegungen, Kommissionierung |
+| 38 | Steuerlogik (Warehousing\TaxBL) | src\backend\Centron.BL\Warehousing\TaxBL.cs | Datumsgültige Steuerketten, Default-Kaskade, Umstellungen |
+| 39 | Einkauf-BL (Purchasing) | src\backend\Centron.BL\Purchasing | Lieferanten, Bestellvorschläge, Bestellungen je Filiale |
+| 40 | Kalender-BL | src\backend\Centron.BL\Calendar | Termin- und Anzeigeeinstellungen |
+| 41 | E-Mail (Mail, MailScanner) | src\backend\Centron.BL\Mail, MailScanner | Transporte (SMTP/EWS/Graph), Vorlagen, Signaturen, Blacklist, Mail-Scanner |
+| 42 | Rechteverwaltung (Administration\Rights) | src\backend\Centron.BL\Administration\Rights | Rechteprüfung (Sichtrus/Sichmemb) und Rechteverwaltung |
+| 43 | Authentifizierung & Sitzungen | src\backend\Centron.BL\Administration\Logins (Auth, TwoFactor), TwoFactorAuthenticator, Administration\AccessTokens | Login-Verfahren (Basic/AD/OIDC/Web), Tickets, 2FA, Access-Token |
+| 44 | Lizenzierung | src\backend\Centron.BL\Administration\Licensing | Lizenz- und Anwendungsprüfung bei der Anmeldung |
+| 45 | Nummernkreise | src\backend\Centron.BL\Administration\Mandatory, Administration\Company | Kollisionsfreie Nummernvergabe mit Bereichen/Intervallen je Mandant/Filiale |
+| 46 | Einstellungen | src\backend\Centron.BL\Administration\Settings | Zentrale Konfiguration über ApplicationSettings/AppSettingsConst |
+| 47 | DSGVO/Datensicherheit | src\backend\Centron.BL\Administration\DataSecurity | Rechtegeschützte Bereinigung und Kontaktlöschung |
+| 48 | Mitarbeiter | src\backend\Centron.BL\EmployeeArea, Administration\Employees | Mitarbeiterstamm, Aktivitätsstatus, Auslastungsbezug |
+| 49 | Passwortmanager-BL | src\backend\Centron.BL\PasswordManagementArea | Verschlüsselte Schlüssel, Zugriffs-/Änderungsprotokolle |
+| 50 | Datenübernahme & E-Rechnung | src\backend\Centron.BL\DataExchange, EDI | ZUGFeRD/XRechnung, Lieferanten-EDI, DocBee, GfK, Zahlungs- und Fremdimporte |
+| 51 | FiBu-Schnittstellen | src\backend\Centron.Gateway | Formatklassen für Buchhaltungssysteme (DATEV, Abacus, Sage, …) |
+| 52 | Zahlungen & OnlineBanking-BL | src\backend\Centron.BL\Finances | Zahlungen, Zahlungseingänge, FinAPI-Abgleich |
+| 53 | Statistiken-BL | src\backend\Centron.BL\Statistics | Umsatz-, Auslastungs-, MSP- und Cache-Statistiken |
+| 54 | Berichtsengine | src\backend\Centron.BL\ReportEngine, Reporting | Vorlagen, Datenabfragen, PDF-Strategien, Filename-Regeln |
+| 55 | Produktion-BL | src\backend\Centron.BL\Production | Fertigungsaufträge/-positionen |
+| 56 | Aufgaben & ToDos | src\backend\Centron.BL\TaskManager, ToDoArea, MyDay | Aufgaben-, Erinnerungs- und Tageslogik |
+| 57 | Änderungsverfolgung | src\backend\Centron.BL\ChangeTracking | Import-Historie und Änderungsnachweise |
+| 58 | Benachrichtigungen | src\backend\Centron.BL\Notifications, NexusNotifications | Ereignis- und E-Mail-Benachrichtigungen |
+| 59 | KI-Chat | src\backend\Centron.BL\Administration\ArtificialIntelligence | Chat-Instruktionen und -Konfiguration |
+| 60 | RMA-BL | src\backend\Centron.BL\CustomerArea | RMA-Scheine, Sendarten, Artikelhistorie |
+| 61 | Entitäten & Schnittstellen | src\backend\Centron.Entities, Centron.Interfaces, Centron.Common | Domänenobjekte, Enums (u. a. BarcodeState), gemeinsame Kontrakte |
+| 62 | REST-Host & Authentifizierung | src\webservice\Centron.Host | API-Host, Ticket-/Token-Handler, Swagger, Versionierung, SignalR |
+| 63 | Hintergrunddienste | src\webservice\Centron.Host\AspNetCore\HostedServices | Über 40 periodische Dienste (Verträge, Caches, Sync, Massenupdates, …) |
+| 64 | Webservice-Kern | src\webservice\Centron.WebServices.Core | DTOs/Entities, RestRequests, Rechtekonstanten |
+| 65 | Verbindungs- & Controller-Schicht | src\webservice\Centron.Controllers, c-entron.misc.ConnectionManager | Verbindungsvermittlung für Clients |
+| 66 | Kundencenter & WebCart | src\nexus\CentronNexus\WebCart, WebOffer, CustomerPortal-* | Kundenportal: Shop, Belege, Tickets, Formulare |
+| 67 | ServiceBoard | src\nexus\CentronNexus\ServiceBoard | Cache-basierte Ticket-Kanban-/Listenansichten mit Filtern |
+| 68 | Dokumentunterschrift | src\nexus\CentronNexus\DocumentSigning | Browser-Signaturerfassung per Signature-Pad |
+| 69 | Management & Office (Web) | src\nexus\CentronNexus\Management, Office, ProductionOrderManagement | Web-Verwaltungsansichten (Tasks, Personal, Fertigung) |
+| 70 | Nexus-Host | src\nexus\CentronNexus.Host | Blazor-Infrastruktur, Datei-, Branding- und Culture-Controller |
+| 71 | Outlook-AddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Integration |
+| 72 | FinAPI-Client | src\apis\Centron.APIs.FinAPI | Bank-API-Client |
+| 73 | Versandclients | src\apis\Centron.Api.Gls, Centron.Api.Shipcloud | Paketdienst-Clients |
+| 74 | E-Rechnung Österreich | src\apis\Centron.Api.EbInterface | ebInterface-Erzeugung |
+| 75 | Produktdaten | src\apis\Centron.APIs.ITscopeDataAccess, Centron.APIs.IcecatDataAccess | Produktdaten-Import-Clients |
+| 76 | Cop/Egis Data Access | src\apis\Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess | Fremddaten-Zugriffsklassen |
+| 77 | Steuerelemente | src\shared\Centron.Controls, Centron.Controls.Preview | Wiederverwendbare UI-Bausteine (Task-, Ticket-, Kalender-Views) |
+| 78 | Basisbibliothek | src\shared\Centron.Core | Result<T>, Google-Authenticator-Implementierung, Netz-/Text-Utils |
+| 79 | Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-DDL (1.558 Tabellen, 134 FK-, 101 UNIQUE-Constraints) |
+| 80 | Skript-Infrastruktur | scripts | DB-Upgrade-Tooling (Skriptnummern, Signatur, Umgebungen) |
+| 81 | Paketierung & Deployment | deployment, docker, azure, azure-blazor, .github | WiX-Installer, Container, CI/CD-Definitionen |
+| 82 | Tests | tests | E2E-, Integrations- und Playwright-Tests |
+| 83 | Dokumentation | docs | Entwickler-/Feature-Dokumentation, Richtlinien |
+| 84 | Periphere Datendienste | src\backend\Centron.BL\VoucherManagement, SocialMedia, ProductMatrix, WebLinks, Tapi, RiverDivo, CPra, SelfCare, VideoPortal, TradePool, ItPlanner, Storage, ExternalHelpdesk; RestService-Parts RMM/RiverDivo/CPra | Kleine Zusatz- und Anbindungsbereiche (Gutscheine, Social-Media-Streams, Telefonie, Fernwartung, Selbstservice) |
+
+---
+
+## Abdeckungstabelle
+
+Einstufung je Inventarzeile: `tief` (Kernklassen gelesen, mehrere Anforderungen), `mittel` (mehrere Anforderungen bzw. BL-Klassen gelesen), `flach` (Mindestabdeckung über Datei-/UI-/Schema-Ebene), `nicht analysiert`. „Anz. Anf." zählt die Anforderungen, die das Modul maßgeblich abbilden (eine Anforderung kann mehrere Module streifen; sie wird nur beim Hauptmodul gezählt).
+
+| Nr | Modul | Abdeckung | Anz. Anf. |
+|---|---|---|---|
+| 1 | Anwendungskern & Verbindungsverwaltung | flach | 1 (SyRS-001) |
+| 2 | Modul Finanzen | mittel | 4 (SyRS-015, SyRS-016, SwRS-009, SwRS-010) |
+| 3 | Modul Helpdesk | mittel | 3 (SyRS-019, SyRS-020, SwRS-013) |
+| 4 | Modul Warenwirtschaft | mittel | 3 (SwRS-018, SwRS-021, SwRS-022) |
+| 5 | Modul Einkauf | flach | 1 (SwRS-023) |
+| 6 | Modul Datenaustausch | mittel | 2 (SwRS-024, SwRS-025) |
+| 7 | Modul MyCentron (inkl. Dashboard) | mittel | 3 (SyRS-044, SwRS-044, SwRS-045) |
+| 8 | Modul Statistiken | mittel | 2 (SyRS-035, SwRS-041) |
+| 9 | Modul Verwaltung | tief | 5 (SwRS-032, SwRS-033, SwRS-037, SyRS-040, SyRS-004) |
+| 10 | Modul Massenupdates | flach | 1 (SyRS-036) |
+| 11 | Modul OnlineBanking | mittel | 2 (SyRS-030, SwRS-027) |
+| 12 | Modul Passwortmanager | flach | 1 (SwRS-031) |
+| 13 | Modul Zahler & Kostenträger | flach | 1 (SyRS-014) |
+| 14 | Modul PLM | flach | 1 (SwRS-052) |
+| 15 | Modul Produktion | flach | 2 (SyRS-046, SwRS-043) |
+| 16 | Modul Projektverwaltung | flach | 1 (SwRS-004) |
+| 17 | Modul Projektpreisimport | flach | 1 (SwRS-006) |
+| 18 | Modul QM | flach | 1 (SyRS-046) |
+| 19 | Modul Berichte | mittel | 2 (SyRS-034, SwRS-042) |
+| 20 | Modul RMA | mittel | 2 (SyRS-047, SwRS-047) |
+| 21 | Modul Vertrieb | flach | 1 (SwRS-008) |
+| 22 | Modul Befragungen | flach | 1 (SyRS-020) |
+| 23 | Modul TelekomDive | flach | 1 (SwRS-052) |
+| 24 | Modul Kalender | mittel | 2 (SyRS-032, SwRS-030) |
+| 25 | Modul Externe Tools | flach | 1 (SwRS-052) |
+| 26 | Modul Logistik | flach | 1 (SwRS-026) |
+| 27 | Modul Global | flach | 1 (SwRS-058) |
+| 28 | Modul KI | flach | 2 (SyRS-045, SwRS-046) |
+| 29 | C-FLOW-Prozesse | flach | 1 (SwRS-017) |
+| 30 | Wizards | flach | 1 (SyRS-017) |
+| 31 | Client-Dienste & Ressourcen | mittel | 2 (SyRS-038, SwRS-057) |
+| 32 | Adressstamm (Accounts-BL) | tief | 3 (SwRS-001, SwRS-002, SwRS-003) |
+| 33 | Belegpipeline (Receipts-BL) | tief | 5 (SyRS-011, SyRS-012, SyRS-013, SwRS-004, SwRS-007) |
+| 34 | Rechnung & Mahnwesen | tief | 5 (SwRS-005, SwRS-006, SwRS-009, SwRS-010, SyRS-015) |
+| 35 | Verträge & Stammblätter | tief | 4 (SwRS-011, SwRS-012, SyRS-017, SyRS-018) |
+| 36 | Helpdesk-BL | tief | 6 (SwRS-013–017, SyRS-021) |
+| 37 | Artikel & Lager (BL) | tief | 3 (SwRS-018, SwRS-021, SwRS-022) |
+| 38 | Steuerlogik | tief | 3 (SwRS-019, SwRS-020, SyRS-023) |
+| 39 | Einkauf-BL | flach | 1 (SwRS-023) |
+| 40 | Kalender-BL | flach | 1 (SwRS-030) |
+| 41 | E-Mail (BL) | tief | 3 (SwRS-028, SwRS-029, SyRS-031) |
+| 42 | Rechteverwaltung (BL) | tief | 4 (SyRS-005, SyRS-006, SwRS-032, SwRS-033) |
+| 43 | Authentifizierung & Sitzungen | tief | 5 (SwRS-034, SwRS-035, SwRS-036, SyRS-003, SyRS-008) |
+| 44 | Lizenzierung | mittel | 1 (SyRS-004) |
+| 45 | Nummernkreise | tief | 3 (SyRS-010, SwRS-005, SwRS-038) |
+| 46 | Einstellungen | mittel | 1 (SwRS-037) |
+| 47 | DSGVO/Datensicherheit | mittel | 2 (SyRS-040, SwRS-039) |
+| 48 | Mitarbeiter | flach | 1 (SwRS-034) |
+| 49 | Passwortmanager-BL | flach | 1 (SwRS-031) |
+| 50 | Datenübernahme & E-Rechnung | tief | 4 (SwRS-023, SwRS-024, SwRS-052, SyRS-026) |
+| 51 | FiBu-Schnittstellen | mittel | 2 (SwRS-025, SyRS-027) |
+| 52 | Zahlungen & OnlineBanking-BL | mittel | 2 (SwRS-027, SyRS-030) |
+| 53 | Statistiken-BL | mittel | 2 (SwRS-041, SyRS-035) |
+| 54 | Berichtsengine | mittel | 2 (SwRS-042, SyRS-034) |
+| 55 | Produktion-BL | flach | 1 (SwRS-043) |
+| 56 | Aufgaben & ToDos | flach | 1 (SwRS-044) |
+| 57 | Änderungsverfolgung | flach | 1 (SwRS-040) |
+| 58 | Benachrichtigungen | flach | 2 (SwRS-045, SyRS-037) |
+| 59 | KI-Chat (BL) | flach | 1 (SwRS-046) |
+| 60 | RMA-BL | flach | 1 (SwRS-047) |
+| 61 | Entitäten & Schnittstellen | mittel | 2 (SwRS-022, SwRS-032) |
+| 62 | REST-Host & Authentifizierung | tief | 4 (SyRS-002, SwRS-036, SyRS-037, SyRS-042) |
+| 63 | Hintergrunddienste | tief | 3 (SyRS-036, SyRS-017, SyRS-044) |
+| 64 | Webservice-Kern | mittel | 2 (SwRS-032, SwRS-037) |
+| 65 | Verbindungs- & Controller-Schicht | flach | 1 (SyRS-001) |
+| 66 | Kundencenter & WebCart | mittel | 2 (SwRS-048 [HYPOTHESE], SyRS-009) |
+| 67 | ServiceBoard | flach | 1 (SwRS-050) |
+| 68 | Dokumentunterschrift | flach | 1 (SwRS-049) |
+| 69 | Management & Office (Web) | flach | 1 (SwRS-050) |
+| 70 | Nexus-Host | flach | 1 (SyRS-042) |
+| 71 | Outlook-AddIn | flach | 1 (SwRS-051) |
+| 72 | FinAPI-Client | flach | 1 (SwRS-027) |
+| 73 | Versandclients | flach | 1 (SwRS-026) |
+| 74 | E-Rechnung Österreich | flach | 1 (SwRS-024) |
+| 75 | Produktdaten | flach | 1 (SwRS-052) |
+| 76 | Cop/Egis Data Access | flach | 1 (SwRS-023) |
+| 77 | Steuerelemente | flach | 1 (SyRS-038) |
+| 78 | Basisbibliothek | flach | 1 (SwRS-034) |
+| 79 | Datenbankschema | tief | 4 (SwRS-001, SwRS-004, SwRS-013, SyRS-039) |
+| 80 | Skript-Infrastruktur | flach | 1 (SwRS-054) |
+| 81 | Paketierung & Deployment | flach | 1 (SwRS-055) |
+| 82 | Tests | flach | 1 (SwRS-053) |
+| 83 | Dokumentation | flach | 1 (SwRS-053) |
+| 84 | Periphere Datendienste | flach | 1 (SwRS-059) |
+
+**Summen:** 84 Module: tief 16, mittel 22, flach 46, nicht analysiert 0. Anteil „nicht analysiert": 0 % (Schwelle 10 % deutlich unterschritten).
+Anforderungen gesamt: 24 StRS + 47 SyRS + 59 SwRS = 130.
+
+---
+
+## Konsistenzcheck (über das gesamte Anforderungs-Set)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Doppelte oder mehrfach vergebene IDs | **Keine.** StRS-001…024, SyRS-001…047, SwRS-001…059 je fortlaufend und eindeutig. |
+| Anforderungen ohne Beleg | **Keine.** Alle 130 Anforderungen führen ≥ 1 Beleg mit Begründung; Klassifikation PRIMÄR/SEKUNDÄR/KONTEXT je Beleg vorhanden. |
+| Anforderungen ohne Übernahmewürdigkeit | **Keine.** Feld in allen 130 Blöcken gefüllt (übernehmen / Workaround / Sonderfall) mit Begründung. |
+| Tracelinks auf nicht existierende IDs | **Keine.** Alle referenzierten StRS-/SyRS-/SwRS-IDs existieren; Trace-Matrix in `Traceability.md` deckt jede SwRS-Anforderung und jede StRS-Anforderung ab (jede StRS hat ≥ 1 SyRS-Kind). |
+| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | **Keine gefunden.** Abgrenzungen dokumentiert: SwRS-005 (Sonderfälle Kunden-/Kreditornummern) vs. SwRS-038 (Nummernkreis-Entitäten je Mandant/Filiale) sind komplementär, nicht deckungsgleich; SwRS-018/019/020 (Artikel-Steuermodell / Kettenermittlung / Umstellung) behandeln getrennte Aspekte. Echte Konsolidierungsfälle (Gerätedaten-Streuhaltung, FiBu-Formate, ExtraKind, Auth-Varianten) sind in `Traceability.md` Abschnitt „Konsolidierungskandidaten" und in den Feldern `Konsolidierung` markiert. Ebenschilderung: SyRS-005/SyRS-006 (Rechte) und SyRS-040/SyRS-041 (DSGVO/Audit) sind bewusst getrennte Aspekte (Prüfung vs. Bereinigung vs. Protokollierung). |
+| Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) | Siehe Tabelle unten: 39 Anforderungen, davon 38 mit PRIMÄR-Beleg (durchsetzende Stelle benannt), 1 korrekt als HYPOTHESE gekennzeichnet (SwRS-048). |
+| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | **Deckungsgleich.** Genau eine Inline-[HYPOTHESE]-Markierung (SwRS-048, `Status: HYPOTHESE` in SwRS.md) und genau dieser Eintrag in `Hypothesen.md`; keine zusätzlichen freien Fragen in `Hypothesen.md` (offene Punkte stehen in der Selbstbewertung). |
+
+### Risikorelevante Anforderungen mit Belegsituation
+
+| ID | Titel | PRIMÄR-Beleg (durchsetzende Stelle) | Status |
+|---|---|---|---|
+| SyRS-002 | REST-API mit Ticket-/Token-Authentifizierung | TicketAuthenticationHandler.cs:44-95; AccessTokenBL.cs:377-486 | belegt |
+| SyRS-003 | Sitzungsverwaltung über Tickets | TicketBL.cs:113-129; Authenticator.cs:124-129 | belegt |
+| SyRS-004 | Lizenzprüfung bei der Anmeldung | Authenticator.cs:100-155 (LicenseManager.CheckLicense) | belegt |
+| SyRS-005 | Serverseitige Rechteprüfung | AppRightsBL.cs:95-111 (SQL Sichtrus/Sichmemb); AccountBL.cs:1299-1370 | belegt |
+| SyRS-006 | Datenbeschränkende Rechte | AppRightsBL.cs:42-47; AccountSearchBL.cs:331 | belegt |
+| SyRS-007 | Kontosperrung/Mitarbeiterstatus | Authenticator.cs:157-218 (ValidateAppUser) | belegt |
+| SyRS-008 | Zwei-Faktor-Authentifizierung | TwoFactorAuthenticationBL.cs:43-54; TwoFactorAuthBL.cs:103-189 | belegt |
+| SyRS-009 | Web-Konto-Anmeldung | WebAccountAuthenticator.cs:42-83; DB WebAccounts | belegt |
+| SyRS-040 | DSGVO-Bereinigung mit Rechteabsicherung | DataSecurityBL.cs:36-66, 379 | belegt |
+| SyRS-041 | Protokollierung Rechte/Passwörter/Änderungen | DB SichProtokoll; PasswordManagementAccessLogBL.cs:22-33; AccessTokenBL.cs:186-280 | belegt |
+| SyRS-010 | Kollisionsfreie Nummernvergabe | NumberGroupBL.cs:62-91 (konditionelles Update) | belegt |
+| SyRS-014 | Rechnungsbehandlung (Pflichtfelder/Lager) | InvoiceSpecificLogic.cs:216-304 | belegt |
+| SyRS-015 | Mahnlauf mit Sperrwirkung | DunningBL.cs:341-456; DB RechKopf Mahnfelder | belegt |
+| SyRS-016 | Offene Posten/Zahlungszuordnung | OposBL.cs:28; DB RechKopf.Bezahlt | belegt |
+| SyRS-017 | Vertragsabrechnung als Hintergrunddienst | ContractEndeService.cs:8-16 | belegt |
+| SyRS-018 | Zählerstände erfassen/zurordnen | DeviceClickCounterBL.cs:30-128 | belegt |
+| SwRS-002 | Kundensuche mit Rechtefilter | AccountSearchBL.cs:76-79, 331-336 | belegt |
+| SwRS-003 | Bankverbindungen mit Rechten | BankAccountBL.cs:72-81 | belegt |
+| SwRS-005 | Nummernkreis-Sonderfälle Kunden/Kreditor | NumberGroupBL.cs:114-131 | belegt |
+| SwRS-006 | Rechnungs-Verhaltensregeln | InvoiceSpecificLogic.cs:216-368 | belegt |
+| SwRS-007 | Negative Artikelbuchungen nur mit Recht | InvoiceSpecificLogic.cs:239-240 | belegt |
+| SwRS-008 | Rechtevalidierung bei Beleg-/Stammdatenaktionen | AccountBL.cs:1299-1370; AccountAddressContactBL.cs:375-413 | belegt |
+| SwRS-009 | Mahnlauf-Verarbeitung | DunningBL.cs:341-456, 1059 | belegt |
+| SwRS-010 | OPOS-Verarbeitung | OposBL.cs:28; DB RechKopf.Bezahlt | belegt |
+| SwRS-011 | Vertrag-Stammblatt-Verknüpfung | SaveReceiptContractRepository.cs:364-365 | belegt |
+| SwRS-012 | Zählerzuordnung zu Stammblättern | DeviceClickCounterBL.cs:87-128 | belegt |
+| SwRS-015 | Helpdesk-Rechtekatalog | HelpdeskTimerWebServiceBL.cs:359-374; HelpdeskPatternWebserviceBL.cs:351-395 | belegt |
+| SwRS-019 | Steuerketten-Auflösung pro Position | TaxBL.cs:207-237, 286-320 | belegt |
+| SwRS-020 | Steuersatz-Umstellung mit Preisübernahme | TaxBL.cs:84-156 | belegt |
+| SwRS-025 | FiBu-Format-Registry | Gateway: IBookKeepingExport + Formatklassen | belegt |
+| SwRS-027 | FinAPI-Umsatzabgleich | OnlineBankingFinApiBL.cs; src\apis\Centron.APIs.FinAPI | belegt |
+| SwRS-031 | Passwortmanager mit Zugriffsprotokoll | PasswordManagementKeywordBL.cs:21-27; PasswordManagementAccessLogBL.cs:22-33 | belegt |
+| SwRS-032 | Rechtekonstanten-Katalog | UserRightsConst.cs (2301 Zeilen, z. B. SHOW_HELPDESK=20400295) | belegt |
+| SwRS-033 | Rechtegruppen-Zuordnung/-Reset | AppRightsBL.cs:63-87; CentronRestService.cs:344-356 | belegt |
+| SwRS-034 | Login-Prüfsequenz | BasicAuthenticator.cs:46-50 (SHA1, Salting-TODO); Authenticator.cs:169-217 | belegt |
+| SwRS-035 | Ticket-Ablage mit IP-Hinterlegung | TicketBL.cs:32-49, 113-129, 183-186 | belegt |
+| SwRS-036 | Access-Token-Verwaltung (Hash) | AccessTokenBL.cs:377-389, 478-486 | belegt |
+| SwRS-039 | DSGVO-Kontaktlöschung | DataSecurityBL.cs:379 | belegt |
+| SwRS-046 | KI-Chat mit Verwaltungsrecht | ArtificialIntelligenceChatInstructionPromptBL.cs:314 | belegt |
+| SwRS-048 | WebCart-Preisfindung aus Sonderpreisen | **kein PRIMÄR-Beleg** (nur README [KONTEXT] + UI [SEKUNDÄR]) | **HYPOTHESE** (regelkonform gekennzeichnet) |
+
+---
+
+## Selbstbewertung
+
+**Module tief/mittel/flach/nicht analysiert (absolute Zahlen):**
+- tief: 16 von 84 (u. a. Belegpipeline, Rechnung/Mahnwesen, Verträge/Stammblätter, Helpdesk-BL, Steuerlogik, Rechteverwaltung, Authentifizierung, Nummernkreise, Datenübernahme/E-Rechnung, REST-Host, Hintergrunddienste, Datenbankschema)
+- mittel: 22 von 84
+- flach: 46 von 84
+- nicht analysiert: 0 von 84 (0 %, Schwelle 10 % unterschritten)
+
+**Mindestabdeckung:** Ja — jedes der 84 Inventarmodule hat mindestens eine Anforderung (siehe Abdeckungstabelle, letzte Spalte). Kein Modul ist ohne Anforderung oder ohne `nicht analysiert`-Begründung.
+
+**Belegqualität / dünne Belegstellen:**
+- Dünn (hoher SEKUNDÄR-/KONTEXT-Anteil, UI- oder Datei-listenbasiert): Modul Logistik (26), Externe Tools (25), TelekomDive (23), Befragungen (22), Projektverwaltung (16), QM (18), Global/Custom Properties (27), Outlook-AddIn (71), Cop/Egis (76) sowie Teile der „Peripheren Datendienste" (84, insbesondere CPra: nur Connector-Präsenz).
+- SyRS-045 (Mobile): Umfang der Mobile-Endpunkte nur als Präsenz geprüft (`src\backend\Centron.BL\Mobile`, DAO\Mobile) — bewusst nicht tief analysiert und im Prüfidee-Text als eingeschränkt ausgewiesen.
+- SwRS-021 (Inventur) wurde nachträglich anhand konkreter Methoden (CheckInventory, SaveInventory) verifiziert; SwRS-049 (Signaturen) ebenfalls (AddSignature/GetSignature).
+
+**Hypothesen:** Genau eine Hypothese (SwRS-048, WebCart-Preisfindung). Begründung: Die Analyse hat die meisten Kernpfade direkt anhand durchsetzender Stellen gelesen (Rechte-SQL, Login-Sequenz, Nummernvergabe, Steuerketten, Belegregeln, Ticketabschluss); die WebCart-Preislogik lag außerhalb des gelesenen Pfadumfangs (nur README + Razor-Seiten). Eine Analyse ohne jeden offenen Punkt wäre bei ~21.700 Quelldateien nicht glaubhaft; die kleine Zahl reflektiert den Fokus auf belegbare Kernregeln statt auf Vollständigkeit jeder UI-Unterseite.
+
+**Erkenntnisse, die einen Nachschlag in einer Folge-Iteration nahelegen:**
+1. **WebCart-Preisfindung** (SwRS-048): Datenpfad Sonderpreise → WebCart-Sortiment im Code verifizieren (Kandidat: `CustomerSpecialArticleBL`).
+2. **Provisionslogik**: `ReceiptProvisionSchemaBL/EmployeeLevel/EmployeeGoal` (Belegpipeline) wurden im Inventar erfasst, aber nicht als eigene Anforderung vertieft — Abrechnungsrelevant, PRIMÄR-Analyse offen.
+3. **Mobile-Umfang** (SyRS-045): Endpunkte und Fachfunktionen der Mobile-Schicht konkret erfassen.
+4. **CPra / SelfCare / TradePool / RiverDivo/RMM**: fachliche Einordnung und Wirkungsbereich klären (aktuell nur Präsenz, SwRS-059).
+5. **Rechte-Abdeckung**: `UserRightsConst` (2.301 Zeilen) gegen die tatsächlich prüfenden Webservice-Methoden abgleichen, um unbeaufsichtigte Aktionen (Rechte ohne Prüfstelle) zu finden.
+6. **ExtraKind-Semantik** (SwRS-011): Bedeutung der Werte 1/3 über Delphi-Legacy/DB-Daten bestätigen.
+7. **Massenupdates**: Regelwerk der `StartReceiptPriceUpdate`-Ausführung (Stornierung, Historie) vertiefen.
+8. **Alte FiBu-/EDI-Formate**: fachliche Entscheidung `veraltet` vs. `übernehmen` je Zielsystem (LexwarePro2011, DATEV-XmlOnline 2012, Sage OfficeLine).

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/Glossar.md

@@ -0,0 +1,45 @@
+# Glossar
+
+Domänenbegriffe, wie sie in StRS/SyRS/SwRS verwendet werden. Technische Bezeichner (Klassen, Tabellen, Spalten) bleiben in Originalsprache.
+
+| Begriff | Definition | Belegherkunft |
+|---|---|---|
+| **Adressstamm** | Zentrale Verwaltung von Geschäftspartnern: Kunden (`Kunden`), Lieferanten (`Kreditor`), Anschriften (`Anschrif`), Kontaktpersonen (`Personen`); gemeinsame Account-Basis mit Typzuordnung (`AccountCustomers`, `AccountSuppliers`). | DB-Schema; AccountBL |
+| **Account** | Internes Objektmodell eines Geschäftspartners im Adressstamm (Kunde und/oder Lieferant). | src\backend\Centron.BL\Accounts |
+| **Beleg (Receipt)** | Oberbegriff für Handelsdokumente: Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Stammblatt; im Code `IReceiptBase` / `CentronObjectKindNumeric`. | InvoiceSpecificLogic; AssetKindEnum |
+| **Belegkette / Übergabe** | Weiterführung von Positionen entlang Angebot → Auftrag → Lieferschein → Rechnung (→ Gutschrift); erlaubte Richtungen je Belegart (`CanBeForwardedFrom/Into`). | InvoiceSpecificLogic.cs:279-311 |
+| **Belegversion** | Änderungsstufe eines Belegs (`RechKopf.Version`); wesentliche Änderungen erzeugen eine neue Version. | SSMS_DB_SCHEMA.sql; ReceiptBL |
+| **Begrenzung („restricting right")** | Rechte, die den Datenbereich einschränken: nur eigene Datensätze, nur eigene Filiale, nur eigene Abteilung (z. B. SHOW_HELPDESK_ONLY_OWN_BRANCH). | CentronRights.md |
+| **Filiale (Branch)** | Organisatorische Untereinheit eines Mandanten; beeinflusst Nummernkreise, Rechtegruppen und Datenbereiche. | SSMS_DB_SCHEMA.sql `Filiale`; NumberGroupBL |
+| **Mandant** | Rechtlich selbstständiger Datenbereich (Mandantenfähigkeit); Nummernkreise hängen am Standardmandant mit BranchI3D je Filiale. | NumberGroupBL.cs:136-152 |
+| **Mahnstufe** | Zeit-/prozessbezogene Eskalationsstufe einer offenen Forderung (1-3) mit Stufentexten und optionaler Gerätesperre (`CustomerAssetsLockedAfterDunningLevel`). | AppSettingsConst.cs:100-104; DunningBL |
+| **OPOS (Offene Posten)** | Unbeglichene Rechnungen bzw. Restbeträge; Zahlungsstand in `RechKopf.Bezahlt`. | OposBL; DB-Schema |
+| **Stammblatt** | Kundenbezogene Geräteliste (im Code `MasterDataList`, `CentronObjectKindNumeric.MasterDataListClass`), vor allem für Mess-/Druckgeräte mit Zählern; vertragsbezogen verknüpfbar (`Stammblattbezogen`). | AssetKindEnum.cs:77; SaveReceiptContractRepository.cs:364 |
+| **Zähler / ClickCounter** | Verbrauchswerte eines Stammblattgeräts (z. B. Druckvolumen); Import via SNMP, Zuordnung per Zählerart-Mapping; Basis der Click-Abrechnung. | DeviceClickCounterBL |
+| **ClickContract** | Vertrag, der mengenbasiert (per Zählerstand) abgerechnet wird. | ClickContracts-Ordner |
+| **Ticket / Helpdesk** | Serviceanfrage im Helpdesk-Modul (`hlpdsk_requests`) mit Typen, Kategorien, Prioritäten, Status, Zeiten, Checklisten, Vorlagen. | DB-Schema; Helpdesk-BL |
+| **C-FLOW** | Ticketprozess-/Mustervorlagen (C-FLOW-Ticketpatterns) mit eigenen Verwaltungsrechten. | CentronRights.md 17.x; HelpdeskPatternBL |
+| **Zeit / Timer** | Abrechenbare Arbeitszeit am Ticket (`HelpdeskTimer`), mit Artikelbuchung, Anfahrtsartikeln und Kundensignatur. | HelpdeskTimer*-BL |
+| **Web-Konto (WebAccount)** | Externes Kundenkonto für das Web-Kundencenter (`WebAccounts`), zugeordnet zu Kunde/Anschrift/Person, mit eigener 2FA-Konfiguration. | DB-Schema WebAccounts; WebAccountAuthenticator |
+| **WebCart** | Web-Shop im c-entron Nexus für Kunden der Kunden; Sortiment/Preise aus Sonderpreisen des Kunden. | README.md |
+| **Nexus** | Web-Frontend (Blazor) mit Kundencenter, ServiceBoard, Dokumentunterschrift, WebCart. | src\nexus |
+| **ServiceBoard** | Cache-basierte Ticket-Kanban-/Listenansicht im Nexus mit Filter- und Formatierungsregeln. | ServiceBoard-Ordner |
+| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler pro Belegart/Objektart je Mandant/Filiale mit Bereich und Intervall; vergibt Beleg- und Objektnummern kollisionsfrei. | NumberGroupBL |
+| **Recht / Sichtrus** | Numerisches Feinrecht (`UserRightsConst`), Gruppenzuweisung über `Sichtrus` (Gruppe↔Recht) und `Sichmemb` (Gruppe↔Benutzer). | AppRightsBL.cs:95-111 |
+| **Sitzung / Ticket (Auth)** | Anmeldungsnachweis als `Ticket` (Ablaufdatum, IP, Maschine) bzw. Personal Access Token (SHA-256-Hash). | TicketBL; AccessTokenBL |
+| **Zwei-Faktor-Authentifizierung (2FA)** | Zweiter Nachweisfaktor: TOTP (Google Authenticator), RADIUS oder E-Mail-Link; Web-Konten mit Gültigkeitsdauer in Tagen. | TwoFactorAuthenticationBL; TwoFactorAuthBL |
+| **MwSt-Kette (TaxRate chain)** | Verketteung von Steuersätzen über `NextTaxRate`/`ExpirationDate`, um zum Belegdatum gültige Sätze zu ermitteln. | TaxBL.cs:207-237 |
+| **WEEE** | Elektrogerätegesetz-Pflichtkennzeichnung (`IsWeeeRequired` je Belegart konfigurierbar). | InvoiceSpecificLogic.cs:304 |
+| **EDV/EDI** | Elektronischer Datenaustausch mit Lieferanten (Alltron, Also, Komsa, Opentrans, Egis, …) über den EDI-Gateway. | src\backend\Centron.BL\EDI |
+| **ZUGFeRD / XRechnung** | Deutsche E-Rechnungsformate/Versionen (2.x, 3.x) für Rechnungsexport. | InvoiceZugferdBL; XInvoiceVersion3 |
+| **ebInterface** | Österreichisches E-Rechnungsformat (eigenes API-Projekt). | src\apis\Centron.Api.EbInterface |
+| **FinAPI** | Bankenschnittstelle für Online-Banking-Umsatzabruf und Zahlungszuordnung. | OnlineBankingFinApiBL; src\apis\Centron.APIs.FinAPI |
+| **FiBu-Export** | Übertragung abgeschlossener Belege in Finanzbuchhaltungssysteme (DATEV, Abacus, Sage, SAP, …). | src\backend\Centron.Gateway |
+| **RMA** | Rücksendeschein mit Artikelpositionen, Sendart und Historie. | RmaBL |
+| **DSGVO-Modul** | Rechtegeschützte Bereinigung: Kontaktlöschung (DSGVO_DELETE_CONTACT) und Datenbank-Cleanup (ACCESS_CLEANUP_DATABASE). | DataSecurityBL |
+| **Sonderpreise** | Kundenspezifische Artikelpreise im Adressstamm; Quelle für WebCart (Hypothese SwRS-048). | README.md |
+| **Workaround (Übernahmewürdigkeit)** | Historisch gewachsene Behelfslösung, die im Zielsystem bewusst anders (sauberer) umgesetzt werden soll. | Prompt-Definition |
+| **Kostenstelle / Kostenträger** | Interne verrechnungstechnische Merkmale; bei Rechnungen verpflichtend (`IsCostCenterNeeded/IsCostCarrierNeeded`). | InvoiceSpecificLogic.cs:221-222 |
+| **Massenupdate** | Template-basierte Sammeländerung (u. a. Belegpreise), ausgeführt als Hintergrunddienst. | MassUpdateBL; MassUpdateService |
+| **MyDay** | Persönliche Tagesübersicht eines Benutzers (Termine, ToDos, Notizen) mit Benachrichtigungsdienst. | MyDay-BL; SendMyDayNotificationsService |
+| **Stammblatt der Zeit** | Konfigurierbare Kalenderanzeige: Anzeige des Stammblatts an einer erfassten Zeit (Einstellungs-ID 1630). | CalendarBL; AppSettingsConst 1630 |

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/Hypothesen.md

@@ -0,0 +1,17 @@
+# Hypothesen
+
+Sammlung aller Anforderungen, deren `Status` auf `HYPOTHESE` steht. Diese Datei deckungsgleich mit den Inline-`[HYPOTHESE]`-Markierungen in den Spezifikationsdateien.
+
+---
+
+## SwRS-048 – WebCart-Preisfindung aus Kunden-Sonderpreisen
+
+| Feld | Inhalt |
+|---|---|
+| Ebene / ID | SwRS-048 |
+| Titel | WebCart-Preisfindung aus Kunden-Sonderpreisen |
+| Tracelinks | SyRS-009 (Web-Konto-Anmeldung) → StRS-021 (Selbstservice-Kundencenter) |
+| Belegsituation | [KONTEXT] README.md, Abschnitt „Contributing/WebCart" (beschreibt Zielgruppe und Preisquelle „Sonderpreise"); [SEKUNDÄR] WebCart-Razor-Seiten (`src\nexus\CentronNexus\WebCart\WebCartShopPage.razor` u. a.) belegen das Feature, nicht die Preislogik |
+| Offene Frage | Über welche Codepfade werden die „Sonderpreise" des Kunden (Adressstamm) in das WebCart-Sortiment/-Preismodell übernommen (Webservice-Methode, Filter, Mengen-/Rabattlogik)? |
+| Fehlende Information zur Bestätigung | Die durchsetzende Stelle (BL-/Controller-Methode, die Sonderpreise lädt) wurde im verfügbaren Analyseumfang nicht identifiziert; der WebCart-Datenzugriff wurde nur bis zur UI-/Konfigurationsebene (WebCartConfig.cs) verfolgt |
+| Auswirkung auf Migration | Preisfindung des Kundencenters vor Neuimplementierung konkret nachziehen (vermutlich `CustomerSpecialArticleBL`, vgl. `src\backend\Centron.BL\Sales\Support\CustomerSpecialArticleBL.cs` – dort nicht verifiziert) |

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/StRS.md

@@ -0,0 +1,533 @@
+# StRS – Stakeholder Requirements Specification
+
+Reverse Requirements Engineering der c-entron ERP-Suite (CentronERP). Ebene 1 von 3 nach ISO/IEC/IEEE 29148:2018.
+Quellenbasis: Arbeitsverzeichnis (Quellcode, DB-Schema `SSMS_DB_SCHEMA.sql`, Dokumentation `docs/`, Rechtekatalog `CentronRights.md`). Alle Belegpfade sind relativ zum Arbeitsverzeichnis.
+
+Traceability: Jede StRS-Anforderung wird von SyRS-Anforderungen referenziert (siehe `Traceability.md`).
+
+---
+
+ID:            StRS-001
+Titel:         Zentrale Pflege des Adressstamms
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter, Backoffice, Lieferantenstammpfleger
+Vorbedingung:  Benutzer besitzt Rechte am Adressstamm
+Fakt:          Die Codebasis führt Kunden (`Kunden`, `AccountCustomers`), Lieferanten (`Kreditor`, `AccountSuppliers`) und Ansprechpartner (`Anschrif`, `Personen`) als eigene Tabellen; `AccountBL.ValidateUserRights` (src\backend\Centron.BL\Accounts\AccountBL.cs:1290-1370) prüft getrennte Rechte für Anlegen/Ändern/Löschen/Suchen/Entsperren.
+Aussage:       Das System soll einen zentralen Adressstamm bereitstellen, in dem Kunden, Lieferanten, Anschriften und Kontaktpersonen einheitlich gepflegt werden, und jede Stammdatenänderung gegen rollenbasierte Rechte absichern.
+Ergebnis:      Konsistenter Adressstamm als Bezugsobjekt für Belege, Tickets und Verträge.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Accounts\AccountBL.cs, Methode `ValidateUserRights` (Zeile 1299) – prüft CREATE_CUSTOMER, EDIT_CUSTOMER, DELETE_CUSTOMER, SEARCH_CUSTOMER, UNLOCK_CUSTOMER, RIGHT_LIEFERANTANLEGEN/-AENDERN und verweigert die Aktion bei fehlendem Recht
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen `Kunden`, `Kreditor`, `Anschrif`, `Personen` – Datenmodell des Adressstamms
+  - [KONTEXT]  src\backend\Centron.BL\Accounts\AccountSearchBL.cs:331 – Einschränkungsrecht SHOW_ONLY_OWN_CUSTOMER verfeinert die Suche
+Prüfidee:      Anlegen eines Kunden ohne Rechte CREATE_CUSTOMER wird mit Fehlermeldung abgewiesen; Anlegen mit Recht erzeugt Datensatz in `Kunden` mit I3D aus Nummernkreis.
+Tracelinks:    StRS-012, StRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Stammdatenhaltung ist Kernbestandteil eines ERP
+Status:        belegt
+
+---
+
+ID:            StRS-002
+Titel:           Vertriebsbelege über die gesamte Belegkette führen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Vertrieb, Innendienst
+Vorbedingung:    Kunde im Adressstamm angelegt
+Fakt:            `CentronObjectKindNumeric` (src\backend\Centron.Interfaces\CentronObjectKindNumeric.cs) und `AssetKindEnum` (src\backend\Centron.Entities\Entities\Sales\CustomerAssets\AssetKindEnum.cs:52-78) definieren die Belegarten Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Stammblatt; `InvoiceSpecificLogic.CanBeForwardedFrom/Into` (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:279-281) regelt erlaubte Übergaben.
+Aussage:         Das System soll die Belegkette von Angebot über Auftrag und Lieferschein bis Rechnung/Gutschrift abbilden und Belege untereinander weiterleiten können.
+Ergebnis:        Nachvollziehbare Beleghistorie über alle Vertriebsstufen (ForwardedFrom/ForwardedInto).
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:279-281 – legt fest, aus welchen Belegarten Rechnungen entstehen und in welche Belegarten sie weitergeführt werden dürfen
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs, Methoden `CreateNewVersion`, `GetForwardedFrom` (Zeile 3505-3520, 3470) – Versionierung und Übergabehistorie
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\Sales\CustomerAssets\AssetKindEnum.cs:52-78 – Belegart-Namen („Angebot", „Auftrag", …)
+Prüfidee:        Aus einem Auftrag wird eine Rechnung erstellt; die Rechnung verweist auf den Auftrag, Änderungen der Menge nach Übergabe sind gesperrt.
+Tracelinks:      StRS-003, StRS-005
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen - Belegkette ist Kern des Vertriebsprozesses
+Status:          belegt
+
+---
+
+ID:            StRS-003
+Titel:           Rechnungsstellung mit lückenloser Belegnummerierung
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Buchhaltung, Vertrieb
+Vorbedingung:    Belegart Rechnung konfiguriert, Nummernkreis existiert
+Fakt:            `NumberGroupBL.GetNextNumber` (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:62-133) vergibt Nummern mit Intervall über optimistisches Update (`rowCountChanged == 1`) und prüft Kollisionen gegen Zieltabelle sowie Sonderfall `Kunden`/`Kreditor`; `RechKopf.Nummer` (SSMS_DB_SCHEMA.sql) ist Pflichtfeld.
+Aussage:         Das System soll für jeden Beleg lückenlose, kollisionsfreie Nummern aus mandanten-/filialspezifischen Nummernkreisen vergeben, auch bei gleichzeitiger Nutzung durch mehrere Benutzer.
+Ergebnis:        Keine doppelten Belegnummern; Nummernkreise lückenlos fortlaufend (Option Intervall).
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:80-91 – bedingtes Update (SET Current WHERE Current=alt) verhindert Doppelvergabe bei Parallelität
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:114-131 – Sonderprüfung gegen `Kunden`/`Kreditor`-I3D
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `RechKopf`, Spalte `Nummer NOT NULL`
+Prüfidee:        Zwei gleichzeitige Rechnungserstellungen erzeugen zwei verschiedene Nummern; künstlich belegte Nummer wird übersprungen.
+Tracelinks:      StRS-002, StRS-011
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen - GoBD-relevante Kernfunktion
+Status:          belegt
+
+---
+
+ID:            StRS-004
+Titel:           Forderungsmanagement: Mahnwesen und Zahlungseingänge
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Buchhaltung, Debitorenbuchhaltung
+Vorbedingung:    Rechnung gestellt, Zahlungsziel verstrichen
+Fakt:            `RechKopf` enthält Mahnstufe, Mahnung1-3-Datum/Bearbeiter, MahnStop, Bezahlt (SSMS_DB_SCHEMA.sql); `DunningBL` (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:58-1059) bildet Mahnkunden, Mahnstatistik, Mahnstopp und Rechteprüfung ab; AppSettingsConst 100-104 (src\backend\Centron.BL\Administration\Settings\AppSettingsConst.cs) definiert Mahntexte je Stufe und Gerätesperre nach Mahnstufe.
+Aussage:         Das System soll überfällige Forderungen in drei Mahnstufen verfolgen, Mahntexte/E-Mails mit Platzhaltern erzeugen, Mahnstopp je Kunde erlauben und Zahlungseingänge den Rechnungen zuordnen.
+Ergebnis:        Mahnlauf liefert je Kunde Mahnstatus; gesperrte Kundengeräte werden beim Ablauf der Stufe gesperrt (StRS-005).
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:341-456 – UpdateDunningSettingsForCustomer/UpdateDunningStopAndInfo/Get- und UpdateSettings
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, `RechKopf`-Spalten Mahnstufe, Mahn1-3Datum, MahnStop, Bezahlt
+  - [SEKUNDÄR] src\backend\Centron.BL\Administration\Settings\AppSettingsConst.cs:100-104 – Mahntexte je Stufe, CustomerAssetsLockedAfterDunningLevel
+Prüfidee:        Rechnung 35 Tage überfällig erscheint im Mahnlauf Stufe 1 mit konfiguriertem Text; Mahnstopp-Kunde wird übersprungen; Teilzahlung reduziert offen markierten Betrag.
+Tracelinks:      StRS-003, StRS-005
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen - Standard-Forderungsprozess
+Status:          belegt
+
+---
+
+ID:            StRS-005
+Titel:           Vertrags- und Zählerabrechnung (Verträge, ClickContracts, Stammblätter)
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Vertrieb (Vertragsmanagement), Service
+Vorbedingung:    Vertrag mit vertragsbezogenem Stammblatt (Geräteliste) beim Kunden
+Fakt:            `SaveReceiptContractRepository` (src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365) setzt `Stammblattbezogen` aus `ExtraKind`; `DeviceClickCounterBL` (src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:30-128) liest importierte Zählerstände (SNMP), ordnet sie Geräten/Stammblättern zu; `ContractEndeService` (src\webservice\Centron.Host\AspNetCore\HostedServices\ContractEndeService.cs:8-16) aktualisiert Vertragsenddaten periodisch; NamedQueryPool.xml:5523 beschreibt Übernahme des Startwerts bei Vertragswechsel.
+Aussage:         Das System soll Wartungs-/Mietverträge inkl. vertragsbezogener Gerätelisten („Stammblätter") verwalten, Zählerstände der Geräte erfassen und daraus mengenbasierte (Click-)Abrechnungen erzeugen, wobei Vertragsübergänge Zählerstände korrekt fortschreiben.
+Ergebnis:        Mengenbasierte Abrechnung pro Gerät und Zeitraum ohne Doppelabrechnung über Vertragsgrenzen.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:87-128 – Zähler je Stammblatt, Zuordnung importierter Zähler
+  - [PRIMÄR]   src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365 – Kennzeichnung `Stammblattbezogen`
+  - [KONTEXT]  src\backend\Centron.DAO\NamedQueries\NamedQueryPool.xml:5523 – Kommentar zur Startwert-Übernahme bei Vertragswechsel
+Prüfidee:        Zählerstand 12.000 bei Endwert 10.000 erzeugt Abrechnung über 2.000 Einheiten; Vertrag wechselt mitten im Jahr, Startwert übernimmt letzten Stand des Vorgängervertrags.
+Tracelinks:      StRS-002, StRS-004
+Konsolidierung:  Kandidat: Stammblatt- (MasterDataList) und Zähler-Datenhaltung (DeviceClickCounter/SNMP-Import) im Zielsystem mit dem allgemeinen Gerätebestand (AccountDevices, AssetManagementDevices) zusammenführen - siehe SwRS-012.
+Übernahmewürdigkeit: übernehmen - Kerngeschäft der Branche; Doppelhaltung der Gerätedaten ist Workaround
+Status:          belegt
+
+---
+
+ID:            StRS-006
+Titel:           Serviceprozesse über Helpdesk-Tickets steuern
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Servicetechniker, Dispatcher, Kunden
+Vorbedingung:    Rechte am Helpdesk-Modul
+Fakt:            Rechtekatalog `CentronRights.md` beschreibt Ticket-Lebenszyklusrechte (anzeigen/anlegen/bearbeiten/abschließen); `HelpdeskCloseBL.CloseHelpdesk` (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-157) setzt Abschlussstatus aus den Einstellungen, löscht ToDos, schreibt Historie und Kundenaktivität; `HelpdeskStatusBL` (src\backend\Centron.BL\Sales\Support\HelpdeskStatusBL.cs:27-56) liefert Status aus freier Statustabelle.
+Aussage:         Das System soll Serviceanfragen als Tickets mit Typen, Kategorien, Prioritäten, Status, Fälligkeit, Zuweisung und Prüf-Checklisten verwalten und ihren Lebenszyklus von Annahme bis Abschluss mit Historie abbilden.
+Ergebnis:        Vollständige Ticketnachverfolgung; abgeschlossene Tickets erzeugen Historien- und Aktivitätseinträge.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-157 – Abschluss: Status aus Einstellungen, ClosedAt, ToDos löschen, Historie, Aktivität
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Tabellen hlpdsk_requests, hlpdsk_status, hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten
+  - [KONTEXT]  CentronRights.md, Abschnitt Helpdesk – beabsichtigte Rechtewirkung je Aktion
+Prüfidee:        Ticket anlegen → Statusfolge bearbeiten → Abschluss erzeugt ClosedAt, Historieneintrag „Close", Kundenaktivität und entfernt offene ToDos.
+Tracelinks:      StRS-007, StRS-021
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen - Kernprozess Service
+Status:          belegt
+
+---
+
+ID:            StRS-007
+Titel:           Zeiterfassung und abrechenbare Leistungen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Techniker, Serviceleitung, Buchhaltung
+Vorbedingung:    Ticket geöffnet bzw. Beleg vorhanden
+Fakt:            `HelpdeskTimerWebServiceBL` (src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374) prüft EDIT_TIME und OWN_TIME_EDIT; `HelpdeskTimerArticleBookingBL` und `HelpdeskTimerAddressSpecialArticlesBL` (src\backend\Centron.BL\Sales\Support\) buchen Leistungen und Anfahrtsartikel; CentronRights.md Abschnitte 7-9 regeln Zeitbearbeitung, Verschieben und Löschen (nur wenn Ticket nicht Teil eines Belegs ist).
+Aussage:         Das System soll Leistungen (Zeiten) am Ticket und am Kunden erfassen, mit Artikeln verrechnen, auf Belege übertragen und dabei Nutzerrechte und Belegbindung berücksichtigen.
+Ergebnis:        Zeiten sind revisionsnachvollziehbar und fließen in Belege/Rechnungen ein.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374 – Rechteprüfung EDIT_TIME/OWN_TIME_EDIT vor Zeitänderung
+  - [KONTEXT]  CentronRights.md, Abschnitte 7-9 – Verschieben/Löschen nur wenn „Ticket nicht Teil eines Belegs"
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Helpdesk\TicketDetails\TimeRecording\TimeRecordingView.xaml:541 – UI-Feld „Stammblatt" an Zeit
+Prüfidee:        Techniker ohne OWN_TIME_EDIT kann fremde Zeit nicht ändern; Zeit eines in Rechnung gestellten Tickets lässt sich nicht löschen.
+Tracelinks:      StRS-006, StRS-012
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen - Kernprozess
+Status:          belegt
+
+---
+
+ID:            StRS-008
+Titel:           Artikelstamm und Lagerbestände verwalten
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Lagerleitung, Einkaufs-/Vertriebsmitarbeiter
+Vorbedingung:    Lagerstandorte angelegt
+Fakt:            Warehousing-BL (src\backend\Centron.BL\Warehousing\) enthält ArticleBL, ArticleStockBL, InventoryNewBL (src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryNewBL.cs), BarcodeBL, MaterialGroupBL; UI-Modul Warehousing (src\centron\Centron.WPF.UI\Modules\Warehousing\) bietet Artikelverwaltung, Inventur, Barcodes, Kommissionierung.
+Aussage:         Das System soll Artikel mit Einheiten, Preisen, Materialgruppen, Ersatzteilen und Lagerbeständen verwalten und Inventuren sowie Barcode-Verfolgung unterstützen.
+Ergebnis:        Korrekte Bestände je Lager/Standort; Artikel als Basis für Belege.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Warehousing\ArticleStockBL.cs – Bestandsführung (Klasse vorhanden und von Beleglogik referenziert)
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Warehousing – Modulaufteilung (Artikelverwaltung, Inventur, Barcode, Kommissionierung)
+  - [KONTEXT]  SSMS_DB_SCHEMA.sql, Tabellen ARTIK, WareKopf/WarePos (Wareneingänge)
+Prüfidee:        Wareneingang erhöht Bestand, Rechnung mit UpdatesStock=true vermindert Bestand; Inventurdifferenz korrigiert Bestand protokolliert.
+Tracelinks:      StRS-002, StRS-009
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-009
+Titel:           Beschaffung mit Lieferanten-Integrationen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Einkäufer, Lieferanten-EDI-Gateways
+Vorbedingung:    Lieferantenstamm konfiguriert
+Fakt:            EDI-Ordner (src\backend\Centron.BL\EDI\) implementiert Lieferantenformatklassen (AlltronOrderBL, AlsoOrderBL, AlsoOrderCH_BL, ConcertoOrderBL, EgisOrderBL, KomsaOrderBL, Opentrans21OrderBL, EgisWarenkorbBL, EgisOrderConfirmBL) und EDIDispatcherBL; Einkauf-BL (src\backend\Centron.BL\Purchasing\SupplierBL.cs, OrderSuggestionListBL.cs) bildet Bestellvorschläge.
+Aussage:         Das System soll Bestellungen je Filiale erzeugen, aus Bestellvorschlägen befüllen und mit Lieferanten über EDI-Formate austauschen (Bestellung, Bestellbestätigung, Warenkorb).
+Ergebnis:        Elektronische Bestellkette mit Protokoll (EDILog).
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\EDI\EDIDispatcherBL.cs – zentrale Weiterverarbeitung der EDI-Vorgänge
+  - [PRIMÄR]   src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs – Bestellungen je Filiale
+  - [SEKUNDÄR] src\backend\Centron.BL\EDI\KomsaOrderBL.cs u. a. – Lieferantenspezifische Formatklassen
+Prüfidee:        Bestellvorschlag → Bestellung → EDI-Export erzeugt lieferantenspezifische Datei; Bestellbestätigung aktualisiert Positionen.
+Tracelinks:      StRS-008, StRS-010
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen; einzelne Lieferantenformate ggf. Sonderfall (Kundenindividuell)
+Status:          belegt
+
+---
+
+ID:            StRS-010
+Titel:           FiBu-konforme Belegweitergabe
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Buchhaltung, externe FiBu-Systeme
+Vorbedingung:    Belege abgeschlossen
+Fakt:            Der Gateway (src\backend\Centron.Gateway) implementiert Export-/Importklassen für DATEV (Ascii, XmlOnline 2012/2020, AccountingPro), Abacus, Addison, Lexware, Navision, Sage 50/OfficeLine, SAP, Schilling AS400, Stotax, Europa3000, GDI, BBG und nutzerdefinierte Schnittstellen.
+Aussage:         Das System soll abgerechnete Belege in Formate gängiger Finanzbuchhaltungssysteme exportieren und Buchungsdaten importieren können.
+Ergebnis:        FiBu-Exportdatei pro Zielsystem mit korrekten Konten/Perioden.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.Gateway\BookKeepingExportDatevAscii.cs u. a. – konkrete Formatimplementierungen
+  - [PRIMÄR]   src\backend\Centron.BL\DataExchange\BookKeepingExportBL.cs, BookKeepingImportBL.cs – Aufruf- und Regellogik
+  - [SEKUNDÄR] src\backend\Centron.Gateway\BookKeepingExportCustomInterface.cs – kundenspezifische Schnittstellen
+Prüfidee:        Monatsabschluss-Export erzeugt DATEV-Ascii-Datei, die im Zielsystem importiert werden kann; fehlerhafte Gegenkonten erzeugen Exportwarnung.
+Tracelinks:      StRS-003
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen; veraltete Formate (z. B. LexwarePro2011, XmlOnline_Maerz2012) als `veraltet` prüfen
+Status:          belegt
+
+---
+
+ID:            StRS-011
+Titel:           Mandanten- und Filialstruktur abbilden
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Gruppenleitung, Systemadministration
+Vorbedingung:    Mehrere Mandanten/Filialen im Einsatz
+Fakt:            `NumberGroupBL.RefreshAllNumberGroups` (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152) erzeugt Nummernkreise je Standardmandant und Filiale; `AppRightsBL.GetAllRightGroups` (src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:39-48) filtert Rechtegruppen nach Filiale; Tabelle `Filiale` im DB-Schema.
+Aussage:         Das System soll mehrere Mandanten und Filialen mit eigenen Nummernkreisen, Stammdaten und Rechtebereichen unterstützen und filialbezogene Datenbegrenzung ermöglichen.
+Ergebnis:        Benutzer sieht nur Daten seiner Filiale, wenn einschränkendes Recht gesetzt ist.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:39-48 – Rechtegruppenfilter `BranchI3D == currentUser.Employee.BranchI3D` bei MANAGE_RIGHTS_ONLY_OWN_BRANCH
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152 – Nummernkreise je Mandant+Filiale
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `Filiale`
+Prüfidee:        Benutzer der Filiale B erhält bei MANAGE_RIGHTS_ONLY_OWN_BRANCH nur Rechtegruppen der Filiale B; Belegnummerierung der Filiale A ist von B unabhängig.
+Tracelinks:      StRS-012, StRS-003
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-012
+Titel:           Zugriff nur nach Rollen- und Gruppenrechten
+Ebene:           StRS
+Typ:             Sicherheit
+Qualitätsmerkmal:
+Akteur:          Administrator, alle Benutzer
+Vorbedingung:    Benutzer ist Gruppen zugeordnet
+Fakt:            Rechte werden über Gruppen zugewiesen: `Sichtrus` (Gruppe↔Recht) und `Sichmemb` (Gruppe↔Benutzer); `AppRightsBL.CheckRightsFromUser` (src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:95-111) führt die Prüfung per SQL durch; Geschäftslogik ruft diese Prüfung in schreibenden Operationen auf (z. B. AccountBL.ValidateUserRights, BankAccountBL.cs:72-81).
+Aussage:         Das System soll jede privilegierte Aktion gegen Rechte prüfen, die dem Benutzer über Gruppen zugeteilt sind, und die Aktion bei fehlendem Recht verweigern.
+Ergebnis:        Kein unautorisierter Zugriff auf Funktionen/Daten; Rechteprüfung serverseitig.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:95-111 – SQL gegen Sichtrus/Sichmemb, Rückgabe der Rechte-IDs
+  - [PRIMÄR]   src\backend\Centron.BL\Accounts\BankAccountBL.cs:72-81 – Prüfung CREATE/EDIT_Bank_Account vor Speichern
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen `Sichtrus`, `Sichmemb`
+Prüfidee:        Benutzer ohne Recht erhält bei direktem Webservice-Aufruf eine Verweigerungsantwort; mit Recht gelingt die Aktion.
+Tracelinks:      StRS-013, StRS-011
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-013
+Titel:           Gesicherte Anmeldung für interne und externe Nutzer
+Ebene:           StRS
+Typ:             Sicherheit
+Qualitätsmerkmal:
+Akteur:          Interne Benutzer, Kunden (Web-Konto), Administratoren
+Vorbedingung:    Benutzerkonto existiert
+Fakt:            Authenticator-Familie (src\backend\Centron.BL\Administration\Logins\Auth\): BasicAuthenticator (SHA1-Passwortvergleich, Zeile 46-50), ActiveDirectoryAuthenticator, OpenIdConnectAuthenticator, WebAccountAuthenticator; TwoFactorAuthenticationBL (TOTP, Zeile 43-54), TwoFactorAuthBL (RADIUS, E-Mail-Link, Zeile 183-189); TicketAuthenticationHandler (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs) schützt jede API-Anfrage.
+Aussage:         Das System soll Benutzer über mehrere Verfahren (lokal, AD, OpenID Connect, Web-Konto) authentifizieren, optional mit Zwei-Faktor-Authentifizierung, und API-Zugriffe nur mit gültigem Ticket/Token zulassen.
+Ergebnis:        Kein API-Zugriff ohne gültige Authentisierung; gesperrte Konten werden abgewiesen.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs:46-50 – Passwortvergleich gegen SHA1-Hash (enthält ausdrücklichen TODO-Kommentar „password should be salted")
+  - [PRIMÄR]   src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs:44-95 – Ticket/AccessToken-Prüfung vor jedem Aufruf
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `WebAccounts.UseTwoFactorAuthentication`, `LastTwoFactorValidatedAt`
+Prüfidee:        Anmeldung mit falschem Kennwort schlägt fehl; 2FA-Pflichtkonto ohne PIN wird abgewiesen; API-Aufruf ohne Bearer-Ticket liefert 401.
+Tracelinks:      StRS-012, StRS-021
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen; Passwort-Hash-Verfahren ist Workaround (SHA1 ohne Salt) → im Zielsystem durch Argon2/bcrypt ersetzen
+Status:          belegt
+
+---
+
+ID:            StRS-014
+Titel:           Lizenzgerechte Systemnutzung
+Ebene:           StRS
+Typ:             nicht-funktional
+Qualitätsmerkmal: Functional Suitability / Compliance
+Akteur:          Betreiber, Lizenzverwalter
+Vorbedingung:    Lizenz mit Anwendungskind und maximaler Nutzerzahl
+Fakt:            `Authenticator.AuthenticateUser` (src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:109-155) ruft `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)` vor Ticketerstellung; `ApplicationKind.DisallowingRight/RequiredRight` schränken Anwendungen zusätzlich per Rechte ein.
+Aussage:         Das System soll beim Login prüfen, ob für die Anwendung und Version eine Lizenz mit freiem Platz verfügbar ist, und sonst die Anmeldung verweigern.
+Ergebnis:        Nutzerzahl pro Lizenz wird eingehalten; unbekannte Anwendungskennungen werden abgelehnt.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:124-155 – Lizenzprüfung und Ticketerstellung inkl. Anwendungskind-Prüfung (Zeile 100-104)
+  - [SEKUNDÄR] src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:68-86 – Required/DisallowingRight je Anwendung
+Prüfidee:        Bei erschöpfter Lizenz schlägt die Anmeldung des zusätzlichen Benutzers mit Lizenzfehler fehl; unbekannte ApplicationGuid wird abgelehnt.
+Tracelinks:      StRS-013
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen (Lizenzmodell ggf. für SaaS anpassen)
+Status:          belegt
+
+---
+
+ID:            StRS-015
+Titel:           Termine, Aufgaben und persönlicher Arbeitsplatz
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Alle internen Benutzer
+Vorbedingung:    Benutzer angemeldet
+Fakt:            Kalenderrechte (CentronRights.md, Kalender: alle/eigene), MyCentron-Modul (src\centron\Centron.WPF.UI\Modules\MyCentron: Kalender, MyDay, TodoList, PersonalSettings, Telephony, Dashboard), `SchedulingBL`/`QuickNoteBL`/`DashboardContainerBL` (src\backend\Centron.BL\MyCentron\).
+Aussage:         Das System soll jedem Benutzer einen persönlichen Arbeitsplatz mit Kalender, Tagesübersicht (MyDay), ToDos, Notizen, Telefonie-Integration und anpassbarem Dashboard bereitstellen, wobei Kalenderdaten personenbezogen begrenzt werden können.
+Ergebnis:        Benutzer plant Termine und Aufgaben zentral und erhält Benachrichtigungen (→ SyRS-044).
+Belege:
+  - [KONTEXT]  CentronRights.md, Kalender-Abschnitt (RIGHT_KALENDERANZEIGENEIGENE) – geplante Sichtbarkeit
+  - [PRIMÄR]   src\backend\Centron.BL\MyCentron\DashboardContainerBL.cs – Dashboard-Container-Speicherung
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\MyCentron – Modulaufbau
+Prüfidee:        Benutzer mit „nur eigene Kalender" sieht fremde Termine nicht; MyDay listet Termine + offene ToDos des Tages.
+Tracelinks:      StRS-016, StRS-006
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-016
+Titel:           E-Mail-Kommunikation mit Vorlagen und Signaturen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Alle internen Benutzer, System (automatische Mails)
+Vorbedingung:    Mailversand konfiguriert (SMTP/Exchange/Graph)
+Fakt:            Mail-BL enthält SMTPMail.cs, ExchangeMail.cs, GraphMail.cs, MailTemplateBL (src\backend\Centron.BL\Mail\Templates\MailTemplateBL.cs), SignatureReplacementBL, DomainBlacklistBL, MailScanner (src\backend\Centron.BL\MailScanner\MailScannerBL.cs).
+Aussage:         Das System soll E-Mails über mehrere Transportwege versenden, Text-/Mailvorlagen mit Platzhaltern nutzen, Signaturen automatisiert einsetzen und eingehende Mails erfassen/scannen können.
+Ergebnis:        Konsistente, vorlagenbasierte Kommunikation aus Belegen, Tickets und Mahnwesen.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Mail\SMTPMail.cs, ExchangeMail.cs, GraphMail.cs – drei konkrete Transportimplementierungen
+  - [PRIMÄR]   src\backend\Centron.BL\Mail\DomainBlacklistBL.cs – Absender-/Domain-Blacklist
+  - [SEKUNDÄR] src\backend\Centron.BL\Mail\Templates\MailTemplateBL.cs – Vorlagenverwaltung
+Prüfidee:        Versand einer Ticketmail nutzt Vorlage + Signaturersatz; Adressen auf Blacklist werden abgewiesen; Exchange-Postfach scannt eingehende Mails.
+Tracelinks:      StRS-006, StRS-004
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-017
+Titel:           Dokumente revisionssicher ablegen und auffinden
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Alle internen Benutzer
+Vorbedingung:    Dokumentenablage konfiguriert
+Fakt:            Hintergrunddienste `DocumentFulltextIndexUpdateService`, `DocumentsCleanupService` (src\webservice\Centron.Host\AspNetCore\HostedServices\); CentronFileSystem (src\centron\Centron.WPF.UI\CentronFileSystem); Dokumentanhang an alle Belegarten (DocDirI3D in RechKopf).
+Aussage:         Das System soll Dokumente versioniert an Belegen, Kunden und anderen Objekten ablegen, einen Volltextindex pflegen und veraltete Dokumente bereinigen.
+Ergebnis:        Dokumente sind über Volltextsuche auffindbar; Ablage bleibt wartbar.
+Belege:
+  - [PRIMÄR]   src\webservice\Centron.Host\AspNetCore\HostedServices\DocumentFulltextIndexUpdateService.cs – periodische Indexpflege
+  - [PRIMÄR]   src\webservice\Centron.Host\AspNetCore\HostedServices\DocumentsCleanupService.cs – Bereinigungsdienst
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, `RechKopf.DocDirI3D` – Dokumentenverzeichnis am Beleg
+Prüfidee:        Nach Upload eines PDFs am Beleg ist dessen Text über die Volltextsuche auffindbar; Bereinigungsdienst entfernt testweise markierte Alt-Dokumente.
+Tracelinks:      StRS-002, StRS-020
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-018
+Titel:           Auswertungen für Steuerung und Abrechnung
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Leitung, Controlling, Serviceleitung
+Vorbedingung:    Daten in Statistik-Caches aktualisiert
+Fakt:            Statistics-BL (src\backend\Centron.BL\Statistics\): RevenueStatisticBL, EmployeeUtilizationBL, ContractEvaluationBL, MspStatisticBL, InvoiceStatisticBL, CacheSalesStatisticsBL, CacheOrderStatisticsBL; Cache-Tabelle `CacheTicketStatistic`; Arbeitnehmerauslastungsrechte (CentronRights.md, Mitarbeiterauslastung).
+Aussage:         Das System soll Umsatz-, Auslastungs-, Vertrags- und Ticketstatistiken bereitstellen und Mitarbeiterauslastung nur nach Rechte sichtbar machen.
+Ergebnis:        Managementauswertungen ohne manuelle Aufbereitung.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Statistics\EmployeeUtilizationBL.cs – Auslastungsberechnung
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql, Tabelle `CacheTicketStatistic`
+  - [KONTEXT]  CentronRights.md, Mitarbeiterauslastung – „nur eigene Filiale" als einschränkendes Recht
+Prüfidee:        Monatsauswertung Umsatz deckt sich mit Rechnungssummen; Auslastung eines Mitarbeiters ohne Recht für andere wird nicht angezeigt.
+Tracelinks:      StRS-003, StRS-006
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-019
+Titel:           Beleg- und Listenberichte erzeugen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Alle internen Benutzer, Druckserver
+Vorbedingung:    Berichtsvorlagen definiert (ReportGroup)
+Fakt:            ReportEngine (src\backend\Centron.BL\ReportEngine\): FastReportHelper, PdfStrategies (FastReport, PdfCreator, SevenPdf), ReceiptToReportObjectMap, ReportGroupBL; ReceiptBL erzeugt Beleg-PDFs inkl. Signatur (ReceiptBL.cs:3199-3361).
+Aussage:         Das System soll Belege (Rechnungen, Lieferscheine, Tickets) und Listen als PDF mit konfigurierbaren Vorlagen erzeugen, zusammenführen, digital signieren und drucken können.
+Ergebnis:        Vorlagengetreue Belegausgabe; Signaturpfad optional.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3199-3361 – PDF-Erzeugung, Merge, Signatur am Beleg
+  - [PRIMÄR]   src\backend\Centron.BL\ReportEngine\PdfStrategies.cs – Strategieauswahl (FastReport/PdfCreator/SevenPdf)
+  - [SEKUNDÄR] src\backend\Centron.BL\ReportEngine\ReceiptToReportObjectMap.cs – Datenabbildung Beleg→Bericht
+Prüfidee:        Rechnung mit Vorlage X erzeugt PDF mit Berichtsgruppe und Pflichtfeldern; Signaturdienst erzeugt signiertes PDF.
+Tracelinks:      StRS-002, StRS-026
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-020
+Titel:           Datenschutzkonforme Datenhaltung (DSGVO)
+Ebene:           StRS
+Typ:             Sicherheit
+Qualitätsmerkmal: Security
+Akteur:          Datenschutzbeauftragter, Administrator
+Vorbedingung:    DSGVO-Modul verfügbar und Rechte gesetzt
+Fakt:            `DataSecurityBL` (src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66, 379, 789) prüft ACCESS_CLEANUP_DATABASE bzw. DSGVO_DELETE_CONTACT vor Bereinigung/Kontaktlöschung; Modul „DSGVO" in Verwaltung (src\centron\Centron.WPF.UI\Modules\Administration\DSGVO).
+Aussage:         Das System soll personenbezogene Daten auf Antrag bereinigen oder anonymisieren können (Kontaktlöschung, Datenbank-Cleanup), wobei die Funktionen rechtegesichert sind.
+Ergebnis:        Lösch-/Bereinigungsvorgänge nur durch berechtigte Rollen; gelöschte Kontakte sind in Adressbelegen nicht mehr identifizierbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66 – Zugriffsrechte ACCESS_CLEANUP_DATABASE + Featureflag `ModuleFeatures.IsDsgvoDatabaseCleanupAvailable`
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:379 – Prüfung DSGVO_DELETE_CONTACT vor Kontaktlöschung
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Administration\DSGVO – Verwaltungs-UI
+Prüfidee:        Kontaktlöschung ohne Recht schlägt fehl; mit Recht werden Bezugsdatensätze (Belege, Mails) anonymisiert und Protokoll geschrieben.
+Tracelinks:      StRS-012, StRS-041→SyRS-041
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-021
+Titel:           Selbstservice-Kundencenter im Web
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Endkunden (Web-Konto), Vertrieb
+Vorbedingung:    Web-Konto im Adressstamm angelegt
+Fakt:            Nexus-WebApp (src\nexus\CentronNexus): WebCart (Shop, Warenkorb, Tickets), ReceiptsOverview/ReceiptDetailsOverview, CustomerTicketDetailsPage, DocumentSigningPage (SignaturePad), WebOffer; README.md (WebCart für Kunden der Kunden, Artikel aus „Sonderpreise"); WebAccountAuthenticator ordnet Web-Konto einem gemeinsamen AppUser zu.
+Aussage:         Das System soll Kunden über ein Web-Portal Zugriff auf eigene Belege, Tickets, Angebote und einen Artikel-Shop (WebCart) geben, inklusive digitaler Dokumentenunterschrift.
+Ergebnis:        Kunden beziehen Artikel und Informationen selbstständig; Rückläufer (Unterschriften) laufen digital zurück.
+Belege:
+  - [KONTEXT]  README.md, Abschnitt Contributing/WebCart – Zielgruppe und Preisquelle „Sonderpreise"
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\Logins\Auth\WebAccountAuthenticator.cs:42-83 – Web-Konto-Anmeldung mit 2FA und Zuordnung zum AppUser
+  - [PRIMÄR]   src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor – Unterschriftenfunktion
+Prüfidee:        Web-Konto-Login zeigt nur Belege des zugeordneten Kunden; Warenkorb mit Sonderpreisen erzeugt Ticket/Bestellung; unterschriebenes Dokument ist am Beleg abgelegt.
+Tracelinks:      StRS-013, StRS-006
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-022
+Titel:           Produktion und Qualitätssicherung
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Fertigungsleitung, QM-Verantwortliche
+Vorbedingung:    Stücklisten/Artikel angelegt
+Fakt:            ProductionOrderBL (src\backend\Centron.BL\Production\ProductionOrderBL.cs:17-122) verwaltet Fertigungsaufträge und -positionen; QM-Einstellungen (src\centron\Centron.WPF.UI\Modules\QM: QmSettingsView, AssetReasonSettingsView); InvoiceSpecificLogic.GetReceiptReasonQmMessageSetting (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:317-322) koppelt QM-Hinweise an Beleggründe.
+Aussage:         Das System soll Fertigungsaufträge mit Positionen verwalten und Qualitätsmerkmale (Prüfgründe, QM-Hinweise an Belegen) konfigurierbar abbilden.
+Ergebnis:        Fertigungs-/Prüfprozesse sind im ERP nachvollziehbar.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\Production\ProductionOrderBL.cs:35-122 – Laden/Speichern von Fertigungsaufträgen und -positionen
+  - [PRIMÄR]   src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:317-322 – QM-Grundeinstellung je Belegart
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\QM\QmSettingsView.xaml – Einstellungs-UI
+Prüfidee:        Fertigungsauftrag mit Positionen anlegen und abschließen; Beleggrund mit QM-Bezug erzeugt QM-Hinweis.
+Tracelinks:      StRS-008
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-023
+Titel:           Rücksendungen (RMA) verfolgen
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Service, Lager, Kunde
+Vorbedingung:    Artikel/Ticket vorhanden
+Fakt:            RmaBL (src\backend\Centron.BL\CustomerArea\RmaBL.cs:81-603): GetNewRma, SaveRma, GetRmaByHelpdeskI3D, CreateNewRmaArticle, ArticleRmaHistory; RMA-UI (src\centron\Centron.WPF.UI\Modules\Rma) mit SendOverview und Artikel-Selbstauswahl; Tabelle `Rma`.
+Aussage:         Das System soll Rücksendungen als RMA-Scheine mit Artikelpositionen, Sendart und Historie verwalten und mit Tickets und Artikeln verknüpfen.
+Ergebnis:        Rückläufer sind je Artikel/Ticket historisiert.
+Belege:
+  - [PRIMÄR]   src\backend\Centron.BL\CustomerArea\RmaBL.cs:347-603 – Speichern, Suche nach Ticket, Artikelhistorie
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabelle `Rma`
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Rma\RmaSendOverviewView.xaml – Sendart-Übersicht
+Prüfidee:        RMA vom Ticket anlegen; Artikelposition mit Seriennummer historisiert; Sendart veränderbar.
+Tracelinks:      StRS-006, StRS-008
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen
+Status:          belegt
+
+---
+
+ID:            StRS-024
+Titel:           Integrationen, Automatisierung und Verwaltung
+Ebene:           StRS
+Typ:             funktional
+Qualitätsmerkmal:
+Akteur:          Administrator, Integrationspartner
+Vorbedingung:    System installiert
+Fakt:            Zentrale Verwaltung (src\centron\Centron.WPF.UI\Modules\Administration: MandatorManagement, CountryManagement, RightsManagement, SqlManagers, PdfSigning, EscalationsSettings, …); Hintergrunddienste-Katalog (src\webservice\Centron.Host\AspNetCore\HostedServices, u. a. CTimeConnectorService, ExchangeSyncService, PlmImportService, GfkExportService); externe Datenquellen (src\apis: ITscope, Icecat, Cop, Egis), KI-Chat (src\backend\Centron.BL\Administration\ArtificialIntelligence), TelekomDive.
+Aussage:         Das System soll zentrale Verwaltung (Mandanten, Länder, Rechte, SQL-Werkzeuge, PDF-Signatur, Eskalationen) sowie automatisierte Synchronisationen und Imports aus externen Datenquellen bereitstellen und einen KI-Chat auf Systemdaten anbieten.
+Ergebnis:        Betriebs- und Integrationsaufgaben sind ohne Datenbankzugriff über die Anwendung ausführbar.
+Belege:
+  - [PRIMÄR]   src\webservice\Centron.Host\AspNetCore\HostedServices – Katalog automatisierter Dienste (ExchangeSyncService, PlmImportService, CTimeConnectorService, …)
+  - [PRIMÄR]   src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatInstructionPromptBL.cs:314 – KI-Chat nur mit Recht Administration.SETTINGS
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\Administration – Verwaltungsmodule
+Prüfidee:        Exchangesync und PLM-Import laufen nach Zeitplan; KI-Chat für Benutzer ohne Administration.SETTINGS gesperrt.
+Tracelinks:      StRS-012, StRS-013
+Konsolidierung:  nein
+Übernahmewürdigkeit: übernehmen; einzelne Alt-Integrationen als `veraltet` prüfen
+Status:          belegt

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Ergebnisse/Traceability.md

@@ -0,0 +1,88 @@
+# Traceability
+
+Konsolidierte Trace-Matrix: StRS → SyRS → SwRS → Haupt-Artefaktbeleg.
+Jede Zeile entspricht einer SwRS-Anforderung (oder einer SyRS-Anforderung ohne SwRS-Kind, dort `—`).
+Alle referenzierten IDs existieren in StRS.md / SyRS.md / SwRS.md.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Haupt-Artefaktbeleg |
+|---|---|---|---|
+| StRS-024, StRS-001 | SyRS-001 | SwRS-051 | src\nexus\CentronNexus.OutlookAddIn |
+| StRS-024, StRS-001 | SyRS-001 | SwRS-053 | tests\Centron.Tests.EndToEnd |
+| StRS-013 | SyRS-002 | SwRS-036 | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs:377-486 |
+| StRS-013, StRS-014 | SyRS-003 | SwRS-035 | src\backend\Centron.BL\Administration\Logins\TicketBL.cs:32-129 |
+| StRS-014 | SyRS-004 | — | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs:100-155 |
+| StRS-012 | SyRS-005 | SwRS-032 | src\webservice\...\Rights\UserRightsConst.cs |
+| StRS-012 | SyRS-005 | SwRS-033 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs:63-87 |
+| StRS-012 | SyRS-005 | SwRS-008 | src\backend\Centron.BL\Accounts\AccountBL.cs:1299-1370 |
+| StRS-012 | SyRS-005 | SwRS-003 | src\backend\Centron.BL\Accounting\BankAccountBL.cs:72-81 |
+| StRS-012 | SyRS-005 | SwRS-003 | src\backend\Centron.BL\Accounting\BankAccountBL.cs:72-81 |
+| StRS-012, StRS-011 | SyRS-006 | SwRS-002 | src\backend\Centron.BL\Accounts\AccountSearchBL.cs:76, 331 |
+| StRS-012 | SyRS-005 | SwRS-015 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskTimerWebServiceBL.cs:359-374 |
+| StRS-013 | SyRS-007 | SwRS-034 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs:35-71 |
+| StRS-013, StRS-021 | SyRS-008 | SwRS-034 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs:43-54 |
+| StRS-021, StRS-013 | SyRS-009 | SwRS-048 | README.md (WebCart/Sonderpreise) – HYPOTHESE |
+| StRS-021, StRS-013 | SyRS-009 | SwRS-049 | src\nexus\CentronNexus\DocumentSigning\IsolatedSignaturePad.razor |
+| StRS-003 | SyRS-010 | SwRS-005 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:114-131 |
+| StRS-003, StRS-011 | SyRS-010 | SwRS-038 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:154-197 |
+| StRS-002 | SyRS-011 | — | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3082-3096 (Lock) |
+| StRS-002 | SyRS-012 | — | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:6216 (CreateNewVersion) |
+| StRS-002 | SyRS-013 | SwRS-011 | src\backend\Centron.DAO\Repositories\Sales\Receipts\ContractList\SaveReceiptContractRepository.cs:364-365 |
+| StRS-003, StRS-008 | SyRS-014 | SwRS-006 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:216-368 |
+| StRS-003, StRS-012 | SyRS-014 | SwRS-007 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:239-240 |
+| StRS-008 | SyRS-014 | SwRS-021 | src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryNewBL.cs:30-207 |
+| StRS-004 | SyRS-015 | SwRS-009 | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs:341-456, 1059 |
+| StRS-004 | SyRS-016 | SwRS-010 | src\backend\Centron.BL\Sales\Receipts\Invoices\Opos\OposBL.cs:28; SSMS_DB_SCHEMA.sql RechKopf.Bezahlt |
+| StRS-005 | SyRS-017 | SwRS-011 | src\webservice\Centron.Host\AspNetCore\HostedServices\ContractEndeService.cs:8-16 |
+| StRS-005 | SyRS-018 | SwRS-012 | src\backend\Centron.BL\Sales\CustomerAssets\Contracts\ClickContracts\DeviceClickCounterBL.cs:30-128 |
+| StRS-006 | SyRS-019 | SwRS-013 | SSMS_DB_SCHEMA.sql (hlpdsk_*), AccountDevicesToTickets |
+| StRS-006 | SyRS-019 | SwRS-016 | src\backend\Centron.BL\CheckListArea |
+| StRS-006 | SyRS-019 | SwRS-017 | src\backend\Centron.BL\WebServices\Sales\Support\HelpdeskPatternWebserviceBL.cs:351-395 |
+| StRS-006, StRS-021 | SyRS-020 | — | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-200 |
+| StRS-006 | SyRS-021 | — | src\webservice\Centron.Host\AspNetCore\HostedServices\EscalationsService.cs |
+| StRS-007, StRS-012 | SyRS-022 | SwRS-014 | src\backend\Centron.BL\Sales\Support\HelpdeskTimerArticleBookingBL.cs |
+| StRS-003 | SyRS-023 | SwRS-018 | src\backend\Centron.BL\Warehousing\TaxBL.cs:239-284 |
+| StRS-003 | SyRS-023 | SwRS-019 | src\backend\Centron.BL\Warehousing\TaxBL.cs:207-237, 286-320 |
+| StRS-003 | SyRS-023 | SwRS-020 | src\backend\Centron.BL\Warehousing\TaxBL.cs:84-156 |
+| StRS-008, StRS-005 | SyRS-024 | SwRS-022 | src\backend\Centron.Entities\Entities\Warehousing\BarCode.cs:100; BarcodeState.cs:19 |
+| StRS-009 | SyRS-025 | SwRS-023 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs; EDIGatewayLogBL.cs |
+| StRS-003, StRS-010 | SyRS-026 | SwRS-024 | src\backend\Centron.BL\DataExchange\InvoiceZugferdBL.cs; XInvoiceVersion3.cs |
+| StRS-010 | SyRS-027 | SwRS-025 | src\backend\Centron.Gateway\IBookKeepingExport.cs; BookKeepingExportDatevAscii.cs |
+| StRS-002 | SyRS-028 | SwRS-026 | src\apis\Centron.Api.Shipcloud; src\apis\Centron.Api.Gls |
+| StRS-008, StRS-024 | SyRS-029 | SwRS-052 | src\backend\Centron.BL\DataExchange\HPQuoteImportBL.cs; src\apis\Centron.APIs.ITscopeDataAccess |
+| StRS-008, StRS-024 | SyRS-029 | SwRS-059 | SSMS_DB_SCHEMA.sql (SocialMedia*); VoucherManagementBL.cs:17 |
+| StRS-004 | SyRS-030 | SwRS-027 | src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingFinApiBL.cs; src\apis\Centron.APIs.FinAPI |
+| StRS-016 | SyRS-031 | SwRS-028 | src\backend\Centron.BL\Mail\CentronMailFactory.cs; DomainBlacklistBL.cs |
+| StRS-016 | SyRS-031 | SwRS-029 | src\backend\Centron.BL\Mail\SignatureReplacementBL.cs |
+| StRS-015 | SyRS-032 | SwRS-030 | src\backend\Centron.BL\Calendar\CalendarBL.cs:31-132 |
+| StRS-017 | SyRS-033 | SwRS-056 | src\centron\Centron.WPF.UI\CentronFileSystem; AddDocumentToDirectoryRequest.cs |
+| StRS-019 | SyRS-034 | SwRS-042 | src\backend\Centron.BL\ReportEngine\PdfStrategies.cs; ReceiptToReportObjectMap.cs |
+| StRS-018 | SyRS-035 | SwRS-041 | SSMS_DB_SCHEMA.sql (CacheTicketStatistic); CacheUpdateService.cs |
+| StRS-024, StRS-005 | SyRS-036 | — | src\webservice\Centron.Host\AspNetCore\HostedServices (Dienstekatalog) |
+| StRS-015, StRS-021 | SyRS-037 | SwRS-050 | src\nexus\CentronNexus\ServiceBoard\CachedKanbanBoard.razor |
+| StRS-024 | SyRS-038 | SwRS-057 | src\centron\Centron.WPF.UI\Resources\LocalizedStrings.en.resx |
+| StRS-001, StRS-003 | SyRS-039 | SwRS-001 | SSMS_DB_SCHEMA.sql (Kunden/Kreditor/Anschrif/Personen) |
+| StRS-001, StRS-003 | SyRS-039 | SwRS-004 | SSMS_DB_SCHEMA.sql (RechKopf) |
+| StRS-001, StRS-003 | SyRS-039 | SwRS-037 | SSMS_DB_SCHEMA.sql (ApplicationSettings); AppSettingsConst.cs |
+| StRS-001, StRS-003 | SyRS-039 | SwRS-058 | src\centron\Centron.WPF.UI\Modules\Global\CustomPropertiesConnector.cs |
+| StRS-020 | SyRS-040 | SwRS-039 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs:36-66, 379 |
+| StRS-020, StRS-012 | SyRS-041 | SwRS-031 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs:21-27 |
+| StRS-020, StRS-012 | SyRS-041 | SwRS-040 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs:33-53; SSMS_DB_SCHEMA.sql (WebAccounts) |
+| StRS-024 | SyRS-042 | SwRS-054 | scripts\RunHelper.cs; docs\guides\database\create-scripts.md |
+| StRS-024 | SyRS-042 | SwRS-055 | deployment\CentronSetupProject.wixproj; docker\compose.yaml |
+| StRS-011 | SyRS-043 | SwRS-005 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152 |
+| StRS-011 | SyRS-043 | SwRS-038 | src\backend\Centron.DAO\Mappings\Administration\Company\NumberGroupMaps.cs |
+| StRS-015 | SyRS-044 | SwRS-044 | src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:134; TodoService.cs |
+| StRS-015 | SyRS-044 | SwRS-045 | src\webservice\Centron.Host\AspNetCore\HostedServices\SendEmailForUnreadMessagesService.cs |
+| StRS-024 | SyRS-045 | SwRS-046 | src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatInstructionPromptBL.cs:314 |
+| StRS-022 | SyRS-046 | SwRS-043 | src\backend\Centron.BL\Production\ProductionOrderBL.cs:25-122 |
+| StRS-023 | SyRS-047 | SwRS-047 | src\backend\Centron.BL\CustomerArea\RmaBL.cs:347-603 |
+
+## Konsolidierungskandidaten (fachlich gleichartige Konzepte in getrennten Implementierungen)
+
+| Kandidat | Beteiligte IDs | Befund |
+|---|---|---|
+| Gerätedaten-Streuhaltung („Stammblätter" vs. Geräte-/Zählerdaten) | SwRS-012, SwRS-022, SyRS-018, SyRS-024 | Drucker/Messgeräte werden als Stammblatt (MasterDataList) mit Zählern (DeviceClickCounter/DeviceClickCounterImported/SNMP) geführt, andere Geräte als AccountDevices/AssetManagementDevices; Barcode kennt eigenen Zustand „in Stammblatt". Im Zielsystem zu einem Asset-Konzept mit Zähler-/Statusdimension zusammenführen. |
+| FiBu-Exportformate | SwRS-025, SyRS-027 | ~20 Einzelklassen mit gleicher Aufgabe (Belege→Zielsystem-Datei); im Zielsystem auf einheitliches Mapping-Modell reduzieren. |
+| Nummernvergabe mit ID-Sonderfällen | SwRS-005, SwRS-038 | Nummernkreise prüfen gegen Zieltabellen inkl. Kunden/Kreditor-I3D; im Zielsystem durch DB-Sequenz/Constraint ersetzen. |
+| Vertragskennzeichnung über ExtraKind-Magic-Values | SwRS-011 | `ExtraKind == 1/3` → Stammblattbezogen; im Zielsystem durch explizite Vertragsart ersetzen. |
+| Authentifizierungsvarianten | SwRS-034, SwRS-036, SyRS-008 | Basic (SHA1), AD, OIDC, WebAccount + 2FA-Varianten; im Zielsystem auf OIDC/OAuth2 plus standardisierten MFA-Dienst konsolidieren. |

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Protokoll.md

@@ -0,0 +1,126 @@
+# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/solo/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:01:21.5727980+02:00
+- **Endzeit:** 2026-09-03T09:29:54.4711449+02:00
+- **Dauer gesamt:** 00:28: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/solo/max/`
+- **Agentenmodus:** `solo`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
+- **Rollen:** {}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 2.930.859 |
+| Output-Tokens | 96.752 |
+| Reasoning-Tokens | 45.229 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 108 |
+
+**Tokens gesamt: 10.220.040.** 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 | 24 | 18,5 % |
+| SyRS | 47 | 36,2 % |
+| SwRS | 59 | 45,4 % |
+| **Gesamt** | **130** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 60 | 46,2 % |
+| Sicherheit | 23 | 17,7 % |
+| Daten | 19 | 14,6 % |
+| Schnittstelle | 17 | 13,1 % |
+| nicht-funktional | 11 | 8,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 346 |
+| davon `PRIMÄR` | 233 (67,3 %) |
+| davon `SEKUNDÄR` | 84 (24,3 %) |
+| davon `KONTEXT` | 29 (8,4 %) |
+| Belege je Anforderung (Median) | 3,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 129 (99,2 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 124 | 95,4 % |
+| workaround | 5 | 3,8 % |
+| sonderfall | 1 | 0,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 129 | 99,2 % |
+| als `HYPOTHESE` gekennzeichnet | 1 | 0,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 8 | 6,2 % |
+| mit ISO-25010-Qualitätsmerkmal | 37 | 28,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (41 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 130 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 130 von 130 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f99ed7003ffeeUQm86XBQsMt1H`
+- **Werkzeugaufrufe:** 156 – {"bash": 111, "read": 17, "grep": 6, "glob": 1, "write": 7, "edit": 14}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-03T07:01:23.272704+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\Ergebnisse)
+[2026-09-03T07:01:23.411046+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=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
+[2026-09-03T07:29:52.324136+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-03T07:29:54.422734+00:00] OpenCode export: Exporting session: ses_f99ed7003ffeeUQm86XBQsMt1H
+[2026-09-03T07:29:54.453699+00:00] Ende: Exitcode=0; Status=success; Turns=108; Tokens=10220040; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\max\03_Lauf_2026-09-03_090121_v13.0.0-0b8f\RawResult.json

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/anforderungen.md

@@ -0,0 +1,64 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 24 | 18,5 % |
+| SyRS | 47 | 36,2 % |
+| SwRS | 59 | 45,4 % |
+| **Gesamt** | **130** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 60 | 46,2 % |
+| Sicherheit | 23 | 17,7 % |
+| Daten | 19 | 14,6 % |
+| Schnittstelle | 17 | 13,1 % |
+| nicht-funktional | 11 | 8,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 346 |
+| davon `PRIMÄR` | 233 (67,3 %) |
+| davon `SEKUNDÄR` | 84 (24,3 %) |
+| davon `KONTEXT` | 29 (8,4 %) |
+| Belege je Anforderung (Median) | 3,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 129 (99,2 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 124 | 95,4 % |
+| workaround | 5 | 3,8 % |
+| sonderfall | 1 | 0,8 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 129 | 99,2 % |
+| als `HYPOTHESE` gekennzeichnet | 1 | 0,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 8 | 6,2 % |
+| mit ISO-25010-Qualitätsmerkmal | 37 | 28,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (41 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 130 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 130 von 130 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/combined_prompt.md

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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-03T09:29:54.4711449+02:00

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/opencode-config.json

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

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/max/03_Lauf_2026-09-03_090121_v13.0.0-0b8f/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-03T09:01:21.5727980+02:00