| name | krit-rule-vetting |
| description | Use when auditing Krit static-analysis rules for false positives, missing project context, library lookalikes, config mismatches, Java/Kotlin coverage gaps, or comparing findings against representative Kotlin/Java/Android projects. Covers both rule precision and Gradle/version-catalog false positives. |
Krit Rule Vetting
Use this workflow before broadening a rule, trusting a noisy result, or changing rule metadata.
Evidence Patterns To Check
- Comments and strings: source text scans must not match comments, KDoc, escaped strings, raw strings, or Gradle string literals unless the rule is explicitly about those nodes.
- Token boundaries: avoid substring and prefix matches for identifiers, imports, URLs, method names, and local lookalikes.
- Receiver/owner proof: common method names need structural receiver, owner, import, source-index, or type evidence.
- Scope boundaries: walks must stop at nested functions, lambdas, anonymous functions, classes/objects, and declarations that can shadow names.
- Traversal completeness: inspect all relevant operands, siblings, and ancestors instead of only the first convenient child.
- Parser shape: verify flat AST node kinds for important Kotlin/Java constructs with focused tests.
- Java parity: if a rule declares Java support, add Java positives and Java local-lookalike negatives.
- Config parity: schema metadata, validation, defaults, and runtime matching must agree.
Start With Evidence
Run the target repo with JSON. Add performance metadata when cost matters:
go build -o krit ./cmd/krit/
./krit -no-cache -perf -perf-rules -f json -q -o /tmp/krit_target.json /path/to/project || true
Inspect samples for the rule:
jq -r '.findings[] | select(.rule=="RuleName") | [.file,.line,.message] | @tsv' /tmp/krit_target.json
jq -r '.perfRuleStats[] | select(.rule=="RuleName")' /tmp/krit_target.json
Before judging findings, verify project config is applied. If uncertain, pass --config.
Check Project Context
High-volume or surprising findings are often caused by missing project facts. Inspect:
jq '.projectProfile | {hasGradle, dependencyExtractionComplete, hasUnresolvedDependencyRefs, catalogCompleteness}' /tmp/krit_target.json
If Gradle or dependency extraction is incomplete, rules that depend on library absence should stay conservative.
Vet The Rule
For each suspected issue:
- Confirm the registry entry has accurate
NodeTypes, Languages, Needs, fix level, confidence, and implementation.
- Confirm the rule uses the narrowest available evidence: AST, imports, source inference, project profile, cross-file index, module index, or KAA.
- Add the regression fixture that would have failed before the fix.
- Include Java/Kotlin parity fixtures when the rule supports both languages.
- Run focused tests first, then full validation when the change is no longer local.
Validation
go build -o krit ./cmd/krit/
go vet ./...
go test ./... -count=1
