Record which rules run on Python, measured rather than read

[zmaril]

A notes-only change. Once a Python parser pack exists (entl#13), some rules work on Python for free, some are lit up by the pack, some correctly decline, and some are genuinely Rust-only. The brief called that inventory "a cheap deliverable in itself"; this is it, taken by running each rule rather than by reading applies_to.

Two corpora: 44 files of CPython's Lib (json, asyncio, argparse, dataclasses), and a file written to contain one trigger for every regex rule.

Work today, no further work — seven rules

file-size (3 findings), deep-nesting (71), emoji, stray-todo, no-comments, unknown-barrier, unused-marker.

The pack is not what turned these on — nothing was. entl-codebase has carried a Python LanguageProfile all along, which is why stray-todo already had a Python test before any of tonight's work.

unknown-barrier is listed as applies, not demonstrated: I did not produce a finding for it.

Lit up by the pack, and by nothing else — two rules

exact-clone (26 findings) and near-clone (11). Verified by running the same 44 files against a parser-paths directory holding only the rust pack:

without the python pack   ok — no findings in 44 file(s)
with it                   37 error(s) across 44 file(s)

These read the pack's [tokenization] lists, which is what makes those lists load-bearing rather than decorative. infact-duplication classifies only leaf nodes, so declaring Python's string — a parent of string_start/string_content/string_end — would have named a kind that exists and normalized nothing, and near-clone would have compared string contents as if they were code. Silently. The pack declares string_content for that reason.

Correctly decline — four rules

color, inline-font, inline-svg, motion are all RegexRules gated on a style facet Python does not have. A Python file containing "#ff8800", a font-family string, an inline <svg> and a transition: string produces zero findings.

Recorded explicitly so nobody "fixes" it: giving Python a style facet would make every hex string in every Python file a finding.

Genuinely Rust-only — four rules, each with what it would need

error-discard is the interesting one. It is fact-backed through infact-errors, whose entire vocabulary is a fallible return type, and Python spells failure with exceptions. It needs [error-handling] in the pack plus a queries/discards.scm naming Python's forms (except: pass, an except that only logs, an unawaited coroutine, contextlib.suppress). The pack deliberately ships neither yet — inventing values for a Result-shaped manifest before writing the forms would be guessing.

effect-barrier and effect-capability need an effect catalog and a call graph. library-opportunity needs behavior derivation; infact-python-normalize (infact#24) is the half of that which now exists.

A gap this turned up

analysis-incomplete exists to say "fact-backed analysis could not inspect a source file." Run over 44 Python files with no Python parser pack configured, it reported nothing, and straitjacket printed:

ok — no findings in 44 file(s)

which reads as a clean repository and is not one. The rule reports facts.diagnostics, and those are parse failures; a file with no parser at all is never selected and so never becomes a diagnostic. The one case that most needs saying — an entire language went unanalyzed — is the one it cannot say.

With the pack it works exactly as intended, and names the construct:

gap.py:1:1  [analysis-incomplete]  exact-clones
  line 1: the grammar cannot read `T =`

The notes record the cheapest fix (have infact-analysis emit a diagnostic for a file whose language resolves to no pack) and that this is not hypothetical: it was Python's state until today and is every un-onboarded language's state now.

No code changed; cargo fmt --all --check is clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UBzKrVRq966CUheQEUCunT