Fix operations report warnings

docs/WORKFLOW.md

@@ -124,14 +124,20 @@ Pflichtschritte beim Anlegen:
 1. Stack in Komodo aus Gitea anlegen
 2. `webhook_enabled` in Komodo aktivieren
 3. passenden Gitea-Webhook fuer die aktuelle Stack-ID anlegen
-4. Gitea-Hook gegen `http://komodo-core:9120/listener/github/stack/<stack-id>/deploy` pruefen
-5. einen Push oder Test-Delivery ausloesen und `last_status`/Komodo-Deploy pruefen
-6. Ausnahmen explizit dokumentieren
+4. Branch-Filter im Gitea-Hook auf den produktiven Branch setzen, aktuell `master`
+5. Gitea-Hook gegen `http://komodo-core:9120/listener/github/stack/<stack-id>/deploy` pruefen
+6. einen Push oder Test-Delivery ausloesen und `last_status`/Komodo-Deploy pruefen
+7. Ausnahmen explizit dokumentieren
 
 **Regel:** Kein neuer produktiver GitOps-Stack ohne funktionierenden Gitea->Komodo-Webhook. Bewusste Ausnahmen muessen im selben Aenderungsblock dokumentiert werden, inklusive Grund und Alternativ-Deploy-Weg.
 
 Der Standardfall nutzt den globalen `KOMODO_WEBHOOK_SECRET` aus der Komodo-Host-`.env`, ausser Komodo zeigt fuer den Stack explizit ein eigenes per-Stack-Secret.
 
+Der Gitea-Branch-Filter darf nicht leer oder `*` bleiben, solange der Komodo-Stack
+einen konkreten Repo-Branch erwartet. Sonst triggern Feature-/Arbeitsbranches alle
+Stack-Listener, Komodo verwirft sie mit `request branch does not match expected`
+und der Operations-Report bekommt unnuetzes Komodo-/Traefik-Rauschen.
+
 ### Ausnahme: Komodo-Zugangsmodell
 
 Komodo bleibt **bewusst** ohne zentrale Traefik-ForwardAuth-Middleware.