Christoph SchwörerandClaude Opus 5
3d5b691bfa
Neue gueltige Zellen in Iteration 3 - claude-opus-5/solo/high: 363 Anforderungen, 99,7 % mit Primaerbeleg, Belege je Anforderung Median 2,0, 38,1 Mio. Tokens - claude-fable-5/solo/high: 241 Anforderungen, 98,3 % mit Primaerbeleg, 89,0 % PRIMAER-Anteil, vollstaendig regelkonform, 30,6 Mio. Tokens Damit sind 6 von 12 Zellen des Rasters belegt. Zwei Befunde daraus: Die Belegdichte folgt dem Modell, nicht dem Effort. Opus erreicht Median 2,0 auch auf high; alle 44 Sonnet-Laeufe lagen bei 1,0. max hebt Opus auf 3,0. Die frueher dem Effort zugeschriebene Verdopplung ist damit eingegrenzt. Die Fable-Modellverletzung ist reproduziert und abgegrenzt. Bei builtin laufen die Subagenten auf claude-opus-5[1m] statt Fable (zweiter Fall nach Iteration 1), bei solo dagegen sauber. Nicht das Modell ist die Ursache, sondern Fable in Kombination mit Delegation. Fehlmessungen, vollstaendig protokolliert - vier 429-Abbrueche (Session-Kontingent) aus dem Parallelblock 19:59; drei davon mit Teilbestand, einer ohne Ergebnis - opus-5/builtin/high zum dritten Mal gescheitert: 790,7 Mio. Tokens ueber drei Anlaeufe ohne Artefakt. Zelle mit dieser Prompt-Version nicht messbar. Skill 7.0.0 (MAJOR) - Isolationsmechanismus modusabhaengig: --safe-mode schaltet MCP-Server und Custom-Agenten ab und ist mit V2/V3 unvereinbar. Smoke-Test verifiziert: mit Flag spawned=0, ohne Flag spawned=2. Ersatz fuer custom/MCP: --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand. - 6.1.0: Pflichtpruefung leeres Ergebnisverzeichnis = Fehlmessung unabhaengig von is_error; CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; Protokollfeld Gueltigkeit - extract-subagenten.py: Start-Quittung wird nicht mehr als Ertragsmass ausgewiesen Versuch 2 und 3 vorbereitet - Prompt-Kette V1 -> V2 (02-A, angepasst an Agentendateien) -> V3 (02-B, MCP) - V2: acht Rollen inkl. nicht delegierendem ISO-29148-Orchestrator - V3: elf Rollen, fuenf Werkzeugserver, neue Belegklasse LAUFZEIT Ablaufprotokoll um Phase 6 und 7 sowie die Vorbereitung von V2/V3 ergaenzt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
154 lines
8.8 KiB
Markdown
154 lines
8.8 KiB
Markdown
# 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.
|