class JavaTaintTracker:
  def __init__( self, params: set[str], sinks: frozenset[str], sanitizers: frozenset[str], sources: frozenset[str], *, assume_taint_preserving: bool = True, ) -> None
  def visit(self, root: tree_sitter.Node) -> None  // L123

(not documented)

The code exposes TaintTracker variants for Java, JavaScript, and Rust in dedicated modules (`dataflow_java.py`, `dataflow_javascript.py`, `dataflow_rust.py`), but these classes and their methods are never mentioned in the documentation. While these may be internal implementation details, their public export in the module API surface suggests they should either be documented or marked as private.

Either document these TaintTracker variants in a private/internal API section, or prefix the class names with underscore (`_JavaTaintTracker`, etc.) to signal they are not part of the public contract. If they are meant to be public, add a section to the relevant language documentation pages explaining when and how to use these dataflow analysis classes.

class RuleSpec  // L81

(not documented)

The `RuleSpec` class from `_rule_listing.py` is exported and used as the parameter/return type for several public functions (`iter_rule_specs()`, `filter_specs()`, `format_*_listing()`), but the class itself and its fields are never documented. Users or extension developers who want to work with rule specifications have no way to know what attributes or methods `RuleSpec` provides.

Document the `RuleSpec` class in an API reference or programmatic API section. Include the class docstring and all public fields/methods so developers can understand what data is available and how to use it.

def format_json_listing(specs: list[RuleSpec]) -> str  // L243
def format_markdown_listing(specs: list[RuleSpec]) -> str  // L282
def format_sarif_listing(specs: list[RuleSpec]) -> str  // L323

(not documented)

The `_rule_listing.py` module exports three public formatting functions (`format_json_listing`, `format_markdown_listing`, `format_sarif_listing`) that are not mentioned anywhere in the documentation. These are used internally by `safelint list-rules --format`, but their availability as importable functions is not documented for users or extension developers.

Add a section to the documentation (either in the API reference or in a new "Programmatic API" page) that documents these formatting functions, their signatures, parameters, and return types. This would help extension developers who want to programmatically generate rule listings in different formats.

ALL_RULES: list[type[BaseRule]]  // L40
RULE_BY_NAME: dict[str, type[BaseRule]]  // L88

(not documented)

The `safelint.rules` module exports two module-level variables (`ALL_RULES` and `RULE_BY_NAME`) that provide direct access to the rule registry. These are not documented, so users or extension developers who want to programmatically iterate rules or look them up by name have no guidance on how to use these exports.

Document these two exports in an API reference section. Explain that `ALL_RULES` is a list of all registered rule classes and `RULE_BY_NAME` is a dict mapping rule names (e.g. 'function_length') to their corresponding rule class, with examples of how to use them.

def get_language_for_file(filepath: str) -> LanguageDefinition | None  // L111
def supported_extensions() -> frozenset[str]  // L122
def unavailable_extensions() -> dict[str, str]  // L134
def install_hint_for(extension: str) -> str | None  // L148
def extra_name_for(extension: str) -> str | None  // L160

(not documented)

The `safelint.languages` module exports five functions for language detection, support querying, and install hints, but none of these are documented. These appear to be programmatic APIs intended for tools, plugins, or scripts that need to introspect language support without invoking the CLI.

Add a section to the documentation (e.g., in a new "Programmatic API" or "Language Support" page) that documents these five functions: their signatures, parameters, return types, and use cases. Include examples showing how a plugin or tool might use them to detect which grammars are installed or generate install hints.

def compute_engine_fingerprint( safelint_version: str, active_rules: Iterable[tuple[str, str, str, dict[str, Any]]], per_file_ignores: Iterable[tuple[str, Iterable[str], Iterable[str]]] = (), engine_internal_ignored: Iterable[str] = (), ) -> str  // L97
def compute_file_key(source: bytes, engine_fingerprint: str, filepath: str) -> str  // L151
class LintCache:
  def __init__(self, cache_dir: Path | None) -> None
  def get(self, key: str) -> tuple[list[Violation], list[Violation]] | None
  def put(self, key: str, violations: list[Violation], suppressed: list[Violation]) -> None  // L173

(not documented)

The `safelint.core._cache` module exports caching functions and a `LintCache` class that are not documented. While these may be intended as internal implementation details, their public export suggests they could be used by external tooling to interface with safelint's caching layer. The documentation does mention `--no-cache` flag behavior but never exposes the underlying cache API.

Either: (1) mark these as private by prefixing with underscore if they are not intended for public use, or (2) document them in an internal/advanced API section explaining their purpose, parameters, and how external tools might use them to implement caching-aware integrations.