trading-system-docs/red-queen-architecture/ROOT_SSH_GATE.md

4.7 KiB

ROOT_SSH_GATE — Privilegierter Zugriff (Root/SSH) Vertrag

Geltungsbereich: Red Queen Autonomous Engineering System v1 Status: Verbindlicher Gate-Vertrag für privilegierte Aktionen (Root/SSH) Sprache: Deutsch (verbindlich) Verwandt: SAFETY_CONTRACT.md, EXTERNAL_REVIEW_CONTRACT.md, SELF_IMPROVEMENT_POLICY.md


1. Grundsatz

Root ist KEIN Standardmodus. Red Queen und alle Sub-Agenten arbeiten standardmäßig als unprivilegierter Runtime-User. Jede privilegierte Aktion (Root-Befehl, SSH-Zugriff, Sudo) ist ein Ausnahmefall und unterliegt einem obligatorischen Gate.

Privilegierte Operationen dürfen nie automatisch, ungeprüft oder als Nebeneffekt ausgeführt werden.

2. Klassifikation

Kategorie Beschreibung Autonomie
READ-ONLY Diagnose Zustand prüfen ohne Mutation (z. B. df, ps, Lese-Zugriff auf Config) Autonom erlaubt, sofern selbst keine Änderung verursacht und keine Secret-Ausgabe
Privilegierte Mutation Irgendeine Zustandsänderung über Root/SSH/Sudo Gate-Pflicht (Abschnitt 3)

READ-ONLY-Diagnose darf autonom erfolgen, wenn sie (a) selbst keinen Zustand ändert, (b) keine Secrets druckt und (c) auf den konkreten Diagnose-Zweck begrenzt ist. Bei Unsicherheit, ob eine Aktion read-only ist → als Mutation behandeln.


3. Gate vor jeder privilegierten Mutation

Vor jeder privilegierten Mutation (Root/SSH) MÜSSEN alle Pflichtfelder erfüllt sein:

Pflichtfeld Definition Beispiel
WHY Zweck, Problem/Anforderung, die nur privilegiert lösbar ist "Config-Datei anpassen, die nur root lesen kann"
WHAT Exakt welche Aktion/Änderung (eine logische Änderung) "Eine Zeile in <file> ergänzen"
IMPACT Erwartete Auswirkung (Zustand vorher → nachher), Risiko "Betroffene Dienste, keine Downtime erwartet"
DEPENDENCIES Was muss vorhanden sein (Backups, Abhängigkeiten, Reihenfolge) "Backup liegt vor; Dienst stoppt sauber"
BACKUP Belegbarer Rollback-Bezug (Snapshot/Backup vorhanden) "Config unter <backup> gesichert"
ROLLBACK Konkrete Rückabwicklung bei Fehlschlag "Zeile wieder entfernen / Config restore"
TEST Verifikation des Erfolgs nach der Änderung "Dienst startet, Konfigurationsprüfung OK"

Regel: EINE logische Änderung → VALIDIEREN → TESTEN → erst dann weiter.

  • Ein Commit/Eine Aktion pro Gate-Durchlauf.
  • Nach der Änderung zwingend VALIDIEREN (ist das erwartete Ergebnis da?).
  • Danach TESTEN (Verifikation aus TEST-Feld).
  • Erst nach erfolgreicher Validierung darf die nächste Änderung beginnen.

4. Kritische Bereiche (erhöhte Gate-Stufe)

Folgende Bereiche erfordern zusätzlich zur obigen Gate Christian/Approval:

  • SSH / Remote-Zugriff
  • Firewall / Networking
  • Docker / Container-Infrastruktur
  • Reverse Proxy
  • Authentication / Authorization
  • Secrets / Credential-Verwaltung
  • Recovery Access (Backup-Zugang)
  • Forgejo Security
  • Ollama Core-Infrastruktur
  • Red Queens eigener Container
  • Hermes Runtime
  • Zentrale Persistenz (state.db, Kanban, Cron)
  • Circuit Breaker / Approval-Gates selbst

Für diese Bereiche: Gate = Pflichtfelder (3) + Christian-Approval — KEINE autonome privilegierte Mutation.


5. Zuständigkeit (WHO / WHEN / STOPP)

Rolle Darf
Red Queen (Orchestrator) READ-ONLY-Diagnose autonom; privilegierte Mutation nur mit Gate (3); kritische Bereiche nur mit Christian-Approval
Sub-Agenten (Maker/Checker/Debugger/Tester/Knowledge) NIE selbst Root/SSH-Mutationen. Nur nach ausdrücklicher Freigabe durch Red Queen/Christian mit präzisem, begrenztem Scope
Rain NIE Root/SSH-Aufträge von Red Queen (siehe EXTERNAL_REVIEW_CONTRACT.md); nur Christian entscheidet über Rain-Einsatz
Christian einzige Instanz für kritische Gate-Freigaben

STOPP-Bedingungen (Break):

  • Ein Pflichtfeld aus Abschnitt 3 fehlt oder ist vage → STOPP, keine Mutation.
  • Unerwartete Berechtigungsänderung / Identity-Mismatch → STOPP, Circuit Breaker.
  • Kritischer Bereich ohne Christian-Approval → STOPP.
  • SECRET / Credential wird sichtbar → STOPP, Sicherheits-Vorfall.

REMAIN-Verstärkung: Bestehende safe-root-engineering / safe-change-management Regeln werden durch diesen Vertrag nicht abgeschwächt, sondern übernommen.


6. Verhältnis zu anderen Contracts

  • SAFETY_CONTRACT.md — Retry/Loop/Circuit Breaker (privilegierte Aktion fällt unter dessen Regeln).
  • SELF_IMPROVEMENT_POLICY.md — Änderungen an Root/SSH-Policy = SI-3 (Human/External Gate).
  • EXTERNAL_REVIEW_CONTRACT.md — Rain erhält nie Root/SSH-Aufträge von Red Queen.