# Masterplan-Integration: überprüfbarer Umsetzungsstand Nachtrag native Speicherung: [I/O-Fehlergrenzen und Recovery](NATIVE_STORAGE_FAILURES.md) ergänzen deterministische Teilwrite-/Syncfehler und einen separaten begrenzten Kernel-ENOSPC-Test. Recovery synchronisiert installierte Objektverzeichnisse vor Entfernen ihrer Reservierungen. Der vorherige dev9-Freeze `e0281fd5e0fd` bestand alle 38 externen Prüfungen; spätere Änderungen sind davon getrennt. Nachtrag Namenskonflikte: [Zusammengesetzte Case-Fold-Kollisionen](NATIVE_NAMESPACE_CLI.md) lassen sich jetzt nach den ursprünglichen Entscheidungen in einer separat versionierten Phase schrittweise vorschauen und auflösen. Alte Plan-/Resolution- IDs bleiben gleich; geschützter Apply rechnet die gesamte neue Schrittfolge nach. Der vorherige dev8-Freeze `4cf433c852a9` bestand alle37 vollständigen externen Prüfungen. Die neuen Quellen sind von diesem Nachweis nicht umfasst. Nachtrag Peer-Konfiguration: [Explizite Peer-Übernahme](PEER_ACTIVATION_CLI.md) ersetzt nach eigener Vorschau/Bestätigung die Discovery-URL-Liste einer Node. Aktuelle Quellenlage und unveränderte Konfigurationsbytes werden im gemeinsamen Lock-Zeitfenster erneut geprüft. Kein Auto-Start, keine automatischen Kontakte, keine dauerhaften Peer-ID-Pins und kein LAN-Modus. Der vorherige dev7-Freeze `4c0982b15b2c` bestand alle 36 vollständigen externen Prüfungen; spätere Peer-Änderungen sind davon nicht umfasst. Nachtrag 26.10., Runde 4: Der dev4-Quellpin wurde unverändert bestätigt; sein HTTP-Abschlussbericht fehlt. Native Konfliktentscheidungen sind jetzt als [getrenntes lokales Artefakt](NATIVE_RESOLUTION_CLI.md) implementiert, einschließlich DAG-Replay und neuer Entscheidungs-ID. Der nachfolgende [geschützte Review-/Apply-Pfad](RESOLVED_REVIEW_CLI.md) nutzt jetzt neue Candidate-/Proposal-/2-Verträge mit unveränderten `/1`-Signaturen und Ablehnungsidentitäten. Zusammengesetzte Namenskonflikte, native Transporte und die vollständige Browserintegration bleiben offen. Caddy-/systemd-user-Vorlagen ergänzen das VPS-Paket; `/health` liefert ausschließlich Prozess-Liveness. Ein neuer Hosted-Prozesscheck ist im HTTP-Testpaket registriert. Der eingefrorene dev6-Stand bestand alle 35 externen HTTP-/Prozessprüfungen; das ist keine Abnahme des danach erweiterten Reviewcodes. Keine Produktionsfreigabe oder v1.0.0-Abnahme. Nachtrag 26.10., Runde 3: expliziter Private Store v2, paged Transfer v2 bis 64 MiB und ein begrenzter Nur-Lese-Domainmodus sind lokal implementiert. Gezielte Store-/Codec-/Transport-/Präsentationsprüfungen liefern separate Nachweise; wegen gesperrter Loopback-Sockets ist die vollständige aktuelle Prozessabnahme offen. Letzter akzeptierter Checkpoint: 18. Keine vollständige Masterplanumsetzung oder produktionsreife v1.0.0. Aktuelle Details und Restarbeit: [Ausführungsinventar, Runde 3](MASTERPLAN_EXECUTION.md#round-3-private-scaling-and-domain-presentation), [Domainmodus](DOMAIN_PRESENTATION.md), [Validierung](VALIDATION.md). Die Anmeldung mit einem Geräteschlüssel auf der eigenen HTTPS-Domain ist lokal implementiert: aktueller Grant-/Widerrufscheck, browsergebundene Challenge, kurze Sitzung und isolierte HTTP-Loginhandler. Das opt-in-Profil `serve --presentation-origin --hosted-auth-catalog --hosted-browser-assets` bindet öffentliche Seiten, Browseroberfläche, Authentifizierung und den gepinnten Ciphertext-Lesetransport ein. `hosted-auth-init` und `hosted-auth-catalog-check` provisionieren und prüfen die Betreiberkonfiguration offline; `hosted-auth-revoke-apply` übernimmt signierte Eigentümerwiderrufe. Die echte Browser-/TLS-/VPS-Abnahme steht aus. Eine Sitzung wird beim Wechsel des ausgewählten Repos ersetzt; eine universelle Mehr-Repo-Sitzung ist nicht Teil dieses Ablaufs. Wenn jede Betreiberzeile ein gepinntes privates v2-Ciphertextverzeichnis hat, schaltet derselbe Domainmodus ausschließlich Challenge/Head-/Objektlesen frei. Cookie, Gerätesignatur und aktuelle Repo-Mitgliedschaft bleiben getrennte Pflichtprüfungen; ein In-Memory-Integrationstest bestätigt den Widerrufspfad. Die öffentliche VPS-TAR ist kein fertiges v1.0.0-Deployment. Ein getrenntes Hosted-TAR mit Browser-Assets und systemd-/nginx-Vorlagen liegt als Entwicklungskandidat vor; es trägt ausdrücklich keine Produktionsfreigabe. Die spätere Node-übergreifende `Name#ID`-Weiterleitung ist für nach v1.0.0 vorgemerkt. [Hosted-Browser-Entwurf](HOSTED_BROWSER_V1_DESIGN.md). Für private Browserinhalte ist E2EE festgelegt: der VPS speichert Ciphertext, der Client entschlüsselt nach Anmeldung lokal. Eine lokale CLI baut die Schlüsseldatei mit unabhängig gepinnten Eigentümern; der Browser liest sie vom Gerät ein. Ein kompromittierter VPS kann jedoch ausgelieferten JS/WASM-Code ersetzen; unabhängige Clientintegrität ist damit noch nicht erreicht. Für 100+ Repos existieren ein verschlüsselter Namensindex für bis zu 256 Einträge, die Auswahloberfläche und ein nativer-v2-Teilabruf. Erst der Index wird geladen und lokal entschlüsselt; die Dateiliste des ausgewählten Repos folgt auf Auswahl, eine Quelldatei erst beim Öffnen. Der Teilabruf prüft Chunk-Ciphertexte, den vollständigen Dateihash und einen erneuten signierten Head-/Mitgliedschaftsstand vor der Ausgabe. Lokal bleibt pro geöffnetem Repo ein kompakter Rollback-Checkpoint. Ein kompletter Browser-/TLS-Roundtrip und Last-/Speicherabnahme mit 100+ Repos fehlen noch. Der lokale Go-Leseclient kann aus dem Teilabruf zusätzlich die aktuelle native Snapshot-Dateiliste und eine einzelne Quelldatei mit HEAD-/Snapshot-/Blob-Pins lesen; er lädt kein vollständiges Repository. Fortsetzung: Ein begrenztes [Envelope-Syntaxmemo](PRIVATE_STORE_V2_HASH_MEMO_DESIGN.md) spart wiederholtes JSON-/Base64-Prüfen, bindet aber jede Nutzung erneut an den vollständigen Ciphertexthash. Ein [frühes Ablehnungsgate](PRIVATE_STORE_V2_EARLY_DENY.md) verwirft widerrufene/veraltete Zertifikate vor dem Inventarscan. Dies sind zusätzliche lokale Änderungen nach dem eingefrorenen HTTP-Testpaket; dessen Ergebnisse dürfen nicht als Abnahme dieses späteren Quellstands gelten. Zusätzliche unabhängige Arbeit während des HTTP-Laufs: [Offline-Epochen-Evidence](NATIVE_POLICY_EPOCH_EVIDENCE.md) implementiert zertifikatzeitunabhängige Policy-/Ablehnungsidentitäten, OwnerEpochAck mit ProposalID und ausschließlich negative EpochRejection-Dokumente samt CLI. Das war der Schema-/Identitätsteil der Rotationsvorbereitung. Der spätere Healthy-Verifier, dauerhafte Negatives, Epochaktivierung und die begrenzte terminale Recovery mit unverändertem Owner sind inzwischen separat implementiert; ihre eigenen Tests und offenen Freigabegates stehen unten. 25. Oktober 2026 · Entwicklungsvorschau · **keine Produktionsfreigabe**. Der Masterplan wurde vollständig und unverändert eingebettet; dies bedeutet nicht, dass alle Produktfunktionen fertig sind. Seine verbindliche Reihenfolge (§0, §12, konkret §16) stellt Integrität vor Remote-/Wallet-/Zahlungsfunktionen. Kanonischer Codec, lokaler Speicher und Identity-Grundmodul sind echter Code mit Tests. Persistente Autorisierung und ausdrücklich aktivierter öffentlicher Snapshot-Transport und separater privater E2EE-Historytransport sind experimentell implementiert; optionale Zahlungs-/Wallet-Schnittstellen bleiben gesperrt. Begriffe: **implementiert** = benannter Teil funktioniert mit angegebenen Tests; **experimentell** = Code vorhanden, Integrations-/Plattform-/Security-Gates offen; **geplant** = Spezifikation/Backlog, kein Runtime-Feature; **blockiert** = konkrete Voraussetzung für Freigabe fehlt. Ein Teilstatus erfüllt nicht automatisch die vollständige Definition of Done des Tickets. Die additive [MeshForge-Governance](MESHFORGE_CODEX_GOVERNANCE.md) priorisiert jetzt P0-Härtung und P1-Bootstrap/Releases/Governance vor optionalen P2-Modulen. [Gap-Inventar](GOVERNANCE_GAP.md) ordnet alle 13 neuen Tickets zu; [Namensmigration](NAME_MIGRATION.md) erhält vorhandene Daten und IDs. ## Neue Paketstände mit begrenzter Abnahme - [Private Sync](PRIVATE_SYNC_CLI.md): separate Ciphertext-ACLs/Owner-Cutover, durable Pins, verschlüsselte volle native History, expliziter Push/Clone und geschützte Readkeyweitergabe. Zwei-Geräte-Prozessfixtures und Raceprüfungen bestanden; keine OS-Keychain oder vollständige Gruppen-/Enrollment-UI. - [Private Pakete](PRIVATE_PACKAGES.md): lokale AES-GCM-Dateipakete; Writerbudget getrennt dauerhaft gebunden. Recoverykey/Readkey setzt keinen Writer zurück. - Backup-/Restore-CLI und owner-only native DOP-Store/CLI-Primitiven vorhanden. Signierte Ref-CAS und incoming Zweige erhalten Divergenz. Keine stille Migration; N3 pure Mergeplanung und explizite N5-Neuzielmigration lokal geprüft; autorisiertes Apply sowie N4 Reviews/Delegation bleiben offen. - [V2 Recovery-CLI](RECOVERY_CLI.md): getrennt provisionierte Rotation und terminale Recovery mit fortbestehenden offenen Ursachen. V1 bleibt unverändert; Migration mit aktiviertem LastTransition wird auch nonterminal verweigert. - [Build-/SBOM-/Provenienztools](REPRODUCIBLE_BUILDS.md): Zwei-Pfad-/Drei-Target- Prüfung bestand für nativen Source-Snapshot 11. Kein finaler Vollsuite-/Build- Nachweis für den aktuell veränderten Baum und keine Produktionsfreigabe. Die [Ausführungsmatrix](MASTERPLAN_EXECUTION.md) benennt die jeweiligen lokalen Prüfungen und verbleibenden externen Gates; Teilpakete schließen kein Gesamtticket. ## Alle Tickets | ID | Status / echter Lieferumfang | Offener Abnahme-Gate | |---|---|---| | DH-001 | **Implementiert:** Inventar, reproduzierte Findings, vier unabhängige Regressionen, Migrationseinstufung | fortlaufende Reviews; keine externe Auditbehauptung | | DH-002 | **Experimentell implementiert:** DOP/1 Blob/Tree/Commit-/Ref-Inhalte, kanonischer Codec, Domain Separation, fünf fixe unabhängige Vektoren, Negativ-/Fuzz-Tests; `object-check` | übrige Objekttypen, unabhängige Interop-Implementierung; Graph-/Import-Signaturintegration im Public-Transport vorhanden | | DH-003 | **Experimentell implementiert:** v1-kompatible Durable-Writes, Linux/Windows-Prozesslock, CAS, Recovery, neun Commit-Crash-Punkte, zwölf injizierte Write-/Syncfehler, fünf Linux-Export-Crash-Punkte und atomare NoReplace-Veröffentlichung; Korruptions-/Alt-Daten-Tests | echte Powerloss-/Disk-full-/Windows-/Netzdateisystem-Prüfung; Windows Directory-Durability nicht zugesichert | | DH-004 | **Experimentell implementiert:** Root-ID, signierte begrenzte Gerätedelegation, persistenter Widerruf mit Lock/Reload pro Autorisierung, HTTP-Request-Bindung, Replay-/Restart-/Mehrinstanztests; CLI Delegate/Revoke, gehärtete begrenzte lokale Key-Datei mit Linux-Owner/Mode-Checks und exklusiver Initialisierung | OS-Keystore, Recovery, Gruppenrollen/Geräte-UI; lokale Schlüsseldateien und vertrauenswürdiges Filesystem erforderlich | | DH-005 | **Experimentell implementiert für PUBLIC:** expliziter separater Store/Owner-Pin, Chunk-/Speicher-/Rate-Limits, signierte Import-Provenienz, Graphprüfung/CAS, CLI clone/fetch/push/pull, v1-Mapping und Pending-Recovery; Zwei-Client-Fixtures | separater privater E2EE-Push/Clone jetzt lokal getestet; Merge/Apply, echte Windows/Linux-Hardware-E2E und unabhängiges Audit offen; Public-Pull bewegt nur Snapshot-HEAD | | DH-006 | **Teilweise implementiert:** private lokale Snapshots/Registry ohne öffentliche Leaks; private Browser-Projektanlage/Registrierung und geprüfte Snapshots mit CSRF/CAS; erste Public-Freigabe snapshot-only + allow-public, Graph-Preflight und CLI-Pfadvorschau | private Remote-Geräte-ACLs/CLI vorhanden; Intranet-/Unlisted-Produktpolicy und Browser-Publication-UI offen | | DH-007 | **Teilweise experimentell implementiert:** gemessene Peer-/Fehler-/LastSync-Zustände, privater Header/Statusseite, persistente öffentliche Event-Outbox und sichtbare vorhandene Snapshot-Retry-Intents | echte LAN-Policy, automatische credential-gestützte Snapshot-Queue fehlen; private Zwei-Geräte-CLI-Fixtures bestehen; keine pauschale Internetbehauptung | | DH-008 | **Teilweise experimentell implementiert:** prozesssicherer begrenzter Legacy-Cache, Batch-Accept, Gossip-Fanout/Leases/Backoff/Dedupe, getrennte/gruppierte Neu-/Release-/Kritisch-Feeds, private Merkliste, expliziter versionierter Sternentzug; 1000 HTML-Commits erzeugen null Events | öffentlich signierte Follows, Kategorie-Abonnements, zeitbezogenes Trending, TTL/GC-Retention und weitere Interop-/Lastabnahme fehlen | | DH-009 | **Spezifiziert/geplant:** signierte Entwickler-/Org-Envelope-Verträge | persistierte Subject-AuthZ, Codec/Vektoren und Profil-UI fehlen | | DH-010 | **Spezifiziert/geplant:** URL/Datei/Formular als drei Angabemethoden | kein Impressum-Editor/Import; keine Rechtsverifikation durch bloßen Link | | DH-011 | **Spezifiziert, Aktivierung blockiert:** optionale BTC/BCH/BSV/Bank/PayPal/Karten-/externe Provider-Verträge | Chain-/Adress-/URI-Testmatrizen, Subject-AuthZ, Provider-/Rechtsprüfung; keine Zahlungsdaten gespeichert | | DH-012 | **Spezifiziert/geplant:** Domain-/Register-/Prüferclaims mit Scope/Ablauf/Widerruf | Domain-Challenge, sichere externe Fetches, Trust-/Evidence-/Revocation-Integration fehlen | | DH-013 | **Spezifiziert, blockiert:** Wallet-Challenge/Adaptervertrag, null freigegebene Kombinationen | geprüfte BTC/BCH/BSV-Adapter, persistierter Replay-Schutz und externe Signaturprüfung fehlen | | DH-014 | **Teilweise experimentell:** eigener nativer public read-only MCP mit Origin/JSON-RPC-Prüfung, Versionsaushandlung, Paging, bounded Batches/Rate/Concurrency; Identity-Capability-Bausteine | MCP-Konformität/AuthZ, persistenter Audit, Workspaces, Proposal-/Review-Runtime, Sandbox fehlen | | DH-015 | **Geplant:** isolierter optionaler Buzz/Nostr-Vertrag | aktuelle Fremd-API/Lizenz prüfen, Tests und Adapter implementieren; Core bleibt unabhängig | | DH-016 | **Experimentell implementiert, Produktion blockiert:** Tests, Crossbuilds, Betriebs-/Recovery-/Migrationsdoku; Offline-Release-Verifier und CLI mit separat gepinnter Policy, Artefakthash, Checkpoint sowie opt-in Policy-Transition bei lokal provisionierten Regeln | echte Windows-Läufe, Last/SLOs, aktuelle Sourcefreeze-Reproduktion/Release-Signaturen, vollständige Upgrade-/Disaster-Recovery und unabhängiger Audit fehlen; SBOM/Provenienztools und v2 Recovery/Rotation lokal geprüft | ## Weitere Anforderungen des Masterplans — vollständig zugeordnet | Masterplan-Bereich | Vorhanden | Offen / genaue Einordnung | |---|---|---| | §0 Arbeitsweise, §1 Inventar | unveränderte Quelle, Ist-Audit, kleine Module, Standardbibliothek, Offline-/V1-Regression | externe Abnahme ist kein ersetzbarer Unit-Test | | §2 Betriebsmodi | lokal/offline, experimenteller manuell konfigurierter Public-Discovery-Peertransport | kein privater Intranet-Modus; Self-hosted nur kontrollierte Tests; öffentliche Föderation nicht gehärtet | | §2 Sichtbarkeit | private lokale Daten + explizite öffentliche Metadaten | vierstufige Policy/ACL, öffentliche Vorschau/Umkehrwarnung in UI fehlen | | §2 Domain/Identität | domainunabhängige bestehende Repo-ID, DOP-IDs, experimentelle Root-ID | kryptografische Bindung lokaler Repos, Locator-Multipeer-Registry/Own-domain-Pfade fehlen | | §3 Objektmodell | native Offline-v1-Snapshots, experimenteller DOP Tree/Commit-DAG-/Ref-Codec | explizite N5-Neuzielmigration mit Importerattest implementiert; Proposals, historische Autorenatteste und Repo-Reviews nur Entwurf; gesonderte Release-Reviews/Testbelege experimentell implementiert | | §3 Remote | Public-Upload/Fetch/Clone/Pull, Ref-CAS, Pending-Recovery und native/DOP-Zuordnung | private E2EE-Historybridge vorhanden; owner-only DOP-Conflict-Branches als separate Library/CLI, Merge/Apply und automatische Credential-Queue offen | | §4 Identität | bestehende Node-Key-Datei und separates geprüfteres DIP-Grundmodul | keine verschlüsselte OS-Ablage, Recovery-/Geräte-UI; Wallet ist kein Primärschlüssel | | §5 Spenden | Provider-/Datensparsamkeits-/Keine-Custody-Verträge | keine Zahlungs-/Spendenseiten, QR, Walletlinks, Status- oder Quittungsbehauptungen | | §6 Firma | alle drei Angabewege und vier Prüfstatus spezifiziert | keine registrierten Firmen, Domains oder rechtlichen Prüfer; lokale Trust-Policy offen | | §7 Discovery | signierte Public-Metadaten, Sternentzug, gruppierte Feeds, begrenzte Outbox/Leases/Jitter/Dedupe/Pagination | öffentliche Follows/Kategorie-Abos, Trending, TTL/Retention und robuste Sybil-Abwehr fehlen | | §8 KI | begrenzte native lesende Discovery-MCP-Tools mit strikter Eingabe/Origin/Quotas/Paging/Batches, kein Ausführen/Mergen | Capabilities/Audit im MCP nicht integriert, Gruppen/Tasks/Reviews/Buzz-Runtime fehlen; privates E2EE bleibt separater Transport ohne MCP-Writes | | §9 Navigation | Projekte/Discovery/private Snapshotseiten + Entwicklungsstand/Specs | Workspaces/Profil/Org/Einstellungen erst mit funktionierenden Backends; Aktivität vorhanden; keine Attrappen | | §9 Status | tatsächliche Peer-Proben, LastSync, laufender Abgleich, getrennte Fehlerzustände, dauerhafte öffentliche Outbox und Snapshot-Retry-Intents | kein allgemeiner Internetnachweis, keine echte LAN-Policy oder automatische private Upload-Queue | | §9 Einstieg | ohne Account lokal starten, Browser öffnen, Snapshot-Historie/Dateien lesen, CLI-Init/Commit | Web-Repo-Anlage/Registrierung/Änderungsvorschau/Commit implementiert mit --local-write; Web-Publish/Identitätsimport/Desktop-UI fehlen | | §9 A11y/i18n | deutsche UI, Fokus/Tastatur/Labels/mobile Layouts, UTC-Zeitangaben | vollständige Englischumschaltung, lokalisierte Zeiten, externes A11y-Review fehlen | | §10 HTTP/SSRF | Timeouts/Bodylimits, bounded private Reads, Origin/Host-Gates, kein Proxy-Bypass, persistierte Peer-URL-Prüfung | Public-Snapshot-Transport hat AuthZ/Quotas; Legacy-Ingestion hat Rate-/Body-/Concurrency-Limits, aber keine produktive Admission-/Sybil-Abnahme | | §10 Persistenz | lokales Repo-Lock/CAS/Recovery; begrenzter process-locked Node-Cache/Config/Outbox mit atomaren Updates und Mehrprozess-/Legacy-Tests | Windows-Powerloss, vollständige Diskquota-/Backupautomation und Cache-GC fehlen | | §10 Privacy | keine Telemetrie/zentralen Accounts, keine privaten API-/MCP-Metadaten | Remote-E2EE experimentell vorhanden; öffentliche Lösch-/Retention-Mechanismen offen | | §10 Recht | Gates für Zielmarkt/Payment/Impressum/Lizenzen benannt | kein Rechtsgutachten, keine universelle Compliance- oder Verifikationsaussage | | §11 P0–P7 | sichere Teile P0 umgesetzt; frühere Funktionen erhalten | keine Phase pauschal abgenommen; P1–P7 durch eigene Abnahmekriterien gesperrt | | §13 Protokolle | DOP/1 und DIP experimental detailliert, DDP Legacy dokumentiert | DAP/DVP/DPP/Workspace nur Entwürfe; Public-Remote experimentell implementiert; keine stabile öffentliche Standardbehauptung | | §14 Testfälle | Offline, Manipulation, Prozessabbruch, Privacy, Legacy, CAS, Pfade, Replay-Grundmodul getestet | Wallet/Payment/Firma/Privatremote/LAN-Modus nicht implementiert, daher keine bestandenen Integrationstests behauptet | | §15 Zusatznutzen | manuelles Verify/Export/Backup-Runbook | Geräte-Recovery-Dashboard, produktiver Release-Trust und extern reproduzierte Pipeline, Lizenzansicht, Bounties/Förderziele, Mirrorstatus, Org-Rollen-UI, Gitadapter, CI-Sandbox, Advisories und Sponsoringlinks geplant | | §17 Entscheidungen | offline/private/self-hosted/Git-/LLM-/Domain-unabhängig erhalten | OS-Key-Recovery, E2EE-Plattform-/Enrollment-Abnahme, NAT/automatische Quellendiversität/Replikation, PSP/Wallet-Matrix, Prüfertrust, Buzz und SLOs bleiben offen | ## Nächste technische Gates 1. Lokale Linux-Storage-Fault-Matrix um Disk-full/echte Dateisystem-Powerloss- Versuche erweitern; Windows-Hardware testen und Directory-Durability lösen. 2. Keystore-Entscheidung und Recovery-Prozess für persistente DIP-Autorisierung; Gruppenrollen und Geräte-UI ergänzen. 3. Experimentellen Public-Objekttransfer auf echter Windows-Hardware und mit größeren Last-/Fehlermatrizen prüfen. Private Remote-Inhalte bleiben zusätzlich hinter externer E2EE-/Schlüsselmanagement-Abnahme; lokale Implementierung ist vorhanden. 4. Profile/Organisationen/Spenden vor Wallet-Login umsetzen, aber erst nach autorisierten revisionssicheren Profilupdates. Keine schnellen unsicheren Wallet-Signer oder fingierte Zahlungs-/Firmenprüfung zum Füllen der Oberfläche. Alle verbleibenden Arbeiten sind sichtbar; „alles integriert“ heißt hier vollständiger Anforderungskatalog mit echten Fundament-Bausteinen und expliziten Gates, **nicht** eine fertige dezentrale Produktions-Forge. Weitere integrierte Architektur-Tickets: MF-ARCH-01 Dokumentationsabgleich und MF-ARCH-02 Hub-/Lock-/Ressourcenanalyse abgeschlossen. MF-ARCH-03 ist mit der gemeinsamen Public-Netzwerkpolicy und geprüfter Integration abgeschlossen; Vollsuite/Crossbuild-/E2E-Abnahme und offene Plattformgates siehe [Architekturreview](ARCHITECTURE_REVIEW.md). Keine Controller-/Handle-Registry oder vorgezogene Payment-/Wallet-Adapter. N5 ist experimentell implementiert: [explizite Neuzielmigration](NATIVE_MIGRATION_CLI.md) aus einem [vollständig gepinnten Backup](BACKUP_READER.md), mit erhaltenen Rohobjekten, abgetrennten Historien, `.dh/ignore` und unabhängig nachprüfbarem Owner-Importerattest. HEAD allein genügt nicht; die genaue Manifest-SHA256 ist Pflicht. Die Signatur ersetzt keine vollständige Konversionsprüfung und belegt keine historische Autorenschaft. Linux-No-replace-Publikation lässt das Quellrepository unverändert; Windows-Backend und DOP-Remote bleiben offen. Checkpoint14 wurde mit 19 gemeinsamen Prüfungen, tatsächlicher Quellmigration und zwei Reproduktionsläufen abgenommen. Der danach ergänzte N4-Stand benötigt seine eigene gemeinsame Abnahme. N4 ist als ausdrücklich aktivierter lokaler Reviewpfad experimentell implementiert: [geschützte native Branches](NATIVE_REVIEW.md), unveränderliche Policy, zertifizierte Autorenbelege, Proposal/Review-Journal mit ursprünglicher Empfangszeit, Schlüssel-/Gruppenquorum und Zeitfenster, dauerhaft gebundene Ablehnungen, Widerruf/Erneuerung derselben Zertifikatslinie und exaktes CAS-Apply. Direkte Owner-/Import-/AlreadyPresent-Schreibpfade umgehen geschützte Refs nicht. Späte Ablehnungen und nachträgliche Autorenbelege können angewandte Ergebnisse terminal quarantänisieren. Lokale Normal-/Race-/Vet-Prüfungen und vier Prozessprüfgruppen bestanden. Konfliktauflösung, native Policy-Recovery, DOP-Remote, Browser-/MCP-Schreibintegration und externe Abnahmen bleiben offen. R0 ergänzt eine ausdrücklich lokale unverändernde Diagnose zu heutigen Zertifikatslinien, Ablauf/Widerruf, Quarantäne, Clock und getrennten Plan-/ Overheadkosten. R1 implementiert reine getrennte Recovery-Bootstrap-Verträge und Offline-Signatur-/ID-Helfer: [CLI](NATIVE_RECOVERY_EVIDENCE_CLI.md). Paket-Normal-/Race-/Vet-Prüfungen und unabhängige Prozessgruppen bestanden. Das ist keine aktivierte Recoveryfunktion. R2 ergänzt separat dauerhaftes Prepare/FirstSeen, Consents/Ablehnungen und atomaren Bootstrap-CAS. Terminale Wiederherstellung, Ownerwechsel und Kapazitätsarchivierung bleiben offene Pakete. R2 ist als ausdrücklich autorisierter gesunder Bootstrap experimentell lokal implementiert: [CLI](NATIVE_RECOVERY_BOOTSTRAP_CLI.md). Ein gemeinsames refs/3- Journal bindet unveränderte N4-Belege, Sourceprojektion, operative Anker und aktuellen Zustands-CAS. Heutige Reviewerconsents und dauerhaftes Zeitfenster aktivieren genau eine erste Constitution; spätere Ablehnungen bleiben wirksam. Paketreviews/Normal/Race/Vet sowie fünf Prozessprüfgruppen bestanden. Das implementiert noch keine terminale Recovery oder Ownerübernahme. ROT1a ergänzt signierte Rotationsbelege und Offline-ID-/Signaturhelfer: [CLI](NATIVE_POLICY_ROTATION_CLI.md). ROT1b implementiert zusätzlich semantische Negatividentitäten, OwnerEpochAck/EpochRejection-Codecs und den [reinen Verifier für gesunde Policywechsel](NATIVE_POLICY_HEALTHY_ROTATION.md). Er prüft bisherige Reviewer, vollständige neue Schlüsselnachweise und Schutzgrenzen gegen unabhängig erhaltene Autorität. ROT2 ergänzt den [refs/4-Epoch-Runtimevertrag](NATIVE_POLICY_EPOCH_RUNTIME.md): signierte Policywechsel mit beobachtetem Zeitfenster, dauerhafte Negativbelege, aktuelle Reviewer-Autorität, OwnerAck für geschützte Applies und atomare Epochen-/Ref-Schreibpfade. Paket-, Race-, Vet- und sieben unabhängige CLI-Prozessprüfgruppen bestanden; die vollständige HTTP-Abnahme des eingefrorenen Quellstands steht noch aus. Eine separate [terminale Same-Owner-Recovery](NATIVE_POLICY_TERMINAL_RECOVERY_CLI.md) hat jetzt Replay, CAS, exakte Ursachen, getrennte R2-Quoren und neun lokale CLI-Prozessprüfgruppen; der vollständige Quellfreeze und die HTTP-Abnahme dieses späteren Standes fehlen. Ownerverlust und unabhängige Produktionsautoritäten bleiben offen. Die explizite private Bridge v2 überträgt mittlerweile bis zu 64 MiB; der v1-Vertrag behält seine 4-MiB-Grenze.