136 lines
5.9 KiB
Markdown
136 lines
5.9 KiB
Markdown
# 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.
|