@routerhub/agent-rules 1.5.127 → 1.5.129
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.
- package/AGENTS.base.md +5 -2
- package/package.json +1 -1
- package/rules/global.md +5 -2
package/AGENTS.base.md
CHANGED
|
@@ -109,7 +109,7 @@
|
|
|
109
109
|
|
|
110
110
|
## PR 核心要求
|
|
111
111
|
|
|
112
|
-
- ⚠️ PR Title / Description / Test Plan
|
|
112
|
+
- ⚠️ PR Title / Description / Test Plan 全部中文。
|
|
113
113
|
- ⚠️ 必须附截图作为可视化证据（前后对比、标注改动区域）。
|
|
114
114
|
- ⚠️ **截图必须直接内嵌在 PR Description 中，让 reviewer 打开 PR 就能看到效果图（`` 方式渲染为可见图片），禁止只在文字里描述"改动了什么"而不放图，也禁止把截图只作为文件附件/提交到分支目录而不在 PR 正文中引用。** 原因：reviewer 看 PR 的第一眼就是看描述，如果看不到图、只能读文字，完全无法直观感知改动效果；截图不内嵌 = 等于没附。
|
|
115
115
|
- ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
|
|
@@ -133,9 +133,12 @@
|
|
|
133
133
|
- 测试描述、断言使用中文。测试用例先主流程再边界情况。
|
|
134
134
|
- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）时，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
|
|
135
135
|
|
|
136
|
-
##
|
|
136
|
+
## 代码质量（一次写对，为结果负责）
|
|
137
137
|
|
|
138
138
|
- ⚠️ 为上线结果负责：把每一行代码都当作「这就是要交付给用户的最终版」来写，而非「先写着、等 review 再挑」。落笔前想清楚最优路径，写完自问有没有重复可提取、能不能更简单、命名是否达意，自己一眼能看出的改进当场改掉，不留给 review 兜底。
|
|
139
|
+
- ⚠️ 落笔前先做设计权衡：动手前先给出 2~3 个实现方案和各自的代价取舍，选最优再写，不要一头扎进实现。复杂度高的地方（并发、锁、资源、边界等），尤其要先把「最坏情况」想全再动笔。
|
|
140
|
+
- ⚠️ 提交前按「最坏情况」自检：边界值、空值、异常路径、并发/重复触发、重试、依赖不可用（Redis/DB/网络）时，行为是否仍正确、会不会出错或重复执行。
|
|
141
|
+
- ⚠️ 沉淀反模式：每次 review 暴露的设计问题（锁粒度、职责划分、重复实现等），提炼成通用的「反模式」记录，下次写同类代码时自发对照，避免重犯。
|
|
139
142
|
|
|
140
143
|
## ⚠️ 数据链路改动核对铁律
|
|
141
144
|
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -109,7 +109,7 @@ name: "通用规则"
|
|
|
109
109
|
|
|
110
110
|
## PR 核心要求
|
|
111
111
|
|
|
112
|
-
- ⚠️ PR Title / Description / Test Plan
|
|
112
|
+
- ⚠️ PR Title / Description / Test Plan 全部中文。
|
|
113
113
|
- ⚠️ 必须附截图作为可视化证据（前后对比、标注改动区域）。
|
|
114
114
|
- ⚠️ **截图必须直接内嵌在 PR Description 中，让 reviewer 打开 PR 就能看到效果图（`` 方式渲染为可见图片），禁止只在文字里描述"改动了什么"而不放图，也禁止把截图只作为文件附件/提交到分支目录而不在 PR 正文中引用。** 原因：reviewer 看 PR 的第一眼就是看描述，如果看不到图、只能读文字，完全无法直观感知改动效果；截图不内嵌 = 等于没附。
|
|
115
115
|
- ⚠️ **截图必须通过 PR Description 编辑区直接上传（拖拽/粘贴/文件选择按钮），禁止走评论区 `input[type=file]` 上传后再搬运 CDN URL。** 原因：PR Description 编辑区本身支持图片拖拽上传、自动转为 `` 内嵌，一步到位；走评论区上传需要多一步「提交评论 → 复制 URL → 粘贴到 Description」，产生的临时图片评论会留在 PR 对话里干扰 reviewer 阅读，且多了一步手动搬运、容易出错。
|
|
@@ -133,9 +133,12 @@ name: "通用规则"
|
|
|
133
133
|
- 测试描述、断言使用中文。测试用例先主流程再边界情况。
|
|
134
134
|
- ⚠️ 代码中出现晦涩难懂的技术名词（如 X-Request-ID、反向代理、CORS、JWT、CSRF、幂等、熔断、降级等）时，必须附加中文注解。注解分两层：（1）先说明该名词是什么功能、解决什么问题；（2）再解释其中特殊因子/字段的具体作用。目的是让不熟悉该领域的人也能看懂代码逻辑，不要求已有背景知识。
|
|
135
135
|
|
|
136
|
-
##
|
|
136
|
+
## 代码质量（一次写对，为结果负责）
|
|
137
137
|
|
|
138
138
|
- ⚠️ 为上线结果负责：把每一行代码都当作「这就是要交付给用户的最终版」来写，而非「先写着、等 review 再挑」。落笔前想清楚最优路径，写完自问有没有重复可提取、能不能更简单、命名是否达意，自己一眼能看出的改进当场改掉，不留给 review 兜底。
|
|
139
|
+
- ⚠️ 落笔前先做设计权衡：动手前先给出 2~3 个实现方案和各自的代价取舍，选最优再写，不要一头扎进实现。复杂度高的地方（并发、锁、资源、边界等），尤其要先把「最坏情况」想全再动笔。
|
|
140
|
+
- ⚠️ 提交前按「最坏情况」自检：边界值、空值、异常路径、并发/重复触发、重试、依赖不可用（Redis/DB/网络）时，行为是否仍正确、会不会出错或重复执行。
|
|
141
|
+
- ⚠️ 沉淀反模式：每次 review 暴露的设计问题（锁粒度、职责划分、重复实现等），提炼成通用的「反模式」记录，下次写同类代码时自发对照，避免重犯。
|
|
139
142
|
|
|
140
143
|
## ⚠️ 数据链路改动核对铁律
|
|
141
144
|
|