Lots of runs

.claude/skills/run-experiment/SKILL.md

@@ -2,7 +2,7 @@
 name: run-experiment
 description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf aus (claude -p) und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
 argument-hint: <Pfad zur Prompt-Datei> <Root-Verzeichnis>
-version: 4.0.0
+version: 4.5.0
 ---
 
 # RunExperiment – Versuchslauf mit Messprotokoll
@@ -36,7 +36,7 @@ Laufverzeichnis neben der Prompt-Datei**, niemals im Root-Verzeichnis:
 ```
 <Verzeichnis der Prompt-Datei>\
   <NN>_Prompt.md
-  <ModellID>\<Agentenmodus>\<Effort>\
+  <Iteration>\<ModellID>\<Agentenmodus>\<Effort>\
     <NN>_Lauf_<yyyy-MM-dd_HHmmss>_v<skillversion>-<id4>\
       Protokoll.md
       RawResult.json
@@ -48,6 +48,26 @@ Laufverzeichnis neben der Prompt-Datei**, niemals im Root-Verzeichnis:
 
 **Die unabhängigen Variablen bilden die Ordnerebenen, nicht den Dateinamen:**
 
+- `<Iteration>` – `Iteration 1`, `Iteration 2`, … fortlaufend. Die Ebene hält Blöcke auseinander, die
+  unter unterschiedlichem Stand des Versuchsaufbaus **oder des Untersuchungsgegenstands**
+  entstanden sind. **Vor dem Anlegen die höchste vorhandene Iteration ermitteln** und entscheiden,
+  ob der Lauf dazugehört oder eine neue Iteration eröffnet – im Zweifel den User fragen.
+
+  Eine neue Iteration ist zu eröffnen, wenn sich etwas ändert, das Läufe **nicht mehr poolbar**
+  macht: der Codebasis-Snapshot, die Prompt-Version, die Werkzeugkonfiguration oder eine
+  MAJOR-Version dieses Skills. Reine PATCH- und MINOR-Änderungen begründen keine neue Iteration.
+
+  **Abgrenzung zur Prompt-Version.** `<Iteration>` meint die *Versuchs*iteration – eine Menge
+  poolbarer Läufe. Die Fassung der Prompt-Datei heißt seit Version 4.4.0 durchgängig
+  **Prompt-Version** (`01_Prompt.md` = Prompt-Version 01). Beides fällt nicht zusammen:
+  Iteration 2 und Iteration 3 laufen beide unter Prompt-Version 02 und unterscheiden sich nur
+  im Untersuchungsgegenstand.
+
+  Die Ebene hieß bis Version 4.3.0 `<Versuchstag>` mit Werten `Tag 1`, `Tag 2`, …. Der Name band
+  sie an das Kalenderdatum, obwohl sie die Vergleichbarkeit abbildet: Iteration 2 und Iteration 3
+  entstanden am selben Tag, unterscheiden sich aber im Untersuchungsgegenstand (Iteration 3
+  enthält den DB-Schema-Dump `SSMS_DB_SCHEMA.sql`, Iteration 2 nicht). Maßgeblich ist die
+  Vergleichbarkeit, nicht das Datum.
 - `<ModellID>` – die an `--model` übergebene ID, z. B. `claude-sonnet-5`, `claude-opus-5`,
   `claude-fable-5`
 - `<Agentenmodus>` – `solo`, `builtin` oder `custom`
@@ -62,7 +82,7 @@ Der Verzeichnisname trägt nur noch, was den einzelnen Lauf identifiziert:
 
 **Warum Ordnerebenen statt Namensbestandteile:** Der Name wuchs mit jeder neuen unabhängigen
 Variable weiter und war mit fünf Bestandteilen kaum noch lesbar. Als Ordnerebenen sind die
-Bedingungen navigierbar, je Zelle abzählbar (`ls <modell>/<modus>/<effort> | wc -l` ergibt
+Bedingungen navigierbar, je Zelle abzählbar (`ls "<tag>/<modell>/<modus>/<effort>" | wc -l` ergibt
 unmittelbar die Anzahl der Messpunkte) und beim Hinzufügen einer weiteren Variable erweiterbar,
 ohne bestehende Namen zu brechen. Die Angaben sind **redundant zum Protokoll** – bei Widerspruch
 gilt das Protokoll.
@@ -91,8 +111,15 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
 
 ### 1. Vorbereitung
 
-1. Prompt-Datei lesen. Existiert sie nicht: abbrechen und den User informieren.
-2. Aus dem Metadaten-Block der Prompt-Datei (falls vorhanden) Versuch/Iteration übernehmen.
+1. **Prompt-Datei bestimmen und lesen.** Nennt der User eine Datei ausdrücklich, gilt diese.
+   Andernfalls im Versuchsordner die **höchste Prompt-Versionsnummer** wählen (`02_Prompt.md` vor
+   `01_Prompt.md`) und die getroffene Wahl im Abschlussbericht nennen. Existiert die Datei
+   nicht: abbrechen und den User informieren.
+
+   Die gewählte Datei wird mit Pfad **und** SHA-256 ins Protokoll übernommen. Ältere
+   Prompt-Versionen bleiben unverändert liegen – sie sind der Beleg dafür, unter welcher Fassung
+   frühere Läufe entstanden sind, und dürfen nicht nachträglich angepasst werden.
+2. Aus dem Metadaten-Block der Prompt-Datei (falls vorhanden) Versuch/Prompt-Version übernehmen.
 3. **CLI-Pfad auflösen.** Unter Windows liegt `claude` in der Regel **nicht im PATH**. Erst
    `Get-Command claude -ErrorAction SilentlyContinue` versuchen; schlägt das fehl, auf die
    VSCode-Extension zurückfallen und die höchste Versionsnummer wählen:
@@ -185,14 +212,23 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
    - SHA-256 der Prompt-Datei: `(Get-FileHash <datei> -Algorithm SHA256).Hash`
    - Claude-Code-Version: `& $claude --version`
    - Git-Zustand des Root-Verzeichnisses: `git -C <root> rev-parse HEAD` und
-     `git -C <root> status --porcelain` (dirty ja/nein)
+     `git -C <repo> status --porcelain -- <pfad-des-roots>` (dirty ja/nein).
+     **Immer pfadskopiert prüfen.** Liegt die Codebasis als Unterverzeichnis im Arbeitsrepo
+     (seit Commit `f045b99a` der Fall, davor ein eigenes Repo per Gitlink), meldet ein
+     unskopiertes `git -C <root> status --porcelain` den Status des **gesamten** Arbeitsrepos –
+     einschließlich aller Versuchsordner. Der Vorher/Nachher-Vergleich schlägt dann bei jedem
+     Lauf falsch an.
    - Git-Commit dieses Repos (Stand der Prompt-Datei): `git rev-parse HEAD`
 8. **Kollisionsfreies Laufverzeichnis anlegen.** Sekundengenau, mit Agentenmodus und
    Zufalls-ID; bei Namenskollision neu würfeln:
    ```powershell
    # Bedingungen werden Ordnerebenen, nicht Namensbestandteile
-   $zelle = Join-Path (Join-Path $modell $modus) $effort
-   $skillVer = 'v4.0.0'   # entspricht version: im Frontmatter dieses Skills
+   # Iteration ermitteln: hoechste vorhandene Iteration, sonst 'Iteration 1'
+   $iterationen = Get-ChildItem "<promptverzeichnis>" -Directory -Filter 'Iteration *' -EA SilentlyContinue |
+             Sort-Object { [int]($_.Name -replace '\D','') }
+   $iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' }
+   $zelle = Join-Path (Join-Path (Join-Path $iteration $modell) $modus) $effort
+   $skillVer = 'v4.5.0'   # entspricht version: im Frontmatter dieses Skills
    do {
      $id4  = '{0:x4}' -f (Get-Random -Maximum 65536)
      $lauf = Join-Path "<promptverzeichnis>\$zelle" "<NN>_Lauf_$(Get-Date -Format 'yyyy-MM-dd_HHmmss')_${skillVer}-$id4"
@@ -205,7 +241,8 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
    nicht der gemeinsame Scratchpad:
    ```powershell
    # Leerwertsicher: -Value erzwingt das Schreiben auch bei sauberem Root.
-   Set-Content -Path "$lauf\_meta\before.txt" -Value (git -C <root> status --porcelain | Out-String)
+   Set-Content -Path "$lauf\_meta\before.txt" `
+     -Value (git -C <repo> status --porcelain -- <pfad-des-roots> | Out-String)
    ```
    **Nicht** `git ... | Set-Content <datei>` verwenden: Ist die Pipeline leer (sauberes Root),
    schreibt `Set-Content` die Datei nicht und lässt einen alten Inhalt stehen. Der
@@ -336,7 +373,7 @@ Bedeutung der Flags:
 | `--safe-mode` | Isolation: CLAUDE.md, Skills, Plugins, Hooks, MCP-Server, Custom-Agenten, Commands und Output-Styles aus – ohne Dateieingriff. Auth, Modellwahl, eingebaute Tools und Permissions bleiben normal aktiv. |
 | `--strict-mcp-config` | zweite Absicherung gegen MCP-Server aus Projekt- oder User-Konfiguration |
 | `--permission-mode acceptEdits` | Schreibrechte für die Ergebnisdateien im Laufverzeichnis |
-| `--allowedTools "Bash" "PowerShell"` | **Shell-Zugriff ohne Rückfrage** – Standard seit Iteration 02 |
+| `--allowedTools "Bash" "PowerShell"` | **Shell-Zugriff ohne Rückfrage** – Standard seit Prompt-Version 02 |
 | `--disallowedTools <Denylist>` | schreibende und bauende Kommandos gesperrt; Deny hat Vorrang vor Allow |
 | `--add-dir "$lauf"` | Schreibziel außerhalb des Arbeitsverzeichnisses |
 | `@agentFlags` | Agentenmodus aus Schritt 5: `solo` sperrt `Task`/`Agent`, `builtin` fügt nichts hinzu, `custom` übergibt `--agents` |
@@ -429,10 +466,10 @@ und die Summe der Transkript-Nachrichten ist **kein** gültiges Verbrauchsmaß (
 
 Zwei Auswertungsfallen:
 - **`usage` erfasst ausschließlich den Hauptagenten.** Für den abrechnungsrelevanten
-  Gesamtverbrauch ist `modelUsage` über alle Modell-IDs zu summieren. In Iteration 01 standen
+  Gesamtverbrauch ist `modelUsage` über alle Modell-IDs zu summieren. In Prompt-Version 01 standen
   105.959 Output-Tokens in `usage` gegenüber 249.040 in `modelUsage`.
 - **`duration_api_ms` kann die Wanduhrzeit übersteigen**, wenn Subagenten parallel laufen
-  (Iteration 01: 47:05 API gegenüber 31:31 Wanduhr). Das ist kein Widerspruch, sondern die
+  (Prompt-Version 01: 47:05 API gegenüber 31:31 Wanduhr). Das ist kein Widerspruch, sondern die
   Summe nebenläufiger Anfragen – im Protokoll entsprechend einordnen.
 
 **Pflichtprüfung: tatsächlich eingesetzte Modelle.** Nach jedem Lauf die Schlüssel von
@@ -479,7 +516,16 @@ Es schreibt `_meta\subagenten.md` (lesbar, mit vollständigem Prompt je Subagent
 `subagent_type`, `description`, Hintergrund-Flag, Prompt-Länge und Länge des zurückgelieferten
 Ergebnisses.
 
-**Plausibilitätskontrolle:** Das Skript vergleicht die gefundene Anzahl mit
+**Abgewiesene Starts sind keine Subagenten.** Erreicht der Hauptagent das
+Nebenläufigkeitslimit (20 gleichzeitige Subagenten), erscheint der Aufruf im Transkript wie ein
+regulärer Start, liefert aber nur die Absage „Concurrent subagent limit reached" zurück und zählt
+**nicht** in `spawned`. Das Skript trennt beide Fälle und weist die Absagen getrennt aus; ohne
+diese Trennung meldet der Abgleich eine Abweichung, die es nicht gibt (Lauf
+`Iteration 3/…/125032_v4.4.0-fb24`: 21 gefundene Aufrufe gegenüber 13 erwarteten – die Differenz
+waren 8 Absagen). Die Zahl der Absagen ist selbst eine Messgröße: Sie zeigt, wie viel stärker der
+Agent parallelisieren wollte, als das Werkzeug zuließ.
+
+**Plausibilitätskontrolle:** Das Skript vergleicht die Anzahl der **echten** Starts mit
 `subagent_stats.spawned` minus `spawned_by_subagents`. Im Haupttranskript stehen nämlich nur die
 **direkt** vom Hauptagenten gestarteten Subagenten – von Subagenten gestartete (`max_depth` > 1)
 liegen in deren eigenen Transkripten. Bei Abweichung setzt das Skript eine Warnung in
@@ -507,6 +553,14 @@ aus `Ergebnisse\StRS.md`, `SyRS.md` und `SwRS.md` und schreibt `_metanforderung
 - **Belegqualität**: Anzahl der Belege, Aufteilung `PRIMÄR`/`SEKUNDÄR`/`KONTEXT`, Median je
   Anforderung, Anteil mit mindestens einem Primärbeleg
 - **Status**: belegt, `[HYPOTHESE]`, Workaround, Konsolidierungskandidaten
+**Die Ebene einer Anforderung wird nicht aus dem Dateinamen abgeleitet.** Maßgeblich ist das
+Feld `Ebene:` des Blocks, hilfsweise das ID-Präfix, erst zuletzt die Datei. Agenten legen Blöcke
+regelmäßig in der Datei einer anderen Ebene ab – im Lauf `Iteration 2/…/094250_v4.2.1-c69e` standen
+12 StRS- und 5 SyRS-Blöcke in `SwRS.md`. Wird nach Datei gezählt, ist die Verteilungstabelle
+falsch, obwohl die Gesamtzahl stimmt. Das Skript weist eine solche Fremdablage als eigene
+Auffälligkeit unter der Verteilungstabelle aus; sie ist ein Befund zur **Set-Qualität**, weil die
+Dreiteilung dann nicht mehr an der Dateistruktur ablesbar ist.
+
 - **Regelkonformität** – geprüft wird gegen die Vorgaben des Prompts selbst:
   Belegpflicht (jede Anforderung ≥ 1 Beleg), risikobasierte Priorisierung (Sicherheit,
   Abrechnung, Berechtigungen brauchen `PRIMÄR` **oder** `[HYPOTHESE]`), Verifizierbarkeit
@@ -532,7 +586,8 @@ Der erzeugte Abschnitt wird **unverändert** als `## Gefundene Anforderungen` in
 übernommen, zwischen `## Ergebnis` und den Vergleichs- bzw. Anmerkungsabschnitten.
 
 Erzeugte Dateien: Inhalt von `<laufverzeichnis>\Ergebnisse\` auflisten. Zusätzlich prüfen,
-ob das Root unverändert blieb: `git -C <root> status --porcelain` gegen `before.txt`
+ob das Root unverändert blieb: `git -C <repo> status --porcelain -- <pfad-des-roots>` – mit
+**demselben Pfadfilter wie in Abschnitt 1** – gegen `before.txt`
 vergleichen (Nachher-Stand nach `$lauf\_metafter.txt`) – Abweichungen als Auffälligkeit
 ins Protokoll. Beim Vergleich Zeilenenden
 normalisieren (`before.txt` entsteht je nach Werkzeug mit CRLF, der Nachher-Stand mit LF),
@@ -545,10 +600,11 @@ Als `Protokoll.md` ins Laufverzeichnis, neben `RawResult.json` und `Stderr.log`.
 Vorlage:
 
 ```markdown
-# Messprotokoll – <Versuch> – Iteration <NN>
+# Messprotokoll – <Versuch> – Prompt-Version <NN>
 
 ## Lauf
 - **Prompt-Datei:** <relativer Pfad>
+- **Prompt-Version:** <Nummer aus dem Dateinamen; bei mehreren vorhandenen Fassungen begründen, warum diese gewählt wurde>
 - **SHA-256 (Prompt):** <hash>
 - **Startzeit:** <ISO 8601>
 - **Endzeit:** <ISO 8601>
@@ -568,7 +624,7 @@ Vorlage:
 - **Effort:** <low | medium | high | xhigh | max> (per `--effort` gesetzt; Gegenprobe im
   Transkript-Feld `effort`)
 - **Laufverzeichnis-ID:** `v<skillversion>-<id4>` aus dem Verzeichnisnamen
-- **Ablage:** `<ModellID>/<Agentenmodus>/<Effort>/`
+- **Ablage:** `<Iteration>/<ModellID>/<Agentenmodus>/<Effort>/`
 - **Parallele Läufe:** <nein | ja: welche Laufverzeichnisse liefen zeitgleich>
 - **Agentenmodus:** <solo (V1) | builtin (V1b) | custom (V2)>; bei `custom` zusätzlich
   Pfad und SHA-256 der Agentendefinitionen
@@ -750,6 +806,12 @@ der Historie unten – im selben Arbeitsschritt.
 | **3.9.0** | **Pflichtabschnitt „Gefundene Anforderungen" im Protokoll.** Neues Skript `analyse-anforderungen.py` wertet die erzeugten Anforderungen aus: Verteilung, Typen, Belegqualität (`PRIMÄR`/`SEKUNDÄR`/`KONTEXT`), Status, Konsolidierungskandidaten und **Regelkonformität gegen die Vorgaben des Prompts**. | Die Protokolle maßen bis dahin nur den Aufwand, nicht den Ertrag. Die reine Anforderungsanzahl taugt nicht als Qualitätsmaß (Streuung Faktor 5,9 bei gleicher Bedingung); Belegdichte und Regelverstöße sind inhaltliche Größen. Erste Anwendung deckte sofort Verstöße gegen die risikobasierte Priorisierung auf. | rückwirkend auf alle 24 Protokolle angewandt |
 | **3.10.0** | **Bedingungen als Ordnerstruktur statt im Dateinamen.** Ablage unter `<ModellID>\<Agentenmodus>\<Effort>\`; der Verzeichnisname lautet wieder `<NN>_Lauf_<yyyy-MM-dd_HHmmss>_v<skillversion>-<id4>`. Neues Protokollfeld „Ablage". | Der Name wuchs mit jeder unabhängigen Variable und war mit fünf Bestandteilen kaum lesbar. Als Ordnerebenen sind die Bedingungen navigierbar, je Zelle unmittelbar abzählbar und um weitere Variablen erweiterbar, ohne bestehende Namen zu brechen. | rückwirkend auf alle 24 Läufe angewandt |
 | **4.0.0** | **Ausrichtung auf Kapitel 4 der Arbeit.** Skill zweigeteilt in `## Prozess` (werkzeugneutral) und `## Werkzeugadapter` (konkrete Aufrufe, derzeit nur Claude Code). Der Prompt trägt nur noch die Analyseanweisung; Werkzeugkontext und Ausgabeverzeichnis werden zur Laufzeit angehängt. Versuchszuordnung korrigiert: **V1 = `solo`, V1b = `builtin`**. Neue Protokollfelder: Kontextfenster, Sampling-Parameter, lokale Runtime-Angaben, Abschnitt Validierungsstichprobe. Abschnitt „Gefundene Anforderungen" den drei Qualitätsdimensionen zugeordnet. | Prompt und Skill waren über 24 Läufe organisch gewachsen und stellenweise nicht mehr deckungsgleich mit Kap. 4. Der Prompt enthielt Aussagen zur Werkzeugkonfiguration, die dort nicht hingehören und ihn an Claude Code banden; der Skill verankerte weder den Evaluationsrahmen noch die von Kap. 4.3 geforderten Reproduzierbarkeitsangaben. MAJOR, weil sich die Zuordnung der Versuchsbedingungen ändert. | ab sofort |
+| **4.1.0** | **Ebene `<Versuchstag>` über den Bedingungen**: `Tag 1`, `Tag 2`, …; Schritt 8 ermittelt den höchsten vorhandenen Tag. Protokollfeld „Ablage" entsprechend erweitert. | Der Versuchsaufbau änderte sich am ersten Tag über 17 Skill-Versionen hinweg. Die Tagesebene hält Blöcke auseinander, die unter unterschiedlichem Stand entstanden sind, und macht sichtbar, welche Läufe überhaupt unter vergleichbaren Rahmenbedingungen liefen. | rückwirkend: alle 24 Läufe nach `Tag 1` verschoben |
+| **4.5.0** | `extract-subagenten.py` trennt am Nebenläufigkeitslimit **abgewiesene** Aufrufe von echten Subagenten-Starts und weist sie getrennt aus. | Der erste Lauf mit mehr als 20 gleichzeitigen Subagenten (`Iteration 3/…/125032_v4.4.0-fb24`, 31 gestartet, `refused.concurrency_limit` = 29) meldete eine Abweichung von 21 gefundenen gegenüber 13 erwarteten Aufrufen. Ursache waren 8 Absagen im Haupttranskript, die wie Starts aussehen, aber nur „Concurrent subagent limit reached" zurückliefern und nicht in `spawned` zählen. Ohne die Trennung wäre jeder stark parallelisierende Lauf mit einer Scheinwarnung versehen. MINOR: neue Messgröße, keine Änderung der Versuchsbedingung. | ab sofort; die drei `builtin`-Läufe der Iteration 3 wurden neu extrahiert und stimmen exakt überein |
+| **4.4.0** | Zwei Umbenennungen zur Auflösung einer Begriffskollision. **(a)** Ordnerebene `<Versuchstag>` → `<Iteration>` (`Tag N` → `Iteration N`), mit ausformuliertem Kriterium: Eine neue Iteration eröffnet, was Läufe nicht mehr poolbar macht – Codebasis-Snapshot, Prompt-Version, Werkzeugkonfiguration oder eine MAJOR-Version dieses Skills. **(b)** Die Fassung der Prompt-Datei heißt nicht mehr „Iteration", sondern **Prompt-Version**; Protokollfeld entsprechend umbenannt. | „Tag" band die Ebene an das Kalenderdatum, obwohl sie die Vergleichbarkeit abbildet: Am 26.08. entstanden zwei nicht poolbare Blöcke am selben Tag – ohne und mit dem DB-Schema-Dump `SSMS_DB_SCHEMA.sql` (Commit `f349d189`). Die Umbenennung in „Iteration" kollidierte dann mit der Prompt-Iteration: Iteration 2 und Iteration 3 laufen beide unter derselben Prompt-Fassung. Erst die zweite Umbenennung macht beide Begriffe eindeutig. MINOR: reine Benennung, keine Änderung der Versuchsbedingung. | rückwirkend: `Tag 1` → `Iteration 1` (24 Läufe), `Tag 2` → `Iteration 2` (5 Läufe); die fünf Läufe mit DB-Schema nach `Iteration 3`. Die Prompt-Dateien selbst bleiben unverändert – ihre SHA-256 sind in 33 Protokollen dokumentiert. |
+| **4.3.0** | `analyse-anforderungen.py` bestimmt die Ebene einer Anforderung aus dem Feld `Ebene:` beziehungsweise dem ID-Präfix statt aus dem Dateinamen und weist Fremdablage als eigene Auffälligkeit aus. | Das Skript zählte die Ebene nach der Datei, in der ein Block stand. Im Lauf `Iteration 2/…/094250_v4.2.1-c69e` lagen 12 StRS- und 5 SyRS-Blöcke in `SwRS.md`; die Verteilungstabelle meldete daraufhin 9/10/141 statt der tatsächlichen 21/15/124. Die Gesamtzahl war korrekt, die Verteilung – Kenngröße der Set-Qualität nach Kap. 4.3 – nicht. Gegenprobe an einem sauber abgelegten Lauf (`084301_v4.2.0-d6f9`): unverändert 20/120/30. MINOR, weil eine Messgröße korrigiert und eine neue Auffälligkeit ergänzt wird, ohne die Versuchsbedingung zu ändern. | ab sofort; die 24 Protokolle von Iteration 1 wurden geprüft: keine Fremdablage |
+| **4.2.1** | Vorher/Nachher-Prüfung des Roots wird **pfadskopiert** ausgeführt: `git -C <repo> status --porcelain -- <pfad-des-roots>` statt `git -C <root> status --porcelain` (Schritte 7, 9 und Abschnitt 4). | Seit Commit `f045b99a` liegt die Codebasis als Dateien im Arbeitsrepo statt als Gitlink. Die unskopierte Abfrage lieferte damit den Status des gesamten Arbeitsrepos – beim Lauf `Iteration 2/…/084301_v4.2.0-d6f9` rund 55 KB Ausgabe, praktisch nur Versuchsdateien. Ohne Pfadfilter hätte die Read-only-Verifikation ab sofort bei **jedem** Lauf eine Abweichung gemeldet, die es nicht gibt. PATCH: keine Änderung der Versuchsbedingung, nur eine korrigierte Messung. | ab Lauf `084301_v4.2.0-d6f9` (dort bereits so ausgeführt und im Protokoll vermerkt) |
+| **4.2.0** | **Auswahlregel bei mehreren Prompt-Versionen**: ohne ausdrückliche Angabe gilt die höchste Prompt-Versionsnummer; neues Protokollfeld „Prompt-Version". Ältere Fassungen bleiben unverändert. | Mit `02_Prompt.md` liegt erstmals mehr als eine Fassung im Versuchsordner. Ohne Regel wäre unklar, welche gilt, und der SHA-256 im Protokoll ließe sich keiner Datei mehr zuordnen. Bei der Einführung fiel auf, dass `01_Prompt.md` nachträglich verändert worden war – der in 24 Protokollen dokumentierte Hash zeigte auf eine Fassung, die es nicht mehr gab. | ab Prompt-Version 02 |
 
 ## Parallele Läufe
 
@@ -801,4 +863,4 @@ messbar wird.
 
 **Bisherige Läufe.** Die 24 Läufe in `Versuche/Versuch_01/` verteilen sich auf V1 (`solo`) und
 V1b (`builtin`). Die Ordnerstruktur macht die Zuordnung unmittelbar sichtbar; die Zellen sind
-über `ls <ModellID>/<Modus>/<Effort> | wc -l` abzählbar.
+über `ls "<Iteration>/<ModellID>/<Modus>/<Effort>" | wc -l` abzählbar. Alle 24 liegen unter `Iteration 1`.