docs: clarify development release gates

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

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. 发布约束