feat(devops): 发版拆分为 client/site/server 三条独立流水线

将单一 CI/CD 流水线拆成三条互不影响的发布流水线，各有 tag 前缀、独立版本
序列与独立 CHANGELOG：

- client（client-v*）：Flutter 全平台 + version.yaml 自更新清单
- site（site-v*）：web/ Eleventy 营销站，不含 web 版 app
- server（server-v*）：backend Go 服务 + 共享基建 nginx/systemd

新增 3 个 workflow（deploy-client/site/server.yml）替换 deploy.yml；CI 脚本
按 part 拆分为 compile-/release-/deploy-{client,site,server}.sh，抽出公共函数
lib-forgejo.sh；compile-{macos,android,ios,windows}.sh 改去 client-v 前缀；
manual.yml 按前缀路由回滚。

跨流水线解耦：version.yaml 归 client，后端每请求实时读取（不重启、不触发
server 流水线）；官网下载页的版本徽章/下载链接/更新日志时间线运行时经
/api/v1/public/release 动态拉取（API 不可达回退构建时静态内容）。为此一次性
扩展后端 changelog 字段（version.go/public.go）与 download.njk 动态渲染。

CHANGELOG.md 重命名为 CHANGELOG-client.md，新增 CHANGELOG-site/server.md；
重写 /release 命令为 /release <part> [version]；同步更新 CLAUDE.md 与部署文档。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.claude/commands/release.md

@@ -1,17 +1,26 @@
 ---
-description: 执行本地发版流程（build → test → CHANGELOG → commit → tag → push）
-argument-hint: <version> 如 1.0.22
+description: 执行某一条流水线的本地发版（part ∈ client|site|server）
+argument-hint: <part> [version]  如 `client 1.0.55` 或 `server`
 model: claude-sonnet-4-6
 allowed-tools: Bash, Read, Edit, Write
 ---
 
-执行本地发版流程。
+执行三条独立流水线之一的本地发版流程。`$ARGUMENTS` 形如 `<part> [version]`：
 
-**确定版本号：**
-- 如果 `$ARGUMENTS` 非空，使用它作为版本号（VERSION）。
-- 如果 `$ARGUMENTS` 为空，运行 `git describe --tags --abbrev=0` 获取最新 tag（如 `v1.0.20`），去掉 `v` 前缀后将 patch 号加 1（如 `1.0.21`），作为版本号（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`。
 
-后续所有步骤中，将确定好的版本号记为 VERSION。
+**三者互不影响**：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`。
 
 按以下步骤顺序执行，任意步骤失败立即停止并报告错误。
 
@@ -19,27 +28,31 @@ allowed-tools: Bash, Read, Edit, Write
 
 检查是否有未提交的改动（`git status`）。如果有，列出文件并询问用户是否继续。
 
-## 2. 本地构建
+## 2. 本地构建 + 测试门禁（按 part）
 
 ```bash
 export PATH="/opt/homebrew/bin:$PATH"
-cd backend && go build ./...
 ```
 
-## 3. 运行测试
+- **server**：
+  ```bash
+  cd backend && go build ./... && go vet ./... && go test ./...
+  ```
+- **client**：
+  ```bash
+  cd client && flutter analyze --no-fatal-infos --no-fatal-warnings
+  ```
+- **site**：
+  ```bash
+  cd web && npm ci && npm run build
+  ```
 
-```bash
-export PATH="/opt/homebrew/bin:$PATH"
-cd backend && go test ./...
-cd client && flutter analyze --no-fatal-infos --no-fatal-warnings
-```
+## 3. 更新 CHANGELOG_FILE
 
-## 4. 更新 CHANGELOG.md
-
-检查 CHANGELOG.md 中是否已有 `## [VERSION]` 版本节。
+检查 CHANGELOG_FILE 中是否已有 `## [VERSION]` 版本节。
 
 - **已有**：直接使用，不修改。
-- **没有**：读取 `git log` 从上一个 tag 到 HEAD 的提交记录，自动生成一个版本节插入到文件顶部（位于已有版本节之前），格式如下：
+- **没有**：读取该 part 上一个 tag（`<PART>-v*`）到 HEAD 的 `git log`，自动生成版本节插入文件顶部（位于已有版本节之前），格式：
 
 ```
 ## [VERSION] - <今天日期>
@@ -54,36 +67,33 @@ cd client && flutter analyze --no-fatal-infos --no-fatal-warnings
 - ...
 ```
 
-只保留有内容的分类（新功能/改进/修复），根据 commit message 的类型（feat/fix/refactor 等）归类。
+只保留有内容的分类，按 commit 类型（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（如界面改版、交互优化）
-- 每条描述用一句话说清楚"用户能做什么"或"修了什么问题"，不堆砌技术术语
+- 站在**用户视角**总结，描述对使用体验的实际影响，而非技术实现。
+- **忽略**产品感知弱的提交：发版/CI/部署（chore: release、ci:、devops:）、内部文档/规范（docs(claude):、docs(internal):）、纯格式/重构（style:、refactor:）、依赖升级（chore: bump）。
+- **保留并重点描述** feat / fix / perf，以及用户可感知的 refactor（界面改版、交互优化）。
+- 每条一句话说清"用户能做什么"或"修了什么问题"。
+- **范围按 part 过滤**：client 只收 `client/` 相关；server 只收 `backend/` 相关；site 只收 `web/`（营销站）相关。
 
-## 5. 提交代码
+## 4. 提交代码
 
-将所有改动（包括 CHANGELOG.md）用以下格式提交到 main：
+将所有改动（含 CHANGELOG_FILE）提交到 main：
 
 ```
-chore: release vVERSION
+chore: release <PART>-v<VERSION>
 ```
 
-## 6. 打 tag
+## 5. 打 tag
 
 ```bash
-git tag vVERSION
+git tag <PART>-v<VERSION>
 ```
 
-## 7. 推送
+## 6. 推送
 
 ```bash
-git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main vVERSION
+git push ssh://git@git.51yanmei.com:2222/wangjia/jiu.git main <PART>-v<VERSION>
 ```
 
-推送成功后提示用户：CI/CD 已触发，等待 Telegram 通知。
+推送成功后提示用户：对应流水线（deploy-<PART>）已触发，等待 Telegram 通知。