@routerhub/agent-rules 1.5.213 → 1.5.214
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 +12 -0
- package/package.json +1 -1
- package/rules/global.md +12 -0
- package/skills/create-doc/SKILL.md +2 -0
- package/skills/forensic-report/SKILL.md +10 -9
package/AGENTS.base.md
CHANGED
|
@@ -259,6 +259,18 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
|
|
|
259
259
|
- ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
|
|
260
260
|
- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
|
|
261
261
|
|
|
262
|
+
## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 证据 三段式）
|
|
263
|
+
|
|
264
|
+
- ⚠️ **核心认知：报告的读者是需求方，而他判断「做没做到」的唯一依据是需求原话。** 报告只写「我们做了什么」，等于让读者自己拿记忆里的需求去比对满篇实现描述——需求→实现之间隔着产品转述、口头对齐、中途口径变化，他拼错了图就会以为某条没做（或以为做了其实没做）。**把原话摆在每段实现旁边，读者不用回忆、不用拼图，逐句对一眼即可。**
|
|
265
|
+
- **类比：报销单不能只写「我花了多少钱」，得把发票贴在你填的每一个数字旁边——审核的人对着发票核你填的数，而不是凭你的口头描述签字。**
|
|
266
|
+
- ⚠️ **硬性要求（交付任何需求实现 / 修复验证 / 取证报告时逐条满足，缺一不算完成）：**
|
|
267
|
+
1. **逐字引用需求原文**：从需求单（Jira / Notion / 需求文档）**原样摘录**，保留原文用词与标点，**禁止润色、提炼、转述**。原文有错别字 / 用词不统一（如「装填维度」实为「筛选维度」）也照抄，旁边用括号注明「此处逐字保留原文」——**改写会让读者无法确认你引的是不是他要的那句**。
|
|
268
|
+
2. **按句拆解，三列并排**：「需求原文（逐字） / 我们的实现 / 证据」——每句原文独占一行，右侧写明这句对应改了哪块代码 / 哪个页面，以及**证据落在哪**（哪张图、哪条命令、哪个数字）。禁止把多句原文压成一段再笼统配一句「已实现」。
|
|
269
|
+
3. **原文之外我们额外做的必须单列并回连原文**：自研 / 顺带修的部分另起一张表（两列：「原文之外我们额外做的 / 它服务于原文的哪一句」），**逐条说明它服务于原文哪一句**。禁止让自研内容脱离原文独立成章——读者看不出它跟需求的关系，就会当成「夹带私货」或「跑偏了」。
|
|
270
|
+
4. **原话出处给到可点链接**：需求单号 + URL 写在引用块头部（如 `MP-160 · https://.../browse/MP-160`），让读者能自己回去核对原话，而不是只能信你摘的这段。
|
|
271
|
+
- ⚠️ **与相邻铁律的分工**：**本条管「报告怎么组织」——骨架必须是需求原文**；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「怎么证明」（主验证 + 真实链路佐证）。三者叠加，报告才是「有骨架、有证据、有对照」的。
|
|
272
|
+
- ⚠️ **具体操作流程见 `/forensic-report` skill 与 `/create-doc` skill**（需求原文从哪取、引用块与三列表怎么排、自研部分怎么回连）。
|
|
273
|
+
|
|
262
274
|
## ⚠️ 取证报告铁律（证明「该变的变了」+「不该动的地方一行没动」）
|
|
263
275
|
|
|
264
276
|
- ⚠️ **核心认知：功能验证只回答了一半问题。** 「页面功能验证铁律」「跨系统真实链路验收铁律」证明的都是**该变的地方变了**；但一次写操作真正危险的部分是它的**副作用范围**——级联删除、批量更新、绑定清理会不会顺手把不该动的数据一起带走。**副作用失控是静默的**：页面照常渲染、功能照常用、接口照常 200，只有被顺带删掉的那几张表知道出过事，而没有任何页面会主动告诉你「我多删了 3 行」。所以「不该动的地方一行没动」必须**单独取证**，不能由「功能正常」推出来。
|
package/package.json
CHANGED
package/rules/global.md
CHANGED
|
@@ -259,6 +259,18 @@ agent-rules 生成的规则文件分两层，行为与归属不同，评审/发
|
|
|
259
259
|
- ⚠️ **不命中触发条件的改动，两段都不走**（纯文案、纯展示类改动不受影响）。
|
|
260
260
|
- ⚠️ **具体操作流程见 `/real-chain-verify` skill**（怎么画链路、每类系统怎么取证、两段各自做到什么程度、证据怎么组织成报告）。
|
|
261
261
|
|
|
262
|
+
## ⚠️ 报告以需求原话为骨架铁律（原文 ↔ 实现 ↔ 证据 三段式）
|
|
263
|
+
|
|
264
|
+
- ⚠️ **核心认知：报告的读者是需求方，而他判断「做没做到」的唯一依据是需求原话。** 报告只写「我们做了什么」，等于让读者自己拿记忆里的需求去比对满篇实现描述——需求→实现之间隔着产品转述、口头对齐、中途口径变化，他拼错了图就会以为某条没做（或以为做了其实没做）。**把原话摆在每段实现旁边，读者不用回忆、不用拼图，逐句对一眼即可。**
|
|
265
|
+
- **类比：报销单不能只写「我花了多少钱」，得把发票贴在你填的每一个数字旁边——审核的人对着发票核你填的数，而不是凭你的口头描述签字。**
|
|
266
|
+
- ⚠️ **硬性要求（交付任何需求实现 / 修复验证 / 取证报告时逐条满足，缺一不算完成）：**
|
|
267
|
+
1. **逐字引用需求原文**：从需求单（Jira / Notion / 需求文档）**原样摘录**，保留原文用词与标点，**禁止润色、提炼、转述**。原文有错别字 / 用词不统一（如「装填维度」实为「筛选维度」）也照抄，旁边用括号注明「此处逐字保留原文」——**改写会让读者无法确认你引的是不是他要的那句**。
|
|
268
|
+
2. **按句拆解，三列并排**：「需求原文（逐字） / 我们的实现 / 证据」——每句原文独占一行，右侧写明这句对应改了哪块代码 / 哪个页面，以及**证据落在哪**（哪张图、哪条命令、哪个数字）。禁止把多句原文压成一段再笼统配一句「已实现」。
|
|
269
|
+
3. **原文之外我们额外做的必须单列并回连原文**：自研 / 顺带修的部分另起一张表（两列：「原文之外我们额外做的 / 它服务于原文的哪一句」），**逐条说明它服务于原文哪一句**。禁止让自研内容脱离原文独立成章——读者看不出它跟需求的关系，就会当成「夹带私货」或「跑偏了」。
|
|
270
|
+
4. **原话出处给到可点链接**：需求单号 + URL 写在引用块头部（如 `MP-160 · https://.../browse/MP-160`），让读者能自己回去核对原话，而不是只能信你摘的这段。
|
|
271
|
+
- ⚠️ **与相邻铁律的分工**：**本条管「报告怎么组织」——骨架必须是需求原文**；「⚠️ 取证报告铁律」管「报告要证明什么」（该变的变了 + 不该动的一行没动）；「⚠️ 修复验证铁律」管「怎么证明」（主验证 + 真实链路佐证）。三者叠加，报告才是「有骨架、有证据、有对照」的。
|
|
272
|
+
- ⚠️ **具体操作流程见 `/forensic-report` skill 与 `/create-doc` skill**（需求原文从哪取、引用块与三列表怎么排、自研部分怎么回连）。
|
|
273
|
+
|
|
262
274
|
## ⚠️ 取证报告铁律（证明「该变的变了」+「不该动的地方一行没动」）
|
|
263
275
|
|
|
264
276
|
- ⚠️ **核心认知：功能验证只回答了一半问题。** 「页面功能验证铁律」「跨系统真实链路验收铁律」证明的都是**该变的地方变了**；但一次写操作真正危险的部分是它的**副作用范围**——级联删除、批量更新、绑定清理会不会顺手把不该动的数据一起带走。**副作用失控是静默的**：页面照常渲染、功能照常用、接口照常 200，只有被顺带删掉的那几张表知道出过事，而没有任何页面会主动告诉你「我多删了 3 行」。所以「不该动的地方一行没动」必须**单独取证**，不能由「功能正常」推出来。
|
|
@@ -120,6 +120,8 @@ description: >-
|
|
|
120
120
|
|
|
121
121
|
### 报告结构
|
|
122
122
|
|
|
123
|
+
⚠️ **交付「需求实现 / 修复验证 / 取证」类文档时，正文骨架必须以需求原话为第一层**（规则见 `AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求原文（保留原用词与标点），按句拆成「需求原文 / 我们的实现 / 证据」三列表并排，引用块头部给需求单号 + 可点 URL；原文之外额外做的另起一张「原文之外我们额外做的 / 它服务于原文的哪一句」两列表逐条回连。纯操作指南 / 纯设计文档不受此限。
|
|
124
|
+
|
|
123
125
|
```html
|
|
124
126
|
<!DOCTYPE html>
|
|
125
127
|
<html lang="zh-CN">
|
|
@@ -212,14 +212,15 @@ SELECT provider_id, count(*) FROM provider_model_pricing
|
|
|
212
212
|
|
|
213
213
|
## 报告骨架（缺一不算完成）
|
|
214
214
|
|
|
215
|
-
1.
|
|
216
|
-
2.
|
|
217
|
-
3.
|
|
218
|
-
4.
|
|
219
|
-
5.
|
|
220
|
-
6.
|
|
221
|
-
7.
|
|
222
|
-
8.
|
|
215
|
+
1. **需求原文 ↔ 实现 ↔ 证据**（骨架的第一层，见规则「⚠️ 报告以需求原话为骨架铁律」）：逐字引用需求单原文（保留原用词与标点，错别字照抄并注明「逐字保留原文」），按句拆成三列表并排——「需求原文（逐字） / 我们的实现 / 证据（哪张图 / 哪条命令 / 哪个数字）」，引用块头部给出需求单号 + 可点 URL；原文之外我们额外做的另起一张两列表「原文之外我们额外做的 / 它服务于原文的哪一句」，逐条回连。
|
|
216
|
+
2. **产品自己的承诺**（可选但强烈建议）：产品在界面上对用户承诺了什么（如确认框文案原文）。**先摆产品的承诺，再用证据逐条验证它有没有兑现**——这比自说自话有说服力得多。
|
|
217
|
+
3. **去哪儿看**（可复核导航）：N 个入口的实拍位置 + 点哪几下 + 直达 URL + 搜索词。
|
|
218
|
+
4. **证据分层结论**：三层（页面数字 / 逐像素 / 数据库）各自的关键数值，并按「从软到硬」说明**每一层会被什么骗过、为什么需要下一层**。
|
|
219
|
+
5. **差异归因**：每一处差异的定位 + 放大图 + 归因结论。
|
|
220
|
+
6. **数据库逐行对照**：基线 → 事后 → 增减量 → 是否等于预期。
|
|
221
|
+
7. **真实的操作链**：逐步截图 + 前置条件说明。
|
|
222
|
+
8. **副作用范围上界表**：逐条 DELETE 的三个问题 + 实测值。
|
|
223
|
+
9. **结论**：逐条列出证据关键数值与可复查标识，量化说清「该变的变了多少、不该动的 0 变化」。
|
|
223
224
|
|
|
224
225
|
⚠️ **报告要在靠前位置放一张「为什么这样验证成立」的原理卡**：先讲清「本次变更的本质是哪一个动作」，再论证「手动模拟该动作 = 真实场景」。**本次的核心论证是**：这个修复的唯一改动点，可以精确映射成一个可手动触发的原子操作（如「对一个还挂着 Active 模型映射的账户执行删除」）——它在旧代码上必定失败、在新代码上必定成功，**是一个天然的「版本判别器」**。所以并不是「删了账户再回头证明表没被动」，而是**刻意构造了一个只有新版本才做得成的动作**：动作做成了 = 新版在跑；副作用范围正确 = 级联被限制住了。**两件事一起成立，才等于「修复按预期生效」。**
|
|
225
226
|
|
|
@@ -241,7 +242,7 @@ SELECT provider_id, count(*) FROM provider_model_pricing
|
|
|
241
242
|
|
|
242
243
|
## 相关
|
|
243
244
|
|
|
244
|
-
- 规则出处：`AGENTS.base.md`「⚠️
|
|
245
|
+
- 规则出处：`AGENTS.base.md`「⚠️ 取证报告铁律」；报告骨架第一层（需求原文 ↔ 实现 ↔ 证据）出处：`AGENTS.base.md`「⚠️ 报告以需求原话为骨架铁律」
|
|
245
246
|
- 改之前证明问题存在：`AGENTS.base.md`「⚠️ 缺陷复现铁律」
|
|
246
247
|
- 改之后证明问题消失：`AGENTS.base.md`「⚠️ 修复验证铁律」
|
|
247
248
|
- 链路成不成立（下游接住了吗）：`AGENTS.base.md`「⚠️ 跨系统真实链路验收铁律」+ `real-chain-verify` skill
|