Add: Zabbix-Probleme Pflicht-Workflow in CLAUDE.md

Neuer Abschnitt mit strukturiertem 5-Phasen-Workflow (Analyse,
Klassifizieren, User-Vorlage, Abarbeitung, Rolling Documentation)
für systematische Zabbix-Problemlösung. Enthält Pitfalls zu
Macro-Naming, LLD-Triggern und Event-Schließung.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

CLAUDE.md

@@ -713,6 +713,85 @@ Nutze parallele Agenten für umfangreiche Scans und rekursive Entdeckung.
 - Explizite User-Anweisung nur aktuelle Aufgabe zu erledigen
 - User sagt explizit "nicht weiter scannen"
 
+### Zabbix-Probleme beheben: Pflicht-Workflow
+
+**BEVOR Zabbix-Probleme behoben werden, MUSS immer zuerst ein Plan erstellt und dem User vorgelegt werden.**
+
+#### Phase A: Analyse (parallel, ohne User-Interaktion)
+
+1. Alle offenen Probleme via API abfragen (`problem.get`)
+2. Trigger-zu-Host-Mapping erstellen (`trigger.get` mit `selectHosts`)
+3. Aktuelle Item-Werte prüfen (`item.get` — ist das Problem echt oder stale?)
+4. Trigger-Expressions lesen (für korrekte Macro-Namen)
+
+#### Phase B: Klassifizieren und Liste erstellen
+
+Jedes Problem in eine Kategorie einordnen:
+
+| Kategorie | Beschreibung | Aktion |
+|-----------|-------------|--------|
+| **STALE** | Trigger disabled, Event offen | `manual_close` setzen + Event schließen |
+| **THRESHOLD** | Wert normal, Schwellwert zu niedrig | Host-Macro erstellen/anpassen |
+| **ECHT** | Tatsächliches Problem | SSH-Intervention oder manuelle Aktion |
+| **TEMPLATE-NOISE** | Trigger passt nicht zum Host-Typ | Trigger disablen oder Macro-Filter |
+
+#### Phase C: Nummerierte Liste dem User vorlegen
+
+**PFLICHT:** Dem User eine nummerierte, nach Priorität sortierte Liste präsentieren:
+
+```
+# | Host | Problem | Kategorie | Geplante Aktion
+1 | srvhost04 | Disk 95% | ECHT | SSH: Cleanup LXC 101
+2 | srvdocker02 | Agent down | ECHT | SSH: Service starten
+3 | gw-st01 | /mnt/share_new | STALE | API: FS-Macro + Event schließen
+...
+```
+
+Der User entscheidet:
+- Welche Punkte bearbeitet werden
+- In welcher Reihenfolge
+- Ob SSH-Aktionen gewünscht sind
+
+#### Phase D: Punkt für Punkt abarbeiten
+
+- Nur nach User-Freigabe ausführen
+- Parallele Agenten für unabhängige API-Fixes
+- Nach jedem Punkt: Ergebnis melden
+- Ergebnis-Verifikation via `problem.get`
+
+#### Phase E: Rolling Documentation aktualisieren (PFLICHT)
+
+Nach JEDER Zabbix-Problem-Session:
+
+1. **Host-Dateien aktualisieren** (`infrastructure/hosts/[host].md`):
+   - Abschnitt "Wiederkehrende Probleme" anlegen/ergänzen
+   - Datum, Problem, Lösung, ob wiederkehrend
+   - Beispiel:
+     ```markdown
+     ## Wiederkehrende Probleme
+
+     | Datum | Problem | Lösung | Wiederkehrend |
+     |-------|---------|--------|---------------|
+     | 2026-01-29 | Memory >90% | Macro {$MEMORY.UTIL.MAX}=95 | Ja (normal für Workload) |
+     | 2026-01-29 | Swap <50% free | Macro {$SWAP.PFREE.MIN.WARN}=10 | Ja (normal) |
+     ```
+
+2. **Zabbix `copilot-instructions.md` aktualisieren**:
+   - Neue Pitfalls dokumentieren
+   - Macro-Namen-Korrekturen festhalten
+   - Patterns für zukünftige Problemlösung
+
+3. **`dependencies.md` prüfen** — Falls neue Abhängigkeiten entdeckt
+
+#### Wichtige Pitfalls
+
+- **Macro-Namen exakt prüfen!** Trigger-Expression lesen, nicht raten.
+  Beispiel: `{$PVE.MEMORY.PUSE.MAX.WARN}` ≠ `{$PVE.MEM.PUSE.MAX.WARN}`
+- **LLD-Trigger:** Discovered Triggers können nicht direkt `manual_close` gesetzt werden.
+  Stattdessen: Template Trigger-Prototyp updaten → LLD re-run (`task.create` type 6)
+- **Event schließen:** Erst `manual_close=1` auf Trigger setzen, dann `event.acknowledge` action=1
+- **curl | jq kann leere Ausgabe liefern:** Immer erst in Datei speichern, dann lesen
+
 ### Skills-Referenz
 
 | Skill | Zweck |