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:

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:

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.

2.9 KiB Raw Blame History