The analyzer pool: inventory, depth and license policy

The catalog of every code-analysis tool this agent knows about, how the pool is narrowed at run time, and what is fact versus what is still work.

The machine-readable form is src/maintainability_audit/_assets/analyzer-catalog.json, regenerated by tools/build_catalog.py. This page explains it; the JSON is the authority.

What is in the catalog

760 tools. 755 from the analysis-tools.dev database at commit 66668c6, captured 2026-06-10 (the database itself is CC0), plus 5 this project installed and ran that the database does not list.

Every count on this page is read from src/maintainability_audit/_assets/analyzer-catalog.json and held to it by test_the_pool_document_states_the_catalogs_own_counts — they drifted by a tool and a licence class before that test existed, which is exactly long enough for a reader to start trusting them.

Every entry carries the source's own facts — name, license, languages, homepage — and two fields that are this project's judgment, not the source's: tier and adapter.

By license class

License strings in the wild are messy: 89 distinct spellings, from MIT License to GPL with Classpath exception / MIT License to NOASSERTION. They are classified by explicit pattern, and anything unmatched stays unverified rather than being guessed.

A dual license takes the most permissive class on offer, because the licensee chooses: GPL v3 or Perl Artistic License 2.0 classifies as permissive.

PMD is an explicit catalog override in this tranche: its BSD-style license is verified against the upstream PMD LICENSE file, rather than inferred from the source catalog's Other value. Checkstyle is the matching weak-copyleft override: its LGPL-2.1-or-later license is verified against the upstream Checkstyle LICENSE file. SpotBugs is already classified weak-copyleft from the upstream catalog's GNU Lesser General Public License v2.1.

None of this is legal advice. Whether invoking a GPL analyzer as a separate process has any effect on the code it scans is a question for your own counsel. The classification exists so that whatever answer your organization reaches can be enforced, rather than left to whichever engineer installed what.

Eligible pool

448 tools are eligible: open-source license class, not deprecated, targets at least one language, and not security-only. Security scanning is secure-code-agent's job — those tools are cataloged and marked, never run from here.

Eligible by class: 368 permissive, 45 strong-copyleft, 35 weak-copyleft.

The three run-time selectors

Independent questions, and the pool is their intersection. Concerns asks what you want examined, depth how much work you want done, license policy what your organization is allowed to run. A user never names a tool.

Concerns

The vocabulary is the scoring model's, so an answer maps onto aspects that exist and can move a score.

It cannot come from the upstream data. Those tags are languages, ecosystems and frameworks — rails, nodejs, spring — and only 5 of the 448 eligible tools carry an upstream tag that names one of this project's concerns. What a tool measures is knowable only by running it, so measures is populated exactly as fast as adapters are written; the upstream tags are kept separately as upstream_tags.

python tools/resolve_pool.py --concerns duplication,dead-code
python tools/resolve_pool.py --concerns documentation

Depth

Analyzers never take their configuration from the tree they audit. Decision 9 draws the line at executing code, and configuration is code: pylint's init-hook= runs arbitrary Python before analysis begins, a mypy plugins = imports a module out of the repository, and an eslint flat config is a JavaScript program. So pylint is spawned with --rcfile, mypy with --config-file, and eslint — which cannot run at all without the tree's config — is refused by selection and reported as refused rather than run. The analyzer child also gets an environment with PYTHONPATH, NODE_PATH, NODE_OPTIONS, PYTHONSTARTUP and the LD_/DYLD_ pair removed, so nothing outside the operator's choice can decide what it loads. This is not a sandbox and is not claimed as one; the child is an ordinary local process.

The two isolation flags are structurally checked everywhere and spawned only where the binary exists — the same disclosure the two JVM tools carry below. test_every_declared_tool_is_classified_for_tree_configuration forces every declared tool to be isolated or to state that it reads no tree configuration, and the live tests plant a hostile pylintrc and mypy.ini and assert the tree's code never runs. Those live tests skip wherever the tool is absent, including this project's CI, so on a machine without pylint and mypy the flags are documented-and-asserted rather than demonstrated.

A tier below all is a promise that the tool works. Nothing is placed in baseline, moderate or heavy until this project has installed it, run it, and parsed its output — with two disclosed exceptions: Checkstyle and SpotBugs are verified against recorded real output (their conditional live tests skip wherever no binary exists, including this project's CI), so their live spawn is unproven until someone supplies the binaries. PMD has run live. That is why these numbers are small and why they grow one verified tool at a time.

all is the honest name for the rest: known to exist, license recorded, invocation not yet implemented. Selecting all today runs the same tools as heavy and reports the remainder as unavailable-no-adapter. It is not a lie by omission — the report says exactly which of them ran.

License policy

source-available and paid proprietary tools are cataloged but never selected. Adding them needs a deliberate configuration entry naming the tool, not a policy tier.

Sonar-family tools are cataloged and unadapted, not blanket-classified as commercial. The catalog classifies SonarAnalyzer.CSharp, SonarQube for IDE and SonarQube Server as weak-copyleft, while SonarQube Cloud is proprietary-free-tier; none is runnable until an adapter ships.

How the selection is made

Read from configuration (analyzers.depth, analyzers.license_policy, analyzers.concerns). A first run with no config asks the same setup questions on chat, MCP, and a CLI TTY (first run) — whether to run the pool, depth, license policy, and scan-history recording — and persists them through the same apply_answers, so both surfaces write a byte-identical maintainability-agent.json with an explicit analyzers.run. Every later run reads that file, so the pool never changes between runs of the same tree (promise P1). A non-TTY run — CI — never asks and never writes, because an audit that stopped to ask a question in a pipeline would be a broken audit, not because the CLI has a shorter questionnaire. Preview a pool without editing the file with tools/resolve_pool.py --depth / --license-policy.

The chosen depth and policy are recorded in the report, because a score computed from four tools and a score computed from forty are not the same measurement and must not be silently comparable.

Runtime prerequisites

Analyzers live in ecosystems, and the agent runs the ones it can reach. Nothing here is required — a missing runtime costs coverage, never a failed run — but each absence is reported with what would close it.

Node tools are fetched only if you opt in. With analyzers.acquire_tools set, a missing jscpd is invoked through npx --yes, which downloads the package — a network action P1 discloses, with the fetched version recorded in the report. By default it is off: a missing Node tool is reported not-installed in coverage and appears in the environment work order with its install command, and nothing is fetched. This agent does not transmit your code in either mode.

Child tools are not network-sandboxed. Once lizard, jscpd, or any other adapter runs, this process does not police outbound connections. Install tools yourself and keep them off npx if you need an air-gapped analysis.

To avoid the fetch entirely — in an air-gapped build, or to pin a version — install the tool ahead of time and it will be used directly:

npm install -g jscpd@5

Adapter status, stated plainly

18 tools have adapters. An inventory entry without an adapter is not a shipped capability.

The full inventory, including everything without an adapter, is in the JSON. Additional adapters remain incremental work; the inventory alone does not make a tool runnable.

Regenerating

pip install -e ".[dev]"   # PyYAML: the upstream catalog is YAML; not a runtime dep
git clone https://github.com/analysis-tools-dev/static-analysis /tmp/sa
python tools/build_catalog.py /tmp/sa

The pinned commit in tools/build_catalog.py is what the checked-in JSON was built from. Bumping it is a deliberate act: tool licenses and deprecations change, and a silent refresh would move the pool under a score without anyone deciding to.