v3.7.0 — English-first README + English commits

🌍 English-first, to widen the reviewer pool

The German-only front page was the biggest barrier for international eyes. As of this release:

• README.md is now English (the project's default GitHub landing page). The German version lives on at README.de.md, linked from the top — both keep their full git history.
• Commit messages and these release notes are now written in English.

Deliberately unchanged

The other bilingual docs (deploy/, docs/, config/) keep their German-primary + .en-twin layout, and the code comments plus the German-canonical UI/API/audit log stay as they are. Anglicising those would be a separate, larger effort — this release is the high-leverage, low-churn step.

Also this session

• First real pull-request workflow in use (this change went through PR #9, CI green, squash-merged) — building the history OpenSSF Scorecard reads for CI-Tests & Code-Review.
• CODEOWNERS now auto-requests reviewers — verified live on PR #9 (schr456 & sahnebar were requested automatically).

Quality

123 smoke checks + frontend check green · docs/meta only, no runtime code touched · signed (Verified ✓)

v3.6.3 — Storage-Dialog bleibt bei Eingabefehler offen

🐛 Kein Neu-Öffnen mehr bei falscher Eingabe

Gemeldet: Ein zu hoher oder ungültiger Wert im Storage-Erweiterungs-Dialog schloss das Fenster — man musste alles neu öffnen und eintippen.

Ursache: Die Validierung lief erst nach askConfirm, also nachdem der Dialog schon geschlossen war.

Jetzt: askConfirm() hat eine validate()-Funktion, die beim OK-Klick vor dem Schließen prüft. Bei einem Fehler bleibt der Dialog offen und zeigt die Meldung inline unter dem Formular — direkt korrigierbar. Nur bei gültiger Eingabe schließt er. Die drei Prüfungen (Wunschgröße > aktuell · TB > 0 · ≤ Max-LUN) laufen jetzt so; der Mechanismus ist generisch für weitere Formular-Dialoge nutzbar.

🔀 Erster Pull-Request-Merge

Diese Änderung lief als PR #7 durch die komplette CI (alle Checks grün) und wurde per Squash gemergt — der Auftakt der PR-basierten Historie, aus der OpenSSF Scorecard CI-Tests & Code-Review bewertet. Der Merge-Commit ist ebenfalls signiert (Verified).

Qualität

E2E im Headless-Browser verifiziert (99 TB bei 5 TB Max → Dialog bleibt offen + Inline-Fehler) · 123 Smoke-Checks + Frontend-Check grün · signiert (Verified ✓)

v3.6.2 — Fix: Auslastungs-Balken sichtbar (+ Check prueft es jetzt)

🐛 Die Auslastungs-Balken sind zurück

Gemeldet: Die Balkengrafiken in der Cluster-Liste — belegt und „in Reservierung" — waren verschwunden.

Ursache: Eine Regression aus der v3.6-Icon-Übernahme. Das Balken-Markup war im Icon-Branch auf <i class="bar-fill" style="--w:X%"> mit Ampel-Klassen (bg-ok/bg-warn/bg-crit) umgestellt — deren CSS-Regeln lagen aber in der bewusst nicht übernommenen tailwind-src.css. Folge: Füllbreite 0, keine Farbe. Die fehlenden 7 Regeln als schlichtes CSS ergänzt.

🔎 Und die eigentliche Lehre (danke für die Nachfrage!)

Der Frontend-Check prüfte bisher nur „läuft das JS fehlerfrei" — eine reine CSS-Regression wie unsichtbare Balken war für ihn unsichtbar. Das ist jetzt behoben: Der Check misst die tatsächlich gerenderte Balken-Breite und -Farbe im DOM. Beweisführung in beide Richtungen: entfernt man die .bar-fill-Regel, meldet er „Balken-Füllung hat 0px Breite"; entfernt man die Farb-Regeln, „ohne Farbe". Genau dieser v3.6-Fehler würde jetzt vor dem Release auffallen.

Qualität

123 Smoke-Checks + Frontend-Check (nun inkl. Balken-Rendering) grün · Deploy-Tags 3.6.2 · signiert (Verified ✓)

v3.6.1 — Fuzzing der Input-Parser + Fix: Storno-Dialog im Vordergrund

🐛 Fix: Storno-Dialog erschien hinter der Detailkarte

Gemeldet: Cluster anklicken → in der Detailkarte bei einer Reservierung „Storno" drücken → der Kommentar-Dialog ging hinter der Karte auf.

Ursache: Die Detailkarte lag auf z-index:20, die Dialoge nur auf z-index:10. Dialoge jetzt auf z-index:40 → liegen über allem (End-to-End im Browser verifiziert: card=20 modal=40).

🔬 Fuzzing der Parser für ungetrusteten Input (Scorecard: Fuzzing erfüllt)

Neu: tests/fuzz/fuzz_parsers.py fuzzt genau die Stellen, an denen das Dashboard fremde Daten parst:

• kapa/ldap.py BER/TLV-Decoder — der handgeschriebene Parser für rohe LDAPS-Bytes (also potenziell von einem bösartigen AD). Das Lehrbuch-Fuzzing-Ziel.
• _dn_to_cn (Distinguished Names) und parse_tag_json (vROps-Tag-JSON)

Zwei Modi, ehrlich gebaut:

• Coverage-guided mit Atheris (Dev/CI-Werkzeug, keine Laufzeit-Abhängigkeit) — Scorecards Fuzzing-Check erkennt das import atheris
• Standardbibliothek-Modus (--stdlib, ohne Zusatzsoftware) — läuft überall, wird bei jedem Smoke-Lauf 2.000 Runden mitgeprüft

Ergebnis: 30.000 Zufallsrunden lokal → 0 unerwartete Abstürze. Der Code war schon robust; Fuzzing sichert das dauerhaft ab und schließt den Scorecard-Fuzzing-Punkt mit echtem Nutzen statt Kosmetik.

(Optional als nächster Schritt: ClusterFuzzLite für kontinuierliches CI-Fuzzing — bringt aber eine Container-Build-Kette mit, daher bewusst noch nicht drin.)

Qualität

123 Smoke-Checks + Frontend-Check grün · Deploy-Tags 3.6.1 · Commit + Tag signiert (Verified ✓)

v3.6 — SVG-Icons statt Emoji (die Rosinen aus dem UI-Branch)

✨ Konsistente Icons — ohne Build-Kette

Aus dem Redesign-Branch des Kollegen (Danke, @schr456! 🎉) übernehmen wir das Beste — und lassen bewusst weg, was nicht zur Projektlinie passt:

Übernommen:

• 22 vendored Phosphor-Icons als Inline-SVGs (kein CDN, CSP unverändert) mit icon()-Helfer
• Alle Knopf-/Label-Emojis ersetzt: ✓→Häkchen, ✕→Kreuz, ⚙→Zahnrad, ⚠→Warnung, 📖→Buch, ⬇⬆→Download/Upload, ☀️🌙→Sonne/Mond — durchgängig gleiche Strichstärke statt Emoji-Zoo, der je nach OS anders aussieht
• 54 i18n-Einträge sauber nachgezogen (Arbeit des Kollegen, 1:1 übernommen)
• Bonus-Rosine: color-scheme koppelt native Browser-Controls ans Theme — das Kalender-Icon im Datums-Picker ist im Dark-Mode endlich sichtbar

Bewusst nicht übernommen: die Tailwind-Build-Kette (npm/package-lock/generiertes CSS) — das Projekt bleibt bei kein npm, kein Build, alles lesbarer Klartext im Repo. Der handgeschriebene <style>-Block lebt weiter; die Icons nutzen eine eigene kleine .icn-Klasse.

Qualität

122 Smoke-Checks + der frisch geschärfte Frontend-Check (testet jetzt auch die Detailkarte mit echten Daten) grün · README-Screenshots aktualisiert · Deploy-Tags 3.6.0 / Helm 1.6.0 · Commit + Tag signiert, Co-Autorschaft im Commit

v3.5.3 — Import-Datum-Mouseover auch in der Clusterliste

⏱ Konsequent zu Ende gedacht

Der Quellen-Selektor zeigt seit v3.4.1 das Import-Datum von Offline-Quellen im Mouseover — das Quellen-Badge in der Clusterliste behauptete bei denselben Clustern aber weiter „Datenquelle (vROps)". Jetzt:

• Offline-Cluster: Badge-Mouseover zeigt „Offline-Import: TT.MM.JJJJ" + dezentes ⏱
• Echte vROps-Cluster: behalten den bisherigen Hinweis
• Wirkt überall, wo das Badge auftaucht: Kapazitätsliste, VLAN-Suche, Reservierungen

Qualität

122 Smoke-Checks + Frontend-Check grün · beide Badge-Varianten live im Browser-DOM verifiziert · Commit + Tag signiert (Verified ✓)

v3.5.2 — Hotfix: Storage-Seite (Erweitern-Knopf, Stati, Quellen-Filter)

🔥 Hotfix: drei stille Regressionen auf der Storage-Seite

Gemeldet: Der Erweitern-Knopf war von der Storage-Seite verschwunden.

Ursache: Beim v3.0-Umzug auf den einen Pfadraum wechselte die Storage-Seite auf /api/v1/storage-requests — dessen (für externe Token-Nutzer gebaute) Antwort hat eine andere Form. Die Analyse fand gleich drei Probleme in dem Zweig:

1. enabled/max_lun_gb fehlten → alle Erweitern-/Anfrage-Knöpfe verschwanden (der gemeldete Bug)
2. Default nur „offene" Anfragen → erledigte fehlten seit v3.0 in der Übersicht
3. Kein Quellen-Sichtbarkeits-Filter für Sessions → Nutzer mit vROps-Quellen-Einschränkung sahen fremde Storage-Anfragen — ein Verstoß gegen die Quellen-Filter-Zusage (Sicherheitsaspekt) ⚠️

Fix: Sessions erhalten auf dem v1-Pfad wieder das UI-Verhalten (Flag, alle Stati, Quellen-Filter). Der Token-Vertrag bleibt unverändert (Default „offen", volle Sicht — wie dokumentiert fürs Storage-Team).

Qualität

3 neue Smoke-Checks — der Quellen-Filter-Test läuft mit echtem Login gegen die eingeschränkte Kennung → 122 gesamt, alle grün · UI-Beweis: 18 Erweitern-Knöpfe im DOM · Commit + Tag signiert (Verified ✓)

Update empfohlen — Punkt 3 betrifft Installationen, die den vROps-Quellen-Filter je Nutzer/Gruppe einsetzen.

v3.5.1 — Hygiene-Sweep: 50+ Code-Scanning-Befunde behoben

🧹 Großreinemachen im Findings-Board

Die Security-Workflows waren grün — aber dahinter sammelten sich 78 offene Code-Scanning-Befunde. Dieser Release behebt über 50 davon durch echte Fixes, nicht durch Wegklicken:

Kategorie	Fix
25 tote Importe	entfernt — überwiegend Artefakte des v3-Modul-Schnitts (eigene AST-Analyse fand sogar mehr als CodeQL)
9 offene Datei-Handles	with-Statements bzw. close() im finally für Popen-Logdateien
13× except: pass	→ idiomatisches contextlib.suppress(...) mit Begründungskommentar
7 gemischte Returns	Dispatcher + v1-Handler in kapa/api.py enden jetzt explizit
K8s-Härtung	CPU-Limits, runAsUser/runAsGroup/fsGroup: 10001 (>10000) — Manifeste und Helm-Chart
nginx-Vorlagen	ssl_protocols TLSv1.2 TLSv1.3 (Legacy-TLS aus)
Test-AD	HEALTHCHECK im Dockerfile
4 bewusst dynamische URLs	nosemgrep-Annotation mit Begründung (vROps-Client, Webhooks, Dev-Seed)

Bonus: Der Import-Wächter aus v3.2.1 kennt jetzt Walrus-Zuweisungen — und hatte die neuen LOGF := open(...)-Handles prompt korrekt beanstandet. Der Wächter erzieht inzwischen seinen Autor. 🤖

Betrieb (K8s-Nutzer)

runAsUser wechselt von 1001 auf 10001 — dank fsGroup und g=u-Rechten im Image transparent; bestehende PVC-Daten übernimmt die fsGroup-Zuweisung beim Pod-Start.

Qualität

120 Smoke-Checks + Headless-Browser-Check grün · Deploy-Tags 3.5.1 · Commit + Tag signiert (Verified ✓)

v3.5 — Import & Export als eigener Reiter

🗂 Aufgeräumt: Import & Export ziehen um

Die Toolbar oben rechts war überladen — und der JSON-Import-Knopf (der den kompletten Reservierungs-Bestand ersetzt) stand dort einen Klick neben dem harmlosen Export. Jetzt gibt es einen eigenen Reiter „Import & Export" zwischen Statistik und Verwaltung (Deep-Link #import-export):

Abschnitt	Inhalt
Kapazität	Cluster-Übersicht als CSV — Rolle und Quellen-Filter greifen serverseitig
Reservierungen	CSV (Excel) · JSON-Export · JSON-Import (nur Admin) — jetzt mit deutlichem Warnhinweis, dass der Import den Bestand ersetzt
Automatisierung	Verweis auf die API-Doku — alles hier ist auch per Bearer-Token skriptbar

• Die Toolbar behält nur noch Refresh, Status und Timer
• Statistik-CSV bleibt im Statistik-Reiter (bewusste Entscheidung — dort ist der Kontext)
• Der Kapazitäts-CSV-Export ist damit erstmals im UI auffindbar (gab es bisher nur „geheim" per API)
• Reiter in der statischen Demo ausgeblendet; zweisprachig DE/EN; Benutzerhandbuch + README aktualisiert

Qualität

120 Smoke-Checks grün · Browser-E2E: Tab-Wechsel, View, Admin-Block und Deep-Link verifiziert · Deploy-Tags 3.5.0 / Helm 1.5.0 · Commit + Tag signiert (Verified ✓)

v3.4.2 — Import-Robustheit (und Export-Entwarnung)

Der Verdacht: Export bei leeren Daten — Entwarnung ✅

Geprüft wurden alle Export-Wege oben rechts im Leer-Zustand (0 Reservierungen):

• CSV-Export DE und EN → sauberes 200, nur Kopfzeile
• JSON-Export (exportRes) → leere Liste [], im Headless-Browser verifiziert: kein Fehler
• Statistik- und Daten-CSV → ebenfalls sauber
• In der statischen Demo ist der CSV-Knopf ohnehin ausgeblendet

Kein Bug im Export.

Der echte Fund: der Nachbar-Knopf 🔍

Der JSON-Import („Reservierungen importieren") parste die Datei ohne Fehlerbehandlung: Wer eine kaputte oder Nicht-JSON-Datei auswählte, bekam gar keine Rückmeldung — der Vorgang brach still ab (unbehandelte Promise-Rejection in der Konsole). Das konnte durchaus wie „der Export/Import ist kaputt" wirken.

Jetzt: saubere Meldung „Ungültige Datei (kein JSON)." (DE/EN).

Qualität

119 Smoke-Checks + Frontend-Check grün · Deploy-Tags 3.4.2 · Commit + Tag signiert (Verified ✓)