Iteration 3: Modell- und Modusraster erweitert, Skill 7.0.0, V2/V3 vorbereitet

Neue gueltige Zellen in Iteration 3
- claude-opus-5/solo/high: 363 Anforderungen, 99,7 % mit Primaerbeleg,
  Belege je Anforderung Median 2,0, 38,1 Mio. Tokens
- claude-fable-5/solo/high: 241 Anforderungen, 98,3 % mit Primaerbeleg,
  89,0 % PRIMAER-Anteil, vollstaendig regelkonform, 30,6 Mio. Tokens

Damit sind 6 von 12 Zellen des Rasters belegt. Zwei Befunde daraus:

Die Belegdichte folgt dem Modell, nicht dem Effort. Opus erreicht Median 2,0
auch auf high; alle 44 Sonnet-Laeufe lagen bei 1,0. max hebt Opus auf 3,0.
Die frueher dem Effort zugeschriebene Verdopplung ist damit eingegrenzt.

Die Fable-Modellverletzung ist reproduziert und abgegrenzt. Bei builtin laufen
die Subagenten auf claude-opus-5[1m] statt Fable (zweiter Fall nach Iteration 1),
bei solo dagegen sauber. Nicht das Modell ist die Ursache, sondern Fable in
Kombination mit Delegation.

Fehlmessungen, vollstaendig protokolliert
- vier 429-Abbrueche (Session-Kontingent) aus dem Parallelblock 19:59;
  drei davon mit Teilbestand, einer ohne Ergebnis
- opus-5/builtin/high zum dritten Mal gescheitert: 790,7 Mio. Tokens ueber drei
  Anlaeufe ohne Artefakt. Zelle mit dieser Prompt-Version nicht messbar.

Skill 7.0.0 (MAJOR)
- Isolationsmechanismus modusabhaengig: --safe-mode schaltet MCP-Server und
  Custom-Agenten ab und ist mit V2/V3 unvereinbar. Smoke-Test verifiziert:
  mit Flag spawned=0, ohne Flag spawned=2. Ersatz fuer custom/MCP:
  --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand.
- 6.1.0: Pflichtpruefung leeres Ergebnisverzeichnis = Fehlmessung unabhaengig von
  is_error; CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; Protokollfeld Gueltigkeit
- extract-subagenten.py: Start-Quittung wird nicht mehr als Ertragsmass ausgewiesen

Versuch 2 und 3 vorbereitet
- Prompt-Kette V1 -> V2 (02-A, angepasst an Agentendateien) -> V3 (02-B, MCP)
- V2: acht Rollen inkl. nicht delegierendem ISO-29148-Orchestrator
- V3: elf Rollen, fuenf Werkzeugserver, neue Belegklasse LAUFZEIT

Ablaufprotokoll um Phase 6 und 7 sowie die Vorbereitung von V2/V3 ergaenzt.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Christoph Schwörer
2026-08-27 08:03:00 +02:00
co-authored by Claude Opus 5
parent affde3a45f
commit 3d5b691bfa
89 changed files with 39498 additions and 104 deletions
@@ -0,0 +1,252 @@
# Analysebericht — Reverse Requirements Engineering c-entron ERP-Suite
**Lauf:** V1 Baseline (Prompt-only), Iteration 02 — 2026-08-26
**Untersuchungsgegenstand:** Gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (nur lesend analysiert)
**Methode:** Statische Analyse entlang der RRE-Methodenkette (Schritte 0, 0b, 0c, 2–6); keine Ausführung des Systems.
## Überblick über den Untersuchungsgegenstand
Die c-entron ERP-Suite ist ein ERP-/Servicemanagement-System für IT-Systemhäuser (deutschsprachiger Markt) mit:
- **WPF-Desktop-Client** (`src\centron\Centron.WPF.UI`, ~29 Fachmodule) — „c-entron.NET"
- **Backend-Geschäftslogik** (`src\backend\Centron.BL`, >80 Fachbereiche) mit NHibernate-Datenzugriff (`Centron.DAO`, `Centron.Entities`)
- **REST-Webservice** (`src\webservice\Centron.Host`, `Centron.Controllers`, `Centron.WebServices.Core`) — der WPF-Client arbeitet wahlweise direkt gegen SQL Server oder über den Webservice (Dual-Architektur `BLLogic`/`WSLogic`, siehe `docs\getting-started\general-structure.md`)
- **Blazor-Web-App „c-entron Nexus"** (`src\nexus\CentronNexus`) mit ServiceBoard (Ticket-Arbeitsplatz), WebCart-Kundenportal, WebOffer, Office, DocumentSigning, ProductionOrderManagement sowie ein **Outlook-Add-In**
- **Externe API-Integrationen** (`src\apis`, `Centron.Api.docuFORM`): ITscope, COP, EGIS, Icecat, finAPI, GLS, Shipcloud, ebInterface, docuFORM
- **MSSQL-Datenbank**: Schema-Dump `SSMS_DB_SCHEMA.sql` mit 1.535 `CREATE TABLE`-Anweisungen (Legacy-Tabellen mit deutschen Namen, z. B. `AngKopf`/`AufKopf`/`RechKopf`, plus englischsprachige Views)
- **Entwicklerdokumentation** (`docs\`) — dient als KONTEXT-Beleg (u. a. `CentronRights.md`, `docs\reference\receipts\*`, `docs\reference\security\*`)
- **Deployment**: WiX-Installer (`deployment\`), Docker/Linux-Betrieb des Webservice (`docker\`), Azure-Pipelines (`azure\`)
- **Tests**: `tests\` (End-to-End, Integration, Playwright, Unit)
Umfang: ca. 15.554 C#-Dateien. Eine Original-Commit-Historie des ERP-Produkts liegt nicht vor (die Codebasis wurde als Snapshot in das Arbeitsrepository übernommen); Change-Historie stand daher als Artefaktquelle nicht zur Verfügung.
## Schritt 0 — Modulinventar
Bezugsgröße für Abdeckung und Mindestabdeckung. Pfade relativ zu `C:\DEV\MasterArbeit\QuellCode\CentronERP`. Kürzel: `UI` = `src\centron\Centron.WPF.UI\Modules`, `BL` = `src\backend\Centron.BL`. Spalte AP = Arbeitspaket der Analyse.
### A — Vertrieb & Belegwesen
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M01 | Belegwesen Verkauf (Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholliste) | `BL\Sales\Receipts` (Offers, Orders, DeliveryLists, Invoices, CreditVouchers, PickupLists, DownPayment), `UI\Sales` | Kern-Belegkette des Verkaufs von Angebot bis Gutschrift inkl. Versionierung und Statusführung. | AP1 |
| M02 | Sonderpreise / Aktionspreise | `docs\reference\receipts\actionprice-system.md`, BL `Accounts` (Sonderpreise), `UI\Sales\SpecialArticleImport` | Kunden-/aktionsbezogene Preisfindung und Import von Sonderpreisen. | AP1 |
| M03 | Belegkonditionen | `UI\Administration\ReceiptConditions` | Verwaltung von Zahlungs-/Lieferkonditionen für Belege. | AP1 |
| M04 | Kassenbuch | `BL\Sales\CashBooks` | Führen von Kassenbüchern mit Ein-/Auszahlungen. | AP1 |
| M05 | Schweiz-Sonderlogik Belege | `BL\Sales\Receipts\Switzerland` | Länderspezifische Sonderbehandlung von Belegen für die Schweiz. | AP1 |
| M06 | Stundenzuschlagssätze | `BL\Sales\HourlySurchargeRatesBL`, `UI\Administration\HourlySurchargeRates` | Zuschlagssätze auf Stundenleistungen. | AP1 |
| M07 | Serienmails/Mailing-Aktionen | `UI\Sales\Mailing`, `BL\Mailings` | Serienmail-Kampagnen mit Vorlagen und Empfängerlisten. | AP9 |
### B — Verträge & wiederkehrende Abrechnung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M08 | Vertragsverwaltung | `UI\Finances\Contracts`, `BL\Sales\Receipts\ContractLists`, `docs\reference\receipts\contracts-backend.md` | Verwaltung von Service-/Wartungsverträgen als Belegart (VertragKopf/VertragPos). | AP2 |
| M09 | Automatische Vertragsabrechnung | `UI\Finances\AutomatedBilling`, `docs\reference\receipts\Contract-Billing-RMM-Article-Logic.md` | Periodische Fakturierung von Verträgen inkl. RMM-Mengenlogik. | AP2 |
| M10 | Flatrate-Abrechnung | `UI\Finances\FlatrateBilling` | Pauschal-Abrechnung von Leistungen. | AP2 |
| M11 | Timer-/Zeitabrechnung | `UI\Finances\TimerBilling`, `UI\Helpdesk` (HelpdeskTimers) | Abrechnung erfasster Arbeitszeiten aus Tickets. | AP2 |
| M12 | Geräte-Klickabrechnung | `UI\Finances\DeviceClickCounter` | Abrechnung von Druck-/Kopierklicks je Gerät (Zählerstände). | AP2 |
| M13 | Vertragsauswertung | `UI\Finances\ContractEvaluation2`, `UI\Finances\ContractEvaluationOld` | Wirtschaftlichkeitsauswertung von Verträgen (neue und alte Implementierung). | AP2 |
| M14 | SEPA-Vertragsdaten | `UI\Administration\SepaContract` | Verwaltung von SEPA-Mandaten/Bankdaten für Vertragsabrechnung. | AP2 |
| M15 | Telekom-DIVE-Export | `UI\Modules\TelekomDive` | Export von Vertrags-/Abrechnungsdaten im Telekom-DIVE-Format. | AP2 |
### C — Finanzen & Buchhaltung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M16 | Offene Posten (OPOS) | `UI\Finances\Opos` | Überwachung offener Forderungen/Verbindlichkeiten. | AP3 |
| M17 | Zahlungsverkehr (Ein-/Ausgangszahlungen) | `UI\Finances\Payments`, `BL\Finances\IncomingPayments`, `BL\Finances\Payments`, `UI\Warehousing\OutcomingPayments` | Erfassen und Zuordnen von Zahlungen zu Belegen. | AP3 |
| M18 | Mahnwesen | `UI\Finances\Dunning` | Mahnläufe über fällige offene Posten. | AP3 |
| M19 | Online-Banking | `UI\Modules\OnlineBanking`, `BL\Finances\OnlineBanking`, `src\apis\Centron.APIs.FinAPI` | Bankkonten-Anbindung, Umsatzabruf und Zahlungen über finAPI. | AP3 |
| M20 | Buchhaltungsexport / DATEV | `UI\DataExchange\BookKeeping`, `UI\DataExchange\DatevOnline2020` | Export von Buchungsdaten an Finanzbuchhaltung/DATEV. | AP3 |
| M21 | E-Rechnung (ZUGFeRD/XRechnung/ebInterface) | `docs\guides\development\xrechnung.md`, `docs\reference\zugferd-field-mapping.md`, `src\apis\Centron.Api.EbInterface`, Controller `ZugferdImportController.cs`, `BL\ReportEngine` (ZUGFeRD-PDF) | Erzeugung und Import elektronischer Rechnungen. | AP3 |
| M22 | Bankverbindungen (Stammdaten) | `BL\Accounting` | Verwaltung der Bankkonten von Kunden und eigener Firma. | AP3 |
| M23 | Zahler & Kostenstellen | `UI\Modules\PayersAndCostCenter` | Verwaltung abweichender Zahler und Kostenstellen. | AP3 |
| M24 | Gutschein-Verwaltung | `BL\VoucherManagement` | Gutscheine mit Barcode und Einlösestatus. | AP3 |
### D — Einkauf & Beschaffung
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M25 | Einkaufsbelege (Bestellung, Wareneingang, Eingangsrechnung, Lieferanten-Gutschrift) | `BL\Sales\Receipts\SupplierOrders`, `...\SupplierDeliveryLists`, `...\SupplierInvoices`, `...\SupplierCreditVouchers`, `UI\Purchasing` | Einkaufsseitige Belegkette gegenüber Lieferanten. | AP4 |
| M26 | EDI-Anbindung Distributoren | `BL\EDI`, `UI\Purchasing\EDIManagement`, `docs\reference\edi\*` | Elektronischer Belegaustausch mit Distributoren (ALSO, Alltron, Komsa, EGIS, Concerto, OpenTrans). | AP4 |
| M27 | Bestellvorschläge | `UI\Purchasing\OrderSuggestionList` | Ermittlung von Bestellvorschlägen aus Bedarf/Beständen. | AP4 |
| M28 | Reisekosten | `UI\Purchasing\TravelExpense` | Erfassung und Abrechnung von Reisekosten. | AP4 |
| M29 | Distributoren-Stammdaten | `BL\Buying` | Stammdaten der Großhändler/Distributoren. | AP4 |
| M30 | ITscope-Marktplatz | `src\apis\Centron.APIs.ITscopeDataAccess` | Produkt-/Preis-/Bestellzugriff auf den ITscope-Marktplatz. | AP4 |
| M31 | COP-Produktdatendienst | `src\apis\Centron.APIs.CopDataAccess` | SOAP-Zugriff auf Produkt-, Preis- und Lieferantendaten (COP). | AP4 |
| M32 | EGIS-Distributionsdienst | `src\apis\Centron.APIs.EgisDataAccess` | Artikelsuche, Preise/Verfügbarkeiten, Produktspezifikationen (EGIS). | AP4 |
| M33 | Icecat-Produktkatalog | `src\apis\Centron.APIs.IcecatDataAccess` | Anreicherung von Artikeln mit Icecat-Katalogdaten. | AP4 |
| M34 | TradePool-Import | `BL\TradePool` | XML-Import von Handels-/Marktplatzdaten. | AP4 |
### E — Artikel, Lager & Logistik
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M35 | Artikelstamm | `UI\Warehousing\ArticleManagement`, `UI\Warehousing\SearchArticle` | Verwaltung des Artikelstamms inkl. Suche. | AP5 |
| M36 | Artikelimport | `UI\Warehousing\ArticleImport` | Dateibasierter Import von Artikeldaten. | AP5 |
| M37 | Artikel-Nebenstammdaten (Einheiten, Warengruppen, Kontenrahmen) | `UI\Warehousing\ArticleUnitManagement`, `...\MaterialGroupManagement`, `...\AccountSystems` | Pflege von Einheiten, Warengruppen und Kontenzuordnungen. | AP5 |
| M38 | Lager & Inventur | `BL\Storage`, `UI\Warehousing\Inventory` | Lagerverwaltung und Inventurdurchführung. | AP5 |
| M39 | Kommissionierung | `UI\Warehousing\Commissioning`, `UI\Warehousing\Commissions` | Kommissionieren von Aufträgen. | AP5 |
| M40 | Barcode-Verwaltung | `UI\Warehousing\BarcodeManagement` | Barcodes für Artikel/Lagerprozesse. | AP5 |
| M41 | Versand/Logistik | `UI\Modules\Logistic`, `BL\Logistics` | Versandabwicklung und Versandarten-Konfiguration. | AP5 |
| M42 | GLS-Versand | `src\apis\Centron.Api.Gls` | Paketerstellung und Labeldruck über GLS. | AP5 |
| M43 | Shipcloud-Versand | `src\apis\Centron.Api.Shipcloud` | Multi-Carrier-Versand über Shipcloud inkl. Zolldaten. | AP5 |
| M44 | Lieferantensuche | `UI\Warehousing\SupplierSearch`, `BL\BusinessPartner` | Suche von Lieferanten zu Artikeln. | AP5 |
### F — Helpdesk & Service
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M45 | Helpdesk/Ticketsystem (Kern) | `UI\Helpdesk` (TicketList, TicketDetails, Dashboard), `BL\Modules`-übergreifende Helpdesk-BLs, `CentronRights.md` | Zentrales Ticketsystem für Servicefälle inkl. Rechten, Timern, Dashboard. | AP6 |
| M46 | Checklisten | `BL\CheckListArea`, `UI\Helpdesk\CentronChecklist` | Checklisten mit Positionen und Änderungsprotokoll. | AP6 |
| M47 | Erwartete Ereignisse | `BL\ExpectedEvents`, `UI\Helpdesk\ExpectedEvents`, `...\ExpectedEventsReporting` | Überwachung erwarteter Ereignisse/Fälligkeiten mit Auswertung. | AP6 |
| M48 | Aufgabenverwaltung (TaskManager) | `BL\TaskManager`, `UI\Helpdesk\TaskManagement`, `UI\Administration\TaskManagmentSettings` | Aufgaben mit konfigurierbaren Aktions-Handlern. | AP6 |
| M49 | Ticket-Projekte | `BL\TicketProjects` | Bündelung von Tickets zu Projekten inkl. Abhängigkeiten. | AP6 |
| M50 | Ticket-Prozessvorlagen / Ticket-Muster | `UI\Helpdesk\TicketProcessTemplates`, Controller `TicketPatternsController.cs` | Vorlagen für wiederkehrende Ticketprozesse. | AP6 |
| M51 | SelfCare-Formulare | `BL\SelfCare`, `UI\Helpdesk\SendSelfCareForm`, Controller `SelfCareFormsController.cs` | Self-Service-Formulare für Endkunden. | AP6 |
| M52 | Externes Helpdesk | `BL\ExternalHelpdesk` | Anbindung externer Ticketsysteme. | AP6 |
| M53 | Zeitregeln/Fristen | `BL\Time` | Konfigurierbare Zeitregeln (z. B. für Fristen und Jobs). | AP6 |
| M54 | Eskalationen | `UI\Administration\EscalationsSettings`, `src\webservice\Centron.Host` (Eskalationsdienst) | Eskalationsregeln für Tickets/Fristen. | AP6 |
| M55 | Umfragen | `UI\Modules\Survey` | Erstellen, Ausführen und Auswerten von Umfragen. | AP6 |
| M56 | RMA-Abwicklung | `UI\Modules\Rma`, `BL\CustomerArea\RmaBL.cs` | Rücksendeabwicklung an Lieferanten und Rückgabe an Kunden. | AP6 |
| M57 | IT-Planner | `BL\ItPlanner` | Kategorien virtueller Objekte für IT-Planungs-/Checklistenstruktur. | AP6 |
| M58 | DocuBoard / Asset-Management-Board | `BL\DocuBoard` | Board mit Partner-, Artikelzuordnungs- und AD-Benutzerausschlussverwaltung. | AP6 |
### G — CRM & Stammdaten
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M59 | Adress-/Kundenstamm | `BL\Accounts`, `BL\CustomerArea`, `BL\Sales\Customers` | Zentraler Kunden-/Adressstamm mit Ansprechpartnern, Branchen, Interessen. | AP8 |
| M60 | Kontaktaktivitäten / CRM | `UI\Finances\Crm`, `BL\CustomerArea` (Aktivitäten) | Dokumentation von Kundenkontakten und Aktivitäten. | AP8 |
| M61 | Kampagnen | `UI\Finances\Campaigns`, `BL\Accounts\Campaigns`, `BL\Sales\Marketing` | Marketing-Kampagnen mit Kundenzuordnung. | AP8 |
| M62 | Geräte/Assets beim Kunden | `BL\Devices`, `BL\Sales\CustomerAssets`, `BL\BusinessPartner\SupplierAssetBL.cs` | Verwaltung von Kundengeräten/Assets (inkl. getrennter Druckerstammblätter — Konsolidierungskandidat). | AP8 |
| M63 | Projekte | `BL\Projects`, `UI\Modules\ProjectManagement`, `UI\Finances\Projects` | Projektstammdaten und Projektsichten. | AP8 |
| M64 | Projektpreis-/Sonderpreisimport & Custom Gateways | `UI\Modules\ProjectPriceImport`, `BL\Gateway`, `UI\Sales\SpecialArticleToContractImport` | Import kundenspezifischer Preis-/Vertragsdaten über konfigurierbare Gateways. | AP11 |
| M65 | Länder & Bundesländer | `BL\CountryArea`, `UI\Administration\CountryManagement` | Stammdaten Länder/Bundesländer. | AP8 |
| M66 | Tags/Schlagwörter | `BL\Tags` | Schlagwortverwaltung und Zuordnung zu Objekten. | AP8 |
| M67 | Textbausteine | `BL\TextModuleArea`, `UI\Administration\TextBlockManagement` | Textbausteine inkl. Anrede-/Grußformel-Ersetzung. | AP8 |
| M68 | Mitarbeiterverwaltung | `BL\EmployeeArea`, `UI\Administration\EmployeeManagement` | Mitarbeiterstamm, App-Benutzer, Abteilungen, Urlaub, RFID, Teams. | AP8 |
| M69 | Stammdatenlisten | `UI\Finances\MasterDataLists`, Controller `MasterDataListsController.cs` | Pflege einfacher Auswahl-/Stammdatenlisten. | AP8 |
| M70 | Massenupdates | `BL\MassUpdate`, `UI\Modules\Massenupdates` | Massenänderungen über konfigurierbare Update-Jobs. | AP8 |
| M71 | Kundenindividuelle Zusatztabellen | `BL\Customizations` | Custom Tables mit Variablenersetzung. | AP8 |
| M72 | Externe Objektreferenzen | `BL\ObjectExternalReferences`, Controller `ObjectExternalReferencesController.cs` | Verknüpfung von c-entron-Objekten mit Fremdsystem-IDs. | AP8 |
| M73 | Produktmatrix | `BL\ProductMatrix`, `UI\Sales\ProductMatrix` | Produktkategorien-Matrix je Kunde. | AP8 |
| M74 | DSGVO | `UI\Administration\DSGVO` | Datenschutzfunktionen (Auskunft/Löschung). | AP7 |
### H — Kommunikation & Zusammenarbeit
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M75 | E-Mail-Versand/-Zugriff | `BL\Mail` (SMTP, Exchange/EWS, MS Graph), `UI\Administration\MailTemplates`, `docs\guides\development\create-mail-templates.md` | Mailversand über mehrere Protokolle inkl. Vorlagen und Signaturen. | AP9 |
| M76 | MailScanner | `BL\MailScanner` | Automatisches Auslesen von Postfächern zur Weiterverarbeitung (Ticket-/Belegerzeugung). | AP9 |
| M77 | Kalender & Exchange-Sync | `UI\Modules\Calendar`, `BL\Calendar`, `UI\Administration\MailAndCalender`, `docs\features\exchange-sync-bugprotokoll.md` | Terminverwaltung und Synchronisation mit Exchange. | AP9 |
| M78 | Terminanfragen | `BL\AppointmentRequests` | Terminanfragen mit Zu-/Absagen. | AP9 |
| M79 | Outlook-Add-In | `src\nexus\CentronNexus.OutlookAddIn`, `BL\Outlook` | Kontextanzeige von Kunde/Belegen/Aktivitäten zur aktuellen Mail. | AP9 |
| M80 | Telefonie (TAPI) | `BL\Tapi`, `docs\reference\architecture\tapi.md`, `UI\Administration\PhoneSettings` | Anruferfassung und -auswertung über TAPI. | AP9 |
| M81 | Interner Chat | `BL\Chats` | Interner Chat mit Objektbezug. | AP9 |
| M82 | Benachrichtigungen | `BL\Notifications`, `BL\NexusNotifications` | Systemweite und Realtime-Benachrichtigungen (SignalR). | AP9 |
| M83 | Soziale Netzwerke | `BL\SocialMedia` | Zuordnung sozialer Netzwerke zu Personen. | AP9 |
| M84 | Videoportal | `BL\VideoPortal` | Zuordnung von Videoinhalten zu Objekten. | AP9 |
| M85 | Signierte Web-Links | `BL\WebLinks` | Signierte Links mit hinterlegten Aktionen. | AP9 |
| M86 | Kurz-URLs | `BL\Urls` | Einfache Objekt-/Kurz-URLs. | AP9 |
### I — Auswertung & persönlicher Arbeitsbereich
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M87 | Statistiken | `UI\Modules\Statistics`, `BL\Statistics` | Umsatz-/Kennzahlenauswertungen. | AP12 |
| M88 | Reports/Formulardruck | `BL\ReportEngine` (FastReport), `BL\Reporting`, `UI\Modules\Reports`, `UI\Administration\ReportServer` | Formular-/Reporterzeugung inkl. PDF und ReportServer. | AP11 |
| M89 | Dashboard | `UI\Modules\Dashboard` | Übergreifendes Kennzahlen-Dashboard. | AP12 |
| M90 | Volltextsuche | `BL\IndexSearch` (Lucene) | Volltextindizierung und -suche über Geschäftsobjekte. | AP11 |
| M91 | KI-Funktionen | `UI\Modules\ArtificialIntelligence`, `BL\ArtificialIntelligence`, Controller `ArtificialIntelligenceChatsController.cs` | KI-gestützte Chats/Assistenz. | AP12 |
| M92 | MyCentron/MyDay/ToDo/QuickNotes | `BL\MyCentron`, `BL\MyDay`, `BL\ToDoArea`, `UI\Modules\MyCentron` | Persönlicher Arbeitsbereich: Dashboard, Tagesübersicht, To-dos, Notizen. | AP12 |
### J — Sicherheit & Administration
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M93 | Benutzerrechte | `CentronRights.md`, `docs\guides\development\check-userrights.md`, `UI\Administration\RightsManagement`, UserRightsConst | Feingranulare Rechteverwaltung inkl. einschränkender Rechte (nur eigene / eigene Filiale). | AP7 |
| M94 | Authentifizierung & Login | `docs\reference\security\anmelden-mit-microsoft-technische-anleitung.md`, `src\webservice\Centron.Controllers\Controllers\...\JwtAuthController.cs`, `AuthConfigurationController.cs`, AccessTokens | Anmeldung am Client/Webservice inkl. „Anmelden mit Microsoft", JWT, Access-Tokens. | AP7 |
| M95 | Zwei-Faktor-Authentifizierung | `BL\TwoFactorAuthenticator`, Controller `TwoFactorAuthController.cs` | TOTP-Registrierung und -Prüfung. | AP7 |
| M96 | Passwortmanager | `BL\PasswordManagementArea`, `BL\PasswordManager`, `UI\Modules\PasswordManager` | Verwaltung von Kundenpasswörtern inkl. Zugriffs-/Änderungsprotokoll. | AP7 |
| M97 | Lizenzierung | `docs\reference\security\licensing-system.md`, `LicenseGuids.cs`, `ApplicationKind.cs`, Controller `LicenseController.cs` | GUID-basierte Lizenzen mit Anzahl/Gültigkeit je Feature und Applikation. | AP7 |
| M98 | Mandanten & Filialen | `UI\Administration\MandatorManagement`, Branch-Logik | Mandanten- und Filialverwaltung. | AP7 |
| M99 | PDF-Signatur | `BL\Security\PdfSigningBL.cs`, `UI\Administration\PdfSigning` | Digitale Signatur von PDF-Dokumenten mit Zertifikaten. | AP7 |
| M100 | Einstellungsverwaltung | `docs\guides\development\settings-management.md`, `UI\Administration\Settings` | Zentrale, hierarchische Verwaltung von System-/Benutzereinstellungen. | AP7 |
| M101 | Änderungsverfolgung/Audit | `BL\ChangeTracking` | Historisierung von Importen und Datenänderungen. | AP7 |
| M102 | Telemetrie | `BL\Telemetry` | Erfassung von Nutzungsdaten. | AP7 |
| M103 | Log-Viewer/Protokollierung | `UI\Administration\LogViewer` | Einsehen von Anwendungsprotokollen. | AP7 |
| M104 | Admin-Werkzeuge (Cache, Profiling, SqlManagers, CentronConfigDb, Connections) | `UI\Administration\Cache`, `...\Profiling`, `...\SqlManagers`, `...\CentronConfigDb`, `...\Connections` | Technische Administrationswerkzeuge des Clients. | AP7 |
| M105 | Modul-Registry & Favoriten | `BL\Modules` | Registrierung der Anwendungsmodule, Kategorien, Favoriten. | AP7 |
| M106 | Systemtabelle/ID-Vergabe | `BL\SystemArea\SystemTableI3DBL.cs` | Zentrale Systemtabelle mit ID-Vergabe (I3D). | AP11 |
### K — Web-Plattform & Schnittstellen
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M107 | Webservice-Server | `src\webservice\Centron.Host`, `src\webservice\Centron.Controllers`, `BL\WebServices` (Fassade, 464 Dateien), `docs\guides\services\add-webservice-methods.md` | REST-/Webservice-Schicht über der Geschäftslogik inkl. Hintergrunddienste. | AP10 |
| M108 | Webservice-Client-Kern | `src\webservice\Centron.WebServices.Core` | Transport, Serialisierung, JWT-Auth, HTTP-Clients für Client-Zugriffe. | AP10 |
| M109 | ConnectionManager | `src\webservice\c-entron.misc.ConnectionManager` | Admin-Tool für Verbindungen, Lizenzen, Hardware-ID, 2FA-Test. | AP10 |
| M110 | Nexus ServiceBoard | `src\nexus\CentronNexus\ServiceBoard`, `BL\NexusTicketViews`, `BL\CentronNexus` | Web-Ticket-Arbeitsplatz (Kanban, Scheduler, MyDay, Statistiken). | AP10 |
| M111 | Nexus WebCart/Kundenportal | `src\nexus\CentronNexus\WebCart`, `README.md` (WebCart), `UI\Administration\WebCart` | Webshop für Endkunden auf Basis von Web-Accounts und Sonderpreisen. | AP10 |
| M112 | Nexus WebOffer/Belegansicht | `src\nexus\CentronNexus\WebOffer` | Web-Ansicht von Belegen mit PDF-Vorschau. | AP10 |
| M113 | Nexus Office & DocumentSigning | `src\nexus\CentronNexus\Office`, `...\DocumentSigning` | Geteilte Dokumente, Freigaben und digitale Unterschrift. | AP10 |
| M114 | Nexus ProductionOrderManagement | `src\nexus\CentronNexus\ProductionOrderManagement` | Web-Verwaltung von Fertigungsaufträgen. | AP10 |
| M115 | Nexus Management/Settings/Shared | `src\nexus\CentronNexus\Management`, `...\Settings`, `...\Shared` | Web-Administration (TaskManagement, TicketPatterns, WebAccounts), Auth, Layout. | AP10 |
| M116 | Mobile-App-Backend | `BL\Mobile` | Datenversorgung der mobilen App. | AP10 |
| M117 | WebSuite (Alt-Web) | `BL\WebSuite` | Konfiguration der älteren Web-Suite. | AP10 |
| M118 | Webservice-Versionsabgleich | `BL\WebVersion` | Versionsermittlung/-abgleich zwischen Client und Webservice. | AP10 |
| M119 | RMM-/DocBee-Integrationen | `BL\Integrations`, Controller `RmmController.cs`, `DocBeeConnectorConfigurationController.cs`, `RmmConnectionSettingsController.cs`, `UI\DataExchange` (RMM) | Anbindung von RMM-Systemen und DocBee. | AP12 |
| M120 | RiverDivo-Schnittstelle | `BL\RiverDivo` | Webservice-Schnittstelle zum Riverbird/Divo-System. | AP12 |
| M121 | cPra-Anbindung | `BL\CPra` | Login/Konfiguration für das externe System „cPra". | AP12 |
| M122 | docuFORM-Anbindung | `Centron.Api.docuFORM`, Controller `DocuFormApiSettingsController.cs`, `UI\DataExchange` (DocSync) | REST-Anbindung docuFORM (OAuth, Kundenanlage, Deployments). | AP12 |
| M123 | Externe Tools | `BL\ExternalToolsBL`, `UI\Modules\ExternalTool`, `UI\Administration\ExternalTools` | Konfigurierbarer Aufruf externer Programme mit Variablenersetzung. | AP12 |
| M124 | Import-/Export-Framework (DataExchange) | `UI\Modules\DataExchange` (Assistenten, Konnektoren) | Generische Import-/Export-Assistenten und Konnektoren. | AP11 |
| M125 | Prozesse (generisch) | `BL\Processes` | Generische Vorgangs-/Prozessobjekte an beliebigen Objekten. | AP11 |
| M126 | Transaktionen | `BL\Transactions` | Verwaltung/Abfrage von Transaktionen. | AP11 |
### L — Produktion & Sonstige Fachmodule
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M127 | Produktion/Fertigungsaufträge | `UI\Modules\Production` (ProductionOrder, MachineManagement, Settings), `BL\Production` | Fertigungsaufträge und Maschinenverwaltung. | AP12 |
| M128 | Produkt-Lifecycle-Management | `UI\Modules\PLM`, `UI\Finances\ProductLifecycleManagement` | Produktfamilien/-gruppen mit Lebenszyklusinformationen. | AP12 |
| M129 | Qualitätsmanagement | `UI\Modules\QM` | QM-Einstellungen (Beleg-/Asset-Gründe). | AP12 |
| M130 | Dokumentation an Objekten | `BL\DocumentationArea`, `BL\Sales\DocumentationWizardArea` | Dokumentationseinträge zu Objekten inkl. Rechteprüfung. | AP12 |
### M — Plattform, Infrastruktur & Betrieb
| Nr | Modul | Pfad(e) | Fachliche Aufgabe | AP |
|---|---|---|---|---|
| M131 | WPF-Client-Rahmen | `src\centron\Centron.WPF.UI` (Start, Layout, Dialogs, Wizards), `src\centron\Centron.WPF.UI.Extension`, `src\shared\Centron.Controls` | Anwendungsrahmen: Start/Login, Modul-Hosting, MVVM, Steuerelemente. | AP11 |
| M132 | Lokalisierung | `docs\guides\ui\localization.md`, `LocalizedStrings.resx`/`.en.resx` | Zweisprachigkeit Deutsch (Standard)/Englisch. | AP11 |
| M133 | Datenzugriff & O/R-Mapping | `src\backend\Centron.DAO`, `src\backend\Centron.Entities`, `BL\Start` | NHibernate-basierter Datenzugriff, Entities, Mapping. | AP11 |
| M134 | Datenbankschema & Skript-System | `SSMS_DB_SCHEMA.sql`, `docs\guides\database\create-scripts.md`, `docs\reference\database\script-rules.md`, `scripts\` | 1.535 Tabellen, Views, Constraints; versionierte Migrationsskripte. | AP11 |
| M135 | Hintergrunddienste | `src\webservice\Centron.Host` (HostedServices), `docs\Background Service\DataQualityService.md` | Geplante Dienste: EDI-Download, Exchange-Sync, Indexierung, Eskalation, Preisupdates, Datenqualität. | AP10 |
| M136 | Deployment/Installer | `deployment\` (WiX), `azure\`, `version.json` | MSI-Installer für Client und Webservice, Build-Pipelines. | AP11 |
| M137 | Docker-/Linux-Betrieb | `docker\`, `docs\guides\services\web-service-on-linux.md` | Containerisierter Betrieb des Webservice. | AP11 |
| M138 | Teststrategie | `tests\` (EndToEnd, Integration, Playwright), `docs\guides\development\end-to-end-testing.md` | Automatisierte Regressions-/E2E-Tests. | AP11 |
| M139 | Gemeinsame Basisbibliothek | `src\shared\Centron.Core`, `src\backend\Centron.Common`, `src\backend\Centron.Interfaces`, `src\backend\Centron.Gateway` | Technische Querschnittsfunktionen (Guard, TOTP, Result-Pattern, DTOs). | AP11 |
**Inventarstand:** 139 Module/Komponenten. Das Inventar darf ergänzt, aber nicht gekürzt werden.
## Arbeitspakete der Analyse (Schritt 0b/0c)
| AP | Themenfeld | ID-Bereich (je Ebene) | Risikofokus |
|---|---|---|---|
| AP1 | Belegwesen Verkauf | 100–299 | Fakturierung ✔ |
| AP2 | Verträge & wiederkehrende Abrechnung | 300–499 | Fakturierung ✔ |
| AP3 | Finanzen & Buchhaltung | 500–699 | Abrechnung/Zahlung ✔ |
| AP4 | Einkauf & Beschaffung | 700–899 | — |
| AP5 | Artikel/Lager/Logistik | 900–1099 | — |
| AP6 | Helpdesk & Service | 1100–1299 | Berechtigungen (Ticketrechte) ✔ |
| AP7 | Sicherheit & Administration | 1300–1499 | Sicherheit/Berechtigungen ✔ |
| AP8 | CRM & Stammdaten | 1500–1699 | — |
| AP9 | Kommunikation | 1700–1899 | — |
| AP10 | Web-Plattform & Webservice | 1900–2099 | Auth am Webservice ✔ |
| AP11 | Plattform & Infrastruktur | 2100–2299 | — |
| AP12 | Übrige Fachmodule & Integrationen | 2300–2499 | — |
Mindestabdeckung (Schritt 0b): Jedes der 139 Module erhält mindestens eine Anforderung oder wird mit Begründung als `nicht analysiert` geführt. Vertiefung (Schritt 0c) erfolgt in AP1–AP3, AP6, AP7 und AP10 (Sicherheits-, Abrechnungs- und Berechtigungslogik).
*Die Abschnitte Abdeckungstabelle, Konsistenzcheck und Selbstbewertung werden nach Abschluss der Analyse ergänzt (siehe unten).*
@@ -0,0 +1,89 @@
# Messprotokoll – Versuch 01 (V1b Baseline mit werkzeugeigenen Agenten) – Prompt-Version 02
> ## ⚠ FEHLMESSUNG – nicht für Auswertungen verwenden
>
> Der Lauf brach mit `is_error: true` und HTTP 429 ab: „You've hit your session limit ·
> resets 10:50pm (Europe/Berlin)". Erzeugt wurden **1 von sieben** geforderten Ergebnisdateien; der Lauf brach mitten in der Bearbeitung ab. Verbraucht wurden
> bis zum Abbruch **77.815.316 Tokens**.
## Lauf
- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
- **Prompt-Version:** 02
- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
- **Startzeit:** 2026-08-26T20:00:11.2795634+02:00
- **Endzeit:** 2026-08-26T20:30:04.2067421+02:00
- **Dauer gesamt:** 00:07:4x — bis zum Kontingentabbruch
- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
- **Codebasis-Commit:** `f349d189c735a87f5829bc93f67991320061a2c0` (dirty: nein)
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; enthält `SSMS_DB_SCHEMA.sql`
## Werkzeugkonfiguration
- **Skill-Version:** 7.0.0
- **Claude-Code-Version:** 2.1.246
- **Modell (angefordert):** `claude-fable-5`
- **Modelle (tatsächlich eingesetzt):** `claude-fable-5` 77.433.773 (99.51 %), `claude-opus-5[1m]` 374.562 (0.48 %), `claude-haiku-4-5-20251001` 6.981 (0.01 %)
- **Kontrolle Modell:** **verletzt** – nicht angefordertes Modell `claude-opus-5[1m]` mit 374.562 Tokens (0.48 %)
- **Effort:** `high`
- **Agentenmodus:** `builtin` (V1b)
- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
- **Hintergrund-Wartezeit:** `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`
- **Parallele Läufe:** **ja** – alle vier Läufe der Welle liefen gleichzeitig
- **Subagenten:** 13 gestartet (1 × `Explore`, 12 × `general-purpose`), `max_depth` = 1
## Verbrauch
| Messgröße | `claude-fable-5` | `claude-opus-5[1m]` | `claude-haiku-4-5-20251001` | Summe |
|---|---:|---:|---:|---:|
| Input-Tokens | 1.426 | 20 | 6.961 | 8.407 |
| Output-Tokens | 1.037.386 | 15.803 | 20 | 1.053.209 |
| Cache-Write-Tokens | 4.150.505 | 52.132 | 0 | 4.202.637 |
| Cache-Read-Tokens | 72.244.456 | 306.607 | 0 | 72.551.063 |
| **Tokens gesamt** | **77.433.773** | **374.562** | **6.981** | **77.815.316** |
**Tokens gesamt: 77.815.316** — real angefallen und deshalb ausgewiesen, obwohl der Lauf ungültig ist.
## Gefundene Anforderungen
Der Lauf brach vor Abschluss ab. Die vorhandenen Dateien sind ein **Teilbestand** und mit vollständigen Läufen nicht vergleichbar; eine Auswertung unterbleibt deshalb.
## Ergebnis
- **Gültigkeit:** **Fehlmessung** – API-Abbruch (HTTP 429, Session-Kontingent); nur 1 von sieben Artefakten erzeugt
- **Status:** `is_error` = true, `terminal_reason` = `api_error`, `api_error_status` = 429
- **Session-ID:** `d77bf9b3-7a4d-4620-861f-28861a420996`
- **Turns:** 44
- **Permission-Denials:** 14
- **Erzeugte Dateien:** 1 von sieben geforderten Artefakten:
| Datei | Größe |
|---|---:|
| `Analysebericht.md` | 26.963 B |
Es fehlen: `StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`
- **Root unverändert:** ja
- **Abschlusstext des Agenten:** „You've hit your session limit · resets 10:50pm (Europe/Berlin)"
## Anmerkungen/Auffälligkeiten
**1. Kontingentabbruch, nicht Laufversagen.** Vier Läufe wurden am 26.08. um 19:59 gleichzeitig
gestartet; alle vier liefen in dieselbe Grenze. Zusammen hatten sie zu diesem Zeitpunkt
297,4 Mio. Tokens verbraucht, davon allein 204,4 Mio. im Lauf `45dd`. Die Parallelität von vier
Läufen – darunter einer mit extremer Delegation – hat das Kontingent gerissen.
**2. Konsequenz für den Versuchsaufbau:** Die verbleibenden Zellen werden **seriell** gefahren.
Der erste serielle Lauf danach (`opus-5/solo/high`, `2269`) lief mit 38,1 Mio. Tokens sauber durch.
**3. Die Modellverletzung aus Iteration 1 ist reproduziert.** `modelUsage` weist neben
`claude-fable-5` auch **`claude-opus-5[1m]`** aus. Derselbe Befund war in Iteration 1 unter
Prompt-Version 01 und ohne DB-Schema aufgetreten; damit ist aus einem Einzelfall ein belegtes
Muster geworden: **Fable wird bei Delegation nicht an die Subagenten durchgereicht**, Sonnet und
Opus dagegen schon. Ursache ist die Sitzungsvorgabe `model: opus[1m]` in
`~/.claude/settings.json`; `--safe-mode` verhindert das nicht.
Die Gegenprobe im selben Block bestätigt die Abgrenzung: Der Lauf `77a1` mit Fable im Modus
`solo` weist ausschließlich `claude-fable-5` plus Haiku aus. **Nicht das Modell ist das Problem,
sondern Fable in Kombination mit Delegation.**
**4. Die Zelle bleibt unbelegt.** Ein gültiger Lauf für `fable-5/builtin/high` steht aus. Er wäre
allerdings von vornherein als bedingungsverletzt zu führen, solange die Subagenten auf einem
nicht angeforderten Modell laufen.
@@ -0,0 +1,178 @@
# Versuch 01 - Baseline (Prompt-only) - Iteration 02
## Metadaten
- **Versuch:** V1 Baseline (Prompt-only)
- **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
- **Zeitstempel:** 2026-08-26
- **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
- **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
| Änderung | Auslösender Befund |
|---|---|
| Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
| Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
| Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
| Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
| Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
| Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
| Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
> 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.
---
## 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.
**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. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
- **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)
```
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)
```
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
### Randbedingungen
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
### Abschluss
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
- Doppelte oder mehrfach vergebene IDs
- Anforderungen ohne Beleg
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
- Tracelinks auf nicht existierende IDs
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
---
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
Für diesen Lauf stehen zur Verfügung: Lesen und Suchen von Dateien, das Ausführen von
Kommandozeilenbefehlen im Arbeitsverzeichnis sowie die werkzeugeigenen Subagenten.
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
Werkzeugserver.
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 3\claude-fable-5\builtin\high\02_Lauf_2026-08-26_195958_v7.0.0-d694\Ergebnisse\`.
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).