# MeshForge: Architekturentscheidungen und ausführbarer Arbeitsplan Stand: 25. Oktober 2026. Status: Plan zur gezielten Modularisierung; keine Controller-/Handle-Migration implementiert. Projektordner: `decentralhub`; Produktname: MeshForge. ## 1. Ziel und Entscheidung MeshForge soll um klar getrennte optionale Implementierungen erweitert werden können, ohne Speicher-, Identitäts- und Protokollcode unnötig zu abstrahieren. Das Controller-/Handle-Muster wird deshalb pro Domäne geprüft und erst bei nachgewiesenem Bedarf eingeführt. Eine flächendeckende Migration ist nicht das Ziel dieses Plans. Die heutige Empfehlung lautet: bestehende Go-Pakete und Sicherheitsgrenzen erhalten, überladene Zuständigkeiten bei konkretem Bedarf in kleine Services zerlegen und später geeignete Providerdomänen über eine explizite Registry erweitern. Der stärkste künftige Kandidat sind Spenden-/Payment-Adapter. Dieser Plan ergänzt die vorhandene Roadmap. Er ersetzt weder deren Reihenfolge noch das Sicherheitsmodell. Optionale Wallet-, Payment- und Buzz-Funktionen bleiben nachgeordnet. Es werden keine neuen externen Abhängigkeiten benötigt, um die hier beschriebenen Architekturentscheidungen zu prüfen. ## 2. Einstieg für den nächsten Agent 1. Aktuellen Nutzerauftrag lesen und den Umfang des Auftrags festhalten. 2. `AGENTS.md`, `docs/ROADMAP.md` und die relevanten Teile dieses Plans lesen. 3. Für das gewählte Ticket die genannten Quellen und vorhandenen Tests prüfen. Dokumentationsstand und tatsächlichen Code unterscheiden. 4. Änderungen anderer Arbeiten erhalten. Repository-/Snapshot-Status feststellen; falls keine Git-Metadaten vorhanden sind, dies berichten und keine Revision erfinden oder ungefragt ein Repository initialisieren. 5. Das kleinste passende, freigegebene Arbeitspaket bearbeiten. Ein blockiertes optionales Ticket nicht durch einen anderen Funktionsausbau umgehen. 6. Passende Prüfungen ausführen, Ergebnisse dokumentieren und Ticket aktualisieren. Dieser Plan ist keine automatische Aufforderung, sämtliche Arbeiten zu starten. Bei einem allgemeinen Auftrag zur Umsetzung dieses Plans ist zunächst MF-ARCH-01 dran. Anschließend folgt MF-ARCH-02; weitere Schritte hängen von dessen Befund und der geltenden P0/P1-Priorität ab. ### Maßgebliche Quellen | Quelle | Zweck | |---|---| | [ARCHITECTURE.md](docs/ARCHITECTURE.md) | Paket- und Vertrauensgrenzen | | [ROADMAP.md](docs/ROADMAP.md) | Reihenfolge P0, P1, P2 | | [GOVERNANCE_GAP.md](docs/GOVERNANCE_GAP.md) | Dokumentiertes IST/ZIEL-Inventar; Aktualität prüfen | | [IMPLEMENTATION_STATUS.md](docs/IMPLEMENTATION_STATUS.md) | Umsetzungsmatrix des Masterplans | | [Masterplan](docs/DECENTRALHUB_CODEX_MASTERPLAN.md) | Ursprüngliche Anforderungen, insbesondere Provider-Modell | | [Governance-Erweiterung](docs/MESHFORGE_CODEX_GOVERNANCE.md) | Additive Prioritäten und Freigabegates | | [SECURITY.md](docs/SECURITY.md), [THREAT_MODEL.md](docs/THREAT_MODEL.md) | Sicherheitsanforderungen | | [VALIDATION.md](docs/VALIDATION.md) | Ausgeführte Prüfungen und offene Plattformnachweise | | [Controller-/Handle-Skill](../controller-handle-architecture-publish/SKILL.md) | Kriterien und gezielt nachzuladende Referenzen | Der Skill liegt außerhalb dieses Projekts, aber im selben Workspace. Wird das Projekt separat weitergegeben, ist der relative Skill-Link möglicherweise nicht verfügbar. Die Entscheidungskriterien dieses Plans bleiben dann lesbar; vor einer explizit nach dem Skill durchgeführten Migration muss dessen Quelle verfügbar sein. ## 3. Beobachteter Ausgangsstand Die folgende Bestandsaufnahme basiert auf gezielter Quellsichtung, nicht auf einem vollständigen Architektur- oder Sicherheitsaudit. Für diese Planung wurden keine Go-Tests ausgeführt. Vor Umsetzung ist der jeweilige Stand erneut zu prüfen. | Bereich | Beobachtung | Konsequenz | |---|---|---| | `cmd/decentralhub/main.go` | CLI-Dispatch, HTTP-Routen und `Hub` mit Events, Peers, HTTP-Client, Workspace und Synchronisationszustand | Zuständigkeiten gezielt untersuchen; eine Registry folgt daraus noch nicht | | `internal/localrepo` | Lokale Snapshots, CAS, Recovery, Export und Plattformvarianten | Bestehenden Dienst erhalten; kein belegter Bedarf für mehrere Speicherprovider | | `internal/state` | Gemeinsame begrenzte und prozessgesicherte Zustandsablage | Als Infrastruktur verwenden, nicht vorsorglich durch ein Plugin-System ersetzen | | `internal/identity` und `cmd/decentralhub/keystore*.go` | Geräteidentität sowie lokale Schlüsseldateien mit plattformspezifischen Prüfungen | Plattformcode ist kein Nachweis laufzeitwählbarer Provider | | `internal/remotesync` | Expliziter öffentlicher Store und HTTP-Client mit Owner-Pin | Keine Gleichsetzung öffentlicher und privater Transporte | | `internal/releaseverify` | Verifier, Policy-/Manifest-Typen, persistente Checkpoints und Tests vorhanden | Bereits implementierten Stand vor Dokumentationskorrektur genau abgleichen | | Payment/Wallet/Buzz | Im Masterplan und der Governance als optionale Zielmodule beschrieben | Geplante Varianten nicht als vorhandene Implementierungen zählen | Insbesondere bedeutet ein vorhandener Release-Verifier weder einen fertigen Updater noch einen bestätigten Founder-Root oder eine Produktionsfreigabe. Umgekehrt dürfen ältere Übersichtstexte nicht dazu führen, bereits existierende Verifier-Funktionen erneut zu implementieren. ## 4. Entscheidungskriterien pro Domäne Vor jeder neuen Controller-/Handle-Domäne schriftlich beantworten: 1. Welche gemeinsame fachliche Aufgabe erfüllen die Implementierungen? 2. Gibt es mindestens drei echte, unterschiedliche Implementierungen dieser Aufgabe? Drei Module mit unterschiedlichen Aufgaben zählen nicht. 3. Wählt der laufende Prozess anhand einer ID, Konfiguration oder fachlicher Fähigkeiten zwischen ihnen? Auswahl beim Build zählt nicht. 4. Soll eine zusätzliche Implementierung ohne Änderung bestehenden Dispatch- oder Controllercodes möglich sein? Eine Ergänzung der Verdrahtung ist erlaubt. 5. Gibt es zusätzlich zur ID-Auswahl Bedarf für Capability-Auflösung oder eine andere begründete Orchestrierung? Für reine Auswahl kann Strategy plus eine einfache Tabelle ausreichen. | Befund | Angemessene Lösung | |---|---| | Eine Implementierung | Konkreter Service | | Zwei feste Implementierungen | Kleines Interface und explizite Konstruktion, falls erforderlich | | Fester Satz von Operationen | Bestehender `switch`, Funktionen oder einfacher Dispatcher | | Mehrere gleichartige HTTP-Routen | `http.ServeMux` und klar geschnittene Handler | | Drei oder mehr erweiterbare Strategien mit reiner ID-Auswahl | Kleines Interface mit expliziter Auswahltabelle prüfen | | Drei oder mehr laufzeitwählbare Strategien mit begründetem Orchestrierungsbedarf | Controller-/Handle-Domäne prüfen | Die Anzahl von CLI-Befehlen, Peer-URLs, Dateitypen oder Betriebssystemdateien erfüllt diese Kriterien nicht automatisch. Ein Testdouble zählt ebenfalls nicht als zusätzliche Produktimplementierung. ### Kandidaten und Grenzen - **Spenden-/Payment-Adapter:** aussichtsreichster späterer Pilot. Der Masterplan fordert ein offenes Provider-Modell. Mehrere Marken mit identischem externem HTTPS-Link können allerdings ein einziger konfigurierbarer Adapter sein. - **Wallet-Verifikation:** mögliche spätere Domäne. BTC, BCH und BSV dürfen nur hinter einem Vertrag zusammengeführt werden, der ihre Unterschiede ausdrücklich trägt. Drei Chain-Bezeichnungen allein belegen noch keine drei fertigen Adapter. - **Peerquellen:** später Kandidat, wenn etwa explizite Konfiguration, signierter Bootstrap und ein weiterer implementierter Mechanismus eine gemeinsame Aufgabe erfüllen. Herkunft liefert Kandidaten, keine Release-Autorität. - **Transporte:** erst bei mehreren realen Implementierungen desselben Vertrags. HTTP-Discovery, lokaler Dateizugriff und Public-Sync sind nicht allein wegen ihrer technischen Kommunikation austauschbar. - **Buzz/Nostr:** ein einzelner optionaler Adapter benötigt keinen Controller. - **Speicher, Identität, Releaseprüfung:** aktuell konkrete Dienste und vorhandene kleine Interfaces beibehalten; eine Registry ist nicht begründet. ## 5. Regeln für eine spätere Umsetzung in Go ### Verträge und Verdrahtung - Interfaces nahe am konsumierenden Fachbereich definieren und klein halten. Keine universelle Schnittstelle für Wallets, Payments, Transport und Storage. - Eine Registry pro qualifizierter Domäne. Nicht ein Controller pro CLI-Befehl, Seite oder einzelner Implementierung. Namen dürfen Go-üblich `Registry` oder `Resolver` lauten; entscheidend sind die Verantwortlichkeiten. - Handles enthalten oder kapseln die konkrete Implementierung. Die Registry validiert Registrierung, löst IDs auf und orchestriert nur begründete Auswahl. - Bestehende Dienste weiterverwenden. Keine Neuimplementierung von Signaturen, Persistenz oder Autorisierung, nur um das Muster einzuführen. - Abhängigkeiten über Konstruktoren übergeben. Der Composition Root erzeugt Dienste und registriert Adapter; Handles greifen nicht auf globale Registries zu. - Die vorhandene Startverdrahtung reicht zunächst aus. Ein neues App-Paket erst einführen, wenn mehrere Einstiegspunkte oder die konkrete Komplexität es tragen. ### Registrierung, Reihenfolge und Fehler - Doppelte oder ungültige IDs bei der Konstruktion ablehnen; unbekannte IDs liefern einen expliziten Fehler. Keine stille Auswahl eines Standardproviders. - Eine Go-`map` garantiert keine Iterationsreihenfolge. Falls Reihenfolge fachlich erforderlich ist, zusätzlich eine geordnete Liste oder einen expliziten Prioritätsplan führen. Lookup und Reihenfolge müssen konsistent bleiben. - Registrierung vorzugsweise beim Start abschließen. Die anschließend nur lesbare Struktur ohne Veränderungsmöglichkeit nach außen geben. - Initialisierung wiederholbar gestalten: erneuter Aufbau erzeugt einen neuen, unabhängigen gültigen Satz; keine globalen Doppelregistrierungen. Ein Reset ist nur bei tatsächlich vorhandenem veränderlichem Registry-Zustand nötig. - Kein Hot-Plugging, Eventbus, Lazy Loading, Circuit Breaker oder Reload ohne konkreten Bedarf. Austauschbare Implementierungen erfordern kein Nachladen fremden Codes zur Laufzeit. ### Nebenläufigkeit und Ressourcen - Eine unveränderliche Registry macht veränderliche Handles nicht automatisch nebenläufig sicher. Zustand, Locks und Ressourcen jedes Adapters separat prüfen. - Netzwerkoperationen benötigen begrenzte Laufzeit und Abbruch; vorhandene Limits, Redirect-/Proxy-Regeln, SSRF-Prüfungen und Retry-Grenzen erhalten. - Der Besitzer von Ressourcen regelt `Close` und Fehler beim Teilaufbau. Bereits erzeugte Ressourcen müssen bei späterem Initialisierungsfehler freigegeben werden. - Müssen Registrierung und Auflösung später parallel stattfinden, zuerst einen ausdrücklichen Synchronisations- und Lebenszyklusvertrag entwerfen und testen. ## 6. Sicherheits- und Kompatibilitätsgrenzen 1. Offline-Arbeit bleibt ohne Domain, Account, Git, LLM oder Payment-Provider möglich. 2. Lokale private Projekte und öffentlicher Sync-Store bleiben getrennte explizite Wurzeln. Keine automatische Veröffentlichung durch Adapterregistrierung. 3. Bestehende IDs, kanonische Bytes, Signaturkontexte und v1-/DOP-Formate erhalten. 4. Loopback-/Host-/Origin-/CSRF-Prüfungen sowie CAS und Review-Bindung bleiben an allen bestehenden Schreibpfaden wirksam. 5. Wallet-Verknüpfung ersetzt nicht die primäre Identität. Netzwerk, Methode, Audience, Aktion, Nonce und Ablauf müssen zur jeweiligen Verifikation passen. 6. Fallback darf keine Autorisierung oder Vertrauensentscheidung abschwächen. Fehlgeschlagene Signaturprüfung ist kein Anlass, einen großzügigeren Provider zu versuchen. Ein Benutzerwunsch nach einer Chain darf nicht umgedeutet werden. 7. Externe Zahlungslinks bleiben optionale Metadaten. Keine Seeds, privaten Wallet-Schlüssel, Kartendaten oder automatische Transaktionsausführung ergänzen. 8. Peeranzahl, Sterne und Discovery-Herkunft werden nicht zu Release-Autorität. Keine automatische Update-Ausführung durch diesen Architekturplan. ## 7. Tickets und Abnahme Alle nachstehenden Tickets sind zunächst **offen**. „Bedingt“ bedeutet, dass ein Gate erfüllt werden muss; solche Tickets sind keine sofortige Implementierungsliste. ### MF-ARCH-01 — Architekturübersicht mit dem Code abgleichen **Status:** offen. **Abhängigkeiten:** keine. **Umfang:** Dokumentation. - `internal/releaseverify` und dessen Tests mit Architektur, Status, Gap-Inventar und Release-Policy vergleichen. Tatsächlich vorhandene Funktionen und noch offene Integration/Trust-Gates getrennt dokumentieren. - Weitere direkt betroffene Paketbeschreibungen gezielt abgleichen. Originalen Masterplan und Governance-Spezifikation als historische Vorgaben erhalten. - Keine pauschale Aussage „Release-Verifikation fehlt“ übernehmen, wenn sie nur noch auf echte Roots, Installation oder vollständige Governance zutrifft. **Abnahme:** aktuelle Übersicht nennt den vorhandenen Verifier und seine Grenzen; jede geänderte Implementierungsaussage hat einen konkreten Quell-/Testnachweis. Dokumentationskorrekturen suggerieren keine ausgeführte Runtime-Verifikation. ### MF-ARCH-02 — `Hub` und Einstieg auf konkrete Trennungsgrenzen prüfen **Status:** offen. **Abhängigkeiten:** MF-ARCH-01. **Umfang:** begrenzte Analyse. - `main.go`, `network.go`, `node_store.go`, `outbox.go`, `discovery_ingest.go`, `private.go` und `local_actions.go` nur soweit für die Frage nötig untersuchen. - Für Events, Peerzustand, Zustellung und HTTP darstellen: Zustandsbesitz, Abhängigkeiten, Locks, Ressourcen und Zugriffsschutz. - Ein einzelnes zusammenhängendes Extraktionspaket vorschlagen. Die Begründung muss eine konkrete Kopplung oder Wartungsschwierigkeit zeigen; Dateigröße allein genügt nicht. Das Ergebnis „aktuell keine Extraktion nötig“ ist zulässig. - Eine kleine Skizze der Abhängigkeiten sowie Liste der betroffenen Tests ablegen. **Abnahme:** klare Grenze mit Vorher-/Nachher-Verantwortlichkeiten und unveränderten Sicherheitsprüfungen; Entscheidung zwischen einfachem Service und Registry anhand von Abschnitt 4. Keine Implementierung optionaler Provider als Nebenarbeit. ### MF-ARCH-03 — Einen begründeten Service extrahieren **Status:** bedingt. **Gate:** MF-ARCH-02 weist einen konkreten Nutzen nach; Änderung passt zum aktuellen P0/P1-Arbeitspaket oder ist ausdrücklich beauftragt. - Genau eine zusammenhängende Verantwortung verschieben und Abhängigkeiten explizit übergeben. Bestehende öffentliche CLI-/HTTP-Verträge erhalten. - Sicherheitsprüfung und Operation nicht versehentlich voneinander entkoppeln. Gemeinsamen Zustand und bisherige Lock-Reihenfolge ausdrücklich überprüfen. - Vorhandene Tests weiterverwenden; zusätzliche Tests nur für neue Grenzen oder sonst nicht abgedeckte Risiken hinzufügen. **Abnahme:** Verhalten kompatibel, kein globaler Service-Locator, keine neue Registry ohne erfülltes Gate; betroffene Tests und erforderliche Gesamtprüfungen bestanden oder konkrete verbleibende Blocker dokumentiert. ### MF-ARCH-04 — Entscheidung für die erste Providerdomäne festhalten **Status:** bedingt. **Gate:** entsprechende P2-Funktion ist nach der Roadmap dran oder ausdrücklich beauftragt; zugehörige Sicherheitsvoraussetzungen sind geklärt. - Zuerst Spenden-/Payment-Adapter prüfen. Unterstützte Anwendungsfälle und fachlich verschiedene Implementierungen konkret benennen. - Für jede Variante Eingaben, Validierung, Ausgabe, externe Interaktion und Fähigkeiten notieren. Reine Konfigurationsvarianten zusammenfassen. - Gemeinsamen Vertrag und Versionierung skizzieren. Payment-Anzeige und Wallet- Login nicht vermischen. Datenmigration nur bei nachgewiesener Notwendigkeit. - Alle fünf Entscheidungskriterien beantworten. Bei zu wenigen Implementierungen oder reinem Lookup ausdrücklich die einfachere Lösung beschließen. **Abnahme:** kurze dokumentierte Entscheidung mit konkreten Beispielen, Sicherheitsgrenzen, Alternativen und begründetem Ja/Nein zur Registry. Noch keine Zusage nicht geprüfter Wallet-/Provider-Kompatibilität. ### MF-ARCH-05 — Begrenzten Provider-Piloten implementieren **Status:** bedingt. **Gate:** MF-ARCH-04 rechtfertigt Controller/Handle und die ausgewählten Implementierungen sind fachlich spezifiziert. - Vor Codegenerierung `references/core-workflow.md` des Skills lesen; bei Migration zusätzlich die passenden Migrations-/Wrapping-Referenzen laden. - Domänenschnittstelle, explizite Registry und Startverdrahtung implementieren. Bestehende Services kapseln. Neue Dateien nur für diese Domäne anlegen. - Echte Anwendungsfälle umsetzen; keine künstlichen Adapter erfinden, um die Dreierregel zu erfüllen. Ausschließlich Testadapter belegen keine Produkteignung. - Zunächst ohne Hot-Plugging oder globale Registry arbeiten. Optionale Funktionen dürfen beim normalen Offline-Start keine Netzwerkverbindung erzwingen. **Abnahme:** neue Implementierung benötigt nur ihren eigenen Code, Tests und Registrierung im Composition Root; Controller/Dispatch bleiben unverändert. Fehler-, Reihenfolge-, Lebenszyklus- und relevante Vertrauensgrenzen sind geprüft. ### MF-ARCH-06 — Pilot bewerten und Folgeschritte begrenzen **Status:** bedingt. **Abhängigkeiten:** MF-ARCH-05. - Prüfen, ob neue Adapter tatsächlich ohne zusätzliche Sonderfälle hinzukommen. - Aufwand, Verständlichkeit, Fehlersichtbarkeit und erhaltene Grenzen bewerten. - Nur bei belegtem Nutzen eine weitere qualifizierte Domäne auswählen. Keine automatische Übertragung auf Storage, Identität oder Releaseprüfung. - Bei fehlendem Nutzen vereinfachen und die Entscheidung dokumentieren. **Abnahme:** nachvollziehbare Fortsetzungs- oder Vereinfachungsentscheidung; Architektur-, Implementierungsstatus und dieser Plan bilden denselben Stand ab. ## 8. Verifikation passend zum Ticket Für reine Dokumentationsänderungen Links, Pfade, Begriffe und Aussagen gegen die Quellen prüfen. Dafür keine neuen Go-Tests schreiben und keine nicht ausgeführten Tests als bestanden nennen. Bei Codeänderungen zuerst betroffene vorhandene Tests ausführen. Neue Tests prüfen Verträge und Risiken, nicht bloß die interne Form der Implementierung. Für einen Registry-Piloten sind insbesondere erforderlich: - Doppelte/ungültige IDs sowie unbekannte und deaktivierte Provider. - Deterministische Reihenfolge, sofern sie zum Vertrag gehört. - Wiederholter Aufbau ohne Doppelregistrierung oder Zustandsreste. - Ressourcenfreigabe bei Teilfehlern und regulärem Ende. - Konkurrierende Nutzung bei tatsächlich gemeinsam verwendetem Zustand. - Keine öffentliche Veröffentlichung durch bloße Registrierung oder lokale Aktion. - Kein Fallback nach Authentisierungs-/Signaturfehlern, sofern Auswahl/Fallback Bestandteil der Domäne ist. - Providerbezogene positive und negative Vektoren; bei Wallets insbesondere falsche Chain, Methode, Origin, Nonce, Ablauf und Replay. Nach einer zusammenhängenden Go-Änderung im Projektroot die erforderlichen Gesamtprüfungen ausführen: ```sh go test ./... go test -race ./... go vet ./... ``` Plattformabhängige Änderungen benötigen zusätzlich die etablierten Crossbuilds und, wo erforderlich, echte Plattformtests. Crossbuilds ersetzen keine Ausführung auf Windows-Hardware. Netzwerk-/Toolchain-Hindernisse mit genauer fehlgeschlagener Prüfung berichten; keine Abhängigkeiten ungefragt nachinstallieren. ## 9. Fortschritt und Übergabe Nach jedem bearbeiteten Ticket diesen Block mit tatsächlichen Ergebnissen ergänzen: ```text Ticket: Datum: Status: offen | in Arbeit | abgeschlossen | blockiert | entfällt Aktueller Auftrag und Umfang: Geprüfter Quellstand: Revision oder dokumentierter Dateistand Entscheidung und Begründung: Geänderte Dateien: Ausgeführte Prüfungen und Ergebnisse: Nicht ausgeführte Prüfungen und Grund: Offene Risiken / Gate für den nächsten Schritt: Nächstes passendes Ticket: ``` Ein Ticket ist erst abgeschlossen, wenn seine Abnahme erfüllt ist. Eine bewusst abgelehnte Registry ist bei MF-ARCH-04 ein gültiger Abschluss; MF-ARCH-05 und MF-ARCH-06 können dann mit Begründung als „entfällt“ markiert werden. Bei längeren Arbeiten den Workspace-Handoff-Prozess verwenden. Ein vollständiges rekursives `LAYERED-AUDIT/v2` ist für diesen Plan nicht erforderlich. Es wird erst bei einem ausdrücklich passenden großen Controller-/Handle-Konformitätsaudit eingesetzt; seine Vorbereitung ist keine Voraussetzung für eine kleine Extraktion. ### Bearbeitung 25. Oktober 2026 - **MF-ARCH-01: abgeschlossen.** Tatsächlicher Release-Verifier einschließlich CLI, Quoren, Fristen, Negativpersistenz und Checkpoint gegen Quellen/Tests abgeglichen; Übersicht, Status, Gap-Inventar, Release-Policy und Threat Model nennen vorhandenen Code getrennt von Root-/Transition-/Installer-Gates. - **MF-ARCH-02: abgeschlossen.** Gezielte Hub-/State-/Lock-/Ressourcenanalyse und Abhängigkeitsskizze in [ARCHITECTURE_REVIEW.md](docs/ARCHITECTURE_REVIEW.md). Eine konkrete Public-Netzwerkpolicy/Dialer-Servicegrenze ist durch reproduzierte divergierende IP-/DNS-Prüfungen begründet; keine Controller-/Handle-Registry. - **MF-ARCH-03: abgeschlossen.** `internal/netpolicy` mit Discovery-, Public-Sync- und Bootstrap-Verwendung implementiert; gezielte Race-Regressionen bestanden. Gemeinsame Vollsuite/Race/Vet, Linux-amd64- und Windows-amd64/arm64-Crossbuilds sowie echte MCP-/Bootstrap-/HTML-/Zwei-Client- Public-Sync-E2E bestanden. Kein Sicherheitsfallback oder Formatwechsel; echte Windows- und externe Sicherheitsabnahme bleiben offen. - **MF-ARCH-04–06: bedingt/offen.** P2-Funktion und tatsächlich qualifizierte Providerdomäne noch nicht erreicht; keine künstlichen Adapter implementiert. Quellstand: aktueller dokumentierter Dateistand der genannten Module, aufbauend auf dem verifizierten lokalen nativen Source-Checkpoint; keine Git-Revision erfunden und kein Git-Repository initialisiert. Geänderte Dokumente: dieser Fortschrittsblock, ARCHITECTURE_REVIEW und die aktuelle Übersicht/Statusmatrix. Dokumentationslinks/Behauptungen wurden anhand der Quellen geprüft; keine neuen Tests allein für Dokumentationsform geschrieben. Runtime-Nachweise stehen in [VALIDATION.md](docs/VALIDATION.md), Plattform-/Auditgates bleiben ausdrücklich offen.