# Experimentelle Release-Rootrotation und Recovery v2 Die neue **explizite opt-in** API und CLI verwenden `mf.release-checkpoint/2` am selben `release-checkpoint.json`-Pfad wie v1. V1-Konfiguration und Hashbytes bleiben unverändert; alte Writer lehnen das neue Schema ab. Das ist kein Installer, Auto-Updater oder automatisch bestätigter Founder-Trust. ## Vorab getrenntes Vertrauen provisionieren Die lokale v2-Trustdatei enthält exakt zwei typisierte Felder in dieser Reihenfolge: `legacy` mit der vollständigen bisherigen lokalen Config und `recovery_rules` mit den vorab unabhängig bestätigten Regeln aus `releaseverify.RecoveryRules`. Dazu gehören Recoverykeys/-quorum, getrennte Recoveryreviewer mit Gruppen/Rollen/Gültigkeit, stärkere Rotationsquoren, Review-/Testregeln und unveränderliche Policyfloors. Recoverykeys und -reviewer dürfen weder aktive Roots noch Online-Policy- Delegationen sein. Bundles können diese lokalen Regeln nicht setzen oder ändern. Reviewfristen sind positiv; es gibt kein `--force`, Nullfenster oder Timeout- Override. Echte Gruppenunabhängigkeit und Founderidentität sind externe Nachweise. ```sh mf release-v2-init --trust /trusted/recoverable.json --state /trusted/new-release-state mf release-v2-status --trust /trusted/recoverable.json --state /trusted/release-state ``` Zielverzeichnisse müssen vorher bestehen; Init ersetzt keine vorhandene Datei. Status liest den frisch geprüften Checkpoint unter Lock. Er nennt Genesistrust, aktive Rootgeneration/-ID, Policy-/Releasehead, ausgewählte terminale Ursache, genauen Terminalanker und weitere ungelöste Ursachen. Das sind lokale Integritätsinformationen, kein unabhängiger Herkunftsbeweis. ## Explizite Migration ```sh mf release-v2-migrate --trust /trusted/recoverable.json --state /trusted/existing-state --expected-checkpoint INDEPENDENTLY_REVIEWED_V1_FILE_SHA256 ``` Der Digest bindet die **exakten** zuvor unabhängig lokal geprüften v1-Dateibytes. Migration erfolgt einmal atomar unter derselben Prozesssperre; Releasehistorie, Negativbefunde und Quarantänen bleiben erhalten. Keine Sidecar-Zustandswelt und kein stiller Open-Fallback. Bei unklarem Syncausgang erst Wiederöffnung/Inspektion. **Aktuelle Grenze:** Jeder v1-Checkpoint mit `LastTransition` wird abgewiesen, auch wenn die Transition bislang nicht abgelehnt wurde. Die v2-Bibliothek kann später eintreffende Ablehnungen dieses alten Transitionformats noch nicht sicher verarbeiten. Ein bereits terminaler v1-Store ohne zuvor provisionierte Recovery- Autorität ist ebenfalls nicht nachträglich heilbar. Nicht durch Löschen oder Neuanlegen desselben Stores umgehen. ## Exakte Kandidaten signieren und sammeln Zusätzliche `release-id --kind`: `rootset`, `recovery-rules`, `root-change`. Zusätzliche `release-sign --kind`: `root-change`, `root-change-review`, `root-change-test`. Bestehende Policy-/Release-Signierung bleibt unverändert. Lokale Regeln werden identifiziert, nicht durch ein fremdes Bundle autorisiert. ```sh mf release-id --kind rootset --file /review/next-rootset.json mf release-id --kind recovery-rules --file /trusted/recovery-rules.json mf release-sign --kind root-change --file /review/change-body.json --data /offline/root mf root-change-bundle --previous-rootset /review/old-roots.json --next-rootset /review/new-roots.json --previous-policy /review/old-policy.json --next-policy /review/new-policy.json --change /review/change-body.json --old-signature /review/old-root.json --new-signature /review/new-root.json --review /review/security-review.json --test /review/security-test.json ``` Das Beispiel zeigt Flags, kein garantiert ausreichendes Quorum. Mitzeichner- Bodies müssen identisch sein. Root-/Policydateien lassen sich je höchstens 16-mal, Reviews 64-mal, Tests 128-mal angeben; aggregiert höchstens 1 MiB. Duplikate/fremde Kandidatenreferenzen werden abgewiesen. Der Collector gibt kanonische Bytes ohne abschließenden Zeilenumbruch aus; er ersetzt keine Signatur-/Autoritätsprüfung. Normale Rotation (`mode=rotate`) benötigt stärkere **alte und neue** Rootquoren, die aktuellen alten Securityreviewer/-tests und die lokal beobachtete Frist. Neue Policy bindet exakt die nächste Sequenz und bisherige Policy-ID und hält alle lokalen Floors ein. Roots rotieren vorwärts; Targets/Genesisvertrauen werden nicht umgedeutet. Terminale Recovery (`mode=recover`) benötigt die **vorab provisionierte** Recoveryautorität und deren getrennte Reviewer sowie das stärkere neue Rootquorum. Statt `--old-signature` verwendet der Collector `--recovery-signature`. Ein abgelaufenes oder verlorenes altes Rootquorum wird nicht als Fallback benutzt. Body bindet die ausgewählte terminale Ursache und den genauen Terminalanker aus Status. Geänderte relevante Negativbefunde verlangen neuen Kandidaten/neue Frist. ```sh mf root-change-observe --trust /trusted/recoverable.json --state /trusted/release-state --bundle /review/change.bundle.json mf root-change-activate --trust /trusted/recoverable.json --state /trusted/release-state --bundle /review/change.bundle.json ``` Observe aktiviert nicht. Activate verwendet frische Generation-/Policy-CAS und erhält den Releasehead samt allen Negativbefunden. Später gelernte gültige Ablehnungen aktivierter Rootwechsel sperren wiederum dauerhaft. Eine Recovery behandelt exakt die angegebene Ursache; weitere ungelöste Ursachen halten die Quarantäne. Replay einer bereits behandelten alten Ablehnung belebt sie nicht wieder, und vorhandene Auflösungsbeziehungen werden nicht überschrieben. Artefakte werden anschließend ausdrücklich mit `release-v2-observe` bzw. `release-v2-verify` und denselben `--trust`, `--state`, `--bundle` und gegebenenfalls `--artifact` geprüft. Es wird nichts heruntergeladen, installiert oder ausgeführt. Echte Plattformtests, unabhängige Trust-Provisionierung und externer Audit bleiben Freigabegates; lokale synthetische Prüfschlüssel sind keine realen Founder-Roots.