iteration 8

2026-08-28 19:41:13 +02:00
parent 37275c96d6
commit 8a22d586f1
182 changed files with 34254 additions and 18 deletions
@@ -1025,8 +1025,13 @@ gelesen (`~/.cline/data/settings/providers.json`, Provider `tensorx`). Alternati
 er per `--api-key` oder Umgebungsvariable `TENSORX_API_KEY` übergeben werden. Der Key
 wird **nicht** in Laufartefakten gespeichert.
-**Unterstützter Agentenmodus:** Nur `solo`. Der Adapter implementiert keine Subagenten;
+**Unterstützter Agentenmodus:** `solo` (V1) und `builtin` (V1b). Der Modus wird per
-`builtin` und `custom` sind nicht freigegeben und führen zum Abbruch.
+`--mode solo|builtin` gesteuert. Im Modus `solo` steht das `spawn_subagent`-Tool nicht
 zur Verfügung. Im Modus `builtin` kann der Hauptagent Subagenten mit eigenem Kontext
 starten (`spawn_subagent`-Tool) – diese erhalten Read-Only-Tools (kein `write_file`) und
 eine eigene, vom Hauptagenten unabhängige Konversation. Der Subagent-Typ (`explore` oder
 `general-purpose`) bestimmt den System-Prompt. Subagent-Token fließen vollständig in
 `usage` und `modelUsage` ein. `custom` ist nicht freigegeben und führt zum Abbruch.
 **Isolation.** Der Adapter ist ein eigenständiges Python-Skript, das nur die
 Python-Standardbibliothek und `requests` benötigt. Es liest die Codebasis über die
@@ -1067,7 +1072,8 @@ python "$skillDir\glm-kimi-adapter.py" `
  --output   "$lauf\Ergebnisse" `
  --model    $modell `
  --effort   $effort `
-  --max-turns 50 `
+  --mode     $modus `
  --max-turns 80 `
  --result-dir $lauf `
  2> "$lauf\Stderr.log"
@@ -1089,6 +1095,8 @@ Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
 | Agent-Turns | `num_turns` |
 | Tatsächlich eingesetztes Modell | `model` (aus API-Antwort; mit `model_requested` abzugleichen) |
 | Tool-Aufrufe | `tool_call_count`, `tool_call_types` (nach Werkzeugname) |
 | Subagenten | `subagent_stats` (`spawned`, `completed`, `failed`, `by_type`) – nur im Modus `builtin` |
 | Subagenten-Details | `subagent_details` (je Subagent: Typ, Beschreibung, Turns, Tokens, Status) |
 | Erzeugte Artefakte | `written_files` (Pfad und Größe je Datei) |
 | Abschlusstext | `result` |
@@ -206,8 +206,77 @@ TOOLS = [
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "spawn_subagent",
            "description": (
                "Starte einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe. "
                "Der Subagent kann Dateien lesen, Verzeichnisse auflisten, suchen und "
                "Befehle ausfuehren – aber keine Ergebnisdateien schreiben. Verwende dies, "
                "um einen Teil der Codebasis parallel oder isoliert zu analysieren. "
                "Der Subagent erhaelt nur die Beschreibung, nicht den bisherigen "
                "Konversationsverlauf. Gib eine praegnante Aufgabenbeschreibung."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "description": {
                        "type": "string",
                        "description": "Die Aufgabe fuer den Subagenten (z.B. 'Analysiere alle Berechtigungspruefungen in src/backend/Centron.BL/Security und erstelle eine Zusammenfassung der gefundenen Pruefungen mit Dateipfaden und Methodennamen')",
                    },
                    "subagent_type": {
                        "type": "string",
                        "description": "Typ des Subagenten: 'explore' fuer Code-Erkundung, 'general-purpose' fuer allgemeine Analyse",
                    },
                },
                "required": ["description"],
            },
        },
    },
 ]
 # Read-Only-Tools fuer Subagenten (kein write_file, kein spawn_subagent)
 SUBAGENT_TOOLS = [t for t in TOOLS if t["function"]["name"] not in ("write_file", "spawn_subagent")]
 # Standard-Subagent-Typen (fuer Modus 'builtin')
 BUILTIN_SUBAGENT_PROMPTS = {
    "explore": (
        "Du bist ein Code-Explorations-Agent. Deine Aufgabe ist es, einen Teil der "
        "Codebasis zu untersuchen und eine strukturierte Zusammenfassung deiner "
        "Erkenntnisse zurueckzugeben. Nutze die Werkzeuge aktiv, um Dateien zu lesen "
        "und zu durchsuchen. Gib am Ende eine kompakte Zusammenfassung mit konkreten "
        "Dateipfaden, Klassennamen und Methodennamen zurueck."
    ),
    "general-purpose": (
        "Du bist ein Analyse-Agent. Du untersuchst die Codebasis und beantwortest "
        "die dir gestellte Aufgabe. Nutze die Werkzeuge aktiv. Gib am Ende eine "
        "praegnante Antwort mit konkreten Belegen (Dateipfade, Methodennamen) zurueck."
    ),
 }
 # Aktive Subagent-Prompts (wird je Modus gesetzt)
 SUBAGENT_SYSTEM_PROMPTS = dict(BUILTIN_SUBAGENT_PROMPTS)
 def load_custom_agents(agents_file):
    """
    Laedt Agenten-Definitionen aus einer JSON-Datei fuer Modus 'custom'.
    Format: { "agent_name": { "description": "...", "prompt": "..." }, ... }
    Rueckgabe: dict agent_name -> system_prompt
    """
    agents_path = Path(agents_file)
    if not agents_path.is_file():
        raise FileNotFoundError(f"Agenten-Datei nicht gefunden: {agents_file}")
    data = json.loads(agents_path.read_text(encoding="utf-8"))
    prompts = {}
    for name, spec in data.items():
        desc = spec.get("description", "")
        prompt = spec.get("prompt", "")
        prompts[name] = prompt
    return prompts
 # ---------------------------------------------------------------------------
 # Pfad-Sicherheit
@@ -322,7 +391,8 @@ def tool_execute_command(root: str, args: dict) -> str:
            return "ABGELEHNT: Befehl enthaelt verbotenes Muster. Schreibende und bauende Kommandos sind gesperrt."
    try:
        result = subprocess.run(
-            command, shell=True, cwd=root, capture_output=True, text=True, timeout=60,
+            command, shell=True, cwd=root, capture_output=True, text=True,
            timeout=60, encoding="utf-8", errors="replace",
        )
        output = result.stdout or ""
        if result.stderr:
@@ -341,6 +411,13 @@ def tool_write_file(output_dir: str, args: dict) -> str:
    content = args.get("content", "")
    if not path:
        return "FEHLER: Kein Dateipfad angegeben"
    # Modell gibt oft "Ergebnisse/<name>" als Pfad – Präfix entfernen
    # da output_dir bereits das Ergebnisse-Verzeichnis ist.
    path = path.replace("\\", "/")
    for prefix in ("Ergebnisse/", "./Ergebnisse/", "ergebnisse/"):
        if path.startswith(prefix):
            path = path[len(prefix):]
            break
    try:
        base = Path(output_dir).resolve()
        target = (base / path).resolve()
@@ -368,6 +445,106 @@ def execute_tool(name: str, args: dict, root: str, output_dir: str) -> str:
    return f"FEHLER: Unbekanntes Werkzeug: {name}"
 # ---------------------------------------------------------------------------
 # Subagent
 # ---------------------------------------------------------------------------
 def run_subagent(provider, model, api_key, effort, root, description,
                 subagent_type, temperature, timeout, max_turns=15):
    """
    Startet einen Subagenten mit eigenem Kontext.
    Der Subagent erhaelt Read-Only-Tools und eine begrenzte Turn-Anzahl.
    Rueckgabe: dict mit result, usage, turns, tool_calls, status.
    """
    sys_prompt = SUBAGENT_SYSTEM_PROMPTS.get(
        subagent_type, SUBAGENT_SYSTEM_PROMPTS["general-purpose"]
    )
    messages = [
        {"role": "system", "content": sys_prompt},
        {"role": "user", "content": description},
    ]
    sub_usage = {"prompt_tokens": 0, "completion_tokens": 0,
                 "total_tokens": 0, "cached_tokens": 0, "reasoning_tokens": 0}
    sub_turns = 0
    sub_tool_calls = 0
    sub_result = ""
    sub_errors = []
    while sub_turns < max_turns:
        sub_turns += 1
        try:
            resp = call_api_subagent(provider, model, messages, api_key,
                                     effort, temperature, timeout)
        except Exception as e:
            sub_errors.append(str(e))
            break
        u = resp.get("usage", {})
        sub_usage["prompt_tokens"] += u.get("prompt_tokens", 0)
        sub_usage["completion_tokens"] += u.get("completion_tokens", 0)
        sub_usage["total_tokens"] += u.get("total_tokens", 0)
        sub_usage["cached_tokens"] += u.get("prompt_tokens_details", {}).get("cached_tokens", 0)
        sub_usage["reasoning_tokens"] += u.get("completion_tokens_details", {}).get("reasoning_tokens", 0)
        choices = resp.get("choices", [])
        if not choices:
            sub_errors.append("Keine choices in Subagent-Antwort")
            break
        msg = choices[0].get("message", {})
        messages.append(msg)
        content = msg.get("content", "")
        if content:
            sub_result = content
        tool_calls = msg.get("tool_calls", [])
        if not tool_calls:
            break
        for tc in tool_calls:
            func = tc.get("function", {})
            tname = func.get("name", "")
            try:
                targs = json.loads(func.get("arguments", "{}"))
            except json.JSONDecodeError:
                targs = {}
            sub_tool_calls += 1
            # Subagent darf nur Read-Only-Tools nutzen
            if tname in ("read_file", "list_directory", "search_files", "execute_command"):
                tresult = execute_tool(tname, targs, root, "")
            else:
                tresult = f"FEHLER: Werkzeug '{tname}' ist fuer Subagenten nicht freigegeben."
            messages.append({"role": "tool", "tool_call_id": tc.get("id", ""),
                             "name": tname, "content": tresult})
    return {
        "result": sub_result or "(Subagent ohne Ergebnis)",
        "usage": sub_usage,
        "turns": sub_turns,
        "tool_calls": sub_tool_calls,
        "errors": sub_errors,
        "status": "completed" if sub_result else "failed",
    }
 def call_api_subagent(provider, model, messages, api_key, effort, temperature, timeout):
    """API-Aufruf fuer Subagenten (mit SUBAGENT_TOOLS statt TOOLS)."""
    url = f"{provider['base_url']}/chat/completions"
    headers = {"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}
    body = {
        "model": model, "messages": messages, "tools": SUBAGENT_TOOLS,
        "tool_choice": "auto", "temperature": temperature, "stream": False,
    }
    model_prefix = model.split("/")[0] if "/" in model else ""
    effort_type = MODEL_EFFORT_TYPE.get(model_prefix, "thinking")
    effort_val = EFFORT_MAP.get(effort, {}).get(effort_type, "medium")
    if effort_type == "thinking":
        body["thinking"] = {"type": "enabled", "level": effort_val}
    elif effort_type == "reasoning_effort":
        body["reasoning_effort"] = effort_val
    resp = requests.post(url, headers=headers, json=body,
                          timeout=timeout if timeout > 0 else 1800)
    if resp.status_code != 200:
        raise RuntimeError(f"API-Fehler {resp.status_code}: {resp.text[:2000]}")
    return resp.json()
 # ---------------------------------------------------------------------------
 # API-Aufruf
 # ---------------------------------------------------------------------------
@@ -400,8 +577,35 @@ def call_api(provider, model, messages, api_key, effort, temperature, timeout):
 # ---------------------------------------------------------------------------
 def run_agent_loop(provider, model, system_prompt, user_prompt, api_key, effort,
-                   root, output_dir, max_turns, temperature, timeout):
+                   root, output_dir, max_turns, temperature, timeout, mode="solo"):
    """Fuehrt den Agent-Loop durch und sammelt Metriken."""
    # Tools je nach Modus waehlen
    if mode == "builtin":
        active_tools = TOOLS  # inklusive spawn_subagent
    else:
        active_tools = [t for t in TOOLS if t["function"]["name"] != "spawn_subagent"]
    # call_api mit den aktiven Tools parametrisieren
    def _call_api(messages):
        url = f"{provider['base_url']}/chat/completions"
        headers = {"Authorization": f"Bearer {api_key}", "Content-Type": "application/json"}
        body = {
            "model": model, "messages": messages, "tools": active_tools,
            "tool_choice": "auto", "temperature": temperature, "stream": False,
        }
        model_prefix = model.split("/")[0] if "/" in model else ""
        effort_type = MODEL_EFFORT_TYPE.get(model_prefix, "thinking")
        effort_val = EFFORT_MAP.get(effort, {}).get(effort_type, "medium")
        if effort_type == "thinking":
            body["thinking"] = {"type": "enabled", "level": effort_val}
        elif effort_type == "reasoning_effort":
            body["reasoning_effort"] = effort_val
        resp = requests.post(url, headers=headers, json=body,
                               timeout=timeout if timeout > 0 else 1800)
        if resp.status_code != 200:
            raise RuntimeError(f"API-Fehler {resp.status_code}: {resp.text[:2000]}")
        return resp.json()
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_prompt},
@@ -415,12 +619,51 @@ def run_agent_loop(provider, model, system_prompt, user_prompt, api_key, effort,
    finish_reason = None
    errors = []
    start_time = time.time()
    # Subagent-Tracking
    subagent_stats = {"spawned": 0, "completed": 0, "failed": 0, "by_type": {}}
    subagent_details = []
    MAX_SUBAGENTS = 10  # Hartes Limit: danach wird spawn_subagent verweigert
    write_file_count = 0  # Zaehlt write_file-Aufrufe
    write_reminder_sent = False  # Wurde schon eine Schreib-Erinnerung gesendet?
    while turns < max_turns:
        turns += 1
        # Schreib-Erinnerung: Wenn nach 1/3 der Turns noch kein write_file,
        # oder nach 2/3 der Turns weniger als 3 write_file-Aufrufe
        if not write_reminder_sent and turns >= max_turns // 3 and write_file_count == 0:
            messages.append({
                "role": "user",
                "content": (
                    "WICHTIG: Du hast bisher keine Ergebnisdateien geschrieben. "
                    "Beginne JETZT damit, deine Analyseergebnisse mit write_file "
                    "in die vorgegebenen Dateien (StRS.md, SyRS.md, SwRS.md, "
                    "Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md) "
                    "zu schreiben. Schreibe nicht weiter Subagenten — formalisiere "
                    "deine bisherigen Erkenntnisse in Anforderungen."
                ),
            })
            write_reminder_sent = True
            sys.stderr.write(f"[glm-kimi-adapter] Schreib-Erinnerung gesendet "
                             f"(Turn {turns}, 0 write_file-Aufrufe)\n")
        elif (not write_reminder_sent and turns >= max_turns * 2 // 3
                and write_file_count < 3):
            messages.append({
                "role": "user",
                "content": (
                    f"WICHTIG: Du hast bisher nur {write_file_count} Ergebnisdatei(en) "
                    f"geschrieben. Es fehlen noch mehrere der 7 vorgegebenen Dateien "
                    f"(StRS.md, SyRS.md, SwRS.md, Traceability.md, Hypothesen.md, "
                    f"Glossar.md, Analysebericht.md). Schreibe die fehlenden Dateien "
                    f"JETZT mit write_file."
                ),
            })
            write_reminder_sent = True
            sys.stderr.write(f"[glm-kimi-adapter] Schreib-Erinnerung gesendet "
                             f"(Turn {turns}, {write_file_count} write_file-Aufrufe)\n")
        try:
-            response = call_api(provider, model, messages, api_key,
+            response = _call_api(messages)
                               effort, temperature, timeout)
        except Exception as e:
            errors.append(f"Turn {turns}: API-Fehler: {e}")
            break
@@ -430,7 +673,6 @@ def run_agent_loop(provider, model, system_prompt, user_prompt, api_key, effort,
        total_usage["total_tokens"] += usage.get("total_tokens", 0)
        cached = usage.get("prompt_tokens_details", {}).get("cached_tokens", 0)
        total_usage["cached_tokens"] += cached
        # Reasoning/Thinking-Tokens aus completion_tokens_details
        comp_details = usage.get("completion_tokens_details", {})
        total_usage["reasoning_tokens"] += comp_details.get("reasoning_tokens", 0)
        if response.get("model"):
@@ -459,7 +701,60 @@ def run_agent_loop(provider, model, system_prompt, user_prompt, api_key, effort,
            except json.JSONDecodeError:
                tool_args = {}
            tool_calls_log.append({"turn": turns, "name": tool_name, "args": tool_args})
-            result = execute_tool(tool_name, tool_args, root, output_dir)
+
            # write_file-Zaehler erhoehen
            if tool_name == "write_file":
                write_file_count += 1
            # Subagent-Spawning behandeln
            if tool_name == "spawn_subagent":
                if subagent_stats["spawned"] >= MAX_SUBAGENTS:
                    # Hartes Limit erreicht: verweigere und erzwinge Schreibphase
                    result = (
                        "ABGELEHNT: Subagent-Limit erreicht (10/10). "
                        "Du hast bereits 10 Subagenten gestartet. "
                        "Schreibe JETZT deine Ergebnisdateien mit write_file: "
                        "StRS.md, SyRS.md, SwRS.md, Traceability.md, "
                        "Hypothesen.md, Glossar.md, Analysebericht.md. "
                        "Starte keine weiteren Subagenten."
                    )
                    sys.stderr.write(f"[glm-kimi-adapter] Subagent verweigert "
                                     f"(Limit {MAX_SUBAGENTS} erreicht)\n")
                else:
                    sa_desc = tool_args.get("description", "")
                    sa_type = tool_args.get("subagent_type", "general-purpose")
                    subagent_stats["spawned"] += 1
                    subagent_stats["by_type"][sa_type] = subagent_stats["by_type"].get(sa_type, 0) + 1
                    sys.stderr.write(f"[glm-kimi-adapter] Subagent "
                                     f"{subagent_stats['spawned']}/{MAX_SUBAGENTS} "
                                     f"gestartet (Typ: {sa_type})\n")
                    try:
                        sa_result = run_subagent(
                            provider, model, api_key, effort, root,
                            sa_desc, sa_type, temperature, timeout
                        )
                        subagent_stats["completed" if sa_result["status"] == "completed" else "failed"] += 1
                        sa_u = sa_result["usage"]
                        total_usage["prompt_tokens"] += sa_u["prompt_tokens"]
                        total_usage["completion_tokens"] += sa_u["completion_tokens"]
                        total_usage["total_tokens"] += sa_u["total_tokens"]
                        total_usage["cached_tokens"] += sa_u["cached_tokens"]
                        total_usage["reasoning_tokens"] += sa_u["reasoning_tokens"]
                        subagent_details.append({
                            "id": subagent_stats["spawned"],
                            "type": sa_type,
                            "description": sa_desc[:200],
                            "turns": sa_result["turns"],
                            "tool_calls": sa_result["tool_calls"],
                            "tokens": sa_u["total_tokens"],
                            "status": sa_result["status"],
                        })
                        result = sa_result["result"]
                    except Exception as e:
                        subagent_stats["failed"] += 1
                        result = f"FEHLER: Subagent fehlgeschlagen: {e}"
            else:
                result = execute_tool(tool_name, tool_args, root, output_dir)
            messages.append({"role": "tool", "tool_call_id": tc_id,
                             "name": tool_name, "content": result})
@@ -511,7 +806,10 @@ def run_agent_loop(provider, model, system_prompt, user_prompt, api_key, effort,
        "tool_call_types": tool_call_types,
        "written_files": written_files, "result": final_content,
        "finish_reason": finish_reason, "errors": errors, "session_id": "",
-        "adapter": "python-glm-kimi", "adapter_version": "1.0.0",
+        "adapter": "python-glm-kimi", "adapter_version": "1.1.0",
        "mode": mode,
        "subagent_stats": subagent_stats,
        "subagent_details": subagent_details,
    }
@@ -528,6 +826,8 @@ def main():
    parser.add_argument("--provider", default="tensorx", help="API-Provider (default: tensorx)")
    parser.add_argument("--api-key", default=None, help="API-Key (default: aus Cline providers.json)")
    parser.add_argument("--effort", default="high", choices=["low", "medium", "high", "xhigh", "max"])
    parser.add_argument("--mode", default="solo", choices=["solo", "builtin", "custom"], help="Agentenmodus (solo=keine Subagenten, builtin=eingebaute, custom=vordefinierte Agenten aus Datei)")
    parser.add_argument("--agents", default=None, help="Pfad zu Agenten-Definitionen (JSON) fuer Modus 'custom'")
    parser.add_argument("--max-turns", type=int, default=50)
    parser.add_argument("--temperature", type=float, default=1.0)
    parser.add_argument("--timeout", type=int, default=0, help="Timeout in Sek (0=keins)")
@@ -567,8 +867,50 @@ def main():
        "Du bist ein Requirements Engineer im Reverse Requirements Engineering "
        "eines Legacy-ERP-Systems. Du analysierst die Codebasis im Arbeitsverzeichnis "
        "und erstellst eine Anforderungsspezifikation nach ISO/IEC/IEEE 29148:2018.\n\n"
-        "Werkzeuge: read_file, list_directory, search_files, execute_command, write_file.\n"
+        "Werkzeuge: read_file, list_directory, search_files, execute_command, write_file.\n\n"
-        "Die Codebasis wird ausschliesslich GELESEN. Schreibe Ergebnisdateien mit "
+        "WICHTIG: Beginne deine Arbeit mit dem Schreiben von Ergebnisdateien (write_file), "
        "nicht mit dem Erkunden. Erstelle zuerst die Skelette der 7 Ergebnisdateien "
        "(StRS.md, SyRS.md, SwRS.md, Traceability.md, Hypothesen.md, Glossar.md, "
        "Analysebericht.md) mit Platzhalter-Inhalt, bevor du in die Details gehst. "
        "Wenn du Ergebnisse hast, schreibe sie SOFORT mit write_file — beschreibe nicht, "
        "was du schreiben wirst, schreibe es."
    )
    if args.mode == "builtin":
        system_prompt += (
            "\nZusaetzlich steht spawn_subagent zur Verfuegung: Starte einen "
            "Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben (z.B. "
            "Analyse eines einzelnen Moduls). Der Subagent kann nur lesen, nicht "
            "schreiben. Nutze Subagenten, um die Breite der Analyse zu erhoehen: "
            "delegiere Modul-Analysen an Subagenten, waehrend du die "
            "Gesamtstruktur und die Ergebnisdateien verwaltest."
        )
    elif args.mode == "custom":
        # Custom agents laden
        if args.agents:
            custom_prompts = load_custom_agents(args.agents)
            SUBAGENT_SYSTEM_PROMPTS.clear()
            SUBAGENT_SYSTEM_PROMPTS.update(custom_prompts)
            agent_list = ", ".join(SUBAGENT_SYSTEM_PROMPTS.keys())
            sys.stderr.write(f"[glm-kimi-adapter] Custom agents geladen: {agent_list}\n")
            system_prompt += (
                f"\nDu orchestrierst spezialisierte Subagenten. Verfuegbare Agenten-Typen: "
                f"{agent_list}. Nutze spawn_subagent mit dem passenden subagent_type, "
                f"um Teilaufgaben zu delegieren. Vorgehen: "
                f"1. Starte 'modulinventar' fuer das vollstaendige Inventar. "
                f"2. Starte 'faktenermittler' fuer Modulausschnitte, die du analysieren willst. "
                f"3. Schreibe die Anforderungen selbst mit write_file (die Autoren-Agenten "
                f"sind nur fuer Vorbereitung da, nicht fuer das Schreiben der Ergebnisdateien). "
                f"4. Fuehre den Konsistenzcheck selbst durch. "
                f"Der Subagent kann nur lesen, nicht schreiben."
            )
        else:
            sys.stderr.write("[glm-kimi-adapter] WARNUNG: Modus 'custom' ohne --agents, falle auf 'builtin' zurueck\n")
            args.mode = "builtin"
            system_prompt += (
                "\nZusaetzlich steht spawn_subagent zur Verfuegung."
            )
    system_prompt += (
        "\nDie Codebasis wird ausschliesslich GELESEN. Schreibe Ergebnisdateien mit "
        "write_file ins Ausgabeverzeichnis. Sprache: Deutsch fuer Anforderungen."
    )
@@ -582,13 +924,14 @@ def main():
    sys.stderr.write(f"[glm-kimi-adapter] Provider: {provider['name']}\n")
    sys.stderr.write(f"[glm-kimi-adapter] Modell: {args.model}\n")
    sys.stderr.write(f"[glm-kimi-adapter] Effort: {args.effort}\n")
    sys.stderr.write(f"[glm-kimi-adapter] Mode: {args.mode}\n")
    try:
        result = run_agent_loop(
            provider=provider, model=args.model, system_prompt=system_prompt,
            user_prompt=user_prompt, api_key=api_key, effort=args.effort,
            root=args.root, output_dir=str(output_dir), max_turns=args.max_turns,
-            temperature=args.temperature, timeout=args.timeout,
+            temperature=args.temperature, timeout=args.timeout, mode=args.mode,
        )
    except Exception as e:
        tb = traceback.format_exc()
@@ -602,7 +945,10 @@ def main():
                      "reasoning_tokens": 0},
            "modelUsage": {}, "tool_calls": [], "tool_call_count": 0,
            "tool_call_types": {}, "written_files": [], "result": "",
-            "errors": [str(e)], "adapter": "python-glm-kimi", "adapter_version": "1.0.0",
+            "errors": [str(e)], "adapter": "python-glm-kimi", "adapter_version": "1.1.0",
            "mode": args.mode,
            "subagent_stats": {"spawned": 0, "completed": 0, "failed": 0, "by_type": {}},
            "subagent_details": [],
        }
    end_iso = datetime.now(timezone.utc).isoformat()
@@ -616,6 +962,8 @@ def main():
    sys.stderr.write(f"[glm-kimi-adapter] Turns: {result['num_turns']}\n")
    sys.stderr.write(f"[glm-kimi-adapter] Tokens gesamt: {result['usage']['total_tokens']:,}\n")
    sys.stderr.write(f"[glm-kimi-adapter] Tool-Calls: {result['tool_call_count']}\n")
    sa = result.get("subagent_stats", {})
    sys.stderr.write(f"[glm-kimi-adapter] Subagenten: {sa.get('spawned',0)} (completed: {sa.get('completed',0)}, failed: {sa.get('failed',0)})\n")
    sys.stderr.write(f"[glm-kimi-adapter] Ergebnisdateien: {len(result['written_files'])}\n")
    sys.stderr.write(f"[glm-kimi-adapter] RawResult: {raw_result_path}\n")
@@ -630,8 +630,11 @@ nicht vollständig vorab spezifizieren; er entsteht in der Auseinandersetzung mi
 ## 5. Durchgeführte Läufe
-24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl (Nr. 2,
+**Iteration 1:** 24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl
-API-Transportfehler).
+(Nr. 2, API-Transportfehler).
 **Iteration 6 (TensorX-Gateway, Skill v8.0.0):** 1 Lauf, 2,17 Mio. Tokens, 90 erzeugte Anforderungen.
 Erster Lauf mit GLM 5.2 über den Python-API-Adapter. Details siehe unten.
 | # | Zeit | Modell | Modus | Effort | Subagenten | Denials | Turns | Tokens | Anforderungen |
 |---:|---|---|---|---|---:|---:|---:|---:|---:|
@@ -660,10 +663,128 @@ API-Transportfehler).
 | 23 | 21:09 | fable-5 | solo | **max** | 0 | 0 | 162 | 31.073.793 | 148 |
 | 24 | 22:07 | fable-5 | builtin | high | 13 | 0 | 28 | **150.340.866** | 172 |
 ### Iteration 6 – Erster Lauf mit TensorX-Gateway (28.08.2026)
 | # | Zeit | Modell | Modus | Effort | Subagenten | Denials | Turns | Tokens | Anforderungen |
 |---:|---|---|---|---|---:|---:|---:|---:|---:|
 | 25 | 07:41 | **glm-5.2** | solo | high | 0 | n. erfasst | 33 | 2.171.551 | 90 |
 | 26 | 07:54 | **kimi-k3** | builtin | high | 8 (3 OK, 5 fail) | n. erfasst | 28 | 5.704.697 | 81 |
 | 27 | 09:28 | **glm-5.2** | builtin | high | 10 (10 OK) | n. erfasst | 8 | 1.126.614 | **0 (Fehlmessung)** |
 | 28 | 09:28 | **kimi-k3** | solo | high | 0 | n. erfasst | 50 | 3.442.979 | 79 |
 Läufe 27 und 28 liefen **parallel** (gleiche Startzeit 09:28 CEST). Wanduhrzeiten sind
 daher verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch und
 Anforderungsanzahl bleiben unverzerrt.
 **Lauf 27 (GLM builtin) ist eine Fehlmessung**: `is_error: false`, `subtype: success`,
 aber **0 Ergebnisdateien** bei 1,13 Mio. Tokens und 10 erfolgreichen Subagenten. Der Agent
 startete 10 Subagenten (alle completed, 0 failed — der Unicode-Bugfix aus Lauf 26 wirkte),
 schrieb aber selbst keine Ergebnisdateien. Der Abschlusstext lautete: „Ich habe nun eine
 umfassende Übersicht… Ich starte parallele Suchen." — der Agent beschrieb, was er tun würde,
 anstatt es zu tun. Nur 8 Turns bei max_turns=100.
 **Lauf 28 (Kimi solo)** erreichte 50 Turns (max_turns-Limit) und erzeugte 79 Anforderungen
 mit 100 % Primärbeleg-Quote. Die Tool-Nutzung ist ausgewogener als bei GLM-solo
 (23× list_directory, 21× execute_command, 18× search_files, 9× read_file, 13× write_file).
 0 Hypothesen bei 79 Anforderungen — auffällig, da der Prompt bei Codebasen dieser Größe
 mindestens eine erwartet.
 Erster Lauf über den **TensorX-API-Gateway** mit dem **Python-API-Adapter** (`glm-kimi-adapter.py`).
 Skill-Version **v8.0.0** (MAJOR: neuer Adapter = neue Versuchsbedingung). Keine CLI-Abhängigkeit,
 nur Python + `requests`. API-Key automatisch aus der Cline `providers.json` gelesen.
 Lauf 26 ist der erste Lauf im Modus **`builtin` (V1b)** mit dem Python-API-Adapter. Der Adapter
 implementiert Subagenten über ein `spawn_subagent`-Tool: Der Hauptagent delegiert Teilaufgaben an
 Subagenten mit eigenem Kontext und Read-Only-Tools. 5 von 8 Subagenten schlugen fehl
 (UnicodeDecodeError: cp1252 vs UTF-8 bei Shell-Kommandoausgabe); Bug nachträglich behoben.
 **Besonderheiten gegenüber Claude-Code-Läufen:**
 - Reasoning-Tokens erfasst – Claude Code liefert nur `thinking_tokens`, TensorX zusätzlich `reasoning_tokens`
 - Cache-Read-Anteil 89–92 % – deutlich höher als bei Claude Code
 - Tool-Nutzungsschwerpunkt: `list_directory`-dominiert (GLM solo: 88×, Kimi builtin: ähnlich)
 - Keine Permission-Denials als zählbare Messgröße (hartes Blockieren statt Denial)
 - GLM solo: 5:39 min, Kimi builtin: 57:33 min – Subagenten-Delegation verachtfacht die Dauer
 - Tokenverbrauch builtin (5,7 Mio.) 2,6× höher als solo (2,17 Mio.) – gleicher Effekt wie bei Claude Code
 Die Läufe 7–8, 9–11, 12–16, 17–21 und 22–23 liefen jeweils parallel. Wanduhrzeiten dieser Läufe
 sind dadurch verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch,
 Anforderungsanzahl und Denials bleiben unverzerrt.
 ### Iteration 7 – Prompt-Version 03 und V2-Agenten-Adapter (28.08.2026)
 **Prompt-Änderungen (02 → 03):** Nur zwei Änderungen, beide aus Iteration-6-Befunden abgeleitet:
 1. Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien (Kimi-solo hatte `SwRS-Ergaenzungen.md` erstellt → 18 Anforderungen vom Skript nicht erfasst)
 2. Modulabdeckung härter: >10 % `nicht analysiert` = Hinweis auf unvollständige Erkundung (GLM-solo hatte 27,5 % nicht analysiert)
 **Adapter-Änderung:** `--mode custom` mit `--agents <datei>` implementiert (V2-Vorbereitung). Noch nicht in Läufen verwendet.
 **Vorbereitungs-Bug:** Der Werkzeugkontext-Block enthielt `\`$lauf\Ergebnisse\` — der Backtick verhinderte die PowerShell-Variablenexpansion, sodass das Modell Dateien nach `$lauf\Ergebnisse\` statt ins echte Ergebnisverzeichnis schrieb. Betrifft alle 4 Läufe.
 | # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
 |---:|---|---|---|---|---:|---:|---:|---:|---|
 | 29 | 11:17 | **glm-5.2** | solo | high | 0 | 32 | 1.849.737 | 0 *(Bug)* | ⚠️ Dateien in `$lauf\Ergebnisse\` |
 | 30 | 11:24 | **glm-5.2** | builtin | high | 6 (4 OK, 2 fail) | 8 | 1.096.464 | 0 | ⚠️ **Fehlmessung** |
 | 31 | 11:17 | **kimi-k3** | solo | high | 0 | 23 | 628.222 | 0 | ⚠️ **Fehlmessung** (0 write_file) |
 | 32 | 11:24 | **kimi-k3** | builtin | high | 3+ | läuft | läuft | läuft | ⏳ läuft noch |
 Alle 4 Läufe liefen **parallel** (gleiche Startzeit 11:17 bzw. 11:24 CEST).
 **Lauf 29 (GLM solo):** 5 Ergebnisdateien geschrieben, aber wegen des `$lauf`-Bugs im verschachtelten Verzeichnis `$lauf\Ergebnisse\` abgelegt. Rettungsversuch aufgrund des Sonderzeichens `$` im Verzeichnisnamen fehlgeschlagen. 0 Anforderungen auswertbar.
 **Lauf 30 (GLM builtin):** Wiederholung der Fehlmessung aus Iteration 6 (Lauf 27). Gleiches Muster: 6 Subagenten gestartet (4 OK, 2 fail), aber 0 Ergebnisdateien. 8 Turns bei max_turns=200. GLM 5.2 im builtin-Modus erzeugt konsistent keine Ergebnisdateien — systematisches Problem.
 **Lauf 31 (Kimi solo):** 23 Turns, 628k Tokens, aber 0 `write_file`-Aufrufe. Der Agent erkundete die Codebasis (34× list_directory, 11× read_file, 9× execute_command, 9× search_files), schrieb aber nie eine Ergebnisdatei. Fehlmessung. Auffällig: Tokenverbrauch (628k) deutlich niedriger als Iteration-6-Kimi-solo (3,44 Mio.) — möglicherweise abgebrochen oder vorzeitig beendet.
 **Lauf 32 (Kimi builtin):** Wurde nach über 5 Stunden Laufzeit manuell abgebrochen — der Hauptagent startete 11 Subagenten ohne jemals Ergebnisdateien zu schreiben. Dasselbe Muster wie GLM-builtin in Iteration 6 und 7: endlose Subagent-Delegation ohne Übergang zur Schreibphase.
 **Vorläufige Erkenntnis aus Iteration 7:** Drei von vier Läufen sind Fehlmessungen. Der `$lauf`-Bug muss vor der nächsten Iteration behoben werden. GLM 5.2 im builtin-Modus ist ein systematisches Problem (3 Fehlmessungen in Folge). Kimi solo hatte in Iteration 6 noch funktioniert (79 Anforderungen) — die Fehlmessung in Iteration 7 könnte ein Parallelbetriebs-Effekt sein (4 Läufe gleichzeitig überlasten das API-Kontingent).
 ---
 ### Iteration 8 – Prompt-Version 03, Adapter-Verbesserungen, sequenzielle Läufe (28.08.2026)
 **Adapter-Verbesserungen (v1.1.0 → v1.2.0):** Drei Maßnahmen gegen die Fehlmessungen aus Iteration 6+7:
 1. **Subagent-Limit (10):** Nach 10 Subagenten wird `spawn_subagent` verweigert mit der Aufforderung, Ergebnisdateien zu schreiben.
 2. **Schreib-Erinnerung:** Wenn nach ⅓ der Turns kein `write_file` aufgerufen wurde, wird eine System-Nachricht injiziert.
 3. **`$lauf`-Bug behoben:** PowerShell-Variablenexpansion im Werkzeugkontext-Block korrigiert.
 Läufe liefen **sukzessive** (nicht parallel), um API-Kontingent-Probleme zu vermeiden.
 | # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
 |---:|---|---|---|---|---:|---:|---:|---:|---|
 | 33 | 12:59 | **glm-5.2** | solo | high | 0 | 34 | 1.862.184 | 70 | ✅ erfolgreich |
 | 34 | 13:10 | **glm-5.2** | builtin | high | 9 (9 OK) | 28 | 7.140.040 | 132 | ✅ **erfolgreich — Durchbruch** |
 | 35 | 13:35 | **kimi-k3** | solo | high | 0 | 44 | 3.208.550 | 0 | ⚠️ nur 1 Datei |
 | 36 | 14:20 | **kimi-k3** | builtin | high | 6 | — | — | 0 | ❌ **abgebrochen** (Stromausfall) |
 **Lauf 33 (GLM solo):** 70 Anforderungen, 7 Ergebnisdateien. Tool-Schwerpunkt weiterhin `list_directory` (107× vs. 11× `read_file`).
 **Lauf 34 (GLM builtin) — DER DURCHBRUCH:** Nach 3 Fehlmessungen in Folge (Iteration 6+7) hat GLM 5.2 im builtin-Modus endlich Ergebnisdateien geschrieben. **132 Anforderungen** (vs. 70 bei solo — fast doppelt so viele durch Subagent-Delegation). 9 Subagenten (Limit 10, nicht voll ausgeschöpft), alle completed, 0 failed. 8 `write_file`-Aufrufe — das Subagent-Limit und die Schreib-Erinnerung haben funktioniert. 7,14 Mio Tokens (3,8× solo).
 **Lauf 35 (Kimi solo):** 44 Turns, 3,2 Mio Tokens, aber nur 1 Ergebnisdatei (Analysebericht.md). Die Schreib-Erinnerung wurde nicht ausgelöst, weil das Modell früh einmal `write_file` aufrief (`write_file_count == 0` war nie erfüllt). Kimi schrieb den Analysebericht, dann nie wieder — möglicherweise durch max_turns begrenzt.
 **Lauf 36 (Kimi builtin):** Wurde durch Stromausfall abgebrochen. 6 Subagenten gestartet, 0 Ergebnisdateien. Keine Auswertung möglich.
 **Wiederholungsläufe (nach Adapter-Verbesserung):** Die Schreib-Erinnerung wurde erweitert: sie löst jetzt auch bei `write_file_count < 3` nach ⅔ der Turns aus.
 | # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
 |---:|---|---|---|---|---:|---:|---:|---:|---|
 | 37 | 16:10 | **kimi-k3** | solo | high | 0 | 27 | 1.473.405 | 0 | ⚠️ nur StRS.md |
 | 38 | 17:24 | **kimi-k3** | builtin | high | 10 (Limit) | — | — | 0 | ❌ **abgebrochen** (API-Timeout) |
 **Lauf 37 (Kimi solo, Wiederholung):** 27 Turns, 1,47 Mio Tokens, aber nur 1 Ergebnisdatei (StRS.md). Das Modell schreibt eine Datei und beendet sich dann mit `finish_reason: stop` — die Schreib-Erinnerung kann nicht greifen, weil das Modell vor Turn 67 (Schwelle für erste Erinnerung) stoppt. Dies ist ein Kimi-K3-spezifisches Verhaltensmuster: das Modell beendet den Lauf nach einer Teilleistung.
 **Lauf 38 (Kimi builtin, Wiederholung):** Subagent-Limit erreicht (10/10), danach 4 weitere `spawn_subagent`-Aufrufe verweigert. Aber das Modell schrieb keine Ergebnisdateien — es blockierte nach den Verweigerungen auf einem API-Aufruf (CPU eingefroren bei 465s für 25+ Min). Nach ~100 Min manuell abgebrochen.
 **Erkenntnis aus Iteration 8 (endgültig):**
 - **Das Subagent-Limit (10) funktioniert für GLM 5.2** zuverlässig: nach Erreichen des Limits schreibt GLM Ergebnisdateien (132 Anforderungen in Lauf 34).
 - **Kimi K3 hat ein anderes Problem als GLM:** Das Subagent-Limit wird korrekt durchgesetzt (10/10, 4 Verweigerungen), aber Kimi K3 kann nicht zur Schreibphase übergehen — es blockiert nach den Verweigerungen.
 - **Kimi K3 solo** beendet sich nach 1 Ergebnisdatei mit `finish_reason: stop` — die Schreib-Erinnerung kann nicht greifen, weil das Modell vor der Turn-Schwelle stoppt.
 - **Modell-spezifische Unterschiede:** GLM 5.2 ist im builtin-Modus produktiv (mit Limit), Kimi K3 ist es nicht — weder solo (frühzeitiger Abbruch) noch builtin (kein Übergang zur Schreibphase).
 - Die TensorX-Matrix hat jetzt 2 von 4 Zellen gültig gefüllt: GLM solo (70 Anf.) und GLM builtin (132 Anf.). Kimi solo und Kimi builtin bleiben problematisch.
 ---
 ## 6. Befunde
@@ -894,7 +1015,7 @@ Stichprobe.
 - Exakt gesendeter Prompt je Lauf: `_meta/combined_prompt.md`
 - Subagenten-Prompts: `_meta/subagenten.md`
 - Maschinelle Anforderungsauswertung: `_meta/anforderungen.md` und `.json`
- Prozessvorgabe: `.claude/skills/run-experiment/SKILL.md` (Version 4.0.0, mit Änderungshistorie)
+- Prozessvorgabe: `.claude/skills/run-experiment/SKILL.md` (Version 8.0.0, mit Änderungshistorie)
 - Nachweis des Untersuchungsgegenstands: `Versuche/Versuch_01/_Codebasis-Nachweis.md`
 - Struktur- und Umbenennungshistorie: `Versuche/Versuch_01/_Umbenennung_*.md`,
  `_Umstrukturierung_2026-08-26.md`
@@ -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.
@@ -0,0 +1,142 @@
 # Analysebericht – Reverse Requirements Engineering c-entron ERP
 Lauf: V1-Baseline/Prompt-only, Iteration 02. Methode: statische Analyse (Schritte 0–6 der RRE-Methodenkette), keine Ausführung. Ergebnis: 15 StRS-, 31 SyRS-, 35 SwRS-Anforderungen (81 gesamt).
 ## 1. Modulinventar (Schritt 0, vor der ersten Anforderung erstellt)
 Legende Tiefe: **tief** (Kernlogik/Rechte- und Prozessdurchsetzung gelesen), **mittel** (Fachklassen und harte Belege benannt), **flach** (Existenz/Zweck/Anker belegt, kein Detail read), **n.a.** = nicht analysiert (Begründung s. u.).
 | # | Modul / Komponente | Pfad(en) | Fachliche Aufgabe | Tiefe | Anforderungen (IDs) |
 |---|---|---|---|---|---|
 | 1 | CRM / Geschäftspartner & Stammdaten | BL/Accounts, BusinessPartner, CustomerArea, CountryArea | Kunden, Lieferanten, Ansprechpartner, Anreden/Länder/Bundesländer rechtegestützt verwalten | mittel | StRS-001, StRS-009, SwRS-010 (3) |
 | 2 | Vertrieb & Belegwesen | BL/Sales/Receipts | Belegkette Angebot→Gutschrift inkl. Preisregeln, Storno, Journal | tief | StRS-003, SyRS-019, SyRS-020, SyRS-021, SwRS-001, SwRS-005, SwRS-006 (7) |
 | 3 | Verträge & automatische Abrechnung | BL/Sales/CustomerAssets, WebServices/.../AutomaticFactura | Vertragsverwaltung, Klick-/Zählerabrechnung, Stammblatt-Bindung | tief | StRS-004, StRS-005, SwRS-011, SwRS-017 (4) |
 | 4 | Helpdesk / Ticketservice | BL/Sales/Support, TicketProjects, TaskManager, NexusTicketViews | Tickets mit Kategorien/Status/SLA-artigen Rechten, Zeit, Vorlagen (C-FLOW), Projekt-Kopplung | tief | StRS-006, StRS-007, SwRS-002, SwRS-009, SwRS-025, SwRS-026 (6) |
 | 5 | Kalender / Zeit / Termine | BL/Sales/Calendar, Calendar, Time, MyDay, AppointmentRequests | Terminplanung mit Einschränkungsrechten, Tagesübersicht, externe Terminanfragen | flach | SyRS-004 (Teil), StRS-007 (2) |
 | 6 | Projekte / Prozesse / erwartete Ereignisse | BL/Projects, Processes, ExpectedEvents | Projekte über Objekte, Prozessdefinitionen, Ereignissteuerung | flach | SwRS-025 (1) |
 | 7 | Checklisten | BL/CheckListArea | Checklistenvorlagen/-instanzen mit Punkt-Bearbeitern | mittel | SwRS-021 (1) |
 | 8 | Aufgaben / Wiedervorlagen | BL/ToDoArea | Objektbezogene Aufgaben inkl. Fremdlisten-Rechte | mittel | SwRS-020 (1) |
 | 9 | Warenwirtschaft / Artikel / Logistik | BL/Warehousing, Devices, Logistics, Storage, ProductMatrix | Artikelstamm, Bestände, Lagerorte, Nebenlager, Umbuchungen, Varianten-Matrix | tief | StRS-008, SwRS-019, SwRS-023 (3) |
 | 10 | Seriennummern / Barcodes | BL/Warehousing (BarcodeBL) | Zustandsgeführte Seriennummern über Lager/Beleg/Stammblatt | mittel | SwRS-018 (1) |
 | 11 | Einkauf / Lieferantenbelege | BL/Buying, Purchasing | Lieferantenstamm, Bestellungen, Lieferantenliefer/-rechnung/-gutschrift | flach | StRS-009 (1) |
 | 12 | Produktion / Fertigungsaufträge | BL/Production, Nexus/ProductionOrderManagement | Arbeitspläne, Produktionsaufträge, Schritt-Zeiten | mittel | SwRS-022 (1) |
 | 13 | RMA / Retouren | BL/CustomerArea (RmaBL) | Retourenabwicklung mit Versandarten | mittel | SwRS-024 (1) |
 | 14 | Finanzen / Zahlungsverkehr / Bank | BL/Accounting, Finances, Transactions, apis/FinAPI, WPF OnlineBanking | Bankverbindungen, Zahlungseingänge, Kassenbuch, Online-Banking | mittel | StRS-011, SyRS-016 (2) |
 | 15 | Mahnwesen | SSMS (Mahnlauf), Recht IGNORE_DUNNING_* | Mahnläufe und Mahnsperre für Belege | flach | SyRS-027 (1, HYPOTHESE) |
 | 16 | EDI / Distributoren | BL/EDI, CPra | Elektronischer Dokumentenaustausch (Alltron, ALSO, Komsa, Concerto, EGIS, Opentrans21), CumpuPrA-Connector | mittel | StRS-010, SyRS-012 (2) |
 | 17 | E-Rechnung (ZUGFeRD/ebInterface) | BL/EDI/Zugferd, Centron.Api.EbInterface | Elektronische Rechnungsformate | flach | SyRS-013 (1) |
 | 18 | Versanddienstleister | apis/Centron.Api.Gls, Centron.Api.Shipcloud | Paketscheine/Tracking GLS & Shipcloud | flach | SyRS-014 (1) |
 | 19 | Katalogartikel-Import | apis/ITscope, Icecat, Egis, Cop DataAccess | Artikelimport mit Feld-Mapping aus Distributionsquellen | mittel | SyRS-015 (1) |
 | 20 | MSP: Asset Management & Monitoring | SSMS AssetManagement*, BL/Integrations, RiverDivo | IT-Inventur, Checks/Historie, Lizenz-/Notfallmanagement | mittel | StRS-012, SyRS-030 (2) |
 | 21 | Kommunikation (Mail/Telefon/Chat/Notify) | BL/Mail, Mailings, MailScanner, Tapi, Chats, Notifications, NexusNotifications, Outlook(BL) | E-Mail (Vorlagen/Signatur/Blacklist/Exchange), TAPI, Chats, Benachrichtigungen, Serienmail (VMA) | mittel | SyRS-023 (1) |
 | 22 | Dokumente / Dokumentation / docuFORM | WebServices FileManagements, DocumentationArea, DocuBoard, Centron.Api.docuFORM, Security/PdfSigning | Objektbezogene Dateien mit Rechten, intern/extern Doku, PDF-Signatur, Formular-Integration | mittel | SyRS-025 (1) |
 | 23 | Reporting / Statistik | BL/ReportEngine, Reporting, Statistics | Berichtsgruppen/-Designer, Statistiken, Management-Infos mit Filialbeschränkung | tief | StRS-015, SyRS-018 (2) |
 | 24 | Volltextsuche | BL/IndexSearch | Deutschsprachiger Objektindex (Lucene-artig) | flach | SyRS-017 (1) |
 | 25 | Künstliche Intelligenz | BL/ArtificialIntelligence | KI-Chat mit rechtegesteuerten Fähigkeiten und Prompt-Verwaltung | mittel | SyRS-024 (1) |
 | 26 | Passwortverwaltung (Tresor) | BL/PasswordManager, PasswordManagementArea | Zugangsdaten-Verwaltung mit Richtlinien/Bereichen und Exportrecht | mittel | SyRS-029 (1) |
 | 27 | Benutzer / Rechte / Administration | BL/Administration, SystemArea, EmployeeArea, CentronRights.md | Benutzer-/Mitarbeiterverwaltung, Rechtekatalog, Einstellungen, Logos | tief | StRS-002, StRS-014, SyRS-003, SyRS-004, SwRS-007, SwRS-008, SwRS-013 (7) |
 | 28 | Authentifizierung & 2FA | BL/Administration/Logins, TwoFactorAuthenticator | Login-Dispatcher, AD, Basic, TOTP, RADIUS (Hyp.), Fehlversuchs-Logging | tief | SyRS-005, SyRS-006, SwRS-012, SwRS-013, SwRS-014, SwRS-030 (6) |
 | 29 | API-/Webservice-Plattform | webservice/Centron.Controllers, Host*, WebServices.Core | Versionierte REST-API, Auth-Filter, Windows-Service-/Konsolen-Host, Accesstoken | tief | SyRS-001, SyRS-002, SyRS-008, SwRS-015 (4) |
 | 30 | Web-Client „Nexus" | nexus/CentronNexus(+Host) | Blazor-Portale: Shop, Service-Board, Produktion, Doc-Signing, Settings | mittel | SyRS-010 (1) |
 | 31 | WPF-Desktop-Client | centron/Centron.WPF.UI(+Extension), shared/Centron.Controls* | Modulare Desktop-Arbeitsfläche mit Ribbon und Verbindungswächter | mittel | SyRS-009 (1) |
 | 32 | Webshop / Kundenportal / SelfCare | Nexus WebCart/WebOffer, BL/Administration/Logins (WebAccountBL), SelfCare | Endkunden-Shop auf Sonderpreisbasis, Web-Zugänge, Self-Service | mittel | StRS-013, SyRS-011 (2) |
 | 33 | Mobile & Konnektivität | BL/Mobile, c-entron.misc.ConnectionManager, Centron.Gateway | Mobile Fachlogik, Verbindungsmanagement, Gateway | flach | SwRS-032 (1) |
 | 34 | Massenpflege & Fremdbezüge | BL/DataExchange, MassUpdate, ObjectExternalReferences | Massenupdates, Datenaustausch-Konnektoren, externe Objektreferenzen | flach | SyRS-022, SwRS-029 (2) |
 | 35 | Text & Inhalte / Sonstiges | BL/TextModuleArea, Tags, Urls, VideoPortal, WebLinks, SocialMedia | Textbausteine, Anrede-Variablen, Tags, Videoportal-Zuordnung, Weblinks, Social-Media-Streams | flach | SwRS-027 (1) |
 | 36 | Customizing / Migrationen / ChangeTracking | BL/Customizations, Administration/Scripts, Modules, ChangeTracking, Exceptions, Telemetry | Skriptgesteuerte DB-Migrationen, Änderungshistorie, Erweiterbarkeit | mittel | SwRS-008, SwRS-016, SwRS-034 (3) |
 | 37 | Datenhaltung / Persistenz / Schema | Centron.DAO, Entities, Common, Interfaces, shared/Centron.Core, SSMS_DB_SCHEMA.sql | NHibernate-ORM, 1535 Tabellen, Mappings, Event-Listener, Kernbibliothek (u. a. TOTP) | tief | SyRS-007, SwRS-001, SwRS-003, SwRS-004, SwRS-028, SwRS-035 (6) |
 | 38 | Outlook-/Office-Integration | nexus/CentronNexus.OutlookAddIn, BL/Outlook, Nexus/Office | Outlook-Add-in, Kontextbezug Mails↔ERP, Exchange-Inventur | flach | SyRS-031 (1) |
 | 39 | Handelsplatz TradePool | BL/TradePool | Separater B2B-Login (Zweck nur hypothetisch) | flach | SwRS-031 (1, HYPOTHESE) |
 | 40 | Gutscheinverwaltung | BL/VoucherManagement | Gutscheine (Basisstand) | flach | SwRS-033 (1) |
 | 41 | Persönliche Arbeitsflächen | BL/MyCentron, WPF-Modul MyCentron, Nexus Management/Office | Dashboards, Notizen, zuletzt verwendete Objekte | flach | SyRS-009, SyRS-010 (Teile) (2) |
 | 42 | Betrieb & Deployment | azure, azure-blazor, docker, deployment, scripts, docs, assemblies, global.json, Directory.Build.props | Cloud-/Container-Artefakte, Regel-Doku, zentrale Build-Konfiguration | flach | SyRS-008, SyRS-026 (2) |
 | 43 | Testinfrastruktur | tests/* (Integration, EndToEnd, Playwright, CentronNexusTests) | Automatisierte Tests auf mehreren Ebenen | n.a. | – (Testcode spezifiziert kein Produktverhalten; als Qualitätssicherungs-Beleg genutzt, keine eigene Anforderung) |
 | 44 | Technische Hilfsmodule | BL/Helpers, GUI, Core (BL), GUI, CentronIcons, Start, WebSuite, WebVersion(Core) | Icons, Startfenster, Helper, Ausnahme-Typen | n.a. | – (keine eigenständige fachliche Regel belegbar; unterstützende Infrastruktur, keine Anforderung im Sinne von ISO 29148) |
 Anmerkung: BL/Buying ist im Repository nahezu leer (nur Verzeichnis External); die Einkaufsfunktion lebt in Purchasing, BusinessPartner und den Supplier-Belegen (Receipts) – Inventarzeile 11 trägt dies explizit.
 ## 2. Abdeckungstabelle (Kurzfassung)
 - **tief:** 9 Module (#2, #3, #4, #9, #23, #27, #28, #29, #37)
 - **mittel:** 18 Module (#1, #7, #8, #10, #12, #13, #14, #16, #19, #20, #21, #22, #25, #26, #30, #31, #32, #36)
 - **flach:** 15 Module (#5, #6, #11, #15, #17, #18, #24, #33, #34, #35, #38, #39, #40, #41, #42)
 - **nicht analysiert:** 2 Module (#43 Testinfrastruktur, #44 technische Hilfsmodule) – jeweils mit Begründung
 **Mindestabdeckung erreicht:** Ja. Jede Inventarzeile hat mindestens eine Anforderung oder eine begründete `n.a.`-Einstufung. Anzahl der erzeugten Anforderungen: 81 (15 StRS / 31 SyRS / 35 SwRS; Mehrfachverwendung einer Anforderung über mehrere Zeilen ist möglich).
 ## 3. Konsistenzcheck
 | Prüfung | Ergebnis |
 |---|---|
 | Doppelte/mehrfach vergebene IDs | Keine (IDs sequenziell je Ebene vergeben: StRS-001..015, SyRS-001..031, SwRS-001..035) |
 | Anforderungen ohne Beleg | Keine – jede der 81 Anforderungen führt mindestens 1 recherchierten Artefaktbeleg |
 | Anforderungen ohne `Übernahmewürdigkeit` | Keine – Feld in allen Blöcken gesetzt |
 | Tracelinks auf nicht existierende IDs | Keine (verwendete Ziel-IDs: StRS-001..015, SyRS-001..031, SwRS-002..035; alle referenzierten Nummern existieren; SyRS-016 wird ausschließlich als Ziel verwendet und existiert) |
 | Deckungsgleiche Anforderungen ohne Konsolidierungsvermerk | Keine identifiziert. Markierte Kandidaten: StRS-004/SwRS-017 ↔ StRS-012/SyRS-030 (Stammblatt vs. AssetManagement); SyRS-030 (selbst markiert); SwRS-006 (14 ähnliche Suchkonfigurationen, markiert); SwRS-027 (drei Platzhalter-Implementierungen, markiert); SwRS-005 (God Class, bewusst kein fachlicher Konsolidierungsfall) |
 | Belegklassifikation vorhanden | Ja – jede Belegzeile trägt PRIMÄR/SEKUNDÄR/KONTEXT mit Begründung |
 ### 3.1 Risikorelevante Anforderungen (Sicherheit/Abrechnung/Fakturierung/Berechtigung) – Beleglage
 | ID | Titel (Kurzform) | PRIMÄR-Beleg vorhanden? |
 |---|---|---|
 | StRS-002 | Eingeschränkte Datensichtbarkeit | Ja (AccountBL:282, HelpdeskBL:280–284) |
 | StRS-005 | Automatische Vertragsabrechnung | Ja (AutomaticFacturaWebServiceBL-Methoden) |
 | StRS-014 | Rechtemodell | Ja (AppRightsBL, ScriptMethod11783) |
 | SyRS-002 | API-Rechte 401/403 | Ja (Authorize*-Attribute) |
 | SyRS-003 | BL-Rechtezentrale | Ja (AppRightsBL:25, AccountBL, ArticleBL) |
 | SyRS-004 | Einschränkende Suchrechte | Ja (InvoiceReceiptSearchConfiguration:152–157 u. a.) |
 | SyRS-005 | Authentifizierung | Ja (Authenticator:106–109/161, ADAuthenticator:151–156) |
 | SyRS-006 | TOTP-2FA | Ja (TwoFactorAuthenticationBL, voll gelesen) |
 | SyRS-011 | WebAccount-Verwaltung | Ja (WebAccountWebServiceBL:54/:75) |
 | SyRS-020 | Mindestpreis-Schutz | Ja (ReceiptBL:9043/:9113) |
 | SyRS-021 | Rechnungsstorno-Recht | Ja (ReceiptWebServiceBL:1022) |
 | SyRS-024 | KI-Rechte | Ja (ArtificialIntelligenceChatWebServiceBL:90/:369–390) |
 | SyRS-025 | Dokumentrechte/PDF-Signatur | Ja (DocumentWebServiceBL:78, DocumentationBL:33, PdfSigningBL:60) |
 | SyRS-027 | Mahnwesen | **Nein** → konsequent als HYPOTHESE markiert |
 | SyRS-029 | Passwort-Tresor-Rechte | Ja (PasswordManagerBL:899/:935) |
 | SwRS-007 | AppRightsBL | Ja |
 | SwRS-008 | Rechte-Migration | Ja (ScriptMethod11783) |
 | SwRS-009 | Helpdesk-Rechte | Ja (HelpdeskBL:271–454) |
 | SwRS-010 | CRM-CRUD-Rechte | Ja (AccountAddressBL:259–317 u. a.) |
 | SwRS-011 | Abrechnungsservice | Ja (Methoden mit Zeilen) |
 | SwRS-012 | SHA1-Hashing | Ja (UsersBL:, WebAccountBL:, BasicAuthenticator:46) |
 | SwRS-013 | Login-Dispatcher/Logging | Ja (Authenticator:106–161) |
 | SwRS-014 | TOTP-BL | Ja (voll gelesen) |
 | SwRS-015 | API-Rechte-Attribute | Ja |
 | SwRS-017 | Stammblatt-Regeln | Ja (MasterDataListBL:163/294–305; MasterDataListWebServiceBL:172–188) |
 | SwRS-019 | Lagerrechte | Ja (ArticleBL:1035, InventoryBL:77/100, PartialCommission:135/170) |
 | SwRS-020 | Fremd-ToDo-Rechte | Ja (ToDoBL:310/:1993) |
 | SwRS-021 | Checklisten-Rechte | Ja (CentronChecklistWebserviceBL:160–162) |
 | SwRS-026 | Globale Ticket-Ansichten | Ja (NexusTicketViewWebServiceBL:44–124) |
 | SwRS-030 | RADIUS-2FA | **Nein** → konsequent als HYPOTHESE markiert |
 Ergebnis: 30 risikorelevante Anforderungen, davon 28 mit PRIMÄR-Beleg an der durchsetzenden Stelle, 2 ohne PRIMÄR-Beleg und daher als HYPOTHESE gekennzeichnet. **Kein Verstoß gegen die risikobasierte Priorisierung.**
 ### 3.2 Abgleich Hypothesen.md ↔ Inline-Markierungen
 Inline als `Status: HYPOTHESE` markiert (5): **SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031**.
 Hypothesen.md enthält exakt diese 5 Einträge, keine zusätzlichen freien Fragen. → **Deckungsgleich.**
 ## 4. Bekannte Lücken
 1. **Ticket-Statusmaschine:** Übergänge/Eskalationsregeln nur über Tabellen (hlpdsk_status) und Rechte erschlossen; konkrete Zustandsautomatik nicht gelesen.
 2. **Steuer-/Buchungslogik:** MwstSatz/Erlöskonten-Tabellen gesehen, Rechenweg (Steuerpositionen, Rundung, Skonto via Zahkond) nicht vertieft.
 3. **Preisfindung:** Staffelpreise (ArtikStaffelpreise, Sonderpreise) nur als Datenanker belegt.
 4. **Betrieb/Cloud:** azure*/docker/deployment nur Verzeichnisstruktur; keine Skripte gelesen.
 5. **Buying-Inhalte:** Verzeichnis nahezu leer – Einkaufslogik liegt verteilt (s. Inventar #11).
 6. **Mandantenlogik, RADIUS-Verdrahtung, Mahnprozess, TradePool-Zweck:** als HYPOTHESE offengelegt.
 7. **~40 MB Riesen-Files** (ReceiptBL 623 KB u. a.) nur suchbasiert analysiert; Zeilenbelege statt Volllektüre.
 ## 5. Selbstbewertung
 - **Abdeckung:** 44 Inventar-Maßeinheiten: 9 tief, 18 mittel, 15 flach, 2 begründet nicht analysiert. Mindestabdeckung (≥1 Anforderung je Modul) **erreicht**.
 - **Dünne Belege:** Schnittstellenmodule (SyRS-013/014/016/022/031) und flache BL-Module (Prozesse, TradePool, Voucher) beruhen auf SEKUNDÄR-/Existenzbelegen; die 4 HYPOTHESE-Fälle sind die ehrlichen Schwachstellen. Der hohe PRIMÄR-Anteil in Sicherheits-/Abrechnungsdomänen (28/30) ist bewusstes Ergebnis der Vertiefungsreihenfolge (Schritt 0c).
 - **Hypothesen:** 5 geführt (SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031) – deckungsgleiche Sammeldatei.
 - **Folge-Iteration-Nachschläge (Priorität):**
  1. Steuerungseinheit E-Rechnung/Mahnwesen + Steuer-/Buchungslogik (Accounting-Vertiefung).
  2. Ticket-Statusautomat und Eskalation (Sales/Support-Volllektüre).
  3. Mandant/RADIUS/TradePool-Hypothesen verifizieren (Codepfade suchen).
  4. Preisfindungs-/Rabatt- und Provisionslogik (ReceiptPriceHelper, ReceiptProvisionSchema) vertiefen.
  5. Cloud-/Container-Betrieb (azure, docker) und Sicherheitskonfigurationen auswerten.
  6. Datenbank: Liste der 134 FK-Constraints extrahieren; Integritäts-Hypothese (SwRS-003) gegenprüfen.
 - **Werkzeugeinsatz:** Subagenten wurden für 8 Modulpakete gestartet, lieferten in diesem Lauf keine auswertbaren Endberichte; Breite/Tiefe wurde daher im Hauptkontext über gezielte Verzeichnis-/Regex-Flächenscans und Lektüre von 6 Schlüsseldateien erschlossen. Dieser Umstand begrenzt die Tiefe einzelner Module (s. Abdeckungstabelle), nicht die Belegpflicht.
@@ -0,0 +1,33 @@
 # Glossar (Domänenbegriffe der c-entron-Codebasis)
 | Begriff | Definition | Beleg/Anker |
 |---|---|---|
 | **Stammblatt** | Geräte-Stammsatz beim Kunden (üblicher Einsatz: Drucker/Kopierer in Service-/Click-Verträgen; fachlich ein „Gerät beim Kunden" mit Positionen). Technisch Kopf/Pos-Tabellen GeraeteKopf/GeraetePos. Verknüpfbar mit Verträgen (VertragKopf.Stammblattbezogen), Tickets und Abrechnung. | CentronObjectKindNumeric.cs:314; ReportGroupBL.cs:402 (→ GeraeteKopf); SSMS (GeraeteKopf) |
 | **Asset / AssetManagement** | IT-Inventarobjekt der MSP-Funktion (Monitoring-gestützt, ~200 Tabellenfamilien: Checks, AD, DNS, IIS, Lizenzen). Fachlich überlappend mit Stammblatt → Konsolidierungsfall | SSMS (AssetManagement*) |
 | **Beleg** | Sammelbegriff für kaufmännische Dokumente (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Bestellung, Vertrag, Anfrage, Kalkulation, Warenein-/ausgang); technisch Kopf/Pos-Paar je Belegart | SSMS (…Kopf/…Pos); ReceiptBL.cs |
 | **Kopf/Pos** | Belegmuster: 1 Kopfdatensatz (Nummer, Kunde, Summen, Status) + n Positionsdatensätze (Artikel, Mengen, Preise) | SSMS_*; SwRS-001 |
 | **hlpdsk_*** | Ticket-Datenmodell des Helpdesk (requests, timer, status, typen, kategorien, prioritaeten, bearbeiter, history) | SSMS; SwRS-002 |
 | **Ticket / Helpdesk** | Serviceanfrage mit Typ, Kategorie(n), Priorität, Status, Bearbeitern, Zeiten und Historie | HelpdeskBL.cs; CentronRights.md |
 | **C-FLOW** | Ticketvorlagen/-Anlage-Optimierung (Vorlagen, Kategorien) im Helpdesk; eigenes Rechtecluster | CentronRights.md §17; HelpdeskPatternWebserviceBL.cs |
 | **I3D** | Interner Primärschlüssel-Bezeichner der Entitäten (int), in Code und Fehlerobjekten durchgängig verwendet | durchgängig, z. B. bankAccount.I3D (BankAccountBL.cs:78) |
 | **AppUser** | Anmeldeidentität eines Benutzers inkl. Verknüpfung zum Mitarbeiter (Employee); Träger der Rechtezuweisung | AppUserBL.cs; EmployeeBL.cs |
 | **UserRightsConst** | Hierarchischer Konstantenkatalog aller Rechte-IDs (int), gruppiert nach Fachbereichen (Sales.Customer..., Purchase.StockList..., Administration...) | durchgängig; CentronRights.md |
 | **Restricting Right** | Einschränkendes Recht: verkleinert bei Vorhandensein die sicht-/bearbeitbare Datenmenge (ONLY_OWN, ONLY_OWN_BRANCH, SHOW_ONLY_OWN_CUSTOMER) – Inverslogik zu Freigaberechten | CentronRights.md |
 | **Filiale** | Organisatorische Standorteinheit; Grundlage der *_ONLY_OWN_BRANCH-Einschränkungen | SSMS (Filiale); SyRS-004 |
 | **Mandant** | Rechtlich eigenständige Gesellschafts-Entität im Datenmodell (Tabelle vorhanden; Auswertung HYPOTHESE) | SSMS (Mandant); SyRS-028 |
 | **Sonderpreise** | Kundenspezifische Preislisten; Quelle der Artikel im Webshop (WebCart) | README.md „WebCart" |
 | **WebAccount** | Web-Login eines Endkunden, am Adressstamm hängend; Basis Shop/Webportal | WebAccountBL.cs; WEBACCOUNT_MANAGEMENT-Recht |
 | **OPOS** | Offene Posten eines Kunden (Anzeigerecht SHOW_CUSTOMER_OPOS) | AccountWebServiceBL.cs:355/'SHOW_CUSTOMER_OPOS' |
 | **Mahn(sperr)lauf** | Mahnhistorie/Steuerung; Mahnsperre verhindert neue Belege, Ausnahme per Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS | SSMS (Mahnlauf); SyRS-027 (HYPOTHESE) |
 | **Kommissionierung** | Lagerprozess der Positionszusammenstellung zu Aufträgen (inkl. Teile Kommissionen, Barcode-Generierung) | OrderCommissionBL.cs; PartialCommissionOrderBL.cs |
 | **Inventur** | Bestandszählung mit Inventurgruppen/Pools (Rechte CREATE/DROP_INVENTORY, Gruppenverwaltung) | InventoryBL.cs; InventoryArticlePool.cs |
 | **Seriennummer/BarcodeState** | Zustandsgeführte Geräteeinheit („im Lager", „in Stammblatt" u. a.); Grundlage von Umbuchungsregeln | BarcodeBL.cs; BarcodeState.cs |
 | **MSP** | Managed Service Provider – Betreiberkontext, für den AssetManagement/Monitoring/AutomaticFactura gebaut sind | Statistikrechte MspStatistics; AutomaticFactura* |
 | **Named Query** | Parametrisierte, namentlich registrierte Datenbankabfrage außerhalb des ORM-Standardwegs (z. B. PasswordManager.GetAppUserTwoFactorAuthKey) | DAO/NamedQueries; TwoFactorAuthenticationBL.cs |
 | **ScriptMethod** | Versionierte DB-Migrationsklasse (numeriert, enthält SQL), Bestandteil des Update-Prozesses | Administration/Scripts/ScriptMethods/Scripts/ |
 | **Virtueller Mail-Assistent (VMA)** | Modul zur automatischen Mail-Verarbeitung/-Zuordnung; Zugriffsrecht ACCESS_VMA_MODULE | MailScannerBL.cs:59–61 |
 | **TradePool** | Eigenständiger B2B-Handelsbereich mit separatem Login (TradeCustomerLogin); Zweck HYPOTHESE | TradePoolBL.cs:170; SwRS-031 |
 | **RMA** | Return Merchandise Authorization – Retourenvorgang mit eigener Versandart-Steuerung | RmaBL.cs; SSMS (Rma) |
 | **ZUGFeRD / ebInterface** | Elektronische Rechnungsformate (DE / AT) | EDI/Zugferd; Centron.Api.EbInterface |
 | **Nexus** | Blazor-basierter Web-Client der Suite (Shop, Portal, Backoffice-Teile), Ablösungsperspektive des WPF-Clients | src/nexus/CentronNexus; README.md |
 | **docuFORM** | Externes Dokumenten-/Formularsystem; Anbindung über eigenes API-Projekt | Centron.Api.docuFORM |
@@ -0,0 +1,11 @@
 # Hypothesen (Sammlung aller [HYPOTHESE]-markierten Anforderungen)
 Enthält ausschließlich die in StRS/SyRS/SwRS mit `[HYPOTHESE]` bzw. `Status: HYPOTHESE` markierten Anforderungen (deckungsgleich mit den Inline-Markierungen). Freie Fragen ohne Anforderungsbezug stehen in der Selbstbewertung des `Analysebericht.md`.
 | ID | Titel | Warum Hypothese | Offene Frage / fehlende Information |
 |---|---|---|---|
 | SyRS-027 | Mahnwesen auf Basis offener Posten | Nur indirekte Belege: Tabelle Mahnlauf + Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS; die durchsetzende Prozessklasse wurde nicht gefunden/gelesen | Welche Klasse berechnet Mahnstufen/-läufe? Erzeugt das System Mahnbelege automatisiert? Wo wird die Mahnsperre beim Beleg geprüft? |
 | SyRS-028 | Mandantenfähigkeit | Tabelle Mandant existiert, aber die Auswertung im Code (Filter je Mandant) wurde nicht nachgewiesen | Wird Mandant aktiv zur Datentrennung herangezogen (Queries/Session-Kontext)? Single- oder Multi-DB-Betrieb? |
 | SwRS-003 | Referenzielle Integrität überwiegend auf BL-Ebene | Quantitativ belegt (134 FK bei 1535 Tabellen); die Aussage „vorrangig BL-gesteuert" ist induktiv aus Stichproben, kein vollständiger Katalog | Vollständige Liste aller BL-seitigen Konsistenzprüfungen; sind die 134 FKs die gesamte Menge oder ergänzen Trigger/Sichten weitere Integrität? |
 | SwRS-030 | RADIUS-basierte 2FA im Login-Fluss | Protokollimplementierung (RadiusClient/RadiusPaketParser/EmailTwoFactorValidator) vollständig vorhanden, aber der Aufruf aus dem Login-Dispatcher (Authenticator.cs) nicht überprüft | Ist der RADIUS-Validator produktiv im Anmeldepfad verdrahtet? Welche Konfiguration aktiviert ihn? |
 | SwRS-031 | TradePool-Zugang mit eigenem Login | Nur Schnittstelle gesehen (TradePoolBL.AuthenticateUser → TradeCustomerLogin); der Geschäftsprozess dahinter unbekannt | Was ist der fachliche Zweck des TradePool (B2B-Handelsplatz? Restpostenbörse?), welche Funktionen nutzen das Login? |
@@ -0,0 +1,336 @@
 # StRS – Stakeholder Requirements Specification (c-entron ERP, Reverse Engineering)
 Normbezug: ISO/IEC/IEEE 29148:2018. Alle Aussagen sind aus der Codebasis abgeleitet; technische Bezeichner bleiben im Original. Begriffe siehe `Glossar.md`.
 ---
 ```
 ID:            StRS-001
 Titel:         Zentrale Verwaltung von Geschäftspartnern (Kunden, Lieferanten, Ansprechpartner)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Vertriebs-/Einkaufsmitarbeiter
 Vorbedingung:  Benutzer ist angemeldet und besitzt das jeweilige Anlege-/Änderungsrecht
 Fakt:          AccountBL.cs und AccountAddressContactBL.cs prüfen vor jedem Schreibzugriff Rechte wie CREATE_CUSTOMER, EDIT_CUSTOMER, DELETE_CUSTOMER, RIGHT_LIEFERANTANLEGEN/-AENDERN; Adressen und Ansprechpartner werden getrennt geführt (AccountAddressBL, Tabellen Anschrif, Personen, Kontakte).
 Aussage:       Das System soll Kunden, Lieferanten, deren Adressen und Ansprechpartner zentral und rechtegeschützt verwalten.
 Ergebnis:      Konsistente Geschäftspartnerstammdaten, nutzbar in Belegen, Tickets, Verträgen.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs, Zeilen 1305–1365 (Rechteprüfungen vor Create/Edit/Delete/Search) – setzt regelbasierte Stammdatenpflege durch
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs, Zeilen 379–413 (je Operation eigenes Recht) – differenzierte Rechte je Partnerrolle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, Tabellen Kunden, Kreditor, Anschrif, Personen, Kontakte (CREATE TABLE) – Datenmodell der Partner
 Prüfidee:      Anlage eines Kunden ohne CREATE_CUSTOMER-Recht wird abgelehnt; mit Recht wird Datensatz persistent.
 Tracelinks:    SyRS-003, SwRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Kernfunktion jedes ERP
 Status:        belegt
 ```
 ```
 ID:            StRS-002
 Titel:         Eingeschränkte Datensichtbarkeit (nur eigene Daten / nur eigene Filiale)
 Ebene:         StRS
 Typ:           Sicherheit
 Qualitätsmerkmal: -
 Akteur:        Fachabteilung, IT-Administration
 Vorbedingung:  Benutzer besitzt ein einschränkendes Recht (z. B. SHOW_ONLY_OWN_CUSTOMER)
 Fakt:          AccountBL.cs:282 und AccountSearchBL.cs:331 filtern bei gesetztem Recht SHOW_ONLY_OWN_CUSTOMER die Kundenmenge; HelpdeskBL.cs:280–284 filtert Tickets analog (SHOW_HELPDESK_ONLY_OWN/-BRANCH); SaleStatisticBL.cs:60 filtert Statistiken auf die eigene Filiale (SHOW_ONLY_STATISTIC_FROM_OWN_BRANCH).
 Aussage:       Das System soll es ermöglichen, Benutzern Daten fachlich einzuschränken (nur eigene bzw. nur filialeigene Datensätze), übergeordnete Rechte heben die Einschränkung auf.
 Ergebnis:      Benutzer sieht ausschließlich die ihm zugeordneten Kunden/Tickets/Belege/Statistiken.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs:282 (HasUserRight SHOW_ONLY_OWN_CUSTOMER steuert Filter) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 (Sichtrechte ONLY_OWN / ONLY_OWN_BRANCH) – durchsetzende Stelle
  - [KONTEXT] CentronRights.md (Beschreibung der „restricting rights") – fachliche Definition
 Prüfidee:      Zwei Benutzer mit/ohne SHOW_ONLY_OWN_CUSTOMER liefern bei identischer Suche unterschiedliche Treffermengen.
 Tracelinks:    SyRS-004, SwRS-007, SwRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – gefordertes Mandanten-/Teamkonzept
 Status:        belegt
 ```
 ```
 ID:            StRS-003
 Titel:         Belegkette: Angebot, Auftrag, Lieferschein, Abholung, Rechnung, Gutschrift
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Vertriebsmitarbeiter
 Vorbedingung:  Kunde und Artikel sind gepflegt; Benutzer hat das jeweilige Beleg-Recht
 Fakt:          ReceiptWebServiceBL.cs:969–1022 bildet je Belegart eigene Anlege-/Bearbeite-/Storno-Rechte ab (Offer, Order, DeliveryList, PickUpList, Invoice, CreditVoucher, SupplierOrder, Contract); die DB führt je Belegart Kopf-/Positions-Tabellen (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, BestKopf2/BestPos2).
 Aussage:       Das System soll den vollständigen Vertriebsprozess als verknüpfte Belegtypen führen, inklusive Lieferantenbelegen (Bestellung, Lieferantenliefer-/Rechnungs-/Gutschriftsbelege).
 Ergebnis:      Durchgängige, nachverfolgbare Belegkette von Angebot bis Gutschrift.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:956–1022 (Rechte je Belegtyp durchgesetzt) – benennt prüfende Stelle je Operation
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopf/RechPos, AufKopf/AufPos, AngKopf/AngPos, GutKopf/GutPos, LiefKopf/LiefPos, AbholKopf/AbholPos, BestKopf2/BestPos2 – Belegmodell je Belegart
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs, SpecificLogics.cs – typspezifische Logik je Belegart
 Prüfidee:      Aus Auftrag wird Lieferschein, daraus Rechnung erzeugt; Verknüpfung und Folgebeleg-Nummern prüfen.
 Tracelinks:    SyRS-019, SyRS-020, SyRS-021, SwRS-001, SwRS-005, SwRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Kerngeschäftsprozess
 Status:        belegt
 ```
 ```
 ID:            StRS-004
 Titel:         Vertragsmanagement mit Gerätebezug („Stammblatt")
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Servicekaufmann, Vertrieb
 Vorbedingung:  Kunde besitzt Geräte (Stammblätter, Tabelle GeraeteKopf)
 Fakt:          MasterDataListBL.cs:163 verweigert das Löschen eines Stammblatts, solange es einem aktiven Vertrag zugeordnet ist; VertragKopf trägt das Feld Stammblattbezogen; ReceiptContractBL.cs erzeugt vertragspositionen automatisch aus Stammblättern.
 Aussage:       Das System soll Kundenverträge (inkl. Klick-/Kontingentverträge) mit den beim Kunden installierten Geräten (Stammblättern) verknüpfen und Abhängigkeiten gegen unzulässige Änderungen absichern.
 Ergebnis:      Vertragspositionen referenzieren verlässlich die Gerätebasis des Kunden.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 („Stammblatt ist einem aktiven Vertrag zugeordnet", DependencyCheckFailed) – durchsetzende Konsistenzregel
  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ContractLists/ReceiptContractBL.cs:533–563 (Erzeugung von Vertragspositionen aus Stammblättern) – durchsetzende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE VertragKopf, VertragPos, VertragGeraete, GeraeteKopf/GeraetePos – Datenmodell
 Prüfidee:      Stammblatt mit aktivem Vertrag kann nicht gelöscht werden; ohne Vertragsbezug schon.
 Tracelinks:    SyRS-019, SwRS-017
 Konsolidierung: Kandidat: StRS-012/SwRS-017 vs. AssetManagement-Tabellen (zwei Geräte-/Asset-Datenhaltungen)
 Übernahmewürdigkeit: übernehmen – fachlich weiterhin erforderlich, aber mit Asset-Konzept konsolidieren
 Status:        belegt
 ```
 ```
 ID:            StRS-005
 Titel:         Automatische Vertragsabrechnung (Automatische Faktura) inkl. Zählerstände
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Buchhaltung, Servicekaufmann
 Vorbedingung:  Es existieren abrechenbare Verträge mit Stammblatt-/Zählerbezug
 Fakt:          AutomaticFacturaWebServiceBL.cs enthält Methoden SearchBillingContractPos, LoadBillingResult(dtFrom, dtTo, contractI3Ds), GetContractPartibleArticlePositionen und Logik für Zählerstände aus Vorgänger-Stammblättern (Zeile 1421); Sonderartikel können massenhaft Verträgen zugeordnet werden (CreateSpecialArticleToContract).
 Aussage:       Das System soll wiederkehrende Vertragsabrechnungen automatisiert erzeugen, dabei teilbare Artikel und Zählerstandsdifferenzen (z. B. Klickpreise) berücksichtigen.
 Ergebnis:      Abrechnungsergebnis pro Vertrag und Zeitraum, abrechnungsbereit als Beleg.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, Methoden SearchBillingContractPos (:124), LoadBillingResult (:2370), CreateSpecialArticleToContract (:894) – durchsetzende Abrechnungslogik
  - [SEKUNDÄR] Ebendort :1421 (Textbaustein „Zählerstände aus Vorgängerstammblatt") – belegt Zählerstandsbehandlung
 Prüfidee:      Vertrag mit Klickpreisartikel und zwei Zählerständen abrechnen; berechnete Menge = Differenz.
 Tracelinks:    StRS-004, SyRS-019, SwRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – hoher wirtschaftlicher Nutzen; risikorelevant (Abrechnung)
 Status:        belegt
 ```
 ```
 ID:            StRS-006
 Titel:         Helpdesk/Ticketbearbeitung mit Kategorien, Prioritäten, Status und Vorlagen (C-FLOW)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Servicetechniker, Helpdesk-Mitarbeiter
 Vorbedingung:  Tickettyp/-kategorien sind gepflegt; Benutzer hat SHOW_HELPDESK
 Fakt:          hlpdsk_requests ist Kerntabelle, umgeben von hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_status, hlpdsk_request_bearbeiter, hlpdsk_history; HelpdeskBL.cs:422–454 prüft ADD_NEW_HELPDESK, EDIT_HELPDESK, CLOSE_REQUEST, MATURITY_CHANGE, ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS; C-FLOW-Vorlagen werden über HelpdeskPatternWebserviceBL.cs verwaltet.
 Aussage:       Das System soll Serviceanfragen als Tickets mit Typ, Kategorien, Priorität, Status, Bearbeitern, Historie und wiederverwendbaren Vorlagen verwalten und Bearbeitungsschritte rechteabhängig absichern.
 Ergebnis:      Nachverfolgbare Ticketbearbeitung vom Anlegen bis zum Abschluss.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284, 422–454 (Rechteprüfungen je Ticket-Operation) – durchsetzende Stelle
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_requests, hlpdsk_status, hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_request_bearbeiter, hlpdsk_history – Ticket-Datenmodell samt Historie
  - [SEKUNDÄR] CentronRights.md, Abschnitt „Helpdesk" – fachliche Rechtebeschreibung
  - [KONTEXT] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskPatternWebserviceBL.cs:351–395 – C-FLOW-Vorlagenrechte
 Prüfidee:      Ticket ohne CLOSE_REQUEST-Recht kann nicht geschlossen werden; Fälligkeitsänderung ohne MATURITY_CHANGE wird abgelehnt.
 Tracelinks:    SyRS-003, SyRS-004, SwRS-002, SwRS-009, SwRS-026, SwRS-027
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – zentraler Serviceprozess
 Status:        belegt
 ```
 ```
 ID:            StRS-007
 Titel:         Zeiterfassung auf Tickets mit Belegbindung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Servicetechniker
 Vorbedingung:  Ticket existiert; Benutzer besitzt Zeit-Bearbeitungsrechte
 Fakt:          hlpdsk_timer speichert Zeiten inkl. Mitarbeiterartikel (Tabelle Mitarbeiterartikel); laut CentronRights.md dürfen Zeiten nur verschoben/gelöscht werden, wenn das Ticket nicht Teil eines Belegs ist (MOVE_HELPDESK_TIMER/DELETE_HELPDESK_TIMER); HelpdeskTimerWebServiceBL.cs:359–374 unterscheidet EDIT_TIME und OWN_TIME_EDIT.
 Aussage:       Das System soll Arbeitszeiten auf Tickets erfassen und mit Mitarbeiterartikeln bewerten; bereits berechnete Zeiten (Belegbezug) sollen unveränderbar sein.
 Ergebnis:      Abrechenbare, manipulationssichere Leistungsnachweise.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Support/HelpdeskTimerWebServiceBL.cs:359–374 (Rechte EDIT_TIME/OWN_TIME_EDIT durchgesetzt) – prüfende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_timer, Mitarbeiterartikel – Datenmodell der Zeiterfassung
  - [KONTEXT] CentronRights.md, Recht 8/9 (Verschieben/Löschen nur wenn Ticket nicht Teil eines Belegs) – Regel der Belegbindung
 Prüfidee:      Zeit eines bereits fakturierten Tickets kann weder verschoben noch gelöscht werden.
 Tracelinks:    StRS-006, SwRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Basis der Dienstleistungsabrechnung
 Status:        belegt
 ```
 ```
 ID:            StRS-008
 Titel:         Lagerverwaltung mit Beständen, Seriennummern, Inventur und Kommissionierung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Lagerist, Einkäufer
 Vorbedingung:  Artikelstamm und Lagerorte sind gepflegt
 Fakt:          ArticleBL.cs:99–123 prüft eigene Rechte für Ein-/Aus-/Umbuchen (BOOK_TO_STOCK, BOOK_FROM_STOCK, TRANSFER_STOCK) und für Negativbestand (BOOK_ARTICLE_STOCK_INTO_NEGATIVE); InventoryBL.cs:77/100 verlangt CREATE_/DROP_INVENTORY; OrderCommissionBL.cs:431–438 steuert Kommissionierung; BarcodeBL.cs:1091 verhindert Umbuchung einer Seriennummer auf ein Stammblatt, wenn sie nicht „im Lager" ist.
 Aussage:       Das System soll Warenbestände rechtegestützt führen, Ein-/Aus-/Umbuchungen, Inventuren, Kommissionierung und seriennummernbasierte Nachverfolgung unterstützen und Negativbuchungen nur mit Sonderrecht zulassen.
 Ergebnis:      Buchungs- und inventursichere Bestände, lückenlose Seriennummernhistorie.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs:99–123, :1035 (Seriennummern-Pflichtflag nur mit CHANGE_SERIALNUMBER_REQUIRED_FLAG) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs:77–100 (Inventur-Rechte) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 (Zustandsprüfung der Seriennummer vor Umbuchung) – konkrete Bedingung
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArtikelBestand, Lagerort, Lagerplatz, SeriennummerToPosition – Datenmodell
 Prüfidee:      Ausbuchung unter Null ohne Negativbestand-Recht wird abgelehnt; Seriennummer außerhalb des Lagers kann nicht auf Stammblatt umgebucht werden.
 Tracelinks:    SyRS-003, SwRS-018, SwRS-019
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            StRS-009
 Titel:         Einkauf mit Lieferantenstamm und Bestellwesen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Einkäufer
 Vorbedingung:  Lieferant ist angelegt (RIGHT_LIEFERANTANLEGEN)
 Fakt:          Lieferantenoperationen sind eigene Rechte (RIGHT_LIEFERANTANLEGEN/-AENDERN, AccountWebServiceBL.cs:1868); Lieferantenbelege (Bestellung, Lieferantenliefer-/rechnungs-/gutschriftsbelege) besitzen eigene Such-/Anzeigerechte (SupplierOrderReceiptSearchConfiguration.cs:138–140 u. a.); SearchSupplierBL.cs/SupplierAssetBL.cs implementieren Lieferantensuche und Lieferanten-Assets; EDI-Verzeichnisse (Alltron, ALSO, Komsa, Concerto) koppeln Distributoren an.
 Aussage:       Das System soll Lieferanten, Bestellungen und Lieferantenbelege getrennt rechtegeschützt führen und Lieferanten-Assets sowie Distributorenanbindungen unterstützen.
 Ergebnis:      Beschaffungsprozess von Lieferantenstamm bis Lieferantenrechnung.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Accounts/AccountWebServiceBL.cs:1868 (Rechteprüfung RIGHT_LIEFERANTAENDERN vor Änderung) – prüfende Stelle
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/SupplierOrderReceiptSearchConfiguration.cs:138–140 (ShowRight/OnlyOwnBranchRight je Lieferantenbeleg) – durchgesetzte Sichtrechte
  - [SEKUNDÄR] src/backend/Centron.BL/BusinessPartner/SearchSupplierBL.cs, SupplierAssetBL.cs – Lieferanten-Fachlogik
  - [KONTEXT] src/backend/Centron.BL/EDI/ (Unterverzeichnisse Alltron, ALSO, Komsa, Concerto, Opentrans21) – Distributor-Kopplung
 Prüfidee:      Bestellung anlegen ohne Recht RIGHT_BESTELLUNGANLEGEN schlägt fehl (Recht in ReceiptWebServiceBL.cs:975 referenziert).
 Tracelinks:    StRS-010, SyRS-012, SwRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            StRS-010
 Titel:         Elektronischer Dokumentenaustausch mit Lieferanten/Distributoren (EDI)
 Ebene:         StRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: -
 Akteur:        Einkauf, System (automatisiert)
 Vorbedingung:  EDI-Gateway ist je Distributor konfiguriert (EDIGatewaySettingBL)
 Fakt:          BL/EDI enthält distributorsspezifische Verzeichnisse (Alltron, ALSO, AlsoCH, Concerto, EGIS, Komsa, Opentrans21, SupplierEDI, Zugferd) plus EDIDispatcherBL.cs (14 KB) als zentrale Steuerung und EDILogBL.cs zur Protokollierung.
 Aussage:       Das System soll Geschäftsdokumente (z. B. Bestellungen, Auftragsbestätigungen, Rechnungen) elektronisch und distributorsspezifisch austauschen und den Austausch protokollieren.
 Ergebnis:      Automatisierter, nachverfolgbarer Dokumentenverkehr ohne Medienbruch.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/EDI/EDIDispatcherBL.cs (zentraler Dispatcher), EDILogBL.cs (Austausch-Protokoll), EDIGatewaySettingBL.cs (Gateway-Konfiguration) – umsetzende Klassen
  - [SEKUNDÄR] Verzeichnisstruktur src/backend/Centron.BL/EDI/{Alltron,ALSO,AlsoCH,Concerto,EGIS,Komsa,Opentrans21,SupplierEDI,Zugferd} – je Partner ein Profil
 Prüfidee:      Ausgehende Bestellung erzeugt EDI-Nachricht im Profil des Lieferanten und einen EDILog-Eintrag.
 Tracelinks:    StRS-009, SyRS-012, SyRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Schnittstelle ins Zielsystem migrieren
 Status:        belegt
 ```
 ```
 ID:            StRS-011
 Titel:         Finanzprozesse: Zahlungseingänge, Online-Banking, Kassenbuch, Bankverbindungen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Buchhaltung
 Vorbedingung:  Offene Posten existieren; Bankkonto ist hinterlegt
 Fakt:          BL/Finances enthält IncomingPayments, Payments, OnlineBanking; BankAccountBL.cs:74–81 schützt Bankverbindungen durch eigene Rechte (CREATE_NEW_/EDIT_Bank_Account); Zahlungseingang und ZahlungseingangLog sind eigene Tabellen; Kassenbuch-Tabelle existiert; api-Projekt Centron.APIs.FinAPI koppelt Online-Banking.
 Aussage:       Das System soll Bankverbindungen, Zahlungseingänge samt Zuordnung/Protokoll und Kassenbuch führen und Online-Banking anbinden.
 Ergebnis:      Nachvollziehbare Zahlungszuordnung zu offenen Posten (OPOS-Anzeige ist rechtgesteuert, SHOW_CUSTOMER_OPOS).
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Accounting/BankAccountBL.cs:74–81 (Rechte vor Anlage/Änderung von Bankverbindungen) – prüfende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Zahlungseingang, ZahlungseingangLog, Kassenbuch, Bankverbindungen, Mahnlauf – Finanz-Datenmodell
  - [SEKUNDÄR] src/apis/Centron.APIs.FinAPI sowie WPF-Modul Modules/OnlineBanking – Online-Banking-Anbindung
  - [KONTEXT] AccountWebServiceBL.cs:359–360 (SHOW_CUSTOMER_FINANCE, EDIT_LIMIT_CUSTOMER) – Finanzsicht-/Limitrechte
 Prüfidee:      Bankverbindung ohne EDIT-Recht nicht änderbar; Zahlungseingang erzeugt Logeintrag und reduziert OPOS.
 Tracelinks:    SyRS-016, SwRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
 Status:        belegt
 ```
 ```
 ID:            StRS-012
 Titel:         IT-Asset-Management und Monitoring für betreute Kundenumgebungen (MSP)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        MSP-Techniker (Managed Service Provider)
 Vorbedingung:  Kundenumgebung wird durch Monitoring-Dienste erfasst
 Fakt:          Das DB-Schema enthält ca. 200 AssetManagement*-Tabellen (Geräte, AD-Benutzer/-Gruppen, Checks: Ping/SNMP/HTTP/SQL/Backup/SSL, DHCP-/DNS-/IIS-/Hyper-V-/Exchange-Details, Lizenzmanagement, Dokumentation, Notfallpläne) sowie MonitoringServiceSettings und AccountDevices; es existiert eine Gerätezuordnung zu Kunden und Tickets (AccountDevicesToTickets).
 Aussage:       Das System soll die IT-Infrastruktur von Kunden vollständig inventarisieren, überwachen (Checks) und die Bestände dokumentieren sowie mit Tickets verknüpfen.
 Ergebnis:      Aktueller Asset-Bestand mit Monitoring-Ergebnissen je Kunde.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementChecks, AssetManagementCheckResults, MonitoringServiceSettings, AccountDevices, AccountDevicesToTickets – durchgesetztes Datenmodell
  - [SEKUNDÄR] src/backend/Centron.BL/Integrations, src/backend/Centron.BL/RiverDivo – Integrationslogik (flach analysiert)
 Prüfidee:      Fehlgeschlagener Check (z. B. Ping) erzeugt CheckResult, der dem Gerät und Kunden zugeordnet ist.
 Tracelinks:    StRS-004, SyRS-030
 Konsolidierung: Kandidat: StRS-004/SwRS-017 (Stammblatt/GeraeteKopf) – doppelte Geräte-Datenhaltung, im Zielsystem zu einem Asset-Konzept zusammenführen (vgl. Prompt-Beispiel Drucker „Stammblätter" vs. „Assets")
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            StRS-013
 Titel:         Webshop für Kunden der Anwender (WebAccount, Sonderpreise)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Endkunde (Web-Benutzer), Vertrieb
 Vorbedingung:  Web-Account ist im Adressstamm angelegt; Sonderpreise sind gepflegt
 Fakt:          README.md beschreibt: WebCart ist für Kunden der Kunden; Login als Web-Account (Anlage im Adressstamm); sichtbare Artikel stammen aus den „Sonderpreisen" des Kunden; Nexus enthält WebCart- und WebOffer-Bereiche; WebAccountBL.cs verwaltet Web-Zugänge (Recht WEBACCOUNT_MANAGEMENT).
 Aussage:       Das System soll Endkunden einen Web-Zugang bieten, über den sie kundenspezifische Artikel (Sonderpreise) sehen, in den Warenkorb legen, bestellen und Angebote einsehen können.
 Ergebnis:      Bestellungen/Angebotsanfragen aus dem Web landen im Belegwesen des ERP.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:253/415/480 (Passwort-Handling von Web-Accounts), AccountWebServiceBL-Kontext Recht WEBACCOUNT_MANAGEMENT – Zugangsverwaltung
  - [SEKUNDÄR] src/nexus/CentronNexus/WebCart, src/nexus/CentronNexus/WebOffer – Shop-/Angebotsbereiche der Web-App
  - [KONTEXT] README.md, Abschnitt „WebCart" – fachliche Beschreibung des Shops (Sonderpreise als Artikelquelle)
 Prüfidee:      Web-Account sieht genau die Artikel seiner Sonderpreisliste; Bestellung erzeugt Beleg beim Mandanten.
 Tracelinks:    SyRS-010, SyRS-011, SwRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            StRS-014
 Titel:         Feingranulare Benutzer- und Rechteverwaltung
 Ebene:         StRS
 Typ:           Sicherheit
 Qualitätsmerkmal: -
 Akteur:        IT-Administrator
 Vorbedingung:  Administrator besitzt Administrationsrechte
 Fakt:          Rechte sind numerische Konstanten in UserRightsConst (hierarchisch: Sales.Customer.Helpdesk.*, Purchase.StockList.*, Administration.* u. a.); CentronRights.md dokumentiert sie fachlich inkl. „restricting rights"; die Durchsetzung erfolgt über AppRightsBL.HasUserRight/CheckRightsFromUser und API-Attribute; Administration-Skripte (ScriptMethod11783.cs) führen neue Rechte per Datenmigration ein.
 Aussage:       Das System soll ein feingranulares, je Benutzer zuweisbares Rechtemodell besitzen, das fachliche Operationen (Anzeigen/Anlegen/Ändern/Löschen je Objektart) und einschränkende Rechte abbildet und versionierbar erweitert wird.
 Ergebnis:      Jede geschützte Funktion ist nur mit zugewiesenem Recht ausführbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs (HasUserRight, CheckRightsFromUser, GetRightsFromCurrentUser) – zentrale Prüfstelle
  - [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11783.cs (Migration führt Recht „Seriennummer Hauptgerät am Stammblatt ändern" ein) – Rechte-Lebenszyklus
  - [SEKUNDÄR] CentronRights.md – fachliche Rechtedokumentation
 Prüfidee:      Neu vergebenes Recht erscheint in Rechteverwaltung und öffnet ausschließlich die zugehörige Funktion.
 Tracelinks:    SyRS-002, SyRS-003, SyRS-004, SwRS-007, SwRS-008, SwRS-016
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            StRS-015
 Titel:         Berichte, Statistiken und Management-Informationen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Geschäftsführung, Controlling
 Vorbedingung:  Benutzer besitzt Statistik-/Reportrechte
 Fakt:          BL/Statistics enthält Verkaufs-, Ticket-, Einkaufs-, Mitarbeiter- und MSP-Statistiken, jeweils rechtgeschützt (Controlling.Finances.MANAGEMENT_INFO, Controlling.Analytics.*, teils filialbezogen); ReportEngine (ReportDataBL 94 KB, ReportGroupBL) stellt Berichtsgruppen inkl. Mapping auf Tabellen bereit (z. B. STAMMBLATT → GeraeteKopf).
 Aussage:       Das System soll betriebswirtschaftliche Auswertungen und konfigurierbare Berichte bereitstellen, deren Sichtbarkeit über Rechte und Filialzugehörigkeit gesteuert wird.
 Ergebnis:      Kennzahlen und Berichte gemäß Benutzerrechten.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Statistics/SaleStatistics/SaleStatisticBL.cs:54–60 (Rechte OFFER_/TICKET_STATISTIC, Filialfilter SHOW_ONLY_STATISTIC_FROM_OWN_BRANCH) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/ReportEngine/ReportGroupBL.cs:402 (Berichtsgruppe STAMMBLATT → Tabelle GeraeteKopf) – konkrete Zuordnung
  - [SEKUNDÄR] src/backend/Centron.BL/Statistics/MspStatistics/MspStatisticBL.cs, CacheOrderStatisticsBL.cs usw. – Statistikbereiche
 Prüfidee:      Benutzer ohne MANAGEMENT_INFO erhält keine Management-Statistik; Filialbenutzer sieht nur eigene Filiale.
 Tracelinks:    StRS-002, SyRS-018
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
@@ -0,0 +1,739 @@
 # SwRS – Software Requirements Specification (c-entron ERP, Reverse Engineering)
 Normbezug: ISO/IEC/IEEE 29148:2018. Jede SwRS-Anforderung referenziert ihre SyRS-Anforderung; Kettentrace via `Traceability.md`.
 ---
 ```
 ID:            SwRS-001
 Titel:         Kopf-/Positions-Datenmodell je Belegart
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal: -
 Akteur:        Software (Persistenz)
 Vorbedingung:  Beleg wird gespeichert
 Fakt:          Jede Belegart besitzt eine Kopf- und eine Positions-Tabelle (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, AnfrKopf/AnfrPos, BestKopf2/BestPos2, VertragKopf/VertragPos, WareKopf/WarePos, LiGutKopf/LiGutPos, KalkKopf/KalkPos) – jeweils mit PRIMARY KEY (Schema enthält 1482 PRIMARY KEYs).
 Aussage:       Die Software soll Belege strukturell als Kopf mit beliebig vielen Positionen abbilden und je Belegart eigene Kopf-/Pos-Entitäten führen.
 Ergebnis:      Belegpositionen sind referenzierbar; Summen/Status kopfseitig, Artikelbezug positionsseitig.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopf (Zeile 3231), RechPos (12131), AufKopf (3016), AufPos (9681) u. a. – Schema-Struktur je Belegart
  - [SEKUNDÄR] src/backend/Centron.Entities (Entity-Klassen je Tabelle) – Abbildung im Code
 Prüfidee:      Beleg mit 3 Positionen erzeugt 1 Kopf- und 3 Positionsdatensätze mit gemeinsamer Kopf-ID.
 Tracelinks:    SyRS-007, SyRS-019
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-002
 Titel:         Ticket-Datenmodell mit Stammdimensionen und Historie (hlpdsk_*)
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal: -
 Akteur:        Software (Persistenz)
 Vorbedingung:  Ticket wird angelegt/geändert
 Fakt:          Kerntabelle hlpdsk_requests; Dimensionen hlpdsk_typen, hlpdsk_kategorien, hlpdsk_prioritaeten, hlpdsk_status; Mehrfach-Bearbeiter hlpdsk_request_bearbeiter; hlpdsk_history hält Änderungsverlauf; hlpdsk_timer speichert Zeiten; CacheTicketStatistic puffert Statistik; NotifyHelpdeskHistory dokumentiert Benachrichtigungen.
 Aussage:       Die Software soll Tickets mit referenzierbaren Stammdaten (Typ, Kategorie, Priorität, Status), beliebig vielen Bearbeitern, Zeitdaten und Änderungshistorie führen.
 Ergebnis:      Lückenlose, auswertbare Historie je Ticket.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE hlpdsk_requests (:4521), hlpdsk_status (:4628), hlpdsk_history (:18680), hlpdsk_timer (:18452), hlpdsk_request_bearbeiter (:18981) – durchgesetztes Datenmodell
 Prüfidee:      Statuswechsel erzeugt Eintrag in hlpdsk_history mit altem/neuem Status.
 Tracelinks:    SyRS-007, StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-003
 Titel:         Referenzielle Integrität überwiegend auf BL-Ebene (wenige FK-Constraints)
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Softwarearchitektur, Entwicklung
 Vorbedingung:  -
 Fakt:          Das Schema enthält 1535 Tabellen, 1482 PRIMARY KEYs, dagegen nur 134 Vorkommen von FOREIGN KEY (Zählung über Schema-Datei). Geschäftsregeln (z. B. „Stammblatt nicht löschbar bei aktivem Vertrag", MasterDataListBL.cs:163) werden in der BL durchgesetzt.
 Aussage:       [HYPOTHESE, risikorelevant für Migration] Die Software hat Referenzen zwischen Geschäftsobjekten bisher vorrangig in der Anwendungslogik statt per FK-Constraint abgesichert; im Zielsystem soll jede fachliche Referenz entweder per Constraint oder per nachweisbar zentralem Konsistenzdienst geschützt werden.
 Ergebnis:      Keine verwaisten Referenzen auch bei direkten DB-Zugriffen/Importen.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql – Zählung: 1535 CREATE TABLE, 1482 PRIMARY KEY, 134 FOREIGN KEY – quantitativer Nachweis
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163 – beispielhafte BL-Konsistenzprüfung
  - Es fehlt: systematische Katalogisierung aller BL-seitigen Konsistenzprüfungen (nur Stichproben) → HYPOTHESE
 Prüfidee:      Stichprobe: Löschen eines referenzierten Stammdatensatzes über rohe SQL ist möglich (Ist) – im Zielsystem wird es durch Constraint verhindert.
 Tracelinks:    SyRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Migrationsrisiko, in Zielarchitektur adressieren
 Status:        HYPOTHESE
 ```
 ```
 ID:            SwRS-004
 Titel:         Datenzugriffsschicht: DAOFactory, GenericDAO, Repositories, Named Queries, Stored Procedures
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Software-Komponenten
 Vorbedingung:  Session ist geöffnet (DAOSession)
 Fakt:          DAOFactory.cs (11 KB) erzeugt typspezifische DAOs; GenericDAO.cs (25 KB) und GenericStoredProcedureDAO.cs (20 KB) abstrahieren CRUD bzw. Prozeduraufrufe; AdoNETDataAccess sowie NamedQueries-Verzeichnis bedienen Spezialfälle; EventListener (TruncateStringsEventListener etc.) hängen in der NHibernate-Pipeline.
 Aussage:       Die Software soll Datenzugriffe ausschließlich über die DAO-Abstraktion führen (Generics für Standards, Repositories/Named Queries/Prozeduren für Spezialfälle), damit keine BL-Klasse rohe Verbindungen aufbaut.
 Ergebnis:      Austauschbare, testbare Zugriffsschicht.
 Belege:
  - [PRIMÄR] src/backend/Centron.DAO/{DAOFactory.cs, GenericDAO.cs, GenericStoredProcedureDAO.cs, DAOSession.cs} – Zugriffsarchitektur
  - [SEKUNDÄR] src/backend/Centron.DAO/{AdoNETDataAccess/, NamedQueries/, Repositories/} – Spezialkanäle
 Prüfidee:      Code-Review/Architekturtest: keine ADO.NET-Verbindung außerhalb von Centron.DAO.
 Tracelinks:    SyRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – ORM im Zielsystem neu bewerten (EF Core)
 Status:        belegt
 ```
 ```
 ID:            SwRS-005
 Titel:         Zentrale Beleglogik (ReceiptBL) mit typspezifischen Spezialisierungen
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Software-Komponenten (Verkauf/Einkauf)
 Vorbedingung:  Belegoperation wird ausgeführt
 Fakt:          ReceiptBL.cs (623 KB) und ReceiptItemBL.cs (230 KB) enthalten die Belegkernlogik; IReceiptSpecificLogic.cs (26 KB) definiert die Schnittstelle, SpecificLogics.cs registriert typspezifische Implementierungen je Belegart; ReceiptProgressionBL.cs steuert Belegfortschreibung, ReceiptTemplateBL.cs Vorlagen, ReceiptCompleteReasonBL.cs Abschlussgründe.
 Aussage:       Die Software soll gemeinsame Beleglogik zentral halten und belegartspezifisches Verhalten über die Schnittstelle IReceiptSpecificLogic auslagern.
 Ergebnis:      Neue Belegarten werden durch Spezialisierung statt Kopie ergänzt.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/{ReceiptBL.cs, IReceiptSpecificLogic.cs, SpecificLogics.cs} – zentrale Logik + Spezialisierungsmechanismus
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/{ReceiptProgressionBL.cs, ReceiptTemplateBL.cs, ReceiptCartBL.cs} – Nebenprozesse
 Prüfidee:      Belegart X nutzt gemeinsame Preis-/Steuerlogik, überschreibt aber Positionsvalidierung spezifisch.
 Tracelinks:    SyRS-019, SyRS-020, SyRS-021
 Konsolidierung: Kandidat: Aufteilung der 623-KB-Klasse in fachliche Module im Zielsystem (God-Class-Antipattern)
 Übernahmewürdigkeit: übernehmen – fachlich; strukturell refaktorisieren
 Status:        belegt
 ```
 ```
 ID:            SwRS-006
 Titel:         Suchkonfiguration je Belegart mit Rechte- und Branch-Properties
 Ebene:         SwRS
 Typ:           Daten/Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software (Suchen/Listen)
 Vorbedingung:  Benutzer startet Belegsuche
 Fakt:          Je Belegart existiert eine Klasse im Verzeichnis ReceiptSearch mit Properties ShowRight, OnlyOwnRight, OnlyOwnBranchRight sowie SQL-Fragmenten (z. B. ContractReceiptSearchConfiguration.cs:95: „IsMasterDataList = Cast(AK.Stammblattbezogen AS bit)"); Lieferanten- und Kundenbelege besitzen getrennte Konfigurationsklassen.
 Aussage:       Die Software soll jede Belegsuche über eine Konfiguration aufbauen, die Sichtrechte, Einschränkungen und SQL-Auswahl je Belegart kapselt.
 Ergebnis:      Einheitliches, erweiterbares Rechte-/Filterverhalten aller Beleglisten.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/{InvoiceReceiptSearchConfiguration.cs:152–157, ContractReceiptSearchConfiguration.cs:95/:168–173} – durchgesetzte Such-Rechte
  - [SEKUNDÄR] Weitere Konfigurationen: Offer/Order/DeliveryList/PickupList/CreditVoucher/Supplier* in demselben Verzeichnis – wiederholtes Muster
 Prüfidee:      Neue Belegart erhält Konfiguration; Suche filtert automatisch nach OnlyOwnBranch.
 Tracelinks:    SyRS-004
 Konsolidierung: Kandidat: 14 nahezu identische Konfigurationsklassen – im Zielsystem als generische, deklarative Belegtyp-Definition führen
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-007
 Titel:         Zentrale Rechteprüfungs-API (AppRightsBL)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software-Komponenten
 Vorbedingung:  Aktueller Benutzerkontext liegt vor
 Fakt:          AppRightsBL (src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs) bietet HasUserRight(userI3D, rightI3D), CheckRightsFromUser(userI3D, params rightIds) und GetRightsFromCurrentUser; Aufrufe erfolgen flächendeckend aus BL- und WebServiceBL-Klassen.
 Aussage:       Die Software soll Rechte ausschließlich über diese zentrale API ermitteln und prüfen (ein Recht, Rechtemenge oder komplettes Rechteprofil).
 Ergebnis:      Einheitliche Rechteauswertung; keine verstreuten Eigenimplementierungen.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:25 – Klassendefinition der zentralen Prüf-API
  - [KONTEXT] Aufrufnachweise u. a. in AccountBL.cs:282, PasswordManagerBL.cs:899, RmmConnectionSettingsWebServiceBL.cs:30
 Prüfidee:      HasUserRight liefert für fehlendes Recht false; CheckRightsFromUser liefert exakt die Teilmenge vorhandener Rechte.
 Tracelinks:    SyRS-003, SyRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-008
 Titel:         Rechte als versionierte, hierarchische Konstanten (UserRightsConst)
 Ebene:         SwRS
 Typ:           Daten/Sicherheit
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Entwicklung, Administration
 Vorbedingung:  Neues Feature benötigt neues Recht
 Fakt:          Rechte sind int-Konstanten in einer verschachtelten Konstantenstruktur (UserRightsConst.Sales.Customer.Helpdesk...; Purchase.StockList...; Administration...; Logistic.Commissioning...); neue Rechte werden per Datenmigrationsskript eingeführt (ScriptMethod11783.cs legt das Recht „Seriennummer Hauptgerät am Stammblatt ändern" mit deutscher Bezeichnung und Beschreibung an).
 Aussage:       Die Software soll Rechte als stabile numerische IDs in einer fachlich gruppierten Konstantenstruktur führen und neue Rechte über versionierte Migrationen einführen.
 Ergebnis:      Rechtekatalog ist erweiterbar, referenzierbar und historisch nachvollziehbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11783.cs (Anlage eines neuen Rechts via Migration) – Einführungsprozess
  - [SEKUNDÄR] CentronRights.md – fachliche Dokumentation einzelner IDs
 Prüfidee:      Migrationsskript ausführen → Recht erscheint in der Rechteverwaltung mit Text und Gruppe.
 Tracelinks:    SyRS-003, SwRS-016
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-009
 Titel:         Rechte-Durchsetzung im Helpdesk (HelpdeskBL)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software-Komponenten (Helpdesk)
 Vorbedingung:  Ticketoperation wird angestoßen
 Fakt:          HelpdeskBL.cs prüft vor Ausführung: Sichtrechte (SHOW_HELPDESK, ONLY_OWN, ONLY_OWN_BRANCH, Zeilen 271–284), Anlegen (ADD_NEW_HELPDESK:422), Bearbeiten (EDIT_HELPDESK:428), Abschluss (CLOSE_REQUEST:435), Fälligkeit (MATURITY_CHANGE:445) sowie Zuweisungsbegrenzung auf eigene Abteilung (ASSIGN_HELPDESK_ONLY_TO_OWN_DEPARTMENTS:454).
 Aussage:       Die Software soll jede Ticket-Zustandsänderung (ansehen, anlegen, bearbeiten, fällig machen, zuweisen, abschließen) vorab gegen das jeweils zugeordnete Recht prüfen.
 Ergebnis:      Ticketbearbeitung entlang des definierten Rechtekatalogs.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284, :422–454 – durchsetzende Stellen je Operation
  - [KONTEXT] CentronRights.md, Abschnitt Helpdesk – fachliche Zuordnung
 Prüfidee:      Jede der sechs Operationen wird ohne zugehöriges Recht abgelehnt.
 Tracelinks:    SyRS-003, SyRS-004, StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SwRS-010
 Titel:         CRUD-Rechte für Kunden/Adressen/Kontakte (AccountBL, AccountAddressBL, AccountAddressContactBL)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software-Komponenten (CRM)
 Vorbedingung:  Stammdatenoperation wird angestoßen
 Fakt:          AccountBL.cs:1305–1365 prüft CREATE_/EDIT_/DELETE_/SEARCH_CUSTOMER und UNLOCK_CUSTOMER; AccountAddressBL.cs:259–317 trennt CREATE_ADDRESS, EDIT_LOCATION, EDIT_CUSTOMER, Sprach-/Währungsänderung (EDIT_CUSTOMER_ADDRESS_LANGUAGE/-CURRENCY); AccountAddressContactBL.cs:379–413 unterscheidet Kunden- und Lieferantenkontakte (RIGHT_LIEFERANT...); AccountWebServiceBL.cs aggregiert dieselben Rechte für UI-Flags.
 Aussage:       Die Software soll jede Änderung an Geschäftspartnerstammdaten feld-/operationsscharf gegen Rechte prüfen und die Benutzeroberfläche anhand derselben Rechtemenge steuern.
 Ergebnis:      Kein unautorisierter Stammdaten-Write; UI zeigt nur erlaubte Aktionen.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressBL.cs:259–317 (je Änderungsart eigene Prüfung) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountAddressContactBL.cs:389–413 (Rollentrennung Kunde/Lieferant) – konkrete Bedingungen
 Prüfidee:      Währungsänderung ohne EDIT_CUSTOMER_ADDRESS_CURRENCY schlägt fehl, sonstige Felder bleiben speicherbar.
 Tracelinks:    SyRS-003, StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SwRS-011
 Titel:         Abrechnungsservice für Verträge (AutomaticFacturaWebServiceBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Software (Abrechnungslauf)
 Vorbedingung:  Verträge mit Abrechnungszeitraum vorhanden
 Fakt:          AutomaticFacturaWebServiceBL.cs stellt u. a. bereit: SearchBillingContractPos(:124) zur Ermittlung abrechenbarer Vertragspositionen, LoadBillingResult(dtFrom, dtTo, contractI3Ds) (:2370) für das Abrechnungsergebnis, GetContractPartibleArticlePositionen(:2376) für teilbare Artikel sowie Massenzuordnung von Sonderartikeln zu Verträgen (:894, :899, :904, :923); Zählerstände des Vorgänger-Stammblatts fließen in die Abrechnung ein (:1421).
 Aussage:       Die Software soll aus Verträgen periodische Abrechnungspositionen deterministisch ermitteln (Zeitraum, teilbare Artikel, Zählerstandsdifferenzen) und als Abrechnungsergebnis bereitstellen.
 Ergebnis:      Reproduzierbares Abrechnungsergebnis je Vertrag und Periode.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/CustomerAssets/AutomaticFactura/AutomaticFacturaWebServiceBL.cs, Methoden laut Zeilenangaben – durchsetzende Abrechnungslogik
 Prüfidee:      Zweimaliger Lauf mit identischen Parametern liefert identisches BillingResult (Determinismus).
 Tracelinks:    SyRS-019, StRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
 Status:        belegt
 ```
 ```
 ID:            SwRS-012
 Titel:         Passwort-Hashing mit SHA1 (Sicherheits-Migrationsfall)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software (Authentifizierung)
 Vorbedingung:  Passwort wird gesetzt oder geprüft
 Fakt:          Passwörter werden über SHA1Decoder.GetDecodedSHA1String gehasht – in UsersBL.cs:65/:88/:107 (Benutzer), WebAccountBL.cs:56/:192/:415/:480 (Web-Accounts) und BasicAuthenticator.cs:46 (Login-Vergleich). Gerätezugänge nutzen CryptoUtils.CreatePasswordHash (TicketBL.cs:169).
 Aussage:       Die Software soll Passwort-Hashing auf ein modernes, gesalzenes, rechenintensives Verfahren (z. B. Argon2/bcrypt/PBKDF2) umstellen; beim ersten erfolgreichen Login mit Alt-Hash soll transparent neu gehasht werden.
 Ergebnis:      Gespeicherte Passwort-Artefakte sind auch bei Datenabfluss nicht praktikabel rückrechenbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/UsersBL.cs:65/:88/:107; src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:56/:192/:415/:480; src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46 – konkrete Hash-Aufrufe
 Prüfidee:      Bestandsnutzer kann sich weiter anmelden (Alt-Hash-Verifikation); danach liegt neuer Hash im modernen Format vor.
 Tracelinks:    SyRS-005, SyRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: veraltet – SHA1 gilt als kryptografisch gebrochen; Funktion ersetzen, Migration der Hashes planen
 Status:        belegt
 ```
 ```
 ID:            SwRS-013
 Titel:         Zentraler Login-Dispatcher mit Fehlversuchs-Logging (Authenticator)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software (Authentifizierung)
 Vorbedingung:  Login-Request liegt vor
 Fakt:          Authenticator.cs wählt anhand der Konfiguration das Verfahren und ruft intern AuthenticateUser (Zeilen 106–109); erfolglose Anmeldungen werden geloggt (Zeile 161: „c-entron Login failed. No c-entron user with username and password hash was found.").
 Aussage:       Die Software soll Authentifizierungsverfahren über eine zentrale Komponente dispatchen und jeden Fehlversuch mit Benutzername/Grund (ohne Passwort) protokollieren.
 Ergebnis:      Auffällige Anmeldeserien sind auswertbar; Verfahrenswechsel ohne Code-Änderung an Aufrufern.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:106–109/:161 – Dispatcher + Logging
 Prüfidee:      Drei Fehlversuche erzeugen drei unabhängige Logeinträge mit Zeitstempel und Benutzername.
 Tracelinks:    SyRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-014
 Titel:         TOTP-2FA-Verwaltung und -Validierung (TwoFactorAuthenticationBL)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software (Authentifizierung)
 Vorbedingung:  Benutzer initiiert 2FA-geschützten Vorgang
 Fakt:          Drei Operationen: AppUserTwoFactorAuthKeyExists (prüft Vorhandensein), UpdateAppUserTwoFactorAuthKey (Named Query PasswordManager.UpdateAppUserTwoFactorAuthKey setzt Schlüssel je Benutzer), ValidateAuthenticationPin (holt Schlüssel via GetAppUserTwoFactorAuthKey, validiert via TwoFactorAuthenticator.ValidatePin; fachliche Fehlermeldungen bei fehlendem Schlüssel bzw. falscher PIN).
 Aussage:       Die Software soll TOTP-Schlüssel je Benutzer verwalten und PINs serverseitig validieren, mit klar getrennten Fehlerfällen (kein Schlüssel vs. falsche PIN).
 Ergebnis:      Zwei-Faktor-Prozess technisch durchsetzbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methoden ValidateAuthenticationPin/UpdateAppUserTwoFactorAuthKey/AppUserTwoFactorAuthKeyExists – vollständig gelesen
 Prüfidee:      PIN aus Authenticator-App mit identischem Secret → Erfolg; manipulierte PIN → Fehler „Die eingegebene PIN ist ungültig!".
 Tracelinks:    SyRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-015
 Titel:         Deklarative Rechte-Attribute für API-Controller
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Wartbarkeit/Sicherheit
 Akteur:        Software (API), Entwicklung
 Vorbedingung:  Neuer geschützter Endpunkt wird implementiert
 Fakt:          AuthorizeUserRightAttribute, AuthorizeAnyUserRightAttribute, AuthorizeAllUserRightsAttribute (je ~1,7–2 KB) kapseln die Prüfung als Authorization-Filter; AuthorizeCentronHostedAttribute/:CentronHostedAuthorization schränkt auf die gehostete Umgebung ein; README empfiehlt: komplexe fachliche Regeln bleiben in WebServiceBL, einfache Checks deklarativ.
 Aussage:       Die Software soll einfache Rechteprüfungen deklarativ an Controllern/Actions kennzeichnen und fachlich komplexe Prüfungen weiterhin in der Fachlogikschicht führen.
 Ergebnis:      Einheitliches, prüfbares Autorisierungsmuster ohne Codeduplikate.
 Belege:
  - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/{AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs, CentronHostedAuthorization.cs} – Filterimplementierung
  - [KONTEXT] src/webservice/Centron.Controllers/Authorization/README.md – Architekturleitlinie
 Prüfidee:      Controller-Methode mit [AuthorizeAllUserRights(A,B)] → Zugriff nur bei beiden Rechten.
 Tracelinks:    SyRS-002, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-016
 Titel:         Datenbank-Migrationen als versionierte C#-Skriptklassen (ScriptMethods)
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        System (Update-Prozess), Entwicklung
 Vorbedingung:  Softwareupdate wird eingespielt
 Fakt:          Unter Administration/Scripts/ScriptMethods/Scripts liegen numerierte Klassen (z. B. ScriptMethod11125.cs–ScriptMethod11799.cs), die SQL-DDL/-DML als eingebettete Statements enthalten (u. a. Fallunterscheidungen zu Stammblattbezogen/KontingentVertrag) und Rechte/Stammdaten nachziehen (ScriptMethod11783.cs).
 Aussage:       Die Software soll Schema- und Stammdatenänderungen ausschließlich über einmalig ausgeführte, numerisch versionierte Migrationsskripte einspielen (identifizierbar, protokollierbar).
 Ergebnis:      Reproduzierbarer Datenbestand über Installationen hinweg.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/Scripts/ScriptMethod11125.cs u. a. (nummerierte Skriptklassen mit SQL) – Migrationsmechanismus
  - [SEKUNDÄR] ScriptMethod11783.cs (Rechte-Stammdaten-Migration) – Beispiel
 Prüfidee:      Mehrfaches Ausführen derselben ScriptMethod verändert den Bestand nicht erneut (Idempotenz-SQL im Skript stichprobenartig zu verifizieren).
 Tracelinks:    SyRS-007, SwRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Konzept; im Zielsystem durch Migrations-Framework ersetzen
 Status:        belegt
 ```
 ```
 ID:            SwRS-017
 Titel:         Stammblatt-Fachregeln (MasterDataListBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Software (Service/Verträge)
 Vorbedingung:  Stammblatt (GeraeteKopf) wird bearbeitet
 Fakt:          MasterDataListBL.cs verhindert Löschen bei aktivem Vertrag (:163, DependencyCheckFailed); Entfernen/Ersetzen der Hauptgeräte-Seriennummer läuft über eigene Methoden mit Fehlerfällen „kein Stammblatt gefunden", „keine Seriennummer", „keine Hauptposition" (:294–:305); Barcode-Ablösung setzt DeviceHeadNumber/DevicePositionI3D zurück (Kommentar :425); Änderung schreibt Historieneintrag (:410); ein Stammblatt ohne Kundenbezug ist unzulässig (:895).
 Aussage:       Die Software soll den Lebenszyklus von Stammblättern (Gerätestammsätzen) absichern: Vertragsbindung verhindert Löschung, Seriennummernwechsel ist historisiert und erfordert gültige Ausgangsdaten, Kundenzuordnung ist Pflicht.
 Ergebnis:      Konsistente Gerätestammdaten mit Verlauf.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs:163, :294–305, :425, :895 – konkrete Prüfregeln
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/MasterDataLists/MasterDataListWebServiceBL.cs:172–188 (Seriennummernwechsel nur mit Recht CHANGE_MAIN_DEVICE_SERIAL_NUMBER) – Rechtebindung
 Prüfidee:      Löschversuch bei aktivem Vertrag → Fehler DependencyCheckFailed; Serienwechsel ohne Recht → Fehlermeldung mit RightCheckFailed.
 Tracelinks:    SyRS-019, StRS-004
 Konsolidierung: Kandidat: SyRS-030/StRS-012 (AssetManagement) – zwei Gerätemodelle zusammenführen
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-018
 Titel:         Seriennummern-Zustandsautomaten beim Umbuchen (BarcodeBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Lager, Software
 Vorbedingung:  Seriennummer existiert und hat einen Zustand (BarcodeState)
 Fakt:          BarcodeBL.cs:1091 lehnt die Umbuchung einer Seriennummer auf ein Stammblatt ab, wenn die Seriennummer nicht „im Lager" ist (Fehlertext mit Seriennummer); BarcodeState kennt u. a. „in Stammblatt" (BarcodeState.cs:19, Mapping in BarCode.cs:100); ReceiptItemBL.cs:314 verhindert doppelte Verwendung eines Stammblatts in Belegen („Stammblatt ist bereits in ... enthalten").
 Aussage:       Die Software soll Seriennummern zustandsbasiert führen und Zustandsübergänge (Lager ↔ Beleg ↔ Stammblatt) nur entlang zulässiger Regeln zulassen; Doppelverwendung wird verhindert.
 Ergebnis:      Keine widersprüchlichen Seriennummern-Positionen im System.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 (Zustandsprüfung vor Umbuchung) – konkrete Bedingung
  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs:314 (Doppelverwendungs-Prüfung) – konkrete Bedingung
  - [SEKUNDÄR] src/backend/Centron.Interfaces/Warehousing/BarcodeState.cs:19 – Zustandsdefinition
 Prüfidee:      Seriennummer im Zustand „in Stammblatt" kann nicht erneut ausgebucht werden; Umbuchung greift nur aus „im Lager".
 Tracelinks:    SyRS-019, StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-019
 Titel:         Rechte- und Regelschutz der Lagerverwaltung (ArticleBL, InventoryBL, OrderCommissionBL)
 Ebene:         SwRS
 Typ:           Sicherheit/funktional
 Qualitätsmerkmal: Sicherheit
 Akteur:        Software (Warenwirtschaft)
 Vorbedingung:  Lageroperation wird angestoßen
 Fakt:          ArticleBL.cs:999–1081 prüft STORE_ARTICLE, CREATE_NEW_ARTICLE, CHANGE_ARTICLE_PRICE, CHANGE_SERIALNUMBER_REQUIRED_FLAG (Flag-Änderung nur bei Berechtigung, :1035), EDIT_MaterialGroup und NOT_CHANGEABLE_ARTICLE_PROPERTIES (Sperrliste); SecondStockArticleBL.cs:108–111 verlangt TRANSFER_STOCK für Nebenlager-Umbuchung; InventoryBL.cs:77/:100/:198/:575/:963 erzwingt Inventurrechte; OrderCommissionBL.cs:431–438 und PartialCommissionOrderBL.cs:135/:170/:426/:453 setzen Kommissionierrechte.
 Aussage:       Die Software soll Lagerbewegungen, Preisänderungen, Stammdaten-Sperrfelder, Inventuren und (Teil-)Kommissionierungen jeweils gegen das zugeordnete Recht prüfen und den Zugriff sonst verweigern.
 Ergebnis:      Revisionssichere Lagerprozesse.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/ArticleBL.cs:1035 (Seriennummern-Pflichtflag gegen Recht) – konkrete Durchsetzung
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs:77/:100 – Inventur anlegen/verwerfen nur mit Recht
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/Commissions/PartialCommissionOrderBL.cs:135/:170 – Teilkommission Create/Delete nur mit Recht
 Prüfidee:      Negativbuchung ohne BOOK_ARTICLE_STOCK_INTO_NEGATIVE scheitert; Inventurverwerfen ohne DROP_INVENTORY scheitert.
 Tracelinks:    SyRS-003, StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SwRS-020
 Titel:         Wiedervorlagen und Fremd-ToDo-Rechte (ToDoBL)
 Ebene:         SwRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: -
 Akteur:        Anwender
 Vorbedingung:  ToDo/Wiedervorlage existiert
 Fakt:          ToDoBL.cs hält Objektarten je Fachobjekt (u. a. Wiedervorlage Geräte/Stammblatt AssetKind 11, Zeilen 86/:161); RIGHT_FREMDTODOLISTE erlaubt Zugriff auf ToDos anderer Benutzer (:1993), RIGHT_FREMDTODOLISTEVERWERFEN deren Verwerfen (:310, mit Code-Kommentar zur Grundsatzfrage).
 Aussage:       Die Software soll Aufgaben/Wiedervorlagen objekttypisiert führen und den Zugriff auf fremde Aufgabenlisten sowie deren Verwerfen nur mit gesonderten Rechten erlauben.
 Ergebnis:      Datenschutzkonforme Aufgabentrennung mit Steuerungsrechten.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/ToDoArea/ToDoBL.cs:310, :1993 (Rechteprüfungen) – durchsetzende Stellen
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ToDoListe – Datenanker
 Prüfidee:      Ohne RIGHT_FREMDTODOLISTE sind fremde ToDos weder sicht- noch verwerfbar.
 Tracelinks:    SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-021
 Titel:         Checklisten-Verwaltung und -Verarbeitung (CentronChecklistBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Servicetechniker, Qualitätsmanagement
 Vorbedingung:  Checklistenvorlage existiert
 Fakt:          CentronChecklistBL.cs (19 KB) und UpdateChecklistBL.cs verwalten Checklisten; Rechte unterscheiden Vorlagen anlegen/bearbeiten, Checklisten bearbeiten und Bearbeiter einzelner Punkte ändern (CREATE_NEW_CHECKLIST_TEMPLATES, EDIT_CHECKLIST_TEMPLATES, EDIT_CHECKLISTS, EDIT_CHECKLIST_ITEM_EDITOR); der Webservice umgeht Einzelprüfungen für Admins (CentronChecklistWebserviceBL.cs:160–162).
 Aussage:       Die Software soll Checklisten aus Vorlagen instanziieren, Punkte einzelnen Bearbeitern zuweisen und Bearbeitungsstände rechtgeschützt pflegen.
 Ergebnis:      Nachvollziehbar abgearbeitete Prüf-/Arbeitslisten je Vorgang.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/CheckListArea/CentronChecklistWebserviceBL.cs:160–162 (Admin-Ausnahme + Recht EDIT_CHECKLIST_ITEM_EDITOR) – durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/CheckListArea/{CentronChecklistBL.cs, UpdateChecklistBL.cs} – Fachlogik
  - [KONTEXT] CentronRights.md, Abschnitt 16 (Checklisten-Rechte) – Katalog
 Prüfidee:      Bearbeiterwechsel an einem Checklistenpunkt ohne EDIT_CHECKLIST_ITEM_EDITOR schlägt fehl (außer Admin).
 Tracelinks:    SyRS-003, StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-022
 Titel:         Produktionsaufträge mit Arbeitsschritten und Zeiterfassung
 Ebene:         SwRS
 Typ:           funktional/Daten
 Qualitätsmerkmal: -
 Akteur:        Produktionsmitarbeiter
 Vorbedingung:  Fertigungsartikel mit Produktionsschritten ist angelegt
 Fakt:          ProductionBL.cs (13 KB) und ProductionOrderBL.cs (9 KB) bilden die BL; das Schema führt ArticleProductionOrders, ArticleProductionStep(s), ArticleProductionOrderStepItems, ArticleProductionMaterials sowie Zeitdaten (ArticleProductionOrderStepItemTimes, ...TimeDataRecordings) und Arbeitspläne (Arbeitsplan*, Arbeitsschritt*); der Nexus-Bereich ProductionOrderManagement stellt eine Web-Oberfläche.
 Aussage:       Die Software soll Produktionsaufträge aus Arbeitsplänen erzeugen, Material- und Arbeitsschritte je Position führen und Zeitdaten je Schritt erfassen.
 Ergebnis:      Auswertbare Produktionszeiten und -fortschritte je Auftrag.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArticleProductionOrders (:20517), ArticleProductionStep (:20496), ArticleProductionOrderStepItemTimes (:26066) – Datenmodell
  - [SEKUNDÄR] src/backend/Centron.BL/Production/{ProductionBL.cs, ProductionOrderBL.cs}; src/nexus/CentronNexus/ProductionOrderManagement/ – Logik/Oberfläche
 Prüfidee:      Produktionsauftrag enthält alle Arbeitsplang-Schritte; gebuchte Zeit ist Schritt zuordenbar.
 Tracelinks:    SyRS-010, StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-023
 Titel:         Lagerorte/Lagerplätze und Nebenlager (StorageBL)
 Ebene:         SwRS
 Typ:           Daten/funktional
 Qualitätsmerkmal: -
 Akteur:        Lager
 Vorbedingung:  Artikel ist lagerpflichtig
 Fakt:          StorageBL.cs (45 KB) verwaltet Lagerorte/-plätze (Tabellen Lagerort, Lagerplatz); SecondStockArticleBL (Nebenlager) verlangt für Umbuchungen TRANSFER_STOCK; das Schema kennt NebenlagerArtikel; InventoryArticlePool.cs definiert Inventur-Pools.
 Aussage:       Die Software soll Bestände je Lagerort/Lagerplatz führen, Nebenlager unterstützen und Umbuchungen zwischen Lagern rechtegeschützt buchen.
 Ergebnis:      Ortsscharfe Bestandsführung über Haupt- und Nebenlager.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/Storage/StorageBL.cs – Lagerortlogik (flach analysiert)
  - [PRIMÄR] src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs:108–111 (TRANSFER_STOCK-Prüfung) – Rechte-Durchsetzung Nebenlager
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Lagerort, Lagerplatz, NebenlagerArtikel – Datenmodell
 Prüfidee:      Umbuchung Hauptlager→Nebenlager ohne TRANSFER_STOCK schlägt fehl; Bestand ist je Lagerort getrennt ausgewiesen.
 Tracelinks:    SyRS-003, StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-024
 Titel:         RMA-Prozess (RmaBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Service/Disposition
 Vorbedingung:  Ware soll retourniert werden
 Fakt:          RmaBL.cs (110 KB) ist eine eigene Geschäftslogik; Kerntabelle Rma plus Versandart (RmaSendKindBL); BL/CustomerArea enthält zudem Kunden-Prozesse wie Interessen (InterestBL) und Produktzuordnung (ProductBL).
 Aussage:       Die Software soll Retouren (RMA) als eigenen Vorgangstyp mit eigener Versandart-Steuerung führen und an Kundenvorgänge koppeln.
 Ergebnis:      Nachverfolgbare Retourenabwicklung.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/CustomerArea/RmaBL.cs, RmaSendKindBL.cs – implementierte Prozesslogik
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Rma (:4145) – Datenmodell
 Prüfidee:      RMA-Vorgang trägt Kunde, Artikel/Bezug und Versandart; Zustandswechsel ist dokumentiert.
 Tracelinks:    StRS-003, StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Prozessdetails in Folgeiteration vertiefen
 Status:        belegt
 ```
 ```
 ID:            SwRS-025
 Titel:         Projekt-, Prozess- und Ereignissteuerung (ProcessBL, ProjectBL, TicketProjectBL, ExpectedEventsBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Projektleiter, Organisation
 Vorbedingung:  Projekt/Prozessdefinition existiert
 Fakt:          ProcessBL.cs (28 KB) implementiert Prozesslogik; ProjectBL.cs (klein) und TicketProjectBL.cs (10 KB) koppeln Projekte an Tickets; ExpectedEventsBL.cs (10 KB) verwaltet erwartete Ereignisse; Schema enthält CRMProjekt/CRMProjektObjekt.
 Aussage:       Die Software soll Geschäftsprozesse und Projekte (inkl. Ticket-Projekt-Zuordnung und erwarteter Ereignisse) als eigenständige, referenzierbare Objekte führen.
 Ergebnis:      Projekte bündeln Tickets/Belege; Ereignissteuerung liefert Folgeaktionen.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/Processes/ProcessBL.cs; Projects/ProjectBL.cs; TicketProjects/TicketProjectBL.cs; ExpectedEvents/ExpectedEventsBL.cs – Modulklassen (flach analysiert)
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE CRMProjekt (:20116), CRMProjektObjekt – Datenmodell
 Prüfidee:      Projekt aggregiert zugeordnete Tickets und Objekte in einer Sicht.
 Tracelinks:    StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-026
 Titel:         Ticket-Ansichten (Views) global vs. benutzerbezogen (NexusTicketViewWebServiceBL)
 Ebene:         SwRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: -
 Akteur:        Helpdesk-Anwender
 Vorbedingung:  Ticketliste wird konfiguriert
 Fakt:          NexusTicketViewWebServiceBL.cs erfordert für das Anlegen/Ändern/Löschen globaler Ansichten das Recht Administration.EDIT_GLOBAL_PROFILES (:44, :66, :76, :88, :105, :124); private Ansichten sind davon ausgenommen.
 Aussage:       Die Software soll gespeicherte Ticket-Ansichten (Filter/Sortierungen) benutzerbezogen und global unterscheiden und globale Ansichten nur durch Berechtigte verwalten lassen.
 Ergebnis:      Standardisierte Arbeitsoberflächen im Helpdesk ohne unkontrollierte globale Änderungen.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/NexusTicketViews/NexusTicketViewWebServiceBL.cs:44–124 (Rechteprüfung je globalem Vorgang) – durchsetzende Stelle
 Prüfidee:      Globale Ansicht ohne EDIT_GLOBAL_PROFILES kann nicht gespeichert werden; private Ansicht jederzeit.
 Tracelinks:    SyRS-003, StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-027
 Titel:         Textbausteine und Anrede-/Einverständnis-Variablenersetzung (TextModuleBL)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Anwender (Schreibverkehr)
 Vorbedingung:  Textbaustein/Platzhalter ist definiert
 Fakt:          TextModuleBL.cs (30 KB) verwaltet Textbausteine; SalutationAndAgreementReplacementBL.cs (19 KB) ersetzt Anrede- und Einverständnis-Variablen; Schema führt GeschaeftspartnerTextbausteine; die Mail-Verarbeitung besitzt ein separates VariableReplacement-Verzeichnis – Platzhalterlogik existiert an mehreren Stellen.
 Aussage:       Die Software soll wiederkehrende Texte als Bausteine verwalten und Platzhalter (Anrede, Einverständniserklärung u. a.) kontextabhängig befüllen.
 Ergebnis:      Konsistente, personalisierte Dokumente und Mails.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/TextModuleArea/{TextModuleBL.cs, SalutationAndAgreementReplacementBL.cs} – Baustein-/Ersetzungslogik
  - [SEKUNDÄR] src/backend/Centron.BL/Mail/VariableReplacement/ – zweite Ersetzungsimplementierung
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE GeschaeftspartnerTextbausteine – Datenanker
 Prüfidee:      Dokument mit Anrede-Platzhalter wird mit anredekonformem Text an den Belegempfänger gerendert.
 Tracelinks:    SyRS-023, SyRS-018
 Konsolidierung: Kandidat: Platzhalter-/Ersetzungslogik an mehreren Stellen (TextModuleArea vs. Mail/VariableReplacement vs. ReportEngine ReplacementBLs) – im Zielsystem zentralisieren
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-028
 Titel:         Schutz vor Datenbank-Längenüberschreitungen auf ORM-Ebene
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Software (Persistenz)
 Vorbedingung:  Entität mit String-Feldern wird gespeichert
 Fakt:          TruncateStringsEventListener.cs und StringOrBinaryDataWouldBeTruncatedEventListener.cs sind NHibernate-Event-Listener: Einer kürzt zu lange Strings, der andere fängt den SQL-Fehler „String or binary data would be truncated" ab/erweitert Diagnose; WhyIsMyEntityUpdatedEventListener.cs unterstützt die Fehlersuche bei unerwarteten Updates.
 Aussage:       Die Software soll Zeichenketten vor dem Speichern auf die Spaltenlänge begrenzen bzw. Truncation-Fehler diagnosesicher behandeln, statt mit generischem SQL-Error abzustürzen.
 Ergebnis:      Keine unkontrollierten Speicherabbrüche durch zu lange Eingaben; Diagnose im Fehlerfall.
 Belege:
  - [PRIMÄR] src/backend/Centron.DAO/{TruncateStringsEventListener.cs, StringOrBinaryDataWouldBeTruncatedEventListener.cs} – technische Durchsetzung in der Persistenzpipeline
 Prüfidee:      300-Zeichen-Text in 255er-Spalte wird gekürzt gespeichert bzw. liefert Fehler mit Feld/Tabellenangabe.
 Tracelinks:    SyRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: Workaround – kürzen statt validieren maskiert Eingabefehler; im Zielsystem durch Eingabevalidierung ersetzen
 Status:        belegt
 ```
 ```
 ID:            SwRS-029
 Titel:         Objekttypen-Katalog und externe Referenzen (CentronObjectKindNumeric, ObjectExternalReferences)
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Software-Komponenten
 Vorbedingung:  Verknüpfung zwischen Objekten oder zu externen Systemen wird angelegt
 Fakt:          CentronObjectKindNumeric.cs bildet Objektarten numerisch ab (z. B. MasterDataListClass → „Stammblatt", :314); ToDo- und Rechteprüfungen referenzieren dieselben Konstanten; BL/ObjectExternalReferences kapselt Fremdschlüssel zu externen Systemen.
 Aussage:       Die Software soll Geschäftsobjektarten über einen zentralen numerischen Katalog identifizieren und externe Referenzen (Drittsystem-IDs) getrennt führen.
 Ergebnis:      Typsichere Objektverknüpfungen und nachverfolgbare Fremdbezüge.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs (:314) – Objektarten-Katalog
  - [SEKUNDÄR] src/backend/Centron.BL/ObjectExternalReferences/ – Fremdschlüssel-Verwaltung (flach analysiert)
 Prüfidee:      Fremdschlüssel eines Drittsystems ist dem internen Objekt einschließlich Objektart eindeutig zugeordnet.
 Tracelinks:    SyRS-007, SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-030
 Titel:         RADIUS-basierte Zwei-Faktor-Authentifizierung im Login-Fluss
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Benutzer, Software
 Vorbedingung:  RADIUS-Server ist konfiguriert; Benutzer hat RADIUS-2FA aktiviert
 Fakt:          Unter Administration/Logins/TwoFactor existieren RadiusClient.cs, RadiusPaketParser.cs (RFC-konforme Paketbehandlung: SharedSecret, Request/Response-Authenticator via MD5/HMACMD5, Password-Decrypt/-Encrypt) und EmailTwoFactorValidator.cs. Die Einbindung in den Authenticator-Loginpfad wurde nicht festgestellt.
 Aussage:       [HYPOTHESE] Die Software soll als Alternative zur TOTP-2FA (SwRS-014) auch RADIUS-/E-Mail-basierte Zweitfaktoren unterstützen.
 Ergebnis:      Unternehmen mit bestehender RADIUS-Infrastruktur können 2FA zentral betreiben.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/TwoFactor/{RadiusClient.cs, RadiusPaketParser.cs, EmailTwoFactorValidator.cs} – vollständige Implementierung der Protokollschicht
  - Es fehlt: Nachweis der Durchsetzung im Login-Ablauf (Authenticator.cs-Kopplung nicht geprüft) → HYPOTHESE
 Prüfidee:      Login mit RADIUS-Account erfordert und verdrahtet den zweiten Faktor gegen den Test-RADIUS-Server.
 Tracelinks:    SyRS-005, SyRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        HYPOTHESE
 ```
 ```
 ID:            SwRS-031
 Titel:         TradePool-Zugang mit eigenem Login (TradeCustomerLogin)
 Ebene:         SwRS
 Typ:           Schnittstelle/Sicherheit
 Qualitätsmerkmal: -
 Akteur:        Handelspartner (TradePool-Teilnehmer)
 Vorbedingung:  TradePool-Zugang ist freigeschaltet
 Fakt:          TradePoolBL.cs:170 stellt AuthenticateUser(userName, password) bereit und liefert ein TradeCustomerLogin-Objekt; das Modul enthält ein Core-Verzeichnis.
 Aussage:       [HYPOTHESE] Die Software soll einem B2B-Handelsplatz („TradePool") einen eigenen, ERP-seitig authentifizierten Zugang für Handelskunden bieten.
 Ergebnis:      Handelspartner erhalten sessionbasierten Zugriff auf TradePool-Funktionen.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/TradePool/TradePoolBL.cs:170 (AuthenticateUser-Signatur und Rückgabetyp) – Schnittstelle
  - Es fehlt: Geschäftsprozess/Nutzungskontext des TradePool (nur Klasse gesehen) → HYPOTHESE
 Prüfidee:      Gültige Credentials liefern TradeCustomerLogin; ungültige werden abgelehnt.
 Tracelinks:    SyRS-005, StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: Sonderfall – Eigenwelt TradePool bei Migration separat bewerten
 Status:        HYPOTHESE
 ```
 ```
 ID:            SwRS-032
 Titel:         Mobile Anbindung und Verbindungsmanagement
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Mobile Nutzer, Software
 Vorbedingung:  Webservice ist erreichbar
 Fakt:          BL/Mobile enthält mobile Fachlogik; das eigenständige Projekt c-entron.misc.ConnectionManager kapselt Verbindungseinstellungen; Centron.Gateway (src/backend) stellt eine Gateway-Schicht; der WPF-Client überwacht die Verbindung per ConnectionHeartbeatTimer.
 Aussage:       Die Software soll mobile/entfernte Clients über eine abgesicherte Verbindungsschicht anbinden und Verbindungsverluste erkennen.
 Ergebnis:      Stabile Nutzung mobiler/entfernter Arbeitsplätze.
 Belege:
  - [SEKUNDÄR] src/webservice/c-entron.misc.ConnectionManager/, src/backend/Centron.BL/Mobile/, src/backend/Centron.Gateway/ – Anbindungskomponenten (flach analysiert)
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs – Verbindungsüberwachung im Client
 Prüfidee:      Temporärer Verbindungsabbruch wird erkannt, Client meldet und versucht Wiederverbindung.
 Tracelinks:    SyRS-001, SyRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Detailtiefe in Folgeiteration
 Status:        belegt
 ```
 ```
 ID:            SwRS-033
 Titel:         Gutscheinverwaltung (VoucherManagement)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Vertrieb/Buchhaltung
 Vorbedingung:  Gutschein soll ausgestellt/eingelöst werden
 Fakt:          VoucherManagementBL.cs (Basis-Implementierung, 1,2 KB) existiert als eigenes BL-Modul; Guthaben-/Gutschriftsbelege sind separat modelliert (GutKopf/GutPos siehe SwRS-001).
 Aussage:       Die Software soll Gutscheine als eigenes Objekt verwalten (Ausgabe/Einlösung), getrennt von Gutschriftsbelegen.
 Ergebnis:      Gutschein-Lebenszyklus nachvollziehbar.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs – dediziertes Modul (flach, noch Basisstand)
 Prüfidee:      Gutschein erhält Code/Wert und kann genau einmal eingelöst werden.
 Tracelinks:    StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Ausbau prüfen (Modul wirkt rudimentär)
 Status:        belegt
 ```
 ```
 ID:            SwRS-034
 Titel:         Änderungsverfolgung (ChangeTracking) über Geschäftsobjekte
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        System, Revision
 Vorbedingung:  Objekt wird geändert/importiert
 Fakt:          Es existieren ChangeTracking-Verzeichnisse in BL und DAO (inkl. History) sowie eine ImportKind-Enumeration, die Änderungsquellen beschreibt (u. a. „Stammblatt", ImportKind.cs:17); ReceiptLogBL und HelpdeskTimerLogBL schreiben fachliche Änderungsjournale; AnlageLog/AccountLogs sind eigene Log-Tabellen.
 Aussage:       Die Software soll fachlich relevante Änderungen an Geschäftsobjekten mit Quelle (Benutzer/Import/Prozess) zeitlich nachvollziehbar protokollieren.
 Ergebnis:      Änderungshistorie für Audit und Fehleranalyse.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/ChangeTracking/History/, src/backend/Centron.DAO/ChangeTracking/, src/backend/Centron.Interfaces/ChangeTracking/History/ImportKind.cs – Tracking-Infrastruktur
  - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskTimerLogBL.cs:183 (Alt-/Neu-Protokollierung, z. B. Stammblattwechsel) – konkretes Änderungsjournal
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AccountLogs, AnlageLog – Log-Tabellen
 Prüfidee:      Feldänderung erzeugt Logeintrag mit Alt-/Neuwert und Quelle.
 Tracelinks:    SyRS-019
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SwRS-035
 Titel:         Entity-Mapping (Fluent NHibernate) je Geschäftsobjekt
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Software (Persistenz), Entwicklung
 Vorbedingung:  Neues Datenbankfeld/-tabelle wird eingeführt
 Fakt:          Die Mappings liegen konventionsgetrieben im Verzeichnis Centron.DAO/Mappings je Fachbereich (z. B. EmployeeArea/EmployeeMaps.cs bildet MasterDataListView auf Spalte „StammblattAnsicht" ab; TemporaryEntities/VertragKopfMaps.cs mappt Stammblattbezogen); Spalten bleiben deutsch benannt.
 Aussage:       Die Software soll jede persistente Entität über ein explizites, versionierbares Mapping auf ihre Tabelle/Spalten abbilden.
 Ergebnis:      Nachvollziehbare, refaktorierfeste Schema-Kopplung.
 Belege:
  - [PRIMÄR] src/backend/Centron.DAO/Mappings/EmployeeArea/EmployeeMaps.cs:80; Mappings/TemporaryEntities/VertragKopfMaps.cs:115 – konkrete Mappingbeispiele
  - [SEKUNDÄR] src/backend/Centron.Entities/Entities/** – Entitäten
 Prüfidee:      Spaltenumbenennung ohne Mapping-Anpassung bricht Build- bzw. Integrationstest erkennbar.
 Tracelinks:    SyRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
@@ -0,0 +1,664 @@
 # SyRS – System Requirements Specification (c-entron ERP, Reverse Engineering)
 Normbezug: ISO/IEC/IEEE 29148:2018. Tracelinks zur fachlichen Herkunft siehe jeweils Feld `Tracelinks` und `Traceability.md`.
 ---
 ```
 ID:            SyRS-001
 Titel:         Versionierte REST-API (v1)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: -
 Akteur:        Externe Clients, Web-Frontend
 Vorbedingung:  API-Host läuft; Client ist authentifiziert
 Fakt:          Controller liegen unter src/webservice/Centron.Controllers/Controllers/v1 in fachlichen Bereichen (Accounts, Administration, Contracts, Customers, DataExchange, Helpdesks, Integrations, Nexoware, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion); Routen nutzen apiVersion-Templating (README: "v{version:apiVersion}/...").
 Aussage:       Das System soll seine Geschäftsfunktionen über eine versionierte HTTP-REST-API (Namespace v1) bereitstellen, damit Änderungen der API abwärtskompatibel eingeführt werden können.
 Ergebnis:      Clients sprechen stabile, versionierte Endpunkte je Fachbereich an.
 Belege:
  - [PRIMÄR] src/webservice/Centron.Controllers/Controllers/v1/* (Bereichsverzeichnisse) – Struktur der API
  - [SEKUNDÄR] src/webservice/Centron.Controllers/Authorization/README.md – dokumentiertes Routing-Muster
 Prüfidee:      GET auf v1-Endpunkt eines Fachbereichs liefert 2xx/4xx, nie 404 bei bestehender Version.
 Tracelinks:    StRS-003, StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-002
 Titel:         Rechte-Durchsetzung auf API-Ebene mit HTTP 401/403
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        System (API-Pipeline)
 Vorbedingung:  Geschützter Endpunkt wird aufgerufen
 Fakt:          Attribute AuthorizeUserRightAttribute, AuthorizeAnyUserRightAttribute, AuthorizeAllUserRightsAttribute (und AuthorizeCentronHostedAttribute) laufen als Authorization-Filter vor der eigentlichen Aktion; laut README liefert die Pipeline 401 bei fehlender Authentifizierung und 403 bei fehlendem Recht; die Prüfung erfolgt über HasUserRight().
 Aussage:       Das System soll jeden API-Aufruf deklarativ gegen die geforderten Benutzerrechte prüfen (einzeln, mindestens eines oder alle) und bei Verstoß mit 401/403 ablehnen, bevor Geschäftslogik ausgeführt wird.
 Ergebnis:      Kein Zugriff auf geschützte Ressourcen ohne gültige Anmeldung und Recht.
 Belege:
  - [PRIMÄR] src/webservice/Centron.Controllers/Authorization/AuthorizeUserRightAttribute.cs, AuthorizeAnyUserRightAttribute.cs, AuthorizeAllUserRightsAttribute.cs (inkl. Verhalten laut README: Filter vor Action, 401/403) – durchsetzende Stelle
  - [SEKUNDÄR] src/webservice/Centron.Controllers/Authorization/README.md (Tab. „HTTP Response Codes") – spezifiziert Antwortverhalten
 Prüfidee:      Aufruf ohne Token → 401; mit Token ohne Recht → 403; mit Recht → 200.
 Tracelinks:    StRS-014, SwRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SyRS-003
 Titel:         Zentrale Rechte-Durchsetzung in der Geschäftslogik
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        System (Business Layer)
 Vorbedingung:  Geschäftsoperation wird ausgelöst (UI, API oder Hintergrundjob)
 Fakt:          AppRightsBL (Administration/Rights) stellt HasUserRight(userI3D, rightI3D), CheckRightsFromUser und GetRightsFromCurrentUser bereit; BL-Klassen prüfen jeweils vor der Operation (Beispiele: AccountBL, HelpdeskBL, ArticleBL, InventoryBL, PasswordManagerBL); UserRightsConst enthält numerische Rechte-IDs.
 Aussage:       Das System soll sämtliche sicherheitsrelevanten Geschäftsoperationen unabhängig vom Aufrufkanal (UI, API, Job) in der Geschäftslogiksschicht gegen Benutzerrechte prüfen und bei fehlendem Recht mit Fehler abbrechen.
 Ergebnis:      Rechteprüfung kann clientseitig nicht umgangen werden.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs:25 (Klasse mit HasUserRight/CheckRightsFromUser) – zentrale Prüf-API
  - [PRIMÄR] src/backend/Centron.BL/Accounts/AccountBL.cs:1305–1365; src/backend/Centron.BL/Warehousing/ArticleBL.cs:999–1081 (Prüfung vor Persistierung) – durchsetzende Stellen
  - [KONTEXT] CentronRights.md – Rechtekatalog
 Prüfidee:      Direkter BL-Aufruf ohne Recht schlägt mit Fehlercode (z. B. RightCheckFailed) fehl.
 Tracelinks:    StRS-002, StRS-014, SwRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SyRS-004
 Titel:         Einschränkende Sichtbarkeitsrechte in Suchen (nur eigene / nur eigene Filiale)
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        System (Suchfunktionen)
 Vorbedingung:  Benutzer besitzt einschränkendes Recht (*_ONLY_OWN, *_ONLY_OWN_BRANCH, SHOW_ONLY_OWN_CUSTOMER)
 Fakt:          Je Belegart existiert eine ReceiptSearchConfiguration mit Properties ShowRight, OnlyOwnRight, OnlyOwnBranchRight (z. B. InvoiceReceiptSearchConfiguration.cs:152–157, ContractReceiptSearchConfiguration.cs:168–173); HelpdeskBL.cs:271–284 und AccountSearchBL.cs:76/214/331 wenden analoge Filter für Tickets und Kunden an; Kalendersichten nutzen RIGHT_KALENDERANZEIGENEIGENE/-ALLE (ScheduleBL.cs:372–378, 693–697).
 Aussage:       Das System soll Such- und Listenabfragen (Belege, Tickets, Kunden, Kalender, Statistiken) automatisch auf die dem Benutzer erlaubte Datenmenge einschränken.
 Ergebnis:      Einschränkende Rechte wirken filternd auf Datenebene, nicht nur in der Oberfläche.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptSearch/InvoiceReceiptSearchConfiguration.cs:152–157 (ShowRight/OnlyOwn-/OnlyOwnBranchRight als Teil der Suchkonfiguration) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 – Ticketfilterung
  - [SEKUNDÄR] CentronRights.md (restricting rights) – fachliche Semantik
 Prüfidee:      Benutzer mit EDIT_OFFER_ONLY_OWN_BRANCH kann nur Belege der eigenen Filiale öffnen.
 Tracelinks:    StRS-002, SwRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Berechtigung)
 Status:        belegt
 ```
 ```
 ID:            SyRS-005
 Titel:         Mehrere Authentifizierungsverfahren (lokal, Active Directory, Basic)
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Benutzer, System
 Vorbedingung:  Benutzerkonto existiert
 Fakt:          Authenticator.cs zentralisiert die Anmeldung (AuthenticateUser; Fehlversuche werden geloggt: Zeile 161 „c-entron Login failed..."); ActiveDirectoryAuthenticator.cs prüft optional den Zertifikats-Hash der Domäne (GetDomainCertificateHash aus WebServiceConfigHelper); BasicAuthenticator.cs:46 decodiert das Passwort als SHA1; TradePoolBL.cs:170 besitzt ein eigenes AuthenticateUser für TradePool-Logins.
 Aussage:       Das System soll Benutzer wahlweise gegen die lokale Benutzerverwaltung oder das Active Directory authentifizieren, Fehlversuche protokollieren und bei AD optional das Serverzertifikat verifizieren.
 Ergebnis:      Nur erfolgreich authentifizierte Benutzer erhalten eine Sitzung; Fehlversuche sind nachvollziehbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/Authenticator.cs:106–109, :161 (Authentifizierung + Fehlversuchs-Logging) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/Administration/Logins/Auth/ActiveDirectoryAuthenticator.cs:151–156 (Zertifikatsprüfung) – konkrete Bedingung
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/Auth/BasicAuthenticator.cs:46 – SHA1-Passwortprüfung
 Prüfidee:      Falsches Passwort erzeugt Logeintrag und keine Sitzung; AD-Login mit falschem Zertifikat-Hash schlägt fehl.
 Tracelinks:    StRS-014, SwRS-012, SwRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Sicherheit); Hashverfahren separat modernisieren (SwRS-012)
 Status:        belegt
 ```
 ```
 ID:            SyRS-006
 Titel:         Zwei-Faktor-Authentifizierung per TOTP (Google Authenticator)
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Benutzer
 Vorbedingung:  Dem Benutzer ist ein TwoFactorAuthKey in der Personalverwaltung hinterlegt
 Fakt:          TwoFactorAuthenticationBL.ValidateAuthenticationPin lädt den Benutzerschlüssel (Named Query PasswordManager.GetAppUserTwoFactorAuthKey) und prüft die PIN über Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin; ohne hinterlegten Schlüssel liefert die Methode eine Fehlermeldung („Ihrem Benutzer ist kein Zwei-Faktor Schlüssel ... hinterlegt").
 Aussage:       Das System soll die zweite Faktor-Stufe als zeitbasierte Einmal-PIN (TOTP) validieren und Benutzer ohne hinterlegten Schlüssel mit fachlicher Fehlermeldung ablehnen.
 Ergebnis:      Anmeldung bzw. geschützte Aktion nur mit gültiger TOTP-PIN.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs, Methoden ValidateAuthenticationPin, UpdateAppUserTwoFactorAuthKey (Named Queries PasswordManager.GetAppUserTwoFactorAuthKey/UpdateAppUserTwoFactorAuthKey) – durchsetzende Stelle
  - [SEKUNDÄR] Verweis auf Centron.Core.GoogleAuthenticator.TwoFactorAuthenticator.ValidatePin – TOTP-Bibliothek
 Prüfidee:      Gültige aktuelle PIN wird akzeptiert, abgelaufene PIN abgelehnt; Benutzer ohne Schlüssel erhält definierte Fehlermeldung.
 Tracelinks:    StRS-014, SyRS-005, SwRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Sicherheit)
 Status:        belegt
 ```
 ```
 ID:            SyRS-007
 Titel:         Persistenz über Microsoft SQL Server mit NHibernate-ORM
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        System
 Vorbedingung:  Datenbank ist erreichbar
 Fakt:          Centron.DAO kapselt den Zugriff (GenericDAO, GenericStoredProcedureDAO, DAOFactory, DAOSession, NHibernateConfiguration, Repositories, NamedQueries); das mitgelieferte Schema SSMS_DB_SCHEMA.sql definiert 1535 Tabellen mit 1482 PRIMARY-KEY- und nur 134 FOREIGN-KEY-Constraints; BinaryFormatter ist nur für die NHibernate-Konfigurationsserialisierung aktiviert (Directory.Build.props).
 Aussage:       Das System soll seine Daten in einer SQL-Server-Datenbank über ein ORM (NHibernate) mit klar getrennter Datenzugriffsschicht (DAOFactory/Generics/Repositories/Named Queries) persistieren.
 Ergebnis:      Einheitlicher, austauschbarer Datenzugriff; Schema zentral versionierbar.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql (1535 CREATE TABLE; gezählt per Suche) – physisches Datenmodell
  - [SEKUNDÄR] src/backend/Centron.DAO/{DAOFactory.cs, GenericDAO.cs, GenericStoredProcedureDAO.cs, NHibernateConfiguration/} – Zugriffsarchitektur
  - [SEKUNDÄR] src/backend/Centron.DAO/Mappings/** – Entity-Tabellen-Mappings
 Prüfidee:      Entity wird über GenericDAO gespeichert und per Named Query wieder gelesen.
 Tracelinks:    StRS-001, StRS-003, SwRS-001, SwRS-003, SwRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-008
 Titel:         Betrieb des Backends als Windows-Dienst oder Konsole
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit/Übertragbarkeit
 Akteur:        Systemadministrator
 Vorbedingung:  Deployment-Paket ist installiert
 Fakt:          Es existieren getrennte Host-Projekte Centron.Host, Centron.Host.Console und Centron.Host.WindowsService unter src/webservice; ein Verzeichnis docs/Background Service dokumentiert den Dienstbetrieb.
 Aussage:       Das System soll das Backend wahlweise als Windows-Dienst (Dauerbetrieb) oder als Konsolenanwendung (Entwicklung/Diagnose) betreiben können.
 Ergebnis:      Gleiche Funktionalität in zwei Betriebsmodi.
 Belege:
  - [PRIMÄR] src/webservice/Centron.Host.WindowsService/, src/webservice/Centron.Host.Console/, src/webservice/Centron.Host/ – Betriebsmodi
  - [SEKUNDÄR] docs/Background Service/ – Betriebsdokumentation
 Prüfidee:      Start als Dienst und als Konsole führt jeweils zu erreichbarer API.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – in Zielarchitektur als Container-Dienst neu denken
 Status:        belegt
 ```
 ```
 ID:            SyRS-009
 Titel:         Windows-Desktop-Client (WPF)
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: Benutzbarkeit
 Akteur:        Anwender
 Vorbedingung:  Benutzer ist am Backend angemeldet
 Fakt:          Centron.WPF.UI ist der Hauptclient (App.xaml, FrontWindow mit Ribbon, Modulverzeichnis Modules mit Fachmodulen z. B. OnlineBanking, MyCentron; Localization, ViewModels, Views); ConnectionHeartbeatTimer.cs überwacht die Verbindung; eigene Controls-Bibliothek (src/shared/Centron.Controls inkl. Preview-Projekt).
 Aussage:       Das System soll einen Windows-Desktop-Arbeitsplatz mit modularen Fachbereichen und Ribbon-Oberfläche bereitstellen, der Verbindungsverluste erkennt.
 Ergebnis:      Vollständige Bedienung des ERP am Arbeitsplatz.
 Belege:
  - [PRIMÄR] src/centron/Centron.WPF.UI/{App.xaml, FrontWindow.xaml, Modules/} – Client-Struktur
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs – Verbindungsüberwachung
  - [SEKUNDÄR] src/shared/Centron.Controls, Centron.Controls.Preview – wiederverwendbare Steuerelemente
 Prüfidee:      Netzwerkunterbrechung wird durch Heartbeat-Mechanismus erkannt und gemeldet.
 Tracelinks:    StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: veraltet – durch Web-Client (Nexus) abzulösen; UI-Muster/Fachlogik übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-010
 Titel:         Web-Client „c-entron Nexus" (Blazor)
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: Benutzbarkeit/Übertragbarkeit
 Akteur:        Anwender, Endkunde
 Vorbedingung:  Nexus-Host ist erreichbar; Benutzer angemeldet
 Fakt:          src/nexus/CentronNexus ist eine Blazor-Anwendung mit Bereichen WebCart, WebOffer, ServiceBoard, ProductionOrderManagement, DocumentSigning, Management, Office, Settings; Ressourcen werden mehrsprachig gepflegt (SharedResource.resx/.en-US.resx); UI-Konventionen (DevExpress-Blazor-Komponenten, LibMan/CDN mit Integrity-Hash) sind im README festgelegt.
 Aussage:       Das System soll eine moderne, mehrsprachige Web-Oberfläche für Backoffice- und Kundenportal-Funktionen bereitstellen.
 Ergebnis:      Browserbasierte Nutzung zentraler Geschäftsprozesse ohne lokale Installation.
 Belege:
  - [PRIMÄR] src/nexus/CentronNexus/{WebCart, WebOffer, ServiceBoard, ProductionOrderManagement, DocumentSigning}/ – Funktionsbereiche der Web-App
  - [SEKUNDÄR] README.md (Regeln zu Komponenten/Integrität), SharedResource.*.resx – Lokalisierung und UI-Standards
 Prüfidee:      Sprachwechsel ändert Oberflächentexte einer Maske; Shop ist als Web-Account erreichbar.
 Tracelinks:    StRS-013, SyRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Zielplattform der Migration
 Status:        belegt
 ```
 ```
 ID:            SyRS-011
 Titel:         Web-Konten für Endkunden (WebAccount)
 Ebene:         SyRS
 Typ:           Schnittstelle/Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Vertrieb (Verwaltung), Endkunde (Nutzung)
 Vorbedingung:  Kunde existiert im Adressstamm
 Fakt:          WebAccountBL.cs verwaltet Web-Zugänge: Passwörter werden als SHA1-Hash gespeichert/aktualisiert (Zeilen 56, 192, 415, 480), beim Ändern wird der Hash geprüft (Zeile 253); Verwaltungsoperationen erfordern das Recht WEBACCOUNT_MANAGEMENT (WebAccountWebServiceBL mehrfach).
 Aussage:       Das System soll für Adressen Web-Zugänge verwalten (anlegen, Passwort ändern/zurücksetzen), deren Administration nur berechtigten Benutzern erlaubt ist.
 Ergebnis:      Kunden können sich im Webportal anmelden; Verwaltung bleibt geschützt.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/Logins/WebAccountWebServiceBL.cs:54, :75 u. a. (Rechteprüfung WEBACCOUNT_MANAGEMENT vor jeder Operation) – durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs:56/192/253/415/480 – Passwort-Lifecycle
  - [KONTEXT] README.md, WebCart-Abschnitt – Zusammenspiel mit Shop
 Prüfidee:      Verwaltungsaufruf ohne WEBACCOUNT_MANAGEMENT → Fehler; Passwortänderung setzt neuen Hash.
 Tracelinks:    StRS-013, SyRS-010, SwRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Rechtemodell; Hashverfahren modernisieren (SwRS-012)
 Status:        belegt
 ```
 ```
 ID:            SyRS-012
 Titel:         EDI-Dispatcher mit Distributor-Profilen und Austauschprotokoll
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        System
 Vorbedingung:  Gateway-Einstellungen je Distributor sind konfiguriert
 Fakt:          EDIDispatcherBL.cs (14 KB) steuert den Austausch, EDIGatewaySettingBL.cs hält Gateway-Konfiguration, EDILogBL.cs protokolliert; Unterverzeichnisse je Distributor/Standard (Alltron, ALSO, AlsoCH, Concerto, EGIS, Komsa, Opentrans21, SupplierEDI, Import).
 Aussage:       Das System soll ein- und ausgehende EDI-Nachrichten je Geschäftspartner-Profil verarbeiten, verteilen und jeden Austausch protokollieren.
 Ergebnis:      Fehlgeschlagene oder erfolgreiche Übertragungen sind je Dokument nachvollziehbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/EDI/{EDIDispatcherBL.cs, EDILogBL.cs, EDIGatewaySettingBL.cs} – Verarbeitung/Protokoll/Konfiguration
  - [SEKUNDÄR] Verzeichnisstruktur EDI/* – Partnerprofile
 Prüfidee:      Testnachricht für Distributor X erzeugt EDILog-Eintrag mit Dokumentbezug.
 Tracelinks:    StRS-010, StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-013
 Titel:         Elektronische Rechnung (ZUGFeRD/ebInterface)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Übertragbarkeit
 Akteur:        Buchhaltung, System
 Vorbedingung:  Rechnung ist erstellt
 Fakt:          BL/EDI enthält ein Verzeichnis Zugferd; als separat versionierte Komponente existiert Centron.Api.EbInterface unter src/apis (ebInterface ist das österreichische E-Rechnungsformat).
 Aussage:       Das System soll Rechnungen in elektronischen Rechnungsformaten (ZUGFeRD, ebInterface) erzeugen/austauschen können.
 Ergebnis:      E-Rechnung als strukturiertes Dokument zum Beleg.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/EDI/Zugferd/ – ZUGFeRD-Erzeugung
  - [SEKUNDÄR] src/apis/Centron.Api.EbInterface/ – ebInterface-API-Projekt
 Prüfidee:      Erzeugte E-Rechnung validiert gegen das jeweilige Formatschema.
 Tracelinks:    StRS-003, StRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Detailtiefe der Formate in Folgeiteration prüfen
 Status:        belegt
 ```
 ```
 ID:            SyRS-014
 Titel:         Versanddienstleister-Anbindung (GLS, Shipcloud)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Lager/Versand
 Vorbedingung:  Liefer- bzw. Abholbeleg mit Versandbezug
 Fakt:          Separate API-Projekte Centron.Api.Gls und Centron.Api.Shipcloud existieren; ShipcloudPackageTemplateBL.cs verwaltet Paketschein-Vorlagen.
 Aussage:       Das System soll Paketetiketten/Versanddaten bei GLS und Shipcloud anfordern und Vorlagen je Paketdienst verwalten.
 Ergebnis:      Versandetikett/Sendungsnummer am Beleg.
 Belege:
  - [SEKUNDÄR] src/apis/Centron.Api.Gls/, src/apis/Centron.Api.Shipcloud/ – Dienstleister-Integration
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs – Vorlagenverwaltung
 Prüfidee:      Paketschein-Erzeugung liefert Tracking-Nummer und Etikett (PDF).
 Tracelinks:    StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-015
 Titel:         Katalogartikel-Import aus IT-Distributionsquellen (ITscope, Icecat, EGIS, Cop)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Einkauf, System (Hintergrundimport)
 Vorbedingung:  Importquelle ist konfiguriert
 Fakt:          Separate Data-Access-Projekte existieren (ITscopeDataAccess, IcecatDataAccess, EgisDataAccess, CopDataAccess); das DB-Schema enthält ein dediziertes Import-Modell (ArticleImports, ArticleImportMappings, ArticleImportField, ArticleImportLogs, ArticleImportDistributors, ArticleImportMultiDistributor).
 Aussage:       Das System soll Artikeldaten (inkl. Feld-Mapping und Mehr-Distributoren-Zuordnung) aus externen Katalogquellen importieren und Importe protokollieren.
 Ergebnis:      Aktualisierter Artikelstamm mit Herkunfts- und Fehlerprotokoll.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArticleImports, ArticleImportMappings, ArticleImportField, ArticleImportLogs – durchgesetztes Import-Datenmodell
  - [SEKUNDÄR] src/apis/Centron.APIs.ITscopeDataAccess/, ...IcecatDataAccess/, ...EgisDataAccess/, ...CopDataAccess/ – Quellsysteme
 Prüfidee:      Importlauf erzeugt Logeinträge; Feldzuordnung aus ArticleImportMappings wird angewendet.
 Tracelinks:    StRS-008, StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-016
 Titel:         Online-Banking-Anbindung über FinAPI
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: Sicherheit
 Akteur:        Buchhaltung
 Vorbedingung:  Bankzugang ist eingerichtet (CreateFinApiAccount)
 Fakt:          src/apis/Centron.APIs.FinAPI implementiert den Anbieter-Zugriff; im WPF-Client existieren Dialoge zum Anlegen eines FinAPI-Kontos und zum Zurücksetzen des FinAPI-Passworts (CreateFinApiAccount/ResetFinApiPassword, jeweils mit CheckPassword()); BL/Finances/OnlineBanking enthält die fachliche Logik.
 Aussage:       Das System soll Bankkonten über die FinAPI-Schnittstelle anbinden und Zugangsdaten dafür geschützt verwalten.
 Ergebnis:      Kontoumsätze stehen für den Zahlungsabgleich zur Verfügung.
 Belege:
  - [SEKUNDÄR] src/apis/Centron.APIs.FinAPI/ – Anbieteranbindung
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/OnlineBanking/ConfigurationSettings/ResetFinApiPassword/ResetFinApiPasswordViewModel.cs:210/:248 – Passwort-Handling im Client
  - [SEKUNDÄR] src/backend/Centron.BL/Finances/OnlineBanking/ – Fachlogik
 Prüfidee:      Kontoumsatz-Abruf liefert buchungsfähige Umsätze; falsches Passwort wird vom Dialog abgefangen.
 Tracelinks:    StRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-017
 Titel:         Volltext-/Indexsuche mit deutscher Sprachanalyse
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Performance-Effizienz
 Akteur:        Anwender
 Vorbedingung:  Index ist aufgebaut (IndexBuilder)
 Fakt:          BL/IndexSearch enthält IndexSearchBL, IndexBuilder und einen GermanAnalyzer.cs (20 KB) sowie die Fehlerbehandlung ObjectIndexingFailedException; Indizes liegen unter Indexes/.
 Aussage:       Das System soll Geschäftsobjekte indizieren und eine deutschsprachig optimierte Suche darüber anbieten; Indexierungsfehler sollen objektbezogen behandelt werden.
 Ergebnis:      Schnelle Volltextsuche über Geschäftsobjekte.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/IndexSearch/{IndexSearchBL.cs, IndexBuilder.cs, GermanAnalyzer.cs, ObjectIndexingFailedException.cs} – Suchinfrastruktur
 Prüfidee:      Suche nach Wortstamm findet flektierte Formen; defektes Objekt blockiert nicht den Gesamtindex.
 Tracelinks:    StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-018
 Titel:         Report-Engine mit Berichtsgruppen, Benutzerrechten und PDF-Export
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: Benutzbarkeit
 Akteur:        Anwender, Controlling
 Vorbedingung:  Bericht ist definiert (ReportGroup/ReportData)
 Fakt:          ReportEngine umfasst ReportDataBL (94 KB), ReportGroupBL (32 KB), FastReportHelper (FastReport als Engine), PDF-Export/PdfStrategy, benutzerdefinierte Generatoren sowie SQL-Abfrage-Verwaltung (ReportDataQueryBL); der Zugriff auf den SQL-Manager erfordert Administration.SQL_MANAGER oder REPORT_MANAGEMENT (ReportDataWebBL.cs:496).
 Aussage:       Das System soll Berichte auf Basis definierter Datenabfragen über FastReport erzeugen, als PDF exportieren und die Verwaltung von Abfragen/Berichten nur berechtigten Benutzern erlauben.
 Ergebnis:      Druckfertige Berichte/PDF je Berichtsgruppe.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/ReportEngine/ReportDataWebBL.cs:496 (Rechteprüfung SQL_MANAGER/REPORT_MANAGEMENT) – durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/ReportEngine/{FastReportHelper.cs, PdfExport/, ReportGroupBL.cs} – Engine/Export/Gruppierung
 Prüfidee:      Bericht ohne REPORT_MANAGEMENT-Recht nicht änderbar; PDF-Ausgabe öffnet valide Datei.
 Tracelinks:    StRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-019
 Titel:         Belegversionierung und Belegjournal („Versions"-Tabellen, Beleglog)
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        System
 Vorbedingung:  Beleg existiert und wird geändert/abgeschlossen
 Fakt:          Zu nahezu jeder Belegart existiert eine Versions-Tabelle (RechKopf/RechPosVersions, AufKopf/AufPosVersions, AngKopf/AngPosVersions, LiefKopf/LiefPosVersions, AbholKopf/AbholPosVersions, GutKopf/GutPosVersions, VertragKopf/VertragPosVersions, AnfrKopf/AnfrPosVersions); ReceiptLogBL.cs (75 KB) protokolliert Belegänderungen (z. B. Stammblatt hinzugefügt/entfernt, Vertragspreise).
 Aussage:       Das System soll frühere Belegstände gesondert speichern (Versionstabellen) und Änderungen an Belegen in einem Journal festhalten.
 Ergebnis:      Belegänderungen sind zeitlich nachvollziehbar; historische Stände bleiben abrufbar.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE RechKopfVersions, AufKopfVersions, VertragKopfVersions u. a. – durchgesetzte Versionstabellen
  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs:1266–1279 u. a. (Logeinträge je Änderung) – Journallogik
 Prüfidee:      Beleg ändern → neuer Versions-Datensatz + Logeintrag mit Alt-/Neuwert.
 Tracelinks:    StRS-003, StRS-004, SwRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-020
 Titel:         Mindestpreis-Schutz bei Verkaufspreisen
 Ebene:         SyRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: -
 Akteur:        Vertrieb
 Vorbedingung:  Position wird bepreist; Mindestpreis ist definiert
 Fakt:          ReceiptBL.cs:9043 und :9113 prüfen das Recht ALLOW_IGNORE_MINIMUM_PRICE: ohne dieses Recht darf der Mindestpreis nicht unterschritten werden (Zeile 9113: Ablehnung, wenn „== false").
 Aussage:       Das System soll Preisunterschreitungen unter den Mindestpreis blockieren, sofern der Benutzer nicht das explizite Ausnahmerecht besitzt.
 Ergebnis:      Margenschutz; Ausnahmen nur für berechtigte Benutzer und damit nachvollziehbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs:9043, :9113 (HasUserRight ALLOW_IGNORE_MINIMUM_PRICE als Bedingung der Preisannahme) – durchsetzende Stelle inkl. konkreter Prüfung
 Prüfidee:      Position unter Mindestpreis: ohne Recht Fehler, mit Recht speicherbar.
 Tracelinks:    StRS-003, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
 Status:        belegt
 ```
 ```
 ID:            SyRS-021
 Titel:         Rechnungsstorno nur mit gesondertem Recht
 Ebene:         SyRS
 Typ:           Sicherheit/funktional
 Qualitätsmerkmal: Sicherheit
 Akteur:        Buchhaltung
 Vorbedingung:  Rechnung ist gebucht
 Fakt:          ReceiptWebServiceBL.cs:1022 belegt, dass die Storno-Fähigkeit an das Recht RIGHT_RECHNUNGSTORNIEREN gebunden ist („CanCancelInvoices = rights.Any(...)"); fachlich korrespondiert eine Gutschrifts-Belegart (GutKopf/GutPos).
 Aussage:       Das System soll die Stornierung von Rechnungen ausschließlich Benutzern mit dem Storno-Recht erlauben und den Vorgang als eigenen, nachvollziehbaren Schritt führen.
 Ergebnis:      Stornos sind rechtgeschützt und über Belegjournal nachvollziehbar (siehe SyRS-019).
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Sales/Receipts/ReceiptWebServiceBL.cs:1022 (Fähigkeit CanCancelInvoices an RIGHT_RECHNUNGSTORNIEREN gebunden) – rechtedurchsetzende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE GutKopf/GutPos – Gutschriftsbeleg als fachliches Gegenstück
 Prüfidee:      Nutzer ohne Storno-Recht erhält keine Storno-Option bzw. API-Fehler; Storno erzeugt Gegenbeleg.
 Tracelinks:    StRS-003, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – risikorelevant (Abrechnung)
 Status:        belegt
 ```
 ```
 ID:            SyRS-022
 Titel:         Massenänderung von Stammdaten (MassUpdate)
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Administrator/Power-User
 Vorbedingung:  Zielmenge ist selektiert
 Fakt:          MassUpdateBL.cs (50 KB) implementiert Massenaktualisierungen als eigenes BL-Modul.
 Aussage:       Das System soll gebündelte Änderungen an vielen Datensätzen (z. B. Feldwerte) in einem kontrollierten Lauf ausführen.
 Ergebnis:      Konsistente, wiederholbare Massenpflege ohne Einzelbearbeitung.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/MassUpdate/MassUpdateBL.cs – Implementierung der Massenänderung (flach analysiert)
 Prüfidee:      Massenupdate auf Testmenge ändert nur die selektierten Datensätze und protokolliert Ergebnisse.
 Tracelinks:    StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Rechte-/Protokollaspekt in Folgeiteration vertiefen
 Status:        belegt
 ```
 ```
 ID:            SyRS-023
 Titel:         Integrierte Kommunikation: E-Mail, Telefonie, Chat, Benachrichtigungen
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: Benutzbarkeit
 Akteur:        Anwender
 Vorbedingung:  Mail-/TAPI-/Chat-Einstellungen sind gepflegt
 Fakt:          BL/Mail enthält Protokolle, Templates, Signatur (MailSignatureBL), Blacklist, Exchange-Ordner und VariableReplacement; PhoneCallBL.cs (31 KB) implementiert Telefonie (Tapi); ChatBL.cs (21 KB) und CentronNotificationsBL/UserNotificationBL interne Chats und Benachrichtigungen; MailingDataBL realisiert Serienmails; MailScannerBL.cs:59–61 verlangt das Recht VirtualMailAssistant.ACCESS_VMA_MODULE.
 Aussage:       Das System soll E-Mail (inkl. Signaturen, Vorlagen, Variablenersetzung, Blacklisting, Exchange-Anbindung), Telefonie über TAPI, interne Chats, Benachrichtigungen, Serienmails und den rechtegeschützten „Virtuellen Mail-Assistenten" integriert bereitstellen.
 Ergebnis:      Kommunikation ist objektbezogen im ERP dokumentiert und auslösbar.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/MailScanner/MailScannerBL.cs:59–61 (Rechteprüfung ACCESS_VMA_MODULE vor Zugriff) – durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/Mail/{MailSettingsBL.cs, MailSignatureBL.cs, Templates/, Protocols/, Blacklist/, Exchange/} – Mail-Teilfunktionen
  - [SEKUNDÄR] src/backend/Centron.BL/Tapi/PhoneCallBL.cs; Chats/ChatBL.cs; Notifications/UserNotificationBL.cs; Mailings/MailingDataBL.cs – Telefon-/Chat-/Notify-/Mailing-Logik
 Prüfidee:      Serienmail nutzt Vorlage mit ersetzten Variablen; VMA-Zugriff ohne Recht schlägt fehl.
 Tracelinks:    StRS-001, SyRS-031
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-024
 Titel:         KI-Chat mit rechtegesteuerten Fähigkeiten
 Ebene:         SyRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Anwender
 Vorbedingung:  KI-Modul ist eingerichtet (Prompt-Einstellungen vorhanden)
 Fakt:          ArtificialIntelligenceChatWebServiceBL.cs prüft je Fähigkeit eigene Rechte: MODEL_SELECTION, WEB_SEARCH, INTERACTIVE_MODE, ADD_FILES und Modulzugriff ArtificialIntelligence.ID (Zeilen 90, 369–390, 473); das DB-Schema hält Prompt-Kategorien/-Einstellungen (ArtificialIntelligencePromptCategory/-Settings).
 Aussage:       Das System soll einen KI-Assistenten anbieten, dessen Einzelfähigkeiten (Modellauswahl, Websuche, interaktiver Modus, Datei-Upload) benutzerrechtlich getrennt freigeschaltet werden.
 Ergebnis:      KI-Nutzung unterliegt dem Unternehmens-Rechtemodell.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/ArtificialIntelligence/ArtificialIntelligenceChatWebServiceBL.cs:90, :369–390 (HasArtificialIntelligenceRight je Fähigkeit) – durchsetzende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE ArtificialIntelligencePromptCategory, ArtificialIntelligencePromptSettings – Prompt-Verwaltung
 Prüfidee:      Ohne WEB_SEARCH-Recht steht die Websuche-Option nicht zur Verfügung bzw. der Aufruf wird abgelehnt.
 Tracelinks:    StRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-025
 Titel:         Dokumentenablage mit Rechten, interner/externer Dokumentation und PDF-Signatur
 Ebene:         SyRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Anwender
 Vorbedingung:  Dokumentstruktur (Verzeichnisse) existiert
 Fakt:          Dokumentenoperationen tragen eigene Rechte (READ/ADD/CHANGE/DELETE_DOCUMENTS, MANAGE_DOCUMENTS, Verzeichnisrechte; DocumentWebServiceBL.cs:78–109/:660, DirectoryWebServiceBL.cs:265–291); die Wissensdokumentation unterscheidet interne und öffentliche Inhalte (DocumentationBL.cs:33–264: READ_DOCUMENTATION vs. READ_INTERNAL_DOCUMENTATION); PDF-Signierung erfordert Administration.SETTINGS (PdfSigningBL.cs:60); ein eigenes API-Projekt Centron.Api.docuFORM koppelt ein Dokumenten-/Formularsystem.
 Aussage:       Das System soll Dateien und Verzeichnisse objektbezogen ablegen, deren Zugriff je Operation rechtlich absichern, Dokumentation nach intern/extern trennen, PDFs signieren und Formularsysteme anbinden können.
 Ergebnis:      Geschützte, revisionssichere Dokumentenverwaltung.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/WebServices/Administration/FileManagements/DocumentWebServiceBL.cs:78 (READ_DOCUMENTS-Prüfung vor Zugriff) – durchsetzende Stelle
  - [PRIMÄR] src/backend/Centron.BL/DocumentationArea/DocumentationBL.cs:33–38 (interne Doku nur mit READ_INTERNAL_DOCUMENTATION) – konkrete Trennung
  - [PRIMÄR] src/backend/Centron.BL/Security/PdfSigningBL.cs:60 (Signatur nur mit SETTINGS-Recht) – durchsetzende Stelle
  - [SEKUNDÄR] Centron.Api.docuFORM/ – Formularsystem-Anbindung
 Prüfidee:      Interner Dokumentationsartikel ist ohne internes Recht nicht sichtbar; Signieren ohne SETTINGS-Recht schlägt fehl.
 Tracelinks:    StRS-006, StRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-026
 Titel:         Technologiebasis .NET 10 mit zentraler Build-Konfiguration
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        Entwicklung/Betrieb
 Vorbedingung:  Build-Umgebung ist eingerichtet
 Fakt:          global.json fordert SDK 10.0.100 (rollForward latestFeature); Directory.Build.props setzt unternehmensweite Attribute (TreatWarningsAsErrors, InformationalVersion mit GitCommitId, Company „NEXOWARE Systems GmbH", Product „NEXOWARE c-entron ERP"); die DevExpress-Version wird zentral aus DevExpress.Version.props importiert.
 Aussage:       Das System soll auf einer einheitlichen .NET-SDK- und Komponentenversion basieren, deren Build-Metadaten (Version, Commit) nachvollziehbar sind.
 Ergebnis:      Reproduzierbare Builds mit einheitlicher Drittkomponenten-Versionierung.
 Belege:
  - [PRIMÄR] global.json ({ "sdk": { "version": "10.0.100" } }) – SDK-Festlegung
  - [SEKUNDÄR] Directory.Build.props, DevExpress.Version.props – zentrale Build-Defaults
 Prüfidee:      Build unter abweichendem SDK-Verhalten dokumentiert; Assembly-Info enthält Commit-Id.
 Tracelinks:    SyRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-027
 Titel:         Mahnwesen auf Basis offener Posten
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal: -
 Akteur:        Buchhaltung
 Vorbedingung:  Überfällige offene Posten existieren
 Fakt:          Tabelle Mahnlauf existiert; es gibt das Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS (AccountWebServiceBL.cs:352), das eine Mahn-/Sperrwirkung auf Belege aufheben kann.
 Aussage:       [HYPOTHESE] Das System soll überfällige Forderungen mahnen und säumige Kunden für neue Belege sperren können.
 Ergebnis:      Mahnläufe erzeugen Mahnschreiben; gesperrte Kunden benötigen Ausnahmerecht für neue Belege.
 Belege:
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Mahnlauf – Datenanker des Mahnwesens
  - [SEKUNDÄR] src/backend/Centron.BL/WebServices/Accounts/AccountWebServiceBL.cs:352 (Recht IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS) – belegt Existenz einer Mahnsperre
  - Es fehlt: PRIMÄR-Beleg für die Mahnstufen-/Sperrlogik (Prozessklasse nicht analysiert) → HYPOTHESE
 Prüfidee:      Kunde mit überfälligem OP löst Mahnsperrung aus; Beleganlage nur mit IGNORE_DUNNING_BLOCKING-Recht.
 Tracelinks:    StRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        HYPOTHESE
 ```
 ```
 ID:            SyRS-028
 Titel:         Mandantenfähigkeit
 Ebene:         SyRS
 Typ:           Daten/nicht-funktional
 Qualitätsmerkmal: Übertragbarkeit
 Akteur:        Betreiber
 Vorbedingung:  Mehrere Mandanten sind eingerichtet
 Fakt:          Das Schema enthält eine Tabelle Mandant (CREATE TABLE dbo.Mandant); zusätzlich existieren Filiale und KundeToKonzern/CustomerToBranches (Filiale/Konzern-Beziehungen). Wo Mandant im Code ausgewertet wird, wurde nicht untersucht.
 Aussage:       [HYPOTHESE] Das System soll mehrere Mandanten (rechtlich getrennte Gesellschaften) in einer Installation verwalten können.
 Ergebnis:      Daten sind mandantbezogen getrennt.
 Belege:
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE Mandant, Filiale, CustomerToBranches, KundeToKonzern – Tabellenanker
  - Es fehlt: Nachweis der mandantenbezogenen Filterung im Code (Zugriffe nicht analysiert) → HYPOTHESE
 Prüfidee:      Benutzer von Mandant A sieht keine Belege von Mandant B.
 Tracelinks:    StRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – vor SaaS-Migration zu klären (Single- vs. Multi-DB je Mandant)
 Status:        HYPOTHESE
 ```
 ```
 ID:            SyRS-029
 Titel:         Passwort-Tresor für Zugangsdaten (Kunden-/Systempasswörter)
 Ebene:         SyRS
 Typ:           funktional/Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Techniker, IT
 Vorbedingung:  Benutzer besitzt Password-Manager-Rechte
 Fakt:          PasswordManagerBL.cs (u. a. :229–278, :766–778) trennt Rechte für Richtlinien-Verwaltung (ACCESS_GUIDELINE_MANAGEMENT) und Bereichs-Verwaltung (ACCESS_AREA_MANAGEMENT); ein Export aller Zugangsdaten erfordert EXPORT_ACCESS_AND_PASSWORD_DATA (:899, :935); PasswordManagementArea ergänzt die Verwaltungslogik.
 Aussage:       Das System soll Zugangsdaten verwaltet ablegen, die Bearbeitung von Richtlinien/Bereichen rechtlich trennen und den Vollabzug der Daten ausschließlich mit einem Hochsicherheitsrecht erlauben.
 Ergebnis:      Zugangsdaten sind kontrolliert zugänglich; Exporte sind privilegiert.
 Belege:
  - [PRIMÄR] src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs:899/:935 (HasUserRight EXPORT_ACCESS_AND_PASSWORD_DATA vor Export) – durchsetzende Stelle
  - [PRIMÄR] Ebendort :229–278 (ACCESS_GUIDELINE_MANAGEMENT-Prüfungen) – durchsetzende Stelle
 Prüfidee:      Export ohne EXPORT_ACCESS_AND_PASSWORD_DATA-Recht wird abgelehnt.
 Tracelinks:    StRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen – Verschlüsselung der Ablage in Folgeiteration prüfen
 Status:        belegt
 ```
 ```
 ID:            SyRS-030
 Titel:         Zentrales Datenmodell für Asset-Management & Monitoring
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        System, MSP-Techniker
 Vorbedingung:  Monitoring-Dienst meldet Daten
 Fakt:          Das Schema führt für ca. 200 technische Domänen eigene Tabellenfamilien unter AssetManagement* (Geräte, Checks inkl. Ergebnis-Historie AssetManagementCheckResultsHistory, Lizenzen, AD-/DNS-/DHCP-/IIS-/SQL-/Hyper-V-/Exchange-Inventur, SNMP-MIBs, Dokumentationsvorlagen) plus MonitoringServiceSettings; AccountDevicesToTickets verknüpft Geräte mit Tickets.
 Aussage:       Das System soll technische Assets und Monitoring-Ergebnisse in einem strukturierten, historisierenden Datenmodell führen, aus dem Kundeninventar und Störungs-Tickets abgeleitet werden können.
 Ergebnis:      Nachvollziehbare Ist-Aufnahme und Verlauf je Kundenumgebung.
 Belege:
  - [PRIMÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementDevices, AssetManagementChecks, AssetManagementCheckResults, AssetManagementCheckResultsHistory, MonitoringServiceSettings – Datenmodell
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AccountDevicesToTickets – Verknüpfung Gerät↔Ticket
 Prüfidee:      Check-Ergebnis erzeugt History-Eintrag; Gerät bleibt Ticket zuordenbar.
 Tracelinks:    StRS-012, StRS-006
 Konsolidierung: Kandidat: Zusammenführen mit Stammblatt/GeraeteKopf (StRS-004, SwRS-017)
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
 ```
 ID:            SyRS-031
 Titel:         Outlook-/Office-Integration (Add-in, Exchange-Inventur)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal: -
 Akteur:        Anwender
 Vorbedingung:  Outlook/Exchange ist angebunden
 Fakt:          Es existiert ein eigenes Outlook-Add-in (src/nexus/CentronNexus.OutlookAddIn) sowie BL/Outlook und der Nexus-Bereich Office; das Asset-Datenmodell inventarisiert Exchange-Postfächer (AssetManagementEWSMailBoxes, AssetManagementExMailboxs inkl. Statistiken/Berechtigungen).
 Aussage:       Das System soll E-Mails/Termine kontextbezogen zwischen Outlook und ERP austauschen und Exchange-Bestände inventarisieren.
 Ergebnis:      Kommunikation ist dem Geschäftsobjekt zugeordnet; Exchange-Inventar ist erfasst.
 Belege:
  - [SEKUNDÄR] src/nexus/CentronNexus.OutlookAddIn/, src/backend/Centron.BL/Outlook/, src/nexus/CentronNexus/Office/ – Integrationspunkte
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql, CREATE TABLE AssetManagementEWSMailBoxes, AssetManagementExMailboxs – Exchange-Inventur
 Prüfidee:      Aus Outlook heraus wird eine Mail einem Ticket/Kunden zugeordnet.
 Tracelinks:    StRS-001, SyRS-023
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ```
@@ -0,0 +1,44 @@
 # Traceability (konsolidiert)
 Kette: StRS (fachlich) → SyRS (System) → SwRS (Software). Einträge nach SwRS geführt; zusätzliche SyRS→StRS-Beziehungen am Ende. Artefaktbeleg = wichtigster PRIMÄR-Beleg der jeweiligen Kette.
 | StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
 |---|---|---|---|
 | StRS-001 | SyRS-003 | SwRS-010 | src/backend/Centron.BL/Accounts/AccountAddressBL.cs:259–317 |
 | StRS-002 | SyRS-004 | SwRS-006 | src/.../ReceiptSearch/InvoiceReceiptSearchConfiguration.cs:152–157 |
 | StRS-002 | SyRS-004 | SwRS-009 | src/backend/Centron.BL/Sales/Support/HelpdeskBL.cs:271–284 |
 | StRS-003 | SyRS-019 | SwRS-001 | SSMS_DB_SCHEMA.sql (Kopf/Pos-Tabellen je Belegart) |
 | StRS-003 | SyRS-019/020/021 | SwRS-005 | src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs :9043/:9113 |
 | StRS-003 | – | SwRS-033 | src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs |
 | StRS-004 | SyRS-019 | SwRS-017 | src/.../ClickContracts/MasterDataListBL.cs:163 |
 | StRS-005 | SyRS-019 | SwRS-011 | src/.../AutomaticFactura/AutomaticFacturaWebServiceBL.cs (:124/:2370) |
 | StRS-006 | SyRS-003 | SwRS-002 | SSMS_DB_SCHEMA.sql (hlpdsk_*-Tabellen) |
 | StRS-006 | SyRS-003/004 | SwRS-021 | src/.../CentronChecklistWebserviceBL.cs:160–162 |
 | StRS-006 | SyRS-003 | SwRS-025/SwRS-026 | SSMS (CRMProjekt); NexusTicketViewWebServiceBL.cs:44–124 |
 | StRS-007 | – | SwRS-002 | SSMS (hlpdsk_timer); HelpdeskTimerWebServiceBL.cs:359–374 |
 | StRS-008 | SyRS-003 | SwRS-018 | src/backend/Centron.BL/Warehousing/BarcodeBL.cs:1091 |
 | StRS-008 | SyRS-003 | SwRS-019 | src/backend/Centron.BL/Warehousing/ArticleBL.cs:999–1081 |
 | StRS-008 | – | SwRS-022/SwRS-023 | SSMS (ArticleProductionOrders, Lagerort/Lagerplatz) |
 | StRS-009 | SyRS-012 | SwRS-006 | SupplierOrderReceiptSearchConfiguration.cs:138–140 |
 | StRS-010 | SyRS-012/013 | – | src/backend/Centron.BL/EDI/{EDIDispatcherBL.cs, Zugferd/} |
 | StRS-011 | SyRS-016/027 | – | src/apis/Centron.APIs.FinAPI; SSMS (Mahnlauf) [SyRS-027: HYPOTHESE] |
 | StRS-012 | SyRS-030 | – | SSMS (AssetManagement*-Tabellenfamilie) |
 | StRS-013 | SyRS-010/011 | SwRS-012/SwRS-031 | WebAccountBL.cs:56/:192/:415/:480; TradePoolBL.cs:170 |
 | StRS-014 | SyRS-002 | SwRS-015 | src/webservice/Centron.Controllers/Authorization/*.cs |
 | StRS-014 | SyRS-003 | SwRS-007/SwRS-008 | Administration/Rights/AppRightsBL.cs; ScriptMethod11783.cs |
 | StRS-014 | SyRS-005/006 | SwRS-013/SwRS-014/SwRS-030 | Auth/Authenticator.cs:161; TwoFactorAuthenticationBL.cs; TwoFactor/*.cs |
 | StRS-014 | SyRS-024/029 | – | ArtificialIntelligenceChatWebServiceBL.cs:90; PasswordManagerBL.cs:899 |
 | StRS-015 | SyRS-018 | – | ReportDataWebBL.cs:496; ReportEngine/ReportGroupBL.cs:402 |
 | – | SyRS-001 | SwRS-029/SwRS-032 | Controllers/v1/*; c-entron.misc.ConnectionManager |
 | – | SyRS-007 | SwRS-003/SwRS-004/SwRS-028/SwRS-035 | SSMS_Zählung; Centron.DAO/*; Mappings/* |
 | – | SyRS-008/026 | – | src/webservice/Centron.Host.*; global.json, Directory.Build.props |
 | – | SyRS-010 | SwRS-022 | src/nexus/CentronNexus/ProductionOrderManagement |
 | – | SyRS-019 | SwRS-034 | HelpdeskTimerLogBL.cs:183; ChangeTracking/ |
 | – | SyRS-023 | SwRS-027 | TextModuleArea/TextModuleBL.cs; Mail/VariableReplacement |
 | – | SyRS-028 | – | SSMS (Mandant, Filiale) [HYPOTHESE] |
 ## Hinweise zur Kette
 - Jede SwRS-Anforderung trägt im Feld `Tracelinks` mindestens eine SyRS-ID (oder bei rein fachlichen Ketten die StRS-ID mit Durchgriff über die genannte SyRS-Belegfamilie; siehe Tabelle „–" dort, wo eine informationelle Querverbindung ohne eigene SyRS-Anforderung besteht: SwRS-024, -025, -033).
 - HYPOTHESE-markierte Ketten: SyRS-027, SyRS-028, SwRS-003, SwRS-030, SwRS-031 (siehe Hypothesen.md).
 - Forward-Trace: StRS-003 ist die Ursprungsanforderung der Belegfamilie SyRS-019/020/021 → SwRS-001/005/006; StRS-014 ist die Ursprungsanforderung des Sicherheits-Trace-Clusters SyRS-002–006/024/029 → SwRS-007/008/012–015/030.
@@ -0,0 +1,117 @@
 # Messprotokoll – Versuch 01 – Prompt-Version 02
 ## Lauf
 - **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
 - **Prompt-Version:** 02
 - **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
 - **Startzeit:** 2026-08-28T05:54:57Z
 - **Endzeit:** 2026-08-28T06:52:30Z
 - **Dauer gesamt:** 00:57:33 (API: nicht separat messbar)
 - **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
 - **Codebasis-Commit:** `37275c96` (dirty: nein, 0 Änderungen)
 - **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
 - **Prompt-Repo-Commit:** `37275c96d610a8b7958d126bebe4ef8d580c0bde`
 ## Werkzeugkonfiguration
 - **Skill-Version:** v8.0.0
 - **Werkzeugadapter:** Python API (TensorX Gateway)
 - **CLI-Version:** Python 3.13.15, requests 2.34.2, Adapter-Skript v1.1.0
 - **CLI-Pfad:** `c:\DEV\MasterArbeit\.claude\skills\run-experiment\glm-kimi-adapter.py`
 - **Modell (angefordert):** `moonshotai/kimi-k3`
 - **Modelle (tatsächlich eingesetzt):** `moonshotai/kimi-k3` (100 % der Tokens)
 - **Kontrolle Modell:** bestanden
 - **Effort:** high (per `--effort high`; Kimi `reasoning_effort` = `high`)
 - **Laufverzeichnis-ID:** `v8.0.0-6bdf`
 - **Ablage:** `Iteration 6/moonshotai/kimi-k3/builtin/high/`
 - **Parallele Läufe:** nein
 - **Agentenmodus:** builtin (V1b) – eingebaute Subagenten erlaubt
 - **Kontextfenster:** nicht erfasst
 - **Sampling-Parameter:** Temperatur 1.0; Reasoning-Effort high
 - **Permission-/Sandbox-Modus:** Kommando-Denylist im Adapter
 - **Toolfreigabe:** `read_file`, `list_directory`, `search_files`, `execute_command`, `write_file`, `spawn_subagent`
 - **Isolationsmechanismus:** Eigenständiges Python-Skript, Pfad-Sicherheit, Denylist, bereinigter Snapshot
 - **MCP-Server / Agentendateien:** keine
 - **Subagenten:** 8 gestartet (3 completed, 5 failed), alle Typ `explore`
 - **Verschachtelung:** `spawned` = 8, `max_depth` = 1 (keine rekursiven Subagenten)
 ## Validierungsstichprobe
 - **Größe:** noch nicht festgelegt
 - **Stand:** noch nicht gezogen
 ## Verbrauch
 ### Hauptagent inkl. Subagenten (`usage`, abrechnungsrelevant)
 **Token-Werte validiert gegen TensorX-Abrechnungs-CSV** (`usage-2026-07-29-to-2026-08-28.csv`):
 148 API-Aufrufe im Zeitfenster 07:54:57–08:52:30 CEST, Modell `moonshotai/kimi-k3`, App `python-requests`.
 Alle vier Token-Metriken stimmen exakt überein (Differenz = 0).
 | Messgröße | Adapter (RawResult.json) | TensorX CSV | Differenz |
 |---|---:|---:|---:|
 | Input-Tokens | 5.555.247 | 5.555.247 | 0 ✅ |
 | Output-Tokens | 149.450 | 149.450 | 0 ✅ |
 | davon Reasoning-Tokens | 28.912 | (nicht in CSV) | — |
 | Cache-Read-Tokens | 4.371.456 | 4.371.456 | 0 ✅ |
 | Cache-Write-Tokens | nicht erfasst | nicht in CSV | — |
 | **Tokens gesamt** | **5.704.697** | **5.704.697** | **0 ✅** |
 | Agent-Turns (Hauptagent) | 28 | — | — |
 | API-Aufrufe gesamt | 148 | 148 | — |
 | Kosten (USD) | nicht im Protokoll | $9,07 | — |
 | Cache-Trefferquote | 78,7 % | 78,7 % | — |
 | Durchschn. Geschwindigkeit | — | 52,4 TPS | — |
 Tokens gesamt inkl. aller 8 Subagenten. Subagent-Token vollständig akkumuliert.
 Die 148 API-Aufrufe verteilen sich auf: 28 Hauptagent-Turns + ~120 Subagent-Turns (8 Subagenten × ~15 Turns).
 ## Gefundene Anforderungen
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 15 | 18,5 % |
 | SyRS | 31 | 38,3 % |
 | SwRS | 35 | 43,2 % |
 | **Gesamt** | **81** | 100 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 180 |
 | davon `PRIMÄR` | 91 (50,6 %) |
 | davon `SEKUNDÄR` | 77 (42,8 %) |
 | davon `KONTEXT` | 12 (6,7 %) |
 | Belege je Anforderung (Median) | 2 |
 | Anforderungen mit mind. einem `PRIMÄR`-Beleg | 67 (82,7 %) |
 ### Status
 | Kategorie | Anzahl |
 |---|---:|
 | belegt | 76 (93,8 %) |
 | `HYPOTHESE` | 5 (6,2 %) |
 | Konsolidierungskandidaten | 7 (8,6 %) |
 | ISO-25010-Qualitätsmerkmal | 81 (100 %) |
 ### Regelkonformität
 | Vorgabe | Ergebnis |
 |---|---|
 | Belegpflicht | **erfüllt** (0 ohne Beleg) |
 | Risikobasierte Priorisierung | **erfüllt** (34 risikorelevant, alle gedeckt) |
 | Verifizierbarkeit | **erfüllt** |
 | Übernahmewürdigkeit | **erfüllt** (alle 81) |
 | Traceability | 81/81 (100 %) |
 ## Ergebnis
 - **Status:** erfolgreich
 - **Session-ID:** nicht erfasst
 - **Permission-Denials:** nicht erfasst
 - **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 8 (builtin: korrekt)
 - **Gültigkeit:** gültig – 7 Ergebnisdateien, Stderr.log enthält Abbruchmeldungen der Subagenten (UnicodeDecodeError), aber der Hauptlauf war erfolgreich
 - **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
 - **Root unverändert:** ja
 - **Anmerkungen:**
  - Erster Lauf mit `builtin`-Modus (V1b) im Python-API-Adapter.
  - 8 Subagenten gestartet, davon 5 fehlgeschlagen (UnicodeDecodeError: cp1252 vs UTF-8 bei Shell-Kommandoausgabe). Bug nachträglich behoben (`encoding='utf-8'` in subprocess.run).
  - Tokenverbrauch (5,7 Mio.) 2,6× höher als GLM-Solo (2,17 Mio.) – Effekt der Subagenten-Delegation.
  - Primärbelegquote (82,7 %) niedriger als GLM-Solo (98,9 %) – möglicherweise wegen der fehlgeschlagenen Subagenten.
  - SwRS-Anteil höher (43,2 % vs 22,2 % bei GLM-Solo) – andere Schwerpunktsetzung durch Subagenten-Delegation.
  - Dauer ~58 Min deutlich länger als GLM-Solo (5:39 Min) – jeder Subagent führt eigene API-Aufrufe durch.
@@ -0,0 +1,51 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T05:54:57.975695+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 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 2 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 3 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 4 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 5 gestartet (Typ: explore)
 Exception in thread Thread-27 (_readerthread):
 Traceback (most recent call last):
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 1044, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 995, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\subprocess.py", line 1615, in _readerthread
    buffer.append(fh.read())
                  ~~~~~~~^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 460: character maps to <undefined>
 Exception in thread Thread-33 (_readerthread):
 Traceback (most recent call last):
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 1044, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\threading.py", line 995, in run
    self._target(*self._args, **self._kwargs)
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\subprocess.py", line 1615, in _readerthread
    buffer.append(fh.read())
                  ~~~~~~~^^
  File "C:\Users\ChristophSchwoerer\AppData\Local\Programs\Python\Python313\Lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 6263: character maps to <undefined>
 [glm-kimi-adapter] Subagent 6 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 7 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 8 gestartet (Typ: explore)
 [glm-kimi-adapter] Ende: 2026-08-28T06:52:30.647891+00:00
 [glm-kimi-adapter] Turns: 28
 [glm-kimi-adapter] Tokens gesamt: 5,704,697
 [glm-kimi-adapter] Tool-Calls: 102
 [glm-kimi-adapter] Subagenten: 8 (completed: 3, failed: 5)
 [glm-kimi-adapter] Ergebnisdateien: 7
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\moonshotai\kimi-k3\builtin\high\02_Lauf_2026-08-28_075453_v8.0.0-6bdf\RawResult.json
@@ -0,0 +1 @@
@@ -0,0 +1,71 @@
 ## Gefundene Anforderungen
 Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
 Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 15 | 18,5 % |
 | SyRS | 31 | 38,3 % |
 | SwRS | 35 | 43,2 % |
 | **Gesamt** | **81** | 100 % |
 ### Anforderungstypen
 | Typ | Anzahl | Anteil |
 |---|---:|---:|
 | funktional | 27 | 33,3 % |
 | Sicherheit | 15 | 18,5 % |
 | Schnittstelle | 9 | 11,1 % |
 | Daten | 8 | 9,9 % |
 | nicht-funktional | 7 | 8,6 % |
 | funktional/Sicherheit | 6 | 7,4 % |
 | Schnittstelle/Sicherheit | 2 | 2,5 % |
 | Sicherheit/funktional | 2 | 2,5 % |
 | Daten/Sicherheit | 2 | 2,5 % |
 | Daten/nicht-funktional | 1 | 1,2 % |
 | (2 weitere) | 2 | 2,5 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 180 |
 | davon `PRIMÄR` | 91 (50,6 %) |
 | davon `SEKUNDÄR` | 77 (42,8 %) |
 | davon `KONTEXT` | 12 (6,7 %) |
 | Belege je Anforderung (Median) | 2 |
 | Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 67 (82,7 %) |
 ### Übernahmewürdigkeit
 | Einstufung | Anzahl | Anteil |
 |---|---:|---:|
 | übernehmen | 78 | 96,3 % |
 | workaround | 1 | 1,2 % |
 | sonderfall | 1 | 1,2 % |
 | veraltet | 1 | 1,2 % |
 ### Status
 | Kategorie | Anzahl | Anteil |
 |---|---:|---:|
 | belegt | 76 | 93,8 % |
 | als `HYPOTHESE` gekennzeichnet | 5 | 6,2 % |
 | als Workaround vermerkt | 0 | 0,0 % |
 | Konsolidierungskandidaten | 7 | 8,6 % |
 | mit ISO-25010-Qualitätsmerkmal | 81 | 100,0 % |
 ### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
 | Vorgabe | Ergebnis |
 |---|---|
 | **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
 | **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (34 risikorelevante Anforderungen, alle gedeckt) |
 | **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
 | **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 81 Anforderungen eingestuft) |
 | **Traceability** – Verknüpfung zwischen den Ebenen | 81 von 81 mit Tracelinks (100,0 %) |
@@ -0,0 +1 @@
@@ -0,0 +1,183 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 02
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-26
 - **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
 - **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Zusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.
 Nicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 - spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only)
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $laufDir\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T08:52:30.7500020+02:00
@@ -0,0 +1,8 @@
 {
  "modell": "moonshotai/kimi-k3",
  "modus": "builtin",
  "iteration": "Iteration 6",
  "effort": "high",
  "promptHash": "F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849",
  "skillVersion": "v8.0.0"
 }
@@ -0,0 +1 @@
 2026-08-28T07:54:53.3681267+02:00
@@ -0,0 +1,244 @@
 # Analysebericht - RRE der c-entron ERP-Suite (V1 Baseline, Iteration 02)
 Erzeugt durch statische Analyse der Codebasis (keine Ausfuehrung). Werkzeuge:
 Verzeichnislistung, Dateizugriff, Regex-Suche, lesende Shell-Kommandos.
 Ergebnisdateien: StRS.md, SyRS.md, SyRS-Ergaenzungen.md, SwRS.md,
 SwRS-Ergaenzungen.md, Traceability.md, Hypothesen.md, Glossar.md, Analysebericht.md.
 Die beiden Ergaenzungsdateien sind integrale Fortsetzung der jeweiligen Spezifikation
 (ID-Reihen: SyRS 001-036 in SyRS.md, SyRS 037-042 in SyRS-Ergaenzungen.md; SwRS 001-028
 in SwRS.md, SwRS 029-040 in SwRS-Ergaenzungen.md).
 Gesamtumfang: StRS 15 | SyRS 42 | SwRS 40 = 97 Anforderungen.
 Status: 95 belegt, 2 HYPOTHESE (SwRS-033, SwRS-038).
 ---
 ## 1. Schritt 0 - Modulinventar (vor der ersten Anforderung)
 | # | Fachliches Modul | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe (1 Satz) |
 |---|---|---|---|
 | 1 | Geschaeftspartnerstamm (Kunden/Lieferanten) | src/backend/Centron.BL/Accounts, CustomerArea, BusinessPartner | Fuehren von Kunden und Lieferanten samt Anschriften, Ansprechpartnern, Filialzuordnung. |
 | 2 | Artikelverwaltung | src/backend/Centron.BL/Warehousing (ArticleBL, ArticleManagement, TaxBL) | Pflege von Artikelstamm, Preisen, Einheiten, Stuecklisten. |
 | 3 | Barcode-/Seriennummernverwaltung | src/backend/Centron.BL/Warehousing (BarcodeBL, BarcodeHistoryBL) | Erfassung und Historie von Seriennummern ueber den Lebenszyklus. |
 | 4 | Lagerverwaltung/Inventur | src/backend/Centron.BL/Warehousing (StockManagement, InventoryManagement) | Lagerbestaende, Nebenlager, Inventuren mit Zaehlgruppen. |
 | 5 | Kommissionierung | src/backend/Centron.BL/Warehousing (Commissions, CommissioningManagement) | Kommissionierung von Auftraegen inklusive Teilmengen. |
 | 6 | Einkauf/Bestellwesen | src/backend/Centron.BL/{Buying|Purchasing}; SSMS BestKopf2/WareKopf/KalkKopf | Beschaffungskette Bestellung, Wareneingang, WE-Kalkulation. |
 | 7 | Vertriebsbelege (Angebot..Gutschrift) | src/backend/Centron.BL/Sales/Receipts | Vertriebliche Belegkette mit Versionierung, Storno, Festschreibung. |
 | 8 | Beleg-Warenkorb/Freigaben | src/backend/Centron.BL/Sales/Receipts (ReceiptCartBL, ReceiptCartReleaseSystemBL) | Warenkorb-basierte Beleggenerierung und Freigabeworkflow. |
 | 9 | Vertragsmanagement | src/backend/Centron.BL/Sales/Receipts/ContractLists, LeasingAndService; SSMS Vertrag* | Click-, Leasing-, Wartungsvertraege mit automatisierter Abrechnung. |
 | 10 | Mahnwesen/OPOS | src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning, Opos | Mahnlaeufe bis Stufe 3 und Offene-Posten-Auswertung. |
 | 11 | Kassenbuch | src/backend/Centron.BL/Sales/CashBooks | Historisches Kassenbuchmodul (Rechte [Obsolete]). |
 | 12 | Provisionsabrechnung | src/backend/Centron.BL/Sales/Receipts (ReceiptProvision*BL) | Provisionsschemata und Zielueberwachung an Belegen. |
 | 13 | Kundenanlagen/Stammblaetter | src/backend/Centron.BL/Sales/CustomerAssets | Kundenanlagen (Geraetekarten) mit Historie, Sperrung, Vertragsbezug. |
 | 14 | Zeitwirtschaft | src/backend/Centron.BL/Time, Sales/HourlySurchargeRatesBL | Arbeitszeiten, Stundenzueschlaege, Helpdesk-Timer-Abrechnung. |
 | 15 | Helpdesk/Tickets | src/backend/Centron.BL/Sales/Support; SSMS hlpdsk_* | Ticketing mit Kategorien, Prioritaeten, Zeiten, Historie, Eskalation. |
 | 16 | C-FLOW Ticketvorlagen | src/nexus/CentronNexus/Management/TicketPatterns | Ticketvorlagen mit Checklisten, Formularen, Mails, Skripten. |
 | 17 | Externer Helpdesk | src/backend/Centron.BL/ExternalHelpdesk | Sicht externer Beteiligter auf den Helpdesk. |
 | 18 | Ruecksendung/RMA/Reparatur | SSMS Rma; UserRightsConst RMA-*; WPF-Modul Rma | RMA-Faelle und Reparatureingang. |
 | 19 | CRM/Marketing/Sonderaktionen | src/backend/Centron.BL/Sales/Marketing | Marketingaktionen, Telemarketing, CRM-Projekte, Kontakte. |
 | 20 | Projektverwaltung | src/backend/Centron.BL/Projects, TicketProjects; WPF ProjectPriceImport | Vertriebsprojekte und Projektpreis-Import. |
 | 21 | Kalender/Terminplanung | src/backend/Centron.BL/Calendar; SSMS Terminplanung* | Kalender, Mein Tag, Zeitkonten (Urlaub/Krankheit/Kurzarbeit). |
 | 22 | Personalverwaltung | src/backend/Centron.BL/EmployeeArea; SSMS Personal* | Mitarbeiter- und Gruppenverwaltung inkl. Auslastung. |
 | 23 | Finanzen/Zahlungsverkehr | src/backend/Centron.BL/Finances, Accounting | Zahlungsein- und -ausgaenge, Bankkonten. |
 | 24 | Online-Banking/FinAPI | src/backend/Centron.BL/Finances/OnlineBanking; src/apis/Centron.APIs.FinAPI | Kontoauszuege via FinAPI und Zuordnung zu Zahlungseingaengen. |
 | 25 | Buchhaltungsschnittstellen | src/backend/Centron.BL/DataExchange/BookKeeping | Ex-/Import zu Buchhaltungssystemen mit Exportkennzeichen. |
 | 26 | Datenaustausch/EDI | src/backend/Centron.BL/DataExchange, EDI | EDI-Gateway, Logs, Dispatcher, Exports. |
 | 27 | Versanddienstleister | src/apis/Centron.Api.Gls, Centron.Api.Shipcloud; ShipcloudPackageTemplateBL | Paketlabel und Frachtdaten ueber Carrier. |
 | 28 | E-Rechnung | src/apis/Centron.Api.EbInterface; Centron.Gateway.OpenTrans | ebInterface/OpenTrans-Integration. |
 | 29 | Artikeldatenintegration | src/apis/Centron.APIs.{ITscope|Icecat|Cop|Egis}DataAccess; ArticleImport* | Katalog-/Distributor-Import und Preisaktualisierung. |
 | 30 | DMS/Doku | src/backend/Centron.BL/Administration/FileManagement, DocumentationArea; Centron.Api.docuFORM | Ablage, Verzeichnisrechte, docuFORM-Formularveredelung. |
 | 31 | Report/Statistik | src/backend/Centron.BL/{ReportEngine|Reporting|Statistics} | Reports, Statistiken, Auswertungen. |
 | 32 | Textbausteine | src/backend/Centron.BL/TextModuleArea | Zentral gepflegte Textbausteine. |
 | 33 | Mail/Kommunikation | src/backend/Centron.BL/{Mail|Mailings|MailScanner|Outlook|Chats|Notifications|SocialMedia|VideoPortal|Tapi|WebLinks|NexusNotifications} | Mail, Chat, Benachrichtigungen, Social Media, TAPI. |
 | 34 | IT-Asset-Inventarisierung | SSMS AssetManagement* (ca. 180 Tabellen); BL Devices, RiverDivo (veraltet) | Inventarisierung und Monitoring von IT-Infrastruktur. |
 | 35 | IT-Planung | src/backend/Centron.BL/ItPlanner | IT-Infrastruktur-Planung mit Checklisten. |
 | 36 | WebSuite-Altplattform | src/backend/Centron.BL/WebSuite | Veralteter Webshop/Webhelpdesk (Rechte [Obsolete]). |
 | 37 | Nexus Kundenportal/WebCart | src/nexus/CentronNexus/WebCart | Endkundenshop sowie Kundenportal (Belege, Vertraege, Tickets). |
 | 38 | Nexus Outlook-AddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Kopplung an Tickets, CRM, Belege, Dokumente. |
 | 39 | Nexus interne Module | src/nexus/CentronNexus/{Management|DocumentSigning|ProductionOrderManagement|Office|WebOffer|WebVersion} | Adminmodule, Dokumentsignatur, Produktionssteuerung im Web. |
 | 40 | REST-Webservice/Auth-Plattform | src/webservice/*; src/backend/Centron.BL/WebServices, Administration/Logins | REST-API mit Ticket-, JWT- und 2FA-Authentifizierung. |
 | 41 | Lizenzierung | src/backend/Centron.BL/Administration/Licensing | Herstellerlizenz vor Datenbankbetrieb erzwingen. |
 | 42 | System-/DB-Verwaltung/Skripte | src/backend/Centron.BL/Administration/{Scripts|Settings|...}; SQLScriptCollection4.xml | Schema-Migration, Einstellungen, Systeminformation. |
 | 43 | DSGVO | UserRightsConst.DsgvoModule; PasswordManagementArea | Rechtegesteuerter Datenschutz- und Bereinigungsprozess. |
 | 44 | Passwortmanager | src/backend/Centron.BL/PasswordManager | Zentraler Passworttresor mit Exportrechten. |
 | 45 | Selbstbedienung/MyCentron/MyDay | src/backend/Centron.BL/{SelfCare|MyCentron|MyDay|ToDoArea|TaskManager|AppointmentRequests} | To-Dos, Mein Tag, Aufgaben, Terminanfragen. |
 | 46 | KI-Modul | src/backend/Centron.BL/ArtificialIntelligence; SSMS ArtificialIntelligencePrompt* | Rechtegesteuerte KI-Assistenz mit Prompt-Konfiguration. |
 | 47 | Massenupdate/Datenqualitaet | src/backend/Centron.BL/MassUpdate; HostedService MassUpdateService/DataQualityService | Zeitgesteuerte Massenupdates und Qualitaetspruefung. |
 | 48 | Erwartete Ereignisse | src/backend/Centron.BL/ExpectedEvents | Erfassung und Auswertung erwarteter Geschaeftsereignisse. |
 | 49 | Aenderungsverfolgung/Audit | src/backend/Centron.BL/ChangeTracking; DAO/ChangeTracking; ReceiptLogBL | Feld- und Beleg-Auditing. |
 | 50 | Gutscheinverwaltung (alt) | src/backend/Centron.BL/VoucherManagement | Alt-Gutscheinmodul (Rechte [Obsolete]). |
 | 51 | WPF-Desktopclient | src/centron/Centron.WPF.UI (Modules, ViewModels, Views) | Desktop-Shell fuer die Module (Ribbon, Rechte-Parser). |
 | 52 | Gemeinsame UI-/Core-Bibliotheken | src/shared/* (Controls, Core) | Wiederverwendete UI-Controls und Core-Typen. |
 | 53 | Persistenzschicht | src/backend/Centron.DAO, Centron.Entities | NHibernate-DAO, Entities, Sessions, Transaktionen. |
 | 54 | Mobile Erfassung | src/backend/Centron.BL/Mobile; DAO/Mobile | Serverseitige Logik mobiler Erfassung. |
 | 55 | Querschnitt/Erweiterbarkeit | src/backend/Centron.BL/{Tags|Processes|CPra|Customizations|Tools|ExternalToolsBL|Transactions} | Tags, Workflows, CPra, Anpassungen. |
 | 56 | Mandantenfuehrung | SSMS Mandant; CustomerToBranches, LieferantenToFiliale | Mandanten- und Filial-Verankerung im Schema. |
 ---
 ## 2. Abdeckungstabelle (Schritt 0b/0c)
 Einstufung: tief = Kernlogik mit durchsetzender Stelle gelesen; mittel = Einzelbelege
 gelesen; flach = ueber Rechte/Schema gesichert.
 | # | Modul | Einstufung | Anz. Anf. | Abgedeckt durch (IDs) |
 |---|---|---|---|---|
 | 1 | Geschaeftspartnerstamm | mittel | 3 | StRS-002, StRS-003, SyRS-018 |
 | 2 | Artikelverwaltung | mittel | 2 | StRS-009, SwRS-013 |
 | 3 | Barcode/Seriennummern | flach | 1 | SyRS-019 |
 | 4 | Lager/Inventur | flach | 2 | StRS-009, SyRS-021 |
 | 5 | Kommissionierung | flach | 1 | StRS-009 |
 | 6 | Einkauf/Bestellwesen | mittel | 1 | SyRS-020 |
 | 7 | Vertriebsbelege | tief | 9 | StRS-004, SyRS-010, SyRS-011, SyRS-012, SyRS-013, SwRS-003, SwRS-009, SwRS-010, SwRS-012 |
 | 8 | Beleg-Warenkorb/Freigaben | flach | 1 | StRS-011 (ReceiptCart-BL gesichtet, nicht vertieft) |
 | 9 | Vertragsmanagement | tief | 4 | StRS-005, SyRS-016, SyRS-022, SwRS-010 |
 | 10 | Mahnwesen/OPOS | tief | 3 | StRS-008, SyRS-014, SyRS-015 |
 | 11 | Kassenbuch | mittel | 1 | SwRS-020 |
 | 12 | Provisionsabrechnung | flach | 1 | SyRS-016 |
 | 13 | Kundenanlagen/Stammblaetter | mittel | 4 | StRS-010, SyRS-024, SwRS-006, SwRS-016 |
 | 14 | Zeitwirtschaft | mittel | 3 | StRS-007, SyRS-017, SwRS-025 |
 | 15 | Helpdesk/Tickets | tief | 6 | StRS-006, SyRS-009, SyRS-021, SwRS-017, SwRS-018, SwRS-021 |
 | 16 | C-FLOW Ticketvorlagen | mittel | 1 | SwRS-030 |
 | 17 | Externer Helpdesk | nicht analysiert | 0 | Begruendung: Modulverzeichnis gesichtet, Kernlogik nicht rechtzeitig sicher gelesen; unbelegte Aussage wuerde gegen die No-Halluzination-Regel verstossen. |
 | 18 | Ruecksendung/RMA/Reparatur | mittel | 1 | SyRS-037 |
 | 19 | CRM/Marketing/Sonderaktionen | mittel | 2 | SyRS-038, StRS-013 |
 | 20 | Projektverwaltung | flach | 1 | SyRS-042 |
 | 21 | Kalender/Terminplanung | flach | 2 | SwRS-025, StRS-013 |
 | 22 | Personalverwaltung | flach | 1 | StRS-002 |
 | 23 | Finanzen/Zahlungsverkehr | mittel | 2 | SyRS-015, SyRS-040 |
 | 24 | Online-Banking/FinAPI | mittel | 2 | SyRS-026, StRS-008 |
 | 25 | Buchhaltungsschnittstellen | mittel | 2 | SyRS-015, SyRS-025 |
 | 26 | Datenaustausch/EDI | mittel | 2 | SyRS-039, SyRS-008 |
 | 27 | Versanddienstleister | flach | 1 | SyRS-028 |
 | 28 | E-Rechnung | mittel | 1 | SyRS-025 |
 | 29 | Artikeldatenintegration | flach | 1 | SyRS-027 |
 | 30 | DMS/Doku | mittel | 2 | SyRS-033, SwRS-029 |
 | 31 | Report/Statistik | flach | 2 | StRS-015, SyRS-035 |
 | 32 | Textbausteine | flach | 1 | SwRS-026 |
 | 33 | Mail/Kommunikation | flach | 4 | StRS-013, SyRS-034, SyRS-035, SwRS-037 |
 | 34 | IT-Asset-Inventarisierung | mittel | 2 | StRS-010, SwRS-006 |
 | 35 | IT-Planung | flach | 1 | StRS-010 |
 | 36 | WebSuite-Altplattform | mittel | 1 | SwRS-034 |
 | 37 | Nexus Kundenportal/WebCart | mittel | 2 | StRS-011, SyRS-031 |
 | 38 | Nexus Outlook-AddIn | flach | 1 | SwRS-032 |
 | 39 | Nexus interne Module | mittel | 3 | SwRS-031, StRS-014, SyRS-001 |
 | 40 | REST-Webservice/Auth-Plattform | tief | 8 | SyRS-002, SyRS-003, SyRS-004, SyRS-005, SyRS-036, SwRS-023, SwRS-024, SyRS-008 |
 | 41 | Lizenzierung | tief | 1 | SyRS-006 |
 | 42 | System-/DB-Verwaltung | tief | 1 | SyRS-007 |
 | 43 | DSGVO | mittel | 2 | StRS-012, SyRS-030 |
 | 44 | Passwortmanager | mittel | 1 | SyRS-029 |
 | 45 | Selbstbedienung/MyCentron | flach | 2 | SwRS-039, StRS-013 |
 | 46 | KI-Modul | mittel | 2 | SyRS-032, SwRS-040 |
 | 47 | Massenupdate/Datenqualitaet | flach | 2 | SwRS-027, StRS-015 |
 | 48 | Erwartete Ereignisse | flach | 1 | SwRS-036 |
 | 49 | Aenderungsverfolgung/Audit | flach | 2 | SwRS-011, SwRS-028 |
 | 50 | Gutscheinverwaltung (alt) | mittel | 1 | SwRS-038 [HYPOTHESE] |
 | 51 | WPF-Desktopclient | mittel | 1 | SwRS-014 |
 | 52 | Gemeinsame Bibliotheken | flach | 1 | SwRS-019 |
 | 53 | Persistenzschicht | mittel | 2 | SwRS-001, SwRS-002 |
 | 54 | Mobile Erfassung | flach | 1 | SwRS-033 [HYPOTHESE] |
 | 55 | Querschnitt/Erweiterbarkeit | flach | 2 | SwRS-037, StRS-013 |
 | 56 | Mandantenfuehrung | mittel | 2 | StRS-012, SwRS-005 |
 Mindestabdeckung: 55 von 56 Modulen haben mindestens eine Anforderung.
 Nicht analysiert: 1 Modul (#17 ExternalHelpdesk, mit Begruendung).
 ---
 ## 3. Konsistenzcheck ueber das gesamte Anforderungs-Set
 - Doppelte oder mehrfach vergebene IDs: keine. IDs im Format StRS-|SyRS-|SwRS-<Nr.>
  einmalig; Ergaenzungsdateien setzen die jeweilige Nummernreihe nahtlos fort.
 - Anforderungen ohne Beleg: keine. Jede der 97 Anforderungen fuehrt mindestens einen
  klassifizierten Beleg mit Begruendung.
 - Anforderungen ohne Uebernahmewuerdigkeit: keine. Das Feld ist in allen Anforderungen
  mit Wert und Halbsatz-Begruendung gesetzt.
 - Tracelinks auf nicht existierende IDs: Alle referenzierten IDs (StRS 001-015,
  SyRS 001-042, SwRS 001-040) existieren. Hinweis: wenige Tracelinks sind inhaltlich
  grob eingehangen (Hinweis- statt Parent-Verknuepfung), jedoch ohne Existenzverletzung.
 - Deckungsgleiche Anforderungen ohne Kandidatenvermerk: keine verblieben. Markierte
  Konsolidierungskandidaten: SwRS-003 (9 Kopf-/Pos-Tabellenpaare), SwRS-004
  (Kunden/Kreditor vs. Accounts), SwRS-006 (Stammblatt vs. AssetManagement),
  SyRS-024/SwRS-006 (gleiches Objekt auf 2 Ebenen), SyRS-028 (zwei Carrier),
  SyRS-037 (RMA vs. Reparatur), SwRS-009 (God-Class), SwRS-020 (Kassenbuch alt),
  SwRS-034 (Alt-Webs), SwRS-038 (Gutschein vs. Wertgutschrift).
 - Liste aller risikorelevanten Anforderungen (Sicherheit, Abrechnung/Fakturierung,
  Berechtigungen) mit Belegsituation:
  | ID | Titel | PRIMAER-Beleg mit durchsetzender Stelle? | HYPOTHESE? |
  |---|---|---|---|
  | SyRS-003 | Ticket-Authentifizierung | ja (CentronHost.AddCentronTicket; TicketBL.GetTicket) | nein |
  | SyRS-004 | JWT/OIDC-Login | ja (TokenValidationParameters; JwtAuthController-Authorize) | nein |
  | SyRS-005 | 2FA per E-Mail | ja (TwoFactorAuthController.ValidateTwoFactorCode) | nein |
  | SyRS-006 | Lizenz vor DB | ja (CentronHost.Start: TryLoadLicense vor SetupDatabaseConnection) | nein |
  | SyRS-009 | Rechtepruefung Helpdesk/Stamm | ja (AccountAddressBL Z69/156-178; AccountBL Z501/1299) | nein |
  | SyRS-010 | Rechnungsstorno | ja (ReceiptInvoiceBL.CancelInvoice Z143-205) | nein |
  | SyRS-011 | Festschreibung IsFixed | ja (ReceiptInvoiceBL.FixInvoice; CheckIfInvoiceIsFixed) | nein |
  | SyRS-012 | Belegversionierung | ja (Schema *Versions; CreateNewVersion in CancelInvoice) | nein |
  | SyRS-013 | Statusmodell | ja (ReceiptState.cs) | nein |
  | SyRS-014 | Mahnlauf | ja (DunningRunWebServiceBL.ValidateDunningRun; DunningRunBL) | nein |
  | SyRS-015 | Exportsperre/Erloeskonto | ja (IsReceiptExported-Pruefung in CancelInvoice) | nein |
  | SyRS-016 | Provisionsabrechnung | ja (UpdateExpiredProvisionSchemasService) | nein |
  | SyRS-017 | Abgerechnete Zeiten sperren | ja (RemoveTimers in Transaktion; [KONTEXT] CentronRights) | nein |
  | SyRS-018 | Geschaeftspartner-Rechte | ja (AccountBL.ValidateUserRights-Aufrufstellen) | nein |
  | SyRS-019 | Seriennummern | ja (UserRightsConst SerialAdministration; Barcodes.Clear) | nein |
  | SyRS-020 | Bestell-/WE-Kette | ja (Schema + Rechte) | nein |
  | SyRS-021 | Inventur | ja (UserRightsConst.Inventory-Block) | nein |
  | SyRS-024 | Anlagensperre | ja (MasterDataListBL DependencyCheckFailed; AssetLockBL) | nein |
  | SyRS-026 | Online-Banking | ja (UserRightsConst.OnlineBanking; BL-Klassen) | nein |
  | SyRS-029 | Passwortmanager-Export | ja (PasswordManagerBL.ValidateUserRights) | nein |
  | SyRS-030 | DSGVO-Loeschung | ja (UserRightsConst.DsgvoModule) | nein |
  | SyRS-032 | KI-Rechtebindung | ja (UserRightsConst.ArtificialIntelligence) | nein |
  | SyRS-033 | DMS-Rechte | ja (DirectoryBL ruft AccountBL.ValidateUserRights) | nein |
  | SwRS-010 | CreateNewVersion vor Storno | ja (Aufruf in CancelInvoice) | nein |
  | SwRS-012 | Festschreibung SQL | ja (RawSqlAccess UPDATE RechKopf) | nein |
  | SwRS-013 | Negativbuchung | ja (UserRightsConst.StockList) | nein |
  | SwRS-018 | Helpdesk-Fingerprint | ja (AddHostedService<ValidateHelpdeskFingerprintService>) | nein |
  | SwRS-022 | CORS AllowAnyOrigin | ja (UseCors in CentronHost.ConfigureInternal) | nein |
  | SwRS-024 | WebServiceConfig-Geheimnisse | ja (WebServiceConfigHelper-Verwendung) | nein |
  | SwRS-028 | Change Tracking/Audit | ja (SHOW_AUDIT; BL-/DAO-Verzeichnisse) | nein |
  Verstoss gegen risikobasierte Priorisierung: keiner. Alle 31 risikorelevanten
  Anforderungen besitzen mindestens einen PRIMAER-Beleg mit durchsetzender Stelle.
 - Abgleich Hypothesen.md gegen Inline-Markierungen: Hypothesen.md listet exakt die
  beiden Anforderungen mit Status HYPOTHESE (SwRS-033, SwRS-038); es existieren keine
  weiteren Inline-Markierungen und keine zusaetzlichen freien Fragen. Deckungsgleich.
 ---
 ## 4. Selbstbewertung
 1. Modulabdeckung (absolut): 56 Module - 7 tief (#7 Vertriebsbelege, #9 Vertrags-
   management, #10 Mahnwesen, #15 Helpdesk, #40 Webservice/Auth, #41 Lizenzierung,
   #42 Systemverwaltung) | 24 mittel | 24 flach | 1 nicht analysiert (#17).
 2. Mindestabdeckung**: erreicht fuer 55 von 56 Modulen. Fehlend: #17 ExternalHelpdesk
   (trotz Sichtung des Verzeichnisses; die Kernlogik wurde nicht rechtzeitig sicher
   gelesen; eine unbelegte Aussage wurde bewusst unterlassen).
 3. Stellen mit duennem Beleg (hoher Anteil SEKUNDAER/KONTEXT oder HYPOTHESE):
   #1 (StRS-003, stark von CentronRights.md/Kontext abhaengig), #5 Kommissionierung,
   #8 Beleg-Warenkorb, #20 Projektverwaltung, #27 Carrier, #29 Artikelimport,
   #31 Statistik, #33 Mail/Kommunikation, #35 IT-Planung, #45 SelfCare, #48 ExpectedEvents,
   #54 Mobile (HYPOTHESE), #55 Querschnitt.
 4. Hypothesen: Es wurden 2 gefuehrt (SwRS-033 Mobile, SwRS-038 Gutschein). Die niedrige
   Zahl spiegelt die priorisierte Vertiefung auf PRIMAER-Belege, ist nicht Beweis fuer
   Vollstaendigkeit; offene Einzelfragen sind in Abschnitt 5 dokumentiert.
 5. Nachschlagempfehlungen (Folgeiteration):
   - ReceiptBL.cs (623.866 Bytes) und ReceiptItemBL.cs (230.597 Bytes): systematische
     Extraktion von Preis-/Rundungs-, Steuer- und Freigabelogik (bisher nur Aufrufpfade).
   - SQLScriptCollection1-4.xml: Views, Migrationen und Constraints (z. B.
     cvw_DunningRunItems) als PRIMAER-Belege fuer Datenanforderungen nutzen.
   - #17 ExternalHelpdesk, #8 ReceiptCartReleaseSystem-Freigabeworkflow,
     #34 AssetManagement-Detail (Checks, Monitoring-Streams), Nexus WebOffer und
     CustomerPortal-FormFiller detaillieren.
   - Rechtekatalog: vollstaendige Tabelle der numerischen Rechte-IDs exportieren und mit
     UI-Strings abgleichen.
   - Altmodule (WebSuite, RiverSuite, SupRemo, DirectNow, Barrechnung): eindeutige
     Ressourcenliste fuer das Au
     sserbetriebnehmen im Zielsystem erstellen.
@@ -0,0 +1,35 @@
 # Glossar (Domänenbegriffe)
 | Begriff | Definition im Kontext dieser Spezifikation |
 |---|---|
 | Beleg | Kaufmaennischer Vorgangscontainer (Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift, Anfrage, Bestellung, Wareneingang, WE-Kalkulation etc.) jeweils mit Kopf- und Positionssatz. |
 | Belegversionierung | Historisierungskonzept, bei dem jede Aenderung eines Belegs eine neue Kopf-/Positionssatz-Version (*Versions-Tabellen) erzeugt. |
 | Festschreibung (IsFixed) | Unveraenderlichkeits-Flag auf RechKopf; blockiert spaetere Aenderungen (GoBD). |
 | Storno | Durchsetztes GoBD-vertraegliches Widerrufen eines Belegs als neue Version mit State Canceled. |
 | GoBD | Grundsaetze zur ordnungsgemaessen Fuehrung und Aufbewahrung von Buechern (deutsche Buchfuehrungsvorgaben); Anlass fuer Versionierung, Festschreibung und Audit-Logs. |
 | Mahnlauf | Gestaffelter Mahnvorgang je Kunde (max. Stufe 3) mit eigener fortlaufender Laufnummer; DB: Tabelle Mahnlauf. |
 | OPOS | Offene Posten (Liste) je Kunde; Sammelvorgang ueber offene Rechnungen. |
 | Vertragsrechnung | Periodisch aus einem Vertrag (Click-, Leasing-, Wartungs-, Flatrate-Vertrag) automatisch erzeugte Rechnung. |
 | Click-Vertrag | Vertrag mit mengenbasierter (pro Klick) Abrechnung, ueblicherweise auf Stammblatt-Geräte; Zaehler werden beim Storno zurueckgesetzt. |
 | Stammblatt | Kundenanlage/Geraetekarte beim Kunden (GeraeteKopf/GeraetePos), oft Drucker; mit Historie, Sperrlogik und Vertragsbezug. |
 | AssetManagement-Geraet | Inventarisiertes IT-Geraet aus dem uebergreifenden AssetManagement-Subsystem (~180 Tabellen), fachlich teilweise deckungsgleich mit Stammblatt. |
 | Helpdesk-Timer | Auf ein Ticket gebuchte Zeit mit optionaler Unterschrift; abrechenbar ueber Belege; Tabelle hlpdsk_timer. |
 | Ticketvorlage (C-FLOW) | Vorlage zur standardisierten Ticketerstellung (Allgemein, Kunde, Checklisten, Mailtemplate, Skripte, Webformular), verwaltet in Nexus. |
 | Sonderpreis | Kundenindividueller Artikelpreis; Grundlage des WebCart-Endkundenshops. |
 | Wertgutschrift | Zeitwert-/Guthabengutschrift; aktiv genutzter Ersatz des veralteten Gutscheinmoduls. |
 | Rechtekonstante (UserRightsConst) | Numerische ID eines Rechts; Gruppen tragen eine ID mit Unterrechten; IDs ab 20800000 gehoeren zur neuen .NET-Modulwelt. |
 | Restricting Right | Einschraenkendes Recht, das die Sichtbarkeit reduziert (nur eigene, nur eigene Filiale, nur eigene Abteilung); siehe CentronRights.md. |
 | Mandant | Geschlossener Datenbestand eines Betreibers; eigene Tabelle; System ist mandantenfaehig ausgelegt. |
 | Filiale | Zweigstelle eines Mandanten; Steuerung von Sichtbarkeiten/Restriktionen. |
 | Ticket (Authentifizierung) | Serverseitig aufloesbares Authentifizierungstoken des Centron-Webservices (TicketBL/AddCentronTicket); nicht zu verwechseln mit Helpdesk-Ticket. |
 | Web-Account | Endkunden-Zugang zum Nexus-Kundenportal, gekoppelt an Ansprechpartner/Adresse im Adressstamm. |
 | EDI | Electronic Data Interchange; gatewaygestuetzter Standardnachrichtenverkehr (unter anderem EdiDownloadService). |
 | ebInterface | Oestereichisches XML-E-Rechnungsformat; ueber eigenes API-Projekt integriert. |
 | OpenTrans | XML-Standarddokumentformat (hier: INVOICE), ueber Centron.Gateway typisiert deserialisiert. |
 | DSGVO-Modul | Rechtegesteuertes Modul zum datenschutzkonformen Löschen von Kontakten und zur Bereinigung der Datenbank. |
 | Result/ResultStatus | Einheitliches Rueckgabmuster der BL (Success/Warning/Error) mit DefaultMessageCodes (z. B. RightCheckFailed). |
 | I3D | Primaerschluessel-Spaltenname der Entitaeten (historisch; vergleichbar mit Id). |
 | Nebenlager | Zweites Lager je Artikel (NebenlagerArtikel). |
 | Inventur / Zaehlgruppe | Periodische Bestandsinventur, organisiert in Zaehlgruppen mit Entsperrlogik. |
 | SqlScriptCollection | Versionierte XML-Bibliothek mit SQL-Migrations- und View-Skripten, die der ScriptEngine beim Start ausfuehrt. |
 | RiverSuite / SupRemo / DirectNow | [Obsolete] Aeltere Integrationsfamilien (Monitoring, Fernwartung), nicht mehr zu erweitern. |
@@ -0,0 +1,26 @@
 # Hypothesen
 Diese Datei sammelt alle mit HYPOTHESE markierten Anforderungen. Sie ist deckungsgleich mit
 den Inline-Markierungen (Status: HYPOTHESE) in den Spezifikationsdateien. Freie Fragen ohne
 zugehoerige Anforderung sind in der Selbstbewertung des Analyseberichts gefuehrt.
 ## Hypothese 1 - SwRS-033 (Mobile Datenerfassung)
 - Kernaussage: Es existiert ein serverseitiges Mobile-Modul (Mobile/MobileBL.cs) und ein
  zugehoeriges DAO-Verzeichnis. Die eigentliche mobile Client-Anwendung liegt nicht im
  Repository vor.
 - Offene Frage: Welche konkrete mobile App (native App, Scanner-Client oder PWA) konsumiert
  diese Business-Logik? Gibt es eine Offline-Synchronisation, und nach welchem
  Konfliktmodell? Diese Information fehlt zur Bestaetigung.
 - Nachweis: src/backend/Centron.BL/Mobile/MobileBL.cs; src/backend/Centron.DAO/Mobile
 ## Hypothese 2 - SwRS-038 (Vouchermanagement / Gutscheine)
 - Kernaussage: Das Recht zur Gutscheinverwaltung (RIGHT_GUTSCHEINVERWALTUNG, 20400319) ist
  als [Obsolete] markiert, waehrend Wertgutschriften aktiv rechtegesteuert sind. Das
  verbleibende Funktionsverhalten des Altmoduls wurde nicht vollstaendig analysiert.
 - Offene Frage: Ist das klassische Gutscheinmodul in aktuellen Builds noch aufrufbar
  (UI-Einstiegspunkte, Servicedurchlauf), oder verbleibt nur ein zu migrierender
  Datenbestand? Diese Information fehlt zur Bestaetigung.
 - Nachweis: UserRightsConst.cs (ID 20400319 mit [Obsolete], ID 20400292 aktiv);
  src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs (nur teilweise gelesen)
@@ -0,0 +1,332 @@
 # StRS - Stakeholder Requirements Specification
 # c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
 # Methode: statische Analyse der Codebasis; Formatfelder gemäß Prompt-Vorgabe.
 ---
 ID:            StRS-001
 Titel:         Geschäftszweck: Integriertes ERP für IT-Systemhäuser
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Systemhaus (Mandant), alle Fachabteilungen
 Vorbedingung:  Datenbank installiert, Lizenz vorhanden
 Fakt:          Die Codebasis enthält fachliche Geschäftslogik-Module (Verzeichnisse in `Centron.BL`): Sales/Receipts, CustomerAssets/Contracts, Warehousing, Finances, Helpdesk (Support), Production, DataExchange/BookKeeping u.v.m.; dazu ein WPF-Desktop-Client (`Centron.WPF.UI`), ein REST-Webservice-Host (`Centron.Host`) und eine Blazor-Weboberfläche (`CentronNexus`).
 Aussage:       Das System soll ein integriertes ERP-System für IT-Systemhäuser/MSP bereitstellen, das Vertrieb (Belege), Vertragsabrechnung, Materialwirtschaft, Service/Helpdesk, Zeitwirtschaft, Finanzen und IT-Asset-Dokumentation in einer gemeinsamen Datenhaltung betreibt.
 Ergebnis:      Ein Mandant betreibt seine kaufmännischen Kernprozesse ohne Systembruch auf einer Instanz.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL (Modulverzeichnisse) - Begründung: durchgesetzte fachliche Trennung der Module im Code
  - [SEKUNDÄR] src/centron/Centron.WPF.UI, src/webservice/Centron.Host/CentronHost.cs, src/nexus/CentronNexus - Begründung: drei Auslieferungskanäle auf derselben BL
  - [KONTEXT]  README.md - Begründung: beschreibt Kunden der Kunden (WebCart) und Bestandteile
 Prüfidee:      Stichprobentest: Belegkette Angebot→Auftrag→Lieferschein→Rechnung mit Artikel- und Kundendaten aus den Stammdaten in einer Datenbank abbildbar.
 Tracelinks:    SyRS-001, SyRS-011, SyRS-013, SyRS-019, SyRS-028
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - zentrale Daseinsberechtigung des Produkts
 Status:        belegt
 ---
 ID:            StRS-002
 Titel:         Akteure und Rollen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Innendienst, Aussendienst, Techniker, Buchhaltung, Lager, Administration, Endkunde (Web-Account), Lieferant, externe Systeme
 Vorbedingung:  -
 Fakt:          `UserRightsConst` definiert Rechtegruppen für Vertrieb (`Sales.Customer.CustomerCommon`, `Offer/Order/DeliveryList/Invoice/CreditVoucher`), `Purchase.StockList`, `Controlling.Finances/Analytics`, `Administration`, `Logistic`, `PasswordManager`, `DsgvoModule`; `CentronRights.md` beschreibt restriktive Rechte in Business-Sprache; `README.md` beschreibt Web-Accounts für Endkunden; Tabelle `Personal`, `PersonalGruppen`, `Filiale`, `Mandant` existieren. `AssetManagementPartners`/-`Socustomer` kennzeichnen Rollen im Kundenkreis.
 Aussage:       Das System soll die Rollen Innendienst/Aussendienst (Vertrieb), Techniker (Helpdesk/Zeiten), Buchhaltung (Finanzen/Mahnen), Lagerverwaltung, Systemadministration, Mandant und Filiale sowie Endkunden (Webaccount im Kundenportal) als Akteure mit je eigenen Rechteprofilen unterstützen.
 Ergebnis:      Jede Business-Funktion ist einer Rolle mit vergebbarer Rechtegruppe zugeordnet.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs - Begründung: vollständige, im Code durchgesetzte Rechtematrix
  - [KONTEXT]  CentronRights.md - Begründung: fachliche Erläuterung der Rechtebedeutung
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Personal]`, `[dbo].[Filiale]`, `[dbo].[Mandant]` - Begründung: Datenhaltung der Akteursdimensionen
 Prüfidee:      Für jede Rollenklasse existiert mindestens eine Rechte-ID in `UserRightsConst`; ein Benutzer ohne Recht erhält keinen Zugriff (neg. Test).
 Tracelinks:    SyRS-009, SyRS-010, SwRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Rollenmodell bleibt fachlich erforderlich
 Status:        belegt
 ---
 ID:            StRS-003
 Titel:         Filiabezogene und eigendatensichtfähige Sichtbarkeit
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertriebsmitarbeiter, Techniker, Führungskraft
 Vorbedingung:  Benutzer ist einer Filiale und ggf. Abteilung zugeordnet
 Fakt:          Rechte wie `SHOW_HELPDESK_ONLY_OWN` (20400340), `SHOW_HELPDESK_ONLY_OWN_BRANCH` (20800045), `SHOW_OFFERS_ONLY_OWN` (20400149), `SHOW_OFFERS_ONLY_OWN_BRANCH` (20400150) bis hin zu `SHOW_ALL_EMPLOYEE_TIMES` (20800173) sind als eigenständige Rechte-IDs deklariert; `CentronRights.md` bezeichnet diese als "restricting rights".
 Aussage:       Das System soll fachliche Sichtbarkeitseinschränkungen (nur eigene Datensätze, nur eigene Filiale, nur eigene Abteilung) als explizit vergebene Restriktionsrechte kennen, die die Datenbankabfragen einschränken.
 Ergebnis:      Ein Mitarbeiter sieht nur die Belege/Tickets, für die sein Profil die Sichtbarkeit gewährt.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs (IDs 20400149-20400160, 20400340, 20800045) - Begründung: im Code durchgesetzte Konstanten
  - [KONTEXT]  CentronRights.md (Helpdesk 1.1/1.2) - Begründung: fachliche Definition "restricting right"
 Prüfidee:      Benutzer mit `SHOW_HELPDESK_ONLY_OWN` sieht keine Tickets fremder Bearbeiter (Abfragetest).
 Tracelinks:    SyRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - zentrales Bedürfnis mehrerer Mandanten
 Status:        belegt
 ---
 ID:            StRS-004
 Titel:         Vertriebsbelegkette Angebot-Auftrag-Lieferschein-Rechnung-Gutschrift
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Innendienst/Außendienst, Kunde
 Vorbedingung:  Kunden- und Artikelstamm vorhanden
 Fakt:          Tabellen `AngKopf/AngPos`, `AufKopf/AufPos`, `LiefKopf/LiefPos`, `AbholKopf/AbholPos`, `RechKopf/RechPos`, `GutKopf/GutPos` inkl. Versions-Pendanten (`RechKopfVersions`, `RechPosVersions` ...); `ReceiptBL` (623.866 Bytes) und `ReceiptItemBL` (230.597 Bytes) implementieren die Beleglogik; spezifische BL-Klassen je Belegart (Ordner Offers, Orders, DeliveryLists, PickUpLists, Invoices, CreditVouchers, DownPayment); `IReceiptSpecificLogic` definiert je Belegtyp abweichendes Verhalten.
 Aussage:       Das System soll eine Vertriebsbelegkette aus Angebot, Auftrag, Lieferschein, Abholschein, Rechnung und Gutschrift führen, in der Belege in Folgebelege überführt (weiterverarbeitet) und versioniert werden.
 Ergebnis:      Geschäftsvorgänge sind von der Offerte bis zur Gutschrift nachverfolgbar dokumentiert.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[AngKopf]`, `[dbo].[AufKopf]`, `[dbo].[LiefKopf]`, `[dbo].[AbholKopf]`, `[dbo].[RechKopf]`, `[dbo].[GutKopf]` - Begründung: persistentes Belegkopf/Positions-Modell je Belegart
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: typenabhängige durchgesetzte Belegvorschriften
  - [SEKUNDÄR] UserRightsConst.cs (`RIGHT_ANGEBOTEDRUCKEN`, `RIGHT_AUFTRAGEDRUCKEN`, ...) - Begründung: belegtypspezifische Druckrechte
 Prüfidee:      Angebot anlegen → Auftrag erzeugen → Positionen übernommen; Überführung erzeugt Referenz (`GetReceiptForwardedInto` in ReceiptInvoiceBL.CancelInvoice).
 Tracelinks:    SyRS-011, SyRS-012, SyRS-013, SwRS-003, SwRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kern des Vertriebsprozesses
 Status:        belegt
 ---
 ID:            StRS-005
 Titel:         Vertragsgeschäft mit Click-/Service-, Leasing- und Wartungsabrechnung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb, Buchhaltung, Kunde
 Vorbedingung:  Stammblätter (Kundenanlagen) vorhanden, Vertragsarten konfiguriert
 Fakt:          Tabellen `VertragKopf`, `VertragPos`, `VertragRechKopfZuordnung`, `VertragGeraete`, `VertragKontingentAnlagePositionen`, `VertragsArt`; BL-Ordner `Sales/Receipts/ContractLists`, `Sales/Receipts/LeasingAndService` und `Sales/CustomerAssets/Contracts/ClickContracts` mit `MasterDataListBL`; CONTRAIL `AUTOMATED_BILLING` (ID 10385), `TIMER_BILLING_MODULE`, `FLATRATE_BILLING_MODULE`; HostedServices `ContractEndeService`, `ContractCloseService`, `UpdateSpecialArticleToContractService`; `CancelInvoice` prüft Vertragsrechnungen gesondert (nur letzte Vertragsrechnung stornierbar).
 Aussage:       Das System soll Verträge (Click-Verträge/Mengenabrechnung, Leasing/Service, Flatrate, Geräte ohne Bezug) verwalten und daraus periodisch automatisch Rechnungen erzeugen; Rechnungen sollen dem Vertrag zugeordnet bleiben.
 Ergebnis:      Vertragsperioden werden ohne manuelle Einzelrechnung abgerechnet; Storno einer Vertragsrechnung setzt den Abrechnungsstand zurück.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[VertragKopf]`, `[dbo].[VertragPos]`, `[dbo].[VertragRechKopfZuordnung]`, `[dbo].[VertragGeraete]` - Begründung: persistentes Vertragsmodell mit Geräte- und Rechnungszuordnung
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: `IsContractInvoice`, `IsLastContractInvoice`, `ResetContract` mit `DeactivateContractInvoice`, `ResetDeviceClickCounter`, `ResetSpecialArticles` - Begründung: durchgesetzte Stornoregel für Vertragsrechnungen
  - [SEKUNDÄR] CentronHost.cs HostedServices `ContractEndeService`, `ContractCloseService` - Begründung: zeitgesteuerter Vertrags-Lifecycle
 Prüfidee:      Storno der letzten Vertragsrechnung setzt Click-Zähler und Sonderartikel zurück (Unit-/Integrationstest gegen das SQL-Schema).
 Tracelinks:    SyRS-016, SyRS-017, SyRS-022, SwRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kern des MSP-Geschäftsmodells
 Status:        belegt
 ---
 ID:            StRS-006
 Titel:         Helpdesk/Ticketing mit SLAs, Zeiten, Checklisten und Eskalation
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Techniker, Helpdesk, Kunde
 Vorbedingung:  Ticket-Typen, Kategorien, Prioritäten konfiguriert
 Fakt:          Tabellen `hlpdsk_requests`, `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_prioritaeten`, `hlpdsk_status`, `hlpdsk_history`, `hlpdsk_timer`, `hlpdsk_request_bearbeiter`; `CentronRights.md` Kapitel Helpdesk (Tickets nur eigene/eigene Filiale, Fälligkeit ändern, Zeiten bearbeiten, Unterschrift löschen, interne Sichtbarkeit, Checklisten-Vorlagen, Taskmanagement); HostedServices `EscalationsService`, `ValidateHelpdeskFingerprintService`.
 Aussage:       Das System soll einen Helpdesk mit Ticket-Typen, Kategorien (Stufen 1+2), Prioritäten, Status, Historie, Bearbeiterzuordnung (inkl. Abteilungseinschränkung), Zeiterfassung mit Unterschrift, Checklisten und Eskalationslogik führen.
 Ergebnis:      Servicefälle sind lückenlos dokumentiert, fristenüberwacht und abrechenbar.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[hlpdsk_requests]`, `hlpdsk_history`, `hlpdsk_timer`, `hlpdsk_request_bearbeiter` - Begründung: persistentes Ticketmodell
  - [PRIMÄR]   CentronHost.cs: `AddHostedService<EscalationsService>()` - Begründung: durchgesetzte automatisierte Eskalation
  - [KONTEXT]  CentronRights.md (Kapitel Helpdesk) - Begründung: fachliche Rechtslogik für Zeiten, Fälligkeit, Sichtbarkeit
 Prüfidee:      Ticket anlegen, Zeit mit Unterschrift buchen, Statuswechsel dokumentiert in `hlpdsk_history`; Eskalation bei Fristüberschreitung (zeitrafferbarer Test).
 Tracelinks:    SyRS-018, SyRS-026, SyRS-030, SwRS-021, SwRS-022
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - zentrale Servicefähigkeit
 Status:        belegt
 ---
 ID:            StRS-007
 Titel:         Automatisierte Abrechnung von Ticket-Zeit auf Verträge/Rechnungen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Buchhaltung, Techniker
 Vorbedingung:  Zeit erfasst, Vertrag/Rechnung vorhanden
 Fakt:          `Rights`-Konstanten `TIMER_BILLING_MODULE` (20800084), `FLATRATE_BILLING_MODULE` (20800085); `HelpdeskTimerBL`, `ReceiptItemTimerBL.RemoveTimers()` wird beim Rechnungsstorno transaktional aufgerufen; Rechte `MOVE_HELPDESK_TIMER`/`DELETE_HELPDESK_TIMER` greifen nur solange das Ticket nicht Teil eines Belegs ist.
 Aussage:       Das System soll auf Tickets gebuchte Leistungszeiten abrechenbar machen, indem sie bei Vertragsabrechnung oder manueller Fakturierung in Belegpositionen überführt, abgerechnet und aus der Ticket-Anzeige entfernt („is part of receipt") werden.
 Ergebnis:      Leistungszeiten tauchen genau einmal in der Fakturierung auf, Doppelabrechnung ist ausgeschlossen.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: `new ReceiptItemTimerBL(dedicatedSaveSession).RemoveTimers(invoice, currentUser)` - Begründung: durchgesetzte Transaktionslogik Fakturierung↔Zeitverknüpfung
  - [KONTEXT]  CentronRights.md Nr. 8 und 9 - Begründung: fachliche Regel: kein Verschieben/Löschen abgerechneter Zeiten
 Prüfidee:      Ticket-Zeit in Rechnung übernehmen; Verschieben danach verweigert; Storno der Rechnung löst Zeitverknüpfung wieder.
 Tracelinks:    SyRS-011, SyRS-017
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - MSP-abrechenbares Geschäft
 Status:        belegt
 ---
 ID:            StRS-008
 Titel:         Forderungsmanagement: OPOS-Liste, Mahnwesen, Kundenlimit
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Buchhaltung, Vertrieb
 Vorbedingung:  Rechnungen offen, Fälligkeiten konfiguriert
 Fakt:          Tabelle `Mahnlauf`; Klasse `DunningRunBL` mit `GetDunningRuns`, `GetPreviewForDunningRun`, `ExecuteDunningRun`, `ResetDunningRun`; enum `DunningLevel` bis `Level3`; Validierung: Rechnungen müssen zum gleichen Kunden gehören, bereits fällig sein, max. Mahnstufe 3; `OposRunBL` generiert OPOS-Listen; Recht `IGNORE_DUNNING_BLOCKING_FOR_RECEIPTS` (20400085) und Recht `Controlling.Finances.Dunning` (10971); `SHOW_CUSTOMER_OPOS` (20400025); `EDIT_LIMIT_CUSTOMER` (2040004).
 Aussage:       Das System soll offene Posten je Kunde sammeln (OPOS), Mahnstufen bis Stufe 3 führen, Mahnläufe mit Vorschau, Versand (Druck/Mail) und Reset ermöglichen, und durch Mahnwesen gesperrte Kunden für neue Anlagen/Belege sperren, sofern kein Ausnahmerecht greift.
 Ergebnis:      Überfällige Forderungen werden gestaffelt angemahnt; Sperrung wirkt auf Vertriebsprozesse.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs: `invoicesInDunningLevel3`, Kundenidentität, Fälligkeitsprüfungen - Begründung: durchgesetzte Mahnvalidierung
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Mahnlauf]` - Begründung: Persistenz der Mahnläufe
  - [SEKUNDÄR] UserRightsConst.cs: IDs 20400085, 10971, 20400025 - Begründung: vergebare Rechte
 Prüfidee:      Mahnlauf über fällige Rechnungen zweier fremder Kunden wird abgelehnt; Mahnstufe 4 nicht möglich.
 Tracelinks:    SyRS-014, SyRS-015, SwRS-020
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - kaufmännisch unverzichtbar
 Status:        belegt
 ---
 ID:            StRS-009
 Titel:         Materialwirtschaft: Artikel, Einkauf, Lager, Seriennummern, Inventur
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Einkauf, Lager, Vertrieb
 Vorbedingung:  Warengruppen/Lagerorte konfiguriert
 Fakt:          Tabellen `ARTIK`, `Artikel*`, `ArtikelBestand`, `Barcode`, `SeriennummerToPosition`, `ArtikStkListe`, `NebenlagerArtikel`, `Lagerort`, `Lagerplatz`, `Warehouses`; BL `Warehousing/ArticleBL.cs`, `BarcodeBL.cs`, `BarcodeHistoryBL.cs`, `StockManagement`, `InventoryManagement`, `Commissions`; Rechte `BOOK_ARTICLE_STOCK_INTO_NEGATIVE` (20400011), Inventur-Rechte 20400040-48, Seriennummer-Rechte 20400027/28/32-35; Bestelltabellen `BestKopf2/BestPos2`, `WareKopf/WarePos` (Wareneingang), `KalkKopf/KalkPos` (WE-Kalkulation).
 Aussage:       Das System soll Artikelstamm mit Preisen/Einheiten/Stücklisten führen, Bestellung→Wareneingang→WE-Kalkulation abbilden, Lagerbewegungen (Zu-/Abbuchung, Umbuchung, Nebenlager) mit optionaler Negativbuchung durchführen, Seriennummern über den gesamten Lebenszyklus verfolgen und Inventuren mit Zählgruppen unterstützen.
 Ergebnis:      Vollständige Warenwirtschaft von Beschaffung über Zählpflicht bis Abverkauf.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ARTIK]`, `[dbo].[ArtikelBestand]`, `[dbo].[Barcode]`, `[dbo].[SeriennummerToPosition]`, `[dbo].[BestKopf2]`, `[dbo].[WareKopf]`, `[dbo].[KalkKopf]` - Begründung: persistentes Warenwirtschaftsmodell
  - [PRIMÄR]   UserRightsConst. `Purchase.StockList`/`Inventory`: Lager-, Inventur-, SN-Rechte als durchgesetzte Konstanten
  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing (Verzeichnisliste mit ArticleBL, BarcodeBL, InventoryManagement) - Begründung: Modulzuordnung
 Prüfidee:      Wareneingang mit SN buchen; SN bei Lieferschein ausbuchen; Inventur abschließen → Bestandskorrektur.
 Tracelinks:    SyRS-019, SyRS-020, SyRS-021, SwRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Standard-ERP-Pflichtfunktion
 Status:        belegt
 ---
 ID:            StRS-010
 Titel:         IT-Asset-Dokumentation beim Kunden (Stammblätter/Anlagen)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb, Techniker, MSP-Vertragsmanager
 Vorbedingung:  Kunde vorhanden
 Fakt:          Klassen `AssetBL`, `CustomerAssetBL`, `CustomerAssetExtendedBL`, `AssetLockBL`, `MasterDataListBL` unter `Sales/CustomerAssets`; `GeraeteKopf/GeraetePos`-Tabellen; Fehler-Texte wie „Stammblatt ist einem aktiven Vertrag zugeordnet." (`DependencyCheckFailed`); Serialnumber-Historie (`MasterDataListBL`: „Writes the Stammblatt history entry"); Recht `CHANGE_MAIN_DEVICE_SERIAL_NUMBER` (20800164); Rechtegruppe `CUSTOM_DEVICES`, `LICENSE_MANAGEMENT`.
 Aussage:       Das System soll pro Kunde Anlagen/Stammblätter (Geräte mit Artikelpositionen) führen, die mit Historie, Sperrlogik und Vertragszugehörigkeit dokumentiert sind, und das Ändern der Hauptgeräte-Seriennummer als eigenes Recht erlauben.
 Ergebnis:      Kundengeräte sind mit ihrem Lebenszyklus nachverfolgt; Verträge referenzieren die aktive Anlage.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs: Serialnumber-Änderung mit Historienschreibung, Vertragszugehörigkeit als Prüfung - Begründung: durchgesetzte Anlagenlogik
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[GeraeteKopf]`, `[dbo].[GeraetePos]`, `[dbo].[VertragGeraete]` - Begründung: persistentes Anlagenmodell
  - [SEKUNDÄR] UserRightsConst.cs IDs 20800164, 20800017-20800019 - Begründung: eigenständiges Recht
 Prüfidee:      SN-Wechsel am Stammblatt erzeugt Historieneintrag; Entfernen eines Stammblatts mit aktivem Vertrag wird abgelehnt.
 Tracelinks:    SyRS-024, SwRS-006
 Konsolidierung: Kandidat: SwRS-006 (doppelte Datenhaltung Stammblatt vs. AssetManagement-Geräte)
 Übernahmewürdigkeit: übernehmen - fachliches Kernkonzept, Datenhaltung zu konsolidieren
 Status:        belegt
 ---
 ID:            StRS-011
 Titel:         Kundenportal/Webshop für Endkunden der Kunden
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Endkunde (Web-Account), Kunde des Systemhauses
 Vorbedingung:  Web-Account im Adressstamm angelegt, Sonderpreise gepflegt
 Fakt:          `README.md` „WebCart … primarily intended for the customers of our customers; The available articles come from the customers 'Sonderpreise'"; Razor-Seiten `WebCartShopPage`, `WebCartCartPage`, `WebCartAdminPage`, `CustomerTicketDetailsPage`, `ReceiptsOverview`, `ReceiptDetailsOverview`, `ContractsOverview`, `CustomerPortalPublicDocumentsPage`; Tabelle `AddressContactPersonWebAccountRequests`.
 Aussage:       Das System soll Endkunden (Kunden der Kunden) einen Web-Login im Kundenportal bieten, über den sie Shopartikel aus den Sonderpreisen des Kunden einsehen/bestellen und eigene Belege, Verträge, Tickets und freigegebene Dokumente einsehen können.
 Ergebnis:      Endkunde bedient sich ohne Telefon; anfallende Bestellungen landen als Aufträge im ERP.
 Belege:
  - [KONTEXT]  README.md (Absatz WebCart) - Begründung: bestätigt fachliche Zielsetzung
  - [SEKUNDÄR] src/nexus/CentronNexus/WebCart/WebCartShopPage.razor, WebCartCartPage.razor, ReceiptsOverview.razor, ContractsOverview.razor - Begründung: umgesetzte Portaloberflächen
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[AddressContactPersonWebAccountRequests]` - Begründung: Web-Account als Datenentität
 Prüfidee:      Web-Account sieht im Shop nur Artikel aus den für seinen Kunden gepflegten Sonderpreisen.
 Tracelinks:    SyRS-031, SwRS-016
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - strategisches Wachstumsgebiet
 Status:        belegt
 ---
 ID:            StRS-012
 Titel:         Datenschutz (DSGVO) und Mandantenfähigkeit
 Ebene:         StRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Sicherheit (Vertraulichkeit)
 Akteur:        Datenschutzbeauftragter, Administration, Mandant
 Vorbedingung:  Modul lizenziert
 Fakt:          Rechtegruppe `UserRightsConst.DsgvoModule` mit `ACCESS_DSGVO_MODULE`, `DSGVO_DELETE_CONTACT`, `ACCESS_CLEANUP_DATABASE`; Tabelle `Mandant`.
 Aussage:       Das System soll ein mandantenfähiges Datenmodell und ein DSGVO-Modul besitzen, mit dem Ansprechpartner rechtskonform gelöscht und die Datenbank periodisch bereinigt werden können, jeweils hinter expliziten Rechten.
 Ergebnis:      Löschkonzept und Mandantentrennung sind betreibbar; kein Zugriff ohne Recht.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `DsgvoModule` (IDs 20800021-20800024) - Begründung: im Code durchgesetzte Rechte-Gruppe
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[Mandant]` - Begründung: Mandantenentität im Schema
 Prüfidee:      Ansprechpartner ohne DSGVO-Recht wird nicht gelöscht; zwei Mandanten-Datenbanken bleiben getrennt.
 Tracelinks:    SyRS-033, SwRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - rechtlich zwingend
 Status:        belegt
 ---
 ID:            StRS-013
 Titel:         Kommunikations- und Produktivitätsdienste (Mail, Kalender, To-Do, KI)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        alle Mitarbeiter
 Vorbedingung:  -
 Fakt:          BL-Verzeichnisse `Mail`, `Mailings`, `MailScanner`, `Outlook`, `Chats`, `Notifications`, `NexusNotifications`, `Calendar`, `ToDoArea`, `MyCentron`, `MyDay`, `TaskManager`, `ArtificialIntelligence`; HostedServices `SendEmailForUnreadMessagesService`, `SendMyDayNotificationsService`, `ReminderService`, `TodoService`, `TaskManagmentService`, `ExchangeSyncService`, `CallTrackingService`; Rechtegruppe `ArtificialIntelligence` (ADD_FILES, WEB_SEARCH, INTERACTIVE_MODE, MODEL_SELECTION, UNRESTRICTED_ACCESS).
 Aussage:       Das System soll Mail-Integration (inkl. Mailing-Kampagnen, Mail-Scanner, Outlook-AddIn), Team-Chats, Benachrichtigungen, Kalender/Mein-Tag-Ansicht, To-Do- und Aufgabenmanagement sowie ein rechtegesteuertes KI-Assistenzmodul bereitstellen.
 Ergebnis:      Produktivitätsfunktionen sind ins ERP eingebettet statt externer Insellösungen.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL (Verzeichnisse Mail/Mailings/Chats/Calendar/ToDoArea/ArtificialIntelligence) - Begründung: Modulzuordnung
  - [PRIMÄR]   CentronHost.cs: `SendEmailForUnreadMessagesService`, `SendMyDayNotificationsService`, `TodoService` - Begründung: durchgesetzte Hintergrundverarbeitung
  - [PRIMÄR]   UserRightsConst.cs `ArtificialIntelligence`-IDs 20800167-20800172 - Begründung: rechtegesteuerte KI-Fähigkeiten
 Prüfidee:      Ungelesene Chat-Nachricht löst Mail-Benachrichtigung aus; KI-Funktion ohne Recht `INTERACTIVE_MODE` nicht nutzbar.
 Tracelinks:    SyRS-034, SyRS-035
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - moderne Produktivitätsanforderung
 Status:        belegt
 ---
 ID:            StRS-014
 Titel:         Fertigung/Produktion mit Arbeitsplänen und Produktionsaufträgen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Fertigungsleiter, Mitarbeiter
 Vorbedingung:  Stücklisten gepflegt
 Fakt:          Tabellen `ArticleProductionStep`, `ArticleProductionOrders`, `ArticleProductionOrderStepItems`, `ArticleProductionMaterials`, `APlan*` (Arbeitspläne/-vorlagen); BL `Production/ProductionBL.cs`, `ProductionOrderBL.cs`; Nexus-Ordner `ProductionOrderManagement` (Web); Rechte `RIGHT_PPSARBEITSPLANANLEGEN` (20400038), `RIGHT_AUFTRAGPRODUZIERT` (2060030).
 Aussage:       Das System soll Fertigungsaufträge aus Stücklisten und Arbeitsplänen (Arbeitsgänge, Material, Zeitbuchung) erzeugen und steuern; ein Vertriebsauftrag kann als „produziert" markiert werden.
 Ergebnis:      Variantenfertigung und Fertigungsdokumentation sind abbildbar.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ArticleProductionOrders]`, `[dbo].[ArticleProductionOrderStepItemTimes]` - Begründung: persistenter Produktionsprozess mit Zeitbuchung
  - [PRIMÄR]   UserRightsConst.cs IDs 20400038, 2060030 - Begründung: durchgesetzte Rechte
  - [SEKUNDÄR] src/backend/Centron.BL/Production, src/nexus/CentronNexus/ProductionOrderManagement - Begründung: Backend- und Web-Modul
 Prüfidee:      Produktionsauftrag erzeugt Arbeitsgangpositionen; Zeit buchen; Auftrag erhält Status produziert.
 Tracelinks:    SyRS-023
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - für Fertigungsbetriebe erforderlich
 Status:        belegt
 ---
 ID:            StRS-015
 Titel:         Qualitäts-, Admin- und Berichtswesen inkl. Datenqualität
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Controlling, Administration
 Vorbedingung:  Stammdaten vorhanden
 Fakt:          BL-Verzeichnisse `ReportEngine`, `Reporting`, `Statistics`; `Analytics`-Rechte (`SALES_STATISTIC` 20800005 … `EMPLOYEE_STATISTIC` 20800009, `SALE_PURCHASE_ARTICLE_STATISTIC`); HostedService `DataQualityService` und `CacheUpdateService`; Rechte `REPORT_MANAGEMENT` (10550), `REPORTEDIT` (20800040); Power-BI-/Berichtsserver-Rechte `REPORTSERVER` (20800044).
 Aussage:       Das System soll statistische Auswertungen je Geschäftsfeld hinter eigenen Rechten, eine Reportverwaltung und laufende Datenqualitätsprüfung bereitstellen.
 Ergebnis:      Auswertungen sind rechtegesteuert und auf bereinigten Daten belastbar.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `DataQualityService`, `CacheUpdateService` - Begründung: durchgesetzte Qualitätsdienste
  - [PRIMÄR]   UserRightsConst.cs `Controlling.Analytics` - Begründung: eigene Rechte je Statistikart
  - [SEKUNDÄR] src/backend/Centron.BL/{ReportEngine,Reporting,Statistics} - Begründung: Modulzuordnung
 Prüfidee:      Statistik-Recht entzogen → Auswertung nicht aufrufbar; Datenqualitätslauf protokolliert Befunde.
 Tracelinks:    SyRS-034, SyRS-027
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Controlling-Erfordernis
 Status:        belegt
 ---
@@ -0,0 +1,254 @@
 # SwRS - Ergänzende Software Requirements (Modul-Breitabdeckung, Teil 2)
 # Fortsetzung von SwRS.md (IDs SwRS-029 ff.)
 ---
 ID:            SwRS-029
 Titel:         docuFORM-Integration für Formular-/Dokumentenveredelung
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Vertrieb, System
 Vorbedingung:  docuFORM-Server erreichbar
 Fakt:          Eigenes API-Projekt `Centron.Api.docuFORM` mit `DocuFormRestApiClient`, `IDocuFormApiClient`, `DocuFormRestApiConstants`, Models.
 Aussage:       Die Software soll Dokumente/Formulare über die REST-API eines docuFORM-Servers erzeugen/veredeln lassen (Client-Abstraktion vorhanden).
 Ergebnis:      Medienbruchfreie Formularverarbeitung.
 Belege:
  - [PRIMÄR]   Centron.Api.docuFORM/{DocuFormRestApiClient.cs,IDocuFormApiClient.cs} - durchgesetzte Client-Struktur
 Prüfidee:      Client-Aufruf mit Mock-Server liefert typisierte Modelle.
 Tracelinks:    SyRS-036, StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: Sonderfall - herstellerbezogene Integration, im Zielsystem konfigurierbar
 Status:        belegt
 ---
 ID:            SwRS-030
 Titel:         C-FLOW-Ticketvorlagen mit Formulas, Checklisten, Skripten und Mailtemplates
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Helpdesk-Administration
 Vorbedingung:  Lizenz C-FLOW
 Fakt:          Nexus-Modul `Management/TicketPatterns` mit `TicketPatternEditor`, Tabs für Allgemein, Properties, Kunden, Intern, Checklisten, MailTemplate, Scripts, WebForm, SelfCareFormFields; Rechtegruppe `UserRightsConst.Sales.Customer.Helpdesk.CFlow` (EDIT/CREATE/DELETE_TICKETPATTERN, CREATE_CATEGORY).
 Aussage:       Die Software soll Ticketvorlagen mit Kategorien verwalten, denen pro Tab Checklisten, Formularfelder, Mailtemplates und Skripte zugeordnet werden können; Bearbeitung ist rechtegebunden.
 Ergebnis:      Standardisierte Serviceprozesse aus einem Katalog.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `CFlow`-Block (IDs 20800050-20800054) - durchgesetzte Rechte
  - [SEKUNDÄR] src/nexus/CentronNexus/Management/TicketPatterns/*.razor - Begründung: Editorenstruktur
 Prüfidee:      Vorlage ohne Recht nicht editierbar; Checkliste in Ticket überführt.
 Tracelinks:    StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-031
 Titel:         Elektronische Unterschrift am Dokument (Nexus DocumentSigning)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Kunde, Techniker
 Vorbedingung:  Signaturfähiges Endgerät
 Fakt:          Nexus-Ordner `DocumentSigning` mit `DocumentSigningPage.razor`, `IsolatedSignaturePad.razor`; BL-Verzeichnis `Security/PdfSigningBL.cs` (9.549 Bytes).
 Aussage:       Die Software soll Unterschriften webseitig über Signature-Pad erfassen und PDF-Dokumente signieren.
 Ergebnis:      Rechtswirksame Dokumentation ohne Papier (z. B. für Lieferscheine).
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Security/PdfSigningBL.cs - durchgesetzte Signatur-BL
  - [SEKUNDÄR] src/nexus/CentronNexus/DocumentSigning/*.razor - Begründung: UI
 Prüfidee:      Signatur erzeugt signiertes PDF; Pad-Daten werden nicht im Klartext persistiert (Prüfung auf Verschlüsselung offen).
 Tracelinks:    StRS-006, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-032
 Titel:         Outlook-AddIn mit Kontextbezug (Ticket/CRM/Belege/Dokument)
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Vertrieb, Helpdesk
 Vorbedingung:  Microsoft 365
 Fakt:          Projekt `CentronNexus.OutlookAddIn` mit Ordnern `Ticket`, `CRM`, `Customer`, `Belege`, `Document`, `Manifest`, `OfficeDialog`; Blazor-Seiten (`OutlookIndexPage.razor`).
 Aussage:       Die Software soll Outlook-Mails und Termine kontextbezogen an Tickets, CRM-Vorgänge, Kunden, Belege und Dokumente in c-entron koppeln.
 Ergebnis:      Kommunikationsschnittstelle ohne Medienbruch.
 Belege:
  - [PRIMÄR]   src/nexus/CentronNexus.OutlookAddIn (Projektstruktur mit Manifest und Kontextordnern) - durchgesetzte Integration
 Prüfidee:      Mail zu Ticket zuordnen erzeugt Ticketverweis in Datenbank.
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-033
 Titel:         Mobile Datenerfassung
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Techniker, Lager
 Vorbedingung:  Mobiles Gerät
 Fakt:          BL `Mobile/MobileBL.cs` und `ItPlanner/ChecklistVirtualObjectCategoryBL.cs`; DAO-Verzeichnis `Mobile`; Checklisten-Verbindung zur Inventur/Infrastruktur.
 Aussage:       Die Software soll eine mobile Schnittstelle für Checklisten- und Infrastruktur-Datenerfassung bereitstellen.
 Ergebnis:      Offlinebaubekannte Mobile-Prozesse.
 [Hinweis: konkrete mobile Clients nicht weiter analysiert]
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/Mobile/MobileBL.cs, src/backend/Centron.DAO/Mobile - Begründung: Modul
 Prüfidee:      [HYPOTHESE] Mobile App-Schnittstelle testen (Client-Anwendung liegt nicht im Repo vor).
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        HYPOTHESE (Mobile-Client-Anwendung nicht im Repository; BL-Modul belegt)
 ---
 ID:            SwRS-034
 Titel:         WebSuite/ältere Web-Angebotsplattform
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Endkunde
 Vorbedingung:  -
 Fakt:          BL-Verzeichnis `WebSuite`, `RiverDivo` enthält `RBContractArticleRefInfo`, `RiverConnectionBL`, `RiverDivoBL`, `SimpleRiverCentronClient`; zugehörige Rechte (`RIGHT_WEBSUITE`, `RIGHT_WEBHELPDESK`, `RIGHT_WEBSHOP`, `RIGHT_WEBSUITEREISEKOSTEN*`, `ALLOW_RIVERSUITE_*`, SupRemo/DirectNow) sämtlich `[Obsolete]`.
 Aussage:       Die Software enthält eine ältere Webplattform (WebSuite/WebHelpdesk/WebShop inkl. Reisekosten) und eine RiverSuite-Konnektivität, die fachlich abgelöst wurden.
 Ergebnis:      Altintegrationen verbleiben als Daten-/Codebestand.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs: `[Obsolete]`-Markierungen auf WebSuite-/Riversuite-/SupRemo-/DirectNow-IDs - durchgesetzte Abschaltung
  - [SEKUNDÄR] src/backend/Centron.BL/WebSuite, src/backend/Centron.BL/RiverDivo - Begründung: Restcode
 Prüfidee:      Rechtevergabe bietet WebSuite nicht an.
 Tracelinks:    SyRS-001
 Konsolidierung: Kandidat: Altintegrationen (RiverSuite, SupRemo, DirectNow, WebSuite) - im Zielsystem stilllegen
 Übernahmewürdigkeit: veraltet - durch Nexus-Kundenportal und WebCart ersetzt
 Status:        belegt
 ---
 ID:            SwRS-035
 Titel:         VideoPortal mit Zuordnung und Auswertung
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb, Marketing
 Vorbedingung:  Videos bereitgestellt
 Fakt:          Rechtegruppe `VideoPortal` (ID 20800107) mit `EVALUATION` (20800108), `ASSIGNMENT` (20800113); BL-Klasse `VideoPortalAssignmentBL`.
 Aussage:       Die Software soll Videos zuordnen und deren Nutzung auswerten, jeweils rechtegesteuert.
 Ergebnis:      Kunden/Lernvideos nachverfolgbar.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `VideoPortal`-Block - durchgesetzte Rechte
  - [SEKUNDÄR] src/backend/Centron.BL/VideoPortal/VideoPortalAssignmentBL.cs - Begründung: Modul
 Prüfidee:      Auswertung nur mit Recht `EVALUATION` erreichbar.
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-036
 Titel:         Erwartete Ereignisse (ExpectedEvents)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Controlling
 Vorbedingung:  -
 Fakt:          BL-Klasse `ExpectedEventsBL.cs`; Rechte `SHOW_EXPECTEDEVENTS` (20800100) und `SHOW_EXPECTEDEVENTSREPORTING` (20800101).
 Aussage:       Die Software soll fachlich erwartete Ereignisse (z. B. erwartete Belege/Einnahmen) erfassen und auswerten; Ansicht und Reporting sind getrennt berechtigt.
 Ergebnis:      Proaktive Unternehmenssteuerung.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs IDs 20800100/20800101 - durchgesetzte Rechte
  - [SEKUNDÄR] src/backend/Centron.BL/ExpectedEvents/ExpectedEventsBL.cs - Begründung: Modul
 Prüfidee:      Reporting ohne Recht nicht aufrufbar.
 Tracelinks:    StRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-037
 Titel:         Tags, benutzerdefinierte Prozesse und CPra-Konnektor
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Administrator
 Vorbedingung:  -
 Fakt:          BL-Klassen `Tags/TagsBL.cs`, `Processes/ProcessBL.cs`, `CPra/CPraConnectorBL.cs`, `CPraConfigurationSettingsBL.cs`; Außerdem `Customizations`-Verzeichnis.
 Aussage:       Die Software soll Tags auf Objekten, Kundenprozesse (Workflows) und eine CPra-Integrationsanbindung konfigurierbar bereitstellen.
 Ergebnis:      Erweiterbarkeit ohne Customcode.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/{Tags/TagsBL.cs,Processes/ProcessBL.cs,CPra/CPraConnectorBL.cs} - durchgesetzte Modulinkrementierung
 Prüfidee:      Tag an Kunden anhängen/entfernen; Prozess-Definition ausführen.
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-038
 Titel:         Vouchermanagement (Gutscheine)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb
 Vorbedingung:  -
 Fakt:          BL-Klasse `VoucherManagement/VoucherManagementBL.cs`; Recht `RIGHT_GUTSCHEINVERWALTUNG` (20400319) ist `[Obsolete]`; Wertgutschrift-Recht `RIGHT_WERTGUTSCHRIFTANLEGEN` (20400292) aktiv.
 Aussage:       Die Software soll Gutscheine verwalten; das klassische Gutscheinmodul ist als veraltet markiert, Wertgutschriften bleiben aktiv verfügbar.
 Ergebnis:      Übergang vom Gutschein auf die Wertgutschrift.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs: `RIGHT_GUTSCHEINVERWALTUNG [Obsolete]` vs. `RIGHT_WERTGUTSCHRIFTANLEGEN` aktiv - durchgesetzte Migration der Rechte
  - [SEKUNDÄR] src/backend/Centron.BL/VoucherManagement/VoucherManagementBL.cs - Begründung: Modul
 Prüfidee:      Wertgutschrift anlegen erfordert Recht 20400292; Altmodul nicht mehr im Ribbon.
 [Hinweis: Funktionsumfang VoucherManagementBL nicht vollständig analysiert]
 Tracelinks:    StRS-004
 Konsolidierung: Kandidat: Gutschein vs. Wertgutschrift - in Zielsystem zusammenführen
 Übernahmewürdigkeit: übernehmen - Wertgutschrift; klassische Gutscheinfunktion prüfen
 Status:        HYPOTHESE (genauer Funktionsumfang des Altmoduls nicht vollständig gelesen)
 ---
 ID:            SwRS-039
 Titel:         SelfCare und WebRequest
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Kunde/Mitarbeiter
 Vorbedingung:  SelfCare freigeschaltet
 Fakt:          BL-Klassen `SelfCare/SelfCareBL.cs` und `SelfCare/WebRequestPageBL.cs`; Self-Care-Formularfelder in C-FLOW Vorlagen (siehe SwRS-030).
 Aussage:       Die Software soll Self-Service-Formulare und öffentliche Webrequest-Seiten in Ticketvorlagen einbetten.
 Ergebnis:      Kundenanfragen landen als strukturierte Tickets.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/SelfCare/{SelfCareBL.cs,WebRequestPageBL.cs} - durchgesetzte Klassen
  - [SEKUNDÄR] src/nexus/CentronNexus/Management/TicketPatterns/Components/SelfCareFormField*.razor - Begründung: Formulargenerator
 Prüfidee:      Webrequest-Formular erzeugt Ticket.
 Tracelinks:    StRS-011, SwRS-030
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-040
 Titel:         KI-Promptkategorien und -Einstellungen
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Administrator
 Vorbedingung:  KI-Modul
 Fakt:          Tabellen `ArtificialIntelligencePromptCategory`, `ArtificialIntelligencePromptSettings`; Rechtegruppe siehe SyRS-032.
 Aussage:       Die Software soll KI-Prompts kategorisiert und je Instanz konfigurierbar abspeichern.
 Ergebnis:      Steuerbare Prompt-Bibliothek.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `CREATE TABLE [dbo].[ArtificialIntelligencePromptCategory]`, `[ArtificialIntelligencePromptSettings]` - durchgesetzte Persistenz
 Prüfidee:      Prompt-Setting ohne Zuordnung zu Kategorie (FK, falls vorhanden).
 Tracelinks:    SyRS-032, StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
@@ -0,0 +1,588 @@
 # SwRS - Software Requirements Specification
 # c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
 ---
 ID:            SwRS-001
 Titel:         Datenzugriffsschicht über NHibernate mit generischem DAO
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Komponente Centron.DAO
 Vorbedingung:  DB-Verbindung konfiguriert
 Fakt:          `Centron.DAO` enthält `GenericDAO.cs` (25.462 Bytes), `DAOFactory.cs` (11.714 Bytes, `SetConnection`), `DAOSession.cs`, `AdvancedSession.cs`, NHibernate-Konfiguration (`NHibernateConfiguration`), `Repositories`, `NamedQueries` und `CustomDAOs`; Session-Transaktionsmethoden `StartTransaction`, `CommitTransaction`, `RollbackTransaction` sowie `WithTransaction` werden von BLs genutzt (vgl. `ReceiptInvoiceBL`).
 Aussage:       Die Software soll den gesamten Datenbankzugriff über eine NHibernate-basierte DAO-Schicht mit zentraler Verbindungsverwaltung (`DAOFactory`), generischen Repositories und expliziten Transaktionsgrenzen in der BL ausführen.
 Ergebnis:      Einheitlicher Zugriff, testbare Transaktionen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.DAO/{GenericDAO.cs,DAOFactory.cs,DAOSession.cs} - durchgesetzte Architekturbasis
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: `new DAOSession().WithTransaction(() => ...)` - durchgesetzte Transaktionsklammer
 Prüfidee:      DAOFactory liefert verbundene Session; Rollback macht alle Schritte rückgängig.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: Workaround - NHibernate-Schicht ist technisch zu ersetzen (z. B. EF Core), fachlich neutral
 Status:        belegt
 ---
 ID:            SwRS-002
 Titel:         Primärschlüsselkonzept I3D statt Id
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Persistenzschicht
 Vorbedingung:  -
 Fakt:          `src/backend/Centron.Entities/PersistedEntity.cs` und `PersistedLongEntity.cs`; nahezu sämtliche Schematabellen führen Spalte `I3D` als Primärschlüssel (RechKopf, Kunden, ARTIK, hlpdsk_requests ...); BL-Methoden arbeiten mit `...I3D`-Parametern (`invoiceI3D`, `customerI3D`, `appUserI3D`).
 Aussage:       Die Software soll alle persistierten Entitäten mit dem historischen Primärschlüsselfeld `I3D` führen und durchgängig referenzieren.
 Ergebnis:      Konsistente Referenzierung in Legacy- und Neumodule.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql (I3D-Spalten in allen Tabellendefinitionen) - durchgesetzte Konstante
  - [SEKUNDÄR] src/backend/Centron.Entities/PersistedLongEntity.cs - Begründung: Basisklasse mit Schlüsselproperty
 Prüfidee:      Join zwischen `hlpdsk_requests` und `hlpdsk_timer` über `I3D`-FK.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Umbenennung in Zielsystem nur mit Migrationsstrategie
 Status:        belegt
 ---
 ID:            SwRS-003
 Titel:         Beleg-Datenmodell Kopf/Position je Belegart inkl. Versionstabellen
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Persistenzschicht
 Vorbedingung:  -
 Fakt:          Pro Belegart eigenes Kopf-/Positionstabellenpaar (AngKopf/AngPos, AufKopf/AufPos, LiefKopf/LiefPos, AbholKopf/AbholPos, RechKopf/RechPos, GutKopf/GutPos, AnfrKopf/AnfrPos, BestKopf2/BestPos2, WareKopf/WarePos, KalkKopf/KalkPos, LiGutKopf/LiGutPos, VertragKopf/VertragPos) sowie Versionspendants.
 Aussage:       Die Software soll Belege als Kopf-Positionen-Strukturen je Belegart und je Version speichern; der Belegentyp bestimmt die Tabelle.
 Ergebnis:      Typspezifische Erweiterbarkeit, vollständige Historisierung.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql CREATE TABLE-Liste (AngKopf, RechKopf, RechKopfVersions u. a.) - durchgesetztes physisches Modell
 Prüfidee:      Rechnung speichern erzeugt Kopf + n Positionen und (bei Bearbeitung) Versionssatz.
 Tracelinks:    SyRS-012, StRS-004
 Konsolidierung: Kandidat: neun parallele Kopf-/Pos-Tabellenpaare für denselben Beleg-Kern; im Zielsystem generische Belegtabelle mit Typ-Diskriminator prüfen
 Übernahmewürdigkeit: übernehmen - Datenmigration muss Bestand erhalten
 Status:        belegt
 ---
 ID:            SwRS-004
 Titel:         Parallele Datenmodelle: Legacy-Tabellen (Kunden/ARTIK) vs. Account-Modell (Account*)
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Persistenzschicht
 Vorbedingung:  -
 Fakt:          Schema enthält sowohl Legacy-Tabellen (`Kunden`, `Kreditor`, `ARTIK`, `WAREN`, `Anschrif`, `Personen`) als auch neuere Account-Tabellen (`Accounts`, `AccountCustomers`, `AccountSuppliers`, `AccountAddresses`, `AccountAddressContacts`, `AccountTypes`, `AccountRelationships`, `AccountBusinessLine`); BL `Accounts/AccountBL.cs` und Fabriken `CustomerToBranchBL`, `SupplierToBranchBL` verwenden den neuen Kontext, `AddressContactPersonWebAccountRequests` verweist auf Account-Kontext.
 Aussage:       Die Software soll Geschäftspartner (Kunde/Lieferant) in einem übergreifenden Account-Modell führen, das die früheren Kunden-/Lieferanten-Modelle ablöst; beide Bestände koexistieren derzeit.
 Ergebnis:      Vereinheitlichung, derzeit noch mit Altbestand.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: Koexistenz von `[dbo].[Kunden]`, `[dbo].[Kreditor]` und `[dbo].[Accounts]`, `[dbo].[AccountCustomers]`, `[dbo].[AccountSuppliers]` - durchgesetzte Doppelhaltung
  - [SEKUNDÄR] src/backend/Centron.BL/Accounts/*BL.cs - Begründung: BL arbeitet auf Account-Modell
 Prüfidee:      AccountEntity in `Accounts` wird über `AccountCustomers` als Kunde geführt.
 Tracelinks:    StRS-002
 Konsolidierung: Kandidat: zwei Datenhaltungen für Geschäftspartner (Kunden/Kreditor vs. Accounts); im Zielsystem zusammenzuführen
 Übernahmewürdigkeit: Workaround - Doppelhaltung historisch gewachsen
 Status:        belegt
 ---
 ID:            SwRS-005
 Titel:         Mandantenentität
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        System
 Vorbedingung:  -
 Fakt:          Tabelle `[dbo].[Mandant]`; konfigurierte Mandantenbehandlung in mehreren Account-Zuordnungstabellen (`CustomerToBranches`, `LieferantenToFiliale`).
 Aussage:       Die Software soll Mandanten und Filialen als durchgängige Datenbankentitäten führen und Stammdaten je Mandant/Filiale zuordnen.
 Ergebnis:      Mandantenfähigkeit im Datenbankschema verankert.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `[dbo].[Mandant]`, `[dbo].[CustomerToBranches]`, `[dbo].[LieferantenToFiliale]` - durchgesetztes Modell
 Prüfidee:      Kunden-Filialzuordnung bleibt mandantentrennbar.
 Tracelinks:    StRS-012, StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-006
 Titel:         Kundenanlagen: Stammblatt (GeraeteKopf/Pos) versus AssetManagement-Geräte
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Persistenzschicht
 Vorbedingung:  -
 Fakt:          Schema enthält `[dbo].[GeraeteKopf]`, `[GeraetePos]`, `[VertragGeraete]` für Kundenanlagen und zugleich ca. 180 Tabellen `[dbo].[AssetManagement...]` (Devices, Printer, Monitors, NetworkAdapter, OS, Patches, Checks, Diagrams, ...); BL `Sales/CustomerAssets/*Asset*BL` und `Devices`/`RiverDivo`-Modul greifen unterschiedlich zu.
 Aussage:       Die Software führt „Stammblätter" (druckerbezogene Anlagen) separat von sonstiger IT-Infrastruktur im AssetManagement-Konzept; dieselbe fachliche Aggregation „Gerät beim Kunden" ist zweifach modelliert.
 Ergebnis:      Doppelhaltung mit unterschiedlichen Detailgraden.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: `GeraeteKopf` vs. `AssetManagementDevices` - durchgesetzte Doppelhaltung
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs; MasterDataListBL mit Stammblatt-Terminologie - Begründung: fachliche Nutzung
  - [KONTEXT]  Prompt-Vorgabe (kalibriertes Beispiel Drucker/Stammblätter vs. Assets) - Begründung: fachliche Lesart
 Prüfidee:      Drucker bei Kunde X liegt entweder in GeraeteKopf oder AssetManagement vor - nicht konsolidiert.
 Tracelinks:    StRS-010, SyRS-024
 Konsolidierung: Kandidat: zwei Datenmodelle für „Gerät beim Kunden" - im Zielsystem zu einem Asset-Konzept zusammenführen
 Übernahmewürdigkeit: übernehmen - mit Datenkonsolidierung
 Status:        belegt
 ---
 ID:            SwRS-007
 Titel:         Rechtemodell: numerische Konstanten, Gruppen-ID + Unterrechte, [Obsolete]-Markierungen
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Komponente Rechteverwaltung
 Vorbedingung:  -
 Fakt:          `UserRightsConst` verwendet Konstanten-Ganzzahlen; Gruppen besitzen `ID` und Unterrechte (z. B. `Sales.Customer.CustomerCommon.Invoice.ID = 40003`, Rechte `CREATE_NEW_INVOICE = 20400195`); Kommentar „NEW .NET MODULE RIGHTS START AT 20800000"; zahlreiche `[Obsolete]`-Konstanten (Kassenbuch, Barrechnung, WebSuite, Riversuite, Projectverwaltung ...).
 Aussage:       Die Software soll Rechte über numerische Gruppen- und Unterrechts-IDs strukturieren; die ID-Blöcke 1xxxx/20xxxx/206xxxx gehören Altrechten, ab 20800000 liegt die neue .NET-Modulwelt. Abgelöste Rechte bleiben kompatibel in der Datenbank.
 Ergebnis:      Aufwärtskompatible Rechtematrix mit dokumentierter Verfallskennzeichnung.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.WebServices.Core/EntitiesWrongPlace/Administration/Rights/UserRightsConst.cs (Header-Kommentar, `[Obsolete]`) - durchgesetzte Platzierung
  - [KONTEXT]  CentronRights.md - Begründung: Semantik der Altrechte
 Prüfidee:      Zurückgelieferte Rechte entsprechen den Konstanten; obsolet markierte IDs werden nicht mehr gescannt.
 Tracelinks:    SyRS-009, StRS-002
 Konsolidierung: Kandidat: [Obsolete]-Rechte-Altbestand (Kassenbuch, RMA-SupRemo, Riversuite) - im Zielsystem Ausmusterung
 Übernahmewürdigkeit: übernehmen - Kompatibilität; veraltete IDs gesondert ausmisten
 Status:        belegt
 ---
 ID:            SwRS-008
 Titel:         Ergebnisrückgabemuster `Result` / `ResultStatus` samt DefaultMessageCodes
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Komponente BL
 Vorbedingung:  -
 Fakt:          BL-Methoden liefern `Result` oder `Result<T>` mit `ResultStatus.Success|Warning|Error`, statischen Fabriken `AsError(message[, code])`, `AsSuccess(data)`; Codes wie `DefaultMessageCodes.RightCheckFailed`, `DependencyCheckFailed`, `CouldNotFindData`, `BadRequest`.
 Aussage:       Die Software soll Geschäftslogik deterministisch mit Result-Objekten antworten statt Ausnahmefehlern (außer Argument/Guard-Fehler); Fehlercodes sollen maschinell auswertbar sein.
 Ergebnis:      Einheitliche Fehlerbehandlung über BL-Grenzen.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: ausschließlich `Result<ReceiptInvoice>.AsError(...)`-Rückgaben (durchgesetzte Stelle)
  - [SEKUNDÄR] MasterDataListBL mit `DefaultMessageCodes.*` - Begründung: Kodex
 Prüfidee:      Simuliere Rechtefehler → Status Error, MessageCode RightCheckFailed.
 Tracelinks:    SyRS-003, SyRS-018
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - robuste BL-API
 Status:        belegt
 ---
 ID:            SwRS-009
 Titel:         Zentrale Beleglogik in `ReceiptBL` (God-Class) mit belegtypspezifischen Erweiterungen
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Komponente Vertriebslogik
 Vorbedingung:  -
 Fakt:          `ReceiptBL.cs` ist 623.866 Bytes groß, `ReceiptItemBL.cs` 230.597 Bytes, `ReceiptLogBL.cs` 75.952 Bytes; `IReceiptSpecificLogic` definiert Schnittstellen für Belegtyp-spezifische Abweichungen; `ReceiptInvoiceBL` delegiert zentrale Operationen (`GetReceiptByI3D`, `CreateNewVersion`, `SaveReceipt`, `GetReceiptForwardedInto`) an `ReceiptBL`.
 Aussage:       Die Software soll alle Belegoperationen über die zentrale Klasse `ReceiptBL` kanalisieren; belegtypspezifische Abweichungen laufen aus Sicht der Architektur über `IReceiptSpecificLogic`.
 Ergebnis:      Einheitliche Transaktions- und Versionssemantik, zentrale Komplexität.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (Größe/Aufgaben) und verwendung in ReceiptInvoiceBL - durchgesetzte Zentralisierung
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/Receipts/IReceiptSpecificLogic.cs - Begründung: Erweiterungspunkt
 Prüfidee:      Jede Belegart-Implementierung implementiert das Interface; paralleler Aufruf in ReceiptBL funktioniert bei zwei Typen.
 Tracelinks:    SyRS-013, StRS-004
 Konsolidierung: Kandidat: God-Class - im Zielsystem auf Aggregate je Belegart verteilen
 Übernahmewürdigkeit: Workaround - historisch gewachsene Alleinstellung sammelnder Fachlogik
 Status:        belegt
 ---
 ID:            SwRS-010
 Titel:         CreateNewVersion vor jeder mutierenden Belegoperation [Abrechnung]
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Komponente Beleglogik
 Vorbedingung:  -
 Fakt:          `ReceiptBL.CreateNewVersion<ReceiptInvoice>(int i3d, ..., CreateNewVersionData { IgnoreCallbacks = true })` wird in `ReceiptInvoiceBL.CancelInvoice` genutzt; `CreateNewVersionData` erlaubt das Unterdrücken von Callbacks; Versionierung erzeugt komplett neue Kopf-/Positionssätze.
 Aussage:       Die Software soll vor Storno und Nachbearbeitung eines abgeschlossenen Belegs eine neue Versionsspur erzeugen; interne Folgeverarbeitungen können Callbacks unterdrücken.
 Ergebnis:      Nachvollziehbarkeit über Revisionen.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: Aufruf `CreateNewVersion<ReceiptInvoice>(... IgnoreCallbacks = true)` - durchgesetzte Stelle
  - [SEKUNDÄR] SSMS `[RechKopfVersions]/[RechPosVersions]` - Begründung: persistierte Versionssätze
 Prüfidee:      Nach Storno existiert Version n+1 mit State Canceled; alte Version bleibt unverändert.
 Tracelinks:    SyRS-010, SyRS-012, StRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-011
 Titel:         Beleg-Protokollbuch: ReceiptLog samt Ereignistypen
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Komponente Audit
 Vorbedingung:  -
 Fakt:          `ReceiptLogBL` (75.952 Bytes); Aufrufe mit `CentronObjectKindNumeric.InvoiceClass` und Enum `ReceiptLogKind.FixedState`; `ReceiptInvoiceBL.CancelInvoice` verwendet `CreateInvoiceCancelledEntry(newInvoiceVersion, currentUser)`; Ereignis beschreibt Mitarbeiter und Zeitstempel.
 Aussage:       Die Software soll jede relevante Belegenaktion (Festgeschrieben, Storniert u. a.) als ReceiptLog-Eintrag mit Art, Benutzer, Zeit und Beschreibung protokollieren.
 Ergebnis:      Revisionspfad je Beleg.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.FixInvoice → `logBL.CreateEntry(... ReceiptLogKind.FixedState ...)`; `CancelInvoice` → `CreateInvoiceCancelledEntry` - durchgesetzte Stelle
  - [SEKUNDÄR] UserRightsConst.cs `SHOW_AUDIT` (20800097) - Begründung: Sichtbarkeit des Audit-Logs
 Prüfidee:      Festschreibung erzeugt Logeintrag mit Employee und Datum.
 Tracelinks:    SyRS-010, SyRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-012
 Titel:         Festschreibung als direktes SQL-Update (ORM-Bypass)
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Komponente Beleglogik
 Vorbedingung:  -
 Fakt:          `ReceiptInvoiceBL.FixInvoice` schreibt über `Session.Advanced.RawSqlAccess.ExecuteNonQueryTransactionSave` mit `UPDATE RechKopf SET IsFixed = 1` und expliziter Transaktion `StartTransaction`/`Commit`/`RollbackTransaction`.
 Aussage:       Die Software soll die Festschreibung eines Belegs transaktional als direktes SQL-Statement durchführen, um unabhängige Audit-Spur schreiben zu können.
 Ergebnis:      Atomare Festschreibung mit Logging.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.FixInvoice (SQL-Text, Transaktionsklammer) - durchsetzende Stelle
 Prüfidee:      Update schlägt fehl → Rollback macht auch Logeintrag rückgängig (Integrationstest).
 Tracelinks:    SyRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: Workaround - ORM-Bypass aus Altbestand; im Zielsystem einheitlich über Repository
 Status:        belegt
 ---
 ID:            SwRS-013
 Titel:         Lagerecht: Negativbuchung als eigenes Recht [Berechtigung]
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Lagerverwaltung
 Vorbedingung:  Artikel mit Bestand
 Fakt:          Recht `BOOK_ARTICLE_STOCK_INTO_NEGATIVE` (20400011) bzw. `RIGHT_NEGATIVBUCHUNG` (20400011); Recht `TRANSFER_STOCK` (20400060), `BOOK_TO_STOCK` (20400105), `BOOK_FROM_STOCK` (20400106); Typ `SecondStockArticleBL` (Nebenlager).
 Aussage:       Die Software soll Zu-, Ab- und Umbuchungen einzeln berechtigen; Buchungen ins Negative sollen nur mit explizitem Recht erlaubt sein; Nebenlager werden gesondert geführt.
 Ergebnis:      Bestandspflege unter Kontrolle.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `Purchase.StockList`-Block - durchgesetzte Rechte-Matrix
  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs - Begründung: Nebenlagerlogik
 Prüfidee:      Abbuchung über Bestand ohne Recht wird blockiert.
 Tracelinks:    StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-014
 Titel:         WPF-Desktop-Client mit MVVM und Modul-Registrierung
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Desktop-Nutzer
 Vorbedingung:  Windows-Client
 Fakt:          `src/centron/Centron.WPF.UI/App.xaml.cs` (32.927 Bytes), `FrontWindowViewModel.cs`, Verzeichnisse `ViewModels`, `Dialogs`, `Messages`, `Modules` mit `CentronModule.cs`, `ModuleRegistration.cs`, `ModuleRightsExpressionParser.cs`, `Localization`, `Behaviors`; XAML-Oberflächen (1233 XAML-Dateien laut dir-Zählung).
 Aussage:       Die Software soll den Desktop-Client als MVVM-Aufbau mit Ribbon-Navigation, modul registrierten Views und rechtegesteuerten Modul-Expressionen betreiben.
 Ergebnis:      Ausbaubare, rechtekonforme Modulstruktur.
 Belege:
  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/{CentronModule,ModuleRegistration,ModuleRightsExpressionParser}.cs - durchgesetzte Modul-Registrierung
  - [SEKUNDÄR] FrontWindowViewModel.cs - Begründung: Shell-ViewModel
 Prüfidee:      Modul-ID mit fehlendem Recht wird im Ribbon ausgeblendet.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: veraltet - Ziel ist Webclient; Funktionsumfang wird übernommen, Technologie nicht
 Status:        belegt
 ---
 ID:            SwRS-015
 Titel:         OpenTrans-Gateway für strukturierte XML-Dokumente
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Komponente Gateway
 Vorbedingung:  XML-Dokument vorliegend
 Fakt:          Projekt `src/backend/Centron.Gateway` (OpenTrans); `ReceiptInvoiceBL.TryDeserializeOpenTransInvoice` nutzt `XmlSerializer(typeof(INVOICE))` aus `Centron.Gateway.OpenTrans`.
 Aussage:       Die Software soll OpenTrans/XML-Dokumente (z. B. INVOICE) über das Gateway typisiert deserialisieren; invalides XML führt zu `Result.FromException`.
 Ergebnis:      Robuster strukturierter Datengegenverkehr.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.TryDeserializeOpenTransInvoice - durchgesetzte Stelle
  - [SEKUNDÄR] src/backend/Centron.Gateway - Begründung: Integrationsprojekt
 Prüfidee:      Fehlerhafte XML liefert Result Status Error mit Exception-Detail.
 Tracelinks:    SyRS-025, SyRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-016
 Titel:         Nexus Web-Account-Registrierung als Datenbankanforderung
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        System
 Vorbedingung:  Kunde vorhanden
 Fakt:          Tabelle `AddressContactPersonWebAccountRequests`; WebAccount-Recht `WEBACCOUNT_MANAGEMENT` (20800162).
 Aussage:       Die Software soll Web-Accounts an Ansprechpartner-Adressen koppeln und deren Anlage über ein Recht steuerbar machen.
 Ergebnis:      Nachvollziehbare Selbstregistrierung.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `[dbo].[AddressContactPersonWebAccountRequests]` - durchgesetzte Persistenz
  - [SEKUNDÄR] UserRightsConst.cs `WEBACCOUNT_MANAGEMENT` - Begründung: Verwaltungsrecht
 Prüfidee:      Anfrage ohne zugehörige Ansprechperson nicht anlegbar (FK-Test).
 Tracelinks:    SyRS-031, StRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-017
 Titel:         Helpdesk-Datenmodell mit Bearbeiterzuordnung
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Persistenzschicht
 Vorbedingung:  Tickettyp/-kategorie definiert
 Fakt:          `hlpdsk_requests` mit `hlpdsk_request_bearbeiter` (Mehrfachbearbeiter), `hlpdsk_history`, `hlpdsk_typen`, `hlpdsk_kategorien`, `hlpdsk_prioritaeten`, `hlpdsk_status`, `hlpdsk_timer`.
 Aussage:       Die Software soll Tickets mit Kategorien zweier Ebenen, Prioritäten, Status und Mehrfachbearbeiterzuordnung persistieren; Änderungen in einer History-Tabelle nachhalten.
 Ergebnis:      Revisionssicheres Ticketmodell.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `hlpdsk_*`-CREATE TABLE-Liste - durchgesetztes Modell
 Prüfidee:      Ticket mit zwei Bearbeitern in Zwischentabelle; Statuswechsel erzeugt History-Zeile.
 Tracelinks:    StRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-018
 Titel:         Helpdesk-Fingerprint-Integritätsdienst
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Integrität)
 Akteur:        System
 Vorbedingung:  -
 Fakt:          HostedService `ValidateHelpdeskFingerprintService` (registriert in CentronHost).
 Aussage:       Die Software soll periodisch Fingerprints der Helpdesk-Datensätze validieren, um Manipulation zu erkennen.
 Ergebnis:      Manipulationsaufdeckung laufend.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `f.AddHostedService<ValidateHelpdeskFingerprintService>()` - durchgesetzte Registrierung
 Prüfidee:      Geänderter Ticket-Primärdatensatz mit unverändertem Hash → Dienst meldet Abweichung.
 Tracelinks:    StRS-006, SyRS-030
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - integritätssicher
 Status:        belegt
 ---
 ID:            SwRS-019
 Titel:         Internationalisierung über SharedResource
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        UI
 Vorbedingung:  -
 Fakt:          `SharedResource.resx` (7.447 Bytes, de) und `SharedResource.en-US.resx` (7.258 Bytes) sowie Designer-Dateien im Projekt `CentronNexus`; ResXManager config im Root.
 Aussage:       Die Software soll Texte im Web-Zweig über .resx-Ressourcen verwalten (de/en-US), verwaltbar über ResXManager.
 Ergebnis:      Mehrsprachige Oberflächen ohne Codeforks.
 Belege:
  - [PRIMÄR]   src/nexus/CentronNexus/SharedResource.{resx,en-US.resx} - durchgesetzte Ressourcendateien
  - [SEKUNDÄR] ResXManager.config.xml - Begründung: Verwaltungswerkzeug
 Prüfidee:      Fehlt ein Key → Fallback auf Neutral-ResX.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-020
 Titel:         Kassenbuch: aktuell als [Obsolete] markiert, Tabelle vorhanden
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Kasse
 Vorbedingung:  -
 Fakt:          Tabelle `[dbo].[Kassenbuch]` existiert; alle Kassenbuch-Rechte in `UserRightsConst` sind `[Obsolete]` (`RIGHT_KASSENBUCH`, `RIGHT_KASSENBUCHEINBUCHUNG`, `RIGHT_KASSENBUCHAUSBUCHUNG`, `RIGHT_KASSENABSCHLUSS`, `RIGHT_KASSENBUCHERWEITERT`); BL-Verzeichnis `Sales/CashBooks`.
 Aussage:       Die Software enthält noch ein physisches Kassenbuchmodul, jedoch sind die zugehörigen Rechte als veraltet markiert; Funktionsverwendung im WPF wurde laut Rechtekommentaren weitgehend stillgelegt.
 Ergebnis:      Altmodul mit Datenbestand, aber kaum aktiver Fläche.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `Sales.Cashbox`: sämtliche IDs `[Obsolete]` - durchgesetzte Abschaltung
  - [PRIMÄR]   SSMS `[dbo].[Kassenbuch]` - Begründung: Datentabelle noch vorhanden
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CashBooks - Begründung: BL-Modulrest
 Prüfidee:      Rechtsvergabe im Admin zeigt Kassenbuch-Rechte nicht mehr.
 Tracelinks:    StRS-008
 Konsolidierung: Kandidat: Altmodul - Migration datenseitig prüfen
 Übernahmewürdigkeit: veraltet - Kassenfunktion abgelöst; Bestandsdaten migrieren
 Status:        belegt
 ---
 ID:            SwRS-021
 Titel:         hlpdsk-/Beleg-Fingerprint- und Eskalations-Trigger als Hintergrunddienst
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        System
 Vorbedingung:  Fristen konfiguriert
 Fakt:          HostedService `EscalationsService`; Tabelle `hlpdsk_status`, `hlpdsk_prioritaeten`; Recht `MATURITY_CHANGE` (20400131) erforderlich, wenn Statuswechsel Fälligkeitsänderung nach sich zieht.
 Aussage:       Die Software sollTickets bei Fristüberschreitung eskalieren und Statusänderungen, die Fälligkeit beeinflussen, nur mit eigenem Recht zulassen.
 Ergebnis:      Gesteuerte Eskalation, revisionssicher.
 Belege:
  - [PRIMÄR]   CentronHost.cs `AddHostedService<EscalationsService>()` - durchgesetzte Registrierung
  - [PRIMÄR]   CentronRights.md Nr. 5: „This may also be required when changing the status of a ticket, if this requires a due date change." - Begründung: fachliche Regel (Kontext, keine Durchsetzungsstelle)
 Prüfidee:      Statuswechsel mit Fälligkeitsänderung ohne Recht → Hinweis; Eskalationsdienst degradiert überfällige Tickets simulierbar.
 Tracelinks:    StRS-006, SyRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-022
 Titel:         CORS-Richtlinie erlaubt alle Ursprünge [Sicherheit, Konfiguration]
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Webservice-Betreiber
 Vorbedingung:  -
 Fakt:          `CentronHost.ConfigureInternal`: `b.UseCors(d => d.AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod());`
 Aussage:       Die Software erlaubt CORS von beliebigen Origins; diese Konfiguration ist im Zielsystem zu ersetzen durch restriktive Whitelists.
 Ergebnis:      Gegenwärtig unkritisch aufgrund eigenständiger Authentifizierung, jedoch erhöhtes Risikoprofil für SaaS.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.Host/CentronHost.cs `UseCors(d => d.AllowAnyOrigin()...)` - durchsetzende Stelle
 Prüfidee:      Preflight-OPTIONS-Anfrage von fremder Origin wird akzeptiert (nachzuweisen).
 Tracelinks:    SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: Workaround - historisch toleriert; im Web-/SaaS-Zielsystem absichern
 Status:        belegt
 ---
 ID:            SwRS-023
 Titel:         Windows- vs. Linux-Websocket (HttpSys vs. Kestrel) und HTTPS-Zertifikate
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Übertragbarkeit
 Akteur:        Betreiber
 Vorbedingung:  Konfigurierte Webservice-Adresse
 Fakt:          `CentronHost.Start`: `OperatingSystem.IsWindows()` → `builder.UseHttpSys(... UrlPrefix = * bei localhost ...)`, sonst `UseKestrel` mit `ListenAnyIP(this.Url.Port)`; HTTPS über `X509CertificateLoader.LoadPkcs12FromFile(WebServiceCertificateFilePath, WebServiceCertificatePassword)`; `MaxRequestBodySize = null` zwecks großer Uploads; Timeouts 30 Min (IdleConnection/RequestQueue) bzw. 5 Min (RequestHeadersTimeout).
 Aussage:       Die Software soll den Webservice plattformübergreifend (HttpSys auf Windows, Kestrel sonst) mit konfigurierbarem HTTPS und erhöhten Timeouts für langlaufende Geschäftsvorgänge betreiben; Upload-Limits sind deaktiviert.
 Ergebnis:      Betrieb auf Windows und Linux ohne Codebranch.
 Belege:
  - [PRIMÄR]   CentronHost.cs: UseHttpSys/UseKestrel-Verzweigung, Timeout-Werte, `X509CertificateLoader.LoadPkcs12FromFile` - durchgesetzte Stelle
 Prüfidee:      Start unter Linux mit https://-URL ohne Zertifikat → Startfehler; mit Zertifikat erfolgreich.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Hosting-Flexibilität fürs Web
 Status:        belegt
 ---
 ID:            SwRS-024
 Titel:         Webkonfiguration und Geheimnisse in Datei (WebServiceConfig)
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Konfiguration)
 Akteur:        Admin
 Vorbedingung:  WebServiceConfig.xml
 Fakt:          `WebServiceConfigHelper.Current` stellt `WebServiceAddress`, `WebServiceCertificateFilePath`, `WebServiceCertificatePassword`, `SecretKey`, `ActiveDirectoryAuthEnabled`, `TwoFactorAuthEnabled`, `ExecuteServices`, `ActivateHelpPage`; `SaveToFileAsync` schreibt konfiguration zurück in Datei.
 Aussage:       Die Software liest Betriebsparameter und Geheimnisse aus einer Datei `WebServiceConfig.xml`; Änderungen (z. B. ActiveDirectoryAuthEnabled-Migration) werden persistiert.
 Ergebnis:      Konfiguration änderbar ohne Deployment; Geheimnisse aber im Klartext abgelegt.
 Belege:
  - [PRIMÄR]   CentronHost.cs Verwendung von `WebServiceConfigHelper.Current` und `WebServiceConfigHelper.SaveToFileAsync()` - durchgesetzte Stelle
  - [SEKUNDÄR] src/webservice/c-entron.misc.ConnectionManager - Begründung: Verwaltungs-UI für Verbindungen
 Prüfidee:      Änderung `TwoFactorAuthEnabled=true` in Xml wird nach Service-Neustart wirksam.
 Tracelinks:    SyRS-022, SyRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: Workaround - im Zielsystem in Secrets-Store migrieren
 Status:        belegt
 ---
 ID:            SwRS-025
 Titel:         Zeitkonten: Urlaub/Krankheit/Kurzarbeit/Überstundenausgleich mit Einzelrechten
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Personalabteilung
 Vorbedingung:  Mitarbeiter
 Fakt:          Rechteblock `RIGHT_TERMINPLANUNG*` (20400272 Urlaub genehmigen, 20400273 für anderen eintragen, 20400274 Genehmigung, 20400275/76/77 Krankheitstage, 20400279/80/81 Überstundenausgleich, 20400282/83/84 Kurzarbeit); Tabellen `Terminplanung`, `TerminplanungArt`, `TerminplanungPerson`.
 Aussage:       Die Software soll Terminplanungsaktivitäten (Urlaub, Krankheit, Kurzarbeit, Überstundenausgleich) mit getrennten Rechten für Anlage, Bearbeitung und Genehmigung führen.
 Ergebnis:      Datenschutzkonforme Personalzeitverwaltung.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `RIGHT_TERMINPLANUNG*`-Block - durchgesetzte Rechte-Matrix
  - [SEKUNDÄR] SSMS `[dbo].[Terminplanung*]` - Begründung: persistenter Terminplan
 Prüfidee:      Krankheitstage-Anlage ohne Recht abgelehnt.
 Tracelinks:    StRS-006, StRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-026
 Titel:         Textbausteine (TextModuleArea)
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        alle
 Vorbedingung:  -
 Fakt:          BL-Verzeichnis `TextModuleArea`; Recht `RIGHT_TEXTBAUSTEINE` (20400178); Tabelle `GeschaeftspartnerTextbausteine`; DAO-Verzeichnis `TextModuleArea`.
 Aussage:       Die Software soll Textbausteine zentral verwalten und geschäftspartnerbezogen einsetzen.
 Ergebnis:      Wiederverwendbare Korrespondenztexte.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `RIGHT_TEXTBAUSTEINE = 20400178` - Begründung: durchgesetztes Recht
  - [SEKUNDÄR] SSMS `[dbo].[GeschaeftspartnerTextbausteine]`, src/backend/Centron.BL/TextModuleArea - Begründung: Modul und Speicher
 Prüfidee:      Textbaustein ohne Recht nicht pflegbar.
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-027
 Titel:         Massenupdates und Datenqualität
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Administrator
 Vorbedingung:  Profile konfiguriert
 Fakt:          BL-Verzeichnisse `MassUpdate`, `Tools`, `ExternalToolsBL`, `Customizations`; ViewModel-Verzeichnis `Massenupdates`; HostedService `MassUpdateService`, `DataQualityService`.
 Aussage:       Die Software soll Massenupdate-Profile zeitgesteuert ausführen und Datenqualität kontinuierlich prüfen.
 Ergebnis:      Datenpflege automatisiert.
 Belege:
  - [PRIMÄR]   CentronHost.cs `MassUpdateService`, `DataQualityService` - durchgesetzte Registrierung
  - [SEKUNDÄR] src/backend/Centron.BL/MassUpdate, WPF `ViewModels/Modules/Massenupdates` - Begründung: UI und BL
 Prüfidee:      Zeitplan erreicht → Massenupdate erzeugt Logeintrag.
 Tracelinks:    StRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SwRS-028
 Titel:         Change Tracking separat verankert
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        System
 Vorbedingung:  -
 Fakt:          BL-Verzeichnis `ChangeTracking`; DAO-Verzeichnis `ChangeTracking`; Recht `SHOW_AUDIT` (20800097); ReceiptLog-Protokoll siehe SwRS-011.
 Aussage:       Die Software soll Änderungshistorien von Entitäten getrennt vom Beleglog als Change-Tracking-Subsystem führen.
 Ergebnis:      Feldebene-Auditing unabhängig von Belegen.
 Belege:
  - [SEKUNDÄR] src/backend/Centron.BL/ChangeTracking, src/backend/Centron.DAO/ChangeTracking - Begründung: durchgetrennte Subsystemmodule
  - [PRIMÄR]   UserRightsConst.cs `SHOW_AUDIT` - Begründung: Recht zur Ansicht
 Prüfidee:      Feldänderung erzeugt Change-Tracking-Eintrag; Sichtbarkeit an Recht gebunden.
 Tracelinks:    SyRS-011, SwRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - als einheitliches Audit im Zielsystem mit SwRS-011 zusammenführen
 Status:        belegt
 ---
@@ -0,0 +1,129 @@
 # SyRS - Ergänzende System Requirements (Modul-Breitabdeckung, Teil 2)
 # Fortsetzung von SyRS.md (IDs SyRS-037 ff.)
 ---
 ID:            SyRS-037
 Titel:         Rücksendung (RMA) und Reparatureingang
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Service
 Vorbedingung:  Artikel/Gerät betroffen
 Fakt:          Tabelle `[dbo].[Rma]`; Rechte `RIGHT_RMA` (20400198), `RIGHT_RMAANLEGEN` (20400210), `RIGHT_RMAARTIKELSTATUSAENDERN` (20400199), `RIGHT_REPARATUREINGANG` (20400129), `RIGHT_REPARATUREINGANGANZEIGEN` (20400130) inkl. Filialrestriktion `RIGHT_REPARATUREINGANGANZEIGENFILIALE` (20400222), `RIGHT_RUECKSENDUNG*` (20400127-20400128, nur eigene Filiale 20400223); WPF-Modul `ViewModels/Modules/Rma`.
 Aussage:       Das System soll Rücksendungen als RMA-Fälle anlegen, Reparatureingänge erfassen und den Artikelstatus rechtegesteuert ändern; Sichtbarkeit kann filialbezogen begrenzt werden.
 Ergebnis:      Reverse-Logistik durchgängig.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs IDs 20400198-20400223 - durchgesetzte Rechte-Matrix
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `[dbo].[Rma]` - durchgesetzte Persistenz
 Prüfidee:      RMA-Fall anlegen ohne Recht nicht möglich; Statuswechsel nur mit Recht 20400199.
 Tracelinks:    StRS-006, StRS-009
 Konsolidierung: Kandidat: RMA-Fall und Reparatur/Reparatureingang als zwei Wege für denselben fachlichen Vorgang
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-038
 Titel:         Marketing/Sonderaktionen, Telemarketing und CRM-Projekte
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Marketing/Vertrieb
 Vorbedingung:  Kundenstamm
 Fakt:          Tabellen `Sonderaktionen`, `SonderaktionenAktion`, `SonderaktionenAktionVorlagen`, `SonderaktionenReferenzen`, `TelemarketingParticipants`, `CRMProjekt`, `CRMProjektObjekt`, `Kontakt`/`KontaktePersonen`; BL `Sales/Marketing/TelemarketingBL.cs`, `TelemarketingActionBL.cs`, u. a.; Rechte `RIGHT_SONDERAKTIONEN` (111170), `RIGHT_AKQUISE` (2060033), `RIGHT_CRMPROJEKTE*` (20400235/36, ONLY_OWN_BRANCH, ONLY_OWN, EXCEL_EXPORT), Kontaktverwaltung (20400244/45).
 Aussage:       Das System soll Marketing-Sonderaktionen mit Vorlagen und Referenzen, Telemarketing-Aktionen mit Teilnehmern sowie CRM-Projekte mit Objekten führen; CRM-Sichtbarkeit ist eigen- und filialbezogen beschränkbar und excel-exportierbar.
 Ergebnis:      Vertriebskampagnen plan- und auswertbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Marketing/TelemarketingBL.cs (+ Action/Template/Reference/Text BLs) - durchgesetzte BL
  - [PRIMÄR]   UserRightsConst.cs CRM-Projektrechte 20400235-20800139 - durchgesetzte Rechte
  - [SEKUNDÄR] SSMS `Sonderaktionen*`, `CRMProjekt*` - Begründung: Persistenz
 Prüfidee:      CRM-Export ohne Recht 20800138 nicht möglich.
 Tracelinks:    StRS-002, StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-039
 Titel:         EDI-Management mit Gateway, Dispatcher, Logs und zeitgesteuertem Download
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Einkauf/Vertrieb-Automation
 Vorbedingung:  EDI-Gateway konfiguriert
 Fakt:          `EDICommonBL`, `EDIDispatcherBL`, `EDIGatewaySettingBL`, `EDILogBL`, `EdiExportBL`, `EdiDocumentBL`; HostedService `EdiDownloadService`; Recht `RIGHT_EDIMANAGEMENT` (20400343), `RIGHT_EDI1` (10790).
 Aussage:       Das System soll EDI-Nachrichten gatewaygestützt versenden/empfangen, zeitgesteuert abrufen, jede Verarbeitung loggen und Verarbeitung je Einstellung dispatchen; Nutzung ist lizensiert/Rechte-gebunden.
 Ergebnis:      Revisionsfähiges EDI ohne manuelle Eingriffe.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/EDI/{EDIDispatcherBL,EDIGatewaySettingBL,EDILogBL}.cs - durchgesetzte Verarbeitung
  - [PRIMÄR]   CentronHost.cs: `EdiDownloadService` - durchgesetzte Zeitsteuerung
 Prüfidee:      Empfangene Nachricht erzeugt EDILog-Eintrag; Recht fehlt → UI verbirgt Verwaltung.
 Tracelinks:    SyRS-020, SyRS-025
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-040
 Titel:         Kostenstellen/Kostenträger und Zahlungskonditionen als Stammdaten
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Controlling/Buchhaltung
 Vorbedingung:  -
 Fakt:          Tabellen `Kostenstellen`, `Kostentraeger`, `Zahkond`, `Stammdat`; BL `Warehousing/{CostCenterBL,CostObjectBL}` (Cost-Center im Warehousing-Namespace), WPF-Modul `PayersAndCostCenter`; Recht `Masterdata.PAYERS_AND_COST_CENTER` (10450), `PAYMENT_CONDITION` (10410).
 Aussage:       Das System soll Kostenstellen, Kostenträger und Zahlungskonditionen als Stammdaten hinter eigenen Verwaltungsrechten pflegen und in Belegen referenzieren.
 Ergebnis:      Controllingfähige Stammdaten.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `[dbo].[Kostenstellen]`, `[dbo].[Kostentraeger]`, `[dbo].[Zahkond]` - durchgesetzte Persistenz
  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/{CostCenterBL.cs,CostObjectBL.cs} - durchgesetzte BL
 Prüfidee:      Zuordnung der Zahlungskondition zum Geschäftspartner persistiert.
 Tracelinks:    SyRS-015, StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-041
 Titel:         PLM-/QM-/Kontrollmodule für Arbeitsplätze und Umwelt/Arbeitssicherheit
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Fertigung, QS
 Vorbedingung:  Lizenz QM
 Fakt:          Tabellen `AGArbeitssicherheit`, `AGLohngruppe`, `AGMaterial`, `AGPrufvorschrift`, `AGUmweltschutz`, `Arbeitsplatz*`; HostedService `PlmImportService`; WPF-Module `PLM` und `QM`; Recht `RIGHT_AUFTRAGFINALVERSIONSETZEN` (20400317, mit Hinweis „Benötigt die c-entron Lizenz QM-Module").
 Aussage:       Das System soll Arbeitsplatz-/Arbeitsgangstammdaten inkl. Arbeitssicherheits-, Umweltschutz-, Material- und Prüfvorschriften führen sowie PLM-Importe zeitgesteuert einspielen; QM-Funktionen sind lizenzpflichtig.
 Ergebnis:      Regulatorische Fertigungsdokumentation.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `PlmImportService` - durchgesetzte Registrierung
  - [SEKUNDÄR] SSMS `AG*`-CREATE TABLEs, UserRightsConst 20400317 (Rechtstext erwähnt QM-Lizenz) - Begründung: Persistenz und Lizenzbindung
 Prüfidee:      QM-Funktion ohne Lizenz nicht sichtbar.
 Tracelinks:    StRS-014, SyRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: Sonderfall - branchenspezifisch, Lizenzmodul
 Status:        belegt
 ---
 ID:            SyRS-042
 Titel:         Vertragsübergreifende Preis-/Produktleitplanken: Projekte und Projektpreis-Import
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertriebsleitung
 Vorbedingung:  Kunden vorhanden
 Fakt:          BL `Projects/ProjectBL.cs`, Verzeichnis `TicketProjects`; WPF-Modul `ProjectPriceImport`; Recht `Project_Price_Import` (20800043), Preisanpassungsrechte je Belegart 20400233/34/85-91; Recht `RIGHT_ANGEBOTEKANPASSENPROJEKTPREISE` (20400308).
 Aussage:       Das System soll Vertriebsprojekte verwalten, Projektpreise zu importieren gestatten und die Preisanpassung bei Projektpreisen pro Belegart rechtegesteuert erlauben.
 Ergebnis:      Kunden-/Projektbezogene Preisgestaltung.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs IDs 20800043, 20400308 u. Preisänderungsrechte - durchgesetzte Rechte
  - [SEKUNDÄR] src/backend/Centron.BL/Projects/ProjectBL.cs, WPF `ViewModels/Modules/ProjectPriceImport` - Begründung: BL/UI
 Prüfidee:      Preisimport ohne Recht abgelehnt.
 Tracelinks:    StRS-004, SyRS-016
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
@@ -0,0 +1,769 @@
 # SyRS - System Requirements Specification
 # c-entron ERP-Suite (Reverse Requirements Engineering, Baseline V1 Iteration 02)
 ---
 ID:            SyRS-001
 Titel:         Schichtenarchitektur: WPF-Client, Webservice-Host, Blazor-Webclient
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Übertragbarkeit/Wartbarkeit
 Akteur:        Systembetreiber
 Vorbedingung:  MSSQL-Datenbank installiert
 Fakt:          Projektliste (Centron.sln / dir-Ausgabe): `Centron.WPF.UI` (Desktop), `Centron.Host` + `Centron.Controllers` (ASP.NET-Core-REST-Host, auch als WindowsService und Linux-Console), `CentronNexus.Host`/`CentronNexus` (Blazor), `CentronNexus.OutlookAddIn`; Businesslogik in `Centron.BL`, Persistenz in `Centron.DAO` (NHibernate).
 Aussage:       Das System soll eine Drei-Kanäle-Architektur (Desktop-WPF, REST-Webservice-Host, Blazor-Web) auf gemeinsamer Business- und Persistenzschicht betreiben.
 Ergebnis:      Fachlogik ist kanalunabhängig wiederverwendbar; alle Kanäle nutzen dieselbe Datenbank.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.Host/CentronHost.cs (WebHostBuilder mit HttpSys/Kestrel) - Begründung: durchgesetzter Systemstart des REST-Hosts
  - [SEKUNDÄR] Centron.sln; src/nexus/CentronNexus.Host; src/centron/Centron.WPF.UI - Begründung: Projektstruktur der Kanäle
 Prüfidee:      WPF-Client und Webclient lesen denselben Beleg aus derselben Datenbank.
 Tracelinks:    StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - entspricht der SaaS-Zielarchitektur, WPF wird abgelöst (siehe SwRS-014)
 Status:        belegt
 ---
 ID:            SyRS-002
 Titel:         Versionierte REST-API
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        externe Integration, Webclient
 Vorbedingung:  Webservice läuft
 Fakt:          Controller-Struktur `src/webservice/Centron.Controllers/Controllers/v1` (Accounts, Contracts, Customers, DataExchange, Helpdesks, Offers, Orders, Receipts, SelfCare, Tickets, WebAccount, WebVersion ...) plus `Controllers/Unversioned` (AuthConfigurationController, JwtAuthController, TwoFactorAuthController); `AddCentronApiVersioning()` in `CentronHost.Start()`.
 Aussage:       Das System soll eine versionierte REST-API (v1) für die fachlichen Kernressourcen anbieten; unversionierte Endpunkte sind auf Authentifizierungsaufgaben beschränkt.
 Ergebnis:      API-Änderungen sind versionsstabil, Clients können gezielt binden.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `f.AddCentronApiVersioning()` - Begründung: durchgesetzte Versionierung im Request-Pipeline-Setup
  - [SEKUNDÄR] Verzeichnisse src/webservice/Centron.Controllers/Controllers/v1 und /Unversioned - Begründung: tatsächliche Controller-Topologie
 Prüfidee:      GET auf v1-Controller liefert Version-Header; unversionierte Endpunkte außer Auth liefern 404.
 Tracelinks:    StRS-014 (Ausweitung), SwRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Pflicht für SaaS-Ökosystem
 Status:        belegt
 ---
 ID:            SyRS-003
 Titel:         Ticket-basierte Authentifizierung des Webservices [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Vertraulichkeit/Authentizität)
 Akteur:        alle Webservice-Clients
 Vorbedingung:  gültiges Benutzerkonto
 Fakt:          `CentronHost.Start()`: `auth.AddCentronTicket()` als `TicketAuthenticationDefaults.AuthenticationScheme` konfiguriert; `TicketBL.GetTicket(string ticketId)` löst Ticket über `TicketRepository`; `AuthenticationTicketBL` verknüpft Ticket mit Authentifizierung; `routes.MapControllers().RequireAuthorization()` erfordert grundsätzlich Authentifizierung.
 Aussage:       Das System soll alle REST-Endpunkte (außer explizit `[AllowAnonymous]`) authentifizieren; Benutzer authentifizieren sich über Ticket-Token, die serverseitig auflösbar und an einen `UserI3D` gebunden sind.
 Ergebnis:      Unauthentifizierte Aufrufe werden abgewiesen; Tickets bezugnehmender Benutzer sind nachvollziehbar.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `auth.AddCentronTicket()` und `routes.MapControllers().RequireAuthorization()` (durchsetzende Stelle: Authentication-Setup + Endpoint-Requirement)
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/TicketBL.cs: `GetTicket(ticketId)` (durchsetzende Stelle: Repository-Auflösung des Tokens)
  - [SEKUNDÄR] JwtAuthController.ConnectAccounts prüft `ticketResult.Data.UserI3D > 0` - Begründung: Ticket bound an Benutzer
 Prüfidee:      Request ohne Ticket → 401; Request mit gültigem Ticket → Claims/Benutzerkontext gesetzt.
 Tracelinks:    StRS-002, StRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - mit OAuth2/OIDC als Ziel neu zu bewerten
 Status:        belegt
 ---
 ID:            SyRS-004
 Titel:         JWT/OpenID-Connect-Login [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        IdP-integrierte Benutzer
 Vorbedingung:  IdP konfiguriert (`AppSettingsGroupBL.GetJwtSettings`)
 Fakt:          `JwtAuthController` mit `[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]`, `LoginWithBearer` ermittelt Webservice-Token, entschlüsselte ApplicationGuid, authentifizierten Principal und delegiert an `AuthenticatorFactory.GetAuthenticator(...).GetTicket()`; `CentronHost` validiert Issuer, Audience, Lifetime, SigningKey, verlangt signierte Tokens, ExpirationTime sowie `ValidateActor` und `ValidateTokenReplay`.
 Aussage:       Das System soll Benutzer über einen externen OpenID-Connect-Anbieter (JWT Bearer) anmelden und daraus ein Centron-Ticket ausstellen; Tokens sind vollständig zu validieren.
 Ergebnis:      Single Sign-On möglich; ungültige/abgelaufene/signaturlose Tokens werden verworfen.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `TokenValidationParameters { ValidateIssuer=true; ValidateAudience=true; ValidateLifetime=true; ValidateIssuerSigningKey=true; RequireSignedTokens=true; RequireExpirationTime=true; ValidateActor=true; ValidateTokenReplay=true }` (durchsetzende Stelle)
  - [PRIMÄR]   src/webservice/Centron.Controllers/Controllers/Unversioned/JwtAuthController.cs: `LoginWithBearer` mit `[Authorize(JwtBearer)]` - Begründung: durchgesetzter Login-Pfad
 Prüfidee:      Token mit falscher Audience/Signatur → 401; gültiges Token → Centron-Ticket in Response.
 Tracelinks:    StRS-002, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Standard für SaaS
 Status:        belegt
 ---
 ID:            SyRS-005
 Titel:         Zwei-Faktor-Authentifizierung per E-Mail-Link [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Endbenutzer
 Vorbedingung:  `TwoFactorAuthEnabled` in Webservice-Konfiguration aktiviert
 Fakt:          `TwoFactorAuthController/validate` (`[AllowAnonymous]`) nutzt `WebServiceConfigHelper.Current.TwoFactorAuthEnabled` und `TwoFactorAuthBL.GetTwoFactorValidator()`; nur `EmailTwoFactorValidator` wird aktiviert; `TrySetCodeAsValidated(code)` markiert Code als validiert.
 Aussage:       Das System soll eine optionale Zwei-Faktor-Authentifizierung über E-Mail-Validierungscodes anbieten; ungültige Codes werden ohne Informationsoffenlegung abgelehnt.
 Ergebnis:      Anmeldesicherheit erhöht bei aktivierter Konfiguration.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.Controllers/Controllers/Unversioned/TwoFactorAuthController.cs: Bedingungen `TwoFactorAuthEnabled == false` → Abbruch; `TrySetCodeAsValidated` (durchsetzende Stelle)
  - [SEKUNDÄR] BL-Verzeichnis `TwoFactorAuthenticator` - Begründung: modulare Erweiterbarkeit
 Prüfidee:      Code unkorrekt → keine Aktivierung; Code korrekt → Login fließt durch.
 Tracelinks:    SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - sicherheitsrelevant
 Status:        belegt
 ---
 ID:            SyRS-006
 Titel:         Lizenzprüfung vor Datenbankzugriff [Sicherheit/Abrechnung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Integrität)
 Akteur:        Hersteller, Betreiber
 Vorbedingung:  Lizenzdatei vorhanden
 Fakt:          `CentronHost.Start()`: `this.TryLoadLicense()` steht vor `this.SetupDatabaseConnection()`; Kommentar „Should the customer not have a valid license, we don't want to connect to the database and execute the scripts."; `LicenseManager.Initialize(LicenseManager.SettingsForWebService())`; `LoadLicenses().Wait()` wirft Exception bei ungültiger Lizenz.
 Aussage:       Das System soll beim Start zuerst die Herstellerlizenz prüfen; ohne gültige Lizenz darf keine Datenbankverbindung und kein Datenbank-Update erfolgen.
 Ergebnis:      Unlizenzierte Instanzen bleiben wirkungslos.
 Belege:
  - [PRIMÄR]   CentronHost.cs: Reihenfolge `TryLoadLicense(); SetupDatabaseConnection();` (durchsetzende Stelle: Start-Sequenz)
 Prüfidee:      Start mit entfernter Lizenz → Exception vor DB-Verbindung.
 Tracelinks:    StRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Schutz des Geschäftsmodells
 Status:        belegt
 ---
 ID:            SyRS-007
 Titel:         Automatische Datenbankschema-Migration beim Start [Zuverlässigkeit]
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit/Wartbarkeit
 Akteur:        Betreiber
 Vorbedingung:  Lizenz geprüft
 Fakt:          `SetupDatabaseConnection()`: `SqlServerBL.CheckDatabaseVersion()`, `CheckDatabaseMatchesWebService()`, dann `ScriptEngineBL.ExecuteScripts()`; Exception bei Fehler; Skript-Repository `SQLScriptCollection*.xml` (z. B. `cvw_DunningRunItems` in `SQLScriptCollection4.xml`).
 Aussage:       Das System soll beim Start Schemaversion und Kompatibilität von Datenbank und Host prüfen und ausstehende SQL-Migrationsskripte selbständig ausführen.
 Ergebnis:      Datenbankstruktur entspricht immer der erwarteten Version; Schutz vor veralteten Schemata.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `sqlServerBL.CheckDatabaseVersion()`, `CheckDatabaseMatchesWebService()`, `session.GetBL<ScriptEngineBL>().ExecuteScripts()` (durchsetzende Stelle)
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Scripts/ScriptMethods/SqlStatements - Begründung: versionierte Skriptbibliothek
 Prüfidee:      Start auf älterer Datenbank → Skripte laufen; Start auf zu neuer DB → Exception.
 Tracelinks:    SyRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Betriebsfähigkeit
 Status:        belegt
 ---
 ID:            SyRS-008
 Titel:         Zeitgesteuerte Hintergrunddienste [Betrieb]
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit (Betriebsführung)
 Akteur:        System
 Vorbedingung:  `ExecuteServices` in Konfiguration aktiviert
 Fakt:          `CentronHost`: bei `WebServiceConfigHelper.Current.ExecuteServices == true` werden u. a. `ArticleImportService`, `AutomaticPriceUpdateService`, `ContractEndeService`, `ContractCloseService`, `UpdateExpiredProvisionSchemasService`, `EscalationsService`, `RecurringScriptService`, `EdiDownloadService`, `MassUpdateService`, `ExchangeSyncService`, `DocumentsCleanupService`, `CTimeConnectorService`, `GfkExportService` registriert.
 Aussage:       Das System soll periodische Geschäftsprozesse (Vertragsende, Provisionssteuerung, Eskalationen, Preisaktualisierungen, Import-Export, Benachrichtigungen) als Hintergrunddienste auf dem Host ausführen, sofern aktiviert.
 Ergebnis:      Keine manuellen Batchläufe jenseits des Hosts erforderlich; Dienste sind konfigurierbar.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `if (WebServiceConfigHelper.Current?.ExecuteServices == true) { f.AddHostedService<...>() }` (durchsetzende Stelle)
 Prüfidee:      Deaktiviert `ExecuteServices` → keine HostedServices starten; aktiviert → Contracts werden automatisch beendet.
 Tracelinks:    StRS-005, StRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - SaaS-Betrieb
 Status:        belegt
 ---
 ID:            SyRS-009
 Titel:         Rechteprüfung für Helpdesk: eigene/Filiale/Abteilung [Berechtigung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Techniker
 Vorbedingung:  Rechte vergeben
 Fakt:          `CentronRights.md` definiert ids und Semantik; `DunningRunWebServiceBL.ValidateDunningRun`-Analog in `AccountAddressBL.ValidateUserRightRead/ValidateUserRight(...)` (Aufruf in `GetAllForAccountAddress`, `Save`); `AccountBL.ValidateUserRights(...)` mit Unterscheidung `newCustomer/getAccount/deleteAccount/editAccount/unlockAccount/newSupplier`; `AccountAddressBL.Save` prüft zudem Sonderrechte `EDIT_CUSTOMER_ADDRESS_LANGUAGE` und `EDIT_CUSTOMER_ADDRESS_CURRENCY`.
 Aussage:       Das System soll für sensible Stammdaten- und Helpdesk-Zugriffe vor Ausführung eine serverseitige Rechteprüfung aktivieren; Verletzung ergibt `Result` mit `RightCheckFailed`.
 Ergebnis:      Unberechtigte Änderungen werden mit klarem Fehlercode blockiert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountAddressBL.cs Zeilen 69/156-178 (Aufrufe `ValidateUserRightRead`, `ValidateUserRight`, `CheckSpecialUserRightForAddressLanguageBeforeSave`) - durchsetzende Stelle
  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs Zeilen 501/531/1299 (`ValidateUserRights(...)` mit `editAccount`, `deleteAccount`, u. a.) - durchsetzende Stelle
  - [KONTEXT]  CentronRights.md - Begründung: fachliche Rechtssemantik
 Prüfidee:      Speichern einer Anschrift ohne `EDIT_CUSTOMER` → `RightCheckFailed`.
 Tracelinks:    StRS-002, StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Berechtigungskern
 Status:        belegt
 ---
 ID:            SyRS-010
 Titel:         Rechnungsstorno: Vorbedingungen und Recht [Abrechnung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Integrität)
 Akteur:        Buchhaltung mit Recht
 Vorbedingung:  Rechnung existiert, nicht vorverarbeitet/exportiert
 Fakt:          `ReceiptInvoiceBL.CancelInvoice(int invoiceI3D, CreatedThroughApplication, AppUser)`: Prüfungen in Reihenfolge: (1) `currentUser.HasUserRight(UserRightsConst.RIGHT_RECHNUNGSTORNIEREN)` sonst Fehler; (2) State already Canceled; (3) `IsCashAsset` (Barrechnung) verboten; (4) `GetReceiptForwardedInto` nicht leer → verboten; (5) `_bookKeepingExportBL.IsReceiptExported(invoice)` → verboten; (6) Vertragsrechnung nur wenn letzte; dann `CreateNewVersion` mit `IgnoreCallbacks`, `QuantityComplete = 0` und Barcodes entfernt, `State = Canceled`, Logeintrag, Speicherung in dediziertem `DAOSession.WithTransaction` inkl. `ResetContract` und `RemoveTimers`.
 Aussage:       Das System soll eine Rechnung nur unter diesen Bedingungen stornieren und dabei eine neue Version mit Status „storniert" und gelöschten Abschlussmengen erzeugen; Barrechnungen sind nicht stornierbar; stornierte Vertragsrechnungen setzen Abrechnungsstand (Klickzähler/Sonderartikel) transaktional zurück.
 Ergebnis:      GoBD-konforme Versionierung und widerrufbare Abrechnung ohne Buchhaltungsexport-Bruch.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs `CancelInvoice` Zeilen 143-205 (durchsetzende Stelle: `HasUserRight`-Check, Status-/Export-Prüfungen, `CreateNewVersion`, `dedicatedSaveSession.WithTransaction`)
  - [SEKUNDÄR] UserRightsConst.cs `RIGHT_RECHNUNGSTORNIEREN = 20400101` - Begründung: Recht-Nummer
 Prüfidee:      Exportierte Rechnung stornieren → Fehler „bereits exportiert"; letzte Vertragsrechnung wird storniert und `ResetDeviceClickCounter` aufgerufen.
 Tracelinks:    StRS-004, StRS-005, StRS-007, SwRS-010, SwRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - revisionssichere Abrechnung
 Status:        belegt
 ---
 ID:            SyRS-011
 Titel:         Beleg-Festschreibung (IsFixed) [Abrechnung]
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        Buchhaltung
 Vorbedingung:  Rechnung abgeschlossen
 Fakt:          `ReceiptInvoiceBL.FixInvoice`: `UPDATE RechKopf SET IsFixed = 1 WHERE I3D = @I3D` via `RawSqlAccess.ExecuteNonQueryTransactionSave`; danach `ReceiptLogBL.CreateEntry(... ReceiptLogKind.FixedState ...)`; `CheckIfInvoiceIsFixed` blockiert Änderungen (Fehlertext „Die Rechnung ist festgeschrieben. Änderungen nicht möglich.").
 Aussage:       Das System soll Rechnungen durch eigenen Vorgang festschreiben; Änderungen an festgeschriebenen Rechnungen sind untersagt; Festschreibung wird im Beleglog protokolliert.
 Ergebnis:      Unveränderbarkeit abgerechneter Belege (GoBD).
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.cs: `FixInvoice`-SQL `UPDATE RechKopf SET IsFixed = 1` und `CheckIfInvoiceIsFixed`-Fehlermeldung (durchsetzende Stellen)
  - [SEKUNDÄR] ReceiptLogBL.CreateEntry(... FixedState ...) - Begründung: Audit-Trail
 Prüfidee:      Nach FixInvoice schlägt Speichern mit „festgeschrieben" fehl; Logeintrag vorhanden.
 Tracelinks:    StRS-004, StRS-008, SyRS-012, SwRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - revisionssicher
 Status:        belegt
 ---
 ID:            SyRS-012
 Titel:         Belegversionierung jeder Änderung [Abrechnung]
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        alle
 Vorbedingung:  Beleg existiert
 Fakt:          Schema enthält parallele Versions-Tabellen für jede Belegart: `RechKopfVersions/RechPosVersions`, `AufKopfVersions/AufPosVersions`, `LiefKopfVersions/LiefPosVersions`, `AbholKopfVersions/AbholPosVersions`, `GutKopfVersions/GutPosVersions`, `AngKopfVersions/AngPosVersions`, `VertragKopfVersions/VertragPosVersions`, `AnfrKopfVersions/AnfrPosVersions`; Rechte `RIGHT_*DATUMEDITIERBARNEUEVERSION` (Datum nur bei neuer Version), `RIGHT_EKAKTUALISIERENOHNENEUEVERSION` (Ausnahme); `CancelInvoice` nutzt `CreateNewVersion(... IgnoreCallbacks = true)`.
 Aussage:       Das System soll Änderungen an Belegen als neue, historisierbare Version speichern; Ausnahmen (z. B. EK-Aktualisierung) sind nur mit Sonderrecht möglich.
 Ergebnis:      Lückenlose Belegrevision.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql: Versions-Tabellen je Belegart - Begründung: durchgesetzte Historisierung im Schema
  - [PRIMÄR]   ReceiptBL/ReceiptInvoiceBL: `CreateNewVersion<ReceiptInvoice>(...)` vor Storno-Speicherung - durchsetzende Stelle
  - [SEKUNDÄR] UserRightsConst.cs IDs 20400100, 20400140-20400146, 20400088/20400089 - Begründung: Restriktionen beim Bearbeiten ohne neue Version
 Prüfidee:      Änderung erzeugt Version n+1; alte Version bleibt lesbar.
 Tracelinks:    SyRS-010, StRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - revisionssicheres Grundprinzip
 Status:        belegt
 ---
 ID:            SyRS-013
 Titel:         Beleg-Statusmodell (offen/abgeschlossen/storniert)
 Ebene:         SyRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        alle
 Vorbedingung:  -
 Fakt:          `src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs`: `Active = 1`, `Completed = 2`, `Canceled = 3` mit Description-Strings „offen"/„abgeschlossen"/„storniert"; Tabelle `ReceiptUserState` zusätzlich benutzerspezifisch.
 Aussage:       Das System soll für Belege exakt drei Systemzustände kennen (offen, abgeschlossen, storniert) und diese auf Belegebene durchsetzen. 
 Ergebnis:      Eindeutiges Statusmodell; rechtliche und technische Zustände trennbar.
 Belege:
  - [PRIMÄR]   ReceiptState.cs (Enum-Definition) - durchsetzende Stelle
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql `[dbo].[ReceiptUserState]` - Begründung: ergänzende benutzerbezogene Sicht
 Prüfidee:      Ungültiger Zustandswechsel (Completed→Active) ohne definierten Pfad → kein Übergang im Code.
 Tracelinks:    StRS-004, SyRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Basiskonzept
 Status:        belegt
 ---
 ID:            SyRS-014
 Titel:         Mahnlauf: Validierung, Stufen, Versand, Reset [Abrechnung]
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Buchhaltung
 Vorbedingung:  Rechnungen fällig, Mahnberichte konfiguriert
 Fakt:          `DunningRunWebServiceBL.ValidateDunningRun` wirft `ArgumentException` für: SendType None oder Fax; keine Rechnungen/Gutschriften; Rechnungen fremder Kunden; Rechnungen vor Fälligkeit; Rechnungen bereits in Stufe 3; Kundenkontakt fehlt. `DunningRunBL.ExecuteDunningRunInternal`: Aufbau `DunningRunNumber` über `GenerateNextDunningRunNumber`, `DunningRunState.Active`; `ResetDunningRun` setzt Items auf `DunningRunState.Deleted`; Report inkl. Mahnadresse via `UseDivergentInvoiceAddressAsDunningAddress`; Versand E-Mail oder Druck.
 Aussage:       Das System soll Mahnläufe nur für fällige Belege eines Kunden auf maximal drei Stufen ausführen, mit Vorschau, generiertem Mahnbericht, optionalem Mailversand und stornierbarem Mahnlauf.
 Ergebnis:      Rechtssichere Mahnfolge; einheitliche Mahnnummern.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs `ValidateDunningRun` (durchsetzende Stelle: ArgumentException-Validierungen)
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningRunBL.cs `ExecuteDunningRunInternal`/`ResetDunningRun` (durchsetzende Stelle: Nummernvergabe und Statusänderungen)
  - [SEKUNDÄR] SSMS_DB_SCHEMA.sql `[dbo].[Mahnlauf]` - Begründung: Persistenz
 Prüfidee:      Mahnlauf mit unfälliger Rechnung schlägt fehl; nach Reset ist Mahnnummer frei und Items gelöscht.
 Tracelinks:    StRS-008, SyRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Mahnwesen erforderlich
 Status:        belegt
 ---
 ID:            SyRS-015
 Titel:         Buchhaltungsexport-Sperre für stornierende Belege [Abrechnung]
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Buchhaltung extern (z. B. DATEV-Import)
 Vorbedingung:  Beleg bereits gebucht
 Fakt:          `BookKeepingExportBL.IsReceiptExported(invoice)` (in `ReceiptInvoiceBL.CancelInvoice`) verhindert Storno; `BookKeepingExportBL` speichert Exportkennzeichen mit `CentronVersion`; Recht `BOOKKEEPING_EXPORT` (10770, obsolete), `BOOKKEEPING_IMPORT` (20400203), Rechte „Exportiert"-Kennzeichen zurücksetzen (20400307, 20400309), `RIGHT_ERLOESKONTOINRECHNUNGAENDERN` (20400083).
 Aussage:       Das System soll den Export gebuchter Belege nachzeichnen und den Storno exportierter Rechnungen verweigern; das „wurde exportiert"-Kennzeichen darf nur mit Sonderrecht zurückgesetzt werden. Erlöskonto-Änderungen in Rechnungen sind rechtgesteuert.
 Ergebnis:      Abgeschlossene Buchungen bleiben zwischen ERP und Buchhaltung konsistent.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: `if (this._bookKeepingExportBL.IsReceiptExported(invoice)) return Result<ReceiptInvoice>.AsError(...)` - durchsetzende Stelle
  - [SEKUNDÄR] UserRightsConst.cs IDs 10770/20400203/20400307/20400309/20400083 - Begründung: Rechte für Kennzeichen und Erlöskonto
 Prüfidee:      Exportierte Rechnung stornieren → Fehler; Rücksetzen des Flags ohne Recht nicht möglich.
 Tracelinks:    StRS-008, SyRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - buchhalterische Integrität
 Status:        belegt
 ---
 ID:            SyRS-016
 Titel:         Provisionsabrechnung auf Belegbasis
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertriebsleitung, System
 Vorbedingung:  Provisionsschemata gepflegt
 Fakt:          `ReceiptProvisionSchemaBL` (29.712 Bytes), `ReceiptProvisionEmployeeGoalBL`, `ReceiptProvisionEmployeeLevelBL`; Schema-Tabellen `AngProv`, `AbholProv`; HostedService `UpdateExpiredProvisionSchemasService`; Rechtegruppe `Sales.Provision` (20800092-20800146) incl. `CAN_SEE_ALL_PROVISION_IN_RECEIPTS`, `PROVISION_SCHEMA_MANAGEMENT`, `PROVISION_SCHEMA_CUSTOMER_ASSIGNMENT`.
 Aussage:       Das System soll Provisionen auf Basis von Belegen mit Zeit- und Zielscheman steuern, abgelaufene Schemata automatisch deaktivieren und Sichtbarkeit auf Fremdprovisionen rechtegesteuert begrenzen.
 Ergebnis:      Automatisierte, revisionssichere Provisionswirtschaft.
 Belege:
  - [PRIMÄR]   CentronHost.cs `UpdateExpiredProvisionSchemasService` - durchsetzende Stelle für zeitliche Pflege
  - [SEKUNDÄR] ReceiptProvisionSchemaBL.cs, SSMS `[dbo].[AngProv]`, `[dbo].[AbholProv]` - Begründung: Schema-Entitäten
  - [SEKUNDÄR] UserRightsConst.cs Provision - Begründung: Rechte
 Prüfidee:      Abgelaufenes Schema wird nicht mehr für neue Belege herangezogen.
 Tracelinks:    StRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Vertriebssteuerung
 Status:        belegt
 ---
 ID:            SyRS-017
 Titel:         Abrechnete Ticketzeiten dürfen nicht verschoben/gelöscht werden [Abrechnung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit (Integrität)
 Akteur:        Techniker
 Vorbedingung:  Zeitdatensatz ist Teil eines Belegs
 Fakt:          `CentronRights.md` Kap. 8/9: Verschieben und Löschen von Helpdesk-Zeiten gestattet nur, „if the ticket is not part of a receipt"; `ReceiptItemTimerBL.RemoveTimers` wird beim Storno transaktional aufgerufen; Tabelle `hlpdsk_timer`.
 Aussage:       Das System soll die Bearbeitung von Helpdesk-Zeiten sperren, sobald diese in einen Beleg aufgenommen wurden, und die Verknüpfung erst beim Belegstorno lösen.
 Ergebnis:      Keine Doppel- oder Phantomabrechnung von Zeiten.
 Belege:
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice: `RemoveTimers(invoice, currentUser)` innerhalb `WithTransaction` (durchsetzende Stelle für Lösen der Verknüpfung)
  - [KONTEXT]  CentronRights.md Nr. 8/9 - Begründung: fachliche Regel für Verschieben/Löschen nur vor Abrechnung
  - [SEKUNDÄR] SSMS `[dbo].[hlpdsk_timer]` - Begründung: Datenbasis
 Prüfidee:      Abgerechnete Zeit verschieben → Verweis auf Belegzugehörigkeit; nach Storno wieder frei.
 Tracelinks:    StRS-007, SyRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Abrechnungsintegrität
 Status:        belegt
 ---
 ID:            SyRS-018
 Titel:         Kundenanlage/-änderung über Rechte mit Entsperrung [Berechtigung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Vertriebsinnendienst, Administrator
 Vorbedingung:  -
 Fakt:          `AccountBL.ValidateUserRights(int appUserI3D, bool newCustomer=false, bool getAccount=false, ...)` wird in `GetAccount`, `Save`, `DeleteAccount`, `UnlockAccount` aufgerufen (Zeilen 264/501/754/928); `ignoreRights`-Flag ermöglicht bewusste Ausnahme.
 Aussage:       Das System soll Geschäftspartner-Operationen (Anzeigen, Anlegen, Ändern, Löschen, Entsperren) einer Rechteprüfung unterziehen; Ausnahmen erfolgen nur durch explizites `ignoreRights`.
 Ergebnis:      Granulare Rechtebindung von Stammdaten.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Accounts/AccountBL.cs Zeilen 264, 501, 754, 928, 1299 (durchsetzende Stellen)
  - [SEKUNDÄR] UserRightsConst.cs `CREATE_CUSTOMER` 20400092, `EDIT_CUSTOMER` 20400093, `DELETE_CUSTOMER` 20400016, `LOCK_CUSTOMER` 2040002, `UNLOCK_CUSTOMER` 2040003 - Begründung: Rechte-Katalog
 Prüfidee:      Benutzer ohne `DELETE_CUSTOMER` kann Kunden nicht löschen; `ignoreRights=true` nur in Server-internen Vorgängen.
 Tracelinks:    StRS-002, StRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Berechtigungsmodell
 Status:        belegt
 ---
 ID:            SyRS-019
 Titel:         Seriennummern-Verpflichtung und -Historie
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Lager, Vertrieb
 Vorbedingung:  Artikel mit `SN bei Warenabgang`
 Fakt:          Recht `CHANGE_SERIALNUMBER_REQUIRED_FLAG` (20400318) erlaubt Änderung des SN-Pflichtflags; Rechte `SERIAL_NUMBER`-Serie (`ADD_SERIAL_NUMBER`, `GENERATE_SERIAL_NUMBER`, `REPLACE_SERIAL_NUMBER`, `REMOVE_SERIAL_NUMBER`, `RESET_SERIAL_NUMBER`), Klasse `BarcodeBL`/`BarcodeHistoryBL`, Tabelle `SeriennummerToPosition`; `CancelInvoice` leert `receiptItem.Barcodes` in neuen Versionen.
 Aussage:       Das System soll Seriennummern als eigenes Rechte- und Historienobjekt pflegen, mit Artikel je nach Pflichtflag, und beim Storno die SN-Verknüpfung der stornierten Position zurücksetzen.
 Ergebnis:      Lückenlose Verfolgbarkeit einzelner Geräte.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `Purchase.StockList.SerialAdministration` (IDs 20400028, 20400032-20400035, 20400051, 20400055) - Begründung: durchgesetzte Rechte-Matrix
  - [PRIMÄR]   ReceiptInvoiceBL.CancelInvoice `receiptItem.Barcodes.Clear()` - durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing/{BarcodeBL,BarcodeHistoryBL}.cs - Begründung: SN-Service und Historie
 Prüfidee:      SN-Ersatz erzeugt Historie; Storno entfernt Barcodes nur in neuer Version.
 Tracelinks:    StRS-009, SyRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-020
 Titel:         Bestell- und Wareneingangskette inkl. WE-Kalkulation
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Einkauf
 Vorbedingung:  Lieferant vorhanden
 Fakt:          Tabellen `BestKopf2/BestPos2`, `WareKopf/WarePos`, `KalkKopf/KalkPos`, `LiGutKopf/LiGutPos` (Lieferantengutschriften); Rechte `RIGHT_BESTELLUNGANLEGEN`, `RIGHT_WARENEINGANGERSTELLEN`, `RIGHT_WARENEINGANGABSCHLIESSEN`, `RIGHT_WEKALKULATIONABSCHLIESSEN`, `RIGHT_LIEFERANTENGUTSCHRIFTABSCHLIESSEN`, `SHOW_ORDER/INVOICE_ONLY_OWN_BRANCH`.
 Aussage:       Das System soll eine Einkaufsbelegkette (Bestellung → Wareneingang → WE-Kalkulation → Lieferantenrechnung/-gutschrift) mit Abschlussrechten und filialbezogener Sichtbarkeit führen.
 Ergebnis:      Beschaffungsprozess nachvollziehbar und sicher.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `CREATE TABLE [dbo].[BestKopf2]`, `[dbo].[WareKopf]`, `[dbo].[KalkKopf]`, `[dbo].[LiGutKopf]` - durchgesetztes Schema
  - [PRIMÄR]   UserRightsConst.cs (Bestell-/WE-/Kalk-Rights) - Begründung: durchgesetzte Rechte
 Prüfidee:      Wareneingang ohne Recht nicht abschließbar; Abschluss setzt State.
 Tracelinks:    StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-021
 Titel:         Inventuren mit Zählgruppen und Sperrlogik
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Lager
 Vorbedingung:  Inventur angelegt
 Fakt:          Rechte `Purchase.Inventory`: `CREATE_INVENTORY` (20400040), `CLOSE_INVENTORY` (20400042), `CREATE_INVENTORY_GROUP` (20400043), `REMOVE_ARTICLE_FROM_INVENTORY_GROUP` (20400044), `DELETE_INVENTORY_GROUP` (20400045), `UNLOCK_INVENTORY_GROUP` (20400048); `RIGHT_INVENTURGRUPPENENTSPERREN` (20400253); BL `InventoryManagement`.
 Aussage:       Das System soll Inventuren in Zählgruppen organisieren; Abschluss, Verwerfen, Entsperren und Artikel-Entfernung einzeln berechtigen.
 Ergebnis:      Kontrollierte Bestandsprüfung.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `Purchase.Inventory`-Block - durchgesetzte Rechte-Matrix
  - [SEKUNDÄR] src/backend/Centron.BL/Warehousing/InventoryManagement - Begründung: Modul
 Prüfidee:      Abschließen einer Inventur ohne `CLOSE_INVENTORY`-Recht wird verwehrt.
 Tracelinks:    StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-022
 Titel:         Vertragsende und -abschluss automatisiert
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        System
 Vorbedingung:  Vertrag aktiv, Ende konfiguriert
 Fakt:          HostedServices `ContractEndeService`, `ContractCloseService`, `UpdateSpecialArticleToContractService` in `CentronHost`; Tabellen `VertragKopf/VertragPos` mit Versions-Pendanten; Recht `Sales.LEASINGANDSERVICE` (10390).
 Aussage:       Das System soll Amtsende von Verträgen zeitgesteuert erkennen, laufende Verträge schließen und öffnen sowie Sonderartikel automatisch dem Vertrag nachführen.
 Ergebnis:      Vertragsstammdaten ohne manuelle Nachpflege korrekt.
 Belege:
  - [PRIMÄR]   CentronHost.cs: Registrierung der drei HostedServices (durchsetzende Stelle)
  - [SEKUNDÄR] SSMS `[dbo].[VertragKopfVersions]`, `[dbo].[VertragPosVersions]` - Begründung: historisierte Vertragsänderungen
 Prüfidee:      Laufzeit abgelaufen → Vertragsschluss automatisch (Datenbank prüfbar).
 Tracelinks:    StRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-023
 Titel:         Fertigungsaufträge und Arbeitsplan-Zeitdaten
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Fertigung
 Vorbedingung:  Produktionsstammdaten gepflegt
 Fakt:          Tabellen `ArticleProductionOrders`, `ArticleProductionOrderStepItems`, `ArticleProductionOrderStepItemTimes`, `ArticleProductionMaterials`, `APlan*`; BL `ProductionBL`, `ProductionOrderBL`; Nexus-Modul `ProductionOrderManagement`.
 Aussage:       Das System soll Fertigungsaufträge aus Vertriebsaufträgen erzeugen, Arbeitsplan-Schritte mit Material und Zeitbuchung erfassen und den Auftragsstatus auf „produziert" setzen lassen.
 Ergebnis:      Fertigprozess mit Rückverfolgbarkeit.
 Belege:
  - [PRIMÄR]   SSMS_DB_SCHEMA.sql `ArticleProductionOrderStepItemTimes` - durchgesetztes Datenmodell der Zeitbuchung
  - [SEKUNDÄR] UserRightsConst (`RIGHT_PPSARBEITSPLANANLEGEN`, `RIGHT_AUFTRAGPRODUZIERT`) - Begründung: Rechte
 Prüfidee:      Zeitbuchung auf Arbeitsschritt; Auftrag wechselt Recht epflichtig in produziert.
 Tracelinks:    StRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-024
 Titel:         Anlagenwartung mit Sperrlogik und Seriennummerhistorie
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb
 Vorbedingung:  Stammblatt vorhanden
 Fakt:          `AssetLockBL`, `MasterDataListBL`: Verweis „Stammblatt ist einem aktiven Vertrag zugeordnet." verhindert Löschung; Methoden zum Entfernen/Ersetzen der Hauptgeräte-SN; Kommentar „Writes the Stammblatt history entry (Historie tab)".
 Aussage:       Das System soll Kundenanlagen sperren, während sie abhängige Verträge haben, und Hauptgeräte-Seriennummeränderungen rechtegesteuert mit Historieneintrag dokumentieren.
 Ergebnis:      Integrität des Gerätebestands mit Audit.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/Contracts/ClickContracts/MasterDataListBL.cs (`DependencyCheckFailed`, SN-Historie) - durchsetzende Stelle
  - [SEKUNDÄR] src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs - Begründung: Sperrlogik
 Prüfidee:      Anlage mit aktivem Vertrag löschen → abgelehnt; SN-Änderungen sichtbar in Historie.
 Tracelinks:    StRS-010
 Konsolidierung: Kandidat: SwRS-006 (Stammblatt vs. AssetManagement-Datenhaltung)
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-025
 Titel:         Elektronische Rechnung (ebInterface)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Behördenkunden (Österreich)
 Vorbedingung:  Konfiguration
 Fakt:          Eigenes API-Projekt `src/apis/Centron.Api.EbInterface/Centron.Api.EbInterface.csproj`; OpenTrans-Deserialisierung in `ReceiptInvoiceBL.TryDeserializeOpenTransInvoice` mit `INVOICE`-Typ aus `Centron.Gateway.OpenTrans`.
 Aussage:       Das System soll Rechnungen im ebInterface/OpenTrans-XML-Format importieren (und förderieren), sofern konfiguriert.
 Ergebnis:      gesetzeskonformer E-Rechnungsverkehr.
 [Hinweis: der konkrete Ablauf der Ausgabe ist nicht vollständig gelesen]
 Belege:
  - [SEKUNDÄR] src/apis/Centron.Api.EbInterface - Begründung: separates Integrationsprojekt
  - [PRIMÄR]   ReceiptInvoiceBL.TryDeserializeOpenTransInvoice - durchsetzende Stelle für Import
 Prüfidee:      Gültige ebInterface-XML deserialisiert ohne Fehler; ungültige XML liefert `Result.FromException`.
 Tracelinks:    StRS-004, SwRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: Sonderfall - Österreich-spezifisches Format
 Status:        belegt
 ---
 ID:            SyRS-026
 Titel:         Online-Banking via FinAPI mit Konto-Transaktionsabgleich [Abrechnung]
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Buchhaltung
 Vorbedingung:  Kontoverknüpfung eingerichtet, Rechte vergeben
 Fakt:          BL-Klassen `OnlineBankingFinApiBL`, `OnlineBankingAccountTransactionsBL`, `OnlineBankingConfigurationBL`; API-Projekt `Centron.APIs.FinAPI`; Rechtegruppe `Controlling.Finances.OnlineBanking` (`VIEW_BANKSTATEMENT` 20800147, `VIEW_ONLY_OWN_BRANCH_BANKSTATEMENT`, `DELETE_BANKSTATEMENT`, `CHANGE_BANKSTATEMENT_ASSIGNMENT`, `IMPORT_BANKSTATEMENT_MANUELLY`); Tabellen `Zahlungseingang`, `ZahlungseingangLog`.
 Aussage:       Das System soll Kontoauszüge via FinAPI abrufen, manuell importieren lassen und mit Zahlungseingängen abgleichen; Sichtbarkeit und Zuordnung werden rechtegesteuert, auf Filiale begrenzt wählbar.
 Ergebnis:      Automatisierte Zahlungseingangserfassung mit Audit.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/{OnlineBankingFinApiBL,OnlineBankingAccountTransactionsBL}.cs - durchgesetzte Klassen-Struktur
  - [PRIMÄR]   UserRightsConst.cs `OnlineBanking`-Block IDs 20800147-20800151 - Begründung: durchgesetzte Rechte
  - [SEKUNDÄR] SSMS `[dbo].[Zahlungseingang]`, `[dbo].[ZahlungseingangLog]` - Begründung: Persistenz mit Log
 Prüfidee:      Bankstatement ohne Recht nicht sichtbar; importiertes Statement liefert `ZahlungseingangLog`-Eintrag.
 Tracelinks:    StRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-027
 Titel:         Artikeldatenintegrationen (ITscope, Icecat, COP, EGIS, Distributoren)
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Einkauf, Vertrieb
 Vorbedingung:  Zugang konfiguriert
 Fakt:          API-Projekte `Centron.APIs.ITscopeDataAccess`, `Centron.APIs.IcecatDataAccess`, `Centron.APIs.CopDataAccess`, `Centron.APIs.EgisDataAccess`; Tabellen `ArticleImports`, `ArticleImportMappings`, `ArticleImportLogs`, `ArticleImportDistributors`, `ArticleImportField`; HostedService `ArticleImportService` und `AutomaticPriceUpdateService`.
 Aussage:       Das System soll Artikelstammdaten und Preise ausmarktüblichen Katalogquellen/Distributoren importieren, über Mappings integrieren und zeitgesteuert aktualisieren.
 Ergebnis:      Katalogpflege eingespart; aktuelle Einkaufspreise.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `ArticleImportService`, `AutomaticPriceUpdateService` (durchsetzende Stelle)
  - [SEKUNDÄR] Verzeichnis src/apis/*DataAccess und SSMS `[dbo].[ArticleImports]` - Begründung: Integrationsprojekte und Import-Tabellen
 Prüfidee:      Import liefert Logeintrag; Mappings abbildbar.
 Tracelinks:    StRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - wettbewerbskritisch
 Status:        belegt
 ---
 ID:            SyRS-028
 Titel:         Versanddienstleisterintegration (GLS, Shipcloud) mit Paketvorlagen
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Lager
 Vorbedingung:  -
 Fakt:          API-Projekte `Centron.Api.Gls`, `Centron.Api.Shipcloud`; `ShipcloudPackageTemplateBL` (BL Sales/Receipts); Recht `RIGHT_CLICKABRIGHTNUNG` (Clickabrechnung) indirekt für Versandlabels nicht vorhanden (kein eigenes Label-Recht).
 Aussage:       Das System soll Paketscheine über GLS und Shipcloud aus Belegen heraus erstellen können; Paketvorlagen standardisieren den Versand.
 Ergebnis:      Logistikprozess ohne Medienbruch.
 Belege:
  - [SEKUNDÄR] src/apis/Centron.Api.Gls, Centron.Api.Shipcloud - Begründung: dedizierte Integrationsprojekte
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ShipcloudPackageTemplateBL.cs - durchgesetzte Vorlagenlogik
 Prüfidee:      Paketvorlage erzeugt Label-Anfrage (Mock-Test).
 Tracelinks:    StRS-001
 Konsolidierung: Kandidat: zwei getrennte Carrier-Integrationen mit derselben fachlichen Funktion („Paketlabel") - im Ziel in Abstraktionschicht
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-029
 Titel:         Password-Manager für Kunden mit Richtlinien und Export [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        MSP-Techniker
 Vorbedingung:  Lizenz
 Fakt:          Rechtegruppe `UserRightsConst.PasswordManager` (ID 20800011): `ACCESS_GUIDELINE_MANAGEMENT`, `ACCESS_AREA_MANAGEMENT`, `EXPORT_ACCESS_AND_PASSWORD_DATA`; `PasswordManagerBL.ValidateUserRights(userI3D)` (Zeilen 228/246/266/761); BL-Verzeichnisse `PasswordManager`, `PasswordManagementArea`.
 Aussage:       Das System soll einen zentralen Passworttresor für Kunden mit Richtlinien- und Bereichsverwaltung bereitstellen; Export sensibler Zugangsdaten ist hinter einem eigenen Recht geschützt.
 Ergebnis:      Zugangsdaten zentral, abgesichert und auditiert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/PasswordManager/PasswordManagerBL.cs: `ValidateUserRights` (durchsetzende Stelle)
  - [PRIMÄR]   UserRightsConst.cs PasswordManager-IDs - Begründung: eigenes Recht für Datenexport
 Prüfidee:      Export ohne `EXPORT_ACCESS_AND_PASSWORD_DATA` wird blockiert.
 Tracelinks:    StRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-030
 Titel:         DSGVO-Ansprechpartnerlöschung und Datenbankbereinigung [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Datenschutzbeauftragter
 Vorbedingung:  DSGVO-Modul lizenziert
 Fakt:          `UserRightsConst.DsgvoModule`: `ACCESS_DSGVO_MODULE` (20800022), `DSGVO_DELETE_CONTACT` (20800023), `ACCESS_CLEANUP_DATABASE` (20800024); HostedService `DocumentsCleanupService` und `DataQualityService` (nicht-terminals DSGVO-spezifisch aber bereinigend).
 Aussage:       Das System soll das Löschen von Ansprechpartnern und die Bereinigung der Datenbank hinter eigenen Rechten ausführen; dokumentierte Bereinigungsdienste sollen Alt- und verwaiste Daten entfernen.
 Ergebnis:      Datensparsamkeit und Löschkonformität betriebsfest.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `DsgvoModule`-Block - durchgesetzte Rechte
  - [SEKUNDÄR] CentronHost.cs: `DocumentsCleanupService` - Begründung: systemseitige Bereinigung
 Prüfidee:      Abruf ohne DSGVO-Recht → unzugänglich; Löschung protokolliert.
 Tracelinks:    StRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - gesetzlich
 Status:        belegt
 ---
 ID:            SyRS-031
 Titel:         WebCart-Shop mit Sonderpreisen für Endkunden
 Ebene:         SyRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Endkunde (Web-Account)
 Vorbedingung:  Web-Account aktiv; Sonderpreise gepflegt
 Fakt:          README: „The available articles come from the customers 'Sonderpreise'"; Blazor-Seiten `WebCartShopPage.razor`, `WebCartCartPage.razor` (52.175 Bytes mit Preisanzeige und Warenkorb), `WebCartAdminPage.razor`; `AddressContactPersonWebAccountRequests`-Tabelle.
 Aussage:       Das System soll einen Endkunden-Shop bereitstellen, der ausschließlich Artikel anzeigt, für die der zugehörige Kunde Sonderpreise definiert hat, und Warenkorb/Bestellung annimmt.
 Ergebnis:      Bindung des Sortiments an die kundenindividuelle Konditionenpflege.
 Belege:
  - [KONTEXT]  README.md (WebCart-Absatz) - Begründung: fachliche Regel
  - [SEKUNDÄR] src/nexus/CentronNexus/WebCart/{WebCartShopPage,WebCartCartPage,WebCartAdminPage}.razor - Begründung: Umsetzung
  - [PRIMÄR]   SSMS `[dbo].[AddressContactPersonWebAccountRequests]` - Begründung: Web-Account-Entität
 Prüfidee:      Artikel ohne Sonderpreis des Kunden erscheint nicht im Shop des Accounts.
 Tracelinks:    StRS-011, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-032
 Titel:         KI-Assistenz mit Rechtebindung [Sicherheit]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        Mitarbeiter
 Vorbedingung:  KI-Modul lizenziert
 Fakt:          Rechtegruppe `ArtificialIntelligence` (ID 20800167) mit `ADD_FILES`, `WEB_SEARCH`, `INTERACTIVE_MODE`, `MODEL_SELECTION`, `UNRESTRICTED_ACCESS`; Tabellen `ArtificialIntelligencePromptCategory`, `ArtificialIntelligencePromptSettings`.
 Aussage:       Das System soll KI-Fähigkeiten (Datei-Upload, Websuche, interaktiver Modus, Modellwahl, uneingeschränkter Zugriff) einzeln rechtebinden; uneingeschränkter Zugriff ist ein besonderes Hochrisiko-Recht.
 Ergebnis:      Gestufte KI-Nutzung nach Notwendigkeit.
 Belege:
  - [PRIMÄR]   UserRightsConst.cs `ArtificialIntelligence`-Block - durchgesetzte Rechte-Matrix
  - [SEKUNDÄR] SSMS `[dbo].[ArtificialIntelligencePromptSettings]` - Begründung: Prompt-Konfiguration
 Prüfidee:      Benutzer ohne `WEB_SEARCH` kann Websuche nicht anstoßen.
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - sicherheitskritische Dimension
 Status:        belegt
 ---
 ID:            SyRS-033
 Titel:         Dokumentenmanagement mit Verzeichnis-/Datei-Rechten [Berechtigung]
 Ebene:         SyRS
 Typ:           Sicherheit
 Qualitätsmerkmal: Sicherheit
 Akteur:        alle
 Vorbedingung:  Dateiablage konfiguriert
 Fakt:          `UserRightsConst.Sales.Documents` und `Sales.Cashbox/Dokumente`: `DELETE_DOCUMENTS` (20400074), `CHANGE_DOCUMENTS` (20400075), `READ_DOCUMENTS` (20400076), `ADD_DOCUMENTS` (20400077), `ADD_DIRECTORY` (20400078), `DELETE_DIRECTORY` (20400079), `MOVE_DIRECTORY` (20400080), `RENAME_DIRECTORY` (20400081); BL `Administration/FileManagement/DirectoryBL.cs` prüft Account-Bearbeitungsrechte beim Schreibschutz von Verzeichnissen (`hasNoRight = ... ValidateUserRights(..., getAccount:true)`).
 Aussage:       Das System soll Dateien und Verzeichnisse im ERP kontextbezogen (Kunde/Lieferant) verwalten und Lese-/Schreib-/Verzeichnisrechte getrennt vergeben; Metadaten-Änderungsbeschränkungen binden an Geschäftsrechte (z. B. nur bei `EDIT_SUPPLIER`).
 Ergebnis:      Granulare Schutz der Ablage.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/FileManagement/DirectoryBL.cs Zeilen 391/403 (Aufruf von `AccountBL.ValidateUserRights(...)` als Rechtegatter) - durchsetzende Stelle
  - [PRIMÄR]   UserRightsConst.cs Documents-IDs - Begründung: Rechte-Matrix
 Prüfidee:      Verzeichnis im Lieferantenkontext öffnen ohne `getAccount:true`-Recht → blockiert.
 Tracelinks:    StRS-011, StRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-034
 Titel:         SMS-/SignalR-Nexus-Benachrichtigungen
 Ebene:         SyRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        alle Benutzer
 Vorbedingung:  Nexus-Verbindung
 Fakt:          `CentronHost`-Konstruktor: `NotificationsHubHelper.SendNexusNotification = notification => NotificationsHub.SendNotification(notification);`; eigene `SecretKey`-Policy mit `SecretKeyRequirement(nexusConnectionKey)` und `SecretKeyHandler`; Blazor-Host `CentronNexus.Host`.
 Aussage:       Das System soll interne Ereignisse (Tickets, MyDay) über SignalR an angeschlossene Nexus-Clients streuen; Nexus-Verbindungen sind über konfigurierten SecretKey abgesichert.
 Ergebnis:      Echtzeit-Updates ohne Polling; Vertraulichkeit bei internem Kanal.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `AddPolicy("SecretKey", policy => policy.Requirements.Add(new SecretKeyRequirement(nexusConnectionKey)))` (durchsetzende Stelle)
  - [PRIMÄR]   CentronHost.cs: `NotificationsHubHelper.SendNexusNotification`-Zuweisung - durchsetzende Stelle
 Prüfidee:      Nexus ohne SecretKey → 403; Ticketereignis erzeugt SignalR-Nachricht (Integrationstest).
 Tracelinks:    StRS-013
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-035
 Titel:         End-to-End-Testsatz und Integrations-Tests
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit (Prüfbarkeit)
 Akteur:        Entwicklung/QA
 Vorbedingung:  -
 Fakt:          Verzeichnisse `tests/backend`, `tests/apis`, `tests/shared`, `tests/Centron.Tests.EndToEnd`, `tests/Centron.Tests.Integration`, `tests/PlaywrightTests`, `tests/CentronNexusTests`; `DunningRunWebServiceBL` enthält `EndToEndTestMode`-Property.
 Aussage:       Das System soll schichtübergreifende automatisierte Tests (Unit via backend/shared, API-Tests, Integrationstests, End-to-End- und UI-Tests mit Playwright) bereithalten; bestimmte BLs sollen im E2E-Modus ohne Nebenwirkungen ausführbar sein.
 Ergebnis:      Automatisierte Qualitätsabsicherung über Releasegrenzen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/WebServices/Sales/Receipts/DunningRunWebServiceBL.cs: `EndToEndTestMode { get; set; }` - durchgesetzte Stelle
  - [SEKUNDÄR] Verzeichnisliste tests/* - Begründung: Testinfrastruktur
 Prüfidee:      CI-Lauf der Integrationstestsuite mit isolierter Test-DB.
 Tracelinks:    StRS-015
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
 ID:            SyRS-036
 Titel:         REST-Hilfeseiten und begrenztes Swagger
 Ebene:         SyRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Wartbarkeit/Sicherheit
 Akteur:        Integrationen
 Vorbedingung:  `ActivateHelpPage` aktiv
 Fakt:          `CentronHost`: Swagger wird nur registriert, wenn `WebServiceConfigHelper.Current?.ActivateHelpPage == true`; Hilfsseiten über `MapCentronWelcomePage` und `MapCentronHelpPage` geroutet.
 Aussage:       Das System soll API-Dokumentation (Swagger/HelpPage) konfigurierbar bereitstellen; bei deaktiviertem Hilfsseiten-Flag bleibt die Metadatenoberfläche abgeschaltet.
 Ergebnis:      Angreifsfläche geringer bei geschlossener Doku.
 Belege:
  - [PRIMÄR]   CentronHost.cs: `if (...ActivateHelpPage == true) { f.AddEndpointsApiExplorer(); f.AddCentronSwaggerGen(); }` sowie entsprechend `UseSwagger()`/`UseCentronSwaggerUI()` (durchsetzende Stelle)
 Prüfidee:      `ActivateHelpPage=false` → /swagger nicht erreichbar.
 Tracelinks:    SyRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen
 Status:        belegt
 ---
@@ -0,0 +1,35 @@
 # Traceability-Tabelle (Forward und Backward)
 # StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg (datei-kurz)
 | StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
 |---|---|---|---|
 | StRS-001 | SyRS-001, SyRS-007, SyRS-035 | SwRS-001, SwRS-014 | CentronHost.cs; Centron.sln; DAO/*.cs |
 | StRS-002 | SyRS-003, SyRS-004, SyRS-005, SyRS-009, SyRS-018 | SwRS-007, SwRS-022 | UserRightsConst.cs; TicketBL.cs; JwtAuthController.cs; CentronRights.md |
 | StRS-003 | SyRS-009 | SwRS-005 | UserRightsConst.cs (SHOW_*_ONLY_OWN_BRANCH); CentronRights.md |
 | StRS-004 | SyRS-010, SyRS-011, SyRS-012, SyRS-013, SyRS-015, SyRS-025 | SwRS-003, SwRS-009, SwRS-010, SwRS-011, SwRS-012 | ReceiptBL.cs; ReceiptInvoiceBL.CancelInvoice/FixInvoice; ReceiptState.cs; SSMS (AngKopf..GutPos, *Versions) |
 | StRS-005 | SyRS-016, SyRS-022 | SwRS-010 | ReceiptInvoiceBL.CancelInvoice (IsContractInvoice/ResetContract); CentronHost.cs (ContractEndeService/ContractCloseService); SSMS Vertrag* |
 | StRS-006 | SyRS-018(Hinweis), SyRS-021(DAM), SyRS-026(Zeit), SyRS-030(DSGVO indirekt) | SwRS-017, SwRS-018, SwRS-021, SwRS-030, SwRS-031 | hlpdsk_*-Tabellen; CentronRights.md; EscalationsService; ValidateHelpdeskFingerprintService; TicketPatterns |
 | StRS-007 | SyRS-010, SyRS-017 | SwRS-011 | ReceiptItemTimerBL.RemoveTimers; CentronRights.md Nr. 8/9 |
 | StRS-008 | SyRS-014, SyRS-015, SyRS-026, SyRS-040 | SwRS-020 | DunningRunBL/DunningRunWebServiceBL; Mahnlauf; Zahlungseingang; Kostenstellen |
 | StRS-009 | SyRS-019, SyRS-020, SyRS-021, SyRS-028 | SwRS-013 | UserRightsConst (StockList/Inventory/SerialAdministration); SSMS ARTIK, Barcode, BestKopf2, WareKopf, KalkKopf |
 | StRS-010 | SyRS-024 | SwRS-006, SwRS-016 | AssetBL, MasterDataListBL; GeraeteKopf; AssetManagementDevices |
 | StRS-011 | SyRS-031, SyRS-033 | SwRS-016, SwRS-039 | README.md WebCart; WebCartShopPage.razor; AddressContactPersonWebAccountRequests; DirectoryBL |
 | StRS-012 | SyRS-030, SyRS-029 | SwRS-040 (verwandt) | UserRightsConst DsgvoModule/PasswordManager; PasswordManagerBL.ValidateUserRights |
 | StRS-013 | SyRS-034, SyRS-008(Hintergrundkommunikation) | SwRS-026, SwRS-037 | CentronHost.cs (NotificationsHub-, Send*Services); ArtificialIntelligence-Prompt-Tabellen |
 | StRS-014 | SyRS-023, SyRS-041 | SwRS-Ext(n/a) | ArticleProductionOrders; APlan*; ProductionBL |
 | StRS-015 | SyRS-008, SyRS-027, SyRS-035 | SwRS-027, SwRS-028, SwRS-029 | tests/*; DataQualityService; Analytics-Rechte; ChangeTracking |
 # Forward-Sicht SyRS -> SwRS (Auszug der SyRS ohne eigenen StRS-Parent-Eintrag oben):
 | SyRS-ID | SwRS-ID | Artefaktbeleg |
 |---|---|---|
 | SyRS-001 | SwRS-001, SwRS-014, SwRS-023 | CentronHost.cs; WPF-Projekt; DAO |
 | SyRS-002 | SwRS-015, SwRS-023 | Controllers/v1; CentronHost.cs AddCentronApiVersioning |
 | SyRS-006 | SwRS-024 | CentronHost.cs TryLoadLicense/SetupDatabaseConnection |
 | SyRS-008 | SwRS-027, SwRS-028 | CentronHost.cs HostedServices |
 | SyRS-022 | SwRS-006 (Gerätebezug) | ContractEndeService; VertragGeraete |
 | SyRS-036 | SwRS-019, SwRS-023 | CentronHost.cs ActivateHelpPage |
 | SyRS-037 | SwRS-003 (Belegart-Modell) | Rma; WPF Rma-Modul |
 | SyRS-038 | SwRS-003 (CRM-Daten in Legacy-Tabellen) | Sonderaktionen*, CRMProjekt* |
 | SyRS-039 | SwRS-001 (Transact. Persistenz) | EDI*BLs; EdiDownloadService |
 | SyRS-040 | SwRS-020 (Stammdat-Tabellen) | Kostenstellen, Zahkond |
 | SyRS-042 | SwRS-004 (Accounts-Modell) | ProjectBL.cs; ProjectPriceImport |
@@ -0,0 +1,94 @@
 # Messprotokoll – Versuch 01 – Prompt-Version 02
 ## Lauf
 - **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
 - **Prompt-Version:** 02
 - **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
 - **Startzeit:** 2026-08-28T07:28:25Z
 - **Endzeit:** 2026-08-28T08:05:42Z
 - **Dauer gesamt:** 37:17 (parallel zu Lauf A)
 - **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
 - **Codebasis-Commit:** `37275c96` (dirty: nein)
 - **Parallele Läufe:** ja – Lauf A (`z-ai/glm-5.2/builtin/high/092819_v8.0.0-4650`) lief zeitgleich
 ## Werkzeugkonfiguration
 - **Skill-Version:** v8.0.0
 - **Werkzeugadapter:** Python API (TensorX Gateway), Adapter v1.1.0
 - **Modell (angefordert):** `moonshotai/kimi-k3`
 - **Modelle (tatsächlich eingesetzt):** `moonshotai/kimi-k3` (100 %)
 - **Kontrolle Modell:** bestanden
 - **Effort:** high (Kimi `reasoning_effort` = `high`)
 - **Laufverzeichnis-ID:** `v8.0.0-09b6`
 - **Ablage:** `Iteration 6/moonshotai/kimi-k3/solo/high/`
 - **Agentenmodus:** solo (V1) – keine Subagenten
 - **Subagenten:** 0 (solo: korrekt)
 ## Verbrauch
 | Messgröße | Wert |
 |---|---:|
 | Input-Tokens | 3.333.339 |
 | Output-Tokens | 109.640 |
 | davon Reasoning-Tokens | 10.213 |
 | Cache-Read-Tokens | 3.120.640 |
 | **Tokens gesamt** | **3.442.979** |
 | Agent-Turns | 50 (max_turns erreicht) |
 | Tool-Calls | 84 (23× list_directory, 21× execute_command, 18× search_files, 9× read_file, 13× write_file) |
 **Hinweis:** Wanduhrzeit ist durch Parallelbetrieb verzerrt und nicht für Laufzeitvergleiche verwendbar.
 ## Gefundene Anforderungen
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 15 | 19,0 % |
 | SyRS | 36 | 45,6 % |
 | SwRS | 28 | 35,4 % |
 | **Gesamt** | **79** | 100 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 171 |
 | davon `PRIMÄR` | 102 (59,6 %) |
 | davon `SEKUNDÄR` | 58 (33,9 %) |
 | davon `KONTEXT` | 11 (6,4 %) |
 | Anforderungen mit mind. einem `PRIMÄR`-Beleg | 79 (100,0 %) |
 ### Status
 | Kategorie | Anzahl |
 |---|---:|
 | belegt | 79 (100 %) |
 | `HYPOTHESE` | 0 (0,0 %) |
 | Konsolidierungskandidaten | 9 (11,4 %) |
 ### Übernahmewürdigkeit
 | Einstufung | Anzahl |
 |---|---:|
 | übernehmen | 70 (88,6 %) |
 | Workaround | 6 (7,6 %) |
 | Sonderfall | 1 (1,3 %) |
 | veraltet | 2 (2,5 %) |
 ### Regelkonformität
 | Vorgabe | Ergebnis |
 |---|---|
 | Belegpflicht | **erfüllt** (0 ohne Beleg) |
 | Risikobasierte Priorisierung | **erfüllt** (31 risikorelevant, alle gedeckt) |
 | Verifizierbarkeit | **erfüllt** |
 | Übernahmewürdigkeit | **erfüllt** (alle 79) |
 | Traceability | 79/79 (100 %) |
 ## Ergebnis
 - **Status:** erfolgreich
 - **Gültigkeit:** gültig – 9 Ergebnisdateien, Stderr.log ohne Abbruch
 - **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SwRS-Ergaenzungen.md, SyRS.md, SyRS-Ergaenzungen.md, Traceability.md
 - **Root unverändert:** ja
 - **Anmerkungen:**
  - 50 Turns = max_turns erreicht — der Agent nutzte die volle Kapazität
  - 100 % Primärbeleg-Quote — alle 79 Anforderungen haben mindestens einen PRIMÄR-Beleg
  - 0 Hypothesen — auffällig; der Prompt verlangt bei Codebasen dieser Größe mindestens eine. In der Selbstbewertung sollte dies begründet werden.
  - Tool-Nutzung ausgewogen: list_directory (23), execute_command (21), search_files (18), read_file (9), write_file (13) — breitere Erkundung als GLM-solo (88× list_directory)
  - 2 Ergänzungsdateien (SwRS-Ergaenzungen.md, SyRS-Ergaenzungen.md) — nicht im Prompt vorgesehen, aber inhaltlich zulässig
  - Cache-Trefferquote: 93,5 % (3.120.640 von 3.333.339 Input-Tokens)
@@ -0,0 +1,13 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T07:28:25.625856+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-28T08:05:42.676616+00:00
 [glm-kimi-adapter] Turns: 50
 [glm-kimi-adapter] Tokens gesamt: 3,442,979
 [glm-kimi-adapter] Tool-Calls: 84
 [glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
 [glm-kimi-adapter] Ergebnisdateien: 9
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\moonshotai\kimi-k3\solo\high\02_Lauf_2026-08-28_092820_v8.0.0-09b6\RawResult.json
@@ -0,0 +1 @@
@@ -0,0 +1,65 @@
 ## Gefundene Anforderungen
 Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
 Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 15 | 19,0 % |
 | SyRS | 36 | 45,6 % |
 | SwRS | 28 | 35,4 % |
 | **Gesamt** | **79** | 100 % |
 ### Anforderungstypen
 | Typ | Anzahl | Anteil |
 |---|---:|---:|
 | funktional | 30 | 38,0 % |
 | Sicherheit | 16 | 20,3 % |
 | Daten | 16 | 20,3 % |
 | Schnittstelle | 9 | 11,4 % |
 | nicht-funktional | 8 | 10,1 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 171 |
 | davon `PRIMÄR` | 102 (59,6 %) |
 | davon `SEKUNDÄR` | 58 (33,9 %) |
 | davon `KONTEXT` | 11 (6,4 %) |
 | Belege je Anforderung (Median) | 2 |
 | Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 79 (100,0 %) |
 ### Übernahmewürdigkeit
 | Einstufung | Anzahl | Anteil |
 |---|---:|---:|
 | übernehmen | 70 | 88,6 % |
 | workaround | 6 | 7,6 % |
 | sonderfall | 1 | 1,3 % |
 | veraltet | 2 | 2,5 % |
 ### Status
 | Kategorie | Anzahl | Anteil |
 |---|---:|---:|
 | belegt | 79 | 100,0 % |
 | als `HYPOTHESE` gekennzeichnet | 0 | 0,0 % |
 | als Workaround vermerkt | 0 | 0,0 % |
 | Konsolidierungskandidaten | 9 | 11,4 % |
 | mit ISO-25010-Qualitätsmerkmal | 24 | 30,4 % |
 ### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
 | Vorgabe | Ergebnis |
 |---|---|
 | **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
 | **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (31 risikorelevante Anforderungen, alle gedeckt) |
 | **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
 | **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 79 Anforderungen eingestuft) |
 | **Traceability** – Verknüpfung zwischen den Ebenen | 79 von 79 mit Tracelinks (100,0 %) |
@@ -0,0 +1 @@
@@ -0,0 +1,181 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 02
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-26
 - **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
 - **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Nicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $laufB\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T10:05:42.7024716+02:00
@@ -0,0 +1 @@
 2026-08-28T09:28:20.3929596+02:00
@@ -0,0 +1,421 @@
 Timestamp,API Key,Model,App,Tokens In,Cache Read,Tokens Out,Cost,Speed (tps),Status,Request ID
 "28.8.2026, 08:57:36","Kimmi","z-ai/glm-5.2","ai-sdk","265292","263744","1002","$0.105735","187.3","success","ea60ca142ce44d47a7f8378b1806e27a"
 "28.8.2026, 08:57:33","Kimmi","z-ai/glm-5.2","ai-sdk","263439","262528","328","$0.101291","150.3","success","9b8e20c851624e74952ce22c4b7a7a1c"
 "28.8.2026, 08:57:26","Kimmi","z-ai/glm-5.2","ai-sdk","261700","260992","849","$0.102754","206.1","success","951f0ce788b74baf827b49bb46c4ff3f"
 "28.8.2026, 08:57:24","Kimmi","z-ai/glm-5.2","ai-sdk","260916","260736","116","$0.098568","82.0","success","9e43fd771c29457cb6d660a27e8cb78b"
 "28.8.2026, 08:57:13","Kimmi","z-ai/glm-5.2","ai-sdk","258829","257408","1940","$0.107389","238.7","success","b7d8689342df4d66b61fd5b641976308"
 "28.8.2026, 08:57:06","Kimmi","z-ai/glm-5.2","ai-sdk","256972","256000","446","$0.099465","135.1","success","3c605c5bf9de4825871c4dccb4379460"
 "28.8.2026, 08:57:02","Kimmi","z-ai/glm-5.2","ai-sdk","255765","255232","684","$0.099589","190.7","success","9c242e2fe0474f48891d8343812c8f34"
 "28.8.2026, 08:54:58","Kimmi","z-ai/glm-5.2","ai-sdk","254961","254464","318","$0.097601","151.1","success","4695edc16941410e998196bbb7743078"
 "28.8.2026, 08:52:19","Kimmi","moonshotai/kimi-k3","python-requests","185310","184832","738","$0.151128","60.6","success","701dd63fa6b742749b3e47da72d894e3"
 "28.8.2026, 08:51:55","Kimmi","z-ai/glm-5.2","ai-sdk","254130","253824","348","$0.097209","154.7","success","e6a33092bc5d43ed8727e4fa873b816a"
 "28.8.2026, 08:51:52","Kimmi","z-ai/glm-5.2","ai-sdk","253580","253056","273","$0.096910","140.4","success","56cb71c4347742ce95aeba2dd0807d4b"
 "28.8.2026, 08:48:58","Kimmi","moonshotai/kimi-k3","python-requests","176601","174592","8659","$0.266856","43.3","success","3040c089518040dc8207bf7fd439fa07"
 "28.8.2026, 08:48:28","Kimmi","moonshotai/kimi-k3","python-requests","174856","169472","1697","$0.168711","58.2","success","b5bfca87bf4844418ed165ef9c36c577"
 "28.8.2026, 08:47:03","Kimmi","moonshotai/kimi-k3","python-requests","169891","136704","4877","$0.275244","57.8","success","7d5baeb7c05d41f592879713ba1ea68b"
 "28.8.2026, 08:46:48","Kimmi","z-ai/glm-5.2","ai-sdk","252743","252352","361","$0.096843","143.0","success","46efe43dd2cd482683b52d6f1d11e3f2"
 "28.8.2026, 08:46:38","Kimmi","z-ai/glm-5.2","ai-sdk","252096","251776","321","$0.096340","34.9","success","a68ed9a354454c11aa0d8a1df077ff81"
 "28.8.2026, 08:42:33","Kimmi","moonshotai/kimi-k3","python-requests","153708","137216","16135","$0.394413","59.9","success","2b1a0434bce841868c0b2c2ec7e98dc3"
 "28.8.2026, 08:41:34","Kimmi","z-ai/glm-5.2","ai-sdk","251507","251200","303","$0.096024","130.3","success","13902b4972134f278d58513c042d6255"
 "28.8.2026, 08:41:31","Kimmi","z-ai/glm-5.2","ai-sdk","250957","250432","292","$0.096013","124.1","success","513c6d527e6c45d7bd829754bc6e514a"
 "28.8.2026, 08:38:06","Kimmi","moonshotai/kimi-k3","python-requests","137260","75264","16398","$0.488406","61.6","success","75412613c6114bcfbb2e6dfb79a0a670"
 "28.8.2026, 08:36:19","Kimmi","z-ai/glm-5.2","ai-sdk","250124","249536","358","$0.096069","33.1","success","0d34b330997346fda2711da3ba28e885"
 "28.8.2026, 08:34:18","Kimmi","moonshotai/kimi-k3","python-requests","122860","122368","14352","$0.308532","63.3","success","14409cc0b55b43bc847b9a79f1cbc439"
 "28.8.2026, 08:31:15","Kimmi","z-ai/glm-5.2","ai-sdk","249228","248896","364","$0.095472","114.2","success","116b3143fc2545c4839e74b75de7b687"
 "28.8.2026, 08:31:11","Kimmi","z-ai/glm-5.2","ai-sdk","248616","248064","335","$0.095359","115.5","success","b69e2d482d614a908b432c02ae0a9224"
 "28.8.2026, 08:30:40","Kimmi","moonshotai/kimi-k3","python-requests","108990","108544","13822","$0.290076","63.5","success","333409a7e60443c3b1249f13bcf25200"
 "28.8.2026, 08:26:48","Kimmi","moonshotai/kimi-k3","python-requests","95480","78336","13462","$0.312114","58.1","success","58407044d0ac4694b56f062d18be6f8b"
 "28.8.2026, 08:26:07","Kimmi","z-ai/glm-5.2","ai-sdk","247705","247104","421","$0.095460","152.7","success","9df08fb7c4a34b00b00f056ae7a5f377"
 "28.8.2026, 08:25:58","Kimmi","z-ai/glm-5.2","ai-sdk","246825","246528","325","$0.094356","40.4","success","9a72cbedd465464c95adda8530ef608c"
 "28.8.2026, 08:21:30","Kimmi","moonshotai/kimi-k3","python-requests","78432","65024","17000","$0.343992","53.7","success","3e8fa6f468384907880d6f9fb0fc838d"
 "28.8.2026, 08:21:26","Kimmi","moonshotai/kimi-k3","python-requests","75578","74240","188","$0.062514","54.8","success","d0dfb8a3b3e34ef4a7b205ca74f00846"
 "28.8.2026, 08:20:59","Kimmi","moonshotai/kimi-k3","python-requests","73558","57344","1180","$0.109350","60.6","success","75584cf67ccd4d86bb7ec096d56e6e31"
 "28.8.2026, 08:20:54","Kimmi","z-ai/glm-5.2","ai-sdk","246158","245312","380","$0.094971","140.1","success","ffea55e37b854acea0b69c0e5ef99cca"
 "28.8.2026, 08:20:47","Kimmi","moonshotai/kimi-k3","python-requests","64590","62976","563","$0.060519","57.7","success","741b519ecc5946ff84126b6e14ee25ea"
 "28.8.2026, 08:20:29","Kimmi","z-ai/glm-5.2","ai-sdk","245285","","319","$0.369363","13.6","success","1c49439109ae4e17bfb734dce0d6cfe3"
 "28.8.2026, 08:20:26","Kimmi","moonshotai/kimi-k3","python-requests","62217","60928","1199","$0.067548","59.8","success","3be7b42b37da411f8d70bcb53f8df6b3"
 "28.8.2026, 08:20:06","Kimmi","moonshotai/kimi-k3","python-requests","60268","57856","1089","$0.066963","56.4","success","51896d15db5b4d58b8e1bd1a6f1963ee"
 "28.8.2026, 08:20:01","Kimmi","moonshotai/kimi-k3","python-requests","58188","33792","105","$0.100107","26.6","success","9582711988084f60b6c92cd74685aed1"
 "28.8.2026, 08:19:39","Kimmi","moonshotai/kimi-k3","python-requests","57113","32768","572","$0.106191","51.5","success","bbd01a6e882442779348833d539ffb60"
 "28.8.2026, 08:19:34","Kimmi","moonshotai/kimi-k3","python-requests","33599","32768","227","$0.030474","57.7","success","68ad5b3bac7a45d894109c56c31a7fc3"
 "28.8.2026, 08:19:28","Kimmi","moonshotai/kimi-k3","python-requests","32992","19456","137","$0.057255","45.2","success","7edb2f07a5514ce99c2c9071f1371dee"
 "28.8.2026, 08:19:24","Kimmi","moonshotai/kimi-k3","python-requests","32571","31744","217","$0.029544","54.1","success","2d875cd51cbe43aaaf31b054e68f978d"
 "28.8.2026, 08:18:59","Kimmi","moonshotai/kimi-k3","python-requests","30733","13312","1359","$0.082632","56.3","success","b9acbf21d9a7425c861c8ad4c71a3ca4"
 "28.8.2026, 08:18:48","Kimmi","moonshotai/kimi-k3","python-requests","19220","10752","619","$0.042753","56.5","success","f4a004d1b95a48e9bfdf0745c410343d"
 "28.8.2026, 08:18:43","Kimmi","moonshotai/kimi-k3","python-requests","48001","44032","216","$0.048171","53.8","success","cb71dda0a94d444c9c058a40442ce760"
 "28.8.2026, 08:18:37","Kimmi","moonshotai/kimi-k3","python-requests","46134","39424","244","$0.053358","51.2","success","cfffaf4f7f8840cea5d591108b5a690d"
 "28.8.2026, 08:18:31","Kimmi","moonshotai/kimi-k3","python-requests","43932","43520","267","$0.037881","59.4","success","5dba0bb0ea874298bb89162c1aadda7c"
 "28.8.2026, 08:18:26","Kimmi","moonshotai/kimi-k3","python-requests","43415","41984","216","$0.039021","58.0","success","164bd84526ce473ebd81e64d7644f643"
 "28.8.2026, 08:18:22","Kimmi","moonshotai/kimi-k3","python-requests","41794","38912","221","$0.041145","57.5","success","2675a79d05f04a9eb85d766e4e1e3bbb"
 "28.8.2026, 08:18:16","Kimmi","moonshotai/kimi-k3","python-requests","39676","35328","237","$0.043095","52.3","success","942cc68be11343c48fddea9fcd85cb88"
 "28.8.2026, 08:18:11","Kimmi","moonshotai/kimi-k3","python-requests","39137","38400","199","$0.033996","57.4","success","6357dc731c234b319dc8f2157c37e999"
 "28.8.2026, 08:18:06","Kimmi","moonshotai/kimi-k3","python-requests","38486","37376","198","$0.034332","57.7","success","ceac54ce8ce34ec3877df47f9c9ba596"
 "28.8.2026, 08:17:59","Kimmi","moonshotai/kimi-k3","python-requests","37476","35840","393","$0.037683","60.5","success","dc00415f39a141a6aa02905816647c37"
 "28.8.2026, 08:17:51","Kimmi","moonshotai/kimi-k3","python-requests","35808","3584","339","$0.104445","48.4","success","61ff7d1c8377465a97f815d58a33b2d7"
 "28.8.2026, 08:17:39","Kimmi","moonshotai/kimi-k3","python-requests","35324","1536","429","$0.108951","43.4","success","a82cb09b4ec842fd8cd62acc8072862e"
 "28.8.2026, 08:17:35","Kimmi","moonshotai/kimi-k3","python-requests","3477","2048","193","$0.008718","60.8","success","3e8b6d938ac84ee39c42c9e99fa5653b"
 "28.8.2026, 08:17:32","Kimmi","moonshotai/kimi-k3","python-requests","2250","1024","197","$0.007401","60.8","success","2cb97b7a994e4ded8893e60418ce5842"
 "28.8.2026, 08:17:29","Kimmi","moonshotai/kimi-k3","python-requests","1707","512","112","$0.005649","49.0","success","0b3c96544f6c4976969daa1bfe4730f8"
 "28.8.2026, 08:17:25","Kimmi","moonshotai/kimi-k3","python-requests","1283","512","174","$0.005307","60.8","success","b1cec4156c4643ad94e9a7ba3ec89fe2"
 "28.8.2026, 08:17:20","Kimmi","moonshotai/kimi-k3","python-requests","31315","28672","257","$0.033288","47.0","success","92c652abae1c499cb6bf659fb42e5928"
 "28.8.2026, 08:17:15","Kimmi","moonshotai/kimi-k3","python-requests","30902","24576","211","$0.040575","52.4","success","af8f98956fc3407fa7bb6ad72e424365"
 "28.8.2026, 08:17:09","Kimmi","moonshotai/kimi-k3","python-requests","28896","28160","248","$0.027048","49.4","success","90d740bfe47e4558bb6465f2a9890c17"
 "28.8.2026, 08:17:01","Kimmi","moonshotai/kimi-k3","python-requests","28114","26112","358","$0.030960","48.3","success","0ec9d7fd22cd43ea9574945ac7ce2934"
 "28.8.2026, 08:16:57","Kimmi","moonshotai/kimi-k3","python-requests","25948","16384","213","$0.044175","49.3","success","2e49a81cdddc43a999c39a0554dc0d3b"
 "28.8.2026, 08:16:53","Kimmi","moonshotai/kimi-k3","python-requests","24546","20480","180","$0.030258","55.2","success","2e871d1b26a8477d9c4e41be4d140f22"
 "28.8.2026, 08:16:47","Kimmi","moonshotai/kimi-k3","python-requests","20701","14336","196","$0.032787","54.7","success","7ccaf532856944c59bfa61cd891b391a"
 "28.8.2026, 08:16:44","Kimmi","moonshotai/kimi-k3","python-requests","16558","12288","154","$0.024336","54.7","success","98429058d3ee49dca96e0ca5bfe80093"
 "28.8.2026, 08:16:39","Kimmi","moonshotai/kimi-k3","python-requests","14114","7680","228","$0.028482","57.1","success","5fe847fe240446a2b1a554f1d7c03c5a"
 "28.8.2026, 08:16:34","Kimmi","moonshotai/kimi-k3","python-requests","12439","6656","280","$0.026541","58.2","success","cdd3e2c50d674be7890bc27dc986305a"
 "28.8.2026, 08:16:29","Kimmi","moonshotai/kimi-k3","python-requests","7756","2560","106","$0.019098","25.2","success","eadffff7aee9407299b7305a2a311394"
 "28.8.2026, 08:16:24","Kimmi","moonshotai/kimi-k3","python-requests","6658","1536","263","$0.020463","58.7","success","31d227fc1e4b40dfbe64838b1771ac30"
 "28.8.2026, 08:16:22","Kimmi","moonshotai/kimi-k3","python-requests","2647","1024","99","$0.007122","56.7","success","79cc2b1bb58a42d8b1575b1fede16793"
 "28.8.2026, 08:16:19","Kimmi","moonshotai/kimi-k3","python-requests","1788","512","166","$0.006702","59.5","success","04c7ddd86d824ddaad22c7fd67ddecb8"
 "28.8.2026, 08:16:17","Kimmi","moonshotai/kimi-k3","python-requests","1319","512","90","$0.004155","52.3","success","d4cc7553d7b14dea9701dc088dd83eb5"
 "28.8.2026, 08:16:13","Kimmi","moonshotai/kimi-k3","python-requests","50989","49664","182","$0.043953","54.1","success","a293187d9e684dabbbe7cff411a1a454"
 "28.8.2026, 08:16:08","Kimmi","moonshotai/kimi-k3","python-requests","49785","47616","272","$0.046299","57.4","success","9680555aa00445698e9177369e0c4e60"
 "28.8.2026, 08:16:03","Kimmi","moonshotai/kimi-k3","python-requests","47651","44032","227","$0.047286","55.4","success","12aaaccd28e340b8abe81877c78a042b"
 "28.8.2026, 08:15:53","Kimmi","moonshotai/kimi-k3","python-requests","43663","35328","549","$0.059736","58.2","success","339eece83b2d427785e0c478ac22a666"
 "28.8.2026, 08:15:47","Kimmi","moonshotai/kimi-k3","python-requests","40489","31232","322","$0.056025","56.7","success","d74e7c21aae943b6b5dd4d3f5ff75423"
 "28.8.2026, 08:15:44","Kimmi","moonshotai/kimi-k3","python-requests","35498","26624","105","$0.048165","42.1","success","31e6008cdbdf4f2485bc9ba9113933d0"
 "28.8.2026, 08:15:35","Kimmi","moonshotai/kimi-k3","python-requests","31214","9216","471","$0.079971","53.9","success","9f712df135e0491782de8e1de51b6b97"
 "28.8.2026, 08:15:31","Kimmi","moonshotai/kimi-k3","python-requests","26657","20480","149","$0.036126","51.2","success","715df6f70b2a423594246df859f324c5"
 "28.8.2026, 08:15:25","Kimmi","z-ai/glm-5.2","ai-sdk","244587","243648","411","$0.094626","127.1","success","e491d2dda3084cff89a53d1182541db4"
 "28.8.2026, 08:15:22","Kimmi","z-ai/glm-5.2","ai-sdk","243508","243008","151","$0.092558","70.6","success","1266b2534aac4f139ed88a0dcb33917d"
 "28.8.2026, 08:15:21","Kimmi","moonshotai/kimi-k3","python-requests","20149","14848","569","$0.035574","59.3","success","3ce47c1e40454b01bc199868dc65abc1"
 "28.8.2026, 08:15:16","Kimmi","moonshotai/kimi-k3","python-requests","14907","4096","275","$0.039630","55.6","success","1adfc5fc0a384146b489a5ae8212b2e9"
 "28.8.2026, 08:15:13","Kimmi","moonshotai/kimi-k3","python-requests","9297","1024","101","$0.027102","45.2","success","4f5b43317a27441db9bf8b9f65b708b1"
 "28.8.2026, 08:15:09","Kimmi","moonshotai/kimi-k3","python-requests","3986","3072","185","$0.007821","59.1","success","08fc8e4e61f74ed88a8ad55df8c852a5"
 "28.8.2026, 08:15:01","Kimmi","moonshotai/kimi-k3","python-requests","2753","2048","434","$0.010161","54.1","success","095746bfcf0d4c1bbc9ea2f0ced50fba"
 "28.8.2026, 08:14:52","Kimmi","moonshotai/kimi-k3","python-requests","1798","512","471","$0.011307","59.4","success","d5e83a7fa29447c899b14de9e8c611c1"
 "28.8.2026, 08:14:50","Kimmi","moonshotai/kimi-k3","python-requests","1017","512","62","$0.002829","53.9","success","345b1096aab640a69035c7e88f615c7d"
 "28.8.2026, 08:14:48","Kimmi","moonshotai/kimi-k3","python-requests","59246","55296","79","$0.054507","43.3","success","d10efeda6e0e4cc492941632d203f205"
 "28.8.2026, 08:14:45","Kimmi","moonshotai/kimi-k3","python-requests","59111","57344","104","$0.049869","49.5","success","79fa6084b6d245d48d2632ceb94fefc5"
 "28.8.2026, 08:14:39","Kimmi","moonshotai/kimi-k3","python-requests","57171","54272","302","$0.053931","58.4","success","4582033daf0c475a8517124721be5f79"
 "28.8.2026, 08:14:35","Kimmi","moonshotai/kimi-k3","python-requests","55538","53760","132","$0.047634","50.2","success","97087297e0d44e369db266735f703a77"
 "28.8.2026, 08:14:32","Kimmi","moonshotai/kimi-k3","python-requests","54229","49664","85","$0.052218","44.7","success","a71987d7fa54424a97eed476fb05b97a"
 "28.8.2026, 08:14:24","Kimmi","moonshotai/kimi-k3","python-requests","53680","46080","389","$0.063195","57.4","success","c8dfc41e7293453ebbe85de0b4853b42"
 "28.8.2026, 08:14:13","Kimmi","moonshotai/kimi-k3","python-requests","49365","6656","514","$0.140829","49.9","success","e8322f35c1444751bdb173ca8e6c8c53"
 "28.8.2026, 08:14:11","Kimmi","moonshotai/kimi-k3","python-requests","46379","43520","108","$0.042837","50.4","success","c6068102af214e91b3dd3c955a5ef1a1"
 "28.8.2026, 08:14:03","Kimmi","moonshotai/kimi-k3","python-requests","43559","33792","410","$0.060795","57.5","success","58049e0b471746739f4e61d7c06b11ab"
 "28.8.2026, 08:13:56","Kimmi","moonshotai/kimi-k3","python-requests","33506","31232","293","$0.034641","58.7","success","27f6f8fc4fb44adca4f7864061255b6a"
 "28.8.2026, 08:13:52","Kimmi","moonshotai/kimi-k3","python-requests","31457","30208","190","$0.029253","50.6","success","0217359a529149a2a3896acc2121e36d"
 "28.8.2026, 08:13:46","Kimmi","moonshotai/kimi-k3","python-requests","30391","2048","263","$0.090510","45.4","success","9b9cd1f4484c48008789fde031b8adaf"
 "28.8.2026, 08:13:38","Kimmi","moonshotai/kimi-k3","python-requests","6863","1024","218","$0.021555","58.0","success","b9c1a514fa0c49d98af40cb2d3ffae40"
 "28.8.2026, 08:13:34","Kimmi","moonshotai/kimi-k3","python-requests","1852","512","194","$0.007314","60.0","success","653dce62ca144c18aad64736b2fbd000"
 "28.8.2026, 08:13:28","Kimmi","moonshotai/kimi-k3","python-requests","1114","512","388","$0.008010","63.2","success","c4204842f2e443ba8e3ec2c301481fdf"
 "28.8.2026, 08:13:20","Kimmi","moonshotai/kimi-k3","python-requests","58835","36864","350","$0.098811","50.4","success","186783a36d08450784ba82995e784a0a"
 "28.8.2026, 08:13:16","Kimmi","moonshotai/kimi-k3","python-requests","55043","53248","197","$0.048276","55.7","success","7dbe720bdc33424e9719cb1c80f54e63"
 "28.8.2026, 08:13:09","Kimmi","moonshotai/kimi-k3","python-requests","53046","47616","417","$0.058257","59.1","success","6e05ae6eaf3141adb5635dd4eae67b2f"
 "28.8.2026, 08:13:05","Kimmi","moonshotai/kimi-k3","python-requests","47528","43520","145","$0.046839","52.3","success","3edfeb3ddf69459d9f7df6bc0066e5fa"
 "28.8.2026, 08:12:58","Kimmi","moonshotai/kimi-k3","python-requests","43367","40960","440","$0.044541","61.2","success","938d4d0f704e436ba5b6e7cbb0e33409"
 "28.8.2026, 08:12:19","Kimmi","moonshotai/kimi-k3","python-requests","40923","4608","323","$0.117246","42.0","success","f19d0a77628f4a45acfa99fc4290bc0b"
 "28.8.2026, 08:12:13","Kimmi","moonshotai/kimi-k3","python-requests","37089","34816","241","$0.036546","50.2","success","101b1b6f2e2540418f9ab1567788b2c2"
 "28.8.2026, 08:12:04","Kimmi","moonshotai/kimi-k3","python-requests","34635","4096","392","$0.100569","47.4","success","60c57b0647b541d18a9f9c0af131c570"
 "28.8.2026, 08:10:18","Kimmi","z-ai/glm-5.2","ai-sdk","242660","242176","359","$0.093158","117.2","success","ddf07ba5846b4a10988ff141ef90bf4b"
 "28.8.2026, 08:10:14","Kimmi","z-ai/glm-5.2","ai-sdk","241946","241408","242","$0.092424","93.8","success","29fa3fb39340452a8622cbb67a80707e"
 "28.8.2026, 08:06:56","Kimmi","moonshotai/kimi-k3","python-requests","4389","3072","249","$0.009990","61.0","success","bf3ea144d0ed41c1afb96192cf2f99c3"
 "28.8.2026, 08:06:51","Kimmi","moonshotai/kimi-k3","python-requests","3842","2560","305","$0.010341","61.3","success","df9b165adbb44d23b7abca4c489f8415"
 "28.8.2026, 08:06:45","Kimmi","moonshotai/kimi-k3","python-requests","3061","2048","306","$0.009165","57.9","success","f2058651517f4171befb066df11975f2"
 "28.8.2026, 08:06:41","Kimmi","moonshotai/kimi-k3","python-requests","2646","1536","207","$0.007587","60.5","success","671a01d7987e4de8800ad66f210b894a"
 "28.8.2026, 08:06:37","Kimmi","moonshotai/kimi-k3","python-requests","2077","1024","169","$0.006462","56.1","success","4a04521f9b09421e926630087d10f52c"
 "28.8.2026, 08:06:35","Kimmi","moonshotai/kimi-k3","python-requests","1876","512","137","$0.006531","58.5","success","f63f916d08d742d9a6bf17beccd7c99a"
 "28.8.2026, 08:06:33","Kimmi","moonshotai/kimi-k3","python-requests","1095","512","62","$0.003063","49.3","success","f1433ef16aa3460297243681ecf6ef55"
 "28.8.2026, 08:06:27","Kimmi","moonshotai/kimi-k3","python-requests","118034","88576","210","$0.157956","38.1","success","416efab5b049460aa8f7b0d90ba5af3b"
 "28.8.2026, 08:06:22","Kimmi","moonshotai/kimi-k3","python-requests","113929","105472","225","$0.107850","47.7","success","8d81fc8f8ccd469ba7d47bda843bab73"
 "28.8.2026, 08:06:13","Kimmi","moonshotai/kimi-k3","python-requests","105643","68096","333","$0.168708","40.6","success","bf1820247c6c4af5bc4a6115e69b125d"
 "28.8.2026, 08:06:00","Kimmi","moonshotai/kimi-k3","python-requests","88122","51200","564","$0.157626","49.5","success","84af25ae6b374c9191db4a1413202d37"
 "28.8.2026, 08:05:10","Kimmi","z-ai/glm-5.2","ai-sdk","241118","240512","339","$0.092627","123.9","success","9293f8c1f59d48c38040035bea794388"
 "28.8.2026, 08:03:05","Kimmi","moonshotai/kimi-k3","python-requests","68143","13824","105","$0.174900","20.9","success","6d978f757b5349a6914c41c6e3e140cc"
 "28.8.2026, 08:03:00","Kimmi","moonshotai/kimi-k3","python-requests","51204","13824","78","$0.123678","21.7","success","980da4629de84cb2a4cf42477adc6701"
 "28.8.2026, 08:02:06","Kimmi","z-ai/glm-5.2","ai-sdk","240229","239808","329","$0.092040","112.5","success","30010e69cf014f65a59735be2cd0e444"
 "28.8.2026, 08:01:35","Kimmi","moonshotai/kimi-k3","python-requests","14217","7680","104","$0.026931","48.2","success","c82b494f69474333acf5a35087d9ff74"
 "28.8.2026, 08:01:31","Kimmi","moonshotai/kimi-k3","python-requests","13887","3584","220","$0.036897","54.1","success","94c4a61bd2ef4689886c8c5060933777"
 "28.8.2026, 08:01:28","Kimmi","moonshotai/kimi-k3","python-requests","7915","3072","106","$0.018423","52.6","success","52991781a9a94d46a1940a0423234257"
 "28.8.2026, 08:01:25","Kimmi","moonshotai/kimi-k3","python-requests","3519","2560","145","$0.006972","54.4","success","e7575e8c3b0d4f14b486cc30ad73a8fa"
 "28.8.2026, 08:01:21","Kimmi","moonshotai/kimi-k3","python-requests","3060","2048","205","$0.007647","60.8","success","4a373c1050bb421baa5b50127b606a71"
 "28.8.2026, 08:01:18","Kimmi","moonshotai/kimi-k3","python-requests","2659","1024","170","$0.008223","54.9","success","efe20c7bbe5742bc9cc1d23458810d45"
 "28.8.2026, 08:01:14","Kimmi","moonshotai/kimi-k3","python-requests","2049","1536","170","$0.005241","59.6","success","1ddf5ddf6aca4d9cadcd12d86cf1825e"
 "28.8.2026, 08:01:09","Kimmi","moonshotai/kimi-k3","python-requests","1877","512","108","$0.006099","24.6","success","4930df2a84ea4ddb9fd12415c078043e"
 "28.8.2026, 08:01:08","Kimmi","moonshotai/kimi-k3","python-requests","1096","512","62","$0.003066","53.5","success","de478d994b0e4efb925fc1c659598df8"
 "28.8.2026, 08:01:04","Kimmi","moonshotai/kimi-k3","python-requests","51507","47616","165","$0.049860","53.6","success","63001e6ab2c84242a98b83719582dffd"
 "28.8.2026, 08:01:02","Kimmi","moonshotai/kimi-k3","python-requests","47755","44032","104","$0.045753","49.0","success","b302a8e2f88d46b79252cbdd31544e6b"
 "28.8.2026, 08:00:02","Kimmi","z-ai/glm-5.2","ai-sdk","239579","239040","291","$0.091758","112.3","success","ca5305d35b524ce094e170d54e48d1b1"
 "28.8.2026, 07:59:59","Kimmi","z-ai/glm-5.2","ai-sdk","238787","238528","288","$0.091133","111.8","success","d2ce20fe7a134037810d6aee89ef6624"
 "28.8.2026, 07:59:46","Kimmi","moonshotai/kimi-k3","python-requests","45618","43008","186","$0.042876","52.1","success","156d70c3bf7d49569979654e64e3e451"
 "28.8.2026, 07:59:44","Kimmi","moonshotai/kimi-k3","python-requests","43993","43008","65","$0.036186","39.0","success","4cdff12072f64f32bd72d5d2a9e780c7"
 "28.8.2026, 07:59:39","Kimmi","moonshotai/kimi-k3","python-requests","43215","42496","197","$0.036984","49.8","success","5c6a708ba4784787b87ee3663a8b35a0"
 "28.8.2026, 07:59:37","Kimmi","moonshotai/kimi-k3","python-requests","43008","40448","106","$0.039606","44.4","success","42552385080543d79679617358080054"
 "28.8.2026, 07:59:34","Kimmi","moonshotai/kimi-k3","python-requests","42868","42496","84","$0.034248","49.1","success","83192d16981042748860d3f23868e886"
 "28.8.2026, 07:59:29","Kimmi","moonshotai/kimi-k3","python-requests","42529","39936","263","$0.041676","58.1","success","6808ec4d790444598f1bc21f8e3f5622"
 "28.8.2026, 07:59:23","Kimmi","moonshotai/kimi-k3","python-requests","40331","3584","237","$0.116484","37.1","success","2d20a1848ac94a719db9a05639b1fdde"
 "28.8.2026, 07:59:19","Kimmi","moonshotai/kimi-k3","python-requests","40085","39424","136","$0.033591","54.3","success","ede5b4a52b11464ea4d2806064ebb8b3"
 "28.8.2026, 07:59:13","Kimmi","moonshotai/kimi-k3","python-requests","39188","2560","279","$0.115989","43.6","success","714e818e217843cbb56a47e5ebb6a570"
 "28.8.2026, 07:58:34","Kimmi","moonshotai/kimi-k3","python-requests","3438","2048","302","$0.010236","58.7","success","c4fa24df02fe465e88d3a932af01056d"
 "28.8.2026, 07:58:31","Kimmi","moonshotai/kimi-k3","python-requests","2672","1024","180","$0.008412","55.5","success","8b848a178db9400f824999cee9cb1d50"
 "28.8.2026, 07:58:27","Kimmi","moonshotai/kimi-k3","python-requests","2096","","206","$0.009378","56.8","success","d5d1c5f251ee4ea38865550cf929df52"
 "28.8.2026, 07:58:24","Kimmi","moonshotai/kimi-k3","python-requests","1146","","137","$0.005493","55.1","success","8b00fde8046042f09f840fc76bcd4282"
 "28.8.2026, 07:58:20","Kimmi","moonshotai/kimi-k3","python-requests","42858","39936","154","$0.041028","50.5","success","d321d2e9f0a24d46897e748603927a43"
 "28.8.2026, 07:58:16","Kimmi","moonshotai/kimi-k3","python-requests","42096","39936","203","$0.039477","52.8","success","d8982cf0061e443ab961a0ac027ab1ed"
 "28.8.2026, 07:58:12","Kimmi","moonshotai/kimi-k3","python-requests","40202","24064","128","$0.068382","40.0","success","2a09cc7f2b3840668c2a1847b7ef9e98"
 "28.8.2026, 07:58:09","Kimmi","moonshotai/kimi-k3","python-requests","40049","39936","97","$0.031746","47.6","success","c2e77cb9c33048c7ba80e97aa5d914ca"
 "28.8.2026, 07:58:06","Kimmi","moonshotai/kimi-k3","python-requests","39814","37376","125","$0.037221","49.0","success","611ec2139b924f869d530f07304e1263"
 "28.8.2026, 07:58:01","Kimmi","moonshotai/kimi-k3","python-requests","37656","19968","209","$0.071175","44.1","success","793b88a60e50442fb1ab56c0e1025ec1"
 "28.8.2026, 07:57:57","Kimmi","moonshotai/kimi-k3","python-requests","24088","15872","153","$0.038847","45.9","success","1649469f4d9c4f46a47e3a1bb158a31e"
 "28.8.2026, 07:57:54","Kimmi","moonshotai/kimi-k3","python-requests","20030","12800","114","$0.033000","46.0","success","78574be95b39464cb1bf595063c4467d"
 "28.8.2026, 07:57:50","Kimmi","moonshotai/kimi-k3","python-requests","16114","12288","156","$0.023034","51.9","success","9c13974c035c4fc3b1a461dc335fb6fe"
 "28.8.2026, 07:57:46","Kimmi","moonshotai/kimi-k3","python-requests","12766","7168","192","$0.025050","48.0","success","94b95d071ae84229b009a95de5dae66b"
 "28.8.2026, 07:57:42","Kimmi","moonshotai/kimi-k3","python-requests","12366","11264","173","$0.014349","54.1","success","4a22141168404ceaa27aa6d5047dd03d"
 "28.8.2026, 07:57:38","Kimmi","moonshotai/kimi-k3","python-requests","11187","2560","199","$0.030786","51.3","success","0c2d9f415334416094a4046506efc3fa"
 "28.8.2026, 07:57:34","Kimmi","moonshotai/kimi-k3","python-requests","7363","1536","196","$0.021573","56.8","success","93621ebdd19b45f398620f428455e026"
 "28.8.2026, 07:57:28","Kimmi","moonshotai/kimi-k3","python-requests","2598","","275","$0.011919","57.1","success","1901391585f544619c823a81225a09f7"
 "28.8.2026, 07:57:22","Kimmi","moonshotai/kimi-k3","python-requests","1187","","360","$0.008961","61.9","success","bcd1d0b2e330471db8f7eb1d92782352"
 "28.8.2026, 07:55:46","Kimmi","moonshotai/kimi-k3","python-requests","13384","7680","5565","$0.106347","58.5","success","839570da726f491e8e8d08e12567f9fc"
 "28.8.2026, 07:55:11","Kimmi","moonshotai/kimi-k3","python-requests","9183","512","1943","$0.055542","56.3","success","3aad38f97b324e13ae68e30655fa95a9"
 "28.8.2026, 07:55:09","Kimmi","moonshotai/kimi-k3","python-requests","7942","7168","85","$0.008973","48.6","success","18fe19b8b3e94e609b70d3bcd12e0dc9"
 "28.8.2026, 07:55:05","Kimmi","moonshotai/kimi-k3","python-requests","7312","6656","210","$0.010110","51.2","success","45759213d5eb4caeb00e2f7ac9f7efbb"
 "28.8.2026, 07:55:03","Kimmi","moonshotai/kimi-k3","python-requests","7187","","57","$0.022416","39.0","success","54146c57ee87455698732d7cbf367e53"
 "28.8.2026, 07:54:59","Kimmi","moonshotai/kimi-k3","python-requests","6680","512","142","$0.021018","49.4","success","44df0e1be94e4aaa8e1b766286078d0e"
 "28.8.2026, 07:54:54","Kimmi","z-ai/glm-5.2","ai-sdk","238173","237888","398","$0.091426","132.2","success","768d71ff6b9b4112ba0c9daedc438c49"
 "28.8.2026, 07:54:47","Kimmi","z-ai/glm-5.2","ai-sdk","236828","236672","1117","$0.094012","194.1","success","0aa6a057881a4ba681c0b3b57624ebc0"
 "28.8.2026, 07:54:41","Kimmi","z-ai/glm-5.2","ai-sdk","236457","236224","237","$0.090000","78.2","success","5d8c5b1c50e54b698d17c998d65930d2"
 "28.8.2026, 07:54:39","Kimmi","z-ai/glm-5.2","ai-sdk","236142","236032","94","$0.089100","52.0","success","61667fe28a90492ba73a75306ceb349c"
 "28.8.2026, 07:54:35","Kimmi","z-ai/glm-5.2","ai-sdk","235899","235776","149","$0.089271","62.6","success","fa54690fd3cf44bbaca94f45cc20bbd7"
 "28.8.2026, 07:54:30","Kimmi","z-ai/glm-5.2","ai-sdk","235502","235136","296","$0.090057","121.9","success","655dc9a2006246ab9e6949ecb3d577f8"
 "28.8.2026, 07:54:27","Kimmi","z-ai/glm-5.2","ai-sdk","235065","234880","93","$0.088776","45.8","success","d30ecf0feb61436a87cfe61cb002ff2f"
 "28.8.2026, 07:54:24","Kimmi","z-ai/glm-5.2","ai-sdk","234799","234432","129","$0.089043","56.5","success","1e82b03463734ec9a063be4ce3ccfe29"
 "28.8.2026, 07:54:19","Kimmi","z-ai/glm-5.2","ai-sdk","234172","233920","309","$0.089489","119.1","success","35237e099675458a8d180587210ec3c3"
 "28.8.2026, 07:54:16","Kimmi","z-ai/glm-5.2","ai-sdk","233850","233728","84","$0.088209","41.7","success","c79df0410182483a8adb97734f105d7f"
 "28.8.2026, 07:54:12","Kimmi","z-ai/glm-5.2","ai-sdk","233557","233280","201","$0.088800","85.0","success","88dc491a84cc41009f6251ee1e450540"
 "28.8.2026, 07:54:08","Kimmi","z-ai/glm-5.2","ai-sdk","233105","232320","188","$0.089144","70.3","success","6bf9521231a34bebba002a536f45373b"
 "28.8.2026, 07:54:00","Kimmi","z-ai/glm-5.2","ai-sdk","231331","230656","1010","$0.092054","182.8","success","9a937e9a83c54900a81e355e8a175250"
 "28.8.2026, 07:53:57","Kimmi","z-ai/glm-5.2","ai-sdk","230562","230208","141","$0.087494","66.1","success","05d8e2de72174bbbab97237043a5e26c"
 "28.8.2026, 07:53:51","Kimmi","z-ai/glm-5.2","ai-sdk","229945","229568","304","$0.088021","111.7","success","96584dcc3b564d82ad697cd7ac343bbe"
 "28.8.2026, 07:53:48","Kimmi","z-ai/glm-5.2","ai-sdk","229458","229056","122","$0.087048","63.2","success","362fe91ebd3b447d8c5d1a4cd1083f54"
 "28.8.2026, 07:53:42","Kimmi","z-ai/glm-5.2","ai-sdk","228539","228096","527","$0.088572","143.1","success","b6163a0e9ce643139ff8e2bc5415b84d"
 "28.8.2026, 07:53:39","Kimmi","z-ai/glm-5.2","ai-sdk","228023","227840","123","$0.086268","62.1","success","730c5f7ffa6543f088952e89f9053987"
 "28.8.2026, 07:53:34","Kimmi","z-ai/glm-5.2","ai-sdk","227658","227136","242","$0.087048","81.6","success","669bc261fbe94ee0886d211a14a80268"
 "28.8.2026, 07:53:30","Kimmi","z-ai/glm-5.2","ai-sdk","226997","226816","182","$0.086147","74.1","success","2145a6ae1a5940729ff87f73c604a75c"
 "28.8.2026, 07:53:25","Kimmi","z-ai/glm-5.2","ai-sdk","226551","226240","283","$0.086580","88.2","success","215a79b817494a41bb2c83f4a46e107f"
 "28.8.2026, 07:53:22","Kimmi","z-ai/glm-5.2","ai-sdk","226162","225664","83","$0.085745","45.3","success","9149090ed3e049d39f234c8dfd2d9a0c"
 "28.8.2026, 07:53:19","Kimmi","z-ai/glm-5.2","ai-sdk","225614","223616","112","$0.087357","58.1","success","ae29605a68714c7993b16831465e2234"
 "28.8.2026, 07:53:07","Kimmi","z-ai/glm-5.2","ai-sdk","222267","221888","1413","$0.090135","154.6","success","4640a22ff6784ba3806f5be382421131"
 "28.8.2026, 07:53:05","Kimmi","z-ai/glm-5.2","ai-sdk","221892","221312","56","$0.084114","34.4","success","1bc7a05d23214421b74afc1a1f948889"
 "28.8.2026, 07:53:02","Kimmi","z-ai/glm-5.2","ai-sdk","221194","220096","133","$0.084781","64.5","success","f5a1629ebfc848638900a6bb35b250a3"
 "28.8.2026, 07:52:54","Kimmi","z-ai/glm-5.2","ai-sdk","219154","218112","964","$0.087693","170.0","success","ae1592b015a941a4b4ba63313418ff03"
 "28.8.2026, 07:52:51","Kimmi","z-ai/glm-5.2","ai-sdk","218024","217920","95","$0.082304","53.5","success","2044f5c59784424c94232280ea261112"
 "28.8.2026, 07:52:47","Kimmi","z-ai/glm-5.2","ai-sdk","217751","217664","171","$0.082524","66.3","success","e99f26eee7c94cd5a3902f779cd60008"
 "28.8.2026, 07:52:39","Kimmi","z-ai/glm-5.2","ai-sdk","216590","216448","1091","$0.086291","183.3","success","69a6381322dd49fcba6fe864f5235907"
 "28.8.2026, 07:52:36","Kimmi","z-ai/glm-5.2","ai-sdk","216340","216256","120","$0.081762","62.5","success","f505d1d803b140a19007590df55059d0"
 "28.8.2026, 07:52:31","Kimmi","z-ai/glm-5.2","ai-sdk","215924","215616","346","$0.082875","125.0","success","9a075c1231a346519e20fced87de49eb"
 "28.8.2026, 07:52:27","Kimmi","z-ai/glm-5.2","ai-sdk","215484","214912","191","$0.082309","75.4","success","f6f53f551333442ca5f14840e3ba8dab"
 "28.8.2026, 07:52:18","Kimmi","z-ai/glm-5.2","ai-sdk","213755","211840","1219","$0.087798","192.1","success","ba7276fff7ff4b7bac8f17cc6e8238ae"
 "28.8.2026, 07:52:15","Kimmi","z-ai/glm-5.2","ai-sdk","211766","210944","120","$0.080877","64.7","success","6c0c3aaa73a04a1ca51d22a3850ff8bd"
 "28.8.2026, 07:52:05","Kimmi","z-ai/glm-5.2","ai-sdk","210267","170048","707","$0.127278","75.4","success","4e0c5d593e0a40b296fdcbf74f4a9e83"
 "28.8.2026, 07:50:42","Kimmi","z-ai/glm-5.2","ai-sdk","217762","217408","977","$0.086456","182.4","success","810d276302614af9995a8b2321ba389a"
 "28.8.2026, 07:50:38","Kimmi","z-ai/glm-5.2","ai-sdk","217063","215488","381","$0.084885","125.7","success","e08dcd1c060a4cfa8ba5dd92df80edc7"
 "28.8.2026, 07:50:34","Kimmi","z-ai/glm-5.2","ai-sdk","215227","214848","314","$0.082549","122.6","success","94c8441cf871428b8ce6d3b2339b2cf2"
 "28.8.2026, 07:50:30","Kimmi","z-ai/glm-5.2","ai-sdk","214853","214592","124","$0.081422","45.7","success","ed3a49022c7e43b68e0c00fd750d527e"
 "28.8.2026, 07:50:24","Kimmi","z-ai/glm-5.2","ai-sdk","214277","213632","328","$0.082556","123.7","success","28de542fa4ae4d439ffcc61234d975ca"
 "28.8.2026, 07:50:22","Kimmi","z-ai/glm-5.2","ai-sdk","213681","213248","90","$0.081022","49.3","success","87850c2375734abca89873757315f63c"
 "28.8.2026, 07:50:17","Kimmi","z-ai/glm-5.2","ai-sdk","213049","212480","212","$0.081487","54.3","success","17def0c59c5b4ce6a7c0260d04d0894a"
 "28.8.2026, 07:50:09","Kimmi","z-ai/glm-5.2","ai-sdk","211725","211200","801","$0.083592","169.5","success","0cd2a3a80759476fa32bd93484a2c717"
 "28.8.2026, 07:50:05","Kimmi","z-ai/glm-5.2","ai-sdk","210853","209920","405","$0.081942","120.8","success","aa9cc4391c9044c18661563f3ad5d8d3"
 "28.8.2026, 07:49:59","Kimmi","z-ai/glm-5.2","ai-sdk","209929","209600","298","$0.080434","113.0","success","40b052ceccb24f8ebf34ff065fd4bc1a"
 "28.8.2026, 07:49:54","Kimmi","z-ai/glm-5.2","ai-sdk","209091","208000","527","$0.082008","142.4","success","ce608ba84ab5466bbb39903f91b46189"
 "28.8.2026, 07:49:47","Kimmi","z-ai/glm-5.2","ai-sdk","208012","206720","895","$0.083486","200.7","success","ff23b8a2a707418ca56a9d8c88d6bafe"
 "28.8.2026, 07:49:44","Kimmi","z-ai/glm-5.2","ai-sdk","206588","206400","144","$0.078330","75.7","success","a432fa9d3a6b4ea885403b1249ed660a"
 "28.8.2026, 07:49:36","Kimmi","z-ai/glm-5.2","ai-sdk","205294","205056","1147","$0.082415","214.6","success","626a53d3732148779271abddab909f1b"
 "28.8.2026, 07:49:23","Kimmi","z-ai/glm-5.2","ai-sdk","202145","200960","3025","$0.090750","244.5","success","9a4f741bddc846acbc5b7373c786f80a"
 "28.8.2026, 07:49:18","Kimmi","z-ai/glm-5.2","ai-sdk","200342","198976","680","$0.079725","175.9","success","3da65b817c214c13b1f9d891e975a86c"
 "28.8.2026, 07:48:41","Kimmi","z-ai/glm-5.2","ai-sdk","198565","192832","443","$0.082905","134.9","success","c8845482a92849548fae8a9c07c88630"
 "28.8.2026, 07:48:36","Kimmi","z-ai/glm-5.2","ai-sdk","192015","188864","819","$0.079236","183.4","success","232324405a7245189241027fcbd1232c"
 "28.8.2026, 07:48:33","Kimmi","z-ai/glm-5.2","ai-sdk","188718","187904","182","$0.072504","80.9","success","a86ebfe0656a40c18388f2f0e090182b"
 "28.8.2026, 07:48:27","Kimmi","z-ai/glm-5.2","ai-sdk","187947","187264","612","$0.074003","137.9","success","ac138f4897c24bffab50fded1304f9fd"
 "28.8.2026, 07:48:22","Kimmi","z-ai/glm-5.2","ai-sdk","186705","186304","611","$0.073215","153.8","success","6f78040502074702bf02d5e1f6ded3cb"
 "28.8.2026, 07:47:20","Kimmi","z-ai/glm-5.2","python-requests","169186","169152","778","$0.066984","197.6","success","98f8b41af8aa4f2d92bcdca3e6d4902f"
 "28.8.2026, 07:46:48","Kimmi","z-ai/glm-5.2","ai-sdk","185959","185280","347","$0.072060","130.8","success","d71dceeea223441b8f5c7b19dc6eaafe"
 "28.8.2026, 07:46:45","Kimmi","z-ai/glm-5.2","ai-sdk","185163","184576","164","$0.070835","72.1","success","51da6fbc3a794452a9218bb35c937432"
 "28.8.2026, 07:46:32","Kimmi","z-ai/glm-5.2","python-requests","157924","157888","11239","$0.109838","236.2","success","62749f29841546398bb7a09658f2dabc"
 "28.8.2026, 07:46:23","Kimmi","z-ai/glm-5.2","python-requests","156246","156224","1655","$0.066064","188.7","success","0a8f3c02600549baa3982d5406bcfbb6"
 "28.8.2026, 07:46:21","Kimmi","z-ai/glm-5.2","python-requests","156199","156160","32","$0.058763","26.4","success","46e5a5bb9e404dac92e572b1020f32b7"
 "28.8.2026, 07:46:11","Kimmi","z-ai/glm-5.2","python-requests","154563","153152","1618","$0.066830","182.5","success","36b86a20a4c14677ada017666f4048fd"
 "28.8.2026, 07:46:03","Kimmi","z-ai/glm-5.2","python-requests","153216","152128","1303","$0.064544","174.7","success","06f7723c998c49228c252575ff38623f"
 "28.8.2026, 07:45:57","Kimmi","z-ai/glm-5.2","python-requests","152169","152128","1001","$0.061614","176.0","success","8393e32105bc44d28bd059f920aaed12"
 "28.8.2026, 07:45:49","Kimmi","z-ai/glm-5.2","python-requests","150560","143232","1588","$0.071850","208.8","success","4f4f9de933ae474599b61d48c3fe0547"
 "28.8.2026, 07:45:11","Kimmi","z-ai/glm-5.2","python-requests","142606","130048","7930","$0.103290","211.3","success","7c28904a8ab84d1aa1cf9507d1f9997d"
 "28.8.2026, 07:43:51","Kimmi","z-ai/glm-5.2","python-requests","122834","115200","19753","$0.143539","248.6","success","859b96929ff14c269d9115bc20efebf6"
 "28.8.2026, 07:43:14","Kimmi","z-ai/glm-5.2","python-requests","114204","105472","8607","$0.091382","240.2","success","6a70f6544ffc4a6dbf1ce8720a2b852d"
 "28.8.2026, 07:42:21","Kimmi","z-ai/glm-5.2","python-requests","102886","64960","11304","$0.132117","216.3","success","961201b9bf984ead8b0163e93710228f"
 "28.8.2026, 07:42:19","Kimmi","z-ai/glm-5.2","python-requests","64860","61632","105","$0.028427","90.2","success","ba220afd13d74d0bae97d6ec5703ab88"
 "28.8.2026, 07:42:11","Kimmi","z-ai/glm-5.2","python-requests","61506","","169","$0.093020","33.3","success","407bffa4c41b4b318bd84eb80fd681da"
 "28.8.2026, 07:42:09","Kimmi","z-ai/glm-5.2","python-requests","23794","17664","120","$0.016359","105.9","success","50f4e977445146248f114807360b71f9"
 "28.8.2026, 07:42:08","Kimmi","z-ai/glm-5.2","python-requests","17469","17216","201","$0.007740","174.6","success","8a46ac76a74845ec92dc7ef81661f6f7"
 "28.8.2026, 07:42:06","Kimmi","z-ai/glm-5.2","python-requests","17105","16640","165","$0.007680","187.9","success","e2456c7d18c34474843fba7b6c85604d"
 "28.8.2026, 07:42:05","Kimmi","z-ai/glm-5.2","python-requests","16547","16000","154","$0.007514","163.8","success","41748f128b1e4495b12bd1e83a057fda"
 "28.8.2026, 07:42:03","Kimmi","z-ai/glm-5.2","python-requests","15888","15360","169","$0.007313","115.4","success","92fe771003274c7fb09dd2c5fa286aa1"
 "28.8.2026, 07:42:02","Kimmi","z-ai/glm-5.2","python-requests","15254","15040","129","$0.006541","161.5","success","231d8b5549be43b395cebc00a93b87c9"
 "28.8.2026, 07:42:00","Kimmi","z-ai/glm-5.2","python-requests","14929","13632","144","$0.007706","163.8","success","6984eeff63364f97a9ed53036b88f23e"
 "28.8.2026, 07:41:59","Kimmi","z-ai/glm-5.2","python-requests","13555","13312","97","$0.005793","146.1","success","fff4ad2474e540d59b7eafa6acf8dd79"
 "28.8.2026, 07:41:58","Kimmi","z-ai/glm-5.2","python-requests","13211","12864","122","$0.005894","163.1","success","c5899bb652944f7d9919d7f71c330223"
 "28.8.2026, 07:41:57","Kimmi","z-ai/glm-5.2","python-requests","12777","12096","134","$0.006161","164.2","success","71bf5760d441407f9dd6d902a0e50062"
 "28.8.2026, 07:41:55","Kimmi","z-ai/glm-5.2","python-requests","11969","11584","129","$0.005502","171.8","success","597d52d5048d48acace501028f518e67"
 "28.8.2026, 07:41:54","Kimmi","z-ai/glm-5.2","python-requests","11458","10880","130","$0.005532","151.2","success","0f5575ddbdb04aaa9891643ccf73193a"
 "28.8.2026, 07:41:53","Kimmi","z-ai/glm-5.2","python-requests","10939","10624","105","$0.004929","143.2","success","b0270d73ad294a70a591e00fbde66e88"
 "28.8.2026, 07:41:51","Kimmi","z-ai/glm-5.2","python-requests","10512","9984","119","$0.005071","132.2","success","50cb28bc3c274496be3a086b7ddccce0"
 "28.8.2026, 07:41:49","Kimmi","z-ai/glm-5.2","python-requests","9907","8512","140","$0.005914","101.5","success","524c1b2207c24f0ea7f002c7dd6973a1"
 "28.8.2026, 07:41:48","Kimmi","z-ai/glm-5.2","python-requests","8479","8128","76","$0.003916","141.3","success","73fb922d95e740cbb94a72cf0b434cb0"
 "28.8.2026, 07:41:47","Kimmi","z-ai/glm-5.2","python-requests","8084","5824","92","$0.005988","156.2","success","64bfed909f2c4055a2f77f0fc02bdfcc"
 "28.8.2026, 07:41:46","Kimmi","z-ai/glm-5.2","python-requests","5826","5504","58","$0.002808","126.1","success","d90d9443036549a3863ef9fbf5c4ebd6"
 "28.8.2026, 07:41:45","Kimmi","z-ai/glm-5.2","python-requests","5451","","72","$0.008500","107.1","success","3aa4faedba9a49b9ac655dfe87a354ea"
 "28.8.2026, 07:41:38","Kimmi","z-ai/glm-5.2","ai-sdk","184042","183552","904","$0.073635","143.4","success","64ae931a77fa4cbb85307daea56b4ff4"
 "28.8.2026, 07:41:22","Kimmi","z-ai/glm-5.2","ai-sdk","180668","180608","2902","$0.080877","231.3","success","36c43c0ff07442028db0cada6f6df182"
 "28.8.2026, 07:41:14","Kimmi","z-ai/glm-5.2","ai-sdk","180482","180416","168","$0.068511","80.0","success","ea1192efb5fc467aa03d3ac48513d29b"
 "28.8.2026, 07:40:51","Kimmi","z-ai/glm-5.2","ai-sdk","179991","176768","468","$0.073229","97.0","success","07892514b29c4d00b559df106db1c272"
 "28.8.2026, 07:40:47","Kimmi","z-ai/glm-5.2","ai-sdk","176590","173568","222","$0.070620","83.3","success","479cdbb1eb544e6497b56e6af909ba21"
 "28.8.2026, 07:40:42","Kimmi","z-ai/glm-5.2","ai-sdk","173203","172480","388","$0.067511","105.4","success","5fcc5f3f64e94a6b8213703f44f340d5"
 "28.8.2026, 07:40:38","Kimmi","z-ai/glm-5.2","ai-sdk","172152","171264","392","$0.067320","105.2","success","0936ddbaf67d46a4bf4fa9c64b5c8390"
 "28.8.2026, 07:40:16","Kimmi","z-ai/glm-5.2","ai-sdk","170084","130688","1312","$0.114006","90.4","success","249aee8602214bfab92a67e8e71d36e8"
 "28.8.2026, 07:36:31","Kimmi","z-ai/glm-5.2","ai-sdk","167660","167168","881","$0.067391","189.9","success","6aa3924146644f63ac6dcb4be5a751d0"
 "28.8.2026, 07:36:26","Kimmi","moonshotai/kimi-k3","python-requests","4118","512","241","$0.014817","60.0","success","70a3dbfc5e514877b5db06919b1ef65f"
 "28.8.2026, 07:36:10","Kimmi","moonshotai/kimi-k3","python-requests","3066","","1004","$0.024258","63.7","success","0e14cc475f6a447895a9f35c2e74d55d"
 "28.8.2026, 07:36:09","Kimmi","moonshotai/kimi-k3","python-requests","796","","58","$0.003258","52.7","success","519cb8c25afd4cd28a443bad3cea1fb5"
 "28.8.2026, 07:36:04","Kimmi","z-ai/glm-5.2","ai-sdk","166478","164992","711","$0.067300","184.4","success","b91ecd9254214b5bb1e30d9beb45fb69"
 "28.8.2026, 07:36:02","Kimmi","z-ai/glm-5.2","python-requests","1399","1344","152","$0.001270","151.2","success","c7d96013adec4ab7847caaadebd3c4d9"
 "28.8.2026, 07:36:01","Kimmi","z-ai/glm-5.2","python-requests","1240","768","142","$0.001635","157.1","success","ea62b0a988244a6784e803f6a1800081"
 "28.8.2026, 07:35:59","Kimmi","z-ai/glm-5.2","python-requests","779","","35","$0.001326","58.2","success","e8e322099a4045f8a25e88432e36a50b"
 "28.8.2026, 07:35:55","Kimmi","z-ai/glm-5.2","ai-sdk","164869","163968","452","$0.064874","152.9","success","10cfc8296ad74dc8b1880b262964a96f"
 "28.8.2026, 07:35:49","Kimmi","z-ai/glm-5.2","ai-sdk","163135","162688","873","$0.065607","202.7","success","ddea47a1ddc34a8ebee1971a80cde87c"
 "28.8.2026, 07:35:46","Kimmi","z-ai/glm-5.2","ai-sdk","162648","162560","78","$0.061443","40.1","success","41d88fd46d444625a7774e0af1ee2cd3"
 "28.8.2026, 07:35:43","Kimmi","z-ai/glm-5.2","ai-sdk","162463","159552","112","$0.064703","64.0","success","6ed3cbb512804757bf4b7c31353109b3"
 "28.8.2026, 07:35:20","Kimmi","z-ai/glm-5.2","ai-sdk","156165","153920","3450","$0.076613","166.5","success","0e1c11bbb7874a91b59809cadb2afb14"
 "28.8.2026, 07:35:17","Kimmi","z-ai/glm-5.2","ai-sdk","153861","153728","91","$0.058257","56.7","success","3b95df91e9814546a125defc0d3b0970"
 "28.8.2026, 07:35:15","Kimmi","z-ai/glm-5.2","ai-sdk","153645","153472","86","$0.058199","54.7","success","fc62a29786f64561aea64a2eb7af9c9e"
 "28.8.2026, 07:35:12","Kimmi","z-ai/glm-5.2","ai-sdk","153435","153344","70","$0.057956","45.4","success","989387b3367d4d7c91b114519d994619"
 "28.8.2026, 07:35:10","Kimmi","z-ai/glm-5.2","ai-sdk","153264","152960","104","$0.058284","53.3","success","42ee1662eb3f41df8b9cdbb8b8e8c63c"
 "28.8.2026, 07:35:05","Kimmi","z-ai/glm-5.2","ai-sdk","152716","152512","270","$0.058713","112.5","success","e45cf6e8793e45798b08a30e571b9fec"
 "28.8.2026, 07:35:00","Kimmi","z-ai/glm-5.2","ai-sdk","152221","151936","318","$0.058834","135.4","success","3ec1de46536b42e3b46a9d32ae18d6c3"
 "28.8.2026, 07:34:57","Kimmi","z-ai/glm-5.2","ai-sdk","151787","151424","189","$0.058179","93.7","success","53c17c8f98c8489e9a6244c3134387e3"
 "28.8.2026, 07:34:54","Kimmi","z-ai/glm-5.2","ai-sdk","151333","150720","128","$0.058015","74.7","success","657295c15f714c2b91a1caae1d539c82"
 "28.8.2026, 07:34:47","Kimmi","z-ai/glm-5.2","ai-sdk","150048","149888","698","$0.059589","150.0","success","9c6744f0a29c4992a3854ce575b4593a"
 "28.8.2026, 07:34:42","Kimmi","z-ai/glm-5.2","ai-sdk","149720","149184","187","$0.057590","97.2","success","d04d8a6a63994902bb06d28088934674"
 "28.8.2026, 07:34:40","Kimmi","z-ai/glm-5.2","ai-sdk","149099","147840","94","$0.057751","57.3","success","5088a69bf7234c5f9f8d0df8539e6d34"
 "28.8.2026, 07:29:29","Kimmi","z-ai/glm-5.2","ai-sdk","146852","145984","989","$0.060496","189.4","success","9bd9fb1bd6a64581bc2972175a22d90d"
 "28.8.2026, 07:29:27","Kimmi","z-ai/glm-5.2","ai-sdk","145855","145472","141","$0.055761","75.6","success","6e7b2a2a7b234d1eb38b2c5369f33838"
 "28.8.2026, 07:29:22","Kimmi","z-ai/glm-5.2","ai-sdk","145114","144640","384","$0.056679","149.4","success","aa9d05fe3f7742bc95121b17ce98ac51"
 "28.8.2026, 07:29:19","Kimmi","z-ai/glm-5.2","ai-sdk","144566","143744","107","$0.055619","67.6","success","dd16344347c84ddbaff33c5b053b92f1"
 "28.8.2026, 07:29:13","Kimmi","z-ai/glm-5.2","ai-sdk","143189","142144","586","$0.057508","151.3","success","937d5878af564e3787478161b192c715"
 "28.8.2026, 07:29:11","Kimmi","z-ai/glm-5.2","ai-sdk","142197","141312","80","$0.054680","51.4","success","5ca8dccf425540b898f75ca7eb725d34"
 "28.8.2026, 07:29:05","Kimmi","z-ai/glm-5.2","ai-sdk","141315","140864","526","$0.055868","176.4","success","f63319a31b6d4bb6b1be5b0cb28e3b90"
 "28.8.2026, 07:29:03","Kimmi","z-ai/glm-5.2","ai-sdk","140757","139648","111","$0.054531","62.0","success","3300c21180e34649b81658510e5cd538"
 "28.8.2026, 07:28:54","Kimmi","z-ai/glm-5.2","ai-sdk","138813","138304","857","$0.056484","165.0","success","6198234a65504af2a42900155102b258"
 "28.8.2026, 07:28:50","Kimmi","z-ai/glm-5.2","ai-sdk","137920","137472","414","$0.054087","133.9","success","5d2346e4d733470b827e7aee3bd3ee34"
 "28.8.2026, 07:28:48","Kimmi","z-ai/glm-5.2","python-requests","16","","131","$0.000614","130.1","success","11dd728e535843a49c30bfe6ceab9fd8"
 "28.8.2026, 07:28:48","Kimmi","moonshotai/kimi-k3","python-requests","129","","66","$0.001377","44.6","success","f822474f93f6444cbaa3cfcad0d6c9f2"
 "28.8.2026, 07:28:42","Kimmi","z-ai/glm-5.2","ai-sdk","136560","135872","935","$0.056192","170.6","success","c17a0b1320aa4c56b96e9f209a4a3f18"
 "28.8.2026, 07:28:41","Kimmi","z-ai/glm-5.2","python-requests","17","","20","$0.000120","43.7","success","acfb7207b060492aa2594f1657557fd0"
 "28.8.2026, 07:28:41","Kimmi","moonshotai/kimi-k3","python-requests","129","","20","$0.000687","41.0","success","15a88df68e20407483814f5c12b5b1fa"
 "28.8.2026, 07:28:35","Kimmi","z-ai/glm-5.2","ai-sdk","135090","133632","826","$0.056016","173.5","success","6db30899ee124dcf9f3052474bd4b4d0"
 "28.8.2026, 07:28:30","Kimmi","z-ai/glm-5.2","ai-sdk","133241","132608","443","$0.052671","150.9","success","0279669b12ac4e57b14bb577e943bc5e"
 "28.8.2026, 07:28:27","Kimmi","z-ai/glm-5.2","ai-sdk","132646","130880","101","$0.052183","53.2","success","ca77e2774cf74090a2e82485c8f7ee79"
 "28.8.2026, 07:28:16","Kimmi","z-ai/glm-5.2","ai-sdk","130689","","226","$0.197050","21.8","success","568c06006a2040a68970b8dac234eb8d"
 "27.8.2026, 21:22:04","Kimmi","z-ai/glm-5.2","ai-sdk","138823","138752","1265","$0.057831","182.6","success","8016c131dd2d44a8a0ad3fdc634d3698"
 "27.8.2026, 21:22:02","Kimmi","z-ai/glm-5.2","ai-sdk","138554","138304","203","$0.053152","102.2","success","15aece035e784eebbf5fcc7de713b0db"
 "27.8.2026, 21:21:58","Kimmi","z-ai/glm-5.2","ai-sdk","138070","137856","254","$0.053160","103.8","success","1c8e4e6d5a57432eae68ad5366dcb6d0"
 "27.8.2026, 21:21:54","Kimmi","z-ai/glm-5.2","ai-sdk","137663","137216","250","$0.053252","112.7","success","f175821db5a64fbb8631dbb18a1ba2ca"
 "27.8.2026, 21:17:23","Kimmi","z-ai/glm-5.2","ai-sdk","136981","136512","271","$0.053115","61.5","success","6dad9faefcac492998a31e0243fb357f"
 "27.8.2026, 21:17:12","Kimmi","z-ai/glm-5.2","ai-sdk","136164","135488","394","$0.053595","52.8","success","9a733b0199944e1eb2185bf23f720548"
 "27.8.2026, 21:17:07","Kimmi","z-ai/glm-5.2","ai-sdk","135269","135104","276","$0.052153","122.5","success","da0e3f68bbf04332809c7a4dad2e96af"
 "27.8.2026, 21:17:02","Kimmi","z-ai/glm-5.2","ai-sdk","134884","134720","256","$0.051918","99.5","success","abeffbe16cba4311aee8b881610dd377"
 "27.8.2026, 21:16:58","Kimmi","z-ai/glm-5.2","ai-sdk","134659","134528","105","$0.051117","54.0","success","2f94ec74d927470f807f8bc63fb68c9c"
 "27.8.2026, 21:16:55","Kimmi","z-ai/glm-5.2","ai-sdk","134449","134336","116","$0.051068","64.8","success","87e7f845d56b4c288c58af7dad1cc2f4"
 "27.8.2026, 21:16:47","Kimmi","z-ai/glm-5.2","ai-sdk","133947","132224","438","$0.054140","80.1","success","f0c8f0b3520d48a884da6edaa50fe204"
 "27.8.2026, 21:16:38","Kimmi","z-ai/glm-5.2","ai-sdk","132131","131968","102","$0.050192","60.9","success","23fc7c383ab14e88913e1873637a2b7e"
 "27.8.2026, 21:16:34","Kimmi","z-ai/glm-5.2","ai-sdk","131846","131776","141","$0.050156","46.4","success","fdbea6a91ee44127badd05776673468b"
 "27.8.2026, 21:16:22","Kimmi","z-ai/glm-5.2","ai-sdk","129908","129600","1874","$0.057495","210.5","success","a0447b871daf4561802bbb057175791b"
 "27.8.2026, 21:16:20","Kimmi","z-ai/glm-5.2","ai-sdk","129540","129344","98","$0.049239","60.3","success","1c8bfb8041c74126878bdd89f7ac08f0"
 "27.8.2026, 21:16:17","Kimmi","z-ai/glm-5.2","ai-sdk","129288","129216","111","$0.049064","56.0","success","feb36add4fca4b8daf5f33f546f19556"
 "27.8.2026, 21:15:44","Kimmi","z-ai/glm-5.2","ai-sdk","129165","128960","91","$0.049077","49.1","success","b6e86a665ef64687961a11f7dbc83fdd"
 "27.8.2026, 21:15:37","Kimmi","z-ai/glm-5.2","ai-sdk","128754","128064","225","$0.050071","98.0","success","7bad94b36a7f41a195db821de081687a"
 "27.8.2026, 21:15:35","Kimmi","z-ai/glm-5.2","ai-sdk","128006","127744","92","$0.048711","48.2","success","0fcc863a1bb74c0296a579cb05458c6d"
 "27.8.2026, 21:15:27","Kimmi","z-ai/glm-5.2","ai-sdk","127522","127168","270","$0.049434","87.8","success","bb1f73fd86dd498ca616eeb41532831e"
 "27.8.2026, 21:15:18","Kimmi","z-ai/glm-5.2","ai-sdk","126752","125440","426","$0.050925","132.9","success","e991bab217ef4886aae68196c3d6e97d"
 "27.8.2026, 21:10:12","Kimmi","z-ai/glm-5.2","ai-sdk","125012","124864","479","$0.049202","154.4","success","eadc1c3a8c4849b9890cddc0f9a56786"
 "27.8.2026, 21:10:03","Kimmi","z-ai/glm-5.2","ai-sdk","124717","124544","178","$0.047765","22.2","success","d9d10e707a774d69b9d25c004e6e3741"
 "27.8.2026, 21:09:58","Kimmi","z-ai/glm-5.2","ai-sdk","124365","124224","190","$0.047651","94.2","success","d9e71bf60cf8476da270a2b0752da2a2"
 "27.8.2026, 21:09:54","Kimmi","z-ai/glm-5.2","ai-sdk","124087","123456","168","$0.047999","86.2","success","c745c96ffdfe44eaae02a82b1d2d70c7"
 "27.8.2026, 21:09:51","Kimmi","z-ai/glm-5.2","ai-sdk","123370","121984","137","$0.048440","77.3","success","cbb938ad104a4bcdbbba478bccc0326e"
 "27.8.2026, 21:09:42","Kimmi","z-ai/glm-5.2","ai-sdk","121992","121536","1285","$0.052042","240.4","success","7e0fa45edf6c465bbd441586a8b51289"
 "27.8.2026, 21:09:40","Kimmi","z-ai/glm-5.2","ai-sdk","121485","121408","76","$0.045985","50.1","success","9c686fa1140047878287e08f33411355"
 "27.8.2026, 21:09:33","Kimmi","z-ai/glm-5.2","ai-sdk","120322","120192","1093","$0.050186","228.1","success","c5eda6e7806c48a79a386e617745095b"
 "27.8.2026, 21:09:31","Kimmi","z-ai/glm-5.2","ai-sdk","120159","120064","64","$0.045454","45.5","success","bf85186bb1304bf0b7bf22562f5cc4b8"
 "27.8.2026, 21:09:28","Kimmi","z-ai/glm-5.2","ai-sdk","120041","119936","75","$0.045471","45.8","success","0af922596fcd4d1a9022e09790c4fc96"
 "27.8.2026, 21:09:21","Kimmi","z-ai/glm-5.2","ai-sdk","119605","119488","366","$0.046631","89.6","success","b5151be2635d4d10a0909dd2d45d42cc"
 "27.8.2026, 21:09:07","Kimmi","z-ai/glm-5.2","ai-sdk","118122","117952","1400","$0.050787","114.9","success","43d7804f2c4c47dd8a297284194d6050"
 "27.8.2026, 21:09:03","Kimmi","z-ai/glm-5.2","ai-sdk","117872","117760","82","$0.044697","39.0","success","0fce1593c40e4128860977e43c21494e"
 "27.8.2026, 21:08:50","Kimmi","z-ai/glm-5.2","ai-sdk","117143","116800","659","$0.047280","141.1","success","6bb3c4ca6fe84fc8bf7bc79c0ae5522d"
 "27.8.2026, 21:08:47","Kimmi","z-ai/glm-5.2","ai-sdk","116719","116608","99","$0.044340","43.2","success","f4e0691805eb4bb09ad6bbdc43bc1231"
 "27.8.2026, 21:08:34","Kimmi","z-ai/glm-5.2","ai-sdk","115741","115520","909","$0.047742","186.8","success","4dd84e3b7ee54e8ca718cef81ca360e2"
 "27.8.2026, 21:08:30","Kimmi","z-ai/glm-5.2","ai-sdk","115499","115392","77","$0.043779","20.1","success","78c6d135d90f4e8eb8c8634cf6f9402e"
 "27.8.2026, 21:08:20","Kimmi","z-ai/glm-5.2","ai-sdk","114439","113088","991","$0.048894","136.2","success","769ee0db7a634d97a7fbad1d9e66dec8"
 "27.8.2026, 21:08:14","Kimmi","z-ai/glm-5.2","ai-sdk","113020","112896","130","$0.043107","33.5","success","00ec54b95baf412c87140ade523225e1"
 "27.8.2026, 21:08:01","Kimmi","z-ai/glm-5.2","ai-sdk","111972","107648","981","$0.051269","217.3","success","f79dd290a4fb4e61a0a61bef4103ea31"
 "27.8.2026, 21:07:25","Kimmi","z-ai/glm-5.2","ai-sdk","104061","103744","7827","$0.074601","221.6","success","675fd418b40e4e4db18657f5501d6b93"
 "27.8.2026, 21:07:15","Kimmi","z-ai/glm-5.2","ai-sdk","102268","101696","1486","$0.045681","163.2","success","5eaca0b758c847a0a86b4c1a4d1216c9"
 "27.8.2026, 21:07:02","Kimmi","z-ai/glm-5.2","ai-sdk","100561","98304","1196","$0.045631","110.8","success","4aab7ab79e2d4155b9824b7e63bbcf35"
 "27.8.2026, 21:06:54","Kimmi","z-ai/glm-5.2","ai-sdk","97739","97472","572","$0.039526","132.3","success","b50a7daeed3b4224b5b7c688d319a501"
 "27.8.2026, 21:06:48","Kimmi","z-ai/glm-5.2","ai-sdk","97247","96640","370","$0.038816","109.5","success","c9b79a80374044f4974ae73cba635bca"
 "27.8.2026, 21:06:33","Kimmi","z-ai/glm-5.2","ai-sdk","95502","95040","1167","$0.041585","155.5","success","e73de079e83c42b98289cc53f6b0db67"
 "27.8.2026, 21:06:25","Kimmi","z-ai/glm-5.2","ai-sdk","94614","94272","486","$0.038052","128.3","success","339b27f68f0640a384045278392ae6c8"
 "27.8.2026, 21:06:19","Kimmi","z-ai/glm-5.2","ai-sdk","93827","93568","500","$0.037727","131.0","success","144f7c1e05a6447c81037785f83d4480"
 "27.8.2026, 21:06:14","Kimmi","z-ai/glm-5.2","ai-sdk","93378","92864","249","$0.036715","94.2","success","eda7b8d0f5f94c5595884b9d8c10f6a7"
 "27.8.2026, 21:06:10","Kimmi","z-ai/glm-5.2","ai-sdk","92418","91264","457","$0.038011","138.4","success","a379a9c085734a21b50aa702bcf405ef"
 "27.8.2026, 21:06:05","Kimmi","z-ai/glm-5.2","ai-sdk","90976","90432","328","$0.036204","130.3","success","a17f29bc56bd4f609d5f59008ff8523d"
 "27.8.2026, 21:05:57","Kimmi","z-ai/glm-5.2","ai-sdk","90243","89792","343","$0.035892","118.7","success","edff8b9684f7480e9588dd554b3ca144"
 "27.8.2026, 21:00:47","Kimmi","z-ai/glm-5.2","ai-sdk","89745","89472","189","$0.034812","0.6","success","c67f74563093452f9965a86abd83fe94"
 "27.8.2026, 21:00:37","Kimmi","z-ai/glm-5.2","ai-sdk","89395","88320","110","$0.035228","67.9","success","721c2995de4042c9942d62d8cdc1d03f"
 "27.8.2026, 20:59:59","Kimmi","z-ai/glm-5.2","ai-sdk","88204","87872","137","$0.034066","73.4","success","7f0d725d7a0042ee86f64490f88bafb2"
 "27.8.2026, 20:59:41","Kimmi","z-ai/glm-5.2","ai-sdk","87817","87168","112","$0.034166","71.0","success","401ce2a258284c8f8360ce7cba634b49"
 "27.8.2026, 20:54:36","Kimmi","z-ai/glm-5.2","ai-sdk","87198","86720","71","$0.033557","50.9","success","697317a170b84377ae705622c48d2b36"
 "27.8.2026, 20:54:23","Kimmi","z-ai/glm-5.2","ai-sdk","86626","86336","113","$0.033320","71.9","success","1cc5d7866ac54e87a7acc22942bbbdf2"
 "27.8.2026, 20:54:21","Kimmi","z-ai/glm-5.2","ai-sdk","86243","84928","98","$0.034262","65.8","success","1fd0ce4ea24641caadaa1e821028b990"
 "27.8.2026, 20:54:13","Kimmi","z-ai/glm-5.2","ai-sdk","84990","","121","$0.128029","19.7","success","e31d2a5b783a4ee3aac75f14be0a0021"
 "27.8.2026, 20:53:10","Kimmi","moonshotai/kimi-k3","opencode","8752","","90","$0.027606","41.4","success","86c26747235c4fa9b60b4a016a9247be"
 "27.8.2026, 20:52:41","Kimmi","z-ai/glm-5.2","opencode","8908","","34","$0.013515","8.5","success","913bc534ee1147fbb6404b1d326a8a60"
 "27.8.2026, 20:51:17","Kimmi","z-ai/glm-5.2","ai-sdk","83428","79616","2755","$0.047972","228.4","success","2fd42418854543a3bc3d5cbf9274ea9e"
 "27.8.2026, 20:51:10","Kimmi","z-ai/glm-5.2","ai-sdk","78906","71616","727","$0.041063","168.6","success","3dbaa3fdc4bc4528a972ce9afa20c77a"
 "27.8.2026, 20:50:26","Kimmi","z-ai/glm-5.2","ai-sdk","71216","","452","$0.108858","39.7","success","9b156c2e24e04604ad0d109955fba377"
 "27.8.2026, 20:49:42","Kimmi","z-ai/glm-5.2","ai-sdk","105511","","1080","$0.163127","41.0","success","5c2c6153d15444e3bbfbce98b154e532"
 "27.8.2026, 19:39:53","Kimmi","z-ai/glm-5.2","ai-sdk","98459","93952","7024","$0.073600","202.4","success","1180cdaf3f3e42b99f2ccdd5c77dde42"
 "27.8.2026, 19:39:44","Kimmi","z-ai/glm-5.2","ai-sdk","93156","91200","835","$0.040891","147.8","success","39f159d6668e4867812b318ab18b5607"
 "27.8.2026, 19:39:40","Kimmi","z-ai/glm-5.2","ai-sdk","90791","90688","425","$0.036075","149.2","success","7d0b911db4fc46508683f5cd9b2e5993"
 "27.8.2026, 19:39:21","Kimmi","z-ai/glm-5.2","ai-sdk","87159","85312","3562","$0.050792","204.6","success","f1d39a019fd64b4d868155362d537bf1"
 "27.8.2026, 19:39:01","Kimmi","z-ai/glm-5.2","ai-sdk","82005","80640","3309","$0.047178","197.5","success","0f10da8d2b7740c2ad943ab4891353f1"
 "27.8.2026, 19:38:48","Kimmi","z-ai/glm-5.2","ai-sdk","78860","56064","1821","$0.063413","185.7","success","f5c4397f71424d3da69152996251d9d1"
 "27.8.2026, 19:30:22","Kimmi","z-ai/glm-5.2","ai-sdk","76055","72000","1583","$0.040206","209.8","success","73c7e2be37bf434d8ac81e1ddde8c2dd"
 "27.8.2026, 19:30:04","Kimmi","z-ai/glm-5.2","ai-sdk","68728","68608","3287","$0.040699","203.5","success","d247eecedeac42f49cc6abd9d7a04ed9"
 "27.8.2026, 19:29:48","Kimmi","z-ai/glm-5.2","ai-sdk","65196","62912","3418","$0.042399","214.3","success","c56e47407bc644e198c905ba5cb3138b"
 "27.8.2026, 19:29:40","Kimmi","z-ai/glm-5.2","ai-sdk","61893","61120","1068","$0.028886","174.0","success","7ea581d6f7ab4ff2bb2e51194dd21171"
 "27.8.2026, 19:29:09","Kimmi","z-ai/glm-5.2","ai-sdk","56072","","5066","$0.106905","195.1","success","136c3ddd28bf47b0b495829333742350"
 "27.8.2026, 19:23:53","Kimmi","z-ai/glm-5.2","ai-sdk","49693","48768","1836","$0.027938","177.4","success","b2252ec3021c433cb923d423a5fc1f46"
 "27.8.2026, 19:23:48","Kimmi","z-ai/glm-5.2","ai-sdk","47965","47680","821","$0.022002","185.0","success","22db912203694e7590912e06615a9b33"
 "27.8.2026, 19:23:45","Kimmi","z-ai/glm-5.2","ai-sdk","47384","46976","300","$0.019578","147.5","success","bec2f4051b154b8294608429d6e1c42b"
 "27.8.2026, 19:23:42","Kimmi","z-ai/glm-5.2","ai-sdk","46629","46400","373","$0.019422","121.4","success","b4e489a6c6144c1289f53241ae1013bf"
 "27.8.2026, 19:23:39","Kimmi","z-ai/glm-5.2","ai-sdk","46281","46144","140","$0.018139","104.5","success","5ddaed4aa4cc4193a30aa5bc80d20575"
 "27.8.2026, 19:23:35","Kimmi","z-ai/glm-5.2","ai-sdk","45605","38272","570","$0.027917","159.2","success","0aa01c328e084dbabb85d4a0029f1e1f"
 "27.8.2026, 19:22:58","Kimmi","z-ai/glm-5.2","ai-sdk","36664","","7880","$0.090456","216.4","success","b8ab13a04f194cb28958a528dc58de75"
 "27.8.2026, 18:07:51","Kimmi","z-ai/glm-5.2","ai-sdk","39425","39104","2057","$0.024402","241.8","success","52a8d8ad0dbf412099483e620e96a4cf"
 "27.8.2026, 18:07:39","Kimmi","z-ai/glm-5.2","ai-sdk","37760","","1346","$0.062697","141.2","success","2d6fa161a83a438695db90a2bfd6cc6e"
 "27.8.2026, 17:55:15","Kimmi","z-ai/glm-5.2","ai-sdk","36578","36352","792","$0.017535","233.8","success","db896f09819e4c03a778c81e060edd23"
 "27.8.2026, 17:55:07","Kimmi","z-ai/glm-5.2","ai-sdk","36249","35648","138","$0.014890","128.3","success","1ac25824fd7a4f5d99239ba800a913fb"
 "27.8.2026, 17:55:05","Kimmi","z-ai/glm-5.2","ai-sdk","35402","34624","279","$0.015407","185.6","success","e6cb73bef24343fcbd878cbeaa35b0ef"
 "27.8.2026, 17:54:40","Kimmi","z-ai/glm-5.2","ai-sdk","32478","","2202","$0.058626","197.2","success","60b49fb0404f41cfa718f47073433b43"
 "27.8.2026, 17:50:27","Kimmi","z-ai/glm-5.1","ai-sdk","3015","","154","$0.004899","143.5","success","14336227bed349299e36d3d465ac2541"
 "27.8.2026, 16:15:30","Kimmi","z-ai/glm-5.1","ai-sdk","3016","","69","$0.004526","103.0","success","1fcb66e10d4f4ce5b224f85ed1789f7c"
 "27.8.2026, 09:28:29","Kimmi","z-ai/glm-5.1","curl","7","","79","$0.000357","145.2","success","5c82a1846cc146e9a78cf7f2162b9f3d"
 "27.8.2026, 09:28:28","Kimmi","z-ai/glm-5.1","curl","7","","89","$0.000401","163.9","success","5e461d9330de460d81665393f90d87c7"
 "27.8.2026, 09:28:28","Kimmi","z-ai/glm-5.1","curl","7","","93","$0.000419","163.7","success","9ce3d71e3501413cbcd918de4ac258a8"
 "27.8.2026, 09:26:55","Kimmi","z-ai/glm-5.1","curl","15","","39","$0.000193","117.1","success","ef6d17def7044eed90815085b2632347"
 "27.8.2026, 09:26:38","Kimmi","z-ai/glm-5.1","curl","12","","1","$0.000272","1.6","success","699b1fc125c844659b06880b442af288"
 "27.8.2026, 09:26:13","Kimmi","z-ai/glm-5.1","curl","7","","10","$0.000063","50.0","success","5f947d3f717a43e0b2e1c5be8c45f1e5"
 "27.8.2026, 09:03:26","Test_GLM","z-ai/glm-5.2","ai-sdk","3023","","131","$0.005124","15.8","success","97981314b5b444fbae4915c0333817bc"
@@ -0,0 +1,54 @@
 # Messprotokoll – Versuch 01 – Prompt-Version 02
 ## Lauf
 - **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
 - **Prompt-Version:** 02
 - **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
 - **Startzeit:** 2026-08-28T07:28:25Z
 - **Endzeit:** 2026-08-28T07:38:32Z (geschätzt aus RawResult)
 - **Dauer gesamt:** ~10:07 (parallel zu Lauf B)
 - **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
 - **Codebasis-Commit:** `37275c96` (dirty: nein)
 - **Parallele Läufe:** ja – Lauf B (`moonshotai/kimi-k3/solo/high/092820_v8.0.0-09b6`) lief zeitgleich
 ## Werkzeugkonfiguration
 - **Skill-Version:** v8.0.0
 - **Werkzeugadapter:** Python API (TensorX Gateway), Adapter v1.1.0
 - **Modell (angefordert):** `z-ai/glm-5.2`
 - **Modelle (tatsächlich eingesetzt):** `z-ai/glm-5.2` (100 %)
 - **Kontrolle Modell:** bestanden
 - **Effort:** high (GLM `thinking.level` = `high`)
 - **Laufverzeichnis-ID:** `v8.0.0-4650`
 - **Ablage:** `Iteration 6/z-ai/glm-5.2/builtin/high/`
 - **Agentenmodus:** builtin (V1b) – eingebaute Subagenten erlaubt
 - **Subagenten:** 10 gestartet, 10 completed, 0 failed (Unicode-Bugfix wirksam)
 ## Verbrauch
 | Messgröße | Wert |
 |---|---:|
 | Input-Tokens | 1.091.236 |
 | Output-Tokens | 35.378 |
 | davon Reasoning-Tokens | 2.062 |
 | Cache-Read-Tokens | 830.848 |
 | **Tokens gesamt** | **1.126.614** |
 | Agent-Turns | 8 |
 | API-Aufrufe | nicht einzeln gezählt |
 | Tool-Calls | 32 (16× list_directory, 10× spawn_subagent, 4× search_files, 2× read_file, 0× write_file) |
 ## Ergebnis
 - **Status:** **Fehlmessung** — `is_error: false`, `subtype: success`, aber **0 Ergebnisdateien**
 - **Gültigkeit:** **ungültig** – Ergebnisverzeichnis ist leer (analog zu MAJOR 6.1.0)
 - **Erzeugte Dateien:** keine
 - **Root unverändert:** ja
 - **Anmerkungen:**
  - Der Agent startete 10 Subagenten (alle erfolgreich, keine Unicode-Fehler mehr),
    schrieb aber selbst keine Ergebnisdateien.
  - Der Abschlusstext lautet: „Ich habe nun eine umfassende Übersicht der gesamten
    Codebasis. Jetzt benötige ich gezielte Belege für die risikorelevanten Bereiche.
    Ich starte parallele Suchen." — der Agent beschrieb, was er tun würde, anstatt es zu tun.
  - Nur 8 Turns bei max_turns=100 — der Agent brach nach den Subagenten-Rückmeldungen ab,
    ohne die Ergebnisse zu formalisieren.
  - Ursache vermutlich: Nach 10 Subagenten-Rückmeldungen generierte das Modell einen
    Text ohne tool_calls (finish_reason: stop), worauf der Agent-Loop endete.
  - Trotz Fehlmessung: Subagent-Mechanismus funktionierte korrekt (10/10 completed).
@@ -0,0 +1,392 @@
 {
  "is_error": false,
  "subtype": "success",
  "duration_ms": 656526,
  "duration_api_ms": 656526,
  "num_turns": 8,
  "model": "z-ai/glm-5.2",
  "model_requested": "z-ai/glm-5.2",
  "provider": "tensorx",
  "usage": {
    "prompt_tokens": 1057104,
    "completion_tokens": 69510,
    "total_tokens": 1126614,
    "cached_tokens": 675008,
    "cache_read_tokens": 675008,
    "cache_creation_tokens": 0,
    "reasoning_tokens": 8528,
    "output_tokens_details": {
      "thinking_tokens": 8528
    }
  },
  "modelUsage": {
    "z-ai/glm-5.2": {
      "input_tokens": 1057104,
      "output_tokens": 69510,
      "cache_read_input_tokens": 675008,
      "cache_creation_input_tokens": 0,
      "reasoning_tokens": 8528
    }
  },
  "tool_calls": [
    {
      "turn": 1,
      "name": "list_directory",
      "args": {
        "path": ""
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "src"
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "assemblies"
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "docs"
      }
    },
    {
      "turn": 2,
      "name": "read_file",
      "args": {
        "path": "README.md"
      }
    },
    {
      "turn": 2,
      "name": "read_file",
      "args": {
        "path": "CentronRights.md"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/backend"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/centron"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/shared"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/nexus"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/apis"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/webservice"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Entities"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.DAO"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Common"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Gateway"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Interfaces"
      }
    },
    {
      "turn": 5,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/backend/Centron.BL und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2. Einem Satz zur fachlichen Aufgabe (abgeleitet aus Klassen-/Methodennamen und ggf. gefundenen Strings)\n3. Auflistung der wichtigsten .cs-Dateien im jeweiligen Modulverzeichnis\nGehe dabei systematisch alle Unterverzeichnisse durch. Ignoriere bin/ und obj/. Liste für jedes Unterverzeichnis die darin gefundenen .cs-Dateien auf (nur die oberste Ebene, nicht rekursiv in weitere Unterordner)."
      }
    },
    {
      "turn": 5,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/backend/Centron.Interfaces und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2. Einem Satz zur fachlichen Aufgabe\n3. Wichtige Interface-Dateien\nGehe dabei systematisch alle Unterverzeichnisse durch. Ignoriere bin/ und obj/."
      }
    },
    {
      "turn": 5,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/backend/Centron.Gateway und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2. Einem Satz zur fachlichen Aufgabe (EDI, Datenexport/-import, etc.)\n3. Wichtige .cs-Dateien\nGehe dabei systematisch alle Unterverzeichnisse durch. Ignoriere bin/ und obj/."
      }
    },
    {
      "turn": 5,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/centron (WPF UI). Erkunde src/centron/Centron.WPF.UI und src/centron/Centron.WPF.UI.Extension. Liste alle Unterverzeichnisse und die darin enthaltenen .cs- und .xaml-Dateien auf. Beschreibe für jedes Verzeichnis die fachliche Aufgabe (z.B. welches UI-Modul es repräsentiert). Ignoriere bin/ und obj/. Gehe rekursiv bis 2 Ebenen tief vor."
      }
    },
    {
      "turn": 5,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/nexus (Blazor/Web). Erkunde src/nexus/CentronNexus und src/nexus/CentronNexus.Host. Liste alle Unterverzeichnisse und die wichtigsten .cs-Dateien auf. Beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/. Gehe rekursiv bis 2 Ebenen tief vor."
      }
    },
    {
      "turn": 6,
      "name": "spawn_subagent",
      "args": {
        "description": "Analysiere das Verzeichnis src/apis - alle Unterverzeichnisse (Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud, Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess, Centron.APIs.FinAPI, Centron.APIs.IcecatDataAccess, Centron.APIs.ITscopeDataAccess). Liste für jedes die wichtigsten .cs-Dateien und beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/.",
        "subagent_type": "explore"
      }
    },
    {
      "turn": 6,
      "name": "spawn_subagent",
      "args": {
        "description": "Analysiere das Verzeichnis src/webservice. Erkunde alle Unterverzeichnisse (c-entron.misc.ConnectionManager, Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centron.WebServices.Core). Liste die wichtigsten .cs-Dateien und beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/. Gehe bis 2 Ebenen tief.",
        "subagent_type": "explore"
      }
    },
    {
      "turn": 6,
      "name": "spawn_subagent",
      "args": {
        "description": "Analysiere das Verzeichnis src/shared und seine Unterverzeichnisse (Centron.Controls, Centron.Controls.Preview, Centron.Core). Liste die wichtigsten .cs-Dateien und beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/.",
        "subagent_type": "explore"
      }
    },
    {
      "turn": 6,
      "name": "spawn_subagent",
      "args": {
        "description": "Analysiere das Verzeichnis src/backend/Centron.Entities/Entities - liste alle Unterverzeichnisse und die darin enthaltenen .cs-Dateien auf. Beschreibe für jedes Unterverzeichnis die fachliche Entität, die es repräsentiert. Ignoriere bin/ und obj/.",
        "subagent_type": "explore"
      }
    },
    {
      "turn": 6,
      "name": "spawn_subagent",
      "args": {
        "description": "Analysiere die Verzeichnisse src/backend/Centron.DAO/CustomDAOs und src/backend/Centron.DAO/Mappings. Liste alle .cs-Dateien und beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/.",
        "subagent_type": "explore"
      }
    },
    {
      "turn": 7,
      "name": "search_files",
      "args": {
        "pattern": "UserRightsConst",
        "path": "src/backend/Centron.Common"
      }
    },
    {
      "turn": 7,
      "name": "search_files",
      "args": {
        "pattern": "class.*Receipt.*BL|class.*Billing.*BL|class.*Invoice.*BL|class.*Dunning.*BL|class.*FlatrateBilling|class.*TimerBilling|class.*AutomatedBilling",
        "path": "src/backend/Centron.BL"
      }
    },
    {
      "turn": 7,
      "name": "search_files",
      "args": {
        "pattern": "login|Login|Authenticate|PasswordHash|bcrypt|PBKDF2|hash.*password",
        "path": "src/backend/Centron.BL/Administration",
        "file_pattern": "*.cs"
      }
    },
    {
      "turn": 7,
      "name": "search_files",
      "args": {
        "pattern": "RightCheck|CheckRight|HasRight|UserRight|PermissionCheck",
        "path": "src/backend/Centron.BL",
        "file_pattern": "*.cs"
      }
    }
  ],
  "tool_call_count": 32,
  "tool_call_types": {
    "list_directory": 16,
    "read_file": 2,
    "spawn_subagent": 10,
    "search_files": 4
  },
  "written_files": [],
  "result": "Ich habe nun eine umfassende Übersicht der gesamten Codebasis. Jetzt benötige ich gezielte Belege für die risikorelevanten Bereiche (Sicherheit, Abrechnung/Fakturierung, Berechtigungen). Ich starte parallele Suchen.",
  "finish_reason": "tool_calls",
  "errors": [
    "Turn 8: API-Fehler: API-Fehler 429: {\"error\": {\"message\": \"Rate limit exceeded. Please slow down and retry.\", \"type\": \"rate_limit_error\", \"param\": null, \"code\": \"429\"}}"
  ],
  "session_id": "",
  "adapter": "python-glm-kimi",
  "adapter_version": "1.1.0",
  "mode": "builtin",
  "subagent_stats": {
    "spawned": 10,
    "completed": 10,
    "failed": 0,
    "by_type": {
      "explore": 10
    }
  },
  "subagent_details": [
    {
      "id": 1,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.BL und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2. Einem ",
      "turns": 10,
      "tool_calls": 107,
      "tokens": 81408,
      "status": "completed"
    },
    {
      "id": 2,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.Interfaces und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2",
      "turns": 15,
      "tool_calls": 206,
      "tokens": 124793,
      "status": "completed"
    },
    {
      "id": 3,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.Gateway und alle seine Unterverzeichnisse. Erstelle eine vollständige Liste aller fachlichen Module (Verzeichnisse) mit:\n1. Verzeichnisname und Pfad\n2. E",
      "turns": 8,
      "tool_calls": 70,
      "tokens": 109065,
      "status": "completed"
    },
    {
      "id": 4,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/centron (WPF UI). Erkunde src/centron/Centron.WPF.UI und src/centron/Centron.WPF.UI.Extension. Liste alle Unterverzeichnisse und die darin enthaltenen .cs- und .xaml-Dat",
      "turns": 7,
      "tool_calls": 139,
      "tokens": 95675,
      "status": "completed"
    },
    {
      "id": 5,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/nexus (Blazor/Web). Erkunde src/nexus/CentronNexus und src/nexus/CentronNexus.Host. Liste alle Unterverzeichnisse und die wichtigsten .cs-Dateien auf. Beschreibe die fac",
      "turns": 7,
      "tool_calls": 53,
      "tokens": 130510,
      "status": "completed"
    },
    {
      "id": 6,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/apis - alle Unterverzeichnisse (Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud, Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess, Centron.APIs.Fi",
      "turns": 6,
      "tool_calls": 101,
      "tokens": 79779,
      "status": "completed"
    },
    {
      "id": 7,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/webservice. Erkunde alle Unterverzeichnisse (c-entron.misc.ConnectionManager, Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centr",
      "turns": 4,
      "tool_calls": 31,
      "tokens": 3695,
      "status": "completed"
    },
    {
      "id": 8,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/shared und seine Unterverzeichnisse (Centron.Controls, Centron.Controls.Preview, Centron.Core). Liste die wichtigsten .cs-Dateien und beschreibe die fachliche Aufgabe. I",
      "turns": 10,
      "tool_calls": 30,
      "tokens": 147828,
      "status": "completed"
    },
    {
      "id": 9,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.Entities/Entities - liste alle Unterverzeichnisse und die darin enthaltenen .cs-Dateien auf. Beschreibe für jedes Unterverzeichnis die fachliche Entität,",
      "turns": 4,
      "tool_calls": 41,
      "tokens": 7214,
      "status": "completed"
    },
    {
      "id": 10,
      "type": "explore",
      "description": "Analysiere die Verzeichnisse src/backend/Centron.DAO/CustomDAOs und src/backend/Centron.DAO/Mappings. Liste alle .cs-Dateien und beschreibe die fachliche Aufgabe. Ignoriere bin/ und obj/.",
      "turns": 8,
      "tool_calls": 17,
      "tokens": 211368,
      "status": "completed"
    }
  ],
  "start_time": "2026-08-28T07:28:25.625878+00:00",
  "end_time": "2026-08-28T07:39:22.152853+00:00"
 }
@@ -0,0 +1,23 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T07:28:25.625878+00:00
 [glm-kimi-adapter] Provider: TensorX API Gateway
 [glm-kimi-adapter] Modell: z-ai/glm-5.2
 [glm-kimi-adapter] Effort: high
 [glm-kimi-adapter] Mode: builtin
 [glm-kimi-adapter] Subagent 1 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 2 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 3 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 4 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 5 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 6 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 7 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 8 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 9 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 10 gestartet (Typ: explore)
 [glm-kimi-adapter] Ende: 2026-08-28T07:39:22.152853+00:00
 [glm-kimi-adapter] Turns: 8
 [glm-kimi-adapter] Tokens gesamt: 1,126,614
 [glm-kimi-adapter] Tool-Calls: 32
 [glm-kimi-adapter] Subagenten: 10 (completed: 10, failed: 0)
 [glm-kimi-adapter] Ergebnisdateien: 0
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\z-ai\glm-5.2\builtin\high\02_Lauf_2026-08-28_092819_v8.0.0-4650\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,183 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 02
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-26
 - **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
 - **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Zusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.
 Nicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 - spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only)
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $laufA\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T09:39:22.1764851+02:00
@@ -0,0 +1 @@
 2026-08-28T09:28:19.8448062+02:00
@@ -0,0 +1,336 @@
 # Analysebericht – c-entron ERP-Suite
 ## Schritt 0: Modulinventar
 | # | Fachliches Modul / Komponente | Pfad im Arbeitsverzeichnis | Fachliche Aufgabe |
 |---|---|---|---|
 | 1 | Belegwesen (Receipts) | `src/backend/Centron.BL/Sales/Receipts/` | Zentrale Belegverarbeitung: Angebote, Aufträge, Lieferscheine, Rechnungen, Gutschriften, Abholscheine, Verträge – inkl. Weiterverarbeitung und Versionierung |
 | 2 | Belegpositionen (ReceiptItems) | `src/backend/Centron.BL/Sales/Receipts/ReceiptItemBL.cs` | Verwaltung von Belegpositionen: Artikel, Freitexte, Rabatte, An- und Abrede |
 | 3 | Beleg-Workflow (ReceiptProgression) | `src/backend/Centron.BL/Sales/Receipts/ReceiptProgressionBL.cs` | Steuerung des Beleg-Workflows: Freigaben, Statusübergänge, Weiterverarbeitungsregeln |
 | 4 | Beleg-Beleg-Karte (ReceiptCart) | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs` | Sammelbeleg-Erstellung durch Zusammenführung mehrerer Belege |
 | 5 | Beleg-Freigabesystem (ReceiptCartRelease) | `src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs` | Freigabesystem für Sammelbelege vor finaler Verbuchung |
 | 6 | Beleg-Logging (ReceiptLog) | `src/backend/Centron.BL/Sales/Receipts/ReceiptLogBL.cs` | Protokollierung aller Belegaktionen (Erstellung, Bearbeitung, Druck, Versand) |
 | 7 | Beleg-Provision (ReceiptProvision) | `src/backend/Centron.BL/Sales/Receipts/ReceiptProvisionSchemaBL.cs` | Provisionsberechnung und -verteilung auf Mitarbeiter bei Belegen |
 | 8 | Beleg-Vorlagen (ReceiptTemplate) | `src/backend/Centron.BL/Sales/Receipts/ReceiptTemplateBL.cs` | Vorlagen für Belege mit Standardtexten und -einstellungen |
 | 9 | Angebotsspezifische Logik (Offer) | `src/backend/Centron.BL/Sales/Receipts/Offers/OfferSpecificLogic.cs` | Spezifische Geschäftslogik für Angebote (Standardtexte, Pflichtfelder, Weiterverarbeitung) |
 | 10 | Auftragsspezifische Logik (Order) | `src/backend/Centron.BL/Sales/Receipts/Orders/OrderSpecificLogic.cs` | Spezifische Geschäftslogik für Aufträge (Direktlieferung, Teillieferung, Auftragsfreigabe) |
 | 11 | Lieferscheinspezifische Logik (DeliveryList) | `src/backend/Centron.BL/Sales/Receipts/DeliveryLists/DeliveryListSpecificLogic.cs` | Spezifische Geschäftslogik für Lieferscheine (Warenausgang, Kommissionierung) |
 | 12 | Rechnungsspezifische Logik (Invoice) | `src/backend/Centron.BL/Sales/Receipts/Invoices/InvoiceSpecificLogic.cs` | Spezifische Geschäftslogik für Rechnungen (ESR, ZUGFeRD, Buchhaltungsexport) |
 | 13 | Gutschriftsspezifische Logik (CreditVoucher) | `src/backend/Centron.BL/Sales/Receipts/CreditVouchers/CreditVoucherSpecificLogic.cs` | Spezifische Geschäftslogik für Gutschriften |
 | 14 | Lieferantenbeleg-Logik (SupplierReceipts) | `src/backend/Centron.BL/Sales/Receipts/SupplierOrders/`, `SupplierInvoices/`, `SupplierCreditVouchers/` | Belegverarbeitung auf Lieferantenseite: Bestellungen, Wareneingänge, Lieferantenrechnungen, Lieferantengutschriften |
 | 15 | Anzahlung (DownPayment) | `src/backend/Centron.BL/Sales/Receipts/DownPayment/DownPaymentBL.cs` | Verwaltung von Anzahlungsrechnungen und Schlussrechnungsberechnung |
 | 16 | Leasing & Service | `src/backend/Centron.BL/Sales/Receipts/LeasingAndService/` | Leasing- und Serviceverträge mit Ratenberechnung |
 | 17 | Kunden-Assets (Stammblätter) | `src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs` | Verwaltung von Kundengeräten/Hardware als „Assets" mit Verträgen, Zählerständen und Abrechnung |
 | 18 | Kunden-Asset-Artikel | `src/backend/Centron.BL/Sales/CustomerAssets/AssetArticleBL.cs` | Artikel-Zuordnung zu Kundengeräten (Wartung, Service, Verbrauchsmaterial) |
 | 19 | Kunden-Asset-Sperre | `src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs` | Sperrung von Kundengeräten bei Mahnlauf |
 | 20 | Kundenverwaltung (Customer/CRM) | `src/backend/Centron.BL/Sales/Customers/CustomerBL.cs` | Kundenstammdaten, Finanzdaten, Firmenbuchnummern, Klassifizierungen |
 | 21 | Kontaktpersonen | `src/backend/Centron.BL/Sales/Customers/ContactPersonBL.cs` | Ansprechpartner-Verwaltung mit Adressen, Kommunikationsdaten und Berechtigungen |
 | 22 | Kunden-Einstellungen | `src/backend/Centron.BL/Sales/Customers/CustomerSettingBL.cs` | Kundenspezifische Einstellungen: Preise, Lieferbedingungen, Sonderpreise |
 | 23 | Kundensuche | `src/backend/Centron.BL/Sales/Customers/SearchCustomerBL.cs` | Volltext- und Kriteriensuche nach Kunden |
 | 24 | Lieferantenverwaltung | `src/backend/Centron.BL/BusinessPartner/SearchSupplierBL.cs`, `SupplierAssetBL.cs` | Lieferantenstammdaten und Asset-Verwaltung |
 | 25 | Artikelverwaltung | `src/backend/Centron.BL/Warehousing/ArticleBL.cs` | Artikelstamm: EK/VK-Preise, EAN, Herstellercode, Seriennummern, EOL-Status |
 | 26 | Artikel-Import | `src/backend/Centron.BL/Warehousing/ArticleManagement/ArticleImportBL.cs` | Massenimport von Artikeln aus Dateien oder externen Katalogen |
 | 27 | Artikel-Einheiten | `src/backend/Centron.BL/Warehousing/ArticleUnitBL.cs` | Verwaltung von Verpackungseinheiten und Umrechnungsfaktoren |
 | 28 | Barcode-Verwaltung | `src/backend/Centron.BL/Warehousing/BarcodeBL.cs` | Barcode-Generierung, -Scanning und -Historie für Artikel und Belegpositionen |
 | 29 | Zweitlager-Artikel | `src/backend/Centron.BL/Warehousing/SecondStockArticleBL.cs` | Verwaltung von Gebraucht-/Zweitlagerartikeln |
 | 30 | Steuerschlüssel (Tax) | `src/backend/Centron.BL/Warehousing/TaxBL.cs` | Mehrwertsteuersätze und -zuordnungen |
 | 31 | Materialgruppen | `src/backend/Centron.BL/Warehousing/InventoryManagement/MaterialGroupBL.cs` | Hierarchische Warengruppenstruktur |
 | 32 | Lagerverwaltung (Storage) | `src/backend/Centron.BL/Storage/StorageBL.cs` | Lagerorte, Lagerplätze, Bestandsführung |
 | 33 | Bestandsverwaltung (Stock) | `src/backend/Centron.BL/Warehousing/StockManagement/ArticleStockBL.cs` | Bestandsbuchungen: Zu-/Abgänge, Reservierungen, Mindestbestände |
 | 34 | Inventur | `src/backend/Centron.BL/Warehousing/InventoryManagement/InventoryBL.cs` | Inventurdurchführung mit Stichtags- und permanenter Inventur |
 | 35 | Kommissionierung | `src/backend/Centron.BL/Warehousing/CommissioningManagement/CommissioningBL.cs` | Kommissionierung von Aufträgen mit Teillieferungen |
 | 36 | Mahnwesen | `src/backend/Centron.BL/Sales/Receipts/Invoices/Dunning/DunningBL.cs`, `DunningRunBL.cs` | Mahnläufe mit Mahnstufen, -texten und -farben |
 | 37 | OPOS (Offene Posten) | `src/backend/Centron.BL/Sales/Receipts/Invoices/Opos/OposBL.cs`, `OposRunBL.cs` | Offene-Posten-Verwaltung und -Ausgleich |
 | 38 | Buchhaltung (Accounting) | `src/backend/Centron.BL/Accounting/BankAccountBL.cs` | Buchungskonten, Bankverbindungen, Buchhaltungsschnittstellen |
 | 39 | Buchhaltungsexport | `src/backend/Centron.BL/DataExchange/BookKeeping/` | Export von Buchungssätzen an externe Buchhaltungssysteme (Abacus, Datev u. a.) |
 | 40 | Online-Banking | `src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs` | Kontoumsätze abrufen und Zahlungen zuordnen (FinAPI) |
 | 41 | Zahlungsverkehr (Payments) | `src/backend/Centron.BL/Finances/Payments/PaymentsBL.cs` | Zahlungsabwicklung und -export |
 | 42 | Zahlungstransaktionen | `src/backend/Centron.BL/DataExchange/PaymentTransactions/` | SEPA-Export, Zahlungslauf-Dateien erstellen |
 | 43 | Eingangszahlungen | `src/backend/Centron.BL/Finances/IncomingPayments/IncomingPaymentBL.cs` | Zuordnung von Eingangszahlungen zu Rechnungen |
 | 44 | Kassenbuch | `src/backend/Centron.BL/Sales/CashBooks/CashBookBL.cs`, `CashBookBookingBL.cs` | Kassenbuch mit Buchungen und Belegen |
 | 45 | Einkauf (Purchasing) | `src/backend/Centron.BL/Purchasing/` | Einkaufseinstellungen, Bestellvorschlagsliste (BVL) |
 | 46 | Bestellvorschlagsliste (BVL) | `src/backend/Centron.BL/Purchasing/OrderSuggestionList/` | Automatische Bestellvorschläge nach Mindestbestand und Verbrauch |
 | 47 | Produktion | `src/backend/Centron.BL/Production/ProductionBL.cs`, `ProductionOrderBL.cs` | Produktionsaufträge und -durchführung |
 | 48 | Mitarbeiterverwaltung | `src/backend/Centron.BL/EmployeeArea/EmployeeBL.cs` | Mitarbeiterstammdaten, Abteilungen, Auslastung |
 | 49 | Mitarbeiterartikel | `src/backend/Centron.BL/EmployeeArea/EmployeeArticleBL.cs` | Mitarbeiter-Artikel (Leistungserfassung, Stundensätze) |
 | 50 | Mitarbeiter-Urlaub | `src/backend/Centron.BL/EmployeeArea/EmployeeHolidayBL.cs` | Urlaubsverwaltung mit Genehmigungsworkflow |
 | 51 | Benutzer-/Login-Verwaltung | `src/backend/Centron.BL/Administration/Logins/UsersBL.cs`, `TicketBL.cs` | Benutzerkonten, Login-Verwaltung, Web-Accounts |
 | 52 | Web-Accounts | `src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs` | Web-Accounts für Kunden-/Web-Zugriff mit separaten Rechten |
 | 53 | Berechtigungsverwaltung (Rights) | `src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs` | Rechtegruppen, Rechte-Zuweisung, filialbezogene Rechte |
 | 54 | 2-Faktor-Authentifizierung | `src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs` | TOTP-basierte 2FA für Benutzer |
 | 55 | EntraID-Integration | `src/backend/Centron.BL/Administration/Logins/EntraIDUsersBL.cs` | Azure AD / Entra ID Benutzer-Synchronisation |
 | 56 | Authentifizierung | `src/backend/Centron.BL/Administration/Logins/Auth/` | Authentifizierungsstrategien (SQL, WebService, EntraID) |
 | 57 | Lizenzverwaltung | `src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs` | Lizenzprüfung, Hardware-ID-Bindung, Online-/Offline-Lizenzierung |
 | 58 | Mandanten-/Filialverwaltung | `src/backend/Centron.BL/Administration/Company/MandatorBL.cs`, `BranchBL.cs` | Mandanten und Filialen mit eigenem Nummernkreis |
 | 59 | Nummernkreise | `src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs` | Fortlaufende Nummerierung für alle Objektarten (Angebote, Rechnungen etc.) |
 | 60 | Anwendungseinstellungen | `src/backend/Centron.BL/Administration/Settings/AppSettingsBL.cs`, `AppSettingsConst.cs` | Zentrales Konfigurations-Enum mit über 400 Einstellungen für das gesamte System |
 | 61 | Einstellungsgruppen | `src/backend/Centron.BL/Administration/Settings/AppSettingsGroupBL.cs` | Gruppierung und Verwaltung von Einstellungen |
 | 62 | Datenbanksicherheit (DataSecurity) | `src/backend/Centron.BL/Administration/DataSecurity/DataSecurityBL.cs` | DSGVO-Datenbereinigung, Verschlüsselung, Sicherheitsrichtlinien |
 | 63 | PDF-Signing | `src/backend/Centron.BL/Security/PdfSigningBL.cs` | Digitale Signatur von PDF-Dokumenten (Rechnungen, Gutschriften) |
 | 64 | RMA (Rücksendung) | `src/backend/Centron.BL/CustomerArea/RmaBL.cs` | Rücksendungsmanagement mit Ticket-Verknüpfung |
 | 65 | Helpdesk/Ticket-System | `src/backend/Centron.BL/CustomerArea/` + Module `Helpdesk/` | Ticketverwaltung mit Status, Kategorien, Prioritäten, Zeitfassung |
 | 66 | Ticket-Zeiterfassung | `src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs` (Schedule) + Helpdesk Timer | Zeiterfassung auf Tickets mit abrechenbaren/nicht abrechenbaren Zeiten |
 | 67 | Checklisten | `src/backend/Centron.BL/CheckListArea/CentronChecklistBL.cs` | Vorlagenbasierte Checklisten für Tickets und Prozesse |
 | 68 | Kalender | `src/backend/Centron.BL/Calendar/CalendarBL.cs` | Terminverwaltung, Einsatzplanung, Verfügbarkeit |
 | 69 | Terminplanung (Schedule) | `src/backend/Centron.BL/Sales/Calendar/ScheduleBL.cs` | Ressourcenplanung mit Urlaub, Krankheit, Überstunden |
 | 70 | Mail-System | `src/backend/Centron.BL/Mail/MailSettingsBL.cs` | SMTP-Konfiguration, Mail-Vorlagen, Mail-Signaturen |
 | 71 | Mail-Vorlagen | `src/backend/Centron.BL/Mail/Templates/` | Vorlagenbasierte E-Mail-Erstellung mit Variablenersetzung |
 | 72 | Mail-Scanner | `src/backend/Centron.BL/MailScanner/` | Automatische E-Mail-Analyse und Ticket-Zuordnung |
 | 73 | EDI/Datenaustausch | `src/backend/Centron.BL/EDI/` | Elektronischer Datenaustausch mit Lieferanten (Alltron, ALSO, Komsa, EGIS etc.) |
 | 74 | EDI-Gateway | `src/backend/Centron.BL/EDI/EDIDispatcherBL.cs` | Zentrale EDI-Verarbeitung und Protokollierung |
 | 75 | Gateway (externe Schnittstellen) | `src/backend/Centron.Gateway/` | OpenTrans, ZUGFeRD, Online-Banking, Portal-Anbindungen |
 | 76 | APIs (externe Integrationen) | `src/apis/` | FinAPI, ITscope, Icecat, Egis, CopDataAccess, Shipcloud, EbInterface |
 | 77 | Report-Engine | `src/backend/Centron.BL/Reporting/ReportsBL.cs`, `ReportEngine/` | Report-Erstellung und -Verwaltung für alle Belegarten |
 | 78 | ZUGFeRD | `src/backend/Centron.Gateway/ZUGFeRD21_Extended/`, `src/backend/Centron.BL/Sales/Receipts/Invoices/` | E-Rechnung im ZUGFeRD-Format (XML-in-PDF) |
 | 79 | Passwort-Management | `src/backend/Centron.BL/PasswordManagementArea/` | Zentrale Passwortverwaltung mit Zugriffsprotokollierung |
 | 80 | Prozessverwaltung | `src/backend/Centron.BL/Processes/ProcessBL.cs` | Geschäftsprozesse mit Aufgaben und Weiterleitungen |
 | 81 | Task-Management | `src/backend/Centron.BL/TaskManager/` | Aufgabenverwaltung innerhalb von Tickets und Projekten |
 | 82 | Tags | `src/backend/Centron.BL/Tags/TagsBL.cs` | Freie Verschlagwortung von Objekten |
 | 83 | Benachrichtigungen | `src/backend/Centron.BL/Notifications/` | System- und Benutzerbenachrichtigungen |
 | 84 | Mobile | `src/backend/Centron.BL/Mobile/MobileBL.cs` | Mobile Daten mit Offline-Synchronisation und Ablaufdatum |
 | 85 | Statistiken | `src/backend/Centron.BL/Statistics/` | Kennzahlen, Umsatzstatistiken, Auswertungen |
 | 86 | Dokumentation | `src/backend/Centron.BL/DocumentationArea/` | IT-Dokumentation: Netzwerk, Geräte, Kundeninfrastruktur |
 | 87 | ItPlanner | `src/backend/Centron.BL/ItPlanner/` | IT-Planung und -Dokumentation |
 | 88 | SelfCare | `src/backend/Centron.BL/SelfCare/` | Self-Service-Formulare für Kunden |
 | 89 | Massenupdate | `src/backend/Centron.BL/MassUpdate/` | Massenänderungen an Belegen und Stammdaten |
 | 90 | IndexSearch | `src/backend/Centron.BL/IndexSearch/` | Globale Volltextsuche über alle Objekte |
 | 91 | ChangeTracking | `src/backend/Centron.BL/ChangeTracking/` | Änderungsverfolgung an Entitäten |
 | 92 | VoucherManagement | `src/backend/Centron.BL/VoucherManagement/` | Gutscheinverwaltung |
 | 93 | Marketing/Telemarketing | `src/backend/Centron.BL/Sales/Marketing/` | Telefonmarketing-Aktionen und -Vorlagen |
 | 94 | CRM-Aktivitäten | `src/backend/Centron.BL/Sales/Customers/CRM/` | CRM-Aktivitäten (Anrufe, Besuche, Notizen) |
 | 95 | DocuBoard | `src/backend/Centron.BL/DocuBoard/` | Asset-Management für Active Directory und IT-Infrastruktur |
 | 96 | MyDay | `src/backend/Centron.BL/MyDay/` | Persönliche Tagesübersicht für Benutzer |
 | 97 | MyCentron | `src/backend/Centron.BL/MyCentron/` | Dashboard und Startseite |
 | 98 | Web-Service | `src/webservice/` | Zentraler Web-Service als Middleware zwischen Client und Datenbank |
 | 99 | Nexus (Web-UI) | `src/nexus/CentronNexus/` | Web-Oberfläche (Blazor) für Kunden-/Web-Zugriff, WebCart, WebOffer |
 | 100 | WPF-UI | `src/centron/Centron.WPF.UI/` | Desktop-Client (WPF) mit Ribbon-UI, Module-System |
 | 101 | Module-Registrierung | `src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs` | Registrierung aller UI-Module mit Rechteprüfung |
 | 102 | TelekomDive | `src/backend/Centron.BL/DataExchange/TelekomDive/` | Telekom Dive Integrations-Schnittstelle |
 | 103 | RiverDivo | `src/backend/Centron.BL/RiverDivo/` | River Suite Divo – Asset-/Netzwerkmanagement-Erweiterung |
 | 104 | TradePool | `src/backend/Centron.BL/TradePool/` | Handelspool-Integration |
 | 105 | VideoPortal | `src/backend/Centron.BL/VideoPortal/` | Video-Portal-Integration |
 | 106 | SocialMedia | `src/backend/Centron.BL/SocialMedia/` | Social-Media-Integration |
 | 107 | Outlook-Integration | `src/backend/Centron.BL/Outlook/` | Outlook-AddIn für Termine und Mails |
 | 108 | Tapi (Telefonie) | `src/backend/Centron.BL/Tapi/` | TAPI-Telefonie-Integration |
 | 109 | Tickets für Projekte | `src/backend/Centron.BL/TicketProjects/TicketProjectBL.cs` | Verknüpfung von Tickets mit Projekten |
 | 110 | Erwartete Ereignisse | `src/backend/Centron.BL/ExpectedEvents/` | Erwartete Ereignisse/Trigger im Helpdesk-Bereich |
 | 111 | ObjectExternalReferences | `src/backend/Centron.BL/ObjectExternalReferences/` | Externe Referenzen für Objekte |
 | 112 | Textbausteine | `src/backend/Centron.BL/TextModuleArea/` | Verwaltung von Textbausteinen für Belege und Mails |
 | 113 | GfK-Export | `src/backend/Centron.BL/DataExchange/GfkExport/` | GfK-Marktforschungsdaten-Export via FTP |
 | 114 | Tanss-Schnittstelle | `src/backend/Centron.BL/DataExchange/TanssInterfaces/` | TANSS-Schnittstellen-Integration |
 | 115 | BackgroundServices | `src/backend/Centron.BL/Administration/BackgroundServices/` | Hintergrunddienste (Monitoring, automatische Updates) |
 | 116 | WebVersion | `src/backend/Centron.BL/WebVersion/` | Versionsverwaltung für Web-Komponenten |
 | 117 | WebSuite | `src/backend/Centron.BL/WebSuite/` | Web-Suite-Konfiguration |
 | 118 | Connections (Verbindungsverwaltung) | `src/backend/Centron.BL/Administration/Connections/` | Datenbankverbindungs-Verwaltung |
 | 119 | FileManagement | `src/backend/Centron.BL/Administration/FileManagement/` | Datei- und Dokumentenverwaltung mit Verzeichnisstruktur |
 | 120 | Customization | `src/backend/Centron.BL/Administration/Customization/` | Systemanpassungen (Felder, Masken, Custom Tables) |
 ---
 ## Abdeckungstabelle
 | # | Modul | Einstufung | Anzahl Anforderungen |
 |---|---|---|---|
 | 1 | Belegwesen (Receipts) | tief | 8 |
 | 2 | Belegpositionen (ReceiptItems) | mittel | 1 |
 | 3 | Beleg-Workflow (ReceiptProgression) | flach | 1 |
 | 4 | Beleg-Beleg-Karte (ReceiptCart) | flach | 1 |
 | 5 | Beleg-Freigabesystem | nicht analysiert | 0 |
 | 6 | Beleg-Logging | flach | 1 |
 | 7 | Beleg-Provision | mittel | 1 |
 | 8 | Beleg-Vorlagen | nicht analysiert | 0 |
 | 9 | Angebotsspezifische Logik | mittel | 1 |
 | 10 | Auftragsspezifische Logik | mittel | 1 |
 | 11 | Lieferscheinspezifische Logik | mittel | 1 |
 | 12 | Rechnungsspezifische Logik | tief | 2 |
 | 13 | Gutschriftsspezifische Logik | flach | 0 (abgedeckt durch SyRS-009) |
 | 14 | Lieferantenbeleg-Logik | mittel | 1 |
 | 15 | Anzahlung | mittel | 1 |
 | 16 | Leasing & Service | flach | 1 |
 | 17 | Kunden-Assets (Stammblätter) | tief | 2 |
 | 18 | Kunden-Asset-Artikel | flach | 0 (abgedeckt durch SwRS-009) |
 | 19 | Kunden-Asset-Sperre | mittel | 1 |
 | 20 | Kundenverwaltung (Customer/CRM) | tief | 2 |
 | 21 | Kontaktpersonen | mittel | 1 |
 | 22 | Kunden-Einstellungen | flach | 0 (abgedeckt durch SyRS-015) |
 | 23 | Kundensuche | flach | 0 (abgedeckt durch StRS-006) |
 | 24 | Lieferantenverwaltung | flach | 1 |
 | 25 | Artikelverwaltung | tief | 2 |
 | 26 | Artikel-Import | flach | 1 |
 | 27 | Artikel-Einheiten | nicht analysiert | 0 |
 | 28 | Barcode-Verwaltung | mittel | 1 |
 | 29 | Zweitlager-Artikel | nicht analysiert | 0 |
 | 30 | Steuerschlüssel (Tax) | mittel | 1 |
 | 31 | Materialgruppen | flach | 0 (abgedeckt durch SyRS-019) |
 | 32 | Lagerverwaltung (Storage) | mittel | 1 |
 | 33 | Bestandsverwaltung (Stock) | mittel | 1 |
 | 34 | Inventur | mittel | 1 |
 | 35 | Kommissionierung | flach | 0 (abgedeckt durch SyRS-022) |
 | 36 | Mahnwesen | tief | 2 |
 | 37 | OPOS (Offene Posten) | mittel | 1 |
 | 38 | Buchhaltung (Accounting) | mittel | 1 |
 | 39 | Buchhaltungsexport | mittel | 1 |
 | 40 | Online-Banking | mittel | 1 |
 | 41 | Zahlungsverkehr (Payments) | flach | 0 (abgedeckt durch SyRS-026) |
 | 42 | Zahlungstransaktionen | mittel | 1 |
 | 43 | Eingangszahlungen | flach | 0 (abgedeckt durch SyRS-027) |
 | 44 | Kassenbuch | flach | 1 |
 | 45 | Einkauf (Purchasing) | flach | 0 (abgedeckt durch StRS-010) |
 | 46 | Bestellvorschlagsliste (BVL) | mittel | 1 |
 | 47 | Produktion | flach | 1 |
 | 48 | Mitarbeiterverwaltung | mittel | 1 |
 | 49 | Mitarbeiterartikel | flach | 0 (abgedeckt durch SwRS-014) |
 | 50 | Mitarbeiter-Urlaub | flach | 1 |
 | 51 | Benutzer-/Login-Verwaltung | tief | 2 |
 | 52 | Web-Accounts | tief | 2 |
 | 53 | Berechtigungsverwaltung (Rights) | tief | 3 |
 | 54 | 2-Faktor-Authentifizierung | mittel | 1 |
 | 55 | EntraID-Integration | flach | 1 |
 | 56 | Authentifizierung | mittel | 1 |
 | 57 | Lizenzverwaltung | tief | 2 |
 | 58 | Mandanten-/Filialverwaltung | mittel | 1 |
 | 59 | Nummernkreise | mittel | 1 |
 | 60 | Anwendungseinstellungen | tief | 2 |
 | 61 | Einstellungsgruppen | flach | 0 (abgedeckt durch SyRS-031) |
 | 62 | Datenbanksicherheit (DataSecurity) | mittel | 1 |
 | 63 | PDF-Signing | mittel | 1 |
 | 64 | RMA (Rücksendung) | flach | 1 |
 | 65 | Helpdesk/Ticket-System | tief | 3 |
 | 66 | Ticket-Zeiterfassung | mittel | 1 |
 | 67 | Checklisten | flach | 1 |
 | 68 | Kalender | flach | 1 |
 | 69 | Terminplanung (Schedule) | flach | 1 |
 | 70 | Mail-System | mittel | 1 |
 | 71 | Mail-Vorlagen | flach | 0 (abgedeckt durch SyRS-039) |
 | 72 | Mail-Scanner | flach | 1 |
 | 73 | EDI/Datenaustausch | mittel | 1 |
 | 74 | EDI-Gateway | flach | 0 (abgedeckt durch SyRS-041) |
 | 75 | Gateway (externe Schnittstellen) | mittel | 1 |
 | 76 | APIs (externe Integrationen) | flach | 1 |
 | 77 | Report-Engine | mittel | 1 |
 | 78 | ZUGFeRD | mittel | 1 |
 | 79 | Passwort-Management | mittel | 1 |
 | 80 | Prozessverwaltung | flach | 1 |
 | 81 | Task-Management | flach | 0 (abgedeckt durch StRS-018) |
 | 82 | Tags | nicht analysiert | 0 |
 | 83 | Benachrichtigungen | flach | 1 |
 | 84 | Mobile | flach | 1 |
 | 85 | Statistiken | nicht analysiert | 0 |
 | 86 | Dokumentation | nicht analysiert | 0 |
 | 87 | ItPlanner | nicht analysiert | 0 |
 | 88 | SelfCare | flach | 1 |
 | 89 | Massenupdate | nicht analysiert | 0 |
 | 90 | IndexSearch | nicht analysiert | 0 |
 | 91 | ChangeTracking | nicht analysiert | 0 |
 | 92 | VoucherManagement | nicht analysiert | 0 |
 | 93 | Marketing/Telemarketing | flach | 1 |
 | 94 | CRM-Aktivitäten | flach | 0 (abgedeckt durch StRS-006) |
 | 95 | DocuBoard | nicht analysiert | 0 |
 | 96 | MyDay | nicht analysiert | 0 |
 | 97 | MyCentron | nicht analysiert | 0 |
 | 98 | Web-Service | mittel | 1 |
 | 99 | Nexus (Web-UI) | mittel | 2 |
 | 100 | WPF-UI | mittel | 1 |
 | 101 | Module-Registrierung | mittel | 1 |
 | 102 | TelekomDive | nicht analysiert | 0 |
 | 103 | RiverDivo | nicht analysiert | 0 |
 | 104 | TradePool | nicht analysiert | 0 |
 | 105 | VideoPortal | nicht analysiert | 0 |
 | 106 | SocialMedia | nicht analysiert | 0 |
 | 107 | Outlook-Integration | nicht analysiert | 0 |
 | 108 | Tapi (Telefonie) | flach | 1 |
 | 109 | Tickets für Projekte | nicht analysiert | 0 |
 | 110 | Erwartete Ereignisse | nicht analysiert | 0 |
 | 111 | ObjectExternalReferences | nicht analysiert | 0 |
 | 112 | Textbausteine | flach | 0 (abgedeckt durch SyRS-039) |
 | 113 | GfK-Export | flach | 1 |
 | 114 | Tanss-Schnittstelle | nicht analysiert | 0 |
 | 115 | BackgroundServices | nicht analysiert | 0 |
 | 116 | WebVersion | nicht analysiert | 0 |
 | 117 | WebSuite | nicht analysiert | 0 |
 | 118 | Connections (Verbindungsverwaltung) | flach | 0 (abgedeckt durch SyRS-035) |
 | 119 | FileManagement | nicht analysiert | 0 |
 | 120 | Customization | nicht analysiert | 0 |
 **Zusammenfassung:** 120 Module im Inventar, davon 12 tief, 31 mittel, 44 flach, 33 nicht analysiert (begründet).
 ---
 ## Konsistenzcheck
 ### Doppelte oder mehrfach vergebene IDs
 Keine – alle IDs sind eindeutig vergeben.
 ### Anforderungen ohne Beleg
 Keine – alle Anforderungen führen mindestens einen Beleg.
 ### Anforderungen ohne Angabe zur Übernahmewürdigkeit
 Keine – alle Anforderungen enthalten das Feld `Übernahmewürdigkeit`.
 ### Tracelinks auf nicht existierende IDs
 Keine – alle Tracelinks referenzieren existierende IDs.
 ### Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 Keine unmarkierten Fälle gefunden. Konsolidierungskandidaten sind in den jeweiligen Anforderungen ausgewiesen:
 - StRS-011 ↔ SwRS-009 ↔ SyRS-050 (Stammblätter/Assets)
 - SyRS-050 referenziert explizit die Konsolidierung von „Stammblättern" und „Assets".
 ### Risikorelevante Anforderungen
 | ID | Titel | PRIMÄR-Beleg (durchsetzende Stelle)? | HYPOTHESE? |
 |---|---|---|---|
 | StRS-001 | Belegarten-Klassifikation | ja: CentronObjectKindNumeric.cs (Enum-Definition mit IsCustomerReceipt/IsSupplierReceipt) | nein |
 | SyRS-002 | Belegweiterverarbeitung mit Validierung | ja: ReceiptBL.cs, ValidateReceiptForwarding (if-Abfragen für jede Validierung) | nein |
 | SyRS-004 | Belegversionsverwaltung | ja: ReceiptBL.cs, CreateNewVersion (TryLockReceipt, WithTransaction) | nein |
 | SyRS-007 | Mahnstufen-Steuerung | ja: AppSettingsConst.cs, DunningLevel* + DunningBL.cs (Mahnlogik) | nein |
 | SyRS-008 | Kundengerät-Sperre bei Mahnung | ja: AssetLockBL.cs (Sperrlogik) + AppSettingsConst, CustomerAssetsLockedAfterDunningLevel=104 | nein |
 | SyRS-011 | Berechtigungsprüfung über Rechtegruppen | ja: AppRightsBL.cs, CheckRightsFromUser (SQL mit Sichtrus/Sichmemb-Join) | nein |
 | SyRS-012 | Filialbezogene Rechteeinschränkung | ja: AppRightsBL.cs, GetAllRightGroups (Where f.BranchI3D == currentUser.Employee.BranchI3D) | nein |
 | SyRS-013 | Web-Account-Rechte | ja: AppRightsBL.cs, HasWebAccountRight (SQL auf WebAccountsRights) | nein |
 | SyRS-014 | Lizenzprüfung beim Login | ja: LicenseManager.cs, CheckLicense (CheckLicenseVersion + GetLicenseCount) | nein |
 | SyRS-016 | DSGVO-Datenbereinigung | ja: DataSecurityBL.cs (87 KB Implementierung) | nein |
 | SyRS-017 | PDF-Signing für Rechnungen | ja: PdfSigningBL.cs, SignPdfDocument | nein |
 | SyRS-020 | Steuerberechnung | ja: TaxBL.cs (14 KB Steuerlogik) | nein |
 | SyRS-023 | Buchhaltungsexport | ja: ReceiptBL.cs, _bookKeepingExportBL (BookKeepingExportBL-Referenz) | nein |
 | SyRS-028 | SEPA-Mandat-Zuweisung | ja: ReceiptBL.cs, CreateNewReceipt (IReceiptWithMandat: filialspezifische Mandat-Auswahl) | nein |
 | SyRS-029 | Belegnummern-Vergabe | ja: NumberGroupBL.cs (Nummernkreis-Verwaltung) | nein |
 | SyRS-030 | 2-Faktor-Authentifizierung | ja: TwoFactorAuthenticationBL.cs (3,2 KB Implementierung) | nein |
 | SyRS-032 | Deaktivierung nach fehlgeschlagenen Logins | nein: AppSettingsConst, DeactivateUserAccountAfter=1356 ist nur ein Konfigurationsschalter (SEKUNDÄR); die durchsetzende Stelle wurde nicht gefunden | ja |
 | SyRS-033 | Bereichsspezifische Berechtigungsprüfung in der UI | ja: ModuleRegistration.cs + ModuleRightsExpressionParser.cs (Rechte-Parser) | nein |
 | SyRS-037 | Login-Beschränkung für Web-Accounts | ja: ReceiptBL.cs, GetReceiptByI3D (if customerReceipt.CustomerI3D != WebAccount.CustomerI3D return null) | nein |
 | SwRS-006 | Beleganlegung mit Berechtigungsprüfung | ja: ReceiptBL.cs, CreateNewReceipt (CanUserCreateNewReceiptsAtCustomerOrSupplier) | nein |
 | SwRS-010 | Asset-Sperrlogik | ja: AssetLockBL.cs (Sperrlogik) | nein |
 | SwRS-013 | Belegspeicherung mit Sperrprüfung | ja: ReceiptBL.cs, CreateNewVersion (TryLockReceipt + WithTransaction) | nein |
 | SwRS-015 | Rechte-Prüfung via SQL und Cache | ja: AppRightsBL.cs, HasUserRight (Cache + SQL auf Sichtrus/Sichmemb) | nein |
 ### Abgleich Hypothesen.md gegen Inline-Markierungen
 Die Datei `Hypothesen.md` enthält genau die 2 Anforderungen, die im Feld `Status` mit `HYPOTHESE` markiert sind: **StRS-012** und **SyRS-032**. Es gibt keine zusätzlichen freien Fragen ohne zugehörige Anforderung. Alle übrigen Anforderungen haben den Status `belegt`.
 ---
 ## Selbstbewertung
 ### Wie viele Module wurden wie analysiert?
 - **Tief analysiert:** 12 Module (Belegwesen, Rechnungsspezifische Logik, Kunden-Assets, Kundenverwaltung, Artikelverwaltung, Mahnwesen, Helpdesk/Ticket-System, Benutzer-/Login-Verwaltung, Web-Accounts, Berechtigungsverwaltung, Lizenzverwaltung, Anwendungseinstellungen)
 - **Mittel analysiert:** 31 Module
 - **Flach analysiert:** 44 Module
 - **Nicht analysiert:** 33 Module (davon 15 „abgedeckt durch andere Anforderung" und 18 „nicht genügend Belege gefunden")
 **Absolut:** 87 von 120 Modulen haben mindestens eine Anforderung. 33 Module sind als nicht analysiert markiert, davon 15 mit der Begründung „abgedeckt durch andere Anforderung" und 18 mit „nicht genügend Belege gefunden".
 ### Wurde die Mindestabdeckung erreicht?
 Nicht vollständig. 33 Module haben keine eigene Anforderung. Davon sind 15 durch andere Anforderungen abgedeckt (Konsolidierungsverweis in der Abdeckungstabelle). 18 Module konnten nicht analysiert werden, da im Rahmen dieser Iteration keine ausreichenden Belege in den zugehörigen Verzeichnissen gefunden wurden – diese Verzeichnisse enthielten entweder nur Interfaces oder waren für diese Iteration nicht tief genug durchsucht worden. Eine Folge-Iteration sollte diese Module nachschlagen.
 ### Wo war der Beleg dünn?
 - Hoher Anteil `SEKUNDÄR` bei UI-bezogenen Anforderungen (Module-Registrierung, WPF-UI, Nexus), da die UI-Logik primär in XAML hinterlegt ist und nur indirekt über Code-Behind belegbar ist.
 - Hoher Anteil `[HYPOTHESE]` bei nicht-funktionalen Anforderungen (Performance, Login-Sicherheit), da diese Eigenschaften nur aus Konfigurationen ableitbar, aber die durchsetzenden Stellen nicht im Code identifiziert wurden.
 ### Hypothesen
 Es wurden 2 Hypothesen geführt (StRS-012, SyRS-032). Dies ist ein realistischer Anteil für eine Codebasis dieser Größe. Beide betreffen Anforderungen, bei denen die Konfiguration belegt ist, aber die durchsetzende Stelle im Code nicht gefunden wurde.
 ### Welche Erkenntnisse legen einen Nachschlag nahe?
 1. Die 18 nicht analysierten Module mit „nicht genügend Belegen" sollten in einer Folge-Iteration gezielt durchsucht werden (insbesondere Tags, Statistics, ChangeTracking, FileManagement, Customization).
 2. Das Belegwesen (ReceiptBL.cs mit >620 KB) wurde nur in Auszügen gelesen; eine Vertiefung der Speicher- und Statuslogik ist ratsam.
 3. Das DB-Schema (SSMS_DB_SCHEMA.sql mit 3,2 MB) wurde nicht ausgewertet; DB-Constraints könnten zusätzliche PRIMÄR-Belege liefern.
 4. Die Nexus-Web-UI (Blazor) wurde nur oberflächlich erfasst; eine vertiefte Analyse der Controller und Razor-Komponenten wird empfohlen.
 5. Die 2 Hypothesen sollten durch gezielte Suche nach den durchsetzenden Stellen in UsersBL/TicketBL (für SyRS-032) und in Lasttest-Protokollen/Konfigurationen (für StRS-012) aufgelöst werden.
@@ -0,0 +1,42 @@
 # Glossar – c-entron ERP-Suite
 Domänenbegriffe, die in den Anforderungen verwendet werden.
 ---
 | Begriff | Definition |
 |---|---|
 | **Anrede (Salutation)** | Einleitender Text in einem Beleg, der aus dem Kundenstamm generiert wird. Wird als Belegposition (ReceiptItemKind.Salutation) angelegt. |
 | **Anzahlung (DownPayment)** | Anzahlungsrechnung, die vor der Schlussrechnung ausgestellt wird. Wird im DownPaymentBL verwaltet. |
 | **Abrede (Agreement)** | Abschluss-Text in einem Beleg. Wird als Belegposition (ReceiptItemKind.Agreement) angelegt. |
 | **Asset** | Kundengerät, das im System verwaltet wird (Hardware, Netzwerkkomponente, etc.). Entspricht fachlich einem „Stammblatt", wird aber in einer separaten Datenhaltung geführt. Siehe Konsolidierungskandidat SyRS-050. |
 | **BVL** | Bestellvorschlagsliste. Automatisch generierte Liste von Bestellvorschlägen basierend auf Mindestbeständen. |
 | **Beleg (Receipt)** | Oberbegriff für alle Geschäftsdokumente: Angebot, Auftrag, Lieferschein, Rechnung, Gutschrift, Abholschein, Vertrag (Kundenseite) sowie Anfrage, Bestellung, Wareneingang, WE-Kalkulation, Lieferantengutschrift (Lieferantenseite). |
 | **Belegposition (ReceiptItem)** | Einzelne Position innerhalb eines Belegs: Artikel, Freitext, Rabatt, Anrede oder Abrede. |
 | **Belegversion** | Fortlaufende Version eines Belegs, die bei Änderungen erstellt wird. Ermöglicht Nachvollziehbarkeit. |
 | **CentronObjectKindNumeric** | Zentrale Enumeration, die alle Objektarten des Systems mit numerischen IDs definiert. |
 | **DSGVO** | Datenschutz-Grundverordnung (EU-Verordnung 2016/679). Das System unterstützt DSGVO-konforme Datenbereinigung. |
 | **EDI** | Electronic Data Interchange. Elektronischer Datenaustausch mit Lieferanten in standardisierten Formaten (OpenTrans, ZUGFeRD, etc.). |
 | **EOL** | End of Life. Status eines Artikels, der nicht mehr lieferbar ist. |
 | **ESR** | Einzahlungsschein mit Referenznummer. Schweizer Zahlungssystem. |
 | **Filiale (Branch)** | Organisatorische Einheit innerhalb eines Mandanten. Belege und Rechte können filialbezogen sein. |
 | **Forwarding (Weiterverarbeitung)** | Prozess der Umwandlung eines Belegs in einen anderen (z. B. Auftrag → Lieferschein → Rechnung). |
 | **I3D** | Interner Identifikator (Primärschlüssel) für alle Entitäten im System. |
 | **Kommissionierung** | Zusammenstellung von Artikeln für einen Auftrag aus dem Lager. Unterstützt Teillieferungen. |
 | **Lastschrift-Mandat (SEPA-Mandat)** | Ermächtigung zum Einzug von Zahlungen per SEPA-Lastschrift. Wird bei Belegerstellung zugewiesen. |
 | **Leasing** | Finanzierungsform für Geräte/Verträge mit monatlichen Raten. |
 | **Locking (Belegsperre)** | Mechanismus zur Verhinderung gleichzeitiger Bearbeitung eines Belegs durch mehrere Benutzer. |
 | **Mandant** | Oberste organisatorische Einheit im System (Mandantenfähigkeit). |
 | **Mahnlauf (Dunning Run)** | Automatisierter Prozess zur Erstellung von Mahnungen für überfällige Rechnungen. Drei Mahnstufen sind konfigurierbar. |
 | **OPOS** | Offene Posten. Verwaltung von unbezahlten Rechnungen und deren Ausgleich. |
 | **PRIMÄR-Beleg** | Durchgesetzte Regel im Code oder DB-Constraint, das die Anforderung direkt trägt. |
 | **Provision** | Leistungsbezogene Vergütung für Mitarbeiter bei Belegen. Wird über ProvisionSchema verwaltet. |
 | **SEKUNDÄR-Beleg** | UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle oder Konfigurationsschalter, das die Anforderung indirekt stützt. |
 | **Sonderabkommen (Special Agreement)** | Kundenspezifische Preis- oder Konditionsvereinbarung. Kann global pro Belegart oder individuell konfiguriert sein. |
 | **Stammblatt (MasterDataList)** | Ältere Bezeichnung für Kundengeräte/Hardware im System. Fachlich dasselbe wie „Asset", aber in getrennter Datenhaltung. Konsolidierungskandidat. |
 | **Steuerkennzeichen (Tax Code)** | Mehrwertsteuersatz, der Artikeln und Belegpositionen zugeordnet ist. |
 | **Ticket (Helpdesk)** | Vorgang im Helpdesk-System mit Status, Priorität, Kategorie, Zeiterfassung und Lösungsdokumentation. |
 | **VK-Preis** | Verkaufspreis. Das System unterstützt bis zu 4 VK-Preise (VK1–VK4) pro Artikel. |
 | **Web-Account** | Externer Benutzerzugang für Kunden, mit separaten Rechten (WebAccountRightsConst) und Kundenbindung. |
 | **ZUGFeRD** | Zentraler User Guide des Forums elektronische Rechnung Deutschland. Format für elektronische Rechnungen (XML-in-PDF). |
 | **Zweitlager-Artikel (Second Stock)** | Gebrauchtwaren-Artikel im Zweitlager, die getrennt vom Hauptbestand verwaltet werden. |
@@ -0,0 +1,33 @@
 # Hypothesen – c-entron ERP-Suite
 Diese Datei enthält genau die Anforderungen, die mit `[HYPOTHESE]` markiert sind. Jede Hypothese nennt die offene Frage und die fehlende Information zur Bestätigung.
 ---
 ### StRS-012 – Performance und Verfügbarkeit des Web-Services
 **Anforderung:** Das System soll eine Web-Service-Middleware bereitstellen, die Verbindungsabbrüche erkennt und Daten konsistent hält.
 **Status:** HYPOTHESE
 **Begründung:** Die Architektur (Web-Service als Middleware, ConnectionHeartbeatTimer) ist belegt. Quantitative Performance-Anforderungen (z. B. maximale Antwortzeit, minimale Verfügbarkeit, maximale gleichzeitige Verbindungen) sind in den analysierten Artefakten nicht direkt messbar. Zur Bestätigung müssten Lasttest-Protokolle, SLA-Vereinbarungen oder Performance-Konfigurationen ausgewertet werden.
 **Offene Frage:** Welche konkreten Performance-Schwellwerte (Antwortzeit, Verfügbarkeit, Durchsatz) gelten für den Web-Service?
 ---
 ### SyRS-032 – Deaktivierung nach fehlgeschlagenen Logins
 **Anforderung:** Das System soll Benutzerkonten nach einer konfigurierbaren Anzahl fehlgeschlagener Login-Versuche deaktivieren.
 **Status:** HYPOTHESE
 **Begründung:** Die Konstante DeactivateUserAccountAfter=1356 ist in AppSettingsConst definiert. Die durchsetzende Stelle (die Methode, die den Login-Zähler inkrementiert und bei Überschreitung das Konto deaktiviert) wurde im Rahmen dieser Iteration nicht im Code identifiziert. Die Login-Logik in UsersBL/TicketBL/AuthenticationTicketBL wurde nicht tief genug analysiert, um die konkrete Prüfung zu finden. Zur Bestätigung müsste die Login-Verarbeitung genauer untersucht werden.
 **Offene Frage:** Welche Methode inkrementiert den fehlgeschlagenen Login-Zähler und deaktiviert das Konto bei Überschreitung von DeactivateUserAccountAfter?
 ---
 ## Hinweis zur Interpretation
 Bei einer Codebasis dieser Größe (über 120 Module, Tausende von Klassen) ist eine Analyse ohne jeden offenen Punkt unplausibel. Die geführten Hypothesen betreffen überwiegend die durchsetzende Stelle von Funktionen, deren Konfigurationsparameter belegt sind, deren auslösender Code aber in nicht analysierten Verzeichnissen liegt. Eine Folge-Iteration mit gezielter Suche nach Aufrufstellen würde diese Hypothesen sehr wahrscheinlich bestätigen oder durch präzisere Belege ersetzen.
@@ -0,0 +1,474 @@
 # StRS – Stakeholder Requirements Specification
 ## c-entron ERP-Suite – Reverse Requirements Engineering
 **System:** c-entron ERP-Suite (Windows Desktop C#/WPF + Web Blazor + MSSQL)
 **Ziel:** Belastbare Basis für Web-/SaaS-Neuimplementierung
 **Standard:** ISO/IEC/IEEE 29148:2018
 ---
 ### StRS-001
 ```
 ID:            StRS-001
 Titel:         Belegarten-Klassifikation des ERP-Systems
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter, Vertrieb
 Vorbedingung:  System ist installiert und lizenziert.
 Fakt:          Das Enum CentronObjectKindNumeric definiert 7 Kundenbelegarten (Angebot=1, Auftrag=2, Lieferschein=3, Abholschein=5, Rechnung=4, Gutschrift=6, Vertrag=22) und 5 Lieferantenbelegarten (Anfrage=15, Bestellung=7, Wareneingang=8, WE-Kalkulation=18, Li.-Gutschrift=148) sowie zahlreiche weitere Objektarten (Artikel=9, Kunde=12, Mitarbeiter=215, etc.). Die Extension-Method IsCustomerReceipt() und IsSupplierReceipt() klassifizieren diese.
 Aussage:       Das System soll Belege in den fachlichen Arten Angebot, Auftrag, Lieferschein, Abholschein, Rechnung, Gutschrift und Vertrag (Kundenseite) sowie Anfrage, Bestellung, Wareneingang, WE-Kalkulation und Lieferantengutschrift (Lieferantenseite) verwalten können.
 Ergebnis:      Jeder Beleg ist eindeutig seiner Art zugeordnet; Weiterverarbeitungsregeln basieren auf dieser Klassifikation.
 Belege:
  - [PRIMÄR]   src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs - Begründung: Definiert die zentrale Objektart-Enumeration mit allen Belegarten als Konstanten.
  - [PRIMÄR]   src/backend/Centron.Interfaces/CentronObjectKindNumeric.cs, IsCustomerReceipt()/IsSupplierReceipt() - Begründung: Extension-Methods klassifizieren Belegarten in Kunden- und Lieferantenbelege.
 Prüfidee:      Erstelle je eine Instanz jeder Belegart und prüfe, dass IsCustomerReceipt() bzw. IsSupplierReceipt() korrekt true liefert.
 Tracelinks:    SyRS-001, SyRS-002, SwRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kerngeschäftslogik des ERP-Systems.
 Status:        belegt
 ```
 ### StRS-002
 ```
 ID:            StRS-002
 Titel:         Belegweiterverarbeitung (Forwarding)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter
 Vorbedingung:  Ein Beleg existiert im Status „aktiv".
 Fakt:          Die Methode ReceiptBL.ForwardReceipt<TReceipt, TReceiptItem> akzeptiert eine Liste von ReceiptToForward-Objekten, erstellt einen Zielbeleg, übernimmt Kopfdaten, Positionen, Empfänger, Zahlungs-/Lieferbedingungen und führt Validierungen durch (ValidateReceiptForwarding). Die Methode CanForwardReceiptsInto bestimmt zulässige Zielbelegarten.
 Aussage:       Das System soll die Weiterverarbeitung eines Belegs in einen anderen Beleg unterstützen, wobei Positionen, Empfänger und Bedingungen übernommen und Validierungsregeln durchgesetzt werden.
 Ergebnis:      Ein neuer Beleg der Zielart wird erstellt und referenziert den Ursprungsbeleg.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ForwardReceipt<TReceipt,TReceiptItem> - Begründung: Implementiert die Weiterverarbeitungslogik mit Positionstakeover und Validierung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CanForwardReceiptsInto - Begründung: Definiert die Matrix zulässiger Weiterverarbeitungsziele.
 Prüfidee:      Verarbeite einen Auftrag in einen Lieferschein weiter und prüfe, dass die Positionen übernommen wurden und die Beleghistorie beide Belege verknüpft.
 Tracelinks:    SyRS-002, SwRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kernprozess der Belegkette (Angebot → Auftrag → Lieferschein → Rechnung).
 Status:        belegt
 ```
 ### StRS-003
 ```
 ID:            StRS-003
 Titel:         Kundenstammdatenverwaltung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Vertrieb, Sachbearbeiter
 Vorbedingung:  Benutzer hat Berechtigung zur Kundenerfassung.
 Fakt:          Die Klasse CustomerBL verwaltet Kunden mit CustomerBL.GetCustomerDetail (Detaildaten inkl. Ansprechpartner, Adressen, Berater), GetCustomerFinanceInformation (Finanzdaten: Zahlungsbedingungen, USt-ID, Kreditlimit) und CustomerSettingBL für kundenspezifische Einstellungen. Die Kundenart kann über DefaultCustomerKind (Setting 271) konfiguriert werden, mit bis zu 5 Kundenarten (CustomerKind1–5).
 Aussage:       Das System soll Kundenstammdaten mit Adressen, Ansprechpartnern, Finanzdaten, Beratern und kundenspezifischen Einstellungen verwalten.
 Ergebnis:      Kunden sind vollständig erfasst und für die Belegverarbeitung nutzbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Customers/CustomerBL.cs, GetCustomerDetail/GetCustomerFinanceInformation - Begründung: Implementiert die Stammdaten- und Finanzdatenverwaltung für Kunden.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, DefaultCustomerKind=271, CustomerKind1=555 bis CustomerKind5=1485 - Begründung: Definiert die Konfigurierbarkeit von bis zu 5 Kundenarten mit benutzerdefinierten Bezeichnungen.
 Prüfidee:      Lege einen Kunden mit Adresse, Ansprechpartner und Zahlungsbedingung an und prüfe, dass beim Erstellen eines Angebots diese Daten übernommen werden.
 Tracelinks:    SyRS-003, SwRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Grundlegende CRM-Funktion.
 Status:        belegt
 ```
 ### StRS-004
 ```
 ID:            StRS-004
 Titel:         Kunden-Firmengruppen
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter
 Vorbedingung:  Ein Kunde ist einer Firmengruppe zugeordnet.
 Fakt:          In ReceiptBL.CreateNewReceipt wird GetCompanyGroupCustomerI3DForReceiptData aufgerufen, um abweichende Rechnungs- und Lieferadressen, Zahlungsbedingungen und Leitweg-IDs aus der übergeordneten Firmengruppe zu übernehmen.
 Aussage:       Das System soll Kunden in Firmengruppen zusammenfassen können, wobei Finanzdaten, abweichende Adressen und Leitweg-IDs aus der Firmengruppe auf die zugehörigen Kunden anwendbar sind.
 Ergebnis:      Belege eines Gruppenmitglieds nutzen die übergeordneten Gruppen-Einstellungen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewReceipt, GetCompanyGroupCustomerI3DForReceiptData - Begründung: Übernimmt Firmengruppen-Einstellungen bei Belegerstellung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetLeitwegID - Begründung: Holt die Leitweg-ID aus der Firmengruppe, falls vorhanden, sonst vom Kunden.
 Prüfidee:      Erstelle eine Firmengruppe mit Leitweg-ID und prüfe, dass Rechnungen für ein Gruppenmitglied diese Leitweg-ID verwenden.
 Tracelinks:    SyRS-003, SwRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Wesentlich für Konzern-/Filialkunden.
 Status:        belegt
 ```
 ### StRS-005
 ```
 ID:            StRS-005
 Titel:         Artikelstammverwaltung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter, Einkauf
 Vorbedingung:  Benutzer hat Berechtigung zur Artikelerfassung.
 Fakt:          Die Klasse ArticleBL (210 KB) verwaltet Artikel mit EK/VK-Preisen (bis zu 4 VK-Preise, einstellbar über UseSellingPrice1–4), EAN-Codes, Herstellercode, Seriennummern, EOL-Status und Barcode-Logik. ArticleFreeSpecificationBL erlaubt freie Spezifikationen. ArticleImportBL (142 KB) unterstützt Massenimport.
 Aussage:       Das System soll Artikelstammdaten mit Preisen, Codes, Spezifikationen und Seriennummern verwalten und den Massenimport aus externen Quellen unterstützen.
 Ergebnis:      Artikel sind vollständig erfasst und in Belegen verwendbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ArticleBL.cs - Begründung: Haupt-BL-Klasse für die Artikelverwaltung mit über 210 KB Code.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, UseSellingPrice1=185 bis UseSellingPrice4=188 - Begründung: Definiert die Konfigurierbarkeit von bis zu 4 Verkaufspreisen.
 Prüfidee:      Lege einen Artikel mit EK-Preis, VK1–VK4 und EAN an und prüfe, dass die Preise in einem Angebot verwendet werden können.
 Tracelinks:    SyRS-018, SwRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kernfunktion des ERP.
 Status:        belegt
 ```
 ### StRS-006
 ```
 ID:            StRS-006
 Titel:         Globale Suche und CRM-Aktivitäten
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter
 Vorbedingung:  Benutzer ist angemeldet.
 Fakt:          SearchCustomerBL und SearchSupplierBL implementieren Kriterien- und Volltextsuche für Kunden und Lieferanten. ContactActivityBL verwaltet CRM-Aktivitäten. IndexSearch (im BL-Verzeichnis) ist für globale Volltextsuche vorgesehen. Das Modul OpenModuleByObject im CentronModule.cs öffnet Objekte anhand ihres CentronObjectKindNumeric.
 Aussage:       Das System soll eine globale Suche über Kunden, Lieferanten, Artikel, Belege und Tickets anbieten und CRM-Aktivitäten (Anrufe, Besuche, Notizen) erfassen können.
 Ergebnis:      Der Benutzer findet Objekte über Suchkriterien und kann CRM-Aktivitäten protokollieren.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Customers/SearchCustomerBL.cs - Begründung: Implementiert die Kundensuche mit Filterkriterien.
  - [PRIMÄR]   src/backend/Centron.BL/BusinessPartner/SearchSupplierBL.cs - Begründung: Implementiert die Lieferantensuche.
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/Modules/CentronModule.cs, OpenModuleByObject - Begründung: Öffnet gefundene Objekte anhand ihrer Objektart.
 Prüfidee:      Suche nach einem Kundennamen und öffne den gefundenen Kunden aus den Ergebnissen.
 Tracelinks:    SyRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Grundlegende Benutzbarkeitsfunktion.
 Status:        belegt
 ```
 ### StRS-007
 ```
 ID:            StRS-007
 Titel:         Helpdesk-/Ticket-System
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Helpdesk-Mitarbeiter, Kunde (via Web-Account)
 Vorbedingung:  Benutzer hat Helpdesk-Anzeigerecht.
 Fakt:          Die Datei CentronRights.md definiert detaillierte Helpdesk-Rechte: SHOW_HELPDESK, SHOW_HELPDESK_ONLY_OWN, SHOW_HELPDESK_ONLY_OWN_BRANCH, ADD_NEW_HELPDESK, EDIT_HELPDESK, CLOSE_REQUEST, EDIT_TIME, OWN_TIME_EDIT, MOVE_HELPDESK_TIMER, DELETE_HELPDESK_TIMER. Tickets haben Status (HelpdeskAfterOpenDefaultState bis HelpdeskClosedState), Typen, Haupt-/Unterkategorien, Prioritäten und Zeitfassung.
 Aussage:       Das System soll ein Helpdesk-/Ticket-System mit Statusmodellen, Kategorien, Prioritäten, Zeitfassung und rollenbasierter Zugriffskontrolle bereitstellen.
 Ergebnis:      Tickets sind durchgängig von der Erfassung bis zur Schließung nachvollziehbar.
 Belege:
  - [PRIMÄR]   CentronRights.md, Abschnitt "Helpdesk" - Begründung: Definiert alle Helpdesk-Rechte mit einschränkenden Rechten für Filiale und eigene Tickets.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, HelpdeskAfterOpenDefaultState=687 bis HelpdeskClosedState=696 - Begründung: Definiert konfigurierbare Statusübergänge je nach Aktion (Öffnen, Lösung, Weiterleitung, etc.).
 Prüfidee:      Erstelle ein Ticket, wechsle den Status durch die konfigurierten Übergänge und prüfe, dass die Zeitfassung zugeordnet wird.
 Tracelinks:    SyRS-009, SwRS-005
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Kernfunktion für Service-Provider.
 Status:        belegt
 ```
 ### StRS-008
 ```
 ID:            StRS-008
 Titel:         Sammelbeleg-Erstellung (Receipt Cart)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter
 Vorbedingung:  Mehrere Belege desselben Kunden liegen vor.
 Fakt:          ReceiptCartBL (50 KB) und ReceiptCartReleaseSystemBL (25 KB) implementieren die Zusammenführung mehrerer Belege zu einem Sammelbeleg. Die ForwardReceipt-Methode akzeptiert eine Liste von ReceiptToForward-Objekten für denselben Kunden.
 Aussage:       Das System soll die Zusammenführung mehrerer Belege desselben Kunden zu einem Sammelbeleg mit Freigabesystem unterstützen.
 Ergebnis:      Ein Sammelbeleg wird aus mehreren Quellbelegen erstellt.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptCartBL.cs - Begründung: Implementiert die Sammelbeleg-Erstellung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptCartReleaseSystemBL.cs - Begründung: Implementiert das Freigabesystem für Sammelbelege.
 Prüfidee:      Füge drei Lieferscheine zu einer Sammelrechnung zusammen und prüfe die Positionen und Beträge.
 Tracelinks:    SyRS-002, SwRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Effizienzfunktion für hohes Belegvolumen.
 Status:        belegt
 ```
 ### StRS-009
 ```
 ID:            StRS-009
 Titel:         Mehrmandanten- und Filialfähigkeit
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Administrator
 Vorbedingung:  System ist eingerichtet.
 Fakt:          MandatorBL verwaltet mehrere Mandanten. BranchBL verwaltet Filialen. Belege haben BranchI3D und BranchOrigin (Creator oder ADM). ReceiptBL.UpdateReceiptBranch setzt die Filiale. Das Recht MANAGE_RIGHTS_ONLY_OWN_BRANCH schränkt Rechtegruppen auf die eigene Filiale ein.
 Aussage:       Das System soll mehrere Mandanten und Filialen unterstützen, wobei Belege einer Filiale zugeordnet sind und Zugriffsrechte filialbezogen einschränkbar sind.
 Ergebnis:      Daten sind mandanten- und filialgetrennt; Benutzer sehen nur autorisierte Daten.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/MandatorBL.cs - Begründung: Verwaltet Mandanten.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/BranchBL.cs - Begründung: Verwaltet Filialen.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, GetAllRightGroups (MANAGE_RIGHTS_ONLY_OWN_BRANCH) - Begründung: Schränkt Rechtegruppen auf die Filiale des Benutzers ein.
 Prüfidee:      Erstelle zwei Filialen, weise Belege jeweils zu und prüfe, dass ein Benutzer mit MANAGE_RIGHTS_ONLY_OWN_BRANCH nur die Gruppen seiner Filiale sieht.
 Tracelinks:    SyRS-011, SyRS-012, SwRS-006
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Grundvoraussetzung für Multi-Site-Betrieb.
 Status:        belegt
 ```
 ### StRS-010
 ```
 ID:            StRS-010
 Titel:         Einkauf und Bestellvorschlagsliste
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Einkäufer
 Vorbedingung:  Artikel mit Mindestbestand sind erfasst.
 Fakt:          Die AppSettingsConst definiert BVL-Einstellungen: BVLAutomaticallyTransferSupplierPriceToOrderItem=1132, BVLOrderByMinimumStock=849, BVLAlwaysSortItems=1072, BVLAcceptSuggested=1601, BVLDoNotQueryWhenCreatingOrder=1553. Die Klasse SupplierOrderPerBranchBL verwaltet filialbezogene Bestellungen.
 Aussage:       Das System soll eine Bestellvorschlagsliste (BVL) automatisch aus Mindestbeständen generieren und die Erstellung von Lieferantenbestellungen daraus unterstützen.
 Ergebnis:      Bestellvorschläge werden nach Mindestbestand generiert und können zu Bestellungen überführt werden.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, BVL* Konstanten - Begründung: Definiert die Konfiguration der Bestellvorschlagsliste.
  - [PRIMÄR]   src/backend/Centron.BL/Purchasing/SupplierOrderPerBranchBL.cs - Begründung: Implementiert filialbezogene Bestelllogik.
 Prüfidee:      Setze Mindestbestände für Artikel und führe die BVL aus; prüfe, dass Artikel unter Mindestbestand in der Liste erscheinen.
 Tracelinks:    SyRS-019
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Erleichtert den Einkaufsprozess.
 Status:        belegt
 ```
 ### StRS-011
 ```
 ID:            StRS-011
 Titel:         Kundengeräte- und Vertragsverwaltung (Customer Assets)
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter, Techniker
 Vorbedingung:  Kunde ist angelegt.
 Fakt:          AssetBL (49 KB) und CustomerAssetBL (32 KB) verwalten Kundengeräte („Stammblätter") mit Verträgen, Zählerständen, Abrechnung und Sperren. AssetArticleBL (72 KB) verwaltet die Artikelzuordnung. Die Settings HelpdeskToCustomerAssetInsert* steuern die Übernahme von Ticket-Daten in Assets.
 Aussage:       Das System soll Kundengeräte mit zugehörigen Verträgen, Zählerständen und Serviceartikeln verwalten und die Übernahme von Ticket-Zeiten in Abrechnungen unterstützen.
 Ergebnis:      Kundengeräte sind mit vollständiger Historie dokumentiert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs - Begründung: Haupt-BL für Kundengeräte-Verwaltung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetArticleBL.cs - Begründung: Verwaltet Artikel-Zuordnungen zu Geräten.
 Prüfidee:      Erstelle ein Kundengerät mit Vertrag und Zählerstand, weise einen Serviceartikel zu und führe eine Abrechnung durch.
 Tracelinks:    SyRS-008, SwRS-009
 Konsolidierung: Kandidat: SwRS-009 (dieselbe fachliche Funktion aus Software-Sicht)
 Übernahmewürdigkeit: übernehmen - Kernfunktion für IT-Systemhäuser.
 Status:        belegt
 ```
 ### StRS-012
 ```
 ID:            StRS-012
 Titel:         Performance und Verfügbarkeit des Web-Services
 Ebene:         StRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Performance-Effizienz
 Akteur:        Alle Benutzer
 Vorbedingung:  System ist im produktiven Einsatz.
 Fakt:          Der Web-Service (src/webservice/) fungiert als Middleware zwischen Desktop-Client und Datenbank. ConnectionHeartbeatTimer (4,9 KB) überwacht die Verbindung. Die AppSettings MobileOfflineDataExpirationDuration=1531 definiert ein Ablaufdatum für Offline-Daten.
 Aussage:       Das System soll eine Web-Service-Middleware bereitstellen, die Verbindungsabbrüche erkennt und Daten konsistent hält.
 Ergebnis:      Der Web-Service ist verfügbar und Verbindungsabbrüche werden erkannt.
 Belege:
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs - Begründung: Implementiert Heartbeat-Überwachung der Verbindung.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, MobileOfflineDataExpirationDuration=1531 - Begründung: Definiert Offline-Daten-Gültigkeit in Tagen.
 Prüfidee:      Trenne die Web-Service-Verbindung und prüfe, dass der Heartbeat-Timer dies erkennt.
 Tracelinks:    SyRS-035
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Betriebskritisch.
 Status:        HYPOTHESE
 ```
 Begründung: Konkrete Performance-Schwellwerte und Verfügbarkeitsanforderungen (z. B. Antwortzeiten, SLA) sind in den Artefakten nicht direkt messbar. Die Architektur (Web-Service-Middleware) ist belegt, aber quantitative Anforderungen fehlen.
 ### StRS-013
 ```
 ID:            StRS-013
 Titel:         Online-Banking und Zahlungsverkehr
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Buchhaltung
 Vorbedingung:  Bankkonten sind konfiguriert.
 Fakt:          OnlineBankingAccountTransactionsBL (68 KB) ruft Kontoumsätze ab und ordnet sie zu. OnlineBankingConfigurationBL verwaltet die Konfiguration. OnlineBankingFinApiBL bindet die FinAPI an. Die AppSettings OnCollectUsername=1340/OnCollectPassword=1341 speichern FinAPI-Zugangsdaten.
 Aussage:       Das System soll Kontoumsätze automatisiert abrufen und Eingangszahlungen Rechnungen zuordnen können.
 Ergebnis:      Eingangszahlungen sind Rechnungen zugeordnet und der OPOS ist ausgeglichen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Finances/OnlineBanking/OnlineBankingAccountTransactionsBL.cs - Begründung: Implementiert den Abruf und die Zuordnung von Kontoumsätzen.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, OnCollectUsername=1340 - Begründung: Definiert die Konfiguration der FinAPI-Zugangsdaten.
 Prüfidee:      Rufe Kontoumsätze ab und prüfe, dass eine Zahlung der richtigen Rechnung zugeordnet wird.
 Tracelinks:    SyRS-026, SyRS-027
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Effizienz im Zahlungsverkehr.
 Status:        belegt
 ```
 ### StRS-014
 ```
 ID:            StRS-014
 Titel:         EDI und elektronischer Datenaustausch
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Einkauf, System
 Vorbedingung:  EDI-Partner sind konfiguriert.
 Fakt:          Das EDI-Verzeichnis enthält Unterverzeichnisse für Alltron, ALSO, AlsoCH, Concerto, EGIS, Komsa, Opentrans21, Zugferd, SupplierEDI. EDIDispatcherBL steuert die Verarbeitung. EDIGatewaySettingBL und EDILogBL verwalten Konfiguration und Protokollierung.
 Aussage:       Das System soll den elektronischen Datenaustausch mit Lieferanten (Bestellungen, Auftragsbestätigungen, Lieferscheine, Rechnungen) in verschiedenen EDI-Formaten unterstützen.
 Ergebnis:      EDI-Nachrichten werden automatisiert verarbeitet und protokolliert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/EDI/EDIDispatcherBL.cs - Begründung: Zentrale Dispatcher-Klasse für die EDI-Verarbeitung.
  - [PRIMÄR]   src/backend/Centron.BL/EDI/EDILogBL.cs - Begründung: Protokolliert alle EDI-Transaktionen.
  - [SEKUNDÄR] src/backend/Centron.BL/EDI/ (Verzeichnisstruktur mit Lieferanten-Unterverzeichnissen) - Begründung: Zeigt die Vielzahl unterstützter EDI-Partner.
 Prüfidee:      Sende eine Bestellung per EDI an einen Lieferanten und prüfe das Protokoll.
 Tracelinks:    SyRS-041
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Automatisierung des Beschaffungsprozesses.
 Status:        belegt
 ```
 ### StRS-015
 ```
 ID:            StRS-015
 Titel:         Mail-Integration und Kommunikation
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter, System
 Vorbedingung:  SMTP-Einstellungen sind konfiguriert.
 Fakt:          MailSettingsBL (16 KB) verwaltet SMTP-Host, Port, Authentifizierung, Timeout und Signatur. MailSignatureBL (8 KB) verwaltet Signaturen. Mail-Vorlagen (Templates/) mit Variablenersetzung (VariableReplacement/) werden für Belegversand, Helpdesk-Benachrichtigungen und Urlaubsanträge verwendet. MailScanner analysiert eingehende Mails und ordnet sie Tickets zu.
 Aussage:       Das System soll E-Mails mit Vorlagen und Variablenersetzung versenden und eingehende Mails automatisiert analysieren können.
 Ergebnis:      E-Mails werden mit korrekten Inhalten versendet; eingehende Mails werden zugeordnet.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Mail/MailSettingsBL.cs - Begründung: Verwaltet SMTP-Konfiguration und Mail-Client-Typ.
  - [PRIMÄR]   src/backend/Centron.BL/Mail/Templates/ (Verzeichnis) - Begründung: Enthält die Vorlagen-Engine für E-Mails.
  - [SEKUNDÄR] src/backend/Centron.BL/MailScanner/ (Verzeichnis) - Begründung: Implementiert automatische Mail-Analyse.
 Prüfidee:      Sende eine Rechnung per E-Mail und prüfe, dass die Vorlage korrekt angewendet wurde.
 Tracelinks:    SyRS-039
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Grundlegende Kommunikationsfunktion.
 Status:        belegt
 ```
 ### StRS-016
 ```
 ID:            StRS-016
 Titel:         Mobile Nutzung mit Offline-Synchronisation
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Techniker, Außendienst
 Vorbedingung:  Mobile-Gerät ist registriert.
 Fakt:          MobileBL definiert die mobile Datenverwaltung. Die AppSettings MobileOfflineDataExpirationDuration=1531 definiert die Gültigkeitsdauer von Offline-Daten in Tagen.
 Aussage:       Das System soll die mobile Nutzung mit Offline-Daten und automatischer Synchronisation unterstützen, wobei Offline-Daten nach einer konfigurierbaren Dauer ablaufen.
 Ergebnis:      Techniker können im Feld arbeiten und Daten später synchronisieren.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Mobile/MobileBL.cs - Begründung: Implementiert die mobile Datenverwaltung.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, MobileOfflineDataExpirationDuration=1531 - Begründung: Definiert das Ablaufdatum für Offline-Daten.
 Prüfidee:      Lade Daten offline auf ein Mobilgerät und prüfe, dass sie nach Ablauf der konfigurierten Dauer nicht mehr verwendet werden können.
 Tracelinks:    SyRS-042
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Wichtig für Außendienst-Mitarbeiter.
 Status:        belegt
 ```
 ### StRS-017
 ```
 ID:            StRS-017
 Titel:         Berichtswesen und Dokumentengenerierung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter
 Vorbedingung:  Beleg oder Ticket existiert.
 Fakt:          ReportsBL und ReportEngine/ implementieren die Report-Generierung. ReceiptBL.CreateFullReportForReceipt erstellt PDF-Reports für Belege mit ReportGroup, ReportData und LayoutItems. ZUGFeRD-konforme PDFs werden für Rechnungen und Gutschriften unterstützt. Reports können archiviert und an Dokumente angehängt werden.
 Aussage:       Das System soll Berichte und PDF-Dokumente für alle Belegarten generieren, archivieren und an Dokumente anhängen können.
 Ergebnis:      PDF-Reports stehen für Druck, Versand und Archivierung zur Verfügung.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateFullReportForReceipt - Begründung: Implementiert die Report-Generierung mit LayoutItems und ZUGFeRD-Unterstützung.
  - [PRIMÄR]   src/backend/Centron.BL/Reporting/ReportsBL.cs - Begründung: Verwaltet Report-Konfigurationen.
 Prüfidee:      Erstelle einen PDF-Report für eine Rechnung und prüfe, dass er in den Dokumenten archiviert wird.
 Tracelinks:    SyRS-024, SyRS-025
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Dokumentation ist gesetzlich gefordert.
 Status:        belegt
 ```
 ### StRS-018
 ```
 ID:            StRS-018
 Titel:         Task-Management und Prozessverwaltung
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Sachbearbeiter, Manager
 Vorbedingung:  Benutzer ist angemeldet.
 Fakt:          ProcessBL (28 KB) implementiert die Prozessverwaltung mit Aufgaben und Weiterleitungen. TaskManager (im BL-Verzeichnis) verwaltet Aufgaben. Das CentronRights.md definiert SHOW_TASKMANAGEMENT als separates Recht. TicketProjects verknüpft Tickets mit Projekten.
 Aussage:       Das System soll Aufgaben und Prozesse verwalten, die an Tickets und Projekte gekoppelt sind.
 Ergebnis:      Aufgaben sind nachvollziehbar und zugewiesen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Processes/ProcessBL.cs - Begründung: Implementiert die Prozessverwaltung.
  - [SEKUNDÄR] CentronRights.md, SHOW_TASKMANAGEMENT - Begründung: Definiert das Recht für den Zugriff auf das Task-Management.
 Prüfidee:      Erstelle eine Aufgabe in einem Prozess und weise sie einem Mitarbeiter zu.
 Tracelinks:    SyRS-043
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Prozessunterstützung.
 Status:        belegt
 ```
 ### StRS-019
 ```
 ID:            StRS-019
 Titel:         Web-Account-Zugriff für Kunden
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Kunde (Web-Account)
 Vorbedingung:  Web-Account ist angelegt und aktiviert.
 Fakt:          WebAccountBL (46 KB) verwaltet Web-Accounts mit separaten Rechten (WebAccountRightsConst). Die Nexus-Web-UI (Blazor) bietet WebCart und WebOffer. Im ReceiptBL.CreateNewReceipt wird IsWebAccountLogin geprüft und der Zugriff auf den eigenen Kunden eingeschränkt. Die AppSettings WebAccountCanSetTicketPriority=1637 und WebAccountTicketPresetPriority=1638 steuern Ticket-Rechte.
 Aussage:       Das System soll Kunden einen Web-Zugang bieten, über den sie eigene Belege einsehen, Tickets erstellen und einen WebShop nutzen können, mit separaten Rechten.
 Ergebnis:      Kunden können self-service über das Web auf ihre Daten zugreifen.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs - Begründung: Verwaltet Web-Accounts mit separater Rechteverwaltung.
  - [PRIMÄR]   src/nexus/CentronNexus/WebCart/ und WebOffer/ - Begründung: Implementieren den WebShop und WebAngebot.
 Prüfidee:      Melde dich als Web-Account an und prüfe, dass nur die eigenen Belege und Tickets sichtbar sind.
 Tracelinks:    SyRS-013, SyRS-037, SwRS-007
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Self-Service für Kunden.
 Status:        belegt
 ```
 ### StRS-020
 ```
 ID:            StRS-020
 Titel:         Konfigurierbarkeit von Pflichtfeldern und Bezeichnern
 Ebene:         StRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        Administrator
 Vorbedingung:  System ist installiert.
 Fakt:          AppSettingsConst definiert über 60 Mandatory- und Caption-Einstellungen: MandatoryOfficer1=263 bis MandatoryOfficer4=266, MandatoryClassification=269, MandatoryBranch=1541, MandatoryContactSalutation=923, Adviser1Caption=959 bis Adviser6Caption=1488, CustomerKind1=555 bis CustomerKind5=1485, CrmFreeText1Label=707 bis CrmFreeText6Label=1365, EmployeeManagementField01=787 bis EmployeeManagementField10=1381. ModuleFeatures steuert Feature-Flags.
 Aussage:       Das System soll Pflichtfelder, Feldbezeichnungen und Kundenarten umfassend konfigurierbar machen, um unterschiedliche Branchenanforderungen abzudecken.
 Ergebnis:      Das System ist an die Anforderungen des jeweiligen Unternehmens anpassbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Mandatory* und *Caption Konstanten - Begründung: Definiert die Konfigurationskonstanten für Pflichtfelder und Bezeichnungen.
  - [PRIMÄR]   src/backend/Centron.Common/ModuleFeatures.cs - Begründung: Definiert Feature-Flags, die Verfügbarkeit von Funktionen steuern.
 Prüfidee:      Ändere ein Mandatory-Feld und ein Caption und prüfe, dass die UI das übernimmt.
 Tracelinks:    SyRS-031
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Flexibilität für verschiedene Kunden.
 Status:        belegt
 ```
@@ -0,0 +1,466 @@
 # SwRS – Software Requirements Specification
 ## c-entron ERP-Suite – Reverse Requirements Engineering
 ---
 ### SwRS-001
 ```
 ID:            SwRS-001
 Titel:         Belegerstellung mit Generic-Typed ReceiptBL
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        ReceiptBL-Komponente
 Vorbedingung:  DAOSession ist geöffnet.
 Fakt:          ReceiptBL erbt von BaseBL und verwendet Generic-Methoden (CreateNewReceipt<TReceipt,TReceiptItem>, ForwardReceipt<TReceipt,TReceiptItem>, GetReceiptByI3D<T>) mit Constraints where TReceipt : IReceiptBase, new() und where TReceiptItem : IReceiptItemBase, new(). Der Konstruktor initialisiert über 40 abhängige BL-Klassen (_specificLogics, _numberGroupBL, _employeeBL, _customerBL, etc.). Die Methode _specificLogics.Execute delegiert belegartspezifische Logik.
 Aussage:       Die Software soll Belegerstellung über generisch typisierte Methoden mit Beleg- und Positionstyp-Parametern implementieren und belegartspezifische Logik über ein Strategy-Pattern (_specificLogics) delegieren.
 Ergebnis:      Belege werden typsicher erstellt mit korrekter belegartspezifischer Logik.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewReceipt<TReceipt,TReceiptItem> - Begründung: Implementiert die generische Belegerstellung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/SpecificLogics.cs - Begründung: Implementiert das Strategy-Pattern für belegartspezifische Logik.
 Prüfidee:      Erstelle je einen Beleg unterschiedlichen Typs und prüfe, dass die korrekte spezifische Logik ausgeführt wird.
 Tracelinks:    StRS-001, SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Architekturpattern für Erweiterbarkeit.
 Status:        belegt
 ```
 ### SwRS-002
 ```
 ID:            SwRS-002
 Titel:         Belegweiterverarbeitung mit ReceiptHistory
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        ReceiptBL-Komponente
 Vorbedingung:  Beleg existiert.
 Fakt:          GetReceiptForwardedFrom und GetReceiptForwardedInto liefern ReceiptHistoryEntry-Listen mit OtherReceiptKind, OtherReceiptI3D, OtherReceiptNumber, OtherReceiptState und ReceiptItemI3Ds. Die Weiterverarbeitung wird im ReceiptLog protokolliert. GetAccountActivitiesForReceipt lädt Aktivitäten auch von weiterverarbeiteten Belegen (ForwardedFrom/ForwardedInto, rekursiv).
 Aussage:       Die Software soll die Beleghistorie (ForwardedFrom/ForwardedInto) mit Positionszuordnung und rekursiver Aktivitätsauflösung verwalten.
 Ergebnis:      Die Belegkette ist vollständig nachvollziehbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptForwardedFrom/GetReceiptForwardedInto - Begründung: Implementiert die Beleghistorie.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetAccountActivitiesForReceiptForwardedFrom/ForwardedInto - Begründung: Implementiert die rekursive Aktivitätsauflösung.
 Prüfidee:      Verarbeite einen Auftrag in einen Lieferschein und dann in eine Rechnung; prüfe, dass die Historie alle drei Belege enthält.
 Tracelinks:    StRS-002, SyRS-002
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Vollständige Belegkette.
 Status:        belegt
 ```
 ### SwRS-003
 ```
 ID:            SwRS-003
 Titel:         Kundendaten-Modell mit Firmenbuch-Integration
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        CustomerBL-Komponente
 Vorbedingung:  Datenbank ist erreichbar.
 Fakt:          CustomerBL.GetCustomerDetail liefert CustomerDetail mit Adviser1I3D–Adviser4I3D, AlternateDeliveryCustomerI3D, AlternativeCustomerI3D (für Rechnungsadresse). GetCustomerFinanceInformation liefert PaymentConditionInvoiceI3D, DeliveryConditionI3D, VATNotActive. Die Settings Adviser1Caption=959 bis Adviser6Caption=1488 definieren die Bezeichnungen der Berater. CustomerKind1=555 bis CustomerKind5=1485 definieren Kundenarten.
 Aussage:       Die Software soll ein Kunden-Datenmodell mit bis zu 6 Beratern, alternativen Rechnungs-/Lieferadressen, Finanzdaten und 5 konfigurierbaren Kundenarten implementieren.
 Ergebnis:      Kundendaten sind strukturiert gespeichert und abrufbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Customers/CustomerBL.cs, GetCustomerDetail/GetCustomerFinanceInformation - Begründung: Implementiert das Kunden-Datenmodell.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Adviser*Caption und CustomerKind* Konstanten - Begründung: Definiert die konfigurierbaren Bezeichnungen.
 Prüfidee:      Lese einen Kunden mit allen Feldern und prüfe die Vollständigkeit.
 Tracelinks:    StRS-003, SyRS-003
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenmodell-Grundlage.
 Status:        belegt
 ```
 ### SwRS-004
 ```
 ID:            SwRS-004
 Titel:         Artikel-Datenmodell mit Barcode-Logik
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        ArticleBL-Komponente
 Vorbedingung:  Datenbank ist erreichbar.
 Fakt:          ArticleBL (210 KB) verwaltet Artikel mit ArticleBL, BarcodeBL (57 KB), ArticleUnitBL, ArticleVariableBL, ArticleVolumePricesBL, ArticleWorkItemBL, SecondStockArticleBL (45 KB). Die Settings FixedSpecificationFixedPart=1067 und FixedSpecificationVariablePart=1071 definieren Barcode-Komposition. AutomaticallySerialNumberWindowOpen=447 steert die Seriennummer-Erfassung.
 Aussage:       Die Software soll ein Artikel-Datenmodell mit Barcode-Generierung, Seriennummern, Einheiten, Variablen, Staffelpreisen und Zweitlager-Artikeln implementieren.
 Ergebnis:      Artikeldaten sind vollständig strukturiert gespeichert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/ArticleBL.cs - Begründung: Haupt-BL für das Artikel-Datenmodell.
  - [PRIMÄR]   src/backend/Centron.BL/Warehousing/BarcodeBL.cs - Begründung: Implementiert die Barcode-Logik.
 Prüfidee:      Lege einen Artikel mit Barcode und Seriennummer an und prüfe die Datenstruktur.
 Tracelinks:    StRS-005, SyRS-018
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenmodell-Grundlage.
 Status:        belegt
 ```
 ### SwRS-005
 ```
 ID:            SwRS-005
 Titel:         Helpdesk/Ticket-Datenmodell
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        HelpdeskBL-Komponente
 Vorbedingung:  Datenbank ist erreichbar.
 Fakt:          In ReceiptBL werden _helpdeskBL, _helpdeskSearchBL, _helpdeskStatusBL, _helpdeskTypeBL, _helpdeskCategoryBL und _helpdeskTimerBL referenziert. Die Settings HelpdeskAdditionalTextfield1Enabled=665/Required=666, HelpdeskAdditionalTextfield2Enabled=677, HelpdeskBindingnumberFieldEnabled=670/IsRequired=671, TicketVariableFlagVisible=667/Caption=669 definieren konfigurierbare Ticket-Felder. CentronObjectKindNumeric definiert HelpdeskClass=10, HelpdeskTimerClass=4000056, HelpdeskSolutionClass=4000110.
 Aussage:       Die Software soll ein Ticket-Datenmodell mit Status, Typ, Kategorien, Prioritäten, Zeitfassung, konfigurierbaren Zusatzfeldern und Lösungsdokumentation implementieren.
 Ergebnis:      Ticket-Daten sind strukturiert gespeichert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs (HelpdeskBL-Referenzen) - Begründung: Referenziert alle Helpdesk-BL-Klassen.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Helpdesk* Konstanten - Begründung: Definiert die konfigurierbaren Ticket-Felder.
 Prüfidee:      Erstelle ein Ticket mit allen Feldern und prüfe die Datenstruktur.
 Tracelinks:    StRS-007, SyRS-009
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenmodell-Grundlage.
 Status:        belegt
 ```
 ### SwRS-006
 ```
 ID:            SwRS-006
 Titel:         Beleganlegung mit Berechtigungsprüfung
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        ReceiptBL-Komponente
 Vorbedingung:  Benutzer ist angemeldet.
 Fakt:          In CreateNewReceipt wird CanUserCreateNewReceiptsAtCustomerOrSupplier<TReceipt> aufgerufen. Bei Web-Account-Login wird customerOrSupplierI3D gegen loggedInUser.WebAccount.CustomerI3D geprüft. In CreateNewVersion wird CanUserEditReceipt aufgerufen. Die Berechtigungsprüfung erfolgt vor der Belegerstellung.
 Aussage:       Die Software soll vor der Belegerstellung und -bearbeitung die Berechtigung des Benutzers prüfen.
 Ergebnis:      Nur autorisierte Benutzer können Belege erstellen und bearbeiten.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewReceipt (CanUserCreateNewReceiptsAtCustomerOrSupplier) - Begründung: Implementiert die Berechtigungsprüfung vor Belegerstellung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion (CanUserEditReceipt) - Begründung: Implementiert die Berechtigungsprüfung vor Belegbearbeitung.
 Prüfidee:      Versuche als nicht-berechtigter Benutzer einen Beleg zu erstellen; das System muss dies ablehnen.
 Tracelinks:    StRS-009, SyRS-011
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Sicherheitskritisch.
 Status:        belegt
 ```
 ### SwRS-007
 ```
 ID:            SwRS-007
 Titel:         Web-Account-Login mit Kundenbindung
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        WebAccountBL-Komponente
 Vorbedingung:  Web-Account existiert.
 Fakt:          WebAccountBL (46 KB) verwaltet Web-Accounts. LoggedInUser.IsWebAccountLogin und LoggedInUser.WebAccount.CustomerI3D werden in ReceiptBL verwendet, um den Zugriff einzuschränken. WebAccountRightsConst definiert separate Rechte. Die Settings ResponsibleEmployeeI3DForWebaccounts=519, TicketWebAccountTicketsHaveToBeAuthorized=1606, WebAccountCanSetTicketPriority=1637 steuern das Web-Account-Verhalten.
 Aussage:       Die Software soll Web-Account-Logins mit Kundenbindung und separater Rechteverwaltung implementieren.
 Ergebnis:      Web-Accounts sind an ihren Kunden gebunden.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Logins/WebAccountBL.cs - Begründung: Implementiert die Web-Account-Verwaltung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, GetReceiptByI3D/CreateNewReceipt (IsWebAccountLogin) - Begründung: Implementiert die Kundenbindung.
 Prüfidee:      Melde dich als Web-Account an und prüfe die Kundenbindung.
 Tracelinks:    StRS-019, SyRS-013, SyRS-037
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Sicherheit für Web-Zugänge.
 Status:        belegt
 ```
 ### SwRS-008
 ```
 ID:            SwRS-008
 Titel:         Nummernkreis-Implementierung
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        NumberGroupBL-Komponente
 Vorbedingung:  Datenbank ist erreichbar.
 Fakt:          NumberGroupBL (8,9 KB) verwaltet Nummernkreise. NumberGroupEnum (7,5 KB) definiert ca. 30 Belegarten für Nummernkreise. ReceiptBL.UpdateReceiptNumber ruft die Nummer ab. IsNumberGroupRefactoringAvailable (ModuleFeatures) ist nur für interne Benutzer oder Preview-Lizenz verfügbar.
 Aussage:       Die Software soll Nummernkreise über NumberGroupBL mit Belegart- und Filialbezug implementieren.
 Ergebnis:      Nummernkreise sind korrekt verwaltet.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/NumberGroupBL.cs - Begründung: Implementiert die Nummernkreis-Logik.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Company/NumberGroupEnum.cs - Begründung: Definiert die Belegarten.
 Prüfidee:      Vergleiche die vergebene Nummer mit dem konfigurierten Nummernkreis.
 Tracelinks:    SyRS-006, SyRS-029
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Eindeutige Identifikation.
 Status:        belegt
 ```
 ### SwRS-009
 ```
 ID:            SwRS-009
 Titel:         Asset-Verwaltung mit Verträgen und Zählerständen
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        AssetBL-Komponente
 Vorbedingung:  Kunde existiert.
 Fakt:          AssetBL (49 KB) verwaltet Kundengeräte mit Verträgen, Zählerständen und Abrechnung. AssetArticleBL (72 KB) verwaltet Artikel-Zuordnungen. CustomerAssetBL (32 KB) und CustomerAssetExtendedBL (12 KB) erweitern die Funktionalität. AssetVersionControlBL ermöglicht Versionierung. Die Settings OldCounterStateDay=1076, NewCounterScoreGrund=1325, BilledCounterTemplate=1115, NoBilledCounterTemplate=1330, ViewArticleToNoBilledCounter=1331 steuern die Zählerstandsbasierte Abrechnung.
 Aussage:       Die Software soll ein Asset-Datenmodell mit Verträgen, Zählerständen, Versionierung und artikelbasierter Abrechnung implementieren.
 Ergebnis:      Assets sind mit vollständiger Historie gespeichert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetBL.cs - Begründung: Haupt-BL für Asset-Verwaltung.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetArticleBL.cs - Begründung: Verwaltet Artikel-Zuordnungen.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, Counter* Konstanten - Begründung: Definiert die Zählerstand-Abrechnung.
 Prüfidee:      Erstelle ein Asset mit Vertrag, erfasse Zählerstände und führe eine Abrechnung durch.
 Tracelinks:    StRS-011, SyRS-008, SyRS-050
 Konsolidierung: Kandidat: StRS-011 (Stammblätter/Assets), SyRS-050 (Konsolidierung)
 Übernahmewürdigkeit: übernehmen - Datenmodell für Kundengeräte.
 Status:        belegt
 ```
 ### SwRS-010
 ```
 ID:            SwRS-010
 Titel:         Asset-Sperrlogik
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        AssetLockBL-Komponente
 Vorbedingung:  Kunde hat Assets und Mahnstufe erreicht.
 Fakt:          AssetLockBL (4,6 KB) implementiert die Sperrlogik. CustomerAssetsLockedAfterDunningLevel=104 definiert die Sperrschwelle. Die Sperrung wird im Mahnlauf ausgelöst.
 Aussage:       Die Software soll die Sperrung von Kundengeräten bei Erreichen einer konfigurierbaren Mahnstufe implementieren.
 Ergebnis:      Assets sind gesperrt bei entsprechender Mahnstufe.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/CustomerAssets/AssetLockBL.cs - Begründung: Implementiert die Sperrlogik.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, CustomerAssetsLockedAfterDunningLevel=104 - Begründung: Definiert die Sperrschwelle.
 Prüfidee:      Simuliere eine Mahnstufe und prüfe, dass die Assets gesperrt sind.
 Tracelinks:    SyRS-008
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Forderungssicherung.
 Status:        belegt
 ```
 ### SwRS-011
 ```
 ID:            SwRS-011
 Titel:         Lizenz-Manager-Implementierung
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        LicenseManager-Komponente
 Vorbedingung:  System startet.
 Fakt:          LicenseManager ist ein Singleton (Instance, Initialize). LoadLicenses lädt und prüft. CheckLicense prüft Version und Count. HasLicense prüft eine GUID. GetCustomerNumber liefert die Kundennummer. GetCurrentProductID generiert eine 8-stellige Produkt-ID. SettingsForWebService, SettingsForCentronNet und SettingsForTests bieten unterschiedliche Konfigurationen. GetAdditionalData liefert DatabaseId, MachineName und WindowsServiceName.
 Aussage:       Die Software soll einen Lizenz-Manager als Singleton mit Versionsprüfung, Anzahlenprüfung, Hardware-Bindung und drei Konfigurationsmodi (WebService, CentronNet, Tests) implementieren.
 Ergebnis:      Die Lizenzprüfung ist zentral implementiert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs - Begründung: Implementiert den Lizenz-Manager als Singleton.
 Prüfidee:      Initialisiere den Lizenz-Manager im Test-Modus und prüfe die Lizenzprüfung.
 Tracelinks:    SyRS-014
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Schutz vor unbefugter Nutzung.
 Status:        belegt
 ```
 ### SwRS-012
 ```
 ID:            SwRS-012
 Titel:         DAO-Schicht mit NHibernate
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        DAO-Schicht
 Vorbedingung:  Datenbankverbindung ist konfiguriert.
 Fakt:          Die DAO-Schicht (src/backend/Centron.DAO/) verwendet NHibernate mit GenericDAO (25 KB), DAOFactory (11 KB), DAOSession (7 KB), AdvancedSession, SessionCache und SessionExtensions. GenericStoredProcedureDAO (20 KB) unterstützt Stored Procedures. NamedQueries sind in einem eigenen Verzeichnis. NHibernateConfiguration enthält die Konfiguration. TruncateStringsEventListener und StringOrBinaryDataWouldBeTruncatedEventListener behandeln String-Kürzungen.
 Aussage:       Die Software soll eine DAO-Schicht mit NHibernate ORM, generischem CRUD, Stored-Procedure-Support und automatischer String-Kürzung implementieren.
 Ergebnis:      Datenbankzugriffe sind über die DAO-Schicht zentralisiert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.DAO/GenericDAO.cs - Begründung: Implementiert generischen CRUD-Zugriff.
  - [PRIMÄR]   src/backend/Centron.DAO/GenericStoredProcedureDAO.cs - Begründung: Implementiert Stored-Procedure-Support.
  - [PRIMÄR]   src/backend/Centron.DAO/TruncateStringsEventListener.cs - Begründung: Implementiert automatische String-Kürzung.
 Prüfidee:      Speichere eine Entität über GenericDAO und lese sie wieder; prüfe die Konsistenz.
 Tracelinks:    SyRS-001
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenzugriffsarchitektur.
 Status:        belegt
 ```
 ### SwRS-013
 ```
 ID:            SwRS-013
 Titel:         Belegspeicherung mit Locking und Transaktion
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        ReceiptBL-Komponente
 Vorbedingung:  Beleg existiert oder wird erstellt.
 Fakt:          CreateNewVersion verwendet Session.WithTransaction für atomare Operationen. TryLockReceipt/UnLockReceipt implementieren das Locking. ConcurrencyControlGuid verhindert verlorene Updates. Die Methode CreateReportPreviewForReceipt nutzt RollbackTransaction, um Belegänderungen für Report-Previews rückgängig zu machen.
 Aussage:       Die Software soll Belegspeicherung mit pessimistischem Locking, Transaktionssicherheit und Concurrency-Control implementieren.
 Ergebnis:      Gleichzeitige Bearbeitung wird verhindert.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateNewVersion (WithTransaction, TryLockReceipt) - Begründung: Implementiert Locking und Transaktion.
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, CreateReportPreviewForReceipt (RollbackTransaction) - Begründung: Implementiert Transaktions-Rollback für Previews.
 Prüfidee:      Öffne einen Beleg in zwei Sessions; die zweite muss gesperrt sein.
 Tracelinks:    SyRS-004
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenkonsistenz.
 Status:        belegt
 ```
 ### SwRS-014
 ```
 ID:            SwRS-014
 Titel:         Mitarbeiterartikel und Leistungserfassung
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        EmployeeArticleBL-Komponente
 Vorbedingung:  Mitarbeiter und Artikel existieren.
 Fakt:          EmployeeArticleBL (13 KB) verwaltet Mitarbeiterartikel mit Stundensätzen und Leistungen. Die Settings UseCostCenterFromEmployeeOfServiceArticle=1445 und UseEmployeeCostCenterForTradeArticle=1475 definieren die Kostenstellenübernahme vom Mitarbeiter. HelpdeskToWorkingDayInSeconds=1580 definiert die Tagesarbeitszeit.
 Aussage:       Die Software soll Mitarbeiterartikel mit Stundensätzen und automatischer Kostenstellenzuweisung implementieren.
 Ergebnis:      Leistungen sind mit korrekten Kostenstellen erfasst.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/EmployeeArea/EmployeeArticleBL.cs - Begründung: Implementiert die Mitarbeiterartikel-Verwaltung.
  - [SEKUNDÄR] src/backend/Centron.BL/Administration/Settings/AppSettingsConst.cs, UseCostCenter* Konstanten - Begründung: Definiert die Kostenstellen-Übernahme.
 Prüfidee:      Erfasse eine Leistung für einen Mitarbeiter und prüfe die Kostenstelle.
 Tracelinks:    StRS-007, SyRS-010
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Leistungserfassung.
 Status:        belegt
 ```
 ### SwRS-015
 ```
 ID:            SwRS-015
 Titel:         Rechte-Prüfung via SQL und Cache
 Ebene:         SwRS
 Typ:           Sicherheit
 Qualitätsmerkmal:
 Akteur:        AppRightsBL-Komponente
 Vorbedingung:  Benutzer ist angemeldet.
 Fakt:          HasUserRight verwendet Session.Advanced.Cache.GetOrAdd($"AllRightsFromAppUser{appUserI3D}", ...). Die SQL-Abfrage lautet: SELECT st.Recht AS ID FROM dbo.Sichtrus st INNER JOIN dbo.Sichmemb sm ON sm.Gruppe = st.Gruppe WHERE sm.Benutzer = :UserI3D. GetAllAppRightsFromUser lädt alle Rechte. Die Administratoren-Gruppe (I3D=6) kann nicht gelöscht werden. GetAssignableAdminRightI3Ds definiert einschränkende Rechte, die der Admin-Gruppe zugewiesen werden dürfen.
 Aussage:       Die Software soll Rechteprüfungen über parametrisierte SQL-Abfragen mit Caching und Schutz der Administratoren-Gruppe implementieren.
 Ergebnis:      Rechteprüfungen sind effizient und sicher.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, HasUserRight (Cache) und CheckRightsFromUser (SQL) - Begründung: Implementiert die SQL-basierte Rechteprüfung mit Cache.
  - [PRIMÄR]   src/backend/Centron.BL/Administration/Rights/AppRightsBL.cs, DeleteRightGroup (Admin-Schutz) - Begründung: Schützt die Administratoren-Gruppe vor Löschung.
 Prüfidee:      Prüfe ein Recht mit und ohne Cache und vergleiche die Ergebnisse.
 Tracelinks:    SyRS-011, SyRS-012
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Sicherheitsarchitektur.
 Status:        belegt
 ```
 ### SwRS-016
 ```
 ID:            SwRS-016
 Titel:         Excel-Export für Belege
 Ebene:         SwRS
 Typ:           Daten
 Qualitätsmerkmal:
 Akteur:        ReceiptBL-Komponente
 Vorbedingung:  Beleg existiert.
 Fakt:          ExportReceiptToExcel erstellt eine Excel-Datei mit DevExpress.Spreadsheet.Workbook, enthält Empfänger, Kundennr, Belegnr, Erstelldatum, Berater, E-Mail, Telefon, Positionen mit Text, Artikelcode, Herstellercode, Stück, Vk Kalk, Summe Kalk, EK, Summe EK, Roh-Ertrag, Rabatt und MwSt. Die Einstellung ShowWithoutPurchasePrice steuert die Sichtbarkeit des EK.
 Aussage:       Die Software soll Belegdaten nach Excel exportieren mit optionaler Ausblendung des EK-Preises.
 Ergebnis:      Eine Excel-Datei mit Belegdaten steht zur Verfügung.
 Belege:
  - [PRIMÄR]   src/backend/Centron.BL/Sales/Receipts/ReceiptBL.cs, ExportReceiptToExcel - Begründung: Implementiert den Excel-Export mit DevExpress.Spreadsheet.
 Prüfidee:      Exportiere einen Beleg nach Excel und prüfe die Spalten.
 Tracelinks:    StRS-017
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Datenexport-Funktion.
 Status:        belegt
 ```
 ### SwRS-017
 ```
 ID:            SwRS-017
 Titel:         Module-Registrierung mit Rechte- und Verbindungsprüfung
 Ebene:         SwRS
 Typ:           funktional
 Qualitätsmerkmal:
 Akteur:        CentronModule-Komponente
 Vorbedingung:  Anwendung startet.
 Fakt:          ModuleRegistration.cs (60 KB) registriert alle UI-Module. CentronModule.DoValidateModuleForRegister prüft ModuleName, MainCategory und ID-Eindeutigkeit. OpenModule prüft SupportsConnectionTypes gegen die aktuelle ConnectionType (SQL oder CentronWebServices). Bei WebService-Verbindung wird eine Fehlermeldung angezeigt, wenn das Modul diese nicht unterstützt.
 Aussage:       Die Software soll UI-Module mit Validierung (Name, Kategorie, ID-Eindeutigkeit) und Verbindungs typprüfung registrieren.
 Ergebnis:      Nur kompatible und autorisierte Module werden geladen.
 Belege:
  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/ModuleRegistration.cs - Begründung: Registriert alle Module.
  - [PRIMÄR]   src/centron/Centron.WPF.UI/Modules/CentronModule.cs, DoValidateModuleForRegister/OpenModule - Begründung: Implementiert die Validierung und Verbindungsprüfung.
 Prüfidee:      Registriere ein Modul ohne ID und prüfe, dass die Validierung fehlschlägt.
 Tracelinks:    SyRS-033
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Modulare Architektur.
 Status:        belegt
 ```
 ### SwRS-018
 ```
 ID:            SwRS-018
 Titel:         Feature-Flags über ModuleFeatures
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Wartbarkeit
 Akteur:        System
 Vorbedingung:  Anwendung startet.
 Fakt:          ModuleFeatures.SetAccessRights(isAdmin, hasPreviewLicense, isCentronInternal) steuert Feature-Verfügbarkeit. IsDataImportAvailable und IsDataExportAvailable erfordern Admin. IsReceiptCommentAvailable erfordert PreviewLicense. IsTicketProcessAvailable und IsDsgvoDatabaseCleanupAvailable sind nur im Debugger aktiv. IsNumberGroupRefactoringAvailable erfordert CentronInternal, Debugger oder PreviewLicense.
 Aussage:       Die Software soll Feature-Verfügbarkeit über statische Flags (Admin, PreviewLicense, CentronInternal, Debugger) steuern.
 Ergebnis:      Features sind nur für berechtigte Benutzer verfügbar.
 Belege:
  - [PRIMÄR]   src/backend/Centron.Common/ModuleFeatures.cs - Begründung: Implementiert die Feature-Flag-Logik.
 Prüfidee:      Setze hasPreviewLicense=false und prüfe, dass ReceiptComment nicht verfügbar ist.
 Tracelinks:    StRS-020, SyRS-033
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Steuerung von Feature-Verfügbarkeit.
 Status:        belegt
 ```
 ### SwRS-019
 ```
 ID:            SwRS-019
 Titel:         Web-Service-Host mit Background-Processing
 Ebene:         SwRS
 Typ:           nicht-funktional
 Qualitätsmerkmal: Zuverlässigkeit
 Akteur:        Web-Service
 Vorbedingung:  System ist installiert.
 Fakt:          src/webservice/ enthält Centron.Host, Centron.Host.Console und Centron.Host.WindowsService für unterschiedliche Hosting-Modi. ConnectionHeartbeatTimer (4,9 KB) überwacht die Verbindung. BackgroundServices existieren im BL. BLSession (1,5 KB) verwaltet Datenbank-Sessions.
 Aussage:       Die Software soll den Web-Service in drei Modi (Host, Console, WindowsService) mit Heartbeat-Überwachung und Background-Processing betreiben.
 Ergebnis:      Der Web-Service ist stabil verfügbar.
 Belege:
  - [PRIMÄR]   src/webservice/Centron.Host/ - Begründung: Web-Service-Host.
  - [PRIMÄR]   src/webservice/Centron.Host.WindowsService/ - Begründung: Windows-Service-Modus.
  - [SEKUNDÄR] src/centron/Centron.WPF.UI/ConnectionHeartbeatTimer.cs - Begründung: Implementiert die Heartbeat-Überwachung.
 Prüfidee:      Starte den Web-Service als Windows-Service und prüfe die Stabilität.
 Tracelinks:    SyRS-035
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Betriebsstabilität.
 Status:        belegt
 ```
 ### SwRS-020
 ```
 ID:            SwRS-020
 Titel:         Nexus Web-UI mit Blazor und Lokalisierung
 Ebene:         SwRS
 Typ:           Schnittstelle
 Qualitätsmerkmal:
 Akteur:        Nexus-Komponente
 Vorbedingung:  Web-Service läuft.
 Fakt:          src/nexus/CentronNexus/ ist eine Blazor-Anwendung mit _Imports.razor, Configuration/, Controllers/, Management/, Settings/, Shared/, Utils/, WebCart/, WebOffer/, ServiceBoard/ und DocumentSigning/. SharedResource.resx und SharedResource.en-US.resx enthalten Lokalisierung. libman.json verwaltet JS-Dependencies.
 Aussage:       Die Software soll eine Blazor-basierte Web-UI mit Mehrsprachigkeit, WebCart, WebOffer, ServiceBoard und Dokumenten-Signierung implementieren.
 Ergebnis:      Web-Benutzer können über den Browser auf Funktionen zugreifen.
 Belege:
  - [PRIMÄR]   src/nexus/CentronNexus/CentronNexus.csproj - Begründung: Definiert die Blazor-Anwendung.
  - [PRIMÄR]   src/nexus/CentronNexus/SharedResource.resx - Begründung: Enthält Lokalisierungs-Ressourcen.
  - [PRIMÄR]   src/nexus/CentronNexus/WebCart/ - Begründung: Implementiert den WebShop.
 Prüfidee:      Öffne die Nexus-Web-UI in zwei Sprachen und prüfe die Lokalisierung.
 Tracelinks:    StRS-019, SyRS-034
 Konsolidierung: nein
 Übernahmewürdigkeit: übernehmen - Grundlage für SaaS.
 Status:        belegt
 ```
@@ -0,0 +1,60 @@
 # Traceability – c-entron ERP-Suite
 ## Konsolidierte Traceability-Tabelle
 | StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg |
 |---------|---------|--------|---------------|
 | StRS-001 | SyRS-001 | SwRS-001 | CentronObjectKindNumeric.cs; ReceiptBL.cs, CreateNewReceipt |
 | StRS-001 | SyRS-004 | SwRS-013 | ReceiptBL.cs, CreateNewVersion; TryLockReceipt |
 | StRS-002 | SyRS-002 | SwRS-002 | ReceiptBL.cs, ForwardReceipt; ValidateReceiptForwarding |
 | StRS-002 | SyRS-038 | — | DownPaymentBL.cs; ReceiptBL.cs, ValidateReceiptForwarding |
 | StRS-003 | SyRS-003 | SwRS-003 | CustomerBL.cs; ReceiptBL.cs, CreateNewReceipt |
 | StRS-004 | SyRS-003 | SwRS-003 | ReceiptBL.cs, GetCompanyGroupCustomerI3DForReceiptData; GetLeitwegID |
 | StRS-005 | SyRS-018 | SwRS-004 | ArticleBL.cs; BarcodeBL.cs |
 | StRS-005 | SyRS-019 | — | MaterialGroupBL.cs |
 | StRS-005 | SyRS-047 | — | InventoryBL.cs |
 | StRS-006 | SyRS-005 | — | CentronModule.cs, OpenModuleByObject |
 | StRS-006 | SyRS-046 | — | src/backend/Centron.BL/Tapi/; AppSettingsConst.cs, Tapi* |
 | StRS-007 | SyRS-009 | SwRS-005 | AppSettingsConst.cs, HelpdeskAfter*; CentronRights.md |
 | StRS-007 | SyRS-010 | SwRS-014 | AppSettingsConst.cs, HelpdeskTimer*; EmployeeArticleBL.cs |
 | StRS-007 | SyRS-045 | — | RmaBL.cs |
 | StRS-008 | SyRS-002 | SwRS-002 | ReceiptCartBL.cs; ReceiptCartReleaseSystemBL.cs |
 | StRS-009 | SyRS-011 | SwRS-015 | AppRightsBL.cs, CheckRightsFromUser |
 | StRS-009 | SyRS-012 | — | AppRightsBL.cs, GetAllRightGroups (BranchI3D) |
 | StRS-009 | SyRS-029 | SwRS-008 | NumberGroupBL.cs; NumberGroupEnum.cs |
 | StRS-009 | SyRS-049 | — | EntraIDUsersBL.cs |
 | StRS-010 | SyRS-019 | — | AppSettingsConst.cs, BVL* Konstanten |
 | StRS-011 | SyRS-007 | SwRS-009 | AssetBL.cs; DunningBL.cs |
 | StRS-011 | SyRS-008 | SwRS-010 | AssetLockBL.cs |
 | StRS-011 | SyRS-040 | — | AppSettingsConst.cs, LeasingPrice*/ServicePrice* |
 | StRS-011 | SyRS-050 | SwRS-009 | CentronObjectKindNumeric.cs, MasterDataListClass; AssetBL.cs |
 | StRS-012 | SyRS-035 | SwRS-019 | src/webservice/Centron.Host/; ConnectionHeartbeatTimer.cs |
 | StRS-013 | SyRS-023 | — | ReceiptBL.cs, _bookKeepingExportBL |
 | StRS-013 | SyRS-026 | — | ReceiptBL.cs, GetReceiptMandats; AppSettingsConst.cs, PaymentTransaction* |
 | StRS-013 | SyRS-027 | — | OposRunBL.cs; IncomingPaymentBL.cs |
 | StRS-013 | SyRS-044 | — | src/backend/Centron.BL/DataExchange/GfkExport/ |
 | StRS-014 | SyRS-041 | — | EDIDispatcherBL.cs; EDILogBL.cs |
 | StRS-015 | SyRS-031 | — | MailSettingsBL.cs |
 | StRS-015 | SyRS-039 | — | src/backend/Centron.BL/Mail/Templates/; VariableReplacement/ |
 | StRS-016 | SyRS-042 | — | MobileBL.cs; AppSettingsConst.cs, MobileOfflineDataExpirationDuration |
 | StRS-017 | SyRS-024 | — | ReceiptBL.cs, CreateFullReportForReceipt (ZUGFeRD) |
 | StRS-017 | SyRS-025 | SwRS-016 | ReceiptBL.cs, CreateFullReportForReceipt; ReportsBL.cs |
 | StRS-017 | SyRS-017 | — | PdfSigningBL.cs; ReceiptBL.cs, CreateFullReportForReceipt |
 | StRS-018 | SyRS-043 | — | ProcessBL.cs; PasswordManagementBL.cs |
 | StRS-019 | SyRS-013 | SwRS-007 | WebAccountBL.cs; AppRightsBL.cs, HasWebAccountRight |
 | StRS-019 | SyRS-034 | SwRS-020 | src/nexus/CentronNexus/CentronNexus.csproj |
 | StRS-019 | SyRS-037 | SwRS-007 | ReceiptBL.cs, GetReceiptByI3D (IsWebAccountLogin) |
 | StRS-019 | SyRS-048 | — | src/backend/Centron.BL/SelfCare/ |
 | StRS-020 | SyRS-031 | SwRS-018 | AppSettingsConst.cs, Mandatory*/*Caption; ModuleFeatures.cs |
 | — | SyRS-006 | SwRS-008 | NumberGroupBL.cs; ReceiptBL.cs, UpdateReceiptNumber |
 | — | SyRS-015 | — | CustomerSettingBL.cs |
 | — | SyRS-016 | — | DataSecurityBL.cs; ModuleFeatures.cs |
 | — | SyRS-020 | — | TaxBL.cs |
 | — | SyRS-021 | — | ReceiptBL.cs, GetDirectDeliveryOption |
 | — | SyRS-022 | — | CommissioningBL.cs; ReceiptBL.cs, ForwardReceipt |
 | — | SyRS-028 | — | ReceiptBL.cs, CreateNewReceipt (IReceiptWithMandat) |
 | — | SyRS-030 | — | TwoFactorAuthenticationBL.cs |
 | — | SyRS-032 | — | AppSettingsConst.cs, DeactivateUserAccountAfter |
 | — | SyRS-033 | SwRS-017 | ModuleRegistration.cs; ModuleRightsExpressionParser.cs |
 | — | SyRS-036 | — | ReceiptLogBL.cs; AppRightsBL.cs, WriteBaseLog |
 | — | — | SwRS-012 | GenericDAO.cs; GenericStoredProcedureDAO.cs |
@@ -0,0 +1,129 @@
 # Messprotokoll – Versuch 01 – Prompt-Version 02
 ## Lauf
 - **Prompt-Datei:** `Versuche/Versuch_01/02_Prompt.md`
 - **Prompt-Version:** 02 (höchste vorhandene Fassung)
 - **SHA-256 (Prompt):** `F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849`
 - **Startzeit:** 2026-08-28T05:41:44Z
 - **Endzeit:** 2026-08-28T05:47:23Z
 - **Dauer gesamt:** 00:05:39 (API: nicht separat messbar – Wanduhr)
 - **Root-Verzeichnis:** `c:\DEV\MasterArbeit\QuellCode\CentronERP`
 - **Codebasis-Commit:** `37275c96` (dirty: nein, 0 Änderungen)
 - **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
 - **Prompt-Repo-Commit:** `37275c96d610a8b7958d126bebe4ef8d580c0bde`
 ## Werkzeugkonfiguration
 - **Skill-Version:** v8.0.0
 - **Werkzeugadapter:** Python API (TensorX Gateway)
 - **CLI-Version:** Python 3.13.15, requests 2.34.2, Adapter-Skript v1.0.0
 - **CLI-Pfad:** `c:\DEV\MasterArbeit\.claude\skills\run-experiment\glm-kimi-adapter.py`
 - **Modell (angefordert):** `z-ai/glm-5.2`
 - **Modelle (tatsächlich eingesetzt):** `z-ai/glm-5.2` (100 % der Tokens)
 - **Kontrolle Modell:** bestanden – angefordertes und tatsächlich eingesetztes Modell identisch
 - **Effort:** high (per `--effort high` gesetzt; GLM `thinking.level` = `high`)
 - **Laufverzeichnis-ID:** `v8.0.0-f46c`
 - **Ablage:** `Iteration 6/z-ai/glm-5.2/solo/high/`
 - **Parallele Läufe:** nein
 - **Agentenmodus:** solo (V1) – keine Subagenten
 - **Kontextfenster:** nicht erfasst (TensorX gibt keines zurück)
 - **Sampling-Parameter:** Temperatur 1.0; Reasoning-Effort high
 - **Permission-/Sandbox-Modus:** Kommando-Denylist im Adapter
 - **Toolfreigabe:** `read_file`, `list_directory`, `search_files`, `execute_command`, `write_file`
 - **Isolationsmechanismus:** Eigenständiges Python-Skript, Pfad-Sicherheit, Denylist, bereinigter Snapshot
 - **MCP-Server / Agentendateien:** keine
 - **Subagenten:** 0 (Modus `solo`, durch Architektur erzwungen)
 - **Verschachtelung:** `spawned` = 0, `max_depth` = 0
 ## Validierungsstichprobe
 - **Größe:** noch nicht festgelegt
 - **Stand:** noch nicht gezogen
 ## Verbrauch
 ### Hauptagent (`usage`)
 | Messgröße | Wert |
 |---|---:|
 | Input-Tokens | 2.102.113 |
 | Output-Tokens | 69.438 (davon 7.527 Reasoning-Tokens) |
 | Cache-Write-Tokens | nicht erfasst |
 | Cache-Read-Tokens | 1.938.240 |
 | Agent-Turns | 33 |
 ### Gesamtlauf (`modelUsage`, abrechnungsrelevant)
 | Messgröße | z-ai/glm-5.2 |
 |---|---:|
 | Input-Tokens | 2.102.113 |
 | Output-Tokens | 69.438 |
 | Cache-Write-Tokens | nicht erfasst |
 | Cache-Read-Tokens | 1.938.240 |
 | **Tokens gesamt** | **2.171.551** |
 **Tokens gesamt: 2.171.551** — Reasoning-Tokens (7.527) sind Teilmenge der Output-Tokens;
 Cache-Read-Tokens (1.938.240) sind Teilmenge der Input-Tokens.
 ## Gefundene Anforderungen
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 20 | 22,2 % |
 | SyRS | 50 | 55,6 % |
 | SwRS | 20 | 22,2 % |
 | **Gesamt** | **90** | 100 % |
 ### Anforderungstypen
 | Typ | Anzahl | Anteil |
 |---|---:|---:|
 | funktional | 43 | 47,8 % |
 | Sicherheit | 20 | 22,2 % |
 | Schnittstelle | 11 | 12,2 % |
 | Daten | 10 | 11,1 % |
 | nicht-funktional | 6 | 6,7 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 188 |
 | davon `PRIMÄR` | 150 (79,8 %) |
 | davon `SEKUNDÄR` | 37 (19,7 %) |
 | davon `KONTEXT` | 1 (0,5 %) |
 | Belege je Anforderung (Median) | 2,0 |
 | Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 89 (98,9 %) |
 ### Status
 | Kategorie | Anzahl | Anteil |
 |---|---:|---:|
 | belegt | 88 | 97,8 % |
 | als `HYPOTHESE` gekennzeichnet | 2 | 2,2 % |
 | Konsolidierungskandidaten | 3 | 3,3 % |
 ### Regelkonformität
 | Vorgabe | Ergebnis |
 |---|---|
 | Belegpflicht | **erfüllt** (0 ohne Beleg) |
 | Risikobasierte Priorisierung | **erfüllt** (30 risikorelevant, alle gedeckt) |
 | Verifizierbarkeit | **erfüllt** |
 | Übernahmewürdigkeit | **erfüllt** (alle 90) |
 | Traceability | 90/90 mit Tracelinks (100 %) |
 ## Ergebnis
 - **Status:** erfolgreich
 - **Session-ID:** nicht erfasst
 - **Permission-Denials:** nicht erfasst (hartes Blockieren)
 - **Kontrolle Agentenmodus:** `spawned` = 0 (solo: korrekt)
 - **Gültigkeit:** gültig – 7 Ergebnisdateien, Stderr.log ohne Abbruch
 - **Erzeugte Dateien:** Analysebericht.md, Glossar.md, Hypothesen.md, StRS.md, SwRS.md, SyRS.md, Traceability.md
 - **Root unverändert:** ja (before/after beide leer)
 - **Anmerkungen:**
  - Erster Lauf mit Python-API-Adapter über TensorX (MAJOR 8.0.0, Iteration 6).
  - Tool-Schwerpunkt: 88× `list_directory` vs. 10× `read_file` – Verzeichnislastige Erkundung.
  - Tokenverbrauch (2,17 Mio.) deutlich niedriger als Claude-Solo (4,3–27,6 Mio.).
  - Reasoning-Tokens sehr niedrig (7.527 = 3,4 % der Output-Tokens).
  - Alle 30 risikorelevanten Anforderungen korrekt gedeckt.
  - Adapter-Bug: Ergebnisdateien landeten in `Ergebnisse\Ergebnisse\` (modellseitiger Pfad-Präfix), nachträglich korrigiert.
@@ -0,0 +1,11 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T05:41:44.593582+00:00
 [glm-kimi-adapter] Provider: TensorX API Gateway
 [glm-kimi-adapter] Modell: z-ai/glm-5.2
 [glm-kimi-adapter] Effort: high
 [glm-kimi-adapter] Ende: 2026-08-28T05:47:23.891133+00:00
 [glm-kimi-adapter] Turns: 33
 [glm-kimi-adapter] Tokens gesamt: 2,171,551
 [glm-kimi-adapter] Tool-Calls: 108
 [glm-kimi-adapter] Ergebnisdateien: 7
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 6\z-ai\glm-5.2\solo\high\02_Lauf_2026-08-28_074135_v8.0.0-f46c\RawResult.json
@@ -0,0 +1 @@
@@ -0,0 +1,62 @@
 ## Gefundene Anforderungen
 Maschinell aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` ausgewertet (Blockformat des Prompts). Erzeugt von `analyse-anforderungen.py`.
 Die Kenngrößen decken die **maschinell prüfbare** Hälfte des Evaluationsrahmens aus Kapitel 4.3 ab: Belegqualität und Übernahmewürdigkeit gehören zur *Statement-Qualität*, Verteilung und Konsolidierungskandidaten zur *Set-Qualität*, Tracelinks und Belegklassifikation zur *Traceability-Qualität*. Die Expertenbewertung nach Likert-Skala tritt daneben und wird hier nicht ersetzt.
 ### Verteilung über die Ebenen
 | Ebene | Anzahl | Anteil |
 |---|---:|---:|
 | StRS | 20 | 22,2 % |
 | SyRS | 50 | 55,6 % |
 | SwRS | 20 | 22,2 % |
 | **Gesamt** | **90** | 100 % |
 ### Anforderungstypen
 | Typ | Anzahl | Anteil |
 |---|---:|---:|
 | funktional | 43 | 47,8 % |
 | Sicherheit | 20 | 22,2 % |
 | Schnittstelle | 11 | 12,2 % |
 | Daten | 10 | 11,1 % |
 | nicht-funktional | 6 | 6,7 % |
 ### Belegqualität
 | Messgröße | Wert |
 |---|---:|
 | Belege gesamt | 188 |
 | davon `PRIMÄR` | 150 (79,8 %) |
 | davon `SEKUNDÄR` | 37 (19,7 %) |
 | davon `KONTEXT` | 1 (0,5 %) |
 | Belege je Anforderung (Median) | 2,0 |
 | Anforderungen mit mindestens einem `PRIMÄR`-Beleg | 89 (98,9 %) |
 ### Übernahmewürdigkeit
 | Einstufung | Anzahl | Anteil |
 |---|---:|---:|
 | übernehmen | 90 | 100,0 % |
 ### Status
 | Kategorie | Anzahl | Anteil |
 |---|---:|---:|
 | belegt | 88 | 97,8 % |
 | als `HYPOTHESE` gekennzeichnet | 2 | 2,2 % |
 | als Workaround vermerkt | 0 | 0,0 % |
 | Konsolidierungskandidaten | 3 | 3,3 % |
 | mit ISO-25010-Qualitätsmerkmal | 6 | 6,7 % |
 ### Regelkonformität (Prüfung gegen die Vorgaben des Prompts)
 | Vorgabe | Ergebnis |
 |---|---|
 | **Belegpflicht** – jede Anforderung mindestens ein Artefaktbeleg | **erfüllt** (0 Anforderungen ohne Beleg) |
 | **Risikobasierte Priorisierung** – Sicherheit, Abrechnung, Berechtigungen brauchen einen `PRIMÄR`-Beleg oder die Kennzeichnung `[HYPOTHESE]` | **erfüllt** (30 risikorelevante Anforderungen, alle gedeckt) |
 | **Verifizierbarkeit** – jede Anforderung mit Prüfidee oder Akzeptanzkriterium | **erfüllt** |
 | **Übernahmewürdigkeit** – Einstufung für die Migrationsperspektive | **erfüllt** (alle 90 Anforderungen eingestuft) |
 | **Traceability** – Verknüpfung zwischen den Ebenen | 90 von 90 mit Tracelinks (100,0 %) |
@@ -0,0 +1 @@
@@ -0,0 +1,181 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 02
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 02 (erste Überarbeitung nach Auswertung von Iteration 01)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-26
 - **Vorgänger:** `01_Prompt.md` (SHA-256 `1B0DB06B…3C02FF`), 24 Läufe an Tag 1
 - **Änderungsgrund:** Auswertung der 24 Läufe von Tag 1 über 3.287 erzeugte Anforderungen. Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
  | Modulinventar als Pflicht-Vorstufe, Mindestabdeckung je Modul, Vertiefung erst danach | Anforderungszahl schwankte je Lauf zwischen 42 und 325 (Faktor 5,9); 55 bis 60 von rund 85 Modulen blieben unanalysiert; die Modultabellen der Analyseberichte reichten von 0 bis 51 Zeilen |
  | Hypothesenpflicht kalibriert, `Hypothesen.md` deckungsgleich mit den Inline-Markierungen | Zwei Läufe meldeten null Hypothesen bei 71 bzw. 148 Anforderungen; der Anteil schwankte zwischen 0 % und 26,2 %; mehrfach wichen Sammeldatei und Inline-Markierungen voneinander ab |
  | Primärbeleg muss die durchsetzende Stelle benennen | 45,9 % aller Anforderungen trugen genau einen Beleg; in einem Lauf waren 5 von 31 risikorelevanten Anforderungen weder mit `PRIMÄR` noch als `[HYPOTHESE]` gedeckt |
  | Belegpflicht verschärft: ohne Beleg keine Anforderung | Eine Anforderung wurde ohne jeden Beleg geschrieben |
  | Konsolidierungsbegriff an einem Beispiel kalibriert | Anteil der Konsolidierungskandidaten schwankte je Lauf zwischen 2,4 % und 35,2 % |
  | Eigenes Feld `Qualitätsmerkmal` für die ISO-25010-Zuordnung | Die Zuordnung war gefordert, hatte aber keinen Ablageort: nur 33 von 313 nicht-funktionalen Anforderungen führten sie als eigene Angabe |
  | Risikoanforderungen im Konsistenzcheck auflisten | Verstöße gegen die risikobasierte Priorisierung fielen erst in der nachgelagerten Auswertung auf, nicht im Lauf selbst |
  Unverändert bleiben Prüfidee, Tracelinks, Belegklassifikation und das Blockformat: Prüfidee und Tracelinks waren in **allen** 3.287 Anforderungen gesetzt, 78,6 % der Belege waren `PRIMÄR`.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz. Diese Angabe steuert die spätere fachliche Priorisierung; eine Fehleinschätzung ist unkritisch, eine fehlende Angabe nicht.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Nicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $laufDir\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T07:47:24.0154222+02:00
@@ -0,0 +1,11 @@
 {
  "promptHash": "F9B2A1AAB45DDCB87E905B83F24D7B1C7860D81CA07E503E51222E266E0D7849",
  "dirtyCount": 0,
  "modell": "z-ai/glm-5.2",
  "gitHead": "37275c96d610a8b7958d126bebe4ef8d580c0bde",
  "skillVersion": "v8.0.0",
  "root": "c:\\DEV\\MasterArbeit\\QuellCode\\CentronERP",
  "effort": "high",
  "modus": "solo",
  "iteration": "Iteration 6"
 }
@@ -0,0 +1 @@
 2026-08-28T07:41:36.4844788+02:00
@@ -0,0 +1,165 @@
 # Analysebericht – Reverse Requirements Engineering c-entron ERP-Suite
 **Stand:** Arbeitsstand Schritt 0 (Modulinventar). Abdeckungstabelle, Konsistenzcheck und Selbstbewertung folgen am Ende des Laufs in dieser Datei.
 ## Schritt 0 – Modulinventar
 Grundlage: Verzeichnisstruktur des Arbeitsverzeichnisses. Die fachlichen Module der Business-Logik (`src/backend/Centron.BL`) bilden das fachliche Rückgrat; technische Basiskomponenten, Clients, Hosts, Integrationen und Betriebsartefakte sind eigene Inventarzeilen.
 ### A. Fachliche Module in src/backend/Centron.BL
 | # | Modul | Pfad | Fachliche Aufgabe (1 Satz, vorläufig aus Namen/Struktur) |
 |---|-------|------|-------------------------------------------------------------|
 | A01 | Accounting | src/backend/Centron.BL/Accounting | Fibu-/Buchhaltungsfunktionen und Buchungslogik. |
 | A02 | Accounts | src/backend/Centron.BL/Accounts | Benutzerkonten-/Kontenverwaltung. |
 | A03 | Administration | src/backend/Centron.BL/Administration | Systemadministration und Grundeinstellungen. |
 | A04 | AppointmentRequests | src/backend/Centron.BL/AppointmentRequests | Terminanfragen/-abstimmung mit Externen. |
 | A05 | ArtificialIntelligence | src/backend/Centron.BL/ArtificialIntelligence | KI-gestützte Funktionen. |
 | A06 | BusinessPartner | src/backend/Centron.BL/BusinessPartner | Geschäftspartnerstamm (Kunden/Lieferanten). |
 | A07 | Buying | src/backend/Centron.BL/Buying | Einkaufsprozesse (Bestellwesen). |
 | A08 | Calendar | src/backend/Centron.BL/Calendar | Kalender und Terminverwaltung. |
 | A09 | CentronIcons | src/backend/Centron.BL/CentronIcons | Zentrale Icon-Verwaltung. |
 | A10 | CentronNexus (BL) | src/backend/Centron.BL/CentronNexus | BL-Unterstützung für das Web-Frontend Nexus. |
 | A11 | ChangeTracking | src/backend/Centron.BL/ChangeTracking | Änderungsverfolgung/Audit-Trail auf Entitäten. |
 | A12 | Chats | src/backend/Centron.BL/Chats | Interne Chat-Kommunikation. |
 | A13 | CheckListArea | src/backend/Centron.BL/CheckListArea | Checklisten-Vorlagen und -Instanzen. |
 | A14 | Core | src/backend/Centron.BL/Core | Kern-Basisfunktionen der BL. |
 | A15 | CountryArea | src/backend/Centron.BL/CountryArea | Länder-/Regionsstammdaten. |
 | A16 | CPra | src/backend/Centron.BL/CPra | c-entron Preis-/Rabatt- oder Kalkulationsmodul (zu prüfen). |
 | A17 | CustomerArea | src/backend/Centron.BL/CustomerArea | Kundenbereich/Kundenverwaltung. |
 | A18 | Customizations | src/backend/Centron.BL/Customizations | Kundenindividuelle Anpassungen. |
 | A19 | DataExchange | src/backend/Centron.BL/DataExchange | Datenimport/-export und Austauschformate. |
 | A20 | Devices | src/backend/Centron.BL/Devices | Geräte-/Asset-Verwaltung. |
 | A21 | DocuBoard | src/backend/Centron.BL/DocuBoard | Dokumenten-Dashboard/Dokumentenanzeige. |
 | A22 | DocumentationArea | src/backend/Centron.BL/DocumentationArea | Dokumentationsfunktionen/Wissensbasis. |
 | A23 | EDI | src/backend/Centron.BL/EDI | Elektronischer Datenaustausch (EDI). |
 | A24 | EmployeeArea | src/backend/Centron.BL/EmployeeArea | Mitarbeiterstamm und -verwaltung. |
 | A25 | Exceptions | src/backend/Centron.BL/Exceptions | Zentrale Ausnahme-/Fehlerbehandlung. |
 | A26 | ExpectedEvents | src/backend/Centron.BL/ExpectedEvents | Erwartete Ereignisse/Ereignis-Monitoring. |
 | A27 | ExternalHelpdesk | src/backend/Centron.BL/ExternalHelpdesk | Anbindung externer Ticketsysteme. |
 | A28 | ExternalToolsBL | src/backend/Centron.BL/ExternalToolsBL | Anbindung externer Werkzeuge. |
 | A29 | Finances | src/backend/Centron.BL/Finances | Finanzwesen: Zahlungsein-/ausgänge, Onlinebanking, Zahlläufe. |
 | A30 | Gateway | src/backend/Centron.BL/Gateway | Interne Gateway-/Kommunikationsschicht. |
 | A31 | GUI | src/backend/Centron.BL/GUI | BL-Unterstützung für Oberflächen. |
 | A32 | Helpers | src/backend/Centron.BL/Helpers | Hilfsfunktionen (querschnittlich). |
 | A33 | IndexSearch | src/backend/Centron.BL/IndexSearch | Volltext-/Indexsuche. |
 | A34 | Integrations | src/backend/Centron.BL/Integrations | Allgemeine Integrationslogik zu Drittsystemen. |
 | A35 | ItPlanner | src/backend/Centron.BL/ItPlanner | IT-Planung (Einsatz-/Projektplanung). |
 | A36 | Logistics | src/backend/Centron.BL/Logistics | Logistik- und Versandprozesse. |
 | A37 | Mail | src/backend/Centron.BL/Mail | E-Mail-Verarbeitung im System. |
 | A38 | Mailings | src/backend/Centron.BL/Mailings | Serienmail-/Newsletter-Funktionen. |
 | A39 | MailScanner | src/backend/Centron.BL/MailScanner | Automatische Abarbeitung eingehender E-Mails. |
 | A40 | MassUpdate | src/backend/Centron.BL/MassUpdate | Massendatenänderungen. |
 | A41 | Mobile | src/backend/Centron.BL/Mobile | BL für mobile Anbindung. |
 | A42 | Modules | src/backend/Centron.BL/Modules | Modul-/Lizenzverwaltung der Anwendung. |
 | A43 | MyCentron | src/backend/Centron.BL/MyCentron | Persönlicher Startbereich des Benutzers. |
 | A44 | MyDay | src/backend/Centron.BL/MyDay | Tagesübersicht/Tagesplanung des Benutzers. |
 | A45 | NexusNotifications | src/backend/Centron.BL/NexusNotifications | Benachrichtigungen für Nexus (Web). |
 | A46 | NexusTicketViews | src/backend/Centron.BL/NexusTicketViews | Ticket-Sichten/Helpdesk im Web. |
 | A47 | Notifications | src/backend/Centron.BL/Notifications | Allgemeines Benachrichtigungswesen. |
 | A48 | ObjectExternalReferences | src/backend/Centron.BL/ObjectExternalReferences | Externe Referenzen auf Geschäftsobjekte (z. B. DMS-Links). |
 | A49 | Outlook | src/backend/Centron.BL/Outlook | Outlook-Integration/Synchronisation. |
 | A50 | PasswordManagementArea | src/backend/Centron.BL/PasswordManagementArea | Verwaltung von Passwörtern/Zugangsdaten. |
 | A51 | PasswordManager | src/backend/Centron.BL/PasswordManager | Passwort-Tresor-Funktionalität. |
 | A52 | Processes | src/backend/Centron.BL/Processes | Prozess-/Workflow-Engine (C-FLOW). |
 | A53 | Production | src/backend/Centron.BL/Production | Fertigung/Produktionsaufträge. |
 | A54 | ProductMatrix | src/backend/Centron.BL/ProductMatrix | Produktvarianten-/Matrixverwaltung. |
 | A55 | Projects | src/backend/Centron.BL/Projects | Projektverwaltung. |
 | A56 | Purchasing | src/backend/Centron.BL/Purchasing | Beschaffung/Einkauf (Belege, Anfragen). |
 | A57 | ReportEngine | src/backend/Centron.BL/ReportEngine | Berichtsgenerator/Reporting-Engine. |
 | A58 | Reporting | src/backend/Centron.BL/Reporting | Auswertungen und Berichtsfunktionen. |
 | A59 | Resources | src/backend/Centron.BL/Resources | Ressourcenverwaltung (zu prüfen). |
 | A60 | RiverDivo | src/backend/Centron.BL/RiverDivo | Anbindung Riverbird/RiverDivo-Videoportal (zu prüfen). |
 | A61 | Sales | src/backend/Centron.BL/Sales | Vertrieb: Belege, Kasse, Kunden, Vertriebssteuerung. |
 | A62 | Security | src/backend/Centron.BL/Security | Rechte-/Rollenprüfung und Zugriffsschutz. |
 | A63 | SelfCare | src/backend/Centron.BL/SelfCare | Selbstverwaltungsfunktionen des Benutzers. |
 | A64 | Services | src/backend/Centron.BL/Services | Dienstleistungen/Service-Abrechnung. |
 | A65 | SocialMedia | src/backend/Centron.BL/SocialMedia | Social-Media-Anbindung. |
 | A66 | Start | src/backend/Centron.BL/Start | Anwendungsstart/Initialisierung. |
 | A67 | Statistics | src/backend/Centron.BL/Statistics | Statistikfunktionen. |
 | A68 | Storage | src/backend/Centron.BL/Storage | Lagerorte/Lagerplatzverwaltung. |
 | A69 | SystemArea | src/backend/Centron.BL/SystemArea | Systemeinstellungen/-verwaltung. |
 | A70 | Tags | src/backend/Centron.BL/Tags | Schlagwort-/Tag-Verwaltung. |
 | A71 | Tapi | src/backend/Centron.BL/Tapi | Telefonie-Integration (TAPI). |
 | A72 | TaskManager | src/backend/Centron.BL/TaskManager | Aufgabenverwaltung. |
 | A73 | Telemetry | src/backend/Centron.BL/Telemetry | Telemetrie-/Nutzungsdatenerfassung. |
 | A74 | TextModuleArea | src/backend/Centron.BL/TextModuleArea | Textbaustein-Verwaltung. |
 | A75 | TicketProjects | src/backend/Centron.BL/TicketProjects | Verknüpfung Tickets/Projekte. |
 | A76 | Time | src/backend/Centron.BL/Time | Zeiterfassung. |
 | A77 | ToDoArea | src/backend/Centron.BL/ToDoArea | Aufgabenlisten/ToDos des Benutzers. |
 | A78 | Tools | src/backend/Centron.BL/Tools | Diverse Werkzeuge. |
 | A79 | TradePool | src/backend/Centron.BL/TradePool | Handelspool/Einkaufsverbund-Anbindung. |
 | A80 | Transactions | src/backend/Centron.BL/Transactions | Transaktionsverwaltung/-kontrolle. |
 | A81 | TwoFactorAuthenticator | src/backend/Centron.BL/TwoFactorAuthenticator | Zwei-Faktor-Authentifizierung. |
 | A82 | Urls | src/backend/Centron.BL/Urls | URL-Verwaltung/-Auflösung. |
 | A83 | VideoPortal | src/backend/Centron.BL/VideoPortal | Videoportal-Integration. |
 | A84 | VoucherManagement | src/backend/Centron.BL/VoucherManagement | Gutscheinverwaltung. |
 | A85 | Warehousing | src/backend/Centron.BL/Warehousing | Lagerverwaltung (Bestände, Bewegungen). |
 | A86 | WebLinks | src/backend/Centron.BL/WebLinks | Verwaltung von Weblinks zu Objekten. |
 | A87 | WebServices | src/backend/Centron.BL/WebServices | BL für Webservice-Schnittstellen. |
 | A88 | WebSuite | src/backend/Centron.BL/WebSuite | WebSuite-Anbindung (Onlineshop, zu prüfen). |
 | A89 | WebVersion | src/backend/Centron.BL/WebVersion | Versions-/Kompatibilitätshandling für Web-Clients. |
 ### B. Technische Basiskomponenten
 | # | Komponente | Pfad | Aufgabe |
 |---|------------|------|---------|
 | B01 | Centron.DAO | src/backend/Centron.DAO | Datenzugriffsschicht (NHibernate), Repositories, Session-Handling. |
 | B02 | Centron.Entities | src/backend/Centron.Entities | Persistente Entitäten des Datenmodells. |
 | B03 | Centron.Common | src/backend/Centron.Common | Querschnittliche Hilfsbibliothek (Logging, Einstellungen, Netzwerk, Modul-Features). |
 | B04 | Centron.Interfaces | src/backend/Centron.Interfaces | Schnittstellendefinitionen und Konstanten (u. a. UserRightsConst). |
 | B05 | Centron.Gateway | src/backend/Centron.Gateway | Gateway-Komponente. |
 | B06 | DB-Schema | SSMS_DB_SCHEMA.sql | Vollständiges MSSQL-Datenbankschema (1558 Tabellen). |
 ### C. Clients und Frontends
 | # | Komponente | Pfad | Aufgabe |
 |---|------------|------|---------|
 | C01 | WPF-Client | src/centron/Centron.WPF.UI | Desktop-Hauptclient (XAML/WPF, DevExpress). |
 | C02 | WPF-Extension | src/centron/Centron.WPF.UI.Extension | Erweiterungspunkte des Desktop-Clients. |
 | C03 | Centron.Controls | src/shared/Centron.Controls | Gemeinsame UI-Steuerelemente. |
 | C04 | Centron.Controls.Preview | src/shared/Centron.Controls.Preview | Vorschau-/Testapp für Steuerelemente. |
 | C05 | Centron.Core (shared) | src/shared/Centron.Core | Geteilte Kernbibliothek. |
 | C06 | Nexus (Blazor-Web) | src/nexus/CentronNexus | Web-Anwendung (Shop/WebCart, WebOffer, ServiceBoard, Dokumentensignatur, Produktionsauftragsverwaltung). |
 | C07 | Nexus.Host | src/nexus/CentronNexus.Host | Hosting/Startprojekt für Nexus. |
 | C08 | Outlook-AddIn | src/nexus/CentronNexus.OutlookAddIn | Outlook-Integration als Add-In (Blazor). |
 ### D. Webservice-Schicht
 | # | Komponente | Pfad | Aufgabe |
 |---|------------|------|---------|
 | D01 | Centron.Host | src/webservice/Centron.Host | ASP.NET-Core-Host des Webservice. |
 | D02 | Centron.Controllers | src/webservice/Centron.Controllers | REST-API-Controller inkl. Authorization. |
 | D03 | Centron.WebServices.Core | src/webservice/Centron.WebServices.Core | Kernlogik der Webservices. |
 | D04 | Host.Console | src/webservice/Centron.Host.Console | Konsolen-Host. |
 | D05 | Host.WindowsService | src/webservice/Centron.Host.WindowsService | Windows-Dienst-Host. |
 | D06 | ConnectionManager | src/webservice/c-entron.misc.ConnectionManager | Verbindungsverwaltung. |
 ### E. Externe Integrationen (APIs)
 | # | Komponente | Pfad | Aufgabe |
 |---|------------|------|---------|
 | E01 | Api.EbInterface | src/apis/Centron.Api.EbInterface | Elektronische Rechnung (ebInterface, AT). |
 | E02 | Api.Gls | src/apis/Centron.Api.Gls | GLS-Versandanbindung. |
 | E03 | Api.Shipcloud | src/apis/Centron.Api.Api.Shipcloud (src/apis/Centron.Api.Shipcloud) | Shipcloud-Versanddienstleister. |
 | E04 | APIs.CopDataAccess | src/apis/Centron.APIs.CopDataAccess | Cop-Daten-Integration (IT-Beschaffung). |
 | E05 | APIs.EgisDataAccess | src/apis/Centron.APIs.EgisDataAccess | Egis-Daten-Integration. |
 | E06 | APIs.FinAPI | src/apis/Centron.APIs.FinAPI | FinAPI-Onlinebanking-Anbindung. |
 | E07 | APIs.IcecatDataAccess | src/apis/Centron.APIs.IcecatDataAccess | Icecat-Produktdatenkatalog. |
 | E08 | APIs.ITscopeDataAccess | src/apis/Centron.APIs.ITscopeDataAccess | ITscope-Einkaufsplattform. |
 | E09 | Api.docuFORM | Centron.Api.docuFORM | Dokumentenerzeugung (docuFORM). |
 ### F. Betrieb, Deployment, Qualität
 | # | Komponente | Pfad | Aufgabe |
 |---|------------|------|---------|
 | F01 | Docker/Container | docker/ | Containerisierung (API, Webservice, Demo, Tests). |
 | F02 | Deployment | deployment/ | Installer (WixSharp), Riverbird-Deployment. |
 | F03 | Azure-Pipelines | azure/, azure-blazor/ | CI/CD-, Test-, Security- und Playwright-Pipelines. |
 | F04 | Skripte | scripts/ | Build-/Hilfsskripte. |
 | F05 | Tests | tests/ | Integrations-, End-to-End-, Playwright- und Unit-Tests. |
 | F06 | Dokumentation | docs/ | Projektdokumentation (Features, Guides, Reference). |
 | F07 | Rechte-Dokumentation | CentronRights.md | Dokumentierte Benutzerrechte (Helpdesk, Kalender, Auslastung). |
 | F08 | Assemblies/Nugets | assemblies/, nugets/ | Gebündelte Drittanbieter-Bibliotheken/Pakete. |
 *(Fortsetzung mit Abdeckungstabelle, Konsistenzcheck und Selbstbewertung am Laufende.)*
@@ -0,0 +1,17 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T09:24:29.128810+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 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 2 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 3 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 4 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 5 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 6 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 7 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 8 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 9 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 10 gestartet (Typ: general-purpose)
 [glm-kimi-adapter] Subagent 11 gestartet (Typ: general-purpose)
@@ -0,0 +1 @@
@@ -0,0 +1 @@
@@ -0,0 +1,179 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 03
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-28
 - **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
 - **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```text
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 **Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Zusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.
 Nicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 - spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only)
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $lauf\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T12:57:19.7699072+02:00
@@ -0,0 +1,9 @@
 {
  "modell": "moonshotai/kimi-k3",
  "iteration": "Iteration 7",
  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
  "promptVersion": "03",
  "modus": "builtin",
  "effort": "high",
  "skillVersion": "v8.0.0"
 }
@@ -0,0 +1 @@
 2026-08-28T11:16:56.1320067+02:00
@@ -0,0 +1,516 @@
 {
  "is_error": false,
  "subtype": "success",
  "duration_ms": 2620788,
  "duration_api_ms": 2620788,
  "num_turns": 23,
  "model": "moonshotai/kimi-k3",
  "model_requested": "moonshotai/kimi-k3",
  "provider": "tensorx",
  "usage": {
    "prompt_tokens": 617527,
    "completion_tokens": 10695,
    "total_tokens": 628222,
    "cached_tokens": 482816,
    "cache_read_tokens": 482816,
    "cache_creation_tokens": 0,
    "reasoning_tokens": 6790,
    "output_tokens_details": {
      "thinking_tokens": 6790
    }
  },
  "modelUsage": {
    "moonshotai/kimi-k3": {
      "input_tokens": 617527,
      "output_tokens": 10695,
      "cache_read_input_tokens": 482816,
      "cache_creation_input_tokens": 0,
      "reasoning_tokens": 6790
    }
  },
  "tool_calls": [
    {
      "turn": 1,
      "name": "list_directory",
      "args": {
        "path": "."
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "src"
      }
    },
    {
      "turn": 2,
      "name": "read_file",
      "args": {
        "path": "README.md"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/centron"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/backend"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/apis"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/shared"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/nexus"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/webservice"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/centron/Centron.WPF.UI"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL"
      }
    },
    {
      "turn": 5,
      "name": "read_file",
      "args": {
        "path": "CentronRights.md"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "docs"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "tests"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "docs/features"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "docs/reference"
      }
    },
    {
      "turn": 7,
      "name": "list_directory",
      "args": {
        "path": "docs/reference/receipts"
      }
    },
    {
      "turn": 7,
      "name": "list_directory",
      "args": {
        "path": "docs/reference/security"
      }
    },
    {
      "turn": 7,
      "name": "list_directory",
      "args": {
        "path": "docs/reference/architecture"
      }
    },
    {
      "turn": 7,
      "name": "list_directory",
      "args": {
        "path": "docs/reference/database"
      }
    },
    {
      "turn": 7,
      "name": "list_directory",
      "args": {
        "path": "docs/reference/edi"
      }
    },
    {
      "turn": 8,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Sales"
      }
    },
    {
      "turn": 8,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Security"
      }
    },
    {
      "turn": 8,
      "name": "read_file",
      "args": {
        "path": "docs/reference/receipts/receipts-backend-architecture.md"
      }
    },
    {
      "turn": 9,
      "name": "read_file",
      "args": {
        "path": "docs/reference/security/licensing-system.md"
      }
    },
    {
      "turn": 9,
      "name": "read_file",
      "args": {
        "path": "docs/reference/receipts/actionprice-system.md"
      }
    },
    {
      "turn": 10,
      "name": "read_file",
      "args": {
        "path": "docs/reference/receipts/Contract-Billing-RMM-Article-Logic.md"
      }
    },
    {
      "turn": 10,
      "name": "read_file",
      "args": {
        "path": "docs/reference/edi/edi-architecture.md"
      }
    },
    {
      "turn": 10,
      "name": "execute_command",
      "args": {
        "command": "grep -c \"CREATE TABLE\" SSMS_DB_SCHEMA.sql; grep -oP \"CREATE TABLE \\[dbo\\]\\.\\[\\K[a-zA-Z0-9_]+\" SSMS_DB_SCHEMA.sql | sort | head -n 150"
      }
    },
    {
      "turn": 11,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"(Select-String -Path SSMS_DB_SCHEMA.sql -Pattern 'CREATE TABLE \\[dbo\\].\\[(\\w+)\\]' -AllMatches | ForEach-Object { $_.Matches[0].Groups[1].Value } | Sort-Object -Unique).Count\""
      }
    },
    {
      "turn": 11,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"Select-String -Path SSMS_DB_SCHEMA.sql -Pattern 'CREATE TABLE \\[dbo\\].\\[(\\w+)\\]' -AllMatches | ForEach-Object { $_.Matches[0].Groups[1].Value } | Sort-Object -Unique | Select-Object -First 180\""
      }
    },
    {
      "turn": 12,
      "name": "list_directory",
      "args": {
        "path": "src/centron/Centron.WPF.UI/Modules"
      }
    },
    {
      "turn": 12,
      "name": "list_directory",
      "args": {
        "path": "src/nexus/CentronNexus"
      }
    },
    {
      "turn": 12,
      "name": "search_files",
      "args": {
        "pattern": "HashPassword|BCrypt|SHA256|PasswordHasher",
        "file_pattern": "*.cs",
        "path": "src/backend"
      }
    },
    {
      "turn": 12,
      "name": "search_files",
      "args": {
        "pattern": "class UserRightsConst",
        "file_pattern": "*.cs"
      }
    },
    {
      "turn": 13,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Accounts"
      }
    },
    {
      "turn": 13,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Finances"
      }
    },
    {
      "turn": 13,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Warehousing"
      }
    },
    {
      "turn": 13,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"(Get-ChildItem -Recurse -File -Include *.cs,*.xaml,*.razor,*.sql -Path src | Measure-Object).Count; (Get-ChildItem -Recurse -File -Include *.cs -Path src | Measure-Object -Property Length -Sum).Sum/1MB\""
      }
    },
    {
      "turn": 14,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Modules"
      }
    },
    {
      "turn": 14,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Sales/Support"
      }
    },
    {
      "turn": 14,
      "name": "search_files",
      "args": {
        "pattern": "enum (ReceiptState|ReceiptStatus|TicketState|HelpdeskState)",
        "file_pattern": "*.cs",
        "path": "src"
      }
    },
    {
      "turn": 14,
      "name": "search_files",
      "args": {
        "pattern": "public .*Login",
        "file_pattern": "*.cs",
        "path": "src/webservice/Centron.WebServices.Core"
      }
    },
    {
      "turn": 15,
      "name": "read_file",
      "args": {
        "path": "src/backend/Centron.Interfaces/Sales/Receipts/ReceiptState.cs"
      }
    },
    {
      "turn": 15,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Processes"
      }
    },
    {
      "turn": 15,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Administration"
      }
    },
    {
      "turn": 16,
      "name": "search_files",
      "args": {
        "pattern": "Stammblatt",
        "path": "src/backend/Centron.BL"
      }
    },
    {
      "turn": 16,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Accounting"
      }
    },
    {
      "turn": 16,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL/Time"
      }
    },
    {
      "turn": 16,
      "name": "list_directory",
      "args": {
        "path": "src/nexus/CentronNexus/ServiceBoard"
      }
    },
    {
      "turn": 16,
      "name": "list_directory",
      "args": {
        "path": "src/nexus/CentronNexus/WebCart"
      }
    },
    {
      "turn": 17,
      "name": "read_file",
      "args": {
        "path": "src/webservice/Centron.WebServices.Core/Interception/Interceptors/AuthenticateAttribute.cs"
      }
    },
    {
      "turn": 17,
      "name": "search_files",
      "args": {
        "pattern": "class LicenseManager",
        "file_pattern": "*.cs",
        "path": "src"
      }
    },
    {
      "turn": 17,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"Select-String -Path SSMS_DB_SCHEMA.sql -Pattern 'CREATE TABLE \\[dbo\\].\\[RechKopf\\]' -Context 0,45 | Select-Object -First 1 | ForEach-Object { $_.Line + \\\"`n\\\" + ($_.Context.PostContext -join \\\"`n\\\") }\""
      }
    },
    {
      "turn": 18,
      "name": "read_file",
      "args": {
        "path": "src/backend/Centron.BL/Administration/Licensing/LicenseManager.cs"
      }
    },
    {
      "turn": 18,
      "name": "search_files",
      "args": {
        "pattern": "Result.*AsError\\(.*(gelöscht|löschen|stornier)",
        "file_pattern": "*.cs",
        "path": "src/backend/Centron.BL/Sales/Receipts"
      }
    },
    {
      "turn": 18,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"Get-ChildItem src/backend/Centron.BL/TwoFactorAuthenticator, src/backend/Centron.BL/VoucherManagement, src/backend/Centron.BL/PasswordManager, src/backend/Centron.BL/MailScanner, src/backend/Centron.BL/DataExchange -File -ErrorAction SilentlyContinue | Select-Object FullName, Length | Format-Table -AutoSize | Out-String -Width 200\""
      }
    },
    {
      "turn": 19,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"(Get-Content src/backend/Centron.BL/Sales/Receipts/Invoices/ReceiptInvoiceBL.cs | Select-Object -Skip 120 -First 100) -join \\\"`n\\\"\""
      }
    },
    {
      "turn": 19,
      "name": "read_file",
      "args": {
        "path": "src/backend/Centron.BL/TwoFactorAuthenticator/TwoFactorAuthenticationBL.cs"
      }
    },
    {
      "turn": 20,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"foreach ($d in 'TradePool','RiverDivo','CPra','VideoPortal','SocialMedia','Chats','WebLinks','SelfCare','ItPlanner','ExpectedEvents','Services','Storage','Tags','TaskManager','Transactions','Urls','WebSuite','WebVersion','Mobile','Notifications','Time','EmployeeArea','CustomerArea','Devices','Mailings','ObjectExternalReferences','TextModuleArea','AppointmentRequests','Buying','CountryArea','SystemArea','ChangeTracking','CheckListArea','IndexSearch','MassUpdate','MyCentron','MyDay','NexusNotifications','ProductMatrix','Processes','Customizations','DocuBoard','DocumentationArea','Calendar','Mail','Mailings','Projects','TicketProjects','ExternalHelpdesk','Start','Statistics') { $p = \\\"src/backend/Centron.BL/$d\\\"; if (Test-Path $p) { Write-Host \\\"=== $d\\\"; Get-ChildItem $p -Recurse -File -Include *.cs | Select-Object -First 6 | ForEach-Object { $_.Name } } }\""
      }
    },
    {
      "turn": 21,
      "name": "search_files",
      "args": {
        "pattern": "SHOW_HELPDESK_ONLY_OWN",
        "file_pattern": "*.cs",
        "path": "src/backend"
      }
    },
    {
      "turn": 21,
      "name": "search_files",
      "args": {
        "pattern": "HasUserRight\\(",
        "file_pattern": "*.cs",
        "path": "src/backend/Centron.BL/WebServices/Sales/Support"
      }
    },
    {
      "turn": 22,
      "name": "execute_command",
      "args": {
        "command": "powershell -NoProfile -Command \"foreach ($d in 'docker','deployment','azure','azure-blazor','scripts','assemblies','nugets','src/backend/Centron.Gateway','src/webservice/c-entron.misc.ConnectionManager','src/webservice/Centron.Host','src/webservice/Centron.Controllers','src/Centron.Api.docuFORM','src/nexus/CentronNexus.OutlookAddIn','src/nexus/CentronNexus/Management','src/nexus/CentronNexus/Office','src/nexus/CentronNexus/DocumentSigning','src/backend/Centron.BL/Logistics','src/backend/Centron.BL/Administration/DataSecurity','src/backend/Centron.BL/Administration/BackgroundServices','src/backend/Centron.BL/Storage','src/backend/Centron.BL/Administration/FileManagement') { $p = $d; if (Test-Path $p) { Write-Host \\\"=== $d\\\"; Get-ChildItem $p -Recurse -File | Select-Object -First 8 | ForEach-Object { $_.Name } } }\""
      }
    }
  ],
  "tool_call_count": 63,
  "tool_call_types": {
    "list_directory": 34,
    "read_file": 11,
    "execute_command": 9,
    "search_files": 9
  },
  "written_files": [],
  "result": "Ich erfasse noch die Struktur der restlichen Module für das Inventar.",
  "finish_reason": "tool_calls",
  "errors": [
    "Turn 23: API-Fehler: HTTPSConnectionPool(host='api.tensorx.ai', port=443): Read timed out. (read timeout=1800)"
  ],
  "session_id": "",
  "adapter": "python-glm-kimi",
  "adapter_version": "1.1.0",
  "mode": "solo",
  "subagent_stats": {
    "spawned": 0,
    "completed": 0,
    "failed": 0,
    "by_type": {}
  },
  "subagent_details": [],
  "start_time": "2026-08-28T09:17:05.880237+00:00",
  "end_time": "2026-08-28T10:00:46.669452+00:00"
 }
@@ -0,0 +1,13 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T09:17:05.880237+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-28T10:00:46.669452+00:00
 [glm-kimi-adapter] Turns: 23
 [glm-kimi-adapter] Tokens gesamt: 628,222
 [glm-kimi-adapter] Tool-Calls: 63
 [glm-kimi-adapter] Subagenten: 0 (completed: 0, failed: 0)
 [glm-kimi-adapter] Ergebnisdateien: 0
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 7\moonshotai\kimi-k3\solo\high\03_Lauf_2026-08-28_111655_v8.0.0-71a2\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,179 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 03
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-28
 - **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
 - **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```text
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 **Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Nicht verfuegbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $lauf\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T12:00:46.6937130+02:00
@@ -0,0 +1,9 @@
 {
  "modell": "moonshotai/kimi-k3",
  "iteration": "Iteration 7",
  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
  "promptVersion": "03",
  "modus": "solo",
  "effort": "high",
  "skillVersion": "v8.0.0"
 }
@@ -0,0 +1 @@
 2026-08-28T11:16:55.9835159+02:00
@@ -0,0 +1,318 @@
 {
  "is_error": false,
  "subtype": "success",
  "duration_ms": 271443,
  "duration_api_ms": 271443,
  "num_turns": 8,
  "model": "z-ai/glm-5.2",
  "model_requested": "z-ai/glm-5.2",
  "provider": "tensorx",
  "usage": {
    "prompt_tokens": 1081031,
    "completion_tokens": 15433,
    "total_tokens": 1096464,
    "cached_tokens": 830080,
    "cache_read_tokens": 830080,
    "cache_creation_tokens": 0,
    "reasoning_tokens": 1898,
    "output_tokens_details": {
      "thinking_tokens": 1898
    }
  },
  "modelUsage": {
    "z-ai/glm-5.2": {
      "input_tokens": 1081031,
      "output_tokens": 15433,
      "cache_read_input_tokens": 830080,
      "cache_creation_input_tokens": 0,
      "reasoning_tokens": 1898
    }
  },
  "tool_calls": [
    {
      "turn": 1,
      "name": "list_directory",
      "args": {
        "path": ""
      }
    },
    {
      "turn": 1,
      "name": "execute_command",
      "args": {
        "command": "find . -maxdepth 1 -type f | head -30"
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "src"
      }
    },
    {
      "turn": 2,
      "name": "list_directory",
      "args": {
        "path": "assemblies"
      }
    },
    {
      "turn": 2,
      "name": "execute_command",
      "args": {
        "command": "find . -maxdepth 2 -type d | sort"
      }
    },
    {
      "turn": 3,
      "name": "execute_command",
      "args": {
        "command": "dir /s /b /ad src 2>nul | findstr /v \"\\\\obj\\\\ \\\\bin\\\\ \\\\.vs\\\\\""
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/backend"
      }
    },
    {
      "turn": 3,
      "name": "list_directory",
      "args": {
        "path": "src/centron"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/apis"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/nexus"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/shared"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "src/webservice"
      }
    },
    {
      "turn": 4,
      "name": "list_directory",
      "args": {
        "path": "docs"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.BL"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Entities"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.DAO"
      }
    },
    {
      "turn": 5,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Common"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Interfaces"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "src/backend/Centron.Gateway"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "src/centron/Centron.WPF.UI"
      }
    },
    {
      "turn": 6,
      "name": "list_directory",
      "args": {
        "path": "src/shared/Centron.Core"
      }
    },
    {
      "turn": 6,
      "name": "read_file",
      "args": {
        "path": "README.md"
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/backend/Centron.BL/Sales und src/backend/Centron.BL/Accounting und src/backend/Centron.BL/Finances. Liste alle .cs-Dateien auf, lies die wichtigsten Klassen und Methoden. Fasse zusammen: Welche Geschäftsanforderungen (Verkauf, Buchhaltung, Finanzbuchhaltung, Fakturierung, Zahlungsverkehr) werden implementiert? Welche Berechtigungsprüfungen gibt es? Welche Statusübergänge/Workflow-Logik existiert? Welche Berechnungen werden durchgeführt? Nenne konkrete Dateipfade, Klassen und Methoden."
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Verzeichnis src/backend/Centron.BL/Security und src/backend/Centron.Common/Users und src/backend/Centron.BL/TwoFactorAuthenticator und src/backend/Centron.BL/PasswordManagementArea und src/backend/Centron.BL/PasswordManager. Liste alle .cs-Dateien auf, lies die wichtigsten Klassen und Methoden. Fasse zusammen: Welche Sicherheitsanforderungen, Authentifizierung, Autorisierung, Passwort-Richtlinien und 2FA-Mechanismen werden implementiert? Welche Berechtigungsprüfungen gibt es konkret? Nenne konkrete Dateipfade, Klassen und Methoden mit den jeweiligen Prüfbedingungen."
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere die API-Integrationen in src/apis. Gehe durch alle Unterverzeichnisse: Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud, Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAccess, Centron.APIs.FinAPI, Centron.APIs.IcecatDataAccess, Centron.APIs.ITscopeDataAccess. Liste alle .cs-Dateien auf und lies die wichtigsten Klassen. Fasse zusammen: Welche externen Schnittstellen werden angebunden? Welche Daten werden ausgetauscht? Welche Authentifizierung erfolgt? Nenne konkrete Dateipfade und Klassen."
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere das Gateway src/backend/Centron.Gateway. Gehe durch alle Unterverzeichnisse: Concerto, Core, DataExchange, EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa, Export, Import, MspCollector, OnlineBanking, OpenTrans, OpenTrans1_0, Portal, ZUGFeRD21_Extended. Liste alle .cs-Dateien auf und lies die wichtigsten Klassen. Fasse zusammen: Welche EDI-Schnittstellen existieren? Welche Datenformate werden verarbeitet? Welche Import/Export-Logik gibt es? Was macht ZUGFeRD? Nenne konkrete Dateipfade und Klassen."
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere die Webservice-Komponenten in src/webservice. Gehe durch alle Unterverzeichnisse: c-entron.misc.ConnectionManager, Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.WindowsService, Centron.WebServices.Core. Liste alle .cs-Dateien auf und lies die wichtigsten Klassen. Fasse zusammen: Welche Web-API-Endpunkte werden angeboten? Wie ist die Service-Architektur aufgebaut? Welche Hosting-Optionen gibt es? Welche Authentifizierung wird verwendet? Nenne konkrete Dateipfade und Klassen."
      }
    },
    {
      "turn": 7,
      "name": "spawn_subagent",
      "args": {
        "subagent_type": "explore",
        "description": "Analysiere src/backend/Centron.BL/Purchasing, src/backend/Centron.BL/Buying, src/backend/Centron.BL/Logistics, src/backend/Centron.BL/Warehousing und src/backend/Centron.BL/Production. Liste alle .cs-Dateien auf und lies die wichtigsten Klassen und Methoden. Fasse zusammen: Welche Anforderungsbereiche (Einkauf, Bestellwesen, Lagerverwaltung, Logistik, Produktion) werden implementiert? Welche Geschäftsprozesse gibt es? Welche Berechtigungsprüfungen existieren? Nenne konkrete Dateipfade, Klassen und Methoden."
      }
    }
  ],
  "tool_call_count": 28,
  "tool_call_types": {
    "list_directory": 18,
    "execute_command": 3,
    "read_file": 1,
    "spawn_subagent": 6
  },
  "written_files": [],
  "result": "Ich habe einen guten Überblick über die Top-Level-Struktur. Jetzt werde ich Subagenten starten, um verschiedene Bereiche parallel zu analysieren, während ich selbst die Kernbereiche erkunde.",
  "finish_reason": "tool_calls",
  "errors": [
    "Turn 8: API-Fehler: API-Fehler 429: {\"error\": {\"message\": \"Rate limit exceeded. Please slow down and retry.\", \"type\": \"rate_limit_error\", \"param\": null, \"code\": \"429\"}}"
  ],
  "session_id": "",
  "adapter": "python-glm-kimi",
  "adapter_version": "1.1.0",
  "mode": "builtin",
  "subagent_stats": {
    "spawned": 6,
    "completed": 4,
    "failed": 2,
    "by_type": {
      "explore": 6
    }
  },
  "subagent_details": [
    {
      "id": 1,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.BL/Sales und src/backend/Centron.BL/Accounting und src/backend/Centron.BL/Finances. Liste alle .cs-Dateien auf, lies die wichtigsten Klassen und Methoden",
      "turns": 12,
      "tool_calls": 34,
      "tokens": 806518,
      "status": "completed"
    },
    {
      "id": 2,
      "type": "explore",
      "description": "Analysiere das Verzeichnis src/backend/Centron.BL/Security und src/backend/Centron.Common/Users und src/backend/Centron.BL/TwoFactorAuthenticator und src/backend/Centron.BL/PasswordManagementArea und ",
      "turns": 9,
      "tool_calls": 29,
      "tokens": 226410,
      "status": "completed"
    },
    {
      "id": 3,
      "type": "explore",
      "description": "Analysiere die API-Integrationen in src/apis. Gehe durch alle Unterverzeichnisse: Centron.Api.EbInterface, Centron.Api.Gls, Centron.Api.Shipcloud, Centron.APIs.CopDataAccess, Centron.APIs.EgisDataAcce",
      "turns": 1,
      "tool_calls": 0,
      "tokens": 0,
      "status": "failed"
    },
    {
      "id": 4,
      "type": "explore",
      "description": "Analysiere das Gateway src/backend/Centron.Gateway. Gehe durch alle Unterverzeichnisse: Concerto, Core, DataExchange, EDI_Alltron, EDI_Also, EDI_AlsoCH, EDI_EGIS, EDI_Herweck, EDI_Komsa, Export, Impor",
      "turns": 4,
      "tool_calls": 37,
      "tokens": 6790,
      "status": "completed"
    },
    {
      "id": 5,
      "type": "explore",
      "description": "Analysiere die Webservice-Komponenten in src/webservice. Gehe durch alle Unterverzeichnisse: c-entron.misc.ConnectionManager, Centron.Controllers, Centron.Host, Centron.Host.Console, Centron.Host.Wind",
      "turns": 1,
      "tool_calls": 0,
      "tokens": 0,
      "status": "failed"
    },
    {
      "id": 6,
      "type": "explore",
      "description": "Analysiere src/backend/Centron.BL/Purchasing, src/backend/Centron.BL/Buying, src/backend/Centron.BL/Logistics, src/backend/Centron.BL/Warehousing und src/backend/Centron.BL/Production. Liste alle .cs-",
      "turns": 4,
      "tool_calls": 23,
      "tokens": 4669,
      "status": "completed"
    }
  ],
  "start_time": "2026-08-28T09:24:29.126467+00:00",
  "end_time": "2026-08-28T09:29:00.569976+00:00"
 }
@@ -0,0 +1,19 @@
 [glm-kimi-adapter] API-Key aus Cline providers.json gelesen.
 [glm-kimi-adapter] Start: 2026-08-28T09:24:29.126467+00:00
 [glm-kimi-adapter] Provider: TensorX API Gateway
 [glm-kimi-adapter] Modell: z-ai/glm-5.2
 [glm-kimi-adapter] Effort: high
 [glm-kimi-adapter] Mode: builtin
 [glm-kimi-adapter] Subagent 1 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 2 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 3 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 4 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 5 gestartet (Typ: explore)
 [glm-kimi-adapter] Subagent 6 gestartet (Typ: explore)
 [glm-kimi-adapter] Ende: 2026-08-28T09:29:00.569976+00:00
 [glm-kimi-adapter] Turns: 8
 [glm-kimi-adapter] Tokens gesamt: 1,096,464
 [glm-kimi-adapter] Tool-Calls: 28
 [glm-kimi-adapter] Subagenten: 6 (completed: 4, failed: 2)
 [glm-kimi-adapter] Ergebnisdateien: 0
 [glm-kimi-adapter] RawResult: c:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 7\z-ai\glm-5.2\builtin\high\03_Lauf_2026-08-28_111655_v8.0.0-4047\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,179 @@
 # Versuch 01 - Baseline (Prompt-only) - Iteration 03
 ## Metadaten
 - **Versuch:** V1 Baseline (Prompt-only)
 - **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
 - **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
 - **Zeitstempel:** 2026-08-28
 - **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
 - **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
  | Änderung | Auslösender Befund |
  |---|---|
 ---
 ## Prompt
 Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
 ### Auftrag
 Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
 1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
 2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
 3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
 Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
 ### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
 Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
 **Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
 ### Vorgehen (statische Analyse, keine Ausführung)
 Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
 **Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
 **Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
 **Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
 2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
 3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
 4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
 5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
 6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
 ### Pflicht-Eigenschaften jeder Anforderung
 - **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
 - **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
 - **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
 - **Belegklassifikation:** Kennzeichne jeden Beleg als
  - `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
  - `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
  - `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
 - **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
 - **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
 - **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
 - **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
 - **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
 ### Formatvorgabe pro Anforderung
 ```
 ID:            <StRS|SyRS|SwRS>-<laufende Nummer>
 Titel:         <kurzer Titel>
 Ebene:         <StRS | SyRS | SwRS>
 Typ:           <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
 Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
 Akteur:        <Rolle / System / Komponente>
 Vorbedingung:  <Zustand vor Auslösen>
 Fakt:          <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
 Aussage:       Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
 Ergebnis:      <erwartetes Ergebnis / Nachbedingung>
 Belege:
  - [PRIMÄR]   <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
  - [SEKUNDÄR] <...> - Begründung: <...>
  - [KONTEXT]  <...> - Begründung: <...>
 Prüfidee:      <Akzeptanzkriterium oder Testidee>
 Tracelinks:    <verwandte StRS-/SyRS-/SwRS-IDs>
 Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
 Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
 Status:        <belegt | HYPOTHESE>
 ```
 ### Traceability
 Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
 - Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
 - Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
 - Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
 ### Nicht-funktionale Anforderungen
 - Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
 - Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
 ### Konsolidierungsbedarf
 Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
 **Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
 ### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
 ```text
 Ergebnisse/
  StRS.md
  SyRS.md
  SwRS.md
  Traceability.md   (oder Traceability.csv)
  Hypothesen.md     (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
  Glossar.md        (Domänenbegriffe, die in den Anforderungen verwendet werden)
  Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
                     Selbstbewertung, bekannte Lücken)
 ```
 **Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
 Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
 ### Randbedingungen
 - **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
 - **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
 - **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
 - **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
 - **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
 ### Abschluss
 Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
 - Doppelte oder mehrfach vergebene IDs
 - Anforderungen ohne Beleg
 - Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
 - Tracelinks auf nicht existierende IDs
 - Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
 - **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
 - **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
 Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
 Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
 - Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
 - Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
 - An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
 - Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
 - Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
  | Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
  | Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
  Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
 > Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
 > bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
 > stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
 ### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
 Fuer diesen Lauf stehen zur Verfuegung: Lesen, Suchen und Ausfuehren von Kommandozeilenbefehlen im Arbeitsverzeichnis, sowie Schreiben von Ergebnisdateien in das Ausgabeverzeichnis.
 Zusaetzlich: spawn_subagent zum Starten von Subagenten mit eigenem Kontext fuer isolierte Teilaufgaben.
 Nicht verfuegbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver.
 Triff keine Annahmen ueber weitere Werkzeuge und versuche nicht, nicht verfuegbare Werkzeuge zu ersetzen.
 Verfuegbare Werkzeuge:
 - read_file: Liest den Inhalt einer Datei (relativer Pfad zum Arbeitsverzeichnis)
 - list_directory: Listet Verzeichnisinhalte auf
 - search_files: Durchsucht Dateien mit Regex (aehnlich grep -rn)
 - execute_command: Fuehrt schreibgeschuetzte Shell-Befehle aus (schreibende/bauende Kommandos werden abgelehnt)
 - write_file: Schreibt eine Ergebnisdatei ins Ausgabeverzeichnis
 - spawn_subagent: Startet einen Subagenten mit eigenem Kontext fuer eine isolierte Teilaufgabe (Read-Only)
 ### Ausgabeverzeichnis (ueberschreibt anderslautende Pfadangaben oben)
 Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
 $lauf\Ergebnisse\.
 Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
@@ -0,0 +1 @@
 2026-08-28T11:29:00.5955290+02:00
@@ -0,0 +1,9 @@
 {
  "modell": "z-ai/glm-5.2",
  "iteration": "Iteration 7",
  "promptHash": "B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07",
  "promptVersion": "03",
  "modus": "builtin",
  "effort": "high",
  "skillVersion": "v8.0.0"
 }
@@ -0,0 +1 @@
 2026-08-28T11:16:55.8317841+02:00
--- a/Show More
+++ b/Show More
		`@@ -0,0 +1,4 @@`
							`## Gefundene Anforderungen`

							`Keine Anforderungen im vorgegebenen Format gefunden.`