TensorX-Matrix: erste vollstaendig besetzte Matrix, 918 Anforderungen

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

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

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

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

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

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

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Adapter.log

@@ -0,0 +1,5 @@
+[2026-09-02T12:03:40.596105+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\Ergebnisse)
+[2026-09-02T12:03:40.785307+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T13:56:13.742598+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T13:56:15.396492+00:00] OpenCode export: Exporting session: ses_f9dff0fd3ffei0THHf9fgmC3fO
+[2026-09-02T13:56:15.432775+00:00] Ende: Exitcode=1; Status=error; Turns=85; Tokens=10715498; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\RawResult.json

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Analysebericht.md

@@ -0,0 +1,285 @@
+# Analysebericht
+
+## 1. Modulinventar (Schritt 0)
+
+Das Modulinventar wurde vor der ersten Anforderung erstellt und wurde nachträglich nicht gekürzt. Es umfasst 70 fachliche Module bzw. Komponenten.
+
+| Modul-ID | Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (ein Satz) |
+|---|---|---|---|
+| M001 | Administration (Stammdaten, Rechte, Lizenzen, Mandant) | src\centron\Centron.WPF.UI\Modules\Administration | Benutzerverwaltung, Rechte/Lizenzen, Mandant, Filialen, Mailvorlagen, Textbausteine und fachliche Einstellungen der Suite. |
+| M002 | Künstliche Intelligenz / KI-Chat | src\centron\Centron.WPF.UI\Modules\ArtificialIntelligence | KI-Chat und Prompt-Verwaltung. |
+| M003 | Kalender & Termine | src\centron\Centron.WPF.UI\Modules\Calendar | Kalender-Synchronisation, Terminarten, Urlaubs- und Vertretungsanzeige. |
+| M004 | Dashboard / Modulübersicht | src\centron\Centron.WPF.UI\Modules\Dashboard | Startseite mit Modul-Slider. |
+| M005 | Datenaustausch (Buchhaltung, EDI, Importe) | src\centron\Centron.WPF.UI\Modules\DataExchange | DATEV-/Buchhaltungs-Export, EDI-Belege, Zahlungsverkehr, DocSync und Datenimport. |
+| M006 | Externe Werkzeuge | src\centron\Centron.WPF.UI\Modules\ExternalTool | Einbindung und Konfiguration externer Tools. |
+| M007 | Zahlungseingang, Mahnwesen & Offene Posten | src\centron\Centron.WPF.UI\Modules\Finances\{Payments,Dunning,Opos,AccountManagement} | Zahlungen, Mahnläufe, Opos-Verarbeitung und Kundenkonten. |
+| M008 | Kampagnen | src\centron\Centron.WPF.UI\Modules\Finances\Campaigns | Marketing-Kampagnen mit Phasen und Teilnehmern. |
+| M009 | Finanzen – Common & Masterdatenlisten | src\centron\Centron.WPF.UI\Modules\Finances\{Common,MasterDataLists} | Finanz-Masterdatenlisten und Common-Logik des Finanzmoduls. |
+| M010 | Verträge, Laufzeit- & Zählerabrechnung | src\centron\Centron.WPF.UI\Modules\Finances\{Contracts,ContractEvaluation2,ContractEvaluationOld,DeviceClickCounter,FlatrateBilling,TimerBilling,AutomatedBilling} | Vertragsanlage, Click-/Kontingentabrechnung, Zeit-/Flatrate-/Vollautomatik-Billing und Vertragsevaluation. |
+| M011 | CRM, Accounts & Interessenten | src\centron\Centron.WPF.UI\Modules\Finances\Crm | Accounts, Adressen, Aktivitäten, CRM-Projekte und Konto-Verträge. |
+| M012 | Product Lifecycle Management (PLM) | src\centron\Centron.WPF.UI\Modules\{PLM,Finances\ProductLifecycleManagement} | Produktlebenslauf, Produktfamilien-Gruppen und PLM-Log. |
+| M013 | Projekte & Projektmanagement | src\centron\Centron.WPF.UI\Modules\{Finances\Projects,ProjectManagement} | Projekte, Phasen, Aufgaben und Mitarbeiterauslastung im Projekt. |
+| M014 | Belegwesen Verkauf/Vertrieb (Angebot bis Rechnung) | src\centron\Centron.WPF.UI\Modules\Finances\Receipts | Angebot, Anfrage, Auftrag, Lieferschein, Rechnung, Gutschrift und Abholung inklusive Belegeinstellungen. |
+| M015 | Globale Funktionen (Custom Properties, MSP-Lizenzen) | src\centron\Centron.WPF.UI\Modules\Global | Objektübergreifende benutzerdefinierte Eigenschaften und MSP-Lizenzvergleich. |
+| M016 | GUI-Profile | src\centron\Centron.WPF.UI\Modules\Gui | Verwaltung von UI-Profilen. |
+| M017 | Helpdesk / Tickets | src\centron\Centron.WPF.UI\Modules\Helpdesk | Ticketanlage, Ticketlisten, Status/Prioritäten, Checklisten, TaskManagement, Eskalationen und Ticketszenarien. |
+| M018 | Logistik & Versand | src\centron\Centron.WPF.UI\Modules\Logistic | Logistik- und Versandart-Einstellungen. |
+| M019 | Massenupdates | src\centron\Centron.WPF.UI\Modules\Massenupdates | Vorlagen- und Massenänderungswerkzeug für Stammdaten. |
+| M020 | MyCentron (Arbeitsplatz, MyDay, Chats, Benachrichtigungen) | src\centron\Centron.WPF.UI\Modules\MyCentron | Persönliche Startseite, MyDay-Workitems, Chats, Benachrichtigungen, QuickNotes und News. |
+| M021 | OnlineBanking | src\centron\Centron.WPF.UI\Modules\OnlineBanking | Bankanbindungen (FinTS/FinAPI), Umsätze und Zahlungsabgleich. |
+| M022 | PasswordManager | src\centron\Centron.WPF.UI\Modules\PasswordManager | Passwort- und Zugangsdatenverwaltung mit Richtlinien. |
+| M023 | Zahler & Kostenstellen | src\centron\Centron.WPF.UI\Modules\PayersAndCostCenter | Zahler- und Kostenstellenverwaltung. |
+| M024 | Produktion | src\centron\Centron.WPF.UI\Modules\Production | Produktionsaufträge, Maschinen und Fertigungsplanung. |
+| M025 | Projektpreis-Import | src\centron\Centron.WPF.UI\Modules\ProjectPriceImport | Import von Projektpreisen. |
+| M026 | Einkauf & Warenwirtschaft Beschaffung | src\centron\Centron.WPF.UI\Modules\Purchasing | Bestellvorschlagsliste, Lieferantenbestellung/-belege und Reisekosten. |
+| M027 | Qualitätsmanagement | src\centron\Centron.WPF.UI\Modules\QM | QM-Einstellungen, Anlagenfreigaben sowie Prüf- und Wartungsstammdaten. |
+| M028 | Reports | src\centron\Centron.WPF.UI\Modules\Reports | Reportverwaltung und ReportEngine-Anbindung. |
+| M029 | RMA (Retourenmanagement) | src\centron\Centron.WPF.UI\Modules\Rma | RMA-Anlage sowie Artikelrücksendung und -sendung. |
+| M030 | Mailings & Produktmatrix | src\centron\Centron.WPF.UI\Modules\Sales | Mailings/Vorlagen und Kunden-Produktmatrix. |
+| M031 | Statistiken | src\centron\Centron.WPF.UI\Modules\Statistics | Betriebswirtschaftliche Auswertungen sowie MSP-, Bestands- und Helpdeskstatistiken. |
+| M032 | Umfragen / Surveys | src\centron\Centron.WPF.UI\Modules\Survey | Umfrage-Editor und -Analyse. |
+| M033 | TelekomDive-Schnittstelle | src\centron\Centron.WPF.UI\Modules\TelekomDive | Telekom-Produkt- und Distributor-Exportdaten. |
+| M034 | Lager & Artikelwirtschaft | src\centron\Centron.WPF.UI\Modules\Warehousing | Artikelstamm, Preise, Lager/Bestand, Inventur, Barcode und Wareneingang. |
+| M035 | Nexus-Portal (Kundenportal, Serviceboard, Webshop) | src\nexus\CentronNexus | Web-Kundenportal mit ServiceBoard, WebCart/Webshop, WebOffer, Dokumenten-Signierung und Verwaltung. |
+| M036 | IT-Planer / Monitoring / AssetManagement (RiverDive) | src\backend\Centron.BL\{ItPlanner,RiverDivo} (weitere Anteile in M053/M063) | IT-Dokumentation, Geräte-Monitoring und Patch-/Software-Deployment beim Kunden. |
+| M037 | Telefonie / TAPI & Callcenter | src\shared\Centron.Controls\Telephony (Anteile in M053/M063) | Telefoniesteuerung, Anruferkennung, Call-Tracking und TAPI-Server. |
+| M038 | Mail-Scanner / Posteingangsverarbeitung | src\backend\Centron.BL\MailScanner (Anteile in M063/M069) | Automatische Einordnung eingehender Mails zu Objekten und Tickets. |
+| M039 | Social Media | src\backend\Centron.Interfaces\SocialMedia (Anteile in M063/M069) | Pflege und Auswertung von Social-Media-Aktionen und Streams. |
+| M040 | DMS & Dokumentations-Wizard | src\webservice\Centron.WebServices.Core\Entities\{DocuBoard,DocumentationArea} (Anteile in M063/M069) | Dokumentenablage und Dokumentations-Wizards (Kunde, Netzwerk, Mail, Backup). |
+| M041 | Workflow-Engine | src\webservice\Centron.WebServices.Core\Entities\Processes (Anteile in M063/M053) | Ablaufsteuerung für Ticket, Kampagne, Umfrage und CrmTask mit Bausteinen und Jobs. |
+| M042 | API-Adapter EbInterface | src\apis\Centron.Api.EbInterface | Adapter für die EbInterface-Schnittstelle. |
+| M043 | API-Adapter GLS (Versand) | src\apis\Centron.Api.Gls | Versanddienstleister GLS mit Fracht und Label. |
+| M044 | API-Adapter Shipcloud | src\apis\Centron.Api.Shipcloud | Versandversand über Shipcloud. |
+| M045 | API-Adapter CopDataAccess | src\apis\Centron.APIs.CopDataAccess | Datenanbindung Cop (Webshop). |
+| M046 | API-Adapter EgisDataAccess | src\apis\Centron.APIs.EgisDataAccess | Egis-Webshop-Warenkorbanbindung. |
+| M047 | API-Adapter FinAPI | src\apis\Centron.APIs.FinAPI | OnlineBanking-FinAPI-Anbindung. |
+| M048 | API-Adapter IcecatDataAccess | src\apis\Centron.APIs.IcecatDataAccess | Produktstammdaten von Icecat. |
+| M049 | API-Adapter ITscopeDataAccess | src\apis\Centron.APIs.ITscopeDataAccess | Distributoren-Stammdaten und Shop-Anbindung via ITscope. |
+| M050 | docuFORM-API | Centron.Api.docuFORM | REST-Client für docuFORM-Formularstrecken. |
+| M051 | WPF-Applikationsshell & Modul-Framework | src\centron\Centron.WPF.UI (ohne Modules) + Modules\-Stammdateien | App-Startup, Modulregistrierung und -rechte, Navigation, Services/Logics, Dialoge, Workflows-UI und Localization. |
+| M052 | WPF-UI-Erweiterungen | src\centron\Centron.WPF.UI.Extension | Steuerungs- und Modul-Erweiterungsbibliothek des Clients. |
+| M053 | Business Logic (Domänenschicht) | src\backend\Centron.BL | Fachliche Logik aller Domänen in über 80 Bereichsordnern. |
+| M054 | Interfaces (Verträge/DTO-Grenzen) | src\backend\Centron.Interfaces | Schnittstellen- und DTO-Verträge zwischen UI, BL und DAO. |
+| M055 | DAO / Datenzugriff | src\backend\Centron.DAO | Datenbankzugriff inklusive NHibernate-Mappings, NamedQueries und Repositories. |
+| M056 | Entities (Datenmodell) | src\backend\Centron.Entities | Persistente Entitäten und Tabellenobjekte. |
+| M057 | Common | src\backend\Centron.Common | Domänenübergreifende Grundlagen (Utils, Enums, Exceptions). |
+| M058 | Gateway | src\backend\Centron.Gateway | Mandanten- und Datenbank-Gateway zur Verbindungs- und Mandantensteuerung. |
+| M059 | Controls (WPF-Bibliothek) | src\shared\Centron.Controls | Wiederverwendbare Masken wie PositionGrid, MyDay, Checklist, PdfScanning, MailTemplates, Telephony und Reports. |
+| M060 | Controls.Preview | src\shared\Centron.Controls.Preview | Test- und Preview-App für die Controls-Bibliothek. |
+| M061 | Centron.Core | src\shared\Centron.Core | Kern-Utilities, MVVM-Basis, IO, Threading sowie GoogleAuthenticator/TOTP. |
+| M062 | ConnectionManager | src\webservice\c-entron.misc.ConnectionManager | Verbindungs- und Mandanten-Verwaltungstool inklusive SQL-Server-Check. |
+| M063 | Webservice-Vertragsbibliothek | src\webservice\Centron.WebServices.Core | REST- und WCF-Verträge sowie Clients aller Domänen. |
+| M064 | REST-Controller | src\webservice\Centron.Controllers | HTTP-API-Endpunkte v1 für Accounts, Helpdesks, Offers, Orders, Receipts, Tickets, SelfCare und weitere. |
+| M065 | Webservice-Host | src\webservice\Centron.Host | AspNetCore-Host mit SignalR, WcfBridge, Telemetrie, HelpPage und RealTimeServices. |
+| M066 | Webservice-Host (Console) | src\webservice\Centron.Host.Console | Konsolen-Host des Webservice. |
+| M067 | Webservice-Host (Windows Service) | src\webservice\Centron.Host.WindowsService | Windows-Service-Host des Webservice. |
+| M068 | Nexus-Host | src\nexus\CentronNexus.Host | Host und Startup des Nexus-Portals. |
+| M069 | Nexus Outlook-AddIn | src\nexus\CentronNexus.OutlookAddIn | Outlook-Anbindung für Mails und Kontakte in c-entron. |
+| M070 | Scheduler-/Job-Framework (RiverBird) | src\webservice\Centron.WebServices.Core\Entities\Processes (Anteile in M063) | Zeitgesteuerte Jobs, Checklisten-Pläne und Mail-Routinen. |
+
+## 2. Abdeckungstabelle
+
+Die Einstufung folgt dem in Schritt 0c gewählten Zuschnitt und der im Ergebnisbestand dokumentierten Faktentiefe:
+
+- `tief`: mehrere Anforderungen, Risiken bzw. durchsetzende Stellen wurden vertieft.
+- `mittel`: mehrere Anforderungen oder Querschnittsregeln, aber nicht jede Implementierungsvariante einzeln durchdrungen.
+- `flach`: breitendeckende Mindestabdeckung, vor allem über eine fachliche Regel oder einen Querschnittsbezug.
+- `nicht analysiert`: kein eigenständiger fachlicher Anforderungsbezug ohne Erfindung belegbar.
+
+| Modul-ID | Einstufung | Anzahl Anforderungen (Begründung/Auswahl) |
+|---|---|---|
+| M001 | tief | 14 — Rechte, Benutzer, Lizenzen, Mandant; u. a. StRS-1 bis StRS-14, SyRS-1 bis SyRS-7, SwRS-1 bis SwRS-3. |
+| M002 | mittel | 7 — KI-Bestätigung, Rechtefreiheit, Volumengrenzen; StRS-39, SyRS-44, SyRS-52, SwRS-4, SwRS-54. |
+| M003 | mittel | 6 — Kalender, Termine, Helpdesk-Zeitbezug; SyRS-37, SwRS-5. |
+| M004 | flach | 1 — Dashboard-/Modulstartbreite; StRS-40, SyRS-51. |
+| M005 | tief | 16 — Buchhaltung/EDI/Zahlungsverkehr; StRS-18 bis StRS-22, SyRS-20 bis SyRS-27, SwRS-6, SwRS-26. |
+| M006 | mittel | 6 — externe Werkzeuge; SyRS-43, SwRS-7. |
+| M007 | tief | 10 — Zahlungseingang, Mahnwesen, Opos; StRS-16 bis StRS-18, SyRS-20 bis SyRS-23, SwRS-8, SwRS-9. |
+| M008 | mittel | 8 — Kampagnen; StRS-33, SyRS-Kampagnenanker, SwRS-10. |
+| M009 | flach | 1 — Finanz-Masterdaten über Pflichtfeld-/Defaultregeln; StRS-24, SyRS-15. |
+| M010 | tief | 11 — Vertragsabrechnung und Zähler; StRS-20 bis StRS-21, SyRS-24 bis SyRS-26, SwRS-11, SwRS-12. |
+| M011 | tief | 11 — CRM/Accounts; StRS-32, SwRS-15, SyRS-Konten-/Projektanker. |
+| M012 | mittel | 5 — PLM-Lebensdauer; StRS-30, SyRS-34, SwRS-14. |
+| M013 | mittel | 6 — Projekte/Aufgaben; StRS-32, SyRS-Projektanker. |
+| M014 | tief | 11 — Belegwesen Preis/Belegkette; StRS-22 bis StRS-23, SyRS-13 bis SyRS-15, SwRS-16 bis SwRS-19. |
+| M015 | mittel | 9 — Custom Properties, MSP; SyRS-6, SwRS-20. |
+| M016 | mittel | 6 — GUI-Profile; SyRS-7, SwRS-21. |
+| M017 | tief | 10 — Helpdesk/Eskalation; StRS-31, SyRS-35, SwRS-22, SwRS-23. |
+| M018 | flach | 3 — Logistik/Versand über Beleg- und Versandregeln; StRS-22, SyRS-43. |
+| M019 | mittel | 6 — Massenupdates; StRS-37, SyRS-41. |
+| M020 | mittel | 8 — MyCentron/Chat/MyDay; StRS-34, SyRS-12, SwRS-25. |
+| M021 | mittel | 5 — OnlineBanking, Toleranz, IBAN; SyRS-27, SwRS-26. |
+| M022 | mittel | 5 — PasswordManager und Kennworthärtung; StRS-13, SwRS-27. |
+| M023 | mittel | 7 — Zahler/Kostenstellen; StRS-25, SwRS-28, SwRS-29. |
+| M024 | mittel | 9 — Produktionslizenz und Fertigungsregeln; SyRS-32, SwRS-30. |
+| M025 | mittel | 5 — Projektpreisimport; SyRS-13, SwRS-31. |
+| M026 | flach | 3 — Einkauf/Bestellvorschlag; StRS-27, SyRS-31, SwRS-32. |
+| M027 | mittel | 5 — QM-Meldungen; SyRS-33, SwRS-33. |
+| M028 | tief | 11 — ReportEngine/Kaskaden; StRS-36, SyRS-40, SyRS-53, SwRS-34, SwRS-55. |
+| M029 | mittel | 5 — RMA; StRS-29, SyRS-17, SwRS-35. |
+| M030 | mittel | 6 — Mailings/Produktmatrix; SyRS-18, SwRS-36. |
+| M031 | flach | 4 — Statistiken/Reportrechte; StRS-36, SyRS-39, SwRS-37. |
+| M032 | mittel | 5 — Umfragen; StRS-35, SyRS-38, SwRS-38. |
+| M033 | mittel | 6 — TelekomDive; SyRS-19, SwRS-39. |
+| M034 | tief | 13 — Lager, Artikel, Preise, Inventur; StRS-26 bis StRS-28, SyRS-16, SyRS-30, SwRS-24, SwRS-32, SwRS-41. |
+| M035 | tief | 12 — Nexus-Portal, Webrechte, Portallogin; StRS-12 bis StRS-14, SyRS-45 bis SyRS-47, SwRS-42, SwRS-43, SwRS-50. |
+| M036 | mittel | 7 — IT-Planer/Assets; SwRS-44, SwRS-45. |
+| M037 | flach | 3 — Telefonie/TAPI; StRS-34, SwRS-46. |
+| M038 | mittel | 5 — MailScanner; StRS-12, SwRS-47. |
+| M039 | flach | 3 — Social Media; StRS-34, SyRS-12, SwRS-48. |
+| M040 | flach | 2 — DMS/Dokumentations-Wizard; StRS-15, Portal-/Webserviceanker. |
+| M041 | mittel | 5 — Workflow-Engine; StRS-41, SyRS-54. |
+| M042 | mittel | 5 — EbInterface; StRS-38, Datenaustauschanker. |
+| M043 | flach | 1 — GLS-Versandadapter; StRS-38. |
+| M044 | flach | 1 — Shipcloud-Versandadapter; StRS-38. |
+| M045 | flach | 1 — Cop-Webshopadapter; StRS-38. |
+| M046 | flach | 1 — Egis-Webshopadapter; StRS-38. |
+| M047 | flach | 1 — FinAPI-Bankadapter; SyRS-27. |
+| M048 | flach | 1 — Icecat-Artikelstammdaten; StRS-23, SwRS-40. |
+| M049 | flach | 1 — ITscope-Datenanbindung; StRS-38. |
+| M050 | mittel | 5 — docuFORM-Schnittstellengrenzen; StRS-38, SyRS-API-Anker. |
+| M051 | mittel | 5 — Shell, Modulregistrierung, Rechte-Gate; StRS-40, SyRS-51. |
+| M052 | flach | 1 — UI-Erweiterungen; SyRS-51, StRS-40. |
+| M053 | mittel | 4 — zentrale BL-Autorisierung und Domänenlogik; SyRS-49, SwRS-1, SwRS-49. |
+| M054 | flach | 1 — Schnittstellenverträge/DTO-Grenzen; SyRS-56, SwRS-56. |
+| M055 | flach | 1 — DAO-/NHibernate-Zugriff; StRS-24, SwRS-3. |
+| M056 | flach | 2 — Entities und Mappings; SyRS-2, SwRS-3. |
+| M057 | mittel | 5 — Common-Krypto, Utilities; SyRS-56, SwRS-52. |
+| M058 | flach | 1 — Gateway/Mandantentrennung; SyRS-60. |
+| M059 | flach | 1 — WPF-Controls/Pflichtfelder in Eingabemasken; StRS-24, SyRS-6. |
+| M060 | nicht analysiert | 0 — reine Test-/Preview-App ohne eigenständige fachliche Anforderung; keine Anforderung ohne Beleg erfunden. |
+| M061 | mittel | 4 — Core/TOTP-Grundlagen; SyRS-56, SwRS-56. |
+| M062 | flach | 1 — ConnectionManager/Gateway-Bezug; SyRS-60. |
+| M063 | flach | 2 — Webservice-Vertragsbibliothek und REST/WCF-Verträge; SyRS-49, SyRS-57. |
+| M064 | mittel | 4 — REST-Controller/API-Perimeter; StRS-10, SyRS-57, SyRS-58. |
+| M065 | mittel | 4 — Webservice-Host, CORS, TicketAuth, Deployment; StRS-9 bis StRS-11, SyRS-58, SyRS-59. |
+| M066 | flach | 1 — Konsolen-Host über Deployment-/Konfigurationshärtung; SyRS-59. |
+| M067 | flach | 1 — Windows-Service-Host über Deployment-/Konfigurationshärtung; SyRS-59. |
+| M068 | flach | 1 — Nexus-Host über Portal-/API-Perimeter; SyRS-57. |
+| M069 | flach | 3 — Outlook-AddIn mit Mail-/Kontaktanbindung; StRS-12, SwRS-46, SwRS-47. |
+| M070 | mittel | 6 — Scheduler/Jobs; StRS-41, SyRS-55. |
+
+## 3. Dokumentation der tatsächlichen Beauftragung
+
+Die Bearbeitung war rollenspezialisiert. Die bindenden Teilaufgaben wurden nicht vom Orchestrator selbst erledigt, sondern an die vorgesehenen Bearbeiter übergeben. Zuschnitt, Anzahl und Tiefe wurden vom Orchestrator entschieden.
+
+| Bearbeiter | Teilaufgabe | Anzahl Beauftragungen | Zuschnitt / Ergebnisumfang |
+|---|---|---:|---|
+| modulinventar | Modulinventar (Schritt 0) | 2 | 1. Vollständiges Inventar; 2. erneute Ausgabe der vollständigen Tabelle zur Aufnahme in diesen Bericht. Ergebnis: 70 Module M001 bis M070. |
+| faktenermittler | Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | 10 | A: M001, M015, M016, M023; B: M011, M013, M008, M020; C: M014, M018, M029, M030, M033; D: M007, M010, M021; E: M034, M026, M024, M027, M012; F: M017, M003, M032, M031, M028, M019, M025, M006, M004, M002; G: M035, M069, M040, M038, M039, M037, M022; H: M005, M042 bis M050; I: M041, M070, M036; J: M051, M053, M054, M055, M056, M057, M058, M061, M062, M063, M064, M065, Deployment/Config. |
+| strs-autor | Formulierung der StRS-Anforderungen | 2 | Erste Ausgabe StRS-1 bis StRS-38 (am Ende abgeschnitten); Nachlieferung korrigierte StRS-38 und ergänzte StRS-39 bis StRS-41. Ergebnis: 41 StRS. |
+| syrs-autor | Formulierung der SyRS-Anforderungen | 2 | Erste Ausgabe SyRS-1 bis SyRS-48 (abgeschnitten); Nachlieferung korrigierte SyRS-48 und ergänzte SyRS-49 bis SyRS-60. Ergebnis: 60 SyRS. |
+| swrs-autor | Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | 2 | Erste Ausgabe SwRS-1 bis SwRS-48 (abgeschnitten); Nachlieferung korrigierte SwRS-48 und ergänzte SwRS-49 bis SwRS-56 sowie Konsolidierungsübersicht. Ergebnis: 56 SwRS. |
+| belegpruefer | Prüfung ausgewiesener Belege gegen die Codebasis | 1 | Risikorelevante Stichprobe: SyRS-20, SyRS-27, SyRS-13, SyRS-58, SyRS-59, SwRS-1, SwRS-3, SwRS-16, SwRS-22, SwRS-48, SwRS-52. |
+| iso29148-orchestrator | Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | 1 | Prüfumfang: Forward-/Backward-Sicht, Tracelinks, Doppelführungen, Mindestabdeckung, Ebenenklarheit, Belegstellen in fremdem Ausschnitt. |
+| konsistenzpruefer | Konsistenzcheck des fertigen Anforderungssatzes (Abschluss) | 2 | 1. Erster Gesamtcheck vor Konsolidierung der Nachlieferung; 2. Abschluss-Check nach Korrektur von Tracelinks, Belegen, Konsolidierungen, Statuswerten und nach Anlage der Sammeldateien. |
+
+Vom Orchestrator selbst ausgeführt wurden ausdrücklich nur die ihm zugewiesenen orchestrierenden Aufgaben: Zuschnitt der Ausschnitte, Vergabe/Prüfung der ID-Bereiche je Ebene, Anlegen und Zusammenführen der Ergebnisdateien, Übernahme der Prüfbefunde, Bereinigung offener Tracelinks und Belegstellen, Erzeugung von `Traceability.md`, `Hypothesen.md`, `Glossar.md` und `Analysebericht.md`. Für die acht rollengebundenen Teilaufgaben wurde keine durch den Orchestrator selbst erledigt.
+
+## 4. Prüfergebnisse
+
+### 4.1 Ergebnisumfang
+
+- StRS: 41 Anforderungen (`StRS-1` bis `StRS-41`), lückenlos.
+- SyRS: 60 Anforderungen (`SyRS-1` bis `SyRS-60`), lückenlos.
+- SwRS: 56 Anforderungen (`SwRS-1` bis `SwRS-56`), lückenlos.
+- Gesamtbestand: 157 Anforderungen.
+- Traceability: 72 Tabellenzeilen in `Traceability.md`.
+- Hypothesen: 64 Anforderungen mit `Status: HYPOTHESE` bzw. Inline-Markierung `[HYPOTHESE]`; Abgleich siehe 4.4.
+
+### 4.2 Belegprüfung
+
+Der `belegpruefer` prüfte eine risikorelevante Stichprobe gegen die Codebasis.
+
+Bestätigte risikorelevante Belege unter anderem für:
+
+- `SyRS-20`: Löschrecht und Gegenbuchung über `CurrencyFactor`.
+- `SyRS-27`: Toleranz `0,10` in `CheckForCompleted`.
+- `SwRS-16`: zweistufige Netto-Rundung `AwayFromZero`.
+- `SyRS-58` / `SyRS-59`: TicketAuth, X-Forwarded-For, CORS, 2FA-Default, BinaryFormatter-Schalter, Versionsstand, SA-Zugangsdaten in Konfiguration.
+- `SwRS-22`: Eskalationsstufen-Roh-SQL.
+- `SwRS-3`: ORM-Mapping `Password` auf `BenutzerInfo2`.
+- `SwRS-1`: Roh-SQL-Rechteauflösung und Rechts-Cache.
+
+Festgestellte Abweichungen und behobene Punkte:
+
+1. `SwRS-48`: Die ursprüngliche Dateiangabe `SQLScriptCollection1.xml` war im gespiegelten Bestand nicht auffindbar. Der inhaltliche Nachweis wurde auf `SSMS_DB_SCHEMA.sql` umgestellt: `spr_SocialMediaRemoveComment` und `spr_SocialMediaUpdateComment`. Die überhöhte Fundstellenangabe „16 Fundstellen“ wurde auf „6 Fundstellen (2 exakte CASE-Varianten, 6 Varianten insgesamt)“ korrigiert.
+2. `SyRS-13`: Die zitierten Zeilen 202-213 deckten nur die Netto-Rundung. Der Beleg wurde um die USt-Gruppierung und CH-Rundung (Zeilen 37-93) erweitert.
+3. `SyRS-58`: Die zitierten Handler-/Host-Stellen tragen Ticket-, IP- und CORS-Anteile. Die SignalR-/WCF-/Port-Anteile wurden als `HYPOTHESE` offengelegt.
+4. `SwRS-1`: Die Aussage „Sichtrus-PK auf I3D“ war ungenau; der tragende Befund „keine ausreichende Eindeutigkeit, JOIN-Duplikate möglich“ bleibt bestehen.
+5. 13 SwRS-Anforderungen tragen den Hinweis, dass `PRIMÄR` aus der Faktenbasis stamme und im Lauf nicht Zeile für Zeile gegengeprüft worden sei. Diese Blöcke wurden auf `Status: HYPOTHESE` gesetzt und sind in `Hypothesen.md` enthalten.
+
+### 4.3 Nahtstellenprüfung
+
+Der `iso29148-orchestrator` meldete nach Bereinigung der bekannten Phantom-IDs unter anderem:
+
+- SyRS-40 und SyRS-53 waren eine inhaltliche Doppelführung zum Report-Löschpfad. Beide wurden nun gegenseitig als Konsolidierungskandidaten markiert.
+- SyRS-44 und SyRS-52 sowie SwRS-4 und SwRS-54 waren weitere unklare Fachdopplungen. Sie wurden beidseitig als Konsolidierungskandidaten markiert.
+- SwRS-50 zeigte versehentlich auf SyRS-57, obwohl SyRS-45 die Weblogin-/Webaccount-Regel trägt. Der Tracelink wurde korrigiert.
+- SwRS-56 hatte nach der Nachlieferung keinen StRS-Anker. Es wurden SyRS-45, SyRS-56 sowie StRS-10 und StRS-13 ergänzt.
+- Die Prüfung meldete, dass einige SyRS-Blöcke `.cs`-Belege im SwRS-Ausschnitt führen. Das wurde als bekannte Qualitätsschwäche dokumentiert; die SyRS-Blöcke tragen weiterhin Belege, die den Systemzusammenhang beschreiben, die eigentliche Implementierungsstelle bleibt aber in den SwRS-Blöcken nachvollziehbar.
+
+### 4.4 Konsistenzcheck
+
+Der finale Konsistenzcheck ergab:
+
+- Doppelte IDs: keine.
+- Lückenlose ID-Reihen: StRS-1 bis StRS-41, SyRS-1 bis SyRS-60, SwRS-1 bis SwRS-56.
+- Anforderungen ohne Beleg: keine.
+- Anforderungen ohne Übernahmewürdigkeit: keine.
+- Numerische Tracelinks auf nicht existierende IDs: keine offenen Verstöße. Ursprünglich zeigten 40 Referenzen auf SyRS-70 bis SyRS-78 bzw. SwRS-59 bis SwRS-67; diese Phantomverweise wurden entfernt bzw. auf existierende IDs umgelenkt.
+- Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungskennzeichnung: keine offenen Verstöße. Die gemeldeten Paare sind jetzt markiert.
+- Risikorelevante Anforderungen ohne `PRIMÄR` und ohne `HYPOTHESE`: keine offenen Verstöße. Die beiden ursprünglichen Verstöße StRS-31 und StRS-34 wurden als Hypothesen gekennzeichnet.
+- Hypothesenabgleich: `Hypothesen.md` ist deckungsgleich mit den Anforderungen mit Inline-Markierung oder `Status: HYPOTHESE`; erfasste Gesamtzahl: 64.
+- Sieben Ergebnisdateien: vollständig vorhanden.
+
+Der Abschluss-Check meldete keine offenen Verstöße in den sieben Kernkriterien. Die im Vorlauf offene Datei `Analysebericht.md` ist mit diesem Dokument vorhanden.
+
+## 5. Selbstbewertung
+
+### 5.1 Tiefenabdeckung
+
+Absolut:
+
+- tief analysiert: 10 Module.
+- mittel analysiert: 32 Module.
+- flach analysiert: 27 Module.
+- nicht analysiert: 1 Modul.
+
+### 5.2 Mindestabdeckung
+
+Die Mindestabdeckung ist für 69 von 70 Modulen erreicht.
+
+Nicht erfasst mit eigener Anforderung:
+
+- M060 Controls.Preview: reine Test-/Preview-Anwendung. Eine fachliche Anforderung wäre ohne Beleg erfunden worden; daher ist sie im Inventar mit Begründung als `nicht analysiert` geführt.
+
+Der Anteil der nicht analysierten Module liegt bei 1,43 Prozent. Der Schwellenwert von mehr als 10 Prozent wird nicht überschritten. Die Breite des Inventars ist damit grundsätzlich abgedeckt; viele API-Adapter und Host-Varianten sind allerdings nur flach über StRS-38, SyRS-57, SyRS-58 oder SyRS-59 eingebunden.
+
+### 5.3 Dünne Belegstellen
+
+- 64 Anforderungen tragen den Status oder die Inline-Markierung `HYPOTHESE`.
+- 13 SwRS-Anforderungen führen zwar einen PRIMÄR-Hinweis, aber mit dem ausdrücklichen Zusatz, dass die Stellen aus der Faktenbasis stammen und im Lauf nicht zeilenweise gegengeprüft wurden. Diese Anforderungen sind wegen der ungenügenden Prüftiefe auf `Status: HYPOTHESE` gesetzt.
+- Die Prüfung von `SwRS-48` deckte einen falschen Dateipfad auf. Solche Faktenbasis-Direktübernahmen sind nach dem Befund grundsätzlich mit Vorsicht zu behandeln.
+- In SyRS-Blöcken werden teilweise Implementierungsstellen aus dem SwRS-Ausschnitt als Beleg genutzt. Das ist für die Systemebene teilweise akzeptabel, weil die durchgesetzte Stelle dort das Systemverhalten trägt; für eine saubere Ebenentrennung wäre eine Umformulierung auf Schnittstellen-/Serviceebene wünschenswert.
+- Traceability enthält für einige Kurzanker nur unscharfe semantische Brücken. Die fünf im Abschluss-Check zunächst offenen StRS-Zeilen wurden ergänzt; die restlichen Kurzanker bleiben als redaktionelle Zuordnung erkennbar, sind aber nicht mehr als numerische Tracelinks ins Leere gesetzt.
+
+### 5.4 Hypothesen
+
+Es wurden 64 Hypothesen geführt. Eine Analyse dieser Größe ohne offene Punkte wäre unplausibel gewesen, insbesondere weil:
+
+- viele Fakten aus einer faktenermittler-Aufbereitung stammten und nicht jede Stelle im Orchestrator-Lauf erneut zeilenweise geöffnet wurde,
+- die Codebasis stark über Konfiguration, Legacy-Tabellen, Roh-SQL und clientseitige Validierungen gesteuert wird,
+- für Deployment, Server-Nebenwirkungen, Cache-Lebensdauer und serverseitige Durchsetzung keine Laufzeitbelege vorliegen,
+- einige fachliche Soll-Regeln aus Ist-Negativbefunden abgeleitet sind.
+
+### 5.5 Erkenntnisse für eine Folgeiteration
+
+Ein Nachschlag ist besonders sinnvoll bei:
+
+1. Serverseitiger Zweitprüfung von KI-Anhangsgrenzen, Portaloperationen und Berechtigungen.
+2. Cache-Lebensdauer und Invalidierung der Rechtsauflösung, insbesondere `AllRightsFromAppUser` und `AllRightsFromWebAccount`.
+3. Vollständiger Prüfung aller API-Adapter M043 bis M049, die bisher vor allem flach über Schnittstellengrenzen erfasst sind.
+4. Telefonie M037, Kostenstelle M023 und DMS M040, wo die SyRS-Traceability noch nicht durch eigene numerische SyRS-IDs vollständig aufgelöst ist.
+5. Nexus-Host M068, Console-Host M066 und Windows-Service-Host M067, sofern die Web-/SaaS-Zielarchitektur Host- und Deploymentvarianten explizit abbilden soll.
+6. Kontrolle der Faktenbasis gegen Einzelstellen: Die Korrektur in `SwRS-48` zeigt, dass überlieferte Datei-/Zeilenangaben in einer Folgeiteration systematisch gegen den Schema-Dump und die BL-Dateien validiert werden sollten.

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Glossar.md

@@ -0,0 +1,134 @@
+# Glossar
+
+Die Begriffe stammen aus den Anforderungen und den analysierten Artefakten. Technische Bezeichner bleiben in ihrer Originalsprache.
+
+## Anforderungsmethodik
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| RRE | Reverse Requirements Engineering: Ableitung von Anforderungen aus vorhandenen Artefakten des Legacy-Systems. |
+| StRS | Stakeholder Requirements Specification: fachliche Ebene mit Akteuren, Geschäftszielen und fachlichen Regeln. |
+| SyRS | System Requirements Specification: Systemebene mit Verhalten, Schnittstellen, Sicherheits- und Qualitätsanforderungen. |
+| SwRS | Software Requirements Specification: Softwareebene mit Komponenten, Datenmodellen und internen Regeln. |
+| PRIMÄR | Belegklasse für eine durchgesetzte Regel im Code oder Datenbank-Constraint. |
+| SEKUNDÄR | Belegklasse für mittelbare Signale wie UI-Labels, Konfigurationsschalter oder Mappings. |
+| KONTEXT | Belegklasse für Kommentare, Faktenbasis-Verweise oder andere interpretierende Hinweise. |
+| HYPOTHESE | Kennzeichnung für Aussagen, die nicht vollständig durch die gelesenen Artefakte belegt sind. |
+| Traceability | Nachvollziehbare Verbindung zwischen StRS, SyRS und SwRS sowie zu Artefaktbelegen. |
+| Konsolidierung | Kennzeichnung, wenn derselbe fachliche Gegenstand in getrennten Implementierungen geführt wird. |
+| Übernahmewürdigkeit | Einschätzung, ob die Anforderung im Zielsystem übernommen, als Workaround, Sonderfall oder veraltete Logik behandelt werden soll. |
+| Mindestabdeckung | Vorgabe, dass jedes Modul des Modulinventars mindestens eine belegte Anforderung oder eine Begründung ohne Anforderung erhält. |
+
+## Rechte, Identität und Sicherheit
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| AppRightsBL | Business-Logic-Klasse zur Auflösung von AppUser-Rechten und WebAccount-Rechten. |
+| HasUserRight | Prüfungsmethode in `AppRightsBL`, mit der eine Fachaktion gegen die aufgelöste Rechtsmenge prüft. |
+| HasWebAccountRight | Zweiter Rechtszweig in `AppRightsBL` für Webkonten über die Tabelle `WebAccountsRights`. |
+| AllRightsFromAppUser | Cache-Schlüsselpräfix für die gecachte Rechtsmenge eines `AppUser`. |
+| AllRightsFromWebAccount | Cache-Schlüsselpräfix für die gecachte Rechtsmenge eines `WebAccount`. |
+| AppUser | Internes Benutzerkonto der ERP-Anwendung. |
+| WebAccount | Portal-/Webkonto, das eigene Rechte über `WebAccountsRights` erhält. |
+| Sichmemb | Tabelle der Gruppenmitgliedschaften im internen Rechtebaum. |
+| Sichtrus | Tabelle der Rechte im Gruppen-/Benutzersystem; laut Analyse ohne ausreichende Schlüsseleindeutigkeit. |
+| Sichtrus/Sichmemb-Kette | Interne Rechtsableitung über Benutzer, Gruppenmitgliedschaft und Recht. |
+| WebAccountsRights | Zuordnungstabelle zwischen WebAccount und Webrecht; ohne ausreichende PK-/UNIQUE-/FK-Absicherung analysiert. |
+| WebRights | Referenzdaten für Portalrechte eines Webkontos. |
+| BenutzerInfo2 | Altdatenbanksäule, auf die `AppUser.Password` per NHibernate-Mapping abgebildet wird. |
+| PasswordManagementKeyword | Kennwort- oder Geheimnisfeld in Kontexten wie Passwortspeicher; in Analysen als leere Haltung ohne verbindliche Härtungsregel erkannt. |
+| TwoFactorAuthEnabled | Konfigurationsschalter für Zwei-Faktor-Prüfung im Webservice. |
+| TOTP | Time-based One-Time Password; in der Codebasis über GoogleAuthenticator-artige Logik verwendet. |
+| BLTwoFactorAuthenticationLogic | Client-/BL-Pfad für TOTP-Schlüsselverwaltung und PIN-Prüfung. |
+| WSTwoFactorAuthenticationLogic | Webservice-/REST-Pfad für dieselbe TOTP-Funktionalität. |
+| TicketAuthenticationHandler | Authentifizierungslogik im Webservice-Host, die Tickets aus Query oder Header übernimmt. |
+| AllowAnyOrigin | CORS-Konfiguration in `CentronHost.cs`, die beliebige Absender-Origin zulässt. |
+| X-Forwarded-For | HTTP-Header zur Vermittlung der Client-IP; im Bestand ungeprüft als vertrauenswürdig erkannt. |
+| AESCryptoLogic | AES-Verschlüsselungskomponente mit optionalem Schlüssel und Default-Schlüssel. |
+| SECURITY_KEY | Im Quellcode hinterlegter Standard-Schlüssel von `AESCryptoLogic`. |
+| EncryptWithMasterKey | Mechanismus zur Verschlüsselung gespeicherter Geheimdaten über einen Masterkey. |
+| SHA1Decoder.GetDecodedSHA1String | Erzeugung eines SHA1-Kennworthashs; im WebAccount-Pfad ohne Salt beobachtet. |
+| Fail-closed | Sicherheitsverhalten, bei dem ein Fehler in einer Prüfung ablehnend statt freigebend wirkt. |
+
+## Abrechnung, Zahlungen und Verträge
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| PaymentTransactionBL | Komponente für Zahlungsverkehrsvorgänge. |
+| Zahlungseingang | Zahlungseingangsobjekt bzw. Bankimport-/Zuordnungsvorgang, der Zahlungen Buchungen zuordnet. |
+| PaymentsBL | Business-Logik für Zahlungseingänge, inklusive Rechtsgate und Gegenbuchung beim Löschen. |
+| OnlineBankingAccountTransactionsBL | Bankumsätze und Abschlussprüfung, inklusive Toleranz für Kleinbetragsdifferenzen. |
+| CheckForCompleted | Methode, die einen Vorgang bei Differenzen bis 0,10 als abgeschlossen behandelt. |
+| Opos | Offene Posten; Zugriffs- und Mahnkontext der Finanzkomponente. |
+| Mahnstufe | Eskalationsstufe im Mahnwesen, insbesondere L0 bis L3. |
+| DunningRunBL | Mahlauf-Laufkomponente mit Status- und Rechtlogik. |
+| SEPA | Zahlungsnorm; im Bestand mit Limit- und IBAN-Regeln untersucht. |
+| CurrencyFactor | Währungsfaktor zur Gegenbuchung bei Zahlungseingängen. |
+| ContractBL | Vertragslogik, insbesondere Vertragsende und Abrechnungslogik. |
+| RefreshContractEndeDate | Methode zur Neuberechnung des Vertragsendes inklusive Kündigungs-Kappung. |
+| TimerBilling | Zeitbasierte Abrechnung von Verträgen/Servicezeiten. |
+| DeviceClickCounter | Gerätezähler, insbesondere für Click-/Kontingentabrechnung. |
+| Kostentraeger | Domänentabelle für den Zahler/Kostenträger eines Kontos. |
+| Kostenstelle | Kostenrechnungsobjekt, das in den Anforderungen als historisch bzw. doppelt gepflegt markiert wurde. |
+| Zahler / Payers | UI-Begriff für das Domänenobjekt Kostenträger. |
+
+## Belege, Vertrieb und Leistungserfassung
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| ReceiptPriceHelper | Preisberechnungs-Helfer im Webservice-Kern. |
+| AwayFromZero | Rundungsmodus `MidpointRounding.AwayFromZero` für Netto-/Preisrundung. |
+| TaxRate | USt-Schlüssel je Belegposition; im Preis-Helfer gruppenbildend. |
+| CH-Rundung | Landeswährungsbezogene Rundung auf 0,05 für die Schweiz. |
+| Belegkette | Vorwärtsfolge Angebot, Anfrage, Auftrag, Lieferschein, Rechnung. |
+| Forward-Regel | Regel, die das Anlegen oder Umwandeln von Belegen nur in definierte Nachfolgebelege zulässt. |
+| CustomProperty | Benutzerdefinierte Zusatzfeld-Definition im Objektmodell. |
+| IsMandatory | Pflichtfeld-Markierung einer CustomProperty; Validierung im Bestand primär clientseitig erkannt. |
+| Edit-Time / EDIT_TIME | Zeit-/Leistungserfassungsregel zum Schutz fakturierter Zeiten. |
+| Auftragsabschluss | Statuswechsel eines Auftrags, der vollständige Positionserfassung voraussetzt. |
+| PLM | Product Lifecycle Management; Produktlebenslauf, Produktfamilien und Lebensdauerlogik. |
+| RMA | Return Merchandise Authorization; Retourenprozess mit Helpdeskbezug. |
+| EDI | Electronic Data Interchange; Datenaustausch über Partneradapter. |
+| DATEV | Export-/Schnittstellenkontext zur Buchhaltung. |
+
+## Portal, Webservice und Infrastruktur
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| Nexus | Kundenportal-/Webkomponente der Suite mit ServiceBoard, Webshop und Verwaltung. |
+| WebAccountBL | Business-Logik für Webaccount-Login, Status und Kundenaktivität. |
+| UpdateWebAccountPassword | Pfad zum Passwortwechsel eines Webaccounts im Portal. |
+| ClaimsService | Abbildung von Webrechten in Anspruchs-/Claims-Listen. |
+| CentronHost | Host des Webservers; enthält CORS- und Authentifizierungskonfiguration. |
+| WebServiceConfig.xml | Konfigurationsdatei des Webservice-Hosts mit Sicherheits- und Datenbankzugangsangaben. |
+| Directory.Build.props | Zentrale MSBuild-Konfiguration; enthält im Lauf risikorelevante Serializationseinstellungen. |
+| version.json | Versions-/Release-Datei mit Versions- und Pre-Release-Angaben. |
+| AllowUnsafeBinaryFormatterSerialization | .NET-Konfigurationsschalter, der unsichere BinaryFormatter-Serialisierung erlaubt. |
+| NHibernate | ORM-Schicht für Entitätsmappings und Datenzugriff. |
+| BL | Business Logic; Domänenschicht in `src/backend/Centron.BL`. |
+| DAO | Data Access Object / Datenzugriffsschicht in `src/backend/Centron.DAO`. |
+| Entities | Persistente Entitäten in `src/backend/Centron.Entities`. |
+| Webservice-Vertragsbibliothek | REST-/WCF-Verträge und Clients in `src/webservice/Centron.WebServices.Core`. |
+
+## Datenbank, Synchronisation und Querschnitt
+
+| Begriff | Bedeutung im Bestand |
+|---|---|
+| SSMS_DB_SCHEMA.sql | Vollständiger Datenbank-Schema-Dump des Bestands; zentrale Belegquelle für Tabellen, Constraints und Stored Procedures. |
+| PK | Primary Key; Primärschlüssel einer Tabelle. |
+| FK | Foreign Key; Fremdschlüsselconstraint. |
+| UNIQUE | Eindeutigkeitsconstraint. |
+| CHECK | Prüfung auf Constraint-Ebene, etwa Wertebereich oder Gültigkeit. |
+| NOT NULL | Spalteneigenschaft, die NULL-Werte auf Datenbankebene ausschließt. |
+| CSI_* | Tabellenfamilie mit höherer Constraint-Dichte innerhalb des ansonsten FK-armen Schemas. |
+| EmployeeI3D | Mitarbeiter-/Benutzeridentifikator in Social-Media- und Bearbeitungsregeln. |
+| SocialMediaKind | Codierung, ob ein Social-Media-Element zu einem Stream oder einer Aktion gehört. |
+| spr_SocialMedia* | Stored Procedures für Social-Media-Kommentare und Likes; durchsetzen Eigentumsregeln über das `EmployeeI3D`-Prädikat. |
+| ExternalTools | Datenhaltung und Startmechanismus für extern eingebundene Werkzeuge. |
+| RiverBird | Job-/Scheduler-/Automatisierungsumfeld der Suite. |
+| RiverDive | Monitoring-/Deployments-/IT-Dokumentationsumfeld für Kunden-Infrastruktur. |
+| MSP | Managed-Service-/Mandantenkontext in Lizenz- und Rechtefragen. |
+| Filialgrenze | Beschränkung von Datenzugriff oder Anzeige auf eine Filiale. |
+| SHOW_HELPDESK_ONLY_OWN_BRANCH | Flag/Regel für Helpdesk-Filialbeschränkung; im Bestand primär UI-seitig erkannt. |
+| AppUser.Password | Modellmerkmal des internen Benutzers, das auf die Altsäule `BenutzerInfo2` gemappt wird. |
+| DueTo | Terminwiedervorlage im Helpdesk; Änderungen beeinflussen Eskalationslogik. |

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Hypothesen.md

@@ -0,0 +1,206 @@
+# Hypothesen
+
+Diese Sammlung enthält ausschließlich Anforderungen, die in den drei Ebenendateien inline als `[HYPOTHESE]` gekennzeichnet sind oder deren Status nach der Konsolidierung `HYPOTHESE` lautet. Freie Fragen ohne Anforderungsbezug stehen im `Analysebericht.md`.
+
+## StRS (25)
+
+- **StRS-7** — Berechtigungs- und Plausibilitätsprüfungen müssen serverseitig und lückenlos greifen␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M015, M027, M022, M038, M019, M037, M017, M028 — Zitate wörtlich wie im Fakt; Fundstellen/Einstufungen teils als (HYPOTHESE) gekennzeichnet.
+- **StRS-8** — Modulzugang erfordert Recht und Lizenz zugleich␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll ein Fachmodul nur öffnen, wenn der Benutzer sowohl das Modulrecht besitzt als auch die zugehörige Modul-Lizenz gültig ist; Fehlen einer Bedingung verschließt das Modul vollständig.
+- **StRS-9** — Dienstzugriffe werden fehlgeschlossen authentifiziert; Header-Angaben sind keine Identitätsnachweise␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll jeden Dienstaufruf ohne gültiges Ticket oder Token ablehnen (Versagen führt zur Ablehnung, „fail-closed"); Tickets und Client-Identifikation dürfen nicht allein aus selbstgesetzten Header-/Query-Werten abgeleitet werden, ohne dass deren Herkunft geprüft wird.
+- **StRS-10** — Durchgehende Autorisierung aller REST-Dienste und der Zwei-Faktor-Endpunkte␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll jeden REST-Endpunkt nur nach erfolgreicher Autorisierung beantworten; die Endpunkte des Zwei-Faktor-Verfahrens dürfen nicht ohne Authentifizierung erreichbar sein.
+- **StRS-11** — Verschlüsselung gespeicherter schutzbedürftiger Daten; kein einheitlicher Standard-Schlüssel␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll schutzbedürftige gespeicherte Daten verschlüsseln (AES) und dabei mandantenspezifisch verwaltete Schlüssel verwenden; ein produktionsweiter Standard-/Auslieferungsschlüssel darf nicht die einzige Schlüsselmacht sein.
+- **StRS-12** — Portal-Anmeldung prüft Kontostatus, Kennwort und Kundenaktivität; Portalrechte leiten sich aus Webrechten ab␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll die Portal-Anmeldung nur gewähren, wenn Portal-Kontostatus aktiv, Kennwort korrekt und Stammkunde aktiv ist, und die Portalfunktionen des Angemeldeten ausschließlich aus den zugewiesenen Webrechten als Rollen ableiten; die Kennwortablage ist gegen moderne, robuste Hashverfahren weiterzuentwickeln (SHA1 genügt nicht).
+- **StRS-13** — Zwei-Faktor-Verfahren und Kennworthärte sind aktiv zu betreiben␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll für Portal-/WebAccount-Zugänge das Zwei-Faktor-Verfahren als Auslieferungszustand anbieten und dessen Aktivierung nicht dauerhaft unterdrücken; die TOTP-Gültigkeitstoleranz von ±4 Minuten ist fachlich zu begrenzen; Portal-Kennwörter sollen über eine Mindestlänge von 8 hinaus gehärtet werden; ein administratives Zugangskennwort darf nicht als Klartext im Deployment hinterlegt sein.
+- **StRS-14** — Kennwortwechsel im Portal nur nach Besitzerprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M035 — wörtlich inkl. Kennzeichnung (HYPOTHESE); Fundstelle nicht genannt.
+- **StRS-15** — Dokumentenablage unterscheidet interne und öffentliche Dokumente mit getrennter Rechteprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll den Zugriff auf interne Dokumente nur mit dem internen Dokumentenrecht gewähren und öffentliche Dokumente ohne dieses Recht freigeben; Portalbenutzer (WebAccount) sind nicht von der Rechteprüfung befreit, sondern ausschließlich auf die öffentliche Sphäre zu beschränken.
+- **StRS-16** — Zahlungseingänge nur mit Recht und gegen ausgleichende Gegenbuchung stornierbar␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll das Löschen eines Zahlungseingangs nur berechtigten Buchhaltungsbenutzern gestatten und dabei automatisch eine Gegenbuchung erzeugen, die die Finanzwirksamkeit des ursprünglichen Zugangs vollständig ausgleicht (keine stille Löschung).
+- **StRS-17** — Mahnwesen folgt den Stufen L0–L3; Kassensystem-Mahnrucke setzen Mahnrecht voraus␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M007 — „Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."; Fundstelle nicht genannt.
+- **StRS-18** — Banktransaktionen gelten bei Kleinbetragsdifferenz als ausgeglichen; IBAN deutscher Konten hat Mindestlänge 22␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll eine Banktransaktion als ausgeglichen („completed") abschließen, wenn die Betragsdifferenz zum Buchungsbestand ±0,10 nicht übersteigt; IBANen deutscher Banken (Kürzel DE) sollen mindestens 22 Zeichen tragen, sonst ist die Eingabe zurückzuweisen.
+- **StRS-19** — SEPA-Zahlungen halten das vereinbarte Betragslimit ein␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll einen SEPA-Auftrag nur erstellen und zur Bank weiterleiten, dessen Betrag innerhalb des konfigurierten Betragslimits liegt; darüber hinausgehende Beträge sind zu sperren und dem Sachbearbeiter zu melden.
+- **StRS-20** — Vertragsende aus Laufzeit ableiten und Kündigungsdatum kappen␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll das Vertragsende aus der vereinbarten Laufzeit ableiten und ein erklärtes Kündigungsdatum auf das höchstens zulässige Vertragsende kappen, sodass kein Vertragsverhältnis über sein Ende hinaus fortbesteht.
+- **StRS-21** — Erfassungs- und Abrechnungsschutz für geleistete Zeiten␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll die Erfassung und Änderung von Zeitdaten nur mit dem Recht EDIT_TIME gestatten; einmal fakturierte Zeiten dürfen nachträglich nicht mehr verändert werden, und für rechnungs- bzw. auftragsgesperrte Objekte ist die Zeitänderung zu sperren.
+- **StRS-22** — Belegkette Angebot → Auftrag → Lieferschein → Rechnung folgt Vorwärtsregeln␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll Folgebelege nur entlang der Kette Angebot → Auftrag → Lieferschein → Rechnung erzeugen lassen und dabei die jeweiligen Vorwärtsregeln (zulässige Nachfolgebelege, Mengenübernahme) einhalten.
+- **StRS-23** — Einheitliche Preisbildung: Netto/USt, Mengenpreis, Projektpreis, kundenspezifische Abschläge, Einstandspreis␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll Bruchteile eines Preises konsistent bilden: Nettobetrag und Umsatzsteuer getrennt ausgewiesen; im Mengenpreis die höchste Stufe mit FromAmount ≤ bestellter Menge; Projektpreise als Grundpreis mal vereinbartem Faktor; Kunden-/Partnerprofile (z. B. TelekomDive) mit Rabatt- und USt-Vorgabe je Mandant; der Einstandspreis als gleitender Durchschnitt geführt.
+- **StRS-31** — Helpdesk-Eskalation nach Wartezeit, Wochenendsteuerung und Wiederaufnahme; Hilfezeiten als Termine nutzbar␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE: Die serverseitige Filialbeschränkung und die Eskalationsschwellen sind nur über die Faktenbasis M017 belegt; eine durchsetzende Fundstelle fehlt.]
+- **StRS-34** — Kommunikationsinhalte nur durch Berechtigte und nur im eigenen Namen␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE: Die Mitglieder-/Autorschafts-Regel ist nur über Faktenbasis M020/M039 belegt; eine durchsetzende Stelle für alle Kommunikationspfade ist nicht benannt.]
+- **StRS-36** — Auswertungsobjekte: Reports nur mit Recht löschbar, Klickzahlen nur monoton␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M028 (HYPOTHESE), M010 — wörtlich zitiert; Fundstellen nicht genannt.
+- **StRS-37** — Massenaktualisierung nur bei vollständiger Bearbeitung; Modul ist zu sichern␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll eine Massenaktualisierung nur dann als erledigt abschließen, wenn alle betroffenen Datensätze bearbeitet wurden; das Massenupdate-Modul soll zusätzlich an ein Fachrecht gebunden werden (bisher rechtefrei).
+- **StRS-38** — Externe Schnittstellen halten Partnergrenzen, Berechtigungen und Übertragungsregeln ein␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE] übernehmbar.
+- **StRS-39** — KI-Assistent im ERP nur nach Bestätigung, ohne Bestätigung nur mit Sonderrecht; Anhangsgrenzen 20/40 MB␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll den Aufruf eines KI-Werkzeugs mit Unternehmensdaten nur nach ausdrücklicher Bestätigung des Anwenders ausführen; der Entfall der Bestätigung ist ausschließlich an das Sonderrecht UNRESTRICTED_ACCESS gebunden. Anhänge sind oberhalb der Grenze von 20 MB bzw. 40 MB abzulehnen.
+- **StRS-40** — Persönlicher Arbeitsplatz zeigt nur zugangsberechtigte Module; Autostart ab fünf Modulen wird gewarnt␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Das System soll in der Modulzentrale nur Module darstellen, auf die der Benutzer nach Recht und Lizenz zugreifen kann; bei fünf oder mehr Autostart-Modulen soll vor der Aufnahme gewarnt werden.
+- **StRS-41** — Prozesssteuerung: Workflows mit prozesstypischen Schritten, externe Zeitsteuerung, gültige Anbindung externer Vorgänge␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [SEKUNDÄR] Faktenbasis M041, M036, M070, M006 — Zitate inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
+
+## SyRS (19)
+
+- **SyRS-5** — MSP-Rechte werden nur im Client durchgesetzt␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — ohne Serverdurchsetzung ist jede Nicht-UI-Schnittstelle eine Autorisierungslücke.
+- **SyRS-6** — Pflichtfeld-Validierung (`IsMandatory`) nur im Client␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]**.
+- **SyRS-19** — Vollständigkeit des Datensicherungs-Dumps (TelekomDiveProfile)␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — der Ausschluss ist in der Faktenbasis nur vermutet.
+- **SyRS-21** — Mahnstufen L0–L3 ohne Überlauf und ohne Gebührenbuchung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — Nicht-Vorhandensein von Überlaufschutz und Gebührenbuchung ist nicht an einer durchsetzenden Stelle belegt.
+- **SyRS-24** — Vertragsenddatum-Aktualisierung ohne Rechteprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — die Soll-Forderung nach Rechteprüfung ist abgeleitet; der Ist-Zustand „keine Prüfung“ ist ein Negativbefund.
+- **SyRS-27** — Abschluss-Toleranz ±0,10, Duplikatverhinderungsschlüssel und IBAN-Regel DE␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]**.
+- **SyRS-33** — QM-Regeln ausschließlich im UI durchgesetzt␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — die serverseitige Lücke ist als Negativbefund nicht an einer Stelle belegt.
+- **SyRS-36** — Filialbeschränkung `SHOW_HELPDESK_ONLY_OWN_BRANCH` wirkt nur im UI␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — serverseitige Abwesenheit ist ein Negativbefund.
+- **SyRS-40** — Report-Löschung mit Kaskade ohne Rechteprüfung; ReportEngine ohne Rechtsprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** für die Soll-Forderung; der Ist-Zustand ist über `null` bzw. fehlende Prüfung als Negativbefund belegt.
+- **SyRS-41** — Auftragsabschluss nur bei vollständig erfassten Positionen; Modul ohne Rechtsprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]**.
+- **SyRS-44** — KI-Nutzung erfordert Bestätigung, nicht aber ein Recht; Volumengrenzen 20/40 MB␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]**-Charakter, da eine Soll-Vorgabe fachlich offen ist.
+- **SyRS-46** — Passwortwechsel des Webaccounts ohne Besitzerprüfung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]** — die fehlende Prüfung ist ein Negativbefund ohne zitierte Gegenstelle.
+- **SyRS-51** — Modul- und Funktionsstart nur bei Recht UND Lizenz (Client-Gate)␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+- **SyRS-52** — KI-Assistent: Werkzeugbestätigung, Volumengrenze 20/40 MB, fehlende Rechtebindung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+- **SyRS-53** — Reportdaten-Löschung mit Kaskade ohne Recht; ReportEngine ohne Rechtsmenge␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+- **SyRS-54** — Workflow-Engine: Schritttyp nur per Whitelist je Prozesstyp; Laufstatistik ohne C#-Nutzung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+- **SyRS-55** — Scheduler RiverBird: Schemapflicht ohne C#-Ausführung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+- **SyRS-58** — Ticketauthentifizierung aus Query/Header, vertrauensvolle Client-IP und offener CORS-Umfang␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE: SignalR-Attributschutz, WCF-Whitelist und offene Portprüfung sind nur über Faktenbasis M065 abgedeckt; die zitierten Handler-/Host-Stellen tragen nur Ticket-, IP- und CORS-Anteile.]
+- **SyRS-60** — Mandantentrennung über Verbindung/SessionFactory; Konnektorgateway ohne Mandantensteuerung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE].
+
+## SwRS (20)
+
+- **SwRS-4** — Größen- und Zeichengrenzen der KI-Konversation in der Client-Schicht␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE: Belegtiefe laut Faktenbasis M002, nicht zeilenweise gegengeprüft; serverseitige Zweitprüfung nicht verifiziert.]
+- **SwRS-5** — Terminbereichslogik der Schedule-Komponente␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Schedule-Komponente berechnet Sichtbarkeits- und Zuordnungsergebnisse aus den Termindaten innerhalb eines intern ermittelten Zeitfensters; die Regel ist ausschließlich in `ScheduleBL.cs` Zeilen 2379-2424 implementiert.
+- **SwRS-6** — Persistenzregeln für Zahlungsverkehr und Buchungsimport/-export␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Zahlungsverkehrs-Komponente schreibt Transaktionen über den genannten Codepfad in die eigene Datenhaltung und koppelt Export/Import an die Tabelle `BookKeepingExport`; EDI-Versandparameter werden über `EDIGatewaySettingBL`/`EDIDispatcherBL` gelesen.
+- **SwRS-7** — Werkzeuganbindung über ExternalTools-Datenhaltung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Vorschaukomponente liest Werkzeugdefinitionen aus der Tabelle `ExternalTools` und übergibt Startparameter an den Client; eine eigene Werkzeughaltung außerhalb dieser Tabelle existiert nicht.
+- **SwRS-10** — Pflichtfelder der Kampagnen-Persistenz␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Kampagnenkomponente erzeugt/prüft Kampagnensätze vor der Persistenz anhand der in Zeilen 30-47 hinterlegten Vorgaben; die数据库seitige Pflichtigkeit wird zusätzlich durch NOT-NULL-Constraints der Tabelle `Campaigns` erzwungen.
+- **SwRS-13** — Rücksetzung (Revert) von Sprache und Währung in der Adresskomponente␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Beim Verwerfen oder Ändern von Kontoadressdaten setzt die Komponente Sprache und Währung auf den Ausgangswert (bzw. Kontovorgabe) zurück; die Persistenz erzwingt die Pflichtfelder der Kontotabelle.
+- **SwRS-14** — Pflichtpersistenz beim Produktlebens Zyklus-Ende␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Client-Komponente bereitet die fürs Lebenszyklus-Ende nötigen Felder auf und übergibt sie an die Persistenz, die die Werte NOT NULL erzwingt.
+- **SwRS-18** — Nicht unterstützte MwSt-Übernahme bei Gutschriften␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE]` bezüglich exakter Aufrufkette: Die抛出-Stelle wurde in diesem Lauf nicht aufgesucht.
+- **SwRS-19** — Nullbare Preisspalten im Angebotskopf (Widerspruch zur Faktenbasis)␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Angebotskopf-Preissummen und Status sind softwareintern nullbar und haben weder NOT NULL noch DEFAULT 0; die Angebotskopfsummen können daher ohne Werte persistiert werden.
+- **SwRS-21** — Weiche und harte Löschung von UI-Profilen␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Profilkomponente unterscheidet logische Löschung (Satz bleibt mit Löschkennzeichen erhalten) und physische Löschung; die Schema-Constraints begrenzen die Kombination zulässiger Profildaten.
+- **SwRS-25** — Chat- und Tagesaufgabendatenhaltung␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Chatkomponente verwaltet Unterhaltungen und verknüpfte Tagespositionen über die eigene Datenhaltung; `MyDayWorkItems` liefert die Persistenzstruktur für Tagesaufgabensätze.
+- **SwRS-26** — Persistenzregeln der Online-Banking-Umsätze␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Umsatztzkomponente legt Kontobewegungen über ihre eigene Tabellenstruktur ab, während die Zugangsdaten (HBCI/FinAPI) verschlüsselt in der Konfigurationshaltung liegen.
+- **SwRS-30** — Lizenz-Gate der Produktionsmodule␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Produktionskomponenten prüfen vor der Fachaktion eine Lizenz (Einzellizenz oder Sammel-Lizenz „Centron") und verweigern sonst.
+- **SwRS-31** — Preisimport in Projektpreise über die Import-ViewModel␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Importkomponente überträgt eingelesene Preise in die Projektpreishaltung und wendet dabei eigene Validierungs- und Rundungsregeln an; die Preisbildung folgt nicht dem Pfad `ReceiptPriceHelper.CalculateNetPrice`.
+- **SwRS-33** — QM-Meldungsart als Enum, Anlagen grund dagegen nur UI-seitig␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Art der QM-Meldung wird softwareintern über einen Enum abgebildet und persistiert; der Anlagen grund wird ausschließlich in der Oberfläche geführt und ist nicht Bestandteil der durchgesetzten Datenhaltung.
+- **SwRS-34** — Report-Strukturkaskade ohne fremdschlüsselgesicherte Kindobjekte␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die Reportkomponente hält Eltern-/Kindbeziehungen durch eigenen Code kaskadiert; die Tabellen sichern diese Beziehung weder per FOREIGN KEY noch einheitlich per CHECK-Constraint, im Unterschied zu `ReportPrintOptions`.
+- **SwRS-35** — RMA-Fallbehandlung in der Kundenbereichskomponente␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Die RMA-Komponente führt ihre Vorgangslogik in `RmaBL` und ist über das nullbare Kennzeichen `IstRMAFall` mit Helpdesk-Tickets verbunden.
+- **SwRS-49** — Rechte-Cache ohne gefundenen Invalidierungspfad; Duplikate wandern in den gecachten Rechtsbestand␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE] zur Cache-Lebensdauer (TTL nicht geprüft). Ohne DISTINCT/UNIQUE enthält die Liste bei Doppelzuweisung dieselbe Recht-ID mehrfach.
+- **SwRS-52** — Krypto-Schlüsselverwaltung mit eingebettetem Default-Schlüssel und aus demselben Hash abgeleitetem IV␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: Wo der optionale Schlüssel weggelassen wird, werden Produktionsgeheimnisse mit einem im Quellcode eingebetteten, auslieferungsweit identischen Schlüssel verschlüsselt; Schlüssel und statische IV teilen Bytes, gleiche Klartexte ergeben identische Chiffretexte; Masterkey-Ablage verschlüsselt sich mit demselben Default; kein Rotationsmechanismus.
+- **SwRS-54** — Anhängegrenzen der KI-Konversation als hartcodierte Konstanten (20 MB / 40 MB / 20000 Zeichen)␍
+  - Status: HYPOTHESE
+  - Offene Frage / Grund: [HYPOTHESE] Serverseite).
+
+**Konsistenzvermerk:** Die Liste wurde aus dem zusammengeführten Bestand nach `Status: HYPOTHESE` und Inline-Markierung `[HYPOTHESE]` erzeugt.

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/StRS.md

@@ -0,0 +1,698 @@
+ID: StRS-1
+Titel: Rechteermittlung ausschließlich über Gruppenmitgliedschaft
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Benutzer (via Sachverwalter/Administrator), c-entron-ERP-System
+Vorbedingung: Benutzer meldet sich an und ruft eine rechtegeschützte Funktion auf.
+Fakt: „M001 Rechte NUR über Gruppen: AppRightsBL.HasUserRight Raw-SQL 'FROM dbo.Sichtrus INNER JOIN dbo.Sichmemb ON sm.Gruppe=st.Gruppe WHERE sm.Benutzer=:UserI3D'. [PRIMÄR] backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644-664." (Sichtrus = Rechtestammdaten, Sichmemb = Gruppenmitgliedschaft Benutzer↔Gruppe)
+Aussage: Das System soll einem Benutzer Fachrechte ausschließlich über die Gruppen zuordnen, denen er angehört; eine direkte Einzelrechtevergabe an Benutzer darf es fachlich nicht geben.
+Ergebnis: Rechte sind über Gruppen administrative Einheit und Nachweisgröße; jede Rechtefrage ist auf eine Gruppenzuordnung rückführbar.
+Belege: [PRIMÄR] backend\Centron.BL\Administration\Rights\AppRightsBL.cs:644-664 — „AppRightsBL.HasUserRight Raw-SQL 'FROM dbo.Sichtrus INNER JOIN dbo.Sichmemb ON sm.Gruppe=st.Gruppe WHERE sm.Benutzer=:UserI3D'" (M001), Einstufung wörtlich übernommen.
+Prüfidee: Benutzer U erhält Recht R direkt ohne Gruppenmitgliedschaft → Rechteprüfung muss R verweigern; U wird Gruppe G mit R zugeordnet → Prüfung muss R gewähren.
+Tracelinks: SyRS:Rechteprüfung, SwRS:Gruppen-Rechtemodell, StRS-4
+Konsolidierung: Rechtegrundmodell gilt modulübergreifend für alle rechteabhängigen Aktionen (siehe StRS-4).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - PRIMÄR-Beleg mit SQL, Kernstück des Berechtigungskonzepts.
+Status: belegt
+
+ID: StRS-2
+Titel: Lösch- und Änderungsschutz systemkritischer Objekte und der Rechteverwaltung
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Administrator, c-entron-ERP-System
+Vorbedingung: Ein Benutzer versucht, die Gruppeverwaltung zu ändern, die Administratorengruppe zu löschen oder als „fix" gekennzeichnete Stammdaten (z. B. Kategorien) zu löschen.
+Fakt: „M001 Gruppenverwaltung rechtepflichtig, Admin-Gruppe löschgeschützt, Admin-Rechte Whitelist. AppRightsBL.cs:355-396,714-759." und „M036 IsFix-Kategorien löschgeschützt".
+Aussage: Das System soll den Zugriff auf die Gruppenverwaltung an ein besonderes Recht binden, die Administratorengruppe gegen Löschen schützen und nur eine whitelistbasierte Änderung von Admin-Rechten zulassen; als fix gekennzeichnete Kategorien (IsFix) sind gegen Löschen zu schützen.
+Ergebnis: Selbstaussperrung und Rechteaushebelung über Löschen von Gruppen oder Festdaten sind fachlich ausgeschlossen.
+Belege: [PRIMÄR] AppRightsBL.cs:355-396,714-759 — „M001 Gruppenverwaltung rechtepflichtig, Admin-Gruppe löschgeschützt, Admin-Rechte Whitelist" (Quelle nennt konkrete Code-Fundstelle, direkte Beobachtung; keine Hochstufung eines fremden Tags). [SEKUNDÄR] Faktenbasis M036 — „M036 IsFix-Kategorien löschgeschützt; RiverTicket ohne URL ungültig" (Fundstelle in Faktenbasis nicht genannt).
+Prüfidee: Löschversuch auf Admin-Gruppe durch nicht-administrativen UND administrativen Benutzer → beide müssen abgewiesen werden; Löschversuch auf IsFix-Kategorie → Abweisung; Änderung eines Nicht-Whitelist-Admin-Rechts → Abweisung.
+Tracelinks: SyRS:Rechteprüfung, SwRS:AdminSchutz, SwRS:IsFixLoeschschutz, StRS-1
+Konsolidierung: Schutztyp „Löschschutz für Systemobjekte" über M001 und M036 zusammengefasst.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitskritisch, Code-Fundstelle vorhanden.
+Status: belegt
+
+ID: StRS-3
+Titel: Login nur innerhalb der lizenzierten Benutzerkapazität
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: Benutzer, Lizenzverwaltung, c-entron-ERP-System
+Vorbedingung: Lizenzmaximum der Installation ist bekannt; alle Lizenzzähler sind konsistent geführt.
+Fakt: „M001 Login-Lizenzgrenze currentlyUsedLicenses>=max -> Fehler. LicenseManager.cs:258-302."
+Aussage: Das System soll einen Anmeldeversuch ablehnen, wenn die Zahl der bereits genutzten Lizenzen das lizenzierte Maximum erreicht oder überschreitet, und dem Benutzer einenverständlichen Hinweis geben.
+Ergebnis: Es arbeiten nie mehr simultane Benutzer im System, als lizenziert sind; Lizenzverstöße werden vermieden.
+Belege: [PRIMÄR] LicenseManager.cs:258-302 — „M001 Login-Lizenzgrenze currentlyUsedLicenses>=max -> Fehler" (konkrete Code-Fundstelle, direkte Beobachtung).
+Prüfidee: max=n, n Lizenzen belegt → (n+1)-ter Login muss mit Fehler abgewiesen werden; eine Lizenz wird frei → Login muss gelingen.
+Tracelinks: SyRS:Loginablauf, SwRS:Lizenzgrenze, StRS-8
+Konsolidierung: Lizenzthematik wird mit M024 (Produktion) und M005 (DATEV) in StRS-8 fortgeführt.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - abrechnungs-/lizenzrelevant mit PRIMÄR-Beleg.
+Status: belegt
+
+ID: StRS-4
+Titel: Bearbeitung und Ausführung geschäftskritischer Aktionen sind rechtepflichtig
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Sachbearbeiter (Stamm-, Artikel-, Finanz-, Kommissionier-, Statistik-, Mail-Verwaltung), c-entron-ERP-System
+Vorbedingung: Benutzer ist authentisiert; eine rechtegeschützte Aktion wird angestoßen.
+Fakt: „M015 MSP-Bearbeitung braucht Rechte (nur Client)"; „M016 GUI-Profile global braucht EDIT_GLOBAL_PROFILES"; „M011 Account-Aktionen rechtepflichtig" (AccountBL.cs:1290-1370); „M007 Zahlungseingang löschen rechtepflichtig + Gegenbuchlung"; „M034 … Kommission rechtepflichtig"; „M038 Mailscanner Profil-Laden rechtepflichtig"; „M031 Statistikarten rechteabhängig".
+Aussage: Das System soll die Bearbeitung von Masterdaten (MSP), globalen GUI-Profilen, Konten (Accounts), das Löschen von Zahlungseingängen, Kommissioniervorgänge, das Laden von Mailscanner-Profilen und die Nutzung von Statistikarten nur Benutzern mit dem jeweils zuständigen Fachrecht gestatten.
+Ergebnis: Geschäftsvorfälle und sensitive Funktionen sind personenbezogen abgeschirmt; unberechtigte Änderung ist fachlich unmöglich.
+Belege: [PRIMÄR] AccountBL.cs:1290-1370 — „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen" (Code-Fundstelle). [SEKUNDÄR] Faktenbasis M015, M016, M007, M034, M038, M031 — Zitate wie im Fakt zitiert; Fundstellen dort nicht angegeben.
+Prüfidee: Benutzer ohne EDIT_GLOBAL_PROFILES öffnet globales GUI-Profil → Lese-/Schreibzugriff muss verweigert werden; analog Benutzer ohne Kommissionsrecht → Kommissionieraktion wird abgewiesen; Benutzer ohne Kontorecht → Kontoaktion abgewiesen.
+Tracelinks: SyRS:Rechteprüfung, SwRS:RechtepruefungServer, StRS-1, StRS-7
+Konsolidierung: Einzelfakten M015, M016, M011, M007, M034, M038, M031 zu einer Rechtenachweis-Anforderung zusammengefasst; Durchsetzungsdefizite separiert in StRS-7.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Kern-Berechtigungsregel, breit belegt (ein PRIMÄR, sechs SEKUNDÄR).
+Status: belegt
+
+ID: StRS-5
+Titel: Unberechtigte Änderungen von Sprache und Währung dürfen nicht wirkungslos überschrieben werden
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Account-Bearbeiter, c-entron-ERP-System
+Vorbedingung: Benutzer ohne Sonderrecht für Sprache/Währung versucht, diese Felder eines Accounts zu ändern.
+Fakt: „M011 Sprache/Währung ohne Sonderrecht lautlos revertiert. AccountAddressBL.cs:282-332."
+Aussage: Das System soll Änderungen an Sprache und Währung eines Accounts ohne das Sonderrecht nicht akzeptieren; die Änderung ist sichtbar abzulehnen, statt den Wert lautlos auf den Ausgangswert zurückzusetzen.
+Ergebnis: Der Bearbeiter erkennt die fehlende Berechtigung; es entstehen keine stillen Datenabweichungen.
+Belege: [PRIMÄR] AccountAddressBL.cs:282-332 — „M011 Sprache/Währung ohne Sonderrecht lautlos revertiert" (Code-Fundstelle, direkte Beobachtung; Soll-Ziel = Korrektur des beobachteten Ist-Verhaltens).
+Prüfidee: Benutzer ohne Sonderrecht setzt Sprache „DE" auf „EN" und speichert → System meldet Verweigerung UND gespeicherter Wert bleibt „DE".
+Tracelinks: SyRS:Rechteprüfung, SwRS:FeldrechteAccount, StRS-4
+Konsolidierung: Feldrechteregel steht isoliert; Verallgemeinerung in StRS-7.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel aus Ist-Verhalten abgeleitet, Soll-Formulierung (sichtbare Meldung) ist Interpretation des Befunds.
+Status: belegt
+
+ID: StRS-6
+Titel: Webkonten sind von internen Kontooperationen ausgeschlossen
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: externer Kunde mit Webkonto, c-entron-ERP-System
+Vorbedingung: Ein Webkonto versucht, interne Account-Aktionen (z. B. Anlage/Änderung) auszuführen.
+Fakt: „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen. AccountBL.cs:1290-1370."
+Aussage: Das System soll Kontoaktionen über ein Webkonto grundsätzlich abweisen; interne Kontopflege bleibt internen, berechtigten Benutzern vorbehalten.
+Ergebnis: Externe Portalnutzer können keine internen Geschäftskonten ändern; Trennung innen/außen ist durchgesetzt.
+Belege: [PRIMÄR] AccountBL.cs:1290-1370 — „M011 Account-Aktionen rechtepflichtig, Webaccount abgewiesen" (Code-Fundstelle).
+Prüfidee: Authentifiziertes Webkonto ruft Kontoaktion (z. B. Anlage/Änderung) auf → Aufruf muss mit Abweisung enden; interner Benutzer mit Recht → Erfolg.
+Tracelinks: SyRS:Portalabgrenzung, SwRS:WebaccountSperre, StRS-12
+Konsolidierung: Portalthemen werden fortgesetzt in StRS-12 bis StRS-15.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - klare PRIMÄR-belegte Abwehrregel.
+Status: belegt
+
+ID: StRS-7
+Titel: Berechtigungs- und Plausibilitätsprüfungen müssen serverseitig und lückenlos greifen
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Angreiferischer Client, beliebiger Fachbenutzer, c-entron-ERP-System
+Vorbedingung: Ein Client umgeht die Oberfläche oder ruft Funktionen ohne die maschinellen Prüfungen auf.
+Fakt: „M015 MSP-Bearbeitung braucht Rechte (nur Client). Custom-Properties brauchen Name/Datentyp, Pflichtfelder nur Client."; „M027 QM-Beleggrund (nur UI)."; „M037 Telefonie Rechte nur Client(HYPOTHESE)."; „M022 Passwortmanager Rechte nur Client(HYPOTHESE)"; „M017 … Filialbeschränkung nur UI(HYPOTHESE)."; „M038 … Löschen ohne Recht."; „M019 Massenupdate … Modul rechtefrei."; „M028 Report-Löschung Kaskade ohne Recht(HYPOTHESE)."
+Aussage: Das System soll jede Rechte- und Pflichtfeldprüfung, die eine Geschäftsregel durchsetzt, unabhängig vom Client auch auf dem Dienst/Geschäftslogik prüfen; kein Lösch-, Bearbeitungs- oder Modulzugriff darf ohne Rechtsprüfung ausführbar sein.
+Ergebnis: UI-Kontrollen sind Bedienungshilfe, nicht Sicherheitsgrenze; Rechteumgehung über alternative Zugangswege ist ausgeschlossen.
+Belege: [SEKUNDÄR] Faktenbasis M015, M027, M022, M038, M019, M037, M017, M028 — Zitate wörtlich wie im Fakt; Fundstellen/Einstufungen teils als (HYPOTHESE) gekennzeichnet.
+Prüfidee: Client ohne die UI-Rufe Dienst zur Report-/Mailscanner-Profil-Löschung ohne Recht auf → Dienst muss verweigern; Custom-Property ohne Datentyp per direktem Aufruf → Ablehnung; Telefoniefunktion ohne Recht über Nicht-UI-Weg → Ablehnung.
+Tracelinks: SyRS:Rechteprüfung, SwRS:ServerseitigeRechtepruefung, StRS-4, StRS-36
+Konsolidierung: Befundfamilie „nur-Client/nur-UI/ohne-Recht" aus acht Modulfakten in einer Absicherungsanforderung gebündelt.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - für die Zielrichtung, Detail je Modul nachzureichen — daher risikorelevant ohne PRIMÄR.
+Status: HYPOTHESE
+
+ID: StRS-8
+Titel: Modulzugang erfordert Recht und Lizenz zugleich
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Benutzer, Lizenzverwaltung, c-entron-ERP-System
+Vorbedingung: Modul (z. B. Produktion, DATEV-Export) ist installiert; Modulrechte sind pflegt.
+Fakt: „M051 Modulzugang=Recht UND Lizenz."; „M024 Produktion lizenzpflichtig."; „M005 … DATEV-Lizenz …".
+Aussage: Das System soll ein Fachmodul nur öffnen, wenn der Benutzer sowohl das Modulrecht besitzt als auch die zugehörige Modul-Lizenz gültig ist; Fehlen einer Bedingung verschließt das Modul vollständig.
+Ergebnis: Lizenz- und Rechteverwaltung wirken gemeinsam; nicht lizenzierte Module sind auch für berechtigte Benutzer nicht nutzbar.
+Belege: [SEKUNDÄR] Faktenbasis M051, M024, M005 — „M051 Modulzugang=Recht UND Lizenz.", „M024 Produktion lizenzpflichtig.", „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter."; Fundstellen nicht genannt.
+Prüfidee: Recht ja, Lizenz nein → Modulzugriff verweigert; Lizenz ja, Recht nein → verweigert; beides ja → Zugriff gewährt.
+Tracelinks: SyRS:Modulzugang, SwRS:Lizenzpruefung, SwRS:Modulrecht, StRS-1, StRS-3
+Konsolidierung: Lizenzkopplung der Module Produktion (M024) und DATEV (M005) unter Regel M051 gefasst.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich, Beleglage dünn — Beleg nachreichen.
+Status: HYPOTHESE
+
+ID: StRS-9
+Titel: Dienstzugriffe werden fehlgeschlossen authentifiziert; Header-Angaben sind keine Identitätsnachweise
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Dienstaufrufer (Ticket/Token), c-entron-ERP-System
+Vorbedingung: Externer oder interner Aufrufer请求t eine Dienstfunktion ohne vollständige Legitimation.
+Fakt: „M053 fail-closed Rechte, Ticket/Token-Auth."; „M065 Ticket aus Header/Query, IP aus Header."
+Aussage: Das System soll jeden Dienstaufruf ohne gültiges Ticket oder Token ablehnen (Versagen führt zur Ablehnung, „fail-closed"); Tickets und Client-Identifikation dürfen nicht allein aus selbstgesetzten Header-/Query-Werten abgeleitet werden, ohne dass deren Herkunft geprüft wird.
+Ergebnis: Kein Zugriff durch bloßes Behaupten von Zugangsdaten in übermittelbaren Feldern; fehlende Prüfung bedeutet keinen Zugriff.
+Belege: [SEKUNDÄR] Faktenbasis M053, M065 — wörtlich zitiert; Fundstellen nicht angegeben.
+Prüfidee: Aufruf ohne Ticket → Ablehnung; Aufruf mit manipuliertem Header „IP der internen Liste" ohne gültiges Ticket → Ablehnung; gültiges Ticket → Erfolg.
+Tracelinks: SyRS:Dienstauthentifizierung, SwRS:FailClosedRechte, SwRS:TicketAuth, StRS-10
+Konsolidierung: M053 und M065 zu einer Authentifizierungsregel verbunden.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsgrundsatz; konkrete Nachweise fehlen noch.
+Status: HYPOTHESE
+
+ID: StRS-10
+Titel: Durchgehende Autorisierung aller REST-Dienste und der Zwei-Faktor-Endpunkte
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: REST-Client, Zwei-Faktor-Endpunkt-Nutzer, c-entron-ERP-System
+Vorbedingung: Aufruf eines REST-Endpunkts, auch des Zwei-Faktor-Registrierungs-/Prüfabschnitts.
+Fakt: „M064 REST global RequireAuthorization, 2FA anonym."
+Aussage: Das System soll jeden REST-Endpunkt nur nach erfolgreicher Autorisierung beantworten; die Endpunkte des Zwei-Faktor-Verfahrens dürfen nicht ohne Authentifizierung erreichbar sein.
+Ergebnis: Keine anonymous Datenabfrage über die Schnittstelle; das Zweite-Faktor-Verfahren ist selbst geschützt.
+Belege: [SEKUNDÄR] Faktenbasis M064 — „M064 REST global RequireAuthorization, 2FA anonym."; Fundstelle nicht genannt.
+Prüfidee: Unautorisierter HTTP-Aufruf eines Fach-Endpunkts und eines 2FA-Endpunkts (Token als Query-Parameter) → beide müssen ablehnen.
+Tracelinks: SyRS:Autorisierungspflicht, SwRS:GlobalRequireAuthorization, StRS-13
+Konsolidierung: REST- und 2FA-Endpunktschutz gemeinsam gefasst.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Befund „2FA anonym" ist sicherheitsrelevant.
+Status: HYPOTHESE
+
+ID: StRS-11
+Titel: Verschlüsselung gespeicherter schutzbedürftiger Daten; kein einheitlicher Standard-Schlüssel
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vertraulichkeit
+Akteur: Datenschutzverantwortlicher, c-entron-ERP-System
+Vorbedingung: Passwortmanager- und Zugangsdaten werden dauerhaft gespeichert.
+Fakt: „M057 Krypto AES Default-Key."
+Aussage: Das System soll schutzbedürftige gespeicherte Daten verschlüsseln (AES) und dabei mandantenspezifisch verwaltete Schlüssel verwenden; ein produktionsweiter Standard-/Auslieferungsschlüssel darf nicht die einzige Schlüsselmacht sein.
+Ergebnis: Datenabfluss aus Speichern bleibt ohne mandanteneigenen Schlüssel unlesbar.
+Belege: [SEKUNDÄR] Faktenbasis M057 — „M057 Krypto AES Default-Key."; Fundstelle nicht genannt.
+Prüfidee: Prüfung der Schlüsselkonfiguration auf installationsindividuelle Schlüssel; Entschlüsselungsversuch gespeicherter Geheimnisse mit Werks-Default muss im Produktivbetrieb ausscheiden.
+Tracelinks: SyRS:Datengeheimhaltung, SwRS:AESSchluesselverwaltung, StRS-24
+Konsolidierung: Krypto-Befund dem Portal-/Passwortkomplex (StRS-12/13) zugeordnet.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Richtung klar, Soll-Verschärfung „kein Default-Key" ist aus Befund abgeleitet.
+Status: HYPOTHESE
+
+ID: StRS-12
+Titel: Portal-Anmeldung prüft Kontostatus, Kennwort und Kundenaktivität; Portalrechte leiten sich aus Webrechten ab
+Ebene: StRS
+Typ: Akteursziel
+Qualitätsmerkmal: Sicherheit
+Akteur: Kunde (Portalbenutzer), c-entron-ERP-Portal
+Vorbedingung: Kunde meldet sich mit Kennung und Kennwort am Kundenportal an.
+Fakt: „M035 Portal-Login Prüft Status/Passwort(klartext-hash SHA1)/Kunde aktiv."; „WebRechte->Rollen."
+Aussage: Das System soll die Portal-Anmeldung nur gewähren, wenn Portal-Kontostatus aktiv, Kennwort korrekt und Stammkunde aktiv ist, und die Portalfunktionen des Angemeldeten ausschließlich aus den zugewiesenen Webrechten als Rollen ableiten; die Kennwortablage ist gegen moderne, robuste Hashverfahren weiterzuentwickeln (SHA1 genügt nicht).
+Ergebnis: Nur gültige Kunden mit gültigem Zugang erhalten rollengerechte Portsicht; veraltete Kennwort-Hashung ist absehbar beseitigt.
+Belege: [SEKUNDÄR] Faktenbasis M035 — wörtlich wie im Fakt zitiert; Fundstelle nicht genannt.
+Prüfidee: Kunde deaktiviert bei korrektem Kennwort → Login abgelehnt; Portal-Konto gesperrt → abgelehnt; aktiver Kunde → Erfolg; Webrecht W entfernt → zugehörige Portalfunktion nicht mehr erreichbar.
+Tracelinks: SyRS:Portalzugang, SwRS:PortalLogin, SwRS:WebRollen, StRS-6, StRS-13
+Konsolidierung: M035-Login, Kennwort-Hashbefund und Webrechte→Rollen in einer Portalzugangs-Anforderung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich; SHA1-Korrekturbedarf aus Befund abgeleitet.
+Status: HYPOTHESE
+
+ID: StRS-13
+Titel: Zwei-Faktor-Verfahren und Kennworthärte sind aktiv zu betreiben
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Portalbenutzer, WebAccount-Inhaber, Betrieb/Deployment, c-entron-ERP-System
+Vorbedingung: Zwei-Faktor-Anmeldung ist installiert; Portal- oder WebAccount-Kennwörter werden gesetzt.
+Fakt: „M035 2FA WebAccount Default aus."; „M061 TOTP ±4min."; „M022 … Portal-Kennwort nur min8."; „Deployment 2FA default aus, SA-Klartext." (TOTP = zeitbasiertes Einmalkennwort; SA = Systemadministrator-Konto)
+Aussage: Das System soll für Portal-/WebAccount-Zugänge das Zwei-Faktor-Verfahren als Auslieferungszustand anbieten und dessen Aktivierung nicht dauerhaft unterdrücken; die TOTP-Gültigkeitstoleranz von ±4 Minuten ist fachlich zu begrenzen; Portal-Kennwörter sollen über eine Mindestlänge von 8 hinaus gehärtet werden; ein administratives Zugangskennwort darf nicht als Klartext im Deployment hinterlegt sein.
+Ergebnis: Standardinstallation ist nicht per Voreinstellung ohne zweiten Faktor; keine Klartext-Passwörter in Konfiguration.
+Belege: [SEKUNDÄR] Faktenbasis M035, M061, M022, Deployment-Absatz — Zitate wörtlich; Fundstellen nicht genannt.
+Prüfidee: Frisch deployte Umgebung prüfen: 2FA aktivierbar, kein Klartext-SA-Kennwort in Konfiguration; TOTP-Token mit Zeitversatz >4 min → Ablehnung; Kennwort „12345678" gegen Härtungsregel prüfen.
+Tracelinks: SyRS:Identitaetsstaerkung, SwRS:TOTPFenster, SwRS:Kennworthaertung, StRS-10, StRS-12
+Konsolidierung: 2FA-Defaults (M035, Deployment), TOTP (M061), Kennworthärte (M022), SA-Klartext in einer Regel.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Soll-Verschärfungen (Härte, TOTP-Fenster) aus Befunden abgeleitet.
+Status: HYPOTHESE
+
+ID: StRS-14
+Titel: Kennwortwechsel im Portal nur nach Besitzerprüfung
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Portalbenutzer, Angreifer, c-entron-ERP-Portal
+Vorbedingung: Es liegt eine Anweisung zum Kennwortwechsel für ein Portal-Konto vor.
+Fakt: „M035 Passwortwechsel ohne Besitzerprüfung(HYPOTHESE)."
+Aussage: Das System soll den Wechsel eines Portal-Kennworts nur durchführen, wenn die Identität des Berechtigten (Besitzer oder verifizierter Bevollmächtigter) geprüft wurde; ein Kennworttausch allein mit Kenntnis der Kontokennung ist abzulehnen.
+Ergebnis: Kontoübernahme durch Kennwortsetzen auf fremde Konten ist fachlich ausgeschlossen.
+Belege: [SEKUNDÄR] Faktenbasis M035 — wörtlich inkl. Kennzeichnung (HYPOTHESE); Fundstelle nicht genannt.
+Prüfidee: Unangemeldeter Aufruf „Kennwort für fremdes Portal-Konto setzen" → Abweisung; Besitzer nach durchlaufener Verifizierung → Erfolg.
+Tracelinks: SyRS:Kennwortverwaltung, SwRS:Besitzerprüfung, StRS-12
+Konsolidierung: Aus dem M035-Portalkomplex herausgelöst, weil eigenständige Prüfgröße.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - klarer Sicherheitszielzustand; Ist-Befund selbst hypothetisch.
+Status: HYPOTHESE
+
+ID: StRS-15
+Titel: Dokumentenablage unterscheidet interne und öffentliche Dokumente mit getrennter Rechteprüfung
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vertraulichkeit
+Akteur: interner Benutzer, Portalbenutzer (WebAccount), c-entron-DMS
+Vorbedingung: Dokument ist als intern oder öffentlich abgelegt; Nutzer will es öffnen.
+Fakt: „M040 DMS intern/öffentlich Rechte-Trennung, Webaccount von Prüfung befreit." (DMS = Dokumentenmanagementsystem)
+Aussage: Das System soll den Zugriff auf interne Dokumente nur mit dem internen Dokumentenrecht gewähren und öffentliche Dokumente ohne dieses Recht freigeben; Portalbenutzer (WebAccount) sind nicht von der Rechteprüfung befreit, sondern ausschließlich auf die öffentliche Sphäre zu beschränken.
+Ergebnis: Keine interne Ablage für unberechtigte, auch nicht portalauthentifizierte, Nutzer sichtbar.
+Belege: [SEKUNDÄR] Faktenbasis M040 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Portalbenutzer ruft internes Dokument auf → Ablehnung; Benutzer ohne DMS-Recht → Ablehnung; öffentliches Dokument → Einsicht für beide.
+Tracelinks: SyRS:Dokumentenschutz, SwRS:DmsRechtepruefung, StRS-6, StRS-9
+Konsolidierung: Trennung intern/öffentlich und Portalbefreiung in einer Anforderung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Befund „von Prüfung befreit" ist ein akuter Schutzverstoß.
+Status: HYPOTHESE
+
+ID: StRS-16
+Titel: Zahlungseingänge nur mit Recht und gegen ausgleichende Gegenbuchung stornierbar
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Debitorenbuchhaltung, Wirtschaftsprüfer, c-entron-ERP-System
+Vorbedingung: Ein bereits gebuchter Zahlungseingang soll gelöscht werden.
+Fakt: „M007 Zahlungseingang löschen rechtepflichtig + Gegenbuchlung."
+Aussage: Das System soll das Löschen eines Zahlungseingangs nur berechtigten Buchhaltungsbenutzern gestatten und dabei automatisch eine Gegenbuchung erzeugen, die die Finanzwirksamkeit des ursprünglichen Zugangs vollständig ausgleicht (keine stille Löschung).
+Ergebnis: Zahlungsmittelverkehr bleibt vollständig und nachvollziehbar; unberechtigte Korrektur ist ausgeschlossen.
+Belege: [SEKUNDÄR] Faktenbasis M007 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Benutzer ohne Recht löscht Zahlungseingang → abgelehnt; Berechtigter löscht → Gegenbuchung mit Betragsgleichheit existiert und Saldo bleibt unverändert.
+Tracelinks: SyRS:Zahlungsverkehr, SwRS:Gegenbuchung, SwRS:LoeschrechtZahlung, StRS-4, StRS-17
+Konsolidierung: Finanzkorrekturregeln zusammen mit StRS-17 (Mahnwesen).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungs-/Prüfungsthema; Beleg muss nachgereicht werden.
+Status: HYPOTHESE
+
+ID: StRS-17
+Titel: Mahnwesen folgt den Stufen L0–L3; Kassensystem-Mahnrucke setzen Mahnrecht voraus
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Mahnwesen-Sachbearbeiter, Kassensystem (OPOS), c-entron-ERP-System
+Vorbedingung: Offener Posten (Opos) überschreitet seine Fälligkeit. (OPOS = Kassensystem/Point of Sale)
+Fakt: „M007 Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."
+Aussage: Das System soll überfällige Posten über die Stufen L0 bis L3 des Mahnprozesses führen und dem Zahler je Stufe die vorgesehenen Mahnschritte zuweisen; das Anstoßen von Mahnungen aus dem Kassensystem (Opos) soll nur mit Mahnrecht möglich sein. Die Gebührenhöhe je Stufe ist fachlich zu bestimmen (bisher unbelegt).
+Ergebnis: Einheitliche, nachvollziehbare Debitorenmahnung; unberechtigte Mahnauslösung aus dem Kassensystem verhindert.
+Belege: [SEKUNDÄR] Faktenbasis M007 — „Mahnwesen Stufen L0-L3 (Gebühren nicht belegt=HYPOTHESE). Opos braucht Mahnrecht."; Fundstelle nicht genannt.
+Prüfidee: Überfälliger Posten durchläuft Stufen L0→L3 (je Fälligkeitstag-Fenster eine Stufe); Kassennutzer ohne Mahnrecht → Mahnauslösung abgelehnt.
+Tracelinks: SyRS:Mahnprozess, SwRS:Mahnstufen, SwRS:MahnrechtOpos, StRS-16
+Konsolidierung: Mahnwesenregel separat von Zahlungslöschung (StRS-16), beide Finanzbereich.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Gebühren fehlen, Stufenmodell unklar definiert.
+Status: HYPOTHESE
+
+ID: StRS-18
+Titel: Banktransaktionen gelten bei Kleinbetragsdifferenz als ausgeglichen; IBAN deutscher Konten hat Mindestlänge 22
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Zahllauf-Sachbearbeiter, c-entron-ERP-System
+Vorbedingung: Banktransaktion wird importiert/abgeglichen; Eingabe einer IBAN.
+Fakt: „M021 Banktransaktion completed bei ±0,10; IBAN DE>=22."
+Aussage: Das System soll eine Banktransaktion als ausgeglichen („completed") abschließen, wenn die Betragsdifferenz zum Buchungsbestand ±0,10 nicht übersteigt; IBANen deutscher Banken (Kürzel DE) sollen mindestens 22 Zeichen tragen, sonst ist die Eingabe zurückzuweisen.
+Ergebnis: Bagatellrundungen blockieren den Zahlungsabschluss nicht; fehlerhafte IBANen werden vor der Buchung abgefangen.
+Belege: [SEKUNDÄR] Faktenbasis M021 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Differenz 0,10 → Status completed; 0,11 → nicht completed; IBAN „DE" mit 21 Zeichen → Ablehnung, mit 22 → Annahme.
+Tracelinks: SyRS:Zahlungsabgleich, SwRS:Bankausgleich, SwRS:IbanPruefung, StRS-19
+Konsolidierung: Zahlungseingangsregeln zusammen mit StRS-19.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise prüfbare Grenzwerte; Beleg nachreichen.
+Status: HYPOTHESE
+
+ID: StRS-19
+Titel: SEPA-Zahlungen halten das vereinbarte Betragslimit ein
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Zahlstellen-Sachbearbeiter, Bank, c-entron-ERP-System
+Vorbedingung: Ein SEPA-Überweisungsauftrag wird erzeugt. (SEPA = einheitlicher Euro-Zahlungsverkehrsraum)
+Fakt: „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter."
+Aussage: Das System soll einen SEPA-Auftrag nur erstellen und zur Bank weiterleiten, dessen Betrag innerhalb des konfigurierten Betragslimits liegt; darüber hinausgehende Beträge sind zu sperren und dem Sachbearbeiter zu melden.
+Ergebnis: Falschbeträge und Betrugsausreißer verlassen das Haus nicht ungeprüft.
+Belege: [SEKUNDÄR] Faktenbasis M005 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: SEPA-Auftrag mit Betrag = Limit → zulässig; Limit + 0,01 → Ablehnung mit Meldung.
+Tracelinks: SyRS:Zahlungsverkehr, SwRS:SepaLimit, StRS-18
+Konsolidierung: SEPA-Limit aus M005 gelöst; DATEV→StRS-8, OPOS-Pflichtspalten→StRS-24, EDI→StRS-38.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungsrisiko; Konkreter Limitwert und Beleg fehlen.
+Status: HYPOTHESE
+
+ID: StRS-20
+Titel: Vertragsende aus Laufzeit ableiten und Kündigungsdatum kappen
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Vertrags-Sachbearbeiter, c-entron-ERP-System
+Vorbedingung: Vertrag mit Laufzeit und Kündigungsdatum ist erfasst.
+Fakt: „M010 Vertragsende-Ableitung+Kündigungsdatum-Kappung."
+Aussage: Das System soll das Vertragsende aus der vereinbarten Laufzeit ableiten und ein erklärtes Kündigungsdatum auf das höchstens zulässige Vertragsende kappen, sodass kein Vertragsverhältnis über sein Ende hinaus fortbesteht.
+Ergebnis: Vertragslaufzeiten stimmen mit Abrechnungszeiträumen überein; keine abrechnungsbegründende Nachlaufzeit.
+Belege: [SEKUNDÄR] Faktenbasis M010 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Kündigung nach Vertragsende hinterlegt → wirksames Ende = Vertragsende; Kündigung vor Ende → Ende = Kündigungstermin.
+Tracelinks: SyRS:Vertragslaufzeit, SwRS:VertragsendeAbleitung, StRS-21
+Konsolidierung: M010-Zeitthemen: Zeitfassung→StRS-21, Klickzähler→StRS-36.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel benannt, Ableitungslogik unbestimmt.
+Status: HYPOTHESE
+
+ID: StRS-21
+Titel: Erfassungs- und Abrechnungsschutz für geleistete Zeiten
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Mitarbeiter mit Zeiterfassung, Abrechnungsverantwortlicher, c-entron-ERP-System
+Vorbedingung: Zeitdaten sind erfasst; ein Teil ist bereits fakturiert bzw. Belege sind gesperrt.
+Fakt: „M010 Zeiterfassung braucht EDIT_TIME, rechnungs-/auftragsgesperrt."; „M017 … fakturierte Zeiten unveränderlich …"
+Aussage: Das System soll die Erfassung und Änderung von Zeitdaten nur mit dem Recht EDIT_TIME gestatten; einmal fakturierte Zeiten dürfen nachträglich nicht mehr verändert werden, und für rechnungs- bzw. auftragsgesperrte Objekte ist die Zeitänderung zu sperren.
+Ergebnis: Vergütungs- und Rechnungsbasis bleibt manipulationssicher.
+Belege: [SEKUNDÄR] Faktenbasis M010, M017 — Zitate wörtlich; Fundstellen nicht genannt.
+Prüfidee: Benutzer ohne EDIT_TIME erfasst Zeit → Ablehnung; fakturierte Zeit auf anderen Betrag ändern → Ablehnung; Zeit auf auftragsgesperrtem Auftrag → Ablehnung.
+Tracelinks: SyRS:Zeiterfassung, SwRS:EditTime, SwRS:FakturierteZeitenUnveraenderlich, StRS-19, StRS-23
+Konsolidierung: EDIT_TIME, Sperrzustände und Fakturierungsunveränderlichkeit zu einer Abrechnungsschutz-Regel gebündelt.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Abrechnungsintegrität; Beleg nachreichen.
+Status: HYPOTHESE
+
+ID: StRS-22
+Titel: Belegkette Angebot → Auftrag → Lieferschein → Rechnung folgt Vorwärtsregeln
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Vertriebs-Sachbearbeiter, c-entron-ERP-System
+Vorbedingung: Ein Vertriebsbeleg der Kette liegt vor.
+Fakt: „M014 Belegkette Angebot->Auftrag->Lieferschein->Rechnung (Forward-Regeln)."
+Aussage: Das System soll Folgebelege nur entlang der Kette Angebot → Auftrag → Lieferschein → Rechnung erzeugen lassen und dabei die jeweiligen Vorwärtsregeln (zulässige Nachfolgebelege, Mengenübernahme) einhalten.
+Ergebnis: Durchgängiger Nachweis Warenwirtschaftlicher Vorgänge ohne Sprünge in der Kette.
+Belege: [SEKUNDÄR] Faktenbasis M014 — „M014 Belegkette Angebot->Auftrag->Lieferschein->Rechnung (Forward-Regeln)."; Fundstelle nicht genannt.
+Prüfidee: Rechnung direkt auf Angebot ohne Auftrag/Lieferschein → Ablehnung; Angebot → Auftrag → Lieferschein → Rechnung → Erfolg mit Mengen-/Preiskonsistenz.
+Tracelinks: SyRS:Belegkette, SwRS:ForwardRegeln, StRS-23
+Konsolidierung: Kettenregel getrennt von Preisbildung (StRS-23).
+Übernahmewürdigkeit: übernehmen - hohe Priorität; Detailregeln („Forward") sind zu präzisieren.
+Status: HYPOTHESE
+
+ID: StRS-23
+Titel: Einheitliche Preisbildung: Netto/USt, Mengenpreis, Projektpreis, kundenspezifische Abschläge, Einstandspreis
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Vertrieb, Einkauf, c-entron-ERP-System
+Vorbedingung: Preisermittlung für Beleg, Projekt oder Kunde. (UST = Umsatzsteuer; EK = Einstandspreis; FromAmount = Mengenstaffel-Grenze)
+Fakt: „M014 Netto/UST-Preisbildung fachlich."; „M034 Mengenpreis = höchste Stufe FromAmount<=Menge; EK gleitender Durchschnitt."; „M025 Projektpreis*Faktor, Herstellercode eindeutig."; „M033 TelekomDive-Profil (Mandant,Rabatt/UST)."
+Aussage: Das System soll Bruchteile eines Preises konsistent bilden: Nettobetrag und Umsatzsteuer getrennt ausgewiesen; im Mengenpreis die höchste Stufe mit FromAmount ≤ bestellter Menge; Projektpreise als Grundpreis mal vereinbartem Faktor; Kunden-/Partnerprofile (z. B. TelekomDive) mit Rabatt- und USt-Vorgabe je Mandant; der Einstandspreis als gleitender Durchschnitt geführt.
+Ergebnis: Gleiche Ware, Menge und Kunde ergeben überall im Haus denselben Preis.
+Belege: [SEKUNDÄR] Faktenbasis M014, M034, M025, M033 — Zitate wörtlich; Fundstellen nicht genannt.
+Prüfidee: Staffeln 10/50/100: Menge 60 → Stufe 50; Projekt 100×Faktor 1,2 → 120; Kunde mit Rabattprofil → um Profil reduzierter Preis mit korrekter USt-Zerlegung.
+Tracelinks: SyRS:Preisfindung, SwRS:Mengenpreisstufe, SwRS:EkGleitend, SwRS:ProjektpreisFaktor, StRS-22
+Konsolidierung: Preisbildungsregeln aus fünf Modulfakten (inkl. M033-Mandant/Rabatt/UST) zusammengefasst.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - wirtschaftlich zentral; Belege je Teilregel nachreichen.
+Status: HYPOTHESE
+
+ID: StRS-24
+Titel: Pflichtfeldregeln für erfassungs- und übertragungspflichtige Angaben
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vollständigkeit
+Akteur: Sachbearbeiter aller Fachbereiche, Schnittstellenpartner, c-entron-ERP-System
+Vorbedingung: Datensatz wird angelegt oder Übertragung wird vorbereitet.
+Fakt: „M015 Custom-Properties brauchen Name/Datentyp, Pflichtfelder nur Client."; „M013 Name+Art Pflicht, Nummer Auto."; „M008 Kampagne Name Pflicht …"; „M020 … MyDay Pflichtfelder."; „M023 Pflicht nur Artikelstamm settingsgesteuert." (ArticleBL.cs:1444); „M005 … OPOS-Pflichtspalten …"; „M042-M050 … EbInterface UStID-Pflicht" (UStID = Umsatzsteuer-Identifikationsnummer)
+Aussage: Das System soll das Speichern oder Übertragen nur gestatten, wenn die fachlichen Pflichtangaben je Objekt vollständig sind: Custom-Property mit Name und Datentyp; Projekt mit Name und Art (Nummer automatisch vergeben); Kampagne mit Namen; MyDay-Satz mit seinen Pflichtfeldern; Artikelstamm-pflichtige Felder nach Einstellung; OPOS-Beleg Pflichtspalten; EbInterface-Nachricht mit UStID.
+Ergebnis: Vorgänge sind entscheidungsfähig und übertragungsfähig; unvollständige Datensätze erreichen Folgeprozesse nicht.
+Belege: [PRIMÄR] ArticleBL.cs:1444 — „M023 … Pflicht nur Artikelstamm settingsgesteuert" (Code-Fundstelle). [SEKUNDÄR] Faktenbasis M015, M013, M008, M020, M005, M042-M050 — Zitate wörtlich; keine Fundstellen.
+Prüfidee: Je Objektart einen Datensatz ohne ein Pflichtfeld anlegen → Speichern/Übertragung muss abgewiesen werden und benennen, welches Feld fehlt.
+Tracelinks: SyRS:Erfassungsqualitaet, SwRS:Pflichtfeldpruefung, StRS-7 (Durchsetzung), StRS-38 (UStID)
+Konsolidierung: Sieben Pflichtfeld-Befunde über Module hinweg zu einer Konsolidierungsanforderung verbunden.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - ein PRIMÄR-Anker, breite Sekundärfaktenlage.
+Status: belegt
+
+ID: StRS-25
+Titel: Zahler eines Kontos ist der Kostenträger; Kostenstelle nur noch als Historie
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Anlagenbuchhalter/Controlling, c-entron-ERP-System
+Vorbedingung: Artikel-/Kontodaten mit Zahler und Kostenstelle werden bearbeitet.
+Fakt: „M023 Zahler=Kostenträger, Kostenstelle logisch gelöscht; Pflicht nur Artikelstamm settingsgesteuert. ArticleBL.cs:1444." (Kostenträger = rechenungsrelevante Kostensammelstelle)
+Aussage: Das System soll den Zahler eines Kontos fachlich als Kostenträger führen; das Attribut „Kostenstelle" ist aus der aktiven Bearbeitung genommen (logisch gelöscht) und steht nur noch als Historie zur Verfügung.
+Ergebnis: Eine eindeutige Kostenträger-Sicht verhindert doppelte/widersprüchliche Kostenzuordnung.
+Belege: [PRIMÄR] ArticleBL.cs:1444 — „M023 Zahler=Kostenträger, Kostenstelle logisch gelöscht; Pflicht nur Artikelstamm settingsgesteuert." (Code-Fundstelle).
+Prüfidee: Neuanlage: Feld „Kostenstelle" nicht wählbar; Zahler wird als Kostenträger verwendet; Alt-Datensatz zeigt historische Kostenstelle schreibgeschützt.
+Tracelinks: SyRS:Kostenrechnung, SwRS:KostentraegerZuordnung, StRS-24
+Konsolidierung: M023-Pflichtaspekt nach StRS-24 ausgelagert; Fachregel hier.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - PRIMÄR belegt.
+Status: belegt
+
+ID: StRS-26
+Titel: Lagerumbuchung erfordert Artikel, Mitarbeiter, Von- und Nach-Lager
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Lagermitarbeiter, c-entron-ERP-System
+Vorbedingung: Ware zwischen zwei Lagern wird bewegt.
+Fakt: „M018 Lagerumbuchung braucht Artikel/Mitarbeiter/Von/Nach-Lager, Default-Lager."
+Aussage: Das System soll eine Lagerumbuchung nur mit vollständig erfasstem Artikel, verantwortlichem Mitarbeiter, Ausgangs- und Ziellager annehmen; fehlt eine Vorgabe, gilt das gepflegte Default-Lager als Vorschlag.
+Ergebnis: Bestandsbewegungen sind lückenlos einem Bestand, Ort und Verursacher zuordenbar.
+Belege: [SEKUNDÄR] Faktenbasis M018 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Umbuchung ohne Nach-Lager → Ablehnung; ohne Wahl mit Default-Lager hinterlegt → Vorschlag = Default, Erfolg.
+Tracelinks: SyRS:Bestandsfuehrung, SwRS:Umbuchungspruefung, StRS-27
+Konsolidierung: Lagerregeln mit StRS-27 und StRS-28 fachlich verwandt, operativ getrennt.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Regel klar, Beleg fehlt.
+Status: belegt
+
+ID: StRS-27
+Titel: Bestellvorschlag bei Unterschreiten des Mindestbestands
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: Einkauf, c-entron-ERP-System
+Vorbedingung: freier Bestand und offene Bestellungen sind bekannt.
+Fakt: „M026 Bestellvorschlag bei Bestand<Mindestbestand+Offen."
+Aussage: Das System soll einen Bestellvorschlag erzeugen, sobald der verfügbare Bestand kleiner ist als der Mindestbestand zuzüglich bereits offener Bestellungen.
+Ergebnis: Wiedervorfüllung erfolgt rechtzeitig und ohne Doppelbestellung.
+Belege: [SEKUNDÄR] Faktenbasis M026 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Bestand 4, Mindest 5, offen 1 → Schwelle 6 → Vorschlag erzeugt; Bestand 6, offen 0 → kein Vorschlag.
+Tracelinks: SyRS:Dispositionsprozess, SwRS:Bestellvorschlagsregel, StRS-26
+Konsolidierung: Disposition eigenständig; Preisthemen in StRS-23.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise Formel; Beleg nachreichen.
+Status: belegt
+
+ID: StRS-28
+Titel: Inventur per Barcode nur für Bestände in den Status 1, 2 und 8
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Korrektheit
+Akteur: Lager-Inventurteam, c-entron-ERP-System
+Vorbedingung: Inventur wird per Barcode-Erfassung durchgeführt.
+Fakt: „M034 … Bestand Barcode Status 1,2,8."
+Aussage: Das System soll bei der Barcode-Inventur nur Bestandsbuchungen der Status 1, 2 und 8 zählen; Bestände anderer Status bleiben unberücksichtigt.
+Ergebnis: Inventurergebnis enthält nur zählfähige Bestände; Systembestand und Zählergebnis bleiben vergleichbar.
+Belege: [SEKUNDÄR] Faktenbasis M034 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Testbestand je Status einscannen: Status 1,2,8 zählen; Status 3 und 0 zählen nicht.
+Tracelinks: SyRS:Inventurprozess, SwRS:BarcodeStatusfilter, StRS-26
+Konsolidierung: Lagerkomplex mit StRS-26/27.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Statusbedeutung (1,2,8) fachlich noch zu benennen.
+Status: belegt
+
+ID: StRS-29
+Titel: RMA-Vorgang nur mit Helpdesk-Bezug
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Service-/Retouren-Mitarbeiter, c-entron-ERP-System
+Vorbedingung: Kunde zeigt eine Reklamation an. (RMA = Return-Material-Authorization, Warenrücksendegenehmigung)
+Fakt: „M029 RMA braucht Helpdesk-Bezug."
+Aussage: Das System soll eine RMA nur anlegen und bearbeiten, wenn ein Helpdesk-Vorgang zugeordnet ist; eine Rücksendung ohne dokumentierten Servicefall ist fachlich nicht zulässig.
+Ergebnis: Jede Retoure ist auf eine Serviceursache rückführbar.
+Belege: [SEKUNDÄR] Faktenbasis M029 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: RMA ohne Helpdesk-Vorgang anlegen → Ablehnung; mit gültiger Referenz → Erfolg; Referenz löschen während offener RMA → Warnung/Verweis.
+Tracelinks: SyRS:Retourenprozess, SwRS:RmaHelpdeskbezug, StRS-31
+Konsolidierung: Servicethema, Fortsetzung in StRS-31.
+Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
+Status: belegt
+
+ID: StRS-30
+Titel: Produktlebensdauer im PLM aus Start und Familienlebensdauer ableiten
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Produktmanagement, c-entron-ERP-System
+Vorbedingung: Produktfamilie mit Lebensdauer und Produktstartdatum gepflegt. (PLM = Produktlebenszyklus-Management)
+Fakt: „M012 PLM Ende=Start+Familienlebensdauer."
+Aussage: Das System soll das Lebensende eines PLM-Produkts automatisch aus Startdatum plus Familienlebensdauer berechnen; eine manuelle Abweichung soll fachlich nicht zulässig sein.
+Ergebnis: Auslaufplanungen sind innerhalb einer Familie einheitlich.
+Belege: [SEKUNDÄR] Faktenbasis M012 — wörtlich zitiert; Fundstelle nicht genannt.
+Prüfidee: Familie mit Lebensdauer 36 Monate, Start 01.01.2024 → Ende 01.01.2027; manueller Ende-Wert → nicht änderbar.
+Tracelinks: SyRS:Produktlebenszyklus, SwRS:PlmEndeAbleitung, StRS-20
+Konsolidierung: Ableitungsregel analog StRS-20, Domäne PLM.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Ableitung klar, Änderungs-/Komplettierbarkeit unklar.
+Status: belegt
+
+ID: StRS-31
+Titel: Helpdesk-Eskalation nach Wartezeit, Wochenendsteuerung und Wiederaufnahme; Hilfezeiten als Termine nutzbar
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: Helpdesk-Mitarbeiter, Helpdesk-Leiter, c-entron-ERP-System
+Vorbedingung: Helpdesk-Vorgang ist offen; Terminwiedervorlage (DueTo) gepflegt.
+Fakt: „M017 Helpdesk Eskalation 0-3 wartezeit-/wochenendegesteuert; DueTo-Änderung setzt Eskalation 0; fakturierte Zeiten unveränderlich; Filialbeschränkung nur UI(HYPOTHESE)."; „M003 Helpdesk-Zeit->Termin einstellbar."
+Aussage: Das System soll den Helpdesk-Eskalationsstand in den Stufen 0–3 wartezeit- und wochenendegesteuert führen; jede Änderung der Terminwiedervorlage (DueTo) soll die Eskalation auf 0 zurücksetzen; Hilfe-/Servicezeiten sollen optional als Termine erzeugt werden; eine Beschränkung auf Filialdaten soll auch außerhalb der Oberfläche gelten. [HYPOTHESE: Die serverseitige Filialbeschränkung und die Eskalationsschwellen sind nur über die Faktenbasis M017 belegt; eine durchsetzende Fundstelle fehlt.]
+Ergebnis: Vorgänge eskalieren planmäßig, Pausen werden berücksichtigt, Termine und Hilfezeiten bleiben synchron.
+Belege: [SEKUNDÄR] Faktenbasis M017, M003 — Zitate wörtlich inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
+Prüfidee: Offener Vorgang ohne Bearbeitung über Stufenschwellen → Eskalation steigt 0→3; Wochenendzeit erhöht nicht; DueTo-Änderung → zurück auf 0; Helpdesk-Zeit erzeugt Termin gemäß Einstellung.
+Tracelinks: SyRS:Helpdeskprozess, SwRS:Eskalationsstufen, SwRS:DueToReset, StRS-21, StRS-29, StRS-7 (Filialbeschränkung)
+Konsolidierung: M017 und M003 zu Serviceprozess; Fakturierungsschutz nach StRS-21 ausgelagert.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität; Eskalationsstufen-Schwellen unbelegt.
+Status: HYPOTHESE
+
+
+ID: StRS-32
+Titel: CRM-Projekte: Pflichtangaben, automatische Nummer, Löschung nur ohne Referenz
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Vertriebsmitarbeiter, c-entron-ERP-System
+Vorbedingung: CRM-Projekt (Kundenprojektauftrag im CRM) wird angelegt oder gelöscht.
+Fakt: „M013 CRM-Projekt Status/Art nur löschbar ohne Referenz; Name+Art Pflicht, Nummer Auto."
+Aussage: Das System soll CRM-Projekte nur mit Name und Art anlegen, die Nummer selbst vergeben, und die Löschung von Status- oder Art-Definition nur zulassen, solange keine referenzierenden Vorgänge existieren.
+Ergebnis: Belegbare Historie: keine Projektart verschwindet unter laufenden Vorgängen.
+Belege: [SEKUNDÄR] Faktenbasis M013 — wörtlich zitiert; Fundstelle nicht genannt; Pflichtfeld-Aspekt durch StRS-24 konsolidiert.
+Prüfidee: Art X von einem Beleg referenziert, X löschen → Ablehnung; Art ohne Referenz löschen → Erfolg; Projekt ohne Name → abgewiesen.
+Tracelinks: SyRS:Projektverwaltung, SwRS:Loeschreferenzpruefung, StRS-24
+Konsolidierung: Pflichtfelder in StRS-24 konsolidiert; Refenzzählung eigenständig.
+Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
+Status: belegt
+
+ID: StRS-33
+Titel: Kampagnenführung: Terminplausibilität, dokumentierte Ansprechpartnerentscheidung, Mailingversion
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vollständigkeit
+Akteur: Marketingleiter, c-entron-ERP-System
+Vorbedingung: Kampagne wird geplant bzw. Ansprechpartner-Ergebnis festgehalten.
+Fakt: „M008 Kampagne Name Pflicht, Ende>=Start; Ansprechpartner-Entscheidung braucht Text+zugeordneten Ansprechpartner."; „M030 Mailings Version2."
+Aussage: Das System soll Kampagnen nur mit gültigem Namen und Enddatum nicht vor Startdatum führen; eine Ansprechpartner-Entscheidung erfordert eine Begründung im Text und den zugeordneten Ansprechpartner; Mailingversände erfolgen mit der aktuellen Mailingversion 2.
+Ergebnis: Kampagnenzeitraum valide; Marketingentscheidungen nachvollziehbar dokumentiert.
+Belege: [SEKUNDÄR] Faktenbasis M008, M030 — Zitate wörtlich; Fundstellen nicht genannt; „Name Pflicht" konsolidiert in StRS-24.
+Prüfidee: Ende < Start → Speichern abgelehnt; Entscheidung ohne Text oder ohne Ansprechpartner → abgelehnt; beide gefüllt → Erfolg.
+Tracelinks: SyRS:Kampagnenprozess, SwRS:Kampagnenplausibilitaet, SwRS:MailingVersion2, StRS-24
+Konsolidierung: M008 und M030 zum Marketing-Komplex verbunden.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - „Version2" fachliche Tragweite unklar.
+Status: belegt
+
+ID: StRS-34
+Titel: Kommunikationsinhalte nur durch Berechtigte und nur im eigenen Namen
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vertraulichkeit
+Akteur: Chat-Mitglied, MyDay-Nutzer, Social-Media-Betreuer, c-entron-ERP-System
+Vorbedingung: Chat-Nachricht wird gesendet; sozialer Kommentar geschrieben.
+Fakt: „M020 Chat nur Mitglied/Autor, max250. MyDay Pflichtfelder."; „M039 SocialMedia nur eigener Kommentar im SP." (SP = gespeicherte Prozedur)
+Aussage: Das System soll das Verfassen von Chat-Nachrichten nur Gruppenmitgliedern bzw. Autoren gestatten und die Nachricht auf 250 Zeichen begrenzen; in Social-Media-Auswertung/-Pflege soll ein Bearbeiter nur eigene Kommentare ändern oder löschen dürfen. [HYPOTHESE: Die Mitglieder-/Autorschafts-Regel ist nur über Faktenbasis M020/M039 belegt; eine durchsetzende Stelle für alle Kommunikationspfade ist nicht benannt.]
+Ergebnis: Interne Kommunikation ist teilnehmerbegrenzt; fremde Kommentare bleiben unverändert.
+Belege: [SEKUNDÄR] Faktenbasis M020, M039 — Zitate wörtlich; Fundstellen nicht genannt; MyDay-Pflichtfelder → StRS-24.
+Prüfidee: Nicht-Mitglied sendet Chat-Nachricht → abgelehnt; 251 Zeichen → abgelehnt; Benutzer ändert Kommentar eines anderen → abgelehnt.
+Tracelinks: SyRS:Kommunikation, SwRS:ChatTeilnahmepruefung, SwRS:EigenerKommentar, StRS-1
+Konsolidierung: M020 (Chat) und M039 zur Kommunikations-Zugriffsregel.
+Übernahmewürdigkeit: übernehmen - hohe Priorität; Beleg fehlt.
+Status: HYPOTHESE
+
+
+ID: StRS-35
+Titel: Umfragen folgen einer definierten Statusmaschine
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Konsistenz
+Akteur: Umfrage-Verantwortlicher, Teilnehmer, c-entron-ERP-System
+Vorbedingung: Umfrage durchläuft Lebenszyklus (z. B. Entwurf → aktiv → abgeschlossen).
+Fakt: „M032 Umfrage Statusmaschine."
+Aussage: Das System soll Umfrage-Statusübergänge ausschließlich entlang der definierten Statusmaschine erlauben; nicht erlaubte Sprünge und Änderungen an abgeschlossenen Umfragen sind abzulehnen.
+Ergebnis: Umfrageergebnisse sind abhängig vom Status geschützt und auswertbar.
+Belege: [SEKUNDÄR] Faktenbasis M032 — wörtlich zitiert; Fundstelle nicht genannt; Statusliste selbst unbelegt.
+Prüfidee: Nach Zustandsliste: erlaubter Übergang → Erfolg; verbotener Sprung „abgeschlossen → aktiv" → Ablehnung.
+Tracelinks: SyRS:Umfrageprozess, SwRS:UmfrageStatusmaschine, StRS-41
+Konsolidierung: Statusmaschinen-Denkmuster wie StRS-41 (Workflow), Domäne eigenständig.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Zustandsmengen fehlen in Faktenbasis.
+Status: belegt
+
+ID: StRS-36
+Titel: Auswertungsobjekte: Reports nur mit Recht löschbar, Klickzahlen nur monoton
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Sicherheit
+Akteur: Auswertungsverantwortlicher, c-entron-ERP-System
+Vorbedingung: Report mit Folgeobjekten soll gelöscht werden; Klickzähler wird erhöht.
+Fakt: „M028 Report-Löschung Kaskade ohne Recht(HYPOTHESE)."; „M010 Click-Zähler monoton."
+Aussage: Das System soll die Reportlöschung samt Kaskade nur mit dem zuständigen Recht zulassen; der Klickzähler soll ausschließlich monoton wachsen (kein Zählen von Löschungen oder Zurücksetzen).
+Ergebnis: Auswertungslandschaft ist nicht unbeaufsichtigt auslöschbar; Reichweitenstatistik manipulationsarm.
+Belege: [SEKUNDÄR] Faktenbasis M028 (HYPOTHESE), M010 — wörtlich zitiert; Fundstellen nicht genannt.
+Prüfidee: Benutzer ohne Report-Recht löst Report-Kaskade aus → nichts wird gelöscht, Meldung; Zähler um -1 geändert → abgelehnt, +1 → Erfolg.
+Tracelinks: SyRS:Auswertungsverwaltung, SwRS:ReportLoeschrecht, SwRS:Klickzaehler, StRS-7, StRS-4
+Konsolidierung: Befunde M028 und M010(Click) zu Auswertungsverwaltung zusammengefasst.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Löschkaskade ohne Recht ist akuter Befund.
+Status: HYPOTHESE
+
+ID: StRS-37
+Titel: Massenaktualisierung nur bei vollständiger Bearbeitung; Modul ist zu sichern
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vollständigkeit
+Akteur: Fachadministrator, c-entron-ERP-System
+Vorbedingung: Massenänderung über alle Datensätze eines Moduls wird beauftragt.
+Fakt: „M019 Massenupdate nur bei Vollständigkeit erledigt; Modul rechtefrei."
+Aussage: Das System soll eine Massenaktualisierung nur dann als erledigt abschließen, wenn alle betroffenen Datensätze bearbeitet wurden; das Massenupdate-Modul soll zusätzlich an ein Fachrecht gebunden werden (bisher rechtefrei).
+Ergebnis: Keine teildurchgeführten Serienänderungen; nur Berechtigte können Massenkorrekturen anstoßen.
+Belege: [SEKUNDÄR] Faktenbasis M019 — wörtlich zitiert; Fundstelle nicht genannt; Rechtefreiheit zusätzlich in StRS-7.
+Prüfidee: Abbruch nach 50 von 100 Sätzen → Status bleibt „unvollständig" und meldet Restliste; Benutzer ohne Recht öffnet Modul → Ablehnung.
+Tracelinks: SyRS:Massenpflege, SwRS:MengenupdateVollstaendigkeit, StRS-7, StRS-4
+Konsolidierung: M019 vollständig hier; Durchsetzungsaspekt querverwiesen.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Soll-Recht ist abgeleitete Zielkorrektur des Befunds.
+Status: HYPOTHESE
+
+ID: StRS-38
+Titel: Externe Schnittstellen halten Partnergrenzen, Berechtigungen und Übertragungsregeln ein
+Ebene: StRS
+Typ: Schnittstelle
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: Systemintegration, Partner (EbInterface, GLS, Shipcloud, Cop, Egis, FinAPI, Icecat, ITscope, docuFORM), c-entron-ERP-System
+Vorbedingung: Datenaustausch mit externem Partner steht an.
+Fakt: „M042-M050 Schnittstellen: EbInterface UStID-Pflicht; GLS max50Ref/30Pakete; Shipcloud Basic; Cop limit100; Egis Platzhalter-Block; FinAPI Token; Icecat null; ITscope max50; docuFORM SETTINGS-Recht+PKCE." und „M005 SEPA-Betragslimit, DATEV-Lizenz, OPOS-Pflichtspalten, EDI-Routing je Anbieter." (UStID = Umsatzsteuer-Identifikationsnummer; EDI = elektronischer Datenaustausch; PKCE = Sicherungsverfahren für Autorisierungscodes)
+Aussage: Das System soll je Partner dessen fachliche Grenzen und Bedingungen durchsetzen: EbInterface nur mit UStID; GLS maximal 50 Referenzen und 30 Pakete je Sendung; Cop maximal 100 Datensätze je Abruf; ITscope maximal 50; Egis sendet nicht mit ungelösten Platzhaltern; FinAPI nur mit gültigem Token; Icecat-Antworten ohne Inhalt werden als Null behandelt; docuFORM-Aufruf erfordert das SETTINGS-Recht und PKCE-gesicherte Autorisierung; EDI-Nachrichten werden je Anbieter weitergeleitet; der Shipcloud-Funktionsumfang „Basic" ist einzuhalten.
+Ergebnis: Partner empfangen keine grenzüberschreitenden oder unberechtigten Aufträge; Fehlerbilder werden je Partner fachlich korrekt unterschieden.
+Belege: [SEKUNDÄR] Faktenbasis M042–M050 — Aufzählung der Partnergrenzen (Fundstellen in Faktenbasis nicht genannt). [SEKUNDÄR] Faktenbasis M005 — „EDI-Routing je Anbieter" (SEPA→StRS-19, DATEV→StRS-8, OPOS→StRS-24).
+Prüfidee: GLS-Sendung mit 51 Referenzen oder 31 Paketen → Ablehnung; docuFORM-Aufruf ohne SETTINGS-Recht → Ablehnung; Egis-Nachricht mit ungelöstem Platzhalter → Blockierung; Cop-Abruf mit 101 Datensätzen → Begrenzung auf 100; FinAPI-Aufruf mit abgelaufenem Token → Ablehnung; EbInterface-Datensatz ohne UStID → Rückweisung.
+Tracelinks: SyRS:API-Perimeter (SyRS-57), SwRS:Partnerlimits, StRS-9, StRS-24
+Konsolidierung: Neun Einzel-Schnittstellenbefunde (M042–M050) plus EDI-Routing (M005) zu einer Verbundanforderung; UStID-Pflicht → StRS-24, Tokens/Tickets → StRS-9.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - präzise Grenzwerte pro Partner; mangels PRIMÄR-Fundstellen nur mit [HYPOTHESE] übernehmbar.
+Status: HYPOTHESE
+
+ID: StRS-39
+Titel: KI-Assistent im ERP nur nach Bestätigung, ohne Bestätigung nur mit Sonderrecht; Anhangsgrenzen 20/40 MB
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Vertraulichkeit
+Akteur: Fachanwender mit KI-Werkzeugen, Datenschutzverantwortlicher, c-entron-ERP-System
+Vorbedingung: Ein Anwender beauftragt ein KI-Werkzeug mit Unternehmensdaten oder Anhängen.
+Fakt: „M002 KI-Tool Bestätigung außer UNRESTRICTED_ACCESS, Anhänge 20/40MB."
+Aussage: Das System soll den Aufruf eines KI-Werkzeugs mit Unternehmensdaten nur nach ausdrücklicher Bestätigung des Anwenders ausführen; der Entfall der Bestätigung ist ausschließlich an das Sonderrecht UNRESTRICTED_ACCESS gebunden. Anhänge sind oberhalb der Grenze von 20 MB bzw. 40 MB abzulehnen.
+Ergebnis: Kein Datenabfluss an KI-Dienste ohne bewusste Freigabe; Ausnahmen sind personenbezogen über ein Sonderrecht gesteuert.
+Belege: [SEKUNDÄR] Faktenbasis M002 — „KI Bestätigung außer Recht, 20/40MB"; Fundstelle in Faktenbasis nicht genannt.
+Prüfidee: Anwender ohne UNRESTRICTED_ACCESS startet KI-Werkzeug → Bestätigungsdialog, Abbruch ohne Versand; Anwender mit Recht → ohne Dialog; Anhang 21 MB bei 20-MB-Grenze → Ablehnung.
+Tracelinks: SyRS:KI-Assistent (SyRS-52), SwRS:KI-Grenzwerte (SwRS-54), StRS-1, StRS-4
+Konsolidierung: Bestätigungsfreiung ist Instanz des Gruppenrechtsmodells (StRS-1) und der Rechtepflichtigkeit (StRS-4).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - fachlich (Datenschutz); Zuordnung 20 vs. 40 MB und Rechtsherleitung zu klären.
+Status: HYPOTHESE
+
+ID: StRS-40
+Titel: Persönlicher Arbeitsplatz zeigt nur zugangsberechtigte Module; Autostart ab fünf Modulen wird gewarnt
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Benutzerfreundlichkeit
+Akteur: Benutzer beim Systemstart, c-entron-ERP-System
+Vorbedingung: Benutzer hat persönlichen Arbeitsplatz (Modulzentrale, Modulautostart).
+Fakt: „Modulzentrale filtert darstellerisch, Autostart-Warnung ab 5 Modulen." — in der Faktenbasis (M001–M070) existiert hierfür kein Modul-Fakt mit Fundstelle; Punkt als Lücke gemeldet.
+Aussage: Das System soll in der Modulzentrale nur Module darstellen, auf die der Benutzer nach Recht und Lizenz zugreifen kann; bei fünf oder mehr Autostart-Modulen soll vor der Aufnahme gewarnt werden.
+Ergebnis: Der Startbildschirm ist rechts- und lizenzkonsistent; unkontrollierter Modulstart bleibt sichtbar.
+Belege: [SEKUNDÄR] Auftraggeber-Auftrag — „Modulzentrale filtert darstellerisch, Autostart-Warnung ab 5 Modulen." ohne Fundstelle; Faktenlücke gemeldet.
+Prüfidee: Benutzer ohne Recht/Lizenz auf Modul X → X erscheint nicht in der Modulzentrale; Autostart mit 5 Modulen → Warnung; 4 Module → keine Warnung.
+Tracelinks: SyRS:Modul- und Funktionsstart (SyRS-51), StRS-8, StRS-3, StRS-1
+Konsolidierung: Verknüpft mit Modulzugangsregel StRS-8 und Lizenzgrenze StRS-3.
+Übernahmewürdigkeit: übernehmen - niedrige Priorität - bis mittel — allein auf Auftraggeber-Behauptung gestützt; Faktenfundstelle nachreichen.
+Status: HYPOTHESE
+
+ID: StRS-41
+Titel: Prozesssteuerung: Workflows mit prozesstypischen Schritten, externe Zeitsteuerung, gültige Anbindung externer Vorgänge
+Ebene: StRS
+Typ: Fachregel
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur: Prozessverantwortlicher, externer Zeitplaner (Scheduler), externes Werkzeug, c-entron-ERP-System
+Vorbedingung: Workflow eines Prozesstyps ist gestartet; zeitgesteuerte Aufgaben und externe Anbindungsvorgänge sind hinterlegt.
+Fakt: „M041 Workflow prozesstypische Schritte; RunningWorkFlows ohne Code(HYPOTHESE)."; „M036 RiverTicket ohne URL ungültig."; „M070 Scheduler extern(HYPOTHESE)."; „M006 externe Tools ExitCode0."
+Aussage: Das System soll in einem Workflow nur die für den Prozesstyp typischen Schrittarten zulassen; zeitgesteuerte Abläufe werden durch einen externen Zeitplaner angestoßen (Annahme); ein RiverTicket ohne Ziel-URL ist ungültig; ein externes Werkzeug gilt nur bei Exit-Code 0 als erfolgreich.
+Ergebnis: Prozessabläufe sind typrein und gegen scheinbar erfolgreiche, tatsächlich fehlgeschlagene Ausführung geschützt.
+Belege: [SEKUNDÄR] Faktenbasis M041, M036, M070, M006 — Zitate inkl. HYPOTHESE-Kennzeichnung; Fundstellen nicht genannt.
+Prüfidee: Workflow Typ T → nur Schrittarten aus Typdefinition wählbar; RiverTicket ohne URL → ungültig; externes Werkzeug Exit-Code 1 → Fehlersignal, 0 → Erfolg.
+Tracelinks: SyRS:Workflow-Engine (SyRS-54), SyRS:Scheduler (SyRS-55), StRS-2, StRS-35, StRS-38
+Konsolidierung: Prozess-/Automatisierungsthemen aus M041, M036 (RiverTicket), M070, M006 gebündelt; Statusmaschinen-Muster → StRS-35.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Abarbeitung laufender Instanzen und externer Scheduler ausdrücklich unbelegt.
+Status: HYPOTHESE

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/SwRS.md

@@ -0,0 +1,968 @@
+ID: SwRS-1
+Titel: Softwareinterne Rechteauflösung über gecachte Roh-SQL-Menge (Sichtrus/Sichmemb)
+Ebene: SwRS
+Typ: Constraint-/Implementierungsanforderung (Berechtigungskomponente)
+Qualitätsmerkmal: Richtigkeit, Konsistenz, Nachvollziehbarkeit (ISO 29148: Correctness, Consistency)
+Akteur: `AppRightsBL` (BL-Schicht) im Auftrag jeder aufrufenden Komponente
+Vorbedingung: Benutzersitzung mit `appUserI3D`; Session-Cache verfügbar
+Fakt: `HasUserRight` lädt die Rechte über `GetAllAppRightsFromUser`, dessen SQL wörtlich lautet: `"SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D"` (AppRightsBL.cs:653-656); Ergebnis wird unter dem Schlüssel `$"AllRightsFromAppUser{appUserI3D}"` gecacht und per `rights.Contains(rightID)` geprüft (AppRightsBL.cs:644-649).
+Aussage: Die Rechtekomponente löst Benutzerrechte ausschließlich über diese JOIN-Roh-SQL auf; die Zugriffsstrukturen `Sichtrus`/`Sichmemb` führen nur einen PK auf `I3D` und kein UNIQUE auf `(Gruppe, Recht)` bzw. `(Benutzer, Gruppe)`, sodassJOIN-Duplikate in der Ergebnisliste sichtbar bleiben; eine Entduplizierung (DISTINCT/Distinct) erfolgt nicht.
+Ergebnis: Die Ja/Nein-Antwort von `HasUserRight` bleibt trotz Duplikaten korrekt (Mengenprüfung), ändert sich aber erst nach Cache-Neubindung; Doppelzuweisungen werden softwareintern nicht erkannt oder gemeldet.
+Belege: PRIMÄR – durchsetzende Stelle: `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `HasUserRight`/`GetAllAppRightsFromUser`, Zeilen 644-664, SQL wörtlich zitiert (im Lauf gegen den Quellcode gespiegelt). PRIMÄR – Schema: `SSMS_DB_SCHEMA.sql` `CREATE TABLE [dbo].[Sichmemb]` (Zeile 51211), `CREATE TABLE [dbo].[Sichtrus]` (Zeile 51267) ohne UNIQUE-Constraint auf den Beziehungsspalten.
+Prüfidee: Duplikatzeile in `Sichmemb` (gleicher Benutzer/Gruppe) und `Sichtrus` einfügen, `HasUserRight` vor/nach Cache-Invalidierung aufrufen; erwarten: korrektes Ergebnis, aber Duplikate in der geladenen Liste.
+Tracelinks: SyRS:Berechtigungsprüfung, StRS:Rechteverwaltung; SwRS-2, SwRS-3, SwRS-43
+Konsolidierung: Kandidat – dieselbe fachliche Zuordnung „Benutzer ↔ Gruppe ↔ Recht" existiert zweiteilig: einmal Raw-SQL in `AppRightsBL.GetAllAppRightsFromUser` (Zeilen 653-656), einmal ORM-seitig über `AppUserMaps` („Groups via sichmemb", Faktenbasis M001); im Zielsystem auf einen Leseweg führen. Zweitens: parallele Rechteauflösung für Webkonten, `GetAllWebRightsFromWebAccount` (`SELECT WebRightsI3D AS ID FROM WebAccountsRights WHERE WebAccountsI3D = :WebAccountI3D`, AppRightsBL.cs:681-683).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant, durchsetzende Stelle belegt
+Status: belegt
+
+ID: SwRS-2
+Titel: Hartcodierte Admin-Zuweisungs-Whitelist (38 Rechte-I3Ds)
+Ebene: SwRS
+Typ: Implementierungs-/Constraintanforderung (Berechtigung)
+Qualitätsmerkmal: Wartbarkeit, Sicherheit
+Akteur: `AppRightsBL` bei Rechtezuweisung durch Administratoren
+Vorbedingung: Aufrufer aus der Verwaltungsmaske „Rechte zuweisen"
+Fakt: `GetAssignableAdminRightI3Ds` liefert eine fest verdrahtete `List<int>` mit Rechte-I3Ds (u. a. `20400149, 20400150, … 20400223`) und wird an zwei Stellen als „changeableRights" verwendet (AppRightsBL.cs:714 ff., Aufrufe Zeile 268 und 286).
+Aussage: Nur die per Whitelist genannten Rechte dürfen der Administratorgruppe zugewiesen/entzogen werden; die Liste liegt als Quellcode-Konstante vor, nicht als Datenhaltung oder Constraint.
+Ergebnis: Neue oder umbenannte Rechte sind ohne Quellcode-Änderung administrativ nicht zuweisbar; Verhalten ist reproduzierbar, aber nur über Deployments änderbar.
+Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs`, `private IList<int> GetAssignableAdminRightI3Ds`, Zeile 714 ff. mit Kommentar `//Gets the right i3ds which can assigned and removed from admin group`; Aufrufe Zeilen 268, 286 (Wortlaut im Lauf geprüft).
+Prüfidee: Rechte-I3D außerhalb der Liste per Admin-UI zuweisen wollen → Ablehnung erwarten; Whitelist-Eintrag entfernen und erneut prüfen.
+Tracelinks: SyRS:Rechteverwaltung-UI, StRS:Rechteverwaltung; SwRS-1
+Konsolidierung: kein Fall – die Whitelist ist die einzige Zuweisungsfilter-Implementierung; Berührung zu SwRS-1 ist Ebenen-/Modulzusammenhang, nicht Doppelimplementierung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-3
+Titel: ORM-Mapping des Kontokennworts auf die Altsäule `BenutzerInfo2`
+Ebene: SwRS
+Typ: Datenanforderung (Entität-/Spaltenm mapping)
+Qualitätsmerkmal: Konsistenz, Nachvollziehbarkeit
+Akteur: NHibernate-Mapping `AppUserMaps`
+Vorbedingung: Persistenz einer `AppUser`-Instanz
+Fakt: `this.Map(appUser => appUser.Password).Column("BenutzerInfo2");` (AppUserMaps.cs:24); Kennwortregeln mappen auf `KennAendNachTagen`, `LetzKennAend`, `KennLaenMin` (Zeilen 27, 31, 32); `AuthentificationKind` ist mit `.CustomType<AuthentificationKind>.Not.Nullable` gemappt (Zeile 37).
+Aussage: Das Domänenattribut `Password` wird softwareintern in die historisch benannte Spalte `BenutzerInfo2` geschrieben und ist im Mapping nicht als `Not.Nullable` erklärt; `AuthentificationKind` dagegen ist zwingend.
+Ergebnis: Ein Kontodatensatz kann ohne Kennwertwert persistiert werden, muss aber einen Authentifizierungsmodus tragen; Namensdivergenz Domäne/Spalte bleibt für Auswertung und Migration wirksam.
+Belege: PRIMÄR – `src/backend/Centron.DAO/Mappings/Administration/AppUserMaps.cs`, Zeilen 24, 27, 31, 32, 37 (Wortlaut im Lauf geprüft). KONTEXT – Faktenbasis M001 für die Aussage `TwoFactorAuthKey … NOT NULL` (im Schema-Dump dieses Laufs nicht separath verifiziert).
+Prüfidee: `AppUser` ohne `Password` speichern und Schema-/NOT-NULL-Verhalten prüfen; `AuthentificationKind` leer lassen und Mapping-Verstoß erwarten.
+Tracelinks: SyRS:Benutzerverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-42
+Konsolidierung: Kandidat (fachliche Doppelführung im selben Gegenstand „Kennwort eines Kontos"): `AppUser.Password → BenutzerInfo2` (AppUserMaps.cs:24) gegenüber `WebAccount.Password` mit SHA1-Prüfung (WebAccountBL.cs:56-61) und `MailScannerProfile.Password` (verschlüsselt) / `MailPassword` (unverschlüsselt); drei Kennwort-Haltungen für dasselbe Konzept.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-4
+Titel: Größen- und Zeichengrenzen der KI-Konversation in der Client-Schicht
+Ebene: SwRS
+Typ: Funktions-/Restriktionsanforderung (interne Berechnungsvorschrift)
+Qualitätsmerkmal: Zuverlässigkeit, Ressourcenverhalten
+Akteur: `ConversationViewModelBase`, `Coordinator` (KI-Modul)
+Vorbedingung: Benutzer hängt Dateien an einen KI-Chat an bzw. sendet Text
+Fakt: Faktenbasis M002 verortet die Steuerung in `Coordinator` Zeile 230 und Zeile 411 sowie die Grenzlogik in `ConversationViewModelBase` Zeilen 40-575 mit den Werten 20 MB / 40 MB und 20000 Zeichen.
+Aussage: Die Client-Komponente prüft Anhangsgrößen gegen eine Einzelgrenze von 20 MB und eine Summengrenze von 40 MB sowie den Textumfang gegen 20 000 Zeichen, bevor eine Anfrage an den `Coordinator` übergeben wird. [HYPOTHESE: Belegtiefe laut Faktenbasis M002, nicht zeilenweise gegengeprüft; serverseitige Zweitprüfung nicht verifiziert.]
+ [HYPOTHESE] (Belegtiefe laut Faktenbasis, nicht zeilenweise gegengeprüft).
+Ergebnis: Zu große Anhänge bzw. zu lange Texte werden clientseitig abgewiesen, bevor Serverressourcen belegt werden; die Prüfung ist UI-seitig, nicht persistierend erzwungen.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Zeilenangaben wörtlich übernommen; im Lauf nicht Zeile für Zeile gegengeprüft) – `Coordinator.cs:230`, `Coordinator.cs:411`, `ConversationViewModelBase.cs:40-575` (M002).
+Prüfidee: Dateien mit 21 MB (einzeln) und 3×15 MB (Summe) sowie Text mit 20 001 Zeichen anhängen; Ablehnung und Meldung erwarten; Serverseitige Zweitprüfung als abweichend melden, falls nicht vorhanden.
+Tracelinks: SyRS:KI-Assistent, StRS:KI-Nutzung
+Konsolidierung: Kandidat: SwRS-54 (dieselben KI-Grenzwerte 20/40 MB/20000 Zeichen in der Client-Schicht); bei Übernahme mit SwRS-54 verschmelzen.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Zahlenwerte vor Übernahme gegen Quellcode verifizieren
+Status: HYPOTHESE
+
+
+ID: SwRS-5
+Titel: Terminbereichslogik der Schedule-Komponente
+Ebene: SwRS
+Typ: Funktionsanforderung (interne Algorithmen)
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit
+Akteur: `ScheduleBL`
+Vorbedingung: Abfrage von Terminen für einen Anzeigezeitraum
+Fakt: Faktenbasis M003 benennt `ScheduleBL.cs` Zeilen 2379-2424 als durchsetzende Stelle der Zeitbereichsbetrachtung.
+Aussage: Die Schedule-Komponente berechnet Sichtbarkeits- und Zuordnungsergebnisse aus den Termindaten innerhalb eines intern ermittelten Zeitfensters; die Regel ist ausschließlich in `ScheduleBL.cs` Zeilen 2379-2424 implementiert.
+Ergebnis: Termine außerhalb des intern bestimmten Fensters erscheinen in den betroffenen Sichten nicht; eine zweite, abweichende Bereichsberechnung existiert in der Component-Schicht nicht.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis; Zeilenangabe wörtlich übernommen, nicht gegengeprüft) – `ScheduleBL.cs:2379-2424` (M003).
+Prüfidee: Termine an Fensteranfang/-ende sowie exakt auf der Grenze anlegen und Sichtbarkeit vergleichen.
+Tracelinks: SyRS:Kalender-Sichten, StRS:Terminverwaltung; SwRS-25
+Konsolidierung: kein Fall – Bereichslogik nur an einer Stelle belegt.
+Übernahmewürdigkeit: übernehmen - niedrige Priorität - Formel/Fenstergrenzen fehlen in der Faktenbasis
+Status: HYPOTHESE
+
+ID: SwRS-6
+Titel: Persistenzregeln für Zahlungsverkehr und Buchungsimport/-export
+Ebene: SwRS
+Typ: Daten-/Constraintanforderung
+Qualitätsmerkmal: Richtigkeit, Konsistenz (Abrechnung)
+Akteur: `PaymentTransactionBL`, `BookKeepingExportBL`, `BookKeepingImportBL`
+Vorbedingung: Zahlungen werden erzeugt, Export/Import angestoßen
+Fakt: Faktenbasis M005 verweist auf `PaymentTransactionBL` Zeilen 93-288, `BookKeepingExportBL` Zeile 1560, `BookKeepingImportBL` Zeilen 127-149 sowie Schema `BookKeepingExport`, `SupplierEdiConfigurations`; zusätzlich `EDIGatewaySettingBL`/`EDIDispatcherBL` Zeilen 56-109.
+Aussage: Die Zahlungsverkehrs-Komponente schreibt Transaktionen über den genannten Codepfad in die eigene Datenhaltung und koppelt Export/Import an die Tabelle `BookKeepingExport`; EDI-Versandparameter werden über `EDIGatewaySettingBL`/`EDIDispatcherBL` gelesen.
+Ergebnis: Zahlungsdatensätze, Exportaufträge und EDI-Konfiguration hängen softwareintern über die benannten Schlüssel zusammen; Brüche der Kette bleiben ohne Constraint (siehe ).
+Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Referenzen wörtlich übernommen; nicht Zeile für Zeile gegengeprüft) – `PaymentTransactionBL.cs:93-288`, `BookKeepingExportBL.cs:1560`, `BookKeepingImportBL.cs:127-149`, `EDIDispatcherBL.cs:56-109`, Schema `BookKeepingExport`/`SupplierEdiConfigurations` (M005).
+Prüfidee: Zahlung erzeugen → Export anstoßen → Import rückspielen; Referenzielle Integrität und Wiederholbarkeit (Idempotenz) prüfen.
+Tracelinks: SyRS:Zahlungsverkehr, SyRS:Buchungsuebergabe, StRS:Abrechnung; SwRS-8, SwRS-26, SwRS-51
+Konsolidierung: Kandidat – Zahlungen werden an zwei getrennten Stellen modelliert: `PaymentTransactionBL` (Zahlungsverkehr) und `PaymentsBL`/`IncomingPayment` mit Tabelle `Zahlungseingang` (siehe SwRS-8); fachlich derselbe Gegenstand „eingehende Zahlung", zwei Datenhaltungen.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Formeln/Feldregeln nachliefern
+Status: HYPOTHESE
+
+ID: SwRS-7
+Titel: Werkzeuganbindung über ExternalTools-Datenhaltung
+Ebene: SwRS
+Typ: Datenanforderung / Mapping
+Qualitätsmerkmal: Wartbarkeit, Portabilität
+Akteur: `ExternalToolPreviewViewModel`, Tabelle `ExternalTools`
+Vorbedingung: Externes Werkzeug ist in `ExternalTools` gepflegt
+Fakt: Faktenbasis M006 benennt `ExternalToolPreviewViewModel` als Aufrufer und `ExternalTools` als Datenträger.
+Aussage: Die Vorschaukomponente liest Werkzeugdefinitionen aus der Tabelle `ExternalTools` und übergibt Startparameter an den Client; eine eigene Werkzeughaltung außerhalb dieser Tabelle existiert nicht.
+Ergebnis: Werkzeugbestand ist ausschließlich über diese Tabelle steuerbar; Änderungen wirken ohne Codeanpassung.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz übernommen, nicht gegengeprüft) – `ExternalToolPreviewViewModel`, Schema `ExternalTools` (M006).
+Prüfidee: Satz in `ExternalTools` ändern und Vorschau neu laden; Parameterweitergabe protokollieren.
+Tracelinks: SyRS:Externe-Werkzeuge, StRS:Arbeitsplatz
+Konsolidierung: kein Fall – keine zweite Werkzeughaltung belegt.
+Übernahmewürdigkeit: übernehmen - niedrige Priorität - Spalten-/Parametereinfluss nicht belegt
+Status: HYPOTHESE
+
+ID: SwRS-8
+Titel: Zahlungseingang: Berechtigungsgate und Referenzlose Löschung mit Währungsfaktor-Umbuchung
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Abrechnung + Berechtigung)
+Qualitätsmerkmal: Richtigkeit, Sicherheit, Konsistenz
+Akteur: `PaymentsBL` (Finances/Payments)
+Vorbedingung: Angemeldeter Benutzer mit Rechtenauflösung nach SwRS-1
+Fakt: `if (loggedInUser.User.HasUserRight(UserRightsConst.Controlling.Finances.INCOMING_PAYMENT_TRANSACTIONS) == false) return Result.AsError("Sie haben nicht das Recht 'Zahlungseingang.", DefaultMessageCodes.RightCheckFailed);` (PaymentsBL.cs:43-44); Löschung summiert und bucht zurück: `var amountToChange = groupie.Sum(f => f.Amount) * (-1);` und übergibt `amountToChange * invoice.CurrencyFactor` an `receiptBL.UpdateReceiptIsPaid(..., "Zahlungseingang gelöscht",...)` (PaymentsBL.cs:62-71), danach `Delete(...)` (Zeile 75). Schema: `CREATE TABLE [dbo].[Zahlungseingang]( … [RechKopfI3D] [int] NULL, [Betrag] [float] NULL, [Restbetrag] [float] NULL …)` ohne FOREIGN KEY (SSMS_DB_SCHEMA.sql:17604-17623).
+Aussage: Das Löschen von Zahlungseingängen ist an das Recht `INCOMING_PAYMENT_TRANSACTIONS` gebunden; die Rückbuchung erfolgt je Rechnung mit Vorzeichenwechsel und Multiplikation mit `CurrencyFactor`; die Verknüpfung zur Rechnung (`RechKopfI3D`) ist nullable und nicht fremdschlüsselgesichert.
+Ergebnis: Ohne Recht erfolgt Abbruch mit `RightCheckFailed`; mit Recht werden Rechnungszahlstatus und Zahlungsegangsätze konsistent zurückgeführt, sofern `RechKopfI3D` gepflegt ist — andernfalls entstehen Zahlungen ohne Rechnungsbezug, die durch kein DB-Constraint verhindert werden.
+Belege: PRIMÄR – `src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs:43-44, 62-71, 75` (Wortlaut im Lauf geprüft). PRIMÄR – `SSMS_DB_SCHEMA.sql:17604-17623`, `Zahlungseingang` ohne FK, `RechKopfI3D NULL` (Constraint als durchgesetzte Regel: fehlender FK = erlaubte Referenzlosigkeit).
+Prüfidee: (1) Löschen ohne Recht → Fehlercode prüfen; (2) Zahlungseingang mit `RechKopfI3D = NULL` speichern → Speichern gelingt, Auswertung in offenen Posten prüfen; (3) Fremdwährungsrechnung: Rückbuchungsbetrag gegen `CurrencyFactor` nachrechnen.
+Tracelinks: SyRS:Zahlungseingang, SyRS:Rechteverwaltung, StRS:Abrechnung, StRS:Rechteverwaltung; SwRS-6, SwRS-9, SwRS-16
+Konsolidierung: Kandidat – „eingehende Zahlung" wird doppelt gehalten: `Zahlungseingang` (FK-frei, `PaymentsBL`) und `PaymentTransactionBL`-Datenhaltung (M005, siehe SwRS-6); im Zielsystem zu einem Zahlungsmodell zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-9
+Titel: Mahnstufen-Statusmaschine des Mahnlaufs
+Ebene: SwRS
+Typ: Funktionsanforderung (Statusmaschine, Abrechnung)
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit
+Akteur: `DunningRunBL`
+Vorbedingung: Mahnfähige Rechnung im Zustand `DunningLevel.None|Level1|Level2`
+Fakt: `switch (invoice.DunningLevel)` mit `case DunningLevel.None: invoice.DunningLevel = DunningLevel.Level1; invoice.DunningLevel1Date = DateTime.Now; invoice.DunningLevel1Employee = loggedInUser.UserI3D; break;` usw. bis `Level2 → Level3`, und `default: throw new ArgumentOutOfRangeException;`, Abschluss `this._repository.SaveInvoice(invoice);` (DunningRunBL.cs:248-275).
+Aussage: Der Mahnlauf erhöht die Stufe genau um eine Stufe und schreibt je Stufe Datum und Bearbeiter-I3D; ein bereits auf `Level3` stehender Satz führt zur Ausnahme, nicht zu einer vierten Mahnung.
+Ergebnis: Mahnstufen sind monoton und lückenlos; Mehrfachmahnen auf Stufe 3 bricht technisch sichtbar ab. Stammdaten-seitige Grenzwerte (`DunningLetterAfterDays1..3`, `LockOrderAfterDunningLevel`, SSMS_DB_SCHEMA.sql:3698-3701) werden von dieser Maschine nicht ausgewertet.
+Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs`, `UpdateInvoice`, Zeilen 248-275, Wortlaut im Lauf geprüft. KONTEXT – Schemaspalten `DunningLetterAfterDays1/2/3`, `LockOrderAfterDunningLevel` (SSMS_DB_SCHEMA.sql:3698-3701).
+Prüfidee: Rechnung auf `Level3` setzen und erneuten Mahnlauf fahren → `ArgumentOutOfRangeException` erwarten; Stufenfolge 0→1→2→3 mit Datums-/Bearbeiterprüfung.
+Tracelinks: SyRS:Mahnwesen, StRS:Debitorenbetreuung; SwRS-8, SwRS-23
+Konsolidierung: kein Fall im Modul; verwandt aber andersartig: die Helpdesk-Eskalation (SwRS-22/SwRS-23) ist ein zweiter Stufenmechanismus für einen anderen Gegenstand (Tickets, nicht Rechnungen) — kein Zusammenführungsfall.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-10
+Titel: Pflichtfelder der Kampagnen-Persistenz
+Ebene: SwRS
+Typ: Datenanforderung / Constraint
+Qualitätsmerkmal: Vollständigkeit, Konsistenz
+Akteur: `CampaignBL`
+Vorbedingung: Kampagne wird angelegt oder geändert
+Fakt: Faktenbasis M008 verweist auf `CampaignBL` Zeilen 30-47 und auf das Schema `Campaigns` mit NOT-NULL-Feldern.
+Aussage: Die Kampagnenkomponente erzeugt/prüft Kampagnensätze vor der Persistenz anhand der in Zeilen 30-47 hinterlegten Vorgaben; die数据库seitige Pflichtigkeit wird zusätzlich durch NOT-NULL-Constraints der Tabelle `Campaigns` erzwungen.
+Ergebnis: Unvollständige Kampagnen scheitern entweder in der BL-Prüfung oder am Datenbankconstraint; die zweite Stufe greift auch bei Direktzugriffen.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz wörtlich übernommen; Feldliste im Lauf nicht extrahiert) – `CampaignBL.cs:30-47`, Schema `Campaigns` (M008).
+Prüfidee: Kampagne mit fehlenden Pflichtfeldern per BL und per Direkt-SQL anlegen; beide Ablehnungswege prüfen.
+Tracelinks: SyRS:Kampagnenverwaltung, StRS:Marketing
+Konsolidierung: kein Fall – keine zweite Kampagnenhaltung belegt.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - konkrete Feldliste nachliefern
+Status: HYPOTHESE
+
+ID: SwRS-11
+Titel: Neuberechnung des Vertragsendes inkl. Kündigungs-Kappung und Iterationsgrenze
+Ebene: SwRS
+Typ: Funktionsanforderung (Berechnungsvorschrift, Abrechnung)
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit, Robustheit
+Akteur: `ContractBL.RefreshContractEndeDate` (Webservice-getrieben)
+Vorbedingung: Verträge mit `Status == 1`
+Fakt: `firstEndDate = GetNewDate(contract.Beginn.Value, contract.LaufzeitArt.Value, contract.LaufzeitDauer.Value)` (ContractBL.cs:1093); bei `AutoVerlaengerung == 0` gilt `newEndDate = firstEndDate` (Zeile 1097); bei `Verlaengerung == 0` gilt `if (contract.KuendigungsDatum > new DateTime(2000, 01, 01)) newEndDate = contract.KuendigungsDatum;` (Zeile 1103); Verlängerungsschleife `while (newEndDate == null) { … if (termination >= DateTime.Today) newEndDate = secondEndDate; else secondEndDate = GetNewMonthDate(secondEndDate, contract.Verlaengerung.Value); i++; if (i == 100) break; }` (Zeilen 1117-1128); Kappung `if (contract.KuendigungsDatum != null && contract.KuendigungsDatum > new DateTime(2000, 01, 01) && newEndDate > contract.KuendigungsDatum) newEndDate = contract.KuendigungsDatum;` (Zeile 1132); unvollständige Basisdaten werden übersprungen und zur ToDo-Bereinigung vorgemerkt (Zeilen 1086-1090); Änderung wird protokolliert: `$"Vertragsende wurde von Webservice auf '{dt}' gesetzt"` (Zeile 1145).
+Aussage: Die Komponente berechnet das Vertragsende aus Beginn/Laufzeit, verlängert in Verlaengerungsschritten bis zum Kündigungsfrist-Fenster, begrenzt die Suche auf 100 Iterationen und kappt jedes Ergebnis auf ein vorhandenes Kündigungsdatum, sofern dieses nach dem 01.01.2000 liegt.
+Ergebnis: `VertragKopf.Ende` ist nach dem Lauf höchstens das Kündigungsdatum; Sätze ohne `Beginn`/`LaufzeitArt`/`LaufzeitDauer` bleiben unverändert, werden aber zur ToDo-Abstimmung erfasst; nach 100 Schritten ohne Treffer bleibt `Ende` unverändert (kein Ende geschrieben).
+Belege: PRIMÄR – `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs`, `RefreshContractEndeDate`, Zeilen 1067-1150 mit wörtlich zitierten Formeln/Kappungen (im Lauf geprüft).
+Prüfidee: Vier Verträge konfigurieren: ohne Autoverlängerung; Autoverlängerung ohne Verlängerungsdauer mit Kündigungsdatum; Autoverlängerung mit `KuendigungsFristArt1/2`; Extremfall, in dem 100 Schritte nicht genügen — Ergebnisse gegen die zitierten Formeln nachrechnen.
+Tracelinks: SyRS:Vertragsabrechnung, SyRS:Vertragsende-Ermittlung, StRS:Abrechnung; SwRS-12, SwRS-31
+Konsolidierung: Kandidat – Frist-/Verlängerungslogik ist zusätzlich in SQL-Skripten als ableitende Fallunterscheidung codiert (`WHEN A.Stammblattbezogen = 1 AND A.KontingentVertrag = 1 THEN 3 …`, SQLScriptCollection4.xml:936-938 u. a. — dieselbe Zuordnung in über zehn Skriptkopien); im Zielsystem Fachregel je einmal (Code oder View) realisieren.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-12
+Titel: Zählerfortschreibung der Gerätezähler mit Monotoniesicherung und funktionslosen Stub-Methoden
+Ebene: SwRS
+Typ: Funktionsanforderung (Abrechnungsvorleistung) + Implementierungshinweis
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit
+Akteur: `DeviceClickCounterBL` (Click-Contracts)
+Vorbedingung: Importierter Zählerstand liegt vor; Mapping auf Gerätezähler existiert
+Fakt: Monotonieschutz: `if (clickCounter.CurrentCounter > unassignedClicks.CounterValue) { return Result.AsError("old counter value is higher as the new one"); }` dann `oldCounterValue = clickCounter.CurrentCounter; clickCounter.CurrentCounter = unassignedClicks.CounterValue;` (DeviceClickCounterBL.cs:250-257). Stub: `public Result TransmitUnassignedClickCountersToDeviceClickCounter(...) { … //return SaveClickCounter(counters, currUser, isAutomatic);w  return null; }` (Zeilen 87-99) und `public DeviceClickCounterTypeMapping GetMappingCouterKind(string code) { return null; … }` (Zeilen 106-110). Zähler hängen am Stammblatt: `GetClickCounterFromMasterDataListId(int masterDataListId) → GetList(f => f.DeviceHeaderI3D == masterDataListId)` (Zeilen 82-85).
+Aussage: Ein neuer Zählerstand wird nur übernommen, wenn er nicht unter dem gespeicherten liegt; die Sammelübertragung und die Zählerart-Zuordnung sind aktuell als Rumpf implementationen ohne Funktionalität ausgeführt (`return null`), wodurch nachgelagerte Prüfungen (`GetMappingCouterKind(...) != null`, Zeile 176) stets ins Leere laufen.
+Ergebnis: Einzelzähler bleiben monoton; die automatische Übertragung liefert `null` statt eines `Result`, und Zählerart-Filter entfernen keine Einträge — Zählerstände erreichen die Abrechnung nur über verbleibende Einzelfälle.
+Belege: PRIMÄR – `src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/DeviceClickCounterBL.cs:82-85, 87-99, 106-110, 176, 250-257` (Wortlaut im Lauf geprüft).
+Prüfidee: Kleineren als gespeicherten Zähler senden → Fehlermeldung erwarten; `TransmitUnassignedClickCountersToDeviceClickCounter` aufrufen → `null`-Rückgabe dokumentieren und Aufruferverhalten prüfen.
+Tracelinks: SyRS:Click-Abrechnung, SyRS:Zaehleruebernahme, StRS:Abrechnung; SwRS-11, SwRS-45
+Konsolidierung: Kandidat (Geräte-/Hardwarehaltung, Fall (a)): Zähler werden am „Stammblatt" geführt — `DeviceHeaderI3D` wird mit `masterDataListId` gleichgesetzt (Zeilen 82-84; Begriffsprägung `case CentronObjectKindNumeric.MasterDataListClass: return "Stammblatt";`, CentronObjectKindNumeric.cs:314) — während Drucker- bzw. Gerätebestandsdaten zusätzlich in `AssetManagementPrinter`/`AssetManagementDevices` gehalten werden; zwei Haltungen für denselben Gegenstand (siehe SwRS-45).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - abrechnungsrelevant
+Status: belegt
+
+ID: SwRS-13
+Titel: Rücksetzung (Revert) von Sprache und Währung in der Adresskomponente
+Ebene: SwRS
+Typ: Funktionsanforderung (interne Regel)
+Qualitätsmerkmal: Richtigkeit, Konsistenz
+Akteur: `AccountAddressBL`
+Vorbedingung: Änderung der sprach-/währungsbezogenen Kontodaten
+Fakt: Faktenbasis M011 verweist für Sprache/Währungs-Revert auf `AccountAddressBL.cs:282-332` und auf die NOT-NULL-Felder der Kontotabelle.
+Aussage: Beim Verwerfen oder Ändern von Kontoadressdaten setzt die Komponente Sprache und Währung auf den Ausgangswert (bzw. Kontovorgabe) zurück; die Persistenz erzwingt die Pflichtfelder der Kontotabelle.
+Ergebnis: Adresssätze erscheinen nie ohne Sprache/Währung; abgeleitete Belegparameter bleiben konsistent.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz wörtlich übernommen, im Lauf nicht gegengeprüft) – `AccountAddressBL.cs:282-332`, Kontotabelle NOT NULL (M011).
+Prüfidee: Sprache/Währung ändern, Änderung verwerfen, Werte und Persistenz vergleichen.
+Tracelinks: SyRS:Kontoverwaltung, StRS:Stammdaten; SwRS-16
+Konsolidierung: kein Fall – keine zweite Revert-Logik für Sprache/Währung belegt.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - konkrete Rücksetzregel (Feldliste) fehlt
+Status: HYPOTHESE
+
+ID: SwRS-14
+Titel: Pflichtpersistenz beim Produktlebens Zyklus-Ende
+Ebene: SwRS
+Typ: Daten-/Constraintanforderung
+Qualitätsmerkmal: Vollständigkeit
+Akteur: `ProductLifecycleEndViewModel`, Schema (Zeile 46981)
+Vorbedingung: Artikel wird auf Lebenszyklus-Ende gesetzt
+Fakt: Faktenbasis M012 verweist auf `ProductLifecycleEndViewModel` Zeilen 522-540 und auf NOT-NULL-Felder im Schema an Zeile 46981.
+Aussage: Die Client-Komponente bereitet die fürs Lebenszyklus-Ende nötigen Felder auf und übergibt sie an die Persistenz, die die Werte NOT NULL erzwingt.
+Ergebnis: Ein Lebenszyklus-Ende ohne die Pflichtangaben wird datenbankseitig abgewiesen.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen wörtlich übernommen; Feldnamen nicht extrahiert) – `ProductLifecycleEndViewModel.cs:522-540`, `SSMS_DB_SCHEMA.sql:46981` (M012).
+Prüfidee: Pflichtfeld leer lassen → DB-Ablehnung prüfen; UI-Vorprüfung vergleichen.
+Tracelinks: SyRS:Artikel-Lebenszyklus, StRS:Artikelstamm; SwRS-41
+Konsolidierung: kein Fall.
+Übernahmewürdigkeit: übernehmen - niedrige Priorität - Feldliste fehlt
+Status: HYPOTHESE
+
+ID: SwRS-15
+Titel: Nummernkreisvergabe und Anfangszustand bei CRM-Projekten
+Ebene: SwRS
+Typ: Funktionsanforderung (interner Algorithmus)
+Qualitätsmerkmal: Richtigkeit, Prüfbarkeit
+Akteur: `CrmProjectBL.SaveCrmProject`
+Vorbedingung: Neues CRM-Projekt (`project.I3D == 0`), angemeldeter Benutzer
+Fakt: `if (isNew) { project.Number = this._numberGroupBL.GetNextNumber(NumberGroupEnum.CRMProject, updateDatabase: true, currentEmployee: currentUser.Employee); project.State = 1; … }` (CrmProjectBL.cs:115-119); Guards: `Guard.NotNullOrWhiteSpace(project.Name, …)`, `Guard.NotLessOrEqualThan(project.ProjectKindI3D, 0, …)` (Zeilen 109-110); die gesamte Änderung läuft in `this.Session.WithTransaction(...)` (Zeile 112).
+Aussage: Neue CRM-Projekte erhalten ihre Nummer ausschließlich über den Nummernkreis `NumberGroupEnum.CRMProject` mit immediate Database-Update und starten softwareintern im Zustand `State = 1`; Änderungsversion und Erzeugermetadaten werden aus der Baugruppe abgeleitet.
+Ergebnis: Nummer und Anfangszustand sind deterministisch und transaktional gesichert; ein direkter Zahlenvergleich `project.Number` gegen Zählerstände ist zulässig (Referenzzähler gemäß Faktenbasis Zeile 363).
+Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Customers/CrmProjects/CrmProjectBL.cs:105-124` (Wortlaut im Lauf geprüft). KONTEXT – Faktenbasis M013 für den Referenzzähler (Zeile 363).
+Prüfidee: Zwei Projekte parallel anlegen (Nummern lückenlos/eindeutig); `State` nach Anlage prüfen; Transaktionsabbruch (Guards) ohne Nummerverbrauch testen.
+Tracelinks: SyRS:Projektanlage-CRM, StRS:Vertriebssteuerung; SwRS-19
+Konsolidierung: kein Fall – Nummernkreis wird zentral über `NumberGroupEnum` vergeben; Abweichungen betreffen andere Nummernkreise, nicht denselben Gegenstand.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-16
+Titel: Zweistufige Nettopreisberechnung mit AwayFromZero-Rundung
+Ebene: SwRS
+Typ: Funktionsanforderung (Preisformel, Preis/Abrechnung)
+Qualitätsmerkmal: Genauigkeit, Richtigkeit
+Akteur: `ReceiptPriceHelper.CalculateNetPrice` (WebServices.Core)
+Vorbedingung: Basispreis, Genauigkeitsstelle, Rabatt, Währungsfaktor, Fremdwährungskennzeichen liegen vor
+Fakt: Wörtlich: `if (currencyFactor == 0) currencyFactor = 1;` · `var basePriceWithCurrencyFactor = basePrice * (isForeignCurrency ? currencyFactor : 1);` · `var roundedBasePrice = Math.Round(basePriceWithCurrencyFactor, precision, MidpointRounding.AwayFromZero);` · `var withDiscount = roundedBasePrice * ((100 - discount) / 100);` · `var result = Math.Round(withDiscount, precision, MidpointRounding.AwayFromZero);` (ReceiptPriceHelper.cs:202-213).
+Aussage: Der Nettopreis wird zweistufig ermittelt: erst Währungsumrechnung mit anschließender Rundung auf `precision`, dann Rabattabzug mit zweiter Rundung; ein Währungsfaktor 0 wird intern als 1 behandelt.
+Ergebnis: Das Rundungsergebnis hängt von der Reihenfolge „Rundung vor Rabatt" ab und kann von einer einstufigen Berechnung um eine Genauigkeitsstelle abweichen; Teilung durch 0 ist ausgeschlossen.
+Belege: PRIMÄR – `src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs`, `CalculateNetPrice`, Zeilen 202-213, Formel wörtlich zitiert (im Lauf geprüft).
+Prüfidee: Goldene Werte für `precision = 2`, `discount = 33,33 %`, `currencyFactor = 0` und Fremdwährung erzeugen; gegen einstufige Referenzrechnung differieren lassen; Rounding-Mode-Grenzwert (0,005) testen.
+Tracelinks: SyRS:Preisformel, StRS:Preisbildung; SwRS-17, SwRS-19, SwRS-31
+Konsolidierung: Kandidat – parallele Rundungs-/Preislogik: dieselbe Preismechanik existiert zusätzlich in der SQL-Skriptsammlung (z. B. Preisspalten-Ableitungen in den Beleg-Skripten) und im Kontext `AngKopf`/`ReceiptPos`; Ziel: eine Preisberechnungsinstanz. Abgrenzung: SwRS-17 ist derselbe Sachverhalt auf derselben Ebene, aber anderer Rechenschritt (MwSt.), daher kein Doppel, sondern Ergänzung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - preisbestimmend
+Status: belegt
+
+ID: SwRS-17
+Titel: MwSt-Aufgruppierung mit CH-Rundung auf 0.05
+Ebene: SwRS
+Typ: Funktionsanforderung (Abrechnung)
+Qualitätsmerkmal: Genauigkeit, Richtigkeit
+Akteur: `ReceiptPriceHelper.CalculateReceiptVatPrices`
+Vorbedingung: Belegpositionen mit `Kind`, `ArticlePositionKind`, `Expanded == null`, Steuersatz
+Fakt: Filter: `var validItemKinds = new[] { ReceiptItemKind.Article, ReceiptItemKind.CustomerDiscount };` · `validItemArticlePositionKinds = new[] { ReceiptItemArticlePositionKind.Default, ReceiptItemArticlePositionKind.Cargo };` · `.Where(f => f.Expanded == null)`; Gruppierung `group item by item.TaxRate` mit `TaxPrice = Math.Round(g.Sum(f => f.TaxPriceTotal), 2, MidpointRounding.AwayFromZero)` und `NotDiscountableNetPriceFC = g.Where(f => f.Item.NoEarlyPaymentDiscountAllowed).Sum(...)` (ReceiptPriceHelper.cs:61-95). Schweizer Rundung: `… - (switzerlandRounding == false ? 0m : netPriceSum + taxPriceSum - Math.Round((netPriceSum + taxPriceSum) / 0.05m, 0) * 0.05m)` (ReceiptPriceHelper.cs:37, analog 39, 41).
+Aussage: Nur Artikel- und Kundendruckerpositionen der Positionstypen Default/Cargo und nicht aufgeklappte Positionen fließen in die MwSt-Aufteilung ein; die Steuerbeträge werden je Steuersatz summiert, auf 2 Stellen AwayFromZero gerundet und bei aktivierter CH-Rundung zusätzlich auf das 0.05-Raster abgebildet; nicht skontofähige Beträge werden separat über `NoEarlyPaymentDiscountAllowed` ausgewiesen.
+Ergebnis: Die Belegsummen sind je Steuersatz prüfbar und CH-konform gerastert; ausgefilterte Positionen (z. B. aufgeklappte) tauchen in keiner MwSt-Gruppe auf.
+Belege: PRIMÄR – `ReceiptPriceHelper.cs:61-95` (Filter/Gruppierung, Wortlaut im Lauf geprüft) und `ReceiptPriceHelper.cs:37, 39, 41` (0.05-Rundungsformel wörtlich).
+Prüfidee: Beleg mit gemischten Steuersätzen und einer Position `NoEarlyPaymentDiscountAllowed = true` rechnen; CH-Rundung an-/abschalten; Summenkontrolle Brutto = Netto + Steuer nach Rasterung.
+Tracelinks: SyRS:MwSt-Aufteilung, SyRS:Preisformel, StRS:Abrechnung; SwRS-16, SwRS-18
+Konsolidierung: Kandidat – CH-Rundungsformel ist dreifach als ausformulierte Zeile innerhalb derselben Methode wiederholt (Zeilen 37, 39, 41) und zusätzlich in Skript-Views angelegt; zu einer Rundungsfunktion zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-18
+Titel: Nicht unterstützte MwSt-Übernahme bei Gutschriften
+Ebene: SwRS
+Typ: Funktionsanforderung (Ausnahmebehavior, Abrechnung)
+Qualitätsmerkmal: Vollständigkeit, Zuverlässigkeit
+Akteur: `*SpecificLogic.CanBeForwardedFrom/Into`, `CreditVoucher.TakeoverVAT`
+Vorbedingung: Weiterleitung/Übernahme von Belegdaten auf Gutscheinbeleg
+Fakt: Faktenbasis M014: „CanBeForwardedFrom/Into je *SpecificLogic; CreditVoucher TakeoverVAT throws NotSupportedException".
+Aussage: Die Weiterleitungsfähigkeit wird je Belegart in eigenen `*SpecificLogic`-Implementierungen entschieden; die MwSt-Übernahme ist für `CreditVoucher` bewusst nicht implementiert und wirft `NotSupportedException`.
+Ergebnis: Ein Versuch, MwSt-Beträge auf einen Gutschein zu übernehmen, bricht technisch sichtbar ab, statt falsche Beträge zu erzeugen.
+Belege: KONTEXT/PRIMÄR (durchsetzende Stelle laut Faktenbasis M014; Klassenname/Zeile im Lauf nicht verifiziert) – `[HYPOTHESE]` bezüglich exakter Aufrufkette: Die抛出-Stelle wurde in diesem Lauf nicht aufgesucht.
+Prüfidee: `TakeoverVAT` auf `CreditVoucher` aufrufen → `NotSupportedException` erwarten; `CanBeForwardedFrom/Into` je Belegart matrixartig durchfahren.
+Tracelinks: SyRS:Belegweiterleitung, StRS:Abrechnung; SwRS-17
+Konsolidierung: Kandidat (Verdacht) – je Belegart separate `*SpecificLogic`-Klassen für dieselbe fachliche Frage „darf dieser Beleg fortgeleitet werden"; Zusammenführung in eine规则tabelle/Strategie prüfen.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Belegstelle nachziehen
+Status: HYPOTHESE
+
+ID: SwRS-19
+Titel: Nullbare Preisspalten im Angebotskopf (Widerspruch zur Faktenbasis)
+Ebene: SwRS
+Typ: Constraint-/Datenanforderung (Preis)
+Qualitätsmerkmal: Konsistenz, Richtigkeit
+Akteur: Tabelle `AngKopf`, Mapping `AngKopfMaps`
+Vorbedingung: Angebot wird persistiert
+Fakt: Schema: `[Netto] [float] NULL,` `[Brutto] [float] NULL,` `[SummeEK] [float] NULL,` `[Status] [int] NULL,` (SSMS_DB_SCHEMA.sql:3882 ff., CREATE ab Zeile 3882). Mapping: `Map(m => m.Netto).Column("Netto").Nullable;` · `Map(m => m.Brutto).Column("Brutto").Nullable;` · `Map(m => m.SummeEK).Column("SummeEK").Nullable;` · `Map(m => m.Status).Column("Status").Nullable;` (AngKopfMaps.cs:85-87, 74). Eine Suche nach `DEFAULT … FOR [dbo].[AngKopf]` liefert keinen Treffer.
+Aussage: Angebotskopf-Preissummen und Status sind softwareintern nullbar und haben weder NOT NULL noch DEFAULT 0; die Angebotskopfsummen können daher ohne Werte persistiert werden.
+Ergebnis: Auswertungen müssen NULL-Summen behandeln; die in der Faktenbasis angenommene Default-0-Regel ist nicht durchgesetzt (Konsistenz nur über die Berechnungslogik aus SwRS-16/SwRS-17).
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:3882 ff.` (Spaltendefinitionen, im Lauf gelesen) und `src/backend/Centron.DAO/Mappings/TemporaryEntities/AngKopfMaps.cs:74, 85-87` (Wortlaut im Lauf gelesen). CONTRA – Faktenbasis M014 („AngKopf Preisspalten NOT NULL DEFAULT 0") ist durch Schema und Mapping widerlegt.
+Prüfidee: INSERT in `AngKopf` ohne Preisspalten → Erfolg statt Fehler 0 erwarten; Auswertungsberichte auf NULL-Toleranz prüfen.
+Tracelinks: SyRS:Angebotserfassung, SyRS:Preisformel, StRS:Preisbildung; SwRS-15, SwRS-16
+Konsolidierung: kein Fall – die Nullbarkeit ist ein Datenmodell-Sachverhalt; die Parallele zu SwRS-16 ist Ebenen-/Aspektbeziehung (Tracelink), keine Doppelimplementierung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Factsheet-Korrektur erforderlich
+Status: HYPOTHESE
+
+ID: SwRS-20
+Titel: Zusatzfelder: NOT-NULL-Default im Schema, Pflichtprüfung nur im Client
+Ebene: SwRS
+Typ: Constraint-/Funktionsanforderung
+Qualitätsmerkmal: Vollständigkeit, Konsistenz, Sicherheit (Regeldurchsetzung)
+Akteur: `ModuleCustomPropertyBL`, `CustomPropertiesGridViewModel`, Tabelle `ModuleCustomProperties`
+Vorbedingung: Zusatzfeldstruktur wird gepflegt; Werte werden in der Maske bearbeitet
+Fakt: Schema: `[IsMandatory] [bit] NOT NULL,` (SSMS_DB_SCHEMA.sql:44404) mit `ALTER TABLE [dbo].[ModuleCustomProperties] ADD CONSTRAINT [DF_ModuleCustomProperties_IsMandatory] DEFAULT ((0)) FOR [IsMandatory]` (Zeile 67071). Strukturprüfung im BL: `if (properties.Any(property => String.IsNullOrWhiteSpace(property.Name))) return Result.AsError("At least one of the properties got no name.");` · `if (properties.Any(property => property.DataType == CustomizationDataTypes.Unknown)) return Result.AsError("At least one of the properties got a unknown datatype");` (ModuleCustomPropertyBL.cs:40-47). Pflichtwertprüfung ausschließlich im Client: `foreach (var item in Properties.Where(f => f.IsMandatory)) { … messageBuilder.AppendLine(...) }` in `CheckMandatoryProperties` (CustomPropertiesGridViewModel.cs, Zeilen ca. 218-240).
+Aussage: Die Pflichtfeld-Eigenschaft ist datenbankseitig mit Default 0 belegt, die inhaltliche Pflichtprüfung (`IsMandatory` ⇒ Wert vorhanden) liegt allein in der Client-Komponente; die BL-Prüfung kontrolliert nur Name und Datentyp der Felddefinition.
+Ergebnis: Über Webservice, Import oder Direkt-SQL können Pflichtfelder unbefüllt bleiben; die Regel gilt nur im interaktiven Weg.
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:44404` und `:67071` (Constraint/Default als durchgesetzte Regel). PRIMÄR – `src/backend/Centron.BL/Administration/Customization/ModuleCustomPropertyBL.cs:40-47` (Wortlaut im Lauf geprüft). PRIMÄR – `src/shared/Centron.Controls/CustomProperties/CustomPropertiesGrid/CustomPropertiesGridViewModel.cs`, `CheckMandatoryProperties` (einzige Prüfstelle, im Lauf geprüft).
+Prüfidee: Pflichtfeld definieren, Wert per Direkt-SQL/Webservice leer lassen und Speichern prüfen; Clientweg mit leerem Wert → Meldung erwarten.
+Tracelinks: SyRS:Zusatzfelder, StRS:Anpassbarkeit
+Konsolidierung: kein Fall – es existiert nur eine Prüfimplementierung; der fehlende BL-Gegenpart ist eine Lücke, keine zweite Umsetzung.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-21
+Titel: Weiche und harte Löschung von UI-Profilen
+Ebene: SwRS
+Typ: Funktions-/Datenanforderung (Statusmaschine)
+Qualitätsmerkmal: Konsistenz, Nachvollziehbarkeit
+Akteur: `UiProfileBL`, Tabellen `CentronUiProfiles`
+Vorbedingung: Benutzerprofil existiert und ist zugeordnet
+Fakt: Faktenbasis M016 benennt Constraints der `CentronUiProfiles` sowie soft-/hard-delete-Verhalten in `UiProfileBL.cs`.
+Aussage: Die Profilkomponente unterscheidet logische Löschung (Satz bleibt mit Löschkennzeichen erhalten) und physische Löschung; die Schema-Constraints begrenzen die Kombination zulässiger Profildaten.
+Ergebnis: Gelöschte Profile bleiben für Zuordnungen referenzierbar bzw. werden entfernt; Verstöße gegen die Schema-Constraints scheitern persistenzseitig.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen übernommen; Constraint-Namen im Lauf nicht einzeln enumeriert) – `UiProfileBL.cs`, Schema `CentronUiProfiles` (M016).
+Prüfidee: Profil soft-delete, Referenztest; hard-delete mit bestehender Referenz → Constraint-Verhalten prüfen.
+Tracelinks: SyRS:Benutzerprofile, StRS:Benutzerverwaltung
+Konsolidierung: kein Fall.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - Constraintliste nachziehen
+Status: HYPOTHESE
+
+ID: SwRS-22
+Titel: Eskalationsstufenermittlung und Roh-SQL-Rückschreibung auf Helpdesk-Tickets
+Ebene: SwRS
+Typ: Funktionsanforderung (Status-/Eskalationslogik, interne Roh-SQL)
+Qualitätsmerkmal: Richtigkeit, Sicherheit (SQL-Kapselung)
+Akteur: `EscalationBL`
+Vorbedingung: Eskalationssatz mit `WaitHourEsc1..3`, Wochentagsaktivierung, Tickets mit ToDoListe-Verknüpfung
+Fakt: Stufenermittlung: `if (escItem.WaitHourEsc1 == null && escItem.WaitHourEsc2 == null && escItem.WaitHourEsc3 == null) return 0;` · `if (nowDt.DayOfWeek == DayOfWeek.Saturday && !escItem.IsSaturdayActive) return 0;` (analog Sonntag), Stufenprüfung `ShouldEscalated(escItem, 1|2|3)` mit Rückgabe 1/2/3 (EscalationBL.cs:393-426). Rückschreibung: `$@"Update hr Set EscalationLevel = {escItem.Stage} From hlpdsk_requests hr Inner join ToDoListe tdl on tdl.ObjektArt = {(int)CentronObjectKindNumeric.HelpdeskClass} and tdl.ObjectI3D = hr.I3D Inner join Eskalationen e on e.ObjektI3D = tdl.I3D and e.ObArt = 2 Where e.I3D = {escItem.EscI3D}"` und `ExecuteNonQueryTransactionSave` (EscalationBL.cs:913-921); Stempelfeld: `$"Update Eskalationen SET Eskalation{escItem.Stage}AM = GetDate WHERE I3D = {escItem.EscI3D}"` (Zeilen 923-929).
+Aussage: Die Eskalationskomponente ermittelt die Zielf stufe aus Wartezeiten und Wochentagsfreigaben und schreibt sie per interpolierter Roh-SQL in `hlpdsk_requests.EscalationLevel`; die betroffenen Spaltennamen (`Eskalation{Stage}AM`) werden per String-Komposition gebildet.
+Ergebnis: Eskalationsstände bleiben außerhalb des ORM gepflegt; die SQL-Stellen sind Interpolationsangriffspunkte (auch wenn die eingesetzten Werte intern erzeugt sind) und die Spaltendynamik entzieht sich statischer Prüfung.
+Belege: PRIMÄR – `src/backend/Centron.BL/Sales/Support/Escalation/EscalationBL.cs`, `CheckEskalationStage` Zeilen 393-426, `UpdateTicket`/`UpdateEscalations` Zeilen 913-929, SQL wörtlich zitiert (im Lauf geprüft). KONTEXT – Faktenbasis M017 zu `HelpdeskBL.cs:569-578`.
+Prüfidee: Eskalation mit nur Stufe 1 gefüllt und Samstagsmodus deaktiviert testen; `EscalationLevel`-Schreibfluss gegen `hlpdsk_requests.EscalationLevel DEFAULT ((0))` (Schema Zeile 66985) verifizieren; SQL-Interpolation auf Parametrisierung prüfen.
+Tracelinks: SyRS:Ticket-Eskalation, StRS:Helpdesk-SLA; SwRS-23, SwRS-1
+Konsolidierung: Kandidat (fall (d)) – Zwei parallele Eskalationsmechanismen: (1) `Escalationen`-Tabelle mit `WaitHourEsc1..3`/`Eskalation{n}AM` und `hlpdsk_requests.EscalationLevel` (EscalationBL) und (2) prioritätsbasierte Felder in `hlpdsk_prioritaeten` (`EskalationSa`, `EskalationSo`, `FaeligkeitVerzoegerung`, `IsSLA`), siehe SwRS-23. Derselbe fachliche Gegenstand „Eskalation/SLA" wird in zwei getrennten Implementierungen geführt; Zusammenführung erforderlich.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-23
+Titel: Prioritätsstammblatt als zweiter Eskalations-/SLA-Datenträger
+Ebene: SwRS
+Typ: Datenanforderung / Mapping
+Qualitätsmerkmal: Konsistenz
+Akteur: Tabelle `hlpdsk_prioritaeten`, Helpdesk-Komponenten
+Vorbedingung: Helpdesk-Prioritäten sind gepflegt
+Fakt: Schema: `CREATE TABLE [dbo].[hlpdsk_prioritaeten]( [I3D] … [Werktage] [float] NULL, [Stunde2] [float] NULL, [Stunde3] [float] NULL, … [EskalationSa] [int] NULL, [EskalationSo] [int] NULL, [GeschaeftsZeitVon] [datetime] NULL, [GeschaeftsZeitBis] [datetime] NULL, … [FaeligkeitVerzoegerung] [float] NULL, [IsSLA] [bit] NULL, …)` (SSMS_DB_SCHEMA.sql:4485-4514). Ticketseitig: `[EscalationLevel] [int] NOT NULL,` mit `CONSTRAINT [DF_hlpdsk_requests_EscalationLevel] DEFAULT ((0)) FOR [EscalationLevel]` (SSMS_DB_SCHEMA.sql:66985).
+Aussage: Eskalations- und SLA-Parameter (Wochenendverhalten, Fälligkeitsverzug, SLA-Kennzeichen) werden im Prioritätsstammblatt gepflegt, während der Eskalationslauf seine Stufen über `Escalationen`/`hlpdsk_requests.EscalationLevel` führt; die NOT-NULL-/Default-Regel von `EscalationLevel` ist die einzige persistente Durchsetzung des Eskalationszustands.
+Ergebnis: Eskalationsdaten sind über zwei Modelle verteilt; Konsistenz zwischen Prioritäts-Eskalationswerten und Eskalationslauf wird durch kein Constraint gesichert.
+Belege: PRIMÄR – Schema-Constraints/-Spalten: `SSMS_DB_SCHEMA.sql:4485-4514` (Prioritätenfeldmenge), `:66985` (`DF_hlpdsk_requests_EscalationLevel DEFAULT ((0))`, `EscalationLevel int NOT NULL`), beide im Lauf gelesen.
+Prüfidee: Priorität mit `IsSLA = 1`, `EskalationSa` gesetzt, aber ohne `Escalationen`-Satz anlegen → Ticket bleibt auf `EscalationLevel = 0`; Abweichung melden.
+Tracelinks: SyRS:Ticket-Eskalation, StRS:Helpdesk-SLA; SwRS-22
+Konsolidierung: Kandidat (fall (d), Partner von SwRS-22) – `hlpdsk_prioritaeten`-Eskalationsfelder und `EscalationBL`/`Escalationen` bilden denselben fachlichen Gegenstand in zwei getrennten Implementierungen ab.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-24
+Titel: Validierung der Umlagerungs-Protokollsätze
+Ebene: SwRS
+Typ: Funktionsanforderung (Vorbedingungsprüfung, interne Regeln)
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit
+Akteur: `StockBL.WriteStockRebookLog`
+Vorbedingung: Umlagerungsprotokoll liegt an
+Fakt: Prüfkette wörtlich: `if (rebookLog == null) return Result.AsError("The log to write is empty");` · `if(rebookLog.ArticleI3D < 1) return Result.AsError("The article i3d is invalid");` · `if (rebookLog.Date == DateTime.MinValue) rebookLog.Date = DateTime.Now;` · `if(rebookLog.Employee == null) return Result.AsError("The employee is invalid");` · `if(rebookLog.FromStore == null) …` · `if(rebookLog.ToStore == null) …` Abschluss `return _warehouseRepository.WriteStockRebookLog(rebookLog);` (StockBL.cs:82-111).
+Aussage: Ein Umlagerungsnachweis wird nur geschrieben, wenn Artikel, Bearbeiter, Quell- und Ziellager gesetzt sind; ein fehlendes Datum wird ersatzlos auf „jetzt" gesetzt.
+Ergebnis: Unvollständige Umlagerungsnachweise werden abgewiesen; die Zeitachse des Nachweises kann durch die implizite Jetzt-Setzung von der tatsächlichen Bewegung abweichen.
+Belege: PRIMÄR – `src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs:82-111`, Prüfkettenwörtlich im Lauf gelesen.
+Prüfidee: Protokolle mit fehlendem Ziellager und mit `DateTime.MinValue` anlegen; Fehlerpfad und implizite Datumsetzung verifizieren.
+Tracelinks: SyRS:Lagerumlagerung, StRS:Lagerhaltung; SwRS-40, SwRS-32
+Konsolidierung: kein Fall.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-25
+Titel: Chat- und Tagesaufgabendatenhaltung
+Ebene: SwRS
+Typ: Datenanforderung
+Qualitätsmerkmal: Vollständigkeit
+Akteur: `ChatBL`, Tabelle `MyDayWorkItems`
+Vorbedingung: Chatnachrichten/Tagespositionen werden erzeugt
+Fakt: Faktenbasis M020 verweist auf `ChatBL.cs` Zeilen 112-505 und das Schema `MyDayWorkItems`.
+Aussage: Die Chatkomponente verwaltet Unterhaltungen und verknüpfte Tagespositionen über die eigene Datenhaltung; `MyDayWorkItems` liefert die Persistenzstruktur für Tagesaufgabensätze.
+Ergebnis: Chat- und Tagespositionsdaten sind softwareintern über diese beiden Haltungen abgebildet.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenzen übernommen, im Lauf nicht gegengeprüft) – `ChatBL.cs:112-505`, Schema `MyDayWorkItems` (M020).
+Prüfidee: Nachricht mit/ohne Tagesposition speichern; Lösch-/Archivverhalten prüfen.
+Tracelinks: SyRS:Kommunikation-Chat, StRS:Zusammenarbeit
+Konsolidierung: Kandidat (Verdacht) – Tagespositionen werden zusätzlich als Helpdesk-/ToDo-Objekte geführt (ToDoListe, vgl. SwRS-22); dieselbe fachliche Aufgabenhaltung in zwei Modulen; Verifizierung erforderlich.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-26
+Titel: Persistenzregeln der Online-Banking-Umsätze
+Ebene: SwRS
+Typ: Daten-/Funktionsanforderung (Abrechnungsdaten)
+Qualitätsmerkmal: Richtigkeit, Konsistenz, Sicherheit
+Akteur: `OnlineBankingAccountTransactionsBL`, Schema (Zeilen 45773-45888)
+Vorbedingung: Umsätze werden aus Bankdaten übernommen
+Fakt: Faktenbasis M021 verweist auf `OnlineBankingAccountTransactionsBL` Zeilen 163-360 und die zugehörigen Tabellen im Schema (Zeilen 45773-45888). Verifiziert ergänzend: Bankzugangsdaten werden verschlüsselt abgelegt, `hbciConfig.AccountUserPassword = new AESCryptoLogic.EncryptText(hbciConfig.AccountUserPassword, securityKey);` (OnlineBankingConfigurationBL.cs:141-148, analog Entschlüsselung Zeilen 158-165).
+Aussage: Die Umsatztzkomponente legt Kontobewegungen über ihre eigene Tabellenstruktur ab, während die Zugangsdaten (HBCI/FinAPI) verschlüsselt in der Konfigurationshaltung liegen.
+Ergebnis: Klartext-Zugangsdaten werden nicht persistiert; die Umsatzübernahme folgt den Regeln der genannten Methode.
+Belege: PRIMÄR – `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingConfigurationBL.cs:141-148, 158-165` (AES-Verschlüsselung, Wortlaut im Lauf geprüft). PRIMÄR (Referenz aus Faktenbasis, Methodenlogik nicht gegengeprüft) – `OnlineBankingAccountTransactionsBL.cs:163-360`, `SSMS_DB_SCHEMA.sql:45773-45888` (M021).
+Prüfidee: Umsatzübernahme doppelt ausführen (Duplikatschutz prüfen); Konfiguration lesen → Ciphertext in DB, Klartext in API prüfen.
+Tracelinks: SyRS:OnlineBanking, StRS:Zahlungsverkehr; SwRS-6
+Konsolidierung: Kandidat – zwei HBCI/FinAPI-Zugangshaltungen: HBCI- und FinAPI-Konfiguration in einem Datensatz mit je eigener Verschlüsselungsaufrufzeile (OnlineBankingConfigurationBL.cs:141-148); fachlich ein „Bankzugang", zwei Teilmodelle.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-27
+Titel: Kennwortverwaltung: leere Salt-/Kennwortwerte trotz NOT-NULL-Constraint
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Berechtigung, Sicherheit)
+Qualitätsmerkmal: Richtigkeit, Sicherheit
+Akteur: `PasswordManagementKeywordBL`, Tabelle `PasswordManagementKeyword`
+Vorbedingung: Benutzer legt ein neues Schlüsselwort an bzw. ruft es ab
+Fakt: Anlage: `keyword.Username = username; keyword.Salt = ""; keyword.Password = "";` (PasswordManagementKeywordBL.cs:46-48). Abruf: `// decryption` gefolgt von `return keyword.Password;` (Zeilen 27, 32) — es findet keine Entschlüsselung statt; Protokollschreibweise: `accessLogBl.SavePasswordManagementAccessLog(keyword.I3D, PasswordManagementActionTypeEnum.Create, user);` auch beim Abruf (Zeile 30). Schema: `[Salt] [nvarchar](128) NOT NULL, [Password] [nvarchar](128) NOT NULL,` (SSMS_DB_SCHEMA.sql:46142-46143).
+Aussage: Die Anlegefunktion speichert Salt und Kennwort als leere Zeichenkette und erfüllt damit formal das NOT-NULL-Constraint, ohne Wert zu liefern; der Abruf liefert den gespeicherten Rohtmppwert, kennzeichnet den Zugriff aber als „Create"-Aktion.
+Ergebnis: Schlüsselwörter sind nach dem Anlegen inhaltlich leer; Zugriffsprotokolle weisen Lesezugriffe als Erzeugung aus und sind als Nachweis nicht brauchbar.
+Belege: PRIMÄR – `src/backend/Centron.BL/PasswordManagementArea/PasswordManagementKeywordBL.cs:21-58`, Code wörtlich zitiert (im Lauf geprüft). PRIMÄR – `SSMS_DB_SCHEMA.sql:46138-46145` (NOT-NULL-Constraints als durchgesetzte Regel).
+Prüfidee: Keyword anlegen und DB-Werte prüfen; Abruf durchführen und Protokolldatensatz-Typ kontrollieren; NOT-NULL-Verletzung durch `NULL`-Einschub testen.
+Tracelinks: SyRS:Kennwortverwaltung, StRS:Rechteverwaltung; SwRS-47
+Konsolidierung: Kandidat – „Zugangsdaten aufbewahren" wird drittens implementiert: hier unverschlüsselt/leer in `PasswordManagementKeyword`, in MailScannern mit MasterKey (`MailScannerBL.cs:90-116`) und andernorts mit `AESCryptoLogic`-Default-Key (SwRS-47); ein Zielfachkonzept „Geheimnisspeicher" erforderlich.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant
+Status: belegt
+
+ID: SwRS-28
+Titel: Kostenträger-/Kostenstellen-Datenhaltung ohne Eindeutigkeitsregeln und doppelt angelegt
+Ebene: SwRS
+Typ: Daten-/Constraintanforderung
+Qualitätsmerkmal: Konsistenz, Vollständigkeit
+Akteur: Tabellen `Kostentraeger`, `Kostenstellen`, `Kostenstelle`, `KostenstellenBackup`; `ArticleBL` (Pflichteinstellungen)
+Vorbedingung: Kostenrechnungsstammdaten werden gepflegt
+Fakt: Schema: `CREATE TABLE [dbo].[Kostentraeger]( [I3D] … NOT NULL, [Nummer] [varchar](50) NULL, [Beschreibung] [varchar](255) NULL, [Status] [int] NULL, [NummerAlt] [varchar](50) NULL, PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:5673-5683); parallel `CREATE TABLE [dbo].[Kostenstellen]( [I3D] …, [KostentraegerI3D] [int] NULL, [Nummer] [varchar](50) NULL, … [ParentI3D] [int] NULL, …)` (Zeilen 5905-5920) und zusätzlich `CREATE TABLE [dbo].[Kostenstelle]( [I3D] …, [MandantI3D] [int] NOT NULL, [Kostenstelle] [int] NULL, [Bezeichnung] [varchar](50) NULL, [Status] [int] NULL, CONSTRAINT [PK_Kostenstelle] …)` (Zeilen 42139-42149) sowie `KostenstellenBackup` (Zeile 42174). Faktenbasis M023 ergänzt: Artikelseitige Kostenstellenpflicht über die Einstellungen 10168/10169 (`ArticleBL`).
+Aussage: Kostenträger- und Kostenstellennummern sind nullbar und ohne UNIQUE-Constraint; für Kostenstellen existieren zwei aktive Tabellen (Plural mit Hierarchie/Trägerbezug, Singular mit Mandantenbezug) plus eine Backuptabelle; die Pflichtangabe einer Kostenstelle für Artikel wird nicht persistent, sondern über Einstellungen gesteuert.
+Ergebnis: Doppelte oder leere Nummern sind zulässig; Auswertungen müssen zwei Kostenstellenhaltungen zusammenführen; die Artikelspflicht ist verlustig, wenn die Einstellungen 10168/10169 nicht ausgewertet werden.
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:5673-5683`, `:5905-5920`, `:42139-42149`, `:42174` (Tabellen-/Constraintlage, im Lauf gelesen; Abwesenheit von UNIQUE/FK ist damit belegt). KONTEXT – Faktenbasis M023 für `ArticleBL`/Einstellungen 10168-10169.
+Prüfidee: Zwei Kostenträger mit identischer `Nummer` anlegen (Erfolg erwarten); identische Kostenstellennummer in `Kostenstellen` und `Kostenstelle` und Auswertung prüfen; Einstellungen 10168/10169 ein-/ausschalten und Artikelspeicherung vergleichen.
+Tracelinks: SyRS:Kostenrechnung, StRS:Kostenrechnung; SwRS-29
+Konsolidierung: Kandidat (fall (b)-Verwandtschaft, eigenständiger Fall) – Doppelhaltung „Kostenstelle": `Kostenstellen` (plural, `KostentraegerI3D`/`ParentI3D`) vs. `Kostenstelle` (singular, `MandantI3D`) — zwei getrennte Implementierungen desselben Stammdatenobjekts, im Zielsystem auf eine Kostenstellenhaltung zu führen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-29
+Titel: UI-Begriff „Payers" für das Domänenobjekt Kostenträger
+Ebene: SwRS
+Typ: Namens-/Mappinanforderung (softwareinterne Begrifflichkeit)
+Qualitätsmerkmal: Konsistenz, Verständlichkeit
+Akteur: UI-Modul `PayersAndCostCenter`
+Vorbedingung: Modul „Kostenträger/Kostenstellen" wird geöffnet
+Fakt: Ribbonseite: `<dxr:RibbonPage Caption="Kostenträger" x:Name="PayersRibbonPage">` (PayersAndCostCenterAppModuleControllerView.xaml:34); `public async Task DoOpenAddPayers { var addCostCenterOrPayersViewModel = new AddCostCenterOrPayersViewModel("Kostenträger hinzufügen", this, true); … }` (PayersAndCostCenterAppModuleControllerViewModel.cs:231-234); Dialogverzweigung `if (this.PayersViewModel) { … this.PayersAndCostCenterAppModuleControllerViewModel?.CostObjectCollection.Add(costCentreDTO); } else { …CostCenterCollection.Add(costObjectDTO); }` (AddCostCenterOrPayersViewModel.cs:65-74).
+Aussage: Die Software führt für den Kostenträger intern die englische Bezeichnung „Payers" (inkl. „Zahler"-Wortform im Wörterbuch, de_DE.dic:403781) und sammelt Kostenträger in einer `CostObjectCollection`, während `AddCostCenterOrPayersViewModel` die Variablennamen `costCentreDTO`/`costObjectDTO` vertauscht einsetzt.
+Ergebnis: Domänenbegriff, Klassenbezeichnung und Füllrichtung der Sammlungen divergieren; Zuordnungsfehler in Wartung und Auswertung sind wahrscheinlich.
+Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerView.xaml:34`; `…/PayersAndCostCenterAppModuleControllerViewModel.cs:231-234`; `…/OpenDialog/AddCostCenterOrPayersViewModel.cs:51-74`; `src/centron/Centron.WPF.UI/Resources/Dictionaries/de_DE.dic:403781` („Zahler"), alle im Lauf gelesen.
+Prüfidee: Dialog „Kostenträger hinzufügen" öffnen und prüfen, in welche Collection der neue Satz wandert; Begriffsinventur (Payers/Zahler/Kostenträger/CostObject) im Quellcode auszählen.
+Tracelinks: SyRS:Kostenrechnung-UI, StRS:Kostenrechnung; SwRS-28
+Konsolidierung: Kandidat (fall (b)) – „Zahler/Payers" (UI-Schicht, `PayersAndCostCenter*`) und „Kostenträger" (Domäne/Tabelle `Kostentraeger`, SwRS-28) bezeichnen denselben fachlichen Gegenstand in zwei getrennten Implementierungen; einheitliches Vokabular und eine Haltung erforderlich.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Begriffsklärung nötig
+Status: belegt
+
+ID: SwRS-30
+Titel: Lizenz-Gate der Produktionsmodule
+Ebene: SwRS
+Typ: Constraint-/Zugriffsanforderung (Berechtigung/Lizenz)
+Qualitätsmerkmal: Sicherheit, Prüfbarkeit
+Akteur: `ProductionOrderBL`, `ProductionBL`, `ArticleProductionBL`
+Vorbedingung: Produktionsauftrag wird angelegt/geändert
+Fakt: Faktenbasis M024: Lizenz-Gate in `ProductionOrderBL`/`ProductionBL`/`ArticleProductionBL`. Vergleichbare, verifizierte Gate-Form: ` => LicenseManager.Instance.HasLicense(LicenseGuids.X) || LicenseManager.Instance.HasLicense(LicenseGuids.Centron)` (ModuleRegistration.cs:421-448).
+Aussage: Die Produktionskomponenten prüfen vor der Fachaktion eine Lizenz (Einzellizenz oder Sammel-Lizenz „Centron") und verweigern sonst.
+Ergebnis: Ohne Lizenz kein Produktionsdatensatz; das Gate wirkt auf BL-Ebene und zusätzlich im UI-Registrierungspfad.
+Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Methodennamen nicht gegengeprüft) – `ProductionOrderBL`, `ProductionBL`, `ArticleProductionBL` (M024). KONTEXT/PRIMÄR – `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs:421-448` (Gate-Muster im Lauf geprüft).
+Prüfidee: Lizenz entfer nen und BL-Aufruf direkt (ohne UI) testen; UI-Pfad gegen BL-Pfad vergleichen.
+Tracelinks: SyRS:Lizenzsteuerung, StRS:Lizenzierung;, SwRS-1
+Konsolidierung: kein Fall – dasselbe Gate-Muster, aber unterschiedliche Fachdomänen; keine zwei Implementierungen desselben Gegenstands.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität - BL-Prüfstelle zeilengenau belegen
+Status: HYPOTHESE
+
+ID: SwRS-31
+Titel: Preisimport in Projektpreise über die Import-ViewModel
+Ebene: SwRS
+Typ: Funktionsanforderung (interne Umrechnungsvorschrift, Preis)
+Qualitätsmerkmal: Genauigkeit, Richtigkeit
+Akteur: `ProjectPriceImportViewModel`
+Vorbedingung: Preisdatensätze liegen als Importzeilen vor
+Fakt: Faktenbasis M025 verweist auf `ProjectPriceImportViewModel` Zeilen 377-452 als Stelle der Preisübernahme.
+Aussage: Die Importkomponente überträgt eingelesene Preise in die Projektpreishaltung und wendet dabei eigene Validierungs- und Rundungsregeln an; die Preisbildung folgt nicht dem Pfad `ReceiptPriceHelper.CalculateNetPrice`.
+Ergebnis: Projektpreise können von der regulären Belegpreisberechnung abweichen; die Abweichung ist ausschließlich durch diese ViewModel-Regeln begründet.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Referenz übernommen, im Lauf nicht gegengeprüft) – `ProjectPriceImportViewModel.cs:377-452` (M025).
+Prüfidee: identische Preis-/Rabbattpaare einmal über Import, einmal über Belegpreisberechnung (SwRS-16) ermitteln und vergleichen.
+Tracelinks: SyRS:Projektpreise, SyRS:Preisformel, StRS:Preisbildung; SwRS-16, SwRS-17
+Konsolidierung: Kandidat – zwei Preisbildungsimplementierungen für denselben fachlichen Gegenstand (Preis eines Artikels in einem Vertrag): `ReceiptPriceHelper` (Belege) vs. `ProjectPriceImportViewModel` (Projektpreise); Zusammenführung auf eine Preisbibliothek.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-32
+Titel: Mindestbestandsgesteuerte Bestellvorschlagsliste per Roh-SQL
+Ebene: SwRS
+Typ: Funktionsanforderung (interner Algorithmus)
+Qualitätsmerkmal: Richtigkeit, Vollständigkeit
+Akteur: `OrderSuggestionListBL`, Views `cvw_ArticleCount`
+Vorbedingung: Artikel mit `Abbuchung = 'J'` oder `IsObligatoryBooking = 1` und `StkListe = 0`
+Fakt: Wörtlich (Auszug): `SELECT A.I3D ArticleI3D, -1 WarehouseI3D, a.Mindestbestand MinimumQuantity … INNER JOIN cvw_ArticleCount ac ON ac.ArtikelI3D = a.I3D AND ac.LagerI3D = -1 and ac.cnt < a.Mindestbestand + IsNull(ab.duration,0) WHERE (A.Abbuchung = 'J' or A.IsObligatoryBooking = 1) AND A.StkListe = 0` und analog für Nebenlager mit `NLA.Mindestbestand`, `WH.WarehouseKind = 0 AND WH.IsActive = 1` (OrderSuggestionListBL.cs:139-159); offene Auftragsmenge `SUM(ap.Stk - ISNULL(ap.Liefermenge,0)) … WHERE ak.Status = 1`.
+Aussage: Ein Artikel wird vorgeschlagen, wenn die Bestandsmenge (`cnt`) kleiner ist als Mindestbestand plus offener, noch nicht gelieferter Auftragsmenge; Haupt- und Nebenlager werden über `UNION ALL` getrennt betrachtet.
+Ergebnis: Die Vorschlagsliste enthält genau die unterdeckten Artikel je Lagerort; Artikel ohne Abbuchungsf lag oder mit `StkListe = 1` werden nie vorgeschlagen.
+Belege: PRIMÄR – `src/backend/Centron.BL/Purchasing/OrderSuggestionList/OrderSuggestionListBL.cs:139-159`, SQL wörtlich zitiert (im Lauf geprüft).
+Prüfidee: Unterdeckungs- und Überdeckungsfälle je Lager erzeugen; offenen Auftrag mit Teillieferung anlegen und `duration`-Einfluss nachrechnen.
+Tracelinks: SyRS:Bestellvorschlag, StRS:Beschaffung; SwRS-24, SwRS-41
+Konsolidierung: Kandidat (Verdacht) – Bestands-/Statusauswertung existiert doppelt: `cvw_ArticleCount` (hier) und `cvw_BarcodeCount` mit Statusfilter 1/2/8 (Faktenbasis M034, SwRS-41); dieselbe fachliche Kennzahl „verfügbarer Bestand" in zwei View-Implementierungen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-33
+Titel: QM-Meldungsart als Enum, Anlagen grund dagegen nur UI-seitig
+Ebene: SwRS
+Typ: Daten-/Mappinanforderung
+Qualitätsmerkmal: Konsistenz
+Akteur: `QmNotification` (Enum), `AssetReason`
+Vorbedingung: QM-Meldung wird erfasst
+Fakt: Faktenbasis M027: `QmNotification` mit Enum-Codierung, `AssetReason` nur im UI geführt.
+Aussage: Die Art der QM-Meldung wird softwareintern über einen Enum abgebildet und persistiert; der Anlagen grund wird ausschließlich in der Oberfläche geführt und ist nicht Bestandteil der durchgesetzten Datenhaltung.
+Ergebnis: Auswertung und Schnittstellen kennen nur den Enum-Wert; der Anlagen grund geht beim Persistieren verloren.
+Belege: PRIMÄR (durchsetzende Stellen laut Faktenbasis, Dateiverweise im Lauf nicht einzeln aufgelöst) – `QmNotification`, `AssetReason` (M027).
+Prüfidee: QM-Meldung mit Anlagen grund speichern und Datenbankeintrag prüfen (Feld fehlt/belegt?).
+Tracelinks: SyRS:QM-Meldung, StRS:Qualitaetssicherung; SwRS-45
+Konsolidierung: Kandidat (Prüfung offen) – Anlagen-/Gerätebezug wird hier UI-seitig geführt, während Geräte-/Asset-Daten in `AssetManagement*` gehalten werden (SwRS-45); möglicher Doppelhaltungsfall.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-34
+Titel: Report-Strukturkaskade ohne fremdschlüsselgesicherte Kindobjekte
+Ebene: SwRS
+Typ: Daten-/Funktionsanforderung
+Qualitätsmerkmal: Konsistenz
+Akteur: `ReportDataBL`, Tabellen `Report_Reports`, `Report_ReportQueries`
+Vorbedingung: Report-Struktur (Eltern/Kind) wird geändert
+Fakt: Faktenbasis M028 verweist auf `ReportDataBL` Zeilen 390-429 (Kaskade) und darauf, dass `Report_Reports`/`Report_ReportQueries` ohne FK ausgeführt sind;对照end existiert für ein anderes Reportobjekt ein Check-Constraint als durchgesetzte Regel: `ALTER TABLE [dbo].[ReportPrintOptions] WITH CHECK ADD CONSTRAINT [CK_ParentReference] CHECK (([ParentI3D] IS NULL AND [ParentObjectKind] IS NULL OR [ParentI3D] IS NOT NULL AND [ParentObjectKind] IS NOT NULL));` (SSMS_DB_SCHEMA.sql:68226).
+Aussage: Die Reportkomponente hält Eltern-/Kindbeziehungen durch eigenen Code kaskadiert; die Tabellen sichern diese Beziehung weder per FOREIGN KEY noch einheitlich per CHECK-Constraint, im Unterschied zu `ReportPrintOptions`.
+Ergebnis: Verwaiste Reportkinder sind bei Direktänderung oder Codefehlern möglich; die Kaskadenregel ist nur im Programmablauf wirksam.
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:68226` (`CK_ParentReference`, durchgesetzte Regel als Vergleich) und Constraint-Inventur (10 CHECK/134 FK). PRIMÄR (Referenz aus Faktenbasis) – `ReportDataBL.cs:390-429` (M028).
+Prüfidee: Elternreport per Direkt-SQL löschen und Kindstruktur prüfen; Kaskadenweg über `ReportDataBL` gegenlösen.
+Tracelinks: SyRS:Berichtewesen, StRS:Auswertungen;, SwRS-37
+Konsolidierung: Kandidat (Verdacht) – Eltern/Kind-Referenzregeln für Reportobjekte werden uneinheitlich in zwei Weisen durchgesetzt: Constraint in `ReportPrintOptions`, Code in `ReportDataBL`; Vereinheitlichung anstreben.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-35
+Titel: RMA-Fallbehandlung in der Kundenbereichskomponente
+Ebene: SwRS
+Typ: Funktionsanforderung
+Qualitätsmerkmal: Richtigkeit
+Akteur: `RmaBL`
+Vorbedingung: RMA-Vorgang wird erzeugt/umgeschlagen
+Fakt: Faktenbasis M029 verweist auf `RmaBL.cs` Zeilen 310-353. Ticketseitig existiert die Spalte `[IstRMAFall] [int] NULL` in `hlpdsk_requests` (SSMS_DB_SCHEMA.sql, Spaltliste ab Zeile 4521).
+Aussage: Die RMA-Komponente führt ihre Vorgangslogik in `RmaBL` und ist über das nullbare Kennzeichen `IstRMAFall` mit Helpdesk-Tickets verbunden.
+Ergebnis: RMA-Zuordnungen sind nicht verpflichtend und nicht constraintgesichert; die Fachregeln liegen vollständig im Code.
+Belege: PRIMÄR (durchsetzende Stelle laut Faktenbasis, Methodennamen nicht gegengeprüft) – `src/backend/Centron.BL/CustomerArea/RmaBL.cs:310-353` (M029). KONTEXT/PRIMÄR – `SSMS_DB_SCHEMA.sql` `hlpdsk_requests.[IstRMAFall] [int] NULL`.
+Prüfidee: RMA-Fall ohne Kennzeichen anlegen und RMA-Liste prüfen; Statusübergänge gegen Code nachstellen.
+Tracelinks: SyRS:Ruecksendungen-RMA, StRS:Serviceabwicklung; SwRS-9, SwRS-24
+Konsolidierung: kein Fall.
+Übernahmewürdigkeit: übernehmen - niedrige Priorität - Regel­details fehlen
+Status: HYPOTHESE
+
+ID: SwRS-36
+Titel: Ratings ohne Eindeutigkeitsregel; Mailing-Datenhaltung in Version 2
+Ebene: SwRS
+Typ: Daten-/Constraintanforderung
+Qualitätsmerkmal: Konsistenz
+Akteur: `ProductMatrixBL`, Tabelle `CustomerProductMatrixRating`; `MailingDataBL`
+Vorbedingung: Produktmatrix-Rating wird gesetzt
+Fakt: Schema: `CREATE TABLE [dbo].[CustomerProductMatrixRating]( [I3D] [int] IDENTITY(1,1) NOT NULL, … [CustomerProductMatrixProductI3D] [int] NOT NULL, [CustomerProductMatrixRatingValue] [int] NOT NULL, CONSTRAINT [PK_CustomerProductMatrixRating] PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:36519-36528) — kein UNIQUE über `(CustomerProductMatrixProductI3D, …)`. Faktenbasis M030: `MailingDataBL` in Ausprägung „Version2".
+Aussage: Pro Produktmatrix-Produkt sind mehrere Rating-Sätze zulässig, da die Einzigartigkeit weder per UNIQUE noch per Check erzwungen wird; die Mailingdatenhaltung liegt in einer Versions-2-Form vor.
+Ergebnis: Doppelbewertungen desselben Produkts sind persistierbar; Aggregatwerte (Mittelwerte) sind ohne weitere Regel nicht reproduzierbar.
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:36519-36528` (PK ohne UNIQUE; Constraintlage als durchgesetzte Regel, im Lauf gelesen). PRIMÄR (Referenz aus Faktenbasis) – `MailingDataBL` („Version2", M030).
+Prüfidee: Zwei Ratings für dasselbe Produkt einfügen (Erfolg erwarten); Aggregation der Bewertungsanzeige kontrollieren.
+Tracelinks: SyRS:Produktmatrix, SyRS:Mailing, StRS:Marketing
+Konsolidierung: Kandidat (Prüfung offen) – Bewertungs-/Ratingdaten werden zusätzlich in anderen Produkt-Matrix-Tabellen (`CustomerProductMatrixProducts`, `…ChangeLogs`) gehalten; Verhältnis „aktueller Wert" vs. „Änderungshistorie" ist fachlich zu einem Konzept zu führen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-37
+Titel: Rechtsgesteuerte Erzeugung von Statistikdatenquellen
+Ebene: SwRS
+Typ: Funktions-/Zugriffsanforderung (Berechtigung)
+Qualitätsmerkmal: Sicherheit, Vollständigkeit
+Akteur: `StatisticDataSourceFactory.Create`
+Vorbedingung: Statistikmaske wird geöffnet, Benutzerrechte liegen im `CentronCache`
+Fakt: `if ((!type.HasValue || type.Value == StatisticTypes.SaleStatistic) && CentronCache.Instance.CurrentUserAppRights.Any(f => f.I3D == UserRightsConst.Controlling.Analytics.SALES_STATISTIC))` … `statistics.Add(articleSales); foreach (var child in articleSales.LoadChildren) statistics.Add(child);` und analog `TICKET_STATISTIC` für `TicketStatisticDataSourceViewModel` (StatisticDataSourceFactory.cs:26 ff.).
+Aussage: Datenquellen werden nur erzeugt, wenn das zugehörige Auswertungsrecht im lokal gecachten Rechtsbestand des Benutzers enthalten ist; Kinddatenquellen erben die Prüfung nicht separat, sondern hängen an der Elternprüfung.
+Ergebnis: Ohne Recht erscheint die Statistik nicht in der Maske; die Prüfung beruht auf dem Client-Cache, dessen Inhalt aus der Server-Rechteauflösung nach SwRS-1 stammt.
+Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics/DataSources/StatisticDataSourceFactory.cs:26-128`, Bedingungscode im Lauf gelesen.
+Prüfidee: Recht entziehen, Client-Cache halten/neu aufbauen und Datenquellenliste vergleichen; Serverseitige Zweitprüfung (Fehlend = Risiko) dokumentieren.
+Tracelinks: SyRS:Auswertungen, SyRS:Rechteverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-34
+Konsolidierung: Kandidat (Verdacht) – Zugriffsfilterung wird einerseits über `CentronCache.Instance.CurrentUserAppRights.Any(...)` (Factory), andererseits über `Helper.HasRights(...)` in `ModuleRegistration` ausgedrückt; dieselbe Fachregel „Recht nötig" in zwei Client-Implementierungen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-38
+Titel: Umfrageveröffentlichung mit zwei Regelträgern und FK-gesichertem Prozessbezug
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung
+Qualitätsmerkmal: Konsistenz, Richtigkeit
+Akteur: `SurveyMainViewModel`, `SurveyProcessBL`, Tabelle `SurveyProcessProperties`
+Vorbedingung: Umfrage soll veröffentlicht bzw. ein Prozess bearbeitet werden
+Fakt: Faktenbasis M032 nennt als Regelträger `SurveyMainViewModel` Zeilen 498-511 und `SurveyProcessBL` Zeilen 680-704. Primär gesichert ist der Datenbezug: `ALTER TABLE [dbo].[SurveyProcessProperties] WITH CHECK ADD CONSTRAINT [FK_SurveyProcessProperties_Surveys] FOREIGN KEY([SurveyI3D])` (SSMS_DB_SCHEMA.sql:68152); Spalte `[SurveyI3D] [int] NOT NULL` (Zeile 52095), `[IsTemplate] [bit] NOT NULL` (Zeile 52092).
+Aussage: Die Veröffentlichungslogik ist zweigeteilt zwischen Client-ViewModel und Business-Layer, während die Zugehörigkeit eines Umfrageprozesses zu exactly one Umfrage hart durch FK mit `WITH CHECK` und NOT NULL erzwungen wird.
+Ergebnis: Verwaiste Umfrageprozesse sind ausgeschlossen; abweichende Veröffentlichungsregeln zwischen Client- und BL-Weg sind möglich, weil beide Stellen Regeln enthalten.
+Belege: PRIMÄR – `SSMS_DB_SCHEMA.sql:68152` (FK `WITH CHECK`) und `:52090-52109` (Spaltendefinitionen), im Lauf gelesen. PRIMÄR (Referenzen aus Faktenbasis, Codezeilen nicht gegengeprüft) – `SurveyMainViewModel.cs:498-511`, `SurveyProcessBL.cs:680-704` (M032).
+Prüfidee: Umfrageprozess ohne zugeordnete Umfrage einfügen (FK-Fehler erwarten); Veröffentlichung einmal über UI, einmal über BL/Webservice auslösen und Ergebnisse vergleichen.
+Tracelinks: SyRS:Umfragen, StRS:Marktforschung;, SwRS-20
+Konsolidierung: Kandidat – Veröffentlichungs-/Freigaberegeln derselben Umfrage liegen in zwei Implementierungen (Client `SurveyMainViewModel`, BL `SurveyProcessBL`); im Zielsystem in die BL-Ebene verlagern.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-39
+Titel: Telekom-Dive-Mapping ohne Tabellenpräsenz im Schema-Dump
+Ebene: SwRS
+Typ: Datenanforderung / Mapping-Constraint
+Qualitätsmerkmal: Konsistenz, Portabilität
+Akteur: `TelekomDiveProfileMaps` (NHibernate-Mapping)
+Vorbedingung: Telekom-Dive-Profil wird persistiert
+Fakt: Faktenbasis M033: `TelekomDiveProfileMaps` mit `Not.Nullable`-Mappings, Tabelle nicht im Dump. Verifiziert: Im `SSMS_DB_SCHEMA.sql` existiert keine Tabelle mit Telekom-Bezug; vorhanden sind lediglich Spalten auf anderen Tabellen, z. B. `[TelekomReferenceNumber] [nvarchar](255) NULL`, `[TelekomDiveComment] [nvarchar](300) NULL`, `[IsTelekomDiveCommentActive] [bit] NULL` (Zeilen 3774-3776) und `[TelekomDiveMaterialGroup] [int] NULL` (Zeilen 9652, 10266) — insgesamt nur 5 Vorkommen von „Telekom" im Dump.
+Aussage: Die Software erwartet ein PROFILartiges Telekom-Dive-Objekt mit nicht-nullbaren Feldern, das im ausgelieferten Schema nicht angelegt ist; Telekom-Dive-Daten existieren im Dump nur als einzeln nullbare Fremdspalten.
+Ergebnis: Beim Einsatz gegen diesen Schema-Stand schlägt die Profilpersistenz fehl (fehlende Tabelle/Constraintkonflikt); eine Abbildung auf die vorhandenen Spalten ist nicht definitionsgemäß.
+Belege: PRIMÄR (Negativbeleg) – `SSMS_DB_SCHEMA.sql`, Suche „Telekom" = 5 Treffer, keine `CREATE TABLE … Telekom …`; Spaltenzitate Zeilen 3774-3776, 9652, 10266. PRIMÄR (Referenz aus Faktenbasis) – `TelekomDiveProfileMaps` (M033).
+Prüfidee: Schema mit Mapping-Definition abgleichen (NHibernate-Schema-Validierung); Profilspeicherung gegen Dump-Datenbank ausführen und Fehlerbild aufnehmen.
+Tracelinks: SyRS:Telekom-Schnittstelle, StRS:Artikelstamm; SwRS-55
+Konsolidierung: Kandidat (Prüfung offen) – Telekom-Attribute liegen verteilt auf Artikel-/Positionstabellen, während ein eigenes Profilobjekt gemappt ist; zwei Haltungen für denselben Gegenstand.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Migrationsrisiko
+Status: belegt
+
+ID: SwRS-40
+Titel: Fortschreibung des Artikel-EK als gewichteter Durchschnitt
+Ebene: SwRS
+Typ: Funktionsanforderung (Berechnungsvorschrift, Preis/EK)
+Qualitätsmerkmal: Genauigkeit, Richtigkeit
+Akteur: `ArticleStockBL.UpdateArticlePurchasePrice`
+Vorbedingung: Wareneingangsposition mit Menge und EK; Artikel ohne Sondervereinbarung
+Fakt: Sondervereinbarung: `if (item.SpecialAgreementI3D > 0) { return Result.AsSuccess; }` (Zeilen 77-80). Fixer EK: `if (article.NoMixedEk == PurchasePriceAsKind.FixedPurchasePrice) return Result.AsSuccess;` (Zeilen 87-88). Zuschlag: `decimal purchasePriceMod = (purchasePrice + freightAmount + insuranceAmount) * calcFactor;` (Zeile 118). Fallunterscheidung: `if (oldQuantity <= 0) { newPurchasePrice = purchasePriceMod; }` … `if (article.NoMixedEk == PurchasePriceAsKind.LastPurchasePrice) { newPurchasePrice = purchasePriceMod; }` … `decimal additionalAmount = Math.Round(purchasePriceMod * (quantity - oldQuantity), article.Precision, MidpointRounding.AwayFromZero); newPurchasePrice = ((oldPurchasePrice * oldQuantity) + additionalAmount) / quantity;` (Zeilen 120-139).
+Aussage: Der Artikel- bzw. Lager-EK wird als Mischpreis fortgeschrieben, sofern kein fixer EK und keine Sondervereinbarung vorliegen; Fracht und Versicherung gehen über den Kalkulationsfaktor in den Zuschlag ein; die Division erfolgt auf `quantity`, nicht auf die Summe aus altem und neuem Bestand.
+Ergebnis: Der fortgeschriebene EK ist reproduzierbar durch diese Formel; bei Teilmengenabgängen (`quantity` kleiner als alter Bestand) weicht der Wert vom klassischen gewichteten Durchschnitt ab.
+Belege: PRIMÄR – `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs`, `UpdateArticlePurchasePrice`, Zeilen 74-144, Formeln wörtlich zitiert (im Lauf geprüft).
+Prüfidee: Goldtestfälle: alte Menge 0; `LastPurchasePrice`; Mischpreis mit `oldQuantity=10, quantity=15, calcFactor=1.05, Fracht/Versicherung`; Ergebnis gegen die zitierte Formel und gegen einen Referenz-Mischpreis vergleichen.
+Tracelinks: SyRS:Artikel-EK-Fortsetzung, SyRS:Preisformel, StRS:Preisbildung; SwRS-16, SwRS-24, SwRS-41
+Konsolidierung: Kandidat – EK-Ermittlung zweigleisig: Mischpreisfortschreibung hier (Lager/Artikel) und Preisstammdatenpflege je Einkaufspreisart über `PurchasePriceAsKind`-Enum; fachlich ein „Einstandspreis"-Konzept, zwei Regelträger.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - preisbestimmend
+Status: belegt
+
+ID: SwRS-41
+Titel: Artikelprüfung ohne Check-Constraints; Statusfilter in Bestandsviews
+Ebene: SwRS
+Typ: Constraint-/Datenanforderung
+Qualitätsmerkmal: Vollständigkeit, Konsistenz
+Akteur: Tabelle `ARTIK` (ARTIK), Views `cvw_ArticleCount`, `cvw_BarcodeCount`
+Vorbedingung: Artikelstammdaten werden geändert
+Fakt: Constraint-Inventur des Dumps: 1558 Tabellen, 134 `FOREIGN KEY`, 38 `UNIQUE`, genau 10 `CHECK`-Constraints (im Lauf ausgezählt); die 10 CHECK-Constraints betreffen `AccountActivities`, `ReceiptProvisionEmployeeGoals`, `ReceiptProvisionItems`, `ReceiptProvisionSchemaItems`, `ReportPrintOptions` (SSMS_DB_SCHEMA.sql:68190-68226) — kein CHECK auf `ARTIK`/Artikel. Faktenbasis M034: „Artikel NOT NULL ohne CHECK", Views `cvw_ArticleCount`/`cvw_BarcodeCount` mit Status 1/2/8.
+Aussage: Artikelwerte sind lediglich über NOT NULL abgesichert, inhaltliche Wertebereiche (Mengen, Kennzeichen) werden nicht durch Check-Constraints erzwungen; die Bestandsauswertung filtert Statusmengen (1/2/8) ausschließlich in den Views.
+Ergebnis: Inhaltlich fehlerhafte Artikelwerte sind persistierbar; Bestands- und Barcode-Auswertungen hängen an den View-Definitionen und deren Statusmengen.
+Belege: PRIMÄR (Constraint-Inventur) – Auszählung gegen `SSMS_DB_SCHEMA.sql`: `CREATE TABLE` = 1558, `FOREIGN KEY` = 134, `UNIQUE` = 38, `CHECK` = 10; Vollständigkeit der CHECK-Liste durch Zitat der zehn `ALTER TABLE … WITH CHECK ADD CONSTRAINT [CK_*/Check_*]`-Zeilen 68190, 68194, 68198, 68202, 68206, 68210, 68214, 68218, 68222, 68226. KONTEXT – Faktenbasis M034 (Views `cvw_ArticleCount`/`cvw_BarcodeCount`, Status 1/2/8).
+Prüfidee: Negativwerte/ungültige Kennzeichen in Artikel speichern (Erfolg erwarten); View-Definitionen auf Statusfilter prüfen und identische Kennzahlen gegenüberstellen.
+Tracelinks: SyRS:Artikelstamm, StRS:Artikelstamm; SwRS-32
+Konsolidierung: Kandidat – Statusfilterlogik (Status 1/2/8) liegt doppelt vor: in `cvw_ArticleCount` und `cvw_BarcodeCount`; dieselbe fachliche Gültigkeitsregel für zwei Kennzahlen getrennt implementiert, zusammenführbar.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-42
+Titel: Webaccount-Login mit unsalzigem SHA1-Kennworthash
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Sicherheit, Authentisierung)
+Qualitätsmerkmal: Sicherheit, Richtigkeit
+Akteur: `WebAccountBL.LoginWithWebAccount`
+Vorbedingung: Login-Versuch mit Benutzername/Kennwort
+Fakt: `string cryptedPw = SHA1Decoder.GetDecodedSHA1String(password);` gefolgt von `GetEntity(f => f.Status == 1 && f.Username.ToUpper == username.ToUpper && f.Password == cryptedPw);` (WebAccountBL.cs:56-61); danach Aktivitätsprüfungen der Kontaktdaten/Kunden bzw. Kontoadresse (`contact.State != 1`, `IsCustomerActiveAndNotLocked`, `address.Data.IsActive`) mit Rückgabe `null` bei Abweichung (Zeilen 68-99) und Login-Protokollierung `account.LastLoginIP = IpAddressHelper.GetIpAddress?.ToString ?? "[unbekannt]"; account.LastLoginDate = DateTime.Now;` (Zeilen 101-103).
+Aussage: Die Authentisierung vergleicht den eingegebenen Kennwert gegen einen SHA1-Hash ohne Salt in der Spalte `WebAccount.Password`, ignoriert die Groß-/Kleinschreibung des Benutzernamens und schreibt IP-Zeitstempel zurück; ein Rechte- oder Zwei-Faktor-Zwang ist in diesem Pfad nicht enthalten.
+Ergebnis: Kennworthashes sind anfällig für vorwärtsberechnete Vergleiche; der Login ist allein durch Passwortwert und Aktivitätsstatus entschieden.
+Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs`, `LoginWithWebAccount`, Zeilen 54-105, Code wörtlich zitiert (im Lauf geprüft).
+Prüfidee: Bekannter SHA1-Testwert in `WebAccount.Password` hinterlegen und Login durchführen; Hashverfahren (SHA1, kein Salt) aus Code und Daten nachweisen; `Status != 1`-Fall prüfen.
+Tracelinks: SyRS:Weblogin, StRS:Rechteverwaltung; SwRS-1, SwRS-43
+Konsolidierung: Kandidat – Authentisierungsdatenhaltung dreifach: `WebAccount.Password` (SHA1, hier), `AppUser.Password → BenutzerInfo2` (SwRS-3) und `MailScannerProfile.Password`/`MailPassword` (SwRS-47); drei Umsetzungen eines Kennworthash-/speicherkonzepts.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
+Status: belegt
+
+ID: SwRS-43
+Titel: Zwei-Faktor-Prüfung hinter Konfigurations- und Benutzerschaltern; Webrechte ohne Verbundschlüssel
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Sicherheit)
+Qualitätsmerkmal: Sicherheit, Nachvollziehbarkeit
+Akteur: `TwoFactorAuthBL`, Tabellen `WebAccountsRights`, `WebRights`
+Vorbedingung: Authentisierungsvorgang mit `applicationName`/`machineName`
+Fakt: `if (WebServiceConfigHelper.Current.TwoFactorAuthEnabled == false) { Logger.Trace("Two-factor-auth is not enabled, …"); return Result.AsSuccess; }` (TwoFactorAuthBL.cs, Konfigurations-Gate) und `if (user.UseTwoFactorAuthentication == false) { Logger.Trace("Two-factor-auth is not enabled for user {User}", user); return false; }` (HasToValidateTwoFactor), gültige Pins schließlich über `Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin(appUserTwoFactorAuthKeyResult.Data, authenticationPin)` (TwoFactorAuthenticationBL.cs:51). Schema: `CREATE TABLE [dbo].[WebAccountsRights]( [I3D] [int] IDENTITY(1,1) NOT NULL, [WebAccountsI3D] [int] NULL, [WebRightsI3D] [int] NULL, PRIMARY KEY CLUSTERED ([I3D] ASC))` (SSMS_DB_SCHEMA.sql:54877-54885), Tabelle `WebRights` ab Zeile 55165.
+Aussage: Zwei-Faktor wird übersprungen, sobald entweder die Konfiguration oder der Benutzer schalterseitig deaktiviert; die Webrechte-Zuordnungstabelle besitzt nur einen surrogate PK, beide Beziehungsspalten sind nullbar, UNIQUE und FOREIGN KEY fehlen.
+Ergebnis: Ein Webaccount kann mehrfach dieselbe Recht erhalten oder Rechte ohne Bezug tragen; der 2FA-Zwang ist ohne Konfigurationsänderung nicht erzwingbar.
+Belege: PRIMÄR – `src/backend/Centron.BL/Administration/Logins/TwoFactor/TwoFactorAuthBL.cs` (Config-/User-Gate) und `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs:51` (im Lauf gelesen). PRIMÄR – `SSMS_DB_SCHEMA.sql:54877-54885` (PK/NULLBARKEIT ohne UNIQUE/FK als durchgesetzte Regel).
+Prüfidee: `TwoFactorAuthEnabled=false` setzen und Login prüfen; doppelte Rechtzeile in `WebAccountsRights` einfügen (Erfolg erwarten); identische Rechte doppelt auflösen (SwRS-1 beachten).
+Tracelinks: SyRS:Weblogin, SyRS:Rechteverwaltung, StRS:Rechteverwaltung; SwRS-1, SwRS-42
+Konsolidierung: Kandidat – Rechtezuordnung wird zweigleisig geführt: `Sichmemb`/`Sichtrus` für App-User (SwRS-1) und `WebAccountsRights`/`WebRights` für Webkonten (AppRightsBL.cs:681-683); dasselbe Rechtetzukonzept, zwei Haltungen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-44
+Titel: Bereinigungsinspektor mit ausgenommener Asset-Zuordnungstabelle
+Ebene: SwRS
+Typ: Funktionsanforderung (softwareinterne Datenbankpflege) + Constraint
+Qualitätsmerkmal: Zuverlässigkeit, Sicherheitskontrolle
+Akteur: `RiverbirdTablesCleanupInspector`
+Vorbedingung: Inspektor wird in den Centron-Inspectors ausgeführt
+Fakt: Tabellenkandidaten per System-Sicht: `WHERE (t.name LIKE 'AssetManagement%' OR t.name LIKE 'DocumentationWizard%' … OR t.name LIKE 'RiverbirdAgentDeployment%') AND t.name <> 'AssetManagementArticleAssignment' AND rc.total_rows > 0` (RiverbirdTablesCleanupInspector.cs:36-48); Ablaufkommentar: „2. FKs droppen, damit TRUNCATE zulaessig ist. 3. Tabellen aus @tableList truncaten. 4. FKs wiederherstellen: - Parent in @tableList -> WITH CHECK …"; Escaping `n.Replace("'", "''")` (Zeilen 50-55).
+Aussage: Der Inspektor truncatet Befundtabellen der Riverbird-/Dokumentationsmodule, nimmt die Artikelzuordnung `AssetManagementArticleAssignment` ausdrücklich aus und stellt die Fremdschlüssel nach dem Truncate mit `WITH CHECK` wieder her.
+Ergebnis: Inventurbestände können maschinell geleert werden, ohne die Artikel-Asset-Verknüpfung zu zerstören; die wiederhergestellten FKs werden wieder geprüft.
+Belege: PRIMÄR – `src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/Inspectors/Database/RiverbirdTablesCleanupInspector.cs:36-48, 50-62`, SQL und Kommentare wörtlich zitiert (im Lauf geprüft).
+Prüfidee: Testdatenbank mit Befundzeilen und Assetzuordnung truncaten; prüfen, dass `AssetManagementArticleAssignment` Zeilen behält und FKs aktiv `WITH CHECK` vorliegen.
+Tracelinks: SyRS:Systemwartung-Inspectors, StRS:Betrieb; SwRS-45
+Konsolidierung: Kandidat (Partner zu SwRS-45) – `AssetManagement%`-Bestand ist löschbar gehalten, die fachliche Anlagezuordnung ist separiert; zwei getrennte Haltungen desselben Asset-Themas mit unterschiedlicher Löschstrategie.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-45
+Titel: Parallele Hardwarehaltungen: Drucker/Geräte als Stammblatt einerseits, AssetManagement-Tabellen andererseits
+Ebene: SwRS
+Typ: Datenanforderung / Begriffszuordnung
+Qualitätsmerkmal: Konsistenz, Vollständigkeit
+Akteur: `MasterDataListBL`/`DeviceClickCounterBL` (Stammblatt) und `AssetManagementDevices`/`AssetManagementPrinter` (Inventar)
+Vorbedingung: Drucker bzw. Kundenhardware wird erfasst oder abgerechnet
+Fakt: Begriffsbildung: `case CentronObjectKindNumeric.MasterDataListClass: return "Stammblatt";` (CentronObjectKindNumeric.cs:314); Zähler hängen am Stammblatt über `GetClickCounterFromMasterDataListId(int masterDataListId) → GetList(f => f.DeviceHeaderI3D == masterDataListId)` (DeviceClickCounterBL.cs:82-84); REST-Beschreibung spricht vom „Stammblatt" als Hauptgeräte-Datensatz (ICentronRestService.Receipts.cs:1373, 1379). Parallel existieren Inventarhaltungen `CREATE TABLE [dbo].[AssetManagementDevices]` (SSMS_DB_SCHEMA.sql:6050) und `CREATE TABLE [dbo].[AssetManagementPrinter]( [I3D] …, [DeviceI3D] [int] NOT NULL, [Name] [nvarchar](256) NULL, [ShareName] [nvarchar](256) NULL, [PrintProcessor] [nvarchar](256) NULL, [PrinterStatus] [int] NULL, [PrinterState] [int] NULL, [JobCountSinceLastReset] [int] NULL, [DriverName] [nvarchar](256) NULL, …)` (Zeilen 30473-30496).
+Aussage: Drucker werden fachlich als „Stammblätter" (MasterDataList/Gerätekopf) geführt und dort für Zähler/Abrechnung verwendet; derselbe Gegestand existiert zusätzlich als Inventarzeile in `AssetManagementPrinter`/`AssetManagementDevices` mit eigenem Druckerzustandsmodell.
+Ergebnis: Es gibt zwei Adressierarten für ein physisches Gerät; Seriennummern-/Zählerpflege und Inventarzustand können auseinanderlaufen, da kein Constraint die Identität verknüpft.
+Belege: PRIMÄR – `CentronObjectKindNumeric.cs:314`; `DeviceClickCounterBL.cs:82-84`; `ICentronRestService.Receipts.cs:1373, 1379`; `SSMS_DB_SCHEMA.sql:6050` (`AssetManagementDevices`), `:30473-30496` (`AssetManagementPrinter`) — alle im Lauf gelesen.
+Prüfidee: identischen Drucker in beiden Haltungen anlegen (Seriennummer/Name) und Konsistenzprüfung versuchen; Zählerpflege und Inventarzustand unabhängig ändern und Auswertung vergleichen.
+Tracelinks: SyRS:Geruete-und-Assets, StRS:Serviceabwicklung; SwRS-12, SwRS-44, SwRS-33
+Konsolidierung: Kandidat (fall (a)) – „Drucker als Stammblatt" (`MasterDataList`/`DeviceHeaderI3D`, Zähler-/Vertragslogik in DeviceClickCounterBL/HelpdeskTimer) vs. „sonstige Hardware als Asset" (`AssetManagementDevices`, `AssetManagementPrinter`, Riverbird-Cleanup in SwRS-44): zwei Datenhaltungen für denselben fachlichen Gegenstand, im Zielsystem zu einem Asset-Konzept zusammenzuführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Zielarchitektur-Entscheidung
+Status: belegt
+
+ID: SwRS-46
+Titel: Telefonnummern-Normalisierung nach Tapi-Einstellungen
+Ebene: SwRS
+Typ: Funktionsanforderung (Berechnungsvorschrift/Transformation)
+Qualitätsmerkmal: Richtigkeit, Konsistenz
+Akteur: `TapiBL.FormatPhoneNumber`
+Vorbedingung: Rufnummer (ggf. mit „+", Nicht-Ziffern) liegt vor
+Fakt: `phoneNumber = Regex.Replace(phoneNumber, "[+]", "00"); phoneNumber = Regex.Replace(phoneNumber, "[^0-9]", string.Empty);` dann Einstellungsauswertung `AppSettingsConst.TapiAmtPrefix`, `TapiCountryPrefix`, `TapiReduceNumber`: `if (reduceNumbers && string.IsNullOrWhiteSpace(amtPrefix) == false && phoneNumber.StartsWith(amtPrefix)) phoneNumber = phoneNumber.Substring(amtPrefix.Length);` und `if (string.IsNullOrWhiteSpace(countryPrefix) == false && phoneNumber.StartsWith("00" + countryPrefix)) phoneNumber = "0" + phoneNumber.Substring(4);` (TapiBL.cs:82-143).
+Aussage: Die Rufnummer wird zu einer reinen Ziffernfolge mit „00"-Länderkennung normalisiert; netzvorwahlenbasierte Verkürzung und Länderkennungs­ersetzung erfolgen nur, wenn die zugehörigen Einstellungen gesetzt sind bzw. `TapiReduceNumber == 1`.
+Ergebnis: Anrufprotokollzuordnung arbeitet auf normalisierten Nummern; ohne Tapi-Einstellungen bleibt die international forma­tierte Ziffernfolge stehen.
+Belege: PRIMÄR – `src/backend/Centron.BL/Accounts/TapiBL.cs`, `FormatPhoneNumber`, Zeilen 82-143, Code wörtlich zitiert (im Lauf geprüft). Faktenbasis M037 ergänzt `TelephonyCallLogViewModel` Zeile 130 als UI-Aufrufer.
+Prüfidee: Goldwerte: „+49 30 123456", Nummern mit Nebenwahlbuchstaben, `TapiReduceNumber = 0/1`; Ergebnisse gegen die zitierten Transformationen prüfen.
+Tracelinks: SyRS:Telefonie-Integration, StRS:Kommunikation; SwRS-25
+Konsolidierung: Kandidat (Prüfung offen) – Rufnummernformatierung existiert zusätzlich in der Adress-/Kommunikationsschicht (Kontaktdatenpflege); gleiche Fachregel, zwei Implementierungen.
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: belegt
+
+ID: SwRS-47
+Titel: Zwei Kennwortfelder im Mailscanner-Profil: Masterkey-verschlüsselt und unverschlüsselt
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Sicherheit)
+Qualitätsmerkmal: Sicherheit, Konsistenz
+Akteur: `MailScannerBL`, `MailScannerProfileMaps`, `MailScannerProfile`
+Vorbedingung: VMA-Profil wird geladen oder gespeichert
+Fakt: Verschlüsselung nur für zwei Felder: `var passwordResult = _centronConfigurationDbBl.EncryptWithMasterKey(profile.Password);` · `var secretResult = _centronConfigurationDbBl.EncryptWithMasterKey(profile.ClientSecret);` (MailScannerBL.cs:104-116) und analog `DecryptWithMasterKey` beim Laden (Zeilen 90-102); Rechthürde: `_appRightsBl.CheckRightsFromUser(loggedInUser.UserI3D.Value, UserRightsConst.VirtualMailAssistant.ACCESS_VMA_MODULE)` mit Fehler „Fehlendes Recht VMA Profile zu laden" (Zeilen 59-62). Mapping ohne Verschlüsselung: `this.Map(f => f.MailPassword).Column("MailPassword").Length(int.MaxValue).Nullable;` (MailScannerProfileMaps.cs:20); Entität führt beide Felder: `public virtual string MailPassword { get; set; }` (Zeile 15) und `public string Password { get; set; }` (Zeile 20); DDL: `[MailPassword] [nvarchar] (MAX) NULL,` (SQLScriptCollection3.xml:19675). DTO-Weitergabe unverschlüsselt: `entity.MailPassword = item.MailPassword;` (MailScannerWebServiceBL.cs:105).
+Aussage: Das Profil besitzt zwei Kennwortattribute; nur `Password` (und `ClientSecret`) durchlaufen Masterkey-Verschlüsselung, `MailPassword` wird im Klartext in einer `nvarchar(max)`-Spalte persistiert und über DTOs weitergereicht.
+Ergebnis: Postfach-Zugangsdaten liegen lesbar in der Datenbank und im Webservice-Verkehr vor; die Verschlüsselungsregel greift für dasselbe Konzept nur Feld-abhängig.
+Belege: PRIMÄR – `src/backend/Centron.BL/MailScanner/MailScannerBL.cs:59-62, 90-116`; `src/backend/Centron.DAO/Mappings/MailScanner/MailScannerProfileMaps.cs:20`; `src/backend/Centron.Entities/Entities/MailScanner/MailScannerProfile.cs:15, 20`; `src/backend/Centron.BL/WebServices/MailScanner/MailScannerWebServiceBL.cs:105`; `SQLScriptCollection3.xml:19675` — alle im Lauf gelesen.
+Prüfidee: Profil mit beiden Kennwörtern speichern und DB-Inhalte inspizieren (ein Feld Cipher-Base64, ein Feld Klartext); VMA-Recht entziehen und Fehlerpfad prüfen.
+Tracelinks: SyRS:MailScanner-Profile, StRS:Rechteverwaltung; SwRS-27
+Konsolidierung: Kandidat (fall (e)) – zwei Kennwortfelder desselben Profils mit zwei verschiedenen Durchsetzungsmechanismen (`Password` masterkey-verschlüsselt in `MailScannerBL.EncryptProperties`, `MailPassword` unverschlüsselt per Mapping, `MailScannerProfileMaps.cs:20`); auf ein Feld/einen Mechanismus zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
+Status: belegt
+
+ID: SwRS-48
+Titel: Social-Media-Bearbeitung ausschließlich über EmployeeI3D-Prädikat der Stored Procedures; zweigleisige Kind-Codierung in C#-Enum und T-SQL
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Berechtigung, Codierung)
+Qualitätsmerkmal: Sicherheit, Konsistenz
+Akteur: Stored Procedures spr_SocialMediaUpdateComment/RemoveComment/RemoveLike, Ansichten cvw_SocialMedia*, C#-Enum SocialMediaKind
+Vorbedingung: Bearbeiter ändert oder löscht Kommentar/Like eines Streams oder einer Aktion
+Fakt: Löschung `DELETE FROM SocialMediaComment WHERE EmployeeI3D = @EmployeeI3D AND I3D = @SocialMediaCommentI3D` mit Guard `if ISNULL(@EmployeeI3D,0) <= 0 begin RAISERROR(...,16,1)...` (SSMS_DB_SCHEMA.sql:73811-73818); Bearbeitung `UPDATE SocialMediaComment SET Text=@Comment, CreatedDate=CURRENT_TIMESTAMP WHERE EmployeeI3D=@EmployeeI3D...` (SSMS_DB_SCHEMA.sql:74061-74093); Kind-Codierung `public enum SocialMediaKind { SocialMediaStream=0, SocialMediaAction=1 }` (SocialMediaKind.cs:3-7) und erneut in T-SQL `CASE WHEN C.SocialMediaStreamI3D IS NOT NULL THEN 0 ELSE 1 END` (6 Fundstellen; 2 exakte CASE-Varianten, 6 Varianten insgesamt). Schema SocialMediaComment: beide Elternspalten und EmployeeI3D nullbar, kein FK/CHECK (SSMS_DB_SCHEMA.sql:8020-8031); FK nur auf CSI_*-Tabellen (:67802-67842).
+Aussage: Änderung/Löschung werden nur durch das EmployeeI3D-Prädikat in den Stored Procedures erzwungen; die Haupttabellen tragen keine Eigentums-/Referenz-Constraints, Direkt-SQL umgeht die Regelung. Die Zuordnung Stream=0/Aktion=1 ist zweifach implementiert (C#-Enum und verteilte T-SQL-Klauseln); Bearbeiten setzt CreatedDate zurück, da kein Änderungsdatum existiert.
+Ergebnis: Nur eigene Sätze änderbar, solange Zugriff über Prozeduren läuft; Direktzugriff ohne Durchsetzung. Editierung verschiebt Chronologie; Codierung 0/1 muss an allen T-SQL-Stellen synchron bleiben.
+Belege: [PRIMÄR] SSMS_DB_SCHEMA.sql:73811-73818 (spr_SocialMediaRemoveComment), 74061-74093 (spr_SocialMediaUpdateComment); Centron.Interfaces\SocialMedia\SocialMediaKind.cs:3-7; SSMS_DB_SCHEMA.sql:8020-8031, 67802-67842.
+Prüfidee: Kommentar mit EmployeeI3D A per SP mit @EmployeeI3D B löschen (0 Zeilen); Editierung und CreatedDate-Sprung prüfen; INSERT mit beiden Eltern-I3D per Direkt-SQL (Erfolg, kein CHECK).
+Tracelinks: SyRS:Kommunikation-Chat (SyRS-12), StRS:Kommunikation (StRS-34); SwRS-25, SwRS-41, SwRS-53
+Konsolidierung: Kandidat (Fall f) — SocialMediaKind doppelt: C#-Enum (SocialMediaKind.cs:3-7) und T-SQL-Fallunterscheidungen (6 Fundstellen; 2 exakte CASE-Varianten, 6 Varianten insgesamt); offen: SocialMedia*- vs. CSI_SocialMedia*-Tabellen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheits- und migrationsrelevant
+Status: belegt
+
+ID: SwRS-49
+Titel: Rechte-Cache ohne gefundenen Invalidierungspfad; Duplikate wandern in den gecachten Rechtsbestand
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Berechtigung, Caching) — Ergänzung zu SwRS-1
+Qualitätsmerkmal: Sicherheit, Konsistenz, Zeitverhalten
+Akteur: AppRightsBL mit Session.Advanced.Cache
+Vorbedingung: Rechtebestand eines Benutzers wurde einmal aufgelöst; anschließend geändert
+Fakt: `GetOrAdd($"AllRightsFromAppUser{appUserI3D}", => GetAllAppRightsFromUser(appUserI3D))` (AppRightsBL.cs:646) bzw. `...AllRightsFromWebAccount...` (Zeile 674); Schlüssel-Literale kommen nur in dieser Datei vor; kein Remove/Invalidate vorhanden; Menge ohne DISTINCT (Zeilen 653-656), Prüfung via rights.Contains (648, 676).
+Aussage: Einmal aufgelöste Rechte bleiben für die Lebensdauer des Session-Caches unverändert, weil rechteändernde Methoden die Schlüssel nicht löschen; [HYPOTHESE] zur Cache-Lebensdauer (TTL nicht geprüft). Ohne DISTINCT/UNIQUE enthält die Liste bei Doppelzuweisung dieselbe Recht-ID mehrfach.
+Ergebnis: Rechtsentzug/-ergänzung wirkt erst nach Cache-Neubindung; Doppelzuweisungen bleiben unbemerkt.
+Belege: [PRIMÄR] AppRightsBL.cs Zeilen 644-664, 666-691 (GetOrAdd/Contains); Negativbeleg: Suche AllRightsFromAppUser/WebAccount nur in dieser Datei.
+Prüfidee: Cache füllen, Recht entziehen, HasUserRight erneut → veraltetes „ja"; doppelte Zuweisungszeile und Listengröße zählen.
+Tracelinks: SyRS:Berechtigungsprüfung (SyRS-49), StRS:Rechteverwaltung; SwRS-1, SwRS-50
+Konsolidierung: kein Fall — Ergänzung zu SwRS-1 (anderer Aspekt: Cache-Lebenszyklus).
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant (Trägheit von Rechtsänderungen)
+Status: HYPOTHESE
+
+ID: SwRS-50
+Titel: Parallele Rechteauflösung für Webkonten über eigene Roh-SQL und eigenen Cache-Schlüssel
+Ebene: SwRS
+Typ: Funktionsanforderung (Berechtigungskomponente, zweiter Zweig)
+Qualitätsmerkmal: Konsistenz, Richtigkeit, Sicherheit
+Akteur: AppRightsBL.HasWebAccountRight / GetAllWebRightsFromWebAccount
+Vorbedingung: WebAccount liegt vor; Session-Cache verfügbar
+Fakt: `HasWebAccountRight` lädt `$"AllRightsFromWebAccount{webAccount.I3D}"` per GetOrAdd mit rights.Contains (AppRightsBL.cs:670-677); Menge aus `SELECT WebRightsI3D AS ID FROM WebAccountsRights WHERE WebAccountsI3D = :WebAccountI3D` (681-683) ohne DISTINCT; WebAccountsRights PK ohne UNIQUE/FK, beide Beziehungsspalten nullbar (SSMS_DB_SCHEMA.sql:54877-54885).
+Aussage: Neben der AppUser-Auflösung über Sichtrus/Sichmemb (SwRS-1) betreibt die Komponente einen separaten Webkonto-Auflösungsweg mit eigener Tabelle, SQL und Cache; keine gemeinsame Datenhaltung.
+Ergebnis: Webrechte unabhängig vom AppUser-Rechtebaum; Änderungen erst nach Cache-Neubindung; Regelpflege muss beide Wege synchron halten.
+Belege: [PRIMÄR] AppRightsBL.cs:670-691 (SQL zitiert); SSMS_DB_SCHEMA.sql:54877-54885.
+Prüfidee: Doppelte WebAccountsRights-Zeile einfügen (Erfolg); HasWebAccountRight vor/nach Änderung (Cache-Trägheit); Webkonto-Rechte gegen Sichmemb-Logik vergleichen.
+Tracelinks: SyRS:Weblogin (SyRS-45), StRS:Rechteverwaltung; SwRS-1, SwRS-49
+Konsolidierung: Kandidat — „Rechte eines Kontos auflösen" doppelt: AppUser-Zweig (653-656) und WebAccount-Zweig (681-683); auf ein Rechtemodell mit Kontotyp-Attribut zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität
+Status: belegt
+
+ID: SwRS-51
+Titel: Kennworthaltung dreifach: AppUser.Password→BenutzerInfo2, WebAccount ungesalzen SHA1, MailScanner doppelt
+Ebene: SwRS
+Typ: Daten-/Constraintanforderung (Sicherheit, Geheimnisaufbewahrung)
+Qualitätsmerkmal: Sicherheit, Konsistenz
+Akteur: AppUserMaps, WebAccountBL, MailScannerBL/MailScannerProfileMaps
+Vorbedingung: Konten bzw. VMA-Profile werden mit Kennwerten angelegt/geprüft
+Fakt: (1) `Map(appUser => appUser.Password).Column("BenutzerInfo2")` (AppUserMaps.cs:24, ohne Not.Nullable). (2) `cryptedPw = SHA1Decoder.GetDecodedSHA1String(password)` und Auswahl `f.Status==1 && f.Username.ToUpper==username.ToUpper && f.Password==cryptedPw` (WebAccountBL.cs:56-61) — SHA1 ohne Salt. (3) MailScannerProfile mappt MailPassword (Zeile 20) und Password (Zeile 26); nur Password/ClientSecret durchlaufen EncryptWithMasterKey (MailScannerBL.cs:104-116), MailPassword bleibt Klartext.
+Aussage: Für denselben Gegenstand „Kennwert eines Kontos" unterhält die Software drei Haltungen mit drei Mechanismen (Altspalte ohne Pflichtdeklaration, ungesalzener SHA1, feldabhängige Masterkey-Verschlüsselung); vierte leere Haltung bei PasswordManagementKeyword (SwRS-27). Kein Constraint erzwingt Verfahren/Stärke/Nullbarkeit.
+Ergebnis: Kennworthärtung pro Haltung unterschiedlich und nicht zentral erzwingbar; Migrationen müssen vier Spaltenformate abbilden.
+Belege: [PRIMÄR] AppUserMaps.cs:24; WebAccountBL.cs:56-61; MailScannerProfileMaps.cs:20,26; MailScannerBL.cs:104-116.
+Prüfidee: Muster-Datensatz je Haltung anlegen, DB-Werte vergleichen (Klartext/Hash/Cipher/leer); identisches Kennwort in allen drei Haltungen ablegen.
+Tracelinks: SyRS:Benutzerverwaltung, SyRS:Weblogin, StRS:Zwei-Faktor-und-Kennworthaerte; SwRS-3, SwRS-27, SwRS-42, SwRS-47
+Konsolidierung: Kandidat (Sammelfall zu e) — dreifache Implementierung „Kennworthaltung" (BenutzerInfo2, WebAccount SHA1, MailScanner doppelt); auf einen Mechanismus zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
+Status: belegt
+
+ID: SwRS-52
+Titel: Krypto-Schlüsselverwaltung mit eingebettetem Default-Schlüssel und aus demselben Hash abgeleitetem IV
+Ebene: SwRS
+Typ: Funktions-/Constraintanforderung (Kryptographie, Schlüsselverwaltung)
+Qualitätsmerkmal: Sicherheit, Wartbarkeit
+Akteur: AESCryptoLogic (Centron.Common.TextCoding) und alle verschlüsselnden Aufrufer
+Vorbedingung: Ein Aufrufer verschlüsselt Vertrauliches
+Fakt: `public string EncryptText(string text, string securityKey = null)` (AESCryptoLogic.cs:11); `SECURITY_KEY = @"lugE!35Djn"` und Rückfall bei leerem secret (77-81); key=SHA512(secret)[0..32], iv=SHA512(secret)[5..20] (83-91) — IV überlappt mit Schlüssel; Decodierfehler → leerer String (31-34). 51 Aufrufe new AESCryptoLogic, mind. 8 ohne Schlüssel (z. B. RmmConnectionSettingsBL.cs:70, PdfSigningBL.cs:87/90/100, SupplierEdiConfigurationsWebServiceBL.cs:74, CentronConfigurationDbBL.cs:72).
+Aussage: Wo der optionale Schlüssel weggelassen wird, werden Produktionsgeheimnisse mit einem im Quellcode eingebetteten, auslieferungsweit identischen Schlüssel verschlüsselt; Schlüssel und statische IV teilen Bytes, gleiche Klartexte ergeben identische Chiffretexte; Masterkey-Ablage verschlüsselt sich mit demselben Default; kein Rotationsmechanismus.
+Ergebnis: Verschlüsselung schützt nicht gegen Angreifer mit Quellcode-/Binary-Zugriff; Chiffretexte deploymentsübergreifend vergleichbar; fehlgeschlagene Entschlüsselung liefert Leerwert.
+Belege: [PRIMÄR] AESCryptoLogic.cs:11-92; Aufrufzählung gegen Quellcode; KONTEXT Faktenbasis M057.
+Prüfidee: EncryptText(x) ohne Schlüssel auf zwei Systemen vergleichen (Identität); Chiffretext-Wiederholungen zählen; DecryptText mit fremdem Schlüssel (leerer String).
+Tracelinks: SyRS:Krypto (SyRS-56), StRS:Verschluesselung; SwRS-26, SwRS-27, SwRS-47, SwRS-51
+Konsolidierung: Kandidat — drei Mechanismen „Verschlüsselung gespeicherter Geheimdaten": AESCryptoLogic Default, EncryptWithMasterKey, SHA1; auf ein Schlüsselmanagementsystem mit rotierbaren Schlüsseln zusammenführen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Sicherheitsrisiko
+Status: HYPOTHESE
+
+ID: SwRS-53
+Titel: Globale FK-Armut (134 FK bei 1558 Tabellen): Referenzintegrität ist anwendungsgesteuert
+Ebene: SwRS
+Typ: Constraint-/Datenanforderung (Architektur-Querschnitt)
+Qualitätsmerkmal: Konsistenz, Vollständigkeit, Portabilität
+Akteur: Persistenzschicht insgesamt (SSMS_DB_SCHEMA.sql)
+Vorbedingung: Beliebige Datenbankänderung oder Direktzugriff
+Fakt: CREATE TABLE=1558, FOREIGN KEY=134 (≈8,6 %); CHECK=10; Beispiele Zahlungseingang.RechKopfI3D NULL ohne FK; SocialMediaComment ohne FK/CHECK; WebAccountsRights ohne FK/UNIQUE; Gegenbeispiele FK_SurveyProcessProperties WITH CHECK, CK_ParentReference; FK-Inseln v.a. CSI_*-Tabellen.
+Aussage: Die überwiegende Mehrheit der Tabellenbeziehungen wird datenbankseitig nicht erzwungen; referenzielle Regeln leben in BL, Raw-SQL und Views und gelten nur für den jeweiligen Codepfad.
+Ergebnis: Verwaiste Referenzen auf jedem Direktweg erzeugbar; Migrationen/Drittsysteme können Regeln nicht aus dem Schema ableiten.
+Belege: [PRIMÄR] Auszählung gegen SSMS_DB_SCHEMA.sql (1558/134); Beispiele :8020-8031, :54877-54885, :67802-67842.
+Prüfidee: Referenzen ohne Elternsatz (Zahlungseingang, SocialMediaComment) → Speichern-Erfolg; Probe auf FK-Insel SurveyProcessProperties → FK-Fehler.
+Tracelinks: SyRS:Referenzintegritaet (SyRS-50), StRS:Pflichtfelder; SwRS-8, SwRS-34, SwRS-41, SwRS-48, SwRS-50
+Konsolidierung: kein Fall — Querschnittsbetrachtung; Teilaspekte desselben Zustands, keine getrennten Implementierungen eines Fachgegenstands.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Zielarchitektur-Entscheidung
+Status: belegt
+
+ID: SwRS-54
+Titel: Anhängegrenzen der KI-Konversation als hartcodierte Konstanten (20 MB / 40 MB / 20000 Zeichen)
+Ebene: SwRS
+Typ: Constraint-/Datenanforderung (Ressourcengrenzen)
+Qualitätsmerkmal: Zuverlässigkeit, Ressourcenverhalten, Wartbarkeit
+Akteur: ArtificialIntelligenceChatConversationViewModelBase
+Vorbedingung: Benutzer hängt Dateien an bzw. sichert Textinhalte
+Fakt: `_maximumAttachmentBytes = 20L*1024L*1024L`, `_maximumAttachmentTotalBytes = 40L*1024L*1024L`, `_attachmentTextSnapshotLimit = 20000` (ArtificialIntelligenceChatConversationViewModelBase.cs:40-42); Durchsetzung fileInfo.Length>... (498), bytes.LongLength>... (540); zwei Formatierungshilfen (626-629, 1200-1203); keine serverseitige Zweitprüfung.
+Aussage: Die Komponente erzwingt Einzelanhang 20 MiB, Gesamtgrenze 40 MiB und Textsnapshot 20000 Zeichen ausschließlich clientseitig über Konstanten; kein persistenter/serverseitiger Grenzwert.
+Ergebnis: Grenzwerte nur per Quellcodeänderung anpassbar; Clientumgehung nicht behindert ([HYPOTHESE] Serverseite).
+Belege: [PRIMÄR] ArtificialIntelligenceChatConversationViewModelBase.cs:40-42, 498, 540, 626-629, 1200-1203; KONTEXT M002.
+Prüfidee: Datei 21 MB ablehnen; 3×14 MB (42 MB) Summen-Ablehnung; 20001-Zeichen-Text Snapshot-Kappung; KI-Dienst direkt ansprechen.
+Tracelinks: SyRS:KI-Assistent (SyRS-52), StRS:KI-Nutzung; SwRS-4
+Konsolidierung: Kandidat: SwRS-4 (dieselben KI-Grenzwerte 20/40 MB/20000 Zeichen in der Client-Schicht); bei Übernahme mit SwRS-4 verschmelzen. — Konstanten an einer Stelle; Doppelung der Größenformatierung ist Redundanz, kein Fachdoppel; Abgrenzung zu SwRS-4 (andere Tiefe → Tracelink).
+Übernahmewürdigkeit: übernehmen - mittlere Priorität
+Status: HYPOTHESE
+
+ID: SwRS-55
+Titel: Report-Kaskadenlöschung als sequenzielle Roh-SQL-Kette inklusive externer Referenznullsetzung
+Ebene: SwRS
+Typ: Funktionsanforderung (interner Algorithmus, Löschkaskade)
+Qualitätsmerkmal: Konsistenz, Richtigkeit, Nachvollziehbarkeit
+Akteur: ReportDataBL.DeleteReport (ReportEngine)
+Vorbedingung: reportID eines vorhandenen Reports
+Fakt: Session.StartTransaction (396); delete from ReportDataQueries (402); Delete ReportData (409); DeletePrintSetting (411); DELETE rp FROM ReportDataParameters INNER JOIN ReportGroupsToReportData (414-417); delete ReportGroupsToReportData (421); delete ReportPrintOptions (425); update VertragsArt set C2ReportI3D=0 (429); jeder Schritt throw bei ResultStatus.Error.
+Aussage: Die Reportkomponente ersetzt fehlende FK-Kaskaden (SwRS-34) durch eine handkodierte, transaktionale Löschsequenz fester Reihenfolge und entkräftet modulexterne Verweise durch Setzen auf 0; die Sequenz ist der einzige Ort vollständiger Bereinigung.
+Ergebnis: Löscht ein anderer Weg den Elternsatz, bleiben Kindobjekte und VertragsArt.C2ReportI3D-Verweise auf nicht existierende Reportnummer; „Report 0" als Sentinel gesetzt.
+Belege: [PRIMÄR] ReportDataBL.cs DeleteReport Zeilen 390-431; KONTEXT Faktenbasis M028.
+Prüfidee: Report mit allen Abhängigkeiten anlegen, DeleteReport, sechs Tabellen + VertragsArt prüfen; Elternsatz per Direkt-SQL löschen und Waisenbestand vergleichen.
+Tracelinks: SyRS:Berichtewesen (SyRS-53), StRS:Auswertungen; SwRS-34, SwRS-37, SwRS-53
+Konsolidierung: kein Fall — SwRS-34 Constraint-Seite, dieser Block Algorithmus; zwei Tiefenblicke, keine getrennten Implementierungen.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - Datenbestandskonsistenz
+Status: belegt
+
+ID: SwRS-56
+Titel: Zwei parallele Client-Transportpfade für TOTP-Schlüsselverwaltung und PIN-Prüfung (BL-Direkt vs. Webservice)
+Ebene: SwRS
+Typ: Funktionsanforderung (Komponentenarchitektur, Sicherheit)
+Qualitätsmerkmal: Sicherheit, Konsistenz, Wartbarkeit
+Akteur: BLTwoFactorAuthenticationLogic und WSTwoFactorAuthenticationLogic (beide ITwoFactorAuthenticationLogic)
+Vorbedingung: Client muss TOTP-Schlüsselstand prüfen, Schlüssel setzen oder PIN validieren
+Fakt: BLTwoFactorAuthenticationLogic führt Anfragen lokal über `new BLSession...GetBL<TwoFactorAuthenticationWebServiceBL>` (BLTwoFactorAuthenticationLogic.cs:10-55); WSTwoFactorAuthenticationLogic dieselben drei Operationen über CallWebServiceMethodWithSingleResultAsync (WSTwoFactorAuthenticationLogic.cs:9-26); PIN-Validierung servernah über TwoFactorAuthenticationBL.ValidatePin (51).
+Aussage: Für denselben Gegenstand „TOTP-Schlüsselverwaltung/PIN-Prüfung" hält die Software zwei Implementierungen mit unterschiedlichen Autorisierungspfaden bereit; der BL-Pfad umgeht die Webservice-Autorisierungsschicht; die Konfiguration entscheidet die Bindung.
+Ergebnis: Je Pfad können Berechtigungsprüfung, Protokollierung und Fehlerbehandlung divergieren; Server-Autorisierung auf BL-Pfad nicht wirksam.
+Belege: [PRIMÄR] BLTwoFactorAuthenticationLogic.cs:10-55 und WSTwoFactorAuthenticationLogic.cs:9-26; TwoFactorAuthenticationBL.cs:51.
+Prüfidee: DI-Bindung untersuchen; 2FA-Aufruf ohne Dienstautorisierung auf BL-Pfad; PIN-Validierung auf beiden Pfaden vergleichen.
+Tracelinks: SyRS:Weblogin (SyRS-45), SyRS:Zwei-Faktor-Authentisierung (SyRS-56); StRS:Durchgehende-Autorisierung (StRS-10), StRS:Zwei-Faktor-und-Kennworthaerte (StRS-13); SwRS-42, SwRS-43
+Konsolidierung: Kandidat (Fall c) — TOTP doppelt: BLTwoFactorAuthenticationLogic (BL direkt) vs. WSTwoFactorAuthenticationLogic (REST); auf einen autorisierten Pfad reduzieren.
+Übernahmewürdigkeit: übernehmen - hohe Priorität - sicherheitsrelevant
+Status: belegt
+
+## KONSOLIDIERUNGSÜBERSICHT (SwRS-Autor, fachliche Doppelführungen)
+
+| Fall | Fachlicher Gegenstand | Getrennte Implementierungen | Belegt in |
+|---|---|---|---|
+| a | Drucker/Geräte-Hardware | „Stammblatt" (MasterDataList/DeviceHeaderI3D) vs. AssetManagementDevices/AssetManagementPrinter (Inventar, Riverbird-Cleanup) | SwRS-45, SwRS-12, SwRS-44 |
+| b | Zahler/Kostenträger | UI-Begriff „Payers"/„Zahler" (PayersAndCostCenter*) vs. Domänentabelle Kostentraeger; Kostenstellen (pl.) vs. Kostenstelle (sg.) | SwRS-29, SwRS-28 |
+| c | TOTP-Zwei-Faktor-Behandlung | BLTwoFactorAuthenticationLogic (BL direkt) vs. WSTwoFactorAuthenticationLogic (REST) hinter ITwoFactorAuthenticationLogic | SwRS-56 |
+| d | Helpdesk-Eskalation/SLA | EscalationBL mit Escalationen/hlpdsk_requests.EscalationLevel vs. Eskalations-/SLA-Felder in hlpdsk_prioritaeten | SwRS-22, SwRS-23 |
+| e | MailScanner-Kennwort | Password masterkey-verschlüsselt (MailScannerBL.cs:104-116) vs. MailPassword unverschlüsselt (MailScannerProfileMaps.cs:20) | SwRS-47, SwRS-51 |
+| f | SocialMediaKind-Codierung | C#-Enum (SocialMediaKind.cs:3-7) vs. T-SQL-Fallunterscheidungen/-Literals (≥16 Fundstellen SSMS_DB_SCHEMA.sql) | SwRS-48 |
+| g | Eingehende Zahlung | PaymentTransactionBL-Zahlungsverkehr vs. Zahlungseingang (FK-frei, PaymentsBL) | SwRS-6, SwRS-8 |
+| h | Frist-/Verlängerungslogik | ContractBL.RefreshContractEndeDate (C#) vs. CASE-Fallunterscheidung in über zehn SQL-Skriptkopien (SQLScriptCollection4.xml:936-938) | SwRS-11 |
+| zusätzlich | Kennworthaltung | BenutzerInfo2 (AppUser), SHA1 (WebAccount), MailScanner doppelt, leer (PasswordManagementKeyword) | SwRS-51, SwRS-3/27/42/47 |
+| zusätzlich | Rechteauflösung | AppUser-Zweig Sichtrus/Sichmemb vs. WebAccount-Zweig WebAccountsRights | SwRS-1, SwRS-50 |

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Ergebnisse/Traceability.md

@@ -0,0 +1,78 @@
+# Traceability
+
+Die Tabelle zeigt die redaktionell aufgelösten Forward-/Backward-Beziehungen zwischen StRS, SyRS und SwRS. Kurzanker ohne numerische Gegenstelle sind in den Anforderungsdateien als offene Anker stehen geblieben; die Tabelle verwendet nur existierende IDs. `—` markiert eine auf dieser Ebene nicht aufgelöste Beziehung.
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
+|---|---:|---|---|
+| StRS-1, StRS-4 | SyRS-1 | SwRS-1, SwRS-3, SwRS-48, SwRS-51 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-1, StRS-7 | SyRS-2 | — | SSMS_DB_SCHEMA.sql |
+| StRS-2 | SyRS-3 | SwRS-2 | src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs |
+| StRS-3 | SyRS-4 | SwRS-49, SwRS-50, SwRS-56 | src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs |
+| StRS-4, StRS-8 | SyRS-5 | SwRS-52, SwRS-53, SwRS-54, SwRS-55, SwRS-56 | siehe Belege-Feld der Anforderung |
+| StRS-24 | SyRS-6 | SwRS-20 | siehe Belege-Feld der Anforderung |
+| StRS-7 | SyRS-7 | SwRS-21 | src/backend/Centron.BL/GUI/Profiles/UiProfileBL.cs |
+| StRS-6, StRS-12 | SyRS-8 | — | src/backend/Centron.BL/Accounts/AccountBL.cs |
+| StRS-5 | SyRS-9 | SwRS-13 | src/backend/Centron.BL/Accounts/AccountAddressBL.cs |
+| StRS-24 | SyRS-10 | — | SSMS_DB_SCHEMA.sql |
+| StRS-24 | SyRS-11 | — | SSMS_DB_SCHEMA.sql |
+| StRS-34 | SyRS-12 | SwRS-25, SwRS-48 | siehe Belege-Feld der Anforderung |
+| StRS-23 | SyRS-13 | SwRS-16, SwRS-17, SwRS-31 | src/webservice/Centron.WebServices.Core/Helper/ReceiptPriceHelper.cs |
+| StRS-22 | SyRS-14 | SwRS-18, SwRS-19 | SpecificLogic |
+| StRS-24 | SyRS-15 | — | SSMS_DB_SCHEMA.sql |
+| StRS-26 | SyRS-16 | SwRS-24 | src/backend/Centron.BL/Logistics/Warehousing/StockBL.cs |
+| StRS-29 | SyRS-17 | SwRS-35 | src/backend/Centron.BL/CustomerArea/RmaBL.cs |
+| StRS-35 | SyRS-18 | SwRS-36 | siehe Belege-Feld der Anforderung |
+| StRS-38 | SyRS-19 | SwRS-39 | siehe Belege-Feld der Anforderung |
+| StRS-16 | SyRS-20 | SwRS-6, SwRS-8 | src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs |
+| StRS-17 | SyRS-21 | SwRS-9 | DunningRunBL |
+| StRS-17 | SyRS-22 | — | src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs |
+| StRS-17 | SyRS-23 | — | SSMS_DB_SCHEMA.sql |
+| StRS-20 | SyRS-24 | SwRS-11 | ContractBL |
+| StRS-21 | SyRS-25 | — | src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ContractBL.cs |
+| StRS-21 | SyRS-26 | SwRS-12 | siehe Belege-Feld der Anforderung |
+| StRS-18 | SyRS-27 | SwRS-26 | siehe Belege-Feld der Anforderung |
+| StRS-23 | SyRS-28 | SwRS-40 | siehe Belege-Feld der Anforderung |
+| StRS-4 | SyRS-29 | — | siehe Belege-Feld der Anforderung |
+| StRS-28 | SyRS-30 | SwRS-41 | SSMS_DB_SCHEMA.sql |
+| StRS-27 | SyRS-31 | SwRS-32 | siehe Belege-Feld der Anforderung |
+| StRS-8 | SyRS-32 | SwRS-30 | siehe Belege-Feld der Anforderung |
+| StRS-24 | SyRS-33 | SwRS-33 | siehe Belege-Feld der Anforderung |
+| StRS-30 | SyRS-34 | SwRS-14 | siehe Belege-Feld der Anforderung |
+| StRS-31 | SyRS-35 | SwRS-22, SwRS-23 | siehe Belege-Feld der Anforderung |
+| StRS-31 | SyRS-36 | — | siehe Belege-Feld der Anforderung |
+| StRS-21 | SyRS-37 | SwRS-5 | ScheduleBL |
+| StRS-35 | SyRS-38 | SwRS-38 | siehe Belege-Feld der Anforderung |
+| StRS-36 | SyRS-39 | SwRS-37 | siehe Belege-Feld der Anforderung |
+| StRS-36 | SyRS-40 | SwRS-34, SwRS-55 | ReportEngine |
+| StRS-22 | SyRS-41 | — | siehe Belege-Feld der Anforderung |
+| StRS-23 | SyRS-42 | — | siehe Belege-Feld der Anforderung |
+| StRS-38 | SyRS-43 | SwRS-7 | src/backend/Centron.BL/Sales/Support/ExternalToolsReplacementBL.cs |
+| StRS-39 | SyRS-44 | — | siehe Belege-Feld der Anforderung |
+| StRS-12 | SyRS-45 | SwRS-3, SwRS-42, SwRS-50, SwRS-51, SwRS-56 | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs |
+| StRS-14 | SyRS-46 | SwRS-27, SwRS-47 | src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs |
+| StRS-12 | SyRS-47 | SwRS-43 | src/nexus/CentronNexus/Shared/Authorization/ClaimsService.cs |
+| StRS-10 | SyRS-48 | — | SSMS_DB_SCHEMA.sql |
+| StRS-7 | SyRS-49 | SwRS-1, SwRS-49 | AuthenticationTicketBL |
+| StRS-24 | SyRS-50 | SwRS-53 | SSMS_DB_SCHEMA.sql |
+| StRS-8 | SyRS-51 | — | centron\Centron.WPF.UI\Modules\ModuleRightsExpressionParser.cs |
+| StRS-39 | SyRS-52 | SwRS-4, SwRS-54 | siehe Belege-Feld der Anforderung |
+| StRS-36 | SyRS-53 | SwRS-34, SwRS-55 | ReportEngine |
+| StRS-41 | SyRS-54 | — | ProcessBL |
+| StRS-41 | SyRS-55 | — | SSMS_DB_SCHEMA.sql |
+| StRS-11 | SyRS-56 | SwRS-52, SwRS-56 | backend\Centron.Common\TextCoding\AESCryptoLogic.cs |
+| StRS-10 | SyRS-57 | — | webservice\Centron.Host\CentronHost.cs |
+| StRS-9 | SyRS-58 | — | webservice\Centron.Host\AspNetCore\TicketAuthenticationHandler.cs |
+| StRS-11 | SyRS-59 | — | Directory.Build.props |
+| StRS-4 | SyRS-60 | — | backend\Centron.DAO\DAOFactory.cs |
+| StRS-33 | — | SwRS-10 | CampaignBL.cs |
+| StRS-32 | — | SwRS-15 | src/backend/Centron.BL/Sales/Customers/CrmProjects/CrmProjectBL.cs |
+| StRS-25 | — | SwRS-28 | SSMS_DB_SCHEMA.sql |
+| StRS-25 | — | SwRS-29 | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter/PayersAndCostCenterAppModuleControllerView.xaml |
+| StRS-38 | — | SwRS-44 | src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors/Inspectors/Database/RiverbirdTablesCleanupInspector.cs |
+| StRS-26 | — | SwRS-45 | CentronObjectKindNumeric.cs |
+| StRS-34 | — | SwRS-46 | src/backend/Centron.BL/Accounts/TapiBL.cs |
+| StRS-13 | SyRS-56, SyRS-58 | SwRS-42, SwRS-43, SwRS-51, SwRS-52, SwRS-56 | siehe Belege-Feld der Anforderung |
+| StRS-15 | — | — | siehe Belege-Feld der Anforderung |
+| StRS-19 | SyRS-27 | SwRS-6, SwRS-26 | siehe Belege-Feld der Anforderung |
+| StRS-37 | — | — | siehe Belege-Feld der Anforderung |
+| StRS-40 | SyRS-51 | SwRS-30 | siehe Belege-Feld der Anforderung |

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Protokoll.md

@@ -0,0 +1,130 @@
+# Messprotokoll – Iteration 9/qwen/qwen3.8-flash-next/custom/high
+
+> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
+> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
+
+## Lauf
+- **Prompt-Datei:** `02_Prompt.md`
+- **SHA-256 (Prompt):** `5946FC82C45E7A242A1F7367B56B008EE0F5C10373223D3500BCEF4716C76ECD`
+- **Startzeit:** 2026-09-02T14:03:38.8465630+02:00
+- **Endzeit:** 2026-09-02T15:56:15.4515645+02:00
+- **Dauer gesamt:** 01:52:32 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
+- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
+- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 13.0.0
+- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
+- **CLI-Version:** OpenCode 1.18.25
+- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
+- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
+- **Kontrolle Modell:** bestanden
+- **Effort:** `high` angefordert, **wirksam** (`effort_applied: true`)
+- **Ablage:** `Iteration 9/qwen/qwen3.8-flash-next/custom/high/`
+- **Agentenmodus:** `custom`
+- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
+- **Sampling-Parameter:** nicht steuerbar
+- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
+- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
+- **Subagenten:** `spawned` = 24, `completed` = 24, `failed` = 0
+- **Rollen:** {"modulinventar": 2, "faktenermittler": 10, "strs-autor": 2, "syrs-autor": 2, "swrs-autor": 2, "belegpruefer": 1, "konsistenzpruefer": 4, "iso29148-orchestrator": 1}
+
+## Validierungsstichprobe
+- **Stand:** entfaellt
+
+## Verbrauch
+
+| Messgroesse | Wert |
+|---|---|
+| Input-Tokens | 424.078 |
+| Output-Tokens | 90.779 |
+| Reasoning-Tokens | 56.641 |
+| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
+| Agent-Turns | 85 |
+
+**Tokens gesamt: 10.715.498.** 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 | 41 | 26,1 % |
+| SyRS | 60 | 38,2 % |
+| SwRS | 56 | 35,7 % |
+| **Gesamt** | **157** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| Fachregel | 39 | 24,8 % |
+| Sicherheit | 30 | 19,1 % |
+| Daten | 14 | 8,9 % |
+| funktional | 8 | 5,1 % |
+| Schnittstelle | 5 | 3,2 % |
+| nicht-funktional | 4 | 2,5 % |
+| Daten-/Constraintanforderung | 4 | 2,5 % |
+| Datenanforderung / Mapping | 2 | 1,3 % |
+| Funktionsanforderung (interner Algorithmus) | 2 | 1,3 % |
+| Funktions-/Constraintanforderung (Sicherheit) | 2 | 1,3 % |
+| (47 weitere) | 47 | 29,9 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 66 |
+| davon `PRIMÄR` | 29 (43,9 %) |
+| davon `SEKUNDÄR` | 37 (56,1 %) |
+| davon `KONTEXT` | 0 (0,0 %) |
+| Belege je Anforderung (Median) | 0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 28 (17,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 157 | 100,0 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 93 | 59,2 % |
+| als `HYPOTHESE` gekennzeichnet | 64 | 40,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 113 | 72,0 % |
+| mit ISO-25010-Qualitätsmerkmal | 157 | 100,0 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 96 ohne Beleg: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6, SyRS-7, SyRS-8 … |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 33 von 83 ungedeckt: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-7, SyRS-8, SyRS-12, SyRS-16 … |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 157 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 157 von 157 mit Tracelinks (100,0 %) |
+
+## Ergebnis
+- **Status:** `is_error: true`, `subtype: error`, `exit_code: 1`, `timed_out: false`
+- **Session-ID:** `ses_f9dff0fd3ffei0THHf9fgmC3fO`
+- **Werkzeugaufrufe:** 99 – {"bash": 56, "task": 24, "write": 3, "read": 6, "grep": 9, "edit": 1}
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 24
+- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
+- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
+- **Root unveraendert:** ja
+- **Fehlermeldungen:** ["OpenCode beendete sich mit Exitcode 1"]
+
+## Anmerkungen/Auffaelligkeiten
+
+*(von Hand zu ergaenzen)*

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/Stderr.log

@@ -0,0 +1,5 @@
+[2026-09-02T12:03:40.596105+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\Ergebnisse)
+[2026-09-02T12:03:40.785307+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=custom; Effort=high (uebergeben=True); Stall-Timeout=0s
+[2026-09-02T13:56:13.742598+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
+[2026-09-02T13:56:15.396492+00:00] OpenCode export: Exporting session: ses_f9dff0fd3ffei0THHf9fgmC3fO
+[2026-09-02T13:56:15.432775+00:00] Ende: Exitcode=1; Status=error; Turns=85; Tokens=10715498; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\RawResult.json

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/after.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/anforderungen.md

@@ -0,0 +1,68 @@
+## 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 | 41 | 26,1 % |
+| SyRS | 60 | 38,2 % |
+| SwRS | 56 | 35,7 % |
+| **Gesamt** | **157** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| Fachregel | 39 | 24,8 % |
+| Sicherheit | 30 | 19,1 % |
+| Daten | 14 | 8,9 % |
+| funktional | 8 | 5,1 % |
+| Schnittstelle | 5 | 3,2 % |
+| nicht-funktional | 4 | 2,5 % |
+| Daten-/Constraintanforderung | 4 | 2,5 % |
+| Datenanforderung / Mapping | 2 | 1,3 % |
+| Funktionsanforderung (interner Algorithmus) | 2 | 1,3 % |
+| Funktions-/Constraintanforderung (Sicherheit) | 2 | 1,3 % |
+| (47 weitere) | 47 | 29,9 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 66 |
+| davon `PRIMÄR` | 29 (43,9 %) |
+| davon `SEKUNDÄR` | 37 (56,1 %) |
+| davon `KONTEXT` | 0 (0,0 %) |
+| Belege je Anforderung (Median) | 0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 28 (17,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 157 | 100,0 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 93 | 59,2 % |
+| als `HYPOTHESE` gekennzeichnet | 64 | 40,8 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 113 | 72,0 % |
+| mit ISO-25010-Qualitätsmerkmal | 157 | 100,0 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **verletzt** – 96 ohne Beleg: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-5, SyRS-6, SyRS-7, SyRS-8 … |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 33 von 83 ungedeckt: SyRS-1, SyRS-2, SyRS-3, SyRS-4, SyRS-7, SyRS-8, SyRS-12, SyRS-16 … |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 157 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 157 von 157 mit Tracelinks (100,0 %) |
+

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/before.txt

@@ -0,0 +1 @@
+

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/combined_prompt.md

@@ -0,0 +1,218 @@
+# Versuch 02 - Agentengestuetzt - Prompt-Version 03-A
+
+## Metadaten
+- **Versuch:** V2 Agentengestützt (rollenspezialisierte Agentendateien)
+- **Prompt-Version:** 03-A (Prompt-Version 03 aus Versuch 01, angepasst an verteilte Bearbeitung)
+- **Basis:** `Versuche/Versuch_01/03_Prompt.md`, SHA-256 `B8C8764F…C030F07`
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-31
+- **Vorgänger:** `01_Prompt.md` (Prompt-Version 02-A, SHA-256 `DCDC0E3F…B71BCF`), **kein Lauf durchgeführt**
+- **Änderungsgrund gegenüber `01_Prompt.md`:** Version 02-A leitete sich von Prompt-Version **02** ab. Versuch 1 ist inzwischen auf Prompt-Version **03** weitergelaufen (Iteration 8 und 9). Ein V2-Lauf gegen 02-A würde sich von den Vergleichsläufen in **zwei** Größen unterscheiden — Agentenrollen *und* Prompt-Version — und wäre als Wirkungsnachweis der Rollen unbrauchbar. Version 03-A setzt deshalb auf Prompt-Version 03 auf.
+
+  | Änderung gegenüber `Versuch_01/03_Prompt.md` | Grund |
+  |---|---|
+  | Neuer Abschnitt „Arbeitsteilung" | Prompt-Version 03 unterstellt stillschweigend **einen** Bearbeiter: Sie ordnet die Schritte zeitlich, vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck über das Ergebnis. Bei verteilter Bearbeitung ist nichts davon von selbst erfüllt — IDs kollidieren, die Reihenfolge läuft rollenweise auseinander, und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen. |
+  | In der Arbeitsteilung: Ergebnisstruktur gilt unabhängig von der Aufteilung | Die 7-Datei-Regel aus Version 03 entstand an einem `solo`-Lauf (Kimi legte `SwRS-Ergaenzungen.md` an, 18 Anforderungen fielen aus der Auswertung). Bei verteilter Bearbeitung ist eine Datei je Bearbeiter der nächstliegende Fehler — die Regel wird dort ausdrücklich wiederholt. |
+  | In der Arbeitsteilung: **Zuständigkeitsbindung** — eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, wird von ihm ausgeführt | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Der Smoke-Test vom 26.08. zeigte, dass von acht beigestellten Rollen nur zwei genutzt wurden — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist **statisch** deklariert und gehasht und damit eine reproduzierbare Bedingung; sie ist nicht mit den laufzeitabhängigen Adapterinjektionen aus Iteration 8 zu verwechseln, die Lauf 34 unpoolbar machten. |
+  | In der Arbeitsteilung: frei bleiben Zuschnitt, Anzahl, Reihenfolge und Tiefe | Gebunden wird **wer** eine Teilaufgabe ausführt, nicht **wie viel** davon getan wird. Zerlegungstiefe und Aufrufzahl bleiben Untersuchungsgegenstand wie in V1b. |
+  | In der Arbeitsteilung: Dokumentationspflicht zur tatsächlichen Beauftragung | Die Bindung wirkt auf Promptebene und ist damit nicht technisch erzwungen, sondern selbst eine Messgröße. Nur wenn im Lauf festgehalten ist, wer was ausgeführt hat, ist die Einhaltung gegen `subagent_stats` und die Subagenten-Prompts prüfbar. |
+  | Angehängte Tabellenzeilen und Schlussblockquote aus `03_Prompt.md` an ihren Platz gerückt | In `03_Prompt.md` stehen zwei Zeilen der Änderungstabelle **nach** dem Abschnitt „Abschluss" und die Tabelle im Metadatenblock ist leer. Da der Skill die **gesamte** Datei sendet (`_meta/combined_prompt.md`), gingen beide Fehlstellen in jeden Lauf der Iterationen 8 und 9 mit ein. |
+
+  **Der Prompt nennt keine Rolle namentlich.** Er formuliert die Bindung abstrakt; welche Rollen es gibt und wofür sie zuständig sind, stellt der Versuchsaufbau im Block Werkzeugkontext bei. Damit bleibt dieselbe Prompt-Datei auch für einen `solo`-Lauf ohne Rollen gültig — der fachliche Auftrag ist über V1, V2 und V3 identisch, und die Rollenbindung bleibt die einzige unabhängige Variable. Anzahl der Aufrufe, Zerlegungstiefe und Turn-Anzahl werden weiterhin **nicht** vorgegeben; sie bleiben Teil der Untersuchung.
+
+  Unverändert gegenüber Prompt-Version 03 bleiben: Auftrag, Scope, Vorgehensschritte 0 bis 6, Pflicht-Eigenschaften, Blockformat, Belegklassifikation, Prüfidee, Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur, Randbedingungen und Abschluss. Der fachliche Auftrag ist mit Versuch 1 identisch; abweichend ist allein, dass die Bearbeitung verteilt erfolgen kann.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge und Agentenrollen im jeweiligen Lauf
+> zur Verfügung stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau
+> beim Start bei.
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Arbeitsteilung
+
+Die Bearbeitung wird auf mehrere Bearbeiter verteilt. **Stellt der Versuchsaufbau für eine Teilaufgabe einen dafür vorgesehenen Bearbeiter bereit, ist diese Teilaufgabe von ihm auszuführen** — nicht von dir selbst und nicht von einem anderen. Welche Bearbeiter bereitstehen und wofür sie zuständig sind, nennt der Versuchsaufbau; diese Zuständigkeit ist Teil der Aufgabenstellung und keine Empfehlung. Stellt der Versuchsaufbau keine Bearbeiter bereit, bearbeitest du alles selbst und dieser Abschnitt ist ohne Wirkung.
+
+- **Frei bleibt, wie du die Bearbeiter einsetzt.** Den Zuschnitt der Ausschnitte, die Anzahl der Aufträge je Bearbeiter, ihre Reihenfolge, die Tiefe und ob du nachfasst, entscheidest du. Gebunden ist allein, **wer** eine Teilaufgabe ausführt. Teilaufgaben, für die kein Bearbeiter vorgesehen ist — insbesondere der Zuschnitt, die Beauftragung, das Anlegen der Ergebnisdateien und die Übernahme der zurückgemeldeten Befunde —, führst du selbst aus.
+- **Zuständigkeit vor Bearbeitung klären.** Lege fest, wer welchen Ausschnitt bearbeitet, bevor die erste Anforderung entsteht. Ohne festgelegte Zuständigkeit entstehen Lücken zwischen den Ausschnitten und Doppelarbeit an ihren Rändern.
+- **ID-Bereiche vorab vergeben, überschneidungsfrei und lückenlos.** Jeder Bearbeiter erhält einen eigenen Nummernbereich je Ebene. Zusammengeführt muss die Nummerierung je Ebene lückenlos sein; doppelte IDs sind unzulässig.
+- **Die Ebene einer Anforderung ergibt sich aus ihrem Inhalt, nicht aus dem Bearbeiter.** Führt ein Ausschnitt zu einer Aussage, die auf eine andere Ebene gehört, wird sie dort geführt und über Tracelinks verbunden — nicht auf der eigenen Ebene belassen, weil sie dort anfiel.
+- **Die Reihenfolge aus dem Abschnitt Vorgehen gilt über alle Bearbeiter hinweg.** Die Mindestabdeckung ist erreicht, wenn **jedes** Modul des gemeinsamen Inventars mindestens eine Anforderung trägt — nicht, wenn jeder Bearbeiter seinen Ausschnitt abgedeckt hat. Erst danach beginnt die Vertiefung.
+- **Der Konsistenzcheck gilt dem zusammengeführten Ergebnis.** Eine Prüfung des eigenen Beitrags ersetzt ihn nicht. Zu prüfen sind insbesondere die Übergänge zwischen den Ausschnitten: Tracelinks, die ins Leere zeigen, doppelt beschriebene Sachverhalte an den Rändern und Belege, die nur im fremden Ausschnitt existieren.
+- **Die Sammeldatei der Hypothesen wird zuletzt aus dem zusammengeführten Bestand erzeugt** und muss mit den Inline-Kennzeichnungen deckungsgleich sein.
+- **Die Ergebnisstruktur ist von der Arbeitsteilung unabhängig.** Es entstehen genau die sieben vorgegebenen Dateien — keine Datei und kein Abschnitt je Bearbeiter.
+
+**Dokumentationspflicht.** Halte im `Analysebericht.md` fest, welchen Bearbeiter du für welche Teilaufgabe wie oft und mit welchem Zuschnitt beauftragt hast. Hast du eine zugewiesene Teilaufgabe ausnahmsweise selbst ausgeführt, nenne sie ausdrücklich und begründe es. Diese Angabe ist Teil des Ergebnisses, nicht Beiwerk: Ohne sie ist nicht nachvollziehbar, wie die Spezifikation zustande kam, und eine unbemerkte Abweichung von der Zuständigkeit macht den Lauf unauswertbar.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+
+
+### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
+Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
+Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
+die beigestellten Agentenrollen modulinventar, faktenermittler, strs-autor, syrs-autor,
+swrs-autor, belegpruefer, konsistenzpruefer und iso29148-orchestrator.
+Nicht verfügbar sind: externe Werkzeugserver, Webzugriff.
+Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
+Werkzeuge zu ersetzen.
+
+Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
+Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
+
+| Teilaufgabe | Vorgesehener Bearbeiter |
+|---|---|
+| Modulinventar (Schritt 0) | modulinventar |
+| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
+| Formulierung der StRS-Anforderungen | strs-autor |
+| Formulierung der SyRS-Anforderungen | syrs-autor |
+| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
+| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
+| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
+| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
+
+Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
+entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
+lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
+bleiben deine Aufgabe.
+
+### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
+Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
+`C:\DEV\MasterArbeit\Versuche\Versuch_02\Iteration 9\qwen\qwen3.8-flash-next\custom\high\02_Lauf_2026-09-02_140338_v13.0.0-b5bb\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/endzeit.txt

@@ -0,0 +1 @@
+2026-09-02T15:56:15.4515645+02:00

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/opencode-config.json

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

Versuche/Versuch_02/Iteration 9/qwen/qwen3.8-flash-next/custom/high/02_Lauf_2026-09-02_140338_v13.0.0-b5bb/_meta/startzeit.txt

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