M3.7+8: workflows/self-correction + workflows/error-recovery
Zwei verwandte aber unterschiedliche Recovery-Pattern: - self-correction: Backend liefert strukturierte errors[] (z.B. atomic_validate_crossword_grid mit Frame-Konflikt-Hinweis), LLM korrigiert gezielt. Max 4 Versuche, dann vereinfachen. "Server denkt"- Pattern, wiederverwendbar fuer kommende validierte Builder. - error-recovery: Tool wirft unstrukturierten Error (HTTP, FK-Verletzung, Timeout). LLM variiert Input, max 3 Versuche, dann ehrlich abbrechen. Beide Pattern koennen parallel in derselben Persona aktiv sein — self-correction beim Validate-Loop, error-recovery bei allen anderen Tools. Die Module sind explizit gegeneinander abgegrenzt (Vergleichstabelle in error-recovery.md). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
module_id: workflows/error-recovery
|
||||||
|
version: 0.1.0
|
||||||
|
description: Was tun wenn ein Tool-Call fehlschlaegt (ohne strukturierten Error-Channel).
|
||||||
|
max_tokens: 150
|
||||||
|
applies_to: [main-voice, kreuzwort-builder, lueckentext-builder, future-personas]
|
||||||
|
sources:
|
||||||
|
- personas/lueckentext-builder.md ("probier nochmal mit anderem Input. ... 3 Versuche")
|
||||||
|
- personas/main-voice.md (Anti-Halluzination + ehrlich bei Fehlschlag)
|
||||||
|
extracted_at: 2026-06-02
|
||||||
|
extracted_by: phase-M3
|
||||||
|
---
|
||||||
|
|
||||||
|
# Error Recovery
|
||||||
|
|
||||||
|
Wenn ein Tool-Call **ohne strukturierte Validation** scheitert (z.B. `error: "..."`
|
||||||
|
im Result-Objekt, HTTP-Error, Timeout):
|
||||||
|
|
||||||
|
## Ablauf
|
||||||
|
|
||||||
|
1. **Lies die Fehlermeldung.** Was sagt das Backend? FK-Verletzung, fehlende ID,
|
||||||
|
ungueltiger Wert?
|
||||||
|
2. **Variiere den Input.** Wenn die ID nicht existiert: hol sie dir frisch via
|
||||||
|
List-Tool. Wenn der Wert ungueltig war: korrigier ihn basierend auf der Meldung.
|
||||||
|
3. **Versuche es nochmal.** Selbes Tool, neue Argumente.
|
||||||
|
|
||||||
|
## Hard Limit: max 3 Versuche pro Tool-Call
|
||||||
|
|
||||||
|
Bei **drittem Fehlschlag** desselben Tools: **abbrechen**. Sag dem User (bzw.
|
||||||
|
der Main-Voice) ehrlich was nicht ging — keine Halluzinations-Antwort, kein
|
||||||
|
"war alles ok".
|
||||||
|
|
||||||
|
## Unterschied zu `workflows/self-correction.md`
|
||||||
|
|
||||||
|
| Pattern | Tool liefert ... | Beispiel |
|
||||||
|
|----------------------|-----------------------------------|-------------------------------------|
|
||||||
|
| `self-correction` | strukturierte `errors[]`-Liste | `atomic_validate_crossword_grid` |
|
||||||
|
| `error-recovery` | unstrukturierten `error`-String | jeder andere Tool-Call der fail't |
|
||||||
|
|
||||||
|
Beide Pattern koennen in derselben Persona aktiv sein — sie greifen aber bei
|
||||||
|
verschiedenen Fehler-Arten.
|
||||||
@@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
module_id: workflows/self-correction
|
||||||
|
version: 0.1.0
|
||||||
|
description: Validate-Loop-Pattern — Backend liefert strukturierte Fehler, LLM korrigiert.
|
||||||
|
max_tokens: 200
|
||||||
|
applies_to: [kreuzwort-builder, future-validated-builders]
|
||||||
|
related_pattern: "Server denkt — Backend validiert, Frontend rendert."
|
||||||
|
sources:
|
||||||
|
- personas/kreuzwort-builder.md (Self-Correction-Loop um atomic_validate_crossword_grid)
|
||||||
|
extracted_at: 2026-06-02
|
||||||
|
extracted_by: phase-M3
|
||||||
|
---
|
||||||
|
|
||||||
|
# Self-Correction Loop
|
||||||
|
|
||||||
|
Wenn dir ein Backend-Tool eine **strukturierte Validation** anbietet
|
||||||
|
(z.B. `atomic_validate_crossword_grid` mit `{ ok: false, errors: [...] }`),
|
||||||
|
ist dein Arbeits-Pattern:
|
||||||
|
|
||||||
|
## Ablauf
|
||||||
|
|
||||||
|
1. **Vorschlag bauen.** Konstruiere deinen ersten Versuch (z.B. ein Wort-Grid).
|
||||||
|
2. **Validieren.** Rufe das Validation-Tool mit deinem Vorschlag.
|
||||||
|
3. **Bei `ok=false`:** lies `errors[]` genau. Jeder Eintrag erklaert konkret was
|
||||||
|
schiefging (Frame-Konflikt, Connected-Component-Verletzung, Bounds-Verstoss,
|
||||||
|
Parallel-Beruehrung ohne Kreuzung, ...). **Korrigiere basierend auf den Errors**
|
||||||
|
— nicht raten, nicht erfinden, sondern den konkreten Fehler beheben.
|
||||||
|
4. **Erneut validieren.** Schritt 2 + 3 wiederholen.
|
||||||
|
|
||||||
|
## Hard Limit: max 4 Versuche
|
||||||
|
|
||||||
|
- Bei **drittem Fehlschlag**: vereinfache (weniger Elemente, kleinere Dimension).
|
||||||
|
- Bei **viertem Fehlschlag**: brich ab. Sag ehrlich was nicht ging
|
||||||
|
(siehe `base/constraints.md`). Lieber ein ehrlicher Abbruch als ein verkorkstes Ergebnis.
|
||||||
|
|
||||||
|
## Warum "Server denkt"
|
||||||
|
|
||||||
|
Das Backend kennt die Constraints (Grid-Topologie, Wort-Kollisionen, mathematische
|
||||||
|
Gueltigkeit) verlaesslicher als das LLM sie erraten kann. Lass das Backend pruefen —
|
||||||
|
deine Rolle ist Kreativitaet (Wort-Wahl, thematische Stimmigkeit), nicht Mathematik.
|
||||||
|
|
||||||
|
`ok=true` → uebernimm die zurueckgegebenen Daten (z.B. `cells[]` beim Kreuzwort)
|
||||||
|
direkt fuer die folgenden Bau-Tool-Calls. Nicht nochmal selbst rechnen.
|
||||||
Reference in New Issue
Block a user