mehlzoerwer/mesh-configs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0eec139a9367415bfb46e16c01793483dc9a5959
mesh-configs/skills/autonomous-ai-agents/multi-agent-mesh/SKILL.md
T

401 lines
20 KiB
Markdown
Raw Blame History

---
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@<ZT-IP> '
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@<ZT-IP> '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 '<PW>' ssh user@<ZT-IP-SATELLIT> \
"curl -s -X POST http://<ZT-IP-HUB>: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.<mein-C>.<mein-D>.*`
- Erzeugung: `mesh-task-create.sh <ziel-agent> <auftrag> <typ> <prio>`
- 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@<ZT-IP-B>:/tmp/msg_bus.json
sshpass -p 'PW' ssh user@<ZT-IP-B> "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)
Reference in New Issue View Git Blame Copy Permalink