docs: enforce main-only release gate

2026-07-01 23:35:55 +08:00
parent 4fc59729ee
commit 8260ff1e0e
5 changed files with 26 additions and 13 deletions
@@ -14,6 +14,9 @@ alwaysApply: true
 必须遵守：

 - 新建分支必须基于最新 `origin/main`，推荐执行 `bash scripts/new-branch.sh feature/xxx`
+- 分支代码必须先合并进 `main`，确认 `main` 正常后，才允许发布
+- 发布只能从完整 `main` 打整包，禁止从功能分支、单个 commit、单个修复或局部差异单包发布
+- 发布前必须确认 CI 已通过，且没有未合并的关键变更
 - 发布前必须重新检查当前分支是否落后 `origin/main`
 - 发布来源必须是干净、可追溯的 Git commit
 - 禁止从脏工作区、detached HEAD、落后主线的分支发布
@@ -5,10 +5,13 @@
 ## 必读：分支与发布闸门

 1. 新建分支前必须先同步远端主线，推荐执行 `bash scripts/new-branch.sh feature/xxx`。
-2. 发布前必须重新检查当前分支是否落后 `origin/main`。
-3. 发布来源必须是干净、可追溯的 Git commit。
-4. 禁止从脏工作区、detached HEAD、落后主线的分支发布。
-5. 发布前必须执行：
+2. 分支代码必须先合并进 `main`，确认 `main` 正常后，才允许发布。
+3. 发布只能从完整 `main` 打整包，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。
+4. 发布前必须确认 CI 已通过，且没有未合并的关键变更。
+5. 发布前必须重新检查当前分支是否落后 `origin/main`。
+6. 发布来源必须是干净、可追溯的 Git commit。
+7. 禁止从脏工作区、detached HEAD、落后主线的分支发布。
+8. 发布前必须执行：

 ```bash
 bash scripts/check-release-ready.sh
@@ -9,6 +9,9 @@
 ## 强制规则

 - 新建分支必须基于最新 `origin/main`。
+- 分支代码必须先合并进 `main`，确认 `main` 正常后，才允许发布。
+- 发布只能从完整 `main` 打整包，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。
+- 发布前必须确认 CI 已通过，且没有未合并的关键变更。
 - 发布前必须重新检查当前分支是否落后 `origin/main`。
 - 发布来源必须是干净、可追溯的 Git commit。
 - 禁止从脏工作区、detached HEAD、落后主线的分支发布。
@@ -52,15 +52,17 @@ git rebase origin/main
 2. **禁止** SSH 登录 `105` 后直接修改业务源码（含 `scripts/wechat-mp-menu.mjs` 等）；必须先本地 commit，再按发布流程上线。详见 [105 服务器变更规范](docs/105-server-operations.md)。
 3. Portal 生产与测试统一走“本机构建 runtime artifact -> 打包发布”，**禁止**在 `103` 解源码包后 `npm install` / `npm run build`。
 4. Portal 唯一合法生产入口是 `bash scripts/release-portal-runtime-prod.sh`。
-5. 发布来源必须是可追溯 commit，不允许从不明工作区直接出包。
-6. 发布前必须有备份，发布后必须有健康检查和业务验收。
-7. 发布前必须通过统一闸门：
+5. 发布只能从已验证的完整 `main` 打整包；分支代码必须先合并进 `main`，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。
+6. 发布前必须确认 CI 已通过，且没有未合并的关键变更。
+7. 发布来源必须是可追溯 commit，不允许从不明工作区直接出包。
+8. 发布前必须有备份，发布后必须有健康检查和业务验收。
+9. 发布前必须通过统一闸门：

 ```bash
 bash scripts/check-release-ready.sh
 ```

-8. 分支落后 `origin/main`、工作区有未提交或未跟踪改动、处于 detached HEAD、或没有明确批准却从 `main` / `master` 发布，均禁止发版。
+10. 分支落后 `origin/main`、工作区有未提交或未跟踪改动、处于 detached HEAD、或没有明确批准却从 `main` / `master` 发布，均禁止发版。

 ## 5. 文档约束

@@ -9,8 +9,10 @@
 4. `scripts/release-prod.sh`（源码包发布）已停用，不得再用于 Portal；`rsync_to_server.sh` 与任何面向 `105` 的直接同步脚本也只保留为禁用提示。
 5. 发布包不得携带运行态资产；`.env`、`MindSpace/`、`data/`、`users/`、`.tailscale/`、`public/plaza-covers/`、`logs/` 只能从线上现有 live 目录继承。
 6. runtime artifact 必须包含 `server.mjs` 与 `mindspace-sandbox-mcp.mjs`（`sandbox-fs` 扩展依赖的独立子进程入口）。
-7. 每次生产发布前必须先通过 `bash scripts/check-release-ready.sh`，确认分支不落后 `origin/main`、工作区干净、发布来源可追溯。
-8. 每次生产发布前必须先做全量备份；发布失败必须自动回滚到切换前的 live 目录。
-9. 发布清单必须记录：本地 commit、分支、发布时间、发布编号、是否含额外手工环境变更。
-10. Portal 生产验证至少包含 `http://127.0.0.1:8081/api/status` 的 200 健康检查，并补充本次功能对应的业务路径验收；Plaza 仍按各自发布流程单独验收。
-11. 生产热修复也不能绕过这套流程；“为了快”不是跳过备份、跳过 commit、跳过发布包的理由。
+7. 生产发布必须从已验证的完整 `main` 打整包：分支代码必须先合并进 `main`，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。
+8. 每次生产发布前必须确认 CI 已通过，且没有未合并的关键变更。
+9. 每次生产发布前必须先通过 `bash scripts/check-release-ready.sh`，确认分支不落后 `origin/main`、工作区干净、发布来源可追溯。
+10. 每次生产发布前必须先做全量备份；发布失败必须自动回滚到切换前的 live 目录。
+11. 发布清单必须记录：本地 commit、分支、发布时间、发布编号、是否含额外手工环境变更。
+12. Portal 生产验证至少包含 `http://127.0.0.1:8081/api/status` 的 200 健康检查，并补充本次功能对应的业务路径验收；Plaza 仍按各自发布流程单独验收。
+13. 生产热修复也不能绕过这套流程；“为了快”不是跳过备份、跳过 commit、跳过发布包的理由。