iteration 8

Versuche/AblaufProtokoll.md

@@ -630,8 +630,11 @@ nicht vollständig vorab spezifizieren; er entsteht in der Auseinandersetzung mi
 
 ## 5. Durchgeführte Läufe
 
-24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl (Nr. 2,
-API-Transportfehler).
+**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 |
 |---:|---|---|---|---|---:|---:|---:|---:|---:|
@@ -660,10 +663,128 @@ API-Transportfehler).
 | 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).
+
+**Lauf 35 (Kimi solo):** 44 Turns, 3,2 Mio Tokens, aber nur 1 Ergebnisdatei (Analysebericht.md). Die Schreib-Erinnerung wurde nicht ausgelöst, weil das Modell früh einmal `write_file` aufrief (`write_file_count == 0` war nie erfüllt). Kimi schrieb den Analysebericht, dann nie wieder — möglicherweise durch max_turns begrenzt.
+
+**Lauf 36 (Kimi builtin):** Wurde durch Stromausfall abgebrochen. 6 Subagenten gestartet, 0 Ergebnisdateien. Keine Auswertung möglich.
+
+**Wiederholungsläufe (nach Adapter-Verbesserung):** Die Schreib-Erinnerung wurde erweitert: sie löst jetzt auch bei `write_file_count < 3` nach ⅔ der Turns aus.
+
+| # | Zeit | Modell | Modus | Effort | Subagenten | Turns | Tokens | Anforderungen | Status |
+|---:|---|---|---|---|---:|---:|---:|---:|---|
+| 37 | 16:10 | **kimi-k3** | solo | high | 0 | 27 | 1.473.405 | 0 | ⚠️ nur StRS.md |
+| 38 | 17:24 | **kimi-k3** | builtin | high | 10 (Limit) | — | — | 0 | ❌ **abgebrochen** (API-Timeout) |
+
+**Lauf 37 (Kimi solo, Wiederholung):** 27 Turns, 1,47 Mio Tokens, aber nur 1 Ergebnisdatei (StRS.md). Das Modell schreibt eine Datei und beendet sich dann mit `finish_reason: stop` — die Schreib-Erinnerung kann nicht greifen, weil das Modell vor Turn 67 (Schwelle für erste Erinnerung) stoppt. Dies ist ein Kimi-K3-spezifisches Verhaltensmuster: das Modell beendet den Lauf nach einer Teilleistung.
+
+**Lauf 38 (Kimi builtin, Wiederholung):** Subagent-Limit erreicht (10/10), danach 4 weitere `spawn_subagent`-Aufrufe verweigert. Aber das Modell schrieb keine Ergebnisdateien — es blockierte nach den Verweigerungen auf einem API-Aufruf (CPU eingefroren bei 465s für 25+ Min). Nach ~100 Min manuell abgebrochen.
+
+**Erkenntnis aus Iteration 8 (endgültig):**
+- **Das Subagent-Limit (10) funktioniert für GLM 5.2** zuverlässig: nach Erreichen des Limits schreibt GLM Ergebnisdateien (132 Anforderungen in Lauf 34).
+- **Kimi K3 hat ein anderes Problem als GLM:** Das Subagent-Limit wird korrekt durchgesetzt (10/10, 4 Verweigerungen), aber Kimi K3 kann nicht zur Schreibphase übergehen — es blockiert nach den Verweigerungen.
+- **Kimi K3 solo** beendet sich nach 1 Ergebnisdatei mit `finish_reason: stop` — die Schreib-Erinnerung kann nicht greifen, weil das Modell vor der Turn-Schwelle stoppt.
+- **Modell-spezifische Unterschiede:** GLM 5.2 ist im builtin-Modus produktiv (mit Limit), Kimi K3 ist es nicht — weder solo (frühzeitiger Abbruch) noch builtin (kein Übergang zur Schreibphase).
+- Die TensorX-Matrix hat jetzt 2 von 4 Zellen gültig gefüllt: GLM solo (70 Anf.) und GLM builtin (132 Anf.). Kimi solo und Kimi builtin bleiben problematisch.
+
+
 ---
 
 ## 6. Befunde
@@ -894,7 +1015,7 @@ Stichprobe.
 - 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)
+- Prozessvorgabe: `.claude/skills/run-experiment/SKILL.md` (Version 8.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`