Neue gueltige Zellen in Iteration 3 - claude-opus-5/solo/high: 363 Anforderungen, 99,7 % mit Primaerbeleg, Belege je Anforderung Median 2,0, 38,1 Mio. Tokens - claude-fable-5/solo/high: 241 Anforderungen, 98,3 % mit Primaerbeleg, 89,0 % PRIMAER-Anteil, vollstaendig regelkonform, 30,6 Mio. Tokens Damit sind 6 von 12 Zellen des Rasters belegt. Zwei Befunde daraus: Die Belegdichte folgt dem Modell, nicht dem Effort. Opus erreicht Median 2,0 auch auf high; alle 44 Sonnet-Laeufe lagen bei 1,0. max hebt Opus auf 3,0. Die frueher dem Effort zugeschriebene Verdopplung ist damit eingegrenzt. Die Fable-Modellverletzung ist reproduziert und abgegrenzt. Bei builtin laufen die Subagenten auf claude-opus-5[1m] statt Fable (zweiter Fall nach Iteration 1), bei solo dagegen sauber. Nicht das Modell ist die Ursache, sondern Fable in Kombination mit Delegation. Fehlmessungen, vollstaendig protokolliert - vier 429-Abbrueche (Session-Kontingent) aus dem Parallelblock 19:59; drei davon mit Teilbestand, einer ohne Ergebnis - opus-5/builtin/high zum dritten Mal gescheitert: 790,7 Mio. Tokens ueber drei Anlaeufe ohne Artefakt. Zelle mit dieser Prompt-Version nicht messbar. Skill 7.0.0 (MAJOR) - Isolationsmechanismus modusabhaengig: --safe-mode schaltet MCP-Server und Custom-Agenten ab und ist mit V2/V3 unvereinbar. Smoke-Test verifiziert: mit Flag spawned=0, ohne Flag spawned=2. Ersatz fuer custom/MCP: --strict-mcp-config plus --disallowedTools Skill WebSearch WebFetch SlashCommand. - 6.1.0: Pflichtpruefung leeres Ergebnisverzeichnis = Fehlmessung unabhaengig von is_error; CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0; Protokollfeld Gueltigkeit - extract-subagenten.py: Start-Quittung wird nicht mehr als Ertragsmass ausgewiesen Versuch 2 und 3 vorbereitet - Prompt-Kette V1 -> V2 (02-A, angepasst an Agentendateien) -> V3 (02-B, MCP) - V2: acht Rollen inkl. nicht delegierendem ISO-29148-Orchestrator - V3: elf Rollen, fuenf Werkzeugserver, neue Belegklasse LAUFZEIT Ablaufprotokoll um Phase 6 und 7 sowie die Vorbereitung von V2/V3 ergaenzt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8.3 KiB
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 |
|---|---|---|
01_Prompt.md |
DCDC0E3F…B71BCF |
Analyseanweisung, Prompt-Version 02-A |
01_Agents.json |
6943EECD…AF1696 |
acht Agentenrollen |
Der Prompt: abgeleitet aus V1, angepasst an Agentendateien
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 |
syrs-autor |
Systemebene | ja, nur SyRS |
swrs-autor |
Softwareebene, zusätzlich Konsolidierungsprüfung | ja, nur SwRS |
iso29148-orchestrator |
führt die Ebenen zur Spezifikation zusammen | 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 keine Anforderungen, sondern stellt her, was erst am zusammengeführten Bestand entstehen kann: durchgängige Nummerierung samt mitgezogener Verweise, beidseitig geschlossene Traceability, eine aus dem Gesamtbestand erzeugte Hypothesenliste, die Abdeckungstabelle über das gemeinsame Inventar. 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>/.
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
extract-subagenten.pyist nicht gegencustom-Typen geprüft. Es erwartet die eingebauten TypenExploreundgeneral-purpose; mit--agentsheißen siefaktenermittler,strs-autorund so fort.- Die Modellbedingung ist bei Delegation über
--modelallein nicht herstellbar. Zwei dokumentierte Fälle aus Versuch 1: bei Fable liefen die Subagenten aufclaude-opus-5[1m], bei Opus entfielen 18,5 Mio. Tokens (4,72 %) aufclaude-sonnet-5. Nach jedem LaufmodelUsageprüfen und die Modellbedingung nicht als gesichert annehmen. - 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 dabeiis_error: falsebei null Ergebnisdateien. - Umgebungsprüfung auf Hooks, Plugins und Output-Styles im User-Profil – siehe oben.