Alpha/Nightly 自动化发布与 Beta 触发技能

一、技能概述

该技能是 OpenClaw/Tideclaw 的 Alpha/Nightly 发布自动化中枢，负责从创建隔离发布分支到 npm 发布的全流程自动化。其核心理念是：Alpha 工作在隔离分支上进行，避免 main 分支的临时故障阻塞 Nightly 版本的可用性。

关键原则：

• Alpha/Nightly 每 12 小时运行一次，或由手动触发

• Beta 由人工从 Discord 触发，基于已验证的 Alpha/Release 分支

• Stable/Latest 始终需要明确的人工确认

• 绝不从 dirty checkout 或直接从 main 发布

• 仅在 release-branch 验证通过后才发布

• Alpha 成功后，将 release-branch 的修复前向移植回 main，并证明 main CI 为绿色

二、核心功能

1. 分支命名与版本号规则

• 分支前缀：tideclaw/alpha/

• 分支名称：tideclaw/alpha/YYYY-MM-DD-HHMMZ

• Base：触发时当前 origin/main 的 SHA

• Release Tag：vYYYY.M.PATCH-alpha.N

• npm dist-tag：alpha

• PATCH 规则：PATCH 是月度发布序列号，不是日历日。从 stable 和 beta 版本中确定 alpha train，忽略 alpha-only 的 patch 号。使用该月最高的 stable/beta patch 加 1，然后在该 train 上递增 alpha.N。如果该 patch 已存在 beta，则将 alpha 移至下一个 train。

2. 启动流程

# 在 Tideclaw host checkout 中工作
git fetch origin main --tags --prune
git switch main && git merge --ff-only origin/main
BASE_SHA="$(git rev-parse origin/main)"
BRANCH="tideclaw/alpha/$(date -u +%Y-%m-%d-%H%MZ)"
git switch -c "$BRANCH" "$BASE_SHA"

启动前必须阅读仓库的 release 文档：AGENTS.md、docs/ 下的 release 文档、scripts/ 下的 release 脚本以及 .github/workflows/*release*。

3. 复用历史修复（Reuse Prior Fixes）

在运行检查之前，技能会从最近的 Tideclaw alpha 分支中挖掘已做出的修复：

• 从 $release-private 读取 Tideclaw 状态文件，获取上次成功的 alpha 分支和修复 commit SHA

• 列出最近 3 天内的 Tideclaw alpha 分支

• 对每个候选分支，检查不在当前 origin/main 中的 commit

• 仅 cherry-pick 真正的稳定性修复，跳过版本 bump、changelog 发布条目、tag artifacts、生成 release notes、state-file-only commits 和调试 instrumentation

• Cherry-pick 冲突时，检查当前 main 是否已包含等效修复，如未包含则最小化解决

4. 修复循环（Repair Loop）

• 首先运行窄范围的本地检查：变更测试、release preflight、type/lint/build gates

• 本地检查失败时，在 alpha 分支上以最小 commit 修复

• 每次修复后重新运行失败的检查

• 不通过编辑 baseline、expected-failure 列表、ignore 文件或 release inventory 来隐藏失败，除非 release docs 明确要求且有正当理由

• 如果失败是 flaky，重跑一次；仍为红色则视为真实失败

• 如果修复对 main 明显有用，保持其小巧且可前向移植

5. 发布 CI

本地验证通过后：

• 从现有 git tags、npm versions 和 GitHub releases 计算下一个 vYYYY.M.PATCH-alpha.N

• 使 alpha 分支的 package version 和 release metadata 匹配该 tag，commit 并 push

• 使用 GitHub CLI 运行 release validation，不使用浏览器/fetch 工具

• 在 Tideclaw host 上，使用 /usr/local/bin/gh-tideclaw-write 进行写操作（workflow run、cancel、publish dispatch）

GH="/usr/local/bin/gh-tideclaw-write"
"$GH" workflow run full-release-validation.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f ref="$BRANCH" \
  -f release_profile=beta \
  -f rerun_group=all
"$GH" workflow run openclaw-npm-release.yml --repo openclaw/openclaw --ref "$BRANCH" \
  -f tag="$SHA" \
  -f preflight_only=true \
  -f npm_dist_tag=alpha

阻塞门控（Blocking Gates）：正常 CI、plugin prerelease、npm preflight、package preparation、install smoke、tag/reachability、publish verification。

建议门控（Advisory Gates）：跨 OS、live channel、QA Lab、package acceptance、long Docker E2E、Telegram package E2E——失败时继续发布，仅在 Discord 中报告。

6. 发布验证与 npm 发布

• Full validation 和 npm preflight 在同一分支 head 上变绿后，从该确切 commit 创建并 push release tag

git tag -a "$TAG" "$SHA" -m "openclaw ${TAG#v}"
git push origin "$TAG"

• 从同一 alpha 分支调度 publish wrapper，使用成功的 npm preflight run ID 和 full release validation run ID

• 不从 host 直接 publish npm，使用 GitHub Actions/OIDC

• openclaw-npm-release.yml 的 preflight_only=true 仅准备 artifacts，不发布。成功需要后续的 openclaw-release-publish.yml wrapper

7. 验证已发布的 Alpha

所有条件为真时，Alpha 发布才算完成：

• GitHub tag 存在

• GitHub Release 存在且标记为 prerelease

• Release body 链接 npm version page、registry tarball、integrity 和 CI/proof

• npm view openclaw@ 显示确切的 version、dist-tag alpha、tarball、integrity 和 publish time

• Installed/package smoke 遵循 repo release docs

• Tideclaw 状态文件记录 version、tag、base SHA、branch、fix commit SHAs、workflow run IDs、npm integrity 和 timestamp

8. 前向移植（Forward-Port）

Alpha 成功后，向 main 提起一个 仅包含修复的 PR：

• 从当前 origin/main 创建 forward-port 分支

• 仅 cherry-pick 使 nightly/release 检查通过的真正修复

• 排除：alpha version bumps、changelog release entries、release notes、tag artifacts、generated release assets、state-file-only commits、仅用于发布 alpha 的 commit

• 如果 commit 混合了真正修复和 release/version 变更，拆分它：仅将修复 hunks 重放到 forward-port 分支

• 冲突时，选择最小的 main 兼容修复

• Push 并开 PR，等待 main CI 变绿

• 报告 PR/merge SHA 以及有意未 forward-port 的 commits

9. 分支保留策略（Branch Retention）

每次运行前后，清理旧的 alpha 分支：

• 保留过去 3 天 UTC 内的分支

• 保留被活跃 workflow run、open PR、release tag 或 state file 引用的分支

• 仅删除 Tideclaw 拥有的 alpha 分支，绝不删除 human branches、beta branches、stable branches 或未知前缀

10. Discord 触发

Alpha 触发（在 #releases 或 #maintainers 中）：

• 接受形状：@Tideclaw run alpha now、@Tideclaw alpha release from main now、@Tideclaw trigger alpha

• 从当前 origin/main 创建全新的 tideclaw/alpha/YYYY-MM-DD-HHMMZ 分支

• 遵循正常 alpha 工作流

• 如果另一个 alpha/beta/stable release run 已激活，报告并停止

• #maintainers 触发需要显式的 Tideclaw 提及

Beta 触发：

• 接受形状：@Tideclaw beta release from vYYYY.M.PATCH-alpha.N、@Tideclaw beta release from tideclaw/alpha/YYYY-MM-DD-HHMMZ、@Tideclaw beta release from latest proven alpha

• 要求包含 beta release 字样和源 alpha tag/branch，或 latest proven alpha

• 从已验证的 alpha source 创建全新的 beta branch

• Beta 版本为 vYYYY.M.PATCH-beta.N，匹配 npm --tag beta

• 使用 GitHub Actions/OIDC 发布，不从 host 直接 npm publish

三、主要用途

1. 每 12 小时自动 Nightly 发布
   Alpha/Nightly 版本每 12 小时自动运行，确保社区始终可以获取最新的开发版本。

2. 手动 Alpha 触发
   维护者可通过 Discord 命令随时触发 Alpha 发布，从当前 main 创建隔离分支并执行完整发布流程。

3. Beta 发布准备
   从已验证的 Alpha 版本触发 Beta 发布，为 Stable 发布做准备。

4. 发布分支修复
   在 Alpha/Beta 发布分支上执行本地检查和修复循环，确保发布候选版本通过所有必要的门控。

5. 发布后前向移植
   Alpha/Beta 发布成功后，将仅包含修复的 commits 前向移植回 main，保持 main 与发布分支的同步。

四、与其他技能的协作

五、重要原则

1. 隔离分支：Alpha 工作必须在隔离的 tideclaw/alpha/ 分支上进行，避免 main 的临时故障阻塞 Nightly 发布

2. 绝不从 dirty checkout 发布

3. 绝不直接从 main 发布

4. 前向移植 PR 仅包含修复：不包含 alpha version bumps、release notes、changelog release entries、tags、generated artifacts 或 state-file updates

5. 使用 Tideclaw 机器身份 commit：git config user.name "Tideclaw" / git config user.email "[email protected]"

6. 避免直接 push 到受保护的 main：通过 PR/automerge 进行前向移植

7. 绝不打印 secrets

8. 停止条件：release docs/scripts 对版本或发布路径有分歧、必需的 secrets/auth 不可用、GitHub Actions 无法调度或观察、必需的 release gate 在真实修复尝试后仍为红色、npm/GitHub 状态在发布后不一致、forward-port 无法在不涉及更大产品决策的情况下变绿

六、总结

Release OpenClaw Nightly 是 OpenClaw/Tideclaw 的 Alpha/Nightly 发布自动化技能，负责每 12 小时或手动触发的 Alpha 发布、Beta 发布触发、发布分支修复以及发布后向 main 的前向移植。它通过隔离分支策略确保 main 的临时故障不阻塞 Nightly 版本的可用性，通过复用历史修复减少重复工作，通过严格的门控分类（阻塞门控 vs 建议门控）平衡发布速度与质量。该技能适用于 OpenClaw/Tideclaw 项目的自动化 Nightly 发布、Alpha/Beta 版本管理和发布后代码同步场景，是保障开发版本持续交付的关键基础设施。