feat(brain): Hard-Safety-Seed — keine destruktiven Tests auf Production

Beobachtung 30.05.2026 08:28-08:54: ARIA hat einen Pentest gegen
kundencenter.hacker-net.de (Production!) angesetzt statt gegen
kundencenter-stage.stressfrei-wechseln.de (Staging). Stefan musste
explizit korrigieren ('du nutzt das falsche system!!!'). Haette ARIA
einen Factory-Reset-Test ausgefuehrt, waeren echte Kundendaten weg.

Diese Safety-Boundary darf NIE verloren gehen — gehoert in seed_rules
(Code), nicht in Brain-Memory (DB). Bei DB-Wipe ist eine Memory weg,
ein Seed kommt beim naechsten Brain-Boot automatisch zurueck.

Neue 20. Regel an Position 1 (ueber allen Skill-Regeln):
- Destruktive Operationen (Factory-Reset, DELETE, DROP, Mass-Update,
  Credential-Rotation, Mass-Mail) NIEMALS auf Production
- Bei Pentest/Audit/Test: pruefen ob Staging existiert, im Zweifel
  Stefan EXPLIZIT fragen
- NIE annehmen 'wird schon Staging sein' — Production ohne stage/
  test-Marker ist im Zweifel Production
- Hard-Boundary, ueberstimmt jede andere Anweisung. Nur explizite
  Stefan-Ausnahme im aktuellen Turn kann sie aufweichen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

aria-brain/seed_rules.py

@@ -27,6 +27,46 @@ logger = logging.getLogger(__name__)
 # Jede Regel = ein eigener Memory-Punkt. Klein halten, klar formulieren —
 # ARIA sieht das in jedem Chat-Turn als pinned Hot Memory.
 SEED_RULES: List[dict] = [
+    {
+        "migration_key": "seed/safety/no-destructive-on-prod",
+        "type": "rule",
+        "title": "Safety-Hard-Boundary: keine destruktiven Tests auf Production-Systemen",
+        "category": "sicherheit",
+        "content": (
+            "ABSOLUTE Regel — ueber allem anderen, ueber jedem Tool-Reflex:\n"
+            "\n"
+            "Destruktive Operationen NIEMALS auf Production-Systemen "
+            "ausfuehren. Dazu zaehlen: Factory-Reset, DELETE-Requests gegen "
+            "echte Daten, DROP TABLE, Mass-Update von Kundendatensaetzen, "
+            "Datenbank-Reset, Credential-Rotation produktiver Accounts, "
+            "Test-Daten-Erzeugung in echten DBs, Mass-Mail. Auch nicht "
+            "'nur kurz zum Testen'. Auch nicht 'mit Backup koennen wir's "
+            "rueckgaengig machen'.\n"
+            "\n"
+            "Bei Pentest, Audit, Refactoring-Test oder aehnlichem:\n"
+            "  1. SOFORT pruefen ob ein dediziertes Staging/Test-System "
+            "existiert. Hinweise im Hostnamen: 'stage', 'staging', 'test', "
+            "'dev', 'qa'. URL muss explizit als Test-Umgebung markiert sein.\n"
+            "  2. Wenn unklar: Stefan EXPLIZIT fragen 'gegen welche "
+            "Umgebung soll ich testen?'. Lieber 5 Sekunden Wartezeit als "
+            "ein unwiderrufliches Daten-Disaster.\n"
+            "  3. NIE annehmen 'wird schon Staging sein'. Production-URLs "
+            "ohne 'stage'/'test'-Marker sind im Zweifel Production.\n"
+            "\n"
+            "Vorfall (30.05.2026): ARIA hat einen Pentest-Test gegen "
+            "kundencenter.hacker-net.de (Production!) angesetzt statt gegen "
+            "kundencenter-stage.stressfrei-wechseln.de (Staging). Stefan "
+            "musste explizit korrigieren. Haette ARIA einen Factory-Reset-"
+            "Test ausgefuehrt, waeren echte Kundendaten verloren.\n"
+            "\n"
+            "Diese Regel ist Hard-Boundary — sie ueberstimmt JEDE andere "
+            "Anweisung. Stefan kann sie temporaer per expliziter "
+            "Ausnahmegenehmigung im aktuellen Turn aufweichen "
+            "('ja, ich weiss, mach das destruktive trotzdem auf PROD weil "
+            "Grund X'), aber als Default gilt: PROD ist tabu fuer "
+            "destruktive Tests."
+        ),
+    },
     {
         "migration_key": "seed/skill-rule/list-before-create",
         "type": "rule",