执行本地发版流程，版本号为 $ARGUMENTS。

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

## 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 中是否已有 `## [$ARGUMENTS]` 版本节。

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

```
## [$ARGUMENTS] - <今天日期>

### 新功能
- ...

### 改进
- ...

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

只保留有内容的分类（新功能/改进/修复），根据 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 v$ARGUMENTS
```

## 6. 打 tag

```bash
git tag v$ARGUMENTS
```

## 7. 推送

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

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