diff --git a/workflows/error-recovery.md b/workflows/error-recovery.md
new file mode 100644
index 0000000..15bd410
--- /dev/null
+++ b/workflows/error-recovery.md
@@ -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.
diff --git a/workflows/self-correction.md b/workflows/self-correction.md
new file mode 100644
index 0000000..d8750e6
--- /dev/null
+++ b/workflows/self-correction.md
@@ -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.