# Hermes-System-Operation (VPS/Master) — durable Regeln für Config-/Budget-Management

> Session 2026-08-08: Nutzer legte fest, wie der Master sein eigenes System verwaltet.
> Diese Regeln sind klasse-weit gültig und ausdrucklich gewollt — NIE ignorieren.

## 1. Hermes-Config NIE via patch/editor ändern — IMMER `hermes config set`

`patch`/`write_file` auf `/root/.hermes/config.yaml` wird abgelehnt („Refusing to write to Hermes config file"). Der Weg ist ausschließlich:

```bash
hermes config set <pfad.zum.key> <wert>    # z.B. approvals.mode auto
hermes config get  <pfad.zum.key>          # rücklesen/verifizieren
```

Beispiel (NUTZER-TROTZ): die falsche Schlüsselnotiz `models.` → richtige `model.` (Singular) bei OpenRouter; beide werden von `hermes config set` geschrieben, aber nur der echte Key wirkt.

## 2. approvals.mode = auto (NUTZERFREIGABE 2026-08-08)

- `hermes config set approvals.mode auto` — reduziert „allow?"-Rückfragen bei normaler Systemarbeit.
- **Sicherheitsnetz bleibt:** die `command_allowlist` (recursive delete, overwrite system config, sudo-Eskalation, …) ist eine **harte Sperre** und greift auch in auto — die kann kein Agent freigeben, bewusst.
- `mcp_reload_confirm` + `destructive_slash_confirm`: **bleiben aktiv** (Nutzer: „Auch ok" — als Schutz behalten).

## 3. BACKUP-ONLY-REGEL (NUTZER, nicht verhandelbar)

> „Wenn also Backup und Rückkehr Optionen da sind, brauchen wir kein extra allow."

Vor **JEDER** System-/Config-/Skript-Änderung zuerst ein Backup + Rückkehr-Option anlegen:

```bash
cp <datei> <datei>.bak-$(date +%s)
```

- Vor systemd-Unit-Änderung → aktuelle Unit-Datei sichern.
- Vor Firewall/UFW → Regelstand exportieren.
- Solange ein Rollback existiert, ist keine weitere Freigabe nötig.
- Hermes legt bei `hermes config set` selbst `.bak.*`-Dateien an — zusätzliche `.bak` bei eigenen Skripten trotzdem setzen.

## 4. Memory-Limits (konfigurierbar, verdoppelt 2026-08-08)

Der Nutzer wählte „Memory verdoppeln" statt bestehende Einträge zu streichen (beides per `hermes config set`):
- `memory.memory_char_limit`: **4400** (war 2200)
- `memory.user_char_limit`: **2750** (war 1375)

Vorher „Memory voll"-Fehler: NICHT bestehende Einträge löschen, sondern Limit erhöhen (Nutzerpräferenz) und/oder kurz verdichten.

## 5. „Wir, nicht du" — Team-Pflicht (Nutzer-Frust aus 2026-08-08)

Der Nutzer korrigierte mehrfach: Master soll bei den Kernsystemen NICHT allein bauen, sondern **Team einspannen** (Brainstorming + gegenseitiges Code-Review), auch wenn das mehr Tokens kostet (4 günstige Agents > 1 teurer Agent). Merke: Der Funktions-Review (z.B. Monats-Delta-Logik der Bremse) wurde von Unraid/Switch echte Fehler finden lassen (row[0]-Basis-Wahl fehleranfällig → Vormonats-Basis-Fix). Allein hätte der Master diese Lücken evtl. nicht gesehen. PITFALL: „Es war Solo schneller" ist keine Ausrede — die Team-Gegenprüfung ist der vereinbarte Standard.