TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

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

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

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

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

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

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

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-02T08:42:44.122853+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse)
+[2026-09-02T08:42:44.241827+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T10:51:52.441929+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T10:51:54.138218+00:00] OpenCode export: Exporting session: ses_f9eb70d9bffeU6O643v8e3i1th
+[2026-09-02T10:51:54.222501+00:00] Ende: Exitcode=0; Status=success; Turns=45; Tokens=11467996; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\RawResult.json

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Analysebericht.md

@@ -0,0 +1,360 @@
+# Analysebericht
+
+Reverse Requirements Engineering - c-entron ERP-Suite (V2, agentengestützt, verteilt). Zeistempel des Laufs: 2026-09-02. Arbeitsverzeichnis: `02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel` (Spiegel der Codebasis; `src` ist ein Windows-Junction auf den Quellcode). Es entstehen genau die sieben vorgegebenen Dateien (StRS.md, SyRS.md, SwRS.md, Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md).
+
+## 1. Modulinventar (Schritt 0)
+
+Erstellt durch den Bearbeiter **modulinventar** vor der ersten Anforderung; Bezugsgröße der Abdeckung. 141 Module (111 fachlich / 30 technisch), 15.268 zugeordnete Quelldateien (.cs/.razor ohne bin/obj/packages), Differenz zu 15.273 Gesamtquelldateien: 5 BL-Basisdateien im Projektroot (BaseBL, BLSession, DBBaseBL, SystemInfoLogger, AssemblyInfo - BL-Infrastruktur, keinem Fachordner zugeordnet).
+
+| Modul | Pfad | Fachliche Aufgabe | Dateien (ca.) |
+|---|---|---|---|
+| M001 Accounting | src\backend\Centron.BL\Accounting | Bankverbindungslogik (BankAccountBL). | 1 |
+| M002 Accounts | src\backend\Centron.BL\Accounts | Adressstamm Kunden/Lieferanten, Adressen, Kontakte, Suche. | 29 |
+| M003 Administration | src\backend\Centron.BL\Administration | Lizenzen, Benutzerrechte, Logins, Mandanten, Mitarbeiter, SQL-Verwaltung. | 959 |
+| M004 AppointmentRequests | src\backend\Centron.BL\AppointmentRequests | Terminanfragen. | 1 |
+| M005 ArtificialIntelligence | src\backend\Centron.BL\ArtificialIntelligence | KI-Chatdienste, Modellkatalog, Link-Validierung. | 25 |
+| M006 BusinessPartner | src\backend\Centron.BL\BusinessPartner | Lieferantensuche und Lieferanten-Assets. | 2 |
+| M007 Buying | src\backend\Centron.BL\Buying | Großhändler/Distributoren. | 1 |
+| M008 Calendar | src\backend\Centron.BL\Calendar | Kalenderlogik. | 1 |
+| M009 CentronIcons | src\backend\Centron.BL\CentronIcons | Zentrale Icons inkl. Webservice-Abgleich. | 2 |
+| M010 CentronNexus (BL) | src\backend\Centron.BL\CentronNexus | BL-Anbindung Nexus-Webclient. | 1 |
+| M011 ChangeTracking | src\backend\Centron.BL\ChangeTracking | Änderungsverfolgung über Import-Historien. | 1 |
+| M012 Chats | src\backend\Centron.BL\Chats | Chatlogik. | 1 |
+| M013 CheckListArea | src\backend\Centron.BL\CheckListArea | Checklisten inkl. Kaskade und Änderungsprotokoll. | 3 |
+| M014 Core (BL) | src\backend\Centron.BL\Core | Krypto- und Platzhalterhelfer. | 2 |
+| M015 CountryArea | src\backend\Centron.BL\CountryArea | Länder- und Bundeslandstammdaten. | 2 |
+| M016 CPra | src\backend\Centron.BL\CPra | Konfiguration/Connector externer CPra-Dienst. | 2 |
+| M017 CustomerArea | src\backend\Centron.BL\CustomerArea | Branchen, Kontaktaktivitäten, Interessen, RMA. | 7 |
+| M018 Customizations | src\backend\Centron.BL\Customizations | Kundenspezifische Tabellen. | 1 |
+| M019 DataExchange | src\backend\Centron.BL\DataExchange | Buchhaltungs-Export/-Import, DocBee-Connector. | 23 |
+| M020 Devices | src\backend\Centron.BL\Devices | Kundengeräte. | 1 |
+| M021 DocuBoard | src\backend\Centron.BL\DocuBoard | Asset-Zuordnungen zu Artikeln/Partnern, AD-Ausschlüsse. | 3 |
+| M022 DocumentationArea | src\backend\Centron.BL\DocumentationArea | Dokumentationsverwaltung. | 1 |
+| M023 EDI | src\backend\Centron.BL\EDI | EDI-Dispatcher und Händler-Bestelllogik. | 27 |
+| M024 EmployeeArea | src\backend\Centron.BL\EmployeeArea | Mitarbeiter, Urlaubsdaten, RFID-Tokens, Abteilungen. | 9 |
+| M025 Exceptions | src\backend\Centron.BL\Exceptions | Zentrale BL-Exception-Typen. | 1 |
+| M026 ExpectedEvents | src\backend\Centron.BL\ExpectedEvents | Erwartete Events (automatisierte Ereignisprüfung). | 1 |
+| M027 ExternalHelpdesk | src\backend\Centron.BL\ExternalHelpdesk | Konfiguration externer Helpdesks. | 1 |
+| M028 ExternalToolsBL | src\backend\Centron.BL\ExternalToolsBL | Externe Werkzeuge (URL-Vorlagen). | 1 |
+| M029 Finances | src\backend\Centron.BL\Finances | Zahlungseingänge, Online-Banking, Produktlebenszyklen. | 9 |
+| M030 Gateway (BL) | src\backend\Centron.BL\Gateway | Benutzerdefinierte Gateways (Sonderartikel-Import). | 1 |
+| M031 GUI (BL) | src\backend\Centron.BL\GUI | Benutzergrids, UI-Profile, Session-Logging. | 6 |
+| M032 Helpers (BL) | src\backend\Centron.BL\Helpers | Graph-Service, PDF/Word, Bilder. | 6 |
+| M033 IndexSearch | src\backend\Centron.BL\IndexSearch | Volltextindex mit deutscher Analyse. | 7 |
+| M034 Integrations | src\backend\Centron.BL\Integrations | Kundengruppen/Rollen eines externen Systems. | 2 |
+| M035 ItPlanner | src\backend\Centron.BL\ItPlanner | IT-Planer, virtuelle Objektkategorien. | 1 |
+| M036 Logistics | src\backend\Centron.BL\Logistics | Lagereinstellungen, Bestandslogik. | 2 |
+| M037 Mail | src\backend\Centron.BL\Mail | E-Mail (Exchange/EWS/SMTP/Graph), Signaturen, Domänen-Blacklist. | 20 |
+| M038 Mailings | src\backend\Centron.BL\Mailings | Serienmailing-Daten und -Vorlagen. | 2 |
+| M039 MailScanner | src\backend\Centron.BL\MailScanner | Virtueller Mailassistent (VMA). | 1 |
+| M040 MassUpdate | src\backend\Centron.BL\MassUpdate | Massenaktualisierung von Daten. | 1 |
+| M041 Mobile | src\backend\Centron.BL\Mobile | Mobile Clients. | 1 |
+| M042 Modules | src\backend\Centron.BL\Modules | Lizenzierbare Module und Kategorien. | 3 |
+| M043 MyCentron (BL) | src\backend\Centron.BL\MyCentron | Dashboard, Kurznotizen, zuletzt verwendet. | 4 |
+| M044 MyDay | src\backend\Centron.BL\MyDay | „Mein Tag"-Arbeitsplatz, Webservice, Berichtskonnektoren. | 7 |
+| M045 NexusNotifications | src\backend\Centron.BL\NexusNotifications | Benachrichtigungsversand an Nexus. | 2 |
+| M046 NexusTicketViews | src\backend\Centron.BL\NexusTicketViews | Ticket-Ansichten für Nexus. | 1 |
+| M047 Notifications | src\backend\Centron.BL\Notifications | Benutzer- und Systembenachrichtigungen. | 2 |
+| M048 ObjectExternalReferences | src\backend\Centron.BL\ObjectExternalReferences | Fremdreferenzen zu c-entron-Objekten. | 1 |
+| M049 Outlook | src\backend\Centron.BL\Outlook | Outlook-seitige Asset-/Objektsuche. | 1 |
+| M050 PasswordManagementArea | src\backend\Centron.BL\PasswordManagementArea | Passwort-Management mit Zugriffs-Logs. | 6 |
+| M051 PasswordManager | src\backend\Centron.BL\PasswordManager | Passwort-Manager (Richtlinien, Export). | 1 |
+| M052 Processes | src\backend\Centron.BL\Processes | Prozessverwaltung (Workflow-Schritte). | 1 |
+| M053 Production | src\backend\Centron.BL\Production | Produktion und Produktionsaufträge. | 2 |
+| M054 ProductMatrix | src\backend\Centron.BL\ProductMatrix | Produktmatrix-Logik. | 1 |
+| M055 Projects | src\backend\Centron.BL\Projects | Projektverwaltungslogik. | 1 |
+| M056 Purchasing | src\backend\Centron.BL\Purchasing | Lieferanten, Bestellvorschlagsliste, Filial-Kalkulation. | 4 |
+| M057 ReportEngine | src\backend\Centron.BL\ReportEngine | Report-Engine (FastReport), Reportdaten-Abfragen. | 26 |
+| M058 Reporting | src\backend\Centron.BL\Reporting | Berichtslogik (Legacy). | 1 |
+| M059 RiverDivo | src\backend\Centron.BL\RiverDivo | River/Divo-RMM-Anbindung. | 4 |
+| M060 Sales | src\backend\Centron.BL\Sales | Belege (Receipts), Kassenbücher, Kunden, Marketing, Support/Helpdesk. | 248 |
+| M061 Security | src\backend\Centron.BL\Security | PDF-Signierung. | 1 |
+| M062 SelfCare | src\backend\Centron.BL\SelfCare | Kundenportal-/Webformularlogik. | 2 |
+| M063 Services | src\backend\Centron.BL\Services | Hintergrund-/Connectordienste (CachedTables, cTime, DirectoryCheck). | 11 |
+| M064 SocialMedia | src\backend\Centron.BL\SocialMedia | Personen-Verknüpfung soziale Netzwerke. | 3 |
+| M065 Start | src\backend\Centron.BL\Start | Start-/Initialisierungslogik. | 1 |
+| M066 Statistics | src\backend\Centron.BL\Statistics | Umsatz, Mitarbeiterauslastung, Verträge. | 16 |
+| M067 Storage | src\backend\Centron.BL\Storage | Lager-/Inventur-Altbestand (stillgelegt). | 2 |
+| M068 SystemArea | src\backend\Centron.BL\SystemArea | Zugriff auf Systemtabellen. | 1 |
+| M069 Tags | src\backend\Centron.BL\Tags | Verschlagwortung von Objekten. | 1 |
+| M070 Tapi | src\backend\Centron.BL\Tapi | TAPI-Telefonie, Anrufprotokolle. | 1 |
+| M071 TaskManager | src\backend\Centron.BL\TaskManager | Aufgabenverwaltung mit Helpdesk-Aktionstypen. | 4 |
+| M072 Telemetry | src\backend\Centron.BL\Telemetry | Telemetrie-/Diagnoselogik. | 1 |
+| M073 TextModuleArea | src\backend\Centron.BL\TextModuleArea | Textbausteine, Anrede-/Grußformel-Ersetzung. | 2 |
+| M074 TicketProjects | src\backend\Centron.BL\TicketProjects | Projektzuordnung von Tickets. | 1 |
+| M075 Time | src\backend\Centron.BL\Time | Einstellungen Zeiterfassung/Timing. | 1 |
+| M076 ToDoArea | src\backend\Centron.BL\ToDoArea | To-do-Verwaltung über Objektarten. | 2 |
+| M077 Tools | src\backend\Centron.BL\Tools | Werkzeuglogik (Textformate). | 1 |
+| M078 TradePool | src\backend\Centron.BL\TradePool | Handelsverbund-Logik mit XML-Austausch. | 2 |
+| M079 Transactions | src\backend\Centron.BL\Transactions | Spesen-/Transaktionsbuchungen. | 1 |
+| M080 TwoFactorAuthenticator | src\backend\Centron.BL\TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung (TOTP). | 1 |
+| M081 Urls | src\backend\Centron.BL\Urls | Einfache URLs mit Webservice-Anbindung. | 2 |
+| M082 VideoPortal | src\backend\Centron.BL\VideoPortal | Zuordnungen im Videoportal. | 1 |
+| M083 VoucherManagement | src\backend\Centron.BL\VoucherManagement | Gutscheinbelegverwaltung. | 1 |
+| M084 Warehousing | src\backend\Centron.BL\Warehousing | Artikel, Einheiten/Varianten, Aktionspreise, Bestände. | 40 |
+| M085 WebLinks | src\backend\Centron.BL\WebLinks | Weblinks mit Aktionen auf Kontenaktivitäten. | 4 |
+| M086 WebServices (BL-Fassade) | src\backend\Centron.BL\WebServices | *WebServiceBL je Fachbereich, bedient Webservice-Hosts. | 464 |
+| M087 WebSuite | src\backend\Centron.BL\WebSuite | Webeinstellungen, Web-Helpdesk-Fragen. | 5 |
+| M088 WebVersion | src\backend\Centron.BL\WebVersion | Versionsprüfung gegen den Webservice. | 1 |
+| M089 Centron.Common | src\backend\Centron.Common | Hilfs-, Format-, Konstantenklassen, Debug-Sicherheit, Feature-Schalter. | 56 |
+| M090 Centron.DAO | src\backend\Centron.DAO | Datenzugriff (NHibernate/ADO.NET, Mappings, Repositories). | 1129 |
+| M091 Centron.Entities | src\backend\Centron.Entities | Fachliche Entitäten inkl. Webservice-Entitäten. | 1183 |
+| M092 Centron.Gateway | src\backend\Centron.Gateway | EDI-Händler, OpenTrans, ZUGFeRD, Online-Banking, MspCollector. | 103 |
+| M093 Centron.Interfaces | src\backend\Centron.Interfaces | Schnittstellen-/Kontraktdefinitionen, Konstanten. | 762 |
+| M094 Centron.Api.EbInterface | src\apis\Centron.Api.EbInterface | Österreichische E-Rechnungen (ebInterface). | 2 |
+| M095 Centron.Api.Gls | src\apis\Centron.Api.Gls | GLS-Versandanbindung. | 15 |
+| M096 Centron.Api.Shipcloud | src\apis\Centron.Api.Shipcloud | Shipcloud-Versand-API. | 29 |
+| M097 Centron.APIs.CopDataAccess | src\apis\Centron.APIs.CopDataAccess | SOAP-Datenzugriff CopData. | 14 |
+| M098 Centron.APIs.EgisDataAccess | src\apis\Centron.APIs.EgisDataAccess | SOAP-Datenzugriff Egis. | 18 |
+| M099 Centron.APIs.FinAPI | src\apis\Centron.APIs.FinAPI | REST-Client FinAPI-Bankdienstleistungen. | 70 |
+| M100 Centron.APIs.IcecatDataAccess | src\apis\Centron.APIs.IcecatDataAccess | Produktstammdaten über Icecat. | 14 |
+| M101 Centron.APIs.ITscopeDataAccess | src\apis\Centron.APIs.ITscopeDataAccess | Produktstammdaten über ITscope. | 22 |
+| M102 Centron.WebServices.Core | src\webservice\Centron.WebServices.Core | Service-Kern (Verbindungen, REST-Requests, Interception). | 2528 |
+| M103 Centron.Host | src\webservice\Centron.Host | ASP.NET-Host mit Fach- und Real-Time-Diensten. | 156 |
+| M104 Centron.Host.Console | src\webservice\Centron.Host.Console | Konsolen-Startvariante. | 2 |
+| M105 Centron.Host.WindowsService | src\webservice\Centron.Host.WindowsService | Windows-Dienst-Startvariante. | 3 |
+| M106 Centron.Controllers | src\webservice\Centron.Controllers | Controller- und Autorisierungsschicht. | 54 |
+| M107 c-entron.misc.ConnectionManager | src\webservice\c-entron.misc.ConnectionManager | Verbindungs-/SQL-Server-Prüftool. | 26 |
+| M108 Centron.WPF.UI (Shell) | src\centron\Centron.WPF.UI | WPF-Shell: Modulregistrierung, Lokalisierung, Wizards, ViewModels. | 1205 |
+| M109 Centron.WPF.UI.Extension | src\centron\Centron.WPF.UI.Extension | MVVM-/Erweiterungsframework (Actions, Commands, Extensibility). | 158 |
+| M110 WPF-Maske: Finances | src\centron\Centron.WPF.UI\Modules\Finances | Abrechnungsmasken: Vertrags-/Ticketabrechnung, Mahnung, OPOS, SEPA, Verträge. | 1664 |
+| M111 WPF-Maske: Warehousing | src\centron\Centron.WPF.UI\Modules\Warehousing | Lagermasken: Artikel, Import, Inventur, Kommissionierung. | 426 |
+| M112 WPF-Maske: Administration | src\centron\Centron.WPF.UI\Modules\Administration | Verwaltungsmasken: Mandanten, Mitarbeiter, Rechte, DSGVO, SQL-Manager, Lizenzen. | 261 |
+| M113 WPF-Maske: Helpdesk | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticket-Liste, Taskmanagement, Checklisten, Prozessvorlagen. | 254 |
+| M114 WPF-Maske: DataExchange | src\centron\Centron.WPF.UI\Modules\DataExchange | Buchhaltungsexport/-import, DATEV, DocSync. | 178 |
+| M115 WPF-Maske: MyCentron | src\centron\Centron.WPF.UI\Modules\MyCentron | Dashboard, Mein Tag, Todo, Telefonate, persönliche Einstellungen. | 169 |
+| M116 WPF-Maske: Statistics | src\centron\Centron.WPF.UI\Modules\Statistics | Controlling/Analytics: Vertriebsstatistik, Management Info, MSP, Auslastung. | 111 |
+| M117 WPF-Maske: Purchasing | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellvorschlagsliste, EDI-Verwaltung, Eingangsbelege. | 105 |
+| M118 WPF-Maske: Global | src\centron\Centron.WPF.UI\Modules\Global | Custom Properties, MSP-Lizenzvergleich. | 89 |
+| M119 WPF-Maske: OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | FinTS/FinAPI-Konfiguration, Zuordnung Banktransaktionen. | 68 |
+| M120 WPF-Maske: ArtificialIntelligence | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Assistent-Chat und KI-Einstellungen. | 58 |
+| M121 WPF-Maske: Survey | src\centron\Centron.WPF.UI\Modules\Survey | Audit-/Umfragewesen. | 46 |
+| M122 WPF-Maske: Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Data-Updater für Massenaktualisierungen. | 34 |
+| M123 WPF-Maske: Sales | src\centron\Centron.WPF.UI\Modules\Sales | Produktmatrix, Sonderartikel-Import zu Verträgen. | 34 |
+| M124 WPF-Maske: Rma | src\centron\Centron.WPF.UI\Modules\Rma | RMA-/Werkstatt-Abwicklung. | 24 |
+| M125 CentronNexus (Blazor) | src\nexus\CentronNexus | Webclient: WebCart/Shop, WebOffer, ServiceBoard, Dokument-Signierung. | 756 (296 .cs + 460 .razor) |
+| M126 CentronNexus.Host | src\nexus\CentronNexus.Host | Host der Blazor-Anwendung. | 3 |
+| M127 CentronNexus.OutlookAddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Add-In mit c-entron-Funktionen. | 53 |
+| M128 Centron.Controls | src\shared\Centron.Controls | WPF-Steuerelementbibliothek je Fachbereich. | 742 |
+| M129 Centron.Controls.Preview | src\shared\Centron.Controls.Preview | Preview-Varianten der Steuerelemente (Test-Harness). | 43 |
+| M130 Centron.Core | src\shared\Centron.Core | MVVM, TOTP/Google-Auth, PDF-Scanning, Threading. | 72 |
+| M131 Datenbankschema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-Schema (1535 dbo-Tabellen, Präfixgruppen). | 1 (76.793 Zeilen) |
+| M132 Tests | tests\ | Unit-, Integrations-, E2E- und Playwright-Tests. | 378 .cs (3.659 gesamt) |
+| M133 Deployment | deployment\ | Installationsbau centron/riverbird, WixSharp-Installer. | 21 |
+| M134 Docker | docker\ | Images/Compose für API, Webservice, Demo, Regression. | 18 |
+| M135 Scripts | scripts\ | Datenbank- und Wartungsskripte, Build-Targets. | 19 |
+| M136 Azure-Pipelines | azure\ | Pipelines Build, Tests, Regression, Docker. | 13 |
+| M137 Azure-Pipelines Blazor | azure-blazor\ | Pipelines Nexus: Unit-Tests, Playwright, Security-Scan. | 6 |
+| M138 GitHub-Workflows | .github\ | GitHub-Actions und Workflows. | 5 |
+| M139 Docs | docs\ | Projektdokumentation Architektur, Belege, Rechte, UI, Dienste. | 54 |
+| M140 Centron.Api.docuFORM | Centron.Api.docuFORM\ | REST-Client DocuFORM (Geräte-/Zählerdaten). | 75 |
+| M141 Assemblies | assemblies\ | Eingecheckte Fremd-Binärdateien (7pdf, Outlook, RDP, TAPI, WPF-Themes). | 9 |
+
+Buchführung (aus dem modulinventar-Lauf): 141 Module; nicht zugeordnete Quelldateien: 5 BL-Basisdateien (oben); nicht als Quellcode gezählt: Root-Konfiguration/Build-Dateien, .vscode, nugets (13 Dritt-Pakete), ~3.281 Nicht-Code-Dateien in tests (Test-/Erwartungsdaten). Die abweichende Formulierung des M108-Eintrags im Rohinventar (fehlerhafte Tabellenzeile) wurde beim Übernehmen berichtigt.
+
+## 2. Abdeckungstabelle
+
+Stufe = Einstufung aus den faktenermittler-Läufen; Anzahl = Anforderungen, die aus dem Modul erzeugt wurden (alle Ebenen). Jede Inventarzeile ist vertreten; Mindestabdeckung (≥ 1 Anforderung je Modul) ist damit erfüllt.
+
+| Modul | Stufe | Anzahl | Abgedeckt durch |
+|---|---|---|---|
+| M001 | mittel | 1 | SwRS-1 |
+| M002 | tief | 2 | SwRS-24; StRS-19/20 |
+| M003 | tief | 7 | SwRS-49/50/51/52; StRS-1/3; SyRS-1..6 |
+| M004 | mittel | 1 | SwRS-116 |
+| M005 | mittel | 2 | SwRS-53; StRS-4 |
+| M006 | mittel | 1 | SwRS-25 |
+| M007 | flach | 1 | SwRS-36 |
+| M008 | flach | 1 | SwRS-117 |
+| M009 | flach | 1 | SwRS-118 |
+| M010 | flach | 1 | SwRS-89 |
+| M011 | flach | 1 | SwRS-119 |
+| M012 | tief | 1 | SwRS-120 |
+| M013 | tief | 2 | SwRS-15; StRS-19 |
+| M014 | mittel | 2 | SwRS-140; SwRS-122 (ReplacementBL) |
+| M015 | mittel | 2 | SwRS-26; StRS-20 |
+| M016 | mittel | 1 | SwRS-121 |
+| M017 | mittel | 2 | SwRS-27; StRS-18 |
+| M018 | flach | 1 | SwRS-122 (CustomTableBL) |
+| M019 | mittel | 4 | SwRS-2/3; StRS-9/11 |
+| M020 | mittel | 2 | SwRS-28; StRS-19 |
+| M021 | mittel | 1 | SwRS-123 |
+| M022 | tief | 1 | SwRS-124 |
+| M023 | mittel | 2 | SwRS-37; StRS-21 |
+| M024 | mittel | 4 | SwRS-61/62; StRS-3/26 |
+| M025 | flach | 1 | SwRS-125 |
+| M026 | mittel | 1 | SwRS-126 |
+| M027 | flach | 2 | SwRS-127/128 |
+| M028 | flach | 1 | SwRS-29 |
+| M029 | mittel | 5 | SwRS-4/5/6; StRS-3/8 |
+| M030 | tief | 1 | SwRS-63 |
+| M031 | mittel | 3 | SwRS-64/107; StRS-2 |
+| M032 | mittel | 1 | SwRS-129 |
+| M033 | tief | 2 | SwRS-130; SyRS-34 |
+| M034 | mittel | 1 | SwRS-65 |
+| M035 | mittel | 2 | SwRS-16; StRS-19 |
+| M036 | mittel | 3 | SwRS-38; StRS-18/21 |
+| M037 | tief | 4 | SwRS-131; StRS-15; SyRS-31; (Kanal/SMTP in SyRS-29/30) |
+| M038 | mittel | 1 | SwRS-132 |
+| M039 | tief | 2 | SwRS-133; StRS-3 |
+| M040 | tief | 3 | SwRS-66/108; StRS-13 |
+| M041 | flach | 1 | SwRS-89 |
+| M042 | flach | 1 | SwRS-54 |
+| M043 | mittel | 1 | SwRS-67 |
+| M044 | tief | 2 | SwRS-68; StRS-26 |
+| M045 | tief | 2 | SwRS-90; SyRS-32 |
+| M046 | tief | 1 | SwRS-91 |
+| M047 | mittel | 2 | SwRS-92; SyRS-33 |
+| M048 | mittel | 2 | SwRS-30; StRS-20 |
+| M049 | flach | 1 | SwRS-93 |
+| M050 | mittel | 2 | SwRS-55; StRS-5 |
+| M051 | mittel | 2 | SwRS-55; StRS-5/25 |
+| M052 | mittel | 1 | SwRS-134 |
+| M053 | tief | 2 | SwRS-39; StRS-25 |
+| M054 | mittel | 1 | SwRS-40 |
+| M055 | flach | 1 | SwRS-135 |
+| M056 | tief | 2 | SwRS-41; StRS-21 |
+| M057 | tief | 4 | SwRS-136/137; StRS-30; SwRS-137 |
+| M058 | mittel | 1 | SwRS-138 |
+| M059 | tief | 3 | SwRS-69/70; StRS-24 |
+| M060 | tief | 5 | SwRS-7/8/9/10; StRS-7 |
+| M061 | tief | 2 | SwRS-56; StRS-3 |
+| M062 | mittel | 2 | SwRS-17; StRS-15 |
+| M063 | tief | 3 | SyRS-25/26/27 |
+| M064 | flach | 1 | SwRS-31 |
+| M065 | nicht analysiert | 1 | SwRS-144 (nur Stubs - Begründung unten) |
+| M066 | mittel | 1 | SwRS-143 |
+| M067 | flach | 1 | SwRS-42 |
+| M068 | flach | 1 | SwRS-145 |
+| M069 | mittel | 2 | SwRS-32; StRS-20 |
+| M070 | mittel | 1 | SwRS-146 |
+| M071 | tief | 2 | SwRS-18; StRS-17 |
+| M072 | mittel | 1 | SyRS-28 |
+| M073 | tief | 1 | SwRS-33 |
+| M074 | mittel | 3 | SwRS-19; StRS-17/20 |
+| M075 | flach | 1 | SwRS-71 |
+| M076 | tief | 3 | SwRS-72/73; StRS-2 |
+| M077 | flach | 1 | SwRS-74 |
+| M078 | mittel | 3 | SwRS-75/76; StRS-24 |
+| M079 | mittel | 1 | SwRS-77 |
+| M080 | flach | 2 | SwRS-57; StRS-1 |
+| M081 | flach | 1 | SwRS-34 |
+| M082 | mittel | 1 | SwRS-139 |
+| M083 | flach | 2 | SwRS-11; StRS-12 [HYP] |
+| M084 | tief | 4 | SwRS-43/44; StRS-21 |
+| M085 | tief | 2 | SwRS-35; StRS-15 |
+| M086 | flach | 3 | SwRS-81/82; SyRS-11 |
+| M087 | mittel | 1 | SwRS-20 |
+| M088 | flach | 2 | SwRS-58; SyRS-37 |
+| M089 | mittel | 2 | SwRS-141/142 |
+| M090 | tief | 4 | SyRS-20/21/22/23 |
+| M091 | mittel | 1 | SyRS-24 |
+| M092 | mittel | 2 | SwRS-45; StRS-8 |
+| M093 | flach | 1 | SyRS-24 |
+| M094 | mittel | 2 | SwRS-99; StRS-14 |
+| M095 | tief | 2 | SwRS-100; StRS-24 |
+| M096 | mittel | 2 | SwRS-101; StRS-24 |
+| M097 | tief | 2 | SwRS-102; StRS-24 |
+| M098 | tief | 2 | SwRS-103; StRS-24 |
+| M099 | tief | 3 | SwRS-104; StRS-8/24 |
+| M100 | mittel | 2 | SwRS-105; StRS-24 |
+| M101 | tief | 2 | SwRS-105; StRS-24 |
+| M102 | mittel | 2 | SwRS-83; SyRS-19 |
+| M103 | tief | 6 | SwRS-84/85; SyRS-8/9/12; StRS-1/6 |
+| M104 | flach | 2 | SwRS-86; SyRS-36 |
+| M105 | flach | 2 | SwRS-86; SyRS-35 |
+| M106 | mittel | 2 | SwRS-87; SyRS-10 |
+| M107 | flach | 2 | SwRS-88; SyRS-36 |
+| M108 | tief | 4 | SwRS-109/110; StRS-2/25 |
+| M109 | flach | 1 | SwRS-109 (Interface-Vertrag im Beleg) |
+| M110 | mittel | 2 | SwRS-12; StRS-10 |
+| M111 | mittel | 3 | SwRS-46; StRS-22/23 |
+| M112 | mittel | 2 | SwRS-59 [HYP]; StRS-2 |
+| M113 | mittel | 3 | SwRS-21/22; StRS-16 |
+| M114 | flach | 2 | SwRS-13; StRS-11 |
+| M115 | mittel | 3 | SwRS-78/111; StRS-25 |
+| M116 | mittel | 3 | SwRS-79/112; StRS-2 |
+| M117 | tief | 2 | SwRS-47; StRS-21 |
+| M118 | flach | 3 | SwRS-80/112; StRS-25 |
+| M119 | mittel | 2 | SwRS-14; StRS-8 |
+| M120 | flach | 2 | SwRS-60; StRS-4 |
+| M121 | mittel | 1 | SwRS-113 |
+| M122 | mittel | 1 | SwRS-113 |
+| M123 | mittel | 3 | SwRS-48; StRS-13/22 |
+| M124 | tief | 2 | SwRS-23; StRS-18 |
+| M125 | mittel | 4 | SwRS-94/95/96; StRS-6/15 |
+| M126 | mittel | 3 | SwRS-97; SyRS-17/18; StRS-6 |
+| M127 | flach | 1 | SwRS-98 |
+| M128 | flach | 1 | SwRS-114 |
+| M129 | flach | 1 | StRS-27/SyRS-38 (Preview-Testharness, kein Produktionspfad) |
+| M130 | mittel | 2 | SwRS-115; StRS-1 |
+| M131 | tief | 2 | SyRS-23; StRS-20 |
+| M132 | mittel | 2 | SyRS-39; StRS-29 |
+| M133 | mittel | 2 | SyRS-38; StRS-27 |
+| M134 | mittel | 3 | SyRS-38; StRS-27/29 |
+| M135 | mittel | 3 | SyRS-38/39; StRS-29 |
+| M136 | mittel | 2 | SyRS-39; StRS-29 |
+| M137 | mittel | 2 | SyRS-39; StRS-29 |
+| M138 | flach | 2 | SyRS-39; StRS-29 |
+| M139 | mittel | 2 | SyRS-40; StRS-29 |
+| M140 | tief | 2 | SwRS-106; StRS-24 |
+| M141 | flach | 1 | SyRS-38 |
+
+**Stufenzählung:** tief 37, mittel 67, flach 36, nicht analysiert 1 (M065) = 141. **Mindestabdeckung: erfüllt** - jedes Modul trägt mindestens eine Anforderung. Das einzige als `nicht analysiert` geführte Modul ist M065 (Start-BL): beide Methoden sind auskommentierte Stubs ohne jede durchsetzbare Stelle; die Funktionslosigkeit ist belegt und als SwRS-144 dokumentiert. 1 von 141 Modulen = 0,7 %, die 10-%-Warnschwelle ist damit klar unterschritten.
+
+## 3. Arbeitsteilung (Dokumentationspflicht)
+
+Die Zuständigkeitsbindung wurde eingehalten: alle gebundenen Teilaufgaben wurden durch den jeweils vorgesehenen Bearbeiter ausgeführt. Beauftragungen (22 Agentenaufträge):
+
+| Bearbeiter | Aufträge | Zuschnitt |
+|---|---|---|
+| modulinventar | 1 | gesamte Codebasis → Inventar M001-M141 inkl. Buchführung |
+| faktenermittler | 13 | Ausschnitte A (Finanzen: M001, M019, M029, M060, M083, M110, M114, M119), B (Support: M013, M035, M062, M071, M074, M087, M113, M124), C (Stammdaten: M002, M006, M015, M017, M020, M028, M048, M064, M069, M073, M081, M085), D (Einkauf/Lager: M007, M023, M036, M053, M054, M056, M067, M084, M092, M111, M117, M123), E (Admin/Sicherheit: M003, M005, M042, M050, M051, M061, M080, M088, M112, M120), F (Webservices: M086-M107), G1 (Nexus/Outlook: M010, M041, M045-M047, M049, M125-M127), G2 (APIs: M094-M101, M140), H (WPF/Shared: M031, M040, M108, M109, M115, M116, M118, M121, M122, M128-M130), I1 (Kommunikation: 17 Module M004-M082), I2 (Datenhaltung: M014, M025, M032, M063, M089-M093), I3 (Restfachlogik: 19 Module M018-M079), L (DB/Build/CI/Doku: M131-M141); die Ausschnitte decken M001-M141 überschneidungsfrei |
+| strs-autor | 1 | StRS aus den 13 Faktenberichten; ID-Bereich StRS-1..40, gestellt 30 (StRS-1..30) |
+| syrs-autor | 1 | SyRS aus den Faktenberichten + StRS-ID-Liste; ID-Bereich SyRS-1..60, gestellt 40 (SyRS-1..40) |
+| swrs-autor | 4 | (1) Ausschnitt A-E → SwRS-1..60; (1a) Nachlieferung 16 Module ohne Fakten im ersten Durchlauf → SwRS-61..80; (2) Ausschnitt F-H → SwRS-81..115; (3) Ausschnitt I-L → SwRS-121..163. ID-Bereiche überschneidungsfrei vergeben (1-80, 81-120, 121-180) |
+| belegpruefer | 1 | 12 Stichproben risikorelevanter Anforderungen (StRS-7/9, SyRS-2/9/12, SwRS-8/9/49/55/61/137/146) gegen den Code |
+| iso29148-orchestrator | 1 | Gesamtbestand 216 Anforderungen gegen ISO/IEC/IEEE 29148, Schwerpunkt Nahtstellen |
+| konsistenzpruefer | 1 | Vollständiger Abschluss-Konsistenzcheck (Abschnitt „Abschluss") |
+
+**Eigenständig ausgeführt (Auftraggeber):** Zuschnitt der 13 Ausschnitte, ID-Bereichsvergabe, Reihenfolge der Aufträge (Inventar → 13× Fakten → StRS → SyRS → SwRS×4 → Prüfung×3), Anlegen der sieben Ergebnisdateien, Übernahme der Rückmeldungen. Dazu gehörten ausdrücklich: Entdoppelung von SwRS-Anforderungen, die zwischen der Nachlieferung des Auftrags A-E (SwRS-61..80) und dem Auftrag I-L (SwRS-121..163) für dieselben Module (M024, M030, M034, M043, M044, M059, M075, M076, M077, M078, M079) entstanden - die Erstfassungen wurden behalten, die Zweitfassungen entfernt und der verbleibende Bestand lückenlos zu SwRS-1..146 neu nummeriert; vier Querverweise auf umnummerierte/entfallene IDs wurden korrigiert. **Keine der gebundenen Teilaufgaben (Inventar, Faktenerhebung, Anforderungsformulierung, Belegprüfung, Nahtstellenprüfung, Konsistenzprüfung) wurde vom Auftraggeber selbst ausgeführt.**
+
+## 4. Konsistenzcheck (Abschnitt „Abschluss")
+
+Ergebnis der drei Prüfläufe (Volltextprüfung durch konsistenzpruefer und iso29148-orchestrator, Stichprobe durch belegpruefer):
+
+- **Doppelte/mehrfach vergebene IDs:** keine. StRS-1..30, SyRS-1..40, SwRS-1..146 lückenlos ohne Dubletten.
+- **Anforderungen ohne Beleg:** keine (216/216 mit nichtleerem Belege-Feld).
+- **Anforderungen ohne Übernahmewürdigkeit:** keine (216/216).
+- **Tracelinks auf nicht existierende IDs:** keine. Nach Prüfbefund korrigiert: SwRS-81 → zusätzlich SyRS-11; SwRS-50 → zusätzlich SyRS-4; SwRS-86/SwRS-88 → zusätzlich SyRS-36; SwRS-115 → zusätzlich SyRS-5; SwRS-137/SwRS-138 → SyRS-20 durch SyRS-21 ersetzt (Raw-SQL liegt sachlich beim Roh-SQL-Zugriff, nicht beim DAO-Lebenszyklus).
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung:** nach Prüfbefund markiert: SwRS-108 ↔ SwRS-66 (Massenpreisaktualisierung, M040), SwRS-81 ↔ SyRS-11, SwRS-50 ↔ SyRS-4, SwRS-86/SwRS-88 ↔ SyRS-36. Weitere Konsolidierungskandidaten sind in den Blöcken markiert (u. a. Aktionspreis Maske/BL, Textbaustein-Löschsemantiken, Versand-Clients GLS/Shipcloud, OAuth finAPI/docuFORM, Passwortprüfstellen BasicAuthenticator/TradePoolBL, 2FA zweifach, Platzhalterersetzung zweifach, Raw-SQL-Ausführung zweifach, StorageBL veraltet).
+- **Liste der risikorelevanten Anforderungen (konsistenzpruefer, 104):** StRS: 1-17, 22-26, 30; SyRS: 1-13, 16-19, 27; SwRS: Typ Sicherheit 6, 22, 24, 39, 49-53, 55-57, 59-61, 69, 70, 72, 79, 81, 82, 84, 87, 94, 96, 97, 114, 115, 120, 121, 124, 128, 133, 139-143; Qualitätsmerkmal Sicherheit 137, 138; abrechnungsrelevant 2-5, 7-14, 43-48, 63, 66, 99, 108, 136. **Belegsituation: 101 von 104 tragen einen PRIMÄR-Beleg mit durchsetzender Stelle; ohne PRIMÄR genau 3 (StRS-12, SwRS-59, SwRS-128), alle drei als [HYPOTHESE] gekennzeichnet. 0 Verstöße gegen die risikobasierte Priorisierung.**
+- **Abgleich Hypothesen.md gegen Inline-Markierungen:** deckungsgleich. Inline mit Status HYPOTHESE: genau StRS-12, StRS-30, SwRS-59, SwRS-128; Hypothesen.md nennt genau diese vier und keine freien Fragen. SyRS führt keine Hypothese.
+- **Belegstichprobe (belegpruefer):** 12 von 12 geprüfte Stellen bestätigt (Datei, Klasse, Methode, Bedingung stimmen im Kern); keine Abweichungen.
+- **Traceability-Konsistenz:** nach Prüfbefund korrigiert: Tabellenzeile SwRS-114 (SyRS-/StRS-Spalten vertauscht) berichtigt; SyRS-34-Tracelink-Feld normiert (Anker StRS-30, fachliche Entsprechung fehlt - dokumentierte Lücke).
+- **Ergebnisstruktur:** genau die sieben vorgegebenen Dateien; keine Ergänzungs- oder Teil-Dateien. (Der Prüfbefund „Analysebericht.md fehlt" bezog sich auf den Prüfzeitpunkt vor dieser Nachlieferung.)
+
+## 5. Selbstbewertung
+
+- **Erkundungstiefe:** 37 Module tief, 67 mittel, 36 flach, 1 nicht analysiert (M065, nur Stubs). Große Fachmodule (M060 Sales 248, M086 WebServices 464, M102 Core 2528, M003 Administration 959, M090 DAO 1129, M108 Shell 1205) wurden als gezielte Stichprobe der Hauptklassen erschlossen, nicht vollständig gelesen - das ist in den faktenermittler-Tabellen je Modul ausgewiesen.
+- **Mindestabdeckung:** erreicht; jedes der 141 Module trägt mindestens eine Anforderung (siehe Abdeckungstabelle). Ein Modul ohne Anforderung und ohne Begründung existiert nicht.
+- **Dünne Beleglage (hoher SEKUNDÄR/KONTEXT-Anteil):** die technischen Kleinst- und Infrastrukturmodule M025, M042, M065, M068, M075, M088, M129, M139, M141 - dort trägt teilweise das Schema oder die Dateistruktur die Aussage statt durchgesetzter Fachregeln. Hypothesen: 4 (StRS-12, StRS-30, SwRS-59, SwRS-128); eine Analyse ohne offene Punkte wäre bei dieser Codebasis unplausibel und wurde nicht behauptet.
+- **Erkenntnisse für eine Folge-Iteration (Nachschlag lohnt):**
+  1. Gutschein-Einlösung (M083): Schreibpfade (Aktivierung/Einlösung) im Webservice/Webshop lokalisieren - Grundlage für StRS-12/SwRS-11.
+  2. Serverseitige Helpdesk-Statuslogik (HelpdeskBL, Sales.Support): die für StRS-16/SwRS-21/22 zitierte Abschlussprüfung liegt außerhalb der geprüften Maskenmodule.
+  3. Backend-Rechteprüfung für SqlManager/Reportabfragen (SwRS-59) und ExternalHelpdesk-Konfiguration (SwRS-128): beide als Hypothese geführt, Webservice-Schicht war nicht im Ausschnitt.
+  4. Mandanten-/Datenbanktrennung je Anfrage: im Host nicht gefunden (eine konfigurierte Verbindungszeichenfolge, Meldung in SwRS-85/SyRS-9) - für den SaaS-Zielentwurf zentral zu klären.
+  5. Serverseitige Spiegelprüfungen zu UI-Gates: Dokument-Signierung/SEPA (M125), Outlook-Verzeichnis-Blacklist (M127), Fremd-Todo-Zugriff (M115), Aktionspreis-BL-Validierung (M084/M111) - Kanalübergreifende Durchsetzung (StRS-22) ist Zielableitung.
+  6. ReceiptBL (11.441 Zeilen) nur ausschnittweise; Belegkette/Ursprungsarten (ReceiptProgressionBL) und Vertragsabrechnung (M110: AutomatedBilling/FlatrateBilling/SEPA-Masken) unbelesen.
+  7. Preisbildung im WebCart serverseitig (M125-Meldung) - für StRS-22 zu verifizieren.
+- **Im Zielsystem zu korrigierende Defekte (aus der Analyse):** ungesalzenes SHA1-Passwort (M003, Kommentar im Code), Passwort-Neuanlage speichert das Passwort nie (M050), Kontaktaktivitäts-Löschschutz deaktiviert (M017), Mailing-Filterzuweisung fehlt (M038), Icon-Kategoriefilter wirkungslos (M009), Outlook-AssetKind-Alias-Bug (M049), vertauschte Kalender-Settings-Schlüssel (M008), SN-Scan-Dialog unvollständig (M111), Online-Banking-Converter NotImplementedException (M119), unendlicher Client-Timeout (M102), pauschale CORS-Policy (M103).
+
+## 6. Bekannte Lücken (Struktur des Anforderungssatzes)
+
+- **Ebenensprung direkt auf StRS** (SwRS ohne eigene SyRS-Verankerung, in Traceability.md dokumentiert): SwRS-99 bis SwRS-106 (Externe-Dienst-Clients) und SwRS-108 (Massenupdate-Ausschlussregeln) - fachlich projektlokale Schnittstellen-/Ausschlussregeln ohne eigenes systemweites Gegenstück; vermittelt über StRS-24 bzw. StRS-14.
+- **SyRS ohne SwRS-Gegenstück** (dokumentiert): SyRS-4 (Anmeldekette, BL-Seite über SwRS-50 verlinkt), SyRS-7 (Web-Konto-Kaskade, M003-Bereich), SyRS-26 (CTime-Sync, Modul M063 über SyRS-25/26/27 abgedeckt), SyRS-31 (Blacklist-Abgleich BL-seitig in M037 geprüft, SwRS-131 verweist), SyRS-36 (Konsolen-Werkzeuge, SwRS-86/88 verlinken nach Korrektur), SyRS-39/40 (QS-Pipelines/Doku - reine Betriebsebene, bewusst ohne SwRS).
+- **SyRS-34 ↔ StRS-30:** formaler Anker; eine fachliche StRS-Verankerung der Volltextsuche fehlt - als Abdeckungslücke dokumentiert.
+- **SwRS-125:** nur Klassendefinition belegt (SEKUNDÄR), Wurfstelle außerhalb der Stichprobe; als Nicht-Risikoanforderung mit SEKUNDÄR-Beleg geführt, Übernahmewürdigkeit „Sonderfall".
+- **SwRS-144:** grenzwertig als Anforderung (beschreibt Funktionsabwesenheit); bewusst als belegte Beobachtung geführt (Übernahmewürdigkeit „Sonderfall").
+- **Kosmetik:** Notation des Qualitätsmerkmal-Felds schwankt („-" vs. leeres Feld); ISO-29148-Befunde SwRS-122 (doppelte Semantik „null bzw. string.Empty") und SwRS-142 (Debugger-Gates nahe an der Implementierung) sind als Anmerkungen im Bericht des Orchestrators dokumentiert.
+- **Proxy-Befund des Konsistenzpruefers** („M063, M091, M129, M139 ohne Anforderungsbezug") beruht auf der Suche nach den M-Nummern im Anforderungstext; tatsächlich sind diese Module über SyRS-25/26/27 (M063), SyRS-24 (M091), StRS-27/SyRS-38 (M129) und SyRS-40 (M139) abgedeckt - siehe Abdeckungstabelle.

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Glossar.md

@@ -0,0 +1,49 @@
+# Glossar
+
+Domänen- und Systembegriffe, die in den Anforderungen verwendet werden (technische Bezeichner im Original).
+
+| Begriff | Definition |
+|---|---|
+| Adressstamm (Account) | Konto-Datensatz für Kunde oder Lieferant inkl. Adressen, Kontakten; Tabelle Accounts; eindeutige Kunden-/Lieferantennummer. |
+| Beleg (Receipt) | Verkaufs-/Einkaufsdokument (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift); Kopf in RechKopf/AufKopf/GutKopf, Positionen in RechPos usw.; Belegversionen mit ConcurrencyControlGuid. |
+| Belegstatus | Zustandsmodell der Belege (ReceiptState: Active, Completed, Canceled u. a.); „bezahlt", „storniert", „festgeschrieben (IsFixed)". |
+| OPOS | Offene Posten; Forderungsstand je Rechnung; wird aus Belegzahlungen fortgeschrieben (UpdateOpos). |
+| SEPA-Mandat | Lastschriftmandat mit Zahlungsart (First/Recurrent/Last/Single) und Gültigkeitsfenster (ValidFrom/ValidTo). |
+| Kassenbuch | Sammlung von Bar-Buchungen (CashBookRecord) je MwSt-Split; Abschluss (ClosedDate) schützt Buchungen. |
+| FIBU | Finanzbuchhaltung; Export/Import von Belegdaten (BookKeepingExport/Import, PORTRECH/PORTWARE-Flags). |
+| Mahnstopp | Befristete Sperre des Mahnlaufs je Kunde oder Rechnung (DunningStop), tagesgenau. |
+| Gutschein | Wertgutschein mit Status frei/aktiviert/eingelöst, abgeleitet über GutscheinZuRechnung → RechPos. |
+| Ticket / Helpdesk | Supportvorgang (hlpdsk_*); Bearbeitersperre, Statusmodell, Abschlussprüfung (CanHelpdeskClose). |
+| Checkliste (CentronChecklist) | Prüfliste mit hierarchischen Items; Caption-Pflicht, Statuskaskade, Soft-Delete, Versionslog. |
+| RMA | Rückgabe-/Reklamationvorgang; lagergebunden (RMA-Lager RmaOwn/RmaCustomer), aktionstypabhängige Pflichten. |
+| Lager (Stock/Warehouse) | Bestandshaltung je Filiale; Vorgabelager (IsDefault), vier RMA-Sonderlager; Umbuchungsprotokoll. |
+| Artikel (Article) | Stammsatz mit Einkaufspreis-Strategie (Fixed/Last/Misch-EK), Aufschlagstabellen, ScanBarcode-Pflicht für SN-Buchungen. |
+| Bestellvorschlag (OrderSuggestionList) | SQL-basierte Vorschlagsliste aus Bedarf − Bestand + Zulauf unter Sperr-/SV-Kriterien. |
+| EDI | Elektronischer Datenaustausch mit Distributoren (Alltron, Also, Komsa, ITscope über OpenTrans 2.1); Format-Routing, Kreditorcode-Pflicht. |
+| Distributor | Externer Großhändler als Stammsatz (State-Flag), automatische Neuanlage beim Import. |
+| Nummernkreis (NumberGroup) | Lückenlose Nummernvergabe je Objektart mit Fallback-Kette Mitarbeiter → Filiale → Standardmandant. |
+| Mandant | Datenhaltungs-/Verwaltungseinheit des ERP-Betriebs; im Webservice eine konfigurierte Datenbankverbindung (keine mandantenweise Trennung je Anfrage belegt). |
+| Filiale / Niederlassung (Branch) | Organisatorische Untereinheit; Rechte variieren (z. B. SHOW_HELPDESK_ONLY_OWN_BRANCH, MANAGEMENT_INFO_ONLY_OWN_BRANCH). |
+| Recht (UserRight) | Feingranulare Berechtigungskonstante, ausschließlich an Gruppen vergeben (Sichtrus/Sichmemb); Beispiele: ADD_NEW_HELPDESK, INCOMING_PAYMENT_TRANSACTIONS, EDIT_GLOBAL_PROFILES. |
+| Lizenz (LicenseGuids) | Produkt-/Modullizenz (Concurrent-User-Beschränkung, Versionsschranke); Modulsichtbarkeit = Rechte UND Lizenz, Centron-Vollizenz als Fallback (Ausnahmen: MSP, PasswordManager, Produktion, AI, PLM). |
+| Ticket (Sitzung) | Anmeldungssitzung am Webservice (AuthenticationTicketBL), slide-Verlängert, parallel zu Access-Token; NICHT mit Helpdesk-Ticket verwechseln. |
+| Access-Token | Dauerhafter API-Zugangs-Token mit Own-or-Right-Verwaltung (VIEW_ALL/EDIT_ALL/DELETE_ALL/CREATE_PERSONAL). |
+| WebAccount | Portal-Login eines Kunden (Status 1, SHA1-Prüfung, Aktiv-Kaskade Konto→Kunde→Kontakt→Adresse). |
+| Nexus | Blazor-Webclient „c-entron Nexus" (Mitarbeiterbereich + Kundenportal, Port-Trennung). |
+| ServiceBoard | Weboberflächen-/Formularkomponente; Basis-URL für öffentliche Webformulare (SelfCare). |
+| VMA (Virtual Mail Assistant) | MailScanner-Profile mit Modulrecht ACCESS_VMA_MODULE und Master-Key-Verschlüsselung. |
+| MSP | Managed-Services-Produktbereich (MspCollector/MspModule) ohne Centron-Lizenz-Fallback. |
+| I3D | Systemweiter ganzzahliger Primärschlüssel (IDENTITY) aller Tabellen; Entitätsidentität; Zahlenraum teilt sich zwischen Employee und WebAccount (Eindeutigkeit nur mit ObjectKind). |
+| ObjectKind | Objektartnummer (CentronObjectKindNumeric), stabiler Wire-Contract (OfferClass=1, InvoiceClass=4, CustomerClass=5000012). |
+| ConcurrencyControlGuid | Optimistische Sperre auf Belegköpfen; Mismatch → ReceiptConcurrencyConflictOnSave. |
+| Soft-Delete | Logische Löschung über Status/IsActive/IsDeleted statt physischem DELETE. |
+| Named Query | In NamedQueryPool.xml hinterlegte, per Enum adressierte SQL-Abfrage. |
+| CachedTable | Lokale Statistik-/Cache-Tabellen mit transaktionalem Update, Stale-Lock-Recovery (>10 min). |
+| RESTC | Webservice-Protokoll: REST-POST unter „/REST"+UriTemplate (komprimierte Variante /RESTC) mit Ticket im Request. |
+| SecretKey-Policy | Statischer Bearer-Schlüssel für den SignalR-NotificationsHub (aus WebService-Konfiguration). |
+| Master-Key | Hotline-seitiger Schlüssel zur Ver-/Entschlüsselung sensibler Konfigurationen (AESCryptoLogic/EncryptWithMasterKey). |
+| ebInterface | Österreichisches E-Rechnungsformat (Schema 4p3) mit USt-ID-/Reverse-Charge-Validierung. |
+| ZUGFeRD / OpenTrans | Austauschformate für E-Rechnung (ZUGFeRD 2.1) und Bestell-EDI (OpenTrans 1.0/2.1), xsd-generierte Klassen im Gateway. |
+| PRIMÄR / SEKUNDÄR / KONTEXT | Belegklassifikation: durchgesetzte Regel im Code/DB-Constraint / UI-Text, Konfiguration, Mapping / Kommentar, README, Ticketreferenz. |
+| [HYPOTHESE] | Kennzeichnung unbelegter oder nur teilweise belegter Aussagen mit Angabe der fehlenden Information. |
+| Übernahmewürdigkeit | Einstufung übernehmen / Workaround / Sonderfall / veraltet zur fachlichen Zukunft der Anforderung im Zielsystem. |

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Hypothesen.md

@@ -0,0 +1,12 @@
+# Hypothesen
+
+Sammlung aller mit [HYPOTHESE] markierten Anforderungen (deckungsgleich mit den Inline-Kennzeichnungen in StRS.md/SyRS.md/SwRS.md). Offene Punkte ohne zugehörige Anforderung stehen in Analysebericht.md (Selbstbewertung, bekannte Lücken).
+
+| ID | Titel | Fehlende Information (warum Hypothese) | Offene Frage |
+|---|---|---|---|
+| StRS-12 | Gutschein-Lebenszyklus mit verbindlicher Einlösung | Die schreibende Einlöse-/Aktivierungslogik für Gutscheine ist im Modul M083 nicht auffindbar; nur die Leseklassifikation über Belegrückverweise ist belegt. | Wo/wie wird ein Gutschein aktiviert und eingelöst, und welche Regel verhindert die doppelte Einlösung? |
+| StRS-30 | Berichte ohne unbeschränkten Datenzugriff | Die Rohtext-SQL-Ausführung (M057/M058) ist belegt; eine Schutzregel existiert an der Stelle nicht - die gewünschte Beschränkung ist Zielbild, nicht Beobachtung. | Wie ist der kontrollierte Rahmen für Berichtsdefinitionen im Zielsystem konkret auszugestalten (Rechte, Parametrisierung, Mandantensicht)? |
+| SwRS-59 | Mandanten-KI-Anweisungen und Reportabfragen: Rechte-/Lizenz-Gate | UI-Gate (AI-Lizenz + MANDATORY) ist belegt; die Backend-Durchsetzung liegt außerhalb des untersuchten Ausschnitts (IReportLogic.ReportEngineExecuteQuery nicht geprüft). | Prüft der Webservice die SqlManager-/Reportabfragen backendseitig nach Recht? |
+| SwRS-128 | ExternalHelpdesk-Konfiguration: Rechteprüfung am Webservice-Zugang | Die BL enthält keine Rechteprüfung; der aufrufende Webservice-Kontext lag außerhalb des untersuchten Ausschnitts. | Prüft der Webservice-Zugang auf ExternalHelpdesk-Konfigurationen eine Modulrechtsprüfung? |
+
+Keine weiteren Hypothesen. SyRS führt keine Hypothese; SwRS führt genau SwRS-59 und SwRS-128.

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/StRS.md

@@ -0,0 +1,591 @@
+# StRS - Stakeholder Requirements Specification
+
+Reverse Requirements Engineering - c-entron ERP-Suite (WPF-Client, Webservice-Host, Blazor-Webclient Nexus, MSSQL). Basis: statische Analyse der Codebasis (Arbeitsverzeichnis). Evidenzkonvention: Belege stammen aus den faktenermittler-Berichten zu den Modulen M001-M141 des Modulinventars (siehe Analysebericht.md); Modulkürzel verweisen auf die dort genannte durchsetzende Stelle (Datei/Klasse/Methode/Bedingung). Risikorelevante Anforderungen (Abrechnung/Fakturierung, Berechtigungen, Sicherheit) tragen PRIMÄR-Belege oder sind als [HYPOTHESE] markiert.
+
+---
+
+ID: StRS-1
+Titel: Authentifizierung mit Zweifaktorprüfung und Lizenzvorbehalt beim Zugang
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Benutzer (Mitarbeiter/Administration); System (Zugangskontrolle)
+Vorbedingung: Benutzerkonto existiert; Konto-/Mitarbeiterstatus aktiv; Lizenzbestand vorhanden
+Fakt: Login-Kette prüft gruppenbasierte Rechte (Sichtrus/Sichmemb), Konto-/Mitarbeiterstatus und Verbots-/Pflichtrechte je Anwendungstyp; 2FA schaltbar, TOTP gegen pro-Benutzer-Key (RFC-Konfiguration); Concurrent-User-Lizenzen als Startvoraussetzung; Admin-Gruppe löschgeschützt (M003, M080, M130, M103).
+Aussage: Das System soll den Zugang nur aktiven, berechtigten Benutzern nach erfolgreicher Authentifizierung - mit zweitem Faktor, wo freigeschaltet - und nur bei verfügbarer Lizenz gewähren.
+Ergebnis: Zugang besteht ausschließlich für gültige Konten mit erfüllter Faktor- und Lizenzbedingung; gesperrte Konten bleiben ausgesperrt.
+Belege:
+  - [PRIMÄR] M003 (AppRightsBL.HasUserRight/CheckRightsFromUser, Authenticator.AuthenticateUser/ValidateRights, LicenseManager.CheckLicense, UsersBL.UpdatePassword, WebAccountBL.LoginWithWebAccount) - Begründung: Zugangskontrolle mit Durchsetzung im Anmeldeprozess.
+  - [PRIMÄR] M080 (TwoFactorAuthenticationBL.ValidateAuthenticationPin) - Begründung: zweiter Faktor benutzergebunden erzwungen.
+  - [SEKUNDÄR] M130 (Totp.VerifyParameters) - Begründung: Konfigurationsdetail zum zweiten Faktor.
+  - [PRIMÄR] M103 (CentronHost.Start: TryLoadLicense vor DB-Setup) - Begründung: Zugang ohne Lizenz verweigert.
+Prüfidee: Gesperrtes Konto, Benutzer ohne freigegebenen Zweifaktor und Anmeldung ohne freie Lizenz führen jeweils zur Ablehnung; aktiver Benutzer mit 2FA gelangt hinein.
+Tracelinks: StRS-2; StRS-3; StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Rechte-/Status-/Lizenzkette belastbar; Passwort-Hashing wegen Widerspruchs M003/M014 neu festzulegen.
+Status: belegt
+
+ID: StRS-2
+Titel: Kanalübergreifende Durchsetzung von Berechtigungen durch das System
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: System (Geschäftslogik); Administration (Rechtepflege)
+Vorbedingung: Benutzer ist authentifiziert; Rechte-, Filial- und Lizenzstammdaten liegen vor
+Fakt: BL-Fassade prüft Rechte pro Operation, auch für den WPF-Kanal (M086); alle API-Controller RequireAuthorization, Endpunkt-Rechtefilter antwortet 401/403 (M103, M106); Modulsichtbarkeit = Rechte UND Lizenz, auch Settings gefiltert (M108); WPF-Admin blendet nach Rechten/Lizenz aus, Backend entscheidet (M112); Statistik mit Filialrechtefilter (M116), globale UI-Profile nur mit EDIT_GLOBAL_PROFILES (M031), fremde Todos verwerfen nur mit Recht (M076).
+Aussage: Das System soll jede fachliche Operation und jeden Datenzugriff - ungeachtet der verwendeten Bedienoberfläche - anhand von Rollen-, Filial- und Lizenzrechten selbst prüfen und unberechtigte Zugriffe ablehnen.
+Ergebnis: Unberechtigte Operationen werden zentral abgelehnt; Ausblendungen in Bedienoberflächen sind nur ergänzend, nie die einzige Sperre.
+Belege:
+  - [PRIMÄR] M086 (AccessTokenWebServiceBL.GetById/Delete mit Own-or-Right-Muster; Kommentar: Rights-Checks bewusst in der BL) - Begründung: zentrale Prüfung unabhängig vom Kanal.
+  - [PRIMÄR] M106 (UserRightAuthorizationFilter.OnAuthorization, AllUserRightsAuthorizationFilter) - Begründung: Ablehnung unberechtigter Zugriffe (401/403) ist implementiert.
+  - [PRIMÄR] M108 (ModuleRegistration.DoRegisterCentronModules/CheckRights/CheckModuleFeatures; GetSettingsWithoutModule) - Begründung: Sichtbarkeit folgt der Systementscheidung.
+  - [PRIMÄR] M112 (MandatorManagementViewModel.SaveMandatorInstructionPrompt; SettingsContainerViewModel) - Begründung: Backend ist maßgeblich, UI blendet nur aus.
+Prüfidee: Benutzer mit Recht R, dem Recht S fehlt, ruft eine S-geschützte Aktion über Desktop und Webschnittstelle auf → beide Aufrufe werden systemseitig abgelehnt.
+Tracelinks: StRS-1; StRS-10; StRS-25
+Konsolidierung: Kandidat: M116 (Filialrechtefilter, ManagementInfoViewModel), M031 (EDIT_GLOBAL_PROFILES, UiProfileBL), M076 (fremde Todos verwerfen, ToDoBL.UpdateTodoDiscardedFlag) als Einzelfälle derselben Regel
+Übernahmewürdigkeit: übernehmen - zentrale Prüfung pro Operation als Grundprinzip festhalten; Rechtetabellen-Details sind SwRS-Thema.
+Status: belegt
+
+ID: StRS-3
+Titel: Kein Klartext für Passwörter, Schlüssel und Tokens
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
+Akteur: System
+Vorbedingung: Zugangsdaten/Geheimnisse werden gespeichert, angezeigt oder gesucht
+Fakt: Passwort-Hash SHA1+Salt (M014; M003-Kommentar nennt „ungesalzenes SHA1"); KI-Keys verschlüsselt (M005); RFID-Tokens verschlüsselt, Klartext nie in der Suchform (M024); VMA-Profile rechtegeschützt, Passwörter verschlüsselt (M039); PDF-Signatur verschlüsselt konfiguriert (M061); Bankkonfiguration verschlüsselt (M029).
+Aussage: Das System soll Zugangsdaten und Geheimnisse (Passwörter, Schlüssel, Tokens, Bank- und Signaturkonfiguration) niemals im Klartext ablegen, anzeigen oder durchsuchbar halten; Passwörter nur als nicht umkehrbare Hashwerte (mit Salt), sonstige Geheimnisse nur verschlüsselt.
+Ergebnis: Geheimnisse liegen ausschließlich gehasht bzw. verschlüsselt vor; Suche und Protokolle liefern keinen Klartext.
+Belege:
+  - [PRIMÄR] M014 (CryptoUtils.CreatePasswordHash mit Salt; TradePoolBL.SaveUser) - Begründung: Passwörter werden gehasht mit Salt abgelegt.
+  - [PRIMÄR] M024 (EmployeeRfidTokenBL.CreateFilterExpression: EncryptWithMasterKey vor Suche; Schema EmployeeRfidTokens.RfidTokenEncrypted NOT NULL) - Begründung: Suchpfad schließt Klartext aus.
+  - [PRIMÄR] M039 (MailScannerBL.SaveProfile/EncryptProperties) - Begründung: Zugangsdaten verschlüsselt geführt.
+  - [PRIMÄR] M061 (PdfSigningBL.DoGetCertificate: AESCryptoLogic für Zertifikat/Passwort) - Begründung: Signaturgeheimnisse geschützt.
+Prüfidee: Abfragen auf den Speicherstellen für Passwörter/Tokens/Keys liefern keinen Klartext; die Suchfunktion findet keine Geheimnisinhalte.
+Tracelinks: StRS-1; StRS-4; StRS-8
+Konsolidierung: Kandidat: M005 (GetApiKey: CryptoControl.DecryptString), M029 (OnlineBankingConfigurationBL.GetSecurityKey, AESCryptoLogic mit Hotline-Master-Key) unter dieselbe Regel
+Übernahmewürdigkeit: übernehmen - Grundsatz fortführen; das Hashverfahren (SHA1) ist für die Neuimplementierung zu ersetzen.
+Status: belegt
+
+ID: StRS-4
+Titel: KI-Funktionen nur freigegeben und mit Benutzerverantwortung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Benutzer; System
+Vorbedingung: KI-Funktion eingerichtet; Zieladresse bekannt
+Fakt: KI-Endpunkte sind an eine HTTPS-Host-Allowlist gebunden, Keys verschlüsselt (M005); KI-Tool-Aufrufe unterliegen einer Bestätigungspflicht (M120).
+Aussage: Das System soll KI-gestützte Aktionen nur gegenüber freigegebenen Zielen und erst nach ausdrücklicher Bestätigung des Benutzers ausführen.
+Ergebnis: Kein KI-Aufruf ohne Ziel-Freigabe und ohne Benutzerbestätigung.
+Belege:
+  - [PRIMÄR] M005 (AiApiLinkValidator.GetValidatedApiLink/IsLocalOrPrivateHost) - Begründung: Zielbeschränkung ist durchgesetzt.
+  - [PRIMÄR] M120 (ArtificialIntelligenceChatCoordinator: RequiresConfirmation → ConfirmAsync, sonst kein Aufruf) - Begründung: menschliche Freigabe vor Ausführung.
+Prüfidee: Aufruf gegen ein nicht freigegebenes Ziel wird abgelehnt; ohne bestätigende Benutzeraktion erfolgt keine Ausführung.
+Tracelinks: StRS-2; StRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Allowlist- und Bestätigungsprinzip für den SaaS-Betrieb fortführen.
+Status: belegt
+
+ID: StRS-5
+Titel: Passwort-Tresor mit Abrufprotokoll und kontrolliertem Export
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Benutzer mit Tresorberechtigung; System
+Vorbedingung: Tresoreintrag existiert; Benutzer ist authentifiziert
+Fakt: Passwort-Management protokolliert jeden Abruf (M050); Export braucht Lizenz UND Recht (M051); Beobachtung: Neuanlage speichert das Passwort nicht (Bug, M050).
+Aussage: Das System soll jeden Abruf eines Tresoreintrags protokollieren und Exporte nur bei Vorliegen von besonderem Recht und Lizenz zulassen; bei Neuanlage ist das Passwort zuverlässig abzulegen.
+Ergebnis: Jeder Abruf ist Person und Zeitpunkt zuordenbar; Export ohne Recht/Lizenz wird abgelehnt; neu angelegte Einträge liefern ihr Passwort korrekt.
+Belege:
+  - [PRIMÄR] M050 (PasswordManagementKeywordBL.GetDecryptedKeywordById: SavePasswordManagementAccessLog vor jeder Rückgabe; Schema PasswordManagementAccessLog NOT NULL) - Begründung: Nachvollziehbarkeit jedes Zugriffs ist implementiert.
+  - [PRIMÄR] M051 (PasswordManagerBL.GetAllCustomerAccountsWithAccessData: HasLicense + EXPORT_ACCESS_AND_PASSWORD_DATA) - Begründung: Export doppelt kontrolliert.
+  - [SEKUNDÄR] M050 (PasswordManagementKeywordBL.AddNewKeyword: password-Parameter wird nie gespeichert) - Begründung: Fehlerbeobachtung, Ziel daraus abgeleitet.
+Prüfidee: Abruf erzeugt Protokolleintrag mit Benutzer/Zeitpunkt; Benutzer ohne Exportrecht erhält eine Ablehnung; nach Neuanlage liefert ein Abruf das hinterlegte Passwort.
+Tracelinks: StRS-1; StRS-3; StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Abrufprotokoll und Rechte-/Lizenzprüfung fortführen; Neuanlagen-Fehler (M050) ist zu beheben.
+Status: belegt
+
+ID: StRS-6
+Titel: Gesicherter Webzugang mit getrennten Portalen
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Sicherheit
+Akteur: Kunde (Kundenportal); Mitarbeiter (Mitarbeiterbereich); System
+Vorbedingung: Webclient „Nexus" ist erreichbar; Portale sind konfiguriert
+Fakt: Nexus-Host erzwingt HTTPS, Mitarbeiter-/Kundenportal-Port-Trennung als Zugriffsregel, Anmeldung über Cookie/OIDC (M126); Open-Redirect-Schutz im Blazor-Client (M125); SignalR-Hubs geschützt (M103).
+Aussage: Das System soll Webzugriffe ausschließlich verschlüsselt anbieten, Mitarbeiter- und Kundenportal als getrennte Zugriffswege führen und Umleitungen so begrenzen, dass Benutzer nicht auf fremde Ziele gelangen.
+Ergebnis: Unverschlüsselte Zugriffe werden abgelehnt; portalübergreifende Zugriffe bleiben ausgeschlossen; Umleitungsziele bleiben im kontrollierten Rahmen.
+Belege:
+  - [PRIMÄR] M126 (Program.cs ConfigureWebHostLinux nur Https/Http; PortAuthorization.PortHandler prüft LocalPort) - Begründung: Verschlüsselung und Trennung sind erzwungen.
+  - [PRIMÄR] M125 (Shared/Auth/AuthController.GetSafeReturnUrl: IsLocalUrl-Prüfung) - Begründung: Schutz gegen manipulierte Umleitungen.
+  - [PRIMÄR] M103 (SecretKeyHandler + [Authorize]-Hubs) - Begründung: Echtzeitkanäle stehen nicht offen.
+Prüfidee: Klartext-HTTP-Anfrage wird abgelehnt bzw. auf HTTPS geführt; Kundenportal ist über den Mitarbeiterzugang nicht erreichbar und umgekehrt; manipulierter Umleitungsparameter wird verworfen.
+Tracelinks: StRS-1; StRS-2; StRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Verschlüsselungszwang und Portaltrennung als Grundschutz fortführen.
+Status: belegt
+
+ID: StRS-7
+Titel: Belegstatus mit Änderungs-, Storno- und Gleichzeitigkeitsregeln
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Buchhaltung/Fakturierung (Rolle); System
+Vorbedingung: Beleg existiert in einem Status (bezahlt/storniert/festgeschrieben)
+Fakt: Belegstatus bezahlt/storniert/festgeschrieben mit Rechte-, Storno-, Export- und Concurrency-Regeln; Kassenbuchabschluss schützt enthaltene Buchungen (M060); optimistische Sperr-GUID auf Belegköpfen, verschachtelte Transaktionen (M090).
+Aussage: Das System soll fertiggestellte und bezahlte Belege vor unberechtigter Änderung und vor gleichzeitigen widersprüchlichen Bearbeitungen schützen; Stornierung nur nach Prüf- und Rechteordnung, abgeschlossene Kassenperioden bleiben unveränderlich.
+Ergebnis: Statuswechsel und Storni erfolgen nur regelkonform; gleichzeitige Änderungen verursachen keinen stillen Datenverlust.
+Belege:
+  - [PRIMÄR] M060 (ReceiptBL.UpdateReceiptIsPaid Z.4902; ReceiptInvoiceBL.CancelInvoice Z.143; FixInvoice Z.86; CashBookBookingBL.DeleteCashBookBooking) - Begründung: Geschäftsregeln am Beleg sind durchgesetzt.
+  - [PRIMÄR] M090 (SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency: ConcurrencyControlGuid-Mismatch → ReceiptConcurrencyConflictException) - Begründung: Gleichzeitigkeitsmechanismus vorhanden.
+Prüfidee: Zwei gleichzeitige Änderungen desselben Belegs → zweite wird abgelehnt; Änderung eines festgeschriebenen Belegs ohne Stornorecht wird verweigert; Buchung im abgeschlossenen Kassenbuch bleibt fix.
+Tracelinks: StRS-8; StRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Status- und Schutzmodell ist Kern der Abrechnungsintegrität.
+Status: belegt
+
+ID: StRS-8
+Titel: Verbuchung von Zahlungseingängen mit Zuweisungsgrenze
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Buchhaltung (Rolle); System
+Vorbedingung: Rechnung/Gutschrift mit offener Forderung vorhanden; Bankanbindung konfiguriert
+Fakt: Zahlungseingänge inkl. Online-Banking-Verbuchung unter Rechnungs-/Gutscheinstatus-Regeln, verschlüsselte Bankkonfiguration (M029); FinTS-Zugangsdaten, TAN-Dialog nötig (M092); Zuweisung von Zahlungseingängen begrenzt auf Eingang und Forderung (M119).
+Aussage: Das System soll Zahlungseingänge nur in Höhe des tatsächlichen Eingangs und nur bis zur Höhe der offenen Forderung zuordnen; der elektronische Bankzugriff erfordert geschützte Zugangsdaten und eine gesonderte Freigabe.
+Ergebnis: Keine Überzuweisung und keine Zuweisung über den Eingang hinaus; Bankzugriffe laufen geschützt mit Freigabeverfahren.
+Belege:
+  - [PRIMÄR] M119 (OnlineBankingTransactionAssignmentViewModel.CheckNewAssignedAmount: Ablehnung bei Eingangs-/Forderungsüberschreitung) - Begründung: Zuweisungsgrenze ist durchgesetzt.
+  - [PRIMÄR] M029 (OnlineBankingAccountTransactionsBL.BookAmountToAssignedInvoice Z.1042; OnlineBankingConfigurationBL mit AESCryptoLogic) - Begründung: Statusregeln und Konfigurationsschutz vorhanden.
+  - [SEKUNDÄR] M092 (OnlineBankingConnectionLibfintx.LoadOnlineBankingTransactionsByFinTS/WaitForTanAsync) - Begründung: Freigabeverfahren beim Bankzugang belegt.
+Prüfidee: Zuweisung oberhalb der offenen Forderung oder des Eingangs wird abgelehnt; Bankabruf ohne Freigabe schlägt fehl; Bankkonfiguration ist nicht im Klartext lesbar.
+Tracelinks: StRS-7; StRS-3; StRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zuweisungsgrenze und geschützter Bankzugang sind abrechnungsrelevant und belastbar.
+Status: belegt
+
+ID: StRS-9
+Titel: SEPA-Mandatsverwaltung mit Gültigkeit und Löschschutz
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Buchhaltung (Rolle); System
+Vorbedingung: Kunde mit Mandat; Lastschriften können aktiv sein
+Fakt: Bankverbindungen/Mandate rechtegeschützt mit Mandats-Gültigkeitsfenster und Löschschutz bei aktiven Lastschriften (M001); FIBU-Export/-Import führt SEPA-Mandatsfortschreibung mit harten Vorbedingungen durch (M019).
+Aussage: Das System soll Mandate nur innerhalb ihres Gültigkeitsfensters nutzen, Mandatsänderungen fortschreiben und Mandate nicht löschen, solange Lastschriften darauf laufen; Verwaltung nur für berechtigte Rollen.
+Ergebnis: Abgelaufene/widerrufene Mandate erzeugen keine Lastschriften; aktive Bezüge verhindern Löschung.
+Belege:
+  - [PRIMÄR] M001 (BankAccountBL.SaveBankAccount mit CheckRightsFromUser; DeleteBankAccount: DependencyCheckFailed bei aktiven Lastschriften; GetBankAccountsFromCustomer: Gültigkeitsfenster) - Begründung: Schutzregeln am Mandat sind durchgesetzt.
+  - [PRIMÄR] M019 (PaymentTransactionBL.RefreshBankInformation: Mandatstyp/Gültigkeit nach Export) - Begründung: Fortschreibung nur regelkonform.
+Prüfidee: Lastschrift auf ein Mandat außerhalb des Gültigkeitsfensters wird abgelehnt; Löschversuch bei aktiver Lastschrift scheitert; ohne Mandatsrecht ist keine Änderung möglich.
+Tracelinks: StRS-8; StRS-11
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Mandatsregeln sind zahlungsverkehrsrechtlich zwingend.
+Status: belegt
+
+ID: StRS-10
+Titel: Mahnprozess mit tagesgenauem Mahnstopp
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Buchhaltung (Rolle); System
+Vorbedingung: Offene Forderungen; Mahnlauf geplant
+Fakt: Mahnstopp je Kunde und je Rechnung, tagesgenau, rechtegeprüft (M110).
+Aussage: Das System soll für Kunden und einzelne Rechnungen einen befristeten Mahnstopp führen und Mahnungen nur durch berechtigte Benutzer auslösen; der Stopp wirkt zum genauen Datum.
+Ergebnis: Gesperrte Kunden/Rechnungen erhalten im Stoppzeitraum keine Mahnung; Mahnstopp nur mit Recht änderbar.
+Belege:
+  - [PRIMÄR] M110 (DunningStopViewModel.GetUpdatedIsDunningStopActive Z.213; CanAccept Z.164 mit HasEditDunningstopRight) - Begründung: Stopp- und Rechteprüfung sind durchgesetzt.
+Prüfidee: Mahnlauf am Stoppdatum lässt gesperrte Positionen aus; Benutzer ohne Mahnrecht kann den Stopp weder setzen noch umgehen.
+Tracelinks: StRS-2; StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - tagesgenaue Stopps sind kundenerhaltend und präzise.
+Status: belegt
+
+ID: StRS-11
+Titel: Finanzbuchhaltungs-Export und -Import nur nach Vorprüfung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Buchhaltung (Rolle); System
+Vorbedingung: Belege sind gebucht; Zielsystem/Format bestimmt
+Fakt: FIBU-Export/-Import mit harten Vorbedingungen und SEPA-Mandatsfortschreibung (M019); Exportmaske erzwingt Vorab-Laden, Formate im Code hinterlegt (M114).
+Aussage: Das System soll Finanzbuchhaltungs-Exporte und -Importe nur ausführen, wenn alle Vorbedingungen (u. a. vollständiges Vorab-Laden der Belege) erfüllt sind; ungeprüfte Datenmengen werden nicht übertragen.
+Ergebnis: Nur vollständig geladene und geprüfte Belegmengen gehen in Export/Import; abgebrochene Läufe hinterlassen keine Teilübertragung.
+Belege:
+  - [PRIMÄR] M114 (BookKeepingExportDataCustomerReceiptsViewModel.ExportData Z.208: ExportDataPreview-Pflicht) - Begründung: Vorbedingung ist erzwungen.
+  - [PRIMÄR] M019 (BookKeepingImportBL.CheckMandatoryColumnKinds/StartImport mit Trigger-Handling in Transaktion) - Begründung: Vorbedingungen blockieren inkonsistente Läufe.
+Prüfidee: Export ohne vorheriges Laden bzw. mit verletzter Vorbedingung wird abgelehnt; Abbruch erzeugt keine Teilübertragung.
+Tracelinks: StRS-7; StRS-9
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Vorbedingungsprinzip belastbar; im Code festgelegte Formate bei Neuimplementierung konfigurierbar denken.
+Status: belegt
+
+ID: StRS-12
+Titel: [HYPOTHESE] Gutschein-Lebenszyklus mit verbindlicher Einlösung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Vertrieb/Kasse (Rolle); System
+Vorbedingung: Gutschein liegt in einem Status (frei/aktiviert/eingelöst) vor
+Fakt: Gutscheinstatus frei/aktiviert/eingelöst über Belegrückverweise; die Durchsetzungsstelle der Einlösung ist nicht lokalisiert (M083).
+Aussage: Das System soll Gutscheine nur einmal und nur im Zustand „aktiviert" einlösbar machen; jede Einlösung ist über Rückverweise auf den auslösenden Vorgang nachvollziehbar.
+Ergebnis: Doppelte Einlösung und Einlösung nicht aktivierter Gutscheine werden verhindert; Einlösungen sind vorgangsbezogen nachvollziehbar.
+Belege:
+  - [SEKUNDÄR] M083 (VoucherManagementBL.GetActivedVoucherBarcodes; NamedQuery VoucherManagementGetVoucherArticles) - Begründung: Statusmodell belegt, Durchsetzung offen.
+  - [KONTEXT] M083 (keine schreibende Einlöse-/Aktivierungslogik im Modul auffindbar) - Begründung: Beleglage lückenhaft, Hypothese nötig.
+Prüfidee: Zweiter Einlösversuch desselben Gutscheins und Einlösung eines nicht aktivierten Gutscheins werden abgelehnt; jede Einlösung verweist auf ihren Vorgang.
+Tracelinks: StRS-7; StRS-8
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Statusmodell übernehmen; verbindliche Einlösungsdurchsetzung muss in der Neuimplementierung erst garantiert werden.
+Status: HYPOTHESE
+
+ID: StRS-13
+Titel: Massenänderung ohne Eingriff in fertiggestellte Verkaufsbelege
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Vertrieb/Backoffice (Rolle); System
+Vorbedingung: Massenänderung auf eine Belegauswahl angestoßen
+Fakt: Massenupdate nur für aktive Belege, niemals für Rechnungen/Gutschriften im Verkaufsfall, mit Protokollierung (M040).
+Aussage: Das System soll Massenänderungen auf aktive Belege beschränken und fertiggestellte Rechnungen und Gutschriften niemals massenweise verändern; jede Massenänderung ist protokolliert.
+Ergebnis: Abgeschlossene Verkaufsbelege bleiben massenänderungsfest; Auswirkungen jeder Massenaktion sind nachvollziehbar.
+Belege:
+  - [PRIMÄR] M040 (MassUpdateBL.StartReceiptPriceUpdate Z.259/272: nur ReceiptState.Active, ObjectKind InvoiceClass/CreditVoucherClass ausgeschlossen) - Begründung: Ausschluss und Protokollierung sind durchgesetzt.
+Prüfidee: Massenlauf über eine Auswahl mit Rechnungen/Gutschriften ändert diese nicht und wird protokolliert; nur aktive Belege ändern sich.
+Tracelinks: StRS-7; StRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schutz fertiger Verkaufsbelege ist abrechnungskritisch.
+Status: belegt
+
+ID: StRS-14
+Titel: E-Rechnungen nur nach inhaltsseitiger Prüfung übermitteln
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Fakturierung (Rolle); System
+Vorbedingung: Rechnung ist fertiggestellt; E-Rechnungsformat ist bestimmt
+Fakt: ebInterface 4.3 als E-Rechnungsformat mit Validierung von Umsatzsteuer-IDs und Reverse-Charge-Fällen (M094).
+Aussage: Das System soll ausgehende E-Rechnungen vor Übermittlung automatisch auf Umsatzsteuerkennzeichnung und Reverse-Charge-Besonderheiten prüfen und nur konforme Rechnungen übermitteln.
+Ergebnis: Nicht konforme Rechnungen werden zur Korrektur zurückgewiesen; übermittelte E-Rechnungen erfüllen das vereinbarte Format.
+Belege:
+  - [PRIMÄR] M094 (EbInterfaceLogic.ValidateValues Z.303-341; DoCreateTaxNode Z.207-221) - Begründung: Prüfpflicht vor Versand ist implementiert.
+Prüfidee: Rechnung mit fehlerhafter/fehlender USt-ID oder unklarem Reverse-Charge-Fall wird beim Erzeugen des E-Rechnungsformats abgelehnt; konforme Rechnung wird übermittelt.
+Tracelinks: StRS-7; StRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Validierung vor Versand bleibt Pflicht; Formatversion ist je Zielmarkt anzupassen.
+Status: belegt
+
+ID: StRS-15
+Titel: Externe Kunden-Vorgänge prüfgesichert, befristet und regelkonform zuordnen
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Kunde (extern); System
+Vorbedingung: Kunde erhält Link/Formular; Unterschrifts- oder SEPA-Vorgang offen
+Fakt: Externe Dokumentensignierung/SEPA mit Pflichtprüfung, WebCart mit serverseitigen Sonderpreisen, öffentliche Webformulare nach Muster+Rechten (M125); SelfCare-Webformulare mit befristeten Links, Default 7 Tage (M062); Mail-Empfang mit Domänen-Blacklist zum Schutz der Kundenerkennung (M037); Weblinks lösen CRM-Aktivitäten beim Berater aus, DSGVO-Default-User (M085).
+Aussage: Das System soll externe Kunden-Vorgänge (Formulare, Signierung, SEPA, Warenkorb) nur nach Pflichtprüfung, über zeitlich befristete und rechtesteuerbare Zugänge abwickeln; eingehende Kommunikation darf Kunden nur regel- und datenschutzkonform zugeordnet werden.
+Ergebnis: Externe Vorgänge laufen prüfgesichert und befristet; die Kundenzuordnung bleibt regelkonform und datenschutzgerecht.
+Belege:
+  - [PRIMÄR] M125 (DocumentSigningPage.razor CanAccept/IsValidIban; PublicWebFormPage.razor: TicketPattern.IsPublic && IsActive) - Begründung: Prüfpflicht bei externen Wertvorgängen ist verankert.
+  - [PRIMÄR] M062 (SelfCareBL.GetWebFormByGuid Z.307-326: Link-Expiration, Default 7 Tage) - Begründung: zeitliche Begrenzung ist durchgesetzt.
+  - [PRIMÄR] M037 (DomainBlacklistBL.IsBlacklisted; ContactPersonBL.SearchAddressContactByEmailAddress) - Begründung: Zuordnungsregel ist implementiert.
+  - [SEKUNDÄR] M085 (WebLinkBL.SaveWebLinkClick mit DSGVO-Default-User) - Begründung: datenschutzkonforme Zuordnung belegt.
+Prüfidee: Abgelaufener Formularlink wird abgelehnt; SEPA-/Signaturvorgang ohne bestandene Pflichtprüfung wird nicht abgeschlossen; Mail aus gesperrter Domäne erzeugt keine automatische Kundenzuordnung.
+Tracelinks: StRS-6; StRS-22
+Konsolidierung: Kandidat: M125, M062, M037, M085 zu einer Regel für externe Kundenkanäle zusammengeführt
+Übernahmewürdigkeit: übernehmen - Pflichtprüfung, Befristung und regelkonforme Zuordnung sind DSGVO- und abrechnungsrelevant.
+Status: belegt
+
+ID: StRS-16
+Titel: Ticketabschluss nur mit zentraler Freigabe und ohne offene Zeiten
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Supporter (Rolle); System
+Vorbedingung: Ticket in Bearbeitung; Zeiten erfasst
+Fakt: Ticketabschluss nur mit Serverfreigabe, ohne offene Zeiten, mit Sperrenlogik; Status-Defaults löschgeschützt (M113).
+Aussage: Das System soll den Abschluss eines Tickets nur zentral freigeben, wenn keine offenen Zeiten mehr vorhanden sind, und gleichzeitige Bearbeitungen sperren; Abschlusszustände sind löschgeschützt.
+Ergebnis: Tickets schließen nur in vollständig erfasstem, unstrittigem Zustand; gleichzeitig bearbeitete Tickets kollidieren nicht.
+Belege:
+  - [PRIMÄR] M113 (CloseHelpdeskHelper.CloseHelpdesk Z.28-139: CanClose-Serverprüfung, nonCalculatedTimers>0 → Abbruch; TicketLogicHelper.GetTicketAndPromptUnlock) - Begründung: Abschlussregeln sind serverseitig durchgesetzt.
+Prüfidee: Abschlussversuch mit offener Zeit wird abgelehnt; gleichzeitiger Abschluss durch zwei Benutzer führt zu genau einem Abschluss; Abschlusszustand lässt sich nicht löschen.
+Tracelinks: StRS-7; StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Abschlussfreigabe sichert abrechnungsrelevante Zeiterfassung.
+Status: belegt
+
+ID: StRS-17
+Titel: Automatische Ticketerstellung nur mit Lizenz und Recht
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: System (automatische Erstellung); Administrator (Konfiguration)
+Vorbedingung: Automatisierungsquelle vorhanden; Ticketprojekt eingerichtet
+Fakt: Automatische Ticketerstellung braucht ServiceBoard-Lizenz UND Recht, Serientask-Lebenszyklus (M071); Ticketprojekte mit Nummernkreis, Soft-Delete (M074).
+Aussage: Das System soll Tickets automatisch nur erzeugen, wenn Lizenz und besonderes Recht vorliegen; jedes Ticket entsteht in einem Projekt mit eindeutiger Nummer, gelöschte Projekte bleiben rekonstruierbar.
+Ergebnis: Keine automatischen Tickets ohne Berechtigung/Lizenz; Nummern bleiben projektbezogen eindeutig.
+Belege:
+  - [PRIMÄR] M071 (TaskManagementHelpdeskActionHandler.Execute Z.50-58: HasLicense + ADD_NEW_HELPDESK) - Begründung: Doppelbedingung ist durchgesetzt.
+  - [PRIMÄR] M074 (TicketProjectBL.SaveOrUpdateTicketProject: Nummernkreis; DeleteTicketProjectTask: Soft-Delete) - Begründung: eindeutige Nummern und rekonstruierbare Projekte.
+Prüfidee: Ohne Recht bzw. ohne Lizenz entsteht kein automatisches Ticket; erzeugte Tickets tragen projekt-eindeutige Nummern.
+Tracelinks: StRS-2; StRS-25; StRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Doppelbedingung Lizenz+Recht verhindert unbefugte Massenerstellung.
+Status: belegt
+
+ID: StRS-18
+Titel: RMA-Prozess mit Lagerbindung und richtungsgebundenen Schritten
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Support/Lager (Rolle); System
+Vorbedingung: Rückgabe/Reklamation vorliegt; Lager zugeordnet
+Fakt: RMA mit Lagerbindung, aktionstypabhängigen Pflichten und Einbahnstraßen-Sperren (M124); Lagermodell enthält 4 RMA-Lager und Filial-Vorgabelager (M036).
+Aussage: Das System soll Rückgaben lagergebunden führen, Pflichtangaben vom Aktionstyp abhängig machen und Bearbeitungsschritte nur in der vorgesehenen Richtung zulassen.
+Ergebnis: RMAs sind jederzeit lagerbezogen nachvollziehbar; Fehlreihenfolgen und Pflichtverletzungen werden abgelehnt.
+Belege:
+  - [PRIMÄR] M124 (RmaOverviewViewModel.NewRma Z.86-126; SendForthViewModel.CheckForthState Z.337-409 und Z.626-629) - Begründung: Prozessrichtung und Pflichten sind durchgesetzt.
+  - [SEKUNDÄR] M036 (StockBL.LoadOpenWarehouses: vier RMA-Lager ausgeschlossen) - Begründung: Lagerkontext für RMA belegt.
+Prüfidee: RMA-Schritt gegen die vorgesehene Richtung wird abgelehnt; Aktionstyp ohne erfüllte Pflichtangaben ist nicht speicherbar; Bestand bewegt sich nur über zugeordnete (RMA-)Lager.
+Tracelinks: StRS-16; StRS-21
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - richtungsgebundene Rückgabeprozesse verhindern Bestandsfehler.
+Status: belegt
+
+ID: StRS-19
+Titel: Löschschutz für verwendete Stammdaten und nachvollziehbare Löschung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Stammdatenpflege (Rolle); System
+Vorbedingung: Stammdatum existiert; Verwendungen möglich (Posten, Tickets, Verträge, Belege)
+Fakt: Adressstamm rechtegeprüft mit Löschschutz bei offenen Posten/Tickets/Verträgen (M002); Geräte-Soft-Delete mit Protokoll (M020); Checklisten mit Pflichtfeldern, beidseitiger Kaskade, Soft-Delete inkl. Log (M013); Fix-Kategorien löschgeschützt (M035).
+Aussage: Das System soll Stammdaten nicht endgültig löschen, solange sie geschäftlich in Verwendung sind; Löschung erfolgt als rekonstruierbare, protokollierte Entfernung, feste Referenzkataloge bleiben löschgeschützt.
+Ergebnis: Keine verwaisten Geschäftsvorfälle; Löschungen sind protokolliert und rekonstruierbar.
+Belege:
+  - [PRIMÄR] M002 (AccountBL.DeleteAccount Z.752-803: Abbruch bei OPOS/Helpdesk/Verträgen) - Begründung: Löschschutz ist durchgesetzt.
+  - [PRIMÄR] M013 (CentronChecklistBL.DeleteCentronChecklist: IsActive=false; CentronChecklistLogs) - Begründung: protokollierte, rekonstruierbare Löschung.
+  - [PRIMÄR] M020 (AccountDeviceBL.DeleteAccountDevice: IsDeleted + Log) - Begründung: gleiche Löschsemantik für Geräte.
+  - [PRIMÄR] M035 (ChecklistVirtualObjectCategoryBL.DeleteChecklistVirtualCategory: IsFix-Sperre) - Begründung: Systemkataloge bleiben erhalten.
+Prüfidee: Löschversuch einer Adresse mit offenen Posten/Tickets/Verträgen wird abgelehnt; zulässige Löschung erzeugt einen Logeintrag und bleibt wiederherstellbar; Fix-Kategorie ist nicht löschbar.
+Tracelinks: StRS-20; StRS-2
+Konsolidierung: Kandidat: M002, M013, M020, M035 als gemeinsame Löschsemantik zusammengeführt
+Übernahmewürdigkeit: übernehmen - einheitliche Löschsemantik verhindert Datenverlust in laufenden Vorfällen.
+Status: belegt
+
+ID: StRS-20
+Titel: Eindeutige Identifikation, Nummernvergabe und verlässliche Referenzdaten
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Stammdatenpflege/Vertrieb (Rolle); System
+Vorbedingung: Neues Objekt (Adresse, Ticket, Kunde/Lieferant) wird angelegt; Fremdreferenz oder Tag wird erfasst
+Fakt: Adressstamm mit automatischer Nummernvergabe (M002); Fremdreferenzen eindeutig (M048); Tags case-insensitive, Dedup nur im Code (M069); Unique-Nummern für Kunden/Lieferanten (M131); Ticketprojekte mit Nummernkreis (M074); Länder/Währung mit EZB-Kursversorgung (M015).
+Aussage: Das System soll Geschäftsobjekte über eindeutige, systemvergebene Nummern identifizieren, Fremdreferenzen nur einmal je Ziel zulassen und Dubletten bei Tags verhindern; Währungsreferenzkurse stammen aus einer autoritativen Quelle.
+Ergebnis: Jedes Objekt ist eindeutig adressierbar; keine doppelten Fremdverweise oder Tag-Dubletten; Kursdaten sind herkunftsgesichert.
+Belege:
+  - [PRIMÄR] M002 (AccountBL.GetNewAccount: GetNextNumber(NumberGroupEnum.Account); Schema IX_AccountCustomers_UniqueNumber) - Begründung: Nummernvergabe ist systemseitig durchgesetzt.
+  - [PRIMÄR] M048 (ObjectExternalReferenceBL.CreateReference: Dublettenprüfung) - Begründung: Eindeutigkeit ist erzwungen.
+  - [SEKUNDÄR] M069 (TagsBL.GetTag/AddTag; kein Unique-Index auf dbo.Tags) - Begründung: Verhalten belegt, Durchsetzung nur im Code (Schwäche).
+  - [SEKUNDÄR] M015 (CountryBL.UpdateCurrencyRateByRateDictionary: EZB-URL) - Begründung: autoritative Kursquelle belegt.
+Prüfidee: Zwei Neuanlagen erhalten unterschiedliche Nummern; dieselbe Fremdreferenz ist nicht zweimal speicherbar; „kunde" und „Kunde" führen zu einem Tag; Kursabruf weist EZB-Herkunft aus.
+Tracelinks: StRS-19; StRS-17
+Konsolidierung: Kandidat: M002, M048, M069, M131, M015 als Identifikations-/Referenzregel zusammengeführt
+Übernahmewürdigkeit: übernehmen - eindeutige Nummern sind Integrationsgrundlage; Dublettenerkennung „nur Code" (M069) ist systemseitig zu ersetzen.
+Status: belegt
+
+ID: StRS-21
+Titel: Beschaffung von Bedarfsermittlung bis Einkaufspreisfortschreibung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Einkauf (Rolle); System
+Vorbedingung: Bedarfs-/Bestandsdaten und Lieferantenvorgaben vorhanden
+Fakt: Bestellvorschlag aus Bedarf−Bestand+Zulauf, SV-Preisablauf, Filial-Export (M056); Filial-Vorgabelager (M036); elektronische Bestellungen (EDI) erzwingen Kreditorcodes/Restmengen mit Format-Routing (M023); Bestellmenge, Mindestbestellmenge nur Warnung, EDI-Abgleich mit Toleranz 0,005 (M117); EK-Fortschreibung fix/letzter/mischt, Doppelbuchungsschutz, Aufschlagstabellen (M084).
+Aussage: Das System soll Beschaffungsbedarf zu prüffähigen Bestellvorschlägen verdichten, elektronisch übermittelte Bestellungen nur mit vollständigen Lieferantenvorgaben ausführen und Einkaufspreise nach gewählter Strategie fortschreiben; Doppelbuchungen werden ausgeschlossen.
+Ergebnis: Vorschläge decken den Bedarf ab; unvollständige Bestellübermittlungen werden abgelehnt; EK-Preise folgen nachvollziehbar der Strategie ohne Doppelbuchungen.
+Belege:
+  - [PRIMÄR] M023 (AlltronOrderBL.BuildOrderBody: Kreditorcode-Pflicht; EDIDispatcherBL.CreateEDISuggestionOrderAsync) - Begründung: Vollständigkeitszwang ist durchgesetzt.
+  - [PRIMÄR] M084 (ArticleStockBL.UpdateArticlePurchasePrice; ArticleLogBL.WriteAmountChangeLog: Doppelbuchungsschutz) - Begründung: Preisstrategie und Schutz sind implementiert.
+  - [SEKUNDÄR] M056 (OrderSuggestionListBL._sqlArticle) - Begründung: Vorschlagslogik belegt.
+  - [SEKUNDÄR] M117 (EDIInvoiceViewModel.GetItemsToUpdate: Toleranz 0,005) - Begründung: Toleranzverhalten belegt.
+Prüfidee: Vorschlag entspricht Bedarf−Bestand+Zulauf; Bestellübermittlung ohne Kreditorcode wird abgelehnt; Doppelbuchung desselben Wareneingangs wird verhindert; Abweichung über 0,005 fällt im Abgleich auf.
+Tracelinks: StRS-18; StRS-22
+Konsolidierung: Kandidat: M056, M023, M117, M084, M036 als Beschaffungsregel zusammengeführt
+Übernahmewürdigkeit: übernehmen - Kernbeschaffung belastbar; „Mindestmenge nur Warnung" (M117) und EK-Strategie „mischt" (M084) sind bewusst zu prüfen.
+Status: belegt
+
+ID: StRS-22
+Titel: Kanalübergreifend gültige Verkaufspreise
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Vertrieb/Preispflege (Rolle); System
+Vorbedingung: Aktions-/Sonderpreis definiert; Verkaufsvorgang (Maske oder Web) läuft
+Fakt: Aktionspreise mit Pflichtangaben nur in der Maske geprüft, Kommissionier-Kappung, SN-Scan unvollständig (M111); WebCart rechnet Sonderpreise serverseitig (M125).
+Aussage: Das System soll Preisregeln für Aktions- und Sonderpreise unabhängig vom Verkaufskanal einheitlich und zentral durchsetzen; Preisangaben dürfen nicht nur in einer einzelnen Eingabemaske geprüft werden.
+Ergebnis: Derselbe Preis gilt in Desktop und Web; maskenbasierte Umgehungen sind ausgeschlossen.
+Belege:
+  - [PRIMÄR] M125 (WebCartShopPage.razor: CalculatedPrice vom Webservice) - Begründung: zentrale Preisdurchsetzung im Web ist belegt.
+  - [PRIMÄR] M111 (AddActionPriceViewModel.Ok: Pflichtprüfung ausschließlich in der Maske; ActionPriceBL nur CRUD) - Begründung: beobachtete Durchsetzungslücke als Zielableitung.
+Prüfidee: Derselbe Artikel mit Aktion zeigt in Desktop-Maske und Web-Warenkorb denselben Preis; eine gegen die Aktionsregel verstoßende Preiseingabe wird auch ohne Maske abgelehnt.
+Tracelinks: StRS-21; StRS-15; StRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - heutige Prüfung nur in der Maske (M111) ist eine Lücke; Ziel ist kanalübergreifende zentrale Durchsetzung.
+Status: belegt
+
+ID: StRS-23
+Titel: Vollständige Kommissionier- und Seriennummernerfassung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Lager/Kommissionierung (Rolle); System
+Vorbedingung: Auftrag zur Kommissionierung freigegeben; serielle Artikel enthalten
+Fakt: Kommissionier-Kappung und unvollständige SN-Scan-Maske als Beobachtung (M111).
+Aussage: Das System soll Entnahmemengen nicht stillschweigend unter den bestätigten Mengen kappen und Seriennummern bei der Kommissionierung vollständig erfassen.
+Ergebnis: Kommissionierte Mengen und Seriennummern entsprechen vollständig den Auftragsangaben; Abweichungen werden sichtbar gemacht.
+Belege:
+  - [PRIMÄR] M111 (PositionViewModel.Done-Setter: value > Amount → Kappung; SNscannViewModel.ScannBarcode: NotImplementedException) - Begründung: implementiertes (mangelhaftes) Verhalten als Beobachtung.
+Prüfidee: Auftrag mit 10 Stück Serienartikel verlangt 10 erfasste Seriennummern; weniger Scans blockieren die Übergabe; eine Kappung erzeugt einen sichtbaren Abweichungshinweis statt stiller Anpassung.
+Tracelinks: StRS-21; StRS-18
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - Kappung und unvollständige SN-Scan-Maske (M111) sind Mängel; Neuimplementierung soll vollständige Erfassung erzwingen.
+Status: belegt
+
+ID: StRS-24
+Titel: Externe Dienste authentifiziert, limitiert und kundenkontextbezogen einbinden
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: System (Integrationen); Administration
+Vorbedingung: Partnerdienst (Versand, Daten, Finanz, Fernwartung) ist beauftragt; Zugangsdaten liegen verschlüsselt vor
+Fakt: GLS Basic-Auth, Limits 50 Referenzen/30 Pakete (M095); Shipcloud API-Key (M096); COP SOAP mit Credentials im Body (M097); Egis HTML-escaped Credentials im TransactionHeader (M098); FinAPI OAuth2 mit Token-Gate (M099); Icecat Basic-Auth (M100); ITscope Basic „AccountId§Mail:ApiKey", Limit 50/Request (M101); docuFORM OAuth2+PKCE mit Zählerständen (M140); RiverDivo RMM mit timing-sicherem Access-Key, Web-Konten nur eigener Kunde (M059); TradePool XML-Schema-Zwang, Salted-Hash-Login (M078).
+Aussage: Das System soll externe Dienste nur über deren vorgesehene, authentifizierte Anbindungen einbinden, deren Mengenlimits einhalten und Fernwartungszugriffe auf den jeweiligen Kunden beschränken.
+Ergebnis: Partneraufrufe laufen authentifiziert und limitiert; Fernwartung greift nur auf den eigenen Kunden zu; Form-/Schemaverstöße werden abgelehnt.
+Belege:
+  - [PRIMÄR] M099 (RestClientBase.GetJsonWebToken/SendRequestWithAccessToken: Token-Gate) - Begründung: Zugang nur mit gültigem Token durchgesetzt.
+  - [PRIMÄR] M059 (RiverDivoBL.ValidateRmmAccessKey: FixedTimeEquals; RiverConnectionBL: Web-Konten nur eigener Kunde) - Begründung: Beschränkung auf den Kundenkontext ist durchgesetzt.
+  - [PRIMÄR] M101 (ITscopeApi.GetUsernameForAuth; Limit 50/Request) - Begründung: Anmeldeschema und Mengenlimit belegt.
+  - [PRIMÄR] M095 (CentronGlsLogic.DoValidateShipment: Limits) - Begründung: Mengenlimits sind festgelegt.
+Prüfidee: Aufruf ohne gültige Zugangsdaten/Token wird abgelehnt; Limitüberschreitung (z. B. 31 Pakete, 51 Referenzen) wird verhindert; Fernwartungskonto eines Kunden erreicht keine Daten fremder Kunden.
+Tracelinks: StRS-3; StRS-6
+Konsolidierung: Kandidat: M095-M101, M140, M059, M078 als gemeinsames Anbindungsmuster zusammengeführt
+Übernahmewürdigkeit: übernehmen - Muster (Auth, Limits, Kundenkontext) fortführen; Credentials im Body (M097) bzw. escaped (M098) sind je Partner neu zu bewerten.
+Status: belegt
+
+ID: StRS-25
+Titel: Funktionsumfang folgt der erworbenen Lizenz
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Lizenznehmer/Kunde; Administrator; System
+Vorbedingung: Lizenzumfang ist definiert; Module installiert
+Fakt: Modulsichtbarkeit = Rechte UND Lizenz, Centron-Vollizenz als Fallback mit Ausnahmen (MSP/PasswordManager/Produktion/AI/PLM), Settings ebenfalls gefiltert (M108); Produktion lizenzgebunden (M053); ServiceBoard-Lizenzbedingung (M071); Export-Lizenzbedingung im Passwort-Manager (M051); MyCentron lizenzoffen für alle (M115).
+Aussage: Das System soll den verfügbaren Funktionsumfang aus der erworbenen Lizenz ableiten und lizenzlose Funktionen weder anbieten noch ausführen; Ausnahmen sind bewusst definiert.
+Ergebnis: Nutzer sehen und erreichen nur lizenzierte Funktionen; Lizenzüberschreitungen werden abgelehnt.
+Belege:
+  - [PRIMÄR] M108 (ModuleRegistrationItem.CheckModuleFeatures: HasLicense(LicenseGuids.X) || HasLicense(LicenseGuids.Centron); GetSettingsWithoutModule) - Begründung: Lizenzfilter ist durchgesetzt.
+  - [PRIMÄR] M053 (ProductionOrderBL/ProductionBL: Lizenz-Gate vor jedem Get/Save) - Begründung: Modulzugang ohne Lizenz verweigert.
+  - [PRIMÄR] M071 (TaskManagementHelpdeskActionHandler: ServiceBoard-Lizenz) - Begründung: Lizenzbedingung am Feature.
+  - [PRIMÄR] M115 (ModuleRegistration Z.774-792: MyCentron mit NoRightCheck, nur Lizenz) - Begründung: bewusste Ausnahme dokumentiert.
+Prüfidee: Benutzer ohne entsprechende Lizenz sieht das Modul nicht und erhält beim Direktaufruf eine Ablehnung; MyCentron bleibt ohne Zusatzlizenz erreichbar.
+Tracelinks: StRS-2; StRS-17; StRS-5
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zentralregel gilt; Lizenzausnahmen (MSP/PasswordManager/Produktion/AI/PLM, MyCentron) als Sonderfälle mitführen.
+Status: belegt
+
+ID: StRS-26
+Titel: Verpflichtender Tagesabschluss mit automatischer Vertretung
+Ebene: StRS
+Typ: funktional
+Qualitätsmerkmal: -
+Akteur: Außendienst/Service (Rolle); System
+Vorbedingung: Arbeitstag im Tageskalender erfasst; Abwesenheit (Urlaub/Krankheit) gemeldet
+Fakt: MyDay erzwingt den Tagesabschluss; bei Urlaub/Krankheit schließt der Systemuser den Tag automatisch ab (M044); die in M024 enthaltene alte Urlaubslogik ist stillgelegt/veraltet.
+Aussage: Das System soll Arbeitstage verpflichtend abschließen und bei gemeldeter Abwesenheit den Abschluss automatisch im Namen des Systems vornehmen, damit keine Tage offen bleiben.
+Ergebnis: Kein dauerhaft offener Arbeitstag; abwesende Mitarbeiter erhalten systemverantwortete Abschlüsse.
+Belege:
+  - [PRIMÄR] M044 (MyDayNotificationsBL.GetDayNotifiedNotifications: Auto-Finalisierung mit Systemuser) - Begründung: Abschlusspflicht und Vertretung sind durchgesetzt.
+  - [KONTEXT] M024 (EmployeeHolidayBL: obsolete, Markierung im Code) - Begründung: belegt nur, dass die alte Urlaubslogik nicht fortgeführt wird.
+Prüfidee: Ein offener Tag ohne Benutzerabschluss wird zum Stichtag automatisch geschlossen (bei Abwesenheit durch den Systemuser); ohne Abwesenheit blockiert/erinnert das System bis zum Abschluss.
+Tracelinks: StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Abschlusspflicht mit Vertretung sichert Auswertungs- und Abrechnungsbasis; die alte Urlaubslogik (M024) ist veraltet und wird nicht übernommen.
+Status: belegt
+
+ID: StRS-27
+Titel: Mehrfache Bereitstellungsart für Betrieb und Auslieferung
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit)
+Akteur: Betrieb/IT-Dienstleister
+Vorbedingung: Zielsystem (Windows-Server oder Containerplattform) verfügbar
+Fakt: MSI-Installer, Nexus läuft als Windows-Dienst (M133); Docker-Setup mit DB+Webservice+SMTP+Nexus inkl. ACR (M134).
+Aussage: Das System soll sowohl klassisch installierbar (als Dienst) als auch containerisiert bereitstellbar sein, damit Kundenbetrieb und Entwicklungsumgebung aus derselben Auslieferung entstehen.
+Ergebnis: Installation per Installer bzw. Container-Stack ist wiederholbar durchführbar.
+Belege:
+  - [PRIMÄR] M133 (WixSharpInstaller/Program.cs: ServiceInstaller Name=CentronNexus, Start auto) - Begründung: klassische Bereitstellungsart ist etabliert.
+  - [SEKUNDÄR] M134 (docker/compose/compose.yaml: Stack db, webservice, smtp, nexus) - Begründung: containerisierte Bereitstellung ist etabliert.
+Prüfidee: Auf einem leeren Zielsystem gelingt die Installation sowohl per MSI/Dienst als auch per Container-Stack; beide Varianten starten und sind erreichbar.
+Tracelinks: StRS-28; StRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - beide Bereitstellungsarten für den SaaS-Mandantenbetrieb weiterentwickeln.
+Status: belegt
+
+ID: StRS-28
+Titel: Kontrolliertes Fehlerverhalten und blockadefreier Betrieb
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: System (Host/Dienste)
+Vorbedingung: Dienst/Konsole startet; Nebensysteme (Telemetrie, Caches) laufen
+Fakt: Konsolen-/Dienststart mit Selbstbeendigung bei Fehlern (M104/M105); Telemetrie deadlock-sicher (M072).
+Aussage: Das System soll bei Startfehlern kontrolliert und nachvollziehbar beenden statt in inkonsistentem Zustand weiterzulaufen; Nebensysteme dürfen den Hauptbetrieb nicht blockieren.
+Ergebnis: Fehlstarts hinterlassen keine „halben" Dienste; Störungen in Nebensystemen beeinträchtigen Kernfunktionen nicht.
+Belege:
+  - [PRIMÄR] M105 (CentronService.OnStart: Startfehler → this.Stop()) - Begründung: kontrollierte Beendigung ist implementiert.
+  - [PRIMÄR] M072 (TelemetryBL.UpsertApiCallBatch: ExecuteWithDeadlockRetry) - Begründung: Nebensystem blockiert nicht.
+Prüfidee: Ein erzwungener Startfehler führt zu sauberer Beendigung mit Fehlermeldung; eine Telemetriestörung verlangsamt oder blockiert Kernfunktionen nicht messbar.
+Tracelinks: StRS-27
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - „Fail fast" und Entkopplung von Nebensystemen für den SaaS-Betrieb fortführen.
+Status: belegt
+
+ID: StRS-29
+Titel: Automatisierte Qualitätssicherung vor jeder Freigabe
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Wartbarkeit (Modifizierbarkeit)
+Akteur: Entwicklungsteam/CI-System
+Vorbedingung: Änderung ist eingecheckt
+Fakt: Tests Unit/Integration/E2E/Playwright (M132); CI mit Build, Unit-, Regression- und Playwright-Matrix (M135-M137); täglicher CodeQL-Scan (M138); Docker/ACR als Testträger (M134).
+Aussage: Das System (Entwicklungsprozess) soll jede Änderung vor Freigabe automatisiert bauen, in allen Teststufen prüfen und täglich auf Sicherheitsschwachstellen untersuchen; nicht bestandene Läufe blockieren die Freigabe.
+Ergebnis: Freigaben erfolgen nur nach bestandenem automatisiertem Nachweis; Sicherheitsbefunde werden täglich sichtbar.
+Belege:
+  - [PRIMÄR] M135 (Centron.Scripts/Program.cs: Target-Kette build inkl. end-to-end-tests) - Begründung: Prüfstufen sind automatisiert verankert.
+  - [PRIMÄR] M137 (security-pipeline.yaml: cron, CodeQL-Init/Analyze) - Begründung: Sicherheitsprüfung ist täglich terminiert.
+  - [SEKUNDÄR] M132 (tests-Baum: 8 Testprojekte inkl. Playwright) - Begründung: Teststufenbestand belegt.
+Prüfidee: Ein Check-in mit fehlgeschlagenem Test oder CodeQL-Befund blockiert die Freigabe; ein vollständiger Lauf erzeugt das Freigabeartefakt.
+Tracelinks: StRS-27; StRS-3
+Konsolidierung: Kandidat: M132, M135, M136, M137, M138 zu einer QS-Regel zusammengeführt
+Übernahmewürdigkeit: übernehmen - automatisierte QS ist Voraussetzung für belastbare SaaS-Releases.
+Status: belegt
+
+ID: StRS-30
+Titel: [HYPOTHESE] Berichte ohne unbeschränkten Datenzugriff
+Ebene: StRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Sicherheit (Zugriffskontrolle)
+Akteur: Berichtsverfasser/Report-Nutzer (Rolle); System
+Vorbedingung: Bericht wird definiert oder ausgeführt
+Fakt: Berichte liegen als Rohtext-SQL vor und sind als Sicherheitsrisiko bewertet (M057/M058).
+Aussage: Das System soll Berichte so bereitstellen, dass über Berichtsdefinitionen keine unbeschränkten Abfragen auf Geschäftsdaten und keine Manipulationen möglich sind; Berichtserstellung erfolgt in einem kontrollierten Rahmen.
+Ergebnis: Berichtsnutzer erreichen nur vorgesehene Daten; manipulierte oder übermäßige Abfragen werden verhindert.
+Belege:
+  - [PRIMÄR] M057 (ReportDataBL.ExecuteQuery: Parameter per Stringverkettung in Rohtext-SQL; ReportsBL.GetRawSqlResult Z.110-113) - Begründung: Risikobeobachtung an durchsetzender Stelle; gewünschte Schutzregel existiert dort nicht.
+Prüfidee: Ein Bericht ohne definierte Datenbeschränkung wird abgelehnt; ein Versuch, über eine Berichtsdefinition schreibend oder mandantenübergreifend zu lesen, scheitert.
+Tracelinks: StRS-2; StRS-16
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - Rohtext-SQL ist nicht übernahmewürdig; das Zielbild (kontrollierte Berichtsdefinitionen) ist in SyRS/SwRS auszugestalten.
+Status: HYPOTHESE

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/SyRS.md

@@ -0,0 +1,744 @@
+# SyRS - System Requirements Specification
+
+Reverse Requirements Engineering - c-entron ERP-Suite. Ebene: Systemverhalten, Schnittstellen, Betrieb, Datenhaltung, Sicherheit. Tracelinks zeigen auf StRS (Ergebnisse\StRS.md); SwRS verlinkt nachfolgend auf diese Datei.
+
+---
+
+ID: SyRS-1
+Titel: Rechteermittlung ausschließlich über Gruppen
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Authentifizierung/Autorisierung)
+Vorbedingung: Benutzer mit Gruppenmitgliedschaften in Sichmemb/Sichtrus
+Fakt: AppRightsBL.HasUserRight (AppRightsBL.cs Z.644-664) und CheckRightsFromUser (Z.95-111) ermitteln Rechte per SQL „Sichtrus INNER JOIN Sichmemb WHERE sm.Benutzer=:UserI3D", gecacht in AllRightsFromAppUser{I3D}; Rechte hängen nur an Gruppen; SichProtokoll als Rechte-Log (SSMS_DB_SCHEMA.sql Z.51211-51271).
+Aussage: Das System soll Zugriffsrechte ausschließlich über Gruppenmitgliedschaften ermitteln, das Ergebnis pro Benutzer cachen und Rechteänderungen in SichProtokoll protokollieren.
+Ergebnis: Nur Gruppenrechte gelten; Direktvergabe an Benutzer ist ausgeschlossen; Rechte-Log geführt.
+Belege:
+  - [PRIMÄR] AppRightsBL.HasUserRight / CheckRightsFromUser (AppRightsBL.cs Z.644-664, Z.95-111), Bedingung SQL-Join Sichtrus/Sichmemb je Benutzer - Begründung: durchgesetzte Rechteermittlungsregel
+  - [PRIMÄR] SSMS_DB_SCHEMA.sql Z.51211-51271 (Sichmemb/Sichtrus ohne FK, SichProtokoll) - Begründung: Schema verankert Gruppenprinzip und Log
+Prüfidee: Benutzer in Gruppe mit Recht X erhält X; Entzug der Gruppenmitgliedschaft entzieht X nach Cache-Neuaufbau; Eintrag in SichProtokoll vorhanden.
+Tracelinks: StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - bewährtes Gruppenprinzip mit Rechte-Log
+Status: belegt
+
+ID: SyRS-2
+Titel: Lizenzpflicht für Webservice-Start, Token und Hardwarebindung
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Webservice-Host / Lizenzverwaltung)
+Vorbedingung: Lizenzdaten für Lizenz-GUID vorhanden
+Fakt: LicenseManager.CheckLicense (LicenseManager.cs Z.258-302) ruft je GUID CheckLicenseVersion; LoadLicenses wirft bei fehlender Lizenz → Web-Service-Start schlägt fehl (Kommentar CentronHost.Start: Webservice-Version > lizenzierter Produktstand → Fehler); SQLManagementBL.GetDatabaseInfosForLicenseServer (Z.181-204) liefert DatabaseId/Name/CreatedDate/OwnerSid (Hardwarebindung); TicketWebServiceBL.GetWebServiceToken: ohne erfolgreiche Lizenzermittlung kein Token (SHA1-dekodierter Produkt-ID-Wert).
+Aussage: Das System soll den Webservice nur mit gültiger, versionsschrankenkonformer Lizenz starten, Datenbankkennzahlen an den Lizenzserver melden und Webservice-Token erst nach erfolgreicher Lizenzermittlung ausgeben.
+Ergebnis: Ohne/mit ungültiger Lizenz kein Start und keine Token-Ausgabe; Hardwarebindung aktiv.
+Belege:
+  - [PRIMÄR] LicenseManager.CheckLicense (LicenseManager.cs Z.258-302) + LoadLicenses, Bedingung fehlende/unpassende Lizenz → Exception - Begründung: durchgesetzte Lizenzschranke
+  - [PRIMÄR] SQLManagementBL.GetDatabaseInfosForLicenseServer (Z.181-204); TicketWebServiceBL.GetWebServiceToken (Bedingung: Lizenzermittlung erfolgreich) - Begründung: Hardwarebindung und Token-Kopplung
+Prüfidee: Lizenz entfernen → Startabbruch; Tokenanfrage ohne Lizenz → Fehler; Webservice-Version über lizenziertem Stand → Startfehler.
+Tracelinks: StRS-1, StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale Lizenzdurchsetzung
+Status: belegt
+
+ID: SyRS-3
+Titel: Begrenzung gleichzeitiger Tickets auf Lizenzanzahl
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Lizenzverwaltung)
+Vorbedingung: Lizenzierte Anzahl abrufbar; Ticketanzahl ermittelbar
+Fakt: LicenseManager.CheckLicense (LicenseManager.cs Z.258-302): wenn TicketBL.GetTicketCount >= GetLicenseCount → Fehler „Die maximale Anzahl an Lizenzen wurde erreicht."
+Aussage: Das System soll die Anzahl gleichzeitiger Tickets gegen die lizenzierte Anzahl begrenzen und Überschreitungen mit definierter Fehlermeldung ablehnen.
+Ergebnis: Login/Ticket-Erstellung über die Grenze scheitert mit der zitierten Meldung.
+Belege:
+  - [PRIMÄR] LicenseManager.CheckLicense (LicenseManager.cs Z.258-302), Bedingung TicketBL.GetTicketCount >= GetLicenseCount - Begründung: durchgesetzte Mengenschranke
+Prüfidee: Bei GetLicenseCount = n wird der (n+1). gleichzeitige Ticketabruf mit der genannten Fehlermeldung abgewiesen.
+Tracelinks: StRS-1, StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-4
+Titel: Login-Abweisung nach Rechten und Kontostatus
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Authentifizierung)
+Vorbedingung: Loginversuch gegen ApplicationKind
+Fakt: Authenticator.ValidateRights (Z.68-86): Login abgewiesen bei DisallowingRight==true bzw. RequiredRight==false je ApplicationKind; AuthenticateUser (Z.109-155): Rechteprüfung vor Lizenz unter lock, existierendes Ticket wird ohne neue Lizenzprüfung wiederverwendet; ValidateAppUser (Z.157-218): Prüfung IsAccountDisabled, AccountDisabledFromDate/ToDate, IsActiveEmployeeCompact.
+Aussage: Das System soll Logins bei anwendungsabhängig fehlenden Pflichtrechten oder vorliegenden Sperrrechten sowie bei gesperrten/zeitlich begrenzten/inaktiven Konten ablehnen und ein existierendes Ticket ohne erneute Lizenzprüfung wiederverwenden.
+Ergebnis: Abgewiesene Logins erhalten kein Ticket; wiederverwendete Tickets verbrauchen keine zusätzliche Lizenz.
+Belege:
+  - [PRIMÄR] Authenticator.ValidateRights (Z.68-86), Bedingung DisallowingRight==true || RequiredRight==false - Begründung: durchgesetzte Rechte-/Anwendungsschranke
+  - [PRIMÄR] Authenticator.ValidateAppUser (Z.157-218) und AuthenticateUser (Z.109-155) - Begründung: Kontostatus- und Ticket-Wiederverwendungsregel
+Prüfidee: Gesperrtes Konto → Login abgewiesen; zweiter Login desselben Benutzers führt nicht zu erneutem Lizenzabzug.
+Tracelinks: StRS-1, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-5
+Titel: Zweifaktor-Authentifizierung nach Schaltung und Gültigkeit
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (2FA)
+Vorbedingung: Login mit 2FA-Einstellungen (global/benutzerbezogen)
+Fakt: TwoFactorAuthBL.ValidateTwoFactor/HasToValidateTwoFactor (Z.33-135): keine Prüfung wenn TwoFactorAuthEnabled==false oder user.UseTwoFactorAuthentication==false; immer Prüfung wenn requireTwoFactorAuth oder twoFactorAuthIsValidDuration<=0; sonst Gültigkeit = lastTwoFactorAuth.Date.AddDays(duration) (tagesgenau); Typen RadiusServer/EmailLink, sonst ArgumentOutOfRangeException.
+Aussage: Das System soll 2FA je globaler Schaltung und Benutzereinstellung erzwingen bzw. aussetzen, die Gültigkeit tagesgenau nach Ablaufdatum bestimmen und unbekannte 2FA-Typen mit Ausnahme ablehnen.
+Ergebnis: Nur gültige 2FA-Sitzungen überspringen die erneute Prüfung; unbekannte Typen brechen ab.
+Belege:
+  - [PRIMÄR] TwoFactorAuthBL.ValidateTwoFactor / HasToValidateTwoFactor (Z.33-135), Bedingung TwoFactorAuthEnabled / UseTwoFactorAuthentication / requireTwoFactorAuth / duration - Begründung: durchgesetzte 2FA-Regeln
+Prüfidee: Abgelaufene 2FA-Gültigkeit → erneute Prüfpflicht; unbekannter Typ → ArgumentOutOfRangeException.
+Tracelinks: StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-6
+Titel: Passwortprüfung und Passwortänderungsregeln
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Benutzerverwaltung)
+Vorbedingung: Lokaler c-entron-Benutzer
+Fakt: BasicAuthenticator.AuthenticateInternal (Z.35-71): Vergleich Name + SHA1-Password; Kommentar Z.48 „// TODO the password should be salted!!!"; UsersBL.UpdatePassword: nur Mindestlänge (PasswordMinLength) als Regel; AD/Entra/OIDC-Benutzer dürfen das c-entron-Passwort nicht ändern.
+Aussage: Das System soll lokale Logins gegen Name + SHA1-Hash prüfen, Passwortänderungen nur bei Einhaltung der Mindestlänge zulassen und extern verwalteten (AD/Entra/OIDC) Konten die lokale Passwortänderung verweigern.
+Ergebnis: Externe Konten können kein lokales Passwort setzen; Passwortregeln greifen nur lokal.
+Belege:
+  - [PRIMÄR] BasicAuthenticator.AuthenticateInternal (Z.35-71), Bedingung Name+SHA1-Password-Vergleich - Begründung: durchgesetztes Authentifizierungsverfahren
+  - [SEKUNDÄR] UsersBL.UpdatePassword (PasswordMinLength; Ausschluss AD/Entra/OIDC) - Begründung: Passwortregel im Code
+Prüfidee: Falsches SHA1-Passwort → Abweisung; AD-Benutzer versucht Passwortänderung → Ablehnung; zu kurzes Passwort → Ablehnung.
+Tracelinks: StRS-1, StRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - SHA1 ohne Salt laut TODO-Kommentar bekannt unsicher; Umstellung auf gesalzenes Verfahren anstreben
+Status: belegt
+
+ID: SyRS-7
+Titel: Web-Konto-Login-Kaskade mit Protokollierung
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Web-Portal-Authentifizierung)
+Vorbedingung: WebAccount mit Status 1
+Fakt: WebAccountBL.LoginWithWebAccount (Z.54-102): Status==1 && Username.ToUpper() && SHA1-Password; anschließende Kaskade IsCustomerActiveAndNotLocked, contact.IsActive, address.IsActive, IsAccountActiveAndNotLocked; schreibt LastLoginIP/LastLoginDate.
+Aussage: Das System soll Web-Konto-Logins nur bei aktiver, nicht gesperrter Kette (Konto → Kunde → Kontakt → Adresse) zulassen und LastLoginIP/LastLoginDate fortgeschreiben.
+Ergebnis: Inaktive oder gesperrte Kettenglieder blockieren den Login; letzter Login ist nachvollziehbar.
+Belege:
+  - [PRIMÄR] WebAccountBL.LoginWithWebAccount (Z.54-102), Bedingung Status==1, Kaskadenprüfungen - Begründung: durchgesetzte Login-Kaskade
+Prüfidee: Gesperrter Kunde mit aktivem WebAccount → Login abgewiesen; erfolgreicher Login setzt LastLoginIP/LastLoginDate.
+Tracelinks: StRS-6, StRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-8
+Titel: Ticket-Authentifizierung am Host (Bearer/Query)
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: System (Centron.Host)
+Vorbedingung: HTTP-Aufruf mit Ticket
+Fakt: Centron.Host TicketAuthenticationHandler.HandleAuthenticateAsync: Ticket aus Query-Parameter access_token oder Header „Authorization: Bearer" (exakt 2 Teile); leer/ungültig → AuthenticateResult.Fail; Validierung via AuthenticationTicketBL.GetAuthTicketInfo(token, ipAddress, apiMethod); Claims: NameIdentifier=Token, AuthenticationTypeIdentifier (AccessToken vs Ticket), UserIdentifier=AppUserI3D.
+Aussage: Das System soll Dienste ausschließlich per Query-Token oder Bearer-Header authentifizieren, ungültige Tickets mit Fail ablehnen und den validierten Kontext als Claims bereitstellen.
+Ergebnis: Nur Tickets/Access Tokens mit gültiger GetAuthTicketInfo-Prüfung gelangen durch.
+Belege:
+  - [PRIMÄR] TicketAuthenticationHandler.HandleAuthenticateAsync (Centron.Host), Bedingung Header „Authorization: Bearer" mit exakt 2 Teilen / access_token - Begründung: durchgesetzte Ticket-Authentifizierung
+Prüfidee: Aufruf ohne/ mit defektem Header → AuthenticateResult.Fail; gültiges Token erzeugt Claims UserIdentifier/NameIdentifier.
+Tracelinks: StRS-1
+Konsolidierung: Kandidat: Ticketvalidierung doppelt implementiert (TicketAuthenticationHandler im Host und AuthenticateInterceptor, M103) - eine Quelle für Ticketprüfung anstreben
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-9
+Titel: Interceptor-Durchsetzung: Ticketpflicht, Beschränkungen, Slide-Refresh
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Centron.Host Interceptors)
+Vorbedingung: Authentifizierter Dienstaufruf
+Fakt: AuthenticateInterceptor (Priority 10): request.Ticket leer → „You need to provide a ticket"; applicationIsBlocked = attribute.Applications.Count>0 && !Contains(ticketApplicationKind); webAccountIsBlocked = WebAccountI3D != null && !AllowWebAccountLogin; blockiert → StatusCode.Failed bzw. InvalidTicket ohne invocation.Proceed(); TicketBL.RefreshTicketExpireDate (Slide-Verlängerung); Access Tokens ohne Anwendungsbeschränkung (Kommentar); IP-Ermittlung X-Forwarded-For → X-Real-IP → RemoteIpAddress; Kommentar Z.33-37: Beschränkung deckt nur eine Richtung; LoggedInUserInterceptor (Priority 20) setzt LoggedInUserManager.AppUserI3D/Ticket/IsAccessToken/WebAccountI3D/LicenseGuid, Double-Logging im AccessTokenLog per Flag verhindert.
+Aussage: Das System soll jeden Dienstaufruf auf Ticketpflicht sowie Anwendungs- und Web-Konto-Beschränkung prüfen, blockierte Aufrufe ohne Ausführung ablehnen, gültige Tickets slidend verlängern und den Aufrufkontext zentral setzen.
+Ergebnis: Blockierte Aufrufe erreichen die Fachlogik nicht; Ticketablauf verschiebt sich bei Nutzung; Kontext steht dem Aufruf konsistent zur Verfügung.
+Belege:
+  - [PRIMÄR] AuthenticateInterceptor (Priority 10), Bedingung applicationIsBlocked / webAccountIsBlocked / leeres Ticket - Begründung: durchgesetzte Aufrufschranken (M103)
+  - [PRIMÄR] LoggedInUserInterceptor (Priority 20), Setting des LoggedInUserManager + Double-Log-Flag - Begründung: Kontextsetzung pro Aufruf
+Prüfidee: Ticket einer unzulässigen Anwendung → Failed/InvalidTicket ohne Methodenaufruf; aufeinanderfolgende Aufrufe verlängern Ticketablauf.
+Tracelinks: StRS-1, StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Einschränkungsrichtung laut Kommentar dokumentieren
+Status: belegt
+
+ID: SyRS-10
+Titel: HTTP-Autorisierung 401/403 fail-closed
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Centron.Controllers)
+Vorbedingung: Controller-Aufruf mit Rechtefilter
+Fakt: Centron.Controllers UserRightAuthorizationFilter: currentUser==null → UnauthorizedResult (401); !HasUserRight(requiredRightId) → ForbidResult (403); AllUserRightsAuthorizationFilter: UND-Verknüpfung aller Rechte, leere Liste → ForbidResult (fail-closed); ApiUserUtils.GetCurrent: ClaimsPrincipal → GetLoggedInUserByToken.
+Aussage: Das System soll Controller-Aufrufe ohne authentifizierten Benutzer mit 401 und ohne erforderliches Recht mit 403 ablehnen; Mehrfachrechte UND-verknüpfen und eine leere Rechtefestlegung ablehnen (fail-closed).
+Ergebnis: Kein unautorisierter oder unterprivilegierter Zugriff auf Controller-Routen.
+Belege:
+  - [PRIMÄR] UserRightAuthorizationFilter / AllUserRightsAuthorizationFilter (Centron.Controllers), Bedingung currentUser==null → 401, !HasUserRight → 403, leere Liste → 403 - Begründung: durchgesetzte Autorisierung
+Prüfidee: Aufruf ohne Benutzer → 401; mit Benutzer ohne Recht → 403; AllUserRights mit leerer Rechtefestlegung → 403.
+Tracelinks: StRS-2
+Konsolidierung: Kandidat: Rechteprüfung in MVC-Filtern und in BL-Kanälen (siehe AccessTokenWebServiceBL-Kommentar) doppelt verankert
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-11
+Titel: Access-Token-Verwaltung nach Own-or-Right
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (Token-Verwaltung)
+Vorbedingung: Angemeldeter Benutzer mit/ohne VIEW_ALL
+Fakt: AccessTokenWebServiceBL.GetById/Delete (Centron.BL\WebServices\Administration\AccessTokens): Own-or-Right (VIEW_ALL); Delete ohne Own-Token-Ausnahme nur mit DELETE_ALL; CreatePersonalToken zwingend eigener Employee; Kommentar: Rights-Checks bewusst in der BL, damit auch der WPF-ILogic-Kanal respektiert wird.
+Aussage: Das System soll Access-Token sichtbar/löschbar nur nach Own-or-Right-Prüfung (VIEW_ALL, Löschen ohne Own-Token nur mit DELETE_ALL) behandeln und persönliche Token zwingend für den eigenen Employee anlegen.
+Ergebnis: Kein fremdes Token ohne Sonderrecht einsehbar/löschbar.
+Belege:
+  - [PRIMÄR] AccessTokenWebServiceBL.GetById / Delete (Centron.BL\WebServices\Administration\AccessTokens), Bedingung Own-or-Right VIEW_ALL / DELETE_ALL - Begründung: durchgesetzte Tokenrechte
+Prüfidee: Benutzer ohne VIEW_ALL erhält fremdes Token nicht; Delete eines fremden Tokens ohne DELETE_ALL wird abgewiesen.
+Tracelinks: StRS-2, StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - BL-seitige Prüfung deckt beide Kanäle (REST und WPF-ILogic)
+Status: belegt
+
+ID: SyRS-12
+Titel: Host-Start-Härtung: Lizenz vor DB, JWT-Pflicht
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (CentronHost)
+Vorbedingung: Host-Start
+Fakt: CentronHost.Start: TryLoadLicense vor SetupDatabaseConnection (Kommentar: License check throws wenn Lizenz ungültig oder Webservice-Version > lizenzierter Produktstand); MapControllers().RequireAuthorization(); JWT-Bearer mit ValidateIssuer/Audience/Lifetime/IssuerSigningKey, RequireSignedTokens, RequireExpirationTime, ValidateTokenReplay=true.
+Aussage: Das System soll beim Start zuerst die Lizenz (inkl. Versionsschranke) laden, alle Controller autorisierungspflichtig machen und JWTs vollständig (Aussteller, Audience, Lebensdauer, Signatur, Ablauf, Token-Replay) validieren.
+Ergebnis: Kein Betrieb ohne gültige Lizenz; unsignierte, abgelaufene oder wiederverwendete JWTs werden abgewiesen.
+Belege:
+  - [PRIMÄR] CentronHost.Start (Reihenfolge TryLoadLicense → SetupDatabaseConnection; MapControllers().RequireAuthorization(); JWT-Bearer-Optionen inkl. ValidateTokenReplay=true) - Begründung: durchgesetzte Start- und JWT-Regeln
+Prüfidee: Unsigniertes/abgelaufenes JWT → 401; Token-Replay → Ablehnung; Lizenzfehler bricht Start vor DB-Setup ab.
+Tracelinks: StRS-6, StRS-25
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-13
+Titel: Pauschale CORS-Freigabe des Hosts
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (CentronHost)
+Vorbedingung: Host läuft
+Fakt: CentronHost.Start: CORS AllowAnyOrigin / AllowAnyHeader / AllowAnyMethod.
+Aussage: Das System soll Cross-Origin-Anfragen aktuell pauschal (jede Origin, jeder Header, jede Methode) zulassen, bis eine restriktivere Richtlinie konfiguriert ist.
+Ergebnis: Browser-Aufrufe fremder Origins werden nicht per CORS blockiert.
+Belege:
+  - [PRIMÄR] CentronHost.Start (CORS-Policy AllowAnyOrigin/AllowAnyHeader/AllowAnyMethod) - Begründung: durchgesetzte Policy im Host-Setup
+Prüfidee: Preflight/Request mit fremdem Origin liefert CORS-Freigabe-Header ohne Ablehnung.
+Tracelinks: StRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - pauschale CORS-Policy aus Sicherheitssicht zu weit; Origin-Allowliste anstreben
+Status: belegt
+
+ID: SyRS-14
+Titel: Hintergrunddienste nur bei freigeschaltetem ExecuteServices
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: System (CentronHost)
+Vorbedingung: Host-Start mit WebServiceConfig
+Fakt: CentronHost.Start: Hosted Services nur wenn WebServiceConfigHelper.Current.ExecuteServices==true.
+Aussage: Das System soll die im Host registrierten Hintergrunddienste nur starten, wenn die Konfiguration ExecuteServices aktiviert.
+Ergebnis: Ohne Schaltung laufen keine Host-Hintergrunddienste.
+Belege:
+  - [PRIMÄR] CentronHost.Start, Bedingung WebServiceConfigHelper.Current.ExecuteServices==true - Begründung: durchgesetzte Startbedingung für Hosted Services
+Prüfidee: ExecuteServices=false → keine registrierten IHostedService werden gestartet; true → Start aller Dienste.
+Tracelinks: StRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-15
+Titel: Protokoll REST/POST ohne SOAP, URI-Eindeutigkeit
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: System (CentronWcfBridge / Centron.Host)
+Vorbedingung: Host-Start mit registrierten Diensten
+Fakt: CentronWcfBridge.MapCentronRestService: jede ICentronRestService-Methode als MapPost(„/REST"+UriTemplate) bzw. /RESTC (Compression); duplicateUris → InvalidOperationException beim Start; Grep „SOAP" in Centron.Host: 0 Treffer.
+Aussage: Das System soll alle Webservice-Methoden ausschließlich als REST-POST (komprimierbar über /RESTC) bereitstellen und doppelte URIs mit Startabbruch (InvalidOperationException) quittieren.
+Ergebnis: Einheitliches POST-Protokoll; URI-Kollisionen verhindern fehlerhaften Start.
+Belege:
+  - [PRIMÄR] MapCentronRestService (MapPost je Methode; duplicateUris → InvalidOperationException) - Begründung: durchgesetzte Routing-Regel
+  - [KONTEXT] Grep „SOAP" in Centron.Host: 0 Treffer - Begründung: Protokollbestimmung REST/POST
+Prüfidee: Doppelte UriTemplate in zwei Diensten → Startabbruch; jede Methode ist nur per POST erreichbar.
+Tracelinks: StRS-24, StRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-16
+Titel: Hub-Autorisierung mit SecretKey-Policy
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (SignalR-Hubs)
+Vorbedingung: SignalR-Verbindungsaufbau
+Fakt: SecretKeyHandler.HandleRequirementAsync: nur wenn authHeader.StartsWith(„Bearer ") && secretKey == requirement.SecretKey → Succeed; NotificationsHub [Authorize(Policy=„SecretKey")] mit statischem Schlüssel aus WebServiceConfigHelper; AvailabilityStatusHub/ChatHub/TapiClientHub nur [Authorize].
+Aussage: Das System soll alle SignalR-Hubs autorisierungspflichtig machen und den NotificationsHub zusätzlich per statischem Bearer-SecretKey aus der Webservice-Konfiguration absichern.
+Ergebnis: Verbindungen ohne gültigen Bearer-SecretKey bzw. Autorisierung werden abgelehnt.
+Belege:
+  - [PRIMÄR] SecretKeyHandler.HandleRequirementAsync, Bedingung StartsWith(„Bearer ") && secretKey == requirement.SecretKey - Begründung: durchgesetzte Hub-Schranke
+Prüfidee: NotificationsHub-Verbindung ohne korrekten SecretKey → abgewiesen; andere Hubs ohne [Authorize]-Nachweis → abgewiesen.
+Tracelinks: StRS-24, StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - statischer Schlüssel ohne Rotation; austauschbares Geheimnis anstreben
+Status: belegt
+
+ID: SyRS-17
+Titel: Nexus-Host-Schemata und Port-Autorisierung
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (CentronNexus.Host)
+Vorbedingung: Nexus-Host-Start unter Linux
+Fakt: CentronNexus.Host Program.cs ConfigureWebHostLinux (M126): nur UriSchemeHttps (PKCS12 aus HostConfig) oder UriSchemeHttp, sonst InvalidDataException; Kestrel auf Host-Port (Default 8050) plus CustomerPortalConfig.Port wenn gesetzt; PortAuthorization.PortHandler: ohne Portal-Port-Konfiguration immer erfolgreich, sonst nur wenn http.Connection.LocalPort == AllowedPort.
+Aussage: Das System soll den Nexus-Host nur mit HTTPS (PKCS12) oder HTTP starten, den Host-Port (Default 8050) plus optionalen Portal-Port binden und Zugriffe auf dem Portal-Port nur bei übereinstimmendem lokalen Port zulassen.
+Ergebnis: Unbekannte Schemata verhindern den Start; Portal-Port akzeptiert nur autorisierte Verbindungen.
+Belege:
+  - [PRIMÄR] ConfigureWebHostLinux (M126), Bedingung UriSchemeHttps/UriSchemeHttp sonst InvalidDataException - Begründung: durchgesetzte Schema-Schranke
+  - [PRIMÄR] PortAuthorization.PortHandler (Bedingung http.Connection.LocalPort == AllowedPort) - Begründung: durchgesetzte Port-Prüfung
+Prüfidee: Konfiguration mit ftp-Schema → Startabbruch; Request auf Portal-Port mit fremdem LocalPort → abgewiesen.
+Tracelinks: StRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-18
+Titel: Portal-Cookie- und OIDC-Authentifizierung
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (CentronNexus.Host Portal)
+Vorbedingung: Portal-Zugriff
+Fakt: CentronNexus.Host (M126): Cookie-Auth LoginPath=/auth, MaxAge 12h, SameSite Lax; OIDC mit OnRemoteFailure-Handler.
+Aussage: Das System soll Portal-Logins per Cookie (LoginPath /auth, MaxAge 12 h, SameSite Lax) und OIDC-Anmeldungen mit behandelter Remote-Failure absichern.
+Ergebnis: Cookies laufen nach 12 h ab; OIDC-Fehler führen in definierte Fehlerbehandlung statt Absturz.
+Belege:
+  - [PRIMÄR] CentronNexus.Host Program.cs (Cookie-Optionen LoginPath/MaxAge/SameSite; OIDC OnRemoteFailure) (M126) - Begründung: durchgesetzte Auth-Konfiguration
+Prüfidee: Cookie nach 12 h ungültig; fehlgeschlagener OIDC-Redirect landet im OnRemoteFailure-Handler.
+Tracelinks: StRS-6, StRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-19
+Titel: Client-Verkehr: RESTC/POST, Ticket-Pflicht, unendlicher Timeout
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: Client (CentronWebService) ↔ System
+Vorbedingung: Bestehende Dienstverbindung
+Fakt: CentronWebService (Centron.WebServices.Core\Connections): BaseAddress + „/RESTC/", jede Methode HttpMethod.Post, Header Accept-Language, Content-Type/Content-Type-Version (Default CompressedDataContractSerializer); StatusCode != OK → Exception „Connection failed on method ..."; Timeout = InfiniteTimeSpan (bewusst, lange Methoden >15 min); Request/Request<T>: [DataMember] public string Ticket an Basisklasse aller Anfragen; serverseitig PRIMÄR: leerer Ticket → „You need to provide a ticket" (AuthenticateInterceptor).
+Aussage: Das System soll den Client-Verkehr als komprimierbares REST-POST mit Ticket-DataMember in jeder Anfrage abwickeln, Nicht-OK-Statuscodes als Ausnahme melden und keinen Client-Timeout setzen (lange Methoden >15 min).
+Ergebnis: Einheitlicher, fehlertoleranter Verkehr für langlaufende Operationen.
+Belege:
+  - [PRIMÄR] AuthenticateInterceptor (M103), Bedingung request.Ticket leer → „You need to provide a ticket" - Begründung: serverseitig durchgesetzte Ticketpflicht
+  - [SEKUNDÄR] CentronWebService Connections (RESTC/POST, StatusCode-Exception, InfiniteTimeSpan) + Request<T> [DataMember] Ticket - Begründung: Client-Protokollkonvention
+Prüfidee: Anfrage ohne Ticket wird serverseitig abgewiesen; HTTP-Fehlerstatus erzeugt „Connection failed on method ...".
+Tracelinks: StRS-24, StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - unendlicher Timeout ist bewusst gewählt; dafür Server-seitige Ablaufkontrolle vorsehen
+Status: belegt
+
+ID: SyRS-20
+Titel: Zentrale DAO-Schicht mit stiller String-Kürzung
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (DAO/NHibernate)
+Vorbedingung: Datenzugriff über DAOFactory
+Fakt: DAOFactory.InitializeAsyncInternal (Z.89-129): NHibernate/FluentNHibernate, MsSqlConfiguration.MsSql2008 mit CentronMsSql2008Dialect, DefaultSchema(„dbo"), Mappings AddFromAssemblyOf<BaseMaps<BaseEntity>>; Listener PreUpdate: ChangeTracking/WhyIsMyEntityUpdated/TruncateStrings/StringOrBinary (nur DEBUG), PreInsert: TruncateStrings+StringOrBinary; GetSession (Z.166-178): ohne IsInitialized/HasConnection → InvalidOperationException; Warten in 50-ms-Schleife während SessionFactory-Neuaufbau; TruncateStringsEventListener.TruncateStringsIfNeeded (Z.37-51): zu lange Strings still auf Mappable-Länge gekürzt (Substring).
+Aussage: Das System soll den gesamten Datenzugriff über eine zentrale NHibernate-DAO-Schicht (Schema dbo) führen, Zugriffe vor Initialisierung ablehnen, SessionFactory-Neuaufbau abwarten und zu lange Strings vor Insert/Update still auf die Ziellänge kürzen.
+Ergebnis: Keine SQL-Fehler durch Überlängen; uninitialisierte Zugriffe scheitern kontrolliert.
+Belege:
+  - [PRIMÄR] DAOFactory.InitializeAsyncInternal (Z.89-129) / GetSession (Z.166-178), Bedingung !IsInitialized || !HasConnection → InvalidOperationException - Begründung: durchgesetzte Lebenszyklusregeln
+  - [PRIMÄR] TruncateStringsEventListener.TruncateStringsIfNeeded (Z.37-51), PreInsert/PreUpdate Substring - Begründung: durchgesetzte Kürzungsregel
+Prüfidee: Insert eines 300-Zeichen-Werts in varchar(100)-Spalte wird ohne Fehler gekürzt gespeichert; Zugriff vor Init → InvalidOperationException.
+Tracelinks: StRS-28
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - stilles Kürzen maskiert Datenverlust; Validierung an der Oberfläche anstreben
+Status: belegt
+
+ID: SyRS-21
+Titel: Zählerbasiertes Transaktionsmanagement inkl. Roh-SQL
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (DAOSession)
+Vorbedingung: Verschachtelte Geschäftsoperationen auf einer Session
+Fakt: DAOSession (Z.89-124, 226-239): verschachtelte Transaktionen über Zähler; Commit nur bei Zählerstand 0, sonst „The transaction has already ended..."; RollbackTransaction setzt Zähler auf 0; Dispose rollt offene Transaktion zurück; WithTransaction (Z.145-182): Commit nur bei ResultStatus.Success, sonst Rollback; bei Exception Rollback + Rethrow; RawSqlAccessDAO (Z.31-79): Roh-SQL über Session.Connection.CreateCommand(), enlistet in Session.GetCurrentTransaction().
+Aussage: Das System soll verschachtelte Transaktionen zählerbasiert nur am äußeren Rand committen, bei Misserfolg, Ausnahme oder Dispose vollständig zurückrollen und Roh-SQL in die laufende Session-Transaktion einbetten.
+Ergebnis: Kein Teilcommit in verschachtelten Operationen.
+Belege:
+  - [PRIMÄR] DAOSession (Z.89-124, Z.145-182, Z.226-239), Bedingung Zählerstand 0 / ResultStatus.Success - Begründung: durchgesetzte Transaktionsregeln
+  - [PRIMÄR] RawSqlAccessDAO (Z.31-79), Enlistment in GetCurrentTransaction() - Begründung: Roh-SQL teilnimmt an Transaktion
+Prüfidee: Exception in verschachtelter WithTransaction rollt alles zurück; inneres Commit vor Zähler 0 wird mit definierter Meldung abgewiesen.
+Tracelinks: StRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-22
+Titel: Beleg-Concurrency über ConcurrencyControlGuid
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (Belegsicherung)
+Vorbedingung: Beleg gleichzeitig durch zwei Sätze bearbeitet
+Fakt: SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency (Z.200-207): ConcurrencyControlGuid != receipt.ConcurrencyControlGuid → ReceiptConcurrencyConflictException; Fang → Result-Fehlercode ReceiptConcurrencyConflictOnSave; Muster je Belegart (RechKopf/AufKopf/GutKopf).
+Aussage: Das System soll gleichzeitige Belegänderungen über den Vergleich von ConcurrencyControlGuid erkennen und als Result-Misserfolg ReceiptConcurrencyConflictOnSave melden.
+Ergebnis: Zweit speichernder Satz erhält definierten Konfliktfehler statt stiller Überschreibung.
+Belege:
+  - [PRIMÄR] SaveReceiptRepository.GetExistingReceiptTableCheckConcurrency (Z.200-207), Bedingung ConcurrencyControlGuid != receipt.ConcurrencyControlGuid - Begründung: durchgesetzte Optimistic-Concurrency-Prüfung
+Prüfidee: Zwei Sessions laden denselben Beleg; erstes Speichern gelingt, zweites mit altem Guid → ReceiptConcurrencyConflictOnSave.
+Tracelinks: StRS-7
+Konsolidierung: Kandidat: Muster in drei Belegarten (RechKopf/AufKopf/GutKopf) wiederholt - generische Prüfung prüfen
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-23
+Titel: Datenbank-Schema-Rahmen und anwendungsseitige Integrität
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (Datenhaltung)
+Vorbedingung: Datenbank nach SSMS_DB_SCHEMA
+Fakt: SSMS_DB_SCHEMA.sql: 1535 dbo-Tabellen, nur 134 FOREIGN KEYs, 0 CHECK-Constraints; IDENTITY(1,1) in 1471 Tabellen (I3D), nur 33 uniqueidentifier; IX_AccountCustomers_UniqueNumber (Z.3784) / IX_AccountSuppliers_UniqueNumber (Z.3854); RechKopf (Z.3231ff): Nummer/Version/Datum/KundenID NOT NULL, Status NULL, IsFixed bit NOT NULL, Preisfelder DEFAULT 0; 3 FKs WITH NOCHECK (ArticleImport); Textbausteine-Tabellen statt Sprachspalten; Referenzintegrität der Kerntabellen liegt in der Anwendung.
+Aussage: Das System soll das Schema als I3D-IDENTITY-Modell mit wenigen DB-FKs und ohne CHECK-Constraints betreiben und Referenzintegrität der Kerntabellen anwendungsseitig plus Eindeutigkeit der Kunden-/Lieferantennummern über Unique-Indizes sicherstellen.
+Ergebnis: Schema ist homogen (dbo, I3D); Nummern-Eindeutigkeit DB-seitig erzwungen; RI-Verletzungen müssen von der Anwendung verhindert werden.
+Belege:
+  - [PRIMÄR] SSMS_DB_SCHEMA.sql (Z.3784, Z.3854 Unique-Indizes; Z.3231ff RechKopf NOT NULL/DEFAULT; Zählung 1535 Tabellen/134 FKs/0 CHECKs) - Begründung: Schema als durchgesetzte Basis
+Prüfidee: Doppelte Kunden-UniqueNumber → DB-Fehler; RechKopf ohne Nummer → DB-Fehler; verwaiste Detailzeilen sind DB-seitig möglich (RI-Prüfung nur in Anwendung).
+Tracelinks: StRS-20, StRS-19
+Konsolidierung: nein
+Übernahmewürdigkeit: Sonderfall - bewusst dünn restraintes Schema; RI-Gewährleistung liegt auf Anwendungsseite und muss getestet werden
+Status: belegt
+
+ID: SyRS-24
+Titel: Entitätsidentität über I3D und stabile Objektart-Nummern
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (Entitätsmodell)
+Vorbedingung: Persistente Entität mit I3D > 0
+Fakt: PersistedEntity.operator == (Z.14-61): Gleichheit bei I3D>0 allein über I3D (proxy-sicher), GetHashCode über I3D (Z.86-99); BaseEntity: [DataContract], virtual int I3D; CentronObjectKindNumeric (M093): stabile Objektart-Nummern als wire contract (OfferClass=1, InvoiceClass=4, CustomerClass=5000012), neue Werte nur am Ende (Kommentar).
+Aussage: Das System soll die Entitätsidentität bei positivem I3D ausschließlich über I3D bestimmen und Objektart-Nummern als stabilen Wire-Contract führen, der nur am Ende erweitert wird.
+Ergebnis: Proxy-sichere Gleichheit; nummerierte Objektarten bleiben über Releases hinweg zuordnungsfest.
+Belege:
+  - [PRIMÄR] PersistedEntity.operator == (Z.14-61) / GetHashCode (Z.86-99), Bedingung I3D > 0 - Begründung: durchgesetzte Identitätsregel
+  - [PRIMÄR] CentronObjectKindNumeric (M093), Kompatibilitätskommentar „nur am Ende erweitern" - Begründung: Wire-Contract-Garantie
+Prüfidee: Zwei Instanzen gleicher Klasse mit gleichem I3D sind gleich (auch als Proxy); bestehende Objektart-Nummern ändern sich bei Release nicht.
+Tracelinks: StRS-20
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-25
+Titel: Cache-Update-Verfahren mit Recovery und Statistik-Neuaufbau
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: System (CachedTableBL)
+Vorbedingung: Cache-Tabellen mit CachedTableStatistics
+Fakt: CachedTableBL.ExecuteCacheUpdates (Z.98-110): Auswahl (IsUpdateRequested || LastUpdated==null || LastUpdated < heute) && (!IsUpdating || LastUpdated < DateTime.Now.AddMinutes(-10)) → hängengebliebene Updates >10 min werden erneut verarbeitet; ExecuteUpdateCache (Z.188-245): IsUpdating=true, StartTransaction, bei Fehler Rollback + Flag zurück, bei Erfolg LastUpdated=now + Commit; UpdateCacheSalesStatistic (Z.252, 1029): TruncateTable(CacheSalesStatistic) + Raw-SQL INSERT SELECT über cvw_InvoicePos/cvw_CreditVoucherPos mit rk.Status IN (1,2), commandTimeout 1800s; Schema CachedTableStatistics: TableName/IsUpdateRequested/IsUpdating NOT NULL.
+Aussage: Das System soll Cache-Tabellen bedarfs- bzw. taggesteuert mit 10-Minuten-Recovery hängender Läufe transaktional aktualisieren und die Vertriebsstatistik über Truncate+INSERT SELECT nur aus Belegen mit Status 1/2 mit 1800-s-Timeout neu aufbauen.
+Ergebnis: Hängende Läufe werden automatisch wiederholt; Fehler rollen inklusive IsUpdating-Flag zurück; Statistik enthält nur gebuchte/stornierte Belege (Status 1,2).
+Belege:
+  - [PRIMÄR] CachedTableBL.ExecuteCacheUpdates (Z.98-110) / ExecuteUpdateCache (Z.188-245), Bedingung Update-Auswahl und Rollback-Handling - Begründung: durchgesetzte Cache-Steuerung
+  - [PRIMÄR] UpdateCacheSalesStatistic (Z.252, Z.1029), Bedingung rk.Status IN (1,2), commandTimeout 1800s - Begründung: durchgesetzter Statistik-Neuaufbau
+Prüfidee: IsUpdating=true mit LastUpdated >10 min alt → erneuter Lauf; Fehler während Update → IsUpdating zurückgesetzt, keine Teildaten.
+Tracelinks: StRS-26, StRS-30
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-26
+Titel: CTime-Synchronisation nur bei Aktivierung
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: System (CTimeConnectorBL)
+Vorbedingung: Zeitwirtschafts-Import konfiguriert
+Fakt: CTimeConnectorBL (Z.116-166): nur bei IsSyncActive; Items ohne TimeTrackIn/Out oder EmployeeEmail übersprungen; Mapping 1→Urlaub, 2→Krankheit, 3→Überstunden.
+Aussage: Das System soll CTime-Daten nur bei aktivierter Synchronisation importieren, unvollständige Posten (fehlende Zeitstempel oder E-Mail) überspringen und Abwesenheitstypen 1/2/3 auf Urlaub/Krankheit/Überstunden mappen.
+Ergebnis: Ohne IsSyncActive kein Import; unvollständige Items erzeugen keine Teildaten.
+Belege:
+  - [PRIMÄR] CTimeConnectorBL (Z.116-166), Bedingung IsSyncActive / Skip-Regeln / Mapping-Tabelle - Begründung: durchgesetzte Sync-Regeln
+Prüfidee: IsSyncActive=false → kein Datentransfer; Item ohne EmployeeEmail → übersprungen; Typ 2 → Krankheit.
+Tracelinks: StRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-27
+Titel: Verzeichnisprüfung nur für Admin-Gruppen-Logins
+Ebene: SyRS
+Typ: Sicherheit
+Qualitätsmerkmal:
+Akteur: System (DirectoryCheckBL)
+Vorbedingung: Aufruf von ExecuteDirectoryCheck
+Fakt: DirectoryCheckBL.ExecuteDirectoryCheck (Z.52-56): nur wenn currentUser.IsCentronUserLogin && IsUserInAdminGroup, sonst „Login does not have the rights to execute this method."
+Aussage: Das System soll Verzeichnisprüfungen nur für Centron-Logins mit Admin-Gruppenmitgliedschaft ausführen und andere Aufrufe mit definierter Fehlermeldung ablehnen.
+Ergebnis: Keine Verzeichnisprüfung durch Web-Konten oder Nicht-Admins.
+Belege:
+  - [PRIMÄR] DirectoryCheckBL.ExecuteDirectoryCheck (Z.52-56), Bedingung IsCentronUserLogin && IsUserInAdminGroup - Begründung: durchgesetzte Rechtebedingung
+Prüfidee: Nicht-Admin-Login ruft Methode → zitierte Fehlermeldung; Web-Konto → abgewiesen.
+Tracelinks: StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-28
+Titel: Idempotente API-Telemetrie mit Deadlock-Wiederholung
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: System (TelemetryBL)
+Vorbedingung: dbo.ApiCallTelemetry vorhanden
+Fakt: TelemetryBL.UpsertApiCallBatch: MERGE dbo.ApiCallTelemetry WITH (HOLDLOCK), Match inkl. ISNULL(LicenseKind,-1); ExecuteWithDeadlockRetry (max 5 Versuche, SQL-Fehler 1205/2627/2601); InsertMissingNames: Unique-Verstoß 2627 wird verschluckt, I3D nachgelesen (idempotent).
+Aussage: Das System soll API-Aufruf-Telemetrie per MERGE idempotent fortschreiben und Deadlock-/Unique-Verstöße (SQL 1205/2627/2601) bis zu 5-mal wiederholen bzw. nachlesen.
+Ergebnis: Telemetrie geht bei Parallelität nicht verloren und doppelt sich nicht.
+Belege:
+  - [PRIMÄR] TelemetryBL.UpsertApiCallBatch (MERGE WITH (HOLDLOCK), Match ISNULL(LicenseKind,-1)) + ExecuteWithDeadlockRetry (max 5, Fehler 1205/2627/2601) - Begründung: durchgesetzte Upsert-/Retry-Regeln
+Prüfidee: Zwei parallele Batches mit identischem Schlüssel erzeugen genau einen Datensatz; simulierter Deadlock wird bis 5-mal wiederholt.
+Tracelinks: StRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-29
+Titel: Zentrale Mailkanalwahl und Graph-Kanal-Regeln
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: System (Mailversand)
+Vorbedingung: ApplicationSetting CentronWebserviceMailType gesetzt
+Fakt: CentronMailFactory.GetMail (Z.29-53): Versandkanal aus ApplicationSetting CentronWebserviceMailType (Exchange/Graph/default SMTPMail); TestMails.IsEnabled schaltet auf TestMail; GraphServiceClientHelper.GetConfig (Z.94-109): GraphAppId/Tenant/Secret leer → InvalidConfiguration; GraphServiceClient mit ClientSecretCredential, Scope https://graph.microsoft.com/.default; GetUser: ohne Fallback-Adresse Fehler; GraphMail.GetAttachments (Z.279-320): Anhang <3 MB inline, 3-150 MB über Upload-Session, ≥150 MB übersprungen mit Warnlog.
+Aussage: Das System soll den Mailversandkanal zentral per ApplicationSetting wählen (Testmodus über TestMails), den Graph-Kanal nur bei vollständiger Konfiguration (AppId/Tenant/Secret) starten und Anhänge nach Größenklassen behandeln (inline <3 MB, Upload-Session 3-150 MB, ≥150 MB überspringen mit Warnlog).
+Ergebnis: Nur ein Kanal je Konfiguration; Graph ohne Konfiguration scheitert kontrolliert; Riesenanhänge blockieren den Versand nicht.
+Belege:
+  - [PRIMÄR] CentronMailFactory.GetMail (Z.29-53), Bedingung CentronWebserviceMailType / TestMails.IsEnabled - Begründung: durchgesetzte Kanalwahl
+  - [PRIMÄR] GraphServiceClientHelper.GetConfig (Z.94-109), Bedingung leere Felder → InvalidConfiguration; GraphMail.GetAttachments (Z.279-320) Größenklassen - Begründung: durchgesetzte Graph-Regeln
+Prüfidee: Leere Graph-AppId → InvalidConfiguration; 200-MB-Anhang → übersprungen mit Warnlog, Mail versendet Rest.
+Tracelinks: StRS-17, StRS-24
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-30
+Titel: SMTP-Versandregeln inkl. Empfängervalidierung
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: System (SMTPMail)
+Vorbedingung: SMTP-Einstellungen vorhanden
+Fakt: SMTPMail.CreateSmtpClient (Z.119-170): leerer SmtpHost → ResultException; EnableSsl = (Host == „smtp.office365.com" || settings.SmtpSslActive); Timeout Math.Max(15, settings.TimeOut)*1000; CreateMailMessage: ungültige TO/CC/BCC → Warning-Ausschluss, ungültiger Absender → AsError.
+Aussage: Das System soll SMTP-Versand ohne Host ablehnen, SSL nur beim office365-Host oder bei expliziter Einstellung aktivieren, das Timeout auf mindestens 15 s setzen und ungültige Empfänger warnend auszuschließen, ungültige Absender aber als Fehler zu werten.
+Ergebnis: Kein Versand ohne Host; Empfängerfehler degradieren, Absenderfehler brechen ab.
+Belege:
+  - [PRIMÄR] SMTPMail.CreateSmtpClient (Z.119-170), Bedingung leerer SmtpHost → ResultException; EnableSsl-Formel; Timeout Math.Max(15, TimeOut)*1000 - Begründung: durchgesetzte SMTP-Regeln
+Prüfidee: SmtpHost leer → ResultException; eine ungültige CC-Adresse → Warnung, Rest versendet; ungültiger Absender → Fehler.
+Tracelinks: StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-31
+Titel: E-Mail-Domain-Blacklist und Kundenerkennung
+Ebene: SyRS
+Typ: Daten
+Qualitätsmerkmal:
+Akteur: System (DomainBlacklistBL)
+Vorbedingung: E-Mail-Adresse zur Kundensuche
+Fakt: DomainBlacklistBL.IsBlacklisted (Z.15-35): Einträge mit @-Präfix exakt („@"+emailDomain), sonst Regex „[@.]domain"; keine @-Teile → AsError „Malformed E-Mail address"; durchgesetzt in ContactPersonBL.SearchAddressContactByEmailAddress nur wenn Setting IsCustomerDetectionOverEMailDomainActive && !blacklisted; Schema dbo.EMailDomainBlacklist (Z.39208): Domain varchar(256) NOT NULL, State NOT NULL.
+Aussage: Das System soll E-Mail-Domänen gegen die Blacklist prüfen (Exaktvergleich bei @-Präfix-Einträgen, sonst Muster [@.]domain), fehlerhafte Adressen als Fehler werten und die Kundenerkennung über E-Mail-Domäne nur bei aktivem Setting und nicht gesperrter Domäne durchführen.
+Ergebnis: Gesperrte Domänen führen nicht zur Kundenzuordnung; defekte Adressen werden als Fehler gemeldet.
+Belege:
+  - [PRIMÄR] DomainBlacklistBL.IsBlacklisted (Z.15-35), Bedingung @-Präfix-Exaktvergleich vs. Regex - Begründung: durchgesetzte Blacklist-Logik
+  - [PRIMÄR] SSMS_DB_SCHEMA.sql Z.39208 (dbo.EMailDomainBlacklist, Domain varchar(256) NOT NULL) - Begründung: Schema der Blacklist
+Prüfidee: Blacklist-Eintrag „@freemail.example" trifft nicht „user@sub.freemail.example", Eintrag „freemail.example" trifft Teilstring; Erkennung deaktiviert → keine Zuordnung.
+Tracelinks: StRS-15
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-32
+Titel: Ticket-Benachrichtigungen ohne Selbstbenachrichtigung
+Ebene: SyRS
+Typ: funktional
+Qualitätsmerkmal:
+Akteur: System (NexusNotificationsBL)
+Vorbedingung: Ticketereignis (Kommentar/Mention/Forward)
+Fakt: NexusNotificationsBL.SaveSimpleTicketNotifications (Z.206-211): Auslöser erhält keine eigene Benachrichtigung außer informAll; Mentions per Regex „\[(?<name>@[^\]]+):(?<id>\d+)\]" → Typ MentionedInComment; SaveForwardTicketNotifications: TicketAssigned/TicketUnassigned, Auslöser ausgeschlossen; NotificationsHubHelper.SendNexusNotification = statischer Delegat, Default No-op (Host registriert Push).
+Aussage: Das System soll Ticket-Benachrichtigungen ohne Selbstbenachrichtigung des Auslösers (Ausnahme informAll), Mention-Benachrichtigungen per definierter Regex und Zuweisungs-/Entzugsmeldungen bei Forward erzeugen; ohne Host-Registrierung läuft der Push als No-op.
+Ergebnis: Adressaten erhalten nur fremdveranlasste Ereignisse; Push-Transport ist austauschbar.
+Belege:
+  - [PRIMÄR] NexusNotificationsBL.SaveSimpleTicketNotifications (Z.206-211) / SaveForwardTicketNotifications, Bedingung Auslöser-Ausschluss außer informAll - Begründung: durchgesetzte Adressatenregeln
+Prüfidee: Kommentierer wird bei eigenem Kommentar nicht benachrichtigt; „[Name:123]" erzeugt MentionedInComment; Forward benachrichtigt neue/entfernte Zuweisungen ohne Auslöser.
+Tracelinks: StRS-17, StRS-16
+Konsolidierung: Kandidat: Auslöser-Ausschluss in SaveSimple- und SaveForward-Pfad doppelt implementiert
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-33
+Titel: Automatische Bereinigung zentraler Benachrichtigungen
+Ebene: SyRS
+Typ: funktional
+Qualitätsmerkmal:
+Akteur: System (CentronNotificationsBL)
+Vorbedingung: Notification-Einstellungen geladen
+Fakt: CentronNotificationsBL.CleanupCentronNotifications (Z.53-68): Bereinigung nur bei settings.DeleteAutomatically; Löschfilter CreatedDate <= now - DeleteAfterDays; CreateFilterExpression: OnlyErrors → LogKind Error || PartlyError.
+Aussage: Das System soll zentrale Benachrichtigungen nur bei aktivierter automatischer Löschung und nur älter als DeleteAfterDays bereinigen; der OnlyErrors-Filter beschränkt die Auswahl auf LogKind Error bzw. PartlyError.
+Ergebnis: Ohne Schaltung keine Löschung; Altbestand ist konfigurierbar begrenzbar.
+Belege:
+  - [PRIMÄR] CentronNotificationsBL.CleanupCentronNotifications (Z.53-68), Bedingung settings.DeleteAutomatically / DeleteAfterDays - Begründung: durchgesetzte Bereinigungsregeln
+Prüfidee: DeleteAutomatically=false → Bestand bleibt; DeleteAfterDays=7 löscht nur Meldungen älter als 7 Tage; OnlyErrors erfasst ausschließlich Error/PartlyError.
+Tracelinks: StRS-17
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-34
+Titel: Volltextsuche mit Stemming und AND-Semantik
+Ebene: SyRS
+Typ: funktional
+Qualitätsmerkmal:
+Akteur: System (IndexSearchBL)
+Vorbedingung: Aufgebauter Suchindex
+Fakt: IndexSearchBL.SearchIndexQueryable (Z.54-72): Stemming (AllowShortWords=true, AllowAlterations=false), Einzel-Queries StartsWith(stemmed), INNER JOIN über (ObjectI3D, Kind) → AND-Semantik; UpdateIndexForObject: fehlgeschlagene Objekte in statischem ConcurrentDictionary, künftig übersprungen; IndexBuilder/GermanAnalyzer: kurze Wörter ≤3 verworfen, Stopwörter nach Stemming.
+Aussage: Das System soll die Volltextsuche über gestemmte Präfix-Queries mit AND-Semantik je Objekt (Join über ObjectI3D und Kind) ausführen, Wörter ≤3 Zeichen und Stopwörter verwerfen und dauerhaft fehlgeschlagene Indexobjekte überspringen.
+Ergebnis: Mehrbegriffsabfragen liefern nur Objekte, die alle Begriffe treffen; Indexierung wird durch Einzelfehler nicht blockiert.
+Belege:
+  - [PRIMÄR] IndexSearchBL.SearchIndexQueryable (Z.54-72), INNER JOIN über (ObjectI3D, Kind) → AND-Semantik - Begründung: durchgesetzte Suchsemantik
+  - [PRIMÄR] IndexBuilder/GermanAnalyzer (Wörter ≤3 verworfen, Stopwörter nach Stemming; ConcurrentDictionary für Fehlobjekte) - Begründung: durchgesetzte Indexregeln
+Prüfidee: Suche „berlin kunde" liefert nur Objekte mit beiden (gestemmten) Begriffen; einmal fehlgeschlagenes Objekt wird bei Folgeindexierungen übersprungen.
+Tracelinks: StRS-30
+Konsolidierung: keine Dublette; dokumentierte Abdeckungslücke: die Volltextsuche hat keine fachliche Entsprechung auf StRS, der Link auf StRS-30 (Berichte) ist nur formaler Anker (siehe Analysebericht, bekannte Lücken).
+Übernahmewürdigkeit: Sonderfall - stilles Überspringen fehlgeschlagener Objekte kann Indexlücken erzeugen; Reparaturpfad vorsehen
+Status: belegt
+
+ID: SyRS-35
+Titel: Windows-Dienst-Lebenszyklus mit Startfehler-Stopp
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: System (CentronService, M105)
+Vorbedingung: Dienst als Windows-Dienst installiert
+Fakt: CentronService.OnStart (M105): Startfehler → Logger.Error + this.Stop(); OnStop → CentronHost.Instance.Stop().
+Aussage: Das System soll als Windows-Dienst Startfehler protokollieren und sich selbst stoppen sowie bei Dienststopp den Host sauber herunterfahren.
+Ergebnis: Fehlgeschlagene Starts sind im Log nachvollziehbar und hinterlassen keinen halben Zustand.
+Belege:
+  - [PRIMÄR] CentronService.OnStart / OnStop (M105), Bedingung Startfehler → Logger.Error + this.Stop() - Begründung: durchgesetzte Lebenszyklusregeln
+Prüfidee: Simulierter Startfehler → Fehlerlogeintrag und Dienststatus „Stopped"; Dienststopp beendet CentronHost.Instance.
+Tracelinks: StRS-27, StRS-28
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-36
+Titel: Konsolen- und Prüfwerkzeuge des Hosts
+Ebene: SyRS
+Typ: Betrieb
+Qualitätsmerkmal:
+Akteur: Bediener ↔ System (Host.Console, M104)
+Vorbedingung: Konsole im Dienst-/Konfigurationsverzeichnis gestartet
+Fakt: Host.Console Program.cs (M104): args []/start → CentronHost.Instance.Start(); Beendigung nur Kommando close/stop bzw. STRG+C; configure <port> <publicUrl> <connectionString> schreibt WebServiceConfigHelper (WebServiceAddress/PublicWebServiceAddress/DatabaseConnectionString); #if ALLOW_HARDWARE_ID_FROM_ENV_VARS → HardwareId aus Umgebungsvariable; SQLServerCheckToolViewModel.CanCheckSqlConnection: vollständig ausgefüllte Instance/DatabaseName/Username/Password erforderlich; SqlHelper.GetConnectionString: MultipleActiveResultSets=true, MaxPoolSize=500.
+Aussage: Das System soll eine Konsole mit Start (args []/start), Beendigung (close/stop, STRG+C) und configure-Befehl (schreibt WebServiceAddress/PublicWebServiceAddress/DatabaseConnectionString) bereitstellen; der SQL-Verbindungstest läuft nur bei vollständigen Zugangsdaten, und generierte Verbindungsstrings aktivieren MARS mit MaxPoolSize=500.
+Ergebnis: Konfiguration ist ohne manuelle XML-Pflege möglich; Verbindungstests scheitern kontrolliert bei unvollständigen Angaben.
+Belege:
+  - [PRIMÄR] Host.Console Program.cs (M104), Befehle start/close/stop/configure und WebServiceConfigHelper-Schreibung - Begründung: durchgesetzte Konsolenbefehle
+  - [PRIMÄR] SQLServerCheckToolViewModel.CanCheckSqlConnection (Pflichtfelder) + SqlHelper.GetConnectionString (MultipleActiveResultSets=true, MaxPoolSize=500) - Begründung: durchgesetzte Prüf- und Verbindungsregeln
+Prüfidee: configure schreibt die drei Werte in WebServiceConfig.xml; Verbindungstest mit leerem Password → abgewiesen; generierter String enthält MARS und MaxPoolSize=500.
+Tracelinks: StRS-27
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-37
+Titel: Versionsauskunft und Versionsschranke
+Ebene: SyRS
+Typ: Schnittstelle
+Qualitätsmerkmal:
+Akteur: Client ↔ System (VersionBL, M088)
+Vorbedingung: Webservice erreichbar
+Fakt: VersionBL.GetWebserviceVersion (M088): nur Assembly-Version als Auskunft; Versionsobergrenze durchgesetzt in LicenseManager.CheckLicenseVersion (in CheckLicense, LicenseManager.cs Z.258-302).
+Aussage: Das System soll die Webservice-Version ausschließlich als Assembly-Version auskunftsfähig halten und Betrieb oberhalb des lizenzierten Produktstands über CheckLicenseVersion verweigern.
+Ergebnis: Versionsabfrage liefert keine Zusatzdaten; Versionsüberschreitung blockiert den Betrieb.
+Belege:
+  - [PRIMÄR] LicenseManager.CheckLicenseVersion (in CheckLicense, LicenseManager.cs Z.258-302), Bedingung Version > lizenzierter Stand → Fehler - Begründung: durchgesetzte Versionsschranke
+  - [SEKUNDÄR] VersionBL.GetWebserviceVersion (M088), nur Assembly-Version - Begründung: Auskunftsumfang im Code
+Prüfidee: GetWebserviceVersion liefert exakt die Assembly-Version; Webservice über lizenziertem Stand → Start-/Betriebsfehler.
+Tracelinks: StRS-25, StRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-38
+Titel: Bereitstellungsarten MSI, Docker und signierter Build
+Ebene: SyRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit (Installierbarkeit/Portierbarkeit)
+Akteur: System (Installer/Build/Deployment)
+Vorbedingung: Build-/Release-Prozess ausgeführt
+Fakt: WixSharpInstaller Program.cs: ServiceInstaller Name=CentronNexus, Start auto (Z.42-55); MajorUpgrade AllowSameVersionUpgrades (Z.27-31, MSI prüft 3 Versionsstellen); docker/compose/compose.yaml: Stack db (1433, MSSQL_SA_PASSWORD), webservice (4321→1234, HARDWARE_ID, mountet WebServiceConfig.xml), smtp (mailcatcher 1025/1080), nexus (8050, appsettings.Production.json), depends_on, restart on-failure; Dockerfile Multi-Stage alpine, ARG dx_license, TZ=Europe/Berlin, ICU+msttcorefonts; ACR centron.azurecr.io, ACR-Token je Kunde via scope-map; Centron.Scripts/Program.cs: DeleteSubDirectoriesOtherThan(PublishDir, „de", „en") nach jedem Build (Z.105-226), Targets build/build-installer (Z.290-292), SignHelper (Code Signing).
+Aussage: Das System soll per MSI als Autostart-Dienst „CentronNexus" mit gleichversionierten Major-Upgrades sowie per Docker-Stack (db/webservice/smtp/nexus mit Neustart-Policy on-failure) bereitstellbar sein; Builds bereinigen Sprachverzeichnisse auf de/en und signieren Artefakte.
+Ergebnis: Zwei gepflegte Bereitstellungswege; nur signierte, sprachbereinigte Artefakte werden ausgeliefert.
+Belege:
+  - [SEKUNDÄR] WixSharpInstaller Program.cs (Z.42-55, Z.27-31) - Begründung: Installer-Konfiguration
+  - [SEKUNDÄR] compose.yaml/Dockerfile; Centron.Scripts/Program.cs (Z.105-226, Z.290-292) + SignHelper - Begründung: Deployment- und Build-Konfiguration
+Prüfidee: MSI-Installation richtet Dienst CentronNexus mit Autostart ein; docker compose up bringt alle vier Dienste hoch; Build entfernt alle Sprachordner außer de/en.
+Tracelinks: StRS-27, StRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-39
+Titel: QS-Pipelines für Build, Regression, Playwright und Security
+Ebene: SyRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Wartbarkeit (Analysebarkeit/Testbarkeit)
+Akteur: System (CI)
+Vorbedingung: Push/PR bzw. cron-Auslösung
+Fakt: Azure build-pipeline.yml: trigger master, release/*; IsDevBuild=PR; DownloadSecureFile Code-Signing-Zertifikat; regression-tests-pipeline.yml: DB-Container centron_db/regression_tests, sa/SA!password; azure-blazor: nexus-unit-tests.yaml (dotnet test-only via Scripts), playwright-pipeline.yml Matrix default|version2|views mit DB-Container je Variante; security-pipeline.yaml: cron 0 0 * * *, CodeQL (csharp,javascript) + Dependency-Scanning; .github tests.yml (workflow_dispatch + PR/Push main/release/**, cancel-in-progress nur PR); build.yml mit sign-artifacts-Composite-Action.
+Aussage: Das System soll seine Qualitätssicherung als Pipelines ausführen: Builds mit Zertifikatsdownload und Signierung, Regressionstests gegen DB-Container, Playwright-Matrix (default|version2|views), tägliche CodeQL-/Abhängigkeitsscans (cron 0 0 * * *) und GitHub-Workflows mit PR-abbruchendem cancel-in-progress.
+Ergebnis: Jeder Push/PR durchläuft definierte Tests- und Sicherheitsgates; Scans laufen täglich.
+Belege:
+  - [SEKUNDÄR] Azure build-pipeline.yml / regression-tests-pipeline.yml / security-pipeline.yaml / playwright-pipeline.yml - Begründung: Pipeline-Konfiguration
+  - [SEKUNDÄR] .github tests.yml / build.yml (sign-artifacts-Composite-Action) - Begründung: Workflow-Konfiguration
+Prüfidee: PR löst tests.yml mit cancel-in-progress aus; security-pipeline.yaml läuft zum cron-Termin mit CodeQL csharp+javascript; Playwright-Varianten laufen je mit eigenem DB-Container.
+Tracelinks: StRS-29
+Konsolidierung: Kandidat: DB-Container-Bereitstellung in regression- und playwright-Pipelines doppelt definiert
+Übernahmewürdigkeit: übernehmen
+Status: belegt
+
+ID: SyRS-40
+Titel: Betriebsdokumentationsstruktur
+Ebene: SyRS
+Typ: nicht-funktional
+Qualitätsmerkmal: Wartbarkeit (Dokumentation/Analysebarkeit)
+Akteur: System (Dokumentation)
+Vorbedingung: Repository mit docs/
+Fakt: docs/README.md: Gliederung getting-started/guides/reference/operations.
+Aussage: Das System soll seine Betriebsdokumentation mit den festen Bereichen getting-started, guides, reference und operations führen.
+Ergebnis: Einstieg, Anleitungen, Referenz und Betrieb sind dokumentarisch getrennt auffindbar.
+Belege:
+  - [SEKUNDÄR] docs/README.md (Gliederung getting-started/guides/reference/operations) - Begründung: Doku-Struktur im Repository
+Prüfidee: docs/README.md enthält alle vier Abschnitte mit verlinkten Unterseiten.
+Tracelinks: StRS-29
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen
+Status: belegt

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/Traceability.md

@@ -0,0 +1,207 @@
+# Traceability
+
+Konsolidierte Trace-Tabelle. Spalten: SwRS-ID | SyRS-ID | StRS-ID | Hauptbeleg (Modul: Stelle). Tracelinks im Detail stehen in den Anforderungsdateien; hier die Zusammenführung.
+
+## SwRS-Anforderungen (SwRS-1 - SwRS-146)
+
+| SwRS | SyRS | StRS | Beleg (Kurzform) |
+|---|---|---|---|
+| SwRS-1 | SyRS-1 | StRS-2, StRS-9, StRS-19 | M001 BankAccountBL.Save/Delete/Get |
+| SwRS-2 | SyRS-21 | StRS-11 | M019 BookKeepingExportBL/ImportBL |
+| SwRS-3 | SyRS-23 | StRS-9 | M019 PaymentTransactionBL.RefreshBankInformation |
+| SwRS-4 | SyRS-11, SyRS-22 | StRS-8 | M029 PaymentsBL.DeleteIncomingPayment |
+| SwRS-5 | SyRS-22, SyRS-23 | StRS-8, StRS-12 | M029 OnlineBankingAccountTransactionsBL |
+| SwRS-6 | SyRS-23 | StRS-3, StRS-8 | M029 OnlineBankingConfigurationBL |
+| SwRS-7 | SyRS-22, SyRS-11 | StRS-7 | M060 ReceiptBL.UpdateReceiptIsPaid |
+| SwRS-8 | SyRS-11, SyRS-21 | StRS-2, StRS-7, StRS-11 | M060 ReceiptInvoiceBL.CancelInvoice |
+| SwRS-9 | SyRS-23 | StRS-7 | M060 FixInvoice; RechKopf.IsFixed |
+| SwRS-10 | SyRS-23 | StRS-8 | M060 CashBookBookingBL |
+| SwRS-11 | SyRS-23 | StRS-12 | M083 GetActivedVoucherBarcodes |
+| SwRS-12 | SyRS-22 | StRS-10 | M110 DunningStopViewModel |
+| SwRS-13 | SyRS-14 | StRS-11 | M114 ExportData |
+| SwRS-14 | SyRS-22 | StRS-8 | M119 CheckNewAssignedAmount |
+| SwRS-15 | SyRS-23 | StRS-16 | M013 CentronChecklistBL/UpdateChecklistBL |
+| SwRS-16 | SyRS-25 | StRS-19 | M035 ChecklistVirtualObjectCategoryBL |
+| SwRS-17 | SyRS-17, SyRS-18 | StRS-15, StRS-6 | M062 SelfCareBL |
+| SwRS-18 | SyRS-2, SyRS-11 | StRS-17 | M071 TaskManagementHelpdeskActionHandler |
+| SwRS-19 | SyRS-23 | StRS-20, StRS-16 | M074 TicketProjectBL |
+| SwRS-20 | SyRS-18 | StRS-6 | M087 WebHDQuestionBL/WebSettingBL |
+| SwRS-21 | SyRS-9 | StRS-16 | M113 CloseHelpdeskHelper |
+| SwRS-22 | SyRS-11, SyRS-8 | StRS-2, StRS-16 | M113 TicketLogicHelper/TicketListViewModel |
+| SwRS-23 | SyRS-23 | StRS-18 | M124 NewRma/CheckForthState |
+| SwRS-24 | SyRS-1, SyRS-23 | StRS-2, StRS-19 | M002 AccountBL |
+| SwRS-25 | SyRS-23 | StRS-21 | M006 SearchSupplierBL |
+| SwRS-26 | SyRS-23 | StRS-22 | M015 CountryBL |
+| SwRS-27 | SyRS-23 | StRS-18, StRS-19 | M017 RmaBL/InterestBL/ContactActivityBL |
+| SwRS-28 | SyRS-23 | StRS-19 | M020 AccountDeviceBL |
+| SwRS-29 | SyRS-23 | StRS-24 | M028 ExternalToolBL |
+| SwRS-30 | SyRS-23 | StRS-20 | M048 ObjectExternalReferenceBL |
+| SwRS-31 | SyRS-23 | StRS-15 | M064 SocialMediaBL |
+| SwRS-32 | SyRS-23 | - | M069 TagsBL |
+| SwRS-33 | SyRS-23 | StRS-20 | M073 TextModuleBL |
+| SwRS-34 | SyRS-23 | StRS-6 | M081 SimpleUrlBL |
+| SwRS-35 | SyRS-18, SyRS-23 | StRS-15, StRS-6 | M085 WebLinkBL |
+| SwRS-36 | SyRS-23 | StRS-21 | M007 DistributorBL |
+| SwRS-37 | SyRS-15 | StRS-21, StRS-24 | M023 EDIDispatcherBL/Alltron/Also |
+| SwRS-38 | SyRS-23 | StRS-23 | M036 StockBL |
+| SwRS-39 | SyRS-2 | StRS-25 | M053 ProductionBL |
+| SwRS-40 | SyRS-23 | StRS-22 | M054 ProductMatrixBL |
+| SwRS-41 | SyRS-23 | StRS-21 | M056 OrderSuggestionListBL |
+| SwRS-42 | SyRS-35 | StRS-23 | M067 StorageBL (veraltet) |
+| SwRS-43 | SyRS-23 | StRS-22 | M084 ArticleStockBL |
+| SwRS-44 | SyRS-28 | StRS-23 | M084 ArticleLogBL.WriteAmountChangeLog |
+| SwRS-45 | SyRS-14 | StRS-8, StRS-24 | M092 Libfintx |
+| SwRS-46 | SyRS-9 | StRS-22 | M111 AddActionPriceViewModel/PositionViewModel |
+| SwRS-47 | SyRS-23 | StRS-21 | M117 SuggestionQuantity/EDIInvoiceViewModel |
+| SwRS-48 | SyRS-23 | StRS-13, StRS-22 | M123 SpecialArticleImportSettings |
+| SwRS-49 | SyRS-1, SyRS-27 | StRS-2 | M003 AppRightsBL |
+| SwRS-50 | SyRS-2, SyRS-3 | StRS-1, StRS-25 | M003 Authenticator/LicenseManager |
+| SwRS-51 | SyRS-6 | StRS-1 | M003 UsersBL/BasicAuthenticator |
+| SwRS-52 | SyRS-5 | StRS-1 | M003 TwoFactorAuthBL |
+| SwRS-53 | SyRS-19 | StRS-4, StRS-3 | M005 AiApiLinkValidator |
+| SwRS-54 | SyRS-23, SyRS-35 | - | M042 ModuleBL |
+| SwRS-55 | SyRS-2, SyRS-11 | StRS-5, StRS-3 | M050/M051 Passwort-Management/Manager |
+| SwRS-56 | SyRS-1 | StRS-14 | M061 PdfSigningBL |
+| SwRS-57 | SyRS-5 | StRS-1 | M080 TwoFactorAuthenticationBL |
+| SwRS-58 | SyRS-37 | StRS-27 | M088 VersionBL |
+| SwRS-59 | SyRS-1, SyRS-2 | StRS-4 | M112 MandatorManagement/SqlManager [HYP] |
+| SwRS-60 | SyRS-14, SyRS-11 | StRS-4 | M120 ArtificialIntelligenceChatCoordinator |
+| SwRS-61 | SyRS-23 | StRS-3, StRS-5 | M024 EmployeeRfidTokenBL |
+| SwRS-62 | SyRS-35 | - | M024 EmployeeHolidayBL (veraltet) |
+| SwRS-63 | SyRS-23 | StRS-21, StRS-22 | M030 CustomGatewayBL |
+| SwRS-64 | SyRS-1, SyRS-23 | StRS-2 | M031 UiProfileBL |
+| SwRS-65 | SyRS-23 | StRS-19 | M034 EsCustomerGroupBL/EsRoleBL |
+| SwRS-66 | SyRS-23 | StRS-13, StRS-22 | M040 MassUpdateBL |
+| SwRS-67 | SyRS-23 | - | M043 QuickNoteBL |
+| SwRS-68 | SyRS-32 | - | M044 MyDayBL/MyDayNotificationsBL |
+| SwRS-69 | SyRS-6, SyRS-8 | StRS-24 | M059 RiverDivoBL/RiverConnectionBL |
+| SwRS-70 | SyRS-24 | StRS-15 | M059 RiverConnectionBL (fremder Kunde) |
+| SwRS-71 | SyRS-23 | - | M075 TimingSettings (Schema) |
+| SwRS-72 | SyRS-11 | StRS-2 | M076 ToDoBL.UpdateTodoDiscardedFlag |
+| SwRS-73 | SyRS-23 | StRS-7 | M076 HandleReceiptToDoEntries |
+| SwRS-74 | SyRS-23 | - | M077 ToolBL.ChangeTextFormat |
+| SwRS-75 | SyRS-23 | StRS-21 | M078 TradePoolXmlLogic |
+| SwRS-76 | SyRS-6 | StRS-1 | M078 TradePoolBL.AuthenticateUser |
+| SwRS-77 | SyRS-23 | - | M079 TransactionBL |
+| SwRS-78 | SyRS-1, SyRS-2 | StRS-25 | M115 ModuleRegistration/TodoListViewModel |
+| SwRS-79 | SyRS-1, SyRS-2 | StRS-25, StRS-2 | M116 ManagementInfoViewModel/Registrierung |
+| SwRS-80 | SyRS-2 | StRS-25 | M118 MSPComparer/CustomPropertiesConnector |
+| SwRS-81 | SyRS-1, SyRS-10 | StRS-1 | M086 AccessTokenWebServiceBL |
+| SwRS-82 | SyRS-2 | StRS-25 | M086 TicketWebServiceBL |
+| SwRS-83 | SyRS-15, SyRS-19 | - | M102 CentronWebService |
+| SwRS-84 | SyRS-8, SyRS-9, SyRS-11 | - | M103 TicketAuthenticationHandler/Interceptors |
+| SwRS-85 | SyRS-12, SyRS-13, SyRS-14, SyRS-16, SyRS-2 | - | M103 CentronHost.Start/SecretKeyHandler |
+| SwRS-86 | SyRS-35, SyRS-38 | - | M104/M105 Host.Console/CentronService |
+| SwRS-87 | SyRS-10, SyRS-1 | StRS-2 | M106 UserRightAuthorizationFilter |
+| SwRS-88 | SyRS-19 | - | M107 SQLServerCheckTool/SqlHelper |
+| SwRS-89 | SyRS-17, SyRS-15 | StRS-6 | M010/M041 CentronNexusBL/MobileBL |
+| SwRS-90 | SyRS-32, SyRS-16 | StRS-17 | M045 NexusNotificationsBL |
+| SwRS-91 | SyRS-18 | StRS-15 | M046 NexusTicketViewBL |
+| SwRS-92 | SyRS-33 | StRS-17 | M047 CentronNotificationsBL/UserNotificationBL |
+| SwRS-93 | SyRS-19 | - | M049 OutlookAssetKindSearchBL (Bug) |
+| SwRS-94 | SyRS-18 | StRS-6 | M125 AuthController |
+| SwRS-95 | SyRS-18 | StRS-15 | M125 DocumentSigningPage.razor |
+| SwRS-96 | SyRS-18, SyRS-1 | StRS-15 | M125 PublicWebFormPage/CurrentCartService |
+| SwRS-97 | SyRS-17, SyRS-18 | StRS-6 | M126 Program.cs/PortAuthorization |
+| SwRS-98 | SyRS-19 | - | M127 DocumentsTab.razor |
+| SwRS-99 | - | StRS-11 | M094 EbInterfaceLogic |
+| SwRS-100 | - | StRS-24 | M095 CentronGlsLogic |
+| SwRS-101 | - | StRS-24 | M096 CentronShipcloudLogic |
+| SwRS-102 | - | StRS-24 | M097 CopApi |
+| SwRS-103 | - | StRS-24 | M098 EgisApi |
+| SwRS-104 | - | StRS-8, StRS-24 | M099 FinAPI-RestClient |
+| SwRS-105 | - | StRS-24 | M100/M101 Icecat/ITscope |
+| SwRS-106 | - | StRS-24, StRS-1 | M140 docuFORM-OAuthHelper |
+| SwRS-107 | SyRS-1 | StRS-2 | M031 UiProfileBL (global/privat) |
+| SwRS-108 | - | StRS-7 | M040 MassUpdateBL (Ausschlüsse) |
+| SwRS-109 | SyRS-2, SyRS-1 | StRS-25 | M108 ModuleRegistration (Engine) |
+| SwRS-110 | SyRS-19, SyRS-1 | - | M108 ModuleListContainer/FrontWindow |
+| SwRS-111 | SyRS-2, SyRS-1 | StRS-25 | M115 Dashboard-Registrierung |
+| SwRS-112 | SyRS-2, SyRS-1 | StRS-25 | M116/M118 Statistik-/MSP-Registrierung |
+| SwRS-113 | SyRS-2, SyRS-1 | StRS-25 | M121/M122 Survey/MassUpdates |
+| SwRS-114 | SyRS-15 | StRS-1, StRS-3 | M128 GoogleAuthenticatorViewModel |
+| SwRS-115 | - | StRS-1 | M130 Totp/CentronBindableBase |
+| SwRS-116 | SyRS-29, SyRS-23 | StRS-15 | M004 AppointmentRequestBL |
+| SwRS-117 | SyRS-29 | StRS-28 | M008 CalendarBL (Defekt) |
+| SwRS-118 | SyRS-23 | StRS-28 | M009 CentronIconsBL (Defekt) |
+| SwRS-119 | SyRS-21 | - | M011 ImportHistoryBL/BaseBL |
+| SwRS-120 | SyRS-1, SyRS-20 | StRS-2 | M012 ChatBL |
+| SwRS-121 | SyRS-35 | StRS-3, StRS-5, StRS-15, StRS-24 | M016 CPraConfiguration/Connector |
+| SwRS-122 | SyRS-23 | StRS-20 | M018 CustomTableBL + M014 ReplacementBL |
+| SwRS-123 | SyRS-23 | StRS-19 | M021 AssetManagementArticleAssignmentBL |
+| SwRS-124 | SyRS-1, SyRS-21 | StRS-2 | M022 DocumentationBL |
+| SwRS-125 | SyRS-32 | StRS-16 | M025 TicketExpiredException |
+| SwRS-126 | SyRS-21, SyRS-23 | - | M026 ExpectedEventsBL |
+| SwRS-127 | SyRS-23 | StRS-15 | M027 ExternalHelpdeskConfigurationBL |
+| SwRS-128 | SyRS-1 | StRS-2, StRS-6 | M027 Rechteprüfung [HYP] |
+| SwRS-129 | SyRS-29 | StRS-24, StRS-28 | M032 GraphServiceClientHelper |
+| SwRS-130 | SyRS-34 | StRS-6, StRS-28 | M033 IndexSearchBL |
+| SwRS-131 | SyRS-29, SyRS-30 | - | M037 MailSignatureBL |
+| SwRS-132 | SyRS-23 | StRS-28 | M038 MailingDataBL (Defekt) |
+| SwRS-133 | SyRS-1, SyRS-29 | StRS-2, StRS-3, StRS-5 | M039 MailScannerBL |
+| SwRS-134 | SyRS-23 | - | M052 ProcessBL |
+| SwRS-135 | SyRS-23 | - | M055 ProjectBL |
+| SwRS-136 | SyRS-23 | StRS-30 | M057 ReportDataQueryBL |
+| SwRS-137 | SyRS-20 | StRS-30 | M057 ReportDataBL.ExecuteQuery |
+| SwRS-138 | SyRS-20 | StRS-30 | M058 ReportsBL.GetRawSqlResult |
+| SwRS-139 | SyRS-1, SyRS-23 | StRS-2 | M082 VideoPortalAssignmentBL |
+| SwRS-140 | SyRS-23 | StRS-1, StRS-3, StRS-5 | M014 CryptoUtils |
+| SwRS-141 | SyRS-29, SyRS-30 | StRS-24, StRS-28 | M089 DeveloperSecurity.Email |
+| SwRS-142 | SyRS-1 | StRS-1, StRS-2 | M089 ModuleFeatures |
+| SwRS-143 | SyRS-1 | StRS-2 | M066 EmployeeUtilizationBL |
+| SwRS-144 | SyRS-35 | - | M065 StartBL (Stubs) |
+| SwRS-145 | SyRS-24 | - | M068 SystemTableI3DBL |
+| SwRS-146 | SyRS-23 | StRS-28 | M070 PhoneCallBL |
+
+Anmerkungen zur Tabelle:
+- Ebenensprung direkt auf StRS (keine eigene SyRS-Verankerung, fachlich projektlokal und über StRS-24 bzw. StRS-14 vermittelt): SwRS-99, SwRS-100, SwRS-101, SwRS-102, SwRS-103, SwRS-104, SwRS-105, SwRS-106, SwRS-108. Begründung und Abdeckungsbewertung: Analysebericht.md (bekannte Lücken).
+- Belegnotiz in der SwRS-93-Zeile verweist auf den dokumentierten Alias-Befund (M049).
+
+## SyRS-Anforderungen (SyRS-1 - SyRS-40) zu StRS
+
+| SyRS | StRS |
+|---|---|
+| SyRS-1 | StRS-2 |
+| SyRS-2 | StRS-1, StRS-25 |
+| SyRS-3 | StRS-1, StRS-25 |
+| SyRS-4 | StRS-1, StRS-2 |
+| SyRS-5 | StRS-1 |
+| SyRS-6 | StRS-1, StRS-3 |
+| SyRS-7 | StRS-6, StRS-15 |
+| SyRS-8 | StRS-1 |
+| SyRS-9 | StRS-1, StRS-2 |
+| SyRS-10 | StRS-2 |
+| SyRS-11 | StRS-2, StRS-1 |
+| SyRS-12 | StRS-6, StRS-25 |
+| SyRS-13 | StRS-6 |
+| SyRS-14 | StRS-24 |
+| SyRS-15 | StRS-24, StRS-6 |
+| SyRS-16 | StRS-24, StRS-17 |
+| SyRS-17 | StRS-6 |
+| SyRS-18 | StRS-6, StRS-15 |
+| SyRS-19 | StRS-24, StRS-1 |
+| SyRS-20 | StRS-28 |
+| SyRS-21 | StRS-7 |
+| SyRS-22 | StRS-7 |
+| SyRS-23 | StRS-20, StRS-19 |
+| SyRS-24 | StRS-20 |
+| SyRS-25 | StRS-26, StRS-30 |
+| SyRS-26 | StRS-24 |
+| SyRS-27 | StRS-2 |
+| SyRS-28 | StRS-29 |
+| SyRS-29 | StRS-17, StRS-24 |
+| SyRS-30 | StRS-17 |
+| SyRS-31 | StRS-15 |
+| SyRS-32 | StRS-17, StRS-16 |
+| SyRS-33 | StRS-17 |
+| SyRS-34 | StRS-30 (nur formaler Anker, fachliche Entsprechung fehlt - dokumentierte Lücke) |
+| SyRS-35 | StRS-27, StRS-28 |
+| SyRS-36 | StRS-27 |
+| SyRS-37 | StRS-25, StRS-29 |
+| SyRS-38 | StRS-27, StRS-29 |
+| SyRS-39 | StRS-29 |
+| SyRS-40 | StRS-29 |
+
+## StRS-Ebene
+
+StRS-1 bis StRS-30 sind die Wurzelebene; nachgelagerte Verlinkung siehe obige Tabellen.

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Protokoll.md

@@ -0,0 +1,128 @@
+# Messprotokoll – Iteration 9/z-ai/glm-5.3-flash/custom/high
+
+> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
+> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
+
+## Lauf
+- **Prompt-Datei:** `02_Prompt.md`
+- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
+- **Startzeit:** 2026-09-02T10:42:42.6471885+02:00
+- **Endzeit:** 2026-09-02T12:51:54.2454720+02:00
+- **Dauer gesamt:** 02:09:08 (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):** `z-ai/glm-5.3-flash`
+- **Modell (tatsaechlich):** `z-ai/glm-5.3-flash`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 9/z-ai/glm-5.3-flash/custom/high/`
+- **Agentenmodus:** `custom`
+- **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` = 30, `completed` = 30, `failed` = 0
+- **Rollen:** {"modulinventar": 1, "faktenermittler": 13, "strs-autor": 3, "syrs-autor": 2, "swrs-autor": 8, "belegpruefer": 1, "iso29148-orchestrator": 1, "konsistenzpruefer": 1}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 7.648.623 |
+| Output-Tokens | 203.967 |
+| Reasoning-Tokens | 69.486 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 45 |
+
+**Tokens gesamt: 11.467.996.** 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 | 30 | 13,9 % |
+| SyRS | 40 | 18,5 % |
+| SwRS | 146 | 67,6 % |
+| **Gesamt** | **216** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 83 | 38,4 % |
+| Sicherheit | 55 | 25,5 % |
+| Daten | 43 | 19,9 % |
+| Schnittstelle | 18 | 8,3 % |
+| nicht-funktional | 11 | 5,1 % |
+| Betrieb | 6 | 2,8 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 422 |
+| davon `PRIMÄR` | 302 (71,6 %) |
+| davon `SEKUNDÄR` | 98 (23,2 %) |
+| davon `KONTEXT` | 22 (5,2 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 198 (91,7 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 159 | 73,6 % |
+| workaround | 41 | 19,0 % |
+| sonderfall | 14 | 6,5 % |
+| veraltet | 2 | 0,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 212 | 98,1 % |
+| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 66 | 30,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 42 | 19,4 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 2 von 80 ungedeckt: SwRS-127, SwRS-135 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 216 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 216 von 216 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9eb70d9bffeU6O643v8e3i1th`
+- **Werkzeugaufrufe:** 81 – {"read": 4, "bash": 19, "task": 30, "write": 10, "grep": 2, "edit": 16}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 30
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-02T08:42:44.122853+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse)
+[2026-09-02T08:42:44.241827+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T10:51:52.441929+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T10:51:54.138218+00:00] OpenCode export: Exporting session: ses_f9eb70d9bffeU6O643v8e3i1th
+[2026-09-02T10:51:54.222501+00:00] Ende: Exitcode=0; Status=success; Turns=45; Tokens=11467996; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\RawResult.json

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/anforderungen.md

@@ -0,0 +1,66 @@
+## 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 | 30 | 13,9 % |
+| SyRS | 40 | 18,5 % |
+| SwRS | 146 | 67,6 % |
+| **Gesamt** | **216** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 83 | 38,4 % |
+| Sicherheit | 55 | 25,5 % |
+| Daten | 43 | 19,9 % |
+| Schnittstelle | 18 | 8,3 % |
+| nicht-funktional | 11 | 5,1 % |
+| Betrieb | 6 | 2,8 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 422 |
+| davon `PRIMÄR` | 302 (71,6 %) |
+| davon `SEKUNDÄR` | 98 (23,2 %) |
+| davon `KONTEXT` | 22 (5,2 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 198 (91,7 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 159 | 73,6 % |
+| workaround | 41 | 19,0 % |
+| sonderfall | 14 | 6,5 % |
+| veraltet | 2 | 0,9 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 212 | 98,1 % |
+| als `HYPOTHESE` gekennzeichnet | 4 | 1,9 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 66 | 30,6 % |
+| mit ISO-25010-Qualitätsmerkmal | 42 | 19,4 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 2 von 80 ungedeckt: SwRS-127, SwRS-135 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 216 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 216 von 216 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/combined_prompt.md

@@ -0,0 +1,218 @@
+# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
+
+## Metadaten
+- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
+- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
+- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-31
+- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
+- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
+
+  | Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
+  |---|---|
+  | Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
+  | In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
+  | In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
+  | In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
+  | In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
+  | Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
+
+  **Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
+
+  Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
+> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
+> beim Start bei.
+
+---
+
+## 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.
+
+### Arbeitsteilung
+
+Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
+
+- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
+- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
+- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
+- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
+- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
+- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
+- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
+- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
+
+**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
+
+### 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?
+
+
+### 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 beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
+swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
+Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+
+Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
+Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
+
+| Teilaufgabe | Vorgesehener Bearbeiter |
+|---|---|
+| Modulinventar (Schritt 0) | modulinventar |
+| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
+| Formulierung der StRS-Anforderungen | strs-autor |
+| Formulierung der SyRS-Anforderungen | syrs-autor |
+| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
+| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
+| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
+| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
+
+Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
+entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
+lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
+bleiben deine Aufgabe.
+
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\z-ai\glm-5.3-flash\custom\high\02_Lauf_2026-09-02_104242_v13.0.0-b971\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/endzeit.txt

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

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/opencode-config.json

@@ -0,0 +1,648 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "provider": {
+    "tensorx": {
+      "npm": "@ai-sdk/openai-compatible",
+      "name": "TensorX",
+      "options": {
+        "baseURL": "https://api.tensorx.ai/v1"
+      },
+      "models": {
+        "qwen/qwen3.8-flash-next": {
+          "name": "Qwen 3.8 Flash Next",
+          "limit": {
+            "context": 262144,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.2": {
+          "name": "GLM 5.2",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          },
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "z-ai/glm-5.3-flash": {
+          "name": "GLM 5.3 Flash",
+          "variants": {
+            "low": {
+              "thinking": {
+                "type": "enabled",
+                "level": "low"
+              }
+            },
+            "medium": {
+              "thinking": {
+                "type": "enabled",
+                "level": "medium"
+              }
+            },
+            "high": {
+              "thinking": {
+                "type": "enabled",
+                "level": "high"
+              }
+            },
+            "xhigh": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            },
+            "max": {
+              "thinking": {
+                "type": "enabled",
+                "level": "xhigh"
+              }
+            }
+          }
+        },
+        "moonshotai/kimi-k3": {
+          "name": "Kimi K3",
+          "limit": {
+            "context": 1048576,
+            "output": 131072
+          }
+        }
+      }
+    }
+  },
+  "model": "tensorx/z-ai/glm-5.3-flash",
+  "permission": {
+    "*": "deny",
+    "read": "allow",
+    "glob": "allow",
+    "grep": "allow",
+    "list": "allow",
+    "edit": {
+      "*": "deny",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow"
+    },
+    "external_directory": {
+      "*": "deny",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
+      "../../Ergebnisse": "allow",
+      "../../Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/Ergebnisse/**": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
+      "C:/DEV/MasterArbeit/Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse/**": "allow",
+      "Ergebnisse": "allow",
+      "Ergebnisse/**": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/spiegel/Ergebnisse": "allow",
+      "Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_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",
+      "modulinventar": "allow",
+      "faktenermittler": "allow",
+      "strs-autor": "allow",
+      "syrs-autor": "allow",
+      "swrs-autor": "allow",
+      "belegpruefer": "allow",
+      "konsistenzpruefer": "allow",
+      "iso29148-orchestrator": "allow"
+    },
+    "webfetch": "deny",
+    "websearch": "deny",
+    "skill": "deny",
+    "question": "deny"
+  },
+  "agent": {
+    "build": {
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "mode": "primary"
+    },
+    "general": {
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "mode": "subagent"
+    },
+    "explore": {
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "mode": "subagent"
+    },
+    "modulinventar": {
+      "description": "Schritt 0: erstellt das vollständige Modulinventar als Bezugsgröße für die Abdeckung, mit Buchführung über zugeordnete und nicht zugeordnete Quelldateien. Erzeugt KEINE Anforderungen.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du erstellst das Modulinventar für ein Reverse-Requirements-Engineering-Vorhaben an einer Legacy-ERP-Suite. Du formulierst KEINE Anforderungen. Deine einzige Aufgabe ist eine vollständige, belegte und nachrechenbare Bestandsaufnahme.\n\n## Vorgehen\n\n1. Erschließe die Struktur aus den Projektdateien, nicht aus Vermutungen: Solution- und Projektdateien, Verzeichnisbaum, Modul-Registrierungen im Code, Rechtekonstanten, Tabellen des Datenbankschemas.\n2. Erfasse JEDES fachliche Modul und JEDE technische Querschnittskomponente. Ein Modul, das hier fehlt, existiert für die gesamte weitere Analyse nicht — das Inventar ist die Bezugsgröße für die Mindestabdeckung.\n3. Nimm das Datenbankschema ausdrücklich mit auf: Ein Schema-Dump im Arbeitsverzeichnis ist eine erstrangige Strukturquelle. Ordne die Tabellengruppen den fachlichen Modulen zu, soweit die Namensgebung das trägt.\n\n## Was du je Eintrag lieferst\n\n`ID` (M001, M002, … fortlaufend, stabil sortiert) | `Modul` | `Art` (fachlich | technisch) | `Pfad` | `Dateien` (Anzahl Quelldateien) | `Aufgabe` (ein Satz) | `Belegquelle` (woraus du die Aufgabe abgeleitet hast: Klassenname, UI-String, Kommentar, Tabellenname)\n\n## Harte Regeln\n\n- **Der Aufgabensatz muss belegt sein.** Leite ihn aus dem ab, was du tatsächlich gelesen hast. Ein Ordnername ist kein Beleg. Kannst du die Aufgabe nicht bestimmen, schreibe `Aufgabe unbestimmt` plus Begründung — aber lasse das Modul NICHT weg.\n- **Kein Zuschnitt nach Bequemlichkeit.** Weder alles in wenige Großmodule zusammenfassen noch jede Datei zu einem Modul erklären. Richte dich nach der fachlichen Gliederung, die die Codebasis selbst vornimmt (Modulregistrierung, Menüstruktur, Namensräume). Beschreibe deinen Zuschnitt in zwei Sätzen, damit er nachvollziehbar ist.\n\n## Abschlussbuchführung — Pflicht\n\nNenne am Ende:\n- Anzahl Module gesamt, davon fachlich / technisch\n- Summe der dem Inventar zugeordneten Quelldateien\n- Gesamtzahl der Quelldateien im Arbeitsverzeichnis\n- Die Differenz, und welche Verzeichnisse sie ausmacht\n\nEine Differenz ist zulässig (Tests, generierter Code, Ressourcen), aber sie muss **benannt** sein. Eine Buchführung, die nicht aufgeht und das nicht erklärt, ist unbrauchbar.\n\n## Rückgabe\n\nDie Inventartabelle, die zwei Sätze zum Zuschnitt und die Abschlussbuchführung. Keine Einleitung, keine Zusammenfassung, keine Empfehlungen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "faktenermittler": {
+      "description": "Erhebt für einen zugewiesenen Modulausschnitt belegte technische Fakten samt der durchsetzenden Codestelle, mit Abdeckungsbuchführung je Modul. Formuliert KEINE Anforderungen.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du erhebst Fakten aus einer Legacy-ERP-Codebasis. Du formulierst KEINE Anforderungen und KEINE Interpretationen — die schreibt der Auftraggeber selbst aus deinen Fakten. Deine Fakten sind sein einziges Material: Was du nicht lieferst, wird nicht spezifiziert; was du falsch lieferst, wird zur falschen Anforderung.\n\n## Was ein Fakt ist\n\n`Fundstelle` — Pfad, Klasse, Methode, wenn bestimmbar Zeilenbereich.\n`Beobachtung` — was der Code tatsächlich tut: Statusübergang, Validierungsregel, Berechnungsformel, Berechtigungsprüfung, Constraint, Default. Die tragende Bedingung wörtlich oder eng paraphrasiert.\n`Einstufung` — nach der Rubrik unten.\n`Modul` — die Inventar-ID, zu der der Fakt gehört.\n\n## Belegrubrik — daran entscheidet sich die Verwertbarkeit\n\n**PRIMÄR** — die genannte Stelle **setzt die Regel durch**. Man kann hingehen und die Bedingung lesen.\n> `AppRightsBL.cs, GetRightsFromCurrentUser(AppUser)` — iteriert `user.Groups` und sammelt `group.Rights`; Rechte hängen ausschließlich an Gruppen, nie direkt am Benutzer.\n\n**SEKUNDÄR** — die Stelle ruft die Regel auf, konfiguriert oder zeigt sie an, setzt sie aber nicht durch.\n> `AppUserGroupBL.cs` — verwaltet die Gruppenzuordnung, auf der die Rechteprüfung aufbaut.\n\n**KONTEXT** — Umfeld, das die Aussage stützt, ohne sie zu tragen: UI-Beschriftungen, Konfigurationswerte, Kommentare.\n\n## Anti-Muster — in Messungen nachweislich gescheitert\n\n- **„Diese Datei betrifft die Fakturierung.“** Ein Dateiverweis ist kein Fakt. Gefordert ist die Stelle **mit Bedingung**, etwa: `InvoiceService.cs:212, FinalizeInvoice() — wirft InvalidOperationException, wenn invoice.Status == InvoiceStatus.Paid`.\n- **„Ich öffne ein bis drei repräsentative Dateien.“** Stichproben liefern keine Primärbelege: Die durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Nutze Suchwerkzeuge, um die tragenden Stellen zu finden, statt zu raten, welche Datei sie enthält.\n- **Aufwärtsrunden der Einstufung.** Was du nicht als durchsetzende Stelle gelesen hast, ist nicht `PRIMÄR`. Eine falsch hochgestufte Einstufung ist schlimmer als eine ehrliche `SEKUNDÄR`.\n\n## Pflichtquellen\n\n- **Das Datenbankschema.** Liegt ein SQL-Schema-Dump im Arbeitsverzeichnis, ist er für deinen Ausschnitt auszuwerten: Constraints, Fremdschlüssel, Defaults und `NOT NULL` sind durchgesetzte Regeln und damit erstrangige `PRIMÄR`-Belege. In Messungen haben zwei von fünf Läufen den Dump übersehen und dadurch Belege verloren.\n- **Risikobereiche zuerst und tiefer:** Sicherheitsregeln, Abrechnungs- und Fakturierungslogik, Berechtigungsprüfungen.\n\n## Was du ausdrücklich melden musst\n\n- **Nicht gefundene Durchsetzung.** Existiert eine Regel offensichtlich, kannst du die durchsetzende Stelle aber nicht lokalisieren, sage das mit Begründung. Diese Meldungen werden zu ausgewiesenen Hypothesen. Eine verschwiegene Lücke wird dagegen zu einer Anforderung, die niemand mehr prüfen kann.\n- **Widersprüche.** Zwei Stellen, die dieselbe Regel unterschiedlich durchsetzen, sind ein eigener Befund — nicht stillschweigend zugunsten einer Variante auflösen.\n- **Nicht implementiertes.** Methoden, die nur `throw new NotImplementedException(...)` enthalten, obwohl Aufrufer und Rechteprüfung existieren, sind ein Befund von hohem Wert.\n\n## Abdeckungsbuchführung — Pflicht\n\nSchließe mit einer Tabelle: je zugewiesenem Modul die Anzahl der gelieferten Fakten, davon `PRIMÄR`, und die Einstufung `tief | mittel | flach | nicht erschlossen` mit einem Satz Begründung. Module ohne einen einzigen Fakt sind namentlich zu nennen.\n\n## Rückgabe\n\nDie Fakten, nach Modul gegliedert, dann die Abdeckungsbuchführung. Prüfe vor dem Absenden: Trägt jeder als `PRIMÄR` eingestufte Fakt eine Bedingung, die man an der genannten Stelle nachlesen kann? Wenn nicht, stufe ihn herunter.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "strs-autor": {
+      "description": "Formuliert ausschließlich Stakeholder-Anforderungen (StRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du formulierst **ausschließlich Stakeholder-Anforderungen (StRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nStRS beschreibt die **fachliche Sicht**: Akteure, Geschäftsziele, Geschäftsregeln, fachliche Ergebnisse. Nicht, wie das System das technisch löst.\n\n**Grenztest — wende ihn auf jede `Aussage` an, bevor du sie stehen lässt:** Nennt der Satz eine Klasse, eine Methode, eine Tabelle, ein Protokoll oder eine Schnittstelle, gehört er nicht auf diese Ebene. Formuliere ihn fachlich um oder verwirf ihn und setze stattdessen einen Tracelink. Der Fakt darf und soll technisch sein — die `Aussage` nicht.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg.** Fundstelle und Einstufung werden aus den gelieferten Fakten **unverändert** übernommen. Du stufst nichts hoch und erfindest nichts. Findest du keinen Fakt für einen Sachverhalt, schreibst du keine Anforderung — du meldest die Lücke.\n- **`Fakt` und `Aussage` sind zwei verschiedene Dinge.** `Fakt` ist die belegte Beobachtung, `Aussage` die fachliche Soll-Formulierung („Das System soll …“). Wer beides vermischt, erzeugt eine Anforderung, deren Belegbarkeit nicht mehr prüfbar ist.\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen einen `PRIMÄR`-Beleg **oder** `[HYPOTHESE]` in `Status`. Einen dritten Weg gibt es nicht. Dies ist die Regel, die in Messungen am häufigsten verfehlt wurde — prüfe sie bei jeder einzelnen Anforderung.\n- **Belege mehrfach, wo die Faktenlage es hergibt.** Ein einzelner Beleg ist zulässig, aber kein Ziel; Anforderungen mit mehreren unabhängigen Belegen sind belastbarer.\n- **`Prüfidee` ist Pflicht** und muss ein prüfbares Kriterium nennen. „Wird getestet“ ist keine Prüfidee. „Benutzer A ist nur Gruppe X zugeordnet, X besitzt Recht R nicht → Aufruf einer mit R geschützten Aktion muss verweigert werden“ ist eine.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, niemals im Feld `Typ`.\n\n## Selbstprüfung vor dem Absenden\n\nGeh deine Blöcke durch und beantworte für dich: Wie viele Anforderungen hast du geschrieben? Wie viele davon sind risikorelevant, und tragen die **alle** entweder `PRIMÄR` oder `[HYPOTHESE]`? Gibt es doppelte IDs? Nenne diese drei Zahlen am Ende deiner Rückgabe.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die drei Zahlen der Selbstprüfung und eine Liste der Sachverhalte, für die dir Fakten fehlten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "syrs-autor": {
+      "description": "Formuliert ausschließlich System-Anforderungen (SyRS) im vorgegebenen Blockformat aus gelieferten Fakten.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du formulierst **ausschließlich System-Anforderungen (SyRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene, und wie du sie prüfst\n\nSyRS beschreibt das **beobachtbare Systemverhalten an den Systemgrenzen**: Schnittstellen, Statusmaschinen, Validierungen, Performance- und Sicherheitsverhalten.\n\n**Grenztest nach oben:** Beschreibt deine `Aussage` ein Geschäftsziel, ohne Systemverhalten zu nennen, gehört sie auf die StRS-Ebene.\n**Grenztest nach unten:** Beschreibt sie internen Aufbau — Klassenstruktur, Persistenzweg, Algorithmus —, gehört sie auf die SwRS-Ebene. Verwende Tracelinks statt die Grenze zu überschreiten.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** Fundstelle und Einstufung unverändert übernehmen, nichts hochstufen.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** (Sicherheit, Abrechnung, Berechtigungen) brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Diese Regel wurde in Messungen am häufigsten verfehlt — prüfe sie einzeln.\n- **Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung** in `Tracelinks`. Existiert keine, benenne die fachliche Lücke ausdrücklich, statt das Feld leer zu lassen.\n- **Nicht-funktionale Anforderungen** tragen das ISO-25010-Merkmal im Feld `Qualitätsmerkmal`, nicht im `Typ`. Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.\n- **`Prüfidee` ist Pflicht** und nennt ein prüfbares Kriterium.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl geschriebener Anforderungen; Anzahl risikorelevanter und ob **alle** gedeckt sind; Anzahl ohne StRS-Tracelink. Nenne die drei Zahlen am Ende.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "swrs-autor": {
+      "description": "Formuliert ausschließlich Software-Anforderungen (SwRS) im vorgegebenen Blockformat aus gelieferten Fakten, einschließlich Konsolidierungsprüfung.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du formulierst **ausschließlich Software-Anforderungen (SwRS)** nach ISO/IEC/IEEE 29148 aus Fakten, die dir geliefert werden. Die Ebene ist deine Zuständigkeit und deine Grenze.\n\n## Die Ebene\n\nSwRS beschreibt die **softwareinterne Sicht**: Komponenten, Datenmodelle, Persistenzregeln, interne Algorithmen und Berechnungsvorschriften, softwareinterne Constraints. Was an der Systemgrenze beobachtbar ist, gehört auf die SyRS-Ebene.\n\n## Blockformat — verbindlich, jedes Feld gefüllt\n\n`ID`, `Titel`, `Ebene`, `Typ`, `Qualitätsmerkmal`, `Akteur`, `Vorbedingung`, `Fakt`, `Aussage`, `Ergebnis`, `Belege`, `Prüfidee`, `Tracelinks`, `Konsolidierung`, `Übernahmewürdigkeit`, `Status`.\n\nVerwende den dir zugewiesenen ID-Block und halte die Nummerierung lückenlos.\n\n## Harte Regeln\n\n- **Du schreibst keine Ergebnisdateien.** Du gibst deine Blöcke als Text zurück; die Ablage in den sieben vorgegebenen Dateien besorgt dein Auftraggeber. Legst du selbst Dateien an, entstehen Dateien außerhalb dieser sieben — die Auswertung erfasst sie nicht, und bei mehreren gleichzeitig schreibenden Autoren kollidieren IDs und Dateistände.\n- **Keine Anforderung ohne Beleg;** nichts hochstufen, nichts erfinden.\n- **`Fakt` und `Aussage` sauber trennen.**\n- **Risikorelevante Anforderungen** brauchen `PRIMÄR` **oder** `[HYPOTHESE]`. Einzeln prüfen.\n- **Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung** in `Tracelinks`.\n- **Datenbank-Constraints sind erstrangige Belege.** Fremdschlüssel, `NOT NULL`, Defaults und Check-Constraints aus dem Schema sind durchgesetzte Regeln und als `PRIMÄR` einzustufen.\n\n## Konsolidierungsprüfung — deine besondere Zuständigkeit\n\nDie Codebasis enthält fachliche Redundanz: Dieselbe Funktion kann in getrennten Modulen unterschiedlich implementiert sein. Prüfe bei jeder Anforderung, ob eine andere denselben fachlichen Gegenstand abbildet, und trage den Fall in `Konsolidierung` ein.\n\n**Kalibrierung.** Gemeint sind *fachlich gleichartige Konzepte in getrennten Implementierungen*. Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter“ geführt, sonstige Hardware getrennt davon als „Assets“ — zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.\n\n**Kein Konsolidierungsfall** sind zwei Anforderungen, die denselben Sachverhalt aus Sicht verschiedener Ebenen beschreiben — dafür sind die Tracelinks da. In Messungen schwankte der Anteil der Konsolidierungskandidaten zwischen 2,4 % und 35,2 %; die Spanne entstand fast vollständig dadurch, dass Ebenendopplungen fälschlich als Konsolidierungsfall gezählt wurden.\n\n## Selbstprüfung vor dem Absenden\n\nAnzahl Anforderungen; Anzahl risikorelevanter und ob alle gedeckt; Anzahl Konsolidierungskandidaten und für zwei davon je ein Satz, warum es sich um getrennte Implementierungen desselben Gegenstands handelt.\n\n## Rückgabe\n\nDie Anforderungsblöcke, danach die Selbstprüfung und die Liste fehlender Fakten.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "belegpruefer": {
+      "description": "Prüft die ihm zugewiesenen Belege gegen die Codebasis, indem er die zitierte Stelle öffnet und die Einstufung nachrechnet. Der Umfang der Prüfung ist genau das, was ihm zugewiesen wird. Korrigiert nichts, meldet Abweichungen.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du prüfst Belege gegen die Codebasis. Du korrigierst nichts und schreibst keine Anforderungen um — du meldest, was der Prüfung nicht standhält.\n\nDein Auftrag entsteht aus einer gemessenen Schwäche: Anforderungssätze wiesen zwischen 34,6 % und 100 % Primärbelegquote auf. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt. Du prüfst, ob sie trägt.\n\n## Vorgehen\n\nFür jeden dir zugewiesenen Beleg:\n\n1. **Öffne die zitierte Stelle.** Existiert die Datei? Die Klasse? Die Methode? Stimmt der Zeilenbereich ungefähr?\n2. **Lies die genannte Bedingung.** Steht dort tatsächlich, was der Beleg behauptet?\n3. **Prüfe die Einstufung.** Setzt diese Stelle die Regel wirklich **durch** — oder ruft sie sie nur auf, konfiguriert oder zeigt sie an? Letzteres ist `SEKUNDÄR`, nicht `PRIMÄR`.\n4. **Prüfe die Deckung.** Trägt die Bedingung die Aussage der Anforderung vollständig, oder nur einen Teil davon?\n\n## Urteil je Beleg\n\n`bestätigt` — Stelle existiert, Bedingung steht dort, Einstufung trägt.\n`einstufung zu hoch` — Stelle existiert, setzt die Regel aber nicht durch. Nenne die korrekte Einstufung.\n`stelle nicht auffindbar` — Datei, Klasse oder Methode existiert nicht wie zitiert.\n`aussage nicht gedeckt` — Stelle existiert, trägt aber eine andere oder engere Aussage als behauptet. Beschreibe die Abweichung.\n\n## Harte Regeln\n\n- **Urteile nur, was du gelesen hast.** Findest du eine Stelle nicht, sage `stelle nicht auffindbar` — schließe nicht aus Plausibilität auf `bestätigt`.\n- **Sei streng bei der Einstufung.** Im Zweifel `einstufung zu hoch`. Ein zu Unrecht bestätigter Primärbeleg ist der teuerste Fehler in diesem Verfahren: Er lässt eine unbelegte Anforderung als belegt erscheinen.\n- **Kürze nichts ab.** Kein „und weitere“. Jeder zugewiesene Beleg bekommt ein Urteil.\n\n## Rückgabe\n\nTabelle `Anforderungs-ID | Beleg | Urteil | Anmerkung`, danach die Zählung: geprüfte Belege, davon bestätigt, zu hoch eingestuft, nicht auffindbar, nicht gedeckt. Bei null Beanstandungen sage das ausdrücklich. Nenne außerdem, wie viele Belege dir zugewiesen wurden und — soweit dir mitgeteilt — auf welchen Gesamtbestand sie sich beziehen. Ohne diese Bezugsgröße ist deine Zählung nicht einzuordnen.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "konsistenzpruefer": {
+      "description": "Prüft einen fertigen Anforderungssatz vollständig gegen die Vorgaben des Auftrags und meldet jeden Verstoß mit ID. Korrigiert nichts.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du prüfst einen fertigen Anforderungssatz gegen die Vorgaben des Auftrags. Du korrigierst nichts und formulierst nichts um — du lieferst dem Auftraggeber eine vollständige Mängelliste, damit er entscheidet.\n\nPrüfe **vollständig und mit absoluten Zahlen**, nicht beispielhaft. Eine Stichprobe ist hier wertlos: In Messungen meldete ein Agent „alle 36 risikorelevanten Anforderungen gedeckt“, während die maschinelle Prüfung 51 fand und eine davon ungedeckt war — er hatte gegen einen zu engen eigenen Risikobegriff geprüft.\n\n## Prüfpunkte\n\n1. **Belegpflicht** — Anforderungen ohne jeden Beleg. Jede ID nennen.\n2. **Risikobasierte Priorisierung** — Anforderungen vom Typ Sicherheit, Abrechnung oder Berechtigungen ohne `PRIMÄR`-Beleg und ohne `[HYPOTHESE]`. **Gehe hier Anforderung für Anforderung vor, nicht überschlägig.** Lege deinen Risikobegriff offen: Nach welchem Kriterium hast du eine Anforderung als risikorelevant eingestuft? Ein enger Begriff lässt Verstöße unentdeckt.\n3. **Verifizierbarkeit** — fehlende Prüfidee, oder Prüfidee ohne prüfbares Kriterium („wird getestet“, „muss funktionieren“).\n4. **Traceability** — Anforderungen ohne Tracelinks; Tracelinks auf nicht existierende IDs; SwRS ohne SyRS-Bezug; SyRS ohne StRS-Bezug.\n5. **Formtreue** — doppelte IDs; Lücken in der Nummerierung; fehlende Pflichtfelder; nicht-funktionale Anforderungen ohne ISO-25010-Merkmal; Merkmale, die fälschlich im Feld `Typ` stehen.\n6. **Ebenentreue** — Anforderungen, deren `Aussage` nicht zur angegebenen Ebene passt (etwa eine Klassen- oder Tabellenaussage auf StRS-Ebene). Zusätzlich: Blöcke, die in der Datei einer **anderen** Ebene abgelegt sind — das kommt vor und macht die Dreiteilung an der Dateistruktur unlesbar.\n7. **Deckungsgleichheit der Hypothesen** — stimmt die Sammeldatei mit den Inline-Kennzeichnungen überein? Nenne Differenzen in beide Richtungen.\n8. **Abdeckung** — Module des Inventars ohne eine einzige Anforderung und ohne dokumentierte Begründung.\n9. **Ergebnisstruktur** — Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`). Nenne jede zusätzliche Datei und die Zahl der darin liegenden Anforderungen — sie werden von der Auswertung nicht erfasst.\n10. **Erkundungstiefe** — Anteil der Module, die als `nicht analysiert` geführt werden, in absoluten Zahlen und in Prozent. Über 10 % ist ein Hinweis auf unvollständige Erkundung.\n11. **Zuständigkeitsbindung** — Ist im `Analysebericht.md` festgehalten, welcher Bearbeiter für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt wurde? Nenne jede Teilaufgabe, für die ein Bearbeiter vorgesehen war und die laut Bericht dennoch selbst ausgeführt wurde, sowie jede Teilaufgabe, zu der die Angabe ganz fehlt. Beides ist ein Verstoß; eine nicht offengelegte Abweichung wiegt schwerer als eine begründete.\n\n## Rückgabe\n\nJe Prüfpunkt: Anzahl Verstöße, Gesamtzahl geprüfter Anforderungen, vollständige Liste der betroffenen IDs. Danach eine Gesamtzählung. Bei null Verstößen in einem Punkt sage das ausdrücklich.\n\nSchätze nichts. Kürze keine Liste mit „und weitere“ ab. Wenn du einen Prüfpunkt nicht vollständig prüfen konntest, sage welchen und warum — das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    },
+    "iso29148-orchestrator": {
+      "description": "Prüft den zusammengeführten Bestand der drei Ebenen gegen die Anforderungen an eine Spezifikation nach ISO/IEC/IEEE 29148 und liefert einen Übergabebericht mit konkreten, ausführbaren Anweisungen. Formuliert keine neuen Anforderungen und ändert nichts selbst.",
+      "mode": "subagent",
+      "model": "tensorx/z-ai/glm-5.3-flash",
+      "prompt": "Du prüfst, ob die Teilergebnisse der drei Ebenen **eine** Spezifikation nach ISO/IEC/IEEE 29148 ergeben, und lieferst deinem Auftraggeber die Anweisungen, die dazu noch fehlen. Du formulierst **keine neuen Anforderungen**, änderst keine Aussagen und schreibst keine Dateien — du lieferst einen Übergabebericht, den dein Auftraggeber ausführt.\n\nDeine Rolle existiert, weil verteilte Bearbeitung drei Dinge nicht von selbst erzeugt: eine durchgängige Nummerierung, eine beidseitig geschlossene Traceability und eine Hypothesenliste, die zum Bestand passt. Keines davon ist am Teilbestand feststellbar — nur am zusammengeführten.\n\n## Was du prüfst und wozu du anweist\n\n1. **Durchgängige Nummerierung.** Je Ebene lückenlos, ohne Doppelvergabe. Ist umzunummerieren, lieferst du die vollständige Zuordnung `alt → neu` **und** die Liste aller Stellen, die mitzuziehen sind: Tracelinks, Traceability-Tabelle, Hypothesenliste, Abdeckungstabelle. Eine halb gezogene Umnummerierung ist schlimmer als die Lücke — liefere die Liste vollständig oder benenne, warum du sie nicht vollständig aufstellen konntest.\n2. **Beidseitige Traceability.** Jede SwRS verweist auf ihre SyRS, jede SyRS auf ihre StRS. Nenne jeden Verweis, der ins Leere zeigt, und jede Anforderung ohne Gegenstück — ein Ziel erfindest du nicht. Für die konsolidierte Tabelle `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg` lieferst du die Zeilen, die aus dem vorliegenden Bestand belegbar sind.\n3. **Deckungsgleiche Hypothesenliste.** Die Sammeldatei muss exakt die Anforderungen enthalten, die inline als `[HYPOTHESE]` gekennzeichnet sind. Prüfe in beide Richtungen und nenne beide Differenzmengen mit IDs.\n4. **Abdeckungstabelle über das gemeinsame Inventar.** Jedes Modul mit der Zahl der auf es entfallenden Anforderungen. Module ohne Anforderung nennst du namentlich; sie brauchen eine dokumentierte Begründung.\n5. **Ergebnisstruktur.** Es dürfen ausschließlich die sieben vorgegebenen Dateien existieren. Melde zusätzliche Dateien, fehlende Dateien und Blöcke, die in der Datei einer anderen Ebene abgelegt sind.\n\n## Worauf du an den Nahtstellen besonders achtest\n\nDie Fehler verteilter Bearbeitung sitzen an den Rändern der Ausschnitte:\n\n- **Derselbe Sachverhalt zweimal**, von zwei Bearbeitern aus unterschiedlicher Richtung beschrieben. Das ist kein Konsolidierungsfall im fachlichen Sinn, sondern eine Doublette — melde sie als solche, mit beiden IDs.\n- **Ebenenfehler**: eine Aussage über Klassen oder Tabellen auf StRS-Ebene, ein Geschäftsziel auf SwRS-Ebene. Du meldest den Fall und nennst die Zielebene, verschiebst ihn aber nicht — beim Verschieben müsste die Aussage umformuliert werden, und das ist Sache des zuständigen Autors.\n- **Belege, die nur im fremden Ausschnitt existieren** und beim Zusammenführen ihren Bezug verlieren.\n\n## Harte Regeln\n\n- **Keine neue Anforderung, keine geänderte `Aussage`, keine hochgestufte Belegeinstufung, keine Datei.** Fällt dir eine Lücke auf, meldest du sie.\n- **Kein stilles Löschen und kein stilles Zusammenführen.** Doubletten werden gemeldet, mit beiden Ursprungs-IDs; ob zusammengeführt wird, entscheidet dein Auftraggeber.\n- **Zähle, statt zu schätzen.** Jede Aussage über den Bestand nennt absolute Zahlen. Kürze keine Liste mit „und weitere\" ab.\n- **Konntest du einen Punkt nicht vollständig prüfen** — etwa weil dir ein Teilbestand nicht vorliegt —, sage welchen und warum. Das ist brauchbarer als eine unvollständige Zahl, die vollständig aussieht.\n\n## Rückgabe\n\nDer Übergabebericht: Anzahl Anforderungen je Ebene, die Umnummerierungsanweisungen samt mitzuziehender Verweise, geschlossene und offene Tracelinks, die Zeilen der Traceability-Tabelle, Differenzen zwischen Hypothesenliste und Inline-Kennzeichnung, Module ohne Anforderung, gefundene Doubletten und Ebenenfehler — jeweils mit IDs.\n\nDu legst keine Dateien an. Deine Rückgabe ist Text; die Ablage besorgt dein Auftraggeber.\n\n## Keine Weiterdelegation\n\nDu startest **keine** Subagenten und delegierst deinen Auftrag nicht weiter. Du führst ihn selbst aus und gibst dein Ergebnis zurück. Reicht dein Auftrag weiter, als du in einem Durchgang bewältigen kannst, sage das ausdrücklich in deiner Rückgabe — dein Auftraggeber schneidet dann neu zu. Ein von dir gestarteter Subagent liefe außerhalb der beauftragten Rolle und wäre im Protokoll nicht mehr einer Zuständigkeit zuzuordnen.",
+      "permission": {
+        "edit": "deny",
+        "task": "deny",
+        "webfetch": "deny",
+        "websearch": "deny",
+        "skill": "deny",
+        "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"
+        }
+      }
+    }
+  },
+  "default_agent": "build"
+}

Versuche/Versuch_02/Iteration 9/z-ai/glm-5.3-flash/custom/high/02_Lauf_2026-09-02_104242_v13.0.0-b971/_meta/startzeit.txt

@@ -0,0 +1 @@
+2026-09-02T10:42:42.6471885+02:00