Masterarbeit/Versuche/Versuch_03/README.md

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.