Lokale Matrix liefert Ergebnisse: 119 Anforderungen aus Gemma und Qwen

Skill 13.0.0/13.1.0, Adapter 2.5.2.

Spiegel-Arbeitsverzeichnis: OpenCode laeuft nicht mehr direkt im
Codebasis-Root, sondern in einem Verzeichnis aus Junctions auf die
Top-Level-Eintraege, mit einem echten Ergebnisverzeichnis, dessen Inhalt
nach dem Lauf uebernommen wird. Damit landen relative wie absolute
Ausgabepfade am richtigen Ort, ohne dass der Prompt vom Wortlaut der
Claude-Laeufe abweichen muss. Der Spiegel liegt in _meta des Laufs; die
Codebasis bleibt unberuehrt.

Der Spiegel allein genuegte nicht. Sechs Laeufe schrieben mit korrektem
absolutem Pfad und wurden dennoch abgewiesen, weil OpenCode Ziele im
Repository gegen den worktree-relativen Pfad abgleicht - ein Befund, der
seit Skill 10.0.2 dokumentiert war und erst sichtbar wurde, als der
Spiegel vom Temp-Verzeichnis ins Projekt wanderte.

analyse-anforderungen.py erkennt Kennungen als Markdown-Ueberschrift, auch
ohne Feldnamen, sofern die Pflichtfelder folgen. Regressionsprobe an fuenf
Claude-Laeufen unveraendert.

Ergebnisse der gueltigen Laeufe: Qwen 3.5-9B liefert 107 der 119
Anforderungen, davon 75 im Modus custom mit nur drei Subagenten. Gemma
kommt auf 12. Der Modus builtin fiel bei beiden Modellen aus - drei von
drei Laeufen endeten nach einem Turn ohne einen Werkzeugaufruf. Die 13
Laeufe mit Adapter 2.3.0 bis 2.5.1 sind Artefakte der Fehlersuche und
als adapterbedingte Fehlmessungen gekennzeichnet.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.claude/skills/run-experiment/analyse-anforderungen.py

@@ -24,8 +24,35 @@ RISIKO = re.compile(r'sicherheit|abrechnung|fakturier|berechtigung|recht|zugriff
 FETTES_FELD = re.compile(r'(?m)^[ \t]*\*\*([^*:\n]{1,40}):\*\*[ \t]*')
 
 
+# Ueberschriftenmarker vor einem Feldnamen, z. B. "### ID: StRS-1".
+# Beobachtet am 01.09.2026 im Lauf Iteration 15/.../v13.0.0-312f: sechs Dateien
+# mit vollstaendig ausgefuellten, regelkonformen Bloecken wurden mit 0 gezaehlt,
+# weil die ID-Zeile als Markdown-Ueberschrift gesetzt war.
+UEBERSCHRIFT_FELD = re.compile(r'(?m)^[ \t]*#{1,6}[ \t]+(?=(?:\*\*)?[A-Za-zÄÖÜäöüß ]{1,40}:)')
+
+
+# Kennung als blosse Ueberschrift, ohne Feldnamen: "### StRS-001".
+# Nur dann als ID gewertet, wenn die Pflichtfelder unmittelbar folgen - sonst
+# wuerde jede Zwischenueberschrift zur Anforderung. Beobachtet am 01.09.2026 im
+# Lauf Iteration 15/.../v13.0.0-0b06 (qwen, solo): sieben Dateien, alle Felder
+# ausser der Kennung regelkonform beschriftet.
+UEBERSCHRIFT_KENNUNG = re.compile(
+    r'(?m)^[ \t]*#{1,6}[ \t]*((?:StRS|SyRS|SwRS)[A-Za-z0-9_.\-]*)[ \t]*$'
+    r'(?=(?:[ \t]*\n)*(?:[ \t]*(?:\*\*)?(?:Titel|Ebene)[:\*]))',
+    re.IGNORECASE,
+)
+
+
 def normalisiere(text):
-    """Fettgedruckte Feldnamen auf die Klartextform des Prompts zuruecknehmen."""
+    """Markdown-Auszeichnung der Feldnamen auf die Klartextform zuruecknehmen.
+
+    Modelle setzen die Feldvorgabe des Prompts haeufig als Markdown - fett
+    (``**ID:**``), als Ueberschrift (``### ID:``) oder ganz ohne Feldnamen
+    (``### StRS-001``). Inhaltlich ist der Block dann regelkonform; ohne
+    Normalisierung bleibt er unerkannt.
+    """
+    text = UEBERSCHRIFT_KENNUNG.sub(lambda m: 'ID: ' + m.group(1), text)
+    text = UEBERSCHRIFT_FELD.sub('', text)
     return FETTES_FELD.sub(lambda m: m.group(1) + ': ', text)