48 lines
2.9 KiB
Markdown
48 lines
2.9 KiB
Markdown
# 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. |