# Arbeitsweise — wer der User ist, wie hier gearbeitet wird, was wohin gehört

_Stand 24.09.2026. Gilt für jeden Agenten, der an diesem System arbeitet (Claude Code, OpenChamber/OpenCode,
Lucy auf der Box). Enthält seit 24.09. auch die frühere Grenzen-Landkarte._

## Der User (Hitonabi, „Commander")

- **Kein Software-Entwickler.** Er fasst keine Konsole an und macht keine Updates von Hand. Alles muss ohne ihn
  laufen oder per Knopf, Lucy oder Telegram bedienbar sein.
- **GUI-first:** klickbare Oberflächen statt Terminal. Sein Wunsch-Erlebnis: Aufträge verteilen, zusehen, Ergebnisse
  abnicken.
- **Produkt-Instinkt ernst nehmen:** Seine einfachen Fragen treffen oft den Kern. Vorschläge ernsthaft prüfen, nie
  abtun.
- **Sprache:** Deutsch, locker, direkt. Er schreibt oft roh und knapp. Lucy nennt ihn „Commander".
- **Nordstern (wörtlich):** „Das komplette System muss AUTONOM funktionieren — in 6 Monaten ohne Claude darf nichts
  brachliegen." Robustheit und Autonomie schlagen Features.

## Die Regeln

1. **Verifizieren vor Behaupten.** Vor jeder Aussage oder Änderung an der Box messen (SSH, Logs, `curl`, Messlauf),
   statt aus Doku, Gedächtnis oder Web zu schließen. Der Erzählung eines Agenten (auch der eigenen) nie glauben:
   Protokolle, Git-Stand und Messwerte sind Beweise.
2. **Scope challengen.** Ein Technik-Vorschlag (auch vom User) ist kein Bauauftrag: erst den Zweck klären, bei einer
   erkennbaren Fehlannahme kurz stoppen und warnen. Lehrbuch-Praxis ist nicht automatisch unser Fall.
3. **Branch, Prüftor, dann Merge.** Nie direkt auf `main` arbeiten. `bash deploy/pruefen.sh` muss grün sein.
   Claude darf bei grünen Prüfläufen selbst mergen und deployen (User-Entscheid 23./24.09.). Ein Direkt-Push auf
   `main` ohne Branch braucht ein ausdrückliches Ja.
4. **Security-Config nie ohne ausdrückliches User-Ja** (approvals, Tokens, ufw, sudoers, command_allowlist).
5. **Endgültig löschen nur per User-Klick** (Modelle, Dateien und Reste auf der Box). Vorschlagen ja, selbst löschen nein.
6. **Hermes-first vor Eigenbau.** Vor jedem Neubau prüfen, ob Hermes es kann (`hermes --help`, Config, Plugins).
   Hermes-Quellcode wird nie gepatcht oder geforkt.
7. **Alles reversibel:** Branch, Sicherung, Festhalten (Pin-Register). Nichts bauen, was Lucys Sprech-Latenz oder das
   warme Hirn gefährdet.
8. **Deutsch für alles, was der User sieht** (Oberfläche, Meldungen, Skills, Zusammenfassungen, Commit-Messages).
   Die erste Zeile einer Meldung sagt am besten, ob er etwas tun muss.
9. **Doku folgt dem Code.** Wer Verhalten ändert, zieht README, `docs/` und `deploy/jobs/README.md` im selben Branch
   nach (Pflegeregeln: [docs/README.md](../README.md)).

## Die Flächen — was gehört wohin

**Kern in einem Satz:** Box-Wart = Steuerpult (anschauen, klicken) · Lucy = Stimme und Gespräch · Hermes = das
Agenten-Fundament darunter (Quelle tabu) · Telegram = mobil melden · OpenChamber = Coding am PC.

| Fläche | Ort | Gehört hierhin | Gehört nicht hierhin |
|---|---|---|---|
| **Box-Wart** (MC2) | dieses Repo, `:9001` | Updates, Wächter-Hinweise, Modelle, Radar, Aufräumen, Dienste und Protokolle, Sicherungen, Einstellungen | ein Chat- oder Gesprächsfenster |
| **Homelab-Teil** (ab Phase 2) | gleiche Software als Container auf dem Proxmox-PC | Homelab-Geräte, deren Updates per Knopf, Erreichbarkeit | Dinge der KI-Box (die bleiben beim Box-Wart) |
| **Lucy** (Desktop-App) | Repo `F:\Coding Stuff\lucy` (Electron) | Sprache, Gespräch, proaktive Meldungen aus dem Briefkasten | Verwaltungs- und Update-Knöpfe |
| **Hermes** (Agent „Lucy" auf der Box) | `~/.hermes/` | Verhalten über `config.yaml`, `SOUL.md`, Skills, Plugins, MCP-Server | Änderungen am Quellcode in `~/.hermes/hermes-agent/` |
| **Telegram** | Hermes-Plattform | Meldungen empfangen, mit Lucy schreiben | eigene Oberflächen |
| **OpenChamber** | PC, Dateien unter `F:\Coding Stuff\…` | Coding; Modelle kommen von der Box über `:9001/v1` | Box-Verwaltung |
| **Android-App** (Phase 5) | noch offen | Push, Cockpit, Updates freigeben, Lucy per Sprache | – |

**Schnell-Entscheid „Ich will X bauen":**

- etwas anzeigen, verwalten, per Knopf auslösen → Box-Wart (Backend-Router dünn, Logik in `backend/services/`).
- reden, hören, proaktiv melden → Lucy.
- wie der Agent sich verhält (Werkzeug, Prompt, Fähigkeit) → Hermes-Config, `SOUL.md`, Skill, Plugin oder MCP-Server.
- etwas mobil melden → `deploy/notify.sh` (Telegram und Briefkasten in einem Aufruf).
- Wissen oder Doku ablegen → `docs/` in diesem Repo.

**Rote Linien:**

- Kein Chat im Box-Wart. Keine Update-Knöpfe in Lucy.
- Nie den Hermes-Quellcode ändern.
- Nie im Box-Checkout `~/mission-control-v2` von Hand ändern oder committen; neuer Code kommt nur über Gitea und
  `deploy/deploy.sh`.
- Keine Doku in Lucys Gedächtnis kippen: Es lernt selbst und ist kein Ablageort.

## Wissens-Orte

- `docs/` in diesem Repo = kuratierte Projekt-Wahrheit für alle Agenten (Index: [docs/README.md](../README.md)).
- `AGENTS.md` (hier und im Lucy-Repo) = verbindliche Bau-Regeln; OpenCode und Claude Code lesen sie selbst.
- `~/.hermes/memories/` = Lucys Gedächtnis; Hermes führt es selbst.
- Das Claude-Gedächtnis am PC = Arbeitsnotizen der Claude-Sitzungen, nicht verbindlich. Was bleiben soll, gehört hierher.