add-on: Operations checklist

[Fluory]

Checklist from the control center (Entwicklungsplan/templates/addons/betrieb.md, fluory-system 2.1), activated in project-profile.yml. Tick items as they are implemented; each item is proven in the PR that implements it. The checklist text is copied verbatim (German).

---

Add-on: Betrieb (bei Nutzern oder geschäftskritischer Nutzung)

• Strukturierte Logs (ohne Personendaten/Secrets)
• Monitoring: Erreichbarkeit + die 2–3 wichtigsten Kennzahlen
• Alert, wenn das System down ist oder Fehlerrate steigt
• Runbook in docs/technical/operations.md: Start, Stopp, häufigste Störungen, Rollback
• Nach jedem Deployment: Monitoring kurz prüfen (Teil des Release-Flusses)
• Incident-Ablauf festgelegt: reproduzieren/validieren → Schaden einschätzen → Sofortmaßnahme
  (Rollback, Feature-Flag, Limit, Sperre) → Issue mit Fakten → Fix auf eigenem Branch →
  Regressionstest → Postmortem nur bei relevantem Vorfall. Kein Auto-Merge bei Vorfällen.
• Bei personenbezogenen Daten: 72h-Meldepflicht (DSGVO Art. 33) als fester Schritt im
  Incident-Ablauf – Prüffrage „Sind Personendaten betroffen?" + Kontaktweg zur Aufsichtsbehörde
• Support-/Feedback-Weg, sobald Dritte das System nutzen: ein klarer Kanal (Button,
  Formular oder E-Mail), dessen Meldungen als priorisierbare Issues bei euch ankommen
• Kosten im Blick: laufende Dienste (Cloud, LLM, Storage, Egress) mit Budget-Alert
  beim Provider; Kostenübersicht als Abschnitt in der Architekturkarte (Vendor-Tabelle)
• Hotfix-Pfad (ab Produktivbetrieb): Hotfix-Issue mit Label hotfix → Branch hotfix/<thema>-<nr>
  → kleinstmöglicher Fix + Regressionstest → PR sofort → verify → menschliche Freigabe → Merge/Deploy
  → Smoke-Test → Nacharbeit binnen 24 h. Abkürzen darf man Spec/Roadmap/volle Doku –
  nie: Issue, Branch+PR, Freigabe, Regressionstest, Verify-Nachweis, Klartext.
• Ab P2: Business Continuity einmal durchdenken – was passiert bei Konto-, Anbieter-
  oder Cloud-Ausfall? (Zugriffe, Backups außerhalb, dokumentierter Wiederanlauf)