更新部署工作流，将分支从 prod 修改为 main，并相应调整文档说明

.gitea/workflows/deploy-production.yaml

@@ -1,13 +1,13 @@
 name: Deploy production
 on:
   push:
-    branches: [prod]
+    branches: [main]
   workflow_dispatch:
 
 jobs:
   deploy:
-    # Manual runs must also select prod before receiving production credentials.
+    # Manual runs must also select main before receiving production credentials.
-    if: ${{ github.ref == 'refs/heads/prod' }}
+    if: ${{ github.ref == 'refs/heads/main' }}
     # Match the label of tencent-prod-runner on server B, not its runner name.
     runs-on: tencent-prod
     steps:

docs/deployment-gitea.md

@@ -1,6 +1,6 @@
 # Gitea 生产部署
 
-本方案使用两台服务器：A 服务器托管 Gitea 和项目仓库；B 服务器运行 `tencent-prod-runner`，拉取 A 上的 `prod` 分支代码，在 B 上构建镜像并启动 Docker Compose。工作流通过标签 `tencent-prod` 选择该运行器。
+本方案使用两台服务器：A 服务器托管 Gitea 和项目仓库；B 服务器运行 `tencent-prod-runner`，拉取 A 上的 `main` 分支代码，在 B 上构建镜像并启动 Docker Compose。工作流通过标签 `tencent-prod` 选择该运行器。
 
 PostgreSQL 位于独立数据库服务器或云数据库，B 上的应用通过 `DATABASE_URL` 访问它，不依赖同机数据库容器或外部 Docker 网络。应用入口绑定 **B 服务器**的 `127.0.0.1:8112`，由 B 的宿主机反向代理提供公网 HTTPS。现有 `compose.yaml`、`compose.public.yaml` 保持独立，不与生产文件叠加。
 
@@ -55,9 +55,9 @@ Runner 注册的 Gitea 地址及仓库克隆地址必须能从 B 和作业执行
 
 执行环境需要 Git、Bash、Node.js 20（checkout v4）以及支持 `up --wait --wait-timeout` 的 Docker Compose。本流程不需要 `flock` 或预建 `/opt/wq-alpha`。服务器需能访问 checkout action、基础镜像仓库和依赖源。
 
-在仓库启用 Actions，向 **`prod`** push 会部署；手动运行也须选择 **`prod`**，选择其他分支时本版工作流会跳过部署任务。Checkout 使用本次触发的提交，构建和迁移均在 B 的执行环境完成，无需 A 通过 SSH 再复制代码到 B。
+在仓库启用 Actions，向 **`main`** push 会部署；手动运行也须选择 **`main`**，选择其他分支时本版工作流会跳过部署任务。Checkout 使用本次触发的提交，构建和迁移均在 B 的执行环境完成，无需 A 通过 SSH 再复制代码到 B。
 
-本次修改仅在 `prod` 分支。`main` 中的旧工作流仍配置为 `main` push → `ubuntu-latest`，不会随 `prod` 的修改自动停用；如需停用旧部署，须另行修改 `main` 的工作流。
+发布统一使用 `main` 分支。`tencent-prod` 是 B 服务器的 Runner 标签，与 Git 分支名无关。
 
 Secrets 仍在 A 的 Gitea 仓库设置中管理，通过部署步骤的环境变量注入 B 上的作业，`--env-file /dev/null` 防止误读开发 `.env`。构建可并行；构建完成后，以 B 的 Docker 唯一容器名 `wq-alpha-production-deploy-lock` 互斥保护预检、迁移和服务切换。锁容器不启动、不携带凭据，正常结束或失败时删除；竞争失败的任务不会删除其他任务的锁。
 
@@ -67,7 +67,7 @@ Secrets 仍在 A 的 Gitea 仓库设置中管理，通过部署步骤的环境
 
 将 `PUBLIC_ORIGIN` 对应域名解析到 **B 服务器**，在 B 配置 HTTPS 反向代理，转发至 **`http://127.0.0.1:8112`**（或你的 `WEB_PORT`）。此回环地址只对 B 本机有效；A 上的代理不能通过它访问 B。代理须运行在 B 的宿主机网络中；独立 bridge 容器中的 `127.0.0.1` 不指向宿主机。若使用容器化 1Panel/OpenResty，先确认其网络模式。AI 流式响应需要关闭代理缓冲，并允许长连接/足够长的读取超时。
 
-首次部署建议在 Gitea Actions 页面选择 **`prod`** 分支手动运行工作流，确认任务由 `tencent-prod-runner` 接收。需要在服务器排障运行时，在 **B 服务器的 `prod` 检出目录**中先从安全渠道将上表必填配置注入当前进程环境，再执行：
+首次部署建议在 Gitea Actions 页面选择 **`main`** 分支手动运行工作流，确认任务由 `tencent-prod-runner` 接收。需要在服务器排障运行时，在 **B 服务器的 `main` 检出目录**中先从安全渠道将上表必填配置注入当前进程环境，再执行：
 
 ```bash
 bash scripts/deploy-production.sh