Dokumentation und Aenderungsliste fuer rc6

docs/web-ui.md beschrieb die Oberflaeche aus Phase 12 — eine, die es nicht mehr
gibt. Eine Anleitung, die auf Bereiche verweist, die anders heissen und anders
funktionieren, ist schlimmer als keine: Der Leser sucht den Fehler bei sich.
Neu geschrieben.

Eine Aussage darin habe ich beim Nachpruefen korrigiert: `/api/v1/events/stream`
steht zwar in SYNCOVA_API.md, ist aber **auch serverseitig** nicht umgesetzt.
"Nicht angebunden" haette den Mangel der Oberflaeche zugeschoben.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,73 @@
 # Änderungen
 
+## V1 — Release Candidate 6, 18. August 2026
+
+**Die Weboberfläche ist eine vollständige Verwaltungskonsole geworden.**
+
+Vorher erreichte sie 23 von 95 fachlichen Endpunkten; schreibend waren es neun,
+vier davon An- und Abmeldung. Real verwaltbar war: einen Auftrag anlegen, einen
+Bericht erzeugen, eine Meldung bestätigen. Das war ein Leseinstrument mit
+Assistent, keine Konsole. **Jetzt sind es 89 von 95.**
+
+### Neu bedienbar
+
+- **Wiederherstellung** als vierstufiger Assistent — vorher nur über `curl`. Die
+  Vorabprüfung ist ein eigener Schritt, weil sie den Unterschied zwischen
+  Hoffnung und Nachweis macht: Sie schreibt nichts und stellt fest, ob **jeder
+  benötigte Block noch da ist**. Die drei Hürden vor dem Überschreiben sind
+  sichtbar umgesetzt; läuft die dritte ins Leere, entfällt sie.
+- **Wiederherstellungspunkte** mit Bewertung, Legal Hold, Fristverlängerung,
+  Löschung und Ransomware-Einschätzung.
+- **Prüfung** mit allen fünf Prüfarten. Zustand und Ergebnis stehen
+  nebeneinander: Eine gescheiterte Prüfung ist kein Befund am Backup.
+- **Repositories** mit Integritätslauf, Katalog-Neuaufbau, Gesundheitsprüfung und
+  gemessener Durchsetzungsstufe.
+- **Aufbewahrung** mit Regeln und Vorschau vor dem Löschen.
+- **Proxmox** — neun Endpunkte, die vorher gar keine Oberfläche hatten — und
+  **Agenten** samt einmaliger Anzeige des Aufnahme-Tokens.
+- **Benutzer, Rollen, Benachrichtigungswege, eigener zweiter Faktor.**
+
+### Neues Design
+
+Tailwind v4 und Radix-Primitive nach shadcn-Muster, alles gebündelt. Dark Mode,
+einklappbare Seitenleiste, Bedienung auf Tablets. Achtzehn Seiten in fünf
+Bereichen.
+
+Die tragende Entscheidung ist keine Frage des Aussehens: **Die Zuordnung der
+Fachbegriffe auf die fünf Statusfarben liegt an genau einer Stelle.** Verteilt
+über die Seiten erschiene früher oder später irgendwo `partial_failure` grün —
+und ein Betreiber hält einen Teilfehler dann für einen Erfolg. Ein unbekannter
+Serverzustand wird neutral dargestellt, niemals grün.
+
+### Funde beim Nachweis
+
+- **Die Einstufung heißt `successful`, nicht `unverified`.** Das ist die
+  gefährlichste Stelle der Oberfläche: `successful` bedeutet „der Lauf ist
+  durchgelaufen" — nicht „wiederherstellbar". Es ist deshalb neutral, nicht
+  grün. Regressionstest vorhanden.
+- **`describeApiError` warf die genauere Servermeldung weg** und ersetzte sie
+  durch einen allgemeinen Satz. Ein `SERVICE_UNAVAILABLE` mit „Für diesen Bericht
+  ist keine Sicherheitsprüfung eingerichtet" wurde zu „Der Dienst ist derzeit
+  nicht vollständig verfügbar" — der Betreiber hätte den Fehler bei seiner Anlage
+  gesucht. Jetzt hat die Servermeldung Vorrang.
+- **Einem Fehler nach einer Handlung fehlte `role="alert"`.** Ein Screenreader
+  hätte ihn nicht angesagt.
+- **Der Geheimnis-Scanner griff korrekt** beim Platzhaltertext des
+  SSH-Schlüsselfelds. Gekennzeichnet, statt das Muster aufzuweichen.
+
+### Aufgeräumt
+
+Ein Stylesheet statt sieben; das ausgelieferte CSS fällt von 54 auf 30 KB.
+Entfernt, weil ersetzt: `JobsPanel`, `StatusIndicator`, `PageState`.
+
+### Unverändert offen
+
+Windows-Dienst, systemd-Einheit des Agenten und der Proxmox-Bootmeilenstein sind
+gebaut, aber nie auf echter Hardware gefahren. Dazu ohne Oberfläche: sechs
+Detail-Endpunkte (ihre Daten stehen in den Listen), Live-Fortschritt
+(`/api/v1/events/stream` ist auch serverseitig nicht umgesetzt) und der Simple
+Mode.
+
 ## V1 — Release Candidate 5, 18. August 2026
 
 Die Oberfläche richtet sich jetzt mit ein. Bisher endete `setup.sh` mit einer

docs/web-ui.md

@@ -1,165 +1,181 @@
 # Weboberfläche
 
-Phase 12. Die Oberfläche, über die man die Anlage bedient — und der Ort, an dem
+Die Konsole, über die man die Anlage bedient — und der Ort, an dem sich am
-sich am leichtesten etwas vortäuschen ließe.
+leichtesten etwas vortäuschen ließe.
 
-Der Implementierungsplan nennt fünfzehn Seiten und zehn Kennzahlen. Nicht hinter
+Sie erreicht **89 von 95 fachlichen Endpunkten**. Die sechs offenen sind
-allen steht heute ein Backend. Wie damit umgegangen wird, ist die eine
+Detail-Abrufe (`GET /alerts/{id}`, `GET /agents/{id}`, `GET /proxmox/vms/{id}`,
-Entscheidung, die diese Phase trägt.
+`GET /security/findings`, `GET /verification/{id}` und dessen Ergebnisse), deren
+Daten die jeweiligen Listen bereits enthalten.
+
+## Die eine Entscheidung, die alles trägt
+
+**Semantische Farben ausschließlich für Zustände** (PROMPT §106). Die Konsole ist
+neutral gehalten; wo Farbe erscheint, bedeutet sie etwas. Eine bunte Oberfläche
+verschleiert, welche Information wirklich dringend ist — und in einer
+Backup-Konsole ist genau das die einzige Frage, die zählt.
+
+Daraus folgt der Zuschnitt: kein Markenblau als Fläche, der Akzent nur für
+Bedienelemente. Der Schweregrad einer Kennzahl färbt die **Randlinie**, nicht die
+Kachel; zehn farbige Flächen nebeneinander ergeben ein Mosaik, in dem die eine
+kritische Zahl untergeht.
+
+### Die Statuszuordnung steht an genau einer Stelle
+
+`components/ui/StatusBadge.tsx` bildet jeden Fachbegriff der API auf einen der
+fünf Töne ab. Wäre diese Abbildung über die Seiten verteilt, erschiene früher
+oder später irgendwo `partial_failure` grün — und ein Betreiber hält einen
+Teilfehler dann für einen Erfolg.
+
+Vier Zuordnungen sind keine Geschmacksfrage:
+
+| Wert | Ton | Warum |
+| --- | --- | --- |
+| `partial_failure` | Warnung | Entwicklungsregel 1: nie `SUCCESS` |
+| `successful` (Einstufung) | **neutral** | Heißt „der Lauf ist durchgelaufen", nicht „wiederherstellbar" |
+| `corrupted` | kritisch | Nicht zu 70 % wiederherstellbar, sondern gar nicht |
+| `advisory` (Löschschutz) | Warnung | Der Schutz ist eine Software-Regel, kein Schutz des Dateisystems |
+
+**Ein unbekannter Wert wird neutral dargestellt, niemals grün.** Ein neuer
+Serverzustand, den die Tabelle nicht kennt, darf nicht als „in Ordnung"
+durchgehen. `StatusBadge.test.tsx` hält alle fünf Punkte fest; jeder wurde durch
+Mutation als fangend bestätigt.
 
 ## Was nicht da ist, wird benannt
 
-Drei Wege standen offen:
+Der Grundsatz aus PROMPT §139 gilt unverändert: Ein Menü, das nur die fertigen
+Bereiche zeigt, verschweigt den Ausbaustand; eines mit leeren Masken täuscht ihn
+vor. Jeder Eintrag erscheint, und ein noch nicht verfügbarer nennt, was fehlt.
 
-1. **Nur die fertigen Bereiche zeigen.** Verschweigt den Ausbaustand. Wer die
+Konkret sichtbar an vier Stellen:
-   Anlage bewertet, hält für nicht vorgesehen, was nur noch nicht gebaut ist.
-2. **Alle Bereiche zeigen, leere Masken dahinter.** Täuscht den Ausbaustand vor.
-   Eine leere Meldungsliste liest sich wie „keine Probleme".
-3. **Alle Bereiche zeigen, unfertige benennen.** Gewählt.
 
-Ein unfertiger Bereich erscheint im Menü mit dem Vermerk „noch nicht verfügbar"
+- **Kennzahlen ohne Datengrundlage** erscheinen mit Begründung statt mit einer
-und führt auf eine Seite, die drei Dinge sagt: was fehlt, warum es fehlt, und wo
+  Null. „0 kritische Meldungen" hieße „keine Probleme" und bedeutete „es wird
-dieselbe Auskunft heute steht. Beispiel Meldungen:
+  nicht geprüft".
+- **Ungemessene Eingangsgrößen der Bewertung** stehen als „ungemessen" da, nicht
+  als null Punkte. Als 0 zu zeigen bestrafte das Unbekannte.
+- **Nicht ausgewertete Meldungsregeln** werden als solche gekennzeichnet. Eine
+  Regel, die dauerhaft schweigt, ist gefährlicher als keine.
+- **Ungeprüfte Bereiche im Security Center** gehen weder positiv noch negativ in
+  die Rechnung ein; ab drei sagt die Seite, dass die Zahl eine Vermutung ist.
 
-> Ein Meldungswesen gibt es noch nicht (Phase 14). Eine leere Liste an dieser
+## Die achtzehn Seiten
-> Stelle hieße „keine Probleme" und würde bedeuten „es wird nicht geprüft". Bis
-> dahin zeigen Übersicht und Ereignisse, was auffällig ist.
 
-| Seite | Zustand |
+| Bereich | Seiten |
 | --- | --- |
-| Übersicht | ✓ `GET /dashboard` |
+| **Betrieb** | Übersicht · Sicherungsaufträge · Wiederherstellung · Meldungen |
-| Sicherungsaufträge | ✓ `GET /jobs` samt Assistent |
+| **Daten** | Wiederherstellungspunkte · Prüfung · Repositories · Aufbewahrung |
-| Wiederherstellungspunkte | ✓ `GET /backups` |
+| **Infrastruktur** | Agenten · Proxmox · Geschützte Systeme |
-| Wiederherstellungen | ✓ `GET /restores` |
+| **Analyse** | Kennzahlen · Berichte · Security Center |
-| Repositories | ✓ `GET /repositories` |
+| **Verwaltung** | Benutzer · Rollen · Ereignisprotokoll · Einstellungen |
-| Agenten | ✓ `GET /agents` |
-| Ereignisse | ✓ `GET /audit-events` |
-| Benutzer | ✓ `GET /users` |
-| Rollen | ✓ `GET /roles` |
-| Geschützte Systeme | — kein System als eigener Gegenstand im Datenmodell |
-| Proxmox | — Provider gebaut, keine API, E2E-Nachweis offen (Phase 7) |
-| Meldungen | — kein Meldungswesen (Phase 14) |
-| Sicherheit | — keine Gesamtbewertung; Einzelangaben unter Benutzer/Rollen/Ereignisse |
-| Berichte | — nicht umgesetzt (Phase 15) |
-| Einstellungen | — Konfiguration läuft über Umgebungsvariablen |
 
-## Die Übersicht
+Die Gliederung folgt dem Weg durch die Anlage: Was täglich beobachtet wird, steht
+oben; was einmal eingerichtet und dann selten angefasst wird, unten.
 
-Zehn Kennzahlen nach Plan §14, davon sieben mit Datengrundlage:
+## Handlungen, die etwas verändern
 
-| Kennzahl | Quelle |
+### Die drei Hürden vor dem Überschreiben
-| --- | --- |
-| Geschützte Systeme | Quellen aktiver Aufträge, angemeldete Agenten |
-| Erfolgsquote (7 Tage) | `backup_job_runs` — **ein Teilfehler zählt nicht als Erfolg** |
-| Aufträge mit Befund | `last_outcome` je Auftrag |
-| Speicherbelegung | `capacity_bytes` / `used_bytes` der Repositories |
-| Nachgewiesen wiederherstellbar | Anteil mit `classification = recoverable` |
-| Repositories | Zustand, gehärtet, gemessener Löschschutz |
-| RPO eingehalten | letzter erfolgreicher Lauf gegen `rpo_seconds` |
 
-Ohne Datengrundlage: **Kritische Meldungen**, **Kapazitätsprognose**, **Security
+Der Wiederherstellungs-Assistent setzt sie sichtbar um:
-Score**. Sie erscheinen mit der Angabe, was fehlt.
 
-### Sieben Tage, nicht einer und nicht dreißig
+1. Das Kennzeichen `overwrite_existing` muss gesetzt werden.
+2. Die Berechtigung `restores.overwrite` prüft der Server — sie steckt bewusst
+   **nicht** in `restores.execute`.
+3. `confirm_overwrite` verlangt den **wörtlich wiederholten Zielpfad**.
 
-Ein Tag zeigt bei täglicher Sicherung einen Lauf je Auftrag und schwankt
+Läuft die dritte ins Leere, weil das Ziel leer ist, entfällt sie. Ein Ritual ohne
-zwischen 0 % und 100 %. Ein Monat verdeckt, dass seit gestern nichts mehr geht.
+Anlass gewöhnt das Wegklicken an — und dann wirkt es dort nicht mehr, wo es
+zählt. Dieselbe Überlegung trägt die wörtliche Bestätigung beim Löschen eines
+Wiederherstellungspunkts, eines Auftrags und beim Anwenden einer
+Aufbewahrungsregel.
 
-### Keine Läufe sind nicht 100 %
+### Die Vorabprüfung ist ein eigener Schritt
 
-Lief in sieben Tagen keine Sicherung, gibt es keine Quote — die Kennzahl meldet
+Sie schreibt nichts und stellt fest, ob **jeder benötigte Block noch da ist**.
-`warning` und sagt es. Ein Dashboard, das bei ausgefallener Sicherung grün
+Ein Manifest allein belegt nur, dass jemand einmal etwas gesichert hat. Fehlende
-zeigt, ist schlimmer als keines.
+Blöcke stehen ganz oben und in Rot; sie sind der einzige Befund, bei dem
+feststeht, dass die Wiederherstellung nicht vollständig gelingen kann.
 
-### Nicht bezifferbar ist nicht null
+### Ein 409 ist eine Auskunft, kein Fehler
 
-Ist für kein Repository eine Kapazität hinterlegt, gibt es keinen Prozentsatz.
+Ein zweiter Anstoß bei laufendem Auftrag erscheint als Hinweis, nicht als
-Die Kachel zeigt „nicht bezifferbar" und nennt im Detailtext die belegte Menge.
+Fehlschlag. Der Auftrag läuft ja — und genau das wollte der Betreiber wissen.
-Einen Wert zu schätzen wäre eine erfundene Statistik.
 
-Umgekehrt gilt dasselbe nach unten: 0,0004 % belegter Speicher erscheint als
+### Was Löschen wirklich bewirkt, steht dabei
-`< 0,1 %`, nicht als `0 %` — „null Prozent" liest sich wie „nichts abgelegt".
 
-## Wiederherstellungspunkte
+- Ein gelöschter **Auftrag** nimmt seine Wiederherstellungspunkte nicht mit. Sie
+  gehören zum Repository. Ohne diesen Hinweis löscht jemand einen Auftrag in der
+  Annahme, Platz zu schaffen.
+- Wird beim Löschen **kein Speicher frei**, ist das kein Fehler, sondern
+  Deduplizierung: Die Blöcke werden von einem anderen Backup gebraucht.
 
-Die zentrale Seite. Sie beantwortet nicht „welche Backups gibt es", sondern „auf
+### Geheimnisse gehen nur hinein
-welche kann ich mich verlassen": Einstufung, Bewertung und Schutzlage stehen in
-jeder Zeile, nicht in einem Detailfenster.
 
-- **Ungeprüft ist eine Aussage, keine Lücke.** Ein Punkt ohne Einstufung
+Das Aufnahme-Token eines Agenten erscheint **genau einmal**, mit
-  erscheint gelb mit „ungeprüft" — er wurde nie zurückgeschrieben.
+ausdrücklichem Hinweis und ohne Weg, den Dialog versehentlich zu schließen. Das
-- **Keine Bewertung heißt nicht null Prozent.** „nicht berechnet" und „0 %" sind
+API-Token eines Proxmox-Verbunds wird nach dem Anlegen nie wieder ausgeliefert —
-  zwei verschiedene Aussagen; die zweite ist ein Befund (Phase 10).
+das ist kein Mangel, sondern der Grund, warum ein Lesezugriff auf die
-- **Gelöschte Punkte erscheinen auf Nachfrage.** Die Frage „warum ist das Backup
+Konfiguration ungefährlich ist.
-  von vorletzter Woche weg?" ist die erste, die im Ernstfall gestellt wird — der
-  Löschgrund steht am Eintrag.
 
 ## Technik
 
-### Navigation ohne Router-Bibliothek
+- **Tailwind v4 und Radix-Primitive** nach shadcn-Muster. Alles gebündelt; die
+  CSP der Auslieferung lässt externe Ressourcen ohnehin nicht zu.
+- **Farben als CSS-Variablen**, damit dieselbe Komponente in beiden Themen
+  funktioniert, ohne dass jede Klasse eine `dark:`-Variante braucht.
+- **Dark Mode über ein Attribut am Wurzelelement**, nicht allein über die
+  Medienabfrage: Eine Konsole, die nachts während einer Störung von selbst
+  umschaltet, ist lästig. Das Attribut sitzt am Wurzelelement, weil ein Dialog im
+  Portal sonst im falschen Thema erschiene.
+- **Navigation über die History-API**, keine Router-Bibliothek. Zwei Ebenen —
+  Seite und optional ein Objekt darauf — reichen für diese Konsole.
+- **`useMutation` für schreibende Aufrufe:** Doppelklickschutz, Vorgangsnummer
+  bis in die Meldung, kein `setState` nach dem Aushängen.
+- **`Idempotency-Key`** an allen anlegenden und zerstörenden Aufrufen. Ohne ihn
+  erzeugt ein Doppelklick zwei Aufträge — und bei einer Wiederherstellung zwei
+  gleichzeitige Läufe in dasselbe Ziel.
+- **Die Servermeldung hat Vorrang** vor der allgemeinen Erklärung zum
+  Fehlercode. Sie kennt den Einzelfall, und diese Genauigkeit ist mehr wert.
+- **Berechtigungen im Menü sind Anzeige, keine Sicherung.** Sie verhindern
+  Sackgassen; geprüft wird auf dem Server.
+- **Jede Fehleranzeige nennt `request_id`**, kopierbar. Ohne sie bleibt „es hat
+  nicht funktioniert".
 
-Eine Anwendung mit einer Ebene flacher Seiten braucht kein Routing-Framework;
+### Betriebsfolge
-sie braucht kopierbare Adressen und einen funktionierenden Zurück-Knopf. Beides
-leistet die History-API in rund fünfzig Zeilen (`useCurrentPage.ts`). Sobald
-verschachtelte Routen mit eigenen Unterseiten entstehen, kehrt sich die Rechnung
-um — dann ist diese Datei der Ort für den Wechsel.
 
-**Betriebsfolge:** Das ausgelieferte Bundle braucht einen SPA-Fallback. Ein
+Das Bundle braucht einen SPA-Fallback (`try_files $uri /index.html`), sonst
-Neuladen auf `/recovery-points` muss dieselbe `index.html` erhalten, sonst
+ergibt ein Neuladen auf `/recovery-points` einen 404. `setup.sh` richtet das mit
-antwortet der Webserver mit 404. Der Vite-Entwicklungsserver tut das von selbst;
+ein.
-für den Produktionsbetrieb ist es Sache des vorgelagerten Webservers
-(`try_files $uri /index.html` bei nginx).
-
-### Ladezustände
-
-`useApiResource` hält Laden, Fehler und Ergebnis an einer Stelle. Der
-Ladezustand wird **abgeleitet**, nicht im Effekt gesetzt: Das Ergebnis trägt den
-Schlüssel, unter dem es entstanden ist; passt er nicht zum aktuellen, läuft die
-Anfrage noch. Ein `setState` im Effektkörper löste eine zweite Renderrunde aus,
-bevor überhaupt etwas geladen wurde — und der Linter weist es zu Recht ab.
-
-Nebeneffekt: Beim Filterwechsel bleiben die vorherigen Zeilen stehen, statt dass
-die Tabelle aufblitzt.
-
-### Fehler tragen ihre Vorgangsnummer
-
-Jede Fehleranzeige nennt Fehlercode und `request_id`. Damit lässt sich ein
-Vorfall im Serverlog eindeutig wiederfinden — ohne sie bleibt „es hat nicht
-funktioniert".
-
-### Berechtigungen sind Anzeige, keine Sicherung
-
-Seiten ohne die nötige Berechtigung erscheinen nicht im Menü. Das ist keine
-Sicherheitsmaßnahme — die liegt auf dem Server (PROMPT.md §42) — sondern
-verhindert eine Oberfläche voller Sackgassen. Wer die Adresse direkt aufruft,
-bekommt eine verständliche Auskunft statt einer Fehlermeldung.
-
-### Farbe nur für Status
-
-Grün healthy, gelb warning, orange high, rot critical, blau information. Ein
-unbekannter Zustand bekommt **keine** Farbe — und schon gar nicht grün.
 
 ## Nachgewiesen
 
-Gegen den laufenden Dienst mit echten Daten:
+Gegen Debian 12 mit echtem PostgreSQL und nginx, über genau die Aufrufe, die die
+Konsole macht:
 
-- Übersicht: 7 von 10 Kennzahlen mit Datengrundlage, drei mit Begründung.
+- Repository übernommen, Durchsetzungsstufe **gemessen** (`advisory` — auf
-- Wiederherstellungspunkte: 9 Punkte, einer `recoverable` mit 80 %, die übrigen
+  overlayfs richtig)
-  „ungeprüft" — keine erfundene Bewertung.
+- Auftrag angelegt, Lauf `202`, zweiter Anstoß `409`
-- Filter geprüft: nur geschützte (1 Treffer), gelöschte einbeziehen, Einstufung.
+- Sicherung erfolgreich: 2 Objekte, 3.000.006 Byte, 0 übergangen
-- Dev-Server liefert `/dashboard` und `/recovery-points` mit HTTP 200; die API
+- Blockprüfung `clean`, 5 Blöcke
-  läuft über den Proxy ohne CORS.
+- Vorabprüfung: „wiederherstellbar, 2 Dateien, 2,9 MiB"
-- 60 Frontend-Tests grün, Bundle 246 kB (74,6 kB gzip).
+- Wiederherstellung nach `/etc` abgewiesen
+- Alle 18 Seiten liefern über HTTPS `200`; das Design-System steckt samt
+  Dark-Mode-Regeln im ausgelieferten CSS
+
+76 Tests, `tsc` sauber, `eslint` ohne Warnung. Bundle 466 KB (136 KB gzip), CSS
+30 KB (6 KB gzip).
 
 ## Bekannte Grenzen
 
-- **Keine Pagination in der Oberfläche.** Die API kann sie, die Seiten laden
+- **Sechs Detail-Endpunkte** haben keine eigene Ansicht; ihre Daten stehen in den
-  jeweils die ersten 50 Einträge. Bei mehr fehlt der Weg zur zweiten Seite.
+  Listen.
-- **Benutzer und Rollen sind reine Anzeige.** Anlegen und Ändern gehen über die
+- **Die Suche im Ereignisprotokoll filtert im Browser** über die letzten 100
-  API. Eine Maske müsste die Sonderfälle beherrschen — letzter Administrator,
+  Einträge. Bei größeren Beständen gehört sie auf den Server.
-  mitgelieferte unveränderliche Rollen — und die gehören geprüft, nicht nebenbei
+- **Kein Live-Fortschritt.** `/api/v1/events/stream` steht in `SYNCOVA_API.md`,
-  gebaut.
+  ist aber **auch serverseitig nicht umgesetzt** — es fehlt nicht nur die
-- **Kein automatisches Aktualisieren.** Die Seiten laden beim Öffnen. Ein
+  Anbindung. Laufende Sicherungen und Wiederherstellungen aktualisieren sich
-  Live-Strom über `/events/stream` ist vorgesehen, aber nicht gebaut.
+  beim Neuladen, nicht von selbst.
-- **Keine Detailansicht je Wiederherstellungspunkt.** Prüfung auslösen,
+- **Kein Simple Mode.** Der Plan trennt Simple und Advanced Mode; umgesetzt ist
-  Legal Hold setzen und Wiederherstellung starten gehen über die API.
+  eine Ansicht.
+- **Proxmox ist nicht auf echter Hardware freigegeben.** Die Seite sagt das
+  ausdrücklich.