release-workflow

# Release Workflow ## Overview 发版流程：前置检查 → 确定新版本号 → 写入 CHANGELOG → 创建 tag 并推送。**只能在 main 分支执行**。 仓库只有**一套 tag**：平台与 CLI 共用同一条版本线，一个 `v*` tag 触发全部三个 workflow。 | Tag 前缀 | 用途 | CI 自动做的事 | |----------|------|----------------| | `v*`（如 `v0.7.1`）| 整个仓库发版（平台 + CLI） | ① 从 CHANGELOG 抽段落 → 创建 GitHub Release ② 构建并推送多架构 Docker 镜像到 GHCR ③ typecheck / test / 包内容校验 → 把 `a2wave` 包发到公共 npm（带 provenance，需 `NPM_TOKEN` 仓库 secret）| 因此 `package.json` 与 `apps/cli/package.json` 的 `version` **必须始终一致**，且都要与 tag 一致——两个 workflow 都会校验，不一致直接失败。 ## When to Use - 用户要求发版、打 tag、创建 release - 需要更新 CHANGELOG 并推送新版本 - 关键词：发版、release、tag、changelog ## Core Workflow ```mermaid flowchart LR P[0. 前置检查] --> S[0.5 敏感 token 扫描] S --> W[0.7 使用手册同步] W --> A[1. 确定版本号] A --> B[2. 写入 CHANGELOG] B --> C[3. 创建 tag 并推送] ``` ### 步骤 0：前置检查（必须全部通过） - **main 分支**：`git branch --show-current` 必须为 `main`。若非 main，中止并提示 `git checkout main` 后再执行。 - **与远程同步**：在 main 分支时，必须先执行 `git pull origin main`（或 `git pull`）。若 pull 产生冲突或失败，中止并提示用户解决后再发版。pull 成功后再进行后续检查。 - **测试通过**：`pnpm test:all` 必须零失败。失败则中止。 - **工作区干净**：`git status` 无未提交变更。若有其它未提交文件，提示用户先 commit 再发版。 ### 步骤 0.5：敏感 token / 凭据扫描（HARD GATE，禁止跳过） 发版会把整份代码 tag 化并（主版本）触发 GitHub Release，一旦泄露的 secret 进入 tag，撤回成本极高。**打 tag 前必须���将要发布的全量代码做一次密钥扫描**： ```bash # 全仓扫描（不只是本次 diff）——发版是整棵树的快照，必须全量 node scripts/gates/check-forbidden-tokens.mjs --all ``` - 该脚本覆盖 PEM 私钥、Anthropic key（`sk-ant-*`）、AWS、通用高熵 token 等规则，allowlist 在 `scripts/gates/forbidden-tokens-allowlist.j...