3.7 KiB
AGENTS.md — Mission Control 2.0
Projekt-Geschmack für Coding-Agenten (Kilo Code, Claude Code lesen diese Datei).
Kurz gehalten, nur die Wahrheiten, die man sonst schmerzhaft lernt. Details: README.md, docs/.
Was das ist
Lokaler Local-AI-Stack für die Box (Bosgame M5, Strix Halo, Vulkan/RADV). Schichten:
Engine (llama-swap) · Builtin-Routing-Gateway (model: auto) · MC2 (FastAPI + React/shadcn) ·
Hermes-Agent (das autonome Gehirn "Lucy"). Backend Python (Box läuft Python 3.14), Frontend Vite/React/shadcn/Tailwind.
WICHTIG: Alle alten Dienste wie mem0, governor oder eigenleben sind komplett gelöscht. Hermes ist das EINZIGE "Gehirn" und läuft autonom. Es nutzt keine alte Mem0-DB, sondern sein eigenes System.
Sprache (nicht verhandelbar)
- Alles User-Sichtbare ist Deutsch: UI-Texte, Fehlermeldungen, Update-/Radar-Meldungen, Skills, LLM-Summaries, Commit-Messages, Code-Kommentare.
- Hermes' INTERNE System-Prompts bleiben Englisch (fremde Software, wir forken sie nicht). Antwort-Sprache ≠ Prompt-Sprache — Deutsch kommt aus SOUL.md, nicht aus den Tool-Prompts.
Build & Deploy (die häufigste Falle)
frontend/distWIRD committet. Auf der Box läuft KEIN Node-Build; das Backend liefert die gebauten Assets direkt aus. Nach jeder Frontend-Änderung:cd frontend && npm run build, dann das neuefrontend/distmit-committen. Vergessen = Box zeigt alten Stand. (Ausnahme:frontend/dist/avatar.vrmist bewusst nicht in git — siehe.gitignore.)- Deploy macht
git reset --hard origin/main(deploy/deploy.sh). Heißt:mainmuss vor dem Deploy auf Gitea liegen, und uncommittete Box-Änderungen gehen verloren (Absicht). - Nie direkt auf
mainarbeiten. Immer Branch (wartung/...), Gate grün, dann Merge/Deploy.
Agentic IDE & Vibe Coding
- Zero Middle-Layers: Coding passiert zu 100% lokal auf dem Dev-PC in der OpenCode Desktop IDE.
- Es gibt keinen Zed-Workflow, keine OpenCode-CLI-Mittelschicht und keinen Governor mehr.
- Der Agent in OpenCode Desktop nutzt via MCP (
.agents/mcp_config.json) die API der Box (:9001/v1), um autonom Projekte zu bauen. - Mix-Ansatz beim Testen: Der Agent testet lokal. Vor dem Push muss er prüfen, ob das Gitea-
VERIFY-Skript fehlerfrei durchläuft.
Zeit & Umgebung
- Box = Ubuntu, läuft in
Europe/Berlin(seit 03.07.2026; vorher UTC). Dev-PC = Windows. Naive/lokale Zeiten immer überMC_LOCAL_TZ(=Europe/Berlin) auflösen, niedatetime.now()ohne TZ annehmen (siehebackend/services/reminders.py).
Backend-Konventionen
- Router unter
backend/routers/(APIRouter(prefix="/api")), Logik inbackend/services/(Single Source of Truth — Router bleiben dünn). Beispiel-Lehre: Restart-Allowlist lebt NUR inservices.maintenance(System-Dienste viasudo -n, User-Dienste viasystemctl --user); keine zweite Allowlist in einem Router duplizieren. - Gate vor Commit:
python -m py_compile <geänderte .py>muss durchlaufen. - Wartung ist sudo-frei gedacht (systemctl --user). Wo doch sudo nötig ist (llama-swap =
System-Dienst), sauber über die NOPASSWD-Whitelist /
password_required-Rückgabe, nie hart failen. - Lokal (Windows) müssen Box-Shell-Befehle harmlos fehlschlagen statt zu crashen.
Grenzen (Verdikt, eingehalten)
- Hermes-Quellcode nie selbst patchen (Fork verboten). Config/Deps ja, Code-Umbau nein.
- Security-Config (approvals, Tokens, ufw, command_allowlist) nie ohne explizites User-Ja.
- Alles reversibel halten: Branch + Backup + Pin.
Gitea
Remote = Hitonabi/mission-control-v2. Auth ist flatterhaft → Push mit Retry, nur über
PowerShell/GCM. Neue Repos per API anlegen. Kein GitHub.