#0099: Tor deckt den ganzen Baum ab, Spiegel ist wieder gleichauf

Zwei Folgen des Merges, die im Issue noch als offen bzw. enger beschrieben waren.

Das Tor war am 19.08. bewusst auf apps/web beschraenkt, weil pnpm -r lint:types
an apps/desktop/electron-builder.ts abbrach und apps/web nie erreichte. Der
Fehler ist behoben (ThreadNet-Web:ac343e9), der Job prueft jetzt pnpm -r, und
desktop_linux/desktop_windows fuehren ihn ebenfalls als needs.

Der Gitea-Spiegel steht wieder auf 8ca03fe. ADR-0023 fuehrt ihn in den
Konsequenzen als ungeloest - die ADR bleibt unangetastet, eine angenommene ADR
wird nicht editiert; die Aufloesung steht hier.

Zwei meiner Diagnosen dazu waren falsch und stehen als solche im Text: weder
Paketgroesse noch ein Zeitlimit, sondern der Zustand des Ziel-Repos (9,6 GB
gegen 649 MB lokal) bei gleichzeitig voller Wurzelpartition.

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.