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_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-02T07:34:03.171666+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\Ergebnisse)
+[2026-09-02T07:34:03.337272+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T07:56:46.598851+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T07:56:48.097160+00:00] OpenCode export: Exporting session: ses_f9ef5eeddffeI5bgXF54VzIYO7
+[2026-09-02T07:56:48.149249+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=6336907; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\RawResult.json

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

@@ -0,0 +1,315 @@
+# Analysebericht (c-entron ERP-Suite)
+
+## 1. Laufübersicht
+
+| Angabe | Wert |
+|---|---|
+| Untersuchungsgegenstand | c-entron ERP-Suite (gesamte Codebasis im Arbeitsverzeichnis, keine Modulbeschränkung) |
+| Version laut version.json | 2.0.2611-alpha (.NET 10 SDK, global.json) |
+| Teilsysteme | Centron.BL / Centron.DAO / Centron.Entities / Centron.Interfaces (Backend), Centron.WPF.UI (Desktop), Centron.Host + Centron.Controllers (Webservice-API), CentronNexus (Blazor-Portal, WebCart, ServiceBoard, OutlookAddIn), Centron.Gateway (EDI/DATEV/OpenTrans/ZUGFeRD), src\apis (FinAPI, GLS, Shipcloud, Icecat, ITscope, Cop, Egis, ebInterface), Centron.Common/Centron.Core (Querschnitt) |
+| DB-Schema | SSMS_DB_SCHEMA.sql (1.558 CREATE-Table-Anweisungen, 76.793 Zeilen) |
+| Vorgehen | RRE-Methodenkette: Schritt 0 Modulinventar → 0b Mindestabdeckung → 0c Vertiefung nach Risiko → Artefakterhebung → technische Analyse → semantische Interpretation → Formalisierung → Traceability |
+| Ergebnisumfang | 126 Anforderungen (StRS 16, SyRS 55, SwRS 55), 242 Belege (160 PRIMÄR, 75 SEKUNDÄR, 7 KONTEXT), 4 Hypothesen |
+| Reihenfolge | Inventar **vor** erster Anforderung erstellt; Mindestabdeckung vor Vertiefung; Vertiefung zuerst in Berechtigungen, Beleg-/Abrechnungslogik, Nummernkreisen, Authentifizierung (ReceiptBL, NumberGroupBL, UserRightsConst, TicketAuthenticationHandler, TwoFactorAuthBL, DunningRunBL, BookKeepingExportBL) |
+
+---
+
+## 2. Modulinventar (Schritt 0)
+
+Legende Abdeckung: `tief` = mehrere Anforderungen, Kernlogik ausgewertet (Klassen-/Methodenlektüre) · `mittel` = Hauptbelege ausgewertet, Randaspekte nicht · `flach` = mindestens ein belegter Befund (Schema, Klasse, Struktur) · `nicht analysiert` = kein belegbarer Befund.
+
+### A. Administration & System
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| A1 | Benutzerverwaltung (AppUser) | src\backend\Centron.BL\Administration\Logins\UsersBL.cs | Interne Benutzerkonten, Passwortprüfung/-änderung, Zuordnung zu Mitarbeitern | tief | SwRS-004 |
+| A2 | Web-Accounts (Kundenportal-Login) | src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs | Portalbenutzer je Kunde mit eigener Rechteverwaltung | tief | SyRS-005, SwRS-005 |
+| A3 | Rechtemodell (UserRightsConst) | src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs; CentronRights.md | Zentraler Berechtigungskatalog (766 Rechte) inkl. einschränkender Rechte | tief | SyRS-002, SwRS-001 |
+| A4 | API-Autorisierung | src\webservice\Centron.Controllers\Authorization\ | Deklarative Rechteprüfung an Endpunkten (401/403) | tief | SyRS-002, SwRS-002 |
+| A5 | Authentifizierungsdienste | src\backend\Centron.BL\Administration\Logins\Auth\ | Verfahrensauswahl (Basic, Active Directory, OpenIdConnect, Fallback) | mittel | SyRS-003 |
+| A6 | Ticket-/Token-Authentifizierung | src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs | Sitzungstickets/Access-Tokens mit IP-/Methodenbindung | tief | SyRS-001, SwRS-003 |
+| A7 | Zwei-Faktor-Authentifizierung | src\backend\Centron.BL\Administration\Logins\TwoFactor\; src\shared\Centron.Core\TotpAuth | 2FA global/je Benutzer mit Gültigkeitsdauer und Validatoren | tief | SyRS-004, SwRS-006 |
+| A8 | Lizenzierung | src\backend\Centron.BL\Administration\Licensing\ | Modulfreigaben über Lizenzprodukte (LicenseGuids, FileLicenseCache) | tief | SyRS-006, SwRS-007 |
+| A9 | Mandanten- & Filialverwaltung | src\backend\Centron.BL\Administration\Masterdata\; SSMS_DB_SCHEMA.sql (Mandant, Filiale) | Mandanten-/Filialstammdaten und -zuordnungen | mittel | SyRS-007, SwRS-009 |
+| A10 | Nummernkreise | src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs | Kollisionsfreie Fachnummernvergabe je Mandant/Filiale | tief | SyRS-008, SwRS-008, SwRS-009 |
+| A11 | Anwendungseinstellungen (AppSettings) | src\backend\Centron.BL\Administration\Settings\ | Datenbankgestützte Verhaltensschalter für Fachregeln | mittel | SyRS-009, SwRS-010 |
+| A12 | SQL-Verwaltung & Skripte | src\backend\Centron.BL\Administration\Scripts\, \SQLManagement | Wartungs-/Reparaturfunktionen als Skriptmethoden | flach | SyRS-010, SwRS-011 |
+| A13 | Dateiablagen & Datenschutzordner | src\backend\Centron.BL\Administration\FileManagement\ (inkl. Dsgvo-Provider) | Objektbezogene Dokumentablagen | flach | SyRS-011, SwRS-012 |
+| A14 | Änderungsverfolgung | src\backend\Centron.BL\ChangeTracking\; src\backend\Centron.DAO\ChangeTracking | Protokollierung geänderter Objekte | flach | SyRS-012, SwRS-031 |
+
+### B. CRM / Adressstamm
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| B1 | Kundenstamm | SSMS_DB_SCHEMA.sql (Kunden, Anschrif, Personen, Kontakte); src\backend\Centron.BL\WebServices\Sales\CustomerWebServiceBL.cs | Kunden mit Adressen, Ansprechpartnern, Konzernzuordnung | mittel | SyRS-013, SwRS-013 |
+| B2 | Lieferantenstamm | SSMS_DB_SCHEMA.sql (Kreditor, LieferantenToFiliale) | Lieferantenstammdaten mit Filialzuordnung | mittel | SyRS-014, SwRS-014 |
+| B3 | Kontakte & Anschriften | SSMS_DB_SCHEMA.sql (Kontakte, KontaktePersonen, AnsprechpartnerBeziehung) | Kontaktpersonen und -beziehungen je Partner | flach | SyRS-013, SwRS-013 |
+| B4 | Vertriebssteuerung & Klassifizierung | SSMS_DB_SCHEMA.sql (Vertriebssteuerung, Vertriebsgebiete, KundenHerkunft, KundenKlassifizierung) | Vertriebssteuerungs- und Klassifikationsdaten | flach | SyRS-015, SwRS-015 |
+| B5 | Sonderpreise & Sondervereinbarungen | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs; Tabelle Sonderaktionen | Kundenspezifische Preisvereinbarungen als Preisquelle | tief | SyRS-019, SwRS-019 |
+
+### C. Vertrieb
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| C1 | Belegsystem (Kopf/Positionen) | src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs; SSMS_DB_SCHEMA.sql (Ang/Auf/Lief/Rech/Gut/Abhol/Vertrag/Anfr-Köpfe) | Einheitliche Belegkette Vertrieb mit belegartenspezifischen Strategien | tief | SyRS-016, SwRS-016, SwRS-017 |
+| C2 | Belegversionierung & Sperrung | ReceiptBL.cs:3063-3175; Tabellen *Versions | Versionshistorie und exklusive Bearbeitungssperre | tief | SyRS-017, SyRS-018, SwRS-018 |
+| C3 | Preisfindung | src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs | Kaskadierte Preisquellen inkl. Mengen-/Einkaufspreisen und USt | tief | SyRS-019, SwRS-019 |
+| C4 | Belegfreigabe / Warenkorb | src\backend\Centron.BL\Sales\Receipts\ReceiptCartBL.cs, ReceiptCartReleaseSystemBL.cs | Belegkörbe mit Freigabeverarbeitung | mittel | SyRS-020, SwRS-020 |
+| C5 | Provisionen | src\backend\Centron.BL\Sales\Receipts\ReceiptProvisionSchemaBL.cs u. Verwandte | Provisionsberechnung nach Schema/Stufe/Ziel | flach | SyRS-024, SwRS-024 |
+| C6 | Vertragsverwaltung | SSMS_DB_SCHEMA.sql (VertragKopf/-Pos, VertragRechKopfZuordnung, VertragsArt) | Verträge, Kontingente, Vertragsrechnungszuordnung | mittel | SyRS-016, SwRS-016 |
+| C7 | Mahnwesen | src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningBL.cs, DunningRunBL.cs | Gestuftes Mahnwesen mit Protokollierung | tief | SyRS-021, SwRS-021 |
+| C8 | OPOS & Zahlungseingang | src\backend\Centron.BL\Sales\Receipts\Invoices\Opos\OposBL.cs; Tabellen Zahlungseingang/-Log | Zahlungszuordnung und offene Posten | mittel | SyRS-022, SwRS-022 |
+| C9 | RMA | src\backend\Centron.BL\CustomerArea\RmaBL.cs, RmaSendKindBL.cs; WPF-Modul Rma | Retourenabwicklung mit Belegerzeugung | flach | SyRS-052, SwRS-052 |
+| C10 | Kassenbuch | src\backend\Centron.BL\Sales\CashBooks\ | Kassenbuchführung mit Belegauto-Buchung | tief | SyRS-023, SwRS-023 |
+| C11 | Anfragen & Angebotsbewertung | SSMS_DB_SCHEMA.sql (AnfrKopf/-Pos+Versions, AngebotBewertung, AngebotVerloren) | Kundenanfragen und Angebotsverfolgung | flach | SyRS-052, SwRS-052 |
+
+### D. Einkauf
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| D1 | Bestellwesen | SSMS_DB_SCHEMA.sql (BestKopf2/BestPos2); src\backend\Centron.BL\Sales\Receipts\SupplierOrders\SupplierOrderBL.cs | Einkaufsbestellungen inkl. EDI-Übermittlung | mittel | SyRS-025, SwRS-025 |
+| D2 | Wareneingang & Lieferantenbelege | src\backend\Centron.BL\Sales\Receipts\SupplierDeliveryLists\, SupplierReceiptDocuments\ (PdfScanning) | Wareneingang, Lieferantenrechnungen, PDF-Extraktion | mittel | SyRS-026, SwRS-026 |
+
+### E. Lager
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| E1 | Artikelstamm | src\backend\Centron.BL\Warehousing\ArticleBL.cs u. a.; Tabellen ARTIK/WAREN/UNTERWAREN | Artikel mit Set-Struktur, Einheiten, Barcodes, Erlöskonten | tief | SyRS-027, SwRS-027 |
+| E2 | Produktfamilien | SSMS_DB_SCHEMA.sql (Produktfamilie*); ProductFamilyBL.cs | Artikelgruppen mit Verkaufsperren | flach | SwRS-047 |
+| E3 | Bestandsführung | src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs; Tabellen Warehouses/Lagerort/Lagerplatz | Bestände je Artikel/Lager, Bedarfe, Einkaufspreise | tief | SyRS-028, SwRS-028 |
+| E4 | Seriennummern & Barcode | src\backend\Centron.DAO\Mappings\Warehousing\SerialNumberMaps.cs; Tabellen SeriennummerToPosition, Barcode* | Stückverfolgung über Belege | mittel | SyRS-029, SwRS-029 |
+| E5 | Inventur | src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs, InventoryNewBL.cs | Zählung und Bestandsabgleich | flach | SyRS-030 |
+
+### F. Fertigung
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| F1 | Produktionsaufträge | src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs; Tabellen ArticleProduction* | Lizenzpflichtige Fertigungsaufträge mit Schritten/Material | mittel | SyRS-031 |
+
+### G. Service / Helpdesk
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| G1 | Tickets / Helpdesk | src\backend\Centron.BL\Sales\Support\HelpdeskBL.cs, HelpdeskStatusBL.cs u. a.; Tabellen hlpdsk_* | Ticketbearbeitung mit Statuskatalog, Historie, Kategorien | tief | SyRS-032, SwRS-030, SwRS-031 |
+| G2 | Ticket-Zeiterfassung & Abrechnung | src\backend\Centron.BL\Sales\Support\HelpdeskTimerBL.cs; ReceiptBL.cs:5295; Tabellen hlpdsk_timer | Zeiteinträge und Belegbildung daraus | tief | SyRS-033, SwRS-032 |
+| G3 | Eskalation & Benachrichtigungen | src\backend\Centron.BL\Sales\Support\Escalation\; NexusNotifications | Überfälligkeit und Ereignisbenachrichtigung | flach | SyRS-034, SwRS-033 |
+| G4 | Externe Ticketsysteme (DocBee) | src\backend\Centron.BL\DataExchange\Connectors\DocBee* | Ticket-/Zeitabgleich mit externem System | flach | SyRS-044 |
+| G5 | Geräte-/Anlagenbindung am Ticket | SSMS_DB_SCHEMA.sql (AccountDevices, AccountDevicesToTickets); HelpdeskAssetBL.cs | Gerät-zu-Ticket-Zuordnung für Service | flach | SyRS-053, SwRS-053 |
+
+### H. Projekte & Organisation
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| H1 | Projektleitung | SSMS_DB_SCHEMA.sql (CRMProjekt, CRMProjektObjekt); CrmProjectWebServiceBL.cs | Projekte mit Objekten und Belegbezug | flach | SyRS-052, SwRS-052 |
+| H2 | Aufgaben & Checklisten | src\backend\Centron.BL\TaskManager\, CheckListArea\; Tabelle ToDoListe | ToDos, Aufgaben, Checklisten (auch C-FLOW-Vorlagen) | flach | SyRS-050, SwRS-050 |
+| H3 | Kalender & Terminplanung | Tabellen Terminplanung*; src\backend\Centron.BL\MyDay\, AppointmentRequests\ | Termine, Teilnehmer, Terminanfragen/-vorschläge | flach | SyRS-050, SwRS-050 |
+| H4 | Mitarbeiterverwaltung | src\backend\Centron.BL\EmployeeArea\; Tabellen Personal, PersonalGruppen, AGLohngruppe | Personalstamm, Gruppen, Lohngruppen | flach | SyRS-051, SwRS-051 |
+| H5 | Zeiterfassung & CTime-Connector | src\backend\Centron.BL\Services\CTimeConnectors\; src\backend\Centron.BL\Time\ | Zeiterfassungssynchronisation (inkrementell) | mittel | SyRS-051, SwRS-051 |
+
+### I. Finanzen
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| I1 | Buchhaltungsexport (DATEV) | src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs; src\backend\Centron.Gateway\DataExchange\BookKeeping\ | DATEV-kompatible Exporte mit Revisionsmetadaten | tief | SyRS-035, SwRS-034 |
+| I2 | Online-Banking (FinAPI) | src\backend\Centron.BL\Finances\OnlineBanking\; src\apis\Centron.APIs.FinAPI\ | PSD2-Bankanbindung, Umsätze, Zahlungen | tief | SyRS-036, SwRS-035 |
+| I3 | Leasing-/Serviceabrechnung | src\backend\Centron.BL\Sales\Receipts\LeasingAndService\ | Wiederkehrende Raten und Logs | mittel | SyRS-037, SwRS-036 |
+| I4 | Kostenstellen & Kostenträger | SSMS_DB_SCHEMA.sql (Kostenstellen, Kostentraeger); ReceiptCostCenterAndCostObjectBL.cs | Kostenzuordnung in Belegpositionen | flach | SyRS-016, SwRS-016 |
+| I5 | Statistik & Controlling | src\backend\Centron.BL\Statistics\ (u. a. TicketStatistics); Tabelle CacheTicketStatistic | Vorberechnete Auswertungen | flach | SyRS-049, SwRS-049 |
+
+### J. Kommunikation
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| J1 | E-Mail & Textbausteine | src\backend\Centron.BL\Mail\; TextModuleArea\; Tabelle GeschaeftspartnerTextbausteine | Prozess-Mails mit Partner-Vorlagen | mittel | SyRS-055, SwRS-055 |
+| J2 | Mail-Scanner (VMA) | src\backend\Centron.BL\MailScanner\MailScannerBL.cs | Automatisierte E-Mail-Verarbeitung mit verschlüsselten Profilen | mittel | SyRS-038, SwRS-037 |
+| J3 | Mailings & Telemarketing | src\backend\Centron.BL\Mailings\; Tabelle TelemarketingParticipants | Kampagnen und Telefonmarketing | flach | SyRS-054, SwRS-055 |
+| J4 | Chats & Social Media | src\backend\Centron.BL\Chats\, SocialMedia\; Tabellen SocialMedia* | Interne Chats und Social-Media-Interaktionen | flach | SyRS-054, SwRS-055 |
+
+### K. Dokumente & Suche
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| K1 | Dokumentenablage (DocuBoard) | src\backend\Centron.BL\DocuBoard\; Anlage*-Tabellen | Objektbezogene Dokumentablage/Freigaben | flach | SyRS-011, SwRS-012 |
+| K2 | Report-Engine | src\backend\Centron.BL\ReportEngine\ (26 Klassen), Reporting | Beleg- und Auswertungsberichte inkl. PDF-Archivierung | mittel | SyRS-016, SyRS-049 |
+| K3 | Volltextsuche | src\backend\Centron.BL\IndexSearch\ (TicketFulltextIndex, GermanAnalyzer) | Volltextindizes mit deutscher Sprachanalyse | flach | SyRS-049, SwRS-049 |
+
+### L. Schnittstellen
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| L1 | EDI-Gateway | src\backend\Centron.BL\EDI\; src\backend\Centron.Gateway\EDI_* | Lieferanten-EDI (Alltron, ALSO, EGIS, Komsa, Concerto, Herweck, OpenTrans) | tief | SyRS-039, SwRS-038 |
+| L2 | E-Rechnung (ZUGFeRD/XRechnung) | src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs | E-Rechnungsexporte in mehreren Varianten | tief | SyRS-040, SwRS-039 |
+| L3 | Versand (GLS/Shipcloud) | src\apis\Centron.Api.Gls\, Centron.Api.Shipcloud\; ShipcloudPackageTemplateBL.cs | Paketlabels über Versanddienste | mittel | SyRS-041, SwRS-040 |
+| L4 | Produktinformationsdienste | src\apis\Centron.APIs.IcecatDataAccess\, ITscopeDataAccess\, CopDataAccess\, EgisDataAccess\ | Artikelanreicherung aus Katalogdiensten | mittel | SyRS-046, SwRS-044 |
+| L5 | Workflow-Engine | src\backend\Centron.BL\Services\Workflows\ | Konfigurierbare Prozessautomatisierung | flach | SyRS-047, SwRS-045 |
+| L6 | Outlook-Integration | src\nexus\CentronNexus.OutlookAddIn\ | Belege/Tickets/Dokumente aus Outlook | mittel | SyRS-048, SwRS-046 |
+
+### M. Web
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| M1 | Nexus-Portal | src\nexus\CentronNexus\ (Blazor, Host) | Kunden-/Mitarbeiter-Webzugang zur Suite | mittel | SyRS-042 |
+| M2 | WebCart / Shop | src\nexus\CentronNexus\WebCart\; README.md | Kunden-Shop auf Basis von Sonderpreisen | tief | SyRS-042, SwRS-041 |
+| M3 | WebOffer | src\nexus\CentronNexus\WebOffer\ | Angebotsansicht/-freigabe im Portal | flach | SyRS-042 |
+| M4 | ServiceBoard | src\nexus\CentronNexus\ServiceBoard\ | Kanban-/Listenansichten für Tickets und CRM | mittel | SyRS-032 |
+| M5 | Dokumentensignierung | src\nexus\CentronNexus\DocumentSigning\ | Externe Signierung (Pad/PDF-Upload) | mittel | SyRS-043, SwRS-042 |
+| M6 | Webservice-API | src\webservice\Centron.Controllers\, Centron.Host\ | Versionierte REST-API mit Swagger und Tickets | tief | SyRS-044, SwRS-002, SwRS-003 |
+
+### N. Sonstige Module
+
+| Nr | Modul | Pfad | Fachliche Aufgabe | Abdeckung | Anforderungen |
+|---|---|---|---|---|---|
+| N1 | Passwort-Manager | src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs | Verschlüsselte Ablage vertraulicher Zugangsdaten | tief | SyRS-045, SwRS-043 |
+| N2 | Gutscheinverwaltung | src\backend\Centron.BL\VoucherManagement\VoucherManagementBL.cs | Gutscheinlebenszyklus (frei/ausgegeben/eingelöst) | flach | SyRS-054, SwRS-054 |
+| N3 | Qualitätsmanagement (QM) | src\centron\Centron.WPF.UI\Modules\QM\; Tabellen AGPrufvorschrift, APlan* | QM-Einstellungen, Prüfgründe, Arbeitspläne | flach | SyRS-052, SwRS-052 |
+| N4 | Asset-Management & Monitoring | Tabellen AssetManagement*; src\backend\Centron.BL\WebServices\RiverSuiteAssetManagment\, ItPlanner | Geräteinventar, SNMP-/Windows-Prüfungen, Netzwerkplanung | flach | SyRS-053, SwRS-053 |
+| N5 | Telefonie (CTI) | src\backend\Centron.BL\Tapi\; TapiNumber-Mapping | Anruf-/Nummernzuordnung | flach | SyRS-054, SwRS-055 |
+| N6 | Video-Portal & Hilfe | src\backend\Centron.BL\VideoPortal\ | Schulungs-/Hilfevideos | flach | SyRS-042 |
+| N7 | Deployment & Installation | docker\, deployment\ (WiX), azure\ (Pipelines) | Container-, Installer- und Pipeline-Betrieb | mittel | SyRS-044, SwRS-048 |
+| N8 | Weblinks & Oberflächenanpassungen | src\backend\Centron.BL\WebLinks\, Customizations\, Administration\Themes | URL-Verknüpfungen, Themes, Mandantenanpassungen | flach | SyRS-009 |
+
+**Inventarsumme: 80 Module.** Das Inventar wurde vor der ersten Anforderung erstellt und im Verlauf nur ergänzt, nicht gekürzt.
+
+---
+
+## 3. Abdeckungstabelle (Konsolidiert)
+
+| Abdeckung | Module (Anzahl) | Anteil | Beispiele |
+|---|---|---|---|
+| tief | 25 | 31,3 % | A1, A2, A3, A4, A6, A7, A8, A10, B5, C1, C2, C3, C7, C10, E1, E3, G1, G2, I1, I2, L1, L2, M2, M6, N1 |
+| mittel | 24 | 30,0 % | A5, A9, A11, B1, B2, C4, C6, C8, D1, D2, E4, F1, H5, I3, J1, J2, K2, L3, L4, L6, M1, M4, M5, N7 |
+| flach | 31 | 38,7 % | A12, A13, A14, B3, B4, C5, C9, C11, E2, E5, G3, G4, G5, H1, H2, H3, H4, I4, I5, J3, J4, K1, K3, L5, M3, N2, N3, N4, N5, N6, N8 |
+| nicht analysiert | 0 | 0,0 % | – |
+| **Gesamt** | **80** | **100 %** | – |
+
+**Mindestabdeckung:** Erreicht — jedes der 80 Module hat mindestens eine zugeordnete Anforderung (siehe Spalte "Anforderungen" im Inventar); kein Modul ist als `nicht analysiert` geführt. Der Schwellenwert "> 10 % nicht analysiert = unvollständige Erkundung" ist damit nicht berührt.
+
+---
+
+## 4. Konsistenzcheck über das gesamte Anforderungs-Set
+
+| Prüfpunkt | Ergebnis |
+|---|---|
+| Doppelte oder mehrfach vergebene IDs | Keine (StRS: 16, SyRS: 55, SwRS: 55; keine Lücken, keine Duplikate — automatisiert geprüft) |
+| Anforderungen ohne Beleg | Keine; jede Anforderung führt mindestens einen Beleg mit Begründung |
+| Anforderungen ohne `Übernahmewürdigkeit` | Keine (126/126) |
+| Tracelinks auf nicht existierende IDs | Keine (alle 126 `Tracelinks`-Felder gegen den ID-Bestand geprüft) |
+| Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsmarkierung | Keine bekannt; 10 Anforderungen führen Konsolidierungskandidaten (s. u.) |
+| Abgleich `Hypothesen.md` ↔ Inline-Markierungen | Übereinstimmend: 4 Anforderungen mit `Status: HYPOTHESE` (SyRS-030, SyRS-031, SyRS-034, SwRS-042) und genau dieselben 4 in `Hypothesen.md`; keine freien Fragen in Hypothesen.md, weitere offene Punkte stehen in Abschnitt 6 |
+| Beleggesamtheit | 242 Belege: 160 PRIMÄR, 75 SEKUNDÄR, 7 KONTEXT |
+
+**Konsolidierungskandidaten** (Feld `Konsolidierung`):
+
+| Anforderung | Kandidat |
+|---|---|
+| SyRS-012, StRS-016 (Change Tracking) | ChangeTracking-Schicht vs. Beleg-Versions-/Logtabellen — zwei Verfolgungsmechanismen |
+| SyRS-013, SwRS-013 | Kundenstamm; Kandidat Kunden-/Lieferantenstamm → einheitlicher Partnerstamm (auch SyRS-014/SwRS-014) |
+| SyRS-030 | InventoryBL vs. InventoryNewBL — zwei Inventurgenerationen |
+| SwRS-016 | Kopf-/Positions-/Versionstabellen je Belegart (9+ Tabellenpaare) → generalisierter Belegkern |
+| SwRS-025 | BestKopf2/-Pos2 (Zweite Bestelltabellen-Generation) → in Belegkern integrieren |
+| SyRS-041, SwRS-040 | GLS-Adapter vs. Shipcloud-Adapter — einheitliche Versandabstraktion |
+| SyRS-052, SwRS-052 | RMA-Belegerzeugung (CreateReceiptFromRma) vs. reguläre Belegkette |
+| SyRS-053, SwRS-053 | AssetManagementDevices vs. AccountDevices vs. GeraeteKopf — drei Geräte-/Anlagen-Datenhaltungen |
+| StRS-015 | Sammelanforderung: Stammblätter vs. Assets; Kunden-/Kreditor-Stämme; Belegart-Tabellen |
+
+---
+
+## 5. Liste der risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
+
+Belegsituation je Anforderung; "PRIMÄR: ja" bedeutet, dass mindestens ein PRIMÄR-Beleg mit benannter durchsetzender Stelle (Datei/Klasse/Methode/Prüfung) vorliegt.
+
+| ID | Titel | Risikobereich | PRIMÄR | Anmerkung |
+|---|---|---|---|---|
+| StRS-001 | Geschützter Systemzugang | Sicherheit | ja | TicketAuthenticationHandler, WebAccountBL |
+| StRS-002 | Rechtegesteuerte Funktionserbringung | Berechtigungen | ja | UserRightAuthorizationFilter, UserRightsConst |
+| StRS-011 | Geheim- und Datenschutz | Sicherheit | ja | AES im Passwort-Manager, VMA-Profilverschlüsselung |
+| SyRS-001 | API-Authentifizierung per Ticket/AccessToken | Sicherheit | ja | ValidateTicketOrAccessToken |
+| SyRS-002 | Feingranulare Rechteprüfung | Berechtigungen | ja | OnAuthorization (401/403) |
+| SyRS-003 | Austauschbare Authentifizierungsverfahren | Sicherheit | ja | ChangeOwnPassword-Sperrregel |
+| SyRS-004 | Zwei-Faktor-Authentifizierung | Sicherheit | ja | ValidateTwoFactor/HasToValidateTwoFactor |
+| SyRS-005 | Portal-Login (Web-Accounts) | Berechtigungen | ja | LoginWithWebAccount, WebRight 31005 |
+| SyRS-006 | Lizenzabhängige Modulfreigabe | Berechtigungen | ja | FinAPI-/Produktions-Lizenzgates |
+| SyRS-008 | Zentrale Nummernvergabe | Abrechnung | ja | Optimistische Sperre in GetNextNumber |
+| SyRS-017 | Belegsperrung | Abrechnung/Integrität | ja | TryLockReceipt in CreateNewVersion |
+| SyRS-019 | Preisfindung | Abrechnung | ja | ReceiptItemPriceBL-Quellenkaskade |
+| SyRS-021 | Mahnprozesse | Abrechnung | ja | DunningRunBL-Stufenlogik |
+| SyRS-022 | Zahlungseingang/OPOS | Abrechnung | ja (schwach) | PRIMÄR stützt sich auf BL-/Schemaebene; Methodenrumpf von OposBL nicht im Detail ausgewertet — Belegdicke als dünn markiert |
+| SyRS-023 | Kassenbuchführung | Abrechnung | ja | CashBookBookingBL-Buchungstechnik |
+| SyRS-033 | Ticketzeiterfassung & Belegbildung | Abrechnung | ja | CreateNewReceiptForHelpdekTimers; Zeitrechte |
+| SyRS-035 | Buchhaltungsexport | Abrechnung | ja | SaveExportSettings (DefaultExport, Metadaten) |
+| SyRS-036 | Online-Banking (FinAPI) | Abrechnung/Sicherheit | ja | Credentials-Gate mit Lizenzprüfung |
+| SyRS-038 | Mail-Scanner (VMA) | Sicherheit | ja | Rechteprüfung + Profilverschlüsselung |
+| SyRS-040 | E-Rechnung (ZUGFeRD/XRechnung) | Abrechnung | ja | Format-/Varianten-/Leitweg-Regeln |
+| SyRS-045 | Passwort-Manager | Sicherheit | ja | AES + Masterkey-Punkte |
+| SwRS-001 | Rechtekonstanten-Katalog | Berechtigungen | ja | UserRightsConst |
+| SwRS-002 | 401/403-Filter | Berechtigungen | ja | OnAuthorization |
+| SwRS-003 | Token-Validierung | Sicherheit | ja | IP-/Methodenbindung |
+| SwRS-004 | Passwortregeln | Sicherheit | ja | UsersBL (SHA1, Mindestlänge, externe Auth) |
+| SwRS-005 | Web-Account-Regeln | Berechtigungen | ja | Loginfilter, 31005 |
+| SwRS-006 | 2FA-Validatoren | Sicherheit | ja | ITwoFactorValidator-Abstraktion |
+| SwRS-007 | Lizenzprodukt-Modell | Berechtigungen | ja | LicenseManager-Settings |
+| SwRS-008 | Nummernkreis-Algorithmus | Abrechnung | ja | Lückenschluss, optimistische Sperre |
+| SwRS-018 | Sperr-/Versionsvalidierungen | Abrechnung/Integrität | ja | Validierungskette in CreateNewVersion |
+| SwRS-019 | Preisquellen-Kaskade | Abrechnung | ja | Caches/Quellen in ReceiptItemPriceBL |
+| SwRS-021 | Mahnfelder | Abrechnung | ja | Feldzuweisungen DunningRunBL |
+| SwRS-022 | Zahlungseingangs-Datenmodell | Abrechnung | ja | Schema (Zahlungseingang/-Log) |
+| SwRS-023 | Kassenbuch-Buchungstechnik | Abrechnung | ja | USt-Split, idempotente Neubuchung |
+| SwRS-028 | Bestands-/Einkaufspreisfortschreibung | Abrechnung | ja | UpdateArticlePurchasePrice |
+| SwRS-032 | Timer→Beleg-Bildung | Abrechnung | ja | CreateNewReceiptForHelpdekTimers + Zeitrechte |
+| SwRS-034 | DATEV-Exportkonfiguration | Abrechnung | ja | Metadaten-/Einzigkeitsregel |
+| SwRS-035 | FinAPI-Credentials-Gate | Abrechnung/Sicherheit | ja | Lizenzprüfung vor Credentials |
+| SwRS-037 | VMA-Profilverschlüsselung | Sicherheit | ja | Encrypt/Decrypt + Rechtecode |
+| SwRS-039 | ZUGFeRD-Varianten/Leitweg-ID | Abrechnung | ja | InvoiceZugferdBL |
+| SwRS-043 | Passwort-Manager-AES | Sicherheit | ja | AESCryptoLogic-Punkte |
+
+**Verstoßbilanz:** Keine risikorelevante Anforderung trägt den Status `HYPOTHESE`; die risikobasierte Priorisierung ist erfüllt. Einzige Einschränkung: SyRS-022 (PRIMÄR auf BL-/Schemaebene statt geprüfter Methodenlogik) — als dünn belegt vermerkt.
+
+---
+
+## 6. Belegdicke und offene Punkte
+
+**Anforderungen mit Status `HYPOTHESE` (4):** SyRS-030 (Inventur — Abweichungsbuchung unbelegt), SyRS-031 (Produktion — Rückmeldung/Materialverbrauch unbelegt), SyRS-034 (Eskalation — Auslöse-/Zeitgeberlogik unbelegt), SwRS-042 (Signierseite — serverseitige Token-Validierung und Ablageziel unbelegt). Details in `Hypothesen.md`.
+
+**Offene Teilfragen zu Anforderungen mit Status `belegt`** (bewusst nicht in Hypothesen.md, da der belegte Kern trägt):
+
+1. **Passwort-Speicherung** (SwRS-004/SwRS-005): SHA1-Hash ist belegt; die Frage nach einer vorhandenen Passwort-Rücksetzfunktion für Web-Accounts blieb offen.
+2. **Masterkey-Verwaltung** (SwRS-043): Quelle (CentronConfigurationDb) ist belegt; Schutz, Rotation und Zugriffskontrolle des Masterkeys sind nicht belegt.
+3. **Ticket-/Token-Gültigkeitsdauer** (SwRS-003): Validierung mit IP/Methode ist belegt; Ablaufdauer und Verhalten bei IP-Wechsel (Roaming) sind nicht belegt.
+4. **Mehrstufige Freigaben** (SwRS-020): Korb-Freigabesystem ist belegt; ob mehrstufige Freigabeketten (mehrere Rollen) möglich sind, ist nicht belegt.
+5. **Preisstichtag** (SwRS-019): Quellenkaskade ist belegt; ob bei Belegfortführung Preise eingefroren oder neu abgeleitet werden, ist nicht belegt.
+6. **DATEV-Formatversionen** (SwRS-034): Ascii/XML-Online/2020 sind belegt; die tatsächlich unterstützte DATEV-Version je Kunde ist nicht belegt.
+7. **Container-Mandantenmodell** (SwRS-048): Deployment-Komponenten sind belegt; ob ein Container mandantengetrennt oder single-tenant betrieben wird, ist nicht belegt.
+8. **Signaturstufe** (SwRS-042): Die rechtliche Stufe (einfach/fortgeschritten/qualifiziert) der Dokumentensignierung ist nicht belegt.
+9. **OPOS-Buchungslogik** (SyRS-022/SwRS-022): Schema und BL-Existenz sind belegt; die innere Zuordnungslogik (Teilzahlungen, Skonti) wurde nicht im Detail ausgewertet.
+
+**Dünn belegte Stellen (hoher SEKUNDÄR/KONTEXT-Anteil):** StRS-013 (Deployment: nur SEKUNDÄR — Artefakte sind Konfigurationsdateien, keine durchgesetzte Logik), StRS-015 (Konsolidierung: SEKUNDÄR/KONTEXT — Befund beruht auf Schema-Mustern und Vorgabe), SwRS-048 (Deployment: nur SEKUNDÄR). Diese Anforderungsbereiche sind nicht risikorelevant; für die Vertiefung genügt eine Folge-Iteration mit Lektüre der Setup-/Pipeline-Definitionen.
+
+---
+
+## 7. Selbstbewertung
+
+**1) Wie viele Module wurden tief, mittel, flach bzw. gar nicht analysiert?**
+Von 80 Inventarmodulen: 25 tief (31,3 %), 24 mittel (30,0 %), 31 flach (38,7 %), 0 nicht analysiert (0 %). Absolute Zahlen: 25 / 24 / 31 / 0.
+
+**2) Wurde die Mindestabdeckung erreicht?**
+Ja. Jedes der 80 Module hat mindestens eine Anforderung (Zuordnung in der Inventartabelle, Spalte "Anforderungen"). Kein Modul ist `nicht analysiert` und damit entfällt auch eine Begründungspflicht dafür.
+
+**3) An welchen Stellen war der Beleg dünn?**
+- SyRS-022/SwRS-022 (OPOS/Zahlungseingang): PRIMÄR stützt sich auf BL-/Schemaebene; die Zuordnungslogik im Methodenrumpf wurde nicht geprüft — im Risikoabschnitt als "schwach" markiert.
+- Die vier HYPOTHESE-Anforderungen (SyRS-030, SyRS-031, SyRS-034, SwRS-042) beruhen jeweils auf Vorhandenseinsbelegen (BL/Schema/UI), nicht auf gelesener Ausführungslogik.
+- Deployment-Bereich (StRS-013, SwRS-048): ausschließlich SEKUNDÄR-Belege (Konfigurations-/Pipeline-Dateien).
+- Randmodule J3/J4, N3, N5, N6 (flach): Beleg meist über Schema-/Klassenpräsenz, fachliche Regeln nur teilweise sichtbar.
+- Belegverteilung insgesamt: 160 PRIMÄR / 75 SEKUNDÄR / 7 KONTEXT; 7 Anforderungen führen SEKUNDÄR/KONTEXT ohne PRIMÄR (StRS-013, StRS-015, SwRS-048 — alle nicht risikorelevant).
+
+**4) Wurde keine einzige Hypothese geführt?**
+Doch — vier Anforderungen sind als HYPOTHESE geführt (SyRS-030, SyRS-031, SyRS-034, SwRS-042); eine Analyse ohne offene Punkte wäre bei 1.558 DB-Tabellen und diesem Codeumfang unplausibel gewesen. Die Hypothesenzahl ist bewusst knapp gehalten: Sie deckt nur Vollaussagen ohne durchsetzenden Beleg ab; sub-Aspekt-Fragen belegter Anforderungen stehen in Abschnitt 6, um den Abgleich Inline ↔ Hypothesen.md eindeutig zu halten.
+
+**5) Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?**
+- **ReceiptBL-Monolith:** 11.441 Zeilen generische Beleglogik; eine gezielte Lektüre der Weiterverarbeitungs-/Buchungspfade (Forward, ArticleBooking) würde die Abrechnungsanforderungen (SyRS-016/019, SwRS-018/019) weiter erhärten.
+- **OposBL/IncomingPaymentBL:** Methodenrümpfe der Zahlungszuordnung lesen (hebt SyRS-022 von "schwach" auf solide PRIMÄR).
+- **EscalationBL und HelpdeskSchedulerBL:** Auslöse-/Zeitgeberlogik lesen (auflöst HYPOTHESE SyRS-034).
+- **InventoryNewBL:** Buchungspfad der Abweichungsbuchung lesen (auflöst HYPOTHESE SyRS-030).
+- **ArticleProductionBL-Schrittabwicklung:** Rückmeldungsbuchung lesen (auflöst HYPOTHESE SyRS-031).
+- **Nexus-Dokumentensignierung:** serverseitige Token-Validierung und Ablageziel der signierten PDFs (auflöst HYPOTHESE SwRS-042).
+- **Deployment:** compose.yaml/WiX-Definitionen im Detail auswerten, um das Betriebsmodell (Mandanten je Container?) zu klären.
+- **AccessTokens/AccessTokenBL:** Langzeit-Token-Richtlinien (Gültigkeit, Sperrung) für eine schlüssigere Sicherheitsanforderung.

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

@@ -0,0 +1,85 @@
+# Glossar (c-entron ERP-Suite)
+
+Domänenbegriffe, die in den Anforderungen verwendet werden. Technische Bezeichner bleiben in der Originalsprache.
+
+## Beleg- und Vertriebsbegriffe
+
+| Begriff | Definition |
+|---|---|
+| **Beleg (Receipt/Asset)** | Oberbegriff für alle Geschäftsdokumente mit Kopf- und Positionsebene: Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertrag, Anzahlung, Anfrage sowie die Lieferantenvarianten (Bestellung, Lieferschein, Rechnung, Gutschrift). Im Code generisch als `IReceiptBase`/`IReceiptSpecificLogic` abgebildet. |
+| **AngKopf/AngPos** | Datenhaltung des Angebots (Kopf/Position). Entsprechend AufKopf (Auftrag), LiefKopf (Lieferschein), RechKopf (Rechnung), GutKopf (Gutschrift), AbholKopf (Abholschein), AnfrKopf (Anfrage), VertragKopf (Vertrag), BestKopf2 (Einkaufsbestellung, Generation 2). |
+| **Weiterverarbeitung (Forward)** | Überführung eines Belegs in einen Folgeberleg (z. B. Angebot → Auftrag, Rechnung → Gutschrift). Geregelt über `CanBeForwardedInto()` der Belegstrategie. |
+| **Belegversion** | Historisierte Fassung eines Belegs; jede Änderung erzeugt Version n+1, gespeichert in `*Versions`-Tabellen. |
+| **Belegsperrung (Lock)** | Exklusive Bearbeitungssperre auf Belegen (`TryLockReceipt`/`UnLockReceipt`). |
+| **ReceiptCart (Belegkorb)** | Sammelbehälter für Belegentwürfe inkl. Freigabesystem; Portaleingänge (WebCart) landen hier. |
+| **Sondervereinbarung (Special Agreement)** | Kundenspezifische Preisvereinbarung, die in der Preisfindungskaskade Vorrang vor Listen-/Mengenpreisen hat. |
+| **Sonderpreise** | Artikel-/Kundenpreise im Adressstamm; Fundament des Portal-Shops (WebCart). |
+| **Mahnstufe (DunningLevel)** | Stufe des Mahnwesens je Rechnung (None → Level1 → Level2 → Level3) mit Stufendatum und -bearbeiter. |
+| **OPOS (Offene Posten)** | Noch nicht ausgeglichene Forderungen; Verarbeitung über OposBL/OposRunBL. |
+| **Kassenbuch (CashBook)** | Kassenbuchführung mit Zeilen je USt-Satz; Belegzahlungen werden automatisch gebucht (InvoiceI3D-Rückverweis). |
+| **Provision (ReceiptProvision)** | Verkaufsprovisionsanspruch aus Belegen, geregelt über Schema-, Stufen- und Zieldaten. |
+| **Leasing-/Service-Rate** | Wiederkehrende Abrechnungseinheit (LeasingRate/ServiceRate) mit zugehörigem Log. |
+
+## Stammdaten
+
+| Begriff | Definition |
+|---|---|
+| **Mandant (Mandant)** | Rechtlich eigenständige Organisationseinheit; belegt MandatorI3D in Fachtabellen. |
+| **Filiale (Branch/Filiale)** | Standort je Mandant; BranchI3D in Fachtabellen; besitzt eigene Nummernkreise und Erlöskontenzuordnungen. |
+| **Kundenstamm (Kunden)** | Kundenstammdaten mit Adressen (Anschrif), Personen, Kontakten und Konzernzuordnung (KundeToKonzern). |
+| **Lieferantenstamm (Kreditor)** | Lieferantenstammdaten mit eigener Nummernvergabe und Filialzuordnung. |
+| **Artikel (ARTIK/WAREN/UNTERWAREN)** | Artikelstamm mit Einheiten, Zubehör, Unterartikeln, Barcode(s) und Erlöskonten je Branche/Filiale. |
+| **Seriennummer (SerialNumber)** | Stückindividuelle Verfolgungseinheit, an Belegpositionen gebunden (SeriennummerToPosition). |
+| **Produktfamilie** | Gruppierung von Artikeln mit Verkaufsperren je Kunde/Position. |
+| **Nummernkreis (NumberGroup)** | Konfigurierbarer Zähler (RangeFrom/RangeTo, Interval) je Nummernart, Mandant und Filiale. |
+| **USt-Satz (MwstSatz)** | Umsatzsteuersatz; Land-/Zeitpunktbezogen in der Preisfindung und Kassenbuch-Aufteilung. |
+
+## Benutzer, Rechte, Betrieb
+
+| Begriff | Definition |
+|---|---|
+| **AppUser** | Interner Benutzer des Systems (angemeldet über Authenticator-Verfahren). |
+| **WebAccount** | Portalbenutzer eines Kunden (Kundenportal/Shop), mit eigenen WebRights; Status=1 bedeutet aktiv. |
+| **UserRight** | Berechtigung aus dem zentralen Rechtekatalog (UserRightsConst, numerische IDs); einschränkende Rechte (z. B. "nur eigene Tickets") verengen die Sicht. |
+| **Ticket/AccessToken** | Anmeldeweis der API: Sitzungsticket bzw. langfristiger Token, gebunden an Client-IP und API-Methode. |
+| **2FA (Two-Factor-Auth)** | Zweistufige Anmeldung mit Validatoren (E-Mail, RADIUS, TOTP) und Gültigkeitsdauer je Benutzer/Anwendung/Gerät. |
+| **Lizenz (LicenseGuid)** | Signierte Modulfreigabe (z. B. ProductionManagement, OnlineBanking_FinApi), geprüft über LicenseManager. |
+| **AppSettings** | Datenbankgestützte Verhaltensschalter (AppSettingsConst), z. B. Kassenbuch-Filialregel, globale Sondervereinbarungen. |
+| **Ablage (FileManagement)** | Objektbezogene Dokumentablage; Pfadbildung über DirectoryReferenceProviders je Objektart. |
+
+## Service, Projekte, Anlagen
+
+| Begriff | Definition |
+|---|---|
+| **Ticket (Helpdesk/hlpdsk_request)** | Servicetransaktion mit konfigurierbaren Status, Prioritäten, Kategorien, Historie und Zeiteinträgen. |
+| **Abschlusszustand (Closed Helpdesk State)** | Definierter Status "Abgeschlossen" im Statuskatalog; Abschluss setzt ClosedAt, Historie und Aktivität. |
+| **Timer (hlpdsk_timer)** | Zeiteintrag am Ticket; Grundlage der Serviceabrechnung (Timer → Beleg). |
+| **C-FLOW-Ticketvorlage** | Wiederverwendbare Ticketvorlage mit Kategorien (Rechtefamilie im Rechtekatalog). |
+| **Projekt (CRMProjekt)** | Projekthaltung mit Objekten (CRMProjektObjekt) und projektspezifischen Belegen/Ansichten. |
+| **RMA** | Retourenprozess mit Sendungsart (RmaSendKind) und Belegerzeugung aus Retouren. |
+| **Asset/Gerät** | Kundengerät/Anlage in einer von drei parallelen Haltungen (AssetManagementDevices, AccountDevices, GeraeteKopf) - Konsolidierungskandidat. |
+| **IT-Planer** | Netzwerk-/Infrastrukturplanung der Kundenumgebung (NetworkStructure, ItPlanner). |
+
+## Schnittstellen und Formate
+
+| Begriff | Definition |
+|---|---|
+| **EDI (Electronic Data Interchange)** | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO/AlsoCH, EGIS, Komsa, Concerto, Herweck) über den EDI-Dispatcher. |
+| **OpenTrans 2.1** | XML-Austauschformat für Bestellungen/Warenkörbe im EDI-Adapter Opentrans21. |
+| **ZUGFeRD/XRechnung** | Deutsche E-Rechnungsformate; Varianten Comfort und XInvoice, Auslösung über Leitweg-ID. |
+| **Leitweg-ID** | Behördliche Empfangsidentifikation für XRechnungen. |
+| **DATEV-Export** | Buchhaltungsübergabe (DatevAscii, DatevXmlOnline/2020) mit genau einer Default-Exportkonfiguration. |
+| **FinAPI** | PSD2-Bankenschnittstelle (Konten, Umsätze, Zahlungen), lizenzgebunden. |
+| **GLS / Shipcloud** | Versanddienst-Adapter für Paketlabels auf Basis von Paketvorlagen. |
+| **Icecat / ITscope / Cop / Egis** | Externe Produktinformationsdienste für Artikelanreicherung und Belegsuche. |
+| **CTime** | Externe Zeiterfassung, inkrementell synchronisiert (LastTransferDate). |
+| **VMA (Virtual Mail Assistant)** | Mail-Scanner-Modul mit Profilen (verschlüsselte Zugangsdaten) und Workflows; Recht ACCESS_VMA_MODULE. |
+| **DocBee** | Externes Ticketsystem, angebunden über Connector-BLs. |
+
+## Qualitäts-/Nicht-funktionale Begriffe (ISO 25010)
+
+| Begriff | Definition |
+|---|---|
+| **Qualitätsmerkmal** | Zuordnung nicht-funktionaler Anforderungen zu ISO/IEC 25010-Merkmalen (u. a. Leistungseffizienz, Übertragbarkeit, Zuverlässigkeit, Rückverfolgbarkeit/Wartbarkeit). |
+| **Revisionssicherheit** | Nachvollziehbare, unverfälschbare Dokumentation von Erstellung/Änderung (Metadaten, Versionen, Protokolltabellen). |
+| **Optimistische Sperre** | Parallelitätstechnik der Nummernvergabe: bedingtes UPDATE nur bei unverändertem Zählerstand, sonst Wiederholung. |

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

@@ -0,0 +1,59 @@
+# Hypothesen (c-entron ERP-Suite)
+
+Diese Datei enthält genau die Anforderungen, deren `Status`-Feld `HYPOTHESE` trägt. Offene Teilfragen zu Anforderungen mit Status `belegt` sind bewusst **nicht** hier aufgeführt; sie stehen in der Selbstbewertung des `Analysebericht.md` (Abschnitt "Belegdicke und offene Punkte").
+
+---
+
+## SyRS-030 – Inventur
+
+**Aussage (Anforderung):** Das System soll Inventuren je Lager/Materialgruppe führen, Zählergebnisse erfassen und Abweichungen buchen.
+
+**Belegter Kern:** Eigenständige Inventurlogik in zwei Generationen (InventoryBL, InventoryNewBL) sowie Materialgruppenebene sind im Code vorhanden (src\backend\Centron.BL\Warehousing\InventoryManagement\InventoryBL.cs, InventoryNewBL.cs, MaterialGroupBL.cs).
+
+**Hypothesenanteil:** Ob und wie Abweichungsbuchungen (Bestandskorrekturbuchungen aus Zählergebnissen) durchgeführt werden und ob Bestände während der Zählung gesperrt werden, ist aus den gelesenen Artefakten nicht nachweisbar.
+
+**Offene Frage:** Welche Buchungslogik erzeugt die Bestandskorrektur aus der Zähldifferenz, und welche Sperrmechanismen gelten während einer laufenden Inventur?
+
+**Bestätigung fehlt, weil:** Der Inhalt von InventoryNewBL (Buchungspfad, Transaktionsverhalten) nicht vollständig ausgewertet wurde.
+
+---
+
+## SyRS-031 – Produktionsaufträge
+
+**Aussage (Anforderung):** Das System soll Fertigungsaufträge mit Arbeitsschritten und Materialverbrauch verwalten, sobald die Lizenz vorliegt.
+
+**Belegter Kern:** Datenmodell (ArticleProductionOrders, ArticleProductionOrderStepItems, Arbeitsplan-Tabellen), Lizenzsperre mit Fehlermeldung und Materialverwaltung (ArticleProductionMaterial) sind belegt (src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs:30-56; SSMS_DB_SCHEMA.sql).
+
+**Hypothesenanteil:** Ob der Abschluss eines Produktionsschritts Materialverbrauch auf den Bestand bucht (Produktionsrückmeldung), ist nicht belegt.
+
+**Offene Frage:** Führt die Schrittrückmeldung zu Bestandsbuchungen der verbrauchten Artikel, und wie wird Fertigwarenbestand gebucht?
+
+**Bestätigung fehlt, weil:** Die Ausführungspfade der Schrittabwicklung (Booking-/Backflush-Logik) nicht ausgewertet wurden.
+
+---
+
+## SyRS-034 – Eskalation und Benachrichtigungen
+
+**Aussage (Anforderung):** Das System soll überfällige/kritische Tickets an definierte Empfängergruppen eskalieren und Ereignisse (z. B. Abschluss) benachrichtigen.
+
+**Belegter Kern:** Eskalationsmodul mit Empfängerklassen (EscalationBL, EscalationReceiversEnum), Benachrichtigungen bei Ticketabschluss (NexusNotificationsBL-Aufruf in HelpdeskCloseBL:149) und Notify-Historientabelle sind belegt.
+
+**Hypothesenanteil:** Die Auslösebedingungen und Zeitgeber der Eskalation (Regelkatalog, Scheduling, Schwellen) sind nicht belegt.
+
+**Offene Frage:** Nach welchen Regeln und in welchen Zeitabständen löst das System Eskalationen aus, und wo ist der Auslöser konfiguriert?
+
+**Bestätigung fehlt, weil:** Der innere Ablauf von EscalationBL (Auslöseprüfung, ggf. Scheduler-Anbindung) nicht ausgewertet wurde.
+
+---
+
+## SwRS-042 – Signierseite (Dokumentensignierung)
+
+**Aussage (Anforderung):** Das System soll externe Signierung über eine Token-Seite mit Signaturpad oder hochgeladener unterschriebener PDF durchführen und den Abschlussstatus anzeigen.
+
+**Belegter Kern:** Signier-/Upload-/Statusinteraktion (Guid-Parameter, Signaturpad, InputFile accept=".pdf", Signierort, "Erfolgreich signiert", Freigabesperre) ist in DocumentSigningPage.razor belegt.
+
+**Hypothesenanteil:** Wohin das signierte Dokument abgelegt und wie der Token (Guid) serverseitig validiert wird, ist aus der UI-Seite allein nicht nachweisbar.
+
+**Offene Frage:** Welche serverseitige Prüfung schützt den Signiervorgang (Token-Gültigkeit, einmalige Nutzung), und in welche Objektablage wird das signierte PDF geschrieben?
+
+**Bestätigung fehlt, weil:** Die Aufruf-/Ablage-Endpunkte hinter der Razor-Seite nicht ausgewertet wurden.

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

@@ -0,0 +1,320 @@
+# StRS – Stakeholder Requirements Specification (c-entron ERP-Suite)
+
+Reverse Requirements Engineering der c-entron ERP-Suite (c-entron.NET WPF-Client, c-entron Webservice-API, c-entron Nexus Web-Portal, Centron.BL/DAO/Entities, Centron.Gateway, externe API-Adapter). Grundlage: statische Analyse der Artefakte im Arbeitsverzeichnis (Quellcode, DB-Schema `SSMS_DB_SCHEMA.sql`, Konfiguration, UI-Ressourcen, Deployment-Skripte). Version der Codebasis laut `version.json`: 2.0.2611-alpha.
+
+Stakeholder (aus Artefakten abgeleitet): Geschäftsführung/Controlling, Vertrieb, Einkauf, Lager/Logistik, Service/Helpdesk, Finanzbuchhaltung, Systemadministration, Mitarbeiter (interne Benutzer), Kunden (Portal-/Web-Accounts), Lieferanten (EDI-Partner), Steuer-/Buchhaltungsaußenstellen (DATEV/E-Rechnung), Softwarebetrieb/Hosting.
+
+---
+
+ID:            StRS-001
+Titel:         Geschützter Systemzugang für alle Benutzer
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Interne Benutzer, Portal-Kunden, Systemadministration
+Vorbedingung:  Benutzerkonto existiert (AppUser oder WebAccount); System ist erreichbar.
+Fakt:          Alle Zugangswege (Webservice-API, WPF-Client, Nexus-Portal) führen Anmeldevorgänge durch: die API validiert Tickets/Access-Tokens mit Client-IP und aufgerufener Methode (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs), der Client authentifiziert über eine Authenticator-Fabrik mit Basic-/AD-/OpenIdConnect-Verfahren (src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs), Portal-Kunden melden sich über WebAccounts an (src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs, LoginWithWebAccount).
+Aussage:       Das System soll jedem Benutzer nur nach erfolgreicher, individualisierbarer Anmeldung Zugriff auf Geschäftsdaten gewähren und alle Anmeldeverfahren (lokal, Active Directory/Entra, OpenIdConnect, Portal-Konto) über einen gemeinsamen Mechanismus abwickeln.
+Ergebnis:      Nicht angemeldete Zugriffe werden abgewiesen; jede Sitzung ist einem Benutzerkonto zuordenbar.
+Belege:
+  - [PRIMÄR]   TicketAuthenticationHandler.HandleAuthenticateAsync / ValidateTicketOrAccessToken (src\webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs:44-95) - Begründung: durchgesetzte Authentifizierungspflicht vor jedem API-Aufruf; ohne Ticket schlägt die Authentifizierung fehl.
+  - [PRIMÄR]   WebAccountBL.LoginWithWebAccount (src\backend\Centron.BL\Administration\Logins\WebAccountBL.cs:54-61) - Begründung: durchgesetzte Passwortprüfung und Statusbedingung (Status == 1) für Portal-Logins.
+  - [SEKUNDÄR] AuthenticatorFactory (src\backend\Centron.BL\Administration\Logins\Auth\AuthenticatorFactory.cs) - Begründung: Auswahlmechanismus der Anmeldeverfahren, stützt die gemeinsame Abwicklung.
+Prüfidee:      API-Aufruf ohne gültiges Ticket wird abgelehnt; Login mit gesperrtem WebAccount (Status ≠ 1) scheitert; jede erfolgreiche Anmeldung erzeugt einen dem Benutzer zuordenbaren Ticket-Datensatz.
+Tracelinks:    SyRS-001, SyRS-003, SyRS-004, SyRS-005
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - individualisierbarer Login ist Grundvoraussetzung für Prüfpflicht und Mandantentrennung.
+Status:        belegt
+
+ID:            StRS-002
+Titel:         Rechtegesteuerte Funktionserbringung
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Systemadministration, alle internen Benutzer
+Vorbedingung:  Benutzer ist angemeldet; Rechtekatalog ist gepflegt.
+Fakt:          Der Code zentralisiert über 760 benannte Rechtekonstanten (src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs, "NEXT ID: 20800174"), dokumentiert Rechte inkl. einschränkender Rechte je Funktion in CentronRights.md und erzwingt Rechteprüfung deklarativ an API-Endpunkten (src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs mit 401/403-Semantik).
+Aussage:       Das System soll Geschäftsfunktionen nur an Benutzer mit der jeweils zuständigen Berechtigung erbringen; Berechtigungen sind administrativ je Benutzer zuordbar und wirken auf Menü, Aktion und Datenzugriff.
+Ergebnis:      Funktionen ohne Berechtigung sind unsichtbar bzw. werden serverseitig verweigert (403).
+Belege:
+  - [PRIMÄR]   UserRightAuthorizationFilter.OnAuthorization (src\webservice\Centron.Controllers\Authorization\AuthorizeUserRightAttribute.cs:38-56) - Begründung: durchgesetzte Rechteprüfung vor Ausführung der Endpunkt-Logik mit 401/403.
+  - [PRIMÄR]   UserRightsConst (src\webservice\Centron.WebServices.Core\EntitiesWrongPlace\Administration\Rights\UserRightsConst.cs, 766 Konstanten) - Begründung: durchgesetztes, zentrales Berechtigungsvokabular im Code.
+  - [KONTEXT]  CentronRights.md (Abschnitt Helpdesk/Kalender) - Begründung: dokumentierte Fachsemantik der Rechte, z. B. einschränkende Rechte "nur eigene Tickets".
+Prüfidee:      Ein Benutzer ohne Recht X erhält auf einen mit Recht X geschützten Endpunkt 403; Menüpunkte ohne Recht sind ausgeblendet (Sichtbarkeitssteuerung).
+Tracelinks:    SyRS-002, SwRS-001, SwRS-002
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Berechtigungsmodell ist fachlich weiter erforderlich; Ablösung veralteter Rechte-IDs sinnvoll.
+Status:        belegt
+
+ID:            StRS-003
+Titel:         Mandanten- und Filialfähigkeit
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Mandatsverwaltung, Filialleitung
+Vorbedingung:  Mandanten- und Filialstammdaten sind angelegt.
+Fakt:          Datenmodell enthält Tabellen Mandant und Filiale (SSMS_DB_SCHEMA.sql); Belege, Benutzer und Nummernkreise tragen MandatorI3D/BranchI3D (z. B. NumberGroupBL.CreateNumberGroups(int mandantI3D, int? branchI3D)); Nummernkreise werden je Mandant und je Filiale angelegt (RefreshAllNumberGroups).
+Aussage:       Das System soll mehrere rechtlich eigenständige Mandanten sowie mehrere Filialen je Mandant mit getrennten Stammdaten, Belegnummern und Zuordnungen verwalten.
+Ergebnis:      Daten je Mandant/Filiale sind getrennt auswertbar; Nummernkreise kollidieren nicht über Filialgrenzen hinweg.
+Belege:
+  - [PRIMÄR]   NumberGroupBL.RefreshAllNumberGroups / CreateNumberGroups (src\backend\Centron.BL\Administration\Company\NumberGroupBL.cs:136-152) - Begründung: durchgesetzte Anlage von Nummernkreisen je Mandant und Filiale.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql: CREATE TABLE [dbo].[Mandant], [dbo].[Filiale], [dbo].[WarenFilialeErloeskonto] - Begründung: Datenmodell trägt Mandanten-/Filialdimension bis auf Erlöskonten.
+Prüfidee:      Zwei Filialen desselben Mandanten vergeben dieselbe Belegnummer aus separaten Nummernkreisen ohne Kollision; Mandant A sieht keine Belege von Mandant B.
+Tracelinks:    SyRS-007, SyRS-008, SwRS-008, SwRS-009
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Multi-Mandantenfähigkeit ist Kernanforderung für SaaS-Betrieb.
+Status:        belegt
+
+ID:            StRS-004
+Titel:         Beleggestützter Vertriebsprozess von Angebot bis Rechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Innendienst
+Vorbedingung:  Kundenstammsatz existiert; Benutzer hat Belegrechte.
+Fakt:          Der Code implementiert ein einheitliches Belegsystem für Angebote, Aufträge, Lieferscheine, Abholscheine, Rechnungen, Gutschriften und Verträge über generische Receipt-BLs mit Belegart-spezifischen Strategien (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs, SpecificLogics.cs); Belegkopf-/Positions- und Versionstabellen existieren je Belegart (AngKopf/-Versions, AufKopf/-Versions, LiefKopf/-Versions, RechKopf/-Versions, GutKopf/-Versions, AbholKopf/-Versions).
+Aussage:       Das System soll den Vertriebsprozess als Kette einheitlich strukturierter Belege (Angebot → Auftrag → Lieferschein → Rechnung, inkl. Gutschrift/Abholung) abbilden, mit Weiterverarbeitung (Forward) zwischen Belegarten, Versionierung und Sperrung gegen parallele Bearbeitung.
+Ergebnis:      Jede Vertriebsentscheidung ist als versionierter, gesperrter Beleg dokumentiert und nachvollziehbar fortgeschrieben.
+Belege:
+  - [PRIMÄR]   ReceiptBL.CreateNewVersion / CreateLock / RemoveLock (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:3063-3175) - Begründung: durchgesetzte Versions- und Sperrlogik auf Belegen.
+  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: RechKopfVersions, AufPosVersions u. a. Versions- und Kopf-/Positionstabellen je Belegart - Begründung: Persistenz der Belegkette inkl. Versionen.
+  - [SEKUNDÄR] InvoiceSpecificLogic.CanBeForwardedInto => CreditVoucherClass (src\backend\Centron.BL\Sales\Receipts\Invoices\InvoiceSpecificLogic.cs:280) - Begründung: regelt zulässige Belegübergänge (Rechnung → Gutschrift).
+Prüfidee:      Aus einem Angebot wird per Weiterverarbeitung ein Auftrag erzeugt; gleichzeitig geöffnete Bearbeitung durch zwei Benutzer erzeugt eine Sperrmeldung; jede Änderung erzeugt Version n+1.
+Tracelinks:    SyRS-016, SyRS-017, SyRS-018, SyRS-020, SwRS-016, SwRS-017, SwRS-018
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Belegkette ist Kernfachlichkeit; Implementierungsdetails (623-KB-Monolith ReceiptBL.cs) sind im Zielsystem zu zergliedern.
+Status:        belegt
+
+ID:            StRS-005
+Titel:         Verbindliche Preisfindung aus Stammdaten und Vereinbarungen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertrieb, Controlling
+Vorbedingung:  Artikel, Kundensonderpreise/Sondervereinbarungen und USt-Sätze sind gepflegt.
+Fakt:          Die Preisfindung speist sich aus Sondervereinbarungen, Mengenpreisen, Einkaufspreisen je Lager und Ländereinstellungen und wird zentral in ReceiptItemPriceBL berechnet; Schalter wie OrderHasGlobalSpecialAgreement/OfferHasGlobalSpecialAgreement steuern die Geltung (src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs:29-79).
+Aussage:       Das System soll Belegpositionen verbindlich aus gepflegten Preisquellen (Sondervereinbarungen, Sonderpreise, Mengenpreise, Artikel-/Einkaufspreise) und gültigen USt-Sätzen ableiten, damit angebotene und fakturierte Preise übereinstimmen.
+Ergebnis:      Belegpreise sind deterministisch aus Stammdaten hergeleitet und nachvollziehbar.
+Belege:
+  - [PRIMÄR]   ReceiptItemPriceBL (src\backend\Centron.BL\Sales\Receipts\Internal\ReceiptItemPriceBL.cs, Konstruktor & Caches für SpecialAgreement/ArticleVolumePrices/ArticlePurchasePriceInWarehouse) - Begründung: zentrale, durchgesetzte Preisberechnungsstelle.
+  - [SEKUNDÄR] Tabellen Sonderaktionen, Zahkond, MwstSatz (SSMS_DB_SCHEMA.sql) - Begründung: Preis- und Steuergrundlagen im Datenmodell.
+Prüfidee:      Für einen Kunden mit Sondervereinbarung wird der vereinbarte Preis – nicht der Listenpreis – in Angebot, Auftrag und Rechnung angesetzt; ohne Vereinbarung gilt der Artikel-/Listenpreis.
+Tracelinks:    SyRS-019, SwRS-019
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Preisfindung ist abrechnungskritisch; Quellkaskade im Zielsystem explizit dokumentieren.
+Status:        belegt
+
+ID:            StRS-006
+Titel:         Forderungsmanagement mit gestuftem Mahnwesen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung, Debitorenbuchhaltung
+Vorbedingung:  Offene Rechnungen (OPOS) existieren; Mahnkonfiguration ist gepflegt.
+Fakt:          Rechnungen tragen Mahnstufen-Felder (DunningLevel, DunningLevel1/2/3Date, DunningLevel1/2/3Employee); der Mahnlauf setzt Stufen 1→2→3 mit Datum und Bearbeiter und kann Stufen zurücknehmen (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs:253-268, 519-539).
+Aussage:       Das System soll offene Forderungen in bis zu drei Mahnstufen verfolgen, jede Mahnung mit Datum und Bearbeiter protokollieren und Stufenrücknahmen unterstützen.
+Ergebnis:      Mahnhistorie je Rechnung ist nachvollziehbar; Inkasso-Übergabe basiert auf Stufe 3.
+Belege:
+  - [PRIMÄR]   DunningRunBL (src\backend\Centron.BL\Sales\Receipts\Invoices\Dunning\DunningRunBL.cs:253-268, 519-539) - Begründung: durchgesetzte Stufenlogik inkl. Zuordnung von Datum und Employee.
+  - [SEKUNDÄR] Tabelle Mahnlauf (SSMS_DB_SCHEMA.sql) - Begründung: Persistenz der Mahnläufe.
+Prüfidee:      Mahnlauf erhöht Stufe je Rechnung um genau eine Stufe und setzt Stufendatum/Bearbeiter; Rücknahme setzt Felder zurück und protokolliert die Übergänge.
+Tracelinks:    SyRS-021, SyRS-022, SwRS-021, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Forderungsmanagement ist abrechnungskritisch.
+Status:        belegt
+
+ID:            StRS-007
+Titel:         Beschaffung und Lagerhaltung mit Verfügbarkeitsnachweis
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkauf, Lager, Vertrieb
+Vorbedingung:  Artikelstamm und Lagerorte sind angelegt.
+Fakt:          Datenmodell enthält Bestellkopf/-positionen (BestKopf2/BestPos2), Wareneingangsbelege (WareKopf/WarePos), Lagerorte/-plätze (Warehouses, Lagerort, Lagerplatz) und Bestandsabfragen mit Bedarfsermittlung (ArticleStockBL.GetArticleStockDemands, src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs:42-44); Bestandsbuchungen wirken auf Barcode/Seriennummern (ArticleStockBL.IncreaseArticleStock, Kommentar zu ScanBarcodes).
+Aussage:       Das System soll Beschaffung (Bestellung → Wareneingang) und Lagerhaltung (Bestände je Artikel und Lagerort, Seriennummern, Inventur) so führen, dass Vertrieb und Service jederzeit die Verfügbarkeit und Herkunft von Material nachweisen können.
+Ergebnis:      Bestände, Bedarfe und Seriennummern sind je Lagerort nachweisbar.
+Belege:
+  - [PRIMÄR]   ArticleStockBL.UpdateArticleStock / IncreaseArticleStock (src\backend\Centron.BL\Warehousing\StockManagement\ArticleStockBL.cs:47-61) - Begründung: durchgesetzte Bestandsfortschreibung.
+  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql: BestKopf2, BestPos2, WareKopf, WarePos, Warehouses, Lagerort, Lagerplatz - Begründung: Beschaffungs- und Lagerdatenmodell.
+Prüfidee:      Wareneingang auf Bestellung erhöht Bestand am gewählten Lagerort; Auslieferung per Lieferschein vermindert ihn; Seriennummernbuchung wirkt nur bei aktivem ScanBarcodes auf den Bestand.
+Tracelinks:    SyRS-025, SyRS-026, SyRS-027, SyRS-028, SyRS-029, SyRS-030, SwRS-025, SwRS-026, SwRS-027, SwRS-028, SwRS-029
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lager- und Beschaffungslogik ist fachlich weiter erforderlich.
+Status:        belegt
+
+ID:            StRS-008
+Titel:         Servicedienstleistungen mit Zeitaufwand und Abrechnung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Service/Helpdesk, Vertrieb, Kunde
+Vorbedingung:  Ticket existiert; Mitarbeiter-/Artikelstämme sind gepflegt.
+Fakt:          Tickets haben konfigurierbare Status mit festem "Abgeschlossen"-Zustand, Pflichtfeldprüfung und Historie beim Abschluss (HelpdeskStatusBL, HelpdeskCloseBL:120-151); Zeiterfassung (hlpdsk_timer) ist an Tickets gebunden und wird zu Belegen mit Positionen verdichtet (ReceiptBL.CreateNewReceiptForHelpdekTimers, ReceiptBL.cs:5295).
+Aussage:       Das System soll Serviceaufträge als Tickets mit Statusworkflow, Zeiterfassung und Abrechnung (Timer → Beleg) führen, damit erbrachte Leistungen nachvollzehbar dokumentiert und fakturiert werden.
+Ergebnis:      Aus Tickets und Zeiteinträgen entstehen prüffähige Belege; Ticketverlauf und -zeiten sind historisiert.
+Belege:
+  - [PRIMÄR]   HelpdeskCloseBL.CloseHelpdesk (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:120-151) - Begründung: durchgesetzte Abschlusslogik mit Pflichtfeldprüfung, ClosedAt, Historie und Benachrichtigung.
+  - [PRIMÄR]   ReceiptBL.CreateNewReceiptForHelpdekTimers (src\backend\Centron.BL\Sales\Receipts\ReceiptBL.cs:5295) - Begründung: durchgesetzte Belegbildung aus Zeiteinträgen.
+  - [SEKUNDÄR] Tabellen hlpdsk_requests, hlpdsk_status, hlpdsk_timer, hlpdsk_history (SSMS_DB_SCHEMA.sql) - Begründung: Ticket-, Status-, Zeit- und Historiendatenhaltung.
+Prüfidee:      Ticketabschluss ohne Pflichtfeldinhalte wird verweigert; aus zwei Zeiteinträgen entsteht ein Beleg mit zwei Positionen und den gebuchten Artikeln.
+Tracelinks:    SyRS-032, SyRS-033, SyRS-034, SyRS-053, SwRS-030, SwRS-031, SwRS-032
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Serviceprozess mit Zeitabrechnung ist Kernfachlichkeit.
+Status:        belegt
+
+ID:            StRS-009
+Titel:         Revisionssichere Finanzdokumentation und Buchhaltungsübergabe
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Finanzbuchhaltung, Steuerberater/Wirtschaftsprüfung
+Vorbedingung:  Belege sind gebucht; Exportkonfiguration existiert.
+Fakt:          Buchhaltungsexporte (DATEV Ascii/XML-Online) sind als Konfigurationsobjekte mit Erstell-/Änderungs-Metadaten (CreatedDate, CreatedVersion, CreatedBy, ChangedDate, ChangedBy) und genau einer DefaultExport-Konfiguration persistiert (src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs:91-125); Belegversionen bleiben als eigene Versionstabellen erhalten.
+Aussage:       Das System soll Finanzdaten revisionssicher dokumentieren und in standardisierten Formaten (u. a. DATEV) an die Finanzbuchhaltung übergeben, inkl. nachvollziehbarer Erstell-/Änderungsangaben je Exportkonfiguration.
+Ergebnis:      Exporte sind rekonstruierbar; genau eine Exportkonfiguration ist als Standard aktiv.
+Belege:
+  - [PRIMÄR]   BookKeepingExportBL.SaveExportSettings (src\backend\Centron.BL\DataExchange\BookKeeping\BookKeepingExportBL.cs:91-125) - Begründung: durchgesetzte Metadatenpflege und DefaultExport-Eindeutigkeit.
+  - [SEKUNDÄR] Centron.Gateway\DataExchange\BookKeeping (DatevAscii, DatevXmlOnline, DatevXMLOnline2020) - Begründung: Formatimplementierungen für den Übergabestandard.
+Prüfidee:      Nach Anlage einer neuen DefaultExport-Konfiguration ist genau eine Konfiguration als Standard markiert; jede Änderung trägt geänderten Benutzer/Version.
+Tracelinks:    SyRS-035, SyRS-018, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Buchhaltungsübergabe ist gesetzlich motiviert.
+Status:        belegt
+
+ID:            StRS-010
+Titel:         Elektronischer Geschäftsverkehr mit Lieferanten, Kunden und Behörden
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Einkauf, Vertrieb, Lieferanten (EDI), Kunden (Portal), Empfänger von E-Rechnungen
+Vorbedingung:  Partnerkonfigurationen (EDI/Portal/FinAPI) sind eingerichtet.
+Fakt:          Ein EDI-Dispatcher verteilt Bestell-/Warenkorbprozesse auf Lieferantenprotokolle (Alltron, ALSO/AlsoCH, EGIS, Komsa, OpenTrans 2.1) (src\backend\Centron.BL\EDI\EDIDispatcherBL.cs, EDI\SupplierEDI\SupplierEdiBL.*); Rechnungen werden als ZUGFeRD/XRechnung exportiert (InvoiceZugferdBL, inkl. Leitweg-ID und Comfort/XInvoice-Varianten); Kunden bestellen über ein Web-Shop-Modul (src\nexus\CentronNexus\WebCart) auf Basis ihrer Sonderpreise (README.md, Abschnitt WebCart).
+Aussage:       Das System soll Geschäftsdaten elektronisch mit Lieferanten (Bestellungen/Lieferscheine), Kunden (Portal/Shop, Angebotsfreigabe, Signierung) und E-Rechnungsempfängern austauschen.
+Ergebnis:      Bestellungen, Bestätigungen, E-Rechnungen und Portaltransaktionen laufen ohne manuelle Datenübernahme.
+Belege:
+  - [PRIMÄR]   EDIDispatcherBL und SupplierEdiBL je Partner (src\backend\Centron.BL\EDI\EDIDispatcherBL.cs; src\backend\Centron.BL\EDI\SupplierEDI\SupplierEdiBL.Alltron.cs u. a.) - Begründung: durchgesetzte Partnerzuordnung und Protokollverarbeitung.
+  - [PRIMÄR]   InvoiceZugferdBL.GenerateZugferdFile (src\backend\Centron.BL\DataExchange\EDI\SaleInvoices\InvoiceZugferdBL.cs:124-155) - Begründung: durchgesetzte E-Rechnungserzeugung inkl. Leitweg-ID.
+  - [SEKUNDÄR] README.md (WebCart-Abschnitt) - Begründung: beschreibt Fachregel "Artikel kommen aus den Sonderpreisen des Kunden".
+Prüfidee:      Eingelesene OpenTrans-Bestellung erzeugt einen Bestellbeleg; exportierte ZUGFeRD-Datei enthält Leitweg-ID und ist schema-valid; Portal-Bestellung landet als Belegentwurf im System.
+Tracelinks:    SyRS-039, SyRS-040, SyRS-041, SyRS-042, SyRS-044, SyRS-046, SwRS-038, SwRS-039, SwRS-041, SwRS-044
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - elektronischer Datenaustausch ist fachlich weiter erforderlich; Partnerliste ist konfigurierbar zu halten.
+Status:        belegt
+
+ID:            StRS-011
+Titel:         Geheim- und Datenschutz für sensible Daten
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Datenschutzbeauftragter, Systemadministration, alle Benutzer
+Vorbedingung:  System ist installiert; Datenschutzkonfiguration (DSGVO-Ordner, Verschlüsselungsschlüssel) existiert.
+Fakt:          Passwörter im Passwort-Manager werden mit AES und einem Masterkey aus der zentralen Konfigurations-DB verschlüsselt (src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs:700, 1051-1052, 1179); Mail-Scanner-Profile verschlüsseln Zugangsdaten vor der Speicherung (MailScannerBL.SaveProfile); DSGVO-Verzeichnisanbieter existieren (src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\Dsgvo); Zugangsdaten sind faktisch als SHA1-Hash gespeichert (UsersBL, WebAccountBL).
+Aussage:       Das System soll vertrauliche Daten (Kundenpasswörter, Dienst-Zugangsdaten, personenbezogene Ablagen) nur verschlüsselt bzw. zugriffsbeschränkt speichern und verarbeiten und DSGVO-relevante Dokumentation eigenständig verwalten.
+Ergebnis:      Sensible Werte liegen nicht im Klartext in der Datenbank; DSGVO-Ablagen sind getrennt verwaltbar.
+Belege:
+  - [PRIMÄR]   PasswordManagerBL (src\backend\Centron.BL\PasswordManager\PasswordManagerBL.cs:700, 1051-1052) - Begründung: durchgesetzte AES-Verschlüsselung mit Masterkey vor Persistenz.
+  - [PRIMÄR]   MailScannerBL.SaveProfile (src\backend\Centron.BL\MailScanner\MailScannerBL.cs:74-84) - Begründung: durchgesetzte Ver-/Entschlüsselung der Profil-Zugangsdaten.
+  - [KONTEXT]  src\backend\Centron.BL\Administration\FileManagement\DirectoryReferenceProviders\Dsgvo - Begründung: dokumentierte DSGVO-Ablagestruktur; SHA1-Hashspeicherung (UsersBL.cs:107, WebAccountBL.cs:56) ist als Altlast im Zielsystem zu ersetzen.
+Prüfidee:      In der Datenbank ist für Passwort-Manager-Werte nur Ciphertext enthalten; Entschlüsselung gelingt nur mit gültigem Masterkey; DSGVO-Dokumente sind nur über den DSGVO-Ordneranbieter erreichbar.
+Tracelinks:    SyRS-011, SyRS-038, SyRS-045, SwRS-037, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: Workaround - SHA1-Hashspeicherung ist historisch überholt und im Zielsystem durch starke Hashverfahren (z. B. Argon2/bcrypt) zu ersetzen; Verschlüsselungsidee bleibt.
+Status:        belegt
+
+ID:            StRS-012
+Titel:         Lizenzgesteuerte Funktionsausprägung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Softwareanbieter, Systemadministration
+Vorbedingung:  Lizenzdatei ist eingespielt.
+Fakt:          Funktionsmodule werden lizenzabhängig freigegeben: Online-Banking prüft LicenseGuids.OnlineBanking_FinApi (OnlineBankingFinApiBL.cs:33), Produktion prüft LicenseGuids.ProductionManagement und verweigert ohne Lizenz mit Fehlermeldung (ArticleProductionBL.cs:34-56); LicenseManager stellt HasLicense/CheckLicense bereit (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs:31-39).
+Aussage:       Das System soll dessen Funktionsumfang je Kundeneinsatz über Lizenzen steuern, sodass lizenzpflichtige Module erst bei gültiger Lizenz nutzbar sind.
+Ergebnis:      Nicht lizenzierte Module sind gesperrt bzw. liefern leere Daten mit klarer Meldung.
+Belege:
+  - [PRIMÄR]   OnlineBankingFinApiBL.GetFinApiClientCredentials (src\backend\Centron.BL\Finances\OnlineBanking\OnlineBankingFinApiBL.cs:29-49) - Begründung: durchgesetzte Lizenzprüfung vor Freigabe der FinAPI-Credentials.
+  - [PRIMÄR]   ArticleProductionBL (src\backend\Centron.BL\Warehousing\ArticleProduction\ArticleProductionBL.cs:34-56) - Begründung: durchgesetzte Lizenzsperre mit Ausnahme-/Fehlermeldung.
+  - [SEKUNDÄR] LicenseManager.HasLicense/GetLicenseCount (src\backend\Centron.BL\Administration\Licensing\LicenseManager.cs:31-39) - Begründung: zentrale Lizenzschnittstelle.
+Prüfidee:      Ohne Produktionslizenz liefert der Produktionszugriff nur leere Daten bzw. eine Fehlermeldung; mit Lizenz sind Produktionsaufträge vollständig nutzbar.
+Tracelinks:    SyRS-006, SyRS-031, SyRS-036, SwRS-007, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Lizenzsteuerung ist Geschäftsmodellbestandteil des Anbieters.
+Status:        belegt
+
+ID:            StRS-013
+Titel:         Web- und Cloud-Betriebsfähigkeit der Suite
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Portierbarkeit / Betriebbarkeit (ISO 25010: Übertragbarkeit, Wartbarkeit)
+Akteur:        Softwarebetrieb, Hosting, Entwicklung
+Vorbedingung:  Zielplattform (Server/Container) ist verfügbar.
+Fakt:          Die Suite wird über Docker-Images (docker\c-entron-webservice\Dockerfile, docker\c-entron-api\Dockerfile, docker\compose\compose.yaml), WiX-Installationspakete (deployment\centron\CentronSetupProject\Product.wxs) und Azure-DevOps-Build-/Testpipelines (azure\build-pipeline.yml, azure\tests-pipeline.yml) gebaut und betrieben; Ziel ist laut Auftrag eine Web-/SaaS-Neuimplementierung.
+Aussage:       Das System soll containerisiert/automatisiert installier- und betreibbar sein, sodass Bereitstellung, Aktualisierung und Regressionstests wiederholbar erfolgen können.
+Ergebnis:      Deployment und Tests laufen pipeline-gesteuert; Installation ist ohne manuelle Einzelritte wiederholbar.
+Belege:
+  - [SEKUNDÄR] docker\compose\compose.yaml und docker\c-entron-webservice\Dockerfile - Begründung: konkrete Containerisierung von Webservice und Abhängigkeiten.
+  - [SEKUNDÄR] azure\build-pipeline.yml, azure\tests-pipeline.yml, azure\regression-tests-pipeline.yml - Begründung: automatisierte Build-/Testkette.
+  - [SEKUNDÄR] deployment\centron\CentronSetupProject\Product.wxs - Begründung: klassische Desktop-Installation als zweiter Betriebsweg.
+Prüfidee:      Aus dem Repository lässt sich der Webservice per Pipeline bauen und in einen Container deployen; Regressionstests laufen gegen die bereitgestellte Instanz.
+Tracelinks:    SyRS-044, SwRS-048
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - automatisierter Betrieb ist Voraussetzung für SaaS.
+Status:        belegt
+
+ID:            StRS-014
+Titel:         Organisation, Personal und Terminsteuerung im System führen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Führungskräfte, Mitarbeiter
+Vorbedingung:  Personalstamm ist angelegt; Benutzer sind Mitarbeitern zugeordnet.
+Fakt:          Personal- und Gruppenstammdaten (Tabellen Personal, PersonalGruppen), Terminplanung (Terminplanung, TerminplanungPerson), Aufgaben/ToDos (ToDoListe) und Zeiterfassung inkl. externem CTime-Connector (src\backend\Centron.BL\Services\CTimeConnectors\CTimeConnectorBL.cs) sind Bestandteil der Suite; Kalender-/Auslastungsrechte sind dokumentiert (CentronRights.md, Abschnitt Mitarbeiterauslastung).
+Aussage:       Das System soll interne Organisation (Personal, Termine, Aufgaben, geleistete Zeiten) so führen, dass Auslastung, Fälligkeiten und Leistungszeiten je Mitarbeiter auswertbar sind.
+Ergebnis:      Führungskräfte können Auslastung und Fälligkeiten je Mitarbeiter einsehen (rechtebeschränkt).
+Belege:
+  - [PRIMÄR]   CTimeConnectorBL (src\backend\Centron.BL\Services\CTimeConnectors\CTimeConnectorBL.cs) - Begründung: durchgesetzter Zeitsynchronisationsdienst mit Übertragungsdatum.
+  - [KONTEXT]  CentronRights.md (Mitarbeiterauslastung: nur eigene Filiale) - Begründung: dokumentierte Fachregel zur Auslastungssicht.
+  - [SEKUNDÄR] Tabellen Personal, PersonalGruppen, Terminplanung, TerminplanungPerson, ToDoListe (SSMS_DB_SCHEMA.sql) - Begründung: Organisationsdatenhaltung.
+Prüfidee:      Termin mit zugeordneter Person erscheint im Personkalender; CTime-Import überträgt nur Zeitsätze nach dem letzten Übertragungsdatum.
+Tracelinks:    SyRS-050, SyRS-051
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Personal-/Zeitdaten tragen Abrechnung und Auslastung.
+Status:        belegt
+
+ID:            StRS-015
+Titel:         Konsolidierte Datenhaltung gleichartiger Geschäftsobjekte
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Geschäftsführung, Systemadministration
+Vorbedingung:  Migrationsprojekt ist gestartet.
+Fakt:          Die Codebasis hält gleichartige Konzepte doppelt: Drucker werden als "Stammblätter" und sonstige Hardware getrennt als "Assets" geführt (vorgegebene Konsolidierungsbeispiel-Regel; Stammblatt-/Asset-Datenhaltung im Modul Devices/AssetManagement), es existieren parallel Beleg-Kopf- und Versionstabellen je Belegart sowie getrennte Kunden-/Lieferantenstämme (Kunden, Kreditor) mit eigenen Nummernkreisen.
+Aussage:       Das Zielsystem soll gleichartige Geschäftsobjekte (Hardware/Drucker, Belegarten, Partner) auf konsolidierte Konzepte abbilden, um Doppelhaltung und Inkonsistenzen zu vermeiden.
+Ergebnis:      Ein Objekttyp existiert genau einmal; bestehende Doppelhaltungen werden bei Migration zusammengeführt.
+Belege:
+  - [SEKUNDÄR] Tabellen AssetManagementDevices, AccountDevices, GeraeteKopf (SSMS_DB_SCHEMA.sql) - Begründung: drei parallele Geräte-/Asset-Datenhaltungen im Schema.
+  - [KONTEXT]  Vorgabe der Auswertung (Konsolidierungsbegriff, Drucker/Asset-Beispiel) - Begründung: benennt das Doppelhaltungsmuster als fachlich bekannt.
+Prüfidee:      Im Zielsystem ist ein Gerät/Drucker in genau einer Datenhaltung abgelegt; Belege referenzieren dieses Konzept eindeutig.
+Tracelinks:    SyRS-027, SyRS-053, SwRS-047
+Konsolidierung: Kandidat: Stammblätter vs. Assets; Kunden/Kreditor-Stämme; Belegart-Kopf-/Versionstabellen
+Übernahmewürdigkeit: übernehmen - Konsolidierung ist Ziel der Neuimplementierung; Altstrukturen sind `veraltet` für das Zielsystem.
+Status:        belegt
+
+ID:            StRS-016
+Titel:         Nachvollziehbare Änderungsverfolgung sensibler Objekte
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Rückverfolgbarkeit (ISO 25010: Zuverlässigkeit/Wartbarkeit)
+Akteur:        Compliance/Audit, Systemadministration
+Vorbedingung:  Change-Tracking ist aktiviert.
+Fakt:          Die Suite enthält ein Change-Tracking-Modul (src\backend\Centron.BL\ChangeTracking) mit eigener Persistenzschicht (src\backend\Centron.DAO\ChangeTracking) und Interface-Layer (src\backend\Centron.Interfaces\ChangeTracking); Belegabschlüsse erzeugen Historien- und Aktivitätsdatensätze (HelpdeskCloseBL:150-151: HistoryForActionType, CreateActivityForTicketClosed).
+Aussage:       Das System soll fachlich relevante Änderungen (z. B. Belegabschluss, Statuswechsel) mit Wer-Hat-Wann-Angaben protokollieren, damit Änderungen auditierbar sind.
+Ergebnis:      Für geprüfte Objekttypen existieren Änderungsprotokolle mit Benutzer und Zeitpunkt.
+Belege:
+  - [PRIMÄR]   HelpdeskCloseBL (src\backend\Centron.BL\Sales\Support\HelpdeskCloseBL.cs:150-151) - Begründung: durchgesetzte Historien-/Aktivitätserzeugung beim Abschluss.
+  - [SEKUNDÄR] src\backend\Centron.BL\ChangeTracking und src\backend\Centron.DAO\ChangeTracking - Begründung: Vorhandensein einer Change-Tracking-Architektur; Granularität im Detail im Zielsystem zu spezifizieren.
+Prüfidee:      Abschluss eines Tickets erzeugt einen Historieneintrag mit Benutzer und Zeitstempel; Änderungen an getrackten Entitäten sind im Change-Log nachweisbar.
+Tracelinks:    SyRS-012, SyRS-018, SyRS-032, SwRS-031
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Auditierbarkeit ist für ERP-Prozesse erforderlich.
+Status:        belegt

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

@@ -0,0 +1,79 @@
+# Traceability (c-entron ERP-Suite)
+
+Konsolidierte Traceability-Tabelle über alle drei Ebenen. Zuordnung: Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung (siehe `Tracelinks` in SwRS.md), jede SyRS-Anforderung die zugehörige StRS-Anforderung (siehe `Tracelinks` in SyRS.md). Diese Tabelle fasst die Beziehungen je Belegkette zusammen und verknüpft mit dem Hauptartefaktbeleg.
+
+## Traceability-Tabelle (StRS | SyRS | SwRS | Artefaktbeleg)
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Hauptquelle) |
+|---|---|---|---|
+| StRS-001 | SyRS-001 | SwRS-003 | TicketAuthenticationHandler.cs:44-95 (src\webservice\Centron.Host\AspNetCore) |
+| StRS-001 | SyRS-001 | SwRS-002 | AuthorizeUserRightAttribute.cs:38-56 + TicketAuthenticationHandler.cs |
+| StRS-001 | SyRS-003 | SwRS-004 | UsersBL.cs:56-130 (src\backend\Centron.BL\Administration\Logins) |
+| StRS-001 | SyRS-004 | SwRS-006 | TwoFactorAuthBL.cs:33-120 (…\Logins\TwoFactor) |
+| StRS-001 | SyRS-005 | SwRS-005 | WebAccountBL.cs:54-61 (…\Logins) |
+| StRS-002 | SyRS-002 | SwRS-001 | UserRightsConst.cs (766 Konstanten) + UserRightAuthorizationFilter |
+| StRS-003 | SyRS-007 | SwRS-009 | NumberGroupBL.cs:136-152; SSMS_DB_SCHEMA.sql (Mandant, Filiale) |
+| StRS-003 | SyRS-008 | SwRS-008 | NumberGroupBL.cs:62-134 (GetNextNumber/FindNextNumber) |
+| StRS-004 | SyRS-016 | SwRS-016, SwRS-017 | ReceiptBL.cs; SpecificLogics.cs; SSMS_DB_SCHEMA.sql (Kopf-/Pos-/Versions-Tabellen) |
+| StRS-004 | SyRS-017 | SwRS-018 | ReceiptBL.cs:3085-3096 (TryLockReceipt) |
+| StRS-004 | SyRS-018 | SwRS-018 | ReceiptBL.cs:3068-3157 (CreateNewVersion) |
+| StRS-004 | SyRS-020 | SwRS-020 | ReceiptCartReleaseSystemBL.cs; CurrentCartService.cs:24-43 |
+| StRS-005 | SyRS-019 | SwRS-019 | ReceiptItemPriceBL.cs:29-79 |
+| StRS-006 | SyRS-021 | SwRS-021 | DunningRunBL.cs:253-268, 519-539 |
+| StRS-006 | SyRS-022 | SwRS-022 | OposBL.cs; SSMS_DB_SCHEMA.sql (Zahlungseingang/-Log) |
+| StRS-007 | SyRS-025 | SwRS-025 | SupplierOrderBL.cs; SSMS_DB_SCHEMA.sql (BestKopf2/BestPos2) |
+| StRS-007 | SyRS-026 | SwRS-026 | SupplierReceiptDocumentBL.cs; PdfScanning\StrategyHandler\* |
+| StRS-007 | SyRS-027 | SwRS-027 | SSMS_DB_SCHEMA.sql (ARTIK/WAREN/UNTERWAREN); ArticleBL.cs |
+| StRS-007 | SyRS-028 | SwRS-028 | ArticleStockBL.cs:47-148 |
+| StRS-007 | SyRS-029 | SwRS-029 | SSMS_DB_SCHEMA.sql (SeriennummerToPosition, Barcode*) |
+| StRS-007 | SyRS-030 | SwRS-028 | InventoryNewBL.cs (Status HYPOTHESE, s. Hypothesen.md) |
+| StRS-008 | SyRS-032 | SwRS-030, SwRS-031 | HelpdeskStatusBL.cs:75-100; HelpdeskCloseBL.cs:120-151 |
+| StRS-008 | SyRS-033 | SwRS-032 | ReceiptBL.cs:5295 (CreateNewReceiptForHelpdekTimers); CentronRights.md |
+| StRS-008 | SyRS-034 | SwRS-033 | EscalationBL.cs; EscalationReceiversEnum.cs (Status HYPOTHESE) |
+| StRS-008 | SyRS-053 | SwRS-053 | SSMS_DB_SCHEMA.sql (AccountDevicesToTickets, GeraeteKopf) |
+| StRS-009 | SyRS-018 | SwRS-016, SwRS-018 | ReceiptBL.cs:3068-3157; SSMS_DB_SCHEMA.sql (*Versions) |
+| StRS-009 | SyRS-035 | SwRS-034 | BookKeepingExportBL.cs:91-125; Gateway DataExchange\BookKeeping |
+| StRS-009 | SyRS-043 | SwRS-042 | DocumentSigningPage.razor (Status HYPOTHESE) |
+| StRS-010 | SyRS-039 | SwRS-038 | EDIDispatcherBL.cs; SupplierEdiBL.* (src\backend\Centron.BL\EDI) |
+| StRS-010 | SyRS-040 | SwRS-039 | InvoiceZugferdBL.cs:85-155 |
+| StRS-010 | SyRS-041 | SwRS-040 | ShipcloudPackageTemplateBL.cs; Centron.Api.Gls/Shipcloud |
+| StRS-010 | SyRS-042 | SwRS-041 | WebCart\Helpers\*; README.md (WebCart) |
+| StRS-010 | SyRS-044 | SwRS-002, SwRS-048 | RegisterCentronApiVersioning/Swagger; docker\*, azure\* |
+| StRS-010 | SyRS-046 | SwRS-044 | ArticleSearch\*ExternalArticleSearchProvider.cs; src\apis\*DataAccess |
+| StRS-011 | SyRS-011 | SwRS-012, SwRS-048 | DirectoryReferenceProviders\* (inkl. Dsgvo) |
+| StRS-011 | SyRS-038 | SwRS-037 | MailScannerBL.cs:57-84 |
+| StRS-011 | SyRS-045 | SwRS-043 | PasswordManagerBL.cs:608, 700, 949, 1051-1052 |
+| StRS-012 | SyRS-006 | SwRS-007 | LicenseManager.cs:24-158; OnlineBankingFinApiBL.cs:29-49 |
+| StRS-012 | SyRS-031 | SwRS-028 | ArticleProductionBL.cs:30-56 (Status HYPOTHESE bzgl. Rückmeldung) |
+| StRS-012 | SyRS-036 | SwRS-035 | OnlineBankingFinApiBL.cs; FinApiClient.cs |
+| StRS-013 | SyRS-044 | SwRS-048 | RegisterCentronApiVersioning.cs; docker\c-entron-webservice\Dockerfile |
+| StRS-014 | SyRS-050 | SwRS-050 | SSMS_DB_SCHEMA.sql (Terminplanung*, ToDoListe); CentronRights.md (Kalender) |
+| StRS-014 | SyRS-051 | SwRS-051 | CTimeConnectorBL.cs; CTimeConnectorLastTransferDate |
+| StRS-014 | SyRS-055 | SwRS-055 | HelpdeskSendMailBL.cs; GeschaeftspartnerTextbausteine |
+| StRS-015 | SyRS-027 | SwRS-047 | SSMS_DB_SCHEMA.sql (Produktfamilie*Sperren); ProductFamilyBL.cs |
+| StRS-015 | SyRS-013 | SwRS-013 | SSMS_DB_SCHEMA.sql (Kunden/Anschrif/Personen) |
+| StRS-015 | SyRS-014 | SwRS-014 | SSMS_DB_SCHEMA.sql (Kreditor); NumberGroupBL.cs:124-131 |
+| StRS-015 | SyRS-015 | SwRS-015 | SSMS_DB_SCHEMA.sql (Vertriebssteuerung, AngebotVerloren) |
+| StRS-015 | SyRS-053 | SwRS-053 | SSMS_DB_SCHEMA.sql (AssetManagement*, GeraeteKopf) |
+| StRS-016 | SyRS-012 | SwRS-031 | ChangeTracking\* (BL/DAO/Interfaces); HelpdeskCloseBL.cs:150-151 |
+| StRS-016 | SyRS-018 | SwRS-016 | ReceiptBL.cs (Versionslogik); SSMS_DB_SCHEMA.sql (*Versions) |
+| StRS-016 | SyRS-032 | SwRS-030 | HelpdeskStatusBL.cs; HelpdeskCloseBL.cs (Historie) |
+| StRS-016 | SyRS-049 | SwRS-049 | CacheTicketStatisticsBL.cs; TicketFulltextIndex.cs; GermanAnalyzer.cs |
+| StRS-016 | SyRS-052 | SwRS-052 | SSMS_DB_SCHEMA.sql (CRMProjekt, AnfrKopf-Versions, Rma); RmaBL.cs |
+| StRS-016 | SyRS-054 | SwRS-054, SwRS-055 | VoucherManagementBL.cs:17-24; TapiNumberMaps.cs; SocialMedia* |
+
+## Ergänzende Zuordnungen (SyRS ohne eigene Zeile oben)
+
+| SyRS-ID | StRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---|---|---|
+| SyRS-009 | StRS-014 | SwRS-010 | CashBookBookingBL.cs:53; ReceiptItemPriceBL.cs:78-79 |
+| SyRS-010 | StRS-014 | SwRS-011 | Scripts\ScriptMethods\RecurringScriptMethods\* |
+| SyRS-047 | StRS-013 | SwRS-045 | WorkflowProcessBL.cs; WorkflowShapeBL.cs |
+| SyRS-048 | StRS-013 | SwRS-046 | CentronNexus.OutlookAddIn\* (Belege/Ticket/Document) |
+| SyRS-054 | StRS-016 | SwRS-054, SwRS-055 | VoucherManagementBL.cs; SocialMedia*-Tabellen |
+
+## Konsistenzregeln der Tabelle
+
+- Jede Zeile bildet eine Belegkette StRS → SyRS → SwRS; Mehrfachnennungen sind zulässig (n:1-Konsolidierung).
+- Zeilen mit "(Status HYPOTHESE)" verweisen auf Anforderungen, deren Vollaussage als Hypothese geführt wird (siehe Hypothesen.md): SyRS-030, SyRS-031, SyRS-034, SwRS-042.
+- Die Vollständigkeit der Beziehungen ist zusätzlich über die `Tracelinks`-Felder in den drei Spezifikationsdateien prüfbar.

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

@@ -0,0 +1,125 @@
+# Messprotokoll – Iteration 16/z-ai/glm-5.3-flash/solo/high
+
+> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
+> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
+
+## Lauf
+- **Prompt-Datei:** `03_Prompt.md`
+- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
+- **Startzeit:** 2026-09-02T09:34:01.4984399+02:00
+- **Endzeit:** 2026-09-02T09:56:48.1729325+02:00
+- **Dauer gesamt:** 00:22:43 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
+- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
+- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **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 16/z-ai/glm-5.3-flash/solo/high/`
+- **Agentenmodus:** `solo`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
+- **Rollen:** {}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 2.411.196 |
+| Output-Tokens | 88.920 |
+| Reasoning-Tokens | 42.935 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 71 |
+
+**Tokens gesamt: 6.336.907.** Kosten `0` – lokaler Betrieb ().
+
+## Gefundene Anforderungen
+
+## Gefundene Anforderungen
+
+Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
+
+Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
+
+### Verteilung über die Ebenen
+
+| Ebene | Anzahl | Anteil |
+|---|---:|---:|
+| StRS | 16 | 12,7 % |
+| SyRS | 55 | 43,7 % |
+| SwRS | 55 | 43,7 % |
+| **Gesamt** | **126** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 53 | 42,1 % |
+| Daten | 33 | 26,2 % |
+| Sicherheit | 17 | 13,5 % |
+| Schnittstelle | 16 | 12,7 % |
+| nicht-funktional | 7 | 5,6 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 242 |
+| davon `PRIMÄR` | 160 (66,1 %) |
+| davon `SEKUNDÄR` | 75 (31,0 %) |
+| davon `KONTEXT` | 7 (2,9 %) |
+| Belege je Anforderung (Median) | 2,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 123 (97,6 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 113 | 89,7 % |
+| workaround | 13 | 10,3 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 122 | 96,8 % |
+| als `HYPOTHESE` gekennzeichnet | 4 | 3,2 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 15 | 11,9 % |
+| mit ISO-25010-Qualitätsmerkmal | 7 | 5,6 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (32 risikorelevante Anforderungen, alle gedeckt) |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 126 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 126 von 126 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
+- **Session-ID:** `ses_f9ef5eeddffeI5bgXF54VzIYO7`
+- **Werkzeugaufrufe:** 111 – {"bash": 74, "read": 9, "write": 7, "edit": 21}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** []
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

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

@@ -0,0 +1,5 @@
+[2026-09-02T07:34:03.171666+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\Ergebnisse)
+[2026-09-02T07:34:03.337272+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/z-ai/glm-5.3-flash; Modus=solo; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T07:56:46.598851+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T07:56:48.097160+00:00] OpenCode export: Exporting session: ses_f9ef5eeddffeI5bgXF54VzIYO7
+[2026-09-02T07:56:48.149249+00:00] Ende: Exitcode=0; Status=success; Turns=71; Tokens=6336907; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\z-ai\glm-5.3-flash\solo\high\03_Lauf_2026-09-02_093401_v13.0.0-19d9\RawResult.json

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

@@ -0,0 +1 @@
+

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

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

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

@@ -0,0 +1 @@
+

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

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

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

@@ -0,0 +1 @@
+2026-09-02T09:56:48.1729325+02:00

Versuche/Versuch_01/Iteration 16/z-ai/glm-5.3-flash/solo/high/03_Lauf_2026-09-02_093401_v13.0.0-19d9/_meta/opencode-config.json

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

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

@@ -0,0 +1 @@
+2026-09-02T09:34:01.4984399+02:00