Tag 1 abgeschlossen

Versuche/AblaufProtokoll.md

@@ -0,0 +1,342 @@
+# 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`