From 1c8e0db256723ad7c59400cb85f3b962c54290ef Mon Sep 17 00:00:00 2001 From: john Date: Wed, 8 Jul 2026 12:25:27 +0800 Subject: [PATCH] docs: clarify development release gates --- AGENTS.md | 17 ++++++++++------- ENGINEERING_WORKFLOW_RULES.md | 6 +++++- 2 files changed, 15 insertions(+), 8 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 1a4a92c..674e112 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -5,13 +5,16 @@ ## 必读：分支与发布闸门 1. 新建分支前必须先同步远端主线，推荐执行 `bash scripts/new-branch.sh feature/xxx`。 -2. 分支代码必须先合并进 `main`，确认 `main` 正常后，才允许发布。 -3. 发布只能从完整 `main` 打整包，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。 -4. 发布前必须确认 CI 已通过，且没有未合并的关键变更。 -5. 发布前必须重新检查当前分支是否落后 `origin/main`。 -6. 发布来源必须是干净、可追溯的 Git commit。 -7. 禁止从脏工作区、detached HEAD、落后主线的分支发布。 -8. 发布前必须执行： +2. 在“修复 bug / 开发中”阶段，默认只允许本地修改、本地运行、本地测试；**没有用户明确批准，不允许 `git push`、不允许生成或发布任何 `103` 相关 runtime/artifact、不允许合并或并入 `main`、不允许触发任何生产动作。** +3. “明确批准”必须是针对下一步动作本身的直接确认，不能把“继续处理”“先看看结果”之类表述解释成 `push`、发版、合并 `main` 的授权。 +4. 即使代码已经改完，也必须先完成与本次改动对应的测试或 verify，并在测试后再次确认，才能决定是否进入 `push`、合并 `main`、`103` 构建或发布等下一步。 +5. 分支代码必须先合并进 `main`，确认 `main` 正常后，才允许发布。 +6. 发布只能从完整 `main` 打整包，禁止从功能分支、单个 commit、单个修复或局部差异单包发布。 +7. 发布前必须确认 CI 已通过，且没有未合并的关键变更。 +8. 发布前必须重新检查当前分支是否落后 `origin/main`。 +9. 发布来源必须是干净、可追溯的 Git commit。 +10. 禁止从脏工作区、detached HEAD、落后主线的分支发布。 +11. 发布前必须执行： ```bash bash scripts/check-release-ready.sh diff --git a/ENGINEERING_WORKFLOW_RULES.md b/ENGINEERING_WORKFLOW_RULES.md index b5f9c9d..e99364e 100644 --- a/ENGINEERING_WORKFLOW_RULES.md +++ b/ENGINEERING_WORKFLOW_RULES.md @@ -33,7 +33,10 @@ git switch -c feature/xxx origin/main 3. 一个 commit 只解决一类问题，避免把功能、环境、运维脚本混成一团。 4. 不允许长期堆积“只有自己知道用途”的未提交改动。 5. `.env`、账号、密钥、运行态数据不进入 Git。 -6. 分支开发中如果主线继续变化，发布前必须重新对齐： +6. 在“修复 bug / 开发中”这一阶段，默认只允许本地修改、本地运行、本地测试；**没有用户明确批准，不允许执行 `git push`、不允许生成或发布任何 `103` 相关 runtime/artifact、不允许合并或并入 `main`、不允许触发任何生产动作。** +7. 上一条中的“明确批准”必须是针对下一步动作本身的直接确认，不能把“继续看看”“先处理一下”之类表述解释成 `push`、发版、合并 `main` 的授权。 +8. 即使代码已经改完，也必须先完成与本次改动对应的测试或 verify，并把结果核对清楚，再决定是否进入 `push`、合并 `main`、`103` 构建或发布等下一步。 +9. 分支开发中如果主线继续变化，发布前必须重新对齐： ```bash git fetch origin --prune @@ -45,6 +48,7 @@ git rebase origin/main 1. 任何会发布的改动，至少要有最小可复现验证。 2. 只看首页 200 不算通过，必须验证本次功能真实路径。 3. 涉及数据结构变化时，必须写清楚兼容方式、回滚方式、补数据方式。 +4. 如果用户已明确要求“先测试、测试后再决定下一步”，则在测试完成并得到新的明确批准前，禁止擅自执行 `git push`、合并 `main`、生成 `103` runtime/artifact、发布或重启线上服务。 ## 4. 发布约束