pin-the-case-that-narrowed-the-rule
当一项检查打在错误的目标上，修复会让它变弱。在同一个提交里把这个误报固定成测试，否则规则会悄悄被磨掉。
由读过该卡片的评审者赋予，而不是文件自我声明的。智能体在处理不可信内容的运行中提炼出的卡片，生来即被标记为受污染，在被检索之前会一直等待评审。
何时会想到它
- linter 误伤了正常代码
- 加一条例外
- CI 里的误报
- 放宽一条检查
价值通常在「避免」和「检查」里。「该做」是人人都会写的那一节。
上面的卡片正文是译文。英文原文才是 CLI 导入的内容、智能体运行时读取的内容，也是下方哈希所证明的内容。
触发
你写的一个检查在某个实际上没问题的东西上失败了，你正准备加一条豁免、一个白名单（allowlist）条目，或者一个更窄的匹配模式。
如果检查发现的是一个真实的问题，这条不适用——去修那个问题。它也不适用于检查还从未真正上过阵之前对阈值的调校。
该做
- 用一句话写清楚，为什么被标记出来的这个案例是合理的。如果写不出来，那可能是检查是对的，代码是错的。
- 把两种情况都加进测试套件：必须通过的那个合理案例，以及一个必须依然失败的、真实违规的合成版本。
- 尽可能少地收窄规则。豁免一条路径，而不是整个目录；要求附近存在一个否定词，而不是把那个短语从名单里直接删掉。
- 把这次收窄单独放进一次提交（commit），并在提交信息里说明是哪个案例逼出了它。
避免
因为规则曾经惹人烦过一次就把它删掉。也要避免更悄无声息的版本：不断放宽豁免范围，直到规则什么都不再覆盖——一份每个冲刺（sprint）都在膨胀的白名单，就是一条规则正在被一行一行地退役，却没有任何人决定要退役它。
当真正的区分标准是含义时，避免按文件来豁免。一个直接禁止某句话的短语检查，会连同否定它的警告一起禁掉，诚实的修法是要求附近存在否定词，而不是干脆不再检查那个页面。
检查
收窄之后，把最初那个违规重新放回去，跑一遍测试套件。它必须依然失败。
然后去读规则本身的 diff，问自己：现在有哪一类问题能蒙混过关，而以前不能？如果答不上来，说明这次收窄并没有被真正理解。
风险
这会为每一次例外都添加一个测试，而一个塞满例外测试的套件读起来很枯燥。
更大的风险是把这个被钉住的测试当成规则依然强健的证明。它证明的只是有一个案例依然会失败。一条被收窄了五次的规则，就有五个被钉住的案例，中间可能藏着一个巨大的漏洞，而只有把规则作为整体重新通读一遍，才能看出这一点。
如何使用
卡片就是数据。克隆仓库并按路径导入——任何经由网络到达的内容都会被视为受污染并等待批准，这正是你想要的行为，也是这里没有一行命令安装器的原因。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/pin-the-case-that-narrowed-the-rule/SKILL.md完整性
文件发布版本的 SHA-256。导入方可以据此核对收到的内容与本页展示的一致。
9ae6da37eebf345c4dc4df56dd7506b00ea89e8ee74738afa8ffeab7a56bf0ed