From 4b72d8e73c32dbd92f8fb06a73331cf8abe8b181 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Sat, 2 May 2026 20:06:04 +0100 Subject: [PATCH] docs: clarify beta validation-only fixes --- .agents/skills/openclaw-release-maintainer/SKILL.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.agents/skills/openclaw-release-maintainer/SKILL.md b/.agents/skills/openclaw-release-maintainer/SKILL.md index 23e73d61ce0..131e72d6534 100644 --- a/.agents/skills/openclaw-release-maintainer/SKILL.md +++ b/.agents/skills/openclaw-release-maintainer/SKILL.md @@ -47,6 +47,13 @@ Use this skill for release and publish-time workflow. Keep ordinary development recreate the tag and prerelease at the fixed commit so npm prerelease versions stay contiguous. If a published prerelease needs a fix, commit the fix on the release branch and increment to the next matching `-alpha.N` or `-beta.N`. +- After a beta is published, distinguish validation-only fixes from product + fixes. Test, docs, workflow, release-script, changelog, or agent-skill fixes + that do not change the `openclaw` package runtime can be committed and + validated without cutting a new beta. Any fix that changes shipped OpenClaw + runtime, package contents, install/update behavior, public API, or user-facing + behavior after the beta was published usually requires a new `-beta.N` before + treating release validation as evidence for the published package. - For a beta release train, run the fast local preflight first, publish the beta to npm `beta`, then run the expensive published-package roster focused on install/update/Docker/Parallels/NPM Telegram. If anything fails, fix it on