Update tenant lifecycle tooling and retire docs/process

docs/ops/backup-restore.md

@@ -75,7 +75,7 @@ Dieses Dokument beschreibt, was gesichert werden sollte, wie Backups geprüft we
   - DB‑Backup einspielen.
   - Medien‑Backups anbinden.
   - Eine Handvoll Tenants/Events kompletter durchklicken (Upload, Galerie, Admin‑Funktionen).
-- Ergebnisse im `docs/process/changes/`‑Ordner dokumentieren (z.B. „DR‑Übung 2026‑Q1“ mit Learnings).
+- Ergebnisse als bd-Issue dokumentieren (z.B. „DR‑Übung 2026‑Q1“ mit Learnings).
 
 ## 5. Verantwortlichkeiten
 

docs/ops/billing-ops.md

@@ -14,7 +14,7 @@ Dieses Runbook beschreibt, wie mit Zahlungsproblemen, Paddle/RevenueCat‑Webhoo
   - Modelle wie `Tenant`, `Packages`, `tenant_packages`, `event_packages`.
   - Services/Jobs zur Paket‑Zuweisung, Limit‑Berechnung und Nutzungstracking.
 
-> Details zur Architektur findest du in den PRP‑Kapiteln (Billing/Freemium) sowie in den TODO‑Dokumenten unter `docs/process/todo/paddle-migration.md` und `docs/process/todo/paddle-catalog-sync.md`.
+> Details zur Architektur findest du in den PRP‑Kapiteln (Billing/Freemium) sowie in den bd-Issues zur Paddle‑Migration und zum Katalog‑Sync.
 
 ## 2. Typische Problemszenarien
 
@@ -55,7 +55,7 @@ Dieses Runbook beschreibt, wie mit Zahlungsproblemen, Paddle/RevenueCat‑Webhoo
     - Notfall: manuelle Paket‑Anpassung (nur mit klar dokumentierter Begründung):
       - Paket in `tenant_packages` aktivieren/verlängern und `package_purchases` sauber nachziehen.
 5. **Dokumentation**
-   - Vorgang im Ticket / `docs/process/changes/*` festhalten, falls wiederkehrend.
+   - Vorgang im Ticket oder als bd-Issue festhalten, falls wiederkehrend.
 
 > TODO: Ergänze konkrete Tabellen-/Modellnamen und die relevanten Jobs/Artisan Commands, sobald Paddle/RevenueCat Migration finalisiert ist.
 

docs/ops/compliance-dsgvo-ops.md

@@ -81,7 +81,7 @@ Dieses Runbook beschreibt praktische Abläufe für Datenschutz‑Anfragen, Daten
 
 ## 5. Verbindung zu Security-Hardening
 
-Das Security‑Hardening‑Epic (`docs/process/todo/security-hardening-epic.md`) enthält mehrere Workstreams, die DSGVO‑relevant sind:
+Das Security‑Hardening‑Epic wird in bd-Issues gepflegt und enthält mehrere DSGVO‑relevante Workstreams:
 
 - Signierte Asset‑URLs statt direkter Storage‑Links.
 - Verbesserte Token‑/Auth‑Flows.

docs/ops/dr-storage-issues.md

@@ -68,7 +68,7 @@ Wenn keine Backups existieren, bleibt nur, die betroffenen Assets sauber als „
 - **Kapazitätsplanung**
   - Erkenntnisse über Medienwachstum nutzen, um frühzeitig auf größere Volumes/Buckets oder häufigere Archivierung umzusteigen.
 - **Dokumentation**
-  - Incident und Maßnahmen in `docs/process/changes/*` dokumentieren.
+  - Incident und Maßnahmen als bd-Issue dokumentieren.
   - Dieses Playbook aktualisieren, wenn neue Muster entdeckt wurden.
 
 Dieses Playbook ist eng mit `docs/ops/media-storage-spec.md` und `docs/ops/monitoring-observability.md` verknüpft. Nutze diese Dokumente für Detailinformationen zu Queues, Thresholds und Storage‑Targets.

docs/ops/dr-tenant-event-restore.md

@@ -89,7 +89,7 @@ Wenn ein kompletter Tenant versehentlich gelöscht wurde (inkl. Benutzer/Events)
   - Ehrlich kommunizieren, was passiert ist, was wiederherstellbar ist und welches Risiko ein Restore birgt.
   - Zeitrahmen und mögliche Einschränkungen klar benennen.
 - **Intern**
-  - Den gesamten Prozess in einem `docs/process/changes/*`‑Eintrag oder im Ticketing festhalten:
+  - Den gesamten Prozess in einem bd-Issue oder im Ticketing festhalten:
     - Was, wann, warum schief ging.
     - Welche Restore‑Schritte durchgeführt wurden.
     - Welche Verbesserungen künftig notwendig sind (z.B. bessere Schutzmechanismen, zusätzliche Bestätigungen beim Löschen).

docs/ops/guest-notification-ops.md

@@ -64,4 +64,4 @@ After enabling push:
 2. Trigger a host broadcast or upload-queue alert; confirm the browser shows a native notification and that the notification drawer refreshes without polling.
 3. Temporarily stop the upload workers to create ≥5 pending assets; re-run `storage:check-upload-queues` and verify guests receive the “Uploads werden noch verarbeitet …” message.
 
-Document any deviations in `docs/process/changes/` for future regressions.
+Document any deviations in a bd issue note for future regressions.

docs/ops/howto-tenant-package-not-active.md

@@ -82,7 +82,7 @@ Nur anwenden, wenn klare Freigabe vorliegt und Paddle die Zahlung eindeutig als
 3. Konsistenz prüfen:
    - Admin UI für Tenant öffnen und prüfen, ob Limits/Paketstatus jetzt korrekt angezeigt werden.
 4. Dokumentation:
-   - Den Vorgang im Ticket oder in `docs/process/changes/*` (falls wiederkehrend) dokumentieren.
+   - Den Vorgang im Ticket oder als bd-Issue (falls wiederkehrend) dokumentieren.
 
 ## 6. Kommunikation mit dem Tenant
 
@@ -92,4 +92,3 @@ Nur anwenden, wenn klare Freigabe vorliegt und Paddle die Zahlung eindeutig als
   - Ehrlich kommunizieren, dass laut Zahlungsprovider noch keine endgültige Zahlung vorliegt und welche Optionen es gibt (z.B. neue Zahlung, Klärung mit Bank/Kreditkarte).
 
 Dieses How‑to sollte dem Support/On‑Call helfen, den gängigsten Billing‑Fehlerfall strukturiert abzuarbeiten. Für tiefere Ursachenanalysen siehe `docs/ops/billing-ops.md`.
-

docs/ops/incidents-major.md

@@ -72,7 +72,7 @@ Nach einem SEV‑1/2 Incident:
 1. **Fakten sammeln** (Timeline, betroffene Tenants/Events, konkrete Auswirkungen).
 2. **Ursache** (Root Cause) möglichst präzise identifizieren – auch dann, wenn direkt „nur“ Symptome gefixt wurden.
 3. **Kurzfristige Maßnahmen** (Hotfixes, Konfig‑Anpassungen, zusätzliche Checks).
-4. **Langfristige Maßnahmen** – sollten als Epics/Tasks in `docs/process/todo/*` bzw. `docs/process/changes/*` landen (inkl. Link zum Incident).
+4. **Langfristige Maßnahmen** – als bd-Issues festhalten (inkl. Link zum Incident).
 5. **Dokumentation aktualisieren**
   - Relevante Runbooks (dieses Dokument, Public‑API‑Runbook, Storage‑Spec, Billing‑Ops, etc.) mit neuen Learnings ergänzen.
 

docs/ops/oncall-roles.md

@@ -45,7 +45,7 @@ Dieses Dokument beschreibt, **wer** im Betrieb wofür zuständig ist und **wie**
 
 - Verantwortlich für:
   - Entscheidungen bei Feature‑Flags, Rollbacks, Hotfix‑Releases.
-  - Priorisierung langfristiger Maßnahmen nach Incidents (`docs/process/roadmap.md`, `docs/process/todo/*`).
+  - Priorisierung langfristiger Maßnahmen nach Incidents (bd-Issues als Roadmap/Backlog).
 - Typische Aufgaben:
   - Teilnahme an Postmortems.
   - Freigabe von riskanteren Änderungen (z.B. große Migrations).

docs/ops/operations-manual.md

@@ -87,16 +87,12 @@ Zusätzlich gibt es kurze „How‑to“-Runbooks für häufige Supportfälle:
 
 Der Betreiber muss wissen, welche größeren Änderungen anstehen oder kürzlich live gegangen sind.
 
-- **Prozess-Hub**
-  - `docs/process/README.md` – erklärt Struktur von `changes/`, `todo/` und `roadmap.md`.
 - **Roadmap & Epics**
-  - `docs/process/roadmap.md` – Überblick über aktive Epics (z.B. Security Hardening, Paddle‑Migration, Streaming‑Uploads) und kürzlich abgeschlossene Themen.
-  - `docs/process/todo/security-hardening-epic.md` – Security‑Hardening‑Plan mit Bezug zu Ops (Signierte URLs, AV/EXIF, Monitoring‑Workstreams).
-  - Paddle‑Themen: `docs/process/todo/paddle-migration.md`, `docs/process/todo/paddle-catalog-sync.md`.
+  - Aktive Epics und offene Arbeitspakete werden in bd gepflegt (`bd list --status=open`, `bd ready`).
 - **Changes & Retro-Notizen**
-  - `docs/process/changes/*` – Session‑Notizen, Refactor‑Pläne und Lessons Learned (z.B. Checkout‑Refactor, Registrierung‑Fixes).
+  - Lessons Learned, Follow-ups und Incident-Maßnahmen werden als bd-Issues oder Issue-Notizen festgehalten.
 
-Als Betreiber lohnt es sich, bei größeren Deployments kurz in `roadmap.md` und den passenden `changes/*` zu schauen, um Seiteneffekte zu antizipieren.
+Als Betreiber lohnt es sich, vor größeren Deployments die offenen bd-Issues zu prüfen, um Seiteneffekte zu antizipieren.
 
 ## 7. Tests, Qualität & Releases