Lots of runs

Versuche/AblaufProtokoll.md

@@ -1,6 +1,7 @@
 # Ablaufprotokoll der Versuchsdurchführung
 
 **Zeitraum:** 25.–26. August 2026
+**Ablage der Läufe:** `Versuche/Versuch_01/Tag 1/` – alle 24 Läufe entstanden am 25. August
 **Untersuchungsgegenstand:** c-entron ERP-Suite, eingefrorener Snapshot `79c1142`
 **Zweck dieses Dokuments:** Grundlage für den Ergebnisteil der Arbeit (Kapitel 5 und 6).
 
@@ -29,7 +30,7 @@ gleichen Bedingungen streuen.
 
 ---
 
-## 2. Chronologie in fünf Phasen
+## 2. Chronologie in sechs Phasen
 
 ### Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
 
@@ -135,10 +136,156 @@ 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).
+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.
 
 ---
 
@@ -146,9 +293,12 @@ Trennung von Analyseanweisung (Prompt) und Prozessvorgabe (Skill).
 
 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.
+Wiederholungsmessungen desselben Prompts, keine Prompt-Versionen im Sinne von Kapitel 4.
 
-Erst nach Abschluss der Läufe wurde er überarbeitet (2026-08-26):
+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 |
 |---|---|
@@ -165,7 +315,7 @@ 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:
+19 Versionen in zwei Tagen. Jede geht auf eine konkrete Beobachtung zurück:
 
 | Version | Änderung | Auslöser |
 |---|---|---|
@@ -186,11 +336,16 @@ Voraussetzung für den in Kapitel 4 geplanten LLM-Querschnitt.
 | 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:** Zehn der sechzehn Änderungen gehen auf Messfehler oder
+**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. Ein Versuchsaufbau für agentische LLM-Werkzeuge lässt sich offenbar nicht
-vollständig vorab spezifizieren.
+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.
 
 ---
 
@@ -305,7 +460,93 @@ deckt ausschließlich die Codebasis ab. Schreibvorgänge in andere Verzeichnisse
 
 ---
 
-## 7. Grenzen und offene Punkte
+## 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
 
 **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
@@ -321,6 +562,20 @@ 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.
 
+**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
@@ -329,9 +584,9 @@ Stichprobe.
 
 ---
 
-## 8. Verweise
+## 9. Verweise
 
-- Messprotokolle je Lauf: `Versuche/Versuch_01/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/Protokoll.md`
+- 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`