build(GOV-009): 对齐应用部署与运行入口

docs/deployment/ubuntu-source-production.md

@@ -1,37 +1,40 @@
 # Ubuntu 源码生产部署
 
-正式支持 Ubuntu 22.04 LTS 与 Ubuntu 24.04 LTS 的 x86_64。服务器管理员预先提供 Node.js 22 LTS、pnpm 10、Nginx，以及 MySQL 5.7、Redis、RocketMQ 5.x 或相应外部服务；项目不负责安装或升级这些软件，也不修改系统软件源。
+正式支持 Ubuntu 22.04 LTS 与 Ubuntu 24.04 LTS x86_64。服务器管理员预先提供 Node.js 22 LTS、pnpm 10、Nginx，以及 MySQL 5.7、Redis、RocketMQ 5.x 或相应外部服务；项目不负责安装、升级或修改系统软件源。
 
-## 前置验证
+## 构建发布目录
 
 ```bash
 uname -m
 node --version
 pnpm --version
-nginx -v
+pnpm install --frozen-lockfile
+pnpm check:contracts
+pnpm verify
 ```
 
-架构必须为 `x86_64`，Node.js 必须为 22 LTS，pnpm 必须为 10.x。不满足要求时终止部署。
+架构必须为 `x86_64`，Node.js 必须为 22.x，pnpm 必须为 10.x。每次发布使用 `/opt/a-share-analysis/releases/<版本或提交>/` 新目录，验证后再原子切换 `/opt/a-share-analysis/current`，禁止在 current 中原地覆盖。
 
-## 目录与配置
+## 配置与 systemd
 
-- 发布目录：`/opt/a-share-analysis/releases/<版本或提交>/`。
-- 当前版本：`/opt/a-share-analysis/current` 符号链接。
-- 生产配置：`/etc/a-share-analysis/api.env`、`scheduler.env`、`worker.env`、`web.env`。
-- 运行用户：非登录系统用户 `a-share`。
+生产配置放在 `/etc/a-share-analysis/api.env`、`scheduler.env`、`worker.env`，建议权限 `root:a-share 0640`；Web 的 `VITE_` 公开变量在构建前注入。三个 systemd 单元通过各自的 `EnvironmentFile=` 只读取本进程需要的键，运行用户为非登录系统用户 `a-share`。
 
-真实配置从仓库生产模板生成，但不得放入发布目录。API、Scheduler、Worker 的 systemd 单元分别通过 `EnvironmentFile=` 读取自己的配置；包含秘密的文件建议为 `root:a-share 0640`。
+```bash
+sudo install -m 0644 deploy/systemd/a-share-*.service.example /etc/systemd/system/
+sudo install -m 0644 deploy/nginx/a-share-analysis.conf.example /etc/nginx/conf.d/a-share-analysis.conf
+sudo systemd-analyze verify /etc/systemd/system/a-share-api.service.example
+sudo systemd-analyze verify /etc/systemd/system/a-share-scheduler.service.example
+sudo systemd-analyze verify /etc/systemd/system/a-share-worker.service.example
+sudo nginx -t
+sudo systemctl daemon-reload
+sudo systemctl restart a-share-api.service.example
+sudo systemctl restart a-share-scheduler.service.example
+sudo systemctl restart a-share-worker.service.example
+curl --fail http://127.0.0.1:3000/api/v1/health
+```
 
-## 构建与启动边界
+当前工程尚无业务表迁移；后续新增迁移后必须在切换 current 前执行并记录结果。生产环境禁止 `synchronize: true`，开发流程也禁止用生产数据库做 Schema 基线或连接测试。
 
-使用 `pnpm install --frozen-lockfile` 安装锁定依赖，在新发布目录构建 Web 和 Server。Web 静态文件由 Nginx 托管，API、Scheduler、Worker 运行编译后的 JavaScript。禁止 Vite 开发服务器、watch、调试端口和生产运行 TypeScript。
+## 检查与回退
 
-当前应用尚未脚手架化，仓库中的 systemd 与 Nginx 文件是路径和权限契约示例，不能冒充已经验证的线上启动文件。后续应用功能必须补充实际构建、启动和健康检查验证。
-
-## 升级、检查与回退
-
-在新的不可变发布目录完成安装、构建和配置校验后，原子切换 `current`，依次重启 API、Scheduler、Worker 并检查 `systemctl status`、`journalctl` 和 HTTP 健康端点。失败时切回上一完整目录并重启服务；生产配置不随版本切换覆盖。
-
-项目部署流程禁止连接或读取生产数据库做开发验证。数据库备份属于独立运维职责，应用回退不得删除或覆盖数据。
-
-RocketMQ 由运维独立维护 NameServer、Broker 和需要时的 Proxy。应用发布只读取受控的 RocketMQ Endpoint、Topic 前缀与 Group 配置，不负责创建或升级集群，也不得把 Broker 数据目录放进应用发布目录。
+使用 `systemctl status`、`journalctl -u`、HTTP 健康端点和 Nginx 访问结果确认发布。失败时把 `current` 原子切回上一完整发布目录，重启三个服务并再次验证。生产配置和数据不随代码目录覆盖；RocketMQ 的 NameServer、Broker、Proxy 与 CommitLog 由运维独立维护。