mehlzoerwer/mesh-configs

Fork 0

Files

T

root 4b65134f8c Initial: Mesh-Configs vom 03.09.2026 01:23

2026-09-03 01:23:55 +02:00

20 KiB

Raw Blame History

name, description, version, author, platforms, models, related_skills

name

description

version

author

platforms

models

related_skills

multi-agent-mesh

Multi-Agent Team: ZeroTier-Mesh + Webhook (A→Sat) + SSH (Sat→A). Failover-fähig, skalierbar für beliebig viele Agenten.

4.3.0

mehlzoerwer

linux

unraid

popos

default	tools	background	fallback
mimo-v2-flash	step-3.5-flash	nemotron-3-super	minimax-m2.5

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:

-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:

# 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):

# 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)

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)

# 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:

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)

# 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)

Memory aktualisieren
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:

BRIEFING-GATE: Ziel / Grenzen / offene Fragen klären (max. 5 Rückfragen an Nutzer ODER Sub-Agenten).
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".
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.
STRUKTUR-FREIGABE: Erst wenn die (gegengeprüfte) Struktur steht → Umsetzung(3).
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.

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.

Master (VPSHermes) ist die einzige Quelle für Skill-/Konfig-/Wissensbasis-Änderungen.
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.
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)
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.
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)

20 KiB Raw Blame History