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>
This commit is contained in:
parent
6e23696fcb
commit
7a5e0e0945
68
CHANGELOG.md
68
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
|
||||
|
||||
272
docs/web-ui.md
272
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
|
||||
sich am leichtesten etwas vortäuschen ließe.
|
||||
Die Konsole, über die man die Anlage bedient — und der Ort, an dem sich am
|
||||
leichtesten etwas vortäuschen ließe.
|
||||
|
||||
Der Implementierungsplan nennt fünfzehn Seiten und zehn Kennzahlen. Nicht hinter
|
||||
allen steht heute ein Backend. Wie damit umgegangen wird, ist die eine
|
||||
Entscheidung, die diese Phase trägt.
|
||||
Sie erreicht **89 von 95 fachlichen Endpunkten**. Die sechs offenen sind
|
||||
Detail-Abrufe (`GET /alerts/{id}`, `GET /agents/{id}`, `GET /proxmox/vms/{id}`,
|
||||
`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
|
||||
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.
|
||||
Konkret sichtbar an vier Stellen:
|
||||
|
||||
Ein unfertiger Bereich erscheint im Menü mit dem Vermerk „noch nicht verfügbar"
|
||||
und führt auf eine Seite, die drei Dinge sagt: was fehlt, warum es fehlt, und wo
|
||||
dieselbe Auskunft heute steht. Beispiel Meldungen:
|
||||
- **Kennzahlen ohne Datengrundlage** erscheinen mit Begründung statt mit einer
|
||||
Null. „0 kritische Meldungen" hieße „keine Probleme" und bedeutete „es wird
|
||||
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
|
||||
> Stelle hieße „keine Probleme" und würde bedeuten „es wird nicht geprüft". Bis
|
||||
> dahin zeigen Übersicht und Ereignisse, was auffällig ist.
|
||||
## Die achtzehn Seiten
|
||||
|
||||
| Seite | Zustand |
|
||||
| Bereich | Seiten |
|
||||
| --- | --- |
|
||||
| Übersicht | ✓ `GET /dashboard` |
|
||||
| Sicherungsaufträge | ✓ `GET /jobs` samt Assistent |
|
||||
| Wiederherstellungspunkte | ✓ `GET /backups` |
|
||||
| Wiederherstellungen | ✓ `GET /restores` |
|
||||
| Repositories | ✓ `GET /repositories` |
|
||||
| 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 |
|
||||
| **Betrieb** | Übersicht · Sicherungsaufträge · Wiederherstellung · Meldungen |
|
||||
| **Daten** | Wiederherstellungspunkte · Prüfung · Repositories · Aufbewahrung |
|
||||
| **Infrastruktur** | Agenten · Proxmox · Geschützte Systeme |
|
||||
| **Analyse** | Kennzahlen · Berichte · Security Center |
|
||||
| **Verwaltung** | Benutzer · Rollen · Ereignisprotokoll · Einstellungen |
|
||||
|
||||
## 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 |
|
||||
| --- | --- |
|
||||
| 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` |
|
||||
### Die drei Hürden vor dem Überschreiben
|
||||
|
||||
Ohne Datengrundlage: **Kritische Meldungen**, **Kapazitätsprognose**, **Security
|
||||
Score**. Sie erscheinen mit der Angabe, was fehlt.
|
||||
Der Wiederherstellungs-Assistent setzt sie sichtbar um:
|
||||
|
||||
### 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
|
||||
zwischen 0 % und 100 %. Ein Monat verdeckt, dass seit gestern nichts mehr geht.
|
||||
Läuft die dritte ins Leere, weil das Ziel leer ist, entfällt sie. Ein Ritual ohne
|
||||
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
|
||||
`warning` und sagt es. Ein Dashboard, das bei ausgefallener Sicherung grün
|
||||
zeigt, ist schlimmer als keines.
|
||||
Sie schreibt nichts und stellt fest, ob **jeder benötigte Block noch da ist**.
|
||||
Ein Manifest allein belegt nur, dass jemand einmal etwas gesichert hat. Fehlende
|
||||
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.
|
||||
Die Kachel zeigt „nicht bezifferbar" und nennt im Detailtext die belegte Menge.
|
||||
Einen Wert zu schätzen wäre eine erfundene Statistik.
|
||||
Ein zweiter Anstoß bei laufendem Auftrag erscheint als Hinweis, nicht als
|
||||
Fehlschlag. Der Auftrag läuft ja — und genau das wollte der Betreiber wissen.
|
||||
|
||||
Umgekehrt gilt dasselbe nach unten: 0,0004 % belegter Speicher erscheint als
|
||||
`< 0,1 %`, nicht als `0 %` — „null Prozent" liest sich wie „nichts abgelegt".
|
||||
### Was Löschen wirklich bewirkt, steht dabei
|
||||
|
||||
## 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
|
||||
welche kann ich mich verlassen": Einstufung, Bewertung und Schutzlage stehen in
|
||||
jeder Zeile, nicht in einem Detailfenster.
|
||||
### Geheimnisse gehen nur hinein
|
||||
|
||||
- **Ungeprüft ist eine Aussage, keine Lücke.** Ein Punkt ohne Einstufung
|
||||
erscheint gelb mit „ungeprüft" — er wurde nie zurückgeschrieben.
|
||||
- **Keine Bewertung heißt nicht null Prozent.** „nicht berechnet" und „0 %" sind
|
||||
zwei verschiedene Aussagen; die zweite ist ein Befund (Phase 10).
|
||||
- **Gelöschte Punkte erscheinen auf Nachfrage.** Die Frage „warum ist das Backup
|
||||
von vorletzter Woche weg?" ist die erste, die im Ernstfall gestellt wird — der
|
||||
Löschgrund steht am Eintrag.
|
||||
Das Aufnahme-Token eines Agenten erscheint **genau einmal**, mit
|
||||
ausdrücklichem Hinweis und ohne Weg, den Dialog versehentlich zu schließen. Das
|
||||
API-Token eines Proxmox-Verbunds wird nach dem Anlegen nie wieder ausgeliefert —
|
||||
das ist kein Mangel, sondern der Grund, warum ein Lesezugriff auf die
|
||||
Konfiguration ungefährlich ist.
|
||||
|
||||
## 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;
|
||||
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
|
||||
|
||||
**Betriebsfolge:** Das ausgelieferte Bundle braucht einen SPA-Fallback. Ein
|
||||
Neuladen auf `/recovery-points` muss dieselbe `index.html` erhalten, sonst
|
||||
antwortet der Webserver mit 404. Der Vite-Entwicklungsserver tut das von selbst;
|
||||
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.
|
||||
Das Bundle braucht einen SPA-Fallback (`try_files $uri /index.html`), sonst
|
||||
ergibt ein Neuladen auf `/recovery-points` einen 404. `setup.sh` richtet das mit
|
||||
ein.
|
||||
|
||||
## 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.
|
||||
- Wiederherstellungspunkte: 9 Punkte, einer `recoverable` mit 80 %, die übrigen
|
||||
„ungeprüft" — keine erfundene Bewertung.
|
||||
- Filter geprüft: nur geschützte (1 Treffer), gelöschte einbeziehen, Einstufung.
|
||||
- Dev-Server liefert `/dashboard` und `/recovery-points` mit HTTP 200; die API
|
||||
läuft über den Proxy ohne CORS.
|
||||
- 60 Frontend-Tests grün, Bundle 246 kB (74,6 kB gzip).
|
||||
- Repository übernommen, Durchsetzungsstufe **gemessen** (`advisory` — auf
|
||||
overlayfs richtig)
|
||||
- Auftrag angelegt, Lauf `202`, zweiter Anstoß `409`
|
||||
- Sicherung erfolgreich: 2 Objekte, 3.000.006 Byte, 0 übergangen
|
||||
- Blockprüfung `clean`, 5 Blöcke
|
||||
- Vorabprüfung: „wiederherstellbar, 2 Dateien, 2,9 MiB"
|
||||
- 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
|
||||
jeweils die ersten 50 Einträge. Bei mehr fehlt der Weg zur zweiten Seite.
|
||||
- **Benutzer und Rollen sind reine Anzeige.** Anlegen und Ändern gehen über die
|
||||
API. Eine Maske müsste die Sonderfälle beherrschen — letzter Administrator,
|
||||
mitgelieferte unveränderliche Rollen — und die gehören geprüft, nicht nebenbei
|
||||
gebaut.
|
||||
- **Kein automatisches Aktualisieren.** Die Seiten laden beim Öffnen. Ein
|
||||
Live-Strom über `/events/stream` ist vorgesehen, aber nicht gebaut.
|
||||
- **Keine Detailansicht je Wiederherstellungspunkt.** Prüfung auslösen,
|
||||
Legal Hold setzen und Wiederherstellung starten gehen über die API.
|
||||
- **Sechs Detail-Endpunkte** haben keine eigene Ansicht; ihre Daten stehen in den
|
||||
Listen.
|
||||
- **Die Suche im Ereignisprotokoll filtert im Browser** über die letzten 100
|
||||
Einträge. Bei größeren Beständen gehört sie auf den Server.
|
||||
- **Kein Live-Fortschritt.** `/api/v1/events/stream` steht in `SYNCOVA_API.md`,
|
||||
ist aber **auch serverseitig nicht umgesetzt** — es fehlt nicht nur die
|
||||
Anbindung. Laufende Sicherungen und Wiederherstellungen aktualisieren sich
|
||||
beim Neuladen, nicht von selbst.
|
||||
- **Kein Simple Mode.** Der Plan trennt Simple und Advanced Mode; umgesetzt ist
|
||||
eine Ansicht.
|
||||
- **Proxmox ist nicht auf echter Hardware freigegeben.** Die Seite sagt das
|
||||
ausdrücklich.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user