@routerhub/agent-rules 1.5.75 → 1.5.77

package/AGENTS.base.md

@@ -110,30 +110,6 @@ Closes #456
 - 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
 - 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. ⚠️ **强制步骤：修改代码并 push 后，必须立刻在 GitHub PR 页面上点击 Resolve conversation。每 push 一条修复，立即 Resolve 对应的那条评论。不可批量延后、不可等到下一轮 review 后再 Resolve。** Copilot 每次 review 只看当前代码 diff，不依赖 Resolve 状态——代码改了就不会再提同一问题。因此 push = 问题已处理，应立即 Resolve 让 reviewer 知道该条已处理完毕。
-  5. 所有问题处理完毕后，重新请求 Copilot review。
-  6. 重复以上步骤，直到满足以下任一终止条件为止。
-- ⚠️ **强制步骤：每 push 一条修复代码后，必须立刻点击该条评论的 Resolve conversation。不可漏点、不可批量延后。** Copilot 每次 review 只看当前代码 diff——代码改了就不会再提同一问题，因此 push 即意味着问题已处理，应立即 Resolve。
-- 每次修改后提交的 commit 信息必须中文，格式：`修复 Copilot review 问题：[简要描述]`。
-- 如果 Copilot review 连续两轮对同一问题提出类似建议，但代码实际上已正确修复（或该建议本身无道理/属于误报），需在 PR 评论中明确说明原因并直接 Resolve，不再反复修改。
-- ⚠️ **循环终止条件（满足任意一条即停止）**：
-  1. **无新问题**：Copilot review 本轮未提出任何新问题 → 自然终止，循环结束。
-  2. **仅剩可忽略级别建议**：本轮 Copilot review 提出的所有问题均标注了 `nit:`、`optional:`、`question:` 或建议将配置项写入 `.env` 等可忽略类型，无任何 `Request changes` 级别的问题 → 逐条回复说明原因并 Resolve，然后终止循环，无需再请求新一轮 review。
-  3. **衰减到底**：连续两轮 review 的新问题数量均 ≤ 2 个，且均为风格偏好或可争议建议，无实质 bug 或安全风险 → 逐条处理并 Resolve，然后终止循环。
-  4. **硬上限**：循环已达到 5 轮仍无法满足上述条件 → 暂停循环，弹出通知告知用户当前状态（已跑 N 轮、剩余未解决问题数量及摘要），由用户决定是否继续。禁止在用户未确认的情况下自动跑第 6 轮。
-  - **核心原则：Copilot review 的目标是发现真正的代码缺陷，不是追求零评论。** 经过几轮修复后，剩余的 nit/optional 级别建议或可争议的风格偏好属于正常现象，直接标记处理即可，不应无限追逐”零评论”状态。
-- PR 图片文件检查：在 Copilot review 循环中（建议放在开始处理 review 问题之前，或所有 review 问题处理完毕之后），必须检查当前 PR 中是否存在未被引用的图片文件（PNG、JPG、JPEG、GIF、SVG、WebP 等）。检查方式：搜索代码库中是否有任何文件引用了该图片的文件名或路径，若没有任何引用 → 该图片为冗余文件。处理方式：若图片内容需要保留（如截图佐证），则将其转为 base64 data URI 内嵌到对应的 HTML 文档中，然后删除原图片文件；若图片内容无需保留，则直接删除。处理完毕后提交并推送。
-- 可忽略的 review 建议：如果 Copilot review 建议将配置项（API 地址、数据库连接、第三方服务地址等）写入 `.env` 文件，必须直接忽略并在评论中回复说明原因后 Resolve。说明内容：「本项目 `.env` 仅允许配置端口号（如 `PORT`、`API_PORT`），其余配置项一律写死在代码中，敏感信息统一放入 Nacos 配置中心，不放 `.env`。」
-- ⚠️ **强制步骤：重新请求 Copilot review 后，必须主动检查 Copilot 是否已回复。** 不能发完评论就停止等待。检查方式：使用 `gh api` 拉取 PR 的 reviews 和 comments，对比上次已知的最新 review 时间戳。检查频率：每次重新请求 review 后，约 2–3 分钟后主动检查一次；若 Copilot 已生成新 review 则立即进入下一轮处理；若尚未回复，再等 2–3 分钟后再次检查。⚠️ **这里的「最多检查 3 次」仅指每轮 review 请求后的轮询等待次数上限（约 6–9 分钟），与 review 循环的迭代轮数无关——循环轮数由上方终止条件控制，不受此限制。** 等待超时后若仍无回复，告知用户当前状态。
-
 ## 安全
 
 - 用户明确要求上线/部署生产环境时，直接执行，无需二次确认。
@@ -143,6 +119,15 @@ Closes #456
 
 - 新需求先在 `docs/` 写文档，含：目标、范围、功能要求、验收标准。
 
+## ⚠️ Superpowers 需求开发流程（强制）
+
+- ⚠️ **每一个新需求、每一次改动，必须严格按以下 Superpowers 流程执行，不可跳过任何步骤：**
+  1. **确定设计文档**：在写任何代码之前，必须先明确当前改动归属哪个设计文档（`docs/` 目录下的 HTML 文档）。如该文档不存在，必须先创建设计文档，含目标、范围、功能要求、验收标准。
+  2. **准备测试用例**：设计文档确定后，必须先准备测试用例，明确要测什么、怎么测、预期结果是什么。
+  3. **开始写代码**：前两步完成后，才能开始编写代码实现。
+  4. **发新版本**：代码完成并通过测试后，执行 `./release.sh` 发版。
+- ⚠️ **禁止跳过设计文档和测试用例直接写代码。** 没有设计文档和测试用例的改动不得开始编码。
+
 ## 文档格式
 
 - 所有新建文档必须使用 HTML 格式（`.html`），禁止使用 Markdown（`.md`）格式。

package/package.json

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

package/rules/global.md

@@ -112,30 +112,6 @@ Closes #456
 - 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
 - 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. ⚠️ **强制步骤：修改代码并 push 后，必须立刻在 GitHub PR 页面上点击 Resolve conversation。每 push 一条修复，立即 Resolve 对应的那条评论。不可批量延后、不可等到下一轮 review 后再 Resolve。** Copilot 每次 review 只看当前代码 diff，不依赖 Resolve 状态——代码改了就不会再提同一问题。因此 push = 问题已处理，应立即 Resolve 让 reviewer 知道该条已处理完毕。
-  5. 所有问题处理完毕后，重新请求 Copilot review。
-  6. 重复以上步骤，直到满足以下任一终止条件为止。
-- ⚠️ **强制步骤：每 push 一条修复代码后，必须立刻点击该条评论的 Resolve conversation。不可漏点、不可批量延后。** Copilot 每次 review 只看当前代码 diff——代码改了就不会再提同一问题，因此 push 即意味着问题已处理，应立即 Resolve。
-- 每次修改后提交的 commit 信息必须中文，格式：`修复 Copilot review 问题：[简要描述]`。
-- 如果 Copilot review 连续两轮对同一问题提出类似建议，但代码实际上已正确修复（或该建议本身无道理/属于误报），需在 PR 评论中明确说明原因并直接 Resolve，不再反复修改。
-- ⚠️ **循环终止条件（满足任意一条即停止）**：
-  1. **无新问题**：Copilot review 本轮未提出任何新问题 → 自然终止，循环结束。
-  2. **仅剩可忽略级别建议**：本轮 Copilot review 提出的所有问题均标注了 `nit:`、`optional:`、`question:` 或建议将配置项写入 `.env` 等可忽略类型，无任何 `Request changes` 级别的问题 → 逐条回复说明原因并 Resolve，然后终止循环，无需再请求新一轮 review。
-  3. **衰减到底**：连续两轮 review 的新问题数量均 ≤ 2 个，且均为风格偏好或可争议建议，无实质 bug 或安全风险 → 逐条处理并 Resolve，然后终止循环。
-  4. **硬上限**：循环已达到 5 轮仍无法满足上述条件 → 暂停循环，弹出通知告知用户当前状态（已跑 N 轮、剩余未解决问题数量及摘要），由用户决定是否继续。禁止在用户未确认的情况下自动跑第 6 轮。
-  - **核心原则：Copilot review 的目标是发现真正的代码缺陷，不是追求零评论。** 经过几轮修复后，剩余的 nit/optional 级别建议或可争议的风格偏好属于正常现象，直接标记处理即可，不应无限追逐”零评论”状态。
-- PR 图片文件检查：在 Copilot review 循环中（建议放在开始处理 review 问题之前，或所有 review 问题处理完毕之后），必须检查当前 PR 中是否存在未被引用的图片文件（PNG、JPG、JPEG、GIF、SVG、WebP 等）。检查方式：搜索代码库中是否有任何文件引用了该图片的文件名或路径，若没有任何引用 → 该图片为冗余文件。处理方式：若图片内容需要保留（如截图佐证），则将其转为 base64 data URI 内嵌到对应的 HTML 文档中，然后删除原图片文件；若图片内容无需保留，则直接删除。处理完毕后提交并推送。
-- 可忽略的 review 建议：如果 Copilot review 建议将配置项（API 地址、数据库连接、第三方服务地址等）写入 `.env` 文件，必须直接忽略并在评论中回复说明原因后 Resolve。说明内容：「本项目 `.env` 仅允许配置端口号（如 `PORT`、`API_PORT`），其余配置项一律写死在代码中，敏感信息统一放入 Nacos 配置中心，不放 `.env`。」
-- ⚠️ **强制步骤：重新请求 Copilot review 后，必须主动检查 Copilot 是否已回复。** 不能发完评论就停止等待。检查方式：使用 `gh api` 拉取 PR 的 reviews 和 comments，对比上次已知的最新 review 时间戳。检查频率：每次重新请求 review 后，约 2–3 分钟后主动检查一次；若 Copilot 已生成新 review 则立即进入下一轮处理；若尚未回复，再等 2–3 分钟后再次检查。⚠️ **这里的「最多检查 3 次」仅指每轮 review 请求后的轮询等待次数上限（约 6–9 分钟），与 review 循环的迭代轮数无关——循环轮数由上方终止条件控制，不受此限制。** 等待超时后若仍无回复，告知用户当前状态。
-
 ## 安全
 
 - 用户明确要求上线/部署生产环境时，直接执行，无需二次确认。
@@ -145,6 +121,15 @@ Closes #456
 
 - 新需求先在 `docs/` 写文档，含：目标、范围、功能要求、验收标准。
 
+## ⚠️ Superpowers 需求开发流程（强制）
+
+- ⚠️ **每一个新需求、每一次改动，必须严格按以下 Superpowers 流程执行，不可跳过任何步骤：**
+  1. **确定设计文档**：在写任何代码之前，必须先明确当前改动归属哪个设计文档（`docs/` 目录下的 HTML 文档）。如该文档不存在，必须先创建设计文档，含目标、范围、功能要求、验收标准。
+  2. **准备测试用例**：设计文档确定后，必须先准备测试用例，明确要测什么、怎么测、预期结果是什么。
+  3. **开始写代码**：前两步完成后，才能开始编写代码实现。
+  4. **发新版本**：代码完成并通过测试后，执行 `./release.sh` 发版。
+- ⚠️ **禁止跳过设计文档和测试用例直接写代码。** 没有设计文档和测试用例的改动不得开始编码。
+
 ## 文档格式
 
 - 所有新建文档必须使用 HTML 格式（`.html`），禁止使用 Markdown（`.md`）格式。