Iteration 3: Modell- und Modusraster erweitert, Skill 7.0.0, V2/V3 vorbereitet
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>
This commit is contained in:
Christoph Schwörer
co-authored by
Claude Opus 5
Claude Opus 5
parent
affde3a45f
commit
3d5b691bfa
@@ -0,0 +1,153 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user