ccfff87d3f
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| ccfff87d3f |
Weboberflaeche: vollstaendige Verwaltungskonsole
Von 95 fachlichen Endpunkten erreicht die Oberflaeche jetzt 89 statt 23. Schreibend waren es neun (vier davon An- und Abmeldung) — jetzt ist jede Handlung der Anlage bedienbar. Neu bedienbar: - **Wiederherstellung** als vierstufiger Assistent. Die Vorabpruefung ist ein eigener Schritt, weil sie den Unterschied zwischen Hoffnung und Nachweis macht: Sie schreibt nichts und stellt fest, ob **jeder benoetigte Block noch da ist**. Ein Manifest allein belegt nur, dass jemand einmal etwas gesichert hat. Die drei Huerden vor dem Ueberschreiben sind sichtbar umgesetzt; laeuft die dritte ins Leere, entfaellt sie — ein Ritual ohne Anlass gewoehnt das Wegklicken an. - **Wiederherstellungspunkte** mit Bewertung, Schutz, Ransomware-Einschaetzung, Legal Hold, Fristverlaengerung und Loeschung. Eine unbelastbare Prozentzahl wird als Vermutung gekennzeichnet, ungemessene Eingangsgroessen erscheinen als "ungemessen" statt als null Punkte. - **Pruefung** mit allen fuenf Pruefarten. Zustand und Ergebnis stehen nebeneinander: Eine gescheiterte Pruefung ist kein Befund am Backup. - **Repositories** mit Integritaetslauf, Katalog-Neuaufbau, Gesundheitspruefung und gemessener Durchsetzungsstufe. Die Uebernahme sagt ausdruecklich, dass hier nichts angelegt wird. - **Aufbewahrung** mit Regeln und Vorschau vor dem Loeschen. - **Proxmox** (neun Endpunkte, bisher ohne jede Oberflaeche) und **Agenten** samt einmaliger Anzeige des Aufnahme-Tokens. - **Benutzer, Rollen, Benachrichtigungswege, eigener zweiter Faktor.** Zwei Funde beim Nachweis gegen den laufenden Dienst: - **Die Einstufung heisst `successful`, nicht `unverified`.** Das Vokabular lautet failed/corrupted/successful/verified/recoverable. `successful` ist die Falle: Es bedeutet "der Lauf ist durchgelaufen" — nicht "wiederherstellbar". Es ist deshalb **neutral**, nicht gruen; ein gruenes Abzeichen laese sich als "geprueft und in Ordnung", und genau diese Verwechslung soll die Anlage verhindern. Regressionstest, durch Mutation als fangend bestaetigt. - **Der Geheimnis-Scanner griff korrekt** beim Platzhaltertext des SSH-Schluesselfelds. Gekennzeichnet statt das Muster aufzuweichen. Die Statuszuordnung steht an genau einer Stelle und faellt fuer unbekannte Werte auf neutral zurueck, nie auf gruen: Ein neuer Serverzustand darf nicht als "in Ordnung" durchgehen. Nachgewiesen im Container gegen Debian 12 mit echtem PostgreSQL und nginx, ueber genau die Aufrufe, die die Konsole macht: Repository uebernommen, Durchsetzungsstufe gemessen (advisory — korrekt auf overlayfs), Auftrag angelegt, Lauf 202, zweiter Anstoss 409, Sicherung erfolgreich (2 Objekte, 3.000.006 Byte, 0 uebergangen), Blockpruefung clean (5 Bloecke), Vorabpruefung "wiederherstellbar: 2 Dateien, 2,9 MiB", Wiederherstellung nach /etc abgewiesen. 76 Tests gruen, tsc sauber, eslint ohne Warnung, Bau 460 KB (136 KB gzip). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| b3f0a99243 |
Weboberflaeche: Design-Fundament und bedienbare Auftraege
Ausgangslage, gemessen statt geschaetzt: Von 99 fachlichen Endpunkten rief die Oberflaeche 23 auf. Schreibend waren es neun, vier davon An- und Abmeldung. Real verwaltbar war: einen Auftrag anlegen, einen Bericht erzeugen, eine Meldung bestaetigen. Das ist ein Leseinstrument, keine Verwaltungskonsole. Dieser Schritt legt das Fundament und macht den ersten Bereich vollstaendig bedienbar. Fundament: - Tailwind v4 und Radix-Primitive (shadcn-Muster). Alles gebuendelt, keine externen Ressourcen — die CSP der Auslieferung laesst sie ohnehin nicht zu. - Farbsystem nach PROMPT.md §106: Semantische Farben ausschliesslich fuer Status, sonst neutral. Die Zuordnung der Fachbegriffe auf die fuenf Bedeutungen steht an genau **einer** Stelle (StatusBadge). Verteilt ueber die Seiten erschiene frueher oder spaeter irgendwo "partial_failure" gruen, und ein Betreiber haelt einen Teilfehler dann fuer einen Erfolg. Ein unbekannter Zustand wird neutral dargestellt, nie gruen. - Neue Seitenhuelle mit fuenf Bereichen, einklappbarer Seitenleiste, Schublade auf schmalen Geraeten und Dark Mode ueber ein Attribut am Wurzelelement (nicht allein ueber die Medienabfrage — eine Konsole, die nachts waehrend einer Stoerung von selbst umschaltet, ist laestig). - `useMutation` fuer schreibende Aufrufe: Doppelklickschutz, Vorgangsnummer bis in die Meldung, kein setState nach dem Aushaengen. `describeApiError` uebersetzt die bekannten Fehlercodes in Saetze **mit Abhilfe**. - Der API-Client sendet jetzt `Idempotency-Key`. Ohne ihn erzeugt ein Doppelklick zwei Auftraege — und bei einer Wiederherstellung zwei gleichzeitige Laeufe in dasselbe Ziel. - Fehlermeldungen nennen immer die `request_id`, kopierbar. Auftraege (Endpunkte, die vorher keine Oberflaeche hatten): - Lauf anstossen, anhalten, fortsetzen, loeschen, laufenden Lauf abbrechen. - Detailseite mit Laufhistorie: Fehlercode, Fehlerklasse und die Auskunft, ob eine Wiederholung ueberhaupt etwas bringt — ein Anmeldefehler behebt sich nicht durch Warten. - **Ein zweiter Anstoss ist kein Fehler, sondern eine Auskunft.** Der 409 wird als Hinweis gezeigt, nicht als Fehlschlag: Der Auftrag laeuft ja, und genau das wollte der Betreiber. - **Loeschen nennt die Folgen.** Die Wiederherstellungspunkte bleiben bestehen; sie gehoeren zum Repository, nicht zum Auftrag. Ohne diesen Hinweis loescht jemand einen Auftrag in der Annahme, Platz zu schaffen. Der Wiederherstellungs-Assistent ist gebaut (vier Schritte, Vorabpruefung als eigener Schritt, die drei Huerden vor dem Ueberschreiben sichtbar umgesetzt), aber noch nicht in eine Seite eingebunden. Drei Lint-Befunde behoben, alle dieselbe Sorte wie in Phase 8 und 12: setState im Effektkoerper und ein Schreibzugriff auf eine Referenz waehrend des Renderns. Der Bestaetigungsdialog haelt seinen Zustand jetzt im Portalinhalt — beim Schliessen verschwindet er von selbst, ein Zuruecksetzen im Effekt entfaellt, und die Huerde steht beim naechsten Oeffnen wieder. Die noch nicht umgebauten Seiten behalten vorerst das alte Stylesheet. Es faellt weg, sobald die letzte umgebaut ist. 69 Tests gruen, tsc sauber, eslint ohne Warnung, Bau 373 KB (115 KB gzip). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 610719c316 |
Syncova Backups V1
Enterprise-Backup-, Recovery-, Verification-, Security- und Monitoring-Plattform fuer Proxmox VE, Windows, Linux und Dateisysteme. Der Leitsatz, der fast jede Entscheidung erklaert: Ein Backup gilt erst als vertrauenswuerdig, wenn Integritaet geprueft und Wiederherstellbarkeit nachgewiesen wurde. Deshalb steigt ein Wiederherstellungspunkt erst nach einem tatsaechlich durchgefuehrten Restore-Test auf "recoverable", und Unbekanntes geht in keine Bewertung als "gut" ein. Umfang (Phasen 0-23): - Repository Engine: inhaltsadressierte Bloecke, atomares Commit-Protokoll, Katalogaufbau allein aus den Manifesten — ohne Datenbank - Backup Engine: inhaltsabhaengiges Chunking, Deduplizierung trotz Verschluesselung, zstd, AES-256-GCM, Streaming mit Gegendruck - Agenten fuer Windows und Linux mit Auftragsabholung (Pull-Modell) - Proxmox-Provider mit beiden Zugriffswegen auf die Sicherungsarchive - Scheduler, Recovery Engine mit Pruefpunkt, Verification, Unveraenderlichkeit - Weboberflaeche, Kennzahlen, Meldungen, Berichte, Security Center, Ransomware-Heuristik (meldet, handelt nie) - Disaster Recovery, Haertung, Leistungsmessung, Chaos Testing - Eingefrorene Vertraege fuer API, Migrationen, Backup-Format und Repository - Auslieferungspaket fuer linux/amd64, linux/arm64 und windows/amd64 Nicht enthalten und als solches gekennzeichnet: Kapazitaetsprognose, Backup Copy, Changed Block Tracking bei Proxmox, erweiterte Attribute und ACLs. Gebaut, aber nie auf echter Hardware gefahren: der Windows-Dienst, die systemd-Einheit und der verpflichtende Proxmox-Meilenstein — ob eine wiederhergestellte VM startet, ist ungeprueft. Einzelheiten in CHANGELOG.md und docs/release-candidate.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
