ccload-release

发布 ccLoad

通过唯一的 Tag 驱动 .github/workflows/release.yml。不要手动创建 Release、手动触发发布工作流或单独发布容器镜像。

参数契约

• $ccload-release、/ccload-release、ccload-release beta、ccload-release preview：发布下一个 Beta。
• ccload-release stable：发布稳定版。必须有显式 stable 参数；禁止根据语气猜测。
• 其他参数：停止并报告只支持 beta、preview、stable。

Tag 形状固定：

• Beta：vX.Y.Z-beta.N
• 稳定版：vX.Y.Z

版本规则

• Beta 必须锁定最近稳定版 vX.Y.S 的主版本 X 和次版本 Y，禁止因 feat 或 breaking change 生成 vX.(Y+1).0-beta.N 或 v(X+1).0.0-beta.N。
• 最近稳定版之后没有有效 Beta 时，发布 vX.Y.(S+1)-beta.1。
• 已有 vX.Y.P-beta.N 时，只检查该 Beta Tag 之后的新提交：
  • 小修改（没有 feat、! 或 BREAKING CHANGE）保持 X.Y.P，发布 vX.Y.P-beta.(N+1)。
  • 大修改（存在 feat、! 或 BREAKING CHANGE）只把 patch 加一并重置序号，发布 vX.Y.(P+1)-beta.1。
• 只有显式 stable 发布才从最近稳定版后的全部提交计算标准 SemVer：breaking change 增加主版本，feat 增加次版本，其余增加 patch。Beta 永远不修改主版本或次版本。
• 最近稳定版之后如果已存在修改主版本或次版本的可达 Beta Tag，立即停止发布并报告非法 Tag；禁止继续制造互相冲突的预览版本。

发布流程

1. 检查 git status 和完整 diff。工作区有改动时，根据实际改动推导一个单行 Conventional Commit subject；必须准确反映最高语义版本影响，禁止使用掩盖功能变更的通用 chore。不要为提交或推送重复询问用户。

2. 从仓库根目录运行预览。默认渠道是 beta。工作区干净时运行：

   bash .agents/skills/ccload-release/scripts/release.sh beta --dry-run
   

   工作区有改动时传入推导出的提交 subject：

   bash .agents/skills/ccload-release/scripts/release.sh beta --dry-run --commit-message 'feat(scope): summary'
   

   稳定版把 beta 改为 stable。

3. 核对脚本输出的上一稳定版、上一有效 Beta、版本动作、目标 Tag、工作区动作和分支动作。用户调用本 Skill 已经授权自动提交、非强制推送 master 和发布；目标符合参数契约时直接继续。

4. 执行发布。工作区干净时运行：

   bash .agents/skills/ccload-release/scripts/release.sh beta --publish
   

   工作区有改动时必须复用 dry-run 的同一个 subject：

   bash .agents/skills/ccload-release/scripts/release.sh beta --publish --commit-message 'feat(scope): summary'
   

   稳定版把 beta 改为 stable。脚本会自动 git add -A、创建提交、非强制推送 master，等待该提交对应的 Test workflow 全部成功，确认远端仍精确一致后再创建并推送 annotated Tag。本地已有未推送提交时不创建额外提交，直接推送并等待 CI。

5. 报告自动创建的提交（如有）、推送的 master 修订、目标 Tag、GitHub Release URL 和 Actions 结果。稳定版报告 ghcr.io/caidaoli/ccload:<tag> 和 ghcr.io/caidaoli/ccload:latest（该稳定版为 SemVer 最高版本时 beta 别名同步指向它，一并报告）；Beta 报告 ghcr.io/caidaoli/ccload:<tag> 和 ghcr.io/caidaoli/ccload:beta。