# SAFETY_CONTRACT — Retry, Loop, Attempt Ledger, Oscillation, Circuit Breaker

> **Geltungsbereich:** Red Queen Autonomous Engineering System v1
> **Status:** Verbindlicher Safety-Contract
> **Sprache:** Deutsch (verbindlich)

---

## 1. Prinzip

Alle Wiederholungs-, Fehler- und Schleifenlogik ist **deterministisch** und wird durch den
**Deterministic Safety Layer** überwacht. Ziel: keine Endlosschleifen, kein Blind-Wiederholen,
kein unkontrollierter Schaden. **Hard Limits werden immer vor Anwendung eines Zählers definiert.**

## 2. Retry / Loop Contract

### 2.1 Globale Notbremse
- `max_iterations = 50` ist die **äußerste Notbremse** für die gesamte Mission/Schleife.
  Sie wird nur als **letzter Schutz** erreicht und darf im Normalbetrieb nie erreicht werden.
  Erreicht ein Zähler `50`, **erzwungener STOPP** (Circuit Breaker) und Escalation.

### 2.2 Operative Regeln (früher und wirksamer)
| Regel | Limit | Erläuterung |
|-------|-------|-------------|
| Maker→Checker **Repair** | **MAX 3** | Maximal 3 Mal darf ein MAKER nach CHECKER-FAIL korrigieren |
| Gleiche **Error Signature** | **MAX 2** | Gleiche Fehler-Signatur maximal 2 Versuche |
| Gleiche **Lösungsstrategie** | **Nicht blind** | Bei erneuter Fehler-Signatur NIE dieselbe Strategie ungeprüft wiederholen; Strategiewechsel verpflichtend |

### 2.3 Eskalationskette (nach wiederholtem Fail)
```
Fehlschlag →
  1) Repair (Maker)  [MAX 3]
  2) Gleiche Error-Signatur? → Strategiewechsel (Debugger) [MAX 2]
  3) Debugger (Root Cause, neue Strategie)
  4) Second Opinion (frischer Checker/External)
  5) BLOCK / ESCALATE (an Red Queen → Christian)
```
- Wenn nach der Eskalationskette **kein Fortschritt** → **BLOCKED/ESCALATED** (siehe
  MISSION_STATE_MACHINE) und **STOPP**.
- Kein Sub-Agent darf die Kette überspringen oder von Schritt 5 zurück zu Schritt 1
  springen, ohne dass der Fehler verändert wurde.

### 2.4 Zähler-Zurücksetzung
- Zähler werden **pro TASK_ID** geführt und nur bei einem tatsächlichen Fortschritt
  (neue Erkenntnis, neuer Zustand) zurückgesetzt. Bloßer Zeitablauf setzt nichts zurück.

---

## 3. Attempt Ledger Contract

**Zweck:** Unveränderliches, nachvollziehbares Log jedes Versuchs — Grundlage für Debugger,
Checker und Oscillation Detection.

### 3.1 Ledger-Schema (jeder Eintrag)
| Feld | Bedeutung |
|------|-----------|
| `ATTEMPT_ID` | Eindeutige ID dieses Versuchs |
| `TIMESTAMP` | Zeitpunkt |
| `TASK_ID` | Zugehörige Aufgabe |
| `HYPOTHESIS` | Vermutete Ursache/Annahme |
| `STRATEGY` | Gewählter Ansatz |
| `CHANGE` | Was geändert wurde |
| `RESULT` | Ergebnis (PASS/FAIL/…) |
| `ERROR_SIGNATURE` | Normalisierte Fehlerkennung |
| `PROGRESS` | Messbarer Fortschritt (ja/nein, welcher) |

### 3.2 Regeln
- **WHO:** Red Queen/Safety Layer schreibt jeden Versuch **append-only** in das Ledger.
- **Kein Löschen / kein Überschreiben** historischer Einträge.
- **CHECKER/DEBUGGER** lesen das Ledger, um Duplikat-Strategien zu vermeiden.
- Ohne Ledger-Eintrag keine neue Zählung; Zählung basiert auf Ledger-Daten.

---

## 4. Oscillation Contract

**Definition von Oscillation:**
- **A→B→A→B** (Zustand/Strategie wechselt ohne echten Fortschritt).
- **Wiederholte Fehler-Signaturen** trotz Wechselversuch.
- **Wiederholte Dateiänderung ohne Fortschritt** (Änderung an derselben Datei, keine messbare
  Verbesserung).

### 4.1 Detektion
- Safety Layer prüft jede neue Attempt gegen das Ledger:
  - Fehler-Signatur identisch zu ≥1 Vorgänger → Warnung.
  - Datei X ≥3 Mal geändert ohne Progress-Metrik → **Oscillation-Verdacht**.
  - Zustandsfolge A→B→A→B erkannt → **Oscillation**.
- **Progress muss messbar sein** (nicht subjektiv). Progress = messbare Metrik
  (z. B. "Test X grün", "Anzahl Fehler sinkt", "Doku-Datei angelegt"), belegt in `PROGRESS`.

### 4.2 Reaktion
- Bei Oscillation: **STOP** der aktuellen Schleife, **Strategiewechsel erzwingen**,
  ggf. **DEBUGGER einsetzen**, andernfalls **BLOCK/ESCALATE**.
- **NIE** dieselbe Strategie blind fortsetzen.

---

## 5. Circuit Breaker Contract

**Zweck:** Harte, automatische Haltesperre bei kritischen Bedingungen.

### 5.1 Trigger-Liste (mindestens diese Bedingungen öffnen den Breaker)
| Trigger | Beispiel |
|---------|----------|
| **Retry** | operativ Limits überschritten (Repair>3, Signature>2) |
| **Oscillation** | A↔B, wiederholte Signaturen, Dateiänderung ohne Progress |
| **State** | ungültige/verbotene Zustands-Transition |
| **Git** | Konflikt/Diverenz, main-Manipulation (siehe PARALLEL) |
| **Prod** | Betroffenheit von Produktion/Live-System |
| **Secret** | Geheimnis/Token-Abruf/Schlüssel sichtbar |
| **Regression** | bestehende Funktionalität gebrochen (Test-Fail) |
| **SSH** | Remote-Zugriff/Verbindung ohne Freigabe |
| **Disk** | Festplatten-/Speicherprobleme |
| **Approval-Identity** | Unberechtigte Freigabe / Identity-Zweifel |
| **Persistenz** | Persistenz/Repo-Integrität gefährdet |

### 5.2 Aktionen bei geöffnetem Breaker
1. **STOP** — alle Sub-Agenten/Arbeit sofort beenden (keine neuen Aktionen).
2. **SAVE** — aktuellen Zustand/ledger persistieren (sofern möglich).
3. **NO MUTATION** — keinerlei weitere Änderung an Dateien/Repo/Systemen.
4. **TELEGRAM ALERT** — kritische Meldung an Telegram (siehe TELEGRAM_MISSION_CONTROL).

### 5.3 Reset / Closing
- Breaker bleibt **offen** bis ein **validierter** Reset erfolgt:
  - Ursache behoben & dokumentiert, gültige Zustands-Transition, Freigabe.
  - **Human/Christian** bei kritischen Triggern (Prod/Secret/SSH/Persistenz/Identity).
- Reset nur durch Red Queen (Lead) + ggf. Christian; kein selbst-Auto-Reset in kritischen Klassen.

---

## 6. Safety Gates & STOP

- **WHO:** Red Queen führt die Safety Layer aus; jeder Sub-Agent hält Limits.
- **WHEN:** Vor jeder Transition, vor jeder Retry, vor jeder Aufgabe-Abschluss.
- **WHERE:** Systemweit, auf Mission- und WP-Ebene.
- **STOP:** Jeder Trigger der §5.1 erzwingt sofortiges STOP; Fortsetzung ohne Freigabe verboten.