chore(deploy): add same-host staging stack next to production

dev deploys to /opt/dukang-staging (819x, *-test domains); main deploys to production. Staging uses full Mock with shared WeChat app ids.

Co-authored-by: Cursor <cursoragent@cursor.com>

.cursor/skills/dukang-release/SKILL.md

@@ -1,89 +1,89 @@
 ---
 name: dukang-release
 description: >-
-  杜康好客生产发布流程：dev_jacy 提交合并到 dev，并用 deploy.sh 发版。
-  Use when the user says 发布、上传、deploy、上线、发版, or @杜康发布 / @dukang-release.
+  杜康好客发布流程：dev→测试(staging)，main→生产；同机双栈。
+  Use when the user says 发布、上传、deploy、上线、发版、发测试、发生产,
+  or @杜康发布 / @dukang-release.
 ---
 
 # 杜康发布
 
-将已完成改动发到生产（`aliyun-smarthr`）。**仅用户明确要求发布时执行。**
+同机双栈：`/opt/dukang-staging`（测试）与 `/opt/dukang`（生产）。**仅用户明确要求发布时执行。**
 
-## 分支约定
+## 分支与环境
 
-| 分支 | 用途 |
-|------|------|
-| `dev_jacy` | 日常开发 / 提交 |
-| `dev` | **发布分支**（服务器拉这个） |
+| 分支 | 环境 | 目录 | 端口 | 域名 |
+|------|------|------|------|------|
+| `dev_jacy` | 日常开发 | 本机 | — | — |
+| `dev` | **staging 测试** | `/opt/dukang-staging` | 8190–8194 | `*-test.dukanghaoke.com` |
+| `main` | **production 生产** | `/opt/dukang` | 8090–8094 | `*.dukanghaoke.com` |
 
-默认：`dev_jacy` → merge → `dev` → 部署。勿 force push `main`/`dev`。
+默认：`dev_jacy` → merge → `dev` → **发测试**。  
+生产：`dev` 验收通过 → merge → `main` → **发生产**。勿 force push `main`/`dev`。
+
+用户只说「发布」且未指明生产时 → **发测试（staging）**。  
+用户说「发生产 / 上线生产」→ 用 `deploy-prod.sh`。
 
 ## 标准流程（Windows）
 
-PowerShell 下 **分支名必须加引号**（否则 `checkout` 与 `dev` 会被粘成 `checkoutdev`）。
+PowerShell 下 **分支名必须加引号**。
 
-### 1. 提交（在 `dev_jacy`）
-
-```powershell
-git status -sb
-git add <files>
-git commit -m @"
-fix(scope): summary
-
-Optional body.
-"@
-```
-
-- Conventional Commits；不提交 `.env` / `dist` / `node_modules`
-- 用户未要求 commit 时不要擅自提交
-
-### 2. 推送并合并到 `dev`
+### A. 发测试（日常）
 
 ```powershell
+# 1. 在 dev_jacy 提交（用户要求时）
 git push -u origin HEAD
 git checkout "dev"
 git pull origin "dev"
 git merge "dev_jacy" -m "merge(dev_jacy): <简述>"
 git push origin "dev"
 git checkout "dev_jacy"
+
+# 2. 发 staging
+& "C:\Program Files\Git\bin\bash.exe" "<repo>/deploy/deploy-staging.sh" -- --skip-db
 ```
 
-### 3. 远程发版
-
-本机无 WSL bash 时用 **Git Bash**：
+### B. 发生产（验收后）
 
 ```powershell
-& "C:\Program Files\Git\bin\bash.exe" "<repo>/deploy/deploy.sh" --branch "dev" -- --skip-db
+git checkout "main"
+git pull origin "main"
+git merge "dev" -m "merge(dev): <简述>"
+git push origin "main"
+git checkout "dev_jacy"
+
+& "C:\Program Files\Git\bin\bash.exe" "<repo>/deploy/deploy-prod.sh" -- --skip-db
 ```
 
 - 默认加 `--skip-db`（无迁移时）
-- 有 Prisma 迁移时去掉 `--skip-db`，按用户确认是否 `--seed` / `--accept-data-loss`
-- `deploy/deploy.env` 提供 `DEPLOY_HOST` 等（勿提交密钥）
+- 有 Prisma 迁移：先在 **staging** 跑通（可 `--seed` / `--accept-data-loss`），再生产去掉 `--skip-db`
+- Staging 微信：正式号 + 全 Mock（`.env.staging`）
+- `deploy/deploy.env` 提供 `DEPLOY_HOST`、`STAGING_APP_ROOT`、`PROD_APP_ROOT`（勿提交密钥）
 
-### 4. 等待完成
+### 首次启用 Staging
 
-后台跑部署时轮询终端输出，成功标志：
+服务器一次性：`bash deploy/bootstrap-staging.sh`（见脚本说明）→ 配 `.env.staging` → DNS `*-test` → nginx → `deploy-staging.sh -- --seed`
+
+### 同步环境变量
+
+```powershell
+bash deploy/sync-api-env.sh staging
+bash deploy/sync-api-env.sh production
+```
+
+## 等待完成
 
 - 出现 `发版完成`
 - `exit_code: 0`
-- `mini-user(h5): 200`（或对应前端 200）
+- `mini-user(h5): 200` / `api: 200`
 
-说明：API 健康检查短暂 `FAIL`/`000` 多为重启中，以 `发版完成` + `exit_code: 0` 为准。
+## 回复用户
 
-### 5. 回复用户
-
-一句说明：已合并 commit、发版结果、建议微信强刷验证。
-
-## 常用变体
-
-| 场景 | 做法 |
-|------|------|
-| 仅部署已推送的 `dev` | 跳过 commit/merge，直接跑 `deploy.sh --branch "dev" -- --skip-db` |
-| 检查服务器 | `deploy.sh --branch "dev" --check` |
-| 含 DB | `deploy.sh --branch "dev" --`（无 skip-db）或按用户给 seed 参数 |
+说明：环境（测试/生产）、commit、建议硬刷验证。测试后台有橙色「测试环境」条。
 
 ## 禁止
 
-- 不 amend 已推送 commit；不 force push `main`/`master`/`dev`
-- 不把 `.env` / 私钥打进仓库
-- 用户只说「修好」未说发布时 → **只改代码，不发版**
+- 不 amend 已推送 commit；不 force push `main`/`dev`
+- 不把 `.env*` 私钥打进仓库
+- **禁止**再用 `dev` 直发生产
+- 用户只说「修好」未说发布 → 只改代码，不发版