@routerhub/agent-rules 1.5.178 → 1.5.179

package/AGENTS.base.md

@@ -32,7 +32,7 @@
 2. 实际 DNS 解析（`dig`/`nslookup`）
 3. 云平台控制台（Cloud Run 域名映射、GCLB、Ingress 等）
 - ⚠️ **上述来源都找不到的，就写「待确认」或留空，禁止自行补全。** 错误的推断值比留空危害更大——留空会在运行时报错、立刻暴露；错误的推断值可能静默运行数月后才被发现（如请求打到了错误的环境），排查成本极高。
-- ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署后取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
+- ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署���取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
 - ⚠️ **部署生产前必须做「部署脚本配置 vs 线上实际环境」对账，禁止直接信任部署脚本里的环境值。** 部署脚本常是多人接力维护的产物，其中的 PROJECT / 服务名 / Nacos namespace / 数据库名可能被中途改掉、与线上真实环境脱节——脚本能跑、能编译、甚至部署能成功（Cloud Run 生成新 revision），但流量不接、数据不对，直到有人切流量才暴露（静默脱节）。实例（SolarX 生产事故 2026-08）：部署脚本 `PROJECT=solarisx-api` / Nacos `f8703bd7`，线上实际服务却是 `solarisx-503302` / Nacos `638c11fe`，两套环境并存从未对齐，导致 admin/console 前端 nginx 注入错误后端、gateway 连错库，线上被迫切回旧版。**动手前必做的对账动作**：`gcloud config get-value project` 核对项目、`gcloud run services list` 核对真实服务名、核对 Nacos namespace 与库名；对不上 → 停下来问用户，绝不按脚本直接部署。
 
 ## ⚠️ 可部署性自包含铁律（写代码之前考虑）
@@ -67,7 +67,7 @@
 - ⚠️ **定位并修复根因后，必须清理诊断过程中留下的临时改动**（调试代码、临时开关、测试脚本），不要把绕过方案的残留物留在代码里。
 - **某个工具/脚本报错时，先检查是否有残留的锁文件、临时文件、缓存导致的问题**，清理后重试；仍失败再切换备用方案，不要一遇报错就直接换路子。
 - **长任务或涉及截图等大内容的操作，注意控制单次传入的数据量**（压缩、降低分辨率等），避免不必要地占满上下文。
-- ⚠️ **用户反馈"看起来没生效/没写入"时，先用权威数据源核实**（直连数据库/调对应 API 查，而不是只信一次前端页面截图），前端页面可能存在多个同名视图、未展开的关联表、缓存等歧义，容易把"看错了地方"误判成"修复失败"，也可能反过来把真的失败误判成"看错了"——两种方向都要用权威数据源排除，不能靠肉眼猜。
+- ⚠️ **用户反馈"看起来没生效/没写入"时，先用权威数据源核实**（直连数据库/调对应 API 查，而不是只信一次前端页面截图），前端页面可能存在多个同名视图、未��开的关联表、缓存等歧义，容易把"看错了地方"误判成"修复失败"，也可能反过来把真的失败误判成"看错了"——两种方向都要用权威数据源排除，不能靠肉眼猜。
 - ⚠️ **停用/归档任何仍可能被其他配置引用的共享资源（数据库、开关、服务实例、旧接口等）前，必须先确认所有引用方已经完成切换**，禁止先下线资源、后补救引用；正确顺序是「新资源就位 → 所有引用方切到新资源并验证 → 确认无引用后才下线旧资源」。
 - ⚠️ **对「只增不改」的追加型数据表（日志表、流水表）做分批消费时，禁止用「每次从头查 + LIMIT 截断 + 幂等去重」的无状态写法**。无断点的全量查询每次都会返回最早的一批行（早已消费、被幂等跳过、不产生任何效果），而新行永远排在 LIMIT 之外——扣款/同步在数据量超过单批上限后静默停滞，不报错、不崩溃，余额/进度「悄悄不涨不降」，是最阴险的静默 bug（offset-pagination 饥荒）。正确写法是带「进度断点」的增量查询：**按业务排序键（如时间+ID）记录上次消费位置（游标），下轮用 `WHERE 排序键 > 断点` 的严格排他下界续拉，消费成功后游标单调推进到批次末尾**，保证不重也不漏。判断标准：只要处理逻辑会「跳过已处理的记录」且「数据量可能超过单批上限」，就必须用游标/断点，而非从头扫。
 
@@ -97,7 +97,7 @@
 - ⚠️ **功能验证的第一交付物是可视化证据报告，而不是测试断言。** AI 每做一个功能/修复，必须用「真实数据 + 真实交互 + 可视化证据」证明给用户看（遵循「⚠️ 修复验证铁律」「⚠️ 截图规范」）：
 1. **页面/界面改动** → 打开真实页面，用真实数据走真实交互，全页截图 + 箭头标注关键改动区域；
 2. **涉及 Redis**（缓存、计数器、限流、Session 等）→ 直接查看 Redis 运行时的 key/value（用 Redis for VS Code 插件页截图），A/B 对比改动前后的值；
-3. **涉及数据库** → 直接查看数据库运行时数据（用 SQLTools 插件截图），A/B 对比改动前后的值。
+3. **涉及数据库** → 直接查看数据库运行时数据（用 SQLTools 插件截图），A/B 对比改动前后的���。
    优先让用户配合一起截图（用户是真人验证关卡：截图里的数据必须是真实的，AI 不得用 mock/虚构数据凑证据）。生成的验证报告是给用户看的，用户能一眼判断功能对不对，禁止把「AI 自己写、AI 自己看」的测试断言当作交付完成。
 - ⚠️ **只有以下两类情况才允许写测试用例（有明确触发路径，非默认行为）**：
 1. **时序/并发/缓存失效类逻辑**：问题出在「某个时刻的状态」，截图截不出来（如并发竞态、延迟失效），必须写测试来证明行为正确；
@@ -106,7 +106,7 @@
 - ⚠️ **判断标准：这个功能用户能不能在页面上操作？**
     - 能 → 必须用真实页面交互验证，能模拟用户手动测试就手动，并截图留证；
     - 不能（纯后端接口、定时任务、无页面入口的链路）→ 用运行时真实返回验证（curl/日志/查库/查 Redis），并把结果渲染成可视化证据（暗色终端风格的请求/响应对比 HTML 截图，或 Redis/SQLTools 插件截图）。
-- ⚠️ **验证结论必须基于运行时真实数据，禁止用 mock/虚构数据自测。** 真实数据会暴露边界情况（空值、超长文本、特殊字符、异常关联关系等），虚构数据碰不到这些。测试环境有真实数据时优先用测试环境；测试环境数据不足时，从生产环境脱敏导出。
+- ⚠️ **验证结论必须基于运行时真实数据，禁止用 mock/虚构数据自测。** 真实数据会暴露边界情况（空值、超长文本、特殊字符、异常关联关系等），��构数据碰不到这些。测试环境有真实数据时优先用测试环境；测试环境数据不足时，从生产环境脱敏导出。
 
 ## Git 规范
 
@@ -150,7 +150,7 @@
 2. `git worktree add -b feature/<任务简称> ../<会话标识>-work origin/main`——从 `origin/main` 检出到独立目录并新建分支，当前工作区完全不动。目录名用英文小写中划线（含会话唯一标识），进入前先确认该路径不存在。
 3. 在 worktree 目录内完成改动 → 编译/验证通过 → `git commit` → `git push -u origin feature/<任务简称>`。
 4. 任务结束（提交完成 / PR 合并）后 `git worktree remove ../<会话标识>-work` 清理。一个会话全程只对应一个 worktree。
-- ⚠️ **多副本仓库（A-/B-/C-/M- 前缀）叠���生效**：worktree 建在当前会话所在副本内（选哪个副本由「⚠️ 处理其他项目/副本时统一用 worktree 隔离」规则决定），本条规则负责副本内部的会话隔离，两者不冲突。
+- ⚠️ **多副本仓库（A-/B-/C-/M- 前缀）叠加生效**：worktree 建在当前会话所在副本内（选哪个副本由「⚠️ 处理其他项目/副本时统一用 worktree 隔离」规则决定），本条规则负责副本内部的会话隔离，两者不冲突。
 - ⚠️ **worktree 只隔离「文件与 git」这一层**：端口、数据库、构建缓存、浏览器标签页等外部资源仍按各自规则隔离（如 agent-browser `--namespace`）。两个会话若改同一批文件，编辑阶段互不可见，冲突会推迟到合并回主分支时显式暴露——改动明显重叠的任务应合成一个会话完成，不要拆成两个 worktree 并行。
 
 ## PR 核心要求
@@ -166,7 +166,7 @@
 - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
 - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。
 - ⚠️ **PR 创建即进入可评审状态**：直接创建正式 PR（非 Draft），创建完成、冲突检查与静态编译通过后即可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review。
-- ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须先定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
+- ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须���定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
 - ⚠️ **每次修改 PR 后（含创建 PR、push 新提交、响应 review 意见重新推送等所有改动 PR 的动作之后），都必须检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。主分支随时可能前进，一个创建时无冲突的 PR 可能在后续 push 后悄悄变冲突，因此每次改动 PR 后都必须重新检查，禁止只在创建时查一次就以为高枕无忧。
 - ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
@@ -205,7 +205,7 @@
 - 禁止重复实现，发现重复必须提取封装。同一数据/配置只在一处维护。禁止硬编码数字。
 - 前端：Tailwind CSS 禁止原生 CSS，尺寸单位必须 `rem` 禁止 `px`（1rem=16px）。
 - 测试描述、断言使用中文。测试用例先主流程再边界情况。
-- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）���，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
+- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）时，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
 
 ## 代码质量（一次写对，为结果负责）
 
@@ -352,8 +352,8 @@
 - ⚠️ **请求带了但不支持的参数禁止静默忽略**：必须显式 4xx 报错——静默忽略让客户端误以为参数生效，是沉默失败。
 - ⚠️ **路由/解析 switch default 分支禁止静默 skip+warn**：静默跳过会让路由表悄悄缺模型/缺路由；应显式报错或强告警。路由收窄/拆池前先查全量数据分布。**依赖「客户端/上游不会这么发」假设的丢弃/忽略分支，必须打日志**：假设一旦被打破（上游发来畸形数据），生产可诊断，禁止静默丢弃。
 - ⚠️ **失败路径也要补全归属字段**：成功/失败覆盖一致（失败 usage 事件也要回填 ProviderAccountId 等），否则某个账号持续失败时按账号排查不出来。
-- ⚠️ **清理/剥离函数必须清「实际被填充」的字段**：核对写入方填哪个字段、清理方清哪个字段，二者对齐；只清自己认识的字段、漏掉写入方真正填的，等于没清。
-- ⚠️ **等效路径行为必须对齐**：同一语义的多条路径（chat/responses、流式/非流式、compat/非 compat）改一条的过滤/剥除逻辑必须同步所有等效路径，否则出现「改前隐藏、改后泄漏」的��默回归。
+- ⚠️ **清理/剥离函数必须清「实际被填充」的字段**：核对写入方填哪个字段、清理方清哪个字��，二者对齐；只清自己认识的字段、漏掉写入方真正填的，等于没清。
+- ⚠️ **等效路径行为必须对齐**：同一语义的多条路径（chat/responses、流式/非流式、compat/非 compat）改一条的过滤/剥除逻辑必须同步所有等效路径，否则出现「改前隐藏、改后泄漏」的静默回归。
 - ⚠️ **流式发出首块后失败必须补发显式错误结束事件**：禁止只静默关闭连接——客户端会误判为网络断开或永远等待。
 - ⚠️ **客户端已断开后禁止再向连接写错误响应**：写前检查断开状态；已断开只做结算与上报，不做无用写。
 - ⚠️ **带副作用的函数先判空/前置校验后写**：先写后判空，nil 入参会 panic。
@@ -423,7 +423,7 @@
 ### HTML 文档截图与 curl 命令规范
 
 - ⚠️ **HTML 页面/文档中的外部链接默认用新标签页打开**：所有指向外部资源（其他网站、GitHub 文档、私有仓库 PDF 等）的链接一律写成 `<a target="_blank" rel="noopener" href="...">`，禁止不加 `target` 让用户点击后直接跳出当前页面。**类比：逛商场拿着一份导购地图，每个店名都标着「在新窗口查看」——点一家店不会把你从地图里踢出去，地图还在，能连续逛好几家；不新开窗口的话，每点一家店整张地图就没了，得反复按返回。** `rel="noopener"` 是安全兜底，防止新页面通过 `window.opener` 反向控制当前页（tabnabbing 钓鱼攻击）。
-- ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主��、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
+- ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主体、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
 - ⚠️ **HTML 文档中的截图必须以 `data:image/png;base64,...` 内嵌，禁止用文件路径或相对链接引用外部 PNG 文件。** 文档会被打开、移动、分享，外部图片路径一旦脱离原目录就全部失效，文档里全是裂图。生成文档后，散落的零散 PNG 文件应一并清理，只保留 HTML 本身。
 - ⚠️ **curl 命令必须完整可复制执行，禁止省略关键参数。** 包括但不限于：API Key / Token、请求体中的图片数据、完整的 URL。禁止用 `...` 或「省略其余参数」代替——看的人无法区分「这里不重要所以省略了」还是「这里我不会写所以跳过了」，前者让命令不可执行，后者掩盖了潜在的错误。
 - ⚠️ **敏感值内嵌真实值（有意为之的既定规则）：示例命令 / 文档（含截图版 HTML）中的 Token、密钥、环境变量等敏感值，直接内嵌真实值，禁止抽离成占位符（如 `${API_KEY}`）或省略号代替。**
@@ -682,7 +682,7 @@
 ⚠️ diff 出现带金钱/权限/路由后果的数值判定（`==`、`!=`、`HasPrefix`、`>=`、`default:` 等），必须对判定的反面和补集提三问，确认覆盖再认可：
 
 1. **排除项的孪生项**：`if status == "failed"` 排除后，同级的 `in_progress` / `searching` / 空串走哪个分支？判定的全集是什么？只盯着被排除的那一个，会漏掉其余状态的归属。
-2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」还是「多收」？哪个方向会造成静默的账面偏差。
+2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」��是「多收」？哪个方向会造成静默的账面偏差。
 3. **数值有核对来源吗**：常量数值（如 10_000 / 25_000）是对过上游公开报价，还是随手拍的？没核对来源的定价常量 → 必须报（呼应「环境配置禁止推断」）。
 
 **③ 以行为变更表为主攻目标**

package/package.json

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

package/rules/global.md

@@ -32,7 +32,7 @@ name: "通用规则"
 2. 实际 DNS 解析（`dig`/`nslookup`）
 3. 云平台控制台（Cloud Run 域名映射、GCLB、Ingress 等）
 - ⚠️ **上述来源都找不到的，就写「待确认」或留空，禁止自行补全。** 错误的推断值比留空危害更大——留空会在运行时报错、立刻暴露；错误的推断值可能静默运行数月后才被发现（如请求打到了错误的环境），排查成本极高。
-- ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署后取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
+- ⚠️ **代码中使用环境变量占位符（如 `process.env.XXX`）时，必须同时确认测试/生产部署脚本（或配置中心）已提供该变量的具体值。** 禁止只写占位符不落地——代码能编译不代表部署���取值非空。具体值的存放规则：敏感值（密钥、Token 等）必须配到 Nacos 配置中心，禁止写进部署脚本；非敏感值（域名、地址、端口、外部服务 URL 等）写入测试/生产各自的部署脚本。部署脚本中找不到的值仍按本规则写「待确认」或留空，禁止自行补全。
 - ⚠️ **部署生产前必须做「部署脚本配置 vs 线上实际环境」对账，禁止直接信任部署脚本里的环境值。** 部署脚本常是多人接力维护的产物，其中的 PROJECT / 服务名 / Nacos namespace / 数据库名可能被中途改掉、与线上真实环境脱节——脚本能跑、能编译、甚至部署能成功（Cloud Run 生成新 revision），但流量不接、数据不对，直到有人切流量才暴露（静默脱节）。实例（SolarX 生产事故 2026-08）：部署脚本 `PROJECT=solarisx-api` / Nacos `f8703bd7`，线上实际服务却是 `solarisx-503302` / Nacos `638c11fe`，两套环境并存从未对齐，导致 admin/console 前端 nginx 注入错误后端、gateway 连错库，线上被迫切回旧版。**动手前必做的对账动作**：`gcloud config get-value project` 核对项目、`gcloud run services list` 核对真实服务名、核对 Nacos namespace 与库名；对不上 → 停下来问用户，绝不按脚本直接部署。
 
 ## ⚠️ 可部署性自包含铁律（写代码之前考虑）
@@ -67,7 +67,7 @@ name: "通用规则"
 - ⚠️ **定位并修复根因后，必须清理诊断过程中留下的临时改动**（调试代码、临时开关、测试脚本），不要把绕过方案的残留物留在代码里。
 - **某个工具/脚本报错时，先检查是否有残留的锁文件、临时文件、缓存导致的问题**，清理后重试；仍失败再切换备用方案，不要一遇报错就直接换路子。
 - **长任务或涉及截图等大内容的操作，注意控制单次传入的数据量**（压缩、降低分辨率等），避免不必要地占满上下文。
-- ⚠️ **用户反馈"看起来没生效/没写入"时，先用权威数据源核实**（直连数据库/调对应 API 查，而不是只信一次前端页面截图），前端页面可能存在多个同名视图、未展开的关联表、缓存等歧义，容易把"看错了地方"误判成"修复失败"，也可能反过来把真的失败误判成"看错了"——两种方向都要用权威数据源排除，不能靠肉眼猜。
+- ⚠️ **用户反馈"看起来没生效/没写入"时，先用权威数据源核实**（直连数据库/调对应 API 查，而不是只信一次前端页面截图），前端页面可能存在多个同名视图、未��开的关联表、缓存等歧义，容易把"看错了地方"误判成"修复失败"，也可能反过来把真的失败误判成"看错了"——两种方向都要用权威数据源排除，不能靠肉眼猜。
 - ⚠️ **停用/归档任何仍可能被其他配置引用的共享资源（数据库、开关、服务实例、旧接口等）前，必须先确认所有引用方已经完成切换**，禁止先下线资源、后补救引用；正确顺序是「新资源就位 → 所有引用方切到新资源并验证 → 确认无引用后才下线旧资源」。
 - ⚠️ **对「只增不改」的追加型数据表（日志表、流水表）做分批消费时，禁止用「每次从头查 + LIMIT 截断 + 幂等去重」的无状态写法**。无断点的全量查询每次都会返回最早的一批行（早已消费、被幂等跳过、不产生任何效果），而新行永远排在 LIMIT 之外——扣款/同步在数据量超过单批上限后静默停滞，不报错、不崩溃，余额/进度「悄悄不涨不降」，是最阴险的静默 bug（offset-pagination 饥荒）。正确写法是带「进度断点」的增量查询：**按业务排序键（如时间+ID）记录上次消费位置（游标），下轮用 `WHERE 排序键 > 断点` 的严格排他下界续拉，消费成功后游标单调推进到批次末尾**，保证不重也不漏。判断标准：只要处理逻辑会「跳过已处理的记录」且「数据量可能超过单批上限」，就必须用游标/断点，而非从头扫。
 
@@ -97,7 +97,7 @@ name: "通用规则"
 - ⚠️ **功能验证的第一交付物是可视化证据报告，而不是测试断言。** AI 每做一个功能/修复，必须用「真实数据 + 真实交互 + 可视化证据」证明给用户看（遵循「⚠️ 修复验证铁律」「⚠️ 截图规范」）：
 1. **页面/界面改动** → 打开真实页面，用真实数据走真实交互，全页截图 + 箭头标注关键改动区域；
 2. **涉及 Redis**（缓存、计数器、限流、Session 等）→ 直接查看 Redis 运行时的 key/value（用 Redis for VS Code 插件页截图），A/B 对比改动前后的值；
-3. **涉及数据库** → 直接查看数据库运行时数据（用 SQLTools 插件截图），A/B 对比改动前后的值。
+3. **涉及数据库** → 直接查看数据库运行时数据（用 SQLTools 插件截图），A/B 对比改动前后的���。
    优先让用户配合一起截图（用户是真人验证关卡：截图里的数据必须是真实的，AI 不得用 mock/虚构数据凑证据）。生成的验证报告是给用户看的，用户能一眼判断功能对不对，禁止把「AI 自己写、AI 自己看」的测试断言当作交付完成。
 - ⚠️ **只有以下两类情况才允许写测试用例（有明确触发路径，非默认行为）**：
 1. **时序/并发/缓存失效类逻辑**：问题出在「某个时刻的状态」，截图截不出来（如并发竞态、延迟失效），必须写测试来证明行为正确；
@@ -106,7 +106,7 @@ name: "通用规则"
 - ⚠️ **判断标准：这个功能用户能不能在页面上操作？**
     - 能 → 必须用真实页面交互验证，能模拟用户手动测试就手动，并截图留证；
     - 不能（纯后端接口、定时任务、无页面入口的链路）→ 用运行时真实返回验证（curl/日志/查库/查 Redis），并把结果渲染成可视化证据（暗色终端风格的请求/响应对比 HTML 截图，或 Redis/SQLTools 插件截图）。
-- ⚠️ **验证结论必须基于运行时真实数据，禁止用 mock/虚构数据自测。** 真实数据会暴露边界情况（空值、超长文本、特殊字符、异常关联关系等），虚构数据碰不到这些。测试环境有真实数据时优先用测试环境；测试环境数据不足时，从生产环境脱敏导出。
+- ⚠️ **验证结论必须基于运行时真实数据，禁止用 mock/虚构数据自测。** 真实数据会暴露边界情况（空值、超长文本、特殊字符、异常关联关系等），��构数据碰不到这些。测试环境有真实数据时优先用测试环境；测试环境数据不足时，从生产环境脱敏导出。
 
 ## Git 规范
 
@@ -150,7 +150,7 @@ name: "通用规则"
 2. `git worktree add -b feature/<任务简称> ../<会话标识>-work origin/main`——从 `origin/main` 检出到独立目录并新建分支，当前工作区完全不动。目录名用英文小写中划线（含会话唯一标识），进入前先确认该路径不存在。
 3. 在 worktree 目录内完成改动 → 编译/验证通过 → `git commit` → `git push -u origin feature/<任务简称>`。
 4. 任务结束（提交完成 / PR 合并）后 `git worktree remove ../<会话标识>-work` 清理。一个会话全程只对应一个 worktree。
-- ⚠️ **多副本仓库（A-/B-/C-/M- 前缀）叠���生效**：worktree 建在当前会话所在副本内（选哪个副本由「⚠️ 处理其他项目/副本时统一用 worktree 隔离」规则决定），本条规则负责副本内部的会话隔离，两者不冲突。
+- ⚠️ **多副本仓库（A-/B-/C-/M- 前缀）叠加生效**：worktree 建在当前会话所在副本内（选哪个副本由「⚠️ 处理其他项目/副本时统一用 worktree 隔离」规则决定），本条规则负责副本内部的会话隔离，两者不冲突。
 - ⚠️ **worktree 只隔离「文件与 git」这一层**：端口、数据库、构建缓存、浏览器标签页等外部资源仍按各自规则隔离（如 agent-browser `--namespace`）。两个会话若改同一批文件，编辑阶段互不可见，冲突会推迟到合并回主分支时显式暴露——改动明显重叠的任务应合成一个会话完成，不要拆成两个 worktree 并行。
 
 ## PR 核心要求
@@ -166,7 +166,7 @@ name: "通用规则"
 - ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `![](CDN_URL)` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
 - ⚠️ 创建 PR 使用 `/create-pr` skill（自动生成中文内容 + 效果截图 + CDN 上传）。
 - ⚠️ **PR 创建即进入可评审状态**：直接创建正式 PR（非 Draft），创建完成、冲突检查与静态编译通过后即可直接交付 review，禁止先开 Draft PR、后续再手动标记 Ready for review。
-- ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须先定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
+- ⚠️ **创建 PR 后必须先过 CI 再进入后续流程**：创建完成后第一时间执行 `gh pr checks <PR>`（必要时轮询直到非 `pending`）。若有任一检查 `failure`，必须���定位并修复失败项、推送新提交并复查到全部 `success`，然后才能进入循环 review、测试验证、交付 review 等后续步骤，禁止带红 CI 继续往下走。
 - ⚠️ **每次修改 PR 后（含创建 PR、push 新提交、响应 review 意见重新推送等所有改动 PR 的动作之后），都必须检查与主分支（默认分支）是否有冲突**：用 `gh pr view <PR> --json mergeable -q .mergeable` 检查（`MERGEABLE`=无冲突可合并，`CONFLICTING`=存在冲突，`UNKNOWN`=GitHub 尚未判定，稍后复查）。若存在冲突，必须先解决冲突再交付 review——`git merge origin/main`（或 `git rebase origin/main`）→ 解决冲突文件 → 测试通过 → 推送，确保 PR 处于可合并状态，禁止把带冲突的 PR 抛给 reviewer。主分支随时可能前进，一个创建时无冲突的 PR 可能在后续 push 后悄悄变冲突，因此每次改动 PR 后都必须重新检查，禁止只在创建时查一次就以为高枕无忧。
 - ⚠️ **每次修改 PR 后，除冲突检查外还必须检查 GitHub 静态编译是否通过，通过后发新版本**，三步收尾缺一不可：
 1. **与主分支冲突检查**：按上一条规则执行（`gh pr view <PR> --json mergeable -q .mergeable`），有冲突必须先解决。
@@ -205,7 +205,7 @@ name: "通用规则"
 - 禁止重复实现，发现重复必须提取封装。同一数据/配置只在一处维护。禁止硬编码数字。
 - 前端：Tailwind CSS 禁止原生 CSS，尺寸单位必须 `rem` 禁止 `px`（1rem=16px）。
 - 测试描述、断言使用中文。测试用例先主流程再边界情况。
-- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）���，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
+- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）时，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
 
 ## 代码质量（一次写对，为结果负责）
 
@@ -352,8 +352,8 @@ name: "通用规则"
 - ⚠️ **请求带了但不支持的参数禁止静默忽略**：必须显式 4xx 报错——静默忽略让客户端误以为参数生效，是沉默失败。
 - ⚠️ **路由/解析 switch default 分支禁止静默 skip+warn**：静默跳过会让路由表悄悄缺模型/缺路由；应显式报错或强告警。路由收窄/拆池前先查全量数据分布。**依赖「客户端/上游不会这么发」假设的丢弃/忽略分支，必须打日志**：假设一旦被打破（上游发来畸形数据），生产可诊断，禁止静默丢弃。
 - ⚠️ **失败路径也要补全归属字段**：成功/失败覆盖一致（失败 usage 事件也要回填 ProviderAccountId 等），否则某个账号持续失败时按账号排查不出来。
-- ⚠️ **清理/剥离函数必须清「实际被填充」的字段**：核对写入方填哪个字段、清理方清哪个字段，二者对齐；只清自己认识的字段、漏掉写入方真正填的，等于没清。
-- ⚠️ **等效路径行为必须对齐**：同一语义的多条路径（chat/responses、流式/非流式、compat/非 compat）改一条的过滤/剥除逻辑必须同步所有等效路径，否则出现「改前隐藏、改后泄漏」的��默回归。
+- ⚠️ **清理/剥离函数必须清「实际被填充」的字段**：核对写入方填哪个字段、清理方清哪个字��，二者对齐；只清自己认识的字段、漏掉写入方真正填的，等于没清。
+- ⚠️ **等效路径行为必须对齐**：同一语义的多条路径（chat/responses、流式/非流式、compat/非 compat）改一条的过滤/剥除逻辑必须同步所有等效路径，否则出现「改前隐藏、改后泄漏」的静默回归。
 - ⚠️ **流式发出首块后失败必须补发显式错误结束事件**：禁止只静默关闭连接——客户端会误判为网络断开或永远等待。
 - ⚠️ **客户端已断开后禁止再向连接写错误响应**：写前检查断开状态；已断开只做结算与上报，不做无用写。
 - ⚠️ **带副作用的函数先判空/前置校验后写**：先写后判空，nil 入参会 panic。
@@ -423,7 +423,7 @@ name: "通用规则"
 ### HTML 文档截图与 curl 命令规范
 
 - ⚠️ **HTML 页面/文档中的外部链接默认用新标签页打开**：所有指向外部资源（其他网站、GitHub 文档、私有仓库 PDF 等）的链接一律写成 `<a target="_blank" rel="noopener" href="...">`，禁止不加 `target` 让用户点击后直接跳出当前页面。**类比：逛商场拿着一份导购地图，每个店名都标着「在新窗口查看」——点一家店不会把你从地图里踢出去，地图还在，能连续逛好几家；不新开窗口的话，每点一家店整张地图就没了，得反复按返回。** `rel="noopener"` 是安全兜底，防止新页面通过 `window.opener` 反向控制当前页（tabnabbing 钓鱼攻击）。
-- ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主��、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
+- ⚠️ **截图版 HTML 文档中的截图必须自动加箭头标注**：当用户要求写「截图版 HTML」文档（以截图为主体、图文结合说明实现/操作步骤的文档，如部署实现说明、操作指南等）时，嵌入的每张截图都必须自动用醒目的箭头 + 简短文字标签标注出关键区域/验证点/操作位置，让读者一眼看懂这张图对应文档的哪一步、证明了什么，禁止只贴裸图不标注。箭头标注放在不遮挡原内容的位置。
 - ⚠️ **HTML 文档中的截图必须以 `data:image/png;base64,...` 内嵌，禁止用文件路径或相对链接引用外部 PNG 文件。** 文档会被打开、移动、分享，外部图片路径一旦脱离原目录就全部失效，文档里全是裂图。生成文档后，散落的零散 PNG 文件应一并清理，只保留 HTML 本身。
 - ⚠️ **curl 命令必须完整可复制执行，禁止省略关键参数。** 包括但不限于：API Key / Token、请求体中的图片数据、完整的 URL。禁止用 `...` 或「省略其余参数」代替——看的人无法区分「这里不重要所以省略了」还是「这里我不会写所以跳过了」，前者让命令不可执行，后者掩盖了潜在的错误。
 - ⚠️ **敏感值内嵌真实值（有意为之的既定规则）：示例命令 / 文档（含截图版 HTML）中的 Token、密钥、环境变量等敏感值，直接内嵌真实值，禁止抽离成占位符（如 `${API_KEY}`）或省略号代替。**

package/rules/review-boundary.md

@@ -51,7 +51,7 @@ outputName: "review-boundary"
 ⚠️ diff 出现带金钱/权限/路由后果的数值判定（`==`、`!=`、`HasPrefix`、`>=`、`default:` 等），必须对判定的反面和补集提三问，确认覆盖再认可：
 
 1. **排除项的孪生项**：`if status == "failed"` 排除后，同级的 `in_progress` / `searching` / 空串走哪个分支？判定的全集是什么？只盯着被排除的那一个，会漏掉其余状态的归属。
-2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」还是「多收」？哪个方向会造成静默的账面偏差。
+2. **默认分支的安全方向**：未命中（`default:` / 最后 return）在金钱上朝哪边偏？朝「漏收」��是「多收」？哪个方向会造成静默的账面偏差。
 3. **数值有核对来源吗**：常量数值（如 10_000 / 25_000）是对过上游公开报价，还是随手拍的？没核对来源的定价常量 → 必须报（呼应「环境配置禁止推断」）。
 
 **③ 以行为变更表为主攻目标**