# Native DOP-Branches, Konflikte und Merge Nachtrag Runde 4: [Explizite Konfliktauflösung](NATIVE_RESOLUTION_CLI.md) ist als getrennte pure Bibliothek plus `native merge-resolve` implementiert. Das ursprüngliche Plan-ID/DAG-Replay, Entscheidungen und Ergebnisbaum sind gebunden; die reinen Artefaktbefehle verändern Ref-/Objektstore nicht. [Geschützter Review/Apply](RESOLVED_REVIEW_CLI.md) und eine zusätzliche [versionierte Namenskonfliktphase](NATIVE_NAMESPACE_CLI.md) sind inzwischen separat implementiert. Die älteren unten schematisch genannten Storemethoden bleiben Entwurf; maßgeblich sind die konkreten APIs der verlinkten Dokumente. Stand 25. Oktober 2026. **N1/N2 owner-only Store/CLI implementiert und lokal geprüft; N3 pure Planung unabhängig lokal geprüft.** Kein vollständiges Branch-/Review-/Mergeprodukt. Bestehende lokale Snapshots, PUBLIC-Sync und ihre IDs bleiben unverändert; Hardware- und externe Sicherheitsabnahmen bleiben separat. ## Quellbefund und Entscheidung `internal/objects/objects.go` und `protocol/DOP-1.md` implementieren bereits kanonische Blob-/Tree-/Commit-/Ref-Inhalte. Commit hat bis zu 16 unterschiedliche **geordnete** Eltern. Author ist bisher ein Claim, kein Signaturnachweis. Ref ist nur ein kanonisches Updateobjekt, kein autorisierter Store. Der native v1-Store `internal/localrepo` hat dagegen eine einzelne HEAD und lineare `dh-snapshot/1`- Historie. `internal/remotesync/bridge_transfer.go` ist ein ausdrücklich öffentlicher Snapshotadapter mit separater Importattestierung und darf nicht private komplette Historie automatisch veröffentlichen. Entscheidung: neues `internal/nativerepo` mit ausdrücklich initialisierter DOP-Speicherwurzel außerhalb bestehender `.dh`-Metadaten. Der Nutzer wählt ein neues Zielverzeichnis; v1 bleibt lesbar, nutzbar und bytegleich. Kein automatisches Feature-Erkennen, kein Lesen von DOPbytes als Legacy-JSON und kein austauschbarer `HEAD`-Pfad. Providerregistry ist hierfür nicht begründet. Neue native Repo-ID: `mf:native:` plus 64 kleine Hexzeichen aus 32 Zufallsbytes. Ein owner-signiertes Genesisdokument bindet ID, Ownerpublickey und Version. Diese ID ersetzt weder vorhandene `dh:repo:`-IDs noch private Transport-IDs. Eine Transportassoziation bindet später beide IDs ausdrücklich im verschlüsselten Manifest; kein automatisches Public-Discovery. ## N1: minimaler DOP-Store mit atomaren Refs Dateien `internal/nativerepo/{types,codec,store,graph}.go` und eigene Tests; bestehender `internal/objects`-Codec unverändert. Layout: ```text new-native-root/ native-state.json # Genesis + Diskreservierungen, eigener state.Store native-refs.json # owner-only Refs + signierte Updatehistorie objects/aa/<62hex> # komplette DOP/1 Envelopebytes attestations/<64hex> # kanonische signierte Sidecars staging/ # nur begrenzte nicht referenzierte Vorbereitung ``` Der implementierte `native-state.json` bindet Schema `mf.native-state/1`, signierte Genesis und Diskreservierungen. `native-refs.json` bindet Repo/Owner/ Genesis exakt sowie Refs und signierte Updatehistorie; beide Dateien sind je 16 MiB begrenzt. Anfangslimits sind 128 Branches und 4096 Refupdates. Fehlendes/korruptes Refstate wird bei Open nicht aus Objekten repariert. Teilweise Initialisierung bleibt geschlossen, nicht implizit erfolgreich. Der Scope ist owner-only: keine Membership-/Delegations-/Reviewautorität. Solche künftigen Autoritäten müssen mit Refs im selben Autorisierungstransaktionsraum liegen; geplante Proposal-/Reviewlimits sind noch keine Runtimefunktion. Ein Refrecord enthält Name, TargetCommitID, Generation und LastUpdateID. Namen verwenden `objects.PortableName` und zusätzlich eindeutige `objects.FoldKey`- Schlüssel über die gesamte Refliste; im ersten Schnitt keine Slashhierarchie. Ein Refupdate ist ein unverändertes DOP/1-Refobjekt plus signierter Sidecar, der Repo, Refobjekt-ID, vorherige **Update-ID**, Generation, Handlung, Owner und festen Scope `owner/ref-write` bindet. ACL-/Delegationsbindungen folgen erst mit N4, ohne diesen Owner-Scope als Gerätefreigabe umzudeuten. Das zusätzliche PreviousUpdateID schützt vor Target-ABA; DOP Ref.Previous bindet nur den vorherigen Zielcommit und genügt alleine nicht. Generation startet bei 1 und steigt genau um 1; Überlauf ist Fehler. ```go type ExpectedRef struct { Name, Target, UpdateID string; Generation uint64 } func Create(root string, trustedGenesis SignedGenesis) (*Store, error) func Open(root, expectedRepo string, owner ed25519.PublicKey) (*Store, error) func (*Store) PutObject(objects.Object) (string, error) func (*Store) ReadObject(id string) (objects.Object, error) func (*Store) Ref(name string) (RefRecord, error) func (*Store) CreateBranch(name, target string, signedUpdate SignedRefUpdate) (RefResult, error) func (*Store) ApplyRef(expected ExpectedRef, candidate SignedRefUpdate) (RefResult, error) func (*Store) ImportBranch(expected ExpectedRef, candidate SignedRefUpdate, incoming *SignedRefUpdate) (RefResult, error) func (*Store) ValidateCommitGraph(id string) (GraphSummary, error) func (*Store) RecoverReservations() error ``` Die Bibliothek speichert keinen privaten Schlüssel. CLI-Signieren verlangt den expliziten bestehenden Ownerkey; Lesen/Put alleine autorisiert kein Refupdate. Import benötigt für `incoming-` einen zweiten explizit owner-signierten Ref. Ohne ihn liefert es nur eine divergente Vorschau. Feste Lockordnung: Objektquota-State vor Refstate, niemals rückwärts. Atteste werden unter Quotalock vorab immutable installiert; anschließend werden ExpectedRef und gegebenenfalls ExpectedMainRef der Importvorschau sowie die vollständige signierte Refhistorie innerhalb einer Reftransaktion geprüft. Beide Ref-CAS-Werte werden dort gemeinsam verglichen. Graphreads sind durch immutable Objekte ohne GC vom separaten Quotalock entkoppelt. Das ist keine atomare Zwei-Dateien-Transaktion, sondern sichere Veröffentlichung bereits dauerhafter Objekte; verwaiste Objekte/Atteste bleiben quotawirksam. Bei Commitfehler/ErrUncertain wird keine erfolgreiche Resultstruct zurückgegeben. Ein gelöschtes/corruptes Statefile wird nicht aus Objekten neu initialisiert. Branchlöschung/Forcepush gehören nicht in N1; fast-forward oder expliziter Mergecommit sind die einzigen vorhandene Branchspitzen bewegenden Vorgänge. Objekte und Atteste vor Refcommit vollständig schreiben, Hash/Typ prüfen, fsyncen und immutable/no-replace installieren. Das darf unreferenzierte Objekte hinterlassen, aber nie eine gültige Ref auf fehlende Bytes. Dateien während der Graphprüfung über gepinnte Root-Handles lesen, keine Prüfung eines Pfads mit anschließendem ungeschütztem Neuöffnen. Ganze Refgraphen müssen vor Veröffentlichung lokal vorhanden sein. ErrUncertain erzwingt Reopen/Refprüfung, keinen blinden Retry. Erster Graph-/Diskrahmen: max 100000 Objekte, 16384 Commits, Tree-Tiefe 128, Pfadlänge 4096 Bytes, max 1 GiB vollständiger Store inklusive Staging/Orphans; Blob32 MiB/Metadaten4 MiB und Tree10000-Einträge wie DOP. Grenzen vor Allokation, Rekursion und Schreibbeginn; DFS mit Farbzustand und Visitbudget, keine unbegrenzte rekursive Dateistruktur. Put reserviert Diskbudget **vor** Dateianlage unter State-Lock und verifiziert bei Finish; Crashreservierungen zählen weiter, bis explizites lokales Recovery sie überprüft. N1 hat keine automatische GC. Nicht einfach nur die Größe erreichbarer Objekte als Diskquota zählen. Aktuelle Umsetzung zählt Objects/Staging/Atteste und offene Reservierungen bei Byte- und Fileslotlimits; zusätzlich bleiben 4×16 MiB für atomare Statekopien reserviert. Rename-no-replace und gepinnte os.Root-Handles ersetzen keine Abnahme anderer Kernel/Dateisysteme. Linux amd64/arm64 ist der unterstützte atomare Pfad; andere Plattformen fail closed. ## N2: zwei Offlinezweige und echte Divergenz Branches sind unabhängige Refs auf denselben immutable DAG. Nach gemeinsamem Commit A erzeugt Gerät 1 Commit B(parent A), Gerät 2 Commit C(parent A). Import von C darf B nicht ersetzen. Ist die erwartete lokale Spitze kein Vorfahr von C, oder änderte sie sich seit der Vorschau, wird C nach Graph-/Signaturprüfung unter einem neuen `incoming-`-Ref gehalten; B bleibt aktiv. Vorhandener identischer incoming-Ref ist idempotent; Namenskonflikt mit anderem Ziel ist ein harter Fehler. Importierte Inhalte überschreiben keinen Worktree. Ergebnis ist strukturiert `Applied | AlreadyPresent | Diverged | StalePreview` mit beiden Commit-IDs und erhaltenem Incoming-Ref. Wenn die Konfliktref absichtlich persistiert wurde, liefert der State.Update-Callback erfolgreich neue Bytes; der äußere Rückgabestatus meldet Divergenz. Ein Callbackfehler würde sonst genau die gewünschte Sicherung wieder verwerfen. CLI zeigt beide Spitzen und den weiteren Review/Merge-Schritt. Kein Zeitstempel, Peermehrheit oder letzter HTTP- Request entscheidet über die gewinnende Historie. ## N3: begrenztes echtes Three-Way-Merge Implementierte und unabhängig lokal geprüfte pure Bibliotheks-API: `Plan(ObjectReader, ours, theirs) (MergePlan,error)` und `Verify(MergePlan)`. Sie überprüft Objektbytes/IDs, den vollständigen DAG, eindeutige beste Bases, Text-/Binär-/Pfadkonflikte und generierte Objekte ohne Speicher-/Refmutation. Status: AlreadyContained, FastForward aus Sicht ours, Merge, Unrelated oder AmbiguousBase. Konflikte liefern keinen fertigen Resulttree. Verify prüft nur Inhaltsbindung, keine Autorisierung und keinen beweisenden Replay der Merge- Semantik gegen einen externen DAG. Planbody bindet Algorithmus/Limitsversion, geordnete Heads, Bases, Resulttree-ID, generierte Objekt-IDs und Konflikte. Repo/ACL/ExpectedRef sind noch nicht Teil dieses reinen Algorithmus. Die folgenden Store-/Review-/Apply-APIs sind weiterhin **Entwurf für N3b/N4**, nicht implementierte Berechtigungen: ```go func (*Store) PlanMerge(ours ExpectedRef, theirsCommit string) (MergePlan, error) func (*Store) Resolve(planID string, resolutions []Resolution) (ResolvedPlan, error) func (*Store) ApplyMerge(planID string, expected ExpectedRef, decision SignedDecision) (CommitResult, error) ``` Der künftige autorisierte Apply-Plan bindet zusätzlich Repo, ACL-ID, beide vollständigen Commit-IDs, ausgewählten Mergebase, ExpectedRef, Ergebnisbaum oder explizite Konflikte und Algorithmusversion. Plan-ID hasht kanonische Bytes mit eigenem Kontext; Resolve erzeugt eine neue Plan-ID, die die vorige und alle Entscheidungen bindet. Reviews über einen alten Plan werden dadurch nicht auf neue Bytes übertragen. Apply prüft den aktuellen Ref/ ACLzustand und Reviewbindung erneut. Kein Hostcommand, Formatter oder Mergetool wird aus dem Repository oder im Nodeprozess ausgeführt. Mergebase ist der eindeutige **beste gemeinsame Vorfahr** im verifizierten DAG, nicht der neueste Zeitstempel oder nur First-Parent-Historie. Ancestors beider Spitzen unter Visitbudget bestimmen, Schnitt bilden, gemeinsame Vorfahren entfernen, die selbst Vorfahren eines anderen gemeinsamen Vorfahren sind. Genau ein Ergebnis erlaubt automatisches Three-Way; mehrere beste Bases (criss-cross) geben `AmbiguousBase`, kein stilles Wählen. Ohne gemeinsamen Vorfahren `UnrelatedHistory`; keine automatische Zusammenführung unabhängiger Repos. Vorfahrfälle werden als Fast-forward oder AlreadyContained gesondert angezeigt. Vergleich pro Pfad über Base/Ours/Theirs unter vollständiger Pfad-/Typprüfung: | Situation | Ergebnis | |---|---| | Ours == Theirs, inklusive fehlend | genau diesen Wert einmal übernehmen | | Ours == Base | Theirs übernehmen | | Theirs == Base | Ours übernehmen | | beide geändert, reguläre kleine Textdatei | unten spezifizierte Three-Way-Hunks | | binary/add-add unterschiedlich/modify-delete/Datei-Directory/Modekonflikt | expliziter Konflikt mit allen drei Versionen | Bytegleichheit umfasst Blob-ID, Existenz, Typ und Mode. Keine Dateiendung als Beweis für Text. Textauto-Merge nur gültiges UTF-8 ohne NUL, höchstens 1 MiB, 2000 Zeilen und 64 KiB je Zeile. Zeilentoken behalten LF/CRLF und fehlenden letzten Newline bytegenau; keine Unicode-/Whitespace-/Newline-Normalisierung. Größere Texte werden als manuell aufzulösende Inhalte behandelt, nicht abgeschnitten. Konkreter erster Algorithmus: deterministischer LCS-Diff Base→Ours und Base→Theirs, höchstens 4 Millionen Vergleichszellen je Paar; bei Gleichstand Löschung vor Einfügung. Hunk = Baseline-Halboffenintervall [start,end) und Ersatzbytes, nebeneinanderliegende Änderungen derselben Seite coalescen. Unterschiedliche nichtüberlappende Intervalle beider Seiten können gemeinsam angewandt werden. Identische Intervalle mit identischen Ersatzbytes einmal. Zwei Einfügungen am selben Basispunkt nur bei bytegleichem Inhalt automatisch. Einfügung am Anfang/Ende oder innerhalb eines fremden Ersetzungsintervalls gilt konservativ als Konflikt. Überlappende unterschiedliche Ersetzungen sind Konflikte. Kein einzelner sichtbarer Hunk darf still eine Änderung der anderen Seite verlieren. Die Bibliothek begrenzt zudem globale Diffarbeit auf16 Millionen Zellen, DAGarbeit auf1 Million Visits, Pfadexpansion auf64MiB und Planbody auf16MiB. Inputgraph und generierte Objekte haben jeweils1GiB-Bytesbudget. CLI-Export der vollständigen Planstruktur ist zusätzlich vor JSON-Marshal auf32MiB begrenzt; das ist kein32MiB-Arbeitsspeicherlimit des Mergealgorithmus. Mergeplan enthält Konfliktart, Pfad, Base-/Ours-/Theirs-Blob-ID oder fehlend, Modes und bei Text genaue Hunks. Konfliktmarker sind nur optionales Preview, niemals automatisch akzeptierte Dateiinhalte. Nutzerentscheidung `ours`, `theirs`, `delete` oder neu bereitgestellter Blob bindet exakt diesen Konflikt. Binary- Konflikte brauchen dieselbe explizite Entscheidung. Renames werden in N3 zunächst als Delete+Add angezeigt, keine heuristische automatische Umbenennung; daraus entstehende Modify/Delete- und Prefixkollisionen bleiben Konflikte. Nach Auflösung aller Konflikte neuen Tree vollständig prüfen. Mergecommit hat exakt geordnete Eltern `[ours,theirs]`, behält beide DAGzweige, und erhält eigenen Commit-/Refattest samt Reviewbindung. Kein konfliktbehafteter Plan darf einen Ref bewegen. Preview→Apply benötigt CAS über originalen ExpectedRef und Plan-ID; neue lokale Arbeit macht den Plan stale, auch wenn Dateiinhalte zufällig gleich sind. ## N4: Signaturen, Attribution, Proposals und Reviews Keine neuen DOP/1-Typbytes in diesem Paket. Kanonische Sidecar-JSON mit festen Structs, Schemafeld, Größenlimit128 KiB, höchstens64 Signaturen/Statements je Kandidat, unknown/duplicate/trailing Bytes ablehnen. ID = SHA-256 von genanntem Kontext + NUL + kanonischem Body; Ed25519 signiert denselben Kontext/Body mit separatem `.../signature/v1`-Kontext. Genaue unabhängige Wire-/ID-Vektoren vor Runtimeverdrahtung festhalten. | Statement | Bodybindung (zusätzlich Schema/Repo/Zeiten/Signer) | ID-Kontext | |---|---|---| | Genesis | Repo, Owner, zufällige Repo-ID | `meshforge/native/genesis-id/v1` | | CommitAttestation | Commit-ID, Rolle `author` oder `importer`, Delegation-ID | `meshforge/native/commit-attestation-id/v1` | | RefUpdate | DOP-Ref-ID, PreviousUpdateID, ACL-ID, Delegation-ID, Handlung | `meshforge/native/ref-update-id/v1` | | Proposal | Sourcecommit, Zielref+Generation+Update-ID, Base, Mergeplan-ID, Ergebnistree | `meshforge/native/proposal-id/v1` | | Review | exakte Proposal-ID, Entscheidung approve/reject, Reviewer-Delegation | `meshforge/native/review-id/v1` | | Attribution | exakter Commit/Tree/Blob, asserted contributor/license/source, authority kind | `meshforge/native/attribution-id/v1` | Authorclaim aus importiertem Legacycommit bleibt Claim. Importer darf nur belegen, wer welche Legacybytes importierte, nicht rückwirkend Autorenschaft signieren. Attribution ist ein belegbarer Claim, keine automatisch geprüfte Lizenz oder rechtliche Identität. Reviewed proposal bindet exakten Baum und beide Parents; ein danach geänderter Patch braucht neue Proposal-ID und neue Reviews. Für branchgeschützte Refs lokale Ownerpolicy mit unabhängigen Reviewerkeys, Permission review, Mindestquorum und Entscheidung gegen exakt gebundene Proposal. Aktuelle ACL/Expiry/Revocations bei Apply prüfen; Self-review zählt nicht zum geforderten unabhängigen Quorum. Gültige Ablehnung wird gespeichert; neue positive Nachricht löscht sie nicht. Änderungen an derselben Kandidaten-ID sind unmöglich; behobene Änderungen benötigen neuen Kandidaten. Unabhängige Organisationen lassen sich nicht aus Schlüsseln beweisen. Agenten können zunächst nur Proposalobjekte erzeugen, nie Ref/Worktree ändern. Capability bindet Repo, Zielref, Operation propose, Quota, Ablauf und Devicekey. Server führt weder Builds/Tests noch Shell aus. Signierte Testbelege sind Aussagen mit Reportdigest, keine Behauptung tatsächlich ausgeführter Tests. Hostausführung wäre später ein getrenntes Sandbox-/Reviewpaket. ## N5: explizite Legacy→DOP-Migration Migrate benötigt verifizierten v1-Backupstand, neuen DOPzielpfad, gepinnten Source- HEAD **und** Backupmanifestdigest (HEAD allein bindet detached/unreachable Objekte nicht). Source unter bestehendem Lock erfassen, vollständige native Historie und alle Snapshotindexes prüfen, dann lockunabhängig aus dem immutable Backup lesen. Keine vorhandene v1-Datei oder frühere PUBLIC-Bridge-Mappingdatei ändern. Map enthält Legacyobject-/Snapshot-ID→DOPblob/Tree/Commit-ID, Sourcebackupdigest, Source-HEAD, Zielgenesis-ID und Importerattest. Objektbytes werden nicht als schon existierende DOPbytes umbenannt: DOPenvelope ändert absichtlich deren ID. Legacy- Commitzeiten mit Nanosekunden bleiben im Importmapping erhalten; DOP-UnixTime hat Sekundenauflösung. Legacyfilemodes sind nicht gespeichert, deshalb explizit 0644 importieren, nicht Executable-Rechte erfinden. Historischer Author ist `importer:` plus separate Importerattest, kein gefälschter damaliger Autor. Alle vorhandenen Elternbeziehungen erhalten, detached Snapshotspitzen als separate `imported-`-Refs sichern. Kein alleiniges Migrieren der aktuellen HEAD mit Weglassen anderer gespeicherter History. Neue Refzustände werden gemeinsam atomar nach vollständiger Prüfung publiziert. Migration darf keinen Publicpush auslösen. Rollback heißt altes unverändertes v1 weiterverwenden; neue DOP-Arbeit wird dadurch nicht zurückkonvertiert oder gelöscht. ## Disjunkte Folgepakete und Abnahme 1. **N1a Objektstore/Graph – implementiert:** Worker `internal/nativerepo/{types,codec,store,graph}*`; DOPcodec unverändert. Typ-/Hash-/DAG-/Pfad-/Quotafehler und Crashreservierungen. 2. **N4a Atteste/Policy:** separater Worker später `internal/nativepolicy/{types,codec,verify}*`; feste unabhängige Vektoren, negative Scope-/Permission-/Expiry-/Signaturetests. Keine Registry. 3. **N1b/N2 Refs/Import – owner-only implementiert:** `internal/nativerepo/refs*`; N4-Delegation bleibt separat. Zwei Offlineclients, beide Zweige erhalten, ABA/Generation/CAS, stale Vorschau, revoked concurrent write, no orphaned accepted refs, ErrUncertain-Reopen. 4. **N3a Pure Merge – implementiert:** `internal/nativemerge/*`; read-only bounded objectreader, kein FS/Netz/Keys. Text/binary, Delete/Modify, UTF8/CRLF/no-final-newline, identische Änderungen, disjoint/overlap, criss-cross, unrelated DAGs, adversariale Dateigrößen und Laufzeitlimits. Golden fixtures unabhängig prüfen. 5. **N3b Review/Apply:** nativerepo mergeadapter nach N3a; Elternordnung, Kandidatenbindung, dauerhafte Rejects, keine Self-review-Abkürzung. 6. **N5 Migration/Backup – experimentell implementiert und lokal geprüft:** `internal/nativerepo/migrate*` plus CLI; v1-Quellhashes vorher/nachher gleich, complete/detached Roundtripmapping, Unterbrechung/no-replace, Quota, unabhängige Importattest. 7. **UI/Transportadapter:** Root integriert nach Bibliotheksabnahme; gemeinsame Vollsuite/Race/Vet/Crossbuilds und reale Prozess-E2E. Kein Test ersetzt Audit. Browserbackend benötigt explizite neue local-write-Routen für Preview, Proposal, Review und Apply; vorhandene Loopback/Host/Origin/CSRF/Reviewdigest-Grenzen erhalten. Preview zeigt Source/Base/Target/Plan-ID und jeden Konflikt; Apply benutzt dieselbe Kandidaten-ID plus CAS. Private Reponamen/Pfade erscheinen nur in lokaler berechtigter Ansicht, nie im Public-MCP/Feed. Anfangs CLI-only ist zulässig; Browserseiten ohne echte Backendmutation gelten nicht als implementiertes Merge. Export/Checkout zunächst nur in neues Verzeichnis mit den vorhandenen atomaren no-replace-Primitiven. Kein automatisches Überschreiben schmutziger Worktrees. Windows darf nicht durch Crossbuild als sicher ausgeführte Checkout-/Lock-/ACL- Plattform ausgewiesen werden. Unsupported atomare Publikation bleibt fail closed. Private Remoteadapter muss das neue DOP-Backupformat ausdrücklich unterstützen; der derzeitige native-v1-Backuptransport darf `.dh`-fremde Dateien nicht plötzlich mitsenden. PUBLIC bleibt snapshot-only mit bestehender expliziter Freigabe. ## Paketprüfung und Freeze N1a/N1b und N3a sind als begrenzte Bibliotheken/CLI-Primitiven vorhanden. N3 Review umfasst vollständigen DAG/beste Bases, echte Textkonflikte, CRLF/fehlenden Newline, Shared-Tree-Expansionsgrenzen, unveränderte bzw. identische Typwechsel, malformed Plan-IDs und generierte Objektbindung. Ein zusätzlicher Reviewerfall fand directory-delete gegen child-add ohne Konflikt: gemischte Nodetypen vergleichen jetzt den exakten Subtree-ID, während übereinstimmende Verzeichnisse rekursiv gemergt werden. Die Regression verlangt expliziten Konflikt und keinen Resulttree. Normale Tests (0.340s), Race (5.779s) und Vet sind unabhängig erneut bestanden. Plan-ID und Owner-Refsignatur ersetzen keine N4-Reviewfreigabe. `native merge-plan` schreibt lediglich eine neue lokale Plandatei; weder Objects noch Refs werden angewandt. Keine Resolve-/Apply-/Browserbranch-Funktion ist daraus abzuleiten. Gemeinsame aktuelle Vollsuite, Sourcehash-Guard und Sourcecheckpoint folgen nach diesem Paketfreeze; diese Dokumentation behauptet sie nicht vorab. ## N5: experimenteller geprüfter Stand `internal/nativeimport` prüft owner-signierte Importnachweise gegen neue Repo-/Genesis-/Ownerpins und beide unabhängigen Quellpins (HEAD und exakte Backupmanifest-SHA256). `internal/nativerepo` installiert den typisierten Nachweis unter der gemeinsamen Quotenprüfung und migriert ausschließlich in ein neues Ziel. Alle ursprünglichen Objekt-/Snapshotbytes, verwaiste Objekte, abgetrennte Historien, HEAD und optionale `.dh/ignore` bleiben nachprüfbar erhalten; Zeitstempel einschließlich Nanosekunden bleiben im Rohbeleg. Importerattribution ist kein Beweis historischer Autorenschaft. [Native-Migrations-CLI](NATIVE_MIGRATION_CLI.md) und [BackupReader](BACKUP_READER.md) beschreiben die expliziten Pins und Aufrufe. Die Migration nutzt Linux-No-replace-Publikation, prüft physische Quellaliase über gepinnte Verzeichnisidentitäten und lässt bestehende `.dh`-Stores unverändert. Fehlende Plattformgarantien führen zur Ablehnung. Keine neue Windows-Backend-, DOP-Remote-, Browserbranch- oder geschützte Merge-Apply-Funktion. Unabhängige lokale Normal-/Race-/Vet-Prüfungen bestanden, einschließlich Quellmanifeständerung, ausgetauschtem Zielparent, Sourcealias und konkurrierender Importinstallation. Der echte Prozesschecker bestand fünf Gruppen mit unabhängiger Python-Rekonstruktion aller Originalbytes, DOP-Trees/-Commits, Mapping-/Attest-IDs und Ed25519-Signatur. Sein Binary lag vor der abschließenden linearen Topologieoptimierung; die jüngste Bibliotheksfassung bestand danach erneut Normal-/Race-/Vet-Prüfungen. Gemeinsamer Freeze/Checkpoint14 und erneuter Prozesslauf auf dessen Binary sind noch nicht als abgeschlossen dokumentiert.