jiu/.claude/commands/release.md at 21a4a8cab76246a96c1bd681c294982d2a387e9c

Files

T

wangjia 21a4a8cab7 ci: 补三道缺口闸——CI 强制 flutter test + SSR 模板 token 同源 + 徽章图标映射同集

- checks.yml 加 flutter test（DoD 写了但此前无闸，golden 回归全靠自觉；
  本地 /release client 门禁同步加了 flutter test，该文件 gitignore 不入库）
- check-l1-sync ⑤：backend 公开页模板内联 token 值须与原型 tokens.css
  对应主题块一致（模板自包含手拷值，此前仅注释约定零校验；已注入漂移自证）
- check-l1-sync ⑥：BADGE_ICON ↔ kStatusIcons 状态词同集（此前两端手工转录）
- 顺修 gen_tokens 旧路径注释（client/lib/core/theme/tool/ → client/tool/）

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JJ1g8XV1YhhmHRzhwWEW7o

2026-07-07 18:24:34 +08:00

3.4 KiB

Raw Blame History

description, argument-hint, model, allowed-tools

description	argument-hint	model	allowed-tools
执行某一条流水线的本地发版（part ∈ client\|site\|server）	<part> [version] 如 `client 1.0.55` 或 `server`	claude-sonnet-4-6	Bash, Read, Edit, Write

执行三条独立流水线之一的本地发版流程。$ARGUMENTS 形如 <part> [version]：

part（必填）：client | site | server，分别对应 tag 前缀 client-v* / site-v* / server-v*、CHANGELOG 文件 CHANGELOG-client.md / CHANGELOG-site.md / CHANGELOG-server.md。
version（选填）：如 1.0.55。

三者互不影响：client 发版只动 app 产物与 version.yaml（官网下载页与后端 /version 自动同步，无需重建官网/重启后端）；site 只重建营销站；server 只换后端二进制 + nginx。

0. 解析参数

校验 part 合法（client|site|server），非法立即报错退出。
记 PART = part。

确定版本号 VERSION：

给了 version：直接用。
没给：git describe --tags --match "<PART>-v*" --abbrev=0 取该前缀最新 tag（如 client-v1.0.54），去掉 <PART>-v 前缀后 patch +1（如 1.0.55）。若该前缀尚无任何 tag，则 VERSION=1.0.0。将自动确定的版本号告知用户。
记 TAG = <PART>-v<VERSION>，CHANGELOG_FILE = CHANGELOG-<PART>.md。

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

1. 检查工作区

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

2. 本地构建 + 测试门禁（按 part）

export PATH="/opt/homebrew/bin:$PATH"

server：

cd backend && go build ./... && go vet ./... && go test ./...

client：

cd client && flutter analyze --no-fatal-infos --no-fatal-warnings && flutter test

site：
```
cd web && npm ci && npm run build
```

3. 更新 CHANGELOG_FILE

检查 CHANGELOG_FILE 中是否已有 ## [VERSION] 版本节。

已有：直接使用，不修改。
没有：读取该 part 上一个 tag（<PART>-v*）到 HEAD 的 git log，自动生成版本节插入文件顶部（位于已有版本节之前），格式：

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

### 新功能
- ...

### 改进
- ...

### 修复
- ...

只保留有内容的分类，按 commit 类型（feat/fix/refactor 等）归类。

CHANGELOG 撰写原则：

站在用户视角总结，描述对使用体验的实际影响，而非技术实现。
忽略产品感知弱的提交：发版/CI/部署（chore: release、ci:、devops:）、内部文档/规范（docs(claude):、docs(internal):）、纯格式/重构（style:、refactor:）、依赖升级（chore: bump）。
保留并重点描述 feat / fix / perf，以及用户可感知的 refactor（界面改版、交互优化）。
每条一句话说清"用户能做什么"或"修了什么问题"。
范围按 part 过滤：client 只收 client/ 相关；server 只收 backend/ 相关；site 只收 web/（营销站）相关。

4. 提交代码

将所有改动（含 CHANGELOG_FILE）提交到 main：

chore: release <PART>-v<VERSION>

5. 打 tag

git tag <PART>-v<VERSION>

6. 推送

git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main <PART>-v<VERSION>

推送成功后提示用户：对应流水线（deploy-）已触发，等待 Telegram 通知。

3.4 KiB Raw Blame History Unescape Escape