--- name: multi-agent-mesh description: "Multi-Agent Team: ZeroTier-Mesh + Webhook (A→Sat) + SSH (Sat→A). Failover-fähig, skalierbar für beliebig viele Agenten." version: 4.3.0 author: mehlzoerwer platforms: [linux, unraid, popos] models: default: mimo-v2-flash tools: step-3.5-flash background: nemotron-3-super fallback: minimax-m2.5 related_skills: [model-allocation] --- # Multi-Agent Mesh — ZeroTier + Webhook + SSH > ⚠️ **DIEDEN SKILL IN JEDER SESSION LADEN — VOR ALLEM ANDEREN!** > Ohne Startup-Check läuft A mit veralteten WireGuard-IPs und der Nutzer wird wütend. > Dieser Fehler trat mehrfach auf („Demenz-Agent\", „Alzheimer-Agent\"). **NIE WIEDER.** ```\n ┌─────────────┐\n │ Nutzer │\n │ (Telegram) │\n └──────┬──────┘\n │\n ZeroTier-Mesh (172.24.0.0/16) — jeder erreicht jeden\n │\n ┌──────────────────┼──────────────────┬──────────────────┐\n │ │ │ │\n ┌────▼────┐ ┌────▼────┐ ┌────▼────┐ ┌────▼────┐\n │VPSHermes│◄─────►│UnraidHermes│◄─────►│Switch │◄─────►│Laptop │\n │Hub/VPS │ SSH │Entwickl.│ SSH │Hermes │ SSH │Hermes │\n │.119 │ │TBD │ │Cockpit │ │Worker │\n └─────────┘ └─────────┘ └─────────┘ └─────────┘\n``` **Kommunikation:** | Richtung | Kanal | Wie | |----------|-------|-----| | Hub → Satellit | **SSH `chat -q`** | `hermes chat -q` per SSH (bevorzugt!) | | Hub → Satellit | **Webhook** | HMAC-signiert via ZT (Fallback) | | Satellit → Hub | **SSH** | Hub triggert curl auf Satellit | | Satellit → Satellit | **Hub-Relay** | Webhook→SSH | | Failover | ZeroTier | Mesh läuft weiter | > **Warum SSH für Sat→Hub?** Hermes blockt Shell/curl aus Webhook-Sessions. SSH umgeht das. Details in `references/debugging-lessons-2026-07-17.md`. --- ## Model-Konfiguration (OpenRouter) | Agent | Model | Tools | Background | Fallback | |-------|-------|-------|------------|----------| | A (Hub) | google/gemini-2.5-flash | step-3.5-flash | nemotron-3-super | minimax-m2.5 | | B (Sat) | google/gemini-2.5-flash | — | — | minimax-m2.5 | **Setze explizit in jedem Chat:** ```bash -hermes -m google/gemini-2.5-flash --provider openrouter --tools step-3.5-flash --background nemotron-3-super --fallback minimax-m2.5 ``` --- ## Lokaler Fallback (VPS-Ollama) Für **kostenfreien Notfall-Anker** (Budget erschöpft, API-Ausfall, einfache Anfragen) läuft auf dem VPS: | Modell | Größe | Kontext | Thinking | Status | |--------|-------|---------|----------|--------| | `deepseek-r1:7b` | 4.7 GB | **128k** | ✅ Reasoning | **Aktiv** | | `deepseek-r1:14b` | 9.0 GB | 128k | ✅ Reasoning | runtergeladen, ungetestet | Alle Agents fallen bei Bedarf auf `deepseek-r1:7b` zurück (64k+ Kontext, Thinking). Detailierte Budget-/Eskalationslogik: **`model-allocation`-Skill** (`config/agents.yaml`). ### 🔒 Ollama nur über ZeroTier (kein Internet) Ollama auf dem VPS ist **nur im ZeroTier-Mesh** erreichbar — nicht vom Internet: ```bash # Ollama bindet an ZT-IP Environment="OLLAMA_HOST=172.24.196.119:11434" # in /etc/systemd/system/ollama.service\n\n# UFW: nur ZT-Subnetz erlaubt (172.24.0.0/16)\nufw allow from 172.24.0.0/16 to any port 11434 comment 'Ollama ZeroTier Only'\n```\n\n**Zugriff für andere Agents:** `http://172.24.196.119:11434` --- ## ⚠️ Telegram nur auf dem Hub **Nur VPSHermes (Hub) hat Telegram-Zugang.** Remote-Agents haben Telegram aus ihrer Config entfernt. ### Telegram auf einem Remote-Agent deaktivieren ```bash # 1. Aus platform_toolsets entfernen sed -i '/^ telegram:/{N;d;}' ~/.hermes/config.yaml # 2. Telegram-Plattform-Konfiguration entfernen (falls vorhanden) sed -i '/^telegram:/{N;N;N;N;d;}' ~/.hermes/config.yaml # 3. Prüfen ob alles weg ist grep -c 'telegram' ~/.hermes/config.yaml # → 0 ``` **Konsequenz:** Remote-Agents sind »stille SSH-Agents« — sie kommunizieren nie von sich aus. Der Nutzer erreicht sie nur über VPSHermes (mich) oder direkt per SSH/VNC. --- ## Multi-Remote SSH Skills Sync Skills auf mehrere Remote-Agents gleichzeitig syncen (gleiches Passwort vorausgesetzt): ```bash # 1. Tar der benötigten Skills cd /root/.hermes/skills && tar czf /tmp/skills.tar.gz \ devops/model-allocation \ devops/zerotier-mesh-join \ autonomous-ai-agents/multi-agent-mesh # 2. Auf alle Remotes kopieren + entpacken for ip in 172.24.20.26 172.24.34.142 172.24.178.202; do sshpass -p 'PW' scp /tmp/skills.tar.gz user@$ip:/tmp/ sshpass -p 'PW' ssh user@$ip ' cd ~/.hermes/skills mkdir -p tmp-incoming && cd tmp-incoming tar xzf /tmp/skills.tar.gz cp -r . ~/.hermes/skills/ rm -rf ~/.hermes/skills/tmp-incoming echo "$ip: OK" ' done ``` ### Ollama-Provider auf Remote einrichten (per SSH) ```bash sshpass -p 'PW' ssh user@ ' echo -e "\nproviders:\n custom:\n api_key: ollama\n base_url: http://172.24.196.119:11434/v1" >> ~/.hermes/config.yaml ' # Testen sshpass -p 'PW' ssh user@ 'curl -s http://172.24.196.119:11434/api/tags | python3 -c "import sys,json; d=json.load(sys.stdin); print([m[\"name\"] for m in d[\"models\"]])"' ``` ### 🔑 Warum Message Bus statt curl? - Webhooks blocken curl aus Sessions - Satelliten können nicht direkt an Hub curl'n - Message Bus funktioniert über SSH+SCP + Cron Details: `references/message-bus-setup.md` --- ## ZeroTier (Netzwerk-Layer) | Eigenschaft | ZeroTier | |------------|----------| | Topologie | Mesh | | NAT-Traversal | ✅ | | Failover | Nur `active_hub` ändern | | Limits | 10 Nodes free (Headscale=∞ bei Bedarf) | | Setup | 2 Minuten | **Aktuelles Netzwerk:** `6ab565387a75e498` (mehlzoerwer's 1st network) | Agent | ZT-IP | Node-ID | Rolle | |-------|-------|---------|-------| | A | `172.24.196.119` | `adccde5dd6` | Hub | | B | `172.24.34.142` | TBD | Entwickler (ZorinOS 18) | | SwitchHermes | `172.24.20.26` | `3c1d63bbed` | Cockpit (ARM64, Switch Lite) | | LaptopHermes | `172.24.178.202` | `94334e18df` | Worker (RTX 2060) | ### ZeroTier-Setup (einmalig) ```bash # Auf JEDEM Agent: curl -s https://install.zerotier.com | sudo bash sudo zerotier-cli join 6ab565387a75e498 # Dann im Dashboard authorisieren: my.zerotier.com ``` **WireGuard** ist installiert aber deaktiviert als Fallback. --- ## SSH-Kanal (Satellit→Hub) Der Hub triggert curl per SSH auf dem Satelliten: ```bash sshpass -p '' ssh user@ \ "curl -s -X POST http://:8644/webhooks/collab-from-b \ -H 'Content-Type: application/json' \ -H 'X-Hub-Signature-256: sha256=...' -d '{\"topic\":\"...\"}'" ``` Funktioniert für ALLE Agenten — nur IP/User ändern sich. --- ## 📚 Task-Dateinamen-Schema (KONVENTION, NUTZERWUNSCH 2026-08-03) **Jeder Agent erkennt seinen Auftrag anhand seiner eigenen IP-Adresse.** Der Dateiname einer Task beginnt mit `JahrMonatTag.C.D.` wobei **C.D die letzten zwei Oktette der ZeroTier-IP des Ziel-Agenten** sind: ``` # Beispiel: UnraidHermes hat IP 172.24.34.142 → 34.142 20260803.34.142.HelloWorld.json # Beispiel: SwitchHermes 172.24.20.26 → 20.26 20260803.20.26.HelloWorld.json # Beispiel: LaptopHermes 172.24.178.202 → 178.202 20260803.178.202.HelloWorld.json ``` **Regeln:** - Dateiname = `JJJJMMTT.C.D.Auftragsbezeichnung.json` (kein separater Zeitstempel/ID — kein Duplikat) - `C.D` → letzte 2 Oktette der Ziel-ZT-IP (nicht der volle Name) - Der Poller eines Agents sucht nach `JahrMonatTag...*` - Erzeugung: `mesh-task-create.sh ` - IP-Auflösung: `/srv/work/registry.json` (Feld `zt_ip`) **Warum:** Ein Agent braucht nur seine eigene IP zu kennen, um seine Aufgaben zu sehen. Keine Zuordnungs-Tabellen nötig, Dateiname ist selbsterklärend. --- ## 📨 Message Bus — Dateibasierte Bidirektional-Kommunikation Wenn Webhooks nicht ausreichen (Satellit kann nicht curl'en), baut der Hub einen Datei-basierten Nachrichtenbus über SSH+SCP: ``` A ──scp──▶ B (sofort) B ──scp──▶ A (Cron alle 30s) ``` ### Setup (einmalig) ```bash # Auf BEIDEN Seiten: mkdir -p /root/.hermes/msg_bus/{inbox,outbox,sent} # Send-Script auf A: cat > /usr/local/bin/mesh-send-to-b << 'SCRIPT' #!/bin/bash TOPIC="${1:-test}"; MSG="${2:-ping}" FILE="/root/.hermes/msg_bus/outbox/$(date +%s)_${RANDOM}.json" cat > "$FILE" << JSONEOF {"from":"agent-a","to":"agent-b","topic":"$TOPIC","message":"$MSG","ts":"$(date -Iseconds)"} JSONEOF sshpass -p 'PW' scp "$FILE" user@:/tmp/msg_bus.json sshpass -p 'PW' ssh user@ "sudo mv /tmp/msg_bus.json /root/.hermes/msg_bus/inbox/" mv "$FILE" /root/.hermes/msg_bus/sent/ SCRIPT chmod +x /usr/local/bin/mesh-send-to-b # Send-Script auf B (gleiches Muster, ZT-IP tauschen) # Pull-Cron auf A (holt B's outbox alle 30s): # * * * * * /usr/local/bin/mesh-pull-from-b # * * * * * sleep 30; /usr/local/bin/mesh-pull-from-b ``` **Kein Hermes-Limit, kein Sandbox-Problem, keine Webhook-Antwort-Void.** ⚠️ **KRITISCH: Message Bus braucht Poll-Cron auf BEIDEN Seiten!** Ohne Poll-Job auf B liegen gesendete Nachrichten für immer in `/root/.hermes/msg_bus/inbox/`. ## ⚠️ ZeroTier-Netzwerk (einzige Quelle) 9. **Memory aktualisieren** 10. **collaboration-secrets.md** Referenz updaten > Fehler bei Schritt 4-6: Andere Agents verlieren Ollama-Zugriff. Reihenfolge einhalten. > Details: `references/message-bus-setup.md`, `references/message-bus-pitfalls.md` --- ## 💬 Chat-Regeln (NUTZER-PRÄFERENZEN) | # | Regel | |---|-------| | 1 | **Deutsch — ALLES.** | | 2 | **Inhalte DIREKT im Chat**, nicht nur als PDF/Datei. | | 3 | **Keine Rohdaten** (Terminal-Logs, Base64, Befehle) im Chat | | 4 | **Kurz & direkt, minimale Tokens** — 1-3 Sätze | | 5 | **Budget-bewusst** — keine teuren Modelle ohne Absprache | | 6 | **Mail (MX) ist heilig** — NIE verändern | | 7 | **Keine englischen Befehle/Infos** — alles auf Deutsch | --- ## 🧠 Brainstorming & ⭐ GRUNDGERÜST (NUTZERWUNSCH 2026-08-03) **Prinzip:** Mehrere "schwächere" Modelle brainstormen + gegenseitig Code prüfen = starkes Team. Rechen-Agenten: UnraidHermes (34.142, RAM) + LaptopHermes (178.202, RTX 2060). Master (VPSHermes) orchestriert, prüft final; Secrets bleiben beim Master. > **🔩 LOCHKARTEN-PRINZIP (NUTZER, 01.09.2026):** Keine Kompromisse. Wenn das Ergebnis einen Fehler enthält -> zurueck zu Schritt 1. Bug finden, neu starten. Kein "schnell fixen und weitermachen". Jeder Schritt MUSS bestanden sein, bevor der naechste beginnt. Das gilt fuer alle 7 Bausteine. **Das Grundgerüst für ALLE weiteren Arbeit:** 6 Kern-Bausteine in `templates/prompt-werkzeugkasten/` (00-index.md): | # | Baustein | Kern | |---|----------|------| | 1 | Briefing | Start: Ziel, Grenzen, nicht verhandelbar (max 5 Rückfragen) | | 2 | Framework | Lage/Optionen/Empfehlung/Umsetzung (+ Modi KRITIK, ALTERNATIVE, MATRIX, PLAN, STATUS) | | 3 | Umsetzung | iterative Schritte mit Feedback-Gates | | 4 | Lernen | Feedback-Revisions-Loop | | 5 | Erklären | einfach erklären + Deep-Dive + Perspektivwechsel | | 6 | Handoff | Stand für neuen Chat | | 7 | Problemlöser | belastbare Lösung + Gegenprüfung/Sparring gegen Halluzinationen (optional Anderer Agent als Gegenpart) | Der Ablauf: `Briefing → Framework → Umsetzung → (Lernen ↔ Erklären) → Handoff`. Einzelne Dateien je Baustein laden selbs-aus. **Problemlöser(7) greift parallel bei jeder Problem-/Entscheidungsdiskussion.** ## ⚠️ ÄNDERUNGSAUFTRAG-PFLICHT (NUTZERWUNSCH 2026-08-09, HART)** Bei **jeder** Änderungs- oder Bau-Anfrage des Nutzers (nach einem laufenden Prozess) gilt für den Master **verbindlich vor dem ersten Code-/Datei-/Config-Eingriff:** 1. **BRIEFING-GATE:** Ziel / Grenzen / offene Fragen klären (max. 5 Rückfragen an Nutzer ODER Sub-Agenten). 2. **PROBLEMLÖSER + TEAM-GEGENPRÜFUNG aktivieren:** Architektur/Ansatz per Framework(2) + ≥1 Rechen-Agent (Unraid/Laptop/Switch) als Gegenpart brainstormen & gegenprüfen lassen — **BEVOR** gebaut wird. Kein "schnell allein bauen". 3. **SUB-AGENTEN:** Arbeiten nur kleine, klar umrissene Teile ab. Bei Unklarheit SOFORT beim Master nachfragen statt eine Teil-Lösung abzuliefern, die der Master eh verwirft. Master gibt klaren Auftrag oder leitet Unklarheit an den Nutzer weiter. 4. **STRUKTUR-FREIGABE:** Erst wenn die (gegengeprüfte) Struktur steht → Umsetzung(3). 5. **POST-BAU-VERIFIKATION:** Nach dem Bau NEUES Team-Review (nicht erst, wenn der Nutzer einen Fehler findet). Bevor Ergebnis an Nutzer, MÜSSEN 3 Sub-Agenten reviewed haben (UnraidHermes + SwitchHermes + LaptopHermes). Ist das nicht möglich -> Agent-Ausfall-Regel gilt. **Keine Ausnahme** fuer "kleine Seiten" oder "schnelle Fixes". Master prueft zusaetzlich gegen echten Systemstand. **Kein Einzelkämpfer-Selbstlauf.** Das Grundgerüst ist Pflicht — bei Rückfall in "allein schnell bauen" hält sich der Master selbst an diese Liste. Nutzer ist "Dream-Team-Partner", Letztentscheider, aber soll nicht ständig Fehler finden müssen. **AGENT-AUSFALL-REGEL (hart, 01.09.2026):** | Phase | Regel | |-------|-------| | **1. Task STOPPEN** | Fällt ein Agent bei Schritt 1-3 aus, wird der laufende Task sofort gestoppt. Kein "dann bau ich eben ohne ihn weiter". | | **2. Agent REPARIEREN** | Master prüft + repariert den defekten Agenten **selbstständig und allein** — das ist sein Job als Admin. Diagnose, Fix, Test bis Agent wieder läuft. | | **3. NICHTS am Task bauen** | Während der Reparatur wird **nichts** am eigentlichen Task gebaut. Kein Code, kein Design, kein Inhalt. | | **4. NEUSTART bei Schritt 1** | Wenn Agent repariert ist → zurück zu **Schritt 1 (Briefing)**. Neuer Durchlauf von vorne. | | **5. "Halber Lauf" als Gewinn** | Haben die anderen Agenten schon Ergebnisse geliefert (Recherche, Design, Code)? Die sind **nicht verloren** — sie fließen als Vorarbeit in den Neustart ein. Spart Zeit, ohne den Prozess zu brechen. | **Kernregel:** *Reparieren ist Einzelkämpfer-Job des Masters. Bauen ist Team-Job. Niemals beides gleichzeitig.* **UNSICHERHEITS-REGEL (hart, 01.09.2026):** "Sollte", "könnte", "wahrscheinlich", "müsste" sind im Ergebnisbericht an den Nutzer **verboten**. Diese Wörter bedeuten: Ich habe nicht geprüft, ich rate. - Kann ich es selbst prüfen? → Prüfen, dann Ergebnis melden. - Kann ich es nicht selbst prüfen? (z.B. Video-Link funktioniert, visuelle Darstellung) → "Bitte überprüfen" sagen. Nicht raten, nicht hoffen. - Bin ich unsicher? → Zurück zu Schritt 1 des Grundgerüsts. ### 🎯 MASTER-DEFINITION (NUTZER, 01.09.2026) > Master heißt **Kontrolle aller laufenden Prozesse** anhand aller Regeln und Abläufe. Grundgerüst als **Taskplaner für Aufgaben**. Bei Fehlern im System muss Master eingreifen um das System wieder zu reparieren — aber niemals parallel zum Task bauen. ### 📎 AUDIT-PITFALL (2026-08-09, Team-Audit-Erkenntnis) Bei **Code-/Daten-Audits** an Sub-Agenten (Unraid/Switch/Laptop): Die haben **KEINEN Zugriff auf VPS-Dateien** (`/opt/urlaub/urlaub.db` u.a. liegen nur auf dem Master). Werden nur Pfade/Dateinamen in den Task gelegt, können sie nicht echt auditieren und laufen ins Leere (oder müssen erfinden). **Deshalb:** - **Relevante Inhalte in den Task einbetten** — konkrete Ausschnitte, Soll-IST-Werte, Ziellisten, Code-Fragmente, DB-Aggregate direkt in der Task-Beschreibung. - Nur **konzeptionelle/KRITIK-Audits** (Geographie, Plausibilität aus Wissen) gehen rein deskriptiv. - Verhaltensregel für Sub-Agenten: Ohne Zugriff auf die echten Daten **nicht erfinden** — konkret "kann ich ohne Daten nicht prüfen" zurückmelden (das tat UnraidHermes korrekt 09.08). - Master prüft Audit-Behauptungen **immer real gegen den Systemzustand** (curl/ss/DB), bevor Fixes übernommen werden (nie Agenten-Behauptung blind glauben). --- --- ## 🧠 LEBENSGESETZ (01.09.2026) > **Die Regeln sind nicht verhandelbar. Sie stehen über meiner Modell-Gewichtung, über "schnell liefern", über allem.** > > **"Schnell" bedeutet: sauber und fehlerfrei durch die Regeln gehen. Nicht: Regeln überspringen.** > > **Zeit ist immer egal. Es gibt keinen Grund, der einen Prozessbruch rechtfertigt.** > > **Jede Interaktion startet mit: Bin ich in den Regeln? Folge ich ihnen?** ## 🔒 ÄNDERUNGSSPERRE (01.09.2026) > **Diese Regeln werden niemals verändert, außer es gibt eine 2-fache Bestätigung vom User.** > > Der User bekommt als 2te Bestätigung **immer alle bisherigen + die vorgeschlagenen neuen Regeln präsentiert** und segnet sie dann ab. ## 📋 Kurzwort "Briefing" (NUTZERWUNSCH 2026-08-06) **"Briefing"** = das standardisierte Kontext-Übergabe-Dokument (Ziel / Entscheidungen / Begriffe / offene Fragen / Grenzen / nächste Schritte — wie beim Session-Handoff). Wenn der Nutzer "Briefing" sagt, ist genau diese Struktur gemeint — **ein Wort, große Wirkung**. Als Master jeweils prüfen: vollständig? Dann arbeiten; fehlt etwas → max. 5 Rückfragen. Aktuelles Briefing: `/srv/work/handoff_2026-08-06.md` --- ## 🔒 Update-Kontrollpolitik (NUTZERWUNSCH 2026-08-03) **"Stable im Betrieb, Updates kontrolliert"** — Hybrid statt Never-change-a-running-system. 0. **BACKUP-ONLY-REGEL (NUTZERWUNSCH 2026-08-08):** Bei JEDER System-/Config-Änderung zuerst Backup anlegen + Rückkehr-Option. Solange Backup/Rollback existiert, ist keine Freigabe nötig ("Master darf System verwalten"). Nichts zerstören ohne Wiederherstellungspfad. Konkret: vor Edit von config/scripts/etc → `cp datei datei.bak-$(date +%s)`; vor systemd-Änderung → aktuelle Unit-Datei sichern; vor Network/Firewall → Regelstand exportieren. 0b. **MAINTENANCE-vs-DATEN-KONVENTION (NUTZERWUNSCH 2026-08-08, ab morgen für ALLE im Mesh):** - **System-Wartung/Neustart/selbstbezogen** (Gateway-Restart, Aufräumen von Altdaten, rotierende Logs, systemd-Timer) → **Timer/Cron AUSSERHALB des Gateway** (läuft frei, fest terminiert). Hermes-Scanner blockt Agenten davon, sich selbst zu killen → für Restart IMMER systemd-Timer. - **Daten-/Inhaltsänderung (risikoreich)** → **im Schutz des Agenten-Terminals + Backup** (Hermes-Scanner bremst Gefährliches, Backup-Regel greift). - Faustregel: Je mehr das System sich selbst verwaltet → Timer außerhalb. Je mehr es Daten/Inhalte ändert → Schutz + Backup. 1. **Master (VPSHermes) ist die einzige Quelle für Skill-/Konfig-/Wissensbasis-Änderungen.** 2. **Agenten führen KEINE autonom Updates durch** (kein eigenmächtiges `apt upgrade`, kein Skill-Replace, kein Config-Tampering) — außer explizit auf Anweisung des Masters. 3. **Kontrollierte Rollout-Hierarchie:** - Phase 1: Änderung am Master entwickeln + testen - Phase 2: auf EINEN Test-Agent ausrollen, Stabilität bestätigen - Phase 3: erst dann auf ALLE Agenten - Rollback: Master kann jederzeit zurück (Backup vor Änderung) 4. **Wissens-Sync bleibt aktiv** (Skill/Wissensbasis/Registry unisono), damit die Agenten wissensmäßig auf Stand bleiben — aber die Dateien kommen aus einer Quelle (Master), nicht aus Agenten-Eigeninitiative. 5. Ausnahme: Vom Nutzer explizit beauftragte Updates/Distributionen. --- ## Referenzen - `templates/task-prompt-template.md` — **Standard-Prompt-Template für Agenten-Tasks**. - `templates/prompt-werkzeugkasten/00-index.md` — **🧰 GRUNDGERÜST (6 Kern-Bausteine)**: Briefing → Framework → Umsetzung → Lernen → Erklären → Handoff. - **PITFALL (2026-08-04):** Kontext für Agenten-Tasks IMMER in die Task-Beschreibung einbetten (`mesh-task-create.sh` Detail-Parameter 6). NIE als externe Datei unter `/srv/work/` ablegen — Agenten sehen per SSH/scp nur `/srv/work/tasks/`. Externes Briefing = Kontext-Halluzination. - `references/agent-hardware-specs.md` — Hardware-Spezifikationen aller Agents - `references/mesh-ssh-trigger-19-07-2026.md` — SSH `hermes chat -q` - `references/message-bus-setup.md` — Message Bus Setup - `references/message-bus-pitfalls.md` — Poll-Cron nötig |- `references/collaboration-secrets.md` — Secrets, SSH, ZT-IPs |- `/usr/local/bin/mesh-deploy-check.sh` — **3-Check-Liste vor jedem Deploy** (nginx-syntax + HTTP-Status + Python-Syntax) |- `/opt/lernerfolg-impressum-2026-09-01.md` — Lernerfolge aus dem Impressum-Projekt (8 Fehler + Prävention)