@routerhub/agent-rules 1.5.143 → 1.5.145

package/AGENTS.base.md

@@ -119,7 +119,12 @@
 ## PR 核心要求
 
 - ⚠️ PR Title / Description / Test Plan 全部中文。
-- ⚠️ 必须附截图作为可视化证据（前后对比、标注改动区域）。
+- ⚠️ **PR 必须附效果截图作为可视化证据，且逐条满足以下硬性要求（缺一不可，禁止跳过）**：
+  - **4K 全页**：截图视口统一 3840px 宽、`fullPage` 截完整页面，禁止用 1920px、禁止只截视口一屏。
+  - **全面多角度**：一张全页图 + 每个关键改动区域的局部放大图，多个改动点要逐个覆盖，确保 reviewer 不看代码就能看全本次全部改动。
+  - **箭头标注**：每张截图必须用醒目箭头 + 简短文字标签标注关键改动区域/验证点（修复前红框/红箭头、修复后绿框/绿箭头），标注放在不遮挡原内容的位置，禁止只贴裸图不标注。
+  - **URL 可见**：截图中必须能看到当前页面 URL，确保证据可追溯。
+  - **前后对比**：必须同时展示修复前与修复后。
 - ⚠️ **截图必须直接内嵌在 PR Description 中，让 reviewer 打开 PR 就能看到效果图（`![](CDN_URL)` 方式渲染为可见图片），禁止只在文字里描述"改动了什么"而不放图，也禁止把截图只作为文件附件/提交到分支目录而不在 PR 正文中引用。** 原因：reviewer 看 PR 的第一眼就是看描述，如果看不到图、只能读文字，完全无法直观感知改动效果；截图不内嵌 = 等于没附。
 - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
 - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。

package/package.json

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

package/rules/global.md

@@ -119,7 +119,12 @@ name: "通用规则"
 ## PR 核心要求
 
 - ⚠️ PR Title / Description / Test Plan 全部中文。
-- ⚠️ 必须附截图作为可视化证据（前后对比、标注改动区域）。
+- ⚠️ **PR 必须附效果截图作为可视化证据，且逐条满足以下硬性要求（缺一不可，禁止跳过）**：
+  - **4K 全页**：截图视口统一 3840px 宽、`fullPage` 截完整页面，禁止用 1920px、禁止只截视口一屏。
+  - **全面多角度**：一张全页图 + 每个关键改动区域的局部放大图，多个改动点要逐个覆盖，确保 reviewer 不看代码就能看全本次全部改动。
+  - **箭头标注**：每张截图必须用醒目箭头 + 简短文字标签标注关键改动区域/验证点（修复前红框/红箭头、修复后绿框/绿箭头），标注放在不遮挡原内容的位置，禁止只贴裸图不标注。
+  - **URL 可见**：截图中必须能看到当前页面 URL，确保证据可追溯。
+  - **前后对比**：必须同时展示修复前与修复后。
 - ⚠️ **截图必须直接内嵌在 PR Description 中，让 reviewer 打开 PR 就能看到效果图（`![](CDN_URL)` 方式渲染为可见图片），禁止只在文字里描述"改动了什么"而不放图，也禁止把截图只作为文件附件/提交到分支目录而不在 PR 正文中引用。** 原因：reviewer 看 PR 的第一眼就是看描述，如果看不到图、只能读文字，完全无法直观感知改动效果；截图不内嵌 = 等于没附。
 - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
 - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。

package/skills/create-pr/SKILL.md

@@ -58,18 +58,21 @@ Closes #issue编号
 1. **截修复后**：浏览器打开改动页面 → 滚动到改动区域 → 全页截图
 2. **截修复前**：临时注释/回退改动代码 → 等 hot reload → 同位置截图 → 恢复代码
    - ⚠️ **若线上数据已变化，导致无法在真实页面复现"修复前"效果**：允许改用等价的纯逻辑对比代替（用新旧两版逻辑代码跑同样的输入数据，把输出结果差异渲染成对比图），但必须在 Description 里明确写清楚"为什么无法复现 + 用了什么替代方案"，禁止因此省略截图或假装能复现。
-3. **生成对比图**：用 sharp 拼接 → 上方红/绿色标注条（❌修复前 / ✅修复后）→ 下方左右并排截图 → 关键改动区域矩形框圈选
+3. **生成对比图**：用 sharp 拼接 → 上方红/绿色标注条（❌修复前 / ✅修复后）→ 下方左右并排截图 → 关键改动区域用箭头 + 红/绿框圈选
 4. **上传 GitHub CDN**（在 PR Description 编辑区直接上传）：
    - 打开目标 PR 页面 → 在 **Description 编辑区**直接上传图片（拖拽/粘贴，或定位 Description 编辑区的隐藏 `input[type=file]` 上传），GitHub 会自动把图片转成 `https://github.com/user-attachments/assets/...` 的 CDN 地址并插入 Description 正文，`![](CDN_URL)` 内嵌
    - ⚠️ **禁止走评论区上传再搬运 CDN URL**：评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多一步手动搬运容易出错
    - ⚠️ **禁止用 `gh gist create --public` 等公开托管服务代替**——这属于未经授权的公开发布
 5. **保存 Description**：确认图片已内嵌进 Description 正文后，保存 PR Description 使图片持久化
 
-**截图规范**：
-- ⚠️ 截图禁止提交到 Git 仓库
-- ⚠️ 必须展示前后对比（修复前红框，修复后绿框）
-- ⚠️ 标注不遮挡页面内容
-- ⚠️ 只截改动相关区域，裁掉无关内容
+**截图硬性规范（PR 效果截图必须逐条满足，缺一不可，禁止跳过）**：
+- ⚠️ **视口宽度统一 4K（3840px 宽）**：用 agent-browser 时先 `agent-browser --cdp 9223 viewport 3840 <height>`（高度按内容给足，如 2400+），或全页截图并保证宽度 3840。禁止用 1920px——1920 宽对复杂内容看不全、看不清。
+- ⚠️ **必须 `fullPage: true` 截完整页面**，不要只截视口的一部分。每个改动点都要覆盖到，禁止只截视口内一屏。
+- ⚠️ **截图必须全面（多图覆盖多个角度）**：一张全页图 + 每个关键改动区域的局部放大图。只截一处、截局部、漏掉改动点都不算全。整份 PR Description 的效果截图要使 reviewer 不看代码就能看全本次改动。
+- ⚠️ **每张截图必须用醒目箭头 + 简短文字标签标注关键改动区域/验证点**，让看的人一眼看懂这张图证明了什么；修复前用红框/红箭头，修复后用绿框/绿箭头，标注放在不遮挡原内容的位置。禁止只贴裸图不标注。
+- ⚠️ **截图中必须能看到当前页面 URL**（浏览器地址栏，或页面顶部叠加 URL 标注），确保证据可追溯。
+- ⚠️ 截图保存到本地磁盘 `docs/` 对应子目录（文件名「编号 + 英文描述」，如 `01-before.png` / `02-after.png`），上传 CDN 后按规则清理临时文件，禁止提交到 Git 仓库。
+- ⚠️ 必须展示前后对比（修复前红框，修复后绿框），标注不遮挡页面内容。
 
 ### 5. 创建 PR
 

package/skills/deploy-test/SKILL.md

@@ -40,6 +40,17 @@ git commit -m "..."  # 使用有意义的提交信息
 git push origin "$ORIGINAL_BRANCH"
 ```
 
+⚠️ **若本次改动经过循环 review（`loop-review` 修复过代码），必须确认所有 review 修复已同步到当前功能分支（PR 对应分支）并推送远程，再进行 test 合并。** 核对方式：
+
+```bash
+# 确认本地功能分支与远程已同步（本地无未推送提交）
+git status
+git log origin/"$ORIGINAL_BRANCH".."$ORIGINAL_BRANCH" --oneline   # 应无输出 = 无未推送提交
+```
+
+- ⚠️ 若 review 修复还没合进当前功能分支 → 先把修复 commit 到功能分支再推送，禁止带着"修复只在 test 分支"的状态去部署。
+- ⚠️ feature 分支与 test 分支两条线必须保持同步：**所有 review 修复代码必须先落 feature 分支（PR 分支），再合并到 test**，缺一不可。
+
 ### 3. test 分支检查
 
 如果 `test` 分支不存在，从主分支创建：

package/skills/loop-review/SKILL.md

@@ -121,6 +121,7 @@ gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq \
 - 判定「值得修」的（无论严重度）→ 每个修复单独 commit，commit 信息用中文，正文引用对应 review 来源
 - 纯建议级且判定值得改的 → 合并为一个 commit
 - 判定「不值得修 / 已处理 / 误报」的 → 按步骤 4 回复，切断 bot 下轮重提
+- ⚠️ **所有修复必须直接 commit 在当前 PR 对应的 feature 分支上**（`git push origin <feature 分支>`），并推送到远程。禁止把 review 修复只放在其他地方（例如直接堆到 test 分支、或修改后不 commit）。**宗旨：feature 分支（PR）与 test 分支两条线保持同步，修复代码同时存在于 feature 分支和 test 分支，缺一不可。**
 
 ### 4. 对「不改」的建议回复（防重复循环，关键）
 
@@ -204,6 +205,7 @@ done
 - ⚠️ **禁止使用 `[skip ci]` / `[skip review]`**——循环依赖「每次 push 触发 review」，跳过就断了。
 - ⚠️ **必须设最大轮数（默认 5；用户明确要求深度循环时最多 8）和等待超时（默认 15 分钟）**，禁止无限循环 / 无限等待。
 - ⚠️ **已修复的功能性问题单独 commit**，禁止与大量建议级改动混在一起，保证每轮 push 的 diff 可读。
+- ⚠️ **每条 review 修复都必须同 commit 回 PR 对应的 feature 分支并推送远程**，不得只推到 test 分支或只放在工作区不 commit。feature 分支与 test 分支两条线必须同步，缺一不可（详见步骤 3）。
 - ⚠️ **等待 bot 审查期间遵守心跳约定**：超过 1 分钟无输出主动说明在等什么。
 - ⚠️ **commit 用中文、禁止 `git push --force`、commit 信息引用对应 review 来源**。
 - ⚠️ **两模型报同一问题合并为一条处理**，不要重复改两遍。