# Legacy-Backup ausdrücklich in ein neues DOP-Repository importieren Experimenteller Linux-Workflow, neue native Speicherwurzel ohne Arbeitsbaum. Das bestehende v1-Repository und sein Backup bleiben bytegleich. Es gibt keine automatische Registrierung, Veröffentlichung, Remote-Verbindung oder Änderung eines bestehenden DOP-Stores. Die beiden Repository-Namensräume bleiben getrennt. ## Vorbereitung Ein vollständiges Backup erstellen und seine beiden ausgegebenen Pins separat aufbewahren: ```sh mf backup --workdir LEGACY_PROJECT --dest NEW_BACKUP mf backup-inspect --source NEW_BACKUP --expected-head LEGACY_HEAD --expected-manifest BACKUP_MANIFEST_SHA256 ``` Der HEAD allein bindet weder detached Objekte noch die mutable `.dh/ignore`. Die Manifestpins müssen aus einem vertrauenswürdigen Kanal stammen. Ein leerer HEAD wird als `--expected-head ""` ausdrücklich übergeben. Eine bestehende geschützte Owneridentität verwenden; sie ist die neue explizite Importautorität. Ein Discovery-Key wird nicht still als Owner ausgewählt. ```sh mf native genesis --data OWNER_KEYS --dest NEW_GENESIS.json ``` Neue `repo_id` und `owner` aus diesem bewusst erzeugten Genesis unabhängig aufbewahren. Der Owner beweist Schlüsselkontrolle, keine historische natürliche Person, Firma oder ursprüngliche Autorschaft des Legacycodes. ## Import und vollständige Prüfung ```sh mf native-migrate --source NEW_BACKUP --dest NEW_NATIVE_STORE --expected-head LEGACY_HEAD --expected-manifest BACKUP_MANIFEST_SHA256 --genesis NEW_GENESIS.json --repo NEW_REPO_ID --owner-key OWNER_PUBLIC --data OWNER_KEYS mf native-import-verify --store NEW_NATIVE_STORE --expected-head LEGACY_HEAD --expected-manifest BACKUP_MANIFEST_SHA256 --genesis NEW_GENESIS.json --repo NEW_REPO_ID --owner-key OWNER_PUBLIC --dest NEW_EVIDENCE.json ``` Das Importziel muss fehlen und außerhalb des Quellbackups liegen, auch hinter Pfadaliasen. Der private Stagingbaum wird erst nach vollständiger Vorprüfung erzeugt. Originale Objekte, Raw-Snapshots, Manifest, optionales HEAD und Ignore- Overrides bleiben als gehashte DOP-Blobs erhalten. Ein vollständiges signiertes Mapping bindet jede alte und neue ID. Die ursprünglichen Nanosekunden- und Timezone-Zeichenfolgen bleiben in den Originalbytes und im Mapping erhalten. Neue Trees erhalten Filemode0644 und Dirmode0755, da v1 keine Executable-Rechte gespeichert hat. Commits binden ihre ursprünglichen Nachrichten, die ursprüngliche sekundengenaue Zeitbehauptung und vollständig konvertierte Eltern; Author ist ausdrücklich `importer:OWNER_PUBLIC`. Ungültige Unicodebytes/isolierte Surrogate, nicht darstellbare Metadaten oder Pfade werden abgelehnt und nicht normalisiert. `main` zeigt auf den konvertierten Source-HEAD. Jede weitere maximale abgetrennte Historie bleibt als `imported-LEGACY_SNAPSHOT_HASH` erhalten. Unreferenzierte Objekte werden ebenfalls vollständig übernommen. Die Ausgabe nennt Sourcepins, neue Repo-/Genesis-/Mapping-/Attest-IDs und alle Branches. Die Verifikation prüft die Ownersignatur und berechnet zusätzlich die komplette ursprüngliche Manifestinventur, alle Sourcehashes, alle Snapshot-Eltern sowie jeden neuen Tree und Commit erneut. Sie benötigt das ursprüngliche Backup danach nicht mehr, weil dessen Rohbytes unverändert mitgeführt werden. Der optionale Evidenzexport wird geschützt ohne Ersetzen angelegt. Ein Importattest erteilt keine Review-, Release-, Team- oder Merge-Capability. ## Grenzen und Fehler Quelle maximal1GiB/100000Inventareinträge, höchstens16384Snapshots,128Branches; Mapping maximal16MiB, Attest128KiB. Globale Pfad-/Visitlimits werden vor Stage- Anlage geprüft. Rohquellen und konvertierte Objekte zählen zusätzlich in die vorhandene native1GiB/100000Dateiquota. Ein passendes Quellbackup kann deshalb für den zusätzlichen Zielumfang zu groß sein; es wird nichts still weggelassen. Vor Publish wird der neue Store erneut geöffnet und vollständig geprüft, einschließlich des authentisierten Originalmanifestes. Linux veröffentlicht atomar ohne Ersetzen; zwei gleichzeitige Importe zum selben Ziel haben höchstens einen Gewinner. Nicht unterstützte Plattformen scheitern geschlossen. Ein Fehler nach Publish kann `ErrUncertain` melden: das mögliche Ziel bleibt erhalten, und es wird kein Erfolgsergebnis ausgegeben. Mit den bekannten Pins erneut öffnen und verifizieren, bevor erneut gehandelt wird. Bestehende `.dh`-Writer und neue native Refs bleiben getrennte Workflows. Private Remote-Synchronisation transportiert derzeit ausdrücklich v1-Backups; dieser Import schaltet dafür keinen DOP-Adapter frei. Zurück zum alten Workflow heißt das unveränderte Legacyprojekt weiterverwenden. Neue DOP-Arbeit wird dadurch nicht automatisch in v1 zurückkonvertiert. Geschützte Reviews und Merge-Apply, Browseraktionen sowie Hardware-/Security-Abnahme sind separate Arbeitspakete.