OpenClaw Release Maintainer

Was macht OpenClaw Release Maintainer?

Nur für Release-Operationen verwenden, nicht für normale Entwicklung oder beratende Änderungen. Lies docs/reference/RELEASING.md für die aktuelle Richtlinie. Lade $release-private, wenn verfügbar, bevor du private Credential Locators oder Host-Topologie auflöst; Credential-Operationen verwenden $one-password.

Rolle wählen

• Release-Besitzer (Standard): "Diese Version verwalten" besitzt eine Version von der Vorbereitung bis zur Verifikation, Retrospektive und zum Abschluss. Beginne mit dem Besitzer-Lebenszyklus, selbst für eine kurze Aufforderung.
• Release-Manager / Orchestrator: Koordiniert mehrere Release-Besitzer, entwirft deren Kickoff- oder Übergabe-Briefs und routet Hotfix-Möglichkeiten. Beginne mit Manager-Modus. Diese Rolle wird nicht zum zweiten Schreiber des Release-Branches oder Veröffentlichungsstatus eines Besitzers.

Die Skill besitzt den allgemeinen Prozess; die anfängliche Aufforderung trägt release-spezifische Absicht, Autorität und Zustand, kein kopiertes Runbook. Eine Übergabe setzt diese Absicht mit aktuellen Beweisen fort, anstatt eine weitere Version zu starten.

Operation wählen

Lies nur die Referenzen, die für die ausgewählte Phase benötigt werden:

• Reguläre Beta/Stable-Vorbereitung oder Veröffentlichung: reguläres Release, das Vorbereitung und phasenspezifische Nachweise routet. Wenn die Anfrage kein Stable/Full spezifiziert, standardmäßig Beta verwenden; Beta-Autorisierung autorisiert keine spätere Stable-Promotion.
• Backport-Erkennung und Portierung: Candidate-Inventar und Worker-Brief. Für Extended-Stable auch Backport-Vorbereitung lesen; SDK/Konfigurationsänderungen benötigen eine sichtbare Wartungsrisiko-Warnung und Maintainer-Entscheidung.
• Extended-Stable .33+ Gateway-Veröffentlichung: Extended-Stable-Veröffentlichung. Den gemeinsamen Publisher mit Extended-Stable-Eingaben verwenden; seine nicht-Latest GitHub Release trägt Nachweise ohne native App- oder ClawHub-Veröffentlichung.
• Validierungsauswahl oder fehlgeschlagener Nachweis: Validierung und Confidence, mit $release-openclaw-ci für Workflow-Ausführung und unveränderliche Manifests.
• Unterbrochene Veröffentlichung oder Registry-Promotion: Wiederherstellung der Veröffentlichung.
• Native Assets: Plattform-Veröffentlichung, mit $release-openclaw-mac für macOS-Operationen.
• Stable Postpublish-Synchronisation und der Exact-SHA-Deployment-Handoff: Main-Abschluss.
• Release-Retrospektive und gemeinsames Issue-Ledger (jeder Track und jeder Übergabe-Snapshot): Retrospektive.
• Release-Notizen: $openclaw-changelog-update, inklusive seiner separaten genehmigten Post-Release-Docs-Mirror-Route. Die anfängliche Generierung des Releases behält sein bestehendes Format; die Docs-Veröffentlichung läuft während des Releases nicht automatisch. Angeforderte Ankündigungen: $release-openclaw-announcement für Discord, $release-tweets für X. Ankündigungen blockieren niemals die Veröffentlichung und erfordern eine explizite Autorisierung zum Posten.
• Veröffentlichung verifizieren: $verify-release. GHSA-Operationen: $openclaw-ghsa-maintainer nur mit expliziter Security-Workflow-Autorisierung.

Hotfix-Ledger-Management

Bevorzuge das gemeinsame Hotfix-Ledger für Backport-Erkennung, Auswahl und Ergebnisse, einschließlich Tideclaw-eigener Releases. Wiederverwende Kandidaten, füge Erkenntnisse aus Main/Sibling-Releases hinzu und aktualisiere die Bewertungen jedes Releases. Falls kein Zugriff möglich ist, behalte lokale Beweise und synchronisiere später. Dies ist empfohlene Buchhaltung, kein weiteres Release-Gate.

Gemeinsame Release-Grenzen

FRV muss erfolgreich unter den festgelegten P's mit der eingecheckten Release-Tooling-Richtlinie enden. Nur genau fehlgeschlagene Live-Provider- oder Telegram-Leaves können ohne Überspringen von Tests oder Ändern von C/Q ausgenommen werden. Alle anderen erforderlichen Lanes müssen erfolgreich sein: Windows- und macOS-Node- und andere normale CI-Jobs, Install-Smoke, Survivor-Lanes, update-first-hop-compat*, Pack/npm-Qualifikation, Paketintegrität und Linux/Windows/macOS-Gateway-Checks, einschließlich Windows-Packaged-Install/Upgrade-Checks in Release Checks. Ein abgebrochener Lauf blockiert ebenfalls. Behalte erste Fehler bei und klassifiziere jeden als untenstehend, bevor die Wiederherstellung beginnt. Stable-Veröffentlichung erfordert Stable/Full-Nachweise, Soak und blockierende Performance. Beta-Profil-Nachweise können keine Stable-Veröffentlichung autorisieren. Keine dieser harten Gates, Soaks oder Performance können ausgenommen werden. Alle neun Gateway-Install/Upgrade-Kombinationen über Linux, Windows und macOS sind für die All-Group-Qualifikation erforderlich. Bewahre Identität, Herkunft, vollständige Nachweise und bestehende Veröffentlichungsgenehmigungen.

Jeder fehlgeschlagene Test erhält eine explizite Lead-Entscheidung, echter Release-Blocker oder Flake, aufgezeichnet in der Übergabe mit seinem Nachweis: derselbe SHA, der anderswo oder beim erneuten Lauf bestanden hat, kein Bezug zum Release-Delta, eine Runner- oder Infra-Signatur, eine Vorgeschichte desselben Falles, der flaked, oder ein bereits bestehender Produktfehler, der keine Regression ist (z. B. der "Assign to…"-Bug von 2026.9.6). Ein echter Blocker ist eine Regression in ausgelieferten Bytes oder Verhalten, oder ein Update/Install/Publish-Defekt; behebe ihn auf dem Release-Branch. Wiederhole einen Flake auf demselben Release-SHA mit maximal zwei aufgezeichneten Wiederholungen als Standard und erstelle ein Fix-in-Parallel-Issue oder PR auf main mit dem Nachweis. Nie für einen Flake neu schneiden. Ein absichtlicher Tooling-Code-Waiver erfordert FRV-Validierung unter dem neuen festgelegten P, kein Publisher-Override. Ein nicht ausgenommener Flake, der rot bleibt, blockiert die Veröffentlichung. Main-only-Fehler und Infrastrukturfehler (Runner-Ausfälle, GitHub-Geisterjobs, Hosted-Runner-Auslagerung) zählen als Flakes für das Release.

Abhängigkeitsadvisories verzögern niemals ein Release. Ein neu veröffentlichtes Advisory ist niemals ein Grund, neu zu schneiden, Tooling zu ändern oder die Validierung zu wiederholen. Zeichne es in den Release-Nachweisen und der Übergabe auf, dann erstelle oder reihe den Dependency-Bump auf main als normales Follow-up nach der Veröffentlichung ein. Nur ein bekannter Malware-Fund stoppt die Veröffentlichung. Release-Abhängigkeitsnachweise und vom Release ausgelöste CI erzwingen dies.

Die CI-Gesundheit von Main blockiert niemals ein Release. Validierung und Veröffentlichung laufen vom Release-Branch plus festgelegtem Tooling, daher ist ein roter main kein Grund zu warten, neu zu schneiden oder zu pausieren. Wenn das Release einen Release-Tooling-Fix auf main benötigt (Tooling-SHAs müssen vertrauenswürdige main-Commits sein), main-Fehler, die der Fix nicht verursacht, dürfen das Landen nicht aufhalten: beweise auf einem sauberen main-Checkout, dass der Fehler dort bereits existiert, zeichne ihn im PR-Body auf und merge. Während eines aktiven Releases ist ein Admin-Merge für einen Release-Tooling-PR genau in dieser Situation erlaubt. Roter main wird trotzdem repariert, parallel von einer separaten Lane, niemals auf dem kritischen Pfad des Releases.

Folge der FRV-Wall-Time-Schleife: starte die Remote-Validierung umgehend, repariere Fehler während die Diagnosen laufen und minimiere Ausfallzeiten zwischen Zyklen. Füge jede bekannte Nicht-Flake-Reparatur ein, die den nächsten Lauf betrifft, anstatt wissentlich Fehler voranzutragen; überlappe nützliche lokale Checks mit Remote-Validierung. Dies leitet die Planung, keine neuen Gates.

Die Betriebsziele liegen bei ungefähr 20 Minuten, um die Validierung abzuschließen und die Veröffentlichung innerhalb einer Stunde durchzuführen, keine gemessenen Garantien. Source-only Children starten zusammen mit den Artefakt-Produzenten; Candidate-Consumer starten, sobald der Candidate bereit ist. Unabhängig abgeschlossene grüne Children können für dasselbe exakte Ziel und dieselben Eingaben wiederverwendet werden, selbst wenn ihr Parent fehlgeschlagen ist, abgebrochen wurde oder noch aktiv ist; verifiziere ihre ursprüngliche zugelassene Qualifikationsidentität (oder historischen Trusted-Main-Workflow-SHA) und den aktuellen Versuch. Das abgeschlossene Manifest liefert den SDK-Beweis-Digest und npm-Veröffentlichungsentscheidungen; es bestätigt niemals SDK-API-Änderungen, also gib plugin_sdk_api_acknowledgement immer dann an, wenn der SDK-Bericht Änderungen enthält. Der Publisher akzeptiert nur erfolgreiches FRV und kann keinen Waiver erteilen. Explizite Publisher-Eingaben wählen den Veröffentlichungsbereich aus; der Candidate-Helfer validiert trotzdem seine explizite SDK-Bestätigung, wenn nötig.

Verwende die Autoritätsvorgaben des Besitzer-Lebenszyklus für Release-Management-Anfragen: Beta enthält validierte Veröffentlichung, sofern nicht zurückgehalten; Stable und Extended-Stable erfordern Veröffentlichungsgenehmigung. Eine explizite Prepare-Only-Anfrage autorisiert niemals die Veröffentlichung. Eine explizite Anweisung zu veröffentlichen oder eine benannte Version abzuschließen, wird durch ihre validierte Veröffentlichung und Verifikation getragen; frage nicht erneut, es sei denn, Identität, Kanal, Bereich oder materielles Risiko ändern sich. Löse auf und zeichne die Version auf, bevor du sie änderst; nicht spezifizierte Versionen folgen der Genehmigungsregel des Lebenszyklus. Ship-Authorität für normalen Code ist keine Release-Autorität.

Die explizite Genehmigung eines Operators, alles Nötige zu tun, um eine benannte Version vorzubereiten, ist eine laufende Autorität für die erforderlichen Vorbereitungsentscheidungen und Reparaturen. Trage sie durch Candidate- und Tooling-Fixes, Upgrade/Migration-Design, überprüfte Test- oder Security-Inventory-Angleichungen, isolierte Nachweise, Commits, Pushes und Validierungswiederherstellung. Zeichne die Entscheidung, ihre Nachweise und den ausgewählten Support-Vertrag auf; frage nicht erneut, nur weil eine bereits genehmigte Arbeitsklasse einen Implementierungs- oder Verifizierungsschritt erreicht. Setze die unabhängige Arbeit fort, während ein Blocker gelöst wird. Diese Autorität erlaubt nicht, Defekte zu verstecken, ein Gate zu senken, um Erfolg zu erzeugen, zerstörerische Änderungen am Zustand des Operators, nicht zusammenhängende Arbeit oder Veröffentlichung. Eine Prepare-Only-Anfrage erfordert trotzdem eine separate Veröffentlichungsanweisung, bevor Artefakte oder eine Bridge-Version herausgegeben werden.

Führe einen kompakten Zustandsdatensatz mit der Übergabe-Vorlage: effektives Ziel, Version/Tag/Branch, Cut/Code/Release-SHAs, C/Q/P-Identitäten, aktiver Parent-Lauf und -Versuch, erfolgreiche Child-Artefakte, genehmigte Änderungen, Phase und nächste Aktion. Neueste Operator-Steuerung ersetzt überholten Bereich. Abgeschlossene Nachweise bleiben vollständig, bis eine benannte Änderung sie ungültig macht.

Bereite für reguläre Releases die vollständigen Notizen vor dem Einfrieren des Code SHA vor, wenn möglich. Wenn diese Notizen endgültig sind, sind Code SHA und Release SHA derselbe Commit: eine erfolgreiche frische vollständige Qualifikation kann beide Rollen und ihre exakten Veröffentlichungsbytes liefern. Erstelle keinen weiteren Commit oder Lauf nur, um die Labels zu trennen. Wenn sich Notizen nach der Qualifikation ändern, darf ein Nachkomme, dessen vollständiges Delta CHANGELOG/<version>.md (exakte Beta-Version oder Stable-Basis) und nur diesen Eintrag, seinen passenden Datensatz und den Root-Index enthält, split-changelog-release-v1 verwenden, um Produktnachweise wiederzuverwenden, während neue Veröffentlichungsbytes qualifiziert werden. Jedes andere Quell-Delta, Umbenennung oder Löschung kehrt zur Code-SHA-Schleife zurück. Historische Root-only-Belege behalten changelog-only-release-v1. Neue Testqualifikation friert Q=C ein: der Test-Workflow-Abschluss des Candidates gehört zum Candidate. Behalte unabhängig vertrauenswürdiges P (Admission, Aggregat-Entscheidung, Verifier und Publisher) getrennt. Eine Q-Harness-Reparatur erfordert ein neues C/Q und neu gebundene Nachweise; P-only- oder Infrastruktur-Reparaturen können den Candidate bewahren. Fehlende Qualifikationsverträge benötigen einen bewussten Backport, niemals Future-Main-Fallback.

Sobald ein Candidate geschnitten ist, ist seine Basis die Entscheidung des Operators. Nie neu schneiden (den Candidate auf neuerem main basieren), es sei denn, Peter bittet explizit darum in diesem Release. Ohne Aufforderung cherry-picke bereits auf main gemergte Commits auf den Release-Branch nur, um einen bestätigten Release-Blocker zu beheben: eine erforderliche Lane, die deterministisch auf dem eingefrorenen Candidate fehlschlägt, oder ein Update/Install/Publish-Bytes-Defekt. Benenne jeden Cherry-Pick im Übergabedatensatz. Nicht erlaubt: opportunistische Backports, Feature-Reverts oder eine neue Basis, die aufgenommen wird, um einen Fix "mitzunehmen", der sich mit einer kleinen Konfliktlösung sauber cherry-picken lässt. Explizit vom Operator genehmigte Ergänzungen folgen dem Besitzer-Aufnahmeverfahren: zeichne den geänderten Bereich auf und requalifiziere den neuen Candidate, niemals stille Wiederverwendung ungültiger Nachweise. Eine Benachrichtigung des Managers über eine Gelegenheit ist nicht diese Genehmigung.

Während eines Releases vorgenommene Verbesserungen des Release-Prozesses landen auf beiden Branches. Workflow-, Release-Script-, Release-Test-, RELEASING.md- und Release-Skill-Änderungen werden zuerst auf main gemergt, dann auf release/YYYY.M.PATCH für den nächsten Candidate oder Patch cherry-gepickt (-x). Eine für dieses Release benötigte Qualifikationsreparatur muss landen, bevor ein neues C/Q eingefroren wird; niemals die Harness für einen bereits qualifizierten Candidate still austauschen. Wo main-only CI-Infrastruktur auf dem Branch fehlt, behalte die Ausdrucksform des Branches und portiere nur die Logik. Produktcode auf dem Release-Branch bleibt gemäß der obigen Regel Blocker-only.

Löse jeden für das Release geöffneten Reparatur-PR vor dem endgültigen Bericht. Der unten beschriebene Retrospektive-PR ist das erforderliche offene Abschluss-Deliverable, keine ungelöste Reparatur. Liste jeden PR auf, der während des Releases erstellt wurde (gh pr list --author @me --state open plus jeder PR, der an…

…[für die Übersetzung gekürzt]