Document final borg backup rollout status

ops/borg-ui/BACKUP_AUDIT_STATUS_QUO.md

@@ -132,9 +132,21 @@ Das betrifft insbesondere:
 ### Weiterhin offen trotz erfolgreichem Lauf
 
 - `komodo-mongo`-Dump bleibt unbestätigt
-- Dump-Automatisierung vor dem Borg-Lauf fehlt noch
 - der Scope kann später noch bewusst verschlankt werden, ist aber aktuell funktionsfähig
 
+## Aktueller Abschlussstand
+
+Seit dem ersten erfolgreichen Lauf wurde der Zielzustand weiter konkret umgesetzt:
+
+- Die Pre-Backup-Dumps laufen host-seitig über Unraid User Scripts / Host-Cron.
+- Der Dump-Zielpfad wurde nach `/mnt/user/backups/borg/dumps` verlagert.
+- Der neue Zielpfad ist im laufenden `borg-ui`-Container sichtbar.
+- Ein Restore-Smoke-Test war erfolgreich:
+  - `postgresql17-globals.sql` wurde wiederhergestellt
+  - `gitea.db` wurde wiederhergestellt
+- `ntfy` und Uptime Kuma sind für Borg-Monitoring eingerichtet.
+- `Firefly`, `Firefly-Fints` und `Semaphore` wurden aus Git und vom Homelab entfernt.
+
 ## Was aktuell bewusst nicht als Problem gewertet wird
 
 - `photos/family_archive` liegt fachlich korrekt im Share `photos` und wird durch Borg gesichert.
@@ -155,11 +167,6 @@ Das ist kein Strukturfehler, sondern eine normale Trennung zwischen Nutzdaten un
    - Dump-Pfad im Skript vorhanden
    - Erfolg noch nicht bestätigt
 
-2. **Automatisierung**
-   - Dumps wurden manuell erzeugt
-   - die festgelegte Zielrichtung ist jetzt host-seitig über Unraid User Scripts / Host-Cron
-   - eine saubere Pre-Backup-Automatisierung ist noch nicht final eingebunden
-
 ## Vorläufiges Audit-Fazit
 
 Der aktuelle Borg-Scope ist **nicht chaotisch**, sondern bereits deutlich strukturierter als ein pauschales Backup von `/mnt/user/appdata`.
@@ -175,19 +182,12 @@ Fachlich sieht das Bild aktuell so aus:
 Das eigentliche Restproblem ist aktuell **nicht** die Share-Struktur, sondern:
 
 - einzelne noch offene Dump-Kandidaten
-- fehlende Automatisierung
 
 ## Nächste sinnvolle Schritte
 
-1. Den erfolgreichen ersten `critical_infra`-Lauf als bestätigt festhalten und nur die verbleibenden Restpunkte weiterverfolgen.
+1. `komodo-mongo` bei Gelegenheit separat prüfen und nur dann erweitern, wenn der tatsächliche Bedarf bestätigt ist.
-2. Die offenen Restpunkte gegen den Audit halten:
+2. Das automatische Borg-Fenster beobachten und nach den ersten geplanten Läufen nur noch auf Warnungen reagieren.
-   - `komodo-mongo` weiterhin als unbestätigt markieren
+3. Optionale spätere Scope-Verschlankung nur bewusst und nicht ad hoc vornehmen.
-   - Dump-Automatisierung als nächsten echten Umsetzungsblock behandeln
-   - dafür host-seitig über Unraid User Scripts / Host-Cron arbeiten, nicht über Borg-UI-Inline-Hooks
-   - optionale spätere Scope-Verschlankung nur bewusst und nicht ad hoc vornehmen
-3. Erst danach entscheiden:
-   - ob Pfade umgezogen werden müssen
-   - wie die Pre-Backup-Dumps automatisiert werden
 
 ## Festgehaltene Entscheidung
 
@@ -217,12 +217,9 @@ Stand jetzt werden **keine grundlegenden Share-Umstrukturierungen** vorgenommen.
 
 ### Aktuelle Prioritäten statt Share-Umbau
 
-1. Den erfolgreichen ersten `critical_infra`-Lauf dokumentarisch abschließen und die verbleibenden Restpunkte sauber abgrenzen.
+1. Den automatischen Betrieb beobachten statt die Architektur weiter umzubauen.
-2. Pre-Backup-Dumps vor Borg automatisieren.
+2. Repo-Soll und Live-Ist nur bei echtem Drift erneut vergleichen.
-   - Zielweg: host-seitig über Unraid User Scripts / Host-Cron
+3. `komodo-mongo` bei Bedarf separat bewerten.
-   - nicht als Borg-UI-Inline-Hook in der aktuellen Architektur
-3. Repo-Soll gegen Live-Ist prüfen und nur bei echtem Drift gezielt eingreifen.
-4. Operative Borg-Artefakte nach `/mnt/user/backups/borg/dumps` verlagern und dort dauerhaft vom Live-App-State trennen.
 
 ### Erläuterung zu Punkt 4