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>

Versuche/AblaufProtokoll.md

@@ -30,7 +30,7 @@ gleichen Bedingungen streuen.
 
 ---
 
-## 2. Chronologie in sechs Phasen
+## 2. Chronologie in sieben Phasen
 
 ### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
 
@@ -287,6 +287,192 @@ und Iteration 3 entstanden am selben Tag. Weil „Iteration" mit der Fassung der
 kollidierte, heißt diese seither **Prompt-Version**. Die Prompt-Dateien selbst blieben unverändert:
 Ihre SHA-256 sind in 33 Protokollen dokumentiert.
 
+### Phase 7 – Delegation, Effort und zwei Totalausfälle (26.08., ab 12:50)
+
+Nach den zehn `solo`-Läufen folgten drei Zellen, die die verbliebenen Stellschrauben trennen
+sollten: `builtin` mit Sonnet, `max`-Effort mit Opus, und `builtin` mit Opus.
+
+**Der Effort ist die wirksamste Einzelvariable der gesamten Reihe.** Über alle 44 Läufe auf
+`high` lag der Median konstant bei **einem** Beleg je Anforderung – genau der Befund, wegen dem
+Prompt-Version 02 geschrieben wurde und der sich unter Version 02 auf `high` sogar verschärft
+hatte. Die drei `max`-Läufe liegen bei 2,0 / 2,0 / 3,0:
+
+| Lauf | Anf. | Belege/Anf. | mit Primärbeleg | Risiko offen | Tokens |
+|---|---:|---:|---:|---:|---:|
+| `a8f5` | 380 | 2,0 | 95,5 % | 0 von 112 | 67,5 Mio. |
+| `37c5` | 434 | 2,0 | **100 %** | 0 von 100+ | 77,3 Mio. |
+| `fcdf` | 446 | **3,0** | 98,2 % | 0 von 139 | 116,2 Mio. |
+
+Alle drei erfüllen sämtliche fünf Regelkriterien. **Damit kippt auch die Anti-Korrelation:** Über
+die zehn `solo`/`high`-Läufe liefen Anforderungszahl und Belegqualität gegeneinander
+(Pearson −0,63, Spearman −0,70); auf `max` treten beide zusammen auf. Der Zielkonflikt war kein
+Gesetz, sondern Folge zu knappen Aufwands. Das beantwortet zugleich die in Abschnitt 8 offene
+Frage nach dem Fable-Block teilweise: Der Verbrauchssprung dort kam **nicht** allein vom Modell.
+
+**`max` zeigt sich nicht in Thinking-Tokens.** `a8f5` liegt mit 51.019 im Bereich der
+`high`-Läufe (33.051–55.760). Der Mehraufwand steckt in Turns und Laufzeit: 210 bis 371 Turns,
+1:34 bis 2:33 Stunden. Die Vermutung aus Iteration 1, `max` sei an den Thinking-Token-Werten
+erkennbar, trägt nicht.
+
+**Bei `builtin` entscheidet die Beauftragung der Subagenten, nicht deren Anzahl.** Drei Läufe,
+gleicher Prompt, gleiches Modell:
+
+| Lauf | Subagenten | Auftragsart | Anf. | mit Primärbeleg |
+|---|---:|---|---:|---:|
+| `4048` | 6 | „concrete, citable **FACTS only** … find the **EXACT enforcing location**" | 185 | **97,8 %** |
+| `fb24` | 31 (2 Ebenen) | „Research … M01–M20" mit Faktenpflicht | 383 | **96,9 %** |
+| `f8b4` | 8 | „**quickly inspect** … open **1-3 representative files**" | 276 | **46,4 %** |
+
+Aus einer Stichprobe von ein bis drei Dateien lässt sich kein Primärbeleg gewinnen – die
+durchsetzende Stelle liegt fast nie in der Datei, die repräsentativ aussieht. Damit hat
+Befund 6.3 erstmals eine **inhaltliche** Erklärung statt nur einer Zahl. Genau dafür wurde die
+Erfassung der Subagenten-Prompts in Skill 3.3.0 eingeführt.
+
+Nebenbefund: `fb24` verlagerte 63,5 % seines Verbrauchs auf die Subagenten, `4048` sogar 78,4 %,
+bei nur 26 Turns im Hauptagenten. Delegation verschiebt den Verbrauch, ohne ihn zwangsläufig zu
+erhöhen – anders als in Iteration 1, wo `builtin` deutlich über `solo` lag.
+
+**Zwei Totalausfälle in der Zelle Opus + `builtin`.** Beide Läufe scheiterten, auf verschiedene
+Weise, und verbrauchten zusammen **586 Mio. Tokens ohne verwertbares Ergebnis**:
+
+- `116d` – **stiller Fehlschlag.** `is_error: false`, `subtype: success`,
+  `terminal_reason: completed` – und **null Ergebnisdateien**. Der Hauptagent hatte zehn
+  Subagenten im Hintergrund gestartet und seinen Turn beendet; der Headless-Modus wartete 600 s
+  und brach ab. Der einzige Hinweis stand in `Stderr.log`. Verbraucht: 193,4 Mio. Tokens.
+- `9d9e` – **API-Abbruch**, HTTP 429, „You've hit your session limit". 34 Subagenten, davon 24
+  von Subagenten gestartet, 22 weitere am Nebenläufigkeitslimit abgewiesen. Verbraucht:
+  392,9 Mio. Tokens, eine Ergebnisdatei von sieben.
+
+Der stille Fehlschlag ist der methodisch wichtigere: **`is_error` erkennt ihn nicht.** Ohne den
+Blick ins Ergebnisverzeichnis wäre der Lauf als gültiger Messpunkt mit „0 Anforderungen" in den
+Modellvergleich eingegangen.
+
+**Die Modellbedingung ist bei Delegation nicht über `--model` herstellbar.** `9d9e` weist neben
+`claude-opus-5` auch `claude-sonnet-5` mit 18,5 Mio. Tokens (4,72 %) aus – der zweite
+dokumentierte Fall nach Fable in Iteration 1. Beide betreffen ausschließlich den Modus `builtin`.
+Für saubere Modellvergleiche ist `solo` zu verwenden oder die Modellbindung der Subagenten
+gesondert zu belegen. Das betrifft Versuch 2 und 3 unmittelbar, die beide auf Delegation setzen.
+
+**Vier weitere Messinstrument-Defekte gefunden und behoben:**
+
+- *Abgewiesene Subagenten wurden als Subagenten gezählt* (Skill 4.5.0 / heute 6.1.0-Zweig).
+  `fb24` meldete 21 gefundene gegenüber 13 erwarteten Aufrufen; die Differenz waren 8 Absagen am
+  Nebenläufigkeitslimit, die im Transkript wie Starts aussehen. Nach der Trennung stimmen alle
+  drei Läufe exakt. Die Zahl der Absagen ist selbst eine Messgröße für die *beabsichtigte*
+  Parallelität.
+- *Die Rückgabe eines Hintergrund-Subagenten ist eine Start-Quittung*, keine Befunde. Die
+  einheitlichen 1.093 Zeichen, die als „Ergebnis" protokolliert wurden, sind der Text „Async
+  agent launched successfully …". Als Ertragsmaß war das wertlos.
+- *Subagenten-Transkripte* werden unter `<temp>\<session>\tasks\<agentId>.output` angelegt,
+  bleiben aber **leer** – geprüft an 33 Dateien aus zwei Läufen. Die bisherige Aussage, sie seien
+  nicht auswertbar persistiert, gilt damit unverändert.
+- *Gültigkeitsprüfung ergänzt:* leeres Ergebnisverzeichnis oder Abbruchmeldung in `Stderr.log`
+  bedeutet Fehlmessung, unabhängig von `is_error`. Vorbeugend setzt der Ausführungsabschnitt
+  jetzt `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`.
+
+**Ein Befund zur Belegquelle, den ein Agent selbst entdeckte.** `116d` hielt im Abschlusstext
+fest, die Codebasis enthalte „keine `.git`-Historie und keine SQL-Migrationsskripte". Das trifft
+zu und gilt für **alle** Läufe der Reihe: Seit die Codebasis als Dateien ins Arbeitsrepo
+übernommen wurde, ist die Entwicklungshistorie der ERP-Suite nicht mehr erreichbar. Der Prompt
+fordert Commit-Messages, Tickets und Release Notes in Schritt 2 ausdrücklich als Artefaktquelle –
+diese Quelle steht der gesamten Versuchsreihe nicht zur Verfügung.
+
+### Vorbereitung von Versuch 2 und 3
+
+Beide Versuchsverzeichnisse wurden angelegt und nach den Vorgaben aus @tab_versuchskonfiguration
+konfiguriert. Die Prompt-Kette folgt der dort festgelegten Ableitung **V1 → V2 → V3**.
+
+| Artefakt | SHA-256 | Ableitung |
+|---|---|---|
+| `Versuch_02/01_Prompt.md` | `DCDC0E3F…B71BCF` | Prompt-Version 02-A: aus V1, angepasst an Agentendateien |
+| `Versuch_02/01_Agents.json` | `6943EECD…AF1696` | acht Rollen |
+| `Versuch_03/01_Prompt.md` | `E65A696C…6A06E1` | Prompt-Version 02-B: aus V2, angepasst an MCP-Server |
+| `Versuch_03/01_Agents.json` | `EDCB8001…C49B55` | elf Rollen |
+| `Versuch_03/01_MCP.json` | `F08840F7…5EE2DB` | fünf Werkzeugserver |
+
+**Die Anpassung „an Agentendateien" ist ein einziger neuer Abschnitt: Arbeitsteilung.** Er nennt
+keine Rolle und schreibt keinen Zuschnitt vor. Er schließt die Lücken, die entstehen, wenn nicht
+mehr ein Bearbeiter die ganze Kette durchläuft: Prompt-Version 02 ordnet Schritte zeitlich,
+vergibt fortlaufende IDs und verlangt am Ende einen Konsistenzcheck – bei verteilter Bearbeitung
+ist nichts davon von selbst erfüllt. Die vier Kernsätze: ID-Bereiche vorab und
+überschneidungsfrei; die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter; die
+Mindestabdeckung gilt für das **gemeinsame** Inventar, nicht je Ausschnitt; der Konsistenzcheck
+gilt dem zusammengeführten Ergebnis. Der Abschnitt ist bei einem einzelnen Bearbeiter
+wirkungslos, sodass der Prompt auch für einen `solo`-Lauf gültig bleibt.
+
+**Die Rollen sind aus den Messungen abgeleitet.** Drei getrennte Autoren je Ebene gegen die
+Verteilungsstreuung (92,7 % StRS bis 89,4 % SwRS bei identischem Prompt); ein `faktenermittler`
+nach dem Muster des erfolgreichsten `builtin`-Laufs samt Stichprobenverbot; ein neuer
+`belegpruefer`, der zitierte Primärbelege öffnet und prüft, ob die Einstufung trägt; ein
+`konsistenzpruefer`, der seinen Risikobegriff offenlegen muss, weil ein Lauf „alle 36 gedeckt"
+meldete, während die maschinelle Prüfung 51 risikorelevante Anforderungen fand.
+
+**Der ISO-29148-Orchestrator ist als konsolidierende, nicht delegierende Rolle umgesetzt.** Er
+startet keine Subagenten und schreibt keine Anforderungen, sondern stellt her, was erst am
+zusammengeführten Bestand entsteht: durchgängige Nummerierung samt mitgezogener Verweise,
+beidseitig geschlossene Traceability, eine aus dem Gesamtbestand erzeugte Hypothesenliste und die
+Abdeckungstabelle über das gemeinsame Inventar. Sein Schwerpunkt liegt auf den Nahtstellen
+zwischen den Ausschnitten – dort sitzen die Fehler verteilter Bearbeitung. Ein **delegierender**
+Orchestrator wäre die naheliegende, aber messtechnisch schlechtere Lösung gewesen: Er erzeugte
+eine zweite Delegationsebene, deren Subagenten-Prompts nicht protokollierbar sind – bei `fb24`
+blieben so 18 von 31 Aufrufen unerfassbar.
+
+**Versuch 3 erhielt eine eigene Prompt-Version.** Prompt-Version 02-A schreibt „statische
+Analyse, keine Ausführung" vor und begrenzt die Quellen auf das Arbeitsverzeichnis; ein live
+gestartetes ERP verletzt beides. Geändert wurde nur das Nötige: Quellenbeschränkung erweitert,
+Schritt 2b „Beobachtung am laufenden System" (ausdrücklich lesend), neue Belegklasse `LAUFZEIT`
+als **nachrangig** gegenüber `PRIMÄR`, und Kennzeichnung fremden Wissens. Der Abschnitt
+Arbeitsteilung wird aus V2 unverändert geerbt.
+
+Fünf Werkzeugserver sind vorgesehen: `serena` (Symbol-Navigation), `mssql` (Datenbank-Inspektion,
+read-only), `windows-mcp` und `playwright` (GUI-Beobachtung für Desktop-Client und Blazor-Portal)
+sowie `context7`. Letzterer steht nicht in der Aufzählung der Arbeit und ist eine bewusst
+hinzugenommene Erweiterung; er ist zugleich der einzige der fünf, der nicht lokal betrieben wird.
+
+Zwei Server wurden **ausgeschlossen**: `memory`, weil er Zustand zwischen Läufen trägt und damit
+die Unabhängigkeit der Wiederholungsmessungen zerstört, und `sequential-thinking`, weil er den
+`--effort`-Parameter dupliziert – zwei Variablen gleichzeitig zu verändern war schon beim
+Fable-Block der Fehler.
+
+**Ein Blocker, gefunden bevor er einen Messlauf gekostet hat: `--safe-mode` ist mit V2 und V3
+unvereinbar.** Das Flag schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and
+agents" ab – also genau das, was beide Versuche untersuchen. 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}` |
+
+Der Fehler wäre **still** geblieben: `--agents` hätte keine Wirkung gehabt, der Lauf wäre
+fehlerfrei durchgelaufen und hätte Anforderungen erzeugt – nur ohne die Rollen, die den Versuch
+ausmachen. Er wäre als V2-Lauf protokolliert worden und wäre in Wahrheit ein V1-Lauf gewesen.
+
+Der Ersatz (Skill 7.0.0, MAJOR): kein `--safe-mode` in den Modi `custom` und bei MCP-Einsatz,
+stattdessen `--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`.
+Gegengeprüft mit derselben Werkzeugabfrage: nichts vorgeladen, keine Skills, kein Webzugriff,
+alle Rollen verfügbar. Bemerkenswert dabei: Ohne die Sperre lädt die CLI **16 global installierte
+Skills** – darunter `code-review`, `security-review`, `run` und `init`. `--setting-sources ''`
+unterdrückt sie nicht.
+
+Der Ersatz deckt Plugins, Hooks und Output-Styles nicht ab. Auf der Versuchsmaschine ist davon
+nichts konfiguriert – geprüft: `~/.claude/settings.json` enthält nur `model` und
+`agentPushNotifEnabled`, kein `hooks`; kein `plugins`- und kein `output-styles`-Verzeichnis. Das
+ist eine Eigenschaft der Umgebung, keine Garantie, weshalb der Skill vor jedem `custom`-Lauf eine
+Umgebungsprüfung verlangt. **Läufe im Modus `custom` sind hinsichtlich der Isolation damit nicht
+unmittelbar mit den `solo`- und `builtin`-Läufen vergleichbar**; der Unterschied ist benannt und
+auf Plugins, Hooks und Output-Styles begrenzt.
+
+Nebenbefund derselben Prüfung: In den User-Settings steht `model: opus[1m]`. Das ist die Quelle
+der zwei dokumentierten Modellabweichungen bei Delegation – und `--safe-mode` hat sie nie
+verhindert, wirkt hier also weder positiv noch negativ.
+
+**Offene Punkte vor dem ersten Lauf beider Versuche:** `extract-subagenten.py` ist nicht gegen
+`custom`-Agententypen geprüft; die Modellbedingung ist bei Delegation über `--model` allein nicht
+herstellbar; für V3 sind die Serverversionen nicht gepinnt, und der Zustand des laufenden Systems
+– Datenbankstand, Mandant, Datenart – ist als Teil des Untersuchungsgegenstands je Lauf zu
+erfassen.
+
 ---
 
 ## 3. Entwicklung des Prompts
@@ -548,9 +734,22 @@ Belegqualität zu halten – dann wäre die Änderung zurückzunehmen.
 
 ## 8. Grenzen und offene Punkte
 
-**Nicht geklärt:** Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt –
-beide Variablen wechselten gleichzeitig. Ein Fable-Block auf `high` oder ein Sonnet-Block auf
-`max` würde die Frage entscheiden.
+**Teilweise geklärt:** Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt –
+beide Variablen wechselten gleichzeitig. Die Zelle `claude-opus-5 / solo / max` (Iteration 3)
+zeigt, dass der Effort allein Verbrauch **und** Belegdichte erheblich anhebt. Vollständig
+isoliert wäre die Frage erst durch einen Opus-`high`-Block unter denselben Bedingungen –
+gleicher Snapshot, gleiche Prompt-Version.
+
+**Nicht messbar in der bisherigen Anlage:** Die Zelle `claude-opus-5 / builtin / high` ist
+zweimal gescheitert (Zeitlimit, Session-Kontingent) und hat dabei 586 Mio. Tokens ohne Ergebnis
+verbraucht. Vor einer Wiederholung ist zu entscheiden, ob die Kombination Opus + Delegation +
+Prompt-Version 02 überhaupt sinnvoll messbar ist.
+
+**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.
 
 **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