Document deployment workflow milestone

plan.md

@@ -453,3 +453,23 @@ zurückzubauen:
 **Nächster Schritt:** Content-Pipeline (Schritt 4) — Markdig + YamlDotNet,
 Services für Seiten/Termine, ICS-Endpoint. Parallel offen und unabhängig vom
 Code: Inhaltslage klären (Schritt 2, zeitkritisch).
+
+### Stand 2026-09-21 (vormittags)
+
+Deployment weiter ausgebaut und einmal komplett durchgespielt:
+
+- **Branch/PR-Workflow** etabliert: nie direkt auf `main`; Feature-Branch → Pull
+  Request in Gitea → Merge. Erstmals durchgeführt (PR #1).
+- **Zwei Build-Skripte** in `scripts/`: `dev-build.sh` (lokales Dev-Image, kein
+  Push — Dev-Stände bleiben aus der Registry raus) und `release.sh` (baut aus
+  `main`, taggt `:latest` **und** Commit-Kurz-SHA, pusht beide; bricht ab, wenn
+  nicht auf `main` oder Arbeitsverzeichnis unsauber).
+- **SHA-Tagging** ist damit Standard → Rollback möglich. Erster Release-Tag:
+  `:8643f2c`. Redeploy auf Unraid (Compose Down/Up) bewusst geübt, läuft.
+- `.gitattributes` erzwingt LF für `*.sh` (sonst scheitert der Shebang unter
+  Windows).
+
+Offen fürs nächste Mal (unverändert): Content-Pipeline (Schritt 4) und die
+zeitkritische Inhaltslage (Schritt 2). Deployment-Automatisierung per Gitea
+Actions (Schritt 10) ist der nächste optionale Deployment-Ausbau, aber nicht
+dringend — der Handbetrieb über `release.sh` reicht.