# MeshForge — experimentelle lokale Policy-Wechsel Ein Policy-Wechsel ändert die delegierten Release-/Review-/Testrechte und Regeln eines **bereits separat vertrauenswürdig konfigurierten** Verifiers. Er installiert keine Software, veröffentlicht nichts und erzeugt keine Founder-Autorität. Root-Schlüssel und lokale Trust-Anforderungen bleiben unverändert. Rootrotation, Emergency-Bypass und automatische Update-Ausführung sind nicht implementiert. ## Ausdrückliche Provisionierung vor der Initialisierung Ohne das optionale letzte Feld `transition_rules` in der lokalen `trust.json` bleiben sämtliche Wechsel gesperrt. Alte Konfigurationen, Fingerprints und Checkpointbytes behalten ihre Bedeutung. Das Feld muss bereits bei `release-trust-init` vorhanden sein. Ein nachträgliches Hinzufügen, Ändern oder Entfernen beim Öffnen wird abgewiesen; es gibt **keine implizite Migration** und keinen sicheren Ersatz durch Löschen oder Neuanlegen eines vorhandenen State. `transition_rules` enthält diese typisierten Felder in dieser Reihenfolge und wird in der vorhandenen lokalen `trust.json` als letztes Feld serialisiert: | Feld | Bedeutung | |---|---| | `root_threshold` | Strikt mehr Root-Signaturen als die gewöhnliche lokale `root_threshold`, höchstens vorhandene gepinnte Roots | | `approvals` | Mindestens zwei aktuelle Security-Reviewer | | `groups` | Mindestens zwei durch die bisherige Policy deklarierte Reviewer-Gruppen | | `review_seconds` | Lokale Mindestwartefrist für den exakten Transition-Kandidaten | | `test_signers` | Mindestzahl verschiedener autorisierter Test-Unterzeichner | | `required_tests` | Sortierte Testarten; `security` muss enthalten sein | | `policy_floors` | Drei vollständige `Rule`-Objekte, geordnet nach `documentation`, `normal`, `security`; unveränderliche Mindestregeln für initiale und spätere Policies | Die gewöhnliche Rootschwelle darf damit nicht bereits alle vorhandenen Roots verbrauchen. Die stärkere Transition-Schwelle muss strikt höher als `root_threshold` und höchstens so groß wie die lokal gepinnte Rootmenge sein. Dieselben Root-Schlüssel müssen auch die alten und neuen Policies mit der gewöhnlichen Rootschwelle signieren. Keine neuen Roots werden aus einem Bundle übernommen. Die effektiven Review-/Gruppen-/Testquoren und Wartezeiten eines Wechsels sind jeweils mindestens die größeren Werte aus lokalen Transition-Regeln und der **bisherigen** Security-Regel; benötigte Testarten werden vereinigt. Die Governance-Spezifikation nennt Startvorschläge für reale Fristen. Null-Fristen in automatisierten Fixtures sind keine Empfehlung für produktive Trust-Konfigurationen. ## Kandidaten vorbereiten Eine Transition bindet `previous_policy_id`, `next_policy_id`, die exakt nächste Policy-Sequenz und `rules_id` an Ausgabe-/Ablaufzeit. `rules_id` ist der domainseparierte Hash des exakten lokalen `transition_rules`-Objekts. Die neue Policy referenziert die bisherige Policy-ID in `previous`. Phasen dürfen nur vorwärts von `founder` über `maintainer` nach `distributed` gehen oder gleich bleiben. Keine Phase verleiht allein reale Personen- oder Firmenidentität. ```sh mf release-id --kind policy --file /reviews/previous-policy-body.json mf release-id --kind policy --file /reviews/next-policy-body.json mf release-id --kind transition-rules --file /trusted/transition-rules.json mf release-id --kind transition --file /reviews/transition-body.json mf release-sign --kind policy --file /reviews/next-policy-body.json --data /protected/release-root mf release-sign --kind transition --file /reviews/transition-body.json --data /protected/release-root mf release-sign --kind transition-review --file /reviews/transition-review-body.json --data /protected/security-reviewer mf release-sign --kind transition-test --file /reviews/transition-test-body.json --data /protected/security-tester ``` Weitere unabhängige Unterzeichner verwenden jeweils ihren eigenen vorhandenen Key-Ordner und denselben Body. Signaturkontexte für Transition, Transition-Review und Transition-Test sind von gewöhnlichen Release-Belegen getrennt. Neue Delegierte können sich nicht selbst in die Autorität wählen: Gezählt werden nur zur Aktivierung noch gültige Security-Review-/Testrechte der bisherigen Policy. Der lokale Collector baut ausschließlich öffentliche Dateien zusammen: ```sh mf policy-transition-bundle --previous-policy /reviews/previous-policy.json --next-policy /reviews/next-policy.json --transition /reviews/root-1-transition.json --transition /reviews/root-2-transition.json --review /reviews/reviewer-1.json --review /reviews/reviewer-2.json --test /reviews/security-test.json --test /reviews/regression-test.json ``` Dieses Beispiel illustriert Flags, nicht ein garantiert ausreichendes Quorum. Je höchstens 16 alte/neue Policy- und Transitiondateien, 64 Reviewdateien und 128 Testdateien; aggregiert höchstens 1 MiB Eingabebytes. Mitzeichner-Bodies müssen identisch sein. Duplikate und fremde Policy-/Kandidatenverweise werden abgewiesen. Die Ausgabe sind kanonische Bundle-Bytes ohne abschließenden Zeilenumbruch. Zusammenstellen authentifiziert keine Autorität; dafür folgt die separate Prüfung. ## Beobachten und lokal aktivieren ```sh mf policy-transition-observe --trust /trusted/trust.json --state /trusted/release-state --bundle /reviews/transition.bundle.json mf policy-transition-activate --trust /trusted/trust.json --state /trusted/release-state --bundle /reviews/transition.bundle.json ``` `transition_observed_not_activated` startet den lokalen Reviewzeitpunkt, ändert aber nicht die aktive Policy. Selbst zum Beobachten sind die stärkeren Root-Signaturen erforderlich; Reviewer/Testbelege dürfen noch unvollständig sein. Bei einem bislang ungebundenen neuen Checkpoint darf nur eine vollständig authentifizierte Ausgangspolicy mit Sequenz 1 gepinnt werden, keine übersprungene Historie. Die Frist beginnt frühestens beim ersten lokalen Beobachten genau dieses Kandidaten. Geänderte Bytes bedeuten eine neue ID und ein neues Fenster. Erst `local_policy_transition_activated_no_release_installed` bestätigt die lokale Aktivierung. Die aktuelle Policygeneration wird unter Prozesslock erneut geprüft. Gewöhnliche Releases dürfen während des Reviewfensters fortschreiten; ihr aktueller Head und ihre Sequenz bleiben erhalten. Alte positive Reviewfenster werden verworfen, bekannte negative Release-/Transition-Belege und Quarantänen bleiben. Releases unter der abgelösten Policy werden anschließend abgewiesen. Ein neuer Release muss weiterhin vom zuletzt akzeptierten Release abstammen. Der Transition-Body bindet die alten/neuen Policy-IDs, exakt nächste Sequenz, `rules_id` sowie Ausgabe-/Ablaufzeit. Die neue Policy muss die alte als Vorgänger nennen. `founder` → `maintainer` → `distributed` darf gleich bleiben oder nur vorwärts gehen. Transition, Policies, Reviews und Tests müssen zum Produkt/Kanal und zu den jeweiligen Gültigkeitsfenstern passen; die Transition läuft spätestens nach 90 Tagen ab und darf nicht länger als eine der beiden Policies gelten. Nur gültige `review`-/`test`-Delegationen mit Security-Risiko aus der alten Policy zählen. Review- und Testbelege müssen den exakten Transition-Kandidaten binden. Aktivierung verlangt genügend eindeutige Reviewer, Gruppen und Testsigner sowie alle vereinigten benötigten Testarten; ein Reject oder fehlgeschlagener Test verhindert sie. Ausgaben enthalten `weakenings` für niedrigere neue Regelwerte/wegfallende Testanforderungen und `delegation_changes` für geänderte Rechte. Änderungen unter die unveränderlichen lokalen `policy_floors` werden abgewiesen. Gruppenbezeichnungen belegen kryptografisch nur die Aussage der Policy, keine unabhängig nachgewiesene organisatorische Trennung. ## Ablehnungen und verbleibende Grenzen Gültig autorisierte Ablehnungen oder fehlgeschlagene Testbelege können nicht durch späteres Weglassen aus demselben Kandidaten verschwinden. Vollständige Authentifizierung erfolgt vor einer State-Änderung; gefälschte negative Belege dürfen keinen Kandidaten sperren. Überfüllte begrenzte Negativspeicher führen zu konservativer Quarantäne statt zum Vergessen bekannter Ablehnungen. Nach Aktivierung später gelernte gültige Ablehnung der zuletzt aktivierten Transition ist terminal: Alle weiteren Releases und Transitions dieser Trustinstanz werden dauerhaft abgewiesen. **Ein sicherer Recoverypfad für diesen Zustand fehlt noch.** Es gibt keinen automatischen Rollback, keine manuelle Reset-Empfehlung und keinen Emergency-Override. Davon zu unterscheiden ist eine Overflow-Quarantäne bis zum Ablauf des überlaufenden Kandidaten. Der Transition-Speicher hält höchstens 16 lebende Kandidaten. Eine weltweite Vollständigkeit aller Reviews oder eine nachträgliche Prüfung beliebig alter, bereits abgelöster Governance-Historie wird nicht behauptet. Privilegierter vollständiger Dateisystem-Rollback und unzuverlässige lokale Uhr bleiben Grenzen. Reale Founder-Vertrauensanker, unabhängig geprüfte Gruppen, Windows-Hardwaretests und externe Sicherheitsabnahme fehlen weiterhin. [Release-CLI](RELEASE_CLI.md) · [Protokoll](../protocol/RELEASE-EXPERIMENTAL.md)