iteration 8

2026-08-28 19:41:13 +02:00
parent 37275c96d6
commit 8a22d586f1
182 changed files with 34254 additions and 18 deletions
@@ -0,0 +1,12 @@
+[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
+[glm-kimi-adapter] Start: 2026-08-28T12:20:22.287761+00:00
+[glm-kimi-adapter] Provider: TensorX API Gateway
+[glm-kimi-adapter] Modell: moonshotai/kimi-k3
+[glm-kimi-adapter] Effort: high
+[glm-kimi-adapter] Mode: builtin
+[glm-kimi-adapter] Subagent 1/10 gestartet (Typ: explore)
+[glm-kimi-adapter] Subagent 2/10 gestartet (Typ: explore)
+[glm-kimi-adapter] Subagent 3/10 gestartet (Typ: explore)
+[glm-kimi-adapter] Subagent 4/10 gestartet (Typ: explore)
+[glm-kimi-adapter] Subagent 5/10 gestartet (Typ: explore)
+[glm-kimi-adapter] Subagent 6/10 gestartet (Typ: explore)
@@ -0,0 +1 @@
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,161 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nZusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.\nNicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only, max. 10)\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\builtin\high\03_Lauf_2026-08-28_125852_v8.0.0-ffe2\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-28T15:19:12.3726657+02:00
@@ -0,0 +1,9 @@
+{
+  "modell": "moonshotai/kimi-k3",
+  "iteration": "Iteration 8",
+  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
+  "promptVersion": "03",
+  "modus": "builtin",
+  "effort": "high",
+  "skillVersion": "v8.0.0"
+}
@@ -0,0 +1 @@
+2026-08-28T12:58:52.6902057+02:00
@@ -0,0 +1,20 @@
+[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
+[glm-kimi-adapter] Start: 2026-08-28T15:24:00.672781+00:00
+[glm-kimi-adapter] Provider: TensorX API Gateway
+[glm-kimi-adapter] Modell: moonshotai/kimi-k3
+[glm-kimi-adapter] Effort: high
+[glm-kimi-adapter] Mode: builtin
+[glm-kimi-adapter] Subagent 1/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 2/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 3/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 4/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 5/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 6/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 7/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 8/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 9/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent 10/10 gestartet (Typ: general-purpose)
+[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
+[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
+[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
+[glm-kimi-adapter] Subagent verweigert (Limit 10 erreicht)
@@ -0,0 +1 @@
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,161 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nZusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.\nNicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n- spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only, max. 10)\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\builtin\high\03_Lauf_2026-08-28_160956_v8.0.0-7247\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-28T19:06:18.4170924+02:00
@@ -0,0 +1,9 @@
+{
+  "modell": "moonshotai/kimi-k3",
+  "iteration": "Iteration 8",
+  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
+  "promptVersion": "03",
+  "modus": "builtin",
+  "effort": "high",
+  "skillVersion": "v8.0.0"
+}
@@ -0,0 +1 @@
+2026-08-28T16:09:57.0822828+02:00
@@ -0,0 +1,90 @@
+# Analysebericht – c-entron ERP-Suite (Reverse Requirements Engineering)
+
+**Stand:** Zwischenstand Schritt 0/0b – Modulinventar und Mindestabdeckung (Konsistenzcheck und Selbstbewertung folgen am Ende des Laufs in derselben Datei).
+
+## 1. Ausgangslage
+
+- Codebasis: c-entron ERP-Suite, C#/XAML (WPF), Blazor (Nexus), MSSQL, NHibernate.
+- Umfang: ~16.000 C#-Dateien (inkl. `obj`-Artefakte), davon ~2.068 in `Centron.BL`; Datenbankschema `SSMS_DB_SCHEMA.sql` mit **1.558 Tabellen** im Schema `dbo`.
+- Vorgehen: statische Analyse gemäß RRE-Methodenkette; Scope = gesamte Codebasis (Breite vor Tiefe).
+
+## 2. Modulinventar (Schritt 0)
+
+Bezugsgröße für die Abdeckung. Ebenen: **T** = technische Schicht/Komponente, **F** = fachliches Modul.
+
+| # | Modul / Komponente | Pfad | Fachliche Aufgabe |
+|---|---|---|---|
+| M01 (T) | WPF-Client (c-entron.NET) | `src/centron/Centron.WPF.UI` | Desktop-Frontend mit Ribbon, Modulen, Dialogen, Wizards |
+| M02 (T) | WPF-UI-Extension | `src/centron/Centron.WPF.UI.Extension` | Erweiterungspunkte des WPF-Clients |
+| M03 (T) | Business-Logik (BL) | `src/backend/Centron.BL` | Fachlogik aller Module (Entities <-> Regeln) |
+| M04 (T) | Datenzugriff (DAO/NHibernate) | `src/backend/Centron.DAO` | NHibernate-Sessions, Mappings, Transaktionen, NamedQueries |
+| M05 (T) | Entities/Domänenmodell | `src/backend/Centron.Entities` | Persistente Entitäten (PersistedEntity mit I3D-Schlüssel) |
+| M06 (T) | Common/Interfaces/Gateway | `src/backend/Centron.Common`, `Centron.Interfaces`, `Centron.Gateway` | Querschnitt (TextCoding, Result-Pattern), Schnittstellenverträge, EDI-Gateway-Anbindung |
+| M07 (T) | SOAP-Webservice & Hosts | `src/webservice/*` (Centron.WebServices.Core, Centron.Host, Centron.Host.WindowsService, Centron.Host.Console, Centron.Controllers, c-entron.misc.ConnectionManager) | Externer Webservice für Fremdanwendungen, Hosting als Windows-Dienst/Konsole |
+| M08 (T) | c-entron Nexus (Blazor Web) | `src/nexus/CentronNexus`, `CentronNexus.Host` | Webanwendung (ServiceBoard, WebCart, WebOffer, Management) |
+| M09 (T) | Nexus Outlook-AddIn | `src/nexus/CentronNexus.OutlookAddIn` | Einbettung von Nexus in Outlook |
+| M10 (T) | Shared Controls/Core | `src/shared/Centron.Controls`, `Centron.Core`, `Centron.Controls.Preview` | Gemeinsame UI-Controls und Basisfunktionen (z. B. GoogleAuthenticator) |
+| M11 (T) | Externe API-Anbindungen | `src/apis/*`, `Centron.Api.docuFORM` | Icecat, ITscope, C.O.P., EGIS, finAPI, GLS, Shipcloud, ebInterface, docuFORM |
+| M12 (T) | Deployment & Container | `docker/`, `deployment/`, `azure*/`, `scripts/` | Docker-Image (Alpine), WiX/WixSharp-Installer, Azure-Artefakte |
+| M13 (F) | Adressstamm / CRM | `src/backend/Centron.BL/CustomerArea`, `Accounts`; Entities `Accounts/*` | Kunden, Lieferanten, Adressen, Ansprechpartner, Aktivitäten, Kampagnen |
+| M14 (F) | Vertriebsbelegwesen | `Centron.BL/Sales/Receipts`; DbEntities `AngKopf/AufKopf/LiefKopf/RechKopf/GutKopf/AbholKopf` | Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholung, Belegversionen |
+| M15 (F) | Preise & Sonderkonditionen | Entities `Accounts/SpecialPrices`, `CustomerArea/CustomerDetails/CustomerSpecialPrice` | Kundenindividuelle Preise, Sonderaktionen |
+| M16 (F) | Vertragswesen & automatische Abrechnung | `Centron.BL/Sales/CustomerAssets/Contracts`, `AutomaticFactura`; DbEntities `VertragKopf/VertragPos` | Verträge, Kontingente, Click-Verträge, periodische Auto-Fakturierung |
+| M17 (F) | Helpdesk / Ticketing / Taskmanagement | `Centron.BL/Sales/Support`; WPF `Modules/Helpdesk` | Tickets, Kategorien, Prioritäten, Status, Checklisten, C-FLOW-Vorlagen |
+| M18 (F) | Zeiterfassung & Verrechnung | `Centron.BL/Sales/Support/HelpdeskTimer*`, `CustomerAssets/TimerBilling`, `Administration/HourlySurchargeRates` | Erfassung von Technikerzeiten, Signaturen, Verrechnung über Belege, Stundenzuschläge |
+| M19 (F) | Finanzwesen / Zahlungsverkehr | `Centron.BL/Finances`, `Sales/CashBooks`; Entities `Finances/*` | Zahlungsein-/ausgänge, Kassenbuch, Zahlungszuordnung |
+| M20 (F) | Online-Banking | `Centron.BL/Finances/OnlineBanking`; Entities `Finances/OnlineBanking/*` | Kontoumsatzabruf via FinTS/finAPI/Tabellen-Import, Umsatzzuordnung |
+| M21 (F) | Mahnwesen | DbEntities `Mahnlauf.cs`; Schema-Tabelle `Mahnlauf` | Mahnläufe zu überfälligen Rechnungen |
+| M22 (F) | SEPA | Entities `Administration/Documents/SepaContracts/*` | SEPA-Mandate und -Vorlagen |
+| M23 (F) | Einkauf | `Centron.BL/Purchasing`, `Buying`; Entities `Businesspartner/*`; DbEntities `AnfrKopf/BestKopf2/WareKopf` | Lieferantenanfrage, Bestellung, Wareneingang, Lieferantengutschrift, Lieferantenkalkulation/-buchung |
+| M24 (F) | Artikel-/Warenwirtschaft | DbEntities `ARTIK/WAREN/UNTERWAREN`, `Hersteller`, `ArtikelEinheit`, `Barcode`, `MwstSatz` | Artikelstamm, Warengruppen, Hersteller, Einheiten, Barcodes, MwSt.-Sätze |
+| M25 (F) | Lagerverwaltung | Entities `Logistics/Warehousing/Stock`, `StockRebookLog`, DbEntities `NebenlagerArtikel`, `SeriennummerToPosition` | Lagerbestände, Umbuchungen, Nebenläger, Seriennummern |
+| M26 (F) | Logistik / Versand | `src/apis/Centron.Api.Gls`, `Centron.Api.Shipcloud`; BL `Logistics` | Paketversand, Sendungsverfolgung |
+| M27 (F) | EDI / Datenaustausch / Buchhaltungsschnittstellen | Entities `EDI/*`, `DataExchange/*`; `Centron.BL/EDI`, `DataExchange` | EDI-Lieferungen/Rechnungen/Auftragsbestätigungen, Buchhaltungsexport/-import, Gateway-Logs |
+| M28 (F) | Kalender / Terminplanung | `Centron.BL/Calendar`; Rechte `RIGHT_KALENDER*` | Kalender, Termine, Mitarbeiterauslastung |
+| M29 (F) | Projektmanagement | Entities `ProjectArea/*`, `TicketProjects`; WPF `Modules/ProjectManagement` | Projekte, Projektstufen, Aufgaben, Jour-fixe-Termine, Ticket-Projekte |
+| M30 (F) | Produktion | Entities `Production/*`; WPF `Modules/Production` | Produktionsaufträge, Maschinen, Schritte, Betriebsdatenerfassung |
+| M31 (F) | RMA / Retouren | Entities `CustomerArea/RmaArea/*`; WPF `Modules/Rma` | Rücksendungen, Hin-/Rückversand, Artikelhistorie |
+| M32 (F) | PLM / Produktmatrix | `Centron.BL/Finances/ProductLifecycleBL.cs`; Entities `ProductMatrix/*`; WPF `Modules/PLM` | Produktlebenszyklen, Kunden-Produktmatrix mit Bewertungen |
+| M33 (F) | QM | WPF `Modules/QM` | Qualitätsmanagement |
+| M34 (F) | Geräte-/Asset-Verwaltung | Entities `Devices/AccountDevice*`, `Sales/CustomerAssets/Asset*`; DbEntities `GeraeteKopf/GeraetePos` | Kundengeräte, Assets, Stammblätter (doppelte Datenhaltung!) |
+| M35 (F) | Monitoring / DocuBoard | Schema `AssetManagement*`; Entities `DocuBoard/*` | SNMP-/Windows-Service-Monitoring, Check-Konfigurationen |
+| M36 (F) | Benutzer- & Rechteverwaltung | `Centron.BL/Administration/Logins`, `Rights`; `CentronRights.md`; Entities `Administration/App*` | AppUser, Authentifizierung (Basic/AD/OIDC), 2FA, granulare Rechte, Web-Accounts |
+| M37 (F) | DSGVO / Datensicherheit | `Centron.BL/Administration/DataSecurity`; Entities `Administration/Documents/Dsgvo/*` | Lösch-/Bereinigungsläufe, AV-Verträge, DSGVO-Marker |
+| M38 (F) | Mandanten & Filialen | Entities `Administration/Company/Mandator`, `BranchArea/Branch` | Mehrmandanten- und Filialfähigkeit |
+| M39 (F) | Nummernkreise | `Centron.BL/Administration/Company/NumberGroupBL.cs`; Entity `NumberGroup` | Nummernvergabe je Belegart/Filiale/Mandant |
+| M40 (F) | Dokumentenmanagement (DMS) | Entities `Administration/FileManagement/*` | Verzeichnisse, Dokumente, Thumbnails, DocSync, Shared Documents |
+| M41 (F) | E-Mail / Mailings / MailScanner / Chat | Entities `Mail/*`, `Mailings/*`, `MailScanner/*`, `Chats/*` | Mailvorlagen, Serienmails, eingehende Mail-Verarbeitung, interner Chat |
+| M42 (F) | Outlook-/TAPI-Integration | Entities `Outlook`, `Tapi`; `Centron.BL/Outlook`, `Tapi` | Kontaktsynchronisation, Telefonie-Wahlhilfe |
+| M43 (F) | Berichtswesen / ReportEngine / Statistik | Entities `ReportEngine/*`, `Reporting`; `Centron.BL/ReportEngine`, `Statistics`; WPF `Modules/Reports`, `Statistics` | Berichtsgruppen, Datenabfragen, Dashboards, Statistiken |
+| M44 (F) | MyDay / MyCentron / Notifications | Entities `MyDay/*`, `MyCentron/*`, `Notifications/*`, `NexusNotifications` | Tagesplanung, persönliches Dashboard, Benachrichtigungen |
+| M45 (F) | Web-Portal: WebCart / WebOffer / Web-Accounts | `src/nexus/CentronNexus/WebCart`, `WebOffer`; Entities `Administration/Logins/WebAccount*` | Kunden-Shop mit Sonderpreisen, Online-Angebote, Web-Logins |
+| M46 (F) | Passwort-Manager (Kundenkennwörter) | Entities `PasswordManagementArea/*`, `PasswordManager/*`; WPF `Modules/PasswordManager` | Verwaltung fremder Zugangsdaten mit Richtlinien und Zugriffslogs |
+| M47 (F) | Textbausteine | DbEntities `GeschaeftspartnerTextbausteine`; `Centron.BL/TextModuleArea` | Wiederverwendbare Textmodule |
+| M48 (F) | Volltext-/Indexsuche | Entities `Administration/IndexSearch/*`; `Centron.BL/IndexSearch` | Objekt- und Dokumentenvolltextindex |
+| M49 (F) | ChangeTracking / Historisierung | Entities `ChangeTracking/ChangeLog`; `Centron.DAO/ChangeTracking` | Änderungsprotokolle auf Entitäten |
+| M50 (F) | Mobile Anbindung | Entities `Mobile/*`; `Centron.BL/Mobile` | DTOs und Modulverwaltung für mobile App |
+| M51 (F) | Massenupdates | Entities `MassUpdate/*`; WPF `Modules/Massenupdates` | Selektive Massenänderungen, Preisupdates |
+| M52 (F) | Umfragen | Entities `Accounts/Survey/*`; WPF `Modules/Survey` | Kundenbefragungen |
+| M53 (F) | Gutscheine | `Centron.BL/VoucherManagement`; Entities `VoucherManagement` | Gutscheinverwaltung |
+| M54 (F) | KI-Integration | Entities `Administration/ArtificialIntelligence/*`; `Centron.BL/ArtificialIntelligence`; WPF `Modules/ArtificialIntelligence` | KI-Chats mit Prompt-Verwaltung und Tool-Aufrufen |
+| M55 (F) | Lizenzierung & Versionen | `Centron.BL/Administration/Licensing`, `Applications` | Lizenzprüfung bei Anmeldung, Versionskontrolle |
+| M56 (F) | Soziale Medien / Diverses | `Centron.BL/SocialMedia`, `VideoPortal`, `WebLinks`, `Urls`, `Tags`, `ToDoArea`, `RiverDivo`, `TelekomDive` | Social-Media-Streams, Videoportal, Weblinks, Tags, ToDos, Telekom-Dive |
+
+Inventar-Stand: 56 Einträge, davon 12 technisch (T) und 44 fachlich (F). Ergänzungen im Verlauf: keine Kürzungen.
+
+## 3. Mindestabdeckung (Schritt 0b)
+
+Wird nach Fertigstellung der Anforderungen als Abdeckungstabelle (Abschnitt 4) ausgewiesen. Ziel: jedes Modul ≥ 1 Anforderung; `nicht analysiert` < 10 %.
+
+## 4. Abdeckungstabelle
+
+*(wird am Laufende ergänzt)*
+
+## 5. Konsistenzcheck
+
+*(wird am Laufende ergänzt)*
+
+## 6. Selbstbewertung
+
+*(wird am Laufende ergänzt)*
@@ -0,0 +1,13 @@
+[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
+[glm-kimi-adapter] Start: 2026-08-28T11:35:48.411192+00:00
+[glm-kimi-adapter] Provider: TensorX API Gateway
+[glm-kimi-adapter] Modell: moonshotai/kimi-k3
+[glm-kimi-adapter] Effort: high
+[glm-kimi-adapter] Mode: solo
+[glm-kimi-adapter] Ende: 2026-08-28T12:16:57.275888+00:00
+[glm-kimi-adapter] Turns: 44
+[glm-kimi-adapter] Tokens gesamt: 3,208,550
+[glm-kimi-adapter] Tool-Calls: 68
+[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
+[glm-kimi-adapter] Ergebnisdateien: 1
+[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-593a\RawResult.json
@@ -0,0 +1 @@
+
@@ -0,0 +1 @@
+[]
@@ -0,0 +1,4 @@
+## Gefundene Anforderungen
+
+Keine Anforderungen im vorgegebenen Format gefunden.
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,161 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\n\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_125852_v8.0.0-593a\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-28T14:16:57.3103502+02:00
@@ -0,0 +1,9 @@
+{
+  "modell": "moonshotai/kimi-k3",
+  "iteration": "Iteration 8",
+  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
+  "promptVersion": "03",
+  "modus": "solo",
+  "effort": "high",
+  "skillVersion": "v8.0.0"
+}
@@ -0,0 +1 @@
+2026-08-28T12:58:52.5369951+02:00
@@ -0,0 +1,364 @@
+# StRS – Stakeholder Requirements Specification
+## c-entron ERP-Suite (Reverse Requirements Engineering)
+
+Basis: statische Analyse der Codebasis (C#/XAML/MSSQL, ca. 2064 C#-Dateien allein in `Centron.BL`, DB-Schema mit 1558 Tabellen).
+Domäne (belegt durch Modulstruktur, CentronRights.md, README.md): Integriertes ERP für ITK-Systemhäuser / Managed Service Provider – Warenwirtschaft, Service, Vertragsabrechnung, Finanzen, IT-Dokumentation.
+
+**Stakeholder / Akteure** (abgeleitet aus `CentronRights.md`-Rollenrechten, `README.md` „Contributing/WebCart", `ReceiptBL.GetReceiptByI3D` Web-Account-Prüfung):
+
+| Akteur | Beschreibung |
+|---|---|
+| Vertriebsmitarbeiter (Innen-/Außendienst, `Adviser1/Adviser2`) | Angebote, Aufträge, CRM |
+| Techniker / Support-Mitarbeiter | Helpdesk-Tickets, Zeiterfassung, RMA |
+| Disponent / Lagerist | Lager, Seriennummern, Kommissionierung |
+| Einkäufer | Lieferantenbestellungen, EDI |
+| Buchhalter | Rechnungen, Mahnwesen, DATEV-Export, Online-Banking |
+| Vertragsmanager | Klick-/Kontingent-/Serviceverträge, automatische Abrechnung |
+| Administrator | Benutzer, Rechte, Einstellungen, Mandanten/Filialen |
+| Web-Kunde (Kunde des Systemhauses, „WebAccount") | Portalzugang: Tickets, Belege, WebCart-Shop |
+| Externe Systeme | DATEV, FinAPI-Banken, EDI-Distributoren, ITscope/ICEcat, OpenAI, Entra ID |
+
+---
+
+```
+ID:            StRS-001
+Titel:         Integrierte ERP-Gesamtlösung für ITK-Systemhäuser
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Gesamtunternehmen
+Vorbedingung:  Systemhaus nutzt c-entron als zentrales ERP
+Fakt:          Die Codebasis umfasst >60 fachliche BL-Module von Warenwirtschaft über Helpdesk bis DATEV-Export und Online-Banking (Verzeichnisstruktur src/backend/Centron.BL/*).
+Aussage:       Das System soll die kaufmännischen, servicetechnischen und finanziellen Kernprozesse eines IT-Systemhauses in einer integrierten Datenbasis abbilden, ohne Medienbruch zwischen Vertrieb, Service, Lager, Einkauf und Finanzen.
+Ergebnis:      Alle Fachbereiche arbeiten auf denselben Entitäten (Kunden, Artikel, Belege, Geräte).
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ (Modulverzeichnisse Sales, Warehousing, Purchasing, Finances, Accounting, Helpdesk-Bereiche) - Begründung: Modulstruktur dokumentiert den fachlichen Gesamtumfang durchgesetzter Funktionalität.
+  - [KONTEXT]  README.md, CentronRights.md - Begründung: beschreiben Einsatzszenario (WebCart für Kunden der Kunden) und Rollenrechte der Fachbereiche.
+Prüfidee:      Durchstich Angebot → Auftrag → Lieferschein → Rechnung → Mahnung → DATEV-Export ohne manuelle Datenerfassung dazwischen.
+Tracelinks:    SyRS-001, SyRS-008
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernzweck des Systems.
+Status:        belegt
+```
+
+```
+ID:            StRS-002
+Titel:         Kunden- und Lieferantenstamm (Adressstamm)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter, Buchhalter, Einkäufer
+Vorbedingung:  Stammdaten werden angelegt und gepflegt
+Fakt:          Entitäten CustomerDetail, CustomerFinanceInfo, Kreditor; Nummernvergabe aus Nummernkreis (NumberGroupEnum.Customer/Supplier); Finanzinfo enthält Zahlungs-/Lieferkonditionen, Sammelkonto, Mahnstatus.
+Aussage:       Das System soll einen zentralen Adressstamm für Kunden und Lieferanten führen, inkl. Adressen, Ansprechpartnern, Finanzkonditionen und kundenspezifischer Preis-/Rabattvereinbarungen (Sonderpreise).
+Ergebnis:      Belege, Verträge und Finanzprozesse greifen konsistent auf dieselben Geschäftspartnerdaten zu.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Customers/CustomerDetail.cs, CustomerFinanceInfo.cs - Begründung: persistierte Datenstruktur des Kundenstamms.
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs (NumberGroupEnum.Customer/Supplier) - Begründung: durchgesetzte Nummernvergabe für Geschäftspartner.
+  - [KONTEXT]  README.md („Sonderpreise" im Adressstamm steuern WebCart-Sortiment) - Begründung: fachliche Nutzung des Kundenstamms für Shop-Preise.
+Prüfidee:      Neuanlage Kunde erhält nächste Nummer aus Nummernkreis; Sonderpreis-Artikel erscheinen im WebCart des Kunden.
+Tracelinks:    SyRS-004, SyRS-024
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernstammdaten.
+Status:        belegt
+```
+
+```
+ID:            StRS-003
+Titel:         Angebots- und Auftragsabwicklung (Belegkette)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertriebsmitarbeiter
+Vorbedingung:  Kunde und Artikelstamm vorhanden
+Fakt:          ReceiptBL.ForwardReceipt verarbeitet Belege positionsweise von einer Belegart in die nächste (Angebot→Auftrag→Lieferschein→Rechnung/Gutschrift), inkl. Validierung (gleicher Kunde, keine Mischung Kunden-/Lieferantenbelege, Filialregeln).
+Aussage:       Das System soll Vertriebsbelege (Angebot, Auftrag/Bestellung, Lieferschein, Abholschein, Rechnung, Gutschrift, Vertragsliste) anlegen, versionieren und ohne Neuerfassung in Folgebelege weiterverarbeiten.
+Ergebnis:      Lückenlose, nachvollziehbare Beleghistorie vom Angebot bis zur Rechnung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ForwardReceipt, ValidateReceiptForwarding, GetReceiptForwardedFrom/Into) - Begründung: durchgesetzte Weiterverarbeitungslogik inkl. Sperrregeln.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs - Begründung: durchgesetzte Belegzustände offen/abgeschlossen/storniert.
+Prüfidee:      Angebot anlegen, in Auftrag weiterverarbeiten, partiell in Lieferschein und Rechnung weiterverarbeiten; Historie zeigt Herkunft je Position.
+Tracelinks:    SyRS-001, SyRS-002, SyRS-003
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kerngeschäft Vertrieb.
+Status:        belegt
+```
+
+```
+ID:            StRS-004
+Titel:         Fakturierung und Mahnwesen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Buchhalter
+Vorbedingung:  Rechnungen vorhanden, teils unbezahlt überfällig
+Fakt:          DunningRunBL hebt Mahnstufen None→1→2→3 mit Datum und Sachbearbeiter an, erzeugt Mahnläufe mit fortlaufender Mahnlaufnummer, Report-Gruppe MAHNUNG und optional E-Mail-Versand; ResetDunningRun macht Läufe rückgängig (Status Deleted).
+Aussage:       Das System soll Rechnungen (inkl. Anzahlungs-/Schlussrechnungen, Bar-/Kassenrechnungen) erstellen, Eingangszahlungen verrechnen und überfällige Forderungen in einem dreistufigen, nachvollziehbaren Mahnlauf anmahnen; Kunden lassen sich ab einer Mahnstufe für neue Belege sperren.
+Ergebnis:      Rechtssicher nachvollziehbare Forderungsverfolgung inkl. Mahndokument (PDF/E-Mail) und Sperrlogik.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs (ExecuteDunningRunInternal, SaveDunningRun, ResetDunningRun) - Begründung: durchgesetzte Mahnstufen-Transitionslogik mit Protokoll (DunningRunItem Old/NewDunningLevel).
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs:723 (BlockNewReceiptsDunningLevel) + AppSettingsConst.CustomerAssetsLockedAfterDunningLevel - Begründung: durchgesetzte Belegsperre ab Mahnstufe aus Einstellung.
+Prüfidee:      Überfällige Rechnung mahnen → Stufe 1 mit Datum/Sachbearbeiter; Mahnlauf zurücksetzen → Stufe zurück und Lauf als Deleted markiert.
+Tracelinks:    SyRS-007
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - gesetzlich/fachlich notwendig.
+Status:        belegt
+```
+
+```
+ID:            StRS-005
+Titel:         Vertragsmanagement mit automatischer Abrechnung (Klick-/Kontingent-/Serviceverträge)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Vertragsmanager, Buchhalter
+Vorbedingung:  Kunde besitzt verwaltete Geräte (Stammblätter)
+Fakt:          Entitäten Contract, ContractType, ContractContigentPositions, AutomaticFacturaContract/CounterHistory, DeviceClickCounter; Verträge referenzieren Stammblätter; Kündigungsarten (TerminationType) vorhanden; Stammblatt-Löschung gesperrt bei aktivem Vertrag.
+Aussage:       Das System soll Rahmenverträge mit Kontingenten und zählerbasierter Abrechnung (Seitenpreis je Gerät bzw. Stammblatt) verwalten, Zählerstände importieren und daraus periodische Abrechnungspositionen automatisch erzeugen.
+Ergebnis:      Vertragliche Leistungen werden termingerecht und mengentreu abgerechnet.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/CustomerAssets/Contracts/Contract.cs, ClickContracts/DeviceClickCounter.cs, AutomaticFactura/AutomaticFacturaContract.cs - Begründung: persistierte Vertrags-/Zählerdatenstrukturen.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 („Stammblatt ist einem aktiven Vertrag zugeordnet.") - Begründung: durchgesetzte Abhängigkeitsprüfung Vertrag↔Stammblatt.
+Prüfidee:      Vertrag mit 2 Stammblättern und Zählerständen abrechnen → Abrechnungspositionen je Zählerdifferenz; Stammblatt mit aktivem Vertrag kann nicht gelöscht werden.
+Tracelinks:    SyRS-001, SwRS-018, SwRS-019
+Konsolidierung: Kandidat: VertragKopf (Legacy-DbEntity) vs. Contracts-Namensraum (siehe SwRS-065)
+Übernahmewürdigkeit: übernehmen - Kerngeschäft MSP.
+Status:        belegt
+```
+
+```
+ID:            StRS-006
+Titel:         Geräte- und Assetverwaltung beim Kunden (Stammblätter, Assets)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Techniker, Vertragsmanager, Vertrieb
+Vorbedingung:  Geräte wurden verkauft oder in Betreuung übernommen
+Fakt:          „Stammblätter" (MasterDataList, DB-Tabelle GeraeteKopf) führen Kundengeräte mit Seriennummern und Zubehör; parallel existiert CustomerAsset als eigene Asset-Datenhaltung; Seriennummerntausch am Stammblatt ist rechtegeschützt und protokolliert.
+Aussage:       Das System soll kundenseitige Geräte/Stammdatenblätter und sonstige Assets verwalten, sie Belegen, Tickets und Verträgen zuordnen und Änderungen an Seriennummern rechtegesichert und nachvollziehbar protokollieren.
+Ergebnis:      Jederzeit richtige Geräteinformation für Service und Abrechnung.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs (Seriennummern-Entfernen/Tauschen, Historieneintrag Zeile 410) - Begründung: durchgesetzte Gerätestammlogik.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/MasterDataLists/MasterDataListWebServiceBL.cs:173 („Fehlende Rechte ...", DefaultMessageCodes.RightCheckFailed) - Begründung: durchgesetzte Rechteprüfung Seriennummernänderung.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/CustomerAssets/CustomerAsset.cs - Begründung: zweite, getrennte persistente Asset-Datenhaltung.
+Prüfidee:      Seriennummer am Stammblatt ohne Recht tauschen → Fehler RightCheckFailed; mit Recht → Historieneintrag vorhanden.
+Tracelinks:    SyRS-011, SwRS-015, SwRS-016
+Konsolidierung: Kandidat: Stammblätter (MasterDataList/GeraeteKopf) und CustomerAsset sind zwei Datenhaltungen für „Kundengerät" → zu vereinheitlichen
+Übernahmewürdigkeit: übernehmen - Kerndaten für Servicegeschäft.
+Status:        belegt
+```
+
+```
+ID:            StRS-007
+Titel:         Helpdesk-/Ticketmanagement mit Zeiterfassung
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Techniker, Support, Disponent
+Vorbedingung:  Kunde meldet Anliegen; ggf. Vertrag/Leistung hinterlegt
+Fakt:          Entitäten Helpdesk (Ticket), HelpdeskTimer (Zeiten mit BillingState, Unterschrift), Eskalationen, SupportLevel; umfangreiches Rechtemodell (CentronRights.md Abschnitt Helpdesk: Sichtbarkeit, eigene/Filiale, Zeiten, Fälligkeit, Schließen).
+Aussage:       Das System soll Tickets mit Kategorien, Zuständigkeiten, Fälligkeiten und Eskalationen verwalten, Arbeitszeiten inkl. Zusatzartikel und Unterschrift erfassen und diese vertragsgerecht (Leistung/Vertrag/Stammblatt-Bindung) abrechenbar machen.
+Ergebnis:      Serviceleistungen sind geplant, dokumentiert und abrechnungsfähig.
+Belege:
+  - [PRIMÄR]   CentronRights.md (Helpdesk-Rechte 1–18 inkl. restriktiver Rechte) - Begründung: dokumentiertes, im Code referenziertes Rechtemodell (UserRightsConst...).
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Support/HelpdeskTimerArea/HelpdeskTimer.cs, HelpdeskTimerBillingState.cs, Escalation/Escalations.cs - Begründung: persistierte Ticket-/Zeit-/Eskalationsstrukturen.
+  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs (Leistung diktiert Vertrag/Stammblatt, Zeilen 782–860) - Begründung: durchgesetzte Bindungslogik Zeit↔Leistung/Vertrag/Stammblatt.
+Prüfidee:      Zeit auf Ticket mit Leistung buchen → Vertrag und Stammblatt automatisch gebunden; Umverschieben der Zeit auf anderes Ticket nur losgelöst möglich (gem. Dialoglogik).
+Tracelinks:    SyRS-011, SwRS-020, SwRS-021, SwRS-022
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kerngeschäft Service.
+Status:        belegt
+```
+
+```
+ID:            StRS-008
+Titel:         Lagerverwaltung mit Seriennummern und Inventur
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Disponent, Lagerist
+Vorbedingung:  Artikel und Lagerorte definiert
+Fakt:          Module Warehouse/StockManagement, InventoryManagement, CommissioningManagement; Barcode/Seriennummern mit Zustandsautomaten (u. a. „im Lager", „in Stammblatt", „in Beleg"); Umbuchung auf Stammblatt nur erlaubt, wenn Seriennummer „im Lager".
+Aussage:       Das System soll Lagerbestände je Lager/Filiale führen, Seriennummern über ihre Lebenszyklen verfolgen, Warenein-/ausgänge buchen, Kommissionierungen unterstützen und Inventuren ermöglichen.
+Ergebnis:      Lagerbestand und Seriennummernverbleib sind jederzeit wahrheitsgemäß.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 („... kann nicht auf das Stammblatt umgebucht werden. Diese befindet sich nicht mehr 'im Lager'") - Begründung: durchgesetzte Zustandsregel für Seriennummern.
+  - [PRIMÄR]   src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs (Zustände inkl. „in Stammblatt") - Begründung: definierter Zustandsautomat.
+  - [SEKUNDÄR] Verzeichnisse src/backend/Centron.BL/Warehousing/{StockManagement,InventoryManagement,CommissioningManagement} - Begründung: zeugen von Bestands-, Inventur- und Kommissionierfunktion.
+Prüfidee:      Seriennummer aus Belegentnahme ist nicht mehr „im Lager" → Umbuchung auf Stammblatt wird mit Fehlermeldung abgelehnt.
+Tracelinks:    SyRS-016, SwRS-017, SwRS-043
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion Handel.
+Status:        belegt
+```
+
+```
+ID:            StRS-009
+Titel:         Einkauf und Beschaffung inkl. Distributor-Integrationen
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Einkäufer
+Vorbedingung:  Lieferanten und Artikel angelegt
+Fakt:          Module Purchasing (Lieferantenbestellungen, Bestellvorschläge, filialspezifische Bestellungen), Gateway-EDI-Adapter für Distributoren (ALSO, AlsoCH, Alltron, EGIS, Komsa, Herweck, Concerto) sowie OpenTrans 1.0/2.1; Lieferantenbelege: Bestellung, Wareneingang (SupplierDeliveryList), Eingangsrechnung, -gutschrift.
+Aussage:       Das System soll Bestellvorschläge generieren, Lieferantenbestellungen auslösen, Wareneingänge und Eingangsrechnungen erfassen sowie Katalog- und Bestellprozesse elektronisch mit IT-Distributoren abwickeln (EDI/OpenTrans).
+Ergebnis:      Beschaffung von der Bedarfsermittlung bis zur Eingangsrechnungsprüfung ohne Medienbruch.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Gateway/{EDI_Also,EDI_Alltron,EDI_EGIS,EDI_Komsa,EDI_Herweck,OpenTrans,OpenTrans1_0} - Begründung: implementierte Distributor-EDI-Adapter.
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Receipts/SupplierOrders/ReceiptSupplierOrder.cs, ReceiptSupplierOrderIntake.cs - Begründung: persistierte Lieferantenbelegstrukturen.
+  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing/OrderSuggestionList/, SupplierOrderPerBranchBL.cs - Begründung: Bestellvorschlags- und Filialbestellfunktion.
+Prüfidee:      Bestellung an ALSO via EDI versenden; Wareneingang bucht Bestand und erzeugt SupplierDeliveryList; Eingangsrechnung (ggf. ZUGFeRD-Import) zugeordnet.
+Tracelinks:    SyRS-016, SyRS-017, SwRS-041, SwRS-042
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Kernfunktion IT-Handel.
+Status:        belegt
+```
+
+```
+ID:            StRS-010
+Titel:         Finanzschnittstellen (Buchhaltungsexport, Online-Banking)
+Ebene:         StRS
+Typ:           Schnittstelle
+Qualitätsmerkmal:
+Akteur:        Buchhalter, Steuerberater (extern)
+Vorbedingung:  Belege gebucht; Exportformat konfiguriert
+Fakt:          BookKeepingExportBL unterstützt 13 Exportformate (DATEV ASCII, DATEV XML-Online 2012/2020, Lexware, Sage 50/Office Line, SAP, Abacus, Navision, Addison, GDI, Europa3000, Schilling AS400, freie Schnittstelle); DATEV-Belegtransfer ist lizenzpflichtig (LicenseGuids.DatevOnline); OnlineBanking über FinAPI mit Bankverbindungen und Umsatzabruf.
+Aussage:       Das System soll Buchungsdaten (Debitoren/Kreditoren, deren Belege, Kassenbuch) in gängigen Buchhaltungsformaten exportieren, Exporte als übertragen markieren und Bankumsätze elektronisch abrufen/zuordnen.
+Ergebnis:      Finanzbuchhaltung und Bankabgleich erfolgen ohne manuelle Belegerfassung im Buchhaltungssystem.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/DataExchange/BookKeeping/BookKeepingExportBL.cs (InvokeExportClass; Zeilen 1564–1565 Lizenzprüfung DatevOnline) - Begründung: durchgesetzte Exportformatauswahl und Lizenzgate.
+  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/{OnlineBankingAccountTransactionsBL.cs, OnlineBankingFinApiBL.cs} + src/apis/Centron.APIs.FinAPI - Begründung: implementierte Bankanbindung.
+Prüfidee:      Export DATEV ASCII für Zeitraum → Datei + Belege als transferiert markiert; Export ohne DatevOnline-Lizenz → Fehler LicenseNotFound.
+Tracelinks:    SyRS-008, SyRS-009, SwRS-035
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Pflichtschnittstellen für Steuerberatung.
+Status:        belegt
+```
+
+```
+ID:            StRS-011
+Titel:         IT-Dokumentation der Kundeninfrastruktur
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Techniker
+Vorbedingung:  Kunde in Betreuung
+Fakt:          Entities DocumentationWizardArea (ActiveDirectory, BackupAndRestore, Machine, MailServer, NetworkComponent inkl. Drucker/Firewall/Router/Switch-Subtypen, NetworkStructure mit DHCP/DNS/NTP/WINS); separater PasswortManager für Kundenzugangsdaten (AES-verschlüsselt).
+Aussage:       Das System soll die IT-Umgebung des Kunden (Netzstruktur, Server, Mail, AD, Backup, Zugangsdaten) strukturiert dokumentieren und vertrauliche Zugangsdaten verschlüsselt ablegen.
+Ergebnis:      Serviceeinsätze können auf aktueller Kundendokumentation aufsetzen; Geheimnisse sind geschützt.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/DocumentationWizardArea/*.cs - Begründung: persistierte Dokumentationsdatenstruktur.
+  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs (AESCryptoLogic Encrypt/Decrypt mit MasterKey) - Begründung: durchgesetzte Verschlüsselung von Kennwörtern.
+Prüfidee:      Kunden-Passwort im Passwortmanager speichern → Datensatz enthält ValueEncryptedString (kein Klartext); Anzeige nur nach Entschlüsselung mit Master-Key.
+Tracelinks:    SyRS-015, SwRS-010
+Konsolidierung: Kandidat: PasswordManager vs. PasswordManagementArea (zwei Verzeichnisse) – SwRS-010
+Übernahmewürdigkeit: übernehmen - IT-Doku ist Kernnutzen für MSP.
+Status:        belegt
+```
+
+```
+ID:            StRS-012
+Titel:         Arbeitsorganisation und Kollaboration (Kalender, Aufgaben, Chat, E-Mail, MyDay)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        alle Mitarbeiter
+Vorbedingung:  Benutzer angelegt
+Fakt:          Kalender-Entities (Schedule, Urlaub ScheduleVacation mitsamt Log, Serientermine, Gruppen); ToDo/Wiedervorlage; Taskmanagement; Chat; Mail-Subsystem (Exchange, Protokolle, Templates, Blacklist); MyDay-Aggregation; Rechte für „nur eigene Kalender"/„nur eigene Filiale".
+Aussage:       Das System soll Mitarbeitern gemeinsame Kalender inkl. Urlaubsplanung, Aufgaben-/Wiedervorlagen, internen Chat, E-Mail-Anbindung und eine Tagesübersicht (MyDay) bereitstellen, jeweils rechtebeschränkt.
+Ergebnis:      Tagesarbeit ist im System plan- und dokumentierbar.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.Entities/Entities/Sales/Calendar/*.cs (ScheduleVacationDaysLog u. a.) - Begründung: persistierte Kalenderstruktur inkl. Historie.
+  - [PRIMÄR]   CentronRights.md (Kalender: RIGHT_KALENDERANZEIGENEIGENE als restrictendes Recht) - Begründung: dokumentierte Sichtbarkeitsregeln.
+  - [SEKUNDÄR] src/backend/Centron.BL/{ToDoArea,TaskManager,Chats,Mail,MyDay} - Begründung: Modulumfang Arbeitsorganisation.
+Prüfidee:      Mitarbeiter mit Recht RIGHT_KALENDERANZEIGENEIGENE sieht nur eigene Termine; Urlaubsänderung erzeugt Logeintrag.
+Tracelinks:    SyRS-011, SyRS-023, SwRS-023..SwRS-031
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Orgafunktionen, teils Konkurrenz zu Outlook-Standardfunktionen (im Zielsystem Abgrenzung prüfen).
+Status:        belegt
+```
+
+```
+ID:            StRS-013
+Titel:         Reporting, Statistiken und Belegdokumente
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Management, Vertrieb, Buchhaltung
+Vorbedingung:  Geschäftsdaten vorhanden
+Fakt:          ReportEngine (FastReport, PDF-Export, Reportgruppen-GUIDs, Vorlage je Mandant), Statistikmodule (MSP-Statistiken, Ticket-/Umsatzstatistiken), Beleg-PDF-Erzeugung inkl. Archivierung und PDF-Signatur.
+Aussage:       Das System soll Geschäftsauswertungen und druckbare Belege (Angebot, Rechnung, Mahnung, Stammblatt …) aus konfigurierbaren Reportvorlagen erzeugen, Beleg-PDFs revisionssicher archivieren und optional signieren.
+Ergebnis:      Entscheidungsrelevante Auswertungen und rechtssichere Belegdokumente liegen vor.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/ReportEngine/{ReportDataBL.cs, ReportGroupBL.cs, FastReportHelper.cs} - Begründung: implementierte Report-Infrastruktur.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (ArchivePdf, CreateFullReportForReceipt, PdfSigningBL-Aufruf) - Begründung: durchgesetzte Archivierung/Signatur beim Rechnungsversand.
+Prüfidee:      Rechnung per E-Mail versenden → PDF archiviert (ArchivePdf) und bei aktivierter Signatur signiert.
+Tracelinks:    SyRS-019, SyRS-005, SwRS-033, SwRS-034
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Pflicht (Archivierung) und Mehrwert (Statistik).
+Status:        belegt
+```
+
+```
+ID:            StRS-014
+Titel:         Webportale für Endkunden (Nexus, WebCart, Customer Portal)
+Ebene:         StRS
+Typ:           funktional
+Qualitätsmerkmal:
+Akteur:        Web-Kunde (Kunde des Systemhauses)
+Vorbedingung:  WebAccount im Adressstamm angelegt; Sonderpreise gepflegt
+Fakt:          CentronNexus (Blazor Server) mit eigenem Login für Web-Accounts; WebCart-Shop zeigt Kunden-Sonderpreise; Customer Portal lauscht auf getrenntem Port; WebAccount-Logins sehen ausschließlich eigene Kundendaten (serverseitige Filterung in ReceiptBL.GetReceiptByI3D).
+Aussage:       Das System soll Endkunden einen Webzugang zu ihren Tickets, Belegen und einem Shop mit kundenindividuellen Preisen bieten, wobei ein Web-Kunde niemals Daten anderer Kunden sieht.
+Ergebnis:      Self-Service für Endkunden bei strikter Mandantentrennung auf Kundenebene.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (GetReceiptByI3D: WebAccount.CustomerI3D-Abgleich, sonst null) - Begründung: durchgesetzte serverseitige Datenzugriffsbeschränkung.
+  - [PRIMÄR]   src/nexus/CentronNexus.Host/Program.cs (Port-Authorization HostPort vs. CustomerPortalPort; WebAccount-Rechte-Authorization) - Begründung: durchgesetzte Mandanten-/Porttrennung.
+  - [KONTEXT]  README.md („WebCart … customers of our customers … Sonderpreise") - Begründung: fachlicher Zweck des Shops.
+Prüfidee:      Als Web-Account von Kunde A die URL einer Rechnung von Kunde B aufrufen → keine Daten (null/403), auch bei direktem API-Aufruf.
+Tracelinks:    SyRS-024, SyRS-025, SyRS-014
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - zentraler Bestandteil der SaaS-Zielarchitektur.
+Status:        belegt
+```
+
+```
+ID:            StRS-015
+Titel:         Rollenbasiertes Berechtigungsmodell mit restriktiven Rechten
+Ebene:         StRS
+Typ:           Sicherheit
+Qualitätsmerkmal: Sicherheit (ISO 25010)
+Akteur:        Administrator
+Vorbedingung:  Benutzer und Rechtegruppen angelegt
+Fakt:          Rechte werden als Konstanten-Hierarchie (UserRightsConst) geführt; es gibt gewährende und „restricting rights" (z. B. SHOW_HELPDESK_ONLY_OWN); Prüfung serverseitig via AppRightsBL.HasUserRight.
+Aussage:       Das System soll Funktionen und Datenbereiche über ein feingranulares Rechtemodell steuern, das sowohl Zuwachs- als auch Beschränkungsrechte (nur eigene/eigene Filiale/eigene Abteilung) unterstützt; Rechte werden serverseitig durchgesetzt.
+Ergebnis:      Benutzer sehen und ändern nur, was ihre Rolle erlaubt; Admin kann restriktive Profile abbilden.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:644 (HasUserRight(int appUserI3D, int rightID)) - Begründung: durchsetzende Stelle der Rechteprüfung.
+  - [PRIMÄR]   CentronRights.md (Definition gewährende vs. restricting rights mit Konstanten) - Begründung: verbindliche Rechtesemantik, direkt auf UserRightsConst referenzierend.
+Prüfidee:      Benutzer mit SHOW_HELPDESK_ONLY_OWN erhält in Ticketliste nur Tickets mit eigener Bearbeiter-/Verantwortlichenrolle.
+Tracelinks:    SyRS-011, SyRS-012
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Pflicht für Mehrbenutzerbetrieb und SaaS-Mandanten.
+Status:        belegt
+```
+
+```
+ID:            StRS-016
+Titel:         Mandanten- und Filialfähigkeit
+Ebene:         StRS
+Typ:           nicht-funktional
+Qualitätsmerkmal: Übertragbarkeit / Anpassbarkeit (ISO 25010)
+Akteur:        Administrator, Unternehmensgruppe
+Vorbedingung:  mehrere Mandanten/Filialen eingerichtet
+Fakt:          Nummernkreise sind mandanten-/filialspezifisch mit Fallback-Kette Mitarbeiter→Filiale→Default-Mandant (MandatoryBL); Belege tragen BranchI3D; Sammelbelege über Filialen hinweg nur für dafür freigegebene Belegarten; Reportvorlagen mandantbezogen.
+Aussage:       Das System soll mehrere Mandanten und Filialen mit eigenen Nummernkreisen, Benutzersichten und Belegzuordnungen unterstützen, inkl. konfigurierbarer Regeln für filialübergreifende Sammelbelege.
+Ergebnis:      Konzernstrukturen sind abbildbar, Nummernkreise bleiben je Filiale lückenlos.
+Belege:
+  - [PRIMÄR]   src/backend/Centron.BL/Administration/Mandatory/MandatoryBL.cs (GetNumberGroupFromEmployee/Branch/DefaultMandator) - Begründung: durchgesetzte Fallback-Hierarchie der Nummernkreise.
+  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (Region „Branch" im ValidateReceiptForwarding; SupportsMultipleBranches) - Begründung: durchgesetzte Filialregel für Sammelbelege.
+Prüfidee:      Rechnung in Filiale B anlegen → Nummer aus Filiale-B-Kreis; zwei Belege unterschiedlicher Filialen in nicht-mehrfachfilialfähige Belegart → Fehlermeldung.
+Tracelinks:    SyRS-004, SyRS-026
+Konsolidierung: nein
+Übernahmewürdigkeit: übernehmen - Voraussetzung für SaaS-Mandantenfähigkeit.
+Status:        belegt
+```
@@ -0,0 +1,13 @@
+[glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
+[glm-kimi-adapter] Start: 2026-08-28T14:10:03.971728+00:00
+[glm-kimi-adapter] Provider: TensorX API Gateway
+[glm-kimi-adapter] Modell: moonshotai/kimi-k3
+[glm-kimi-adapter] Effort: high
+[glm-kimi-adapter] Mode: solo
+[glm-kimi-adapter] Ende: 2026-08-28T15:18:47.346573+00:00
+[glm-kimi-adapter] Turns: 27
+[glm-kimi-adapter] Tokens gesamt: 1,473,405
+[glm-kimi-adapter] Tool-Calls: 67
+[glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
+[glm-kimi-adapter] Ergebnisdateien: 1
+[glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_160956_v8.0.0-281c\RawResult.json
@@ -0,0 +1 @@
+
@@ -0,0 +1 @@
+
@@ -0,0 +1,161 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\n\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_160956_v8.0.0-281c\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
+2026-08-28T17:18:47.3861702+02:00
@@ -0,0 +1,9 @@
+{
+  "modell": "moonshotai/kimi-k3",
+  "iteration": "Iteration 8",
+  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
+  "promptVersion": "03",
+  "modus": "solo",
+  "effort": "high",
+  "skillVersion": "v8.0.0"
+}
@@ -0,0 +1 @@
+2026-08-28T16:09:56.9053311+02:00
@@ -0,0 +1 @@
+
@@ -0,0 +1,161 @@
+# Versuch 01 - Baseline (Prompt-only) - Iteration 03
+
+## Metadaten
+- **Versuch:** V1 Baseline (Prompt-only)
+- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
+- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
+- **Zeitstempel:** 2026-08-28
+- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
+- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
+
+  | Änderung | Auslösender Befund |
+  |---|---|
+
+---
+
+## Prompt
+
+Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
+
+### Auftrag
+
+Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
+
+1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
+2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
+3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
+
+Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
+
+### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
+
+Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
+
+**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
+
+### Vorgehen (statische Analyse, keine Ausführung)
+
+Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
+
+**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
+
+**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
+
+**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
+
+2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
+3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
+4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
+5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
+6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
+
+### Pflicht-Eigenschaften jeder Anforderung
+
+- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
+- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
+- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
+- **Belegklassifikation:** Kennzeichne jeden Beleg als
+  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
+  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
+  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
+- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
+- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
+- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
+- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
+- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
+
+### Formatvorgabe pro Anforderung
+
+```
+ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
+Titel:         <kurzer Titel>
+Ebene:         <StRS | SyRS | SwRS>
+Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
+Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
+Akteur:        <Rolle / System / Komponente>
+Vorbedingung:  <Zustand vor Auslösen>
+Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
+Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
+Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
+Belege:
+  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
+  - [SEKUNDÄR] <...> - Begründung: <...>
+  - [KONTEXT]  <...> - Begründung: <...>
+Prüfidee:      <Akzeptanzkriterium oder Testidee>
+Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
+Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
+Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
+Status:        <belegt | HYPOTHESE>
+```
+
+### Traceability
+
+Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
+- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
+- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
+- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
+
+### Nicht-funktionale Anforderungen
+
+- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
+- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
+
+### Konsolidierungsbedarf
+
+Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
+
+**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
+
+### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
+
+```text
+Ergebnisse/
+  StRS.md
+  SyRS.md
+  SwRS.md
+  Traceability.md   (oder Traceability.csv)
+  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
+  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
+  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
+                     Selbstbewertung, bekannte Lücken)
+```
+
+**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
+
+Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
+
+### Randbedingungen
+
+- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
+- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
+- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
+- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
+- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
+
+### Abschluss
+
+Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
+- Doppelte oder mehrfach vergebene IDs
+- Anforderungen ohne Beleg
+- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
+- Tracelinks auf nicht existierende IDs
+- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
+- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
+- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
+
+Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
+
+Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
+- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
+- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
+- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
+- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
+- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
+  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
+  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
+
+  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
+
+> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
+> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
+> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.\n\n### Werkzeugkontext (vom Versuchsaufbau vorgegeben)\nFuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.\nNicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.\nTriff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.\n\nVerfuegbare Werkzeuge:\n- read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)\n- list_directory: Listet Verzeichnisinhalte auf\n- search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)\n- execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)\n- write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis\n\n### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)\nSchreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis\nc:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 8\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_194103_v8.0.0-b1a2\Ergebnisse\.\nVerändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1,9 @@
+{
+  "modell": "moonshotai/kimi-k3",
+  "iteration": "Iteration 8",
+  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
+  "promptVersion": "03",
+  "modus": "solo",
+  "effort": "high",
+  "skillVersion": "v8.0.0"
+}
@@ -0,0 +1 @@
+2026-08-28T19:41:03.4969129+02:00