OpenClaw-Release-Ankündigung

OpenClaw Release-Ankündigung

Verwende mit release-openclaw-maintainer, nachdem ein Release live ist. Verwende mit $discord-user-post, wenn die Ankündigung tatsächlich als eingeloggter Benutzer auf Discord gepostet wird.

Evidenz zuerst

Bevor du Schwerpunkte entwirfst, lies echte Release-Evidenzen:

1. GitHub-Release-Body und unveränderlicher Tag; für Extended-Stable bestätige zusätzlich den npm/Container-only-Scope und die Nicht-Latest-Klassifizierung.
2. Die CHANGELOG/<version>.md der veröffentlichten Basisversion und die Beitragsaufzeichnung, aufgelöst mit node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] (füge --record für die Buchhaltung hinzu). Der gemeinsame Resolver liest historische monolithische Tags; die aktuelle CHANGELOG.md ist ein Index. Nach der genehmigten Dokumentenveröffentlichung lies den vollständigen Docs-Mirror und die eingefrorene Aufzeichnung, anstatt den kompakten GitHub-Body als vollständige Notizen zu behandeln.
3. Commits seit der vorherigen ausgelieferten Version oder der vom Operator angegebenen Basis.
4. Registry-/Paketmetadaten für die exakte Version und den aktuellen dist-tag.
5. Validierungsstatus, der für das Vertrauen der Benutzer relevant ist.

Behaupte keine vollständige Changelog-Prüfung, es sei denn, du hast sie durchgeführt. Wenn du nur die generierten Release-Notes oder einen ausgewählten Changelog-Abschnitt gelesen hast, sage das und prüfe entweder ordnungsgemäß oder entwirf mit dieser Einschränkung.

Priorisiere für Beta-Schwerpunkte benutzersichtbare Änderungen gegenüber internen Test- oder CI-Mechaniken:

• Installations-/Aktualisierungspfade
• Betriebssystem-/plattformspezifisches Verhalten
• Gateway-Start/Neustart, Konfiguration und Laufzeitverhalten
• Provider/Modell/Runtime-Routing
• Plugin-Laden und lokale Plugin-Entwicklung
• Kanäle und Medienpfade
• Sicherheits-/Datenverlust-/Benutzerauswirkungs-Fixes

Lasse späte Release-Branch-Fixes nicht automatisch die Ankündigung dominieren. Wenn die Version eine große Differenz zur vorherigen ausgelieferten Version enthält, ordne die Schwerpunkte nach der gesamten Release-Differenz und der erwarteten Benutzerauswirkung; erwähne späte Fixes in ihrer natürlichen Kategorie.

Erforderlicher Text

Jede Beta-Ankündigung muss den Beta-Status explizit machen und Folgendes enthalten:

• exakte Version, z.B. OpenClaw 2026.5.25-beta.1
• Ein-Satz-Risikoeinordnung: Beta, nützlich zum Testen, nicht für Stable-Promotion
• fokussierte Testbereiche, die aus Evidenzen abgeleitet sind, nicht aus Vermutungen
• Update-Befehl, der oben nahe der Spitze beworben wird:

  openclaw update --channel beta --yes
  openclaw --version
  

• Frischinstallationspfad: Installieren von https://openclaw.ai
• GitHub-Release-Link
• präzise Validierungsnotiz, ohne CI zur Schlagzeile zu machen

Schlage keine npm-Install-Befehle in Beta-Ankündigungen vor, es sei denn, der Operator bittet explizit um npm-spezifischen Text oder Fehlerbehebungstext. Es ist in Ordnung, Registry-Metadaten als Evidenz zu verwenden; mache daraus keine öffentlichen Installationsanleitungen.

Verwende für Stable-Ankündigungen die Stable-Kanal-Formulierung:

openclaw update --channel stable --yes
openclaw --version

Frischinstallationen verweisen weiterhin auf https://openclaw.ai.

Für Extended-Stable nenne die exakte Version und den nachfolgenden Monat. Erwähne nur beobachtbare Backports und verwende:

openclaw update --channel extended-stable
openclaw --version

Füge kein --yes hinzu: Benutzer, die von neuerem regulärem Stable wechseln, müssen die Downgrade-Warnung sehen, weil ältere Versionen möglicherweise neuere Konfigurationen nicht verstehen. Verlinke das GitHub-Release, aber übernimm keine regulären Stable-macOS-, Windows-, ClawHub-, latest- oder Website-Ansprüche.

Stil

• Discord-Markdown, keine Tabellen.
• Übersichtlich halten: kurze Einleitung, Aufzählungspunkte, Befehle, Links.
• Führe mit dem, was Benutzer fühlen oder testen können, nicht mit Beweisinfrastruktur.
• Erwähne Validierung erst nach Installations-/Update-Anweisungen.
• Sei spezifisch, wo Feedback nützlich ist.
• Erwähne keine privaten lokalen Beweispfade in öffentlichen Ankündigungen.
• Übertreibe unverifizierte Plattformen, Kanäle oder Provider-Verhalten nicht.

Posten

Wenn du gebeten wirst zu posten, verwende $discord-user-post, um die eingeloggte Discord-Desktop-App als Benutzer zu bedienen. Löse den genauen Server/Kanal auf und überprüfe ihn sichtbar, überprüfe den endgültigen Body und bitte um Aktion-Zeit-Bestätigung, bevor du ihn eingibst oder sendest. Verwende niemals OpenClaw-Kanal-Sends, Bots, Webhooks, Relays oder Tokens.