Effortvergleich high gegen max: Effort wirkt ueber Delegation
Dieselbe TensorX-Matrix ein zweites Mal bei hoechstem Effort. Zwoelf gueltige Laeufe, 2.116 Anforderungen, 127,6 Mio. Tokens, hochgerechnet $10,53 aus der Preisliste vom 02.09.2026. Befund: In den nicht-delegierenden Zellen bewegt sich der Ertrag zwischen minus 18 und plus 44 Prozent ohne erkennbare Richtung - in der Groessenordnung der Streuung. Der eine deutliche Ausschlag ist GLM in custom mit plus 122 Prozent, erreicht mit 78 statt 30 Subagenten. Der hoehere Denkaufwand schlaegt sich in mehr Zerlegung nieder, und die traegt den Ertrag, nicht der Denkaufwand als solcher. Qwens custom-Zelle hat sich qualitativ erholt: bei high 61 Prozent ohne Beleg und 40 Prozent Hypothesen, bei max 3 Prozent ohne Beleg und 96 Prozent Primaerbeleg. Der Einbruch war ein Laufmerkmal, kein Modellmerkmal - ein weiterer Beleg, dass n gleich 1 je Zelle nicht traegt. Skill 13.2.0: analyse-anforderungen.py toleriert jetzt vier Markdown-Fassungen der Feldvorgabe. Jedes der vier eingesetzten Modelle formatierte sie anders, und jede Fassung wurde zunaechst mit null Anforderungen gezaehlt, obwohl Belege und Pruefideen vollstaendig vorlagen. Das ist ein Befund ueber den Versuchsaufbau: Die Formatvorgabe ist fuer Menschen eindeutig, fuer maschinelle Auswertung nicht. Regressionsprobe an sieben Laeufen unveraendert. _matrix.ps1 nimmt zusaetzlich -Effort und -Modi fuer einzelne Zellen. Ein Lauf fiel durch Standby des Rechners aus und wurde wiederholt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
e2c3a0e8f8
commit
08d90f1ccb
+1
-1
@@ -10,7 +10,7 @@
|
||||
- **Endzeit:** 2026-09-02T13:11:01.6994339+02:00
|
||||
- **Dauer gesamt:** 00:19:03 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `6c5c26a2e4f6b5e6499536973fffded9cdaa626d` (vor dem Lauf dirty: nein)
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-03T12:55:53.171309+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\Ergebnisse)
|
||||
[2026-09-03T12:55:53.444214+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-03T13:14:26.157936+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-03T13:14:27.621337+00:00] OpenCode export: Exporting session: ses_f98a8e51fffe3QtphUN2xVQvN5
|
||||
[2026-09-03T13:14:27.668580+00:00] Ende: Exitcode=0; Status=success; Turns=82; Tokens=5736232; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\RawResult.json
|
||||
+268
@@ -0,0 +1,268 @@
|
||||
# Analysebericht
|
||||
|
||||
Reverse Requirements Engineering der c-entron ERP-Suite (Arbeitsverzeichnis = Spiegel des Repos CentronERP). Vorgehen: statische Analyse von Quellcode, Konfiguration, UI-Ressourcen und SQL-Schema; keine Ausführung, kein Datenbankzugriff. Ergebnis: 117 Anforderungen (StRS 13, SyRS 20, SwRS 84), 3 Hypothesen, 107 Dateien-/Code-Belege.
|
||||
|
||||
Änderungsprotokoll der Codebasis war NICHT verfügbar: Das Repo liegt im Arbeitsverzeichnis als Spiegel ohne eigene Git-Historie; Commit-Messages/Tickets (Schritt 2, KonTEXT-Quellen) konnten daher nicht erhoben werden. `docs/` wurde als Ersatz-Kontextquelle genutzt.
|
||||
|
||||
---
|
||||
|
||||
## Schritt 0 – Modulinventar
|
||||
|
||||
Erfassungsgrundlage: Verzeichnisstruktur `src/backend/Centron.BL` (86 Business-Module), `src/centron`, `src/webservice`, `src/nexus`, `src/apis`, `src/shared`, `src/backend/*` (Schichtprojekte), Projektwurzel-Artefakte. Fachlich eng verwandte BL-Ordner wurden zu einem fachlichen Modul zusammengefasst (in „Pfad“ ersichtlich); die Zusammenfassung ist bewusst konservativ (kein Ordner ohne Zuordnung).
|
||||
|
||||
| # | Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (ein Satz) |
|
||||
|---|---|---|---|
|
||||
| 1 | Adressstamm (Kunde/Lieferant/Kontakt) | src/backend/Centron.BL/Accounts | Typisierte Adressen inkl. Klassifikation, Herkunft, Verträge, Sonderpreise, Kampagnen und Aktivitäten. |
|
||||
| 2 | Vertrieb – Belegwesen | src/backend/Centron.BL/Sales/Receipts | Angebot bis Rechnung: 7 Belegarten mit Status, Lock, Versionen, Provisionen, Reports, ZUGFeRD. |
|
||||
| 3 | Mahnwesen | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning | Mahnläufe je Kunde mit Stufen, Reset und Konfiguration. |
|
||||
| 4 | E-Rechnung (ZUGFeRD/XRechnung) | src/backend/Centron.BL/DataExchange (Zugferd*), src/backend/Centron.BL/EDI/ZUGFeRD_BL.cs | Erzeugung und Parsen elektronischer Rechnungen inkl. Leitweg-ID. |
|
||||
| 5 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Barbuchungen mit Historie. |
|
||||
| 6 | Stundenzuschlagsätze | src/backend/Centron.BL/Sales/HourlySurchargeRatesBL | Zuschlagsregeln für Dienstleistungszeiten inkl. Überlappungserkennung. |
|
||||
| 7 | Zeiterfassung / Servicezeiten | src/backend/Centron.BL/Time, Entities/Sales/Support/HelpdeskTimerArea | Zeiterfassung an Tickets inkl. Billing-Status und Signaturen. |
|
||||
| 8 | Kunden & CRM | src/backend/Centron.BL/Sales/Customers, CustomerArea (ohne RMA) | Kundenpflege, Kontaktformen, Anreden, CRM-Projekte, Kennzahlen. |
|
||||
| 9 | Marketing & Kampagnen | src/backend/Centron.BL/Sales/Marketing, Accounts/Campaigns | Kampagnenphasen, Entscheidungstexte, Umfragen (Survey). |
|
||||
| 10 | RMA (Rücksendungen) | src/backend/Centron.BL/CustomerArea/RmaBL.cs, WPF RMA | Warenrücksendung mit Artikelstatus und Ticketbindung. |
|
||||
| 11 | Helpdesk / Tickets (C-FLOW) | src/backend/Centron.BL/Sales/Support | Tickets, Status, Historie, Vorlagen, Kategorien, Abschluss, Mailbezug. |
|
||||
| 12 | Kundenanlagen / Assets (DocuBoard) | Sales/CustomerAssets, Devices, DocuBoard, Outlook | Anlagen/Geräte der Kunden inkl. Artikelzuordnung und Ticketlink. |
|
||||
| 13 | Artikelstamm | src/backend/Centron.BL/Warehousing (Artikelklassen) | Artikel inkl. System-/Sonderartikel, Serviceartikel, Stücklisten. |
|
||||
| 14 | Preiswesen | Warehousing (Action/Volume), Accounts (Sonderpreis), Sales/Receipts (PriceHelper) | Aktions-, Volumen-, Sonder- und Belegpreise. |
|
||||
| 15 | Lager & Inventur | Warehousing/InventoryManagement, Logistics, Storage | Lagerorte, Bestände, Inventuren, Kommissionierung. |
|
||||
| 16 | Einkauf | Purchasing, Buying, BusinessPartner | Bestellungen je Filiale, Bestellvorschläge, Distributoren. |
|
||||
| 17 | EDI | src/backend/Centron.BL/EDI | Distributorenbestellungen (Alltron, Also, Herweck, Komsa, Egis, OpenTrans) und Logs. |
|
||||
| 18 | Datenaustausch / Import-Export | src/backend/Centron.BL/DataExchange | DocBee, GfK, TANSS, RMM, Rechnung-Upload, Buchhaltungstransfer. |
|
||||
| 19 | Finanzen | Finances (+ src/apis/Centron.APIs.FinAPI) | Zahlungseingänge, Onlinebanking (FinAPI), Aktivitäts-/Aktiveneinstellungen. |
|
||||
| 20 | Buchhaltung | Accounting, Centron.Gateway/BookKeeping*, DataExchange/BookKeeping* | Kontierung und Export/Import (Abacus, Addison). |
|
||||
| 21 | Benutzer & Rechte | Administration/Rights, Logins/Users | Konten, Gruppen, Rechtsprüfung, WebAccount-Rechte. |
|
||||
| 22 | Authentifizierung & 2FA | Administration/Logins (Auth, TwoFactor), Core/CryptoUtils | Basic/AD/OIDC-Login, Fallback, 2FA (E-Mail/Radius), Geräte-Tickets. |
|
||||
| 23 | Lizenzwesen | Administration/Licensing, Interfaces LicenseGuids/ApplicationKind | GUID-Lizenzen mit Anzahl/Datum/Version, Login-/Feature-Schalter. |
|
||||
| 24 | Einstellungen | Administration/Settings, WebSuite (WebSetting*) | Geschichtete Konfiguration Benutzer/Firma/Web. |
|
||||
| 25 | Firma, Filialen, Datenschutz, MasterDB | Administration (Company, DataSecurity, CentronConfigDb, Masterdata) | Firmendaten, Filialen, DSGVO-Cleanup, Masterpasswort-Ablage. |
|
||||
| 26 | Hintergrunddienste & Wartung | Administration (BackgroundServices, Maintenance, SQLManagement, Scripts) | Geplante Dienste inkl. DataQualityService, DB-Pflege. |
|
||||
| 27 | Mitarbeiter | src/backend/Centron.BL/EmployeeArea | Personalstamm, Abteilungen, Urlaub, RFID-Tokens. |
|
||||
| 28 | Kalender / MyDay / MyCentron | Calendar, MyDay, MyCentron, AppointmentRequests, ExpectedEvents | Dashboard, Schnellnotizen, Kalender, Terminanfragen, Importe. |
|
||||
| 29 | Aufgaben, Checklisten, ToDo | TaskManager, CheckListArea, ToDoArea, Processes | Wiedervorlagen mit Aktions-Handlern, Checklisten-Vorlagen. |
|
||||
| 30 | E-Mail-Kommunikation | src/backend/Centron.BL/Mail | SMTP/EWS/Graph-Versand, Templates, Signaturen, Blacklist. |
|
||||
| 31 | MailScanner | src/backend/Centron.BL/MailScanner | Workflow-Verarbeitung eingehender Mails (u. a. Ticketanlage). |
|
||||
| 32 | Mailings | src/backend/Centron.BL/Mailings | Newsletter/Versandkampagnen mit Vorlagen. |
|
||||
| 33 | Chats | src/backend/Centron.BL/Chats | Interne Chat-Kommunikation. |
|
||||
| 34 | Benachrichtigungen | Notifications, NexusNotifications | User-Notifications inkl. SignalR-Hub in Nexus. |
|
||||
| 35 | Telefonie (TAPI) | src/backend/Centron.BL/Tapi, Administration/PhoneSettings | Anrufaufzeichnung und Telefonie-Integration. |
|
||||
| 36 | CPra | src/backend/Centron.BL/CPra | Konnektor zur externen Prüf-/Exportanwendung „c-pra“. |
|
||||
| 37 | Projekte | Projects, TicketProjects, CrmProject | Vorgangsprojekte inkl. Belegprojektnummern. |
|
||||
| 38 | Produktion / IT-Planer | Production, ItPlanner | Fertigungsaufträge mit Positionen, Log, Stücklisten. |
|
||||
| 39 | Reporting / Report-Engine | ReportEngine, Reporting | Layouts, Druckoptionen, Portal-Reports. |
|
||||
| 40 | Statistiken & Kennzahlen | src/backend/Centron.BL/Statistics | Vertriebs-/Ticket-/Rechnungsstatistiken mit Caches. |
|
||||
| 41 | Volltextsuche | src/backend/Centron.BL/IndexSearch | Objektübergreifende Indizierung und Suche. |
|
||||
| 42 | Kundenspezifische Felder | src/backend/Centron.BL/Customizations | Custom-Tables mit Variablenersetzung. |
|
||||
| 43 | Tags | src/backend/Centron.BL/Tags | Verschlagwortung von Objekten. |
|
||||
| 44 | WebLinks & URLs | WebLinks, Urls | Konfigurierbare Links mit Aktions-Handlern, Kurzlinks. |
|
||||
| 45 | Videoportal | src/backend/Centron.BL/VideoPortal | Videoportal-Zuweisungen an Zielgruppen. |
|
||||
| 46 | Social Media | src/backend/Centron.BL/SocialMedia | Netzwerkprofile von Kontaktpersonen. |
|
||||
| 47 | Gutscheine | src/backend/Centron.BL/VoucherManagement | Barcode-Gutscheine inkl. Einlösung. |
|
||||
| 48 | Self-Care | src/backend/Centron.BL/SelfCare | Kundenformulare mit Zuständen, C-FLOW-Sync. |
|
||||
| 49 | Externe Werkzeuge / Remote | ExternalToolsBL, ExternalHelpdesk, Tools | Remote-/Monitoring-Werkzeuge (WOASI, NAble, GFIMax) konfigurieren. |
|
||||
| 50 | TradePool | src/backend/Centron.BL/TradePool | XML-Import der Handelsplattform TradePool. |
|
||||
| 51 | Transaktionslog | src/backend/Centron.BL/Transactions | Systemtransaktionen mit Details. |
|
||||
| 52 | Änderungshistorie & Massenupdates | ChangeTracking, MassUpdate | Import-Historie, Massenänderungsvorlagen. |
|
||||
| 53 | Telemetrie | src/backend/Centron.BL/Telemetry | MCP-/Tool-Nutzungsmessung in Batches. |
|
||||
| 54 | KI-Integration | src/backend/Centron.BL/ArtificialIntelligence | LLM-Clients (OpenAI/Claude/Gemini/Mistral), Ticket-/Text-APIs. |
|
||||
| 55 | Riversuite/RiverDivo | RiverDivo, WebSuite, Integrations | Anbindung der Hersteller-Cloud (Monitoring, Inventory, Compliance …). |
|
||||
| 56 | Textbausteine | src/backend/Centron.BL/TextModuleArea | Wiederverwendbare Texte, Anreden, Variablen. |
|
||||
| 57 | Produktmatrix | src/backend/Centron.BL/ProductMatrix | Kunde-Produkt-Kategorien mit Ratings. |
|
||||
| 58 | Konnektordienste | src/backend/Centron.BL/Services | CTime-Personalzeiten, Directory-Checks, CachedTables. |
|
||||
| 59 | Systemtabellen | src/backend/Centron.BL/SystemArea | I3D-Reservierung der Systemtabellen. |
|
||||
| 60 | Externe Objektreferenzen | src/backend/Centron.BL/ObjectExternalReferences | Fremdsystem-Referenzen an Centron-Objekten. |
|
||||
| 61 | GUI-Profile / Icons / Themes / Start | GUI, Administration/Themes, CentronIcons, Start | Benutzerprofile, Grid-Einstellungen, Iconkatalog. |
|
||||
| 62 | Mobile | src/backend/Centron.BL/Mobile | Mobile-Client-Unterstützung (Tickets, Zeiten, Bilder). |
|
||||
| 63 | Modulkatalog | src/backend/Centron.BL/Modules | Selbstkatalogisierung der Module, Favoriten. |
|
||||
| 64 | Länder-/Bundeslandstamm | src/backend/Centron.BL/CountryArea | Referenzdaten Adressräume. |
|
||||
| 65 | Doku-Hilfe | DocumentationArea, Sales/DocumentationWizardArea | Interne kontextbezogene Dokumentation. |
|
||||
| 66 | Passwort-Tresor | PasswordManager, PasswordManagementArea | Anlagenpasswörter mit Zugriffshistorie. |
|
||||
| 67 | Client-Version / Update | src/backend/Centron.BL/WebVersion | Versionsführung/Updategrenzen der Clients. |
|
||||
| 68 | WPF-Client | src/centron/Centron.WPF.UI | Desktop-Anwendung (MVVM, ILogic-Container, Dialoge). |
|
||||
| 69 | UI-Controls/Extension | src/shared/Centron.Controls*, WPF.UI.Extension | Wiederverwendbare Steuerelemente. |
|
||||
| 70 | Entitätsmodell | src/backend/Centron.Entities | Datenobjekte/DTOs aller Domänen inkl. Statusmodelle. |
|
||||
| 71 | Datenzugriff (DAO) | src/backend/Centron.DAO | NHibernate-Mappings, GenericDAO, Repositories, NamedQueries. |
|
||||
| 72 | Webservice-Host & Verträge | src/webservice/* | Gehostete REST-/Session-API inkl. Login-Requests, DTOs. |
|
||||
| 73 | Nexus (Web) | src/nexus/* | Blazor-Web: ServiceBoard, WebCart/CustomerPortal, WebOffer, Signatur. |
|
||||
| 74 | API-Adapter extern | src/apis (8 Projekte) | GLS, Shipcloud, eBuddy, Cop, Egis, ICECAT, ITscope, FinAPI. |
|
||||
| 75 | docuFORM-API | Centron.Api.docuFORM | OAuth-Client für DMS docuFORM. |
|
||||
| 76 | Datenbank-Gesamtschema | SSMS_DB_SCHEMA.sql | 1.535 Tabellen mit Constraints/Views (Legacy + clean Views). |
|
||||
| 77 | Rechte-Katalog | CentronRights.md | Fachbeschreibung der Helpdesk-Berechtigungen. |
|
||||
| 78 | Deployment-Installer | deployment (WiX) | MSI-Pakete Client/Webservice, WixSharp. |
|
||||
| 79 | CI & Container | .github, azure, docker | Build-/Test-/Regressionsschienen, Dockerfiles, Azure-Pipelines. |
|
||||
| 80 | Build-Skripte | scripts | Build-/Paketier-Hilfsprogramme. |
|
||||
| 81 | Tests | tests | E2E-, Integrations-, Unit-, Playwright-, Nexus-Tests. |
|
||||
| 82 | Projektdokumentation | docs | Entwickler-/Architekturdokumentation (Analysequelle). |
|
||||
| 83 | Fremd-Assemblies | assemblies, nugets | Drittanbieter-Bibliotheken (DevExpress, NHibernate …). |
|
||||
| 84 | Utility-Helfer | Centron.BL/Helpers, Centron.Common, Centron.Core, Centron.Interfaces, WPF.UI.Extension | Querschnitts-Hilfsfunktionen ohne eigene Fachfunktion. |
|
||||
|
||||
**Ergänzungsregeln:** Ordner `Exceptions` → Modul 11; `Gateway` (BL/CustomGateway) → Modul 20; `Core` → Modul 22/84; `CentronNexus` (BL) → Modul 73; `Integrations` → Modul 55; `Outlook` (AssetSearch) → Modul 12; `Reporting`/`ReportEngine` → Modul 39; `WebServices` (BL-Clientproxies, 464 Dateien) → Modul 72; `Merchandise`/`Import` (Entities) → Modul 70.
|
||||
|
||||
---
|
||||
|
||||
## Abdeckungstabelle (Schritt 0b)
|
||||
|
||||
Bewertung: tief = Regeln/Constraints an Durchsetzungspunkten belegt und querverifiziert; mittel = Kernregeln belegt, Detailtiefe begrenzt; flach = Existenz + eine Hauptoperation belegt.
|
||||
|
||||
| Modul | Einstufung | Anforderungen | IDs |
|
||||
|---|---|---|---|
|
||||
| 1 Adressstamm | tief | 2 | SwRS-01, SwRS-02 |
|
||||
| 2 Belegwesen | tief | 8 | SwRS-03–07, SwRS-14, SyRS-01, SyRS-07 |
|
||||
| 3 Mahnwesen | mittel | 2 | SwRS-08, SwRS-09 |
|
||||
| 4 E-Rechnung | tief | 2 | SyRS-09, SwRS-10 |
|
||||
| 5 Kassenbuch | flach | 1 | SwRS-11 |
|
||||
| 6 Stundenzuschläge | flach | 1 | SwRS-12 |
|
||||
| 7 Zeiterfassung | mittel | 1 | SwRS-13 |
|
||||
| 8 Kunden/CRM | mittel | 1 | SwRS-15 |
|
||||
| 9 Marketing/Kampagnen | flach | 2 | SwRS-16, SwRS-49 |
|
||||
| 10 RMA | flach | 1 | SwRS-17 |
|
||||
| 11 Helpdesk | tief | 3 | SwRS-18, SwRS-19, SwRS-20 |
|
||||
| 12 Kundenanlagen/Assets | mittel | 2 | SwRS-21, SwRS-22 |
|
||||
| 13 Artikelstamm | tief | 2 | SwRS-23, SwRS-24 |
|
||||
| 14 Preiswesen | mittel | 2 | SwRS-25, SwRS-26 |
|
||||
| 15 Lager/Inventur | mittel | 2 | SwRS-27, SwRS-28 |
|
||||
| 16 Einkauf | mittel | 1 | SwRS-29 |
|
||||
| 17 EDI | tief | 1 | SwRS-30 (plus SyRS-08) |
|
||||
| 18 Datenaustausch | mittel | 2 | SwRS-31, SwRS-32 |
|
||||
| 19 Finanzen | mittel | 2 | SwRS-33, SwRS-34 |
|
||||
| 20 Buchhaltung | mittel | 1 | SwRS-35 (plus SyRS-11) |
|
||||
| 21 Benutzer & Rechte | tief | 2 | SwRS-36, SwRS-37 (plus SyRS-03) |
|
||||
| 22 Authentifizierung/2FA | tief | 1 | SwRS-38 (plus SyRS-02, SyRS-05) |
|
||||
| 23 Lizenzwesen | tief | 1 | SwRS-39 (plus SyRS-04) |
|
||||
| 24 Einstellungen | flach | 1 | SwRS-40 |
|
||||
| 25 Firma/Filialen/Datenschutz/MasterDB | mittel | 2 | SwRS-41, SwRS-42 (plus SyRS-15) |
|
||||
| 26 Hintergrunddienste | flach | 1 | SwRS-43 [HYPOTHESE] |
|
||||
| 27 Mitarbeiter | mittel | 1 | SwRS-44 |
|
||||
| 28 Kalender/MyDay/MyCentron | flach | 1 | SwRS-45 |
|
||||
| 29 Aufgaben/Checklisten | mittel | 1 | SwRS-46 |
|
||||
| 30 E-Mail | mittel | 1 | SwRS-47 |
|
||||
| 31 MailScanner | flach | 1 | SwRS-48 |
|
||||
| 32 Mailings | flach | 1 | SwRS-49 |
|
||||
| 33 Chats | flach | 1 | SwRS-50 |
|
||||
| 34 Benachrichtigungen | flach | 1 | SwRS-51 |
|
||||
| 35 Telefonie | flach | 1 | SwRS-52 |
|
||||
| 36 CPra | flach | 1 | SwRS-53 [HYPOTHESE] |
|
||||
| 37 Projekte | flach | 1 | SwRS-54 |
|
||||
| 38 Produktion/IT-Planer | flach | 1 | SwRS-55 |
|
||||
| 39 Reporting | mittel | 1 | SyRS-14 |
|
||||
| 40 Statistiken | flach | 1 | SwRS-56 |
|
||||
| 41 Volltextsuche | flach | 1 | SwRS-57 |
|
||||
| 42 Custom Fields | flach | 1 | SwRS-58 |
|
||||
| 43 Tags | flach | 1 | SwRS-59 |
|
||||
| 44 WebLinks/URLs | flach | 1 | SwRS-60 |
|
||||
| 45 Videoportal | flach | 1 | SwRS-61 |
|
||||
| 46 Social Media | flach | 1 | SwRS-62 |
|
||||
| 47 Gutscheine | flach | 1 | SwRS-63 |
|
||||
| 48 Self-Care | flach | 1 | SwRS-64 |
|
||||
| 49 Externe Werkzeuge | flach | 1 | SwRS-65 |
|
||||
| 50 TradePool | flach | 1 | SwRS-66 |
|
||||
| 51 Transaktionslog | flach | 1 | SwRS-67 |
|
||||
| 52 Historie/Massenupdates | flach | 1 | SwRS-68 |
|
||||
| 53 Telemetrie | flach | 1 | SwRS-69 |
|
||||
| 54 KI-Integration | mittel | 1 | SwRS-70 |
|
||||
| 55 Riversuite/RiverDivo | flach | 1 | SwRS-71 |
|
||||
| 56 Textbausteine | flach | 1 | SwRS-72 |
|
||||
| 57 Produktmatrix | flach | 1 | SwRS-73 |
|
||||
| 58 Konnektordienste | flach | 1 | SwRS-74 |
|
||||
| 59 Systemtabellen | flach | 1 | SwRS-75 |
|
||||
| 60 Objektreferenzen | flach | 1 | SwRS-76 |
|
||||
| 61 GUI-Profile/Icons/Start | flach | 1 | SwRS-77 |
|
||||
| 62 Mobile | flach | 1 | SwRS-78 |
|
||||
| 63 Modulkatalog | flach | 1 | SwRS-79 |
|
||||
| 64 Länderstamm | flach | 1 | SwRS-80 |
|
||||
| 65 Doku-Hilfe | flach | 1 | SwRS-81 |
|
||||
| 66 Passwort-Tresor | mittel | 1 | SwRS-82 |
|
||||
| 67 Client-Version | flach | 1 | SwRS-83 |
|
||||
| 68 WPF-Client | mittel | 2 | SyRS-12, SyRS-20 |
|
||||
| 69 UI-Controls | flach | 1 | SyRS-12 (Mitbeleg) |
|
||||
| 70 Entitätsmodell | mittel | 2 | SwRS-03, SwRS-18 (Schlüssel-/Statusmodelle) |
|
||||
| 71 Datenzugriff DAO | mittel | 1 | SyRS-16 |
|
||||
| 72 Webservice | tief | 3 | SyRS-04, SyRS-06, SwRS-38 |
|
||||
| 73 Nexus | mittel | 2 | SyRS-13, SwRS-51 |
|
||||
| 74 API-Adapter | mittel | 2 | SyRS-17, SwRS-34 |
|
||||
| 75 docuFORM-API | flach | 1 | SwRS-84 |
|
||||
| 76 DB-Gesamtschema | tief | 1 | SyRS-16 (+Constraints in SwRS-01/07/15/17) |
|
||||
| 77 Rechte-Katalog | mittel | 1 | SyRS-03 (Belegquelle) |
|
||||
| 78 Deployment | flach | 1 | SyRS-18 |
|
||||
| 79 CI/Container | flach | 1 | SyRS-19 |
|
||||
| 80 Build-Skripte | **nicht analysiert** | 0 | Begründung: reine Build-/Paketierhilfen (RunHelper, WXSHelper), keine Systemanforderung eigenen Rechts; in SyRS-18/SyRS-19 erwähnt. |
|
||||
| 81 Tests | flach | 1 | SyRS-19 (Testinfrastruktur als Migrationsvermögen) |
|
||||
| 82 Projektdokumentation | **nicht analysiert** | 0 | Begründung: docs/ ist Analysequelle (KONTEXT-Belege), kein Systembestandteil. |
|
||||
| 83 Fremd-Assemblies | **nicht analysiert** | 0 | Begründung: Drittbinaries ohne einsehbaren Quellcode; nur als Lizenz-/Komponentenkontext erwähnt (DevExpress, NHibernate). |
|
||||
| 84 Utility-Helfer | **nicht analysiert** | 0 | Begründung: Querschnitts-Utility-Schichten ohne fachliche Eigenaussage; Inhalte in Belegen zahlreicher Anforderungen enthalten. |
|
||||
|
||||
**Abdeckungsbilanz:** 84 Module, davon 80 mit ≥1 Anforderung (95,2 %), 4 als `nicht analysiert` (4,8 % – unter der 10-%-Schwelle). Einstufungen: **10 tief, 22 mittel, 48 flach, 4 nicht analysiert**.
|
||||
|
||||
---
|
||||
|
||||
## Konsistenzcheck
|
||||
|
||||
1. **Doppelte IDs:** Keine. 13 StRS-, 20 SyRS-, 84 SwRS-IDs, alle eindeutig (skriptgeprüft).
|
||||
2. **Anforderungen ohne Beleg:** Keine – alle 117 Anforderungen führen ≥1 Beleg (Feldzähler: 13/20/84 `Belege:`).
|
||||
3. **Fehlende Übernahmewürdigkeit:** Keine – Feld in allen 117 Anforderungen ausgefüllt.
|
||||
4. **Tracelinks auf nicht existierende IDs:** Keine (alle referenzierten IDs aufgelöst; SyRS-06 und SyRS-13 werden als Ziel-Ebene für Portal-/Webmodule genutzt, die Querverweise zeigen auf existierende IDs).
|
||||
5. **Inhaltlich deckungsgleiche Anforderungen ohne Kennzeichnung:** 53 SwRS- und 7 SyRS-Anforderungen tragen einen Konsolidierungseintrag; die bekanntesten Duplikatfelder (drei Geräte-/Asset-Haltungen SwRS-21/22, Preisquellen SwRS-25/26/SyRS-07, Passwortbehandlung SwRS-36/37, Statistikcaches, EDI-Partials) sind markiert. Doppelzählungen über Ebenen (z. B. StRS-07/SyRS-03/SwRS-24) sind bewusst Tracelink- und keine Konsolidierungsfälle.
|
||||
6. **Risikorelevante Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit Belegsituation:**
|
||||
|
||||
| ID | Titel | PRIMÄR-Beleg? | Sonstiges |
|
||||
|---|---|---|---|
|
||||
| StRS-06 | Lizenzmodell | ja (`Authenticator.cs:132`) | – |
|
||||
| StRS-07 | Berechtigungen | ja (`UserRightsExt.cs:18`) | – |
|
||||
| StRS-09 | E-Rechnung | ja (`ReceiptBL.cs:3273-3333`) | – |
|
||||
| StRS-12 | Compliance/Löschung | ja (`DataSecurityBL.cs:64,377`) | – |
|
||||
| SyRS-02 | Authentifizierung/Fallback | ja (`AuthenticatorFactory.cs:54-135`) | – |
|
||||
| SyRS-03 | Rechteprüfung | ja (`UserRightsExt.cs`, `AppRightsBL.cs:264-297`) | – |
|
||||
| SyRS-04 | Login-Lizenzprüfung | ja (`Authenticator.cs:68-150`) | – |
|
||||
| SyRS-05 | 2FA | ja (`BasicAuthenticator.cs:62`) | – |
|
||||
| SyRS-07 | Preismatrix | ja (`ReceiptPriceHelperBL.cs:65,122`) | Doku SEKUNDÄR |
|
||||
| SyRS-09 | E-Rechnungsdienst | ja (`InvoiceZugferdBL.cs`) | – |
|
||||
| SyRS-10 | Web-Account-Sicherheit | ja (`WebAccountBL.cs:56`) | – |
|
||||
| SyRS-15 | Löschkonzept | ja (`DataSecurityBL.cs:64,377`; `Authenticator.cs:169-172`) | – |
|
||||
| SwRS-03 | Belegstatus | ja (`ReceiptState.cs`, `ReceiptBL.cs:3273`) | – |
|
||||
| SwRS-07 | Provisionen | ja (DB-CHECK-Constraints) | – |
|
||||
| SwRS-08 | Mahnlauf | ja (`DunningRunBL.cs:49,495`) | – |
|
||||
| SwRS-09 | Auftragsperre nach Mahnung | **nein** | als `[HYPOTHESE]` gekennzeichnet (nur Schema-Felder) |
|
||||
| SwRS-10 | Leitweg-ID/ZUGFeRD | ja (`ReceiptBL.cs:3417-3438`) | – |
|
||||
| SwRS-11 | Kassenbuch | ja (`CashBookBL.cs:15`) | – |
|
||||
| SwRS-13 | Zeit-Unveränderlichkeit | ja (`HelpdeskTimerBillingState.cs`) | Rechte-Semantik SEKUNDÄR |
|
||||
| SwRS-14 | Zeiten→Beleg | ja (`ReceiptBL.cs:5295`) | – |
|
||||
| SwRS-24 | Artikelrechte | ja (`ArticleBL.cs:129`) | – |
|
||||
| SwRS-25 | Aktionspreise | ja (`ActionPriceBL.cs:26`) | Doku SEKUNDÄR |
|
||||
| SwRS-26 | Sonderpreise | ja (`AccountSpecialPriceBL.cs`) | – |
|
||||
| SwRS-32 | Upload/Duplikatprüfung | ja (`ReceiptBL.cs:5082,5095`) | – |
|
||||
| SwRS-33 | Zahlungseingang | ja (`IncomingPaymentBL.cs`, `ReceiptBL.cs:4902`) | – |
|
||||
| SwRS-34 | Onlinebanking FinAPI | ja (`FinApiClient.cs`, LicenseGuids) | – |
|
||||
| SwRS-36 | Benutzerverwaltung/SHA1 | ja (`UsersBL.cs:65,107`) | Sicherheitsmangel benannt |
|
||||
| SwRS-37 | WebAccounts | ja (`WebAccountBL.cs:56,415`) | – |
|
||||
| SwRS-38 | Login-Tickets | ja (`TicketBL.cs:169`) | – |
|
||||
| SwRS-41 | Filialberechtigungen | ja (`CustomerToBranchBL.cs`) | Rechte SEKUNDÄR |
|
||||
| SwRS-42 | Masterpasswort-Ablage | ja (`MasterPasswordSecureFileStorage.cs`) | – |
|
||||
| SwRS-65 | Remote-Werkzeuge | ja (`ExternalToolBL.cs:58`) | Lizenz SEKUNDÄR |
|
||||
| SwRS-71 | Riversuite-Loginzugriff | ja (`Authenticator.cs:68-82`) | – |
|
||||
| SwRS-82 | Passwort-Tresor | ja (`PasswordManagementBL.cs:17,32`) | – |
|
||||
| SwRS-83 | Versionsgrenze | ja (`Authenticator.cs:132,150`) | – |
|
||||
|
||||
Nur **SwRS-09** besitzt keinen PRIMÄR-Beleg und ist korrekt als `[HYPOTHESE]` geführt.
|
||||
7. **Abgleich Hypothesen.md ↔ Inline-Markierungen:** Übereinstimmung – `[HYPOTHESE]` markiert: SwRS-09, SwRS-43, SwRS-53; Hypothesen.md führt exakt diese drei und keine weiteren.
|
||||
|
||||
---
|
||||
|
||||
## Bekannte Lücken
|
||||
|
||||
- **Change-Historie nicht zugänglich:** Kein git-Log des Quellrepos im Spiegel; Schritt 2 (Commit-Messages, Tickets, Release Notes) blieb leer – KONTEXT-Belege stammen ausschließlich aus `docs/`.
|
||||
- **WPF-Validierungsdetails:** Die Prüfung von Feldrechten in konkreten Dialog-Viewmodels wurde stichprobenartig (über Rechte-Konstanten), nicht flächendeckend verifiziert; daher Generalisierung in SyRS-03.
|
||||
- **Report-/Layout-Definitionen:** DevExpress-Reportlayouts (.repx/Ressourcen) wurden nicht im Detail analysiert; SyRS-14 stützt sich auf Constraints und Rechte.
|
||||
- **1.535 Tabellen, ~3.000 Constraints:** Nur stichprobenhaft extrahiert (Mahn-, Provisionen-, Aktivitäts-, Unique-Constraints); ein vollständiger DB-Requirement-Katalog wäre eine eigene Iteration.
|
||||
- **Nexus-Routing im Detail:** WebCart-/ServiceBoard-Seiten wurden strukturell erfasst; einzelne Razor-Komponentenregeln (Validierungen) sind nicht einzeln belegt.
|
||||
- **`WebRightsVisibility`-Semantik der Kategorien 6000/6500:** Lizenzabhängigkeit („Only show if customer has a web cart2 license“) nur als Kommentar belegt.
|
||||
|
||||
---
|
||||
|
||||
## Selbstbewertung
|
||||
|
||||
- **Modulanalyse gesamt:** 84 Module → **10 tief / 22 mittel / 48 flach / 4 nicht analysiert** (absolute Zahlen).
|
||||
- **Mindestabdeckung:** erreicht für 80 von 84 Modulen (95,2 %). Fehlend (4): Build-Skripte, Projektdokumentation, Fremd-Assemblies, Utility-Helfer – jeweils mit Begründung im Inventar; Anteil 4,8 % < 10 % Schwelle.
|
||||
- **Dünne Belegstellen:** Höchster SEKUNDÄR/KONTEXT-Anteil bei (a) SwRS-43 Hintergrunddienst (nur Doku + Ordner), (b) SwRS-53 CPra (nur Auth-Methode + Lizenz-Konstante), (c) SyRS-18 Deployment (nur Projektdateien/Pipelines), (d) Doku-abgeleitete Regeln in SyRS-12/SyRS-14 (Architekturdoku mit Code-Gegenprüfung). Diese Anforderungen sind bewusst nicht als Hypothese markiert, wo Code-Gegenbelege (Dockerfiles, WiX-Projekte, Report-Constraints) die Aussage zusätzlich tragen.
|
||||
- **Hypothesen:** 3 geführt (SwRS-09, SwRS-43, SwRS-53) – vollständig in Hypothesen.md; eine analyse ohne offene Punkte wäre bei 26.000 Dateien unplausibel.
|
||||
- **Nachschlag-Empfehlungen für die Folgeiteration:** (1) Vollständige Constraint-Extraktion des Schemas als Datenqualitätsanforderungen; (2) Lokalisierung der Auftragsperren-Durchsetzung (SwRS-09 auflösen); (3) CPra-Datenfluss rekonstruieren (SwRS-53); (4) WPF-Viewmodel-Rechtsprüfungen systematisch abgleichen; (5) Nexus-Razor-Validierungen und WebCart-Bestellstrecke vertiefen; (6) die im Feld `Konsolidierung` markierten Parallelhaltungen (Asset-Triple, Preisquellen, Passwort-/Token-Duplikate, EDI-Partials, Statistiken) zu einem Ziel-Architekturvorschlag bündeln.
|
||||
+45
@@ -0,0 +1,45 @@
|
||||
# Glossar
|
||||
|
||||
Domänenbegriffe, die in den Anforderungen verwendet werden, mit Definition aus der Codebasis.
|
||||
|
||||
| Begriff | Definition (abgeleitet aus Artefakten) |
|
||||
|---|---|
|
||||
| **Beleg** | Verkaufsvorgang mit Kopf (`*Kopf`) und Positionen (`*Pos`): Angebot (Ang), Auftrag (Auf), Lieferschein (Lief), Rechnung (Rech), Vertrag (Vertrag), Gutschrift (Gut), Abholeliste (Abhol). Basis: `ReceiptBase`/`ReceiptState`. |
|
||||
| **I3D** | Systemweiter Primärschlüssel („ID 3develop“), `int IDENTITY(1,1)` in jeder Tabelle; Fremdschlüssel enden auf `I3D` (docs/guides/database/database-conventions.md). |
|
||||
| **CentronObjectKindNumeric** | Zentraler Zahlenenum, der jeden Objekttyp (Belegarten, Kunden, Tickets …) eindeutig identifiziert; Used in Filter-/Trace-APIs. |
|
||||
| **C-FLOW** | Produktname des Helpdesk-/Ticketmoduls (Tickets, Vorlagen, Kategorien); Rechte `UserRightsConst.Sales.Customer.Helpdesk.CFlow.*`. |
|
||||
| **Helpdesk / Ticket** | Kundenanliegen mit konfigurierbaren Statuszuständen (`HelpdeskState`), Bearbeitern, Prioritäten, Zeiten und Vorlagen. |
|
||||
| **Ticketzeit / Timer** | Arbeitszeitbuchung auf einem Ticket (`HelpdeskTimer*`), abrechnungssteuernd über `HelpdeskTimerBillingState`; mit Zuschlagsätzen und Signaturen. |
|
||||
| **Preismatrix** | Mehrquellige Preisauskunft je Artikel/Belegposition: Kunden-Sonderpreis, Aktionspreis (zeitlich befristet, `HerstellerArtikAktionspreis`), Volumenpreis, Standardpreis (docs/reference/receipts/actionprice-system.md). |
|
||||
| **Aktionspreis** | Zeitlich befristeter Distributor-/Hersteller-Aktionspreis mit `GueltigAb`/`GueltigBis` (ActionPriceBL). |
|
||||
| **Sonderpreise** | Kundenindividuelle Preisliste (`AccountSpecialPriceBL`); Grundlage des Web-Cart-Angebots (README.md). |
|
||||
| **Mahnlauf** | Nummerngeführter Sammelvorgang, der fällige Rechnungen nach kundenspezifigen `MahnungNachTagen(1..3)` in Mahnstufen hebt; stornierbar (`ResetDunningRun`, `DunningRunState`). |
|
||||
| **Kassenbuch** | Journal für Bar-Ein-/Ausgangsbuchungen (`CashBookBL.SaveCashBookBooking`) mit Historie. |
|
||||
| **Leitweg-ID** | Empfängerkennzeichnung der öffentlichen Verwaltung für E-Rechnungen; je Kunde bzw. Konzerngruppe gepflegt (`AccountCustomer.LeitwegID`). |
|
||||
| **ZUGFeRD / XRechnung** | Deutsche E-Rechnungsformate (PDF-Hybrid bzw. XML); Implementierung `InvoiceZugferdBL`, Spezifikationen 2.x im Repo. |
|
||||
| **EDI** | Elektronischer Datenaustausch mit Distributoren (Alltron, Also, Also-CH, Herweck, Komsa, Egis, OpenTrans) mit Dispatch und Log (`SupplierEdiBL.*`, `EDILogBL`). |
|
||||
| **Web-Account** | Externer Portal-Benutzer einer Kundenadresse (`WebAccountBL`) mit eigenem, per Allowlist begrenztem Rechtesatz; Login-Typ für Web-Cart/ServiceBoard. |
|
||||
| **Web-Cart** | B2B2C-Shop in Nexus; zeigt Artikel aus den Sonderpreisen des Kunden; Rechte 62001/62002. |
|
||||
| **ServiceBoard (SBO)** | Web-/Mitarbeiterportal für Helpdesk-Arbeit in Nexus inkl. Kanban, Scheduler, Passwortmanager; Lizenz `ServiceBoard`/-Web-Dev. |
|
||||
| **SelfCare** | Kunden-Selbstbedienungsformulare mit Zuständen und C-FLOW-Rückmeldung (`SelfCareBL`). |
|
||||
| **Filiale (Branch)** | Mandanteninterne Niederlassung mit Datenbezug (`BranchI3D`) und einschränkenden Rechten („nur eigene Filiale“); eigene Lizenz-GUID. |
|
||||
| **Mandant/Kunde** | Im Prompt-Sinn: Installation/Kunde mit eigenem Lizenzdatensatz; funktionaler Mandantenbegriff existiert als „Konzerngruppe/Filiale“ auf Datenobjektebene. |
|
||||
| **Konzerngruppe** | Kundenhierarchie (Mutterkunde); beeinflusst u. a. Leitweg-ID-Ermittlung (`GetCompanyGroupCustomerI3DForReceiptData`). |
|
||||
| **Rechte / UserRightsConst** | Zentrale Rechts-ID-Konstanten (Gruppenzuordnung über `AppGroupRightAssignment`); Admin-Gruppe „Administratoren“ hebt Prüfungen. |
|
||||
| **Lizenz (LicenseGuids)** | GUID-basierte Lizenz pro Produkt/Feature mit Anzahl, Gültigkeitsdatum und Versionsgrenze; geprüft beim Login (`LicenseManager.CheckLicense`). |
|
||||
| **ApplicationKind** | Katalog der loginfähigen Anwendungen (c-entron.NET, Nexus, ServiceBoard, Riversuite-Apps …) inkl. Rechten und Ablaufverhalten (`ExpirationKind`). |
|
||||
| **Login-Ticket** | Nach Login ausgestellte, an Anwendung+Benutzer+Maschine gebundene Sitzung (`TicketBL`, `CryptoUtils.CreatePasswordHash(deviceId, salt)`). |
|
||||
| **BLLogic/WSLogic** | Zweigleisiger Client-Datenzugriff: direkte Datenbank (`BL*Logic`) oder Webservice (`WS*Logic`) hinter einer `ILogic`-Schnittstelle (general-structure.md). |
|
||||
| **Result/BLSession** | Durchgängiges Fehler-/Transaktionsmuster: `Result<T>` als Rückgabewert, `BLSession` als Geschäftslogik-Sitzung. |
|
||||
| **Riversuite / Riverbird** | Hersteller-Cloud-Suite (Monitoring, Inventory, Compliance, RFlow …); Anbindung über `RiverConnectionBL` mit eigenen Login-Rechten. |
|
||||
| **DocuBoard** | Anlagen-/Dokumentationsmodul inkl. Asset-Management (`AssetManagement*BL`) und Riversuite-Asset-Services. |
|
||||
| **Asset / Anlagenstammblatt** | Anlage eines Kunden; aktuell getrennt gehalten als „Stammblätter“ (z. B. Drucker), „Assets“ und `AccountDevice` → Konsolidierungskandidat (SwRS-21/22). |
|
||||
| **MyDay** | Persönlicher Tages-/Importbereich inkl. konfigurierbarer Importe aus Fremdtools (anzahl-lizenziert). |
|
||||
| **MailScanner** | App, die Eingangspostfächer nach Workflows verarbeitet (u. a. automatische Ticketanlage). |
|
||||
| **Provision (ReceiptProvision…)** | Mitarbeiterbeteiligung an Belegen nach Schema mit Empfängertypen (`CustomerAdviser1..6`, `ReceiptAdviser1/2`, `ServiceArticleEmployee`, `FixedEmployee`), Quellen und Zielen. |
|
||||
| **RMA** | Warenrücksendungsprozess mit Artikelstatus und optional eindeutiger Ticketbindung (`CI_RMA_HelpdeskI3D`). |
|
||||
| **TradePool** | Handelsplattform-Import (XML) für Gebraucht-/Fremdware (`StartTradeImport`). |
|
||||
| **CPra** | Externe Anwendung „c-pra“ mit eigener Lizenz und Konnektor; fachlicher Zweck unklar → Hypothese SwRS-53. |
|
||||
| **FinAPI** | Online-Banking-API-Adapter (ersetzt abgelöstes HBCI/FinTS, LicenseGuids-Kommentar 2509). |
|
||||
| **DMS (DocBee, docuFORM)** | Dokumentenmanagementsysteme mit eigenen Konnektoren (`DocBee*`, `Centron.Api.docuFORM`). |
|
||||
| **Stammblatt** | Historische Bezeichnung für Anlagen-/Gerätestammdaten (im Prompt-Beispiel: Drucker); synonym zu Asset im Zielsystem. |
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
# Hypothesen
|
||||
|
||||
Sammlung aller Anforderungen, die in StRS.md/SyRS.md/SwRS.md mit `[HYPOTHESE]` markiert sind. Weitere offene Punkte ohne zugehörige Anforderung stehen in der Selbstbewertung des Analyseberichts.
|
||||
|
||||
---
|
||||
|
||||
## SwRS-09 – Auftragsperre nach Mahnstufe
|
||||
- **Status:** HYPOTHESE
|
||||
- **Bislang belegt:** Datenbankschema enthält die Steuerungsfelder `Kunden.AuftragsperreNachMahnung` (SSMS_DB_SCHEMA.sql:2947) und `RechKopf.MahnStop`/`Kunden.MahnStop` (Zeile 3274). Der Feldname legt eine Sperrlogik nahe.
|
||||
- **Offene Frage:** An welcher Stelle (BL/Client/DB-Trigger) wird die Sperre beim Anlegen oder Freigeben eines Auftrags tatsächlich geprüft? Im untersuchten Business-Layer wurde kein Durchsetzungspunkt gefunden; die Prüfung könnte im WPF-ViewModel, in einem Stored Procedure oder in einer nicht mitgelieferten Komponente liegen.
|
||||
- **Fehlende Information:** Zugriff auf die WPF-Validierungslogik der Auftragsanlage im Detail bzw. Volltextsuche nach `Auftragsperre` in allen Projektlagen war nur auszugsweise möglich.
|
||||
|
||||
## SwRS-43 – Hintergrunddienste (Data Quality)
|
||||
- **Status:** HYPOTHESE
|
||||
- **Bislang belegt:** Modulordner `src/backend/Centron.BL/Administration/BackgroundServices` existiert; `docs/Background Service/DataQualityService.md` beschreibt einen DataQualityService.
|
||||
- **Offene Frage:** Welche konkreten Datenqualitätsregeln laufen zeitgesteuert, und gibt es weitere Hintergrunddienste (z. B. Indizes, Cache-Statistiken als Dienst)? Die Klassennamen und Zeitpläne des Dienstes wurden nicht im Detail gelesen.
|
||||
- **Fehlende Information:** Implementierungsdetails/Konfiguration des Dienstes (Frequenz, Regelkatalog).
|
||||
|
||||
## SwRS-53 – CPra-Konnektor (Audit-/Exportanbindung)
|
||||
- **Status:** HYPOTHESE
|
||||
- **Bislang belegt:** `CPraConnectorBL.ConnectToCPra(username, password)` und `CPraConfigurationSettingsBL` existieren; eine eigene Anwendungslizenz `ExternalAppCPra("c-pra")` ist im Login-System registriert.
|
||||
- **Offene Frage:** Welchen fachlichen Zweck erfüllt „c-pra“ konkret (GoBD-/Betriebsprüfungsexport nach AO-Dataportformat, Kassen-TSE-Anbindung oder Buchhaltungs-Frontend)? Der Code belegt nur den Authentifizierungsvorgang, nicht den Datenumfang.
|
||||
- **Fehlende Information:** Dokumentation oder Schnittstellenvertrag des Externprodukts c-pra; die Aufrufliste der Connector-Methoden wurde nur teilweise gelesen.
|
||||
+278
@@ -0,0 +1,278 @@
|
||||
# StRS – Stakeholder Requirements Specification
|
||||
|
||||
Quelle: Reverse Requirements Engineering der c-entron ERP-Suite (c-entron.NET).
|
||||
Kontext: Das Produkt ist ein lizenziertes, mandantenfähig eingesetztes ERP-/Warenwirtschaftssystem für IT-Systemhäuser und Handels-/Servicebetriebe (Handel mit Artikeln und Dienstleistungen, Helpdesk/C-FLOW, Abrechnung, Lager, EDI-Anbindung an Distributoren). Akteure wurden aus Berechtigungskonstanten (`UserRightsConst`), Anwendungslizenzen (`ApplicationKind`) und Rollenbezeichnungen der Codebasis abgeleitet.
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-01
|
||||
Titel: Durchgängiger Vertriebsprozess vom Angebot bis zur Rechnung
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebssachbearbeiter, Kunde
|
||||
Vorbedingung: Kunde und Artikelstamm vorhanden.
|
||||
Fakt: Das System führt sieben Belegarten mit Kopftabellen `AngKopf/AufKopf/LiefKopf/RechKopf/VertragKopf/GutKopf/AbholKopf` und Positionstabellen (`*Pos`) samt Versions- und Progressionstabellen (`ReceiptProgressionBL`, `ForwardReceipt`, `CopyReceipt`).
|
||||
Aussage: Das soll den kompletten Vertriebsprozess (Angebot → Auftrag → Lieferschein → Rechnung; zusätzlich Vertrag, Gutschrift, Abholeliste) mit Umwandlung, Kopie und Nachverfolgung der Belegkette abbilden.
|
||||
Ergebnis: Aus jedem Beleg kann der Folgeberleg erzeugt werden; die Belegkette ist lückenlos rückverfolgbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:1377,1548` (CopyReceipt, ForwardReceipt) - die Umwandlungs-/Kopiervorgänge sind hier implementiert.
|
||||
- [SEKUNDÄR] `docs/reference/receipts/receipts-backend-architecture.md` (Tabelle der Belegarten und Tabellenzuordnung) - beschreibt die sieben Belegarten.
|
||||
Prüfidee: Aus einem Angebot einen Auftrag erzeugen; Auftragskopf verweist per Progression auf das Angebot.
|
||||
Tracelinks: SyRS-01, SwRS-03, SwRS-05, SwRS-06
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kernfunktion eines ERP, fachlich unverändert benötigt.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-02
|
||||
Titel: Helpdesk-/Ticketverwaltung (C-FLOW) für Service und Support
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicemitarbeiter, Kundenbetreuer, Endkunde (via ServiceBoard/SelfCare)
|
||||
Vorbedingung: Kunde mit Supportbeziehung ist angelegt.
|
||||
Fakt: Modul `Sales/Support` mit `HelpdeskBL`, `HelpdeskCloseBL`, `HelpdeskState` (Statuszustände als Datenobjekt mit Icon, Deaktivierung, ServiceBoard-Farbe), Ticketzeiten (`HelpdeskTimer*`), Vorlagen und Checklisten.
|
||||
Aussage: Das System soll Kunden-Tickets mit konfigurierbaren Statuszuständen, Bearbeiterzuweisung, Prioritäten, Kategorien, Laufzeit-Erfassung und Kundenkommunikation verwalten.
|
||||
Ergebnis: Tickets von der Anlage bis zum Abschluss inkl. Zeiterfassung und Kunde-Sicht durchlaufbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Entities/Entities/CustomerArea/Support/HelpdeskState.cs:7-14` (Status als konfigurierbare Entität inkl. ServiceBoardWebColor) - Statusverwaltung ist datengetrieben implementiert, nicht hartcodiert.
|
||||
- [SEKUNDÄR] `CentronRights.md` Abschnitt Helpdesk (Rechte für Anlegen/Bearbeiten/Abschließen/Zeiten) - beschreibt die fachlichen Bedienmöglichkeiten.
|
||||
Prüfidee: Ticket anlegen → Statuswechsel → Abschluss mit Benachrichtigung; Statusliste ohne DB-Änderung per Konfiguration erweiterbar.
|
||||
Tracelinks: SyRS-13, SwRS-18, SwRS-19, SwRS-20
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - zentrales Service-Modul des Produkts.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-03
|
||||
Titel: Zeiterfassung mit direkter Weiterberechnung an den Kunden
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Servicetechniker, Disponent
|
||||
Vorbedingung: Ticket mit Zeiteintrag vorhanden.
|
||||
Fakt: `HelpdeskTimerBillingState`, `CreateNewReceiptForHelpdekTimers(...)` erzeugt aus Ticketzeiten einen Beleg; Rechte `MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` gelten nur, „if the ticket is not part of a receipt“ (CentronRights.md).
|
||||
Aussage: Das System soll erfasste Serviczeiten und Serviceartikel abrechnungsreif in Verkaufsbelege überführen und einmal abgerechnete Zeiten vor Verschieben/Löschen schützen.
|
||||
Ergebnis: Abgerechnete Zeiten sind unveränderlich; nicht abgerechnete Zeiten sind abrechnungsreif.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:5295` (`CreateNewReceiptForHelpdekTimers(IList<int> timerI3Ds, TimerBillingSetti…`) - die Überführungsregel ist dort implementiert.
|
||||
- [SEKUNDÄR] `CentronRights.md` Punkte 8/9 (Zeiten verschieben/löschen „only if the ticket is not part of a receipt“) - Formulierungen der Schutzregel.
|
||||
Prüfidee: Der Versuch, eine Zeit mit verknüpfter Rechnung zu verschieben, schlägt fehl.
|
||||
Tracelinks: SyRS-01, SwRS-12, SwRS-13, SwRS-14
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Kern der Dienstleistungsabrechnung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-04
|
||||
Titel: Artikel- und Preiswirtschaft für Handel mit Fremdware
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf, Vertrieb
|
||||
Vorbedingung: Distributoren-/Herstellerstämme gepflegt.
|
||||
Fakt: `ActionPriceBL.GetActionPricesByArticleI3D`, Tabelle `HerstellerArtikAktionspreis` mit GueltigAb/GueltigBis/Distributor, `ArticleVolumePricesBL`, `AccountSpecialPriceBL`; Fremdartikelsucher für Egis/ITscope/ICECAT (`src/apis`).
|
||||
Aussage: Das System soll Einkaufs-, Aktions-, Volumen- und Kunden Sonderpreise verwalten und Fremdartikel über Distributor-Schnittstellen suchen und übernehmen können.
|
||||
Ergebnis: Bei Belegerfassung wird der fachlich passende Preis (Aktionspreis im Gültigkeitszeitraum, Kunden-Sonderpreis, Volumenpreis) verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Warehousing/ActionPriceBL.cs:26` (GetActionPricesByArticleI3D) - Aktionspreis lookup implementiert.
|
||||
- [SEKUNDÄR] `docs/reference/receipts/actionprice-system.md` (Tabellenstruktur `HerstellerArtikAktionspreis`, Integration in Preismatrix) - kontextliche Beschreibung.
|
||||
Prüfidee: Artikel mit Aktionspreis (heute gültig) im Auftrag: Aktionspreis wird in der Preismatrix angezeigt.
|
||||
Tracelinks: SyRS-07, SwRS-25, SwRS-26
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - wettbewerbsentscheidende Kernfunktion.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-05
|
||||
Titel: EDI-Anbindung an Distributoren für Bestellabwicklung
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Einkauf (im Backend), Distributoren (Alltron, Also, Herweck, Komsa, Egis, Concerto, OpenTrans)
|
||||
Vorbedingung: Lieferant mit EDI-Konfiguration angelegt.
|
||||
Fakt: `SupplierEdiBL.Alltron/Also/Herweck/Komsa/Opentrans.cs`, `EDIDispatcherBL`, `EDILogBL`, `EgisWarenkorbBL` (Modul `Centron.BL/EDI`); `docs/reference/edi/edi-architecture.md`.
|
||||
Aussage: Das System soll Bestellungen aus Aufträgen automatisch im je Lieferant korrekten EDI-Format übermitteln und die Übermittlung protokollieren.
|
||||
Ergebnis: Bestellung geht ohne medienbruch an den Distributor; jeder Vorgang ist im EDI-Log nachvollziehbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/Dispatch/SupplierEdiBL.cs` und Partials für Alltron/Also/Herweck/Komsa/Opentrans - Implementierung der formatspezifischen Versandlogik.
|
||||
- [SEKUNDÄR] `docs/reference/edi/edi-architecture.md` - Architekturbeschreibung des EDI-Systems.
|
||||
Prüfidee: Testbestellung an Sandbox-Lieferant; Eintrag in `EDILog` mit State.
|
||||
Tracelinks: SyRS-08, SwRS-30
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - ohne EDI wäre der Einkaufsprozess nicht automatisierbar.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-06
|
||||
Titel: Mandanten-/Kundenlizenzmodell für Funktionen und Zusatzprodukte
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: Hersteller (NEXOWARE), Kunde
|
||||
Vorbedingung: Lizenzdaten liegen vor.
|
||||
Fakt: Lizenzprüfung über `LicenseManager.Instance.HasLicense(LicenseGuids.*)`; `LicenseGuids.cs` zählt Dutzende Produkt-/Feature-GUIDs; `ApplicationKind.cs` listet Anwendungen mit `count`, `ExpirationKind` und optionalen Rechten (`requiredRight`, `disallowingRight`).
|
||||
Aussage: Das System soll Funktionsumfang und Login-Zulassung steuerbar über ein GUID-basiertes Lizenzmodell (Anzahl, Gültigkeitsdatum, gültige Version) pro Kunde abbilden.
|
||||
Ergebnis: Ohne Lizenz sind Modul/Login gesperrt; Lizenzgrenzen werden beim Login erzwungen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:132` (`LicenseManager.CheckLicense(applicationKind, appVersion, userResult)`) - durchgesetzte Login-Lizenzprüfung.
|
||||
- [SEKUNDÄR] `docs/reference/security/licensing-system.md` - Beschreibung des Lizenzmodells.
|
||||
Prüfidee: Login mit Application-Key ohne Lizenz → Fehler „No license …“.
|
||||
Tracelinks: SyRS-04, SwRS-39
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Geschäftsmodell des Herstellers.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-07
|
||||
Titel: Rollen- und berechtungsgetragene Datensicht
|
||||
Ebene: StRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Administrator, Fachanwender
|
||||
Vorbedingung: Benutzer und Berechtigungsgruppen gepflegt.
|
||||
Fakt: `UserRightsExt.HasUserRight(AppUser,int)` (UserRightsExt.cs:18) delegiert an `AppRightsBL.HasUserRight`; `CentronRights.md` beschreibt einschränkende Rechte („only own tickets“, „only own branch“); `UserRightsConst.cs` mit tausenden Rechte-IDs.
|
||||
Aussage: Das System soll jede Funktion und gefilterte Datensichten über ein zentrales, gruppenbasiertes Rechtesystem steuerbar machen.
|
||||
Ergebnis: Ohne Recht ist Funktion gesperrt; einschränkende Rechte begrenzen Daten auf eigene Objekte/Filialen.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs:18-30` (HasUserRight → AppRightsBL) - zentrale Durchsetzung.
|
||||
- [SEKUNDÄR] `CentronRights.md` (Semantik der Helpdesk-Rechte) - fachliche Bedeutung.
|
||||
Prüfidee: Benutzer ohne `ADD_NEW_HELPDESK` kann kein Ticket anlegen.
|
||||
Tracelinks: SyRS-02, SyRS-03, SwRS-24
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Grundvoraussetzung für Mehrbenutzung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-08
|
||||
Titel: Zahlungseingang, Mahnwesen und Forderungsmanagement
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Kreditorenbuchhaltung
|
||||
Vorbedingung: Offene Rechnungen vorhanden.
|
||||
Fakt: `DunningRunBL.GetDunningRuns/ResetDunningRun`, Kundenfelder `MahnungNachTagen(1..3)`, `AuftragsperreNachMahnung`, `MahnStop`; Rechnungsfelder `Mahnung1Datum…Mahnung3Datum`, `MahnStop` (SSMS_DB_SCHEMA.sql:2904,2947,3268); `IncomingPaymentBL` (Finances/IncomingPayments).
|
||||
Aussage: Das System soll Zahlungseingänge erfassen, offene Rechnungen in konfigurierbaren Mahnstufen mahnen und optional Auftragsperren je Kunde ableiten.
|
||||
Ergebnis: Mahnläufe sind reproduzierbar/stornierbar; Mahnstand je Kunde und Rechnung sichtbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs:49,495` - Mahnlauf-Erzeugung und Reset implementiert.
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql:2904-2906,2947,3268-3274` (MahnungNachTagen, AuftragsperreNachMahnung, Mahnung1..3Datum) - persistierte Mahnstruktur.
|
||||
- [KONTEXT] `SSMS_DB_SCHEMA.sql` Tabelle `Mahnlauf` - Name belegt das Konzept.
|
||||
Prüfidee: Mahnlauf über fällige Rechnung erzeugt Mahnstufe 1 mit Datum auf dem Beleg.
|
||||
Tracelinks: SwRS-08, SwRS-09, SwRS-11
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - betriebsnotwendig.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-09
|
||||
Titel: revisionssichere Ausgangsrechnungen (ZUGFeRD/XRechnung)
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Rechnungsempfänger (insb. öffentliche Auftraggeber)
|
||||
Vorbedingung: Rechnung existiert; ZUGFeRD-Lizenz/Setting aktiv.
|
||||
Fakt: `ReceiptBL.CreateFullReportForReceipt` verlangt bei ZUGFeRD-Aktivierung zwingend ein PDF („Für ZUGFeRD muss ein PDF Dokument über die Rechnung erzeugt werden“, ReceiptBL.cs:3279), erzeugt konformes PDF via `InvoiceZugferdBL.CreateZugferdConformPdfDocument` und ermittelt `LeitwegID` (ReceiptBL.cs:3296-3423); Spezifikations-PDFs XRechnung 2.2/2.3.1, ZUGFeRD 2.1.1 im Repo.
|
||||
Aussage: Das System soll Rechnungen und Gutschriften als hybrides PDF mit e-Rechnungsteil (ZUGFeRD/XRechnung) inkl. Leitweg-ID erzeugen und archivieren.
|
||||
Ergebnis: Empfänger-konforme E-Rechnungen; Archivierung der PDFs.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3273-3299` (Erzwingung PDF + ZUGFeRD-Erzeugung) - durchgesetzte Regelkette.
|
||||
- [SEKUNDÄR] `docs/guides/development/xrechnung.md`, `docs/reference/zugferd-field-mapping.md` - Feldzuordnung dokumentiert.
|
||||
Prüfidee: Rechnung mit aktivem ZUGFeRD-Setting exportieren → PDF/A-3 mit XML-Teil, Leitweg-ID aus Kundendaten/Konzern.
|
||||
Tracelinks: SyRS-09, SwRS-10
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - gesetzliche Anforderung (E-Rechnungspflicht).
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-10
|
||||
Titel: Kunden-/Partnerportale (Web-Cart, ServiceBoard, SelfCare)
|
||||
Ebene: StRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Endkunde des Kunden (B2B2C), Servicetechniker extern
|
||||
Vorbedingung: Web-Account mit Sonderpreisen angelegt.
|
||||
Fakt: README.md: WebCart „available if you login as a web-account … articles come from the customers 'Sonderpreise'“; Nexus-Module `WebCart`, `ServiceBoard`, `CustomerPortal`; WebAccount-Rechte 62001/62002 „Warenkorb prüfen/einkaufen“ (`WebRightsVisibility.cs`); SelfCare-Formulare (`SelfCareBL`).
|
||||
Aussage: Das System soll Externen (Kunden der Kunden, Technikern) webbasierte Portale für Bestellungen, Tickets, Dokumente und Selbstbedienung mit eigenem, eingeschränktem Rechtekreis bieten.
|
||||
Ergebnis: Externe Nutzer sehen nur ihre freigegebenen Artikel/Tickets/Dokumente.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10-33` (Allowlist der WebAccount-Rechte) - zentrale Einschränkung der Portalrechte.
|
||||
- [SEKUNDÄR] `README.md` Rules/Contributing Abschnitt WebCart - Funktionsbeschreibung.
|
||||
Prüfidee: Web-Account ohne Recht 62002 kann nicht bestellen.
|
||||
Tracelinks: SyRS-06, SyRS-10, SwRS-37, SwRS-64
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Wachstumsfeld des Produkts (Nexus).
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-11
|
||||
Titel: Anbindung externer Fachsysteme (Buchhaltung, DMS, Personaleinsatz, Banking)
|
||||
Ebene: StRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Buchhaltung, Backoffice
|
||||
Vorbedingung: Konfiguration der Zielsysteme vorhanden.
|
||||
Fakt: Buchhaltungs Export/Import-Implementierungen für Abacus/Addison (`Centron.Gateway/BookKeeping*`), DocBee-DMS Connector (`DataExchange/DocBee*`), TANSS (`DataExchange/TanssBL`), RMM, CTime (`Services/CTimeConnectorBL`), FinAPI-Onlinebanking (`src/apis/Centron.APIs.FinAPI/FinApiClient.cs`).
|
||||
Aussage: Das System soll Belegdaten, Tickets und Personenzeiten mit gängigen Fachsystemen austauschen (Export, Import, Status-Sync).
|
||||
Ergebnis: kein Medienbruch zwischen ERP und Fremdsystemen; Austausch protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/BookKeepingExportAbacus.cs`/`BookKeepingImportAbacus.cs` (+Addison) - konkrete Format-Implementierungen.
|
||||
- [SEKUNDÄR] `docs/reference/architecture/stanislaus-secret-api-documentation.md` - interne Schnittstellendoku.
|
||||
Prüfidee: Rechnungs Export erzeugt Abacus-Datei mit korrekten Kontenfeldern.
|
||||
Tracelinks: SyRS-11, SwRS-31, SwRS-34, SwRS-35, SwRS-74
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Integrationsfähigkeit ist Verkaufsargument.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-12
|
||||
Titel: Rechtliche Compliance: Datenschutz, Audit-Export, manipulationssichere Signaturen
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Datenschutzbeauftragter, Auditor, Kassenbetriebe
|
||||
Vorbedingung: personenbezogene Daten vorhanden.
|
||||
Fakt: `DataSecurityBL.DsgvoDeleteRightGetContacts` + `DataSecurityExecuteCleanUp` (Löschkonzept); CPra-Konnektor (`CPra/CPraConnectorBL.ConnectToCPra`, Application `ExternalAppCPra`); PDF-Signing (`Security/PdfSigningBL.cs`); Timesheet-Signaturen (`HelpdeskTimerSignatureCompact`, Recht `DELETE_HELPDESK_SIGNATURE`).
|
||||
Aussage: Das System soll DSGVO-Löschung/Löschstatistiken, Export für Betriebsprüfung (GoBD) und Nachweis-Signaturen (PDF, Timesheets) unterstützen.
|
||||
Ergebnis: Löschersuchen durchführbar und protokolliert; Audit-Export erzeugbar; Signaturen löschbar nur mit Sonderrecht.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs:64,377` (ExecuteCleanUp, DsgvoDeleteRightGetContacts) - implementierte Löschfunktion.
|
||||
- [SEKUNDÄR] `CentronRights.md` Punkt 7.2 (Signatur aus Zeit löschen = eigenes Recht) - Schutz der Signatur.
|
||||
Prüfidee: DSGVO-Löschlauf entfernt Kontakte eines Löschbegehrens und protokolliert dies.
|
||||
Tracelinks: SyRS-15, SwRS-53
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - rechtlich erforderlich.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: StRS-13
|
||||
Titel: Wartbare, testbare und internationalisierbare technische Plattform
|
||||
Ebene: StRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Wartbarkeit, Übertragbarkeit
|
||||
Akteur: Entwicklung, Betrieb, QA
|
||||
Vorbedingung: Produktentwicklung und Kundenbetrieb laufen.
|
||||
Fakt: Durchgängige Testprojekte (EndToEnd/Integration/Playwright), CI-Schienen in `.github/workflows` und `azure/`, DB-Konventionenwerk (`docs/guides/database`), mehrsprachige Ressourcen inkl. CH-Prozessvariante (`AlsoOrderCH_BL.cs`, `CultureController`).
|
||||
Aussage: Das System soll auf einer wartbaren, automatisiert testbaren und internationalisierbaren Plattform betrieben werden, damit Funktionserhaltung bei Refactoring und Neuimplementierung nachweisbar bleibt.
|
||||
Ergebnis: Änderungen sind durch CI-Tests abgesichert; Sprach-/Landesvarianten konfigurierbar.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `docs/guides/development/end-to-end-testing.md` - Teststrategie dokumentiert.
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/Controllers/CultureController.cs` - Kulturumschaltung durchgesetzt.
|
||||
Prüfidee: Regressionssuite läuft in CI vor jedem Release.
|
||||
Tracelinks: SyRS-12, SyRS-16, SyRS-18, SyRS-19, SyRS-20
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
+1720
File diff suppressed because it is too large
Load Diff
+424
@@ -0,0 +1,424 @@
|
||||
# SyRS – System Requirements Specification
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-01
|
||||
Titel: Belegwesen als einheitliches System (Header/Position/Version/Progression)
|
||||
Ebene: SyRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Alle Vertriebs-/Abrechnungsclients, Webservice
|
||||
Vorbedingung: Beleg einer der sieben Belegarten wird angelegt/geändert.
|
||||
Fakt: `ReceiptBase` (abstract) definiert Nummer, Datum, Version, State, Filiale, Währung, Auditfelder, `ConcurrencyControlGuid`; jede Belegart hat Kopf/Position/Versions-Tabellen und englische Views (`Offers`→`AngKopf` usw.).
|
||||
Aussage: Das System soll alle Belegarten auf einer gemeinsamen Datenstruktur mit Versionierung, Mandanten-/Filialbezug, Währungsfaktor und Optimistic Concurrency (`ConcurrencyControlGuid`) betreiben.
|
||||
Ergebnis: Parallele Änderungen werden über die Concurrency-GUID erkannt; jede Änderungsversion ist historisiert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Entities/Entities/Sales/Receipts/ReceiptBase.cs` (via docs/reference/receipts/receipts-backend-architecture.md zitierte Properties inkl. ConcurrencyControlGuid) - gemeinsame Basisklasse aller Belege.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:3063,3068` (`CreateNewVersion`) - Versionsbildung implementiert.
|
||||
Prüfidee: Zwei Clients speichern denselben Beleg → zweiter Speichervorgang schlägt wegen Concurrency-Guid fehl.
|
||||
Tracelinks: StRS-01, SwRS-03, SwRS-05
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - tragendes Datenkonzept.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-02
|
||||
Titel: Authentifizierung mit austauschbaren Verfahren und Fallback
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: AppUser, WebAccount, OpenID-Connect-Identität
|
||||
Vorbedingung: System-Authentifizierungsmethode konfiguriert.
|
||||
Fakt: `AuthenticatorFactory` wählt je `SystemAuthenticationMethod` (None/Basic/ActiveDirectory/OpenIdConnect) und hängt für Basic-Logins einen `FallbackAuthenticator` (CentronLogin → BasicAuthenticator; AD/OIDC → `FailingAuthenticator` mit Konfigurationsfehler-Meldung); OIDC nur mit Lizenz `OpenIDConnectAuthentication` (AuthenticatorFactory.cs:133).
|
||||
Aussage: Das System soll Login wahlweise lokal, gegen Active Directory oder OpenID-Connect (Entra ID) durchführen; bei Fehlkonfiguration des primären Verfahrens darf der Login kontrolliert fehlschlagen bzw. auf lokales Passwort zurückfallen.
|
||||
Ergebnis: Login erfolgreich bzw. definierte Fehlermeldung; nie stille Umgehung.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/AuthenticatorFactory.cs:54-135` -Fabrik und Fallback-Verzweigungen.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs:151-156` (optionaler Server-Zertifikats-Hash-Abgleich) - durchgesetzte Verbindungssicherung.
|
||||
Prüfidee: AD deaktiviert + Nutzer mit AD-Marker → Fallback-Meldung statt Login.
|
||||
Tracelinks: StRS-06, SwRS-36, SwRS-38, SwRS-42
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - modernes IdP-Setup (Entra ID) vorhanden.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-03
|
||||
Titel: Zentrale Rechteprüfung für Clients und Web Accounts
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: AppUser, WebAccount
|
||||
Vorbedingung: Benutzer ist authentifiziert.
|
||||
Fakt: `AppRightsBL.HasUserRight(userI3D, rightId)` prüft Gruppenzuordnung (`AppGroupRightAssignment`); `UserRightsExt.IsAdmin` prüft Gruppenname „Administratoren“ (UserRightsConst.ADMIN_ACCOUNT); WebAccount-Rechte über `HasWebAccountRight`; WebUI-Rechte auf Allowlist `WebRightsVisibility.AllowedRightIds` beschränkt.
|
||||
Aussage: Das System soll Funktionszugriffe ausschließlich über die zentrale, gruppenbasierte Rechteprüfung (inkl. Admin-Ausnahme und Web-Rechte-Allowlist) freigeben.
|
||||
Ergebnis: Fehlendes Recht ⇒ verweigerter Zugriff inkl. Fehlermeldung; Admin-Gruppe hebt Prüfungen auf.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Rights/UserRightsExt.cs:18-30,56-65` und `AppRightsBL.cs` (HasUserRight/HasWebAccountRight/IsAdmin, Zeilen 264-297 Prüfrückgaben) - Durchsetzungspunkte.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10` (AllowedRightIds) - Web-Begrenzung.
|
||||
- [KONTEXT] `docs/guides/development/check-userrights.md`, `add-a-new-right.md` - Entwicklerleitfaden zur Rechteprüfung.
|
||||
Prüfidee: Integrationstest: Recht entziehen → Aufruf scheitert; Admin-Gruppe → Erfolg.
|
||||
Tracelinks: StRS-07, SwRS-24
|
||||
Konsolidierung: Kandidat: `UserRightsExt` (Extensions) und `AppRightsBL` (BL) bilden dieselbe Prüfung doppelt ab – im Zielsystem eine Autorisierungsschicht.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-04
|
||||
Titel: Lizenz- und Kontingentprüfung beim Webservice-Login
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Zentrales Lizenzsystem, Webservice
|
||||
Vorbedingung: Client meldet sich mit Application-GUID, MachineName, AppVersion.
|
||||
Fakt: `Authenticator.AuthenticateUser` → `LicenseManager.CheckLicense(applicationKind, appVersion, userResult)`; bei „license max reached“ ohne bestehendes Ticket wird abgelehnt; `TicketBL.CreateNewTicket(...)` zählt aktive Sitzungen; `ApplicationKind` trägt `ExpirationKind` (OneDay/MonitoringConnector/FromSettings), `requiredRight`, `disallowingRight`; `ValidateRights` (Authenticator.cs:68-82) prüft Zu-/Ausschlussrechte vor Lizenzprüfung.
|
||||
Aussage: Das System soll jeden Webservice-Login gegen Lizenzexistenz, Versionsgrenze, Gültigkeit, Benutzerzahl und optionale Zulassungs-/Ausschlussrechte prüfen und Sitzungen als Tickets mit Gültigkeitsdauer verwalten.
|
||||
Ergebnis: Überzählter/aparter Login wird abgewiesen; erlaubter Login erzeugt Ticket mit Ablauf.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:68-150` - die Prüf- und Ticketkette.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces/Administration/Logins/ApplicationKind.cs:11-58` - Deklaration der erlaubten Anwendungen inkl. Rechte- und Ablaufvarianten.
|
||||
Prüfidee: N+1. Login bei Lizenz-Count N ohne freies Ticket → Fehler.
|
||||
Tracelinks: StRS-06, SwRS-39, SwRS-71, SwRS-83
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-05
|
||||
Titel: Zweifaktor-Authentifizierung (E-Mail/Radius) nach Passwortlogin
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: AppUser, 2FA-Provider
|
||||
Vorbedingung: Benutzer mit 2FA-Konfiguration meldet sich an.
|
||||
Fakt: `BasicAuthenticator` ruft nach Validierung `TwoFactorAuthBL.ValidateTwoFactor(username, password, loggedInUser, …)` (BasicAuthenticator.cs:62); Validatoren austauschbar via `GetTwoFactorValidator()` (EmailTwoFactorValidator, RadiusTwoFactorValidator inkl. RADIUS-Client).
|
||||
Aussage: Das System soll die Zwei-Faktor-Prüfung als verpflichtenden Schritt nach der Passwortvalidierung einbauen und den Faktor austauschbar (E-Mail-Code, RADIUS) konfigurieren.
|
||||
Ergebnis: Ohne gültigen zweiten Faktor kein Login; 2FA-Abbruch bricht Login ab.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:52-65` + `TwoFactor/TwoFactorAuthBL.cs:33` - erzwungener Aufruf im Loginpfad.
|
||||
- [SEKUNDÄR] `docs/reference/security/anmelden-mit-microsoft-technische-anleitung.md` - Dokumentationskontext.
|
||||
Prüfidee: Richtiges Passwort ohne 2FA-Code → kein Ticket.
|
||||
Tracelinks: StRS-06, SwRS-36, SwRS-38
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-06
|
||||
Titel: Webservice als zentraler Zugriffspunkt (WCF/REST, Session-Tickets)
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: WPF-Client, Nexus, Add-Ins, externe Apps
|
||||
Vorbedingung: Login erfolgreich.
|
||||
Fakt: `Centron.Host`/`Centron.Host.WindowsService` hosten `Centron.WebServices.Core` (`ICentronRestService`-Muster, `LoginRequest`, `JwtLoginRequest`, `WebAccountLoginRequest`, `ChangeWebReceiptStateRequest`); Tickets als Sitzungsbeleg (`TicketBL.GetExistingTicket/CreateNewTicket`); Clients wechseln je Modul zwischen BLLogic (Direkt-DB) und WSLogic (Fernzugriff) (docs/general-structure.md).
|
||||
Aussage: Das System soll allen FRONTENDS einen versionierten Webservice mit Ticket-/JWT-basierten Sitzungen bereitstellen, sodass Clients ohne direkten Datenbankzugriff arbeiten können.
|
||||
Ergebnis: identische Geschäftslogik über Direkt- und Remote-Zugriff; Sitzungen invalidierbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/webservice/Centron.Host/CentronHost.cs` + `src/webservice/Centron.WebServices.Core/Messages` (LoginRequest/JwtLoginRequest/WebAccountLoginRequest) - gehosteter Dienst und Login-Verträge.
|
||||
- [SEKUNDÄR] `docs/getting-started/general-structure.md` (Duale BLLogic/WSLogic-Architektur) - Architekturregel.
|
||||
- [KONTEXT] `docs/guides/services/add-webservice-methods.md`, `web-service-on-linux.md` - Betrieb/Erweiterung.
|
||||
Prüfidee: Nexus ohne Ticket-Token erhält 401; mit Ticket Erfolg.
|
||||
Tracelinks: StRS-10, SwRS-38, SwRS-42
|
||||
Konsolidierung: Kandidat: Direkt-DB-Zugriff (BLLogic) und Webservice-Pfad (WSLogic) implementieren dieselben Funktionen doppelt – SaaS-Zielbetrieb nur über API.
|
||||
Übernahmewürdigkeit: übernehmen (Architektur), Direkt-DB-Pfad → Workaround für On-Premise
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-07
|
||||
Titel: Preismatrix und mehrstufige Preisfindung im Beleg
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Vertriebsclient, Webservice
|
||||
Vorbedingung: Belegposition mit Artikel.
|
||||
Fakt: `ReceiptPriceHelperBL.CalculateReceiptVatPrices(...)` und `CalculateReceiptItemBasePrice(netPriceFC, …)` (ReceiptPriceHelperBL.cs:65-122); `RecalculateItemsFreightAndDistribution(receipt)` (ReceiptBL.cs:5125); Aktions-/Volumen-/Sonderpreis-Quellen (ActionPriceBL, ArticleVolumePricesBL, AccountSpecialPriceBL).
|
||||
Aussage: Das System soll den Positionspreis deterministisch aus Preisquellen (Kunden-Sonderpreis, Aktionspreis im Gültigkeitszeitraum, Volumenpreis, Standard) ableiten, MwSt.-Summen je Satz bilden und Fracht Verteilung neu berechnen.
|
||||
Ergebnis: Belegsummen stimmen mit Positionspreisen und MwSt.-Sätzen überein.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Sales/Receipts/ReceiptPriceHelperBL.cs:65,122` - die Kalkulationsmethoden.
|
||||
- [SEKUNDÄR] `docs/reference/receipts/actionprice-system.md` Abschnitt „Integration with Price Matrix“ - Regelbeschreibung.
|
||||
Prüfidee: Positionspreis-Änderung → MwSt.-Aufstellung und Frachtverteilung aktualisieren sich.
|
||||
Tracelinks: StRS-04, SwRS-25, SwRS-26
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-08
|
||||
Titel: EDI-Versandpipeline mit Log- und Zustandsverwaltung
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal: Zuverlässigkeit
|
||||
Akteur: EDI-Dispatcher, Distributoren
|
||||
Vorbedingung: Auftrag mit EDI-fähigem Lieferanten.
|
||||
Fakt: `EDIDispatcherBL` + `SupplierEdiBL.<Distributor>`-Partials; Zustandsenummern `EDIHeadState`, `EDILogState`; Protokollierung `EDILogBL`, `EDIGatewayLogBL`.
|
||||
Aussage: Das System soll EDI-Vorgänge zustandsbehaftet (angestoßen/übermittelt/fehlerhaft) mit Wiederholbarkeit und vollständigem Log-Betrieb.
|
||||
Ergebnis: Jeder Versand hat dauerhaften Log-Eintrag mit Status; Fehler sind wiederholbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/Dispatch/SupplierEdiBL.cs` (+ Distributor-Partials) und `EDICommon/EDIDispatcherBL.cs` - Versand- und Dispatch-Logik.
|
||||
- [SEKUNDÄR] `docs/reference/edi/edi-architecture.md`, `edi-import-rules.md` - Regelwerk.
|
||||
Prüfidee: Simulierter Timeout → Logeintrag mit Fehlerstatus, erneuter Versuch möglich.
|
||||
Tracelinks: StRS-05, SwRS-30
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-09
|
||||
Titel: E-Rechnungs-Ausgabe (ZUGFeRD 2.x / XRechnung) als Systemdienst
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Rechnungswesen, empfangende Systeme
|
||||
Vorbedingung: Rechnung/Gutschrift liegt vor.
|
||||
Fakt: `InvoiceZugferdBL` (+ Partial `Zugferd10`), `ZugferdFileKind`, `XInvoiceVersion3.cs`, Spezifikations-PDFs XRechnung 2.2.0/2.3.1 und ZUGFeRD 2.1.1 TA im Verzeichnis `src/backend/Centron.BL/DataExchange/`; Fehlerpfad bei fehlendem PDF (ReceiptBL.cs:3279); `ZUGFeRD_BL`, `ZugferdParseBL` im EDI-Modul (Importseite).
|
||||
Aussage: Das System soll ausgehende Rechnungen als ZUGFeRD/XRechnung erzeugen und eingehende E-Rechnungs-Dateien parsen können.
|
||||
Ergebnis: Validierbare XML/PDF-Hybrid-Ausgaben; Parse-Ergebnisse strukturiert verfügbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/DataExchange/InvoiceZugferdBL.cs` (+`.Zugferd10.cs`) und `Data/XInvoiceVersion3.cs` - Erzeugungs- und Versionierungscode.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/EDI/ZUGFeRD_BL.cs`, `ZugferdParseBL.cs` - Import-/ParseLogik.
|
||||
Prüfidee: Erzeugtes XML gegen Schematron der hinterlegten Spezifikation validieren.
|
||||
Tracelinks: StRS-09, SwRS-10
|
||||
Konsolidierung: Kandidat: ZUGFeRD-Code existiert parallel in DataExchange (Export) und EDI (Parse) - ein E-Invoicing-Dienst im Zielsystem.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-10
|
||||
Titel: Web-Accounts als eigener Authentifizierungstyp mit Rechtemenge
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: WebAccount (Portalkunde)
|
||||
Vorbedingung: Web-Account im Adressstamm mit Sonderpreisen angelegt.
|
||||
Fakt: `WebAccountAuthenticator` über Fabrik eingehängt; `WebAccountBL` prüft/setzt Passwörter als SHA1-Hash (`SHA1Decoder.GetDecodedSHA1String`, WebAccountBL.cs:56,192,253); `WebRightsExt`/`HasWebAccountRight` (UserRightsExt.cs:34-50); Rechte auf `WebRightsVisibility` beschränkt; Application `WebCart` mit `ExpirationKind.FromSettings`.
|
||||
Aussage: Das System soll Portalnutzer als eigenständigen Accounttyp mit eigenem Rechtekanon und ablaufender Lizenz führen; Passwörter sind zu hashen (aktueller SHA1-Algorithmus ist abzulösen, siehe SwRS-39).
|
||||
Ergebnis: Portallogin nur mit gültigem Account, Passworthash geprüft, Rechte gefiltert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/WebAccountAuthenticator.cs` + `Users/WebAccountBL.cs:56` - Authentifizierung und Passworthandhabung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/WebRightsVisibility.cs:10-52` - Rechtemenge.
|
||||
Prüfidee: WebAccount ohne Recht 26000 kann kein Ticket anlegen.
|
||||
Tracelinks: StRS-10, SwRS-36, SwRS-37
|
||||
Konsolidierung: Kandidat: AppUser- und WebAccount-Passwortbehandlung (UsersBL/WebAccountBL) sind Parallelimpelementationen - ein Accounts-/Credential-Dienst im Zielsystem.
|
||||
Übernahmewürdigkeit: übernehmen (Konzept), SHA1 → veraltet (siehe SwRS-38)
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-11
|
||||
Titel: Buchhaltungsanbindung über Export-/Import-Konnektoren (DATEV-artig)
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Externes Buchhaltungssystem (Abacus, Addison, DATEV-artige Formate)
|
||||
Vorbedingung: Buchhaltungssystem konfiguriert (BankAccountProperty, BookKeepingAccountSystems).
|
||||
Fakt: `Centron.Gateway` implementiert `IBookKeepingExport`/`IBookKeepingImportDataToCentron` mit Concrete ExportAbacus/ImportAbacus/ExportAddison/…; `DataExchange/BookKeepingExportBL.cs`, `BookKeepingImportBL.cs`; Kontenfeld-Service `ReceiptItemAccountBL`, `BankAccountBL` (BL/Accounting).
|
||||
Aussage: Das System soll Belegdaten exportier- und importierbar in Buchhaltungsformate machen, inklusive Kontenzuordnung je Belegposition.
|
||||
Ergebnis: Exportdatei enthält vollständige Kontierungsdaten; Import schreibt Buchungsdaten zurück.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.Gateway/BookKeepingExportAbacus.cs`, `BookKeepingImportAddison.cs` u.a. - Formatimplementierungen.
|
||||
- [SEKUNDÄR] `src/backend/Centron.BL/Administration/BookKeepingAccountSystems` (Modulordner) - Konfigurationsablage.
|
||||
Prüfidee: Export einer Rechnung enthält USt-Schlüssel und Konten je Position.
|
||||
Tracelinks: StRS-11, SwRS-35
|
||||
Konsolidierung: Kandidat: je Zielsystem eine Implementierungsklasse – Zielsystem: ein Export-Framework mit Format-Plugins.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-12
|
||||
Titel: Duale Client-Datenzugriffsschicht (BLLogic/WSLogic) mit DI-Container
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Wartbarkeit, Übertragbarkeit
|
||||
Akteur: WPF-Client (Centron.WPF.UI)
|
||||
Vorbedingung: Modul implementiert ILogic.
|
||||
Fakt: `ClassContainer.Instance.WithInstance((IAccountContractsLogic logic) => …)`; Konvention: je Modul `ILogic` + `BL*Logic` (Direkt-DB) + `WS*Logic` (REST); `Result<T>`-Fehlermuster durchgängig (docs/general-structure.md).
|
||||
Aussage: Das System soll jeden Modulzugriff hinter einem Interface kapseln, damit Deployment zwischen Direkt-Datenbank- und API-Betrieb umschaltbar ist.
|
||||
Ergebnis: Umschaltung ohne Änderung an ViewModel-Schicht.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `docs/getting-started/general-structure.md` - Architekturregel mit Codebeispielen.
|
||||
- [PRIMÄR] `src/backend/Centron.Interfaces` (ILogic-Schnittstellen, z. B. `Sales/Receipts/ReceiptState.cs` im selben Paketmuster) - Schnittstellenpaket als Infrastruktur.
|
||||
Prüfidee: WSModus: Trace zeigt HTTP-Aufruf statt DB-Query.
|
||||
Tracelinks: StRS-13, SyRS-06, SwRS-77
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: Workaround - Doppelpfad existiert wegen On-Premise-Historie; SaaS-Ziel kennt nur API.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-13
|
||||
Titel: Nexus-Webfrontend (Blazor) mit eigener Hostarchitektur
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: Browsernutzer (Mitarbeiter und Kunden)
|
||||
Vorbedingung: CentronNexus.Host läuft.
|
||||
Fakt: `src/nexus/CentronNexus` mit Bereichen ServiceBoard (Kanban, Scheduler, DocumentViewer, PasswordManager, MyDay), WebCart/CustomerPortal, WebOffer, DocumentSigning, ProductionOrderManagement, Office; `CentronNexus.Host`, `CentronNexus.OutlookAddIn`; README: DevExpress-Blazor-Komponenten, LibMan/CDN-Integrity-Regeln.
|
||||
Aussage: Das System soll Webanwendungsfunktionen (Service-Board, Web-Cart, Angebotsportal, Dokumentenzeichnung) als Blazor-Frontend gegen den zentralen Webservice bereitstellen.
|
||||
Ergebnis: Webnutzer erhalten äquivalente Funktionen des Desktop-Clients für die betroffenen Module.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/ServiceBoard/Kanban`, `WebCart/CustomerPortal`, `DocumentSigning` (Verzeichnis-/Komponentenstruktur) - existente Webmodule.
|
||||
- [SEKUNDÄR] `README.md` - Frontend-Regeln und WebCart-Hinweis.
|
||||
Prüfidee: ServiceBoard-Ticketliste filtert wie Client-Filter; Login nur über WebAccount/AppUser-Ticket.
|
||||
Tracelinks: StRS-10, SwRS-51, SwRS-78
|
||||
Konsolidierung: Kandidat: WPF-Client und Nexus-UI bilden Helpdesk/Belege doppelt ab - ein domänenseitiges Backend, zwei Presentation Layers.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-14
|
||||
Titel: Reporting-Engine mit Druckoptionen und Portal-Reports
|
||||
Ebene: SyRS
|
||||
Typ: funktional
|
||||
Qualitätsmerkmal:
|
||||
Akteur: Anwender, Reportserver
|
||||
Vorbedingung: Reportgruppe/Layout konfiguriert.
|
||||
Fakt: `ReportEngine`-Modul (26 Klassen, `ReportsSqlStatements.cs`), DB-Constraint `CK_ParentReference` auf `ReportPrintOptions` (ParentI3D und ParentObjectKind nur gemeinsam gesetzt, SSMS_DB_SCHEMA.sql); Sonderrecht `UPLOAD_PORTAL_REPORTS = 99999458` („only in c-entron databases where you are allowed to upload reports to the portal“, UserRightsConst.cs:22).
|
||||
Aussage: Das System soll Belegdruck/Reportausgabe über konfigurierbare Layouts und Hierarchie-Druckoptionen steuern und Portal-Report-Uploads kundenspezifisch sperren.
|
||||
Ergebnis: Reports gemäß Druckoptionen; Upload nur mit Sonderrecht.
|
||||
Belege:
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` `CONSTRAINT [CK_ParentReference] CHECK …ReportPrintOptions` - durchgesetztes Datenconstraint.
|
||||
- [SEKUNDÄR] `src/backend/Centron.WebServices.../UserRightsConst.cs:22` (UPLOAD_PORTAL_REPORTS) - Konfigurationsschalter.
|
||||
Prüfidee: Druckoption mit ParentI3D ohne ParentObjectKind wird von DB abgelehnt.
|
||||
Tracelinks: StRS-13, SwRS-56
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-15
|
||||
Titel: Löschkonzept und Soft-Delete-Muster
|
||||
Ebene: SyRS
|
||||
Typ: Sicherheit
|
||||
Qualitätsmerkmal: Sicherheit
|
||||
Akteur: Datenschutzbeauftragter, Fachanwender
|
||||
Vorbedingung: Daten mit Lösch-/Sperrflags vorhanden.
|
||||
Fakt: `DataSecurityBL.GetDataSecurityCleanUpStats` + `DataSecurityExecuteCleanUp` + `DsgvoDeleteRightGetContacts` (DataSecurityBL.cs:34,64,377); `EntityState`-Entität im Datenmodell; Deaktivierungsflags z. B. `AppUser.AccountDisabledFromDate/ToDate`, `IsAccountDisabled` (Authenticator.cs:169-172).
|
||||
Aussage: Das System soll Löschen primär als Sperrung/Deaktivierung mit Zeitfenstern abbilden und physische Bereinigung nur über den DSGVO-Cleanup-Dienst mit Statistik erlauben.
|
||||
Ergebnis: Deaktivierte Nutzer/Tickets sind funktional gelöscht; Cleanup protokolliert.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs:64,377` - Vollzug der Löschung.
|
||||
- [PRIMÄR] `src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:169-172` (AccountDisabledFrom/To-Prüfung beim Login) - Durchsetzung der Sperrung.
|
||||
Prüfidee: Deaktiviertes Zeitfenster heute → Login abgelehnt.
|
||||
Tracelinks: StRS-12, SwRS-36, SwRS-43
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-16
|
||||
Titel: Datenbank-Konventionen (I3D-Schlüssel, Audit-Spalten, dbo)
|
||||
Ebene: SyRS
|
||||
Typ: Daten
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: Entwickler, DBA
|
||||
Vorbedingung: Neues Tabellenobjekt wird angelegt.
|
||||
Fakt: Konvention: PK immer `I3D int IDENTITY(1,1)`, FK-Suffix `I3D`, Pflichtspalten `CreatedByI3D/CreatedDate` (+Änderungsspalten), Schema `dbo` (docs/guides/database/database-conventions.md); 1.535 CREATE-TABLE-Objekte und ~3.000 Constraints/Indexes im Gesamtschema.
|
||||
Aussage: Das System soll alle Datenobjekte nach einheitlichen Namens- und Auditkonventionen führen, damit Migration und Tooling (NHibernate-Mapping) funktionieren.
|
||||
Ergebnis: Jede Tabelle historisiert Anlage/Änderung; Fremdschlüssel maschinell erkennbar.
|
||||
Belege:
|
||||
- [PRIMÄR] `SSMS_DB_SCHEMA.sql` (PK-Cluster auf I3D in allen Tabellen, z. B. `PK_…`; CHECK-Constraints z. B. `CK_AccountActivities_Rating`, `Check_ReceiptProvisionItems_Receiver`) - gelebte Konvention im Schema.
|
||||
- [KONTEXT] `docs/guides/database/database-conventions.md`, `docs/reference/database/script-rules.md` - Regelwerk.
|
||||
Prüfidee: Schema-Analyse: 100 % Tabellen mit I3D-PK.
|
||||
Tracelinks: StRS-13, SwRS-01, SwRS-07
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen - Basis für Neuimplementierung.
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-17
|
||||
Titel: Externe Produkt-/Logistik-/Bank-APIs als Adapterdienste
|
||||
Ebene: SyRS
|
||||
Typ: Schnittstelle
|
||||
Qualitätsmerkmal:
|
||||
Akteur: GLS, Shipcloud, ICECAT, egis, ITscope, CopData, eBuddy(eBay-Schnittstelle), FinAPI
|
||||
Vorbedingung: Zugangsdaten hinterlegt.
|
||||
Fakt: Acht API-Projekte unter `src/apis` (Centron.Api.Gls, .Shipcloud, .EbInterface, APIs.CopDataAccess, .EgisDataAccess, .IcecatDataAccess, .ITscopeDataAccess, .FinAPI) mit Client-/Constants-Klassen und Unit-Tests unter `tests/apis`.
|
||||
Aussage: Das System soll Versandlabels, Produktdaten, Fremdartikelpreise und Banktransaktionen über gekapselte API-Adapter beziehen/übermitteln.
|
||||
Ergebnis: Adapter mit konfigurierbaren Credentials; Ausfall eines Adapters blockiert Kernsystem nicht.
|
||||
Belege:
|
||||
- [PRIMÄR] `src/apis/Centron.Api.Shipcloud` inkl. `ShipcloudPackageTemplateBL` (Sales/Receipts) - Label-/Paketintegration im Beleg.
|
||||
- [SEKUNDÄR] `docs/reference/architecture/dtos-and-entities.md` - Adapter-/DTO-Muster.
|
||||
Prüfidee: Versenderzeugung aus einem Auftrag erzeugt ein Shipcloud-Label im Testmodus.
|
||||
Tracelinks: StRS-04, StRS-11, SwRS-34, SwRS-84
|
||||
Konsolidierung: Kandidat: Fremdartikel-Provider (Egis/ITscope/ICECAT/Cop) sind vier Parallelimplementierungen derselben Suchfunktion - ein Provider-Plugin-Verzeichnis.
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-18
|
||||
Titel: Deployment: Windows-Installer für Client und Webservice, Docker für Nexus
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: Betrieb/IT-Partner
|
||||
Vorbedingung: Build-Artefakte vorhanden.
|
||||
Fakt: WiX-Installer `deployment/centron/CentronSetupProject`, `WebServiceSetupProject`, `WixSharpInstaller`; mehrere Dockerfiles (`docker/`) inkl. `install.sh/startup.sh` und `docker-pipeline.yml`, `build-nexus.yaml`, `build-web-service.yaml`; `docs/operations/build-server-and-automated-builds.md`.
|
||||
Aussage: Das System soll Client und Webservice als MSI für Windows ausliefern und die Webkomponente containerisierbar betreiben.
|
||||
Ergebnis: reproduzierbare Installation/Updates; Nexus-Image in Azure/Container-lauffähig.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `deployment/centron/CentronSetupProject/CentronSetupProject.wixproj` - Installerprojekt.
|
||||
- [SEKUNDÄR] `azure/build-pipeline.yml`, `docker-pipeline.yml`, `docker/*/Dockerfile` - Build-/Deploy-Pipelines.
|
||||
Prüfidee: Pipeline baut MSI und Nexus-Image aus demselben Commit.
|
||||
Tracelinks: StRS-13, SwRS-83
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen (Containerpfad) / Sonderfall (MSI nur für On-Premise-Kunden)
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-19
|
||||
Titel: Continuous Integration mit Build-, Test- und Regressionsschienen
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Wartbarkeit
|
||||
Akteur: Entwicklung, QA
|
||||
Vorbedingung: Push/PR im Repository.
|
||||
Fakt: `.github/workflows/build.yml`, `tests.yml`, `regression-tests.yml`; azure-pipelines `analyze-pipeline.yml`, `regression-tests-pipeline.yml`, `tests-pipeline.yml`; Testprojekte `Centron.Tests.EndToEnd`, `Centron.Tests.Integration`, `Centron.Tests.BL/DAO/Core/Controls`, `PlaywrightTests`, `CentronNexusTests`; `docs/guides/development/end-to-end-testing.md`.
|
||||
Aussage: Das System soll Build, Unit-/Integrations-/E2E- und Regressionstests automatisiert ausführen, um Refactoring-Migrationen abzusichern.
|
||||
Ergebnis: grüne Pipeline als Auslieferungsvoraussetzung.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `.github/workflows/tests.yml`, `regression-tests.yml` - existierende Schienen.
|
||||
- [PRIMÄR] `tests/Centron.Tests.Integration/*.csproj` - ausführbare Testinfrastruktur.
|
||||
Prüfidee: PR mit fehlschlagendem Integrationstest wird rot.
|
||||
Tracelinks: StRS-13, SwRS-68
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
|
||||
---
|
||||
|
||||
ID: SyRS-20
|
||||
Titel: Mehrsprachigkeit und Lokalisierung
|
||||
Ebene: SyRS
|
||||
Typ: nicht-funktional
|
||||
Qualitätsmerkmal: Übertragbarkeit
|
||||
Akteur: Anwender (DE/CH/weitere)
|
||||
Vorbedingung: Sprach-/Kulturkontext gesetzt.
|
||||
Fakt: `docs/guides/ui/localization.md`, `ResXManager.config.xml`, `CentronNexus/CultureController.cs`, lokalisierte Fehlermeldungen (`LocalizedStrings.AuthenticatorFactory_FallbackMisconfiguredErrorMessage`), CH-spezifische EDI-Variante `AlsoOrderCH_BL.cs`.
|
||||
Aussage: Das System soll Bedientexte und Validierungs-/Fehlermeldungen mehrsprachig verwalten und länderspezifische Prozessvarianten (CH-EDI) unterstützen.
|
||||
Ergebnis: UI und Meldungen folgen der Nutzersprache.
|
||||
Belege:
|
||||
- [SEKUNDÄR] `ResXManager.config.xml` + `src/centron/Centron.WPF.UI/Localization` - Ressourcenverwaltung.
|
||||
- [PRIMÄR] `src/nexus/CentronNexus/Controllers/CultureController.cs` - Kulturumschaltung im Web.
|
||||
- [KONTEXT] `docs/guides/ui/localization.md` - Leitfaden.
|
||||
Prüfidee: Sprachwechsel ändert Menü- und Meldungstexte vollständig.
|
||||
Tracelinks: StRS-13, SwRS-20
|
||||
Konsolidierung: nein
|
||||
Übernahmewürdigkeit: übernehmen
|
||||
Status: belegt
|
||||
+134
@@ -0,0 +1,134 @@
|
||||
# Traceability
|
||||
|
||||
Forward-/Backward-Verknüpfung StRS → SyRS → SwRS mit Haupt-Artefaktbeleg. (Vollständige Beleglisten je Anforderung stehen in den Ebenendateien.)
|
||||
|
||||
## StRS → SyRS
|
||||
|
||||
| StRS-ID | SyRS-IDs |
|
||||
|---|---|
|
||||
| StRS-01 | SyRS-01 |
|
||||
| StRS-02 | SyRS-13 |
|
||||
| StRS-03 | SyRS-01 (Zeiter→Beleg über SwRS-14) |
|
||||
| StRS-04 | SyRS-07, SyRS-17 |
|
||||
| StRS-05 | SyRS-08 |
|
||||
| StRS-06 | SyRS-02, SyRS-04, SyRS-05 |
|
||||
| StRS-07 | SyRS-03 |
|
||||
| StRS-08 | SyRS-11 |
|
||||
| StRS-09 | SyRS-09 |
|
||||
| StRS-10 | SyRS-06, SyRS-10, SyRS-13 |
|
||||
| StRS-11 | SyRS-11, SyRS-17 |
|
||||
| StRS-12 | SyRS-15 |
|
||||
| StRS-13 | SyRS-12, SyRS-16, SyRS-18, SyRS-19, SyRS-20 |
|
||||
|
||||
## Konsolidierte Traceability-Tabelle
|
||||
|
||||
| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (Kern) |
|
||||
|---|---|---|---|
|
||||
| StRS-01 | SyRS-01 | SwRS-03 | `Centron.Interfaces/Sales/Receipts/ReceiptState.cs:6-13` |
|
||||
| StRS-01 | SyRS-01 | SwRS-04 | `Sales/Receipts/ReceiptBL.cs:3160,3169` (Lock/Unlock) |
|
||||
| StRS-01 | SyRS-01 | SwRS-05 | `ReceiptBL.cs:3063` + `*KopfVersions`-Tabellen |
|
||||
| StRS-01 | SyRS-01 | SwRS-06 | `ReceiptBL.cs:1377,1548,4767` (Copy/Forward/Progression) |
|
||||
| StRS-01 | SyRS-07 | SwRS-07 | DB-CHECK `Check_ReceiptProvisionItems_*` |
|
||||
| StRS-01 | SyRS-07 | – (SyRS direkt) | `ReceiptPriceHelperBL.cs:65,122` (Preiskalkulation, in SyRS-07 belegt) |
|
||||
| StRS-01 | - | SwRS-01 | `IX_AccountCustomers_UniqueNumber` (Schema) |
|
||||
| StRS-01 | - | SwRS-02 | `AccountBL.cs:307-351`, `ReceiptBL.cs:3417` |
|
||||
| StRS-02 | SyRS-13 | SwRS-18 | `Entities/CustomerArea/Support/HelpdeskState.cs:7-14` |
|
||||
| StRS-02 | SyRS-13 | SwRS-19 | `HelpdeskCloseBL.cs:108,200` |
|
||||
| StRS-02 | - | SwRS-20 | `HelpdeskCreationTemplateBL.cs` + CentronRights.md 17 |
|
||||
| StRS-03 | SyRS-01 | SwRS-12 | `HelpdeskTimerHourlySurchargeRateOverlap.cs` |
|
||||
| StRS-03 | SyRS-01 | SwRS-13 | `HelpdeskTimerBillingState.cs` + CentronRights.md 7-9 |
|
||||
| StRS-03 | SyRS-01 | SwRS-14 | `ReceiptBL.cs:5295` (Zeiten→Beleg) |
|
||||
| StRS-04 | SyRS-07 | SwRS-25 | `ActionPriceBL.cs:26` + `HerstellerArtikAktionspreis` |
|
||||
| StRS-04 | SyRS-07 | SwRS-26 | `AccountSpecialPriceBL.cs` + README (WebCart/Sonderpreise) |
|
||||
| StRS-04 | SyRS-17 | SwRS-23 | `ArticleBL.cs:166-235` |
|
||||
| StRS-04 | - | SwRS-29 | `OrderSuggestionListBL.cs` |
|
||||
| StRS-05 | SyRS-08 | SwRS-30 | `EDI/Dispatch/SupplierEdiBL.cs` (+Partials) |
|
||||
| StRS-06 | SyRS-02 | SwRS-36 | `UsersBL.cs:65,107` (SHA1 – abzulösen) |
|
||||
| StRS-06 | SyRS-02 | SwRS-38 | `TicketBL.cs:169` (gerätegebundenes Ticket) |
|
||||
| StRS-06 | SyRS-02 | SwRS-42 | `MasterPasswordSecureFileStorage.cs` |
|
||||
| StRS-06 | SyRS-04 | SwRS-39 | `AccountLicenseBL.cs` + licensing-system.md |
|
||||
| StRS-06 | SyRS-04 | SwRS-71 | `Authenticator.cs:68-82` (requiredRight Riversuite) |
|
||||
| StRS-06 | SyRS-04 | SwRS-83 | `Authenticator.cs:132,150` (Versionsgrenze) |
|
||||
| StRS-07 | SyRS-03 | SwRS-24 | `ArticleBL.cs:129` (HasUserArticleRights) |
|
||||
| StRS-07 | SyRS-03 | SwRS-41 | `CustomerToBranchBL.cs` + CentronRights.md (Filialrechte) |
|
||||
| StRS-08 | SyRS-11 | SwRS-08 | `DunningRunBL.cs:49,495` + `Kunden.MahnungNachTagen` |
|
||||
| StRS-08 | - | SwRS-09 | `Kunden.AuftragsperreNachMahnung` [HYPOTHESE] |
|
||||
| StRS-08 | - | SwRS-11 | `CashBookBL.cs:15` |
|
||||
| StRS-08 | - | SwRS-33 | `IncomingPaymentBL.cs`, `ReceiptBL.cs:4902` |
|
||||
| StRS-09 | SyRS-09 | SwRS-10 | `ReceiptBL.cs:3273-3438` (ZUGFeRD/Leitweg) |
|
||||
| StRS-09 | - | SwRS-32 | `ReceiptBL.cs:5082,5095` (Duplikatprüfung) |
|
||||
| StRS-10 | SyRS-06 | SwRS-37 | `WebAccountBL.cs:56,415` + `WebRightsVisibility.cs` |
|
||||
| StRS-10 | SyRS-10 | SwRS-64 | `SelfCareBL.cs:47,55` |
|
||||
| StRS-10 | SyRS-13 | SwRS-51 | `NexusNotifications/NotificationsHubHelper.cs` |
|
||||
| StRS-10 | SyRS-13 | SwRS-78 | `Entities/Mobile/NewMobileHelpdeskTimer.cs` |
|
||||
| StRS-11 | SyRS-11 | SwRS-31 | `DocBeeTicketCreationBL.cs` |
|
||||
| StRS-11 | SyRS-11 | SwRS-34 | `FinApiClient.cs` + LicenseGuids (HBCI→FinAPI) |
|
||||
| StRS-11 | SyRS-11 | SwRS-35 | `Gateway/BookKeepingExportAbacus.cs` |
|
||||
| StRS-11 | SyRS-11 | SwRS-74 | `Services/CTimeConnectorBL.cs` |
|
||||
| StRS-11 | SyRS-17 | SwRS-84 | `Centron.Api.docuFORM/OAuthHelper.cs` |
|
||||
| StRS-12 | SyRS-15 | SwRS-43 | `docs/Background Service/DataQualityService.md` [HYPOTHESE] |
|
||||
| StRS-12 | - | SwRS-53 | `CPra/CPraConnectorBL.cs:31` [HYPOTHESE] |
|
||||
| StRS-13 | SyRS-12 | SwRS-77 | `GUI/UiProfileBL.cs` |
|
||||
| StRS-13 | SyRS-16 | SwRS-58 | `Customizations/CustomTables/CustomTableBL.cs:20,25` |
|
||||
| StRS-13 | SyRS-16 | SwRS-75 | `SystemArea/SystemTableI3DBL.cs` |
|
||||
| StRS-13 | SyRS-16 | SwRS-80 | `CountryArea/CountryBL.cs` |
|
||||
| StRS-13 | SyRS-18 | SwRS-76 | `ObjectExternalReferenceBL.cs` |
|
||||
| StRS-13 | SyRS-19 | SwRS-68 | `MassUpdateBL.cs:92,132` |
|
||||
| StRS-13 | SyRS-20 | SwRS-66 | `TradePoolBL.cs:28` |
|
||||
|
||||
## Restliche SwRS → SyRS (Zuordnung vollständig, Kernbeleg)
|
||||
|
||||
| SwRS-ID | SyRS-ID | Artefaktbeleg (Kern) |
|
||||
|---|---|---|
|
||||
| SwRS-07 | SyRS-07 | `ReceiptProvisionSchemaBL.cs` + DB-Constraints Provisionen |
|
||||
| SwRS-14 | SyRS-01 | `ReceiptBL.cs:5295` |
|
||||
| SwRS-15 | SyRS-16 | `CK_AccountActivities_Rating` (Schema) |
|
||||
| SwRS-16 | SyRS-16 | `CampaignPhaseActionBL.cs` |
|
||||
| SwRS-17 | SyRS-16 | `CI_RMA_HelpdeskI3D UNIQUE` (Schema) |
|
||||
| SwRS-21 | SyRS-16 | `Devices/AccountDeviceBL.cs:21-40` |
|
||||
| SwRS-22 | SyRS-16 | `DocuBoard/AssetManagementArticleAssignmentBL.cs` |
|
||||
| SwRS-27 | SyRS-16 | `InventoryManagement/InventoryBL.cs:75-196` |
|
||||
| SwRS-28 | SyRS-01 | `ReceiptBL.cs:5031` (QuantityPicked) |
|
||||
| SwRS-32 | SyRS-09 | `InvoiceUploadBL.cs`, `ReceiptBL.cs:5082` |
|
||||
| SwRS-36 | SyRS-02 | `UsersBL.cs:65,88,107` |
|
||||
| SwRS-37 | SyRS-10 | `WebAccountBL.cs:56,192,415,480` |
|
||||
| SwRS-38 | SyRS-04 | `TicketBL.cs:169`, `Authenticator.cs:127-142` |
|
||||
| SwRS-39 | SyRS-04 | `AccountLicenseBL.cs` |
|
||||
| SwRS-40 | SyRS-06 | `WebSuite/WebSettingGlobalBL.cs` |
|
||||
| SwRS-41 | SyRS-03 | `Accounts/CustomerToBranchBL.cs` |
|
||||
| SwRS-42 | SyRS-06 | `CentronConfigDb/MasterPasswordSecureFileStorage.cs` |
|
||||
| SwRS-44 | SyRS-16 | `EmployeeArea/EmployeeHolidayBL.cs:25-34` |
|
||||
| SwRS-45 | SyRS-06 | `MyDay/MyDayBL.cs` |
|
||||
| SwRS-46 | SyRS-16 | `TaskManager/TaskManagementTaskBL.cs` + Handler |
|
||||
| SwRS-47 | SyRS-06 | `Mail/CentronMailFactory.cs` |
|
||||
| SwRS-48 | SyRS-16 | `MailScanner/MailScannerBL.cs:36,45` |
|
||||
| SwRS-49 | SyRS-16 | `Mailings/MailingDataBL.cs` |
|
||||
| SwRS-50 | SyRS-16 | `Chats/ChatBL.cs:45,176` |
|
||||
| SwRS-51 | SyRS-13 | `NexusNotifications/NotificationsHubHelper.cs` |
|
||||
| SwRS-52 | SyRS-11 | `Tapi/PhoneCallBL.cs:52` |
|
||||
| SwRS-54 | SyRS-01 | `ReceiptBL.cs:4865` (Projektnummer) |
|
||||
| SwRS-55 | SyRS-16 | `Production/ProductionOrderBL.cs:35-184` |
|
||||
| SwRS-56 | SyRS-14 | `Statistics/CacheSalesStatisticsBL.cs` |
|
||||
| SwRS-57 | SyRS-12 | `IndexSearch/IndexSearchBL.cs:28-44` |
|
||||
| SwRS-59 | SyRS-16 | `Tags/TagsBL.cs:19,70` |
|
||||
| SwRS-60 | SyRS-16 | `WebLinks/WebLinkActionReminderHandler.cs` |
|
||||
| SwRS-61 | SyRS-16 | `VideoPortal/VideoPortalAssignmentBL.cs:25` |
|
||||
| SwRS-62 | SyRS-16 | `SocialMedia/PersonSocialNetworkBL.cs` |
|
||||
| SwRS-63 | SyRS-16 | `VoucherManagement/VoucherManagementBL.cs:17` |
|
||||
| SwRS-64 | SyRS-06 | `SelfCare/SelfCareBL.cs:47,55` |
|
||||
| SwRS-65 | SyRS-03 | `ExternalToolsBL/ExternalToolBL.cs:58` |
|
||||
| SwRS-67 | SyRS-15 | `Transactions/TransactionBL.cs:29-63` |
|
||||
| SwRS-68 | SyRS-15 | `ChangeTracking/History/ImportHistoryBL.cs:20,27` |
|
||||
| SwRS-69 | SyRS-19 | `Telemetry/TelemetryBL.cs:23` |
|
||||
| SwRS-70 | SyRS-17 | `ArtificialIntelligence/ApiClientFactory.cs` |
|
||||
| SwRS-71 | SyRS-04 | `RiverDivo/RiverConnectionBL.cs` |
|
||||
| SwRS-72 | SyRS-16 | `TextModuleArea/TextModuleBL.cs:54-64` |
|
||||
| SwRS-73 | SyRS-16 | `ProductMatrix/ProductMatrixBL.cs:27-65` |
|
||||
| SwRS-74 | SyRS-11 | `Services/CTimeConnectorBL.cs` |
|
||||
| SwRS-77 | SyRS-12 | `GUI/UiProfileBL.cs` |
|
||||
| SwRS-78 | SyRS-13 | `Entities/Mobile/NewMobile*` |
|
||||
| SwRS-79 | SyRS-04 | `Modules/ModuleBL.cs:22,44` |
|
||||
| SwRS-81 | SyRS-16 | `DocumentationArea/DocumentationBL.cs:27-97` |
|
||||
| SwRS-82 | SyRS-03 | `PasswordManagementArea/PasswordManagementBL.cs:17,32` |
|
||||
| SwRS-83 | SyRS-04 | `Authenticator.cs:132,150` + WebVersion/VersionBL |
|
||||
| SwRS-84 | SyRS-17 | `Centron.Api.docuFORM/DocuFormRestApiClient.cs` |
|
||||
+377
File diff suppressed because one or more lines are too long
+126
@@ -0,0 +1,126 @@
|
||||
# Messprotokoll – Iteration 16/qwen/qwen3.8-flash-next/solo/max
|
||||
|
||||
> **GERUEST** – maschinell aus den Rohdaten erzeugt. Die Abschnitte *Anmerkungen*
|
||||
> und *Gueltigkeit* sind von Hand zu pruefen und zu ergaenzen.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `03_Prompt.md`
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-09-03T14:55:51.3674789+02:00
|
||||
- **Endzeit:** 2026-09-03T15:14:27.6927641+02:00
|
||||
- **Dauer gesamt:** 00:18:30 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:/DEV/MasterArbeit/QuellCode/CentronERP`
|
||||
- **Codebasis-Commit:** `e2c3a0e8f81d005161dde733f7e4b08f581e3468` (vor dem Lauf dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 13.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider tensorx` (Adapter-Version 2.5.2)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `qwen/qwen3.8-flash-next`
|
||||
- **Modell (tatsaechlich):** `qwen/qwen3.8-flash-next`
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `max` angefordert, **wirksam** (`effort_applied: true`)
|
||||
- **Ablage:** `Iteration 16/qwen/qwen3.8-flash-next/solo/max/`
|
||||
- **Agentenmodus:** `solo`
|
||||
- **Kontextfenster:** 0 Tokens geladen (Modellmaximum 0)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `?`, `lms` ?, Architektur `?`, **Quantisierung `?`**, ? Slots, GPU-Offload `?`, alleiniges Modell: ?
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0`, `--max-runtime` siehe Matrixskript
|
||||
- **Subagenten:** `spawned` = 0, `completed` = 0, `failed` = 0
|
||||
- **Rollen:** {}
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfaellt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgroesse | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 122.568 |
|
||||
| Output-Tokens | 99.634 |
|
||||
| Reasoning-Tokens | 33.710 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 82 |
|
||||
|
||||
**Tokens gesamt: 5.736.232.** Kosten `0` – lokaler Betrieb ().
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 13 | 11,1 % |
|
||||
| SyRS | 20 | 17,1 % |
|
||||
| SwRS | 84 | 71,8 % |
|
||||
| **Gesamt** | **117** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 43 | 36,8 % |
|
||||
| Daten | 23 | 19,7 % |
|
||||
| Schnittstelle | 21 | 17,9 % |
|
||||
| Sicherheit | 16 | 13,7 % |
|
||||
| nicht-funktional | 14 | 12,0 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 191 |
|
||||
| davon `PRIMÄR` | 136 (71,2 %) |
|
||||
| davon `SEKUNDÄR` | 46 (24,1 %) |
|
||||
| davon `KONTEXT` | 9 (4,7 %) |
|
||||
| Belege je Anforderung (Median) | 2 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 114 (97,4 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 106 | 90,6 % |
|
||||
| workaround | 4 | 3,4 % |
|
||||
| sonderfall | 7 | 6,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 114 | 97,4 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 3 | 2,6 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 60 | 51,3 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 28 | 23,9 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (26 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 117 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 117 von 117 mit Tracelinks (100,0 %) |
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** `is_error: false`, `subtype: success`, `exit_code: 0`, `timed_out: false`
|
||||
- **Session-ID:** `ses_f98a8e51fffe3QtphUN2xVQvN5`
|
||||
- **Werkzeugaufrufe:** 131 – {"bash": 109, "write": 8, "edit": 12, "grep": 1, "read": 1}
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt fuer solo
|
||||
- **Gueltigkeit:** *(pruefen)* Ergebnisdateien vorhanden.
|
||||
- **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
|
||||
- **Root unveraendert:** ja
|
||||
- **Fehlermeldungen:** []
|
||||
|
||||
## Anmerkungen/Auffaelligkeiten
|
||||
|
||||
*(von Hand zu ergaenzen)*
|
||||
+1185
File diff suppressed because one or more lines are too long
+5
@@ -0,0 +1,5 @@
|
||||
[2026-09-03T12:55:53.171309+00:00] Spiegel angelegt: C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\_meta\spiegel (13 Junctions, 17 Dateien, Ergebnisse -> C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\Ergebnisse)
|
||||
[2026-09-03T12:55:53.444214+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=tensorx; Modell=tensorx/qwen/qwen3.8-flash-next; Modus=solo; Effort=max (uebergeben=True); Stall-Timeout=0s
|
||||
[2026-09-03T13:14:26.157936+00:00] 0 Ergebnisdatei(en) aus dem Spiegel uebernommen
|
||||
[2026-09-03T13:14:27.621337+00:00] OpenCode export: Exporting session: ses_f98a8e51fffe3QtphUN2xVQvN5
|
||||
[2026-09-03T13:14:27.668580+00:00] Ende: Exitcode=0; Status=success; Turns=82; Tokens=5736232; Dateien=7; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+2299
File diff suppressed because it is too large
Load Diff
+64
@@ -0,0 +1,64 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
|
||||
|
||||
Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
|
||||
|
||||
### Verteilung über die Ebenen
|
||||
|
||||
| Ebene | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| StRS | 13 | 11,1 % |
|
||||
| SyRS | 20 | 17,1 % |
|
||||
| SwRS | 84 | 71,8 % |
|
||||
| **Gesamt** | **117** | 100 % |
|
||||
|
||||
### Anforderungstypen
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| funktional | 43 | 36,8 % |
|
||||
| Daten | 23 | 19,7 % |
|
||||
| Schnittstelle | 21 | 17,9 % |
|
||||
| Sicherheit | 16 | 13,7 % |
|
||||
| nicht-funktional | 14 | 12,0 % |
|
||||
|
||||
### Belegqualität
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Belege gesamt | 191 |
|
||||
| davon `PRIMÄR` | 136 (71,2 %) |
|
||||
| davon `SEKUNDÄR` | 46 (24,1 %) |
|
||||
| davon `KONTEXT` | 9 (4,7 %) |
|
||||
| Belege je Anforderung (Median) | 2 |
|
||||
| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 114 (97,4 %) |
|
||||
|
||||
### Übernahmewürdigkeit
|
||||
|
||||
| Einstufung | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| übernehmen | 106 | 90,6 % |
|
||||
| workaround | 4 | 3,4 % |
|
||||
| sonderfall | 7 | 6,0 % |
|
||||
|
||||
### Status
|
||||
|
||||
| Kategorie | Anzahl | Anteil |
|
||||
|---|---:|---:|
|
||||
| belegt | 114 | 97,4 % |
|
||||
| als `HYPOTHESE` gekennzeichnet | 3 | 2,6 % |
|
||||
| als Workaround vermerkt | 0 | 0,0 % |
|
||||
| Konsolidierungskandidaten | 60 | 51,3 % |
|
||||
| mit ISO-25010-Qualitätsmerkmal | 28 | 23,9 % |
|
||||
|
||||
### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
|
||||
|
||||
| Vorgabe | Ergebnis |
|
||||
|---|---|
|
||||
| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
|
||||
| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (26 risikorelevante Anforderungen, alle gedeckt) |
|
||||
| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
|
||||
| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 117 Anforderungen eingestuft) |
|
||||
| **Traceability** – Verknüpfung zwischen den Ebenen | 117 von 117 mit Tracelinks (100,0 %) |
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 16\qwen\qwen3.8-flash-next\solo\max\03_Lauf_2026-09-03_145551_v13.0.0-e556\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-03T15:14:27.6927641+02:00
|
||||
+230
@@ -0,0 +1,230 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "TensorX",
|
||||
"options": {
|
||||
"baseURL": "https://api.tensorx.ai/v1"
|
||||
},
|
||||
"models": {
|
||||
"qwen/qwen3.8-flash-next": {
|
||||
"name": "Qwen 3.8 Flash Next",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.2": {
|
||||
"name": "GLM 5.2",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.3-flash": {
|
||||
"name": "GLM 5.3 Flash",
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"moonshotai/kimi-k3": {
|
||||
"name": "Kimi K3",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/**": "allow",
|
||||
"../../Ergebnisse": "allow",
|
||||
"../../Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse/**": "allow",
|
||||
"Ergebnisse": "allow",
|
||||
"Ergebnisse/**": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 16/qwen/qwen3.8-flash-next/solo/max/03_Lauf_2026-09-03_145551_v13.0.0-e556/_meta/spiegel/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "tensorx/qwen/qwen3.8-flash-next",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+10265
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-03T14:55:51.3674789+02:00
|
||||
Reference in New Issue
Block a user