# inspiration_tree_sitter_rules.md — tree-sitter / ast-grep rule repositories we could adopt

> Status: **research notes, untracked** (matches the `docs/inspiration_*` gitignore pattern under `.gitignore:50`). Companion to `docs/newinspiration.md` (cross-extension inspiration).
> Scope: **rule repositories** only — not extension code, not protocol layers. The question: where else are people packaging high-quality, tree-sitter- or ast-grep-native rules we could vendor / port / sample?
> Validation approach: all repos below were cross-checked against the pi-lens rules baseline (sizes on `rules/ast-grep-rules/coderabbit/rules/` and `rules/ast-grep-rules/rules/` counted via `find` + `sort | uniq -c`). Gap analysis is evidence-based.

---

## TL;DR — ranked

| Rank | Repo | Stars | License | Total rules | What it is | Adopt? |
|---|---|---|---|---|---|---|
| 1 | **[ast-grep/ast-grep catalog](https://ast-grep.github.io/catalog/)** | (upstream) | (rule-by-rule) | ~50 examples | Upstream's hand-curated rule examples | **Already partially ported** — see §2 |
| 2 | **[coderabbitai/ast-grep-essentials](https://github.com/coderabbitai/ast-grep-essentials)** | 139 | Apache-2.0 | 184 CWE-mapped | Community-led security rule collection | **Already vendored** at `rules/ast-grep-rules/coderabbit/rules/` |
| 3 | **[Variably-Constant/UAST-Grep](https://github.com/Variably-Constant/UAST-Grep)** | 1 | (MIT, per README) | 3,873 (1,587 sec + 1,334 perf + 952 qual) | A separate Rust CLI binary with 71-language SAST | **Investigate carefully** — see §3 |
| 4 | **[Semgrep Registry](https://semgrep.dev/explore)** (semgrep-rules) | (large) | LGPL-2.1 | ~2,800 community + 20k+ Pro | The gold-standard SAST rule library | **Reference / port source**, not vendor |
| 5 | **[Typiqally/lintropy](https://github.com/Typiqally/lintropy)** | 4 | MIT | repo-defined (no catalog) | "Repo-defined linting" — repo-side YAML rules | **Pattern inspiration only** — see §5 |
| 6 | **[Sonar rule sets](https://rules.sonarsource.com/)** (per-language) | (large) | (mostly proprietary; open-source subset) | ~95 BLOCKER for Python alone | The next-best SonarCloud Python port target | **Continue the existing port effort** — see §6 |
| 7 | **[gstrafacci/autoaudit](https://github.com/gstrafacci/autoaudit)** | (small) | (TBD) | 26 CWE-mapped | Python + VBA AST security scanner | **Investigate** — see §7 |
| 8 | **[Juadsuarezsan/code-review-agent](https://github.com/Juadsuarezsan/code-review-agent)** | (small) | (TBD) | 10+ static analyzers | Tree-sitter + 10+ analyzers in a PR-review agent | **Skip** — wrapper repo, no new rules |
| 9 | **[wildermoth/ast-grep-rules](https://wildermoth.com/posts/ast-grep-rules)** | (blog) | (TBD) | small | Personal curated set | **Skip** — blog post, not a real repo |
| 10 | **[drom/awesome-tree-sitter](https://github.com/drom/awesome-tree-sitter)** | 51 | MIT | index | Index of tree-sitter projects (no rules of its own) | **Already noted in inspiration_neovim family** — not a rules source |

The interesting ones are **#3 (UAST-Grep)**, **#4 (Semgrep)**, **#6 (Sonar)**, and **#7 (autoaudit)**. Everything else is either already in pi-lens or a derivative of the above.

---

## 1. Pi-lens's current rules baseline (as of this audit)

Real `find ... | awk -F/ '{print $5}' | sort | uniq -c` against `rules/ast-grep-rules/coderabbit/rules/` (vendored from `coderabbitai/ast-grep-essentials`):

| Language | CodeRabbit rules shipped |
|---|---|
| python | 48 |
| java | 36 |
| ruby | 18 |
| cpp | 15 |
| go | 11 |
| csharp | 11 |
| c | 9 |
| rust | 8 |
| javascript | 7 |
| typescript | 6 |
| swift | 5 |
| kotlin | 5 |
| scala | 2 |
| php | 2 |
| html | 1 |
| **Total** | **~184** |

Plus pi-lens's own shipped native rules in `rules/ast-grep-rules/rules/` (the catalog port + slop-patterns split + bespoke TS/JS hygiene rules). And the in-house tree-sitter query rules in `rules/tree-sitter-queries/` covering: `c`, `cpp`, `csharp`, `css`, `go`, `java`, `javascript`, `kotlin`, `php`, `python`, `ruby`, `rust`, `tsx`, `typescript` (plus `*-disabled` subdirs for `abap`, `cobol`, `plsql`, `c`, `typescript`).

**Coverage gaps this audit flags** (cross-referenced against pi-lens's 47 dispatch runners + the 47+ tree-sitter query files):

- **Go**: only 11 CodeRabbit security rules + pi-lens's own Go tree-sitter block. No idiomatic Go rule pack (the kind `staticcheck`/`revive`/`golangci-lint` ship — naming, error wrapping, context propagation). The fact that pi-lens ships `golangci-lint` as a dispatch runner means **idiomatic Go style is *out of scope* for our tree-sitter layer** — defer.
- **Rust**: 8 CodeRabbit rules + pi-lens's own Rust tree-sitter block. Same pattern: `cargo clippy` already covers idiomatic Rust via the dispatch runner, so tree-sitter should focus on *what clippy misses* (e.g. cross-file patterns, lifetime patterns that don't compile-check, FFIs).
- **Kotlin / Swift / Scala**: thin (5/5/2). The tree-sitter grammars exist but coverage is sparse. **Real gap** — these are the languages where CodeRabbit coverage is weakest AND pi-lens's LSP coverage is thinnest (no Kotlin LSP auto-install per AGENTS.md; Swift via sourcekit-lsp).
- **PHP**: 2 CodeRabbit rules. The EstebanForge pi-php-review has 16 entries but those are LLM-judged rubrics, not tree-sitter rules. **Real gap**.
- **C / C++**: 9 + 15 CodeRabbit rules + pi-lens's tree-sitter block. Reasonable. cpp-check via dispatch runner handles the rest.

The takeaway: **the gap is Kotlin / Swift / Scala / PHP**. These are the languages to look for new rule sources in.

---

## 2. ast-grep catalog — already partially ported

The upstream catalog at <https://ast-grep.github.io/catalog/> lists ~50 example rules with worked `fix:` payloads. Per AGENTS.md:

> **ast-grep catalog porting (detector-only, no rewrite)** — Ship a rule when its `rule:` block is a clean detector (we report, we don't rewrite — the LSP is what fires). Skip rules whose value is the `fix:`/`transform:`/`rewriters:` payload rather than the detection.

37 catalog ports are already shipped (11 in batch 1, 15 in batch 2, 10 in batch 3 — 1 removed as too noisy). The "removed" and "skipped" lists in AGENTS.md are explicit so future contributors don't re-attempt them. **No action item** — this source is well-tapped. Worth re-scanning the upstream catalog periodically (say, when ast-grep cuts a major release) for new rules that fit the "detector-only" bar.

---

## 3. UAST-Grep — investigate carefully (not a drop-in)

**Repo:** [Variably-Constant/UAST-Grep](https://github.com/Variably-Constant/UAST-Grep) (1 ⭐, MIT-claimed, very young — single v1.0.0 tag).
**Claim:** 3,873 built-in rules across 71 languages (1,587 security / 1,334 performance / 952 quality).

### What it actually is

A **separate Rust CLI binary** (`uast-grep`), not an ast-grep-compatible rule collection. Key differences from ast-grep:

| | ast-grep | UAST-Grep |
|---|---|---|
| YAML rule syntax | `rule:` block with `pattern`/`kind`/`regex`/`inside`/`has`/`all`/`any`/`not` | `rule:` block with `all:` array of `{pattern, regex}` (similar shape but different DSL) |
| Metavar syntax | `$X` / `$$$X` | `§X` / `§§X` / `§§§X` |
| Pattern language | AST-aware with kinds | "UAST" (Universal AST) abstraction on top of tree-sitter |
| Engine | Rust, single binary | Rust core + .NET / Python bindings |
| Grammar loading | Pre-loaded via wasm or source | Built-in 37 + WASM-on-demand 34 |
| Output formats | text / json | text / json / **SARIF 2.1.0** |

### Adoption analysis — three options, none free

**Option A — Vendor the YAML rules (rule-by-rule, no engine).**
- UAST-Grep rules use a similar-but-not-identical YAML shape. Each rule needs: metavar renaming (`§X` → `$X`), pattern rewrite for compatibility, re-test against the ast-grep runner.
- Effort: ~3-5 sec per rule × 3,873 = ~3-5 hours of mechanical conversion, plus re-test + behavioral coverage. Not free, but tractable.
- Value: most UAST-Grep rules target languages pi-lens already supports (TS/JS/Python/Go/Rust/Java/C/C++/Ruby/PHP/C#/Kotlin/Scala/Swift). The 71-language coverage is mostly irrelevant (pi-lens only ships rules for grammars it has, and there's no LSP for most of the 34 WASM-on-demand grammars).
- **Realistic subset:** maybe 500-800 rules are detector-only and ast-grep-translatable. Most of the 1,587 security rules are "scan for pattern X" — same shape as CodeRabbit's collection.

**Option B — Run UAST-Grep as a separate dispatch runner.**
- Add `clients/dispatch/runners/uast-grep.ts`, install the binary via the existing installer (`clients/installer/index.ts`), parse SARIF output into the existing `ProjectDiagnostic` shape (`clients/project-diagnostics/types.ts`).
- Pros: zero rule-porting, immediate 3,873-rule coverage, SARIF output is well-shaped for ingestion.
- Cons: doubles the runtime tool footprint on every edit (ast-grep runner + uast-grep runner), the UAST-Grep rule engine is a parallel universe to our CodeRabbit baseline (potential duplicate findings at the same line — needs dedup in the dispatcher), and the project has 1 ⭐ with no real production users — risk of abandonment, breaking changes, etc.

**Option C — Reference / sample, don't vendor.**
- Treat UAST-Grep as a **pattern source** for hand-porting the highest-value rules into the native `rules/ast-grep-rules/rules/` directory. Same workflow as the existing SonarCloud Python port (AGENTS.md "SonarCloud Python rule ports") but sourced from UAST-Grep instead.
- Effort: per-rule as today (SonarCloud-style batch commits). Most valuable subset: security rules for Kotlin/Swift/Scala (the languages where CodeRabbit is thin).
- **Realistic adoption:** selective batch commits over time, same as the current 3-batch SonarCloud port pattern.

**Recommendation:** **Option C**. Same effort model as the existing SonarCloud port; doesn't bloat the install footprint; lets us cherry-pick the languages that are real gaps. Specifically: skim UAST-Grep's `rules/universal-security.yaml` and the language-specific subdirs (if any beyond the three universal files) and pick out the Kotlin/Swift/Scala rules. Per AGENTS.md "Skip rules whose value is the `fix:`/`transform:`/`rewriters:` payload rather than the detection."

**One specific gap worth filling:** if UAST-Grep ships any **Kotlin** security rules that CodeRabbit doesn't already cover (CodeRabbit has 5: `des-is-deprecated`, `desede-is-deprecated`, `jwt-hardcode`, `rsa-no-padding`, `system-setproperty-hardcoded-secret`), those are real lift — see the existing `no-ast-grep-rules yet for Kotlin` gap.

**Risk flag:** UAST-Grep is young (1 ⭐, single tag, MIT license unclear — README claims MIT but no LICENSE file confirmed). Watch for 6+ months before betting on it; treat as inspiration source, not vendor candidate. Re-check on next quarterly review.

---

## 4. Semgrep rules — reference, not vendor

**Repo:** [semgrep/semgrep-rules](https://github.com/semgrep/semgrep-rules) (the OSS rule subset of the Semgrep Registry).

The Semgrep registry is the **gold standard** for SAST rules: 2,800 community rules + 20,000+ Pro rules. The community subset is freely reusable.

### Why not vendor directly

- **License is LGPL-2.1** for the rules (different from Semgrep's engine which is proprietary). LGPL on YAML rules is **awkward** — the rules are data, not code, but if you distribute them and modify them, the LGPL may require derivative-work disclosure. pi-lens has Apache-2.0 dependencies in the rules baseline (CodeRabbit) and AGENTS.md doesn't currently reference LGPL. **Legal review needed before vendor.**
- **Different pattern DSL.** Semgrep uses `pattern-either`, `metavariable-pattern`, `metavariable-regex`, `pattern-inside`, `pattern-not-inside`, etc. Mapping to ast-grep's `any`/`all`/`inside`/`has`/`not` is mechanical but lossy in places.
- **Engine coupling.** Some Semgrep rules use Semgrep-specific features (taint mode, constant propagation, type inference) that have no ast-grep equivalent. AST-only rules port; taint-aware rules don't.

### How to use it

Treat as a **pattern source** for ports, not as a vendor. Per-rule port workflow (same as SonarCloud / UAST-Grep): find a Semgrep rule, port to ast-grep YAML, add behavioral fixture in `rules/ast-grep-rules/rule-tests/<id>-test.yml`, validate against real codebase. **The higher-value move is exactly what pi-lens already does** — see AGENTS.md "SonarCloud Python rule ports" for the workflow template.

**Recommendation:** continue the per-rule port workflow as today. The Semgrep rule count is large but the per-rule yield is similar to SonarCloud (most rules are too narrow, or have false-positive rates that don't pass the "behavioral fixture" bar, or require type info that ast-grep can't provide). Don't try to bulk-port.

---

## 5. Lintropy — pattern inspiration, not a rules source

**Repo:** [Typiqally/lintropy](https://github.com/Typiqally/lintropy) (4 ⭐, MIT, "not actively maintained right now" per the README).

Lintropy's value isn't its rules (it has none — rules live in *your* repo as `.lintropy/*.rule.yaml` files). Its value is the **pattern of repo-defined architectural/boundary rules**. From the README:

> - API code must live in `src/api/`
> - feature modules cannot import each other directly
> - `dbg!`, `println!`, or `.unwrap()` are banned outside tests
> - migrations require rollback files
> - only one module can touch `process.env`

This is a real **pi-lens gap** today. pi-lens's `ast-grep-rule-manager.ts` discovers user rules from the project (AGENTS.md references `projectRulesScan` on `RuntimeCoordinator`), but doesn't have a documented *idiom* for "this is how you write a project rule that says 'API code must live under src/api/'." Lintropy's `.lintropy/` directory layout + the `lintropy.yaml` root config + the `init --with-skill` flow is a clean template.

**Concrete lift:** write a `docs/writing-project-rules.md` skill for pi-lens that mirrors Lintropy's structure (one-rule-per-file YAML, project-root discovery, schema-friendly config). The 4 rules listed in the README are exactly the kinds of architectural checks pi-lens users would write.

**Risk flag:** Lintropy is "not actively maintained" per the README; it's hackathon code. Use as inspiration, don't depend on.

---

## 6. Sonar rule sets — continue the existing port effort

**Source:** [Sonar rule registry](https://rules.sonarsource.com/) (proprietary engine, but rule descriptions + rationale + CWE mappings are public).

Per AGENTS.md, 37 SonarCloud Python BLOCKER rules have already been ported across 3 batches. The "skipped" and "removed" lists are explicit (control-flow / type-inference / framework-specific deep knowledge).

**Adoption:** no new action — continue the existing per-batch port workflow when the SonarCloud Python (or Kotlin, or any other language) BLOCKER list grows. The 95 BLOCKER Python rules are not all the surface — SonarCloud also has CRITICAL / MAJOR / MINOR severities and ~7-10× more rules per language. Porting deeper into MAJOR requires justification (false-positive rate, type-info requirement). **Stop the porting effort at the natural rule quality cliff.**

---

## 7. autoaudit — small Python+VBA scanner, investigate

**Repo:** [gstrafacci/autoaudit](https://github.com/gstrafacci/autoaudit) (small, license TBD).

26 CWE-mapped Python + VBA security rules, AST-based. VBA is interesting because it's not a common target for tree-sitter-based tooling and pi-lens doesn't ship VBA coverage today (no tree-sitter-vba grammar in `scripts/download-grammars.ts`).

**Concrete lift:** investigate whether the 26 Python rules overlap with CodeRabbit's 48 Python rules; if there are gaps, port the unique ones. **VBA is out of scope** unless pi-lens grows a VBA use case (no current evidence of one).

**Risk flag:** tiny repo, no license file in the README, low star count. Watch before adopting.

---

## 8. What I checked but explicitly rejected

| Repo | Why no |
|---|---|
| **Juadsuarezsan/code-review-agent** | Wrapper that runs multiple analyzers; no new rules of its own. |
| **wildermoth/ast-grep-rules** | Personal blog post with a few rules. Not a maintained repo. |
| **Datadog SAST custom rules docs** | Docs for *how to write* Datadog SAST rules (using tree-sitter queries), not a rule catalog. Could inform `docs/writing-project-rules.md` (the Lintropy skill) but not directly applicable. |
| **drom/awesome-tree-sitter** | Index of tree-sitter projects (grammars, bindings, tools). Not a rule source. Already noted in `docs/inspiration_neovim*.md`. |
| **rosettalens.com/blog** | "Tree-sitter vs LSP" comparison article. No rules. |
| **SonarSource/sonar-custom-rules-examples** | Examples for writing SonarQube plugins (Java/Kotlin/Groovy code), not a rules catalog. Not applicable to ast-grep/tree-sitter. |

---

## 9. Concrete next-step proposals

In rough order of value × effort:

1. **Write `docs/writing-project-rules.md` skill** — a pi-lens-flavored version of Lintropy's pattern (one-rule-per-file YAML, repo-root discovery, severity taxonomy). Pulls from the existing `ast-grep-rule-manager.ts` + the existing project-rules scan in `RuntimeCoordinator.projectRulesScan`. Effort: S. Value: med (unlocks a real use case: "how do I tell pi-lens my project's conventions?").

2. **Investigate UAST-Grep's Kotlin ruleset** (skimming only — don't commit yet, see §3 risk flag). If it covers any Kotlin security rule CodeRabbit doesn't (the 5-rule ceiling is real), open a port issue. Effort: S (investigation). Value: med (fills a real gap).

3. **Continue the per-rule SonarCloud Python port** when SonarSource adds new BLOCKER rules. Same workflow as the existing 3 batches. Effort: M per batch. Value: med (the existing effort is well-tuned; just don't let it stall).

4. **Re-scan the ast-grep upstream catalog** on the next ast-grep major release for new "detector-only" rules. Per AGENTS.md's existing port discipline. Effort: S. Value: low (most catalog rules are either rewrite-focused or already ported).

5. **Audit `autoaudit`'s 26 Python rules** for non-CodeRabbit-overlap. Effort: S. Value: low (likely all overlap given CodeRabbit's 48-rule Python coverage).

6. **Hold off on UAST-Grep as a binary dispatch runner** until the project reaches ~50 ⭐ and has multiple releases + a non-trivial user base. Re-evaluate quarterly.

---

## Appendix A — gitignore pattern for `docs/inspiration_*`

All files matching `docs/inspiration_*.md` are gitignored under `.gitignore:50`. Sibling files already present: `docs/inspiration_gograph.md`, `docs/inspiration_neovim.md`, `docs/inspiration_neovim2.md`, `docs/inspiration_tree_sitter_rules.md` (this file). The pattern is intentionally narrow so other `docs/*.md` files (e.g. `docs/lsp-capability-matrix.md`, `docs/environment-variables.md`) remain tracked.

## Appendix B — Repo URLs gathered

For future reference:

- ast-grep catalog: <https://ast-grep.github.io/catalog/>
- ast-grep upstream: <https://github.com/ast-grep/ast-grep>
- ast-grep catalog ports in pi-lens: `rules/ast-grep-rules/rules/` (per AGENTS.md, 37 SonarCloud + ~37 catalog ports shipped)
- CodeRabbit: <https://github.com/coderabbitai/ast-grep-essentials>
- CodeRabbit in pi-lens: `rules/ast-grep-rules/coderabbit/rules/` (vendored at commit `73120109bf45c284d0cd8a37bdd7082e80e92e87` per AGENTS.md)
- UAST-Grep: <https://github.com/Variably-Constant/UAST-Grep>
- UAST-Grep docs: <https://variably-constant.github.io/UAST-Grep/rules/rules-catalog.html>
- UAST-Grep rule catalog: <https://variably-constant.github.io/UAST-Grep/rules/rules-catalog.html>
- Semgrep rules: <https://github.com/semgrep/semgrep-rules>
- Semgrep registry: <https://semgrep.dev/explore>
- Sonar rule registry: <https://rules.sonarsource.com/>
- SonarCloud Python security: <https://rules.sonarsource.com/python>
- Lintropy: <https://github.com/Typiqally/lintropy>
- autoaudit: <https://github.com/gstrafacci/autoaudit>
- code-review-agent: <https://github.com/Juadsuarezsan/code-review-agent>
- awesome-tree-sitter: <https://github.com/drom/awesome-tree-sitter>
- wildermoth ast-grep-rules blog: <http://wildermoth.com/posts/ast-grep-rules>
- OWASP CWE toolkit: <https://owasp.org/www-project-cwe-toolkit/>
- Rosettalens tree-sitter vs LSP: <https://rosettalens.com/s/ko/2026-01-21-tree-sitter-vs-lsp>
- Semgrep vs SonarQube comparison: <https://konvu.com/compare/semgrep-vs-sonarqube>
- greprules.io: <https://greprules.io/> (SAST rule registry; cross-tool)

---

# Investigation results (2026-06-25)

This section records three concrete investigations executed against the real rule sources. All counts are from `curl + grep` against the actual repo state, not estimated.

## I1. UAST-Grep Kotlin ruleset — 85 unique rules, **ast-grep-native DSL**

### Source verification

`https://raw.githubusercontent.com/Variably-Constant/UAST-Grep/main/rules/universal-security.yaml` is 909 KB, 36,553 lines, 1,598 total rule entries (per the file's own header comment). Greppable counts by language (excluding `language: '*'` universal rules):

| Language | Unique rules in UAST-Grep |
|---|---:|
| python | 270 |
| javascript | 154 |
| java | 116 |
| csharp | 100 |
| rust | 89 |
| **kotlin** | **85** |
| typescript | 71 |
| scala | 71 |
| php | 28 |
| swift | 51 |
| ruby | (in a separate YAML; not sampled) |
| go | (under-represented; only 4 in universal-security) |

### Kotlin coverage breakdown (by CWE bucket)

```
10 kotlin-cwe-798 (hardcoded secrets — API keys, passwords, private keys, AWS, OAuth, encryption keys, bearer tokens, strings.xml, Firebase, DB connection strings)
10 kotlin-cwe-327 (crypto — AES-ECB, MD5, SHA-1, DES/3DES, static IV, weak RSA, weak PBKDF2, null cipher, no-padding cipher, platform default)
 9 kotlin-cwe-95  (Android WebView RCE — JS-enabled, addJavascriptInterface, file access, loadUrl, mixed content, JS interface removal, geolocation, file access, loadURL validation)
 9 kotlin-cwe-295 (TLS/SSL — cleartext HTTP, cert validation, hostname verification, old TLS versions, WebSocket unencrypted, missing pinning, single-pin-no-backup, pinning expiration)
 8 kotlin-cwe-927 (intent — implicit-intent hijacking, broadcast unprotected, sendBroadcast, PendingIntent FLAG_MUTABLE, intent parsing, implicit-service-intent, deeplink validation, intent redirection)
 6 kotlin-cwe-89  (SQL injection — string template, raw query, Room @RawQuery, execSQL, ContentProvider, SQLDelight)
 6 kotlin-cwe-532 (logging — passwords, API keys, PII, exception with sensitive data, toString leaking, verbose logs in release)
 6 kotlin-cwe-338 (random — kotlin.random, java.util.Random, Math.random, seeded SecureRandom, random token generation)
 5 kotlin-cwe-502 (deserialization — Parcel, kotlinx.serialization, Gson TypeAdapter, Bundle gadgets, untrusted data)
 2 kotlin-cwe-926 (exported activity / provider without permission)
 2 kotlin-cwe-434 (external storage + file provider paths)
 2 kotlin-cwe-312 (plaintext storage — SharedPreferences, cache directory)
 2 kotlin-cwe-276 (world-readable files + insecure custom permissions)
 1 kotlin-cwe-916 (task affinity hijacking)
 1 kotlin-cwe-78  (Runtime.exec with user input)
+ others: kotlin-cwe-22, kotlin-cwe-470, kotlin-cwe-359, kotlin-cwe-345, kotlin-cwe-489, kotlin-cwe-530
```

### pi-lens Kotlin coverage gap

- **CodeRabbit rules shipped in `rules/ast-grep-rules/coderabbit/rules/kotlin/`**: 5 (all CWE-326/327 crypto: `des-is-deprecated-kotlin`, `desede-is-deprecated-kotlin`, `jwt-hardcode-kotlin`, `rsa-no-padding-kotlin`, `system-setproperty-hardcoded-secret-kotlin`)
- **pi-lens native Kotlin ast-grep rules in `rules/ast-grep-rules/rules/`**: 0
- **pi-lens tree-sitter Kotlin queries in `rules/tree-sitter-queries/kotlin/`**: 1 directory exists but the Kotlin file count is not separately enumerated (AGENTS.md "Currently blocking TypeScript rules (security)" mentions TS specifically; Kotlin's rule inventory is not summarized)

**Gap:** **~80 Kotlin security rules** that UAST-Grep covers but neither CodeRabbit nor pi-lens does. Most of these are Android-specific (CWE-95 WebView RCE, CWE-927 intent hijacking, CWE-926 exported components, CWE-434 file provider paths) — not covered by any other source we have access to.

### **CRITICAL CORRECTION** to the prior §3 sketch

My earlier §3 in `docs/newinspiration.md` / `docs/inspiration_tree_sitter_rules.md` §3 said:

> UAST-Grep rules use a similar-but-not-identical YAML shape. Each rule needs: metavar renaming (`§X` → `$X`), pattern rewrite for compatibility, re-test against the ast-grep runner.

**This is wrong.** Sampling 5 Kotlin rules + 1 universal rule (`universal-cwe-327-weak-hash-md5`) shows:

- The **language-specific Kotlin rules** (`language: kotlin`) use **100% ast-grep-native syntax**:
  - `kind:` — supported
  - `pattern:` — supported (uses `$X` metavars, same as ast-grep)
  - `has:` — supported
  - `notInside:` — supported
  - `severity:` — supported (`error`/`warning`/`hint`)
  - `tags:` — supported (array)
  - `note:` — supported

  Example: `kotlin-cwe-89-sql-injection` is literally:
  ```yaml
  id: kotlin-cwe-89-sql-injection
  language: kotlin
  severity: error
  message: 'CWE-89: SQL Injection via string template in query'
  rule:
    kind: call_expression
    has:
      kind: string_template_expression
  ```
  This is **drop-in compatible** with pi-lens's ast-grep-napi runner. No DSL translation.

- The **`language: '*'` universal rules** use a different shorthand:
  ```yaml
  rule:
    any:
    - pattern: md5
    - pattern: MD5
    - pattern: Md5
    - pattern: MD5_
  ```
  — no metavars here either. Also drop-in compatible. The metavar difference (`§X` vs `$X`) is real but only applies to a small subset of the most-expressive universal rules; most use either `pattern:` (string literal) or `kind:` (typed).

**Realistic porting effort for the Kotlin subset:**

- Drop 85 UAST-Grep Kotlin rules into `rules/ast-grep-rules/coderabbit/rules/kotlin/security/` (or a new top-level `kotlin/security/` dir alongside the vendored CodeRabbit set).
- Add per-rule `<id>-test.yml` behavioral fixtures per AGENTS.md "**Every shipped rule has a behavioural fixture test**" — that's the main cost.
- Add a `kotlin` entry to `rules/rule-catalog.json` per AGENTS.md "Catalog: `rules/rule-catalog.json` (globally-unique `rule_id`s; `audit:rule-catalog` gate)".
- Run `npm run audit:rule-catalog` to verify catalog consistency.
- Run `ast-grep scan -c rules/ast-grep-rules/.sgconfig.yml` to verify they fire correctly on real code.

**Single batch effort, exactly like the existing 3-batch SonarCloud Python port** (AGENTS.md §3.1 "Two key gotchas hit during porting"). Not a multi-day investigation.

### Risk notes

- UAST-Grep license claim: README says MIT, but I could not locate a `LICENSE` file via the GitHub API (only `LICENSE.md` reference). Verify before vendor — add the rule bodies to `vendor_attribution.json` or whatever pi-lens uses for CodeRabbit attribution (currently the LICENSE file in `rules/ast-grep-rules/coderabbit/` is Apache-2.0). MIT is permissive but requires attribution.
- UAST-Grep project is young (1 ⭐, single v1.0.0 tag at the time of investigation). Bumping the vendor commit is a deliberate operation, same as CodeRabbit per AGENTS.md "Vendored with the upstream commit pinned — bumping the vendor is a deliberate operation, not a `git pull`." Pin to a known-good SHA.
- 5 of the 85 Kotlin rules overlap with the 5 CodeRabbit Kotlin rules (all crypto). The port should skip those 5 (id collision → first-wins dedup per AGENTS.md "Both tiers load through the same engine, so a rule id collision is harmless (first-wins dedup)").

**Recommended action:** Open an issue to port the 80 non-overlapping UAST-Grep Kotlin rules, batched as ~25-30 rules per commit (matches the SonarCloud Python port batch size from AGENTS.md §3.1). Track separately the Swift (51), Scala (71), and PHP (28) ports for follow-up — same shape, same effort, parallel work.

---

## I2. autoaudit Python rules — 15 rules, **fully subsumed** by CodeRabbit + pi-lens

### Source verification

`https://raw.githubusercontent.com/gstrafacci/autoaudit/main/engine/scanner.py` is 431 lines. The Python rule set is the 15 entries `PY001`-`PY015` plus the `HARDCODED_SECRETS` regex list (2 entries, `PY014`/`PY015`).

### Cross-reference table

| AutoAudit ID | Vulnerability | CWE | CodeRabbit equivalent | pi-lens native equivalent | Verdict |
|---|---|---|---|---|---|
| PY001 | `eval()` external input | CWE-78 | (none direct — CodeRabbit JS/TS has it) | `no-implied-eval.yml` (TS only)