diff --git a/docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md b/docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md
index 1b15d05..4474590 100644
--- a/docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md
+++ b/docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md
@@ -404,3 +404,62 @@ Rückhebel bleibt der Tag-Revert auf `v0.5.4`.
 **Alle vier Schritte dieses Issues sind beantwortet**; Schritt 4 ist wie in ADR-0022
 vorhergesagt gegenstandslos geworden. Das nächste Upstream-Update ist ein gewöhnlicher
 Merge.
+
+## Nachtrag 2026-08-20 — zwei Folgen des Merges, die noch offen waren
+
+### Das Typprüfungs-Tor deckt jetzt den ganzen Baum ab
+
+Der Abschnitt oben beschreibt den Job so, wie er am 19.08. entstand: `pnpm --dir
+apps/web lint:types`, bewacht `docker_web`. Beides war eine Notlösung mit Grund —
+`pnpm -r lint:types` brach an `apps/desktop/electron-builder.ts:237` ab
+(`config.dmg` möglicherweise `undefined`) und erreichte `apps/web` nie. Das Tor eng zu
+fassen war die einzige Möglichkeit, es überhaupt scharf zu stellen.
+
+Behoben in `ThreadNet-Web:ac343e9`: Der Desktop-Fehler ist weg — mit `!` statt mit
+einer Zeile in Upstreams `Configuration`-Interface, weil der Kommentar direkt darüber
+genau diese Änderung vermeiden will, um bei Upstream-Merges keinen Konflikt zu
+erzeugen. Damit prüft der Job `pnpm -r`, und `desktop_linux` sowie `desktop_windows`
+führen ihn ebenfalls als `needs`. Vorher hätte ein Typfehler im Desktop-Code weiterhin
+ein Paket erzeugt — dasselbe Loch, das für das Web-Image geschlossen wurde.
+
+⚠️ Beim Nachweis wäre mir fast eine Lücke durchgegangen: `element-desktop` taucht in
+der nx-Erfolgsliste **nicht** auf, weil sein `lint:types` aus fünf einfachen
+`tsc`-Läufen besteht statt aus einem nx-Target. Erst die Gegenprobe — Fehler wieder
+einsetzen, `pnpm -r` läuft auf Rückgabewert 1 mit der Meldung außerhalb von
+`node_modules` — belegt die Abdeckung. Ohne sie hätte hier eine Zusage gestanden, die
+nur eine Vermutung war.
+
+### Der Gitea-Spiegel ist wieder gleichauf
+
+[ADR-0023](../adr/0023-fremdhistorie-von-der-git-hygiene-ausnehmen.md) führt in den
+Konsequenzen „Nicht gelöst: Der Gitea-Spiegel … Eigener Vorgang". Das ist seit
+2026-08-20 erledigt; die ADR bleibt unangetastet, weil eine angenommene ADR nicht
+editiert wird.
+
+Der Spiegel-Worker scheiterte reproduzierbar am Erstschub (70.269 Commits). Der Weg
+dorthin ist lehrreicher als das Ergebnis, weil **zwei** Diagnosen falsch waren:
+
+| Annahme | Widerlegt durch |
+|---|---|
+| „zu große Pakete, also stückeln" | ein Push mit **6 Objekten** scheiterte ebenfalls |
+| „festes Zeitlimit von ~60 s" | ein Push über **95 s** lief durch |
+
+Die tatsächliche Ursache war der Zustand des Ziel-Repos: **9,6 GB auf Gitea gegen
+649 MB lokal**, aufgebläht durch die Rückstände jedes abgebrochenen Pushs — meine
+eigenen eingeschlossen. Jeder Push zahlte die Erreichbarkeitsprüfung über diesen
+Haufen, unabhängig von seiner Nutzlast. Verschärfend lief die Wurzelpartition dabei
+auf **100 %** voll, wodurch auch `git gc` nicht mehr durchlaufen konnte — die
+Reparatur scheiterte an dem Zustand, den sie beheben sollte.
+
+Nach Aufräumen und sauberem Repack (Repo auf 451 MB) liefen die restlichen Etappen
+durch. Auffällig dabei: Derselbe Schritt scheiterte im ersten Versuch nach 3.734
+Sekunden und gelang im zweiten in **einer** Sekunde. Bei sporadischer Serverlast ist
+**wiederholen** die richtige Antwort, nicht weiter verkleinern — mit Halbieren wäre
+der Lauf nie fertig geworden.
+
+Gegengeprüft: Gitea `main` = `8ca03fe`, identisch mit git.lab, alle vier
+`v0.6.0`-Tags übertragen, Hilfszweig entfernt.
+
+**Die Lehre für den nächsten großen Push:** Erst den Zustand des Ziels messen
+(`count-objects -vH`, freier Platz), dann übertragen. Ein Spiegel, der seit Monaten
+nie repackt wurde, ist kein passives Ziel.