feat(deploy): 接入全自动生产发布校验

docs/decisions.md

@@ -477,6 +477,20 @@
 
 **理由**：Docker Compose 足够覆盖当前单机云服务器和本地服务器形态，部署成本低、可读性强，也符合现阶段 2 核 4G 云主机目标。同域反代能减少 CORS 和公网端口暴露面。本地服务器默认 8080，避免占用 80 端口或要求管理员权限；云服务器继续使用 80 作为外层入口。HTTPS 证书自动续期和域名接入在不同云环境差异较大，先作为外层能力处理，避免把生产部署模板绑死在某一种证书方案上。
 
+## 38.1. 生产发布改为 CI 镜像制品 + 运行版本校验
+
+**问题**：仅让部署侧 `git pull` 最新代码并不能保证线上用户看到新前端。Next.js 前端需要重新构建，Docker 容器也需要重新创建；如果对方只拉代码、不 `build/up`，就会出现仓库是新的、运行容器仍是旧的情况，需求池搜索、成员用户名、性能改动等都无法靠肉眼判断是否已经上线。
+
+**决策**：
+- GitHub Actions 在 `master` 更新时构建 `web` / `server` Docker 镜像，并推送到 GHCR。
+- 镜像以 commit SHA 作为不可变 tag，同时更新 `master` tag。
+- `docker-compose.prod.yml` 使用 `WEB_IMAGE` / `SERVER_IMAGE` 拉取镜像，保留 `build` 仅作为本地兜底。
+- `APP_VERSION` 使用 commit SHA，构建时写入前端 `NEXT_PUBLIC_APP_VERSION` 和后端运行环境。
+- 后端提供 `GET /api/v1/health/version`，Actions 发布结束后必须校验返回版本等于本次 commit SHA。
+- 前端定时比较自身构建版本和服务端运行版本，不一致时提示刷新页面。
+
+**理由**：发布物必须是 CI 产出的镜像，而不是服务器上的源码目录。版本号打进镜像后，部署问题可以被机器判断：如果 Actions 校验通过，说明线上容器已经运行本次提交；如果校验失败，问题就在部署链路而不是业务代码。前端刷新提示解决的是浏览器仍持有旧 bundle 的尾部问题，不能替代容器更新，但能让用户明确知道需要刷新。
+
 ## 39. AppData 文档写入采用乐观锁，先阻止静默覆盖
 
 **问题**：V2.1 阶段业务数据仍按模块存成 `app_data.value` 整份 JSON 文档。多人同时打开同一模块后，如果 A 和 B 都基于旧副本编辑，原来的无条件 `upsert` 会让后保存的人覆盖先保存的人，尤其是任务、Bug、成员等高频写入数据。