# Versuch 02 – Agentengestützt (V2)

Rollenspezialisierte Agentendateien statt eines einzelnen Threads. Agentenmodus des Skills:
`custom`; die Rollen werden per `--agents` übergeben.

## Dateien

| Datei | SHA-256 | Zweck |
|---|---|---|
| `02_Prompt.md` | `5946FC82…C76ECD` | **aktuell** – Analyseanweisung, Prompt-Version **03-A** |
| `03_Agents.json` | `424DDD83…644170` | **aktuell** – acht Agentenrollen, Delegationstiefe **`unverschachtelt`** (Abschnitt *Keine Weiterdelegation* je Rolle) |
| `02_Agents.json` | `4BF0AF8F…9781F1` | acht Agentenrollen, Delegationstiefe **`verschachtelt`** – Fassung des ersten V2-Laufs; weiterhin gültige Alternative, siehe Skill 9.2.0 |
| `01_Prompt.md` | `DCDC0E3F…B71BCF` | abgelöst – Prompt-Version 02-A, kein Lauf durchgeführt |
| `01_Agents.json` | `030B2142…21A9D9` | abgelöst, kein Lauf durchgeführt. Die README nannte hier bis zum 31.08. den Hash `6943EECD…AF1696`; er passte zu keinem Stand der Datei. |

## Stand 31.08.2026: Prompt-Version 03-A und Zuständigkeitsbindung

**Prompt-Version 03-A löst 02-A ab.** 02-A leitete sich von Prompt-Version **02** aus Versuch 1
ab. Versuch 1 ist seit Iteration 8 auf Prompt-Version **03** weitergelaufen. Ein V2-Lauf gegen
02-A hätte sich von den Vergleichsläufen in **zwei** Größen unterschieden – Agentenrollen *und*
Prompt-Version – und wäre als Wirkungsnachweis der Rollen unbrauchbar gewesen. 03-A setzt auf
Prompt-Version 03 auf; einzige Ergänzung bleibt der Abschnitt *Arbeitsteilung*.

**Die Rollennutzung ist gebunden.** Der Smoke-Test vom 26.08. nutzte von acht beigestellten Rollen
nur zwei. Bleibt die Nutzung freigestellt, wird die Versuchsbedingung nicht hergestellt: Der Lauf
führte die Rollen mit, ohne sie einzusetzen. Der Prompt verlangt deshalb, dass eine Teilaufgabe,
für die ein Bearbeiter vorgesehen ist, von ihm ausgeführt wird. Die konkrete Zuordnung
`Teilaufgabe → Rolle` steht im Block *Werkzeugkontext* des Skills (Version 9.1.0), nicht im
Prompt – so bleibt dieselbe Prompt-Datei für `solo` und `builtin` gültig und die Rollenbindung
die einzige unabhängige Variable.

Gebunden ist **wer** eine Teilaufgabe ausführt. Frei bleiben Zuschnitt, Anzahl der Aufträge je
Rolle, Reihenfolge, Tiefe und Turn-Anzahl – sie bleiben Untersuchungsgegenstand wie in V1b. Die
Bindung ist vor dem Lauf statisch deklariert, in `_meta\combined_prompt.md` archiviert und über
den SHA-256 der `--agents`-Datei versioniert; sie ist damit von den in Skill 9.0.0 entfernten
**laufzeitabhängigen** Adaptereingriffen zu unterscheiden, die Lauf 34 unpoolbar machten.

Da die Bindung auf Promptebene wirkt, ist ihre Einhaltung nicht erzwungen, sondern selbst eine
Messgröße: Das Protokollfeld *Zuständigkeitsbindung* führt die Aufrufe je Rolle aus
`subagent_stats.by_type`, nennt Rollen mit null Aufrufen und gleicht sie gegen die
Dokumentationspflicht im `Analysebericht.md` ab.

**Änderungen an den Rollen (02_Agents.json).** Namen und die gemessen begründeten Regeln sind
unverändert. Neu ist:

| Rolle | Änderung | Grund |
|---|---|---|
| `strs-autor`, `syrs-autor`, `swrs-autor` | schreiben keine Ergebnisdateien, Rückgabe als Text | Im TensorX-Adapter können Subagenten grundsätzlich nicht schreiben, in der Claude-CLI erben `--agents`-Rollen alle Werkzeuge. Dieselbe Rollendatei hätte je Adapter eine andere Bedingung ergeben; drei gleichzeitig schreibende Autoren brechen zudem die 7-Datei-Regel und die ID-Disziplin. |
| `iso29148-orchestrator` | prüft und liefert einen Übergabebericht mit ausführbaren Anweisungen, statt die Struktur selbst herzustellen | Die alte Fassung verlangte Herstellungsleistungen (Umnummerierung, Ergebnisstruktur) von einem Subagenten, der nicht schreiben kann – im Adapter unausführbar, in der CLI ein zweiter Schreiber neben dem Hauptagenten. |
| `konsistenzpruefer` | Prüfpunkte 9 bis 11: 7-Datei-Regel, Anteil `nicht analysiert` über 10 %, Einhaltung der Zuständigkeitsbindung | Die Rolle prüfte gegen Prompt-Version 02; die beiden Regeln kamen mit Version 03 hinzu. Punkt 11 macht die Bindung im Lauf selbst sichtbar. |
| `belegpruefer` | Umfang ist das Zugewiesene; geprüfte Zahl und Bezugsgröße sind zu nennen | Ohne Bezugsgröße ist die Zählung nicht einzuordnen. |
| alle | „Du legst keine Dateien an" | macht die Bedingung adapterunabhängig |

## Historisch: Prompt-Version 02-A

> Dieser Abschnitt beschreibt die abgelöste Fassung `01_Prompt.md`. Er bleibt stehen, weil die
> Begründung des Abschnitts *Arbeitsteilung* unverändert gilt; maßgeblich ist der Stand vom
> 31.08.2026 weiter oben.


Prompt-Version **02-A** entsteht aus `Versuche/Versuch_01/02_Prompt.md`
(`F9B2A1AA…0D7849`) durch **eine** Ergänzung: den Abschnitt **Arbeitsteilung**. Alles Übrige –
Auftrag, Scope, Vorgehensschritte 0 bis 6, Blockformat, Belegklassifikation, Prüfidee,
Tracelinks, Konsolidierungsbegriff, Ergebnisstruktur – ist unverändert.

**Warum die Ergänzung nötig ist.** Prompt-Version 02 unterstellt an mehreren Stellen
stillschweigend, dass *ein* Bearbeiter die gesamte Kette durchläuft: Sie ordnet Schritte zeitlich
(erst Inventar, dann Mindestabdeckung, dann Vertiefung), vergibt fortlaufende IDs und verlangt am
Ende einen Konsistenzcheck über das Ergebnis. Wird die Arbeit auf Rollen verteilt, ist nichts
davon mehr von selbst erfüllt: IDs kollidieren, die Reihenfolge läuft rollenweise auseinander,
und eine Prüfung des eigenen Beitrags ist keine Prüfung des Ganzen.

Der Abschnitt nennt **keine Rolle** und schreibt **keinen Zuschnitt** vor – welche Rollen es
gibt, stellt der Versuchsaufbau bei. Seine vier Kernsätze:

- ID-Bereiche vorab vergeben, überschneidungsfrei; zusammengeführt je Ebene lückenlos
- **Die Ebene ergibt sich aus dem Inhalt, nicht aus dem Bearbeiter** – fällt in einem Ausschnitt
  eine fremde Ebene an, wird sie dort geführt und über Tracelinks verbunden
- Die Mindestabdeckung ist erreicht, wenn **jedes Modul des gemeinsamen Inventars** eine
  Anforderung trägt – nicht, wenn jeder seinen Ausschnitt abgedeckt hat
- Der Konsistenzcheck gilt dem **zusammengeführten** Ergebnis, mit besonderem Blick auf die
  Ränder der Ausschnitte

Der Abschnitt gilt ausdrücklich nur bei verteilter Bearbeitung; bei einem einzelnen Bearbeiter
ist er wirkungslos. Damit bleibt der Prompt auch für einen `solo`-Lauf gültig und der fachliche
Auftrag über V1, V2 und V3 identisch.

## Die acht Rollen

| Rolle | Aufgabe | Schreibt Anforderungen? |
|---|---|---|
| `modulinventar` | Schritt 0: vollständiges Inventar samt Abdeckungsbuchführung | nein |
| `faktenermittler` | belegte Fakten samt durchsetzender Codestelle, je Modulausschnitt | nein |
| `strs-autor` | Stakeholder-Ebene | ja, nur StRS – als Rückgabetext, ohne Datei |
| `syrs-autor` | Systemebene | ja, nur SyRS – als Rückgabetext, ohne Datei |
| `swrs-autor` | Softwareebene, zusätzlich Konsolidierungsprüfung | ja, nur SwRS – als Rückgabetext, ohne Datei |
| `iso29148-orchestrator` | prüft den zusammengeführten Bestand und liefert den Übergabebericht | nein |
| `belegpruefer` | öffnet zitierte Stellen und prüft, ob `PRIMÄR` trägt | nein |
| `konsistenzpruefer` | vollständige Regelprüfung gegen die Promptvorgaben | nein |

Die vier von der Arbeit genannten Rollen – Stakeholder, System, Software und
ISO-29148-Orchestrator – sind damit besetzt; `modulinventar`, `faktenermittler`, `belegpruefer`
und `konsistenzpruefer` kommen aus den Messungen hinzu.

**Der Orchestrator delegiert nicht.** Er startet keine Subagenten und schreibt weder
Anforderungen noch Dateien. Er prüft, was sich erst am zusammengeführten Bestand feststellen
lässt – durchgängige Nummerierung samt mitzuziehender Verweise, beidseitig geschlossene
Traceability, Deckungsgleichheit der Hypothesenliste, Abdeckung über das gemeinsame Inventar –
und liefert die fehlenden Schritte als ausführbare Anweisungen zurück; ausgeführt werden sie vom
Hauptagenten. Ein delegierender Orchestrator erzeugte eine zweite Ebene, deren Subagenten-Prompts
nicht protokollierbar sind – in Versuch 1 blieben so 18 von 31 Aufrufen unerfassbar.

## Woraus die Rollen abgeleitet sind

Jede Regel in den Agentenprompts ist an einen gemessenen Befund aus den 17 Läufen von
Versuch 1 gekoppelt:

**Drei Autoren statt einem** – die Ebenenverteilung schwankte bei identischem Prompt von
92,7 % StRS bis 89,4 % SwRS. Ursache: Der Prompt verlangt in Schritt 0b je Modul eine
Anforderung, sagt aber nicht, auf welcher Ebene. Getrennte Autoren machen die Verteilung
strukturell statt emergent.

**Der `faktenermittler` ist aus den Läufen abgeschrieben.** Drei `builtin`-Läufe, gleiche
Bedingung, unterschiedliche Beauftragung der Subagenten:

| Lauf | Auftragsart | Anforderungen mit Primärbeleg |
|---|---|---:|
| `4048` | „concrete, citable FACTS only … find the EXACT enforcing location" | 97,8 % |
| `fb24` | „Research …" mit Faktenpflicht | 96,9 % |
| `f8b4` | „quickly inspect … open 1-3 representative files" | 46,4 % |

Nicht die Zahl der Subagenten entscheidet, sondern ob Tiefe oder Breite beauftragt wird. Das
Stichproben-Verbot im Prompt der Rolle folgt direkt daraus.

**Der `belegpruefer` ist neu.** Die Primärbelegquote schwankte über 17 Läufe zwischen 34,6 % und
100 %. Eine hohe Quote ist wertlos, wenn die Einstufung nicht trägt – geprüft wurde sie bis dahin
nie.

**Der `konsistenzpruefer` adressiert den am häufigsten verfehlten Prüfpunkt.** Die risikobasierte
Priorisierung scheiterte in 9 von 16 gültigen Läufen, im schlimmsten Fall bei 18 von 49
Anforderungen. In einem Lauf meldete der Agent „alle 36 gedeckt", während die maschinelle Prüfung
51 risikorelevante Anforderungen fand – er hatte gegen einen zu engen eigenen Risikobegriff
geprüft. Die Rolle muss ihren Risikobegriff deshalb offenlegen.

## Ausführung

Der Skill `run-experiment` übernimmt das im Modus `custom`. Ablage der Läufe:
`<Iteration>/<ModellID>/custom/<Effort>/`.

### TensorX-Modelle

Für TensorX-Läufe in Versuch 2 sind zusätzlich `qwen/qwen3.8-flash-next` und
`z-ai/glm-5.3-flash` konfiguriert. Beide IDs waren bei der Prüfung am 31.08.2026 im
`/v1/models`-Katalog des Gateways vorhanden. Der Python-Adapter lädt im Modus `custom` die
Agentendatei über `--agents` und stellt dem Hauptagenten `spawn_subagent` bereit; ohne diese
beiden Teile wäre die Agentenbedingung von Versuch 2 nicht hergestellt.

Der kleine Qwen-Kompatibilitätstest bestätigte Tool-Calling, `thinking` und Reasoning-Tokens.
Der entsprechende GLM-Test lieferte innerhalb von 90 Sekunden keine Antwort; die Modell-ID ist
vorhanden und konfiguriert, vor einem kostenintensiven Lauf ist aber ein erneuter Smoke-Test
erforderlich.

## Wichtig: `--safe-mode` ist hier nicht verwendbar

`--safe-mode` schaltet ausweislich der CLI-Hilfe „all customizations (CLAUDE.md, skills, plugins,
hooks, **MCP servers, custom commands and agents**, output styles, …)" ab – also genau das, was
dieser Versuch untersucht. Smoke-Test am 2026-08-26 (CLI 2.1.246, identischer Aufruf, nur das
Flag variiert):

| Konfiguration | `spawned` | `by_type` |
|---|---:|---|
| mit `--safe-mode` | **0** | leer – „die Rollen sind nicht in der Agent-Registry registriert" |
| ohne `--safe-mode` | **2** | `{"modulinventar": 1, "konsistenzpruefer": 1}` |

**Ohne diesen Test wäre der erste Lauf stillschweigend als V1-Lauf gemessen worden**: `--agents`
hätte keine Wirkung gehabt, der Lauf hätte fehlerfrei durchlaufen und Anforderungen erzeugt – nur
eben ohne die Rollen, die den Versuch ausmachen.

**Der Ersatz** (Skill 7.0.0): kein `--safe-mode`, stattdessen `--strict-mcp-config` und
`--disallowedTools Skill WebSearch WebFetch SlashCommand` zusätzlich zur 33er-Denylist.
Gegengeprüft mit derselben Werkzeugabfrage: `VORGELADEN: NICHTS VORGELADEN` · `SKILLS: KEINE` ·
`WEB: KEIN WEBZUGRIFF` · alle Rollen verfügbar. Ohne die Sperre lädt die CLI **16 global
installierte Skills** (darunter `code-review`, `security-review`, `run`, `init`);
`--setting-sources ''` unterdrückt sie nicht.

**Was der Ersatz nicht abdeckt:** Plugins, Hooks und Output-Styles. Auf der Versuchsmaschine ist
davon nichts konfiguriert, das ist aber eine Eigenschaft der Umgebung und keine Garantie. Der
Skill verlangt deshalb vor jedem Lauf eine Umgebungsprüfung, deren Ergebnis ins Protokoll geht.

**Folge für die Vergleichbarkeit:** Läufe dieses Versuchs sind hinsichtlich der Isolation nicht
unmittelbar mit den `solo`- und `builtin`-Läufen aus Versuch 1 vergleichbar. Der Unterschied ist
benannt und begrenzt – er betrifft Plugins, Hooks und Output-Styles, nicht CLAUDE.md, Skills,
Webzugriff oder MCP.

## Offene Punkte vor dem ersten Lauf

1. ~~**`extract-subagenten.py` ist nicht gegen `custom`-Typen geprüft.**~~ **Geklärt am
   31.08.2026 durch Inspektion:** Das Skript filtert auf die Werkzeugnamen `Task`/`Agent` und
   liest `subagent_type` generisch aus; eine Liste erwarteter Typen gibt es nicht. Custom-Typen
   werden damit wie eingebaute erfasst. Bestätigung am ersten realen Lauf steht aus.
2. **Die Modellbedingung ist bei Delegation über `--model` allein nicht herstellbar.** Zwei
   dokumentierte Fälle aus Versuch 1: bei Fable liefen die Subagenten auf `claude-opus-5[1m]`,
   bei Opus entfielen 18,5 Mio. Tokens (4,72 %) auf `claude-sonnet-5`. Nach jedem Lauf
   `modelUsage` prüfen und die Modellbedingung nicht als gesichert annehmen.
3. **Hintergrund-Subagenten und Zeitlimit.** Der Skill setzt seit 6.1.0
   `CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0`; ohne diese Einstellung bricht der Headless-Modus
   nach 600 s ab und meldet dabei `is_error: false` bei null Ergebnisdateien.
4. **Umgebungsprüfung** auf Hooks, Plugins und Output-Styles im User-Profil – siehe oben.
5. **Der `--safe-mode`-Smoke-Test lief auf CLI 2.1.246; installiert ist inzwischen 2.1.251.**
   Der Test ist das, was verhindert, dass ein V2-Lauf stillschweigend als V1-Lauf gemessen wird.
   Vor der Auswertung des ersten Laufs ist `subagent_stats.by_type` daher darauf zu prüfen, dass
   die Rollennamen tatsächlich erscheinen.