Release Publisher

TrailSnap 版本发布与验收

严格按顺序执行。完整性优先于打标签；未经用户确认，不得创建 GitHub Release。

1. 发布前检查

1. 确认位于 TrailSnap 仓库根目录。
2. 运行 gh auth status，确认 GitHub CLI 已登录。
3. 运行 git status --short --branch。保护用户已有改动；工作区不干净时先判断归属，不得覆盖。
4. 获取远程标签，并只选择严格语义化标签：
   • 接受正则 ^v[0-9]+.[0-9]+.[0-9]+$
   • 排除 pr-preview、app-v*、预发布标签等
   • 不要直接信任 git describe --tags；它可能选中非版本标签
5. 确认目标标签和 Release 均不存在：
   • 检查本地标签、git ls-remote --tags origin 和 gh release view
6. 获取上个正式版本到 HEAD 的提交。若为空，停止并提示先提交代码。
7. 运行 git grep 搜索上个版本的带 v 和不带 v 形式，建立版本影响清单。

PowerShell 可按版本对象排序标签：

$lastTag = git tag --list |
  Where-Object { $_ -match '^v\d+\.\d+\.\d+$' } |
  Sort-Object { [version]($_ -replace '^v', '') } -Descending |
  Select-Object -First 1

2. 确定版本号

• 用户已指定版本时直接采用。
• 未指定时根据提交建议 patch、minor 或 major。
• patch：修复和小优化。
• minor：向后兼容的新功能。
• major：不兼容变更；必须向用户确认影响与迁移方式。
• 标签始终使用 v 前缀，项目文件使用不带 v 的版本号。

3. 同步版本号

以下是当前基线清单，不是完整清单。先更新这些位置，再用 git grep 发现新增位置。

AI 服务

• package/ai/pyproject.toml
• package/ai/uv.lock
• package/ai/desktop_app.py
• package/ai/app/services/photo_model_repository.py 中的 User-Agent

Server

• package/server/pyproject.toml
• package/server/uv.lock
• package/server/app/core/config_manager.py 中的全部版本常量和默认值

Website 与 CLI

• package/website/package.json
• package/trailsnap-cli/package.json
• package/trailsnap-cli/pyproject.toml
• package/trailsnap-cli/trailsnap/cli.py
• 仅在测试夹具表达“当前产品版本”时同步测试版本；不要误改依赖版本，例如 ts-node@10.9.2

Desktop 与 AI 扩展

• package/desktop/package.json
• package/desktop/src-tauri/Cargo.toml
• package/desktop/src-tauri/Cargo.lock
• package/desktop/src-tauri/tauri.conf.json
• package/desktop/src-tauri/resources/ai-extensions.json
• package/desktop/src-tauri/src/ai_extension.rs 中的扩展版本
• .github/workflows/build-desktop-ai-extension.yml 中的 EXTENSION_VERSION

完成后再次搜索旧版本：

• 历史 changelog 和 version.json 中的旧版本应保留。
• 第三方依赖版本不得误改。
• 所有当前产品版本、锁文件本地包版本和发布工作流版本必须一致。

4. 分析提交并撰写内容

按功能模块归并最终用户可见结果，不要机械罗列 commit。

• 优先提炼 feat、fix、perf 和有用户影响的 refactor。
• 忽略构建前端、构建后端、构建ai、构建cli 等 CI 触发词。
• 忽略中间修复：如果同一功能先实现后优化，只描述最终能力。
• 测试、内部重构和 CI 调整仅在影响稳定性、安装或发布体验时提及。
• Release Notes 使用中文，按桌面端、移动端、照片浏览、设置、安装部署、修复稳定性等实际模块组织。
• 避免无必要的实现术语。

5. 更新官网和客户端更新清单

必须在创建标签前完成：

1. 在 package/official-site/docs/guide/changelog.md 顶部加入中文日志，使用“新增功能 / 优化功能 / Bug 修复”。
2. 在 package/official-site/en/docs/guide/changelog.md 顶部加入等价英文日志，使用“New / Improvements / Bug Fixes”。
3. 在 package/official-site/public/version.json 数组末尾加入新版本：
   • version 不带 v
   • update_info 使用面向用户的简洁中文 HTML，以 <br> 换行
   • download_url 指向本次 GitHub Release 地址
4. 生成 releases/v{version}/：
   • release-notes.md
   • xiaohongshu.md
   • wechat.md

releases/ 通常被 git 忽略；确认三个文件存在即可，不强行提交。

6. 发布前验证、提交与推送

依次执行：

1. 在 package/official-site 下解析 public/version.json。

2. 在 package/official-site 下运行 pnpm docs:build。

3. 在仓库根目录运行完整 E2E：

   pwsh .\tests\scripts\run-tests.ps1 -Layer e2e -Level full

4. 若失败：

   • 区分代码失败与环境/启动器失败。
   • 修复属于本次发布范围的根因后，重新运行同一完整命令。
   • 不得把扫描准备通过或部分用例通过报告为完整通过。

5. 审查 git diff、git diff --check 和工作区状态。

6. 提交所有版本号、官网日志、version.json 及必要的发布测试修复。

7. 使用 Conventional Commits，例如 chore(release): prepare vX.Y.Z。

8. 除非用户明确要求，不在提交消息中加入镜像或包发布触发词。

9. 推送当前分支，确认本地 HEAD 与远程一致且工作区干净。

7. 确认并创建 Release

1. 向用户完整展示 release-notes.md。

2. 明确说明官网构建和完整 E2E 结果。

3. 等待用户确认。

4. 确认后创建 Release：

   gh release create vX.Y.Z --title "vX.Y.Z" --notes-file "releases\vX.Y.Z\release-notes.md"

5. 记录 Release URL、标签 SHA 和创建时间。

6. 不要手动重复创建标签；gh release create 会创建并推送标签。

7. 不得移动已发布标签或删除 Release，除非用户明确授权。

8. 监控标签 CI

创建 Release 后不要立即结束。持续监控该标签触发的工作流，直到全部进入 completed。

当前应关注的工作流基线：

• Build and Push Frontend
• Build and Push Server
• Build and Push AI
• Build Desktop Installers
• Build Desktop AI Extension
• Build Mobile App
• Build and Publish CLI

使用 gh run list --branch vX.Y.Z 和 gh run view 检查状态、矩阵任务及失败步骤。

• 记录本次标签触发的 run ID，避免混入同一提交的分支 push 任务。
• 定期汇报状态变化，不重复播报无变化快照。
• 工作流 queued 或 pending 时继续等待。
• 任一工作流失败时，读取失败 job 和日志，报告根因。
• 未经用户授权，不移动标签、重建 Release 或实施范围外修复。
• Docker 镜像工作流成功不代表有 Release 附件；分别报告镜像与附件状态。