---
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.