feat(ci): GitHub Release 发布后自动更新 production 分支触发生产部署 (SHA-4)

[WardLu]

变更说明

实现「GitHub Release 发布 → 更新 production 分支 → 触发 Vercel 生产部署」的发布流程（SHA-4 拆分任务 SHA-11），并对 production 分支启用真实的分支保护：

• 新增 .github/workflows/release-to-production.yml（Deploy release to production）：GitHub Release 发布（release: published）后，将 production 分支指针快进到该 release 的 tag commit；Vercel 的 Branch Tracking（已填 production）随之触发生产构建与部署。支持 workflow_dispatch 手动指定 tag 补发/重跑。
• 分支保护（本次处理重点）：production 已启用两个仓库 ruleset：
  • production: guarded updates：require_pull_request（1 个审查），bypass 仅限专用 deploy key 与 admin；
  • production: no force push or deletion：禁止 force push、禁止删除分支，bypass 仅限 admin（供回滚用 --force-with-lease）。
    工作流不再用 GITHUB_TOKEN 推指针，改用专用 deploy key（secret PRODUCTION_DEPLOY_KEY，SSH，仅本仓库写权限）经 SSH 推送；GITHUB_TOKEN 降为只读。GITHUB_TOKEN/普通协作者推送将被 ruleset 拒绝。
• CONTRIBUTING.md「Release 闸门」同步 production 分支机制、回滚命令与分支保护现状；发布步骤按新流程调整为线性顺序。

只更新分支指针、不创建新提交、不并入 main 开发内容；本 PR 不 push production 分支、不执行部署、不改生产数据。

变更类型

• 功能新增（发布工作流）
• 安全加固（production 分支保护）
• 文档更新

方案取舍

选项	取舍	结论
release 触发 vs 手动触发	release: published 自动触发（主路径）+ workflow_dispatch 手动补发/重跑（兜底）。手动单独触发会增加操作摩擦且容易漏发	两者都做，自动为主、手动兜底
快进校验	strict fast-forward：目标 commit 必须是当前 production 指针的后代，否则失败并明确报错；绝不 force	防止误覆盖，保证 production 永远可回滚、可追溯
分支保护	production 启用 ruleset：require_pull_request(1 审查) + 禁止 force push + 禁止删除；工作流改用专用 deploy key（PRODUCTION_DEPLOY_KEY）作为 bypass actor 推送，GITHUB_TOKEN 降为只读	保护已落地，不再依赖「未来升级路径」
回滚策略	回滚无法快进，由维护者（admin，ruleset 允许）手动 git push --force-with-lease origin <上一个vX.Y.Z>^{commit}:production，再跑 Release production verification 复核	不把 force 自动化，避免误触发生产
与现有工作流衔接	release.yml 负责 tag 产物验证（Release 创建前必须全绿），release-production.yml 负责部署后站点验收；新增工作流只负责中间一环「更新 production 指针」，不重复验证	各司其职，不重复、不冲突

依赖关系：创建 GitHub Release 即代表该 tag 已通过 Release verification（CONTRIBUTING.md「Release 闸门」第 2、3 条），因此本工作流不重复验证产物。

检查清单

• 已按改动范围选择最小充分的测试层级（L0 静态：工作流 YAML + 文档；另含对 GitHub 分支保护 ruleset 的实测）
• npm run check 通过
• npm run public:check 通过
• actionlint 对本工作流及现有 release.yml/release-production.yml/ci.yml 均无告警
• 用模拟 git 仓库实测工作流 shell 逻辑三种场景：正常快进、幂等重跑、非快进拒绝
• 在 GitHub 上实测分支保护 ruleset：deploy key 推送放行（Bypassed rule violations）、admin 令牌推送被拒（GH013）
• deploy key SSH 认证与 host key 指纹校验逐字运行通过
• 未提交 .env、.vercel、secret key 或个人数据
• 无数据库变更
• 已同步 CONTRIBUTING.md；README/CHANGELOG/RELEASE_NOTES 不涉及本次内部工作流改动，无需更新
• 已运行 npm run public:check，并复查暂存区没有内部、敏感或不必要文件

验证记录

• 选定层级：L0 静态（工作流配置 + 文档）＋ 对 GitHub 分支保护的实际验证
• npm run check：Static checks passed.
• npm run public:check：Public repository check passed (0 staged paths, 178 candidate paths).
• actionlint 1.7.7：新增与现有工作流均无输出（无问题）
• shell 逻辑实测（本地模拟远端仓库，production 从 v1.3.8 快进到 v1.3.9）：
  1. 正常路径：production 快进到目标 tag commit ✅
  2. 幂等重跑：已处于目标 commit 时 no-op，明确提示 ✅
  3. 非快进：目标不是当前指针后代时拒绝并提示走回滚命令 ✅
• 分支保护 ruleset 实测（真实 GitHub 仓库，临时分支 + 同结构 ruleset，测后已清理）：
  4. deploy key（SSH）推送：remote: Bypassed rule violations ... Changes must be made through a pull request，推送成功 ✅
  5. admin 令牌（HTTPS，不在 bypass 集合）：remote: GH013 ... push declined due to repository rule violations，被拒 ✅
• 工作流「Set up production deploy key」步骤逐字运行：deploy key 写入、ssh-keyscan 指纹校验（固定 GitHub 官方 RSA host key SHA256:uNiVzt...）、ssh config 生成均通过 ✅
• 未运行：npm run test:full 等（不涉及源码/数据库/浏览器行为，按风险矩阵不适用）

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
shadow-mate	Ready	Preview	Aug 18, 2026 2:13pm