@routerhub/agent-rules 1.5.39 → 1.5.41

package/AGENTS.base.md

@@ -93,7 +93,22 @@ Closes #456
 - 较大方案分歧可以升级为线下或会议讨论，但最终结论必须回写到 PR。
 - 改动后必须使用 `Re-request review` 重新请求审阅，并在评论里简述本次更新改了什么。
 - 必须避免以下反模式：Test Plan 只写“测了没问题”；一个 PR 改 2000 行且跨多个模块；Description 只有“fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
-- PR 规范可按团队约定微调字段，但“充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
+- PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
+
+## Copilot PR Review 自动循环
+
+- 用户说”生成一个 PR”时，在创建 PR 之后必须主动打开该 PR 页面，检查 Copilot 是否已自动 review 并发现问题。
+- 用户说”Copilot review 出了一些问题”时，同样触发以下循环流程。
+- Copilot review 循环流程：
+  1. 打开 PR 页面，逐一查看 Copilot review 提出的每一条问题。
+  2. 逐条判断问题是否有道理：确实存在的代码缺陷、逻辑错误、安全风险、性能问题等 → 必须修复；误报、与需求不符、风格偏好无实质影响等 → 在评论中回复解释为何不改，然后 Resolve。
+  3. 对于有道理的问题，直接修改代码、提交并推送到该 PR 分支。
+  4. 在 PR 评论中回复该问题（如”已修复”或简要说明修改内容），然后点击 Resolve conversation。
+  5. 所有问题处理完毕后，重新请求 Copilot review。
+  6. 重复以上步骤，直到 Copilot review 不再提出新问题为止。
+- 每一条 Copilot review 评论处理完毕后，必须点击 **Resolve conversation**，不能只回复不 Resolve。不点 Resolve 会导致该评论一直处于未解决状态，无法判断是否已完成处理。
+- 每次修改后提交的 commit 信息必须中文，格式：`修复 Copilot review 问题：[简要描述]`。
+- 如果 Copilot review 连续两轮提出同一问题但实际已修复或无道理，需在 PR 评论中明确说明原因并直接 Resolve，不再反复修改。
 
 ## 安全
 

package/package.json

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

package/rules/devops.md

@@ -9,3 +9,8 @@ outputName: "devops"
 - 部署方式因项目而异，具体部署规则请在项目 `AGENTS.private.md` 中按需定义。
 - `.env` 文件中仅允许配置端口号（如 `PORT`、`API_PORT` 等），其余所有配置项（API 地址、数据库连接、第三方服务地址等）必须直接写死到代码中。
 - 密钥、Token、密码、证书等敏感信息不得写入 `.env` 或代码中，必须统一配置到 Nacos 配置中心，应用启动时从 Nacos 拉取。
+- 用户说「部署测试环境」时，必须按以下步骤执行：
+  1. **test 分支检查**：如果当前项目的 `test` 分支不存在，从主分支（`main` 或 `master`）创建 `test` 分支并推送到远程。
+  2. **合并当前分支到 test**：将当前功能分支合并到 `test` 分支。
+  3. **部署 test 分支**：按当前项目自己的部署方式部署 `test` 分支（如 Cloud Run 部署、容器部署、npm publish 等）。
+  4. **发新版本**：按当前项目自己的发版规则发布新版本（如 `./release.sh`、自动递增版本号等）。

package/rules/frontend.md

@@ -50,6 +50,7 @@ outputName: "frontend"
 
 - 依赖安装统一 `pnpm`，禁止 `npm install`/`yarn install`。
 - 写完代码先 `npm run format`，再 `npm run build`，构建通过才可发版。
+- AI 改完代码后禁止自动执行任何格式化命令（包括但不限于 `npm run format`、`pnpm run format`、`prettier`、`eslint --fix` 等），避免产生仅含格式差异的文件变更，防止 PR 中混入大量与业务逻辑无关的格式化 diff；仅在用户明确要求格式化时才执行格式化操作。
 
 ## 测试
 

package/rules/global.md

@@ -93,7 +93,22 @@ Closes #456
 - 较大方案分歧可以升级为线下或会议讨论，但最终结论必须回写到 PR。
 - 改动后必须使用 `Re-request review` 重新请求审阅，并在评论里简述本次更新改了什么。
 - 必须避免以下反模式：Test Plan 只写“测了没问题”；一个 PR 改 2000 行且跨多个模块；Description 只有“fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
-- PR 规范可按团队约定微调字段，但“充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
+- PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
+
+## Copilot PR Review 自动循环
+
+- 用户说”生成一个 PR”时，在创建 PR 之后必须主动打开该 PR 页面，检查 Copilot 是否已自动 review 并发现问题。
+- 用户说”Copilot review 出了一些问题”时，同样触发以下循环流程。
+- Copilot review 循环流程：
+  1. 打开 PR 页面，逐一查看 Copilot review 提出的每一条问题。
+  2. 逐条判断问题是否有道理：确实存在的代码缺陷、逻辑错误、安全风险、性能问题等 → 必须修复；误报、与需求不符、风格偏好无实质影响等 → 在评论中回复解释为何不改，然后 Resolve。
+  3. 对于有道理的问题，直接修改代码、提交并推送到该 PR 分支。
+  4. 在 PR 评论中回复该问题（如”已修复”或简要说明修改内容），然后点击 Resolve conversation。
+  5. 所有问题处理完毕后，重新请求 Copilot review。
+  6. 重复以上步骤，直到 Copilot review 不再提出新问题为止。
+- 每一条 Copilot review 评论处理完毕后，必须点击 **Resolve conversation**，不能只回复不 Resolve。不点 Resolve 会导致该评论一直处于未解决状态，无法判断是否已完成处理。
+- 每次修改后提交的 commit 信息必须中文，格式：`修复 Copilot review 问题：[简要描述]`。
+- 如果 Copilot review 连续两轮提出同一问题但实际已修复或无道理，需在 PR 评论中明确说明原因并直接 Resolve，不再反复修改。
 
 ## 安全