Add TensorX models for Versuch 2

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

@@ -1,8 +1,8 @@
 ---
 name: run-experiment
-description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code, Codex CLI oder dem Python-API-Adapter (GLM/Kimi) aus 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.
+description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code, Codex CLI oder dem Python-API-Adapter (GLM/Qwen/Kimi) aus 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: 8.0.0
+version: 9.3.0
 ---
 
 # RunExperiment – Versuchslauf mit Messprotokoll
@@ -101,7 +101,7 @@ Der Skill ist zweigeteilt:
 - **`## Prozess`** beschreibt werkzeugneutral, **was** je Lauf zu tun und zu erheben ist. Dieser
   Teil gilt unabhängig davon, mit welchem LLM oder welcher CLI gearbeitet wird.
 - **`## Werkzeugadapter`** beschreibt **wie** das mit einem konkreten Werkzeug umgesetzt wird.
-  Ausgearbeitet sind Adapter für Claude Code, Codex CLI und den Python-API-Adapter (GLM/Kimi). Konkrete Flags und Rohfelder sind
+  Ausgearbeitet sind Adapter für Claude Code, Codex CLI und den Python-API-Adapter (GLM/Qwen/Kimi). Konkrete Flags und Rohfelder sind
   ausschließlich dem gewählten Adapterabschnitt zu entnehmen.
 
 **Arbeitsteilung mit der Prompt-Datei:** Der Prompt enthält ausschließlich die *Analyseanweisung*
@@ -125,7 +125,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
 2. Aus dem Metadaten-Block der Prompt-Datei (falls vorhanden) Versuch/Prompt-Version übernehmen.
 3. **Werkzeugadapter bestimmen und CLI-Pfad auflösen.** Die Modell-ID entscheidet eindeutig:
    `claude-*` verwendet Claude Code, OpenAI-IDs wie `gpt-*` oder `o*` verwenden Codex CLI,
-   `z-ai/*` und `moonshotai/*` verwenden den Python-API-Adapter über den TensorX-Gateway.
+   `z-ai/*`, `qwen/*` und `moonshotai/*` verwenden den Python-API-Adapter über den TensorX-Gateway.
    Keine Modell-ID an eine CLI übergeben, die sie nicht unterstützt.
 
    Unter Windows liegt `claude` in der Regel **nicht im PATH**. Erst
@@ -166,6 +166,8 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
    | TensorX-Modell-ID | Einordnung |
    |---|---|
    | `z-ai/glm-5.2` | Z.AI GLM 5.2 über TensorX-Gateway |
+   | `z-ai/glm-5.3-flash` | Z.AI GLM 5.3 Flash über TensorX-Gateway |
+   | `qwen/qwen3.8-flash-next` | Qwen 3.8 Flash Next über TensorX-Gateway |
    | `moonshotai/kimi-k3` | Moonshot Kimi K3 – 1-Mio.-Kontext, 2,8T Parameter |
 
    In der Frage den letzten verwendeten Stand nennen, damit der User bewusst wechseln oder
@@ -223,6 +225,30 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
    unangetastet und die Agentenkonfiguration ist eine dokumentierte, versionierte
    Versuchsbedingung. Format siehe `claude --help` zu `--agents`.
 
+   **Delegationstiefe – nur Modus `custom`, beim User erfragen.** Zwei Fassungen der
+   Agentendatei stehen bereit; sie unterscheiden sich ausschließlich darin, ob die Rollen selbst
+   delegieren dürfen:
+
+   | Fassung | Rollen dürfen delegieren | Wirkung |
+   |---|---|---|
+   | `verschachtelt` | ja | Rollen erben über `--agents` alle Werkzeuge einschließlich `Task` und starten eigene Subagenten. `max_depth` > 1. |
+   | `unverschachtelt` | nein | Jede Rolle führt ihren Auftrag selbst aus. Nur der Hauptagent delegiert; `max_depth` soll 1 sein. |
+
+   **Warum das eine eigene Option ist.** Im ersten V2-Lauf (`v9.1.0-0c39`) entfielen 26 von
+   86 Subagenten auf Starts durch Subagenten, `max_depth` = 3. Das war nicht beabsichtigt – der
+   `iso29148-orchestrator` ist ausdrücklich als nicht-delegierende Rolle entworfen – und es
+   verteuert den Lauf erheblich, weil jede zusätzliche Ebene ihren Kontext erneut liest. Es
+   verwischt außerdem die Zuständigkeit: Ein von einer Rolle gestarteter Subagent ist keiner
+   Teilaufgabe der Bindungstabelle mehr zuzuordnen.
+
+   Die Fassung ist **nicht** technisch erzwungen, sondern in jedem Rollenprompt als Abschnitt
+   *Keine Weiterdelegation* formuliert. Kontrolle nach dem Lauf: `subagent_stats.max_depth` und
+   `spawned_by_subagents`. Beide gehen ins Protokoll; bei `unverschachtelt` und
+   `spawned_by_subagents` > 0 ist die Bedingung verletzt und im Protokoll zu kennzeichnen.
+
+   Beide Fassungen liegen neben der Prompt-Datei und werden per SHA-256 geführt; die gewählte
+   Fassung ist über ihren Hash eindeutig belegt.
+
    **Codex-Adapter ab Version 5.0.0:** ausschließlich `solo` ist freigegeben und wird doppelt
    mit `--disable multi_agent` sowie `-c agents.enabled=false` erzwungen. Bei `builtin` oder
    `custom` abbrechen und mitteilen, dass dieser Adaptermodus noch nicht verifiziert ist. Eine
@@ -262,7 +288,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
              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 = 'v8.0.0'   # entspricht version: im Frontmatter dieses Skills
+   $skillVer = 'v9.3.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"
@@ -344,6 +370,50 @@ Der Inhalt richtet sich nach dem Agentenmodus:
 | `builtin` | zusätzlich die werkzeugeigenen Subagenten | spezialisierte Agentenrollen aus Konfigurationsdateien, externe Werkzeugserver |
 | `custom` | zusätzlich die beigestellten Agentenrollen (namentlich nennen) | externe Werkzeugserver, sofern nicht Teil des Versuchs |
 
+**Zuständigkeitsbindung – nur Modus `custom`.** Der Prompt verlangt im Abschnitt
+*Arbeitsteilung*, dass eine Teilaufgabe von dem dafür vorgesehenen Bearbeiter ausgeführt wird,
+nennt aber bewusst keine Rolle – sonst wäre er nicht mehr für `solo` und `builtin` gültig. Welche
+Rolle wofür zuständig ist, gehört deshalb in den Werkzeugkontext. Block 1 wird bei `custom` um
+folgende Tabelle ergänzt, mit den Rollennamen aus der `--agents`-Datei:
+
+```
+Für die folgenden Teilaufgaben stehen vorgesehene Bearbeiter bereit. Führe diese
+Teilaufgaben durch den jeweils genannten Bearbeiter aus, nicht selbst:
+
+| Teilaufgabe | Vorgesehener Bearbeiter |
+|---|---|
+| Modulinventar (Schritt 0) | modulinventar |
+| Faktenerhebung zu einem Modulausschnitt (Schritte 2 bis 4) | faktenermittler |
+| Formulierung der StRS-Anforderungen | strs-autor |
+| Formulierung der SyRS-Anforderungen | syrs-autor |
+| Formulierung der SwRS-Anforderungen samt Konsolidierungsprüfung | swrs-autor |
+| Prüfung ausgewiesener Belege gegen die Codebasis | belegpruefer |
+| Prüfung des Gesamtbestands an den Nahtstellen der Ausschnitte | iso29148-orchestrator |
+| Konsistenzcheck des fertigen Anforderungssatzes (Abschnitt Abschluss) | konsistenzpruefer |
+
+Zuschnitt, Anzahl der Aufträge je Bearbeiter, deren Reihenfolge und die Tiefe
+entscheidest du. Gebunden ist allein, wer eine Teilaufgabe ausführt. Die Bearbeiter
+lesen nur; das Anlegen der Ergebnisdateien und die Übernahme ihrer Rückmeldungen
+bleiben deine Aufgabe.
+```
+
+Die Tabelle wird aus der `--agents`-Datei abgeleitet und **nicht** freihändig formuliert: Jede
+Zeile nennt eine Rolle, die dort definiert ist, und jede definierte Rolle kommt vor. Kommt eine
+Rolle in der Datei vor, aber nicht in der Tabelle, ist sie im Lauf faktisch nicht vorgesehen –
+das ist zulässig, aber im Protokoll zu vermerken.
+
+**Warum die Bindung keine Strategieinjektion ist.** Sie ist vor dem Lauf statisch deklariert,
+wird als Teil von `_meta\combined_prompt.md` archiviert und ist über den SHA-256 der
+`--agents`-Datei versioniert. Damit unterscheidet sie sich grundlegend von den in Version 9.0.0
+entfernten **laufzeitabhängigen** Eingriffen des TensorX-Adapters (Subagenten-Limit,
+turnabhängige Schreib-Erinnerungen), die den Lauf abhängig von seinem eigenen Verlauf umsteuerten
+und Lauf 34 unpoolbar machten. Was in `custom` weiterhin **nicht** vorgegeben wird: Anzahl der
+Aufrufe, Zerlegungstiefe, Reihenfolge und Turn-Anzahl.
+
+**Die Bindung ist nicht technisch erzwungen.** Sie wirkt über den Prompt; ob der Agent sie
+einhält, ist selbst eine Messgröße. Nach dem Lauf ist sie zu prüfen – siehe Protokollfeld
+*Zuständigkeitsbindung*.
+
 **Block 2 – Ausgabeverzeichnis.** Damit die Ergebnisse im Laufverzeichnis landen und nicht in
 der Codebasis:
 
@@ -772,6 +842,15 @@ Vorlage:
 - **MCP-Server / Agentendateien:** <keine – aus dem Snapshot entfernt, zusätzlich --safe-mode |
   Liste der Server mit Pfad und SHA-256 der `--mcp-config`-Datei; Pfad und SHA-256 der
   `--agents`-Datei>
+- **Delegationstiefe (nur `custom`):** <verschachtelt | unverschachtelt> gemäß gewählter
+  Agentendatei. Kontrolle: `subagent_stats.max_depth` und `spawned_by_subagents`. Bei
+  `unverschachtelt` muss `spawned_by_subagents` = 0 und `max_depth` = 1 sein; andernfalls hat
+  die Rollenvorgabe nicht gegriffen und der Lauf ist entsprechend zu kennzeichnen.
+- **Zuständigkeitsbindung (nur `custom`):** je Rolle die Zahl der Aufrufe aus
+  `subagent_stats.by_type`; Rollen mit null Aufrufen namentlich nennen. Dazu der Abgleich mit
+  der Dokumentationspflicht aus dem `Analysebericht.md`: Welche Teilaufgabe hat der Hauptagent
+  entgegen der Bindung selbst ausgeführt, und hat er das dort offengelegt? Eine nicht
+  offengelegte Abweichung ist im Protokoll als solche zu kennzeichnen.
 - **Umgebungsprüfung (nur `custom` / MCP):** <keine Hooks, Plugins, Output-Styles im
   User-Profil vorgefunden | **abweichend**: welche>
 - **Subagenten:** <Anzahl und Typ aus `subagent_stats`, z. B. 8 × Explore, 0 fehlgeschlagen>
@@ -1003,7 +1082,7 @@ die angeforderte ID; da `codex exec --json` sie im Ereignisstrom nicht wiederhol
 Modellkontrolle im Protokoll `nicht prüfbar`. Temperatur und weitere Sampling-Parameter sind in
 diesem CLI-Ablauf nicht steuerbar; Effort und Service-Tier werden dagegen explizit festgelegt.
 
-### Adapter: Python API / GLM & Kimi-Modelle über TensorX
+### Adapter: Python API / GLM-, Qwen- und Kimi-Modelle über TensorX
 
 Dieser Adapter wurde für Modelle entwickelt, die über den **TensorX API-Gateway**
 (`https://api.tensorx.ai/v1`) erreichbar sind. Er nutzt das Skript `glm-kimi-adapter.py`,
@@ -1015,9 +1094,11 @@ REST-API implementiert. Referenzstand bei Einführung: **Python 3.13, requests 2
 | TensorX-Modell-ID | Hersteller | Effort-Parameter |
 |---|---|---|
 | `z-ai/glm-5.2` | Z.AI (Zhipu AI) | `thinking` (`{"type":"enabled","level":"…"}`) |
+| `z-ai/glm-5.3-flash` | Z.AI (Zhipu AI) | `thinking` (`{"type":"enabled","level":"…"}`) |
+| `qwen/qwen3.8-flash-next` | Alibaba Qwen | `thinking` (`{"type":"enabled","level":"…"}`) |
 | `moonshotai/kimi-k3` | Moonshot AI | `reasoning_effort` (top-level) |
 
-Das Modell-Präfix (`z-ai/` bzw. `moonshotai/`) bestimmt, welcher Effort-Parameter an die
+Das Modell-Präfix (`z-ai/`, `qwen/` bzw. `moonshotai/`) bestimmt, welcher Effort-Parameter an die
 API gesendet wird. Der Adapter wählt ihn automatisch anhand des Präfixes.
 
 **Authentifizierung.** Der API-Key wird **automatisch aus der Cline providers.json**
@@ -1025,13 +1106,29 @@ gelesen (`~/.cline/data/settings/providers.json`, Provider `tensorx`). Alternati
 er per `--api-key` oder Umgebungsvariable `TENSORX_API_KEY` übergeben werden. Der Key
 wird **nicht** in Laufartefakten gespeichert.
 
-**Unterstützter Agentenmodus:** `solo` (V1) und `builtin` (V1b). Der Modus wird per
-`--mode solo|builtin` gesteuert. Im Modus `solo` steht das `spawn_subagent`-Tool nicht
+**Unterstützte Agentenmodi:** `solo` (V1), `builtin` (V1b) und `custom` (V2). Der Modus wird per
+`--mode solo|builtin|custom` gesteuert. Im Modus `solo` steht das `spawn_subagent`-Tool nicht
 zur Verfügung. Im Modus `builtin` kann der Hauptagent Subagenten mit eigenem Kontext
 starten (`spawn_subagent`-Tool) – diese erhalten Read-Only-Tools (kein `write_file`) und
-eine eigene, vom Hauptagenten unabhängige Konversation. Der Subagent-Typ (`explore` oder
-`general-purpose`) bestimmt den System-Prompt. Subagent-Token fließen vollständig in
-`usage` und `modelUsage` ein. `custom` ist nicht freigegeben und führt zum Abbruch.
+eine eigene, vom Hauptagenten unabhängige Konversation. Anzahl und Typen bestimmt allein
+das Modell; der Adapter setzt weder ein Anzahl- noch standardmäßig ein Turn-Limit. Fordert
+das Modell in einer Antwort mehrere Subagenten an, laufen sie tatsächlich parallel. Der
+Subagent-Typ (`explore` oder `general-purpose`) bestimmt den System-Prompt. Subagent-Token
+fließen vollständig in `usage` und `modelUsage` ein. Im Modus `custom` werden die Rollen mit
+`--agents <JSON-Datei>` geladen und über dasselbe `spawn_subagent`-Werkzeug bereitgestellt.
+
+**Lebenszeichen.** Der Adapter schreibt standardmäßig alle 60 Sekunden eine
+`LIFESIGN`-Zeile nach `Stderr.log`. Sie nennt die aktiven Operationen des Hauptagenten und
+jedes Subagenten, beispielsweise einen API-Turn, einen Tool-Aufruf oder das Warten auf eine
+parallele Subagentengruppe. Das Intervall ist mit `--heartbeat-interval` steuerbar. Ein
+Lebenszeichen während eines nicht gestreamten HTTP-Aufrufs beweist nur, dass der lokale
+Adapterprozess lebt und auf TensorX wartet; es ist kein Nachweis, dass serverseitig weiterhin
+Tokens erzeugt werden.
+
+**Keine impliziten Abbrüche.** `--timeout 0`, `--max-turns 0` und
+`--subagent-max-turns 0` bedeuten tatsächlich unbegrenzt. Der Adapter injiziert keine
+laufzeit- oder limitbedingten Schreibaufforderungen. Damit bleibt es Teil der Messung, ob,
+wie und mit wie vielen Subagenten ein Modell zum Abschluss kommt.
 
 **Isolation.** Der Adapter ist ein eigenständiges Python-Skript, das nur die
 Python-Standardbibliothek und `requests` benötigt. Es liest die Codebasis über die
@@ -1043,13 +1140,13 @@ zusätzliche Pflicht.
 
 **Effort-Steuerung.** Der Adapter mappt die Skill-Effort-Stufen auf beide APIs:
 
-| Skill-Effort | GLM `thinking.level` | Kimi `reasoning_effort` |
-|---|---|---|
-| `low` | `low` | `low` |
-| `medium` | `medium` | `medium` |
-| `high` | `high` | `high` |
-| `xhigh` | `xhigh` | `high` (höchste verfügbare Stufe) |
-| `max` | `xhigh` | `high` |
+| Skill-Effort | GLM `thinking.level` | Qwen `thinking.level` | Kimi `reasoning_effort` |
+|---|---|---|---|
+| `low` | `low` | `low` | `low` |
+| `medium` | `medium` | `medium` | `medium` |
+| `high` | `high` | `high` | `high` |
+| `xhigh` | `xhigh` | `xhigh` | `high` (höchste verfügbare Stufe) |
+| `max` | `xhigh` | `xhigh` | `high` |
 
 **Der Aufruf** (als Background-Task starten):
 
@@ -1059,6 +1156,8 @@ $lauf     = "<absoluter Pfad zum Laufverzeichnis>"
 $root     = "<Root-Verzeichnis der Codebasis>"
 $modell   = "<vom User gewählte Modell-ID, z.B. z-ai/glm-5.2>"
 $effort   = "<vom User gewählte Stufe>"
+$modus    = "<solo|builtin|custom>"
+$agents   = "<Agenten-JSON; im Modus custom erforderlich>"
 
 # Prompt zusammenstellen (wie bei den anderen Adaptern)
 $prompt = (Get-Content "<prompt-datei>" -Raw) + "`n`n<Werkzeugkontext-Block>`n`n<Ausgabe-Block>"
@@ -1073,7 +1172,11 @@ python "$skillDir\glm-kimi-adapter.py" `
   --model    $modell `
   --effort   $effort `
   --mode     $modus `
-  --max-turns 80 `
+  --agents   $agents `
+  --max-turns 0 `
+  --subagent-max-turns 0 `
+  --timeout 0 `
+  --heartbeat-interval 60 `
   --result-dir $lauf `
   2> "$lauf\Stderr.log"
 
@@ -1095,10 +1198,11 @@ Set-Content -Path "$lauf\_meta\endzeit.txt" -Value (Get-Date -Format o)
 | Agent-Turns | `num_turns` |
 | Tatsächlich eingesetztes Modell | `model` (aus API-Antwort; mit `model_requested` abzugleichen) |
 | Tool-Aufrufe | `tool_call_count`, `tool_call_types` (nach Werkzeugname) |
-| Subagenten | `subagent_stats` (`spawned`, `completed`, `failed`, `by_type`) – nur im Modus `builtin` |
+| Subagenten | `subagent_stats` (`spawned`, `completed`, `failed`, `by_type`) – nur in den Modi `builtin` und `custom` |
 | Subagenten-Details | `subagent_details` (je Subagent: Typ, Beschreibung, Turns, Tokens, Status) |
 | Erzeugte Artefakte | `written_files` (Pfad und Größe je Datei) |
 | Abschlusstext | `result` |
+| Lebenszeichen | periodische `LIFESIGN`-Zeilen in `Stderr.log` |
 
 **Semantik der Token-Zählung.** `usage.total_tokens` wird über alle Turns aufsummiert.
 Jeder Turn umfasst dabei den vollen Kontext (Eingabe + Ausgabe); die Token-Zahl ist
@@ -1179,6 +1283,10 @@ der Historie unten – im selben Arbeitsschritt.
 
 | Version | Änderung | Grund | Verwendet in |
 |---|---|---|---|
+| **9.3.0** | **TensorX-Modellkatalog für Versuch 2 erweitert:** `qwen/qwen3.8-flash-next` und `z-ai/glm-5.3-flash`; Qwen erhält explizit das `thinking.level`-Effort-Mapping. Der TensorX-Aufruf dokumentiert nun `--agents`. Im Adapter stellt `custom` wie `builtin` das Werkzeug `spawn_subagent` bereit; Adapter-Version 2.1.0. | Beide IDs wurden am 31.08.2026 über `GET /v1/models` des konfigurierten TensorX-Gateways bestätigt. Ein Qwen-Smoke-Test bestätigte `thinking`, Reasoning-Tokens und Tool-Calling. Bei der Konfigurationsprüfung fiel außerdem auf, dass `custom` trotz geladener Rollen das Delegationswerkzeug ausblendete und der dokumentierte Aufruf die Agentendatei nicht übergab; damit wäre Versuch 2 über TensorX ohne spezialisierte Rollen gelaufen. MINOR für die Modellauswahl, funktionale Korrektur für V2. | ab dem ersten TensorX-Lauf in Versuch 2 |
+| **9.2.0** | **Delegationstiefe als Option im Modus `custom`.** Zwei gehashte Fassungen der Agentendatei: `verschachtelt` (Rollen dürfen selbst delegieren, bisheriges Verhalten) und `unverschachtelt` (Abschnitt *Keine Weiterdelegation* in jedem Rollenprompt). Die Fassung wird wie Modell, Modus und Effort vor dem Lauf beim User erfragt. Neues Protokollfeld *Delegationstiefe* mit Kontrolle über `subagent_stats.max_depth` und `spawned_by_subagents`. | Im ersten V2-Lauf (`v9.1.0-0c39`) entfielen 26 von 86 Subagenten auf Starts durch Subagenten (`max_depth` = 3). Das war nicht beabsichtigt – der `iso29148-orchestrator` ist als nicht-delegierende Rolle entworfen – und ist ein erheblicher Kostentreiber: Jede zusätzliche Ebene liest ihren Kontext erneut, und Cache-Reads stellten 46 % der Laufkosten. Es verwischt zudem die Zuständigkeit, weil ein von einer Rolle gestarteter Subagent keiner Teilaufgabe der Bindungstabelle mehr zuzuordnen ist. MINOR: neue Option und neue Messgröße; die Bedingung bestehender Läufe ändert sich nicht, sie gelten rückwirkend als `verschachtelt`. | ab dem zweiten V2-Lauf |
+| **9.1.0** | **Zuständigkeitsbindung im Modus `custom`.** Block 1 (Werkzeugkontext) wird bei `custom` um eine Tabelle `Teilaufgabe → vorgesehener Bearbeiter` ergänzt, abgeleitet aus der `--agents`-Datei. Der Prompt formuliert die Bindung abstrakt und nennt weiterhin keine Rolle, damit dieselbe Prompt-Datei für `solo` und `builtin` gültig bleibt. Neues Protokollfeld *Zuständigkeitsbindung*: Aufrufe je Rolle aus `subagent_stats.by_type`, Rollen mit null Aufrufen namentlich, Abgleich gegen die Dokumentationspflicht im `Analysebericht.md`. | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Im Smoke-Test vom 26.08. nutzte der Agent von acht beigestellten Rollen nur zwei (`modulinventar`, `konsistenzpruefer`) — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist statisch deklariert, in `_meta\combined_prompt.md` archiviert und über den SHA-256 der `--agents`-Datei versioniert; sie unterscheidet sich damit von den in 9.0.0 entfernten laufzeitabhängigen Adaptereingriffen. Anzahl der Aufrufe, Zerlegungstiefe, Reihenfolge und Turn-Anzahl bleiben unvorgegeben. MINOR, weil bislang **kein** Lauf im Modus `custom` existiert und deshalb keine Läufe unpoolbar werden; der erste V2-Lauf eröffnet ohnehin eine neue Iteration. | ab dem ersten V2-Lauf |
+| **9.0.0** | **Freie und tatsächlich parallele Subagenten-Orchestrierung im Python-Adapter.** Das künstliche 10er-Limit, die limitbedingte Zwangsnachricht und die laufzeitabhängigen Schreib-Erinnerungen entfallen. Mehrere `spawn_subagent`-Aufrufe desselben Turns werden parallel ausgeführt; Haupt- und Subagenten haben standardmäßig kein Turnlimit. `--timeout 0` bedeutet nun wirklich keinen HTTP-Timeout. Ein threadsicherer Heartbeat protokolliert alle 60 Sekunden den lokalen Zustand von Haupt- und Subagenten. API-Fehler setzen unabhängig von vorhandenem Freitext `is_error: true`, werden nach `Stderr.log` geschrieben und führen zu Exitcode 1. | Das 10er-Limit und die serielle Abarbeitung veränderten gerade die zu untersuchende autonome Delegationsstrategie des Modells. Außerdem wurden fünf Kimi-Timeouts wegen fehlerhafter Statuslogik als Erfolg klassifiziert. MAJOR, weil Subagentenfreiheit, Parallelität und Abbruchsemantik die Versuchsbedingung ändern; der nächste Lauf eröffnet eine neue Iteration. | ab dem nächsten TensorX-Lauf |
 | **8.0.0** | **Neuer Python-API-Adapter für GLM- und Kimi-Modelle über den TensorX-Gateway.** Das Skript `glm-kimi-adapter.py` implementiert einen minimalen Agent-Loop mit Tool-Calling (read_file, list_directory, search_files, execute_command, write_file) direkt gegen die OpenAI-kompatible TensorX-API (`https://api.tensorx.ai/v1`). Modelle: `z-ai/glm-5.2` und `moonshotai/kimi-k3`. Der API-Key wird automatisch aus der Cline providers.json gelesen. Token-Verbrauch wird pro Turn aus dem API-Response `usage`-Objekt akkumuliert, inkl. Reasoning-Tokens (`completion_tokens_details.reasoning_tokens`). Effort-Mapping anhand des Modell-Präfixes: `z-ai/*` nutzt `thinking.level`, `moonshotai/*` nutzt `reasoning_effort`. Nur Modus `solo` freigegeben. Neue Modell-Tabelle für TensorX-Modell-IDs im Vorbereitungsabschnitt. | Die Cline CLI (`npm i -g cline`) versprach einen Headless-Modus mit GLM-Support, ihr natives Binary (143 MB, Bun-kompiliert) wurde jedoch durch die Application-Control-Richtlinie der Maschine blockiert (EPERM/Zugriff verweigert). Der Python-Adapter umgeht dieses Problem und bietet zusätzliche Vorteile: exakte Token-Metriken direkt aus der API (inkl. Reasoning-Tokens, die Claude Code nur als `thinking_tokens` liefert), keine externen Binary-Abhängigkeiten, API-Key aus bestehender Cline-Konfiguration. MAJOR, da neues Werkzeug mit anderer Isolationsarchitektur und anderen Metrik-Quellen eine neue Versuchsbedingung bildet; der nächste Lauf eröffnet eine neue Iteration. | ab dem ersten GLM/Kimi-Lauf |
 
 | **7.0.0** | **Isolationsmechanismus wird modusabhängig.** In den Modi `solo` und `builtin` unverändert `--safe-mode`; im Modus `custom` und bei jedem Lauf mit `--mcp-config` **kein** `--safe-mode`, stattdessen `--strict-mcp-config` plus `--disallowedTools Skill WebSearch WebFetch SlashCommand`. Neue Pflicht-Umgebungsprüfung auf Hooks, Plugins und Output-Styles im User-Profil; neue Protokollfelder für die MCP-Konfiguration und die Umgebungsprüfung. | `--safe-mode` schaltet ausweislich der CLI-Hilfe „MCP servers, custom commands and agents" ab – also genau das, was V2 und V3 untersuchen. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur `--safe-mode` variiert): mit Flag `spawned` = 0 und die Meldung, die Rollen seien „nicht in der Agent-Registry registriert"; ohne Flag `spawned` = 2 mit `{"modulinventar": 1, "konsistenzpruefer": 1}`. Ohne Ersatz hätte der erste V2-Lauf stillschweigend als V1-Lauf gemessen. Der Ersatz wurde gegengeprüft: nichts vorgeladen, keine Skills, kein Webzugriff, alle Rollen verfügbar. **MAJOR: Läufe im Modus `custom` sind hinsichtlich der Isolation nicht unmittelbar mit `solo`- und `builtin`-Läufen vergleichbar** – Plugins, Hooks und Output-Styles sind dort nicht durch das Flag, sondern nur durch die Umgebungsprüfung ausgeschlossen. | ab dem ersten V2-Lauf |