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>
SSMS_DB_SCHEMA.sql (3.266.626 B, 76.793 Zeilen) - Schema-Dump der Datenbank
CentronVOED2: 1.558 Tabellen, 182 Views, 63 Prozeduren, 30 Funktionen,
134 Fremdschluessel.
Aenderung der Versuchsbedingung: Der Prompt fordert Datenbankschemata in
Schritt 2 (Artefakterhebung) ausdruecklich als Quelle. Laeufe mit und ohne
diese Datei untersuchen einen anderen Gegenstand und sind nicht poolbar.
Zeitpunkt im Arbeitsverzeichnis: 2026-08-26 10:28:08.
- Laeufe ohne die Datei: Tag 2, 02_Lauf_..._084301-d6f9 sowie 094249/094250
(3983, f631, c69e); 4840 lief zum Zeitpunkt des Hinzufuegens noch.
- Laeufe mit der Datei: die fuenf 102932-Laeufe, abgelegt unter Tag 3.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
QuellCode/CentronERP war nur als Gitlink (Submodul-Referenz auf 79c1142)
getrackt, ohne .gitmodules und ohne erreichbares Remote. Der
Untersuchungsgegenstand der Versuchsreihe war damit nicht reproduzierbar
gesichert: Ein Klon haette ein leeres Verzeichnis erhalten, und die Belege
der 3.287 Anforderungen waeren nicht ueberpruefbar gewesen.
Umstellung:
- Historie nach c:\DEV\CentronERP_git_snapshot_79c1142 ausgelagert
(vollstaendig lesbar, enthaelt 79c1142 und Vorgaenger 89ccfd6)
- Gitlink aus dem Index entfernt
- Dateiinhalt aufgenommen: 24.557 Dateien, rund 333 MB
Die verschachtelte .gitignore der Codebasis gilt weiter, Build-Artefakte
bleiben ausgeschlossen. Details in Versuche/Versuch_01/_Codebasis-Nachweis.md
Christoph Schwörer