Doku: Merge-Risiko praeziser fassen - Art des Eingriffs, nicht Umfang

Meine Aussage "ClamAV kostet mehr als das gesamte Branding zusammen" war so nicht haltbar: gemessen sind es ~130 zu ~104 Zeilen, der groesste Einzelpatch ist sogar Branding (HelpUserSettingsTab.tsx, 71 Zeilen). Der Unterschied liegt woanders: Branding-Patches stehen am Rand und sind nach einem Umbau wiederfindbar, ClamAV-Patches stehen mitten in Entschluesselungs- und Fehlerpfaden. Dazu der eigentliche Haken - verschiebt Upstream die viewmodels/-Dateien, entsteht kein Konflikt, die Zeilen sind schlicht weg und Git meldet nichts. Deshalb ist dort ein Funktionstest maszgeblich, nicht die Merge-Ausgabe. Refs axion1337.chat/ThreadNet-Web#7
2026-08-06 12:00:00 +00:00
parent 9ac56d671b
commit 965c456dee
1 changed files with 26 additions and 5 deletions
@@ -101,11 +101,32 @@ Updates.
 - `apps/web/src/components/views/messages/MImageBody.tsx`, `MAudioBody.tsx`
 - `apps/web/src/viewmodels/message-body/FileBodyViewModel.ts`, `VideoBodyViewModel.ts`

-⚠️ **Die zweite Gruppe ist die teure.** Element baut die Medien-Anzeige gerade auf
-MVVM um (`docs/MVVM.md`, `docs/MVVM-v1.md`) — die beiden `viewmodels/`-Dateien
-existierten in älteren Ständen gar nicht. Genau dort, wo wir eingegriffen haben,
-bewegt sich Upstream also aktiv. Ein Update wird an ClamAV mehr Arbeit machen als am
-gesamten Branding zusammen.
+### Nicht der Umfang entscheidet, sondern die Art des Eingriffs
+
+Gemessen in geänderten Zeilen nehmen sich beide Gruppen wenig: **ClamAV ~130 Zeilen,
+Branding ~104**. Der größte Einzelpatch ist sogar Branding
+(`HelpUserSettingsTab.tsx`, 71 Zeilen). Wer nur zählt, hält beide für gleich teuer.
+
+Sie sind es nicht, und der Grund ist die Art des Eingriffs:
+
+- **Branding-Patches stehen am Rand.** Ein zusätzlicher Default in `SdkConfig.ts`,
+  ein `<link>` im `<head>`, ein `<li>` in einer Settings-Liste. Wird die Datei
+  umgebaut, sieht man sofort, wo das eigene Stück wieder hin muss.
+- **ClamAV-Patches stehen mittendrin** — in Entschlüsselungs- und Fehlerpfaden der
+  Medien-Pipeline, verschränkt mit Upstream-Logik. Ein geänderter Kontrollfluss
+  bedeutet nicht „Konflikt lösen", sondern „neu verstehen".
+
+⚠️ **Und der eigentliche Haken: `viewmodels/`.** Element baut die Medien-Anzeige
+gerade auf MVVM um (`docs/MVVM.md`; v1 ist dort bereits als deprecated markiert —
+der Umbau läuft also schon in zweiter Runde). `FileBodyViewModel.ts` und
+`VideoBodyViewModel.ts` gab es in älteren Ständen gar nicht. Unsere Änderung darin
+ist mit je 6 Zeilen winzig — aber wenn Upstream diese Dateien verschiebt, umbenennt
+oder auflöst, entsteht **kein Konflikt**: die Zeilen sind einfach weg, und Git meldet
+nichts. Das ist gefährlicher als ein Konflikt, weil es stillschweigend passiert.
+
+Praktische Folge: Nach einem Upstream-Update ist an ClamAV nicht die Merge-Ausgabe
+maßgeblich, sondern ein **Funktionstest** — eine verschlüsselte Datei senden und eine
+abgelehnte empfangen. Steht so auch in Abschnitt 2.

 ### Was daraus für künftige Änderungen folgt