AGENT SKILL

verify-release

Verify regular or extended-stable OpenClaw releases against the exact publication surfaces, workflow identities, package provenance, and published CLI smoke tests expected for that release track.

License 许可
MIT
所属仓库
openclaw/openclaw
最近更新
2026-11-13
Stars
★ 39w
Forks
8.3w

01 前言 Front Matter

name
verify-release
description
Verify regular or extended-stable OpenClaw releases against the exact publication surfaces, workflow identities, package provenance, and published CLI smoke tests expected for that release track.

03 SKILL.md 正文

Verify Release

Use this when asked whether an OpenClaw release is fully released, published, promoted, smoke-tested, or live-verified. This is a verification skill, not a publish skill; use $release-openclaw-maintainer before changing release state.

Rules

  • Resolve short suffixes like .27 to the concrete CalVer version from the current date/context, then say the resolved version.
  • Resolve the track first. Both tracks use the shared GitHub Release evidence ledger. Regular beta/stable also uses the platform graph; extended-stable uses its canonical branch, npm selector, and Gateway surfaces. Do not require one track's native or ClawHub artifacts from the other.
  • Verify live state. Do not trust local checkout state, release notes, or old memory as current truth.
  • If the checkout is dirty or divergent, use it only for scripts/reference. For version metadata, fetch from GitHub release/tag or unpack the tag tarball under /tmp.
  • Verify selected npm plugins published successfully before core npm.
  • Report ClawHub separately from core release readiness. Its pending or failed publication/verification never blocks core, GitHub finalization, main closeout, or the retrospective PR. Keep its exact run/attempt, owner, and next action visible; do not call ClawHub complete without public-byte proof.
  • Never print secrets.
  • Keep the final terse: yes/no, evidence bullets, caveats, cleanup.

Regular beta/stable checks

Use these checks only for the regular orchestrated release track.

  1. GitHub release:
    • gh release view v<VERSION> --repo openclaw/openclaw --json tagName,name,publishedAt,isDraft,isPrerelease,targetCommitish,url,body,assets
    • Confirm stable releases are not draft/prerelease.
    • Confirm release body has npm, CI, plugin npm, ClawHub, mac/appcast evidence links when expected.
    • Confirm assets expected for stable mac releases are uploaded: zip, dmg, dSYM, dependency evidence, immutable full-validation manifest, postpublish evidence, and stable-main closeout manifest.
    • Download each immutable evidence asset and its .sha256 companion, then verify the checksum before trusting the release record.
  2. Root npm:
    • npm view openclaw@<VERSION> version dist-tags.latest dist.tarball dist.integrity time.<VERSION> --json
    • latest must equal <VERSION> for stable.
    • Record tarball, integrity, publish time.
    • Confirm the release postpublish evidence records npmRegistrySignaturesVerified: true and npmProvenanceAttestationMatched: true.
  3. Plugin publish set:
    • Get exact tag metadata from GitHub, not the local checkout when dirty: download https://api.github.com/repos/openclaw/openclaw/tarball/v<VERSION> into /tmp/openclaw-v<VERSION>-src.
    • Derive the full expected npm and ClawHub package sets for the release track with the canonical publication planners/collector from the recorded release Tooling SHA, using the exact tag's package metadata. Do not count raw publish flags: openclaw.build.bundledDist === true explicitly defers external publication even when publish flags are set. Record deferred package names and reasons separately.
    • Reconcile expected package identities, versions, and counts across original publication, previously published versions, and selected recovery runs using immutable publication plans, registry readback, and workflow jobs. A selected recovery subset must not narrow the full expected release set: gh api repos/openclaw/openclaw/actions/runs/<RUN>/jobs --paginate.
    • For each expected npm plugin, verify the planned version and npm selector from that immutable publication plan. A regular beta publishes to beta; do not require it to move latest. Verify any planned mirror tags separately.
  4. ClawHub (independent status, not a core or closeout gate):
    • Check the Plugin ClawHub Release workflow conclusion and publish job count. If pending or failed, record that state and its follow-up separately; continue core verification and closeout without waiting.
    • Use OpenClaw itself for live registry proof: openclaw plugins search <known-plugin> --json.
    • Install one official plugin at the exact requested release version from ClawHub in an isolated HOME: openclaw plugins install clawhub:@openclaw/matrix@<VERSION>. Prefer matrix unless that plugin is not in the expected set. ClawHub versions belong in the spec; --pin is only supported for npm installs.
  5. Release workflows:
    • Verify conclusions for release notes evidence links: Full Release Validation, OpenClaw Release Checks, OpenClaw NPM Release, Plugin NPM Release, mac preflight/validation/publish when stable mac assets are expected. Report Plugin ClawHub Release independently, even when its result is still pending or failed.
    • For stable, verify OpenClaw Stable Main Closeout succeeded and its manifest records the matching release tag, current rollback drill, stable soak, and blocking performance evidence.
    • Summarize only relevant successful/failed jobs; ignore routine skipped optional lanes unless the release body promised them.
  6. Container registries:
    • Resolve VERCEL_VCR_IMAGE from the repository variable and use the trusted tooling checkout to run scripts/container-registry-readback.mjs with the exact version, both ghcr.io/openclaw/openclaw and docker.io/openclaw/openclaw, and the Vercel image. Pass --include-browser when the release Dockerfile includes that variant.
    • Require every default, slim, browser, amd64, and arm64 immutable tag in all three registries, matching cross-registry platform descriptors, and every policy-owned moving alias at the immutable digest and descriptor set. Beta intentionally has zero moving aliases; do not require a beta container alias.
    • Use existing Docker credential state for private Vercel reads. If it is unavailable, report Vercel live readback as a gap rather than treating the workflow conclusion as equivalent proof.

Extended-stable checks

Extended-stable has a GitHub Release with shared release evidence but no native or ClawHub artifacts. Verify it alongside the live tag, workflow, registry, provenance, and image state.

  1. Identity: require final v<VERSION> at patch 33+, with no suffix, contained in extended-stable/YYYY.M.33. Only an active candidate must equal the tip. Root and every publishable official plugin must declare <VERSION>. Require the Git tag and a public, non-prerelease GitHub Release whose title and canonical body match the tag. Require isLatest=false, the dependency evidence, immutable Full Release Validation manifest, postpublish evidence, and their checksums. Require no native or ClawHub assets.
  2. Workflow chain: find the successful parent release run plus its preflight, complete validation, plugin npm, and core publish children. Require a protected release-publish/* parent and canonical release-ci/* validation producer with verified workflow SHA provenance. Validation must use rerun_group=all, release_profile=stable, blocking soak/performance, and the saved attempt. Core publish must reference all three run IDs and bind its manifest, workflow ref, and tarball digest to the release SHA.
  3. Registry: require exact and extended-stable selectors to return <VERSION> for root, every preflight corePackageTarballs entry, and every publishToNpm === true official plugin derived from the tag. Compare the plugin plan, jobs, and complete readback; never infer inventory from diffs.
  4. Provenance: from trusted current tooling, run node --import tsx scripts/openclaw-npm-postpublish-verify.ts <VERSION>. Require signatures, canonical-branch provenance, and publish/preflight digest binding to the release SHA. Preserve output and workflow URLs.
  5. Docker: run scripts/container-registry-readback.mjs against GHCR, Docker Hub, and the repository's VERCEL_VCR_IMAGE. Require exact default, slim, browser, and architecture images, matching platform descriptor sets, and only the three extended-stable* aliases at those immutable digests. Separately verify attestations in GHCR and Docker Hub. Require the successful OpenClaw Release Publish parent run and its completed Docker verification. The normal route finalizes afterward; an explicitly requested fast path may activate GitHub first. Repair aliases through current-main Docker Channel Promotion for the exact tag, without rebuilding.
  6. Recovery: never republish. Use promote_extended_stable in the openclaw/releases dist-tag workflow for the root selector (an unsuffixed final patch 33+) and approved credential-isolated tooling for others, then repeat complete readback. Do not require ClawHub, native/mobile apps, website, private dist-tags, or regular latest. Require shared release evidence, but do not require regular native or ClawHub assets.

Published package smoke

After the track-specific core publication checks pass, use a disposable installation/cache with isolated OpenClaw state. Do not wait for independent ClawHub verification to run this smoke:

  • npm exec --yes --package openclaw@<VERSION> -- openclaw --version.
  • Run at least one harmless command that touches the published CLI surface, for example plugins --help or gateway --help.

Do not start an extra local Gateway or run an ad hoc live model turn as a preliminary release check. Use the canonical release-validation workflows and publication evidence above; this does not remove any of their required lanes. Run additional manual live checks only when explicitly requested.

Caveats To Report

  • Dist-tag caveat: stable latest is release truth; if optional beta mirrors still point at a beta version, report it as a caveat, not a stable-release blocker, unless the user asked to verify beta promotion.
  • ClawHub caveat: distinguish “core release verified; ClawHub pending/failed” from “all selected publication surfaces verified.” The former still permits main closeout and the retrospective PR.
  • Track caveat: name the track and intentionally absent surfaces. Do not call missing regular-release artifacts an extended-stable failure.
  • Divergent checkout caveat: say when local source SHA differs from release tag or origin and which live sources were used instead.

04 同仓库更多 Skills