@routerhub/agent-rules 1.5.114 → 1.5.116

package/AGENTS.base.md

@@ -161,6 +161,21 @@
 - 值传递优先，软删除用 `gorm.DeletedAt`（禁止 `*time.Time`）。
 - 禁止无条件执行 GORM AutoMigrate，必须由开关控制，默认关闭。
 
+## ⚠️ 数据存储选型铁律（Redis vs PostgreSQL）
+
+- ⚠️ **能交给 Redis 的写入就交给 Redis，避免用 PostgreSQL 硬扛高频写入**（PG 面向持久化与复杂查询，高频写入场景性能差）。但 Redis 与 PG 不是同类存储，**必须区分场景使用，禁止无脑替代**。
+- **Redis 优先的场景**（高频写、可容忍丢失、可重建的数据）：
+  - 缓存（接口缓存、配置缓存、热点数据）
+  - 计数器、排行榜、PV/UV、点赞数等
+  - 限流（滑动窗口、令牌桶）、分布式锁
+  - 会话/Session、验证码等短时效数据（天然依赖 TTL 过期）
+- **PostgreSQL 保留的场景**（不能丢、要按条件查、要事务）：
+  - 业务主体数据（订单、用户、商品、账单等需要事务与持久化的数据）
+  - 需要复杂 SQL 查询、联表、报表统计的数据
+  - 需要长期保留、生命周期远大于缓存时长的数据
+- ⚠️ **判定标准**：落库前先问三个问题——「这份数据丢了行不行？」「需不需要按条件查？」「需不需要事务？」。只要有一个答案是「需要/不行」，就必须用 PostgreSQL；三个都是「可以丢 / 不用查 / 不用事务」，才优先用 Redis。
+- ⚠️ **Redis 只能做加速层，禁止作为唯一数据源承载不可重建的业务数据**——默认未开启持久化时进程重启数据即丢，Redis 中的数据必须能由上游（数据库/消息队列）重建。
+
 ## ⚠️ 数据库 DELETE 铁律（最高级别，所有写操作前必检）
 
 - ⚠️ **DELETE 是数据库中唯一不可逆的写操作**（INSERT 可以删、UPDATE 可以回改，DELETE 执行后数据消失，只有备份能救）。因此 DELETE 的每一条都必须经过严格的「副作用范围检查」：

package/package.json

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

package/rules/global.md

@@ -161,6 +161,21 @@ name: "通用规则"
 - 值传递优先，软删除用 `gorm.DeletedAt`（禁止 `*time.Time`）。
 - 禁止无条件执行 GORM AutoMigrate，必须由开关控制，默认关闭。
 
+## ⚠️ 数据存储选型铁律（Redis vs PostgreSQL）
+
+- ⚠️ **能交给 Redis 的写入就交给 Redis，避免用 PostgreSQL 硬扛高频写入**（PG 面向持久化与复杂查询，高频写入场景性能差）。但 Redis 与 PG 不是同类存储，**必须区分场景使用，禁止无脑替代**。
+- **Redis 优先的场景**（高频写、可容忍丢失、可重建的数据）：
+  - 缓存（接口缓存、配置缓存、热点数据）
+  - 计数器、排行榜、PV/UV、点赞数等
+  - 限流（滑动窗口、令牌桶）、分布式锁
+  - 会话/Session、验证码等短时效数据（天然依赖 TTL 过期）
+- **PostgreSQL 保留的场景**（不能丢、要按条件查、要事务）：
+  - 业务主体数据（订单、用户、商品、账单等需要事务与持久化的数据）
+  - 需要复杂 SQL 查询、联表、报表统计的数据
+  - 需要长期保留、生命周期远大于缓存时长的数据
+- ⚠️ **判定标准**：落库前先问三个问题——「这份数据丢了行不行？」「需不需要按条件查？」「需不需要事务？」。只要有一个答案是「需要/不行」，就必须用 PostgreSQL；三个都是「可以丢 / 不用查 / 不用事务」，才优先用 Redis。
+- ⚠️ **Redis 只能做加速层，禁止作为唯一数据源承载不可重建的业务数据**——默认未开启持久化时进程重启数据即丢，Redis 中的数据必须能由上游（数据库/消息队列）重建。
+
 ## ⚠️ 数据库 DELETE 铁律（最高级别，所有写操作前必检）
 
 - ⚠️ **DELETE 是数据库中唯一不可逆的写操作**（INSERT 可以删、UPDATE 可以回改，DELETE 执行后数据消失，只有备份能救）。因此 DELETE 的每一条都必须经过严格的「副作用范围检查」：

package/skills/loop-review/SKILL.md

@@ -168,7 +168,7 @@ done
 
 - **本轮没有任何「值得修」的新问题**（要么 bot 没提新的，要么新问题全是已处理/口味/误报，全部有回复落点）→ 循环结束 ✅，进入步骤 7 收尾
 - **本轮有「值得修」的新问题** → 已修复并回复，回到步骤 5 进入下一轮
-- **达到最大轮数（默认 3 轮）仍有值得修的新问题** → 停止循环，把剩余问题逐条列给用户，由用户决定（继续 / 放过 / 人工处理），禁止无限循环
+- **达到最大轮数（默认 5 轮；用户明确要求深度循环时最多 8 轮）仍有值得修的新问题** → 停止循环，把剩余问题逐条列给用户，由用户决定（继续 / 放过 / 人工处理），禁止无限循环
 
 ⚠️ 每轮结束向用户汇报：本轮发现什么、改了什么、拒绝了什么、剩什么。
 
@@ -190,7 +190,7 @@ done
 | 条件 | 行为 |
 |------|------|
 | 本轮没有任何「值得修」的新问题 | ✅ 结束（注意：**不是**「严重度清零」——bot 总会挂着几条我们判断过不值得修的） |
-| 达到最大轮数（默认 3 轮） | ⛔ 停止，剩余问题交用户决定 |
+| 达到最大轮数（默认 5 轮；用户明确要求深度循环时最多 8 轮） | ⛔ 停止，剩余问题交用户决定 |
 | 等待新 review 超时（默认 15 分钟） | ⏸ 停止等待，询问用户 |
 | 连续两轮 review 内容完全相同（bot 疑似卡死） | ⛔ 停止，向用户报告 |
 
@@ -201,7 +201,7 @@ done
 - ⚠️ **每条 review 建议必须有落点**（修复 commit / Won't fix / 误报回复），禁止静默跳过——不回复 bot 下轮必重提，循环无限。
 - ⚠️ **每轮先确认哪些是上一轮已处理过的**，一律不重复改，直接回复「已修复于 <hash>」。
 - ⚠️ **禁止使用 `[skip ci]` / `[skip review]`**——循环依赖「每次 push 触发 review」，跳过就断了。
-- ⚠️ **必须设最大轮数（默认 3）和等待超时（默认 15 分钟）**，禁止无限循环 / 无限等待。
+- ⚠️ **必须设最大轮数（默认 5；用户明确要求深度循环时最多 8）和等待超时（默认 15 分钟）**，禁止无限循环 / 无限等待。
 - ⚠️ **已修复的功能性问题单独 commit**，禁止与大量建议级改动混在一起，保证每轮 push 的 diff 可读。
 - ⚠️ **等待 bot 审查期间遵守心跳约定**：超过 1 分钟无输出主动说明在等什么。
 - ⚠️ **commit 用中文、禁止 `git push --force`、commit 信息引用对应 review 来源**。