docs: update betrieb/upgrades

betrieb/upgrades.md

@@ -2,7 +2,7 @@
 title: Upgrades
 description: Stack aktualisieren — alles über GitOps
 published: true
-date: 2026-08-13T20:27:33.029Z
+date: 2026-08-13T22:14:08.333Z
 tags: 
 editor: markdown
 dateCreated: 2026-08-13T20:27:33.029Z
@@ -23,3 +23,26 @@ Der Stack wird per **GitOps** aktualisiert — nichts von Hand am Cluster, alles
 2. Version im Repo anheben, committen, nach git.lab pushen.
 3. `flux reconcile` beobachten; Pods + Health prüfen.
 4. Bei Problemen: Commit zurückrollen — GitOps macht das Rollback trivial.
+
+
+## Stack-Anpassungen & Fork-Porting
+
+Beim Upgrade der zugrundeliegenden Element-/Synapse-Versionen müssen **unsere Anpassungen
+mit**. Wo sie liegen:
+
+| Komponente | Basis | Änderungen dokumentiert in |
+|---|---|---|
+| **ThreadNet Web** (Element-Web-Fork) | Element Web/Desktop `1.12.17` | `ThreadNet-Web:docs/axion1337-fork.md` · [/betrieb/element-customization](/betrieb/element-customization) |
+| **threadnet-call** (Element-Call-Fork) | Element Call `0.19.2` (via `emmick4/element-call` `livekit`) | `threadnet-call:docs/axion1337-fork.md` · [/betrieb/element-call](/betrieb/element-call) |
+| **Synapse & Stack** | ESS `v26.4.0` — **kein** Code-Fork, nur Config/Module | gitops (`synapse-values.yaml`, `clamav_spam_checker.py`, …) + die jeweiligen Betriebsseiten |
+
+**Ablauf beim Element-Upgrade eines Forks:**
+1. Ziel-Upstream-Version wählen; das jeweilige `axion1337-fork.md` ist die **Liste dessen,
+   was re-appliziert/geportet werden muss**.
+2. Rebase/Merge auf die neue Version; die dort genannten **kritischen Dateien** zuerst
+   prüfen (dort sitzt die Merge-Reibung).
+3. Bauen, Image nach Gitea publizieren, im gitops-Stack die Version anheben (siehe oben).
+
+**Synapse/Stack ist kein Fork:** unsere Eingriffe sind GitOps-Config (Room-Policies,
+ClamAV-Modul, Backups, TURN-Rotation …) und wandern mit dem ESS-Chart-Upgrade automatisch
+mit — dokumentiert auf den jeweiligen Betriebsseiten, nicht als Code-Diff.