Compare commits
6
Commits
ea1f3caff7
...
654339464e
| Author | SHA1 | Date | |
|---|---|---|---|
 Christoph Schwörer
|
654339464e | ||
|
Christoph SchwörerandClaude Opus 5
|
611fd0a80c | ||
|
Christoph Schwörer
|
b369e6115e | ||
|
Christoph Schwörer
|
ca52aa4701 | ||
|
Christoph Schwörer
|
8a22d586f1 | ||
|
Christoph Schwörer
|
37275c96d6 |
@@ -1,8 +1,8 @@
|
||||
---
|
||||
name: run-experiment
|
||||
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code oder Codex CLI aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
||||
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code, Codex CLI oder OpenCode (TensorX oder lokales LM Studio) aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
||||
argument-hint: <Pfad zur Prompt-Datei> <Root-Verzeichnis>
|
||||
version: 7.0.0
|
||||
version: 12.0.0
|
||||
---
|
||||
|
||||
# RunExperiment – Versuchslauf mit Messprotokoll
|
||||
@@ -101,7 +101,8 @@ Der Skill ist zweigeteilt:
|
||||
- **`## Prozess`** beschreibt werkzeugneutral, **was** je Lauf zu tun und zu erheben ist. Dieser
|
||||
Teil gilt unabhängig davon, mit welchem LLM oder welcher CLI gearbeitet wird.
|
||||
- **`## Werkzeugadapter`** beschreibt **wie** das mit einem konkreten Werkzeug umgesetzt wird.
|
||||
Ausgearbeitet sind Adapter für Claude Code und Codex CLI. Konkrete Flags und Rohfelder sind
|
||||
Ausgearbeitet sind Adapter für Claude Code, Codex CLI und OpenCode über TensorX. Der frühere
|
||||
direkte Python-API-Adapter bleibt nur als ausdrücklich gewählter Legacy-Fallback erhalten. Konkrete Flags und Rohfelder sind
|
||||
ausschließlich dem gewählten Adapterabschnitt zu entnehmen.
|
||||
|
||||
**Arbeitsteilung mit der Prompt-Datei:** Der Prompt enthält ausschließlich die *Analyseanweisung*
|
||||
@@ -124,9 +125,16 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
frühere Läufe entstanden sind, und dürfen nicht nachträglich angepasst werden.
|
||||
2. Aus dem Metadaten-Block der Prompt-Datei (falls vorhanden) Versuch/Prompt-Version übernehmen.
|
||||
3. **Werkzeugadapter bestimmen und CLI-Pfad auflösen.** Die Modell-ID entscheidet eindeutig:
|
||||
`claude-*` verwendet Claude Code, OpenAI-IDs wie `gpt-*` oder `o*` verwenden Codex CLI.
|
||||
`claude-*` verwendet Claude Code, OpenAI-IDs wie `gpt-*` oder `o*` verwenden Codex CLI,
|
||||
`z-ai/*`, `qwen/qwen3.8-flash-next` und `moonshotai/*` verwenden OpenCode mit
|
||||
`--provider tensorx`, `google/gemma-4-e4b` und `qwen/qwen3.8-27b` verwenden OpenCode mit
|
||||
`--provider lmstudio` gegen den lokalen LM-Studio-Server.
|
||||
Keine Modell-ID an eine CLI übergeben, die sie nicht unterstützt.
|
||||
|
||||
**Achtung Präfixkollision:** `qwen/qwen3.8-flash-next` läuft remote über TensorX,
|
||||
`qwen/qwen3.8-27b` lokal über LM Studio. Das Präfix `qwen/` allein entscheidet **nicht** –
|
||||
maßgeblich ist die vollständige Modell-ID.
|
||||
|
||||
Unter Windows liegt `claude` in der Regel **nicht im PATH**. Erst
|
||||
`Get-Command claude -ErrorAction SilentlyContinue` versuchen; schlägt das fehl, auf die
|
||||
VSCode-Extension zurückfallen und die höchste Versionsnummer wählen:
|
||||
@@ -142,6 +150,12 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
`$env:USERPROFILE\.vscode\extensions\openai.chatgpt-*-win32-x64\bin\windows-x86_64\codex.exe`
|
||||
wählen. Findet sich die benötigte ausführbare Datei nicht: abbrechen und den User informieren.
|
||||
Adapter und aufgelösten Pfad fürs Protokoll festhalten.
|
||||
|
||||
Für TensorX-Modelle `Get-Command opencode -ErrorAction SilentlyContinue` versuchen. Der
|
||||
Adapter löst zusätzlich die globale npm-Installation unter
|
||||
`$env:APPDATA\npm\node_modules\opencode-ai\bin\opencode.exe` auf. Fehlt OpenCode, mit
|
||||
`npm install -g opencode-ai` installieren; fehlt die TensorX-Anmeldung, `opencode auth login`
|
||||
ausführen. Niemals dafür Cline-Konfigurationsdateien oder Cline-Credentials lesen.
|
||||
4. **Modell beim User erfragen.** Hat der User das Modell nicht bereits im Aufruf genannt,
|
||||
**immer** per `AskUserQuestion` nachfragen – auch dann, wenn frühere Läufe derselben
|
||||
Versuchsreihe ein bestimmtes Modell verwendet haben. Es gibt bewusst keinen Default.
|
||||
@@ -162,6 +176,23 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
| `gpt-5.6-terra` | ausgewogenes Verhältnis aus Leistung und Verbrauch |
|
||||
| `gpt-5.6-luna` | schnelle und günstige GPT-5.6-Variante |
|
||||
|
||||
| TensorX-Modell-ID | Einordnung |
|
||||
|---|---|
|
||||
| `z-ai/glm-5.2` | Z.AI GLM 5.2 über TensorX-Gateway |
|
||||
| `z-ai/glm-5.3-flash` | Z.AI GLM 5.3 Flash über TensorX-Gateway |
|
||||
| `qwen/qwen3.8-flash-next` | Qwen 3.8 Flash Next über TensorX-Gateway |
|
||||
| `moonshotai/kimi-k3` | Moonshot Kimi K3 – 1-Mio.-Kontext, 2,8T Parameter |
|
||||
|
||||
| Lokale Modell-ID (LM Studio) | Einordnung |
|
||||
|---|---|
|
||||
| `google/gemma-4-e4b` | Gemma 4 E4B, 7,5B Parameter, lokal über LM Studio |
|
||||
| `qwen/qwen3.8-27b` | Qwen 3.8 27B, lokal über LM Studio |
|
||||
|
||||
Lokale IDs nur anbieten, wenn `lms ls` das Modell als heruntergeladen ausweist. Fehlt es,
|
||||
den User auf `lms get <ID>` hinweisen und den Download **nicht** ungefragt starten – es
|
||||
sind mehrere Gigabyte. Lokale Läufe sind eine eigene Versuchsbedingung und nicht mit
|
||||
Cloud-Läufen poolbar: anderes Kontextfenster, quantisierte Gewichte, kein Effort.
|
||||
|
||||
In der Frage den letzten verwendeten Stand nennen, damit der User bewusst wechseln oder
|
||||
bewusst wiederholen kann (z. B. „Lauf 3 lief mit `claude-sonnet-5`, 11.516.200 Tokens, 23:40").
|
||||
|
||||
@@ -217,6 +248,30 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
unangetastet und die Agentenkonfiguration ist eine dokumentierte, versionierte
|
||||
Versuchsbedingung. Format siehe `claude --help` zu `--agents`.
|
||||
|
||||
**Delegationstiefe – nur Modus `custom`, beim User erfragen.** Zwei Fassungen der
|
||||
Agentendatei stehen bereit; sie unterscheiden sich ausschließlich darin, ob die Rollen selbst
|
||||
delegieren dürfen:
|
||||
|
||||
| Fassung | Rollen dürfen delegieren | Wirkung |
|
||||
|---|---|---|
|
||||
| `verschachtelt` | ja | Rollen erben über `--agents` alle Werkzeuge einschließlich `Task` und starten eigene Subagenten. `max_depth` > 1. |
|
||||
| `unverschachtelt` | nein | Jede Rolle führt ihren Auftrag selbst aus. Nur der Hauptagent delegiert; `max_depth` soll 1 sein. |
|
||||
|
||||
**Warum das eine eigene Option ist.** Im ersten V2-Lauf (`v9.1.0-0c39`) entfielen 26 von
|
||||
86 Subagenten auf Starts durch Subagenten, `max_depth` = 3. Das war nicht beabsichtigt – der
|
||||
`iso29148-orchestrator` ist ausdrücklich als nicht-delegierende Rolle entworfen – und es
|
||||
verteuert den Lauf erheblich, weil jede zusätzliche Ebene ihren Kontext erneut liest. Es
|
||||
verwischt außerdem die Zuständigkeit: Ein von einer Rolle gestarteter Subagent ist keiner
|
||||
Teilaufgabe der Bindungstabelle mehr zuzuordnen.
|
||||
|
||||
Die Fassung ist **nicht** technisch erzwungen, sondern in jedem Rollenprompt als Abschnitt
|
||||
*Keine Weiterdelegation* formuliert. Kontrolle nach dem Lauf: `subagent_stats.max_depth` und
|
||||
`spawned_by_subagents`. Beide gehen ins Protokoll; bei `unverschachtelt` und
|
||||
`spawned_by_subagents` > 0 ist die Bedingung verletzt und im Protokoll zu kennzeichnen.
|
||||
|
||||
Beide Fassungen liegen neben der Prompt-Datei und werden per SHA-256 geführt; die gewählte
|
||||
Fassung ist über ihren Hash eindeutig belegt.
|
||||
|
||||
**Codex-Adapter ab Version 5.0.0:** ausschließlich `solo` ist freigegeben und wird doppelt
|
||||
mit `--disable multi_agent` sowie `-c agents.enabled=false` erzwungen. Bei `builtin` oder
|
||||
`custom` abbrechen und mitteilen, dass dieser Adaptermodus noch nicht verifiziert ist. Eine
|
||||
@@ -256,7 +311,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
Sort-Object { [int]($_.Name -replace '\D','') }
|
||||
$iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' }
|
||||
$zelle = Join-Path (Join-Path (Join-Path $iteration $modell) $modus) $effort
|
||||
$skillVer = 'v7.0.0' # entspricht version: im Frontmatter dieses Skills
|
||||
$skillVer = 'v10.0.2' # entspricht version: im Frontmatter dieses Skills
|
||||
do {
|
||||
$id4 = '{0:x4}' -f (Get-Random -Maximum 65536)
|
||||
$lauf = Join-Path "<promptverzeichnis>\$zelle" "<NN>_Lauf_$(Get-Date -Format 'yyyy-MM-dd_HHmmss')_${skillVer}-$id4"
|
||||
@@ -338,6 +393,50 @@ Der Inhalt richtet sich nach dem Agentenmodus:
|
||||
| `builtin` | zusätzlich die werkzeugeigenen Subagenten | spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver |
|
||||
| `custom` | zusätzlich die beigestellten Agentenrollen (namentlich nennen) | externe Werkzeugserver, sofern nicht Teil des Versuchs |
|
||||
|
||||
**Zuständigkeitsbindung – nur Modus `custom`.** Der Prompt verlangt im Abschnitt
|
||||
*Arbeitsteilung*, dass eine Teilaufgabe von dem dafür vorgesehenen Bearbeiter ausgeführt wird,
|
||||
nennt aber bewusst keine Rolle – sonst wäre er nicht mehr für `solo` und `builtin` gültig. Welche
|
||||
Rolle wofür zuständig ist, gehört deshalb in den Werkzeugkontext. Block 1 wird bei `custom` um
|
||||
folgende Tabelle ergänzt, mit den Rollennamen aus der `--agents`-Datei:
|
||||
|
||||
```
|
||||
Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
|
||||
Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
|
||||
|
||||
| Teilaufgabe | Vorgesehener Bearbeiter |
|
||||
|---|---|
|
||||
| Modulinventar (Schritt 0) | modulinventar |
|
||||
| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
|
||||
| Formulierung der StRS-Anforderungen | strs-autor |
|
||||
| Formulierung der SyRS-Anforderungen | syrs-autor |
|
||||
| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
|
||||
| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
|
||||
| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
|
||||
| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
|
||||
|
||||
Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
|
||||
entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
|
||||
lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
|
||||
bleiben deine Aufgabe.
|
||||
```
|
||||
|
||||
Die Tabelle wird aus der `--agents`-Datei abgeleitet und **nicht** freihändig formuliert: Jede
|
||||
Zeile nennt eine Rolle, die dort definiert ist, und jede definierte Rolle kommt vor. Kommt eine
|
||||
Rolle in der Datei vor, aber nicht in der Tabelle, ist sie im Lauf faktisch nicht vorgesehen –
|
||||
das ist zulässig, aber im Protokoll zu vermerken.
|
||||
|
||||
**Warum die Bindung keine Strategieinjektion ist.** Sie ist vor dem Lauf statisch deklariert,
|
||||
wird als Teil von `_meta\combined_prompt.md` archiviert und ist über den SHA-256 der
|
||||
`--agents`-Datei versioniert. Damit unterscheidet sie sich grundlegend von den in Version 9.0.0
|
||||
entfernten **laufzeitabhängigen** Eingriffen des TensorX-Adapters (Subagenten-Limit,
|
||||
turnabhängige Schreib-Erinnerungen), die den Lauf abhängig von seinem eigenen Verlauf umsteuerten
|
||||
und Lauf 34 unpoolbar machten. Was in `custom` weiterhin **nicht** vorgegeben wird: Anzahl der
|
||||
Aufrufe, Zerlegungstiefe, Reihenfolge und Turn-Anzahl.
|
||||
|
||||
**Die Bindung ist nicht technisch erzwungen.** Sie wirkt über den Prompt; ob der Agent sie
|
||||
einhält, ist selbst eine Messgröße. Nach dem Lauf ist sie zu prüfen – siehe Protokollfeld
|
||||
*Zuständigkeitsbindung*.
|
||||
|
||||
**Block 2 – Ausgabeverzeichnis.** Damit die Ergebnisse im Laufverzeichnis landen und nicht in
|
||||
der Codebasis:
|
||||
|
||||
@@ -365,8 +464,8 @@ und unter `content` den vollständigen Dateiinhalt. `summary` enthält nur eine
|
||||
### 3. Ausführung (Headless-Lauf)
|
||||
|
||||
Den Adapter anhand der Modell-ID wählen. Der folgende Aufruf ist **ausschließlich der
|
||||
Claude-Code-Adapter**. Der Codex-Aufruf steht vollständig unter `Adapter: Codex CLI` und darf
|
||||
nicht mit Claude-Flags vermischt werden.
|
||||
Claude-Code-Adapter**. Der Codex-Aufruf steht vollständig unter `Adapter: Codex CLI`, der
|
||||
TensorX-Aufruf unter `Adapter: OpenCode`; beide dürfen nicht mit Claude-Flags vermischt werden.
|
||||
|
||||
Den kombinierten Prompt per stdin an `claude -p` übergeben. `--add-dir` gibt dem
|
||||
Headless-Lauf Schreibrecht auf das Laufverzeichnis außerhalb seines Arbeitsverzeichnisses.
|
||||
@@ -526,7 +625,9 @@ Regeln:
|
||||
|
||||
`RawResult.json` im Laufverzeichnis lesen und defensiv parsen. Beim Claude-Adapter ist dies die
|
||||
unveränderte CLI-Antwort; beim Codex-Adapter erzeugt `normalise-codex-result.py` diese Datei aus
|
||||
`RawEvents.jsonl` und `_meta\final_response.json`. Relevante Claude-Felder:
|
||||
`RawEvents.jsonl` und `_meta\final_response.json`; beim OpenCode-Adapter erzeugt
|
||||
`opencode-adapter.py` sie aus dem Sessionexport und `OpenCodeEvents.jsonl` gemäß der
|
||||
OpenCode-Referenz. Relevante Claude-Felder:
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
@@ -766,6 +867,15 @@ Vorlage:
|
||||
- **MCP-Server / Agentendateien:** <keine – aus dem Snapshot entfernt, zusätzlich --safe-mode |
|
||||
Liste der Server mit Pfad und SHA-256 der `--mcp-config`-Datei; Pfad und SHA-256 der
|
||||
`--agents`-Datei>
|
||||
- **Delegationstiefe (nur `custom`):** <verschachtelt | unverschachtelt> gemäß gewählter
|
||||
Agentendatei. Kontrolle: `subagent_stats.max_depth` und `spawned_by_subagents`. Bei
|
||||
`unverschachtelt` muss `spawned_by_subagents` = 0 und `max_depth` = 1 sein; andernfalls hat
|
||||
die Rollenvorgabe nicht gegriffen und der Lauf ist entsprechend zu kennzeichnen.
|
||||
- **Zuständigkeitsbindung (nur `custom`):** je Rolle die Zahl der Aufrufe aus
|
||||
`subagent_stats.by_type`; Rollen mit null Aufrufen namentlich nennen. Dazu der Abgleich mit
|
||||
der Dokumentationspflicht aus dem `Analysebericht.md`: Welche Teilaufgabe hat der Hauptagent
|
||||
entgegen der Bindung selbst ausgeführt, und hat er das dort offengelegt? Eine nicht
|
||||
offengelegte Abweichung ist im Protokoll als solche zu kennzeichnen.
|
||||
- **Umgebungsprüfung (nur `custom` / MCP):** <keine Hooks, Plugins, Output-Styles im
|
||||
User-Profil vorgefunden | **abweichend**: welche>
|
||||
- **Subagenten:** <Anzahl und Typ aus `subagent_stats`, z. B. 8 × Explore, 0 fehlgeschlagen>
|
||||
@@ -997,10 +1107,197 @@ die angeforderte ID; da `codex exec --json` sie im Ereignisstrom nicht wiederhol
|
||||
Modellkontrolle im Protokoll `nicht prüfbar`. Temperatur und weitere Sampling-Parameter sind in
|
||||
diesem CLI-Ablauf nicht steuerbar; Effort und Service-Tier werden dagegen explizit festgelegt.
|
||||
|
||||
### Adapter: OpenCode / TensorX-Modelle und lokale LM-Studio-Modelle
|
||||
|
||||
Dies ist der **primäre Adapter für alle TensorX-Modell-IDs und für den lokalen
|
||||
LM-Studio-Betrieb**. Beide nutzen OpenCodes OpenAI-kompatiblen Custom Provider und dasselbe
|
||||
Skript `opencode-adapter.py`; `--provider` wählt Gateway und Modellvorlage. OpenCode verwaltet
|
||||
Authentifizierung, Agenten-Loop und Session; der Wrapper erzeugt eine isolierte Konfiguration,
|
||||
streamt die Rohereignisse, erzwingt Berechtigungen und normalisiert das Ergebnis nach
|
||||
`RawResult.json`. Es besteht keine Abhängigkeit zu Cline.
|
||||
|
||||
| `--provider` | Modell-IDs | Betrieb | Vorlage |
|
||||
|---|---|---|---|
|
||||
| `tensorx` (Standard) | `z-ai/*`, `qwen/qwen3.8-flash-next`, `moonshotai/*` | Remote `https://api.tensorx.ai/v1` | `opencode-tensorx.json` |
|
||||
| `lmstudio` | `google/gemma-4-e4b`, `qwen/qwen3.8-27b` | lokal `http://localhost:1234/v1` | `opencode-lmstudio.json` |
|
||||
|
||||
Vor jedem Lauf die vollständige Referenz
|
||||
[`references/opencode-adapter.md`](references/opencode-adapter.md) lesen und deren Aufruf,
|
||||
Timeouts, Artefakte und Pflichtprüfungen anwenden. API-Keys gehören ausschließlich in OpenCodes
|
||||
Credential-Store; die Vorlagen enthalten keine.
|
||||
|
||||
**Lokaler Betrieb ist eine eigene Versuchsbedingung.** Ein Preflight prüft Server,
|
||||
Modellverfügbarkeit, Tool-Fähigkeit, geladenes Kontextfenster (`--min-context`, Standard 32768)
|
||||
und dass genau eine Modellinstanz geladen ist; er bricht sonst mit Exitcode `2` und dem exakt
|
||||
nötigen `lms`-Befehl ab. `RawResult.json` führt zusätzlich `local_runtime` (Quantisierung,
|
||||
Architektur, Runtime, `lms`-Version, Kontextfenster) und `context_window` – damit sind die von
|
||||
Kap. 4.3 geforderten Angaben für lokalen Betrieb erfasst. **Effort ist bei `lmstudio` nicht
|
||||
steuerbar** (`effort_applied: false`) und im Protokoll so auszuweisen; Kosten sind
|
||||
definitionsgemäß `0`, Cache-Metriken `nicht erfasst`. Lokale Läufe niemals mit Cloud-Läufen
|
||||
poolen.
|
||||
|
||||
Referenzstand bei Einführung: **OpenCode 1.18.25**. Ein Live-Smoke-Test mit
|
||||
`qwen/qwen3.8-flash-next`, Variante `low`, bestätigte Headless-Ausführung, Sessionexport,
|
||||
Reasoning-/Cache-Metriken und die erwartete Textantwort. Für LM Studio bestätigte ein
|
||||
Smoke-Test mit `google/gemma-4-e4b` (Q4_K_M, gguf, 32768 Kontexttokens) Preflight,
|
||||
Providerauflösung, Streaming und Tool-Calling.
|
||||
|
||||
**Terminierung kleiner lokaler Modelle.** Im Smoke-Test lief `google/gemma-4-e4b` über 50
|
||||
Schritte weiter, ohne die geforderte Datei zu schreiben. Da laufend Text erzeugt wird, greift
|
||||
der Stall-Timeout nicht. Lokale Läufe deshalb immer mit absolutem `--max-runtime` starten und
|
||||
einen Abbruch als Abbruch protokollieren, nicht als Ergebnis.
|
||||
|
||||
### Legacy-Adapter: direkte Python API / GLM-, Qwen- und Kimi-Modelle über TensorX
|
||||
|
||||
Dieser frühere Adapter darf nur verwendet werden, wenn der User ihn ausdrücklich verlangt oder
|
||||
OpenCode nach dokumentierter Diagnose technisch nicht einsetzbar ist. Die Abweichung ist im
|
||||
Messprotokoll festzuhalten; Läufe beider Adapter sind verschiedene Versuchsbedingungen.
|
||||
|
||||
Der Legacy-Adapter wurde für Modelle entwickelt, die über den **TensorX API-Gateway**
|
||||
(`https://api.tensorx.ai/v1`) erreichbar sind. Er nutzt das Skript `glm-kimi-adapter.py`,
|
||||
das einen minimalen Agent-Loop mit Tool-Calling direkt gegen die OpenAI-kompatible
|
||||
REST-API implementiert. Referenzstand bei Einführung: **Python 3.13, requests 2.34**.
|
||||
|
||||
**Verfügbare Modell-IDs über TensorX:**
|
||||
|
||||
| TensorX-Modell-ID | Hersteller | Effort-Parameter |
|
||||
|---|---|---|
|
||||
| `z-ai/glm-5.2` | Z.AI (Zhipu AI) | `thinking` (`{"type":"enabled","level":"…"}`) |
|
||||
| `z-ai/glm-5.3-flash` | Z.AI (Zhipu AI) | `thinking` (`{"type":"enabled","level":"…"}`) |
|
||||
| `qwen/qwen3.8-flash-next` | Alibaba Qwen | `thinking` (`{"type":"enabled","level":"…"}`) |
|
||||
| `moonshotai/kimi-k3` | Moonshot AI | `reasoning_effort` (top-level) |
|
||||
|
||||
Das Modell-Präfix (`z-ai/`, `qwen/` bzw. `moonshotai/`) bestimmt, welcher Effort-Parameter an die
|
||||
API gesendet wird. Der Adapter wählt ihn automatisch anhand des Präfixes.
|
||||
|
||||
**Authentifizierung.** Der API-Key wird **automatisch aus der Cline providers.json**
|
||||
gelesen (`~/.cline/data/settings/providers.json`, Provider `tensorx`). Alternativ kann
|
||||
er per `--api-key` oder Umgebungsvariable `TENSORX_API_KEY` übergeben werden. Der Key
|
||||
wird **nicht** in Laufartefakten gespeichert.
|
||||
|
||||
**Unterstützte Agentenmodi:** `solo` (V1), `builtin` (V1b) und `custom` (V2). Der Modus wird per
|
||||
`--mode solo|builtin|custom` 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. Anzahl und Typen bestimmt allein
|
||||
das Modell; der Adapter setzt weder ein Anzahl- noch standardmäßig ein Turn-Limit. Fordert
|
||||
das Modell in einer Antwort mehrere Subagenten an, laufen sie tatsächlich parallel. Der
|
||||
Subagent-Typ (`explore` oder `general-purpose`) bestimmt den System-Prompt. Subagent-Token
|
||||
fließen vollständig in `usage` und `modelUsage` ein. Im Modus `custom` werden die Rollen mit
|
||||
`--agents <JSON-Datei>` geladen und über dasselbe `spawn_subagent`-Werkzeug bereitgestellt.
|
||||
|
||||
**Lebenszeichen.** Der Adapter schreibt standardmäßig alle 60 Sekunden eine
|
||||
`LIFESIGN`-Zeile nach `Stderr.log`. Sie nennt die aktiven Operationen des Hauptagenten und
|
||||
jedes Subagenten, beispielsweise einen API-Turn, einen Tool-Aufruf oder das Warten auf eine
|
||||
parallele Subagentengruppe. Das Intervall ist mit `--heartbeat-interval` steuerbar. Ein
|
||||
Lebenszeichen während eines nicht gestreamten HTTP-Aufrufs beweist nur, dass der lokale
|
||||
Adapterprozess lebt und auf TensorX wartet; es ist kein Nachweis, dass serverseitig weiterhin
|
||||
Tokens erzeugt werden.
|
||||
|
||||
**Keine impliziten Abbrüche.** `--timeout 0`, `--max-turns 0` und
|
||||
`--subagent-max-turns 0` bedeuten tatsächlich unbegrenzt. Der Adapter injiziert keine
|
||||
laufzeit- oder limitbedingten Schreibaufforderungen. Damit bleibt es Teil der Messung, ob,
|
||||
wie und mit wie vielen Subagenten ein Modell zum Abschluss kommt.
|
||||
|
||||
**Isolation.** Der Adapter ist ein eigenständiges Python-Skript, das nur die
|
||||
Python-Standardbibliothek und `requests` benötigt. Es liest die Codebasis über die
|
||||
implementierten Tools (`read_file`, `list_directory`, `search_files`,
|
||||
`execute_command`) und schreibt Ergebnisdateien ausschließlich über das `write_file`-Tool
|
||||
ins Ausgabeverzeichnis. Schreibende und bauende Shell-Kommandos sind durch eine
|
||||
Denylist gesperrt (analog zum Claude-Code-Adapter). Der bereinigte Snapshot bleibt
|
||||
zusätzliche Pflicht.
|
||||
|
||||
**Effort-Steuerung.** Der Adapter mappt die Skill-Effort-Stufen auf beide APIs:
|
||||
|
||||
| Skill-Effort | GLM `thinking.level` | Qwen `thinking.level` | Kimi `reasoning_effort` |
|
||||
|---|---|---|---|
|
||||
| `low` | `low` | `low` | `low` |
|
||||
| `medium` | `medium` | `medium` | `medium` |
|
||||
| `high` | `high` | `high` | `high` |
|
||||
| `xhigh` | `xhigh` | `xhigh` | `high` (höchste verfügbare Stufe) |
|
||||
| `max` | `xhigh` | `xhigh` | `high` |
|
||||
|
||||
**Der Aufruf** (als Background-Task starten):
|
||||
|
||||
```powershell
|
||||
$skillDir = "<Verzeichnis des Skills>"
|
||||
$lauf = "<absoluter Pfad zum Laufverzeichnis>"
|
||||
$root = "<Root-Verzeichnis der Codebasis>"
|
||||
$modell = "<vom User gewählte Modell-ID, z.B. z-ai/glm-5.2>"
|
||||
$effort = "<vom User gewählte Stufe>"
|
||||
$modus = "<solo|builtin|custom>"
|
||||
$agents = "<Agenten-JSON; im Modus custom erforderlich>"
|
||||
|
||||
# Prompt zusammenstellen (wie bei den anderen Adaptern)
|
||||
$prompt = (Get-Content "<prompt-datei>" -Raw) + "`n`n<Werkzeugkontext-Block>`n`n<Ausgabe-Block>"
|
||||
Set-Content -Path "$lauf\_meta\combined_prompt.md" -Value $prompt -Encoding utf8
|
||||
Set-Content -Path "$lauf\_meta\startzeit.txt" -Value (Get-Date -Format o)
|
||||
|
||||
# API-Key wird automatisch aus Cline providers.json gelesen
|
||||
python "$skillDir\glm-kimi-adapter.py" `
|
||||
--prompt "$lauf\_meta\combined_prompt.md" `
|
||||
--root $root `
|
||||
--output "$lauf\Ergebnisse" `
|
||||
--model $modell `
|
||||
--effort $effort `
|
||||
--mode $modus `
|
||||
--agents $agents `
|
||||
--max-turns 0 `
|
||||
--subagent-max-turns 0 `
|
||||
--timeout 0 `
|
||||
--heartbeat-interval 60 `
|
||||
--result-dir $lauf `
|
||||
2> "$lauf\Stderr.log"
|
||||
|
||||
Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
|
||||
```
|
||||
|
||||
**Gelieferte Messgrößen** – vollständig aus `RawResult.json` (vom Adapter geschrieben):
|
||||
|
||||
| Messgröße | Feld |
|
||||
|---|---|
|
||||
| Abbruchstatus | `is_error`, `subtype`, `finish_reason` |
|
||||
| Dauer | `duration_ms` (Wanduhr, selbst gemessen; keine separate API-Zeit) |
|
||||
| Tokens gesamt | `usage.total_tokens` über alle Turns akkumuliert |
|
||||
| Input-Tokens | `usage.prompt_tokens` |
|
||||
| Output-Tokens | `usage.completion_tokens` |
|
||||
| Reasoning-Tokens | `usage.reasoning_tokens` (aus `completion_tokens_details.reasoning_tokens`) |
|
||||
| Cache-Read-Tokens | `usage.cached_tokens` (soweit von TensorX geliefert) |
|
||||
| Cache-Write-Tokens | **nicht erfasst** – TensorX liefert keine |
|
||||
| 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 in den Modi `builtin` und `custom` |
|
||||
| Subagenten-Details | `subagent_details` (je Subagent: Typ, Beschreibung, Turns, Tokens, Status) |
|
||||
| Erzeugte Artefakte | `written_files` (Pfad und Größe je Datei) |
|
||||
| Abschlusstext | `result` |
|
||||
| Lebenszeichen | periodische `LIFESIGN`-Zeilen in `Stderr.log` |
|
||||
|
||||
**Semantik der Token-Zählung.** `usage.total_tokens` wird über alle Turns aufsummiert.
|
||||
Jeder Turn umfasst dabei den vollen Kontext (Eingabe + Ausgabe); die Token-Zahl ist
|
||||
daher die Summe aller API-Aufrufe, nicht die eines einzelnen Austauschs.
|
||||
Reasoning-Tokens sind eine Teilmenge von `completion_tokens` und werden nicht erneut
|
||||
addiert.
|
||||
|
||||
**Nicht erfasst und niemals schätzen:** Cache-Write-Tokens, Permission-Denials (das
|
||||
Deny-Modell ist ein hartes Blockieren, keine zählbaren Denials), Subagenten-Stats (keine
|
||||
Subagenten), Session-ID (keine persistierte Session), API-Dauer (nicht von der API
|
||||
geliefert). Sampling-Parameter: Temperatur ist steuerbar (`--temperature`),
|
||||
Reasoning-Effort ist steuerbar (`--effort`).
|
||||
|
||||
**Pflichtprüfung nach dem Lauf:**
|
||||
1. `Ergebnisse\` ist **nicht leer** – sonst Fehlmessung (analog zu MAJOR 6.1.0).
|
||||
2. `Stderr.log` enthält keine Abbruchmeldung.
|
||||
3. `model` in `RawResult.json` stimmt mit `model_requested` überein (Modellkontrolle).
|
||||
4. `tool_call_count` > 0 (ein Lauf ohne Tool-Aufrufe hat die Codebasis nicht analysiert).
|
||||
|
||||
|
||||
### Weitere Adapter (für Versuch 4 nachzurüsten)
|
||||
|
||||
Kapitel 4 der Arbeit sieht zusätzlich Qwen Code CLI über LM Studio und DeepSeek über die
|
||||
Cloud-API vor. Diese Adapter sind noch nicht ausgearbeitet. Damit ein
|
||||
Kapitel 4 der Arbeit sieht zusätzlich DeepSeek über die Cloud-API vor; dieser Adapter ist noch
|
||||
nicht ausgearbeitet. Der lokale LM-Studio-Betrieb ist seit 10.1.0 über
|
||||
`opencode-adapter.py --provider lmstudio` abgedeckt – allerdings mit OpenCode als Agenten-Loop
|
||||
statt der in Kap. 4 genannten Qwen Code CLI. Diese Abweichung gehört ins Protokoll. Damit ein
|
||||
Lauf als Messpunkt taugt, muss ein Adapter mindestens liefern:
|
||||
|
||||
| Pflichtangabe | Zweck |
|
||||
@@ -1057,6 +1354,19 @@ der Historie unten – im selben Arbeitsschritt.
|
||||
|
||||
| Version | Änderung | Grund | Verwendet in |
|
||||
|---|---|---|---|
|
||||
| **12.0.0** | **Die Shell-Rechte des OpenCode-Adapters werden eine Denylist statt einer Allowlist** – spiegelbildlich zu den Claude-Eintraegen: alles erlaubt ausser den ausdruecklich gesperrten schreibenden und bauenden Kommandos (`rm`, `mv`, `sed -i`, schreibende `git`-Kommandos inkl. `fetch`/`pull`/`remote`, `dotnet`, `msbuild`, `npm install`, `Remove-Item`, `Set-Content`, `Out-File` u. a.). Das Catch-all `"*": "allow"` steht zuerst, weil OpenCode die **zuletzt passende** Regel gewinnen laesst. Zusaetzlich lehnt der Adapter `--stall-timeout > 0` jetzt fuer **jeden** lokalen Provider ab, nicht nur fuer die delegierenden Modi. Adapter-Version 2.0.0, vier neue Regressionstests. | Der Claude-Adapter erlaubt ueber eine Denylist jedes nicht gesperrte Kommando, der OpenCode-Adapter nur explizit Gelistetes. Die Werkzeugfreiheit war zwischen beiden **nie aequivalent** – ein Confounder fuer jeden Werkzeugvergleich. Ausloeser war der erste Qwen-Lauf (`v11.1.0-45b1`): Dessen **einzige beide** Werkzeugaufrufe, `Get-ChildItem ... | Format-Table ...`, wurden verweigert, weil die Allowlist nur Praefixe trifft und an Pipelines scheitert. Bei Gemma war das ein Randfall (1 von 106 Aufrufen), bei Qwen legte es den Lauf still. Der zweite Ausloeser: Qwen 27B benoetigte fuer einen einzelnen Schritt mehr als 15 Minuten, sodass der Stall-Timeout auch in `solo` Modellgeschwindigkeit als Haenger wertete. **Kontrolltest am 01.09.2026 bestaetigte beide Richtungen:** `Get-ChildItem ... | Format-Table Name` lief durch, `rm opfer.txt` wurde verweigert, und die Datei blieb auf der Platte. MAJOR: Die Toolfreigabe ist eine unabhaengige Variable; Laeufe ab dieser Version sind mit allen frueheren OpenCode- und TensorX-Laeufen nicht poolbar. | ab dem naechsten OpenCode-Lauf; Iterationen 10 und 11 bleiben unter der Allowlist |
|
||||
| **11.1.0** | **Der Adapter lehnt `--stall-timeout > 0` in den Modi `builtin` und `custom` ab.** Die Laufzeit wird dort ausschliesslich ueber `--max-runtime` begrenzt. Adapter-Version 1.3.0; Referenz und Aufrufbeschreibung entsprechend ergaenzt. | Der erste `builtin`-Lauf mit LM Studio (`v11.0.0-9ad0`) wurde nach 15:48 min abgebrochen, obwohl das Limit bei 60 min lag. Ursache war nicht das Modell: OpenCode sendet **keine Ereignisse, solange ein Subagent arbeitet**. Nach 8 Ereignissen in den ersten 39 Sekunden schwieg der Strom, waehrend der gestartete `explore`-Subagent lief; der Stall-Timeout deutete das als Haenger. Jeder Lauf mit Subagenten waere so zuverlaessig zu frueh gestorben. Die Kombination wird abgelehnt statt stillschweigend korrigiert, damit die Entscheidung bewusst faellt. MINOR: Es existierte noch **kein** gueltiger OpenCode-Lauf in `builtin` oder `custom`, dessen Bedingung sich dadurch aendern koennte; die `solo`-Laeufe waren nie betroffen, weil bei ihnen der Stall-Timeout nie griff. **Zu pruefen:** ob die als Fehler protokollierten TensorX-V2-Laeufe (Modus `custom`, `--stall-timeout 600`) dieselbe Ursache haben. | ab dem naechsten OpenCode-Lauf in `builtin` oder `custom` |
|
||||
| **11.0.0** | **Read-only-Shell-Allowlist des OpenCode-Adapters erweitert.** Neben `rg` und den lesenden `git`-Kommandos sind jetzt die verbreiteten POSIX-Werkzeuge `ls`, `cat`, `head`, `tail`, `find`, `grep`, `wc`, `file`, `stat`, `tree` sowie `dir`, `type`, `Get-Item` und `Measure-Object` freigegeben; `git log` und `git show` kommen hinzu. Alles Übrige bleibt `deny`. Zwei Regressionstests sichern die Liste ab: Sie muss die lesenden Kommandos enthalten und darf kein schreibendes enthalten. Adapter-Version 1.2.0. | Der erste LM-Studio-Lauf (`v10.1.0-b00a`, Gemma/solo) erzeugte zwei Permission-Denials auf `ls src` – das Kommando fehlte auf der Allowlist. Der Agent hatte damit kein POSIX-Mittel, Verzeichnisse aufzulisten, obwohl genau das laut Werkzeugkontext zur Bedingung gehört. Die Lücke benachteiligte OpenCode-Läufe gegenüber den Claude-Läufen, die mit einer Denylist arbeiten und deshalb jedes nicht ausdrücklich gesperrte Lesekommando erlauben. **MAJOR: Die Toolfreigabe ist eine unabhängige Variable.** Läufe ab dieser Version sind mit den bisherigen OpenCode- und TensorX-Läufen nicht poolbar; der nächste Lauf eröffnet eine neue Iteration. | ab dem nächsten OpenCode-Lauf; Iteration 10 bleibt unter der alten Allowlist |
|
||||
| **10.1.0** | **Lokaler LM-Studio-Adapter für `google/gemma-4-e4b` und `qwen/qwen3.8-27b`.** `opencode-tensorx-adapter.py` heißt jetzt `opencode-adapter.py` und wählt über `--provider {tensorx,lmstudio}` Gateway und Modellvorlage; die Referenz heißt entsprechend `references/opencode-adapter.md`. Neue keyfreie Vorlage `opencode-lmstudio.json` (`http://localhost:1234/v1`). Ein Preflight über `/api/v0/models` prüft Servererreichbarkeit, Modellverfügbarkeit, `tool_use`-Fähigkeit, geladenes Kontextfenster (`--min-context`, Standard 32768) und dass genau **eine** Modellinstanz geladen ist; `--lmstudio-autoload` stellt den Sollzustand per `lms unload`/`lms load` selbst her. Das geladene Fenster wird als `limit.context` in die Laufkonfiguration gepinnt. `RawResult.json` erhält `local_runtime` (Quantisierung, Architektur, Runtime, `lms`-Version, Instanzbezeichner, Kontextfenster), `context_window`, `cost_source` und providerübergreifend `effort_applied`. Neue Artefaktdatei `_meta/lmstudio-modelle.json`. Adapter-Version 1.1.0, fünf zusätzliche Unit-Tests. Zwei Korrekturen am gemeinsamen Pfad: Der Abbruchgrund wird nur noch einmal in `errors` vermerkt statt je Sekunde bis zum Prozessende, und die `lms`-Version wird aus dem ANSI-Banner der CLI sauber extrahiert. | Kapitel 4 sieht lokalen Betrieb als eigene Bedingung vor und fordert nach Kap. 4.3 Runtime samt Version und Quantisierungsstufe – beides liefert erst der Preflight. Drei Befunde aus der Inbetriebnahme sind direkt in den Adapter eingeflossen: LM Studio lädt Modelle standardmäßig mit nur 8192 Kontexttokens, was eine Codebasisanalyse stillschweigend abschneiden würde; ein erneutes `lms load` erzeugt eine **zweite** Instanz (`modell:2`), womit die `model`-Angabe der OpenAI-API nicht mehr eindeutig routet; und der lokale Endpunkt nimmt keinen Thinking-Level entgegen, weshalb Effort als nicht steuerbar auszuweisen ist statt als gesetzt. MINOR: neuer Provider und neue Messgrößen; für `--provider tensorx` bleiben Aufruf, Berechtigungen und Metriken unverändert – die vier bestehenden TensorX-Regressionstests laufen unverändert durch, sodass laufende V2-Läufe vergleichbar bleiben. Live-Smoke-Test am 31.08.2026 mit `google/gemma-4-e4b` (Q4_K_M, gguf, 32768 Tokens): Preflight bestanden, Providerauflösung, Streaming und Tool-Calling bestätigt. | ab dem ersten LM-Studio-Lauf |
|
||||
| **10.0.2** | Ergebnis-Allowlist zusätzlich relativ zur per Git ermittelten Worktree-Wurzel; Adapter-Version 1.0.2. | Der erste Fix deckte den aktiven Root und den kanonischen Pfad ab. OpenCode 1.18.25 matcht ein Ziel innerhalb desselben Repositories jedoch gegen den Pfad relativ zur Worktree-Wurzel. PATCH: weitere Normalisierungsform desselben bereits autorisierten Zielverzeichnisses. | ab dem ersten OpenCode-V2-Lauf |
|
||||
| **10.0.1** | Der OpenCode-Adapter autorisiert Ergebnisziele zusätzlich mit einem zum aktiven Root relativen Pfad, einschließlich notwendiger `..`-Segmente; Adapter-Version 1.0.1. Regressionstest für Root und Laufverzeichnis in verschiedenen Unterordnern desselben Windows-Git-Worktrees. | OpenCode normalisiert solche Ziele intern worktree-relativ. Die alleinige kanonische Allow-Regel griff daher nicht, obwohl der absolute Werkzeugpfad exakt im erlaubten Ergebnisordner lag. Ein Custom/max-Preflight startete den vorgesehenen Subagenten erfolgreich, konnte anschließend aber keine Ergebnisdatei schreiben. PATCH: korrigiert nur die beabsichtigte Schreibfreigabe. | ab dem ersten OpenCode-V2-Lauf |
|
||||
| **10.0.0** | **OpenCode wird primärer TensorX-Adapter.** Neue keyfreie Provider-/Modellvorlage `opencode-tensorx.json`, Wrapper `opencode-tensorx-adapter.py`, Unit-Tests und Detailreferenz. Der Wrapper startet `opencode run --pure` mit einer isolierten Laufkonfiguration, streamt JSONL und stderr, exportiert die Session, normalisiert Token-, Tool- und Subagentenmetriken und beendet bei Inaktivität oder Benutzerabbruch den Prozessbaum. `solo`, `builtin` und aus `03_Agents.json` übersetztes `custom` werden unterstützt. Der direkte Python-Adapter bleibt als ausdrücklich gewählter Legacy-Fallback erhalten. | Der direkte Adapter hing bei `qwen/qwen3.8-flash-next` in einem nicht gestreamten HTTP-Aufruf ohne lokalisierbaren Fortschritt. OpenCode liefert inkrementelle Ereignisse, eine persistierte Session und einen klaren Prozesslebenszyklus; außerdem entfällt die Kopplung der TensorX-Authentifizierung an Cline. MAJOR, weil Agentenlaufzeit, Werkzeugsemantik und Metrikquelle eine neue Versuchsbedingung bilden. Live-Smoke-Test am 31.08.2026 mit Qwen/low: Exitcode 0, erwartete Antwort, Sessionexport und vollständige Tokenfelder. | ab dem nächsten TensorX-Lauf; vorherige direkte Python-Läufe bleiben Legacy-Bedingung |
|
||||
| **9.3.0** | **TensorX-Modellkatalog für Versuch 2 erweitert:** `qwen/qwen3.8-flash-next` und `z-ai/glm-5.3-flash`; Qwen erhält explizit das `thinking.level`-Effort-Mapping. Der TensorX-Aufruf dokumentiert nun `--agents`. Im Adapter stellt `custom` wie `builtin` das Werkzeug `spawn_subagent` bereit; Adapter-Version 2.1.0. | Beide IDs wurden am 31.08.2026 über `GET /v1/models` des konfigurierten TensorX-Gateways bestätigt. Ein Qwen-Smoke-Test bestätigte `thinking`, Reasoning-Tokens und Tool-Calling. Bei der Konfigurationsprüfung fiel außerdem auf, dass `custom` trotz geladener Rollen das Delegationswerkzeug ausblendete und der dokumentierte Aufruf die Agentendatei nicht übergab; damit wäre Versuch 2 über TensorX ohne spezialisierte Rollen gelaufen. MINOR für die Modellauswahl, funktionale Korrektur für V2. | ab dem ersten TensorX-Lauf in Versuch 2 |
|
||||
| **9.2.0** | **Delegationstiefe als Option im Modus `custom`.** Zwei gehashte Fassungen der Agentendatei: `verschachtelt` (Rollen dürfen selbst delegieren, bisheriges Verhalten) und `unverschachtelt` (Abschnitt *Keine Weiterdelegation* in jedem Rollenprompt). Die Fassung wird wie Modell, Modus und Effort vor dem Lauf beim User erfragt. Neues Protokollfeld *Delegationstiefe* mit Kontrolle über `subagent_stats.max_depth` und `spawned_by_subagents`. | Im ersten V2-Lauf (`v9.1.0-0c39`) entfielen 26 von 86 Subagenten auf Starts durch Subagenten (`max_depth` = 3). Das war nicht beabsichtigt – der `iso29148-orchestrator` ist als nicht-delegierende Rolle entworfen – und ist ein erheblicher Kostentreiber: Jede zusätzliche Ebene liest ihren Kontext erneut, und Cache-Reads stellten 46 % der Laufkosten. Es verwischt zudem die Zuständigkeit, weil ein von einer Rolle gestarteter Subagent keiner Teilaufgabe der Bindungstabelle mehr zuzuordnen ist. MINOR: neue Option und neue Messgröße; die Bedingung bestehender Läufe ändert sich nicht, sie gelten rückwirkend als `verschachtelt`. | ab dem zweiten V2-Lauf |
|
||||
| **9.1.0** | **Zuständigkeitsbindung im Modus `custom`.** Block 1 (Werkzeugkontext) wird bei `custom` um eine Tabelle `Teilaufgabe → vorgesehener Bearbeiter` ergänzt, abgeleitet aus der `--agents`-Datei. Der Prompt formuliert die Bindung abstrakt und nennt weiterhin keine Rolle, damit dieselbe Prompt-Datei für `solo` und `builtin` gültig bleibt. Neues Protokollfeld *Zuständigkeitsbindung*: Aufrufe je Rolle aus `subagent_stats.by_type`, Rollen mit null Aufrufen namentlich, Abgleich gegen die Dokumentationspflicht im `Analysebericht.md`. | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Im Smoke-Test vom 26.08. nutzte der Agent von acht beigestellten Rollen nur zwei (`modulinventar`, `konsistenzpruefer`) — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist statisch deklariert, in `_meta\combined_prompt.md` archiviert und über den SHA-256 der `--agents`-Datei versioniert; sie unterscheidet sich damit von den in 9.0.0 entfernten laufzeitabhängigen Adaptereingriffen. Anzahl der Aufrufe, Zerlegungstiefe, Reihenfolge und Turn-Anzahl bleiben unvorgegeben. MINOR, weil bislang **kein** Lauf im Modus `custom` existiert und deshalb keine Läufe unpoolbar werden; der erste V2-Lauf eröffnet ohnehin eine neue Iteration. | ab dem ersten V2-Lauf |
|
||||
| **9.0.0** | **Freie und tatsächlich parallele Subagenten-Orchestrierung im Python-Adapter.** Das künstliche 10er-Limit, die limitbedingte Zwangsnachricht und die laufzeitabhängigen Schreib-Erinnerungen entfallen. Mehrere `spawn_subagent`-Aufrufe desselben Turns werden parallel ausgeführt; Haupt- und Subagenten haben standardmäßig kein Turnlimit. `--timeout 0` bedeutet nun wirklich keinen HTTP-Timeout. Ein threadsicherer Heartbeat protokolliert alle 60 Sekunden den lokalen Zustand von Haupt- und Subagenten. API-Fehler setzen unabhängig von vorhandenem Freitext `is_error: true`, werden nach `Stderr.log` geschrieben und führen zu Exitcode 1. | Das 10er-Limit und die serielle Abarbeitung veränderten gerade die zu untersuchende autonome Delegationsstrategie des Modells. Außerdem wurden fünf Kimi-Timeouts wegen fehlerhafter Statuslogik als Erfolg klassifiziert. MAJOR, weil Subagentenfreiheit, Parallelität und Abbruchsemantik die Versuchsbedingung ändern; der nächste Lauf eröffnet eine neue Iteration. | ab dem nächsten TensorX-Lauf |
|
||||
| **8.0.0** | **Neuer Python-API-Adapter für GLM- und Kimi-Modelle über den TensorX-Gateway.** Das Skript `glm-kimi-adapter.py` implementiert einen minimalen Agent-Loop mit Tool-Calling (read_file, list_directory, search_files, execute_command, write_file) direkt gegen die OpenAI-kompatible TensorX-API (`https://api.tensorx.ai/v1`). Modelle: `z-ai/glm-5.2` und `moonshotai/kimi-k3`. Der API-Key wird automatisch aus der Cline providers.json gelesen. Token-Verbrauch wird pro Turn aus dem API-Response `usage`-Objekt akkumuliert, inkl. Reasoning-Tokens (`completion_tokens_details.reasoning_tokens`). Effort-Mapping anhand des Modell-Präfixes: `z-ai/*` nutzt `thinking.level`, `moonshotai/*` nutzt `reasoning_effort`. Nur Modus `solo` freigegeben. Neue Modell-Tabelle für TensorX-Modell-IDs im Vorbereitungsabschnitt. | Die Cline CLI (`npm i -g cline`) versprach einen Headless-Modus mit GLM-Support, ihr natives Binary (143 MB, Bun-kompiliert) wurde jedoch durch die Application-Control-Richtlinie der Maschine blockiert (EPERM/Zugriff verweigert). Der Python-Adapter umgeht dieses Problem und bietet zusätzliche Vorteile: exakte Token-Metriken direkt aus der API (inkl. Reasoning-Tokens, die Claude Code nur als `thinking_tokens` liefert), keine externen Binary-Abhängigkeiten, API-Key aus bestehender Cline-Konfiguration. MAJOR, da neues Werkzeug mit anderer Isolationsarchitektur und anderen Metrik-Quellen eine neue Versuchsbedingung bildet; der nächste Lauf eröffnet eine neue Iteration. | ab dem ersten GLM/Kimi-Lauf |
|
||||
|
||||
| **7.0.0** | **Isolationsmechanismus wird modusabhängig.** In den Modi `solo` und `builtin` unverändert `--safe-mode`; im Modus `custom` und bei jedem Lauf mit `--mcp-config` **kein** `--safe-mode`, stattdessen `--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`. Neue Pflicht-Umgebungsprüfung auf Hooks, Plugins und Output-Styles im User-Profil; neue Protokollfelder für die MCP-Konfiguration und die Umgebungsprüfung. | `--safe-mode` schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and agents" ab – also genau das, was V2 und V3 untersuchen. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur `--safe-mode` variiert): mit Flag `spawned` = 0 und die Meldung, die Rollen seien „nicht in der Agent-Registry registriert"; ohne Flag `spawned` = 2 mit `{"modulinventar": 1, "konsistenzpruefer": 1}`. Ohne Ersatz hätte der erste V2-Lauf stillschweigend als V1-Lauf gemessen. Der Ersatz wurde gegengeprüft: nichts vorgeladen, keine Skills, kein Webzugriff, alle Rollen verfügbar. **MAJOR: Läufe im Modus `custom` sind hinsichtlich der Isolation nicht unmittelbar mit `solo`- und `builtin`-Läufen vergleichbar** – Plugins, Hooks und Output-Styles sind dort nicht durch das Flag, sondern nur durch die Umgebungsprüfung ausgeschlossen. | ab dem ersten V2-Lauf |
|
||||
| **6.1.0** | Zwei adapterunabhängige Pflichtprüfungen nach jedem Lauf: **(a)** `Ergebnisse\` darf nicht leer sein – sonst Fehlmessung, unabhängig von `is_error`; **(b)** `Stderr.log` auf Abbruchmeldungen prüfen. Der Ausführungsabschnitt setzt `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`. Neues Protokollfeld „Gültigkeit". Dokumentiert, dass die Rückgabe eines Hintergrund-Subagenten eine Start-Quittung ist und ihre Länge kein Ertragsmaß. | Lauf `…160037_v4.5.0-116d` meldete `is_error: false`, `subtype: success` und lieferte **null Ergebnisdateien** bei 193,4 Mio. Tokens – der Headless-Modus hatte nach 600 s abgebrochen, während zehn Hintergrund-Subagenten noch liefen. Ohne die neue Prüfung wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in den Modellvergleich eingegangen. MINOR: neue Prüfschritte; die Umgebungsvariable ändert die Versuchsbedingung für künftige `builtin`-Läufe und ist dort zu vermerken. | ab sofort |
|
||||
| **6.0.0** | **Windows-taugliche Codex-Isolation.** Pro Lauf wird im System-Temp-Verzeichnis außerhalb des IDE-Projektbaums eine Kopie der versionierten und nicht ignorierten Dateien des Codebasis-Roots erstellt. Codex läuft ausschließlich dort mit `--sandbox workspace-write`; SHA-256-Manifeste vor und nach dem Lauf erkennen jede Änderung. Ergebnisse und Nachweise bleiben im Laufverzeichnis, die temporäre Kopie wird danach entfernt. | Der erste Codex-Lauf mit 5.0.0 konnte fachlich nicht starten, weil die Windows-Read-only-Sandbox sämtliche lesenden Kindprozesse vor dem Start blockierte. Eine Kopie im Laufverzeichnis wurde zudem vom C#-Projektservice automatisch mit ignorierten `obj`-Dateien verändert. MAJOR, weil Sandboxmodus und Arbeitsverzeichnis eine neue Versuchsbedingung bilden; der erste Lauf eröffnet deshalb eine neue Iteration. | ab dem ersten wiederholten Codex-Lauf |
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,84 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "TensorX",
|
||||
"options": {
|
||||
"baseURL": "https://api.tensorx.ai/v1"
|
||||
},
|
||||
"models": {
|
||||
"qwen/qwen3.8-flash-next": {
|
||||
"name": "Qwen 3.8 Flash Next",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "low"
|
||||
}
|
||||
},
|
||||
"medium": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "medium"
|
||||
}
|
||||
},
|
||||
"high": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "high"
|
||||
}
|
||||
},
|
||||
"xhigh": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
},
|
||||
"max": {
|
||||
"thinking": {
|
||||
"type": "enabled",
|
||||
"level": "xhigh"
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.2": {
|
||||
"name": "GLM 5.2",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
},
|
||||
"variants": {
|
||||
"low": { "thinking": { "type": "enabled", "level": "low" } },
|
||||
"medium": { "thinking": { "type": "enabled", "level": "medium" } },
|
||||
"high": { "thinking": { "type": "enabled", "level": "high" } },
|
||||
"xhigh": { "thinking": { "type": "enabled", "level": "xhigh" } },
|
||||
"max": { "thinking": { "type": "enabled", "level": "xhigh" } }
|
||||
}
|
||||
},
|
||||
"z-ai/glm-5.3-flash": {
|
||||
"name": "GLM 5.3 Flash",
|
||||
"variants": {
|
||||
"low": { "thinking": { "type": "enabled", "level": "low" } },
|
||||
"medium": { "thinking": { "type": "enabled", "level": "medium" } },
|
||||
"high": { "thinking": { "type": "enabled", "level": "high" } },
|
||||
"xhigh": { "thinking": { "type": "enabled", "level": "xhigh" } },
|
||||
"max": { "thinking": { "type": "enabled", "level": "xhigh" } }
|
||||
}
|
||||
},
|
||||
"moonshotai/kimi-k3": {
|
||||
"name": "Kimi K3",
|
||||
"limit": {
|
||||
"context": 1048576,
|
||||
"output": 131072
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,305 @@
|
||||
# OpenCode-Adapter
|
||||
|
||||
Ein Wrapper, zwei Provider. `opencode-adapter.py` startet OpenCode headless und normalisiert den
|
||||
Lauf nach `RawResult.json`. Welcher Provider gilt, entscheidet `--provider`:
|
||||
|
||||
| `--provider` | Modell-IDs | Betrieb | Vorlage |
|
||||
|---|---|---|---|
|
||||
| `tensorx` (Standard) | `z-ai/*`, `qwen/qwen3.8-flash-next`, `moonshotai/*` | Remote-Gateway `https://api.tensorx.ai/v1` | `opencode-tensorx.json` |
|
||||
| `lmstudio` | `google/gemma-4-e4b`, `qwen/qwen3.8-27b` | lokaler LM-Studio-Server `http://localhost:1234/v1` | `opencode-lmstudio.json` |
|
||||
|
||||
`qwen/qwen3.8-flash-next` (TensorX) und `qwen/qwen3.8-27b` (lokal) teilen sich das Präfix `qwen/`.
|
||||
Das Präfix allein bestimmt den Adapter deshalb **nicht** – maßgeblich ist die vollständige
|
||||
Modell-ID gemäß dieser Tabelle.
|
||||
|
||||
Der Abschnitt **LM Studio** unten beschreibt alles, was nur für den lokalen Betrieb gilt.
|
||||
Alle übrigen Abschnitte gelten für beide Provider.
|
||||
|
||||
## Voraussetzungen und Authentifizierung
|
||||
|
||||
1. OpenCode installieren und die Version protokollieren:
|
||||
|
||||
```powershell
|
||||
npm install -g opencode-ai
|
||||
opencode --version
|
||||
```
|
||||
|
||||
2. Nur für `--provider tensorx`: TensorX einmal im OpenCode-Credential-Store anmelden
|
||||
(`--provider lmstudio` braucht keine Anmeldung – der lokale Server prüft keinen Key):
|
||||
|
||||
```powershell
|
||||
opencode auth login
|
||||
opencode auth list
|
||||
```
|
||||
|
||||
Die statische Datei `opencode-tensorx.json` enthält Provider, Basis-URL, Modelle und
|
||||
Effort-Varianten, aber keinen API-Key. Der Adapter liest weder Cline-Dateien noch einen
|
||||
Cline-Credential-Store. OpenCode löst das Credential selbst auf. Keys niemals in
|
||||
Laufartefakte, Prompts oder die Konfigurationsvorlage schreiben.
|
||||
|
||||
## Modell- und Effort-Mapping
|
||||
|
||||
Der Adapter ergänzt intern das Providerpräfix (`tensorx/` bzw. `lmstudio/`). Aus
|
||||
`qwen/qwen3.8-flash-next` wird daher für OpenCode
|
||||
`tensorx/qwen/qwen3.8-flash-next`; im Messprotokoll bleibt die ursprüngliche TensorX-ID.
|
||||
|
||||
Die Stufen `low`, `medium`, `high`, `xhigh` und `max` werden als OpenCode-Varianten aus der
|
||||
Providervorlage übergeben. Für Qwen und GLM über TensorX enthält die Variante
|
||||
`thinking: {type: enabled, level: ...}`; `max` wird auf `xhigh` abgebildet, falls der Provider
|
||||
keine eigene `max`-Stufe kennt. Nur in der Vorlage vorhandene Varianten werden per
|
||||
`--variant` gesetzt.
|
||||
|
||||
**Bei `lmstudio` ist Effort nicht steuerbar.** Der OpenAI-kompatible Endpunkt von LM Studio
|
||||
nimmt keinen Thinking-Level entgegen; `opencode-lmstudio.json` deklariert deshalb bewusst keine
|
||||
Varianten. Der Adapter protokolliert das im `Adapter.log` und setzt `effort_applied: false` in
|
||||
`RawResult.json`. Der übergebene `--effort`-Wert bleibt als angeforderte Bedingung erhalten, ist
|
||||
im Protokoll aber unter „Sampling-Parameter" als **nicht steuerbar** auszuweisen – niemals so
|
||||
darzustellen, als hätte er gewirkt. Reasoning-Tokens liefern die Modelle trotzdem, sofern sie
|
||||
von sich aus mit `reasoning_content` antworten.
|
||||
|
||||
## Isolierte Laufkonfiguration
|
||||
|
||||
Für jeden Lauf schreibt der Adapter `_meta/opencode-config.json` und setzt nur für den
|
||||
Kindprozess `OPENCODE_CONFIG` auf diese Datei. Der Aufruf verwendet `opencode run --pure`,
|
||||
damit keine interaktive Oberfläche benötigt wird. Der Prompt wird über stdin übergeben.
|
||||
|
||||
Die Berechtigungen beginnen mit `deny` und erlauben gezielt:
|
||||
|
||||
- Lesen, Suchen, Auflisten sowie eine Read-only-Shell-Allowlist;
|
||||
- Schreiben und externe Verzeichnisse ausschließlich für das angegebene Ergebnisverzeichnis;
|
||||
- im Modus `solo` keine Tasks;
|
||||
- im Modus `builtin` nur OpenCodes `general`- und `explore`-Subagenten;
|
||||
- im Modus `custom` nur Rollen aus der mit `--agents` übergebenen JSON-Datei.
|
||||
|
||||
Für das Ergebnisziel erzeugt der Wrapper kanonische sowie zum aktiven OpenCode-Root und zur
|
||||
Git-Worktree-Wurzel relative Allow-Patterns. Das ist unter Windows notwendig, wenn Root und
|
||||
Laufverzeichnis im selben Git-Worktree liegen, das Laufverzeichnis aber außerhalb des
|
||||
Root-Unterordners liegt.
|
||||
|
||||
Die Shell-Rechte sind seit Skill 12.0.0 eine **Denylist**, spiegelbildlich zum
|
||||
Claude-Code-Adapter: Erlaubt ist alles, gesperrt sind ausdrücklich die schreibenden und
|
||||
bauenden Kommandos – `rm`, `rmdir`, `mv`, `cp`, `dd`, `truncate`, `chmod`, `chown`, `ln`,
|
||||
`tee`, `sed -i`, die schreibenden `git`-Kommandos einschließlich `fetch`, `pull` und `remote`,
|
||||
`dotnet`, `msbuild`, `npm install`, `nuget` sowie `Remove-Item`, `Move-Item`, `Copy-Item`,
|
||||
`New-Item`, `Set-Content`, `Add-Content`, `Clear-Content`, `Out-File`, `Set-ItemProperty` und
|
||||
`Rename-Item`.
|
||||
|
||||
**Die Reihenfolge ist bedeutsam.** OpenCode wertet die Regeln der Reihe nach aus; die *zuletzt
|
||||
passende* Regel gewinnt – nicht die spezifischste, und `deny` gewinnt nicht automatisch. Das
|
||||
Catch-all `"*": "allow"` muss deshalb **zuerst** stehen, die Sperren danach. Python-Dicts
|
||||
erhalten ihre Einfügereihenfolge, `json.dump` schreibt sie unverändert.
|
||||
|
||||
Die frühere Allowlist konnte Kommandos nur als Präfix treffen und scheiterte deshalb an
|
||||
Pipelines: `Get-ChildItem ... | Format-Table ...` blieb gesperrt, obwohl `Get-ChildItem`
|
||||
erlaubt war. Zugleich war die Werkzeugfreiheit nicht mit der des Claude-Adapters vergleichbar.
|
||||
|
||||
Wie beim Claude-Adapter gilt: Mustervergleich auf Kommandozeilen ist **nicht lückenlos**. Die
|
||||
belastbare Read-only-Garantie bleibt der Vorher/Nachher-Vergleich per `git status`; die
|
||||
Denylist senkt das Risiko, sie ersetzt die Verifikation nicht.
|
||||
|
||||
Webzugriff, Skills, Rückfragen und Weiterdelegation durch Subagenten bleiben gesperrt. Bei
|
||||
`custom` übersetzt der Adapter `description` und `prompt` jeder Rolle in eine explizite
|
||||
OpenCode-Subagentenkonfiguration mit demselben Modell wie der Hauptagent.
|
||||
|
||||
## LM Studio (nur `--provider lmstudio`)
|
||||
|
||||
Lokale Läufe sind eine eigene Versuchsbedingung: kein Netzzugriff, keine Providerkosten,
|
||||
gewichtsbezogene Reproduzierbarkeitsangaben (Quantisierung, Runtime, Kontextfenster) und ein
|
||||
Kontextfenster, das der Server beim Laden festlegt.
|
||||
|
||||
### Vorbereitung
|
||||
|
||||
```powershell
|
||||
lms server start # OpenAI-kompatibler Endpunkt auf Port 1234
|
||||
lms ls # heruntergeladene Modelle
|
||||
lms get qwen/qwen3.8-27b # fehlendes Modell holen (mehrere GB)
|
||||
lms ps # geladene Instanzen samt Kontextfenster
|
||||
```
|
||||
|
||||
### Preflight des Adapters
|
||||
|
||||
Vor dem Start von OpenCode prüft der Adapter über `GET /api/v0/models` und bricht mit
|
||||
Exitcode `2` und einer Handlungsanweisung ab, wenn eine Bedingung verletzt ist:
|
||||
|
||||
| Prüfung | Abbruchgrund |
|
||||
|---|---|
|
||||
| Server erreichbar | `lms server start` fehlt |
|
||||
| Modell vorhanden | nicht heruntergeladen → `lms get <ID>` |
|
||||
| `capabilities` enthält `tool_use` | ohne Tool-Calling ist kein Analyselauf möglich |
|
||||
| `max_context_length` ≥ `--min-context` | Modell kann die Bedingung nicht erfüllen |
|
||||
| Zustand `loaded` und `loaded_context_length` ≥ `--min-context` | zu kleines Fenster schneidet die Codebasis **stillschweigend** ab |
|
||||
| genau **eine** geladene Instanz | mehrere Instanzen (`modell`, `modell:2`) beantworten dieselbe `model`-Angabe; das Routing wäre nicht reproduzierbar |
|
||||
|
||||
`--min-context` ist standardmäßig `32768`. Ein bewusst kleinerer Wert ist zulässig, gehört aber
|
||||
als abweichende Versuchsbedingung ins Protokoll.
|
||||
|
||||
`--lmstudio-autoload` stellt den Sollzustand selbst her: Es entlädt **alle** Instanzen des
|
||||
Modells und lädt genau eine mit `--min-context` neu. Ohne das Flag meldet der Preflight nur den
|
||||
exakten `lms`-Befehl. Die Standardgröße von LM Studio (häufig 8192) reicht für eine
|
||||
Codebasisanalyse nicht.
|
||||
|
||||
Das geladene Fenster wird zusätzlich als `limit.context` in die Laufkonfiguration geschrieben,
|
||||
damit OpenCode nicht mehr Kontext sendet, als der Server vorhält.
|
||||
|
||||
### Speicherhygiene und Ladeparameter
|
||||
|
||||
Der lokale Durchsatz haengt fast vollstaendig davon ab, ob Gewichte und KV-Cache in den VRAM
|
||||
passen. Gemessen am 01.09.2026 auf einer RTX 5080 Laptop GPU (16.303 MiB):
|
||||
|
||||
| Konfiguration | VRAM belegt | Generierung |
|
||||
|---|---:|---:|
|
||||
| `gemma-4-e4b`, 32k, parallel 1 | 5.162 MiB | 48,3 tok/s |
|
||||
| `gemma-4-e4b`, 32k, parallel 4 | 5.222 MiB | 47,7 tok/s |
|
||||
| `gemma-4-e4b`, **131k**, parallel 4 | 6.854 MiB | 46,8 tok/s |
|
||||
| `qwen3.8-27b`, 32k, `--gpu max` | 15.696 MiB (308 frei) | Abbruch nach 10 min |
|
||||
| beide Modelle gleichzeitig geladen | 15.836 MiB (168 frei) | 0,028 Mio. Tokens/h |
|
||||
|
||||
Daraus die drei Regeln, die der Preflight seit Adapter 2.2.0 durchsetzt:
|
||||
|
||||
1. **Genau ein Modell ist geladen.** `--lmstudio-autoload` entlaedt `--all` und laedt nur das
|
||||
angeforderte Modell; ein fremdes geladenes Modell fuehrt sonst zum Abbruch. Ein nebenher
|
||||
geladenes Modell belegt VRAM, das dem Lauf fehlt, und veraendert dessen Durchsatz um
|
||||
Groessenordnungen.
|
||||
2. **Der Kontext wird auf das Modellmaximum geladen** (`--lmstudio-context max`, Standard).
|
||||
Freier VRAM ist in Kontext besser investiert als ungenutzt: vierfaches Fenster fuer 1,7 GB
|
||||
und 1,5 tok/s. `--min-context` bleibt die Gueltigkeitsschwelle, nicht die Ladegroesse.
|
||||
3. **`--lmstudio-gpu max`** erzwingt die vollstaendige Auslagerung, **`--lmstudio-parallel 4`**
|
||||
ist messbar kostenneutral und hilft, wenn Subagenten nebenlaeufig anfragen.
|
||||
|
||||
**Modelle jenseits der VRAM-Grenze sind nicht messbar.** `qwen3.8-27b` belegt mit 17,74 GB
|
||||
Gewichten mehr, als die Karte hat; der Rest laeuft auf der CPU. Auch eine kleinere
|
||||
Quantisierung loest das nicht, weil der KV-Cache eines 27B-Modells bei brauchbarem Kontext
|
||||
mehrere GB zusaetzlich fordert. Fuer eine 16-GB-Karte ist die 9B-Klasse die groesste, die mit
|
||||
vollem Fenster hineinpasst - dann aber in hoher Quantisierung, um den Speicher zu nutzen.
|
||||
|
||||
### Zusätzliche Laufartefakte und Messfelder
|
||||
|
||||
| Datei | Inhalt |
|
||||
|---|---|
|
||||
| `_meta/lmstudio-modelle.json` | Rohantwort von `/api/v0/models` zum Zeitpunkt des Preflights |
|
||||
|
||||
`RawResult.json` enthält bei lokalen Läufen zusätzlich:
|
||||
|
||||
| Messgröße | Feld |
|
||||
|---|---|
|
||||
| Kontextfenster des Laufs | `context_window` (= `local_runtime.loaded_context_length`) |
|
||||
| Quantisierungsstufe | `local_runtime.quantization` |
|
||||
| Runtime und Architektur | `local_runtime.compatibility_type`, `local_runtime.arch` |
|
||||
| Runtime-Version | `local_runtime.lms_version` |
|
||||
| Instanzbezeichner | `local_runtime.instance_id` |
|
||||
| Endpunkt | `local_runtime.base_url` |
|
||||
| Kosten | `cost` ist `0`; `cost_source` weist „nicht erfasst (lokaler Betrieb)" aus |
|
||||
| Effortwirkung | `effort_applied` ist `false` |
|
||||
|
||||
Damit sind die von Kapitel 4.3 geforderten Angaben für lokalen Betrieb – Runtime samt Version
|
||||
und Quantisierungsstufe – vollständig erfasst.
|
||||
|
||||
### Laufzeitverhalten
|
||||
|
||||
Kleine lokale Modelle beenden eine Aufgabe nicht zuverlässig von selbst; im Smoke-Test lief
|
||||
`google/gemma-4-e4b` über 50 Schritte weiter, ohne die geforderte Datei zu schreiben. Der
|
||||
Stall-Timeout greift dabei **nicht**, weil laufend Text erzeugt wird. Für lokale Läufe deshalb
|
||||
immer ein absolutes `--max-runtime` setzen und einen Abbruch als solchen protokollieren, statt
|
||||
ihn als Ergebnis zu werten.
|
||||
|
||||
## Aufruf
|
||||
|
||||
```powershell
|
||||
$skillDir = "<Verzeichnis des Skills>"
|
||||
$lauf = "<absoluter Pfad zum Laufverzeichnis>"
|
||||
$root = "<Root-Verzeichnis der Codebasis>"
|
||||
$provider = "<tensorx|lmstudio>"
|
||||
$modell = "<Modell-ID>"
|
||||
$effort = "<low|medium|high|xhigh|max>"
|
||||
$modus = "<solo|builtin|custom>"
|
||||
$agents = "<Agenten-JSON; nur bei custom>"
|
||||
|
||||
python "$skillDir\opencode-adapter.py" `
|
||||
--prompt "$lauf\_meta\combined_prompt.md" `
|
||||
--root $root `
|
||||
--output "$lauf\Ergebnisse" `
|
||||
--provider $provider `
|
||||
--model $modell `
|
||||
--effort $effort `
|
||||
--mode $modus `
|
||||
--agents $agents `
|
||||
--stall-timeout 600 `
|
||||
--max-runtime 0 `
|
||||
--result-dir $lauf `
|
||||
--title "run-experiment $modell $modus $effort"
|
||||
```
|
||||
|
||||
Für `--provider lmstudio` kommen hinzu:
|
||||
|
||||
```powershell
|
||||
--min-context 32768 ` # Mindestgröße des geladenen Kontextfensters
|
||||
--lmstudio-autoload ` # Modell notfalls selbst neu laden
|
||||
--max-runtime 3600 # absolutes Limit; lokale Modelle terminieren nicht zuverlässig
|
||||
```
|
||||
|
||||
`--base-url` (Standard `http://localhost:1234`) und `--lms` (Pfad zur CLI) sind nur nötig, wenn
|
||||
Port oder Installationsort abweichen.
|
||||
|
||||
`--agents` bei `solo` und `builtin` weglassen. `--stall-timeout 600` beendet den gesamten
|
||||
OpenCode-Prozessbaum, wenn zehn Minuten lang weder stdout noch stderr Aktivität zeigen.
|
||||
`--stall-timeout 0` deaktiviert diese Sicherung.
|
||||
|
||||
**In den Modi `builtin` und `custom` ist `--stall-timeout 0` zwingend.** OpenCode sendet
|
||||
**keine Ereignisse, solange ein Subagent arbeitet** – der Ereignisstrom schweigt für dessen
|
||||
gesamte Laufzeit. Jeder positive Stall-Timeout bricht den Lauf deshalb ab, sobald der erste
|
||||
Subagent startet, und erzeugt eine Fehlmessung, die wie ein Hänger aussieht. Der Adapter lehnt
|
||||
diese Kombination seit Version 1.3.0 mit einer Fehlermeldung ab, statt sie stillschweigend zu
|
||||
korrigieren. Die Laufzeit wird in diesen Modi ausschließlich über `--max-runtime` begrenzt. `--max-runtime 0` setzt kein absolutes
|
||||
Laufzeitlimit. `Ctrl+C` beendet ebenfalls den Prozessbaum und persistiert soweit möglich das
|
||||
Teilergebnis. Ein leeres `Ergebnisse`-Verzeichnis macht den Lauf standardmäßig zu einem Fehler.
|
||||
Nur ein bewusst textueller Smoke-Test darf diese Prüfung mit `--allow-empty-output` abschalten.
|
||||
|
||||
## Laufartefakte und Messfelder
|
||||
|
||||
| Datei | Inhalt |
|
||||
|---|---|
|
||||
| `OpenCodeEvents.jsonl` | unveränderter, inkrementell geschriebener JSON-Ereignisstrom |
|
||||
| `OpenCode.log` | OpenCode-stderr, inkrementell geschrieben |
|
||||
| `Adapter.log` | Start, Lebenszyklus, Abbruchgrund und Abschluss des Wrappers |
|
||||
| `_meta/opencode-config.json` | tatsächlich verwendete, keyfreie Laufkonfiguration |
|
||||
| `_meta/opencode-session.json` | exportierte Session, soweit eine Session-ID vorliegt |
|
||||
| `RawResult.json` | normalisierte Metriken für das gemeinsame Messprotokoll |
|
||||
|
||||
Aus `RawResult.json` verwenden:
|
||||
|
||||
| Messgröße | Feld |
|
||||
|---|---|
|
||||
| Erfolg/Abbruch | `is_error`, `subtype`, `timed_out`, `interrupted`, `exit_code`, `errors` |
|
||||
| Modellkontrolle | `provider`, `model`, `model_requested` |
|
||||
| Zeit | `duration_ms`, `start_time`, `end_time` |
|
||||
| Tokens | `usage.prompt_tokens`, `completion_tokens`, `reasoning_tokens`, `cache_read_tokens`, `cache_creation_tokens`, `total_tokens` |
|
||||
| Turns und Ende | `num_turns`, `finish_reason` |
|
||||
| Tools | `tool_call_count`, `tool_call_types`, `tool_calls` |
|
||||
| Subagenten | `subagent_stats`, `subagent_details` |
|
||||
| Ergebnisdateien | `written_files` |
|
||||
| Abschlusstext | `result` |
|
||||
| Reproduzierbarkeit | `adapter_version`, `opencode_version`, `config_path`, `session_id`, `adapter` |
|
||||
| Effortwirkung | `effort`, `effort_applied` |
|
||||
| Lokaler Betrieb | `local_runtime`, `context_window`, `cost_source` (nur `lmstudio`) |
|
||||
|
||||
`usage.total_tokens` übernimmt nach Möglichkeit OpenCodes Gesamtwert. Fehlt dieser, addiert
|
||||
der Adapter Input, Output, Reasoning, Cache-Read und Cache-Write aus den gelieferten
|
||||
OpenCode-Feldern. Kosten werden nur protokolliert, wenn OpenCode sie liefert; nicht schätzen.
|
||||
Bei `lmstudio` entstehen keine Providerkosten – `cost` ist definitionsgemäß `0`, nicht
|
||||
„unbekannt". Cache-Read und Cache-Write liefert der lokale Server nicht; sie sind im Protokoll
|
||||
als `nicht erfasst` auszuweisen.
|
||||
|
||||
## Pflichtprüfung
|
||||
|
||||
1. `RawResult.json` existiert und `is_error` ist `false`.
|
||||
2. `timed_out` und `interrupted` sind `false`; `exit_code` ist `0`.
|
||||
3. `OpenCode.log` und `errors` enthalten keinen Provider- oder Permissionfehler.
|
||||
4. Für Analyseversuche ist `Ergebnisse/` nicht leer und `tool_call_count` größer null.
|
||||
5. `model_requested` entspricht der angeforderten Modell-ID; `provider` entspricht `--provider`.
|
||||
6. Bei `custom` sind die erwarteten Rollen in `subagent_stats.by_type` nachweisbar.
|
||||
7. Bei `lmstudio` zusätzlich: `local_runtime.loaded_context_length` ≥ `--min-context`,
|
||||
`local_runtime.quantization` und `local_runtime.lms_version` sind gefüllt, und
|
||||
`effort_applied` ist `false` (im Protokoll als nicht steuerbar vermerken).
|
||||
|
||||
Ein absichtlich textueller Smoke-Test darf von den Prüfungen 4 und 6 abweichen, muss aber
|
||||
Antwort, Exitcode, Modell, Sessionexport und Tokenmetriken bestätigen.
|
||||
@@ -0,0 +1,244 @@
|
||||
import importlib.util
|
||||
import tempfile
|
||||
import time
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
from unittest.mock import patch
|
||||
|
||||
|
||||
ADAPTER_PATH = Path(__file__).with_name("glm-kimi-adapter.py")
|
||||
SPEC = importlib.util.spec_from_file_location("glm_kimi_adapter", ADAPTER_PATH)
|
||||
ADAPTER = importlib.util.module_from_spec(SPEC)
|
||||
SPEC.loader.exec_module(ADAPTER)
|
||||
|
||||
|
||||
def response(message, finish_reason="tool_calls", tokens=10):
|
||||
return {
|
||||
"model": "test/model",
|
||||
"usage": {
|
||||
"prompt_tokens": tokens,
|
||||
"completion_tokens": 1,
|
||||
"total_tokens": tokens + 1,
|
||||
"prompt_tokens_details": {"cached_tokens": 0},
|
||||
"completion_tokens_details": {"reasoning_tokens": 0},
|
||||
},
|
||||
"choices": [{"finish_reason": finish_reason, "message": message}],
|
||||
}
|
||||
|
||||
|
||||
def subagent_result(agent_id):
|
||||
return {
|
||||
"result": f"Ergebnis {agent_id}",
|
||||
"usage": {
|
||||
"prompt_tokens": 2,
|
||||
"completion_tokens": 1,
|
||||
"total_tokens": 3,
|
||||
"cached_tokens": 0,
|
||||
"reasoning_tokens": 0,
|
||||
},
|
||||
"turns": 1,
|
||||
"tool_calls": 0,
|
||||
"errors": [],
|
||||
"status": "completed",
|
||||
}
|
||||
|
||||
|
||||
class AdapterTests(unittest.TestCase):
|
||||
def setUp(self):
|
||||
self.provider = {
|
||||
"base_url": "https://example.invalid/v1",
|
||||
"__id": "test",
|
||||
}
|
||||
self.liveness = ADAPTER.LivenessMonitor(interval_seconds=0)
|
||||
|
||||
def test_timeout_zero_is_forwarded_as_no_requests_timeout(self):
|
||||
captured = {}
|
||||
|
||||
class FakeResponse:
|
||||
status_code = 200
|
||||
text = ""
|
||||
|
||||
@staticmethod
|
||||
def json():
|
||||
return {"ok": True}
|
||||
|
||||
def fake_post(*args, **kwargs):
|
||||
captured["timeout"] = kwargs["timeout"]
|
||||
return FakeResponse()
|
||||
|
||||
with patch.object(ADAPTER.requests, "post", side_effect=fake_post):
|
||||
result = ADAPTER.post_chat_completion(
|
||||
"https://example.invalid", {}, {}, 0, self.liveness,
|
||||
"test", "Testaufruf",
|
||||
)
|
||||
|
||||
self.assertEqual({"ok": True}, result)
|
||||
self.assertIsNone(captured["timeout"])
|
||||
|
||||
def test_requested_tensorx_models_have_explicit_effort_mapping(self):
|
||||
self.assertEqual("thinking", ADAPTER.MODEL_EFFORT_TYPE["qwen"])
|
||||
self.assertEqual("thinking", ADAPTER.MODEL_EFFORT_TYPE["z-ai"])
|
||||
|
||||
def test_custom_mode_exposes_spawn_subagent(self):
|
||||
captured = {}
|
||||
|
||||
def fake_post(url, headers, body, timeout, liveness,
|
||||
activity_id, activity_label):
|
||||
captured["tools"] = body["tools"]
|
||||
return response(
|
||||
{"role": "assistant", "content": "Fertig."},
|
||||
finish_reason="stop",
|
||||
)
|
||||
|
||||
with tempfile.TemporaryDirectory() as temp_dir, \
|
||||
patch.object(ADAPTER, "post_chat_completion", side_effect=fake_post):
|
||||
result = ADAPTER.run_agent_loop(
|
||||
provider=self.provider,
|
||||
model="qwen/qwen3.8-flash-next",
|
||||
system_prompt="System",
|
||||
user_prompt="Aufgabe",
|
||||
api_key="key",
|
||||
effort="high",
|
||||
root=temp_dir,
|
||||
output_dir=temp_dir,
|
||||
max_turns=0,
|
||||
temperature=1.0,
|
||||
timeout=0,
|
||||
liveness=self.liveness,
|
||||
mode="custom",
|
||||
)
|
||||
|
||||
tool_names = {
|
||||
tool["function"]["name"] for tool in captured["tools"]
|
||||
}
|
||||
self.assertIn("spawn_subagent", tool_names)
|
||||
self.assertFalse(result["is_error"])
|
||||
|
||||
def test_liveness_monitor_reports_active_main_and_subagent_operations(self):
|
||||
lines = []
|
||||
monitor = ADAPTER.LivenessMonitor(interval_seconds=0.02)
|
||||
with patch.object(ADAPTER, "log_stderr", side_effect=lines.append):
|
||||
monitor.set("main", "Hauptagent wartet auf Subagenten")
|
||||
monitor.set("subagent-1", "Subagent 1 wartet auf API-Antwort")
|
||||
monitor.start()
|
||||
time.sleep(0.06)
|
||||
monitor.stop()
|
||||
|
||||
output = "\n".join(lines)
|
||||
self.assertIn("LIFESIGN: Prozess lebt", output)
|
||||
self.assertIn("Hauptagent wartet auf Subagenten", output)
|
||||
self.assertIn("Subagent 1 wartet auf API-Antwort", output)
|
||||
self.assertIn("keinen serverseitigen Fortschritt", output)
|
||||
|
||||
def test_subagents_from_one_turn_run_in_parallel_without_count_limit(self):
|
||||
first_message = {
|
||||
"role": "assistant",
|
||||
"content": "Ich delegiere.",
|
||||
"tool_calls": [
|
||||
{
|
||||
"id": f"spawn-{index}",
|
||||
"type": "function",
|
||||
"function": {
|
||||
"name": "spawn_subagent",
|
||||
"arguments": (
|
||||
'{"description":"Aufgabe %d",'
|
||||
'"subagent_type":"explore"}' % index
|
||||
),
|
||||
},
|
||||
}
|
||||
for index in range(12)
|
||||
],
|
||||
}
|
||||
responses = [
|
||||
response(first_message),
|
||||
response(
|
||||
{"role": "assistant", "content": "Fertig."},
|
||||
finish_reason="stop",
|
||||
),
|
||||
]
|
||||
starts = []
|
||||
|
||||
def fake_post(*args, **kwargs):
|
||||
return responses.pop(0)
|
||||
|
||||
def fake_subagent(*args, **kwargs):
|
||||
agent_id = args[10]
|
||||
starts.append(time.monotonic())
|
||||
time.sleep(0.15)
|
||||
return subagent_result(agent_id)
|
||||
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
started = time.monotonic()
|
||||
with patch.object(ADAPTER, "post_chat_completion", side_effect=fake_post), \
|
||||
patch.object(ADAPTER, "run_subagent", side_effect=fake_subagent):
|
||||
result = ADAPTER.run_agent_loop(
|
||||
provider=self.provider,
|
||||
model="test/model",
|
||||
system_prompt="System",
|
||||
user_prompt="Aufgabe",
|
||||
api_key="key",
|
||||
effort="high",
|
||||
root=temp_dir,
|
||||
output_dir=temp_dir,
|
||||
max_turns=0,
|
||||
temperature=1.0,
|
||||
timeout=0,
|
||||
liveness=self.liveness,
|
||||
mode="builtin",
|
||||
subagent_max_turns=0,
|
||||
)
|
||||
elapsed = time.monotonic() - started
|
||||
|
||||
self.assertEqual(12, result["subagent_stats"]["spawned"])
|
||||
self.assertEqual(12, result["subagent_stats"]["completed"])
|
||||
self.assertEqual(0, result["subagent_stats"]["failed"])
|
||||
self.assertLess(max(starts) - min(starts), 0.12)
|
||||
self.assertLess(elapsed, 0.6)
|
||||
|
||||
def test_api_error_is_not_masked_by_earlier_content(self):
|
||||
first_message = {
|
||||
"role": "assistant",
|
||||
"content": "Zwischenstand",
|
||||
"tool_calls": [{
|
||||
"id": "list-1",
|
||||
"type": "function",
|
||||
"function": {
|
||||
"name": "list_directory",
|
||||
"arguments": '{"path":""}',
|
||||
},
|
||||
}],
|
||||
}
|
||||
calls = [response(first_message), RuntimeError("Transportfehler")]
|
||||
|
||||
def fake_post(*args, **kwargs):
|
||||
item = calls.pop(0)
|
||||
if isinstance(item, Exception):
|
||||
raise item
|
||||
return item
|
||||
|
||||
with tempfile.TemporaryDirectory() as temp_dir, \
|
||||
patch.object(ADAPTER, "post_chat_completion", side_effect=fake_post):
|
||||
result = ADAPTER.run_agent_loop(
|
||||
provider=self.provider,
|
||||
model="test/model",
|
||||
system_prompt="System",
|
||||
user_prompt="Aufgabe",
|
||||
api_key="key",
|
||||
effort="high",
|
||||
root=temp_dir,
|
||||
output_dir=temp_dir,
|
||||
max_turns=0,
|
||||
temperature=1.0,
|
||||
timeout=0,
|
||||
liveness=self.liveness,
|
||||
mode="solo",
|
||||
)
|
||||
|
||||
self.assertEqual("Zwischenstand", result["result"])
|
||||
self.assertTrue(result["is_error"])
|
||||
self.assertEqual("error", result["subtype"])
|
||||
self.assertIn("Transportfehler", result["errors"][0])
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -0,0 +1,372 @@
|
||||
import importlib.util
|
||||
import json
|
||||
import tempfile
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
ADAPTER_PATH = Path(__file__).with_name("opencode-adapter.py")
|
||||
SPEC = importlib.util.spec_from_file_location("opencode_adapter", ADAPTER_PATH)
|
||||
ADAPTER = importlib.util.module_from_spec(SPEC)
|
||||
SPEC.loader.exec_module(ADAPTER)
|
||||
|
||||
|
||||
class OpenCodeAdapterTests(unittest.TestCase):
|
||||
def test_model_reference_keeps_upstream_slashes(self):
|
||||
self.assertEqual(
|
||||
(
|
||||
"tensorx/qwen/qwen3.8-flash-next",
|
||||
"qwen/qwen3.8-flash-next",
|
||||
),
|
||||
ADAPTER.normalize_model("qwen/qwen3.8-flash-next"),
|
||||
)
|
||||
self.assertEqual(
|
||||
(
|
||||
"tensorx/qwen/qwen3.8-flash-next",
|
||||
"qwen/qwen3.8-flash-next",
|
||||
),
|
||||
ADAPTER.normalize_model("tensorx/qwen/qwen3.8-flash-next"),
|
||||
)
|
||||
|
||||
def test_custom_mode_translates_agents_and_restricts_delegation(self):
|
||||
base = {
|
||||
"provider": {
|
||||
"tensorx": {
|
||||
"models": {"qwen/qwen3.8-flash-next": {"name": "Qwen"}}
|
||||
}
|
||||
}
|
||||
}
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
temp = Path(temp_dir)
|
||||
root = temp / "root"
|
||||
output = root / "run" / "Ergebnisse"
|
||||
root.mkdir()
|
||||
output.mkdir(parents=True)
|
||||
agents = temp / "agents.json"
|
||||
agents.write_text(
|
||||
json.dumps(
|
||||
{
|
||||
"reviewer": {
|
||||
"description": "Prueft Fakten",
|
||||
"prompt": "Pruefe nur die zugewiesenen Fakten.",
|
||||
}
|
||||
}
|
||||
),
|
||||
encoding="utf-8",
|
||||
)
|
||||
|
||||
config = ADAPTER.build_run_config(
|
||||
base,
|
||||
"tensorx/qwen/qwen3.8-flash-next",
|
||||
"qwen/qwen3.8-flash-next",
|
||||
"custom",
|
||||
root,
|
||||
output,
|
||||
agents,
|
||||
)
|
||||
|
||||
self.assertEqual("allow", config["permission"]["task"]["reviewer"])
|
||||
self.assertEqual("deny", config["permission"]["task"]["*"])
|
||||
self.assertEqual("subagent", config["agent"]["reviewer"]["mode"])
|
||||
self.assertEqual(
|
||||
"tensorx/qwen/qwen3.8-flash-next",
|
||||
config["agent"]["reviewer"]["model"],
|
||||
)
|
||||
self.assertEqual("deny", config["agent"]["reviewer"]["permission"]["task"])
|
||||
self.assertIn(
|
||||
ADAPTER.normalized_path(output) + "/**",
|
||||
config["permission"]["edit"],
|
||||
)
|
||||
self.assertIn(
|
||||
"run/Ergebnisse/**",
|
||||
config["permission"]["edit"],
|
||||
)
|
||||
|
||||
def test_output_permissions_include_parent_relative_worktree_path(self):
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
temp = Path(temp_dir)
|
||||
root = temp / "QuellCode" / "Product"
|
||||
output = temp / "Versuche" / "Lauf" / "Ergebnisse"
|
||||
root.mkdir(parents=True)
|
||||
output.mkdir(parents=True)
|
||||
|
||||
patterns = ADAPTER.output_permission_patterns(root, output, temp)
|
||||
|
||||
self.assertIn("Versuche/Lauf/Ergebnisse/**", patterns)
|
||||
self.assertIn("../../Versuche/Lauf/Ergebnisse", patterns)
|
||||
self.assertIn("../../Versuche/Lauf/Ergebnisse/**", patterns)
|
||||
self.assertIn(ADAPTER.normalized_path(output) + "/**", patterns)
|
||||
|
||||
def test_normalize_result_uses_exported_metrics_and_tool_calls(self):
|
||||
session = {
|
||||
"info": {
|
||||
"id": "ses_test",
|
||||
"version": "1.18.25",
|
||||
"model": {
|
||||
"id": "qwen/qwen3.8-flash-next",
|
||||
"providerID": "tensorx",
|
||||
},
|
||||
"tokens": {
|
||||
"input": 100,
|
||||
"output": 10,
|
||||
"reasoning": 5,
|
||||
"cache": {"read": 20, "write": 0},
|
||||
},
|
||||
"cost": 0.1,
|
||||
},
|
||||
"messages": [
|
||||
{
|
||||
"info": {"role": "assistant", "finish": "stop"},
|
||||
"parts": [
|
||||
{
|
||||
"type": "tool",
|
||||
"tool": "task",
|
||||
"state": {
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"subagent_type": "reviewer",
|
||||
"description": "Pruefen",
|
||||
},
|
||||
},
|
||||
},
|
||||
{"type": "text", "text": "Fertig"},
|
||||
],
|
||||
}
|
||||
],
|
||||
}
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
output = Path(temp_dir)
|
||||
(output / "StRS.md").write_text("Inhalt", encoding="utf-8")
|
||||
result = ADAPTER.normalize_result(
|
||||
session=session,
|
||||
events=[],
|
||||
model_ref="tensorx/qwen/qwen3.8-flash-next",
|
||||
mode="custom",
|
||||
effort="low",
|
||||
exit_code=0,
|
||||
timed_out=False,
|
||||
interrupted=False,
|
||||
duration_s=1.5,
|
||||
output_dir=output,
|
||||
errors=[],
|
||||
)
|
||||
|
||||
self.assertFalse(result["is_error"])
|
||||
self.assertEqual(135, result["usage"]["total_tokens"])
|
||||
self.assertEqual(1, result["tool_call_count"])
|
||||
self.assertEqual(1, result["subagent_stats"]["spawned"])
|
||||
self.assertEqual({"reviewer": 1}, result["subagent_stats"]["by_type"])
|
||||
self.assertEqual("Fertig", result["result"])
|
||||
self.assertEqual(1, len(result["written_files"]))
|
||||
|
||||
|
||||
class ReadonlyShellTests(unittest.TestCase):
|
||||
"""Denylist: alles erlaubt ausser schreibenden und bauenden Kommandos."""
|
||||
|
||||
def test_catch_all_allow_comes_first(self):
|
||||
# OpenCode wertet der Reihe nach aus, die letzte passende Regel gewinnt.
|
||||
# Stuende das Catch-all hinten, waere jede Sperre wirkungslos.
|
||||
perms = ADAPTER.readonly_shell_permissions()
|
||||
self.assertEqual("allow", perms["*"])
|
||||
self.assertEqual("*", next(iter(perms)))
|
||||
|
||||
def test_writing_and_building_commands_are_denied(self):
|
||||
perms = ADAPTER.readonly_shell_permissions()
|
||||
for muster in ("rm *", "mv *", "sed -i*", "git commit*", "git push*",
|
||||
"dotnet *", "msbuild *", "npm install*",
|
||||
"Remove-Item *", "Set-Content *", "Out-File *"):
|
||||
self.assertEqual("deny", perms[muster], muster)
|
||||
|
||||
def test_reading_commands_need_no_rule(self):
|
||||
# Der Kern der Umstellung: Lesekommandos - auch als Pipeline - sind
|
||||
# erlaubt, ohne einzeln aufgefuehrt zu sein. Genau daran scheiterte
|
||||
# 'Get-ChildItem ... | Format-Table ...' unter der Allowlist.
|
||||
perms = ADAPTER.readonly_shell_permissions()
|
||||
for kommando in ("ls -la", "cat foo.cs", "rg muster",
|
||||
"Get-ChildItem -Recurse | Format-Table Name",
|
||||
"find . -name *.cs"):
|
||||
self.assertNotIn(kommando, perms)
|
||||
self.assertEqual("allow", perms["*"])
|
||||
|
||||
def test_no_reading_command_is_denied(self):
|
||||
verboten_praefixe = ("ls", "cat", "rg", "grep", "find", "head", "tail",
|
||||
"Get-ChildItem", "Get-Content", "Select-String",
|
||||
"git status", "git log", "dir", "type")
|
||||
for muster, aktion in ADAPTER.readonly_shell_permissions().items():
|
||||
if aktion != "deny":
|
||||
continue
|
||||
for praefix in verboten_praefixe:
|
||||
self.assertFalse(
|
||||
muster.lower().startswith(praefix.lower()),
|
||||
f"Lesekommando gesperrt: {muster}",
|
||||
)
|
||||
|
||||
|
||||
class UsageCapturedTests(unittest.TestCase):
|
||||
"""Eine Null aus einem laufenden Subagenten ist kein Messwert."""
|
||||
|
||||
def _result(self, session, output):
|
||||
return ADAPTER.normalize_result(
|
||||
session=session, events=[], model_ref="lmstudio/google/gemma-4-e4b",
|
||||
mode="builtin", effort="high", exit_code=1, timed_out=True,
|
||||
interrupted=False, duration_s=3600.0, output_dir=output, errors=[],
|
||||
provider="lmstudio", effort_applied=False,
|
||||
)
|
||||
|
||||
def test_running_subagent_with_zero_tokens_is_not_captured(self):
|
||||
session = {
|
||||
"info": {"model": {"id": "google/gemma-4-e4b"},
|
||||
"tokens": {"input": 0, "output": 0, "reasoning": 0,
|
||||
"cache": {"read": 0, "write": 0}}},
|
||||
"messages": [{
|
||||
"info": {"role": "assistant"},
|
||||
"parts": [{"type": "tool", "tool": "task",
|
||||
"state": {"status": "running",
|
||||
"input": {"subagent_type": "explore"}}}],
|
||||
}],
|
||||
}
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
result = self._result(session, Path(temp_dir))
|
||||
self.assertFalse(result["usage_captured"])
|
||||
self.assertIn("nicht erfasst", result["usage_note"])
|
||||
self.assertIn("1 Subagent(en)", result["usage_note"])
|
||||
|
||||
def test_real_token_counts_are_marked_captured(self):
|
||||
session = {
|
||||
"info": {"model": {"id": "google/gemma-4-e4b"},
|
||||
"tokens": {"input": 100, "output": 10, "reasoning": 0,
|
||||
"cache": {"read": 0, "write": 0}}},
|
||||
"messages": [{"info": {"role": "assistant"},
|
||||
"parts": [{"type": "text", "text": "ok"}]}],
|
||||
}
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
result = self._result(session, Path(temp_dir))
|
||||
self.assertTrue(result["usage_captured"])
|
||||
self.assertNotIn("usage_note", result)
|
||||
|
||||
|
||||
class OpenCodeLmStudioTests(unittest.TestCase):
|
||||
def test_model_reference_uses_lmstudio_provider(self):
|
||||
self.assertEqual(
|
||||
("lmstudio/google/gemma-4-e4b", "google/gemma-4-e4b"),
|
||||
ADAPTER.normalize_model("google/gemma-4-e4b", "lmstudio"),
|
||||
)
|
||||
self.assertEqual(
|
||||
("lmstudio/qwen/qwen3.8-27b", "qwen/qwen3.8-27b"),
|
||||
ADAPTER.normalize_model("lmstudio/qwen/qwen3.8-27b", "lmstudio"),
|
||||
)
|
||||
|
||||
def test_template_declares_both_local_models_without_key(self):
|
||||
template = json.loads(
|
||||
(ADAPTER_PATH.parent / "opencode-lmstudio.json").read_text(
|
||||
encoding="utf-8-sig"
|
||||
)
|
||||
)
|
||||
provider = template["provider"]["lmstudio"]
|
||||
self.assertEqual(
|
||||
"http://localhost:1234/v1", provider["options"]["baseURL"]
|
||||
)
|
||||
self.assertEqual(
|
||||
{"google/gemma-4-e4b", "qwen/qwen3.8-27b"},
|
||||
set(provider["models"]),
|
||||
)
|
||||
# Lokale Server pruefen den Key nicht; er darf nur ein Platzhalter sein.
|
||||
self.assertEqual("lm-studio", provider["options"]["apiKey"])
|
||||
|
||||
def test_build_run_config_pins_loaded_context_window(self):
|
||||
base = json.loads(
|
||||
(ADAPTER_PATH.parent / "opencode-lmstudio.json").read_text(
|
||||
encoding="utf-8-sig"
|
||||
)
|
||||
)
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
root = Path(temp_dir) / "root"
|
||||
output = root / "run" / "Ergebnisse"
|
||||
output.mkdir(parents=True)
|
||||
config = ADAPTER.build_run_config(
|
||||
base,
|
||||
"lmstudio/google/gemma-4-e4b",
|
||||
"google/gemma-4-e4b",
|
||||
"solo",
|
||||
root,
|
||||
output,
|
||||
None,
|
||||
provider="lmstudio",
|
||||
context_limit=32768,
|
||||
)
|
||||
|
||||
model = config["provider"]["lmstudio"]["models"]["google/gemma-4-e4b"]
|
||||
self.assertEqual(32768, model["limit"]["context"])
|
||||
self.assertEqual("deny", config["permission"]["task"])
|
||||
self.assertEqual("deny", config["permission"]["webfetch"])
|
||||
|
||||
def test_normalize_result_reports_local_runtime_and_zero_cost(self):
|
||||
runtime = {
|
||||
"provider": "lmstudio",
|
||||
"quantization": "Q4_K_M",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"loaded_context_length": 32768,
|
||||
"max_context_length": 131072,
|
||||
}
|
||||
session = {
|
||||
"info": {
|
||||
"id": "ses_local",
|
||||
"model": {"id": "google/gemma-4-e4b"},
|
||||
"tokens": {"input": 10, "output": 4, "reasoning": 2,
|
||||
"cache": {"read": 0, "write": 0}},
|
||||
"cost": 0,
|
||||
},
|
||||
"messages": [
|
||||
{
|
||||
"info": {"role": "assistant", "finish": "stop"},
|
||||
"parts": [{"type": "text", "text": "Fertig"}],
|
||||
}
|
||||
],
|
||||
}
|
||||
with tempfile.TemporaryDirectory() as temp_dir:
|
||||
output = Path(temp_dir)
|
||||
(output / "StRS.md").write_text("Inhalt", encoding="utf-8")
|
||||
result = ADAPTER.normalize_result(
|
||||
session=session,
|
||||
events=[],
|
||||
model_ref="lmstudio/google/gemma-4-e4b",
|
||||
mode="solo",
|
||||
effort="high",
|
||||
exit_code=0,
|
||||
timed_out=False,
|
||||
interrupted=False,
|
||||
duration_s=2.0,
|
||||
output_dir=output,
|
||||
errors=[],
|
||||
provider="lmstudio",
|
||||
effort_applied=False,
|
||||
local_runtime=runtime,
|
||||
)
|
||||
|
||||
self.assertEqual("lmstudio", result["provider"])
|
||||
self.assertEqual("opencode-lmstudio", result["adapter"])
|
||||
self.assertFalse(result["effort_applied"])
|
||||
self.assertEqual(32768, result["context_window"])
|
||||
self.assertEqual("Q4_K_M", result["local_runtime"]["quantization"])
|
||||
self.assertEqual(0, result["cost"])
|
||||
self.assertIn("lokaler Betrieb", result["cost_source"])
|
||||
self.assertEqual(16, result["usage"]["total_tokens"])
|
||||
|
||||
def test_tensorx_result_keeps_remote_shape(self):
|
||||
session = {"info": {"model": {"id": "qwen/qwen3.8-flash-next"},
|
||||
"tokens": {"input": 1, "output": 1}}, "messages": []}
|
||||
result = ADAPTER.normalize_result(
|
||||
session=session, events=[], model_ref="tensorx/qwen/qwen3.8-flash-next",
|
||||
mode="solo", effort="low", exit_code=0, timed_out=False,
|
||||
interrupted=False, duration_s=1.0, output_dir=Path("."), errors=[],
|
||||
)
|
||||
self.assertEqual("tensorx", result["provider"])
|
||||
self.assertEqual("opencode-tensorx", result["adapter"])
|
||||
self.assertTrue(result["effort_applied"])
|
||||
self.assertNotIn("local_runtime", result)
|
||||
self.assertNotIn("context_window", result)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
+591
-12
@@ -1,7 +1,7 @@
|
||||
# Ablaufprotokoll der Versuchsdurchführung
|
||||
# Ablaufprotokoll der Versuchsdurchführung
|
||||
|
||||
**Zeitraum:** 25.–26. August 2026
|
||||
**Ablage der Läufe:** `Versuche/Versuch_01/Tag 1/` – alle 24 Läufe entstanden am 25. August
|
||||
**Zeitraum:** 25.–31. August 2026
|
||||
**Ablage der Läufe:** `Versuche/Versuch_01/Iteration <N>/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/`
|
||||
**Untersuchungsgegenstand:** c-entron ERP-Suite, eingefrorener Snapshot `79c1142`
|
||||
**Zweck dieses Dokuments:** Grundlage für den Ergebnisteil der Arbeit (Kapitel 5 und 6).
|
||||
|
||||
@@ -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,
|
||||
API-Transportfehler).
|
||||
**Iteration 1:** 24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl
|
||||
(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,551 @@ 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).
|
||||
|
||||
---
|
||||
|
||||
### Nachanalyse der Kimi-K3-Läufe und Adapterkorrektur 9.0.0 (29.08.2026)
|
||||
|
||||
Die zunächst notierte Erklärung, Kimi K3 beende seine Arbeit nach einer Beschreibung mit
|
||||
`finish_reason: stop`, wird durch die Rohdaten widerlegt. In allen fünf `solo`-Läufen mit
|
||||
Prompt-Version 03 war die letzte erfolgreiche Antwort ein Tool-Aufruf
|
||||
(`finish_reason: tool_calls`). Der jeweils folgende HTTP-Aufruf an TensorX lieferte 1.800
|
||||
Sekunden lang keine Antwort und endete mit `Read timed out (read timeout=1800)`.
|
||||
|
||||
| Lauf | Iteration | Turns | Tokens | Dateien | Tatsächliches Ende |
|
||||
|---:|---:|---:|---:|---:|---|
|
||||
| 31 | 7 | 23 | 628.222 | 0 | API-Read-Timeout in Turn 23 |
|
||||
| 35 | 8 | 44 | 3.208.550 | 1 | API-Read-Timeout in Turn 44 |
|
||||
| 37 | 8 | 27 | 1.473.405 | 1 | API-Read-Timeout in Turn 27 |
|
||||
| 39 | 8 | 25 | 695.248 | 7, davon 6 nur Skelette | API-Read-Timeout in Turn 25 |
|
||||
| 40 | 8 | 30 | 2.094.726 | 0 | API-Read-Timeout in Turn 30 |
|
||||
|
||||
Der Timeout war im Adapter trotz der CLI-Beschreibung `--timeout 0` fest auf 1.800 Sekunden
|
||||
gesetzt. Zusätzlich lautete die Fehlerbedingung
|
||||
`len(errors) > 0 and not final_content`: Sobald irgendeine frühere Modellantwort Freitext
|
||||
enthielt, wurden der Timeout, `subtype` und der Prozess-Exitcode als Erfolg ausgewiesen. Der
|
||||
Fehler stand nur im Feld `errors` der `RawResult.json`, nicht in `Stderr.log`. Dadurch konnte die
|
||||
vorgeschriebene Stderr-Prüfung ihn nicht erkennen.
|
||||
|
||||
Die Kausalität ist daher zweistufig: Der unmittelbare Stillstand liegt auf dem nicht
|
||||
gestreamten Kimi-/TensorX-API-Aufruf; dass daraus eine stille oder falsch als erfolgreich
|
||||
markierte Fehlmessung wurde, liegt am Adapter. Ein grundsätzlich ungeeignetes Modell ist nicht
|
||||
belegt: Kimi K3 schloss in Iteration 6 unter Prompt-Version 02 sowohl `solo` als auch `builtin`
|
||||
ohne Hauptagenten-API-Fehler ab. Auch ein fester Kontext- oder Turnschwellenwert erklärt die
|
||||
Streuung der Abbruchturns 23 bis 44 nicht.
|
||||
|
||||
Die beiden abgebrochenen `builtin`-Wiederholungen haben zusätzliche, getrennte Ursachen:
|
||||
|
||||
- Lauf 36 wurde nach sechs gestarteten Subagenten durch einen Stromausfall beendet.
|
||||
- Lauf 38 wurde nach zehn gestarteten und vier vom Adapter verweigerten Subagenten manuell
|
||||
beendet. Der Adapter arbeitete Subagenten synchron ab, obwohl das Modell sie gemeinsam und
|
||||
damit parallel angefordert hatte.
|
||||
|
||||
Das in Iteration 8 eingeführte 10er-Limit ist keine neutrale Schutzmaßnahme. Anzahl, Typ und
|
||||
Zerlegung der Subagenten sind selbst Untersuchungsgegenstand von V1b. Nach dem zehnten Start
|
||||
injizierte der Adapter zudem eine Aufforderung, keine weiteren Subagenten zu starten und sofort
|
||||
Dateien zu schreiben. Auch die turnabhängigen Schreib-Erinnerungen griffen in die autonome
|
||||
Strategie ein. Lauf 34 belegt daher nur, dass GLM unter dieser erzwungenen Adapterstrategie
|
||||
Ergebnisdateien erzeugte; er ist nicht mit einem freien `builtin`-Lauf poolbar.
|
||||
|
||||
**Adapterkorrektur und neue Versuchsbedingung (Skill 9.0.0, Adapter 2.0.0):**
|
||||
|
||||
- Kein Anzahl-Limit für `spawn_subagent`; Typ und Zahl bestimmt ausschließlich das Modell.
|
||||
- Alle Subagenten-Aufrufe aus demselben Hauptagenten-Turn laufen tatsächlich parallel.
|
||||
- Haupt- und Subagenten haben standardmäßig kein Turnlimit; laufzeitabhängige
|
||||
Schreib-Erinnerungen wurden entfernt.
|
||||
- `--timeout 0` bedeutet tatsächlich kein clientseitiges HTTP-Timeout.
|
||||
- API-Fehler setzen unabhängig von früherem Freitext `is_error: true`, werden nach
|
||||
`Stderr.log` geschrieben und führen zu Exitcode 1.
|
||||
- Ein threadsicheres Lebenszeichen meldet standardmäßig alle 60 Sekunden, welche Operation
|
||||
beim Hauptagenten und bei jedem Subagenten aktiv ist. Abgeschlossene API-Turns melden ihren
|
||||
Einzel- und kumulierten Tokenverbrauch.
|
||||
|
||||
Ein Lebenszeichen während eines API-Aufrufs bedeutet ausschließlich: Der lokale Python-Prozess
|
||||
lebt und wartet weiterhin auf TensorX. Da die API nicht gestreamt wird, kann der Adapter während
|
||||
dieser Wartephase nicht unterscheiden, ob serverseitig noch inferiert wird oder der Request
|
||||
hängt. Der Logtext weist auf diese Grenze ausdrücklich hin. Automatische Abbrüche oder Retries
|
||||
wurden bewusst nicht eingeführt, weil Laufzeit unerheblich ist und ein Retry zusätzlichen,
|
||||
möglicherweise doppelten Tokenverbrauch verursachen kann.
|
||||
|
||||
Die Implementierung wurde ohne echten API-Aufruf geprüft: zwölf in einem Turn angeforderte
|
||||
Subagenten starteten ohne Ablehnung parallel; `timeout=0` wurde als unbegrenztes Requests-Timeout
|
||||
weitergereicht; ein API-Fehler nach vorhandenem Freitext blieb ein Fehler; Haupt- und
|
||||
Subagentenaktivitäten erschienen gemeinsam im Heartbeat. Alle vier Tests liefen erfolgreich.
|
||||
|
||||
Da Parallelität, Limits, Laufsteuerung und Fehlersemantik geändert wurden, ist dies eine neue
|
||||
Versuchsbedingung. Der nächste TensorX-Lauf beginnt **Iteration 9**; Iteration-8-`builtin`-Läufe
|
||||
werden nicht mit den neuen freien `builtin`-Läufen gepoolt.
|
||||
|
||||
### Versuch 2 – erster Lauf im Modus `custom` (31.08.2026)
|
||||
|
||||
Erster Lauf mit rollenspezialisierten Agentendateien überhaupt. Er eröffnet `Iteration 1` in
|
||||
`Versuche/Versuch_02/`.
|
||||
|
||||
**Vorgeschaltete Korrekturen am Versuchsaufbau.** Der bis dahin vorbereitete V2-Prompt
|
||||
(`01_Prompt.md`, Version 02-A) leitete sich von Prompt-Version **02** ab, während Versuch 1 seit
|
||||
Iteration 8 auf Version **03** lief. Ein Lauf dagegen hätte sich in zwei Größen unterschieden –
|
||||
Agentenrollen *und* Prompt-Version – und wäre als Wirkungsnachweis der Rollen unbrauchbar
|
||||
gewesen. `02_Prompt.md` (Version **03-A**) setzt deshalb auf Prompt-Version 03 auf; einzige
|
||||
Ergänzung bleibt der Abschnitt *Arbeitsteilung*. Dabei fielen zwei Fehlstellen in
|
||||
`Versuch_01/03_Prompt.md` auf, die in jeden Lauf der Iterationen 8 und 9 eingingen, weil der
|
||||
Skill die gesamte Datei sendet: eine leere Änderungstabelle im Metadatenblock und zwei
|
||||
Tabellenzeilen, die hinter dem Abschnitt *Abschluss* stehen.
|
||||
|
||||
**Die Rollennutzung wurde gebunden.** Ein Smoke-Test vom 26.08. hatte gezeigt, dass der Agent von
|
||||
acht beigestellten Rollen nur zwei einsetzt. Ohne Bindung wird die Versuchsbedingung nicht
|
||||
hergestellt: Der Lauf führt die Rollen mit, ohne sie zu nutzen. Der Prompt verlangt seither, dass
|
||||
eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, von ihm ausgeführt wird; die konkrete
|
||||
Zuordnung `Teilaufgabe → Rolle` steht im Block *Werkzeugkontext* (Skill 9.1.0), nicht im Prompt,
|
||||
damit dieselbe Prompt-Datei für `solo` und `builtin` gültig bleibt. Gebunden ist **wer** eine
|
||||
Teilaufgabe ausführt; Zuschnitt, Anzahl, Reihenfolge und Tiefe bleiben frei.
|
||||
|
||||
Die Bindung ist statisch deklariert und über den SHA-256 der `--agents`-Datei versioniert. Sie
|
||||
ist damit von den in Skill 9.0.0 entfernten **laufzeitabhängigen** Adaptereingriffen zu
|
||||
unterscheiden, die Lauf 34 unpoolbar machten: Jene steuerten den Lauf abhängig von seinem eigenen
|
||||
Verlauf um, diese steht vor dem Lauf fest.
|
||||
|
||||
**Ergebnis des Laufs** (`Iteration 1/claude-sonnet-5/custom/high/…_v9.1.0-0c39`):
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Wanduhrdauer | 03:07:16 |
|
||||
| Tokens gesamt | **352.828.287** |
|
||||
| Anforderungen | 845 (StRS 185 / SyRS 180 / SwRS 480) |
|
||||
| Subagenten | 86 gestartet, 86 abgeschlossen, 0 fehlgeschlagen |
|
||||
| Primärbelegquote | 96,0 % der Belege; 95,6 % der Anforderungen |
|
||||
| Permission-Denials | 3 (alle Bash, Denylist) |
|
||||
|
||||
Der Lauf ist gültig: alle sieben geforderten Dateien, keine Ergänzungsdateien, `Stderr.log` leer,
|
||||
Root unverändert, Modellkontrolle bestanden. Er ist mit **352,8 Mio. Tokens** zugleich der
|
||||
aufwendigste der gesamten Reihe – 1,8-fach über dem bisherigen Höchstwert (193,4 Mio., ohne
|
||||
Artefakt) und 2,3-fach über dem teuersten Lauf mit Ergebnis.
|
||||
|
||||
**Die Bindung wirkt.** Alle acht Rollen wurden eingesetzt, gegenüber 2 von 8 im ungebundenen
|
||||
Smoke-Test. Die Zerlegung blieb dabei frei gewählt: acht Inventar-Ausschnitte, 35 Faktenaufträge,
|
||||
ID-blockweise Autorenaufträge.
|
||||
|
||||
| Rolle | Aufrufe | Rolle | Aufrufe |
|
||||
|---|---:|---|---:|
|
||||
| `faktenermittler` | 35 | `syrs-autor` | 6 |
|
||||
| `general-purpose` | 12 | `Explore` | 4 |
|
||||
| `swrs-autor` | 10 | `belegpruefer` | 1 |
|
||||
| `modulinventar` | 8 | `iso29148-orchestrator` | 1 |
|
||||
| `strs-autor` | 8 | `konsistenzpruefer` | 1 |
|
||||
|
||||
**Vier Befunde aus dem Lauf:**
|
||||
|
||||
1. **Die Bindung hatte eine Lücke.** 12 Aufrufe gingen an den eingebauten Typ `general-purpose`,
|
||||
sämtlich für die Traceability-Anreicherung (Schritt 6) – für die die Zuordnungstabelle keinen
|
||||
Bearbeiter vorsah, obwohl `iso29148-orchestrator` laut Rollenprompt dafür zuständig ist. Kein
|
||||
Verstoß des Agenten, sondern ein Konstruktionsfehler der Tabelle. Wo die Bindung schweigt,
|
||||
greift der Agent zum eingebauten Typ.
|
||||
2. **Die Selbstauskunft war an einer Stelle falsch.** Der `Analysebericht.md` vermerkt
|
||||
*Ausnahmen von der Zuständigkeitsbindung: keine*, obwohl die Traceability von
|
||||
`general-purpose` stammt. Aufgefallen ist das nur durch den maschinellen Abgleich gegen
|
||||
`subagent_stats.by_type` – die Dokumentationspflicht allein hätte den Fall verdeckt.
|
||||
3. **`--agents` ersetzt die Agent-Registry nicht, es ergänzt sie.** `Explore` und
|
||||
`general-purpose` blieben verfügbar. Ein V2, das ausschließlich die beigestellten Rollen
|
||||
zulassen soll, bräuchte zusätzlich eine Sperre – eine geänderte Werkzeugkonfiguration und
|
||||
damit eine neue Bedingung.
|
||||
4. **Die Rollen delegierten selbst.** `spawned_by_subagents` = 26 von 86, `max_depth` = 3. Die
|
||||
Rollen erben über `--agents` alle Werkzeuge einschließlich `Task`. Das war nicht beabsichtigt
|
||||
und ist der wesentliche Kostentreiber (siehe unten).
|
||||
|
||||
**Zwei überholte Annahmen des Skills.** Unter CLI 2.1.251 liegt je Lauf ein Verzeichnis
|
||||
`subagents/` mit einer vollständigen `.jsonl` je Subagent; die Feststellung, Subagenten-Transkripte
|
||||
würden nicht auswertbar persistiert (Stand 2.1.245), gilt nicht mehr. Damit wären erstmals auch
|
||||
die Prompts und Verläufe der Ebenen 2 und 3 auswertbar, die `extract-subagenten.py` nicht
|
||||
erreicht. Zweitens erfasst `duration_ms` (220.847 ms) den Gesamtlauf erkennbar nicht und ist als
|
||||
Dauer unbrauchbar; berichtet wird die selbst gemessene Wanduhrzeit.
|
||||
|
||||
**Nebenbefund zur Zerlegung.** 72 Aufrufe wurden am Nebenläufigkeitslimit (20 gleichzeitig)
|
||||
abgewiesen – gegenüber 86 gestarteten die höchste Absagequote der Reihe. Die Zerlegung ist damit
|
||||
nur eingeschränkt selbstgewählt: Sie ist teilweise vom Werkzeuglimit geformt.
|
||||
|
||||
### Kostenanalyse und die Option `unverschachtelt` (Skill 9.2.0, 31.08.2026)
|
||||
|
||||
Der Lauf verbrauchte 43 % des verfügbaren Modellkontingents. Für die Wiederholung mit
|
||||
`claude-opus-5` ist das die bindende Grenze, denn Opus kostet **gleichmäßig das 2,5-fache** von
|
||||
Sonnet 5 – auf Input, Output, Cache-Write und Cache-Read gleichermaßen. Derselbe Lauf mit Opus
|
||||
entspräche rund **108 %** des Kontingents; das Ergebnis hängt nicht davon ab, wie das Kontingent
|
||||
denominiert ist, weil der Faktor uniform ist.
|
||||
|
||||
Kostenanteile des Laufs:
|
||||
|
||||
| Position | Tokens | Anteil an den Kosten |
|
||||
|---|---:|---:|
|
||||
| Cache-Read | 335,3 Mio. | 46 % |
|
||||
| Output | 4,69 Mio. | 32 % |
|
||||
| Cache-Write | 12,8 Mio. | 22 % |
|
||||
|
||||
Cache-Reads dominieren, und sie entstehen **innerhalb** der Subagenten: Jeder Turn liest den bis
|
||||
dahin gewachsenen Kontext erneut, die Kosten wachsen daher etwa quadratisch mit der Turn-Zahl je
|
||||
Agent. Bei 86 Agenten entfallen rechnerisch rund 3,9 Mio. Cache-Reads auf jeden.
|
||||
|
||||
Daraus folgt die neue Option **Delegationstiefe** (Skill 9.2.0). `unverschachtelt` untersagt jeder
|
||||
Rolle in ihrem Prompt die Weiterdelegation; `verschachtelt` entspricht dem bisherigen Verhalten.
|
||||
Bestehende Läufe gelten rückwirkend als `verschachtelt`. Kontrolle nach dem Lauf über
|
||||
`subagent_stats.max_depth` und `spawned_by_subagents`.
|
||||
|
||||
Die strukturellen Korrekturen allein – keine Weiterdelegation, Faktenübergabe per Datei statt
|
||||
inline – bringen geschätzt 30 bis 40 %. Nötig wären 60 %. Der Opus-Lauf erfordert deshalb
|
||||
zusätzlich eine bewusste Bedingungsänderung: **Effort `medium` statt `high`**. Der Modellvergleich
|
||||
Sonnet-`high` gegen Opus-`medium` ist damit konfundiert; aufzulösen ist das durch einen
|
||||
zusätzlichen, günstigen Lauf `claude-sonnet-5 / custom / medium`, der Modell- und Effort-Effekt
|
||||
trennt.
|
||||
|
||||
**Anzumerken bleibt:** Die Wirkung des Effort-Wechsels auf einen `custom`-Lauf ist nicht gemessen,
|
||||
sondern geschätzt. Bleibt der Opus-Lauf über 43 %, ist das selbst ein Befund zur Messbarkeit der
|
||||
Zelle – vergleichbar mit `claude-opus-5 / builtin / high` aus Versuch 1.
|
||||
|
||||
---
|
||||
|
||||
### Versuch 2 – Opus-Lauf und die Kontingentgrenze (31.08.2026)
|
||||
|
||||
Der zweite V2-Lauf sollte prüfen, ob die Zelle `claude-opus-5 / custom` innerhalb der 43 % des
|
||||
Modellkontingents machbar ist, die der Sonnet-Lauf verbraucht hatte. **Sie ist es nicht.** Er
|
||||
eröffnet `Iteration 2` in Versuch 02
|
||||
(`Iteration 2/claude-opus-5/custom/medium/…_v9.2.0-da6a`).
|
||||
|
||||
**Drei Größen wurden gleichzeitig gewechselt**, zwei davon erzwungen durch das Kontingent:
|
||||
|
||||
| Größe | Iteration 1 | Iteration 2 |
|
||||
|---|---|---|
|
||||
| Modell | `claude-sonnet-5` | `claude-opus-5` |
|
||||
| Effort | `high` | `medium` |
|
||||
| Delegationstiefe | `verschachtelt` | `unverschachtelt` |
|
||||
|
||||
Ein Modellvergleich zwischen beiden Läufen ist damit **nicht zulässig**; die Gegenüberstellung
|
||||
unten vergleicht zwei Bedingungen, nicht zwei Modelle.
|
||||
|
||||
**Ergebnis:**
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---:|
|
||||
| Wanduhrdauer | 03:47:17 |
|
||||
| Tokens gesamt | **397.199.658** |
|
||||
| Anforderungen | 606 (StRS 53 / SyRS 149 / SwRS 404) |
|
||||
| Subagenten | 56 gestartet, 56 abgeschlossen, 0 fehlgeschlagen, **0 abgewiesen** |
|
||||
| Permission-Denials | 0 |
|
||||
| Regelverstöße (maschinell) | **0** |
|
||||
|
||||
Der Lauf ist gültig – alle sieben Dateien, `Stderr.log` leer, Root unverändert – **mit einer
|
||||
Einschränkung: die Modellbedingung ist verletzt.**
|
||||
|
||||
**Die Kontingentgrenze ist die eigentliche Nachricht.** Zu Listenpreisen kostet der Lauf rund
|
||||
$433 gegenüber $146 des Sonnet-Laufs, also das **2,97-fache** und damit rund **128 % des
|
||||
Kontingents**. Der Preisfaktor zwischen Opus 5 und Sonnet 5 beträgt gleichmäßig 2,5 auf allen
|
||||
Token-Klassen; die restliche Differenz stammt aus einem um 12,6 % **höheren** Tokenverbrauch –
|
||||
und zwar trotz `medium` statt `high`, trotz unterbundener Weiterdelegation und trotz 56 statt 86
|
||||
Agenten. Je Subagent wurden rund 13,6 Mio. Transkript-Tokens verbraucht gegenüber 7,0 Mio. beim
|
||||
Sonnet-Lauf: Opus zerlegt gröber und arbeitet jeden Ausschnitt tiefer aus. Beide strukturellen
|
||||
Sparmaßnahmen wurden davon vollständig aufgezehrt.
|
||||
|
||||
Die vorab getroffene Schätzung von 38 bis 45 % war damit **deutlich zu niedrig**. Auch die
|
||||
laufende Live-Schätzung aus den Transkripten traf nicht: Sie meldete kurz vor Laufende 96 %,
|
||||
tatsächlich waren es 128 %. Der dafür verwendete Kalibrierfaktor – Transkriptsumme geteilt durch
|
||||
den am Sonnet-Lauf gemessenen Wert 2,45 – beträgt für diesen Lauf nur 1,95. Er ist nicht
|
||||
laufübergreifend stabil, weil er vom Verhältnis Haupt- zu Subagenten-Nachrichten abhängt. Eine
|
||||
solche Schätzung taugt zur Richtungsanzeige, nicht zur Budgetsteuerung.
|
||||
|
||||
**Damit ist `claude-opus-5 / custom` als unter dem verfügbaren Kontingent nicht wiederholbar
|
||||
messbare Zelle zu führen** – die zweite nach `claude-opus-5 / builtin / high` aus Versuch 1. In
|
||||
beiden Fällen ist die Grenze das Kontingent und nicht das Verfahren.
|
||||
|
||||
**Modellbedingung verletzt – erstmals auftragsscharf lokalisiert.** `modelUsage` weist neben
|
||||
`claude-opus-5` (365,0 Mio.) das nicht angeforderte `claude-sonnet-5` mit 32,2 Mio. Tokens
|
||||
(8,1 %) aus. Weil CLI 2.1.251 jedes Subagenten-Transkript einzeln persistiert, ließ sich der Fall
|
||||
erstmals genau verorten statt nur als Summe zu sehen: 8 der 56 Subagenten liefen auf Sonnet –
|
||||
sechs `faktenermittler`, ein `swrs-autor`, ein `modulinventar`. Sieben davon betreffen denselben
|
||||
Gegenstand (docuFORM, offener Punkt 63), für den der `faktenermittler` sechsmal beauftragt wurde.
|
||||
Ob der Modellwechsel eine Folge der wiederholten Beauftragung derselben Teilaufgabe ist oder eine
|
||||
davon unabhängige Zuweisung der CLI, ist aus den Daten nicht zu entscheiden. Der Fall ist der
|
||||
dritte dokumentierte seiner Art und bestätigt: `--model` bindet den Hauptagenten, nicht
|
||||
zuverlässig die Subagenten.
|
||||
|
||||
**Was die neuen Vorgaben geleistet haben.** Die Delegationstiefe `unverschachtelt` hat
|
||||
vollständig gegriffen: `spawned_by_subagents` = 0, `max_depth` = 1, 56 Aufrufe gegen 56
|
||||
Transkripte – und das allein über den Rollenprompt, ohne technische Erzwingung. Als Nebeneffekt
|
||||
entfielen die Absagen am Nebenläufigkeitslimit vollständig (0 gegenüber 72 im ersten V2-Lauf).
|
||||
|
||||
Alle acht Rollen wurden eingesetzt, und zwar **ohne einen einzigen Aufruf an einen eingebauten
|
||||
Typ** – gegenüber 16 von 86 (18,6 %) im ersten V2-Lauf. Die Bindungslücke bei Schritt 6
|
||||
(Traceability) blieb absichtlich offen, um die Zahl der geänderten Größen zu begrenzen; sie
|
||||
wirkte sich hier nicht aus. Die `Traceability.md` entstand ohne ungebundenen Agenten. Ein
|
||||
Modelleffekt ist naheliegend, bei drei gleichzeitig gewechselten Größen aber nicht belegt.
|
||||
|
||||
**Gegenüberstellung der beiden V2-Läufe** – zwei Bedingungen, kein Modellvergleich:
|
||||
|
||||
| Kenngröße | Iteration 1 (Sonnet/high/verschachtelt) | Iteration 2 (Opus/medium/unverschachtelt) |
|
||||
|---|---:|---:|
|
||||
| Anforderungen | 845 | 606 |
|
||||
| Verteilung StRS/SyRS/SwRS | 185 / 180 / 480 | 53 / 149 / 404 |
|
||||
| Belege gesamt | 1.086 | **1.927** |
|
||||
| Belege je Anforderung (Median) | 1,0 | **3,0** |
|
||||
| Anforderungen mit `PRIMÄR`-Beleg | 95,6 % | **98,5 %** |
|
||||
| Anforderungen ohne jeden Beleg | 9 | **0** |
|
||||
| Hypothesenanteil | 8,9 % | 4,8 % |
|
||||
| Konsolidierungskandidaten | 22,1 % | 38,3 % |
|
||||
| mit ISO-25010-Merkmal | **65,9 %** | 13,4 % |
|
||||
| Subagenten | 86 | 56 |
|
||||
| Tokens gesamt | 352.828.287 | 397.199.658 |
|
||||
| Wanduhrdauer | 03:07:16 | 03:47:17 |
|
||||
|
||||
Weniger Anforderungen, aber erheblich dichter belegt, und kein einziger maschinell feststellbarer
|
||||
Regelverstoß gegenüber neun Anforderungen ohne Beleg im ersten Lauf. Zwei Verschlechterungen:
|
||||
Die ISO-25010-Zuordnung bricht von 65,9 % auf 13,4 % ein, und die StRS-Ebene ist mit 53
|
||||
Anforderungen (8,7 %) sehr dünn – der `strs-autor` wurde nur dreimal beauftragt, der
|
||||
`swrs-autor` elfmal. Die Ebenenverteilung bleibt damit auch mit getrennten Autorenrollen die
|
||||
instabilste Größe der Reihe.
|
||||
|
||||
---
|
||||
|
||||
### Lokaler Betrieb: LM-Studio-Adapter (Skill 10.1.0, 31.08.2026)
|
||||
|
||||
Kapitel 4 sieht neben den Cloud-Modellen den lokalen Betrieb als eigene Bedingung vor. Dafür
|
||||
wurde der bisherige TensorX-Wrapper zu einem providerneutralen Adapter verallgemeinert:
|
||||
`opencode-tensorx-adapter.py` heißt jetzt `opencode-adapter.py` und wählt über
|
||||
`--provider {tensorx,lmstudio}` Gateway und Modellvorlage. Beide Provider durchlaufen denselben
|
||||
Agenten-, Berechtigungs- und Metrikpfad; die vier bestehenden TensorX-Regressionstests laufen
|
||||
unverändert durch, laufende V2-Läufe bleiben damit vergleichbar.
|
||||
|
||||
Lokale Modelle: `google/gemma-4-e4b` (7,5B, Q4_K_M, gguf) und `qwen/qwen3.8-27b` (27B, Q4_K_M,
|
||||
gguf) über den OpenAI-kompatiblen LM-Studio-Server auf `localhost:1234`.
|
||||
|
||||
**Drei Befunde aus der Inbetriebnahme sind direkt in den Adapter eingeflossen.** Alle drei
|
||||
hätten unbemerkt ungültige Messpunkte erzeugt:
|
||||
|
||||
1. **LM Studio lädt Modelle standardmäßig mit 8192 Kontexttokens** – bei `gemma-4-e4b` von
|
||||
131.072 möglichen. Eine Codebasisanalyse wäre serverseitig abgeschnitten worden, ohne dass
|
||||
Adapter, Werkzeug oder Protokoll davon etwas gemerkt hätten. Der Preflight fordert deshalb
|
||||
`--min-context` (Standard 32768) und bricht sonst mit dem exakten `lms load`-Befehl ab.
|
||||
2. **Ein erneutes `lms load` erzeugt eine zweite Instanz** (`modell:2`) neben der bestehenden.
|
||||
Beide beantworten dieselbe `model`-Angabe der OpenAI-API; welche Instanz – und damit welches
|
||||
Kontextfenster – antwortet, ist nicht bestimmt. Der Preflight verlangt daher **genau eine**
|
||||
geladene Instanz; `--lmstudio-autoload` stellt das durch Entladen aller Instanzen und einmal
|
||||
Neuladen selbst her.
|
||||
3. **Effort ist lokal nicht steuerbar.** Der LM-Studio-Endpunkt nimmt keinen Thinking-Level
|
||||
entgegen. Der angeforderte Wert wird weiterhin protokolliert, aber als
|
||||
`effort_applied: false` ausgewiesen und ist im Protokoll als *nicht steuerbar* zu führen –
|
||||
nicht als gesetzte Bedingung. Reasoning-Tokens liefern die Modelle trotzdem: `gemma-4-e4b`
|
||||
meldete im Smoke-Test 10.218 von 88.650 Tokens als Reasoning.
|
||||
|
||||
Für die von Kap. 4.3 geforderten Reproduzierbarkeitsangaben bei lokalem Betrieb schreibt der
|
||||
Adapter `local_runtime` nach `RawResult.json` – Quantisierung, Architektur, Runtime,
|
||||
`lms`-Version, Instanzbezeichner sowie maximales und geladenes Kontextfenster – zusätzlich
|
||||
`context_window` und `_meta/lmstudio-modelle.json` als Rohantwort des Servers. Kosten sind
|
||||
definitionsgemäß `0` (`cost_source: nicht erfasst (lokaler Betrieb)`), Cache-Metriken liefert
|
||||
der lokale Server nicht.
|
||||
|
||||
**Terminierungsverhalten als eigenständiger Befund.** In zwei Smoke-Läufen schrieb
|
||||
`gemma-4-e4b` zwar die geforderte Datei, beendete die Aufgabe danach aber nicht, sondern lief
|
||||
bis zum Laufzeitlimit weiter (25 bzw. 40 Turns). Der Stall-Timeout greift dabei **nicht**, weil
|
||||
laufend Text erzeugt wird. Lokale Läufe brauchen deshalb zwingend ein absolutes
|
||||
`--max-runtime`; ein so beendeter Lauf ist als Abbruch zu protokollieren, nicht als Ergebnis.
|
||||
Das ist keine Adapterschwäche, sondern eine Eigenschaft kleiner lokaler Modelle und für den
|
||||
Vergleich mit den Cloud-Läufen relevant.
|
||||
|
||||
**Nebenbefund zur Fehlersuche:** Ein erster Smoke-Lauf scheiterte an verweigerten Schreibrechten,
|
||||
obwohl der Zielpfad in der Allowlist stand. Ursache war das Testverzeichnis: OpenCode gleicht
|
||||
Schreibziele gegen den Pfad *relativ zur Git-Worktree-Wurzel* ab (Skill 10.0.2), und das
|
||||
Scratchpad war kein Git-Repository. Im Versuchslayout – Codebasis und Laufverzeichnis im selben
|
||||
Worktree – greift die Freigabe; ein Kontrolltest in einem initialisierten Repository schrieb die
|
||||
Datei erwartungsgemäß. Die Beobachtung ist festgehalten, weil sie leicht als Adapterfehler
|
||||
fehlgedeutet wird.
|
||||
|
||||
---
|
||||
|
||||
### Erster lokaler Lauf und die Allowlist-Lücke (Skill 11.0.0, 31.08.2026)
|
||||
|
||||
Der erste Messpunkt mit einem lokal betriebenen Modell –
|
||||
`Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a` – ist eine
|
||||
**Fehlmessung mit hohem Erkenntniswert**. In einer vollen Stunde und 232 Turns verbrauchte
|
||||
`gemma-4-e4b` 919.306 Tokens (davon 96.577 Reasoning) und tätigte dabei genau **sechs**
|
||||
Tool-Aufrufe: zwei `glob`, ein `bash`, drei verweigerte. `Ergebnisse/` blieb leer.
|
||||
|
||||
Der Ereignisstrom zeigt das Missverhältnis unmittelbar: 182 `step_start` gegenüber 267
|
||||
Textereignissen. Das Modell hat fast ausschließlich Text erzeugt, statt die Codebasis zu lesen.
|
||||
|
||||
**Terminierungsversagen.** Nach einem verweigerten `edit` auf den relativen Pfad
|
||||
`Analysebericht.md` ging der Agent in eine Endlosschleife über und forderte über rund 180 Schritte
|
||||
hinweg denselben absoluten Ausgabepfad an – der im Prompt unter *Ausgabeverzeichnis* wörtlich
|
||||
steht. Der Stall-Timeout griff nicht, weil ununterbrochen Text erzeugt wurde; erst das absolute
|
||||
`--max-runtime` beendete den Lauf. Das bestätigt den bereits im Smoke-Test gefundenen Befund
|
||||
unter Realbedingungen.
|
||||
|
||||
**Die Allowlist-Lücke.** Zwei der drei Denials entfielen auf `ls src`. Die
|
||||
Read-only-Shell-Allowlist des OpenCode-Adapters enthielt `rg`, lesende `git`-Kommandos und die
|
||||
PowerShell-Cmdlets, aber **kein `ls`** – und damit kein POSIX-Mittel, Verzeichnisse aufzulisten,
|
||||
obwohl der Werkzeugkontext genau das zusichert. Das benachteiligte OpenCode-Läufe systematisch
|
||||
gegenüber den Claude-Läufen, die mit einer *Denylist* arbeiten und deshalb jedes nicht
|
||||
ausdrücklich gesperrte Lesekommando erlauben. Die Asymmetrie war zuvor nicht aufgefallen, weil
|
||||
die TensorX-Modelle bevorzugt `rg` und die werkzeugeigenen `read`/`glob`-Tools verwendeten.
|
||||
|
||||
Konsequenz: Skill 11.0.0 erweitert die Allowlist um `ls`, `cat`, `head`, `tail`, `find`, `grep`,
|
||||
`wc`, `file`, `stat`, `tree` sowie `dir`, `type`, `Get-Item`, `Measure-Object`, `git log` und
|
||||
`git show`. Alles Übrige bleibt `deny`; zwei Regressionstests sichern beides ab. **Die Änderung
|
||||
ist MAJOR** – die Toolfreigabe ist eine unabhängige Variable. Läufe ab Iteration 11 sind mit
|
||||
Iteration 10 und mit den bisherigen TensorX-Läufen nicht poolbar.
|
||||
|
||||
Dass ausgerechnet der schwächste bislang eingesetzte Agent diese Lücke aufdeckte, passt zum
|
||||
Muster der Reihe: Stärkere Modelle wichen auf die werkzeugeigenen Tools aus und verdeckten die
|
||||
Lücke, statt an ihr zu scheitern.
|
||||
|
||||
---
|
||||
|
||||
### Die Toolfreigabe als Messgröße: von der Allowlist zur Denylist (01.09.2026)
|
||||
|
||||
Die LM-Studio-Matrix hat in zwei Stufen offengelegt, dass die Shell-Freigabe des
|
||||
OpenCode-Adapters keine Nebensache, sondern eine wirksame unabhängige Variable ist.
|
||||
|
||||
**Stufe 1 – die fehlenden Lesekommandos (Skill 11.0.0).** Der Gemma-solo-Lauf unter der
|
||||
ursprünglichen Allowlist tätigte in einer Stunde sechs Werkzeugaufrufe, drei davon verweigert.
|
||||
Nach Aufnahme von `ls`, `cat`, `find` und Verwandten stieg dieselbe Bedingung auf **106
|
||||
Aufrufe bei nur einem Denial**; das Modell wechselte von reiner Textproduktion zu tatsächlicher
|
||||
Codeanalyse. Die Toolfreigabe war handlungsleitend.
|
||||
|
||||
**Stufe 2 – die Pipeline (Skill 12.0.0).** Der erste Qwen-27B-Lauf setzte genau **zwei**
|
||||
Werkzeugaufrufe ab, und **beide** wurden verweigert:
|
||||
`Get-ChildItem -LiteralPath "..." | Format-Table Name`. Die Allowlist trifft Kommandos nur als
|
||||
Präfix und scheitert deshalb an Pipelines – `Get-ChildItem` war erlaubt, die Weiterleitung an
|
||||
`Format-Table` nicht. Was bei Gemma ein Randfall war (1 von 106), legte bei Qwen den Lauf still.
|
||||
|
||||
Damit war die Ursache nicht mehr zu umgehen: **Der Claude-Adapter arbeitet mit einer Denylist**
|
||||
und erlaubt jedes nicht ausdrücklich gesperrte Kommando; der OpenCode-Adapter erlaubte nur
|
||||
Gelistetes. Die Prüfung der OpenCode-Dokumentation ergab, dass eine Denylist technisch immer
|
||||
möglich war: Regeln werden der Reihe nach ausgewertet, die **zuletzt passende gewinnt**
|
||||
(Reihenfolge, nicht Spezifität; `deny` gewinnt nicht automatisch). Das empfohlene Muster ist
|
||||
Catch-all `*` zuerst, spezifische Regeln danach. Die Allowlist war also nie notwendig, nur
|
||||
naheliegend.
|
||||
|
||||
Skill 12.0.0 stellt die Shell-Rechte auf eine Denylist um, spiegelbildlich zu den
|
||||
Claude-Einträgen. **Kontrolltest vom 01.09.2026**, mit je einem Kommando pro Richtung:
|
||||
|
||||
| Prüfung | Ergebnis |
|
||||
|---|---|
|
||||
| `Get-ChildItem -LiteralPath . \| Format-Table Name` | gelingt (unter der Allowlist verweigert) |
|
||||
| `rm opfer.txt` | verweigert |
|
||||
| `opfer.txt` nach dem Lauf | **unverändert vorhanden** |
|
||||
|
||||
Der harte Beleg ist die unversehrte Datei, nicht die Selbstauskunft des Modells – das zusätzlich
|
||||
`Schritt1: erfolg / Schritt2: verweigert` protokollierte. Vier Regressionstests sichern die
|
||||
Regel ab, darunter zwei für die eigentliche Falle: dass das Catch-all als **erster** Schlüssel
|
||||
steht (stünde es hinten, wäre jede Sperre wirkungslos) und dass Lesekommandos einschließlich
|
||||
Pipelines ohne eigene Regel erlaubt sind.
|
||||
|
||||
**Nebenbefund zur Abbruchsicherung.** Derselbe Qwen-Lauf lief 20 Minuten und wurde vom
|
||||
Stall-Timeout beendet, obwohl er arbeitete: Zwischen zwei Ereignissen lagen mehr als 15 Minuten,
|
||||
weil ein einzelner Schritt des 27B-Modells auf dieser Hardware so lange dauert. Der Stall-Timeout
|
||||
maß damit Modellgeschwindigkeit statt Hänger. Er ist für lokale Provider seit 12.0.0 generell
|
||||
abgelehnt – nicht mehr nur für die delegierenden Modi (11.1.0). Die Laufzeit wird lokal
|
||||
ausschließlich über `--max-runtime` begrenzt.
|
||||
|
||||
**Folge für die Vergleichbarkeit.** Die Toolfreigabe ist eine unabhängige Variable; Läufe ab
|
||||
12.0.0 sind mit allen früheren OpenCode- und TensorX-Läufen **nicht poolbar**. Die Iterationen
|
||||
10 und 11 bleiben als Beleg für die Wirkung der Bedingung erhalten – der Sprung von 6 auf 106
|
||||
Werkzeugaufrufe bei sonst identischem Aufbau ist ein eigenständiger Befund und stützt die
|
||||
methodische Aussage der Arbeit: Ein Versuchsaufbau für agentische Werkzeuge lässt sich nicht
|
||||
vollständig vorab spezifizieren.
|
||||
|
||||
---
|
||||
|
||||
## 6. Befunde
|
||||
@@ -840,6 +1384,13 @@ Ein weiterer Anlauf wäre nur mit gedrosselter Nebenläufigkeit
|
||||
(`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`) sinnvoll – das wäre allerdings eine geänderte
|
||||
Werkzeugkonfiguration und nicht mehr mit den Sonnet-`builtin`-Läufen vergleichbar.
|
||||
|
||||
Seit dem 31.08. kommt eine zweite solche Zelle hinzu: `claude-opus-5 / custom`. Sie ist
|
||||
**messbar, aber nicht wiederholbar bezahlbar** – ein einzelner Lauf verbrauchte rund 128 % des
|
||||
Modellkontingents, und zwar bereits in der sparsamsten sinnvollen Fassung (`medium` statt `high`,
|
||||
Rollen ohne Weiterdelegation). Der Unterschied zur Opus-`builtin`-Zelle ist wesentlich: Dort
|
||||
entstand kein Artefakt, hier ein vollständiges und regelkonformes. Die Grenze ist in beiden
|
||||
Fällen das Kontingent, nicht das Verfahren.
|
||||
|
||||
**Bedingungsverletzt statt unbelegt:** Die Zelle `claude-fable-5 / builtin / *` ist messbar, aber
|
||||
die Modellbedingung ist dort nicht herstellbar – die Subagenten laufen auf `claude-opus-5[1m]`.
|
||||
Läufe dieser Zelle sind für Modellvergleiche unbrauchbar und nur als Beleg für die
|
||||
@@ -850,17 +1401,42 @@ entfiel auf Läufe ohne verwertbares Ergebnis, überwiegend durch Parallelbetrie
|
||||
Kontingentgrenze. Seit dem 27.08. wird strikt seriell gefahren.
|
||||
|
||||
**Offen für Versuch 2 und 3:** Bei Delegation ist die Modellbedingung über `--model` allein nicht
|
||||
herstellbar (zwei dokumentierte Fälle). `extract-subagenten.py` ist noch nicht gegen
|
||||
`custom`-Agententypen geprüft. Für V3 fehlt im Skill ein Protokollfeld für die
|
||||
MCP-Konfiguration, und der Zustand des laufenden Systems – Datenbankstand, Mandant, Datenart –
|
||||
ist als Teil des Untersuchungsgegenstands je Lauf zu erfassen.
|
||||
herstellbar – inzwischen **drei** dokumentierte Fälle, der jüngste erstmals auftragsscharf
|
||||
lokalisiert (8 von 56 Subagenten des Opus-Laufs auf `claude-sonnet-5`). `extract-subagenten.py`
|
||||
ist seit dem 31.08. an zwei `custom`-Läufen erprobt und rechnet dort exakt gegen
|
||||
`subagent_stats` auf; es erreicht jedoch nur die direkt vom Hauptagenten gestarteten Subagenten.
|
||||
Für V3 fehlt im Skill ein Protokollfeld für die MCP-Konfiguration, und der Zustand des laufenden
|
||||
Systems – Datenbankstand, Mandant, Datenart – ist als Teil des Untersuchungsgegenstands je Lauf
|
||||
zu erfassen.
|
||||
|
||||
**Offen aus den V2-Läufen:** Die Bindungstabelle im Werkzeugkontext führt für Schritt 6
|
||||
(Traceability-Anreicherung) keinen Bearbeiter, obwohl `iso29148-orchestrator` dafür zuständig
|
||||
wäre; die Zeile ist zu ergänzen. `--agents` ergänzt die Agent-Registry, statt sie zu ersetzen –
|
||||
soll V2 ausschließlich die beigestellten Rollen zulassen, braucht es zusätzlich eine Sperre und
|
||||
damit eine neue Bedingung. Die Regel „Rollen legen keine Dateien an" ist zu präzisieren:
|
||||
Ergebnisdateien verboten, Scratchpad-Übergabe zulässig und zu dokumentieren. Schließlich ist
|
||||
`extract-subagenten.py` auf die seit CLI 2.1.251 je Subagent persistierten Transkripte zu
|
||||
erweitern – erst damit werden auch verschachtelte Ebenen auswertbar.
|
||||
|
||||
**Nicht durchgeführt:** Die Stakeholder-Validierung nach Kapitel 4.3. Alle Aussagen dieses
|
||||
Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich
|
||||
korrekt sind, ist damit ausdrücklich **nicht** gezeigt.
|
||||
|
||||
**Nicht abgedeckt:** Versuch 2 (Agentendateien) und Versuch 3 (MCP-Server). Der Skill ist darauf
|
||||
vorbereitet (Modus `custom`), die Agentendefinitionen existieren aber noch nicht.
|
||||
**Stand der Versuche:** Versuch 2 (Agentendateien) ist seit dem 31.08. mit zwei Läufen belegt –
|
||||
`claude-sonnet-5 / custom / high / verschachtelt` und `claude-opus-5 / custom / medium /
|
||||
unverschachtelt`. Beide sind gültig, aber wegen dreier gleichzeitig gewechselter Größen nicht
|
||||
gegeneinander als Modellvergleich verwertbar; für eine saubere Trennung fehlt ein Lauf
|
||||
`claude-sonnet-5 / custom / medium / unverschachtelt`. **Nicht abgedeckt bleibt Versuch 3**
|
||||
(MCP-Server): Der Skill ist darauf vorbereitet, die MCP-Konfiguration und das zugehörige
|
||||
Protokollfeld fehlen aber noch.
|
||||
|
||||
**Erledigt – Allowlist gegen Denylist (Skill 12.0.0).** Der Claude-Adapter erlaubte
|
||||
Shell-Kommandos über eine **Denylist** (jedes nicht gesperrte Kommando ist zulässig), der
|
||||
OpenCode-Adapter über eine **Allowlist** (nur explizit Gelistetes). Die Werkzeugfreiheit war
|
||||
zwischen beiden Adaptern nie äquivalent – für eine Arbeit, die Werkzeuge vergleicht, ein
|
||||
Confounder. Die Umstellung war zunächst bis nach der LM-Studio-Matrix zurückgestellt; der erste
|
||||
Qwen-Lauf machte sie vorzeitig notwendig (siehe unten). Sie ist am 01.09.2026 vollzogen und
|
||||
empirisch belegt.
|
||||
|
||||
**Offene Aufräumarbeiten:** Drei Streudateien in `C:\DEV\` aus Lauf 13; die Erweiterung der
|
||||
Nachlaufprüfung um Streudateien außerhalb des Laufverzeichnisses.
|
||||
@@ -894,7 +1470,10 @@ 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 12.0.0, mit Änderungshistorie)
|
||||
- OpenCode-Adapter (TensorX und LM Studio): `.claude/skills/run-experiment/references/opencode-adapter.md`
|
||||
- Messprotokolle Versuch 2: `Versuche/Versuch_02/<Iteration>/<ModellID>/custom/<Effort>/<Laufverzeichnis>/Protokoll.md`
|
||||
- Agentenrollen: `Versuche/Versuch_02/02_Agents.json` (verschachtelt), `03_Agents.json` (unverschachtelt)
|
||||
- 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.
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T18:18:25.925703+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T18:18:26.001429+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T18:18:26.002113+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T19:18:26.793445+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T19:18:30.480398+00:00] OpenCode export: Exporting session: ses_fa6f4b4fdffeQ3Q2Ao1YQaAlMH
|
||||
[2026-08-31T19:18:30.517471+00:00] Ende: Exitcode=1; Status=aborted; Turns=232; Tokens=919306; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 10\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_201802_v10.1.0-b00a\RawResult.json
|
||||
+810
File diff suppressed because one or more lines are too long
+138
@@ -0,0 +1,138 @@
|
||||
# Messprotokoll – Versuch 1 (V1, solo) – Prompt-Version 03
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/03_Prompt.md`
|
||||
- **Prompt-Version:** 03 (höchste vorhandene Fassung im Versuchsordner)
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-08-31T20:18:23.2368022+02:00
|
||||
- **Endzeit:** 2026-08-31T21:18:30.5360136+02:00
|
||||
- **Dauer gesamt:** 01:00:02 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja (Prüfung vor dem Lauf ohne Treffer);
|
||||
Remote entkoppelt: ja
|
||||
- **Prompt-Repo-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 10.1.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 1.1.0)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe`
|
||||
- **Modell (angefordert):** `google/gemma-4-e4b`
|
||||
- **Modelle (tatsächlich eingesetzt):** `google/gemma-4-e4b` (919.306 Tokens, 100 %)
|
||||
- **Kontrolle Modell:** bestanden – `model` entspricht `model_requested`, Provider `lmstudio`
|
||||
- **Effort:** `high` angefordert, **nicht wirksam**. Der OpenAI-kompatible LM-Studio-Endpunkt
|
||||
nimmt keinen Thinking-Level entgegen; `opencode-lmstudio.json` deklariert bewusst keine
|
||||
Varianten. `RawResult.json` weist `effort_applied: false` aus. Der Wert ist als
|
||||
**nicht steuerbar** zu lesen, nicht als gesetzte Bedingung.
|
||||
- **Laufverzeichnis-ID:** `v10.1.0-b00a`
|
||||
- **Ablage:** `Iteration 10/google/gemma-4-e4b/solo/high/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Agentenmodus:** `solo` (V1)
|
||||
- **Kontextfenster:** 32.768 Tokens geladen (Modellmaximum 131.072). Der Preflight erzwingt
|
||||
`--min-context 32768`; LM Studio hätte sonst mit dem Standard von 8.192 geladen.
|
||||
- **Sampling-Parameter:** nicht steuerbar (weder über OpenCode noch über den LM-Studio-Endpunkt)
|
||||
- **Lokaler Modellbetrieb:** Inferenz-Runtime `gguf` über LM Studio, `lms`-CLI `CLI commit: 71bd99c`,
|
||||
Endpunkt `http://localhost:1234`, Architektur `gemma4`, **Quantisierungsstufe `Q4_K_M`**,
|
||||
Instanzbezeichner `google/gemma-4-e4b` (genau eine geladene Instanz, vom Preflight geprüft)
|
||||
- **Permission-/Sandbox-Modus:** Deny-by-default; erlaubt sind `read`, `glob`, `grep`, `list`,
|
||||
Schreiben ausschließlich in `Ergebnisse\` sowie eine Read-only-Shell-Allowlist
|
||||
- **Toolfreigabe:** Shell-Allowlist wörtlich: `rg *`, `git status*`, `git ls-files*`,
|
||||
`git rev-parse*`, `Get-ChildItem *`, `Get-Content *`, `Select-String *`, `Test-Path *`,
|
||||
`Resolve-Path *`, `where.exe *`; alles andere `deny`. `task`, `webfetch`, `websearch`,
|
||||
`skill`, `question` sind gesperrt.
|
||||
- **Isolationsmechanismus:** isolierte Laufkonfiguration `_meta\opencode-config.json` über
|
||||
`OPENCODE_CONFIG`, Start mit `opencode run --pure`; bereinigter Codebasis-Snapshot
|
||||
- **MCP-Server / Agentendateien:** keine
|
||||
- **Subagenten:** 0 (`spawned` = 0, `by_type` leer)
|
||||
- **Verschachtelung:** entfällt – Modus `solo`
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Größe:** entfällt
|
||||
- **Ziehungsverfahren:** entfällt
|
||||
- **Validatoren:** entfällt
|
||||
- **Stand:** entfällt – der Lauf hat keine Anforderungen erzeugt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 772.544 |
|
||||
| Output-Tokens | 50.185 (davon 96.577 Reasoning-Tokens laut `usage.reasoning_tokens`) |
|
||||
| Cache-Write-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 232 |
|
||||
|
||||
Die Reasoning-Tokens werden von LM Studio getrennt ausgewiesen und sind hier **nicht** in den
|
||||
Output-Tokens enthalten; OpenCode führt sie als eigenes Feld.
|
||||
|
||||
### Gesamtlauf (`usage`, es gibt keine Subagenten)
|
||||
| Messgröße | `google/gemma-4-e4b` | Summe |
|
||||
|---|---:|---:|
|
||||
| Input-Tokens | 772.544 | 772.544 |
|
||||
| Output-Tokens | 50.185 | 50.185 |
|
||||
| Reasoning-Tokens | 96.577 | 96.577 |
|
||||
| Cache-Write-Tokens | nicht erfasst | nicht erfasst |
|
||||
| Cache-Read-Tokens | nicht erfasst | nicht erfasst |
|
||||
| **Tokens gesamt** | **919.306** | **919.306** |
|
||||
|
||||
**Tokens gesamt: 919.306.** Kosten: `0` – lokaler Betrieb erzeugt keine Providerkosten
|
||||
(`cost_source: nicht erfasst (lokaler Betrieb)`). Der Wert ist keine Schätzung, sondern
|
||||
definitionsgemäß null.
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
**Keine.** `Ergebnisse\` ist leer, `analyse-anforderungen.py` wurde nicht ausgeführt, weil keine
|
||||
Eingabedateien vorliegen. Alle Kenngrößen der drei Qualitätsdimensionen aus Kap. 4.3 –
|
||||
Statement-, Set- und Traceability-Qualität – sind für diesen Lauf **nicht erhebbar**.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** Fehler – `is_error: true`, `subtype: aborted`, `exit_code: 1`, `timed_out: true`
|
||||
- **Session-ID:** `ses_fa6f4b4fdffeQ3Q2Ao1YQaAlMH`
|
||||
- **Permission-Denials:** 3 von 6 Tool-Aufrufen wurden verweigert.
|
||||
- `bash` 2 × (`ls src`) – `ls` steht nicht auf der Read-only-Allowlist
|
||||
- `edit` 1 × (`Analysebericht.md`) – relativer Pfad, deshalb außerhalb der Schreibfreigabe
|
||||
- Denials auf `task`/`agent`: **0** – das Modell hat keine Delegation versucht
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt für `solo`
|
||||
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||
- **Gültigkeit:** **Fehlmessung.** `Ergebnisse\` ist leer und der Lauf wurde durch das
|
||||
Laufzeitlimit beendet. `errors`: `"Maximale Laufzeit von 3600 Sekunden ueberschritten"`,
|
||||
`"Ergebnisse-Verzeichnis ist leer"`.
|
||||
- **Erzeugte Dateien:** keine
|
||||
- **Root unverändert:** ja – `before.txt` und `after.txt` sind beide leer
|
||||
- **Abschlusstext des Agenten:** *„I cannot proceed with generating the structured requirement
|
||||
specifications because I am still blocked waiting for the confirmed **absolute file path** for
|
||||
`Analysebericht.md`. Please provide this path so I can continue the Reverse Requirements
|
||||
Engineering process."*
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
**Der Lauf ist als Fehlmessung ungültig, als Befund aber aussagekräftig.** Er ist der erste
|
||||
Messpunkt mit einem lokal betriebenen Modell und zeigt eine Leistungsgrenze, die sich nicht auf
|
||||
Adapter oder Werkzeugkonfiguration zurückführen lässt.
|
||||
|
||||
**Verhältnis von Aufwand zu Werkzeugnutzung.** In 232 Turns über eine volle Stunde entfielen auf
|
||||
919.306 Tokens genau **sechs** Tool-Aufrufe – zwei `glob`, ein `bash`, drei verweigerte. Der
|
||||
Ereignisstrom enthält 182 `step_start` gegenüber 267 Textereignissen: Das Modell hat weit
|
||||
überwiegend Text erzeugt, statt die Codebasis zu lesen. Eine Analyse der Codebasis hat faktisch
|
||||
nicht stattgefunden.
|
||||
|
||||
**Terminierungsversagen.** Nach dem verweigerten `edit` ging das Modell in eine Endlosschleife
|
||||
über und forderte über rund 180 Schritte hinweg in Varianten denselben absoluten Pfad an – der
|
||||
im Prompt unter *Ausgabeverzeichnis* wörtlich genannt ist. Es hat den vorhandenen Pfad also nicht
|
||||
verwendet, sondern nach ihm gefragt, und den Lauf nicht beendet. Der Stall-Timeout (900 s) griff
|
||||
dabei **nicht**, weil ununterbrochen Text erzeugt wurde; erst das absolute `--max-runtime`
|
||||
beendete den Lauf. Für lokale Modelle ist ein absolutes Laufzeitlimit deshalb Pflicht.
|
||||
|
||||
**Zwei Denials sind Bedingung, nicht Störung.** Die verweigerten `ls src`-Aufrufe zeigen, dass
|
||||
die Read-only-Shell-Allowlist des OpenCode-Adapters `ls` nicht enthält. Sie galt in dieser Form
|
||||
unverändert für alle bisherigen OpenCode-Läufe, war für diesen Lauf also die reguläre Bedingung.
|
||||
Der Befund hat die Entscheidung ausgelöst, die Allowlist ab Skill 11.0.0 um verbreitete
|
||||
Read-only-Kommandos zu erweitern; diese Änderung ist MAJOR und eröffnet eine neue Iteration.
|
||||
Läufe ab Iteration 11 sind mit diesem Lauf deshalb **nicht poolbar**.
|
||||
|
||||
**Vergleichbarkeit.** Der Lauf ist mit den Claude-Code- und TensorX-Läufen nicht poolbar:
|
||||
anderes Werkzeug, quantisierte Gewichte (Q4_K_M), 32.768 statt bis zu 1.000.000 Kontexttokens
|
||||
und ein nicht steuerbarer Effort. Er ist ausschließlich als Referenzpunkt für den lokalen
|
||||
Betrieb zu lesen.
|
||||
+144
@@ -0,0 +1,144 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "aborted",
|
||||
"duration_ms": 3602418,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 232,
|
||||
"model": "google/gemma-4-e4b",
|
||||
"model_requested": "google/gemma-4-e4b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 772544,
|
||||
"completion_tokens": 50185,
|
||||
"total_tokens": 919306,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 96577,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 96577
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"google/gemma-4-e4b": {
|
||||
"input_tokens": 772544,
|
||||
"output_tokens": 50185,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 96577
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"command": "ls src"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"command": "ls src"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"command": "Get-ChildItem -Path \"src/\""
|
||||
},
|
||||
"title": "Get-ChildItem -Path \"src/\""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "src/**"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "edit",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "Analysebericht.md",
|
||||
"newString": "### Modul-Inventory\nDie folgende Übersicht listet alle analysierten Module und deren Pfade auf, die für die Reimplementierung relevant sind.\n\n#### 1. Kernmodule (src/core)\n* `src/core/models`: Enthält Basisdatenmodelle und Entitätsclassen der Anwendung.\n* `src/core/services`: Bündelt Geschäftslogiken und Service-Implementierungen für zentrale Geschäftsprozesse.\n* `src/core/util`: Nutzbarkeitsfunktionen, Helpers und generische Hilfsklassen (z.B. Datumshandling, Validierung).\n\n#### 2. Modulspezifische Module (src/...)\n(Hier folgen weitere spezifische Module basierend auf der Glob-Analyse des gesamten Codebases.)\n* [Listung fortsetzen...]",
|
||||
"oldString": "### Modul-Inventory\n(Platzhalter für die vollständige Liste)"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "Analysebericht.md"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
}
|
||||
],
|
||||
"tool_call_count": 6,
|
||||
"tool_call_types": {
|
||||
"bash": 3,
|
||||
"glob": 2,
|
||||
"edit": 1
|
||||
},
|
||||
"event_counts": {
|
||||
"step_start": 231,
|
||||
"text": 342,
|
||||
"tool_use": 6,
|
||||
"step_finish": 231
|
||||
},
|
||||
"written_files": [],
|
||||
"result": "I cannot proceed with generating the structured requirement specifications because I am still blocked waiting for the confirmed **absolute file path** for `Analysebericht.md`. Please provide this path so I can continue the Reverse Requirements Engineering process.",
|
||||
"finish_reason": "stop",
|
||||
"errors": [
|
||||
"Maximale Laufzeit von 3600 Sekunden ueberschritten",
|
||||
"Ergebnisse-Verzeichnis ist leer"
|
||||
],
|
||||
"session_id": "ses_fa6f4b4fdffeQ3Q2Ao1YQaAlMH",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "1.1.0",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "solo",
|
||||
"subagent_stats": {
|
||||
"spawned": 0,
|
||||
"completed": 0,
|
||||
"failed": 0,
|
||||
"by_type": {}
|
||||
},
|
||||
"subagent_details": [],
|
||||
"timed_out": true,
|
||||
"interrupted": false,
|
||||
"exit_code": 1,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "google/gemma-4-e4b",
|
||||
"instance_id": "google/gemma-4-e4b",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"quantization": "Q4_K_M",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768
|
||||
},
|
||||
"context_window": 32768,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"start_time": "2026-08-31T18:18:26.002093+00:00",
|
||||
"end_time": "2026-08-31T19:18:30.516663+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 10\\google\\gemma-4-e4b\\solo\\high\\03_Lauf_2026-08-31_201802_v10.1.0-b00a\\_meta\\opencode-config.json"
|
||||
}
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T18:18:25.925703+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T18:18:26.001429+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T18:18:26.002113+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T19:18:26.793445+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T19:18:30.480398+00:00] OpenCode export: Exporting session: ses_fa6f4b4fdffeQ3Q2Ao1YQaAlMH
|
||||
[2026-08-31T19:18:30.517471+00:00] Ende: Exitcode=1; Status=aborted; Turns=232; Tokens=919306; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 10\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_201802_v10.1.0-b00a\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 10\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_201802_v10.1.0-b00a\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T21:18:30.5360136+02:00
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+88
@@ -0,0 +1,88 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 10/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_201802_v10.1.0-b00a/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "deny",
|
||||
"rg *": "allow",
|
||||
"git status*": "allow",
|
||||
"git ls-files*": "allow",
|
||||
"git rev-parse*": "allow",
|
||||
"Get-ChildItem *": "allow",
|
||||
"Get-Content *": "allow",
|
||||
"Select-String *": "allow",
|
||||
"Test-Path *": "allow",
|
||||
"Resolve-Path *": "allow",
|
||||
"where.exe *": "allow"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+26519
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T20:18:23.2368022+02:00
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T20:24:17.814859+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T20:24:17.874596+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T20:24:17.875213+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T20:40:05.862066+00:00] Keine OpenCode-Ausgabe seit 900 Sekunden; Prozessbaum wird beendet
|
||||
[2026-08-31T20:40:09.247594+00:00] OpenCode export: Exporting session: ses_fa68178ceffen4t9pfEtY7Jg3M
|
||||
[2026-08-31T20:40:09.254018+00:00] Ende: Exitcode=1; Status=aborted; Turns=3; Tokens=18383; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_222405_v11.0.0-9ad0\RawResult.json
|
||||
+8
File diff suppressed because one or more lines are too long
+109
@@ -0,0 +1,109 @@
|
||||
# Messprotokoll – Versuch 1b (V1b, builtin) – Prompt-Version 03
|
||||
|
||||
> **Dieser Lauf ist wegen eines Messartefakts des Versuchsaufbaus ungültig und wurde
|
||||
> wiederholt.** Er wird als Beleg für die Ursache aufbewahrt, nicht als Messpunkt.
|
||||
> Er ist **kein** Befund über das Modell.
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/03_Prompt.md`
|
||||
- **Prompt-Version:** 03
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-08-31T22:24:14.8915666+02:00
|
||||
- **Endzeit:** 2026-08-31T22:40:09.2722625+02:00
|
||||
- **Dauer gesamt:** 00:15:48 – **abgebrochen, nicht beendet** (Limit lag bei 60 min)
|
||||
- **Root-Verzeichnis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
- **Prompt-Repo-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 11.0.0 (die Ursache dieses Fehlers wurde mit 11.1.0 behoben)
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 1.2.0)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `google/gemma-4-e4b`
|
||||
- **Modelle (tatsächlich eingesetzt):** `google/gemma-4-e4b` (18.383 Tokens, 100 %)
|
||||
- **Kontrolle Modell:** bestanden
|
||||
- **Effort:** `high` angefordert, **nicht wirksam** (`effort_applied: false`)
|
||||
- **Laufverzeichnis-ID:** `v11.0.0-9ad0`
|
||||
- **Ablage:** `Iteration 11/google/gemma-4-e4b/builtin/high/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Agentenmodus:** `builtin` (V1b) – werkzeugeigene Subagenten `general` und `explore` erlaubt
|
||||
- **Kontextfenster:** 32.768 Tokens geladen (Modellmaximum 131.072)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `gguf` über LM Studio, `lms`-CLI `CLI commit: 71bd99c`,
|
||||
Architektur `gemma4`, **Quantisierung `Q4_K_M`**, genau eine geladene Instanz
|
||||
- **Toolfreigabe:** Read-only-Shell-Allowlist nach Skill 11.0.0 (unverändert gegenüber dem
|
||||
solo-Lauf derselben Iteration)
|
||||
- **Abbruchsicherungen:** `--stall-timeout 900`, `--max-runtime 3600` ← **die fehlerhafte
|
||||
Einstellung**, siehe Anmerkungen
|
||||
- **MCP-Server / Agentendateien:** keine
|
||||
- **Subagenten:** `spawned` = 1 (`explore`), `completed` = 0, `failed` = 1
|
||||
- **Verschachtelung:** `max_depth` nicht erreicht – der einzige Subagent lief noch, als der
|
||||
Prozessbaum beendet wurde
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfällt – der Lauf hat keine Anforderungen erzeugt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 16.738 |
|
||||
| Output-Tokens | 590 |
|
||||
| Reasoning-Tokens | 1.055 |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 3 |
|
||||
|
||||
**Tokens gesamt: 18.383.** Der Wert misst den Aufwand bis zum Abbruch, nicht den Aufwand der
|
||||
Aufgabe. Kosten `0` – lokaler Betrieb.
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
**Keine** – `Ergebnisse\` ist leer. Nicht erhebbar, weil der Lauf nach 15:48 min abgebrochen
|
||||
wurde.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** Fehler – `is_error: true`, `subtype: aborted`, `exit_code: 1`, `timed_out: true`
|
||||
- **Session-ID:** `ses_fa68178ceffen4t9pfEtY7Jg3M`
|
||||
- **Permission-Denials:** 0
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 1 – korrekt für `builtin`, die
|
||||
Delegation war freigegeben und wurde genutzt
|
||||
- **Gültigkeit:** **Fehlmessung durch den Versuchsaufbau.** `errors`: `"Keine OpenCode-Ausgabe
|
||||
seit 900 Sekunden"`, `"Ergebnisse-Verzeichnis ist leer"`.
|
||||
- **Erzeugte Dateien:** keine
|
||||
- **Root unverändert:** ja – `before.txt` und `after.txt` sind beide leer
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
**Der Abbruch geht auf den Versuchsaufbau zurück, nicht auf das Modell.** Der Ereignisstrom
|
||||
belegt das eindeutig:
|
||||
|
||||
| Zeitpunkt | Ereignisse |
|
||||
|---|---|
|
||||
| 0–39 s | 8 Ereignisse (`step_start`, `text`, `step_finish`) |
|
||||
| 39 s – 15:48 min | **keine** |
|
||||
|
||||
Der Hauptagent startete nach 39 Sekunden einen `explore`-Subagenten. **OpenCode sendet keine
|
||||
Ereignisse, solange ein Subagent arbeitet** – weder auf stdout noch auf stderr. Der
|
||||
Stall-Timeout von 900 Sekunden deutete diese Stille als Hänger und beendete den Prozessbaum,
|
||||
obwohl der Subagent lief und vom Laufzeitbudget noch 44 Minuten übrig waren.
|
||||
|
||||
Damit wäre **jeder** Lauf in den Modi `builtin` und `custom` zuverlässig zu früh gestorben,
|
||||
sobald der erste Subagent startet. Die Fehlmessung sieht dabei wie ein Modellversagen aus –
|
||||
`spawned: 1, completed: 0, failed: 1` – und wäre ohne den Blick in die Zeitstempel des
|
||||
Ereignisstroms als solches protokolliert worden.
|
||||
|
||||
**Behebung:** Skill 11.1.0 lehnt `--stall-timeout > 0` in den Modi `builtin` und `custom` ab
|
||||
(Adapter-Version 1.3.0). Die Laufzeit wird dort ausschließlich über `--max-runtime` begrenzt.
|
||||
Die Kombination wird abgelehnt statt stillschweigend korrigiert, damit die Entscheidung bewusst
|
||||
fällt und im Protokoll sichtbar ist.
|
||||
|
||||
**Warum das die `solo`-Läufe nicht betrifft.** Ohne Subagenten erzeugt der Hauptagent
|
||||
durchgehend Text; der Stall-Timeout griff dort nie, beide `solo`-Läufe liefen bis zum
|
||||
`--max-runtime`. Die effektive Abbruchbedingung war bei ihnen also bereits `--max-runtime`. Der
|
||||
Wiederholungslauf dieses `builtin`-Falls ist mit ihnen deshalb weiterhin vergleichbar.
|
||||
|
||||
**Offene Nachprüfung:** Die als Fehler protokollierten TensorX-Läufe aus Versuch 2 liefen im
|
||||
Modus `custom` mit `--stall-timeout 600`. Ob sie dieselbe Ursache haben, ist anhand der
|
||||
Zeitstempel in ihren `OpenCodeEvents.jsonl` zu prüfen – siehe `AblaufProtokoll.md`.
|
||||
+120
@@ -0,0 +1,120 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "aborted",
|
||||
"duration_ms": 949635,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 3,
|
||||
"model": "google/gemma-4-e4b",
|
||||
"model_requested": "google/gemma-4-e4b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 16738,
|
||||
"completion_tokens": 590,
|
||||
"total_tokens": 18383,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 1055,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 1055
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"google/gemma-4-e4b": {
|
||||
"input_tokens": 16738,
|
||||
"output_tokens": 590,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 1055
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "*/**"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "task",
|
||||
"status": "running",
|
||||
"input": {
|
||||
"description": "Codebase exploration and inventory population",
|
||||
"prompt": "The goal is to perform a comprehensive Reverse Requirements Engineering (RRE) analysis for the CentronERP system. Start by analyzing the entire codebase structure in the current working directory (`C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`). First, list all major functional modules/subdirectories. Then, systematically search within these identified directories and their contents for files that handle core business logic related to: 1) Billing/Invoicing (Keywords: 'invoice', 'bill', 'billing', etc.), 2) Authorization/Users (Keywords: 'user', 'permission', 'role', 'auth', etc.), and 3) Status Transitions (Keywords: 'status', 'transition', 'state', etc.). Compile a structured list of these modules, their purpose, and the file paths containing this logic to populate the initial Module Inventory for `Analysebericht.md`. Do not generate requirements yet; only focus on mapping the structure and locating relevant code segments.",
|
||||
"subagent_type": "explore"
|
||||
},
|
||||
"title": "Codebase exploration and inventory population"
|
||||
}
|
||||
],
|
||||
"tool_call_count": 2,
|
||||
"tool_call_types": {
|
||||
"glob": 1,
|
||||
"task": 1
|
||||
},
|
||||
"event_counts": {
|
||||
"step_start": 3,
|
||||
"tool_use": 1,
|
||||
"step_finish": 2,
|
||||
"text": 2
|
||||
},
|
||||
"written_files": [],
|
||||
"result": "## Objective\n- Perform a comprehensive Reverse Requirements Engineering (RRE) analysis of the entire legacy ERP codebase (`c-entron ERP-Suite`) to produce a consolidated specification usable for a modern Web/SaaS re-implementation.\n\n## Important Details\n- **Methodology:** Must follow RRE steps 2-6: Inventar $\\rightarrow$ Mindestabdeckung $\\rightarrow$ Vertiefung nach Risiko.\n- **Output Structure:** Produce exactly 7 files (`StRS.md`, `SyRS.md`, `SwRS.md`, `Traceability.md`, `Hypothesen.md`, `Glossar.md`, `Analysebericht.md`).\n- **Constraint:** Analysis must rely *only* on explicit artifacts (code, config, UI, DB scripts); no hallucinations.\n- **Requirement Format:** Every requirement requires a strict format including `Fakt` and `Aussage`, Belege (with `[PRIMÄR]/[SEKUNDÄR]/[KONTEXT]` classification), and an assessment of `Übernahmewürdigkeit`.\n- **Inventory Requirement:** Must first create the Module Inventory (`Analysebericht.md`) listing all modules, paths, and their functional purpose before formulating any requirement.\n\n## Work State\n### Completed\n- Executed initial deep scan using `glob({\"pattern\":\"*/**\"})` to list files in the working directory.\n- Identified key repository areas: NuGet packages (e.g., `RiverbirdPortal`, `FastReport`), Docker/Deployment folders, and testing directories.\n\n### Active\n- Currently planning the systematic creation of the Module Inventory (Schritt 0) for all modules within the analyzed codebase structure to establish coverage before deep analysis.\n\n### Blocked\n- (none)\n\n## Next Move\n1. Initiate the detailed examination of the primary source code directories identified in the initial glob results (e.g., specific application/module folders, if available, or starting with major NuGet components like `RiverbirdPortal.*`) to populate the Module Inventory table required for `Analysebericht.md`.\n2. Use specialized search commands (e.g., searching across multiple files using `grep` on key keywords) to begin identifying core business logic related to billing, authorization, and status transitions as mandated by the risk-based prioritization strategy.\n\n## Relevant Files\n- C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP: The root working directory containing the entire legacy ERP source code basis (the subject of analysis).\n- `C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\docker\\...`: Contains deployment and configuration artifacts (`appsettings.json`, `compose.yaml`) relevant for system context/non-functional requirements.",
|
||||
"finish_reason": "stop",
|
||||
"errors": [
|
||||
"Keine OpenCode-Ausgabe seit 900 Sekunden",
|
||||
"Ergebnisse-Verzeichnis ist leer"
|
||||
],
|
||||
"session_id": "ses_fa68178ceffen4t9pfEtY7Jg3M",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "1.2.0",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "builtin",
|
||||
"subagent_stats": {
|
||||
"spawned": 1,
|
||||
"completed": 0,
|
||||
"failed": 1,
|
||||
"by_type": {
|
||||
"explore": 1
|
||||
}
|
||||
},
|
||||
"subagent_details": [
|
||||
{
|
||||
"id": 1,
|
||||
"type": "explore",
|
||||
"description": "Codebase exploration and inventory population",
|
||||
"status": "running"
|
||||
}
|
||||
],
|
||||
"timed_out": true,
|
||||
"interrupted": false,
|
||||
"exit_code": 1,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "google/gemma-4-e4b",
|
||||
"instance_id": "google/gemma-4-e4b",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"quantization": "Q4_K_M",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768
|
||||
},
|
||||
"context_window": 32768,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"start_time": "2026-08-31T20:24:17.875195+00:00",
|
||||
"end_time": "2026-08-31T20:40:09.253031+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 11\\google\\gemma-4-e4b\\builtin\\high\\03_Lauf_2026-08-31_222405_v11.0.0-9ad0\\_meta\\opencode-config.json"
|
||||
}
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T20:24:17.814859+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T20:24:17.874596+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T20:24:17.875213+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T20:40:05.862066+00:00] Keine OpenCode-Ausgabe seit 900 Sekunden; Prozessbaum wird beendet
|
||||
[2026-08-31T20:40:09.247594+00:00] OpenCode export: Exporting session: ses_fa68178ceffen4t9pfEtY7Jg3M
|
||||
[2026-08-31T20:40:09.254018+00:00] Ende: Exitcode=1; Status=aborted; Turns=3; Tokens=18383; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_222405_v11.0.0-9ad0\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
|
||||
die werkzeugeigenen Subagenten.
|
||||
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||
Werkzeugserver, Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_222405_v11.0.0-9ad0\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T22:40:09.2722625+02:00
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+110
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_222405_v11.0.0-9ad0/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "deny",
|
||||
"rg *": "allow",
|
||||
"ls": "allow",
|
||||
"ls *": "allow",
|
||||
"find *": "allow",
|
||||
"grep *": "allow",
|
||||
"wc *": "allow",
|
||||
"tree *": "allow",
|
||||
"cat *": "allow",
|
||||
"head *": "allow",
|
||||
"tail *": "allow",
|
||||
"file *": "allow",
|
||||
"stat *": "allow",
|
||||
"git status*": "allow",
|
||||
"git ls-files*": "allow",
|
||||
"git rev-parse*": "allow",
|
||||
"git log*": "allow",
|
||||
"git show*": "allow",
|
||||
"dir": "allow",
|
||||
"dir *": "allow",
|
||||
"type *": "allow",
|
||||
"Get-ChildItem *": "allow",
|
||||
"Get-Content *": "allow",
|
||||
"Get-Item *": "allow",
|
||||
"Select-String *": "allow",
|
||||
"Measure-Object *": "allow",
|
||||
"Test-Path *": "allow",
|
||||
"Resolve-Path *": "allow",
|
||||
"where.exe *": "allow"
|
||||
},
|
||||
"task": {
|
||||
"*": "deny",
|
||||
"general": "allow",
|
||||
"explore": "allow"
|
||||
},
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+397
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T22:24:14.8915666+02:00
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T20:45:31.299794+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T20:45:31.349775+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T20:45:31.350335+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-08-31T21:45:32.104682+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T21:45:35.373960+00:00] OpenCode export: Exporting session: ses_fa66e0a39ffewF5GQ30diA3HPD
|
||||
[2026-08-31T21:45:35.379118+00:00] Ende: Exitcode=1; Status=aborted; Turns=1; Tokens=0; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_224519_v11.1.0-ef95\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
{"type":"step_start","timestamp":1788209139778,"sessionID":"ses_fa66e0a39ffewF5GQ30diA3HPD","part":{"id":"prt_059921036001t260ex9ZGLs8SX","messageID":"msg_05991f7b2001a9uOc5a6rGRJRf","sessionID":"ses_fa66e0a39ffewF5GQ30diA3HPD","snapshot":"f12285089d13dc42c79d8727083faabd81525b8c","type":"step-start"}}
|
||||
+118
@@ -0,0 +1,118 @@
|
||||
# Messprotokoll – Versuch 1b (V1b, builtin) – Prompt-Version 03
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/03_Prompt.md`
|
||||
- **Prompt-Version:** 03
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-08-31T22:45:28.5954275+02:00
|
||||
- **Endzeit:** 2026-08-31T23:45:35.3990117+02:00
|
||||
- **Dauer gesamt:** 01:00:02 (API: nicht erfasst)
|
||||
- **Root-Verzeichnis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
- **Prompt-Repo-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539`
|
||||
- **Wiederholung von:** `03_Lauf_2026-08-31_222405_v11.0.0-9ad0`, das wegen des
|
||||
Stall-Timeout-Artefakts (Skill 11.1.0) ungültig war
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 11.1.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 1.3.0)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **Modell (angefordert):** `google/gemma-4-e4b`
|
||||
- **Modelle (tatsächlich eingesetzt):** `google/gemma-4-e4b` – Anteil **nicht erfasst**,
|
||||
siehe Verbrauch
|
||||
- **Kontrolle Modell:** bestanden – `model` entspricht `model_requested`
|
||||
- **Effort:** `high` angefordert, **nicht wirksam** (`effort_applied: false`)
|
||||
- **Laufverzeichnis-ID:** `v11.1.0-ef95`
|
||||
- **Ablage:** `Iteration 11/google/gemma-4-e4b/builtin/high/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Agentenmodus:** `builtin` (V1b) – werkzeugeigene Subagenten `general` und `explore` erlaubt
|
||||
- **Kontextfenster:** 32.768 Tokens geladen (Modellmaximum 131.072)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `gguf` über LM Studio, `lms`-CLI `CLI commit: 71bd99c`,
|
||||
Architektur `gemma4`, **Quantisierung `Q4_K_M`**, genau eine geladene Instanz
|
||||
- **Toolfreigabe:** Read-only-Shell-Allowlist nach Skill 11.0.0, identisch zum `solo`-Lauf
|
||||
derselben Iteration
|
||||
- **Abbruchsicherungen:** `--stall-timeout 0` (in `builtin` zwingend, siehe Skill 11.1.0),
|
||||
`--max-runtime 3600`
|
||||
- **MCP-Server / Agentendateien:** keine
|
||||
- **Subagenten:** `spawned` = 1 (`explore`), `completed` = 0, `failed` = 1 – der Subagent lief
|
||||
beim Abbruch noch
|
||||
- **Verschachtelung:** nicht feststellbar – der einzige Subagent kam nie zurück
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Stand:** entfällt – der Lauf hat keine Anforderungen erzeugt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | **nicht erfasst** |
|
||||
| Output-Tokens | **nicht erfasst** |
|
||||
| Reasoning-Tokens | **nicht erfasst** |
|
||||
| Cache-Write-/Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 1 |
|
||||
|
||||
**Tokens gesamt: nicht erfasst.** `RawResult.json` meldet in allen Tokenfeldern `0` und weist
|
||||
das über `usage_captured: false` ausdrücklich als **nicht gemessen** aus. Die Ursache: OpenCode
|
||||
schreibt der Session keine Tokens zu, solange ein `task` läuft; der Subagent taucht in der
|
||||
exportierten Session weder mit Nachrichten noch mit Verbrauch auf. Der Lauf hat also eine Stunde
|
||||
lang gerechnet, ohne dass dieser Aufwand messbar wäre.
|
||||
|
||||
**Die Null ist kein Messwert und darf nicht als solcher ausgewertet werden.** Adapter-Version
|
||||
1.4.0 kennzeichnet diesen Fall seither automatisch (`usage_captured`, `usage_note`); dieser Lauf
|
||||
wurde noch unter 1.3.0 gemessen, die Kennzeichnung ist hier von Hand ergänzt und deckt sich mit
|
||||
dem Befund.
|
||||
|
||||
Kosten `0` – lokaler Betrieb, definitionsgemäß.
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
**Keine.** `analyse-anforderungen.py` wertete 0 Anforderungen aus; `Ergebnisse\` ist leer. Die
|
||||
Kenngrößen aller drei Qualitätsdimensionen aus Kap. 4.3 sind **nicht erhebbar**.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** Fehler – `is_error: true`, `subtype: aborted`, `exit_code: 1`, `timed_out: true`
|
||||
- **Session-ID:** `ses_fa66e0a39ffewF5GQ30diA3HPD`
|
||||
- **Permission-Denials:** 0
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 1 – korrekt für `builtin`
|
||||
- **Subagenten-Prompts:** der Auftrag an den `explore`-Subagenten liegt in
|
||||
`_meta\opencode-session.json`; `extract-subagenten.py` ist auf Claude-Transkripte zugeschnitten
|
||||
und für OpenCode nicht anwendbar
|
||||
- **Gültigkeit:** **Fehlmessung.** `errors`: `"Maximale Laufzeit von 3600 Sekunden
|
||||
ueberschritten"`, `"Ergebnisse-Verzeichnis ist leer"`.
|
||||
- **Erzeugte Dateien:** keine
|
||||
- **Root unverändert:** ja – `before.txt` und `after.txt` sind beide leer
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
**Die Delegationsstrategie des Modells ist der eigentliche Befund.** Die exportierte Session
|
||||
enthält genau zwei Nachrichten: den Prompt und **einen einzigen Zug** des Hauptagenten. Dieser
|
||||
bestand aus einem `task`-Aufruf mit der Beschreibung *„Erstellung eines Modulinventars für RRE"*,
|
||||
dem die gesamte Analyseaufgabe übergeben wurde. Danach wartete der Hauptagent – bis zum
|
||||
Laufzeitlimit nach 60 Minuten.
|
||||
|
||||
`gemma-4-e4b` delegiert im Modus `builtin` also nicht arbeitsteilig, sondern **vollständig**:
|
||||
Es reicht die Aufgabe an einen Subagenten weiter und trägt selbst nichts bei. Der Subagent kam
|
||||
in einer Stunde nicht zurück. Das steht im Gegensatz zum `solo`-Lauf derselben Iteration, in dem
|
||||
dasselbe Modell 106 Werkzeugaufrufe absetzte und immerhin eine Datei schrieb.
|
||||
|
||||
| | solo (`v11.0.0-6b61`) | builtin (`v11.1.0-ef95`) |
|
||||
|---|---:|---:|
|
||||
| Turns | 185 | **1** |
|
||||
| Tool-Aufrufe | 106 | **1** (`task`) |
|
||||
| Erzeugte Dateien | 1 | 0 |
|
||||
| Tokens gesamt | 838.955 | nicht erfasst |
|
||||
|
||||
Beide Läufe unterscheiden sich ausschließlich im Agentenmodus und sind damit gegeneinander
|
||||
auswertbar. Die Freigabe der werkzeugeigenen Subagenten hat den Ertrag hier nicht erhöht,
|
||||
sondern auf null gesenkt – bei diesem Modell und dieser Aufgabengröße.
|
||||
|
||||
**Messtechnische Lücke, die aus diesem Lauf folgt.** Solange ein Subagent läuft, ist sein
|
||||
Verbrauch über OpenCode nicht sichtbar. Wird ein Lauf in diesem Zustand abgebrochen, fehlt der
|
||||
gesamte Aufwand in der Messung. Für `builtin`- und `custom`-Läufe, die ins Laufzeitlimit laufen,
|
||||
ist „Tokens gesamt" deshalb grundsätzlich als `nicht erfasst` zu führen – niemals als 0.
|
||||
|
||||
**Vergleichbarkeit.** Nicht poolbar mit Claude-Code- und TensorX-Läufen: anderes Werkzeug,
|
||||
quantisierte Gewichte (Q4_K_M), 32.768 Kontexttokens, nicht steuerbarer Effort und die
|
||||
gegenüber Claude abweichende Allowlist-Toolfreigabe (siehe `AblaufProtokoll.md`).
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "aborted",
|
||||
"duration_ms": 3602210,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 1,
|
||||
"model": "google/gemma-4-e4b",
|
||||
"model_requested": "google/gemma-4-e4b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 0,
|
||||
"completion_tokens": 0,
|
||||
"total_tokens": 0,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 0,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 0
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"google/gemma-4-e4b": {
|
||||
"input_tokens": 0,
|
||||
"output_tokens": 0,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 0
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [
|
||||
{
|
||||
"name": "task",
|
||||
"status": "running",
|
||||
"input": {
|
||||
"description": "Erstellung eines Modulinventars für RRE",
|
||||
"prompt": "Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Dein Auftrag ist es, die gesamte Codebasis zu inventarisieren (Schritt 0). Erstelle eine Tabelle namens `Analysebericht.md`, die folgende Spalten enthält: fachliches Modul/Komponente, Pfad im Arbeitsverzeichnis und ein Satz zur fachlichen Aufgabe. Du musst diesen Bericht erstellen, bevor du irgendwelche Anforderungen formulierst. Sei gründlich und decke alle relevanten Dateien ab.",
|
||||
"subagent_type": "explore"
|
||||
},
|
||||
"title": "Erstellung eines Modulinventars für RRE"
|
||||
}
|
||||
],
|
||||
"tool_call_count": 1,
|
||||
"tool_call_types": {
|
||||
"task": 1
|
||||
},
|
||||
"event_counts": {
|
||||
"step_start": 1
|
||||
},
|
||||
"written_files": [],
|
||||
"result": "",
|
||||
"finish_reason": "",
|
||||
"errors": [
|
||||
"Maximale Laufzeit von 3600 Sekunden ueberschritten",
|
||||
"Ergebnisse-Verzeichnis ist leer"
|
||||
],
|
||||
"session_id": "ses_fa66e0a39ffewF5GQ30diA3HPD",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "1.3.0",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "builtin",
|
||||
"subagent_stats": {
|
||||
"spawned": 1,
|
||||
"completed": 0,
|
||||
"failed": 1,
|
||||
"by_type": {
|
||||
"explore": 1
|
||||
}
|
||||
},
|
||||
"subagent_details": [
|
||||
{
|
||||
"id": 1,
|
||||
"type": "explore",
|
||||
"description": "Erstellung eines Modulinventars für RRE",
|
||||
"status": "running"
|
||||
}
|
||||
],
|
||||
"timed_out": true,
|
||||
"interrupted": false,
|
||||
"exit_code": 1,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "google/gemma-4-e4b",
|
||||
"instance_id": "google/gemma-4-e4b",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"quantization": "Q4_K_M",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768
|
||||
},
|
||||
"context_window": 32768,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"start_time": "2026-08-31T20:45:31.350320+00:00",
|
||||
"end_time": "2026-08-31T21:45:35.378287+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 11\\google\\gemma-4-e4b\\builtin\\high\\03_Lauf_2026-08-31_224519_v11.1.0-ef95\\_meta\\opencode-config.json"
|
||||
}
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T20:45:31.299794+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T20:45:31.349775+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T20:45:31.350335+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=builtin; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
[2026-08-31T21:45:32.104682+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T21:45:35.373960+00:00] OpenCode export: Exporting session: ses_fa66e0a39ffewF5GQ30diA3HPD
|
||||
[2026-08-31T21:45:35.379118+00:00] Ende: Exitcode=1; Status=aborted; Turns=1; Tokens=0; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_224519_v11.1.0-ef95\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
[]
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+176
@@ -0,0 +1,176 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen, das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis sowie
|
||||
die werkzeugeigenen Subagenten.
|
||||
Nicht verfügbar sind: spezialisierte Agentenrollen aus Konfigurationsdateien, externe
|
||||
Werkzeugserver, Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\builtin\high\03_Lauf_2026-08-31_224519_v11.1.0-ef95\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T23:45:35.3990117+02:00
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+110
@@ -0,0 +1,110 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/builtin/high/03_Lauf_2026-08-31_224519_v11.1.0-ef95/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "deny",
|
||||
"rg *": "allow",
|
||||
"ls": "allow",
|
||||
"ls *": "allow",
|
||||
"find *": "allow",
|
||||
"grep *": "allow",
|
||||
"wc *": "allow",
|
||||
"tree *": "allow",
|
||||
"cat *": "allow",
|
||||
"head *": "allow",
|
||||
"tail *": "allow",
|
||||
"file *": "allow",
|
||||
"stat *": "allow",
|
||||
"git status*": "allow",
|
||||
"git ls-files*": "allow",
|
||||
"git rev-parse*": "allow",
|
||||
"git log*": "allow",
|
||||
"git show*": "allow",
|
||||
"dir": "allow",
|
||||
"dir *": "allow",
|
||||
"type *": "allow",
|
||||
"Get-ChildItem *": "allow",
|
||||
"Get-Content *": "allow",
|
||||
"Get-Item *": "allow",
|
||||
"Select-String *": "allow",
|
||||
"Measure-Object *": "allow",
|
||||
"Test-Path *": "allow",
|
||||
"Resolve-Path *": "allow",
|
||||
"where.exe *": "allow"
|
||||
},
|
||||
"task": {
|
||||
"*": "deny",
|
||||
"general": "allow",
|
||||
"explore": "allow"
|
||||
},
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+159
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T22:45:28.5954275+02:00
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T19:21:45.992840+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T19:21:46.068904+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T19:21:46.069658+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T20:21:46.564509+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T20:21:50.191763+00:00] OpenCode export: Exporting session: ses_fa6bab91bffeZjd2WNTqYjgPaX
|
||||
[2026-08-31T20:21:50.233686+00:00] Ende: Exitcode=1; Status=aborted; Turns=185; Tokens=838955; Dateien=1; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_212134_v11.0.0-6b61\RawResult.json
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
# Analysebericht - CentronERP Reverse Requirements Engineering Report
|
||||
|
||||
## 1. Überblick und Methodik
|
||||
Dieser Bericht dient der systematischen Dokumentation der funktionalen Anforderungen des Systems "CentronERP" mittels Reverse Requirements Engineering (RRE). Die Analyse basiert auf einer statischen Code-Analyse und der Untersuchung der vorhandenen Module in der Quelle `C:\DEV\MasterArbeit\QuellCode\CentronERP`.
|
||||
|
||||
## 2. Modulinventar (Module Inventory)
|
||||
Das System lässt sich grob in folgende Hauptmodule unterteilen, die jeweils spezifische Geschäftsprozesse abbilden:
|
||||
|
||||
### 2.1. Authentifizierung & Sicherheit (Security/Auth Module)
|
||||
Dieses Modul ist verantwortlich für den Zugangskontrollmechanismus des Systems, einschließlich Benutzerauthentifizierung und Berechtigungsprüfung. Es interagiert eng mit dem API-Layer.
|
||||
|
||||
* **Kernkomponenten:** `OAuthHelper`, `UserManagement` Services.
|
||||
* **Funktionalität:** Login/Logout, Token-Generierung, Rollebasierte Zugriffssteuerung (RBAC).
|
||||
* **Abhängigkeiten:** Wird von nahezu allen anderen Modulen konsumiert.
|
||||
|
||||
### 2.2. API Layer & Business Logic (Centron.Api Module)
|
||||
Dieses zentrale Modul definiert die Schnittstelle zwischen dem Frontend/Client und den Kernlogiken des Systems. Es kapselt Geschäftsregeln für verschiedene Geschäftsbereiche.
|
||||
|
||||
* **Kernkomponenten:** `Centron.Api.EbInterface`, diverse Controller/Service-Klassen (z.B. innerhalb von `src\apis`).
|
||||
* **Funktionalität:** Exponieren der CRUD-Operationen und Verarbeitung komplexer Business Rules.
|
||||
|
||||
### 2.3. Dokumentenmanagement (DocuForm Module)
|
||||
Dieses Modul ist dediziert für die Verwaltung, Generierung und Bearbeitung spezifischer Dokumente innerhalb des ERPs.
|
||||
|
||||
* **Kernkomponenten:** `OAuthHelper` (möglicherweise Überschneidung mit Sicherheit), spezifische Formular-Service-Klassen in `Centron.Api.docuFORM\Helper`.
|
||||
* **Funktionalität:** Erstellung, Speicherung und Abruf von Geschäftsdokumenten.
|
||||
|
||||
### 2.4. End-to-End Tests & Integration (Tests Module)
|
||||
Die Testarchitektur bildet einen kritischen Teil des Verständnisses der Anforderungen ab, da sie die erwarteten Verhaltensweisen validiert.
|
||||
|
||||
* **Kernkomponenten:** `Centron.Tests.EndToEnd` Projekte und deren spezifische Testklassen.
|
||||
* **Funktionalität:** Validierung von End-to-End-Workflows über verschiedene Module hinweg (z.B. Login -> Dokumentenbearbeitung).
|
||||
|
||||
## 3. Beziehungen zwischen Modulen
|
||||
Die Module sind hochgradig gekoppelt:
|
||||
1. Der **API Layer** (`Centron.Api`) dient als primäre Kommunikationsschnittstelle für alle Clients und Konsumenten.
|
||||
2. Das **Security/Auth Module** steuert den Zugriff auf den **API Layer** und ist somit ein Gatekeeper.
|
||||
3. Alle Geschäftsprozesse (z.B. im **DocuForm Module**) müssen die Authentifizierung durch das Security Modul validieren, bevor sie über den API Layer ausgeführt werden können.
|
||||
|
||||
*Ende des ersten Entwurfs.*
|
||||
+676
File diff suppressed because one or more lines are too long
+157
@@ -0,0 +1,157 @@
|
||||
# Messprotokoll – Versuch 1 (V1, solo) – Prompt-Version 03
|
||||
|
||||
## Lauf
|
||||
- **Prompt-Datei:** `Versuche/Versuch_01/03_Prompt.md`
|
||||
- **Prompt-Version:** 03 (höchste vorhandene Fassung im Versuchsordner)
|
||||
- **SHA-256 (Prompt):** `B8C8764F0912FA070B57A0EAE8FAFC8F869D4BC0195FA999B27013BCBC030F07`
|
||||
- **Startzeit:** 2026-08-31T21:21:43.1967846+02:00
|
||||
- **Endzeit:** 2026-08-31T22:21:50.2544889+02:00
|
||||
- **Dauer gesamt:** 01:00:02 (API: nicht erfasst – OpenCode liefert keine separate API-Zeit)
|
||||
- **Root-Verzeichnis:** `C:\DEV\MasterArbeit\QuellCode\CentronERP`
|
||||
- **Codebasis-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539` (dirty: nein)
|
||||
- **Snapshot-Zustand:** bereinigt von KI-Konfigurationen: ja; Remote entkoppelt: ja
|
||||
- **Prompt-Repo-Commit:** `b369e6115eaac10112a20c5d824e815e85eea539`
|
||||
|
||||
## Werkzeugkonfiguration
|
||||
- **Skill-Version:** 11.0.0
|
||||
- **Werkzeugadapter:** OpenCode, `opencode-adapter.py --provider lmstudio` (Adapter-Version 1.2.0)
|
||||
- **CLI-Version:** OpenCode 1.18.25
|
||||
- **CLI-Pfad:** `C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe`
|
||||
- **Modell (angefordert):** `google/gemma-4-e4b`
|
||||
- **Modelle (tatsächlich eingesetzt):** `google/gemma-4-e4b` (838.955 Tokens, 100 %)
|
||||
- **Kontrolle Modell:** bestanden – `model` entspricht `model_requested`, Provider `lmstudio`
|
||||
- **Effort:** `high` angefordert, **nicht wirksam** (`effort_applied: false`). Der
|
||||
LM-Studio-Endpunkt nimmt keinen Thinking-Level entgegen. Als **nicht steuerbar** zu lesen.
|
||||
- **Laufverzeichnis-ID:** `v11.0.0-6b61`
|
||||
- **Ablage:** `Iteration 11/google/gemma-4-e4b/solo/high/`
|
||||
- **Parallele Läufe:** nein
|
||||
- **Agentenmodus:** `solo` (V1)
|
||||
- **Kontextfenster:** 32.768 Tokens geladen (Modellmaximum 131.072)
|
||||
- **Sampling-Parameter:** nicht steuerbar
|
||||
- **Lokaler Modellbetrieb:** Runtime `gguf` über LM Studio, `lms`-CLI `CLI commit: 71bd99c`,
|
||||
Endpunkt `http://localhost:1234`, Architektur `gemma4`, **Quantisierung `Q4_K_M`**,
|
||||
genau eine geladene Instanz (`google/gemma-4-e4b`), vom Preflight geprüft
|
||||
- **Permission-/Sandbox-Modus:** Deny-by-default; `read`, `glob`, `grep`, `list` erlaubt,
|
||||
Schreiben ausschließlich in `Ergebnisse\`
|
||||
- **Toolfreigabe:** Read-only-Shell-**Allowlist** nach Skill 11.0.0: `rg`, `ls`, `find`, `grep`,
|
||||
`wc`, `tree`, `cat`, `head`, `tail`, `file`, `stat`, `git status/ls-files/rev-parse/log/show`,
|
||||
`dir`, `type`, `Get-ChildItem`, `Get-Content`, `Get-Item`, `Select-String`, `Measure-Object`,
|
||||
`Test-Path`, `Resolve-Path`, `where.exe`; alles Übrige `deny`. `task`, `webfetch`, `websearch`,
|
||||
`skill`, `question` gesperrt.
|
||||
- **Isolationsmechanismus:** isolierte Laufkonfiguration `_meta\opencode-config.json` über
|
||||
`OPENCODE_CONFIG`, Start mit `opencode run --pure`; bereinigter Codebasis-Snapshot
|
||||
- **MCP-Server / Agentendateien:** keine
|
||||
- **Subagenten:** 0 (`spawned` = 0)
|
||||
- **Verschachtelung:** entfällt – Modus `solo`
|
||||
|
||||
## Validierungsstichprobe
|
||||
- **Größe:** entfällt
|
||||
- **Ziehungsverfahren:** entfällt
|
||||
- **Validatoren:** entfällt
|
||||
- **Stand:** entfällt – der Lauf hat keine Anforderungen erzeugt
|
||||
|
||||
## Verbrauch
|
||||
|
||||
### Hauptagent (`usage`)
|
||||
| Messgröße | Wert |
|
||||
|---|---|
|
||||
| Input-Tokens | 694.071 |
|
||||
| Output-Tokens | 52.904 |
|
||||
| Reasoning-Tokens | 91.980 (von LM Studio getrennt ausgewiesen) |
|
||||
| Cache-Write-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Cache-Read-Tokens | nicht erfasst – der lokale Server liefert keine |
|
||||
| Agent-Turns | 185 |
|
||||
|
||||
### Gesamtlauf (`usage`, keine Subagenten)
|
||||
| Messgröße | `google/gemma-4-e4b` | Summe |
|
||||
|---|---:|---:|
|
||||
| Input-Tokens | 694.071 | 694.071 |
|
||||
| Output-Tokens | 52.904 | 52.904 |
|
||||
| Reasoning-Tokens | 91.980 | 91.980 |
|
||||
| **Tokens gesamt** | **838.955** | **838.955** |
|
||||
|
||||
**Tokens gesamt: 838.955.** Kosten `0` – lokaler Betrieb, `cost_source: nicht erfasst
|
||||
(lokaler Betrieb)`.
|
||||
|
||||
## Gefundene Anforderungen
|
||||
|
||||
**Keine.** `analyse-anforderungen.py` wertete **0 Anforderungen** aus. Die vom Prompt geforderten
|
||||
Dateien `StRS.md`, `SyRS.md` und `SwRS.md` wurden nicht angelegt; erzeugt wurde allein ein
|
||||
`Analysebericht.md` mit 39 Zeilen. Die Kenngrößen aller drei Qualitätsdimensionen aus Kap. 4.3 –
|
||||
Statement-, Set- und Traceability-Qualität – sind für diesen Lauf **nicht erhebbar**.
|
||||
|
||||
Inhaltlich bleibt der erzeugte Bericht auf der Ebene eines groben Modulüberblicks und benennt
|
||||
Komponenten teilweise unspezifisch (`diverse Controller/Service-Klassen`, `z.B. innerhalb von
|
||||
src\apis`). Er enthält keine Anforderungen im Sinne des Prompts und keine Belege.
|
||||
|
||||
## Ergebnis
|
||||
- **Status:** Fehler – `is_error: true`, `subtype: aborted`, `exit_code: 1`, `timed_out: true`
|
||||
- **Session-ID:** `ses_fa6bab91bffeZjd2WNTqYjgPaX`
|
||||
- **Permission-Denials:** **1** von 106 Tool-Aufrufen.
|
||||
- `bash` 1 × – `Get-ChildItem -Path "…" -Directory | Format-Table Name, LastWriteTime`.
|
||||
Der Aufruf beginnt mit dem erlaubten `Get-ChildItem`, enthält aber eine Pipeline nach
|
||||
`Format-Table`, für das keine Allow-Regel existiert.
|
||||
- Denials auf `task`/`agent`: **0** – das Modell hat keine Delegation versucht.
|
||||
- **Weitere gescheiterte Aufrufe – keine Permission-Ursache:**
|
||||
- `read` 22 × „File not found" – das Modell konstruierte Pfade, die es nie aufgelistet hatte
|
||||
(`src\webservice\Controllers\AccountsController.cs`, `SomeOtherController.cs`), und übergab
|
||||
einmal ein Glob-Muster (`**/*Controller.cs`) im Feld `filePath`.
|
||||
- `edit` 1 × Schemafehler: `SchemaError(Expected string, got null at ["newString"])` – das
|
||||
Modell rief das Werkzeug mit `newString: null` auf.
|
||||
- **Kontrolle Agentenmodus:** `subagent_stats.spawned` = 0 – korrekt für `solo`
|
||||
- **Subagenten-Prompts:** entfällt (Modus `solo`)
|
||||
- **Gültigkeit:** **Fehlmessung.** Der Lauf wurde durch das Laufzeitlimit beendet
|
||||
(`"Maximale Laufzeit von 3600 Sekunden ueberschritten"`) und lieferte keine der geforderten
|
||||
Anforderungsdateien.
|
||||
- **Erzeugte Dateien:** `Ergebnisse\Analysebericht.md` (2.873 Bytes)
|
||||
- **Root unverändert:** ja – `before.txt` und `after.txt` sind beide leer
|
||||
- **Abschlusstext des Agenten:** meldet als Hindernis, das Schreiben nach `Analysebericht.md`
|
||||
sei „blocked by an unidentified schema error" – gemeint ist der selbst verursachte
|
||||
`edit`-Aufruf mit `newString: null`.
|
||||
|
||||
## Anmerkungen/Auffälligkeiten
|
||||
|
||||
**Wirkung der erweiterten Allowlist – der eigentliche Ertrag dieses Laufs.** Gegenüber dem
|
||||
Vorlauf unter Skill 10.1.0 (`Iteration 10/…/v10.1.0-b00a`), der sich nur in der Toolfreigabe
|
||||
unterscheidet:
|
||||
|
||||
| Messgröße | Iteration 10 (alte Allowlist) | Iteration 11 (erweitert) |
|
||||
|---|---:|---:|
|
||||
| Tool-Aufrufe | 6 | **106** |
|
||||
| davon Permission-Denials | 3 | **1** |
|
||||
| `read` | 0 | 38 |
|
||||
| `glob` | 2 | 55 |
|
||||
| `grep` | 0 | 6 |
|
||||
| Erzeugte Dateien | 0 | 1 |
|
||||
| Tokens gesamt | 919.306 | 838.955 |
|
||||
| Turns | 232 | 185 |
|
||||
|
||||
Die fehlenden Lesekommandos waren damit tatsächlich handlungsleitend: Mit `ls`, `dir /s` und
|
||||
`cat` verfügbar wechselt das Modell von reiner Textproduktion zu tatsächlicher Codeanalyse. Der
|
||||
Befund stützt die Entscheidung für Skill 11.0.0 empirisch. **Die beiden Läufe sind wegen der
|
||||
geänderten Toolfreigabe nicht poolbar**; der Vergleich ist als Wirkung der Bedingung zu lesen,
|
||||
nicht als Wiederholungsmessung.
|
||||
|
||||
**Die verbleibende Grenze ist das Modell, nicht die Konfiguration.** Von 106 Aufrufen scheiterte
|
||||
genau einer an einer Regel. Die 22 fehlgeschlagenen Lesevorgänge sind erfundene Dateipfade, der
|
||||
Schemafehler ein fehlerhaft aufgebauter Werkzeugaufruf. Das Modell hat also Zugriff, nutzt ihn
|
||||
aber unzuverlässig: Es liest Verzeichnislisten und leitet daraus Pfade ab, die es anschließend
|
||||
nicht verifiziert.
|
||||
|
||||
**Terminierungsversagen erneut bestätigt.** Nach dem Schemafehler deutete das Modell die
|
||||
Ursache falsch – es hielt das Schreiben für blockiert statt den eigenen Aufruf für fehlerhaft –
|
||||
und kam bis zum Zeitlimit nicht zum Abschluss. Der Stall-Timeout (900 s) griff wieder nicht,
|
||||
weil durchgehend Text erzeugt wurde. Das absolute `--max-runtime` bleibt für lokale Modelle die
|
||||
einzige wirksame Abbruchsicherung.
|
||||
|
||||
**Bekannte Abweichung der Versuchsbedingung.** Der Claude-Adapter regelt Shell-Kommandos über
|
||||
eine **Denylist** und erlaubt damit jedes nicht gesperrte Kommando; dieser Lauf verwendet eine
|
||||
**Allowlist**. Die Werkzeugfreiheit ist zwischen beiden Adaptern also nicht äquivalent – der
|
||||
Denial auf die `Format-Table`-Pipeline wäre unter der Claude-Konfiguration nicht aufgetreten.
|
||||
Die Umstellung auf eine Denylist ist beschlossen, aber bewusst bis nach Abschluss dieser Matrix
|
||||
zurückgestellt (siehe `AblaufProtokoll.md`, Abschnitt *Grenzen und offene Punkte*). Bei jedem
|
||||
Vergleich mit Claude-Läufen ist diese Abweichung mitzuführen.
|
||||
|
||||
**Vergleichbarkeit.** Nicht poolbar mit Claude-Code- und TensorX-Läufen: anderes Werkzeug,
|
||||
quantisierte Gewichte (Q4_K_M), 32.768 statt bis zu 1.000.000 Kontexttokens, nicht steuerbarer
|
||||
Effort und abweichende Toolfreigabe.
|
||||
+961
@@ -0,0 +1,961 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "aborted",
|
||||
"duration_ms": 3602174,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 185,
|
||||
"model": "google/gemma-4-e4b",
|
||||
"model_requested": "google/gemma-4-e4b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 694071,
|
||||
"completion_tokens": 52904,
|
||||
"total_tokens": 838955,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 91980,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 91980
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"google/gemma-4-e4b": {
|
||||
"input_tokens": 694071,
|
||||
"output_tokens": 52904,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 91980
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"command": "dir /s"
|
||||
},
|
||||
"title": "dir /s"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/src/**, **/modules/**, \"*.module\""
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "*/**/src/**/*.ts, */**/components/**/*.tsx, */**/*.js, */**/*.java, */**/*.py"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"command": "Get-ChildItem -Path \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\" -Directory | Format-Table Name, LastWriteTime"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*{java,js,ts,cs}*"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"command": "dir /s C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
"title": "dir /s C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"command": "ls -R C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
"title": "ls -R C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs",
|
||||
"path": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "*.cs",
|
||||
"path": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP",
|
||||
"pattern": "using System;"
|
||||
},
|
||||
"title": "using System;"
|
||||
},
|
||||
{
|
||||
"name": "write",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"content": "# Analysebericht - CentronERP Reverse Requirements Engineering Report\n\n## 1. Überblick und Methodik\nDieser Bericht dient der systematischen Dokumentation der funktionalen Anforderungen des Systems \"CentronERP\" mittels Reverse Requirements Engineering (RRE). Die Analyse basiert auf einer statischen Code-Analyse und der Untersuchung der vorhandenen Module in der Quelle `C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP`.\n\n## 2. Modulinventar (Module Inventory)\nDas System lässt sich grob in folgende Hauptmodule unterteilen, die jeweils spezifische Geschäftsprozesse abbilden:\n\n### 2.1. Authentifizierung & Sicherheit (Security/Auth Module)\nDieses Modul ist verantwortlich für den Zugangskontrollmechanismus des Systems, einschließlich Benutzerauthentifizierung und Berechtigungsprüfung. Es interagiert eng mit dem API-Layer.\n\n* **Kernkomponenten:** `OAuthHelper`, `UserManagement` Services.\n* **Funktionalität:** Login/Logout, Token-Generierung, Rollebasierte Zugriffssteuerung (RBAC).\n* **Abhängigkeiten:** Wird von nahezu allen anderen Modulen konsumiert.\n\n### 2.2. API Layer & Business Logic (Centron.Api Module)\nDieses zentrale Modul definiert die Schnittstelle zwischen dem Frontend/Client und den Kernlogiken des Systems. Es kapselt Geschäftsregeln für verschiedene Geschäftsbereiche.\n\n* **Kernkomponenten:** `Centron.Api.EbInterface`, diverse Controller/Service-Klassen (z.B. innerhalb von `src\\apis`).\n* **Funktionalität:** Exponieren der CRUD-Operationen und Verarbeitung komplexer Business Rules.\n\n### 2.3. Dokumentenmanagement (DocuForm Module)\nDieses Modul ist dediziert für die Verwaltung, Generierung und Bearbeitung spezifischer Dokumente innerhalb des ERPs.\n\n* **Kernkomponenten:** `OAuthHelper` (möglicherweise Überschneidung mit Sicherheit), spezifische Formular-Service-Klassen in `Centron.Api.docuFORM\\Helper`.\n* **Funktionalität:** Erstellung, Speicherung und Abruf von Geschäftsdokumenten.\n\n### 2.4. End-to-End Tests & Integration (Tests Module)\nDie Testarchitektur bildet einen kritischen Teil des Verständnisses der Anforderungen ab, da sie die erwarteten Verhaltensweisen validiert.\n\n* **Kernkomponenten:** `Centron.Tests.EndToEnd` Projekte und deren spezifische Testklassen.\n* **Funktionalität:** Validierung von End-to-End-Workflows über verschiedene Module hinweg (z.B. Login -> Dokumentenbearbeitung).\n\n## 3. Beziehungen zwischen Modulen\nDie Module sind hochgradig gekoppelt:\n1. Der **API Layer** (`Centron.Api`) dient als primäre Kommunikationsschnittstelle für alle Clients und Konsumenten.\n2. Das **Security/Auth Module** steuert den Zugriff auf den **API Layer** und ist somit ein Gatekeeper.\n3. Alle Geschäftsprozesse (z.B. im **DocuForm Module**) müssen die Authentifizierung durch das Security Modul validieren, bevor sie über den API Layer ausgeführt werden können.\n\n*Ende des ersten Entwurfs.*",
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 11\\google\\gemma-4-e4b\\solo\\high\\03_Lauf_2026-08-31_212134_v11.0.0-6b61\\Ergebnisse\\Analysebericht.md"
|
||||
},
|
||||
"title": "Versuche\\Versuch_01\\Iteration 11\\google\\gemma-4-e4b\\solo\\high\\03_Lauf_2026-08-31_212134_v11.0.0-6b61\\Ergebnisse\\Analysebericht.md"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "*.cs",
|
||||
"path": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP",
|
||||
"pattern": "[A-Z].*Service|[A-Z].*Manager"
|
||||
},
|
||||
"title": "[A-Z].*Service|[A-Z].*Manager"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "**/*.cs",
|
||||
"pattern": "public class *Service|public abstract class *Repository|DbContext"
|
||||
},
|
||||
"title": "public class *Service|public abstract class *Repository|DbContext"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "Centron.Api/Services/**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "Centron.Api/Managers/**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "Centron.Api/**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "*"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.csproj"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "*.cs",
|
||||
"pattern": "[HttpGet] | [HttpPost] | public void Create | SaveData | GetDetails"
|
||||
},
|
||||
"title": "[HttpGet] | [HttpPost] | public void Create | SaveData | GetDetails"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.csproj"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "*.cs",
|
||||
"pattern": "using System.Data;|SaveChanges()|ExecuteQuery\\(|\\.Result"
|
||||
},
|
||||
"title": "using System.Data;|SaveChanges()|ExecuteQuery\\(|\\.Result"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Startup.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\deployment\\WixSharpInstaller\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\deployment\\WixSharpInstaller\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\scripts\\Scripts\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\scripts\\Scripts\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\scripts\\Centron.Scripts\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\scripts\\Centron.Scripts\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Host.WindowsService\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Host.WindowsService\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Host.Console\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Host.Console\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\nexus\\CentronNexus.Host\\Program.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\nexus\\CentronNexus.Host\\Program.cs"
|
||||
},
|
||||
{
|
||||
"name": "edit",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "[Long Path to] Analysebericht.md",
|
||||
"newString": null,
|
||||
"oldString": "(Placeholder content representing the end of previous sections.)"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "src/webservice/*/Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "src/webservice/**/Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "src/webservice/**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "src/webservice/Centron.Controllers/Controllers/v1/Tickets/HelpdeskTimersController.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Controllers\\v1\\Tickets\\HelpdeskTimersController.cs"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "grep",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"include": "*.cs",
|
||||
"pattern": "Controller|ApiController"
|
||||
},
|
||||
"title": "Controller|ApiController"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "src/webservice/Controllers/HelpdeskTimersController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "src/webservice/Controllers/AccountsController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"command": "ls -la C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
"title": "ls -la C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\ApiControllerBaseController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\AccountController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\BusinessUnitController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\CommonController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\DocuFormController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\Controllers\\ModuleController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\api\\ApiController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\api\\SomeOtherController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\WebServices\\Api/Entities/ServiceUser.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\ControllerBaseExtensions.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP\\Centron.Api.docuFORM\\DocuFormRestApiConstants.cs"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\WebServiceVersionController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\WebAccountController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\TicketPatternsController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller*.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\centron\\Centron.WPF.UI.Modules\\OnlineBanking\\Controllers\\OnlineBankingController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\Utils\\LoginController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\centron\\Centron.WPF.UI.Modules\\Warehousing\\Controllers\\WarehousingController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\centron\\Centron.WPF.UI\\Controllers\\ICentronAppModuleSettingController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\OutgoingPaymentsModuleController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\\src\\webservice\\Centron.Controllers\\SomeOtherModuleController.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "read",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"filePath": "**/*Controller.cs"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
},
|
||||
{
|
||||
"name": "glob",
|
||||
"status": "completed",
|
||||
"input": {
|
||||
"pattern": "**/*Controller.cs"
|
||||
},
|
||||
"title": "QuellCode\\CentronERP"
|
||||
}
|
||||
],
|
||||
"tool_call_count": 106,
|
||||
"tool_call_types": {
|
||||
"bash": 5,
|
||||
"glob": 55,
|
||||
"grep": 6,
|
||||
"write": 1,
|
||||
"read": 38,
|
||||
"edit": 1
|
||||
},
|
||||
"event_counts": {
|
||||
"step_start": 185,
|
||||
"tool_use": 106,
|
||||
"step_finish": 184,
|
||||
"text": 201
|
||||
},
|
||||
"written_files": [
|
||||
{
|
||||
"path": "Analysebericht.md",
|
||||
"size": 2873
|
||||
}
|
||||
],
|
||||
"result": "## Objective\n- Analyze all API controller files (`*.cs`) to document usage patterns and functional contracts of web services for inclusion in `Analysebericht.md`.\n\n## Important Details\n- Constraint: Writing final findings to `Analysebericht.md` is blocked by an unidentified schema error.\n- Decision: The process requires reading the content of all collected API controller files to proceed with analysis documentation.\n- Context: A comprehensive list of relevant file paths was successfully retrieved using `glob({\"pattern\":\"**/*Controller.cs\"})`.\n\n## Work State\n### Completed\n- Analysis documentation was initially performed for specific source code files (e.g., `ControllerBaseExtensions.cs`).\n- Successfully executed `glob` to retrieve a detailed, confirmed list of all API controller file paths within the project structure.\n\n### Active\n- The process is currently gathering data content by planning to read the contents of the many collected controller files iteratively/in batches using the `read` tool based on the recent path output.\n\n### Blocked\n- Writing findings to `Analysebericht.md` remains blocked due to an unidentified schema error, preventing report generation.\n\n## Next Move\n1. Use the `read` tool sequentially or in batches to retrieve the content of all file paths listed by the latest `glob` output.\n2. Once all data collection is complete, focus on structuring the documentation and addressing the underlying schema error in `Analysebericht.md`.\n\n## Relevant Files\n- **C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP**: Core source code repository containing target controller files for analysis (e.g., paths starting with `src/centron` or `src/nexus`).\n- **Analysebericht.md**: The target report file, currently blocked by a schema error.",
|
||||
"finish_reason": "stop",
|
||||
"errors": [
|
||||
"Maximale Laufzeit von 3600 Sekunden ueberschritten"
|
||||
],
|
||||
"session_id": "ses_fa6bab91bffeZjd2WNTqYjgPaX",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "1.2.0",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "solo",
|
||||
"subagent_stats": {
|
||||
"spawned": 0,
|
||||
"completed": 0,
|
||||
"failed": 0,
|
||||
"by_type": {}
|
||||
},
|
||||
"subagent_details": [],
|
||||
"timed_out": true,
|
||||
"interrupted": false,
|
||||
"exit_code": 1,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "google/gemma-4-e4b",
|
||||
"instance_id": "google/gemma-4-e4b",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"quantization": "Q4_K_M",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768
|
||||
},
|
||||
"context_window": 32768,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"start_time": "2026-08-31T19:21:46.069635+00:00",
|
||||
"end_time": "2026-08-31T20:21:50.232377+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 11\\google\\gemma-4-e4b\\solo\\high\\03_Lauf_2026-08-31_212134_v11.0.0-6b61\\_meta\\opencode-config.json"
|
||||
}
|
||||
+6
@@ -0,0 +1,6 @@
|
||||
[2026-08-31T19:21:45.992840+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-08-31T19:21:46.068904+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T19:21:46.069658+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T20:21:46.564509+00:00] Maximale Laufzeit von 3600 Sekunden ueberschritten; Prozessbaum wird beendet
|
||||
[2026-08-31T20:21:50.191763+00:00] OpenCode export: Exporting session: ses_fa6bab91bffeZjd2WNTqYjgPaX
|
||||
[2026-08-31T20:21:50.233686+00:00] Ende: Exitcode=1; Status=aborted; Turns=185; Tokens=838955; Dateien=1; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_212134_v11.0.0-6b61\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
[]
|
||||
+4
@@ -0,0 +1,4 @@
|
||||
## Gefundene Anforderungen
|
||||
|
||||
Keine Anforderungen im vorgegebenen Format gefunden.
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\google\gemma-4-e4b\solo\high\03_Lauf_2026-08-31_212134_v11.0.0-6b61\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T22:21:50.2544889+02:00
|
||||
+42
@@ -0,0 +1,42 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 262144,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/google/gemma-4-e4b/solo/high/03_Lauf_2026-08-31_212134_v11.0.0-6b61/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "deny",
|
||||
"rg *": "allow",
|
||||
"ls": "allow",
|
||||
"ls *": "allow",
|
||||
"find *": "allow",
|
||||
"grep *": "allow",
|
||||
"wc *": "allow",
|
||||
"tree *": "allow",
|
||||
"cat *": "allow",
|
||||
"head *": "allow",
|
||||
"tail *": "allow",
|
||||
"file *": "allow",
|
||||
"stat *": "allow",
|
||||
"git status*": "allow",
|
||||
"git ls-files*": "allow",
|
||||
"git rev-parse*": "allow",
|
||||
"git log*": "allow",
|
||||
"git show*": "allow",
|
||||
"dir": "allow",
|
||||
"dir *": "allow",
|
||||
"type *": "allow",
|
||||
"Get-ChildItem *": "allow",
|
||||
"Get-Content *": "allow",
|
||||
"Get-Item *": "allow",
|
||||
"Select-String *": "allow",
|
||||
"Measure-Object *": "allow",
|
||||
"Test-Path *": "allow",
|
||||
"Resolve-Path *": "allow",
|
||||
"where.exe *": "allow"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+22883
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-08-31T21:21:43.1967846+02:00
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
[2026-08-31T22:50:12.558708+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe load qwen/qwen3.8-27b --context-length 32768 --yes
|
||||
[2026-08-31T22:50:52.857678+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.8-27b; Quantisierung=Q4_K_M; Kontext=32768/262144; Runtime=gguf
|
||||
[2026-08-31T22:50:52.940007+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.8-27b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T22:50:52.941375+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.8-27b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T23:11:40.498955+00:00] Keine OpenCode-Ausgabe seit 900 Sekunden; Prozessbaum wird beendet
|
||||
[2026-08-31T23:11:44.326149+00:00] OpenCode export: Exporting session: ses_fa5fb4532ffe7qy8sROHbSYKwF
|
||||
[2026-08-31T23:11:44.331561+00:00] Ende: Exitcode=1; Status=aborted; Turns=2; Tokens=10225; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\qwen\qwen3.8-27b\solo\high\03_Lauf_2026-09-01_005001_v11.1.0-45b1\RawResult.json
|
||||
+5
@@ -0,0 +1,5 @@
|
||||
{"type":"step_start","timestamp":1788216724788,"sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","part":{"id":"prt_05a05cd20001dGEIyW5lLEnO6x","messageID":"msg_05a04bce00018Z0TdHfhcumLp5","sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","snapshot":"f12285089d13dc42c79d8727083faabd81525b8c","type":"step-start"}}
|
||||
{"type":"tool_use","timestamp":1788216939659,"sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","part":{"type":"tool","tool":"bash","callID":"dL7y7WTyhS0jD2G2pqCoC0a9v4ixpCod","state":{"status":"error","input":{"command":"Get-ChildItem -LiteralPath \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\" | Format-Table Name, Length, Mode"},"error":"The user has specified a rule which prevents you from using this specific tool call. Here are some of the relevant rules [{\"permission\":\"*\",\"action\":\"allow\",\"pattern\":\"*\"},{\"permission\":\"*\",\"action\":\"deny\",\"pattern\":\"*\"},{\"permission\":\"bash\",\"pattern\":\"*\",\"action\":\"deny\"},{\"permission\":\"bash\",\"pattern\":\"rg *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"ls\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"ls *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"find *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"grep *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"wc *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"tree *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"cat *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"head *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"tail *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"file *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"stat *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git status*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git ls-files*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git rev-parse*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git log*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git show*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"dir\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"dir *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"type *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-ChildItem *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-Content *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-Item *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Select-String *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Measure-Object *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Test-Path *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Resolve-Path *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"where.exe *\",\"action\":\"allow\"}]","time":{"start":1788216939499,"end":1788216939649}},"id":"prt_05a08c162001Lar4zQIRyotLkH","sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","messageID":"msg_05a04bce00018Z0TdHfhcumLp5"}}
|
||||
{"type":"tool_use","timestamp":1788216961601,"sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","part":{"type":"tool","tool":"bash","callID":"ST487fKUXJAPCl0lvyEDCkIgTu1BGSpL","state":{"status":"error","input":{"command":"Get-ChildItem -LiteralPath \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\" -Recurse -Directory -Depth 2 | Select-Object -ExpandProperty FullName"},"error":"The user has specified a rule which prevents you from using this specific tool call. Here are some of the relevant rules [{\"permission\":\"*\",\"action\":\"allow\",\"pattern\":\"*\"},{\"permission\":\"*\",\"action\":\"deny\",\"pattern\":\"*\"},{\"permission\":\"bash\",\"pattern\":\"*\",\"action\":\"deny\"},{\"permission\":\"bash\",\"pattern\":\"rg *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"ls\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"ls *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"find *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"grep *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"wc *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"tree *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"cat *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"head *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"tail *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"file *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"stat *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git status*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git ls-files*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git rev-parse*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git log*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"git show*\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"dir\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"dir *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"type *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-ChildItem *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-Content *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Get-Item *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Select-String *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Measure-Object *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Test-Path *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"Resolve-Path *\",\"action\":\"allow\"},{\"permission\":\"bash\",\"pattern\":\"where.exe *\",\"action\":\"allow\"}]","time":{"start":1788216961581,"end":1788216961588}},"id":"prt_05a0913f5001fPoKxF3FU5fVy3","sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","messageID":"msg_05a04bce00018Z0TdHfhcumLp5"}}
|
||||
{"type":"step_finish","timestamp":1788216962409,"sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","part":{"id":"prt_05a096d57001tBkCCG3H5uRDwX","reason":"tool-calls","snapshot":"f12285089d13dc42c79d8727083faabd81525b8c","messageID":"msg_05a04bce00018Z0TdHfhcumLp5","sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","type":"step-finish","tokens":{"total":10225,"input":9628,"output":125,"reasoning":472,"cache":{"write":0,"read":0}},"cost":0}}
|
||||
{"type":"step_start","timestamp":1788216999678,"sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","part":{"id":"prt_05a09feea001IqIiv1vV1Jvkku","messageID":"msg_05a096f9b001Fr6jt1PCb3GCrP","sessionID":"ses_fa5fb4532ffe7qy8sROHbSYKwF","snapshot":"f12285089d13dc42c79d8727083faabd81525b8c","type":"step-start"}}
|
||||
+108
@@ -0,0 +1,108 @@
|
||||
{
|
||||
"is_error": true,
|
||||
"subtype": "aborted",
|
||||
"duration_ms": 1249239,
|
||||
"duration_api_ms": 0,
|
||||
"num_turns": 2,
|
||||
"model": "qwen/qwen3.8-27b",
|
||||
"model_requested": "qwen/qwen3.8-27b",
|
||||
"provider": "lmstudio",
|
||||
"effort": "high",
|
||||
"effort_applied": false,
|
||||
"usage": {
|
||||
"prompt_tokens": 9628,
|
||||
"completion_tokens": 125,
|
||||
"total_tokens": 10225,
|
||||
"cached_tokens": 0,
|
||||
"cache_read_tokens": 0,
|
||||
"cache_creation_tokens": 0,
|
||||
"reasoning_tokens": 472,
|
||||
"output_tokens_details": {
|
||||
"thinking_tokens": 472
|
||||
}
|
||||
},
|
||||
"modelUsage": {
|
||||
"qwen/qwen3.8-27b": {
|
||||
"input_tokens": 9628,
|
||||
"output_tokens": 125,
|
||||
"cache_read_input_tokens": 0,
|
||||
"cache_creation_input_tokens": 0,
|
||||
"reasoning_tokens": 472
|
||||
}
|
||||
},
|
||||
"cost": 0,
|
||||
"tool_calls": [
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"command": "Get-ChildItem -LiteralPath \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\" | Format-Table Name, Length, Mode"
|
||||
},
|
||||
"title": ""
|
||||
},
|
||||
{
|
||||
"name": "bash",
|
||||
"status": "error",
|
||||
"input": {
|
||||
"command": "Get-ChildItem -LiteralPath \"C:\\DEV\\MasterArbeit\\QuellCode\\CentronERP\" -Recurse -Directory -Depth 2 | Select-Object -ExpandProperty FullName"
|
||||
},
|
||||
"title": ""
|
||||
}
|
||||
],
|
||||
"tool_call_count": 2,
|
||||
"tool_call_types": {
|
||||
"bash": 2
|
||||
},
|
||||
"event_counts": {
|
||||
"step_start": 2,
|
||||
"tool_use": 2,
|
||||
"step_finish": 1
|
||||
},
|
||||
"written_files": [],
|
||||
"result": "",
|
||||
"finish_reason": "tool-calls",
|
||||
"errors": [
|
||||
"Keine OpenCode-Ausgabe seit 900 Sekunden",
|
||||
"Ergebnisse-Verzeichnis ist leer"
|
||||
],
|
||||
"session_id": "ses_fa5fb4532ffe7qy8sROHbSYKwF",
|
||||
"adapter": "opencode-lmstudio",
|
||||
"adapter_version": "1.4.0",
|
||||
"opencode_version": "1.18.25",
|
||||
"mode": "solo",
|
||||
"subagent_stats": {
|
||||
"spawned": 0,
|
||||
"completed": 0,
|
||||
"failed": 0,
|
||||
"by_type": {}
|
||||
},
|
||||
"subagent_details": [],
|
||||
"timed_out": true,
|
||||
"interrupted": false,
|
||||
"exit_code": 1,
|
||||
"usage_captured": true,
|
||||
"local_runtime": {
|
||||
"provider": "lmstudio",
|
||||
"base_url": "http://localhost:1234",
|
||||
"lms_path": "C:\\Users\\ChristophSchwoerer\\.lmstudio\\bin\\lms.exe",
|
||||
"lms_version": "CLI commit: 71bd99c",
|
||||
"model_id": "qwen/qwen3.8-27b",
|
||||
"instance_id": "qwen/qwen3.8-27b",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"quantization": "Q4_K_M",
|
||||
"compatibility_type": "gguf",
|
||||
"state": "loaded",
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
],
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 32768
|
||||
},
|
||||
"context_window": 32768,
|
||||
"cost_source": "nicht erfasst (lokaler Betrieb)",
|
||||
"start_time": "2026-08-31T22:50:52.941127+00:00",
|
||||
"end_time": "2026-08-31T23:11:44.329705+00:00",
|
||||
"opencode_path": "C:\\Users\\ChristophSchwoerer\\AppData\\Roaming\\npm\\node_modules\\opencode-ai\\bin\\opencode.exe",
|
||||
"config_path": "C:\\DEV\\MasterArbeit\\Versuche\\Versuch_01\\Iteration 11\\qwen\\qwen3.8-27b\\solo\\high\\03_Lauf_2026-09-01_005001_v11.1.0-45b1\\_meta\\opencode-config.json"
|
||||
}
|
||||
+7
@@ -0,0 +1,7 @@
|
||||
[2026-08-31T22:50:12.558708+00:00] LM Studio: C:\Users\ChristophSchwoerer\.lmstudio\bin\lms.exe load qwen/qwen3.8-27b --context-length 32768 --yes
|
||||
[2026-08-31T22:50:52.857678+00:00] LM-Studio-Preflight bestanden: qwen/qwen3.8-27b; Quantisierung=Q4_K_M; Kontext=32768/262144; Runtime=gguf
|
||||
[2026-08-31T22:50:52.940007+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'qwen/qwen3.8-27b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-08-31T22:50:52.941375+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/qwen/qwen3.8-27b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=900s
|
||||
[2026-08-31T23:11:40.498955+00:00] Keine OpenCode-Ausgabe seit 900 Sekunden; Prozessbaum wird beendet
|
||||
[2026-08-31T23:11:44.326149+00:00] OpenCode export: Exporting session: ses_fa5fb4532ffe7qy8sROHbSYKwF
|
||||
[2026-08-31T23:11:44.331561+00:00] Ende: Exitcode=1; Status=aborted; Turns=2; Tokens=10225; Dateien=0; RawResult=C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\qwen\qwen3.8-27b\solo\high\03_Lauf_2026-09-01_005001_v11.1.0-45b1\RawResult.json
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 11\qwen\qwen3.8-27b\solo\high\03_Lauf_2026-09-01_005001_v11.1.0-45b1\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T01:11:44.3527792+02:00
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+106
@@ -0,0 +1,106 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 131072,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/qwen/qwen3.8-27b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 11/qwen/qwen3.8-27b/solo/high/03_Lauf_2026-09-01_005001_v11.1.0-45b1/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "deny",
|
||||
"rg *": "allow",
|
||||
"ls": "allow",
|
||||
"ls *": "allow",
|
||||
"find *": "allow",
|
||||
"grep *": "allow",
|
||||
"wc *": "allow",
|
||||
"tree *": "allow",
|
||||
"cat *": "allow",
|
||||
"head *": "allow",
|
||||
"tail *": "allow",
|
||||
"file *": "allow",
|
||||
"stat *": "allow",
|
||||
"git status*": "allow",
|
||||
"git ls-files*": "allow",
|
||||
"git rev-parse*": "allow",
|
||||
"git log*": "allow",
|
||||
"git show*": "allow",
|
||||
"dir": "allow",
|
||||
"dir *": "allow",
|
||||
"type *": "allow",
|
||||
"Get-ChildItem *": "allow",
|
||||
"Get-Content *": "allow",
|
||||
"Get-Item *": "allow",
|
||||
"Select-String *": "allow",
|
||||
"Measure-Object *": "allow",
|
||||
"Test-Path *": "allow",
|
||||
"Resolve-Path *": "allow",
|
||||
"where.exe *": "allow"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/qwen/qwen3.8-27b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/qwen/qwen3.8-27b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/qwen/qwen3.8-27b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+276
File diff suppressed because one or more lines are too long
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T00:50:10.2117931+02:00
|
||||
+3
@@ -0,0 +1,3 @@
|
||||
[2026-09-01T04:52:58.094151+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-09-01T04:52:58.164985+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T04:52:58.165676+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
+523
File diff suppressed because one or more lines are too long
+3
@@ -0,0 +1,3 @@
|
||||
[2026-09-01T04:52:58.094151+00:00] LM-Studio-Preflight bestanden: google/gemma-4-e4b; Quantisierung=Q4_K_M; Kontext=32768/131072; Runtime=gguf
|
||||
[2026-09-01T04:52:58.164985+00:00] Effort 'high' wird nicht an den Provider uebergeben: 'google/gemma-4-e4b' kennt keine passende Variante. Im Protokoll als nicht steuerbar ausweisen.
|
||||
[2026-09-01T04:52:58.165676+00:00] Start OpenCode C:\Users\ChristophSchwoerer\AppData\Roaming\npm\node_modules\opencode-ai\bin\opencode.exe; Provider=lmstudio; Modell=lmstudio/google/gemma-4-e4b; Modus=solo; Effort=high (uebergeben=False); Stall-Timeout=0s
|
||||
+1
@@ -0,0 +1 @@
|
||||
|
||||
+174
@@ -0,0 +1,174 @@
|
||||
# Versuch 01 - Baseline (Prompt-only) - Iteration 03
|
||||
|
||||
## Metadaten
|
||||
- **Versuch:** V1 Baseline (Prompt-only)
|
||||
- **Iteration:** 03 (zweite Überarbeitung nach Auswertung der Iteration-6-Läufe)
|
||||
- **Codebasis:** c-entron ERP-Suite (Windows, C#/XAML, MSSQL)
|
||||
- **Zeitstempel:** 2026-08-28
|
||||
- **Vorgänger:** `02_Prompt.md` (SHA-256 `F9B2A1AA…0D7849`), 4 Läufe in Iteration 6
|
||||
- **Änderungsgrund:** Auswertung der 4 Iteration-6-Läufe (GLM-solo, GLM-builtin, Kimi-solo, Kimi-builtin). Jede Änderung ist an einen gemessenen Befund gekoppelt:
|
||||
|
||||
| Änderung | Auslösender Befund |
|
||||
|---|---|
|
||||
|
||||
---
|
||||
|
||||
## Prompt
|
||||
|
||||
Du bist ein Requirements Engineer im Reverse Requirements Engineering eines Legacy-ERP-Systems. Erzeuge aus der vorliegenden Codebasis eine Anforderungsspezifikation nach **ISO/IEC/IEEE 29148:2018**. Arbeite ausschließlich auf den im Arbeitsverzeichnis liegenden Artefakten (Quellcode, Konfiguration, UI-Ressourcen, ggf. DB-Skripte). Nutze nur Informationen, die du aus diesen Artefakten gewinnen kannst.
|
||||
|
||||
### Auftrag
|
||||
|
||||
Erzeuge eine konsolidierte Spezifikation auf den drei Ebenen:
|
||||
|
||||
1. **StRS** - Stakeholder Requirements Specification (fachliche Sicht, Akteure, Geschäftsziele)
|
||||
2. **SyRS** - System Requirements Specification (Systemverhalten, Schnittstellen, Performance-, Sicherheitsanforderungen)
|
||||
3. **SwRS** - Software Requirements Specification (Komponenten, Datenmodelle, Software-interne Regeln)
|
||||
|
||||
Ziel ist eine Spezifikation, die als belastbare Basis für eine Web-/SaaS-Neuimplementierung dienen kann.
|
||||
|
||||
### Scope (Schritt 1 der RRE-Methodenkette, manuell vorgegeben)
|
||||
|
||||
Der Untersuchungsgegenstand ist die **gesamte Codebasis** im Arbeitsverzeichnis. Es gilt bewusst keine Modulbeschränkung: Alle Module, Datenobjekte und Prozesse sind gleichrangig zu erfassen.
|
||||
|
||||
**Breite geht vor Tiefe.** Ein fehlendes Requirement führt bei einer Neuimplementierung zu Funktionsverlust; eine oberflächlich erfasste Funktion lässt sich dagegen nachschärfen. Erfasse deshalb zuerst die gesamte Breite und vertiefe erst danach. Halte dich an die Reihenfolge aus dem Abschnitt **Vorgehen**: erst Inventar, dann Mindestabdeckung, dann Vertiefung.
|
||||
|
||||
### Vorgehen (statische Analyse, keine Ausführung)
|
||||
|
||||
Bearbeite die Schritte 2-6 der RRE-Methodenkette (Schritt 1 Scope ist oben vorgegeben, Schritt 7 Validierung erfolgt manuell durch Fachexperten). Vorgeschaltet ist eine verbindliche Inventarisierung:
|
||||
|
||||
**Schritt 0 - Modulinventar (vor der ersten Anforderung).** Verschaffe dir zuerst einen vollständigen Überblick über den Untersuchungsgegenstand und lege ihn im `Analysebericht.md` als Tabelle ab: fachliches Modul beziehungsweise Komponente, Pfad im Arbeitsverzeichnis, ein Satz zur fachlichen Aufgabe. Das Inventar wird erstellt, **bevor** die erste Anforderung formuliert wird. Es ist die Bezugsgröße für die Abdeckung und darf später ergänzt, aber nicht gekürzt werden.
|
||||
|
||||
**Schritt 0b - Mindestabdeckung.** Jedes Modul des Inventars erhält **mindestens eine** Anforderung, bevor irgendein Modul vertieft wird. Lässt sich für ein Modul keine belegbare Anforderung bilden, führe es im Inventar als `nicht analysiert` mit einer kurzen Begründung. Ein Modul ohne Anforderung und ohne Begründung ist unzulässig. **Mehr als 10 % der Module als `nicht analysiert` zu führen, ist ein Hinweis auf unvollständige Erkundung** – gehe zurück und lies die zugehörigen Quelldateien, bevor du mit der Vertiefung fortfährst.
|
||||
|
||||
**Schritt 0c - Vertiefung nach Risiko.** Erst wenn die Mindestabdeckung steht, vertiefe einzelne Module. Beginne dort, wo Sicherheitsregeln, Abrechnungs- und Fakturierungslogik oder Berechtigungsprüfungen liegen.
|
||||
|
||||
2. **Artefakterhebung:** Erfasse Quellcode, Konfiguration, UI-Texte, Datenbankschemata, Schnittstellenbeschreibungen sowie Change-Historie und Projektartefakte (Commit-Messages, Tickets, Release Notes, Migrationsnotizen), soweit als Datei lesbar.
|
||||
3. **Technische Analyse:** Identifiziere Module, Komponenten, Abhängigkeiten, Statusmaschinen, Validierungslogik, Berechtigungsprüfungen.
|
||||
4. **Semantische Interpretation:** Leite fachliche Aussagen aus technischen Implementierungen ab (z. B. Statusübergänge → Geschäftsregel).
|
||||
5. **Formalisierung:** Überführe die Aussagen in klare, testbare Anforderungen mit Kontext, Vorbedingung und Ergebnis.
|
||||
6. **Traceability-Anreicherung:** Verknüpfe jede Anforderung mit konkreten Artefaktbelegen.
|
||||
|
||||
### Pflicht-Eigenschaften jeder Anforderung
|
||||
|
||||
- **Belegpflicht:** Jede Anforderung **muss** mindestens einen konkreten Artefaktbeleg führen (Dateipfad, Klasse/Methode, SQL-Statement, UI-String, Konfigurationseintrag). Jeder Beleg erhält eine kurze Begründung, warum er die Aussage trägt. Lässt sich eine Aussage nicht belegen, **schreibe die Anforderung nicht** - erfasse den offenen Punkt stattdessen als Hypothese. Eine Anforderung ohne Beleg ist unter keinen Umständen zulässig.
|
||||
- **Trennung von Fakt und Interpretation:** Die belegte technische Beobachtung (Feld `Fakt`) wird getrennt von der fachlichen Interpretation (Feld `Aussage`) dokumentiert, damit nachvollziehbar bleibt, was im Artefakt steht und was daraus geschlossen wurde.
|
||||
- **Risikobasierte Priorisierung:** Anforderungen zu Sicherheitsregeln, Abrechnungs-/Fakturierungslogik und Berechtigungen unterliegen strengeren Evidenzanforderungen: Sie benötigen mindestens einen `PRIMÄR`-Beleg, andernfalls sind sie zwingend als `[HYPOTHESE]` zu kennzeichnen. Ein `PRIMÄR`-Beleg benennt hier die **durchsetzende Stelle** - Datei, Klasse, Methode und die konkrete Prüfung, Bedingung oder das Constraint. Ein Verweis auf eine Datei ohne Angabe der prüfenden Stelle genügt für diese Anforderungen nicht.
|
||||
- **Belegklassifikation:** Kennzeichne jeden Beleg als
|
||||
- `PRIMÄR` (durchgesetzte Regel im Code oder DB-Constraint),
|
||||
- `SEKUNDÄR` (UI-Label, Fehlermeldung, Reportlayout, Mappingtabelle, Konfigurationsschalter),
|
||||
- `KONTEXT` (Kommentar, Commit-Message, Ticketreferenz).
|
||||
- **Hypothesenmarkierung:** Aussagen, die sich nicht eindeutig aus Artefakten ableiten lassen, kennzeichnest du explizit mit `[HYPOTHESE]` und einer kurzen Begründung, welche Information zur Bestätigung fehlt. Bei einer Codebasis dieser Größe ist eine Analyse ohne jeden offenen Punkt unplausibel: Führst du keine einzige Hypothese, begründe das ausdrücklich in der Selbstbewertung. Umgekehrt ist eine hohe Hypothesenzahl kein Mangel, sondern ein Hinweis auf ehrliche Abgrenzung.
|
||||
- **Verifizierbarkeit:** Jede Anforderung enthält mindestens eine Prüfidee oder ein Akzeptanzkriterium.
|
||||
- **Eindeutigkeit:** Vermeide vage Begriffe ("schnell", "benutzerfreundlich"); definiere domänenspezifische Begriffe beim ersten Auftreten.
|
||||
- **Übernahmewürdigkeit:** Beurteile für jede Anforderung, ob ihre Funktion im Zielsystem erhalten bleiben soll. Unterscheide `übernehmen` (fachlich weiterhin erforderlich), `Workaround` (historisch gewachsene Behelfslösung), `Sonderfall` (Ausnahme für einen einzelnen Kunden, Mandanten oder Altbestand) und `veraltet` (durch neuere Logik abgelöst oder fachlich überholt). Begründe die Einstufung in einem Halbsatz.
|
||||
- **Redundanzfreiheit:** Formuliere jede Anforderung so, dass sie von den übrigen klar abgegrenzt ist. Beschreiben zwei Anforderungen dieselbe fachliche Funktion aus unterschiedlicher Perspektive, führe sie zusammen oder grenze sie im Titel und in der Aussage ausdrücklich gegeneinander ab.
|
||||
|
||||
### Formatvorgabe pro Anforderung
|
||||
|
||||
```
|
||||
ID: <StRS|SyRS|SwRS>-<laufende Nummer>
|
||||
Titel: <kurzer Titel>
|
||||
Ebene: <StRS | SyRS | SwRS>
|
||||
Typ: <funktional | nicht-funktional | Schnittstelle | Daten | Sicherheit | ...>
|
||||
Qualitätsmerkmal: <nur bei nicht-funktionalen Anforderungen: ISO-25010-Merkmal, sonst leer>
|
||||
Akteur: <Rolle / System / Komponente>
|
||||
Vorbedingung: <Zustand vor Auslösen>
|
||||
Fakt: <belegte technische Beobachtung, z. B. Statusübergang, Constraint, Prüfung>
|
||||
Aussage: Das System soll <...>. (fachliche Interpretation als klare Soll-Aussage)
|
||||
Ergebnis: <erwartetes Ergebnis / Nachbedingung>
|
||||
Belege:
|
||||
- [PRIMÄR] <Pfad/Klasse/Methode/SQL/UI-String> - Begründung: <warum trägt der Beleg die Aussage>
|
||||
- [SEKUNDÄR] <...> - Begründung: <...>
|
||||
- [KONTEXT] <...> - Begründung: <...>
|
||||
Prüfidee: <Akzeptanzkriterium oder Testidee>
|
||||
Tracelinks: <verwandte StRS-/SyRS-/SwRS-IDs>
|
||||
Konsolidierung: <nein | Kandidat: <IDs oder Stellen, die dieselbe fachliche Funktion abbilden>>
|
||||
Übernahmewürdigkeit: <übernehmen | Workaround | Sonderfall | veraltet> - <kurze Begründung>
|
||||
Status: <belegt | HYPOTHESE>
|
||||
```
|
||||
|
||||
### Traceability
|
||||
|
||||
Stelle Forward- und Backward-Traceability zwischen den drei Ebenen her:
|
||||
- Jede SwRS-Anforderung referenziert die zugehörige SyRS-Anforderung.
|
||||
- Jede SyRS-Anforderung referenziert die zugehörige StRS-Anforderung.
|
||||
- Erzeuge zusätzlich eine konsolidierte **Traceability-Tabelle** (Markdown oder CSV): `StRS-ID | SyRS-ID | SwRS-ID | Artefaktbeleg`.
|
||||
|
||||
### Nicht-funktionale Anforderungen
|
||||
|
||||
- Ordne nicht-funktionale Anforderungen den Qualitätsmerkmalen der **ISO/IEC 25010** zu (z. B. Zuverlässigkeit, Performance-Effizienz, Sicherheit, Wartbarkeit, Übertragbarkeit). Trage die Zuordnung in das dafür vorgesehene Feld `Qualitätsmerkmal` ein, nicht in das Feld `Typ`.
|
||||
- Leite Betriebs- und Sicherheitsanforderungen gezielt auch aus indirekt sichtbaren Artefakten ab: Konfigurationen, Deployment-Skripte, Logging-Policies, Rechteprüfungen.
|
||||
|
||||
### Konsolidierungsbedarf
|
||||
|
||||
Die Codebasis enthält fachliche Redundanz: Dieselbe Anforderung kann auf unterschiedlichen Masken oder in unterschiedlichen Modulen mehrfach und teils unterschiedlich implementiert sein. Prüfe daher bei jeder Anforderung, ob andere Anforderungen dieselbe fachliche Funktion abbilden, und vermerke solche Fälle im Feld `Konsolidierung` als Kandidat für eine Zusammenführung im Zielsystem.
|
||||
|
||||
**Gemeint sind fachlich gleichartige Konzepte in getrennten Implementierungen**, nicht bloß ähnlich formulierte Anforderungen. Ein Beispiel aus dieser Codebasis: Drucker werden als „Stammblätter" geführt, sonstige Hardware getrennt davon als „Assets" - zwei Datenhaltungen für denselben fachlichen Gegenstand, die im Zielsystem zu einem Asset-Konzept zusammengeführt werden sollen. Zwei Anforderungen, die denselben Sachverhalt nur aus Sicht verschiedener Ebenen beschreiben (etwa StRS und SwRS), sind **kein** Konsolidierungsfall - dafür sind die Tracelinks da.
|
||||
|
||||
### Ergebnisstruktur (im vorgegebenen Ausgabeverzeichnis)
|
||||
|
||||
```text
|
||||
Ergebnisse/
|
||||
StRS.md
|
||||
SyRS.md
|
||||
SwRS.md
|
||||
Traceability.md (oder Traceability.csv)
|
||||
Hypothesen.md (Sammlung aller mit [HYPOTHESE] markierten Aussagen mit offener Frage)
|
||||
Glossar.md (Domänenbegriffe, die in den Anforderungen verwendet werden)
|
||||
Analysebericht.md (Modulinventar aus Schritt 0, Abdeckungstabelle, Konsistenzcheck,
|
||||
Selbstbewertung, bekannte Lücken)
|
||||
```
|
||||
|
||||
**Erstelle ausschließlich diese 7 Dateien.** Keine Ergänzungsdateien, keine Aufteilungen wie `SwRS-Ergaenzungen.md` oder `SyRS-Teil2.md`. Wenn eine Datei zu lang wird, fahre in derselben Datei fort — die ID-Reihe macht die Reihenfolge klar. Anforderungen außerhalb dieser 7 Dateien werden von der Auswertung nicht erfasst.
|
||||
|
||||
Das Ausgabeverzeichnis wird beim Start des Laufs beigestellt. Die analysierte Codebasis wird ausschließlich gelesen und nicht verändert.
|
||||
|
||||
### Randbedingungen
|
||||
|
||||
- **Keine Halluzinationen.** Wenn ein Artefakt nicht gelesen oder eine Aussage nicht belegt werden kann, ist das offen zu legen, nicht zu erfinden.
|
||||
- **Keine Generierung von Code.** Es sollen ausschließlich Spezifikationsartefakte entstehen.
|
||||
- **Keine Annahme über nicht beigestellte Hilfsmittel.** Arbeite mit dem, was dir in diesem Lauf zur Verfügung steht. Setze keine zusätzlichen Analysewerkzeuge, Datenbankzugriffe oder laufende Systeme voraus. Stehen für eine Aussage nur indirekte Belege zur Verfügung, ist sie als `[HYPOTHESE]` zu kennzeichnen.
|
||||
- **Migrationsperspektive berücksichtigen.** Erkennbare Workarounds, Sonderfälle und überholte Logik gehören in das Feld `Übernahmewürdigkeit`, nicht in das Feld `Status`. `Status` beschreibt ausschließlich die Belegsituation (`belegt` oder `HYPOTHESE`), `Übernahmewürdigkeit` die fachliche Zukunft der Anforderung. Beide Angaben sind unabhängig voneinander: Eine gut belegte Anforderung kann ein Workaround sein, eine Hypothese kann übernahmewürdig sein.
|
||||
- **Sprache:** Deutsch für Anforderungsaussagen, technische Bezeichner (Klassen, Methoden, Spalten) bleiben in ihrer Originalsprache.
|
||||
|
||||
### Abschluss
|
||||
|
||||
Führe vor Abgabe einen **Konsistenzcheck über das gesamte Anforderungs-Set** durch und dokumentiere das Ergebnis im `Analysebericht.md`:
|
||||
- Doppelte oder mehrfach vergebene IDs
|
||||
- Anforderungen ohne Beleg
|
||||
- Anforderungen ohne Angabe zur `Übernahmewürdigkeit`
|
||||
- Tracelinks auf nicht existierende IDs
|
||||
- Inhaltlich deckungsgleiche Anforderungen, die nicht als Konsolidierungskandidat markiert sind
|
||||
- **Liste aller risikorelevanten Anforderungen** (Sicherheit, Abrechnung/Fakturierung, Berechtigungen) mit ihrer Belegsituation: ID, Titel, ob ein `PRIMÄR`-Beleg vorliegt, andernfalls die `[HYPOTHESE]`-Kennzeichnung. Diese Liste macht Verstöße gegen die risikobasierte Priorisierung im Lauf selbst sichtbar.
|
||||
- **Abgleich `Hypothesen.md` gegen die Inline-Markierungen:** Beide müssen dieselben Anforderungen nennen. `Hypothesen.md` enthält genau die Anforderungen mit `[HYPOTHESE]`-Markierung und keine zusätzlichen freien Fragen; offene Punkte ohne zugehörige Anforderung gehören in die Selbstbewertung.
|
||||
|
||||
Erstelle außerdem die **Abdeckungstabelle** auf Basis des Modulinventars aus Schritt 0: je Modul die Einstufung `tief | mittel | flach | nicht analysiert` und die Anzahl der daraus erzeugten Anforderungen. Jede Zeile des Inventars muss in der Abdeckungstabelle auftauchen.
|
||||
|
||||
Beende den Lauf mit einer kurzen Selbstbewertung im `Analysebericht.md`:
|
||||
- Wie viele Module des Inventars wurden tief, mittel, flach beziehungsweise gar nicht analysiert? Nenne absolute Zahlen, nicht nur Beispiele.
|
||||
- Wurde die Mindestabdeckung erreicht, also hat jedes Modul mindestens eine Anforderung? Falls nein: welche Module fehlen und warum?
|
||||
- An welchen Stellen war der Beleg dünn (hoher Anteil `SEKUNDÄR`/`KONTEXT` oder `[HYPOTHESE]`)?
|
||||
- Falls keine einzige Hypothese geführt wurde: Begründung, warum die Analyse ohne offene Punkte auskommt.
|
||||
- Welche Erkenntnisse legen einen Nachschlag in einer Folge-Iteration nahe?
|
||||
| Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien | Kimi-solo erstellte `SwRS-Ergaenzungen.md` und `SyRS-Ergaenzungen.md` — 18 Anforderungen lagen außerhalb der vorgegebenen Dateien und wurden vom Auswertungsskript nicht erfasst |
|
||||
| Modulabdeckung härter einfordern: >10 % `nicht analysiert` = unvollständige Erkundung | GLM-solo ließ 33 von 120 Modulen (27,5 %) unanalysiert; Kimi-solo kam auf 1/56 (1,8 %) — die Streuung zeigt, dass die Formulierung „nicht analysiert mit Begründung" zu weich war |
|
||||
|
||||
Unverändert bleiben: Prüfidee, Tracelinks, Belegklassifikation, Blockformat, Hypothesenpflicht, risikobasierte Priorisierung, Konsolidierungsbegriff und ISO-25010-Zuordnung. Werkzeugnutzung und Turn-Anzahl werden bewusst nicht vorgegeben — sie sind Teil der Untersuchung.
|
||||
|
||||
> Dieser Prompt enthält ausschließlich die **Analyseanweisung** und ist damit unabhängig von einem
|
||||
> bestimmten Werkzeug oder Modell einsetzbar. Welche Werkzeuge im jeweiligen Lauf zur Verfügung
|
||||
> stehen und wohin die Ergebnisse geschrieben werden, stellt der Versuchsaufbau beim Start bei.
|
||||
|
||||
### Werkzeugkontext (vom Versuchsaufbau vorgegeben)
|
||||
Für diesen Lauf stehen zur Verfügung: Lesen von Dateien, Suchen im Dateibestand, Auflisten von
|
||||
Verzeichnissen sowie das Ausführen rein lesender Kommandozeilenbefehle im Arbeitsverzeichnis.
|
||||
Nicht verfügbar sind: Subagenten, spezialisierte Agentenrollen, externe Werkzeugserver,
|
||||
Webzugriff.
|
||||
Triff keine Annahmen über weitere Werkzeuge und versuche nicht, nicht verfügbare
|
||||
Werkzeuge zu ersetzen.
|
||||
|
||||
### Ausgabeverzeichnis (überschreibt anderslautende Pfadangaben oben)
|
||||
Schreibe ALLE zu erzeugenden Ergebnisdateien in das Verzeichnis
|
||||
`C:\DEV\MasterArbeit\Versuche\Versuch_01\Iteration 12\google\gemma-4-e4b\solo\high\03_Lauf_2026-09-01_065255_v12.0.0-4d01\Ergebnisse\`.
|
||||
Verändere keine Dateien im Arbeitsverzeichnis (der analysierten Codebasis).
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
[
|
||||
{
|
||||
"id": "google/gemma-4-e4b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "google",
|
||||
"arch": "gemma4",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 131072,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "qwen/qwen3.8-27b",
|
||||
"object": "model",
|
||||
"type": "vlm",
|
||||
"publisher": "qwen",
|
||||
"arch": "qwen35",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "loaded",
|
||||
"max_context_length": 262144,
|
||||
"loaded_context_length": 32768,
|
||||
"capabilities": [
|
||||
"tool_use"
|
||||
]
|
||||
},
|
||||
{
|
||||
"id": "text-embedding-nomic-embed-text-v1.5",
|
||||
"object": "model",
|
||||
"type": "embeddings",
|
||||
"publisher": "nomic-ai",
|
||||
"arch": "nomic-bert",
|
||||
"compatibility_type": "gguf",
|
||||
"quantization": "Q4_K_M",
|
||||
"state": "not-loaded",
|
||||
"max_context_length": 2048
|
||||
}
|
||||
]
|
||||
+113
@@ -0,0 +1,113 @@
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"provider": {
|
||||
"lmstudio": {
|
||||
"npm": "@ai-sdk/openai-compatible",
|
||||
"name": "LM Studio (lokal)",
|
||||
"options": {
|
||||
"baseURL": "http://localhost:1234/v1",
|
||||
"apiKey": "lm-studio"
|
||||
},
|
||||
"models": {
|
||||
"google/gemma-4-e4b": {
|
||||
"name": "Gemma 4 E4B (lokal)",
|
||||
"limit": {
|
||||
"context": 32768,
|
||||
"output": 32768
|
||||
}
|
||||
},
|
||||
"qwen/qwen3.8-27b": {
|
||||
"name": "Qwen 3.8 27B (lokal)",
|
||||
"limit": {
|
||||
"context": 262144,
|
||||
"output": 32768
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"permission": {
|
||||
"*": "deny",
|
||||
"read": "allow",
|
||||
"glob": "allow",
|
||||
"grep": "allow",
|
||||
"list": "allow",
|
||||
"edit": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow"
|
||||
},
|
||||
"external_directory": {
|
||||
"*": "deny",
|
||||
"Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"../../Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse": "allow",
|
||||
"C:/DEV/MasterArbeit/Versuche/Versuch_01/Iteration 12/google/gemma-4-e4b/solo/high/03_Lauf_2026-09-01_065255_v12.0.0-4d01/Ergebnisse/**": "allow"
|
||||
},
|
||||
"bash": {
|
||||
"*": "allow",
|
||||
"rm *": "deny",
|
||||
"rmdir *": "deny",
|
||||
"mv *": "deny",
|
||||
"cp *": "deny",
|
||||
"dd *": "deny",
|
||||
"truncate *": "deny",
|
||||
"chmod *": "deny",
|
||||
"chown *": "deny",
|
||||
"ln *": "deny",
|
||||
"tee *": "deny",
|
||||
"sed -i*": "deny",
|
||||
"git checkout*": "deny",
|
||||
"git restore*": "deny",
|
||||
"git clean*": "deny",
|
||||
"git reset*": "deny",
|
||||
"git add*": "deny",
|
||||
"git commit*": "deny",
|
||||
"git push*": "deny",
|
||||
"git fetch*": "deny",
|
||||
"git pull*": "deny",
|
||||
"git remote*": "deny",
|
||||
"dotnet *": "deny",
|
||||
"msbuild *": "deny",
|
||||
"npm install*": "deny",
|
||||
"nuget *": "deny",
|
||||
"Remove-Item *": "deny",
|
||||
"Move-Item *": "deny",
|
||||
"Copy-Item *": "deny",
|
||||
"New-Item *": "deny",
|
||||
"Set-Content *": "deny",
|
||||
"Add-Content *": "deny",
|
||||
"Clear-Content *": "deny",
|
||||
"Out-File *": "deny",
|
||||
"Set-ItemProperty *": "deny",
|
||||
"Rename-Item *": "deny"
|
||||
},
|
||||
"task": "deny",
|
||||
"webfetch": "deny",
|
||||
"websearch": "deny",
|
||||
"skill": "deny",
|
||||
"question": "deny"
|
||||
},
|
||||
"agent": {
|
||||
"build": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "primary"
|
||||
},
|
||||
"general": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
},
|
||||
"explore": {
|
||||
"model": "lmstudio/google/gemma-4-e4b",
|
||||
"mode": "subagent"
|
||||
}
|
||||
},
|
||||
"default_agent": "build"
|
||||
}
|
||||
+1
@@ -0,0 +1 @@
|
||||
2026-09-01T06:52:55.3842262+02:00
|
||||
+142
@@ -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.
|
||||
+33
@@ -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 |
|
||||
+11
@@ -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? |
|
||||
+336
@@ -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
|
||||
```
|
||||
+739
@@ -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
|
||||
```
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user