Initial: Mesh-Configs vom 03.09.2026 01:23

2026-09-03 01:23:55 +02:00
commit 4b65134f8c
797 changed files with 146197 additions and 0 deletions
@@ -0,0 +1,48 @@
+# 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.