---
description: 执行本地发版流程（build → test → CHANGELOG → commit → tag → push）
argument-hint: <version> 如 1.0.22
model: claude-sonnet-4-6
allowed-tools: Bash, Read, Edit, Write
---

执行本地发版流程。

**确定版本号：**
- 如果 `$ARGUMENTS` 非空，使用它作为版本号（VERSION）。
- 如果 `$ARGUMENTS` 为空，运行 `git describe --tags --abbrev=0` 获取最新 tag（如 `v1.0.20`），去掉 `v` 前缀后将 patch 号加 1（如 `1.0.21`），作为版本号（VERSION）。将自动确定的版本号告知用户。

后续所有步骤中，将确定好的版本号记为 VERSION。

按以下步骤顺序执行，任意步骤失败立即停止并报告错误。

## 1. 检查工作区

检查是否有未提交的改动（`git status`）。如果有，列出文件并询问用户是否继续。

## 2. 本地构建

```bash
export PATH="/opt/homebrew/bin:$PATH"
cd backend && go build ./...
```

## 3. 运行测试

```bash
export PATH="/opt/homebrew/bin:$PATH"
cd backend && go test ./...
cd client && flutter analyze --no-fatal-infos --no-fatal-warnings
```

## 4. 更新 CHANGELOG.md

检查 CHANGELOG.md 中是否已有 `## [VERSION]` 版本节。

- **已有**：直接使用，不修改。
- **没有**：读取 `git log` 从上一个 tag 到 HEAD 的提交记录，自动生成一个版本节插入到文件顶部（位于已有版本节之前），格式如下：

```
## [VERSION] - <今天日期>

### 新功能
- ...

### 改进
- ...

### 修复
- ...
```

只保留有内容的分类（新功能/改进/修复），根据 commit message 的类型（feat/fix/refactor 等）归类。

**CHANGELOG 撰写原则：**
- 站在**用户视角**总结，描述对使用体验的实际影响，而非技术实现
- **忽略**以下类型的提交（产品感知弱）：
  - 发版工具、CI/CD、部署脚本相关（chore: release、ci:、devops:）
  - 内部文档、开发规范、CLAUDE.md 更新（docs(claude):、docs(internal):）
  - 代码格式、lint、重构（style:、refactor: 纯内部）
  - 依赖升级、版本号 bump（chore: bump、chore: upgrade）
- **保留并重点描述**：feat、fix、perf 类，以及用户能感知到的 refactor（如界面改版、交互优化）
- 每条描述用一句话说清楚"用户能做什么"或"修了什么问题"，不堆砌技术术语

## 5. 提交代码

将所有改动（包括 CHANGELOG.md）用以下格式提交到 main：

```
chore: release vVERSION
```

## 6. 打 tag

```bash
git tag vVERSION
```

## 7. 推送

```bash
git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main vVERSION
```

推送成功后提示用户：CI/CD 已触发，等待 Telegram 通知。