5.9 KiB
5.9 KiB
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 = 50ist 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ähler50, 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
- STOP — alle Sub-Agenten/Arbeit sofort beenden (keine neuen Aktionen).
- SAVE — aktuellen Zustand/ledger persistieren (sofern möglich).
- NO MUTATION — keinerlei weitere Änderung an Dateien/Repo/Systemen.
- 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.