@routerhub/agent-rules 1.5.221 → 1.5.222

package/AGENTS.base.md

@@ -329,6 +329,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（唯一例外：发版载体仓库执行 `./release.sh` 时会在 main 上生成「发布 vX.Y.Z」提交；非发版载体仓库没有该脚本，不存在这个例外）。
 - ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
 - ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
+- ⚠️ **所有 PR 一律以仓库默认分支（`main`/`master`）为 base，禁止创建「其他分支合并到其他分支」的 PR。** 功能分支的去向只有一条：合回默认分支；不允许出现 `feature/* → test`、`feature/* → develop`、`feature/* → feature/*` 这类以非默认分支为 base 的 PR。需要另一分支的改动时，先把该分支合回默认分支，再从默认分支拉新分支——禁止靠「分支合分支」把改动横向搬运（那样改动绕过了默认分支，主干永远拿不到它，后续发版与团队其他人的分支都会与之脱节）。⚠️ **发现 PR 的 base 不是默认分支（自己建的或别人的），先把 base 改回默认分支（`gh pr edit <PR> --base main`）再继续**，禁止顺着错误的 base 把 PR 合到非默认分支上。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
 - ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。
 

package/CHANGELOG.md

@@ -2,7 +2,7 @@
 
 所有对 @routerhub/agent-rules 的重大更改都会记录在这个文件中。
 
-## [1.5.220] - 2026-09-16
+## [1.5.221] - 2026-09-16
 
 ### Fixed
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@routerhub/agent-rules",
-  "version": "1.5.221",
+  "version": "1.5.222",
   "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
   "main": "AGENTS.base.md",
   "bin": {

package/rules/global.md

@@ -329,6 +329,7 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
 - ⚠️ **一般情况下，主分支（`main`）不允许直接提交代码**：日常改动必须先直接拉取远程主分支 → 创建功能分支 → 提交 → 推送 → PR 合并回主分支，禁止直接 commit/push 到 main（唯一例外：发版载体仓库执行 `./release.sh` 时会在 main 上生成「发布 vX.Y.Z」提交；非发版载体仓库没有该脚本，不存在这个例外）。
 - ⚠️ **从主分支拉/建功能分支之前，必须先直接拉取远程主分支（`git pull origin main`）**，确保基于最新的远程主分支拉分支，禁止基于过期的本地主分支创建分支。
 - ⚠️ **可评审 PR 的合并目标永远是仓库默认分支（如 `main`/`master`），不是 `test`**。`test` 分支只用于部署测试环境，只能通过 `/deploy-test` skill 直接 `merge` 更新（见「部署规则」），不发 PR、不走 code review；`test` 分支同样禁止直接提交代码。commit 必须中文，禁止 `git push --force`。
+- ⚠️ **所有 PR 一律以仓库默认分支（`main`/`master`）为 base，禁止创建「其他分支合并到其他分支」的 PR。** 功能分支的去向只有一条：合回默认分支；不允许出现 `feature/* → test`、`feature/* → develop`、`feature/* → feature/*` 这类以非默认分支为 base 的 PR。需要另一分支的改动时，先把该分支合回默认分支，再从默认分支拉新分支——禁止靠「分支合分支」把改动横向搬运（那样改动绕过了默认分支，主干永远拿不到它，后续发版与团队其他人的分支都会与之脱节）。⚠️ **发现 PR 的 base 不是默认分支（自己建的或别人的），先把 base 改回默认分支（`gh pr edit <PR> --base main`）再继续**，禁止顺着错误的 base 把 PR 合到非默认分支上。
 - ⚠️ **已推送到远程的提交需要撤销时，必须用 `git revert`，禁止用 `git push --force` 覆盖远程历史。** `git revert` 会创建一条新的撤销提交，保留完整的操作记录，不影响其他协作者的本地分支；`git push --force` 会破坏远程历史，导致其他人的本地分支与远程脱节，极易引发合并冲突或丢失他人提交。
 - ⚠️ **提交并推送代码后，若发现与主分支存在冲突，必须主动解决**，不能推送完就算完事、把冲突留给别人处理。