# Dashboard-V5-Previewprofil im Betrieb

Der Action-Worker akzeptiert genau einen optionalen Vertrag:

```text
HEALTH_DASHBOARD_V5_PROFILE=default
HEALTH_DASHBOARD_V5_PROFILE=health-record-6e
```

Ohne Variable beziehungsweise mit leerem Wert gilt `default`; bestehende Standard- und Testläufe bleiben unverändert. Andere Werte, Whitespace-Varianten sowie kombinierte oder widersprüchliche Werte werden beim Prozessstart abgewiesen, bevor Inbox oder Datenbank berührt werden.

`health-record-6e` ergänzt bei jeder Worker-Regeneration exakt `--health-record-6e`. Damit bleiben Explorer, Kalender/Tag und Akte nach einer Queue-Verarbeitung aktiv. Die manuelle Preview-Generierung muss dasselbe Profil verwenden:

```bash
python3 scripts/health/health_dashboard_v5.py \
  --db "$HEALTH_DASHBOARD_DB" \
  --output "$HEALTH_DASHBOARD_V5_FILE" \
  --health-record-6e
```

Das versionierte Worker-Unit-Template pinnt das autorisierte Previewprofil. V4 wird dadurch weder ersetzt noch in seiner Route verändert.

## Deploymentkontrolle

1. Vor Installation das Profil im Unit-Template und in der manuellen Generierung vergleichen.
2. Unit mit `systemd-analyze --user verify` validieren.
3. `systemctl --user daemon-reload` ausführen.
4. Einen Queue→Worker→Regenerationsfall zuerst ausschließlich mit einer privaten SQLite-Kopie und synthetischem Action-JSON prüfen.
5. Auf Produktion keine synthetische Action einspielen.
6. Nach Workerläufen prüfen, dass V5 weiterhin die drei lokalen Assets für Explorer, Kalender/Tag und Akte referenziert.

## Rollback

Vorherige Unit, Workerdatei, V5-HTML und Assets aus dem privaten Rollback-Artefakt atomar wiederherstellen, `daemon-reload` ausführen und nur die betroffenen User-Services neu starten. V4 bleibt währenddessen über seine bestehende Route verfügbar. FTS kann über `document_fts_migrate.py --drop` entfernt oder durch Wiederherstellung des konsistenten SQLite-Backups zurückgesetzt werden.