TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

Sechs Zellen - z-ai/glm-5.3-flash und qwen/qwen3.8-flash-next je solo, builtin und custom - alle mit dem kompletten Artefaktsatz von sieben Dateien. 47,1 Mio. Tokens in 6,4 Stunden, hochgerechnet rund $3,25. Das Matrixskript heisst jetzt _matrix.ps1 und nimmt -Provider und -Effort; die LM-Studio-Ladeparameter werden nur noch lokal uebergeben. Vor dem Start bestaetigte ein Smoke-Test den TensorX-Pfad unter den seither geaenderten Bedingungen (Denylist, Spiegel, Freigabemuster): Anmeldung, Modellkontrolle, wirksame Effort-Variante und Dateiuebernahme. Befund: Die Anforderungsanzahl haette in die Irre gefuehrt. Qwens custom-Lauf liegt mit 157 Anforderungen im Mittelfeld, ist aber qualitativ zusammengebrochen - 61 Prozent ohne jeden Beleg, 17 Prozent mit Primaerbeleg, 40 Prozent Hypothesen, gegenueber 0 Prozent ohne Beleg und 79 bis 98 Prozent Primaerbelegen in den uebrigen fuenf Laeufen. Er lieferte zugleich weniger als builtin bei 37 Prozent mehr Tokens. Der Moduseffekt ist modellabhaengig: Bei GLM steigt der Ertrag monoton von 126 ueber 139 auf 216 bei durchgaengig hoher Belegqualitaet, bei Qwen ist builtin das Optimum. Die Annahme, rollenspezialisierte Agenten seien generell ueberlegen, traegt damit nicht. Qwens custom-Lauf meldet exit_code 1 bei finish_reason stop und ohne Timeout, nachdem alle 24 Subagenten zurueckkamen und sieben Dateien entstanden. Er ist als gueltig mit Vorbehalt gefuehrt, die Ursache offen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-02 16:21:31 +02:00
parent 6c5c26a2e4
commit e2c3a0e8f8
135 changed files with 102006 additions and 17 deletions
@@ -0,0 +1,5 @@
+[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
+[2026-09-02T11:11:03.862020+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
+[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
@@ -0,0 +1,221 @@
+# Analysebericht
+
+Reverse Requirements Engineering der c-entron ERP-Suite (Baseline, prompt-only). Stand: nach Konsistenzbereinigung.
+Stufen: **tief** = mehrere Anforderungen inkl. verifizierter Durchsetzungsstellen; **mittel** = eigene Anforderung(en) mit PRIMÄR-Beleg; **flach** = Modulinventar + Stichprobe (API-Sicht), keine/eine Requirement; **nicht analysiert** = mit Begründung.
+
+## 1. Ergebnisübersicht
+
+| Kennzahl | Wert |
+|---|---|
+| Anforderungen gesamt | 199 (StRS 16, SyRS 49, SwRS 134) |
+| Belegzeilen | 323 (davon 256 PRIMÄR, Rest SEKUNDÄR/KONTEXT) |
+| Anforderungen ohne Beleg | 0 |
+| Anforderungen ohne Übernahmewürdigkeit | 0 |
+| Hypothesen | 23 (5 SyRS, 18 SwRS, 0 StRS) → Hypothesen.md |
+| Konsolidierungskandidaten | 165 |
+| Verdikte ≠ „übernehmen" | 31 (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischformen 6) |
+| Analysierte Module (Inventar) | 117 von 117 (=100 %); nicht-analysiert-Anteil 0 % (Ziel ≤10 % eingehalten) |
+
+## 2. Modulinventar und Abdeckung
+
+### 2.1 Backend-Fachmodule `src\backend\Centron.BL\` (88 Module, ohne bin/obj/Properties/Resources)
+
+| Modul | .cs | Stufe | Anf. | Kernsatz |
+|---|---|---|---|---|
+| Administration | 959 | tief | 42 | Rechte, Logins/2FA, Lizenzen, Settings, Config-DB, Customizing, Diagnostik, Themes, KI |
+| Sales | 248 | tief | 24 | Belegfluss, Rechnungen, Mahnen, Zahlungen, Helpdesk/SLA, Shop-Preisstellung |
+| WebServices | 464 | mittel | 4 | *WebServiceBL-Schicht als REST-Backend (strukturell analysiert, Details je Fachbereich offen) |
+| Warehousing | 40 | mittel | 2 | Kommissionierung/Barcode mit Rechteprüfung, EK-Fortschreibung |
+| Accounts | 29 | mittel | 4 | Account-Stamm, Nummernvergabe, Filterzwang für Web-Accounts |
+| EDI | 27 | mittel | 1 | EDIDispatcher: Bestellungen hinaus, Antworten herein |
+| DataExchange | 23 | mittel | 5 | Buchhaltungsexport (DATEV/SAP), E-Rechnung, Exportkonfiguration |
+| Mail | 20 | mittel | 1 | austauschbare Mail-Protokollclients, verschlüsselte Secrets |
+| Statistics | 16 | mittel | 1 | Cache-Statistiken + benutzereigene Definitionen |
+| Services | 11 | mittel | 1 | CachedTableBL-Selbstreparatur/Sofortaktualisierung |
+| EmployeeArea | 9 | mittel | 5 | Employee↔AppUser-Mapping, Verfügbarkeit, Dispatcher, Abteilungen, Einstellungen |
+| Finances | 9 | mittel | 1 | PaymentsBL-Rückbuchung über zentralen Buchungspunkt |
+| CustomerArea | 7 | mittel | 1 | Branchenzuweisungen atomar ersetzen |
+| Purchasing | 4 | mittel | 2 | Bestellvorschlagsliste, bereichsübergreifender Lieferantenexport |
+| TaskManager | 4 | mittel | 2 | wiederkehrende Aufgaben mit Lizenz-/Aktionsvalidierung |
+| MyDay | 7 | flach | 1 | Tagesplanungs-Batches mit gemeinsamer BatchId |
+| Production | 2 | flach | 2 | Fertigungsaufträge filterbar; Lizenzpflicht |
+| NexusTicketViews | 1 | flach | 2 | Ticket-Ansichten mit Besitzer-/Namensregeln |
+| CountryArea | 2 | mittel | 3 | Inlandsland, Defaultland, EZB-Kursimport |
+| IndexSearch | 7 | flach | 1 | deutsche Volltextsuche (Stemming, ALL-Semantik) |
+| ReportEngine | 26 | mittel | 1 | PDF-Strategien mit PDF/A3-Fallback; Berichte/Archivierung |
+| RiverDivo | 4 | flach | 1 | Gegenstelle externes Ticketsystem (River Suite) |
+| WebLinks | 4 | flach | 1 | Weblink→CRM-Aktivität |
+| Modules | 3 | flach | 1 | Modulstamm-Autoanlage, Favoriten |
+| CheckListArea | 3 | flach | 1 | Checklisten-Pflicht-Caption, transaktional |
+| Mailings | 2 | flach | 1 | Mailing-Gesamtaggregat laden |
+| Notifications | 2 | flach | 1 | Empfängerlisten-Sync + Meldungs-Cleanup |
+| NexusNotifications | 2 | flach | 1 | rohe SQL-Verwaltung je Empfänger |
+| MyCentron | 4 | flach | 1 | benutzergetrennte Dashboardcontainer |
+| TextModuleArea | 2 | flach | 1 | Textbaustein-Resolver benutzer>kunde>global |
+| TradePool | 2 | flach | 1 | Handelspool-XML-Import |
+| Urls | 2 | flach | 1 | durchsuchbare Objekt-URLs |
+| ToDoArea | 2 | flach | 1 | zentraler ToDo-Typkatalog (>30 Objektarten) |
+| SelfCare | 2 | flach | 1 | Formular→Helpdesk-Ticket (Kette teiloffen) |
+| Integrations | 2 | flach | 1 | ElectronicSales-Gruppen/Rollen-Spiegel (Hypothese) |
+| CPra | 2 | flach | 1 | c-pra-Token/Webhooks |
+| WebSuite | 5 | flach | 1 | Web-Einstellungen nach Login-Art getrennt |
+| PasswordManagementArea | 6 | flach | 1 | Alt-Passwortverwaltung (Hypothese: Nutzung offen) |
+| Security | 1 | flach | 1 | PDF-Signatur mit Zertifikatskonfiguration |
+| TwoFactorAuthenticator | 1 | flach | 1 | personengebundener 2FA-Schlüssel (Erzwingerstelle Hypothese) |
+| PasswordManager | 1 | flach | 1 | Export nur mit Recht/Lizenz/Masterkey |
+| DocumentationArea | 1 | flach | 1 | interne Doku nur mit Leserecht |
+| Tags | 1 | flach | 1 | Tag-Reaktivierung beim Verschlagworten |
+| Tapi | 1 | flach | 1 | CTI-Rufnummern-Suchkaskade |
+| Outlook | 1 | flach | 1 | Kundensuche nach Gerätenummer (Modulminimal) |
+| SocialMedia | 1 | flach | 1 | Kommentare/Likes via DB-Prozeduren (Hypothese) |
+| VideoPortal | 1 | flach | 1 | Videozuweisung rechtsgeprüft + ToDo-Kopplung |
+| DocuBoard | 3 | flach | 1 | Partner-Aggregat-Speicherung |
+| AppointmentRequests | 1 | flach | 1 | Terminanfrage-Antwort gegen Exchange |
+| Calendar | 1 | flach | 1 | Kalender-/Outlook-Sync-Einstellungen |
+| Chats | 1 | flach | 1 | Chat-Guards (250 Zeichen, Autor, Soft-Delete) |
+| MassUpdate | 1 | flach | 1 | Massenänderungs-Vorlagen (Rechte offen) |
+| Processes | 1 | flach | 1 | Prozessmodell-Validierung/Atomarität |
+| ExpectedEvents | 1 | flach | 1 | Überwachungsdefinitionen mit Löschkaskade |
+| Devices | 1 | flach | 1 | Geräte-Soft-Delete mit Protokoll |
+| Logistics | 1 | flach | 1 | Umlagerungsprotokoll validiert |
+| Buying | 1 | flach | 1 | Distributor-Autoanlage bei Import |
+| ProductMatrix | 1 | flach | 1 | Kunden-Produktmatrix mit Historie |
+| Projects | 1 | flach | 1 | nur Lese-API (Hypothese: auslaufend) |
+| TicketProjects | 1 | flach | 1 | Nummernkreis + Soft-Delete-Aufgaben |
+| Time | 1 | flach | 1 | Zeiterfassungs-Settings (Zweck offen) |
+| Transactions | 1 | flach | 1 | Transaktionen je Benutzer (Zweck offen) |
+| VoucherManagement | 1 | flach | 1 | Gutschein-Barcodes per NamedQuery (Hypothese) |
+| ExternalHelpdesk | 1 | flach | 1 | Config-CRUD je Kunde/Kundenort |
+| ExternalToolsBL | 1 | flach | 1 | externe Tools mit Variablenersetzung |
+| ItPlanner | 1 | flach | 1 | virtuelle Checklistenkategorien-Sync |
+| ObjectExternalReferences | 1 | flach | 1 | typisierte Fremdsystem-Referenzen |
+| Telemetry | 1 | flach | 1 | Telemetrie-Buckets mit Upload-Markierung |
+| WebVersion | 1 | flach | 1 | Versionsauskunft |
+| Reporting | 1 | flach | 1 | Legacy-Report-BLOB-Verwaltung |
+| Gateway | 1 | flach | 1 | Custom-Gateway openTRANS (Hypothese) |
+| Customizations | 1 | flach | 1 | Custom-Tabellen-Platzhalter |
+| MailScanner | 1 | flach | 1 | VMA-Profile recht+verschlüsselt |
+| SystemArea | 1 | flach | 1 | Systemzähler-Einzelinstanz |
+| ArtificialIntelligence | 25 | mittel | 1 | KI-Chat-Historie; Provider-Familie (OpenAI/Gemini/Mistral/Claude) |
+| Accounting | 1 | flach | 0 | BankAccount-CRUD inkl. Belegrückgriff (gelesen, keine eigene Requirement) |
+| BusinessPartner | 2 | flach | 0 | Lieferanten-Suche/Anlagen-Buchungen (gelesen; Datenmodell in StRS-005) |
+| Core | 2 | flach | 0 | CryptoUtils, Variablen-Ersetzung (gelesen) |
+| Exceptions | 1 | flach | 0 | TicketExpiredException (gelesen) |
+| GUI | 6 | flach | 0 | UserGrid/ImportOrder/UiProfile (APIs gelesen) |
+| Helpers | 6 | flach | 0 | Graph/PDF/Word/Image-/String-Helfer (APIs gelesen) |
+| Mobile | 1 | flach | 0 | MobileEmployee-Lesen inkl. Bild (gelesen) |
+| Start | 1 | flach | 0 | Mapping-Start/ConnectionString (gelesen) |
+| Storage | 2 | flach | 0 | StorageBL komplett auskommentiert („obsolete"), nur statischer InventoryArticlePool |
+| Tools | 1 | flach | 0 | ToolBL nur ChangeTextFormat (gelesen) |
+| ChangeTracking | 1 | flach | 0 | ImportHistoryBL; Kernlistener liegt unter Centron.DAO |
+| CentronNexus | 1 | flach | 0 | Nexus-Settings Get/Update (gelesen) |
+| CentronIcons | 2 | flach | 0 | Icon-/Ressourcenbestand ohne Fachlogik |
+
+### 2.2 Persistenz und Verträge
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.DAO (Mappings, NamedQueries, Repositories, ChangeTracking, UserTypes) | tief | 10 | ORM-Konventionen, Query-Pool, Audit-/Historie-Erzeugung |
+| Centron.Entities (1179 Dateien) | mittel | 4 | I3D-/Legacy-Abbildung, ObjectType-Nummern, Audit-Basisklasse |
+| Centron.Interfaces | mittel | 2 | Contract-First-Schicht (Details nur oberflächlich) |
+| Centron.Common | flach | 1 | Querschnittsbibliothek Logging/Netzwerk/Codierung |
+| src\shared\Centron.Core (TotpAuth) | flach | 1 | TOTP-Bibliothek |
+| SSMS_DB_SCHEMA.sql | mittel | 5 | RechKopf/RechPos, Zahkond, cvw_InvoiceDunnings als Datenbasis |
+
+### 2.3 Webservice (5 Projekte)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.Host (Host-Regie, Auth-Schemas, TicketHandler) | tief | 6 | globales RequireAuthorization, HttpSys/Kestrel, Dienstbetrieb |
+| Centron.Controllers (Authorization-Filter, API-Versionierung, GlobalExceptionFilter) | tief | 4 | 401/403-Filter, Namespace-Versionierung, 500-Pfad |
+| Centron.WebServices.Core (CentronWebService-Client) | flach | 1 | RESTC-Kanal, Kompression, Proxy |
+| Centron.Host.WindowsService | flach | 1 | Fehlerkapselung OnStart/OnStop |
+| c-entron.misc.ConnectionManager | flach | 1 | Diagnose-Werkzeug |
+
+### 2.4 Nexus (6 Bereiche)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| CentronNexus.Host (Program.cs) | tief | 3 | Cookie+OIDC-Registrierung, iframe/Cookie-Middleware |
+| WebCart (Kundenportal) | tief | 6 | Port-/Loginzwang, Sortiment, Preis, Prüfstufe, Ticketseiten |
+| ServiceBoard | mittel | 3 | Login-/Lizenz-/Portschutz, Kanban, TicketCache |
+| Shared (Auth, TicketCache, NotificationHub, SignalR) | tief | 6 | Open-Redirect-Schutz, AuthController, Push-Zustellung |
+| Office (PdfController/FilePreview) | flach | 1 | Cache-PDF-Auslieferung |
+| DocumentSigning + WebOffer | mittel | 3 | Signatur-/Akzeptanzstrecke, tokenierte Angebotsseite |
+
+### 2.5 Desktop (1 Modul) und APIs (9 Adapter)
+
+| Modul | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| Centron.WPF.UI (Shell, Login, Module, Finances-Masken) | tief | 6 | Single-Instance, Login-Gate, Layout/Pflichtfelder/Feldvalidierung |
+| Centron.Api.Gls | flach | 2 | Sendungsupload mit Vorabvalidierung |
+| Centron.Api.Shipcloud | flach | 1 | Sendungsanlage/Carrier-Abruf |
+| Centron.Api.EbInterface | flach | 1 | eb:interface 4.3 (AT) |
+| Centron.APIs.CopDataAccess | flach | 1 | SOAP-Session-Produktdaten |
+| Centron.APIs.EgisDataAccess | flach | 2 | EGIS-Artikelsuche |
+| Centron.APIs.FinAPI | flach | 1 | PSD2-Bankdaten |
+| Centron.APIs.IcecatDataAccess | flach | 1 | Produktinhalte je EAN |
+| Centron.APIs.ITscopeDataAccess | flach | 2 | Produkte/Angebote/Deals |
+| Centron.Api.docuFORM | flach | 1 | Gerätezähler OAuth2-PKCE |
+
+### 2.6 Dokumentation/Modelle
+
+| Artefakt | Stufe | Anf. | Kernsatz |
+|---|---|---|---|
+| README.md | flach | 2 | WebCart-Zieldefinition |
+| CentronRights.md | flach | 2 | Semantik einschränkender Rechte |
+
+### 2.7 Abdeckungsblatt (Stufen je Komponente)
+
+| Stufe | Module | Anteil |
+|---|---|---|
+| tief | 8 (Administration, Sales, DAO, Centron.Host, Controllers, WebCart, Shared, WPF-UI) | 6,8 % |
+| mittel | 24 | 20,5 % |
+| flach | 85 | 72,6 % |
+| nicht analysiert | 0 | 0 % |
+
+Damit ist jede Inventarzeile mindestens flach erfasst; tiefe Durchdringung liegt planmäßig bei Sicherheit, Abrechnung, Portal und Plattform.
+
+## 3. Risikorelevante Anforderungen (Sicherheit, Abrechnung, Berechtigungen)
+
+Prüfregel: jede riskante Anforderung hat PRIMÄR-Beleg der Durchsetzungsstelle **oder** ist als HYPOTHESE markiert. Ergebnis: 32/32-Sicherheitsanforderungen erfüllt (30 mit PRIMÄR, 2 als HYPOTHESE markiert).
+
+### 3.1 Zugriff & Authentifizierung (PRIMÄR-belegt)
+StRS-004 (AppRightsBL, AppUserGroupBL), SyRS-001 (UserRightAuthorizationFilter), SyRS-002 (TwoFactorAuthBL/RadiusClient/EmailValidator), SyRS-003 (CentronHostedHandler), SyRS-004 (DataSecurityBL), SyRS-005 (Authenticator/LicenseManager/TicketBL), SyRS-006 (TicketAuthenticationHandler + RequireAuthorization), SyRS-007 (Nexus Program.cs/AuthController), StRS-006/SyRS-016/SyRS-018 (ReceiptCartBL-Guards), SwRS-001 (AppRightsBL fail-closed), SwRS-003 (BasicAuthenticator), SwRS-018 (OrderCommissionBL), SwRS-024 (ProductionBL), SwRS-044 (ServiceBoard _Imports), SwRS-051 (AuthController Redirect), SwRS-053/054 (TicketAuthenticationHandler), SwRS-066/070 (docuFORM PKCE, MailScanner), SwRS-077 (VideoPortalAssignmentBL), SwRS-107 (DocumentationBL), SwRS-127 (HelpdeskBL.CheckUserRigths), SwRS-129 (FrontWindow.Login), SwRS-040 (ReceiptCartBL Rechte-/Prüfstufenguard, nachgetragen), SwRS-008 (PasswordManagerBL), SwRS-009 (DataSecurityBL Anonymisierung).
+
+### 3.2 Sicherheit mit Hypothesenstatus (offene Erzwingerstelle)
+SwRS-004 (2FA-PIN: Erzwingerstelle im Login-Ablauf offen), SwRS-005 (Alt-Passwortnutzung offen), SwRS-006 (Rechtsprüfung bei Signatur-Settings offen), SwRS-007 (Datenfilter „nur eigene Tickets" auf BL-Seite offen), SwRS-055 (TOTP-Prüfstelle offen), SyRS-019/020/021 (Token-Lebenszyklus, Servervalidierung, Cache-Id-Zugriff).
+
+### 3.3 Abrechnung/Berechtigung (PRIMÄR-belegt)
+StRS-003/StRS-011/StRS-016; SyRS-010 (ReceiptBL.UpdateReceiptNumber), SyRS-011 (HandleIsAlreadyExported/CancelInvoice), SyRS-012 (DunningRunBL transaktional), SyRS-013 (UpdateReceiptIsPaid mit ConcurrencyGuid), SyRS-014 (InvoiceSpecificLogic), SyRS-015/017 (ReceiptCartBL), SyRS-041 (Skonto), SwRS-010..014 (Storno/Preise), SwRS-019 (EK-Fortschreibung), SwRS-102 (PDF/A3), SwRS-108 (Textbausteine), SwRS-123 (Gutscheine, HYPOTHESE), SwRS-131 (Pflichtfelder).
+
+## 4. Konsistenzprüfung (Ergebnis nach Bereinigung)
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Doppelte IDs | 0 (199 eindeutige IDs: StRS-001..016, SyRS-001..049, SwRS-001..134, lückenlose Sequenzen) |
+| Anforderungen ohne Belege | 0 |
+| Anforderungen ohne Übernahmewürdigkeit | 0 |
+| Verwaiste Trace-Links | 0 (vor Bereinigung: 0 toter Verweis, aber 29 semantisch falsche Eltern→Kind-Referenzen; alle korrigiert) |
+| Kind→Elter-Rückwärtsverfolgung | vollständig (100 %) |
+| Elter→Kind-Vorwärtsverfolgung | selektiv geführt; vollständige Rekonstruktion über Kind→Elter (in Traceability.md begründet) |
+| Deckungsgleiches ohne Konsolidierungsmarkierung | 0 aufgefundene Duplikatpaare bleiben unmarkiert; u.a. markiert: NumberGroupBL↔MandatoryBL (SwRS-099), AppSettings-Zwillinge (SyRS-029/SwRS-096), Abteilungs-Parallelimplementierung (SwRS-032), Alt-/Neu-Reports (SwRS-103), Portal-Rechtefamilie (SyRS-016..018) |
+| Hypothesen-Abgleich | 23 Inline-Markierungen = 23 Einträge Hypothesen.md |
+| Sicherheits-/Abrechnungsregeln | 32/32 mit PRIMÄR oder HYPOTHESE (siehe 3.) |
+| Konsolidierungszähler StRS↔SyRS↔SwRS | Geschwisterlinks SyRS-010↔044, SyRS-039↔011 als Querverweise kenntlich gemacht |
+
+## 5. Dünne Belegstellen (Nachsteuerung nötig)
+
+1. Logik außerhalb des Quellcode-Bestands: DB-Prozeduren „SocialMedia.*" (SwRS-075), NamedQuery-SQL (SwRS-123), gespeicherte Sichten.
+2. Erzwingerstellen nicht ablesbar: 2FA-PIN-Aufrufpfad (SwRS-004/055), PDF-Signatur-Settings (SwRS-006), WebCart-Ticketfilter (SwRS-007), Token-Erzeugung WebOffer (SyRS-019), Backend-Signaturvalidierung (SyRS-020), Cache-Id-Autorisierung (SyRS-021).
+3. Zweck/Nutzung unklar: Projects, Transactions, Time/TimingSettings, VoucherManagement, ElectronicSales-Sync (SwRS-119/122/121/123/134), Alt-Passwortkeywords (SwRS-005).
+4. Nebenläufigkeit/Risiken dokumentiert, aber nicht bewertet: Mahnlauf „Max+1" (SyRS-012), Auto-Sync bei Abfrage (SwRS-118), best-effort ChangeLog (SwRS-093).
+
+## 6. Selbstbewertung (absolut)
+
+- Erfasst: 199 Anforderungen; 16 StRS decken 100 % der SyRS-Eltern; jede SyRS hat 1–2 StRS-Eltern; 84 % der SwRS (113/134) nennen eine SyRS als direkten Elter, der Rest referenziert direkt die StRS (begründet: Ein-Modul-Funktionalitäten ohne Systemverhalten eigener Art).
+- Belegt: 323 Belege, davon 256 PRIMÄR (Durchsetzungsstelle), 199/199 Anforderungen mindestens ein Beleg.
+- Hypothesen: 23 (11,6 %), alle mit Prüffrage in Hypothesen.md; keine Requirement ohne Status.
+- Verworfen/abgestuft statt „übernehmen": 31 Verdikte (Workaround 8, Sonderfall 7, veraltet 6, unklar 4, Mischungen 6).
+- Modulinventar: 117 Zeilen, alle mit Kennsatz; Stufen: tief 8, mittel 24, flach 85, nicht analysiert 0.
+- Bekannte Grenzen des Laufs: WebServices-Schicht (464 Klassen) nur strukturell; Entities/DAO nur stichprobenartig; ReportEngine, Calendar, Statistics, Warehousing nur anzapfend; DB-Prozeduren/NamedQuery-SQL nicht im Bestand; UI (WPF/Nexus-Seiten) nur an Belegstellen gelesen; Performanz-/Verfügbarkeits-NFVs außerhalb des Quellcodes nicht messbar (deshalb 0 Benchmark-Anforderungen).
@@ -0,0 +1,95 @@
+# Glossar
+
+Fach- und Systembegriffe der c-entron ERP-Suite, wie aus den Artefakten abgeleitet. Links in eckigen Klammern zeigen auf prägende Anforderungen.
+
+## Identität, Rechte, Lizenz
+
+| Begriff | Bedeutung |
+|---|---|
+| I3D | Zentraler ganzzahliger Primärschlüssel aller Datenbankobjekte (allgegenwärtige Konvention `Id(a => a.I3D)`). [SyRS-034] |
+| Employee | Personalstammdatensatz (Mitarbeiter); eigenständige Identität neben dem Zugang. [StRS-007] |
+| AppUser | Interner Systemzugang (Login, Rechtegruppen, 2FA); per Mapping an einen Employee gebunden. [SwRS-029] |
+| Web-Account | Portalzugang eines Endkunden; dritte Identitätsart mit eigener Rechtequelle WebRights. [StRS-006] |
+| Recht / Rechtegruppe | Deklarierte Berechtigung, gruppenweise über Sichusr/Sichmemb an AppUser; Prüfung zentral über AppRightsBL.HasUserRight (Fail-closed). [SwRS-001] |
+| Einschränkendendes Recht (restricting right) | Recht, das andere Rechte entzieht; in der Admin-Gruppe nur eingeschränkt zuweisbar. [StRS-004] |
+| WebRights | Portalrechte (z. B. "Warenkorb bestellen", "Tickets abschließen"), serverseitig erzwungen. [SyRS-018] |
+| Lizenz / CentronInternal | Modulare Lizenzpflicht; interne Funktionen nur mit CentronInternal-Lizenz. [SyRS-003] |
+| Sitzungsticket | Zeitlich begrenztes Authentifizierungsticket je Anwendung (30/5/1440 Minuten). [SyRS-005] |
+| Access-Token | Personengebundener API-Nachweis (Bearer/access_token), mit Client-Kontext validiert. [SwRS-002, SwRS-054] |
+| 2FA / TOTP | Zweitfaktor per RADIUS, E-Mail-Link (Login) oder TOTP-Bibliothek (Schlüssel). [SyRS-002, SwRS-004, SwRS-055] |
+| Masterkey | AES-Master-Passwort der Konfigurations-DB zum Entschlüsseln von Secrets. [SyRS-030] |
+
+## Organisation und Mandantenmodell
+
+| Begriff | Bedeutung |
+|---|---|
+| Mandant | Rechtlich-organisatorische Oberinstanz mit eigenem Default-Land und Nummernkreisen. [StRS-009, StRS-016] |
+| Filiale (Branch) | Unterhalb des Mandanten mit genau einem Default-Lager plus Sekundärlagern. [StRS-010] |
+| Inlandsland | Über den Default-Mandanten deterministisch abgeleitetes Steuer-/Preisland. [SwRS-042] |
+| Account / Kunde / Lieferant | Neuer, maßgeblicher Adressstamm (Account*, AccountCustomer, AccountSupplier) als Migrationsziel der Altstämme Customer/Address/Supplier. [StRS-005] |
+
+## Beleg- und Zahlungswesen
+
+| Begriff | Bedeutung |
+|---|---|
+| Beleg / Belegart | Urkundentypisiertes Fachobjekt mit Kopf/Positionen (Tabelle RechKopf/RechPos), nummernkreis- und pflichtgeführt. [StRS-003, StRS-016] |
+| Belegfluss / Herkunft | Verknüpfung Ursprungs→Folgebeleg über RechPos.UrsprungI3D/UrsprungArt. [SwRS-010] |
+| Zahkond / Zahlungsbedingung | Zentral gepflegte Kondition mit Zahlungsziel und bis zu drei Skontostaffeln. [StRS-011] |
+| Skonto | Skonto1..3 (Prozent/Tage) je Zahlungsbedingung, mit Textbaustein-Vorschau gegen Testrechnung. [SwRS-012, SwRS-034] |
+| Mahnstufe | Eskalationsstufe None→1→2→3 im transaktionalen Mahnlauf über fällige aktive Rechnungen. [SyRS-012] |
+| Opos | Offene Posten; Auswertung auf derselben Belegbasis wie der Mahnlauf. [StRS-003] |
+| IsReceiptExported | Kennzeichnung "an Buchhaltung übergeben"; steuert Versionszwang und Stornoverbot. [SyRS-011] |
+| Sonderpreis / Sondervereinbarung | Kundenindividuelle Artikelvereinbarung; begrenzt das Shop-Sortiment und die Nettopreisstellung. [SyRS-017, SyRS-015] |
+| Preishierarchie | Preisfindung Vertrag > Sonderpreis > Staffelpreis, zweistufig gerundet. [SwRS-013, SwRS-014] |
+
+## Helpdesk und Organisation
+
+| Begriff | Bedeutung |
+|---|---|
+| Ticket (Helpdesk) | Servicevorgang mit Statusmaschine, SLA-Priorität, Historie und Abschluss-Checkliste. [StRS-013, SyRS-043, SwRS-127] |
+| SLA-Priorität | Aus dem Servicevertrag erzwungene Ticketpriorität inkl. abgeleitetem Fälligkeitsdatum. [StRS-012] |
+| Abschluss-Checkliste | Checkliste mit CanClose-Punkten; offen ⇒ Abschluss blockiert. [SwRS-127, SwRS-114] |
+| ToDo / Wiedervorlage | Bereichsübergreifende Aufgabenliste mit über 30 registrierten Objektarten. [StRS-014] |
+| ObjectKind / ObjectI3D / ObjectType | Typisierte Objektreferenz mit zentraler, unveränderlicher Typnummernliste. [SwRS-112] |
+
+## Portal, Kanäle und Integrationen
+
+| Begriff | Bedeutung |
+|---|---|
+| WebCart / Kundenportal | Endkunden-Selfservice (Shop, Warenkorb, Tickets, Dokumente) auf eigenem Port, nur Web-Account-Login. [SyRS-016] |
+| Prüfstufe | Vier-Augen-Freigabe im Warenkorb (bereit zur Prüfung → geprüft). [SwRS-040] |
+| ServiceBoard | Mitarbeiter-Browserarbeitsplatz im Nexus mit Login-, Lizenz- und Portschutz. [SwRS-044] |
+| WebOffer | Loginfreie, token-gesteuerte Angebotsansicht. [SyRS-019] |
+| SharedDocument / Signierstrecke | Token-basierte Dokumentenfreigabe mit Zeichnungs-/Typ-/Upload-Signatur (SEPA: IBAN-Pflicht). [SyRS-020] |
+| RESTC | Standardisierter komprimierter REST-Kanal des Zentralklienten. [SyRS-025] |
+| openTRANS | XML-Austauschformat für EDI-Bestellungen/Antworten; Custom-Gateway für Sonderfälle. [SyRS-045, SwRS-133] |
+| ZUGFeRD / XRechnung / eb:interface | Normkonforme E-Rechnungsformate (DE/AT). [SyRS-040, SwRS-058] |
+| Handelspool / EGIS / ITscope / Icecat / Cop | Distributor-/Poolquellen für Fremdarticlelnhalte und -preise. [SyRS-046] |
+| c-pra | Externer Freigabe-/Workflowdienst (Nexoware Smartflow) mit Token-Login und Webhooks. [SwRS-115] |
+| Riverbird / River Suite | Externes Ticketsystem mit Helpdesk-Gegenstelle und DB-/WebService-Trennregel. [SyRS-048, SwRS-098] |
+| docuFORM | Gerätezähler-Fernübermittlung per OAuth2-PKCE. [SwRS-066] |
+
+## Technik und Plattform
+
+| Begriff | Bedeutung |
+|---|---|
+| WebServiceBL | Service-spezifische BL-Schicht der REST-Dienste (464 Klassen). [SyRS-028] |
+| NamedQuery / NamedQueryPool | Zentral gepflegte SQL-/HQL-Abfragen statt SQL im Code. [SyRS-035] |
+| DBUpdate / ScriptEngine | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll. [SyRS-023] |
+| ChangeTracking / ChangeLog | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer (Update-only, best-effort). [SyRS-033, SwRS-093] |
+| CreatedBy/CreatedDate/CreatedVersion | Auditfelder der DBEntity-Basisklasse, Repository-erzwungen. [SwRS-110] |
+| Soft-Delete | Löschung durch Deaktivierung (IsActive/Deleted) statt Zeilenentfernung. [SwRS-023, SwRS-120] |
+| Nummernkreis (NumberGroup) | Fortschreibender Zähler je Mandant/Filiale/Belegart mit Intervall und Delegation. [SyRS-044, SwRS-099] |
+| HostedService / ExecuteServices | Hintergrunddienste, zentral per Konfigurationsflag schaltbar. [SyRS-022, SwRS-084] |
+| TicketCache (Nexus) | Prozessweiter Singleton-Cache mit HostedService-Synchronisation. [SyRS-037] |
+| AppSetting / ApplicationSetting | Zwei Settings-Generationen mit fehlertolerantem On-Demand-Default. [SyRS-029, SwRS-096] |
+| DSGVO-Löschung / Anonymisierung | Rechtegebundene Nullung personenbezogener Ansprechpartnerfelder mit Löschprotokoll. [SyRS-004, SwRS-009] |
+
+## Arbeitsbegriffe dieser Spezifikation
+
+| Begriff | Bedeutung |
+|---|---|
+| PRIMÄR / SEKUNDÄR / KONTEXT | Belegklassen: Durchsetzungsstelle im Quelltext / Struktur- oder Modellbeleg / dokumentarischer Kontext. |
+| HYPOTHESE | Status: fachliche Regel plausibel, aber Durchsetzung/Zweck nicht vollständig artefaktbelegt; offen in Hypothesen.md. |
+| Übernahmewürdigkeit | Verdikt für das Migrationsziel: übernehmen / Workaround / Sonderfall / veraltet / unklar. |
+| Konsolidierung | Markierung von Anforderungen, die inhaltlich zusammenzuführen sind (Duplikate/Parallelimplementierungen). |
@@ -0,0 +1,102 @@
+# Hypothesen-Liste
+
+Enthält exakt die Anforderungen mit `Status: HYPOTHESE` aus StRS.md, SyRS.md und SwRS.md (Abgleich: 0 StRS, 5 SyRS, 18 SwRS = 23). Zu jeder Hypothese: Grund der Markierung und offene Frage zur Bestätigung.
+
+## SyRS
+
+### SyRS-019 – Token-basierte Angebotsansicht ohne Login
+- Offen: Token-Erzeugung, Ablauf und Rate-Limiting sind nicht nachgewiesen; der Token-Erzeugungscode wurde nicht gefunden.
+- Prüfen: Erzeugungsstelle des Receipt-Access-Tokens incl. Gültigkeitsdauer und Wiederverwendungsschutz.
+
+### SyRS-020 – Signatur- und Akzeptanzstrecke für freigegebene Dokumente
+- Offen: serverseitige Validierung außerhalb der UI (CanAccept) nicht nachgewiesen.
+- Prüfen: Confirm/Decline-Endpunkte im Backend auf unabhängige Signatur-/IBAN-Prüfung.
+
+### SyRS-021 – PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt
+- Offen: Zugriffskontrolle auf Cache-Ids nicht sichtbar.
+- Prüfen: `getcachedfile/{id}/{filename}` mit fremder/erratener Cache-Id (Authorisierung, Ratenbegrenzung).
+
+### SyRS-025 – Standardisierter komprimierter REST-Kanal „RESTC"
+- Offen: „unbegrenztes Timeout" nur durch Kommentar belegt.
+- Prüfen: tatsächliche Timeout-/CancellationToken-Implementierung des CentronWebService-Clients.
+
+### SyRS-039 – Buchhaltungsexport in austauschbare Zielsystemformate
+- Offen: Detailregeln je Zielformat (DATEV, SAP, ...) nicht analysiert; nur Struktur und Default-Regel belegt.
+- Prüfen: Format-Builder je Zielsystem inkl. Kontenfindung und Stornologik.
+
+## SwRS
+
+### SwRS-004 – Prüfung des personengebundenen Zwei-Faktor-Schlüssels
+- Offen: aufrufende Erzwingerstelle im Login-Ablauf nicht nachgewiesen.
+- Prüfen: alle Login-Endpunkte/Masken daraufhin, ob `ValidateAuthenticationPin` zwingend aufgerufen wird.
+
+### SwRS-005 – Alt-Passwortverwaltung (Keywords) – Migrationsbedarf
+- Offen: keine Belege für aktive Nutzung (UI-/Aktivierungsnachweis fehlt).
+- Prüfen: Referenzsuche nach Konsumenten; Entsorgung entscheiden.
+
+### SwRS-006 – Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration
+- Offen: Rechtsprüfung beim Pflegen der Signatur-Einstellungen nicht im Detail verifiziert.
+- Prüfen: Save-Pfad von `PdfSigningBL` auf Rights-Guard.
+
+### SwRS-007 – Ticketansichten im Kundenportal nach Web-Rechten differenzieren
+- Offen: eigentliche Datenfilterung „nur eigene Tickets" nicht im Detail nachgewiesen.
+- Prüfen: BL-Seite der Ticketlisten im WebCart auf WebAccount-/Vertriebsgebietsfilter.
+
+### SwRS-035 – Preis- und Rabatttransparenz im Shop
+- Offen: Priorisierung von Sondervereinbarungen innerhalb der Preisfindung nicht vollständig nachverfolgt.
+- Prüfen: `ReceiptPriceHelper`-Kette bei gleichzeitiger Sondervereinbarung + Staffelpreis.
+
+### SwRS-036 – SelfCare-Formular erzeugt Helpdesk-Ticket
+- Offen: Trigger→Ticket-Ausführungskette nicht vollständig verfolgt.
+- Prüfen: ActionHandler-Kette vom Formular-Save bis zur Helpdesk-Anlage.
+
+### SwRS-046 – Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl
+- Offen: fachliche Vervollständigung unklar.
+- Prüfen: Rückfrage an Fachbereich Produktion; Seiten-Rohtext lesen.
+
+### SwRS-054 – Client-Kontext (IP, API-Methode) in der Access-Token-Validierung
+- Offen: konkrete IP-/Methoden-Bindungsregel in `AccessTokenBL.ValidateToken` nicht eingesehen.
+- Prüfen: ValidateToken-Quelltext inkl. Edge Cases (Proxy-IP, Methodswechsel).
+
+### SwRS-055 – TOTP-Zwei-Faktor-Bibliothek im Plattformkern
+- Offen: erzwungene Prüfstelle im Login-Pfad nicht gezeigt.
+- Prüfen: Konsumenten von `Totp.cs` im Anmelde-/Einstellungen-Pfad.
+
+### SwRS-056 – Schnittstellenmodul als Contract-First-Schicht
+- Offen: Einzelinterface-Inhalte nur oberflächlich geprüft.
+- Prüfen: Stichprobe der Interface-Definitionen gegen Implementierungen.
+
+### SwRS-057 – Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung)
+- Offen: Detailverhalten der Klassen nicht gelesen.
+- Prüfen: AESCryptoLogic-Schlüsselherkunft und Logging-Rotation.
+
+### SwRS-075 – Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren
+- Offen: Kernlogik liegt in DB-Prozeduren, deren Inhalt nicht im Artefaktbestand liegt.
+- Prüfen: Prozeduren „SocialMedia.*" aus SSMS-Export oder Server beschaffen.
+
+### SwRS-119 – Projektliste mit Erstellungsdatumfilter (rumpfhaft)
+- Offen: Save/Delete nirgends belegt; Modul möglicherweise auslaufend.
+- Prüfen: Referenzsuche nach `ProjectBL`-Konsumenten.
+
+### SwRS-121 – Zeiterfassungs-Stammeinstellungen pflegen
+- Offen: fachlicher Zweck der Settings nicht ableitbar (keine Konsumenten belegt).
+- Prüfen: Konsumenten von `TimingSetting` identifizieren (Timer/CTime).
+
+### SwRS-122 – Benutzerbezogene Transaktionen mit Kategorie-Details
+- Offen: Verwendungszweck nicht aus Artefakten belegt.
+- Prüfen: UI-/Webservice-Konsumenten der TransactionBL.
+
+### SwRS-123 – Aktive Gutschein-Barcodes per NamedQuery
+- Offen: SQL im NamedQuery-Pool; Zustandssemantik nicht verifizierbar.
+- Prüfen: NamedQuery `VoucherManagementGetVoucherArticles` + Flags gegen Testdaten.
+
+### SwRS-133 – Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen
+- Offen: Methodenumfang nicht gelesen; REST-Aufrufverbindung nur vermutet.
+- Prüfen: `CustomGatewayBL`-Methoden und `CentronRestService.CustomGateway.cs` durchgehen.
+
+### SwRS-134 – Externe ElectronicSales-Gruppen/Rollen lokal spiegeln
+- Offen: eigentlicher Sync-Abruf liegt außerhalb des Moduls; End-to-End-Verhalten unbelegt.
+- Prüfen: Sync-Initiator (Hintergrunddienst/Webservice) identifizieren.
+
+## Begründung der Hypothesen-Quote
+Die 23 Hypothesen betreffen überwiegend (a) Logik außerhalb des Quellcode-Bestands (DB-Prozeduren, NamedQuery-SQL, externe Systeme), (b) nicht gelesene Konsumenten-/Erzwingerstellen und (c) möglicherweise auslaufende Module. Alle Sicherheits- und Abrechnungsanforderungen mit zweifelhaftem Durchsetzungsbeleg sind markiert; keine StRS-Hypothese, weil jede StRS mehrere unabhängige PRIMÄR-Belege hat.
@@ -0,0 +1,345 @@
+# StRS - Stakeholder Requirements Specification
+
+Quelle: c-entron ERP-Suite (Reverse Requirements Engineering, ISO/IEC/IEEE 29148:2018).
+Alle Pfade relativ zum Arbeitsverzeichnis. Belegklassen: PRIMÄR / SEKUNDÄR / KONTEXT.
+
+---
+
+ID:            StRS-001
+Titel:         Ein gemeinsames ERP-System für alle Fachprozesse
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        ERP-Anwender (Vertrieb, Einkauf, Lager, Service, Finanzen)
+Vorbedingung:  Client ist gestartet, Benutzer ist angemeldet
+Fakt:          WPF-Shell `FrontWindow` exportiert `OpenModule/CloseModule/DockModule`; unter `src\centron\Centron.WPF.UI\Modules\` existieren 29 Fachmodule (Finances, Helpdesk, Warehousing, Production, ...), jedes mit Modul-Controller; das Webfront CentronNexus ergänzt Browser-Zugriffe.
+Aussage:       Das System soll alle ERP-Fachprozesse (Angebot bis Rechnung, Einkauf bis Lager, Helpdesk bis Finanzen) in einer gemeinsamen, modular erweiterbaren Anwendung bereitstellen.
+Ergebnis:      Alle Fachbereiche sind über eine Shell mit öffn-/schließbaren Modulen erreichbar; kein Fachbereich läuft als Insellösung.
+Belege:
+  - [PRIMÄR] src\centron\Centron.WPF.UI\FrontWindow.xaml.cs, OpenModule/CloseModule/DockModule - Begründung: zentraler Modulvertrag der Gesamtleistung
+  - [SEKUNDÄR] src\centron\Centron.WPF.UI\Modules\ (29 Modulordner), src\centron\Centron.WPF.UI.Extension\Modules\ICentronAppModule.cs - Begründung: Modularchitektur als Systemprinzip
+Prüfidee:      Jedes der 29 Fachmodule lässt sich ohne Neustart öffnen, andocken und schließen.
+Tracelinks:    SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - modulare Gesamt-ERP-Idee ist das tragende Produktversprechen
+Status:        belegt
+
+---
+
+ID:            StRS-002
+Titel:         Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Endkunde eines c-entron-Kunden (Web-Account), Kundenadministrator
+Vorbedingung:  Mandant hat WebCart-Lizenz, Kunde besitzt Sonderpreise und Web-Accounts
+Fakt:          README: "The webcart is a feature primarily intended for the customers of our customers"; Portal unter `/customerportal` mit Tickets, Formularen, Dokumenten, Belegen/Verträgen sowie Shop/Warenkorb; Bestell-/Prüfrechte werden serverseitig in `ReceiptCartBL` erzwungen.
+Aussage:       Das System soll Endkunden den kompletten Selbstbedienungspfad (Sonderpreis-Sortiment → Warenkorb → Bestellung, Tickets/Formulare/Dokumente) ohne ERP-Benutzer öffnen, wobei der Kundenadministrator Rechte und Benutzer selbst verwaltet.
+Ergebnis:      Bestellungen und Servicevorgänge erreichen das ERP ohne manuelle Erfassung durch den c-entron-Kunden.
+Belege:
+  - [SEKUNDÄR] README.md, Zeilen 31-36 - Begründung: dokumentiertes Ziel des WebCart
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Rechte-/Portprüfungen (Zeilen 133, 859-864) - Begründung: der Selbstbedienungspfad ist serverseitig erzwungen implementiert
+  - [SEKUNDÄR] src\nexus\CentronNexus\WebCart\CustomperPortalHomePage.razor, Route `/customerportal` - Begründung: Portalbündel als eigene Startseite
+Prüfidee:      Durchlauf ohne ERP-Benutzer: Shop-Suche → Warenkorb → Bestellung mit Bestellrecht; Formular erzeugt Helpdesk-Ticket.
+Tracelinks:    SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Wachstums-/Entlastungsziel
+Status:        belegt
+
+---
+
+ID:            StRS-003
+Titel:         Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Debitorenbuchhaltung
+Vorbedingung:  Auftrag oder Lieferschein mit Positionen existiert
+Fakt:          `ReceiptProgressionBL.GetRelatedItemsForObject` ermittelt Ursprungs-/Folgebelege über `RechPos.UrsprungI3D/UrsprungArt`; `InvoiceSpecificLogic` deklariert `CanBeForwardedFrom/Into`; Mahnwesen/Opos greifen auf dieselbe RechKopf-Basis zu (View `cvw_InvoiceDunnings`).
+Aussage:       Das System soll jeden Beleg über seine Positionsherkunft lückenlos mit Ursprungs- und Folgebelegen verknüpfen und diese Kette für Fakturierung, Mahnwesen und Debitorensteuerung nutzbar machen.
+Ergebnis:      Zu jeder Rechnung sind Vorbelege und Weiterverarbeitungen eindeutig bestimmbar; nur überfällige aktive Rechnungen erreichen Mahn-/Opos-Läufe.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs, GetRelatedItemsForObject/CreateOriginReceiptsSql - Begründung: Belegkette technisch über alle Belegarten erzwungen
+  - [SEKUNDÄR] src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs, CanBeForwardedFrom/Into (Zeilen 279-280) - Begründung: definierte Übergänge des Belegflusses
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, View [dbo].[cvw_InvoiceDunnings] - Begründung: Auswertungen setzen auf derselben Belegbasis auf
+Prüfidee:      Auftrag → Rechnung; beide erscheinen im Belegfluss; bezahlte Rechnung taucht im Mahnlauf nicht auf.
+Tracelinks:    SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041
+Konsolidierung: Kandidat: Sammelthema "Belegfluss Auftragsabwicklung" mit Lieferschein/RMA-Verzweigungen (ReceiptProgressionBL)
+Übernahmewürdigkeit: übernehmen - tragendes Prinzip der Auftragsabwicklung
+Status:        belegt
+
+---
+
+ID:            StRS-004
+Titel:         Wer darf was - selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Benutzer mit Recht UserRightsManagement; Administratoren
+Vorbedingung:  Anmeldung an der c-entron-Verwaltung
+Fakt:          `AppRightsBL.SaveRightGroup` prüft `HasUserRight(UserRightsManagement)` und bei `MANAGE_RIGHTS_ONLY_OWN_BRANCH` die Filialzugehörigkeit; `DeleteRightGroup` verbietet das Löschen der Gruppe I3D==6/"Administratoren"; in der Admin-Gruppe sind nur freigegebene einschränkende Rechte zuweisbar.
+Aussage:       Das System soll das Anlegen, Ändern und Löschen von Rechtegruppen nur berechtigten Benutzern gestatten, bei Filialbindung auf die eigene Filiale beschränken und die Administratorengruppe gegen Löschung/Entrechtung schützen.
+Ergebnis:      Nicht berechtigte/filialfremde Anfragen werden abgewiesen; Admin-Gruppe bleibt erhalten.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs, SaveRightGroup/DeleteRightGroup - Begründung: exakte Durchsetzungsstellen inkl. Bedingungen
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Rights\AppUserGroupBL.cs, IsAdministratorGroupI3D (`groupI3D == 6`) - Begründung: harter Admin-Gruppenschutz
+  - [SEKUNDÄR] CentronRights.md, Abschnitt "This is a restricting right" - Begründung: Fachsemantik einschränkender Rechte
+Prüfidee:      Benutzer ohne UserRightsManagement legt Gruppe an → Fehler; Admin-Gruppe löschen → Fehler; filialfremde Gruppe bei MANAGE_RIGHTS_ONLY_OWN_BRANCH → Fehler.
+Tracelinks:    SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - klare Gewaltenteilung und Selbstschutzregel
+Status:        belegt
+
+---
+
+ID:            StRS-005
+Titel:         Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Datenverantwortliche, Systemarchitektur
+Vorbedingung:  Altstruktur (Customer/Address/ContactPerson) und neuer Account-Stamm koexistieren
+Fakt:          Entities `CustomerArea\Customer.cs` (DeliveryConditionI3D) und `Accounts\AccountCustomer.cs` (ReceiptConditionDeliveryI3D) führen Parallelfelder; `Supplier` (Businesspartner) und `AccountSupplier` (Accounts) führen Frachtfelder doppelt; `AccountMigrationBL` nutzt NamedQuery "MigrateWebAccountsFromOldCustomerStructure".
+Aussage:       Das System soll Kunden-, Liefer- und Ansprechpartnerdaten an einer maßgeblichen Stelle (Account-Stamm) führen; das Zielsystem überführt die Altbestände (CustomerArea, Supplier) und legt sie still.
+Ergebnis:      Ein Kundenstamm mit einer Konditionenquelle; keine Divergenz zwischen Supplier.Name und Account.Name/Frachtsätzen.
+Belege:
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs, DeliveryConditionI3D - Begründung: Altmodell mit Konditionsfeldern
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\Accounts\AccountCustomer.cs, ReceiptConditionDeliveryI3D - Begründung: Neumodell mit denselben Fachmerkmalen
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountMigrations\AccountMigrationBL.cs, MigrateWebAccountsFromOldCustomerStructure - Begründung: dokumentierter Migrationslauf Alt→Neu
+  - [PRIMÄR] src\backend\Centron.Entities\Entities\Businesspartner\Supplier.cs vs. src\backend\Centron.Entities\Entities\Accounts\AccountSupplier.cs - Begründung: doppelter Lieferantendatenbestand
+Prüfidee:   Zähl-Query: Module, die noch Customer/Address (alt) lesen, vs. Account/AccountAddress; Ziel: Differenz = 0.
+Tracelinks:    SwRS-027, SwRS-028, SwRS-031, SwRS-132
+Konsolidierung: Kandidat: Muster "zwei Datenhaltungen für denselben Fachgegenstand" wie beim Prompt-Beispiel Drucker-Stammblätter vs. Assets
+Übernahmewürdigkeit: Workaround - Parallelhaltung ist Migrations-Zustand, Ziel ist der eine Stamm
+Status:        belegt
+
+---
+
+ID:            StRS-006
+Titel:         Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Endkunde (Web-Account-Login)
+Vorbedingung:  Web-Account ist mit Account/Customer verknüpft
+Fakt:          `AccountAddressBL` erzwingt `filter.AccountI3Ds = { WebAccount.AccountI3D }`; `AccountSearchBL` filtert bei `IsWebAccountLogin` auf `WebAccount.CustomerI3D`; `ReceiptCartBL.SearchArticles` begrenzt auf `WebAccount.CustomerI3D` (Zeilen 228-244).
+Aussage:       Das System soll jede Adress-, Konto-, Beleg- und Artikelsuche im Kundenportal zwingend auf den Stammkunden des angemeldeten Web-Accounts einschränken.
+Ergebnis:      Kunden sehen im Self-Service nur eigene Daten; Mandantendaten bleiben abgeschottet.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountAddressBL.cs, Filterzwang (Zeilen 75-79) - Begründung: erzwungener Mandantenzwang
+  - [PRIMÄR] src\backend\Centron.BL\Accounts\AccountSearchBL.cs, IsWebAccountLogin-Filter (Zeilen 294-299) - Begründung: gleiche Regel zweite Stelle
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, Zeilen 228-244 - Begründung: Kundenisolierung im Shop
+Prüfidee:   Webservice-Aufruf mit Web-Account-Token; fremde Kunde-I3D im Filter muss ignoriert/abgewiesen werden.
+Tracelinks:    SyRS-016, SyRS-017, SyRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Mandantentrennung des Portals
+Status:        belegt
+
+---
+
+ID:            StRS-007
+Titel:         Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Administration, System
+Vorbedingung:  Employee existiert; Zugangsdaten werden unabhängig gepflegt
+Fakt:          `AppUserBL.GetAppUserObjectForEmployee(employeeId)`/`GetAppUserI3DForEmployee` mappen Mitarbeiter→Login; `SaveOrUpdateAppUser` führt separates Passwortargument; Web-Accounts sind dritte Identitätsart mit eigener Rechtequelle (`WebRights`).
+Aussage:       Das System soll Personalstammdaten und Zugangsdaten als getrennte Konzepte mit definierter Zuordnung führen, damit Passwort-/Lizenzverwaltung den Personalstamm nicht ändert.
+Ergebnis:      Sperrung/Änderung eines Zugangs ohne Eingriff in Personaldaten; drei Akteursidentitäten (Employee, AppUser, Web-Account) sauber unterscheidbar.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\EmployeeArea\AppUserBL.cs, GetAppUserObjectForEmployee - Begründung: explizite Mapping-Methoden belegen Zwei-Konzept-Design
+  - [SEKUNDÄR] src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs, Doku zu geteiltem I3D-Bereich von Employee/Web-Account - Begründung: Identitäten teilen sich Nummernkreise, daher Typ needed
+Prüfidee:   AppUser eines Employees sperren; Employee-Daten bleiben lesbar, Zugriffe des Logins scheitern.
+Tracelinks:    SwRS-029, SwRS-032, SwRS-052
+Konsolidierung: Kandidat: Identitätskonzepte Employee/AppUser/Web-Account im Zielsystem auf ein Identitätsmodell führen
+Übernahmewürdigkeit: übernehmen - saubere Rollen-/Identitätstrennung
+Status:        belegt
+
+---
+
+ID:            StRS-008
+Titel:         Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mitarbeiter, Disponent
+Vorbedingung:  Mitarbeiter ist aktiv (`IsActiveEmployeeCompact`-Prüfung)
+Fakt:          `EmployeeBL` bietet `SetDispatcher`, `IsActiveEmployeeCompact`, `UpdateEmployeeAvailability(employeeI3D, EmployeeAvailability)`.
+Aussage:       Das System soll je Mitarbeiter eine schaltbare Verfügbarkeit und eine Dispatcher-Eigenschaft führen und diese vor weiterleitungsrelevanten Aktionen (Ticketweitergabe, Zuteilung) prüfen.
+Ergebnis:      Tickets/Aufgaben erreichen nur verfügbare, rollengerecht eingestellte Mitarbeiter.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs, SetDispatcher/UpdateEmployeeAvailability/IsActiveEmployeeCompact (Zeilen 67-127) - Begründung: Steuerungsmethoden inkl. Aktivitätsprüfung
+Prüfidee:   Inaktiven Mitarbeiter als Dispatcher setzen → Fehlerresult; Zuweisung an Abwesenden verhindert.
+Tracelinks:    SyRS-002
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-009
+Titel:         Deterministische Länder-, Währungs- und Inlandsbasis
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:       _any user; Buchhaltung
+Vorbedingung:  Default-Mandant mit Land gepflegt; genau ein Defaultland markiert
+Fakt:          `CountryBL.GetInlandCountry` liefert `MandatorBL.GetDefaultMandator().Country` (offenes TODO zur Filialland-Prüfung); `GetDefaultCountry` filtert `f.Default`; `UpdateCurrencyRateByRateDictionary` importiert EZB-Kurse.
+Aussage:       Das System soll das für Preise/Steuern maßgebliche Inlandsland deterministisch aus dem Default-Mandanten ableiten und tagesaktuelle Wechselkurse je Währung bereitstellen.
+Ergebnis:      Belege, Steuern und Fremdwährungspreise rechnen auf einer eindeutigen Länderbasis.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, GetInlandCountry/GetDefaultCountry - Begründung: Implementierung inkl. TODO als bekannte Lücke
+  - [PRIMÄR] src\backend\Centron.BL\CountryArea\CountryBL.cs, UpdateCurrencyRateByRateDictionary (EZB-XML) - Begründung: Kursimport durchgesetzt
+Prüfidee:   Default-Mandant auf zweites Land setzen; Inlandslogik neuer Belege folgt dem neuen Land.
+Tracelinks:    SwRS-041, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen (TODO Filialland als Nachsteuerung)
+Status:        belegt
+
+---
+
+ID:            StRS-010
+Titel:         Filial- und Lagerstruktur je Mandant
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Administration, Logistik
+Vorbedingung:  Mandant mit Filialen angelegt
+Fakt:          `BranchBL.SaveAssignedSecondaryStocks` verwaltet je Filiale genau ein Default-Lager plus Sekundärlager atomar; `GetBranchesForSelection` stellt Pseudo-Einträge "Hauptsitz"/"Alle Filialen" bereit.
+Aussage:       Das System soll Mandanten, Filialen und Lager mit je genauem Default-Lager je Filiale abbilden und in allen Masken einheitlich auswahlbar machen.
+Ergebnis:      Deterministische Lager- und Filialzuordnung von Belegen, Beständen und Benutzern.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, SaveAssignedSecondaryStocks (Zeilen 72-154) - Begründung: Default-Lager-Rotation im Transaktionsblock
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\BranchBL.cs, GetBranchesForSelection/IsBranchEqual - Begründung: einheitliche Filialfilter-Semantik
+Prüfidee:   Zweites Default-Lager setzen → altes entfällt; Filialauswahl enthält genau einen "Alle Filialen"-Eintrag.
+Tracelinks:    SwRS-030, SwRS-031
+Konsolidierung: Kandidat: Organisationskonzepte Firma (Company) vs. Mandant vs. Filiale zusammenführen
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-011
+Titel:         Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar
+Ebene:         StRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Finanz-/Einkaufsabteilung
+Vorbedingung:  Masterdatenpflege geöffnet
+Fakt:          `AssetCondition` führt bis zu drei Skonto-Staffeln (Skonto1..3 OffDay/Percent) mit verwalteten Texten; `AssetConditionBL.GetAssetConditionTextPreview` rendert Platzhalter gegen eine Testrechnung und meldet Fehler ohne Rechnungsbestand.
+Aussage:       Das System soll Zahlungs-/Lieferkonditionen mit Skonto-Staffeln zentral pflegen, in Belege, Textbausteine und E-Rechnung übernehmen und die Auswirkung per Vorschau verifizierbar machen.
+Ergebnis:      Einheitliche Konditionen für Belege/Materialgruppen; Fälligkeit und Skonto sind aus einer Quelle abgeleitet.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs, GetAssetConditionTextPreview (Zeilen 34-55) - Begründung: Skonto-Feldsemantik und Fehlerpfad belegt
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE [dbo].[Zahkond] mit Skonto1/Skonto2, LaenPer1..3 - Begründung: Datenmodell der Skontostufen
+Prüfidee:   Zahlungsbedingung "2 % / 14 Tage, netto 30"; Rechnung speichern → Fälligkeit und Skontotext stimmen; E-Rechnung enthält SKONTO-Angaben.
+Tracelinks:    SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-012
+Titel:         SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Helpdesk-Bearbeiter, Kunde mit Servicevertrag
+Vorbedingung:  Ticket einem Servicevertrag zugeordnet
+Fakt:          `UpdateHelpdeskBL.UpdatePriority` verwirft abweichende Prioritäten ("Die Priorität wird durch den gewählten Vertrag vorgegeben."); `GetDueDateFromPriority` leitet das Fälligkeitsdatum ab; `HelpdeskPriority.IsSLA` und `Contract.SLAPriority` verknüpfen Vertrag und Ticket.
+Aussage:       Das System soll bei SLA-Verträgen die Ticketpriorität verbindlich aus dem Vertrag ableiten und daraus das Fälligkeitsdatum automatisch berechnen; manuelle Abweichungen sind unzulässig.
+Ergebnis:      Verträge werden eingehalten; Fälligkeit/Priorität springen automatisch bei Vertragswechsel; Beteiligte werden benachrichtigt.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs, UpdatePriority (Zeilen 281-326), SetContract (Zeilen 430-455) - Begründung: Durchsetzungsstellen der SLA-Kette
+  - [SEKUNDÄR] src\backend\Centron.Entities\Entities\CustomerArea\Support\HelpdeskPriority.cs, IsSLA - Begründung: SLA-Kennzeichen im Datenmodell
+Prüfidee:   SLA-Vertrag setzen, abweichende Priorität wählen → Fehler; Vertragswechsel → Priorität+DueDate springen.
+Tracelinks:    keine abgeleitete Anforderung - SLA-Kette abschließend in UpdateHelpdeskBL belegt
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrales Service-Vermarktungsmerkmal
+Status:        belegt
+
+---
+
+ID:            StRS-013
+Titel:         Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Interne Bearbeiter, Kunde (Web-Account)
+Vorbedingung:  Ticket existiert, Benutzer angemeldet
+Fakt:          `HelpdeskBL.GetHelpdeskRequest` prüft Vertriebsgebietsrechte (`EmployeeToSalesAreaBL`) und blendet `IsOnlyInternalVisible`-Tickets für Web-Logins mit einheitlichem Fehler "Ticket nicht gefunden!" aus.
+Aussage:       Das System soll Ticketzugriff nach internen Rechten (Vertriebsgebiet) und Kanälen (Kunde/sichtbarkeit) steuern, ohne Kunden die Existenz interner Tickets zu verraten, und jede Statusänderung historisieren.
+Ergebnis:      Berechtigte sehen Tickets, Unberechtigte erhalten einen einheitlichen Nicht-gefunden-Fehler; Statushistorie ist vollständig.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, GetHelpdeskRequest (Zeilen 113-146) - Begründung: Rechte-/Kanalfilter durchgesetzt
+  - [PRIMÄR] src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, SetHelpdeskAction (Zeilen 558-609) - Begründung: Statushistorie im Speicherpfad
+Prüfidee:   Web-Account öffnet internes Ticket → CouldNotFindData; fremdes Vertriebsgebiet → RightCheckFailed; Statuswechsel erzeugt Historieneintrag.
+Tracelinks:    SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-014
+Titel:         Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        alle Fachbereiche
+Vorbedingung:  Quellvorgang (Beleg, Helpdesk, Urlaub, Kommissionierung ...) erzeugt Wiedervorlage
+Fakt:          `ToDoBL.FillObjectKindsListe` registriert über 30 `ToDoObjectKind`-Einträge (Name, Area, AssetKind); `TaskManagementTaskBL.SaveOrUpdateTask` erzwingt valide Aktion/Wiederkehr und Lizenz.
+Aussage:       Das System soll Wiedervorlagen aller Fachbereiche in einer strukturierten ToDo-Liste mit Typ/Bereich/Objektbezug führen und wiederkehrende Aufgaben nur bei valider, lizenzierter Aktion anlegen.
+Ergebnis:      Ein Einstiegspunkt zeigt bereichsübergreifende Aufgaben; keine defekten oder unlizenzierten Automationen.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\ToDoArea\ToDoBL.cs, FillObjectKindsListe (Zeilen 69-118) - Begründung: zentraler Typkatalog
+  - [PRIMÄR] src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs, SaveOrUpdateTask (Zeilen 40-97) - Begründung: Validierungs-/Lizenzprüfung
+Prüfidee:   ToDo je registriertem Typ anlegen → in Liste mit korrektem Bereichstext; Aufgabe mit ungültiger Wiederkehr → Fehlerresult.
+Tracelinks:    SwRS-074, SwRS-077, SwRS-079
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status:        belegt
+
+---
+
+ID:            StRS-015
+Titel:         Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann)
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Wartbarkeit / Sicherheitsfunktionalität (ISO 25010)
+Akteur:        Prüfer, Fachanwender, System
+Vorbedingung:  Änderung an getracktem Objekt durch angemeldeten Benutzer
+Fakt:          `ChangeTrackingEventListener` (NHibernate IPreUpdateEventListener) schreibt je geänderter Property Alt-/Neuwert, Benutzer und Datum in `ChangeLog`; Repositories belegen CreatedBy/CreatedDate/CreatedVersion automatisch; Soft-Delete plus Log Tabellen (Geräte, Umlagerungen, Belegprotokolle) ergänzen.
+Aussage:       Das System soll Änderungen an als überwachungswürdig deklarierten Feldern automatisch mit Alt-/Neuwert, Benutzer und Zeitpunkt protokollieren und Herkunftsfelder (Ersteller/-zeitpunkt/-version) beim Anlegen zwangsläufig setzen.
+Ergebnis:      Auditgrundlage ohne Fachcode; Löschung erfolgt,revidierbar per Soft-Delete mit Log.
+Belege:
+  - [PRIMÄR] src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs, OnPreUpdate/CreateChangeLog (Zeilen 52-142) - Begründung: zentrale, automatische Protokollierung
+  - [PRIMÄR] src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs, CreateNewAccount (Zeilen 39-52) - Begründung: Auditfelder im Repository-Muster
+Prüfidee:   Getrackte Property ändern → genau ein ChangeLog-Satz mit korrektem Benutzer; Neuanlage setzt CreatedVersion = Assemblyversion.
+Tracelinks:    SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Audit-Basis; Lücken (kein Insert/Delete-Tracking) im Zielsystem schließen
+Status:        belegt
+
+---
+
+ID:            StRS-016
+Titel:         Lückenlose, prüfsichere Nummernvergabe (GoBD)
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Funktionale Sicherheit (ISO 25010)
+Akteur:        System bei jeder Beleg-/Stammdatenanlage
+Vorbedingung:  Nummernkreise je Mandant/Filiale gepflegt
+Fakt:          `NumberGroupBL.GetNextNumber` vergibt und fortschreibende Nummern je Mandant/Filiale; `MandatoryBL` priorisiert filialbezogene Kreise vor dem Standardmandanten und überspringt verbrauchte (`Aktuell<=0`); Vergabe ohne manuelle Eingabe in allen Belegarten.
+Aussage:       Das System soll alle Nummern (Belege, Adressen, Ticketprojekte) fortlaufend, lückenlos und mandanten-/filialbezogen aus Nummernkreisen vergeben, ohne dass Benutzer Nummern setzen können.
+Ergebnis:      Keine Doppelvergabe; Nummerierung ist revisionssicher und je Mandant/Filiale getrennt.
+Belege:
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs, GetNextNumber/CreateNumberGroups - Begründung: zentrale Vergabestelle
+  - [PRIMÄR] src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs, GetNumberGroup (ORDER BY Mandantenpriorität) - Begründung: Delegation Mandant→Filiale→Standard
+Prüfidee:   Paralleles Neuanlegen → keine Duplikate, Zähler monoton; Filiale mit eigenem Kreis wird vor Standardmandant gezogen.
+Tracelinks:    SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120
+Konsolidierung: Kandidat: Nummernkreislogik (Company) und Nummernkreis-Delegation (Mandatory) zusammenführen
+Übernahmewürdigkeit: übernehmen - GoBD-Kernanforderung
+Status:        belegt
@@ -0,0 +1,224 @@
+# Traceability-Matrix
+
+Rückwärts-/Vorwärtsverfolgung über alle 199 Anforderungen (16 StRS, 49 SyRS, 134 SwRS).
+„Verfolgung" = Inhalt des Feldes Tracelinks im jeweiligen Anforderungsblock; „Hauptartefakt" = erster PRIMÄR-Beleg (sonst SEKUNDÄR/KONTEXT). Alle Pfade relativ zum Arbeitsverzeichnis.
+
+## StRS-Ebene
+
+| StRS-ID | Titel | Verfolgung (abgeleitete Anforderungen) | Hauptartefakt |
+|---|---|---|---|
+| StRS-001 | Ein gemeinsames ERP-System für alle Fachprozesse | SyRS-024, SyRS-025, SyRS-026, SyRS-027, SyRS-028 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| StRS-002 | Endkunden wickeln Bestellung und Service selbstständig im Kundenportal ab | SyRS-016, SyRS-017, SyRS-018, SyRS-019, SyRS-020, SyRS-021 | README.md (SEKUNDÄR); ReceiptCartBL.cs (PRIMÄR) |
+| StRS-003 | Lückenloser, nachvollziehbarer Belegfluss vom Ursprungsbeleg bis zum Mahnlauf | SyRS-012, SyRS-013, SyRS-014, SyRS-039, SyRS-040, SyRS-041 | src\backend\Centron.BL\Sales\Receipts\ReceiptProgressionBL.cs |
+| StRS-004 | Wer darf was – selbstverwaltetes Rechte- und Lizenzmodell mit Selbstschutz | SyRS-001, SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-006, SyRS-007, SyRS-008, SyRS-009 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
+| StRS-005 | Ein maßgeblicher Adress-/Kundenstamm statt paralleler Datenhaltungen | SwRS-027, SwRS-028, SwRS-031, SwRS-132 | src\backend\Centron.Entities\Entities\CustomerArea\Customer.cs |
+| StRS-006 | Web-Accounts sehen ausschließlich Daten ihres eigenen Kunden | SyRS-016, SyRS-017, SyRS-018 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
+| StRS-007 | Personalstamm (Employee) und Zugang (AppUser/Web-Account) sind getrennte Identitäten | SwRS-029, SwRS-032, SwRS-052 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
+| StRS-008 | Verfügbarkeit und Rolle des Mitarbeiters steuern die Arbeitsverteilung | SyRS-002 | src\backend\Centron.BL\EmployeeArea\EmployeeBL.cs |
+| StRS-009 | Deterministische Länder-, Währungs- und Inlandsbasis | SwRS-041, SwRS-042 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| StRS-010 | Filial- und Lagerstruktur je Mandant | SwRS-030, SwRS-031 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
+| StRS-011 | Zahlungs- und Lieferkonditionen zentral pflegen, Skonto aussteuerbar | SyRS-013, SyRS-015, SyRS-040, SyRS-041, SwRS-012, SwRS-013, SwRS-014, SwRS-034 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
+| StRS-012 | SLA-Zusagen aus Serviceverträgen verbindlich durchsetzen | keine abgeleitete Anforderung (SLA-Kette abschließend in UpdateHelpdeskBL belegt) | src\backend\Centron.BL\Sales\Support\UpdateHelpdeskBL.cs |
+| StRS-013 | Nachvollziehbare Ticketbearbeitung mit beschränkter Sichtbarkeit | SyRS-037, SyRS-038, SyRS-043, SyRS-048, SwRS-043, SwRS-045, SwRS-047, SwRS-049, SwRS-050, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| StRS-014 | Wiedervorlagen und Aufgaben über alle Fachbereiche bündeln | SwRS-074, SwRS-077, SwRS-079 | src\backend\Centron.BL\ToDoArea\ToDoBL.cs |
+| StRS-015 | Nachvollziehbarkeit von Datenänderungen (Wer, Was, Wann) | SyRS-004, SyRS-033, SwRS-020, SwRS-023, SwRS-047, SwRS-082, SwRS-086, SwRS-093, SwRS-094, SwRS-110 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| StRS-016 | Lückenlose, prüfsichere Nummernvergabe (GoBD) | SyRS-010, SyRS-039, SyRS-044, SwRS-026, SwRS-099, SwRS-120 | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs |
+
+## SyRS-Ebene
+
+| SyRS-ID | Titel | Eltern (StRS) | Kinder | Hauptartefakt |
+|---|---|---|---|---|
+| SyRS-001 | API-Aufrufe nur mit deklariertem Benutzerrecht | StRS-004 | SwRS-001, SwRS-002 | src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs |
+| SyRS-002 | Mehrstufiger Anmeldeprozess mit Zweitfaktor (RADIUS oder E-Mail-Link) | StRS-004, StRS-008 | SwRS-003, SwRS-004 | src\backend\Centron.BL\Administration\Logins\TwoFactor\TwoFactorAuthBL.cs |
+| SyRS-003 | Lizenz- und Hosted-Schranke für interne Funktionen und Modulzugriffe | StRS-004 | SwRS-006, SwRS-024 | src\webservice\Centron.Controllers\Authorization\CentronHostedAuthorization.cs |
+| SyRS-004 | DSGVO-Löschung personenbezogener Daten nur für Berechtigte, mit Protokoll | StRS-004, StRS-015 | SwRS-009 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
+| SyRS-005 | Ticketvergabe nach Rechts- und Lizenzprüfung, zeitlich befristet | StRS-004 | SwRS-003 | src\backend\Centron.BL\Administration\Logins\Auth\Authenticator.cs |
+| SyRS-006 | Every REST request must pass ticket/token authentication | StRS-004 | SwRS-002, SwRS-053, SwRS-054 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SyRS-007 | Nexus-Host authentifiziert per Cookie/Ticket oder OIDC und stellt Sitzung aus | StRS-004 | SwRS-044, SwRS-051 | src\nexus\CentronNexus.Host\Program.cs |
+| SyRS-008 | Umschaltung der Systemauthentifizierung auf OpenID Connect (Entra ID) | StRS-004 | – | src\nexus\CentronNexus\Configuration\OpenIdConnectConfigurationService.cs |
+| SyRS-009 | Outlook-AddIn-Einbettung mit iframe-fähiger Cookie-Policy | StRS-004 | – | src\nexus\CentronNexus.Host\Program.cs |
+| SyRS-010 | Fortlaufende Rechnungsnummern je Nummernkreis | StRS-016, StRS-003 | SyRS-044 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-011 | Rechnungsexport-Kennzeichnung steuert Änderung und Storno | StRS-003 | SwRS-011 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-012 | Mahnlauf: stufenweise Eskalation überfälliger Rechnungen, transaktional | StRS-003 | – | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs |
+| SyRS-013 | Zahlungsstatus nur über zentralen, protokollierten Buchungspunkt | StRS-003, StRS-011 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-014 | Belegweiterverarbeitung nur entlang definierter Regeln je Belegart | StRS-003 | SwRS-010 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
+| SyRS-015 | Kundenindividuelle Preise im Web-Shop mit nachvollziehbarer Rabattanzeige | StRS-002, StRS-011 | SwRS-013, SwRS-035 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-016 | Kundenportal nur für Web-Account-Login über den Kundenportal-Port | StRS-002, StRS-006 | SwRS-007, SwRS-036 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-017 | Shop-Sortiment auf aktive Sonderpreise des Kunden beschränken | StRS-002, StRS-006 | – | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-018 | Warenkorb-Bestellung nur mit Web-Recht und Prüfstufe | StRS-002, StRS-006 | SwRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SyRS-019 | Token-basierte Angebotsansicht ohne Login | StRS-002 | – | src\backend\Centron.BL\WebServices\Sales\Receipts\ReceiptWebServiceBL.cs |
+| SyRS-020 | Signatur- und Akzeptanzstrecke für freigegebene Dokumente | StRS-002 | – | src\nexus\CentronNexus\DocumentSigning\DocumentSigningPage.razor |
+| SyRS-021 | PDF-Auslieferung über gemeinsamen Office-Cache-Endpunkt | StRS-002 | – | src\nexus\CentronNexus\Office\Controllers\PdfController.cs |
+| SyRS-022 | Hintergrunddienste zentral über Konfigurationsflag steuerbar | StRS-001 | SwRS-084 | src\webservice\Centron.Host\CentronHost.cs |
+| SyRS-023 | Versionsgesteuerte, idempotente Datenbankmigration mit Protokoll | StRS-001 | – | src\backend\Centron.BL\Administration\Scripts\ScriptEngineBL.cs |
+| SyRS-024 | REST-API-Versionierung und einheitliche Fehlerbehandlung | StRS-001 | – | src\webservice\Centron.Host\AspNetCore\RegisterCentronApiVersioning.cs |
+| SyRS-025 | Standardisierter komprimierter REST-Kanal „RESTC" | StRS-001 | – | src\webservice\Centron.WebServices.Core\Connections\CentronWebService.cs |
+| SyRS-026 | Plattformabhängiger Webserver-Betrieb (HttpSys/Kestrel) | StRS-001 | – | src\webservice\Centron.Host\CentronHost.cs |
+| SyRS-027 | Betrieb als Windows-Dienst mit Fehlerkapselung | StRS-001 | – | src\webservice\Centron.Host.WindowsService\CentronService.cs |
+| SyRS-028 | Service-spezifische BL-Schicht (*WebServiceBL) | StRS-001 | – | src\backend\Centron.BL\WebServices\Administration\Logins\TicketWebServiceBL.cs |
+| SyRS-029 | Zentrales Konfigurationswertesystem (AppSettings/ApplicationSettings) | StRS-001 | SwRS-096 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
+| SyRS-030 | Zentrale Konfigurations-DB mit verschlüsseltem Hotline-Masterkey | StRS-004 | – | src\backend\Centron.BL\Administration\CentronConfigDb\CentronConfigurationDbBL.cs |
+| SyRS-031 | WebService-Konfigurationsdatei mit verschlüsselten Geheimnissen | StRS-004 | – | src\backend\Centron.BL\Administration\WebServiceConfiguration\WebServiceConfigSerializer.cs |
+| SyRS-032 | Client-Verbindungsprofile mit AES-verschlüsselten Passwörtern | StRS-004 | – | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
+| SyRS-033 | Attributsgesteuerte Feldänderungs-Historie im Persistenzlayer | StRS-015 | – | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| SyRS-034 | Einheitliches ORM-Mapping auf Legacy-Schema (PK I3D) | StRS-001 | – | src\backend\Centron.DAO\Mappings\BaseMaps.cs |
+| SyRS-035 | Zentrale SQL-Abfragen in einem NamedQuery-Pool | StRS-001 | – | src\backend\Centron.DAO\NamedQueries\NamedQueryManager.cs |
+| SyRS-036 | Rohe SQL-Zugriffe transaktionsgebunden über die ORM-Session | StRS-001 | – | src\backend\Centron.DAO\AdoNETDataAccess\RawSqlAccessDAO.cs |
+| SyRS-037 | Serverseitiger Ticket-Cache mit Hintergrund-Synchronisation | StRS-013, StRS-001 | SwRS-048 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
+| SyRS-038 | Push-Zustellung von Benachrichtigungen per SignalR | StRS-013 | SwRS-049, SwRS-050 | src\nexus\CentronNexus\Shared\Services\SignalRNotificationsService.cs |
+| SyRS-039 | Buchhaltungsexport in austauschbare Zielsystemformate | StRS-003, StRS-016 | SyRS-011, SwRS-067, SwRS-133 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
+| SyRS-040 | Normkonforme E-Rechnungsformate (ZUGFeRD/XRechnung, eb:interface) | StRS-003, StRS-011 | – | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs |
+| SyRS-041 | Zahlungsziel- und Skontoermittlung aus der Zahlungsbedingung | StRS-003, StRS-011 | SwRS-012 | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs |
+| SyRS-042 | Statistik-Caches mit Selbstreparatur und Sofortaktualisierung | StRS-001 | SwRS-104 | src\backend\Centron.BL\Services\CachedTableBL.cs |
+| SyRS-043 | Helpdesk-Statusmaschine als konfigurierbare Übergänge | StRS-013 | SwRS-043, SwRS-045, SwRS-047, SwRS-127 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SyRS-044 | Nummernkreis-Delegation Mandant→Filiale→Standard | StRS-016 | SyRS-010, SwRS-026, SwRS-099 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
+| SyRS-045 | Lieferanten-EDI: Bestellungen hinaus, Antworten herein | StRS-001, StRS-003 | SwRS-016, SwRS-065 | src\backend\Centron.BL\EDI\EDIDispatcherBL.cs |
+| SyRS-046 | Fremddaten-Produktanreicherung über Distributor-/Poolschnittstellen | StRS-001 | – | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
+| SyRS-047 | Paketversand über externe Carrier-Plattformen | StRS-001 | – | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
+| SyRS-048 | Helpdesk-Gegenstelle für externes Ticketsystem (River Suite/Riverbird) | StRS-013 | – | src\backend\Centron.BL\RiverDivo\RiverDivoBL.cs |
+| SyRS-049 | Mandanten-Installationsstatus und Installer-Download | StRS-001 | – | src\backend\Centron.BL\Administration\Portal\PortalWebServiceAccessBL.cs |
+
+## SwRS-Ebene
+
+| SwRS-ID | Titel | Eltern | Hauptartefakt |
+|---|---|---|---|
+| SwRS-001 | Zentrale, gecachte Rechtsprüfung mit Fail-closed-Semantik | SyRS-001, StRS-004 | src\backend\Centron.BL\Administration\Rights\AppRightsBL.cs |
+| SwRS-002 | Sichere Behandlung personengebundener API-Access-Tokens | SyRS-001, SyRS-006, StRS-004 | src\backend\Centron.BL\Administration\AccessTokens\AccessTokenBL.cs |
+| SwRS-003 | Passwortanmeldung nur für aktive, nicht gesperrte Konten | SyRS-002, SyRS-005, StRS-004 | src\backend\Centron.BL\Administration\Logins\Auth\BasicAuthenticator.cs |
+| SwRS-004 | Prüfung des personengebundenen Zwei-Faktor-Schlüssels | SyRS-002, StRS-004 | src\backend\Centron.BL\TwoFactorAuthenticator\TwoFactorAuthenticationBL.cs |
+| SwRS-005 | Alt-Passwortverwaltung (Keywords) – Migrationsbedarf | SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManagementArea\PasswordManagementKeywordBL.cs (SEKUNDÄR) |
+| SwRS-006 | Elektronische PDF-Signatur mit geschützter Zertifikatskonfiguration | SyRS-003, StRS-003 | src\backend\Centron.BL\Security\PdfSigningBL.cs |
+| SwRS-007 | Ticketansichten im Kundenportal nach Web-Rechten differenzieren | SyRS-016, StRS-002 | src\nexus\CentronNexus\WebCart\CustomerTicketDetailsPage.razor (SEKUNDÄR) |
+| SwRS-008 | Passwort-Manager: Export nur mit Recht, Lizenz und Masterkey | SyRS-003, SyRS-030, StRS-004 | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs |
+| SwRS-009 | Anonymisierung von Ansprechpartnern mit Löschprotokoll | SyRS-004, StRS-004 | src\backend\Centron.BL\Administration\DataSecurity\DataSecurityBL.cs |
+| SwRS-010 | Weiterverarbeitungsregeln und Herkunftsbindung je Belegart | SyRS-014, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs |
+| SwRS-011 | Rechnungsstorno: Guard-Kette und historisierende Neufassung | SyRS-011, StRS-003 | src\backend\Centron.BL\Sales\Receipts\Invoices\ReceiptInvoiceBL.cs |
+| SwRS-012 | Skontoberechnung und -text je Zahlungsbedingung | SyRS-041, StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionTextReplacementBL.cs |
+| SwRS-013 | Preishierarchie der Belegposition (Vertrag > Sonderpreis > Staffelpreis) | StRS-011, SyRS-015 | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs |
+| SwRS-014 | Zweistufige Preisrundung mit artikelbezogener Genauigkeit | StRS-011, SyRS-040 | src\backend\Centron.BL\Sales\Receipts\ReceiptPriceHelperBL.cs |
+| SwRS-015 | Distributoren automatisch bei Import anlegen | StRS-001 | src\backend\Centron.BL\Buying\External\DistributorBL.cs |
+| SwRS-016 | Bestellvorschlagsliste aus öffentlichem Bedarf und Mindestbestand | StRS-001, SyRS-045 | src\backend\Centron.BL\Purchasing\OrderSuggestionList\OrderSuggestionListBL.cs |
+| SwRS-017 | Bereichsübergreifender Export von Lieferantenrechnungen/Timerleistungen | StRS-003 | src\backend\Centron.BL\Purchasing\SupplierOrderPerBranchBL.cs |
+| SwRS-018 | Rechteprüfung in Kommissionierung und Barcodeerzeugung | SyRS-001, StRS-004 | src\backend\Centron.BL\Warehousing\Commissions\OrderCommissionBL.cs |
+| SwRS-019 | Fortschreibung des Artikel-EK aus Wareneingangspreisen | StRS-003, StRS-011 | src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs |
+| SwRS-020 | Validierte Protokollierung von Lagerumlagerungen | StRS-015 | src\backend\Centron.BL\Logistics\Warehousing\StockBL.cs |
+| SwRS-021 | Kunden-Produktmatrix mit Bewertungshistorie | StRS-001 | src\backend\Centron.BL\ProductMatrix\ProductMatrixBL.cs |
+| SwRS-022 | Fertigungsaufträge nach Maschine/Maschinenart filterbar | StRS-001 | src\backend\Centron.BL\Production\ProductionOrderBL.cs |
+| SwRS-023 | Geräteverwaltung mit Soft-Delete und Protokoll | StRS-015 | src\backend\Centron.BL\Devices\AccountDeviceBL.cs |
+| SwRS-024 | Produktionsmanagement durchgehend lizenzgeprüft | SyRS-003, StRS-004 | src\backend\Centron.BL\Production\ProductionBL.cs |
+| SwRS-025 | Handelspool-Artikelimport aus Distributor-XML | SyRS-046, StRS-001 | src\backend\Centron.BL\TradePool\Core\TradePoolXmlLogic.cs |
+| SwRS-026 | Automatische Nummernvergabe für Account, Kunde und Lieferant | StRS-016, SyRS-044 | src\backend\Centron.BL\Accounts\AccountBL.cs |
+| SwRS-027 | Genau eine Standardadresse je Account | StRS-005 | src\backend\Centron.BL\Accounts\AccountAddressBL.cs |
+| SwRS-028 | Branchenzuweisungen atomar ersetzen | StRS-005 | src\backend\Centron.BL\CustomerArea\BusinessLineBL.cs |
+| SwRS-029 | Explizite Zuordnung Employee → AppUser | StRS-007 | src\backend\Centron.BL\EmployeeArea\AppUserBL.cs |
+| SwRS-030 | Filialauswahl mit Pseudo-Einträgen Hauptsitz/Alle Filialen | StRS-010 | src\backend\Centron.BL\Administration\Company\BranchBL.cs |
+| SwRS-031 | Firmenübersicht als reines Lese-API | StRS-005, StRS-010 | src\backend\Centron.BL\Administration\CompanyInformations\CompanyBL.cs |
+| SwRS-032 | Abteilungen benutzerbezogen laden und pflegen (Parallelimplementierung) | StRS-007 | src\backend\Centron.BL\Administration\Employees\EmployeeDepartmentBL.cs |
+| SwRS-033 | Persistente persönliche Mitarbeitereinstellungen | StRS-001 | src\backend\Centron.BL\Administration\Employees\EmployeeSettingBL.cs |
+| SwRS-034 | Konditionstextvorschau gegen echte Testrechnung | StRS-011 | src\backend\Centron.BL\Administration\Masterdata\AssetConditionBL.cs |
+| SwRS-035 | Preis- und Rabatttransparenz im Shop | SyRS-015, StRS-002 | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs |
+| SwRS-036 | SelfCare-Formular erzeugt Helpdesk-Ticket | SyRS-016, StRS-002 | src\backend\Centron.BL\SelfCare\SelfCareBL.cs |
+| SwRS-037 | Weblink-Aktion legt CRM-Aktivität für den Betreuer an | StRS-001 | src\backend\Centron.BL\WebLinks\WebLinkActionAccountActivityHandler.cs |
+| SwRS-038 | Versionsauskunft des Webservices | StRS-001 | src\backend\Centron.BL\WebVersion\VersionBL.cs |
+| SwRS-039 | Web-Einstellungen strikt nach Login-Art getrennt | StRS-006, StRS-001 | src\backend\Centron.BL\WebSuite\Administration\Settings\WebSettingBL.cs |
+| SwRS-040 | Warenkorb-Prüfstufe und Kundenadmin-Oberfläche | SyRS-018, StRS-002 | src\nexus\CentronNexus\WebCart\Helpers\UserViewModel.cs (SEKUNDÄR) |
+| SwRS-041 | Täglicher Devisenkursimport aus dem EZB-Feed | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| SwRS-042 | Inlandsland aus dem Default-Mandanten ableiten | StRS-009 | src\backend\Centron.BL\CountryArea\CountryBL.cs |
+| SwRS-043 | Ticket-Statuswechsel per Drag-and-Drop im Kanban | SyRS-043, StRS-013 | src\nexus\CentronNexus\ServiceBoard\CachedTicketList\Components\KanbanBucket.razor |
+| SwRS-044 | ServiceBoard-Seiten durch Login-, Lizenz- und Portschutz | SyRS-007, SyRS-003, StRS-013 | src\nexus\CentronNexus\ServiceBoard\_Imports.razor |
+| SwRS-045 | Automatische Status-Defaults bei Anlage und Übernahme | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-046 | Fertigungsübersicht mit Arbeitsplatz- und Mitarbeiterauswahl | StRS-001 | src\nexus\CentronNexus\ProductionOrderManagement\Pages\ProductionOrderOverView.razor |
+| SwRS-047 | Lückenlose Ticketstatus-Historie im Speicherpfad | SyRS-043, StRS-013, StRS-015 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-048 | Prozessweiter Ticketcache im Nexus (Singleton + HostedService) | SyRS-037, StRS-013 | src\nexus\CentronNexus\Shared\Services\TicketCacheService.cs |
+| SwRS-049 | NexusNotifications je Empfänger verwalten (Raw-SQL) | SyRS-038, StRS-013 | src\backend\Centron.BL\NexusNotifications\NexusNotificationsBL.cs |
+| SwRS-050 | NotificationHub filtert pro Benutzer und unterscheidet Schedule-Typen | SyRS-038, StRS-013 | src\nexus\CentronNexus\Shared\Services\NotificationHub.cs |
+| SwRS-051 | Nur lokale Redirect-Ziele bei An-/Abmeldung (Open-Redirect-Schutz) | SyRS-007, StRS-004 | src\nexus\CentronNexus\Shared\Auth\AuthController.cs |
+| SwRS-052 | Ticket-Ansichten mit Besitzer- und Namensregeln | StRS-013, StRS-007 | src\backend\Centron.BL\NexusTicketViews\NexusTicketViewBL.cs |
+| SwRS-053 | Ticketauthentifizierungs-Handler als Durchsetzungsstelle | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SwRS-054 | Client-Kontext (IP, API-Methode) in der Access-Token-Validierung | SyRS-006, StRS-004 | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| SwRS-055 | TOTP-Zwei-Faktor-Bibliothek im Plattformkern | StRS-004 | src\shared\Centron.Core\TotpAuth\Totp.cs |
+| SwRS-056 | Schnittstellenmodul als Contract-First-Schicht | StRS-001 | src\backend\Centron.Interfaces (Ordnerstruktur) |
+| SwRS-057 | Gemeinsame Querschnittsbibliothek (Logging, Settings, Netzwerk, Codierung) | StRS-001 | src\backend\Centron.Common\Network\IpAddressHelper.cs |
+| SwRS-058 | eb:interface-4.3-E-Rechnung für Österreich | SyRS-040, StRS-003 | src\apis\Centron.Api.EbInterface\EbInterfaceLogic.cs |
+| SwRS-059 | GLS-Sendungsupload mit Vorabvalidierung | SyRS-047, StRS-001 | src\apis\Centron.Api.Gls\CentronGlsLogic.cs |
+| SwRS-060 | Sendungsanlage und Carrier-Abruf über Shipcloud | SyRS-047, StRS-001 | src\apis\Centron.Api.Shipcloud\CentronShipcloudLogic.cs |
+| SwRS-061 | Produktdaten per SOAP-Session vom Cop-System | SyRS-046, StRS-001 | src\apis\Centron.APIs.CopDataAccess\CopApi.cs |
+| SwRS-062 | EGIS-Artikelsuche mit Preis und Verfügbarkeit | SyRS-046, StRS-001 | src\apis\Centron.APIs.EgisDataAccess\EgisApi.cs |
+| SwRS-063 | PSD2-Bankdatenabruf über finapi | StRS-003, StRS-011 | src\apis\Centron.APIs.FinAPI\FinApiClient.cs |
+| SwRS-064 | Icecat-Produktinhalte (Text/Bild/Specs) je EAN | SyRS-046, StRS-001 | src\apis\Centron.APIs.IcecatDataAccess\IcecatApi.cs |
+| SwRS-065 | ITscope-Produkte, Angebote und Deals inkl. Archivierung | SyRS-046, SyRS-045 | src\apis\Centron.APIs.ITscopeDataAccess\ITscopeApi.cs |
+| SwRS-066 | docuFORM-Gerätezähler über OAuth2-PKCE | StRS-001, StRS-003 | Centron.Api.docuFORM\DocuFormRestApiClient.cs |
+| SwRS-067 | Eindeutige Standard-Exportkonfiguration je Mandant | SyRS-039, StRS-003 | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs |
+| SwRS-068 | E-Mail-Versand über austauschbare Protokollclients, Secrets verschlüsselt | StRS-001 | src\backend\Centron.BL\Mail\Factory\CentronMailFactory.cs |
+| SwRS-069 | Mailing als vollständiges Aggregat laden | StRS-001 | src\backend\Centron.BL\Mailings\MailingDataBL.cs |
+| SwRS-070 | MailScanner-Profile nur mit VMA-Recht, Passwörter verschlüsselt | SyRS-001, SyRS-030, StRS-004 | src\backend\Centron.BL\MailScanner\MailScannerBL.cs |
+| SwRS-071 | Chat-Nachrichten: Mitgliederzugriff, Autorschaft, Löschschutz | StRS-001 | src\backend\Centron.BL\Chats\ChatBL.cs |
+| SwRS-072 | Kundensuche im Outlook-AddIn über Gerätenummer | SyRS-035, StRS-001 | src\backend\Centron.BL\Outlook\OutlookAssetKindSearchBL.cs |
+| SwRS-073 | CTI-Anruferidentifikation über mehrstufige Rufnummernsuche | StRS-001 | src\backend\Centron.BL\Tapi\PhoneCallBL.cs |
+| SwRS-074 | Empfängerlisten je Objekt deckungsgleich halten, Meldungen auto-cleanupen | StRS-014 | src\backend\Centron.BL\Notifications\UserNotificationBL.cs |
+| SwRS-075 | Interne Social-Media-Kommentare/Likes über gespeicherte Prozeduren | StRS-001 | src\backend\Centron.BL\SocialMedia\SocialMediaBL.cs |
+| SwRS-076 | DocuBoard-Partner als konsistentes Aggregat speichern | StRS-001 | src\backend\Centron.BL\DocuBoard\AssetManagementPartnerBL.cs |
+| SwRS-077 | Videozuweisungen rechtsgeprüft mit ToDo-Kopplung | StRS-014, StRS-004 | src\backend\Centron.BL\VideoPortal\VideoPortalAssignmentBL.cs |
+| SwRS-078 | Terminanfrage-Antwort gegen Exchange-Kalender verarbeiten | StRS-001 | src\backend\Centron.BL\AppointmentRequests\AppointmentRequestBL.cs |
+| SwRS-079 | Wiederkehrende Aufgaben nur mit valider Aktion und Lizenz | StRS-014 | src\backend\Centron.BL\TaskManager\TaskManagementTaskBL.cs |
+| SwRS-080 | Kalenderdarstellung und Outlook-Synchronisation konfigurieren | StRS-001 | src\backend\Centron.BL\Calendar\CalendarBL.cs |
+| SwRS-081 | Tagesplanungs-Batches mit gemeinsamer Kennung | StRS-001 | src\backend\Centron.BL\MyDay\MyDayBL.cs |
+| SwRS-082 | Erwartete Ereignisse je Kunde mit Löschkaskade | StRS-015, StRS-001 | src\backend\Centron.BL\ExpectedEvents\ExpectedEventsBL.cs |
+| SwRS-083 | Persönliche Dashboardcontainer je Benutzer | StRS-001 | src\backend\Centron.BL\MyCentron\Dashboard\DashboardContainerBL.cs |
+| SwRS-084 | Hintergrunddienste namentlich erfassen und zentral aktivieren | SyRS-022, StRS-001 | src\backend\Centron.BL\Administration\BackgroundServices\BackgroundServiceBL.cs |
+| SwRS-085 | SQL-Server-Betriebsdiagnostik für Administratoren | StRS-001 | src\backend\Centron.BL\Administration\SQLManagement\SQLManagementBL.cs |
+| SwRS-086 | Automatische, referenzierte Objektverzeichnisse im Dokumentenmanagement | StRS-001, StRS-015 | src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\DirectoryReferenceProviderBase.cs |
+| SwRS-087 | Theme-Verwaltung mit unantastbarem Standard-Theme | StRS-001 | src\backend\Centron.BL\Administration\Themes\ThemeBL.cs |
+| SwRS-088 | Strukturierter Netzwerk-/SQL-Diagnosebericht | StRS-001 | src\backend\Centron.BL\Administration\NetworkDiagnostics\NetworkDiagnosticsBL.cs |
+| SwRS-089 | Profilaufzeichnungen aufbewahrungsgesteuert aggregieren | StRS-001 | src\backend\Centron.BL\Administration\Profiling\ProfilerBL.cs |
+| SwRS-090 | Telefonie-Einstellungen in drei Ebenen | StRS-001 | src\backend\Centron.BL\Administration\PhoneSettings\PhoneSettingsBL.cs |
+| SwRS-091 | Benutzerdefinierte Modul-Eigenschaften ohne Schemaänderung | StRS-001 | src\backend\Centron.BL\Administration\Customization\ModuleCustomPropertyBL.cs |
+| SwRS-092 | Custom-Tabellen mit Platzhalterbefüllung aus dem Fachobjekt | StRS-001 | src\backend\Centron.BL\Customizations\CustomTables\CustomTableBL.cs |
+| SwRS-093 | ChangeLog-Schreibregeln des ChangeTracking-Listeners | SyRS-033, StRS-015 | src\backend\Centron.DAO\ChangeTracking\ChangeTrackingEventListener.cs |
+| SwRS-094 | Wiederverwendbare Massenänderungs-Vorlagen | StRS-001, StRS-015 | src\backend\Centron.BL\MassUpdate\MassUpdateBL.cs |
+| SwRS-095 | Prozessmodelle nur mit gültigen Schritttypen, atomar gespeichert | StRS-001 | src\backend\Centron.BL\Processes\ProcessBL.cs |
+| SwRS-096 | Fehlende ApplicationSettings on-demand mit Default anlegen | SyRS-029, StRS-001 | src\backend\Centron.BL\Administration\Settings\AppSettingsBL.cs |
+| SwRS-097 | Verbindungsdatei mit Fallbackkette und Trust-Optionen | SyRS-032 | src\backend\Centron.BL\Administration\Connections\ConnectionBL.cs |
+| SwRS-098 | Registry-Präferenzen und Typ-Isolation WebService/DB | StRS-001 | src\backend\Centron.BL\Administration\Environments\RegistryBL.cs |
+| SwRS-099 | Nummernkreis-Fortschreibung mit Intervall und Restzähler | SyRS-044, StRS-016 | src\backend\Centron.BL\Administration\Mandatory\MandatoryBL.cs |
+| SwRS-100 | Versionsmeldung je Maschine/Benutzer mit Portal-Upload | SyRS-049, StRS-001 | src\backend\Centron.BL\Administration\Applications\ApplicationVersionBL.cs |
+| SwRS-101 | Systemzähler als Einzelinstanz-Lieferant | StRS-001 | src\backend\Centron.BL\SystemArea\SystemTableI3DBL.cs |
+| SwRS-102 | PDF-Ausgabestrategie mit PDF/A3-Pflicht-Fallback | StRS-003, StRS-001 | src\backend\Centron.BL\ReportEngine\PdfStategy\PdfStrategies.cs |
+| SwRS-103 | Alt-Reportdefinitionen (Legacy "Reports") verwalten | StRS-001 | src\backend\Centron.BL\Reporting\ReportsBL.cs |
+| SwRS-104 | Statistiken aus vorberechneten Cache-Tabellen mit Eigenstatistiken | SyRS-042, StRS-001 | src\backend\Centron.BL\Statistics\OrderStatistics\CacheOrderStatisticsBL.cs |
+| SwRS-105 | Deutsche Volltextsuche mit Stemming UND-Verknüpfung | StRS-001 | src\backend\Centron.BL\IndexSearch\IndexSearchBL.cs |
+| SwRS-106 | Telemetrie-Buckets mit Upload-Kennzeichnung | StRS-001 | src\backend\Centron.BL\Telemetry\TelemetryBL.cs |
+| SwRS-107 | Interne Dokumentation nur mit Leseberechtigung | StRS-004 | src\backend\Centron.BL\DocumentationArea\DocumentationBL.cs |
+| SwRS-108 | Spezifischster Textbaustein je Benutzer/Kunde ermitteln | StRS-011, StRS-003 | src\backend\Centron.BL\TextModuleArea\TextModuleBL.cs |
+| SwRS-109 | Tags beim Verschlagworten reaktivieren | StRS-013 | src\backend\Centron.BL\Tags\TagsBL.cs |
+| SwRS-110 | Auditfelder beim Anlegen über Repositories erzwingen | StRS-015 | src\backend\Centron.DAO\Repositories\Accounts\AccountRepository.cs |
+| SwRS-111 | Feldlängen über typisierte UserTypes abbilden (Trunkierungsschutz) | StRS-001 | src\backend\Centron.DAO\UserTypes\TruncatedStringUserType.cs |
+| SwRS-112 | Zentrale Objekttyp-Nummern als domänenübergreifender Standard | StRS-001 | src\backend\Centron.Entities\Entities\ObjectTypes\ObjectType.cs |
+| SwRS-113 | KI-Chats strikt benutzergetrennt mit persistierter Historie | StRS-001 | src\backend\Centron.BL\Administration\ArtificialIntelligence\Chat\ArtificialIntelligenceChatBL.cs |
+| SwRS-114 | Checklisten an Objekte mit Pflicht-Caption, atomar gespeichert | StRS-013 | src\backend\Centron.BL\CheckListArea\CentronChecklistBL.cs |
+| SwRS-115 | Anbindung an c-pra (Nexoware Smartflow) | SyRS-046 | src\backend\Centron.BL\CPra\CPraConnectorBL.cs |
+| SwRS-116 | Externe-Helpdesk-Konfiguration je Kunde/Kundenort | StRS-013 | src\backend\Centron.BL\ExternalHelpdesk\ExternalHelpdeskConfigurationBL.cs |
+| SwRS-117 | Externe Tools mit Namenspflicht und Variablenersetzung | StRS-001 | src\backend\Centron.BL\ExternalToolsBL\ExternalToolBL.cs |
+| SwRS-118 | Helpdesk-Typen/Kategorien automatisch als virtuelle Checklistenkategorien | StRS-013 | src\backend\Centron.BL\ItPlanner\ChecklistVirtualObjectCategoryBL.cs |
+| SwRS-119 | Projektliste mit Erstellungsdatumfilter (rumpfhaft) | StRS-001 | src\backend\Centron.BL\Projects\ProjectBL.cs |
+| SwRS-120 | Ticketprojekte mit eigener Nummer und Soft-Delete-Aufgaben | StRS-016, StRS-013 | src\backend\Centron.BL\TicketProjects\TicketProjectBL.cs |
+| SwRS-121 | Zeiterfassungs-Stammeinstellungen pflegen | StRS-001 | src\backend\Centron.BL\Time\TimingSettingsBL.cs |
+| SwRS-122 | Benutzerbezogene Transaktionen mit Kategorie-Details | StRS-001 | src\backend\Centron.BL\Transactions\TransactionBL.cs |
+| SwRS-123 | Aktive Gutschein-Barcodes per NamedQuery | StRS-003 | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs |
+| SwRS-124 | URLs als sichtbare, durchsuchbare Objekt-Links | StRS-001 | src\backend\Centron.BL\Urls\SimpleUrlBL.cs |
+| SwRS-125 | Objekt↔Fremdsystem-Referenzen typisiert verwalten | StRS-001 | src\backend\Centron.BL\ObjectExternalReferences\ObjectExternalReferenceBL.cs |
+| SwRS-126 | Modulstamm automatisch ergänzen, Favoriten je Mitarbeiter | StRS-001 | src\backend\Centron.BL\Modules\ModuleBL.cs |
+| SwRS-127 | Ticketabschluss nur mit Recht und erledigter Abschluss-Checkliste | SyRS-043, StRS-013 | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs |
+| SwRS-128 | Single-Instance-Start der Desktop-Anwendung | StRS-001 | src\centron\Centron.WPF.UI\App.xaml.cs |
+| SwRS-129 | Anmeldung als Pflicht-Gate vor der Arbeitsfläche | SyRS-002, StRS-004 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| SwRS-130 | Modul-Layout je Benutzerprofil speichern/zurücksetzen | StRS-001 | src\centron\Centron.WPF.UI\FrontWindow.xaml.cs |
+| SwRS-131 | Konfigurierbare Pflichtfelder in der Belegmaske | StRS-011, StRS-003 | src\centron\Centron.WPF.UI\Modules\Finances\Receipts\ReceiptViewModel.cs |
+| SwRS-132 | Inline-Feldvalidierung E-Mail/IBAN in der Adressmaske | StRS-005 | src\centron\Centron.WPF.UI\Modules\Finances\Crm\Info\CrmInfoTabView.xaml.cs |
+| SwRS-133 | Custom-Gateway-BL für kundenindividuelle openTRANS-Integrationen | SyRS-039, StRS-001 | src\backend\Centron.BL\Gateway\CustomGatewayBL.cs |
+| SwRS-134 | Externe ElectronicSales-Gruppen/Rollen lokal spiegeln | StRS-001 | src\backend\Centron.BL\Integrations\EsCustomerGroupBL.cs |
+
+## Hinweise zur Matrix
+
+1. Die Verfolgung ist vollständig in Richtung Kind→Elter: jede Anforderung listet ihre Eltern in Tracelinks. In Richtung Elter→Kind werden die wesentlichen direkten Kinder genannt; SwRS, die nur eine StRS als groben Rahmen referenzieren, werden dort nicht repetitiv aufgelistet (Deduplizierung über die Kind→Elter-Spalten).
+2. SyRS-010↔SyRS-044 und SyRS-039↔SyRS-011 sind Geschwisterlinks (Querverweise, keine Eltern-Kind-Beziehungen).
+3. StRS-012 besitzt keine abgeleitete Anforderung; die Durchsetzung ist vollständig im PRIMÄR-Beleg (UpdateHelpdeskBL) dokumentiert.
@@ -0,0 +1,129 @@
+# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/builtin/high
+
+> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
+> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
+
+## Lauf
+- **Prompt-Datei:** `03_Prompt.md`
+- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
+- **Startzeit:** 2026-09-02T13:11:02.2153173+02:00
+- **Endzeit:** 2026-09-02T14:03:38.1060735+02:00
+- **Dauer gesamt:** 00:52:32 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
+- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
+- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 13.0.0
+- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
+- **CLI-Version:** OpenCode 1.18.25
+- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
+- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/builtin/high/`
+- **Agentenmodus:** `builtin`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 13, `completed` = 13, `failed` = 0
+- **Rollen:** {"explore": 13}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 501.335 |
+| Output-Tokens | 194.782 |
+| Reasoning-Tokens | 68.781 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 71 |
+
+**Tokens gesamt: 7.830.882.** Kosten `0` – lokaler Betrieb ().
+
+## Gefundene Anforderungen
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 16 | 8,0 % |
+| SyRS | 49 | 24,6 % |
+| SwRS | 134 | 67,3 % |
+| **Gesamt** | **199** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 95 | 47,7 % |
+| Sicherheit | 32 | 16,1 % |
+| nicht-funktional | 28 | 14,1 % |
+| Schnittstelle | 26 | 13,1 % |
+| Daten | 17 | 8,5 % |
+| Datenschutz | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 323 |
+| davon `PRIMÄR` | 256 (79,3 %) |
+| davon `SEKUNDÄR` | 66 (20,4 %) |
+| davon `KONTEXT` | 1 (0,3 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 171 | 85,9 % |
+| workaround | 9 | 4,5 % |
+| sonderfall | 12 | 6,0 % |
+| veraltet | 4 | 2,0 % |
+| (sonstige Angabe) | 3 | 1,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 176 | 88,4 % |
+| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 170 | 85,4 % |
+| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9e2f37dbffePXP0P4ACRLx8cN`
+- **Werkzeugaufrufe:** 116 – {"bash": 50, "task": 13, "grep": 2, "write": 10, "read": 6, "edit": 35}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 13
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*
@@ -0,0 +1,5 @@
+[2026-09-02T11:11:03.761390+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse)
+[2026-09-02T11:11:03.862020+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=builtin; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T12:03:36.484593+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T12:03:38.004876+00:00] OpenCode export: Exporting session: ses_f9e2f37dbffePXP0P4ACRLx8cN
+[2026-09-02T12:03:38.084502+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=7830882; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\RawResult.json
@@ -0,0 +1 @@
+
@@ -0,0 +1,67 @@
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 16 | 8,0 % |
+| SyRS | 49 | 24,6 % |
+| SwRS | 134 | 67,3 % |
+| **Gesamt** | **199** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 95 | 47,7 % |
+| Sicherheit | 32 | 16,1 % |
+| nicht-funktional | 28 | 14,1 % |
+| Schnittstelle | 26 | 13,1 % |
+| Daten | 17 | 8,5 % |
+| Datenschutz | 1 | 0,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 323 |
+| davon `PRIMÄR` | 256 (79,3 %) |
+| davon `SEKUNDÄR` | 66 (20,4 %) |
+| davon `KONTEXT` | 1 (0,3 %) |
+| Belege je Anforderung (Median) | 2 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 197 (99,0 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 171 | 85,9 % |
+| workaround | 9 | 4,5 % |
+| sonderfall | 12 | 6,0 % |
+| veraltet | 4 | 2,0 % |
+| (sonstige Angabe) | 3 | 1,5 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 176 | 88,4 % |
+| als `HYPOTHESE` gekennzeichnet | 23 | 11,6 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 170 | 85,4 % |
+| mit ISO-25010-Qualitätsmerkmal | 60 | 30,2 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (51 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 199 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 199 von 199 mit Tracelinks (100,0 %) |
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,175 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
+Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
+die werkzeugeigenen Subagenten.
+Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
+Werkzeugserver, Webzugriff.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\builtin\high\03_Lauf_2026-09-02_131102_v13.0.0-6a1a\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-09-02T14:03:38.1060735+02:00
@@ -0,0 +1,234 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "provider": {
+    "tensorx": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "TensorX",
+      "options": {
+        "baseURL": "https://api.tensorx.ai/v1"
+      },
+      "models": {
+        "qwen/qwen3.8-flash-next": {
+          "name": "Qwen 3.8 Flash Next",
+          "limit": {
+            "context": 262144,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.2": {
+          "name": "GLM 5.2",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.3-flash": {
+          "name": "GLM 5.3 Flash",
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "moonshotai/kimi-k3": {
+          "name": "Kimi K3",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          }
+        }
+      }
+    }
+  },
+  "model": "tensorx/qwen/qwen3.8-flash-next",
+  "permission": {
+    "*": "deny",
+    "read": "allow",
+    "glob": "allow",
+    "grep": "allow",
+    "list": "allow",
+    "edit": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "external_directory": {
+      "*": "deny",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/builtin/high/03_Lauf_2026-09-02_131102_v13.0.0-6a1a/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "bash": {
+      "*": "allow",
+      "rm *": "deny",
+      "rmdir *": "deny",
+      "mv *": "deny",
+      "cp *": "deny",
+      "dd *": "deny",
+      "truncate *": "deny",
+      "chmod *": "deny",
+      "chown *": "deny",
+      "ln *": "deny",
+      "tee *": "deny",
+      "sed -i*": "deny",
+      "git checkout*": "deny",
+      "git restore*": "deny",
+      "git clean*": "deny",
+      "git reset*": "deny",
+      "git add*": "deny",
+      "git commit*": "deny",
+      "git push*": "deny",
+      "git fetch*": "deny",
+      "git pull*": "deny",
+      "git remote*": "deny",
+      "dotnet *": "deny",
+      "msbuild *": "deny",
+      "npm install*": "deny",
+      "nuget *": "deny",
+      "Remove-Item *": "deny",
+      "Move-Item *": "deny",
+      "Copy-Item *": "deny",
+      "New-Item *": "deny",
+      "Set-Content *": "deny",
+      "Add-Content *": "deny",
+      "Clear-Content *": "deny",
+      "Out-File *": "deny",
+      "Set-ItemProperty *": "deny",
+      "Rename-Item *": "deny"
+    },
+    "task": {
+      "*": "deny",
+      "general": "allow",
+      "explore": "allow"
+    },
+    "webfetch": "deny",
+    "websearch": "deny",
+    "skill": "deny",
+    "question": "deny"
+  },
+  "agent": {
+    "build": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "primary"
+    },
+    "general": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "subagent"
+    },
+    "explore": {
+      "model": "tensorx/qwen/qwen3.8-flash-next",
+      "mode": "subagent"
+    }
+  },
+  "default_agent": "build"
+}
@@ -0,0 +1 @@
+2026-09-02T13:11:02.2153173+02:00