当 Greptile 评审发现可复现的高风险或重复性仓库不变…

用于把已验证的评审发现谨慎提升为 .greptile 版本控制配置，并避免把一次性问题或未证实偏好写成规则。

适用场景

解决思路

1. 保持 `.greptile/` 高信噪比：把评审发现当作待评估证据，不自动视为新规则。
2. 对照当前仓库复现或追踪发现，包括相关调用路径、测试和有意例外。
3. 提出变更前先阅读 `.greptile/config.json`、`.greptile/rules.md` 和 `.greptile/files.json`。
4. 区分新引入风险与相邻遗留债务；不要编码未验证假设或一次性实现细节。
5. 仓库中不存在某做法不等于策略证据：如果 reviewer 仅因当前没有例子而推断偏好，除非 owner 明确采纳该策略，否则保持 Greptile、代码和 CI 不变。
6. 一次性 bug：修复代码并添加聚焦的回归测试；不要添加 Greptile 规则。
7. 已验证的确定性策略违规：优先使用 TypeScript、Oxlint、Knip、聚焦测试或 CI。
8. 可重复、可在 diff 中强制的不变量：在 `.greptile/config.json` 中添加或改进有范围的结构化规则。
9. 架构、偏好或误报校准：更新 `.greptile/rules.md`。
10. Greptile 应参考的规范实现：在 `.greptile/files.json` 中添加范围很窄的引用。
11. 小型工作流摩擦：使用 `papercuts` skill 并记录到 `.agents/PAPERCUTS.md`。
12. 应用提升门槛：仅当所有适用检查通过时才提升发现。
13. 已对照当前代码验证。
14. 未来 reviewer 能从 diff 和相关调用路径观察到。
15. 具有仓库特定性，或能实质性改善误报校准。
16. 可能复发，或影响足够高以值得预防：授权、安全、计费、数据丢失或跨数据库正确性。
17. 现有 Greptile 上下文和自动化检查尚未充分覆盖。
18. 指令可以具体、可衡量、范围狭窄，并明确合法例外。
19. 如果证据或策略不明确，保持配置与执行机制不变，并将候选报告给人工判断。
20. 保守编辑：每条结构化规则只保留一个连贯关注点，使用稳定的小写 ID、severity，以及最窄的未来安全范围。
21. 不要仅因当前仓库没有替代方案示例就推断永久策略。
22. 优先收窄或替换噪声规则，而不是叠加更多 prose。
23. 将仓库特定规则保留在 `.greptile/`；验证并报告最小化的 **org-enforced** dashboard baseline 是否保护外部贡献、secrets、authentication、billing、CI 以及削弱评审控制的尝试。除非用户明确要求，否则不要创建或更改 dashboard、MCP 或 organization 规则，也不要在那里复制完整仓库规则集。
24. 将 `.greptile/**`、`AGENTS.md`、`CLAUDE.md`、`.agents/skills/**` 和 `.github/**` 的变更视为评审控制变更，必须获得明确 maintainer review。CODEOWNERS 请求该评审；branch protection 或 ruleset 必须另外要求 code-owner approval（当可用时）。
25. 更新所需的最小配置文件集；不要在单独文档中复制规则正文。
26. 运行验证命令：`jq empty .greptile/config.json .greptile/files.json`、`node_modules/.bin/prettier --check .greptile/config.json .greptile/files.json .greptile/rules.md`、`git diff --check`。
27. 还要验证规则 ID 唯一、severity 有效、每个 `files.json` 路径存在，并且独立 reviewer 无法在新措辞中发现明显误报。
28. 在 merge-ready 工作中，只评估通过提升门槛的已验证发现。如果没有发现持久评审缺口，merge-ready 运行不需要修改 `.greptile/`。

适用边界 · 注意事项

• 不要用于未验证的发现、一次性实现细节，或仅因仓库无先例而推断出的偏好；这些不应写入 Greptile、代码或 CI。
• 一次性 bug 不应添加 Greptile 规则，应改代码并加回归测试。
• 除非用户明确要求，不要创建或更改 dashboard、MCP、organization 规则；证据或策略不明确时也不要改配置。