# DH-001: überprüfter Ausgangsstand und Findings

Stand: 24. Oktober 2026. Grundlage ist der tatsächlich gelesene Quellcode,
nicht der Zielkatalog. Der unveränderte Masterplan steht in
`DECENTRALHUB_CODEX_MASTERPLAN.md`; verbindliche Priorität ist dessen §16:
Bestandsaufnahme → kanonisches Format → lokale Persistenz, danach sichere Gates.

## Module vor dieser Änderung

| Modul | Tatsächliche Funktion | Grenze |
|---|---|---|
| `cmd/decentralhub/main.go` | CLI, Ed25519 DDP/0.1, JSON-Index, Peer-HTTP, MCP | Ein Prozess; kein Remote-Repo-Transport/AuthZ |
| `internal/localrepo/store.go` | Offline-Init/Commit/Log/Verify/Export, raw SHA-256 v1 | Linearer HEAD, keine Signatur/Ref-Autorisierung |
| `internal/localrepo/browser.go` | begrenzte, eingeschlossene Snapshot-Reads | nur 50 Stände, kein Live-Arbeitsbaum |
| `internal/localrepo/ignore.go` | gitignore-artige Quelltextauswahl | kein Git-Index, keine vollständige Git-Semantik |
| `cmd/decentralhub/private.go`, `templates.go` | deutsche private Browseransicht | Loopback, lesend, keine Teamarbeit |
| `*_test.go` | Fixtures für Offline/Hash/Peer/UI/Pfade/Privacy | kein echter Windows-/Power-Cut-Test |

Die initiale Codebestandsaufnahme und reproduzierbaren Sicherheitsfälle verwenden
ausschließlich Fixtures. Anschließend wurden lokale bereits vorhandene registrierte
Snapshot-Speicher mit der neuen CLI lesend verifiziert; alle HEAD-IDs blieben
unverändert. Dabei wurden gespeicherte .dh-Objekte, keine Live-Arbeitsdateien gelesen.
Keine produktiven Snapshots oder Registry-Daten wurden geändert.

## Reproduzierbare Findings und Behandlung

| ID | Befund vor Änderung | Reproduktion / Regression | Behandlung |
|---|---|---|---|
| F-001 | `put` akzeptiert existierende Hash-Datei ohne Inhaltsprüfung | vorhandenes Objekt manipulieren, identischen Inhalt erneut committen | DH-003 prüft bestehende Objekte; beschädigte Daten nicht überschreiben |
| F-002 | `HEAD.tmp` und Snapshot-Kopie ohne fsync; Objektverzeichnisse nicht synchronisiert | Abbruch an jeder Commit-Persistenzgrenze | DH-003 durables Objekt vor atomarem HEAD, Fault-Injection |
| F-003 | parallele Prozesse teilen `HEAD.tmp`, verlieren Historie | zwei Commit-Prozesse auf ein Fixture | exklusive OS-Prozesssperre, CAS, Sperre endet beim Prozessabbruch |
| F-004 | CLI-Reads erlauben Metadaten-Symlinks/ungegrenzte Objektdateien | .dh-/Objekt-Symlink, übergroßes Objekt | eingeschlossene `os.Root`-Reads und Größenlimits |
| F-005 | Export prüft Pfade während des Schreibens; falsche Größe unbemerkt | manipuliertes Manifest exportieren | vorab validieren; neues exklusives Ziel; kein Überschreiben |
| F-006 | Hash gleich für Blob und Snapshot mit identischen Bytes | Typverwechslung im raw v1 möglich | DH-002 neuer getrennter Namespace; v1 bleibt kompatibel |
| F-007 | Peer-Transport erbt ProxyFromEnvironment | Proxy kann Hostprüfung verschieben | gezielter Transport-Härtungstest; keine allgemeine Public-Freigabe |
| F-008 | öffentlicher Event-Endpunkt ohne AuthZ/Quotas; Index pro Event komplett neu | fremde korrekt selbstsignierte Events akzeptiert | weiterhin experimentell, kein öffentlicher Produktivbetrieb |
| F-009 | Node-JSON-Persistenz/Identity nicht transaktional multiprozessfähig | parallele CLI-/Server-Schreiber | separater offener Gate; nicht mit lokalem Repo-Lock verwechseln |
| F-010 | Schlüssel unverschlüsselt auf Dateisystem; keine Delegation/Revocation | `identity.key`-Modell | DH-004-Spezifikation, keine vorgetäuschte sichere Geräteablage |

Die vier unabhängigen `TestReview*`-Fälle reproduzierten vor dem Fix tatsächlich
alle vier Fehler: korruptes vorhandenes Blob akzeptiert, `.dh`-Symlink verfolgt,
Export-Ziel nach Fehler hinterlassen und erfolgreiche parallele Commits aus der
HEAD-Historie verloren. Dieselben Tests bestehen nach DH-003.

## Migration und Prüfgrenzen

Bestehende `.dh/objects`, Snapshot-JSONs, IDs und HEAD bleiben unverändert.
Keine automatische Konvertierung nach DOP/1, keine Hintergrundmigration, keine
neuen Snapshots in realen Repos. Alt-Daten werden durch eine feste v1-Fixture
und Browser-/CLI-Regressionstests abgedeckt. Vor späterer Migration: verifiziertes
Backup, gesonderter neuer Namespace, vollständiger Vergleich, expliziter Opt-in,
erhaltener alter HEAD und getesteter Rollback.

Echte Windows-Tests, Stromausfall auf realen Dateisystemen, Last-/NFS-Tests,
Schlüsselkeystore, E2EE und unabhängiges Security Review sind offene Gates.
Aktuelle ausgeführte Checks und der genaue Abschlussstatus stehen in
`VALIDATION.md` und `IMPLEMENTATION_STATUS.md`.