# Native DOP-Repositories per CLI Experimenteller Linux-Workflow. Dieser neue Store ist von den bestehenden `.dh`-Snapshots und vom privaten Snapshottransport getrennt. Kein Befehl migriert oder veröffentlicht bestehende Projekte automatisch. Der Store hält keine privaten Schlüssel. Owner und Repo-ID müssen beim Öffnen ausdrücklich gepinnt sein. ## Anlegen und Objekte prüfen Eine bestehende geschützte Ed25519-Identität verwenden; Schlüsselverzeichnis außerhalb des Repositories halten. Alle Ausgabedateien müssen neu sein und in einem vertrauenswürdigen bestehenden Verzeichnis liegen. `STORE` ist ein bereits vorhandenes leeres Verzeichnis. ```sh mf native genesis --data OWNER_KEY_DIR --dest genesis.json # repo_id und owner aus der lokalen Ausgabe unabhängig aufbewahren. mf native init --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --file genesis.json mf native object --kind blob --file source.txt --dest blob.dop mf native put --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --file blob.dop ``` `native object` erzeugt kanonische DOP/1-Envelopes für `blob`, `tree`, `commit` oder `ref`. Metadaten verwenden die typisierten JSON-Felder aus [DOP/1](../protocol/DOP-1.md). `put` validiert Typ, Hash und Quota, veröffentlicht aber keinen Branch. `get --id ID --dest NEW_FILE` liest ein geprüftes Envelope; `graph --id COMMIT_ID` prüft den vollständigen Commit-DAG einschließlich aller referenzierten Bäume und Blobs. Ein Commit-Authorfeld bleibt eine Behauptung. ## Signierte Branches mit CAS Für den ersten Branch enthält eine explizit geprüfte Datei `expected.json`: ```json {"name":"main","target":"","update_id":"","generation":0} ``` Ein neues Refobjekt bindet denselben Namen, den vollständigen Zielcommit, `previous:""` und `generation:1`. Nach `native object --kind ref` und `native put` seine DOP-ID verwenden: ```sh mf native ref-sign --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --data OWNER_KEY_DIR --id REF_OBJECT_ID --expected expected.json --dest signed-update.json mf native ref-apply --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --expected expected.json --file signed-update.json mf native ref --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --name main ``` Die letzte Ausgabe hat die Felder des nächsten `ExpectedRef`-Tokens. Für ein Advance müssen Generation um eins steigen und sowohl vorheriger Zielcommit als auch vorherige signierte Update-ID exakt gebunden sein. Das Signieren verändert keinen Ref; Apply prüft CAS und vollständigen Graph erneut. Nur der Owner darf Refs signieren; Geräte-/Review-/Teamrechte sind hier noch nicht integriert. Ein identisches bereits angewandtes Update kann idempotent wiederholt werden. Stale oder divergente Updates dürfen bestehende Historie nicht ersetzen. `native import --expected TOKEN --file SIGNED_UPDATE` liefert bei Divergenz eine Vorschau ohne Refmutation. Zum Erhalten der eingehenden Spitze unter `incoming-` zusätzlich `--incoming SIGNED_INCOMING_UPDATE` übergeben. Dieses Update muss eigens für den neuen Incoming-Ref signiert sein. Die ursprüngliche lokale Spitze wird bei der Veröffentlichung erneut per CAS geprüft. Import kopiert keine Objekte aus dem Netz und überschreibt keine Arbeitsdateien; die vollständigen Objekte müssen bereits lokal vorliegen. ## Grenzen und Recovery Owner-signiertes Genesis und Branch-Signaturen beweisen Schlüsselkontrolle, keine rechtliche Person oder Vertrauenswürdigkeit des Codes. Keine Ausführung, Shell, Netzwerkübertragung, automatische GC oder Force-Updates. Quotas zählen auch Orphans, Sidecars und ausstehende Schreibreservierungen. `native recover-reservations` prüft verwaiste Reservierungen und lehnt aktive Writer ab. Bei ungewissem Commitfehler den Store erneut öffnen und den aktuellen Ref prüfen, bevor erneut gehandelt wird. Fehlender State wird niemals aus Objekten neu initialisiert. Windows-Crossbuilds belegen keinen funktionierenden nativen Store; nicht unterstützte Laufzeitplattformen scheitern geschlossen. Legacy-Migration, Reviews, Merge-Anwendung und Browseraktionen sind weitere Pakete des [Branchdesigns](NATIVE_BRANCH_DESIGN.md). Der aktuelle Snapshotbrowser bleibt an die bestehenden `.dh`-Stores gebunden. ## Three-Way-Merge lokal planen ```sh mf native merge-plan --store STORE --repo REPO_ID --owner-key OWNER_PUBLIC --ours LOCAL_COMMIT --theirs INCOMING_COMMIT --dest NEW_PLAN.json ``` Der Planer prüft beide vollständigen DAGs, bestimmt einen eindeutigen besten Mergebase und verbindet nicht überlappende kleine Textänderungen. Fehlende oder mehrdeutige Bases, Binär-/Typ-/Lösch-/Modekonflikte und überlappende Textänderungen erscheinen ausdrücklich im Plan. Er erhält genaue Zeilenbytes einschließlich CRLF und fehlender letzter Leerzeile. Zeitstempel bestimmen keine Gewinner. Die neue lokale Datei enthält Plan-ID, gebundene Eltern/Bases, Ergebnisbaum, neu berechnete Objekte und Konfliktdetails. Die Ausgabe zeigt ID und Planbody. Die vollständige Plan-Datei ist auf 32 MiB begrenzt; Base64-Expansion wird vor der vollständigen JSON-Allokation gezählt. Größere Resultate scheitern geschlossen. Die Datei kann private Inhalte enthalten und wird geschützt ohne Ersetzen angelegt. Der native Store, Branches und Arbeitsdateien bleiben unverändert; keine Objekte werden allein durch das Planen installiert. Ein Planhash bindet Inhalte, autorisiert aber keinen Merge. Review/Resolution/Apply sind ein separates Folgepaket. Ressourcenlimits und konservative Konfliktregeln stehen im [Branchdesign](NATIVE_BRANCH_DESIGN.md). ## Round 4: conflict decisions `native namespace-preview` und der optionale `--namespace-steps`-Pfad erweitern die reine Auflösung für weitere aktuelle Namenskonflikte. Siehe [Namespace-Vertrag](NATIVE_NAMESPACE_CLI.md); das ursprüngliche `/1`-Verhalten bleibt unverändert. `native merge-resolve` produces a new, replay-verifiable local artifact from an exact conflicted plan and explicit path decisions. See [the resolution contract](NATIVE_RESOLUTION_CLI.md) for arguments, canonical decision JSON, limits and the still separate review/apply integration.