# Versuch 03 – Werkzeugzugriff (V3)

Wie Versuch 2, zusätzlich externe Werkzeugserver – einschließlich Zugriff auf das **laufende**
ERP-System. Agentenmodus `custom`, dazu `--mcp-config 01_MCP.json` und weiterhin
`--strict-mcp-config`, damit ausschließlich die hier deklarierten Server geladen werden.

## Dateien

| Datei | SHA-256 | Zweck |
|---|---|---|
| `01_Prompt.md` | `E65A696C…6A06E1` | Analyseanweisung, Prompt-Version **02-B** |
| `01_Agents.json` | `EDCB8001…C49B55` | elf Agentenrollen |
| `01_MCP.json` | `F08840F7…5EE2DB` | fünf Werkzeugserver |

## Die Prompt-Kette

`Versuch_01/02_Prompt.md` → `Versuch_02/01_Prompt.md` (02-A, angepasst an Agentendateien) →
`Versuch_03/01_Prompt.md` (02-B, angepasst an MCP-Server).

V3 erbt damit den Abschnitt **Arbeitsteilung** aus V2 unverändert. Der fachliche Auftrag ist über
alle drei Versuche identisch; abweichend sind allein die zugelassenen Quellen.

## Warum der Prompt für V3 geändert werden musste

Prompt-Version 02-A schreibt **„statische Analyse, keine Ausführung"** vor und begrenzt die
Quellen auf „die im Arbeitsverzeichnis liegenden Artefakte". Ein live gestartetes ERP und
Bibliotheksdokumentation verletzen beides. Ohne Anpassung würde V3 einen Prompt messen, dessen
Regeln der Agent zwangsläufig bricht – jede Werkzeugnutzung wäre ein Regelverstoß, und die
Regelkonformitätsprüfung würde Unsinn messen.

| Änderung | Grund |
|---|---|
| Quellenbeschränkung um Beobachtung am laufenden System erweitert | sonst ist Werkzeugnutzung regelwidrig |
| Neuer Schritt 2b „Beobachtung am laufenden System", ausdrücklich lesend | dynamische Analyse ist der Untersuchungsgegenstand von V3 |
| Neue Belegklasse `LAUFZEIT`, nachrangig gegenüber `PRIMÄR` | beobachtetes Verhalten belegt nicht, **wo** die Regel durchgesetzt wird |
| Herkunft fremden Wissens kennzeichnen | trennt Framework-Verhalten von Geschäftsregeln |

Unverändert: Auftrag, Scope, Arbeitsteilung, Vorgehensschritte 0 bis 6, Blockformat, Prüfidee,
Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur.

**`LAUFZEIT` ersetzt `PRIMÄR` nicht.** Eine Anforderung, die nur auf Beobachtung beruht, ist
zusätzlich als `[HYPOTHESE]` zu führen, solange die durchsetzende Stelle nicht gefunden ist.
Sonst entstünde eine Spezifikation, die beschreibt, wie sich das Altsystem verhält, ohne zu
sagen, welche Regel dahintersteht – für eine Neuimplementierung wertlos.

## Die elf Rollen

Die acht aus Versuch 2 – darunter der nicht delegierende `iso29148-orchestrator` – plus drei
werkzeuggestützte:

| Rolle | Werkzeug | Beitrag |
|---|---|---|
| `laufzeitanalyst` | windows-mcp, playwright | Oberflächenverhalten, Feldvalidierungen, **Fehlermeldungen im Wortlaut** |
| `datenanalyst` | mssql (nur `SELECT`) | tatsächliche Wertebereiche, Wirksamkeit von Constraints, Nutzungsgrad |
| `frameworkabgrenzer` | context7 | trennt Framework-Standardverhalten von echten Geschäftsregeln |

Der größte Hebel des `laufzeitanalyst` ist nicht das Bildschirmfoto, sondern die **Fehlermeldung
im Wortlaut**: Sie lässt sich per Volltextsuche in die durchsetzende Codestelle zurückverfolgen
und liefert dem `faktenermittler` damit den Suchbegriff für einen Primärbeleg. Dessen Prompt
wurde für V3 um genau diesen Hinweis ergänzt.

Der `datenanalyst` liefert als Einziger einen harten Beleg für die Einstufung `veraltet`: Ein im
Code definierter Status, der in keinem Datensatz vorkommt, ist toter Code. Umgekehrt beweisen
Datensätze, die eine im Code geprüfte Regel verletzen, dass die Regel **nicht durchgesetzt**
wird – ein Befund, der die Belegeinstufung einer Anforderung ändert.

## Die fünf Werkzeugserver

| Server | Beitrag | In der Arbeit genannt? |
|---|---|---|
| `serena` | semantische Codenavigation: Referenzsuche, Aufrufhierarchie | ja (Symbol-Navigation) |
| `mssql` | Datenlage des laufenden Systems, **read-only** | ja (Datenbank-Inspektion) |
| `windows-mcp` | Bedienung des WPF-Clients, Bildschirmfotos | ja (GUI-Beobachtung, optional) |
| `playwright` | Blazor-Webportal (Nexus) und REST-API | ja (GUI-Beobachtung, optional) |
| `context7` | Bibliotheksdokumentation für den `frameworkabgrenzer` | **nein – bewusste Erweiterung** |

`serena` trifft die gemessene Schwachstelle direkt: `grep` findet Text, nicht „wer setzt diese
Regel durch". `playwright` deckt den Systemteil ab, den `windows-mcp` nicht erreicht – die
Codebasis enthält neben dem WPF-Client ein Blazor-Portal und eine REST-API.

**`context7` steht nicht in der Aufzählung der Arbeit** und ist eine bewusst hinzugenommene
Erweiterung. Zu beachten: Er ist der einzige der fünf Server, der **nicht lokal** betrieben wird.

**Ausgeschlossen, mit Begründung:**

`memory` (Knowledge Graph) – **der kritische Fall.** Er trägt Zustand zwischen Läufen.
Wiederholungsmessungen wären nicht mehr unabhängig: Lauf 2 profitierte von Lauf 1, und die
Varianzaussage, für die in Versuch 1 siebzehn Läufe erhoben wurden, wäre wertlos. Soll er dennoch
eingesetzt werden, muss der Speicher vor jedem Lauf nachweislich geleert und das im Protokoll
belegt werden.

`sequential-thinking` – dupliziert den `--effort`-Parameter, der sich in Versuch 1 als wirksamste
Einzelvariable erwiesen hat (Belegdichte Median 1,0 auf `high` gegenüber 2,0–3,0 auf `max`).
Beide gleichzeitig zu variieren wiederholte den Fehler des Fable-Blocks aus Iteration 1, wo
Modell und Effort zusammen wechselten und der Befund unzuordenbar blieb.

`fetch` – unbegrenzter Webzugriff macht die Herkunft von Aussagen unprüfbar; `context7` ist die
engere, zitierbare Variante.

## Wichtig: `--safe-mode` ist hier nicht verwendbar

`--safe-mode` schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins,
hooks, **MCP servers, custom commands and agents**, output styles, …)" ab – also genau das, was
dieser Versuch untersucht. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur das
Flag variiert):

| Konfiguration | `spawned` | `by_type` |
|---|---:|---|
| mit `--safe-mode` | **0** | leer – „die Rollen sind nicht in der Agent-Registry registriert" |
| ohne `--safe-mode` | **2** | `{"modulinventar": 1, "konsistenzpruefer": 1}` |

**Ohne diesen Test wäre der erste Lauf stillschweigend als V1-Lauf gemessen worden**: `--agents`
hätte keine Wirkung gehabt, der Lauf hätte fehlerfrei durchlaufen und Anforderungen erzeugt – nur
eben ohne die Rollen, die den Versuch ausmachen.

**Der Ersatz** (Skill 7.0.0): kein `--safe-mode`, stattdessen `--strict-mcp-config` und
`--disallowedTools Skill WebSearch WebFetch SlashCommand` zusätzlich zur 33er-Denylist.
Gegengeprüft mit derselben Werkzeugabfrage: `VORGELADEN: NICHTS VORGELADEN` · `SKILLS: KEINE` ·
`WEB: KEIN WEBZUGRIFF` · alle Rollen verfügbar. Ohne die Sperre lädt die CLI **16 global
installierte Skills** (darunter `code-review`, `security-review`, `run`, `init`);
`--setting-sources ''` unterdrückt sie nicht.

**Was der Ersatz nicht abdeckt:** Plugins, Hooks und Output-Styles. Auf der Versuchsmaschine ist
davon nichts konfiguriert, das ist aber eine Eigenschaft der Umgebung und keine Garantie. Der
Skill verlangt deshalb vor jedem Lauf eine Umgebungsprüfung, deren Ergebnis ins Protokoll geht.

**Folge für die Vergleichbarkeit:** Läufe dieses Versuchs sind hinsichtlich der Isolation nicht
unmittelbar mit den `solo`- und `builtin`-Läufen aus Versuch 1 vergleichbar. Der Unterschied ist
benannt und begrenzt – er betrifft Plugins, Hooks und Output-Styles, nicht CLAUDE.md, Skills,
Webzugriff oder MCP.

## Vor dem ersten Lauf zu erledigen

1. **Zugangsdaten in `01_MCP.json`** sind Platzhalter. Der MSSQL-Benutzer muss ein reiner
   Lesebenutzer sein – die Leseregel im Agentenprompt ist eine Anweisung, keine Absicherung.
   Die ausgefüllte Datei gehört **nicht** ins Repository.
2. **Serverversionen festhalten.** `@latest` und `uvx` ohne Versionsbindung machen den Lauf
   unreproduzierbar. Vor dem ersten Messlauf pinnen und die Versionen ins Protokoll übernehmen.
3. **Zustand des laufenden Systems protokollieren.** Ein laufendes ERP mit eigener Datenbank ist
   Teil des Untersuchungsgegenstands, steckt aber nicht im Git-Snapshot. Datenbankstand, Mandant
   und Datenart (Produktiv-, Test- oder Demodaten) sind je Lauf festzuhalten; sonst sind
   V3-Läufe untereinander nicht vergleichbar.
4. **Skill erweitern:** Es gibt noch kein Protokollfeld für die MCP-Konfiguration. Pfad und
   SHA-256 von `01_MCP.json` gehören wie die Agentendefinition ins Protokoll.
5. **Modellbedingung.** Wie in V2: bei Delegation über `--model` allein nicht herstellbar – nach
   jedem Lauf `modelUsage` prüfen.
6. **`extract-subagenten.py`** ist nicht gegen `custom`-Agententypen geprüft.

## Einordnung

V3 ändert Werkzeugkonfiguration **und** Prompt und eröffnet damit nach der Regel aus Skill 4.4.0
zwingend eine **neue Iteration**. Läufe aus V1, V2 und V3 sind nicht poolbar; der Vergleich
zwischen ihnen ist der Zweck, nicht die Wiederholungsmessung.