maintain-greptile-rules

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Maintain Greptile rules

维护Greptile规则

Keep

.greptile/

high-signal. A review finding is evidence to evaluate, not automatically a new rule.

保持

.greptile/

目录的高信号价值。审查发现是需要评估的证据，而非直接成为新规则。

1. Verify the finding

1. 验证发现

Reproduce or trace the finding against the current repository, including the relevant call path, tests, and intentional exceptions.

Read

.greptile/config.json

.greptile/rules.md

, and

.greptile/files.json

before proposing a change.

Distinguish a newly introduced risk from adjacent legacy debt. Do not encode an unverified assumption or a one-off implementation detail.
Repository absence is not policy evidence. If a reviewer infers a preference only because no current example exists, leave Greptile, code, and CI unchanged unless an owner explicitly adopts the policy.

针对当前仓库重现或追溯该发现，包括相关调用路径、测试及明确的例外情况。

在提议修改前，阅读

.greptile/config.json

、

.greptile/rules.md

和

.greptile/files.json

。

区分新引入的风险与相邻的遗留债务。不要将未经验证的假设或一次性实现细节编码为规则。
仓库中不存在某内容并非政策依据。若审查者仅因当前无实例就推断出偏好，除非所有者明确采纳该政策，否则不要修改Greptile、代码及CI配置。

2. Route it to the right mechanism

2. 选择合适的处理机制

One-off bug: fix the code and add a focused regression test. Do not add a Greptile rule.
Verified deterministic policy violation: prefer TypeScript, Oxlint, Knip, a focused test, or CI.
Repeatable, diff-enforceable invariant: add or refine a scoped structured rule in
```
.greptile/config.json
```
.
Architecture, preference, or false-positive calibration: update
```
.greptile/rules.md
```
.
Canonical implementation Greptile should consult: add a narrowly scoped reference in
```
.greptile/files.json
```
.
Small workflow friction: use the
```
papercuts
```
skill and log it in
```
.agents/PAPERCUTS.md
```
.

一次性bug：修复代码并添加针对性的回归测试。不要添加Greptile规则。
已验证的确定性政策违规：优先使用TypeScript、Oxlint、Knip、针对性测试或CI工具处理。
可重复、可通过差异强制执行的不变量：在
```
.greptile/config.json
```
中添加或细化范围明确的结构化规则。
架构、偏好或误报校准：更新
```
.greptile/rules.md
```
。
Greptile应参考的标准实现：在
```
.greptile/files.json
```
中添加范围狭窄的引用。
轻微工作流摩擦：使用
```
papercuts
```
技能并记录在
```
.agents/PAPERCUTS.md
```
中。

3. Apply the promotion bar

3. 满足升级标准

Promote a finding only when all applicable checks pass:

It is verified against current code.
A future reviewer can observe it from the diff and relevant call path.
It is repository-specific or materially improves false-positive calibration.
It is likely to recur, or its impact is high enough to justify prevention: authorization, security, billing, data loss, or cross-database correctness.
Existing Greptile context and automated checks do not already cover it adequately.
The instruction can be specific, measurable, narrowly scoped, and explicit about legitimate exceptions.

If the evidence or policy is ambiguous, leave the configuration and enforcement unchanged and report the candidate for human judgment.

仅当所有适用检查通过时，才将发现升级为规则：

已针对当前代码验证。
未来的审查者可通过差异及相关调用路径观察到该规则。
该规则是仓库特定的，或能显著改善误报校准效果。
问题可能重复出现，或其影响严重到值得预防：如授权、安全、计费、数据丢失或跨数据库一致性问题。
现有Greptile上下文及自动化检查未充分覆盖该问题。
规则指令需具体、可衡量、范围狭窄，并明确说明合法例外情况。

若证据或政策存在歧义，请勿修改配置及执行规则，将候选规则上报给人工判断。

4. Edit conservatively

4. 保守修改

Keep one coherent concern per structured rule, with a stable lowercase ID, severity, and the narrowest future-safe scope.
Do not infer permanent policy merely because the current repository has zero examples of an alternative.
Prefer narrowing or replacing a noisy rule over layering on more prose.
Keep repository-specific rules in
```
.greptile/
```
. Verify and report whether a minimal org-enforced dashboard baseline protects external contributions, secrets, authentication, billing, CI, and attempts to weaken review controls. Do not create or change dashboard, MCP, or organization rules unless the user explicitly asks, and do not duplicate the full repository rule set there.
Treat changes to
```
.greptile/**
```
,
```
AGENTS.md
```
,
```
CLAUDE.md
```
,
```
.agents/skills/**
```
, and
```
.github/**
```
as review-control changes that must receive explicit maintainer review. CODEOWNERS requests that review; branch protection or a ruleset must separately require code-owner approval when available.
Update the smallest set of configuration files needed; do not duplicate rule bodies in separate documentation.

每条结构化规则仅关注一个连贯的问题，使用稳定的小写ID、严重程度，并采用最窄的、面向未来的范围。
不要仅因当前仓库没有替代方案的实例就推断出永久政策。
优先缩小或替换噪音规则，而非添加更多说明性文字。
将仓库特定规则保留在
```
.greptile/
```
目录中。验证并汇报最小化的组织强制执行仪表板基线是否能保护外部贡献、密钥、认证、计费、CI及试图削弱审查控制的行为。除非用户明确要求，否则不要创建或修改仪表板、MCP或组织级规则，也不要在那里复制完整的仓库规则集。
将
```
.greptile/**
```
、
```
AGENTS.md
```
、
```
CLAUDE.md
```
、
```
.agents/skills/**
```
及
```
.github/**
```
的修改视为审查控制变更，必须获得维护者的明确审查。CODEOWNERS会发起审查请求；若有可用的分支保护或规则集，需单独要求代码所有者批准。
仅更新所需的最小配置文件集；不要在不同文档中重复规则内容。

5. Validate

5. 验证

Run:

bash

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

Also verify that rule IDs are unique, severities are valid, every

files.json

path exists, and an independent reviewer cannot find a clear false positive in the new wording.

During merge-ready work, evaluate only verified findings that clear the promotion bar. A merge-ready run does not need to change

.greptile/

when no durable review gap was found.

运行以下命令：

bash

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

同时验证规则ID是否唯一、严重程度是否有效、

files.json

中的每个路径是否存在，以及独立审查者无法在新表述中找到明显的误报。

在合并就绪工作中，仅评估符合升级标准的已验证发现。若未发现长期存在的审查缺口，合并就绪运行无需修改

.greptile/

配置。