npm - @routerhub/agent-rules - Versions diffs - 1.5.60 → 1.5.62 - Mend

@routerhub/agent-rules 1.5.60 → 1.5.62

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/AGENTS.base.md CHANGED Viewed

@@ -25,10 +25,7 @@
 - ⚠️ **强制要求：所有 PR 的 Title、Description、Test Plan 等全部文字内容必须使用中文编写**，方便团队成员阅读理解，禁止使用英文撰写 PR 内容。
 - ⚠️ **强制要求：所有 PR 必须附上相关截图作为可视化证据**，无论是否涉及 UI 改动。截图需包含：功能效果截图、测试结果截图、关键代码变更对比截图等，让 reviewer 无需拉取代码即可直观理解改动内容与验证结果。
 - PR 的目标是让审阅者在不依赖私下沟通的情况下独立理解、验证并放心 Approve；一个好的 PR 必须自解释。
-- 一个 PR 只做一件事（One logical change per PR），必须是完整、独立、可审阅的逻辑改动，禁止把重构、修 bug、加功能混在同一个 PR。
-- PR 应保持小而聚焦，尽量控制在约 200 行以内，超过 500 行应优先拆分；小 PR 审得快、回滚风险低、`git bisect` 定位更精准。
-- 大改动必须拆成 Stacked PRs（例如 PR1 → PR2 → PR3），每个 PR 都要能独立 review、独立合入；底层先合，上层后合。
-- 每个 PR 必须能独立通过编译与测试，禁止出现“这个 PR 编译不过，要等下一个 PR 才能跑”的状态；每一层都应是绿色可发布状态。
+- 每个 PR 必须能独立通过编译与测试，禁止出现”这个 PR 编译不过，要等下一个 PR 才能跑”的状态。
 - PR Title 必须用祈使句、现在时态描述“做了什么”，建议加模块/组件前缀，保持简洁且一行说清。
 - PR Title 示例：`[auth] Fix token refresh race condition on concurrent requests`、`[payments] Add idempotency key to charge API`、`[infra] Migrate cache layer from Redis 6 to Redis 7`。
 - PR Title 禁止使用 `fix bug`、`update code`、`改了一下` 等无法表达实际改动的标题。
@@ -86,8 +83,8 @@ Closes #456
 - 作者不能 Approve 自己的 PR。
 - PR 其他元数据必须完整：Assignees 填负责人，Labels 填类型/优先级/模块，Linked Issues/Projects 关联需求来源与项目看板，Milestone 按需关联发布里程碑。
 - 尚未准备好审阅时必须先开 Draft PR，准备好后再标记 `Ready for review`。
-- 作者提交审阅前必须完成自查：PR 只做一件事；没有夹带格式化、顺手改动等无关改动；Title 清晰；Description 写明 What/Why/How；Test Plan 完整且带证据；已自审 `Files changed`；已移除调试代码、注释代码和无效 TODO；没有泄露密钥、token、内部地址、PII 等敏感信息；已指定合适 reviewer；已关联 issue；本地编译、lint、测试通过；CI status checks 全绿。
-- 满足以下全部条件才允许 Merge：至少一名 reviewer 已 Approve；`CODEOWNERS` required review（如有）已通过；所有 required status checks（构建、单测、lint、静态分析等）全部绿色；所有 review 评论和 `Request changes` 均已解决并 Resolve conversation；分支与目标分支无冲突且已更新到最新；Stacked PR 的所有底层依赖已先行合入。
+- 作者提交审阅前必须完成自查：没有夹带格式化、顺手改动等无关改动；Title 清晰；Description 写明 What/Why/How；Test Plan 完整且带证据；已自审 `Files changed`；已移除调试代码、注释代码和无效 TODO；没有泄露密钥、token、内部地址、PII 等敏感信息；已指定合适 reviewer；已关联 issue；本地编译、lint、测试通过；CI status checks 全绿。
+- 满足以下全部条件才允许 Merge：至少一名 reviewer 已 Approve；`CODEOWNERS` required review（如有）已通过；所有 required status checks（构建、单测、lint、静态分析等）全部绿色；所有 review 评论和 `Request changes` 均已解决并 Resolve conversation；分支与目标分支无冲突且已更新到最新。
 - 建议开启 Branch protection 强制合入门禁，并开启 `Require branches to be up to date`。
 - 团队应统一 Merge 方式，多数情况用 `Squash and merge` 保持主干历史干净；需要保留完整提交历史时再用 merge commit。
 - Reviewer 收到 review 请求后应尽量在 1 个工作日内给出首次反馈。
@@ -99,7 +96,7 @@ Closes #456
 - 有分歧时优先在 PR 上公开讨论，结论必须写回 PR，避免私聊后无记录。
 - 较大方案分歧可以升级为线下或会议讨论，但最终结论必须回写到 PR。
 - 改动后必须使用 `Re-request review` 重新请求审阅，并在评论里简述本次更新改了什么。
-- 必须避免以下反模式：Test Plan 只写“测了没问题”；一个 PR 改 2000 行且跨多个模块；Description 只有“fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
+- 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
 - PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
 ## Copilot PR Review 自动循环
@@ -331,3 +328,15 @@ function FieldTooltip({ text }: { text: string }) {
 	  - **依赖更新**：涉及新的系统依赖（如新的中间件、新的外部服务地址、新的环境变量等）时，必须在部署脚本中自动检查依赖可用性，不存在时部署失败并明确报错，禁止静默跳过等人工发现。
 	  - **缓存/队列/索引重建**：涉及 Redis 缓存结构变更、消息队列 topic 新增、ES 索引 mapping 变更等，必须脚本化并自动执行。
 	  - 以上所有自动化脚本必须在 PR 的 Test Plan 中明确写出执行时机（部署前/部署中/部署后）、执行方式和验证方法，不得只写"部署后手动执行"。
+## 用户通知
+- ⚠️ **强制要求：任务完成或需要用户决策时，必须弹出 macOS 对话框提醒用户，不得静默结束。**
+- 通知场景：任务完成（代码写完、PR 创建、部署完成等）、需要用户决策（等待审批、需要确认、需要输入等）。
+- 通知方式（动态取当前工作目录，适配任意项目）：
+  ```bash
+  osascript -e 'display dialog "消息内容" with title "Claude Code" buttons {"按钮文字"} default button 1 with icon note' && code "$(pwd)" --reuse-window
+  ```
+- 对话框不得自动消失（不加 `giving up after` 参数），必须等用户手动点击。
+- `$(pwd)` 动态取当前会话的工作目录，确保多项目场景下点击按钮后能跳转到正确的 VS Code 窗口。
+- 按钮文字需清晰表明操作（如「收到 👌」「去看看 👀」等）。

package/package.json CHANGED Viewed

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

package/rules/devops.md CHANGED Viewed

@@ -21,3 +21,15 @@ outputName: "devops"
 	  - **依赖更新**：涉及新的系统依赖（如新的中间件、新的外部服务地址、新的环境变量等）时，必须在部署脚本中自动检查依赖可用性，不存在时部署失败并明确报错，禁止静默跳过等人工发现。
 	  - **缓存/队列/索引重建**：涉及 Redis 缓存结构变更、消息队列 topic 新增、ES 索引 mapping 变更等，必须脚本化并自动执行。
 	  - 以上所有自动化脚本必须在 PR 的 Test Plan 中明确写出执行时机（部署前/部署中/部署后）、执行方式和验证方法，不得只写"部署后手动执行"。
+## 用户通知
+- ⚠️ **强制要求：任务完成或需要用户决策时，必须弹出 macOS 对话框提醒用户，不得静默结束。**
+- 通知场景：任务完成（代码写完、PR 创建、部署完成等）、需要用户决策（等待审批、需要确认、需要输入等）。
+- 通知方式（动态取当前工作目录，适配任意项目）：
+  ```bash
+  osascript -e 'display dialog "消息内容" with title "Claude Code" buttons {"按钮文字"} default button 1 with icon note' && code "$(pwd)" --reuse-window
+  ```
+- 对话框不得自动消失（不加 `giving up after` 参数），必须等用户手动点击。
+- `$(pwd)` 动态取当前会话的工作目录，确保多项目场景下点击按钮后能跳转到正确的 VS Code 窗口。
+- 按钮文字需清晰表明操作（如「收到 👌」「去看看 👀」等）。

package/rules/global.md CHANGED Viewed

@@ -25,10 +25,7 @@ name: "通用规则"
 - ⚠️ **强制要求：所有 PR 的 Title、Description、Test Plan 等全部文字内容必须使用中文编写**，方便团队成员阅读理解，禁止使用英文撰写 PR 内容。
 - ⚠️ **强制要求：所有 PR 必须附上相关截图作为可视化证据**，无论是否涉及 UI 改动。截图需包含：功能效果截图、测试结果截图、关键代码变更对比截图等，让 reviewer 无需拉取代码即可直观理解改动内容与验证结果。
 - PR 的目标是让审阅者在不依赖私下沟通的情况下独立理解、验证并放心 Approve；一个好的 PR 必须自解释。
-- 一个 PR 只做一件事（One logical change per PR），必须是完整、独立、可审阅的逻辑改动，禁止把重构、修 bug、加功能混在同一个 PR。
-- PR 应保持小而聚焦，尽量控制在约 200 行以内，超过 500 行应优先拆分；小 PR 审得快、回滚风险低、`git bisect` 定位更精准。
-- 大改动必须拆成 Stacked PRs（例如 PR1 → PR2 → PR3），每个 PR 都要能独立 review、独立合入；底层先合，上层后合。
-- 每个 PR 必须能独立通过编译与测试，禁止出现“这个 PR 编译不过，要等下一个 PR 才能跑”的状态；每一层都应是绿色可发布状态。
+- 每个 PR 必须能独立通过编译与测试，禁止出现”这个 PR 编译不过，要等下一个 PR 才能跑”的状态。
 - PR Title 必须用祈使句、现在时态描述“做了什么”，建议加模块/组件前缀，保持简洁且一行说清。
 - PR Title 示例：`[auth] Fix token refresh race condition on concurrent requests`、`[payments] Add idempotency key to charge API`、`[infra] Migrate cache layer from Redis 6 to Redis 7`。
 - PR Title 禁止使用 `fix bug`、`update code`、`改了一下` 等无法表达实际改动的标题。
@@ -86,8 +83,8 @@ Closes #456
 - 作者不能 Approve 自己的 PR。
 - PR 其他元数据必须完整：Assignees 填负责人，Labels 填类型/优先级/模块，Linked Issues/Projects 关联需求来源与项目看板，Milestone 按需关联发布里程碑。
 - 尚未准备好审阅时必须先开 Draft PR，准备好后再标记 `Ready for review`。
-- 作者提交审阅前必须完成自查：PR 只做一件事；没有夹带格式化、顺手改动等无关改动；Title 清晰；Description 写明 What/Why/How；Test Plan 完整且带证据；已自审 `Files changed`；已移除调试代码、注释代码和无效 TODO；没有泄露密钥、token、内部地址、PII 等敏感信息；已指定合适 reviewer；已关联 issue；本地编译、lint、测试通过；CI status checks 全绿。
-- 满足以下全部条件才允许 Merge：至少一名 reviewer 已 Approve；`CODEOWNERS` required review（如有）已通过；所有 required status checks（构建、单测、lint、静态分析等）全部绿色；所有 review 评论和 `Request changes` 均已解决并 Resolve conversation；分支与目标分支无冲突且已更新到最新；Stacked PR 的所有底层依赖已先行合入。
+- 作者提交审阅前必须完成自查：没有夹带格式化、顺手改动等无关改动；Title 清晰；Description 写明 What/Why/How；Test Plan 完整且带证据；已自审 `Files changed`；已移除调试代码、注释代码和无效 TODO；没有泄露密钥、token、内部地址、PII 等敏感信息；已指定合适 reviewer；已关联 issue；本地编译、lint、测试通过；CI status checks 全绿。
+- 满足以下全部条件才允许 Merge：至少一名 reviewer 已 Approve；`CODEOWNERS` required review（如有）已通过；所有 required status checks（构建、单测、lint、静态分析等）全部绿色；所有 review 评论和 `Request changes` 均已解决并 Resolve conversation；分支与目标分支无冲突且已更新到最新。
 - 建议开启 Branch protection 强制合入门禁，并开启 `Require branches to be up to date`。
 - 团队应统一 Merge 方式，多数情况用 `Squash and merge` 保持主干历史干净；需要保留完整提交历史时再用 merge commit。
 - Reviewer 收到 review 请求后应尽量在 1 个工作日内给出首次反馈。
@@ -99,7 +96,7 @@ Closes #456
 - 有分歧时优先在 PR 上公开讨论，结论必须写回 PR，避免私聊后无记录。
 - 较大方案分歧可以升级为线下或会议讨论，但最终结论必须回写到 PR。
 - 改动后必须使用 `Re-request review` 重新请求审阅，并在评论里简述本次更新改了什么。
-- 必须避免以下反模式：Test Plan 只写“测了没问题”；一个 PR 改 2000 行且跨多个模块；Description 只有“fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
+- 必须避免以下反模式：Test Plan 只写”测了没问题”；Description 只有”fix bug”；CI 红着或跳过检查直接合；把格式化/重命名和逻辑改动混在一起；评论不回复、不 Resolve 就直接重提 review。
 - PR 规范可按团队约定微调字段，但”充分的 Description + 带证据的 Test Plan + 至少一人 Approve + 状态检查全绿才能 Merge”是不可妥协的核心要求。
 ## Copilot PR Review 自动循环