diff --git a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
index 4da4867..92761e5 100644
--- a/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
+++ b/docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md
@@ -327,3 +327,34 @@ die Wiederauffindbarkeit der Einstellung gehoert in die Anwenderdoku.
 
 Erst danach: Tor oeffnen + UI einblenden (v0.5.3). Alternativ bleibt Abbruch (Option C)
 jederzeit moeglich — v0.5.2 ist fuer alle Nutzer verhaltensgleich mit v0.5.1.
+
+## Nachtrag 2026-08-17/18: Safari sendete ungefiltert — behoben in v0.5.4
+
+Nach der Tor-Oeffnung (v0.5.3) meldete sorb: Filter wirkungslos, **Staerke 0-100 ohne jeden
+Unterschied**, sauberer Alleintest (Hoergeraet gemutet). Auf anderen Rechnern (Chromium-Familie)
+funktionierte derselbe Stand. Messungen mit einem lokalen Pruefstand (Playwright, echter
+LiveKit-`setProcessor`-Pfad, Sprachsignal mit Klick-Transienten) ergaben: Prozessor und Modell
+arbeiten korrekt — Sprache passiert, Klicks verschwinden.
+
+**Ursache:** LiveKits `setProcessor` tauscht den Sender-Track per
+`this.sender?.replaceTrack(processedTrack)`. Ist der Sender in dem Moment nicht am Track
+(Safari-Timing beim LocalTrackPublished-Event), wird der Tausch **stumm uebersprungen** — der
+Prozessor laedt seine 23 MB, meldet Erfolg, und das rohe Mikrofon bleibt auf der Leitung.
+Viertes Vorkommen des Sitzungsmusters "meldet Erfolg, ist aber blind", diesmal in Fremdcode
+(das `?.` verschluckt den Fehlschlag).
+
+**Zwei Irrwege der Diagnose, festgehalten weil lehrreich:**
+- Ein synthetischer Sinuston als "Stimme" liess den Filter wie einen Totalausfall aussehen —
+  fuer ein **Sprach**-Modell ist ein Ton Rauschen, die Daempfung bis zum Limit war korrektes
+  Verhalten am falschen Signal. Messsignale muessen dem Modell entsprechen.
+- Zwei Geraete im selben Raum machen jeden Hoertest wertlos (Tastatur akustisch und ueber das
+  zweite, ungefilterte Mikro hoerbar). Der brauchbare Alleintest: Hoergeraet **gemutet** mit
+  Kopfhoerer.
+
+**Fix (threadnet-call `fee9866`, embedded `.12`, ThreadNet-Web v0.5.4):** Nach dem Anhaengen
+wird verifiziert, dass der RTCRtpSender den gefilterten Track traegt — notfalls wird auf den
+Sender gewartet und der Tausch explizit erzwungen. Die Konsolen-Zeile weist den Zustand aus:
+`Sendepfad gefiltert: ja/NEIN`. Drei Tests decken die Sender-Faelle ab.
+
+**Test sorb 2026-08-18 (Safari als sendender Client): bestanden.** Damit ist der Filter auf
+beiden Engine-Familien nachgewiesen. Weiterhin offen und bewusst vertagt: Telefontest (mobil).