Skip to content

Wartung 2026-04-06: Architektur-Compliance und Verbesserungen #1

@stho32

Description

@stho32

Wartung 2026-04-06: Architektur-Compliance und Verbesserungen

1. Repository-Analyse

Eigenschaft Wert
Sprache Rust (Edition 2021)
Typ Windows-CLI-Tool
Build-System Cargo
Version 0.1.0
Quellcode 3 Dateien: main.rs (29 Zeilen), lib.rs (1 Zeile), dumper.rs (155 Zeilen + 284 Zeilen Tests)
Unit-Tests 28 Tests in dumper.rs
Integration-Tests Keine (tests/-Verzeichnis fehlt)
Architektur-Vorlage rust-cli

Verzeichnisstruktur (Ist)

regdumpy/
  .github/workflows/ci-release.yml
  Anforderungen/
    R00003-Wartung-2026-04-03.md
  docs/requirements/
    r0001-console-application and parameters.md
    r0002-github-build-and-automatic-release.md
  src/
    main.rs
    lib.rs
    dumper.rs
  Cargo.toml / Cargo.lock
  CLAUDE.md
  README.md
  LICENSE
  .gitignore

2. Architektur-Compliance (Soll vs. Ist)

Abgleich gegen die Architektur-Vorlage rust-cli (~/.claude/app-architectures/rust-cli/).

Bereich Soll (rust-cli) Ist (regdumpy) Status
Projektstruktur src/main.rs, src/lib.rs, src/<domain>.rs, Anforderungen/, docs/, .github/workflows/ Alle vorhanden ✅ Konform
Entry Point (main.rs) Nur CLI-Parsing (clap derive), Pre-flight-Checks, Delegation an lib, main() -> Result<()> Exakt so umgesetzt: clap Parser, elevation check, delegation an dumper::dump_registry, returns Result<()> ✅ Konform
Module Root (lib.rs) Minimal, nur pub mod Deklarationen pub mod dumper; -- eine Zeile ✅ Konform
Domain Module Public API + private Helfer + #[cfg(test)] mod tests am Ende dumper.rs: Public dump_registry(), private recurse_key, match_value_to_json, match_root, decode_utf16le. Tests-Block am Ende. ✅ Konform
clap derive clap 4.5 mit derive Feature, #[derive(Parser)] Struct clap = { version = "4.5", features = ["derive"] }, Cli Struct mit #[derive(Parser)] ✅ Konform
Error Handling anyhow::Result in App-Code, .context() fuer Kontext, bail! fuer fruehes Abbrechen anyhow verwendet, .context("create output file"), anyhow::bail! in match_root ✅ Konform
Graceful Degradation Ungueltige Daten in Output darstellen, nicht paniken RegValueJson::Invalid { reason } fuer ungueltige DWORD/QWORD/UTF-16. Unlesbare Values/Subkeys werden uebersprungen/markiert. ✅ Konform
Serialisierung serde + serde_json mit derive serde = { version = "1.0", features = ["derive"] }, #[derive(Serialize)] auf RegEntry und RegValueJson ✅ Konform
Unit-Tests In-Module #[cfg(test)] mod tests, Helper-Funktionen, alle Varianten + Edge Cases testen 28 Tests vorhanden, rv() Helper, alle RegValue-Typen + Edge Cases (zero, max, invalid, unicode, CJK, empty) ✅ Konform
Integration-Tests tests/-Verzeichnis mit externen Crate-Tests ❌ Kein tests/-Verzeichnis. Ein Integration-artiger Test (test_dump_registry_hkcu) existiert, liegt aber im Unit-Test-Block. ⚠️ Abweichung
CI/CD Workflow 4 Jobs: check (fmt+clippy), test, audit, release. dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2, Tag-basiertes Release Alle 4 Jobs vorhanden und korrekt konfiguriert. Moderne Actions. Tag-basiertes Release mit v*. ✅ Konform
Dependabot .github/dependabot.yml fuer cargo + github-actions ❌ Nicht vorhanden ⚠️ Abweichung
Cargo.toml Metadaten authors, description, license, repository, keywords, categories Nur name, version, edition vorhanden. Metadaten fuer crates.io fehlen. ⚠️ Abweichung
Plattform-spezifische Dependencies [target.cfg(windows).dependencies] Alle Windows-Dependencies stehen unter [dependencies] ohne cfg(windows) Guard ⚠️ Abweichung
.gitignore Umfassend: target, exe, pdb, IDE, OS, output files Vorhanden und vollstaendig ✅ Konform
CLAUDE.md Build-Befehle, Architektur, Konventionen Vorhanden und korrekt strukturiert ✅ Konform
README.md + LICENSE Features, Installation, Usage, Development, MIT License Beides vorhanden und vollstaendig ✅ Konform

Compliance-Zusammenfassung

  • 13 von 17 Bereichen konform (76%)
  • 4 Abweichungen: Integration-Tests, Dependabot, Cargo.toml-Metadaten, cfg(windows)

3. Fortschritt seit letzter Wartung (2026-04-03)

Die Wartung vom 2026-04-03 hatte 11 Vorschlaege. Aktueller Status:

# Vorschlag Status
1 winreg aktualisieren (0.11 -> 0.56) ✅ Erledigt
2 REG_SZ UTF-16LE Bug fixen ✅ Erledigt
3 Test-Coverage erhoehen ✅ Erledigt (3 -> 28 Tests)
4 LICENSE-Datei erstellen ✅ Erledigt
5 Deprecated GitHub Actions ersetzen ✅ Erledigt
6 Clippy + rustfmt in CI ✅ Erledigt
7 Semantische Versionierung ✅ Erledigt
8 CLAUDE.md erstellen ✅ Erledigt
9 .gitignore erweitern ✅ Erledigt
10 REG_MULTI_SZ Support ✅ Erledigt
11 Dependency-Audit in CI ✅ Erledigt

Alle 11 Vorschlaege aus der letzten Wartung wurden umgesetzt.


4. Verbesserungsvorschlaege (Neu)

Vorschlag 1: Integration-Tests in tests/-Verzeichnis verschieben

Prioritaet: Mittel | Aufwand: Klein | Kategorie: Testing / Architektur-Compliance

Ist: Der Integration-Test test_dump_registry_hkcu liegt im Unit-Test-Block in dumper.rs. Laut Architektur-Vorlage gehoeren Integration-Tests in ein separates tests/-Verzeichnis.

Soll: tests/integration_test.rs anlegen und den Test dorthin verschieben. Der Test importiert ueber die public API (use regdumpy::dumper::dump_registry;).

Grund: Saubere Trennung von Unit- und Integrationstests. Integrationstests testen die public API als externe Crate.


Vorschlag 2: Dependabot konfigurieren

Prioritaet: Mittel | Aufwand: Klein | Kategorie: CI/CD / Sicherheit

Ist: Keine .github/dependabot.yml vorhanden. Dependency-Updates muessen manuell geprueft werden.

Soll: Dependabot fuer Cargo- und GitHub-Actions-Updates einrichten (woechentlich).

Grund: Automatische PRs bei neuen Dependency-Versionen und Sicherheitsupdates.


Vorschlag 3: Cargo.toml-Metadaten ergaenzen

Prioritaet: Niedrig | Aufwand: Klein | Kategorie: Dokumentation / Distribution

Ist: Cargo.toml enthaelt nur name, version, edition. Metadaten fuer crates.io fehlen.

Soll: authors, description, license, repository, keywords, categories ergaenzen.

Grund: Vollstaendige Metadaten ermoeglichen spaeteres Publizieren auf crates.io und verbessern die Auffindbarkeit.


Vorschlag 4: Windows-Dependencies mit cfg(windows) schuetzen

Prioritaet: Niedrig | Aufwand: Klein | Kategorie: Code-Qualitaet / Architektur-Compliance

Ist: winreg und is_elevated stehen unter [dependencies] ohne Plattform-Guard. Kompilation auf Linux/macOS schlaegt fehl.

Soll: Windows-spezifische Crates unter [target.cfg(windows).dependencies] verschieben.

Grund: Best Practice laut Architektur-Vorlage und verhindert kryptische Build-Fehler auf anderen Plattformen.


Vorschlag 5: Doc Comments auf private Hilfsfunktionen

Prioritaet: Niedrig | Aufwand: Klein | Kategorie: Code-Qualitaet / Lesbarkeit

Ist: Nur dump_registry hat einen Doc-Comment. Private Funktionen (recurse_key, decode_utf16le, match_value_to_json, match_root) sind undokumentiert.

Soll: Kurze ///-Kommentare auf allen nicht-trivialen Funktionen.

Grund: Erleichtert das Verstaendnis bei spaeterer Wartung.


Zusammenfassung

Nr Vorschlag Prioritaet Aufwand Kategorie
1 Integration-Tests in tests/ verschieben Mittel Klein Testing
2 Dependabot konfigurieren Mittel Klein CI/CD
3 Cargo.toml-Metadaten ergaenzen Niedrig Klein Dokumentation
4 Windows-Dependencies mit cfg(windows) Niedrig Klein Code-Qualitaet
5 Doc Comments auf private Funktionen Niedrig Klein Code-Qualitaet

Empfohlene Reihenfolge

  1. Vorschlag 2 -- Dependabot (5 Minuten, automatische Sicherheitsupdates)
  2. Vorschlag 1 -- Integration-Tests verschieben (Architektur-Compliance)
  3. Vorschlag 3 -- Cargo.toml-Metadaten (Quick Win)
  4. Vorschlag 4 -- cfg(windows) Guard (Quick Win)
  5. Vorschlag 5 -- Doc Comments (bei Gelegenheit)

Gesamtbewertung

Das Projekt befindet sich in einem guten Zustand. Alle 11 kritischen Punkte aus der letzten Wartung (2026-04-03) wurden behoben. Die Architektur-Compliance liegt bei 76% (13/17). Die verbleibenden 4 Abweichungen sind alle mit niedrigem bis mittlerem Aufwand behebbar und betreffen keine Kernfunktionalitaet.

Die Code-Qualitaet ist hoch: 28 Unit-Tests, sauberes Error-Handling mit anyhow, korrekte UTF-16LE-Dekodierung, vollstaendige CI/CD-Pipeline mit Lint, Test, Audit und Release. Es gibt keine Bugs, keine Sicherheitsprobleme und keine veralteten Dependencies.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions