Masterarbeit/Versuche/AblaufProtokoll.md

# Ablaufprotokoll der Versuchsdurchführung

**Zeitraum:** 25.–31. August 2026
**Ablage der Läufe:** `Versuche/Versuch_01/Iteration <N>/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/`
**Untersuchungsgegenstand:** c-entron ERP-Suite, eingefrorener Snapshot `79c1142`
**Zweck dieses Dokuments:** Grundlage für den Ergebnisteil der Arbeit (Kapitel 5 und 6).

Festgehalten wird, wie Prompt und Versuchsaufbau schrittweise entstanden sind, welche Läufe
durchgeführt wurden und welche Erkenntnisse sich daraus ergeben haben. Der methodisch
wesentliche Punkt: **Der Versuchsaufbau ist nicht vorab fertig gewesen, sondern an den Läufen
gewachsen.** Jede Änderung geht auf eine konkrete Beobachtung zurück. Diese Kopplung ist hier
dokumentiert, damit im Ergebnisteil nachvollziehbar bleibt, welche Messung unter welchen
Bedingungen entstand.

---

## 1. Ausgangslage

Zu Beginn lagen vor:

- ein Initial-Prompt (`Versuche/Versuch_01/01_Prompt.md`) mit der Analyseanweisung nach
  ISO/IEC/IEEE 29148, abgestimmt auf die RRE-Methodenkette aus Kapitel 4
- ein Skill `run-experiment` (Version 1.0.0), der den Prompt als Headless-Lauf ausführt und ein
  Messprotokoll schreibt
- die Codebasis als eigenständiges Git-Repository mit aktivem GitHub-Remote

Nicht vorhanden waren: eine belastbare Isolationsstrategie, eine Definition der zu erhebenden
Messgrößen über Tokens und Dauer hinaus, und jede Vorstellung davon, wie stark Läufe unter
gleichen Bedingungen streuen.

---

## 2. Chronologie in acht Phasen

### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)

Der erste Lauf offenbarte sofort ein Grundproblem: Das Codebasis-Verzeichnis enthielt genau die
Dinge, die die Versuchsbedingung „keine Agentendateien, keine MCP-Server" ausschließt – eine
`CLAUDE.md` mit 201 Zeilen Projektkontext, `AGENTS.md`, drei projektspezifische Subagenten,
34 Skill-Definitionen, sechs Slash-Commands, elf Serena-Memories und einen aktiven MCP-Server.

Diese Dateien wurden vor dem Lauf gelöscht und danach per `git restore` zurückgesetzt.

**Ergebnis:** 96 Anforderungen, 13,1 Mio. Tokens, **36 Permission-Denials** (32 × Bash,
4 × PowerShell). Der Lauf war unter `--permission-mode acceptEdits` gestartet – dieser Modus
erlaubt Dateibearbeitungen, aber keine Shell-Ausführung. Der Agent wich auf Read, Grep und Glob
aus; Verzeichnisinventuren und Dateizählungen standen ihm nicht zur Verfügung. Von rund 85
Business-Logic-Modulen blieben 55 bis 60 unanalysiert.

**Auslöser für die erste große Skill-Änderung.**

### Phase 2 – Werkzeugfreigabe, Isolation und der eingefrorene Snapshot (13:49–15:00)

Zwei Entscheidungen fielen zusammen:

**Shell-Zugriff wird Standard.** `--allowedTools "Bash" "PowerShell"` mit einer Denylist von 33
Einträgen für schreibende und bauende Kommandos. Die Read-only-Eigenschaft der Codebasis wird
weiterhin über den Vorher/Nachher-Vergleich per `git status` nachgewiesen; die Denylist senkt das
Risiko, ersetzt die Verifikation aber nicht.

**Isolation über `--safe-mode` – und die Erkenntnis, dass das nicht reicht.** Ein Kontrolltest
belegte: `--safe-mode` unterdrückt zuverlässig das *Vorladen* von `CLAUDE.md` als
Systemanweisung – ohne das Flag zitiert der Agent deren Inhalt, mit dem Flag antwortet er
„NICHTS VORGELADEN". Es verhindert jedoch **nicht**, dass der Agent diese Dateien mit
Shell-Zugriff selbst *liest*. Im Smoke-Test tat er genau das.

Konsequenz: Die KI-Konfigurationen wurden **dauerhaft aus der Codebasis entfernt** (Commit
`79c1142`, 92 Dateien), das GitHub-Remote entkoppelt und der Stand als Versuchssnapshot
eingefroren. Damit ist die Bedingung „keine Agentendateien" eine Eigenschaft des Untersuchungs-
gegenstands und muss nicht pro Lauf hergestellt werden.

**Lauf 2 brach nach 24 Minuten mit einem API-Transportfehler ab** („The response stopped
arriving"), nachdem vier von sieben Artefakten geschrieben waren. Kein Konfigurationsproblem –
`permission_denials` war 0.

**Lauf 3** lief vollständig durch: 106 Anforderungen, 11,5 Mio. Tokens, **0 Denials**,
23:40 statt 31:31. Schneller, sparsamer und ergiebiger als Lauf 1 – die Werkzeugfreigabe schien
sich in jeder Dimension auszuzahlen.

### Phase 3 – Der Varianzbefund (15:05–19:31)

**Lauf 4** unter identischer Konfiguration lieferte **55 Anforderungen** – knapp die Hälfte von
Lauf 3 – bei *höheren* Kosten. Der Agent hatte diesmal **keinen einzigen Subagenten** gestartet
und stattdessen 147 eigene Turns absolviert.

Das war der Wendepunkt der Reihe. Die naheliegende Erklärung – die Subagentenzahl bestimmt den
Ertrag – hielt der nächsten Messung nicht stand: **Lauf 5** startete 14 Subagenten und lieferte
**325 Anforderungen** bei 52,7 Mio. Tokens; **Lauf 6** startete ebenfalls 7 wie Lauf 3, lieferte
aber **189 statt 106** Anforderungen bei dreifachem Verbrauch.

Nicht die *Anzahl* der Subagenten erklärt die Streuung, sondern die *Freiheit*, die Analyse
überhaupt selbst zu zerlegen.

Um das zu prüfen, wurde der Modus `solo` eingeführt: `Task`, `Agent` und `Workflow` gesperrt,
sodass keine Delegation möglich ist. Ein Verifikationstest bestätigte die Sperre (`spawned: 0`,
Antwort „KEINE SUBAGENTEN MOEGLICH") und deckte dabei auf, dass der Agent nach der Sperre von
`Task`/`Agent` auf `Workflow` auswich – dieses Werkzeug orchestriert ebenfalls Subagenten und
musste ergänzt werden.

**Fünf Solo-Läufe** (42, 82, 60, 73, 67 Anforderungen) gegen **neun Builtin-Läufe** ergaben:

| | V1 (`solo`) | V1b (`builtin`) |
|---|---|---|
| Anforderungen | 42 – 82 (Faktor 2,0) | 55 – 325 (Faktor 5,9) |
| Tokens | 4,4 – 12,6 Mio. (Faktor 2,9) | 11,5 – 52,7 Mio. (Faktor 4,6) |
| Median Tokens | 5,1 Mio. | 30,1 Mio. |

**Zentraler Befund der Reihe.** Die selbstgewählte Zerlegung in Subagenten ist die dominierende
Störgröße. Wird sie unterbunden, halbiert sich die Streuung mehr als, und der Verbrauch sinkt um
Faktor 6.

### Phase 4 – Modellvergleich und die Grenzen der Steuerbarkeit (19:59–23:10)

Um zu prüfen, ob die Streuung modellabhängig ist, wurde dieselbe Bedingung mit zwei weiteren
Modellen wiederholt.

**Opus 5, solo, fünf Läufe:** 71 – 182 Anforderungen (Median 114), 13,6 – 24,9 Mio. Tokens
(Median 22,8). Gegenüber Sonnet: 1,7-mal mehr Anforderungen bei 4,5-fachem Verbrauch, also rund
das 2,7-fache an Tokens je Anforderung. **Die Streuung blieb im selben Rahmen** – der
Modellwechsel verschiebt das Niveau, nicht die Stabilität.

**Fable 5, solo, Effort `max`, zwei Läufe:** 207 und 148 Anforderungen bei 24,2 und 31,1 Mio.
Tokens – der höchste Solo-Verbrauch der Reihe, vom nominell sparsamsten Modell. Die
Thinking-Tokens (35.220 und 39.609) übertreffen jeden der 21 Vorläufe deutlich; der bisherige
Höchstwert lag bei 24.179. Das spricht für den Effort als Treiber, ist aber **nicht beweisbar**,
weil Modell und Effort gleichzeitig gewechselt wurden.

**Fable 5, builtin – ein Fehlschlag mit Erkenntniswert.** `--model claude-fable-5` steuerte nur
den Hauptagenten. Die 13 Subagenten liefen auf **`claude-opus-5[1m]`**, dem Standardmodell aus
den Sitzungseinstellungen. Auf sie entfielen 136,7 von 150,3 Mio. Tokens – **91 %**. Eine
Gegenprüfung über alle 24 Läufe grenzte den Fall eindeutig ein: Sonnet und Opus werden an
Subagenten durchgereicht, Fable nicht.

**Konsequenz:** Bei Modus `builtin` ist das Modell nicht allein durch das Flag festgelegt. Der
Abgleich der tatsächlich eingesetzten Modelle wurde zur Pflichtprüfung.

### Phase 5 – Nachbereitung und Ausrichtung auf die Arbeit (26.08.)

Nach Abschluss der Läufe folgte die Konsolidierung. Sie ist kein bloßes Aufräumen: Mehrere
Schritte haben Messfehler aufgedeckt oder die Belastbarkeit der Ergebnisse erst hergestellt.

**Aufwandsgröße von Kosten auf Tokenverbrauch umgestellt** (Skill 3.5.0). USD-Beträge hängen an
Preisliste und Modellwahl und veralten; Token sind die unmittelbare Verbrauchsgröße. Bei der
Umstellung fiel auf, dass sich die berichteten Streuungsfaktoren ändern: In Dollar lag V1 gegen
V1b bei Faktor 2,1 zu 5,6, in Token bei 2,9 zu 4,6. Cache-Read-Token werden günstiger
abgerechnet als Output-Token – eine reine Tokensumme gewichtet sie gleich, der Preis nicht.
Die inhaltliche Aussage bleibt, der Abstand ist geringer als die Dollarwerte nahelegten.

**Verschachtelte Subagenten verifiziert** (Skill 3.6.0). Bis dahin war unbelegt, ob Subagenten
auf Tiefe 2 in die Tokensumme einfließen. Ein Kontrolltest mit erzwungener Kaskade, bei dem
ausschließlich der Enkel-Agent arbeitete, ergab 49.103 Token im Hauptagenten gegenüber 1.689.288
in `modelUsage` – die Differenz stammt nachweislich von der tieferen Ebene. Nebenbefund:
Subagenten-Transkripte werden nicht separat persistiert, ihre Prompts sind daher nicht
rekonstruierbar, ihre Tokens dagegen vollständig erfasst.

**Untersuchungsgegenstand im Arbeitsrepository gesichert.** Die Codebasis war nur als Gitlink
auf `79c1142` getrackt – ohne `.gitmodules` und ohne erreichbares Remote, nachdem das
GitHub-Remote zu Versuchsbeginn entkoppelt worden war. Ein Klon des Arbeitsrepositories hätte
ein leeres Verzeichnis erhalten; keiner der 3.287 Anforderungsbelege wäre überprüfbar gewesen.
Die Historie wurde aus dem Arbeitsbaum ausgelagert und der Dateiinhalt als reguläre Dateien
aufgenommen: 24.557 Dateien, rund 333 MB. Prompts, Protokolle, Ergebnisartefakte und der
analysierte Quellcode sind damit gemeinsam versioniert.

**Maschinelle Auswertung der Anforderungen** (Skill 3.9.0). Die Protokolle maßen bis dahin nur
den Aufwand, nicht den Ertrag. Ein Auswertungsskript parst die 3.287 Anforderungsblöcke und
erhebt Verteilung, Typen, Belegqualität, Status und – methodisch am wertvollsten – die
**Regelkonformität gegen die Vorgaben des Prompts selbst**. Erste Anwendung deckte sofort
Verstöße gegen die risikobasierte Priorisierung auf, die von Hand nicht auffindbar gewesen wären.

**Ordnerstruktur nach Bedingungen** (Skill 3.10.0, später 4.1.0). Modell, Agentenmodus und
Effort wurden von Namensbestandteilen zu Ordnerebenen; darüber kam die Ebene `<Versuchstag>`.
Die Zellenbelegung ist damit unmittelbar abzählbar – und die Struktur macht sichtbar, dass von
den möglichen Kombinationen nur fünf belegt sind.

**Ausrichtung auf Kapitel 4** (Skill 4.0.0). Prompt und Skill waren organisch gewachsen und
stellenweise nicht mehr deckungsgleich mit dem Versuchsdesign der Arbeit. Der Prompt enthielt
Aussagen zur Werkzeugkonfiguration, die ihn an ein bestimmtes Werkzeug banden; der Skill
verankerte weder den Evaluationsrahmen noch die geforderten Reproduzierbarkeitsangaben. Beides
wurde getrennt: Der Prompt trägt seither ausschließlich die Analyseanweisung, der Skill den
Prozess. Werkzeugkontext und Ausgabeverzeichnis werden zur Laufzeit angehängt.

Dabei fiel die Zuordnungsfrage an: Die Arbeit kannte nur V1 „Prompt-only, keine Agentendateien".
Werkzeugeigene Subagenten sind keine Agentendateien und wären nach Wortlaut in V1 erlaubt –
ihr Einsatz verändert die Ergebnisse aber erheblich. Entschieden wurde **V1 = `solo`,
V1b = `builtin`**; Kapitel 4 der Arbeit wurde um V1b und um einen Absatz zum vorgezogenen
Modellvergleich ergänzt.

**Prompt-Version 02** (Skill 4.2.0). Auf Basis der Auswertung entstand die erste echte
Iteration – ausführlich in Abschnitt 7.

### Phase 6 – Prompt-Version 02, zehn Läufe und ein geänderter Untersuchungsgegenstand (26.08., ab 08:43)

Prompt-Version 02 wurde erstmals gemessen: ein serieller Lauf, danach zwei Parallelblöcke zu vier
und fünf Läufen. Zwischen den Blöcken änderte sich der Untersuchungsgegenstand, weshalb die zehn
Läufe auf **Iteration 2** (fünf Läufe, ohne DB-Schema) und **Iteration 3** (fünf Läufe, mit
verfügbarem DB-Schema) aufgeteilt sind. Alle zehn liefen unter `claude-sonnet-5` / `solo` / `high`.

**Die Menge wird gebunden, die Struktur nicht.** Iteration 2 ergab 123 bis 185 Anforderungen
(Faktor 1,50) gegenüber 42 bis 82 unter Prompt-Version 01 (Faktor 2,0). Das Modulinventar aus
Schritt 0 bindet die Anzahl also messbar. Die **Ebenenverteilung** streut dagegen über beide
Iterationen extrem – von 92,7 % auf Stakeholder- bis 89,4 % auf Softwareebene:

| Lauf | It. | Anf. | StRS/SyRS/SwRS | Primärbeleg | Tracelinks | Risiko offen | Tokens |
|---|---:|---:|---|---:|---:|---:|---:|
| d6f9 *(seriell)* | 2 | 170 | 20/120/30 | 85,3 % | 100 % | 1 von 51 | 35,7 Mio. |
| 3983 | 2 | 185 | 37/28/120 | 34,6 % | 100 % | **18 von 49** | 17,3 Mio. |
| 4840 | 2 | 123 | **114/2/7** | 56,1 % | **56,9 %** | 1 von 17 | **53,4 Mio.** |
| f631 | 2 | 156 | 40/56/60 | **98,1 %** | 91,7 % | **0** | 18,2 Mio. |
| c69e | 2 | 160 | 21/15/124 | 73,8 % | 100 % | 2 von 42 | 13,0 Mio. |
| 0848 | 3 | 211 | 134/39/38 | 43,6 % | **49,8 %** | 7 von 46 | **11,4 Mio.** |
| 1b24 | 3 | 215 | 34/101/80 | 42,8 % | 100 % | 8 von 48 | 49,7 Mio. |
| 2316 | 3 | 175 | 20/36/119 | 78,3 % | 100 % | **0** | 48,3 Mio. |
| 3ef5 | 3 | **237** | 25/28/184 | 38,8 % | 100 % | 9 von 51 | **68,9 Mio.** |
| b652 | 3 | 151 | 7/9/135 | **96,0 %** | 100 % | **0** | 42,9 Mio. |

Der Prompt verlangt in Schritt 0b je Modul mindestens eine Anforderung, sagt aber nicht, **auf
welcher Ebene**. Genau diese Lücke erzeugt die verbliebene Streuung. Auch der Inventarbegriff ist
je Lauf ein anderer: 120 fachliche Module, 133 nach fachlich und technisch getrennt, oder eine
Gliederung nach Verzeichnisstruktur des WPF-Clients. Für Prompt-Version 03 ist das der konkreteste
Ansatzpunkt.

**Befund 6.1 bestätigt sich – in verschärfter Form.** Über alle zehn Läufe korrelieren
Anforderungszahl und Primärbelegquote **negativ** (Pearson −0,63, Spearman −0,70). Die Läufe mit
der besten Belegqualität liefern die wenigsten Anforderungen (`f631` 98,1 % bei 156, `b652` 96,0 %
bei 151), die mengenstärksten die schlechteste (`3ef5` 38,8 % bei 237, `3983` 34,6 % bei 185).
Die Anforderungszahl ist damit nicht nur kein Qualitätsmaß – als Maß genommen zeigt sie **ins
Gegenteil**.

**Der Untersuchungsgegenstand änderte sich mitten im Betrieb (10:28:08).** `SSMS_DB_SCHEMA.sql`
kam in das Arbeitsverzeichnis: 3.266.626 B, 76.793 Zeilen, 1.558 Tabellen, 182 Views, 63
Prozeduren, 30 Funktionen, 134 Fremdschlüssel. Der Prompt fordert Datenbankschemata in Schritt 2
ausdrücklich als Quelle; Läufe mit und ohne die Datei sind nicht poolbar. Die Vorher/Nachher-
Prüfung erfasste die Änderung selbsttätig – `_meta/before.txt` der neuen Läufe ist 46 B statt 2 B.
Der Snapshot wurde als eigener Commit `f349d189` festgeschrieben.

**Verfügbarkeit ist nicht Nutzung.** Von den fünf Läufen der Iteration 3 haben nur **drei** das
Schema geöffnet (`0848`, `1b24`, `2316`); `3ef5` und `b652` haben es in der Verzeichnisauflistung
gesehen und ignoriert. Ob das Schema genutzt wird, ist damit eine **abhängige** Variable und wird
seither je Lauf erhoben – über Werkzeugaufrufe, deren *Eingabe* den Dateinamen nennt, nicht über
Texttreffer im Transkript.

Ein Verbrauchseffekt ist **nicht belegt**: `0848` nutzte das Schema und war mit 11,4 Mio. Tokens
der sparsamste Lauf beider Iterationen, `2316` nutzte es ebenfalls und verbrauchte 48,3 Mio.
`3ef5` nutzte es nicht und war mit 68,9 Mio. der teuerste. Der Median der Anforderungszahl steigt
von 160 (Iteration 2) auf 211 (Iteration 3), aber die Spannen überlappen deutlich (123–185 gegen
151–237), und innerhalb der Iteration 3 trennt die Nutzung die Läufe nicht. Bei n = 5 je Gruppe
ist das ein Hinweis, keine Wirkung.

**Ein Lauf lag auf der Grenze und wurde am Transkript entschieden.** `094249_v4.2.1-4840` startete
um 09:43 ohne die Datei und lief noch, als sie erschien. Sein Transkript enthält **null Treffer**
für `SSMS_DB_SCHEMA`, `CentronVOED2` und `.sql` – er gehört zweifelsfrei zu Iteration 2. Dabei
fiel eine Grenze der Read-only-Verifikation auf: Sein `before.txt` und sein `after.txt` sind beide
leer, aber aus verschiedenen Gründen (vorher existierte die Datei nicht, nachher war sie
committet). Zwei gleiche Messwerte bei ungleichen Zuständen – für künftige Läufe wäre der
Snapshot zusätzlich über einen Inhaltshash zu führen.

**Drei Defekte am Messinstrument aufgedeckt und behoben.** Keiner ließ einen Lauf fehlschlagen,
alle drei hätten Protokollangaben verfälscht:

- *Root-Prüfung ohne Pfadfilter* (Skill 4.2.1). Seit die Codebasis als Dateien im Arbeitsrepo
  liegt statt als Gitlink, lieferte `git -C <root> status --porcelain` den Status des gesamten
  Arbeitsrepos – rund 55 KB, praktisch nur Versuchsdateien.
- *Ebenenbestimmung nach Dateiname* (Skill 4.3.0). Das Auswertungsskript leitete die Ebene einer
  Anforderung aus der Datei ab, in der ihr Block stand. `c69e` legte 12 StRS- und 5 SyRS-Blöcke in
  `SwRS.md` ab; die Verteilungstabelle meldete 9/10/141 statt der tatsächlichen 21/15/124. Der
  Agent hatte korrekt gezählt, das Skript widersprach ihm zu Unrecht. Alle 24 Läufe der
  Iteration 1 wurden gegengeprüft: keine Fremdablage, ihre Protokolle bleiben gültig.
- *Schema-Nutzung über Texttreffer*. Die erste Fassung der Erhebung zählte Vorkommen im
  Transkript und stufte `b652` als Nutzer ein – der Treffer stammte aus der Verzeichnisauflistung.
  Gezählt werden seither nur Werkzeugaufrufe mit dem Dateinamen in der **Eingabe**.

Die Fremdablage aus dem zweiten Punkt ist kein Skriptartefakt, sondern ein Befund zur
**Set-Qualität**: Die Dreiteilung StRS / SyRS / SwRS ist dann nicht mehr an der Dateistruktur
ablesbar.

**Die Denylist erzeugt systematisch Streudateien.** Drei der zehn Läufe (`f631`, `b652`, `3ef5`)
ließen Arbeitsdateien im Ergebnisordner zurück – bis zu sechs bei `3ef5`. In allen Fällen hatte
der Agent versucht, sie aufzuräumen (`rm`, `Remove-Item`), und wurde von der Denylist gestoppt;
die Löschversuche machen den Großteil aller Permission-Denials dieser Läufe aus. Die Dateien
bleiben bewusst liegen: Nachträgliches Löschen würde die Artefaktlage verändern. Der Befund
gehört zur Werkzeugkonfiguration, nicht zum Modell – die Denylist sperrt Löschbefehle pauschal,
auch im Laufverzeichnis, für das der Agent Schreibrecht hat.

**Zwei Umbenennungen** (Skill 4.4.0). Die Ordnerebene `<Versuchstag>` heißt jetzt `<Iteration>`:
Der alte Name band sie an das Kalenderdatum, obwohl sie die Vergleichbarkeit abbildet – Iteration 2
und Iteration 3 entstanden am selben Tag. Weil „Iteration" mit der Fassung der Prompt-Datei
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.

### Phase 8 – Rastererweiterung, Kontingentgrenzen und der Wechsel auf serielle Läufe (26.–27.08.)

Iteration 3 belegte zu Beginn dieser Phase erst **4 von 12 Zellen** des aufgespannten Rasters aus
drei Modellen, zwei Agentenmodi und zwei Effort-Stufen. Ziel war, je einen Lauf für die fehlenden
Kombinationen zu erheben.

**Der erste Anlauf scheiterte vollständig – an der Parallelität.** Vier gleichzeitig gestartete
Läufe (19:59) liefen sämtlich in HTTP 429, „You've hit your session limit". Zusammen hatten sie
bis dahin **297,4 Mio. Tokens** verbraucht, davon allein 204,4 Mio. in `opus-5/builtin/high`. Drei
der vier hatten Teilergebnisse erzeugt, bevor das Kontingent riss – zwischen einer und drei von
sieben Dateien; sie sind als Fehlmessungen mit Teilbestand protokolliert und gehen in keinen
Vergleich ein.

Daraus folgte die Umstellung auf **strikt serielle Läufe**. Sie hat einen messtechnischen
Nebeneffekt, der über die Kontingentfrage hinausreicht: Seit dem seriellen Lauf `d6f9` waren
sämtliche Wanduhrzeiten entweder durch Parallelbetrieb oder durch Kontingent-Wartezeiten
verzerrt. Serielle Läufe machen die Laufzeit wieder zu einer verwertbaren Messgröße.

**Zwei neue Zellen sind seriell entstanden und gültig:**

| Zelle | Anf. | StRS/SyRS/SwRS | Primärbeleg | Belege/Anf. | Tokens | Wanduhr |
|---|---:|---|---:|---:|---:|---:|
| `opus-5/solo/high` | 363 | 62/132/169 | **99,7 %** | **2,0** | 38,1 Mio. | 26 min |
| `fable-5/solo/high` | 241 | 33/50/158 | 98,3 % | 1,0 | 30,6 Mio. | 7:03 h\* |

\*Kontingent-Wartezeit, siehe unten.

**Befund: Die Belegdichte folgt dem Modell, nicht dem Effort.** In Phase 7 war die verdoppelte
Belegdichte – Median 2,0 statt 1,0 – dem `max`-Effort zugeschrieben worden, weil alle 44
vorherigen `high`-Läufe bei Median 1,0 lagen. `opus-5/solo/high` erreicht Median **2,0 auf
`high`**. Die 44 Läufe mit Median 1,0 liefen sämtlich auf Sonnet, die `max`-Läufe auf Opus – die
beiden Variablen waren konfundiert. Nach jetzigem Stand:

| Modell | `high` | `max` |
|---|---:|---:|
| Sonnet | 1,0 | – |
| Fable | 1,0 | – |
| Opus | **2,0** | **2,0–3,0** |

Der Effort bleibt für den **Verbrauch** wirksam (38,1 Mio. auf `high` gegenüber 67,5–116,2 Mio.
auf `max`), für die Belegdichte ist das Modell die stärkere Größe.

**Befund: Die Fable-Modellverletzung ist reproduziert – und abgegrenzt.** Der Lauf
`fable-5/builtin/high` wies erneut `claude-opus-5[1m]` in `modelUsage` aus, wie schon in
Iteration 1 unter anderer Prompt-Version und anderem Snapshot. Der Lauf `fable-5/solo/high`
dagegen ist sauber: ausschließlich `claude-fable-5` plus Haiku. Damit steht fest: **Nicht Fable
ist die Ursache, sondern Fable in Kombination mit Delegation.** Sonnet und Opus werden an die
Subagenten durchgereicht, Fable nicht; die CLI fällt dann auf die Sitzungsvorgabe
`model: opus[1m]` aus `~/.claude/settings.json` zurück.

**`opus-5/builtin/high` ist zum dritten Mal gescheitert.** Über drei Anläufe zusammen
**790,7 Mio. Tokens ohne ein einziges verwertbares Artefakt**:

| Lauf | Abbruch | Subagenten | Tokens |
|---|---|---:|---:|
| `116d` | 600-s-Zeitlimit für Hintergrund-Subagenten | 20 (10 verschachtelt) | 193,4 |
| `9d9e` | Kontingent (429) | 34 (24 verschachtelt) | 392,9 |
| `45dd` | Kontingent (429) | 24 | 204,4 |

Jedes Mal dasselbe Muster: Opus zerlegt die Aufgabe in 20 bis 34 Subagenten, beendet seinen
eigenen Turn nach einem einzigen Turn und überlässt die Arbeit den Hintergrundagenten. Die
Korrektur des Zeitlimits (`CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`) beseitigte die erste Ursache;
die Delegationsbreite riss dann das Kontingent. **Die Zelle ist mit dieser Prompt-Version und
diesem Modell nicht messbar** – drei reproduzierbare Ausfälle sind als Grenzbefund über die
Delegation aussagekräftiger als ein vierter Versuch.

**Ein dritter Verzerrungsmechanismus der Zeitmessung.** `fable-5/solo/high` brauchte 7:03:44
Wanduhrzeit, ohne parallel zu laufen. Die Abstände zwischen den Werkzeugaufrufen zeigen den
Grund: Lücken von 4:00 h und zweimal rund 2 h. Bei erschöpftem Kontingent **bricht die CLI nicht
ab, sondern wartet auf das nächste Reset-Fenster** und arbeitet dann weiter. `duration_ms` bildet
diese Wartezeit mit ab. Neben Parallelbetrieb und Abbruch ist das die dritte Ursache unbrauchbarer
Zeitangaben – und die einzige, die von außen wie ein hängender Prozess aussieht. Tokenverbrauch,
Anforderungszahl und Belegkennzahlen sind davon nicht betroffen.

**Verbrauchsbilanz der Reihe.** Über beide Tage: 42 abgeschlossene Läufe, **2.294,7 Mio. Tokens**,
davon am 26.08. allein 1.703,6 Mio. mit fünf Fehlmessungen. Rund 880 Mio. Tokens – gut ein Drittel
des Gesamtverbrauchs – entfielen auf Läufe ohne verwertbares Ergebnis.

**Codex-Lauf verworfen.** Der Lauf `Iteration 5/gpt-5.6-sol/solo/high/…-54dd` stand seit
13,5 Stunden ohne Fortschritt und ohne `RawResult.json`; die Arbeitskopie lag zudem mit 352 MB im
Laufverzeichnis statt im System-Temp-Verzeichnis, wie Skill 6.0.0 es vorsieht. Prozesse beendet,
Lauf gelöscht. Der Neustart steht aus: Die Codex-CLI ist inzwischen auf **0.150.0-alpha.8**, der
Referenzstand des Adapters ist **0.149.0-alpha.4.3**. Der Skill verlangt bei geändertem
JSONL-Schema einen Smoke-Test des Normalisierers **vor** dem Messlauf – sonst endet ein
mehrstündiger Lauf mit nicht parsbaren Rohdaten.

**Serielle Kette gestartet (27.08., 08:12).** Sechs offene Zellen, günstigste zuerst, damit bei
einem Kontingentabbruch möglichst viele belegt sind: `fable/solo/max`, `sonnet/solo/max`,
`fable/builtin/high`, `sonnet/builtin/max`, `fable/builtin/max`, `opus/builtin/max`. Die Kette
wartet bei einem 429 einmal 70 Minuten und wiederholt dieselbe Zelle; beim zweiten 429 bricht sie
ab. Ein leeres Ergebnisverzeichnis trotz Erfolgsmeldung wird als Fehlmessung protokolliert, ohne
die Kette zu stoppen.

---

## 3. Entwicklung des Prompts

Der Prompt blieb inhaltlich über alle 24 Läufe **unverändert** – der SHA-256
`1B0DB06B…3C02FF` ist in jedem Protokoll dokumentiert. Alle 24 Läufe sind damit
Wiederholungsmessungen desselben Prompts, keine Prompt-Versionen im Sinne von Kapitel 4.

Erst nach Abschluss der Läufe wurde er überarbeitet (2026-08-26). Diese Überarbeitung war
zunächst rein formal – sie machte den Prompt werkzeugneutral, ohne die Analyseanweisung zu
ändern. Die inhaltliche Überarbeitung folgte als **Prompt-Version 02** und ist in Abschnitt 7
dokumentiert.

| Änderung | Grund |
|---|---|
| Metadaten `Werkzeugkonfiguration` und `Modell` entfernt | Beschreiben den Lauf, nicht die Analyse; gehören ins Messprotokoll |
| Satz „Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung" entfernt | Bindet den Prompt an eine Werkzeugkonfiguration; wird zur Laufzeit als Werkzeugkontext beigestellt |
| Feld `Übernahmewürdigkeit` ergänzt (`übernehmen`/`Workaround`/`Sonderfall`/`veraltet`) | Der Evaluationsrahmen (Kap. 4.3) bewertet diese Dimension; bislang steckte sie halb im Feld `Status` und war nicht auswertbar |
| Pflichteigenschaft `Redundanzfreiheit` ergänzt | Ergänzt das vorhandene Feld `Konsolidierung` um die ausdrückliche Abgrenzungsprüfung |
| Konsistenzcheck erweitert | Prüft nun auch fehlende Übernahmewürdigkeit und nicht markierte Doubletten |

**Damit ist der Prompt werkzeug- und modellneutral** und von jedem LLM verwendbar – eine
Voraussetzung für den in Kapitel 4 geplanten LLM-Querschnitt.

---

## 4. Entwicklung des Versuchsaufbaus (Skill)

19 Versionen in zwei Tagen. Jede geht auf eine konkrete Beobachtung zurück:

| Version | Änderung | Auslöser |
|---|---|---|
| 1.0.0 | Ausgangsfassung | – |
| 2.0.0 | Shell-Zugriff + Denylist; Isolation über eingefrorenen Snapshot | 36 Denials in Lauf 1; `--safe-mode` allein unzureichend |
| 2.0.1 | `before.txt` leerwertsicher schreiben | Bei sauberem Root schrieb PowerShell die Datei nicht und ließ alten Inhalt stehen – der Vergleich meldete eine Abweichung, die es nicht gab |
| 2.1.0 | Modell wird vor jedem Lauf erfragt | Das Modell wurde bis dahin ad hoc gewählt |
| 2.1.1 | Warnung zur Snapshot-Prüfung | Ein verkürzter Regex sprach auf echte Produktdateien an (`ClaudeCodeChatModelClient.cs`) |
| 3.0.0 | Agentenmodus als Pflichtparameter (`solo`/`builtin`/`custom`) | Subagenten-Einsatz schwankte zwischen 0 und 14 und war die dominierende Störgröße |
| 3.1.0 | Parallelfähigkeit; Steuerdateien nach `_meta` im Laufverzeichnis | Geteilte Scratchpad-Dateien hätten sich zwischen parallelen Läufen überschrieben |
| 3.2.0 | Modell und Version im Verzeichnisnamen; `Workflow` mitgesperrt | Im Verifikationstest wich der Agent auf `Workflow` aus |
| 3.3.0 | Subagenten-Prompts werden protokolliert | Die selbstgewählte Zerlegung war nur als Zahl sichtbar, nicht inhaltlich |
| 3.4.0 | Effort als dritter Pflichtparameter | Der Denkaufwand wurde nur aus der Sitzung geerbt und nirgends dokumentiert |
| 3.5.0 | Berichtete Aufwandsgröße ist der Tokenverbrauch statt USD | USD-Beträge hängen an Preisliste und Modellwahl und veralten |
| 3.6.0 | Verschachtelte Subagenten verifiziert und dokumentiert | Unbelegt, ob tiefere Ebenen in die Tokensumme einfließen – Kontrolltest belegte es |
| 3.7.0 | Effort im Verzeichnisnamen | Erster `max`-Block; gleichnamige Verzeichnisse hätten verschiedene Bedingungen bezeichnet |
| 3.8.0 | Pflichtprüfung der tatsächlich eingesetzten Modelle | Fable-Lauf: 91 % des Verbrauchs auf einem nicht angeforderten Modell |
| 3.9.0 | Pflichtabschnitt „Gefundene Anforderungen" | Protokolle maßen nur Aufwand, nicht Ertrag |
| 3.10.0 | Bedingungen als Ordnerstruktur statt im Dateinamen | Der Name wuchs mit jeder Variable und war kaum noch lesbar |
| 4.0.0 | Zweiteilung Prozess/Werkzeugadapter; V1 = `solo`, V1b = `builtin`; Evaluationsrahmen verankert | Ausrichtung auf Kapitel 4 der Arbeit |
| 4.1.0 | Ebene `<Versuchstag>` über den Bedingungen | Der Aufbau durchlief an Tag 1 siebzehn Versionen; die Tagesebene hält Blöcke auseinander, die unter unterschiedlichem Stand entstanden |
| 4.2.0 | Auswahlregel bei mehreren Prompt-Versionen; Protokollfeld „Prompt-Version" | Mit `02_Prompt.md` liegt erstmals mehr als eine Fassung vor; ohne Regel ließe sich der SHA-256 im Protokoll keiner Datei mehr zuordnen |

**Beobachtung für die Diskussion:** Von den achtzehn Änderungen gehen zehn auf Messfehler oder
Fehlannahmen zurück, die erst im Betrieb sichtbar wurden – nicht auf Planungslücken im
klassischen Sinn. Betroffen waren durchweg Annahmen, die plausibel schienen und sich als falsch
erwiesen: dass `--safe-mode` genügt, dass `--model` die Subagenten steuert, dass `duration_ms`
die Laufzeit misst, dass gesperrte Werkzeuge Denials erzeugen, dass `git status` alle
Schreibvorgänge erfasst. Ein Versuchsaufbau für agentische LLM-Werkzeuge lässt sich offenbar
nicht vollständig vorab spezifizieren; er entsteht in der Auseinandersetzung mit dem Werkzeug.

---

## 5. Durchgeführte Läufe

**Iteration 1:** 24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl
(Nr. 2, API-Transportfehler).

**Iteration 6 (TensorX-Gateway, Skill v8.0.0):** 1 Lauf, 2,17 Mio. Tokens, 90 erzeugte Anforderungen.
Erster Lauf mit GLM 5.2 über den Python-API-Adapter. Details siehe unten.

| # | Zeit | Modell | Modus | Effort | Subagenten | Denials | Turns | Tokens | Anforderungen |
|---:|---|---|---|---|---:|---:|---:|---:|---:|
| 1 | 12:29 | sonnet-5 | builtin | high | 8 | **36** | 43 | 13.052.010 | 96 |
| 2 | 13:49 | sonnet-5 | builtin | high | 6 | 0 | 8 | 16.655.125 | 89 *(Abbruch)* |
| 3 | 14:29 | sonnet-5 | builtin | high | 7 | 0 | 69 | 11.516.200 | 106 |
| 4 | 15:05 | sonnet-5 | builtin | high | 0 | 0 | 147 | 27.562.244 | 55 |
| 5 | 15:35 | sonnet-5 | builtin | high | 14 | 1 | 31 | 52.713.542 | 325 |
| 6 | 16:35 | sonnet-5 | builtin | high | 7 | 0 | 29 | 32.568.122 | 189 |
| 7 | 17:31 | sonnet-5 | solo | high | 0 | 0 | 68 | 4.357.855 | 42 |
| 8 | 17:31 | sonnet-5 | solo | high | 0 | 0 | 107 | 12.598.503 | 82 |
| 9 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 72 | 5.659.692 | 60 |
| 10 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 77 | 4.591.733 | 73 |
| 11 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 67 | 5.050.595 | 67 |
| 12 | 18:29 | sonnet-5 | builtin | high | 19 *(9 versch.)* | 2 | 94 | 55.167.397 | 246 |
| 13 | 18:29 | sonnet-5 | builtin | high | 8 | 1 | 84 | 42.204.257 | 238 |
| 14 | 18:29 | sonnet-5 | builtin | high | 20 *(6)* | 0 | 23 | 40.787.325 | 113 |
| 15 | 18:29 | sonnet-5 | builtin | high | 21 *(3)* | 0 | 15 | 44.713.674 | 145 |
| 16 | 18:29 | sonnet-5 | builtin | high | 18 *(6)* | 0 | 33 | 65.101.243 | 239 |
| 17 | 19:59 | opus-5 | solo | high | 0 | 0 | 116 | 13.560.381 | 71 |
| 18 | 19:59 | opus-5 | solo | high | 0 | 1 | 195 | 22.759.401 | 119 |
| 19 | 19:59 | opus-5 | solo | high | 0 | 1 | 177 | 24.860.083 | 114 |
| 20 | 20:00 | opus-5 | solo | high | 0 | 0 | 145 | 24.280.282 | 182 |
| 21 | 20:00 | opus-5 | solo | high | 0 | 0 | 131 | 19.751.531 | 109 |
| 22 | 21:09 | fable-5 | solo | **max** | 0 | 1 | 152 | 24.225.555 | 207 |
| 23 | 21:09 | fable-5 | solo | **max** | 0 | 0 | 162 | 31.073.793 | 148 |
| 24 | 22:07 | fable-5 | builtin | high | 13 | 0 | 28 | **150.340.866** | 172 |

### Iteration 6 – Erster Lauf mit TensorX-Gateway (28.08.2026)

| # | Zeit | Modell | Modus | Effort | Subagenten | Denials | Turns | Tokens | Anforderungen |
|---:|---|---|---|---|---:|---:|---:|---:|---:|
| 25 | 07:41 | **glm-5.2** | solo | high | 0 | n. erfasst | 33 | 2.171.551 | 90 |
| 26 | 07:54 | **kimi-k3** | builtin | high | 8 (3 OK, 5 fail) | n. erfasst | 28 | 5.704.697 | 81 |
| 27 | 09:28 | **glm-5.2** | builtin | high | 10 (10 OK) | n. erfasst | 8 | 1.126.614 | **0 (Fehlmessung)** |
| 28 | 09:28 | **kimi-k3** | solo | high | 0 | n. erfasst | 50 | 3.442.979 | 79 |

Läufe 27 und 28 liefen **parallel** (gleiche Startzeit 09:28 CEST). Wanduhrzeiten sind
daher verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch und
Anforderungsanzahl bleiben unverzerrt.

**Lauf 27 (GLM builtin) ist eine Fehlmessung**: `is_error: false`, `subtype: success`,
aber **0 Ergebnisdateien** bei 1,13 Mio. Tokens und 10 erfolgreichen Subagenten. Der Agent
startete 10 Subagenten (alle completed, 0 failed — der Unicode-Bugfix aus Lauf 26 wirkte),
schrieb aber selbst keine Ergebnisdateien. Der Abschlusstext lautete: „Ich habe nun eine
umfassende Übersicht… Ich starte parallele Suchen." — der Agent beschrieb, was er tun würde,
anstatt es zu tun. Nur 8 Turns bei max_turns=100.

**Lauf 28 (Kimi solo)** erreichte 50 Turns (max_turns-Limit) und erzeugte 79 Anforderungen
mit 100 % Primärbeleg-Quote. Die Tool-Nutzung ist ausgewogener als bei GLM-solo
(23× list_directory, 21× execute_command, 18× search_files, 9× read_file, 13× write_file).
0 Hypothesen bei 79 Anforderungen — auffällig, da der Prompt bei Codebasen dieser Größe
mindestens eine erwartet.

Erster Lauf über den **TensorX-API-Gateway** mit dem **Python-API-Adapter** (`glm-kimi-adapter.py`).
Skill-Version **v8.0.0** (MAJOR: neuer Adapter = neue Versuchsbedingung). Keine CLI-Abhängigkeit,
nur Python + `requests`. API-Key automatisch aus der Cline `providers.json` gelesen.

Lauf 26 ist der erste Lauf im Modus **`builtin` (V1b)** mit dem Python-API-Adapter. Der Adapter
implementiert Subagenten über ein `spawn_subagent`-Tool: Der Hauptagent delegiert Teilaufgaben an
Subagenten mit eigenem Kontext und Read-Only-Tools. 5 von 8 Subagenten schlugen fehl
(UnicodeDecodeError: cp1252 vs UTF-8 bei Shell-Kommandoausgabe); Bug nachträglich behoben.

**Besonderheiten gegenüber Claude-Code-Läufen:**
- Reasoning-Tokens erfasst – Claude Code liefert nur `thinking_tokens`, TensorX zusätzlich `reasoning_tokens`
- Cache-Read-Anteil 89–92 % – deutlich höher als bei Claude Code
- Tool-Nutzungsschwerpunkt: `list_directory`-dominiert (GLM solo: 88×, Kimi builtin: ähnlich)
- Keine Permission-Denials als zählbare Messgröße (hartes Blockieren statt Denial)
- GLM solo: 5:39 min, Kimi builtin: 57:33 min – Subagenten-Delegation verachtfacht die Dauer
- Tokenverbrauch builtin (5,7 Mio.) 2,6× höher als solo (2,17 Mio.) – gleicher Effekt wie bei Claude Code

Die Läufe 7–8, 9–11, 12–16, 17–21 und 22–23 liefen jeweils parallel. Wanduhrzeiten dieser Läufe
sind dadurch verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch,
Anforderungsanzahl und Denials bleiben unverzerrt.

### Iteration 7 – Prompt-Version 03 und V2-Agenten-Adapter (28.08.2026)

**Prompt-Änderungen (02 → 03):** Nur zwei Änderungen, beide aus Iteration-6-Befunden abgeleitet:
1. Ergebnisstruktur: nur die 7 vorgegebenen Dateien, keine Ergänzungsdateien (Kimi-solo hatte `SwRS-Ergaenzungen.md` erstellt → 18 Anforderungen vom Skript nicht erfasst)
2. Modulabdeckung härter: >10 % `nicht analysiert` = Hinweis auf unvollständige Erkundung (GLM-solo hatte 27,5 % nicht analysiert)

**Adapter-Änderung:** `--mode custom` mit `--agents <datei>` implementiert (V2-Vorbereitung). Noch nicht in Läufen verwendet.

**Vorbereitungs-Bug:** Der Werkzeugkontext-Block enthielt `\`$lauf\Ergebnisse\` — der Backtick verhinderte die PowerShell-Variablenexpansion, sodass das Modell Dateien nach `$lauf\Ergebnisse\` statt ins echte Ergebnisverzeichnis schrieb. Betrifft alle 4 Läufe.

| # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
|---:|---|---|---|---|---:|---:|---:|---:|---|
| 29 | 11:17 | **glm-5.2** | solo | high | 0 | 32 | 1.849.737 | 0 *(Bug)* | ⚠️ Dateien in `$lauf\Ergebnisse\` |
| 30 | 11:24 | **glm-5.2** | builtin | high | 6 (4 OK, 2 fail) | 8 | 1.096.464 | 0 | ⚠️ **Fehlmessung** |
| 31 | 11:17 | **kimi-k3** | solo | high | 0 | 23 | 628.222 | 0 | ⚠️ **Fehlmessung** (0 write_file) |
| 32 | 11:24 | **kimi-k3** | builtin | high | 3+ | läuft | läuft | läuft | ⏳ läuft noch |

Alle 4 Läufe liefen **parallel** (gleiche Startzeit 11:17 bzw. 11:24 CEST).

**Lauf 29 (GLM solo):** 5 Ergebnisdateien geschrieben, aber wegen des `$lauf`-Bugs im verschachtelten Verzeichnis `$lauf\Ergebnisse\` abgelegt. Rettungsversuch aufgrund des Sonderzeichens `$` im Verzeichnisnamen fehlgeschlagen. 0 Anforderungen auswertbar.

**Lauf 30 (GLM builtin):** Wiederholung der Fehlmessung aus Iteration 6 (Lauf 27). Gleiches Muster: 6 Subagenten gestartet (4 OK, 2 fail), aber 0 Ergebnisdateien. 8 Turns bei max_turns=200. GLM 5.2 im builtin-Modus erzeugt konsistent keine Ergebnisdateien — systematisches Problem.

**Lauf 31 (Kimi solo):** 23 Turns, 628k Tokens, aber 0 `write_file`-Aufrufe. Der Agent erkundete die Codebasis (34× list_directory, 11× read_file, 9× execute_command, 9× search_files), schrieb aber nie eine Ergebnisdatei. Fehlmessung. Auffällig: Tokenverbrauch (628k) deutlich niedriger als Iteration-6-Kimi-solo (3,44 Mio.) — möglicherweise abgebrochen oder vorzeitig beendet.

**Lauf 32 (Kimi builtin):** Wurde nach über 5 Stunden Laufzeit manuell abgebrochen — der Hauptagent startete 11 Subagenten ohne jemals Ergebnisdateien zu schreiben. Dasselbe Muster wie GLM-builtin in Iteration 6 und 7: endlose Subagent-Delegation ohne Übergang zur Schreibphase.

**Vorläufige Erkenntnis aus Iteration 7:** Drei von vier Läufen sind Fehlmessungen. Der `$lauf`-Bug muss vor der nächsten Iteration behoben werden. GLM 5.2 im builtin-Modus ist ein systematisches Problem (3 Fehlmessungen in Folge). Kimi solo hatte in Iteration 6 noch funktioniert (79 Anforderungen) — die Fehlmessung in Iteration 7 könnte ein Parallelbetriebs-Effekt sein (4 Läufe gleichzeitig überlasten das API-Kontingent).


---

### Iteration 8 – Prompt-Version 03, Adapter-Verbesserungen, sequenzielle Läufe (28.08.2026)

**Adapter-Verbesserungen (v1.1.0 → v1.2.0):** Drei Maßnahmen gegen die Fehlmessungen aus Iteration 6+7:
1. **Subagent-Limit (10):** Nach 10 Subagenten wird `spawn_subagent` verweigert mit der Aufforderung, Ergebnisdateien zu schreiben.
2. **Schreib-Erinnerung:** Wenn nach ⅓ der Turns kein `write_file` aufgerufen wurde, wird eine System-Nachricht injiziert.
3. **`$lauf`-Bug behoben:** PowerShell-Variablenexpansion im Werkzeugkontext-Block korrigiert.

Läufe liefen **sukzessive** (nicht parallel), um API-Kontingent-Probleme zu vermeiden.

| # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
|---:|---|---|---|---|---:|---:|---:|---:|---|
| 33 | 12:59 | **glm-5.2** | solo | high | 0 | 34 | 1.862.184 | 70 | ✅ erfolgreich |
| 34 | 13:10 | **glm-5.2** | builtin | high | 9 (9 OK) | 28 | 7.140.040 | 132 | ✅ **erfolgreich — Durchbruch** |
| 35 | 13:35 | **kimi-k3** | solo | high | 0 | 44 | 3.208.550 | 0 | ⚠️ nur 1 Datei |
| 36 | 14:20 | **kimi-k3** | builtin | high | 6 | — | — | 0 | ❌ **abgebrochen** (Stromausfall) |

**Lauf 33 (GLM solo):** 70 Anforderungen, 7 Ergebnisdateien. Tool-Schwerpunkt weiterhin `list_directory` (107× vs. 11× `read_file`).

**Lauf 34 (GLM builtin) — DER DURCHBRUCH:** Nach 3 Fehlmessungen in Folge (Iteration 6+7) hat GLM 5.2 im builtin-Modus endlich Ergebnisdateien geschrieben. **132 Anforderungen** (vs. 70 bei solo — fast doppelt so viele durch Subagent-Delegation). 9 Subagenten (Limit 10, nicht voll ausgeschöpft), alle completed, 0 failed. 8 `write_file`-Aufrufe — das Subagent-Limit und die Schreib-Erinnerung haben funktioniert. 7,14 Mio Tokens (3,8× solo).

---

### Nachanalyse der Kimi-K3-Läufe und Adapterkorrektur 9.0.0 (29.08.2026)

Die zunächst notierte Erklärung, Kimi K3 beende seine Arbeit nach einer Beschreibung mit
`finish_reason: stop`, wird durch die Rohdaten widerlegt. In allen fünf `solo`-Läufen mit
Prompt-Version 03 war die letzte erfolgreiche Antwort ein Tool-Aufruf
(`finish_reason: tool_calls`). Der jeweils folgende HTTP-Aufruf an TensorX lieferte 1.800
Sekunden lang keine Antwort und endete mit `Read timed out (read timeout=1800)`.

| Lauf | Iteration | Turns | Tokens | Dateien | Tatsächliches Ende |
|---:|---:|---:|---:|---:|---|
| 31 | 7 | 23 | 628.222 | 0 | API-Read-Timeout in Turn 23 |
| 35 | 8 | 44 | 3.208.550 | 1 | API-Read-Timeout in Turn 44 |
| 37 | 8 | 27 | 1.473.405 | 1 | API-Read-Timeout in Turn 27 |
| 39 | 8 | 25 | 695.248 | 7, davon 6 nur Skelette | API-Read-Timeout in Turn 25 |
| 40 | 8 | 30 | 2.094.726 | 0 | API-Read-Timeout in Turn 30 |

Der Timeout war im Adapter trotz der CLI-Beschreibung `--timeout 0` fest auf 1.800 Sekunden
gesetzt. Zusätzlich lautete die Fehlerbedingung
`len(errors) > 0 and not final_content`: Sobald irgendeine frühere Modellantwort Freitext
enthielt, wurden der Timeout, `subtype` und der Prozess-Exitcode als Erfolg ausgewiesen. Der
Fehler stand nur im Feld `errors` der `RawResult.json`, nicht in `Stderr.log`. Dadurch konnte die
vorgeschriebene Stderr-Prüfung ihn nicht erkennen.

Die Kausalität ist daher zweistufig: Der unmittelbare Stillstand liegt auf dem nicht
gestreamten Kimi-/TensorX-API-Aufruf; dass daraus eine stille oder falsch als erfolgreich
markierte Fehlmessung wurde, liegt am Adapter. Ein grundsätzlich ungeeignetes Modell ist nicht
belegt: Kimi K3 schloss in Iteration 6 unter Prompt-Version 02 sowohl `solo` als auch `builtin`
ohne Hauptagenten-API-Fehler ab. Auch ein fester Kontext- oder Turnschwellenwert erklärt die
Streuung der Abbruchturns 23 bis 44 nicht.

Die beiden abgebrochenen `builtin`-Wiederholungen haben zusätzliche, getrennte Ursachen:

- Lauf 36 wurde nach sechs gestarteten Subagenten durch einen Stromausfall beendet.
- Lauf 38 wurde nach zehn gestarteten und vier vom Adapter verweigerten Subagenten manuell
  beendet. Der Adapter arbeitete Subagenten synchron ab, obwohl das Modell sie gemeinsam und
  damit parallel angefordert hatte.

Das in Iteration 8 eingeführte 10er-Limit ist keine neutrale Schutzmaßnahme. Anzahl, Typ und
Zerlegung der Subagenten sind selbst Untersuchungsgegenstand von V1b. Nach dem zehnten Start
injizierte der Adapter zudem eine Aufforderung, keine weiteren Subagenten zu starten und sofort
Dateien zu schreiben. Auch die turnabhängigen Schreib-Erinnerungen griffen in die autonome
Strategie ein. Lauf 34 belegt daher nur, dass GLM unter dieser erzwungenen Adapterstrategie
Ergebnisdateien erzeugte; er ist nicht mit einem freien `builtin`-Lauf poolbar.

**Adapterkorrektur und neue Versuchsbedingung (Skill 9.0.0, Adapter 2.0.0):**

- Kein Anzahl-Limit für `spawn_subagent`; Typ und Zahl bestimmt ausschließlich das Modell.
- Alle Subagenten-Aufrufe aus demselben Hauptagenten-Turn laufen tatsächlich parallel.
- Haupt- und Subagenten haben standardmäßig kein Turnlimit; laufzeitabhängige
  Schreib-Erinnerungen wurden entfernt.
- `--timeout 0` bedeutet tatsächlich kein clientseitiges HTTP-Timeout.
- API-Fehler setzen unabhängig von früherem Freitext `is_error: true`, werden nach
  `Stderr.log` geschrieben und führen zu Exitcode 1.
- Ein threadsicheres Lebenszeichen meldet standardmäßig alle 60 Sekunden, welche Operation
  beim Hauptagenten und bei jedem Subagenten aktiv ist. Abgeschlossene API-Turns melden ihren
  Einzel- und kumulierten Tokenverbrauch.

Ein Lebenszeichen während eines API-Aufrufs bedeutet ausschließlich: Der lokale Python-Prozess
lebt und wartet weiterhin auf TensorX. Da die API nicht gestreamt wird, kann der Adapter während
dieser Wartephase nicht unterscheiden, ob serverseitig noch inferiert wird oder der Request
hängt. Der Logtext weist auf diese Grenze ausdrücklich hin. Automatische Abbrüche oder Retries
wurden bewusst nicht eingeführt, weil Laufzeit unerheblich ist und ein Retry zusätzlichen,
möglicherweise doppelten Tokenverbrauch verursachen kann.

Die Implementierung wurde ohne echten API-Aufruf geprüft: zwölf in einem Turn angeforderte
Subagenten starteten ohne Ablehnung parallel; `timeout=0` wurde als unbegrenztes Requests-Timeout
weitergereicht; ein API-Fehler nach vorhandenem Freitext blieb ein Fehler; Haupt- und
Subagentenaktivitäten erschienen gemeinsam im Heartbeat. Alle vier Tests liefen erfolgreich.

Da Parallelität, Limits, Laufsteuerung und Fehlersemantik geändert wurden, ist dies eine neue
Versuchsbedingung. Der nächste TensorX-Lauf beginnt **Iteration 9**; Iteration-8-`builtin`-Läufe
werden nicht mit den neuen freien `builtin`-Läufen gepoolt.

### Versuch 2 – erster Lauf im Modus `custom` (31.08.2026)

Erster Lauf mit rollenspezialisierten Agentendateien überhaupt. Er eröffnet `Iteration 1` in
`Versuche/Versuch_02/`.

**Vorgeschaltete Korrekturen am Versuchsaufbau.** Der bis dahin vorbereitete V2-Prompt
(`01_Prompt.md`, Version 02-A) leitete sich von Prompt-Version **02** ab, während Versuch 1 seit
Iteration 8 auf Version **03** lief. Ein Lauf dagegen hätte sich in zwei Größen unterschieden –
Agentenrollen *und* Prompt-Version – und wäre als Wirkungsnachweis der Rollen unbrauchbar
gewesen. `02_Prompt.md` (Version **03-A**) setzt deshalb auf Prompt-Version 03 auf; einzige
Ergänzung bleibt der Abschnitt *Arbeitsteilung*. Dabei fielen zwei Fehlstellen in
`Versuch_01/03_Prompt.md` auf, die in jeden Lauf der Iterationen 8 und 9 eingingen, weil der
Skill die gesamte Datei sendet: eine leere Änderungstabelle im Metadatenblock und zwei
Tabellenzeilen, die hinter dem Abschnitt *Abschluss* stehen.

**Die Rollennutzung wurde gebunden.** Ein Smoke-Test vom 26.08. hatte gezeigt, dass der Agent von
acht beigestellten Rollen nur zwei einsetzt. Ohne Bindung wird die Versuchsbedingung nicht
hergestellt: Der Lauf führt die Rollen mit, ohne sie zu nutzen. Der Prompt verlangt seither, dass
eine Teilaufgabe, für die ein Bearbeiter vorgesehen ist, von ihm ausgeführt wird; die konkrete
Zuordnung `Teilaufgabe → Rolle` steht im Block *Werkzeugkontext* (Skill 9.1.0), nicht im Prompt,
damit dieselbe Prompt-Datei für `solo` und `builtin` gültig bleibt. Gebunden ist **wer** eine
Teilaufgabe ausführt; Zuschnitt, Anzahl, Reihenfolge und Tiefe bleiben frei.

Die Bindung ist statisch deklariert und über den SHA-256 der `--agents`-Datei versioniert. Sie
ist damit von den in Skill 9.0.0 entfernten **laufzeitabhängigen** Adaptereingriffen zu
unterscheiden, die Lauf 34 unpoolbar machten: Jene steuerten den Lauf abhängig von seinem eigenen
Verlauf um, diese steht vor dem Lauf fest.

**Ergebnis des Laufs** (`Iteration 1/claude-sonnet-5/custom/high/…_v9.1.0-0c39`):

| Messgröße | Wert |
|---|---:|
| Wanduhrdauer | 03:07:16 |
| Tokens gesamt | **352.828.287** |
| Anforderungen | 845 (StRS 185 / SyRS 180 / SwRS 480) |
| Subagenten | 86 gestartet, 86 abgeschlossen, 0 fehlgeschlagen |
| Primärbelegquote | 96,0 % der Belege; 95,6 % der Anforderungen |
| Permission-Denials | 3 (alle Bash, Denylist) |

Der Lauf ist gültig: alle sieben geforderten Dateien, keine Ergänzungsdateien, `Stderr.log` leer,
Root unverändert, Modellkontrolle bestanden. Er ist mit **352,8 Mio. Tokens** zugleich der
aufwendigste der gesamten Reihe – 1,8-fach über dem bisherigen Höchstwert (193,4 Mio., ohne
Artefakt) und 2,3-fach über dem teuersten Lauf mit Ergebnis.

**Die Bindung wirkt.** Alle acht Rollen wurden eingesetzt, gegenüber 2 von 8 im ungebundenen
Smoke-Test. Die Zerlegung blieb dabei frei gewählt: acht Inventar-Ausschnitte, 35 Faktenaufträge,
ID-blockweise Autorenaufträge.

| Rolle | Aufrufe | Rolle | Aufrufe |
|---|---:|---|---:|
| `faktenermittler` | 35 | `syrs-autor` | 6 |
| `general-purpose` | 12 | `Explore` | 4 |
| `swrs-autor` | 10 | `belegpruefer` | 1 |
| `modulinventar` | 8 | `iso29148-orchestrator` | 1 |
| `strs-autor` | 8 | `konsistenzpruefer` | 1 |

**Vier Befunde aus dem Lauf:**

1. **Die Bindung hatte eine Lücke.** 12 Aufrufe gingen an den eingebauten Typ `general-purpose`,
   sämtlich für die Traceability-Anreicherung (Schritt 6) – für die die Zuordnungstabelle keinen
   Bearbeiter vorsah, obwohl `iso29148-orchestrator` laut Rollenprompt dafür zuständig ist. Kein
   Verstoß des Agenten, sondern ein Konstruktionsfehler der Tabelle. Wo die Bindung schweigt,
   greift der Agent zum eingebauten Typ.
2. **Die Selbstauskunft war an einer Stelle falsch.** Der `Analysebericht.md` vermerkt
   *Ausnahmen von der Zuständigkeitsbindung: keine*, obwohl die Traceability von
   `general-purpose` stammt. Aufgefallen ist das nur durch den maschinellen Abgleich gegen
   `subagent_stats.by_type` – die Dokumentationspflicht allein hätte den Fall verdeckt.
3. **`--agents` ersetzt die Agent-Registry nicht, es ergänzt sie.** `Explore` und
   `general-purpose` blieben verfügbar. Ein V2, das ausschließlich die beigestellten Rollen
   zulassen soll, bräuchte zusätzlich eine Sperre – eine geänderte Werkzeugkonfiguration und
   damit eine neue Bedingung.
4. **Die Rollen delegierten selbst.** `spawned_by_subagents` = 26 von 86, `max_depth` = 3. Die
   Rollen erben über `--agents` alle Werkzeuge einschließlich `Task`. Das war nicht beabsichtigt
   und ist der wesentliche Kostentreiber (siehe unten).

**Zwei überholte Annahmen des Skills.** Unter CLI 2.1.251 liegt je Lauf ein Verzeichnis
`subagents/` mit einer vollständigen `.jsonl` je Subagent; die Feststellung, Subagenten-Transkripte
würden nicht auswertbar persistiert (Stand 2.1.245), gilt nicht mehr. Damit wären erstmals auch
die Prompts und Verläufe der Ebenen 2 und 3 auswertbar, die `extract-subagenten.py` nicht
erreicht. Zweitens erfasst `duration_ms` (220.847 ms) den Gesamtlauf erkennbar nicht und ist als
Dauer unbrauchbar; berichtet wird die selbst gemessene Wanduhrzeit.

**Nebenbefund zur Zerlegung.** 72 Aufrufe wurden am Nebenläufigkeitslimit (20 gleichzeitig)
abgewiesen – gegenüber 86 gestarteten die höchste Absagequote der Reihe. Die Zerlegung ist damit
nur eingeschränkt selbstgewählt: Sie ist teilweise vom Werkzeuglimit geformt.

### Kostenanalyse und die Option `unverschachtelt` (Skill 9.2.0, 31.08.2026)

Der Lauf verbrauchte 43 % des verfügbaren Modellkontingents. Für die Wiederholung mit
`claude-opus-5` ist das die bindende Grenze, denn Opus kostet **gleichmäßig das 2,5-fache** von
Sonnet 5 – auf Input, Output, Cache-Write und Cache-Read gleichermaßen. Derselbe Lauf mit Opus
entspräche rund **108 %** des Kontingents; das Ergebnis hängt nicht davon ab, wie das Kontingent
denominiert ist, weil der Faktor uniform ist.

Kostenanteile des Laufs:

| Position | Tokens | Anteil an den Kosten |
|---|---:|---:|
| Cache-Read | 335,3 Mio. | 46 % |
| Output | 4,69 Mio. | 32 % |
| Cache-Write | 12,8 Mio. | 22 % |

Cache-Reads dominieren, und sie entstehen **innerhalb** der Subagenten: Jeder Turn liest den bis
dahin gewachsenen Kontext erneut, die Kosten wachsen daher etwa quadratisch mit der Turn-Zahl je
Agent. Bei 86 Agenten entfallen rechnerisch rund 3,9 Mio. Cache-Reads auf jeden.

Daraus folgt die neue Option **Delegationstiefe** (Skill 9.2.0). `unverschachtelt` untersagt jeder
Rolle in ihrem Prompt die Weiterdelegation; `verschachtelt` entspricht dem bisherigen Verhalten.
Bestehende Läufe gelten rückwirkend als `verschachtelt`. Kontrolle nach dem Lauf über
`subagent_stats.max_depth` und `spawned_by_subagents`.

Die strukturellen Korrekturen allein – keine Weiterdelegation, Faktenübergabe per Datei statt
inline – bringen geschätzt 30 bis 40 %. Nötig wären 60 %. Der Opus-Lauf erfordert deshalb
zusätzlich eine bewusste Bedingungsänderung: **Effort `medium` statt `high`**. Der Modellvergleich
Sonnet-`high` gegen Opus-`medium` ist damit konfundiert; aufzulösen ist das durch einen
zusätzlichen, günstigen Lauf `claude-sonnet-5 / custom / medium`, der Modell- und Effort-Effekt
trennt.

**Anzumerken bleibt:** Die Wirkung des Effort-Wechsels auf einen `custom`-Lauf ist nicht gemessen,
sondern geschätzt. Bleibt der Opus-Lauf über 43 %, ist das selbst ein Befund zur Messbarkeit der
Zelle – vergleichbar mit `claude-opus-5 / builtin / high` aus Versuch 1.

---

### Versuch 2 – Opus-Lauf und die Kontingentgrenze (31.08.2026)

Der zweite V2-Lauf sollte prüfen, ob die Zelle `claude-opus-5 / custom` innerhalb der 43 % des
Modellkontingents machbar ist, die der Sonnet-Lauf verbraucht hatte. **Sie ist es nicht.** Er
eröffnet `Iteration 2` in Versuch 02
(`Iteration 2/claude-opus-5/custom/medium/…_v9.2.0-da6a`).

**Drei Größen wurden gleichzeitig gewechselt**, zwei davon erzwungen durch das Kontingent:

| Größe | Iteration 1 | Iteration 2 |
|---|---|---|
| Modell | `claude-sonnet-5` | `claude-opus-5` |
| Effort | `high` | `medium` |
| Delegationstiefe | `verschachtelt` | `unverschachtelt` |

Ein Modellvergleich zwischen beiden Läufen ist damit **nicht zulässig**; die Gegenüberstellung
unten vergleicht zwei Bedingungen, nicht zwei Modelle.

**Ergebnis:**

| Messgröße | Wert |
|---|---:|
| Wanduhrdauer | 03:47:17 |
| Tokens gesamt | **397.199.658** |
| Anforderungen | 606 (StRS 53 / SyRS 149 / SwRS 404) |
| Subagenten | 56 gestartet, 56 abgeschlossen, 0 fehlgeschlagen, **0 abgewiesen** |
| Permission-Denials | 0 |
| Regelverstöße (maschinell) | **0** |

Der Lauf ist gültig – alle sieben Dateien, `Stderr.log` leer, Root unverändert – **mit einer
Einschränkung: die Modellbedingung ist verletzt.**

**Die Kontingentgrenze ist die eigentliche Nachricht.** Zu Listenpreisen kostet der Lauf rund
$433 gegenüber $146 des Sonnet-Laufs, also das **2,97-fache** und damit rund **128 % des
Kontingents**. Der Preisfaktor zwischen Opus 5 und Sonnet 5 beträgt gleichmäßig 2,5 auf allen
Token-Klassen; die restliche Differenz stammt aus einem um 12,6 % **höheren** Tokenverbrauch –
und zwar trotz `medium` statt `high`, trotz unterbundener Weiterdelegation und trotz 56 statt 86
Agenten. Je Subagent wurden rund 13,6 Mio. Transkript-Tokens verbraucht gegenüber 7,0 Mio. beim
Sonnet-Lauf: Opus zerlegt gröber und arbeitet jeden Ausschnitt tiefer aus. Beide strukturellen
Sparmaßnahmen wurden davon vollständig aufgezehrt.

Die vorab getroffene Schätzung von 38 bis 45 % war damit **deutlich zu niedrig**. Auch die
laufende Live-Schätzung aus den Transkripten traf nicht: Sie meldete kurz vor Laufende 96 %,
tatsächlich waren es 128 %. Der dafür verwendete Kalibrierfaktor – Transkriptsumme geteilt durch
den am Sonnet-Lauf gemessenen Wert 2,45 – beträgt für diesen Lauf nur 1,95. Er ist nicht
laufübergreifend stabil, weil er vom Verhältnis Haupt- zu Subagenten-Nachrichten abhängt. Eine
solche Schätzung taugt zur Richtungsanzeige, nicht zur Budgetsteuerung.

**Damit ist `claude-opus-5 / custom` als unter dem verfügbaren Kontingent nicht wiederholbar
messbare Zelle zu führen** – die zweite nach `claude-opus-5 / builtin / high` aus Versuch 1. In
beiden Fällen ist die Grenze das Kontingent und nicht das Verfahren.

**Modellbedingung verletzt – erstmals auftragsscharf lokalisiert.** `modelUsage` weist neben
`claude-opus-5` (365,0 Mio.) das nicht angeforderte `claude-sonnet-5` mit 32,2 Mio. Tokens
(8,1 %) aus. Weil CLI 2.1.251 jedes Subagenten-Transkript einzeln persistiert, ließ sich der Fall
erstmals genau verorten statt nur als Summe zu sehen: 8 der 56 Subagenten liefen auf Sonnet –
sechs `faktenermittler`, ein `swrs-autor`, ein `modulinventar`. Sieben davon betreffen denselben
Gegenstand (docuFORM, offener Punkt 63), für den der `faktenermittler` sechsmal beauftragt wurde.
Ob der Modellwechsel eine Folge der wiederholten Beauftragung derselben Teilaufgabe ist oder eine
davon unabhängige Zuweisung der CLI, ist aus den Daten nicht zu entscheiden. Der Fall ist der
dritte dokumentierte seiner Art und bestätigt: `--model` bindet den Hauptagenten, nicht
zuverlässig die Subagenten.

**Was die neuen Vorgaben geleistet haben.** Die Delegationstiefe `unverschachtelt` hat
vollständig gegriffen: `spawned_by_subagents` = 0, `max_depth` = 1, 56 Aufrufe gegen 56
Transkripte – und das allein über den Rollenprompt, ohne technische Erzwingung. Als Nebeneffekt
entfielen die Absagen am Nebenläufigkeitslimit vollständig (0 gegenüber 72 im ersten V2-Lauf).

Alle acht Rollen wurden eingesetzt, und zwar **ohne einen einzigen Aufruf an einen eingebauten
Typ** – gegenüber 16 von 86 (18,6 %) im ersten V2-Lauf. Die Bindungslücke bei Schritt 6
(Traceability) blieb absichtlich offen, um die Zahl der geänderten Größen zu begrenzen; sie
wirkte sich hier nicht aus. Die `Traceability.md` entstand ohne ungebundenen Agenten. Ein
Modelleffekt ist naheliegend, bei drei gleichzeitig gewechselten Größen aber nicht belegt.

**Gegenüberstellung der beiden V2-Läufe** – zwei Bedingungen, kein Modellvergleich:

| Kenngröße | Iteration 1 (Sonnet/high/verschachtelt) | Iteration 2 (Opus/medium/unverschachtelt) |
|---|---:|---:|
| Anforderungen | 845 | 606 |
| Verteilung StRS/SyRS/SwRS | 185 / 180 / 480 | 53 / 149 / 404 |
| Belege gesamt | 1.086 | **1.927** |
| Belege je Anforderung (Median) | 1,0 | **3,0** |
| Anforderungen mit `PRIMÄR`-Beleg | 95,6 % | **98,5 %** |
| Anforderungen ohne jeden Beleg | 9 | **0** |
| Hypothesenanteil | 8,9 % | 4,8 % |
| Konsolidierungskandidaten | 22,1 % | 38,3 % |
| mit ISO-25010-Merkmal | **65,9 %** | 13,4 % |
| Subagenten | 86 | 56 |
| Tokens gesamt | 352.828.287 | 397.199.658 |
| Wanduhrdauer | 03:07:16 | 03:47:17 |

Weniger Anforderungen, aber erheblich dichter belegt, und kein einziger maschinell feststellbarer
Regelverstoß gegenüber neun Anforderungen ohne Beleg im ersten Lauf. Zwei Verschlechterungen:
Die ISO-25010-Zuordnung bricht von 65,9 % auf 13,4 % ein, und die StRS-Ebene ist mit 53
Anforderungen (8,7 %) sehr dünn – der `strs-autor` wurde nur dreimal beauftragt, der
`swrs-autor` elfmal. Die Ebenenverteilung bleibt damit auch mit getrennten Autorenrollen die
instabilste Größe der Reihe.

---

### Lokaler Betrieb: LM-Studio-Adapter (Skill 10.1.0, 31.08.2026)

Kapitel 4 sieht neben den Cloud-Modellen den lokalen Betrieb als eigene Bedingung vor. Dafür
wurde der bisherige TensorX-Wrapper zu einem providerneutralen Adapter verallgemeinert:
`opencode-tensorx-adapter.py` heißt jetzt `opencode-adapter.py` und wählt über
`--provider {tensorx,lmstudio}` Gateway und Modellvorlage. Beide Provider durchlaufen denselben
Agenten-, Berechtigungs- und Metrikpfad; die vier bestehenden TensorX-Regressionstests laufen
unverändert durch, laufende V2-Läufe bleiben damit vergleichbar.

Lokale Modelle: `google/gemma-4-e4b` (7,5B, Q4_K_M, gguf) und `qwen/qwen3.8-27b` (27B, Q4_K_M,
gguf) über den OpenAI-kompatiblen LM-Studio-Server auf `localhost:1234`.

**Drei Befunde aus der Inbetriebnahme sind direkt in den Adapter eingeflossen.** Alle drei
hätten unbemerkt ungültige Messpunkte erzeugt:

1. **LM Studio lädt Modelle standardmäßig mit 8192 Kontexttokens** – bei `gemma-4-e4b` von
   131.072 möglichen. Eine Codebasisanalyse wäre serverseitig abgeschnitten worden, ohne dass
   Adapter, Werkzeug oder Protokoll davon etwas gemerkt hätten. Der Preflight fordert deshalb
   `--min-context` (Standard 32768) und bricht sonst mit dem exakten `lms load`-Befehl ab.
2. **Ein erneutes `lms load` erzeugt eine zweite Instanz** (`modell:2`) neben der bestehenden.
   Beide beantworten dieselbe `model`-Angabe der OpenAI-API; welche Instanz – und damit welches
   Kontextfenster – antwortet, ist nicht bestimmt. Der Preflight verlangt daher **genau eine**
   geladene Instanz; `--lmstudio-autoload` stellt das durch Entladen aller Instanzen und einmal
   Neuladen selbst her.
3. **Effort ist lokal nicht steuerbar.** Der LM-Studio-Endpunkt nimmt keinen Thinking-Level
   entgegen. Der angeforderte Wert wird weiterhin protokolliert, aber als
   `effort_applied: false` ausgewiesen und ist im Protokoll als *nicht steuerbar* zu führen –
   nicht als gesetzte Bedingung. Reasoning-Tokens liefern die Modelle trotzdem: `gemma-4-e4b`
   meldete im Smoke-Test 10.218 von 88.650 Tokens als Reasoning.

Für die von Kap. 4.3 geforderten Reproduzierbarkeitsangaben bei lokalem Betrieb schreibt der
Adapter `local_runtime` nach `RawResult.json` – Quantisierung, Architektur, Runtime,
`lms`-Version, Instanzbezeichner sowie maximales und geladenes Kontextfenster – zusätzlich
`context_window` und `_meta/lmstudio-modelle.json` als Rohantwort des Servers. Kosten sind
definitionsgemäß `0` (`cost_source: nicht erfasst (lokaler Betrieb)`), Cache-Metriken liefert
der lokale Server nicht.

**Terminierungsverhalten als eigenständiger Befund.** In zwei Smoke-Läufen schrieb
`gemma-4-e4b` zwar die geforderte Datei, beendete die Aufgabe danach aber nicht, sondern lief
bis zum Laufzeitlimit weiter (25 bzw. 40 Turns). Der Stall-Timeout greift dabei **nicht**, weil
laufend Text erzeugt wird. Lokale Läufe brauchen deshalb zwingend ein absolutes
`--max-runtime`; ein so beendeter Lauf ist als Abbruch zu protokollieren, nicht als Ergebnis.
Das ist keine Adapterschwäche, sondern eine Eigenschaft kleiner lokaler Modelle und für den
Vergleich mit den Cloud-Läufen relevant.

**Nebenbefund zur Fehlersuche:** Ein erster Smoke-Lauf scheiterte an verweigerten Schreibrechten,
obwohl der Zielpfad in der Allowlist stand. Ursache war das Testverzeichnis: OpenCode gleicht
Schreibziele gegen den Pfad *relativ zur Git-Worktree-Wurzel* ab (Skill 10.0.2), und das
Scratchpad war kein Git-Repository. Im Versuchslayout – Codebasis und Laufverzeichnis im selben
Worktree – greift die Freigabe; ein Kontrolltest in einem initialisierten Repository schrieb die
Datei erwartungsgemäß. Die Beobachtung ist festgehalten, weil sie leicht als Adapterfehler
fehlgedeutet wird.

---

## 6. Befunde

### 6.1 Die Anforderungsanzahl ist kein Qualitätsmaß

Vier Läufe unter identischer Bedingung (Nr. 3, 4, 5, 6) ergaben 106, 55, 325 und 189
Anforderungen – Faktor 5,9. Der Unterschied zwischen Lauf 1 (ohne Shell, 96) und Lauf 3 (mit
Shell, 106) liegt vollständig innerhalb dieser Streuung. **Jede Aussage der Form „Konfiguration
X liefert mehr Anforderungen" ist ohne Wiederholungsläufe wertlos.**

### 6.2 Die einzige robuste Wirkung der Werkzeugkonfiguration ist die Denial-Zahl

36 Denials ohne Shell-Zugriff, 0 mit. Das ist eine direkte Eigenschaft der Konfiguration und
keine Zufallsgröße. Alle anderen Kennzahlen streuen zu stark.

### 6.3 Die selbstgewählte Zerlegung dominiert alles

`solo` gegen `builtin`: Streuung Faktor 2,0 gegen 5,9 bei den Anforderungen, Medianverbrauch
5,1 gegen 30,1 Mio. Tokens. Der Effekt gilt modellunabhängig – die Opus-Reihe zeigt dieselbe
Stabilität im Solo-Modus.

Bemerkenswert ist die Gegenläufigkeit von Turns und Delegation: Lauf 15 delegierte am stärksten
(21 Subagenten) und brauchte die wenigsten eigenen Turns (15); Lauf 4 delegierte gar nicht und
brauchte 147. **`num_turns` zählt nur den Hauptagenten und ist deshalb kein Aufwandsmaß.**

### 6.4 Verschachtelte Delegation ist der Normalfall, nicht die Ausnahme

In vier von fünf Läufen des Blocks 12–16 erreichte die Delegation Tiefe 2, mit 3 bis 9 von
Subagenten gestarteten Subagenten. Ein Kontrolltest belegte, dass deren Tokens vollständig in
`modelUsage` einfließen – ihre **Prompts** dagegen liegen in nicht persistierten Transkripten
und sind nicht rekonstruierbar. Die Prompt-Erfassung ist in diesen Läufen systematisch
unvollständig, die Verbrauchsmessung nicht.

### 6.5 Modellstärke und Ertrag

| Reihe | Anforderungen (Median) | Tokens (Median) | Tokens je Anforderung |
|---|---:|---:|---:|
| Sonnet 5, solo, high | 67 | 5,1 Mio. | ~76.000 |
| Opus 5, solo, high | 114 | 22,8 Mio. | ~200.000 |
| Fable 5, solo, max | 178 | 27,6 Mio. | ~155.000 |

Der Mehrertrag stärkerer Modelle wird mit überproportionalem Verbrauch erkauft. Die
Anforderungsanzahl misst allerdings nur Menge; die Belegqualität ist davon unabhängig zu
betrachten.

### 6.6 Regelkonformität – der Agent verfehlt teilweise die eigenen Vorgaben

Die maschinelle Auswertung prüft die Artefakte gegen die Vorgaben des Prompts. Zwei Beispiele:

- **Lauf 11** (Sonnet, solo): 5 von 31 risikorelevanten Anforderungen tragen weder einen
  `PRIMÄR`-Beleg noch die Kennzeichnung `[HYPOTHESE]`, obwohl der Prompt das für Sicherheits-,
  Abrechnungs- und Berechtigungsthemen ausdrücklich verlangt. Primärbelegquote 62,7 %.
- **Lauf 24** (Fable/Opus, builtin): alle 58 risikorelevanten Anforderungen gedeckt,
  Primärbelegquote 100 %, Median 2 Belege je Anforderung.

Diese Prüfung wäre von Hand nicht leistbar und liefert eine inhaltliche Vergleichsgröße, die
unabhängig vom Mengengerüst ist.

### 6.7 Werkzeugtechnische Befunde

| Befund | Beleg |
|---|---|
| `--safe-mode` unterdrückt das *Vorladen* von Projektanweisungen, nicht das *Lesen* | Kontrolltest: ohne Flag zitiert der Agent `CLAUDE.md`, mit Flag „NICHTS VORGELADEN"; mit Shell liest er sie dennoch |
| Gesperrte Werkzeuge erzeugen keine Denials | In allen 12 Solo-Läufen 0 Denials auf `Task`/`Agent`/`Workflow` – das Modell plant von vornherein ohne sie |
| `--model` steuert nur den Hauptagenten | Lauf 24: 91 % des Verbrauchs auf nicht angefordertem Modell |
| Der Effort steht nicht im Ergebnisobjekt | Nur über das Session-Transkript belegbar |
| `duration_ms` ist bei starker Nebenläufigkeit unbrauchbar | Lauf 5: 09:37 gemeldet, 43:01 tatsächlich |
| Ein Lauf schrieb außerhalb von Codebasis und Laufverzeichnis | Lauf 13 legte drei Arbeitsdateien in `C:\DEV\` an; nur weil die Denylist das Aufräumen blockierte, wurde es sichtbar |

Der letzte Punkt ist methodisch der unangenehmste: Die etablierte Prüfung „Root unverändert"
deckt ausschließlich die Codebasis ab. Schreibvorgänge in andere Verzeichnisse bleiben unbemerkt.

---

## 7. Prompt-Version 02 (26.08.)

Bis hierher waren alle 24 Läufe **Wiederholungsmessungen desselben Prompts** – der SHA-256 blieb
über zwei Tage identisch. Prompt-Version 02 ist damit die erste Prompt-Version im Sinne von Kapitel 4:
Der Prompt wird auf Basis der Auswertung überarbeitet, jede Änderung ist an einen gemessenen
Befund gekoppelt.

### Was der Prompt bereits zuverlässig steuert

Diese Teile blieben unverändert, weil die Auswertung keine Schwäche zeigt:

| Vorgabe | Ergebnis über 3.287 Anforderungen |
|---|---|
| Prüfidee je Anforderung | 100 % erfüllt |
| Tracelinks je Anforderung | 100 % erfüllt |
| Belegklassifikation | 78,6 % `PRIMÄR`, 11,5 % `SEKUNDÄR`, 9,8 % `KONTEXT` |
| Blockformat der Anforderungen | über alle Läufe eingehalten |

### Was der Prompt nicht steuerte

| Befund | Zahl |
|---|---|
| Anforderungen je Lauf | 42 – 325 (Faktor 5,9) |
| Modultabellen im Analysebericht | 0 – 51 Zeilen |
| Läufe ohne jede Hypothese | 2 (bei 71 bzw. 148 Anforderungen) |
| Hypothesenanteil je Lauf | 0 % – 26,2 % |
| Konsolidierungskandidaten je Lauf | 2,4 % – 35,2 % |
| Anforderungen mit genau einem Beleg | 45,9 % |
| Anforderungen ohne jeden Beleg | 1 |
| ISO-25010-Merkmal als eigenes Feld | 50 von 3.287 (1,5 %) |
| verschiedene `Typ`-Werte | 301 |

### Abgeleitete Änderungen

1. **Abdeckung wird gesteuert statt dem Modell überlassen.** Der Satz „Priorisiere die
   Analysetiefe selbstständig" entfällt. An seine Stelle tritt eine dreistufige Vorstufe:
   Modulinventar vor der ersten Anforderung, dann Mindestabdeckung mit mindestens einer
   Anforderung je Modul, dann Vertiefung nach Risiko. Begründung im Prompt: Ein fehlendes
   Requirement führt bei einer Neuimplementierung zu Funktionsverlust, eine flach erfasste
   Funktion lässt sich nachschärfen.
2. **Hypothesenpflicht kalibriert.** Wer keine Hypothese führt, begründet das ausdrücklich.
   `Hypothesen.md` muss deckungsgleich mit den Inline-Markierungen sein.
3. **Primärbeleg präzisiert.** Bei Risikoanforderungen genügt ein Dateipfad nicht mehr; der
   Beleg benennt Datei, Klasse, Methode und die konkrete Prüfung.
4. **Belegpflicht verschärft.** Ohne Beleg wird die Anforderung nicht geschrieben, der offene
   Punkt wird als Hypothese erfasst.
5. **Konsolidierungsbegriff an einem Beispiel kalibriert** (Stammblätter gegenüber Assets), mit
   ausdrücklicher Abgrenzung gegen ebenenübergreifende Dubletten.
6. **Feld `Qualitätsmerkmal`** für die ISO-25010-Zuordnung, die bislang keinen Ablageort hatte.
7. **Konsistenzcheck erweitert** um eine Liste aller risikorelevanten Anforderungen mit ihrer
   Belegsituation und um den Abgleich der Hypothesenliste.

### Bewusst nicht geändert

Die formale Streuung – 301 `Typ`-Werte, zwei ID-Schemata, acht Hypothesen-Formate – bleibt
bestehen. Geschlossene Vokabulare und erzwungene Dateivorlagen hätten sie beseitigt, wurden aber
verworfen, um die Formulierungsfreiheit nicht einzuschränken. Für die Auswertung ist diese
Streuung als Rauschen zu behandeln; die maschinelle Analyse ist entsprechend heuristisch
ausgelegt.

### Nebenbefund: Der Prompt war nachträglich verändert worden

Bei der Einführung von `02_Prompt.md` fiel auf, dass `01_Prompt.md` im Zuge der
werkzeugneutralen Überarbeitung geändert und committet worden war. Der in allen 24 Protokollen
dokumentierte SHA-256 zeigte damit auf eine Fassung, die im Repository nicht mehr existierte.

Die As-Run-Fassung ließ sich **bitgenau rekonstruieren**: Aus dem je Lauf archivierten
`_meta/combined_prompt.md` den Text vor dem angehängten Ausgabeverzeichnis-Block abschneiden,
Zeilenenden normalisieren – das Ergebnis stimmt für drei unabhängig geprüfte Läufe exakt mit
`1B0DB06B…3C02FF` überein. `01_Prompt.md` wurde darauf zurückgesetzt.

**Methodische Lehre:** Die Archivierung des tatsächlich gesendeten Prompts je Lauf, ursprünglich
als Nebeneffekt der Parallelfähigkeit eingeführt (Skill 3.1.0), hat hier die Reproduzierbarkeit
gerettet. Ohne sie wäre der Bezug zwischen Protokoll und Prompt unwiederbringlich verloren
gewesen.

### Offene Frage

Ob die Steuerung greift, ist eine empirische Frage. Erwartet wird eine höhere Anforderungszahl
bei geringerer Tiefe je Modul und eine **kleinere Streuung** zwischen Läufen. Der Vergleich mit
den fünf Solo-Läufen von Tag 1 (42 bis 82 Anforderungen, Faktor 2,0) wird das zeigen. Möglich
ist auch, dass die Mindestabdeckung nur die Zahl flacher Anforderungen erhöht, ohne die
Belegqualität zu halten – dann wäre die Änderung zurückzunehmen.

---

## 8. Grenzen und offene Punkte

**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:** Die Zelle `claude-opus-5 / builtin / high` ist **dreimal** gescheitert
(einmal Zeitlimit, zweimal Session-Kontingent) und hat dabei 790,7 Mio. Tokens ohne ein Artefakt
verbraucht. Sie wird als nicht messbare Kombination dokumentiert statt ein viertes Mal versucht.
Ein weiterer Anlauf wäre nur mit gedrosselter Nebenläufigkeit
(`CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS`) sinnvoll – das wäre allerdings eine geänderte
Werkzeugkonfiguration und nicht mehr mit den Sonnet-`builtin`-Läufen vergleichbar.

Seit dem 31.08. kommt eine zweite solche Zelle hinzu: `claude-opus-5 / custom`. Sie ist
**messbar, aber nicht wiederholbar bezahlbar** – ein einzelner Lauf verbrauchte rund 128 % des
Modellkontingents, und zwar bereits in der sparsamsten sinnvollen Fassung (`medium` statt `high`,
Rollen ohne Weiterdelegation). Der Unterschied zur Opus-`builtin`-Zelle ist wesentlich: Dort
entstand kein Artefakt, hier ein vollständiges und regelkonformes. Die Grenze ist in beiden
Fällen das Kontingent, nicht das Verfahren.

**Bedingungsverletzt statt unbelegt:** Die Zelle `claude-fable-5 / builtin / *` ist messbar, aber
die Modellbedingung ist dort nicht herstellbar – die Subagenten laufen auf `claude-opus-5[1m]`.
Läufe dieser Zelle sind für Modellvergleiche unbrauchbar und nur als Beleg für die
Durchreichungsgrenze zu verwenden.

**Kontingent als Versuchsgrenze:** Rund ein Drittel des Gesamtverbrauchs von 2.294,7 Mio. Tokens
entfiel auf Läufe ohne verwertbares Ergebnis, überwiegend durch Parallelbetrieb an der
Kontingentgrenze. Seit dem 27.08. wird strikt seriell gefahren.

**Offen für Versuch 2 und 3:** Bei Delegation ist die Modellbedingung über `--model` allein nicht
herstellbar – inzwischen **drei** dokumentierte Fälle, der jüngste erstmals auftragsscharf
lokalisiert (8 von 56 Subagenten des Opus-Laufs auf `claude-sonnet-5`). `extract-subagenten.py`
ist seit dem 31.08. an zwei `custom`-Läufen erprobt und rechnet dort exakt gegen
`subagent_stats` auf; es erreicht jedoch nur die direkt vom Hauptagenten gestarteten Subagenten.
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.

**Offen aus den V2-Läufen:** Die Bindungstabelle im Werkzeugkontext führt für Schritt 6
(Traceability-Anreicherung) keinen Bearbeiter, obwohl `iso29148-orchestrator` dafür zuständig
wäre; die Zeile ist zu ergänzen. `--agents` ergänzt die Agent-Registry, statt sie zu ersetzen –
soll V2 ausschließlich die beigestellten Rollen zulassen, braucht es zusätzlich eine Sperre und
damit eine neue Bedingung. Die Regel „Rollen legen keine Dateien an" ist zu präzisieren:
Ergebnisdateien verboten, Scratchpad-Übergabe zulässig und zu dokumentieren. Schließlich ist
`extract-subagenten.py` auf die seit CLI 2.1.251 je Subagent persistierten Transkripte zu
erweitern – erst damit werden auch verschachtelte Ebenen auswertbar.

**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
korrekt sind, ist damit ausdrücklich **nicht** gezeigt.

**Stand der Versuche:** Versuch 2 (Agentendateien) ist seit dem 31.08. mit zwei Läufen belegt –
`claude-sonnet-5 / custom / high / verschachtelt` und `claude-opus-5 / custom / medium /
unverschachtelt`. Beide sind gültig, aber wegen dreier gleichzeitig gewechselter Größen nicht
gegeneinander als Modellvergleich verwertbar; für eine saubere Trennung fehlt ein Lauf
`claude-sonnet-5 / custom / medium / unverschachtelt`. **Nicht abgedeckt bleibt Versuch 3**
(MCP-Server): Der Skill ist darauf vorbereitet, die MCP-Konfiguration und das zugehörige
Protokollfeld fehlen aber noch.

**Offene Aufräumarbeiten:** Drei Streudateien in `C:\DEV\` aus Lauf 13; die Erweiterung der
Nachlaufprüfung um Streudateien außerhalb des Laufverzeichnisses.

**Nicht poolbar:** Iteration 2 und Iteration 3 unterscheiden sich im Untersuchungsgegenstand
(`SSMS_DB_SCHEMA.sql`, Commit `f349d189`). Ein Vergleich beider misst die Wirkung des
Datenbankschemas – ein eigener Befund, keine Wiederholungsmessung. Mit n = 5 je Gruppe und
überlappenden Spannen ist diese Wirkung derzeit **nicht** belegt.

**Messtechnisch offen:** Der Snapshot-Zustand wird über `git status` geführt. Wird eine Datei
zwischen Laufbeginn und Auswertung committet, sind Vorher- und Nachher-Stand gleich, obwohl die
Zustände es nicht sind (Fall `4840`). Ein Inhaltshash des Arbeitsverzeichnisses je Lauf würde das
schließen.

**Offen für Prompt-Version 03:** Der Prompt schreibt die Ebene der Mindestabdeckung nicht vor.
Das ist die verbliebene Hauptquelle der Strukturstreuung – von 92,7 % StRS bis 89,4 % SwRS bei
identischem Prompt.

**Einschränkung der Zeitmessung:** 18 der 24 Läufe liefen parallel. Für belastbare
Laufzeitvergleiche wären serielle Wiederholungen nötig. Eine Teilauswertung zeigt bei den
Solo-Läufen einen messbaren Kontentionseffekt: bei zwei gleichzeitigen Läufen 114–176 Sekunden
je Million Tokens, bei drei gleichzeitigen 185–233 – nicht überlappende Bereiche trotz kleiner
Stichprobe.

---

## 9. Verweise

- Messprotokolle je Lauf: `Versuche/Versuch_01/Tag 1/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/Protokoll.md`
- Rohdaten: `RawResult.json` je Lauf, unverändert erhalten
- Exakt gesendeter Prompt je Lauf: `_meta/combined_prompt.md`
- Subagenten-Prompts: `_meta/subagenten.md`
- Maschinelle Anforderungsauswertung: `_meta/anforderungen.md` und `.json`
- Prozessvorgabe: `.claude/skills/run-experiment/SKILL.md` (Version 10.1.0, mit Änderungshistorie)
- OpenCode-Adapter (TensorX und LM Studio): `.claude/skills/run-experiment/references/opencode-adapter.md`
- Messprotokolle Versuch 2: `Versuche/Versuch_02/<Iteration>/<ModellID>/custom/<Effort>/<Laufverzeichnis>/Protokoll.md`
- Agentenrollen: `Versuche/Versuch_02/02_Agents.json` (verschachtelt), `03_Agents.json` (unverschachtelt)
- Nachweis des Untersuchungsgegenstands: `Versuche/Versuch_01/_Codebasis-Nachweis.md`
- Struktur- und Umbenennungshistorie: `Versuche/Versuch_01/_Umbenennung_*.md`,
  `_Umstrukturierung_2026-08-26.md`