bumplisted

# Bump：发版前的版本号对齐（三段式发版的第一段） 职责边界（三段式；2026-09-07 用户修订：bump 属普通文件处理修改——不新增测试用例、不碰核心功能，不走 dev-workflow，直接在 main 上改、`/commit` 直推）： | 段 | 动作 | 执行者 | |---|---|---| | ① `/bump` | 对齐 main → 在 main 上改齐版本号 → 指引 `git add` + `/commit`（main 直推） | 本 skill | | ② `/commit` | commit + push 直推远程 main（main 不设分支保护，2026-09-07 起） | commit skill | | ③ `/release` | 在最新 main 上打 tag + 发 Release | release skill | 为什么直接在 main 上改：版本号文件属普通文件修改，按 dev-workflow 适用范围（仅存在测试用例的软件开发项目的核心改动走分支 + PR）不走分支流程；main 不设分支保护、不限制直接 push，直改直推最简。功能分支永不 bump 的纪律不变——多个并行分支各自 bump 必然冲突，版本号只在发版时于 main 统一改。 ## 执行流程 1. **对齐 main**：`git switch main && git pull --ff-only`。 - 本地 main 与远端分叉（本地领先 / 历史不一致）→ **暂停报告**，等用户确认对齐方式（如 `git reset --hard origin/main`，重置需征得同意）； - 用户在功能分支上触发 `/bump` → 提示：先切回 main（版本号不写在功能分支上）；该功能分支的改动应经自己的 PR 进 main 后再 bump。 2. **判定新版本号**（发布状态必须实测，不凭 VERSION / CHANGELOG / commit 历史推断）： - 实测最新已发布版本：`gh release list --limit 1`（或 `gh release view v<版本>` 查重）； - **CHANGELOG 顶部条目的版本号高于已发布版本** → 新版本号 = 该条目版本号（CHANGELOG 已定稿，bump 只做各文件对齐）； - **无待发布条目** → 从当前 VERSION 起按待发布改动性质定幅度（新增功能 → minor；仅修复 / 文档 → patch；build 号体系按既有序列 +1，如 `3.8.1-32` → `3.8.1-33`），并在 CHANGELOG 顶部**新建**该版本条目（`## [<新版本号>] - <今天日期>`，依据近期 commit 补简要摘要；不改已发布版本的历史条目）。 3. **在 main 上改齐版本号**（以新版本号同步所有版本号载体，存在的才改）： - `VERSION`（纯数字 + 换行，无 `v` 前缀）； - `package.json` 顶层 `version`；`package-lock.json` **顶层** `version`（不动 packages 内依赖版本）； - CHANGELOG 顶部条目版本号与日期（第 2 步已定）； - 主 manifest：`manifest.json` / `pyproject.toml` / `Cargo.toml` /