verify-release

Verify Release (Veröffentlichung prüfen)

Verwende dies, wenn gefragt wird, ob eine OpenClaw-Veröffentlichung vollständig veröffentlicht, publiziert, beworben, rauchgetestet oder live-verifiziert ist. Dies ist ein Verifikations-Skill, kein Publikations-Skill; verwende $release-openclaw-maintainer, bevor du den Release-Status änderst.

Regeln

• Löse Kurzsuffixe wie .27 in die konkrete CalVer-Version aus dem aktuellen Datum/Kontext auf und gib dann die aufgelöste Version an.
• Löse zuerst den Track auf. Beide Tracks verwenden das gemeinsame GitHub-Release-Evidenz-Ledger. Der reguläre Beta/Stable-Track verwendet auch den Plattform-Graphen; Extended-Stable verwendet seinen kanonischen Branch, npm-Selector und Gateway-Oberflächen. Verlange nicht die nativen oder ClawHub-Artefakte eines Tracks vom anderen.
• Verifiziere Live-Zustand. Vertraue nicht dem lokalen Checkout-Status, Release-Notes oder alten Erinnerungen als aktuelle Wahrheit.
• Wenn der Checkout verschmutzt oder abweichend ist, verwende ihn nur für Skripte/Referenzen. Für Versionsmetadaten lade vom GitHub-Release/Tag herunter oder entpacke das Tag-Tarball unter /tmp.
• Gib niemals Geheimnisse aus.
• Halte die Ausgabe kurz: ja/nein, Evidenz-Aufzählungspunkte, Einschränkungen, Bereinigung.

Prüfungen für regulären Beta/Stable

Verwende diese Prüfungen nur für den regulären orchestrierten Release-Track.

1. GitHub-Release:
   • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
   • Bestätige, dass Stable-Releases nicht als Draft oder Prerelease markiert sind.
   • Bestätige, dass der Release-Body bei Erwartung Links zu npm-, CI-, Plugin-npm-, ClawHub- und Mac/Appcast-Evidenzen enthält.
   • Bestätige, dass erwartete Assets für Stable-Mac-Releases hochgeladen sind: zip, dmg, dSYM, Abhängigkeitsnachweis, unveränderliches Vollvalidierungs-Manifest, Postpublish-Evidenz und Stable-Main-Schließungsmanifest.
   • Lade jedes unveränderliche Evidenz-Asset und seinen .sha256-Begleiter herunter und überprüfe dann die Prüfsumme, bevor du dem Release-Eintrag vertraust.
2. Root npm:
   • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
   • latest muss für Stable <VERSION> entsprechen.
   • Notiere Tarball, Integrität und Veröffentlichungszeit.
   • Bestätige, dass die Postpublish-Evidenz npmRegistrySignaturesVerified: true und npmProvenanceAttestationMatched: true festhält.
3. Plugin-Publish-Set:
   • Hole die genauen Tag-Metadaten von GitHub, nicht vom lokalen Checkout, wenn dieser verschmutzt ist: lade https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> nach /tmp/openclaw-v<VERSION>-src herunter.
   • Leite den vollständig erwarteten npm- und ClawHub-Paketsatz für den Release-Track mit den kanonischen Publikationsplanern/Sammler aus dem aufgezeichneten Release-Tooling-SHA unter Verwendung der genauen Tag-Paket-Metadaten ab. Zähle keine rohen Publish-Flags: openclaw.build.bundledDist === true verschiebt die externe Veröffentlichung explizit, auch wenn Publish-Flags gesetzt sind. Notiere verschobene Paketnamen und Gründe separat.
   • Gleiche erwartete Paketidentitäten, Versionen und Anzahlen über die ursprüngliche Veröffentlichung, zuvor veröffentlichte Versionen und ausgewählte Wiederherstellungsläufe unter Verwendung unveränderlicher Veröffentlichungspläne, Registry-Rücklesung und Workflow-Jobs ab. Eine ausgewählte Wiederherstellungs-Teilmenge darf den vollständig erwarteten Release-Satz nicht einschränken: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
   • Überprüfe für jedes erwartete npm-Plugin die geplante Version und den npm-Selector aus diesem unveränderlichen Veröffentlichungsplan. Ein reguläres Beta veröffentlicht auf beta; verlange nicht, dass es latest verschiebt. Überprüfe geplante Mirror-Tags separat.
4. ClawHub:
   • Überprüfe die Schlussfolgerung des Plugin-ClawHub-Release-Workflows und die Anzahl der Publish-Jobs.
   • Verwende OpenClaw selbst für Live-Registry-Nachweise: openclaw plugins search <bekanntes-plugin> --json.
   • Installiere ein offizielles Plugin in der exakt angeforderten Release-Version von ClawHub in einem isolierten HOME: openclaw plugins install clawhub:@openclaw/matrix@<VERSION>. Bevorzuge matrix, es sei denn, dieses Plugin ist nicht im erwarteten Satz enthalten. ClawHub-Versionen gehören in die Spezifikation; --pin wird nur für npm-Installationen unterstützt.
5. Release-Workflows:
   • Überprüfe Schlussfolgerungen für Release-Notes-Evidenz-Links: Vollständige Release-Validierung, OpenClaw-Release-Checks, OpenClaw-NPM-Release, Plugin-NPM-Release, Plugin-ClawHub-Release, Mac-Preflight/Validation/Publish, wenn stabile Mac-Assets erwartet werden.
   • Überprüfe für Stable, ob OpenClaw Stable Main Closeout erfolgreich war und sein Manifest den passenden Release-Tag, den aktuellen Rollback-Drill, das stabile Soaking und blockierende Leistungsevidenzen festhält.
   • Fasse nur relevante erfolgreiche/fehlgeschlagene Jobs zusammen; ignoriere routinemäßig übersprungene optionale Spuren, es sei denn, der Release-Body hat sie versprochen.

Prüfungen für Extended-Stable

Extended-Stable hat ein GitHub-Release mit gemeinsamer Release-Evidenz, aber keine nativen oder ClawHub-Artefakte. Verifiziere es zusammen mit dem Live-Tag, Workflow, Registry, Provenanz und Image-Status.

1. Identität: verlange endgültiges v<VERSION> bei Patch 33+, ohne Suffix, enthalten in extended-stable/YYYY.M.33. Nur ein aktiver Kandidat muss der Spitze entsprechen. Root und jedes veröffentlichbare offizielle Plugin müssen <VERSION> deklarieren. Verlange den Git-Tag und ein öffentliches, nicht-Prerelease-GitHub-Release, dessen Titel und kanonischer Body dem Tag entsprechen. Verlange isLatest=false, den Abhängigkeitsnachweis, das unveränderliche Full-Release-Validation-Manifest, die Postpublish-Evidenz und deren Prüfsummen. Verlange keine nativen oder ClawHub-Assets.
2. Workflow-Kette: finde den erfolgreichen Parent-Release-Lauf sowie seine Preflight-, kompletten Validierungs-, Plugin-npm- und Core-Publish-Childs. Verlange einen geschützten release-publish/*-Parent und einen kanonischen release-ci/*-Validierungsproduzenten mit verifizierter Workflow-SHA-Provenanz. Die Validierung muss rerun_group=all, release_profile=stable, blockierendes Soaking/Performance und den gespeicherten Versuch verwenden. Der Core-Publish muss alle drei Run-IDs referenzieren und sein Manifest, den Workflow-Ref und den Tarball-Digest an die Release-SHA binden.
3. Registry: verlange, dass exakte und extended-stable-Selektoren <VERSION> für Root, jeden Preflight-corePackageTarballs-Eintrag und jedes publishToNpm === true-offizielle Plugin, das vom Tag abgeleitet wurde, zurückgeben. Vergleiche den Plugin-Plan, Jobs und die vollständige Rücklesung; leite das Inventar niemals aus Diffs ab.
4. Provenanz: führe mit vertrauenswürdigem aktuellen Tooling aus: node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>. Verlange Signaturen, kanonische Branch-Provenanz und die Bindung des Publish/Preflight-Digests an die Release-SHA. Bewahre die Ausgabe und Workflow-URLs auf.
5. Docker: verifiziere exakte Default-, Slim-, Browser- und Architektur-Images sowie Attestationen in beiden Registries. Nur die drei extended-stable*-Aliase dürfen zu diesen Digests aufgelöst werden. Verlange den erfolgreichen Parent-Run OpenClaw Release Publish und dessen abgeschlossene Docker-Verifikation. Die normale Route schließt danach ab; ein explizit angeforderter Fast-Path kann zuerst GitHub aktivieren. Repariere Aliase durch aktuelles Main-Docker Channel Promotion für den exakten Tag, ohne Neubau.
6. Wiederherstellung: veröffentliche niemals erneut. Verwende promote_extended_stable im openclaw/releases-Dist-Tag-Workflow für den Root-Selektor (ein unsuffizierter finaler Patch 33+) und genehmigte, credential-isolierte Werkzeuge für andere, wiederhole dann die vollständige Rücklesung. Verlange kein ClawHub, native/mobile Apps, Website, private Dist-Tags oder reguläres latest. Verlange gemeinsame Release-Evidenz, aber verlange keine regulären nativen oder ClawHub-Assets.

Rauchtest veröffentlichter Pakete

Führe nach bestandenen trackspezifischen Veröffentlichungsprüfungen eine einmalige Installation/einen einmaligen Cache mit isoliertem OpenClaw-Zustand durch:

• npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
• Führe mindestens einen harmlosen Befehl aus, der die veröffentlichte CLI-Oberfläche berührt, z. B. plugins --help oder gateway --help.

Starte keinen zusätzlichen lokalen Gateway und führe keinen Ad-hoc-Live-Model-Turn als vorläufige Release-Prüfung durch. Verwende die kanonischen Release-Validierungs-Workflows und Veröffentlichungsevidenzen oben; dies entfernt keine ihrer erforderlichen Spuren. Führe zusätzliche manuelle Live-Checks nur durch, wenn explizit angefordert.

Meldepflichtige Einschränkungen

• Dist-Tag-Einschränkung: Stable latest ist Release-Wahrheit; wenn optionale beta-Mirrors immer noch auf eine Beta-Version zeigen, melde dies als Einschränkung, nicht als Stable-Release-Blocker, es sei denn, der Benutzer hat die Überprüfung der Beta-Promotion angefordert.
• Track-Einschränkung: Nenne den Track und die absichtlich nicht vorhandenen Oberflächen. Bezeichne fehlende reguläre Release-Artefakte nicht als Extended-Stable-Fehler.
• Abweichender Checkout-Einschränkung: Sage, wenn sich die lokale Source-SHA vom Release-Tag oder von Origin unterscheidet und welche Live-Quellen stattdessen verwendet wurden.