# MeshForge — Release-Policy und Aktivierungsgates

**Status: experimenteller Offline-Verifier und CLI implementiert; kein Installer
oder Updater, keine reale Release-Freigabe.** `1.0.0-preview` bezeichnet einen Entwicklungsstand,
keine zertifizierte Produktionsversion. Lokale Builds werden nicht automatisch
als autorisierte SteveCo-AI-Releases ausgegeben.

## Root-Vertrauen

Es ist kein unabhängig bestätigter Founder-Fingerprint eingerichtet. Ein
Download-Peer, Installer oder neu erzeugter Node-Key darf ihn nicht selbst
festlegen. Vor echter Freigabe muss ein Betreiber die anfänglichen öffentlichen
Roots über einen unabhängigen Kanal bestätigen. Fixtures benutzen ausdrücklich
getrennte Test-Policies. Domain, Sterne, Unternehmen, KI-Identitäten und 1000
künstliche Peers ersetzen keine einzige erforderliche autorisierte Signatur.

## Implementierter experimenteller Vertrag

Der Offline-Verifier prüft zuerst Root-/Maintainer-Delegationen und lokale Policy,
anschließend kanonisches Manifest, Plattform/Architektur, Protokollkompatibilität,
Binärhash, vorherigen autorisierten Checkpoint, Ablauf und Build-Provenienz-Digest.
Er lehnt ohne konfigurierte Policy ab. [CLI und Grenzen](RELEASE_CLI.md), [Protokoll](../protocol/RELEASE-EXPERIMENTAL.md).
Jeder Review/Testbeleg bindet den
exakten Kandidatenhash; geänderte Bytes benötigen neue Freigaben und ein neues
betroffenes Zeitfenster. Peer-Verbreitung bleibt lediglich Verfügbarkeitsanzeige.

Risikoklassen, Quoren, unabhängige Gruppen und Fristen gehören in eine versionierte
signierte Policy. Die Governance-Vorgabe schlägt 1/2/3 Reviews und 24h/72h/7 Tage
vor; diese Werte sind keine mathematische Sicherheitsgarantie. Reale Gruppen-
Unabhängigkeit ist organisatorisch zu prüfen. Für Policy-Wechsel existiert ein
experimenteller expliziter Opt-in-Pfad mit stärkerem Rootquorum, Übergangsreviews
und -tests sowie lokalen Policy-Floors; Details und Grenzen stehen in der
[Governance-CLI](GOVERNANCE_CLI.md). Separat provisioniertes v2 erlaubt
Rootrotation und terminalgebundene Recovery ([Recovery-CLI](RECOVERY_CLI.md));
ein Emergency-Bypass bleibt ausgeschlossen. Lokale Entwicklungsarbeit wartet nicht diese Fristen ab.

Rollback-/Freeze-Schutz verlangt persistierte geprüfte Checkpoints und gültige
Zeitannahmen. Rotation muss vom bisherigen Trust-Anker autorisiert werden und
Kompromittierungs-/Recovery-Verfahren beschreiben. Fehlende/kaputte State-Dateien
dürfen kein stilles Zurücksetzen auf eine alte gültige Version ermöglichen.

## Vor einer produktiven Freigabe

Linux-/echte Windows-E2E, Failure-/Recovery-/Upgrade-Tests, Security-Audit,
finale Reproduktion des eingefrorenen aktuellen Sources, dokumentierte Disclosure-
und Betriebsprozesse sowie verifizierte Root-/Quorumpolicy sind offen. Die
[Build-/SBOM-/Provenienzwerkzeuge](REPRODUCIBLE_BUILDS.md) existieren und wurden
mit zwei Pfaden/drei Targets auf dem früheren nativen Source-Snapshot 11 geprüft. Crossbuilds
belegen keine Windows-Laufzeit. Artefakte dürfen über beliebige Peers transportiert
werden, aber niemals vor lokaler Verifikation ausgeführt werden. Der implementierte
Verifier prüft ausschließlich Bytes und Metadaten; Installation erfordert eine eigene geprüfte
atomare, rollbackfähige und ausdrücklich autorisierte Implementierung.

Unveränderter v1-Übergangs-Gate: Ohne `transition_rules` wird Policy-Sequenz 1 lokal
gepinnt und jeder spätere Policywechsel abgelehnt. Mit bei `release-trust-init`
provisionierten Regeln ist ein Policywechsel möglich, sofern Signaturen, Quoren,
Floors, Zeitfenster und persistenter Checkpoint ihn zulassen. Lokale Rootpins
bleiben unveränderlich. V1 erlaubt keine Recovery, wenn nach Aktivierung
eine gültige Ablehnung der zuletzt aktivierten Transition bekannt wird; dieser
Fall sperrt die Trustinstanz dauerhaft. Diese Grenze wird durch v2 nicht nachträglich aufgehoben.

V2 verwendet denselben Checkpointpfad mit eigenem Schema; alte Verifier lehnen
es ab. Migration ist ein ausdrücklicher CAS auf die exakten v1-Dateibytes und
verweigert jedes vorhandene aktivierte `LastTransition`, auch nichtterminale.
Recoveryregeln werden vorher unabhängig provisioniert; kein Löschen/Neuanlegen
oder Timeout hebt Quarantäne auf. Ein Recoverykandidat bindet den aktuellen
terminalen Gesamtanker und genau eine Ursache; weitere offene Ursachen sperren
weiter. Neue Rootgeneration/Policysequenz, erhaltene Release-/Negativhistorie und
Reviewfrist gelten auch nach Recovery. Die CLI lädt/installiert keine Artefakte.
Private Schlüssel-/Datenpakete sind davon getrennt: [Pakete](PRIVATE_PACKAGES.md),
[private Sync](PRIVATE_SYNC_CLI.md). Deren Readkey-Export ist keine Governance-Recovery.