# Ablaufprotokoll der Versuchsdurchführung

**Zeitraum:** 25.–26. August 2026
**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 fünf 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 wurden Struktur und Dokumentation konsolidiert: Umstellung der
Kostenangabe auf Tokenverbrauch, Ordnerstruktur nach Bedingungen, maschinelle Auswertung der
erzeugten Anforderungen, Sicherung des Untersuchungsgegenstands im Arbeitsrepository sowie die
Trennung von Analyseanweisung (Prompt) und Prozessvorgabe (Skill).

---

## 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 Iterationen im Sinne von Kapitel 4.

Erst nach Abschluss der Läufe wurde er überarbeitet (2026-08-26):

| Ä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)

17 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 |

**Beobachtung für die Diskussion:** Zehn der sechzehn Änderungen gehen auf Messfehler oder
Fehlannahmen zurück, die erst im Betrieb sichtbar wurden – nicht auf Planungslücken im
klassischen Sinn. Ein Versuchsaufbau für agentische LLM-Werkzeuge lässt sich offenbar nicht
vollständig vorab spezifizieren.

---

## 5. Durchgeführte Läufe

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

| # | 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 |

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.

---

## 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. 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.

**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.

**Nicht abgedeckt:** Versuch 2 (Agentendateien) und Versuch 3 (MCP-Server). Der Skill ist darauf
vorbereitet (Modus `custom`), die Agentendefinitionen existieren aber noch nicht.

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

**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.

---

## 8. Verweise

- Messprotokolle je Lauf: `Versuche/Versuch_01/<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 4.0.0, mit Änderungshistorie)
- Nachweis des Untersuchungsgegenstands: `Versuche/Versuch_01/_Codebasis-Nachweis.md`
- Struktur- und Umbenennungshistorie: `Versuche/Versuch_01/_Umbenennung_*.md`,
  `_Umstrukturierung_2026-08-26.md`