# MF-ARCH-01/02 — gezielter Architekturabgleich und Servicegrenze 25. Oktober 2026. Grundlage: bestehende Quellen/Tests und der aktuelle kleine MCP-/Bootstrap-/Netzwerk-Härtungsschritt. Kein vollständiger Security-Audit und keine Controller-/Handle-Migration. Ausgangsplan bleibt am ursprünglichen Pfad [ARCHITECTURE_WORKPLAN.md](../ARCHITECTURE_WORKPLAN.md). ## MF-ARCH-01: Code und Dokumentation `internal/releaseverify` und die CLI implementieren bereits Policy-/Manifest-/ Review-/Testbelegprüfung, separat vorgegebenes Rootvertrauen, Kandidatenfristen, begrenzte Artefakthashes und prozessgesperrte Checkpoints. Belege sind `verify_test.go`, `negative_test.go`, `codec_test.go`, unabhängige `governance_review_test.go` sowie `release_cli_test.go` und echte CLI-E2E-Berichte. Architektur, Gap-Inventar, Status, Release-Policy und Bedrohungsmodell nennen entsprechend die vorhandene Implementierung. Offen sind reale Founder-Roots, strengere Policy-/Root-Transitions, Installer/Updater, externe Abnahme. Diese Gates dürfen nicht als pauschal fehlender Offline-Verifier formuliert werden. Zusätzlich abgeglichen: gehärtete Klartext-Key-Datei versus fehlender OS-Keystore, Linux-Export-Atomarität versus offene Windows/Powerloss-Gates, öffentlicher Sync versus nicht vorhandenes privates Remote-E2EE. Historische Auditstände und die beiden ursprünglichen verbindlichen Spezifikationen werden nicht umgeschrieben. ## MF-ARCH-02: Zustands- und Ressourcenbesitz | Bereich / Besitzer | Zustand und Synchronisation | Ressourcen / Zugriffsschutz | |---|---|---| | Hub / node_store | Event-/Peer-Caches und komponentenbezogene Fehler unter `h.mu`; Events/Config zusätzlich fresh reload unter State-Prozesslock | begrenzte JSON-Dateien, Store pro Operation öffnen/schließen; Signaturen vor Aufnahme, Marker verhindert stillen Reset | | Hub / network | `syncMu.TryLock` verhindert doppelte Abgleichschleifen; Cursor unter diesem Lock, Statusfelder unter h.mu; Beobachtungen separat prozessgesperrt | HTTP außerhalb h.mu; maximal drei Peers/Zyklus, Seiten-/Byte-/Timeoutbudget; Responses schließen; Hintergrundticker mit Kontext | | Hub / outbox | `outboxMu.TryLock` pro Instanz; Queue-Claims/Leases/ACKs atomar im State-Store; Peer-Snapshot kurz unter h.mu | öffentliche verifizierte Event-IDs, begrenzte Jobs/Fanout/Retry; Transport außerhalb State-Lock; Lease verhindert veraltete ACKs | | HTTP / discovery_ingest und MCP | eigene Admission-Zähler und aktive Semaphore; keine unbeschränkten Worker pro Request | Body-/Antwort-/Rate-/Concurrency-Limits, korrekte Origin-/RPC-Prüfung; MCP lädt nur öffentlichen Cache | | private.go / local_actions | keine öffentlichen Events; pro Request gepinnter Workspace-/Repo-Root; Commit besitzt Repo-Writer-Lock, Registry einen eigenen State-Lock | Loopback/Host/Origin/CSRF, Pfad-/HEAD-/Tree-Bindung; lokale Filehandles per Close, keine Repo-Ausführung | | CLI / remotesync | Client besitzt HTTP-Transport; Bridge besitzt Mapping-/Pending-State und Repo-CAS | Timeout/Cancel, begrenzter Stream, CloseIdleConnections; private Registry nicht automatisch angebunden | | peertrust / releaseverify | separate explizite private State-Verzeichnisse und versionierte Contracts | Create/Open getrennt, eigene Limits; Peerbeobachtung ist keine Release-Autorität | Die lockabhängigen Cacheoperationen folgen `h.mu → State-Lock`; State-Callbacks rufen nicht zurück in Hub-Netzwerkoperationen. HTTP wird nach dem Kopieren des benötigten Zustands außerhalb dieser Locks ausgeführt. Sync-/Outbox-Serienlocks umschließen ihre jeweiligen Abläufe; sie greifen nicht gegenseitig ineinander. MCP-Admission wird vor Cache-I/O begrenzt, damit langsame Cacheprüfung keine unbegrenzte Requestwarteschlange vor der Admission erzeugt. Begrenzte offene Punkte: Eventreload prüft/serialisiert weiterhin einen ganzen begrenzten Cache, was CPU-/Latenzkosten verursacht; keine Produktions-SLO-Behauptung. Hub-Transport ist pro Prozess langlebig, kein eigenständiges Service-Close/Graceful- Shutdown-Modell. Der Scheduler-Kontext beendet den Ticker; laufende einzelne Operationen verwenden eigene endliche Timeouts. Eine weitere Lifecycle-Extraktion ist hierfür nicht nebenbei erforderlich und wird nicht als bereits gelöst behauptet. ## Eine begründete konkrete Servicegrenze Ausgewählt ist **öffentliche Netzwerkadresspolicy und geprüfter Dialer** in `internal/netpolicy`. Vorher besaß Discovery eine `IsGlobalUnicast`-/Privateprüfung, Bootstrap begann eine weitere, und Public-Sync nutzte einen separaten Transport. Die Regeln waren dadurch nicht deckungsgleich. Die unabhängigen Regressionen zeigten tatsächliche Akzeptanz von CGN-, Benchmark-, Dokumentations- und reservierten Adressen; auch ein ausschließlich literal geprüfter Host würde die DNS-Grenze nicht schützen. Das ist eine Sicherheitskopplung, kein Argument aus Dateigröße. Nachher verwenden alle drei Consumer eine konkrete konservative `PublicIP`-/ Hostpolicy und einen Transport, der genau die geprüfte numerische DNS-Adresse anwählt, ohne Environment-Proxy. Redirectverbote und fachliche Timeouts bleiben bei den jeweiligen Clients. Es wird keine Authentisierung aus dem Dialer entfernt oder in einen großzügigen Fallback ausgelagert. Loopback bleibt ausdrückliche Fixture-/lokale-Origin-Ausnahme; LAN ist keine öffentliche Policyalternative. ```mermaid flowchart LR Hub[Discovery und Outbox] --> NP[netpolicy: PublicIP und geprüfter Dialer] Sync[Public-Sync-Client] --> NP Bootstrap[Bootstrap-Probe] --> NP NP --> HTTP[Go net/http Transport] Hub --> State[State-Prozesslock und atomare Dateien] Bootstrap --> Obs[Private Peerbeobachtungen] Verifier[Offline-Release-Verifier] --> CP[Separater Release-Checkpoint] ``` Entscheidung nach §4 des Arbeitsplans: **konkreter Service, keine Registry**. Es gibt eine fachliche Public-Policy und einen Dialer, keine drei realen laufzeitwählbaren Provider und keinen Capability-Resolverbedarf. Betriebssystem- Varianten und Testdoubles zählen nicht als zusätzliche Produktprovider. Auch Bootstrap und Discovery sind keine austauschbaren Speicher-/Identitätsdienste. Betroffene Nachweise: `internal/netpolicy/public_test.go` (fake DNS, Unmap, Sondernetze, kein zweiter Resolve), `security_review_test.go` (Discovery), `internal/remotesync/network_review_test.go` (Snapshotclient), `internal/peertrust/protocol_test.go` (Kandidaten) sowie bestehende Zwei-CLI- Public-Sync-E2E. Gemeinsame Vollsuite/Race/Vet, Linux-amd64- und Windows-amd64/arm64- Crossbuilds sowie tatsächliche MCP-/Bootstrap-/HTML-/Zwei-Client-Public-Sync-E2E bestanden; MF-ARCH-03 ist damit im beschriebenen Entwicklungsvorschau-Umfang abgeschlossen. Reine Dokumentationsprüfung wird nicht als neue Runtimeprüfung ausgegeben; echte Windows- und externe Sicherheitsabnahme bleiben offen. MF-ARCH-04–06 bleiben bedingte P2-Tickets. Keine Payment-/Wallet-/Buzz-Adapter werden erfunden, um eine Dreierregel zu erfüllen. Vor einer tatsächlich passenden Controller-/Handle-Migration wäre der referenzierte Skill gezielt anzuwenden.