more runs before cline

2026-08-27 19:22:37 +02:00
parent 3d5b691bfa
commit ea1f3caff7
60 changed files with 30406 additions and 5 deletions
@@ -0,0 +1 @@
+{"is_error":true,"duration_api_ms":6921934,"num_turns":39,"stop_reason":"stop_sequence","session_id":"8d493a0f-f069-46a0-93de-8427787b311e","total_cost_usd":19.8662592,"usage":{"input_tokens":28,"cache_creation_input_tokens":110625,"cache_read_input_tokens":960495,"output_tokens":65463,"output_tokens_details":{"thinking_tokens":37220},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":110625,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":31750,"cache_read_input_tokens":106780,"cache_creation_input_tokens":3845,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":3845},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0070810000000000005,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":548,"outputTokens":710526,"cacheReadInputTokens":40508211,"cacheCreationInputTokens":1794097,"webSearchRequests":0,"costUSD":19.8591782,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Bash","tool_use_id":"toolu_01JBgsXfn416qWFSQG5hziEb","tool_input":{"command":"mkdir -p \"/c/Users/CHRIST~1/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/8d493a0f-f069-46a0-93de-8427787b311e/scratchpad/findings\"","description":"Ensure findings directory exists"}}],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":8,"requested":{"background":0,"foreground":8,"unset":0},"started_in_background":0,"max_depth":1,"spawned_by_subagents":0,"completed":4,"failed":4,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"general-purpose":8}},"subtype":"success","api_error_status":429,"result":"You've hit your weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":1716122,"uuid":"4b5fe352-1035-4d7b-a25a-af4850c43257","queued_turn_count":0}
@@ -0,0 +1 @@
+
@@ -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-sonnet-5\builtin\max\02_Lauf_2026-08-27_110958_v7.0.0-7499\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-27T11:38:36.1567144+02:00
@@ -0,0 +1 @@
+2026-08-27T11:09:58.2717910+02:00
@@ -0,0 +1 @@
+{"is_error":true,"duration_api_ms":0,"num_turns":1,"stop_reason":"stop_sequence","session_id":"af9be153-a3b0-427c-954b-615d562631fa","total_cost_usd":0,"usage":{"output_tokens_details":{"thinking_tokens":0},"input_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":0,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":0,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":429,"result":"You've hit your weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":457,"uuid":"10894110-3434-4adc-b7f0-6a0ee842f78a","queued_turn_count":0}
@@ -0,0 +1 @@
+
@@ -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-sonnet-5\builtin\max\02_Lauf_2026-08-27_124836_v7.0.0-cf3c\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-27T12:48:38.8520809+02:00
@@ -0,0 +1 @@
+2026-08-27T12:48:36.4195736+02:00
@@ -0,0 +1,327 @@
+# Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
+
+Untersuchungsgegenstand: gesamte Codebasis unter `C:\DEV\MasterArbeit\QuellCode\CentronERP` (Arbeitsverzeichnis, ausschließlich lesend analysiert). Pfadangaben in diesem Bericht sind relativ zu diesem Arbeitsverzeichnis.
+
+## Schritt 0 – Modulinventar
+
+Das Inventar wurde durch Auswertung der Projekt- und Verzeichnisstruktur (`Centron.sln`, `src/*`) erstellt, **bevor** eine Anforderung formuliert wurde. Es ist die Bezugsgröße für die Abdeckung (siehe Abdeckungstabelle am Ende dieses Berichts) und wird ergänzt, nicht gekürzt.
+
+Abgrenzung: Rein technische Querschnittsbibliotheken ohne eigenständige fachliche Funktion (u. a. `shared/Centron.Controls`, `shared/Centron.Core`, WPF-interne Ordner `Behaviors/`, `Extensions/`, `Style/`, `VisualTree/`) sind nicht als eigene Inventarzeile geführt; sie werden als technische Grundlage in den Belegen einzelner Anforderungen mitgenutzt, wo relevant. Große, fachlich heterogene Verzeichnisse (`Finances`, `Warehousing`, `Administration`, `Helpdesk`, `DataExchange`, `MyCentron`, `Statistics`, `Purchasing`) wurden auf Ebene ihrer Unterordner aufgeschlüsselt, weil diese jeweils eigenständige fachliche Funktionen abbilden; kleine, thematisch zusammengehörige Unterordner wurden zu einer Zeile zusammengefasst (z. B. mehrere Administration-„Settings“-Ordner). Vier produktdatenliefernde Fremd-APIs (COP/EGIS/ITscope/Icecat) sind wegen identischer fachlicher Funktion (externe Produktkatalog-Anreicherung) in einer Zeile zusammengefasst – siehe hierzu auch den Konsolidierungshinweis in SyRS.
+
+| Nr | Bereich | Modul/Komponente | Pfad (relativ zum Arbeitsverzeichnis) | Fachliche Aufgabe |
+|----|---------|-------------------|----------------------------------------|--------------------|
+| 1 | Vertrieb/CRM | Sales – Sonderpreise/Mailing | src/centron/Centron.WPF.UI/Modules/Sales | Verwaltung kundenspezifischer Sonderpreise, Serienmail- und Produktmatrix-Funktionen für den Vertrieb |
+| 2 | Vertrieb/CRM | CRM/Adressstamm | src/centron/Centron.WPF.UI/Modules/Finances/Crm | Zentrale Kunden-, Lieferanten- und Kontaktverwaltung (Adressstamm) inkl. Aktivitäten, Verträgen, Sonderpreisen, DSGVO-Tab |
+| 3 | Vertrieb/CRM | Kampagnenmanagement | src/centron/Centron.WPF.UI/Modules/Finances/Campaigns | Planung, Durchführung und Auswertung von Marketing-/Vertriebskampagnen |
+| 4 | Vertrieb/CRM | CRM-Stammdatenlisten | src/centron/Centron.WPF.UI/Modules/Finances/MasterDataLists | Listenbasierte Massenpflege von CRM-Stammdaten |
+| 5 | Vertrieb/CRM | Vertragsverwaltung & -auswertung | src/centron/Centron.WPF.UI/Modules/Finances/Contracts, ContractEvaluation2, ContractEvaluationOld | Verwaltung von Kundenverträgen und Auswertung von Vertragskennzahlen (zwei parallele Implementierungsstände) |
+| 6 | Vertrieb/CRM | Projektverwaltung (Finanzsicht) | src/centron/Centron.WPF.UI/Modules/Finances/Projects | Kaufmännische Projektverwaltung und -abrechnung |
+| 7 | Vertrieb/CRM | Zählerstandserfassung (MPS) | src/centron/Centron.WPF.UI/Modules/Finances/DeviceClickCounter | Erfassung von Zählerständen verwalteter Drucksysteme als Abrechnungsgrundlage (Managed Print Services) |
+| 8 | Vertrieb/CRM | Produktlebenszyklus-Management | src/centron/Centron.WPF.UI/Modules/PLM, Modules/Finances/ProductLifecycleManagement | Verwaltung von Produktfamilien und deren Lebenszyklusphasen |
+| 9 | Vertrieb/CRM | Zahler- und Kostenstellenverwaltung | src/centron/Centron.WPF.UI/Modules/PayersAndCostCenter | Zuordnung abweichender Zahler sowie Kostenstellen/-objekte zu Belegen |
+| 10 | Vertrieb/CRM | Projektpreisimport | src/centron/Centron.WPF.UI/Modules/ProjectPriceImport | Import und Abgleich projektspezifischer Preislisten |
+| 11 | Vertrieb/CRM | Projektmanagement (allgemein) | src/centron/Centron.WPF.UI/Modules/ProjectManagement | Allgemeine Projektverwaltungsfunktionen außerhalb der Finanzsicht |
+| 12 | Belegwesen | Belegbearbeitung Kern | src/centron/Centron.WPF.UI/Modules/Finances/Receipts | Erstellung/Bearbeitung der Belegkette Angebot–Auftrag–Lieferschein–Rechnung–Gutschrift inkl. Kalkulation, Positionserfassung, Belegvorlagen |
+| 13 | Belegwesen | Anzahlungen | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/DownPayment | Verwaltung von Anzahlungsrechnungen und deren Verrechnung |
+| 14 | Belegwesen | Steuersatzänderung im Beleg | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ChangeTaxRate | Nachträgliches Ändern des Steuersatzes auf Belegpositionen |
+| 15 | Belegwesen | Provisionsermittlung | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/Provision | Ermittlung von Verkäuferprovisionen je Beleg/Position (Korrektur: „PartialCommission" gehört fachlich zur Kommissionsware, siehe Zeile 32, nicht zur Verkäuferprovision – ursprüngliche Zuordnung war irreführend) |
+| 16 | Belegwesen | Web-Angebote | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/WebOffer, GenerateWebOffer | Bereitstellung von Angeboten über einen Weblink für Kunden |
+| 17 | Belegwesen | EDI-Auftragsverbuchung | src/centron/Centron.WPF.UI/Modules/Finances/Receipts/EdiOrderbooking | Automatisierte Verbuchung elektronisch eingehender Aufträge |
+| 18 | Abrechnung/Fakturierung | Automatisierte Rechnungserstellung | src/centron/Centron.WPF.UI/Modules/Finances/AutomatedBilling | Automatisiertes, periodisches Erstellen von Rechnungen aus Verträgen |
+| 19 | Abrechnung/Fakturierung | Pauschalabrechnung (Flatrate) | src/centron/Centron.WPF.UI/Modules/Finances/FlatrateBilling | Abrechnung pauschaler Vertragsleistungen |
+| 20 | Abrechnung/Fakturierung | Zeit-/Leistungsabrechnung (Timer) | src/centron/Centron.WPF.UI/Modules/Finances/TimerBilling | Abrechnung erfasster Zeiterfassungen/Leistungen |
+| 21 | Abrechnung/Fakturierung | Mahnwesen | src/centron/Centron.WPF.UI/Modules/Finances/Dunning | Automatisiertes Mahnverfahren für offene Forderungen |
+| 22 | Abrechnung/Fakturierung | Offene Posten | src/centron/Centron.WPF.UI/Modules/Finances/Opos | Verwaltung offener Forderungen/Verbindlichkeiten |
+| 23 | Abrechnung/Fakturierung | Zahlungsverkehr (Payments) | src/centron/Centron.WPF.UI/Modules/Finances/Payments | Erfassung und Zuordnung von Zahlungseingängen/-ausgängen |
+| 24 | Abrechnung/Fakturierung | Kontenverwaltung (Buchhaltung) | src/centron/Centron.WPF.UI/Modules/Finances/AccountManagement | Verwaltung von Finanzkonten und zugehörigen Buchungen |
+| 25 | Abrechnung/Fakturierung | Warenausgangszahlungen | src/centron/Centron.WPF.UI/Modules/Warehousing/OutcomingPayments | Erfassung von Zahlungen im Warenausgangsprozess (z. B. Nachnahme) |
+| 26 | Abrechnung/Fakturierung | Kassensystem-Anbindung | src/centron/Centron.WPF.UI/Modules/Warehousing/AccountSystems | Anbindung/Abgleich von Kassen-/Kontensystemen im Lager |
+| 27 | Lager/Artikel | Artikelstammdaten | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleManagement | Zentrale Pflege der Artikelstammdaten (Preise, Bestände, Merkmale) |
+| 28 | Lager/Artikel | Artikelimport | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleImport | Importieren von Artikeldaten aus externen Quellen |
+| 29 | Lager/Artikel | Mengeneinheitenverwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/ArticleUnitManagement | Pflege von Mengeneinheiten und Umrechnungsfaktoren |
+| 30 | Lager/Artikel | Barcode-Verwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/BarcodeManagement | Erzeugung/Zuordnung von Barcodes zu Artikeln |
+| 31 | Lager/Artikel | Kommissionierung | src/centron/Centron.WPF.UI/Modules/Warehousing/Commissioning | Steuerung der Warenkommissionierung im Lager |
+| 32 | Lager/Artikel | Kommissionsware/Konsignation | src/centron/Centron.WPF.UI/Modules/Warehousing/Commissions | Verwaltung von Kommissionsaufträgen (Konsignationslager) inkl. Teilkommissionen |
+| 33 | Lager/Artikel | Inventur | src/centron/Centron.WPF.UI/Modules/Warehousing/Inventory | Durchführung und Bewertung von Lagerinventuren |
+| 34 | Lager/Artikel | Warengruppenverwaltung | src/centron/Centron.WPF.UI/Modules/Warehousing/MaterialGroupManagement | Pflege der Warengruppenhierarchie |
+| 35 | Lager/Artikel | Artikelsuche | src/centron/Centron.WPF.UI/Modules/Warehousing/SearchArticle | Übergreifende Artikelsuche als UI-Dienst |
+| 36 | Lager/Artikel | Lieferantensuche | src/centron/Centron.WPF.UI/Modules/Warehousing/SupplierSearch | Suche/Auswahl von Lieferanten im Beschaffungskontext |
+| 37 | Lager/Artikel | Logistikeinstellungen/Versandarten | src/centron/Centron.WPF.UI/Modules/Logistic | Konfiguration von Versandarten und logistischen Einstellungen |
+| 38 | Einkauf | EDI-Bestellwesen | src/centron/Centron.WPF.UI/Modules/Purchasing/EDIManagement | Elektronischer Bestelldatenaustausch mit Lieferanten |
+| 39 | Einkauf | Bestellvorschlagsliste | src/centron/Centron.WPF.UI/Modules/Purchasing/OrderSuggestionList | Ermittlung von Nachbestellbedarf |
+| 40 | Einkauf | Einkaufseinstellungen | src/centron/Centron.WPF.UI/Modules/Purchasing/PurchaseSettings, Others | Grundeinstellungen des Einkaufsprozesses |
+| 41 | Einkauf | Reisekostenabrechnung | src/centron/Centron.WPF.UI/Modules/Purchasing/TravelExpense | Erfassung/Abrechnung von Reisekosten |
+| 42 | Produktion | Fertigungsauftragsverwaltung | src/centron/Centron.WPF.UI/Modules/Production/ProductionOrder, Settings | Anlage und Steuerung von Fertigungsaufträgen |
+| 43 | Produktion | Maschinenverwaltung | src/centron/Centron.WPF.UI/Modules/Production/MachineManagement | Stammdatenverwaltung von Produktionsmaschinen |
+| 44 | Retouren | RMA-Abwicklung | src/centron/Centron.WPF.UI/Modules/Rma | Abwicklung von Rücksendungen/Reklamationen (Return Merchandise Authorization) |
+| 45 | Helpdesk | Ticketverwaltung | src/centron/Centron.WPF.UI/Modules/Helpdesk/TicketDetails, TicketList, TicketProcessTemplates | Erfassung und Bearbeitung von Support-Tickets |
+| 46 | Helpdesk | Helpdesk-Dashboard | src/centron/Centron.WPF.UI/Modules/Helpdesk/Dashboard | Übersichts-/Kennzahlendarstellung für den Helpdesk |
+| 47 | Helpdesk | Wartungsverträge/erwartete Ereignisse | src/centron/Centron.WPF.UI/Modules/Helpdesk/ExpectedEvents, ExpectedEventsReporting | Überwachung vertraglich erwarteter Wartungsereignisse (SLA-Fristen) |
+| 48 | Helpdesk | Helpdesk-Einstellungen | src/centron/Centron.WPF.UI/Modules/Helpdesk/Settings, TaskManagement | Konfiguration von Ticketprozessen und Aufgaben |
+| 49 | Helpdesk | Helpdesk Sonstiges | src/centron/Centron.WPF.UI/Modules/Helpdesk/Events, ConnectionNumber, CentronChecklist, SendSelfCareForm | Ereignisprotokoll, Checklisten, Self-Service-Formular |
+| 50 | MyCentron | CentronInspectors | src/centron/Centron.WPF.UI/Modules/MyCentron/CentronInspectors | Pluggable Datenqualitäts-/Selbstdiagnoseprüfungen (Inspectors), die Stammdatenverstöße per SQL aufspüren und Korrekturdialoge anbieten (Korrektur ggü. Erstinventar: keine Prüfmittelverwaltung, sondern Dateninspektion) |
+| 51 | MyCentron | Persönliche Einstellungen | src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings | Benutzerbezogene Einstellungen |
+| 52 | MyCentron | Mein Tag (MyDay) | src/centron/Centron.WPF.UI/Modules/MyCentron/MyDay | Tagesplanansicht für Mitarbeitende |
+| 53 | MyCentron | MyCentron-Dashboard | src/centron/Centron.WPF.UI/Modules/MyCentron/Dashboard | Persönliches Übersichts-Dashboard |
+| 54 | MyCentron | Aufgabenliste (ToDo) | src/centron/Centron.WPF.UI/Modules/MyCentron/TodoList, Calendar | Persönliche Aufgaben-/Terminliste |
+| 55 | MyCentron | Telefonie-Integration | src/centron/Centron.WPF.UI/Modules/MyCentron/Telephony | Anbindung an Telefonanlage (CTI) |
+| 56 | MyCentron | Fernwartungsintegration (Supremo) | src/centron/Centron.WPF.UI/Modules/MyCentron/Supremo | Anbindung des Fernwartungstools Supremo |
+| 57 | Statistik | Verkaufsstatistik | src/centron/Centron.WPF.UI/Modules/Statistics/SaleStatistics | Auswertung von Verkaufszahlen |
+| 58 | Statistik | Management-Informationen | src/centron/Centron.WPF.UI/Modules/Statistics/ManagementInfo | Kennzahlen-Dashboards für das Management |
+| 59 | Statistik | MSP-Statistiken | src/centron/Centron.WPF.UI/Modules/Statistics/MspStatistics, MspCollectors | Auswertung von Managed-Service-Provider-Kennzahlen |
+| 60 | Statistik | Mitarbeiteranalyse | src/centron/Centron.WPF.UI/Modules/Statistics/EmployeeAnalytics | Auswertung mitarbeiterbezogener Kennzahlen |
+| 61 | Statistik | Reportverwaltung | src/centron/Centron.WPF.UI/Modules/Reports/ReportManagement | Verwaltung/Ausführung hinterlegter Reports |
+| 62 | Administration | Rechteverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/RightsManagement | Verwaltung von Benutzerrechten und Rollen (Risikobereich) |
+| 63 | Administration | Mitarbeiterverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/EmployeeManagement | Stammdatenverwaltung der Mitarbeitenden inkl. Rechtezuordnung |
+| 64 | Administration | Mandantenverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/MandatorManagement | Verwaltung mehrerer Mandanten (Multi-Tenant-Fähigkeit) |
+| 65 | Administration | DSGVO-Funktionen | src/centron/Centron.WPF.UI/Modules/Administration/DSGVO | Werkzeuge zur Umsetzung datenschutzrechtlicher Pflichten (Risikobereich) |
+| 66 | Administration | Systemeinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/Settings, Customization, Cache, Profiling | Allgemeine Systemkonfiguration |
+| 67 | Administration | Verbindungs-/Schnittstelleneinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/Connections, WebServiceSettings, SqlManagers, CentronConfigDb | Konfiguration von DB-/Webservice-Verbindungen |
+| 68 | Administration | Kommunikationseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/MailAndCalender, MailTemplates, PhoneSettings | Konfiguration von E-Mail-/Kalender-/Telefonanbindung |
+| 69 | Administration | Belegwesen-Konfiguration | src/centron/Centron.WPF.UI/Modules/Administration/PdfExport, PdfSigning, ReceiptConditions, TextBlockManagement, ReportServer | Konfiguration von PDF-Erzeugung/-Signatur, Textbausteinen, Reportserver |
+| 70 | Administration | Stundensätze/Zuschläge | src/centron/Centron.WPF.UI/Modules/Administration/HourlySurchargeRates | Pflege von Stundenverrechnungssätzen und Zuschlägen |
+| 71 | Administration | Eskalationseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/EscalationsSettings | Konfiguration von SLA-Eskalationsregeln |
+| 72 | Administration | Länderverwaltung | src/centron/Centron.WPF.UI/Modules/Administration/CountryManagement | Pflege von Länderstammdaten |
+| 73 | Administration | Service-/Leasing-/SEPA-Verträge | src/centron/Centron.WPF.UI/Modules/Administration/ServiceAndLeasing, SepaContract | Verwaltung von Service-/Leasingverträgen und SEPA-Lastschriftmandaten (Risikobereich) |
+| 74 | Administration | Externe Werkzeuge | src/centron/Centron.WPF.UI/Modules/Administration/ExternalTools, Modules/ExternalTool | Einbindung externer Zusatzwerkzeuge |
+| 75 | Administration | WebCart-Konfiguration | src/centron/Centron.WPF.UI/Modules/Administration/WebCart | Konfiguration des Web-Shops für Kunden |
+| 76 | Administration | Sonstige Prozesseinstellungen | src/centron/Centron.WPF.UI/Modules/Administration/TaskManagmentSettings, UpdateAvailableNotificationSettings, SendDeliveryListShippingConfirmationSettings | Verschiedene Prozess-Konfigurationsschalter |
+| 77 | Administration | Log-Betrachter | src/centron/Centron.WPF.UI/Modules/Administration/LogViewer | Einsicht in Anwendungs-Logdateien |
+| 78 | Administration | Dienste-Verwaltung | src/centron/Centron.WPF.UI/Modules/Administration/Services | Verwaltung von Hintergrunddiensten |
+| 79 | OnlineBanking | Kontoumsätze | src/centron/Centron.WPF.UI/Modules/OnlineBanking/AccountTransactions | Abruf und Zuordnung von Kontoumsätzen (Risikobereich) |
+| 80 | OnlineBanking | OnlineBanking-Konfiguration | src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings | Konfiguration der Bankverbindungen |
+| 81 | OnlineBanking | OnlineBanking-Verbindungsdialog | src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConnectionDialog | Verbindungsaufbau zu Banken (FinTS/HBCI) |
+| 82 | Querschnitt | KI-Unterstützung | src/centron/Centron.WPF.UI/Modules/ArtificialIntelligence | KI-gestützter Chat, Angebotspositions-Editor, Textbewertung (OpenAI-Anbindung) |
+| 83 | Querschnitt | Umfragen | src/centron/Centron.WPF.UI/Modules/Survey | Erstellung/Auswertung von Kundenumfragen |
+| 84 | Querschnitt | Massenänderungen | src/centron/Centron.WPF.UI/Modules/Massenupdates | Massenhaftes Aktualisieren von Datensätzen |
+| 85 | Querschnitt | Passwortverwaltung | src/centron/Centron.WPF.UI/Modules/PasswordManager | Sichere Ablage von Zugangsdaten (Risikobereich) |
+| 86 | Querschnitt | Kalender | src/centron/Centron.WPF.UI/Modules/Calendar | Terminverwaltung |
+| 87 | Querschnitt | Qualitätsmanagement | src/centron/Centron.WPF.UI/Modules/QM | QM-Prüfprozesse |
+| 88 | Querschnitt | Telekom-DIVE-Integration (UI) | src/centron/Centron.WPF.UI/Modules/TelekomDive | Anbindung an die Telekom-DIVE-Plattform |
+| 89 | Querschnitt | Startdashboard | src/centron/Centron.WPF.UI/Modules/Dashboard | Konfigurierbares Startbildschirm-Dashboard |
+| 90 | Querschnitt | Oberflächenprofile | src/centron/Centron.WPF.UI/Modules/Gui | Verwaltung von Layout-/Oberflächenprofilen je Benutzer |
+| 91 | Querschnitt | Cross-cutting Dialoge (Global) | src/centron/Centron.WPF.UI/Modules/Global | Wiederverwendbare Dialoge (Mitarbeiterauswahl, Videoportal, Netzwerkdiagnose, Lizenzabgleich) |
+| 92 | Backend-Kern | Geschäftslogik-/Datenzugriffsschicht | src/backend/Centron.BL, Centron.DAO, Centron.Entities, Centron.Interfaces, Centron.Common | Fachliche Kernlogik, Datenbankzugriff und Entitätsmodell, von allen UI-Modulen genutzt |
+| 93 | Backend-Kern | EDI-Lieferantenanbindungen | src/backend/Centron.Gateway/EDI_Also, EDI_AlsoCH, EDI_Alltron, EDI_Herweck, EDI_Komsa, EDI_EGIS | Elektronischer Datenaustausch (Bestellung/Lieferschein/Rechnung) mit Distributoren |
+| 94 | Backend-Kern | Banking-Gateway (Backend) | src/backend/Centron.Gateway/OnlineBanking | Technische Anbindung an Bankschnittstellen (FinTS) |
+| 95 | Backend-Kern | MSP-Collector-Gateway | src/backend/Centron.Gateway/MspCollector | Sammeln von Gerätedaten bei Managed-Service-Anbietern (Octopus, Wortmann) |
+| 96 | Backend-Kern | E-Rechnungsformate | src/backend/Centron.Gateway/OpenTrans, OpenTrans1_0, ZUGFeRD21_Extended | Erzeugen/Verarbeiten strukturierter Rechnungsformate |
+| 97 | Backend-Kern | Portal-Gateway | src/backend/Centron.Gateway/Portal | Anbindung an den c-entron Portal-Webservice |
+| 98 | Webservice | Zentrale Web-API | src/webservice/Centron.WebServices.Core, Centron.Controllers, Centron.Host, Host.Console, Host.WindowsService | Bereitstellung der c-entron-Funktionalität als Webservice/REST-Schnittstelle für externe/mobile Clients |
+| 99 | Webservice | Lizenz-/Verbindungsmanager | src/webservice/c-entron.misc.ConnectionManager | Verwaltung von Lizenzen/Hardware-IDs für Webservice-Verbindungen |
+| 100 | Nexus (Web) | ServiceBoard (Web-Ticketboard) | src/nexus/CentronNexus/ServiceBoard | Web-basierte Ticket-/Kanban-Oberfläche für den technischen Support |
+| 101 | Nexus (Web) | Nexus Office/Kundenportal (WebCart) | src/nexus/CentronNexus/Office | Web-Kundenportal inkl. Bestell-/Shopfunktion (WebCart) |
+| 102 | Nexus (Web) | Web-Fertigungsauftragsverwaltung | src/nexus/CentronNexus/ProductionOrderManagement | Weboberfläche zur Fertigungsauftragssteuerung |
+| 103 | Nexus (Web) | Nexus-Verwaltung | src/nexus/CentronNexus/Management | Verwaltung von Web-Benutzerkonten, Aufgaben und Ticketmustern |
+| 104 | Nexus (Web) | Dokumentensignatur (Web) | src/nexus/CentronNexus/DocumentSigning | Elektronische Signatur von Dokumenten im Web |
+| 105 | Nexus (Web) | Outlook-Add-in | src/nexus/CentronNexus.OutlookAddIn | Integration von c-entron-Funktionen in Microsoft Outlook |
+| 106 | Externe APIs | Produktdaten-Anreicherungs-APIs | src/apis/Centron.APIs.CopDataAccess, EgisDataAccess, ITscopeDataAccess, IcecatDataAccess | Abruf von Produktstamm-/Katalogdaten bei externen Datenlieferanten |
+| 107 | Externe APIs | Bankanbindung FinAPI | src/apis/Centron.APIs.FinAPI | Kontoinformationsabruf über den Drittanbieter FinAPI (Risikobereich) |
+| 108 | Externe APIs | E-Rechnung Österreich | src/apis/Centron.Api.EbInterface | Erstellung von ebInterface-E-Rechnungen (österreichischer Standard) |
+| 109 | Externe APIs | Versanddienstleister-Schnittstellen | src/apis/Centron.Api.Gls, Centron.Api.Shipcloud | Anbindung an Paketversanddienstleister (Label-/Sendungsdaten) |
+| 110 | Datenaustausch | PDF-Formulargenerierung (docuFORM) | Centron.Api.docuFORM, src/centron/.../Modules/DataExchange/DocuForm | Dynamische PDF-Formularerzeugung aus Belegdaten |
+| 111 | Datenaustausch | Datenimport (allgemein) | src/centron/Centron.WPF.UI/Modules/DataExchange/DataImport | Generischer Import von Fremddaten in c-entron |
+| 112 | Datenaustausch | Buchhaltungsexport | src/centron/Centron.WPF.UI/Modules/DataExchange/BookKeeping | Export von Buchungsdaten an Finanzbuchhaltungssysteme |
+| 113 | Datenaustausch | DATEV-Anbindung | src/centron/Centron.WPF.UI/Modules/DataExchange/DatevOnline2020 | Direkter Datenaustausch mit DATEV |
+| 114 | Datenaustausch | SEPA-Zahlungsverkehrsdatei | src/centron/Centron.WPF.UI/Modules/DataExchange/PaymentTransactions | Erzeugung von SEPA-Zahlungs-/Lastschriftdateien (Risikobereich) |
+| 115 | Datenaustausch | Telekom-DIVE-Datenaustausch | src/centron/Centron.WPF.UI/Modules/DataExchange/TelekomDive | Datenaustausch mit der Telekom-DIVE-Plattform |
+| 116 | Datenaustausch | Datenexport (allgemein) | src/centron/Centron.WPF.UI/Modules/DataExchange/DataExport | Genereller Export von c-entron-Daten |
+| 117 | Datenaustausch | Sonstige Schnittstellen | src/centron/Centron.WPF.UI/Modules/DataExchange/Connectors, DocSync, Rmm, SupplierOrderPerBranch | Weitere Konnektoren (Remote Monitoring, filialweise Lieferantenbestellung) |
+| 118 | Betrieb | Deployment & Betrieb | deployment/, docker/, azure/, azure-blazor/ | Build-, Container- und Pipeline-Konfiguration für Auslieferung und Betrieb |
+
+**118 Inventarzeilen.** Datenbankschema (`SSMS_DB_SCHEMA.sql`) ist kein eigenständiges Modul, sondern durchgängig als Belegquelle für Datenmodell/Constraints in den obigen Zeilen herangezogen.
+
+## Abdeckungstabelle
+
+Einstufung je Inventarzeile: **tief** (Anforderung auf mehreren Ebenen mit StRS→SyRS/SwRS-Kette und mindestens einem PRIMÄR-Beleg vertieft), **mittel** (genau eine Anforderung, aber mit PRIMÄR-Beleg), **flach** (genau eine Anforderung, nur SEKUNDÄR/KONTEXT-Belege), **nicht analysiert** (kein Beleg möglich). „Anzahl Anforderungen" zählt alle StRS/SyRS/SwRS-Anforderungen, die diesem Modul unmittelbar zugeordnet sind (bei modulübergreifend geteilten SyRS/SwRS – z. B. SwRS-5 für Opos/Payments oder SwRS-7/SyRS-10 für RightsManagement/Nexus – bei jedem beteiligten Modul mitgezählt).
+
+| Nr | Modul | Einstufung | Anzahl Anforderungen |
+|----|-------|------------|------------------------|
+| 1 | Sales – Sonderpreise/Mailing | tief | 3 (StRS-1, SyRS-2, SwRS-3) |
+| 2 | CRM/Adressstamm | tief | 3 (StRS-2, SyRS-1, SwRS-1) |
+| 3 | Kampagnenmanagement | tief | 2 (StRS-3, SwRS-2 [HYPOTHESE]) |
+| 4 | CRM-Stammdatenlisten | flach | 1 |
+| 5 | Vertragsverwaltung & -auswertung | flach | 1 |
+| 6 | Projektverwaltung (Finanzsicht) | flach | 1 |
+| 7 | Zählerstandserfassung (MPS) | mittel | 1 |
+| 8 | Produktlebenszyklus-Management | flach | 1 |
+| 9 | Zahler-/Kostenstellenverwaltung | mittel | 1 |
+| 10 | Projektpreisimport | flach | 1 |
+| 11 | Projektmanagement (allgemein) | flach | 1 |
+| 12 | Belegbearbeitung Kern | tief | 2 (StRS-12, SyRS-5 [HYPOTHESE]) |
+| 13 | Anzahlungen | tief | 2 (StRS-13, SyRS-3) |
+| 14 | Steuersatzänderung im Beleg | tief | 2 (StRS-14, SwRS-4) |
+| 15 | Provisionsermittlung | mittel | 1 |
+| 16 | Web-Angebote | flach | 1 |
+| 17 | EDI-Auftragsverbuchung | flach | 1 |
+| 18 | Automatisierte Rechnungserstellung | mittel | 1 |
+| 19 | Pauschalabrechnung (Flatrate) | flach | 1 [HYPOTHESE] |
+| 20 | Zeit-/Leistungsabrechnung (Timer) | flach | 1 [HYPOTHESE] |
+| 21 | Mahnwesen | tief | 2 (StRS-21, SyRS-4) |
+| 22 | Offene Posten | tief | 2 (StRS-22, SwRS-5) |
+| 23 | Zahlungsverkehr (Payments) | tief | 2 (StRS-23, SwRS-5 geteilt) |
+| 24 | Kontenverwaltung (Buchhaltung) | flach | 1 |
+| 25 | Warenausgangszahlungen | flach | 1 |
+| 26 | Kassensystem-Anbindung | mittel | 1 |
+| 27 | Artikelstammdaten | flach | 1 |
+| 28 | Artikelimport | flach | 1 |
+| 29 | Mengeneinheitenverwaltung | mittel | 1 |
+| 30 | Barcode-Verwaltung | flach | 1 |
+| 31 | Kommissionierung | flach | 1 |
+| 32 | Kommissionsware/Konsignation | flach | 1 |
+| 33 | Inventur | flach | 1 |
+| 34 | Warengruppenverwaltung | mittel | 1 |
+| 35 | Artikelsuche | flach | 1 |
+| 36 | Lieferantensuche | flach | 1 |
+| 37 | Logistikeinstellungen/Versandarten | flach | 1 |
+| 38 | EDI-Bestellwesen | flach | 1 |
+| 39 | Bestellvorschlagsliste | flach | 1 |
+| 40 | Einkaufseinstellungen | flach | 1 |
+| 41 | Reisekostenabrechnung | mittel | 1 |
+| 42 | Fertigungsauftragsverwaltung | flach | 1 |
+| 43 | Maschinenverwaltung | flach | 1 |
+| 44 | RMA-Abwicklung | mittel | 1 |
+| 45 | Ticketverwaltung | flach | 1 |
+| 46 | Helpdesk-Dashboard | flach | 1 |
+| 47 | Wartungsverträge/erwartete Ereignisse | mittel | 1 |
+| 48 | Helpdesk-Einstellungen | flach | 1 |
+| 49 | Helpdesk Sonstiges | flach | 1 |
+| 50 | CentronInspectors | mittel | 1 |
+| 51 | Persönliche Einstellungen (Access-Token) | tief | 3 (StRS-51, SyRS-6, SyRS-7) |
+| 52 | Mein Tag (MyDay) | flach | 1 |
+| 53 | MyCentron-Dashboard | flach | 1 |
+| 54 | Aufgabenliste (ToDo) | flach | 1 |
+| 55 | Telefonie-Integration | flach | 1 |
+| 56 | Fernwartungsintegration (Supremo) | flach | 1 |
+| 57 | Verkaufsstatistik | flach | 1 |
+| 58 | Management-Informationen | flach | 1 |
+| 59 | MSP-Statistiken | flach | 1 |
+| 60 | Mitarbeiteranalyse | flach | 1 |
+| 61 | Reportverwaltung | flach | 1 |
+| 62 | Rechteverwaltung | tief | 5 (StRS-62, SyRS-8 [HYPOTHESE-Anteil], SyRS-9, SyRS-10, SwRS-6, SwRS-7) |
+| 63 | Mitarbeiterverwaltung | flach | 1 |
+| 64 | Mandantenverwaltung | flach | 1 |
+| 65 | DSGVO-Funktionen | mittel | 1 |
+| 66 | Systemeinstellungen | flach | 1 |
+| 67 | Verbindungs-/Schnittstelleneinstellungen | flach | 1 |
+| 68 | Kommunikationseinstellungen | flach | 1 |
+| 69 | Belegwesen-Konfiguration | flach | 1 |
+| 70 | Stundensätze/Zuschläge | flach | 1 |
+| 71 | Eskalationseinstellungen | flach | 1 |
+| 72 | Länderverwaltung | flach | 1 |
+| 73 | Service-/Leasing-/SEPA-Verträge | mittel | 1 |
+| 74 | Externe Werkzeuge | flach | 1 |
+| 75 | WebCart-Konfiguration | flach | 1 |
+| 76 | Sonstige Prozesseinstellungen | flach | 1 |
+| 77 | Log-Betrachter | flach | 1 |
+| 78 | Dienste-Verwaltung | flach | 1 |
+| 79 | Kontoumsätze | flach | 1 |
+| 80 | OnlineBanking-Konfiguration | flach | 1 |
+| 81 | OnlineBanking-Verbindungsdialog | flach | 1 |
+| 82 | KI-Unterstützung | flach | 1 |
+| 83 | Umfragen | flach | 1 |
+| 84 | Massenänderungen | flach | 1 |
+| 85 | Passwortverwaltung | tief | 2 (StRS-85, SwRS-8) |
+| 86 | Kalender | flach | 1 |
+| 87 | Qualitätsmanagement | flach | 1 |
+| 88 | Telekom-DIVE-Integration (UI) | flach | 1 |
+| 89 | Startdashboard | flach | 1 |
+| 90 | Oberflächenprofile | flach | 1 |
+| 91 | Cross-cutting Dialoge (Global) | flach | 1 |
+| 92 | Geschäftslogik-/Datenzugriffsschicht | flach | 1 |
+| 93 | EDI-Lieferantenanbindungen | mittel | 1 |
+| 94 | Banking-Gateway (Backend) | flach | 1 |
+| 95 | MSP-Collector-Gateway | flach | 1 |
+| 96 | E-Rechnungsformate | mittel | 1 |
+| 97 | Portal-Gateway | flach | 1 |
+| 98 | Zentrale Web-API | tief | 2 (StRS-98, SyRS-10 geteilt) |
+| 99 | Lizenz-/Verbindungsmanager | flach | 1 |
+| 100 | ServiceBoard (Web-Ticketboard) | flach | 1 |
+| 101 | Nexus Office/Kundenportal (WebCart) | tief | 2 (StRS-101, SwRS-7 geteilt) |
+| 102 | Web-Fertigungsauftragsverwaltung | flach | 1 |
+| 103 | Nexus-Verwaltung | mittel | 1 |
+| 104 | Dokumentensignatur (Web) | flach | 1 [HYPOTHESE] |
+| 105 | Outlook-Add-in | flach | 1 |
+| 106 | Produktdaten-Anreicherungs-APIs | flach | 1 |
+| 107 | Bankanbindung FinAPI | flach | 1 |
+| 108 | E-Rechnung Österreich | flach | 1 |
+| 109 | Versanddienstleister-Schnittstellen | flach | 1 |
+| 110 | PDF-Formulargenerierung (docuFORM) | flach | 1 |
+| 111 | Datenimport (allgemein) | flach | 1 |
+| 112 | Buchhaltungsexport | flach | 1 |
+| 113 | DATEV-Anbindung | flach | 1 |
+| 114 | SEPA-Zahlungsverkehrsdatei | mittel | 1 |
+| 115 | Telekom-DIVE-Datenaustausch | flach | 1 |
+| 116 | Datenexport (allgemein) | flach | 1 |
+| 117 | Sonstige Schnittstellen | flach | 1 |
+| 118 | Deployment & Betrieb | mittel | 1 |
+
+**Summe:** 118 Module, 0 „nicht analysiert" (Mindestabdeckung zu 100 % erreicht) · 14 tief · 18 mittel · 86 flach. Gesamtanzahl Anforderungen: **136** (118 StRS + 10 SyRS + 8 SwRS).
+
+## Konsistenzcheck
+
+- **Doppelte/mehrfach vergebene IDs:** Keine gefunden. StRS-1 bis StRS-118 sind lückenlos und eindeutig vergeben (verifiziert per Durchsuchung aller `ID:`-Zeilen in StRS.md). SyRS-1 bis SyRS-10 und SwRS-1 bis SwRS-8 sind ebenfalls eindeutig; SyRS-10 steht aus editortechnischen Gründen physisch vor SyRS-8/SyRS-9 in der Datei (Einfügereihenfolge), was die Eindeutigkeit der IDs nicht beeinträchtigt, aber beim manuellen Lesen auffällt.
+- **Anforderungen ohne Beleg:** Keine gefunden. Jede der 136 Anforderungen enthält mindestens einen Eintrag unter `Belege:` (automatisiert gegengeprüft: 118 `Belege:`-Vorkommen in StRS.md stehen exakt 118 `ID:`-Vorkommen gegenüber, keine leere Belege-Sektion).
+- **Anforderungen ohne Angabe zur Übernahmewürdigkeit:** Keine gefunden (automatisiert gegengeprüft, jede `Übernahmewürdigkeit:`-Zeile ist gefüllt).
+- **Tracelinks auf nicht existierende IDs:** Keine gefunden. Alle in `Tracelinks:`-Feldern referenzierten IDs (siehe `Traceability.md`) liegen innerhalb der belegten Bereiche StRS-1..118, SyRS-1..10, SwRS-1..8.
+- **Inhaltlich deckungsgleiche Anforderungen ohne Konsolidierungsvermerk:** Bei der Erstellung wurden 23 Konsolidierungskandidaten aktiv identifiziert und im Feld `Konsolidierung` vermerkt (u. a. StRS-4/StRS-7 Zählerstandserfassung doppelt, StRS-32 Kommissionsware vs. Provision-Namensverwechslung, StRS-62/StRS-103 getrennte Rechtemodelle intern/Web, StRS-65/StRS-73 DSGVO-AVV/SEPA nahezu identischer Signatur-Workflow, StRS-93 sechsfache EDI-Implementierung, StRS-106 vierfache Produktdaten-API, StRS-96/StRS-108 dreifaches E-Rechnungsformat). Ein manueller Nachvergleich der übrigen 95 flach/mittel eingestuften Anforderungen auf **nicht erkannte** Deckungsgleichheit wurde aus Zeitgründen nicht durchgeführt; hierin liegt ein Restrisiko (siehe Selbstbewertung).
+- **Korrektur während der Erhebung:** Zwei Inventar-Fehleinschätzungen aus Schritt 0 wurden während der Erhebung selbst korrigiert, statt sie unkommentiert zu übernehmen: Zeile 15 (Provision) enthielt ursprünglich fälschlich den Pfad „PartialCommission", der tatsächlich zu Kommissionsware (Zeile 32) gehört; Zeile 50 (CentronInspectors) war ursprünglich fälschlich als Prüfmittelverwaltung statt als Dateninspektions-Framework beschrieben. Beide Korrekturen sind im Modulinventar oben nachvollziehbar vermerkt.
+- **Nachträglich behobene Regelverstöße (Belegpflicht bei Risikoanforderungen):** Bei der Selbstprüfung wurden drei Anforderungen mit Typ „Sicherheit" bzw. Fakturierungsbezug gefunden, die ursprünglich als `belegt` ohne PRIMÄR-Beleg geführt waren (StRS-19 Pauschalabrechnung, StRS-20 Zeitabrechnung, StRS-104 Web-Dokumentensignatur). Alle drei wurden korrigiert und tragen jetzt `Status: HYPOTHESE` mit expliziter Begründung; sie sind in `Hypothesen.md` nachgeführt.
+
+### Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung, Berechtigungen)
+
+| ID | Titel | PRIMÄR-Beleg vorhanden? | Status |
+|----|-------|--------------------------|--------|
+| StRS-62 | Gruppenbasierte Rechtevergabe | Ja | belegt |
+| SyRS-8 | Serverseitige Rechteprüfung mit Cache | Ja (für Prüfung selbst), Cache-Invalidierung unbelegt | HYPOTHESE |
+| SyRS-9 | Admin-Gruppen-Schutz | Ja | belegt |
+| SwRS-6 | Sichtrus/Sichmemb-Datenmodell | Ja | belegt |
+| SwRS-7 | Getrennte Web-Rechte | Ja | belegt |
+| StRS-98 | Web-API duale Authentifizierung | Ja | belegt |
+| SyRS-10 | Duale API-Authentifizierung | Ja | belegt |
+| StRS-51 | Personal-Access-Token | Ja | belegt |
+| SyRS-6 | Pflicht-Ablaufdatum Token | Ja | belegt |
+| SyRS-7 | Serverseitige Ablaufprüfung Token | Ja | belegt |
+| StRS-85 | Passwortverwaltung AES-Verschlüsselung | Ja | belegt |
+| SwRS-8 | AES-Verschlüsselung Master-Key | Ja | belegt |
+| StRS-65 | DSGVO/AVV/Löschrechte | Ja | belegt |
+| StRS-104 | Web-Dokumentensignatur | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
+| SwRS-2 | Rechteabhängige Kampagnenfunktionen | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
+| SyRS-5 | Nebenläufigkeitsschutz Belege | Nein (nur SEKUNDÄR/Feldexistenz) | **HYPOTHESE** |
+| StRS-13 | Anzahlung → Schlussrechnung | Ja | belegt |
+| StRS-14 | Steuersatzänderung | Ja | belegt |
+| StRS-15 | Provisionsermittlung (Überschreibschutz) | Ja | belegt |
+| StRS-18 | Automatisierte Rechnungserstellung | Ja | belegt |
+| StRS-19 | Pauschalabrechnung | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
+| StRS-20 | Zeit-/Leistungsabrechnung | Nein (nur SEKUNDÄR) | **HYPOTHESE** |
+| StRS-21 | Mahnwesen (Mahnstopp) | Ja | belegt |
+| SyRS-4 | Mahnfähigkeit serverseitig | Ja | belegt |
+| StRS-22 | Offene Posten (OpenPrice-Formel) | Ja | belegt |
+| StRS-23 | Zahlungserfassung | Ja | belegt |
+| StRS-26 | Kassensystem-Steuerkonten | Ja | belegt |
+| StRS-73 | SEPA-Mandate (Signatur-Workflow) | Ja | belegt |
+| StRS-114 | SEPA-Zahlungsdatei (pain.008) | Ja | belegt |
+
+**Ergebnis:** 29 risikorelevante Anforderungen identifiziert. Davon tragen 23 (79 %) einen PRIMÄR-Beleg und sind `belegt`; 6 (21 %) sind korrekt als `[HYPOTHESE]` gekennzeichnet (SyRS-8 mit Einschränkung: die Rechteprüfung selbst ist PRIMÄR belegt, die zusätzliche Aussage zur Cache-Invalidierung nicht, daher in Summe HYPOTHESE). Keine risikorelevante Anforderung ist ohne PRIMÄR-Beleg als `belegt` geführt (nach den oben dokumentierten Korrekturen).
+
+### Abgleich Hypothesen.md gegen Inline-Markierungen
+
+Automatisiert geprüft: `Hypothesen.md` führt genau die 6 Anforderungen, die in StRS.md/SyRS.md/SwRS.md mit `Status: HYPOTHESE` markiert sind (SyRS-5, SyRS-8, SwRS-2, StRS-19, StRS-20, StRS-104) – keine zusätzliche, keine fehlende. Offene Punkte ohne unmittelbaren Anforderungsbezug (z. B. generelle Unsicherheit über Cache-Ablaufzeiten) stehen ausschließlich in der Selbstbewertung unten, nicht in `Hypothesen.md`.
+
+## Selbstbewertung
+
+**Tiefenverteilung:** Von 118 Inventarmodulen wurden 14 **tief** (mehrstufige StRS→SyRS/SwRS-Kette, überwiegend mit PRIMÄR-Beleg), 18 **mittel** (eine Anforderung mit PRIMÄR-Beleg) und 86 **flach** (eine Anforderung mit SEKUNDÄR-/KONTEXT-Beleg) analysiert. **0 Module sind „nicht analysiert"** – die in Schritt 0b geforderte Mindestabdeckung (mindestens eine Anforderung je Modul) wurde für alle 118 Module erreicht.
+
+**Mindestabdeckung erreicht:** Ja, vollständig. Jedes Modul aus dem Inventar (Schritt 0) trägt mindestens eine Anforderung mit mindestens einem Beleg.
+
+**Wo war der Beleg dünn:** Die 86 „flach" eingestuften Module stützen sich überwiegend auf SEKUNDÄR-/KONTEXT-Belege (Klassenexistenz, Ordnerstruktur, Namensgebung) statt auf durchsetzende Stellen (PRIMÄR). Das ist in dieser Breitenphase eine bewusste, im Auftrag so vorgesehene Priorisierung („Breite geht vor Tiefe") und kein Zufallsergebnis: Für alle Module mit Bezug zu Sicherheit, Abrechnung/Fakturierung oder Berechtigungen wurde gezielt nach PRIMÄR-Belegen gesucht (siehe Risikoliste oben, 79 % PRIMÄR-Quote), während bei fachlich unkritischeren Modulen (z. B. Kalender, Umfragen, Log-Betrachter, Startdashboard) die Existenzbestätigung über Klassenstruktur als für die Mindestabdeckung ausreichend erachtet wurde. Am dünnsten belegt sind die rein technischen Querschnittsmodule (92 Geschäftslogikschicht, 97 Portal-Gateway, 99 Lizenzmanager) sowie mehrere Nexus-Teilbereiche (100, 102, 105), da hier aus Zeitgründen jeweils nur eine repräsentative Klasse gesichtet wurde, obwohl die zugrundeliegenden Projekte (z. B. Centron.BL mit 2.068 Dateien) erheblich umfangreicher sind.
+
+**Warum die Hypothesenzahl (6 von 136, 4,4 %) vergleichsweise niedrig ausfällt:** In der Breitenphase (Schritt 0b) wurden Aussagen bewusst eng an das tatsächlich Beobachtete formuliert – „Klasse X belegt Funktion Y" statt „System garantiert Y" –, sodass für die meisten Anforderungen SEKUNDÄR-/KONTEXT-Belege ausreichten, ohne dass eine unbelegte, risikorelevante Aussage entstand, die zwingend `[HYPOTHESE]` erfordert hätte. Die vorhandenen 6 Hypothesen entstanden ausnahmslos dort, wo in der gezielten Risikovertiefung (Schritt 0c) oder bei der abschließenden Selbstprüfung eine serverseitige Durchsetzungsstelle gesucht, aber nicht gefunden wurde (Cache-Invalidierung bei Rechteänderung, Konfliktbehandlung bei Nebenläufigkeit, Kampagnen-Rechteprüfung, Pauschal-/Zeitabrechnungsformel, Web-Signatur-Versiegelung). Eine Vertiefung der 86 „flach" eingestuften Module würde nach bisherigem Muster voraussichtlich weitere Hypothesen zutage fördern, insbesondere überall dort, wo bislang nur eine ViewModel-Klasse, nicht aber die zugehörige BL-Methode gesichtet wurde.
+
+**Erkenntnisse für eine Folge-Iteration:**
+1. **MandatorManagement/Mandantentrennung (Modul 64) vertiefen.** Bislang nur strukturell (Firmendaten, Filialen) belegt; die eigentliche Sicherheitsfrage – wie wird verhindert, dass ein Mandant Daten eines anderen Mandanten sieht (Datenbank-Filterung nach MandatorI3D, Zeilenebene vs. Anwendungsebene) – wurde nicht geprüft und ist für ein SaaS-Zielsystem mit gemeinsamer Infrastruktur mehrerer Mandanten sicherheitskritisch.
+2. **TimerBilling/FlatrateBilling-Berechnungslogik lokalisieren** (StRS-19/20, aktuell HYPOTHESE) – vermutlich in `Centron.BL/Sales/CustomerAssets/TimerBilling` oder einer noch nicht gesichteten Nachbarklasse.
+3. **Web-Dokumentensignatur-Versiegelung (StRS-104) und Rechte-Cache-Invalidierung (SyRS-8) klären** – beide sicherheitsrelevant und aktuell HYPOTHESE.
+4. **Konsolidierungskandidaten priorisieren und quantifizieren:** Die 23 gefundenen Fälle (siehe oben) sollten in einer Folge-Iteration mit Aufwandsschätzung für die Zusammenführung versehen werden, beginnend bei den am klarsten belegten Fällen (SEPA/DSGVO-Signatur-Workflow, sechsfache EDI-Anbindung, vierfache Produktdaten-API).
+5. **86 „flach" eingestufte Module gezielt auf SwRS-Ebene ergänzen**, insbesondere die datenintensiven Kernmodule Warehousing/ArticleManagement (320 Dateien, aber nur 1 Anforderung) und Finances/Receipts-Kern (794 Dateien, nur StRS-12), deren Umfang die aktuelle Abdeckungstiefe deutlich übersteigt.
+6. **Manueller Deckungsgleichheits-Check der 95 nicht aktiv auf Konsolidierung geprüften Anforderungen** (siehe Konsistenzcheck), da bei einer Codebasis dieser Größe weitere, bislang unentdeckte Dopplungen wahrscheinlich sind.
@@ -0,0 +1,32 @@
+# Glossar
+
+Domänenbegriffe, wie sie in den Anforderungen verwendet werden. Technische Bezeichner (Klassen/Methoden/Spalten) bleiben in Originalsprache.
+
+| Begriff | Bedeutung im Kontext c-entron |
+|---------|-------------------------------|
+| Beleg / Belegkette | Sammelbegriff für Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Bestellung; technisch getrennte Kopftabellen (`AngKopf`, `AufKopf`, `LiefKopf`, `RechKopf`, `GutKopf`, `BestKopf`), fachlich eine zusammenhängende Verarbeitungskette (siehe StRS-12). |
+| Anzahlung / Anzahlungsrechnung | Vor der Schlussrechnung gestellte Teilrechnung zu einem Auftrag; wird bei Erstellung der Schlussrechnung vom Gesamtbetrag abgezogen (StRS-13). |
+| Sonderpreis (Special Price) | Kunden- bzw. kundenklassenspezifischer, vom Listenpreis abweichender Artikelpreis mit Gültigkeitszeitraum (`AccountSpecialPriceDTO`); Grundlage sowohl für die klassische Vertriebspreisfindung (StRS-1) als auch für den WebCart-Shop (StRS-75). |
+| Kontingent | Im Vertrag hinterlegte Mengenobergrenze für eine Leistung/einen Artikel, gegen die der tatsächliche Verbrauch aus Belegen gegengerechnet wird (StRS-5). |
+| Kommissionsware / Konsignation | Ware, die einem Kunden zur Ansicht/zum Verbrauch überlassen wird, ohne dass zum Übergabezeitpunkt bereits eine Rechnung gestellt wird; Abrechnung erfolgt erst bei tatsächlichem Verbrauch/Verkauf (Modul „Warehousing/Commissions", StRS-32). Nicht zu verwechseln mit „Provision" (siehe dort). |
+| Provision | Verkäuferbezogene Vergütung auf Basis abgeschlossener Belege, gesteuert über Provisionsschemata (Modul „Finances/Receipts/Provision", StRS-15). Im Quellcode weckt der Ordnername „PartialCommission" (Finances/Receipts) durch die englische Doppelbedeutung von „Commission" Verwechslungsgefahr mit „Kommissionsware" – „PartialCommission" gehört fachlich zu Letzterem (siehe Korrekturhinweis in Analysebericht.md, Zeile 15 des Inventars). |
+| Offene Posten (Opos) | Noch nicht vollständig ausgeglichene Rechnungsbeträge; `OpenPrice` wird zentral aus Bruttobetrag (bzw. Nettobetrag bei nicht ausweisbarer USt.), bereits gezahltem Betrag und Währungsfaktor berechnet (StRS-22). |
+| Mahnstopp / Mahnstufe | Am Rechnungskopf geführtes Flag (`MahnStop`) bzw. Zähler (`Mahnstufe`), das eine Rechnung zeitweise oder dauerhaft vom automatisierten Mahnlauf ausschließt bzw. deren Mahnfortschritt dokumentiert (StRS-21). |
+| Zahler / Kostenstelle / Kostenobjekt | Vom Rechnungsempfänger abweichende Instanz, die einen Beleg wirtschaftlich trägt (Zahler), bzw. interne Verrechnungseinheiten für Kosten (Kostenstelle/-objekt) (StRS-9). |
+| AVV (Auftragsverarbeitungsvertrag) | Datenschutzrechtlich (Art. 28 DSGVO) erforderlicher Vertrag mit Auftragsverarbeitern; im System als digitaler Signatur-Workflow mit Vorlagen abgebildet (StRS-65), strukturell nahezu identisch mit dem SEPA-Mandats-Workflow (StRS-73). |
+| Recht / Rechtegruppe (Sichtrus/Sichmemb) | Internes RBAC-Modell: Rechte (`AppRight`) werden ausschließlich Gruppen (`AppGroup`) zugewiesen (Tabelle `Sichtrus`), Benutzer werden Gruppen zugeordnet (Tabelle `Sichmemb`); ein Benutzer besitzt die Vereinigungsmenge der Rechte all seiner Gruppen (StRS-62). Getrennt davon existiert ein strukturell ähnliches, aber eigenständiges Rechtemodell für Web-Accounts (`WebRights`). |
+| Web-Account | Eigenständiges Login für externe Personen (Kunden, Web-Shop-Nutzer), technisch getrennt vom internen Mitarbeiter-Login (`AppUser`) samt eigenem Rechtemodell (siehe „Recht"). |
+| I3D | Durchgängige Namenskonvention für den Primärschlüssel/die eindeutige ID einer Entität in c-entron (z. B. `accountI3D`, `articleI3D`); technischer Bezeichner, bleibt in Originalform. |
+| Stammblatt | Im Altbestand verwendete Bezeichnung für ein verwaltetes Gerät (z. B. Drucker) mit Zählerstandshistorie; fachlich Teil des in dieser Analyse dokumentierten Gerätelebenszyklus (PLM, DeviceClickCounter). |
+| RMA | Return Merchandise Authorization – Rücksendeprozess für reklamierte/defekte Ware (StRS-44). |
+| PLM | Product Lifecycle Management – Verwaltung von Produktfamilien und deren Lebenszyklusphasen, hier zusätzlich auf einzelne ausgelieferte Geräte angewendet (StRS-8). |
+| MSP | Managed Service Provider – Geschäftsmodell, bei dem c-entron-Kunden IT-Dienstleistungen für ihre eigenen Endkunden erbringen; das System sammelt hierzu Gerätedaten externer MSP-Plattformen (StRS-59, StRS-95). |
+| EDI | Electronic Data Interchange – strukturierter elektronischer Geschäftsdatenaustausch (Bestellung, Lieferschein, Rechnung) mit Distributoren (StRS-38, StRS-93). |
+| ZUGFeRD / openTRANS / ebInterface | Strukturierte E-Rechnungsformate; ZUGFeRD (hybrides PDF+XML, Standard „CrossIndustryInvoice"), openTRANS (älterer XML-Standard), ebInterface (österreichischer E-Rechnungsstandard) – im System parallel implementiert (StRS-96, StRS-108). |
+| SEPA (pain.008) | Single Euro Payments Area – einheitlicher europäischer Zahlungsverkehrsraum; `pain.008` ist der ISO-20022-Nachrichtentyp für SEPA-Lastschriften (StRS-114). |
+| DATEV | Weit verbreitete deutsche Software/Datenaustauschformat für Steuerberater und Finanzbuchhaltung (StRS-113). |
+| FinTS/HBCI | Standardisiertes deutsches Online-Banking-Protokoll für den automatisierten Kontoabruf (StRS-79, StRS-94). |
+| Belegwesen / Fakturierung | Sammelbegriff für die Erstellung und Verwaltung kaufmännischer Belege (Angebot bis Rechnung) bzw. speziell den Rechnungsstellungsprozess. |
+| AccountType | Fachliche Rollenzuweisung eines Adressstamm-Datensatzes (`Account`), z. B. „Customer" (Kunde), „Supplier" (Lieferant); ein Account kann mehrere AccountTypes gleichzeitig besitzen (StRS-2). |
+| Mandant / Filiale | Mandant = rechtlich eigenständige Unternehmenseinheit im Mehrmandantenbetrieb; Filiale = organisatorische Untereinheit eines Mandanten mit eigenem Belegnummernkreis (StRS-64). |
+
@@ -0,0 +1,15 @@
+# Hypothesen
+
+Sammlung aller mit `[HYPOTHESE]` markierten Anforderungen. Diese Liste ist deckungsgleich mit den Inline-Markierungen in StRS/SyRS/SwRS (keine zusätzlichen freien Fragen ohne zugehörige Anforderung – offene Punkte ohne Anforderungsbezug stehen in der Selbstbewertung in `Analysebericht.md`).
+
+| ID | Titel | Offene Frage / fehlende Information zur Bestätigung |
+|----|-------|-------------------------------------------------------|
+| SyRS-5 | Nebenläufige Bearbeitung von Belegen durch Sperr- und Versionskennung absichern | `RechKopf` führt `LockUser` und die GUID-Spalte `GUI3D`; belegt ist damit nur die Existenz der Felder. Nicht lokalisiert wurde die Schreibstelle, die beim Speichern eines Belegs die aktuelle mit der beim Laden gelesenen GUID/dem LockUser vergleicht und bei Abweichung den Speichervorgang abweist. Zur Bestätigung fehlt: die konkrete Save-Methode in Centron.BL/Centron.DAO für Belegköpfe (z. B. `RechKopfBL.Save`) mit ihrer Konfliktprüfung. |
+| SyRS-8 | Serverseitige Rechteprüfung mit benutzerbezogenem Cache | `AppRightsBL.HasUserRight()` cacht Rechte je Benutzer unter dem Schlüssel `AllRightsFromAppUser{appUserI3D}`. Nicht lokalisiert wurde ein Aufruf, der diesen Cache-Eintrag gezielt invalidiert, wenn sich die Gruppenzuordnung eines Benutzers oder die Rechte einer Gruppe ändern (z. B. in `SaveAndAssignGroupToRight`/`RemoveAssignGroupToRight`). Zur Bestätigung fehlt: Einsicht in die Cache-Implementierung (`Session.Advanced.Cache`) und deren Ablaufzeit/Invalidierungsstrategie. |
+| SwRS-2 | Rechteabhängige Freigabe von Kampagnenfunktionen | `CampaignMainViewModel` führt die Felder `UserCanEditCampaign`/`UserCanOpenCampaign`, die vermutlich aus einer Rechteprüfung stammen. Nicht lokalisiert wurde die serverseitige Stelle, die diese Flags setzt bzw. die bei einem direkten Service-Aufruf (unter Umgehung der UI) das Bearbeiten/Öffnen einer Kampagne ohne Recht tatsächlich verhindert. Zur Bestätigung fehlt: die Backend-Methode, die beim Speichern/Öffnen einer Kampagne das zugehörige Recht prüft (analog zu `AppRightsBL.HasUserRight`). |
+| StRS-19 | Pauschale Projektleistungen abrechnen | Die Existenz eines eigenständigen Pauschalabrechnungs-Moduls (`FlatRateProjectAppModuleController`) ist belegt, nicht aber die BL-seitige Berechnungsstelle, die den Pauschalbetrag unabhängig von erfassten Stunden in die Rechnung übernimmt. Da es sich um Fakturierungslogik handelt, ist ohne PRIMÄR-Beleg zwingend `[HYPOTHESE]` zu setzen. Zur Bestätigung fehlt: die Business-Logic-Klasse, die die Rechnungsposition aus dem Pauschalpreis erzeugt. |
+| StRS-20 | Erfasste Zeiten/Leistungen verrechnen | `TimerBillingViewModel` und `TimerBillingBL.cs` existieren; die konkrete Formel (Stundensatz × erfasste Dauer, inkl. Zuschlägen aus StRS-70) wurde in `TimerBillingBL.cs` nicht lokalisiert. Zur Bestätigung fehlt: die Berechnungsmethode in `TimerBillingBL` bzw. der aufgerufenen Rechnungspositions-Erzeugung. |
+| StRS-104 | Elektronische Dokumentensignatur im Web mit Signaturstil-Auswahl | Belegt ist nur die Auswahl von Signaturstil/-farbe (`SignatureType` u. a.). Nicht lokalisiert wurde die Stelle, die die Signatur manipulationssicher/rechtsverbindlich in das Dokument einbettet. Zur Bestätigung fehlt: die serverseitige Signatur-Versiegelungslogik in `CentronNexus/DocumentSigning`, ggf. mit Bezug zu `PdfSigningBL` (StRS-69). |
+
+**Hinweis zur Menge:** Bei einer Codebasis dieser Größe (>15.000 Dateien) mit vollständiger Modulabdeckung, aber notwendig selektiver Vertiefung (Schritt 0c), ist eine Hypothesenzahl von 6 (von 136 Anforderungen, 4,4 %) zunächst niedrig. Der Grund: In der Breitenphase (Schritt 0b) wurden Aussagen bewusst eng an das tatsächlich Beobachtete formuliert (z. B. „Klasse belegt X" statt „System garantiert X"), sodass für die meisten Anforderungen SEKUNDÄR-/KONTEXT-Belege ausreichten, ohne dass eine unbelegte, risikorelevante Aussage entstand, die eine `[HYPOTHESE]`-Kennzeichnung erzwungen hätte. Echte Hypothesen entstanden dort, wo in der Vertiefungsphase (Schritt 0c) eine serverseitige Durchsetzungsstelle gezielt gesucht, aber nicht gefunden wurde. Weitere, tiefer liegende Hypothesen sind bei einer Vertiefung der in der Selbstbewertung (`Analysebericht.md`) genannten Module wahrscheinlich (insbesondere MandatorManagement/Mandantentrennung, EmployeeManagement-Rechtezuordnung, ServiceAndLeasing).
+
@@ -0,0 +1,166 @@
+# Software Requirements Specification (SwRS) – c-entron ERP-Suite
+
+Nach ISO/IEC/IEEE 29148:2018. Komponenten, Datenmodelle, software-interne Regeln. IDs: `SwRS-<n>`, laufend über alle Module.
+
+---
+
+```
+ID:            SwRS-1
+Titel:         CanAccept()-Gate für den Kundenanlage-Dialog
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Komponente MakeCustomerViewModel
+Vorbedingung:  Dialog "Kundendaten eingeben" ist geöffnet
+Fakt:          CanAccept() (Z. 244-293) ist als Predicate von DelegateCommand AcceptCommand (Z. 210) verdrahtet; DevExpress.Mvvm.DelegateCommand ruft CanAccept() bei jeder Eigenschaftsänderung erneut auf und (de-)aktiviert den zugehörigen Button
+Aussage:       Die Komponente MakeCustomerViewModel soll den Speicherbefehl des Kundenanlage-Dialogs an das Prädikat CanAccept() binden, sodass der Button automatisch reagiert, ohne dass der Anwender manuell eine Prüfung anstoßen muss.
+Ergebnis:      Schaltfläche "Übernehmen" ist genau dann aktiv, wenn CanAccept() true liefert
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/MakeCustomerViewModel.cs, Zeile 210 (AcceptCommand = new DelegateCommand(this.Accept, this.CanAccept)) - Begründung: Verdrahtung von Commandausführung und Prüfprädikat an der durchsetzenden Stelle
+Prüfidee:      Unit-Test, der CanAccept() mit einer Kombination gesetzter/nicht gesetzter Pflichtfelder aufruft und den erwarteten bool-Rückgabewert prüft
+Tracelinks:    SyRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Command/CanExecute-Bindung ist Standardmuster und im Zielsystem als deklarative Validierung abzubilden
+Status:        belegt
+```
+
+```
+ID:            SwRS-2
+Titel:         Rechteabhängige Freigabe von Kampagnenfunktionen
+Ebene:         SwRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Komponente CampaignMainViewModel
+Vorbedingung:  Kampagnenübersicht ist geladen
+Fakt:          Felder UserCanEditCampaign und UserCanOpenCampaign (Z. 37, 40) steuern laut Namensgebung und Verwendung im ViewModel die Aktivierung von Bearbeiten-/Öffnen-Funktionen; die Herkunft der Werte (Rechteservice) wurde im Rahmen dieser Analyse nicht bis zur prüfenden Stelle zurückverfolgt
+Aussage:       Die Komponente CampaignMainViewModel soll Bearbeiten- und Öffnen-Funktionen für Kampagnen abhängig von vorab ermittelten Berechtigungsflags freigeben oder sperren.
+Ergebnis:      UI-Funktionen sind entsprechend der Berechtigungsflags aktiv/inaktiv
+Belege:
+  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/Finances/Campaigns/CampaignMainViewModel.cs (Z. 37, 40) - Begründung: Feldnamen belegen die UI-seitige Rechteauswertung; die serverseitig prüfende Stelle ist damit nicht belegt, daher sekundär statt primär und keine Sicherheits-Risikoeinstufung ohne PRIMÄR-Beleg
+Prüfidee:      Benutzer ohne Kampagnen-Bearbeitungsrecht anmelden und prüfen, dass die Bearbeiten-Funktion in der UI deaktiviert ist UND ein direkter Service-Aufruf serverseitig abgelehnt wird
+Tracelinks:    StRS-3
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - rechteabhängige Funktionsfreigabe ist Standardanforderung; serverseitige Durchsetzung im Zielsystem verifizieren (siehe Hypothese)
+Status:        HYPOTHESE
+```
+
+```
+ID:            SwRS-3
+Titel:         Update statt Duplikat bei bestehendem Sonderpreis
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente PositionToSpecialPriceViewModel
+Vorbedingung:  Für Artikel/Kundenklasse existiert bereits ein AccountSpecialPriceDTO
+Fakt:          Bei Fund eines existingSpecialPrice werden dessen Felder ArticleDescription, Comment, ValueKind, Value, ValidFrom, ValidTo mit den neuen Werten überschrieben und derselbe Datensatz (specialPriceToSave = existingSpecialPrice, Z. 121) gespeichert, statt einen neuen Datensatz anzulegen (Kommentar Z. 113: "Make sure to update the existing one, to not create duplicates")
+Aussage:       Die Komponente PositionToSpecialPriceViewModel soll bei Bestätigung des Überschreibens den bestehenden Sonderpreis-Datensatz aktualisieren, statt einen weiteren Datensatz mit gleicher Artikel-/Kundenklassen-Zuordnung anzulegen.
+Ergebnis:      Je Artikel/Kundenklasse existiert höchstens ein Sonderpreis-Datensatz
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs, Z. 113-121 - Begründung: Code-Kommentar und Zuweisung belegen explizit die Duplikatvermeidung als bewusste Entwurfsentscheidung
+Prüfidee:      Zwei Sonderpreise für denselben Artikel/dieselbe Kundenklasse anlegen und in der Datenbank prüfen, dass nur ein Datensatz existiert
+Tracelinks:    SyRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Datenintegritätsregel ohne erkennbaren Workaround-Charakter
+Status:        belegt
+```
+
+```
+ID:            SwRS-4
+Titel:         Länderspezifische Steuersatzliste als einzige Quelle für ChangeTaxRateViewModel
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente ChangeTaxRateViewModel
+Vorbedingung:  Dialog "Mehrwertsteuer ändern" wird initialisiert
+Fakt:          InitializeAsync(int? taxI3D) ruft IValueAddedTaxLogic.GetVATByCountry(CentronApplication.Instance.DefaultCountry.I3D) auf und befüllt TaxRates ausschließlich mit dem Ergebnis; SelectedTaxRate wird per I3D-Abgleich aus genau dieser Liste vorbelegt
+Aussage:       Die Komponente ChangeTaxRateViewModel soll die auswählbaren Steuersätze ausschließlich aus dem länderspezifischen Ergebnis von IValueAddedTaxLogic.GetVATByCountry beziehen, ohne eigene oder erweiterte Werte zuzulassen.
+Ergebnis:      TaxRates-Liste enthält genau die vom Backend für das Land gelieferten Sätze
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/ChangeTaxRate/ChangeTaxRateViewModel.cs, Methode InitializeAsync() (Z. 41-48) - Begründung: Durchsetzende Stelle, die die Datenquelle der Auswahlliste auf den Backend-Aufruf beschränkt
+Prüfidee:      Backend-Antwort auf zwei Steuersätze begrenzen und prüfen, dass der Dialog exakt diese zwei Optionen anzeigt
+Tracelinks:    StRS-14
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale, länderabhängige Steuersatzquelle vermeidet inkonsistente Sätze
+Status:        belegt
+```
+
+```
+ID:            SwRS-5
+Titel:         Berechnungsregel für OpenPrice/OpenPriceFC in der Belegsuche
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente InvoiceReceiptSearchConfiguration (Centron.BL)
+Vorbedingung:  Rechnungsdatensatz RechKopf (AK) wird für Opos/Zahlungserfassung gelesen
+Fakt:          OpenPrice = IIF(ISNULL(AK.MwstNichtAusweisbar,0)=0, AK.Brutto, AK.Netto) − (ISNULL(AK.Bezahlt,0) / AK.CurrencyFactor); OpenPriceFC = ROUND((IIF(...)*AK.CurrencyFactor) − ISNULL(AK.Bezahlt,0), 2) (Z. 71-72)
+Aussage:       Die Komponente InvoiceReceiptSearchConfiguration soll den offenen Rechnungsbetrag in Haus- und Fremdwährung einheitlich aus Brutto-/Netto-Betrag, Umsatzsteuerausweisbarkeit, bereits bezahltem Betrag und Währungsfaktor ableiten, damit alle lesenden Module (Opos, Zahlungserfassung, Mahnwesen) denselben Wert erhalten.
+Ergebnis:      OpenPrice/OpenPriceFC sind für alle Verbraucher dieser zentralen Abfrage konsistent
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 71-72 - Begründung: Einzige durchsetzende Berechnungsstelle, aus der Opos-Übersicht und Zahlungserfassung ihre Werte beziehen
+Prüfidee:      Unit-/Integrationstest mit MwstNichtAusweisbar=1, Bezahlt>0 und CurrencyFactor≠1 gegen die erwartete Formel prüfen
+Tracelinks:    SyRS-2, StRS-22, StRS-23
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentrale, einheitliche Berechnungsstelle vermeidet abweichende Parallelberechnungen in Opos/Zahlungserfassung/Mahnwesen
+Status:        belegt
+```
+
+```
+ID:            SwRS-6
+Titel:         Datenmodell Sichtrus/Sichmemb für gruppenbasierte Rechte
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente AppRightsBL
+Vorbedingung:  Rechteprüfung für einen Benutzer wird angestoßen
+Fakt:          GetAllAppRightsFromUser() (Z. 651-664) verknüpft dbo.Sichtrus (Spalten Gruppe, Recht) über die Gruppen-ID mit dbo.Sichmemb (Spalten Gruppe, Benutzer) und liefert alle Recht-IDs, die irgendeiner Gruppe des Benutzers zugeordnet sind
+Aussage:       Die Komponente AppRightsBL soll das Rechtemodell als Zuordnung Gruppe→Recht (Sichtrus) getrennt von der Zuordnung Benutzer→Gruppe (Sichmemb) führen, sodass sich ein Recht nie direkt, sondern immer nur über eine Gruppe einem Benutzer zuordnen lässt.
+Ergebnis:      Effektive Rechte eines Benutzers ergeben sich als Vereinigungsmenge der Rechte all seiner Gruppen
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 653-656 (SQL-Text) - Begründung: Durchsetzende Datenbankabfrage, die das Rechtemodell exakt definiert
+Prüfidee:      Benutzer zwei Gruppen mit je einem unterschiedlichen Recht zuordnen und prüfen, dass GetAllAppRightsFromUser() beide Rechte zurückliefert
+Tracelinks:    StRS-62
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - reines Gruppenmodell ohne Benutzer-Einzelrechte vereinfacht Administration und Auditierbarkeit
+Status:        belegt
+```
+
+```
+ID:            SwRS-7
+Titel:         Getrennte Rechtemodelle für interne Benutzer und Web-Accounts
+Ebene:         SwRS
+Typ:           Daten
+Qualitätsmerkmal:
+Akteur:        Komponente AppRightsBL
+Vorbedingung:  Rechteprüfung für einen Web-Account (Kundenportal/Nexus) wird angestoßen
+Fakt:          HasWebAccountRight() (Z. 666-677) nutzt eine vollständig getrennte Datenquelle (Tabelle WebAccountsRights, Spalte WebRightsI3D) gegenüber HasUserRight() für interne Benutzer (Sichtrus/Sichmemb); beide Methoden liegen zwar in derselben Klasse AppRightsBL, referenzieren aber getrennte Entitäten AppRight vs. WebRights
+Aussage:       Die Komponente AppRightsBL soll interne Benutzerrechte und Web-Account-Rechte als zwei fachlich getrennte, aber strukturell gleichartige Modelle (Objekt→Recht-Zuordnung) führen.
+Ergebnis:      Web-Accounts erhalten ausschließlich über WebAccountsRights geprüfte Rechte, unabhängig vom internen Rechtemodell
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 666-691 - Begründung: Durchsetzende Stelle, die ein zur internen Rechteprüfung strukturell paralleles, aber datenseitig getrenntes Modell implementiert
+Prüfidee:      Web-Account und internen Benutzer mit identischem Namen aber unterschiedlichen Rechten anlegen und prüfen, dass sich Web-Zugriff und interner Zugriff unabhängig voneinander verhalten
+Tracelinks:    StRS-62, StRS-101 (Nexus)
+Konsolidierung: Kandidat: Zwei strukturell gleichartige, aber datenseitig getrennte Rechtemodelle (AppRight/Sichtrus für interne Benutzer, WebRights für Web-Accounts) - im Zielsystem als ein gemeinsames Rechtemodell mit Geltungsbereich zu konsolidieren
+Übernahmewürdigkeit: Workaround - historisch getrennt gewachsene Rechtemodelle für zwei Kanäle; im SaaS-Zielsystem mit einheitlichem Identitätsmodell zusammenzuführen
+Status:        belegt
+```
+
+```
+ID:            SwRS-8
+Titel:         AES-Verschlüsselung von Zugangsdaten mit zentralem Master-Schlüssel
+Ebene:         SwRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        Komponente PasswordManagerBL
+Vorbedingung:  Zugangsdatensatz wird gespeichert oder gelesen
+Fakt:          Speichern: new AESCryptoLogic().EncryptText(customerHotline.Password, masterKeyResult.Data) (Z. 700); Lesen: new AESCryptoLogic().DecryptText(propertyValue?.ValueEncryptedString, masterKey) (Z. 1051-1052) bzw. (Z. 1179); der Master-Schlüssel selbst stammt aus CentronConfigurationDbBL.GetHotlineMasterKey() (Z. 551), also einer von der Fachdatenbank getrennten Konfigurationsdatenbank
+Aussage:       Die Komponente PasswordManagerBL soll jedes Passwortfeld beim Schreiben mit AES und einem aus einer getrennten Konfigurationsdatenbank bezogenen Master-Schlüssel verschlüsseln und beim Lesen entsprechend entschlüsseln, sodass ein Zugriff auf die Fachdatenbank allein nicht zur Preisgabe der Zugangsdaten führt.
+Ergebnis:      ValueEncryptedString enthält niemals Klartext; Klartext existiert nur transient nach Entschlüsselung mit korrektem Master-Schlüssel
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs, Z. 700, 1051-1052, 1179, 551 - Begründung: Durchsetzende Ver-/Entschlüsselungsstellen und Herkunft des Master-Schlüssels aus getrennter Konfigurationsdatenbank
+Prüfidee:      Master-Schlüssel-Zugriff simulieren und prüfen, dass ohne ihn kein aus der Fachdatenbank gelesener ValueEncryptedString entschlüsselbar ist
+Tracelinks:    StRS-85
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Trennung von Chiffrat und Schlüssel auf getrennte Datenbanken ist ein sinnvolles Sicherheitsmuster für das Zielsystem
+Status:        belegt
+```
+
@@ -0,0 +1,207 @@
+# System Requirements Specification (SyRS) – c-entron ERP-Suite
+
+Nach ISO/IEC/IEEE 29148:2018. Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen. IDs: `SyRS-<n>`, laufend über alle Module.
+
+---
+
+```
+ID:            SyRS-1
+Titel:         Konfigurierbares Pflichtfeld-Set bei Objekterzeugung prüfen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (CRM-Teilsystem)
+Vorbedingung:  Anwender löst die Erzeugung eines neuen fachlichen Objekts (hier: AccountType "Customer") aus einem bestehenden Datensatz aus
+Fakt:          MakeCustomerViewModel.CanAccept() liest 20 Boolean-Flags aus CrmSettings/CurrentAccount (z. B. IsAccountEmailRequired) und verknüpft sie jeweils mit einer Nullprüfung des zugehörigen Eingabefelds, bevor AcceptCommand ausführbar wird
+Aussage:       Das System soll vor dem Anlegen eines Kunden aus einem Adressstamm-Datensatz alle als Pflichtfeld konfigurierten Angaben auf Vollständigkeit prüfen und die Speicherung erst danach zulassen.
+Ergebnis:      Speicherbefehl ist genau dann ausführbar, wenn alle konfigurierten Pflichtfelder befüllt sind
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Crm/MakeCustomerViewModel.cs, Methode CanAccept() (Z. 244-293) - Begründung: Durchsetzende Stelle der Pflichtfeldprüfung vor Freigabe des Speicherbefehls
+Prüfidee:      Alle Pflichtfeld-Flags in CrmSettings deaktivieren und prüfen, dass der Dialog ohne Eingaben speicherbar ist; danach ein Flag aktivieren und Gegenprobe durchführen
+Tracelinks:    StRS-2
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - konfigurierbare Pflichtfelder je Mandant sind ein wiederkehrendes Muster, das im Zielsystem als generischer Validierungsmechanismus vorgesehen werden sollte
+Status:        belegt
+```
+
+```
+ID:            SyRS-2
+Titel:         Duplikatprüfung beim Anlegen eines Sonderpreises aus der Belegposition
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Belegerfassung)
+Vorbedingung:  Anwender legt aus einer Belegposition heraus einen neuen Sonderpreis für Artikel/Kundenklasse an
+Fakt:          PositionToSpecialPriceViewModel.CreateSpecialPrices() (Z. 80-131) lädt bestehende Sonderpreise über IAccountSpecialPriceLogic.GetAccountSpecialPricesAsync(), sucht je Artikel (ArticleI3D) einen bereits vorhandenen Sonderpreis und fragt bei Fund per Dialog "Sonderpreis existiert bereits" (Z. 100-108) nach, ob überschrieben werden soll; bei Ablehnung wird die Zeile übersprungen (continue, Z. 111), bei Zustimmung der bestehende Datensatz aktualisiert statt dupliziert (Z. 114-121)
+Aussage:       Das System soll beim Anlegen eines Sonderpreises aus einer Belegposition heraus prüfen, ob für Artikel und Kundenklasse bereits ein Sonderpreis existiert, und eine explizite Anwenderentscheidung einholen, statt stillschweigend einen Duplikatsatz anzulegen.
+Ergebnis:      Es existiert höchstens ein aktiver Sonderpreis je Artikel/Kundenklasse-Kombination, sofern der Anwender das Überschreiben bestätigt oder ablehnt
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs, Methode CreateSpecialPrices() (Z. 80-131) - Begründung: Durchsetzende Stelle, die Duplikate durch Update des bestehenden Datensatzes statt Neuanlage verhindert und den Anwender aktiv einbindet
+Prüfidee:      Für einen Artikel mit bereits bestehendem Sonderpreis einen zweiten Sonderpreis aus einer Belegposition anlegen und prüfen, dass der Bestätigungsdialog erscheint und bei "Nein" kein zweiter Datensatz entsteht
+Tracelinks:    StRS-1
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Duplikatvermeidung bei Sonderpreisen ist eine sinnvolle Datenintegritätsregel
+Status:        belegt
+```
+
+```
+ID:            SyRS-3
+Titel:         Auftragsbezogene Anzahlungsrechnungen für die Schlussrechnung bereitstellen
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Belegverwaltung)
+Vorbedingung:  Schlussrechnungserstellung zu einem Auftrag wird angestoßen
+Fakt:          LoadRelatedDownPaymentInvoices() filtert über ReceiptSearchFilter mit DownPaymentForOrderI3D=orderI3D und ReceiptKinds=InvoiceClass inkl. bereits abgeschlossener Belege (IncludeClosedReceipts=true), lädt zu jedem Treffer den vollständigen ReceiptInvoiceDTO nach
+Aussage:       Das System soll beim Auslösen der Schlussrechnungserstellung alle zu einem Auftrag gehörenden Anzahlungsrechnungen – einschließlich bereits abgeschlossener – vollständig auflösen und für die Weiterverarbeitung bereitstellen.
+Ergebnis:      Liste vollständiger Anzahlungsrechnungs-DTOs zum Auftrag liegt der Schlussrechnungserstellung vor
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/Finances/Receipts/DownPayment/FinalInvoice/OrderToFinalInvoiceHelper.cs, Methode LoadRelatedDownPaymentInvoices() (Z. 27-47) - Begründung: Durchsetzende Stelle des Suchfilters inkl. expliziten Einschlusses abgeschlossener Anzahlungsrechnungen
+Prüfidee:      Auftrag mit einer bereits abgeschlossenen und einer offenen Anzahlungsrechnung versehen und prüfen, dass LoadRelatedDownPaymentInvoices() beide zurückliefert
+Tracelinks:    StRS-13
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - vollständige Erfassung aller Anzahlungen unabhängig vom Abschlussstatus ist für eine korrekte Schlussrechnung zwingend
+Status:        belegt
+```
+
+```
+ID:            SyRS-4
+Titel:         Mahnfähigkeit eines Belegs serverseitig aus Persistenzdaten ableiten
+Ebene:         SyRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        System (Mahnwesen)
+Vorbedingung:  Mahnlauf wird für eine Menge fälliger Rechnungen vorbereitet
+Fakt:          Die Spalten AK.Mahnstufe und AK.MahnStop am Rechnungskopf (RechKopf) werden 1:1 in DunningLevel/DunningStop der Belegsuche übernommen (InvoiceReceiptSearchConfiguration.cs Z. 86-87) und von DunningItemViewModel.EvaluateSelectionValidity() zur Ausschlussprüfung herangezogen; das bereinigte DueDate (Z. 56) ist Grundlage der Prüfung "Rechnung hat kein Fälligkeitsdatum"
+Aussage:       Das System soll Mahnstufe, Mahnstopp und Fälligkeitsdatum als persistente Belegattribute führen und der Mahnlaufvorbereitung als konsistente, serverseitig ermittelte Datenbasis bereitstellen.
+Ergebnis:      Mahnlaufvorbereitung erhält für jede Rechnung konsistente Mahnstufe/-stopp/-fälligkeit ohne clientseitige Neuberechnung
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 56, 86-87 - Begründung: Durchsetzende Stelle der Datenableitung auf Serverseite, die die UI-Prüfung in DunningItemViewModel erst ermöglicht
+Prüfidee:      AK.FaelligAm auf einen Platzhalterwert ≤2 setzen und prüfen, dass DueDate in der Belegsuche NULL liefert und der Beleg im Mahnlauf als "ohne Fälligkeitsdatum" ausgeschlossen wird
+Tracelinks:    StRS-21
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - serverseitige, konsistente Datenbasis für den Mahnlauf ist Voraussetzung für ein rechtssicheres Mahnwesen
+Status:        belegt
+```
+
+```
+ID:            SyRS-5
+Titel:         Nebenläufige Bearbeitung von Belegen durch Sperr- und Versionskennung absichern
+Ebene:         SyRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Zuverlässigkeit
+Akteur:        System (Belegverwaltung)
+Vorbedingung:  Zwei Benutzer öffnen denselben Beleg gleichzeitig
+Fakt:          RechKopf führt sowohl LockUser (AK.LockUser, ausgewertet als LockedBy) als auch eine GUID-Spalte GUI3D (ausgewertet als ConcurrencyControlGuid) gemäß InvoiceReceiptSearchConfiguration.cs Z. 55, 78; zusätzlich werden CreatedThroughApplicationVersion/ChangedThroughApplicationVersion (Z. 83-84) je Beleg geführt
+Aussage:       Das System soll parallele Bearbeitung desselben Belegs durch eine kombinierte Sperrbenutzer- und Versions-/GUID-Kennung erkennen und einen erneuten Speichervorgang bei zwischenzeitlicher Änderung durch einen anderen Benutzer verhindern.
+Ergebnis:      Konkurrierende Änderungen an einem Beleg führen zu einer erkennbaren Konfliktmeldung statt stillem Überschreiben
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs, Z. 55, 78, 83-84 - Begründung: Persistente Felder LockUser und GUI3D belegen einen Sperr-/Konfliktmechanismus auf Datenebene; die konkrete Konfliktbehandlung beim Speichern (Vergleich/Abweisung) wurde innerhalb dieser Analyse nicht bis zur Schreibstelle zurückverfolgt
+Prüfidee:      Beleg in zwei Sitzungen gleichzeitig öffnen, in Sitzung A speichern, danach in Sitzung B speichern und prüfen, dass Sitzung B einen Konflikt anhand der abweichenden GUID/des LockUser erkennt statt die Änderung aus A stillschweigend zu verwerfen
+Tracelinks:    StRS-12
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Konflikterkennung bei Mehrbenutzerzugriff ist für ein Mehrbenutzer-ERP zwingend; Umsetzungsdetail im Zielsystem zu verifizieren
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-6
+Titel:         Pflichtangabe eines Ablaufdatums bei Erzeugung persönlicher API-Token
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Personal-Access-Token-Verwaltung)
+Vorbedingung:  Mitarbeiter erzeugt ein neues persönliches API-Token
+Fakt:          CreateToken() (Z. 157-169) übernimmt ExpiresAt aus dem Erzeugungsdialog in das gespeicherte Token; kein Codepfad innerhalb dieser Klasse erzeugt ein Token ohne ExpiresAt-Wert
+Aussage:       Das System soll bei der Erzeugung eines persönlichen API-Tokens zwingend ein Ablaufdatum erfassen und mit dem Token persistieren.
+Ergebnis:      Jedes erzeugte Token trägt ein Ablaufdatum
+Belege:
+  - [PRIMÄR] src/centron/Centron.WPF.UI/Modules/MyCentron/PersonalSettings/AccessTokens/PersonalAccessTokenSettingsViewModel.cs, Methode CreateToken() (Z. 157-169) - Begründung: Durchsetzende Stelle der Token-Erzeugung, die ExpiresAt aus dem Dialog übernimmt
+Prüfidee:      Token-Erzeugungsdialog ohne Auswahl eines Ablaufdatums abschließen und prüfen, ob ein Standardwert gesetzt oder die Erzeugung verweigert wird
+Tracelinks:    StRS-51
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - verpflichtendes Ablaufdatum begrenzt das Risiko dauerhaft gültiger, kompromittierter Token
+Status:        belegt
+```
+
+```
+ID:            SyRS-7
+Titel:         Ablaufende persönliche API-Token beim API-Zugriff serverseitig zurückweisen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Webservice-Authentifizierung, AccessTokenBL)
+Vorbedingung:  API-Aufruf mit persönlichem Zugriffstoken trifft am Webservice ein
+Fakt:          AccessTokenBL.ValidateToken() (Z. 377-419) hasht das übergebene Token (HashToken) und vergleicht ausschließlich den Hash gegen TokenHash in der DB (Z. 387-389); bei !token.IsActive (Z. 394-399) oder token.IsExpired (Z. 401-406) wird der Zugriff mit protokollierter Begründung ("Token ist deaktiviert"/"Token ist abgelaufen", AccessTokenLogActionType.ValidationFailed) abgelehnt; jeder erfolgreiche Aufruf wird zusätzlich mit apiMethod und ipAddress protokolliert (Z. 413-416) und die Funktion selbst ist lizenzpflichtig (LicenseManager.HasLicense(AccessTokenModule), Z. 382-383)
+Aussage:       Das System soll beim API-Zugriff mit einem persönlichen Token dessen Hash gegen die gespeicherten, gehashten Token prüfen, deaktivierte und abgelaufene Token zurückweisen und jeden Validierungsversuch (erfolgreich wie fehlgeschlagen) mit IP-Adresse und aufgerufener Methode protokollieren.
+Ergebnis:      Abgelaufenes oder deaktiviertes Token wird von der Webservice-Schicht mit Audit-Log-Eintrag abgelehnt; Token liegt nie im Klartext in der Datenbank
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/AccessTokens/AccessTokenBL.cs, Methode ValidateToken() (Z. 377-419) - Begründung: Durchsetzende Stelle mit Hash-Vergleich, Aktiv-/Ablaufprüfung und lückenloser Protokollierung
+  - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AuthenticateInterceptor.cs, Z. 51-58 - Begründung: Ruft bei fehlgeschlagener Ticket-Validierung ValidateToken() als zweiten Authentifizierungsweg für jeden mit [Authenticate] markierten API-Aufruf auf
+Prüfidee:      Token mit ExpiresAt in der Vergangenheit gegen einen Webservice-Endpunkt verwenden und prüfen, dass der Aufruf abgelehnt und ein ValidationFailed-Logeintrag mit Grund "Token ist abgelaufen" erzeugt wird
+Tracelinks:    StRS-51, SyRS-6
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Hash-Speicherung, Ablaufprüfung und lückenlose Protokollierung sind vorbildliche Sicherheitspraxis für das Zielsystem
+Status:        belegt
+```
+
+```
+ID:            SyRS-10
+Titel:         Duale API-Authentifizierung über Sitzungsticket oder Access-Token mit anwendungsbezogener Einschränkung
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Webservice-Authentifizierung)
+Vorbedingung:  Beliebiger, mit [Authenticate] markierter API-Aufruf trifft ein
+Fakt:          AuthenticateInterceptor.InterceptExecution() (Z. 22-61) validiert zunächst als Sitzungsticket (ValidateTicketAndSetReturnValue → AuthenticationTicketBL.GetAuthTicketInfo, Z. 25-48 in AuthenticationTicketBL.cs); bei gültigem Ticket wird zusätzlich geprüft, ob die aufrufende Anwendung (ApplicationKind) für die Methode zugelassen ist (Z. 38) und ob ein Web-Account-Ticket die Methode aufrufen darf (Z. 39, AllowWebAccountLogin); schlägt die Ticket-Prüfung fehl, wird als zweiter Weg ein Access-Token geprüft (Z. 52-57), wobei Access-Token laut Code ausdrücklich KEINE Anwendungseinschränkung unterliegen; ein Kommentar im Code (Z. 33-37) hält fest, dass das Modell nur "diese Anwendung darf aufrufen" abbildet, nicht aber "diese Anwendung darf nur diese Methoden aufrufen"
+Aussage:       Das System soll jeden API-Aufruf entweder über ein anwendungsbezogen eingeschränktes Sitzungsticket oder über ein Access-Token ohne Anwendungseinschränkung authentifizieren und dabei Web-Account-Tickets standardmäßig von internen Methoden ausschließen.
+Ergebnis:      Nicht authentifizierte oder unzulässige Aufrufe werden mit einheitlicher Fehlermeldung ohne Preisgabe des genauen Fehlgrundes abgewiesen
+Belege:
+  - [PRIMÄR] src/webservice/Centron.Host/AspNetCore/WcfBridge/Interception/Interceptors/AuthenticateInterceptor.cs, Z. 22-61 - Begründung: Durchsetzende Stelle der gesamten API-Authentifizierung inkl. der vom Entwickler selbst im Code dokumentierten Modellgrenze
+Prüfidee:      Ticket einer für Methode X nicht zugelassenen Anwendung verwenden und prüfen, dass der Aufruf mit "You don't have the permission..." abgewiesen wird; anschließend mit einem Access-Token dieselbe Methode aufrufen und die fehlende Anwendungseinschränkung bestätigen
+Tracelinks:    StRS-62, SyRS-7
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Zwei-Wege-Authentifizierung ist sinnvoll; die vom Entwickler selbst dokumentierte Lücke (keine methodenscharfe Einschränkung für Access-Token/bestimmte Anwendungen) ist im Zielsystem gezielt zu schließen (z. B. Scopes je Access-Token)
+Status:        belegt
+```
+
+```
+ID:            SyRS-8
+Titel:         Serverseitige Rechteprüfung mit benutzerbezogenem Cache
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Rechtesystem, Centron.BL)
+Vorbedingung:  Geschützte Funktion wird aufgerufen
+Fakt:          HasUserRight() cacht das Ergebnis von GetAllAppRightsFromUser() unter dem Schlüssel "AllRightsFromAppUser{appUserI3D}" (Z. 646); ein Aufruf, der den Cache nach einer Rechteänderung gezielt invalidiert, wurde innerhalb dieser Analyse nicht lokalisiert
+Aussage:       Das System soll die Rechte eines Benutzers serverseitig prüfen und dabei zur Performanceoptimierung cachen; Änderungen an der Gruppenzuordnung oder Gruppenrechten sollen sich zeitnah auf bereits angemeldete Sitzungen auswirken.
+Ergebnis:      Rechteprüfung ist performant; Rechteänderungen wirken ohne unangemessene Verzögerung
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 646 (Cache.GetOrAdd) - Begründung: Durchsetzende Stelle des Caching-Mechanismus
+Prüfidee:      Benutzer ein Recht entziehen, während dessen Sitzung aktiv ist, und prüfen, wie lange die alte Berechtigung noch wirksam bleibt
+Tracelinks:    StRS-62
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Caching ist sinnvoll, Invalidierungsstrategie bei Rechteänderung im Zielsystem explizit zu spezifizieren
+Status:        HYPOTHESE
+```
+
+```
+ID:            SyRS-9
+Titel:         Administrator-Gruppe vor Entzug systemkritischer Rechte schützen
+Ebene:         SyRS
+Typ:           Sicherheit
+Qualitätsmerkmal:
+Akteur:        System (Rechtesystem)
+Vorbedingung:  Administrator ändert Rechte der Administrator-Gruppe selbst
+Fakt:          SaveAndAssignGroupToRight()/RemoveAssignGroupToRight() (Z. 261-299) prüfen bei IsAdministratorGroup(group) zusätzlich GetAssignableAdminRightI3Ds() und verweigern die Änderung (return false), wenn das gewählte Recht nicht in dieser Freigabeliste enthalten ist
+Aussage:       Das System soll verhindern, dass systemkritische Rechte von der Administrator-Gruppe entfernt oder ihr zusätzliche, nicht freigegebene Rechte zugewiesen werden, um ein versehentliches Aussperren aller Administratoren zu verhindern.
+Ergebnis:      Änderungsversuch an nicht freigegebenen Rechten der Administrator-Gruppe wird abgewiesen
+Belege:
+  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, Z. 266-271 und 284-289 - Begründung: Durchsetzende Stelle, die Änderungen an der Administrator-Gruppe auf eine Freigabeliste beschränkt
+Prüfidee:      Versuch, ein nicht in GetAssignableAdminRightI3Ds() enthaltenes Recht von der Administrator-Gruppe zu entfernen, und prüfen, dass RemoveAssignGroupToRight() false liefert
+Tracelinks:    StRS-62
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Schutz vor Selbstaussperrung der Administration ist eine bewährte Sicherheitsmaßnahme
+Status:        belegt
+```
+
@@ -0,0 +1,139 @@
+# Traceability-Tabelle
+
+Konsolidierte Forward-/Backward-Traceability zwischen StRS, SyRS und SwRS. Jede StRS-Zeile ist vorhanden (Mindestabdeckung, ein StRS je Inventarmodul aus `Analysebericht.md`). Wo eine Anforderung in dieser Iteration bis auf SyRS- und/oder SwRS-Ebene vertieft wurde (Schritt 0c, Risikomodule), sind die zugehörigen IDs eingetragen; die übrigen Zeilen sind auf StRS-Ebene belegt, aber in dieser Iteration nicht weiter auf SyRS/SwRS heruntergebrochen (siehe Selbstbewertung). Artefaktbeleg = jeweils der primäre Beleg der am weitesten unten liegenden Ebene der Zeile.
+
+## A. Vertiefte Ketten (StRS ↔ SyRS ↔ SwRS)
+
+| StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (primär) |
+|---------|---------|---------|--------------------------|
+| StRS-1 (Sonderpreise/Produktmatrix) | SyRS-2 (Duplikatprüfung Sonderpreis) | SwRS-3 (Update statt Duplikat) | Receipts/PositionToSpecialPrice/PositionToSpecialPriceViewModel.cs Z. 80-131 |
+| StRS-2 (Pflichtfelder Kundenanlage) | SyRS-1 (Pflichtfeld-Set prüfen) | SwRS-1 (CanAccept-Gate) | Finances/Crm/MakeCustomerViewModel.cs Z. 244-293 |
+| StRS-3 (Kampagnen-Status/Rechte) | – | SwRS-2 (Rechteabhängige Kampagnenfunktionen) [HYPOTHESE] | Finances/Campaigns/CampaignMainViewModel.cs Z. 31-40 |
+| StRS-12 (Belegkette Angebot–Rechnung) | SyRS-5 (Nebenläufigkeitsschutz) [HYPOTHESE] | – | InvoiceReceiptSearchConfiguration.cs Z. 55, 78, 83-84 |
+| StRS-13 (Anzahlung → Schlussrechnung) | SyRS-3 (Anzahlungsrechnungen bereitstellen) | – | DownPayment/FinalInvoice/OrderToFinalInvoiceHelper.cs Z. 27-47 |
+| StRS-14 (Steuersatzänderung) | – | SwRS-4 (Länderspezifische Steuersatzliste) | Receipts/ChangeTaxRate/ChangeTaxRateViewModel.cs Z. 41-53 |
+| StRS-21 (Mahnlauf/Mahnstopp) | SyRS-4 (Mahnfähigkeit serverseitig) | – | Dunning/Common/DunningItemViewModel.cs Z. 445-469 |
+| StRS-22 (Offene Posten) | – | SwRS-5 (OpenPrice-Formel) | InvoiceReceiptSearchConfiguration.cs Z. 71-72 |
+| StRS-23 (Zahlungserfassung) | – | SwRS-5 (OpenPrice-Formel, gemeinsam mit StRS-22) | Payments/PaymentsReceiptViewModel.cs Z. 39-46 |
+| StRS-51 (Personal-Access-Token) | SyRS-6 (Pflicht-Ablaufdatum), SyRS-7 (serverseitige Ablaufprüfung) | – | AccessTokenBL.ValidateToken() Z. 377-419 |
+| StRS-62 (Gruppenbasierte Rechte) | SyRS-8 (Rechteprüfung+Cache) [HYPOTHESE-Anteil], SyRS-9 (Admin-Gruppen-Schutz), SyRS-10 (duale API-Authentifizierung) | SwRS-6 (Sichtrus/Sichmemb-Modell), SwRS-7 (getrennte Web-Rechte) | AppRightsBL.cs Z. 644-691, 261-299 |
+| StRS-85 (Passwortverwaltung AES) | – | SwRS-8 (AES-Verschlüsselung Master-Key) | PasswordManagerBL.cs Z. 700, 1051-1052, 1179 |
+| StRS-98 (Web-API-Authentifizierung) | SyRS-10 (duale Authentifizierung, gemeinsam mit StRS-62), SyRS-7 | – | AuthenticateInterceptor.cs Z. 22-61 |
+| StRS-101 (Nexus Kundenportal/WebCart) | – | SwRS-7 (getrennte Web-Rechte, gemeinsam mit StRS-62) | Management/WebAccount/Model/WebRightNode.cs |
+
+## B. StRS-Anforderungen ohne separate SyRS-/SwRS-Formalisierung in dieser Iteration
+
+Diese Anforderungen sind auf StRS-Ebene mit eigenem Artefaktbeleg (siehe StRS.md) belegt; der Artefaktbeleg unten verweist auf den Modulpfad aus dem Inventar (`Analysebericht.md`, Schritt 0). Eine Vertiefung auf SyRS/SwRS ist gemäß Selbstbewertung für die dort genannten Module priorisiert nachzuholen.
+
+| StRS-ID | Titel (Kurzform) | Artefaktbeleg (Modulpfad lt. Inventar) |
+|---------|-------------------|------------------------------------------|
+| StRS-4 | CRM-Stammdatenlisten (Counters) | Modules/Finances/MasterDataLists |
+| StRS-5 | Vertragsverwaltung | Modules/Finances/Contracts |
+| StRS-6 | Projektverwaltung (Finanzsicht) | Modules/Finances/Projects |
+| StRS-7 | Zählerstandserfassung MPS | Modules/Finances/DeviceClickCounter |
+| StRS-8 | PLM | Modules/PLM |
+| StRS-9 | Zahler-/Kostenstellenverwaltung | Modules/PayersAndCostCenter |
+| StRS-10 | Projektpreisimport | Modules/ProjectPriceImport |
+| StRS-11 | Projektmanagement (Workload) | Modules/ProjectManagement |
+| StRS-15 | Provisionsermittlung | Modules/Finances/Receipts/Provision |
+| StRS-16 | Web-Angebote | Modules/Finances/Receipts/WebOffer |
+| StRS-17 | EDI-Auftragsverbuchung | Modules/Finances/Receipts/EdiOrderbooking |
+| StRS-18 | Automatisierte Rechnungserstellung | Modules/Finances/AutomatedBilling |
+| StRS-19 | Pauschalabrechnung | Modules/Finances/FlatrateBilling |
+| StRS-20 | Zeit-/Leistungsabrechnung | Modules/Finances/TimerBilling |
+| StRS-24 | Kontenverwaltung | Modules/Finances/AccountManagement |
+| StRS-25 | Warenausgangszahlungen | Modules/Warehousing/OutcomingPayments |
+| StRS-26 | Kassensystem-Anbindung | Modules/Warehousing/AccountSystems |
+| StRS-27 | Artikelstammdaten/AutoEOL | Modules/Warehousing/ArticleManagement |
+| StRS-28 | Artikelimport | Modules/Warehousing/ArticleImport |
+| StRS-29 | Mengeneinheiten (UN/ECE) | Modules/Warehousing/ArticleUnitManagement |
+| StRS-30 | Barcode-Verwaltung | Modules/Warehousing/BarcodeManagement |
+| StRS-31 | Kommissionierung | Modules/Warehousing/Commissioning |
+| StRS-32 | Kommissionsware/Konsignation | Modules/Warehousing/Commissions |
+| StRS-33 | Inventur | Modules/Warehousing/Inventory |
+| StRS-34 | Warengruppenverwaltung | Modules/Warehousing/MaterialGroupManagement |
+| StRS-35 | Artikelsuche | Modules/Warehousing/SearchArticle |
+| StRS-36 | Lieferantensuche | Modules/Warehousing/SupplierSearch |
+| StRS-37 | Logistikeinstellungen | Modules/Logistic |
+| StRS-38 | EDI-Bestellwesen | Modules/Purchasing/EDIManagement |
+| StRS-39 | Bestellvorschlagsliste | Modules/Purchasing/OrderSuggestionList |
+| StRS-40 | Einkaufseinstellungen | Modules/Purchasing/PurchaseSettings |
+| StRS-41 | Reisekostenabrechnung | Modules/Purchasing/TravelExpense |
+| StRS-42 | Fertigungsauftragsverwaltung | Modules/Production/ProductionOrder |
+| StRS-43 | Maschinenverwaltung | Modules/Production/MachineManagement |
+| StRS-44 | RMA-Abwicklung | Modules/Rma |
+| StRS-45 | Ticketverwaltung | Modules/Helpdesk/TicketDetails |
+| StRS-46 | Helpdesk-Dashboard | Modules/Helpdesk/Dashboard |
+| StRS-47 | Erwartete Wartungsereignisse | Modules/Helpdesk/ExpectedEvents |
+| StRS-48 | Helpdesk-Einstellungen | Modules/Helpdesk/Settings |
+| StRS-49 | Helpdesk Selbstbedienung | Modules/Helpdesk/SendSelfCareForm |
+| StRS-50 | CentronInspectors (Dateninspektion) | Modules/MyCentron/CentronInspectors |
+| StRS-52 | MyDay | Modules/MyCentron/MyDay |
+| StRS-53 | MyCentron-Dashboard | Modules/MyCentron/Dashboard |
+| StRS-54 | ToDo-Liste | Modules/MyCentron/TodoList |
+| StRS-55 | Telefonie-Integration | Modules/MyCentron/Telephony |
+| StRS-56 | Supremo-Fernwartung | Modules/MyCentron/Supremo |
+| StRS-57 | Verkaufsstatistik | Modules/Statistics/SaleStatistics |
+| StRS-58 | Management-Informationen | Modules/Statistics/ManagementInfo |
+| StRS-59 | MSP-Statistiken | Modules/Statistics/MspStatistics |
+| StRS-60 | Mitarbeiteranalyse | Modules/Statistics/EmployeeAnalytics |
+| StRS-61 | Reportverwaltung | Modules/Reports/ReportManagement |
+| StRS-63 | Mitarbeiterverwaltung/AD-Import | Modules/Administration/EmployeeManagement |
+| StRS-64 | Mandantenverwaltung | Modules/Administration/MandatorManagement |
+| StRS-65 | DSGVO/AVV/Löschrechte | Modules/Administration/DSGVO |
+| StRS-66 | Systemweite Token-Richtlinie | Modules/Administration/Settings |
+| StRS-67 | Verbindungs-/Schnittstelleneinstellungen | Modules/Administration/WebServiceSettings |
+| StRS-68 | KI-Mailvorlagen | Modules/Administration/MailTemplates |
+| StRS-69 | PDF-Signatur/KI-Textbausteine | Modules/Administration/PdfSigning |
+| StRS-70 | Stundensätze/Zuschläge | Modules/Administration/HourlySurchargeRates |
+| StRS-71 | Eskalationseinstellungen | Modules/Administration/EscalationsSettings |
+| StRS-72 | Länderverwaltung | Modules/Administration/CountryManagement |
+| StRS-73 | SEPA-Mandate (Signatur-Workflow) | Modules/Administration/SepaContract |
+| StRS-74 | Externe Werkzeuge | Modules/Administration/ExternalTools |
+| StRS-75 | WebCart-Konfiguration | Modules/Administration/WebCart |
+| StRS-76 | Sonstige Prozesseinstellungen | Modules/Administration/SendDeliveryListShippingConfirmationSettings |
+| StRS-77 | Log-Betrachter | Modules/Administration/LogViewer |
+| StRS-78 | Dienste-Verwaltung | Modules/Administration/Services |
+| StRS-79 | Bankumsätze/IBAN-Klärung | Modules/OnlineBanking/AccountTransactions |
+| StRS-80 | OnlineBanking-Konfiguration | Modules/OnlineBanking/AccountTransactions/Converter |
+| StRS-81 | OnlineBanking-Verbindungsdialog | Modules/OnlineBanking/ConnectionDialog |
+| StRS-82 | KI-Chat-Assistent | Modules/ArtificialIntelligence |
+| StRS-83 | Kundenumfragen | Modules/Survey |
+| StRS-84 | Massenänderungen | Modules/Massenupdates |
+| StRS-86 | Kalendersynchronisation | Modules/Calendar |
+| StRS-87 | QM-Prüfgründe | Modules/QM |
+| StRS-88 | Telekom-DIVE-Export (UI) | Modules/TelekomDive |
+| StRS-89 | Startdashboard | Modules/Dashboard |
+| StRS-90 | UI-Layoutprofile | Modules/Gui |
+| StRS-91 | MSP-Lizenzabgleich | Modules/Global/MSPLicensesCompare |
+| StRS-92 | Backend-Kernschicht | backend/Centron.BL |
+| StRS-93 | EDI-Lieferantenanbindungen | backend/Centron.Gateway/EDI_Also |
+| StRS-94 | Banking-Gateway Backend | backend/Centron.Gateway/OnlineBanking |
+| StRS-95 | MSP-Collector-Gateway | backend/Centron.Gateway/MspCollector |
+| StRS-96 | E-Rechnungsformate (ZUGFeRD) | backend/Centron.Gateway/ZUGFeRD21_Extended |
+| StRS-97 | Portal-Gateway | backend/Centron.Gateway/Portal |
+| StRS-99 | Lizenz-/Verbindungsmanager | webservice/c-entron.misc.ConnectionManager |
+| StRS-100 | ServiceBoard (Web-Kanban) | nexus/CentronNexus/ServiceBoard |
+| StRS-102 | Web-Fertigungsauftragsverwaltung | nexus/CentronNexus/ProductionOrderManagement |
+| StRS-103 | Nexus-Verwaltung/WebRights | nexus/CentronNexus/Management |
+| StRS-104 | Web-Dokumentensignatur | nexus/CentronNexus/DocumentSigning |
+| StRS-105 | Outlook-Add-in | nexus/CentronNexus.OutlookAddIn |
+| StRS-106 | Produktdaten-APIs | apis/Centron.APIs.IcecatDataAccess |
+| StRS-107 | FinAPI-Bankanbindung | apis/Centron.APIs.FinAPI |
+| StRS-108 | ebInterface (Österreich) | apis/Centron.Api.EbInterface |
+| StRS-109 | Versanddienstleister-APIs | apis/Centron.Api.Gls |
+| StRS-110 | docuFORM PDF-Generierung | Modules/DataExchange/DocuForm |
+| StRS-111 | Adress-/Kontoimport-Validierung | Modules/DataExchange/DataImport |
+| StRS-112 | Buchhaltungsexport | Modules/DataExchange/BookKeeping |
+| StRS-113 | DATEV-Anbindung | Modules/DataExchange/DatevOnline2020 |
+| StRS-114 | SEPA-Zahlungsdatei (pain.008) | backend/Centron.Gateway/DataExchange/PaymentTransactions/Sepa |
+| StRS-115 | Telekom-DIVE (Austauschebene) | Modules/DataExchange/TelekomDive |
+| StRS-116 | Datenexport (allgemein) | Modules/DataExchange/DataExport |
+| StRS-117 | Sonstige Schnittstellen | Modules/DataExchange/SupplierOrderPerBranch |
+| StRS-118 | Deployment & Betrieb | docker/, azure/ |
+
+## Hinweise zur Lesart
+
+- Ein „–" in Spalte SyRS/SwRS bedeutet: kein zugehöriger Datensatz auf dieser Ebene in dieser Iteration.
+- `[HYPOTHESE]`-Kennzeichnungen in Abschnitt A sind identisch mit `Hypothesen.md` zu lesen.
+- Rückwärtsverknüpfung (SwRS→SyRS→StRS, SyRS→StRS) ist in jedem einzelnen Anforderungsblock über das Feld `Tracelinks:` zusätzlich dezentral hinterlegt (siehe StRS.md/SyRS.md/SwRS.md) und hier nur konsolidiert zusammengeführt.
@@ -0,0 +1,165 @@
+# Messprotokoll – Versuch 01 (V1 Baseline, Prompt-only) – Iteration 02
+
+## Lauf
+- **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
+- **Iteration:** 02 – vom User ausdrücklich benannt; entspricht zugleich der Regel „höchste
+  vorhandene Iterationsnummer". Wiederholungslauf zur Varianzbestimmung in derselben Zelle.
+- **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
+- **Startzeit:** 2026-08-27T09:12:15.0639875+02:00
+- **Endzeit:** 2026-08-27T09:59:53.4377636+02:00
+- **Dauer gesamt:** 0:47:38 (`duration_ms` 0:47:35; API: 0:46:19)
+  — **im Parallelbetrieb erhoben, nicht für Laufzeitvergleiche verwendbar**
+- **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP` (24.662 versionierte Dateien)
+- **Codebasis-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748` (dirty: nein)
+- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfmuster ohne Treffer);
+  die Codebasis ist seit Commit `f045b99a` kein eigenes Repository mehr, sondern Teil des
+  Arbeitsrepos – der Vorher/Nachher-Vergleich läuft deshalb pfadskopiert
+- **Snapshot-Zusatzartefakte:** keine – der Snapshot entspricht dem Commit-Stand
+- **Prompt-Repo-Commit:** `7df384f6d2e7249dc914a74e299fe7fa71ece748`
+
+## Werkzeugkonfiguration
+- **Skill-Version:** 7.0.0
+- **Claude-Code-Version:** 2.1.246
+- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\.vscode\extensions\anthropic.claude-code-2.1.246-win32-x64\resources\native-binary\claude.exe`
+- **Modell (angefordert):** `claude-sonnet-5`
+- **Modelle (tatsächlich eingesetzt):** `claude-sonnet-5` 38.429.213 Tokens (99.98 %), `claude-haiku-4-5-20251001` 6.965 Tokens (0.02 %)
+- **Kontrolle Modell:** bestanden – ausschließlich das angeforderte Modell plus Haiku als zulässiger interner Hilfsaufruf
+- **Effort:** `max` (per `--effort max` gesetzt)
+- **Laufverzeichnis-ID:** `v7.0.0-da3c`
+- **Ablage:** `Iteration 3/claude-sonnet-5/solo/max/`
+- **Parallele Läufe:** nein – die Zeitangaben sind für Laufzeitvergleiche verwendbar
+- **Agentenmodus:** `solo` (V1)
+- **Kontextfenster:** 1.000.000 Tokens; `maxOutputTokens` 64.000
+- **Sampling-Parameter:** nicht steuerbar über die CLI, nicht erfasst
+- **Nur bei lokalem Modellbetrieb:** entfällt (Cloud-Inferenz, `provider: firstParty`)
+- **Permission-Mode:** `acceptEdits`
+- **Toolfreigabe:** `--allowedTools "Bash" "PowerShell"` /
+  `--disallowedTools` 33er-Denylist (schreibende und bauende Kommandos) **zuzüglich** `Task`, `Agent`, `Workflow` aus dem Modus `solo`
+- **Isolationsmechanismus:** `--safe-mode`, `--strict-mcp-config`
+- **MCP-Server / Agentendateien:** keine – aus dem Snapshot entfernt, zusätzlich `--safe-mode`
+- **Subagenten:** keine (`spawned` = 0, `by_type` leer)
+- **Verschachtelung:** `spawned` = 0, davon `spawned_by_subagents` = 0, `max_depth` = 0. Keine tieferen Ebenen, `_meta\subagenten.md` entfällt.
+
+## Validierungsstichprobe
+- **Größe:** noch nicht festgelegt
+- **Ziehungsverfahren:** noch nicht festgelegt
+- **Validatoren:** noch nicht festgelegt
+- **Stand:** noch nicht gezogen
+
+## Verbrauch
+
+### Hauptagent (`usage`)
+| Messgröße | Wert |
+|---|---:|
+| Input-Tokens | 290 |
+| Output-Tokens | 284.916 (davon 95.123 Thinking-Tokens) |
+| Cache-Write-Tokens | 457.428 |
+| Cache-Read-Tokens | 37.686.579 |
+| Agent-Turns | 217 |
+
+### Gesamtlauf inkl. Subagenten (`modelUsage`, abrechnungsrelevant)
+| Messgröße | `claude-sonnet-5` | `claude-haiku-4-5-20251001` | Summe |
+|---|---:|---:|---:|
+| Input-Tokens | 290 | 6.945 | 7.235 |
+| Output-Tokens | 284.916 | 20 | 284.936 |
+| Cache-Write-Tokens | 457.428 | 0 | 457.428 |
+| Cache-Read-Tokens | 37.686.579 | 0 | 37.686.579 |
+| **Tokens gesamt** | **38.429.213** | **6.965** | **38.436.178** |
+
+**Tokens gesamt: 38.436.178** — Input + Output + Cache-Write + Cache-Read über alle Modelle.
+Das ist die **berichtete Aufwandsgröße** der Versuchsreihe. `total_cost_usd` bleibt unberührt in
+`RawResult.json` erhalten, wird aber nicht ins Protokoll übernommen: Token sind modell- und
+preisunabhängig und bleiben damit über Preisänderungen und Modellwechsel hinweg vergleichbar.
+
+Da im Modus `solo` keine Subagenten laufen, sind `usage` und `modelUsage` für das Hauptmodell
+deckungsgleich; die Differenz zur Summe stammt allein aus den Haiku-Hilfsaufrufen.
+
+## 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 | 118 | 86,8 % |
+| SyRS | 10 | 7,4 % |
+| SwRS | 8 | 5,9 % |
+| **Gesamt** | **136** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 100 | 73,5 % |
+| Schnittstelle | 19 | 14,0 % |
+| Sicherheit | 10 | 7,4 % |
+| Daten | 5 | 3,7 % |
+| nicht-funktional | 2 | 1,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 166 |
+| davon `PRIMÄR` | 51 (30,7 %) |
+| davon `SEKUNDÄR` | 60 (36,1 %) |
+| davon `KONTEXT` | 55 (33,1 %) |
+| Belege je Anforderung (Median) | 1,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 46 (33,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 129 | 94,9 % |
+| workaround | 2 | 1,5 % |
+| sonderfall | 4 | 2,9 % |
+| veraltet | 1 | 0,7 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 130 | 95,6 % |
+| als `HYPOTHESE` gekennzeichnet | 6 | 4,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 23 | 16,9 % |
+| mit ISO-25010-Qualitätsmerkmal | 2 | 1,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 33 ungedeckt: StRS-25, StRS-31, StRS-72, StRS-91, StRS-92, StRS-99, StRS-102 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 136 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 136 mit Tracelinks (59,6 %) |
+
+## Ergebnis
+- **Status:** erfolgreich (`is_error` = false, `subtype` = `success`, `stop_reason` = `end_turn`, `terminal_reason` = `completed`)
+- **Session-ID:** `4a31e82c-b2b8-43a5-9a37-d3dc63f94b58`
+- **Permission-Denials:** 0 – **keines auf `Task`/`Agent`/`Workflow`**. Der Agent hat zu keinem Zeitpunkt zu delegieren versucht; die Modus-Sperre wurde nie ausgelöst.
+- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – Bedingung `solo` eingehalten
+- **Subagenten-Prompts:** entfällt (Modus `solo`)
+- **Erzeugte Dateien:** 7 Dateien in `Ergebnisse\`:
+
+  | Datei | Größe |
+  |---|---:|
+  | `Analysebericht.md` | 39.319 B |
+  | `Glossar.md` | 5.940 B |
+  | `Hypothesen.md` | 4.425 B |
+  | `StRS.md` | 168.024 B |
+  | `SwRS.md` | 13.076 B |
+  | `SyRS.md` | 18.243 B |
+  | `Traceability.md` | 11.369 B |
+
+- **Root unverändert:** ja (zeilenendennormalisiert verglichen).
+- **Abschlusstext des Agenten:** siehe `RawResult.json` (`result`)
+
+## Anmerkungen/Auffälligkeiten
+
+<!-- ANMERKUNGEN -->
@@ -0,0 +1 @@
+{"is_error":false,"duration_api_ms":2779209,"num_turns":217,"stop_reason":"end_turn","session_id":"4a31e82c-b2b8-43a5-9a37-d3dc63f94b58","total_cost_usd":12.223812800000006,"usage":{"input_tokens":290,"cache_creation_input_tokens":457428,"cache_read_input_tokens":37686579,"output_tokens":284916,"output_tokens_details":{"thinking_tokens":95123},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":457428,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":910,"cache_read_input_tokens":456874,"cache_creation_input_tokens":554,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":554},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007045,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":290,"outputTokens":284916,"cacheReadInputTokens":37686579,"cacheCreationInputTokens":457428,"webSearchRequests":0,"costUSD":12.216767800000005,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"The reverse requirements engineering specification for the c-entron ERP-Suite is complete. All seven deliverables are in `Ergebnisse/`:\n\n**Coverage achieved:**\n- **Modulinventar (Schritt 0):** 118 modules identified across the entire codebase (WPF desktop client, backend BL/DAO, webservice API, Nexus web frontend, external API integrations, data-exchange connectors, deployment) — 0 modules left unanalyzed\n- **136 requirements total:** 118 StRS + 10 SyRS + 8 SwRS, with full forward/backward traceability\n- **Risk-based deepening (Schritt 0c):** 14 modules fully deepened across all three levels — rights management (found the actual group-based RBAC enforcement in `AppRightsBL.HasUserRight`), password vault AES encryption, dual ticket/access-token API authentication, dunning-stop logic, open-items/payment formulas, SEPA/DSGVO signature workflows\n- **29 risk-relevant requirements** (security, billing, permissions) individually checked: 23 carry a PRIMÄR beleg, 6 are honestly marked `[HYPOTHESE]`\n- **23 consolidation candidates** found with concrete evidence (e.g., a literal copy-paste artifact: the SEPA-mandate settings class still carries internal field names like `_declinedOrderProcessingContractSubject` left over from the DSGVO-AVV class it was cloned from)\n- **Self-check caught and fixed 3 rule violations** during the consistency pass — three security/billing requirements had only SEKUNDÄR evidence but were marked `belegt`; corrected to `HYPOTHESE` before finalizing\n\nThe codebase itself was only read, never modified (verified via `git status`).\n\nOne thing worth flagging to you directly: 86 of the 118 modules are at \"flach\" depth (one requirement, existence-level evidence only) — that's the explicit breadth-first tradeoff the prompt asked for, but it means modules like the 794-file `Finances/Receipts` core or the 320-file `ArticleManagement` still have far more to extract in a follow-up pass. That's called out concretely in the self-assessment.","ttft_ms":7192,"ttft_stream_ms":1124,"time_to_request_ms":36,"type":"result","duration_ms":2855005,"uuid":"0912e717-c040-47a4-8d5e-381952f58a7d","queued_turn_count":0}
@@ -0,0 +1,65 @@
+## 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 | 118 | 86,8 % |
+| SyRS | 10 | 7,4 % |
+| SwRS | 8 | 5,9 % |
+| **Gesamt** | **136** | 100 % |
+
+### Anforderungstypen
+
+| Typ | Anzahl | Anteil |
+|---|---:|---:|
+| funktional | 100 | 73,5 % |
+| Schnittstelle | 19 | 14,0 % |
+| Sicherheit | 10 | 7,4 % |
+| Daten | 5 | 3,7 % |
+| nicht-funktional | 2 | 1,5 % |
+
+### Belegqualität
+
+| Messgröße | Wert |
+|---|---:|
+| Belege gesamt | 166 |
+| davon `PRIMÄR` | 51 (30,7 %) |
+| davon `SEKUNDÄR` | 60 (36,1 %) |
+| davon `KONTEXT` | 55 (33,1 %) |
+| Belege je Anforderung (Median) | 1,0 |
+| Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 46 (33,8 %) |
+
+### Übernahmewürdigkeit
+
+| Einstufung | Anzahl | Anteil |
+|---|---:|---:|
+| übernehmen | 129 | 94,9 % |
+| workaround | 2 | 1,5 % |
+| sonderfall | 4 | 2,9 % |
+| veraltet | 1 | 0,7 % |
+
+### Status
+
+| Kategorie | Anzahl | Anteil |
+|---|---:|---:|
+| belegt | 130 | 95,6 % |
+| als `HYPOTHESE` gekennzeichnet | 6 | 4,4 % |
+| als Workaround vermerkt | 0 | 0,0 % |
+| Konsolidierungskandidaten | 23 | 16,9 % |
+| mit ISO-25010-Qualitätsmerkmal | 2 | 1,5 % |
+
+### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
+
+| Vorgabe | Ergebnis |
+|---|---|
+| **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
+| **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **verletzt** – 7 von 33 ungedeckt: StRS-25, StRS-31, StRS-72, StRS-91, StRS-92, StRS-99, StRS-102 |
+| **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
+| **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 136 Anforderungen eingestuft) |
+| **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 136 mit Tracelinks (59,6 %) |
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,177 @@
+# 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 sowie das Ausführen von
+Kommandozeilenbefehlen im Arbeitsverzeichnis.
+Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, 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-sonnet-5\solo\max\02_Lauf_2026-08-27_091214_v7.0.0-da3c\Ergebnisse\`.
+Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-27T09:59:53.4377636+02:00
@@ -0,0 +1 @@
+2026-08-27T09:12:15.0639875+02:00
				`@@ -0,0 +1 @@`
				{"is_error":true,"duration_api_ms":6921934,"num_turns":39,"stop_reason":"stop_sequence","session_id":"8d493a0f-f069-46a0-93de-8427787b311e","total_cost_usd":19.8662592,"usage":{"input_tokens":28,"cache_creation_input_tokens":110625,"cache_read_input_tokens":960495,"output_tokens":65463,"output_tokens_details":{"thinking_tokens":37220},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":110625,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":31750,"cache_read_input_tokens":106780,"cache_creation_input_tokens":3845,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":3845},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6961,"outputTokens":24,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.0070810000000000005,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":548,"outputTokens":710526,"cacheReadInputTokens":40508211,"cacheCreationInputTokens":1794097,"webSearchRequests":0,"costUSD":19.8591782,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[{"tool_name":"Bash","tool_use_id":"toolu_01JBgsXfn416qWFSQG5hziEb","tool_input":{"command":"mkdir -p \"/c/Users/CHRIST~1/AppData/Local/Temp/claude/C--DEV-MasterArbeit-QuellCode-CentronERP/8d493a0f-f069-46a0-93de-8427787b311e/scratchpad/findings\"","description":"Ensure findings directory exists"}}],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":8,"requested":{"background":0,"foreground":8,"unset":0},"started_in_background":0,"max_depth":1,"spawned_by_subagents":0,"completed":4,"failed":4,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{"general-purpose":8}},"subtype":"success","api_error_status":429,"result":"You've hit your weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":1716122,"uuid":"4b5fe352-1035-4d7b-a25a-af4850c43257","queued_turn_count":0}
				`@@ -0,0 +1 @@`
				{"is_error":true,"duration_api_ms":0,"num_turns":1,"stop_reason":"stop_sequence","session_id":"af9be153-a3b0-427c-954b-615d562631fa","total_cost_usd":0,"usage":{"output_tokens_details":{"thinking_tokens":0},"input_tokens":0,"cache_creation_input_tokens":0,"cache_read_input_tokens":0,"output_tokens":0,"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":0,"ephemeral_5m_input_tokens":0},"inference_geo":"","iterations":[],"speed":"standard"},"modelUsage":{},"permission_denials":[],"terminal_reason":"api_error","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":429,"result":"You've hit your weekly limit · resets Aug 31, 7am (Europe/Berlin)","type":"result","duration_ms":457,"uuid":"10894110-3434-4adc-b7f0-6a0ee842f78a","queued_turn_count":0}
				`@@ -0,0 +1 @@`
				{"is_error":false,"duration_api_ms":2779209,"num_turns":217,"stop_reason":"end_turn","session_id":"4a31e82c-b2b8-43a5-9a37-d3dc63f94b58","total_cost_usd":12.223812800000006,"usage":{"input_tokens":290,"cache_creation_input_tokens":457428,"cache_read_input_tokens":37686579,"output_tokens":284916,"output_tokens_details":{"thinking_tokens":95123},"server_tool_use":{"web_search_requests":0,"web_fetch_requests":0},"service_tier":"standard","cache_creation":{"ephemeral_1h_input_tokens":457428,"ephemeral_5m_input_tokens":0},"inference_geo":"not_available","iterations":[{"input_tokens":2,"output_tokens":910,"cache_read_input_tokens":456874,"cache_creation_input_tokens":554,"cache_creation":{"ephemeral_5m_input_tokens":0,"ephemeral_1h_input_tokens":554},"type":"message"}],"speed":"standard"},"modelUsage":{"claude-haiku-4-5-20251001":{"inputTokens":6945,"outputTokens":20,"cacheReadInputTokens":0,"cacheCreationInputTokens":0,"webSearchRequests":0,"costUSD":0.007045,"contextWindow":200000,"maxOutputTokens":32000,"canonicalModel":"claude-haiku-4-5","provider":"firstParty","costBasis":"list"},"claude-sonnet-5":{"inputTokens":290,"outputTokens":284916,"cacheReadInputTokens":37686579,"cacheCreationInputTokens":457428,"webSearchRequests":0,"costUSD":12.216767800000005,"contextWindow":1000000,"maxOutputTokens":64000,"canonicalModel":"claude-sonnet-5","provider":"firstParty","costBasis":"list"}},"permission_denials":[],"terminal_reason":"completed","fast_mode_state":"off","fast_mode_disabled_reason":"extra_usage_disabled","subagent_stats":{"spawned":0,"requested":{"background":0,"foreground":0,"unset":0},"started_in_background":0,"max_depth":0,"spawned_by_subagents":0,"completed":0,"failed":0,"killed":{"parent":0,"user":0,"system":0},"refused":{"depth_limit":0,"concurrency_limit":0,"budget":0},"by_type":{}},"subtype":"success","api_error_status":null,"result":"The reverse requirements engineering specification for the c-entron ERP-Suite is complete. All seven deliverables are in `Ergebnisse/`:\n\nCoverage achieved:\n- Modulinventar (Schritt 0): 118 modules identified across the entire codebase (WPF desktop client, backend BL/DAO, webservice API, Nexus web frontend, external API integrations, data-exchange connectors, deployment) — 0 modules left unanalyzed\n- 136 requirements total: 118 StRS + 10 SyRS + 8 SwRS, with full forward/backward traceability\n- Risk-based deepening (Schritt 0c): 14 modules fully deepened across all three levels — rights management (found the actual group-based RBAC enforcement in `AppRightsBL.HasUserRight`), password vault AES encryption, dual ticket/access-token API authentication, dunning-stop logic, open-items/payment formulas, SEPA/DSGVO signature workflows\n- 29 risk-relevant requirements (security, billing, permissions) individually checked: 23 carry a PRIMÄR beleg, 6 are honestly marked `[HYPOTHESE]`\n- 23 consolidation candidates found with concrete evidence (e.g., a literal copy-paste artifact: the SEPA-mandate settings class still carries internal field names like `_declinedOrderProcessingContractSubject` left over from the DSGVO-AVV class it was cloned from)\n- Self-check caught and fixed 3 rule violations during the consistency pass — three security/billing requirements had only SEKUNDÄR evidence but were marked `belegt`; corrected to `HYPOTHESE` before finalizing\n\nThe codebase itself was only read, never modified (verified via `git status`).\n\nOne thing worth flagging to you directly: 86 of the 118 modules are at \"flach\" depth (one requirement, existence-level evidence only) — that's the explicit breadth-first tradeoff the prompt asked for, but it means modules like the 794-file `Finances/Receipts` core or the 320-file `ArticleManagement` still have far more to extract in a follow-up pass. That's called out concretely in the self-assessment.","ttft_ms":7192,"ttft_stream_ms":1124,"time_to_request_ms":36,"type":"result","duration_ms":2855005,"uuid":"0912e717-c040-47a4-8d5e-381952f58a7d","queued_turn_count":0}